# AI 智能体的常见工作流模式——以及何时使用它们

作者：Hex4C59 · 发布于 2026-03-25

原文：https://hex4c59.cc/translations/common-workflow-patterns-for-ai-agents-and-when-to-use-them/


> **译文信息**  
> - 原文：[Common workflow patterns for AI agents—and when to use them](https://claude.com/blog/common-workflow-patterns-for-ai-agents-and-when-to-use-them)  
> - 作者：Anthropic  
> - 原文发布：2026-03-05  
> - 翻译发布：2026-03-25（东八区）

AI 智能体（agent）会自主做决策，**工作流**则规定这些决策如何配合：各步按什么顺序执行、何时交接，怎样在多步协作中得到可预期的结果。

当你需要多个 agent 一起工作时，真正要决定的是：**哪种模式适合你的问题**。

我们与数十个团队共建过 AI agent；在生产环境里，**三种模式**覆盖了绝大多数用例：**顺序式（sequential）**、**并行式（parallel）** 与 **评估-优化式（evaluator-optimizer）**。

它们各自解决不同问题；选错会在**延迟**、**token** 或**可靠性**上付出代价。本文拆解这三种模式，说明各自何时合适、如何组合。

## 工作流与 agent 如何协同

如果你带过团队，就已经理解工作流。

想象一条制造流水线：每个工位都有熟练工人，对自己那一步做决策，但**整体流向是事先设计好的**——即便某些步骤里还有动态决策，例如路由或重试。

Agent 工作流同理。

### 理解工作流与自主 agent

工作流**规定 agent 在哪些步骤中可以自主决策，以及怎样决策**。

**完全自主的 agent** 决定一切：用哪些工具、以什么顺序执行任务、何时停止。

**工作流提供结构**：规定总体流程、检查点，以及在每一步如何约束 agent 的运作边界，同时在边界内仍允许动态行为。

工作流中的每一步仍可利用 agent 的推理与工具调用，但**整体编排**走既定路径。这样，每一步都能利用 agent 的判断，整项任务又能按可预测的流程推进。

## Agent 工作流模式

在生产中，我们最常看到下面三种模式。把它们当作**积木**而非死板模板——需求变化时，你往往会**组合或嵌套**它们：

1. **顺序式工作流** —— 按固定顺序执行任务  
2. **并行式工作流** —— 多个 agent 同时跑彼此独立的任务  
3. **评估-优化式工作流** —— 输出需要迭代打磨  

每种类型对应特定问题，并在复杂度、成本与性能上有清晰的取舍。

| 模式 | 解决的问题 | 适用场景 | 代价 | 收益 |
|------|------------|----------|------|------|
| **顺序式** | 任务存在依赖：步骤 B 需要步骤 A 的输出 | 多阶段流程、数据管道、草稿-审核-润色类循环 | 增加延迟（每一步都要等上一步） | 让每个 agent 专注一件事，往往能提高准确度 |
| **并行式** | 子任务彼此独立，但串行做太慢 | 多维度评估、代码审查、文档分析 | 成本更高（多路并发 API 调用），且需要汇总策略 | 可能更快完成，并在工程团队之间划分职责 |
| **评估-优化式** | 初稿质量达不到要求 | 技术文档、客户沟通、需满足特定标准的代码生成 | 放大 token 消耗并增加迭代时间 | 通过结构化反馈循环产出更好的结果 |

从**能解决你问题的最简单模式**起步。默认用**顺序式**；只有当延迟成为瓶颈且任务彼此独立时，再考虑**并行**；只有当你**能量化**质量提升时，才加上**评估-优化**循环。

### 顺序式工作流

顺序式工作流按**预定顺序**执行任务。

每一阶段的 agent 处理输入、做决策、按需调用工具，再把结果交给下一阶段。由此形成清晰的**操作链**：上一步的输出就是下一步的输入。

**何时使用：** 顺序式适合任务自然拆成**有明确依赖**的多个阶段。你用一点延迟换取更高准确度——让每个 agent 专注一个子任务，而不是一次包揽所有事。

适合顺序式的情形包括：

* 多阶段流程，每一步都依赖上一步产出  
* 数据转换管道，每一阶段增加特定价值  
* 由于内在依赖而无法并行的任务  
* 迭代改进循环，例如草稿 → 审核 → 润色  

**何时避免：** 若单个 agent 就能把整个任务做好，就不要强行分段。若 agent 需要**协作**而不是**交接**，顺序式也不合适。若任务并不天然适合线性拆分，却硬拆成多步，只会增加无谓复杂度。

**示例：** 当每一步确实是不同类型的工作时，顺序式很合适：

* 先生成营销文案，再翻译成多种语言；或从文档抽取数据、按 schema 校验、再写入数据库  
* 内容审核管道：抽取内容 → 分类 → 应用审核规则 → 再路由到合适去处  

**实用建议：** 先尝试让**单个 agent**完成整条流程，把各步骤写在同一条提示中。若效果已经够好，就不必增加工作流的复杂度。只有当一个 agent **无法稳定完成**时，再拆成多步工作流。

### 并行式工作流

并行式工作流把**彼此独立**的任务分给多个 agent **同时**执行。不等前一个跑完再开下一个，而是多路并行，再合并结果。

当子任务互不依赖时，这种模式能带来速度上的收益。

思路接近分布式系统里的 **fan-out / fan-in**：把相同或相关的工作发给多个 agent，各自独立处理，再汇总或综合输出。

Agent 之间**不交接工作**，而是各自运行，再用各自产出的结果完成总任务。

**何时使用：** 当工作能拆成可独立处理的子任务、且并行有收益时；或当你需要**同一问题的多个视角**时。也便于**职责分离**：不同工程师可以各自维护、优化某个 agent，互不干扰。对复杂任务，**每个需要检查的方面单独用一次 AI 调用处理**，往往比在一次调用里同时兼顾所有方面效果更好。

可考虑并行式的场景：

* **分域处理**：例如一个 agent 处理查询，另一个并行做安全筛查  
* **评估**：每个 agent 负责不同质量维度  
* **投票/多判**：多个 agent 分析同一内容，再汇总判断  

**何时避免：** 若 agent 需要**累积上下文**或必须**承接彼此产出**，不要用并行。若 API 配额等资源让并发不划算，或你没有清晰策略处理**相互矛盾**的结果，也要谨慎。若汇总逻辑过于复杂或反而拉低质量，并行就不值得。

**示例：**

* 自动化评估（每个 agent 检查不同质量指标），或代码审查（多个 agent 各看不同漏洞类别）  
* 文档分析：并行做主题抽取、情感分析、事实核查，再汇总分析结果

**实用建议：** 在实现并行 agent **之前**先设计**汇总策略**：多数票？平均置信度？还是听最专长的 agent？有明确综合方案，才不至于拿到一堆冲突输出却无处下手。

### 评估-优化式工作流

评估-优化式工作流让两个 agent **反复配合**：一个生成内容，另一个按明确标准评估；生成方根据反馈修改。如此反复，直到输出达到质量门槛或达到最大迭代次数。

关键在于：**生成**与**评估**需要完成不同的判断。把它们分开后，生成方可以专注产出，评估方则专注于按统一质量标准检查结果。

**何时使用：** 当你有**清晰、可度量**的质量标准，且 AI 评估能**稳定**套用；并且从首稿到终稿的质量差距足够大，值得多付 token 与延迟。

可考虑评估-优化式的场景：

* 有具体要求的代码生成（安全规范、性能指标、风格指南）  
* 对语气与准确度要求高的专业沟通  
* 任何「首稿经常不达标」的场景  

**何时避免：** 若首稿已经满足需求，就不要迭代消耗 token。不适合实时、要立刻响应的应用；不适合简单例行任务（如基础分类）；也不适合标准**过于主观**、AI 难以一致评判的情形。若已有**确定性工具**（如代码风格检查工具 linter），优先用工具。若资源约束大于质量收益，也不要上这套模式。

**示例：**

* 生成 API 文档：生成方写文档，评估方对照代码库检查完整性、清晰度与准确性  
* 客户沟通：生成方写邮件草稿，评估方检查语气与政策合规  
* 产出 SQL：生成方写查询，评估方检查效率与安全问题  

**实用建议：** 迭代前先定**停止条件**：最大迭代次数、具体质量阈值。没有这些限制时，容易陷入成本高昂的循环：评估方不断挑小毛病，生成方不断微调，但质量已经不再提高。因此，要事先明确什么程度算**够好**。

## 如何选择合适的工作流模式

合适的工作流取决于任务结构、质量要求和资源约束。

选型前，先用**单次 agent 调用**试跑任务。若已达标，就不需要工作流。若不行，看清**差在哪里**——那往往指向该用哪种模式。

可参考这些问题：

* 单个 agent 能否有效完成？若能，就不要工作流。  
* 是否有清晰的顺序依赖？若有，用顺序式。  
* 子任务能否独立并行处理，且更快完成有价值？考虑并行式。  
* 质量是否会因迭代打磨而**明显**提升？考虑评估-优化式。  

选定模式后，还要考虑：

* **失败处理：** 为每一步定义降级行为与重试逻辑。  
* **延迟与成本：** 决定你能跑多少 agent、允许多少轮迭代。  
* **是否真在改进：** 用单次 agent 建立基线，才能判断工作流是否真的更好。  

**组合模式：** 三者并非互斥，可按复杂度嵌套。

* 评估-优化里可以对**多个评估维度**做并行评估。  
* 顺序式里可以在某一阶段做并行，再进入下一步。  

关键是让模式复杂度**匹配真实需求**。不要「能并行就并行」——只有并发带来明确收益时才加。不要「能迭代就迭代」——除非能量化证明质量提升。

## 有意识地演进工作流

我们最建议的做法：**从最简单的可行模式开始**。顺序式够用就不要并行；首稿够用就不要评估-优化循环。

这三种模式在需求变化时提供了清晰的**升级路径**：顺序式可以在耗时的瓶颈阶段引入并行处理；质量标准收紧时可以增加评估步骤。这些模式可以分别组合，通常不需要推倒重来。

若要更细的实现指导、示例以及包含混合方案在内的高级模式，可参阅完整白皮书：[_Building effective AI agents: architecture patterns and implementation frameworks_](https://resources.anthropic.com/ty-building-effective-ai-agents)。

在 [Claude Developer Platform](https://claude.com/platform/api) 上开始构建。