智能体的记忆架构有个尴尬：上线那天就定型。存什么、怎么检索、何时压缩，都是部署时拍定的代码；任务类型一变，原来的设计就开始将就。想让它自适应，流行的做法是拿执行反馈去演化——可反馈通常只有一个评分或一段压缩摘要，粗到定位不出失败在哪，修改范围框不住，改着改着就变成大段重写，把本来能用的架构改坏。10 月 15 日提交 arXiv 的 MemScope（编号 2610.21170）想把这个「粗反馈」换成「证据定位的小补丁」。
论文七位作者，归类人工智能，尚未经同行评审。做法是配一个会用工具的 Patch Agent：它同时看三样东西——原始执行轨迹（失败具体发生在哪一步）、运行时记忆状态（当时记忆里到底存了什么、检索命中没有）、当前架构代码（哪一段该为这次失败负责）。三源对齐之后，才给出代码级修改目标，并且编辑是有界的：提供方身份不能换（换存储不换供应商），记忆兼容要保住（旧记忆仍可读取），每次只做原位小改，不做推倒重来。
读数：细在哪，增益就在哪
论文用同一套演化框架做了个干净对照：只换反馈粒度。GAIA 基准上，摘要反馈 63.33%，加上原始轨迹提到 70.00%，再把运行时记忆状态并进来，到 86.67%——同一框架，增益全来自「看得细」。另两组读数：xBench 任务上，演化后的记忆架构把 DeepSeek V3.2 从 49 题提到 55 题、把 Kimi K2.7 Code 从 50 题提到 53 题；ALFWorld 的未见任务集上，成功率从 50.75% 提到 71.64%。
还有个数字比分数更值得记：跨架构快照迁移的代码改动中位数是 4.4%。小步修改在这篇论文里不是谦辞，是设计目标——它既是「约束生效」的证据，也是可审计、可回滚的前提。一个会自己改自己代码的组件，改动幅度就是它的安全边际。
放进台谱里看
记忆是本站的日更题材：从祛魅的 1941（记忆层省的那点 KV，换不来统计上站得住的增益），到 EngramRAG（1444）、CTWM（1528）、Percepta（1577）、Mem++（1615）各路机制设计，再到 T-Mem（1835）与 T²Mem（1875）的版本化记忆。这些工作回答的是「记忆该怎么设计」；MemScope 回答的是另一个问题：「设计定错或者任务变了，怎么小步改回来」。一篇治设计，一篇治演进，中间还隔着 1920 与 1956 那类「记忆即基础设施」的产品化尝试。
和 1941 对读特别有意思：那篇说记忆组件的增益常常经不起严格测量，这篇给出的部分答案是——不是记忆没用，是粗放地加记忆组件没用；增益要靠证据定位地改架构才能兑现。两篇合起来，给「堆记忆模块」的冲动踩了脚刹车。
几盆该浇的冷水
GAIA 的 86.67% 是单点数字，xBench 的增益是 6 题与 3 题的量级，ALFWorld 未见任务涨了 20.89 个百分点但绝对值 71.64%——分开读比合成一个「大幅提升」的印象诚实。其次，「提供方身份不变」这条约束假设了存储后端可枚举，真实系统里存储供应商的边界有时比代码更难画。再者，自改代码的组件，审计轨迹与回滚机制论文摘要未展开，这恰是企业采纳时先要问清的问题。七位作者、预印本、未经同行评审，复现要等代码。
给做记忆系统的团队一个可以立刻抄的作业：先把「失败→哪一段代码负责」的映射做出来——不需要自动演化，人工能定位就赢过大半团队。至于自演化，把 4.4% 这个中位改动率当成内部演进预算的基准线：超过它，就该停下来重审，而不是继续打补丁。