// tier: helix-primary · order 6

HelixMemory betalicense: TBD

GoMem0CogneeLettaGraphitiPostgreSQLNeo4jRedisPrometheus

Source

HelixMemory — four engines, fused AI Application MemoryStore interface Mem0 fact extraction Cognee semantic graph (ECL) Letta stateful runtime Graphiti bi-temporal graph Fusion Router classify + route Collect Deduplicate Cross-source Re-rank Unified Result one ranked memory Circuit breakers closed→open→half-open
// architecture

AI 智能体的单一记忆大脑——四大顶尖引擎融合一体

HelixMemory 是一款 Go SDK 系统，将四大领先记忆系统（Mem0、Cognee、Letta、Graphiti）整合为单一认知记忆引擎，并行搜索并融合结果。它为 AI 应用提供一个持久、去重、重新排序的统一记忆层，取代四个相互独立的记忆系统。

HelixMemory 是一款 Go SDK 系统，将 Mem0、Cognee、Letta 和 Graphiti 融合为一个统一的认知记忆引擎，专为 AI 应用设计。它智能路由写入操作，并行搜索所有后端，并通过三阶段"收集-去重-重排"流水线融合结果。

HelixMemory 是一款面向 AI 应用的统一认知记忆引擎，以 Go SDK 形式提供（模块 digital.vasic.helixmemory，Go 1.25+ 版本）。其核心理念在于：没有任何单一记忆项目能在所有方面都做到最优——因此，与其从零重新实现记忆系统并继承某一项目的局限性，不如协调四大顶尖系统，让每个系统发挥所长：Mem0 负责动态事实提取与偏好管理，Cognee 用于通过 ECL 流水线构建的语义知识图谱，Letta 提供具备可编辑记忆块和休眠时计算能力的有状态智能体运行时，Graphiti 则是一个能推理事实随时间变化的双时态知识图谱。

融合引擎将这四个独立存储系统转化为一个统一的"大脑"。在写入路径上，每条传入的记忆内容都会根据内容分类，并路由至最适合存储的后端。在读取路径上，查询请求会并行分发至所有后端，原始结果随即进入三阶段融合流水线——收集、去重、跨源重排——调用方无需面对四组嘈杂且重叠的结果集，仅需处理一个经过清理和排序的统一答案。每个后端均由断路器封装，实现优雅降级：当某一引擎故障时，其断路器触发，剩余后端继续提供服务，而不会拖垮整个记忆层。由于该引擎实现了即插即用的 MemoryStore 接口，可直接替代普通记忆提供程序——无需重构调用方代码——且 Prometheus 指标暴露了路由与融合的内部细节，确保全面可观测性。

HelixMemory 原本是为 HelixAgent（更广泛的 Helix AI 集成系统）构建的记忆层，并将家族严格的"反虚假测试"原则延伸至记忆领域：内置挑战运行器在真实生产代码路径（路由、融合、翻译器、断路器）上运行，同时配对变异封装器故意破坏不变量，以验证测试在逻辑错误时确实会失败，从而确保测试套件通过时具有实际意义。

内容

AI 智能体需要长效、高质量的记忆系统，但当前生态却支离破碎——每个记忆项目（Mem0、Cognee、Letta、Graphiti）各有所长，却难以兼顾。HelixMemory 的诞生，正是为了让 HelixAgent 拥有一个统一的记忆平台，将各家之长融于一体，同时避免对任何单一系统的锁定。

它终结了非此即彼的选择。四套原本相互竞争的记忆系统，如今通过单一接口成为互补的后端——应用程序得以同时获得动态事实提取、语义知识图谱、有状态智能体记忆及双时态推理能力，且自动完成去重与跨源重排。以往不切实际的"选择哪种记忆引擎"的困境，在 HelixMemory 面前不再成立：你无需承担任何引擎的短板，也无需锁定某一系统，只需通过一个即插即用的 MemoryStore，便能同时享有所有优势。

  • 多后端融合（采集 → 去重 → 跨源重排）：返回单一排序结果集，而非将调用方绑定至单一存储。
  • 智能写入路由：根据内容分类记忆，并将其发送至最适合的引擎存储，确保数据精准落入对应系统。
  • 优雅降级：通过后端级断路器实现故障隔离——单个引擎失效不会致命，其余系统仍可正常服务。
  • 闲时计算整合（基于 Letta）：利用空闲时段重组记忆，而非仅在查询时处理。
  • 反虚假验证：通过生产代码挑战运行器，结合变异包装器（当不变量被篡改时必须失败），证明测试门槛并非同义反复，而是真正有效的检验。

  • 将四种异构后端整合为统一结果集：各引擎返回的记忆格式不一，简单合并会导致重复与排序失衡。解决方案是构建一个类型化融合引擎，跨源采集、去重重叠部分，并在统一标准下重排，同时通过测试断言融合计数不变量，确保合并过程不会悄然遗漏或重复计数。
  • 后端故障下的系统稳定性：单个记忆引擎不可用不应导致整个层级停摆。解决方案是引入后端级断路器，通过闭合 → 打开（触发故障阈值后） → 半开（超时后）的状态机制，隔离故障后端，并持续从健康后端提供服务，直至其恢复。
  • 验证记忆逻辑的有效性，而非仅编译通过：测试套件通过即绿不代表测试真正有效。解决方案是内置挑战运行器，驱动实际生产代码（路由、融合、转换、断路器），并配合变异包装器篡改不变量，要求测试必须失败，从而确保验证门槛并非同义反复，而是真正可靠的检验。

内容

  • Go（1.25+版）——单一的 SDK 核心及运行时。选择它的原因在于，跨四个后端的并行读取扩展属于并发问题，而 Go 的 goroutine 机制使其成本低廉，同时其接口类型（如 MemoryStore）为整个系统提供了统一的清晰接口，供调用方依赖。
  • Mem0——动态事实提取与偏好管理后端，用于处理"用户实际偏好/已浮现的事实"这一记忆切片。
  • Cognee——基于 ECL 管道构建的语义知识图谱后端，用于存储结构化、相互关联的知识，而非扁平化的事实。
  • Letta——具备可编辑记忆块及休眠期计算能力的有状态代理运行时后端，适用于需要持久化代理实时状态并在空闲时段进行整合的场景。
  • Graphiti——双时态知识图谱后端，用于推理事实及关系随时间变化的过程，而非仅关注其当前值。
  • PostgreSQL + Neo4j + Redis——后端实际运行的数据存储层，通过 make infra-start 命令启动，用于真实集成测试，确保测试套件运行于实时基础设施而非模拟环境。
  • Prometheus——通过融合管道集成的指标与可观测性工具，使路由及融合行为在生产环境中可度量，而非黑盒操作。
  • 国际化翻译接口——采用命名空间（helixmemory_）的字符串层，以便未来任何面向用户的层级均可实现本地化，无需对核心进行改造。

  • 状态：测试版。SDK 已实现功能，作为 HelixAgent 的记忆层构建。
  • 许可证：待定。通过 GitHub API 检查未发现 LICENSE 文件——未验证/未声明。
  • 显示名称"HelixMemory"对应代码库 memory。README 中引用的准确性数据均为上游供应商声明，而非 HelixMemory 的实测结果，此处不予列出。

优先级： Helix-主线。