9.7.2 多 Agent 架构模式

多 Agent 协作消息流图

学习目标

理解什么时候真的需要多 Agent
分清几种最常见的多 Agent 架构模式
看懂监督者-执行者、流水线、评审等模式的优缺点
用一个小型示例感受不同模式的组织方式

为什么不是所有任务都需要多 Agent？

多 Agent 不是默认升级路线

如果一个任务本来就能由单 Agent 稳定完成，多 Agent 往往只会增加：

通信成本
调试难度
失败路径

所以更稳妥的原则通常是：

先把单 Agent 做稳，再考虑是否真的需要拆成多 Agent。

那什么时候值得上多 Agent？

通常是这些情况：

任务明显可以拆工
子任务类型差异很大
一个 Agent 同时承担所有职责太乱
需要独立的规划、执行、评审角色

这时多 Agent 才真正有意义。

先看最常见的几种模式

监督者-执行者模式

一个监督者负责：

拆任务
分配任务
汇总结果

其他执行者负责具体执行。

这是最常见也最好理解的模式之一。

流水线模式

每个 Agent 只负责固定阶段：

检索
分析
写作

它更像流水线。

评审模式

一个 Agent 负责生成，另一个专门负责检查或评审。

这在代码、文档、报告生成里特别常见。

同伴协作模式

多个 Agent 相对平等地协商。

这种模式更灵活，但也更难控。

监督者-执行者：最值得先学的模式

为什么它很常见？

因为它最符合很多现实团队结构：

项目经理 / 组长负责拆任务
执行同学负责具体工作

一个最小可运行示例

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 <- 撰写总结 (负责生成最终文本)

它的优点和缺点

优点：

分工清楚
更容易控制
更容易观察谁哪一步出问题

缺点：

监督者可能成为瓶颈
如果拆任务质量差，后面全都会受影响

流水线模式：像工厂流水线一样协作

它和监督者-执行者模式的区别

监督者-执行者模式强调“一个中心调度”。流水线模式更强调“任务按固定阶段流动”。

例如：

检索者找资料
过滤者过滤噪声
撰写者生成答案

一个最小示例

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': '退款政策是什么'}
基于 ['退款政策']，生成最终回答。

它适合什么？

适合：

阶段固定
顺序清晰
每一层职责非常明确

不太适合：

需要频繁回头修改计划
需要大量灵活协商

评审模式：生成和检查分离

为什么这个模式很实用？

很多任务里，“生成”和“评审”天然就是两种不同能力。

例如：

代码编写 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': '关键信息已覆盖'}

为什么这个模式好用？

因为它可以把“生成质量”和“检查质量”拆开管理。

这在高风险任务里尤其有价值。

同伴协作模式：多个 Agent 平等协作

看起来很自由，但也更难控

在这种模式里，多个 Agent 都能提议、争论、补充。

优点：

灵活
容易激发多种方案

缺点：

容易重复劳动
容易跑题
更难收敛

多 Agent 架构模式选择图

什么时候考虑它？

比较适合：

头脑风暴
方案比较
多视角分析

但对很多工程系统来说，它未必是最稳的起点。

一个很重要的问题：谁负责收尾？

不管你用哪种模式，都必须回答这个问题：

最终由谁来决定“任务完成了”？

如果这个问题没设计好，很容易出现：

大家都在做事，但没人收尾
多个 Agent 互相来回发消息
任务迟迟不结束

这也是为什么很多多 Agent 系统，最后还是会有一个“最终裁决者”。

多 Agent 架构的选择逻辑

如果任务阶段固定

优先考虑：

流水线模式

如果任务需要中心拆分和调度

优先考虑：

监督者-执行者模式

如果任务需要强评审和复核

优先考虑：

撰写-评审模式

如果任务本身就是多视角讨论

才考虑：

同伴协作模式

所以最重要的不是“哪种模式更高级”，而是：

哪种模式更匹配你的任务形状。

初学者最常踩的坑

把多 Agent 当成“多开几个模型就行”

真正难的是架构，不是数量。

一上来就选最自由的协作模式

自由越高，调试和收敛难度通常也越高。

没有明确的结束条件

这是很多多 Agent 演示看起来聪明，但实际跑起来容易死循环的根源。

留下的证据

学完这一页，至少保留这张证据卡：

角色: 负责人、执行者、评审者，或专家职责
消息契约: artifact、request、response 和交接状态
协同: 路由、任务拆分、冲突解决和最终负责人
失败检查: 重复工作、上下文丢失、没有明确负责人或消息循环
评估动作: 将多 Agent 结果与单 Agent 基线对比

小结

这一节最重要的不是背模式名字，而是理解：

多 Agent 架构模式的核心，是把任务拆成合适的角色和协作关系，而不是简单增加参与者数量。

选对架构模式，系统会更稳、更可控；选错了，复杂度会比收益增长得更快。

练习

用自己的话解释监督者-执行者、流水线、评审三种模式的区别。
想一想：如果你要做“自动研究报告”，哪种模式最适合先落地？为什么？
设计一个“检索 -> 写作 -> 审核”的三 Agent 流水线。
思考：为什么说多 Agent 架构首先是组织问题，而不是模型数量问题？

参考实现与讲解

supervisor 模式把任务分配和决策集中起来；pipeline 模式让工作按阶段顺序传递；reviewer 模式增加显式质量关卡，可以接受、拒绝或要求修改。
自动研究报告可以先做 retrieval -> writing -> review。这条 pipeline 容易检查，reviewer 也给了你抓 unsupported claims 的明确位置。
一个好的三 Agent pipeline 会记录 retrieval 的 query 和 evidence，只把相关笔记交给 writing，再让 review 检查引用覆盖、缺失假设和最终答案质量。
多 Agent 首先是组织问题，因为关键在于责任、信息和决策如何流动。只增加模型数量而不明确边界，通常增加的是噪声而不是能力。