第6章：多 Agent 协作与编排

本章解决的核心问题：一个 Agent 不够用怎么办？多个 Agent 怎么分工、怎么通信、怎么防止互相踩脚？流水线、并行、辩论——这三种协作模式分别在什么场景下用？

读完这一章，你会理解多 Agent 系统的设计逻辑——从两三个 Agent 的小作坊到上百个 Agent 的生产线。

6.1 为什么一个 Agent 不够

🎨 漫画图解：〈一只小狗读不完一百本书〉

单一 Agent 有三个绕不过去的天花板：

天花板一：上下文窗口

第2章说过，Agent 的短期记忆（上下文窗口）是有限且昂贵的。一个复杂任务——比如「分析 GitHub 上这个开源项目的全部代码并写一份架构文档」——可能涉及几百个文件、几万行代码。一个 Agent 的上下文根本塞不下。

类比：一个人可以读完一本 100 页的书并写总结。但让一个人读完 100 本书并写总结——要么他花一年时间，要么你找 10 个人各读 10 本，最后汇总。

天花板二：单线程效率

很多任务的子步骤是相互独立的，可以并行处理。但单一 Agent 只能串行——因为它只有一个「大脑」，一次只能想一件事。

你要写一份报告，其中需要分析三份不同的数据。单一 Agent 会一份一份地分析，花 3 倍时间。三个 Agent 可以同时分析，花 1 倍时间。

天花板三：技能带宽

一个 Agent 可能擅长写代码，但写不好 PPT。一个 Agent 可能擅长分析法律文本，但不擅长翻译诗歌。虽然底层用的是同一个大模型，但不同的 System Prompt、不同的工具集、不同的训练微调会让 Agent 表现出截然不同的「专长」。

让一个 Agent 什么都会 = 什么都不精。让多个 Agent 各司其职 = 整个系统更强。

6.2 多 Agent 的三种协作模式

🎨 漫画图解：〈三种组队战术〉

多 Agent 协作的方式可以归结为三种基本模式，所有花样都是这三种的变体或组合：

mindmap
  root((多 Agent 协作模式))
    流水线 Pipeline
      顺序执行
      A的输出是B的输入
      适合：有明确流程的任务
      例子：调研→写作→审校
    并行 Parallel
      同时执行独立子任务
      结果汇总
      适合：可分解的任务
      例子：分析三个数据源
    辩论 Debate
      多个Agent互审
      对抗性验证
      适合：高风险决策
      例子：代码审查、安全审计

6.3 流水线模式（Pipeline）

🎨 漫画图解：〈流水线接力赛〉

核心思想

A 干完 → B 拿到 A 的结果继续干 → C 拿到 B 的结果继续干。

示意图

flowchart LR
    Input[📥 原始任务] --> Agent1[🤖 研究 Agent
搜集资料]
    Agent1 -->|研究报告| Agent2[🤖 写作 Agent
撰写初稿]
    Agent2 -->|初稿| Agent3[🤖 审校 Agent
检查事实与逻辑]
    Agent3 -->|修改意见| Agent2
    Agent3 -->|定稿| Output[📤 最终产出]

典型场景

写一份行业分析报告：

优点

• 逻辑清晰：每一步做什么、输入什么输出什么——一目了然。
• 易于调试：哪个环节出了问题，直接看那个 Agent 的输入输出。
• 每个 Agent 可以针对自己的环节做专门优化。

缺点

• 串行瓶颈：最慢的 Agent 决定整体速度。
• 误差传播：第 1 步的小错误到第 5 步可能被放大——研究 Agent 搜错了一个数据，写作 Agent 基于错误数据写了一整段，审校 Agent 也没发现。

实现时的关键设计

# 流水线的伪代码
def pipeline(task, agents):
    result = task
    for agent in agents:
        result = agent.run(result)  # 每个 Agent 处理上一个的输出
        if validate(result):        # 每步之后做质量检查
            continue
        else:
            # 质量不合格 → 回退重做
            result = agent.run(result, retry=True)
    return result

6.4 并行模式（Parallel / Map-Reduce）

🎨 漫画图解：〈分头行动，集中汇总〉

核心思想

把一个大任务拆成 N 个互不依赖的子任务，N 个 Agent 同时干，最后一个人汇总。

示意图

flowchart TB
    Input[📥 用户问题：「总结这三家竞品的优劣势」] --> Split[🔀 任务拆分]

    Split --> A1[🤖 Agent A
分析竞品1]
    Split --> A2[🤖 Agent B
分析竞品2]
    Split --> A3[🤖 Agent C
分析竞品3]

    A1 --> Merge[🔀 结果汇总 Agent]
    A2 --> Merge
    A3 --> Merge

    Merge --> Output[📤 综合对比报告]

典型场景

大规模代码审查：一次 PR 改了 50 个文件。一个 Agent 审查不过来——上下文装不下。方案：把 50 个文件分成 10 组，每组 5 个文件，启动 10 个审查 Agent 同时审。最后汇总 Agent 把 10 份审查报告合并成一份总报告。

多源数据采集：需要从 5 个不同的数据源获取信息。每个数据源分配一个 Agent，同时去对接。最后汇总。

优点

• 快：并行处理，总时间 ≈ 最慢那个 Agent 的时间。
• 可扩展：100 个文件？加 Agent 就行（理论上）。

缺点

• 汇总难：把 N 份结果合在一起的「汇总 Agent」本身也是瓶颈——它自己的上下文要能装下 N 份结果。
• 信息不对称：Agent A 不知道 Agent B 分析了什么，可能出现重复或遗漏。
• 一致性差：三个 Agent 用了三种不同的分析框架，汇总时对不上。

Map-Reduce 的变体

这是从大数据领域借来的经典模式：

flowchart TB
    subgraph Map 阶段
        M1[Agent 1: 分析前10篇文档]
        M2[Agent 2: 分析中间10篇]
        M3[Agent 3: 分析最后10篇]
    end

    subgraph Reduce 阶段
        R1[Agent 4: 汇总 Agent1+2 的结果]
        R2[Agent 5: 汇总 Agent3+ 前一轮]
    end

    subgraph 最终汇总
        F[Agent 6: 生成最终报告]
    end

    M1 --> R1
    M2 --> R1
    M3 --> R2
    R1 --> F
    R2 --> F

分层 Reduce 解决了「汇总 Agent 的上下文装不下所有结果」的问题——像锦标赛一样，一层一层往上汇总。

6.5 辩论模式（Debate / Adversarial）

🎨 漫画图解：〈让两个 Agent 互相挑刺〉

核心思想

让多个 Agent 从不同角度审视同一个结论或方案，相互挑战、找出漏洞。不是为了让它们「吵赢」——而是为了让最终输出更经得起推敲。

示意图

flowchart TB
    Prop[📝 提案 Agent
生成初步方案] --> S1[🔍 安全 Agent
从安全角度审查]
    Prop --> S2[💰 成本 Agent
从成本角度审查]
    Prop --> S3[⚖️ 合规 Agent
从合规角度审查]
    Prop --> S4[👤 用户 Agent
从用户体验审查]

    S1 --> Judge[👨‍⚖️ 裁判 Agent
综合各方意见
决定方案是否通过]
    S2 --> Judge
    S3 --> Judge
    S4 --> Judge

    Judge -->|不通过| Prop
    Judge -->|通过| Output[✅ 最终方案]

典型场景

安全审计：一个 Agent 写了一段代码，另一个 Agent 专门找安全漏洞，第三个 Agent 验证第二个 Agent 找到的漏洞是不是真的。这不是「找茬」——这是软件行业标准的安全审计流程，只是现在由 Agent 来做了。

事实核查：写作 Agent 生成了一篇报告。核查 Agent 逐条验证报告中的事实陈述——「你说 Q3 增长 15%？我去搜一下确认。」如果发现矛盾，退回给写作 Agent 修改。

为什么辩论模式有效

LLM 有一个有趣的性质：它在对自己的输出做「自我批评」时，往往比「做正向推理」时表现更好。就像一个学生在写完作文后，再读一遍往往能发现不少问题。

辩论模式把这种「自我纠错」形式化了——不是让同一个 Agent 自己审自己（容易形成「回音室」），而是让不同的 Agent 从不同的视角审。

6.6 主流多 Agent 框架

你不是手动写代码管理这些 Agent 之间的通信和状态——有现成的框架。

怎么选？

• 想建一个复杂的工作流、有循环和条件分支 → LangGraph
• 想快速试验几个 Agent 角色协作的效果 → CrewAI
• 需要人类在工作流中审批和介入 → AutoGen
• 只是想理解多 Agent 概念、做教学演示 → OpenAI Swarm

你在第7章做的 Obsidian Agent 是一个单 Agent 系统，但理解了多 Agent 的设计模式之后，你随时可以把它扩展成「研究 Agent + 写作 Agent + 审校 Agent」的三人组。

6.7 多 Agent 的翻车现场

多 Agent 虽然强大，但翻车的方式也更多样：

翻车1：通信死锁

Agent A 在等 Agent B 的结果，Agent B 在等 Agent A 的确认——两个 Agent 互等，整个系统卡住。

解法：超时机制 + 死锁检测。

翻车2：信息过载

汇总 Agent 收到 10 份各 5000 字的报告，上下文直接爆了。

解法：分层汇总（Map-Reduce）、让每个 Agent 在输出中包含一个 200 字以内的 TL;DR。

翻车3：一致性问题

三个 Agent 分析同一份数据得出了三个不同的结论——谁对谁错？汇总 Agent 应该信哪一个？

解法：引入裁判 Agent 或投票机制。或者让 Agent 在输出中包含置信度评分。

翻车4：成本爆炸

10 个 Agent 跑一个任务，API 费用是单 Agent 的 10 倍——但产出质量可能只提升了 20%。

解法：不是所有任务都值得用多 Agent。先问自己：「这个任务拆开后子任务之间真的没有依赖吗？并行真的能省时间吗？」

本章小结

下一章预告

理论到此结束。六章的内容——Agent 是什么 → 架构怎么搭 → RAG 怎么装知识 → 工具怎么调 → Agent 怎么训练 → 多 Agent 怎么协作——全是为下一章做准备的。

第7章，你会亲手写一个Obsidian Agent。从 RAG 索引你的全部笔记开始，到工具定义、Agent 循环、安全策略——你会在你自己的 vault 上跑一个真正能用的 Agent。

准备好了吗？→ 第7章：实操——从零构建 Obsidian Agent