向量数据库在Agent记忆中的适用边界
定义
向量数据库在Agent记忆中的适用边界，是指：在 Agent 的 Memory 设计里，向量检索不是默认基础设施，更不是“只要有记忆就该上”的通用答案。它只适合那类非结构化、数量持续增长、查询目标依赖模糊语义相似性的记忆。
反过来说，凡是要求精确读取、字段级命中、旧值可被新值覆盖的信息，都不应把向量数据库当作主要记忆载体。
在本文档中的语境
本文语境讨论的是 ChatGPT、Anthropic 一类 Agent 系统的“记忆机制应该怎么设计”，核心结论不是“向量数据库没用”，而是不要把所有 Memory 混成一种东西，然后无脑用向量库统一处理。
原文明确指出，很多项目的问题不在于向量数据库本身，而在于把 Memory 误当成单一模块。真实工程里，Memory 更接近一套分层系统，不同类型的信息应采用不同的存储与读取方式，这与 Agent记忆分层架构、即时检索记忆策略 的思路一致。
为什么向量数据库不适合作为默认记忆方案
1. 向量检索是模糊匹配，但很多记忆要求精确调用
原文给出的第一个反例非常直接：
- 用户上周说预算是 5 万。
- 之后还讨论过 3 万的备选方案。
- 用户还随口提过“考虑过 10 万的升级”。
- 当用户再问“我的预算是多少”时，系统如果依赖向量检索，就会召回一堆都带“预算”语义的片段。
问题在于，这些片段在语义上都相近，模型只能在“看起来都说得过去”的候选内容里猜一个答案。即使其中包含正确值，也不能保证正确值排在最前面。
这正是向量检索的天然特性：它做的是相似性召回，而不是字段精确命中。对于“我的预算是多少”“我的名字是什么”“我的偏好是什么”这一类关键事实查询，系统需要的是唯一、明确、可验证的答案，而不是若干近似候选。
因此，原文的结论很明确：
关键事实类的信息，不应依赖模糊匹配，而应通过字段级精准命中读取。
也就是说，这类信息更适合存成结构化字段，例如 user.budget、user.name、user.preference 之类的稳定档案，而不是混在大量自然语言片段里再靠相似度去“猜”。
2. 需要更新和覆盖的信息，不适合追加写入式存储
原文的第二个反例讨论的是更新问题：
- 上周用户预算是 5 万。
- 今天用户改主意，把预算更新为 8 万。
如果使用向量数据库，常见做法是继续追加一条新记忆。这样一来，库里会同时存在“预算 5 万”和“预算 8 万”两条内容。
当系统再次检索“预算”相关信息时，旧值和新值都可能被召回。模型此时不仅要理解语义，还要自行推断时间顺序、有效性和覆盖关系，最终判断“到底该信哪条”。这一点并不是向量数据库擅长解决的问题。
相反，若使用结构化记忆，更新过程就是直接覆盖：
- 旧值：
user.budget = 50000 - 新值写入后：
user.budget = 80000
系统里始终只有一个当前有效答案，不会在检索阶段让模型面对冲突事实。
因此，原文给出的判断同样非常明确：
需要更新和覆盖的信息，不适合追加写入式存储，而更适合结构化字段直接覆盖。
这里的关键不只是“能不能存”，而是“更新后的读取语义是否单值且稳定”。向量库天然偏向追加、累积、并存；而很多 Agent 记忆恰恰要求覆盖、替换、唯一生效。
原文所依据的Memory分层视角
原文进一步强调，理解向量数据库的边界，前提是先承认 Memory 不是单一模块，而是分层系统。文中至少区分了四类记忆：
1. 当前对话上下文
这类信息直接保留在滑动窗口中，只处理最近 N 条消息，超过 token 限制就丢弃更早内容。这一层本质上不需要长期存储，也不需要向量检索。
2. 用户长期事实
包括名字、职业、偏好、长期目标等稳定信息。原文认为这类内容应该使用结构化档案式存储，支持随时覆盖、精准读取，而不是切块后做 embedding 再召回。
3. 近期对话摘要
最近十几次对话的标题和关键信息，可整理为轻量级摘要列表。这里强调的是“摘要”和“脉络保持”，不是保留全部原文，也不是对完整历史做相似度检索。
4. 历史经验和案例
过去成功的解决方案、失败的尝试、历史工单、经验案例等，才是原文认定真正适合向量检索的一类记忆。因为它们通常：
- 内容是非结构化自然语言；
- 数量会持续增长；
- 查询目标不是某个唯一字段，而是“找相似情况”。
这也是本文标题里“适用边界”的核心：向量数据库只适合其中一部分记忆，而不是全部记忆。
正向边界：什么情况下向量数据库是对的
原文没有否定向量数据库，而是给出了明确的正面判断标准：
当记忆内容是非结构化的、数量是开放增长的、查询是模糊语义的——这时候向量检索才是对的。
这个判断标准包含三个条件，缺一不可：
非结构化
如果数据本来就能拆成稳定字段，例如预算、姓名、职业、城市、会员等级、当前目标，那么优先方案应是结构化存储。只有当内容主要以自然语言段落、案例描述、故障经过、解决过程存在时，向量化才更合理。
数量开放增长
如果记忆规模很小，或者本质上是有限字段集合，用结构化方式维护通常更简单、更快、更可控。向量检索的价值，更多体现在数据量大、历史长、人工难以穷举规则筛选的情况下。
查询是模糊语义
如果查询目标是“精确取出唯一事实”，那不该依赖相似度；但如果查询目标是“找和当前问题类似的案例”“检索曾经怎么处理过类似投诉”“找出过去相近场景下的解决方案”，那么语义相似检索就能真正发挥优势。
原文给出的正面示例
原文明确给出一个适用场景：
- 做一个客服 Agent；
- 系统里积累了几万条历史工单；
- 目标是从这些工单中找相似案例、相似处理方式或相近经验。