Beyond Token Savings + GitHarness + DyadMem 三篇合读：上下文经济学与 Agent 记忆工程——该不该压、怎么管、怎么测 精读

论文一：Beyond Token Savings: A Systematic Study of Context Compression in LLM Agents（arXiv:2609.32961v1，2026 年 9 月 26 日） 论文二：GitHarness: Git Init Your Harness Working Memory for Perpetual User Requirements（arXiv:2609.36789v1，2026 年 9 月 29 日，匿名开源仓库） 论文三：DyadMem: A Long-Term Memory Benchmark of How Agents Work with Users（arXiv:2610.03020v1，2026 年 10 月 2 日，数据集/GitHub/项目页链接见论文首页） 发表时间：2026 年 9-10 月（三篇同期出现在 arXiv） 机构：论文一——UT Austin（纯高校，四位作者，无企业参与）；论文二——北京大学（国家软件工程研究中心、计算机学院、教育部高置信软件重点实验室、前沿计算研究中心、北大信息技术天津滨海研究院，纯高校多院系合作）；论文三——南洋理工大学 NTU + 新加坡国立大学 NUS + 香港大学 HKU + 阶跃星辰 Stepfun（产学研合作且企业主导：四位共同一作中三位挂 Stepfun，通讯作者邮箱 alex@stepfun.com 属 Stepfun，数据构建与 57,751 美元标注成本由企业方承担，三所高校提供学术署名——典型的"企业出数据和工程、高校出学术背书"结构） 领域标签：LLM Agent / 上下文管理 / 记忆系统 / 评测基准 / cs.AI / cs.LG / cs.MA

一、论文背景：上下文是 Agent 的第一生产资料，也是第一成本项

把三篇论文放在一起读，需要先建立一个共同视角：对长时程 Agent 来说，上下文（context）既是决策的全部信息来源，又是账单和延迟的主要来源；而记忆（memory）是跨会话、跨轮次的上下文管理问题。三篇论文分别站在这一主题的三个位置上。

第一面透镜：压缩是生产系统的日常，但从来没人系统测过它。 先补三个背景概念。Coding Agent：执行仓库级任务的 LLM 智能体，在「推理→调工具→读输出」的循环中解决真实 GitHub issue 或终端任务；轨迹（trajectory）：这个循环累积下来的全部中间记录——每一步的推理文本、工具调用与（往往极长的）工具返回；上下文压缩（context compression）：当轨迹增长到接近窗口或成本过高时，harness 主动删除、清除或改写部分历史以继续执行的机制。

轨迹增长带来三重代价：计费线性上升、注意力随长度退化（Lost in the Middle：关键信息埋在长上下文中部时利用率显著下降，甚至低于闭卷基线）、窗口终究会满。于是所有主流 harness——Claude Code 的 Compaction、Codex 的 auto compact、Gemini CLI 的 compressionThreshold（默认 0.5）、Cline 的 Auto Compact（90% 窗口触发）、OpenHands 的 Context Condenser（默认 LLMSummarizingCondenser，把前半历史替换为单条摘要事件）——都内置了压缩机制，且各家在「压什么/何时压/压多深」上选择各异。这不是学术玩具：论文一引用的 13M 次 GitHub Copilot 会话生产 trace 显示，需要压缩的会话占全部服务 token 的 44.2%，中位压缩事件会移除现有上下文的 72.8%——压缩已经是生产系统不可忽视的负载。但每家 harness 把三个决策捆绑成一个固定策略，端到端评测无法区分到底哪个决策在起作用；而且这些系统的评测口径是 token 数与成功率，看不到时延与计费。UT Austin 的论文一就是对这个设计空间做首次系统拆解。

第二面透镜：需求会变，而摊平的历史无法回滚。 这里的关键词是 harness（脚手架/编排层）：包在模型外面、负责组装上下文与调度工具的系统层——harness 的「工作记忆」就是它为执行模型拼装的上下文。长时程协作中用户很少一次给全需求：看到中间结果后补信息（requirement completion）、受结果启发加新需求（requirement elicitation）、改主意或撤回（requirement shift）。论文二开篇给了两个直观例子：让 Agent 改报告中一处细节，结果整份文档被重新生成、未受影响的章节全变了；让 Agent 修一个 bug，无关文件被大面积改动——局部修订变成全局重写是当前 Agent 的通病。此时 Agent 面临三难：全量保留历史（Native）会把作废需求的结果继续喂进上下文污染决策；每次从头重做（Restart）浪费可复用的工作，token 与时间成本高昂；局部更新（Selective Update）又要求 Agent 准确预测「哪些工作受影响」——这本身既难又脆。北大的 GitHarness 把这个困境交给版本控制抽象：把「当前有效需求」与「对应工作区状态」绑定为可分支的版本历史，每次反馈是一次从合适历史基线出发的分支更新。

第三面透镜：记忆系统到底做得好不好，最终答案 QA 说了不算。 2026 年 Agent 记忆系统已经是创业赛道：Mem0（抽取-检索式，约 48K star）、Zep（双时态知识图 Graphiti，被替代事实标记失效而非删除）、Letta（MemGPT 后续，分层记忆块自编辑）各自报告 LoCoMo/LongMemEval 高分（Mem0 自报 LoCoMo 92.5 / LongMemEval 94.4，Zep 自报 94.7——评测协议互不兼容且全部自报）。但这些评测有一个共同盲区：只看最终问答准确率。一个答对的背后可能是记忆库残缺但答案靠参数知识蒙对；一个答错的背后无法定位是抽取（Capture）、更新（Update）、检索（Recall）还是生成（QA）环节失败。更根本的缺口是：现有基准只监督「关于用户的事实」（画像/偏好/事件演变），而没人标注「这个 Agent 该如何与这个用户协作」——同一用户面对两个 Agent，因交互历史不同，需要的未来行为也不同（论文三图 1 的例子：用户先后说过喜欢辣、喜欢西餐、后因肠胃炎只能吃清淡——用户侧记忆记「用户生病需清淡饮食」，URAM 记「该先推辣、现改推清淡」这一协作方法本身的演变）。DyadMem 把这两层缺口一起补上：定义 URAM（User-conditioned Relational Agent Memory，用户条件化关系型记忆），并沿同一条多会话轨迹对 Capture/Update/Recall/QA 全生命周期打金标。

三篇的递进关系由此清晰：论文一在单次会话内问「该不该压、怎么压才不亏」；论文二在跨轮协作中问「历史该怎么组织才能既保留有效工作又丢弃过时信息」；论文三在跨会话生命周期上问「记忆系统的每个环节到底损失了多少」。压缩、版本管理、生命周期评测——上下文经济学的测、管、评三部曲。

二、论文定位和关联工作

三篇论文各自处于一条活跃研究脉络中，定位各不相同。

谱系一：上下文压缩与 compaction（论文一的战场）

• 生产系统的事实性工作：Liu et al. 2026（arXiv:2608.00101）对 13M 次 Copilot 会话的生产 trace 做表征，发现压缩事件破坏前缀缓存复用——论文一的 44.2%/72.8% 数据即引自此文。这类工作「表征给定机制下的负载」，而论文一「变化机制本身」，是表征与受控实验的互补关系。
• 压缩方法论文：ACON（Kang et al. 2025）、CoAct（Chen et al. 2026）、Context Folding 等提出「大幅减 token 且基本保成功率」的技术；论文一不与之比 SOTA，而是指出这些方法评测的共同缺陷——只看 token 和成功率，不看时延与计费。
• 同期「策略内化」路线：AutoCompact（SMU+NTU+Harvard，arXiv:2610.02163）给 Agent 一个 compact() 动作用 SFT+RL 训练何时调用，SWE-bench Verified +9.2 点；FOCUS（Microsoft M365，arXiv:2609.37590）免训练地在测试时做因果决策保留，峰值上下文降 48%、成功率反升 8.9 点；Context Language Models（Meta，arXiv:2609.37725，本博客 10-05 精读）把上下文镜像为文件让模型用 Bash 编辑。这些工作把压缩决策从 harness 迁移进模型，与论文一的「策略该按模型定制」结论同向。
• 本文内部交叉印证：论文一发现「简单掩码 ≥ LLM 摘要」与 The Complexity Trap（JetBrains+TUM，arXiv:2508.21433）在 SWE-agent 上的结论一致——观察掩码成本减半且解出率与摘要持平甚至略超（Qwen3-Coder 480B 上 54.8% vs 摘要相当），后者是论文一直接引用的独立证据。

谱系二：执行侧历史的版本化管理（论文二的战场）

• 需求/意图追踪：U-Fold（意图感知折叠）、intent mismatch 系列澄清「用户现在要什么」，但不回答「之前的工作哪些还能用」；Laban et al. 2026 证明模型在渐进披露下会被早期假设锚定。
• 轨迹组织与恢复：HiAgent（分层工作记忆）、SAM（状态自适应记忆）、Sculptor（主动上下文管理）、检查点恢复方法，均假设任务目标固定；GCC（Wu et al. 2025）引入 commit/branch/merge 管理上下文，但版本选择由「当前推理状态/执行失败/探索需要」驱动。GitHarness 的差异点是需求驱动：版本选择回答的是「用户改了需求后哪个历史状态语义兼容」，而非「执行需要什么」。
• 训练侧：GitHarness 的 Git Agent 用 Harness RL（Jiang et al. 2026，接口级黑盒 RL + LoRA-GRPO）训练，属于「harness 组件可训练、下游执行模型冻结」的新兴范式。

谱系三：长期记忆评测（论文三的战场）

• 用户侧记忆基准：LoCoMo、LongMemEval、PerLTQA、ConvoMem、PersonaMem、Memora、STALE 监督事实/画像/偏好的演变，但记忆内容只描述用户。
• 经验型 Agent 记忆：Agent Workflow Memory、Memp、LongMemEval-V2 抽取跨用户可迁移的工作流，与「这个用户」无关。
• 生命周期评测：AMemGym 探测写/读/用失败，HaluMem/MemOps/Memora 提供抽取或状态转移监督，但都只覆盖部分环节。DyadMem 的 Table 1 显示：它是唯一在「用户侧 + URAM 双域 × 逐会话金标抽取 × 金标生命周期操作 × 查询到库支持链接」四个维度全勾的基准。
• 工业界对照：Mem0/Zep/Letta 各自报告 LoCoMo 90+ 分，但评测协议不统一且都是最终 QA——恰好是 DyadMem 指出的「一个数字掩盖一切」问题。

定位总结

三、问题定义

三篇论文各自把纷繁的具体场景压缩成一个干净的抽象问题。

论文一：压缩策略 = 三轴设计空间

具体问题：哪个压缩策略好？端到端比一下就知道了——但端到端比分无法告诉你为什么好。 抽象问题：把压缩策略分解为三个正交决策轴，固定其余变量测单轴效应：

一个精妙设计是触发阈值校准：阈值不能拍脑袋定，而是先跑无压缩轨迹，取每条轨迹峰值上下文需求分布的 5/15/25 分位数作为 tight/primary/loose 三档——这样阈值相对于「这个模型在这个负载下的自然上下文需求」定位，而非绝对 token 数。评估函数是四元的：任务成功率 × token × 时延 × 计费（缓存价 0.1×），给定任务集与模型，刻画整个帕累托前沿而非单点。

论文二：需求追踪 + 局部更新 = 版本图上的基线选择

具体问题：用户改需求后，怎么只改受影响的部分？ 抽象问题：每轮 t 系统维护需求状态 I（当前目标与约束）和工作状态 W（执行上下文与累积工件）。新反馈 q 到来时求三元组：

(Q, b, h) = f(q, H)

即恢复完整当前需求 Q、选择语义兼容的历史基线版本 b、产出更新提示 h，然后由下游执行算子做局部更新。关键的洞察是：不要求 Agent 预测「哪些具体工件受影响」（这既难又脆），而是让局部性从「从兼容状态续跑」中自然产生——从正确的基线分支出去，编辑范围天然被新需求限定。这与 Git 的分支哲学同构：变更的范围由分叉点决定，而非由 diff 预测决定。需求变化被形式化为相对历史锚点的三种编辑：Completion（补全）/ Elicitation（新增）/ Shift（撤回或修订），数据构造时实例化为九个细粒度算子，但方法本身不需要识别变化类型。

论文三：记忆 = 双域六类 + 全生命周期状态转移

具体问题：Agent 记忆系统好不好？最终 QA 准确率高就是好。 抽象问题：一条 episode 是会话序列 + QA 集。每个会话 t 携带完整对话 D、金标抽取条目 C、金标更新操作 (L, A)（删除与添加）。金标记忆库按状态转移演化：

B(t) = Dedup((B(t−1) ∪ C(t)) \ L(t)) ∪ A(t)

记忆条目分六类：用户侧两类（user_profile 持久属性偏好、fact 客观事实）+ URAM 三类（agent_identity 角色与行为边界、agent_method 可复用协作流程、agent_knowledge 用户条件化决策规则）+ 共享 episodic（交互事件）。评测分解为四阶段独立指标 + 两档 QA：Capture（只见当前会话，抽记忆）、gold 条件下的独立 Update（给金标前库与金标新抽取，隔离上游错误）、Recall（从终态金标库选有序证据集）、Gold-Memory QA（直接喂金标证据答问）与 Full-Pipeline QA（自建库自检索答问），两者之差 ΔG2P = Acc_gold − Acc_pipe 量化完整管线引入的损失。这个抽象的精妙在于：ΔG2P 是端到端总量，四阶段指标是独立定位——总量告诉你亏了多少，分解告诉你亏在哪，且明确声明 ΔG2P 不是误差的因果分配。

还有一个指标设计细节体现了 DyadMem 的严谨：Recall 的主指标 Recall@n 不是固定 top-k 命中率，而是以「每题自己的金标支持集大小 n_j」为窗——题目的证据需求有多大，就检查多大的窗，避免用统一 k 偏袒短支持集或长支持集的题目；辅以 @n+4（容忍冗余）、@All（集合召回）、精确率与 Hit@1 分离「排序质量」与「完整性」两个维度。

三篇的问题定义共享一个立场：把「上下文/记忆管理」从工程技巧提升为可形式化、可分解、可测量的对象——论文一分解决策轴，论文二分解「需求-工作」绑定关系，论文三分解生命周期阶段。

四、问题解法

论文一：35,000 次运行的受控实验矩阵（测量即方法）

论文一没有新算法，它的「解法」是实验设计本身：

1. 固定混杂：mini-swe-agent 极简循环（无任何自带记忆/上下文管理机制以免混淆）、固定任务集（SWE-bench Verified 100 题：Django/SymPy/scikit-learn；Terminal-Bench 1.0 40 题）、三个开源模型（Qwen3.5-35B-A3B、Devstral-Small-2-24B、GLM-4.7-Flash）本地 vLLM 部署。
2. 策略网格：65 种策略组合（8 primitive × 3 档阈值 × 3 档深度，深度不变型 primitive 只测一次）+ 全上下文 FC 参照 + 步进 TRC（OTRC）。
3. 重复：每个任务-策略-模型组合跑 3 次量化运行间方差，合计约 35,000 次 Agent 执行。
4. 指标口径：token 用量、端到端时延、估算计费（缓存 token 计 0.1× 价格，对齐三大厂商 API 定价）、任务成功率（resolve rate），资源指标以「与 FC 的配对比值」呈现，统计用任务级 bootstrap 95% 置信区间。
5. 双轨矩阵：全量对比（primary 阈值 + D=0.5 在全部任务上跑所有 primitive）+ 受控扫描（25/15 题子集上单独变阈值或深度）。

三个 primitive 家族的区分标准是「信息以什么形式幸存」：规则型删除不需要额外模型调用；LLM 型重写需要（用与执行相同的模型做摘要，附录单独测了换摘要模型的敏感性）；堆叠型先规则清理再摘要。系统提示与任务指令永远原样保留，只有「可压缩窗口」（累积的助手消息与工具结果）参与压缩——这个划分本身就是论文的一个概念贡献。

类比：这相当于药物试验中的析因设计（factorial design）——不是发明新药，而是把「剂量 × 给药时机 × 疗程」三个维度拆开测主效应与交互效应。

论文二：GITHARNESS——Git Agent + 版本图 + 接口级 RL

类比：给 Agent 的 harness 工作记忆做一次 git init。四个组件：

Git Agent 的短 ReAct 循环在每一步 a_k ∈ {INSPECT, COMMIT, REUSE} 上采样，环境返回历史版本的观察；成功的 COMMIT 或 REUSE 终止循环并输出交接四元组（完整需求 Q、选中基线 b、目标版本 v、非权威更新提示 h）。一个关键设计：branching 不是独立动作而是基线选择的副产品——选当前 HEAD 就是延续主线，选历史版本就自然开分支。这把「要不要回滚、回到哪」统一成一个决策。

训练（GITHARNESS-RL 可选增强）：只用接口级黑盒 RL 训练 Git Agent（Qwen3-8B + LoRA-GRPO），下游 harness 与执行模型全部冻结。rollout 捕获时每次 Git Agent 调用记录为接口调用记录（tokenized 输入、采样输出、逐 token rollout 对数概率），两次调用之间 harness 派发给 update agent 的执行只贡献上下文、不进梯度——训练掩码只覆盖 Git Agent 的输出 token，这是接口级黑盒 RL 的精髓。奖励 = 稀疏终局奖励 R_out（最终产物对验证器的正确性）+ 逐轮 query-tracking 奖励 R_track（LLM judger 按「需求保真度 / 基线最优性 / 过时排除」三维打分），逐 token 优势合成 A = (1−λ)·A_out + λ·A_track，λ=0.2 为平衡点（λ=1 时 Query 指标微升但任务分从 70 跌到 65——过度优化追踪会伤害最终完成）。训练信号与评测协议三维对齐，形成闭环。

配套基准 MTAgentBench：把 GSM8K/BIRD/BrowseComp-Plus/SWE-bench Verified/DeepResearch Bench 各 100 题扩展为 7 轮交互（Math/SQL/Search/Code/Research 五域），保留各基准原生验证器，标注需求状态、版本转移与任务完成度。

论文三：DyadMem——对话先行构造 + 双域联合标注

类比：给记忆系统做「全流程质检流水线」，而非只看成品的「出厂测试」。

1. 对话先行构造：生成计划只规定「哪类记忆变化何时发生」，不规定最终记忆条目；先完整生成并审校多会话对话，再从「实际发生的交互」回溯标注 Capture/Update/Recall——每条标注可追溯到对话证据（沿用 LoCoMo 的 dialogue-first 策略）。终产物：3,065 episodes、50,961 会话、126 万轮对话、61,210 QA，覆盖 5 大生活域 25 子域，构造与标注成本 57,751 美元，9 名质检员全量复审。
2. 双域六类记忆（见第三节）：URAM 三类的定义是本基准的灵魂——agent_identity（「对这位用户我是谁」：角色与行为边界）、agent_method（「怎么跟这位用户干活」：可复用协作流程）、agent_knowledge（「对这位用户怎么决策」：交互中学到的条件化规则）。
3. 评测协议：Capture 用条目级 micro-F1（双向语义覆盖匹配，容忍粒度差异）；gold 条件独立 Update 用操作级 op-F1（Add F1 与 Delete F1 宏平均，删除用精确索引匹配），只在含金标操作的 20,590 个会话上计算；Recall 主指标 Recall@n（金标支持集大小为 n 时取前 n 的命中率），辅以 @n+4、@All、精确率、Hit@1；QA 用 GPT-5-mini 判语义一致性，并报告 Grounded（正确且有证据支持）/ OA 过度弃权 / Ung. 无证据答对三个诊断口径。截断、不可解析、空输出保留在分母中记零分。
4. URAM 有效性验证实验：同 500 episodes 上配对比较「URAM 变体（同时看用户与助手轮次）」vs「Agent-only 变体（只抽助手侧信息）」，对同一金标评测——这是「定义有效性」的受负对照实验，罕见于基准论文。 两个 QA 设置的对照逻辑值得细看：Gold-Memory QA 喂的是「金标支持集」（该问应该用到的记忆），Full-Pipeline QA 用「模型自建库 + 自检索（上限 K=16 条）」——前者测「给你对的证据你会不会用」，后者测「从零养库到答题的全链路」。因为每个 QA 的金标支持集都非空，空检索记为失败而非正确弃权——堵住了「什么都不检就算 abstain 蒙混」的路径。
5. 判官可靠性：三判官（GPT-5-mini/Gemini-2.5-Flash/Claude-Haiku-4.5）排序 Spearman ≥ 0.988，人机一致率 86.52%、Cohen’s κ=0.7099。

五、评估指标与实验证据

论文一核心数据

SWE-bench（Qwen3.5-35B-A3B，primary 阈值，D=0.5）：

用差不多 0.56-0.63× token 的策略，成功率可以差 12 个百分点、计费差 0.71-0.95×——token 用量几乎不预测任何东西。

Terminal-Bench（Qwen）：12 策略中 11 个成功率降 5-13pp；所有策略都比 FC 慢（1.05-1.8×）；用约 1/3 token 的策略慢 20-80%。解释：SWE-bench 的 Agent 可以从代码和补丁中重建工作上下文，而 Terminal-Bench 的多样工作流更依赖中间观察与动作历史。摘要调用本身占 4 个摘要型策略已解运行墙钟时间的 28-46%。

触发与深度扫描（Qwen SWE-bench，SU，D=0.5）：阈值 10K→20K，成功率 50.7%→62.7%，压缩频次 4.85→1.15 次/attempt，输入成本 1.10×→0.92×，时延 653s→599s——晚压比早压全面更好。深度效应按 primitive 分化：TR 从 D=0.3→0.7 成功率 61.3%→50.7%（越深越糟），SU 反向 50.7%→60.0%。

模型间转移失败：OTRC vs TR，Qwen +7.0pp、Devstral −17.0pp；Devstral 最佳是 TRC+SS 57.0%，GLM 最佳是 OTRC/SU-p 41.3%，无一策略跨模型称王。配置敏感性同样不转移：SS-p 的 SWE-bench 阈值从 10K→15K→20K，Qwen 成功率 50.7%→60.0%→73.3% 一路上升，Devstral 却在 72-73% 纹丝不动；SU-p 在 Terminal-Bench 上把深度从 0.7→0.5→0.3 调浅，Qwen 33.3%→40.0%→46.7% 改善，Devstral 反而 37.8%→22.2%→37.8% 震荡。但有跨模型一致的设计收益：SS-p vs SS 三模型 +6.7/+8.7/+8.0pp，TRC+SS vs SS +7.7/+9.7/+9.7pp——「保留近期历史 + 结构化重写」是可复用组件；而「每步清除 vs 阈值清除」（OTRC vs TRC）三模型 −2.3/−14.3/+2.7pp 方向都不一致。

任务级换血：总量相近的策略解的是不同的题——FC 解 53 题，压缩后 2-7 个 FC 失误的题被新解出，6-14 个 FC 已解的题反而丢失（TRC+SU 新解 7 丢 8 得 52 题；TR 只新解 3 丢 14 崩到 42）。

论文二核心数据

MTAgentBench 主表（7 轮交互，5 域 × 2 骨干 × 3 harness = 30 设置）：

• training-free GITHARNESS 30/30 设置胜 Native，28/30 匹配或超过最强 baseline（27 严格胜 1 平）。Search 域提升最猛：比最强 baseline 高 14.0 分（TCRAG）/ 18.0 分（OpenHands）。
• 跨 harness 一致性（DeepSeek-V4-Flash，GITHARNESS 相对最强 baseline 的典型领先幅度）：Search 域 TCRAG 34.0→56.0（+22.0）、OpenHands 27.0→57.0（+30.0）；Code 域 OpenHands 64.0→72.0；Research 域三 harness 全部第一（46.65-51.48 RACE）。Qwen3-32B 侧 SQL 比 Native 高 26.0 分（StackPlanner）、15.0 分（OpenHands）——提升方向在 2 骨干 × 3 harness 上同号。
• token 经济：相对 Native，SQL 降 35.8%、Search 降 54.5%、Code 降 73.6%、Research 降 36.7%，且四域性能同时提升（Search/Code/Research 同时做到所有方法中最优性能 + 最低 token）。
• 长时程：H=30（30 轮交错 2-4 任务）时 Math 84.0、Research 47.32，从 H=10 到 H=30 Research 仅降 2.21 分（baseline 至少降 3.37 分）。
• 消融（StackPlanner + DeepSeek-V4-Flash）：去掉历史版本选择（固定当前 HEAD 为基线），Code 从 74.0 崩到 44.0，token 从 1.29M 涨到 4.51M（3.5 倍）；去掉 INSPECT 降到 42.0（4.22M）——基线选择与检视历史是全部价值的核心。禁用 REUSEANDPATCH 五域全线退化，禁用 FRESHSOLVE 亦然（SQL −10.0、Search −11.0）。
• RL 适配：8B Git Agent 从 Math 51.0→81.0、SQL 55.0→73.0（+30/+18 点），仍不及 training-free 的 DeepSeek Git Agent 但已在 StackPlanner 五域中四域超过 Qwen3-32B 配置。
• 技能注入（RQ4）：从源数据集推理轨迹蒸馏的非参数化策略记忆（无测试泄漏），15 设置中 13 个提升（SQL +5.0，Research +2.07~+4.27）。

论文三核心数据

主表（20 模型：16 开源 + 4 闭源），以下为组均值：

• 模型终库中位数仅约 75 条，金标库 323.6 条，库大小比 0.20-0.35——欠抽取而非乱存。
• 代表模型明细（Capture F1 / Update op-F1 / Recall@n / Gold-Mem / Full-Pipe）：Kimi-K3 28.14 / 31.69 / 62.09 / 94.99 / 74.85（Full-Pipeline 最高）；GLM-5.2 26.73 / 21.06 / 56.71 / 94.30 / 71.40；GPT-5.6-Sol 21.71 / 25.54 / 56.06 / 96.28 / 70.35；Gemini-3.1-Pro Capture F1 最高 36.37（P 72.49 / R 24.27）但 Full-Pipeline 仅 42.35、OA 高达 42.11%——抽取能力与答题风格是两个独立维度；Llama-3.1-8B Update op-F1 低至 4.44（Del F1 仅 2.37，几乎不会删除）。
• Kimi-K3 悖论：Full-Pipeline 最高 74.85%，但 Capture recall 仅 18.55%、op-F1 31.69%，Grounded 69.26% 且 7.94% 答案无证据支持——最终分高完全可以掩盖残缺、不稳定、被绕过的记忆库。
• URAM vs Agent-only 配对实验：20 个模型 Update op-F1 全部为正（均值 +2.78/+1.92 点），QA 17 个为正（均值 +3.20/+3.67 点，DeepSeek-V4-Pro 最高 +9.77）——用户条件化是必要的，不是锦上添花。
• 用户侧更难：开源模型 user-centric vs agent-centric Full-Pipeline QA 差 14.8 分，而 Capture/Recall 差仅 3.4/0.9 分——瓶颈在「组合使用用户侧证据」而非存取。
• 类型决定难度：Capture F1 按记忆类型 agent_identity/agent_method ≈ 50%、fact 25%、episodic 16%；按生活域只波动 22.7-26.3%——是记忆的类型而非话题领域决定抽取难度。
• 答题风格反转：Qwen3-4B Full-Pipeline 43.6% > Qwen3-5-9B 38.1%，但后者 Capture/Recall/Update/Gold-Mem 全更强；原因是前者 OA 仅 16.2%（敢答）后者 43.1%（过度弃权）——Full-Pipeline 必须与 Grounded/OA/Ung. 联合解读。

三组实验的评估设计都直接服务于各自主张：论文一用「配对比值 + 任务级换血 + 交叉模型」证明 token 指标失效；论文二用「30 设置全覆盖 + 消融定位核心组件 + 长时程压力」证明版本化价值；论文三用「阶段分解 + ΔG2P + 配对变体」证明最终 QA 失效。这是三篇共同的评估美学：指标体系的设计本身就是论点。

六、效果优势的根源解释

6.1 根源机制与证据链

论文一：为什么省 token 反而更慢更贵？

因果链（论文实验已支持）：

1. 摘要类 primitive 重写前缀 → 缓存失效 → 计费反升。KV 缓存与前缀缓存的经济前提是「输入前缀字节不变」，缓存 token 计 0.1× 价；SU 每次压缩都重写历史，使大量可复用前缀作废，于是「处理更少 token、按全价计费的更多」。Copilot 生产 trace 独立观测到压缩周边缓存复用下降（论文引用 Liu et al. 2026）——机制有外部佐证。
2. 步进触发 → 调用次数增加 10-27% → 时延叠加。单次调用更快但调用更多，Devstral 上调用本身还更慢，双重叠加（Terminal-Bench 1/3 token 慢 1.2-1.8× 的直接原因）。
3. 信息保留方式决定后续决策质量。TRC 只删工具输出、保留交互结构（决策骨架「我做了什么、结果如何」仍在），所以成功率近 FC；TR 按时间删整段前缀，早期交互全丢，成功率崩；SU 重写历史虽保信息但摘要器本身会遗漏/失真（−11.0pp）。Terminal-Bench 更糟是因为其工作流依赖中间观察，而 SWE-bench 可从代码重建上下文——信息是否可从环境重建，决定压缩的边际伤害。
4. 聚合成功率掩盖任务换血：总量近 FC ≠ 覆盖同 FC，增益与损失对冲（2-7 新解 vs 6-14 丢失）。

反事实验证：若去掉「触发阈值校准」而用统一绝对阈值，结论可能被各模型上下文行为差异混淆——论文专门校准并分模型报告阈值，消除了这一威胁。

论文二：为什么版本绑定既提精度又降 token？

因果链（论文实验已支持，消融为证）：

1. Native/Restart/U-Fold 把历史摊平在单一上下文 → 撤回的需求及其关联结果继续在场 → 过时信息污染后续决策（Laban et al. 2026 的多轮锚定效应为独立佐证）；Restart 走另一极端全量重做，token 爆炸。
2. GITHARNESS 把「需求→工作区」绑定为版本图 → 基线选择本身就是编辑范围的控制：从语义兼容的历史状态续跑，新需求的边界天然限定修改范围（局部性来自分叉点而非预测受影响工件）→ 撤回需求的关联结果不再进入上下文。
3. 消融反证：去掉历史版本选择，Code 74.0→44.0 且 token 3.5 倍膨胀——局部性确实来自「选对基线」这一步；去掉 INSPECT（不许看历史就决策）同样崩溃，说明基线选择需要主动推理而非最新状态默认。
4. 与 GCC 的差异是因果起点不同：GCC 的版本选择由执行状态驱动（探索需要什么），GitHarness 由需求驱动（用户改了什么）——需求频繁变化的 Search/Code 域正是 GitHarness 领先最大的域（+14/+18 分、token −54.5%/−73.6%），差异与机制吻合。
5. 阅读者推测（论文未直接测量）：需求-工作绑定还消除了「这段代码是为哪个需求写的」的归属歧义，降低了 update agent 的判断负担——此为合理推断而非论文实证。

论文三：为什么 ΔG2P 高达 42.9 点？

因果链（论文实验已支持）：

1. Gold-Memory QA 90+ 证明答案生成不是瓶颈；损失全部来自管线。
2. Capture recall 仅 15.1% → 终库只有金标的 1/5 到 1/3 → 后续 Recall 无论多准，完整支持集大概率根本不在库里（Recall@n < 63% 的上游原因之一）。
3. 不安全删除率 84.1% → 每次错误删除从库中永久移除仍有效的条目，且删除的损害随会话数累积传播（未来所有会话都受影响）——这解释了为什么 Update 分数低是结构性风险而非局部噪声。值得对照的是 Mem0 的工业选择：其 2026 年 4 月算法改为「单遍 ADD-only 抽取、不做 UPDATE/DELETE，记忆只累积不覆写」——用放弃删除来回避删除的风险，代价是库膨胀与过时条目长期在场。DyadMem 的数据（不安全删除率 84.1%/78.1%，gold 条件下 Update op-F1 组均值也仅 18.55/24.47）说明工业界的回避有其道理：当前模型在「何时该删」上的判断接近随机。
4. 「找到一条 ≠ 凑齐全套」：Hit@1 85-89% 但 Recall@n < 63%，多证据问题的支持集组装是独立失败模式。
5. 类型难度分层（agent 侧 50% vs episodic 16%）提示机制：显式、可复用的规则文本好抽，异质事实与事件难抽——欠抽取集中在信息密度低、表述分散的类型上。

6.2 相关工作检索与对照

围绕三条机制假设做外部检索，结果如下：

与 10-03/10-04 日报相关工作对照：10-03 记忆范式三篇（Mem++/MemFit/Beyond Memory）的共识「写时蒸馏有害」与论文一 SU −11.0pp、论文三 Update 不安全删除率 84.1% 构成三方独立会师——在信息写入时用 LLM 重写/合并/删除，是当前记忆管线中最不可靠的环节；Mem++ 的非破坏性存储 + 读时选择，本质是论文一 TRC 哲学（保留原件、控制可见性）在跨会话记忆上的对应物。10-05 CLM 精读中「编辑即缓存失效」的 SCR 补丁与 TokenPilot/论文一互为印证。AI HOT 10-06 日报中 GraphMemory 的「存储量与每查询处理量解耦」（O(N)→O(1)）与 GitHarness 的版本化按需恢复，共享同一个设计公理：上下文的组织结构决定其经济性。

6.3 综合判断与未决问题

多研究共同支持的机制：

1. 「保留交互/决策骨架、删除冗余观察」优于「重写历史」——论文一 TRC 最优区 + Complexity Trap + FOCUS 三方独立支持（不同 scaffold、不同模型、不同实现粒度）。
2. 「重写式压缩破坏前缀缓存、使计费与时延反直觉」——论文一 + Copilot trace + TokenPilot + CLM 四方独立发现，且 TokenPilot 以此为核心优化目标拿到 −61%~−87% 成本收益，反证充分。
3. 「最终答案 QA 不能评估记忆/压缩系统」——论文三的 ΔG2P/Kimi-K3 悖论与论文一的任务级换血（总量同、覆盖异）是同一结论在两个领域的实例。

仍属合理推测的部分：GitHarness 的需求-工作绑定消除「代码归属歧义」（6.1 第 5 条）；论文三「用户侧证据的组合使用是 QA 瓶颈」的机制（领域差异小、阶段差异小、QA 差异大）尚无过程性证据定位失败模式。

适用边界与可能失效条件：

• TRC 最优区成立于「决策可从交互结构 + 环境重建」的编码/终端类负载；对话型任务（无环境可重建）可能不同——论文一未测对话域，此为明确的外推边界。
• GitHarness 依赖需求解读与基线选择的准确性，作者自承在模糊或矛盾反馈下会退化；恢复兼容状态也不保证下游 Agent 一定保留所有未受影响的工作（作者自列的局限）。合成轨迹构造的 MTAgentBench（7 轮、九种细粒度变化算子由协议生成）与真实用户反馈的分布差异未经检验——真实需求的变更往往更隐晦、更情绪化、更少显式锚点。
• DyadMem 的对话由模型生成（dialogue-first 但非真实用户流量），自然记忆需求率（真实场景中多远、多久需要一次记忆）未被测量——这正是 RealCompanion 类真实语料基准的互补价值（其测得真实陪伴对话的自然记忆需求率仅 3.4%、所需消息中位距离 2,157 条）；且 20 个被测模型的行为分布可能随生成器模型偏移。
• DyadMem 的对话由模型生成（dialogue-first 但非真实用户流量），自然记忆需求率（真实场景中多远、多久需要一次记忆）未被测量——这正是 RealCompanion 类真实语料基准（10-06 日报）的互补价值；且 20 模型的行为分布可能随生成器模型偏移。

七、必要知识反推

假设一个零知识的人要独立完成这三项工作，最少需要什么？

领域知识层：

• Agent 执行模型的细节（论文一/二）：mini-swe-agent 循环、SWE-bench/Terminal-Bench 的任务协议与验证器语义、「压缩窗口 = 助手消息 + 工具结果、系统提示词原样保留」这类实现级划分——不理解这些就无法设计出「固定混杂」的受控实验。
• 服务系统的经济学（论文一）：KV 缓存/PagedAttention/前缀缓存的工作原理与三大厂商的缓存计价（0.1×）——不知道「缓存命中与否改变计费结构」，就会把 token 当成本的全部，得出完全错误的结论。
• 版本控制的抽象（论文二）：commit/branch/fork/不可变历史/检查点——GitHarness 的全部设计语言；以及「分支即基线选择的副产品」这种对 Git 语义的再诠释。
• 记忆的分类学与双时态性（论文三）：情景记忆 vs 语义记忆的认知科学划分、用户画像 vs 关系性知识的区别、「一条记忆何时为真」的有效性问题——URAM 六类划分需要这张概念地图。

方法论知识层：

• 析因实验设计与统计推断（论文一）：主效应/交互效应分离、分位数校准、任务级 bootstrap 置信区间、配对比值口径——35,000 次运行的价值全靠这套方法论兑现。
• RL 训练工程（论文二）：GRPO、LoRA、奖励分解与合成（稀疏 + 稠密、组归一化优势）、rollout-balanced 损失——λ=0.2 的平衡点需要理解「过度优化代理指标伤害真实目标」的经典教训。
• 基准构造与标注科学（论文三）：dialogue-first 范式、金标传播（修一处标注沿记忆索引传播到受影响 QA）、判官校准（多判官排序稳定性 + 人机 κ）、配对变体实验设计。

工程知识层：

• vLLM 部署、多节点 A800 集群、三 harness（TCRAG/StackPlanner/OpenHands）的接入改造、57,751 美元规模的数据管线预算与质检流程；
• 工业界记忆系统的实际形态（论文三需要知道 Mem0 的 ADD/UPDATE/DELETE/NOOP 操作语义、Zep 的双时态图、MemGPT/Letta 的分层记忆块）——不知道产业界在做什么，就无法定位「现有基准缺什么」。

知识融合的关键节点：

1. 论文一的核心创造 = 把「药物析因设计」迁移到「系统策略空间」 + 把「缓存计价」注入「效率评测」——两个外来视角的相遇造就了「token 不预测成本」这一反共识。
2. 论文二的核心创造 = 把 Git 的「分叉点决定变更范围」哲学迁移到「需求-工作绑定」——版本控制的领域知识与多轮协作的痛点在此发生化学反应：不预测受影响工件，而是选对分叉点。
3. 论文三的核心创造 = 把「关系特异性」（生态学/社会学概念：同一物种在不同共生关系中行为不同）迁移到 Agent 记忆定义 + 把软件工程的「全流程质检」迁移到评测协议——URAM 不是一个新数据集类别，而是一个被所有前人隐式忽略的记忆本体论空格。

八、论文中可以提取的通用性灵感

灵感一：代理指标与真实成本之间隔着缓存结构。 核心思想：一个系统中间量的减少（token 数）不等于终点量的改善（钱、时间），当中间量与终点量之间存在「复用/缓存」机制时，破坏复用的「优化」会倒贴。 论文证据：1/3 token 慢 20-80%（Terminal-Bench）；SU 类策略计费 0.85-0.95× 于 0.59× token；TokenPilot 以缓存连续性为核心再省 61-87%。 推广场景：① 数据库查询优化中「逻辑读减少但 buffer cache 命中率下降」的计划倒退；② CDN/边缘计算里破坏内容寻址的「压缩」；③ 组织管理中「减少会议数量但打断深度工作的连续性」；④ 编译器中破坏增量编译依赖的「清理重构」。

灵感二：删除的信息类型决定伤害，删除的信息总量不决定。 核心思想：按「内容类型」选择性删除（保交互骨架、删工具输出）优于按「时间」删除（删最旧）或按「模型重写」（摘要）——关键不是删多少，而是删掉的部分是否可从环境/结构重建。 论文证据：TRC 成功率近 FC 而 TR/SU 崩；SWE-bench（可从代码重建）与 Terminal-Bench（依赖历史观察）伤害差一个量级；Complexity Trap 独立复现。 推广场景：① 人脑记忆的「遗忘曲线」对程序性记忆（怎么做）与情景记忆（做过什么）的不同保留策略；② 数据治理中「删原始日志保事件索引」vs「删索引保日志」；③ 代码 review 时保留 diff 上下文骨架；④ API 设计中「保留调用记录、清除响应体」的调试日志策略；⑤ 增量学习中的「保留任务边界/损失曲线元数据、清除中间检查点」。

灵感三：分叉点决定变更范围——用「选对起点」替代「预测影响面」。 核心思想：当一次修改的波及范围难以预测时，把「可回滚的版本历史 + 基线选择」作为控制爆炸半径的机制：从不同基线出发，修改范围天然不同。 论文证据：去掉历史版本选择 Code 74.0→44.0、token 3.5 倍；Git 的分支语义在 Agent 工作记忆上的直接移植。 推广场景：① 数据库事务的 savepoint；② 系统运维的金丝雀发布与快照回滚；③ 法律合同的修订条款（修订从哪个版本起算）；④ 个人知识管理中「分支笔记」而非「线性覆写」；⑤ 多智能体协作中任务分派的「从共识状态分叉」。

灵感四：评估一个多级管线，要测每一级 + 总量差值，而非只测终点。 核心思想：终点指标（最终 QA、总成功率）会把上游残缺、中游错误、下游绕过全部对冲掉；给每个生命周期阶段独立金标 + 测「金标条件版与自主版的差」（ΔG2P），才能定位损失来源。 论文证据：Gold-Memory 90.6% vs Full-Pipeline 47.7%（ΔG2P 42.9）；Kimi-K3 终分最高但库残缺；不安全删除率 84.1% 若无 Update 金标永远不可见。 推广场景：① RAG 系统分环节评测（检索/重排/生成）；② 供应链质检的工序级抽检 + 终检对比；③ 教育测量中的诊断性评估 vs 总结性评估；④ MLOps 的分段数据质量监控。

灵感五：为「关系特异性知识」建立独立本体。 核心思想：关于实体 A 的知识、跨实体可迁移的知识、以及「这个系统与这个实体之间因共同历史而形成的行为约定」是三种不同的知识——第三种被系统性忽视。 论文证据：URAM 变体在 20 个模型上 Update 全正、17 个模型 QA 为正；agent 侧 Capture F1 ≈ 50% vs episodic 16%（关系规则比事件好学）。 推广场景：① 医患关系中「这位医生与这位患者的沟通惯例」独立于病历事实；② 客户成功系统中「与该客户的 escalations 历史约定」；③ 师徒制中师傅对徒弟的因材施教规则；④ 多 Agent 系统中 agent 对间的协作默契建模。

灵感六：训练信号与评测维度对齐。 核心思想：当一个组件由 RL 训练时，奖励的分解维度应与最终评测的分解维度同构，且代理维度的权重需要实验校准（过重则伤害真实目标）。 论文证据：query-tracking 奖励三维（保真/最优/过时排除）= 评测三维；λ=0.2 最优、λ=1 时任务分 70→65。 推广场景：① 推荐系统的代理指标与留存的关系；② 学生刷题（对齐考试形式）vs 学懂（对齐能力）；③ 自动驾驶的接管率与安全冗余；④ 代码生成中单测通过率与真实正确性的错位。

结语：三种研究范式的示范

这三篇论文还分别示范了三种可复用的研究范式。测量型研究（论文一）：当一个领域的方法论文爆炸但决策维度从未被拆解时，系统的析因测量本身就是贡献——它的风险不在「没有新方法被诟病」，而在实验规模与混杂控制必须无可挑剔（35,000 次运行、阈值校准、三模型交叉就是它的防御工事）。抽象迁移型研究（论文二）：把一个领域的成熟抽象（Git）完整迁移到另一个领域的痛点上，关键在找到同构的精确对应（需求↔commit 内容、工作区↔工作树、反馈↔branch），并在迁移中做必要的再诠释（branching 是基线选择的副产品）。定义先行型研究（论文三）：当一个本体论空格（关系特异性记忆）被所有前人隐式绕开时，先命名它、再为它构造全生命周期金标——定义的价值由那个「20 个模型全部为正」的受控实验兜底，而非靠基准规模本身。

附录：三篇论文的互补读法

若只读一篇：关心成本与部署读论文一（结论可直接指导 harness 选型——优先 TRC/堆叠阈值策略、晚压、按模型调优）；关心多轮协作产品读论文二（需求变更场景的完整方案 + 可插拔设计）；关心记忆系统创业/评测读论文三（20 模型的全管线短板清单就是产品路线图）。三篇合读的最大收益是第六部分的机制会师：「写时重写有害」与「结构化保留有益」在压缩、版本管理、记忆评测三个尺度上同时成立——这大概率不是巧合，而是当前 LLM「重写可靠性不足 + 缓存经济结构」两个底层约束的必然投影。下一步的开放问题：当模型的重写可靠性提升（如更强的约束解码），TRC 哲学的最优区会否向摘要区移动？DyadMem 式全生命周期金标 + GitHarness 式结构化恢复的结合——「可版本化、可审计、按需恢复的记忆库」——是两条线最自然的交汇点。