研究发现：让编程智能体失败的是上下文溢出，而不是压缩质量
176 组对照实验分离出：框架里哪些部件真的影响跑分，哪些只增加成本
一支来自马萨诸塞大学阿默斯特分校、埃默里大学和北卡罗来纳大学夏洛特分校的九人研究团队 —— 部分工作是在 Zoom Video Communications 实习期间完成的 —— 本周发表了一项实证研究，首次通过受控隔离的方式确定：编程智能体的框架（harness）中，哪些部件真正影响基准分数，哪些只增加工程复杂度而没有可测量的收益。这篇题为《An Empirical Study of Harness Design for Coding Agents》的论文于 9 月 17 日登上 arXiv，并在提交后 24 小时内冲到 HuggingFace Papers 第三位。
每个智能体开发者都有的问题，终于有了大规模的答案
这项研究针对的问题贯穿了 2026 年的编程智能体评测：同一个模型放进不同的框架里，在同一个基准上的得分可以相差 10 到 20 个百分点，但此前没有任何工作在受控条件下系统性地解释过原因。已有的比较都是拿完整的智能体系统互相比，这让人无法把表现差异归因到具体部件上。研究团队的解法是搭一个模块化框架，固定执行循环 —— 也就是决定何时停止、何时调用工具、何时推进任务的那部分 —— 只改动三个部件：上下文管理、规划和动作空间。由此得到的实验覆盖 176 组一一对应的配置，在四个模型上跑了两个基准：SWE-Bench Verified（500 个任务的 Python 软件工程基准）和 Terminal-Bench 2.1（89 个任务的终端操作套件，覆盖科学计算、系统管理、数据科学和安全）。
实验设计横跨五种上下文管理策略和四档不同的上下文窗口预算 —— 从非常紧到基本不受限 —— 并对规划模块和工具接口做了针对性的消融。176 组的规模，加上跨模型、跨基准的广度，使它成为迄今框架工程文献中受控最系统的一项部件消融研究。
主要的失效模式是上下文溢出，而不是压缩质量
这项研究最能立刻拿来用的发现，和上下文管理有关。研究者测试了一条光谱上的五种策略：什么都不做；按规则删减、丢掉较旧的上下文；用大模型做摘要；先按规则删减、再以大模型摘要作为兜底；以及让被删减的内容可恢复，使智能体之后还能取回。他们还在四种不同的上下文窗口预算下逐一测试，看预算收紧或放宽时每种策略的价值如何变化。
最醒目的结果是哪一种没用：可恢复的删减。让智能体有能力取回此前被压缩掉的内容，增加了工程复杂度，但论文报告说，模型很少真的去调用这个恢复机制，相比更简单的做法没有带来准确率提升。把删减做成可恢复的那份工程投入，在模型的实际行为面前根本不划算。
真正有用的是分级策略：先做基于规则的删减，只在需要时才升级到更贵的大模型摘要。在所测试的策略中，这个组合取得了最好的总体效率。关键在于，研究者进一步考察了上下文管理的准确率收益究竟从哪里来，发现其中大部分来自避免上下文溢出失败 —— 也就是智能体的上下文窗口被填满、执行轨迹在任务完成前就终止的情形。一旦溢出被挡住，再在上面叠加更精巧的压缩，贡献就相对有限了。
这个发现有直接的架构含义。学界在基于大模型的上下文压缩、摘要质量和可检索记忆系统上投入了大量研究精力。这项研究表明，对于在现实上下文预算下运行的编程智能体来说，一个更简单但可靠的溢出预防机制，就能吃下准确率收益中的大头。一旦溢出被可靠地挡住，团队可以把工程预算花在别的部件上。
延伸阅读：OpenAI Agents API 开放公测，所有开发者都能用上托管的 Codex 编排框架
规划和工具设计，随模型能力朝相反方向变化
研究的第二组重要发现，关于规划和动作空间设计如何与模型能力相互作用。结果并不一致 —— 合适的框架配置，根本上取决于你用的是哪个模型。
在规划上，轨迹层面的分析揭示了一种随能力而来的角色反转。对较弱的模型，加一个规划阶段起的是准确率脚手架的作用：它让轨迹活得足够久，使智能体能真的尝试一次编辑，从而提高成功率。对较强的模型，准确率上的好处基本消失，但规划转而起到省钱的作用 —— 减少编辑之后冗余的验证步骤，降低总推理成本，而不改变任务成功与否。研究者把这概括为：随着模型变强，规划从脚手架转变为效率手段 —— 这个结果反对在不同档位的模型上套用同一份框架配置。
动作空间的结果遵循类似的逻辑。bash 熟练度较弱的模型，在拿到一组预定义的结构化工具时表现更好，因为预定义工具减少了对拼装 shell 命令的依赖，也能挡住常见的失败模式。而本来就精通 bash 的模型，只给一个 bash 接口也能干得很好 —— 尤其在以命令行为中心的任务上，只给 bash 反而成本低得多，因为它们可以把多个操作合进一次工具调用，而不必分别派发多个结构化工具。研究者的轨迹分析解释了其中的机制：动作空间改变的是代码被写出和组合的粒度，而不是任务是否被尝试、或者在哪里终止。
框架工程这门手艺，迎来第一条受控基线
这项研究出现在框架工程迅速形成为一个研究领域的当口。2026 年发布的几项平行工作处理的是相关但不同的问题。英伟达的 SoL-Pi 于 9 月 11 日开源，走的是效率路线：用自动研究循环找出能把 token 流量和 API 成本降低 45%–64% 的机制，同时不提前中止智能体、也不隐藏证据。它的四项机制 —— 动作融合、上下文重放管理、观察裁剪和选择性日志读取 —— 针对的是同一层框架，但优化目标是成本，而不是分离出各部件的贡献。Meta-Harness 由 Lee 等人于 2026 年发表，走的又是另一条路：自动化的框架搜索 —— 由一个智能体提议者从完整的执行轨迹出发，迭代地提出更好的框架实现，在文本分类基准上取得了 7 个准确率点以上的提升。
这篇论文与 Fan 等人工作的区别在于方法论上的贡献。它并不提出一套新的框架配置供人采用，而是提供了一套受控的实验设计，让其他人可以用它来评估未来的部件。固定执行循环、只变三个部件的这套框架，是为了让结果能归因到具体选择，而不是归因到未被测量的交互效应。这与 SoL-Pi 那种可以立刻部署的机制、或者 Meta-Harness 的自动搜索是不同性质的价值 —— 它更接近于框架研究本身的一套基准方法论。
研究的边界，以及哪些还需要独立验证
有几点需要注意。论文用了四个模型 —— Nemotron-3 家族的三种规模（300 亿、1200 亿和 5500 亿参数）和 Mistral-Medium-3.5-128B —— 作为能力和交互风格的探针，既覆盖家族内部的能力轴，也做了跨家族的对比。规划和 bash 熟练度的阈值 —— 角色反转究竟发生在哪个能力水平上 —— 只有定性描述，而没有换算成从业者可以直接查阅的模型能力指标。基准套件集中在 Python 软件工程和终端任务上；同样的结论在多文件、多语言或企业级代码库上是否成立，仍是未解的问题。
SWE-Bench Verified 这个基准本身在 2026 年也带着数据污染方面的疑虑 —— 前沿模型如今在这 500 个任务上已经能到 80% 以上，这让人怀疑剩下那些没被解决的任务还有多少代表性。Terminal-Bench 2.1 构建的时间更近，被刷饱和的可能性较小。如果能在第三个基准上独立复现这些发现，尤其是在 SWE-Bench Pro（Scale AI 推出的、控制了污染的后继版本）上，结论会大大增强。
可恢复删减这个发现 —— 模型很少去调用取回机制 —— 也值得后续追踪。未来如果模型被专门训练去在长程任务中使用检索，它们从这类系统中榨出的价值可能比当前这一代多，这意味着今天的这个结论可能随着训练方式的演进而过时。
框架带来的差距，现在可以测量，而不只是被观察到
多年来，编程智能体的开发者一直看得到框架造成的分数差距，却说不清是哪个部件导致的。这项研究把这场讨论从轶事推进到数据：上下文管理在预算紧张时最重要，但那只是因为溢出会杀死轨迹；规划取决于模型能力，对更强的模型来说，它优化的可能是成本而不是准确率；只给 bash 的接口能为有能力的模型省钱，而对还在学 shell 的模型，结构化工具仍然必要。这个领域的下一步，是把这套受控方法论延伸到轨迹长达数小时的长程基准、延伸到框架之间相互作用会带来新失效模式的多智能体场景，以及延伸到原生上下文窗口更大的模型的上下文管理策略 —— 在那里，溢出的阈值会移动，各策略的相对价值很可能又会变。