AI 智能体常见工作流模式深度解析：何时顺序、何时并行、何时迭代优化

一、引言：Agent 需要自主性，也需要工程结构

原文链接：Common workflow patterns for AI agents—and when to use them
来源：Claude Blog / Anthropic
发布时间：2026 年 3 月 5 日

过去两年，开发者谈到 AI Agent 时，常常会把重点放在“自主性”上：模型能否自己决定下一步、能否选择工具、能否规划任务、能否在不确定环境中持续推进。这个方向没有错，但一旦进入生产系统，另一个问题会变得更关键：Agent 的执行过程是否可控、可调试、可复现、可度量。

Anthropic 这篇文章的核心观点可以概括为一句话：工作流不是为了削弱 Agent 的智能，而是为了给智能体系统提供可控的执行结构。 在每个步骤内部，Agent 仍然可以推理、调用工具、处理局部不确定性；但在步骤之间，工作流负责规定边界、依赖、并发、质量门槛和停止条件。

换句话说，生产级 Agent 系统不是简单地让一个模型“随便想办法完成任务”，而是在自主性和确定性之间做工程折中：

AI Agent 工作流选型总览

图注：本文配图均为作者基于 Anthropic 原文机制整理的概念示意，并非官方架构图。

原文重点讨论三种常见工作流模式：

Sequential workflows：顺序工作流，解决步骤依赖问题；
Parallel workflows：并行工作流，解决独立子任务的延迟问题；
Evaluator-optimizer workflows：评估器-优化器工作流，解决高质量输出的迭代改进问题。

这三种模式并不是越复杂越好。恰恰相反，原文反复强调：先从最简单的方案开始。 如果单个 Agent 调用已经能稳定完成任务，就不要急着引入多 Agent、多步骤或循环评估。工作流的价值必须通过质量、延迟、成本或可治理性来证明，而不是为了让架构图看起来更高级。

二、工作流与自主 Agent：先划清系统边界

在讨论具体模式之前，需要先区分两个概念：自主 Agent 和 工作流化 Agent 系统。

自主 Agent 更像一个开放式执行器。它接收目标后，自行决定使用哪些工具、按什么顺序执行、什么时候停止、如何处理异常。这种方式在探索性任务中很有吸引力，例如研究资料、修复未知 bug、浏览代码库、调查生产事故等。

工作流化 Agent 系统则更像一个有明确阶段边界的执行管线。系统提前规定任务如何拆分、哪些步骤必须先后执行、哪些步骤可以并行、什么结果需要评估、何时重试、何时降级、何时终止。每个阶段可以仍然由 LLM 或 Agent 完成，但阶段之间的控制权属于工作流。

一个实用判断是：

问题	更偏向自主 Agent	更偏向工作流
任务路径是否提前可知	很难提前确定	大体可枚举
输出质量是否有明确标准	标准模糊	标准清晰
是否需要审计和复现	相对弱	很强
是否有固定阶段依赖	不明显	很明显
失败处理是否可规则化	难规则化	可设计 retry、fallback、人工介入

很多生产系统最终会采用混合形态：外层是工作流，内层步骤由 Agent 执行。外层保证系统不会失控，内层保留模型处理局部复杂性的能力。

三、模式一：顺序工作流——把复杂任务拆成可验证的依赖链

顺序工作流是最容易理解、也最常见的 Agent 工作流。它按照预定义顺序执行多个步骤，前一步的输出成为后一步的输入。

顺序工作流运行机制

3.1 运行机制

顺序工作流的核心是 stage boundary：每个阶段都有清晰输入、输出和验收条件。典型流程如下：

接收用户请求或外部事件；
第一个 Agent/步骤完成局部任务；
对中间结果做格式化、校验或压缩；
将结果传给下一个步骤；
重复直到最终输出。

例如，一个文档入库系统可以拆成：

原始文档 → 信息抽取 → Schema 校验 → 去重合并 → 写入数据库 → 生成审计记录

这里每一步都依赖前一步输出。信息抽取还没完成，就无法校验字段；字段没有校验，就不应该写入数据库。这类任务天然适合顺序工作流。

从工程实现看，顺序工作流通常需要为每个步骤定义统一接口：

type Step<Input, Output> = {
  name: string
  run(input: Input, context: RunContext): Promise<Output>
  validate?(output: Output): Promise<void>
}

重点不在于这个接口本身，而在于它迫使系统把“Agent 说了一段话”变成“某个步骤产出了可消费的结构化结果”。这会显著提升可调试性：当最终结果失败时，开发者能定位是抽取失败、校验失败，还是写入失败。

3.2 适用场景

顺序工作流适合以下场景：

步骤之间有强依赖：A 的输出是 B 的输入；
任务可以拆成稳定阶段：每个阶段职责明确；
需要中间检查点：可以在每一步记录输入、输出、耗时、Token 和错误；
需要逐步降低不确定性：先提取事实，再基于事实做判断；
需要把复杂 prompt 拆小：一个大而全的 prompt 不稳定时，将任务拆成多个窄任务。

典型例子包括：

场景	顺序拆分方式
营销内容本地化	生成英文文案 → 术语审查 → 多语言翻译 → 本地化润色
内容审核	抽取内容 → 分类风险 → 应用规则 → 路由到处理队列
数据处理	文档解析 → 字段抽取 → Schema 校验 → 数据写入
代码迁移	扫描依赖 → 修改代码 → 运行测试 → 生成变更说明

3.3 工程收益

顺序工作流的最大收益不是“更智能”，而是更可控：

可观测：每一步都可以记录日志和指标；
可回放：可以用同一中间输入重跑某个阶段；
可替换：某个 Agent 表现不好时，只替换该阶段；
可降级：某一步失败时，可以重试、跳过、转人工或返回部分结果；
可做单元测试：用固定输入测试单个阶段的输出约束。

3.4 不该使用的情况

顺序工作流也有明显代价：延迟会线性累加。如果每一步都需要一次模型调用，五步流程就至少有五次模型延迟。它也会增加数据传递和状态管理成本。

因此，不应在以下场景强行使用顺序工作流：

单个 Agent 调用已经能稳定完成任务；
拆分后的每一步边界并不清晰；
多个步骤只是复述同一件事，没有信息增益；
用户期望实时响应，无法接受多次模型调用；
为了“看起来像架构”而把简单任务拆成流水线。

一个好的实践是：先建立单 Agent baseline，再根据失败点拆分。 如果发现单个 Agent 经常在“先抽取再判断”这类任务中混淆事实和结论，再把抽取和判断拆成两个顺序步骤。

四、模式二：并行工作流——用 fan-out/fan-in 降低延迟并分离视角

并行工作流适用于多个子任务彼此独立、但顺序执行太慢的场景。它的结构类似分布式系统中的 fan-out / fan-in：先把任务分发给多个 Agent，再把结果聚合回来。

并行工作流的 fan-out/fan-in 机制

4.1 运行机制

并行工作流通常包含三个阶段：

任务拆分：将原始请求拆成多个互不依赖的子任务；
并发执行：多个 Agent 或多个模型调用同时运行；
结果聚合：汇总多个结果，生成最终答案、评分或路由决策。

并行可以有两种常见形态。

第一种是 任务分片：每个 Agent 处理不同子任务。例如分析一篇长文时，一个 Agent 抽取主题，一个 Agent 做事实核查，一个 Agent 判断情绪倾向。

第二种是 视角分离：多个 Agent 处理同一输入，但从不同角度审查。例如代码审查中，一个 Agent 看安全漏洞，一个看性能问题，一个看可维护性，一个看测试覆盖。

4.2 适用场景

并行工作流适合以下情况：

子任务之间没有数据依赖；
总延迟比单次调用成本更重要；
不同维度需要不同专家 prompt；
需要多个独立判断降低漏检风险；
可以设计清晰的结果聚合策略。

典型应用包括：

场景	并行方式	聚合方式
代码审查	安全、性能、可读性、测试分别审查	汇总问题并按严重度排序
文档分析	主题、事实、情绪、实体并行抽取	合并成结构化报告
用户请求处理	主任务响应与安全筛查并行	安全结果决定是否放行
分类任务	多个分类器独立判断	多数投票或置信度加权
RAG 问答	多路检索、重排、答案生成并行探索	汇总证据后生成答案

4.3 关键难点：聚合比并发更难

并行工作流最容易被低估的地方，不是如何发起多个 API 请求，而是如何处理多个输出之间的冲突。

如果三个 Agent 给出三个结论：一个认为代码安全，一个认为存在高危注入风险，一个认为证据不足，系统应该如何决策？这不能靠“再问一次模型”随意解决，而需要提前设计聚合策略：

多数投票：适合分类、判断、简单偏好选择；
置信度加权：适合每个 Agent 能给出可解释评分的场景；
专家优先：安全、合规等高风险领域优先采纳专业审查 Agent；
规则兜底：只要任一高优先级检查命中，就触发阻断或人工复核；
汇总 Agent：让一个专门的聚合 Agent 读取全部结果并生成最终报告。

并行工作流的工程质量，取决于聚合层是否明确。否则你得到的只是更快、更贵、但更难解释的一组矛盾输出。

4.4 成本与限流问题

并行会降低墙钟时间，但不会降低总计算量。相反，它通常会增加：

并发 API 调用数量；
峰值速率限制压力；
输出聚合 Token；
日志、追踪和错误处理复杂度。

因此，并行工作流的收益主要体现在 延迟优化 和 职责分离，而不是成本优化。只有当任务确实可独立拆分，并且延迟是瓶颈时，并行才值得引入。

五、模式三：评估器-优化器工作流——把生成与质检拆成闭环

评估器-优化器工作流适用于“第一次生成通常不够好，但有明确标准可以迭代改进”的场景。它把系统拆成两个角色：

Optimizer / Generator：负责生成候选答案、代码、文档或方案；
Evaluator：根据标准检查候选结果，并给出可执行反馈。

评估器-优化器工作流闭环

5.1 运行机制

基本循环如下：

生成候选结果 → 根据标准评估 → 若不达标则反馈修改 → 再次生成 → 达标或达到预算后停止

这个模式的关键不是“让模型多想几次”，而是把两个认知任务拆开：生成和评价。

生成器倾向于产出内容，评估器则专注于发现缺陷、应用标准、提出修正方向。两者可以使用不同 prompt、不同模型、不同工具，甚至不同温度参数。例如生成器使用更开放的采样策略，评估器使用更保守、更结构化的输出格式。

5.2 适用场景

评估器-优化器适合高质量要求且评估标准清晰的任务：

场景	评估器检查什么
代码生成	编译是否通过、测试是否通过、安全规则、边界条件
SQL 生成	是否可执行、是否使用参数化查询、是否有全表扫描风险
技术文档	是否完整、是否准确、是否遗漏前提、是否有矛盾
客服回复	语气、政策合规、是否解决用户问题
数据分析报告	指标解释是否正确、结论是否有证据支撑

这类任务有一个共同点：初稿可以有瑕疵，但评估器能够指出具体改进方向，并且改进后的质量可以被验证。

5.3 停止条件比循环本身更重要

评估器-优化器最大的风险是进入低收益循环：每轮都能发现一些小问题，但整体质量已经接近平台期，继续迭代只是在消耗 Token 和时间。

因此必须预先设置停止条件：

最大迭代次数，例如最多 3 轮；
质量阈值，例如评分达到 0.9；
阻断问题清零，例如没有高危安全问题；
增益阈值，例如连续两轮评分提升小于 0.02；
时间或成本预算，例如 15 秒内必须返回。

一个可落地的控制逻辑如下：

for (let i = 0; i < maxIterations; i++) {
  const candidate = await optimizer.generate(input, feedback)
  const report = await evaluator.check(candidate, criteria)

  if (report.pass || report.score >= threshold) {
    return candidate
  }

  if (!report.actionableFeedback.length) {
    return candidate
  }

  feedback = report.actionableFeedback
}

return bestCandidate

在生产系统中，bestCandidate 不一定是最后一轮结果，而应该是历史迭代中评分最高、且没有阻断问题的结果。

5.4 不该使用的情况

不要把评估器-优化器当成默认增强器。以下情况通常不适合：

第一次生成已经足够好；
实时交互不允许多轮延迟；
任务是简单分类或抽取，不需要迭代；
评估标准非常主观，评估器无法稳定判断；
已有确定性工具可以完成检查，例如 lint、typecheck、单元测试；
成本预算无法承受多轮模型调用。

更好的做法是：先用确定性工具做硬检查，再用评估器做语义检查。比如代码生成场景中，编译、测试、lint 应该由工具执行；评估器负责检查设计合理性、边界遗漏和安全风险。

六、三种模式的使用场景对比

把三种模式放在一起看，选择逻辑其实很清晰：

AI Agent 工作流模式对比矩阵

维度	单 Agent	顺序工作流	并行工作流	评估器-优化器
主要目标	最小复杂度	处理依赖链	降低总延迟 / 分离视角	提升质量
任务结构	简单或开放	阶段明确、前后依赖	子任务独立	可生成、可评估、可改进
延迟	最低	随步骤数增加	墙钟时间较低，峰值并发高	多轮迭代，通常最高
成本	最低	中等	API 调用数增加	Token 和调用数增加
调试性	取决于日志	强	中等，聚合层关键	强，但需要记录每轮反馈
典型风险	单次输出不稳定	过度拆分、延迟累加	结果冲突、聚合困难	无限打磨、收益递减
最适合	baseline、简单任务	数据管道、审核流程、迁移流程	多维审查、并发抽取、投票	代码、文档、SQL、高标准输出

可以把选型压缩成四个问题：

单个 Agent 是否已经足够好？ 如果是，停止，不要引入工作流。
子任务是否存在强依赖？ 如果是，优先顺序工作流。
子任务是否相互独立且延迟是瓶颈？ 如果是，考虑并行工作流。
输出是否需要基于明确标准反复改进？ 如果是，考虑评估器-优化器。

这也是原文最重要的工程建议：不要从模式出发设计系统，而要从失败模式出发选择模式。

七、组合模式：真实系统往往不是三选一

在真实生产系统中，这三种模式经常组合使用。例如一个代码修复 Agent 可能是这样的：

顺序阶段一：理解 issue、定位相关代码；
并行阶段：安全 Agent、测试 Agent、架构 Agent 同时审查修复方案；
顺序阶段二：生成 patch、运行测试；
评估器-优化器：根据测试失败和审查意见迭代修改；
顺序阶段三：生成变更说明并请求人工确认。

组合模式要特别注意两个问题。

第一，不要让状态传播变得不可控。每个阶段传递给下一阶段的内容应该是结构化摘要，而不是把所有中间对话原样塞进去。否则上下文会迅速膨胀，成本和错误传播都会失控。

第二，每个复杂模式都要有明确收益假设。例如并行阶段的收益假设是“多角度审查能降低漏检率”；评估器-优化器的收益假设是“迭代能让测试通过率提升”。没有指标，就无法判断复杂度是否值得。

八、落地建议：从 baseline 到生产工作流

基于原文观点和工程实践，可以按以下路径落地 Agent 工作流：

8.1 先建立单 Agent baseline

先把任务完整交给单个 Agent，并记录：

成功率；
平均延迟；
Token 成本；
常见失败类型；
用户是否需要人工修正。

只有当 baseline 暴露出稳定失败模式时，再引入工作流。否则复杂度只会掩盖问题。

8.2 用失败模式决定拆分方式

失败模式	推荐模式
经常漏掉固定步骤	顺序工作流
某一步输出格式不稳定	顺序工作流 + 校验
多个独立检查耗时太长	并行工作流
单次生成质量波动大	评估器-优化器
安全/合规漏检风险高	并行审查 + 高优先级阻断规则
初稿可用但需要打磨	评估器-优化器

8.3 每个步骤都要可观测

不要只记录最终答案。生产系统至少应该记录：

每个步骤的输入摘要；
每个步骤的结构化输出；
模型、参数、工具调用；
Token、耗时、重试次数；
校验错误和降级路径；
聚合器如何处理冲突。

这些日志既用于 debug，也用于评估工作流是否真的带来收益。

8.4 优先使用确定性检查

如果问题可以用确定性程序检查，就不要让 LLM 猜。例如：

JSON Schema 校验；
TypeScript 类型检查；
单元测试；
SQL explain；
lint 和格式化；
权限、配额、敏感操作确认。

LLM 更适合处理语义、意图和模糊判断；确定性工具适合处理规则、格式和执行结果。好的 Agent 工作流会把两者结合起来。

九、总结：工作流是 Agent 的工程化约束层

AI Agent 的价值来自模型的推理和工具使用能力，但生产级可靠性来自工程结构。Anthropic 这篇文章给出的三种模式，本质上对应三类问题：

顺序工作流解决“步骤之间有依赖”的问题；
并行工作流解决“独立任务顺序执行太慢”的问题；
评估器-优化器工作流解决“单次生成质量不够稳定”的问题。

真正重要的不是记住这些模式名称，而是理解它们背后的取舍：顺序带来可控性但增加延迟；并行降低墙钟时间但增加聚合难度；评估器-优化器提升质量但放大成本和迭代时间。

因此，设计 Agent 工作流时最稳妥的原则是：从单 Agent baseline 开始，用可观测的失败模式驱动架构演进。 当你能明确说出“为什么需要拆分、为什么需要并行、为什么需要迭代、如何验证收益”时，工作流才是在增强 Agent；否则，它只是把一个不稳定系统包装成了更复杂的不稳定系统。

「真诚赞赏，手留余香」