Agent 设计模式

五种 Workflow 模式

业界已验证有效的五种 Workflow 编排模式。它们由简到繁，每种解决特定类型的问题。不追求最复杂的，追求最合适的。

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