为什么 Agent 用 SQLite 数据库？

目录

• [1. 引言](#1. 引言)
• [2. Agent 的数据存储需求](#2. Agent 的数据存储需求)
• [3. SQLite 的核心优势](#3. SQLite 的核心优势)
  • [3.0 SQLite 是什么类型的数据库？](#3.0 SQLite 是什么类型的数据库？)
  • [3.0.1 那 NoSQL 数据库呢？](#3.0.1 那 NoSQL 数据库呢？)
  • [3.1 零配置、零服务](#3.1 零配置、零服务)
  • [3.2 单文件存储](#3.2 单文件存储)
  • [3.3 轻量高效](#3.3 轻量高效)
  • [3.4 标准 SQL 支持](#3.4 标准 SQL 支持)
  • [3.5 可靠性](#3.5 可靠性)
• [4. 与 MySQL / PostgreSQL 的对比](#4. 与 MySQL / PostgreSQL 的对比)
• [5. SQLite 的适用边界](#5. SQLite 的适用边界)
• [6. 总结](#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 的对比

维度	SQLite	MySQL / PostgreSQL
部署	嵌入式，零配置	独立服务，需安装配置
存储	单文件	数据目录/集群
并发	单写多读，写锁全局	高并发，行级锁
适用场景	本地、单机、轻量	服务端、多用户、高并发
运维成本	几乎为零	需要 DBA 或运维
网络访问	不支持（本地文件）	支持远程连接

结论很清晰：Agent 的场景更接近"本地单机应用"，而不是"高并发 Web 服务"，因此 SQLite 是更匹配的选择。

5. SQLite 的适用边界

SQLite 并非万能，以下场景不建议使用：

• 多进程高并发写入：SQLite 的写锁是全局的，高并发写入会成为瓶颈。
• 多机分布式部署：SQLite 不支持网络访问，无法跨机器共享。
• 海量数据：单文件在数据量极大时，性能和备份都会遇到挑战。
• 多用户共享：多个用户同时读写同一数据库文件时，需要额外的锁机制。

如果你的 Agent 需要扩展为多实例、多租户的云端服务，届时再迁移到 PostgreSQL 也不迟------SQLite 到 PostgreSQL 的迁移路径是成熟且平滑的。

6. 总结

Agent 选择 SQLite，本质上是场景匹配的结果：

• 本地优先、单机运行、低并发 → 不需要重型数据库。
• 零配置、单文件、轻量 → 部署和分发极其方便。
• 标准 SQL、ACID 事务 → 功能够用且可靠。

它不是"最好的数据库"，而是"最适合 Agent 的数据库"。在 Agent 从单机走向规模化服务的过程中，SQLite 是一个理想的起点，而不是终点。