跳到主要内容

选择真正能落地的 AI Agent 工作流模式

· 阅读需 5 分钟
Claude Dev
Claude Dev
Claude Dev

大多数团队做 agent 失败，不是因为模型不够强。

真正的问题是：太早选了错误的工作流模式，编排过度、组件过多、复杂度却没有明确收益。

Anthropic 最近这篇关于常见 agent workflow patterns 的官方文章很有价值，但这篇会改写成面向生产环境开发者的版本。

大多数团队忽略的一条规则​

先从满足质量要求的最简单模式开始。

落地上就是：

  1. 先试单次单 agent 调用
  2. 只有在依赖关系强制顺序时才加串行步骤
  3. 只有在任务真正独立且延迟敏感时才加并行
  4. 只有在质量提升可度量时才加 evaluator-optimizer 循环

跳过这个顺序，通常会付出延迟、token 成本和调试成本。

模式 1：串行工作流（Sequential）​

当 B 步骤依赖 A 步骤结果时，用串行。

可以把它看作 pipeline：

  • extract
  • transform
  • validate
  • route

适用场景​

  • 多阶段且有强依赖的任务
  • 每阶段提供不同价值的数据流水线
  • Draft -> review -> polish 流程

不适用场景​

  • 单个 agent 已能稳定完成任务
  • 步骤拆分只是形式拆分，实际可合并

开发者取舍​

  • 延迟更高
  • 分阶段控制力和可观测性更好

快速判断​

去掉某个阶段后输出几乎不变，这个阶段大概率是冗余的。

模式 2：并行工作流（Parallel）​

当子任务彼此独立且可同时运行时，用并行。

用分布式系统术语就是 fan-out/fan-in：

  • fan out 到多个 agents
  • fan in 通过聚合策略收敛

适用场景​

  • 多维度评估（安全、风格、正确性）
  • 按类别拆分的安全/代码审查
  • 独立视角的文档分析

不适用场景​

  • agents 之间需要共享且持续演化的上下文
  • 没有健壮的聚合策略
  • API 并发或配额限制抵消速度收益

开发者取舍​

  • 完成更快
  • 成本更高，聚合复杂度更高

快速判断​

如果聚合逻辑比每个并行 worker 还复杂，说明你并行过度了。

模式 3：Evaluator-Optimizer 工作流​

当首稿质量达不到要求，且质量标准明确时，用 evaluator-optimizer。

结构是：

  • Generator 产出草稿
  • Evaluator 按明确标准打分
  • Generator 迭代修订
  • 达到阈值或迭代上限后停止

适用场景​

  • 有严格标准的代码生成
  • 语气和精度要求高的高风险文档/沟通
  • 需要安全/性能检查的 SQL 或查询生成

不适用场景​

  • 需要即时响应的实时交互
  • 标准过于主观，evaluator 无法稳定判断
  • 已有确定性工具可完成校验（linter、schema validator）

开发者取舍​

  • 质量可能显著提升
  • token 与延迟更高，且有无效微迭代风险

快速判断​

如果第 3 轮以后改进很小，就该降低迭代上限。

一个实用决策树​

可直接放到设计评审文档：

  1. 单个 agent 能否稳定解决？ 能，就停止。
  2. 是否存在硬性步骤依赖？ 有，就用串行。
  3. 子任务是否独立且延迟敏感？ 是，就加并行分支。
  4. 首次输出质量是否低于标准且可量化？ 是，就在必要处加 evaluator-optimizer。

这样能让复杂度和真实需求匹配。

上线前就该定义好的失败处理​

不管用哪种模式，上线前都要先定义：

  • 每阶段重试策略
  • 超时预算
  • 降级/回退行为
  • 部分失败处理策略
  • 矛盾输出的仲裁规则

不定义这些，你的“agent 架构”就只是 demo。

先建立基线，再谈编排​

Anthropic 的建议方向是对的：先用更简单方式建立基线。

团队至少应追踪：

  • task success rate
  • latency p50/p95
  • 单次成功运行的 token 成本
  • 人工修正率

只有这些指标有实质提升，才值得保留额外编排。

真正常用的组合模式​

这些模式是积木，不是互斥选项。

两个常见组合：

  • Sequential + Parallel：整体串行，局部一两个阶段并行化
  • Parallel + Evaluator：多个生成或审查分支汇入一个聚焦 evaluator

除非你能用指标解释质量/成本收益，否则不要嵌套太深。

最后结论​

工作流模式不是架构表演，它是成本和质量控制器。

如果你要系统能上线且可维护：

  • 从简单开始
  • 只有在瓶颈被证明后再增加结构
  • 每一次复杂度提升都要可度量

这才是把 agent 实验变成生产工作流的方法。

来源​