多 Agent 系统设计模式：Fan-out、Pipeline、Best-of-N——你该用哪一种？

当一个 Agent 不够用时，你就需要多个 Agent 协作。但多个 Agent 不是"多开几个窗口各干各的"那么简单------它们之间怎么分工、怎么沟通、怎么汇总，需要设计模式。

本文拆解三种最实用的多 Agent 设计模式：什么时候用、怎么配、效果如何。

一、为什么需要多 Agent？

一个 Agent 的瓶颈

单个 Agent 能做的事有限制：

上下文窗口限定了它能同时处理的信息量
单线程意味着它一次只能做一件事
单模型意味着它只能用一种推理方式

多 Agent 的优势

优势	说明
并行	多个 Agent 同时干不同的活
专精	每个 Agent 用不同的模型/技能处理不同任务
容错	一个 Agent 失败了不影响其他的
可扩展	加 Agent 比改代码容易

二、模式一：Fan-out（扇出/并行探索）

是什么

一个任务拆成多个独立的子任务，同时执行，各自完成后汇总。

复制代码

你的需求
    ↓
拆解器
    ├── Agent A：查数据库性能
    ├── Agent B：查 API 延迟
    ├── Agent C：查内存使用
    └── Agent D：查网络瓶颈
                    ↓
         汇总器 → 综合报告

适用场景

场景	说明
性能分析	从多个角度同时分析同一个系统
技术调研	同时查多个技术方案的优劣
安全检查	同时扫描代码的多个安全维度
多维度测试	同时测试性能、安全、兼容性

在 Hermes 中实现

复制代码

from hermes_tools import delegate_task, terminal

# 1. 派 3 个子 Agent 并行做性能分析
task_db = delegate_task(
    goal="分析项目的数据库查询性能，找出慢查询和 N+1 问题",
    context="项目路径：/path/to/project，数据库：PostgreSQL"
)

task_api = delegate_task(
    goal="分析项目的 API 响应时间，找出最慢的 5 个端点",
    context="项目路径：/path/to/project，框架：FastAPI"
)

task_memory = delegate_task(
    goal="分析项目的内存使用情况，找出内存泄漏风险",
    context="项目路径：/path/to/project，Python 3.12"
)

# 2. 等待所有结果回来（delegate_task 自动异步执行）
# 结果会在各自完成时自动返回

# 3. 汇总
print("=== 性能分析汇总 ===")
print(f"数据库问题：{result_db}")
print(f"API 问题：{result_api}")
print(f"内存问题：{result_memory}")

用 Kanban 实现

复制代码

# 创建 3 个并行的调研任务
hermes kanban create "分析数据库性能瓶颈" --assignee research
hermes kanban create "分析 API 响应时间" --assignee research
hermes kanban create "分析内存使用" --assignee research

# 创建汇总任务（依赖上面三个完成）
hermes kanban create "汇总性能分析报告" \
  --assignee writer \
  --parent t_db,t_api,t_memory

优点与缺点

复制代码

✅ 优点：
  - 速度快（N 个任务并行 = 时间近似于最慢的那个）
  - 互不干扰（每个 Agent 独立）
  - 容易扩展（加一个维度就加一个 Agent）

❌ 缺点：
  - 不能处理有依赖的子任务
  - 如果子任务之间有信息重叠，可能重复劳动
  - 汇总器的质量取决于各子任务的质量

三、模式二：Pipeline（流水线）

是什么

任务分成多个阶段，每个阶段依赖前一个阶段的输出。后一个 Agent 拿到前一个的结果再处理。

复制代码

需求 → Agent A（调研）→ 输出方案
                ↓
          Agent B（实现）→ 输出代码
                ↓
          Agent C（审查）→ Review 结论
                ↓
          你（决策）→ 合并或退回

适用场景

场景	说明
功能开发	调研→方案→实现→审查→发布
数据分析	采集→清洗→分析→可视化→报告
内容创作	选题→大纲→初稿→编辑→发布
Bug 修复	复现→定位→修复→测试→审查

在 Hermes 中实现

复制代码

# Step 1：调研
hermes kanban create "调研 PostgreSQL 15 新特性及迁移方案" \
  --assignee research

# Step 2：方案（依赖调研）
hermes kanban create "基于调研结果编写迁移方案" \
  --assignee writer \
  --parent t_research

# Step 3：实现（依赖方案）
hermes kanban create "按迁移方案执行数据库升级" \
  --assignee coder \
  --parent t_plan

# Step 4：审查（依赖实现）
hermes kanban create "审查数据库迁移代码" \
  --assignee reviewer \
  --parent t_impl

# Step 5：最终决策（依赖审查）
hermes kanban create "审批迁移并发布" \
  --assignee pm \
  --parent t_review

依赖链自动流转

关键设计：Kanban 的 parent 参数让后一个任务在前一个完成后自动变为 ready。不需要手动通知。

复制代码

t_research (done) → t_plan 自动变 ready
t_plan (done) → t_impl 自动变 ready
t_impl (done) → t_review 自动变 ready
t_review (done) → t_pm 自动变 ready

优点与缺点

复制代码

✅ 优点：
  - 结构清晰，每个阶段职责明确
  - 每个阶段可以换不同的 Agent/模型/技能
  - 可以随时插入人工审批节点

❌ 缺点：
  - 串行执行，慢在"最慢的阶段"
  - 上游出错，下游白干
  - 需要良好的依赖管理

四、模式三：Best-of-N（竞争式）

是什么

同一个任务交给多个 Agent 独立做，然后挑最好的结果。

复制代码

你的需求：设计一个用户认证方案
    ↓
Agent A（o4-mini）：方案 A
Agent B（Claude）：方案 B
Agent C（DeepSeek Pro）：方案 C
    ↓
你（或一个评判 Agent）→ 挑出最优方案

适用场景

场景	说明
技术方案设计	多个方案比选，选最优
代码重构	多个重构方案，选可读性最高的
文案生成	多个版本，选最符合调性的
Bug 修复	多个修复方案，选影响最小的

在 Hermes 中实现

复制代码

from hermes_tools import delegate_task

# 同一个需求，用不同模型/角度各出一份方案
task_a = delegate_task(
    goal="设计用户认证方案，用 JWT + refresh token",
    context="项目使用 FastAPI，PostgreSQL。方案要简洁，易于维护。"
)

task_b = delegate_task(
    goal="设计用户认证方案，用 session + JWT 混合",
    context="同上项目。方案要安全，防止常见攻击。"
)

task_c = delegate_task(
    goal="设计用户认证方案，用 OAuth2 + 本地会话",
    context="同上项目。方案要灵活，后续容易扩展第三方登录。"
)

# 三个结果回来后，让一个评审 Agent 选最优
best = delegate_task(
    goal="评审以下三个认证方案，选出最优的一个并说明理由",
    context=f"""
方案 A：{result_a}
方案 B：{result_b}
方案 C：{result_c}

评估维度：安全性、可维护性、开发成本、扩展性
请给出综合评分（1-10）和推荐方案
"""
)

优点与缺点

复制代码

✅ 优点：
  - 质量高（N 个方案中选一个）
  - 可以并行使不同模型的优势
  - 适合高风险决策

❌ 缺点：
  - 成本高（N 倍的 token 消耗）
  - 评判 Agent 的质量决定最终结果
  - 不适合时间敏感的场景

五、如何选择：决策树

复制代码

你的需求是什么？
    │
    ├─ 从多个角度看同一个问题 → Fan-out（扇出）
    │   例：性能分析、安全扫描、技术调研
    │
    ├─ 任务有明确的先后依赖 → Pipeline（流水线）
    │   例：功能开发、数据分析、内容创作
    │
    ├─ 需要高质量决策、可以接受高成本 → Best-of-N（竞争）
    │   例：技术选型、架构设计、高影响 Bug 修复
    │
    └─ 以上都有 → 混合模式
        例：先用 Fan-out 调研，再串成 Pipeline，关键决策用 Best-of-N

六、混合模式实战

一个真实项目的多 Agent 工作流：

复制代码

第一阶段：Fan-out 调研（同时进行）
  ├── Agent A：查 DB 性能 ------ 15 分钟
  ├── Agent B：查 API 延迟 ------ 15 分钟
  └── Agent C：查前端性能 ------ 15 分钟
            ↓
第二阶段：Pipeline 执行（串行）
  Agent D（汇总）：出优化方案 ------ 10 分钟
  Agent E（实现）：按方案改代码 ------ 30 分钟
  Agent F（审查）：审查代码质量 ------ 10 分钟
            ↓
第三阶段：Best-of-N 决策（关键节点）
  ├── Agent G（方案一）：用 Redis 缓存
  ├── Agent H（方案二）：用 CDN 加速
  └── Agent I（方案三）：升级服务器
              ↓
    你：选最优方案 → 合并 PR

整个流程：3 个 Fan-out + 3 个 Pipeline + 1 个 Best-of-N，约 60-90 分钟完成。如果一个人从头到尾做，至少需要 4-6 小时。

七、一句话总结

Fan-out 快，Pipeline 稳，Best-of-N 准。

没有万能模式。选哪种取决于你的约束条件：

时间紧 → Fan-out

质量要求高 → Pipeline（每步有人审）

决策风险大 → Best-of-N

全都要 → 混合模式