上下文是流水线而非窗口：LLM 智能体框架中的信息损耗

1. 问题与价值

这篇论文解决的是一个被系统性忽视的问题：LLM 智能体在调用工具后，工具产生的结果在到达模型之前，有多少信息被 harness（包裹模型的代码层）悄悄丢弃了。作者的核心主张是，智能体的上下文不是一个「窗口」，而是一条「管道」——工具产出、序列化、预算截断、跨轮保留、阶段间传递，每一步都是一个可能丢失信息的边界。

这个问题重要，因为当前对 LLM 智能体的评估几乎只看两个数字：上下文窗口有多大，最终答案对不对。这两个数字都看不见中间的信息损耗。一个智能体可以在窗口几乎全空的情况下，仍然因为 harness 在交付前把工具结果截断而丢失关键证据。作者在真实部署中测到的数据是：720 次运行中，最大的 prompt 只用到窗口的 5.75%（该实验的窗口上限是 400k，原文第 IV 节给出），但 11,189 个工具结果中有 3,827 个（约 34%）在到达模型前被截断，且每一个被截断的结果都变成了损坏的 JSON。

受益者是所有构建和使用 LLM 智能体的人。但先把这篇论文的贡献说准：它是「知道」，不是「做到」——核心是测量（把上下文拆成五个边界并逐一实测），以及用受控实验去检验「数据丢失是不是准确率下降的原因」——但论文自己的结论更保守：因果仍是 open question，受控实验显示截断的代价首先表现为额外工作量，而不是错误答案（原文：The accuracy half of the field split remains correlation, not cause）。修复（row-aware cut）是这项测量的副产品，不是论文的主语。

对框架开发者，最有用的也不是那个修复，而是缺陷模式本身：按位置切片 JSON 文本，会按字段顺序整体删除靠后的字段。同一批结果里，一个字段只有 4.7% 的情况下到达模型，另一个字段是 99.3% —— 同一份数据、两个字段的存活率差二十倍，这种不对称是只看准确率永远发现不了的。对部署团队，它提供了一个新的监控维度：除了准确率和延迟，还应该报告每个边界上「有多少产出的证据存活到了下一步」。对研究者，它把「上下文管道上的信息损耗」确立为一个可测量、可复现、可做因果实验的研究对象。

2. 已有工作的不足

在本文之前，最接近的工作可以分为几类，每一类都有一个具体的缺口。

第一类是上下文窗口和注意力研究，代表是 Liu et al. 的「Lost in the Middle」和 Hsieh et al. 的 RULER。这些工作研究的是模型在窗口内部如何不均匀地使用不同位置的信息。但它们的起点是「信息已经在窗口里了」。本文指出，在信息进入窗口之前，harness 可能已经把它删掉了。一个被截断的字段不是「被注意力忽视了」，而是「注意力根本没有机会看到它」。

第二类是 harness 源码研究，代表是 Barbaste et al. 对 11 个编码智能体系统的源码研究和 Rombaut 对 13 个 scaffold 的分类。这两项工作读了源码，但没有测量数据在通过 harness 时实际发生了什么。知道一个框架「有截断逻辑」和知道「这个截断逻辑在真实运行中删掉了 34% 的结果、且全部变成损坏 JSON」是两回事。

第三类是失败分类研究，代表是 Cemri et al. 的「Why do multi-agent LLM systems fail?」。这类工作给失败打标签，但标签不是损失测量。说「这次运行失败了，原因是工具输出不完整」和说「这个字段在 742 次调用中只有 4.7% 到达了模型」是完全不同的信息粒度。

第四类是最接近的四项工作。Kate et al. 问模型能不能用好工具的完整输出；本文问的是输出本身是否完整。Yao et al. 的 Harness-bench 测量 harness 设计如何改变结果，但把方差追溯到结果层面，没有定位到具体的损失点。Fan et al. 在编码 harness 中变化上下文管理策略和窗口预算，报告了成功率和成本，但没有报告每个策略删掉了哪条证据。Zhang et al. 发现把工具输出存到文件里再检索会损害某些模型的准确率，但那是检索选择的问题，不是本文说的「破坏性交付」——信息在进入日志之前就已经没了。

所有这些工作共享一个盲区：运行日志记录的是工具「交付了什么」，不是工具「产出了什么」。在进入日志的路上发生的损失，无法从日志里找到。

3. 重建作者的思考路径

如果我是作者，面对第 2 项里的缺口，我的起点会是：我想知道工具结果在到达模型之前到底损失了多少。最直接的办法是去翻运行日志。但我马上会撞上一个矛盾——日志里存的已经是截断后的结果，我根本不知道截断前是什么样。要解决这个矛盾，我得在 harness 里加一层记录，在截断发生之前把完整结果存下来，同时记录截断后实际发给模型的是什么。这样我才能做对比。

有了这个对比，我会先看到一个让我意外的数字：窗口几乎全空，但三分之一的工具结果被截断了。这说明截断不是因为窗口不够用，而是 harness 里有一个独立的、固定的预算。接下来我会问：截断到底删掉了什么？如果截断是均匀的，那每个字段应该按比例损失。但 JSON 的键顺序是固定的，前缀切片意味着靠后的字段整体消失。我会去验证这个猜测，结果发现同一个 payload 里，一个字段到达率 4.7%，另一个 99.3%。这证实了「按位置删除」的机制。

到这里，我有了一个相关性发现：数据丢失和准确率下降在字段数据里同步出现。但我知道相关性不是因果。而且还有一个混淆因素：修复交付边界的同时，我还上线了两个新的分析工具，准确率提升可能来自工具而不是修复。要分离因果，我得做受控实验，把每个缺陷单独放回去，其他条件全部固定。

设计实验时，我会先预测：如果把键顺序反过来，原来存活的字段会变成被删除的，准确率应该下降。这个预测看起来很合理。但实验结果会推翻它——准确率没降。我会去查 transcript，发现 agent 通过另一条路找到了答案：那个故障进程是 trace 里最响的，占了 14.0% 的内核事件，它出现在 agent 自己构建的排序表的前几行，而前几行恰好是切片后存活的部分。这个发现会逼我修正原来的规则：截断只在 agent 没有第二条路径时才会伤害准确率，而且它的代价首先表现为额外的工作量，而不是错误答案。

与论文实际路径的差异：我猜的路径是先做受控实验、再发现「补偿税」现象，论文的实际路径是先有完整的字段数据（720 次运行、11,189 个工具结果），从字段数据里看到了 4.7% 对 99.3% 的极端不对称，然后才设计受控实验去验证因果。论文还多做了一步我没想到的：在生产规模的 trace 上做直接 replay，用真实的 33,370 字符结果验证切片规则会删掉全部 128 条晚期列表记录。另外，论文对七个框架的源码调查也是我猜的路径里没有的——那是为了回答「这个缺陷有多普遍」而做的外部验证。

4. 核心 intuition

用一个日常类比：想象一个快递分拣中心，包裹按照固定的装箱顺序排列——地址标签永远放在箱子最上面，货物清单永远放在最下面。分拣中心有一个规定：每个箱子只保留前 60 厘米的内容，超出的部分直接切掉。这个规定听起来是在「缩短箱子」，但实际上它永远只删掉箱子底部的东西。如果货物清单在底部，那货物清单永远消失；如果地址标签在顶部，那地址标签永远安全。箱子里装了什么不重要，重要的是东西放在哪个位置。

这个类比对应论文的机制：harness 对 JSON 文本做前缀切片，JSON 的键顺序是固定的，所以切片永远删除靠后的字段，完全保留靠前的字段。一个字段是否存活，不取决于它对任务有多重要，只取决于它在文本里的位置。这就是为什么同一个 payload 里，一个字段到达率 4.7%，另一个 99.3%——不是模型选择性地关注了哪个，而是切片规则机械地决定了哪个能活下来。

这个机制之所以危险，是因为它和任务的真实结构完全脱节。在论文的场景里，故障的证据在哪个字段取决于故障进程是「新启动的」还是「一直在运行的」。这个时间属性决定了证据在 JSON 里的位置，而位置又决定了证据是否被切片删除。一个对任务至关重要的字段，可能因为恰好排在后面就被整体删除，而 agent 甚至不知道它存在过。

5. 方法 pipeline 举例

假设有一个具体的诊断运行。输入是一条 Linux 内核 trace，来自一个 21 容器的部署，其中一个 Java 服务被施加了 CPU 限制。agent 的任务是找出哪个容器是故障源。

第一步，agent 调用容器列表工具。工具产生一个完整结果，包含两个顶层字段：early_list（trace 早期启动的容器）和 late_list（trace 开始前已经在运行的容器）。完整结果有 33,370 个字符，其中 early_list 有 118 条记录，late_list 有 128 条记录。故障容器在这个场景里是「一直在运行的」，所以它的证据在 late_list 里。

第二步，harness 的 S1 边界对结果做前缀切片。shipped 预算是 6,000 字符。切片保留前 6,000 字符，剩下的全部删除。结果是：early_list 的 118 条记录里前 30 条存活，late_list 的 128 条记录全部消失。整个 payload 因为 JSON 被从中间切断而变成损坏的 JSON。

第三步，损坏的 JSON 被发给模型。模型看到的是一个不完整的、无法解析的 payload。它可能尝试从 early_list 的前 30 条记录里找线索，但故障容器不在那里。

第四步，agent 根据收到的信息做推理。如果故障容器恰好也是 trace 里内核事件占比最高的进程（比如 14.0%），它可能出现在 agent 自己构建的排序表的前几行，而前几行在切片后存活。这样 agent 仍然能通过第二条路径找到答案。但如果故障容器是「安静的」——比如五个 Java 容器各占约 1.4% 的内核事件，没有明显突出——那它就没有第二条路径，答案就找不到了。

第五步，agent 的最终答案取决于它是否找到了第二条路径。在受控实验的 spawned 故障类里，故障进程是新启动的，证据在 early_list 里，切片后存活，所以准确率高。在 resident 故障类里，证据在 late_list 里，切片后消失，准确率低。这就是字段数据里 40–55 分对 0–24 分的分裂的来源。

6. 核心数学推导

论文的核心量化工具是 yield，定义为「记录到的发现数除以执行的计算数」。用符号表示：yield = findings_recorded ÷ computations_run。

先解释每个符号。findings_recorded 是 agent 在运行过程中明确记录下来、并且成功传递到决策阶段的发现数量。computations_run 是 agent 实际执行的计算数量，在论文里用工具调用数或计算步骤数来近似。yield 衡量的是「有多少工作真正到达了决策环节」，而不是「工作做得好不好」。

推导 yield 为什么能捕捉到截断的代价。假设一次运行中 agent 执行了 C 次计算，每次计算产生一个发现。在理想情况下，所有 C 个发现都被记录下来并传递到决策阶段，yield 等于 C ÷ C = 1。现在引入 S1 截断：每次工具调用有概率 p 被截断，被截断的结果变成损坏 JSON，其中的发现无法被记录。那么预期记录到的发现数是 C × (1 - p)，yield 变成 C × (1 - p) ÷ C = 1 - p。

但论文观察到的现象比这个简单模型更复杂。在受控实验中，从 repaired 到 S1 defect，计算数从 18 升到 32，而发现数保持在 11。yield 从 11 ÷ 18 = 0.61 降到 11 ÷ 32 = 0.34。这里的关键是：发现数没有减少，减少的是 yield 的分母——计算数增加了。这意味着截断的代价首先表现为「agent 做了更多计算，但没有找到更多东西」，而不是「agent 找到的东西变少了」。

用论文的数据验证：repaired 条件下 yield 是 0.61，S1 defect 条件下是 0.34，S1 reversed 条件下是 0.31。三个条件下的发现数都是 11，但计算数分别是 18、32、36。yield 的下降完全来自分母的膨胀。这个公式在算的是：agent 每找到一个有效发现，需要付出多少无效的计算代价。yield 越低，说明 agent 在截断造成的黑暗中浪费了越多的努力。

7. 实验设计

数据集：受控实验使用 Linux 内核 trace，来自一个编码 agent 在资源限制下运行的场景，带有精确的 ground truth。有两类故障：spawned faults（故障进程在 trace 中途启动）和 resident faults（故障进程在 trace 开始前已经在运行）。每类故障有 5 个不同的 recording，每个 recording 重复 3 次。另外还有健康 trace 作为负控制。总运行数是 145 次，没有一次失败。

基线：repaired 配置是修复后的版本，使用 row-aware cut 和自动 hand-off。这是所有缺陷配置的对照基线。

配置：共六个配置，在原 harness 上逐项对照，原文 Setup 的命名是 repaired、S1 defect、S1 reversed、order-only control、single-defect arms（S2–S4）、all defects。repaired 是修复版。S1 defect 单独重新引入前缀切片截断。S1 reversed 保持截断但反转键顺序。order-only 只反转键顺序不截断，用来隔离重排序的影响。single-defect arms 分别重新引入 S2 到 S4。all defects 同时重新引入全部五个缺陷，匹配原始 shipped harness。

指标：正确性（agent 是否在答案字段中明确命名了正确的故障容器，按 ground truth 判定）、工具调用数、被截断的结果数、计算数、yield、输入 token 数。

消融：order-only 配置是关键消融。它只改变键顺序而不截断，用来验证 yield 的变化确实来自截断而不是重排序。结果是 order-only 的 yield 回到 0.61，与 repaired 相同，证实 yield 测量的是截断的真实效果。

实验能否支撑结论：实验能支撑「截断的代价首先表现为额外工作」这个结论，因为从 repaired 到 S1 defect 到 S1 reversed，工具调用数从 53 升到 68 升到 76（53 到 68 是 28% 的上升，68 到 76 是 12% 的上升，累计 53 到 76 是 43% 的上升），计算数从 18 升到 32 升到 36，yield 从 0.61 降到 0.34 降到 0.31，而正确率在 spawned 类里没有显著差异（14/15 对 15/15 对 15/15）。但实验不能支撑「截断导致准确率下降」这个因果主张，因为 spawned 类里准确率没有下降，而 resident 类的受控实验数据在 Table II 中没有报告。论文自己也承认这一点：准确率的一半仍然是相关性，不是因果。

缺什么：缺少 resident faults 在受控实验中的完整结果。Table II 只报告了 spawned-culprit 的 15 次运行的中位数，resident 类的受控数据没有在表格中呈现。另外，5 个 recording 是配对重复，不是 5 个独立的故障实例，这限制了统计推广性。

8. take-aways

1. 在 720 次真实运行中，最大的 prompt 只用了 400k 窗口的 5.75%（23k token），但 11,189 个工具结果中有 3,827 个（约 34%）在到达模型前被截断，且每一个被截断的结果都变成了损坏的 JSON。窗口大小和实际信息损失之间没有必然联系。

1. 前缀切片 JSON 文本会按字段位置整体删除靠后的字段。在 742 次调用中，一个字段到达率只有 4.7%，而同一个 payload 里的另一个字段到达率是 99.3%。字段是否存活取决于它在文本里的位置，不取决于它对任务的重要性。

1. 在受控实验中，截断的代价首先表现为额外工作而不是错误答案：从 repaired 到 S1 defect 到 S1 reversed，工具调用数从 53 升到 68 升到 76（累计上升 43%），计算数从 18 升到 32 升到 36（约翻倍），yield 从 0.61 降到 0.34 降到 0.31，但发现数保持在 11，正确率在 spawned 类里没有显著差异。

1. 截断只在 agent 没有第二条路径时才会伤害准确率。一个「响亮的」故障进程（占 14.0% 的内核事件）即使其列表字段被完全删除，仍然能通过 agent 自己构建的排序表的前几行被找到。一个「安静的」故障进程（五个容器各占约 1.4%）没有第二条路径，其证据被删除后准确率崩溃。

1. 七个被调查的框架中，有两个以同样不安全的方式截断工具输出：langchain-core 把序列化的工具输出切片到 500 字符，只保留前面；smolagents 删除超过 20k 字符的 observation 的中间部分。只有一个框架（一个 shell middleware）按整行切割并明确说明，说明安全模式存在但不是默认。

9. 最脆弱的假设

最脆弱的假设是：截断导致的证据丢失是字段数据中准确率分裂的原因。论文的整个因果故事——从 4.7% 对 99.3% 的到达率不对称，到 40–55 分对 0–24 分的准确率分裂——都依赖于这个假设成立。

论文自己给出了这个假设不成立的证据。在受控实验中，S1 reversed 配置成功地把 spawned 故障的列表字段从完全交付变成完全删除，transcript 显示故障容器在每一个 listing payload 里都缺席。但 agent 仍然在 15/15 次运行中正确命名了故障容器。它通过第二条路径恢复了答案：故障进程是 trace 里最响的，占 14.0% 的内核事件，出现在 agent 自己构建的排序表的前几行，而前几行在切片后存活。这意味着至少对于 spawned 类里的「响亮」故障，截断并不导致准确率下降。

论文对这个假设的处理是诚实的：它明确说「准确率的一半仍然是相关性，不是因果」，并把因果准确率实验列为未来计划的第一项。但这也意味着论文最核心的主张——「我们的 harness 对准确率分裂负有部分责任」——在严格意义上还没有被证明。生产规模的 replay 显示 0/5 正确对 3/6 正确，方向一致但样本太小，且 repaired 条件下 6 次运行里有 3 次仍然错误，原因与数据丢失无关。

如果这个假设被推翻——比如未来实验发现 resident 类里截断和准确率没有因果关系——那么论文的贡献会从「发现了一个导致准确率下降的缺陷」降级为「发现了一个导致额外计算成本的缺陷」。后者仍然有价值，但冲击力会小很多。

10. 一周最小复现

目标：复现论文最核心的机制——前缀切片按位置删除字段，以及 row-aware cut 能避免这个问题。不需要复现完整的 agent 诊断任务。

第一天：搭建一个最小的 harness 模拟器。写一个 Python 脚本，生成模拟的 JSON 工具结果，包含两个顶层字段：early_list 和 late_list，每个字段包含 100 条记录，每条记录有 3 个键。完整结果约 30,000 字符（按每条记录约 100 字符自拟，估算）。实现两个切割函数：前缀切片（保留前 6,000 字符）和 row-aware cut（按记录边界切割，保留完整的记录直到预算用完）。

第二天：验证机制。对同一个模拟结果分别应用两种切割。预期结果：前缀切片下 early_list 部分存活、late_list 完全消失、payload 变成损坏 JSON；row-aware cut 下两个字段都部分存活、payload 保持有效。记录每个字段的到达率。

第三天：准备真实数据。从论文的 replication package（DOI 在论文脚注）下载 replay 语料库。如果无法访问，用自己生成的模拟数据代替，但要确保 JSON 键顺序固定、字段大小不对称。

第四天：运行 replay。对 864 个记录的结果（或自己生成的等价规模数据）分别应用两种切割。统计：多少结果被截断、多少变成损坏 JSON、每个字段的到达率。预期结果：前缀切片下所有超预算的结果都损坏，row-aware cut 下没有损坏。

第五天：做一个最小化的「第二条路径」验证。构造一个场景，其中 late_list 里的某个记录也在 early_list 的前几行出现（模拟「响亮的」故障进程）。验证：即使 late_list 被完全删除，这个记录仍然能通过 early_list 被找到。这复现了论文中 S1 reversed 实验的核心发现。

第六天：写一个简短的报告，包含：切割机制的确定性验证、字段到达率的不对称性、row-aware cut 的修复效果、第二条路径的补偿效应。

第七天：如果时间允许，用一张 24GB 消费级显卡跑一个小规模的 LLM 验证。用一个 7B 模型，给它一个被截断的 JSON 和一个完整的 JSON，看它能否在两个条件下都找到目标记录。预期：完整 JSON 下能找到，截断 JSON 下找不到（如果目标记录在 late_list 里）。这个实验不需要训练，只需要推理，24GB 显存足够。

预期指标：前缀切片下超预算结果的损坏率 100%，row-aware cut 下损坏率 0%。字段到达率的不对称性应该清晰可见。如果使用论文的 replay 语料库，应该能复现「50% 的 process-listing 调用损坏」这个量级。

11. 反例设计

要推翻本文的核心主张——「前缀切片按位置删除证据，且这种删除在 agent 没有第二条路径时会伤害准确率」——可以设计以下实验。

实验设计：选择一个 resident fault 场景，故障容器是「安静的」（在 trace 中没有突出的内核事件占比，比如五个容器各占约 1.4%）。确保故障容器的证据只存在于 late_list 字段中，没有第二条路径可以找到它。使用论文的 repaired 配置作为基线，确认 repaired 条件下 agent 能以高准确率找到这个故障容器（比如 5/5 或 4/5）。

关键操作：在 S1 defect 配置下运行同样的 trace。前缀切片会删除 late_list 的全部记录。如果 agent 仍然能以与 repaired 相当或更高的准确率找到故障容器，那么论文的核心主张就被推翻了。

判据：如果 S1 defect 条件下 agent 的准确率不低于 repaired 条件（比如 repaired 是 4/5，S1 defect 也是 4/5 或 5/5），且 transcript 确认 late_list 确实被完全删除、故障容器没有出现在任何存活的数据中，那么「截断导致准确率下降」的因果链条就不成立。agent 一定通过某种论文没有预料到的机制恢复了答案，或者答案根本不需要 late_list 的证据。

为什么这个实验有区分力：论文的字段数据中，resident 类的准确率是 0–24 分（满分 60），远低于 spawned 类的 40–55 分。论文把这个分裂归因于 late_list 的到达率只有 4.7%。如果在一个严格控制的环境里，删除 late_list 不影响 resident 类的准确率，那么字段数据中的分裂一定有其他原因——可能是 resident 故障本身更难诊断，而不是证据被删除了。

可能的反例结果：如果 agent 在 S1 defect 条件下仍然找到故障容器，可能是因为它从其他工具的输出中推断出了答案——比如从进程事件的时间戳、从资源使用模式、或者从 trace 的其他部分。这会说明「第二条路径」比论文认为的更普遍，截断的伤害被高估了。

12. 落地判断

能否用于「抢占式 GPU 自托管 27B 模型做多智能体脚手架」：能，而且这篇论文的发现对这个场景特别相关。抢占式 GPU 意味着计算资源不稳定，27B 模型意味着单次推理的 token 成本不可忽略，多智能体脚手架意味着有多个 worker 在并行调用工具、传递结果。这三个特点恰好放大了论文发现的缺陷的代价。

怎么用：第一，在脚手架里实现 row-aware cut 而不是前缀切片。具体做法是：对每个工具结果，按记录边界切割，保留完整的记录直到预算用完，而不是按字符数切到固定位置。这需要知道每个工具输出的 JSON schema，但这是一次性的工作。第二，在脚手架里加一层 S1 边界监控：记录每个工具结果的完整大小、截断后大小、哪些顶层字段到达了模型、payload 是否仍然有效。第三，报告 yield 指标：每个 worker 记录了多少发现、传递了多少到决策阶段。这三个改动都不需要额外的 GPU 资源，是纯代码层面的修改。

成本量级：row-aware cut 的实现成本很低，对于一个已经知道工具输出 schema 的脚手架，每个工具加一个切割函数大约是几十行代码。监控层的成本是每个工具调用多存一份完整结果和一份截断结果，对于 27B 模型的多智能体运行，存储开销相对于推理 token 成本可以忽略。yield 的计算是简单的除法，没有额外推理成本。

最大的坑：论文明确指出，修复 S1 边界可能不会立即改善准确率——在 spawned 类里，repaired 和 S1 defect 的正确率差异是 14/15 对 15/15，在噪声范围内。如果你的多智能体系统里的故障模式恰好是「响亮的」——有第二条路径可以找到答案——那么修复截断只会减少 token 消耗（从 68 次调用降到 53 次，即 (68-53)/68≈22% 的减少），不会改善准确率。你可能会觉得修复没有效果而放弃。真正的收益在「安静的」故障上，但这些故障在你的系统里可能很少见，或者你根本没有 ground truth 来识别它们。另一个坑是：论文发现两个主流框架（langchain-core 和 smolagents）有同样的问题，如果你的脚手架构建在这些框架之上，你需要绕过它们的默认切割逻辑，否则你自己的 row-aware cut 会在上游已经被前缀切片破坏的数据上操作。