让 agent 有野心地干活之前，先给它一份真人签过名的 truth source

这是「探索 agent 的未来模式」系列的一篇。我也在思考研发助手怎么变成一支能自己扩编的 bot 舰队：《我想让研发 agent 长成一支能自己扩编的舰队》。

大模型要用得有野心

最近我读到 Anthropic 的 Felix Rieseberg 在 10 月 13 日发的 How to be more ambitious: A tutorial for humans with models，这篇文章传得很广。他的观点是：我们用 AI 要更有野心，不能只拿 Claude 这类大模型干小活。

这个观点直接影响我怎么设计我们的研发助手和企业里的 AI 员工，也就是产品里的 agent 到底该接多大的活。

他把野心分成四种，我按自己的理解概括一下：

• 速度：同样的工作用更少的时间做完。他认为这一种已经很成熟，所以文章没有展开。
• 高度：交给模型的不是单个任务，而是你真正想要的结果。他举的例子是，他以前让 Claude 一个个修崩溃，后来直接让 Claude 保证应用不崩溃。为了做到这一点，他先让 Claude 能拉到崩溃报告、能把版本对上 git commit，还能用 Windows、macOS 和 Linux 机器自己复现并验证修复。
• 深度：让模型像领域里最顶尖的专家那样做事。他建议坚持让模型用专家真正用的工具，比如用数据库和统计模型，而不是写一张 Markdown 表格；他也建议定一个看似不合理的目标，比如网页加载时间要从 10 秒降到 200 毫秒，而不是降到 5 秒，并告诉模型这完全做得到。他还建议把原始数据交给模型，让它对抗性地检验团队已有的假设，再去找大家还不知道的新结论。最后，他强调不要让模型给自己打分，而要找外部裁判来验证，最好是模型能直接运行、立刻拿到反馈的工具。
• 广度：调动任务表面上用不到的其他领域的知识、工具和方法，从不同专业的视角看同一件事。他提到，多 agent 系统越来越容易跑起来，只要请 Claude 引入更多领域，结果常常很有意思。

他还给了一段可以直接接在提示词后面的话，开头是「我想要这个任务更深，而不是更大」。这段话让模型先回答四个问题：这个领域的顶尖专家会额外做什么，他们会从哪些最原始的材料入手，他们会用哪些具体的方法和工具，以及除了模型和我之外，还有什么能证明结果是对的；然后，模型再按这些答案重写提示词。他也提醒，上面这些做法都要求模型有一台能装软件的电脑，并且能通过 MCP 连接器等方式拿到相关数据。

这篇文章让我开始反思，自己是不是把大模型用得太保守了。其中「找外部裁判」这一条，正好对应我下面想说的 truth source。我理解的「有野心」，是把一项有明确目标和验收条件的工作交给 agent，让它自己拆任务、查资料、实现并验证，而不只是让它补一小段代码。但是，我仍然要说明它能改什么、遇到什么情况必须停下来问我，不能把任务变大理解成授权没有边界。

借 agent automation 的做法

我还读到一篇 agent automation 的文章，感觉可以拿来把企业里的 AI 员工和我们的研发助手结合起来用。企业里的 AI 员工和我们的研发助手做的都是「让 agent 自己干活」，所以可以借现成的做法。

更重要的是，我想看看他们是怎么做 code review 的。

对于读到的 agent automation 做法，我想先借它的工作组织方式，而不是照搬某个实现。我希望 agent 执行任务时留下改动理由和验证结果，再让 code review 对照原始需求、实际 diff 和测试证据检查，而不只是接受执行者的口头汇报。对于涉及已确认行为的改动，我希望审查能指出它碰到了哪条基准，并把需要人决定的分歧单独交出来。

放手之前，先定一份 truth source

这是我在开发过程中冒出来的想法：自动化测试需要有一个 truth source，定义哪些是验证过的、真人签过名的、在迭代中不该轻易变化的。

我在意这个，是因为 agent 改代码时，不能顺手把已经确认过的行为也改掉。换句话说，agent 越有野心，越需要一份它不能随手动的基准。

团队也可以共享这份 truth source，大家都按同一份基准来。

我倾向于把这份基准放进版本管理：每项约定都写清用户可观察的行为、适用范围和验收例子，并关联相应测试。我说的真人签名，是由负责需求或验收的人明确确认这个版本，而不是让 agent 替人点头。团队成员可以共享同一份记录，agent 也从这个版本读取约束；如果需求确实变了，负责人就通过一次可追溯的审查更新基准，而不是让执行中的 agent 顺手改掉它。

两件事要放在一起

我想一边放手，让大模型有野心地干大活，用 agent automation 让企业里的 AI 员工和我们的研发助手自己跑起来；与此同时，我也要用真人签过名的 truth source 和 code review 守住边界。

我的判断是，truth source 负责说明哪些行为必须守住，code review 则负责检查这次改动有没有越过边界；两者不能互相替代。Agent 可以在约定范围内自己拆解、尝试和验证，但是，当它发现目标与基准冲突时，它应该把冲突和修改建议交给人确认，而不是一边改代码一边重写验收标准。我也不希望基准把旧需求永久冻结；团队可以修改它，只是这次修改必须有明确的理由和真人确认。这样，我才敢把更完整的工作交出去，而不是每次都靠缩小任务来降低风险。

我设想的研发助手 bot 舰队，就是需要这道护栏的场景。