OpenCode 记忆插件踩坑记:49% 垃圾数据逼我换了 Engram

你有没有这样的体验——

每次打开 AI 编程助手，它都像个失忆症患者：不记得你上次改了什么架构，不知道你项目的技术栈偏好，甚至连你半小时前说过的话都得重新解释一遍。

这不是幻觉。目前的 AI 编程助手，每次对话都是从零开始的全新会话。你之前花 10 万 token 让它理解的项目上下文，下次打开，归零。

记忆插件，就是解决这个问题的。

我花了一周时间，深挖了 OpenCode 生态中所有主流记忆插件——从本地 SQLite 到云端图谱，从零成本到月费 30 美元，从 17 星的小项目到 5 万星的大厂方案。这篇文章，把我的发现全部摊开给你看。

先说一个残酷的数据：

没有记忆插件的情况下，每次新会话平均浪费 5 万–20 万 token 在重复探索上。而有了记忆，传递等价信息的成本仅需 300–500 token。

这意味着什么？按 Claude Opus 4.7 的定价算，每次新对话光是「找回记忆」就要多花 $0.75–$3.00。一天开 5 个会话，一个月就是 $110–$450 的纯浪费。

更关键的是时间成本——你每次都得重新解释项目背景、架构决策、代码规范，这是纯粹的重复劳动。

二、候选方案全景：四大阵营

我把所有方案分成了四个层级：

Tier A：OpenCode 原生插件（即装即用）

插件	GitHub 星标	周下载量	核心特点
opencode-mem	645 ⭐	2,100+	社区最大，功能全面
codemem	39 ⭐	-	轻量级，专注代码记忆
open-mem	17 ⭐	-	极简设计，本地优先
opencode-mem0	6 ⭐	-	Mem0 的 OpenCode 封装
opencode-memory	11 ⭐	-	基础记忆存储

Tier B：通用 MCP 记忆服务器（功能最强）

方案	GitHub 星标	定位
Mem0	52,000+ ⭐	企业级记忆平台
Honcho	4,301 ⭐	学术背景，LongMem 基准测试 90.4%
Engram	2,200+ ⭐	三级渐进式检索
Recallium	36 ⭐	本地 Ollama + 高精度

Tier C：框架级方案（大杀器级别）

• Letta/MemGPT：~20,000+ ⭐，虚拟上下文管理
• Zep/Graphiti：24,500 ⭐，知识图谱 + 时间感知

Tier D：代码智能工具

Sverklo、serena、vexp 等——这类更偏「代码理解」而非「对话记忆」，不在本次讨论范围。

三、核心维度对比：安全、成本、功能

3.1 数据安全与隐私（最重要）

这可能是选择记忆插件时最被低估的维度。

方案	数据存储	网络调用	风险等级
open-mem / opencode-mem / codemem	纯本地 SQLite	零	⭐⭐⭐⭐⭐
Engram	本地默认	可选云端	⭐⭐⭐⭐
Honcho / Mem0	默认云端	发送到第三方	⭐⭐⭐

重点提醒：Honcho 和 Mem0 默认会将你的代码上下文发送到它们的云服务器。如果你的项目涉及商业代码，这可能是一个合规风险。

opencode-mem0 本质上是 Mem0 的封装，同样存在这个数据外传的问题，只是被包了一层 OpenCode 的壳。

3.2 部署复杂度

方案	部署时间	依赖
open-mem	1 分钟	无
opencode-mem	2 分钟	无
Engram	5 分钟	Python
Recallium	10 分钟	Ollama
Honcho	30 分钟	PostgreSQL + Redis + LLM
Mem0	15 分钟	API Key

3.3 功能对比

功能	open-mem	opencode-mem	Engram	Honcho
FTS5 全文搜索	✅	✅	❌	❌
向量检索	✅	❌	✅	✅
知识图谱	✅	❌	❌	✅
RRF 混合排序	✅	❌	❌	❌
AGENTS.md 自动生成	✅	❌	❌	❌
渐进式检索	❌	❌	✅	❌
LongMem 基准	-	-	-	90.4%

open-mem 在检索能力上意外地强——FTS5 + 向量 + 图谱 + RRF 混合排序，这基本是搜索领域的「全明星阵容」。

四、Token 经济学：真正的隐性成本

这是大多数评测文章不会告诉你的——记忆插件自身的 Token 消耗。

记忆插件有 5 个 Token 消耗点：

1. 系统提示注入（每次对话）：记忆上下文塞进 system prompt
2. 工具定义注入（每轮消息）：工具的 JSON Schema 定义
3. AI 压缩/提取（每次捕获）：用 AI 提取和压缩记忆
4. 搜索/检索（每次查询）：检索相关记忆
5. 自动捕获（每次工具执行后）：自动记录操作

月度 Token 成本估算

方案	月成本	关键因素
🏆 open-mem	~$0.20	渐进式披露 + 本地压缩
🥈 Engram	~$0.25	零 LLM 压缩 + 渐进式检索
🥉 Recallium	~$0.25	本地 Ollama + 高精度
opencode-mem	~$1.20	较高的系统提示开销
codemem	~$2.50	频繁 AI 压缩
Mem0	~$5–10	云端 API 调用
Honcho	~$8–15	复杂管道开销
💀 MCP-agent-memory	~$15–30	53 个工具定义的巨大开销

最大赢家：open-mem 和 Engram，月成本不到一杯咖啡钱。

最大陷阱：MCP-agent-memory。它注册了 53 个工具定义，每轮消息都要把所有工具的 Schema 注入上下文。这就像每次点外卖，餐厅都把整本菜单念给你听一遍——即使你只想要一份炒饭。

关键洞察

记忆插件省钱，不费钱。没有记忆时，每次会话浪费 5 万–20 万 token 重复探索。有了记忆，等价信息只需 300–500 token。

ROI 算一笔：即使是最贵的 MCP-agent-memory（$15–30/月），相比无记忆状态每月浪费的 $110–$450，依然净省钱。

五、我的推荐：怎么选？

如果你最在意检索质量和稳定性 → Engram

三级渐进式检索（从精确到模糊到 AI 辅助），Token 效率极高（零 LLM 压缩），成本只有 $0.25/月。这也是我最终的选择。

如果你最在意隐私 → open-mem 或 opencode-mem

纯本地 SQLite，零网络调用，代码永远不会离开你的机器。Open-mem 的检索能力还特别强（FTS5 + 向量 + 图谱 + RRF）。但要注意 open-mem 的维护节奏——社区较小，遇到问题可能需要自己动手。

如果你最在意社区和生态 → opencode-mem

645 星，2,100+ 周下载，是 OpenCode 记忆领域目前最大的社区。出问题有人答，有 bug 有人修。

如果你不在意数据上云且要最强性能 → Honcho

LongMem S 基准 90.4%，学术背景，功能全面。但需要 PostgreSQL + Redis + LLM，部署复杂度高，月费 $8–15。

如果你是企业用户 → Mem0

52,000+ 星，有完整的团队管理、API、SDK。但代码上下文会发送到云端，需要评估合规性。

六、我的实际选择：从 open-mem + true-mem 到 Engram

说实话，我最初选的是 open-mem + true-mem 的组合方案。

open-mem 负责底层的记忆捕获和检索（FTS5 + 向量 + 图谱 + RRF），true-mem 则在上层提供基于认知心理学的记忆管理——衰减曲线、记忆强度分级、长期/短期记忆分层。理论上，这是一个相当完备的组合。

但实际用了一段时间后，两个插件都暴露了各自的问题。

open-mem 的问题

Bug 1：AI 内部提示词被当成「记忆」存进数据库（见文末链接 ¹）

open-mem 的观察提取流程会调用 LLM 来分析工具输出，生成结构化记忆。问题是，这些 LLM 分析时使用的内部提示词本身（比如 <task>Analyze the following tool output and extract a structured observation.</task>）也会被 chat-capture 钩子捕获，当成「用户消息」存进 observations 表。

我的项目数据库里，4710 条记忆中有 2330 条（49%）是这种垃圾数据——全是内部提示词，不是用户意图。更糟糕的是，这些垃圾记忆会被注入回后续对话的上下文里，导致旧的指令（如 [search-mode]、[analyze-mode]）在新会话中被错误激活，直接干扰当前行为。

而且这个问题会逐渐恶化——用得越久，垃圾记忆占比越高。

Bug 2：/undo 操作后持续报错（见文末链接 ²）

在 OpenCode 中执行 /undo 撤回操作后，open-mem 的各个钩子（chat-capture、tool-capture、session-events 等）会持续抛出错误日志。原因是钩子没有 undo 感知能力，对已撤回的消息仍然尝试处理，且所有错误都通过 console.error 直接输出——config.logLevel 字段虽然存在但从未被实际使用。

我提交了两个修复 PR：

• PR #21（见文末链接 ³）：为 chat-capture 添加内部提示词过滤，匹配 5 种内部提示模板，在写入数据库前拦截。同时补充了 4 个测试用例，全部通过。
• PR #19（见文末链接 ⁴）：实现分级日志系统，替换所有 18 处 console.error 为可控的 logger.warn/debug，默认只显示 warn 级别，消除 /undo 后的噪音。964 个测试全部通过。

两个 PR 至今未合并。

true-mem 的问题

Bug：会话创建竞态条件导致记忆丢失（见文末链接 ⁵）

true-mem 的事件钩子使用 fire-and-forget 模式——session.idle 和 tool.execute.after 事件可能在 session.created 完成数据库插入之前就触发。由于 events 和 memory_units 表都有 FOREIGN KEY (session_id) REFERENCES sessions(id) 的约束，当 session 行还不存在时，所有记忆写入都会失败，抛出 FOREIGN KEY constraint failed 错误。

这意味着你辛辛苦苦工作产生的记忆，可能因为时序问题被静默丢弃。

此外社区还有其他用户反馈的问题：GSD 等编排框架的提示词被当成记忆存入（见文末链接 ⁶）、艾宾浩斯遗忘曲线按时间而非活跃度衰减导致休假一周回来记忆全没了（见文末链接 ⁷）。

我同样提交了修复 PR（见文末链接 ⁸）：用 INSERT OR IGNORE 实现 ensureSessionExists() 幂等方法，在每次记忆写入前确保 session 存在。

同样至今未合并。

为什么我最终切换到 Engram

一个记忆系统最怕的不是功能少，而是你不确定它记住的东西到底对不对。49% 的垃圾数据、静默丢失的记忆、迟迟不合并的修复——一旦对输出产生怀疑，信任链条就断了。

Engram 最初吸引我的是它的三级渐进式检索（精确匹配 → 模糊搜索 → AI 辅助扩展），这意味着它不会一股脑把所有「记忆」塞进上下文，而是按需逐层展开。Token 效率极高——它甚至不依赖 LLM 做记忆压缩，省掉了那个最烧钱的环节。

切换之后，整体体验确实稳了很多：

• 检索质量明显提升：渐进式检索比单一搜索模式靠谱得多，尤其在跨项目、跨会话的场景下
• Token 消耗更低：零 LLM 压缩 + 渐进式加载，月成本 ~$0.25
• 数据依然在本地：虽然是 Python 方案（部署比 open-mem 多花几分钟），但数据不出本机

所以如果你问我现在的推荐顺序：

1. 优先尝试 Engram——检索质量高，成本低，数据本地
2. opencode-mem 作为备选——社区更大，纯 Node.js，出问题有人答
3. open-mem + true-mem 看后续维护情况——设计理念很好，但目前两个项目的维护节奏都跟不上

写在最后

AI 编程助手的记忆，不是一个「锦上添花」的功能，而是从「工具」到「队友」的关键跨越。

没有记忆的 AI，永远只能做你的「一次性工具人」。有了记忆，它才能理解你的项目脉络、记住你的架构决策、积累你的代码偏好——真正成为你的编程搭档。

选择哪个记忆插件，取决于你最看重什么。但不选任何一个，才是最贵的选择。

本文基于对 OpenCode 生态所有主流记忆插件的深度调研，数据截至 2026 年 5 月。所有成本估算基于中等使用频率（日均 5 个会话，每会话 20 轮对话）。