Agent上下文未满，工具结果为何仍被截断

Agent 的上下文窗口还空着，工具返回的关键证据却可能已经被外围代码删掉。作者 Igor Eduardo 借一篇新论文提醒：窗口容量、最终答对率，都不能证明模型完整看到了工具结果。

这项研究里，最大提示词只用了窗口的 5.75%，仍有约三分之一的工具结果被截断。对正在做 AI 编程助手、日志诊断或工具调用的团队，值得追问的不是还能塞多少 token，而是工具找到的东西，究竟有多少送到了模型面前。

窗口明明够用，证据为什么还会丢

论文《Context Is a Pipeline, Not a Window: Information Attrition in LLM Agent Harnesses》，编号 arXiv 2610.36114，发布于 2026-10-26，研究的是一个读取 Linux 内核跟踪数据、诊断注入故障的 Agent。

模型外面还有一层运行框架，论文称为 harness。它负责把工具结果序列化、按预算裁剪、保留或删除历史，以及在多个工作单元之间传递发现。模型读到的是这层代码整理后的输入，而非工具刚刚产生的完整结果。

上下文窗口有空位，只能说明放得下，不能说明已经送到。

在 720 次运行中，最大的提示词也只占窗口的 5.75%。但 11,189 个工具结果里，有 3,827 个在送达模型前被截断，而且每个被截断的结果都变成了无法解析的 JSON。

这里不是模型读不懂，也不是检索没找到，而是中间代码直接按固定文本长度切了一刀。排在后面的内容更容易消失，内容是否重要并不参与决定。

同一份载荷中的两份容器列表，一份只在 4.7% 的调用里送达模型，另一份却能在 99.3% 的调用里送达。字段出现在什么位置，成了证据能否留下来的关键。

只记录「发给模型的内容」也查不出全部问题。没有工具原始结果作对照，你看到的只是裁剪后的版本，无法知道哪些内容曾经存在。

答案仍然正确，为什么也可能是退步

研究中的准确率分布很悬殊：故障出现在保留下来的列表里时，每 60 个案例能答对 40–55 个；故障只出现在被删列表里时，只能答对 0–24 个。

但论文明确说，这种字段分组与准确率差异是相关关系，尚未证明截断导致了准确率下降。站内解读不能把这一步推断替作者做完。

另一项回放展示了更直接的证据损失：对一份生产规模的真实跟踪数据应用随系统交付的裁剪规则后，某类故障证据共有 128 条记录，送达模型的是 0 条。这能证明整类证据消失，却不能单独证明所有类似任务都会答错。

受控实验更有意思。研究者原本预计删掉相关列表会降低准确率，Agent 却从另一张表中找回了目标名称。在这些仍有其他取证路径的案例里，准确率没有下降，工作量先涨了。

工具调用从 53 次增加到 76 次，论文称为增加 43%；计算次数从约 18 次增加到 36 次；每次计算产出的发现数，即 yield，从 0.61 降到 0.31。

答案正确，也可能是 Agent 多绕了几圈才补回丢失的信息。

如果评测只设答对率门槛，这种退步很容易过关。等到证据只存在于一个字段、没有其他表格可以补救时，系统才可能暴露更严重的问题。

为什么延迟面板也不容易报警

原文还有两组容易被混读的数据。

在对 864 个已记录结果的回放中，只有 2.5% 的调用受到影响。它和前面的 11,189 个工具结果属于不同统计范围，不能拿来直接比较，更不能相互抵消。

另外，对两个生产编码 Agent 的跟踪显示，等待模型响应占总耗时的中位数为 84%。在这种耗时结构下，工具结果的交付异常很容易被延迟面板掩盖。系统耗时看着平稳，不代表证据传递完整。

论文还调查了七个 Agent 框架，其中两个存在类似的按位置截断行为。原文没有列出名称，也没有提供足够信息支持框架排名。

作者提出的改进方向，是把评测沿信息传递过程拆开：先看工具是否找到了证据，再看证据是否完整送达，最后才看模型是否答对。检索阶段成功，后续交付阶段仍然可能失败。

我的判断

我认同把「工具结果送达情况」放进评测，因为它补上了一个明确的观测缺口。扩大上下文窗口不能自动修复固定长度裁剪；换更强的模型，也不能保证找回从未进入输入的字段。

但这篇材料的证据边界需要保留。研究覆盖一个 harness、一个领域、一个模型，样本规模也有限。文章作者没有复现实验，准确率差异的因果关系仍待验证，不能据此断言所有 Agent 都有同样严重的问题。

受控实验支持的是：在仍有其他取证路径的案例中，信息丢失可能先表现为额外工作。把它进一步推成所有团队都会遇到的成本规律，还缺少跨任务、跨系统的对照数据。

对于始终返回短小、扁平结果的工具，这套观测可能收益有限。对于返回可增长列表、日志和跟踪数据的工具，交付过程就值得单独检查。原文没有提供通用预算、最佳截断长度或裁剪算法；具体怎么取舍，仍要看漏掉一个字段会影响什么。

能拿来做什么

• 给读取日志、文件搜索或诊断结果的 Agent，同时记录工具原始输出和实际送给模型的文本，并按调用关联起来。排查漏读时，先定位信息在哪一步消失。

• 对返回 JSON 的 Node 工具，统计各字段被截断的频率，并检查送达后的载荷能否继续解析。只监控请求成功率，覆盖不到这种内容损坏。

• 在 AI 编程评测里，把工具调用数、计算次数和每个有效发现的工作量放到答对率旁边。一次仍然成功、却需要更多调用的改动，也应进入回归分析。

• 单独保留一组「证据只有一处」的案例，例如线索只出现在某条日志或某个工具字段中，并分别报告准确率，避免大量容易补救的案例掩盖交付缺陷。