1
00:00:00,100 --> 00:00:06,432
本内容改编自小山学堂《学 AI 产品，从入门到精通》，为二次演绎配音版。

2
00:00:06,382 --> 00:00:10,757
这一集讲两件事，一件是观念，一件是架构。

3
00:00:10,757 --> 00:00:18,329
观念这件是，Harness 不只是包裹模型的外壳，它正在成为 AI 递归自我改进的核心引擎。

4
00:00:18,329 --> 00:00:28,365
架构这件是，好的 Harness 有清晰的模式语言，三个核心模式覆盖了当前最强智能体系统百分之九十的架构决策。

5
00:00:28,365 --> 00:00:30,769
先说清楚 Harness 是什么。

6
00:00:30,769 --> 00:00:42,584
它是围绕基座模型的运行时系统，决定模型怎么思考与规划，怎么调用工具与行动，怎么感知与管理上下文，怎么存储制品，怎么评估结果。

7
00:00:42,584 --> 00:00:45,925
一句话，模型周围的一切编排系统。

8
00:00:45,925 --> 00:00:49,134
为什么这两件事值得放在一起讲。

9
00:00:49,134 --> 00:00:55,661
因为行业里已经有一个被反复验证的结论，Harness 层与原始模型智能同等重要。

10
00:00:55,661 --> 00:01:01,334
一个平庸的模型加上优秀的 Harness，往往胜过裸露的更强模型。

11
00:01:01,334 --> 00:01:06,213
这句话听着反直觉，但它是这集所有内容的地基。

12
00:01:06,360 --> 00:01:11,910
先铺一段历史，这段历史能让后面那个论断显得不那么突然。

13
00:01:11,860 --> 00:01:20,791
一九六五年，古德定义了超级智能机器，能在所有智力活动上超越人类，并设计更好的机器来改进自身。

14
00:01:20,791 --> 00:01:22,834
那还只是理论设想。

15
00:01:22,834 --> 00:01:32,437
到了二零零八年，尤德考斯基正式提出递归自我改进这个概念，指的是 AI 用自身智能去改进产生智能的认知机制。

16
00:01:32,437 --> 00:01:38,110
中间还有一串早期尝试，自博弈、合成数据、测试时训练。

17
00:01:38,110 --> 00:01:45,142
它们的共同点是，模型开始改善自己的训练数据，但还没有碰产生智能的机制本身。

18
00:01:45,142 --> 00:01:50,755
最近的这一步变化是，Harness 工程成了递归自我改进的核心路径。

19
00:01:50,755 --> 00:01:58,964
关键区别在于，模型不直接改写权重，它改进的是围绕自身的部署系统、工作流和上下文管理。

20
00:01:58,964 --> 00:02:01,043
这里要交代一下出处。

21
00:02:01,043 --> 00:02:08,002
本篇章的整个框架、概念与案例，都源自莉莉安·翁在二零二六年七月发表的长文。

22
00:02:08,002 --> 00:02:15,502
她在 AI 安全与智能体前沿领域持续输出多年，她的博客几乎是这个行业公认的必读。

23
00:02:15,502 --> 00:02:21,163
原作者的观点与功劳都属于她，这里做的只是讲得更适合听。

24
00:02:21,163 --> 00:02:25,034
为什么要把出处说得这么清楚，有两层原因。

25
00:02:25,034 --> 00:02:29,769
一层是尊重，这种级别的框架性工作值得被指名。

26
00:02:29,769 --> 00:02:38,159
另一层更实际，这类长文里藏着大量原文才说得清的限定条件，转述过程中难免丢掉一些边界。

27
00:02:38,159 --> 00:02:44,709
所以如果你打算把这集的结论用在工作里，回去读原文是对自己负责的做法。

28
00:02:44,860 --> 00:02:48,319
为什么不是直接改权重，而是改 Harness。

29
00:02:48,269 --> 00:02:51,358
有三步预测可以把这件事说清楚。

30
00:02:51,358 --> 00:02:59,471
第一步，模型不会直接改写自己的权重，但它能改进训练管线和部署系统，使下一代模型更强。

31
00:02:59,471 --> 00:03:07,812
这一步今天是成立的，因为改权重这件事的验证成本极高，而改外围系统的验证成本很低。

32
00:03:07,812 --> 00:03:11,262
第二步，Harness 工程走向元方法论。

33
00:03:11,262 --> 00:03:16,070
改善的对象从答案本身，变成得到更好答案的机制。

34
00:03:16,070 --> 00:03:24,291
这是关键的一跳，以前我们优化的是模型给出的那个结果，现在我们优化的是它是怎么走到那个结果的。

35
00:03:24,291 --> 00:03:26,947
Harness 本身成了优化目标。

36
00:03:26,947 --> 00:03:32,223
第三步，成熟的 Harness 加上智能模型形成正反馈循环。

37
00:03:32,223 --> 00:03:39,014
更好的 Harness 催生更强的模型，更强的模型又让 Harness 不必过度工程化。

38
00:03:39,014 --> 00:03:48,822
这个循环有意思的地方在于它是自我收敛的，模型变强之后，一些原本靠工程手段补的短板会被模型自身的能力吃掉。

39
00:03:48,822 --> 00:03:52,332
有个现成的类比可以帮你理解这个过程。

40
00:03:52,332 --> 00:04:04,615
随着指令微调和推理能力提升，手动提示词技巧变得不那么核心了，但指定目标、约束、上下文和评估的需求并没有消失，只是换了个地方存在。

41
00:04:04,615 --> 00:04:13,317
Harness 也是一样，最终很多改进会被内化为模型行为，但与外部上下文和工具的接口将永远存在。

42
00:04:13,470 --> 00:04:16,268
进入架构部分，三个模式。

43
00:04:16,218 --> 00:04:21,266
它们不是可选优化，是任何生产级智能体的结构性需求。

44
00:04:21,266 --> 00:04:23,874
第一个是工作流自动化。

45
00:04:23,874 --> 00:04:30,713
核心思想是，智能体是一个目标导向的循环，不能当成执行一次就结束的脚本。

46
00:04:30,713 --> 00:04:36,915
循环是这么走的，规划、执行、观察或测试、改进、再执行。

47
00:04:36,915 --> 00:04:40,461
每一轮生成都是下一轮优化的起点。

48
00:04:40,461 --> 00:04:43,165
这里有三个要点值得拆开说。

49
00:04:43,165 --> 00:04:54,908
第一，优秀的智能体会分析自身轨迹，回头看自己前几轮做了什么、哪里失败了、为什么失败，然后调整策略，避免重复同一个提示词。

50
00:04:54,908 --> 00:05:01,939
第二，强调运行时迭代，改进发生在执行过程中，不依赖人类事先写好的静态模板。

51
00:05:01,939 --> 00:05:10,918
第三，失败是信号而不是终止，测试不通过、命令报错、输出不符合预期，这些都是自我纠正的触发条件。

52
00:05:10,918 --> 00:05:15,894
设计启示很直接，不要把智能体设计成一次性回答器。

53
00:05:15,894 --> 00:05:26,687
让它拥有自己审查自己的能力，看到测试失败后自动分析原因，看到代码检查报错后自动修复，看到用户反馈后调整策略。

54
00:05:26,687 --> 00:05:31,999
这就是工作流自动化的核心，把反馈循环内置到系统里。

55
00:05:31,999 --> 00:05:36,579
这个转变听起来简单，做起来是一次身份的重新定义。

56
00:05:36,579 --> 00:05:45,064
一次性回答器的验收标准是「首次输出够不够好」，而循环型智能体的验收标准是「它能不能收敛到够好」。

57
00:05:45,064 --> 00:05:49,632
前者关注单次采样的质量，后者关注迭代的收敛性。

58
00:05:49,632 --> 00:05:59,992
这两套指标会导向完全不同的工程投入，比如前者会让人拼命堆提示词，后者会让人去补测试、补日志、补可观测性。

59
00:05:59,992 --> 00:06:04,415
你想优化什么，取决于你把系统定义成什么。

60
00:06:04,570 --> 00:06:13,101
第二个模式解决的是一个非常具体的问题，在长期运行的智能体中，制品会迅速超出上下文窗口。

61
00:06:13,051 --> 00:06:20,984
制品种类很多，实验日志、代码差异、论文摘要、错误追踪记录、过去的完整执行轨迹。

62
00:06:20,984 --> 00:06:25,082
这些都是有价值的状态，但塞不进上下文。

63
00:06:25,082 --> 00:06:34,530
答案是把持久状态存在文件系统里，让智能体学会按需读写，不要试图把全部工作历史压进提示词。

64
00:06:34,530 --> 00:06:46,717
为什么用文件系统而不是别的方案，有个理由很实在，文件读写是大模型的基础技能，不需要复杂的外部工具链，它直接受益于核心模型能力的提升。

65
00:06:46,717 --> 00:06:50,034
模型越聪明，文件管理越高效。

66
00:06:50,034 --> 00:06:55,671
这一点比很多精巧的外部方案更值得押注，因为它是顺水推舟的。

67
00:06:55,671 --> 00:07:03,448
好的智能体会自己维护暂存笔记、待办列表、实验记录，像人类程序员一样管理工作区。

68
00:07:03,448 --> 00:07:06,621
那什么该放上下文，什么该放文件。

69
00:07:06,621 --> 00:07:15,491
放上下文的是需要即时参考的信息，当前正在处理的任务指令、即时的工具调用结果、最近两三轮对话。

70
00:07:15,491 --> 00:07:26,549
放文件系统的是需要持久保存但不必时刻在视野中的信息，历史实验结果、累积的错误日志、已完成子任务的摘要、长期策略和规则。

71
00:07:26,549 --> 00:07:32,258
关键原则一句话，上下文是工作记忆，文件系统是长期记忆。

72
00:07:32,258 --> 00:07:37,186
好的 Harness 像人脑一样，在两者之间智能地搬运信息。

73
00:07:37,186 --> 00:07:40,070
这个比喻值得再往深推一层。

74
00:07:40,070 --> 00:07:49,974
人脑的工作记忆容量也很小，大概只能同时 hold 住几个组块，但人靠写字、画图和做笔记把思考外包给了外部介质。

75
00:07:49,974 --> 00:07:59,698
工程师写代码、写文档、写提交信息，本质上都是把工作记忆的内容固化到长期介质里，腾出空间继续思考。

76
00:07:59,698 --> 00:08:09,337
智能体面对的是同样的约束，所以解法也应该是同样的，不是想办法把工作记忆撑大，而是建立一套可靠的搬运机制。

77
00:08:09,337 --> 00:08:18,003
这里还有个反直觉的提醒，把上下文塞满通常不是因为信息真的都需要，而是因为没有做取舍的机制。

78
00:08:18,003 --> 00:08:25,984
一旦你有了文件系统这个落点，取舍就变得自然了，不需要的先写下去，要用的时候再读回来。

79
00:08:26,150 --> 00:08:34,513
第三个模式处理的是单体不够用的情况，生成多个子智能体并行执行，同时监控后台长任务。

80
00:08:34,463 --> 00:08:43,165
父智能体扮演进程管理器，启动子任务、检查日志和进度、取消失败的分支、合并成功的结果。

81
00:08:43,165 --> 00:08:49,559
这是操作系统层面的思维，把一个智能体系统当成一个进程树来管理。

82
00:08:49,559 --> 00:08:51,074
有四条纪律。

83
00:08:51,074 --> 00:09:00,088
第一，并行性必须显式且可检查，不能发射后不管，父智能体要能查看每个子智能体的状态、输出和错误。

84
00:09:00,088 --> 00:09:11,398
第二，子智能体输出要持久化，结果存为文件、日志或状态记录，而不只是返回到父智能体的上下文中，这样即使中断也能恢复。

85
00:09:11,398 --> 00:09:20,376
第三，容错与恢复，后台任务可能超时、崩溃或产出低质量结果，需要设计重试策略和优雅降级。

86
00:09:20,376 --> 00:09:26,254
第四，也是最重要的一条取舍，并行带来速度，但也带来复杂性。

87
00:09:26,254 --> 00:09:39,391
成功的实现都遵循同一个原则，让每个子智能体在独立的沙箱中工作，输出到明确的文件路径，父智能体通过轮询文件状态来协调，不做内存共享。

88
00:09:39,391 --> 00:09:48,826
这一条极大简化了并发控制，因为它把最难的那部分问题，也就是共享状态的一致性，直接从架构里删掉了。

89
00:09:48,970 --> 00:09:53,956
有个对比数据很能说明三个模式的价值，值得念一遍。

90
00:09:53,906 --> 00:09:59,182
第一种架构，所有工具返回、历史轨迹全塞进上下文。

91
00:09:59,182 --> 00:10:05,648
结果是上下文窗口到百分之九十二，溢出风险极高，第四轮就开始丢信息。

92
00:10:05,648 --> 00:10:09,651
智能体开始遗忘早期信息，输出质量骤降。

93
00:10:09,651 --> 00:10:17,091
第二种架构，每轮完成后写文件、释放上下文，下一轮只读需要的文件片段。

94
00:10:17,091 --> 00:10:24,074
上下文稳定在百分之三十五，可以持续运行数十轮不退化，因为上下文大小恒定。

95
00:10:24,074 --> 00:10:33,593
第三种架构，主智能体只做规划和派发，子智能体各自独立沙箱、结果写文件，主智能体轮询状态加合并。

96
00:10:33,593 --> 00:10:41,586
主上下文只有百分之二十八，速度提升三倍，五个任务三轮全部完成，而串行需要五轮。

97
00:10:41,586 --> 00:10:45,360
这三个数字放在一起，结论不需要再解释。

98
00:10:45,360 --> 00:10:49,627
差别不在模型，在怎么组织模型周围的那一层。

99
00:10:49,627 --> 00:10:58,413
同样的基座，换个组织方式，从第四轮就开始丢信息，变成能稳定跑几十轮，还能顺带拿到三倍速度。

100
00:10:58,413 --> 00:11:07,848
这三种架构的差距，比换一个更强的模型带来的差距大得多，而它的成本只是改架构，不用重新训练任何东西。

101
00:11:07,848 --> 00:11:14,038
这也侧面解释了开头那句话，为什么 Harness 层与模型智能同等重要。

102
00:11:14,038 --> 00:11:17,740
三个模式是三层叠加，不需要三选一。

103
00:11:17,740 --> 00:11:23,449
工作流自动化提供了执行的脊椎，也就是循环结构和反馈机制。

104
00:11:23,449 --> 00:11:30,732
文件系统记忆为循环提供了硬盘，让每轮迭代的成果不会丢失，即使上下文被清空。

105
00:11:30,732 --> 00:11:38,040
子智能体并行为循环提供了多核，当任务可分解时，用并行加速取代串行等待。

106
00:11:38,040 --> 00:11:45,180
三者组合，一个智能体就具备了迭代优化、长期记忆、并行扩展的能力。

107
00:11:45,320 --> 00:11:51,135
看一眼主流编码智能体的核心工具接口，你会发现它们高度趋同。

108
00:11:51,085 --> 00:11:55,929
这些当前最强的产品都围绕相似的工具集构建 Harness。

109
00:11:55,929 --> 00:12:07,864
文件系统这一组，读、写、搜索、编辑文件，管理工作区状态，典型工具有读取、写入、编辑、通配符匹配、内容搜索、字符串替换。

110
00:12:07,864 --> 00:12:13,104
外壳执行这一组，执行终端命令、运行测试、安装依赖。

111
00:12:13,104 --> 00:12:18,320
输入输出这一组，与用户交互、确认操作、展示结果。

112
00:12:18,320 --> 00:12:23,465
外部上下文这一组，获取外部信息、文档、接口响应。

113
00:12:23,465 --> 00:12:25,616
网络搜索单独一组。

114
00:12:25,616 --> 00:12:29,763
制品这一组，生成、管理和版本化制品。

115
00:12:29,763 --> 00:12:34,967
后台进程这一组，后台运行长任务、监控进程状态。

116
00:12:34,967 --> 00:12:40,941
智能体委派这一组，生成子智能体、分配并行任务、合并结果。

117
00:12:40,941 --> 00:12:44,955
这张表的价值在于，它是一份现成的清单。

118
00:12:44,955 --> 00:12:50,616
你要搭自己的 Harness，照着这八组去配齐，基本不会漏掉结构性能力。

119
00:12:50,616 --> 00:12:57,647
反过来说，如果你的系统缺了其中某一组，缺的那一组往往就是你能力短板的来源。

120
00:12:57,647 --> 00:13:00,965
更有意思的是这个趋同现象本身。

121
00:13:00,965 --> 00:13:10,412
几家互相独立的产品，最后收敛到了几乎一样的工具分组，这不是巧合，说明这套分组背后有某种结构性约束。

122
00:13:10,412 --> 00:13:20,953
当你看到多个团队独立地走到同一个形状，通常意味着那个形状是被问题本身的性质决定的，而不是被某个团队的品味决定的。

123
00:13:20,953 --> 00:13:25,857
所以抄这张表不丢人，它更像是抄一份物理常数。

124
00:13:25,857 --> 00:13:32,623
另外注意最后两组，后台进程和智能体委派，它们正是第三个模式的落地形态。

125
00:13:32,623 --> 00:13:37,780
前六组是单体的能力边界，后两组是突破单体的手段。

126
00:13:37,780 --> 00:13:45,869
很多系统做到前六组就停了，然后困惑于为什么能力上不去，答案往往就在缺的这两组里。

127
00:13:46,020 --> 00:13:49,010
最后收几条能直接用上的原则。

128
00:13:48,960 --> 00:13:53,564
第一，把智能体设计成循环，不是一次性回答器。

129
00:13:53,564 --> 00:14:00,559
规划、执行、观察、改进、再执行，并且把失败当成信号而不是终止。

130
00:14:00,559 --> 00:14:06,965
测试不通过、命令报错，这些都该触发自我纠正，而不是直接抛给用户。

131
00:14:06,965 --> 00:14:11,629
第二，上下文是工作记忆，文件系统是长期记忆。

132
00:14:11,629 --> 00:14:18,131
需要即时参考的放上下文，需要持久保存但不必时刻在视野中的放文件。

133
00:14:18,131 --> 00:14:26,532
别试图把全部工作历史压进提示词，那会让上下文在第几轮就打满，然后输出质量断崖式下跌。

134
00:14:26,532 --> 00:14:29,766
第三，并行必须显式且可检查。

135
00:14:29,766 --> 00:14:38,143
子智能体各自独立沙箱，输出到明确路径，父智能体轮询文件状态来协调，不做内存共享。

136
00:14:38,143 --> 00:14:45,367
这一条把并发控制里最难的一致性直接从架构里删掉，是性价比最高的一个决定。

137
00:14:45,367 --> 00:14:48,347
第四，别低估 Harness 层的价值。

138
00:14:48,347 --> 00:14:54,020
一个平庸的模型加上优秀的 Harness，往往胜过裸露的更强模型。

139
00:14:54,020 --> 00:15:00,186
如果你的产品效果上不去，先看看是模型不行，还是模型周围那一层太薄。

140
00:15:00,186 --> 00:15:03,936
第五，把优化对象从答案提升到机制。

141
00:15:03,936 --> 00:15:09,922
改善智能体的方式不只是改提示词，还可以改它得到答案的那个流程。

142
00:15:09,922 --> 00:15:18,059
这是递归自我改进在当下最现实的落地方式，不需要改模型权重，只需要改围绕模型的那一层。

143
00:15:18,059 --> 00:15:27,987
最后一句提醒，这集的框架来自莉莉安·翁那篇长文，强烈建议听完回去读原文，原作者的观点与功劳都属于她。