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