精读: MCP 记忆拓扑 — 从协议到生态

基础概念与 Profile 对比：MCP 记忆集成层 Claude Code 记忆机制：精读: Claude Code 记忆系统 Codex 记忆机制：精读: Codex 记忆系统

调研元信息

一句话定位

MCP 是 Agent 记忆生态的 USB 口（见 bridge 篇），本文深入拓扑层面——多 Agent 连同一个 MCP 记忆服务时的架构差异、延迟特性、workspace 隔离策略，以及 Host-Adapter 模式与纯 MCP Server 模式的工程取舍 [文档][源码]。

记忆类型标注

日常类比

上一篇（bridge）把 MCP 比作 USB 口。本文进一步：想象你有三台不同品牌的电脑（Claude Code / Codex / Cursor），要共享同一个 NAS（网络附属存储）。USB 口是物理标准（MCP 协议），NAS 设备是记忆服务。但问题来了——每台电脑的文件系统不同（Agent 内建记忆格式不同），NAS 上的文件夹权限设置也不同（workspace 隔离），而且从电脑到 NAS 的网线有长有短（延迟差异）。本文就是在研究这些”网络拓扑”问题。

类比边界：NAS 通常是被动存储，但 MCP 记忆服务（如 DB-Agent-Memory）是主动蒸馏——它不只是存文件，还会对存入的对话做 L0→L3 的提炼。

MCP 记忆拓扑全景

flowchart TB
    subgraph agents["Coding Agents（各有内建记忆）"]
        CC["Claude Code<br/>内建: memdir<br/>读: 双阶段注入<br/>写: extractMemories"]
        CX["Codex<br/>内建: Phase1/2 pipeline<br/>读: memory_summary 全量<br/>写: AI consolidation"]
        OC["OpenClaw<br/>内建: flush+dreaming<br/>读: MEMORY.md+daily<br/>写: pre-compaction flush"]
        CU["Cursor<br/>内建: Memories Beta<br/>读: 向量搜索注入<br/>写: AI 自动/用户触发"]
    end

    subgraph mcp["MCP 协议层"]
        PROTO["标准化工具接口<br/>add_memory / search / get_profile"]
    end

    subgraph servers["MCP 记忆服务"]
        SM["supermemory<br/>三流检索<br/>Profile API<br/>浏览器捕获"]
        DB["DB-Agent-Memory<br/>四层金字塔<br/>MMD 注入<br/>Host-Adapter"]
        M0["mem0<br/>扁平事实<br/>25+向量后端"]
        CONT["Continue memory-mcp<br/>知识图谱<br/>实体-关系-观察"]
    end

    CC --> PROTO
    CX --> PROTO
    OC --> PROTO
    CU --> PROTO
    PROTO --> SM
    PROTO --> DB
    PROTO --> M0
    PROTO --> CONT

两种集成模式：Host-Adapter vs 纯 MCP Server

这是 MCP 记忆生态中最重要的架构分歧 [源码][已有]：

模式 A：纯 MCP Server（supermemory、mem0、Continue memory-mcp）

flowchart LR
    AGENT[Coding Agent] -->|MCP 工具调用| SERVER[MCP Server]
    SERVER --> ENGINE[记忆引擎]
    ENGINE --> STORE[(存储)]

Agent 通过 MCP 工具调用（add_memory、search_memory）与记忆服务交互。记忆服务对 Agent 是黑盒——Agent 不知道内部用了向量检索还是图遍历，只知道”调用 tool → 拿结果”。

优势：接入简单，Agent 无需感知记忆内部结构。 劣势：所有交互必须走 MCP 工具调用的路径，每次读写都是一次 LLM tool call + 网络往返。

模式 B：Host-Adapter 架构（DB-Agent-Memory）

flowchart LR
    subgraph agent["Agent 框架"]
        AGENT[Agent Core]
        ADAPTER[Adapter 层]
    end

    subgraph host["Memory Host"]
        HOST[生命周期管理]
        LAYERS[L0→L1→L2→L3]
        MMD[MMD Builder]
    end

    AGENT --> ADAPTER
    ADAPTER --> HOST
    HOST --> LAYERS
    HOST --> MMD
    MMD -->|注入| AGENT

Adapter 嵌入在 Agent 框架内部，直接在代码层面与 Memory Host 交互。对话流自动注入 L0，提炼自动发生，MMD 自动生成并注入 prompt。

优势：更深集成——对话可以自动流入记忆系统，无需 Agent 显式调用工具；MMD 注入可以利用 KV Cache 优化。 劣势：需要为每个 Agent 框架写 Adapter；记忆系统与 Agent 框架有代码级耦合。

对比矩阵

关键洞察：DB-Agent-Memory 同时提供两种模式——MCP Adapter（模式 A）和 OpenClaw/Hermes Adapter（模式 B）。这意味着它既可以作为”USB 移动硬盘”被任何 MCP Agent 使用，也可以作为”内置硬盘”深度集成到特定框架中 [已有]。

多 Agent 接同一 MCP 服务的差异

当 Claude Code、Codex、Cursor 同时连接同一个 MCP 记忆服务（如 supermemory）时，行为差异来自 Agent 侧，而非 MCP 侧 [源码][文档]：

差异 1：内建记忆与外部记忆的冲突

Claude Code 特有问题：extractMemories 会自动从对话中提取记忆到 memdir，但对话内容也可能通过 MCP 工具调用被存到 supermemory。这导致同一段知识可能在两个地方各存一份，且各自独立演化（memdir 有 autoDream 整合，supermemory 有 Dynamic Dreaming），最终可能产生矛盾 [源码][已有]。

差异 2：MCP 调用时机

各 Agent 何时调用 MCP 工具取决于其 harness 的工具选择策略：

• Claude Code：Agent 自主决定是否调用 MCP 工具——如果 system prompt 中已经有足够的 memdir 上下文，可能跳过 MCP 调用
• Codex：在沙箱中运行，MCP 调用受沙箱网络策略限制
• Cursor：Agent 模式下自由调用 MCP 工具
• OpenClaw：通过 Adapter 层自动调用，无需 Agent 显式决策

差异 3：Workspace 隔离

MCP 记忆服务需要处理”不同项目的记忆不应混在一起”的问题 [文档]：

Codex 的设计选择值得注意：它的 ~/.codex/memories/ 是全局共享的，所有项目的记忆混在一起由 Phase2 consolidation agent 统一管理。这在接入 MCP 外部记忆时可能导致问题——外部记忆按项目隔离，但 Codex 的内建记忆不隔离，两者的粒度不匹配 [源码]。

延迟分析

MCP 记忆调用引入的延迟是生产环境中的关键考量 [文档]：

flowchart LR
    A[Agent 决策<br/>是否调用 MCP] -->|~0ms| B[MCP 协议<br/>序列化+传输]
    B -->|10-50ms 本地<br/>50-200ms 远程| C[记忆服务<br/>检索+处理]
    C -->|50-500ms<br/>取决于检索方式| D[MCP 响应<br/>反序列化]
    D -->|10-50ms| E[注入上下文<br/>继续推理]

关键对比：Claude Code 的 findRelevantMemories 使用 Sonnet 做 sideQuery，每 turn 检索延迟约 1-3s（因为是 LLM 调用）。相比之下，纯向量检索的 MCP 延迟（100-300ms）反而更低。但 DB-Agent-Memory 的 Host-Adapter 模式由于是本地函数调用，可以做到 10-50ms——这是所有方案中延迟最低的 [源码][已有]。

犀牛鸟切入点：DB-Agent-Memory MCP Adapter

以下是从 MCP 拓扑视角看到的犀牛鸟贡献方向 [已有][源码]：

方向 1：MCP Adapter 能力完整暴露

DB-Agent-Memory 的 MCP Adapter 是否完整暴露了四层金字塔的能力？当前 MCP 工具集可能只有 add / search 两个操作，但 Host 的能力远不止此——L1→L2→L3 的手动触发蒸馏、MMD 全文获取、特定层级的定向检索，这些能力如果没有通过 MCP 暴露，就只有 OpenClaw/Hermes Adapter 能用。

方向 2：MMD 注入的 MCP 传递

MMD（Memory Meta Description）的分区注入优化（稳定区前置利用 KV Cache）是 DB-Agent-Memory 的核心创新。但通过 MCP 调用时，结果只是一个 tool response 字符串——无法控制它在 prompt 中的位置。是否可以设计一个 MCP Resource 类型来传递 MMD，让 Agent 将其放在 system prompt 的固定位置？

方向 3：跨 Agent 记忆一致性协议

当 Claude Code 和 Cursor 同时连接同一个 DB-Agent-Memory MCP Server 时，两边可能对同一事实有不同的记忆。是否可以在 MCP 层面设计一个版本戳 / 冲突解决协议？这超出了当前 MCP 规范的范围，但可以作为 MCP 记忆扩展提案。

局限性

1. MCP 不定义记忆语义：MCP 只是传输协议，不规定记忆如何组织、检索、遗忘——每个 memory server 的行为差异巨大，客户端无法做出通用假设 [文档]。
2. Auth 不统一：不同 MCP 记忆服务的认证方式各异（API Key / OAuth / 无认证），目前没有标准化的 MCP auth 层。
3. 工具发现缺乏语义：Agent 无法仅通过 MCP 工具列表判断”这是一个记忆服务”——没有标准化的 capability announcement。
4. 内建记忆与外部记忆的一致性：目前没有任何生产 Agent 解决了”内建记忆和 MCP 外部记忆的冲突合并”问题，这是一个开放挑战。

证据等级汇总