目录1. 引言2. Agent 的数据存储需求3. SQLite 的核心优势3.0 SQLite 是什么类型的数据库3.0.1 那 NoSQL 数据库呢3.1 零配置、零服务3.2 单文件存储3.3 轻量高效3.4 标准 SQL 支持3.5 可靠性4. 与 MySQL / PostgreSQL 的对比5. SQLite 的适用边界6. 总结1. 引言在构建 AI Agent智能体时一个经常被问到的问题是为什么很多 Agent 框架和项目选择 SQLite 作为默认数据库而不是 MySQL、PostgreSQL 这类更“重量级”的数据库这个选择看似简单背后却涉及 Agent 应用的特殊需求轻量、本地优先、零配置、单文件、并发可控。本文从 Agent 的实际使用场景出发拆解 SQLite 被选中的核心原因并指出它的适用边界。2. Agent 的数据存储需求Agent 应用与传统 Web 应用的数据访问模式有明显差异本地优先多数 Agent 运行在用户本机或边缘设备数据以本地文件为主不需要远程数据库服务。单机为主单个 Agent 实例通常只服务一个会话或一个用户并发量低不需要分布式能力。快速迭代Agent 的记忆、会话、工具调用记录等数据结构频繁调整需要灵活、低摩擦的存储方案。部署简单用户希望“下载即用”不希望额外安装和配置数据库服务。这些特点决定了 Agent 对数据库的核心诉求轻量、零运维、可靠、够用。3. SQLite 的核心优势3.0 SQLite 是什么类型的数据库先回答一个最基础的问题SQLite 是关系型数据库RDBMS。它遵循关系模型数据以表table的形式组织表之间通过主键和外键建立关联支持标准的 SQL 查询语言并完整支持 ACID 事务、索引、视图、触发器等功能。它与 MySQL、PostgreSQL 同属关系型数据库家族。核心区别在于部署形态SQLite 是嵌入式关系型数据库整个数据库引擎作为一个库文件直接链接进应用程序进程无需独立的服务器进程而 MySQL/PostgreSQL 是客户端-服务器架构需要独立安装和启动服务。可以这样理解SQLite 是关系型数据库只是它把整个数据库引擎“内嵌”到了你的程序里而不是作为一个独立服务运行。3.0.1 那 NoSQL 数据库呢既然 SQLite 是关系型数据库那 Agent 为什么不直接用 NoSQL 数据库如 MongoDB、Redis、向量数据库呢这同样要回到 Agent 的实际需求来看。NoSQL 数据库确实在某些方面有优势但对大多数 Agent 场景并不必要数据模型Agent 的记忆、会话、工具调用记录大多是结构化程度较高的数据用关系模型表达清晰自然而 NoSQL 的文档/键值模型在简单场景下反而增加了建模成本。事务与一致性SQLite 完整支持 ACID 事务能保证记忆和会话状态的一致性多数 NoSQL 数据库在分布式下只能提供最终一致性对需要可靠持久化的 Agent 并不友好。部署复杂度MongoDB、Redis 通常需要独立服务进程违背了 Agent「下载即用、零配置」的诉求而 SQLite 只是一个库文件。查询能力SQL 的联表、聚合、索引能力成熟且通用NoSQL 的查询往往受限于自身模型复杂查询需要额外开发。需要说明的是向量数据库如 Chroma、FAISS在 Agent 的 RAG检索增强生成场景中确实有独特价值但它通常与 SQLite配合使用而非替代SQLite 负责结构化数据会话、记忆、配置向量库负责非结构化内容的相似度检索。两者各司其职并不冲突。所以结论是NoSQL 不是 Agent 的默认选择不是因为 NoSQL 不好而是因为 Agent 的多数数据需求用关系型 SQLite 就足够且更简单只有在特定场景如向量检索才需要引入 NoSQL 组件。3.1 零配置、零服务SQLite 是一个嵌入式数据库不需要独立的服务器进程。它只是一个库文件直接链接进你的程序。这意味着无需安装、无需启动服务、无需配置端口和账号。对用户完全透明开箱即用。对于 Agent 这种需要“随处运行”的应用这是巨大的部署优势。3.2 单文件存储整个数据库就是一个.db文件。这个特性带来几个直接好处便于备份和迁移复制一个文件即可完成备份。便于分发可以把带数据的数据库文件直接随应用分发。便于清理删除文件即删除全部数据。3.3 轻量高效SQLite 体积小约几百 KB运行时内存占用低非常适合资源受限的环境如树莓派、嵌入式设备、Docker 容器。对于 Agent 常见的读写模式——少量数据、低频写入、单进程访问——SQLite 的性能完全够用甚至比连接远程数据库更快省去了网络开销。3.4 标准 SQL 支持SQLite 支持标准的 SQL 语法包括事务、索引、视图、触发器。这意味着开发者无需学习新的查询语言。可以平滑迁移到 MySQL/PostgreSQL如果未来需要。生态成熟各种语言的驱动都很完善。3.5 可靠性SQLite 支持 ACID 事务具备崩溃恢复能力。对于 Agent 的记忆持久化、会话状态保存这类关键数据SQLite 能提供足够的数据安全保障。4. 与 MySQL / PostgreSQL 的对比维度SQLiteMySQL / PostgreSQL部署嵌入式零配置独立服务需安装配置存储单文件数据目录/集群并发单写多读写锁全局高并发行级锁适用场景本地、单机、轻量服务端、多用户、高并发运维成本几乎为零需要 DBA 或运维网络访问不支持本地文件支持远程连接结论很清晰Agent 的场景更接近“本地单机应用”而不是“高并发 Web 服务”因此 SQLite 是更匹配的选择。5. SQLite 的适用边界SQLite 并非万能以下场景不建议使用多进程高并发写入SQLite 的写锁是全局的高并发写入会成为瓶颈。多机分布式部署SQLite 不支持网络访问无法跨机器共享。海量数据单文件在数据量极大时性能和备份都会遇到挑战。多用户共享多个用户同时读写同一数据库文件时需要额外的锁机制。如果你的 Agent 需要扩展为多实例、多租户的云端服务届时再迁移到 PostgreSQL 也不迟——SQLite 到 PostgreSQL 的迁移路径是成熟且平滑的。6. 总结Agent 选择 SQLite本质上是场景匹配的结果本地优先、单机运行、低并发 → 不需要重型数据库。零配置、单文件、轻量 → 部署和分发极其方便。标准 SQL、ACID 事务 → 功能够用且可靠。它不是“最好的数据库”而是“最适合 Agent 的数据库”。在 Agent 从单机走向规模化服务的过程中SQLite 是一个理想的起点而不是终点。