译文信息

AI agent 会自主做决策，而工作流是把这种自主性组织起来的方式。它们确立执行模式，把 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，各步骤写在同一条 prompt 里。若效果已够好，就不必再上工作流复杂度。只有当一个 agent 稳定搞不定时，再拆成多步工作流。

并行式工作流

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

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

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

Agent 之间不交接工作——它们自主运行，产出共同服务于总任务。

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

可考虑并行式的场景：

  • 分域处理：例如一个 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。

在 Claude Developer Platform 上开始构建。