多 agent 编排Multi-agent orchestration

多 agent 编排就是让多个 agent 分工干同一件事。 分工的理由通常有三个：上下文装不下、任务能并行、不同环节要不同专业知识。 编排的核心问题只有一个：下一步交给谁，上下文跟着谁走。

本站讲机制，不排名。文中提到的产品都链到各自的档案页——档案是事实源，这篇是视角。

Multi-agent orchestration means having several agents divide up one job. The usual reasons to divide are three: the context does not fit, tasks can run in parallel, different stages need different expertise. The core question of orchestration is a single one: who takes the next step, and whose context travels with it.

This site explains mechanisms, not rankings. Every product mentioned links to its own dossier — the dossiers are the source of facts, this guide is the lens.

多数「想上多 agent」的需求，单 agent 加对工具和提示词就能满足。 LangGraph 官方文档把这句话放在多 agent 篇的开头：

"However, not every complex task requires this approach— a single agent with the right (sometimes dynamic) tools and prompt can often achieve similar results."

开发者想要多 agent，通常真实想要的是三种能力之一： 上下文管理、并行化、多人分头开发。 后两个是好理由；第一个要先确认「上下文真的装不下」， 因为拆错的代价比不拆大。

Most needs that "want multi-agent" are satisfied by a single agent with the right tools and prompt. LangGraph's official docs put this sentence at the top of the multi-agent page:

"However, not every complex task requires this approach— a single agent with the right (sometimes dynamic) tools and prompt can often achieve similar results."

When developers want multi-agent, what they usually really want is one of three capabilities: context management, parallelism, or multiple people developing separately. The latter two are good reasons; for the first, first confirm "the context genuinely does not fit", because the cost of splitting wrong is bigger than the cost of not splitting.

LangGraph 把市面上的多 agent 实现归成四类模式。

Subagents（子 agent 当工具）：主 agent 把子 agent 当工具调用， 路由全部经过主 agent，由它决定何时调用哪个。 LangGraph 与 Google ADK 都属这一形态。

ADK 官方原文："ADK automatically generates weather_checker and flight_booker delegation tools"—— 协调 agent 声明 SubAgents 后，委派工具以各子 agent 命名。 子 agent 干完活，控制权自动回到协调 agent。

Handoffs（交接）：当前 agent 把对话整个移交给下一个 agent。 OpenAI Agents SDK 的官方定义是 "Handoffs allow an agent to delegate tasks to another agent"。 交接在模型眼里是一个工具：移交 refund agent 的工具就叫 transfer_to_refund_agent。

CrewAI 官方原文：hierarchical 进程下 "Tasks are not pre-assigned; the manager allocates tasks to agents based on their capabilities, reviews outputs, and assesses task completion"。 manager 动态分派、复核输出、判断是否完成，近似 Anthropic 的 orchestrator-workers。

Router（路由）：一步分类，把输入导给专门的 agent，再合成回答。 它和 Anthropic 写的 routing 模式同源：先分类，再走专门路径。

自定义工作流：把编排画成图，确定性和 agent 行为混排。 适合流程本身需要被代码约束的场景——哪步必须拦、哪步可并行，写死在图里。

四种形态对照：

LangGraph groups the market's multi-agent implementations into four patterns.

Subagents (a sub-agent as a tool): the main agent calls sub-agents as tools, all routing passes through the main agent, which decides when to call which. LangGraph and Google ADK both belong to this shape.

ADK official text: "ADK automatically generates weather_checker and flight_booker delegation tools" — after a coordinating agent declares SubAgents, delegation tools are named after each sub-agent. When a sub-agent finishes, control automatically returns to the coordinating agent.

Handoffs: the current agent transfers the whole conversation to the next agent. The official definition in the OpenAI Agents SDK is "Handoffs allow an agent to delegate tasks to another agent". To the model a handoff is a tool: the tool that transfers to the refund agent is called transfer_to_refund_agent.

CrewAI official text: under the hierarchical process, "Tasks are not pre-assigned; the manager allocates tasks to agents based on their capabilities, reviews outputs, and assesses task completion". The manager dispatches dynamically, reviews outputs, and judges completion — close to Anthropic's orchestrator-workers.

Router: one classification step sends the input to a specialized agent, then synthesizes the answer. It shares its roots with the routing pattern Anthropic describes: classify first, then take a specialized path.

Custom workflows: draw the orchestration as a graph, mixing determinism and agent behavior. Fits scenarios where the flow itself must be constrained by code — which step must be intercepted, which can run in parallel, written into the graph.

The four shapes compared:

这是编排里最容易被忽略、出事最多的一点。

OpenAI 官方原文："the new agent takes over the conversation, and gets to see the entire previous conversation history"。 也就是说，交接发生时默认全量历史跟走。 要改，用 input_filter 过滤，或用运行配置控制交接历史的嵌套方式。

ADK 的协作模式还多一层选择，子 agent 可配成三种模式：

• chat（默认）：可与用户来回。
• task：可追问用户，做完自动还回控制权。
• single_turn：单轮执行，做完即回。

官方特意提醒：这个模式只给子 agent 用，根 agent 不要配。

CrewAI 的 sequential 进程则是另一极：任务按列表顺序跑， 上一个任务的输出作为下一个的上下文。 可控，但不够灵活。

This is the most overlooked, most accident-prone point in orchestration.

OpenAI official text: "the new agent takes over the conversation, and gets to see the entire previous conversation history". That is, when a handoff happens the full history follows by default. To change that, use an input_filter, or control the nesting of handoff history via run configuration.

ADK's collaboration modes add one more choice — a sub-agent can be configured in three modes:

• chat (default): can go back and forth with the user.
• task: can ask the user follow-ups, then automatically returns control when done.
• single_turn: one turn, returns immediately when done.

The official docs specifically remind: this mode is for sub-agents only; do not set it on the root agent.

CrewAI's sequential process is the other pole: tasks run in list order, the previous task's output becomes the next one's context. Controllable, but not flexible enough.

上下文逐级膨胀。 每交接一次默认带上全量历史， 多跳之后提示词被历史撑爆，成本和延迟一起涨。 拆 agent 的初衷（省上下文）反而没了。

职责重叠或留空。 两个 agent 都以为某件事归对方， 或者某件事谁都不接。 Anthropic 的建议是从简单做起：先优化单次调用，不够再叠加多步系统。

错误复合。 单 agent 出错还能原地重试； 多 agent 一环错、环环错，且更难定位是哪一环开始的。 Anthropic 官方原文："The autonomous nature of agents means higher costs, and the potential for compounding errors."

Context balloons hop by hop. Each handoff carries the full history by default; after several hops the prompt is swollen by history and cost and latency rise together. The original point of splitting agents (saving context) is gone.

Overlapping or empty responsibilities. Two agents each assume the other owns something, or nobody picks something up. Anthropic's advice is to start simple: optimize the single call first, add multi-step systems only if it is not enough.

Errors compound. A single agent can retry in place; in multi-agent one wrong link poisons every later link, and it is harder to locate which link started it. Anthropic official text: "The autonomous nature of agents means higher costs, and the potential for compounding errors."

一个够用的判断顺序：

1. 单 agent 加工具能解决吗？能，就停在这里。 2. 任务能被清楚切成固定几步？能，走顺序流程（CrewAI sequential、Anthropic 的 prompt chaining）。 3. 输入有明确类别、各类差异大？走 Router / routing。 4. 子任务无法预先枚举、要动态拆？走 orchestrator-workers 或 Subagents。 5. 需要人审关键节点？在自定义工作流里加人工检查点。

拆错比不拆贵。拆之前先想清楚： 每个 agent 各自的上下文里应该有什么、不应该有什么。

A decision order that is usually enough:

1. Can a single agent with tools solve it? If yes, stop here. 2. Can the task be cleanly cut into a fixed few steps? If yes, use a sequential flow (CrewAI sequential, Anthropic's prompt chaining). 3. Are the inputs clearly categorized with large per-category differences? Use Router / routing. 4. Are subtasks not enumerable in advance, needing dynamic decomposition? Use orchestrator-workers or Subagents. 5. Do humans need to review key nodes? Add human checkpoints inside a custom workflow.

Splitting wrong costs more than not splitting. Before splitting, think through: what each agent's own context should contain — and what it should not.