Agent 也有自己的「设计模式」——一套针对不同任务形状、被反复验证有效的「结构方案」。

今天这篇，就把业界最经典的五种 Agent 设计模式，一次讲透。每个模式我都会告诉你：它是什么、长什么样、怎么用、什么时候该用什么时候不该用。

---

一、什么是「Agent 设计模式」？为什么需要它？

1.1 先认识一个老朋友：软件工程的设计模式

如果你写过代码，一定听过 设计模式（Design Pattern）——单例、工厂、观察者、策略……它们不是「新技术」，而是**「前人踩了无数坑之后，总结出来的可复用的结构套路」**。

比如「工厂模式」，解决的是「我不想在每个地方都 new，想让创建对象的逻辑集中管理」这个问题。它没有新语法，只是一种组织代码的结构。

Agent 设计模式，是同一套思想，搬到了「大模型应用」的领域。

1.2 Agent 设计模式的定义

Agent 设计模式，就是「针对某一类任务，被反复验证有效的、组织大模型调用的结构方案」。

它的核心不是「模型更强」，而是「怎么把一次或多次 LLM 调用，组织成正确的结构，从而稳定地解决一类问题」。

1.3 为什么需要它？三个理由

理由	说明
可复用	不用每次从零设计，遇到同类问题直接套
可预期	知道它怎么工作，出了问题能定位
可交流	团队有了共同语言：「这个用路由模式就行」

一句话：Agent 设计模式，就是大模型应用界的「设计图纸」。它不是玄学，而是「任务长什么样，就用什么结构去接」的经验沉淀。

---

二、模式一：Prompt Chaining（提示链）

2.1 是什么？

Prompt Chaining（提示链），是最简单、也最常用的一种模式：

把一个复杂任务，拆成多个串行步骤，每一步用一次 LLM 调用，上一步的输出，作为下一步的输入，像链条一样一环扣一环。

2.2 结构图

2.3 伪代码

# 任务：写一份「市场调研报告」
# 直接让模型一次写完，往往又长又乱；拆成链式，每步专注一件事

大纲 = LLM.调用("根据主题 X，生成一份报告大纲")
初稿 = LLM.调用("根据这个大纲，写正文：", 大纲)
润色 = LLM.调用("把这段文字润色得更专业流畅：", 初稿)

每一步的职责单一，输出质量更可控。

2.4 适用 / 不适用

适用场景	不适用场景
任务可清晰拆成「先后有序」的步骤	任务无法预先拆解，要边走边看
每步输出是下一步的输入	各步骤互不依赖（该用并行，见模式三）
希望每步都可单独调试、单独优化	追求极低延迟（链式是串行的，慢）

一句话：Prompt Chaining 的精髓是「大事化小，一步一步来」。把一个复杂的活，拆成一串简单的小活，每一步都好控制、好调试。

---

三、模式二：Routing（路由）

3.1 是什么？

Routing（路由），解决的是「不同的问题，该交给不同的专家」：

先让一个「分类器」判断输入属于哪一类，再把它分发给对应的「专门处理器」。

3.2 结构图

3.3 伪代码

# 任务：一个「智能客服」，用户可能问：退款、物流、售后、投诉…
# 不同问题，需要的知识、语气、流程都不一样，交给不同的「专家」处理

类别 = LLM.分类("用户这句话属于哪类：退款 / 物流 / 售后 / 投诉", 用户输入)

if 类别 == "退款":
    回复 = LLM.退款专家(用户输入)
elif 类别 == "物流":
    回复 = LLM.物流专家(用户输入)
elif 类别 == "售后":
    回复 = LLM.售后专家(用户输入)
else:
    回复 = LLM.通用客服(用户输入)

3.4 链式 vs 路由：本质区别

很多人会混淆「链式」和「路由」，记住这个区别：

维度	Prompt Chaining	Routing
结构	一条线（顺序执行）	一个分叉（选择其一）
步骤关系	每一步都执行	只执行被选中的那一路
类比	流水线	交通分流

一句话：链式是「按顺序走」，路由是「先分好类，再走对路」。当一个任务明显分成「几个不同类型、各有各的处理方式」时，就该用路由。

---

四、模式三：Parallelization（并行化）

4.1 是什么？

Parallelization（并行化），解决的是「活儿太多，串行太慢」：

把一个任务，拆成多个互不依赖的子任务，同时处理，最后汇总。

它有两种经典子类——分段（Sectioning） 和 投票（Voting）。

4.2 子类一：Sectioning（分段）

把一个「大活」切成几块，各算各的，最后拼起来：

# 任务：分析一份 300 页的报告
# 串行读要读很久，分段并行：把报告切成 3 段，同时分析，最后合并结论

段1分析 = LLM.调用("分析报告第 1-100 页的要点", 报告.前100页)
段2分析 = LLM.调用("分析报告第 101-200 页的要点", 报告.中100页)
段3分析 = LLM.调用("分析报告第 201-300 页的要点", 报告.后100页)

结论 = LLM.调用("把这三段分析合并成完整结论", 段1分析, 段2分析, 段3分析)

4.3 子类二：Voting（投票）

同一个任务，让多个 LLM 各做一遍，投票/比较取最优：

# 任务：给一段文案写标题（主观任务，好坏难判）
# 让 3 个模型各写一个，再投票选出最好的

候选1 = LLM.调用("写一个标题", 文案)
候选2 = LLM.调用("写一个标题", 文案)
候选3 = LLM.调用("写一个标题", 文案)

最佳 = LLM.调用("这 3 个标题哪个最好，为什么", 候选1, 候选2, 候选3)

4.4 适用 / 不适用

子类	适用	不适用
Sectioning	任务可切成互不依赖的块	子任务之间有依赖（要用链式）
Voting	任务「好坏」主观、需要多视角	任务有唯一客观答案（投票意义不大）

一句话：并行化的核心是「没有依赖，就同时干」。分段是「各管一块」，投票是「各做一遍取最优」。它能显著提速、提质量，但前提是——子任务必须真的互不依赖。

---

五、模式四：Orchestrator-Workers（编排者-执行者）

5.1 是什么？

Orchestrator-Workers（编排者-执行者），是五种模式里最「智能」的一个：

一个「编排者（Orchestrator）」动态地拆解任务、分配给多个「执行者（Worker）」，最后汇总结果。

它和前面几个模式最大的不同：拆解是「动态」的——不是预先写死的步骤，而是编排者「看着办」。

5.2 结构图

5.3 伪代码

# 任务：「帮我做一个新产品的市场分析」
# 编排者动态拆出若干子任务，分给不同执行者

子任务列表 = 编排者.拆解("做一个新产品市场分析")
# 可能拆出：查竞品 / 查目标用户 / 查定价 / 查渠道…

结果集 = []
for 子任务 in 子任务列表:
    执行者 = 选一个合适的(子任务)        # 或并行派给多个
    结果集.append(执行者.执行(子任务))

最终答案 = 编排者.汇总(结果集)

5.4 它和前面几个模式的区别

模式	拆解方式	决策者
Prompt Chaining	预先写死	开发者
Routing	预先写死分类	开发者
Parallelization	预先写死分块	开发者
Orchestrator-Workers	运行时动态拆解	编排者（LLM）

🎯 关键点：前三个模式，路径是「提前定好」的；编排者-执行者模式，路径是「模型运行时自己定的」。这就是它更灵活、也更能应对开放任务的原因。

5.5 适用 / 不适用

适用场景	不适用场景
任务开放、无法预先确定步骤	任务步骤固定、清晰（用链式更省）
子任务之间差异大、需要不同能力	子任务同质（用并行分段更简单）
任务复杂到「一个人拆不完」	任务简单（上编排者纯属杀鸡用牛刀）

一句话：编排者-执行者是「动态版的并行」——由一个「大脑」临场拆活、派活、收活。它最灵活，但也最贵、最难控制，非复杂开放任务，不必动用它。

---

六、模式五：Evaluator-Optimizer（评估者-优化者）

6.1 是什么？

Evaluator-Optimizer（评估者-优化者），解决的是「一次生成不够好，怎么让它更好」：

一个模型负责「生成」，另一个模型负责「评估」，评估结果作为反馈，驱动生成方反复迭代改进，直到达标。

6.2 结构图

6.3 伪代码

# 任务：写一篇高质量的英文文章
# 生成者写，评估者挑毛病，反复改到合格为止

版本 = 生成者.生成("写一篇关于 AI 的英文文章")
最多迭代 = 3

for 轮次 in 1..最多迭代:
    评估 = 评估者.评估("这篇有什么问题？打分 1-10", 版本)

    if 评估.分数 >= 8:
        break                       # 达标，收工

    版本 = 生成者.改进("根据这些意见改：", 评估.反馈)

输出(版本)

6.4 适用 / 不适用

适用场景	不适用场景
任务有「明确的好坏标准」可评估	好坏无法客观判断
生成质量能通过迭代明显提升	答案唯一确定、一次就对
写作、代码、翻译、设计等「可打磨」任务	追求低延迟（迭代慢）

一句话：评估者-优化者的精髓是「写好不算完，改好才算数」。它引入一个「挑刺的评委」，用反馈驱动反复打磨。凡是「能越改越好」的任务，都值得用它。

---

七、五种模式总览与如何选择（收口）

7.1 五模式总览图

7.2 模式选择速查表

任务形状	推荐模式
任务可拆成「先后有序」的步骤	Prompt Chaining
问题明显分几类，各有各的处理	Routing
子任务互不依赖，想提速/多视角	Parallelization
任务开放复杂，无法预先确定步骤	Orchestrator-Workers
有明确好坏标准，想反复打磨	Evaluator-Optimizer

7.3 真实系统往往是「组合拳」

五种模式不是互斥的，真实系统往往是它们的组合：

一个「智能营销内容生成」系统，可能是这样：
① Routing 先判断用户要的是「海报文案」还是「视频脚本」
② 若是海报文案，用 Orchestrator-Workers 拆解成「标题/正文/卖点」分头写
③ 每一块内容，用 Evaluator-Optimizer 反复打磨
④ 最后用 Prompt Chaining 串成完整的成稿

一句话：五种模式像五块积木，单个模式解决一类问题，组合起来解决真实世界的复杂问题。高手不是「会背五种模式」，而是「一看任务，就知道该用哪几块、怎么拼」。

---