别再把 RAG 当成 AI 的“长期记忆”了,这逻辑根本不对
很多开发者在做 AI Agent 时,习惯把之前的对话记录存进向量数据库,下次对话再检索出来塞进 Prompt,然后就自豪地宣称自己实现了“长效记忆”。但我实测下来发现,这种做法更像是你在公寓里到处贴便利贴,然后自欺欺人地认为这房子长了脑子。
这样做的目的是为了避免“上下文污染”。如果你把整个公司的历史都塞进 Prompt,那不叫记忆,那叫昂贵的噪音。
下一篇
AI 生成的内容真的能像生物一样自我演化吗 →
现在的模型确实博学,它懂 Rust,懂 Kubernetes,甚至能一眼看出你的架构设计有多烂。但它对你“上周二”干了什么一无所知。它不知道你已经尝试过那个显而易见的方案但失败了,也不知道某个看起来很丑的接口是因为三个旧仓库还在依赖它,更不知道某个看似随意的约定其实是团队开了一小时会吵出来的结果。
这些信息不是通用的知识,而是“工作的状态(State generated by work)”。RAG 检索的是既有的文档、代码或票据,而真正的记忆应该是记录“决策过程”的:为什么选 A 而不是 B?为什么 C 方案行不通?哪些假设是临时的?这些东西往往根本没写进文档里,导致 AI 每次新开 Session 都要重新踩一遍坑,这简直是在浪费 Token。
我最近在折腾一个思路:把记忆从模型中剥离出来,做一个独立的、外部的共享记忆层。
核心实操思路:基于 MCP 的外部记忆中枢
我现在的原型非常“无聊”,但逻辑很清晰。我没有试图改变模型,而是构建了一个独立的 HTTP Memory Hub。
- 存储媒介: 记忆不是数据库里的二进制块,而是带有结构化元数据的 Markdown 文件。
- 解耦架构: 模型、客户端、MCP Server 都不是存储主体,记忆是独立存在的。
- 按需调用: AI Session 开始时只拿到一个极小的索引(Index),只有当 Agent 意识到需要了解历史背景时,才会通过 MCP 工具主动去“拉取”相关的记忆。
这样做的目的是为了避免“上下文污染”。如果你把整个公司的历史都塞进 Prompt,那不叫记忆,那叫昂贵的噪音。
如果你也想尝试这种架构,可以参考下面这个简单的 MCP Tool 定义逻辑,让 Agent 学会主动“记笔记”和“查旧账”:
{
"name": "manage_project_memory",
"description": "用于存储决策过程、失败尝试和项目特有的约定,而非存储文档。",
"parameters": {
"type": "object",
"properties": {
"action": {
"type": "string",
"enum": ["push", "pull", "list"],
"description": "push: 记录新发现/决策; pull: 获取相关背景; list: 查看现有记忆索引"
},
"content": {
"type": "string",
"description": "记忆的具体内容,建议包含 'Context', 'Decision', 'Reasoning' 等维度"
},
"tags": {
"type": "array",
"items": { "type": "string" },
"description": "用于快速检索的标签,如 #failed_attempt, #architecture_decision"
}
},
"required": ["action"]
}
}这种做法的核心在于,我们要让 AI 意识到“过去存在”,但不要强迫它每次都背着沉重的历史包袱。只有在需要的时候,它才会去翻那本属于你们团队的“避坑指南”。
免费 AI 工具箱 · 全部完全免费
各类AI落地变现的详细拆解见AI赚钱方法实操指南,有不少直接可参考的案例。