方案选型对比

3.1 候选格式概述

在 AI 编程助手的上下文存储场景中，常见的候选数据格式包括：

3.2 对比维度

为了全面评估各格式的适用性，我们从以下维度进行对比：

3.2.1 写入性能

JSONL：

• 追加写入：O(1)，只需在文件末尾添加新行
• 无需读取现有内容
• 适合高频写入场景

JSON 数组：

• 追加写入：O(n)，需要读取 - 修改 - 重写整个文件
• 文件增大后性能急剧下降
• 不适合频繁追加的场景

SQLite：

• 追加写入：O(log n)，B 树索引开销
• 支持事务，保证 ACID 特性
• 适合需要强一致性的场景

纯文本：

• 追加写入：O(1)
• 但缺乏结构化，后续处理困难

3.2.2 读取性能

JSONL：

• 顺序读取：O(n)，流式处理
• 随机访问：O(n)，需要扫描
• 内存占用：O(1)，恒定

JSON 数组：

• 顺序读取：O(n)，但必须一次性加载全部数据
• 随机访问：O(1)，内存中直接索引
• 内存占用：O(n)，与文件大小成正比

SQLite：

• 顺序读取：O(n)
• 随机访问：O(log n) 或 O(1)（带索引）
• 支持复杂查询和聚合

3.2.3 存储效率

3.2.4 可维护性

JSONL：

• 人类可读：是
• 文本工具兼容：优秀（grep, sed, jq）
• 损坏恢复：单行损坏不影响其他记录
• 版本控制友好：diff 清晰

JSON 数组：

• 人类可读：是（小文件）
• 文本工具兼容：差（单行或大文件难以处理）
• 损坏恢复：整个文件可能无法解析
• 版本控制友好：中等

SQLite：

• 人类可读：否（二进制格式）
• 文本工具兼容：差（需要专用工具）
• 损坏恢复：可能损坏整个数据库
• 版本控制友好：差

3.3 决策矩阵

基于 AI 编程助手的核心需求，我们定义以下评估标准：

3.3.1 综合评分

3.4 实际案例分析

3.4.1 Claude Code

存储位置：~/.claude/projects/ 和 ~/.claude/history.jsonl

使用模式：

• 每个项目一个 JSONL 文件
• 每条消息占用一行
• 包含完整的工具调用和结果

优势体现：

• 用户可以随时查看历史会话
• 工具可以轻松解析和导出
• 即使会话长达数月也能高效处理

3.4.2 Cursor

存储方式：SQLite 数据库

使用场景：

• 全局存储（globalStorage）
• 需要跨项目查询
• 复杂的会话管理功能

权衡考虑：

• 牺牲了部分可读性
• 获得了更强的查询能力

3.4.3 Gemini CLI

存储位置：~/.gemini/sessions/

使用模式：JSON 文件（非 JSONL）

局限性：

• 会话较大时性能下降
• 追加操作需要重写整个文件

3.5 为什么 AI 工具选择 JSONL

综合以上分析，AI 编程助手选择 JSONL 的核心原因包括：

3.5.1 对话本质上是日志

AI 对话具有以下特征：

• 追加为主：新消息不断添加，历史消息极少修改
• 时间顺序：按时间顺序存储和读取
• 独立性：每条消息可以独立理解

这些特征与 JSONL 的设计目标完美匹配。

3.5.2 流式处理需求

AI 工具需要：

• 实时显示对话进度
• 支持长对话不占用过多内存
• 能够在对话过程中持续记录

JSONL 的流式特性使得这些需求得以高效实现。

3.5.3 调试和可解释性

开发者需要：

• 直接查看原始对话数据
• 使用标准工具分析日志
• 在问题发生时快速定位

JSONL 的人类可读性和工具兼容性提供了这些能力。

3.5.4 数据迁移和互操作性

用户需要：

• 在不同工具间迁移对话历史
• 导出数据进行备份或分析
• 第三方工具能够解析数据

JSONL 作为开放标准，降低了生态系统的互操作成本。

3.6 替代方案对比总结

参考资料

• JSONL 优势 - 详细的格式对比
• SuperJSON JSONL vs JSON 分析 - 性能基准测试
• mnemo 项目案例 - 多工具 JSONL 索引实践