有检查点，不等于可以继续执行
一次 Session Append 返回错误。Backend 可能拒绝了它，也可能已经写入 Item、只是 Ack 丢失。Retry 假设未提交，可能造成重复；Skip 假设已提交，可能造成丢失。两种选择都把缺少证据变成了猜测。
OpenAI Agents Python 在 2026-08-25 合并的一项变更，为这种不确定性建立了持久身份。它把 Pending Session Write 写入 RunState，Resume 时重读权威 Session History，并在允许下一次 Model Call 前分类观察结果：Already Committed 不重放，Unchanged 可以补写，其他状态属于 Ambiguous 并 Fail Closed。
架构结论比“谨慎重试”更强，但比 Exactly-once Execution 更窄：Checkpoint 可以恢复 Process State，却不能自动恢复 Continuation Authority。 未来 Reasoning 所依赖的 Durable Boundary 未解决前，Runtime 不应获得继续执行的权力。
Resumability 保存状态，不保存确定性
Checkpoint 回答进程能否重建，却不会自动回答最后一个 Durable Effect 是否完成。Transport Exception 是 Epistemic Event：调用方知道 Ack 失败，但不知道 Storage 最终包含什么。
如果这种不确定性在进程停止时丢失，恢复后的 Runtime 就没有原则化选择，只能重复 Append 或从不完整 History 继续。所选变更保存了未决 Intent 本身：Session Identity、Item Batch、已知的 Pre-write History Fingerprint 与 Persisted-item Count。
于是，不确定性成为 State Machine 的一部分。只有 Running、Paused 与 Resumed 不够，Runtime 还需要“Unresolved Durable Effect”状态，用它暂停更高层工作。
Reconciliation 是新 Reasoning 之前的门禁
Streaming 与 Non-streaming Resume Path 都在下一次 Model Call 前处理 Pending Write。这个顺序不可交换：新 Reasoning 不应消费最后边界仍有争议的 History。
算法重读权威 Session History，并比较稳定 Item Fingerprint。如果观察到的 Tail 等于记录的 Pre-write History 加 Pending Item，Append 已提交，不需要重放；如果 History 仍等于写入前状态，Append 仍缺失，可以执行；两者都不匹配时，状态就是 Ambiguous。
Ambiguity 时 Fail Closed 可能拒绝合法 Concurrent Extension，这确实牺牲 Availability。但在没有 Revision Token、CAS 或受治理 Merge Rule 时，自动接受会虚构 Runtime 并不拥有的知识。显式 Error 保留冲突，等待 Repair，而不是静默改写 History。
这套三路分类正是 Reconciliation 与通用 Retry 的区别：它先要求权威 Storage 说明哪个已表达世界真实存在，再允许 Execution 推进。
Recovery Evidence 与 Execution Progress 是不同记录
健壮控制面至少应分别保存三类事实：预期 Durable Effect、用于分类的 Storage Evidence，以及更高层 Execution Position。只保存第三类的 Checkpoint 会诱导不安全继续。
Recovery Record 还应严格绑定 Identity。如果恢复后的 Runtime 可能指向不同 Backend Implementation 或 Namespace，仅有 Logical Session ID 可能不够。Backend Identity、Serialization Version 与 Fingerprint Scheme 决定“相等”到底意味着什么。
Operator 需要一条 Decision Trail：观察到 Pending Intent、重读权威 History、得到分类、授予或拒绝 Continuation Authority。它能解释 Model Call 为何恢复或停止，而不需要暴露完整 Conversation Payload。
如果多个恢复 Worker 可能并发，还需要另一层 Ownership。所选实现只有 In-process Guard，没有分布式 CAS；独立副本能够同时处理同一 Session 时，系统需要 Lease、Revision Token 或 CAS-backed Append。
Session Reconciliation 不会让 External Effect 具有事务性
精确 Session Fingerprint 只证明被比较 Serialization Representation 相等，不能证明 Session Item 所代表的 Tool Call、Payment、Message 或 Deployment 恰好提交一次。External-effect Identity 与 Receipt 需要自己的 Reconciliation Boundary。
该实现也没有建立分布式 Exactly-once Session Persistence。它证明的是一个有界规则：对一个 Pending Append 与一个权威 History，保存 Intent、重读、分类，并在新 Model Execution 前对歧义停止。
剩余设计问题由此自然出现：Session Backend 是否应暴露 Revision 或 CAS？如何区分合法 Concurrent Extension 与 Corruption？Pending-write State 应绑定哪一种 Backend Identity？Recovered Item 在授权继续之前需要什么 External-effect Evidence？
一手证据： OpenAI Agents Python 已合并提交 40f0d9fc。公开实现支持有界 Session-write Reconciliation，不支持分布式 Exactly-once Execution 或 Transactional External Effect。