第11章 可靠接续：未知、重试与跨重启恢复

第10章把动作限制在获准范围，并要求用句柄查询受理、运行和结束事实。但执行边界不会让通信变成可靠事务。命令可能已经写完文件，宿主却没有保存回执；外部服务可能已经受理，客户端却只看见超时；宿主也可能在写前意图之后、真正提交之前停止。它们都留下中断，却需要不同的处理。

第3章对此采用保守出口：保留现场，未知停下，不自动重试，每次启动创建新 run。本章解释怎样取得继续资格，而不把全书改造成自动恢复平台。先核对旧效果，再决定能否重提；先重建事实，再决定谁能调度。没有足够契约时，可靠接续的结果可以是停止和人工确认，不必总是恢复运行。

11.1恢复、重试与三个身份

恢复是在中断之后重建必要事实，并依据当前条件决定后续动作。它不是重新运行一遍历史，也不是把状态改回 running。重试是为同一项操作再发起一次尝试；核对（reconcile）是向程序侧记录或实际对象取得证据，判断旧操作发生了什么。核对可以不产生业务效果，重试则可能再产生效果。

最小恢复形态可以没有自动调度。它读取旧意图、结果和对象版本，返回已知事实、未知范围及允许的下一步。读完账本后自动执行未完成动作，不是最小形态，而是已经增加了续权、去重与旧执行者控制责任。

先把状态分开。未提交指存在可靠依据，证明请求尚未进入执行路径。accepted 指接收者已经受理并承担管理责任；running 指可信执行处报告仍在推进；finished 指约定范围已经结束，但不必成功；partial 指已确认只有部分效果；unknown 指现有证据不足以判断其中某些事实。

这些词不是一条必须单向经过的进度条。客户端观察未知时，接收者可能已经结束；执行已结束时，产物仍可能只有部分；收到受理回执时，效果也可能很快发生。最好分别保存提交事实、执行状态、效果状态和验收状态，不让一个状态字段同时承担四种判断。

写前意图说明准备执行，不说明已经提交。反过来，没有结果记录也不说明没有执行。记录意图后、调用接收者前会有一个间隙；接收者完成后、宿主记录结果前也有一个间隙。仅凭“最后一条是 intent”，不能知道中断位于哪一个间隙。

未提交的证明必须来自控制路径，而不是记录缺失。例如，宿主在可靠记录的提交门之前拒绝请求，且没有其他提交入口，可以认定未提交。一旦提交可能发生，网络错误、等待超时和响应持久化失败都不能重新赋予这个证明。此时应保留动作身份，走查询和核对。

效果、结果和费用也各有未知。外部模型请求没有可靠响应，本地便不能知道生成内容或全部用量；本地工具没有被调度，仍不代表模型服务没有计算。把这些缺口分别保存，后续才不会因为找到文件就顺便把费用、接口接续和整个任务都标成成功。

恢复首先需要定位对象。动作身份（action_id）标识一项业务操作；尝试身份（attempt_id）标识一次提交或通信尝试；外部身份（external_id）由实际接收者提供，定位它管理的工作或资源。三者可以关联，不能因为方便就合并成一个编号。

同一动作重试时，动作身份保持不变，尝试身份应改变。外部身份可能在受理以后才取得，也可能由于响应丢失而暂时未知。若每次重试都创建新动作身份，接收者会把它们当作不同业务操作；若只记录动作身份而不记录尝试，费用、错误和返回时序又会混在一起。

操作幂等是指在接收者约定的范围和期限内，多次提交同一操作身份及同一内容，不增加约定外的重复业务效果。它不是“请求看起来一样”，也不是任意动作执行两次都天然安全。最小形态是接收者持久保存操作键、内容摘要和处理状态，并在重复提交时返回原事实或继续管理同一操作。

完整幂等契约要说明 scope、identity 和 retention。scope 是去重适用的接收者、账户、工作区、接口或资源范围；identity 是双方用来认定同一操作的键；retention 是接收者保留记录和兑现去重的时间范围。键相同但 scope 变了，不应被误认为同一操作；超过保留期限，也不能继续借用旧去重承诺。

同一操作键携带不同 payload 必须拒绝。payload 是操作的语义内容，包括影响效果的参数和版本条件，不只是展示文本。摘要应按约定的编码与字段语义计算。不能在重试时删除一个空字段或更换默认值，仍声称内容完全相同；第5章的调用绑定在这里继续有效。

接收者保存记录是关键。宿主自己记着“这个键发过”，只能证明宿主的意图，不能阻止接收者重复执行。接收者的去重记录还要与业务效果正确关联；先删除记录再执行、效果已经发生而去重记录不可靠，均不能提供所需承诺。我们使用已成立的接收者契约，不在客户端凭空补出它。

第3章的独占新文件也不等于业务幂等。它防止覆盖本次目标；下一次 run 使用另一个目录，仍可能再创建一个产物。动作是否重复，必须按业务身份和效果定义判断，不能按文件名不同或运行编号不同判断。

11.2核对结论与等待、重试

有了身份，查询才具有明确范围。核对请求应携带原接收者、账户与工作区绑定、操作身份或外部身份，并取得服务侧状态及对象版本。服务返回“处理中”时继续等待或停止观察；返回终结事实时核验结果；返回证据不足时保持未知，不让网络异常直接触发重试。

not_found 通常只说明本次查询没有找到记录。查询可能使用错误账户、遗漏了分区、命中了延迟副本，或发生在原请求仍在传输的时候。记录也可能已经过期。因此 unknown 和 not_found 都不是未执行证明，不能直接映射成新提交资格。

强一致查询要求观察已完成受理的最新事实，而不从延迟副本取得旧状态。但只有接收者同时提供完整 scope 的契约，并解决原请求仍可能被接收的时序，否定结果才可能证明未执行。例如，接收者能对操作身份作原子查询与提交判断，或已封闭旧提交路径。仅有强一致而仍容许旧请求晚到，不能排除查询之后的旧效果。

重试安全需要两类条件同时成立。一类来自旧操作：接收者有有效幂等记录，或有充分证据证明未提交、无旧在途提交且重新执行不会重复。另一类来自当前任务：目标仍有效，操作仍获准，版本前提、工具绑定和凭证仍符合要求。旧操作可去重，不表示当前还有权再发请求。

对于 partial，先解释哪些部分已确认。一个操作写了文件但没有完成远端登记，不能把全部动作当作未发生而重做。接收者若定义了同一操作的继续协议，可以按它的状态推进；没有这种协议，就保留部分效果，选择人工处理或新受控动作，不由客户端猜测接收者应该补做哪一半。

发件箱（outbox）是保存已提交业务意图、供调度者随后发送的耐久队列。它的最小形态是可靠保存操作内容与身份，再由发送者尝试交付。它解决意图容易丢失的问题，不保证任意外部效果恰好一次。发送者在交付后、记录回执前停止，仍可能重复发送。

所以 outbox 与接收者幂等可以共同建设可靠交付，却不能把其中一个当成另一个。发件箱记录本身也不应授予永不失效的权限。每次真正发送前重新核验当前资格；用户撤权后，可以保留未发意图作为事实，但不能因为它已经排队就继续执行。

重试还应保留上限和停止条件。接收者状态长期未知、去重期限临近或版本前提改变时，不能以不断重发代替核对。一次恢复可以诚实地结束为“旧效果未知，不自动重提”，并交付可继续调查的身份和证据。

11.3持久记录与事实重建

事件记录保存已发生的状态变化或可靠观察。快照（snapshot）保存某个版本的状态表示。检查点（checkpoint）标明这个表示对应哪一段已验证记录及哪些接续条件。三者不是三个同义的备份文件：快照可能完整却落后，事件可能更新却有残缺尾部，检查点则帮助确认怎样把它们关联。

最小恢复记录保留任务与动作身份、意图内容及 hash、尝试与受理事实、结果来源、当前对象观察、目标和授权版本、工具绑定及停止原因。模型消息也要保存其合法接续关系，但不能由一段聊天摘要证明文件已经写入或服务已经受理。

事件重放（replay）是在不产生业务效果的条件下，按事件重建状态。重放 write_intent 应恢复“有这项意图”，不是再调用写工具；重放结果应恢复已知回执，不是再次查询后把当前观察当作历史结果。状态重建与外部核对可以相继发生，但应保存为不同来源的事实。

读取时校验格式版本、任务身份、顺序、引用文件、大小与 hash，以及记录之间的绑定。hash 证明取得的字节与原引用一致，不证明内容真实、不证明授权当前有效，也不提供独立防篡改保证。所有记录都在同一个可被攻击者改写的目录时，自洽 hash 不能成为可信外部审计。

尾部不完整应隔离保存，不能猜补 JSON、跳过残缺动作后继续执行。经校验的完整前缀可以用于重建已知事实，但最后一次动作的结果仍可能未知。若发现中间缺口、相互冲突的版本或引用对象损坏，不能把它按普通尾部截断处理；自动接续应停止，保留原记录供核对。

快照要记录包含到哪个事件序号、对应记录摘要、状态格式及各绑定版本。恢复从已验证检查点重建，再读取后续完整事件。新快照写入、内容校验和检查点发布要有明确提交顺序；只看最新文件名或修改时间，无法证明那份快照已经完整提交。

第3章 Ledger.append 与 create_new 使用文件及目录同步。这提供的是声明文件系统和存储正确兑现 fsync 等操作时的本机耐久前提，不是存储共识。它不承诺整个磁盘丢失后仍可恢复，也没有实现副本协议。进程停止、主机掉电、介质丢失、外部服务丢记录，应分开声明覆盖范围。

本地账本与外部效果也不是一笔跨系统事务。账本先成功，不保证效果一定发生；效果先成功，不保证结果一定写回。恢复协议必须承认这些间隙，再用身份和核对补足证据，不能宣称多次 fsync 已经消除了所有未知。

11.4只读核对与恢复协议

第3章的摘录文件适合说明最小扩展，因为预期内容、来源和版本已经明确。harness.py 当前仍不支持 resume。最小只读 reconcile 契约先核验当前读取与发送许可，再读取旧 run 的证据，输出核对事实、缺口与外部确认要求，不执行 create_card。它不是执行前免费取得全部历史资料的旁路。

第一步关联意图与结果。核对 write_intent 的 action、目标、预期 hash、字节数、version 和 revision；再找对应 write_result 与验收记录。没有结果时，不把意图当成成功；有结果时，也不忽略后来文件改变。每项结论都注明来自历史账本还是当前对象观察。

第二步绑定实际对象。重新读取原 run 留下的文件，与原意图的预期字节、hash、长度和版本标记比较，不能拿另一目录中相似文件替代。文件存在但内容不符，应报告冲突或部分效果；完整匹配而结果记录缺失，可以报告当前存在符合意图的对象，却不能自动补造历史提交回执或过去的同步事实。

第三步核对来源与发送情况。从绑定的请求快照、工具结果及来源 hash 判断原材料是什么，以及两份材料是否进入产生创建请求的输入。快照脱敏后可能无法还原某些原字段，必须保存这一限制；缺少原字节时不能用现在同名材料替代历史快照，也不能靠摘要声称原文检查已经重新完成。

第四步核验当前目标与授权。旧 revision 说明当时依据什么执行，当前授权说明现在允许核对、发送、验收或续做什么。撤权后可能仍获准读取有限状态，却不再允许把文件交给模型或用户之外的接收者。当前用途的许可与旧效果事实必须分开，不通过改写旧 revision 把它们合并。

第五步处理旧执行者。第3章没有开放命令或 daemon 转交，也没有跨重启查询执行组的接口。若接续安全依赖旧写入已停止，需要来自外部的可靠确认，记录确认来源与覆盖范围，不能只从账本推断旧进程已经结束。扩展到命令或服务以后，看见 PID 不在，更不能证明后代、daemon 或远端任务已停。

只读核对因此不是“文件 exists 才 resume”。文件不存在时也可返回意图和未知，文件匹配时也可能仍无继续资格。它应分别报告当前对象是否符合原意图、历史结果是否可靠、来源与发送证据是否完整、当前核对权限是否成立、旧执行者是否已排除，以及剩余未知。

这项扩展不要求先建分布式存储。它先把第3章留下的证据变成可读的判断接口。真正 resume 还需认领和调度协议；只读核对通过，至多是其中一项前提，不能自行启动新一轮模型或业务动作。

核对能给出一部分答案，接手还需要一份完整记录。恢复记录（resume record）是接手所需事实和资格的结构化集合，不是只有消息历史的会话文件。最小协议也要完整表达身份、版本、未决动作、证据、所有者和允许的下一步。字段完整不等于值都已知；未知应显式携带原因，不用空字符串冒充不存在。

下面给出 resume/v1 的建设 schema。它定义字段责任，不是已实现的数据类或分布式存储代码。标识使用不透明字符串；hash 说明算法和所指字节；时间注明来源。每个动作和尝试都按同样结构保存，不能只保留最后一条错误。

引用字段可以指向本机可信文件或已有服务记录，但引用位置和读取权限属于协议。凭证字段只引用绑定和可用状态，不保存秘密。没有使用租约或方法时记录“不适用”及依据；缺失必要证据时记录“未知”并阻止依赖它的下一步，不能让默认值悄悄放宽条件。

完整 resume 流程先核验当前核对与发送许可，再验证存储和检查点，重放完整事件，核对未决动作。取得认领资格后，重新检查 current revision、目标、执行授权、对象版本、工具和执行器绑定、凭证及预算，形成允许的下一步。每次新动作启动前还要在提交边界复查，不能认为启动时检查一次便永久有效。

调度提交要与持久状态版本关联。单宿主可以在同一受控临界区检查当前 revision、记录决定并进入提交门；多人或多 worker 更新时需要存储提供相应的条件更新契约。这里讲明条件，不用一段内存布尔值伪装分布式原子操作。

原方法或工具版本不可获得时，仍可以保存和解释旧事实，但不能按最新同名实现执行旧 payload。迁移需要明确的新决定和重新验证。目标改变也一样：旧事实可以供新目标参考，不等于旧计划中的剩余动作自动转为新任务的授权动作。

11.5认领资格与旧执行者排除

认领（claim）是协调存储授予某个调度者在指定版本和范围内推进任务的资格。它不是接手者自己写一句“由我继续”。认领应有所有者、代次和条件更新依据，并明确旧执行者还可能拥有哪些能力。

单宿主最小方案可以使用文件锁，让遵守同一锁协议的进程在临界区内串行更新。文件锁解决这些本机参与者同时认领或写账的问题，不自动覆盖绕过锁的进程，也不撤销已提交的外部任务。进程退出释放锁，只说明这个锁不再被它持有，不证明其后代或 daemon 没有继续工作。

租约（lease）是在约定期限内有效的所有权声明，便于协调者失联后允许重新认领。租期不是死亡证明。旧 worker 可能暂停、网络隔离或暂时不能续租，之后仍恢复运行；它手里也可能已有一项外部请求。租约过期不等于那些效果不再发生。

隔离代次（fencing epoch）是随认领递增的代次，用来拒绝旧所有者的更新。只在宿主账本检查 epoch，可以挡住旧 worker 更新本地状态，却不能挡住它调用外部服务写数据。旧代次仍可能产生外部效果，随后才被本地拒绝入账。

有效 fencing 必须在效果执行处被认可。接收者需要把操作与当前代次关联，在实际变更的原子边界拒绝过时代次，且契约要说明已经受理的旧工作如何处理。客户端发送一个 epoch 字段、服务忽略它，不构成 fencing；服务只在客户端提交前让其自查，也不能封住检查后的间隙。

本地命令同样需要执行处约束。若不能让实际写入路径识别代次，就必须依赖可信执行组停止证明或其他排除旧效果的机制，再允许冲突性新动作。仅更新账本所有者、杀根进程或查询一个 PID，都不能自动证明旧动作已失去效果能力。

所以认领有两个不同出口：取得事实整理权，取得新效果调度权。接手者可以先在只读范围核对，即使旧执行者状态还未知；若下一步可能与旧效果冲突，则必须补齐停止、幂等或执行处 fencing 条件。不能为了把运行状态显示成恢复成功而合并这两个出口。

没有接收者 fencing、可靠去重或旧执行组证明的系统，可以保留人工确认策略。它并非失败的分布式实现，而是明确没有建设那项能力。第6章的单线推进仍可继续使用，本书不要求为了恢复而新增 agent 或多 worker。

11.6当前资格与迟到事实

认领之后还要面对用户纠正。事实入账把可靠观察记入旧动作账目；调度生效决定这项观察是否可以推动当前任务。迟到结果可能有历史价值，却不自动携带当前行动权限。把它们分开，才不会为了拒绝旧调度而丢掉已经发生的效果。

例如，旧授权下已受理的动作在撤权后返回完成，可以入账为旧动作的结束事实。当前界面应说明它属于旧 revision，并重新判断是否允许发送和使用。下一项操作必须依据当前目标和授权，不能沿用返回结果所带的旧计划。历史事实晚入账可以成立，新调度依据必须是 current。

重试前也要重新检查版本。目标 revision、授权 revision、目标对象版本、工具 schema 和实现绑定、执行策略、方法依赖及当前凭证各有含义。授权修订号变了，不必抹掉旧效果，但必须重新取得当前执行决定；payload 语义变了，则不能继续复用原操作键冒充同一操作。

组织平台恢复应保留原任务用户与工作区，不采用接手者正在浏览的界面范围。provider 模式重新核验用户在原工作区的当前平台授权，再使用对应平台执行能力；connector 模式重新核验原本地用户与目标账户绑定以及当前凭证，交由目标平台判断资源权限。第13章会展开这些责任，这里只确立恢复必须经过的接点。

凭证刷新可以保持同一账户绑定，但身份和范围要重新核验。凭证失效不能自动换成平台宽权限账户或另一用户的连接。外部查询需要的权限也应独立判断：用户可能允许核对旧任务，却禁止再产生效果；也可能连旧结果发送都已撤回。

模型响应缺失是另一项边界。服务曾经生成过什么，不能由本地摘要恢复出来。没有可靠保存的响应，就没有可执行的旧工具提议，也不能猜出原 reasoning 或不透明接续项。可以依据已验证事实建立新的上下文，但这是一项新的模型请求，不是找回原思考。

第9章的摘要只能重建任务所需表示，不能替代接口要求保留的调用配对、签名或接续字段。需要开启新合法会话时，应明确原响应缺失，携带当前目标、已知效果和未决动作，并重新计入预算。未知旧动作仍留在控制状态中，不能因历史被压缩就从事实记录中消失。

11.7补偿与阶段结束的新决定

补偿是为处理已发生效果而执行的新动作。它不是让历史从未发生，也不是通用 rollback。删除新建的文件不能收回已经发送的内容；恢复一个文件版本也可能覆盖别人之后的修改。补偿需要自己的目标、权限、身份、版本前提、强制执行和验收。

最小补偿方案可以只是提出可核对的选择，不自动执行。确需自动补偿时，先记录新意图，再在第10章的边界内执行，结果与原动作关联。补偿失败或未知也要进入同样的核对规则，不能用清理函数吞掉异常后宣布现场已恢复。

用户撤权尤其不能被解释成自动补偿许可。用户可能允许查看旧任务状态，不允许删除产物；也可能只要求停止进一步工作。已有授权若没有清楚包含相应补偿，宿主应停止并请求新决定。历史完成事实照常保留，当前使用和新效果分别控制。

长任务应在业务阶段完整结束之后，再迁移上下文或方法。这里的“结束”指：已确认的动作结果、必要的生命周期终结依据、产物验收、当前目标与授权判断，以及未解决问题的登记。阶段结束不要求所有未知都消失，但有未知时不能把依赖其结果的下一阶段默认为可执行。

第9章的历史压缩要保留这些事实与引用，第13章的工具或方法迁移要核验原绑定及替代契约。上下文检查点更新不授予新调度权；方法包更新不重新解释旧 payload；删除已无收益的恢复组件，也不能删除仍承担核对责任的记录。

预算和费用随动作尝试保存，不因 restart 清零。重试模型请求会再次提交上下文并可能发生额外输出，使用第3章日期化基线核算已知用量，真实账单另按实际契约核对。未知响应的费用仍未知，不补成零；新的摘要请求也计入请求次数和用量。

随书 practices.py 的 reconcile_run 实现的是只读记录核对，不是 resume。它限量读取本项目旧 run 的 events.jsonl 和 card.md，检查物理换行完整性、事件顺序、动作与版本关联、当前文件 hash 与字节数，以及账本中来源与发送范围的绑定。按 JSONL 的物理 LF 分隔，不能把合法 JSON 字符串里的 Unicode 分隔字符误当成新事件。

在项目根目录运行 python3 -I -B book/v2/practices.py --reconcile book/v2/runs/某次运行目录，目录须替换为自己的实际记录。当前限定实现依赖本项目可信目录，没有建立组织授权服务；调用者先确认自己获准核对和发送这些材料，不把命令入口当作授权。

本次已对第3章留下的748字节文件做进程退出后的核对，结果为 matched。它表示限定记录与当前字节匹配，同时明确 full_acceptance=false、no_resume=true。代码没有独立重读原请求载荷来证明材料已进入请求，没有重建当前执行授权，没有排除所有旧执行者，也不重新判断原文选择或语义质量。账本的历史停止状态照样保留，不提升成当前续跑许可。

新增39项局部契约测试包括这项核对、缺失结果、残缺尾部、字节和版本不匹配、旧产物保留及 Unicode 字符等路径。它们不证明接收者去重或执行处 fencing 已落实。恢复 schema、认领和自动续跑仍是本章给出的建设契约；本次没有真实模型重试或实际模型费用。

可靠接续最终是一项有条件的判断：旧事实足以支撑什么，当前条件允许什么，执行处能够保证什么。可以继续则记录依据并受控推进；不能继续则保留证据和未知。这个出口不要求系统成为全自动恢复平台，也不把重试次数多当作可靠性的证明。

11.8本章判据

• ☐是否区分未提交、accepted、running、finished、partial 和 unknown，而不从丢响应推断未执行？
• ☐action、attempt 与 external identity 是否分别保存，幂等是否具有接收者记录、scope、identity 和 retention 契约？
• ☐同一操作身份携带不同 payload 是否拒绝，否定查询是否没有超出强一致、完整范围及提交时序的证明能力？
• ☐outbox 是否只承担耐久意图与交付责任，而不声称任意效果恰好一次？重试前是否重核当前资格？
• ☐replay 是否只重建状态，snapshot、checkpoint、hash 与版本是否关联，残缺尾部是否隔离且不猜补效果？
• ☐只读核对是否关联意图、结果、实际对象、来源、发送、当前授权与旧执行者，而不是只检查 exists？
• ☐resume schema 是否完整保存未决动作及未知，claim、current revision 与新提交是否有明确接收边界？
• ☐文件锁、租约和 fencing 是否各有范围，执行处是否认可 fence，租期和 PID 是否没有被当作死亡证明？
• ☐迟到事实是否可以有限入账，但新调度必须 current？原工作区、账户与当前凭证是否重新核验？
• ☐缺失模型响应是否没有被摘要伪造恢复，补偿是否作为新受控动作，重启是否不抹掉未知费用和已用预算？

本章没有回答什么

本章没有实现分布式账本、存储共识、任意外部操作恰好一次或所有故障下自动恢复。文件同步承诺依赖已声明的存储前提；接收者去重、查询和 fencing 能力依赖它自己的契约，没有这些条件时仍应停下。

本章也没有把第3章程序改成可 resume 的系统，没有把缺失模型响应还原成历史思考，没有自动删除撤权后的旧产物。它给出的是从证据到继续资格的完整判断路径。第12章将把这些边界组织为可追溯验证，第13章再处理集成、契约迁移和可选组织扩展。