一条正在换挡的研究线索
过去半年，智能体工程领域有一条线索持续升温：在模型权重不动的前提下，只改模型外面的那层执行环境，就能显著改变任务表现。这条线索的产物被统称为 Harness——循环控制、工具调用、上下文管理、权限约束、编排与扩展，全部属于它。
围绕 Harness 的研究，前一段时间主要在回答「能不能自动优化」。同一周出现的两篇新论文，把问题往前推了一步：一篇问的是「怎么优化才不会被基准带偏」，另一篇问的是「什么才算 Harness」。前者关心效率，后者关心定义，合起来说明这条线索正在从探索期进入整理期。
需要说明的是，这两项研究均处于论文阶段，缺少生产规模验证与第三方独立复现，部分实验设置与数据细节也未完全公开，官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
一篇论文：一次失败说明不了什么，二十次才能
论文 Ecdysis（arXiv 编号 2609.11677，9 月 10 日提交）指出了一个成本很高的习惯：Harness 演化通常是这样做的——看一次失败的运行，判断是脚手架的问题，打一个补丁，然后重复。研究者认为这个「逐例循环」既慢又容易判断错。
它的核心主张叫「批量级的跨实例失败聚合」。道理其实很朴素：如果某个失败只在某一个任务上出现过一次，你无法判断是模型在这个问题上弱，还是脚手架少了点什么；但如果同一种失败形态在二十个不同任务上重复出现，那大概率是脚手架的问题。前者你去改脚手架，等于在修一个修不了的模型缺陷；后者你去改模型，等于在浪费算力。
论文给出的效果是：相比既有的 Harness 演化方法，训练速度快 1.84 倍，得到的脚手架在推理准确率上高 18.56%。此外它还在聚合之上叠了一层「多角色诊断精炼」，让补丁提案来自不止一个视角，避免单一诊断口径带来的偏差。
真正的敌人是过拟合
这篇论文最值得记录的判断，是它把「过拟合」当成了主要靶子。一个被反复针对某套基准调优的脚手架，会在这套基准上拿到很好的分数，同时在未见过的任务上悄悄退化。
这个现象在模型侧早就有大量讨论，基准污染与刷榜是常见话题；但在脚手架侧，此前几乎没人系统测量过。原因也不难理解：模型有公开权重和标准评测，脚手架则千差万别，很难建立可比性。Ecdysis 的价值在于把这个被忽视的问题摆上了台面——如果脚手架会成为产品差异的主要来源，那么「脚手架本身会不会被基准带偏」就是一个必须回答的问题。
另一篇论文：给 Harness 立必要与充分条件
另一篇论文叫《What makes a harness a harness: necessary and sufficient conditions for an agent harness》，作者来自戈亚斯联邦研究所。它处理的是一个看起来很学究、实际很要命的问题：Harness 这个词被用得太随意了，与智能体框架、SDK、IDE 插件、评测工具的边界长期模糊。
研究者的做法是概念分析。他们沿着历史谱系往回追，把 Harness 从传统的软件测试工具，到机器学习评估工具，再到智能体执行环境这条演变链梳理清楚，然后提出了一套可操作的定义标准，给出一个系统成为智能体 Harness 的必要条件与充分条件，并通过「包含测试」与「排除测试」来划定概念边界。
为了验证这套定义不是纸上谈兵，他们把标准应用到了六个真实的编码智能体系统上——Claude Code、Codex CLI、Aider、Cline、OpenHands 与 SWE-agent，以及若干边缘案例，检查分类结果是否一致。论文的目标不是排名，而是建立一套共享词汇，让后续的工程设计、系统比较与研究有一个共同的坐标系。
定义这件事为什么不是学究
概念澄清的实用价值，在采购与评测环节最明显。当两个团队都在说「我们的 Harness 支持多智能体」时，如果不先对齐「Harness」到底指哪一层，讨论就没有意义。更现实的是评测：如果连被测对象是什么都没定义清楚，基准分数的可比性就无从谈起。
这也解释了为什么这条研究线会与评测研究合流。近期已经出现的主张是：静态题库正在失效，因为模型迭代速度超过了人工设计基准任务的速度。当「考模型」这条路越来越难走，行业自然会转向「考系统」；而一旦开始考系统，就绕不开「系统由哪些部分组成」这个定义问题。
把这批研究串起来看
如果把最近几周的 Harness 研究放在一条时间线上，可以看到比较清晰的三个阶段。起初的问题是「模型之外的那层东西到底有多重要」，出现了把 Harness 效率层的 Token 消耗压掉近一半的开源项目，也出现了在固定权重下把脚手架当成独立研究对象、用大量实例与多模型交叉验证的工作。接着的问题变成「长周期任务怎么持续进步」，出现了在既有编码智能体之上再叠一层外部编排的方案。现在的问题进一步变成「怎么定义它、怎么衡量它、怎么不被基准带偏」。
这个演进顺序本身是有意义的：一个领域只有在开始给自己立标准、开始担心度量失效的时候，才说明它开始成熟。
中立思辨
需要辩证看待几件事。其一，1.84 倍与 18.56% 是在特定实验设置下得到的结果，与真实生产环境的差距尚未被量化，不能直接外推。其二，批量聚合的思路有一个潜在盲区：稀有但后果严重的失败形态可能因为样本太少而被忽略，而这类失败往往才是生产事故的来源，聚合策略需要与「稀有高影响」的单独监控配合使用。其三，定义类论文的价值取决于是否被社区采纳，如果各方继续各说各话，再严谨的界定也只是又一份文献，这类工作的实际影响力需要时间检验。其四，把「框架」与「Harness」严格区分开，在概念上清晰，但在实际系统里两者常常交织，过度的分类洁癖可能增加沟通成本而不是降低。其五，脚手架侧过拟合的测量本身也有方法论难题：如何界定「未见过的任务」，不同研究给出的答案可能不同，横向比较仍需谨慎。其六，这条研究线的共同前提是「Harness 是主要变量」，但如果未来模型自身对执行环境的鲁棒性大幅提升，Harness 优化的边际收益可能会下降，投入产出比需要动态评估。
趋势研判
短期看，Harness 的定义与评测会成为学术与工程共同关注的问题，出现更多类似「必要与充分条件」这类基础工作；中期看，如果脚手架侧的过拟合问题被广泛承认，基准的设计逻辑可能会改变，从「单一静态题库」转向「多套轮换题库加未见任务验证」的组合；长期看，一旦 Harness 的边界与评价标准稳定下来，它有可能像今天的容器与编排系统一样，从「每个团队自己造」变成「有公认实现可选」的基础设施层。
对工程团队来说，一个立即可用的建议是：在优化脚手架之前，先记录失败是按任务聚集还是跨任务重复。前者指向模型能力，后者指向脚手架设计。这个区分不需要任何新工具，只需要在日志里多记一个字段，却能省下大量在错误方向上投入的算力。