五种 Workflow 模式

Agent 设计模式五种 Workflow 模式业界已验证有效的五种 Workflow 编排模式。它们由简到繁，每种解决特定类型的问题。不追求最复杂的，追求最合适的。一句话速览 Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer Pattern 1

Prompt Chaining 提示链

把一个大任务拆解为多个顺序步骤，上一步的输出直接作为下一步的输入。每一步都是一次独立的 LLM 调用，专注做好一件事。步骤之间可以插入质量门（programmatic gate），只有通过检查才进入下一步。

输入

LLM Step 1

Gate

LLM Step 2

输出

适用场景任务能自然拆解为多个固定步骤；需要在中间环节做质量检查；用准确度换取延迟。真实例子：生成营销文案（Step 1）-> 翻译为目标语言（Step 2）-> 格式化为特定平台样式（Step 3）。中间 Gate：检查 Step 1 输出是否包含品牌关键信息。

Pattern 2

Routing 路由

先分类输入，然后将其导向不同的专门处理分支。每个分支可以有独立的 Prompt、模型甚至工具配置。核心价值：关注点分离，让每个分支只处理一种类型的输入。

输入

分类器

处理分支 A 处理分支 B 处理分支 C

适用场景输入类型多样，不同类型需要完全不同的处理逻辑；需要成本优化（简单问题用便宜模型，复杂问题用强模型）。真实例子：客服系统：简单 FAQ 用 Haiku（快且便宜），退款相关用 Sonnet + 订单工具，技术故障用 Sonnet + 日志查询。一个分类器决定走哪条路，实现成本与效果的最优平衡。

Pattern 3

Parallelization 并行化

让多个 LLM 调用同时执行，再聚合结果。有两种子模式： Sectioning（拆分并行）：把一个任务拆为独立子任务，并行处理后合并。 Voting（多次投票）：同一个任务用相同 Prompt 跑多次，取多数/最佳结果。

输入

LLM A LLM B LLM C

聚合

输出

适用场景子任务之间没有依赖关系；需要提升速度（并行比串行快）；需要提升置信度（多次投票降低随机性）。真实例子 - Sectioning：代码审查中，一个 LLM 检查安全漏洞，一个检查性能问题，一个检查代码风格，最后汇总所有发现。真实例子 - Voting：内容审核中，同一段文本让 3 个 LLM 分别判断是否违规，取多数意见作为最终结果。

Pattern 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

Evaluator-Optimizer 评估-优化

一个 LLM 负责生成，另一个 LLM 负责评判，二者形成迭代循环：生成者根据评判者的反馈不断改进输出，直到评判者认为满意或达到迭代上限。

输入

生成者 LLM

评判者 LLM

输出

虚线框 = 循环迭代直到满足标准

适用场景有明确的质量评估标准；迭代改进能显著提升输出质量；单次生成很难达到要求。真实例子：文学翻译中，生成者做初步翻译，评判者检查信达雅和风格一致性并给出具体修改建议，生成者根据建议改进。循环 2-3 次后输出终稿。每次迭代的翻译质量都在提升。

动手试试：模拟调度器

Prompt Chaining Routing Parallelization Orchestrator Evaluator

点击上方按钮查看不同模式的数据流转动画

总结

五种模式一览

模式核心思想典型场景复杂度

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 开始，只在确认简单方案不够用时才升级到更复杂的模式。每增加一层复杂度，都要问自己：这个复杂度带来的收益，值得额外的延迟、成本和调试难度吗？