Anthropic 建议单智能体优于多子代理

Anthropic 发现，在质量、成本和延迟方面，具备按需上下文能力的单一智能体往往优于多智能体架构。该公司正在发布一套迁移工具包，帮助团队进行评估并完成切换。

Anthropic 建议企业评估是否可以整合子智能体，因为能够按需加载上下文的单一主智能体通常比由多个专用智能体组成的集群能提供更优的结果。从 Opus 4.5 开始的新模型，以及 Opus 5.5 和 Fable 5.1，可以直接在单个循环中管理复杂计划，这也有助于降低成本和等待时间。在一项对比测试中，Anthropic 表示单智能体架构的运行速度约为多智能体设置的两倍。

这一建议源于 Anthropic 应用 AI 团队在多个企业级部署中的实践经验。他们发现，使用所谓“技能”（skills）的单一智能体在质量上经常胜过单体提示词设计和子智能体设置。例如，某家公司在其面向客户的智能体内部署了十几个专用子智能体，这使得保持统一的品牌体验变得困难，并且高延迟也损害了可用性。

在多智能体工作流中，上下文会在功能编写、测试编写和代码审查之间的每次交接时丢失。而在单智能体工作流中，由于已经拥有完整上下文，一个智能体可以同时编写功能和测试，而另一个独立的验证器仅负责运行测试并报告结果。| 图片：Anthropic

模型现在可以自行完成大部分编排工作

据 Anthropic 介绍，许多智能体设计遵循一种熟悉的模式：意图检测、固定处理流程、用户细分、独立的推荐分支，以及位于顶层的编排器。对于相应的用例而言，其中大部分工作现在可以由模型自行处理。

Anthropic 将这种现象称为智能体的“康威定律”。架构变成了组织结构的翻版，每个团队都发布自己的子智能体，导致数百个重叠的智能体堆积如山，且缺乏统一标准。随之而来的是 Anthropic 所称的“弗兰肯斯坦式提示词”（Frankenprompt），即每个团队都在系统提示词中添加规则，最终导致这些规则相互矛盾。该公司指出，一个简洁的系统提示词、四到五个精简的数据工具以及固定的输出护栏，就能覆盖大部分相应的用例。

视频 5 例如，Anthropic 将 Claude Code 针对新模型的提示词缩减了超过 80%，部分原因是技能和工具现在仅在需要时才加载。较新的模型还会自行评论进度并检查工作成果，这使得某些额外的控制层变得不再必要。

Anthropic 表示，在以下情况下，子智能体仍然有意义：当单个智能体的上下文窗口出现可测量的性能下降时；当多个任务需要在独立的上下文窗口中并行运行时；或者当单个智能体在工具选择上遇到困难时。

视频 6 为了进行逐步迁移，Anthropic 在 GitHub 上发布了一个 迁移套件，指导团队通过工作流程来识别现有模式、评估替代方案并验证最佳方法。Anthropic 警告不要盲目合并，因为在一项支持智能体的测试中，整合子智能体虽然降低了延迟，但破坏了一个原本正常运行的流程。主智能体开始自行回答，而不是咨询正确的专家。

团队应避免技能库无序扩张

Anthropic 建议不要为每个团队配备独立的 agent，而是将工作流打包成 skills，并通过 tool search 按需加载工具。应由一个小型中央团队负责维护系统提示词（system prompt）和整体质量。此外，Anthropic 指出，当工具定义数量超过 30 到 50 个时，模型的工具选择能力往往会下降，因此各团队应指定专人负责维护 skill 库，防止其无序膨胀。

对于指南、产品规格或指标定义等参考资料，Anthropic 推荐使用知识库，agent 仅在需要时通过搜索工具进行查询。这类信息也可以作为参考文件嵌入到 skill 中。Anthropic 建议避免通过代码获取上下文并直接注入到提示词中。

Anthropic 的发现与近期研究结果一致。Vals 的一项研究发现，agent 团队可能比单个 agent 速度更快，但并未带来更高的质量。该研究指出，将 agent 数量从 10 个扩展到 30 个甚至 100 个，并没有提升质量，反而导致成本显著增加。OpenAI 开发者 Eric Provencher 也质疑了 agent swarm（智能体集群）的价值，称其为“几乎肯定”是浪费金钱。