尧图网页设计 
摘要本文解读ISSTA 2026论文《AttnCompress: Dynamic Attention-Guided Trajectory Compression for Software Engineering Agents》。该论文提出AttnCompress一个免训练的软件工程 Agent 轨迹压缩中间件通过融合PPL 尖峰结构分块、代理模型注意力打分与滚动窗口动态维护三种机制在不改动后端大模型的前提下压缩长程交互历史其特别之处在于把「保留什么」从固定规则变成由小模型注意力实时给出的相关性打分。实验表明在 SWE-bench Verified 上取得压缩方法中最高的 53.17% 通过率同时把输入 token 降低 21.6%、总成本降低 33.6%并在七种编程语言与五个代理模型上保持稳定为长程代码 Agent 的上下文管理与成本控制提供了重要借鉴。视频讲解点击观看 B 站视频摘要论文基本信息背景与动机研究主线从问题到结论基准/方法设计分类全景方法细节实验设计与结果结果对比总结关键发现局限性常见问题FAQAttnCompress 需要训练或微调吗为什么不直接用大模型摘要历史压缩会不会把 Agent 需要的代码切碎代理模型换成别的模型还有效吗压缩率设成多少合适参考链接论文基本信息项目内容标题英文AttnCompress: Dynamic Attention-Guided Trajectory Compression for Software Engineering Agents标题中文Agent 轨迹太长怎么办用代理模型的注意力做动态上下文压缩作者Zhengran Zeng, Yixin Li, Rui Xie, Wei Ye, Shikun Zhang机构北京大学软件工程国家工程研究中心 / 知识计算实验室KCL会议ISSTA 2026PACMSE Vol.3, ISSTA058arXiv2609.08318论文 DOI10.1145/3832149背景与动机自主软件工程ASEAgent 以 ReAct 循环解题给定 GitHub issue模型先产生思考与动作环境执行后返回观测如此往复直到通过测试。问题在于这条轨迹会迅速变长——论文统计显示交互轨迹里观测Observationtoken 占用 62.6%远高于动作的 24.8%、思考的 8.6% 与任务输入的 4%。观测之所以膨胀是因为工具输出动辄包含整份文件内容、完整日志与错误栈而这些内容里真正与当前 bug 相关的往往只有几十行。已有上下文压缩方法大致分三类各自解决了一半问题启发式掩码ObsMask直接丢弃较旧的观测输出SlidingWindow只保留固定 token 预算内的最近内容。它们便宜、快但假设「旧信息一定不重要」删除不可回滚。选择式压缩LLMLingua-2用一个小分类器在 token 级别判断去留RECOMP、Provence一类需要训练专门的打分模块。它们精度尚可但 token 粒度的删除会破坏代码语法与 JSON 日志结构训练依赖也削弱了即插即用性。摘要式压缩LLMSummary与前一任 SOTAAgentDiet用另一个大模型把历史重写成更短的文本。它们保留高层语义但改写会抹掉精确的路径、行号与变量名甚至引入幻觉而且每步都调用大模型会带来明显的延迟与成本。论文进一步指出两个具体的失败模式并用真实数据把它们钉死。其一是粒度失配在django-11133实例中Agent 读取response.py得到七百多行输出其中真正有用的只有make_bytes方法约十五行消息级剪裁会保留整段噪声token 级剪裁则会把函数与 JSON 结构切碎。其二是调试焦点漂移Agent 在第 1 至 10 轮全仓浏览第 11 至 20 轮把注意力转向auth_service.py直到第 21 轮才发现根因是被剪掉的utils.py里一个错误的正则表达式——静态压缩已经把这条线索永久删除。作者随机抽取 100 条摘要式轨迹用 LLM 辅助审计加人工复核发现其中40 条存在焦点漂移问题。这两张图把上述挑战画成了具体的时间线一张显示大段输出里只有一小段函数是有效信息另一张显示调试焦点如何在多个文件之间迁移而静态压缩会在迁移过程中丢弃后来才变关键的证据。图 1粒度失配Granularity Mismatch——一次文件读取吐出的大部分内容都是低信息量噪声只有 make_bytes 一小段有用。图 2焦点漂移Focus Shifting——Agent 的调试焦点在多个文件间迁移静态压缩会永久丢弃 utils.py 中后来才关键的线索。ReAct 工作流的完整闭环与轨迹 token 构成如下观测是上下文膨胀的主因因此压缩的收益几乎全部来自对工具输出的处理。图 3ReAct Agent 工作流左与轨迹 token 分布右Observation 占 62.6%是上下文膨胀的主因。研究主线从问题到结论图 7研究主线——从轨迹爆上下文的问题到静态压缩不可回滚的动机、PPL 分块与注意力打分设计再到 SWE-bench Verified 53.17% 的结论。基准/方法设计AttnCompress 的定位是一个插在轨迹管理器与后端大模型之间的中间件不需要训练、不修改 Agent 的任何参数。给定原始轨迹 $T{(a_1,o_1),\dots,(a_t,o_t)}$其中 $a_t$ 是 Agent 的动作、$o_t$ 是环境观测目标是实时维护一份压缩轨迹 $T$使 $|T| \ll |T|$ 的同时尽量保留与当前推理步 $s_t$ 相关的语义信息。三段流水线各解决一个具体问题结构感知分块解决粒度失配。用一个小的代理模型监测工具输出的困惑度波动在语义边界处切分得到语义连贯的「块」而不是按 token 硬切。代理注意力打分解决「保留什么」。把当前上下文、新观测与一个生成起始 token 拼接后前向一次取注意力权重作为历史块与当前需求的相关性度量。动态滚动维护解决不可回滚。历史被拆成长时归档、短时缓冲与最近若干轮三段短时区每轮重估缓冲满时触发全局刷新被丢弃的深历史有机会复活。效率上的关键设计是困惑度分块与注意力打分来自同一次前向长时归档文本保持不变因此可以最大化前缀缓存命中率——这直接决定了压缩开销能否被接受。分类全景图 8上下文压缩方法分类——启发式掩码ObsMask / SlidingWindow、选择式压缩LLMLingua-2 / RECOMP、摘要式压缩LLMSummary / AgentDiet与注意力引导的动态压缩AttnCompress。方法细节阶段一PPL 尖峰结构分块。对工具输出按行计算困惑度 $PPL(l_i)\exp\left(-\frac{1}{|l_i|}\sum_{x\in l_i}\log P(x \mid x_{ \tau$ 处即切分为边界长度仅一行的小块并入前一块。这样切出的块在语法与语义上相对自洽避免了把函数体或 JSON 对象从中间劈开。阶段二代理注意力打分与贪心选择。对每个候选块计算 $Score(b_i)\frac{1}{|b_i|}\sum_{t\in b_i}A(q_{gen},t)$即生成起始 token $q_{gen}$ 投射到块内所有 token 的平均注意力。给定压缩率 $\rho$token 预算为 $L_{budget}\rho\sum_i |b_i|$把所有块按分数降序排序后贪心填入直到用满预算未选中的块直接丢弃。这里有一个容易被忽略的设计点打分用的不是「当前思考」的文本而是生成起始 token 的注意力因为在因果语言模型里只有必须回看前文才能生成的 token才无偏地代表「下一步要看什么」。阶段三三段式滚动窗口与全局刷新。上下文被切分为三类最近 $k$ 轮保持原始保证文件名、行号等可执行细节不丢中间的短时缓冲每轮重估重压最早的区间作为固定归档。缓冲未满时执行增量更新只重压短时区长时区文本不变当短时缓冲累计超过 $M$ 轮时触发全局刷新把长时归档与短时缓冲合并做一次全局选择于是先前被丢弃的深历史可以重新被召回代价是前缀缓存失效因此低频执行。图 4AttnCompress 框架总览——拦截原始轨迹做结构感知分块用代理模型注意力打分再用滚动窗口动态维护压缩上下文。实现上代理模型选用Qwen3-4B-Instruct参数小、开销低同时对代码语法与上下文有足够理解力。默认超参为尾部轮数 $k2$、压缩率 $\rho0.2$、分块阈值 $-2$、注意力层取最后一层、滚动窗口 $M10$这些取值由 100 例验证集上的预实验确定。实验设计与结果评测用两个互补基准。SWE-bench Verified包含 500 例人工验证任务论文沿用 AgentDiet 的实例划分100 例作为验证集用于调参与消融200 例测试集严格保留给主对比与代理模型泛化实验。Multi-SWE-bench-Flash包含 300 例、覆盖 Rust、TypeScript、JavaScript、Java、Go、C、C 七种语言多数任务需要先修环境构建错误。所有方法统一集成在Trae-Agent框架内比较尾部轮数对齐为 $k2$摘要类基线使用与 Agent 相同的 LLM 骨干成本按真实的前缀缓存折扣计算。主对比结果三种后端 LLM 的均值如下方法Pass (%)Input (k)总成本 ($)StepOriginal全上下文55.171118.160.118945.93ObsMask47.17628.930.044363.47SlidingWindow49.83588.060.096851.21LLMSummary50.83810.520.112652.54AgentDiet51.17822.440.142948.12AttnCompress53.17644.660.094952.43消融实验把三条组件的贡献排序得很干净变体Pass (%)Input (k)总成本 ($)StepAttnCompress完整42.0547.270.055745.89去掉 PPLtoken 级剪裁39.0622.370.063550.48去掉注意力随机选块35.0566.810.056747.38去掉滚动窗口固定压缩37.0514.360.061948.44跨语言泛化Multi-SWE-bench-Flash七种语言方法Pass (%)Input (k)总成本 ($)StepOriginal20.331629.380.105752.83ObsMask15.72719.770.037672.05AgentDiet18.331014.700.113258.45AttnCompress19.67879.770.082662.38超参敏感性方面尾部轮数从 2 加到 10 可把通过率提到 44.0%但成本从 0.0557 涨到 0.0821 美元压缩率提到 0.3 时通过率微升至 43.0%降到 0.1 则掉到 40.0%分块阈值越小切得越细越好$-2$ 与 $0$ 都能拿到 42.0%粗粒度 $2$ 掉到 39.0%注意力层位从首层到末层结果接近41.0% / 43.0% / 42.0%说明相关性信号对层不敏感窗口从 2 加到 10 把通过率从 35.0% 提到 42.0%而对 token 开销影响很小因为窗口内的内容本身已经压缩过。延迟拆解显示AttnCompress 平均端到端耗时 366.7 秒其中压缩只占 66.6 秒作为对比AgentDiet 平均需要 498.5 秒摘要开销 248.1 秒而 ObsMask 与 SlidingWindow 分别只要 303.6 秒与 284.7 秒但通过率明显更低。AttnCompress 恰好落在「启发式的快」与「摘要式的好」之间。图 5端到端延迟拆解——AttnCompress 平均 366.7 秒比 AgentDiet 的 498.5 秒快 26.4%。图 6Multi-SWE-bench-Flash 各语言通过数——AttnCompress 在 Java、Rust、C 上与全上下文持平并优于其他压缩方法。结果对比总结图 9结果对比总结——通过率从 AgentDiet 的 51.17% 提升到 AttnCompress 的 53.17%同时总成本降低 33.6%。关键发现压缩方法中通过率最高AttnCompress 在 SWE-bench Verified 上取得53.17%的平均通过率高于 AgentDiet 的 51.17%、LLMSummary 的 50.83%、SlidingWindow 的 49.83%、LLMLingua 的 48.67%、ObsMask 的 47.17% 与 Random 的 48.17%相对前一任 SOTA 提升约 3.9%。效果与成本同时改善总成本降到0.0949 美元比 AgentDiet 的 0.1429 美元低33.6%比全上下文的 0.1189 美元低 20.2%输入 token 从 822.44k 降到644.66k降幅 21.6%。三条组件缺一不可且有排序去掉注意力打分改成随机选块通过率掉到 35.0%损失7.0 个点去掉滚动窗口掉到 37.0%损失 5.0 个点把 PPL 分块换成 token 级剪裁掉到 39.0%损失 3.0 个点。注意力在过滤噪声而非单纯砍 token注意力模块把平均步数从 50.48 压回45.89而 Random 与 LLMLingua 分别要 61.42 与 58.31 步说明破坏语义连贯会让 Agent 反复做冗余动作。跨语言接近全上下文在 Multi-SWE-bench-Flash 七种语言上通过率19.67%对全上下文的 20.33% 达到 96.7% 的相对性能输入 token 从 1629.38k 降到 879.77k。跨模型族可迁移把代理模型换成 Qwen3-1.7B/8B、Gemma3-4B、Llama3.2-3B通过率只在 44.5%–46.5% 之间波动块级注意力排序与 Qwen3-Coder-30B 的 Spearman 相关系数为 0.56–0.64前 20% 重叠率稳定在 0.62–0.66。局限性失败模式仍然存在作者人工检查失败样例后指出压缩依然可能删掉「后来才变重要」的信息例如早期的文件路径、辅助函数或错误信息一旦后续推理依赖这些被删证据Agent 可能做出错误决策且无法在剩余步数内恢复。评测面偏窄主对比与消融都在 SWE-bench Verified 上完成跨框架只验证了Trae-Agent一个实现。作者以算力成本解释这一取舍并强调中间件式设计理论上可迁移但未给出实测。分块方案是工程简化论文采用无重叠分块。作者明确写到在相邻块之间引入重叠区域是可以进一步改善跨边界连贯性的工程改进但会带来额外超参如重叠长度因此留作未来工作。超参仍需定档尾部轮数、压缩率、分块阈值、注意力层位与窗口大小共五个超参都是在一百例验证集上选定的属于成本与性能的折中论文没有给出跨任务族的自动配置方案。常见问题FAQAttnCompress 需要训练或微调吗不需要。它是一个免训练的推理期中间件不增加可训练参数、不改动后端 Agent 的参数只用一个 4B 级的小代理模型在每一步做一次前向同时取出困惑度与注意力两类信号。为什么不直接用大模型摘要历史摘要式方法如 AgentDiet用另一个 LLM 重写历史既会把精确的文件路径、行号、变量名抹掉又会在每一步引入额外的推理开销。论文的测量显示AgentDiet 的摘要开销平均达 248.1 秒而 AttnCompress 的压缩开销只有 66.6 秒端到端总时间也更快。压缩会不会把 Agent 需要的代码切碎这正是 PPL 尖峰分块要解决的问题。它按语义边界切块而不是按 token 切消融显示把结构分块换成 token 级剪裁通过率从 42.0% 掉到 39.0%平均步数也从 45.89 升到 50.48说明语法结构确实在起作用。代理模型换成别的模型还有效吗有效。论文在 Qwen3-1.7B/4B/8B、Gemma3-4B 与 Llama3.2-3B 五个代理模型上做了实验在 Qwen3-Coder-30B 后端上通过率为 43.5%–46.5%在 Gemini-3-Flash 后端上为 68.5%–72.5%说明区分信号与噪声的注意力模式在不同模型族之间可以迁移。压缩率设成多少合适论文默认取 $\rho0.2$。实验显示 0.3 能再涨 1 个点通过率、0.1 会掉 2 个点而 0.2 在成本与效果之间提供了较好的性价比也保留了显著的上调空间。参考链接论文 arXiv 摘要页https://arxiv.org/abs/2609.08318论文 DOIACM PACMSE, ISSTA 2026https://dl.acm.org/doi/10.1145/3832149H2O: Heavy-Hitter Oracle注意力作为重要性信号的源头工作NeurIPS 2023https://arxiv.org/abs/2306.14048LongCodeZip基于困惑度的代码长上下文压缩本文 PPL 分割依据https://arxiv.org/abs/2510.00446SWE-bench: Can Language Models Resolve Real-world Github Issues?ICLR 2024https://arxiv.org/abs/2310.06770给大家推荐一款自用写文献综述、无虚构文献的 AI复旦大学 FudanNLP 团队自研 切问学术官网qiewenpaper.com覆盖3.6 亿篇可溯源真实中英文文献能自动整合文献观点生成规范综述还能挖掘研究创新点、复现实验配合视频教学新手快速上手文献综述写作后记博客的关键词集中在编程、算法、机器人、人工智能、数学等等持续高质量输出中。讨论QQ群白拾的小屋 (750365700)⭐B站账号白拾的物理AI组会活跃于知识区和动画区✨GitHub主页YhbCode000工程文件 【ISSTA 2026】AttnCompress：Agent 轨迹太长怎么办，用代理模型的注意力做动态上下文压缩｜从 LLM Agent 上下文工程视角
摘要本文解读ISSTA 2026论文《AttnCompress: Dynamic Attention-Guided Trajectory Compression for Software Engineering Agents》。该论文提出AttnCompress一个免训练的软件工程 Agent 轨迹压缩中间件通过融合PPL 尖峰结构分块、代理模型注意力打分与滚动窗口动态维护三种机制在不改动后端大模型的前提下压缩长程交互历史其特别之处在于把「保留什么」从固定规则变成由小模型注意力实时给出的相关性打分。实验表明在 SWE-bench Verified 上取得压缩方法中最高的 53.17% 通过率同时把输入 token 降低 21.6%、总成本降低 33.6%并在七种编程语言与五个代理模型上保持稳定为长程代码 Agent 的上下文管理与成本控制提供了重要借鉴。视频讲解点击观看 B 站视频摘要论文基本信息背景与动机研究主线从问题到结论基准/方法设计分类全景方法细节实验设计与结果结果对比总结关键发现局限性常见问题FAQAttnCompress 需要训练或微调吗为什么不直接用大模型摘要历史压缩会不会把 Agent 需要的代码切碎代理模型换成别的模型还有效吗压缩率设成多少合适参考链接论文基本信息项目内容标题英文AttnCompress: Dynamic Attention-Guided Trajectory Compression for Software Engineering Agents标题中文Agent 轨迹太长怎么办用代理模型的注意力做动态上下文压缩作者Zhengran Zeng, Yixin Li, Rui Xie, Wei Ye, Shikun Zhang机构北京大学软件工程国家工程研究中心 / 知识计算实验室KCL会议ISSTA 2026PACMSE Vol.3, ISSTA058arXiv2609.08318论文 DOI10.1145/3832149背景与动机自主软件工程ASEAgent 以 ReAct 循环解题给定 GitHub issue模型先产生思考与动作环境执行后返回观测如此往复直到通过测试。问题在于这条轨迹会迅速变长——论文统计显示交互轨迹里观测Observationtoken 占用 62.6%远高于动作的 24.8%、思考的 8.6% 与任务输入的 4%。观测之所以膨胀是因为工具输出动辄包含整份文件内容、完整日志与错误栈而这些内容里真正与当前 bug 相关的往往只有几十行。已有上下文压缩方法大致分三类各自解决了一半问题启发式掩码ObsMask直接丢弃较旧的观测输出SlidingWindow只保留固定 token 预算内的最近内容。它们便宜、快但假设「旧信息一定不重要」删除不可回滚。选择式压缩LLMLingua-2用一个小分类器在 token 级别判断去留RECOMP、Provence一类需要训练专门的打分模块。它们精度尚可但 token 粒度的删除会破坏代码语法与 JSON 日志结构训练依赖也削弱了即插即用性。摘要式压缩LLMSummary与前一任 SOTAAgentDiet用另一个大模型把历史重写成更短的文本。它们保留高层语义但改写会抹掉精确的路径、行号与变量名甚至引入幻觉而且每步都调用大模型会带来明显的延迟与成本。论文进一步指出两个具体的失败模式并用真实数据把它们钉死。其一是粒度失配在django-11133实例中Agent 读取response.py得到七百多行输出其中真正有用的只有make_bytes方法约十五行消息级剪裁会保留整段噪声token 级剪裁则会把函数与 JSON 结构切碎。其二是调试焦点漂移Agent 在第 1 至 10 轮全仓浏览第 11 至 20 轮把注意力转向auth_service.py直到第 21 轮才发现根因是被剪掉的utils.py里一个错误的正则表达式——静态压缩已经把这条线索永久删除。作者随机抽取 100 条摘要式轨迹用 LLM 辅助审计加人工复核发现其中40 条存在焦点漂移问题。这两张图把上述挑战画成了具体的时间线一张显示大段输出里只有一小段函数是有效信息另一张显示调试焦点如何在多个文件之间迁移而静态压缩会在迁移过程中丢弃后来才变关键的证据。图 1粒度失配Granularity Mismatch——一次文件读取吐出的大部分内容都是低信息量噪声只有 make_bytes 一小段有用。图 2焦点漂移Focus Shifting——Agent 的调试焦点在多个文件间迁移静态压缩会永久丢弃 utils.py 中后来才关键的线索。ReAct 工作流的完整闭环与轨迹 token 构成如下观测是上下文膨胀的主因因此压缩的收益几乎全部来自对工具输出的处理。图 3ReAct Agent 工作流左与轨迹 token 分布右Observation 占 62.6%是上下文膨胀的主因。研究主线从问题到结论图 7研究主线——从轨迹爆上下文的问题到静态压缩不可回滚的动机、PPL 分块与注意力打分设计再到 SWE-bench Verified 53.17% 的结论。基准/方法设计AttnCompress 的定位是一个插在轨迹管理器与后端大模型之间的中间件不需要训练、不修改 Agent 的任何参数。给定原始轨迹 $T{(a_1,o_1),\dots,(a_t,o_t)}$其中 $a_t$ 是 Agent 的动作、$o_t$ 是环境观测目标是实时维护一份压缩轨迹 $T$使 $|T| \ll |T|$ 的同时尽量保留与当前推理步 $s_t$ 相关的语义信息。三段流水线各解决一个具体问题结构感知分块解决粒度失配。用一个小的代理模型监测工具输出的困惑度波动在语义边界处切分得到语义连贯的「块」而不是按 token 硬切。代理注意力打分解决「保留什么」。把当前上下文、新观测与一个生成起始 token 拼接后前向一次取注意力权重作为历史块与当前需求的相关性度量。动态滚动维护解决不可回滚。历史被拆成长时归档、短时缓冲与最近若干轮三段短时区每轮重估缓冲满时触发全局刷新被丢弃的深历史有机会复活。效率上的关键设计是困惑度分块与注意力打分来自同一次前向长时归档文本保持不变因此可以最大化前缀缓存命中率——这直接决定了压缩开销能否被接受。分类全景图 8上下文压缩方法分类——启发式掩码ObsMask / SlidingWindow、选择式压缩LLMLingua-2 / RECOMP、摘要式压缩LLMSummary / AgentDiet与注意力引导的动态压缩AttnCompress。方法细节阶段一PPL 尖峰结构分块。对工具输出按行计算困惑度 $PPL(l_i)\exp\left(-\frac{1}{|l_i|}\sum_{x\in l_i}\log P(x \mid x_{ \tau$ 处即切分为边界长度仅一行的小块并入前一块。这样切出的块在语法与语义上相对自洽避免了把函数体或 JSON 对象从中间劈开。阶段二代理注意力打分与贪心选择。对每个候选块计算 $Score(b_i)\frac{1}{|b_i|}\sum_{t\in b_i}A(q_{gen},t)$即生成起始 token $q_{gen}$ 投射到块内所有 token 的平均注意力。给定压缩率 $\rho$token 预算为 $L_{budget}\rho\sum_i |b_i|$把所有块按分数降序排序后贪心填入直到用满预算未选中的块直接丢弃。这里有一个容易被忽略的设计点打分用的不是「当前思考」的文本而是生成起始 token 的注意力因为在因果语言模型里只有必须回看前文才能生成的 token才无偏地代表「下一步要看什么」。阶段三三段式滚动窗口与全局刷新。上下文被切分为三类最近 $k$ 轮保持原始保证文件名、行号等可执行细节不丢中间的短时缓冲每轮重估重压最早的区间作为固定归档。缓冲未满时执行增量更新只重压短时区长时区文本不变当短时缓冲累计超过 $M$ 轮时触发全局刷新把长时归档与短时缓冲合并做一次全局选择于是先前被丢弃的深历史可以重新被召回代价是前缀缓存失效因此低频执行。图 4AttnCompress 框架总览——拦截原始轨迹做结构感知分块用代理模型注意力打分再用滚动窗口动态维护压缩上下文。实现上代理模型选用Qwen3-4B-Instruct参数小、开销低同时对代码语法与上下文有足够理解力。默认超参为尾部轮数 $k2$、压缩率 $\rho0.2$、分块阈值 $-2$、注意力层取最后一层、滚动窗口 $M10$这些取值由 100 例验证集上的预实验确定。实验设计与结果评测用两个互补基准。SWE-bench Verified包含 500 例人工验证任务论文沿用 AgentDiet 的实例划分100 例作为验证集用于调参与消融200 例测试集严格保留给主对比与代理模型泛化实验。Multi-SWE-bench-Flash包含 300 例、覆盖 Rust、TypeScript、JavaScript、Java、Go、C、C 七种语言多数任务需要先修环境构建错误。所有方法统一集成在Trae-Agent框架内比较尾部轮数对齐为 $k2$摘要类基线使用与 Agent 相同的 LLM 骨干成本按真实的前缀缓存折扣计算。主对比结果三种后端 LLM 的均值如下方法Pass (%)Input (k)总成本 ($)StepOriginal全上下文55.171118.160.118945.93ObsMask47.17628.930.044363.47SlidingWindow49.83588.060.096851.21LLMSummary50.83810.520.112652.54AgentDiet51.17822.440.142948.12AttnCompress53.17644.660.094952.43消融实验把三条组件的贡献排序得很干净变体Pass (%)Input (k)总成本 ($)StepAttnCompress完整42.0547.270.055745.89去掉 PPLtoken 级剪裁39.0622.370.063550.48去掉注意力随机选块35.0566.810.056747.38去掉滚动窗口固定压缩37.0514.360.061948.44跨语言泛化Multi-SWE-bench-Flash七种语言方法Pass (%)Input (k)总成本 ($)StepOriginal20.331629.380.105752.83ObsMask15.72719.770.037672.05AgentDiet18.331014.700.113258.45AttnCompress19.67879.770.082662.38超参敏感性方面尾部轮数从 2 加到 10 可把通过率提到 44.0%但成本从 0.0557 涨到 0.0821 美元压缩率提到 0.3 时通过率微升至 43.0%降到 0.1 则掉到 40.0%分块阈值越小切得越细越好$-2$ 与 $0$ 都能拿到 42.0%粗粒度 $2$ 掉到 39.0%注意力层位从首层到末层结果接近41.0% / 43.0% / 42.0%说明相关性信号对层不敏感窗口从 2 加到 10 把通过率从 35.0% 提到 42.0%而对 token 开销影响很小因为窗口内的内容本身已经压缩过。延迟拆解显示AttnCompress 平均端到端耗时 366.7 秒其中压缩只占 66.6 秒作为对比AgentDiet 平均需要 498.5 秒摘要开销 248.1 秒而 ObsMask 与 SlidingWindow 分别只要 303.6 秒与 284.7 秒但通过率明显更低。AttnCompress 恰好落在「启发式的快」与「摘要式的好」之间。图 5端到端延迟拆解——AttnCompress 平均 366.7 秒比 AgentDiet 的 498.5 秒快 26.4%。图 6Multi-SWE-bench-Flash 各语言通过数——AttnCompress 在 Java、Rust、C 上与全上下文持平并优于其他压缩方法。结果对比总结图 9结果对比总结——通过率从 AgentDiet 的 51.17% 提升到 AttnCompress 的 53.17%同时总成本降低 33.6%。关键发现压缩方法中通过率最高AttnCompress 在 SWE-bench Verified 上取得53.17%的平均通过率高于 AgentDiet 的 51.17%、LLMSummary 的 50.83%、SlidingWindow 的 49.83%、LLMLingua 的 48.67%、ObsMask 的 47.17% 与 Random 的 48.17%相对前一任 SOTA 提升约 3.9%。效果与成本同时改善总成本降到0.0949 美元比 AgentDiet 的 0.1429 美元低33.6%比全上下文的 0.1189 美元低 20.2%输入 token 从 822.44k 降到644.66k降幅 21.6%。三条组件缺一不可且有排序去掉注意力打分改成随机选块通过率掉到 35.0%损失7.0 个点去掉滚动窗口掉到 37.0%损失 5.0 个点把 PPL 分块换成 token 级剪裁掉到 39.0%损失 3.0 个点。注意力在过滤噪声而非单纯砍 token注意力模块把平均步数从 50.48 压回45.89而 Random 与 LLMLingua 分别要 61.42 与 58.31 步说明破坏语义连贯会让 Agent 反复做冗余动作。跨语言接近全上下文在 Multi-SWE-bench-Flash 七种语言上通过率19.67%对全上下文的 20.33% 达到 96.7% 的相对性能输入 token 从 1629.38k 降到 879.77k。跨模型族可迁移把代理模型换成 Qwen3-1.7B/8B、Gemma3-4B、Llama3.2-3B通过率只在 44.5%–46.5% 之间波动块级注意力排序与 Qwen3-Coder-30B 的 Spearman 相关系数为 0.56–0.64前 20% 重叠率稳定在 0.62–0.66。局限性失败模式仍然存在作者人工检查失败样例后指出压缩依然可能删掉「后来才变重要」的信息例如早期的文件路径、辅助函数或错误信息一旦后续推理依赖这些被删证据Agent 可能做出错误决策且无法在剩余步数内恢复。评测面偏窄主对比与消融都在 SWE-bench Verified 上完成跨框架只验证了Trae-Agent一个实现。作者以算力成本解释这一取舍并强调中间件式设计理论上可迁移但未给出实测。分块方案是工程简化论文采用无重叠分块。作者明确写到在相邻块之间引入重叠区域是可以进一步改善跨边界连贯性的工程改进但会带来额外超参如重叠长度因此留作未来工作。超参仍需定档尾部轮数、压缩率、分块阈值、注意力层位与窗口大小共五个超参都是在一百例验证集上选定的属于成本与性能的折中论文没有给出跨任务族的自动配置方案。常见问题FAQAttnCompress 需要训练或微调吗不需要。它是一个免训练的推理期中间件不增加可训练参数、不改动后端 Agent 的参数只用一个 4B 级的小代理模型在每一步做一次前向同时取出困惑度与注意力两类信号。为什么不直接用大模型摘要历史摘要式方法如 AgentDiet用另一个 LLM 重写历史既会把精确的文件路径、行号、变量名抹掉又会在每一步引入额外的推理开销。论文的测量显示AgentDiet 的摘要开销平均达 248.1 秒而 AttnCompress 的压缩开销只有 66.6 秒端到端总时间也更快。压缩会不会把 Agent 需要的代码切碎这正是 PPL 尖峰分块要解决的问题。它按语义边界切块而不是按 token 切消融显示把结构分块换成 token 级剪裁通过率从 42.0% 掉到 39.0%平均步数也从 45.89 升到 50.48说明语法结构确实在起作用。代理模型换成别的模型还有效吗有效。论文在 Qwen3-1.7B/4B/8B、Gemma3-4B 与 Llama3.2-3B 五个代理模型上做了实验在 Qwen3-Coder-30B 后端上通过率为 43.5%–46.5%在 Gemini-3-Flash 后端上为 68.5%–72.5%说明区分信号与噪声的注意力模式在不同模型族之间可以迁移。压缩率设成多少合适论文默认取 $\rho0.2$。实验显示 0.3 能再涨 1 个点通过率、0.1 会掉 2 个点而 0.2 在成本与效果之间提供了较好的性价比也保留了显著的上调空间。参考链接论文 arXiv 摘要页https://arxiv.org/abs/2609.08318论文 DOIACM PACMSE, ISSTA 2026https://dl.acm.org/doi/10.1145/3832149H2O: Heavy-Hitter Oracle注意力作为重要性信号的源头工作NeurIPS 2023https://arxiv.org/abs/2306.14048LongCodeZip基于困惑度的代码长上下文压缩本文 PPL 分割依据https://arxiv.org/abs/2510.00446SWE-bench: Can Language Models Resolve Real-world Github Issues?ICLR 2024https://arxiv.org/abs/2310.06770给大家推荐一款自用写文献综述、无虚构文献的 AI复旦大学 FudanNLP 团队自研 切问学术官网qiewenpaper.com覆盖3.6 亿篇可溯源真实中英文文献能自动整合文献观点生成规范综述还能挖掘研究创新点、复现实验配合视频教学新手快速上手文献综述写作后记博客的关键词集中在编程、算法、机器人、人工智能、数学等等持续高质量输出中。讨论QQ群白拾的小屋 (750365700)⭐B站账号白拾的物理AI组会活跃于知识区和动画区✨GitHub主页YhbCode000工程文件