Agent 圈这两年有个共识越来越硬:同一个模型,换一套执行框架,任务表现能差出一大截。模型权重之外的这层基础设施——planning、执行、记忆、验证的胶水代码,社区管它叫 agent harness。可现有的评测几乎都只报告"某个选定 harness 之下"的下游分数,模型自己会不会搭 harness、搭得好不好,长期是个盲区。字节跳动 Seed 团队参与的新基准 HarnessDev 就是冲着这个盲区去的,论文已提交 arXiv。
评测对象换成了"可运行的基建"
HarnessDev 的思路是把评估单元从任务输出整体搬到可运行的基础设施上,分两个阶段考察。Creation 阶段,agent 从一个最小种子和少量样例出发,要求搭出一套完整的执行系统;Evolution 阶段,则让它以自己刚搭好的 harness 为起点,根据下游执行反馈反复修改,目标是把基准成绩继续往上推。每一套构建出来的 harness,都在两个维度上打分:能力(留出基准上的任务成功率)和效率(执行消耗的 token 成本)。Creation 结果覆盖六个创作者模型、四个领域、五个下游基准,共 2207 个唯一下游实例,评估任务对开发过程全程隐藏。
三条泼冷水的发现
第一条,领域分化非常明显。生成的 harness 在代码和搜索研究领域仍明显落后于成熟的人类工程参考实现;但在写作和机器学习实验这两个领域,已经能追平甚至超过所选参考——顺带一提,不同模型生成的 harness 在执行成本上差异巨大。
第二条,自我演化没那么神。Evolution 阶段确实能带来一些性能提升,但提升不稳定,而且只能部分迁移到留出任务上,越接近真实泛化越露馅。
第三条,harness 收益是"模型绑定"的。固定 runtime 模型的对照实验显示,一套 harness 带来的增益强烈依赖于究竟由哪个模型来执行它——换模型,收益就缩水,跨模型迁移性有限。
为什么这篇值得读
最近"模型自建工具链"的叙事很热,各家风向都在讲 agent 自己写 harness、自己进化的故事。HarnessDev 的价值恰恰在于给出了一个可复现的负面答案:在代码这类硬核工程领域,模型自建的执行系统离人类成熟实现还有肉眼可见的差距,而且优化出来的收益既不稳、也不通用。这提醒从业者,harness 工程短期内仍是人的活儿,所谓"自进化 agent"的宣传要打个折扣看。
对研究者来说,它还示范了一种新的评测视角:与其在固定 harness 下刷任务分,不如把 harness 本身变成被测对象——毕竟当模型能力逐渐趋同,基建层的差异反而成了胜负手。
所以,下次看到"我们的 agent 会自己搭自己的运行环境",先问一句:在 held-out 任务上、换个模型跑,还能保持这个提升吗?
参考:arxiv.org/abs/2609.01437