Memori 评测：把智能体行为变成可查询的长期记忆
Memori is agent-native memory infrastructure. A LLM-agnostic layer that turns agent execution and conversation into structured, persistent state for production systems. Built for enterprise, Memori works with the data infrastructure you already run, no rip-and-replace, and deploys across managed cloud, single-tenant cloud, VPC, and on-premises.
秒懂
- 它是什么？
- Memori 是一个与模型无关的智能体记忆层，通过 SDK 自动捕获对话与工具调用，并支持自带数据库（BYODB）与企业部署。本文基于公开文档分析其机制、上手方式与适用边界。
- 适合谁用？
- Memori 适合已经运行多个 LLM 智能体、且受困于会话间遗忘问题的团队，尤其是那些希望在不改动智能体代码的前提下获得结构化记忆，并愿意把记忆数据放在自己数据库里的企业。它不适合只需要简单键值缓存或单次会话内上下文的项目，也不适合尚未确定数据主权要求、希望一切开箱即用的个人开发者，因为云服务需要注册获取 API key，而 BYODB 模式需要自行准备数据库。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库最近一次提交在 12 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
智能体为什么需要专门的记忆层
大多数智能体框架默认是无状态的。每次对话结束，模型就忘记了刚才说过的话。OpenClaw 的文档里明确写道，代理在会话之间会忘记一切。这个问题在单轮问答中不致命，但一旦智能体要跨多轮维护用户偏好、跟踪任务进度，或者在企业场景中需要审计决策过程，无状态就成了硬伤。Memori 的切入点是把智能体的执行过程，包括对话、工具调用、决策和结果，转化成结构化的持久状态。它不是给模型加一个更大的上下文窗口，而是把记忆外置成可查询的存储。面向的对象很明确：正在生产环境中运行多个智能体、并且不想为每个模型或框架单独写记忆逻辑的工程团队。按 README 的说法，它同时兼容 TypeScript 和 Python SDK，也提供 OpenClaw 插件和 Hermes provider，说明它试图覆盖从个人网关到企业系统的不同接入点。
记忆捕获的机制：注册 LLM 客户端而非修改提示词
Memori 的核心机制不是靠提示词工程，也不是在每次请求前手动注入历史。从快速开始的代码看，它要求你先创建一个 Memori 实例，然后调用 .llm.register(client) 把现有的 OpenAI 客户端注册进去。注册之后，正常的 chat.completions.create 调用不需要任何改动，Memori 在后台自动捕获对话内容，并持久化。第二次提问时，它会自动召回相关记忆。另一个关键调用是 attribution(entity_id, process_id)，它把对话归属于某个实体和某个流程。这解决了多用户场景下的数据隔离问题：同一个智能体服务多个用户时，记忆必须按 entity 分开。README 没有透露具体的存储 schema 或召回算法，只说这是结构化的记忆。从架构角度看，这种设计把记忆的读写从应用代码中抽离，代价是你必须信任 SDK 的钩子能正确拦截所有 LLM 调用。如果应用里有绕过注册客户端的调用路径，那些对话就不会被记录。
部署选项：云服务与自带数据库 BYODB
Memori 提供两条明显的部署路径。第一条是 Memori Cloud，README 描述为零配置，注册后拿 API key 即可。第二条是 BYODB，即自带数据库，文档链接指向 memori-byodb，里面还专门提到 TiDB Zero 作为可丢弃的开发数据库。这种双轨策略对企业很实际：云服务适合快速验证，BYODB 满足数据驻留和合规要求。README 强调它不要求 rip-and-replace，意思是你可以保留现有的数据基础设施。但要注意，BYODB 不是默认选项，需要额外查阅文档，而且 README 没有列出支持哪些数据库，只说有 TiDB 的指南。这意味着在采用前，你必须确认自己的 PostgreSQL、MySQL 或其他存储是否在支持列表里。如果不在，BYODB 反而会引入新的运维组件，与它宣称的降低集成成本相矛盾。
LoCoMo 基准：用 721 tokens 换 87% 准确率
README 给出了具体的基准数据：在 LoCoMo 长对话记忆基准上，Memori 达到 87% 的总体准确率，平均每个查询只用 721 tokens，这大约是完整上下文足迹的 2.8%。它还声称相比 Zep、LangMem 和 Mem0，在减少提示词大小方面有优势，提示词体积比 Zep 小约 67%，上下文成本比全上下文提示低 36 倍以上。这些数字来自项目自己的评估，论文挂在 arxiv 上，但没有提供复现细节。作为技术编辑，我要提醒：基准结果不能直接等同于生产环境表现，因为 LoCoMo 是特定任务集，你的智能体交互模式可能完全不同。值得肯定的是，Memori 明确量化了 token 节省，这比那些只谈准确率的项目更有参考价值。但如果你需要严格的第三方验证，应该去读 arxiv 论文，而不是只看 README 的图表。
OpenClaw 插件与 Hermes provider：两种集成方式
Memori 不只提供 SDK，还针对两个具体智能体框架做了适配。OpenClaw 插件通过 openclaw plugins install @memorilabs/openclaw-memori 安装，然后 enable，再用 openclaw memori init 配置 API key、entity-id 和 project-id，最后重启网关。README 强调无需修改智能体代码或提示词，插件自动在每一轮后捕获结构化记忆，包括工具调用和决策。Hermes 则走另一条路：安装 hermes-memori 后，通过 hermes config set memory.provider memori 启用，它会在后台捕获完成的对话，并给 Hermes 提供显式的 memori_recall 和 memori_recall_summary 工具，让智能体自己决定何时召回。对比下来，OpenClaw 是自动捕获加自动注入，Hermes 是自动捕获加按需召回。这两种模式反映了记忆系统的一个核心设计选择：记忆应该被动影响上下文，还是由智能体主动查询。Memori 两种都支持，但你必须清楚自己用的是哪种，因为它们的上下文占用和延迟特征不同。
许可证与维护成本的现实问题
仓库的许可证字段是 NOASSERTION，但 README 顶部显示了 Apache 2.0 的徽章。这是一个需要警惕的不一致。NOASSERTION 意味着 GitHub 无法识别许可证文件，而 README 里的徽章可能只是宣传图。如果你打算在企业内部采用，必须先确认仓库里是否有 LICENSE 文件，并核对许可证类型是 Apache 2.0 还是其他。开源许可证直接影响你能不能用、改了能不能闭源分发。另外，仓库最近一次推送是 2026 年 9 月，而最近版本 v3.3.6 发布于 2026 年 5 月，中间有几个月间隔，但还在活跃开发。维护成本方面，Memori 的 Python 和 TypeScript SDK 需要跟随主版本更新，OpenClaw 插件和 Hermes provider 也是独立包，这意味着一个记忆层的变更可能要同步升级四个组件。若你只用云服务，升级负担较小，但 BYODB 模式下，数据库 schema 迁移可能由你负责，这部分文档没有说明，需要向维护者确认。
替代方案与适用边界
README 提到了 Zep、LangMem 和 Mem0 作为对比对象。Zep 也是一个记忆层，但它通常需要部署自己的服务端，而 Memori 的卖点是 BYODB 和云托管。LangMem 是 LangChain 生态的一部分，它绑定 LangGraph 的抽象，如果你的智能体已经用 LangChain 构建，LangMem 的集成成本可能更低。Mem0 则更偏向轻量级记忆 API，适合快速原型。Memori 的核心差异在于它试图与模型无关、框架无关，并且通过注册 LLM 客户端的方式工作，这比要求你重写记忆逻辑的方案侵入性更小。但这也意味着它依赖 SDK 的魔法，如果底层 LLM API 发生变化，比如 OpenAI 客户端版本升级，注册机制可能失效。Memori 不是万灵药，它解决的是跨会话记忆问题，而不是推理能力不足或工具调用错误。如果你的智能体本身逻辑有缺陷，记忆层只会把错误延续得更久。
编辑结论
Memori 适合已经运行多个 LLM 智能体、且受困于会话间遗忘问题的团队，尤其是那些希望在不改动智能体代码的前提下获得结构化记忆，并愿意把记忆数据放在自己数据库里的企业。它不适合只需要简单键值缓存或单次会话内上下文的项目，也不适合尚未确定数据主权要求、希望一切开箱即用的个人开发者，因为云服务需要注册获取 API key，而 BYODB 模式需要自行准备数据库。采用前应验证三件事：确认你的 LLM 调用路径能被 SDK 的 register 机制正确拦截，因为记忆捕获依赖这个钩子；检查 BYODB 支持的数据库列表是否包含你现有的存储，避免引入新的运维负担；最后，若你使用 OpenClaw 或 Hermes，先在小流量环境测试插件或 provider 的版本兼容性。Memori 的定位是记忆层而非完整框架，它的价值取决于你现有基础设施的配合程度，而不是它单独能做什么。
社区笔记