Anthropic内部测试高出90.2%，多智能体一定更强？

一个智能体加两个工具就能跑通的任务，硬拆成三个智能体，结果路由错了、上下文丢了、延迟涨了、账单也涨了。多智能体不是升级版，是另一种架构选择。

Anthropic曾报告，其自研的多智能体研究系统在一项内部研究评测中，比单智能体基线高出90.2%。但这个结果只属于那套系统和那组测试集，它并不能证明多智能体架构存在普遍优势。换句话说，多几个智能体，不等于系统自动变好。

单智能体系统把指令、上下文和工具交给一个模型驱动的智能体，由它自己规划、调工具、检查结果、产出最终输出。它可以用很多确定性工具，但不会因此变成多智能体系统。多智能体系统则包含两个或更多有独立角色的模型驱动智能体，可以由管理者协调，也可以通过交接转移控制权，或者并行跑独立分支。OpenAI的Agents SDK把"管理者即工具"和"交接"列为两种常见模式。这些是架构选择，不是成熟度等级。

关键问题只有一个：谁拥有下一个决策和最终结果。多出来的框框，只有在制造出有用边界时才站得住脚。

三种常见架构

• 单智能体：请求 → 一个智能体 → 工具 → 结果。一个负责人掌握全部上下文，决定调用哪个确定性工具。
• 管理者加专家：管理者 → 研究智能体 → 数据智能体 → 写作智能体。管理者把专家当工具调用，合并输出，拥有最终结果。
• 分诊加交接：分诊 → 计费 → 预订 → 支持。路由器选出一个专家，由它负责对话的下一段。

什么时候一个智能体就够了？当一个角色能理解目标、拿到必要上下文、从可控的工具集里做选择时，就用一个。线索接收、预约准备、支持草稿、内部报告，往往都从这一步开始。一个负责计算、搜索或写记录的工具，只要遵循确定性逻辑，就不需要拥有自己的智能体。

单智能体更容易追踪，因为一套指令拥有整个决策循环。它也避免了反复打包上下文和专家输出互相打架。Anthropic的架构指南建议从最简单的系统起步，只有当复杂度带来可测量的改进时才往上加。不要为每个工具都造一个专家智能体，只有当它需要自己的判断、上下文、权限或评估时，才值得独立。

多智能体什么时候有用？当任务能拆成需要不同指令或工具权限的独立区域时。研究管理者可以派并行智能体去探索不同市场，再比对证据；客服路由器可以把计费案例交给一个只有有限账户工具的计费专家。并行研究是个典型例子，因为各分支可以朝不同方向探索，不必互相等待。

值得拆分的理由包括：独立工作可以并行；专家需要不同的数据或工具权限；每个专业方向有独立的评估集；一个提示词已经难以理解和维护；路由边界对应真实的运营边界；一个管理者必须合并多个产出证据的子任务。

管理者还是交接

当一个组件必须保留用户上下文、执行共享策略并产出最终答案时，用管理者。专家表现得像工具：接收一个有边界的任务，返回一个结果。这对报告、提案和调查有用，多份贡献最终汇成一份交付物。

当路由本身就是工作流时，用交接。专家接管，比如计费、预订或技术支持。OpenAI的交接文档允许带类型的路由元数据和上下文过滤器。但设计上仍然需要在任何副作用发生前做应用层权限检查，模型生成的一个交接理由不是授权。

选择可以按七步走：定义一个有可测量结果的目标，说清什么算跑完、谁拥有业务结果；搭一个单智能体基线，只给它任务需要的上下文和工具；记录真实失败，判断问题出在上下文过载、工具混淆、缺少专业知识、延迟还是源数据太弱；先试更简单的修法，改进工具描述、结构化输出、检索和确定性路由；命名边界，只有当指令、工具、权限和评估确实不同时，才给新智能体独立身份；在管理者、交接或代码编排里选一个，合成保留一个负责人，服务路由转移控制权，顺序必须可预测时用代码；最后对照基线，在同一测试集上测量任务成功率、路由、证据、延迟、成本和恢复能力。

测试要分三层：先单独测每个智能体，再测每个路由或交接边界，最后测整个系统。单智能体和多智能体版本要用同一批正常、模糊和对抗性案例。记录每一次智能体调用、工具调用、转移、来源和审批结果，让复核者能重建整次运行。

成功的标准也很具体：所选架构比基线更可靠地完成任务；每条路由要么正确，要么失败进一个安全可见的队列；转移的上下文足够但不含不必要的敏感数据；专家输出使用定义好的模式并引用证据；循环在配置的上限处停止；每次交接之后，有后果的操作仍然停在同一个审批闸门后面；改进足以证明额外的延迟、成本和运维工作是值得的。

如果一段提示词加两个工具就能可靠解决你的任务，你不需要多智能体系统。先建一个可靠的智能体，再谈编排。