Agent 系统有一项几乎无人质疑的默认设定：Tool Result 必须完整保留在上下文中，模型只有看完原文才能正确推理。Maka 团队的实践结论彻底挑战了这一假设——对 Tool Result 做大刀阔斧的剪枝后，推理质量近乎无变化，但 Token 消耗降至 OpenCode 的 38%。
工具返回结果占据 Agent 上下文中最大的体积，但它是否真的是最重要的信息？如果大幅剪掉它不会损害推理，那「信息完整性」这个执念到底在保护什么？本文追踪一条推文引发的技术讨论，梳理出三层机制解释、五种工程路线、两项硬约束，以及一个核心洞察：信息的真正载体不是原文，是理解。
2026 年 6 月 25 日，Maka Agent 的作者 @jakevin7 发了一条推文，直言「做 Agent 有个不成文的默认假设：Tool Result 很重要，模型要看完原文才能继续推理。最近发现这个假设可能是错的。」这条推文迅速引来了包括 MiroThinker、Pi、Headroom、rtk-ai 等多个项目的作者和贡献者，展开了一场围绕 Tool Result 压缩问题的深入讨论。
理解这场讨论的前提，是先看清 Agent 循环中上下文的累积方式。每一轮的标准结构是：
System Prompt → User → Assistant → Tool Use → Tool Result → Assistant → ...
Tool Result 是这链条中体积最大的环节——一次 grep 可能返回 500 行结果，一次 read_file 可能是上万字符的 JSON，一次网页抓取更可能是整屏 HTML。在长任务中，Tool Result 的累计 Token 量通常会占上下文总体的 60–80%。
传统的本能反应是「保留原文，信息不丢失」。但 Maka 的实测数据让这个本能站不住脚：
| 指标 | Maka（prune 后） | OpenCode（保留全文） | 对比 |
|---|---|---|---|
| 总 Token 消耗 | 38%（相对值） | 100%（基准） | 节省 62% |
| Output Token | 2.7× | 1×（基准） | 多产出 170% |
| 推理质量 | 近乎无损 | 基准水平 | 无明显退化 |
这些数据背后有两个关键前提：一是 DeepSeek 的 Cache 命中率贡献了 95% 的 Token 经济改善，二是 Tool Result Prune 在 Cache 基础上进一步释放了上下文空间。两者合力，让长程任务的 Token 经济性出现了量级跃升。
「对 Agent 工程的启示：Context 里最占体积的部分，不一定是最重要的部分。与其把精力放在『怎么让 Tool Result 完整进上下文』，不如放在『模型读完之后的 Reasoning 质量』上。」
—— @jakevin7
如果剪掉 Tool Result 原文不损害推理质量，那信息去了哪里？讨论中形成了三层互补的解释——它们不是互相排斥的假说，而是从不同层面描述同一个现象的三种语言。
这是最直观的一层解释，也是 Maka 团队和 MiroThinker 团队独立验证过的核心发现。
在每一次 Tool Result 之后，模型都会输出一段 Assistant Message 来表达它对结果的理解和下一步决策。这段回应本质上是一次语义蒸馏——原始数据被压缩成了推理摘要。后续轮次的模型，更多是在跟「它自己的理解」对话，而不是在跟原始 Tool Result 对话。
MiroThinker 1.5 的实践更极端地证明了这个假说。他们处理的场景是「在 256K 上下文里塞进 400 次 Tool Use」。做法是：除了最近 K 轮保留原文，前几百轮的 Tool Result 全部替换成一句「Tool result is omitted to save tokens」，但完整保留所有 <thought> 链。
这里有个非常反直觉的地方：这个 Agent 本身就在做 Deep Research，前面几百轮的原文都没了，还怎么回答问题？前提是——只要 Thought 链足够密，它其实就是在无限逼近 Summary。T1 产生时已经把 O1 里的关键数据「吃」进脑子了。这条完整的 Thought 链，本身就是一份不断增量更新的、高保真的动态摘要。
—— @yan5xu，MiroThinker 1.5 技术分析
用一句话概括：Prune 掉原文，相当于删掉一份已经被读取并转化的档案——信息早就走了，外壳还在而已。
来自学术界更底层的证据。经典论文「Lost in the Middle」证明了 Transformer 对长上下文中间段的注意力权重会大幅衰减——模型更关注开头（System Prompt）和最近几轮的内容。
Tool Result 在 Agent 循环中的位置碰巧处于这个「衰减敏感区」：它在上下文中间位置，时间上已经过去若干轮，而且信息密度极低（500 行终端输出、冗余 JSON、重复的模板文本）。模型本来就没在认真「读」它。Prune 只是把这部分被隐式忽略的内容显式删除。
从 Agent 决策时序的角度看，模型调用某个工具是因为当时需要那个信息。但 5 轮之后，那个 Tool Result 早已不是边际信息了——核心内容已被消化进后续的推理链中。保留原文是「存档」，不是「决策输入」。
@Kunka020 给了一个生动的类比：「这很像写代码时的删缓存——原文留着很安心，但人其实早就只看自己那句备注了。Agent 长任务里，记忆太厚反而容易把桌面堆成垃圾场。」
语义蒸馏：Assistant Message 已经吃掉了 Tool Result 的关键信息，原文只是外壳。
注意力稀疏：Transformer 天然忽略长上下文中间段，模型本来就没读。
决策点已过：旧轮次的 Tool Result 已被消化进后续推理，不再是边际信息。
讨论中浮现的不是「一个正确答案」，而是一个按「压缩发生在哪一环节」自然分层的策略光谱。每条路线都有自己的定位、适用场景和代价。
| 策略 | 代表项目 | 压缩位置 | 核心做法 | 适用场景 |
|---|---|---|---|---|
| Shell 层过滤 | rtk-ai | 数据进入上下文之前 | 在 Shell 输出层面过滤冗余内容后再喂给模型 | 命令行开发场景，确定性规则可覆盖 |
| 进入前压缩 | headroom | 数据进入上下文之前 | 本地模型对 Tool 输出 / 日志 / 文件内容做智能摘要后送入 LLM | 通用场景，需要保持语义但不想在上下文中保留冗余 |
| 进入后回溯裁剪 | Maka、MiroThinker | 数据进入上下文之后 | 对历史 Tool Result 做激进 Prune，保留 Assistant Message 链 | 高确定性任务场景，模型已经消化过结果 |
| 外化 Memory | Pi、@_talosai | 上下文内外联动 | 完整结果落盘到临时文件，上下文只进部分摘要，模型需要时可主动读取 | 通用 Agent，任务多样性高 |
| Agent 自主压缩 | @lynskylate 实验 | Agent 自行决策 | 通过 Agents.md 提示词赋予 Agent 调用 Compact Tool 的能力，让其自行判断何时压缩 | 需要与 Post-Training 配合，当前仅在特定 Workflow 上验证 |
五种策略并非扁平并列，它们沿着两条核心轴分化：
第一轴：压缩发生的时点。是数据进入上下文之前（Pre-Context）、之后（Post-Context），还是按需联动（Hybrid）？Maka 的作者 @jakevin7 澄清了一个关键区别：「rtk 是数据进入上下文之前过滤，我们是数据进入上下文之后回溯裁剪。」
第二轴：任务确定性。高确定性任务（如代码解释器、特定 Workflow）可以承受激进 Prune；通用 Agent 面对未知任务多样性时，外化 Memory 或按需读取的容错率更高。@BohuTANG 概括道：「这个上下文状态机很复杂，不同场景下对 Tool Result 的需求不一样。如果做通用场景 Agent，Pi 的方案很优了。」
讨论中也出现了一个独立方向——@realxujiang 提到 @_talosai 在做的恰恰相反：从记忆和历史 Session 补充信息到上下文。这条路走的是「压缩策略的复杂化」而非「信息的删除」。两端的张力说明：上下文管理不是「多 vs 少」的二元选择，而是「什么东西在哪、什么时候出现」的编排问题。
这种「剪枝优于全量」的规律并非 Agent 独有。讨论中 @kundocs 分享了企业 RAG 场景的同类发现：「检索回来的文档原文塞满上下文，模型反而被噪音干扰。后来改成只传摘要 + 原文引用链接，效果反而更好。」
信息的价值不在于完整，在于精准。无论是在 Agent Tool Use 还是 RAG 场景，把全部原文塞进上下文的做法都假设了模型有无限的注意力和完美的信息筛选能力——而这两个假设都不成立。
策略选择不能只看 Token 节省。三项硬约束——KV Cache、评估方法论、幻觉风险——构成了任何 Prune 方案必须穿越的工程窄门。
这是讨论中争论最激烈的一项工程约束。剪掉历史 Tool Result 的代价不是信息损失，而是破坏了 KV Cache 的连续性。
推理服务使用 KV Cache 来复用已计算过的前缀 Token。当你修改历史上下文中的任何一部分，整个后续序列的 Cache 全部失效——这意味着 Tool Result 之后的所有 Token（包括模型自身的 Assistant Message）都需要重新计算。
@xlifanh 简洁地指出了这个痛点：「这个行为会让缓存失效。」@ashfold 进一步细化：「除了 DeepSeek 支持的好点，其他的 LLM Provider 可能会无法 Match Prefix。」
@jakevin7 的回应确认了这个局限：「确实是会破坏 KV Cache 的。DeepSeek 支持不完整前缀匹配，在这一块做的机制确实完善一些。」这里的不完整前缀匹配（Partial Prefix Match）是指：即使上下文被修改过，只要存在共同前缀段，就可以复用该段的 Cache。这意味 Prune 方案的 Token 经济性高度依赖于推理 Provider 的 Cache 实现——同样的裁剪策略，在 DeepSeek 上能省钱，在 GPT-4 上可能是净亏损。
MiroThinker 的折中方案：@yan5xu 指出 MiroThinker 只丢弃最后一轮的 Cache 复用——1, 2, 3 ... n-1 轮的 Token 仍然可以缓存。这是一种「渐进式修复」，在 Prune 激进度和 Cache 效率之间找到了一个中间点。
@BtreeWw 提出了几个直击要害的评估问题，目前业界没有统一答案：
@_4rcadia 进一步指出幻觉风险：「不保留原文是否存在堆积幻觉的风险，特别是在中小型模型上？」这个问题触及了 Prune 策略的模型能力下限——大模型可以通过自身推理链重构丢失的信息，但中小模型可能不行。
@VersunPan 提出了一个实操瓶颈：「怎么判断哪些 Tool Result 是没用的，这个应该不大好做。由模型判断的话，徒增上下文，有点得不偿失。」
这确实是 Prune 策略的「元问题」：如果需要一个模型来判断该不该 Prune 另一个模型的结果，你只是把 Token 从 Tool Result 转移到了判断逻辑上。目前业界的应对方式分为三类：
这场讨论的最珍贵之处，在于打破了一个很少有人质疑的默认假设，并让不同项目的实践者在一个开放空间里交叉验证各自的取舍。以下是从讨论中提炼的实践启示。
在 Agent 工程中，「完整」不等于「有用」。上下文不是档案柜，而是工作台——它的价值取决于上面有多少东西正在被使用，而不是有多少东西堆积在上面。三条机制解释（语义蒸馏、注意力稀疏、决策点已过）各自独立地指向同一个结论：保留原文是一种「信息完整性幻觉」，看起来安全，实际浪费了模型本可以用于真正推理的 Token 空间。
讨论中提及的五个项目——rtk-ai、headroom、Maka、MiroThinker、Pi——不是五个互不相关的点子，而是同一问题的五种工程解。它们的共同信号是：上下文压缩不再是一个「优化项」，而是 Agent 能跑长任务的前提条件。正如 @BohuTANG 所说，「如果做通用场景 Agent，Pi 的方案很优了」——但「优」的标准不是单一维度的，而是场景依赖的。通用场景需要外化 Memory 的容错性，确定性任务可以承受回溯裁剪的经济性。
不存在一个放之四海皆优的 Prune 策略。选择策略时至少需要回答四个问题：
讨论中最前沿的探索——Agent 自主压缩——提示了一个更深的方向：上下文管理从外部规则走向 Agent 内化能力。如果 Agent 能判断什么时候该 Compress、Compress 到什么程度、Compress 后保留什么摘要，那就不是「删不删」的问题了，而是 Agent 的元认知能力——它能感知到自己「记不住了」，然后主动整理自己的记忆。这需要 Post-Training 和 Harness 的协同演进，目前在 @lynskylate 的实验中只达到了「特定 Workflow 上效果一样且 Token 减少很多」的阶段。
如果你正在构建 Agent 系统，可以从三件事开始：
1. 跑一个内部 Benchmark：在现有任务上尝试保留最近 K 轮原文、对 K 轮之前只留 Assistant Message，比较任务完成率和 Token 消耗
2. 检查你的推理 Provider 的 Prefix Cache 策略——这对 Prune 方案的 ROI 影响极大
3. 区分 Tool Result 类型：终端输出、文件读取、Web 抓取各自的信息衰减曲线不同，不要一刀切
讨论中涉及的开源项目及其定位。所有项目均可通过 GitHub 获取。
| 项目 | 定位 | 核心价值 | 仓库 |
|---|---|---|---|
| Maka Agent | 本地优先的 AI 桌面助手 | 首次系统验证 Prune + Compact 路线在长任务中的 Token 经济性 | github.com/maka-agent/maka-agent |
| MiroThinker 1.5 | Deep Research Agent | 256K 上下文内支持 400+ 次 Tool Use；证明 Thought 链可替代原文 | 见 @yan5xu 推文 |
| rtk-ai | CLI 代理，Shell 层过滤 | 单 Rust 二进制，零依赖；开发命令 Token 减少 60–90% | github.com/rtk-ai/rtk |
| headroom | 通用上下文压缩层 | 本地模型压缩 Tool 输出 / 日志 / 文件 / RAG 块；库、代理、MCP 服务器三种形态 | github.com/headroomlabs-ai/headroom |
| Pi | Coding Agent | 外化 Memory 设计：部分结果进上下文，完整结果落文件，模型按需读取 | 开源项目 |
本文内容源自 2026 年 6 月 25 日 X/Twitter 上围绕 @jakevin7 推文的公开讨论。主要贡献者包括：
感谢所有参与讨论的实践者，他们的坦诚分享让这场「默认假设的瓦解」不再是某一个项目的内部发现，而成为了可被交叉验证的社区共识。特别感谢 @jakevin7 率先公开了 Maka 的实验数据和机制分析。