Memory 技术日报 2026-07-27：记忆写入、context 账本与 agent trace 优化

先看结论

过去 24 小时可确认的新增，集中在四个开源工程入口：OpenViking 收紧记忆 patch 的写入条件，Hermes 把 context 用量拆成可读的本地账本，Headroom 修正压缩器对照和 prefix cache 默认值，World Model Optimizer 则把 agent traces 接入路由、蒸馏与 token compaction。它们都在处理状态进入下一轮之前的可见性和边界，但没有共同的模型、硬件或流量基线，不能合并成一条性能结论。

本窗口没有能以绝对提交时间闭环的新 arXiv 主条目，下面只收录四条时间证据明确的开源工程更新。

进展	北京时间	直接变化	适合怎么读
OpenViking memory patch	7 月 26 日 14:29	重复命中时拒绝静默替换	验证记忆写入的 fail-closed 边界
Hermes `/context`	7 月 27 日 05:22	展示类别、空余空间和 skill/toolset 用量	建立 context 成本账
Headroom parity 与 cache mode	7 月 26 日 10:26、7 月 27 日 03:09	20 个压缩器 fixture 对照通过，安装默认改为 cache	区分压缩收益和前缀缓存损失
World Model Optimizer	7 月 27 日 07:35	traces 进入路由、蒸馏和 compaction 流程	把优化目标拆成可复现的流水线

1. OpenViking：记忆 patch 不再接受模糊命中

OpenViking 在 openviking/session/memory 中修复了 SEARCH/REPLACE patch 的歧义处理。7 月 26 日 14:29 的提交要求 SEARCH 文本在目标文件中恰好出现一次；如果命中多处，代码抛出 PatchParseError，并要求模型补充连续上下文来消除歧义。唯一命中时只替换一次，不再对整段内容做全量字符串替换。1

这个改动很小，却直接碰到 agent memory 最危险的一类错误：写入动作成功返回，但改错了对象。提交同时补上了字典形式 patch 的解析测试、解析异常透传测试，以及重复 SEARCH 命中测试。对持久记忆来说，拒绝一次不确定写入比生成一份看似完整、实际污染了两个位置的记忆更容易恢复。

复现动作： 构造一个包含两行相同 status: pending 的记忆文件，提交只包含这一行的 patch，确认系统抛出 PatchParseError；再把相邻字段加入 SEARCH，确认只改动目标位置。测量写入失败率和人工修复时间，暂时不要把「patch 被接受」当成 memory 质量指标。

2. Hermes：把 context 从总量变成来源账本

Hermes agent 在 7 月 27 日 05:22 合并 /context 的统一实现。CLI 现在可以显示一个 5×20 的用量网格，每格约对应模型窗口的 1%，并附带按类别估算的用量表、剩余空间，以及展开后的 skill 和 toolset 列表；gateway 侧不依赖等宽字体，只输出类别表。这个视图直接读取当前 agent 和内存中的会话历史，不调用 provider，也不影响 prompt cache。2

它解决的是「知道窗口快满了，却不知道是谁占满的」这个运维问题。用量估算沿用 prompt-size attribution 的字符启发式，不能代替 provider 返回的真实 token 计数；提交说明也把它定位成 read-only 视图。这个边界很重要，来源拆得更细不等于账本已经精确。

复现动作： 固定同一个任务，依次注入 system prompt、skill index、toolset、历史对话和 memory，保存 /context 的类别表。比较总量变化、剩余窗口和首次响应延迟，再把技能从常驻改成按需加载。若总 token 下降但工具调用次数和失败重试上升，压缩并没有真正减轻热路径。

3. Headroom：先把压缩器对照做实，再修正 cache 默认值

Headroom 在 7 月 27 日 03:09 的提交把 log_compressor 从 stub 提升为真实 comparator，解除 20 个记录 fixture 的跳过状态。提交说明称，Rust 版本与已记录的 Python 输出 20/20 首轮匹配，并且包含 CCR 路径；完整 parity harness 的结果是 176 个 matched、45 个 skipped、0 个 diffed。这里是项目自己的回归证据，不是跨实现的独立 benchmark。3

更值得线上 serving 工程师注意的是另一项同窗口修复：headroom install 和 deploy 过去默认 token 模式，proxy 和服务端默认却是 cache。现在安装入口也改为 cache。该模式冻结已有轮次，只压缩最新增量，能保持缓存前缀的字节不变；token 模式会重写冻结历史，可能让 provider 的前缀缓存失效。4

提交里的成本数据来自 35 个本地 Claude Code 会话、23,018 轮和 8,985M prompt tokens，作者明确说明这不是 token 与 cache 模式的同流量 A/B；现有 manifest 中已经写死的 token 也不会自动迁移。因而这条更新更适合作为配置一致性修复和实验基线，而不是「cache 一定更便宜」的证明。

复现动作： 对同一批会话分别运行 cache 和 token，记录前缀命中、写入 token、压缩后 token、TTFT 和 P95。把已有 manifest 与新安装分开测，避免把默认值修复误当成存量部署迁移。

4. World Model Optimizer：agent trace 进入路由、蒸馏和压缩

World Model Optimizer 在北京时间 7 月 27 日 07:35 发布 Show HN 帖子，介绍一套面向 agent 的开源优化工具。项目把已采集的 agent traces 用作优化输入，提供三条路径：从较大开源模型向较小模型蒸馏相关推理轨迹，把任务路由到 frontier 或开源模型，以及用 token compaction 去掉噪声。wmo build 用 traces 构造待优化的模拟，wmo optimize 训练 router、compaction 并执行蒸馏，wmo serve 提供模型端点。5

这条材料的新增点不在标题里的成本承诺，而在优化链路开始被拆成了可以单独检查的组件。仓库同一窗口还加入了 optimize route sweep、OpenAI-compatible tool-call serving，并修复 wmo optimize route 的三个 artifact-integrity 问题。6 7 8

项目没有在这条首发帖里给出与基线模型、硬件、流量和任务集绑定的端到端收益，所以不能把 traces 接入后就等同于更低成本或更高质量。更稳妥的做法是把 router 选择、student 模型质量、compaction 后 token 数和 serving 延迟分别记账；否则一项质量提升可能只是换来了更高的 frontier 调用比例。

复现动作： 先冻结一批 agent traces，拆成 build、eval 和 serve 三份，避免训练数据泄漏。分别记录路由命中、蒸馏模型任务成功率、compaction 删除的 token 以及错误恢复；最后才比较总成本。任何「半价」结论都要回到同一任务集和同一服务配置上。

共同判断：先让状态边界可见，再谈 memory 优化

四条更新可以排成一条依赖链。OpenViking 先阻止不唯一的写入进入持久记忆；Hermes 让 context 来源和空余空间进入读取账本；Headroom 用 comparator 固定压缩行为，并把安装入口的 cache 策略与 proxy 对齐；World Model Optimizer 再把 agent trace 接到路由、蒸馏和 compaction。它们分别覆盖写入正确性、读取成本、缓存一致性和优化闭环，不能互相替代。

今天最小的验证顺序是：

用重复 SEARCH 样本验证记忆写入会拒绝歧义，而不是静默改错位置。
用 Hermes /context 保存一份按 skill、toolset、历史和 memory 分组的基线。
用 Headroom 的 parity comparator 固定压缩输出，再比较 cache 与 token 两种模式对 prefix cache 的影响。
用固定 agent traces 分开评估 WMO 的路由、蒸馏、compaction 和 serving，不把四个结果汇成一个模糊的收益数字。

这四个入口共同补的是测量和拒绝机制；至于它们能否改善线上质量，仍要由各自的任务集、硬件和流量实验回答。