S36：Agent、Workflow 与业务事务的状态边界

内容类型：预习教材（不代表已完成）
日期：2026-12-28
阶段：P2 · AI Systems Engineering 90
总路线：Day 126 / 360
周次：W6 · Agent Runtime & Durable Workflow
节奏：周一概念与阅读
状态：教材已备；学习未完成
标签：agent-loop、workflow、state-machine、business-transaction、durability

一句话定义

耐久 Agent runtime 把不确定的模型推理嵌入显式状态机，使长时间任务能够暂停、恢复、审批和对账，而不会把一次模型循环误当成完整业务事务。

学习目标

1. 区分 agent loop、workflow、状态机和跨系统业务事务。
2. 能画出 collect→propose→approve→effect→verify/reconcile 的状态与事件。
3. 理解模型输出是建议或命令输入，外部副作用必须由确定性边界控制。
4. 能指出持久状态、瞬时状态和外部真相分别在哪里。

核心知识

• Agent loop 常是观察、推理、选择动作、获得反馈的循环，循环次数和路径可能动态变化。
• Workflow 显式编排步骤、依赖、等待、超时和恢复策略；动态并不等于不可描述。
• 状态机 用有限状态与合法迁移定义当前事实；事件触发迁移，命令请求副作用，两者不应混用。
• 业务事务 可能跨模型、工具、人工和核心系统，无法依赖单数据库 ACID 一次提交；需要幂等、outbox、saga、补偿与对账。
• Durability 指进程退出后仍能从持久历史恢复，而不是简单在内存保存对话。
• 模型调用通常不是确定性的。重放 workflow history 时应重放已记录结果或把不确定活动放在受控边界，不能重新生成后假装历史未改变。

机制与推导

一个简化状态机：

COLLECTING --evidence_ready--> PROPOSED
PROPOSED --approval_required--> WAITING_APPROVAL
WAITING_APPROVAL --approved--> EFFECT_PENDING
EFFECT_PENDING --effect_ack--> VERIFYING
VERIFYING --consistent--> COMPLETED
VERIFYING --mismatch--> RECONCILING
任意可恢复状态 --timeout/failure--> RETRY_WAIT 或 NEEDS_ATTENTION

每条迁移都要回答：触发事件是什么、前置条件是什么、状态写入何时持久化、要发出什么命令、重复事件如何处理。尤其 EFFECT_PENDING 与 effect_ack 之间存在“不知道外部是否成功”的窗口。此时直接重试可能重复副作用，应先用 idempotency key 查询或对账。

命令与事件分离很关键：SubmitFreezeRequest 是意图，FreezeAccepted 是外部系统确认的事实。模型可以建议命令参数，但只有授权过的 runtime 才能发出，且 workflow 要等待事实事件再推进。

最小练习或观察步骤

1. 选择合成 AML 案例，只画六个主状态，不从代码开始。
2. 为每个状态写“进入条件、允许动作、退出事件、超时处理”。
3. 标出模型推理、人工审批和外部系统调用三类边界。
4. 构造“effect 已成功但 ack 丢失”的场景，写出为何不能直接再次执行。
5. 标出哪些状态必须持久化，哪些 UI loading 状态可以丢失。
6. 不要求部署 Temporal；只需让状态语义可以被另一人解释。

常见误区与边界

• 把聊天历史当成 workflow 状态，无法判断副作用是否发生。
• 用 success/failed 两个状态压扁审批、等待、未知和对账。
• 认为队列“至少一次投递”意味着业务效果也可以至少一次。
• 在 workflow 重放时重新调用模型，得到不同动作却沿用旧审计历史。
• 把补偿理解成数据库 rollback；外部通知、支付或链上交易往往不可真正撤销。
• 本日学习状态语义，不声称本地状态机具备生产持久化与灾难恢复。

系统 / 金融 / Web3 场景连接

AML 调查建议需要先收集证据、生成建议、主管审批，再向案件系统写入动作并核对结果。每一步的决策权不同。Web3 钱包 Agent 可构造交易、等待用户签名、广播、等待链上确认并处理 reorg；“已广播”不等于“最终完成”，且链上副作用不能靠删除本地记录撤销。

自检问题

1. agent loop 与 workflow 最重要的边界是什么？
2. 命令和事件为什么要分开命名？
3. EFFECT_PENDING 状态解决了什么未知窗口？
4. 哪些不确定结果在重放时不应重新计算？

专业课程对齐

• 阅读 Temporal 官方文档 的 Workflows、Activities、Event History 与 durable execution 概览，重点映射确定性 workflow 和不确定外部 activity 的边界。
• 阅读 MIT 6.5840 Distributed Systems 中容错、复制与一致性的课程主题，关注“进程失败不等于业务状态消失”，不要求完成其分布式实验。
• 阅读 Full Stack Deep Learning 2022 中 deployment 与 ML infrastructure 内容，将模型服务置于更长业务流程中，观察模型成功与任务成功的差别。

深入学习提示

阅读顺序是状态图→Temporal history→分布式失败模型。深入时用“进程在任意两行之间崩溃”逐条攻击状态机：恢复后知道什么、不知道什么、能否安全重做。若答案依赖“通常不会发生”，就标记为未解决边界，不必立即实现。

学后填写区

• 实际画出的状态机：
• 三类边界所在位置：
• 一个外部未知状态：
• 可恢复与不可恢复部分：
• 尚未理解的问题：