跳到主要内容

多 Agent 系统设计

单 Agent 能解决很多问题，但系统一旦变复杂，很快就会出现一个新问题：

是不是应该拆成多个 Agent。

这件事常被理解成能力升级，但本质上是架构选择。

拆成多个 Agent 之后，系统往往会同时得到：

  • 更清晰的职责边界
  • 更复杂的协作开销
  • 更高的观察与治理要求

这一页主要回答 6 件事：

  • 多 Agent 系统什么时候值得做
  • 常见的多 Agent 结构有哪些
  • Handoff / Agents as Tools / Workflow / Crew / A2A 分别适合什么问题
  • 多 Agent 系统最容易失控的地方在哪里
  • 第一版设计时最该先定什么
  • 在这个模块里，多 Agent 应该接在哪些章节后面去学

1. 多 Agent 不是默认答案​

可以先把核心判断放在前面：

单 Agent 能解决的问题，通常不要急着拆成多 Agent。

原因很直接。

一旦进入多 Agent，系统就会多出这些额外复杂度：

  • 角色划分
  • 协作协议
  • 状态传递
  • 失败恢复
  • 观察与评估
  • 成本与延迟放大

所以多 Agent 的价值，不在于“看起来更高级”，而在于：

单 Agent 已经不足以清晰承载任务边界。

2. 什么时候值得考虑多 Agent​

2.1 任务天然可以拆成稳定角色​

例如：

  • 调研
  • 规划
  • 执行
  • 审核

如果这些角色本身边界比较稳定，拆成多个 Agent 会更自然一些。

2.2 一个 Agent 需要频繁切换不同工作模式​

例如同一个系统既要：

  • 做问题分流
  • 处理专业领域推理
  • 执行高风险动作
  • 做最后复核

把所有逻辑都塞进一个 Agent，提示和上下文很容易膨胀。

2.3 下游能力已经是独立服务​

如果某些能力本来就是独立 Agent 服务，系统设计自然会更接近多 Agent。

2.4 协作过程本身就需要显式观察​

例如：

  • 谁负责决策
  • 谁负责执行
  • 谁负责审批
  • 谁负责最终输出

如果这些边界需要显式审计和回溯，多 Agent 通常会更清楚一些。

3. 什么时候不值得拆​

3.1 只是想让系统看起来更智能​

这是常见误区之一。

很多场景里，真正需要的只是：

  • 单 Agent + tools
  • 或 workflow + 少量模型步骤

3.2 角色只是提示词差异，没有真正边界​

如果所谓“多个 Agent”本质上只是：

  • 换个名字
  • 换段 prompt
  • 用同样工具
  • 读同样上下文

那通常还没到值得拆的程度。

3.3 当前连单 Agent 都还没跑稳​

单 Agent 的停止条件、状态、工具选择都还没稳定时，直接上多 Agent 往往只会把问题放大。

4. 常见的多 Agent 结构​

4.1 Triage + Specialist​

这是最常见、也最容易上手的一种结构。

结构是：

  • 一个总控或分流 Agent
  • 多个专长 Agent

适合：

  • 客服
  • 问题分流
  • 多领域问答

4.2 Manager + Workers​

结构是：

  • 一个 manager 负责拆任务和汇总
  • 多个 worker 执行子任务

适合：

  • research
  • 分工明确的长任务
  • 并行子问题处理

4.3 Reviewer / Approver Pattern​

结构是：

  • 执行 Agent 负责做事
  • 审查 Agent 或人工节点负责复核

适合：

  • 高风险动作
  • 文档生成
  • 合规审查

4.4 Workflow-wrapped Multi-Agent​

结构是：

  • 多个 Agent 作为 workflow 里的节点
  • 执行路径由 graph 或 flow 控制

适合：

  • 多步骤业务流程
  • 明确的条件分支
  • 需要 checkpoint / resume 的任务

5. 几种常见协作方式分别适合什么​

5.1 Handoff​

最适合：

  • 一个 Agent 判断谁应该接手
  • 接手后由下一个 Agent 主导后续对话

这类模式在 OpenAI Agents SDK 里很典型。官方 handoffs 文档明确把它定义成“一个 agent delegate part of a conversation to another agent”。

5.2 Agents as Tools​

最适合：

  • 主 Agent 仍然掌控流程
  • 下游 Agent 只是一个被调用的专长能力

这种模式通常更稳，也更容易把复杂度控制在单条运行链里。

5.3 Workflow Orchestration​

最适合：

  • 多 Agent 只是执行节点
  • 流程顺序、并发、分支需要显式控制

这类模式在 LangGraph、Microsoft Agent Framework Workflows、CrewAI Flows 里都不少见。

5.4 Crew / Team / Group Chat​

最适合：

  • 希望显式表达多角色协作
  • 多个 Agent 会围绕同一目标互动

这类模式表达力强，但控制难度也更高。

5.5 A2A​

最适合：

  • 下游对象已经是独立 Agent 服务
  • 需要跨系统协作
  • 需要任务状态、产物和异步更新

6. 多 Agent 系统最容易出问题的地方​

6.1 角色边界不清​

如果多个 Agent 都能做差不多的事，系统很快就会出现：

  • 路由混乱
  • 上下文重复
  • 相互覆盖

6.2 责任链不清​

很多系统能跑，但很难说清：

  • 谁做了最后决策
  • 谁发起了写操作
  • 谁负责最终输出质量

6.3 状态传递失控​

多 Agent 一旦共享：

  • 历史
  • 中间结果
  • memory
  • 检索材料

很容易出现上下文膨胀与污染。

6.4 延迟和成本成倍放大​

多 Agent 常见副作用是：

  • 步数变多
  • 模型调用变多
  • 工具调用变多
  • 观察和调试成本变高

6.5 评估变难​

单 Agent 时只要看：

  • 是否答对
  • 是否调对工具

多 Agent 时还要看：

  • 路由对不对
  • 协作链有没有多余步骤
  • 哪个 Agent 拉低了成功率

7. 第一版多 Agent 设计最该先定什么​

7.1 先定角色，而不是先定框架​

先回答：

  • 这个角色为什么必须独立
  • 独立后上下游边界是什么
  • 不独立会出现什么问题

7.2 先定协作方式​

至少要明确：

  • handoff
  • as tool
  • workflow node
  • remote agent via A2A

到底是哪一种。

7.3 先定状态和上下文交接规则​

包括：

  • 谁能看到全部历史
  • 谁只看摘要
  • 谁拿到工具结果
  • 哪些内容不能跨角色传递

7.4 先定停止与升级条件​

例如：

  • 什么时候路由给 specialist
  • 什么时候回到 manager
  • 什么时候转人工
  • 什么时候任务失败

8. 一个很实用的演进顺序​

一个更稳的顺序是：

  1. 单 Agent 跑通主任务
  2. 找出最稳定的专长边界
  3. 先拆成 triage + specialist
  4. 再决定是否需要 workflow 化
  5. 最后才考虑跨系统 A2A

这个顺序的好处是：

  • 先把复杂度压住
  • 再按真实边界拆分
  • 避免一开始就进入全栈多 Agent

9. 和这个专题里的哪些内容最该一起看​

最适合一起看的有：

10. 小结​

多 Agent 最有价值的地方，不是让系统显得像团队协作，而是把真实存在的职责边界显式化。

一个更稳的判断标准是：

  • 单 Agent 是否已经承载过多角色
  • 协作是否真的需要分开观察、分开治理
  • 下游能力是否已经是独立协作者，而不只是一个工具

如果这些问题都已经开始出现，多 Agent 才值得认真设计。