智能体配置数据库，向量库还是关系库

智能体配置数据库向量库还是关系库，这问题被问到的频率比想象中高，问的人多半代码已经写了一部分，卡在选型那一页。先把话放在这：向量库不是关系库的升级版，两者管的根本不是同一件事。你要是抱着上个向量库就高级了的心态去搭，后面大概率还得绕回来补关系库，白折腾一轮。

智能体配置数据库向量库还是关系库，本质是两种提问方式

关系库擅长回答是哪一条。用户 id 是某个值的那个人，订单号对应的那笔单子，权限表里 role 等于 admin 的那几行——精确、可事务、可回滚，这是它的看家本领。向量库擅长回答最像哪个。用户这句话跟知识库里哪段文字意思接近，这个商品跟哪几个历史商品属于同一类东西。它不保证唯一答案，只给一个相似度排序，排第一的那条也可能是错的。智能体的记忆、知识检索、工具调用参数，基本都落在这两类问题里。所以别纠结选哪个，先问清楚这个功能要的是哪一种回答。

那些必须留在关系库里的东西

账户、余额、订单状态、权限、审计日志，这些东西塞进向量库早晚出事。向量库大多不提供完整的事务语义，写入没成功、索引还没建完就查询，读到的可能是旧数据。金额和状态这类字段经常要按范围筛、按条件聚合，向量检索干不了这活，硬做就是全表扫一遍再自己过滤，慢到让人怀疑人生。见过有人想用相似度去找消费超过某个数的用户，这思路从根上就偏了。

一个客服智能体的查询路径，拆开看就很清楚

用户发来一句我的快递到哪了。智能体先做意图识别和参数抽取，这步可能用模型，也可能用规则；抽出来的订单号要去关系库精确查，查到状态和物流节点；如果用户接着问你们的退货政策是什么，这才轮到向量库——把问题转成 embedding，去政策文档的向量里找最接近的几段，拼进上下文。一条完整的对话里两种库各干一段活，谁也没法替代谁。这条路径想清楚，选型那场争论基本就结束了。

关系库加个向量扩展，多数项目够用

数据量没到那个份上，最省事的做法是在原来的关系库里开一个向量字段。PostgreSQL 有 pgvector 这个扩展，MySQL 也有相应的向量支持方案，具体版本和语法以官方文档为准。百万级以内的向量、并发不高的场景，跑起来问题不大。好处是省掉一整套系统：备份还是一个备份，事务还是同一个事务，删用户的时候顺手把它的向量一起删掉，不用两边对账。短板也明显，向量索引和业务查询抢同一份内存，数据涨起来之后调优空间有限，到了某个点就得承认：该换了。

什么时候真该单独上一个向量库

几个信号比较明确。向量条数上去了，几百万往上还要毫秒级返回，关系库里的近似索引就开始吃力。过滤条件复杂，要在相似度检索的同时带上租户、时间、标签这些条件，专门的向量库对混合查询支持更成熟。并发一高，检索请求和业务写入互相干扰，也说明是时候拆了。这时候单独部署 Milvus 或者 Qdrant 这类就合理。但别一上来就上集群，单机版先跑，业务量没到那个量级，集群的运维成本纯属白搭。

向量和主键的映射，这步最容易漏

单独上向量库之后，第一个要解决的问题是这条向量对应关系库里的哪条记录。常见做法是关系库存主键，向量库里把主键当 payload 或者 metadata 一起存，检索回来拿 id 回关系库取详情。真正麻烦的是同步：记录改了、删了，向量库那边得跟着动，否则智能体会检索到一条已经不存在的资料，答出来的内容跟问题完全不搭边。删除尤其容易漏，不少人只做了写入同步。这块要么在业务代码里双写，要么挂个队列异步同步，指望它自动同步是不现实的。

会话记忆别一股脑做成向量

有些团队上来就把对话历史全转成向量存起来，觉得这样智能体就有记忆了。短期上下文用不着向量，一次会话里的几十条消息，按顺序取出来拼进 prompt 就行，存关系库或者缓存都行，简单可靠。真正需要向量的是跨会话的长期记忆和知识库，而且长期记忆还得考虑过期、去重、用户隔离这些事，做起来比想象中琐碎。把这两层混在一起，后面调试会非常痛苦，日志里全是相似度分数，根本看不出问题出在哪。

备份、迁移、数据一致性，选型时就得问清楚

向量库的备份跟关系库不是一回事。索引文件往往不小，重建一次耗时也不短，换机器的时候光把 embedding 重新灌一遍就够受的。所以选型的时候顺手问三句：支不支持增量备份，能不能在线扩容，索引重建要不要停服务。还有一个坑是 embedding 模型换了，向量维度跟着变，老数据基本没法直接比，得整批重算。这个成本在项目初期就要留出余量，别等上线半年才发现要重跑一遍。

我的判断口径很朴素：要精确、要事务、要按条件聚合的，一律留在关系库；找相似、做召回、当记忆用的，放向量库；量小就在关系库上加扩展，量大了再拆出来。拆的时候先把主键映射和删除同步这两件事想明白，剩下的都是调优的活，慢慢磨就行。别被向量数据库这四个字唬住，它解决的是检索方式的问题，不是数据管理的问题。