cs.SE提交于 2026-10-28已译

Stratum：超越上下文窗口的代码智能体仓库记忆

Stratum: Repository Memory for Coding Agents Beyond the Context Window

Yuvraj Sehgal · Mahsa Panahandeh · Naser Ezzati-Jivan

中文摘要

尽管上下文窗口扩大千倍，代码智能体仍缺乏跨会话记忆，导致重复读取文件与重试失败方案。这属于记忆架构而非长度问题。Stratum 提出一种持久化、经验感知的仓库记忆系统。基于真实仓库的三项测量显示：中型项目已超出最大生产级上下文窗口，且将知识存入 KV 缓存比索引文本成本高 $10^4$ 至 $10^5$ 倍；在 752 个真实 Bug 修复提交中，中位修复仅涉及两个文件及其直接导入，占仓库不足 10%，瓶颈在于选择而非容量；即使包含传递导入和测试链接，47% 的共编辑文件对在结构上仍不连通，表明选择所需知识需从历史挖掘。Stratum 采用分层记忆架构，通过页面安全工具服务，每次响应明确返回内容、剩余内容及成本。在百万节点存储上，中位检索耗时 1.7 ms。在八个真实 Bug 的多会话实验中，继承不同模型写入记忆的代理在 24 次试验中 21 次定位到根因文件，而仅检索基线为 6 次（Fisher $p<10^{-4}$），中位 Token 成本降低 4.5 倍。合并所有八个调查笔记后，成功率保持 8/8。

关键要点

01指出代码智能体缺乏跨会话记忆是架构问题，而非上下文长度限制。
02通过真实数据证明修复瓶颈在于文件选择而非容量，且结构连通性不足。
03提出 Stratum 分层记忆系统，支持百万节点存储下 1.7 ms 的中位检索速度。
04实验显示继承记忆的代理在 Bug 定位上显著优于基线，且 Token 成本更低。

解读

在 GitHub 查看

1. 问题与价值

这篇论文要解决的问题是：编码智能体（coding agent）每次新会话开始时都没有对过去工作的记忆。它们反复重读文件、重试已经失败过的方法、忘记几小时前刚建立的根因结论。论文明确指出这不是上下文长度问题，而是记忆架构问题。

为什么重要：上下文窗口四年内从 2K 增长到 1M token，但窗口变大只让当前回合更便宜，没有让知识跨会话存活。一个在仓库上工作数小时的智能体，会话一结束就丢失了所有关于这个仓库的经验。

谁受益、怎么受益：长期使用编码智能体的开发者受益。如果智能体能把「上次定位到的根因文件」「试过但失败的方案」持久化在仓库旁边，下一个会话（哪怕是另一个模型）可以直接继承，避免重复发现。论文用实验证明：继承记忆的读者模型在 24 次试验中成功 21 次，而仅靠检索的基线只成功 6 次，且 token 成本降低到 1/4.5。

2. 已有工作的不足

在 STRATUM 之前，最接近的工作分几类：

KV-cache 管理层：论文 Related Work 中按引用编号列出，包括量化（引用 [3]）、token 选择（引用 [9] 到 [13]）、分页服务内存（引用 [14]）、多级卸载（引用 [15] 到 [19]）、跨请求复用（引用 [6] 到 [8]、[20]、[21]）、缓存本身上的检索（引用 [22] 到 [26]）。这些工作的共同局限是：管理的都是模型特定的状态，针对的是已经读过的 token，且都只在一个服务上下文内有效。没有任何一个能跨会话或跨模型边界存活。

MemGPT（引用 [29]）：精神上最接近的系统，对对话历史做分页，但完全不了解代码。它不知道仓库结构、import 关系、测试链接。

Repository RAG 和代码知识图谱（引用 [30]）：索引的是「代码是什么」，而不是「关于代码学到了什么」。它们不保存失败记录和根因分析。

共变挖掘（co-change mining）：这是挖掘软件仓库研究的经典技术（引用 [1]），但传统上用于指导开发者，STRATUM 把它变成任务执行中可遍历的活边。

具体哪一步不够：现有检索管线在返回 top-k 结果后静默丢弃其余内容，模型看不到截断边界，无法判断自己是否掌握了完整信息。论文称之为「lossy heuristic」，并指出模型会误用被塞进长上下文的内容（引用 [5] 的 lost-in-the-middle 现象）。

3. 重建作者的思考路径

如果我是作者，面对「编码智能体每次会话都失忆」这个问题，第一步会想到：把仓库内容压缩后放进上下文不就行了？但立刻撞上矛盾——Django 有 6.2M token，是最大生产上下文窗口的 6 倍。那把仓库存进 KV cache 呢？算一下：10 亿 token 作为索引文本约 4 GB，但作为 fp16 KV 状态对 70B 模型约 300 TB。差距是 4 到 5 个数量级。结论很清楚：长期记忆必须活在模型外面。

那放在外面之后，每次任务需要读多少？直觉上会以为要读很多。但去量真实 bug 修复提交：752 个提交的中位数只改 2 个文件。把这 2 个文件加上它们的直接 import 闭包，只占仓库的 2.7% 到 9.9%。所以瓶颈不是容量，是选择——怎么找到这 2 个文件。

怎么找？自然会想到静态结构：import 图、测试链接。但量出来发现：852 个提交里 3695 对共同修改的文件中，76.5% 没有直接 import 边。扩展到传递闭包和测试命名链接，仍然有 47.3% 的配对在结构上完全断开。静态分析只能看到一半。那另一半从哪来？版本历史里有共变记录，智能体自己的调试经历里有「我试过 X，失败了，因为 Y」。这些必须被挖掘并持久化。

到这里，设计方向浮现：一个分层的记忆系统，冷数据在 SSD 上的图数据库里，热数据在 RAM 和上下文里，控制器负责换页。但换页有个老问题：传统缓存策略把页面当不透明块，LRU 不知道哪些节点在语义上相关。于是想到给节点打分，把图距离、共变亲和度、访问频率、pin 意图都算进去。这是假设，不是调好的策略。

还有一个关键矛盾：检索系统静默截断，模型不知道有东西被丢了。如果模型要自己管理记忆，它必须能看到记忆的边界。所以每个工具响应都要带 has_more、budget、页码。这样模型可以决定「第 2/3 页已经有答案了，停止」。

试错的分叉点：一开始可能只想做结构记忆（解析代码），但 E3 的数据表明结构记忆只能恢复一半的工作集。于是必须加入历史记忆（从 git 历史挖共变边）和经验记忆（智能体写回的失败和根因笔记）。经验记忆是现有 RAG 栈不保存的东西，而它恰好是防止重复踩坑的关键。

与论文实际路径的差异：我猜的路径是先想到「放外面」再想到「怎么选」，论文确实也是这个顺序（F1 到 F2 到 F3）。但论文在 F3 之后直接跳到「共变挖掘是经典技术，我们把它变成活边」，我猜的路径里会先纠结「要不要用 embedding 相似度来补静态结构的缺口」，论文实际把 embedding 相似度放在 search 工具里作为辅助，而把共变边作为一等公民。另一个差异：我没想到「page safety」这个契约会这么早就成为设计核心——我倾向于把它当作实现细节，但论文把它列为 R2，是五个设计决策之一。

4. 核心 intuition

把 STRATUM 类比成数据库的缓冲池（buffer pool）：磁盘上有一大块便宜的数据，内存里有一小块热数据，中间有一个控制器决定哪些数据该被提升、哪些该被驱逐。数据库不会把整张表都加载进内存，它只加载查询需要的页。

STRATUM 对编码智能体做同样的事：仓库的全部知识（结构、历史、经验）存在 SSD 上的图数据库里，控制器根据当前编辑的文件、共变关系、访问频率，把一小部分节点提升到上下文窗口里。模型看到的是一个「工作集」，而不是整个仓库。

这个类比能对上机制：数据库缓冲池的页替换策略对应 STRATUM 的 S(v) 评分和驱逐逻辑；数据库的预取（prefetch）对应 STRATUM 的 prefetch 工具；数据库的脏页写回对应 STRATUM 的 remember 工具——智能体在任务结束时把新学到的知识写回冷存储，就像数据库把修改过的页刷回磁盘。

为什么有效：因为 F2 证明了工作集很小（中位数 2 个文件加直接 import 闭包只占仓库不到 10%），所以「只加载工作集」是可行的。F3 证明了工作集不能只靠静态结构找到，所以缓冲池的「页」必须带有从历史和经验学来的边。page safety 则对应数据库的「查询计划可见性」——模型知道还有多少数据没读，才能决定什么时候停止。

5. 方法 pipeline 举例

假设有一个 Flask 仓库，智能体收到任务：「修复一个 bug：当请求的 URL 包含 IPv6 地址时，路由匹配失败。」

第一步：Session 1，writer 模型（Claude Sonnet）开始调查。

它调用 tree 工具，看到仓库的层级结构。它调用 search，用关键词「IPv6」「route」「URL」做 embedding 相似度加关键词匹配。search 返回一个分页信封：第 1 页共 3 页，has_more=true，剩余预算 180K token，提示「第 2 页包含 url_parse 相关节点」。

它调用 get 读取 flask/routing.py 的 api 级别详情，发现路由匹配逻辑在 Rule.match 方法里。它调用 walk 沿着 imports 边找到 werkzeug/routing.py，再沿着 tests 边找到 tests/test_routing.py。

它定位到根因：werkzeug 的 URL 解析器对 IPv6 地址中的冒号处理有误。它调用 remember 写入一条 rca 节点：「IPv6 路由匹配失败的根因在 werkzeug/routing.py 的 _parse_host 函数，冒号被误当作端口分隔符。」同时写一条 failure 节点：「尝试在 flask/routing.py 里修，失败，因为 Flask 只是包装了 werkzeug 的路由。」

第二步：Session 2，reader 模型（Claude Haiku），上下文完全重置。

它收到同样的症状描述。它调用 search，关键词「IPv6 route failure」。这次 search 返回的节点里包含 Session 1 写入的 rca 和 failure 笔记，因为它们与查询的 embedding 相似度高。它调用 get 读取 rca 节点的 summary 级别，看到根因文件是 werkzeug/routing.py。

它调用 get 读取该文件的 api 级别，确认 _parse_host 函数的位置。它输出答案：根因文件是 werkzeug/routing.py。成功。

第三步：Session 3，另一个任务，但记忆池里已有 26 条笔记。

新任务与 IPv6 无关，但 search 返回的候选节点里混入了 26 条旧笔记。因为 page-safe 信封明确告诉模型「还有更多结果」，模型可以判断第 1 页的笔记都不相关，继续翻页或换关键词。论文报告在这种池化条件下成功率为 8/8，说明积累没有伤害检索质量。

6. 核心数学推导

论文的核心公式是控制器对每个节点 v 的评分：

S(v) = w1·G(v) + w2·C(v) + w3·H(v) + w4·P(v)

先解释每个符号：

S(v)：节点 v 的驻留评分。分数越高，越应该留在 RAM 和上下文中。
G(v)：图邻近度，即节点 v 到当前正在编辑的文件在图上的距离。距离越近，G 值越高。
C(v)：共变亲和度，即节点 v 与当前编辑文件在 git 历史中共同被修改的频率。频率越高，C 值越高。
H(v)：时间衰减的访问频率。最近被访问得越多，H 值越高；访问时间越久远，衰减越大。
P(v)：显式 pin 优先级。如果智能体调用 pin 工具固定了节点 v，P 值就高。
w1 到 w4：四个权重，控制各信号的相对重要性。

推导过程：这是一个线性加权和。每个信号先被归一化到可比较的尺度（论文未给出具体归一化方法，原文此处无法辨认），然后乘以权重后相加。控制器对所有节点计算 S(v)，按分数排序。分数高的节点保持驻留，分数低的节点被驱逐。

驱逐规则：当空闲上下文低于 15% 时，控制器从最大且最冷的节点开始驱逐，并报告移除了什么。被 pin 的节点永不驱逐。当前编辑文件的直接邻居保留接口级详情。其他热节点降级为单行摘要。其余回到 SSD。

这个公式在算什么：它在算「在上下文预算有限的情况下，哪些知识最值得留在模型眼前」。它把四个直觉——离当前工作近的、历史上经常一起改的、最近常用的、智能体明确要求保留的——合成一个可排序的分数。论文明确说这是研究假设，不是调好的策略，RQ3 要检验它是否比单纯的 LRU 更好。

另一个关键数字是 KV cache 的大小公式：每 token 的 KV 大小是 2·L·H_kv·d·2 字节。其中 L 是层数，H_kv 是 KV 头数，d 是头维度。第一个 2 覆盖 key 和 value，最后一个 2 是 fp16 的每值 2 字节。论文用这个公式算出 10 亿 token 对 8B 模型是 119 TB，对 70B 是 298 TB，对 405B 是 469 TB。对比索引文本的 4 GB，差距是 4 到 5 个数量级。

7. 实验设计

数据集：

E1 用 6 个开源仓库：Django、Flask、Redis、requests、scikit-learn、Vue core，共 17.6M token。
E2 用 3 个 Python 为主的仓库（Django、Flask、scikit-learn）的 752 个 bug 修复提交。
E3 用 4 个仓库（加上 requests）的 852 个提交、3695 对共同修改文件。
E4 用合成数据：10^6 节点、约 440M token、5×10^6 条边、384 维向量。
E5 用 8 个来自 requests 和 Flask 的真实 bug 修复提交。

基线：

条件 A：仅检索（RAG 风格），读者模型有仓库的完整词法搜索，但没有继承笔记。
条件 B：检索加经验记忆，读者继承 writer 写的 rca 和 failure 笔记。
条件 P：池化记忆，读者继承全部 26 条笔记（来自 8 个不同调查）。
条件 C：整个仓库放进上下文窗口，单次调用，无工具。

指标：

成功率：命名根因文件（文件级判据）。
调用次数、读取次数、输入 token 数。
E4 的检索延迟：中位数和 99 百分位。

消融：

A 对 B 隔离了经验记忆的贡献。
B 对 P 检验记忆积累是否伤害检索。
B 对 C 检验「小工作集加记忆」是否优于「全量上下文」。
论文未来计划 RQ4 要消融 failure 和 rca 节点，移除后比较。

实验能否支撑结论：E5 的规模很小（8 个任务、2 个仓库、24 次试验），且是「重新诊断」而非「迁移到新任务」。但 Fisher 精确检验 p=1.3×10^-5，统计上显著。E4 用合成内容，检索质量在真实 embedding 上未测量。论文在 Limitations 里承认了这些。

缺什么：没有控制 writer 笔记质量的实验；检索基线是词法的而非 embedding 的；没有测试纯会话摘要的传递效果（RQ1 要补）；没有在 Django 这种大仓库上验证。

8. take-aways

真实 bug 修复的工作集很小：752 个提交的中位数只改 2 个文件，加上直接 import 闭包只占仓库的 2.7% 到 9.9%。所以「选择」比「容量」更是瓶颈。

静态结构看不到一半的共变关系：852 个提交中 3695 对共同修改文件，76.5% 没有直接 import 边，扩展到传递闭包和测试链接后仍有 47.3% 断开。共变对是随机对的 26 倍更可能有 import 边（23.5% 对 0.9%）。

跨模型记忆传递有效：继承另一个模型写的笔记后，读者模型在 24 次试验中成功 21 次，对比仅检索的 6 次；输入 token 成本中位数从 196.6K 降到 43.3K，即降低到 43.3/196.6≈0.22，约 4.5 倍。

记忆积累不伤害检索：26 条笔记池化后成功率为 8/8，与单任务笔记的 21/24（87.5%）一致，且成本相同（41.7K 对 43.3K 输入 token）。

全量上下文不划算：条件 C 成功 14/16，与 B 的 87.5% 相同，但单次调用 164.4K token 是整个记忆会话 43.3K 的 164.4/43.3≈3.8 倍，且每次调用都重复此成本，且对 Django 这种 31 倍于 200K 窗口的仓库不可用。

9. 最脆弱的假设

最脆弱的假设是：经验记忆的质量足够好，且不会被污染。整个 E5 的结论——继承记忆让成功率从 6/24 跳到 21/24——依赖于 writer 模型写的 rca 和 failure 笔记是准确的。如果 writer 写错了根因，reader 会继承错误结论，比没有记忆更糟。

论文自己给出的证据：writer 模型解决了全部 8 个任务（中位数 83K token），所以「探针测量的是传递而非 writer 错误」。但这只说明 writer 在这些任务上找到了正确根因，没有说明笔记的措辞是否足以让一个更小的模型（Haiku）正确理解。论文在 Limitations 里承认「没有控制 writer 笔记的质量」。

另一个相关假设：记忆的检索能找到相关笔记。E5 用的是词法全文检索，不是 embedding 检索。如果笔记的措辞与 reader 的查询词不重叠，检索会失败。论文在 Limitations 里承认检索基线是词法的而非 embedding 的。

还有一个隐含假设：负面知识（失败记录）的价值高于正面知识。论文在 R3 里推测失败和根因笔记是「最高价值的内容」，但 RQ4 才要检验这个推测。如果失败笔记的价值被高估，整个经验记忆层的设计依据就动摇了。

10. 一周最小复现

目标：复现 E5 的核心结论——继承记忆能提高跨会话根因定位成功率。

步骤：

选 4 个来自 requests 或 Flask 的真实 bug 修复提交（这两个仓库足够小，可以在 200K 窗口内做条件 C 对照）。从 git log 里找带 fix/bug 关键词的提交，提取修复前的文件树和症状描述（去掉文件路径）。

搭一个最小 STRATUM 原型：SQLite 存节点，FTS5 做词法全文检索，实现 4 个工具：tree、search、get、remember。每个响应带 has_more、budget、页码字段。用约 200 行 Python 加 MCP SDK 完成。

Session 1：用一个 API 可访问的模型（如 Claude Sonnet 或 GPT-4o）作为 writer，对每个 bug 调查并写 rca 和 failure 笔记。记录它用了多少 token。

Session 2：用一个小模型（如 Claude Haiku 或 GPT-4o-mini）作为 reader，在两种条件下各跑 3 次：条件 A 只有 FTS 检索，条件 B 有检索加笔记。每次给 16 轮工具调用预算。

判据：reader 是否命名了人类修复实际修改的根因文件。计算 A 和 B 的成功率，做 Fisher 精确检验。

数据规模：4 个任务 × 2 条件 × 3 次试验 = 24 次 reader 运行。每次 reader 运行预计 40K 到 200K 输入 token。总 API 成本估算在 20 到 50 美元量级。

预期指标：如果论文结论可复现，B 的成功率应显著高于 A。论文报告 B 为 21/24（87.5%），A 为 6/24（25%）。小规模复现可能看到类似趋势，但置信区间更宽。

硬件：24GB 消费级显卡不是必需的——E5 用的是 API 模型。如果必须本地跑，可以用 7B 到 14B 的开源模型做 reader，但成功率可能下降。E4 的存储层（10^6 节点、3.7 GB）在 CPU 上就能跑，不需要 GPU。

11. 反例设计

要推翻本文核心主张——「经验记忆是跨会话性能提升的关键」——设计如下实验：

实验：取 20 个 SWE-bench 任务（比 E5 的 8 个更多样）。对每个任务，writer 模型写笔记。然后 reader 在三种条件下诊断：

条件 X：继承 writer 的完整笔记（rca 加 failure）。
条件 Y：继承一个「伪笔记」——用与 writer 相同数量的 token，但内容是无关的通用建议（如「检查 import 语句」「阅读测试文件」），不包含任何任务特定的根因信息。
条件 Z：无笔记，仅检索。

判据：如果条件 X 的成功率与条件 Y 无显著差异，说明提升来自「有额外文本可读」而非「经验记忆的内容」。如果条件 X 与条件 Y 都显著高于 Z，说明任何额外上下文都有帮助，经验记忆的特殊性不成立。

更强的反例：在条件 Y 中，伪笔记由另一个模型生成，内容是关于仓库的通用结构描述（如「Flask 的路由在 flask/routing.py，请求上下文在 flask/ctx.py」），但不含任何 bug 特定的根因。如果这种通用结构笔记能达到条件 X 的 80%（本反例设定的阈值）以上成功率，说明论文高估了「经验」的价值，低估了「结构」的价值。

论文主张被推翻的条件：条件 X 与条件 Y 的成功率差异不显著，且两者都显著高于 Z。这意味着 E5 的 21/24 对 6/24 的提升可能来自「reader 有了更多文本可读」这个混淆因素，而非「笔记里记录了根因」这个机制。

12. 落地判断

用于「抢占式 GPU 自托管 27B 模型做多智能体脚手架」：可以用，但要注意几个关键点。

怎么用：STRATUM 的存储层（SQLite 图加 HNSW 索引）完全可以在 CPU 上跑，不需要 GPU。27B 模型本身占约 16GB 到 20GB 显存（取决于量化），24GB 显卡可以跑 4-bit 量化的 27B。STRATUM 的 MCP 服务器作为独立进程跑在宿主机上，多智能体通过 MCP 协议调用 9 个工具。每个智能体的上下文窗口里只放工作集，不放全仓库。

成本量级：存储层 4 到 8 GB 每 10 亿 token，一个中型仓库（几百万 token）的记忆库只有几十 MB 到几百 MB。检索延迟中位数 1.7ms，对 LLM 回合（秒级）可忽略。27B 模型在 24GB 卡上的推理速度大约 20 到 40 token/秒，一个 43K token 的会话大约需要 18 到 36 分钟。如果多智能体并行，需要排队或降级到更小的模型。

最大的坑：27B 模型写笔记的质量可能不够好。E5 的 writer 是 Claude Sonnet（比 27B 开源模型强很多），reader 是 Claude Haiku。如果 27B 模型既当 writer 又当 reader，笔记质量下降会导致继承记忆的价值缩水。建议先用强 API 模型写笔记，验证 27B 模型作为 reader 能否利用这些笔记。另一个坑是抢占式 GPU 的会话中断：如果智能体在写笔记前被抢占，经验就丢了。需要在 remember 调用上做原子性保证，或者定期 checkpoint 会话状态。

内容由 AI 生成，仅供参考。如发现错误，欢迎反馈。

原始英文摘要

arXiv:2610.36153v1 Announce Type: cross Abstract: Context windows have grown a thousand-fold, yet coding agents still start every session with no memory of their past work. They re-read files, retry failed approaches, and forget root causes they established hours earlier. This is not a context-length problem but a memory-architecture problem. Our hypothesis: coding agents need persistent, experience-aware repository memory, so that knowledge survives from one session to the next. Three measurements on real repositories motivate the design. First, mid-size projects already exceed the largest production context windows, and storing knowledge inside the model's key-value (KV) cache costs $10^4$ to $10^5$ times more bytes than storing it as indexed text. Second, across 752 real bug-fix commits, the median fix edits two files, and these files plus their direct imports amount to less than 10% of the repository; the bottleneck is selection, not capacity. Third, even with transitive import reachability and test links, 47% of co-edited file pairs remain structurally disconnected; the knowledge needed for selection must be mined from history and experience. We sketch Stratum, a tiered memory that lives with the repository and serves it through page-safe tools: every response states what was returned, what remains, and what it cost. Retrieval over a store of one million nodes takes 1.7 ms at the median. In a multi-session experiment on eight real bugs, a fresh agent that inherited a prior session's memory, written by a different model, identified the root-cause file in 21 of 24 trials versus 6 of 24 for a retrieval-only baseline (Fisher $p<10^{-4}$), at 4.5x lower median token cost. With the notes of all eight investigations pooled in one store, success remained 8/8.