Agentic AI 应用到底该用什么数据库？
一个 Agentic 应用里有五类数据，每一类想要的家都不一样。一篇实操选型：状态、会话、召回、遥测，以及大多数指南跳过的那一类——Agent 产出的事实。
问「Agentic AI 应用该用什么数据库」，多数答案会直接甩你一个产品名。这个回答的形状就错了：一个 Agentic 应用里装的不是一类数据，是五类，它们同一天到达，每一类想要的家都不一样。按「类」选，不按「产品」选，这个决策大半会自动完成。
先给结论。 应用自身的状态进 Postgres。热的会话上下文进 Redis——而且比你想的晚。语义召回先用同一个 Postgres 里的 pgvector，等你能测出理由，再毕业到专用向量库。日志与 token 账目进分析型存储，从第一天就分开。而 Agent 产出的业务事实——几乎每篇选型指南都忘了列的那一类——应该住进一个记录层：能显示每条事实是谁写的、人到底接受过没有。
一个具体的应用
空谈便宜，拿一个具体的应用说：一个处理支持工单的 Agent。它读每张新工单、分类、检索历史解决方案、起草回复给人批准、再把处理结论更新到客户记录上。普通、能落地，已经足够生出全部五类数据：
- 应用状态——用户、工单、客户、权限。小、事务性、必须精确。
- 会话与热上下文——Agent 正在处理中的东西：当前对话、工具结果、限流计数。易逝、高频变动、对延迟敏感。
- 语义召回——上万张已解决工单加帮助中心，做成向量，让它能找「和这张类似的」。
- 遥测——每一次提示词、回复、工具调用和 token 计数，留着调试和算成本。只追加、无限增长。
- 产出的事实——每张工单的分类、起草的解决方案、被更新的客户记录。其他人和之后的 Agent 运行会把这些当真来读。
前四类都有成熟答案。第五类是 Agentic 应用悄悄翻车的地方——先记住这句。
每一类住哪
| 数据类 | 住所 | 理由 |
|---|---|---|
| 应用状态 | Postgres | 事务、约束、关联查询。这是已解决的问题，不要在这里创新。 |
| 会话与热上下文 | 先 Postgres，延迟被证实后再 Redis | 多数 Agent 应用还没快到会话读取成为瓶颈。Redis 是给每请求计数和去重窗口的，不是默认项。 |
| 语义召回 | 同一个 Postgres 里的 pgvector | 只运维一套系统，向量和它描述的行住在一起。专用向量库的位置在几千万向量或可测量的延迟目标之后——不在那之前。 |
| 遥测 | 分析型存储（ClickHouse、DuckDB 一类），或一个独立的 Postgres | 只追加、无上限。挨着状态表放，几个月内就会变成清理与分区的苦役。早期分开很便宜，事后改造很贵。 |
| 产出的事实 | 记录层 | 这些会被人和后续运行当真来读。它们需要出处（哪个 Agent、来自什么输入）和审核状态（已提议 vs 已接受）——通用引擎不建模这两样东西。 |
引擎的阈值、基准和更完整的「Postgres 优先」论证，在我们的参考页《你的 AI Agent 该用哪个数据库》里。本文谈的是决策，不是调优。
决策顺序
按这个顺序问，每个答案都会收窄下一个。
- 我的应用本身存什么？ 用户、订单、工单、内容。这是 Postgres，没有悬念——托管还是自建是预算问题，不是架构问题。
- Agent 需要召回什么？ 文档和历史案例，按相似度找。先用 pgvector。把向量数量和你实测的延迟写下来；这张纸条就是你将来上专用向量库的触发条件，在那之前不用。
- 什么东西是热的、可丢的？ 进行中的会话、计数器、锁。丢了不心疼的，可以住 Redis——或者先住 Postgres，等你证明它确实慢。
- 日志去哪？ 去别的地方。第一天就定，那时它只是一行配置。
- Agent 会写下什么、会被别人当真？ 这个问题决定你的栈需不需要记录层，而多数团队是在第一次事故之后才问它。
团队最常犯的三个错
从向量数据库开始。 演示效果极佳——什么都向量化，什么都能问。六个月后，团队有了一套召回系统，却没有可靠的东西可召回：事实仍散落在工单、文档和聊天里。召回是第三类问题，它很少是第一个问题。
把聊天记录当记忆。 Agent 的历史攒在对话日志里，下一次运行重读原始转录，希望能拼出当时到底定了什么。转录是遥测（第四类）。决策应该住进记录里，以一种下一次运行——和下一个人——真能用的形状。
让 Agent 直写生产数据库。 写入格式良好、权限齐全，其中一些就是错的——错得貌似可信、理直气壮。数据库没法告诉你哪些行被人看过。当某个客户基于其中一行采取了行动，你才发现「Agent 写的」和「我们为此负责」在你的系统里从来不是同一句话。这正是第五类数据存在要防的失败。
记录层的位置
注意，第五类需要的不是一个更大或更聪明的数据库，是另一份工作：把业务事实保存在类型化记录里，把解释它们的文档、Agent 遵循的规则放在同一个工作区，并让写入在分量重时以提案形式到达——一个带 diff 的变更请求，人可以接受或驳回——分量轻时才直接落地。Busabase 占的就是这一层：它本身跑在 Postgres 上（本地是 PGlite，云端是标准 Postgres），Agent 通过 MCP、Agent Skill、API 或 CLI 接入。它不替代前四类；它是那四类从来不是为之设计的一类数据的家。
所以：状态用 Postgres；向量先用 pgvector，直到测量说话；Redis 等延迟被证实、而不是被担心时再上；遥测从一开始就独立存储——而 Agent 产出的事实，住进记录层，因为你的业务最终是按那一类被评判的。
常见问题
做 Agentic 应用必须要有向量数据库吗？ 你需要的是向量检索（为了召回）；一开始很少需要一个独立的向量数据库。现有 Postgres 里的 pgvector 足以覆盖大多数应用远超上线阶段。等规模或延迟的实测说话时再毕业，不要等某篇发布稿说话。
一个 Postgres 实例能包办一切吗？ 第一、二、三类，很长时间内都舒服。第四类迟早会让它疼。第五类根本不是容量问题——是缺了一个概念（出处与审核状态），再怎么调优也调不出一个概念。
第二个 Agent 加入时，什么会变？ 每一类共享数据多了一个写作者。状态和召回扛得住。产出的事实是咬人的地方：两个 Agent 写同一条客户记录，彼此看不见对方提议过什么、人已经接受过什么。多 Agent 系统不是倒在引擎上的，是倒在未经审核、没有出处的事实上的——所以决策顺序里第五个问题，会随着你每加一个 Agent 而变得更重要。