12. 多 Agent 协作:Orchestrator、Debate、Handoff 与它们的陷阱

第一篇开头就提过一个反直觉事实:多 Agent 经常比单 Agent 弱。这一篇展开讲清楚——为什么会这样、哪些多 Agent 模式真的有效、哪些只是"看起来炫"。

开源社区在 2024~2025 年一度被"多 Agent 系统"的概念冲昏头脑。每个项目看起来都要有 PM Agent、Coder Agent、Reviewer Agent、QA Agent。结果是一堆"玩具能跑、生产不行"的 demo。Anthropic 和 Cognition 在 2024 年底各自发文打了一盆冷水,业界才开始严肃思考"什么时候多 Agent 真的有价值"。

为什么多 Agent 常常出问题

把任务拆给多个 Agent,直觉上像公司分工——每个人专精一件事,效率更高。但 LLM Agent 和人类员工有几个根本不同:

上下文不能真正共享。人类员工之间可以"15 分钟同步一下",用自然语言传递信息时丢失量很小。Agent A 把任务交给 Agent B,中间要把 A 的上下文"压缩成消息"传给 B。压缩必然丢信息。A 做了 2 小时才形成的直觉和细节,B 永远拿不到。

错误沿链路放大。A 略微偏了,B 在 A 的输出上继续偏,到 D 那里已经完全跑偏。单 Agent 跑偏时,它自己在下一轮 Thought 里有机会发现;多 Agent 看不到彼此的思考过程,只看到对方的"最终输出",很难纠错。

延迟和成本乘积累加。5 个 Agent 串行每个跑 30 秒,加上它们之间的协调开销,一次任务 3 分钟。同样的任务单 Agent 循环 10 轮可能 1 分钟搞定。

协调成本。谁决定下一步给谁做?Agent A 觉得 B 该做,B 说自己做不了该 C 做,C 不理解,绕回 A——这些在多 Agent 系统里是真的会发生的 deadlock。

Cognition(Devin 的团队)在 2024 年底的文章 "Don't Build Multi-Agents" 里有句话很精准:如果你能用单 Agent 跑,就用单 Agent;你能给 Agent 更多工具而不是拆一个出去,就多给工具。

多 Agent 真有用的三种场景

这不是说多 Agent 一无是处。它确实在某些场景有价值:

场景一:任务可清晰划分,且每个子任务足够独立

典型:研究型任务。"帮我调研 10 家同行公司的产品特性",这是可以拆成 10 个几乎独立的子任务的。每个 Worker Agent 负责查一家,最后 Orchestrator 汇总。子任务之间没有依赖,Worker 不需要看彼此的上下文,多 Agent 的弱点被规避。

场景二:需要不同"视角"而非不同"分工"

典型:Debate 模式。同一个问题给两个 Agent,一个从 Pro 角度论证,一个从 Con 角度反驳,第三方综合。多视角能暴露单 Agent 容易忽略的盲点。这不是把任务拆小,是让同一任务被多个独立思考覆盖。

场景三:工具集或权限相差巨大

典型:一个 Agent 能读写生产数据库(高权限、高风险),一个 Agent 只读文档(低风险)。用不同 Agent 做权限隔离,避免模型在错误时做出破坏性操作。这里多 Agent 是安全边界,不是效率工具。

其他看起来合理但实际不行的:PM Agent + Coder Agent + Reviewer Agent 做软件开发——实际跑下来 PM 的上下文传不到 Coder,Coder 的代码 Reviewer 看不到完整背景,结果比一个配齐工具的 Coder Agent 差得多。Claude Code、Cursor、Aider 全是单 Agent 做代码,不是偶然。

Orchestrator-Worker 模式

这是最常见、也最经得起推敲的多 Agent 架构:

            Orchestrator
          ↙     ↓     ↘
    Worker A  Worker B  Worker C
    (各自独立执行子任务)

核心是Orchestrator 做分派和汇总,Worker 各自独立工作,Worker 之间不交流。Worker 之间不交流这一点很重要——一旦 Worker 之间开始协调,就退化成"多 Agent 协调灾难"。

一个最小实现:

import asyncio
from openai import AsyncOpenAI

client = AsyncOpenAI()

async def worker(task: str, worker_id: int) -> dict:
    resp = await client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": f"你是 Worker {worker_id},专注完成分给你的子任务,返回结果。"},
            {"role": "user", "content": task},
        ],
    )
    return {"worker_id": worker_id, "task": task, "result": resp.choices[0].message.content}

async def orchestrator(main_task: str):
    # Step 1: 让 Orchestrator 拆任务
    plan_resp = await client.chat.completions.create(
        model="o4-mini",
        messages=[
            {"role": "system", "content": "你是协调者。把用户的任务拆成可并行的独立子任务,返回 JSON 数组。每个子任务要自包含,能独立完成。"},
            {"role": "user", "content": main_task},
        ],
        response_format={"type": "json_object"},
    )
    subtasks = json.loads(plan_resp.choices[0].message.content)["subtasks"]

    # Step 2: 并行分派给 Worker
    results = await asyncio.gather(*[
        worker(t, i) for i, t in enumerate(subtasks)
    ])

    # Step 3: Orchestrator 综合
    synth_resp = await client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "综合多个 worker 的结果,输出完整答案。"},
            {"role": "user", "content": f"原任务: {main_task}\n子任务结果: {results}"},
        ],
    )
    return synth_resp.choices[0].message.content

这个模式之所以稳,是因为它遵守了几个原则:

Worker 之间完全不交流,每个 Worker 只和 Orchestrator 有关系
子任务自包含,Worker 拿到就能跑,不需要"跨 Worker 的协调"
并行执行,5 个子任务并发跑,总延迟等于最慢那个,不是累加
最终综合由 Orchestrator 做一次,不需要 Worker 之间比较结果

Anthropic 2025 年初公开的 Claude Research 架构就是这个模式——一个 Lead Agent 拆任务,多个 Subagent 并行查询,Lead 再综合。对"同时调研多个方向"的任务,这比单 Agent 串行做快好几倍。

Debate / Multi-Critic 模式

另一种有效的多 Agent 模式是让多个 Agent 对同一个问题独立表态,再综合:

async def debate(question: str, personas: list[str]):
    # 每个 persona 独立回答
    responses = await asyncio.gather(*[
        call_model(system=p, user=question) for p in personas
    ])

    # 综合者看到所有回答,给出最终意见
    synth = await call_model(
        system="你是综合者。下面是多个视角的回答,找出共识和分歧,给出综合判断。",
        user=f"问题: {question}\n\n回答们:\n{responses}"
    )
    return synth

personas = [
    "你是乐观主义者,倾向于看到机会和上升可能",
    "你是悲观主义者,倾向于指出风险和失败可能",
    "你是数据派,只看数据和事实",
]
print(await debate("应不应该买入这只股票?", personas))

这种模式对需要多角度判断的任务有效:投资决策、技术选型、风险评估、高 stakes 的写作(需要站在多种读者角度检查)。

但它对事实查询类任务没用——同一个"北京人口"问题问三次,答案差不多。只在答案有多种合理可能时,debate 才会暴露不同视角。

Handoff / Swarm 模式

OpenAI 2024 年底开源的 Swarm 把多 Agent 推向另一个方向——Agent 之间可以显式传递对话。

用户和 Agent A 对话,A 判断"这个问题应该交给 Agent B",调用一个 handoff(B) 函数,对话就切到 B。用户继续和 B 对话。

这在客服分流这种场景很自然:通用客服 Agent 先接待,判断问题类型后 handoff 给账单 Agent、技术 Agent、退款 Agent。每个专项 Agent 有自己专精的工具和 prompt。

Swarm 的核心对象是这样:

class Agent:
    name: str
    instructions: str
    functions: list[Callable]  # 包括可以 handoff 到其他 Agent 的函数

def transfer_to_billing():
    return billing_agent

def transfer_to_tech():
    return tech_agent

triage_agent = Agent(
    name="triage",
    instructions="先判断问题类型,账单问题转给 billing,技术问题转给 tech,其他自己答。",
    functions=[transfer_to_billing, transfer_to_tech],
)
billing_agent = Agent(
    name="billing",
    instructions="你处理账单、退款、发票问题。",
    functions=[lookup_invoice, process_refund],
)

Handoff 的价值在对话状态转移的自然性——用户不需要重新说一遍上下文,对话历史自动带过去。但 Handoff 也继承了多 Agent 的所有陷阱:handoff 后的 Agent 拿到上下文仍有丢信息的问题,A 手上的细节传给 B 时做了压缩。

经验是:handoff 的粒度要大。把大类任务分给不同 Agent 没问题(账单 vs 技术);但不要在一个任务内部频繁 handoff,那只会制造混乱。

多 Agent 的几个真实陷阱

写过多 Agent 后你会反复遇到这些:

无限 handoff。Agent A 转给 B,B 转回 A,死循环。解法:加 handoff 次数上限,超过就强制回到用户。

上下文爆炸。Orchestrator 综合 10 个 Worker 的输出,每个 2KB,已经 20KB。再跑几轮 Orchestrator 自己的 token 爆了。解法:Worker 必须压缩输出,不能原样扔回。

责任不清。用户问"这任务做到哪了?"——A 以为 B 接管了,B 以为 A 还在做,没人答。解法:任何时候必须有一个 Agent 明确持有"当前任务主权",handoff 时要显式转移。

失败放大。5 个 Worker 并行,1 个失败,整体任务到底算成功还是失败?解法:在 Orchestrator 层面做容错——2 个失败以内可以继续,3 个以上任务终止。

一条经验:只在单 Agent 证明不够后才引入多 Agent

我反复会用的判断流程:

先做单 Agent,配齐所有需要的工具,循环够多步
如果失败率超过可接受阈值(比如 30%),分析失败模式
如果失败是"工具不够用"——加工具
如果失败是"上下文太长,模型记不住"——优化上下文管理(第 08 篇)
如果失败是"任务步骤太多、有明显可并行的部分"——引入 Orchestrator-Worker
如果失败是"需要多视角交叉验证"——引入 Debate
如果失败是"任务类型太杂,一个 prompt 写不清"——考虑 Handoff

大多数情况下在第 3 或 4 步就解决了,根本到不了多 Agent。

小结

多 Agent 不是单 Agent 的升级,是另一个复杂度等级的系统。它有自己的价值(并行、多视角、权限隔离),也有自己的陷阱(上下文碎片、错误放大、协调灾难)。做得对的多 Agent 架构往往是 Orchestrator 拆+汇总、Worker 独立执行、互不交流 的结构——这种结构的失败模式可预测、可调试。超出这种结构的多 Agent 设计(Worker 之间相互交流、复杂 Handoff 链、嵌套 Orchestrator)几乎一定会在生产中爆炸。

下一篇切到另一个重要的 Agent 形态——Code Execution Agent。让 Agent 真正能写代码、运行代码、处理数据。沙箱怎么选、状态怎么持久化、Jupyter kernel 做状态后端的漂亮模式,都在那里。