Workflow 系列（01）：基础理论——三种执行模型与 Anthropic 5 种模式

工作流不是流程图

传统工作流是确定性的：每个节点是一段代码，分支条件是布尔表达式，失败是预定义的异常类型。相同输入给相同输出，跑一百次和跑一次结果一样。

Agent Workflow 打破了这个假设：

python 复制代码

传统 Workflow（Airflow / n8n）：
  节点        = Python 函数 / API 调用（确定性）
  分支条件    = x > 0（布尔表达式）
  失败处理    = try/except（预定义异常类型）

Agent Workflow：
  节点        = LLM + 工具（输出不确定）
  分支条件    = 置信度 ≥ 95%（语义判断）
  失败处理    = 重试 + 人工升级 + 语义降级

Agent Workflow 是三种本质不同的执行模型之一，而不是流程图的升级。

三种执行模型

DAG（有向无环图）

控制流在执行前完全确定，节点之间只能向前，不能回头。

复制代码

代表：Airflow、n8n、GitHub Actions
用途：数据管道、ETL、定时任务

特点：
  → 结构可视化，执行顺序透明
  → 不支持循环（Agent 的重试逻辑需要变通处理）
  → 适合确定性数据处理，不适合需要动态分支的 AI 任务

状态机

系统有有限个"状态"，事件触发状态转移。当前状态 + 事件 → 下一个状态。

javascript 复制代码

代表：LangGraph、自研 Workflow（基于 JSON 状态文件）
用途：有分支、有重试、有人工确认门的业务流程

特点：
  → 任意时刻系统状态可序列化（支持中断续接）
  → 支持循环（重试就是状态回退）
  → workflow_state.json 就是状态文件，确认门就是等待事件

以 Bug 修复工作流为例，状态机的结构是：

bash 复制代码

状态：analyzing / fixing / reviewing / waiting_human / done / failed
事件：analyze_done / fix_passed / human_approved / timeout
转移：analyzing + analyze_done → fixing
      fixing + fix_passed → reviewing
      reviewing + human_approved → done
      reviewing + timeout → waiting_human（升级）

事件驱动

节点之间通过消息解耦，每个节点订阅消息、处理后发布新消息，天然支持异步和长时间运行。

vbnet 复制代码

代表：Temporal、AWS Step Functions、Apache Kafka Streams
用途：长时间运行（> 1 小时）的业务流程、企业级事务

特点：
  → 节点之间松耦合，可以独立部署和扩展
  → 内置持久化和 Durable Execution 保证
  → 复杂度高，不适合快速迭代

选型判断

复制代码

任务是数据管道，节点确定性    → DAG
任务有分支/重试/人工确认门    → 状态机
任务运行时间超长，需要强一致  → 事件驱动

大多数 AI Agent Workflow 用状态机：支持循环重试、状态可序列化、中断可续接。

Anthropic 5 种基本模式

任何 Agent Workflow 都可以用这 5 种模式来描述。掌握这套语言，就能和任何人说清楚你的系统架构。

模式 1：Prompt Chaining（顺序链）

css 复制代码

A → B → C
上一步的输出是下一步的输入

适用： 任务可以分解成有序步骤，每步的质量对后续步骤有直接影响。

复制代码

示例：Bug 修复工作流的主链路
  Phase 1（获取信息）→ Phase 2（日志分析）→ Phase 3（根因分析）
  → Phase 4（代码修复）→ Phase 5（提交）→ Phase 7（通知）

关键约束： 任何一步失败，整条链中断。需要为每步定义 on_failure 行为。

模式 2：Routing（条件路由）

css 复制代码

输入 → Classifier → [类型A] → Agent A
                  → [类型B] → Agent B
                  → [默认]  → Agent C

适用： 不同类型的输入需要走不同的处理路径。

markdown 复制代码

## 路由设计示例（Workflow Markdown 格式）

Phase 3 完成后，根据根因分析的置信度路由：

- confidence ≥ 95%  → 直接进入 Phase 4（代码修复）
- 60% ≤ confidence < 95% → 触发 Gate A（人工确认根因）
- confidence < 60%  → 重新执行 Phase 3（换角度分析，max 3 次）
- 3 次后仍低于 60%  → 升级为人工介入

关键设计： Router 输出必须是枚举类型 ，不能是自由文本。confidence < 60% 是可计算的条件，"分析不够深入"不是。

模式 3：Parallelization（并发执行）

bash 复制代码

        → B1 →
A → split → B2 → merge → C
        → B3 →

适用： 子任务之间相互独立，可以并发执行；或需要多个角度的结果做比较选优。

python 复制代码

# Fan-out：并发跑 3 个修复候选
from concurrent.futures import ThreadPoolExecutor, as_completed

candidates = ["candidate_a", "candidate_b", "candidate_c"]

with ThreadPoolExecutor(max_workers=3) as executor:
    futures = {
        executor.submit(run_fix_candidate, c, bug_info): c
        for c in candidates
    }
    results = {}
    for future in as_completed(futures):
        candidate = futures[future]
        results[candidate] = future.result()

# Fan-in：选质量最高的候选
best = max(
    (r for r in results.values() if r["passed"]),
    key=lambda r: r["test_coverage"],
    default=None,
)

注意： Parallelization 的加速比受限于 Amdahl 定律。3 个并发 + 1 个串行 merge，实际加速比往往只有 1.5x 左右（参见 Skill 系列第 05 篇的实测数据）。

模式 4：Orchestrator-Subagents（编排与子 Agent）

css 复制代码

Orchestrator（主 Agent）
  ├── spawn Subagent A（隔离会话）
  ├── spawn Subagent B（隔离会话）
  └── collect results → make decision

适用： 任务可以拆解成独立子任务，每个子任务需要专注的上下文，不应共享主 Agent 的全部历史。

子 Agent 的三条设计原则：

csharp 复制代码

原则 1：输入完备性
  子 Agent 的 task prompt 包含它需要的一切
  不能依赖"主 Agent 的隐含上下文"

原则 2：输出契约严格性
  输出必须符合声明的 JSON Schema
  {"passed": bool, "result": {...}, "error": str | null}

原则 3：失败时输出结构化错误
  即使执行失败，也要写 {"passed": false, "error": "具体原因"}
  不能因为失败就不写输出文件（主 Agent 会认为超时）

模式 5：Evaluator-Optimizer（评估与优化循环）

ini 复制代码

Generator → Evaluator → [score ≥ threshold] → 输出
                ↓
         [score < threshold] → feedback → Generator（重试）
                                          max_retries = 3

适用： 输出质量重要，第一次不一定达标，可以通过迭代改进。

yaml 复制代码

# 工作流中的评估循环定义
phase_4_fix:
  generator: write-android-code
  evaluator: run-unit-tests
  quality_threshold:
    min_test_coverage: 80%
    all_tests_passed: true
  on_fail:
    max_retries: 3
    feedback_to_generator: true  # 把失败原因传回给 Generator
  on_max_retries_exceeded:
    action: human_escalation    # 3 次后升级人工，不是无限循环

反模式： 没有 max_retries 的评估循环会死循环。Evaluator 的 feedback 必须指向具体问题，"再好一点"是无效 feedback。

5 种模式的组合

真实的生产工作流组合多种模式。以 Bug 修复工作流为例：

arduino 复制代码

整体结构：Prompt Chaining（主链路，Phase 1→7）

Phase 3 内部：Evaluator-Optimizer（根因分析，最多 3 次重试）

Phase 3 → Phase 4 之间：Routing（按置信度路由）

Phase 4 内部：Parallelization（3 个候选并发修复）+ Evaluator-Optimizer（每个候选运行测试）

Phase 5/7 各关键写操作：Human-in-the-loop（属于模式 2 Routing 的特殊分支）

整体 Orchestrator：主 Agent 负责状态机控制，每个 Phase 通过 spawn 调用子 Agent

识别每个部分对应哪种模式，是设计审查的起点。

关于工作流的表达形式

工作流的"代码"可以有多种形式，没有唯一正确答案：

形式	例子	适合场景
Markdown + YAML	`workflow.md` + `config.yaml`	频繁迭代，非技术人员可读
Python 代码（LangGraph）	`StateGraph` + Node 函数	复杂状态机，需要代码级测试
可视化配置（n8n）	画布 + JSON	以 API 集成为主，AI 只是其中一步
自然语言描述	`AGENTS.md` + Task prompt	早期探索，快速验证

形式选择影响：可维护性、测试难度、执行引擎的选择。下一篇（W2 设计范式）会具体讲如何设计这些文件的结构。

总结

Agent Workflow 是状态机：节点输出不确定，分支是语义判断，失败需要语义降级，传统 DAG 的三个假设全部不成立
5 种模式是通用语言：Prompt Chaining / Routing / Parallelization / Orchestrator-Subagents / Evaluator-Optimizer，任何工作流都可以用这 5 种模式来描述
真实工作流是模式的组合：识别自己系统里每个部分对应哪种模式，是设计能力的基础

参考资料

欢迎访问 PrimeSkills ------ 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。

更多实用知识和有趣产品，欢迎访问我的个人主页