两篇论文，同一个问题
过去一年，一个判断在工程圈里被反复提起：同一套模型权重，放进不同的执行框架，干活效率可能差出一大截。这个说法此前多半靠经验与零散对照支撑，而 9 月上旬前后发布的两份工作，把它变成了可测量、可复现的研究对象。
一份来自字节跳动 Seed 团队，联合新加坡科技设计大学、佐治亚理工学院、M-A-P 与 TokenWave.AI，名为 HarnessDev，问的是：大模型能不能像前瞻部署工程师那样，自主搭建并持续演进自己的 Agent Harness。另一份来自 Meta，编号 arXiv 2609.10922，名为 Auto-RecSys，问的是：在不换模型的前提下，把 Harness 工程做好，能把一个长周期、高成本的自动化流程做到多稳。两份工作的共同前提是——Harness 已经不是附属的「胶水代码」，而是决定结果的一层。
需要说明的是，两份工作都是作者自测口径，尚无独立第三方复现，具体百分比应作为阶段性参考。截至目前，HarnessDev 的后续版本计划与 Auto-RecSys 在推荐系统之外场景的迁移效果，官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
HarnessDev：把「可运行的系统」当作被测对象
主流基准的做法是固定 Harness，只给模型的答案打分。HarnessDev 把这个靶子换了：它评估的是模型亲手写出的那套可执行系统——循环逻辑、工具、上下文处理、状态、失败恢复、停止规则与验证机制。
论文开篇给出的对照很有说服力：同一套 GPT-5 权重，在 Terminus 2 这个脚手架里解出 Terminal-Bench 任务的 35.2%，换到 Codex CLI 里则升到 49.6%。这个差距比多数模型升级带来的提升还要大。
基准分两个阶段。创建阶段里，每个模型拿到同一个「弱种子」——只有文件、搜索、进程三类基础原语，没有规划器、没有验证器、没有重试逻辑、没有停止规则——然后自行搭出一套完整可运行的系统。演进阶段则让模型根据执行反馈修改自己那份被冻结的代码，再用它从未见过的 SWE-bench Pro 任务来评分。整体规模覆盖 2,207 个任务实例，横跨 SWE-bench Pro、Terminal-Bench 2.1、MLE-bench、EQ-Bench3 与 BrowseComp 五类基准，六个创建模型统一在 Claude Code 2.1.177 里工作。
分域成绩：写作与实验超过参考，代码与检索差得远
在自评口径下，Opus 4.8 拿到 67.8 的平均分，低于人类工程化参考实现的 86.2。但真正有信息量的是分域结果，而不是这个平均值。
在代码域，Opus 4.8 在 SWE-Pro 上拿到 69.3，参考实现是 80.0；在终端任务上，Gemini 3.1 Pro 以 68.8 领先，但参考实现高达 88.8；在检索域，GPT-5.5 在 BrowseComp 上只有 52.6，参考实现是 92.2。反过来，在写作域 Opus 4.8 以 84.6 超过 83.7 的参考值；在机器学习实验域，Opus 4.8 的 32.9 与 Gemini 的 32.4 都高于 24.0 的参考值。
这组数字传达的判断是：智能体并不是在所有任务上均匀地差，而是按工作负载类型分化。写作与实验类任务对运行时差异的容忍度更高；代码与检索类任务对规划质量、重试规则与工具纪律要敏感得多。
还有一个反直觉的发现：代码量并不预示质量。18 个由模型生成的系统一共新增了 17,111 行代码，但加行数少的 Gemini 反而在 Terminal-Bench 上领先。在 108 个代码组件实例中，有 18 个在运行时从未被触发，全部集中在状态与记忆模块；在写作类系统里，587 个特性中有 124 个是死代码。换句话说，模型很擅长写出看起来很完整的框架，但其中相当一部分从未真正发挥作用。
演进阶段：它分不清「改进」和「噪声」
如果说创建阶段说明模型能搭出系统，演进阶段说明的则是另一件事——它未必能判断自己的修改到底有没有变好。
在 73 个版本、9 条轨迹的演进过程中，模型能看到的反馈方向与它看不到的留出表现，在 64 次可比版本切换里只有 34 次同向，也就是 53.1%。这个数字意味着：Agent 用来判断「上次改动是否有帮助」的信号，比抛硬币好不了多少。更直接的结果是，9 个被声明为最终版的版本里，只有 2 个在留出任务上真正是最优的。
这带来一个值得警惕的推论：一个分不清改进与噪声的系统，依然会持续修改自己，而它宣布完成的那一版，通常不是它最好的一版。对把「自我改进」当作卖点的产品来说，这个发现比任何单一分数都重要。
换一个执行器就重排：Harness 并不通用
论文里最具操作价值的结果，是「执行器替换」实验。研究者把某个模型搭出的系统，交给 Gemini 3.1 Pro 来执行，排名随即发生明显变化：Qwen 搭的系统在 BrowseComp 上提升 17.6 分、在 MLE-bench 上提升 12.9 分；而 Opus 4.8 在 SWE-Pro 上的成绩从 69.3 掉到 33.0。
这种量级的落差不是基准噪音，而是一个结论：由某个模型调优出来的 Harness，不一定是另一个模型的更好 Harness。Harness 与执行模型之间存在耦合，跨模型迁移的收益并不稳定。这解释了为什么「换更强的模型就能解决问题」在实践中经常落空——如果 Harness 是按旧模型的行为习惯调出来的，换模型可能反而打破原有的平衡。
Auto-RecSys：不换模型，把失败率降下来
Meta 的 Auto-RecSys 从另一头切入。它面对的是一个天然不适合快速试错的场景：推荐模型的单次改动可能需要数天训练与监控，一个研究周期通常三到七天，每次运行消耗数百 GPU 小时。而任务失败的原因往往与想法本身无关——抢占、检查点损坏、数据陈旧、包版本不匹配、硬件不稳定。配置动辄数千行，Agent 会话会在任务中途断开，服务器会在训练中重启。
面对这种长反馈、高复杂度，Meta 的做法是工程化 Harness，而不动模型。论文给出的结果很集中：一套经过设计的 Harness 让自主智能体跑了 31 轮实验，把每次迭代的运营失败从 4.0 降到 0.5，把人工投入时间从数小时乃至数天压缩到分钟级。而变化的那一项是 Harness，不是模型。
支撑这个结果的是三个设计。分布式异步执行让多个实验想法并行跑，每个想法由独立的状态文件跟踪，一个失败不会拖累其他。跨服务器中心化记忆把实验状态、操作手册与历史集中存放，任何服务器上的会话都能在崩溃或重启后接着干。认知与程序分离则把系统一分为二：自然语言写的技能文件负责引导模型的推理，确定性脚本负责状态变更、接口调用与文件操作——让模型决定「做什么」，让脚本保证「确实按预期发生」。论文对此的解释很直白：模型推理灵活但不精确，而状态管理要求精确，一个 JSON 状态文件里错一个字段，就可能毁掉整个实验生命周期。
一个更早的信号：脚手架效应
把这两份工作放回更长的脉络里，会发现它们并非孤立。此前已有研究报告过「脚手架效应」：在模型固定的情况下，不同 Harness 在终端任务上的表现差距可以达到 40 倍；另一组 Harness 工程工作仅通过演进 Harness，就把 Terminal-Bench 通过率从 69.7% 提到 77.0%，且增益能迁移到其他模型；还有团队报告让 Agent 重写自己的 Harness 规则，改进幅度最高到 60%。
反方向的证据同样存在：有结果指出，一个每次调用成本约两美分的便宜模型，在通过 MCP 注入结构化上下文后，能在 SWE-bench Verified 上拿到 78.2%，超过成本高出近四十倍的对手。结构胜过规模——这句话在 Harness 这一层被反复验证。
中立思辨
需要辩证看待。其一，HarnessDev 与 Auto-RecSys 都是作者自测口径，HarnessDev 所属的还是三篇一组的研究计划，另两篇报告了类似结论，但独立复现尚未出现，具体百分比宜作为方向性参考而非定论。其二，53.1% 的泛化信号虽然刺眼，但它衡量的是「模型自评反馈与留出表现是否同向」，这比「自我改进完全无效」要温和——它说明的是信号噪声大，而非改进不可能。其三，Auto-RecSys 的 4.0 到 0.5 是特定流程（推荐模型训练）里的运营失败，不能直接外推到所有 Agent 场景。其四，两个研究都指向同一个工程结论，但也共同回避了一个问题：当 Harness 成为主要变量，如何防止「为基准调优 Harness」变成新的过拟合。其五，执行器替换实验说明 Harness 与模型耦合，这意味着企业一旦围绕某套 Harness 建立了工程积累，迁移成本会比想象中高，锁定风险需要提前评估。其六，死代码比例之高提示另一件事：模型生成的框架里，看起来完整与真正有效是两回事，验收标准应当从「功能是否齐全」转向「哪些组件真的被触发过」。
趋势研判
短期，Harness 会成为独立的评测与采购对象，团队会像评估模型一样评估「同一模型在不同框架下的单位任务成本与完成率」；中期，如果自动演进 Harness 的信号问题得不到改善，行业会更倾向于「人定评估标准、机器做搜索」的分工，而不是放任 Agent 自评自改；长期，模型与 Harness 的耦合关系会催生新的工程规范，包括跨模型迁移的验证流程、死代码检测、以及针对长链路任务的停止条件设计。
对企业来说，这两份工作给出的可执行建议是一致的：在预算允许的范围内，把「换模型」和「改 Harness」当作两条独立的优化路径分别测量。很多情况下，后者更便宜，也更快见效——前提是你先得有一套能分辨改进与噪声的评估方法。