指南
AI Agent 该用什么数据库？
简短回答：状态用 Postgres，召回用 pgvector 或向量库，缓存用 Redis，遥测用分析型数据库。大多数智能体系统只需要其中两个，而不是四个；而且引擎选型的影响，远没有相关文章数量暗示的那么大。
本文先把这个问题答完。然后讲引擎选型漏掉的那块：智能体产出的业务事实——人和后续的智能体运行都要读、要信、也要能撤回。
最后核对：2026 年 11 月 13 日
智能体到底在存什么
「给 AI Agent 用的数据库」其实是五种同时到来的负载。拆开看，选择就很清楚：
| 存的是什么 | 访问模式 | 合理的默认选择 |
|---|---|---|
| 应用与会话状态 | 小量读写、事务性、必须精确 | Postgres |
| 文档的语义召回 | 对向量做近似最近邻搜索 | pgvector；规模很大时用专用向量库 |
| 热上下文与限流 | 亚毫秒级、临时、变化频繁 | Redis |
| 提示词/回复日志与 token 计费 | 大量追加写、聚合读 | ClickHouse、DuckDB/MotherDuck，或先用 Postgres 直到撑不住 |
| 智能体产出的业务事实 | 人和后续智能体当作事实来读；必须看得出谁改了什么 | 带修改历史的工作区，比如 Busabase（见下文） |
从 Postgres 开始，并且认真用它
对大多数智能体项目来说，只用 Postgres 就是正确的第一步，第一天就加第二套系统为时过早。状态、关系、JSON、全文检索，以及通过 pgvector 实现的向量，它都能扛到大多数智能体产品永远达不到的规模。
别太早上专用向量数据库。pgvector 支持 HNSW 和 IVFFlat 索引。单独的向量服务换来的召回性能，你现在多半还测不出来，代价却是多一个一致性边界、多一套要运维的东西。
别把提示词和回复日志写进存状态的那个 Postgres。完整的提示词/回复记录是大量追加写、无限增长的；和事务表放在一起，几个月后就会变成清理和分区的难题。遥测尽早单独存放。
什么时候值得上专用向量库或 Redis
- 向量库：向量达到数千万级、并且你真的在测延迟目标；大量元数据过滤要和近邻搜索一起用（pgvector 在近似索引扫描之后才应用过滤，0.8.0 起加了迭代索引扫描来弥补）；或者频繁全量重新向量化，想和主库的负载隔开。
- Redis：会话上下文、工具调用限流、去重窗口、队列状态——这些按请求发生的事 Postgres 也能做，只是延迟达不到你的要求。Redis 不是记录系统，把它当记录系统用，迟早会因为淘汰策略丢掉一整天的工作。
没到这些门槛之前，多运维一套系统的成本大于性能差异。先测量，再迁移。
问题底下的那个问题
上面每个选项回答的都是字节放在哪。没有一个回答改了什么、谁改的、能不能改回来——而对智能体的工作来说，决定项目能不能被信任的，正是后一个问题。
假设一个智能体补全了 200 条客户记录，正确地写进 Postgres，权限也完全没问题。其中一些是错的——格式没毛病，只是自信地错了。每条约束都通过了，旧值已经没了。整个系统里没有任何东西能告诉后来的人：智能体动了哪几行、原来是什么、是哪个智能体干的。
这不是引擎的问题，所以换引擎解决不了。约束校验的是格式，行级安全校验的是权限，两者都不保留改动前后的值。
引擎漏掉的那一层：每次修改都是变更请求
Busabase 就是现成的这一层。它底层跑在 Postgres 上，但智能体不是盲目地往里写行。每次修改——一条记录、一篇文档、一个技能文件、一次表结构调整——都是一个变更请求：一条带不可篡改提交、说明和逐字段差异的分支。合并只是把记录往前推，不覆盖任何内容。
在裸数据库上要做到同样的事，就得自己设计并维护审计表、触发器、带晋升步骤的暂存表，以及一个审核界面。
- 每次写入都有说明和差异。每个改动写明做了什么，并逐字段展示改动前后。
- 知道是哪个智能体改的。作者，以及改动经由哪把密钥、哪个工具提交，都记在提交上。
- 自带撤销。记录、文档、技能都保留完整历史；合并不会覆盖旧值，任何改动都能回滚。
- 要不要审，由你决定。有写权限的写入立即合并。给某个智能体一把「只能提议」的密钥，或提交时带上
autoMerge: false，改动就会进收件箱，等人批准或退回。查看变更请求文档。
在 Postgres 上自己搭，还是用 Busabase
每一行都是团队管理智能体所写业务数据时必须覆盖的工作。最后一行是 Postgres 的主场，那里的正确答案就是 Postgres。
| 你需要的 | Busabase | 在 Postgres 上自己搭 |
|---|---|---|
| 看到每次改动的前后，以及是哪个智能体改的 | 自带：每个提交都有逐字段差异、作者、所用密钥或工具 | 自己设计审计表和触发器；不专门保留，旧值就没了 |
| 让某个智能体的改动先等人审 | 可以：「只能提议」的密钥把改动送进收件箱 | 暂存表、晋升步骤、审核界面 |
| 只撤回某一次错误改动 | 可以：任何变更请求都能回滚 | 时间点恢复会回滚整个库，或者手写修复 |
| 让同事查看并修正智能体写的内容 | 可以：表格、画廊、看板、日历、甘特图视图 | 自己做管理后台或内部工具 |
| 把文档、文件和技能放在记录旁边 | 可以：同一棵目录树，同一套权限 | 另找存储，另搭知识库 |
| 在这些内容里精确搜索文字 | 可以：一次 grep 覆盖文件、文档正文、记录和提示词 | 对自己的表写 SQL 和全文检索 |
| 把数据做成应用或网站 | 可以：AirApp，包括绑定自己域名的网站 | 前端和托管自己找 |
| 接入 Claude Code、Codex 等智能体 | 可以：MCP、命令行、OpenAPI、Webhook 和插件 | 自己写工具或 MCP 服务器，并做好安全 |
| 你自己应用的事务状态、向量召回、高频写入 | 不是它的活：用 Postgres（加 pgvector） | 可以：这正是 Postgres 的用途 |
Busabase 还给智能体和团队带来什么
看得懂的可视化数据表
团队知识库
一次 grep 搜遍所有内容
全团队共用的技能
长在实时数据上的 AirApp
绑定自己域名的网站
几分钟接入智能体
开源，哪里都能跑
价格固定、可预期
接下来
以下功能正在开发，目前还不能用。上线之前，本页都会这样标注。
应用用户开发中
业务本体（Ontology）开发中
细粒度权限开发中
两者一起用
这不是二选一。应用状态放 Postgres，召回用 pgvector，缓存用 Redis，遥测放分析库。智能体为团队产出的事实——调研、客户记录、内容、运营文档——放进 Busabase，人看得懂，每次改动都可追溯。如果你在具体比较托管 Postgres，见Busabase 与 Supabase 对比。
说明一下：Busabase 自己就跑在 Postgres 上——本地用 PGlite，Cloud 用标准 Postgres。在引擎问题上我们不中立，但我们的选择很无聊，这正是本节想说的。
常见问题
Postgres 对 AI Agent 够用吗？
我需要向量数据库吗？
提示词和回复存哪里？
智能体写的业务数据该放哪？
Busabase 用什么数据库？
一个数据库能包办这一切吗？
下一步
如果引擎问题已经定了，卡住你的是「智能体到底改了什么」，那就接入一个智能体到 Busabase，看看它留下的第一个变更请求。
相关阅读： AI Agent 的记录系统 · Busabase 对比 · Busabase 与 Supabase · 变更请求 · 什么是智能体工作区
资料来源： pgvector README