先给结论

不是"全网最成熟"——因为没有绝对意义上的最成熟，只看你解决的是哪一类问题。但把我的系统放进 2026 年的开源生态里横向比较，它稳居第一梯队的自制方案，而且有一个绝大多数开源项目都没有的特长：跨 6 家 harness 的单源权威架构。

同时要诚实：业界正在把同类能力产品化。星数最高的 claude-mem（9.3 万星，已改名 Grok Mem）做的就是我想做的事——跨 Claude Code / Codex / Gemini / Hermes / Copilot / OpenCode / OpenClaw 持久化上下文——只是它是开箱即用的成品，我是手工攒的匠人方案。

这篇文章做三件事：先讲清我系统到底由哪几层构成（回应一个常见混淆：ECC 是不是我的记忆系统）；再把它和全网开源记忆项目做横向盘点；最后给出 7 条改进建议。

一、先把三层边界讲清楚：原生机制 / 我的跨 harness 层 / ECC 配置层

很多人（包括我自己一开始）会把这三个东西混为一谈。它们其实是三层：

第一层：Claude Code 原生的文件记忆机制。 这是 Anthropic 内置的功能（官方文档 code.claude.com/docs/en/memory，本次经 3 票对抗式核验确认）。机制是：CLAUDE.md 在会话开始时按四层作用域（系统 / 用户 ~/.claude/CLAUDE.md / 项目 ./CLAUDE.md / 本地 ./CLAUDE.local.md）从宽到窄拼接加载（不是覆盖）；支持 @path/to/import 递归导入，最大 4 跳；自动记忆目录 ~/.claude/projects/<项目>/memory/ 里，MEMORY.md 是索引，只加载前 200 行或 25KB（以先到者为准），具体记忆文件由 Claude 按需读。/compact 后项目根 CLAUDE.md 从磁盘重读重注入。

这一层是地基，所有人（包括我）都站在它上面。

第二层：我自建的跨 harness 共享架构（2026-07-24 设计，迭代至今）。 这才是"我的记忆系统"的真正主体，是我自己设计建造的。核心是单一权威库 + 指针访问：

• 权威库 = Claude Code 的记忆目录，CC 每会话自动加载索引，零额外成本；
• 其他 harness（Hermes / OpenClaw / Codex / Kimi / OpenCode）各持一条指针，需要回忆时主动读权威库（先读 MEMORY.md 索引，再读对应文件）；
• 不做双向同步、不做 symlink——这是我实测验证后的决定：Hermes 的 MemoryStore 有 3500 字符上限，软链后整文件原子重写会把 CC 索引截断写崩；OpenClaw 整文件重写触发 drift 守卫。所以选"指针"而非"同步"，单源真相，无冲突无过期。

第三层：ECC 配置管理系统。 ECC 不是记忆系统，它是管 Claude Code 配置的"管家"——管规则包（~/.claude/rules/ecc/）、管受管文件（每周一凌晨 4:02 自动更新覆盖）、提供一个 ecc-memory-vault MCP 后端。它跟我的记忆架构有一处摩擦：ECC 受管文件（~/.codex/AGENTS.md、~/.kimi-code/AGENTS.md）会被周更覆盖，所以我把跨 harness 指针故意放在 ECC 管不到的 ~/.agents/AGENTS.md，2026-09-09 专门把 Kimi 的指针迁过去，就是为了逃过 ECC 的覆盖。

一句话：记忆架构是我建的，ECC 是旁路的配置管家，两者有交集但不是一回事。

二、我的系统体检（实测数字）

我用一个子 agent 实测了记忆目录，数字都核验过：

注：上表分类合计 507，另有 15 个索引/非标准文件（MEMORY.md 及 ecc/github/blog 等杂项前缀）未计入分类，合计 522。

几个值得注意的点：最大的文件 project_lynxhouse 有 79KB，违反了"一事实一文件"原则；4 个文件缺 type 字段（索引和非标准文件）；没有自动记忆写入/抽取 hook，全靠模型自觉。

三、业界全景：五大架构流派

把全网开源项目扫一遍（星数都用 gh 认证 API 核验，2026-09-10 快照），能归出五种架构模式（经 3 票核验，但"哪种最优"无公开基准，属合理推断）：

1. 纯文件 / Markdown（Claude Code CLAUDE.md、Cline .clinerules）——最简单、零依赖、可 git；但大型项目 token 膨胀，内容易陈旧。
2. 纯向量数据库（Memorizer 的 pgvector、Phantom 的 Qdrant）——语义检索强；但无重排序时噪声大。
3. 纯知识图谱（以关系图谱为核心存储）——关系表达强，但不剪枝则查询延迟占主导。Memento 的 Neo4j 属此倾向但兼带向量，并非纯 KG。
4. 嵌入式混合（codebase-memory-mcp 的 SQLite+Nomic、graph-memory 的 SQLite+LPA/PageRank、mcp-memory-keeper 的 SQLite+KG+轻量向量）——兼顾性能与零依赖，在本次盘点样本内占比最高。
5. 云端混合（mem0 的向量+BM25+实体链接、mcp-memory-service 本地优先 ONNX + 可选 Cloudflare 同步）——支持多设备同步；但引入外部依赖与隐私顾虑。

混合架构在本次盘点样本内占比最高，但没有公开基准证明单一方案在所有项目规模下胜出。

四、重点玩家盘点

按定位分三层（星数为 2026-09-10 认证核验快照）：

产品化跨 harness（最接近我的路线）

• thedotmack/claude-mem（Grok Mem）— 93,580★：全场星数最高。捕获会话→AI 压缩→注入未来会话；跨 CC/Codex/Gemini/Hermes/Copilot/OpenCode/OpenClaw。就是我的跨 harness 思路的产品化版本。

通用记忆基础设施

• mem0ai/mem0 — 65,009★：YC S24，Apache 2.0，向量+BM25+实体链接混合；显式集成 CC/Codex/Cursor/Windsurf/OpenCode/OpenClaw。
• DeusData/codebase-memory-mcp — 42,782★：代码图谱类记忆工具中星数最高。把代码库索引成持久知识图谱（SQLite WAL + 内置 Nomic 768 维嵌入，无 Neo4j 无外部向量库），深度集成 CC（hooks + Scout/Verify/Auditor 三层代理）。我自己就在用这个 MCP，实测 ECC 项目有 48,168 节点 / 62,589 边。
• getzep/graphiti — 30,736★：时序知识图谱（有 arXiv 论文），节点/边带时间，bi-temporal。Zep 的开源内核。
• topoteretes/cognee — 30,608★：自托管 KG 记忆平台。
• supermemoryai/supermemory — 29,573★：记忆+上下文引擎，主打快和可扩展。
• oraios/serena — 29,099★：MCP 语义代码检索工具包，带 memories。
• letta-ai/letta（前 MemGPT）— 24,677★：OS 式记忆层级（核心记忆=RAM，归档记忆=磁盘，自我编辑），有状态 agent。
• cline/cline — 67,746★：本节内星数最高但无专用记忆系统，靠 .clinerules 文件跨 CLI/VSCode/JetBrains 加载。
• getzep/zep — 4,902★：托管版 agent 记忆（Graphiti 驱动）。

Claude 专用中腰部（各有绝活）

• basicmachines-co/basic-memory — 3,908★：纯 Markdown + wiki 链接 + MCP 知识图谱，哲学上跟我最像。
• lucasrosati/claude-code-memory-setup — 969★：Obsidian Zettelkasten + Graphify 代码图谱 + 聊天导入，号称省 71.5× token。
• debugtheworldbot/msync — 54★：把 CC 记忆同步到 claude.ai / Claude App。
• Durafen/Claude-code-memory — 74★：Tree-sitter + Qdrant 向量 + “Memory Guard” 代码质量门。
• kuitos/opencode-claude-memory — 59★：OpenCode 插件，兼容 CC 的 Markdown 格式，auto-dream 自动巩固（合并/剪枝/重写）。
• WhenMoon-afk/claude-memory-mcp（Mooncite）— 68★：引文核验——从本机各家历史里召回，mooncite_inspect 核验引文是否仍匹配源文件（只证"出处对"，不证"内容真"）。
• mycelium-hq/ai-brain-starter — 36★：vault + hooks + 双时态规则谱系（每条规则两个时钟：写入时 + 上次验证时）+ 周漂移扫描。
• hudrazine/claude-code-memory-bank — 41★：Cline Memory Bank 方法论，分层文档。
• LARIkoz/eidetic — 12★：Markdown + FTS5/向量混合，漂移检测降权陈旧记忆，session-end 自动抽取巩固，topic bases 按需挂载。
• d2a8k3u/claude-code-memory — 7★：自治 hook 循环——每次 prompt/编辑/Bash 前搜记忆，类型感知衰减（pattern 慢衰减 / episodic 快褪），自动合并 ≥95% 相似重复，关系图随用演化。
• serkansmg/smg-claude-memory-mcp — 33★：DuckDB + 嵌入，per-project 隔离，团队 git 共享。
• nwiizo/ccat — 33★（已归档）：CLAUDE.md 上下文分析器，import 链诊断（循环依赖/缺文件/超大上下文）。

MCP 记忆服务器

• doobidoo/mcp-memory-service — 1,933★：本地优先——SQLite-vec + ONNX 本地嵌入，Cloudflare Vectorize/Milvus 可选同步，活跃维护。
• ghostwright/Phantom — 1,467★：基于 Claude Agent SDK，Qdrant + Ollama 三层向量。
• adoresever/graph-memory — 609★：DSH/OpenClaw 插件，SQLite + LPA 社区检测 + PageRank。
• gannonh/memento-mcp — 424★：Neo4j 统一图+向量，但最后推送 2025-10，活跃存疑。
• petabridge/memorizer — 196★：.NET，PostgreSQL+pgvector。
• mkreyman/mcp-memory-keeper — 134★：SQLite + KG + 字符 n-gram 哈希向量（非神经嵌入）。

还有 Grok 缺口分析点到、但本次未深验的大生态项目：continuedev/continue（~28k★）、paul-gauthier/aider（~28k★，repo-map 作隐式记忆）、microsoft/autogen（~22k★）、langchain-ai/langgraph（~18k★）、RooVet/RooCode（~1.4k★，内置分层记忆）。它们是更广义的 agent 生态，不是专门的记忆系统。

五、我的自制系统 vs 业界（一张表）

我的强项：跨 harness 单源、溯源字段、互连密度、用了最强的代码图谱 MCP。短板：无自动写入、无漂移检测、无语义检索、无自动巩固。

六、7 条改进建议

每条都对应业界做得更好的点，可落地：

1. 加语义/向量检索层。 我的 522 文件靠 [[链接]] 和关键词，召回精度随规模下降。最对路的是借鉴 eidetic（FTS5+向量 hybrid，专为 Markdown 记忆设计）或 mem0 的向量+BM25+实体链接，给记忆库加一层语义召回。context-mode 已有 FTS5，缺的是跨库语义层。（codebase-memory-mcp 索引的是代码图谱，给 Markdown 记忆做语义检索并非开箱即用，需改造或另选。）
2. 引入漂移检测 / 陈旧审计。 522 文件里肯定有过期记忆。eidetic 的"检测到陈旧就降权"、mycelium 的双时态时钟（写入时 + 上次验证时）+ 周漂移扫描是现成范式。可加一个定期 job 扫高编辑文件累积语义漂移。
3. 自动记忆抽取 + 巩固。 我全靠模型内联写，漏写就丢。可加 Stop/SessionEnd hook：会话结束由小模型从 transcript 抽取决策/规则/教训存成卡片（eidetic、d2a8k3u 都这么做），并定期 auto-dream 合并/剪枝/重写去重。
4. 引文 / 核验机制。 我有 originSessionId 但不验证记忆是否仍真。借鉴 Mooncite：引用记忆前对照实况核验（只证出处对，不证内容真），至少在研究/博客这类要公开的场景加这步。
5. 索引规模治理。 MEMORY.md 已用 87%（118/200 行，~21.7/25KB；超 25KB CC 只加载前 25KB，后面看不见）。可分层索引（大类子索引）或上语义检索缓解。
6. 大文件原子化。 project_lynxhouse 79KB 违反"一事实一文件"，检索时整文件读进上下文浪费 token。拆成多条小记忆 + 索引行。
7. 产品化路径抉择：并存还是迁移？ claude-mem（9.3 万星）做的就是我跨 harness 的成品版。要决定：继续手工攒（完全可控、零依赖、隐私本地），还是引入 claude-mem 做"会话捕获+压缩+注入"那层（省手工，但黑盒、依赖外部）。我的建议是并存——保留我的权威库做长期记忆，让 claude-mem 补会话级短时上下文，两层各司其职。

七、诚实的局限

这次调研有边界，写在这里免得过度自信：

• 星数是 2026-09-10 快照，有正常波动；
• Grok 缺口分析点名了一批项目（continue/aider/autogen/langgraph/RooCode 等）只到星数未深验实现；
• Anthropic 目前没有发布原生的持久记忆 API 或 /recall、/checkpoint 等命令——Grok 一度声称有（Claude Projects 持久记忆 API、Claude Code v2.3 检查点存储、2M prompt caching），经 3 票对抗式核验在官方文档找不到痕迹，判定为幻觉，已全部排除，不写进上文结论；
• 本次验证主要覆盖英文生态项目，中文社区的 CLAUDE.md 最佳实践集合未系统覆盖；
• “哪种架构最优"是合理推断，无公开基准。

结论

把我的系统放进 2026 年的开源记忆生态横向比较：它不是"最成熟”（无此绝对值），但稳居第一梯队自制方案，独特价值在跨 6 家 harness 的单源权威架构——这件事连星数最高的 claude-mem 也是走类似路线只是产品化了。我的短板集中在三个方向：语义检索、漂移检测、自动抽取/巩固，恰好是 eidetic / d2a8k3u / mycelium 这几个小项目做得最好的地方。补上这三块，我的自制系统就能从"第一梯队"往"自我演进"再进一步。

记忆不是越多越好，是越能自我维护越好。

调研方法：本地子 agent 实测体检 + gh 认证 API 核验星数 + grok-deep-research 工作流（5 路并行搜索 → 抓取 29 源 → 缺口分析 → 3 票对抗式核验 25 条声明 → 中文综合）。