AI-Memory（Memmy Agent）深度调研报告

调研对象：MemTensor / Memmy Agent
调研日期：2026-10-08（America/Los_Angeles）
核验代码版本：b9eee051f113aa3db113f20a829786ecd9415511
官方仓库：https://github.com/MemTensor/memmy-agent
官方网站：https://memmy.bot

一、执行摘要

用户所说的 AI-Memory，经项目描述、支持列表和源码结构交叉核验，高概率指 Memmy Agent。用户提到的 “Pineapple” 应是 Pi Agent：Memmy 官方列出的九个内置数据源恰好包括 Cursor、Claude Code、Codex、OpenCode、OpenClaw、Hermes、WorkBuddy、Pi 和 qwenwork。

核心判断

项目真实存在，而且不是概念 Demo。 它有完整的桌面端、CLI、本地 Memory Service、九类 Agent 读取适配器，以及 Claude Code/Codex 的 Hook、OpenClaw/Hermes 的 Memory Provider 插件。源码和测试能验证主要能力，并非只有 README 宣传。
“打通全部记忆文件”的说法不准确。 Memmy 不会让 MEMORY.md、CLAUDE.md、AGENTS.md 等原始文件彼此双向同步。它读取各 Agent 的本地会话记录和数据库，把完整对话 turn 归一化进自己的 ~/.memmy/memory-service/memory.sqlite，再通过 Hook、plugin 或 Skill 把相关记忆注入新请求。
它解决的是跨 Agent 的“经历连续性”，不是配置文件一致性。 Claude Code 里完成的任务可以被 Codex 或 OpenClaw 召回；但各 Agent 自己的身份、规则、原生 memory 文件仍然独立存在。
架构比普通向量数据库更完整。 它将记忆分为 L1 Trace、L2 Policy、L3 World Model 和 Skill 四层，组合向量检索、SQLite FTS5、短模式匹配、结构化错误片段、RRF、MMR 和可选 LLM 过滤，并带有反馈、奖励、抽象和 Skill 演化链路。
当前成熟度是“高潜力、快速迭代、仍属早期”。 仓库创建不到三个月，已达约 2,082 stars、200 forks、20 个 release、25 名贡献者；但提交高度集中在少数核心成员，公开独立用户反馈很少，且已有与 Codex 导入和 episode 恢复相关的实质性 bug。
对现有 OpenClaw 记忆体系存在冲突。 OpenClaw 只有一个 memory-provider slot。安装 Memmy 完整插件会把 plugins.slots.memory 指向 memmy-memory，可能替换现有 memory-lancedb-pro 等插件。对当前环境不应直接全量安装。
建议结论：值得做隔离试点，不建议立即成为主记忆系统。 最合适的第一阶段是“只读导入 + 手动检索”，先验证召回质量、重复率、隐私边界和 OpenClaw 配置兼容性，再决定是否启用自动注入与自动捕获。

综合评分：7.6 / 10。

维度	评分	判断
产品价值	9.0	跨 Agent 连续性是真实痛点
架构完整度	8.5	采集、归一化、分层、检索、演化、注入形成闭环
集成覆盖	8.5	主流 coding/personal agent 覆盖较广，但能力并不等价
工程成熟度	7.0	代码和测试规模可观，项目年龄仍短
隐私与安全	7.0	local-first、鉴权和脱敏做得不错，但不是完全离线
可运维性	7.0	有 CLI、日志、面板、fail-open；组件和后台服务较多
对现有 OpenClaw 的适配	6.5	可集成，但 memory slot 冲突必须先解决

二、项目身份与可信度

2.1 基本信息

截至本次核验：

指标	数据
GitHub 仓库创建	2026-07-16
最新稳定版	v1.2.0，2026-09-30 发布
Stars / Forks	2,082 / 200
Release 数	20
贡献者	25
主语言	TypeScript
许可证	MIT
仓库规模	GitHub 统计约 132 MB
TypeScript/TSX 文件	约 1,813
测试文件	约 825
GitHub Actions 工作流	6

这些指标说明它已经越过“周末项目”阶段。Memory、桌面端、本地后端、Agent Runtime、数据迁移、打包、Windows/Linux 验证均有独立模块。测试覆盖源适配器、Hook 安装、导入幂等、检索、记忆演化、服务生命周期和 release packaging。

但 star 数不能直接等价于真实生产采用。项目年龄很短，前五名贡献者贡献占比很高，尚未看到有分量的第三方基准、长期运行报告或安全审计。Hacker News 未检索到有效讨论，公开 Issue 当前也较少，因此“社区验证充分”这一结论不能成立。

2.2 名称消歧

市场上存在多个相似项目，例如 Memorix、Open Second Brain、AgentMemory、Hippo Memory。Memmy 的辨识特征是：

宣传语为 “Let every AI remember the same you”；
仓库为 MemTensor/memmy-agent；
内置支持 OpenClaw、Hermes、Claude Code、Codex 和 Pi；
同时提供个人 Agent Runtime，而不仅是 MCP memory server。

因此，本报告没有把泛称 “AI-Memory” 当作正式项目名，而是按 Memmy Agent 进行核验。

三、它到底如何“打通”不同 Agent

3.1 不是文件同步，而是中间记忆层

真实数据链路如下：

各 Agent 的会话 JSONL / SQLite / state.db
                ↓ 读取适配器、增量扫描、去重、脱敏
        Memmy 本地 Memory Service
  ~/.memmy/memory-service/memory.sqlite
                ↓ 检索、排序、上下文组装
       Hook / Memory plugin / Skill
                ↓
         当前 Agent 的新一轮请求
                ↓ 回合结束后自动捕获
           统一写回 Memmy

它的核心资产不是一个共享 Markdown 文件，而是一个统一 schema 的本地记忆数据库。每个导入记录保留来源 Agent，使搜索结果可以追溯到 claude_code、codex、openclaw 或 hermes。

3.2 历史导入

Memmy 对每个 Agent 提供读取适配器：

Agent	默认读取位置	实时能力
Claude Code	`~/.claude/projects/*/.jsonl`	Hook 自动召回、注入、捕获
Codex	`~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl`	Hook 自动召回、注入、捕获
OpenClaw	`~/.openclaw` 下 conversation / memory SQLite	Memory plugin
Hermes	`~/.hermes/sessions/*/.jsonl`、`~/.hermes/state.db`	Memory Provider plugin
Pi	`~/.pi/agent/sessions/*/.jsonl`	Skill 按需读写
Cursor	VS Code `state.vscdb`	主要为捕获和 resume，普通请求按需检索
OpenCode	`opencode.db`	Native plugin
WorkBuddy / qwenwork	各自 JSONL	Skill 按需读写

扫描过程以“完整 turn”为单位：一条用户消息开始，后续 tool/system/assistant 消息合并，必须有非空用户输入和最终 Assistant 输出。它用 conversation checkpoint、source message ID 和稳定 turn ID 去重，并为每个源维护独立时间水位线。超过 2 MiB 的单个完整 turn 会被跳过。

这说明它比简单的“遍历 Markdown 后 embedding”更严谨，但也意味着：

未完成或格式异常的会话可能无法导入；
Agent 上游格式一变，适配器就可能失效；
导入结果是重新解释后的记忆，不是原文件的无损镜像；
附件正文和大块工具输出可能被截断、脱敏或跳过。

3.3 实时召回与捕获

不同 Agent 的集成深度并不相同：

Claude Code / Codex：在 UserPromptSubmit 之前召回并用 additionalContext 注入，Stop 时捕获回合。
OpenClaw：使用 before_prompt_build 注入，用 agent_end 捕获，并注册 memmy_memory_search/get/add 三个原生工具。
Hermes：作为 Memory Provider，通过 prefetch、sync_turn、on_memory_write 等接口深度集成。
Pi / WorkBuddy / qwenwork：只安装 Skill，由 Agent 主动调用 CLI，不等于每轮自动共享。
Cursor：当前 Hook 重点是自动捕获和 /memmy-resume，普通请求需要 Skill 按需搜索。

所以，“所有 Agent 都完全自动共享”也是过度表述。准确说法应是：九个内置源都能进入统一记忆库，但只有其中一部分具备双向、自动、实时的完整链路。

四、Memory 架构

4.1 四层记忆

层级	内容	生成方式
L1 Trace	请求、回答、工具调用、结果、错误、来源	回合捕获、历史扫描或显式写入
L2 Policy	触发条件、步骤、边界、验证和避错经验	从相似且有价值的 L1 归纳
L3 World Model	项目、环境和约束的稳定知识	从 L2 聚类抽象
Skill	可调用 SOP、步骤和验收条件	从合格 L2 结晶并验证

这套分层的真正亮点是，它试图把“检索旧对话”升级为“把经历压缩成策略，再压缩成世界模型和技能”。方向上接近人类记忆从情景记忆到语义记忆、程序记忆的固化过程。

但默认参数偏激进：L2 归纳、L3 抽象和 Skill 结晶的最低支持数均可低至 1。若上游模型误判，单次经历就可能被过早固化为规则。项目提供 gain、confidence、eta、归档阈值和反馈修正，但在真实长期使用中是否能抑制“错误经验自我强化”，目前缺少独立验证。

4.2 检索链路

一次召回包括：

意图判断，闲聊或 Memmy 元命令可跳过召回；
把请求生成语义 query、关键词、中文双字短模式和错误/路径结构片段；
并行执行向量、SQLite FTS5、pattern 和 structural 检索；
通过 layer quality、时间衰减和 RRF 合并；
相对阈值、去重、episode rollup 和 MMR 多样性筛选；
可选 LLM 过滤；
以“历史信息、需结合当前事实核验”的形式注入上下文。

优点是：对中文、代码、文件路径和错误码，不完全依赖 embedding；向量服务失败时，全文和结构检索仍可工作。问题是链路较长，默认启用摘要、embedding、reflection 和 LLM filter，会引入模型费用、延迟和更多不可观测误差。

另一个重要限制是，本地 SQLite 向量检索目前先从符合层级/字段的最新 2,000 条向量记录构建搜索窗口，再交给 sqlite-vec 取 Top K。这个固定窗口在小规模个人使用中足够，但在多年、多 Agent、高频工作流中可能让更老但高度相关的记忆失去进入候选池的机会。

五、安全与隐私

5.1 做得好的部分

默认数据目录统一在 ~/.memmy，Memory 主库为本地 SQLite；
Memory Service 默认监听 127.0.0.1:18960；
Memory API 可用 bearer token，桌面本地 API 使用独立 token，Composio MCP bridge 又使用另一 token；
配置支持 ${ENV_NAME}，避免 API Key 明文写入主配置；
历史扫描会脱敏常见 OpenAI、Anthropic、Google Key、Bearer token、password、SSH private key 和 Base64 长串；
安装包下载有 SHA-256 校验，并检查 tar 路径穿越；
Hook/plugin 采用 fail-open，Memory 服务故障不会阻断 Agent 主任务；
删除 Hook/plugin 与删除已导入记忆分离，避免卸载时误删数据库。

5.2 不能忽略的风险

“Local-first” 不等于“数据永不出机”

数据存储和扫描默认在本地，但摘要、reflection、L2/L3/Skill 演化、query rewrite 和最终 LLM filter 可以调用远程模型。使用 OpenAI、Anthropic、DeepSeek 等 API 时，相关对话或派生内容会发送给所选 provider。只有明确使用本地 embedding、本地推理并关闭账号云模式，才接近完全离线。

有分析数据上报能力

源码包含 installation ID、client ID、user ID、事件名及参数上报到 MEMMY_CLOUD_SERVICE/api/analytics/events 的实现。官方称“memory improvement program”由隐私设置显式开关控制，但基础产品分析事件与 improvement-tier 事件是两套概念。部署前应实际抓包，核验拒绝改进计划后的网络行为，而不能只依赖文档措辞。

脱敏规则不是 DLP

当前规则只覆盖部分典型 secret 格式。GitHub token、Slack token、AWS key/secret、私有数据库 URL、自定义 JWT、Cookie、客户数据和业务机密仍可能进入 Memmy，随后又进入远程摘要模型。对于科学仪器客户数据，这一点尤其重要。

记忆注入也是提示注入入口

项目使用 <memmy_memory_context> 和 <current_user_request> 区分历史与当前指令，这是正确防线，但不是安全隔离。被污染的旧会话仍可能包含恶意指令。跨 Agent 聚合扩大了单次污染的传播范围，应该对外部网页、邮件、附件产生的会话设置来源信任级别或禁止进入高层 Policy/Skill。

安装权限面较大

完整安装会修改 Claude/Codex/OpenClaw/Hermes 的配置、Hook、Skill、AGENTS/CLAUDE/SOUL 文件，并运行常驻服务。Linux 安装器还会安装 Computer Use 依赖。虽然安装逻辑做了 checksum 和回滚设计，但这不是一个“无侵入插件”。

5.3 安全判断

目前没有发现明显恶意代码或刻意外传会话正文的证据；安全工程质量高于普通早期项目。但在处理私密客户数据前，仍需要：

关闭账号云模式和 improvement program；
使用本地 embedding，并确认摘要/演化模型的数据边界；
对网络域名做 allowlist 或抓包验证；
扩展 secret/PII redaction；
限制哪些 source 可进入 L2/L3/Skill；
加密磁盘并保护 ~/.memmy 目录权限和备份。

六、已知问题与成熟度信号

正向信号

20 个版本在约两个半月内快速发布；
主要 integration 不只是文档声明，存在独立 adapter、installer、template 和 test；
导入有水位线、checkpoint、stable ID 和幂等设计；
OpenClaw/Hermes 都显式检测唯一 memory provider 冲突，而非静默覆盖；
配置和运行时文件采用原子写入、token、loopback 限制和 health check；
有完整 Memory Viewer，可检查候选、LLM 丢弃项和实际注入 ID，具有一定可解释性。

负向信号

公开 Issue 已出现两个直接影响核心价值的问题：

#530：Codex 首轮 harness 前言被错误识别为用户问题，导致 trace/episode 标题异常且无法召回；
#531：历史扫描的 L1 未带会话信息、不生成 episode，报告者称本机约 92% L1 受影响，导致 /memmy-resume 无法正常续接。

这两个问题说明最困难的部分不是向量检索，而是准确解析不同 Agent 持续变化的会话协议，并保留 episode 语义。这也是所有跨 Agent memory 产品的结构性风险。

公开 issue 样本较少，而且最近 100 个 issue/PR 条目中绝大多数是 PR，无法据此计算可靠的用户故障率。版本迭代快既说明团队响应快，也意味着 API、数据 schema 和安装行为仍可能频繁变化。

七、与主要替代方案的区别

项目	核心定位	优势	相对 Memmy 的不足/不同
Memmy Agent	跨 Agent 本地记忆中心 + 独立 Agent Runtime	原生扫描多种历史格式；四层记忆；深度 Hook/plugin	复杂、年轻、侵入配置、存在 slot 冲突
Memorix	MCP 型跨 Agent memory layer	更轻、生态覆盖广、MCP 方式标准化	对既有历史库的自动扫描和深层 Agent 集成弱于 Memmy
Open Second Brain	Obsidian-first 第二大脑	Markdown 可见、可编辑、审计友好	自动化、分层演化与原生历史解析较弱
AgentMemory	通用持久记忆与 benchmark 导向	社区规模大，定位通用	不以本机多个 Agent 历史“汇流”为唯一核心
Hippo Memory	coding-agent 本地长期记忆	轻量、专注开发工具、local-first	产品面和 personal-agent 能力较窄
OpenClaw 原生 memory + workspace 文件	单 Agent 内的可控记忆	简单透明、与现有工作流融合最好	Claude/Codex/Hermes 的会话不会天然汇入

Memmy 的差异化不在“有向量数据库”，而在为每个主流 Agent 维护读取适配器与实时写回桥接。这也是它最有价值、同时维护成本最高的部分。

八、对当前 OpenClaw 系统的适用性

8.1 价值

当前 OpenClaw 已有 MEMORY.md、daily notes、TEAM_MEMORY、wiki、Agent workspace 和 memory-lancedb-pro。Memmy 能补齐的是：

把 Claude Code、Codex、Hermes、Pi 中发生但未沉淀进 workspace 的过程找回来；
在更换 coding agent 时延续任务背景；
从失败回合中抽取跨工具可复用经验；
用统一界面审计不同 Agent 的历史和召回情况。

8.2 重叠与冲突

它也会与现有系统发生明显重叠：

Memmy L3 World Model 与现有 MEMORY/wiki 重叠；
Memmy Skill 演化与 OpenClaw skills 重叠；
自动写 AGENTS.md/SOUL.md 与现有受控规则文件冲突；
OpenClaw 的 plugins.slots.memory 只有一个，Memmy 不能与现有 memory provider 同时完整占位；
双重自动捕获可能产生重复、循环召回和上下文膨胀；
Memmy 的“模型归纳规则”不符合当前“稳定规则经人工晋升”的治理原则。

8.3 推荐边界

对当前系统，Memmy 更适合当作 跨 Agent 原始经历索引层，而不是新的最高记忆权威：

Memmy：跨 Agent 会话、失败、执行轨迹、可搜索经历
memory/daily：跨会话连续性和近期事实
wiki：经过提炼的长期知识
AGENTS/TOOLS/SOUL：人工确认后的稳定规则

不要让 Memmy 自动生成的 L2/L3/Skill 无审查地反向覆盖 AGENTS.md、SOUL.md 或团队知识库。

九、建议的隔离试点

阶段 0：不安装，先备份和建基线

备份 ~/.openclaw/openclaw.json、当前 memory provider 配置及 workspace 规则文件；
记录 Claude Code、Codex、OpenClaw 各 20 个代表性任务作为召回测试集；
明确禁止导入的客户目录和 session；
记录当前 OpenClaw memory 的准确率、延迟和 token 消耗。

阶段 1：只启 Memory Service，不接管 OpenClaw slot

从源码或固定版本安装，不使用浮动 latest；
使用单独测试用户目录和独立 MEMMY_HOME；
关闭云账号模式、improvement program、自动连接新 Agent；
先只导入 Codex 与 Claude Code 的非敏感测试会话；
仅用 memmy-memory search/get 手动检索，不启自动 prompt injection。

验收指标：

指标	建议门槛
Top-5 相关召回率	≥ 80%
错误/污染记忆率	≤ 5%
重复记录率	≤ 3%
P95 手动检索延迟	≤ 1.5 秒（不含远程 LLM filter）
敏感信息漏检	0 个高危样本

阶段 2：单一 coding agent 启用 Hook

优先选择 Codex 或 Claude Code，不先动 OpenClaw。观察两周：

自动注入是否真正提高任务续接质量；
是否把 harness/system 前言误当作用户记忆；
每轮额外 token 和延迟；
fail-open 是否稳定；
卸载后配置能否完整恢复。

阶段 3：再评估 OpenClaw

只有在阶段 2 达标后，才选择以下两种路径之一：

保守方案，推荐：保留现有 OpenClaw memory provider，只安装 Memmy Skill，按需搜索共享库；
激进方案：在隔离 OpenClaw profile 中让 Memmy 接管 memory slot，与现有 provider 做 A/B 测试。

不建议直接在当前生产 Zen 环境替换 memory slot。

十、最终判断

Memmy 抓住了一个正在迅速变大的问题：当一个人同时使用 Claude Code、Codex、OpenClaw、Hermes、Cursor 等工具时，真正稀缺的不是模型能力，而是跨工具连续存在的个人上下文。

它的技术路线是可信的，源码也证明它已经实现主要链路。它最值得肯定的地方，是没有停留在 MCP key-value memory，而是进入各 Agent 的真实本地历史格式、回合生命周期和原生 Hook/plugin 接口。

但它并没有真正“统一所有记忆文件”。它新建了第五套、更高一层的记忆系统。这样能解决信息孤岛，也会新增数据治理、提示污染、模型费用、配置冲突和单点依赖。对于已经有成熟记忆治理的 OpenClaw 环境，最大的风险不是装不上，而是形成两套同时自我演化、互相注入的记忆体系。

决策建议：列为高优先级试验项目，以只读、隔离、可回滚方式验证；暂不替换现有 OpenClaw 主记忆。 如果两周测试证明跨 Agent Top-5 召回率稳定、无敏感信息外泄、无明显上下文污染，再把它定位为“跨 Agent 事件层”，而不是“唯一真相源”。

十一、主要来源

L1：官方资料

GitHub 仓库：https://github.com/MemTensor/memmy-agent
官方文档：https://memmy.bot/docs/
README：https://github.com/MemTensor/memmy-agent/blob/main/README.md
Memory 工作原理：https://github.com/MemTensor/memmy-agent/blob/main/docs/en/memory/overview.mdx
Agent Sources：https://github.com/MemTensor/memmy-agent/blob/main/docs/en/memory/sources.mdx
Security & Privacy：https://github.com/MemTensor/memmy-agent/blob/main/docs/en/security/security.mdx
Release 列表：https://github.com/MemTensor/memmy-agent/releases
MIT License：https://github.com/MemTensor/memmy-agent/blob/main/LICENSE

L2：源码与 API 核验

OpenClaw 集成：Memory/src/agent-source/integration/openclaw/target.ts
Hermes 集成：Memory/src/agent-source/integration/hermes/target.ts
Secret redaction：AgentSourceCore/src/secret-redactor.ts
Analytics transport：App/backend/src/analytics/analytics-transport.ts
Runtime installer：Memory/src/cli/runtime-installer.ts
GitHub Repository API：https://api.github.com/repos/MemTensor/memmy-agent

风险与用户反馈

Codex 首轮解析问题：https://github.com/MemTensor/memmy-agent/issues/530
episode / resume 导入问题：https://github.com/MemTensor/memmy-agent/issues/531

置信度说明

架构、支持列表、安装行为、存储位置：高置信，已由官方文档与源码交叉验证；
社区采用与长期稳定性：中低置信，项目较新且第三方材料不足；
安全判断：中等置信，完成静态源码抽查，未进行运行时抓包、渗透测试或完整依赖审计；
实际召回质量：未验证，需要按第九章进行本机 A/B 测试。

AI-Memory（Memmy Agent）深度调研：跨 Agent 记忆打通的真实能力与边界