Reducing Cost of LLM Agents with Trajectory Reduction
论文阅读：Reducing Cost of LLM Agents with Trajectory Reduction
论文标题：Reducing Cost of LLM Agents with Trajectory Reduction
作者：Yuan-An Xiao, Pengfei Gao, Chao Peng, Yingfei Xiong
发表位置：Proc. ACM Softw. Eng. 3, FSE, Article FSE056；accepted for FSE 2026
arXiv 编号：arXiv:2509.23586
主题：LLM Agent、软件工程智能体、轨迹压缩、推理时成本优化
核心问题：多轮 LLM Agent 在执行任务时会不断累积完整轨迹，导致输入 token 成本快速增长；论文研究是否可以在推理时自动删减轨迹中的无用、冗余和过期信息，从而降低成本而不损害任务完成率。
1. 引言：为什么 Agent 的成本问题会越来越明显？
近几年，基于大语言模型的 Agent 被广泛用于软件工程任务，例如代码生成、测试、调试和程序修复。和单轮问答不同，Agent 会在一个循环中不断调用工具：读文件、编辑代码、运行命令、查看测试结果，然后把每一步的操作和结果继续放回上下文中，作为下一次模型调用的输入。
这种范式让 Agent 能够处理更复杂的软件工程任务，但也带来了一个直接的问题：轨迹会不断变长。
在典型 Agent 系统中，一旦模型调用了工具，对应的 assistant message 和 tool message 通常会一直保留到任务结束。比如模型打开了一个很长的文件，或者运行了一个输出很长的测试命令，这些内容会在后续每一步中反复作为输入 token 传给模型。论文指出，在他们收集的 SWE-bench Verified 轨迹中，解决一个 GitHub issue 的平均轨迹包含 48.4K token、40 个步骤；由于每个 token 会在后续多次调用中重复出现，累计 token 使用量达到约 1.0M。
这篇论文关注的问题就是：在 Agent 执行过程中，能不能把轨迹里的“浪费信息”自动减掉，从而降低推理成本？
论文提出的方法叫 AgentDiet。它不是修改底层模型，也不是训练新的压缩模型，而是在 Agent 执行时加入一个独立的 reflection module，用较便宜的 LLM 来识别并压缩轨迹中已经不再重要的内容。
2. 问题分析：Agent 轨迹中有哪些“浪费”？
论文首先分析 LLM Agent 的基本工作流。
【论文 Figure 1（Typical workflow of an LLM agent）。该图展示 Agent 如何从 system/user 初始提示开始，不断生成 assistant 工具调用，再接收 tool 返回结果，并把这些步骤持续拼接到 trajectory 中。】
在这个工作流中，trajectory 是 Agent 的核心上下文。它记录 system message、user message、assistant message、tool message，以及所有历史操作。Agent 每执行一步，新的 assistant/tool message 都会被追加到轨迹后面。
这种设计简单有效，但问题是：历史内容默认永久保留。论文认为，轨迹中存在大量可以从人类角度删除或压缩的信息，并把它们分成三类。
| 类型 | 含义 | 论文中的例子 |
|---|---|---|
| Useless information（无用信息） | 与当前任务无关，删除后几乎不损失关键信息 | 列目录时包含 __pycache__、.egg-info 等无关文件；构建或测试日志中大量重复的 Entering/Leaving directory 输出 |
| Redundant information（冗余信息） | 同一信息在轨迹中出现多次，保留一份即可 | str_replace_editor 的参数里有旧代码 P 和新代码 Q，工具返回结果又重复包含 Q；旧代码 P 也可能已经在之前查看文件时出现过 |
| Expired information（过期信息） | 曾经对局部搜索有用，但后续已经不再需要 | Agent 用 grep 搜索多个文件，逐个打开排查；一旦找到真正相关文件，其他候选文件内容就不再重要 |
这三类浪费说明，Agent 轨迹不是越完整越好。完整轨迹中既有任务所需信息，也混杂了大量对后续推理贡献很小的信息。论文的核心判断是：如果能够在不破坏关键上下文的前提下移除这些信息，就可能同时降低成本并保持性能。
3. 原型方法：让 LLM 帮忙识别并压缩轨迹
论文首先讨论了一个直接问题：如何自动识别这些浪费？
一种可能做法是写规则，比如用正则表达式删除日志中的固定模式。但论文认为这种方式覆盖面有限，因为不同项目的输出格式不同，不同工具调用产生的冗余也不一样。于是作者选择用 LLM 来做轨迹压缩。
他们设计了一个用于轨迹压缩的 prompt，主要包含四部分：
- 高层任务描述：告诉模型要分析并压缩 Agent 轨迹中的某一步。
- 输入输出格式：轨迹中的每一步用 XML 风格的
<step id="..."></step>包起来，要求模型保持结构。 - 三类浪费信息的说明和例子：无用、冗余、过期。
- 防止信息损失的约束：删除内容时要用简短 takeaway 替换，保留原有结构，不要破坏 XML 标签等。
论文用一个 pytest 任务展示了压缩效果。
在这个例子中，Agent 运行测试命令后得到一大段输出，其中绝大部分是通过的测试项列表，真正有用的是最终的测试总结和失败信息。原始 step 有 1995 token，其中大量 passed test 列表属于无用信息。AgentDiet 将这些测试行替换为类似“individual test lines omitted; mostly PASSED”的短占位描述，同时保留关键测试总结，最终压缩到 259 token。
【论文 Figure 2（A case study of reducing information waste in the trajectory）。该图对比了原始测试输出和 AgentDiet 压缩后的输出，重点展示长测试日志如何被短 takeaway 替换。】
这个例子说明，LLM 可以在一定程度上理解轨迹中哪些内容是冗余或无用的，并把它们变成更短但仍保留语义的表示。
4. 为什么不能让 Agent 自己压缩自己的轨迹？
接下来论文讨论一个看似自然的方案：既然 Agent 本身就是 LLM，能不能给它一个 erase 工具，让它自己决定什么时候删除历史轨迹？
作者做了初步实验。他们给 Agent 加了一个 erase 工具，允许它用类似下面的参数覆盖已有轨迹片段：
{"id": 17, "takeaway": "unrelated content"}
但实验发现，即使使用 Claude 4 Sonnet 和 Gemini 2.5 Pro，并在 prompt 中明确要求模型进入 reflection 模式、只能调用 erase 工具，模型仍经常继续执行原始任务，而不是主动整理轨迹。
论文据此认为：让 Agent 自己负责轨迹压缩并不可靠。如果要做到这一点，可能需要专门的微调，而这既昂贵又容易出错，对于无法访问内部参数的闭源模型也不现实。
因此，AgentDiet 采用了一个外部控制的设计：把轨迹压缩放到一个独立的 reflection module 中，由外层系统决定何时调用它。这样，执行任务的主 Agent 不需要知道轨迹正在被压缩，也不会被额外的压缩决策干扰。
5. AgentDiet：用滑动窗口控制压缩开销
直接把完整轨迹交给 reflection module 压缩并不可行，因为这会引入巨大的额外成本。论文指出，额外调用 LLM 本身会消耗 token，而且 reflection module 和主 Agent 的 system prompt、工具集合不同，KV Cache 不能共享。如果频繁修改轨迹，还会使后续 token 的缓存失效。
AgentDiet 的核心设计是：只压缩一个较早的 step，并且只给 reflection module 一个局部窗口上下文。
【论文 Figure 3（Design of the reflection module in AgentDiet）。该图展示滑动窗口设计：当 Agent 执行到第 s 步时，reflection module 只尝试压缩第 s-a 步，并查看从 s-a-b 到 s 的有限上下文。】
具体来说，当 Agent 执行到第 s 步时，AgentDiet 只尝试压缩第 s-a 步。reflection module 的输入不是完整轨迹，而是一个窗口：
- 目标 step：
s-a - 目标 step 之前的
b个 step - 目标 step 之后直到当前的
a个 step
这里有三个关键超参数：
| 超参数 | 含义 | 作用 |
|---|---|---|
a |
目标 step 距离当前 step 的延迟步数 | 避免压缩太新的信息，让 Agent 先用完局部上下文 |
b |
给 reflection module 的前文步数 | 提供压缩判断所需上下文 |
θ |
长度阈值 | 如果目标 step 不够长，就跳过压缩，避免压缩收益小于调用开销 |
论文给出的算法流程可以概括为：
- Agent 正常执行一步，得到 assistant message 和 tool message。
- 把这一步追加到轨迹中。
- 如果当前步数已经超过延迟
a，则考虑压缩第s-a步。 - 如果该步长度小于等于阈值
θ，跳过。 - 否则构造局部上下文，调用便宜的
LLMreflect。 - 如果压缩后的 token 减少量超过
θ，就用压缩版本替换原 step；否则不替换。
这个设计同时服务于两个目标：
- 从效率上看，reflection module 每次只处理有限窗口，不会把完整轨迹再读一遍。
- 从安全性上看，它不能一次删除所有历史，也不能立刻删除最新 step，因此即使
LLMreflect偶尔出错，也不容易造成灾难性破坏。
6. 实现：集成到 Trae Agent
论文将 AgentDiet 集成到 Trae Agent 中。Trae Agent 是一个开源软件工程 Agent，在作者研究时位于 SWE-bench Verified 的较高排名。它包含四类主要工具：
| 工具 | 功能 |
|---|---|
bash |
执行 Bash 命令 |
str_replace_editor |
查看或编辑文件 |
think |
分析问题 |
task_done |
结束任务 |
作者认为，当前许多软件工程 Agent 的结构比较相似，都是“模型 + 工具循环”的范式，因此 AgentDiet 理论上可以迁移到类似系统中。不过论文的实验只实际集成并评估了 Trae Agent。
对于 ensemble agent 或 multi-agent 系统，论文认为可以把 reflection module 加到每个单独 Agent 上，但没有展开针对这些复杂系统的专门优化，相关评估留给未来工作。
7. 超参数选择：反射模型、阈值和窗口大小
在正式评估前，论文用 SWE-bench Verified 中的 100 个实例进行超参数选择。这 100 个实例同时也用于前面的人工轨迹分析；正式评估时会从剩余实例中抽样，降低超参数过拟合风险。
论文考察了四类超参数：
LLMreflect：用于压缩轨迹的模型。θ：长度阈值。a：压缩目标距离当前步骤的延迟。b：压缩时可见的前文步数。
候选 LLMreflect 包括 Claude 3.5 Haiku、Gemini 2.5 Flash、GPT-5 mini、DeepSeek v3 和 Qwen 3。论文还比较了几个 baseline：
| Baseline | 含义 |
|---|---|
| Original | 不做 reflection，也不删除内容 |
| LLMLingua-2 | 用现有 prompt compression 模型压缩 |
| Random | 随机删除被处理 token 的 75% |
| Delete | 删除所有被处理 token |
论文使用的效率指标包括：
| 指标 | 含义 |
|---|---|
| Keep% | reflection module 处理过的 step 中保留下来的 token 比例 |
| I | 累计输入 token，用 Original 的输入 token 归一化 |
| O | 累计输出 token，用 Original 的输入 token 归一化 |
| $ | 主 Agent 调用成本，用 Original 成本归一化 |
| $+ | reflection module 额外成本 |
性能指标包括：
| 指标 | 含义 |
|---|---|
| Pass% | 成功解决 benchmark 实例的比例 |
| Step | 所有实例的平均 Agent 步数 |
| PStep | 成功解决实例的平均 Agent 步数 |
实验结果显示，不同 LLMreflect 都能删除大量被处理 step 中的内容，保留比例在 14.4% 到 29.0% 之间。最终，GPT-5 mini 被选为 AgentDiet 的反射模型，因为它保持了和 Original 相同的 Pass%，同时也是唯一让 Step 和 PStep 下降的模型。
对于其他超参数，论文最终选择：
| 超参数 | 最终设置 |
|---|---|
LLMreflect |
GPT-5 mini |
θ |
500 |
a |
2 |
b |
1 |
论文解释说，θ=500 在 token 节省和 reflection 开销之间取得平衡；a=2,b=1 是对性能影响很小、同时仍能显著节省成本的较小窗口设置。
8. 正式评估设置
论文围绕三个研究问题进行评估：
| RQ | 问题 |
|---|---|
| RQ1 | AgentDiet 能否通过减少 trajectory 长度提升效率？ |
| RQ2 | AgentDiet 是否会损害 Agent 的任务解决性能？ |
| RQ3 | 结果能否泛化到不同 benchmark 和不同 LLM？ |
实验使用两个 benchmark：
| Benchmark | 内容 |
|---|---|
| SWE-bench Verified | 500 个经过人工验证的软件工程任务，主要来自 Python 项目的真实 GitHub issue；论文正式评估随机选取剩余 400 个中的 200 个 |
| Multi-SWE-bench Flash | 300 个 GitHub issue 任务，覆盖 Rust、TypeScript、JavaScript、Java、Go、C、C++ 七种语言 |
主 Agent 使用两个模型：
| LLMagent | 用途 |
|---|---|
| Claude 4 Sonnet | 作为软件工程 Agent 的主模型之一 |
| Gemini 2.5 Pro | 用于测试 AgentDiet 在另一个强模型上的泛化 |
SWE-bench Verified 的 step limit 设为 50；Multi-SWE-bench Flash 更难，需要更多步骤，因此 step limit 设为 100。
9. RQ1：AgentDiet 能降低多少成本？
论文的主要结果显示，AgentDiet 确实显著降低了输入 token 和总成本。
| Benchmark | LLMagent | 输入 token 比例 I | 主 Agent 成本 $ | reflection 成本 $+ | Pass% 变化 |
|---|---|---|---|---|---|
| SWE-bench Verified | Claude 4 Sonnet | 0.601 | 0.714 | 0.074 | 64.5 → 66.5 |
| SWE-bench Verified | Gemini 2.5 Pro | 0.591 | 0.623 | 0.118 | 50.5 → 52.0 |
| Multi-SWE-bench Flash | Claude 4 Sonnet | 0.596 | 0.676 | 0.055 | 40.0 → 39.0 |
| Multi-SWE-bench Flash | Gemini 2.5 Pro | 0.403 | 0.559 | 0.082 | 21.7 → 22.7 |
从这些结果可以看出：
- AgentDiet 将累计输入 token 降低到 Original 的 40.3% 到 60.1%。
- 换句话说，输入 token 减少了 39.9% 到 59.7%。
- 主 Agent 成本降低到 Original 的 55.9% 到 71.4%。
- 如果再加上 reflection module 的额外成本，最终总成本仍减少 21.1% 到 35.9%。
论文还把归一化成本换算成每个实例的美元成本。例如在四个设置中，Original 的平均成本分别为 0.535、0.385、1.277、0.701 美元；AgentDiet 分别降到 0.422、0.285、0.933、0.449 美元。虽然单个任务节省金额不大，但如果是大规模 Agent 产品，累计节省会非常明显。
【论文 Figure 4（Histogram of the number of tokens reduced by AgentDiet in each step）。该图展示每个 step 压缩前后的 token 数分布，以及哪些 step 因低于阈值或收益不足而没有被替换。】
10. RQ2：压缩轨迹会不会损害性能？
论文用 Pass%、Step 和 PStep 来衡量性能影响。
在两个 benchmark 和两个主模型上，AgentDiet 的 Pass% 与 Original 相比变化范围是 -1.0% 到 +2.0%。这说明，在论文实验范围内，轨迹压缩没有明显损害任务解决率。
更进一步，Step 和 PStep 也没有整体增加。也就是说，AgentDiet 并没有让 Agent 因为信息被删掉而不得不多走很多步来找回上下文。
一个有意思的现象出现在 Multi-SWE-bench Flash + Gemini 2.5 Pro 设置中：Original 的平均 Step 是 57.20，而 AgentDiet 降到 43.90。论文通过检查轨迹发现，Gemini 2.5 Pro 在上下文过长时会更容易出现异常行为，例如重复发出无效工具调用直到达到 100 步上限。AgentDiet 缩短轨迹后，触发这种异常的概率下降。在该设置中，到达 100 步上限的实例数从 66 个降到 26 个。
【论文 Figure 5（Histogram of the Step metric on Multi-SWE-bench Flash + Gemini 2.5 Pro）。该图比较 Original 和 AgentDiet 的 step 分布，重点展示达到 100 步上限的实例明显减少。】
因此，论文认为 AgentDiet 不仅能降低成本，在某些角落情况中还可能改善 Agent 的鲁棒性。
11. RQ3：能否泛化到不同模型、任务和语言？
论文从三个层面讨论泛化性。
第一，AgentDiet 在两个 benchmark 上都有效：SWE-bench Verified 和 Multi-SWE-bench Flash。
第二，AgentDiet 在两个主模型上都有效：Claude 4 Sonnet 和 Gemini 2.5 Pro。
第三，Multi-SWE-bench Flash 覆盖七种语言，论文进一步按语言拆分结果。总体上，前面 RQ1 和 RQ2 的发现仍然成立：AgentDiet 能减少输入 token 和成本，并且对 Pass% 的影响有限。
| 语言 | 实例数 |
|---|---|
| Rust | 45 |
| TypeScript | 45 |
| JavaScript | 45 |
| Java | 40 |
| Go | 45 |
| C | 40 |
| C++ | 40 |
论文因此得出结论：基于少量样例优化 prompt、基于 100 个实例选择超参数的 AgentDiet，可以泛化到两个 benchmark、两个主模型和七种编程语言。
12. 讨论：未来工作和有效性威胁
12.1 延迟问题
AgentDiet 在 Agent 循环中额外加入 reflection step，因此可能增加延迟。论文没有定量比较延迟，因为实验依赖商业 LLM API，而 API 延迟受服务器负载影响较大，不稳定。
论文提出，在延迟敏感场景中，可以让 reflection step 和 Agent step 并行执行。这样可以减少或消除额外延迟，但代价是 reflection module 能看到的后续上下文少一步，相当于改变超参数 a 的有效值。
12.2 更高效的轨迹压缩设计
当前 AgentDiet 使用现成 LLM 作为 LLMreflect，会带来约 5% 到 10% 的额外成本。论文认为，未来可以训练或设计更专门、更便宜的模型来完成轨迹压缩，从而进一步降低开销。
此外，对于会根据任务难度路由到不同 LLM 的 Agent 系统，也可以动态调整 AgentDiet 的超参数，在效率和性能之间自动平衡。
12.3 泛化到更多 Agent 系统
论文的一个外部有效性威胁是：AgentDiet 只实际集成到 Trae Agent 中。虽然作者认为当前软件工程 Agent 大多采用类似的“模型 + 工具循环”结构，工具也较相似，但没有在更多 Agent 框架上实测。
作者解释说，实验已经花费约 2000 美元 LLM 成本，因此进一步测试更多 Agent 系统在成本上较困难。
12.4 数据泄漏问题
由于实验使用了闭源商业模型，benchmark 实例可能已经进入模型训练数据，作者无法直接控制这一点。论文通过加入较新的 Multi-SWE-bench Flash 来缓解这一威胁，因为该 benchmark 由第三方收集，并且未出现在被评估模型的技术报告中。
12.5 补丁正确性问题
SWE-bench Verified 和 Multi-SWE-bench Flash 都通过开发者编写的测试来判断补丁是否成功。测试通过的 patch 可能只是 plausible patch，并不一定与开发者真实 patch 语义完全等价。论文指出，这是所有基于测试的程序修复评估都会面临的问题。由于 AgentDiet 和 Original 在同样 benchmark、同样测试机制下比较，因此这一威胁对两者相对比较的影响有限。
13. 相关工作
论文把相关工作分成三类。
13.1 Prompt Reduction
已有 prompt reduction 方法主要面向 RAG 或单轮输入压缩，例如过滤检索文档、按 token 信息量裁剪、用模型生成摘要、训练分类器判断 token 相关性等。
这些方法和 AgentDiet 的区别在于：
- 它们通常处理初始输入，而不是 Agent 逐步生成的轨迹。
- 它们多面向自然语言，不一定能保留代码、命令输出和工具调用结构。
- 它们没有重点讨论“什么时候压缩”这个问题，而 Agent 轨迹的压缩时机对性能和成本都有影响。
论文还指出，LLMLingua-2 在 pytest 例子中会把测试名压缩成难以辨认的碎片，而 AgentDiet 的 reflection module 更强调保持结构并用简短 takeaway 替换无用内容。
13.2 Agent 系统中的上下文管理
一些现有 Agent 产品或系统已经有上下文管理机制。例如 Cursor 和 Claude Code 会在上下文窗口满时用 LLM 压缩上下文；Trae Agent 会把每个工具响应截断到前 16KB；SWE-agent 也有基于正则删除文本等机制。
但这些机制通常是临时性的，主要用于避免上下文爆掉或提升极端情况下的鲁棒性。AgentDiet 的不同点在于，它把 trajectory reduction 作为一个明确的效率优化问题，并进行系统实验评估。
13.3 白盒 LLM 系统的效率优化
还有一类方法通过修改模型结构、训练方式或推理过程来提升效率，例如合并 KV Cache、蒸馏 RAG 文档到 embedding、剪枝 Chain-of-Thought token、增加 Transformer 内部剪枝层等。
这些方法通常需要白盒访问模型，而当前许多强 Agent 模型是闭源商业模型，无法修改训练或推理内部机制。AgentDiet 不依赖模型内部机制，因此更容易应用到闭源 LLM Agent 系统中。
14. 总结
这篇论文研究了一个很实际的问题：LLM Agent 在多轮工具调用过程中会积累越来越长的 trajectory，而这些历史轨迹会带来显著的输入 token 成本。论文通过分析 SWE-bench Verified 中的 Agent 轨迹，发现其中普遍存在三类浪费：无用信息、冗余信息和过期信息。
基于这个观察，论文提出 AgentDiet。它在 Agent 执行过程中加入一个独立 reflection module，用较便宜的 LLM 在滑动窗口内压缩较早的 step。这个设计避免让主 Agent 自己管理轨迹，也避免把完整轨迹反复交给压缩模型，从而在压缩效果、成本开销和性能安全之间取得平衡。
实验结果显示，AgentDiet 在两个 benchmark、两个主模型和七种编程语言上都能降低成本：输入 token 减少 39.9% 到 59.7%，最终计算成本减少 21.1% 到 35.9%，同时 Pass% 与 Original 基本持平，变化范围为 -1.0% 到 +2.0%。
因此，论文的核心结论是：对于软件工程 LLM Agent，推理时轨迹压缩是一条有潜力的成本优化方向；只要压缩时机和压缩范围设计得当，就可以减少大量 token 浪费，而不必牺牲任务完成性能。
参考
- Yuan-An Xiao, Pengfei Gao, Chao Peng, Yingfei Xiong. Reducing Cost of LLM Agents with Trajectory Reduction. arXiv:2509.23586.
- 论文 artifact：实现、实验脚本和原始轨迹数据见论文 Data Availability 中给出的 Figshare artifact。
浙公网安备 33010602011771号