1
00:00:00,320 --> 00:00:04,300
想象两个使用同一语言模型的智能体。一个会检查工作，

2
00:00:04,500 --> 00:00:08,960
从错误中恢复，并保留有用的上下文；另一个却过早停止。

3
00:00:09,660 --> 00:00:14,740
外围软件能够改变模型完成任务的能力，这套软件就是智能体的执行框架。

4
00:00:15,480 --> 00:00:21,360
HarnessDev 研究语言模型能否构建这些基础设施，并进一步改进自己创建的可运行系统。

5
00:00:22,040 --> 00:00:27,240
提交对象是跨任务复用的持久代码，而不是对某个问题的一次回答。

6
00:00:27,840 --> 00:00:33,720
这改变了评估单位：设计和实现执行系统本身，成为被测试的能力。

7
00:00:34,540 --> 00:00:39,840
我们将跟着一个完成检查的例子，再区分开发反馈与之后的留出测试。

8
00:00:40,380 --> 00:00:47,240
创建阶段从一个刻意弱化的初始框架开始，它能够读取配置、提供工具，并写出所需日志。

9
00:00:47,720 --> 00:00:55,560
它没有智能体循环、任务分解、验证、恢复逻辑或停止规则；不修改时，它得分为零。

10
00:00:56,240 --> 00:01:01,680
创建模型获得任务族说明、约束，以及一到三个开发案例。

11
00:01:02,200 --> 00:01:06,740
它必须把现有基础组件连接成一个真正尝试执行下游任务的系统。

12
00:01:07,320 --> 00:01:11,620
在开发期间，隐藏评估任务和人工实现都不可见。

13
00:01:12,399 --> 00:01:18,500
随后，完成的框架会在评估前冻结；基准衡量新增执行逻辑带来的能力。

14
00:01:19,167 --> 00:01:25,867
创建模型编写框架；执行模型则在冻结后的框架内部运行，处理下游任务。

15
00:01:26,627 --> 00:01:31,767
区分这两个角色，让论文能够检查某个设计是否依赖最初的运行时模型。

16
00:01:32,647 --> 00:01:36,887
创建评估覆盖六个创建模型、四个领域和五个基准，

17
00:01:37,087 --> 00:01:40,047
共计 2,207 个不同实例。

18
00:01:40,947 --> 00:01:45,747
生成的框架表现不均衡：写作和机器学习实验

19
00:01:45,807 --> 00:01:49,647
相对于选定参考系统，比代码与搜索表现更强。

20
00:01:50,327 --> 00:01:55,467
这些参考对比属于系统层面的对比，部分参考分数来自外部报告。

21
00:01:56,287 --> 00:02:01,527
更换执行模型也会改变排名，说明兼容性是框架质量的一部分。

22
00:02:02,233 --> 00:02:05,753
一条演化轨迹提供了具体的诊断案例。

23
00:02:06,453 --> 00:02:12,733
Opus 发现，一百次执行中有九十九次报告成功，但只有四十八次通过。

24
00:02:13,373 --> 00:02:18,233
它把差距追溯到过早结束，并在框架中加入完成检查。

25
00:02:18,973 --> 00:02:23,913
可以想象最终回答前的一道关卡：要求的产物是否已生成，

26
00:02:24,273 --> 00:02:26,573
是否有证据证明任务完成？

27
00:02:27,173 --> 00:02:32,353
这个问题属于模型外围的执行逻辑，而不是模型权重的变化。

28
00:02:33,113 --> 00:02:38,793
论文把这道关卡视为一个具有执行路径和案例证据的正面例子。

29
00:02:39,413 --> 00:02:45,413
这个启示很具体：有用的反馈揭示出可由可执行修改解决的故障。

30
00:02:46,073 --> 00:02:51,633
演化从创建模型自己冻结后的代码框架开始，并反复评估修改后的提交版本。

31
00:02:52,293 --> 00:02:57,093
可见反馈使用一百个 SWE-Pro 和八十九个 Terminal-Bench 任务。

32
00:02:57,633 --> 00:03:00,333
正式候选版本必须完成这两部分评估。

33
00:03:01,273 --> 00:03:07,053
开发结束后，每个正式版本都会在六百三十个不重叠的 SWE-Pro 实例上测试。

34
00:03:07,653 --> 00:03:12,093
这些分数不会反馈给创建模型，也不能影响其修改或最终版本选择。

35
00:03:12,833 --> 00:03:17,813
反馈分数对两个基准的百分比分数求平均；留出分数则只使用 SWE-Pro。

36
00:03:18,533 --> 00:03:23,753
因此，开发阶段增益和留出增益回答的是不同问题，图表必须把二者区分开。

37
00:03:24,327 --> 00:03:28,167
来看由固定 Gemini 执行的 GPT-5.5 谱系。

38
00:03:28,667 --> 00:03:32,787
它的反馈配对分数从五十六点六升至五十九点一。

39
00:03:33,487 --> 00:03:40,627
在留出 SWE-Pro 集合上，对应分数却从四十二点二二降至三十一点九零。

40
00:03:41,367 --> 00:03:46,707
选定的修改提升了可见配对分数，却降低了在独立留出集合上的表现。

41
00:03:47,267 --> 00:03:52,087
这是一种执行模型下的一条轨迹，而不是归因于该创建模型的平均效应。

42
00:03:52,827 --> 00:03:56,726
在使用各自运行时模型的最终版本中，五个都提升了留出表现；

43
00:03:57,167 --> 00:04:00,667
但固定 Gemini 时，只有 Opus 提升，其他三个都退步。

44
00:04:01,687 --> 00:04:06,467
因此，执行模型兼容性和泛化表现，都应纳入演化框架的测试。

45
00:04:07,047 --> 00:04:11,687
九条演化谱系一共产生六十四次相邻正式版本切换。

46
00:04:12,207 --> 00:04:17,587
其中三十四次切换的反馈和留出分数朝同一方向变化，约占百分之五十三。

47
00:04:18,167 --> 00:04:23,047
九个声明的最终版本中，只有两个也是各自谱系里留出表现最好的版本。

48
00:04:23,527 --> 00:04:29,367
同一提交版本的重复执行会有波动，许多报告的增益仍处于测得的噪声范围内。

49
00:04:29,907 --> 00:04:35,347
因此，选择最高可见分数，并不能可靠地替代对未见任务的检查。

50
00:04:35,927 --> 00:04:41,287
基准把版本选择视为开发的一部分，而不是假设每次编辑都代表改进。

51
00:04:41,740 --> 00:04:47,800
HarnessDev 把模型外围的执行系统变成一个可检查、可跨任务持续使用的产物。

52
00:04:48,440 --> 00:04:54,400
创建阶段检查系统能否被构建；演化阶段检查反馈能否改进现有产物。

53
00:04:55,220 --> 00:04:58,220
完成关卡示例展示了建设性的局部修复。

54
00:04:58,720 --> 00:05:02,200
留出对比检查这些修复能否超越反馈集合发挥作用。

55
00:05:03,040 --> 00:05:07,860
代码必须能够运行，保留有用行为，并与执行它的模型保持兼容。

56
00:05:08,680 --> 00:05:13,740
一个有说服力的自开发智能体，需要同时提供软件和下游表现的证据。

57
00:05:14,340 --> 00:05:20,780
重要的成果是一个能够测量的工程任务：构建、冻结、运行、检查，再修改。