本文迁移自 mindcarver/91ai · 原始位置 docs/agent/ai-app-tutorials/agent-workflow/workflow-basics.md · 由 @阿新聊ai 整理。

Workflow 基础

TL;DR: Workflow 把复杂任务拆成可执行、可检查、可复用的步骤。2025 年 Anthropic 定义了五种 Workflow 模式（Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer），给"什么时候用 Workflow、什么时候上 Agent"提供了清晰的决策框架。Workflow 的核心价值是把不稳定的模型能力放进稳定的流程框架。

Workflow 的定义

Workflow 是把一件复杂任务拆成一组可执行、可检查、可复用的步骤，并规定步骤之间如何流转。

它不是简单的"步骤列表"。一个真正的 Workflow 至少包含四样东西：

• 每个步骤做什么
• 每个步骤需要什么输入
• 每个步骤产出什么输出
• 上一步和下一步如何连接

可以把 Workflow 想成一条生产线：原材料进入第一道工序 → 半成品 → 第二道工序 → 质检 → 包装。每道工序不需要理解整个公司战略，只需要把自己的输入加工成合格输出。

在 AI 应用中，Workflow 把"让 AI 完成一件复杂事"拆成多个节点：某个节点调用大模型，某个节点检索知识库，某个节点做结构化校验，某个节点生成报告，某个节点等待人工审核。

核心价值：把不稳定的模型能力放进稳定的流程框架。 大模型输出可能有波动，但流程本身应该可预测——每次从哪里开始、经过哪些节点、失败后怎么处理、最终交付什么，都应该清楚。

这也是企业特别需要 Workflow 的原因。企业最怕的不是 AI 偶尔不够聪明，而是系统行为不可解释、不可复现、不可追责。Workflow 提供的是可控性。

Workflow 解决什么问题

复杂任务拆解。 "生成企业 AI 诊断报告"包含资料收集、行业理解、流程拆解、岗位分析、场景识别、方案排序、风险审查。拆成节点后，每个节点都更容易设计和验证。

中间结果可检查。 最终报告错了，能追溯是哪一步错了——行业概览？岗位拆解？方案排序？没有 Workflow，错误混在一大段生成结果里，很难定位。

系统行为可复现。 同样的输入经过同样的流程，至少经过同样的节点。即使模型输出略有差异，执行轨迹也能被记录和比较。

多人协作和交付管理。 产品、研发、交付、业务专家、客户都需要知道流程走到哪一步。Workflow 把 AI 执行过程变成可管理的项目过程。

什么时候用 Workflow，什么时候用 Agent

一句话区分：

流程能提前画出来，用 Workflow；路径要边走边判断，用 Agent；企业系统里通常两者混合。

适合 Workflow 的三个特征：

• 流程相对固定。 不管输入对象是谁，整体步骤差不多。行业研究、合同审查、简历筛选、工单分流、报告生成。
• 步骤之间有明确依赖。 后一步需要前一步的结果。先有企业背景才能分析岗位；先有岗位任务才能识别 AI 场景。
• 输出格式要求高。 每一步都要输出 JSON、表格、清单或可审核的 Markdown。

不适合 Workflow：任务路径高度不确定，需要系统运行时自己判断下一步。这时可以在 Workflow 的某些节点里嵌入 Agent。

Anthropic 的五种 Workflow 模式

1. Prompt Chaining（串联）

前一步的输出作为后一步的输入。

用户输入 → LLM 调用 A → 输出 A → LLM 调用 B → 输出 B → 最终结果

适用场景：文档生成后翻译、代码生成后审查、内容创作后 SEO 优化。

优势：每步可独立调试和评估。劣势：串行延迟累加。

2. Routing（路由）

分类器判断输入类型，分发到不同的处理分支。

用户输入 → 分类器 → 分支 A / 分支 B / 分支 C

适用场景：客服按意图路由、邮件分类处理、工单按类型分流。

关键：分类器的准确率决定了整个系统的上限。分类错误会导致后续处理全错。

3. Parallelization（并行）

多个 LLM 调用同时执行，再聚合结果。两种子模式：

• Sectioning：把大任务拆成独立片段并行处理
• Voting：多路独立评估同一内容，取共识

         ┌→ LLM A → 结果 A ─┐
用户输入 →├→ LLM B → 结果 B ─├→ 聚合 → 最终结果
         └→ LLM C → 结果 C ─┘

适用场景：多角度内容审核、多语言翻译、代码多维度分析。

4. Orchestrator-Workers（编排-工人）

中央 LLM 动态分解任务并分配给 Worker，Worker 数量不固定。

用户输入 → Orchestrator LLM → 分析任务
                                ├→ Worker 1（创建文件 A）
                                ├→ Worker 2（创建文件 B）
                                └→ Worker 3（创建文件 C）
                                → 汇总结果

适用场景：文件数量不确定的编码任务、多步骤研究、复杂分析。

与 Routing 的区别：Routing 是预定义分支，Orchestrator-Workers 的分支是运行时动态决定的。

5. Evaluator-Optimizer（评估-优化）

一个 LLM 生成，另一个 LLM 评估并提供反馈，迭代直到达标。

用户输入 → 生成器 → 初稿 → 评估器 → 反馈
              ↑                        │
              └──── 修改后重试 ←────────┘

适用场景：写作精炼、代码重构、搜索查询优化、方案迭代。

关键：评估器要有明确的评估标准。没有标准的评估器只会产生无意义的来回。

节点设计

节点是 Workflow 的最小工作单元。设计节点时先问五个问题：

1. 这个节点的职责是什么？
2. 输入字段有哪些？
3. 输出字段有哪些？
4. 如何判断输出合格？
5. 失败后怎么处理？

以"行业概览"节点为例：

• 职责：生成结构化行业概览，不是随便写一段行业介绍
• 输入：行业名称、目标地区、时间范围、报告用途
• 输出：产业链结构、主要玩家、市场规模、关键技术、发展趋势、数据来源
• 合格标准：字段不能缺，市场规模必须有来源，趋势判断要对应证据
• 失败处理：重试一次，仍失败则降级为"基于已有资料生成初版"并标注证据不足

粒度原则：一个节点应该产出一个有独立价值的中间成果。

"行业概览"是一个好节点——可以单独审核、单独保存、被后续多个节点复用。"搜索资料并总结行业并推荐方案"太粗——混合了收集、分析和决策。

AI 节点与非 AI 节点

不要每个节点都调用大模型。一个健康的 Workflow 同时包含两类节点：

• AI 节点：理解、生成、归纳、判断
• 非 AI 节点：格式校验、字段提取、去重、排序、权限检查、数据存储

能用确定性代码解决的问题不要交给模型。JSON 格式校验、分数加权、字段是否为空——这些由程序处理。模型处理语义不确定的问题。

让模型做判断，让代码做约束。

状态传递

Workflow 每个节点都需要状态。状态记录了任务从开始到当前的所有关键中间结果。

两种传递方式：

显式传递。 节点 A 的输出直接作为节点 B 的输入。清楚，但多个节点需要同一份信息时传参变复杂。

共享状态对象。 所有节点读写同一个状态对象：

{
  "industry": "半导体",
  "overview": {},
  "roles": [],
  "processes": [],
  "ai_opportunities": [],
  "risks": []
}

灵活，但容易状态膨胀。

实际工程常用混合方式：核心字段显式传递，共享元信息放在全局状态里。行业名称、任务 ID、用户配置全局共享；行业概览、岗位清单、风险结果这类关键产物要明确命名、版本化、可追踪。

三个注意点：

• 只传必要信息。 后续节点不需要的原始材料不要一直塞在状态里
• 保留证据链。 关键结论能追溯到来源、节点和时间
• 区分草稿和确认结果。 未审核的模型输出不要和已确认结果混在一起

条件分支

真实 Workflow 很少完全线性。常见三类分支：

数据分支。 根据数据内容选择路径。企业规模小走轻量诊断，企业流程复杂走深度诊断。

质量分支。 根据节点输出质量选择路径。行业概览缺少数据来源 → 回到资料检索节点；质量合格 → 进入岗位分析。

风险分支。 根据风险等级选择路径。方案涉及生产控制系统 → 强制专家审核；只是知识助手 → 普通审核。

分支不是越多越好。分支太多让 Workflow 像一张缠在一起的网，很难测试。优先考虑"少数关键判断"，不要为每种边缘情况单独设计路径。

异常处理

Workflow 的可靠性很大程度取决于异常处理。模型超时、输出格式错误、API 限流、权限不足、数据缺失——这些不是意外，是正常会发生的情况。

异常处理分三层：

节点级。 节点内部能恢复的错误就内部处理。模型输出 JSON 格式错误 → 尝试一次修复；搜索 API 超时 → 重试；缺少非关键字段 → 标记为低置信度。

流程级。 节点失败后 Workflow 决定下一步：重试、跳过、降级、回退、转人工。

系统级。 整个任务失败后的处理：记录日志、告警、释放资源、保存失败现场、生成可恢复任务。

重试要有上限。无限重试不是稳定性，是失控。明确最大重试次数、重试间隔、哪些错误可重试、哪些必须人工介入。

人工介入

Workflow 的优势之一是容易插入人工审核节点。适合人工审核的三类节点：

• 基础事实节点：错了会污染后续所有分析
• 关键决策节点：会影响方案方向、预算、优先级
• 外部动作节点：会发邮件、写系统、创建任务、影响客户

人工审核节点要设计清楚：审核什么、通过标准、拒绝后怎么办、超时怎么办、谁负责。不要只给审核者一大段原始文本——给摘要、证据、风险点和明确选项。

完成标准

一个 Workflow 不是"跑完所有节点"就算完成。真正完成需要四个条件：

1. 所有必需节点已执行或有明确降级记录
2. 每个关键输出都通过格式和质量校验
3. 高风险节点已经人工审核或明确豁免
4. 最终交付物能追溯到中间结果和证据来源

这四个条件比"生成一份报告"麻烦，但决定了系统能不能从 Demo 走向真实交付。

设计模板

Workflow 名称：
目标：
输入：
最终输出：

节点 1：
- 职责：
- 输入：
- 输出：
- 校验：
- 失败处理：

节点 2：
- 职责：
- 输入：
- 输出：
- 校验：
- 失败处理：

人工审核点：
异常处理：
完成条件：
审计日志：

这个模板的价值不在形式，在逼你提前回答关键问题。这些问题答不清楚，上线后就会在同样的位置出问题。

延伸阅读

• Anthropic: Building Effective Agents — 五种 Workflow 模式的原始定义
• LangGraph: Workflow Patterns — 状态图实现 Workflow
• OpenAI: Agents SDK — Guardrails 作为 Workflow 安全层