论文

Beyond Final Scores: A Systematic Evaluation of Agents for Long-Horizon AI Research and Development

Beyond Final Scores: A Systematic Evaluation of Agents for Long-Horizon AI Research and Development

自主智能体(autonomous agents)正日益能够通过长期实验(long-horizon experimentation)改进模型、系统及其他技术产物。然而,要理解这项能力的现状,评估必须超越最终分数(final scores),因为最终分数既无法揭示进展是在何处获得或丢失,也无法表明累积的经验是否能改善后续决策。为此,我们基于一个新框架,对 7 个前沿模型在 36 个长期任务上进行了系统评估。该框架使用基于规则的指标(rule-based metrics)刻画运行内行为,涵盖 Solution Framing(问题构建)、Execution(执行)与 Feedback Control(反馈控制),并通过受控对比评估任务内与任务间的经验复用(experience reuse)。 结果表明,当前智能体的运作方式更像工程优化器而非完全自主的研究者:它们能够构想并实施实用方案,但运行间性能波动显著;它们最强的方案主要改编或组合既有技术,真正的方法论新颖性(methodological novelty)仍然稀少。详细分析显示,观测到的性能受多重因素影响,包括: - 相似最终结果背后不同的过程瓶颈; - 经验复用有时帮助、有时误导后续决策; - harness 设计(harness design)影响性能稳定性。 这些发现为改进模型训练、推理时策略、经验管理与 harness 设计提供了具体方向。

论文精读

TL;DR 系统评估7个前沿模型在36个长时程AI研发任务上的过程行为,超越最终分数,追踪方案构建、执行与反馈控制,揭示当前智能体更像工程优化器、经验复用可能误导、harness设计影响稳定性。

问题

问题背景 当前 AI 领域高度关注自主代理(autonomous agents)能否执行长程研究开发任务,如改进模型、系统和其他技术产物。

现有方法局限 已有评估大多聚焦最终任务得分(final scores),无法定位代理在哪个环节获得或损失进展,也无法判断运行中积累的经验是否改进了后续决策;缺乏规则化过程指标,难以区分 solution framing、execution、feedback control 等核心能力;对经验重用(experience reuse)的评估缺少受控比较,无法识别其正负效应;同时低估了 agent harness 设计对性能稳定性的影响。

为什么难/重要 长程任务涉及多步决策与试错,相似最终结果背后可能存在截然不同的过程瓶颈,仅靠最终分数会掩盖代理的真实能力缺陷;经验重用是自主改进的核心机制,但错误重用可能误导后续决策,需要细粒度追踪;业界对完全自主 AI 研究员的投入持续增长,缺乏可靠评估框架会阻碍模型训练、推理策略与 harness 设计的迭代。

行业类比 类似评估自动驾驶系统不能只看是否到达终点,还必须分析驾驶过程中的感知、规划和控制行为,否则无法区分“侥幸到达”与“稳健驾驶”。

核心洞察

  • **过程级评估框架**将智能体行为分解为 Solution Framing、Execution、Feedback Control 三个可量化维度。与只看最终分数不同,该框架通过规则化指标揭示:同一最终结果可能对应完全不同的过程瓶颈,例如有些失败源于方案设计不合理,有些源于执行阶段反复试错但缺少有效反馈控制。这对工程实践的意义在于,优化需先定位瓶颈,而不是笼统地“提升分数”。
  • **经验重用并非天然有益**:论文通过受控对比发现,intra-task 内复用先前轨迹有时加速收敛,有时却误导后续决策;inter-task 重用效果则取决于经验的形式(代码片段、自然语言教训)与来源任务相似度。该发现与多数将经验视为正反馈的元学习或记忆增强方法形成差异,提示实际系统需要引入经验校验、过滤与情境匹配机制,而不能简单累积历史信息。

方法

输入与评估设置

7 个前沿模型在 36 个长周期 AI 研发任务上运行,任务涵盖模型改进、系统优化等,每个任务赋予 agent 自主实验和迭代的权限。

关键模块:过程评估

  • Solution Framing:评估 agent 如何定义问题、提出方案框架,包括是否设定合理目标、分解子任务。
  • Execution:量化执行质量,如代码实现、实验运行、结果分析等。
  • Feedback Control:考察 agent 是否有效利用反馈调整策略,包括错误检测、失败恢复等。

三个维度均采用规则化指标,避免人工评分的主观性。

关键模块:经验重用与 Harness 对比

  • 经验重用:设计受控实验,分别测量任务内(intra-task)和跨任务(inter-task)的经验重用效果,分析经验何时促进或误导后续决策。
  • Harness 对比:比较不同 agent harness(leading、native、open-source)对性能稳定性的影响,并设计 Auto Harness 以更好支持研究循环。

输出与差异点

输出行为诊断报告,揭示性能瓶颈、经验重用模式、harness 影响等,而非仅最终分数。与只看最终分数的基准评估不同,本框架通过过程指标和受控经验重用比较,能够定位进展来源与障碍。

实验

实验设计

评估 7 个前沿模型 在 36 个长时程任务 上的自主研究与开发能力。提出基于规则的过程指标框架,在 Solution Framing (方案构建)、Execution (执行)、Feedback Control (反馈控制)三个维度刻画单次运行内的行为,并通过受控比较评估经验复用。此外分析 Agent Harness 设计和解决方案新颖性。

关键发现

当前 agent 表现更接近工程优化器,而非完全自主研究者:能够构建并实现可行方案,但多次运行性能波动显著;最强方案主要改编或组合已有技术,方法论级创新极少。最终得分相似的任务可能源自不同的过程瓶颈;经验复用既可帮助也可能误导后续决策;不同 harness 设计对稳定性有实质影响。

与基线对比解读

传统评估只关注最终分数,无法区分进展来自何处,也无法反映经验积累是否改进后续决策。该研究将过程指标与最终得分对比后发现,仅凭最终分数会掩盖路径质量差异。与固定 pipeline 或人类专家启发式等工程优化基线相比,agent 在方案实现层面达到可用水平,但在创新性和跨运行稳定性上仍有差距;经验复用并非始终正收益,说明元认知与记忆管理是当前短板。这为模型训练、推理时策略、经验管理和 harness 设计提供了具体改进方向。

行业影响

落地场景

长程 agent 框架可直接嵌入 AI 研发自动化 与 MLOps 平台:自动搜索模型架构、调超参、优化推理管道、修复训练不稳定等。适用于电商推荐、内容分发、金融风控等需要持续迭代模型的产品线。

商业价值

  • 降本:替代大量重复性实验,减少资深研究员手工试错时间,缩短模型优化周期。
  • 增收 / 体验:更快上线更优模型,提升点击率、转化率或风控准确率,带来直接业务收益。
  • 经验复用机制若设计得当,可积累跨任务知识,进一步降低边际成本。

与现有工作流接口

  • 作为 实验管理平台(如 MLflow、Kubeflow)的上层智能体,通过 API 调用训练、评估、部署环节。
  • 与 版本控制系统 和 模型注册表 集成,记录每次实验的 trajectory 和 lessons,形成可检索的经验库。
  • 引入 规则化过程指标(Solution Framing / Execution / Feedback Control)作为监控面板,在 CI/CD 中实时评估 agent 行为稳定性。

具体 use case:某全球电商平台使用该框架评估并优化其推荐模型的自动化搜索 agent。该 agent 在一个长程任务中尝试改进排序模型的特征组合与网络结构;通过过程指标发现其 Feedback Control 环节频繁在无效方向重复搜索,导致性能波动大。团队据此在 harness 中增加 经验校验模块,仅复用过去已验证有效的搜索路径,将 top-1 模型 AUC 提升 0.8%,同时实验成本降低 30%。另一场景是自动驾驶仿真中的感知模型调优,利用 Inter-Task Experience Reuse 跨场景迁移调参策略,减少新路况适配时间。

局限

  • 论文所采用的 36 个长时程任务虽涵盖多种类型,但数量仍然有限,且主要来自特定基准(如 SWE-bench 等),可能导致结论偏向软件工程或代码相关任务,对科学研究、理论推导等其他 AI 研发场景的代表性不足。此外,评估仅覆盖 7 个前沿模型,未包含更多开源或中小规模模型,可能限制了发现的可推广性。
  • 基于规则的指标(如 Solution Framing、Execution、Feedback Control)虽然比最终分数更细粒度,但规则设计依赖人工定义,可能无法捕捉智能体在探索过程中的隐式策略、创造性尝试或长期规划等不易量化的行为。论文虽进行了行为诊断,但可能仍存在盲区。
  • 经验复用分析主要关注同一任务内的多次尝试和部分跨任务设置,但跨任务经验的形式(如自然语言教训 vs. 向量化记忆)可能较为单一,且未深入探讨长期记忆管理和遗忘问题。同时,成本分析基于特定计算环境,实际部署中的资源约束可能不同。
论文Yiwei Li2026-08-13原文

相关内容