摘要：单个 agent 做不完的任务，要拆给一批 agent 协同。这篇文章不复述某一家框架怎么用，而是把多智能体编排共有的机制拆开——控制流怎么走、agent 之间怎么通信、共享状态放在哪、下一步交给谁、什么时候停、结果怎么合。机制之上，看两种主流范式、几种常见拓扑，以及把编排延伸到组织边界的互操作协议 MCP 与 A2A。最后给一份选型判断和几个容易踩的坑。
《Agent 子智能体工程笔记》讲了多智能体编排的最简形态 SubAgent：一个父 agent 派一个子 agent，子带独立上下文，只把摘要交回，父保留控制权。那是「一对一委派」。
一旦任务需要多个 agent 同时参与、彼此交换中间结果、共同收敛到一个答案，单层 SubAgent 就不够了。一批 agent 怎么协同，是编排（orchestration）要回答的事。
2026 年的多框架生态已经不少：LangGraph、CrewAI、Google ADK、Microsoft Agent Framework、LlamaIndex Workflows、Mastra、Strands Agents、Agno、Pydantic AI，加上 OpenAI Agents SDK 与 Claude Agent SDK 两个厂商 SDK，还有 Anthropic 自己的多智能体研究系统。它们的差异不在功能清单——工具、记忆、可观测这些现在各家都有——而在「用什么原语组织 agent 交互」：LangGraph 用有状态图，CrewAI 用角色团队，AG2（原 AutoGen）用多轮对话，OpenAI Agents SDK 用 handoff。原语不同，但被组织起来的机制是同一批。
这篇文章不绑定某一家，先把这批机制拆开讲，再回来看它们怎么组合成不同的范式和拓扑。
一、编排层解决什么
SubAgent 那两个前提——子任务互相独立、父拿摘要就能决策——一旦破了，单层委派就不够用。
三种失灵的形态：
子任务之间有依赖。B 要先读到 A 的输出才知道怎么改，A 没跑完 B 只能等着。把依赖的子任务串起来顺序执行也能跑通，但同一个 agent 要在几个视角之间来回切换，上下文容易互相干扰。
结论需要协商。三个 agent 各出一版方案，要互相看、互相评审，收敛成一个。各自独立产出再交给父合并，合出来的版本可能自相矛盾——因为谁都没见过别人改到哪了。
状态要活很久。任务跑几十分钟，中途要人能看一眼再放行，进程崩了要能接着跑。一次性的 SubAgent 调用支撑不了这么长的生命周期。
三种失灵各自指向一组机制：依赖要由控制流安排先后，协商要解决通信、路由与汇聚，长寿命任务要求状态能放到 agent 之外。
落到工程上，就是五个机制层面的问题：
- 控制流：谁先跑、谁等谁，同步还是异步
- 通信：agent 之间用什么方式交换信息
- 共享可变状态：共同的状态放在哪，谁改，怎么避免并发冲突
- 路由：下一步交给哪个 agent，由谁决定
- 终止与汇聚：什么条件下停，多个结果怎么合
五个机制是编排的骨架。不同框架、不同拓扑，本质是这五条的取值和组合不同。
二、控制流：同步阻塞与异步事件
最直接的控制流是同步阻塞。父 agent 发起一批子任务，等全部返回，再往下走。第 13 期的 fan-out / fan-in 就是这一种，只是那时讲的是「一个父多个子」，这里升到编排维度：谁来等、等多久、等待期间能否处理其他任务。
同步的好处是可预测。执行顺序清楚，状态在每一步都是确定的，出错时调用栈容易读。代价是延迟按最慢的那个算——派出去五个子任务，其中一个跑了三分钟，其余四个早回了也没法继续。
异步事件驱动换一种方式。agent 各自跑，谁完成了谁通过事件或消息上报，调度端收到就推进。首字延迟低，慢任务不会阻塞快任务。代价是复杂度上升：执行顺序不再确定，状态要在并发下保持一致，出错的传播路径变长——一个子任务静默失败，事件流里可能没人注意。
各家的落点：LangGraph 的图按 superstep 批量执行节点，一个 superstep 内的节点并发、跨 superstep 同步；OpenAI Agents SDK 由一个 runner loop 驱动整个 agent 循环；AG2 把控制流建模成对话轮次，一轮一个说话者。这些都是同一个问题的不同答案：谁在驱动、以什么节奏推进。
