Anthropic 300个Agent闭环才是被忽视的真正护城河

Agent 闭环才是真正的护城河：Anthropic "300 个 Agent" 背后被忽视的秘密

最近，Anthropic内部的消息刷了屏——99%的工程师在跑300个以上会自我改进的agent。很多人盯着“300”这个数字激动不已，但真正值得咀嚼的，是每个agent身上那个能自己验证自己、自己纠正自己的闭环回路。数字背后的工程逻辑，才是决定成败的关键。

一、核心观点

拉起300个agent？门槛低得很，便宜模型加个并发脚本就能搞定。可如果每个agent都是“开环”的，结果不是产能翻300倍，而是垃圾翻300倍。真正难的，是让这群agent干出来的活靠谱。

二、关键信息

2.1 开环 vs 闭环

2.2 闭环的标准工作姿势

规划（想清楚要干什么、规范是什么）
↓
执行（按计划动手）
↓
验证（调用工具检查自己的输出）
↓
调整计划（根据验证结果修正）
↓
再循环……直到自己满意，才交出来

2.3 让闭环成为可能的三项模型能力提升

2.4 数据佐证

• SWE-bench Verified 编码评测：Claude 一年前 62%，Opus 4.8 已达 88%，失败率压到原来的 1/3。
• Anthropic 内部超过 80% 的代码，如今由 Claude 自己合并。

2.5 两个实操建议

1. 精简 Scaffolding（外层提示 & 工具）

   • 旧模型时代打的「补丁」，对新模型反而是枷锁。
   • 一行过时的格式指令，新模型太听话照做，功能"看着坏了"，删掉就好。
   • ✅ 别围着旧模型的毛病写提示，要围着你真正想要的结果写。

2. 给模型留出干活的空间

   • 让它自己决定思考多久、用多大劲。
   • 在受控前提下，把更多动手的权限交给它。
   • ✅ 你把每一步都焊死，agent 就没有空间自己验证和纠正。

2.6 闭环的真实代价

三、代码 / 示例

文中无具体代码，但给出了一个概念性工具配置示例：

场景：让 agent 写前端应用

❌ 开环做法：agent 写完代码 → 直接输出 → 等人审查

✅ 闭环做法：agent 写完代码
→ 调用「操作电脑工具」打开浏览器
→ 自动点击页面交互
→ 观察页面是否正常渲染
→ 发现问题 → 回到代码修改
→ 重复，直到页面跑通
→ 输出已自验证的成品

核心配置原则：给 agent 的工具集中，必须包含能检验自身输出正确性的工具，而不只是执行工具。

四、个人启发

1. "数量崇拜"是一种认知陷阱。 技术圈习惯被大数字震撼，但真正的壁垒往往藏在不性感的工程细节里——比如"怎么设计反馈回流"，这种东西写不进课程标题，但才是决定成败的地方。

2. "什么叫干对了"比"怎么干"更重要。 闭环的前提是你得先想清楚验证标准：对于你的任务，什么状态算"通过"？这个问题不想清楚，给 agent 再多工具也是白搭。

3. 放手是能力，不是懈怠。 很多人控制欲太强，把每一步都焊死在提示词里，结果 agent 没有纠错空间。真正信任一个系统，是给它设定好目标和验证标准，然后让它自己爬向正确答案。

4. Token 是成本，翻车才是风险。 两者不对等——token 账单可预测、可控制，生产事故的代价往往无法估量。重新定义"贵"，才能做出正确的架构决策。

五、延伸思考

1. 验证工具的设计本身，是不是一门独立的学问？
   不同任务（写代码、生成文案、数据分析）需要完全不同的自检工具。如何系统地为各类 agent 设计可靠的验证层，目前似乎还缺乏成熟的方法论。这会成为下一个被重点研究的方向吗？

2. 闭环的「收敛条件」如何防止无限循环？
   agent 自我验证、自我纠错，理论上可以一直转下去。现实中如何设置合理的终止条件（最大迭代次数、置信阈值、人工介入触发点），在保证质量的同时控制成本，是个值得深究的工程问题。

3. 当 agent 的"验证工具"本身出错时，谁来验证验证者？
   如果验证层本身有盲区或偏差（比如测试用例写错了），agent 可能在错误的轨道上越跑越远、越来越"自信"。如何构建多层次、互相独立的验证机制，避免「自我欺骗式闭环」，可能是规模化部署 agent 时最容易被忽视的安全隐患。