Session 中断后重新启动时如何恢复上下文？

核心回答

OpenCode 是能够阅读仓库、修改文件和执行命令的编程助手。以该版 TypeScript 会话实现为例，它把用户输入受理、会话执行和模型输入重建分开：先将输入写入持久待处理队列，按会话串行推进步骤；服务重启后检查遗留执行标记，核对未结束的工具记录，再从持久消息重建上下文继续。

这恢复的是任务的推进依据。它不会接回旧模型请求的进程现场，也不会仅凭会话恢复就撤销或去重所有文件、命令和外部系统的副作用。

输入先持久受理，再唤醒执行

Session.prompt 先按输入 ID 核对已有记录，再准备并受理输入，之后才唤醒执行器。resume: false 可以只受理而暂不执行。相同会话、相同输入类型和相同 ID 的重试沿用第一次受理的内容，因此重新发送并不意味着替换原输入。

待处理输入保存在 session_inbox 中；投递时消费待处理行，并在同一事件事务中插入可见消息。这样，恢复时可以区分“已经受理、尚未投递”和“已经成为会话消息”的输入，而不依赖客户端是否收到了响应。

重启标记与执行协调各管一件事

执行器在开始执行时，随开始事件的事务写入持久执行标记。正常完成、失败或用户主动中断会释放标记；服务关闭导致的中断保留标记，进程突然退出也可能留下它。

受管理服务启动时，恢复扫描识别这些遗留会话，持久增加恢复尝试次数，再安排继续执行；超过预算则记录失败。这个标记用于识别未结束的执行，不是分布式租约。

同一会话的多次唤醒由进程内协调器合并，同一会话串行推进，不同会话可以并发。重启恢复假定旧进程已经退出，不能据此允许多个进程共享数据库并同时接管同一会话。

先结清遗留记录，再重建模型输入

Runner 开始推进时，会把遗留的 streaming／running 工具记录标为中断失败，把遗留的执行中压缩记录标为压缩失败。这段处理让后续模型能看到调用没有取得正常结果，避免历史永远停在“执行中”；它没有证明实际动作未发生，也没有恢复那个动作的执行现场。

之后每一步重新选择会话上下文并加载持久历史，再进行一次模型流式请求。工具调用及结果进入会话记录，下一步从更新后的历史继续，而不是依赖一个只在内存里保存消息的无限工具循环。

长历史采用压缩时，本地摘要路径会保留任务目标、要求、决定、工作状态和下一步等内容，并通过 keepID 引用近期消息；历史加载再取回这些近期消息组成文本，与摘要及后续消息一起重建模型输入。原生模型压缩还有模型兼容条件，不能将任意压缩结果直接用于任意模型。

哪些状态仍要另行核对？

最关键的情况是：工具已经修改文件或完成外部请求，但进程在结果落库前退出。恢复后即使工具记录被标成中断，动作也可能已经发生。输入 ID 的受理幂等与会话串行，都不能替代业务动作的幂等和结果核对。该版重启恢复明确采用至少一次的执行语义。

同样，遗留后台 Shell 的取消或完成通知，是对后台任务状态的处理；不能把通知当成任意子进程、外部服务或业务资源已经恢复的证据。文件快照与显式回退也不能撤销任意命令的外部副作用。

验证时应分别在输入受理后、工具动作完成但结果未写入时、模型输出中途和压缩过程中终止进程，再检查恢复后的输入数量、消息顺序、工具状态及实际文件或业务结果。还要区分用户主动停止与服务退出，确认不会把用户已取消的任务自动重启。