通过结构化实验系统检查 Agent Zero 的提示、工具、内存与执行规则，六项候选改动均未获晋级的详细记录。
AI translation, not an official translation. Refer to the original for technical details.
Adapted from @Agent0ai# 打开线束，了解智能体的运作原理。 一个模型可以写出优秀的代码，却依然是一个令人沮丧的编码智能体。 它能找到正确的文件，做出修改，通过几个测试，却错过了真正的需求。它能从一次工具调用失败中恢复，却忘记了自己原本想完成什么。它可能花费一千个 token 阅读某些内容，最终却对决策毫无影响。 如果你想知道原因，就打开线束。 线束是模型周围一切将响应转化为工作的东西：指令、工具、观察结果、内存、执行环境，以及继续或停止的规则。每个部分都影响着智能体能注意到什么，以及它接下来会做什么。 我们最近花了将近两天时间检查和修改 Agent Zero 中的这些部分。我们审查了 Terminal-Bench 2 和 DeepSWE 的运行轨迹，然后使用我们的 Revolve（https://github.com/agent0ai/revolve）工作流进行了一组单独的本地 Terminal-Bench 4 实验。我们测试了六项候选改动，保留了详细记录，并在此过程中修复了几个具体缺陷。 六项候选均未获晋级进入通用线束。这一结果及其背后的教训值得分享。 ## 智能体可以有不止一种形态 从一个模型选择工具、读取结果、再次选择开始。这是一种有用的工作流。 现在给它一个在步骤之间持续存在的计划。或者让它在提出补丁之前先定位相关代码。或者让一个协调者将独立的工作分配给专家并汇总他们的发现。模型可能保持不变，而围绕它的系统却发生了实质性的变化。 直接循环可以在每次观察后进行调整。计划为依赖步骤提供了共同方向，但增加了需要维护的状态。先定位的工作流缩小了需要考虑的代码范围，但可能遗漏该边界之外的依赖关系。委派分离了独立的调查，但协调者仍然需要整合各方答案。 每种形态都会改变决策发生的位置、哪些上下文能到达决策点，以及错误如何传播。 这些都是概念性的工作流模式。下面我们实测的实验改动的是线束中更细小的部分，而不是对这四种完整架构进行基准测试。 一个有用的线束能让你探索这些选择。Agent Zero 为此提供了多个切入点： - 提示塑造了智能体处理问题的方式。它们是可读的文件，支持特定配置文件的覆盖。 - 工具和插件塑造了它可以执行的操作以及它收到的反馈。核心能力也使用插件系统。 - 内存和上下文塑造了它能从早期工作中带入什么。 - 配置文件和委派塑造了职责的划分方式。 - 项目和范围化设置允许将实验应用于特定工作区或智能体，而不是更改所有人的默认值。 你可以从一个小的提示覆盖开始。当证据指向工具问题时，你可以检查该工具。当问题在于到达模型的内容时，你也可以检查那个边界。 这使得该框架成为一个通过真实干预来学习的地方。一个假设可以变成一个文件修改、一条追踪记录，以及一个可衡量的结果。 ## 六个合理的想法，六个需要衡量的理由 Agent Zero 的提示刻意保持紧凑。我们希望在改善行为的同时保留这种经济性。添加一句话很容易；证明它改善了已完成的工作则更难。 我们在本地的 Terminal-Bench 4 环境中从十个纯 CPU 任务起步，主模型为 GLM-5.3-flash。 我们将五个任务用于开发，在筛选候选方案时将另外五个任务保留，不纳入详细的失败分析。前三个候选方案对求解指导做出了修改： 1. 组织性。使所请求的行为、权威输入、相关代码与交付物之间的关联更加明确。 1. 导航性。寻求能够改变下一步决策的最小观测量，而非大范围搜索和反复阅读。 1. 研究动力。识别一个尚未解决的假设，选择一个能够区分不同解释的行动，然后根据证据更新方案。 这三条听起来都很合理。"听起来合理"，正是一项实验的起点。 来看一次五任务对比。基线方案在五次尝试中完成了三个任务，共使用 438,000 个输出 token。组织性方案完成一个，使用 562,000 个；导航性方案完成零个，使用 491,000 个；研究动力方案完成一个，使用 548,000 个。 在这个例子中，每个候选方案使用了更多的输出 token，却完成了更少的任务。结论是保留基线方案。一条听起来合理的指令，必须切实改善工作效果，才能获得进入默认测试框架的资格。 我们的实际实验同样没有产生任何值得晋升的候选方案；其测量结果与上述示例相互独立。 随后我们尝试了三项更细粒度的修改：种子记忆召回、更清晰的 Python 运行时指导，以及一个关于剩余时间的实际提示。 召回候选方案多通过了一项部分检查，但两组实验实际上都没有发生记忆召回。我们无法将这一差异归功于检索机制的改变。 截止时间候选方案在限制时间内完成了任务，而其对照组超时。两者仍然都未能完成任务，均只通过了五项检查中的同一项。其中一对实验的对照组在运行期间存在共享主机活动，单凭这一对不足以证明有任何收益。 有益的纪律在于：在合理的修改真正证明自己的价值之前，将其拒之于默认测试框架之外。 ## 一个看似成功的错误 在 DeepSWE 的运行追踪中，我们发现了一些增量处理的实现，它们在解析之前会先收集完整的数据流。 这样的代码可以产生预期的最终输出，现有测试也可以通过。然而所请求的行为——增量地产出结果——依然缺失。如果你以活动量来衡量进展——编辑了多少文件、运行了多少命令、通过了多少测试——这个错误很容易被忽视。 一个更好的问题是：什么样的观测能够将我们所请求的行为与我们不经意间构建出的更简单行为区分开来？ 对于流式处理而言，这或许意味着检查第一个结果是否在完整输入可用之前就已抵达。如果大量测试中没有一项能做出这种区分，测试数量再多也意义有限。 这一教训的适用范围超越了验证本身。它改变了智能体读取任务的方式、选择实现方案的方式、解读反馈的方式，以及判断任务已完成的方式。 ## 工具报错并非同一类问题 追踪记录还揭示了一种值得警惕的倾向：将每一次操作失败都归结为模型的格式问题。 无效的调用信封、不支持的补丁操作、过时的补丁上下文，以及执行后失败的 shell 命令，需要不同的恢复方式。Context Doctor 有助于修复许多序列化调用错误，但它无法凭空创造出一个不支持的操作，也无法将错误的算法变为正确的算法。 在我们检查的DeepSWE操作日志中，31个涵盖的试验中有27个出现了编辑失败，其中包括8个最终通过的试验。错误很常见，而应对方式至关重要。 我们复现的一个具体缺陷完全存在于提示层之下。一个编辑补丁用临时文件替换了原始文件，并丢失了原始文件的所有者信息和权限。一个可正常运行的可执行文件可能变得无法执行；一个由宿主拥有的文件可能变得难以被其所有者编辑。 修正方案存在于共享的文件替换辅助函数中：在发布替换文件之前保留现有元数据，并根据实际宿主访问权限进行验证。 无论多少"编辑时请小心"之类的提示，都无法修复那个辅助函数。 ## 改变接口可能暴露出不同的问题 我们的实时集成检查还揭示了当你通过订阅方式使用Codex并接入自定义执行框架时，原生工具调用、注释与历史记录之间的交互方式。 公开注释应当让你在代理持续使用工具的同时跟踪其工作过程。如果注释被误认为最终响应，循环可能在最不恰当的时刻终止。如果显示层将其丢弃，工作过程就会变得难以追踪。如果回放时丢弃了附带的原生条目，下一轮就会失去提供方的部分原始上下文。 我们修正了这些边界：将公开注释流式传输到生成显示界面，将推理摘要单独保存，并在Responses历史回放期间保留符合条件的原生条目。共享历史记录保持与API无关。 我们测试了普通的Codex对话、并行的Agent Zero工作器以及A0 API兼容性。在热请求上，匹配缓存检查仍可达到约93%的命中率。间歇性零缓存请求问题仍未解决，我们也未声称通过回放获得任何缓存效率提升。 这些都是经过验证的正确性改进，我们尚未确认它们能够提升Terminal-Bench评分。 这是单一提示框所隐藏的另一部分代理工程问题：提供方输出的内容、代理执行的内容、用户看到的内容，以及下一轮接收到的内容——这四者之间的差异。 ## 为什么Agent Zero是学习这一切的好地方 如果你的目标是学习代理工程，我们认为Agent Zero是最佳起点之一。原因在于你可以直接检查和修改系统。 你可以阅读引导某个决策的提示词，为某个配置文件覆盖它，为框架的每个部分更换插件，检查某个操作及其结果，尝试不同的任务分工，在测试关于模型环境的假设时保持模型本身不变。 同一个框架既可以作为你的日常助手，也可以作为你的实验工作台。 这种访问权限之所以重要，是因为一些直觉上颇具吸引力的想法可能反而会使事情变得更糟。额外的规划步骤可能消耗注意力而不改善执行效果。更短的执行轨迹可能意味着过早停止。更多被召回的材料可能引入无关上下文。一个恢复执行的工具调用可能仍然无法完成用户的请求。 开放的实现让你能够深入调查这些差异，而不必把每一个结果都解释为"模型表现好"或"模型表现差"。 文献研究为实验提供了依据。SWE-agent（https://arxiv.org/abs/2405.15793）研究了智能体-计算机界面的影响；Agentless（https://arxiv.org/abs/2407.01489）探索了一种更简洁的定位与修复工作流程；GEPA（https://arxiv.org/abs/2507.19457）开发了反思性提示优化方法。它们提供了有价值的假设和方法。但它们的结果仍需在你自己的环境中加以验证。 ## 从一个你能观察到的行为入手 选取一个你的智能体反复令你失望的任务。保存指令、初始文件、模型配置和运行轨迹。 定位失败原因。它是误解了需求？读取了错误的内容？使用了不支持的操作？丢失了状态？还是在完成之前就停止了？ 修改运行框架中的某一个相关部分。从相同的起点重新运行。在为减少了令牌数量而庆祝之前，先检查任务是否成功。如果有所改善，重复对比测试，并确保原本可以成功的案例仍然有效。 你不需要构建一个新框架才能开始。你需要的是访问你正在使用的那个框架。 打开运行框架。做一处修改。看看它实际上做了什么。 探索 Agent Zero · 阅读源码 · 探索 Revolve（https://agent-zero.ai/）（https://github.com/agent0ai/agent-zero）（https://github.com/agent0ai/revolve）
