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

2
00:00:06,382 --> 00:00:08,918
这是本专题的最后一集。

3
00:00:08,918 --> 00:00:17,127
前面我们把 DeepSeek Harness 几乎每一层都拆开看过，从事件日志真源一路到凭据、设置、遥测。

4
00:00:17,127 --> 00:00:20,240
今天不做新的拆解，做一次收拢。

5
00:00:20,240 --> 00:00:23,076
先把要解决的三个问题摆出来。

6
00:00:23,076 --> 00:00:28,834
五家 Agent 底座在真源、扩展、安全这三个维度上各站在哪里。

7
00:00:28,834 --> 00:00:33,605
那些机制里，有哪五件我们不用它的框架也能抄走。

8
00:00:33,605 --> 00:00:38,581
还有哪些设计看着眼馋，但没有专职团队千万别碰。

9
00:00:38,581 --> 00:00:45,000
这三件事本质上是一个问题，别人的最佳实践，凭什么到你这儿就变成了负债。

10
00:00:45,000 --> 00:00:50,480
给一句贯穿全片的判断标准，也是这一集唯一必须记住的话。

11
00:00:50,480 --> 00:00:54,050
删掉框架还成立的设计才值得抄。

12
00:00:54,050 --> 00:01:00,456
听着像废话，但真到拍板的时候，我们大多数人抄的都是框架那一层。

13
00:01:00,456 --> 00:01:02,764
另外提一句证据边界。

14
00:01:02,764 --> 00:01:09,951
五家里的三列是逐行核对过的源码和官方材料，另外两列来自公开资料，没有逐行核。

15
00:01:09,951 --> 00:01:12,860
取舍的时候请你自己去验证。

16
00:01:12,860 --> 00:01:21,454
还有一处更正要说明，表里某一列成文比较早，后来那一家的源码我另开了一章逐行拆过，结论以那一章为准。

17
00:01:21,454 --> 00:01:25,036
这一集还配了一个可以自己动手的演示。

18
00:01:25,036 --> 00:01:34,146
它把全专题讲过的主要机制做成了勾选项，每张卡片标着这个机制解决什么问题、依赖哪些前置机制。

19
00:01:34,146 --> 00:01:44,122
你像点菜一样勾出项目里需要的，右边实时生成一份架构清单，缺了依赖会标红，勾了体量陷阱会提醒你养不养得起。

20
00:01:44,122 --> 00:01:49,531
建议你看完这一集回去对着自己手上的项目点一遍，比听十集有用。

21
00:01:49,531 --> 00:01:54,014
这一集不像前面那样抽丝剥茧，它更像一次评审。

22
00:01:54,014 --> 00:02:01,406
我们会把三十来个机制筛成两堆，一堆能原地搬走，一堆看着眼馋但碰了必翻车。

23
00:02:01,560 --> 00:02:05,272
第一个维度，对话状态的权威副本放哪儿。

24
00:02:05,222 --> 00:02:10,246
DSH 的答案是 append-only 的事件日志，压缩过的按行文本。

25
00:02:10,246 --> 00:02:16,484
它的厉害之处不在存储格式，而在于这一份东西同时伺候四个用处。

26
00:02:16,484 --> 00:02:20,931
恢复、分叉、检索、回放，共用同一份。

27
00:02:20,931 --> 00:02:25,955
消息数组永远从它派生，不存在第二份需要同步的副本。

28
00:02:25,955 --> 00:02:31,327
Claude Code 是一份会话文件，事后记录型，主要支撑恢复和查看。

29
00:02:31,327 --> 00:02:35,041
够用，但它的定位是记录而不是源泉。

30
00:02:35,041 --> 00:02:40,654
Grok Build 是内存为主，异步落盘为从，写盘失败不打断对话。

31
00:02:40,654 --> 00:02:44,957
这个取舍很干净，对话的连续性优先于持久性。

32
00:02:44,957 --> 00:02:48,226
Codex 那边是会话的 rollout 文件。

33
00:02:48,226 --> 00:02:53,106
OpenCode 则是本地文件存储的会话数据，中规中矩。

34
00:02:53,106 --> 00:02:54,789
看出差别了吗。

35
00:02:54,789 --> 00:03:01,075
同样是存对话，有的是唯一的源头，有的是事后的记录，有的是内存的投影。

36
00:03:01,075 --> 00:03:08,034
这个选择会一直往下传导，决定你能不能分叉、能不能回放、能不能事后给人看证据。

37
00:03:08,034 --> 00:03:16,604
这里我建议你换个问法，别问我们用什么格式存，问一句，出问题的时候，我拿哪一份东西出来当证据。

38
00:03:16,604 --> 00:03:20,967
答案是事件日志的，说明你把真源当成了资产。

39
00:03:20,967 --> 00:03:25,654
答案是事后记录文件的，说明你把真源当成了日志。

40
00:03:25,654 --> 00:03:33,359
两种选择都能跑，但它们在审计、回放、分叉这几件事上的能力差着一个数量级。

41
00:03:33,500 --> 00:03:36,863
第二个维度，第三方怎么给系统加能力。

42
00:03:36,813 --> 00:03:39,662
DSH 的立场是一切皆插件。

43
00:03:39,662 --> 00:03:45,455
二百一十九个包，四十九个分组，还支持把包组从仓库外面装进来。

44
00:03:45,455 --> 00:03:52,234
代价后面讲，先说收益，任何能力进来走的是同一条路，同一套生命周期。

45
00:03:52,234 --> 00:03:59,662
Claude Code 是钩子、外接工具协议、子代理和插件多条路并存，属于产品线先解问题的做法。

46
00:03:59,662 --> 00:04:03,628
Grok Build 是七十多个静态单元，编译期定形。

47
00:04:03,628 --> 00:04:07,174
好处是确定性，没有运行期组装的意外。

48
00:04:07,174 --> 00:04:10,022
Codex 以外接工具协议为主。

49
00:04:10,022 --> 00:04:14,854
OpenCode 是抽象层加插件，多模型接入是它的第一需求。

50
00:04:14,854 --> 00:04:19,421
这张表看完记住一件事，五家没有对错，只有立场。

51
00:04:19,421 --> 00:04:23,676
产品单体的公司，要的是快，数据驱动止损。

52
00:04:23,676 --> 00:04:27,089
看重性能的团队，要编译期就定死。

53
00:04:27,089 --> 00:04:32,907
天天在别人机器上跑命令的工具，当然要把不信任写进操作系统那层。

54
00:04:32,907 --> 00:04:37,967
而把可更换模型放在第一位的，界面形式就不是重点了。

55
00:04:37,967 --> 00:04:39,806
再补一层观察。

56
00:04:39,806 --> 00:04:46,344
扩展模型的选择，其实是在回答一个新能力从提出到上线要走几道审批。

57
00:04:46,344 --> 00:04:50,010
走同一条路的，治理简单但门槛高。

58
00:04:50,010 --> 00:04:57,883
多条路并存的，上手快但每条路的生命周期都不一样，最后你会有五种不同味道的插件。

59
00:04:57,883 --> 00:05:05,395
这两条我都待过，说不上哪条更好，但你得选一条，并且让所有人知道选的是哪一条。

60
00:05:05,540 --> 00:05:10,465
第三个维度最有意思，防出事到底靠劝，还是靠机制。

61
00:05:10,415 --> 00:05:12,663
DSH 靠的是机制层。

62
00:05:12,663 --> 00:05:17,651
运行时断言、类型边界、溯源鉴权、单调证明。

63
00:05:17,651 --> 00:05:21,726
这四个词的共同点是，它们都不需要人配合。

64
00:05:21,726 --> 00:05:27,495
它的立场写成一句话就是，运行时优先，可证明性压倒交付速度。

65
00:05:27,495 --> 00:05:34,117
这也是它文档和测试体量膨胀到吓人的根源，选择了可证明，就得付那笔账。

66
00:05:34,117 --> 00:05:39,298
Claude Code 靠的是权限确认框，加上把生产监控的反馈接回来。

67
00:05:39,298 --> 00:05:45,740
有个细节我很欣赏，它的断路器阈值不是拍脑袋定的，来自真实账单数据。

68
00:05:45,740 --> 00:05:50,067
产品单体的优势在这儿，数据能从业务里直接拿。

69
00:05:50,067 --> 00:05:56,617
Grok Build 把一部分力气交给类型系统，加上确认流程和编译期固定的模板。

70
00:05:56,617 --> 00:06:05,223
Codex 是审批模式分级，加上操作系统级沙箱，一个管平台自用解释器，一个管另一种系统下的接口。

71
00:06:05,223 --> 00:06:08,264
OpenCode 以权限确认这一种为主。

72
00:06:08,264 --> 00:06:13,120
这五种选择没有高下，但你得知道自己端的是哪碗饭。

73
00:06:13,120 --> 00:06:20,800
同一家公司今天用确认框，明天改用类型系统，往往不是因为它更先进，是因为它的人变了。

74
00:06:20,800 --> 00:06:23,937
还有一个更细的区分值得单独说。

75
00:06:23,937 --> 00:06:27,699
靠确认框的路线，前提是有人在看。

76
00:06:27,699 --> 00:06:35,704
一旦运行规模上去，或者进了无人值守的流程，确认框就退化成了一个自动点同意的按钮。

77
00:06:35,704 --> 00:06:41,629
靠机制的路线没有这个退化点，代价是前期投入肉眼可见地贵。

78
00:06:41,629 --> 00:06:46,954
所以真正该问的是，这个系统会有一部分时间是没人盯的吗。

79
00:06:46,954 --> 00:06:51,738
答案是会，那就别把保命的东西放在人的注意力上。

80
00:06:51,880 --> 00:06:56,361
三十来个机制里，大多数和它的插件框架绑死。

81
00:06:56,311 --> 00:06:59,736
但有五件是纯思路，抄走就能用。

82
00:06:59,736 --> 00:07:02,320
第一，事件日志真源。

83
00:07:02,320 --> 00:07:08,318
对话状态只存一份 append-only 的事件序列，消息数组永远从它派生。

84
00:07:08,318 --> 00:07:14,953
一个文本文件加一个折叠函数就是最小实现，恢复和回放是白送的。

85
00:07:14,953 --> 00:07:17,537
第二，三种输入语义。

86
00:07:17,537 --> 00:07:25,650
用户在 Agent 干活时发来的消息，明确分成排队、插话、打断三种命运，写成显式的接口语义。

87
00:07:25,650 --> 00:07:33,847
没有这一层，输入时机就是薛定谔的状态，你永远不知道那句话到底算插话还是算下一轮的指令。

88
00:07:33,847 --> 00:07:36,058
第三，双路径压缩。

89
00:07:36,058 --> 00:07:42,729
主动测压和被动溢出恢复分开挂，事件不同、条件不同、失败语义也不同。

90
00:07:42,729 --> 00:07:49,051
混成一条路径，你就分不清这次压缩是计划内的保养还是兜底的抢救。

91
00:07:49,051 --> 00:07:51,251
第四，溯源鉴权。

92
00:07:51,251 --> 00:07:57,212
每段进入上下文的内容都带来源标签，高权限操作只认可信来源。

93
00:07:57,212 --> 00:08:02,633
工具结果里藏的指令冒充不了用户，这一条在今天比什么都实用。

94
00:08:02,633 --> 00:08:04,688
第五，单调 Guard。

95
00:08:04,688 --> 00:08:13,474
重试、恢复这类危险放行，一律要求出示单调递增的证据，世代号或者计数器都行，不认插件的口供。

96
00:08:13,474 --> 00:08:22,212
这条解决的是一个特别隐蔽的 bug，同一个动作被放行两次，两次之间世界已经变了，可系统自己不知道。

97
00:08:22,212 --> 00:08:29,412
这五件的共同点，它们都是接口语义层面的决定，跟你用什么语言、什么框架无关。

98
00:08:29,412 --> 00:08:32,849
一个周末能搭出毛坯，剩下的是打磨。

99
00:08:32,849 --> 00:08:35,686
再强调一遍它们为什么好抄。

100
00:08:35,686 --> 00:08:39,340
因为它们都不要求你引入任何基础设施。

101
00:08:39,340 --> 00:08:53,558
事件日志就是一个文本文件加一个函数，输入语义就是三个枚举值，双路径压缩就是两个触发条件，溯源鉴权就是给每段内容贴个标签，单调 Guard 就是放行前比一下数字。

102
00:08:53,558 --> 00:08:56,335
没有一样需要团队扩编。

103
00:08:56,490 --> 00:09:03,026
反过来，有三件是拿专职团队的人力堆出来的，个人和小团队照抄必翻车。

104
00:09:02,976 --> 00:09:06,137
第一，二百一十九个包的插件树。

105
00:09:06,137 --> 00:09:16,558
一切皆插件听起来优雅，落到操作上意味着每个能力都要切出三个角色，服务定义、提供方、使用方，还得配齐说明文档和测试。

106
00:09:16,558 --> 00:09:20,224
它的仓库里有二百六十八份说明文档。

107
00:09:20,224 --> 00:09:25,284
你项目里的同款需求，一个插件文件夹加一条约定就够了。

108
00:09:25,284 --> 00:09:28,216
第二，双语三文件的文档配对。

109
00:09:28,216 --> 00:09:36,930
每份文档是英文、中文，再加一份记录两侧哈希的配对文件，改一边不重新确认配对，持续集成就红。

110
00:09:36,930 --> 00:09:41,065
纪律漂亮，成本是每次文档改动双倍起步。

111
00:09:41,065 --> 00:09:44,695
第三，逐文件的百分之百覆盖率门禁。

112
00:09:44,695 --> 00:09:52,531
有意思的是它自己都写了一篇笔记承认，覆盖率只证明代码被执行过，不证明它被验证过。

113
00:09:52,531 --> 00:10:00,224
没有大规模自动生成测试的产能，这个门禁只会逼人写出那种执行但不断言的假测试。

114
00:10:00,224 --> 00:10:02,676
这条我踩过，说点体感。

115
00:10:02,676 --> 00:10:07,243
一旦定了百分之百这个数字，团队的行为会立刻变形。

116
00:10:07,243 --> 00:10:16,257
难测的部分被拆成小函数，断言被写成检查返回值不等于空，覆盖率报表一片绿，回归照样发。

117
00:10:16,257 --> 00:10:20,801
门禁没有变严，只是把压力从质量转移到了耐心上。

118
00:10:20,801 --> 00:10:23,361
所以判断标准很简单。

119
00:10:23,361 --> 00:10:28,553
五件可抄的都是接口语义，三件陷阱都是基础设施。

120
00:10:28,553 --> 00:10:32,219
问一句，这个设计删掉框架还成立吗。

121
00:10:32,219 --> 00:10:33,841
成立就能抄。

122
00:10:33,841 --> 00:10:36,293
再给一个更实用的自测。

123
00:10:36,293 --> 00:10:49,322
抄之前问三件事，引完之后我们要不要加人维护，一年之后这套东西还在不在人手里，以及最关键的，它现在是解决了问题，还是解决了引入它所带来的问题。

124
00:10:49,322 --> 00:10:53,180
三个答案里有任何一个含糊，就先别抄。

125
00:10:53,320 --> 00:10:55,157
收官不吹主角。

126
00:10:55,107 --> 00:11:02,859
它是开发者预览版，仓库根目录那份给 Agent 看的说明文件，第二节第一句话就写着预发布立场。

127
00:11:02,859 --> 00:11:04,938
原话的大意是这样。

128
00:11:04,938 --> 00:11:08,111
第一个正式版本发布时，删掉本节。

129
00:11:08,111 --> 00:11:19,397
当前没有外部使用者，宁要正确的地基，也不做兼容垫片；后端直接拒绝旧的磁盘格式，会话格式版本停在零，不做任何兼容承诺。

130
00:11:19,397 --> 00:11:22,486
还有两处没干完也写在明面上。

131
00:11:22,486 --> 00:11:31,296
外接工具协议这边只桥了工具一种能力，资源和提示词明确延后，理由写得毫不掩饰，没有使用方就先不做。

132
00:11:31,296 --> 00:11:38,676
产品入口也只有一个网页端和一个无界面运行端，没有另外两家那种交互式终端界面。

133
00:11:38,676 --> 00:11:41,537
这三条不算黑点，算取舍。

134
00:11:41,537 --> 00:11:44,085
地基没干透之前不浇二楼。

135
00:11:44,085 --> 00:11:48,869
看一个项目的成熟度，我建议你先看它敢不敢列这张表。

136
00:11:48,869 --> 00:11:51,994
敢写未完成的项目，通常也敢写 bug。

137
00:11:51,994 --> 00:12:00,034
我自己带项目的习惯是把这张表放在仓库根目录那份给 Agent 看的文件里，和给人看的文档并列。

138
00:12:00,034 --> 00:12:06,236
为什么放在那儿，因为任何新来的人和任何新来的模型，第一眼读的都是它。

139
00:12:06,236 --> 00:12:13,111
你在这里写清楚哪些没承诺兼容，比在文档站上写十页免责声明都管用。

140
00:12:13,260 --> 00:12:17,897
最后讲一个容易被略过、但最能解释它动机的东西。

141
00:12:17,847 --> 00:12:22,414
它的四种产品模式，实际上就是四份预设配置文件。

142
00:12:22,414 --> 00:12:26,188
其中极简模式的核心配置一共没几行。

143
00:12:26,188 --> 00:12:28,712
读一下这份配置在做什么。

144
00:12:28,712 --> 00:12:35,359
系统提示词只有一句话，而且声明为完整不可追加，任何插件都加不了字。

145
00:12:35,359 --> 00:12:37,991
运行时上下文被抑制。

146
00:12:37,991 --> 00:12:42,450
工具只剩两个，一个命令行，一个文件编辑。

147
00:12:42,450 --> 00:12:44,626
压缩功能整个缺席。

148
00:12:44,626 --> 00:12:47,763
所有底座侧的变量都被拧到最小。

149
00:12:47,763 --> 00:12:57,234
而仓库里的基准测试文档，推荐用软件开发工具包跑这个极简变体做评测，每个任务用独立的工作区和会话。

150
00:12:57,234 --> 00:12:59,506
到这里动机就清楚了。

151
00:12:59,506 --> 00:13:08,580
模型厂商需要一台标准化、可复现、没有压缩干扰的测量仪来评自家模型，顺手把它做成了通用运行时。

152
00:13:08,580 --> 00:13:15,684
另一家做终端产品是为了让模型服务产品，这家做底座有一半是为了测量模型本身。

153
00:13:15,684 --> 00:13:18,520
立场不同，工程观自然不同。

154
00:13:18,520 --> 00:13:26,477
往后看，带强化的训练流程和模型评测，对这种可回放、可证明的底座只会更饥渴。

155
00:13:26,477 --> 00:13:31,056
这大概是它这套重机制路线最先兑现价值的地方。

156
00:13:31,056 --> 00:13:36,537
顺带说一句，这对我们这些不做模型的人是很好的职业提醒。

157
00:13:36,537 --> 00:13:40,347
你手上的工程，最终是在替谁产生价值。

158
00:13:40,347 --> 00:13:46,092
如果答案是替评测和训练产生数据，那可复现就比好用重要。

159
00:13:46,092 --> 00:13:51,501
如果答案是替终端用户产生体验，那好用就比可复现重要。

160
00:13:51,501 --> 00:13:56,164
同一套技术，服务对象不同，最优解完全不同。

161
00:13:56,320 --> 00:14:00,164
收尾，压成几条可以随时拿出来用的东西。

162
00:14:00,114 --> 00:14:02,710
第一，抄机制不抄框架。

163
00:14:02,710 --> 00:14:06,640
判断一句话，删掉框架还成立，就能抄。

164
00:14:06,640 --> 00:14:09,717
这是本集唯一希望你记住的一条。

165
00:14:09,717 --> 00:14:13,864
第二，先把三个维度上的立场写清楚再动手。

166
00:14:13,864 --> 00:14:17,782
真源放哪、第三方怎么进、防出事靠什么。

167
00:14:17,782 --> 00:14:24,994
这三件事的答案必须互斥且自洽，很多架构灾难是因为三个维度各抄了一家的优点。

168
00:14:24,994 --> 00:14:28,768
第三，先补缺的依赖，再补酷的功能。

169
00:14:28,768 --> 00:14:37,169
做一次评审，把已经有的机制勾出来，找出缺依赖的组合，比如有重试逻辑却没有任何单调证据。

170
00:14:37,169 --> 00:14:42,986
补那块的最小代码量如果超过一周，说明你该先去抄更底下那层。

171
00:14:42,986 --> 00:14:46,460
第四，把未完成写进仓库根目录。

172
00:14:46,460 --> 00:14:52,950
这张表的成本几乎为零，收益是团队和外部使用者对成熟度有正确预期。

173
00:14:52,950 --> 00:14:56,232
第五，体量既是成本也是自证。

174
00:14:56,232 --> 00:15:03,647
一万八千行文档、几百篇笔记、逐文件覆盖门禁，养这些的前提是有实打实的产能。

175
00:15:03,647 --> 00:15:07,590
它证明的与其说是必要性，不如说是投入。

176
00:15:07,590 --> 00:15:10,883
别拿别人的投入证明自己的必要性。

177
00:15:10,883 --> 00:15:12,277
最后一句。

178
00:15:12,277 --> 00:15:17,241
这个专题讲了三十来个机制，但机制会过时，立场不会。

179
00:15:17,241 --> 00:15:24,561
下次再看到一个新框架的时候，先别问它怎么装，先问一句，它在这三个维度上站在哪。

180
00:15:24,561 --> 00:15:27,794
想清楚这个，剩下的都是体力活。

181
00:15:27,794 --> 00:15:31,857
本专题到这里收官，感谢一路听到这里。