多 Agent 系统有哪些协作模式?什么时候需要多 Agent?
一句话回答
常见的协作模式有四种:主管模式(主 Agent 拆分任务、分派给多个工作 Agent、汇总结果)、流水线(按固定顺序交给不同的 Agent 处理)、评审或辩论(一个生成一个挑错,或者多个 Agent 各自给出意见再裁决)、交接(handoff,把对话的控制权整个转给另一个 Agent)。多 Agent 的好处是上下文隔离、并行、专业分工;代价是 token 成本成倍增加,协调和调试都更难,信息在 Agent 之间传递时还会丢失。能用单 Agent 加工具解决的,就不要上多 Agent。
详细解析
四种协作模式
主管模式: 主 Agent(拆分任务)
↙ ↓ ↘
调研 A 调研 B 调研 C (并行,各自只返回精简的结论)
↘ ↓ ↙
主 Agent(汇总)
流水线: 需求分析 Agent → 编码 Agent → 测试 Agent
评审: 生成 Agent ⇄ 评审 Agent(不通过就带着意见重写,设轮数上限)
交接: 分诊 Agent ──退款问题──→ 退款 Agent(之后由它直接和用户对话)
| 模式 | 适合 | 注意 |
|---|---|---|
| 主管模式 | 能拆成独立子任务的工作,如多个方向同时调研 | 子任务描述要写清,避免重复劳动和遗漏 |
| 流水线 | 阶段固定的处理流程 | 本质上接近工作流,前一步的错误会传到后面 |
| 评审或辩论 | 质量要求高、评判标准说得清的任务 | 评审标准要具体,设置轮数上限 |
| 交接 | 按领域路由对话,如客服分诊 | 交接时带上必要的上下文,原 Agent 不再参与 |
一些框架把交接作为内置概念,例如 OpenAI Agents SDK 里的 handoff。
好处
- 上下文隔离:子 Agent 在自己的上下文里搜索、阅读大量资料,只把结论交回去,主 Agent 的上下文保持干净。这是多 Agent 最实在的收益
- 并行:互不依赖的子任务同时进行,缩短总耗时
- 专业分工:每个 Agent 有自己的提示词、工具集和权限,工具少了选得更准;简单的子任务可以交给更便宜的模型
代价
- token 成倍增加:每个 Agent 都有自己的上下文,背景信息要重复提供,结果还要再汇总一遍
- 协调难:任务拆得不好会重复劳动、互相冲突,比如两个 Agent 同时改同一个文件
- 信息丢失:子 Agent 看不到完整对话,主 Agent 看不到子 Agent 的过程,关键细节可能在传递中丢掉
- 调试难:出了问题要在多条轨迹之间定位,每个 Agent 的随机性也会叠加
什么时候需要多 Agent
适合的情况:任务能拆成互相独立的部分;需要大量阅读和探索,一个上下文装不下;不同部分需要不同的工具和权限。
不适合的情况:子任务之间紧密耦合、需要共享大量上下文。比如大多数写代码的任务,改动之间互相依赖,拆给多个 Agent 反而容易冲突。
建议的路径:先把单 Agent 加工具做好;遇到上下文装不下、或者可以并行的子任务时,再把这部分拆给子 Agent。
代码示例
把子 Agent 包装成一个工具,是实现主管模式最简单的方式。runAgent 是一个完整的 Agent 循环(参考 手写一个最小的 Agent 循环),这里假设它可以传入系统提示、工具和步数上限:
const delegateResearch = {
name: 'delegate_research',
description:
'把一个独立的调研子任务交给调研子 Agent,返回它的结论。子 Agent 看不到当前对话,task 里要写清目标、范围、已知信息和期望的输出格式。互不依赖的多个子任务可以在同一轮里并行调用。',
parameters: {
type: 'object',
properties: { task: { type: 'string', description: '完整、独立的任务描述' } },
required: ['task'],
},
async execute({ task }: { task: string }) {
// 子 Agent 有独立的消息列表、工具集和预算,只有最终结论返回给主 Agent
return runAgent({
system: '你是调研助手。只根据检索到的资料回答,结论控制在 300 字以内,并列出来源链接。',
input: task,
tools: [webSearch, fetchPage],
maxSteps: 15,
})
},
}
主 Agent 在同一轮里发起多个 delegate_research 调用时,就是并行的主管模式,执行方式见 并行工具调用。
面试官可能追问
子 Agent 之间怎么共享信息?
尽量通过主 Agent 中转:在任务描述里给出必要的背景。结果比较大时写到共享存储(文件、数据库),只回传路径或 ID 加一段摘要,避免长内容在 Agent 之间反复转述、越传越走样。子 Agent 之间尽量不要直接通信,否则协调的复杂度会迅速上升。
交接(handoff)和主管模式有什么区别?
主管模式下控制权一直在主 Agent 手里,子 Agent 做完把结果交回来。交接则是把对话本身转给另一个 Agent,之后由它直接面对用户,原来的 Agent 退出。主管模式适合拆分任务,交接适合按领域路由对话。
多 Agent 系统怎么调试和评估?
每个 Agent 的每次调用都记录成链路里的一个节点,能看出谁在什么时候收到了什么、返回了什么,见 怎么给 LLM 调用链做链路追踪。先单独评估每个子 Agent,再做端到端评估,还要和单 Agent 方案对比效果和成本,证明拆分确实值得。
多个 Agent 并行修改同一个代码仓库,怎么避免冲突?
按文件或模块划清边界;让每个 Agent 在独立的工作副本里修改(比如 git worktree),最后再合并;或者只把调研、阅读这类只读工作并行化,写代码仍由一个 Agent 完成。
易错点
- 为了显得高级而上多 Agent,单 Agent 能做好的事拆开后成本更高、效果更差
- 给子 Agent 的任务描述太简略,忘了它看不到主对话
- 照搬人类团队的分工(产品经理、程序员、测试)硬拆角色,信息在层层交接中不断损耗
AI 模拟面试官
用自己的话回答,AI 对照参考答案打分、指出遗漏,再追问,最多 3 轮
这道题你掌握了吗?
选一个最接近的状态,没掌握的题会出现在"我的进度 · 待复习"里。
学习记录暂存在本机浏览器。登录后自动同步到账号,换设备也能看到。