Agent 记忆系统设计：为什么 OpenAI 和 Anthropic 都不用向量数据库 - 今日头条.md8.7 KBit/ai/Agent 记忆系统设计：为什么 OpenAI 和 Anthropic 都不用向量数据库 - 今日头条.md
--- title: "Agent 记忆系统设计：为什么 OpenAI 和 Anthropic 都不用向量数据库 - 今日头条" source_url: "https://www.toutiao.com/article/7644945128331592235/?wid=1782275203071" source_site: "www.toutiao.com" clipped_at: "2026-06-24T04:26:59.434058+00:00" clipper: "aiwiki-url-ingest" extractor: "toutiao_rendered" --- # Agent 记忆系统设计：为什么 OpenAI 和 Anthropic 都不用向量数据库 - 今日头条 前段时间帮一个朋友看他做的客服 Agent，他第一句就跟我说："学长，我接了个向量数据库，把历史对话全 embedding 进去了，但用户问'我之前的预算是多少'，模型经常答错。" 我让他打开后台看了一眼。果然，向量召回回来的是一堆带"预算"字样的对话片段——上周说的 5 万、前天讨论的 3 万备选方案、还有用户随口提的"考虑过 10 万的升级"——**全都在库里，模型挑哪条都说得过去**，但用户真正要的那个最新答案，根本没排在最前面。 这不是他一个人的问题。我最近看了不少同学的 Agent 项目，**九成都犯同一个错：把 Memory 当成一个东西，无脑上向量数据库。** 今天我把这事讲透。这篇看完，你下次面试被问到"Agent 的记忆机制怎么设计"，能直接把面试官讲服。 # 先说一个可能颠覆你认知的事实： **ChatGPT 的记忆系统，根本没用向量数据库。** 没有 RAG，没有 Embedding 召回，连相似度匹配都没有。 这不是我瞎说。过去一年，国外好几个开发者通过对话实验，把 ChatGPT 的记忆机制逆向出来了，结论高度一致：ChatGPT 的记忆系统不是复杂的、向量数据库驱动的架构，没有 RAG 对完整对话历史做检索。 整个系统就四层纯结构化设计： **第一层：滑动窗口**——当前对话的最近 N 条消息，超 token 就丢最早的。这层根本不需要"存"，就在窗口里。 **第二层：近期对话摘要**——最近十几次聊天的标题和关键信息，整理成一份轻量级清单，不存原文，也不做检索。 **第三层：用户记忆（结构化档案）**——名字、职业、偏好、长期目标这些稳定事实，每次对话都会出现，确保 ChatGPT 始终知道你的偏好。 **第四层：元数据**——设备类型、时区、使用习惯，临时信息，不存入长期记忆。 就这么简单。没有向量数据库，没有 RAG，纯靠分层和策略。 # 你可能会问：向量检索那么强大，为什么不用？ 两个核心原因。 **第一，向量检索是模糊匹配，但很多记忆需要精确调用。** 举个例子。用户上周告诉你预算是 5 万，今天用户问你"我的预算是多少"。 如果你用向量检索，召回的可能是一堆预算相关的内容——讨论过的各种金额、各种场景，模型要从一堆相似度差不多的片段里挑出"5 万"这个答案。挑错的概率不小。 但如果你用结构化存储，直接查`user.budget`这个字段，精准命中，返回 8 万，没有歧义。 **关键事实类的信息，不该用模糊匹配来找。** **第二，向量数据库的时间处理很别扭，更新和覆盖困难。** 继续上面的例子。用户改主意了：上周预算 5 万，今天说预算改成 8 万了。 向量数据库里两条都存着，检索的时候可能两条都召回，模型不知道该信哪一个。但如果你的 Memory 是结构化的，**新值直接覆盖旧值，永远只有一个答案**。 需要更新和覆盖的信息，不该用追加写入的方式存。 # 讲到这里，应该能感觉到—— 问题不在向量数据库本身，而在于你把 Memory 当成了一个单一模块。 真实情况是：Memory 是一套分层系统，不同类型的记忆用不同的存储和读取策略。 至少有四种类型： **第一种：当前对话的上下文。**这根本不需要"存"，就在滑动窗口里。 **第二种：用户的长期事实。**名字、职业、偏好、目标——结构化档案卡式存储，随时覆盖，精准读取。 **第三种：近期对话的摘要。**最近聊什么话题、什么方向，用轻量级的摘要列表，不需要存原文。 **第四种：历史经验和案例。**过去成功的解决方案、失败的尝试——**只有这一种，才真正适合向量检索。** 向量数据库只是工具箱里的一把锤子，不是唯一的锤子，更不是万能的锤子。 可能有同学会说："这只是 OpenAI 的做法，Anthropic 那边呢？" 我专门去翻了 Anthropic 的官方工程博客，结论让我自己也有点意外—— **Anthropic 的思路和 OpenAI 高度一致，甚至走得更彻底。** Anthropic 在 2025 年 9 月发的《Effective Context Engineering for AI Agents》里，明确提出了一个概念叫**"just\-in\-time" 检索**。Agent 不预处理所有相关数据，而是维护轻量级标识符（文件路径、存储的查询、网页链接等），用工具在运行时动态加载数据到上下文中。 他们的原话很有意思：这个方法模仿了人类认知——我们一般不记忆整个语料库，而是引入外部组织和索引系统，比如文件系统、收件箱、书签。 更直接的证据是 Claude Code。你猜 Claude Code 怎么管理跨会话记忆？ **不是向量数据库，是 Markdown 文件。** Claude Code 把文件系统当作记忆，用 Markdown 文件和一组专门的子 Agent 来维护上下文。整个三层架构，没有向量数据库，没有 RAG。 2026 年 4 月，Anthropic 又发了一个叫**Memory for Managed Agents**的功能，让 Agent 跨会话学习。怎么存？还是文件。Memory 直接挂载到文件系统上，Claude 可以用它已经擅长的 bash 和代码执行能力来操作。 效果怎么样？Anthropic 官方公布的客户数据是这样的： Rakuten 在 Agent 工作负载上错误率降低了 97%，成本降低了 27%，延迟降低了 34%。 **没用向量数据库，效果比堆 RAG 还好。** # 讲到这里你可能觉得我在黑向量数据库。其实不是。 向量数据库不是不能用，**而是要用对地方** 判断标准就一句话： **当你的 Memory 内容是非结构化的、数量是开放增长的、查询是模糊语义的——这时候向量检索是对的。** 比如：你在做一个客服 Agent，需要从几万条历史工单里找相似案例，这时候向量检索就是对的。 但如果你只是想让 Agent 记住用户的基本信息和对话脉络，**结构化存储 \+ 摘要机制就够了**。而且更快、更准、更可控。 工程设计的本质是选对工具，而不是证明你会用复杂工具。 如果你下次面试被问到"Agent 的记忆机制怎么设计"，别急着说向量数据库。 **先反问一句：你们的 Memory 需要存什么类型的信息？** 这一句话出来，你就已经赢了一半。 因为这个问题问出来，说明你知道 Memory 不是一种东西、不是一个单一模块，而是一套分层系统。说明你不是上来就背方案，是先理解问题。 记住一句话—— **不是背方案，是理解每种方案解决什么问题。** 这才是工程师和"调包工程师"的区别。