第 07 讲 | 多 Agent 怎么协作：从单兵到团队

本节我们将掌握：

• 为什么单 Agent 不够用，什么时候需要多 Agent
• 四种协作模式：路由、接力、协作评审、辩论
• 多 Agent 架构的代价和反模式
• 主流框架在 2026 年的定位和选型决策

---

单 Agent 的上限

第 03-05 讲讲了单 Agent 的范式和编排。但生产环境经常碰到单 Agent 的物理极限：

• 上下文窗口不够：一个任务要同时懂代码、懂产品、懂安全，每个领域的知识都占满窗口
• 能力混杂：擅长写代码的模型不一定擅长做安全审计；擅长创意的模型不一定擅长做数据计算
• 并行度为零：单 Agent 只能串行干活，10 个任务跑下来等半天

多 Agent 解决的就是这三个问题：拆角色、拆任务、拆并行。

但多 Agent 不是银弹——它引入了新的复杂度：通信开销、一致性保证、调试难度。

---

四种协作模式

模式	通信结构	适合场景	LLM 调用次数	复杂度
路由	星形（1→N选一）	意图分类、客服分流	1+N（N=1）	低
接力	链式（A→B→C）	多步骤流水线（如编码-检查-发布）	N	中
协作评审	并行（N→汇总）	审计、质检、多专家视角验证	N+1	中
辩论	网状（A↔B↔裁判）	开放决策（方向辩论、市场调研）、方案设计	2N+1	高

模式一：路由（Router）

用户问题 → Router（意图分类） → Agent A / Agent B / Agent C

场景：企业客服系统——用户提问后，Router 判断问题类型，路由到专项 Agent。

场景1：用户问："我的退款什么时候到账？"

── Router 节点 ──────────────────────────────────────────
LLM 分类：财务类 → 路由到 RefundAgent

── RefundAgent 处理──────────────────────────────────────────
查询订单系统 → 计算退款进度 → 生成回答
→ "您的退款 ¥299 已于昨天处理，预计 2-3 个工作日到账"

─────────────────────────────────────────────────────────

场景2：用户问："你们这个功能怎么用？"

── Router 节点 ──────────────────────────────────────────
LLM 分类：使用帮助类 → 路由到 HelpAgent

── HelpAgent 处理────────────────────────────────────────────
查产品文档 → 生成操作指引
→ "在设置页面点击右上角'高级'，然后..."

骨架代码：

代码只为想了解原理同学准备，非编程场景可不看，编码场景也有成熟框架

def router_agent(user_input):
    intent = llm.invoke(f"分类这个问题：{user_input}", categories=["财务", "技术", "使用帮助", "投诉"])
    agent = {
        "财务": RefundAgent(),
        "技术": TechAgent(),
        "使用帮助": HelpAgent(),
        "投诉": ComplaintAgent()
    }[intent]
    return agent.run(user_input)

Router 模式的关键是分类器质量。分类错了，后面 Agent 再强也没用。2026 年的最佳实践：

• 分类器用轻量模型（成本低、延迟小）
• 加一个"不确定 → 转人工"的兜底路由
• 定期用实际数据微调分类 prompt

---

模式二：接力（Pipeline）

接力执行某个流程，每个流程由一个单独的Agent负责。

Agent A 输出 → Agent B 输入 → Agent C 输入 → 最终结果

场景：自动生成技术文档——代码分析 → 提取 API → 写文档 → 校对。

── Agent 1: CodeAnalyzer ────────────────────────────────
输入：GitHub 仓库 URL
输出：{ endpoints: [...], models: [...], auth: "JWT" }

── Agent 2: DocWriter ───────────────────────────────────
输入：Agent 1 的输出
输出：Markdown 格式 API 文档初稿

── Agent 3: DocReviewer ─────────────────────────────────
输入：Agent 2 的文档 + 原始代码
输出：{ issues: ["缺少错误码说明", "示例 curl 命令缺失"], suggestions: [...] }

── Agent 4: DocFinalizer ────────────────────────────────
输入：Agent 2 的文档 + Agent 3 的反馈
输出：最终文档（合并修订） → 提交 PR

接力和第 03 讲的 Plan-and-Execute 不同：Plan-and-Execute 是一个 Agent 规划再执行；接力是不同角色的 Agent 各司其职，每个 Agent 的输入就是上一个的输出。

这种模式的威力在于：每个 Agent 可以配不同的模型和提示词。Analyzer 用强推理模型，Writer 用强写作模型，Reviewer 用强批判模型——成本和质量都最优。

---

模式三：协作评审（Peer Review）

       ┌→ Agent A ──┐
Input ─┼→ Agent B ──┼→ Aggregator → 最终结果
       └→ Agent C ──┘

场景：一篇 AI 生成的"Cursor vs Windsurf 竞品分析"文章，发布前审核。

输入：AI 生成的一篇"Cursor vs Windsurf 竞品分析"文章

── Agent A（数据核对员）───────────────────────────
发现："Windsurf 月活约 80 万"无来源
未发现：文章没有提到定价差异

── Agent B（结构编辑）────────────────────────────
发现：没有结论段，缺少明确的推荐建议
未发现：数据无来源

── Agent C（读者代表）────────────────────────────
发现：全文只对比了功能，没有对比上手难度和学习曲线
未发现：结构不完整、数据无来源

── Aggregator 汇总 ────────────────────────────────────
合并 3 个独立发现 → 输出修订清单：
  1. [高] 补充数据来源或移除无来源数据
  2. [高] 增加明确的结论和推荐建议
  3. [中] 补充上手难度和学习曲线对比

协作评审的核心优势是视角多样性。不同角色看到不同风险，比单 Agent 审一遍覆盖更广。

代价：每个 Agent 都要调一次 LLM，成本成倍涨。

---

模式四：辩论（Debate）

Agent A（正方）←→ Agent B（反方）←→ Judge Agent（裁判）

场景：为某媒体撰写"2026 年轻人职业选择趋势"报告的核心章节——"留在大城市还是回老家"。

议题：30 岁程序员要不要从北京回老家成都？

── Round 1 ──────────────────────────────────────────
正方（留在大城市）: "北京的机会、薪资、成长空间，成都给不了。跳槽选择多 10 倍"
反方（回老家）: "北京房价是你年薪的 8 倍。成都生活质量高，幸福感更重要"

── Round 2 ──────────────────────────────────────────
正方: "30 岁正是职业上升期，回去后再出来就断了"
反方: "北京卷到 40 岁还是得回。成都现在 IT 机会也不少，远程工作也是趋势"

── Judge Agent ──────────────────────────────────────
输入：正方论点 + 反方论点 + 决策框架
推理：
  1. 评估正反方核心论据 → 正方强在职业发展，反方强在生活成本
  2. 识别双方盲区 → 都没提到远程工作对决策的影响
  3. 应用决策框架 → 按用户目标函数分类
输出裁决：
  目标=快速成长+存钱 → 留大城市 3-5 年
  目标=生活平衡 → 回老家
  补充建议：远程工作可兼得两者

辩论模式适合没有标准答案的开放决策。比 ToT 打分更可靠，因为正反方被迫找对方的真实漏洞，而不是自说自话地给自己打分。

代价最大：N 轮辩论 = 2N+1 次 LLM 调用。

---

框架选型：2026 年的格局

这里的"框架"指的是生产 Agent 框架（LangGraph、CrewAI 等），和客户端 Agent 应用（Claude Code、Cursor 等）不是同一个东西。客户端应用是开箱即用的工具，生产框架是编排底座。

框架	哲学	多 Agent 能力	核心特点
LangGraph	"状态机就是一切"	状态图编排	生产最可靠，状态机控制力最强，但学习曲线陡
CrewAI	"角色+流程"	角色+任务+过程	API 最干净，最快从想法到多Agent系统
模型厂商原生 SDK（如 OpenAI SDK）	"轻量够用"	Handoff（交接）机制	轻量级，Agent 之间通过 Handoff 转移控制权
AG2（原 AutoGen）	"聊起来再说"	多Agent对话协作	灵活度最高，研究场景用得多，工业落地相对少
Microsoft Agent Framework	"企业统一"	企业级统一	统一 AutoGen + Semantic Kernel，支持插件、记忆、多模型协同

选型信号：

• 生产级复杂工作流 + 多 Agent 协作 → LangGraph
• 快速验证多 Agent 想法 → CrewAI 或模型厂商原生 SDK
• 研究型场景（论文、实验） → AG2
• 已有微软技术栈 → Microsoft Agent Framework

---

多 Agent 的代价

时间成本（⭐）

每多一个 Agent，就多一次上下文切换、一次LLM调用，一次网络延迟，还有信息传递和最终的信息综合。接力模式里 4 个 Agent 串行，耗时最少是单 Agent 的 4 倍。

降低时间成本手段：

• 多个任务间并行——执行任务1的Step2和任务2的Step1同时进行。

• 简单步骤切换更快的模型，如“锦囊项目可行性验证平台，把项目名称总结，生成项目简报，切换为DeepSeek-V4-Flash”

  注意，对于时间不敏感场景，正确比省时更重要(比如研究型场景，得到正确的结果比快重要的多)。

成本（⭐）

同等复杂任务，多 Agent = 多倍 Token + 中间消耗（上下文分发、Agent沟通、决策）。一个 3-Agent 协作评审场景，Token 消耗最少是单 Agent 的 3-5倍。降本手段：

• 路由：固定选项场景用规则匹配（如80%走硬编码的规则，20%由LLM处理），分类器用轻量模型。
• 接力：执行步骤用便宜模型；简单任务跳过重度步骤（如”快速分析”跳过”深度搜索”步骤）。
• 辩论：设置最大轮数（通常 3 轮够了），如果还有分歧，由决策模型/用户统一收尾。

一致性保证

大部分生产任务，尤其是接力场景，关键信息传递场景，Agent 间的接口基本要用结构化 Schema 约束（JSON Schema），不用纯文本传话。

但是研究型的多Agent，如”辩论”匹配的场景，”思维发散”的场景，”研发过程”这种比较灵活的场景，自然语言文本交互是很正常，而且很有必要的。这时候”一致性保证”更多的来自决策机制以及前期的约束。

调试难度

最主要是能够绑定请求ID和Agent ID。日志会多一点，分散的时间范围更久一点。如果不使用框架，那么就自己多加详细日志进行区分。如果使用框架，LangGraph 的 LangSmith 和 W&B Weave 提供执行轨迹可视化，是成熟的方案。

---

多 Agent 的五种核心机制

单 Agent 不用想这些，多 Agent 一上就得面对。用一句话概括：多 Agent 比单 Agent 多出来的复杂度不在 prompt 层面，而在通信、协调、仲裁、并发——和分布式系统是同一个量级。

通信协议（Communication Protocol）

Agent A 怎么跟 Agent B 说话？自然语言自由聊？还是结构化 JSON 模式？

• 自然语言流（AutoGen 默认）：灵活，但解析费、容易跑偏
• 结构化协议（ACL 风格 / 自定义模式）：A 的输出严格按 {role, intent, payload} 封包，B 按模式解。稳但僵化。
• 现在主流折中：关键交接用结构化模式，自由讨论用自然语言

消息队列（Message Queue）

N 个 Agent 同时说话，谁先谁后？B 发两条消息 A 是按顺序收还是乱序？

每个 Agent 挂一个收件箱（inbox），框架层用队列（Queue）解耦。AutoGen 的群聊（GroupChat）是广播 + 轮次管理；CrewAI 是顺序交接不走队列。

冲突仲裁（Conflict Resolution）

三个 Agent 两个说”选方案 A”一个说”选 B”，听谁的？

策略	说明
多数投票	最简单，但不论据质量
仲裁 Agent	让第四个 Agent 当裁判，看论据质量不是看人数
置信度加权	谁的历史准谁权重高
人仲裁	高风险场景

并发控制（Concurrency）

10 个 Agent 同时调 LLM，会碰到三个问题：触发频率限制、Token 成本飙升、上下文互相竞争。

做法：Agent 级信号量、LLM 调用池化、对高耗 Agent 限并发数。

结果汇总（Aggregation）

N 个 Agent 各干各的，最后一棒怎么收？

模式	说明
汇总 Agent	专门一个 Agent 读所有人输出，合成最终答案
牵头 Agent 收口	编排器模式里牵头 Agent 自己汇总
投票/共识	debate 场景常见

💡 一句话总结：多 Agent 的复杂度不在 prompt，而在通信、消息、仲裁、并发、汇总——和分布式系统是同一个量级。这五个机制就是”为什么多 Agent 听着酷但落地难”。

另外，很多时候，框架（LangGraph、CrewAI 等）已经兜住了这些机制的实现——我们不用自己写消息队列、信号量、仲裁逻辑。但框架不帮我们做设计决策——Agent 怎么分工、交接用什么协议、分歧听谁的。框架兜住了”怎么做”，但”做什么”、”怎么选”就需要了解机制之后由人来做决策。

---

研发过程视角：多 Agent 就是我们的代码审查小组

详见第 03 讲（Agent 核心范式）至第 05 讲（编排与工作流）中 Superpowers 的工程纪律。从多 Agent 的视角看，Superpowers 的 Review 阶段本质上就是协作评审模式：

Superpowers 审查轮	对应的多 Agent 模式	审查重点
Spec 合规审查	Agent A（审计员角色）	实现是否覆盖了规格中的所有需求
代码质量审查	Agent B（架构师角色）	代码结构、可维护性、设计模式
安全审查	Agent C（安全专家角色）	注入、权限、数据泄露

我们用 Claude Code 跑 Superpowers 时，三个审查轮依次执行——这正是模式三（协作评审）的工程化实现。

Russell经验⭐：多 Agent 不只是”为用户造产品”的架构，它也是我们自己研发工具链的核心。

---

选型决策

架构师决策清单：

• 意图明确 + 专项处理 → 路由模式。客服、工单分类。
• 多步骤流水线 → 接力模式。每步可以配不同模型，成本最优。
• 需要多角度验证 → 协作评审模式。审计、质检、代码审查。
• 开放决策无标准答案 → 辩论模式。架构选型、方案设计。
• Agent 间接口 → 关键交接用结构化 Schema（JSON Schema / Pydantic），自由讨论可用自然语言。
• 五种机制必配：通信协议、消息队列、冲突仲裁、并发控制、结果汇总——复杂度不在 prompt，而在协调。
• 拍板点：能单 Agent 搞定就别多 Agent。符合多Agent的场景也不要不舍得。

---

面试回答要点

Q：多 Agent 协作有哪些模式？怎么选？

答（抓结构 + 讲代价）：

四种基本模式——

• 路由：意图分类后分发到专项 Agent。适合客服分流。成本最低。关键是分类器质量。
• 接力：A 输出 → B 输入 → C 输出。适合流水线任务。每步可配不同模型，成本最优。延迟是 Agent 数的倍数。
• 协作评审：N 个 Agent 独立处理同一输入后汇总。适合审计、代码审查。覆盖最广，但 Token 成本 N 倍。
• 辩论：正反方多轮交锋后裁判裁决。适合开放决策。代价最大（2N+1 次 LLM 调用）。

选型原则：能单 Agent 就别多 Agent。符合多Agent的场景也不要不舍得。复杂度不在 prompt，而在协调。

深度追问：

• "多 Agent 通信怎么保证一致性？" → 关键交接用结构化 Schema（JSON Schema / Pydantic），自由讨论可用自然语言。通信协议、消息队列、冲突仲裁、并发控制、结果汇总，这五个机制就是"为什么多 Agent 听着酷但落地难"。
• "多 Agent 调试困难怎么办？" → 绑定请求ID和Agent ID，多加详细日志。如果用框架，LangSmith 或 W&B Weave 提供执行轨迹可视化。

---

小结

1. 四种协作模式：路由（分发）、接力（流水线）、协作评审（多视角验证）、辩论（开放决策）
2. 多 Agent 的价值：拆角色、拆任务、拆并行，突破单 Agent 的上下文和能力上限
3. 五种核心机制：通信协议、消息队列、冲突仲裁、并发控制、结果汇总——复杂度不在 prompt，而在协调
4. 2026 年框架格局：LangGraph（生产可靠）、CrewAI（快速上线）、模型厂商原生SDK（轻量入门）

---

思考题

1. 我们要设计一个"自动生成竞品分析报告"的多 Agent 系统。任务包括：搜索竞品信息 → 提取关键数据 → 生成对比表格 → 撰写分析结论 → 质量审核。我们会用哪种协作模式？每个 Agent 该配什么模型？预估 Token 成本是单 Agent 的几倍？

2. 我们的路由型多 Agent 系统上线后，用户反馈"经常答非所问"。排查发现分类器把 30% 的技术问题路由到了客服 Agent。从架构层面，我们会怎么优化这个系统？（提示：分类器升级、兜底机制、反馈闭环各是一种思路）