你请两位同样聪明的人修一件东西，一个只有纸笔，另一个有工具箱、检查清单和返工流程，结果往往不同。Agent也是这样：决定表现的不只是底座模型，还有包在模型外面的“工作台”。它负责提供工具、整理上下文、保存状态、执行命令、检查结果，并决定失败后要不要重试。
HarnessDev追问了一步：既然这套工作台如此重要，能不能让大模型自己把它造出来，再根据工作反馈持续改造？这项基准测试——也就是一套统一任务和评分规则——不再只看Agent答对了几道题，而是评估它能否交付一套真正可运行、可反复使用的Agent基础设施。
答案目前是：能造，也能局部改进，但离稳定接管这项工程还有距离。以下结果均来自HarnessDev论文这一项信源，尚无第三方复现；论文中的“达到或超过”等结论，只针对其选定的参考系统。
从交答案，变成造工作台
我们在8月31日的报道中提到，同一底座模型只要更换上下文管理和执行循环，代码修复成绩就可能大幅变化。HarnessDev把这个观察继续向前推：不再由研究者替模型选好外壳，而是让模型亲自开发它。
这里的Agent harness，可以理解为Agent外部的执行系统。它包含执行循环、工具调用、上下文管理、持续状态、生命周期控制和结果验证。模型权重不变时，改变这些安排，也可能显著改变最终表现。
HarnessDev把开发分成两段。
第一段叫Creation。模型拿到一个很弱、但可以运行的种子系统，以及任务说明和1至3个开发案例。这个种子只处理接口、工具权限和结果记录，没有任务拆解、重试恢复、停止规则、记忆或验证机制；原样运行时，在所有下游基准上都得零分。模型必须把缺失的工作流程补齐。
第二段叫Evolution。模型从自己造出的代码工作台出发，根据后续任务的执行反馈反复修改。它像一名工人，一边使用工作台，一边调整工具摆放、检查流程和返工规则。关键不在于某次修得更好，而在于改动能否积累成稳定、可迁移的能力。
开发结束后，研究者会冻结这套harness，再让执行模型用它处理未参与开发的任务。这样测到的不是临场改答案，而是这套基础设施能否复用。
它真的能自己搭起来吗？
Creation实验覆盖6个creator LLM——即负责开发工作台的模型——、4个领域和5项下游基准，共2,207个独立任务实例。领域包括代码、机器学习实验、短文本写作，以及搜索与研究。隐藏评测任务与开发过程隔离，模型不能依据最终考题修改系统。
结果呈现出很强的领域差异。模型生成的harness在代码、搜索与研究任务上，仍明显落后于成熟的人工工程参考系统。代码任务要求它持续检查代码库、修改文件并验证结果；搜索与研究则要求长时间寻找和整理信息。这些工作都依赖较长的执行链，也更考验恢复和验证机制。
但在写作和机器学习实验任务上，生成的harness达到或超过了论文选定的参考系统。这里不能扩写成“已经超过人工系统”或“达到行业最佳”：比较对象只是论文选用的特定参考实现。
一个值得注意的结果是，写得更多不等于做得更好。18个代码harness一共净增17,111行代码，但改动规模不能预测成绩。Gemini 3.1 Pro生成的版本增加代码最少，共1,006行，却拿到最高的Terminal-Bench成绩68.8。论文据此观察到，聚焦关键环节并频繁验证，可能比堆叠功能更重要。
执行成本也很不均匀。不同harness消耗的执行模型token——模型处理和生成文本时使用的计量单位——差异很大；在MLE-bench上，token用量相差约19倍，却没有出现“花得越多，效果越好”的稳定关系。换句话说，一套工作台既要看能不能完成任务，也要看它为此消耗多少计算。
最薄弱的地方，是记忆和自检
论文对生成代码的检查解释了部分差距。18个代码harness都实现了明确的执行循环，但只有13个完整实现工具体系，13个完整实现生命周期控制，15个完整实现验证。
状态与记忆的问题更突出。11个harness定义了State类，但只有一个提供保存状态的接口，也只有一个实现定期检查点。在26,679条任务轨迹中，研究者没有观察到一次检查点事件。有些功能看起来已经写进代码，实际运行时却从未触发。
验证也常停留在“程序能不能跑”，而不是“结果到底对不对”。2,325次数据任务执行中，有441次产生了退化提交，所有harness都没发现。单纯增加自测次数与下游成绩的相关性只有0.13至0.26，且不显著；真正更有价值的环节，是读懂失败、做针对性修改，再重新验证。
这说明模型已经会搭架子，却还不善于确认架子上的部件是否真的工作。生成一段“记忆模块”代码，与在长任务里可靠地保存、恢复和使用记忆，是两件不同的事。
会改进，但容易改偏
Evolution阶段目前只研究代码harness。模型会看到固定反馈任务的结果，再提交新版本；每个正式版本必须同时完成100个SWE-Pro任务和89个Terminal-Bench任务。研究者另外准备了630个从未向开发模型展示的SWE-Pro任务，用来检查改进能否推广。
结果并非稳定向上。9条演化路线共产生73个正式版本和64次相邻版本切换。其中8次让两个反馈基准同时退步，16次在一个基准上退步，3次出现此消彼长；只有两次有超出重复运行噪声范围的明确正向证据。新增的169个函数或类中，也有56个处在死代码路径上或根本没有调用者。
模型确实能抓住具体故障。论文举例说，Opus发现100次运行中有99次自报成功，实际却只有48次通过，于是把问题追到过早结束，并加入完成检查。但整体来看，反馈集上的提升到了隐藏任务上会缩小，也更不稳定。64次可比较的版本切换中，反馈成绩与隐藏成绩只有34次同向；9个最终声明版本里，仅2个恰好也是隐藏任务上的最佳版本。
问题很像反复修改一份练习卷答案：你可能越来越适应眼前这批题，却不一定真正学会了新方法。
同一工作台，也会挑使用者
HarnessDev还把执行模型固定下来，以区分“工作台设计得好”与“设计者恰好最会使用自己的工作台”。结果显示，harness的收益强烈依赖实际运行它的模型。
例如，Opus生成的代码harness在由Opus自己执行时，SWE-Pro得分为69.3；换成Gemini后降到33.0。论文追踪到的一个原因，是系统把120步上限写死，规则适配原执行模型，却不适配新的使用者。相反，一些Qwen和DeepSeek生成的harness换成Gemini后反而提高，说明它们原来的执行模型可能才是瓶颈。
因此，harness可以在技术上被另一个模型运行，不代表能力能够完整迁移。提示方式、工具协议、预算和停止规则，都可能暗中绑定某个模型。所谓“通用Agent外壳”，目前更像目标，而不是已经得到证明的产品属性。
为什么值得现在看
HarnessDev最重要的变化，不是又给模型加了一套考试，而是改变了考试对象。过去我们常把Agent表现归因于模型本身；这项工作提醒我们，模型外部的工程安排也是能力的一部分，而且可能决定能力能否真正落地。
更进一步说，模型开始从“使用工具的人”变成“改造工具系统的人”。如果这条路线成熟，Agent开发可能不再只是工程师手工编排流程，模型也能参与发现瓶颈、修改执行逻辑和维护系统。但当前证据同样清楚：模型会做有用的局部修补，却难以稳定判断哪次修改真正有效，也容易针对眼前反馈或特定执行模型过度适配。
局限与未知
- 所有效果都来自论文作者团队的一项研究，没有外部复现；部分表述缺少逐项分数、误差区间或显著性检验。
- Evolution目前集中在代码任务。它能否在写作、研究和机器学习实验中稳定演化，材料没有给出答案。
- 反馈成绩存在运行噪声，最终版本也常不是隐藏任务上的最佳版本。如何可靠选出真正进步的harness，仍是开放问题。