Anthropic 改口：一个 agent 可能比一群子代理更好用

两年前建 agent 的标准答案是多招募几个「专科医生」，现在的风向变了：Anthropic 亲手劝大家做减法。

一、发生了什么

10 月 25 日报道，Anthropic 建议企业评估能否把手头的子代理合并成一个主 agent，按需加载上下文。理由来自其应用团队的多个企业项目：从 Opus 4.5 起的新模型，包括后续版本，已经能在一个循环里直接处理复杂计划。有个做客服的客户，对话 agent 里塞了十几个子代理，结果品牌口吻前后不一、响应慢得没法用。换成单 agent 后，对照测试里跑得比原来快约一倍。该公司把这类经验总结成一套迁移指南，放上了 GitHub。他们还给这种病起了个名字：agent 版的康威定律——架构照抄了组织结构图，每个团队都给自己造个 agent，堆到几百个互相重叠，系统提示词里塞满互相打架的规则。

二、跟你有什么关系

如果你在维护一套多代理系统，先别急着推翻，但值得花一个下午做个对照实验：挑一条高频流程，分别用单 agent 和现有架构跑同批任务，比质量、比延迟、比账单。如果你是采购方，供应商拿「多智能体协作」当卖点时，可以追问一句：为什么不单 agent？答不上来的大概率是在给组织结构而非业务需求付费。如果你是开发者，这条建议的潜台词是模型变强了，你写的那层编排代码可能正在拖后腿——Anthropic 举例说，他们把代码助手的系统提示词砍掉八成以上，效果反而更好，因为技能和工具改成用的时候才加载。

三、怎么判断

1. 先看上下文：如果单个 agent 的窗口没有出现可测的性能滑坡，合并就有戏。Anthropic 明确说，出现明显退化、需要并行隔离、或者工具选择混乱时，子代理仍然合理。
2. 再看交接损耗：多代理方案里，写功能、写测试、审代码每过一道手，上下文就丢一层。单 agent 自己全包，另设一个独立校验者只负责跑测试并回报结果，分工反而更干净。
3. 合并别一刀切：他们自己试过把客服 agent 的子代理直接折进去，延迟降了，但主 agent 开始自作主张抢答，不再去问该问的专家，一条本来正常的流程就坏了。
4. 工具库要设管理员：模型面对三五十个以上工具定义时选择能力会下降，技能库得有人定期修剪。

四、三个别信的说法

「子代理彻底过时了。」 这是厂商基于自家模型和场景的经验之谈，不是普适定律。长任务并行、上下文隔离这类场景，多代理依然是对的工具。

「合并只有好处。」 Anthropic 自己的翻车案例说明，盲目合并会破坏经过验证的流程。省下的是延迟，赔进去的可能是正确性。

「堆越多 agent 越聪明。」 有第三方研究测过：从 10 个 agent 扩到 30 个甚至 100 个，质量没有提升，成本显著上涨。多智能体的热闹，很多时候是 token 在烧。

五、一句话结论

模型能自己扛复杂度了，你的架构图该跟着组织架构一起瘦身。

信息来源

• The Decoder 关于 Anthropic 单 agent 建议的报道，2026 年 10 月 25 日

功能与价格以官方公告为准。本文写于 2026 年 10 月 26 日。