arXiv 2609.40303 · How Much of a Harness Does a Strong Agent Need for Autonomous ML Engineering? · Kirill Brilliantov、Alejandro Hernández-Cano 等EPFL / Apple· 2026-09-30一句话版本论文用严格受控的消融实验证明在自主机器学习工程MLE任务上给模型一个 shell 和文件系统比什么都重要而架在它之上的多层机械搜索树/多智能体编排/记忆层级几乎不再产生增益——一个「裸」的编码 agent 会话Malena 基线打平或胜过四个开源 SOTA harness。背景Harness 军备竞赛的前提已经变了MLE 智能体系统这几年越来越重外层 harness 负责提示、执行、打分、探索内层加上搜索树、程序种群、记忆层级、专业智能体团队。这套架构建立在两个前提上单次模型补全不能自己跑代码——所以 harness 得替它做MLE 是长视野问题需要专门的记忆与上下文管理论文指出这两个前提都过时了现代模型经后训练已经能在编码 agent 环境里自主读文件、写代码、执行、调试——工作单元本身从「一次补全」变成了「一个自包含的会话」。百万 token 上下文也便宜了。那问题来了harness 里还有哪些层在挣自己的饭钱实验模型、预算、任务全固定的消融阶梯现有文献没法回答这个问题——harness 性能涨的时候底座也在涨增益没法归因跨论文对比则是不同模型不同硬件种子数普遍 ≤3头条差距比跑次方差还小。这篇的做法是把所有变量钉死同一 backbone、同一硬件、同一 24h 时间预算在同一个代码库里重实现一整条干预阶梯从纯聊天迭代 → 编码 agent 环境 → 搜索结构 → 多智能体编排MLE-bench NatureBench 双基准多个前沿底座GLM 5.2、Kimi K3、DeepSeek V4 Flash 等核心发现唯一大增益是「给个终端」结论一句话几乎所有增益来自 runtime 和 LLM 底座来自其上构建物的几乎为零。干预效果聊天界面 → 编码 agent 环境shell文件系统单项最大增益之上的搜索树/种群/编排/多智能体统计上不再显著Malena 基线单个 well-prompted 编码 agent 会话最小工具集在与四个开源 SOTA harness 的对比中每个前沿底座上都不落下风GLM 5.2 上 Malena 拿 62.5% 奖牌率对比最强外部 harness 的 47.1%。为什么裸 agent 能赢trace 分析显示有能力的编码 agent自己在做那些 harness 硬编码的搜索——平衡罕见技巧与性能导向的精炼复用自己已产出的中间产物。harness 想从外部供应的东西强模型已经在内部自己做了。佐证隔壁软件工程的同样结论论文引用的旁证链很有说服力35 个 SWE harness 发布版本在 SWE-bench 上无统计显著改进单个 well-prompted agent 打平多智能体工作流多智能体失败源自协调而非能力编排本身引入可观开销。MLE 只是迟到地复现了软件工程的规律——结论呼应 Sutton 的 bitter lesson能力往前走手工脚手架的收益就往零走。边界论文诚实的部分弱底座仍然受益于手工工作流先验——差距随 agentic 能力增长才闭合论文测的是 24h 预算内可完成的 MLE 竞赛任务超长视野数周级场景未覆盖Malena 也不是零机械——最小工具集好的提示词本身就是一种设计为什么这篇值得读方法论的干净backbone/预算/硬件三固定的消融在「换模型刷榜」盛行的领域是稀缺品「coding agent 后训练替代了 harness 手工设计的脚手架」这个论断对选型有直接指导意义对「多智能体一定更强」的行业叙事提供了强反例与 09-29 我们解读的欺骗者占比篇互为印证——多智能体的协调成本真实存在与 BuddyMe 的经验印证我们做 BuddyMe 时的一个取舍与这篇结论同向把力气花在 runtime工作台/文件落盘/断点续跑而不是编排复杂度上。任务链条里真正值钱的是「模型能看见自己改过什么、能接着上一步继续」——这正是「runtime 优先」的思路。多智能体协作留给真正需要并行的任务单链任务用强模型直跑可回放的工作台往往更稳。每天免费 4500 万 token可以自己跑对照试试。BuddyMe 每日免费 4500 万 Token。