来自 Viv（@Vtrivedy10）的推文线程

我目前实验中提出的问题是：如果我们执着地在编码代理框架的每个重要维度上选择“略微更好的工具”，我们究竟能把编码代理框架优化到什么程度？ 影响代理性能的最大因素是模型智能（参见 Opus 4.5）。但是，我们在框架中做出的每一个工具选择又该如何考虑呢？如果每个工具的性能都提升 X%，那么我们在任务上究竟能提升多少性能？ 有些关键的基本功能已经成为许多全功能编码代理的默认设置： - 良好的本地搜索（例如：近年来 warpgrep、mgrep 等工具带来的“更好”的搜索体验） - 良好的网络搜索，通常此工具本身就是代理，我们会调用 websearch+代理端点来更好地准备数据（例如：@p0） - 内置了良好的上下文管理功能，例如 Anthropic 的工具搜索工具、上下文编辑、更好的压缩以及文件系统组织指令，以便根据需要卸载和重新加载上下文。 - 针对规划或审查等常见任务，已针对默认子代理进行了良好的调整 - ETC 我对未来充满期待，期待着： 1. 一个优秀的基础框架是构建者可以基于其进行构建的交付机制（例如 Claude Agent SDK 和其他框架）。 2. 构建者注入一系列可插入到框架中的功能。我目前非常看好技能作为一种分发机制，我们还有一些工具/MCP可以存在于技能中。 3. 构建者优化了安全带提示，使其与安全带中展示的技能/工具集良好配合。 4. 构建者根据评估结果迭代更新线束 在这个世界上，以下方面具有很高的价值： 驱动线束的模型 - 全套代理产品，精心挑选了一款优秀的模特+安全带组合 - 该工具/功能层可插入线束，并在每次调用该功能时产生收益。