LLMNotes

第 19 章：工作流编排

zjc 于 2026-01-19 发布

这是《LLM 应用开发 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 企业应用中，LLM 常常只是长流程中的一个节点。工作流编排把模型调用、规则、API、人工审批和异步任务组织成可观测、可恢复的执行图。

19.1 为什么需要编排

单次调用难以覆盖：

  1. 多步骤任务；
  2. 人工审批；
  3. 定时任务；
  4. 事件触发；
  5. 失败重试；
  6. 并行分支；
  7. 长时间等待；
  8. 多系统一致性。
Webhook
  -> validate
     -> classify
        -> RAG answer
           -> guardrail
              |-- auto reply
              +-- human review

19.2 编排方式

方式 适用 示例
代码编排 逻辑稳定 FastAPI + service
状态机 明确状态流转 工单处理
工作流引擎 长事务、审批 Temporal、Airflow
图编排 数据管道 Dagster
规则引擎 复杂决策 Drools 类方案

不要为了“Agent 感”把稳定流程交给自由循环。固定流程用工作流，不确定部分再用模型。

19.3 状态机示例

状态 事件 动作 下一状态
CREATED start 校验输入 CLASSIFYING
CLASSIFYING done 保存分类 RETRIEVING
RETRIEVING done 构造上下文 GENERATING
GENERATING done 安全检查 REVIEWING
REVIEWING approve 发送回复 DONE
REVIEWING reject 记录原因 FAILED

状态要求：

  1. 状态数量有限；
  2. 事件幂等；
  3. 每次状态写入审计；
  4. 支持超时补偿；
  5. 可人工介入；
  6. 可回放。

19.4 DSL 设计

name: ticket-answer
input_schema: ticket-input.v1
steps:
  - id: classify
    type: llm
    prompt: ticket-classifier.v3
    timeout_ms: 5000
  - id: retrieve
    type: retrieval
    profile: hybrid-policy.v2
    depends_on: [classify]
  - id: answer
    type: llm
    prompt: ticket-answer.v5
    depends_on: [retrieve]
  - id: review
    type: human
    when: answer.risk == "high"

DSL 的价值是把流程版本化，但不要过度抽象到难以调试。

19.5 异步任务

Client
  -> POST /tasks
     -> task_id
        -> worker executes
           -> callback / polling
              -> result

实现要点：

  1. 任务持久化；
  2. 幂等任务 ID；
  3. 队列削峰；
  4. 优先级隔离；
  5. 超时取消；
  6. 死信重试；
  7. 进度可查询；
  8. 结果保留周期明确。

19.6 人工介入

模型草稿
  -> 风险评分
     |-- low: 自动发送
     |-- medium: 人工抽检
     +-- high: 强制审批

审批界面应显示用户问题、引用资料、模型草稿、工具调用、风险原因和最终动作。审批人只能看到权限内数据，审批记录要可追溯。

19.7 失败处理

失败 策略
模型超时 备用模型或模板
检索失败 关键词降级
工具失败 幂等重试
安全拦截 拒答并记录
数据不一致 终止并告警
队列堆积 限流和扩容
审批超时 升级或关闭

每个节点都应有明确 on_error 行为，而不是让异常穿透整个流程。

19.8 幂等与事务

外部系统调用示例：

update_order
  -> request_id
     -> target system dedupe
        -> apply once

建议：

  1. 使用稳定业务 ID；
  2. 前置状态检查；
  3. 乐观锁版本号；
  4. 补偿动作；
  5. 本地消息表或事务日志；
  6. 不假设“没响应就是失败”。

19.9 版本与灰度

发布单元包括：

workflow version
prompt version
model version
tool version
policy version
dataset version

灰度策略可以按租户、用户比例、任务类型和风险等级执行，必要时新旧流程双跑，指标达标后全量。

19.10 观测

每个流程记录：

{
  "workflow": "ticket-answer",
  "version": "v7",
  "status": "completed",
  "steps": [
    {"id": "classify", "latency_ms": 320, "status": "success"},
    {"id": "retrieve", "latency_ms": 180, "status": "success"},
    {"id": "answer", "latency_ms": 2400, "status": "success"}
  ],
  "total_latency_ms": 2900
}

关键指标包括完成率、节点失败率、自动解决率、人工率、p95 耗时和单次成本。

本章小结

工作流编排把 LLM 变成可靠业务流程中的一个组件。要用状态机或工作流引擎管理步骤、超时、重试、人工审批和版本灰度，保证幂等和可回放。流程越关键，越需要显式状态和治理。

思考题

  1. 哪些任务适合工作流而不是自由 Agent？
  2. 状态机的每个节点应满足什么工程要求？
  3. 人工介入的阈值如何设计？
  4. 外部系统调用为什么要幂等？
  5. 工作流灰度需要绑定哪些版本？