9.7.2 多 Agent 架构模式
很多人第一次做多 Agent 时，最容易犯的错就是：
“既然一个 Agent 不够，那就多开几个。”
但真正的问题不是“数量”，而是：
这些 Agent 怎样分工、怎样组织、怎样协作。
这就是多 Agent 架构模式要解决的核心。
学习目标
- 理解什么时候真的需要多 Agent
- 分清几种最常见的多 Agent 架构模式
- 看懂 supervisor、pipeline、reviewer 等模式的优缺点
- 用一个小型示例感受不同模式的组织方式
为什么不是所有任务都需要多 Agent？
多 Agent 不是默认升级路线
如果一个任务本来就能由单 Agent 稳定完成，多 Agent 往往只会增加：
- 通信成本
- 调试难度
- 失败路径
所以更稳妥的原则通常是：
先把单 Agent 做稳，再考虑是否真的需要拆成多 Agent。
那什么时候值得上多 Agent？
通常是这些情况：
- 任务明显可以拆工
- 子任务类型差异很大
- 一个 Agent 同时承担所有职责太乱
- 需要独立的规划、执行、评审角色
这时多 Agent 才真正有意义。
先看最常见的几种模式
Supervisor-Worker 模式
一个监督者（supervisor）负责：
- 拆任务
- 分配任务
- 汇总结果
其他 worker 负责具体执行。
这是最常见也最好理解的模式之一。
Pipeline 模式
每个 Agent 只负责固定阶段：
- 检索
- 分析
- 写作
它更像流水线。
Reviewer 模式
一个 Agent 负责生成，另一个专门负责检查或评审。
这在代码、文档、报告生成里特别常见。
Group / Peer 模式
多个 Agent 相对平等地协商。
这种模式更灵活，但也更难控。
Supervisor-Worker：最值得先学的模式
为什么它很常见？
因为它最符合很多现实团队结构：
- 项目经理 / 组长负责拆任务
- 执行同学负责具体工作
一个最小可运行示例
tasks = ["检索资料", "整理要点", "撰写总结"]
workers = {
"researcher": "负责找资料",
"analyst": "负责整理信息",
"writer": "负责生成最终文本"
}
assignment = {
"检索资料": "researcher",
"整理要点": "analyst",
"撰写总结": "writer"
}
for task in tasks:
worker = assignment[task]
print(f"{worker} <- {task} ({workers[worker]})")
预期输出：
researcher <- 检索资料 (负责找资料)
analyst <- 整理要点 (负责整理信息)
writer <- 撰写总结 (负责生成最终文本)
它的优点和缺点
优点：
- 分工清楚
- 更容易控制
- 更容易观察谁哪一步出问题
缺点：
- supervisor 可能成为瓶颈
- 如果拆任务质量差，后面全都会受影响
Pipeline 模式：像工厂流水线一样协作
它和 supervisor 模式的区别
supervisor 模式强调“一个中心调度”。 pipeline 模式更强调“任务按固定阶段流动”。
例如：
- Retriever Agent 找资料
- Filter Agent 过滤噪声
- Writer Agent 生成答案
一个最小示例
def retriever(query):
return {"docs": ["退款政策", "证书说明"], "query": query}
def filter_agent(data):
return {"docs": [doc for doc in data["docs"] if "退款" in doc], "query": data["query"]}
def writer(data):
if not data["docs"]:
return "未找到足够相关的信息。"
return f"基于 {data['docs']}，生成最终回答。"
query = "退款政策是什么"
step1 = retriever(query)
step2 = filter_agent(step1)
step3 = writer(step2)
print(step1)
print(step2)
print(step3)
预期输出：
{'docs': ['退款政策', '证书说明'], 'query': '退款政策是什么'}
{'docs': ['退款政策'], 'query': '退款政策是什么'}
基于 ['退款政策']，生成最终回答。
它适合什么？
适合：
- 阶段固定
- 顺序清晰
- 每一层职责非常明确
不太适合：
- 需要频繁回头修改计划
- 需要大量灵活协商
Reviewer 模式：生成和检查分离
为什么这个模式很实用？
很多任务里，“生成”和“评审”天然就是两种不同能力。
例如：
- 代码编写 vs 代码审查
- 报告撰写 vs 事实核查
- 答案生成 vs 风险审查
一个可运行示例
def writer_agent(topic):
return f"关于 {topic} 的初稿：课程购买后 7 天内可退款。"
def reviewer_agent(text):
if "7 天内" in text:
return {"approved": True, "comment": "关键信息已覆盖"}
return {"approved": False, "comment": "缺少核心时间条件"}
draft = writer_agent("退款政策")
review = reviewer_agent(draft)
print("draft :", draft)
print("review:", review)
预期输出：
draft : 关于 退款政策 的初稿：课程购买后 7 天内可退款。
review: {'approved': True, 'comment': '关键信息已覆盖'}
为什么这个模式好用？
因为它可以把“生成质量”和“检查质量”拆开管理。
这在高风险任务里尤其有价值。
Peer / Group 模式：多个 Agent 平等协作
看起来很自由，但也更难控
在这种模式里，多个 Agent 都能提议、争论、补充。
优点：
- 灵活
- 容易激发多种方案
缺点：
- 容易重复劳动
- 容易跑题
- 更难收敛
读这张图时，先看任务有没有天然分工：需要中心调度就选 supervisor-worker，阶段固定就选 pipeline，需要质量检查就加 reviewer，需要多视角讨论才考虑 peer/group。
什么时候考虑它？
比较适合：
- 头脑风暴
- 方案比较
- 多视角分析
但对很多工程系统来说，它未必是最稳的起点。
一个很重要的问题：谁负责收尾？
不管你用哪种模式，都必须回答这个问题：
最终由谁来决定“任务完成了”？
如果这个问题没设计好，很容易出现：
- 大家都在做事，但没人收尾
- 多个 Agent 互相来回发消息
- 任务迟迟不结束
这也是为什么很多多 Agent 系统，最后还是会有一个“最终裁决者”。
多 Agent 架构的选择逻辑
如果任务阶段固定
优先考虑：
- Pipeline 模式
如果任务需要中心拆分和调度
优先考虑：
- Supervisor-Worker 模式
如果任务需要强评审和复核
优先考虑：
- Writer-Reviewer 模式
如果任务本身就是多视角讨论
才考虑：
- Peer / Group 模式
所以最重要的不是“哪种模式更高级”，而是：
哪种模式更匹配你的任务形状。
初学者最常踩的坑
把多 Agent 当成“多开几个模型就行”
真正难的是架构，不是数量。
一上来就选最自由的协作模式
自由越高，调试和收敛难度通常也越高。
没有明确的结束条件
这是很多多 Agent demo 看起来聪明，但实际跑起来容易死循环的根源。
小结
这一节最重要的不是背模式名字，而是理解：
多 Agent 架构模式的核心，是把任务拆成合适的角色和协作关系，而不是简单增加参与者数量。
选对架构模式，系统会更稳、更可控； 选错了，复杂度会比收益增长得更快。
练习
- 用自己的话解释 supervisor、pipeline、reviewer 三种模式的区别。
- 想一想：如果你要做“自动研究报告”，哪种模式最适合先落地？为什么？
- 设计一个“检索 -> 写作 -> 审核”的三 Agent 流水线。
- 思考：为什么说多 Agent 架构首先是组织问题，而不是模型数量问题？