Anthropic 发现，一个按需加载上下文的单一智能体在质量、成本和延迟方面往往优于多智能体配置。该公司正在发布一套迁移工具包，帮助团队评估并完成切换。
Anthropic 建议企业评估是否可以合并子智能体，因为一个按需加载上下文的单一主智能体往往比一组专用智能体带来更好的结果。从 Opus 4.5 开始的新模型，以及 Opus 5.5 和 Fable 5.1，可以在单个循环中直接管理复杂计划，这也能降低成本并减少等待时间。在一项对比中，Anthropic 表示单智能体架构的运行速度约为多智能体配置的两倍。
这一建议来自在多个企业部署中的实践经验，Anthropic 的应用 AI 团队发现，一个使用所谓技能的单一智能体在质量上经常同时胜过单体式提示设计和子智能体配置。例如，有一家公司在面向客户的智能体中内置了十几个专用子智能体，这使其难以保持一致的品牌体验，并因高延迟而损害了可用性。
该模型现在可以自行完成大部分编排工作
据 Anthropic 称，许多智能体设计都遵循一种熟悉的模式：意图检测、固定的处理流水线、用户分群、独立的推荐分支，以及位于顶层的编排器。其中大部分工作，模型现在可以针对相应的用例自行处理。
Anthropic 称之为智能体领域的“康威定律”。架构变成了组织架构图的复制品，每个团队各自交付自己的子智能体，直到数百个相互重叠的智能体堆积起来，却没有共享标准。随之而来的是 Anthropic 所称的“Frankenprompt”，即每个团队都往系统提示词里添加规则，最终彼此矛盾。据该公司称，一个干净的系统提示词、四五个精简的数据工具，以及固定的输出护栏，就能覆盖相应用例的大部分需求。
举例来说，Anthropic将较新模型的 Claude Code 系统提示词削减了 80% 以上，部分原因是技能和工具现在只在需要时才加载。较新的模型还会自行评论进展并检查自己的工作，这可以让一些额外的控制层变得不再必要。
Anthropic 表示，当单个智能体的上下文窗口出现可测量的性能下降、当多个任务需要在各自独立的上下文窗口中并行运行，或当单个智能体在工具选择上吃力时，子智能体仍然是有意义的。
对于分步迁移，Anthropic 发布了一套迁移工具包，放在 GitHub 上，引导团队走完一套工作流程，以识别现有模式、评估替代方案并验证最佳方法。Anthropic 警告不要盲目合并，因为在一次针对客服智能体的测试中，并入子智能体确实降低了延迟，却破坏了原本正常工作的流程。主智能体开始自行作答，而不是去咨询正确的专家。
团队应避免技能库无序膨胀
Anthropic 不建议让每个团队各自拥有智能体，而是建议将工作流打包成技能，并通过工具搜索按需加载工具。应由一个小型中央团队负责系统提示词和整体质量。另外，Anthropic 指出，当工具定义超过 30 到 50 个时，模型的工具选择往往会退化，因此各团队应指定负责人维护技能库，防止其膨胀。
对于指南、产品规格或指标定义等参考材料，Anthropic 建议使用知识库，让智能体仅在需要时通过搜索工具查询。这类信息也可以作为参考文件嵌入到技能中。Anthropic建议不要通过代码获取上下文并直接注入提示词。
Anthropic 的发现与近期研究一致。一项由 Vals开展的研究发现，智能体团队可能比单个智能体更快，但并不能带来更高质量。根据该研究，从 10 个智能体扩展到 30 个或 100 个智能体并未带来质量提升，但成本显著更高。OpenAI 开发者 Eric Provencher 也质疑智能体集群的价值，称它们“几乎肯定”是在浪费钱。