记忆 MCP 模式：Mem0 与 Cognee

Agent（智能体） 没有持久化记忆时，每个新会话都从零开始。本篇章聚焦 Mem0 + Cognee 双 MCP（模型上下文协议） 方案，用三层记忆架构 + 异步抽取管线，把“会话事实“和“代码结构“分别交给两个原生 MCP 服务器管理。这是 记忆系统设计 的子篇章——母篇章讲插件选型与通用 MCP 服务器，本篇章讲 MCP 服务器组合模式的生产级落地。

无持久化记忆的三个痛点

OpenCode + oh-my-openagent 生态在跨会话记忆上存在三组核心痛点：

痛点一：重复加载项目结构。 一个 70K Token 的项目上下文，若不做记忆抽取，每次新会话都要重新加载目录树、依赖关系、调用链。智能体花 3-5 分钟全量重读，成本叠加严重。

痛点二：重复提问需求。 上一次会话刚澄清过的用户偏好、架构决策、技术选型理由，下一个会话全部丢失。用户被迫反复回答同一组问题，协作体验断裂。

痛点三：协作记忆断层。 Sisyphus 委派给 Oracle 的探索过程、Metis 澄清过的需求细节，汇总后即丢弃。下一个智能体无法继承前一个智能体的探索轨迹，导致重复探索同一份代码。

生产实践中观察到：被动上下文（AGENTS.md 等启动时加载的文件）几乎总被智能体使用，但主动工具（MCP 记忆检索）的调用率明显偏低——智能体不会主动调用记忆工具，除非规则强制路由。这一观察与业界“被动注入优于主动调用“的共识一致，直接决定了本方案的设计取向：记忆加载必须被动触发，记忆路由必须写入 AGENTS.md 钉死。

三层记忆架构

借鉴人类认知科学，把智能体记忆划分为三层，每层用不同的存储引擎和读写策略：

Episodic 记“发生了什么“，Semantic 记“代码长什么样“，Procedural 记“怎么做才对“。三层互补——Episodic 提供时间线索，Semantic 提供结构线索，Procedural 提供可复用的工作模板。

六大记忆系统横评

选型前先看清主流方案的全貌。下表是六款记忆系统的横向对比，数据来自元宝记忆横评：

数据来源：Mem0 与 Zep 的 LongMemEval 数据来自元宝记忆横评及各项目官方博客（截至 2026-07），第三方独立复测结果有限，读者选型时应以自测为准。

关键决策：Mem0 管会话事实，Cognee 管 codebase 结构。两者均为 Apache-2.0 且原生 MCP，组合后覆盖 Episodic + Semantic 两层。Letta 方向反了——它是运行时自管记忆而非外挂存储；Mneme 核心闭源且社区活跃度极低，不推荐生产；腾讯 TencentDB-Agent-Memory 走另一条路——L0-L3 四层语义金字塔 + Mermaid 符号画布，白盒可追溯但需独立部署（详见下节）。

腾讯 TencentDB-Agent-Memory 的分层符号方案

六大系统横评中，腾讯 TencentDB-Agent-Memory 是唯一走“分层符号 + 白盒可追溯“路线的方案，与本篇章的 Mem0 + Cognee 组合形成鲜明对比。

L0-L3 四层语义金字塔

底层（L0/L1）存数据库，高层（L2/L3）存 Markdown 文件——底层重检索效率，高层重人类可读。每条信息都保留向下追溯的链接，保证“看到结论可以下钻到原始记录“。

Mermaid 符号画布：短期记忆压缩

腾讯方案最独特的设计是 Mermaid 无限画布——把几十万 Token 的工具调用日志卸载到外部文件系统，上下文只保留轻量级 Mermaid 任务地图（几百 Token），Agent 可通过 node_id 随时下钻恢复原文。

flowchart LR
    Log["繁杂过程日志<br/>(几十万 Token)"] -->|"1. 卸载完整原文"| FS[("外部文件系统<br/>refs/xxx.md")]
    Log -->|"2. 提取关系"| MMD["Mermaid 符号图谱<br/>(带 node_id)"]
    MMD -->|"3. 轻量注入"| Agent(("Agent 上下文<br/>几百 Token"))
    Agent -. "4. 按 node_id 下钻" .-> FS

实验显示 Flowchart 比 StateDiagram 效果好约 15%——Flowchart 更适合 Agent 自由探索式执行，StateDiagram 更适合严格生命周期的对象。

与 Mem0 + Cognee 的关键差异

选型建议：如果你的项目需要审计可追溯（金融、医疗、政务场景）或超长任务（连续 50+ 步骤的探索式任务），腾讯方案的 Mermaid 画布和白盒设计更有优势。如果追求轻量即插即用和原生 MCP 生态，本方案的 Mem0 + Cognee 更合适。两者并非互斥——可以用腾讯方案做 L0/L1 的短期压缩与审计，用 Mem0/Cognee 做 Episodic/Semantic 的跨会话沉淀。

数据来源：腾讯方案的性能数据（Token 节省 30-61%、任务成功率提升 8-52%）来自项目官方压力测试，第三方独立复测结果有限，读者选型时应以自测为准。

Mem0 + Cognee 双 MCP 方案

与 memory-system.md 的选型差异

记忆系统设计 推荐了 @modelcontextprotocol/server-memory、Kronvex、Memstate 三款通用 MCP 记忆服务器，适合轻量场景。本文的 Mem0 + Cognee 是专业分工方案——Episodic（会话事实）与 Semantic（代码结构）分层更精细，但部署成本更高（需 Mem0 API Key + Cognee 本地资源）。两者不是替代关系，而是复杂度梯度：小型项目用 memory-system.md 的通用方案即可，需要跨会话代码结构记忆的中大型项目适用本文方案。

分工与配置

Mem0 管 Episodic：会话事实、用户偏好、决策复盘。Cognee 管 Semantic：codebase 结构、依赖关系、调用链。

// .opencode/opencode.json — 双 MCP 服务器配置
{
  "mcp": {
    "mem0": {
      "type": "remote",
      "url": "https://mcp.mem0.ai/mcp",
      "enabled": true,
      "headers": {
        "Authorization": "Bearer ${MEM0_API_KEY}"
      }
    },
    "cognee": {
      "type": "local",
      "command": ["cognee", "mcp"],
      "enabled": true,
      "environment": {
        "COGNEE_DATA_DIR": ".opencode/cognee"
      }
    }
  }
}

Tool 白名单收紧

两个 MCP 服务器默认暴露较多工具（合计十几个），全部开放会让智能体在选择工具时产生歧义。把白名单收紧到 6 个核心工具：

三道防干扰防线

光配 MCP 不够，智能体仍可能乱调用。三道防线把被动加载的优势落地：

1. Tool 白名单收紧——只暴露上述 6 个工具，其余禁用，减少选择歧义。
2. AGENTS.md 路由规则钉死——在 AGENTS.md 中写入硬规则：代码结构问题→走 cognee，用户偏好/决策复盘→走 mem0。路由不依赖智能体自觉。
3. Mem0 auto-dream——配置 24 小时 / 5 个 session / 20 条 memories 触发合并去重，防止记忆库膨胀退化。

// AGENTS.md 片段
- 检索代码结构、依赖、调用链 → 调用 cognee:recall
- 检索用户偏好、历史决策、会话事实 → 调用 mem0:search
- 禁止用 mem0 存代码结构，禁止用 cognee 存会话偏好

异步抽取管线

记忆写入若同步阻塞智能体主循环，会拖慢响应。参考 iEnable AI 的 12 层 SQLite 记忆 + 独立 cron 模式，把抽取放到后台 worker。

flowchart TB
    subgraph Agent["智能体层"]
        A["Agent 主循环"]
    end
    subgraph Async["异步抽取管线"]
        E["events/ 目录<br/>原始事件流"]
        W["后台 Worker<br/>cron 30min"]
        M0["Mem0<br/>Episodic"]
        C["Cognee<br/>Semantic"]
        P["Procedural JSON<br/>importance≥7"]
    end
    subgraph Trigger["触发源"]
        T1["会话结束"]
        T2["代码变更"]
        T3["验证成功"]
    end

    A -->|实时写入不阻塞| E
    T1 --> W
    W -->|抽取事实| M0
    T2 -->|增量 cognify| C
    T3 -->|写入工作流| P
    A -->|启动加载| P

    classDef agent fill:#4A90D9,stroke:#333,color:#fff
    classDef workflow fill:#FF9F43,stroke:#333,color:#fff
    classDef mcp fill:#A66CFF,stroke:#333,color:#fff
    class A agent
    class E,W,T1,T2,T3 workflow
    class M0,C,P mcp

图中紫色节点表示外部状态存储（含 MCP 服务器与文件型 Procedural JSON），非严格意义上的 MCP 服务器。Procedural JSON 归类为“外部存储“是因为它独立于智能体上下文存在。

四步管线：

1. 会话进行中——智能体把原始事件写到 .opencode/memory/events/ 目录，写文件不阻塞主循环。
2. 独立 worker（cron 每 30 分钟）——从 events/ 读取原始事件，调用 LLM 抽取结构化事实写入 Mem0。worker 独立于智能体进程，故障不影响主循环。
3. 代码变更触发 cognee cognify——git commit 后增量更新 codebase 图谱，只处理变更文件。
4. 验证成功时写入 Procedural JSON——给工作流步骤打 importance 1-10 评分，启动时仅加载 importance≥7 的 15-20 条。低分条目定期归档，防止启动加载变慢。

与 Compaction 的边界

上下文压缩 的 Compaction 在会话内压缩对话历史，异步管线在会话结束后抽取事实写入 Mem0。两者不冲突：Compaction 是会话内 Token 管理（把长对话压成短摘要仍留在上下文里），管线是跨会话记忆沉淀（把摘要里的事实抽出来存到外部存储）。推荐协同策略：Compaction 触发时同步 dump 事件到 events/，worker 在会话结束后抽取；下一会话启动时，Mem0 的事实检索补充 Compaction 摘要可能丢失的细节。

多因子加权检索

单一向量检索的 Hit@1 基线偏低——智能体问“上次怎么解决这个 bug 的“，召回的往往是无关记忆。引入多因子加权：

score = 0.45 × vector_similarity
      + 0.25 × keyword_match
      + 0.20 × freshness(14天半衰期)
      + 0.10 × importance

• vector_similarity（0.45）——语义相似度，主召回信号
• keyword_match（0.25）——代码上下文（变量名、路径）的精确匹配
• freshness（0.20）——14 天半衰期，近期记忆权重更高
• importance（0.10）——Procedural 评分，验证成功的工作流加分

引入多因子加权后，Hit@1 较单一向量基线显著提升（约翻倍），freshness 因子解决了“三个月前的架构决策已被新方案取代“的过期记忆问题。实际提升幅度依赖记忆库规模与查询分布，建议读者在自测环境中重新标定基线。

关键坑

Cognee cognify 批处理阻塞

超过 5K 文件的项目，cognify 全量构建要 10-30 分钟，期间 recall 搜不到任何东西。对策：增量 cognify（仅变更文件）+ 夜间全量重建 + 阻塞期间降级为 Mem0 兜底。

Mem0 project id 来自 git remote

Mem0 默认用 git remote URL 推断 project id，多项目共用同一 remote 时会混淆记忆。对策：显式配置 MEM0_PROJECT_ID 环境变量，不依赖推断。

双 MCP LLM 调用叠加成本

Mem0 和 Cognee 各自会调用 LLM 做抽取和摘要，两个 MCP 叠加 Token 开翻倍。对策：tool 白名单收紧 + AGENTS.md 路由规则减少误调用 + auto-dream 去重降低存储量。

常见反模式

手调启发式控制器

现象：为了“优化“记忆检索，手写一堆 if-else 规则决定何时查 Mem0、何时查 Cognee、何时跳过记忆。

问题：规则越调越复杂，最终变成一个无法维护的启发式怪兽，且每个项目都要重调。

对策：把路由规则固化到 AGENTS.md，用多因子加权检索替代手调阈值。智能体不该决定“怎么查“，只该决定“查什么“。

内联记忆写入阻塞 agent

现象：智能体每完成一步就同步调用 mem0:add 写记忆，主循环被 MCP 往返延迟拖慢。

问题：记忆写入成了性能瓶颈，智能体响应时间翻倍。

对策：所有记忆写入走 events/ 目录异步管线，worker 在后台抽取。智能体主循环只读不写。

单一通用存储不区分类型

现象：把会话事实、代码结构、工作流步骤全塞进一个记忆库，用同一个检索策略。

问题：代码结构需要图遍历，会话事实需要时间索引，工作流需要按 importance 过滤——混在一起哪种都查不准。

对策：三层记忆架构，Episodic / Semantic / Procedural 各自用合适的存储引擎，检索时按类型路由。

关联章节

• ↑ 记忆系统设计（母篇章，讲插件选型与通用 MCP 服务器）
• ← 上下文压缩与Token 预算（Compaction 与记忆的协同）
• → DCP 与高级上下文管理插件（上下文管理与记忆的边界）
• → 交接架构设计（跨会话交接与记忆的集成）