分角色很容易，交接很难

多 Agent 演示通常很好看：一个规划 agent，一个研究 agent，一个写作 agent，一个审稿 agent，再加一个工具 agent。每个角色都有名字、职责和提示词，像一个小团队。

真正落到产品里，难点很快从「怎么分工」变成「怎么交接」。

谁先接任务，什么时候判断自己不该继续，转给哪个 agent，转交时带哪些上下文，哪些历史不该带过去，转交后原 agent 是否还能插手，最终答案由谁负责，失败时回到哪里。这些问题如果没有协议，多 Agent 只是在同一个上下文里制造更多声音。

所以我更愿意把多 Agent 系统看成控制权系统。角色只是表层，控制权转交才是底层。

handoff 不是普通工具调用

OpenAI Agents SDK 的 handoffs 文档给了一个清楚定义：handoff 允许一个 agent 把任务委派给另一个 agent，适合不同 agent 负责不同专业领域的场景，比如客服里的订单、退款、FAQ。

关键在于，handoff 在模型眼里表现为工具，但它的效果不是「调用一个函数拿结果」。它会把控制权转给另一个 agent。文档还提供了 input filter、handoff tool arguments、on_handoff callback、动态启停等机制，用来控制接收方看到什么、转交时记录什么、什么时候允许转交。

这和「让一个 agent 调另一个 agent 作为工具」不同。工具调用通常是主 agent 仍然拥有最终回答权，专家 agent 只是返回一个局部结果。handoff 则更像客服系统里的转接：从这一刻起，用户面对的是另一个负责者。

如果产品没有把这个差异讲清楚，用户会困惑，系统也会混乱。一个退款 agent 是在给主 agent 提供建议，还是已经接管用户会话？一个安全审查 agent 是给出检查结果，还是有权阻止后续执行？这是产品语义。

manager 和 triage 是两种责任结构

OpenAI 的 multi-agent 文档把常见编排分成两类：让 LLM 决策，或者用代码编排。它还特别区分了 manager agent 和 triage agent。

manager 模式里，一个主 agent 保持会话控制权，把 specialist agents 当工具调用。适合一个 agent 汇总多个专家输出、统一把关、承担最终答案。triage 模式里，一个路由 agent 把对话交给某个 specialist，后者成为接下来这一段的 active agent。适合让专家直接回应，保持提示词聚焦。

这两个模式没有绝对优劣，区别在责任结构。

manager 模式更像项目经理：它可以问研究员、测试员、写作者，但最后由它整合。好处是口径统一，坏处是主 agent 容易变成瓶颈，也可能在整合时丢细节。

triage 模式更像分诊台：判断用户属于哪个队列，然后把人转给专科。好处是专家上下文更干净，坏处是转错以后用户要付代价，系统也要处理二次转交和回退。

多 Agent 产品要先问清楚：最终责任在中心，还是在接手者。这个问题不回答，后面的路由、日志、UI 和审计都会摇摆。

共享上下文不是越多越好

AutoGen 的 Swarm 文档描述了一种更分布式的模式：多个 agent 共享同一段 message context，每个 agent 可以基于自身能力把任务 hand off 给其他 agent；接收方拿着同一个上下文继续推进，直到满足终止条件。

这个模式的吸引力很明显。没有一个固定中心，局部 agent 可以根据当前局势决定谁更适合继续。客服、旅行退款、内容生产这类任务里，它很自然。

但共享上下文也有代价。所有 agent 都看同一段历史，意味着无关信息会扩散；一个 agent 的误解可能被后续 agent 继承；敏感内容也可能在不该出现的角色里出现。上下文共享越宽，控制权转交越像「全员围观」。

OpenAI handoff 文档里的 input filter 正是为了解这个问题。转交不只是「把聊天记录传过去」，还要决定哪些输入应该传、哪些应该删、哪些应该转成结构化摘要。

多 Agent 系统常见的坏味道，是把上下文窗口当会议纪要，所有人都看全部内容。真正可维护的系统，应该把上下文当权限和工作材料处理：接手者需要什么，就给什么；不需要的历史，不要因为方便而传过去。

选择下一个说话者也是一种编排

AutoGen 的 Selector Group Chat 提供了另一种思路：团队成员轮流广播消息，由模型根据共享上下文和参与者描述选择下一个 speaker。它支持配置 participant roles、避免同一 speaker 连续发言、用自定义 selection function 覆盖模型选择，以及用 candidate function 收窄候选人。

这类机制容易被看成「群聊玩法」，但它处理的是严肃问题：当多个 agent 都可能接下一步时，谁来决定？

如果完全交给模型选，系统会灵活，但可预测性下降。模型可能选错专家，可能让同一个 agent 反复发言，也可能在任务已经该结束时继续转圈。如果完全由代码写死，系统可控，但会失去一部分动态适应能力。

所以 selector 模式真正有价值的地方在于把「下一步谁说话」变成一个可观察、可替换、可约束的决策点。产品可以记录每次选择的理由，也可以在关键环节把候选范围收窄，甚至用规则覆盖模型。

多 Agent 协作不是越自治越好。好的系统会把自治放在被框住的位置上。

workflow graph 把交接从语言变成结构

Microsoft Agent Framework Workflows 的文档把 agent 和 workflow 分开：agent 由 LLM 驱动，步骤由上下文和工具动态决定；workflow 则是预定义的操作序列，可以包含多个 agent、人工交互和外部系统集成。它还强调强类型消息、图结构、条件路由、并行处理、request/response、HITL、checkpoint，以及 sequential、concurrent、hand-off、magentic 等多 agent 协调模式。

Google ADK 的 Workflows 文档也指向类似判断：单一大 agent 在任务复杂后会变得难开发、难评估、难维护；把应用拆成多个 agent 和节点，可以用 graph、code、coordinator、sequence、loop、parallel 等结构控制执行顺序和上下文范围。

这两套文档都在把交接从语言层拉到结构层。

只靠提示词说「你完成后交给审核 agent」，在 demo 中可能够用。生产里更稳的做法，是把交接写成图、边、条件、类型和 checkpoint。谁能把什么消息传给谁，什么条件触发并行，什么节点需要人工确认，哪个 checkpoint 可以恢复，这些都应该是系统结构，而不是靠 agent 临场记住。

这也是为什么多 Agent 不一定意味着更自由。很多时候，它反而需要更明确的工作流。

协作工具要有边界

CrewAI 的 Collaboration 文档里，协作主要通过两个工具展开：delegate work to coworker 和 ask question to coworker。一个 agent 可以把任务分派给有特定专长的同伴，也可以向同伴提问获取信息。

这个设计很朴素，但提醒了一件事：协作动作本身也应该被建模。

「问问题」和「委派任务」不是同一种动作。问问题不转移责任，只是补信息；委派任务则要求对方产出一个结果，甚至可能改变执行路径。把它们混成「agent 之间互相聊天」，系统就很难知道谁欠谁一个结果，也很难判断什么时候该结束。

多 Agent 系统越复杂，越需要把协作动词收敛。查询、委派、审核、批准、拒绝、转交、升级、终止，最好都是明确动作，而不是一堆自然语言来回。

这是为了让人能看懂发生了什么。

多 Agent 的最小可用协议

如果现在要做一个多 Agent 产品，我不会先堆很多角色。我会先写一份很短的 handoff 协议。

它至少要回答七个问题。

  • 触发条件：什么情况下当前 agent 必须转交，什么情况下只能询问。
  • 目标选择：候选 agent 是固定列表、模型选择，还是代码路由。
  • 上下文过滤：接手者看到完整历史、摘要，还是结构化字段。
  • 责任归属：转交后谁拥有下一步控制权，谁负责最终答案。
  • 终止条件：任务结束、失败、升级和人工接管分别怎么判断。
  • 可观察性：每次转交要记录理由、输入、接收方和结果。
  • 恢复路径：转错了能不能回退，失败了从哪里恢复。

这些问题答清楚以后，再去决定用 manager、triage、swarm、selector group chat、workflow graph，或者几种模式混合。

多 Agent 的价值不是把一个大模型拆成一群小角色。它的价值在于把复杂任务里的责任、上下文和执行路径拆清楚。真正难的地方，也正在这里：让控制权可靠地移动。