3.2 多智能体协作与工作流
3.2 多智能体协作与工作流
本节摘要：一个智能体解决不了的任务，交给"团队"。本节讲清多智能体协作的核心机制——Handoffs（交接），以及三种协作模式（交接、并行、分层），并用"客服团队"示例展示工作流设计。
学习目标
阅读完本节，你应当能够：
- 解释 Handoffs 机制
- 区分三种协作模式
- 设计客服团队工作流
- 管理协作中的上下文
- 判断何时需要多智能体
一、问题与直觉
"智能体又要懂产品、又要懂物流、又要懂售后"——一个 Agent 的指令会越来越长、每样都做不深。多智能体的解法是分工：每个 Agent 只管一件事，搞不定就"交接"给合适的同事。Handoffs 就是"交接棒"机制。
为什么要交接而不是让一个 Agent 全干？三个现实理由。第一，指令质量：单一 Agent 指令越长，模型越容易"顾此失彼"；拆开后每个 Agent 的指令短而专注。第二，工具隔离：物流 Agent 只需要物流工具，不必把订单、售后工具全塞给它，减少选错概率。第三，可维护性：改售后逻辑只动售后 Agent，不影响其他部分。
二、核心原理
2.1 Handoffs 交接机制
Agent 通过 handoffs 声明"我能交接给谁"，模型根据对话内容自动决定是否交接——分工靠定义，交接靠模型判断。
2.2 三种协作模式
交接模式适合"职责分域"；并行模式适合"一次查多个数据源"；分层模式适合"主管分派、专员执行"的团队结构。
三、工程实践要点
3.1 客服团队工作流
from agents import Agent, Runner 前台 = Agent( name="前台", instructions="判断用户问题归属，需要时交接给对应专员。", handoffs=["产品专员", "物流专员", "售后专员"], # 概念示意 ) 产品专员 = Agent(name="产品专员", instructions="只回答产品功能与使用问题。") 物流专员 = Agent(name="物流专员", instructions="只查询物流状态，不回答其他。") 售后专员 = Agent(name="售后专员", instructions="处理退换货与投诉，语气安抚。") result = Runner.run_sync(前台, "我的包裹到哪了？") print(result.final_output)
3.2 协作上下文管理
交接时带上：对话历史 + 用户意图 避免：每个 Agent 都重复问用户 设计：前台负责收集信息，专员负责处理
多智能体最容易出现的体验问题是"换人失忆"：用户刚跟前台说完订单号，转到物流专员又得重说一遍。解决方案是把已收集的信息显式传入上下文，交接时一并带上——让用户觉得"团队内部信息是通的"。
💡 关键直觉：多智能体的核心收益是"职责清晰"——每个 Agent 的指令更短更专注，行为更可控。代价是上下文传递的复杂度，任务简单时别硬拆。
3.3 何时需要多智能体
| 场景 | 判断 |
|---|---|
| 一个 Agent 指令太长 | 该拆 |
| 职责天然分域 | 适合多 Agent |
| 任务简单 | 别拆 |
⚠️ 常见坑：为多而多。多 Agent 有交接开销与上下文成本——"一个 Agent 能搞定"时，多智能体是负优化。拆之前先问：指令真的长到管不过来了吗？
⚠️ 常见坑：交接条件写得含糊。模型靠指令判断何时交接，"用户提到物流就交接"比"视情况而定"可靠得多——交接规则要写成可判定的条件。
3.4 多智能体的成本与取舍
多智能体不是免费的。每个交接都是一次额外的模型决策，多一次延迟与 token 消耗；每个 Agent 都要维护指令和工具，配置成本线性增长；协作链路越长，出问题的点越多，排错难度越大。所以在设计时先问三个问题：职责是否真的分域？每个 Agent 的指令是否真的会变短？交接带来的延迟用户是否接受？三个都答"是"再拆。一个实用的中间方案是"单 Agent + 多工具"，让一个 Agent 用工具区分能力域，多数场景已经够用，复杂度却低得多。
本节速览
- 要点一：Handoffs 是交接棒，模型判断何时交接
- 要点二：三模式——交接、并行、分层
- 要点三：客服团队是最典型的多 Agent 场景
- 要点四：交接要带上下文，别重复问用户
- 要点五：核心收益是职责清晰
- 要点六：任务简单别硬拆，交接条件要明确
会分工了，下一节守边界——安全与合规 Guardrails。回顾本节，请记住：多智能体的本质是"用职责清晰换协作开销"，拆与不拆的决策，永远从业务需求出发。