Common Workflow Patterns for AI Agents
原文: https://claude.com/blog/common-workflow-patterns-for-ai-agents-and-when-to-use-them
概述
AI agents 自主做出决策，而工作流（Workflows）则为这种自主性引入结构。工作流建立了执行模式，将 agent 的能力引导向需要协调步骤、可预测结果和编排时机的复杂问题。
当多个 agents 需要协同工作时，真正的决策在于选择哪种模式来适配你的问题。
在生产环境中，三种模式覆盖了绝大多数用例：顺序执行、并行执行和评估优化器。
工作流 vs 自主 Agent
工作流不取代 agent 的自主性，而是塑造 agent 自主性的应用方式和位置。
- 完全自主的 agent: 自己决定使用什么工具、以什么顺序执行任务、何时停止
- 工作流: 建立总体流程、定义检查点、设置边界，agent 在这些边界内仍有动态行为
每个工作流步骤仍然可以利用 agent 的推理和工具使用能力，但整体编排遵循预定义的路径。
三种核心工作流模式
| 模式 | 解决的问题 | 何时使用 | 权衡 | 收益 |
|---|---|---|---|---|
| Sequential | 任务有依赖：步骤 B 需要步骤 A 的输出 | 多阶段流程、数据管道、draft-review-polish 循环 | 增加延迟（每步等待上一步） | 通过让每个 agent 专注一件事来提高准确性 |
| Parallel | 任务独立，逐个处理太慢 | 多维度评估、代码审查、文档分析 | 成本更高（多个并发 API 调用）需要聚合策略 | 更快完成，跨工程团队分离关注点 |
| Evaluator-optimizer | 第一次输出质量不够好 | 技术文档、客户沟通、针对特定标准的代码生成 | 倍增 token 使用和迭代时间 | 通过结构化反馈循环生成更好的输出 |
核心建议: 从最简单的能解决问题的模式开始。默认选择顺序执行。当延迟是瓶颈且任务独立时转向并行。只有当能衡量质量提升时，才添加 evaluator-optimizer 循环。
1. 顺序工作流（Sequential Workflows）
顺序工作流按预定顺序执行任务。
每个阶段的 agent 处理输入、做出决策、必要时调用工具，然后将结果传递给下一阶段。输出线性流经系统，形成清晰的操作链。
何时使用
- 多阶段流程，每步依赖前一步输出
- 数据转换管道，每阶段增加特定价值
- 因固有依赖无法并行化的任务
- draft-review-polish 循环
何时避免
- 单个 agent 能有效处理整个任务时
- agents 需要协作而非顺序交接时
示例
- 生成营销文案 → 翻译成多种语言
- 从文档提取数据 → 针对 schema 验证 → 加载到数据库
- 内容审核管道：提取内容 → 分类 → 应用审核规则 → 路由
技巧
先尝试作为单个 agent 运行 pipeline，步骤只是 prompt 的一部分。如果这样就够了，就无需额外复杂性。
2. 并行工作流（Parallel Workflows）
并行工作流将独立任务分配给多个 agents 同时执行。
不等一个 agent 完成就启动下一个，多个 agents 同时运行，然后合并结果。这种模式在任务不依赖彼此时能显著提升速度。
类似于分布式系统中的 fan-out/fan-in 模式。
何时使用
- 任务可分解为独立子任务且同时处理有益时
- 需要多个视角审视同一问题时
- 不同工程师独立拥有和优化各自的 agents 时
- 复杂任务中，用独立 AI 调用处理每个考虑因素通常优于在一个调用中同时处理所有
何时避免
- agents 需要累积上下文或必须互相构建时
- API 配额等资源限制使并发处理不切实际时
- 缺乏清晰策略处理不同 agents 的矛盾结果时
- 结果聚合过于复杂或降级输出质量时
示例
- 自动化评估：每个 agent 检查不同质量指标
- 代码审查：多个 agents 检查不同漏洞类别
- 文档分析：并行提取主题、情感分析和事实核查
技巧
在实现并行 agents 前先设计聚合策略。是取多数票？平均置信度分数？还是听从最专业的 agent？
3. 评估优化器工作流（Evaluator-Optimizer Workflows）
评估优化器工作流将两个 agents 配对形成迭代循环：
- 一个生成内容
- 另一个根据标准评估
- 生成器根据反馈改进
- 循环直到输出达到质量阈值或最大迭代次数
核心洞察：生成和评估是不同认知任务。分离它们让每个 agent 专业化——生成器专注产出内容，评估器专注应用一致的质量标准。
何时使用
- 有清晰、可衡量的质量标准，AI 评估器能一致应用时
- 首次尝试和最终质量之间的差距足够大，值得额外 token 和延迟投入时
何时避免
- 首次尝试质量已满足需求时
- 实时应用需要即时响应时
- 简单分类等日常任务时
- 评估标准对 AI 评估器来说过于主观时
- 存在确定性工具（如代码风格的 linter）时
示例
- API 文档生成（生成器写文档，评估器对照代码库检查完整性、清晰度和准确性）
- 客户沟通（生成器起草邮件，评估器评估语调和策略合规性）
- SQL 查询生成（生成器写查询，评估器检查效率和安全性问题）
技巧
在开始迭代前设置清晰的停止标准。定义最大迭代次数和具体质量阈值。没有这些护栏，你可能陷入昂贵循环——评估器不断发现小问题，生成器不断调整，但质量早已 plateau。
选择合适的工作流模式
选择正确的模式取决于任务结构、质量要求和资源约束。
决策问题
- 单个 agent 能有效处理这个任务吗？ → 如果是，根本不需要工作流
- 任务有清晰顺序依赖吗？ → 使用顺序工作流
- 子任务能独立同时处理，且更快完成有帮助吗？ → 考虑并行工作流
- 迭代改进能显著提升质量吗？ → 考虑评估优化器模式
还需要考虑
- 故障处理: 为每步定义 fallback 行为和重试逻辑
- 延迟和成本约束: 决定你能运行多少 agents、负担多少次迭代
- 衡量改进: 用单个 agent 设置基线，这样能判断工作流是否真正有帮助
组合模式
这三种模式并非互斥。复杂性需求出现时可以嵌套它们：
- 评估优化器工作流可以在评估阶段采用并行处理——多个评估器同时评估不同质量维度
- 顺序工作流可以在某些阶段包含并行处理——在进入下一步之前多个独立操作同时发生
关键是将模式复杂度与实际需求匹配。不要因为能做到就添加并行处理——只有并发执行提供明确好处时才加。
进阶建议
从能工作的最简单模式开始。如果顺序工作流能处理你的用例，不要添加并行化。如果首次质量够好，跳过评估优化器循环。
这三种模式提供了清晰升级路径：
- 顺序工作流可以在瓶颈阶段加入并行处理
- Agent 方法可以在质量标准收紧时添加评估
- 因为这些模式是模块化的，不需要完全重写