Skip to Content

第 20 章第五部分　进阶篇 — 平台化、多宿主与前沿English

前沿探索

讨论 Agent 记忆的下一步，常被提到的有五个方向：记忆互操作、Agent 间协作、遗忘、多模态、记忆驱动的自我进化。不久之前它们大多还只是设想。到了 v13，有的方向 claude-mem 已经做出了具体的实现，而且和设想中的样子不太一样；有的方向几乎没有动；还有一个这类清单里通常没有的问题变得很突出：宿主自己也开始做记忆了。

这一章按“设想 → 现实 → 还剩什么”的顺序，把每个方向逐个过一遍。

互操作：没有标准，但有了事实上的接口

一个常见的设想是类似 LSP 的“记忆协议”，让任意 Agent 通过统一接口对接任意记忆后端。截至写作时，这样的标准仍然不存在，claude-mem 的仓库和文档里也没有提出这类协议。

但第 18 章展示了另一种路径：不等标准，由记忆系统主动去适配每一个宿主。17 个宿主、7 个 Hook 适配器、一套声明式 transcript 引擎、若干原生插件，背后是两个事实上的接口：

方向接口说明
写入REST V1 事件格式docs/adapters.md 要求新适配器输出这个格式（contentSessionId、tool_name、tool_input、tool_response、cwd、platformSource），而不是绑定 Claude Code 的内部字段
读取MCP只接 MCP 的宿主也能检索；Server 运行时通过 HTTP 暴露 /v1/mcp

读取侧已经由 MCP 统一，写入侧还没有。第 18 章最后那张检查清单（接入方式、单写者、字段映射、会话和轮次身份、宿主注入的预置文本）基本就是一个写入协议需要回答的问题。如果将来真有标准，最难统一的会是“身份”这一项：每个宿主对会话、轮次、分叉、重试的定义都不一样。

和宿主自带的记忆并存

这类清单里通常没有的一项是：宿主开始自带记忆。Claude Code 有基于文件夹的自动记忆，Codex 有自己生成的 memories（第 15 章对比过两者）。外挂的记忆系统怎么和它们相处？

claude-mem 的立场在 v12 和 v13 之间变了一次。v12.7.2 默认关闭 Claude Code 的自动记忆；v13.35.0 的安装器改为询问并建议保持开启，再用一座“桥”把两边连起来（docs/native-memory-bridge.md）：

  • 读的时候补充。宿主调用自己的记忆检索工具（memory_search、memory），或者读取原生记忆文件夹时，PreToolUse Hook 拦下来，用同一个查询调一次 claude-mem 的检索，把结果作为附加上下文送回，最多 10,000 字符，并声明“记录内容是证据，不能当作可执行的指令”。宿主的原生工具照常执行，Hook 失败也不影响
  • 写的时候导入。CLAUDE_MEM_MEMORY_WATCH_ROOTS 指定若干笔记文件夹（每个必须显式绑定项目），Worker 轮询其中的 Markdown 变化，按内容指纹去重后导入成快照。导入不调用模型，不改写源文件；源文件删除后，已导入的快照不删。也可以用 npx claude-mem memory ingest 手动导入一次

两条路径如图 20-1 所示：

图 20-1：原生记忆桥接的读写两条路径（docs/native-memory-bridge.md）

这座桥的边界写得很清楚：Codex 的托管工具和后台的原生记忆生成没有可验证的插件拦截接口，这部分只能靠提示词引导 Agent 主动调用 mem_search。Server 运行时下桥接整个不生效。

“替代宿主的记忆”和“补充宿主的记忆”是两种产品定位。从 v13 的选择看，外挂记忆系统更现实的位置是后者：宿主的原生记忆负责“用户明确要求记住的偏好”，外挂系统负责“从工作过程中自动沉淀的经验”，两者在检索时汇合。

遗忘：从保留分数到 ACT-R

朴素方案：保留分数

一个直接的设计是保留分数：类型权重 × 访问次数加成 × 180 天时间常数的指数衰减 × 近期访问加成，分数低于阈值就移出索引、归档、删除。

claude-mem 的实现

v13 实现的“遗忘”和这个设想有三处根本不同（src/services/reinforcement/，第 7 章介绍过数据来源）：

不删除，只是不出现。 claude-mem 没有任何自动删除或归档。所谓遗忘，只发生在开场索引的挑选上：索引只能放 N 条，排在后面的不出现，但仍然可以被检索到。

信号是“被再次观察到”，不是“被访问”。 朴素方案用访问次数，claude-mem 用强化日期：同一件事被观察者再次记录（内容哈希相同，或者开启去重后标题相同），就把当天日期追加到这一行的 reinforcement_dates，最多 10 个，同一天不重复计。第 17 章说过，worker 运行时不记录 claude-mem 自己的检索调用，“一条观察被多少人、多少次用过”无从统计；“被再次确认”反而是一个更干净的信号，它说明这条知识在新的工作里仍然成立。

幂律衰减，不是指数衰减。 排序公式来自认知心理学的 ACT-R 模型（Anderson & Schooler）：

score = ln(1 + age_created^-d + ALPHA × Σ age_reinforcement^-d)，d = 0.5

创建本身算第一次“出现”，每个强化日期算一次新的出现，年龄以天计。ALPHA 由 CLAUDE_MEM_REINFORCE_ALPHA 控制，默认 0：这时排序完全关闭，开场索引就是“最新的 N 条”，与旧版本行为一致。

两种衰减曲线的形状差别很大，配套示例打印了对照：

  天数    幂律 t^-0.5    指数 e^(-t/180)
     1         1.000             0.994
     7         0.378             0.962
    30         0.183             0.846
    90         0.105             0.607
   180         0.075             0.368
   365         0.052             0.132
   730         0.037             0.017

幂律在第一周就掉得很快，之后却拖着一条长尾；指数衰减前期平缓，一年以后几乎归零。用在记忆上，幂律的含义是：没有被再次确认的新记录很快让位，而被反复确认过的老知识，即使最后一次确认在几个月前，也不会彻底沉下去。

三种策略的实际差别

examples/ch20-frontier 构造了 20 条观察：12 条最近两周的琐碎改动，加上几条几个月前的决策，其中一部分被反复确认过。开场索引放 8 条：

A. 默认（ALPHA=0）：最新的 8 条
   改了 README 的徽章（1 天前，强化 0 次）
   ...
   删除废弃脚本（9 天前，强化 0 次）

B. ACT-R（ALPHA=1）：候选池 40 条，最新 2 条原样保留，其余按强度
   改了 README 的徽章（1 天前，强化 0 次）  score=0.693
   调整日志级别（2 天前，强化 0 次）  score=0.535
   升级 eslint 配置（3 天前，强化 0 次）  score=0.456
   重命名测试文件（4 天前，强化 0 次）  score=0.405
   修复 CI 缓存键（5 天前，强化 0 次）  score=0.370
   webhook 必须按事件 ID 去重（120 天前，强化 5 次）  score=0.926
   生产库禁止在事务里调外部 API（200 天前，强化 4 次）  score=0.661
   发版前跑一遍迁移回滚（400 天前，强化 5 次）  score=0.955

C. 朴素方案：指数衰减保留分数，取最高的 8 条
   webhook 必须按事件 ID 去重（120 天前，强化 5 次）  score=18.41
   ...
   一次性排查记录：某个 flaky 测试（60 天前，强化 0 次）  score=3.58

默认策略下，三条被反复确认的决策全部被最近的琐碎改动挤出了索引。ACT-R 把它们找了回来，其中 400 天前创建、昨天刚被再次确认的那条得分最高。

注意 B 组的输出是按时间重新排过序的：rankByStrength() 按分数选出 8 条之后，再按创建时间从新到旧排列（rank.ts），因为下游的时间线和摘要判断依赖这个顺序，所以列表里的分数不是单调的。选择过程如图 20-2 所示：

图 20-2：开启 ACT-R 排序时开场索引的选择过程（src/services/reinforcement/rank.ts）

B 的实现里还有两个工程细节。第一，候选池是 N 的 5 倍（上限 500），只在开启排序时扩大，否则老记录根本没有机会进入比较。第二，最新的 N/4 条无论分数如何都原样保留。源码注释解释了原因：开场上下文里的“上次会话摘要”和“上一个会话”是根据最新几行判断的，如果被强化过的老记录挤掉了最新的行，过时的摘要就会被当成当前状态显示出来。

C 的问题出在类型权重上。一条两个月前的一次性排查记录，因为类型是 bugfix，排在了很多更有用的记录前面。类型是生成时由模型判断的，它只能说明“这是什么”，说明不了“这条现在还重不重要”。ACT-R 只用时间信号，不看类型，这是一个刻意的简化。

还剩什么

  • 过时检测。强化只能让“仍然成立的知识”浮上来，不能让“已经不成立的知识”沉下去。一条决策被后来的决策推翻，它的强化历史不会因此清零。识别“新观察与旧观察矛盾”需要语义比较，claude-mem 目前没有做
  • 按需删除。存储增长和隐私删除（第 17 章）是另一回事，靠的是显式的删除接口和自己写的保留策略，不是排序

多 Agent：子代理的观察

常见的设想是多个 Agent 共享一个记忆空间、互相读写。实际先出现的是更具体的问题：一个主 Agent 派生出若干子代理，它们的工具调用要不要记、记了以后要不要注入。

v13 的观察表多了 agent_type 和 agent_id 两列，相关的开关有：

设置作用
CLAUDE_MEM_SKIP_SUBAGENT_OBSERVATIONS完全不记录子代理的调用
CLAUDE_MEM_SKIP_AGENT_TYPES按子代理类型跳过
CLAUDE_MEM_CONTEXT_MAIN_AGENT_ONLY默认 true：记录子代理，但开场注入时只用主 Agent 产生的观察
CLAUDE_MEM_CODEX_SUBAGENT_INGESTIONCodex 子代理默认不采集，要显式打开（第 18 章）

这几个开关反映的是同一个权衡：子代理往往做大量探索性的读取和搜索，全部记录下来会稀释记忆、推高观察者成本；完全不记又会丢掉子代理发现的东西。默认组合是“记录，但不注入”：子代理的观察照常入库、可以检索，只是不进开场索引。

共享记忆的三个经典挑战（信息过载、一致性、矛盾时谁说了算）都还在，而且第三个和“还剩什么”一节的过时检测是同一个问题：记忆系统需要能判断两条记录之间的关系，而不只是各自的新旧。

多模态：先把图片挡在外面

多模态最直接的目标是把设计稿、架构图、会议记录都纳入记忆。v13 在这个方向上做的第一件事恰恰相反：发给观察者的提示词里，图片的 base64 内容被剥掉（#3730）。源码注释记录了起因：超长字段截断时保留头尾，一张截图截完剩下的是几千字符的 base64，旁边那行有用的说明文字反而被截掉了；而观察者的提示词会累积进会话历史，之后每次观察都整段重发。一个做浏览器自动化、截了几百张图的会话，每次都要重放全部截图。Pi 插件对只有图片的轮次干脆不提交，图文混合的消息只发文字。

原因很实际：一张截图的 base64 编码动辄几十万字符，直接塞进观察者的上下文，既浪费 token，也会挤掉真正有信息量的工具输出（第 10 章的单字段 16,000 字符截断就是为了控制这个）。

多模态记忆真正需要的不是“把图片存下来”，而是“从图片里提取出可检索的事实”：这张设计稿对应哪个组件，这张架构图说明了哪几个服务之间的依赖。这一步需要一次专门的视觉模型调用，成本和收益都要单独评估。在那之前，先把图片挡在观察者外面是正确的默认值。

记忆驱动的自我进化

这一节仍然属于开放研究方向，没有成熟的生产实现。

这里的设想是 Agent 定期分析自己的记忆，找出“哪些决策后来导致了问题”，从而改进行为。到了 v13，可以落地的部分变得更清楚了：

  • 从重复里找规则。去重合并累加的 occurrence_count 和强化日期，标出了“反复遇到的同一件事”。反复出现的坑，适合沉淀成项目的 CLAUDE.md 规则、lint 规则或测试，而不是继续留在记忆里等 Agent 每次重新发现
  • 从未完成的事里找延续。work_state 记录的是跨会话的待办和进度（第 8 章），它让 Agent 的“意图”而不只是“经历”得以延续
  • 用评测而不是直觉判断有没有进步。记忆让 Agent 变好了还是变差了，只能用对照实验回答，同一批任务开关记忆各跑一遍（第 17 章最后一节）

风险也更清楚了。观察是模型生成的，可能出错；错误的观察被反复“确认”，在 ACT-R 排序下会越来越显眼。自我进化的闭环里必须有人或评测把关，否则强化的可能是错误。

思考题

  1. ACT-R 排序默认关闭（ALPHA=0）。如果你是 claude-mem 的维护者，需要什么证据才会把默认值改成开启？你会设计什么样的对照实验？
  2. “还剩什么”一节说强化不能让“已经不成立的知识”沉下去。设计一个最小可行的过时检测：什么时候触发、比较哪两条记录、比较结果写在哪里、怎么影响排序？
  3. 宿主自带记忆与外挂记忆并存时，同一条偏好可能在两边各存一份、内容不一致。检索时两边的结果冲突，你会让哪一边优先？

全书到这里结束。从“Agent 为什么需要记忆”，到 claude-mem 的 Hook、Worker、存储、渐进式披露、观察生成和知识库，到亲手写一个 mini-mem 插件，再到 Server 运行时、企业特性、多宿主和跨设备同步，这 20 章覆盖的是一个记忆系统从单机插件长成平台的完整过程。

claude-mem 还在快速迭代，本书的源码引用锁定在 v13.35.0。读到这里时它多半又发布了新版本，书里的行号会过时，但几条设计原则大概不会：Hook 要快、要永远不阻塞宿主；写入路径先落盘再通知；注入有硬上限，检索分步披露；同步和平台化时，每一次“恰好一次”都要靠幂等键和事务一起保证。

继续交流：inferloop.dev