9.7.5 多 Agent 实战模式

学习目标

理解几种高频多 Agent 实战模式
学会根据任务目标选择更合适的协作方式
看懂一个小型多 Agent 工作流示例
理解“模式”为什么比“多开几个 Agent”更重要

为什么要讲“实战模式”？

因为真实系统通常不是纯理论架构

很多项目不会说：

“我要一个 peer-to-peer 多 Agent 系统”

它更常说：

“我要一个研究助理团队”
“我要一个写作 + 审核工作流”
“我要一个代码开发小组”

也就是说，真实项目更像“任务组织形态”，而不只是抽象架构名。

所以学实战模式的意义是什么？

它能帮你从：

抽象结构理解

走向：

具体产品落地

模式一：研究型协作

典型分工

规划者：拆问题
研究者：检索资料
整合者：整合结果

适合什么任务？

做背景调研
收集材料
输出结构化报告

一个最小示例

def planner(query):
    return ["收集退款政策", "整理时间条件", "形成结论"]

def researcher(task):
    docs = {
        "收集退款政策": "课程购买后 7 天内且学习进度低于 20% 可退款。",
        "整理时间条件": "关键条件包括时间范围和学习进度。"
    }
    return docs.get(task, "未找到资料")

def synthesizer(items):
    return "结论：" + " ".join(items)

plan = planner("退款政策是什么")
materials = [researcher(task) for task in plan[:-1]]
answer = synthesizer(materials)

print(plan)
print(materials)
print(answer)

预期输出：

['收集退款政策', '整理时间条件', '形成结论']
['课程购买后 7 天内且学习进度低于 20% 可退款。', '关键条件包括时间范围和学习进度。']
结论：课程购买后 7 天内且学习进度低于 20% 可退款。 关键条件包括时间范围和学习进度。

这个模式的关键是：

先发散搜集，再统一收敛。

模式二：写作 + 审核

最经典也最实用的模式之一

分工通常是：

撰写者：先写初稿
审核者：检查问题
修订者：按意见修订

为什么这个模式特别常见？

因为很多任务天然就适合：

生成
检查
再修正

例如：

报告撰写
答案生成
代码文档

一个最小示例

def writer(topic):
    return f"初稿：{topic} 的核心是 7 天内可退款。"

def reviewer(draft):
    if "7 天内" in draft:
        return "建议补充学习进度条件。"
    return "时间条件缺失。"

def reviser(draft, review):
    return draft + " " + review

draft = writer("退款政策")
review = reviewer(draft)
final = reviser(draft, review)

print(draft)
print(review)
print(final)

预期输出：

初稿：退款政策 的核心是 7 天内可退款。
建议补充学习进度条件。
初稿：退款政策 的核心是 7 天内可退款。 建议补充学习进度条件。

这个模式最大的好处是：

它把“生成能力”和“纠错能力”分开了。

模式三：开发团队模式

一个很常见的 AI 开发团队抽象

例如：

产品经理 / 规划者：定义需求
开发者：写实现
审核者：做代码检查
测试者：验证结果

为什么这个模式在 AI coding 场景里很常见？

因为软件开发天然就已经有这种角色分工。多 Agent 只是把它程序化、自动化了。

一个最小示例

workflow = [
    {"agent": "planner", "task": "定义要实现的功能"},
    {"agent": "coder", "task": "写出实现代码"},
    {"agent": "reviewer", "task": "检查逻辑问题"},
    {"agent": "tester", "task": "验证输出是否符合预期"}
]

for step in workflow:
    print(step["agent"], "->", step["task"])

预期输出：

planner -> 定义要实现的功能
coder -> 写出实现代码
reviewer -> 检查逻辑问题
tester -> 验证输出是否符合预期

这个模式的关键不是“角色好听”，而是：

每一层都能捕捉不同类型的问题。

模式四：双重核验 / 高风险审核模式

什么时候需要？

如果任务风险较高，比如：

法律建议
医疗辅助
金融判断

那么很多时候不能只让一个 Agent 单独产出结论。

常见做法

一个 Agent 生成答案
另一个 Agent 做事实核查
还有一个 Agent 检查风险与合规

这类模式虽然更慢，但更稳。

一个小型多 Agent 工作流示例

def planner(query):
    return ["retrieve", "write", "review"]

def retriever(query):
    return "检索结果：退款需满足时间与进度条件。"

def writer(material):
    return f"回答草稿：{material}"

def reviewer(draft):
    if "进度条件" in draft:
        return {"approved": True, "comment": "信息较完整"}
    return {"approved": False, "comment": "遗漏关键条件"}

query = "退款政策是什么？"
steps = planner(query)
material = retriever(query)
draft = writer(material)
review = reviewer(draft)

print("steps  :", steps)
print("draft  :", draft)
print("review :", review)

预期输出：

steps  : ['retrieve', 'write', 'review']
draft  : 回答草稿：检索结果：退款需满足时间与进度条件。
review : {'approved': True, 'comment': '信息较完整'}

多 Agent 实战工作流结果图

这段代码虽然很小，但已经体现了实战模式最核心的味道：

先规划
再执行
再评审

怎样选合适的实战模式？

如果任务重点在搜资料

优先考虑：

研究型协作

如果任务重点在内容质量

优先考虑：

写作 + 审核

如果任务重点在工程落地

优先考虑：

开发团队模式

如果任务风险高

优先考虑：

双重核验 / 高风险审核模式

所以真正重要的问题不是：

“哪个模式最酷？”

而是：

“哪个模式最符合当前任务的失败风险和目标结构？”

初学者最常踩的坑

把模式和角色数量绑定死

不是“3 个 Agent 就一定是某模式”。关键是职责关系，不是数量。

为了看起来复杂而堆模式

很多任务用单 Agent 或两 Agent 已经足够。

没有明确评价标准

如果你不知道“这个模式为什么比另一个模式更好”，那系统迭代会很难推进。

留下的证据

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

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

小结

这一节最重要的不是背“研究型”“开发型”这些标签，而是理解：

多 Agent 实战模式的价值，在于把抽象协作结构映射到真实任务目标。

当你能把任务形状和协作模式对应起来，多 Agent 才会真正从概念走向产品。

练习

选一个你熟悉的任务，判断它更像研究型、写作审核型还是开发团队型。
给本节的小型工作流再加一个 reviser Agent，让它根据 review 修改 draft。
想一想：高风险任务为什么更需要“生成 + 核查 + 风险审查”的组合？
用自己的话解释：为什么说多 Agent 的重点不是角色数量，而是协作结构？

参考实现与讲解

可以按主要风险分类：如果证据覆盖最重要，就是 research collaboration；如果表达和准确性最重要，就是 writing + review；如果实现和测试最重要，就是 development team。
reviser Agent 应读取 draft 和 review comments，只修改被拒绝或薄弱的部分，并返回 revised output 和简短 change note。
高风险任务需要 generation + verification + risk review，因为流畅输出仍可能错误、不完整、不安全，或没有证据支撑。
重点是协作结构，因为角色只有在形成有用边界、交接、检查和决策时才有价值。没有结构的长角色列表，只会增加对话量。