Durable Execution / Agent Workflow State Machines 解读

Source Anchors

核心导读

企业 Agent 不是一次模型调用，而是带状态、工具、副作用、人工审批、失败恢复和审计证据的长运行工作流。只要 Agent 会跨系统行动，就必须把“模型建议”放进 durable workflow 和显式状态机中治理。

Durable execution 的机制价值在于: 进程崩溃后可恢复，外部工具调用可幂等，人工审批可等待，失败可重试或补偿，审计可 replay。它把 Agent 从“会调用工具的聊天框”变成可控制的企业流程组件。

落到金融零售场景，状态机本身就是风险控制语言。开户、投诉、支付异常、催收、AML 调查和客户补件都不能依赖隐式对话历史推进；每个状态必须说明允许的输入、可执行动作、审批要求、超时规则、补偿路径、记录保留和责任 owner。模型可以参与规划和草拟，但不能绕过 workflow 的幂等、权限、人工门禁和可重放证据。

问题定义

许多 Agent demo 可以写成:

while not done:
  ask model what to do
  call tool
  append observation

生产系统会立刻遇到不同问题:

• 进程崩溃后不知道执行到哪一步。
• 工具调用成功但模型上下文没保存结果。
• 重试导致重复扣款、重复发邮件、重复开 case。
• 人工审批等待几小时后上下文丢失。
• 模型、prompt 或工具版本升级后 replay 结果不一致。
• 高风险动作没有明确状态、责任人和审批证据。
• 审计无法复盘“当时系统为什么这样做”。

Agent workflow 要解决的是长时间、跨系统、有副作用、有人工介入的行动可靠性:

long-running objective
  -> explicit state
  -> persisted event history
  -> deterministic transitions where possible
  -> controlled side effects
  -> retries and compensation
  -> human approval
  -> audit and replay

核心原理

Workflow 与 Activity 的分离是 durable execution 的基础:

状态机是产品契约，不是底层实现细节:

Draft
  -> EvidenceGathering
  -> AIProposedAction
  -> HumanReview
  -> Approved
  -> ToolExecution
  -> Completed
  -> Failed / Compensated / Escalated / Cancelled

每个状态必须定义:

• 谁拥有责任。
• 允许哪些工具。
• 需要哪些输入和证据。
• 哪些条件允许转移。
• 哪些失败可自动重试。
• 哪些失败必须人工处理。
• 哪些动作可补偿。
• 哪些动作不可逆，必须前置审批。

Determinism 是 replay 的关键。LLM 调用天然不确定，因此不应在 replay 时重新调用模型生成新计划。正确做法是把模型输出作为 activity result 写入事件历史，并记录模型版本、prompt 版本、retrieved context、tool result 和 policy decision。

Idempotency 防止重复副作用:

idempotency_key = workflow_id + step_id + business_action_id

涉及付款、费用调整、邮件发送、case 创建、冻结/解冻、补件请求等写操作时，幂等键是生产底线。

系统/架构模型

Durable Agent architecture:

User / Event
  -> workflow engine
       -> state store
       -> event history
       -> timers and signals
       -> retry policies
  -> agent planner activity
  -> policy engine
  -> tool gateway
       -> idempotency
       -> side-effect classification
       -> audit
  -> human task queue
  -> evidence store
  -> monitoring and replay console

组件责任:

Agent 的规划能力应嵌入状态机，而不是绕过状态机:

current workflow state
  -> allowed actions
  -> agent proposes next step
  -> policy checks action
  -> workflow records decision
  -> tool or human task executes
  -> new event transitions state

关键机制与取舍

Saga 的思想适合长事务:

step 1 succeeds
step 2 succeeds
step 3 fails
  -> compensate step 2
  -> compensate step 1

但在金融零售中有很多不可完全补偿的动作: 客户已经看到的信息、监管报告、账户冻结、拒绝通知、投诉结论。对于不可逆动作，策略应从“事后补偿”前移到“事前审批”。

证据与控制

上线前应验证:

事件历史应记录:

workflow_id
state
trigger_event
actor / agent session
model and prompt version
retrieved evidence
policy decision
tool request and result
idempotency key
human approval or rejection
customer-facing output

没有事件历史，Agent 记忆就会被误用为事实来源。

AI产品/金融零售场景

支付争议 Agent:

Intake
  -> EligibilityCheck
  -> EvidenceRequest
  -> NetworkRuleReview
  -> ProvisionalCreditProposal
  -> HumanApproval
  -> CustomerNotice
  -> CaseClosed

AI 可以读取交易、规则和证据，草拟建议；临时贷记、费用调整和客户通知必须经过规则服务、审批状态和模板控制。

AML investigation copilot:

AlertOpened
  -> EntityResolution
  -> EvidenceCollection
  -> NarrativeDraft
  -> AnalystReview
  -> QAReview
  -> FilingDecision

AI 可以聚合证据和草拟 narrative，但不能做最终可疑活动结论。SAR/STR 决策由授权人员推进，证据路径和模型版本进入 case record。

KYC onboarding:

ApplicationSubmitted
  -> DocumentIntake
  -> Extraction
  -> PolicyCheck
  -> ExceptionReview
  -> Approval / Rejection / RequestMoreInfo

OCR/LLM 可做抽取、缺失检查和解释草稿；最终拒绝、批准和补件要求需要规则、人工例外处理和申诉路径。

客户投诉:

• Agent 可总结历史、提取争议点、建议下一步。
• 补偿、正式结论和监管响应需要工作流状态、审批和证据包。
• 错误通知或延迟处理需要补偿路径和投诉升级记录。

反模式

• 用 while-loop 和内存数组管理长流程，进程重启后状态丢失。
• replay 时重新调用模型，导致事故复盘得到不同计划。
• 工具重试没有幂等键，造成重复副作用。
• 模型可以在任意状态调用任意工具，没有状态机约束。
• 把人工审批作为聊天确认，而不是持久化 workflow state。
• 事后补偿不可逆客户影响，例如错误拒绝、错误冻结或错误通知。
• 只记录最终输出，不记录模型版本、prompt、证据、工具结果和 policy decision。
• 失败、取消、超时、人工拒绝和部分完成状态没有明确定义。

最终心智模型

Durable execution 是 Agent 行动系统的可靠性和治理底座。模型负责提出建议，状态机定义允许的行动空间，policy engine 判断边界，workflow engine 保证恢复和等待，tool gateway 控制副作用，事件历史保存证据。

正确的心智模型是: Agent 不应“自由行动直到完成”，而应“在持久化状态机中提出下一步，并由策略、幂等、副作用控制和人工边界共同决定是否执行”。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。