🚀30 秒速览
先给你一张全景图,后面每章再逐层加深。任何一章停下来,你都能带走一个完整(虽然粗)的理解。
一句话:多智能体编排,就是把一个大任务拆给"一位主管 + 若干名专职助手"去做——主管负责拆解任务、分派、汇总,助手各自埋头搞定自己那块,互不打扰。这套"主管-工人"(orchestrator-worker)结构是目前生产环境里最主流的多智能体架构。[Anthropic 工程博客]
相对单个 Opus 4 的评测提升
的 token 消耗倍数
"智能体间不对齐"占比
数据来源见下文对应章节与文末来源清单。多智能体是把双刃剑:用对了大幅提升,用错了成本爆炸、还更容易失败。
🧭背景:单个 Agent 撞到了什么墙
先讲痛点,你才知道多智能体是来解决什么的。
先说清楚"Agent(智能体)"是什么:它就是一个能自己循环思考、调用工具、根据结果决定下一步的 AI 程序——不是回答一句就停,而是"想→做→看结果→再想",直到把任务办完。
单个 Agent 很能干,但做又长又杂的任务时会撞三堵墙:
- 上下文窗口装不下。一个模型一次能"记住"的内容有上限(上下文窗口)。要读几十份资料、跑几十步的任务,信息量早就超了,越到后面它越容易"忘记前面"。
- 串行太慢。一个 Agent 一次只能干一件事。要调研 5 个方向,它只能一个一个来,时间线性叠加。
- 什么都自己扛,容易乱。让一个 Agent 同时管一堆互不相关的复杂工具(日历、邮件、数据库、代码……),它的"注意力"被摊薄,选错工具、串味的概率上升。
多智能体的思路很朴素:既然一个人忙不过来,那就组个团队。主管把大任务切成互相独立的小块,分给几个只专注一块、各自拥有全新干净上下文的助手,还能同时开工。这正是 Anthropic 让研究系统提速的核心——子智能体并行探索不同方向,每人一个新的上下文窗口。[Anthropic]
一个厨子做满汉全席,只能一道接一道慢慢来,还得记住每道菜进度。换成一个后厨:主厨(主管)看菜单拆单,凉菜、热炒、汤锅各有专人(子智能体)同时开火,最后主厨摆盘上桌(汇总)。快,而且每个人只需盯住自己那口锅。
📖核心概念:到底什么是"多智能体编排"
把几个关键词一次讲透,后面就不再卡壳。
拆开看几个必懂术语:
| 术语 | 人话解释 |
|---|---|
| 主管 / 编排者 (Orchestrator / Supervisor / Lead Agent) | 拿到用户请求的那个"总指挥"。它分析任务、制定策略、把子任务分派下去、最后把结果拼成答案。全局视野在它手里。[CallSphere] |
| 子智能体 / 工人 (Subagent / Worker) | 只负责一小块的专职助手。Anthropic 的设计里,每个子智能体拿到一份自包含的任务说明、期望的输出格式和一个全新上下文——它不知道其他子智能体的存在,也不能中途和它们商量。[Anthropic] |
| 交接 / 移交 (Handoff) | 一个智能体把"控制权"或任务转交给另一个的动作。有的框架里交接会把完整对话历史一并传过去,接手方看到的就像自己从头参与过。[OpenAI Agents SDK] |
| 护栏 (Guardrails) | 套在每次智能体交互上的输入/输出检查,防止跑偏或输出不该输出的东西。[OpenAI Agents SDK] |
🔀两大编排范式:Supervisor 还是 Handoff
读到这里你会问:多个智能体具体怎么"连线"?主流就两种连法。
OpenAI Agents SDK 把它总结为两个广泛适用的模式,理解了这两个,市面上大部分多智能体系统你都能看懂:[OpenAI Agents SDK]
范式一:Manager / Supervisor(把子智能体当"工具"用)
一个中央主管始终掌控整场对话,需要时把某个专职子智能体当作一个工具去调用,拿回结果后自己继续。控制权从不真正离开主管。适合"专家只帮我搞定一小段、但别抢过对话主导权"的情况。这也是 LangGraph 生产部署里最常用的架构。[CallSphere]
范式二:Handoff(平级智能体"交棒")
智能体之间是平级的,一个把控制权整个交给另一个专家,由后者接管接下来的对话。这是去中心化的——路由本身就是流程的一部分。适合"根据用户意图,直接把他转给对的专家窗口"的情况,比如客服先分诊再转接。[OpenAI API 文档]
🛠️怎么用:动手搭一个(以主流框架为例)
这里给两条最常见的落地路径。代码为示意骨架,具体 API 以官方最新文档为准。
路径 A:LangGraph 的 Supervisor 模式
LangGraph 里,智能体之间通过基于工具的交接机制沟通,主管根据当前上下文决定该调哪个工人;还能加短期/长期记忆,甚至让一个主管去管多个下级主管,搭出多层级结构。[LangChain Reference]
# 示意骨架(LangGraph Supervisor 思路)
supervisor = create_supervisor(
agents=[calendar_agent, email_agent, crm_agent],
model="claude-…",
prompt="你是主管。根据用户请求,把子任务派给合适的专家,再汇总结果。"
)
# 主管收到请求 → 选专家(以工具形式调用)→ 收回结果 → 继续/汇总上面是概念示意,用于说明"主管持有一组专家、按需以工具形式调用"的结构;实际函数名与参数请对照 LangGraph 当前文档。
路径 B:OpenAI Agents SDK 的四件套
OpenAI 在 2026 年初开源的 Agents SDK,把多智能体系统抽象成四个基本积木:AgentsToolsHandoffsGuardrails,用很少的样板代码就能拼出复杂工作流。用 handoff() 函数指定交接目标,还能配置输入过滤器;交接时完整消息历史会一起传给接手方。[OpenAI Agents SDK]
- 定义每个 Agent:给它名字、指令(system prompt)、可用工具。
- 声明关系:是把子 Agent 作为工具挂给主管(Manager 模式),还是用
handoff()配置平级交棒(Handoff 模式)。 - 加护栏:给输入/输出套 Guardrails,拦掉越界请求或不合规输出。
- 跑起来看轨迹:观察每次调用/交接,定位问题多半出在"交接点"而非模型本身。
🎯什么场景用:三类"值得组团"的任务
不是所有任务都该上多智能体。它的甜区很明确。
研究与实践都指向:多智能体架构专门擅长三类任务——需要大量并行、信息量超出单个上下文窗口、以及要对接一大堆复杂工具。[DEV]
| 场景 | 为什么适合多智能体 | 真实例子 |
|---|---|---|
| 深度research / 情报调研 | 要同时探索多个独立方向,信息量远超单窗口 | Anthropic 的 Claude Research:主管规划,并行开 3–5 个子智能体各查一个方向,再由独立的"引用核对"环节收尾;相对单 Agent 提升 90.2%。[Anthropic] |
| 多领域个人助理 | 日历、邮件、CRM、数据库各自有一堆工具和逻辑,分给专家更清爽 | Supervisor 统一路由,子智能体不直接和用户对话——LangGraph 推荐的典型用法。[LangChain Docs] |
| 客服 / 工单分诊 | 路由本身是流程,不同意图交给不同专家窗口 | Handoff 模式:分诊 Agent 判断意图后,把整段对话交棒给退款、技术支持等专家。[OpenAI] |
⚖️和单智能体怎么比:一场真实的行业争论
这不是"多智能体一定更好"。业界对此有过公开对撞,值得你两边都听。
2025 年 6 月 12 日,Cognition 发了篇著名的《Don't Build Multi-Agents(别搭多智能体)》,立场很硬:并行子智能体架构天生脆弱,因为上下文被隔离,导致各自做出互相冲突的隐含决策,拼起来就是一团乱。[Cognition]
Cognition 的解法是:优先用单线程、线性的智能体,换取可靠性。
另一边,Anthropic 用数据反驳:它的 Claude Research 用多个智能体并行探索,内部评测比单智能体基线高 90.2%。差别在哪?Anthropic 和 Cosine 这类系统都用一个主管来维持全局视野,确保子智能体在"共享的大目标"下对齐,而不是放任它们各自为战。[对比综述]
| 维度 | 单智能体(线性) | 多智能体(编排) |
|---|---|---|
| 一致性 | 高:全程一个上下文,决策连贯 | 要靠主管兜底,子智能体间易不对齐 |
| 并行/速度 | 串行,慢 | 可并行,快 |
| 可处理规模 | 受单窗口限制 | 能突破单窗口,吞更大信息量 |
| 成本 | 约为对话的 4× | 约为对话的 15×[Augment] |
| 适合 | 环环相扣、强依赖上一步的任务 | 可并行、超大信息量、多复杂工具 |
🕳️有什么坑:上手前先知道这几件事
这些是社区和研究里反复出现的高频问题,不是危言耸听。
多智能体任务失败率区间
(单智能体不会有这类失败)
烧掉的 API 费用(还没产出)
数据来源:多智能体扩展性研究综述。[DigitalOcean] [Augment]
坑一:成本非线性膨胀
不是"3 个智能体 = 3 倍成本"。编排开销、反复的上下文传递、验证层、重试循环、协调税,会在每一次交接处层层叠加,导致成本非线性暴涨。失控的重试循环几分钟就能烧掉 $40+ 还没有可用产出。[Augment Code]
坑二:智能体间不对齐(最独特的失败)
当任务扇出给并行子智能体,每个只看到任务的局部视角,各自对风格、边界情况、语义做出隐含判断,这些判断互相打架——就是前面那只"四不像"的鸟。这类失败在单智能体里根本不存在,占多智能体失败的约三分之一。[Cognition]
坑三:该共享的上下文没共享够
Cognition 的核心告诫:要共享的是完整的智能体轨迹(它到底看了什么、做了什么),而不只是最后几条零散消息。上下文给不足,子智能体就在"信息残缺"下做决定。设计时要在"隔离换并行"和"共享保一致"之间找平衡。[Cognition]
坑四:把简单任务硬做成多智能体
需要强共享上下文、或子任务间依赖很多的任务,不适合多智能体。硬上只会引入协调复杂度、成本和新的失败类别。先问自己:单智能体真的搞不定吗?[DEV]
📰和今日新闻的关系:为什么现在讲这个
把今天的情报和这个主题连起来,你会更明白它的当下意义。
- Anthropic:"工程师从实现者变编排者"。其 2026 Agentic Coding 趋势报告指出,工程师的价值正转向系统设计、Agent 协调与质量评估——多智能体编排正是这项新技能的核心。[Anthropic 趋势报告]
- MCP 2026-07-28 规范(RC)新增 Tasks 扩展。长时任务从实验特性升为正式扩展,
tools/call可返回 task handle,由tasks/get/update/cancel驱动——这正好给"主管派发长任务、子智能体异步跑"提供了标准协议支撑。[MCP Blog] - MCP Apps 扩展带来交互式 UI。子智能体的工具可以声明 UI 模板、在沙箱 iframe 里渲染界面,让多智能体协作的中间产物可视化。[Stacktree]
换句话说:今天的行业趋势(编排者角色)、协议进展(MCP Tasks/Apps)、和这份文档讲的架构方法,是同一件事的三个侧面。
📚学习资源清单
想继续深入,从这几个一手来源开始最靠谱。
- Anthropic《How we built our multi-agent research system》(orchestrator-worker 一手实践、90.2% 数据出处)— anthropic.com/engineering/multi-agent-research-system
- Cognition《Don't Build Multi-Agents》(反方视角,必读的对照)— cognition.com/blog/dont-build-multi-agents
- LangChain《How and when to build multi-agent systems》(何时该用、官方建议)— langchain.com/blog
- OpenAI Agents SDK · Multi-agent / Handoffs 文档(四件套与两大范式)— openai.github.io/openai-agents-python
- LangGraph Supervisor 参考(Supervisor 落地)— reference.langchain.com/python/langgraph-supervisor