Agent中tool result修剪可无损降低token消耗

avante.nvim 就是这么做的，不过当初是为了解决 2025 年初除了 claude 之外所有的（注意是所有的）大模型在 multiple steps turn 的 agent 能力巨差的问题，所以必须要对中途的 tool calling 进行修剪，不然的话 agent turn 甚至都会提前 stop > **引用原帖 kabikabi (@jakevin7):** > 做 Agent 有个不成文的默认假设：tool result 很重要，模型要看完原文才能继续推理。 > 最近发现这个假设可能是错的。 > ---------------------------------- > https://t.co/PV5Fv29bFx 欢迎 star > ---------------------------------- > 在 maka 里，我们对 tool result 做了激进的 prune——把工具返回的原始数据大幅裁剪，只保留关键摘要，然后跑了完整的任务对比。结论让人意外：推理质量几乎没有变化，近乎无损压缩。 > 这是为什么？我有几个可能的解释： > 第一，信息已经被蒸馏进 Assistant Message > Agent loop 的上下文结构是： > System Prompt → User → Assistant → Tool Use → Tool Result → Assistant → ... > 每次 tool result 之后，模型都会输出一段 Assistant Message 来表达它的理解和下一步决策。这是一次语义蒸馏——原始数据被压缩成了推理摘要。 > 后续轮次的模型，更多是在跟"它自己的理解"对话，而不是在跟 tool result 原文对话。prune 掉原文，相当于删掉了一份已经被读取并转化的档案——信息早就走了，外壳还在而已。 > 第二，Attention 在长上下文里本来就稀疏 > "Lost in the Middle" 那篇研究证明：Transformer 对长上下文中间段的注意力权重会大幅衰减，模型更关注开头（system prompt）和最近几轮。 > Tool result 通常在上下文中间位置，而且信息密度极低（500 行代码、终端输出、冗余 JSON）。模型本来就没在认真"读"它。prune 只是把这部分被隐式忽略的内容显式删掉。 > 第三，决策点已经过去 > 模型调用工具是因为当时需要那个信息。但 5 轮之后，那个 tool result 早已不是边际信息了——核心内容已被消化进后续推理链，保留原文是"存档"，不是"决策输入"。 > 实测数据：对同一个任务（MIPS interpreter），Maka 的总 token 消耗只有 OpenCode 的 38%，但 output token 是它的 2.7 倍。 > 这个差距背后，有 DeepSeek cache 命中率 95% 的贡献，也有 tool result prune 的贡献。两者合力，长程任务的 token 经济性出现了量级跃升。 > 对 Agent 工程的启示：context 里最占体积的部分，不一定是最重要的部分。 > 与其把精力放在"怎么让 tool result 完整进上下文"，不如放在"模型读完之后的 reasoning 质量"上。信息的真正载体不是原文，是理解。 > https://x.com/jakevin7/status/2070035047973822796