把 RAG 当作 AI 的长期记忆，恰恰混淆了知识与工作状态

开发 AI Agent 时，很多开发者会习惯性地把之前的对话记录存入向量数据库，下次对话再检索出来塞进 Prompt，然后宣称自己实现了“长效记忆”。但这种做法更像是把便利贴贴满公寓，再误以为房子本身长出了大脑。

现在的模型确实博学，它懂 Rust，懂 Kubernetes，甚至能一眼看出你的架构设计有多烂。但它对你“上周二”干了什么一无所知。它不知道你已经尝试过那个显而易见的方案但失败了，也不知道某个看起来很丑的接口是因为三个旧仓库还在依赖它，更不知道某个看似随意的约定，其实是团队开了一小时会吵出来的结果。

这些信息并不是通用知识，而是“工作的状态（State generated by work）”。RAG 检索的是既有的文档、代码或票据，真正的记忆则应该记录“决策过程”：为什么选 A 而不是 B？为什么 C 方案行不通？哪些假设是临时的？

这些东西往往根本没有写进文档，导致 AI 每次新开 Session 都要重新踩一遍坑，白白浪费 Token。把历史对话存进向量数据库再塞回 Prompt，看起来是在延续上下文，实际上只是把过去的片段重新摆在桌面上，并不等于模型理解了这些信息为何出现。

一种更清晰的做法，是不再改变模型本身，而是把记忆从模型中剥离出来，构建一个独立的、外部的共享记忆层。这个原型可以很“无聊”，但边界非常明确：一个独立的 HTTP Memory Hub 负责承载记忆，模型只负责理解、判断和调用。

这个方案有三个关键点：

• 存储媒介： 记忆不是数据库里的二进制块，而是带有结构化元数据的 Markdown 文件。
• 解耦架构： 模型、客户端、MCP Server 都不是存储主体，记忆独立存在。
• 按需调用： AI Session 开始时只拿到一个极小的 Index，只有当 Agent 意识到需要了解历史背景时，才会通过 MCP 工具主动“拉取”相关记忆。

这样做的目的，是避免“上下文污染”。如果把整个公司的历史都塞进 Prompt，那不叫记忆，只是一份昂贵的噪音。模型不需要背着完整历史完成每次任务，也不该在毫无必要时接触所有项目细节。

让 Agent 学会主动“记笔记”和“查旧账”，关键不在于增加多少记忆，而在于让它知道过去存在，并在真正需要时再获取对应的决策背景。下面的 MCP Tool 定义逻辑，可以用来区分记录新发现、获取相关背景和查看现有记忆索引：

{
  "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"]
  }
}

这里保存的不是大段历史，而是新发现、决策、失败尝试和项目特有的约定。Agent 需要背景时主动拉取，不相关时就不让记忆进入当前上下文。这样，AI 才能在需要时翻阅属于团队的“避坑指南”，而不是每次都拖着沉重的历史包袱行动。