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

原创于 2026-06-29 11:34:27 发布 · 404 阅读

4 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#AI #自动化

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 时最容易被忽视的安全隐患。