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+

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 多了一条「内嵌 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） 当默认融合策略。但走的路数完全不一样：

两个项目对 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

• 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 想证明的是记忆系统能不能让 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）的最新发布版本为准。