单一智能体已能胜过多子智能体架构

Anthropic 的应用 AI 团队在多个企业级部署项目中积累了大量实践经验，发现采用「技能」机制的单一智能体，在质量表现上往往超越整体式提示词设计和多子智能体方案。以某客户服务场景为例，该企业在其面向用户的智能体内部嵌套了十余个专用子智能体，导致品牌体验难以保持一致，高延迟也严重影响了可用性。Anthropic 将这一现象类比为软件工程中的「康威定律」——智能体架构最终变成了组织架构图的镜像。

在多智能体工作流中，上下文信息会在功能编写、测试编写和代码审查等环节的每次交接中不断流失。而在单智能体工作流中，同一个智能体因为始终持有完整上下文，可以同时完成功能开发和测试编写，仅由独立的验证器负责运行测试并汇报结果。这种设计不仅减少了信息损耗，也降低了系统整体的协调开销。

Anthropic 指出，许多智能体系统都遵循一种固定模式：意图检测、固定处理流水线、用户分层、独立推荐分支，再加一个顶层编排器。而这些工作，如今的模型大多可以自行处理。随着各团队各自交付子智能体，系统中会逐渐堆积数百个相互重叠、缺乏统一标准的智能体，最终形成 Anthropic 所称的「弗兰肯提示词」——各团队在系统提示词中叠加的规则相互矛盾，维护成本极高。

新一代模型还具备自我进度注释和自我检查能力，使部分额外的控制层变得不再必要。以 Claude Code 为例，Anthropic 已将其针对新模型的系统提示词精简了逾 80%，原因正是技能和工具现在仅在需要时才会加载。不过，Anthropic 也明确指出，当单一智能体的上下文窗口出现可测量的性能下降、多任务需要并行运行且各自需要独立上下文，或者智能体在工具选择上存在困难时，多子智能体架构仍然是合理的选择。

在工具管理方面，Anthropic 建议将工作流封装为技能，并通过工具搜索按需加载，而非为每个团队单独配备一个智能体。研究还发现，模型的工具选择能力在工具定义超过 30 至 50 个后会明显下降，因此各团队应指定专人维护技能库，防止其无序膨胀。对于指南、产品规格或指标定义等参考资料，Anthropic 推荐使用知识库，让智能体通过搜索工具按需查询，而非通过代码抓取后直接注入提示词。

Anthropic 的建议与近期独立研究结论相互印证。Vals 的一项研究发现，智能体团队虽然可能比单一智能体更快，但并不能带来更高的质量；将智能体数量从 10 个扩展到 30 个乃至 100 个，质量没有提升，成本却大幅攀升。OpenAI 开发者 Eric Provencher 也对智能体集群的价值提出质疑，认为这种做法「几乎可以肯定是在浪费金钱」。Anthropic 已在 GitHub 发布迁移工具包，但同时警告不要盲目合并——在一次测试中，将子智能体并入主智能体虽然降低了延迟，却破坏了原本正常运行的流程。

要点

• Anthropic 建议企业评估是否可将多个子智能体整合为单一智能体，新一代模型已具备在单循环中处理复杂任务的能力，实测速度约为多智能体方案的两倍。
• 多智能体架构容易因任务交接导致上下文丢失，并催生相互矛盾的「弗兰肯提示词」，单一智能体配合按需加载的技能机制可有效规避这些问题。
• 模型工具选择能力在工具定义超过 30 至 50 个后会明显下降，Anthropic 建议由专人维护技能库并通过知识库管理参考资料，避免系统提示词无序膨胀。
• 多子智能体架构在上下文窗口性能下降、任务需并行处理或工具选择困难等场景下仍有其价值，迁移前应充分评估而非盲目合并。
• Anthropic 已在 GitHub 发布迁移工具包，独立研究同样表明扩大智能体数量不能提升质量，反而会显著推高成本。