Agent

先问谁决定下一步#

本文采用一个便于工程判断的区分：代码规定主要控制路径的是 Workflow；模型根据中间结果持续选择行动的是 Agent。这个区分来自 Anthropic 的工程文章，但并不是业界统一的命名标准。1

因此，不要先数用了几个模型、多少工具、有没有聊天界面。先看一次运行中“接下来做什么”由谁决定。

一次有反馈的任务循环#

教学情境：排查测试失败。 系统先读取失败信息，决定查看哪个文件，提出修改，再运行测试。新失败可能改变下一步行动；测试通过后还需要检查是否满足原始需求。

可以把过程记成“观察 → 选择动作 → 应用执行 → 检查结果 → 继续或退出”。ReAct 论文研究了推理与行动交替组织的方式，说明从环境获得反馈的重要性。2 这不要求产品展示模型的内部推理；用户需要的是可核查的操作记录、结果和依据。

给自主决策划定范围#

本站建议先写一份任务契约，再接入循环：

教学示意：修复一个测试失败
目标：目标测试通过，相关检查没有回归
可用动作：读取工作区文件、提出修改、执行允许的测试
预算：由应用配置最大步骤数、耗时和调用费用
停止：通过验收 / 预算耗尽 / 重复失败 / 需要额外权限
交付：修改摘要、测试结果和仍未验证的部分

“任务完成”不应只取决于模型说完成了。对能用程序验证的结果，让程序验证；对必须由人判断的要求，明确交回检查。

怎样判断是否值得引入#

先尝试 Workflow 或更简单的方案，再用相同任务比较。需要记录的不是只有成功率，还包括执行次数、耗时、人工介入和失败后的恢复成本。自主性带来的灵活性可能伴随更高成本与延迟。1

如果每次路径都相同，模型的持续规划可能没有带来足够收益。如果任务会因工具结果改变方向，并且结果可检查、权限可控制，才值得进一步测试。

长任务失败时看什么#

• 反复做同一件事： 是否保存了已尝试动作和失败原因？有没有重复失败的停止条件？
• 目标逐渐偏离： 查看当前上下文是否仍保留原始目标与限制，继续读 上下文工程。
• 请求了不该做的动作： 应用是否真正限制工具和权限，还是只靠提示中的承诺？
• 报告成功但结果不对： 评测是否检查了最终环境状态，而只检查了回复文案？

这些是排查方向，不是自动安全保证。增加一个“自我反思”步骤，也不能替代外部验证。