Agent 可靠运行的关键是验证与停止

Agent 能不能把事办成，关键不只是模型会不会推理，还在于它何时继续、何时改计划、何时停止。作者把 Agent 拆成「推理、行动、观察、重复」的循环，认为决定这套循环是否有用的，是停止规则。

对准备给 AI 接工具、让它连续执行任务的程序员，这篇短文提供了一个实用视角：别只看回答是否流畅，要看每一步能否验证、失败后如何修正，以及错误会被限制在什么范围内。

Agent 的区别，是行动之后还要看结果

聊天机器人回答完就结束。Agent 则接收目标、拆分步骤，通过工具执行操作，再根据实际结果调整计划。工具让它能影响外部环境，反馈让它有机会纠正判断。

同一个模型在一次运行里承担三项工作：理解目标、决定下一步、生成文本或工具调用。这三项能力不能混为一谈。回答写得漂亮，并不能证明下一步选得正确。

作者给出的评判标准是「可验证」：检索出符合预算的三个最便宜选项，可以核对价格、预算和数量；找到最佳选项，如果没有事先定义「最佳」，就很难判断是否完成。

目标越模糊，Agent 就越容易用一段好听的解释代替交付结果。

因此，停止规则不能只依赖模型宣布「任务完成」。它需要对应可检查的结果，也需要明确哪些情况必须结束执行。

为什么观察比继续推理更重要

思维链（Chain-of-thought）可以把推理展开，但展开不等于正确。早期判断一旦出错，后续步骤可能都建立在错误前提上。

ReAct 将推理与行动交替进行：先判断下一步，再调用工具，读取观察结果，然后重新推理。它的价值是让环境反馈有机会打断模型已有的判断。

原文引用的数据是：在 ALFWorld 上，ReAct 达到 71%，只行动而不推理的方式为 45%。不过，这篇短文没有交代评测配置、模型或指标细节，也没有展示作者自己的复现实验。这个数字支持文中的特定比较，不能直接当成任何业务接入 ReAct 后的收益预期。

真正考验 Agent 的，是计划出错之后。工具报错、搜索无结果、观察推翻假设，都应该触发重新规划。作者主张只修正被证伪的部分，避免每次从头开始。

这里有两种失败：一种是不停重试同一个无效步骤；另一种是悄悄降低成功标准，把已经做出的结果包装成完成。后者更难发现，因为最终回答可能十分自信。

护栏要管住循环，也要限制错误成本

作者列出四类常见故障：编造工具参数、没有终止条件的无限循环、中间推理过长导致目标漂移，以及错误逐步累积。

对应的措施并不神秘：

• 用严格的工具 schema 约束参数，减少不符合接口要求的调用。
• 设置步骤上限，并检查任务是否取得进展。
• 默认使用只读操作，限制错误造成的影响。
• 在出错代价高的操作前设置人工确认。

这些措施解决的问题不同。schema 能检查参数结构，却未必能判断参数是否符合任务意图；步骤上限能终止消耗，却不能证明任务已经成功。实现时需要分别处理「完成」「失败」「达到上限」，不能统一返回一句「已处理」。

护栏的作用，是让错误更便宜、更容易被发现。

我的判断

我认同作者把注意力从模型表达能力转向执行过程。对工程团队来说，工具返回了什么、结果是否满足目标，比模型解释得多有条理更有判断价值。

但「这些问题都不能靠更聪明的模型解决」说得过于绝对。模型能力可能影响参数选择和规划质量，只是它不能替代执行层的约束。更合理的取舍，是同时改善模型选择与系统控制。

原文也没有提供不同停止规则、步骤上限或进展检查策略的对照数据。除 ALFWorld 的引用外，其余主要是设计主张，不能当成作者已经验证过的通用方案。

如果任务流程固定，普通工作流也可以调用工具、校验结果、按规则重试。只有下一步确实依赖环境变化时，才更有理由让模型持续参与规划。原文没有比较两者的成本，这部分需要团队自行验证。

能拿来做什么

• 给日常 AI 编程任务写清验收条件，例如指定需要修复的行为和必须通过的现有检查，让完成判断有据可查。
• 在 Node 工具调用层校验参数，并分别记录调用失败、结果不满足目标和任务完成，给重新规划提供明确反馈。
• 为连续执行设置步骤上限和进展检查；同一步反复失败时，应调整相关计划或结束运行。
• 接入会修改外部状态的工具时，先采用只读默认值，再把出错代价高的操作放到人工确认之后。