READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 审批快照、持久化等待与一次逻辑恢复
先理解核心原理
先备概念：可信审批身份、状态条件更新、恢复重入与幂等
批准授权的是一个具体、可审阅动作快照，等待期间它的内容、权限和外部条件都会变化。恢复须验证批准仍适用，并把重复回调归并为同一逻辑动作。
等待不需要进程持续活着
把 run、待执行动作快照、恢复点和审批状态持久化后释放 Worker。用户回调只是事件，调度器根据记录继续运行。内存 approved 标志或 sleep 三天不能支撑重启，也无法让其他 Worker 判断是谁批准了什么。
批准对象是动作语义
记录 action_hash、revision、审批者、范围、有效期与 operation_id。哈希应基于规范化后的完整业务参数，而不是只对页面标题计算；收件人、费用、对象范围和正文变化都可能改变动作。身份由认证系统验证，模型转述“用户已同意”不能创建有效批准。
恢复有两次验证
收到回调时验证批准者与待审版本，真正发送前再检查任务未取消、内容未变、当前权限和业务条件仍满足。用条件状态领取一次逻辑恢复，重复回调返回相同 approval_id 状态；执行失败仍依稳定操作键恢复，不能简单删除批准后再造新运行。批准消费与远端动作不是同一个事务，未知结果需对账。
中断位置不是程序计数器
LangGraph 中断恢复会从节点开头重入，interrupt 之前的代码会再执行。副作用放在独立可恢复步骤，或使用明确幂等保护，不能假定暂停在哪行就从哪行继续。验收双击、重复回调、参数更改、审批者离职、批准后取消和写工具成功未记录；判断一项逻辑批准产生的业务效果，而非 HTTP 只返回一次。
回到问题：怎样回答？
等待审批应成为持久化状态，不用进程睡眠保活。批准记录绑定运行、待执行动作摘要、版本、审批者和有效期，服务端以条件更新消费批准。双击或重复回调返回同一结果，不触发两次动作。恢复前重查权限、业务状态和内容版本；动作变化或批准过期时重新审批，恢复点前可能重跑的代码不能包含无保护的副作用。
实现与取舍
等待不占用工作线程
保存 waiting_approval、动作摘要、输入版本和恢复位置，然后释放 Worker。用户回调仅表达审批事件，调度器负责恢复任务。重启后仍能从数据库显示待审批项，不能把内存对象或 WebSocket 连接当唯一状态。长时间等待期间工具版本、权限和业务对象都可能变化。
批准与动作绑定
批准包含 approval_id、run_id、action_hash、revision、actor 和 expires_at。服务端从可信身份取得审批者，用条件写将 pending 转为 approved 或 consumed；相同请求重复到达返回已处理状态。批准不能被拿去执行另一个动作，也不能由模型转述“用户说可以”替代实际记录。
恢复时重新验证
检查任务仍在等待、未取消，动作摘要未变，批准有效且审批者仍具权限。对于暂停节点恢复时会重新进入哪些代码，要按所用框架版本验证，将副作用隔离在可幂等的步骤。领取恢复任务还需并发控制，双 Worker 不能因为都读到 approved 就同时执行。
失败时怎样收尾
若外部动作已成功但消费批准状态未写入，靠操作幂等键或回执对账确定结果，而不是再消费一次。测试双击、重复回调、撤销权限、修改参数、批准后取消和 Worker 宕机。每种情况都应有明确业务终态与可解释审计记录。
工程推演
- 场景
- 面试假设：审批报告发布三天后同意按钮被重复点击。
- 设计决策
- 持久化批准并按动作摘要验证，以条件更新领取一次恢复。
- 验证目标
- 最多产生一次逻辑发布，重复回调返回同一状态。
- 适用边界
- 外部发布是否可保证一次效果仍取决于幂等或回执机制。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层批准后正文修改一个字能沿用吗？
从批准绑定动作进入最小修改是否改变授权范围。
参考解答
默认需要重新批准，因为快照改变。若产品明确允许不改变语义的格式规范化，可在审批前定义规范化规则并展示实际输出；不能在批准后临时判断“一个字没关系”。尤其金额、收件人、否定或链接变化须重新审核，内容版本与动作摘要一起校验。
沿着这个回答继续深入
第 2 层只修改空格也会改变哈希，怎样兼顾可用性？
父问严格绑定快照后，规范化解决非语义差异但引入边界。
参考解答
先定义业务级规范化，例如无意义空白、JSON 键序；审批展示与实际执行都使用同一规范化结果。格式可能影响邮件排版、代码或签名时不能随意规范化。记录原审阅版本，验证语义参数完全相同；没有明确规则就重新批准。
沿着这个回答继续深入
第 3 层正文没变，收件人增加一位，为什么仍需新批准？
文本规范化不能掩盖动作其他参数变化，检验快照是否完整。
参考解答
动作语义包含目标、权限、费用与内容，不能只哈希正文。新增收件人扩大信息披露范围，原批准未必覆盖。重新生成完整 action_hash 并展示差异，确认后才执行；旧批准不会因正文相同自动迁移到新动作。
第 1 层审批者离职后旧批准有效吗？
长时间等待后，身份合法性与批准生命周期发生变化。
参考解答
按业务策略重新验证当前权限。教学中的严格执行策略会拒绝已失权主体的旧批准，并让新的有权审批者确认。若业务定义批准是当时授予且持续有效的凭据，也必须明确期限、撤销和范围；不能仅凭旧 actor_id 默认有效。
第 1 层暂停节点恢复前代码会不会重跑？
批准恢复不仅是状态变更，还涉及框架执行语义。
参考解答
会，LangGraph 的动态 interrupt 恢复会重入节点开头，暂停前代码再次执行；子图还可能让父节点重入。将计算与副作用分离，副作用按稳定操作键可重试；升级后中断次序也需验证，不能把恢复值错误匹配到另一个审批项。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
批准时价格锁定，恢复时失效
改变的条件：对象相同但商业条件变化
延伸问题：原批准酒店 500 元，三天后 650 元可继续吗？
推导与参考解答
动作金额和条款已经超出快照，重新审批或按用户预先明确的上限规则判断。批准状态为 approved 不能覆盖价格变化；重新查询报价并保存版本，再让用户审阅。若已有外部订单先对账，避免报价变化引发重复预订。
保持不变的原理：批准绑定具体条件，任务等待不会冻结外部世界。
审批可代理
改变的条件：原审批者不在线，另一人代点同意
延伸问题：持有审批链接是否足够？
推导与参考解答
链接定位待审项，身份和代理资格需服务端确认。记录实际 actor、代理关系与权限范围，核对同一动作快照；重复回调仍归同一批准。不可将共享链接当成无限 bearer 授权，尤其会产生外部效果时。
保持不变的原理：可访问审批入口不等于具备批准能力，可信身份与动作范围缺一不可。
易错点
- 进程 sleep 等审批
- 只记录 approved=true
- 双击回调各自创建运行
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 设计可跨重启保留的等待状态，并独立验证审批身份。
- 中高级信号
- 能绑定摘要、有效期并处理重复回调。
- 资深信号
- 覆盖恢复重入、并发领取、未知副作用与权限变化。
巩固练习 按需完成 · 建议 15 分钟
给批准接口写条件更新伪代码，模拟两次同时到达的同意请求。
展开验收要求与检查点
- 同一批准不重复消费
- 动作变化会拒绝恢复
- 已取消任务不重新启动
重点检查
- 等待可跨进程持久化
- 批准绑定动作并原子消费
- 恢复前校验变化与并发