2个国产AI记忆层开源项目PK
**Cortrix vs PowerMem 的设计取舍与选型指导, 两款产品之前都发文讲解过, 今天来个 PK.** **Cortrix 是刚刚新鲜发布的: **Cortrix 一手解说 PowerMem 则是 OceanBase AI 战略开源产品之一: PowerMem 未来可能成为 OB 的杀手锏 > 5 万行 Python 撞上 6.4 万行 C++，两种 RAG 基础设施哲学正面交锋 ## **写在前面** 最近翻了两个项目，巧合的是都跟「Agent 记忆」沾边。 一个是 **cortrix**——6.4 万行 C++17，AGPL-3.0 协议，刚放出 v1.0.0-rc.1。我上一篇已经拆过它了，把它定位成「带向量索引的数据库」。 另一个是 **powermem**——5 万行 Python 加上周边工具链，Apache-2.0 协议，OceanBase 团队出品，已经在 PyPI 上跑了好几个版本。它把自己定位成「持久化、自演化的记忆引擎」。 把它们放一起对比，是因为这两个项目**代表了两条完全相反的路径**：一条是把现有数据库的能力边界往死里推，另一条是把所有能用的数据库适配成统一接口。今天这篇把这两条路子的差异拆到源码级。 文章结构按四维展开：**产品设计**、**技术栈**、**生态**、**场景**。每个维度都给出双项目的对照，最后给一个可执行的选型建议。 ## **一、产品设计：底座 vs 中间件** 打开两个项目的 README，第一句话就把分歧讲清楚了： - **cortrix**：*「本地优先的语义存储服务」*——全栈自管，从存储到索引到 HTTP 一条龙 - **powermem**：*「持久化、自演化的记忆引擎」*——下沉到已有数据库上，只做记忆层 这两个定位的差异不是修辞，是技术债的分界。 cortrix 的设计压力来自「**我要替换现有向量库**」。它把 SQLite 的能力边界推到极致（多库架构、WAL 调优、自研 PHnsw），目的是让你不再需要 milvus / qdrant / weaviate 那一套独立部署。所有能力只能跑在它自己的 SQLite 上——这是它的封闭性，也是它的简化能力。 powermem 的设计压力来自「**我已经有一堆数据库了**」。它的 StorageAdapter 在 OceanBase、PostgreSQL、SQLite、seekdb 之间归一化 insert/search/get/update/delete，再加 json 元数据过滤和 snowflake ID。代价是：换存储时有些语义差异要靠 adapter 兜底；好处是：你可以把记忆层直接叠到现有基础设施上。 **一句话总结**：cortrix 是底座（替换你的向量库），powermem 是中间件（叠在已有数据库上）。 ## **二、技术栈：C++17 vs Python 3.11+** |维度|cortrix|powermem| | --- | --- | --- | |主语言|C++17|Python 3.11+| |代码量|6.4 万行|5 万行 + 周边| |协议|AGPL-3.0|Apache-2.0| |状态|v1.0.0-rc.1|已发布多版本| |编译/启动|自编译 C++|pip install| **AGPL-3.0 vs Apache-2.0** 是商业集成的分水岭。AGPL 是「传染型」开源——只要你的服务通过网络对外提供 AGPL 组件的能力，就得开源整个服务栈。Apache-2.0 允许闭源商用，只要保留版权和许可声明。对于企业级集成，powermem 显然更友好。 **C++17 vs Python 3.11+** 决定了演进路径： - cortrix 在 C++ 里自研了 hnswlib 的持久化封装、SQLite 多库拆分、BGE-M3 和 bge-reranker 的本地推理。代价是 C++ 编译地狱、依赖管理复杂、招人难 - powermem 走 Python 生态，全面接入 OpenAI、Anthropic、Qwen、DeepSeek、SiliconFlow、Ollama 等十几家 LLM 供应商。代价是单进程性能，powermem 自己文档就写明：embedded SQLite 模式下强制 workers=1，多进程起不来 **取舍的本质**：选 cortrix 是为**性能/可控性**自己扛；选 powermem 是为**生态/可改性**接受 Python 开销。 ## **三、接入路径：四条 vs 四条** 两个项目都给了四种客户端入口，但**成熟度分布完全不一样**： |路径|cortrix|powermem| | --- | --- | --- | |HTTP / OpenAPI|主力（自建服务）|FastAPI（成熟）| |MCP|标 Verification required|13 工具（7 记忆 + 6 用户画像）| |Python SDK|标 Verification required|主力，最成熟| |第四个|内置 Agent（Roadmap）|CLI（pmem）（成熟）| |IDE 插件|无|Claude Code / Cursor / VSCode 等多端| cortrix 多了一条「**内嵌 Agent**」——一个本地固定流程的 RAG 聊天服务，定位是给非开发者直接体验。Roadmap 标的是「高级自主执行器，如 tool-use 和 plan-execute 模式」。 powermem 多了一条「**CLI**」（`pmem` / `powermem-cli`），更偏运维和调试。它还通过 apps/ 目录提供了 Claude Code、Cursor、VSCode、OpenClaw 等十几种 IDE/Agent 的插件适配——这是「**生态广度**」的最直接体现。 **成熟度对照**：cortrix 的 MCP、SDK 都在补完中；powermem 的 4 条都已发布，且 13 个 MCP 工具有现成测试覆盖。 ## **四、存储：SQLite 多库 vs 多后端适配** 这是两个项目**分歧最大**的地方。 ### **cortrix · 一库打天下** 每个命名空间一份 `cortrix.db`，全局一份 `catalog.db`，稀疏向量的倒排索引再单独一份。所有 PRAGMA 参数都调过：WAL + `synchronous=NORMAL` + 256MB mmap + `auto_vacuum=INCREMENTAL` + `FULLMUTEX`。 向量索引是自研的 **PHnsw**（Persistent HNSW）：vendor 进 hnswlib，但外面套了一整套 `WAL → fdatasync → 内存图 apply → 后台 snapshot` 流程。写入侧还有 group-commit 协调器。说白了，是把一个纯内存的图索引硬改成了崩溃可恢复的。 ### **powermem · Adapter 模式** `StorageAdapter` 把 insert/search/get/update/delete 在 OceanBase / PostgreSQL / SQLite / seekdb 之间归一化。filter 分两类：`_SYSTEM_FILTER_KEYS = {user_id, agent_id, run_id}` 和 `_PAYLOAD_FILTER_KEYS`，跨后端通过 `_metadata_filter_key_for_store()` 适配语义差异（SQLite / PG 的嵌套结构 vs OceanBase 的扁平结构）。 **隐藏强项**：OceanBase 后端原生支持 **vector + full-text + graph** 三合一，powermem 直接利用。代价是：换存储时有些**过滤路径差异**要靠 adapter 兜底（powermem 在 adapter 里有显式的注释说明这一点）。 **取舍**：cortrix 的存储是**最优解但唯一**（只能用它的 SQLite）；powermem 的存储是**良好解但有妥协**（用哪个数据库都行，但要吃 adapter 层的抽象成本）。 ## **五、检索：都选了 RRF，但融合路数不同** 巧合的是，两个项目都把 **RRF（Reciprocal Rank Fusion，k=60）** 当默认融合策略。但走的路数完全不一样： |维度|cortrix|powermem| | --- | --- | --- | |主融合路数|2（向量 + FTS5）|4+（向量 + 全文 + 稀疏 + 图 + 时间）| |RRF 默认参数|k=60|k=60| |备选融合|仅 5 路 SPLADE 分支|weighted 加权融合| |FTS5 处理|主动改写为 OR 模式|用数据库原生全文索引| |过采样|3× 后过滤再截断|由后端实现，差异较大| **两个项目对 FTS5 的态度很能说明问题**： - cortrix 发现 SQLite FTS5 默认对多个查询词是隐式 AND 的，但自然语言查询往往词很多，隐式 AND 命中率极低，所以**主动改写为 OR 连接的词袋 BM25**，并对操作符做了注入清洗 - powermem 走的是数据库原生全文索引（OceanBase / SQLite FTS5 / PG tsvector），不在应用层改查询语法 **额外路径差异**： - cortrix 还有一个 5 路融合（dense / contextualized / sparse / fts5 / hype_question）专门给 SPLADE 稀疏分支用，是真的把融合当成了工程问题在做 - powermem 在 OceanBase 后端实现了完整 4 路 RRF，vector_w / fts_w 权重可调，weighted 加权融合作为备选 **结论**：两个项目 RRF 一样，但 cortrix 是在「**怎么让 RRF 跑得对**」上花了更多心思（SQL 路由只在意图分类器命中时触发，3× 过采样后再截断），powermem 是在「**让 RRF 适配多个后端**」上花了更多心思。 ## **六、记忆模型：矛盾判定 vs 经验蒸馏** 这一层是两个项目**最本质的差异**——它们对「记忆」的理解不一样。 ### **cortrix · 记忆会自己打架** 三层模型： ``` memory_sessions 会话元信息 └── interaction_log 每一轮 user/assistant 对话 └── blocks 抽出的事实（block_type=memory） ``` 第三层落的是**普通的 `blocks` 行**，只是类型标记不同——为了让 memory 检索直接复用 QueryPipeline（继承向量 + BM25 + RRF），不用另写召回。 **核心创新：矛盾判定**。新事实写入前会**再调一次 LLM** 判断它和已有事实有没有冲突。命中冲突就把旧事实标成 `invalidated`，并记录 `invalidated_by_block_id`——是哪条新事实把它作废的，有据可查。同时还支持手动作废和**撤销作废**。 这意味着记忆不是只写不改的日志，而是一个**会自我修正的状态机**。 ### **powermem · 两层蒸馏** 不只抽事实，还抽**程序性技能**： ``` class SkillManager: def distill(messages, today) -> List[{title, description, tags, procedure: {"prerequisites": [...], "steps": [...], "pitfalls": [...]}}]: ``` `distill()` 抽可复用的 SOP（prerequisites / steps / pitfalls 三段式），`merge()` 用 LLM 判定两个 skill 是否合并。**这是 cortrix 完全没有的能力**。 记忆还按重要性分三档：working（1h）、short_term（7h）、long_term（60h），由 `importance_score` 自动归类。 ### **决定的差异** - cortrix 是**会自我修正的状态机**（处理事实冲突） - powermem 是**会自己蒸馏出 SOP**（从对话里学到可复用工作流） 后者更激进，但要求 LLM 更靠谱。如果你做的是「**事实性**」agent（不能犯错），cortrix 的矛盾判定更合适；如果你做的是「**任务执行**」agent（越用越聪明），powermem 的 Skill 蒸馏更合适。 ## **七、生命周期：类型免疫 vs 艾宾浩斯** 记忆的「什么时候该忘」是核心设计取舍。 |维度|cortrix|powermem| | --- | --- | --- | |衰减模型|按类型免疫|艾宾浩斯曲线 R=e^(-t/S)| |触发器|纯时间|时间 + 访问强化| |衰减下限|event 类有下限|由 access_count 提升| |复习机制|无|按 review_schedule 主动复习| ### **cortrix** - `fact` 和 `preference`**永久免疫**，不衰减 - `event` 按 `exp(-λ·age_days)` 指数衰减，**但设了下限**，不会衰减到零 - 衰减是**纯时间**驱动，没有「复习强化」概念 ### **powermem** 经典 Ebbinghaus 公式 `R = e^(-t/S)`： - `decay_rate` 默认 1.5 - `decay_rate_multipliers` 按档位分 `{working: 1, short_term: 7, long_term: 60}` - `review_intervals` 默认 `[1, 6, 24, 72, 168]` 小时 - 每次访问会**强化 S**（stability），access_count 提升 retention - 工作流会按 schedule 主动复习 **行为差异**：powermem 的记忆会被**主动按 schedule 复习**（像人脑），cortrix 的记忆一旦写入就只受时间影响（像带 TTL 的 KV）。powermem 更像「人脑」，cortrix 更像「带 TTL 的 KV」。 ## **八、可观测：错误契约 vs Plugin 钩子** 两个项目都重视「让 Agent 用得稳」，但走的路不一样。 ### **cortrix · 对 LLM 友好的输出契约** **`agent_friendly::error`：全项目所有错误必须**带五个字段——`code` / `message` / `retryable` / `category`（auth / quota / transient / permanent / timeout） / `retry_after_ms`。意图明确：让 LLM 拿到错误能自己判断该重试、该换参数、还是该认输。 **`agent_trace`：能反查证据链（这次回复的依据是哪些 block），snippet 做了头 400 字节 + 尾 100 字节**的截断。权限做得很克制：跨用户读 trace 直接 unauthorized，而且**不泄露 session 是否存在**，避免被枚举探测。 ### **powermem · 对开发者友好的扩展点** **`IntelligentMemoryPlugin**` 抽象接口 + `EbbinghausIntelligencePlugin` 默认实现，提供 `on_add` / `on_get` / `on_search` 钩子。要加新行为，写个 plugin 就行，不用 fork 核心。 **`AuditLogger`：默认开启，所有写操作记到 `./logs/audit.log`，用于合规追溯。`TelemetryManager**` 默认 opt-in 开启遥测。 ### **设计取向差异** - cortrix 走的是**对 LLM 友好的输出契约**（错误 + 证据链）——面向 Agent 消费 - powermem 走的是**对开发者友好的扩展点**（plugin + 审计）——面向人类调试 前者把「LLM 能不能用得好」当一等公民；后者把「开发者能不能改得动」当一等公民。 ## **九、基准：BEIR 全量语料 vs LOCOMO 87.79%** 两个项目都跑了基准，但维度完全不同——**对比时要小心**。 |维度|cortrix|powermem| | --- | --- | --- | |基准|BEIR 三数据集（SciFact / FiQA / NFCorpus）|LOCOMO + AppWorld| |测什么|文档检索质量（Recall / nDCG）|端到端 Agent 任务| |指标|全量语料上的硬指标|87.79% 准确率 / 39% pass| |基线|无基线（绝对指标）|有显式基线对比| |声明|「不代表回答质量，不代表生产性能」|「+65.9% / +62.5% 提升」| ### **基准差异的根源** - cortrix 想证明的是**检索质量**（数据库角度） - powermem 想证明的是**记忆系统能不能让 Agent 真的多答对题**（产品角度） 这反映了两个项目的目标客户不一样：cortrix 服务的是「要替换向量库的工程师」，powermem 服务的是「要给产品加记忆层的应用开发者」。 你跑 BEIR 找不到 powermem，跑 LOCOMO 也找不到 cortrix。这是**测的东西根本不同**，不是谁更优。 ## **十、选型：给你三条具体建议** 如果让我基于源码看完给建议，会是这样： ### **选 cortrix 的场景** - 你需要**本地优先**部署（数据不出本机） - 你**能接受 AGPL-3.0** 协议（或用商业许可） - 你愿意**自己编译 C++** 二进制并集成到现有栈 - 你对**检索质量有硬指标要求**（BEIR 风格） - 你**不急着上生产**（v1.0.0-rc.1，鉴权/多租户还 Blocked） ### **选 powermem 的场景** - 你已有 **OceanBase / PostgreSQL / SQLite** 集群，要给现有应用加记忆层 - 你需要**商业可集成**（Apache-2.0） - 你想要 **Skills / 经验蒸馏**，让 Agent 越用越聪明 - 你**已准备好接 LLM**（默认 Qwen，也支持 OpenAI/Anthropic） - 你需要 CLI 调试或多 IDE 插件 ### **都不选的场景** 你需要的是**鉴权 / 多租户 / 生产 SLA**。 两个项目都还在这块补课： - cortrix 的 `RBAC 与租户隔离` 标 `Blocked`，README 自己写「在当前关闭鉴权的本地运行时中根本无法证明」 - powermem 的多智能体隔离在 `src/powermem/agent/abstract/` 抽象层，ManagerType 有 `multi_agent / multi_user / hybrid` 三种，但生产化程度不深 ## **最后** 把两个项目放一起看，最大的收获不是「选哪个」，而是看到**同一类问题有两种完全不同的解法**。 cortrix 押注「**底座**」——把一个能力极致的存储做透，让所有上层应用都建在它上面。代价是封闭、AGPL、自己编译。 powermem 押注「**中间件**」——把所有能用的数据库适配成统一接口，让记忆层可以被任何应用叠加。代价是抽象成本、多后端语义差异。 两条路都对。区别在于你的起点：你是「没有数据库想找一个」，还是「有数据库想加一层记忆」。 如果这篇对比让你对 Agent 记忆基础设施的工程取舍有更具体的理解，欢迎在评论区说说你选哪个、为什么。 --- **项目地址**： - cortrix: https://github.com/cortrix/cortrix（AGPL-3.0-only，v1.0.0-rc.1） - powermem: https://github.com/oceanbase/powermem（Apache-2.0） > 本文基于对 cortrix `src/` 6.4 万行 C++ 源码与 powermem `src/powermem/` 5 万行 Python 源码的实际探查写成。对比维度涵盖定位、技术栈、接入路径、存储、检索、记忆模型、生命周期、可观测、基准、选型。两个项目都还在快速演进，所述状态以写稿时（2026-07）的最新发布版本为准。
