你有没有想过这样一个问题：一个厨艺再好的厨师，如果厨房里连刀都是钝的，锅都是漏的，他能做出什么好菜?
大语言模型现在的处境，跟这个厨师有点像。
模型本身的能力已经很强了，但它真正干活的时候，靠的从来不只是它自己脑子里的东西。它需要一整套外部系统来帮它执行任务，读文件、调工具、管理上下文、失败了怎么重试、结果怎么验证。这套系统有个专门的名字，叫智能体脚手架（agent harness，指模型之外那套负责执行循环、工具调用、上下文管理、失败恢复和结果验证的软件基础设施，是模型输出转化为实际行动的中间层）。
这套东西的影响力有多大？论文里给了一个扎实的例子：同样是GPT-5这个模型，权重完全没变，放进Terminus 2这个脚手架里跑Terminal-Bench 2.1，只能解决35.2%的任务；换成Codex CLI这套脚手架，成功率直接跳到49.6%。同一个大脑，换了一副身体，表现差了14.4个百分点。
这就带来一个很自然的追问：既然脚手架这么重要，那能不能让AI自己来造这套脚手架，甚至自己不断改进它？
来自字节跳动Seed团队、新加坡科技设计大学等机构的研究者们，就干了这么一件事。他们做了一个叫HarnessDev的评测基准，专门用来考察大模型有没有能力从零开始造出一套能跑的智能体系统，并且在之后持续把它改得更好。
这事听起来简单，做起来其实很拧巴。
以往几乎所有的智能体评测，比如SWE-bench、GAIA、WebArena这些耳熟能详的名字，都是先固定好一套脚手架，然后看模型在这套固定环境里能考多少分。脚手架在这些评测里更像是考场的桌椅板凳，是背景设定，不是被考察的对象。
HarnessDev反过来了，它把桌椅板凳本身变成了考题。
这个转变背后其实有个更深的行业背景。论文提到了一个很有意思的职业角色，叫前向部署工程师（forward-deployed engineer，简称FDE，一种被派驻在客户现场、把通用模型改造成能真正适配客户具体业务场景的工程师角色，这个头衔最早由Palantir公司推广，后来被多家前沿模型公司采用）。
这些工程师干的活是什么？不是简单地调用一下模型接口交差了事，而是要面对一堆模糊不清的业务需求，把它们翻译成具体的技术目标；要在没有现成测试标准的情况下，自己造出判断成功与否的标准；还要把工具、上下文、状态管理这些执行系统从无到有搭建起来，并且长期维护下去，客户需求变了就跟着改。
这三件事，恰好是现在大部分智能体评测都默认已经完成、直接跳过的部分。HarnessDev选择啃的，正是这块最难啃、也最贴近真实部署场景的骨头。
从一颗"弱种子"开始生长
要评测一个模型能不能造脚手架，第一个难题是：给它什么样的起点？
如果给一个空仓库，那模型花的力气大部分会耗在搭命令行、处理文件格式这些和"脚手架设计能力"本身没什么关系的杂事上，测出来的结果没有代表性。可如果直接给一套已经很成熟的脚手架，那模型只需要小修小补，考察的就变成了修补能力而不是设计能力，而且相当于提前把答案的骨架泄露给了模型。
研究者的解决方案是设计一个精心控制的"弱种子"（weak seed，指一套只有基础的输入输出接口、日志记录能力，但完全没有任务解决逻辑的最小化可运行系统，是Creation阶段所有创造者模型的统一起点）。
这颗种子能读懂任务配置、调用一些被动的底层工具、写出规定格式的结果文件，但它没有执行循环，没有任务拆解逻辑，没有工具使用策略，没有记忆，没有失败重试，什么都没有。如果不做任何修改直接跑，它在所有下游任务上的得分都是零。
这个设计其实挺巧妙的。
打个比方，这就像给一个想开餐厅的人提供一个空空如也但水电煤气俱全的商铺，而不是给他一堆现成的菜谱，也不是让他自己去拉电线接水管。商铺给你的是干活的最低条件，剩下菜怎么炒、店怎么开，全靠你自己。如果给的是毛坯房（连电都没通），大部分精力就耗在装修上了；如果直接给一家装修好、菜谱齐全的餐厅，那你顶多算个接班的，测不出你有没有开店的本事。
在这颗种子的基础上，研究团队设计了两个阶段的考察，对应论文里的两个核心研究问题。
第一阶段叫创造（Creation），考察模型能不能从这颗弱种子出发，只靠一份任务说明和一到三个开发样例，造出一套完整可用的脚手架。第二阶段叫演化（Evolution），考察模型能不能拿着自己造出来的脚手架，通过不断在真实任务上跑、看反馈、改代码，把它变得更好。
论文里给这套脚手架该长什么样，提出了一个很清晰的理论框架，用六个字母表示：E、T、C、S、L、V。
E代表执行循环（execution，负责规划任务怎么一步步进行、什么时候该停下来）；T代表工具（tools，工具接口怎么设计、什么时候能用、输入输出怎么约束）；C代表上下文管理（context，任务信息、历史记录怎么组织进模型能看到的窗口里）；S代表状态（state，当前的目标、已经尝试过的方案、失败记录怎么保存）；L代表生命周期（lifecycle，失败了怎么处理、超时了怎么办、怎么恢复、怎么收尾）；V代表验证（verification，用什么方式判断任务是不是真的做完了，是不是做对了）。
这六个模块不需要真的写成六个文件，但一套合格的脚手架，理论上应该把这六件事都落到实处，而不是只写在文档里说说而已。
六个模型，一场造脚手架的比赛
研究团队找来了六个当下比较有代表性的大模型来当"造脚手架的人"：Opus 4.8、GPT-5.5、Gemini 3.1 Pro、DeepSeek V4 Pro、Qwen 3.7 Max，还有字节自家的Seed 2.0 Pro。
它们要在四个领域里各自造出一套脚手架：代码（用SWE-bench Pro和Terminal-Bench 2.1两个基准考察，一共820个任务）、数据分析（用MLE-bench，75个机器学习任务）、写作（用EQ-Bench3，46个场景）、以及研究检索（用BrowseComp，1266道需要长时间信息搜索才能回答的题）。加起来一共2207个下游任务实例，覆盖面相当广。
评测这件事听起来简单，其实暗藏不少坑。一套脚手架完全可能针对造它的那个模型做了特别的适配，换个模型来跑就水土不服；也可能在开发时看到的样例上表现很好，但那其实是背答案，遇到没见过的新任务立刻现原形；还可能在某个能力上进步了，却在另一个能力上悄悄退步，而这种退步在没有专门检查的情况下根本不会被发现。
于是研究团队设计了两套评测视角。
一套叫Self-Eval（自评，即让造脚手架的那个模型自己去执行下游任务，用来考察模型和它自己设计的脚手架之间的适配程度），另一套叫Unified-Eval（统一评测，把所有不同模型造出来的脚手架，都固定用同一个执行模型来跑，这样就能剥离出脚手架本身的质量，不受执行模型能力差异的干扰）。
这两套视角一对比，结果特别有意思。
在自评模式下，Opus 4.8造出来的脚手架综合得分最高，达到67.8分，但依然比人类工程师精心打磨的成熟系统低了不少，人类参考系统能拿到86.2分。具体拆开看，写作领域上模型造的脚手架已经很接近人类水准了（Opus在EQ-Bench3上拿84.6分，人类参考是83.7分，甚至反超了）；机器学习实验领域更是直接反超，Opus和Gemini的奖牌率分别是32.9和32.4，都超过了人类参考的24.0。
但代码和搜索研究这两个领域，差距就拉得很大了。SWE-bench Pro上，Opus的69.3分对上人类的80.0分，差了将近11分；BrowseComp（需要长时间检索信息才能回答的高难度搜索基准）上，表现最好的Opus也只拿到52.4分，人类参考却高达92.2分，几乎是打对折。
为什么代码和搜索这两块特别难？
论文给出的解释挺直觉的：这两类任务都需要长时间、多回合、高度依赖上下文积累的操作。代码任务要在多轮对话里协调仓库检查、代码编辑、验证测试；搜索任务要不断地查、去重、判断信息是否够用、决定什么时候该停。这些恰恰是脚手架里最难设计好的部分，状态管理和生命周期控制，稍有差池就会一步错步步错。
论文里有一个特别具体的例子说明这种脆弱性。有一个由Opus造出来的代码脚手架，在自评（也就是用Opus自己来跑）时表现很好，可一旦换成Gemini来执行，成绩几乎崩盘。原因是这套脚手架里硬编码了一个"最多执行120步"的限制，这个数字是针对Opus的行为模式调校出来的，换了另一个模型，节奏完全不一样，这个写死的限制就成了枷锁。
这就好比给一位习惯小步快跑的短跑运动员定制了一双钉鞋，钉子的位置、鞋底的弹性都是照着他的步频调的。你把这双鞋给一个习惯大步流星走路的人穿，他每一步的着力点都对不上，跑起来反而更累更慢。如果脚手架的设计者压根没考虑过换人穿这件事，那这双"鞋"看似精致，实际上只服务于一个人。
更有意思的是，花的钱和跑出来的成绩完全不成正比。
论文统计了执行时消耗的token数量（可以粗略理解为模型思考和输出所花费的计算资源，越多意味着运行成本越高），发现在MLE-bench上，GPT-5.5用2930万token拿到19.1的奖牌率，而DeepSeek V4用了2.084亿token，是前者的七倍多，结果奖牌率也才19.6，几乎没有优势。这说明脚手架设计得好不好，跟砸多少计算资源没有必然关系，关键还是那套控制逻辑本身设计得是否精巧。
十套预算，一场自我修炼的实验
如果说创造阶段测的是模型有没有从零搭系统的本事，那第二阶段的演化（Evolution）测的就更狠了：模型能不能拿着自己造出来的东西，靠真实反馈不断改进它。
这个设定特别贴近真实工程实践。没有哪个软件系统是一次成型、永久不变的，真正的工程师是要不断根据线上表现去调整代码的。问题是，AI能不能扮演这个持续迭代的角色？
实验设计得很严格。每个模型从自己在创造阶段造出的代码脚手架H0出发，能看到两组反馈信息：一个是100道题的SWE-Pro反馈集，一个是全部89道Terminal-Bench任务。整个演化过程里，模型总共只有十次提交完整评测配对的机会（论文里称为pair，每次要同时在两个基准上跑一整轮完整评测才算数），另外还有限量的"探测"机会，只能在一个固定的5题小样本上快速试错，探测结果不计入正式成绩。
这个预算限制很关键。它模拟的是真实世界里资源永远有限这个残酷事实：你不可能无限次地在生产环境上试错，每一次全面测试都是有代价的。这就像医院给医生做临床试验设定了病人数量上限，不是因为多测几次不好，而是因为每一次真实测试都有真实成本，逼着你必须在有限次数里做出足够聪明的判断，而不是靠海量试错去碰运气。
评测结果分成两条线看：一条是模型能实时看到反馈的"可见反馈集"表现，另一条是训练全程完全对模型隐藏、事后才拿出来打分的"留出集"（held-out set，指从始至终不向模型展示的测试数据，专门用来检验模型改进的成果是不是真的泛化了，还是只是在死记硬背见过的题）表现。
结果相当耐人寻味。五个用自己模型来跑的演化实验（也就是造脚手架的和执行脚手架的是同一个模型），全都在可见反馈集上取得了进步，最高的Qwen 3.7 Max涨了13.9个百分点。但是转到留出集上一看，涨幅普遍大幅缩水。表现最好的Opus 4.8留出集提升4.44分，是所有模型里最扎实的；而涨幅最猛的Qwen在留出集上只剩1.43分的提升，缩水了超过九成。
这说明什么？说明模型确实在学，但学到的很多东西可能是针对那100道可见题目的小聪明，而不是真正普适的能力提升。
更麻烦的问题出现在换执行模型这个实验里。研究团队专门做了一组对照，让所有创造脚手架的模型统一用固定的Gemini来执行任务（而不是用自己）。结果四条演化路径里，只有Opus这一条在留出集上依然是正向提升的，另外三条全都变成了倒退。
这个结果直接戳破了一个可能的幻想：改脚手架不是一个和模型无关的、纯客观的"优化代码"过程，而是深深绑定在执行它的那个模型身上。你精心调优出来的一套改进方案，很可能只是恰好适配了那一个特定模型的行为模式，换个人来用，可能不进反退。
论文还统计了64次官方版本切换里的具体情况：8次两个基准都退步，16次单个基准退步，3次一个基准好一个基准坏，7次几乎没变化，27次的提升幅度落在重复运行本身的噪声范围之内（也就是说这个提升到底是不是真的改进，统计上说不准），只有2次有明确证据表明是超出噪声的真实进步。
这个数据背后藏着一个挺扎心的事实：同一份代码，同样的评测集，跑两次结果都能差出将近5个百分点。这不是脚手架不稳定，而是评测本身固有的波动。这就像考试成绩本来就会有几分的正常起伏，你今天多考2分不代表你真的变聪明了，可能只是那天状态好、蒙对了几道题。如果不设置留出集这道防线，光看训练时的提分曲线，很容易把运气误判成实力。
模型自己选出来的"最终版本"，也常常不是留出集上表现最好的那个版本。九条演化路径里，只有2条的最终选择恰好是留出集最优版本，也就是说，靠可见反馈来做最终决策，命中真正最优解的概率并不高，这暴露了一个更深层的困境：反馈信号本身有噪声，模型如果反复用这个有噪声的信号去挑最好的版本，很容易挑中一个恰好走运、但并不代表真实实力的候选者，这在统计学上是一个经典的"过拟合搜索"陷阱。
论文里给了一个非常生动的正面案例，来自Opus的代码演化过程。它发现了一个诡异的现象：99道题里有99道自我报告"成功"，但实际通过验证的只有48道。这说明脚手架里的完成判断逻辑本身出了问题，模型过早地宣称任务完成，而不是真正做到位。Opus把这个问题定位到了具体的完成判断机制，加了一道验证关卡，才在下一版本里把留出集分数从63.02拉到67.46。
这是整套演化案例里少数几个"诊断准确、改动精准、效果扎实"的例子。它之所以珍贵，恰恰因为它稀少：多数版本切换要么改了没用，要么改了反而更糟，要么根本没触发过任何真实的执行路径（论文提到169个新增函数或类里有25个从来没有被任何代码调用过，属于写了但根本不起作用的死代码）。
写在后面
读完这篇论文，我印象最深的不是那些成绩差距的数字，而是那个"换执行模型就翻车"的实验结果。
这个发现有点动摇了一个我原本没意识到自己在默认相信的假设：我以为好的工程改进应该是"客观"的，就像修好一个bug之后，不管谁来运行这段代码，它都应该更稳定。但HarnessDev的实验说明，至少在AI给自己造工具这件事上，改进本身可能是主观的、和特定使用者深度绑定的。你造出来的"更好"，很可能只是"对我来说更好"。
这让我想起一个不太搭界但内核相通的场景：一个人给自己配了一副度数极其精准的眼镜，戴上之后视力表现一流，但这副眼镜的度数只对他那双眼睛管用，别人戴上去反而头晕眼花。这副眼镜本身没有做错任何事，问题出在它从设计之初就没打算通用。
论文里另一个让我停下来想很久的细节，是那个"441个数据分析任务产生了退化提交，但没有一个脚手架检测出来"的统计。这说明现在这些模型造出来的验证机制，大多还停留在"格式对不对"的语法层面，而不是"内容真的有意义吗"的语义层面。这个差距挺本质的，格式检查是可以枚举穷尽的规则，而判断内容质量需要真正理解任务本身，这恰恰是最难教会脚手架去做的事。
这篇论文没有给出一个让人兴奋的"AI已经能自己造工具了"的结论，它给出的其实是一个更诚实、也更值得深挖的中间状态：AI能造，能改，但造出来的东西和它自己深度绑定，改进的效果也常常在换个场景后就打折扣。
如果有一天，一个模型造出来的脚手架，换谁来用都一样好使，那会是什么样的分水岭时刻？
Q&A
Q1：HarnessDev是什么？
A：HarnessDev是一个评测大语言模型能不能自己创造并持续改进智能体执行系统（也就是agent harness）的基准测试，它把评测对象从"任务答案"转变成了"可运行的基础设施本身"。
Q2：为什么脚手架（harness）对AI智能体这么重要？
A：因为同一个模型换不同的执行脚手架，表现差异极大。论文举例说GPT-5在Terminus 2脚手架里只能解决35.2%的Terminal-Bench任务，换成Codex CLI脚手架能提升到49.6%，差距达14.4个百分点。
Q3：AI自己造的脚手架效果怎么样，能超过人类工程师吗？
A：分领域来看，AI造的脚手架在写作和机器学习实验任务上已经能匹配甚至超过人类精心打造的系统，但在代码开发和信息搜索这两个需要长时间多轮操作的任务上，差距依然很明显。
红腾网提示：文章来自网络，不代表本站观点。
