Anthropic 称单智能体快 2 倍:多子智能体系统提示词砍 80%

Anthropic 在 10 月 25 日给企业客户的建议很直接:评估一下能不能把手里那些子智能体合并掉。一个按需加载上下文的主智能体,在质量、成本和延迟三项上都常常胜过一群专职子智能体。公司给出的对比数字是单智能体架构的运行速度约为多智能体方案的两倍,并同步放出了迁移套件。

多智能体架构的三个典型症状

Anthropic 把常见的坏模式总结成一条组织结构映射链。系统按意图识别、固定处理流水线、用户分群、推荐分支分层,最后加一个编排器收口,这套结构在过去是合理分工,如今模型已能单独处理大部分环节。由此衍生的症状被称作智能体领域的 Conway 定律:架构变成组织架构图的复制品,最后堆积出几百个功能重叠、彼此没有共享规范的智能体。再往下就是 Frankenprompt,各团队都往系统提示词里塞规则,最终互相矛盾。

砍掉 80% 系统提示词之后

Anthropic 给出的替代路径是:干净的单一系统提示词,四五个精简的数据工具,加上固定的输出护栏,就足以覆盖对应的使用场景。以 Claude Code 为例,针对新模型他们把系统提示词砍掉了超过 80%,部分原因是技能和工具现在可以按需加载。新模型还会自己汇报进度、复核工作结果,一部分额外控制层因此不再必要。

这套思路在工程实现上的具体路径此前有过讨论,Anthropic 用 Claude 自建新代码系统替换 Git 那篇深度文提到的自举式工程实践指向同一个方向:把重复的流程规则从静态配置,收进模型可以自己调用的技能里。

什么情况下子智能体依然合理

Anthropic 也划了边界。当单智能体的上下文窗口出现可测量的性能衰减时,当多个任务需要各自独立上下文并行执行时,或者当单个智能体在工具选择上持续出错时,拆分仍然合理。官方同时提醒不要盲目合并,曾有客服智能体把子智能体合并进去后延迟确实降了,但主智能体开始自己回答问题,不再调用对应专家。另外模型在工具定义超过 30 到 50 个之后选择工具的能力会退化,技能库需要专人维护。外部研究也提供了同向证据,规模从 10 个扩到 100 个,质量没有提升,成本却明显上升。