摘要本文解读 FSE 2026PACMSE论文《Reducing Cost of LLM Agents with Trajectory Reduction》。该论文提出AgentDiet一种推理期轨迹削减方法通过融合三类浪费识别、滑动窗口调度与双阈值控制在 agent 执行过程中自动清除轨迹里的无用、冗余与过期信息其特别之处在于把削减逻辑外置为 agent 循环之外的“反射模块”用低成本 LLM 定时清理而不触碰模型本身。实验表明输入 token 下降 39.9%~59.7%、总计算成本下降 21.1%~35.9%而任务成功率变化仅 $-1.0\%$ 到 $2.0\%$直接挑战了“测试时计算必然用性能换效率”的常识为 LLM Agent 的成本工程提供了可复用的借鉴。视频讲解点击观看 B 站视频摘要论文基本信息背景与动机研究主线从问题到结论基准/方法设计分类全景三类轨迹浪费方法细节实验设计与结果结果对比总结关键发现局限性常见问题FAQAgentDiet 会不会降低 agent 的任务成功率为什么不让 agent 自己删除历史步骤反射模块本身的开销有多大为什么阈值 $\theta$ 选 500 而不是更大或更小这套方法能用到其他 agent 上吗这篇论文的写作有什么特点参考链接论文基本信息项目内容标题英文Reducing Cost of LLM Agents with Trajectory Reduction标题中文LLM Agent 轨迹削减用推理期“节食”降低计算成本作者Yuan-An Xiao, Pengfei Gao, Chao Peng, Yingfei Xiong机构北京大学高可信软件技术教育部重点实验室· 字节跳动 Trae 团队会议FSE 2026Proc. ACM Softw. Eng.PACMSE Vol.3DOI 10.1145/3797084arXivhttps://arxiv.org/abs/2509.23586项目网站https://doi.org/10.6084/m9.figshare.30073654背景与动机LLM agent 的基本范式是“在一个循环里使用工具”。每调用一次工具助手消息与工具返回就被拼接进轨迹并且在任务结束前永不移除。结果是长消息在之后的每一步都会被重新计入输入 token。作者统计 SWE-bench Verified 上单个 GitHub issue 的平均轨迹长达48.4K token / 40 步其中工具消息占 30.4K、助手消息占 13.7K、系统与用户消息占 4.4K。行业侧的数字更直观某模型单日 1000 亿 token 的消耗中99% 是轨迹里累积的输入只有 1% 是模型自己生成的。KV Cache 并不能解决这个问题它只缓存部分计算仍要占用显存与 I/O 带宽更麻烦的是一旦修改轨迹中的某个 token其后的所有缓存都会失效——这恰恰是轨迹削减设计的核心难点。已有工作可以分为三类但都不足以直接搬过来Prompt 压缩 / 上下文剪枝Selective Context 按自信息删除 tokenLLMLingua-2 做数据蒸馏压缩RECOMP 做抽取式摘要Provence 做鲁棒剪枝PISCO 把文档蒸馏成向量DietCode 一类则依赖启发式规则。它们全部针对一次性输入不考虑 agent 轨迹逐步累积的特性因此“什么时候削减”这个新问题无从回答。Agent 系统自带的上下文管理Cursor 与 Claude Code 在上下文窗口满时做压缩Trae Agent 把单次工具输出截断到 16 KBSWE-agent 提供可配置的正则规则。这些机制大多是 ad-hoc 的工程手段从未被当作研究问题评测。白盒方法DMC、MEM1、Alpine 等直接改动模型的训练或推理过程需要访问模型内部对商用 API 的 agent 不可用。把这一条线放进历史脉络看会更清楚2023 年的 Selective Context、Gist Tokens、AutoCompressors 把“压缩上下文”做成独立问题2023—2024 年的 LLMLingua、RECOMP、Provence 把它变成即插即用组件MemGPT 甚至把上下文当作操作系统的分页来管理2024—2025 年 SWE-agent、Trae Agent、Claude Code 让 agent 自带上下文管理却始终停留在工程实践。AgentDiet 的位置是把轨迹削减提升为推理期、有调度、可评测的一等方法此后的 ACON、Context-Folding 等工作进一步把它做成一等研究方向。研究主线从问题到结论图 6AgentDiet 研究主线——从轨迹只增不减的问题经三类浪费调研到外置反射模块与最终成本收益。基准/方法设计AgentDiet 的设计可以概括为反射模块 滑动窗口 双阈值反射模块reflection module挂在 agent 循环之外的独立 LLM 调用。当 agent 走到第 $s$ 步时由外层系统显式触发且只允许削减第 $s-a$ 步的内容。滑动窗口提供给反射模型的上下文固定为第 $s-a-b$ 步到第 $s$ 步单次削减的 token 开销被 $ab1$ 步封顶。双阈值被处理的步长度超过 $\theta$ 才调用反射模型削减量超过 $\theta$ 才把结果写回轨迹避免无效调用与无效改写。低成本模型反射模型用 GPT-5 mini比 agent 使用的 Claude 4 Sonnet 便宜约 12 倍。KV Cache 友好只修改固定的近端步前面所有步的缓存都得以保留。图 1LLM agent 的典型工作流——assistant 与 tool 消息被不断拼进轨迹且在整个任务完成前永不移除。分类全景三类轨迹浪费图 7轨迹中的三类浪费及其典型场景分类。论文的 pilot study 手工检查了 Trae Agent 在 SWE-bench Verified 上的 100 条轨迹把浪费归纳为三类无用信息与任务无关的列举与噪声。几乎所有轨迹开头都会列出仓库全部文件其中夹带__pycache__、.egg-info等缓存目录构建和测试也会打印大量过程信息例如 GNU make 会为每个访问的目录输出一行 Entering/Leaving directory。冗余信息同一信息反复出现。最典型的是str_replace_editor它的 JSON 参数里同时包含old_str与new_str而工具返回又把替换结果原样回显同一段内容被重复了三份。过期信息局部步骤完成后即失效。例如先用 grep 定位符号再逐个打开搜索结果中的文件一旦找到问题文件其余文件的内容就再无价值。值得强调的是Trae Agent 本身已经把单次工具输出截断到 16 KB但固定阈值只能挡住极端个例——真正的浪费必须在语义层面识别。方法细节反射模块的 prompt 由四段组成高层任务描述、输入输出格式说明、三类浪费的示例以及防止信息丢失的准则。示例直接来自 pilot study 的发现准则则是在反复观察到“删得不够”或“删得过多”之后逐步打磨出来的。一个关键的设计转折是作者最初希望让 agent 自己削减轨迹为此实现了erase工具让模型用形如{id: 17, takeaway: unrelated content}的参数覆盖历史步。但在 Claude 4 Sonnet 与 Gemini 2.5 Pro 上都失败了——即使 prompt 明确要求“只调用 erase、不要继续原任务”模型仍然继续追查代码。作者推断原因是模型在训练中记住了修 bug 的标准流程产生了不可控的行为惯性。于是改成外置模块时机由系统控制agent 对削减过程完全无感知。延迟 $a$ 步有两个作用。其一是效率层面的只修改固定的近端步前序 KV Cache 不会整体失效而且反射模型的上下文被限制在 $ab1$ 步之内。其二是鲁棒性层面的反射模块无法抹掉最新的、仍在被使用的步也无法一次性清空整段历史偶发的模型失败被限制在局部。图 2反射模块设计——到达第 $s$ 步时只削减第 $s-a$ 步上下文取 $s-a-b$ 到 $s$兼顾开销与削减质量。一个真实案例能说明削减的力度。在pytest-dev__pytest-6202的第 19 步agent 运行测试套件返回结果包含完整的测试列表后面跟着唯一失败的测试。序列化后这一步共 1995 个 token其中 1714 个是浪费。反射模型把这段浪费替换为一句 takeaway“具体测试行已省略、大部分通过”同时完整保留失败的那个测试——这一步最终从 1995 token 压到 259 token压缩率约 87%关键信息一个都没丢。图 3案例研究pytest-dev__pytest-6202第 19 步——冗长的通过测试列表被替换为一句 takeaway保留唯一失败的测试。实验设计与结果实验使用两个基准SWE-bench Verified500 个人工校验的 Python 实例其中 100 个用于手工分析与超参数选择评测时从剩余 400 个中随机抽 200 个调参集与评测集严格隔离和Multi-SWE-bench Flash300 个实例覆盖 Rust、TypeScript、JavaScript、Java、Go、C、C 七种语言难度普遍更高。宿主 agent 是集成后的 Trae Agent分别搭配 Claude 4 Sonnet 与 Gemini 2.5 Pro反射模型为 GPT-5 mini$a2$、$b1$、$\theta500$。效率指标包括 $\text{Keep\%}$保留率$\sum l_\text{reduced} / \sum l_\text{orig} \times 100$、归一化输入 token $I$、归一化输出 token $O$、agent 步成本 \$ 与反射开销 \$性能指标包括通过率 $\text{Pass\%}$、平均步数 $\text{Step}$ 与成功实例平均步数 $\text{PStep}$。设置Keep%↓输入 I↓成本 \$↓Pass%Orig→OursSWE-bench Claude 4 Sonnet30.80.6010.71464.5 →66.5SWE-bench Gemini 2.5 Pro22.60.5910.62350.5 →52.0Multi-SWE-bench Claude 4 Sonnet30.20.5960.67640.0 → 39.0Multi-SWE-bench Gemini 2.5 Pro25.70.4030.55921.7 →22.7超参数研究用的是单独留出的 100 个实例阈值 θ输入 I↓成本 \$↓反射开销 \$Pass%00.5470.6690.118622500.5870.7000.10065500最终0.5860.7070.0776510000.6620.7650.0406020000.7280.8160.01758Original1.0001.000—65$\theta$ 越大反射开销越低但输入 token 的降幅也随之变小因为很多中等长度的步被跳过了$\theta500$ 是唯一同时保住通过率与效率的折衷点。语言模型侧也做了同样的扫描GPT-5 mini 是唯一让 $\text{Step}$ 与 $\text{PStep}$ 同时下降的模型整体额外开销控制在 5.2%~14.8%。图 4每步削减 token 数直方图横轴对数——灰区是未被削减的步左侧短于 $\theta500$ 直接跳过右侧调用后因收益不足未落地。图 5Multi-SWE-bench Flash Gemini 2.5 Pro 的步数分布——原始左大量实例撞上 100 步上限AgentDiet右把长尾显著削薄。结果对比总结图 8从 Original 基线到 AgentDiet 的成本与成功率变化总结。关键发现单步压缩非常激进整体降幅被调度策略限制反射模块在它处理过的内容里删掉了69.2%~77.4%$1-\text{Keep\%}$但整体输入 token 只降 39.9%~59.7%因为它只处理超过 $\theta$ 的长步、并且要延迟 $a2$ 步才动手。成本降幅小于 token 降幅输出 token 不变同时反射步骤本身带来5.5%~11.8%的额外开销折算成绝对金额四个组合的单实例成本分别从 \$0.535、\$0.385、\$1.277、\$0.701 降到 \$0.422、\$0.285、\$0.933、\$0.449。异常增益来自“治长上下文病”Gemini Multi-SWE-bench 上平均步数从57.2 降到 43.9撞上 100 步上限的实例从66 个降到 26 个。作者检查轨迹后发现Gemini 在上下文过长时会开始重复无效的工具调用轨迹削减反而治好了这个病。损害来自“削减方式”而非“削减本身”Random随机删 75%与 Delete全删这两个基线在 $\theta500$、$a2$ 的保护下仍能保持一定性能但 Delete 会让 $\text{Pass\%}$ 掉约 7%、步数涨 14%而 AgentDiet 只波动 $-1.0\%$ 到 $2.0\%$。泛化性结论在 2 个基准 × 2 个 LLM × 7 种编程语言上一致$\text{LLM}_\text{reflect}$ 换成五家厂商的便宜模型Claude 3.5 Haiku、Gemini 2.5 Flash、GPT-5 mini、DeepSeek v3、Qwen 3均有效输入 token 降到 0.473~0.722。从创新模式看它命中“重新表述为可解对象”把上下文压缩从离线、一次性的输入问题重新表述为带时序的调度问题——削减哪一步、何时削减、给多少上下文都是可调变量。把延迟 $a$ 从 0 调到 2$\text{Pass\%}$ 从 59 回到 65、$\text{Step}$ 从 44.94 降到 38.90说明时机确实是一等变量。局限性单一宿主 agentAgentDiet 只集成到 Trae Agent实验已花掉约\$2000的 API 费用扩展到更多 agent 系统成本过高。作者认为当前 agent 系统高度同质化工具集与 prompt 相似但外部效度威胁依然存在。未定量比较时延商用 API 时延受服务端负载影响很大。在延迟敏感场景可以把反射步骤与 agent 步骤并行执行以消除时延增量代价是反射模型可见的上下文变少。数据泄漏风险评测使用专有 LLM可能见过基准数据作者用新发布的 Multi-SWE-bench Flash 做了部分缓解。补丁正确性测试通过只说明补丁 plausible未必等价于开发者真值靠每个实例的 held-out 测试集缓解。作者自认是“初步研究”论文把自身定位为效率方向的早期探索两处归因如“长上下文导致重复无效调用”属于推测性解释没有做机制层面的实验验证。常见问题FAQAgentDiet 会不会降低 agent 的任务成功率不会。在 2 个基准 × 2 个 LLM 共 4 个组合上通过率变化区间是 $-1.0\%$ 到 $2.0\%$其中 3 个组合还小幅上升平均步数与成功实例平均步数也没有增加说明削减没有让 agent 被迫走更多弯路。为什么不让 agent 自己删除历史步骤作者试过。他们实现了erase工具让模型覆盖历史步但 Claude 4 Sonnet 与 Gemini 2.5 Pro 即便被明确要求“只调用 erase”仍会继续追查代码。推断原因是模型在训练中记住了修 bug 的标准流程产生行为惯性。外置反射模块把时机交给系统绕开了这个不可控因素。反射模块本身的开销有多大论文把它单独记为 $\$$在五个不同厂商的低成本模型上额外成本是原始 agent 成本的5.2%~14.8%最终选用的 GPT-5 mini 约为 7.7%。由于它同时把 agent 侧的输入 token 砍掉近一半整体成本仍然是净下降的。为什么阈值 $\theta$ 选 500 而不是更大或更小$\theta$ 越大跳过的步越多反射开销越低2000 时仅 0.017但输入 token 的降幅也越小通过率从 65 掉到 58。$\theta500$ 时输入降到 0.586、成本降到 0.707同时通过率保持 65与原始 agent 持平是唯一兼顾两者的取值。这套方法能用到其他 agent 上吗理论上可以只要是“模型 工具循环”的 agent 都可以加一个反射模块。但论文只落地在 Trae Agent 上作者论证当前主流 agent 的工具集与 prompt 高度同质化Trae Agent、mini-SWE-agent、OpenHands 的 bash / str_replace_editor / think / task_done 语义相似所以他们认为结论有较好迁移性但未做实测。这篇论文的写作有什么特点叙事上采用“权威引语开场 → 数字痛点 → 反常识闭环”先引用 Anthropic 对 agent 的定义界定对象再用 1000 亿 token 的行业数据坐实问题规模最后用结论推翻开篇提到的“测试时计算必然用性能换效率”这一信念。措辞上属强证据框架摘要直接给出双区间数字新颖性立场却相当克制自称“初步研究”并主动交代只在一个 agent 上实现过需要报告的残留问题是两处推测性归因。参考链接论文 arXiv 摘要页https://arxiv.org/abs/2509.23586论文工件代码、表格脚本、原始轨迹https://doi.org/10.6084/m9.figshare.30073654宿主 agent Trae Agenthttps://arxiv.org/abs/2507.23370评测基准 SWE-benchhttps://arxiv.org/abs/2310.06770对照基线 LLMLingua-2https://arxiv.org/abs/2403.12968同期工作 The Complexity Traphttps://arxiv.org/abs/2508.21433历史脉络 Selective Contexthttps://arxiv.org/abs/2310.06201给大家推荐一款自用写文献综述、无虚构文献的 AI复旦大学 FudanNLP 团队自研 切问学术官网qiewenpaper.com覆盖3.6 亿篇可溯源真实中英文文献能自动整合文献观点生成规范综述还能挖掘研究创新点、复现实验配合视频教学新手快速上手文献综述写作后记博客的关键词集中在编程、算法、机器人、人工智能、数学等等持续高质量输出中。讨论QQ群白拾的小屋 (750365700)⭐B站账号白拾的物理AI组会活跃于知识区和动画区✨GitHub主页YhbCode000工程文件