Memory 技术日报 2026-07-26：上下文按需加载、HotPin 与声明图记忆

先看结论

严格按北京时间 2026 年 7 月 25 日 09:00 至 7 月 26 日 09:00 的过去 24 小时窗口，本期能闭环核验的不是 3 条全新论文或官方 release，而是 3 条窗口内的技术社区讨论。它们分别把 memory 问题推向三个层面：上下文应该按需加载，模型权重的热页可以按路由驻留，长期记忆则需要保存声明的时间、来源与冲突关系。三条材料的证据强度明显低于一手论文或合并后的工程版本，下面不把社区自报结果包装成官方结论。

进展	窗口内时间	证据形态	读者先核验什么
Claude 5 context engineering 讨论	7 月 26 日 04:42	Hacker News 讨论；原文为 Anthropic 官方博客的 7 月 24 日文章	删除上下文约束后，任务成功率与 token 成本是否同时稳定
HotPin 低内存 MoE 推理	7 月 26 日 02:41	Ask HN 作者自报 + GitHub 实现	3.84 tok/s 与 2.6 tok/s 的不同表格口径，以及 bit-identical 是否可复现
Statement graph 记忆设计	7 月 26 日 05:46	Reddit 工程讨论，5 条评论	事实冲突、有效期和来源能否进入热路径上下文切片

三条窗口内信号

1. 上下文工程：从「多写规则」转向按需加载

Hacker News 在北京时间 7 月 26 日 04:42 发布了对 Anthropic 官方文章的讨论，页面显示 146 分、93 条评论。1 原文的发布时间是 2026 年 7 月 24 日，因此这里的窗口依据是社区讨论时间，不是 Anthropic 的首发时间。2

Anthropic 把 agent 收到的 context 拆成 system prompt、Skills、CLAUDE.md、memory 和其它来源，并称在 Claude Opus 5、Claude Fable 5 上移除了 Claude Code system prompt 的 80% 以上，在其 coding evaluations 中没有可测的损失。它给出的方向包括：少写过度具体的规则，多设计表达能力更强的接口；把不常用的验证和工具定义做成 progressive disclosure；让自动记忆和 Skills 承担跨会话的上下文装载。2

这条材料最有用的不是「删掉 80%」这个数字，而是把 context 变成一个调度问题：哪些约束常驻，哪些资料延迟到需要时才加载，哪些记忆应该由系统自动写入。局限也很明确：文章没有公开 coding evaluation 的任务集、模型版本、硬件、token 账或完整对照表；「没有可测损失」是 Anthropic 的内部评估表述，不是独立复现结果。

建议动作： 把现有 agent 的 system prompt、工具描述、Skills 和 memory 记录成 token 账，建立一个「常驻 / 延迟 / 不注入」三分类。先在固定任务集上比较成功率、首次响应延迟、输入 token 与工具调用次数，再逐步删除重复规则；不要把博客里的 80% 直接当成自己的压缩目标。

2. HotPin：让 MoE 的热专家留在 RAM，冷页从 NVMe 按需取回

Ask HN 的作者在北京时间 7 月 26 日 02:41 发布了 HotPin 介绍，页面显示 4 分。作者称，这是一组针对 llama.cpp 的补丁：对 MoE 路由频率进行统计，把高频专家页用 mlock 或 Windows 的 VirtualLock 固定在 RAM，冷专家仍由 mmap 和 NVMe 按需读取；设计目标是让模型文件大于物理内存时仍能运行，同时保持输出 bit-identical。3

作者在 AMD Ryzen AI 9 HX 370、23.6 GB LPDDR5X、NVMe 大于 1 GB/s、CPU-only 的条件下自报：gpt-oss:120b 磁盘占用 58.5 GB，最低 RAM 19.1 GB；在一个配置中报告 3.84 tok/s，并称相对 mmap-only 的 2.64 tok/s 提升 45.5%。同一篇首帖还列出 Qwen3 30B-A3B 最低 RAM 10.4 GB、19.7 tok/s，以及 Gemma4 26B-A4B 最低 RAM 10.6 GB、11.5 tok/s。3

这里有一个不能跳过的口径问题：项目 README 的最低 RAM 表把 gpt-oss:120b 写成 19.1 GB、2.6 tok/s，而 3.84 tok/s 出现在 L1 pin speed comparison；README 还明确说数字来自 AMD Ryzen AI 9 HX 370、CPU-only 和特定模型文件。4 因此 3.84 不是脱离配置的通用吞吐承诺。项目仓库提供 REPRODUCIBILITY.md、benchmark 脚本、原始 JSON 结果，并把补丁绑定到 llama.cpp commit a6647b1a32f2ee456abff98ee2db15ed6e957c74；当前仓库许可证是 AGPLv3，另有商业许可说明。5

判断： 这是本期最像可运行工程的条目，但证据仍是作者自测，仓库的 arXiv 链接还未填入具体论文编号，且仓库历史显示主要实现提交早于本窗口。复现时要把「bit-identical」与「吞吐」分开：前者可在不同机器上做 SHA-256 对照，后者必须固定 CPU、内存、NVMe、模型量化、llama.cpp commit、上下文长度和线程数。

建议动作： 先只复现 gpt-oss:120b 的 baseline、L1 pin、L3 prefetch 三组，并记录 page fault、RAM 驻留、首 token 延迟和持续 tok/s；再拿一个完全放得进 RAM 的 MoE 做反例。若「模型大于 RAM 才有收益」的边界条件不成立，优先查路由热文件和 page-cache 行为，而不是继续扩大 pin budget。

3. Statement graph：记忆单元不应只有一个当前值

Reddit 的 r/AI_Agents 在北京时间 7 月 26 日 05:46 发布了「Agent memory kept failing for me until I treated it like a statement graph」，帖子有 5 条评论、评分 3。6 作者描述的不是已发布 benchmark，而是一套正在形成的工程设计：用带类型的实体和关系保存声明，把声明的来源、有效时间、支持证据以及后续修正或 superseded 关系一起记录。

作者特别反对把记忆更新成 last-write-wins：同一时间窗内出现冲突时，两个声明都应保留，直到解析策略或人工决定哪一个生效；「过期」和「错误」也不应混为一谈。作者还提到网络资源 ID 的确定性指纹、statement-about-statement 结构，以及按 trust policy 持久化「什么被相信、何时被相信、依据哪套规则」。这些观点来自单个社区作者的设计经验，不是独立评测结论。6

这条信号对 RAG 系统的直接启发是：检索到一条文本不等于知道它当前是否成立。实体消歧、时间有效性、来源等级和冲突解析，应该在 context assembly 前完成一部分，而不是把所有候选声明交给模型临场判断。代价是数据结构和查询路径更重：如果每轮都要展开多跳关系、版本和证据，读取延迟可能比普通向量检索高很多；原帖没有报告延迟、准确率、数据量或线上故障率。

建议动作： 选一组真实的冲突样本，至少包含同名实体、被替代的决策、同一时间窗内的相反声明和无来源文本。分别实现 last-write-wins 与 append-only temporal statements，比较实体误合并率、过期事实召回率、证据覆盖率、上下文 token 数和 P95 组装延迟。没有这组对照前，不宜把 statement graph 当成向量库的直接替代品。

共通判断：memory 的关键不是存得更多，而是控制状态如何进入下一轮

三条材料虽然证据等级不一，却落在同一个工程问题上：记忆不是一个无限增长的文本桶。Anthropic 的方案控制「什么时候把哪类资料装进 context」；HotPin 控制「哪些模型页常驻物理内存」；statement graph 控制「哪条声明、以什么时间和证据状态进入检索结果」。它们分别对应 context、serving residency 和 data semantics 三层，不能用一个向量召回分数代替。

本期更适合排入复现队列，而不是直接改生产架构：

Agent harness： 先做常驻与延迟上下文的 token / 成功率对照，验证 progressive disclosure 是否真的减少热路径负担。
本地 MoE serving： 复现 HotPin 的 bit-identity、page fault 与吞吐三项，不把作者单机数字外推到 GPU 或不同 NVMe。
企业记忆 / RAG： 用冲突声明测试时间有效性、来源与解析策略，再决定是否引入图式记忆。