工程进阶 · 可靠 Agent 的工程模式

五种 Workflow 模式

Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer

本页解决的问题

先给结论

「五种 Workflow 模式」要解决的关键问题是什么?

Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer

判断标准

让这个结论先证明自己值得留下。 把这一页当成决策工具,而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果,以及一个能改变你判断的失败上。

下一步

写下一个问题:试完这个方法后,你能用什么证据回答它?

常见误区

结论听起来很完整,却没有检查最关键的假设。

Pattern 1
1
Prompt Chaining
提示链
把一个大任务拆解为多个顺序步骤,上一步的输出直接作为下一步的输入。每一步都是一次独立的 LLM 调用,专注做好一件事。步骤之间可以插入质量门(programmatic gate),只有通过检查才进入下一步。
输入
LLM Step 1
Gate
LLM Step 2
输出
适用场景
任务能自然拆解为多个固定步骤;需要在中间环节做质量检查;用准确度换取延迟。
真实例子:生成营销文案(Step 1)-> 翻译为目标语言(Step 2)-> 格式化为特定平台样式(Step 3)。中间 Gate:检查 Step 1 输出是否包含品牌关键信息。
Pattern 2
2
Routing
路由
分类输入,然后将其导向不同的专门处理分支。每个分支可以有独立的 Prompt、模型甚至工具配置。核心价值:关注点分离,让每个分支只处理一种类型的输入。
输入
分类器
处理分支 A
处理分支 B
处理分支 C
适用场景
输入类型多样,不同类型需要完全不同的处理逻辑;需要成本优化(简单问题用便宜模型,复杂问题用强模型)。
真实例子:客服系统:简单 FAQ 用 Haiku(快且便宜),退款相关用 Sonnet + 订单工具,技术故障用 Sonnet + 日志查询。一个分类器决定走哪条路,实现成本与效果的最优平衡。
Pattern 3
3
Parallelization
并行化
让多个 LLM 调用同时执行,再聚合结果。有两种子模式:
Sectioning(拆分并行):把一个任务拆为独立子任务,并行处理后合并。
Voting(多次投票):同一个任务用相同 Prompt 跑多次,取多数/最佳结果。
输入
LLM A
LLM B
LLM C
聚合
输出
适用场景
子任务之间没有依赖关系;需要提升速度(并行比串行快);需要提升置信度(多次投票降低随机性)。
真实例子 - Sectioning:代码审查中,一个 LLM 检查安全漏洞,一个检查性能问题,一个检查代码风格,最后汇总所有发现。
真实例子 - Voting:内容审核中,同一段文本让 3 个 LLM 分别判断是否违规,取多数意见作为最终结果。
Pattern 4
4
Orchestrator-Workers
编排者-工人
一个中心 LLM(编排者)动态拆解任务并分配给多个工人 LLM。与 Parallelization 的区别:子任务由编排者在运行时动态决定,代码里没有预先定义。这是最接近 Agent 的 Workflow 模式。
输入
编排者 LLM
Worker 1
Worker 2
Worker N...
合并
适用场景
子任务不能提前预知(需要根据输入动态决定);涉及对多个文件/资源的并行操作。
真实例子:代码修改需求「给项目加国际化支持」。编排者分析代码库后动态决定:Worker 1 改 Button 组件、Worker 2 改 Header 组件、Worker 3 创建语言文件。不同需求产生不同数量和类型的 Worker。
Pattern 5
5
Evaluator-Optimizer
评估-优化
一个 LLM 负责生成,另一个 LLM 负责评判,二者形成迭代循环:生成者根据评判者的反馈不断改进输出,直到评判者认为满意或达到迭代上限。
输入
生成者 LLM
评判者 LLM
输出
虚线框 = 循环迭代直到满足标准
适用场景
有明确的质量评估标准;迭代改进能显著提升输出质量;单次生成很难达到要求。
真实例子:文学翻译中,生成者做初步翻译,评判者检查信达雅和风格一致性并给出具体修改建议,生成者根据建议改进。循环 2-3 次后输出终稿。每次迭代的翻译质量都在提升。
动手试试:模拟调度器
点击上方按钮查看不同模式的数据流转动画
总结
五种模式一览
模式 核心思想 典型场景 复杂度
Prompt Chaining 顺序串联,逐步处理 文案生成管道
Routing 分类导向,专门处理 智能客服分流
Parallelization 并行处理,聚合结果 多维度代码审查
Orchestrator-Workers 动态拆分,分布执行 跨文件代码修改 中高
Evaluator-Optimizer 生成评判,迭代改进 高质量翻译
"Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short."
不要追求最复杂的模式,要追求最合适的。从最简单的 Prompt Chaining 开始,只在确认简单方案不够用时才升级到更复杂的模式。每增加一层复杂度,都要问自己:这个复杂度带来的收益,值得额外的延迟、成本和调试难度吗?

「Pattern 1」里的算法代价曲线

「Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer」真正训练的不是背诵步骤,而是识别重复工作:输入变大时,程序到底多做了多少次比较、移动或递归。

先找重复工作,再谈快慢

「Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer」可以拆成输入规模、每轮做什么、以及是否能缩小下一轮范围三个问题。Big-O 是描述增长趋势的语言,不是对每台机器的精确计时;常数、内存和真实数据分布也会影响最终结果。

别把理论最优当成无条件最优

面对 AI 写出的算法,先用小输入手算一遍,再用逐渐放大的数据做基准测试。这样才能把「Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer」从一句结论变成可检查的性能判断。

从「Pattern 1」走到「Pattern 2」

「Pattern 1」先把问题落在「1 Prompt Chaining 提示链 把一个大任务拆解为 多个顺序步骤 ,上一步的输出直接作为下一步的输入。每一步都是一次独立的 LLM 调用,专注做好一件事。步骤之间可以插入质量门(programmatic gate),只有通过检查才进入下一步。 输入 LLM Step 1 Gate LLM Step 2 输出 适用场景 任务能自然拆解为多个固定步骤;需要在中间环节做质量检查;用准确度换取延迟。 真实例子…」上;到了「Pattern 2」,讨论继续推进到「2 Routing 路由 先 分类输入 ,然后将其导向不同的专门处理分支。每个分支可以有独立的 Prompt、模型甚至工具配置。核心价值:关注点分离,让每个分支只处理一种类型的输入。 输入 分类器 处理分支 A 处理分支 B 处理分支 C 适用场景 输入类型多样,不同类型需要完全不同的处理逻辑;需要成本优化(简单问题用便宜模型,复杂问题用强模型)。 真实例子: 客服系统:简单 FAQ 用 Haiku(快且便宜),退款…」。两段连起来,重点就不只是记住一个结论,而是看清它成立所依赖的条件。

把这条判断带到下一个场景

算法题换成真实任务后,先找出重复工作,再问输入规模如何变化,最后用一个小基准验证理论判断。这样不会把复杂度记成脱离场景的标签。

  • 「Pattern 1」:1 Prompt Chaining 提示链 把一个大任务拆解为 多个顺序步骤 ,上一步的输出直接作为下一步的输入。每一步都是一次独立的 LLM 调用,专注做好一件事。步骤之间可以插入质量门(programmatic gate),只有通过检查才进入下一步。 输入 LLM Step 1 Gate LLM Step 2 输出 适用场景 任务能自然拆解为多个固定步骤;需要在中间环节做质量检查;用准确度换取延迟。 真实例子…
  • 「Pattern 2」:2 Routing 路由 先 分类输入 ,然后将其导向不同的专门处理分支。每个分支可以有独立的 Prompt、模型甚至工具配置。核心价值:关注点分离,让每个分支只处理一种类型的输入。 输入 分类器 处理分支 A 处理分支 B 处理分支 C 适用场景 输入类型多样,不同类型需要完全不同的处理逻辑;需要成本优化(简单问题用便宜模型,复杂问题用强模型)。 真实例子: 客服系统:简单 FAQ 用 Haiku(快且便宜),退款…
  • 「动手试试:模拟调度器」:Prompt Chaining Routing Parallelization Orchestrator Evaluator 点击上方按钮查看不同模式的数据流转动画 总结 五种模式一览 模式 核心思想 典型场景 复杂度 Prompt Chaining 顺序串联,逐步处理 文案生成管道 低 Routing 分类导向,专门处理 智能客服分流 低 Parallelization 并行处理,聚合结果 多维度代码审查 中 Or…

最后的「动手试试:模拟调度器」把讨论落到「Prompt Chaining Routing Parallelization Orchestrator Evaluator 点击上方按钮查看不同模式的数据流转动画 总结 五种模式一览 模式 核心思想 典型场景 复杂度 Prompt Chaining 顺序串联,逐步处理 文案生成管道 低 Routing 分类导向,专门处理 智能客服分流 低 Parallelization 并行处理,聚合结果 多维度代码审查 中 Or…」。回看这条线索时,最值得保留的是:当输入、规模或风险改变,哪些判断需要重新做一遍。

标记为已学完 阅读进度会自动记录
← 上一篇下一篇 →

继续阅读

同一条线上的下一篇。

文章讨论

读到这里,留下一个判断。

把刚想明白的地方、还没想通的问题,留给下一位一起学习的人。

正在讨论 五种 Workflow 模式 可靠 Agent 的工程模式
3条讨论文章讨论 · 与共学社区同步
在共学社区查看
AM
Asha Morgan内容编辑
观点实践记录

我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是,知道下一步要观察什么。

文章讨论7 有帮助
LH
Lin Harper独立开发者
观点观点

读完以后我先回头找它成立的条件,而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。

文章讨论5 有帮助
KM
Kiki Moore产品运营
问题问题

如果把这个判断放到真实工作里,最先需要补的约束是什么?我想知道从阅读到第一次实践之间,哪一步最值得先做。

文章讨论4 有帮助