S38：Pause / Resume：Checkpoint、Session 与 HITL 的连接

内容类型：预习教材（不代表已完成）
日期：2026-12-30
阶段：P2 · AI Systems Engineering 90
总路线：Day 128 / 360
周次：W6 · Agent Runtime & Durable Workflow
节奏：周三引导练习
状态：教材已备；学习未完成
标签：pause-resume、session、hitl、approval、checkpoint

一句话定义

Pause / resume 不是暂停一个进程，而是把可恢复状态、待决策事项和恢复条件持久化，使人工或外部事件稍后能够安全推动同一业务流程。

学习目标

1. 区分会话上下文、workflow checkpoint 与人工任务记录。
2. 能说明 pause 时必须保存什么，resume 时必须重新验证什么。
3. 理解人工审批是有期限、有权限、有证据的状态迁移，不是一个布尔按钮。
4. 能观察现有教学组件而不夸大其持久性能力。

核心知识

• Session 保存交互上下文和偏好，生命周期可能短；workflow 保存业务进度；human task 保存受让人、证据、决策权、截止时间与决定。三者 ID 可以关联，但不应共用同一状态对象。
• Pause 应记录状态版本、等待原因、可见证据引用、允许的下一事件、超时点和恢复 token。敏感正文尽量引用而非复制。
• Resume 不是从下一行继续：要检查审批者身份、任务是否过期、资源版本是否变化、外部效果是否已发生以及策略是否仍允许。
• 人工决定至少包括 approve / reject / request_more_info / abstain / escalate；二元批准无法表达证据不足和权限不足。
• 长等待期间模型、prompt、policy 或数据可能更新。恢复时应明确沿用原 bundle 以保证一致，还是迁移到新版本并重新生成证据。

机制与推导

一个暂停记录可抽象为：

PauseRecord {
 workflowId, stateVersion, waitingFor,
 evidenceRefs[], allowedEvents[],
 assigneeRole, expiresAt, bundleVersion
}

恢复条件不是 paused == true 的反面，而是谓词：

[ canResume = validActor \land validEvent \land notExpired \land stateVersionMatch \land policyStillValid ]

若审批事件重复到达，transition 应以 workflowId + stateVersion + decisionId 去重。若两个审批者并发决定，只能有一个从当前 stateVersion 成功迁移，另一个得到“状态已变化”的明确响应，而不是覆盖历史。

最小练习或观察步骤

1. 只读查看 checkpointMachine.ts、sessionRuntime.ts 与 hitl.ts，分别记录它们表达的状态，不假设具备外部持久化。
2. 为一个等待主管复核的合成案例写 pause record。
3. 依次推演 approve、request_more_info、timeout 三条事件路径。
4. 构造并发审批：两人基于同一 stateVersion 提交不同决定，写出冲突处理。
5. 构造等待期间 policy 更新的场景，说明恢复前需要哪项重新判断。
6. 记录源码实际支持与教材推演的边界；未运行时不写“恢复成功”。

常见误区与边界

• 只保存聊天记录，恢复后不知道已执行到哪个业务步骤。
• 把审批链接当作永久权限，不检查身份、期限和当前状态版本。
• 等待期间自动升级模型，却沿用旧证据和旧解释。
• timeout 后直接标记业务失败，忽略升级、重新分配或人工对账。
• 为恢复复制全部敏感上下文，扩大数据保留和泄露面。
• 内存 checkpoint 只能展示状态迁移，不能证明跨进程、跨区域耐久性。

系统 / 金融 / Web3 场景连接

高风险 AML 决定可能等待主管数小时，期间案件新增交易或策略更新，resume 必须提示证据是否过期。Web3 多签交易则等待多个 signer；提案内容、chain ID、nonce 与截止时间必须固定，任何签名不能被挪到已变化的交易上。

自检问题

1. session、workflow 与 human task 为什么要分开？
2. resume 前为何需要重新验证策略和外部状态？
3. stateVersion 怎样处理并发审批？
4. bundle 更新时有哪些恢复选择？

专业课程对齐

• 阅读 Temporal 官方文档 中 Signals、Updates、Timers 与 durable execution 内容，具体映射外部事件怎样唤醒等待中的 workflow。
• 阅读 MIT 6.5840 Distributed Systems 的一致性、并发与容错主题，思考两个审批事件为何需要版本比较而不能 last-write-wins。
• 阅读 Google SRE 资源 中 incident response 与 on-call 相关章节目录，把超时、升级和人工接管理解为运营路径，而非 UI 附加功能。

深入学习提示

从“暂停 24 小时后什么会变”开始：身份、数据、策略、模型、外部状态、负责人都可能改变。逐项决定固定、重新验证或迁移。深入时可画 session/workflow/human task 三条平行生命周期及其关联 ID，避免把所有上下文塞入一个大对象。

学后填写区

• 三类状态的区别：
• Pause record 的关键字段：
• 一条超时或并发路径：
• 源码支持 / 教材推演边界：
• 尚未理解的问题：