智能体记忆需要它的「OpenTelemetry 时刻」：盘点 9 种记忆格式，提议一个跨工具共享的记录规范

每个智能体工具都用自己的形状来存记忆，而且每周都有人再造一个。它们谁也读不了谁的。可观测性领域曾经也是这样，直到 OpenTelemetry 给了大家一个共享的数据模型。本文盘点今天的记忆格式、已经存在的提案，以及一个共享规范可能长什么样。

把你的编码工具里所有「记住」东西的地方列出来。今天一个典型的配置是：

• 大多数仓库里有一个 AGENTS.md 或 CLAUDE.md，少数仓库里还有 .cursor/rules/*.mdc
• 一个通过 Anthropic 的 memory 工具往 /memories 目录写文件的智能体
• Copilot 在 GitHub 那一侧为每个仓库保存的事实
• 一个用 JSONL 知识图谱保存记忆的 memory MCP 服务器

这是四种不同的形状，谁也读不了谁。你的 CI 智能体学到的一条经验，只留在写下它的那个工具里。你的编辑器智能体读不到，你下一个要试的工具也读不到。

每种格式单独看都合理。放在一起，它们却一遍又一遍地重造同一个小想法：智能体留给未来自己的一张便条，存在某个地址上，在一段时间内成立。

而且这个列表还在变长。去逛逛 r/ClaudeAI、r/LocalLLaMA 或 r/cursor，你会看到源源不断的「我给我的智能体做了个记忆层」帖子，每个都有自己的存储、自己的 schema 和自己的 MCP 工具。这很好地证明了问题是真实的：人们被它折腾得够呛，才会动手造东西。但每个新方案都多加了一种别人读不了的格式。问题不在于缺工具，而在于缺共识，而共识只能来自社区一起来做。

我自己做其中一个工具，叫 LoreKit，是开源的。这不是在推销说 LoreKit 已经解决了记忆问题。它的格式只是若干提案之一，也有自己的缺口。重点在于，现在正是就一个共享形状达成一致的时机，而另一个领域已经示范过怎么做。

2019 年以前，每家可观测性厂商都发布自己的 agent、自己的埋点库和自己的数据格式。换厂商就意味着重新给代码埋点。两个开源项目 OpenTracing 和 OpenCensus 试图解决这个问题，彼此之间也在竞争。

2019 年它们合并成了 OpenTelemetry。关键在于厂商们同意不再在哪些方面竞争：

• 数据模型：span、metric 和 log record 分别是什么。
• 语义约定：共享的名字，比如 service.name 和 http.*。
• 协议：OTLP，一种发送数据的方式。
• 参考实现：共享的 SDK 和 Collector。

厂商们继续在如何处理数据上竞争：存储、查询、分析。用户只需埋点一次。我每天在 Dash0 跟 OpenTelemetry 打交道，正是这份共识让整个工具生态能互相读取数据。

智能体记忆现在正处在可观测性 2019 年之前的位置。时机很好：这些格式还年轻，来得及改，而且智能体标准已经有了一个中立的归宿。MCP 和 AGENTS.md 都归在 Linux 基金会的 Agentic AI Foundation 之下。

今天的格式

这些东西变化很快，请把细节当作 2026 年末的一张快照。

其中有几个做对了某些事，值得共享规范保留。Copilot Memory 把可以对照代码核验的引用和默认遗忘结合起来，只是被锁在一个产品里。LangGraph 说明核心可以有多小：put(namespace, key, value)。Graphiti 正确地建模了时间，分开记录事实何时为真、何时被记录。而 AGENTS.md 说明，放在已知路径上的一个普通文件也能变成标准。

已经有几个人开始做这件事。MacPaw Research 的 Portable Memory 是一种 .mem 包，有字节级可复现的序列化、删除墓碑和可选签名；作者说它还没有被广泛采用。Open Memory Protocol 是 2026 年 4 月的一份草案，用带 manifest 的 ZIP 在平台之间迁移对话以及从对话中提炼出的记忆。Cognee 的 COGX 格式可以从 Mem0、Letta 和 Zep 导入。

这些方案大多解决的是导出：把一个人的记忆从厂商 A 搬到厂商 B。编码工具还有第二个尚未解决的问题：实时寻址。当一个 CI 任务、一个编辑器智能体和一个评审机器人同时在同一个仓库里工作时，它们怎样读写同一个位置，并对其含义达成一致？一个完整的规范两者都需要。

剥掉品牌，每种格式都在用不同方式回答同样四个问题：一条记忆在哪里成立；它的身份是什么（第二次写入是更新它还是复制一份？）；它说了什么；以及它何时不再成立。没人否认这些问题重要。工具们只是在答案上有分歧，而 OpenTelemetry 当初也是从这里起步的。

真正的分叉只有一个：谁来写记忆。在指令文件里是人。在 memory 工具、Letta 和 LoreKit 里是模型。在 Mem0 和 Graphiti 里，是一个服务从对话里抽取事实。规范不需要三选一，它需要记录是哪一种，好让读者知道该多信任读到的内容。

下面大致是一条记录作为文件可能的样子。它用来说明数据模型，字段名并不是提案：

---
spec: agent-memory/0.1
id: 8f0c2a6e-4b1d-4c7a-9e2f-3a5b6c7d8e9f
address: { level: repo, value: github.com/acme/checkout }
key: tests-need-local-postgres
kind: lesson
written_by: { type: agent, name: claude-code }
content_type: text/markdown
lifecycle: { expires_at: null, extended_by: write }
attributes: { vcs.pr: 482, ci.run_url: "https://ci.example/runs/123" }
---
Integration tests fail with `ECONNREFUSED 127.0.0.1:5432` unless Postgres
is already running. Start it before `pnpm test`:

    docker compose up -d db

The test setup does not start it for you.

（正文大意：除非 Postgres 已经在运行，否则集成测试会报 ECONNREFUSED 127.0.0.1:5432。在 pnpm test 之前先用 docker compose up -d db 启动它；测试初始化不会替你启动。）

frontmatter 是信封：address 和 key 说明它在哪里成立，id 是它的身份，lifecycle 说明它何时失效，written_by 回答了上面那个分叉。下面的 Markdown 才是记忆本身，content_type 告诉读者该如何对待它。工具需要的其他任何东西都放进 attributes，挂在其他工具可以忽略的命名空间下。同一条记录也能同样好地序列化成 JSON，供想通过网络发送它的工具使用。

围绕这条记录，规范可以照搬 OpenTelemetry 的分层：

• 约定：在一个带版本的注册表里，为地址层级（global、project、repo、branch，以及 monorepo 需要的任何层级）、类别和属性命名空间（vcs.、ci.、agent.*）定下共享的名字。
• 契约：少数几个操作（write、read、list、search、archive），输入输出固定，通过 MCP 暴露。现在很多记忆服务器都提供 MCP 接口，但每个暴露的工具不同、含义也不同。
• 用一致性测试代替参考实现：把一条记录往返一遍，检查没有丢东西；检查未知属性在重写后仍然保留；检查过期行为与声明一致。

不放进去的东西同样重要：存储、排序、嵌入、用户界面。工具应该在这些地方竞争。而且规范应该放在中立的地方，而不是 LoreKit 的仓库或任何单一厂商那里。

「你做记忆工具，当然想要一个长得像你家的标准。」说得对。所以 LoreKit 只是表格里的一行，而不是模板。如果共享规范长得不一样，LoreKit 也应该照样采用。

「MCP 已经是标准了。」MCP 标准化的是调用，不是记录。OpenTelemetry 既需要协议也需要数据模型，记忆同样两者都要。

「共享记忆是一条提示注入通道。」是的。智能体读到的任何东西都可能操纵它，而共享记忆扩大了有权写入的人群。规范应该把这一点摆到明处：记录每条记忆是谁写的，允许签名（Portable Memory 已经支持），并让记录可以指向它所依赖的代码，好让读者检查那段代码有没有变。没有哪种格式能让投毒变得不可能。

「再来一个标准也解决不了碎片化。」这就是 xkcd 927，也是最有力的反对意见。我的回答和 OpenTelemetry 一样：共识来自现有项目的合并，而不是有人再加一个。这里的工作也一样：把现有提案和工具各自做对的部分拿过来，就它们共有的部分达成一致。

这些问题我不知道答案，宁愿公开地一起解决：

• 要有哪些地址层级？monorepo 想在 repo 和 branch 之间再加一层。层级应该是固定列表还是约定？
• 遗忘应该是默认行为吗？Copilot 默认遗忘，LoreKit 不会，LangGraph 在读取时延长寿命。
• 记录应该指向它依赖的代码吗？这是防止记忆过时的最好办法，但会把记录绑定到某个代码托管平台。
• 谁来协调？一个工作组、一个基金会，还是一份大家提交修改的草案规范？

如果你在做表里的任何一个工具，或写过其中某份提案，我很想交流一下。LoreKit 的 schema 和磁盘格式以 MIT 许可开放，作为一份具体的参考输入。想看真实的记录，LoreKit 的离线存储写的是普通 Markdown 文件，可以直接打开、grep 和 diff：

npx @lorekit/cli install

把它们和你其他工具写下的东西比一比，然后告诉我：一个共享格式还需要哪些它们都还没有的东西。