如何打造会检查自己工作的 AI Agent

深度分析：从“会做”到“能证明做对”

这期真正解决的是什么问题

表面上，这期节目讨论多个 Agent 协作，实际核心是软件团队如何把不稳定的模型输出变成可管理的生产过程。Jared 的出发点不是让模型看起来更自主，而是把“完成任务”的含义改写为一组外部可检查的证据。只要成功标准仍然依赖 Agent 自己说“我完成了”，多 Agent 只是把不确定性并行放大。

因此，节目把提示词的重要性下调，把工具、测试与反馈回路的重要性上调。提示词告诉模型应该怎么想；工具决定它能做什么；验证器决定系统是否接受结果。后两者比自然语言约束更接近传统工程中的接口与测试，也更容易复用、记录和追责。

关键论证链

1. 先观察，再约束：如果一开始就堆满规则，团队无法知道模型原本能完成什么，也无法区分真正必要的护栏与人为想象的风险。
2. 失败必须沉淀：一次失败不应只靠人工修正，而应进入失败分类、回归测试和评测集，成为系统下一版的资产。
3. 经理 Agent 不是万能路由器：它需要掌握任务状态、依赖、预算和验收条件；否则只是增加一次模型调用。
4. 证明工作是默认协议：代码任务提交测试与 diff，研究任务提交来源与冲突证据，运营任务提交状态变化和回滚方法。

容易被误读的地方

“先让模型自由发挥”并不等于在生产环境中取消权限边界。更准确的做法是在隔离沙箱和低风险数据上开放探索，在外部写入、付费、发送消息等动作上保持硬审批。节目中的自由度属于探索策略，不是安全策略。

适用于个人工作流的翻译

个人不需要一次运行十个 Agent。更有效的起点是把一个任务拆成执行者与检查者：执行者产出，检查者只按清单找缺口。只有当两类任务都稳定后，再引入经理 Agent。这样能避免“为了多 Agent 而多 Agent”。