关键要点
- Anthropic 建议企业评估是否能够将子代理整合为单个代理，从而按需加载上下文。
- 该公司的经验表明，许多专业子代理会导致更高的延迟、更高的成本以及每次数据传递时的信息丢失。
- Anthropic 在 GitHub 上发布了一个迁移工具包，以帮助团队完成过渡。
Anthropic 发现，单个代理配合按需上下文功能，在质量、成本与延迟方面往往优于多代理架构。该公司正在发布迁移工具包，以帮助团队进行评估并实施切换。
Anthropic建议各公司评估是否可以将子代理整合在一起，因为单个主代理根据需求加载上下文的方式，往往比多个专业代理更能取得更好的效果。从Opus 4.5开始的新模型，以及Opus 5.5和Fable 5.1，能够直接在单一循环中管理复杂的计划，这也能降低成本和等待时间。据Anthropic称，在一项对比中，单代理架构的运行速度约为多代理设置的两倍。
该建议来自在多个企业部署中的实际经验。Anthropic 的应用人工智能团队发现，单个智能体使用所谓的技能，在质量方面常常优于整体提示设计以及子智能体设置。例如，某公司在其面向客户的智能体中拥有十几个专业子智能体，这导致难以保持一致的品牌体验，且高延迟还会影响易用性。
该模型现在可以自行完成大部分调度工作
根据 Anthropic 的说法，许多智能体设计都遵循一种熟悉的模式：包括意图检测、固定的处理流程、用户细分、独立的推荐分支，以及位于顶层的协调器。其中大部分工作现在可由模型独自完成，以应对相应的应用场景。
Anthropic将其称为“Conway’s Law”用于代理机制。架构变成了组织图式的复制品，每个团队都推出自己的子代理，最终形成数百个相互重叠的代理，且没有统一的标准。Anthropic称之为“Frankenprompt”，即每个团队向系统提示语添加规则，而这些规则最终会相互矛盾。据该公司称，一个简洁的系统提示语、四到五种高效的数据工具以及固定的输出约束规则，就能解决大部分相关使用场景。
例如，Anthropic 将 Claude Code 系统提示词在新模型中的占比减少了 80% 以上，部分原因是技能和工具现在仅在需要时加载。新模型还会对自己的进展进行评论并检查自己的工作，这使得一些额外的控制层变得不再必要。
Anthropic 表示，当单个智能体的上下文窗口出现可测量的性能下降时，当多个任务需要以独立的上下文窗口并行运行时，或者当单个智能体在工具选择方面存在困难时，子智能体仍然具有意义。
对于逐步迁移过程，Anthropic 在 GitHub 上发布了一个 迁移工具包，帮助团队按照流程识别现有模式、评估替代方案，并确认最佳方法。Anthropic 警告说不要盲目合并，因为在一个支持代理测试中，将子代理纳入其中虽然降低了延迟，但破坏了之前正常运作的流程。主代理开始自行回答问题，而不是咨询合适的专家。
团队应避免技能库过于庞大
与其给每个团队分配独立的代理，Anthropic 建议将工作流程封装为 技能，并通过 工具搜索 按需加载工具。一个小型中央团队应负责系统提示和整体质量。此外，Anthropic 指出，当模型使用的工具数量超过 30 到 50 种时，其性能会下降，因此每个团队的指定负责人应维护这些技能库，以防止数量过度增加。
对于指南、产品规格或度量单位定义等参考材料，Anthropic 建议使用搜索工具在需要时才向知识库查询。此类信息也可以作为参考文件嵌入到技能中。 建议避免 通过代码获取上下文，并直接将其注入到提示中。
Anthropic的研究结果与最新研究一致。Vals的一项研究表明，代理团队可能比单个代理更快，但质量却不会更高。根据该研究，从10个代理扩展到30或100个代理并不会带来质量提升，反而会显著增加成本。OpenAI开发者Eric Provencher也质疑了代理群的价值，称它们“几乎可以肯定”是浪费资金。
来源：Anthropic