这篇是编码智能体工程侧少见的组件级拆解，43 页，四模型两基准。帖子四条发现全部对得上原文，但"176 个匹配设置"的账它没算全，最贵的那个反例它也没提。
一、176 的构成：22 × 8，与直觉的乘法不同。 5 种上下文管理策略 × 4 种窗口预算 = 20，加 2 个组件消融（去规划、bash-only，只在 T4/128k 下测）= 每对模型-基准 22 个设置，4 模型 × 2 基准 = 8 对，22×8 = 176。四个模型是 Nemotron-3 的 30B/120B/550B 三档 + 跨家族对照 Mistral-Medium-3.5-128B——帖子只说"4 个模型"，把"结论要跨家族才立得住"这层丢了。
二、防溢出是全部收益的来源，量化在这里。 T0（无管理）的溢出率随窗口 32k→128k 从 78.7% 降到 8.7%（SWE-Bench）、61.0% → 12.1%（Terminal-Bench）；所有受管策略全程零溢出。管理带来的成功率增益从 32k 的 35.7 个百分点缩到 128k 的 2.7 个百分点——窗口越大，上下文管理越接近无用功，这是全篇最有时代感的数字。
三、"可恢复省略"的量化：模型根本懒得用。 64 个 T2/T4 设置里 36 个（56.3%）从未调用 recall_event；平均调用次数从 32k 的 0.540 跌到 128k 的 0.007；用得最重的配置（30B/TB/32k/T2）4.326 次/任务，成功率反而比 T1 低 3.37%。T2 对 T1 总体 −0.36 pp（15 胜 14 负 3 平）——花哨的恢复机制，净收益约等于零。
四、bash-only 有个 23.2 个百分点的反例。 550B 模型 bash-only 成功率 SWE +3.6 / TB +5.6，成本 −53% / −30%（$2.33→$1.11；$2.43→$1.70）；但 Mistral 在 SWE-Bench 上从 68.60% 跌到 45.40%（McNemar + BH 校正后 q<0.05）。不过它在 Terminal-Bench 上 bash-only 反而 +6.7 pp——是任务类型相关的权衡，与模型 bash 熟练度强相关。
补一个没说的：这套 harness 是作者自建的（LangGraph 底座 + Harbor 基准驱动，ReAct 循环，软/硬阈值 0.6/0.85），论文里没给名字也没给仓库链接——声称"提供模块化框架"却无法复现，这是它离好论文最近的一步。
下一根钉子：128k 窗口下管理收益只剩 2.7 pp，那原生 256k/1M 窗口的模型还需要 harness 吗？等下一代原生长窗模型出来，把同一张 22×8 表重跑一遍，答案自己会浮出来。