Agent 记忆用向量库还是文件？4 步选型不踩坑

给 Agent 加长期记忆，纠结的通常不是「要不要加」，而是「存在哪」。这个决定一旦定错，后面每次迭代都在为检索不准和运维麻烦还债。

一、先看清本质：联想检索 vs 精确读取

向量库解决的是「我说不清要找什么，但意思差不多就行」——模糊召回。

文件系统解决的是「我知道它在哪，别给我近似答案」——确定性读取。

这两件事不冲突，但很多人把它们塞进同一个组件里，于是两头都不讨好。

二、4 个判断维度

1. 记忆条数与写入频率

几百条以内、每天新增几条，纯 Markdown 文件完全够用，直接全量注入上下文。

上万条、每轮会话写十几条，就得靠向量库做筛选，否则上下文预算会被记忆撑爆。一个粗略的切分点是：当「全量注入」会占掉你单轮可用 token 的三成以上，就该上检索了。

2. 查询是联想型还是定位型

• 「上次用户抱怨过什么」——联想型，走向量。

• 「用户当前套餐名是什么」——定位型，走文件或结构化字段。

把定位型查询交给向量检索是自找麻烦：它永远给你「最像」的答案，而不是「对」的答案。用户余额、订单号、配置项这类必须精确的数据，别放进向量库。

3. 可调试性

Markdown 文件能直接打开、能 git diff、能回滚、能手工改一行。

向量库里一条漂移的 embedding，你只能盯着相似度分数发呆。记忆系统出问题时，可观测性比召回率高几个百分点重要得多。

4. 成本与延迟

向量检索多两次调用：一次 query embedding，一次 ANN 查询。单次不贵，但 Agent 一轮任务可能检索十几次，延迟会累加。

如果你的记忆总量小、查询以定位为主，为它引入一套向量基础设施，收益远小于运维成本。

三、多数团队该走的路：文件为主，向量为辅

具体做法可以照抄：

1. 事实类记忆（身份、偏好、配置）写进结构化文件，如 profile.json 或 memory.md，每轮直接注入，不检索。

1. 经验类记忆（踩过的坑、对话摘录、决策记录）按月份分文件，再建一个向量索引，索引里只存「文件路径 + 片段 ID」，不存原文。

1. 检索时先精确后模糊：先按关键词 / grep 命中，未命中再走向量召回，两条路径返回统一格式，让上层无感。

1. 让 Agent 通过工具读写文件，而不是让它直接操作向量库。现在主流的 Agent 框架都支持文件系统 + MCP 类工具调用，Agent 自己维护记忆文件这件事已经很容易实现。

四、4 步落地清单

1. 先跑两周纯文件版，记录每一次「Agent 想不起来」的具体提问，这是你最真实的评测集。

1. 只把失败率最高的那一类记忆挪进向量索引，不要全量迁移。通常只有「跨会话的模糊回忆」需要它。

1. 给记忆加 TTL 和压缩：超过 30 天未被召回的条目，自动归档成一句摘要，原文进冷存储。

1. 建 20~30 条评测用例，每次调整检索策略都跑一遍，看命中率和误召回率，而不是凭感觉。

五、两个最容易踩的坑

坑一：把向量库当数据库用。 存订单、余额、权限这类必须精确的数据，一次误召回就是一次线上事故。

坑二：记忆只写不删。 半年后 Agent 每轮注入几千 token 的历史垃圾，既拖慢响应又污染判断。记忆系统必须自带清理机制，否则它迟早变成负债。

结语

记忆方案不是一道选型题，而是一道分层题：精确的归文件，模糊的归向量，能删的别留。先让文件版跑通、跑出真实失败样本，再让向量去补那部分确实补不上的漏，比一上来就搭向量库稳得多。