多 Agent 编排：Manager、Handoff、并行与群聊
确定要使用多个 Agent 之后，下一个问题不是“需要几个角色”，而是“控制权怎样移动”。
谁拥有与用户的对话？谁能决定下一步？子任务结果回到哪里？两个 Worker 冲突时谁裁决？失败后重试一个节点，还是让整组 Agent 从头再聊？
这些问题共同构成多 Agent 编排。Manager、Handoff、并行、群聊看起来都能组织多个角色，实际却把上下文、责任和失败放在完全不同的位置。
一、先画控制权，再写角色 Prompt
Section titled “一、先画控制权，再写角色 Prompt”一个可运行的多 Agent 系统至少包含五类对象：
Task：原始目标和完成条件State：当前事实、产物、预算、版本Agent：在局部上下文中作出决策Message：跨边界传递的结构化信息Orchestrator：决定谁在何时运行角色说明只回答“这个 Agent 应该做什么”。编排还必须回答：
- 输入从哪里来；
- 允许读取哪些状态；
- 输出必须满足什么 Schema；
- 谁接受或拒绝结果；
- 超时、重复、冲突怎样处理；
- 整个任务由谁宣布结束。
如果这些问题留给自然语言临场协商，系统的真实控制流就藏进了模型对话，难以重放，也难以测试。
二、模式一：Manager：：一个中心负责到底
Section titled “二、模式一：Manager：：一个中心负责到底”Manager 模式中，一个主 Agent 保留用户对话和全局任务所有权。专业 Agent 被当作工具或 Worker 调用，结果返回 Manager，再由它决定下一步。
User -> Manager -> Researcher -> Manager -> Coder -> Manager -> User -> Verifier -> ManagerOpenAI Agents SDK 把这种方式称为“Agents as tools”：中心 Agent 调用专业 Agent，但不交出会话控制权。[1]
- 用户始终面对一个统一入口；
- 全局政策和语气容易集中管理；
- 子任务可以按需调用；
- 汇总与最终责任清楚；
- 适合一个任务需要多个领域专家的场景。
- Manager 容易成为上下文和延迟瓶颈；
- 专业结果经过二次总结可能失真；
- 中心节点一旦误判，所有 Worker 都被错误调度；
- 如果 Manager 看见所有原始材料，上下文隔离形同虚设。
因此，Worker 最好返回证据卡，而不是一大段聊天记录：
{ "claim": "当前稳定规范为 2025-11-25", "evidence_url": "https://...", "confidence": "high", "unresolved": []}
图 1：OpenAI Agents SDK 用 Agent、Tool、Handoff、Session 和 Trace 等少量原语表达编排。来源见文末。
三、模式二：Handoff：：把对话所有权交出去
Section titled “三、模式二：Handoff：：把对话所有权交出去”Handoff 不只是“调用另一个 Agent”。当前 Agent 把后续会话交给专业 Agent，接收者成为新的控制者。
典型例子是客服分流：入口 Agent 判断用户需要售后，交给售后 Agent；售后 Agent 从此直接追问订单号、解释规则并处理流程。
User <-> Triage Agent | +-- handoff --> Billing Agent <-> User- 专业 Agent 需要直接与用户多轮澄清；
- 后续流程长期处在同一领域；
- 转交边界清晰，例如销售、售后、技术支持；
- 接收者应拥有不同工具和政策。
Handoff 最容易丢失的是上下文和责任。交接包至少应包含：
- 任务目标与用户已确认事项；
- 已收集的事实和证据来源；
- 已执行动作及其副作用；
- 当前权限、预算和期限；
- 未解决问题；
- 回退或升级路径。
不要把完整聊天历史直接塞给接收者。完整历史可能包含无关信息、过期指令和不应跨域传播的敏感数据。
四、模式三：并行扇出：：独立工作，集中汇总
Section titled “四、模式三：并行扇出：：独立工作，集中汇总”并行适合相互独立的子问题。Orchestrator 先把任务分解，再同时启动 Worker，最后由 Aggregator 合并。
-> Worker A -\Task -> Decompose -> Worker B --> Aggregate -> Verify -> Worker C -/并行的价值主要是降低墙钟时间和隔离上下文。它并不自动降低费用：三个 Worker 仍然会产生三份计算量。
一个可靠的并行节点需要什么
Section titled “一个可靠的并行节点需要什么”- 每个 Worker 有唯一
task_id； - 输入包含明确范围和输出 Schema；
- Worker 不共享可变状态，或通过版本控制写入；
- 超时可以单独标记，不拖死全部分支；
- Aggregator 能表示“缺一项”而不是假装完整；
- 冲突结论保留来源，由验证器或规则裁决。
对于代码修改，多个 Worker 不应直接写同一工作区。更安全的方式是独立分支或工作树，提交不可变 Diff，再由唯一协调者串行接收。
五、模式四：群聊与辩论：：让多个角色共享讨论
Section titled “五、模式四：群聊与辩论：：让多个角色共享讨论”Group Chat 通常让多个 Agent 围绕同一问题轮流发言，由调度器选择下一位。Microsoft Agent Framework 提供 Group Chat、Handoff、Concurrent、Sequential 和 Magentic 等编排模式。[2]
群聊适合需要观点探索、方案评审或角色协商的任务，但它常被误用成“多说几遍就更可靠”。
群聊有效的条件
Section titled “群聊有效的条件”- 角色拥有不同信息、工具或评价函数；
- 发言轮次有终止条件；
- 决策不靠简单多数表决；
- 关键主张要落到外部证据；
- 反对意见有固定处理规则；
- 最终 Owner 明确。
如果所有角色都使用同一模型、同一上下文和同一提示，只换角色名，它们的错误高度相关。三个 Agent 同意，并不等于三个独立证据一致。
CAMEL 的 RolePlaying、Societies 和 Workforce 将角色、协调者、任务分解与 Critic 作为研究和工程对象。[3][4] 这类设计更适合探索协作机制，不代表每个生产任务都需要开放式讨论。
图 3：CAMEL 把 Agent Societies 和多 Agent 协作作为核心研究方向。来源见文末。
六、模式五：图、黑板与事件驱动
Section titled “六、模式五：图、黑板与事件驱动”复杂业务往往混合前几种模式。此时可以把编排显式化为图或事件流。
LangGraph 以共享 State 和节点/边表达控制流，支持检查点、人工介入和长时运行。[5]
图 2：LangGraph 的核心抽象是带状态的图，不是预设一组拟人角色。来源见文末。
另一种思路是黑板架构：多个 Worker 不直接相互聊天，而是读取任务板，提交结构化产物；协调器根据状态决定下一项工作。事件驱动 Flow 则由“资料已齐全”“审批已通过”“测试失败”等事件触发节点。
它们的共同优点是：控制流能被检查、重放和测试，不必从聊天顺序中推断发生了什么。
七、四种主模式怎样选择
Section titled “七、四种主模式怎样选择”| 模式 | 控制权 | 最适合 | 主要风险 |
|---|---|---|---|
| Manager | 始终在中心 Agent | 多领域协助、统一回答 | 中心瓶颈、摘要失真 |
| Handoff | 转移到接收 Agent | 分流后的长期专业对话 | 上下文与责任丢失 |
| Parallel | 编排器分发，汇总器接收 | 独立研究、批量检查 | 冲突、资源峰值、缺失分支 |
| Group Chat | 调度器轮转或角色协商 | 观点探索、评审 | 相关错误、无休止讨论 |
真实系统通常组合使用：入口先 Handoff 给领域 Manager，Manager 再并行调用检索 Worker，最后把高风险决定交给独立审批节点。
八、上下文不是消息转发，而是权限设计
Section titled “八、上下文不是消息转发，而是权限设计”每次跨 Agent 传递内容时，至少区分四类信息：
- 任务事实：用户目标、输入数据、业务约束；
- 中间产物：检索结果、代码 Diff、草稿；
- 控制信息：预算、截止时间、重试次数、状态版本；
- 信任信息：内容来源、是否已验证、允许的用途。
一个来自网页的字符串不能因为进入了 Agent 消息，就自动升级成系统指令。一个 Worker 的“我已完成”也不能直接成为终态证据。
最小交接格式可以是：
{ "task_id": "research-03", "artifact_ref": "sha256:...", "claims": [], "evidence": [], "status": "ready_for_review", "permissions_used": ["web.read"], "next_owner": "editor"}结构化交接让消息能做 Schema 校验、版本检查和权限审计。
九、失败、重试和终止必须由系统定义
Section titled “九、失败、重试和终止必须由系统定义”多 Agent 常见的死循环是：Worker 说资料不足，Manager 让它继续；Worker 返回相同结果，Manager 再次重试。
每个节点至少需要：
- 最大尝试次数；
- 绝对或相对截止时间；
- 可重试错误集合；
- 幂等键；
- 局部失败是否允许整体降级；
- 明确的
success / failed / needs_human / partial终态。
重试应该针对可恢复的节点，不是让全体角色从头复述。产生副作用的工具还要先查询真实状态，避免重复发送、扣款或提交。
十、真实实验：并行 Worker 与私有上下文
Section titled “十、真实实验：并行 Worker 与私有上下文”本讲的 orchestration_patterns.py 使用 Python 标准库 ThreadPoolExecutor 同时运行三个 Worker：课程、协议和可靠性。
每个 Worker 只保留 100 单位私有上下文，Manager 保留 150 单位共享上下文。结果估算总量为 450；如果三个 Worker 都复制 400 单位完整共享历史，则为 1200。
{ "pattern": "parallel_workers_with_manager", "estimated_total_context_units": 450, "naive_shared_history_units": 1200, "terminal": "success"}完整运行结果见 experiment-result.json。
这个数字只是教学模型，不是 Token Benchmark。实验要说明的是：并行本身不保证节省上下文，私有上下文加结构化汇总才产生隔离收益。
十一、20：40 分钟扩展实践
Section titled “十一、20：40 分钟扩展实践”把实验中的一个 Worker 改成超时失败，再实现两种策略：
fail_fast：任一关键 Worker 失败，整体进入failed；allow_partial：保留成功分支，输出缺失清单，进入partial。
然后给每个 Worker 增加 task_id 和 attempt，验证相同任务重试不会生成两个汇总项。最后故意让两个 Worker 对同一事实给出相反结论，要求 Aggregator 保留双方证据，而不是自行拼成一个模糊答案。
这组练习能直接暴露编排系统最重要的三个问题：局部失败、重复执行和结论冲突。
十二、这一讲的结论
Section titled “十二、这一讲的结论”Manager 解决统一所有权，Handoff 解决专业会话接管，并行解决独立子任务的时延，群聊解决受约束的观点交互，图与事件流则把复杂组合变成可检查状态。
选择模式时，先问控制权在哪里、上下文怎样裁剪、失败由谁承担。不要从“想要几个角色”开始。
下一讲讨论工具生态的标准接口 MCP。它不是多 Agent 协议，而是让应用怎样以一致方式发现、读取和调用外部能力。
[1] OpenAI, Agent orchestration. https://openai.github.io/openai-agents-python/multi_agent/
[2] Microsoft, Agent Framework Orchestrations. https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/
[3] CAMEL, Societies. https://docs.camel-ai.org/key_modules/societies
[4] CAMEL, Workforce. https://docs.camel-ai.org/key_modules/workforce
[5] LangChain, Multi-agent systems. https://docs.langchain.com/oss/python/langchain/multi-agent
[6] CrewAI, Flows. https://docs.crewai.com/concepts/flows