Anthropic企业级Agent实践：单Agent优于多子Agent
很多企业在搭建企业级智能体（Agent）时，习惯按照业务部门或功能模块拆分出大量“专家子Agent”，动辄十几个甚至上百个层层嵌套，认为这样的架构才足够清晰。但最近，Anthropic官方团队却给这股“多Agent热潮”泼了冷水，甚至提出了“劝退”建议。
该团队在调研多个企业级Agent部署案例后发现，配备Skills（技能）的“单Agent”，在输出质量上往往优于复杂的多Agent架构，同时单任务的成本和延迟也更低。
文章还给出了具体的架构优化思路——可以根据“上下文独立性”决定子Agent的去留，将提示词和API转化为Skills与工具，把合适的子Agent逐步并入主循环，最后通过端到端评测确保迁移后的稳定性。
多Agent架构为何从“清晰”变“累赘”？
很多企业的Agent设计，其实是照搬了公司的组织架构，也就是康威定律的体现。此前常见的设计路径是层层叠加：先加入意图分类器，再接固定的多步推理流程，按用户分群设置不同路径，分出独立的推荐分支，最后在顶层加一个多Agent编排器。比如某公司的客服Agent内部塞了12个专家子Agent，不仅导致品牌调性难以统一，还大幅增加了延迟，损害了用户体验。这类设计的问题在于，绝大部分架构都在替模型做“不再必要”的工作——如今，一个清晰的系统提示词、4至5个轻量数据工具和严格的输出限制，就能覆盖大部分用例。
当然，子Agent并非毫无价值，只有满足以下任一条件时，才建议保留：
- 上下文膨胀导致性能下降：单个Agent循环因上下文过长，出现可测量的性能衰退。
- 高并发且上下文独立：多个任务需要并行处理，每个任务只需要一个用完即弃的全新上下文窗口。
- 工具过载或指令冲突：单个Agent难以在海量工具中做出正确选择，或系统提示词中的指令开始相互冲突。
如果不满足这些条件，盲目推行多Agent架构，往往会陷入五大常见失败模式：
- 上下文丢失：Agent之间交换的信息细节在来回传递中丢失。
- 子Agent泛滥：每个团队都交付自己的子Agent，衍生出上百个重叠的子Agent，无统一标准和负责人。
- 拼接提示词冲突：各团队在系统提示词里添加内容，规则相互冲突，整体口吻割裂。
- 评测局部化：各团队只优化子任务，完整评测集无人维护，无法反映端到端表现。
- 高昂的延迟：多Agent跳转耗时，实测单Agent循环速度约为多Agent的2倍。
解法：用渐进式披露简化架构
对于跨团队协作，与其用“编排器+子Agent”的模式，更有效的做法是回归单Agent，并采用“渐进式披露”机制——通过Skills和工具搜索按需加载上下文与工具，Agent一开始只看到简短描述，需要时才加载完整内容。这种做法的核心优势有三点：
- 共享上下文带来更优质的回答：Agent可以关联此前每一步的结果，产出更深入的见解，减少信息交接的损耗。
- 渐进式披露防止上下文膨胀：让一个Agent处理多种任务，无须把所有上下文一次性塞进冗长的系统提示词，消除拆分多Agent的主要原因。
- 模型能力提升让单Agent更可行：最新版本的模型在单个循环中能处理远超预期的工作，还能在工作过程中自我检查，减少对额外机制的依赖，更简单的循环也更容易迁移到下一代模型。
理想的单循环设计
相关团队建议的理想单循环设计，核心是让模型主导整个流程：由一个模型和一个上下文窗口运行开放式工具循环，调度层负责设置轮次与成本预算、写操作限制等约束。每轮，模型发出一批工具调用，调度层并行执行这些调用，把原始结果返回给同一个模型，模型再决定下一步是继续调用工具、向用户提问还是给出答案。
模型在第一轮就把计划写入上下文，并随着结果返回不断修订，写计划和执行计划的是同一个模型，因此可以在执行中途修改计划。这种设计与传统“编排器+专家Agent”的核心区别在于，计划的制定和执行都由同一个模型完成，不需要代码根据规则清单改写计划，执行顺序和领域流程会被整合到Skills中，硬性限制和对话中途的需求会被移入工具，代码仅用于加载成本低且始终相关的内容，以及处理机械性工作。
实战：分四步将子Agent并入主循环
如果已经在生产环境中运行着“编排器+专家子Agent”，可以分四个阶段平稳迁移到单Agent循环：
第一步：建立评测集判断子Agent去留
中央团队负责一套共享的端到端评测集，各团队随自己负责的Skills提供较小的评测集，哪怕只有10个黄金样例也足够起步。通过评分标准追踪回答质量，保留编排器时需追踪路由准确率，子Agent并回后则检查Agent是否加载了正确的Skills或调用了正确的工具，逐步转向任务完成评测。
第二步：合并紧密耦合的领域Agent
第一次合并前，先建立小型端到端评测集，按共享上下文确定并回对象，先处理使用最频繁的子Agent。合并那些输出彼此串联、访问同一份数据或经常被一起调用的专家Agent，比如生产流量中经常连续调用的两个Agent就可以合并。
第三步：过渡期将保留的子Agent降级为“工具”
如果符合保留子Agent的条件，可让主Agent把它作为工具调用，只有当子Agent需要直接与用户交谈时，才完整交接让它接管对话。这样无需重写子Agent，就能先得到任务完成评测的基线，但仍存在每个专家Agent有独立提示词、返回有损摘要、嵌套循环增加延迟等问题。
第四步：彻底拆解子Agent为Skills和工具
每次只处理一个子Agent，把它的提示词转成Skills，把API调用转成工具，彻底并入主Agent。分别评测保留子Agent和并回后的表现，比较时不仅看最终分数，还要看任务结果的翻转情况。每次改动前确保评测集覆盖所有Agent调用链和规则，每个任务至少运行两次。
组织协同：多团队共建单Agent的规范
当子Agent被拆解后，各业务团队的交付物从“独立Agent”变成了“知识库、Skills和工具”，统一交由小型中央团队审核上线，三类资产的维护规范如下：
工具：负责执行操作与数据交互
适合Agent需要执行操作、读取实时数据或返回固定结构的场景。建议按用户意图给工具分组，不要每个API都配一个工具，使用工具搜索并延迟加载工具，尽量减少硬性前置条件，用户级权限也可通过工具处理，让同一个循环服务不同权限的用户。
Skills：承载业务规则与步骤
适合承载业务步骤、规则和判断方法，即原专家Agent的提示词。中央团队可以用Skills来构建、测试和精简其他Skills，避免Skills无序扩张，每个团队的直接负责人管理各自的Skills，确保设计得当、有明确区分并附带评测，还可使用辅助工具维护Skills库。
知识库：存放静态参考资料
适合存放Agent只偶尔需要的参考资料，如政策、指标定义、产品规格等。可放在搜索或查询工具后面，由模型按需调用，尽量避免用代码检索后粘贴到提示词中。
写在最后
随着模型不断演进，对最佳实践的认知也会持续刷新，比起执着于某一种具体架构，背后的工程原则更重要：建立测量基线，每次只改一个变量，只保留经得起评测验证的方案。面对多Agent架构的简化，完全不必一步到位，可以先建一套包含10个样例的小型端到端评测集，挑一个最常用的子Agent尝试并回主循环，只有当并回版本的得分确实更低时才保留它，否则就用Skills和工具取代它，然后不断重复这一过程。
