课 1 · Multi-Agent 设计模式

本课目标

掌握三种 Multi-Agent 协作模式：编排型、委托型、对等型，理解角色分工原则。课后你会清楚什么场景需要多 Agent、以及怎么设计协作关系。

这一课默认要求你先真正吃透 Boss-Worker。Pipeline 和 Joint Discussion 也会讲，但当前更重要的是知道它们分别适合什么问题，不要求这节课就全部实现。

到目前为止，我们做的都是"一个 Agent 干所有事情"。但当任务变复杂，一个 Agent 的局限就暴露了。

所以这节课的目标不是把三种模式都硬背下来，而是建立一个判断框架：什么时候单 Agent 够用，什么时候该拆角色，以及主线为什么先落 Boss-Worker。

为什么需要多 Agent

单 Agent 的瓶颈：

问题	表现
上下文爆炸	工具太多、指令太长，模型注意力分散，失误率上升
角色冲突	既要做研究又要做审校，两种角色的要求互相干扰
调试困难	一个 Agent 做十件事，出错很难定位到哪一步
不可扩展	新增能力就要改 System Prompt，越改越臃肿

核心思路：把一个"全能 Agent"拆成多个"专精 Agent"，各自做擅长的事，通过协作完成复杂任务。

类比团队协作：一个人又写代码又做设计又测试，不如拆成前端、设计师、测试三个角色。

三种基本模式

先给一个阅读提示：下面三种模式都会介绍，但课程主线默认先回收 编排型（Boss-Worker）。后两种更像帮助你做设计判断的对照组。

三种 Multi-Agent 模式

编排型 Boss-Worker

Boss规划 + 调度 + 汇总

Worker A

Worker B

Worker C

委托型 Pipeline

Agent 1

→

Agent 2

→

Agent 3

对等型 Joint Discussion

Agent A

Agent B

Agent C

多轮讨论，协商达成结论。

模式一：编排型（Boss-Worker）

一个 Boss Agent 负责任务拆解和调度，多个 Worker Agent 负责执行具体子任务。

用户请求
  ↓
Boss Agent（规划 + 调度）
  ├── Worker A（研究员）→ 搜索资料
  ├── Worker B（写手）→ 撰写内容
  └── Worker C（审校）→ 质量检查
  ↓
Boss Agent（汇总结果）
  ↓
最终输出

特点：

• Boss 统一调度，Worker 之间不直接通信
• Boss 有全局视角，能根据执行结果动态调整计划
• 最常用的模式，适合大多数场景

适用场景： 研究报告生成、代码审查流程、客服工单处理

模式二：委托型（Pipeline）

任务按步骤依次传递，每个 Agent 处理一个环节，输出作为下一个 Agent 的输入。

用户请求
  ↓
Agent 1（信息提取）→ 结构化数据
  ↓
Agent 2（内容生成）→ 初稿
  ↓
Agent 3（质量审查）→ 修改建议
  ↓
Agent 4（格式化输出）→ 最终结果

特点：

• 流水线，每步输出是下一步的输入
• 每个 Agent 的职责非常清晰
• 顺序固定，不灵活但可预测

适用场景： 文档翻译流水线（翻译→校对→润色）、数据处理流程

这类模式这节课先知道“什么时候它更顺手”就够了，不要求你现在就把它作为主线默认架构。

模式三：对等型（Joint Discussion）

多个 Agent 地位平等，通过讨论协商达成结论。

用户请求
  ↓
┌────── Agent A（正方）
│       Agent B（反方）
│       Agent C（主持人）
└── 多轮讨论 → 达成共识
  ↓
最终结果

特点：

• 没有明确的上下级关系
• 适合需要多角度分析的场景
• 复杂度高，需要设计好终止条件

适用场景： 辩论式分析、多专家会诊、设计评审

它更像进阶模式：适合你已经能稳定控制多角色流程之后，再去处理讨论式协作。

三种模式对比

	编排型	委托型	对等型
控制关系	中心调度	链式传递	平等协商
灵活度	高（可动态调整）	低（固定顺序）	中
复杂度	中	低	高
调试难度	中	低	高
常用场景	通用	流水线	分析决策

角色分工原则

设计 Multi-Agent 系统，核心是角色设计。几个原则：

1. 最小角色数

能两个 Agent 解决的问题，不要拆成五个。每增加一个 Agent 都增加通信成本和出错概率。

❌ 过度拆分：
  研究Agent → 大纲Agent → 写作Agent → 格式Agent → 校对Agent

✅ 合理设计：
  研究Agent → 写作Agent → 审校Agent

2. 职责不重叠

每个 Agent 有明确的职责边界，不要让两个 Agent 做同样的事情。

// 好的角色定义
const researcher = '你是研究员，只负责搜索和整理资料，不做内容创作'
const writer = '你是写手，基于研究员提供的资料撰写内容，不自行搜索'

3. 输入输出格式明确

Agent 之间传递信息，格式要标准化。

// 定义 Agent 之间的消息格式
const TaskResult = z.object({
  status: z.enum(['success', 'failed', 'need_revision']),
  content: z.string(),
  issues: z.array(z.string()).optional(),
})

4. 常用角色模板

角色	职责	典型工具
Planner	分析需求、拆解任务	无（纯推理）
Researcher	搜索、整理信息	搜索、知识库
Writer	基于资料生成内容	无（纯生成）
Reviewer	检查质量、提修改意见	无（纯推理）
Executor	执行具体操作	文件操作、API 调用

Agent 间的状态管理

多个 Agent 协作时，需要一个共享的状态来传递信息。

简单共享状态

// 用一个对象管理协作状态
interface WorkflowState {
  task: string
  plan: string[]
  results: Map<string, string>
  status: 'planning' | 'executing' | 'reviewing' | 'done'
  errors: string[]
}

const state: WorkflowState = {
  task: '写一篇关于 RAG 的技术博客',
  plan: [],
  results: new Map(),
  status: 'planning',
  errors: [],
}

消息传递

// Agent 之间通过消息通信
interface AgentMessage {
  from: string      // 发送者角色
  to: string        // 接收者角色
  type: 'task' | 'result' | 'feedback'
  content: string
}

关键原则：Agent 之间传递的是结构化数据，不是自由文本。 这样每个 Agent 知道自己收到什么、需要输出什么。

终止条件设计

Multi-Agent 系统最容易出问题的地方：无限循环。 必须设计明确的终止条件。

const MAX_ROUNDS = 5      // 最多讨论 5 轮
const MAX_REVISIONS = 3   // 最多修改 3 次
const TIMEOUT = 60_000    // 超时 60 秒

let round = 0
while (state.status !== 'done') {
  round++
  if (round > MAX_ROUNDS) {
    console.log('⚠️ 达到最大轮次，强制结束')
    break
  }
  // ... 执行协作流程
}

三种终止方式：

1. 自然终止 — 任务完成，审校通过
2. 轮次限制 — 达到最大轮次强制结束
3. 超时终止 — 超过时间限制

复杂度控制

Multi-Agent 的陷阱：为了酷而做多 Agent。 实际项目中，80% 的场景单 Agent 加几个工具就够了。

什么时候该用 Multi-Agent

信号	建议
单 Agent 的工具超过 10 个	考虑拆分
System Prompt 超过 2000 字	考虑拆分
需要多步骤且每步骤类型不同	考虑 Pipeline
需要质量把关（生成+检查）	考虑 Writer+Reviewer
任务本身就是"多角色协作"	用 Multi-Agent

Multi-Agent 和 SubAgent 的边界

前一模块讲过 SubAgent。它解决的是“把一个局部子任务安全地委派出去”。

这一模块的 Multi-Agent 解决的是“把一个复杂目标拆成多个角色协作完成”。

	模块 5 SubAgent	模块 7 Multi-Agent
目标	把局部任务委派出去	用多个角色协作完成复杂目标
结构	主 Agent + 受限子任务执行器	Boss + Researcher + Writer + Reviewer
关注点	最小授权、局部执行、结果回收	角色分工、流程编排、状态传递
适合场景	多个独立子问题	明确的研究/写作/审校流程

一个直观判断方法：

• 如果你只是想把某个检索动作单独派出去，用 SubAgent
• 如果你需要研究、写作、审校这种明确角色分工，用 Multi-Agent

什么时候不该用

• 一个工具就能搞定的事，不需要 Agent
• 工具少于 5 个且职责清晰，不需要拆分
• 没有实际的复杂度瓶颈，不要提前优化

并入基础项目

本模块能力会在基础项目 basic/project/ 中收束，当前课内 Demo 见下方运行方式。

这一课并不是把三种模式一次性全写进主线，而是先给 basic/project 定清楚设计边界：

• 主线先采用 Boss-Worker 作为第一种落地模式
• Pipeline 和 Joint Discussion 先作为模式认知与设计对照，不写成 basic/project 已完整支持
• 角色分工、状态传递、终止条件这些原则，会直接约束后面 basic/project 的实现方式

为什么先这样并入： 主线项目需要一个保留全局视角的 Boss 来做编排和收口，因此比 Pipeline 更适合先落地；同时又比对等讨论更容易控制复杂度和调试成本，所以课程先让 basic/project 回收最常用的 Boss-Worker。

本课产物

• ✅ 理解三种 Multi-Agent 模式（编排型、委托型、对等型）
• ✅ 掌握角色分工原则
• ✅ 了解状态管理和消息传递机制
• ✅ 掌握终止条件设计
• ✅ 清楚什么时候该/不该用 Multi-Agent

代码演示在 basic/examples/07-multi-agent/01-design-patterns/index.ts。它会用一条固定流程帮助你观察角色传递，更接近 Pipeline 的展示方式；但课程默认要求掌握的主线落地模式仍然是 Boss-Worker。

试试看

cd daqi-ai-agent
pnpm exec tsx basic/examples/07-multi-agent/01-design-patterns/index.ts

1. 输入一个技术主题，观察信息提取 → 大纲生成 → 质量评估三步如何按顺序传递
2. 输入 compare，对比编排型、委托型、对等型三种模式的特点，重点理解为什么主线先落 Boss-Worker
3. 尝试注释掉 stepEvaluate() 调用或修改它的评分标准，观察少了质量评估后，固定流程的结果会发生什么变化

面试追问

Q：Multi-Agent 有哪些协作模式？

三种基本模式。编排型（Boss-Worker）：中心调度，Boss 拆解任务分配给 Worker，最常用。委托型（Pipeline）：流水线，每步输出是下一步输入，适合固定流程。对等型（Joint Discussion）：平等讨论协商，适合多角度分析。

Q：如何控制 Multi-Agent 的复杂度？

最小角色数，能两个解决不用五个。职责不重叠，每个 Agent 有清晰边界。传递结构化数据，不依赖自由文本。必须设置终止条件（轮次限制、超时、自然完成），防止无限循环。

Q：Multi-Agent 和单 Agent 多工具的区别？

单 Agent 多工具：一个模型同时管理所有工具，System Prompt 里包含所有指令，适合工具少（<10）且职责相似的场景。Multi-Agent：多个模型各自管理少量工具，各有独立的 System Prompt，适合职责差异大、需要专精角色的场景。核心区别是"一个人通才" vs "团队协作"。

Q：Multi-Agent 和 SubAgent 有什么区别？

SubAgent 更像受限委派，重点是把某个局部任务隔离出去，并通过白名单保证最小授权；Multi-Agent 更像角色协作，重点是让多个专职角色按流程共同完成复杂目标。前者解决的是任务隔离，后者解决的是流程分工。