别再给每个工具写记忆：Agent 记忆差在实时寻址

打开一个同时跑着 Claude Code、Codex、Cursor 和 CI 检查的工程仓库，你会看到一排互不相通的记忆文件：根目录放着 AGENTS.md 与 CLAUDE.md，.cursor/rules/ 下塞满 .mdc，本地还挂着 Anthropic 的 /memories 目录与 MCP 知识图谱 memory.jsonl。当 CI Agent 在凌晨排查出「数据库连接池超过 20 会触发死锁」并记入状态库后，第二天你在编辑器里唤醒另一个 Agent 改配置，它对昨晚的事故依然一无所知。

多 Agent 团队的记忆断层，靠再装一个向量插件或同步 Markdown 解决不了。单用户跨平台迁移需要的是「可导出（Export）」，而多工具并发协作真正卡脖子的是「跨工具实时寻址（Live Addressing）」与「写入者溯源」。只要不同工具还把项目经验锁在私有路径或无署名文本块里，团队每加一个 Agent，上下文漂移与隐性覆盖的风险就会翻倍。

本文面向混用 Claude Code、Codex、Cursor 及自定义 CI/Review Agent 的研发团队负责人与工具链开发者。我们将拆解 9 类主流 Agent 记忆形态的存储边界，对比离线导出与实时寻址的差异，并给出落地最小共享记忆信封（Envelope）的可复现步骤与避坑清单。

九种记忆形态为什么彼此无法互通

讨论结构化 Agent 记忆前，先排除两个常见混淆：长上下文窗口（Context Window）和常规 RAG 向量检索。上下文窗口只是单次会话的临时工作台；常规 RAG 负责静态文档的相似度召回，不处理「谁在何时修正了哪条判断」。Agent 记忆解决的是跨会话状态沉淀、作用域寻址与过期淘汰。

2026 年 11 月，LoreKit 作者 Mads Thines 在《An Open Agent Memory Format: What It Would Take》中盘点了 9 类主流记忆形态。放在「记忆单元、寻址方式、遗忘机制」三个维度下对比，就能看清它们为何无法互通：

这 9 类系统的壁垒，根源在于底层数据模型的三处分裂：

1. 最小颗粒度不同：Letta 把记忆看作定长文本块，Mem0 拆成单句事实，Graphiti 建模成带有效期的图谱边，指令文件干脆不切分单元。
2. 寻址坐标系不对齐：LangGraph 靠元组命名空间，Mem0 靠会话与用户 ID，文件型记忆靠磁盘路径。当 CI Agent 想把构建失败原因写给「当前仓库 feat/payment 分支」时，其他工具没有统一地址栏去订阅该位置。
3. 过期语义缺失：除 GitHub Copilot Memory（28 天过期加代码校验）和 Graphiti（维护事件发生时间 t_valid 与入库时间 t_created 双时间线）外，多数本地记忆既无 TTL，也无「取代旧结论（superseded）」标记。

为什么离线导出救不了多 Agent 并发

面对碎片化，社区在 2026 年推出了几套便携记忆方案：MacPaw Research 的 Portable Memory（.mem）定义了含 Markdown 与 JSON 的归档包，支持从 ChatGPT 导出并导入 Claude；Open Memory Protocol 打包成带 SHA-256 校验的 ZIP；Cognee 的 COGX 则把向量与图谱状态封装进签名的 SQLite 二进制文件。

这些方案解决的是单用户跨平台搬家（Export）。但在工程团队里，Claude Code、Codex 和 CI Agent 在同一小时内围绕同一代码库并发工作，没人会在切换终端时手动导出导入 ZIP 包。多 Agent 协作真正卡在跨工具实时寻址（Live Addressing）。

那么 MCP（Model Context Protocol）能顺手解决互通吗？不能。MCP 标准化的是调用传输层（The Call），没有标准化记录数据模型（The Record）。哪怕五个服务都暴露 memory_write 工具，一个接收 (entity, observations[])，另一个接收 (namespace[], key, value)，调用方仍要逐个写适配代码。

这与 2019 年可观测性领域的困境一致。当时 OpenTracing 与 OpenCensus 并立，直到合并为 OpenTelemetry 并划清四层边界，生态才真正收敛：

• 数据模型层：规定 Span 必含 trace_id、span_id、时间戳、状态码与键值属性。
• 语义约定层：约定通用属性名，不锁死扩展字段。
• 线路协议层：用 OTLP 规定序列化与传输，后端实现完全自由。
• 上下文传播层：用 W3C Trace Context 跨进程传递位置信息。

2026 年 10 月 22 日，Anthropic 将 Agent Skills 移交 Agentic AI Foundation（AAIF），统一了静态操作手册格式（详见《Agent Skills 移交 Agentic AI Foundation：编程 Agent 团队要改什么》）。但执行任务时动态产生的项目记忆，至今还没迎来它的 OpenTelemetry 时刻。

怎么在仓库里落地四要素共享记忆信封

截至 2026 年 11 月，业界尚无基金会发布强制性的 agent-memory/1.0 标准；LoreKit 提出的 agent-memory/0.1 也只是启发讨论的草案，LoreKit 自身只是众多 MIT 开源探索之一。但团队不必等标准定稿，参考 OpenTelemetry 分层思路，用「四要素信封 + 5 个原子操作」即可收拢跨工具记忆。

第一步：约定四要素记忆信封

不要让 Agent 往公共 Markdown 里追加无头无尾的段落。要求每条共享记忆包含 4 个核心要素：

schema: agent-memory/0.1
id: mem_01j9x8k2m4p7q9r3s5t7v8w0y2
key: db-pool-max-connections
address:
  org: acme
  repo: github.com/acme/payment-service
  branch: main
  scope: project
written_by:
  agent: github-actions-ci-agent
  model: claude-sonnet-4-6
  trust: verified-ci
created_at: 2026-11-07T02:14:00Z
updated_at: 2026-11-07T02:14:00Z
lifecycle:
  status: active
  ttl_seconds: 2419200
  supersedes: null
attributes:
  kind: constraint
  confidence: 0.92
  code_refs:
    - src/db/pool.ts:42
content:
  summary: PostgreSQL 连接池上限不得超过 20，否则高并发结算批次下会触发连接耗尽死锁。

1. 作用域地址（address）：通过 org、repo、branch 与 scope 提供实时寻址坐标，让工具精准拉取当前分支经验。
2. 唯一标识与键（id + key）：id 用于全局引用与替换链（supersedes）；语义化 key 支持对同一结论做幂等更新。
3. 写入者身份与可信度（written_by）：记录 agent、model 与 trust 等级，区分「CI 验证结论」与「单次会话猜测」。
4. 生命周期与属性（lifecycle + attributes）：维护 active、superseded、archived 状态与 ttl_seconds，并用 code_refs 绑定代码行。

第二步：收敛五个最小原子操作

无论底层用 SQLite、PostgreSQL 还是 JSONL，暴露给各 Agent 的 MCP 接口只需收敛为 5 个操作：

• write(record)：按 address 和 key 写入；替换旧结论时自动将旧记录标为 superseded。
• read(address, key | id)：精确读取单条记忆。
• list(address, filters)：按作用域和状态（默认 active）列出摘要。
• search(address, query, filters)：在授权作用域内检索，禁止跨项目全局混搜。
• archive(address, id, reason)：将过时记忆移出活跃集并保留审计轨迹。

第三步：按三层架构隔离静态指令与任务上下文

把所有信息都塞进动态记忆库同样会拖慢响应，稳妥做法是拆成三层：

1. 静态规范走技能层：编译命令与代码规范放在 SKILL.md 或 AGENTS.md。在 HiFox 中，可按技能文档导入含 SKILL.md 的技能包，将范围固定为组织、空间或 Agent，由平台管控编辑权限。
2. 跨工具经验走共享信封层：架构约束通过上述 5 个 MCP 操作读写，会话启动时只拉取当前 repo 与 branch 的 active 摘要。
3. 单次任务交接走任务时间线：多 Agent 协作（详见《AI Agent 交接：Agent 对 Agent 与对人》）中的排查过程属于任务级上下文。根据 HiFox 的《Agent 如何执行任务》，把任务派给不同电脑或 Runtime 上的 Agent 时，日志、评论与交付物直接沉淀在任务上。至于平台是否内置了 agent-memory/0.1 原生存储引擎，目前帮助文档未提及（待核实），团队可通过自定义 MCP 服务挂载。

共享记忆落地的三个高频坑

在相关的 Hacker News 讨论（175 分，33 个顶层讨论串）中，开发者指出了三个工程隐患：

1. 自动写入制造确认偏误：HN 用户 pessimizer 与 leptons 指出，让 Agent 每轮自动总结并写入长期记忆，会把未经验证的错误推断变成「可复现的确认偏误」，误导后续接手的 Agent。应对方法是：自主推断只能以低置信度（confidence < 0.7）和短 TTL（7 天）写入；仅通过测试或人工确认的结论才能升格为长期 constraint。
2. 并发静默覆盖与提示词注入：多个 Agent 共享写权限时容易静默覆盖前序约束；若抓取外部 Issue 的 Agent 被植入恶意指令并写入共享记忆，所有本地高权限 Agent 都会中招。因此 write 接口必须禁止物理覆盖，强制生成新 id 并填写 supersedes，同时限制外部读取类 Agent 的写权限。
3. 代码演进后的僵尸记忆反噬：代码重构后，指向旧行号的记忆会误导修改。应在 read 和 search 返回前用脚本校验 code_refs 指向的文件与行号是否大改，引用失效即自动降级。

结论与下一步行动

Agent 记忆层离它的「OpenTelemetry 时刻」，差的不是更复杂的向量算法或更大的 ZIP 导出包，而是一套让多工具按仓库实时寻址、按写入者追溯可信度、按代码变更淘汰过期结论的最小记录契约。

如果你的团队正在混用多个编程 Agent，本周即可按三步清理记忆孤岛：

1. 瘦身静态指令文件：删掉 AGENTS.md、CLAUDE.md 和 .mdc 里的临时排查记录，只留构建命令与目录约定。
2. 加上四要素信封：在内部 MCP 记忆服务中补齐 address、id/key、written_by 和 lifecycle 字段，拒绝无署名、无过期时间的裸文本入库。
3. 收敛任务级上下文：在 HiFox 中用任务承载多 Agent 协作的执行记录与交付物，配合受管技能下发静态规范，让动态记忆层只装值得跨任务复用的工程经验。