模型: gpt-5.4 (openai/gpt-5.4) 生成日期: 2026-04-01 书名: Claude Code VS OpenCode：架构、设计与未来 章节: 第5章 — 会话与上下文管理 Token消耗: 约 18,500 input + 4,100 output（估算）

5.4 会话恢复与续接

会话恢复回答“怎么把过去找回来”，会话续接回答“找回来以后怎么继续做”。二者看似接近，其实不同。恢复更像读档，续接更像读档后无缝继续施工。对编码智能体而言，真正困难的不是把历史文件重新加载，而是避免上下文重置后丢掉任务动量。这里可以把这个难题称为续接问题：上下文被压缩、进程被打断、窗口被清空之后，系统如何仍然知道自己做到哪、下一步该做什么、哪些承诺还未完成。

OpenCode 已经具备比较完整的恢复基座。session/index.ts 里可以看到 time_archived 字段与 setArchived()，说明会话可归档；消息和 part 作为结构化记录被保存在 SQLite 中，因此恢复时不是读一份模糊文本，而是重建可查询状态。再结合 summary.ts、revert.ts、snapshot diff 等机制，OpenCode 的恢复逻辑更像“数据库级恢复”：会话、摘要、差异、回滚点都在同一套模型内。

Claude Code 则把恢复体验做成显式命令。用户熟悉的 /resume 或 claude --resume，底层会走 loadConversationForResume()，再从 JSONL transcript 中恢复消息、fileHistory、content replacements、context collapse 状态、worktree 状态、agent setting、tag 等元数据。sessionStorage.ts 还专门处理 compact_boundary，确保 resume 时不会把压缩前的大段旧历史重新整包装回去。也就是说，Claude Code 的恢复不是简单“打开旧文件”，而是一次带剪枝和重建的日志回放。

OMO 进一步把“恢复”升级为“继续干活”。一方面，它通过 Claude Code 兼容钩子与 continuation hooks，在会话中断、压缩、停止后注入恢复信息；另一方面，boulder-state 会把当前活跃计划写进 .sisyphus/boulder.json，记录 active_plan、started_at、session_ids、plan_name，必要时还记录应使用的 agent。这个文件的重要性在于：它把“正在推哪块石头”从聊天历史里剥离出来，单独变成恢复锚点。

另外，OMO 的 loop-session-recovery.ts 维护了短窗口恢复状态，Ralph Loop 与 todo continuation 机制则在更高层保证“没做完就继续”。这背后体现的不是单纯的 session management，而是一种任务连续性设计。传统 CLI 认为中断后重新输入命令即可；智能体系统若也这么设计，就会频繁丢失执行承诺。

因此，解决续接问题至少需要四类锚点：第一，历史锚点，知道说过什么；第二，结构锚点，知道压缩边界和父子链；第三，进度锚点，知道 todo 或计划完成到哪；第四，环境锚点，知道 worktree、cwd、agent、权限状态是否变化。OpenCode 强在前两类，Claude Code 强在日志回放与边界恢复，OMO 则把第三类——进度锚点——补得最狠。

从理想 Agent 设计看，恢复系统不该只恢复“记忆”，还必须恢复“意图、进度与责任”。如果下一次启动只能告诉模型“我们之前聊过什么”，却不能告诉它“还欠哪些事没做完”，那恢复了一半，工作却断了。真正优秀的续接机制，应该让用户感觉这不是一个新会话，而是同一个工程师从短暂离席后回到了工位。