Agent 闭环才是真正的护城河：Anthropic “300 个 Agent“ 背后被忽视的秘密
Agent 闭环才是真正的护城河：Anthropic "300 个 Agent" 背后被忽视的秘密
原文作者：Just Jason｜原文来源：微信公众号
核心一句话：数量不是壁垒，让 agent 自己验证、自己纠错的「闭环回路」才是。
一、核心观点
"Close the loop，闭环。"
Anthropic 内部 99% 的工程师在跑 300 个以上会自我改进的 agent，这个数字被广泛转发。但真正的重点不是"300"这个数量，而是每个 agent 身上那个能自己验证自己、自己纠正自己的回路。
- 拉起 300 个 agent，门槛极低——便宜的模型 + 一个并发脚本即可。
- 若每个 agent 都是「开环」的，结果不是产能翻 300 倍，而是垃圾翻 300 倍。
- 真正难的，是让这群 agent干出来的活靠谱。
二、关键信息
2.1 开环 vs 闭环
| 对比维度 | 开环（Open Loop） | 闭环（Close the Loop） |
|---|---|---|
| 验证者 | 人工审查 | Agent 自己 |
| 逻辑 | 生成一次，赌它对 | 生成 → 自检 → 不对就改 → 反复直到收敛 |
| 本质 | 聊天逻辑 | 工程逻辑 |
| 风险 | 错误流向用户后才发现 | 交付前已自检过一道 |
2.2 闭环的标准工作姿势
规划（想清楚要干什么、规范是什么） ↓ 执行（按计划动手） ↓ 验证（调用工具检查自己的输出） ↓ 调整计划（根据验证结果修正） ↓ 再循环……直到自己满意，才交出来关键在"验证"那一步：不是等人来挑错，而是 agent 自己调用工具去检查输出。
例：一个写应用的 agent，应配备「能操作电脑的工具」，让它写完前端后自己打开页面、自己点几下、自己看跑没跑通，再决定要不要回去改代码。
2.3 让闭环成为可能的三项模型能力提升
| 能力 | 旧模型 | 新模型 |
|---|---|---|
| 行动前规划 | 上来就干，撞墙才回头 | 先想清楚规范再动手，反而调用更少工具 |
| 自我纠错 | "原地打转"，换汤不换药 | 真正读懂反馈，换方法重来 |
| 长时程任务 | 上下文跑偏 | 百万 token 跨度内保持专注，循环可转很多圈 |
2.4 数据佐证
- SWE-bench Verified 编码评测：Claude 一年前 62%，Opus 4.8 已达88%，失败率压到原来的1/3。
- Anthropic 内部超过80% 的代码，如今由 Claude 自己合并。
2.5 两个实操建议
精简 Scaffolding（外层提示 & 工具）
- 旧模型时代打的「补丁」，对新模型反而是枷锁。
- 一行过时的格式指令，新模型太听话照做，功能"看着坏了"，删掉就好。
- ✅别围着旧模型的毛病写提示，要围着你真正想要的结果写。
给模型留出干活的空间
- 让它自己决定思考多久、用多大劲。
- 在受控前提下，把更多动手的权限交给它。
- ✅你把每一步都焊死，agent 就没有空间自己验证和纠正。
2.6 闭环的真实代价
| 维度 | 开环 | 闭环 |
|---|---|---|
| Token 消耗 | 少（只推理一次） | 多（规划/执行/验证/纠错各推理一次，单任务十几到几十次调用） |
| 风险 | 把全部身家押在"第一次就对"上 | 交付前自检，错误提前暴露 |
| 适用场景 | 低风险、一次性生成够用的任务 | 上生产、错不起的任务 |
权衡公式：拿可计量的 token，换不可控的翻车风险。
三、代码 / 示例
文中无具体代码，但给出了一个概念性工具配置示例：
场景：让 agent 写前端应用 ❌ 开环做法： agent 写完代码 → 直接输出 → 等人审查 ✅ 闭环做法： agent 写完代码 → 调用「操作电脑工具」打开浏览器 → 自动点击页面交互 → 观察页面是否正常渲染 → 发现问题 → 回到代码修改 → 重复，直到页面跑通 → 输出已自验证的成品核心配置原则：给 agent 的工具集中，必须包含能检验自身输出正确性的工具，而不只是执行工具。
四、个人启发
"数量崇拜"是一种认知陷阱。技术圈习惯被大数字震撼，但真正的壁垒往往藏在不性感的工程细节里——比如"怎么设计反馈回流"，这种东西写不进课程标题，但才是决定成败的地方。
"什么叫干对了"比"怎么干"更重要。闭环的前提是你得先想清楚验证标准：对于你的任务，什么状态算"通过"？这个问题不想清楚，给 agent 再多工具也是白搭。
放手是能力，不是懈怠。很多人控制欲太强，把每一步都焊死在提示词里，结果 agent 没有纠错空间。真正信任一个系统，是给它设定好目标和验证标准，然后让它自己爬向正确答案。
Token 是成本，翻车才是风险。两者不对等——token 账单可预测、可控制，生产事故的代价往往无法估量。重新定义"贵"，才能做出正确的架构决策。
五、延伸思考
验证工具的设计本身，是不是一门独立的学问？
不同任务（写代码、生成文案、数据分析）需要完全不同的自检工具。如何系统地为各类 agent 设计可靠的验证层，目前似乎还缺乏成熟的方法论。这会成为下一个被重点研究的方向吗？闭环的「收敛条件」如何防止无限循环？
agent 自我验证、自我纠错，理论上可以一直转下去。现实中如何设置合理的终止条件（最大迭代次数、置信阈值、人工介入触发点），在保证质量的同时控制成本，是个值得深究的工程问题。当 agent 的"验证工具"本身出错时，谁来验证验证者？
如果验证层本身有盲区或偏差（比如测试用例写错了），agent 可能在错误的轨道上越跑越远、越来越"自信"。如何构建多层次、互相独立的验证机制，避免「自我欺骗式闭环」，可能是规模化部署 agent 时最容易被忽视的安全隐患。