精读: MCP 记忆集成层

开源记忆项目精读见 supermemory · DB-Agent-Memory 生产 Agent 记忆见 Claude Code 记忆 · Codex 记忆

调研元信息

一句话定位

MCP 是生产 Coding Agent 与开源记忆库之间的 USB 口——同一个 MCP memory server 可以被 Claude Code、Codex、Cursor 等任何支持 MCP 的 Agent 调用，让记忆能力从 Agent 产品中解耦出来 [文档]。

日常类比

想象你有三台不同品牌的电脑（Claude Code / Codex / Cursor），每台都有自己的内置硬盘（内建记忆）。MCP 就像 USB 接口标准——你可以把同一个移动硬盘（supermemory / DB-Agent-Memory）插到任何一台电脑上使用。有的电脑内置硬盘很大（Claude Code 有完整的 memory 子系统），有的几乎没有内置存储（旧版 Cursor），但它们都能用同一个 USB 移动硬盘。

类比边界：USB 移动硬盘的接口是标准化的，但 MCP memory server 的能力差异远大于硬盘之间——supermemory 有三流检索，DB-Agent-Memory 有四层金字塔，接口相同但内部能力天差地别。

记忆类型标注

本文聚焦 External memory（独立记忆服务通过 MCP 暴露），兼讨论 Agent profile（Rules / CLAUDE.md / AGENTS.md）如何被社区用来模拟 User memory。

三种记忆能力的层次

在理解 MCP 集成层之前，需要先明确生产 Coding Agent 中三种记忆能力的层次关系 [文档][源码]：

flowchart TB
    subgraph profile["Agent Profile（静态配置）"]
        CM[CLAUDE.md]
        AM[AGENTS.md]
        CR[".cursor/rules/*.mdc"]
    end

    subgraph user["User Memory（自动提炼）"]
        CC_MEM["Claude Code<br/>~/.claude/projects/*/memory/"]
        CX_MEM["Codex<br/>~/.codex/memories/"]
        CU_MEM["Cursor Memories<br/>(1.0 Beta)"]
    end

    subgraph external["External Memory（MCP 服务）"]
        SM["supermemory MCP Server"]
        DB["DB-Agent-Memory MCP Adapter"]
        M0["mem0 via MCP adapter"]
    end

    subgraph bridge["MCP Protocol"]
        MCP["MCP 标准接口"]
    end

    profile -->|人工维护| AGENT[Coding Agent]
    user -->|系统写入| AGENT
    external -->|MCP 调用| MCP --> AGENT

Profile vs User vs External

关键洞察：Cursor 在 1.0 之前默认没有 User memory，只有 Profile（Rules）+ Working（session）。这促成了 Memory Bank 社区模式的兴起——用 Profile 文件来模拟 User memory [社区]。

Profile 机制对比

AGENTS.md 发现链（Codex）

Codex 的 AGENTS.md 发现链在 agents_md.rs 中实现 [源码]：

1. 确定项目根：从 cwd 向上逐级找 .git 等标记——找到即为根，不再越过
2. 确定搜索范围：从项目根到 cwd 路径上的每一级目录（含两端）
3. 每级目录按优先级查找：AGENTS.override.md → AGENTS.md → fallback 文件名（如 CLAUDE.md）
4. 拼接：用户级 instructions 排最前 → --- project-doc --- 分隔符 → 各级内容

设计亮点：AGENTS.override.md 作为本地覆盖，类似 .env.local 的思路——可以 gitignore，不影响团队配置 [源码]。

CLAUDE.md 发现链（Claude Code）

Claude Code 也支持链式发现，但路径布局更复杂 [源码]：

Cursor Rules 四种模式

Cursor 的 .cursor/rules/*.mdc 文件通过 frontmatter 控制注入策略 [文档]：

Cursor 1.0 Memories（2025-06-04） [文档]：Cursor 终于在 1.0 版本引入了原生 User memory——按项目级别、个人层面存储，由后台模型自动提取，用户批准后保存。但仍是 Beta 且限于项目粒度（不跨项目），这与 Claude Code 的跨项目 memory 和 Codex 的全局 ~/.codex/memories/ 不同。

Profile 对比总表

MCP 外部记忆: supermemory

完整架构精读见 supermemory 精读

supermemory 通过独立的 apps/mcp-server/ 应用暴露记忆能力 [已有]。

集成架构

flowchart LR
    subgraph clients["Coding Agents"]
        CC[Claude Code]
        CX[Codex]
        CU[Cursor]
    end

    subgraph mcp_layer["MCP Protocol"]
        MCP_IF["MCP 标准接口"]
    end

    subgraph supermem["supermemory"]
        MCP_SRV["MCP Server<br/>(apps/mcp-server/)"]
        WEB["Web App"]
        EXT["Browser Extension"]
        ENGINE["Memory Engine"]
        SEARCH["三流混合检索<br/>BM25+向量+图"]
        PROFILE["Profile API"]
    end

    CC --> MCP_IF --> MCP_SRV
    CX --> MCP_IF
    CU --> MCP_IF
    WEB --> ENGINE
    EXT --> ENGINE
    MCP_SRV --> ENGINE
    ENGINE --> SEARCH
    ENGINE --> PROFILE

作为外部记忆的特点 [已有]：

• 多入口统一记忆：MCP Server、Web App、Browser Extension 三个入口共享同一份记忆——浏览器捕获的网页知识也能在 Claude Code 中被检索到
• Profile API：用户可以手动 curate 画像（编辑/修正/删除），这在开源记忆库中是独特的
• Dynamic Dreaming：后台自动整理、关联、巩固记忆——与 Claude Code 的 autoDream 异曲同工
• 三流混合检索 sub-300ms：BM25 + 向量 + 图遍历

MCP 外部记忆: DB-Agent-Memory

完整架构精读见 DB-Agent-Memory 精读

DB-Agent-Memory 通过 Host-Adapter 架构将记忆与 Agent 框架解耦 [已有]。

集成架构

flowchart LR
    subgraph clients["Coding Agents"]
        CC[Claude Code]
        CX[Codex]
        CU[Cursor]
    end

    subgraph adapters["Adapter 层"]
        MCP_A["MCP Adapter"]
        OC["OpenClaw Adapter"]
        HM["Hermes Adapter"]
    end

    subgraph host["Memory Host"]
        L0["L0 对话层"]
        L1["L1 原子事实"]
        L2["L2 场景块"]
        L3["L3 用户画像"]
        MMD["MMD Builder<br/>稳定区+动态区"]
    end

    subgraph store["Storage"]
        DB[(SQLite + sqlite-vec)]
    end

    CC --> MCP_A
    CX --> MCP_A
    CU --> MCP_A
    MCP_A --> L0
    OC --> L0
    HM --> L0
    L0 --> L1 --> L2 --> L3
    L3 --> MMD
    L0 --> store
    L1 --> store
    L2 --> store
    L3 --> store

作为外部记忆的特点 [已有]：

• Host-Adapter 解耦：同一套记忆数据可同时被 MCP、OpenClaw、Hermes 三种接口访问——记忆不锁死在任何框架
• 四层语义金字塔：L0（对话）→ L1（原子事实）→ L2（场景块）→ L3（画像），逐层自动蒸馏
• MMD 注入优化：稳定区（L3+L2）排在 prompt 前部利用 KV Cache 前缀匹配，动态区（L1+L0）排在后部——这是一个 prompt 工程层面的成本优化
• 零外部依赖：SQLite + sqlite-vec，一个 .db 文件即全部数据

两个 MCP 记忆服务的对比

Memory Bank 社区模式

Memory Bank 是一种社区驱动的模式——用 Profile 文件（Cursor Rules 或项目 Markdown）模拟 User memory [社区]。

工作机制

flowchart TB
    START[新 Session 开始] --> LOAD["读取 Memory Bank 文件<br/>(通过 Rules 指令)"]
    LOAD --> CONTEXT[Agent 获得项目上下文]
    CONTEXT --> WORK[正常工作]
    WORK --> TRIGGER["用户说 'update memory bank'"]
    TRIGGER --> REVIEW[Agent 审查所有 Bank 文件]
    REVIEW --> UPDATE["更新 activeContext.md<br/>+ progress.md"]
    UPDATE --> WORK

典型文件结构

为什么存在

Memory Bank 模式的存在本身就说明了一个问题：产品内建记忆的供给不足 [社区]。

Memory Bank 的代价

用 Profile 模拟 User memory 有三个根本问题：

1. 无 embedding / 无语义检索：Memory Bank 文件全量注入上下文，随着项目增长会占用大量 token
2. 无冲突合并：多个 session 可能同时修改 activeContext.md，没有版本控制以外的冲突解决机制
3. 人工触发：需要用户手动说 “update memory bank”，遗忘就等于丢失——对比 extractMemories 的自动触发

这正是为什么 DB-Agent-Memory（腾讯）+ supermemory 的 MCP 路线更有前途——它们提供了 Memory Bank 缺少的自动提取、语义检索和冲突处理 [已有]。

MCP 作为统一集成层的价值

当前格局

flowchart TB
    subgraph agents["Coding Agents"]
        CC["Claude Code<br/>内建: memdir"]
        CX["Codex<br/>内建: Phase1/2 pipeline"]
        CU["Cursor<br/>内建: Memories Beta"]
    end

    subgraph mcp_bridge["MCP 桥接层"]
        MCP["MCP Protocol"]
    end

    subgraph external["外部记忆服务"]
        SM["supermemory<br/>三流检索"]
        DB["DB-Agent-Memory<br/>四层金字塔"]
        M0["mem0<br/>扁平事实"]
        LT["Letta<br/>虚拟内存"]
    end

    CC -->|内建记忆 + MCP 扩展| MCP
    CX -->|内建记忆 + MCP 扩展| MCP
    CU -->|Memories Beta + MCP 扩展| MCP

    MCP --> SM
    MCP --> DB
    MCP --> M0
    MCP --> LT

内建记忆 vs MCP 外部记忆

犀牛鸟视角

从犀牛鸟备赛角度看，MCP 集成层有两个值得关注的切入点 [社区]：

DB-Agent-Memory + MCP 集成：DB-Agent-Memory 的 Host-Adapter 架构天然适合 MCP 集成。它的 mcp-adapter.ts 已经存在，但功能可能不完整——四层金字塔的检索能力是否充分暴露给 MCP 客户端？MMD 注入优化是否能通过 MCP 传递？这些是潜在的改进方向。

supermemory 的多入口模式：如果 Coding Agent 需要访问浏览器收藏的文档、阅读过的文章——这是单靠 Agent 内建记忆无法覆盖的场景，恰恰是 supermemory MCP Server 的甜区。

局限性

1. MCP 不定义记忆语义：MCP 只是传输协议，不规定记忆如何组织、检索、遗忘——每个 memory server 的行为差异巨大 [文档]。
2. Profile 文件不是记忆：Rules / CLAUDE.md / AGENTS.md 没有 embedding、没有检索、没有冲突合并——它们是静态配置，不是知识库。
3. Memory Bank 是权宜之计：随着 Cursor 1.0 Memories 和 Claude Code 内建记忆的完善，这种社区模式的必要性在下降。
4. MCP 延迟：通过 MCP 调用外部记忆服务引入额外网络延迟，在高频交互中可能成为瓶颈。

证据等级汇总