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

5.1 会话持久化

会话持久化，指的是智能体把“已经发生过的对话、工具调用、编辑痕迹与任务状态”可靠保存下来，使系统在下一次启动、压缩、切换终端甚至异常中断之后，还能接着干活。它不是传统教材中的标准章节名，更接近工程界对“长期运行状态保存”的通俗说法。对编码智能体而言，持久化不是附属功能，而是把一次性聊天变成连续软件工作的前提。

OpenCode 的选择是 SQLite + Drizzle ORM。从 /packages/opencode/src/session/session.sql.ts 可以看到，它把 session、message、part、todo 分成多张表：会话是顶层对象，消息是中层记录，part 则把一条消息拆成 text、reasoning、tool、snapshot、patch 等更细颗粒。这个设计明显带有关系型思维：先定义实体，再定义关系，再通过索引和 schema 保证一致性。它的优点是结构清晰、查询精确、适合做归档、过滤、统计和局部更新；缺点是实现复杂度更高，迁移和版本兼容也更重。

Claude Code 的路径几乎相反。src/utils/sessionStorage.ts 表明它把会话落到 *.jsonl 文件中。JSONL 可理解为“每行一个 JSON 对象的日志文件格式”：不是把整个会话改写成一个大对象，而是像记流水账一样不断 append。它代表的是一种日志型存储思维——先保证顺序追加和恢复，再在读取时重建链路。其优点是实现直接、写入快、对崩溃更友好，也天然适合流式输出；代价则是读取时要做更多“回放”和“重建”，例如依靠 parentUuid、compact_boundary、元数据记录来恢复真正有效的对话链。

如果说 OpenCode 更像“数据库里的会话系统”，Claude Code 更像“事件溯源式的会话账本”。前者强调规范化建模，后者强调 append-only 日志。两者没有绝对高下，而是优化目标不同。OpenCode 更适合开放平台和插件生态，因为第三方能力需要稳定 schema；Claude Code 更适合产品级高频交互，因为日志写入路径短、失败面小、对实时 UI 更自然。

Oh-My-OpenCode 并没有推翻 OpenCode，而是在其上继续加状态层。它继承宿主的 SQLite/消息模型，同时补上持续执行所需的状态追踪。最典型的是 boulder-state：src/features/boulder-state/storage.ts 会把当前 active plan、started_at、session_ids、plan_name 以及可选 agent 写入 .sisyphus/boulder.json。这意味着 OMO 不仅记住“聊到了哪里”，还记住“这块石头已经滚到哪一步”。对多轮长任务来说，这比单纯保存聊天记录更重要。

因此，三者的权衡可以概括为三句话。OpenCode 追求结构化可查询性，所以选关系型；Claude Code 追求高吞吐可恢复性，所以选 JSONL 日志；OMO 追求不中断的任务连续性，所以在关系型宿主之上再叠加工作状态。前两者在回答“历史怎么存”，OMO 额外回答“进度怎么续”。

从 Agent 设计角度看，理想方案往往不是二选一，而是分层：底层用日志保证不丢事件，中层用结构化索引支持查询，上层再维护任务状态与恢复指针。换句话说，会话持久化最好拆成三层：事件层、结构层、进度层。只做第一层，能恢复聊天；做到第三层，才能恢复工作。