五种 Workflow 模式
Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer
本页解决的问题
先给结论「五种 Workflow 模式」要解决的关键问题是什么?
Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer
让这个结论先证明自己值得留下。 把这一页当成决策工具,而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果,以及一个能改变你判断的失败上。
写下一个问题:试完这个方法后,你能用什么证据回答它?
结论听起来很完整,却没有检查最关键的假设。
Sectioning(拆分并行):把一个任务拆为独立子任务,并行处理后合并。
Voting(多次投票):同一个任务用相同 Prompt 跑多次,取多数/最佳结果。
真实例子 - Voting:内容审核中,同一段文本让 3 个 LLM 分别判断是否违规,取多数意见作为最终结果。
| 模式 | 核心思想 | 典型场景 | 复杂度 |
|---|---|---|---|
| Prompt Chaining | 顺序串联,逐步处理 | 文案生成管道 | 低 |
| Routing | 分类导向,专门处理 | 智能客服分流 | 低 |
| Parallelization | 并行处理,聚合结果 | 多维度代码审查 | 中 |
| Orchestrator-Workers | 动态拆分,分布执行 | 跨文件代码修改 | 中高 |
| Evaluator-Optimizer | 生成评判,迭代改进 | 高质量翻译 | 中 |
「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…」。回看这条线索时,最值得保留的是:当输入、规模或风险改变,哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是,知道下一步要观察什么。
读完以后我先回头找它成立的条件,而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里,最先需要补的约束是什么?我想知道从阅读到第一次实践之间,哪一步最值得先做。
还没有这篇文章的讨论。