Agent 闭环才是真正的护城河：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 时最容易被忽视的安全隐患。