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

2
00:00:06,382 --> 00:00:12,055
这一集讲工具设计，一个听起来偏工程、实际上非常产品的话题。

3
00:00:12,055 --> 00:00:19,026
核心观点只有一句，你花在工具设计上的精力，应该和你花在提示词上的一样多。

4
00:00:19,026 --> 00:00:21,406
先说本集解决什么问题。

5
00:00:21,406 --> 00:00:29,026
传统软件里我们花大量精力设计人机界面，按钮放哪、文案怎么写、点了怎么反馈。

6
00:00:29,026 --> 00:00:35,120
但当智能体成为系统的使用者，界面就换了一样东西，变成了工具定义。

7
00:00:35,120 --> 00:00:39,795
工具的名字、参数、描述，就是它的用户界面。

8
00:00:39,795 --> 00:00:43,257
这一集给你一套设计这套界面的方法。

9
00:00:43,257 --> 00:00:46,093
再说为什么产品经理要关心。

10
00:00:46,093 --> 00:00:52,668
因为工具质量直接决定了智能体的能力上限，而工具设计里几乎全是取舍。

11
00:00:52,668 --> 00:01:00,745
要不要多做一个工具，两个工具的边界怎么划，调用之后返回多少内容，什么时候该调、什么时候不该调。

12
00:01:00,745 --> 00:01:04,230
这些都不是技术细节，是产品判断。

13
00:01:04,230 --> 00:01:06,634
顺便交代这一集的结构。

14
00:01:06,634 --> 00:01:20,192
前四节讲单个工具怎么设计，从原则到描述，再到一个完整的封装案例；后两节讲两个提升上限的手段，一个是在行动链中插入思考，一个是用评测驱动工具自我迭代。

15
00:01:20,192 --> 00:01:23,437
你可以把它当成一份工具评审清单来听。

16
00:01:23,437 --> 00:01:25,829
还有一层更现实的考虑。

17
00:01:25,829 --> 00:01:34,086
业界有一句广为流传的话，请把投入到智能体与计算机界面上的精力，提升到和人机界面一样的水平。

18
00:01:34,086 --> 00:01:44,182
这句话背后是一个容易忽略的事实，智能体不会自己变聪明，它能做到什么，很大程度上取决于你给了它什么样的工具。

19
00:01:44,330 --> 00:01:46,383
先看两者的区别。

20
00:01:46,333 --> 00:01:56,549
人机界面里，用户点一下查天气按钮，系统调用一个固定方法，返回结果，路径是确定的，相同操作必然得到相同结果。

21
00:01:56,549 --> 00:01:59,109
智能体这一侧完全不同。

22
00:01:59,109 --> 00:02:04,230
用户说一句要不要带伞，它要先判断，用户在哪个城市。

23
00:02:04,230 --> 00:02:07,763
如果对话里没提过，它可能先反问一句。

24
00:02:07,763 --> 00:02:15,131
然后判断要不要调工具，如果上一轮刚查过，它也许直接用缓存回答，跳过调用。

25
00:02:15,131 --> 00:02:22,270
接着判断调哪个，是查当前天气还是查未来预报，工具名和描述决定了它的选择。

26
00:02:22,270 --> 00:02:29,025
最后才是参数怎么填，城市填拼音还是填中文，格式不清晰它就容易出错。

27
00:02:29,025 --> 00:02:34,133
所以传统接口是确定性的，开发者写什么它就执行什么。

28
00:02:34,133 --> 00:02:42,631
而智能体的工具是非确定性的，模型需要自己理解什么时候用、怎么用，这完全取决于工具的设计质量。

29
00:02:42,631 --> 00:02:49,794
这就是为什么工具是智能体和世界之间的契约，契约写得含糊，执行就一定会走样。

30
00:02:49,794 --> 00:02:54,422
这个对比还引出一件重要的事，工具数量不是越多越好。

31
00:02:54,422 --> 00:02:57,980
每多一个工具，就多一次选错的机会。

32
00:02:57,980 --> 00:03:05,804
所以后面会讲到一条原则，如果两个工具的适用场景大面积重叠，宁可合并成一个。

33
00:03:05,950 --> 00:03:09,193
第一条，给模型足够的思考空间。

34
00:03:09,143 --> 00:03:15,116
模型生成参数是逐词进行的，一旦开始写就很难回头修改。

35
00:03:15,116 --> 00:03:21,102
所以设计上应该让它在写复杂参数之前，先写简单的方向性参数。

36
00:03:21,102 --> 00:03:30,729
反例是第一个参数就要求写五百行代码补丁，正例是先写文件路径，再写改动类型，最后才写具体内容。

37
00:03:30,729 --> 00:03:34,059
第二条，格式贴近模型的训练数据。

38
00:03:34,059 --> 00:03:43,470
模型在训练时见过大量自然语言和常见代码格式，参数格式越接近这些熟悉的模式，它越不容易出错。

39
00:03:43,470 --> 00:03:54,155
反例是用一套自定义的描述语法去描述文件变更，正例是用标准的差异对比格式，那是它在训练数据里见过无数次的东西。

40
00:03:54,155 --> 00:03:57,256
第三条，避免不必要的格式开销。

41
00:03:57,256 --> 00:04:01,727
不要让模型去做数行数、做转义这类机械操作。

42
00:04:01,727 --> 00:04:06,378
它不擅长精确计数，强迫它做只会增加出错概率。

43
00:04:06,378 --> 00:04:14,023
反例是要求它给出精确的行号范围，正例是用一段唯一的上下文字符串去匹配目标位置。

44
00:04:14,023 --> 00:04:22,268
第四条是防呆设计，这个理念源自丰田的生产系统，意思是通过改变设计让错误更难发生。

45
00:04:22,268 --> 00:04:27,136
与其期望模型不犯错，不如让工具本身就不容易用错。

46
00:04:27,136 --> 00:04:35,922
反例是参数接受相对路径，模型经常搞错当前目录；正例是只接受绝对路径，从源头消除歧义。

47
00:04:35,922 --> 00:04:38,842
一个真实案例很能说明问题。

48
00:04:38,842 --> 00:04:51,751
在某个公开的软件工程评测集里，把编辑文件的参数从相对路径改成绝对路径，代码量改动极小，但效果巨大，从频繁出错变成几乎完美。

49
00:04:51,751 --> 00:04:56,931
一个参数的改动，就让整个智能体的可靠性大幅提升。

50
00:04:56,931 --> 00:04:59,347
这就是防呆的力量。

51
00:04:59,490 --> 00:05:01,903
工具描述怎么才算好。

52
00:05:01,853 --> 00:05:08,079
业界有个很实用的比方，像给一个聪明但没有上下文的初级开发者写文档。

53
00:05:08,079 --> 00:05:14,606
这个人理解力很强，但对你的项目一无所知，你需要把所有前提条件都告诉他。

54
00:05:14,606 --> 00:05:17,899
一份好的描述应该包含五样东西。

55
00:05:17,899 --> 00:05:22,971
第一是示例用法，给出具体的输入输出样例，让它一看就会。

56
00:05:22,971 --> 00:05:28,356
第二是边界情况说明，输入为空怎么办，找不到结果返回什么。

57
00:05:28,356 --> 00:05:34,858
第三是输入格式要求，日期用标准格式还是时间戳，路径用绝对还是相对。

58
00:05:34,858 --> 00:05:44,305
第四是和其他工具的区别，比如用搜索代码这个工具搜代码内容，用搜索文件这个工具搜文件名，别搞混。

59
00:05:44,305 --> 00:05:54,101
第五是什么时候不该用，如果只需要检查文件是否存在，就用检查存在的工具，读取内容的工具留给真正要读内容的场景。

60
00:05:54,101 --> 00:05:55,988
对比一下就清楚了。

61
00:05:55,988 --> 00:05:59,029
差的描述只有一句，搜索东西。

62
00:05:59,029 --> 00:06:05,315
模型不知道搜什么，不知道参数格式，也分不清和其他搜索工具的差别。

63
00:06:05,315 --> 00:06:18,320
好的描述会写清楚，在代码仓库里按规则搜索代码，返回匹配的文件路径和行号，如果要匹配文件名请改用另一个工具，并且附上一个完整的调用示例。

64
00:06:18,320 --> 00:06:22,803
名称精确、描述清晰、有示例、有边界说明。

65
00:06:22,803 --> 00:06:25,591
这里有个可以直接套用的模板。

66
00:06:25,591 --> 00:06:38,668
某工具用于某种具体用途，当你需要场景甲或者场景乙时使用它，不要在场景丙时使用，那种情况请用另一个工具代替，最后附上一个具体的输入输出示例。

67
00:06:38,668 --> 00:06:42,539
把这段模板填满，描述基本就及格了。

68
00:06:42,690 --> 00:06:45,356
再看一个具体的封装案例。

69
00:06:45,306 --> 00:06:56,424
企业知识库可以封成一个检索工具，让智能体自己判断什么时候需要查内部资料，工具只负责检索，智能体负责基于返回结果组织答案。

70
00:06:56,424 --> 00:06:58,924
一次完整的调用是这样的。

71
00:06:58,924 --> 00:07:04,056
智能体判断这个问题涉及内部知识，于是调用检索工具。

72
00:07:04,056 --> 00:07:14,705
工具把问题编码成向量，带上权限过滤去向量库里检索，然后返回相关片段、来源和匹配分数，注意，它不直接编答案。

73
00:07:14,705 --> 00:07:20,955
最后智能体引用这些证据作答，证据不足时就明确说无法确认。

74
00:07:20,955 --> 00:07:23,130
这里有两个容易踩的坑。

75
00:07:23,130 --> 00:07:26,376
第一个是工具边界必须写进描述里。

76
00:07:26,376 --> 00:07:36,171
检索工具内部重新编码问题时，用的模型、预处理方式和维度必须和写入时完全一致，否则有结果不等于结果可信。

77
00:07:36,171 --> 00:07:39,885
第二个坑是知识和记忆不要混成一锅。

78
00:07:39,885 --> 00:07:48,611
企业知识是审核过的制度、产品文档和常见问题，按文档版本更新，权限由组织和角色决定。

79
00:07:48,611 --> 00:07:57,626
用户记忆是个人偏好、历史选择和任务状态，必须按用户标识强制过滤，还要可查看、可删除、设保留期。

80
00:07:57,626 --> 00:08:03,779
两者的来源、权限、保留期和质量门槛都不一样，至少要分开存储。

81
00:08:03,779 --> 00:08:07,457
验收的时候必须同时测调用和不调用。

82
00:08:07,457 --> 00:08:14,140
问一句企业版退款审批要几级，它应该调用检索工具并且回答里带引用。

83
00:08:14,140 --> 00:08:19,957
问一句十七乘八等于多少，它不应该调用工具，直接答一百三十六。

84
00:08:19,957 --> 00:08:27,361
再问一个超出权限的问题，它应该如实说明没有权限或者没有证据，而不是编一个答案。

85
00:08:27,361 --> 00:08:36,315
好的智能体不是每题都搜索，而是在需要企业知识时才调用，并且把检索结果当证据，而不是当最终答案。

86
00:08:36,315 --> 00:08:39,308
再补充一句关于评测的细节。

87
00:08:39,308 --> 00:08:49,741
测试不该调用这一类问题，其实比测试该调用更重要，因为多查一次顶多是浪费，而该查的时候不查，给出的就是凭记忆编出来的答案。

88
00:08:49,741 --> 00:08:55,835
这三类问题应该做成固定的回归集，每次改动工具描述都跑一遍。

89
00:08:55,990 --> 00:08:59,605
接下来是一个反直觉但极其有效的设计。

90
00:08:59,555 --> 00:09:07,825
智能体在执行长工具链的时候，经常忘记前面的信息，或者在需要同时权衡多条规则时犯错。

91
00:09:07,825 --> 00:09:11,947
解决办法很简单，给它一个停下来想一想的工具。

92
00:09:11,947 --> 00:09:13,846
什么是思考工具。

93
00:09:13,846 --> 00:09:25,373
它是一个没有副作用的特殊工具，不查数据库、不调接口、不改任何状态，唯一的作用就是让智能体把思考过程写下来，强迫自己想清楚再行动。

94
00:09:25,373 --> 00:09:28,029
它和深度思考有什么区别。

95
00:09:28,029 --> 00:09:34,339
深度思考发生在生成回复之前，适合需要一次性想清楚的复杂推理。

96
00:09:34,339 --> 00:09:43,245
而思考工具发生在执行过程中，允许它随时暂停，适合需要中途整理信息、重新评估策略的长链场景。

97
00:09:43,245 --> 00:09:48,834
一个是开头想好再一路执行，一个是边做边想、步步为营。

98
00:09:48,834 --> 00:09:54,904
为什么要包装成一个工具，而不是在系统提示词里写一句请先想清楚。

99
00:09:54,904 --> 00:10:00,902
因为在工具调用模式下，思考和调用工具是两种不同的输出格式。

100
00:10:00,902 --> 00:10:08,894
把思考包装成一个工具调用，能让它在工具链的流程中自然地插入一段思考，保持调用节奏。

101
00:10:08,894 --> 00:10:11,010
效果有数据支撑。

102
00:10:11,010 --> 00:10:20,577
在一个模拟真实客服场景的评测基准上，航空客服场景提升了百分之五十四，零售客服场景提升了百分之十一。

103
00:10:20,577 --> 00:10:32,500
注意航空场景的幅度，因为航空退改签政策远比零售复杂，不同舱位、不同时段、不同会员等级，策略密度越高，这个工具的价值越大。

104
00:10:32,500 --> 00:10:40,421
还要提醒一句，长链任务里真正稀缺的不是信息，而是它在中途停下来整理信息的能力。

105
00:10:40,421 --> 00:10:47,921
调用的工具越多，前面的关键结果越容易被后面的大量内容淹没，这个暂停就越值钱。

106
00:10:47,921 --> 00:10:50,565
但也不是所有场景都该加。

107
00:10:50,565 --> 00:10:57,127
适用的是复杂工具链、策略密集环境、串行依赖决策、多轮信息聚合。

108
00:10:57,127 --> 00:11:06,647
不适用的是简单的一步到位调用、各步骤相互独立的任务、已经用了深度思考的简单场景，以及纯生成类任务。

109
00:11:06,647 --> 00:11:16,839
二零二五年十二月业界进一步明确了分工，简单任务直接用深度思考，思考工具的真正价值在于长链路中的中途暂停。

110
00:11:16,839 --> 00:11:21,731
还有个细节值得记住，思考工具的实现简单到令人惊讶。

111
00:11:21,731 --> 00:11:32,752
它就是一个只接受一段文字、什么都不做的工具，描述里写清楚它不会获取新信息、不会改变任何状态，只是把这段思考追加到日志里。

112
00:11:32,752 --> 00:11:38,882
就这么几行定义，换来的却是长链任务上准确率的显著变化。

113
00:11:39,020 --> 00:11:42,683
工具写得好不好，智能体自己最有发言权。

114
00:11:42,633 --> 00:11:47,754
业界已经验证了一套工作流，让它自己来当工具的产品经理。

115
00:11:47,754 --> 00:11:55,698
传统方式是人类写工具、人类测试、人类改进，周期长、反馈慢、还依赖开发者的直觉。

116
00:11:55,698 --> 00:11:58,054
新的方式是三步循环。

117
00:11:58,054 --> 00:12:04,316
第一步快速生成原型，描述你想要的功能，让它生成工具的代码框架。

118
00:12:04,316 --> 00:12:11,287
第二步建立评测体系，系统化度量表现，关键是要有数据，光看起来能用不算数。

119
00:12:11,287 --> 00:12:18,992
第三步让它读评测结果，自动分析失败原因并改进描述和实现，不满意就重复循环。

120
00:12:18,992 --> 00:12:28,054
评测要看四个维度，它有没有选对工具，参数填得对不对，返回结果有没有被正确理解，端到端的任务完成率如何。

121
00:12:28,054 --> 00:12:39,593
这个循环的关键洞察在于，跑完评测之后，它能精确地说出有多少比例的错误是因为混淆了两个相似的工具，然后自动重写描述去解决。

122
00:12:39,593 --> 00:12:42,429
这比人类凭直觉调试快得多。

123
00:12:42,429 --> 00:12:44,953
还有五条设计原则要记住。

124
00:12:44,953 --> 00:12:47,922
第一，选对工具，少即是多。

125
00:12:47,922 --> 00:12:53,331
如果两个工具的使用场景有百分之五十以上重叠，就合并它们。

126
00:12:53,331 --> 00:12:58,415
如果连人类开发者都分不清该用哪个，智能体也一定分不清。

127
00:12:58,415 --> 00:13:01,804
第二，命名空间，用前缀分组。

128
00:13:01,804 --> 00:13:11,311
这个价值很直观，当它看到一组带同一前缀的工具时，立刻知道这些工具操作的是同一个系统，选错的概率大幅下降。

129
00:13:11,311 --> 00:13:19,725
反过来，一堆零散的名字，比如创建任务、列出条目、更新状态，既看不出归属，也看不出关系。

130
00:13:19,725 --> 00:13:27,453
第三，返回有意义的上下文，不要只回一个成功状态，要把它下一步需要的信息一起返回。

131
00:13:27,453 --> 00:13:41,347
第四，追求词元效率，大量结果要精简，返回十条核心字段加一个总数和翻页提示，远比返回八百四十七条完整记录有用，后者要吃掉五万二千词元，它根本处理不过来。

132
00:13:41,347 --> 00:13:48,727
第五，把工具描述当成提示词的一部分来写，尤其要写清楚什么时候不该用。

133
00:13:48,880 --> 00:13:53,156
最后给你一份可以马上用的判断清单，一共五条。

134
00:13:53,106 --> 00:13:56,953
第一条，把工具当成智能体的用户界面。

135
00:13:56,953 --> 00:14:04,320
传统接口是确定性的，智能体工具是非确定性的，它需要自己判断什么时候用、怎么用。

136
00:14:04,320 --> 00:14:08,864
名字、参数、描述写含糊了，执行一定走样。

137
00:14:08,864 --> 00:14:12,169
第二条，设计工具记住四条原则。

138
00:14:12,169 --> 00:14:26,267
给足思考空间，先写简单参数再写复杂参数；格式贴近模型熟悉的样子；别让它做数行数这类机械操作；用防呆设计让错误更难发生，比如只接受绝对路径。

139
00:14:26,267 --> 00:14:32,169
第三条，工具描述要像给聪明但没上下文的初级开发者写文档。

140
00:14:32,169 --> 00:14:40,186
必须包含五样东西，示例用法、边界情况、格式要求、和相邻工具的区别、以及什么时候不该用。

141
00:14:40,186 --> 00:14:44,392
第四条，封装检索类工具时守住两个边界。

142
00:14:44,392 --> 00:14:56,700
知识和记忆要分开存，权限和保留期都不一样；验收时必须同时测该调用和不该调用两类问题，证据不足时要如实说无法确认，而不是编一个。

143
00:14:56,700 --> 00:15:01,243
第五条，用评测驱动工具迭代，而不是凭直觉。

144
00:15:01,243 --> 00:15:12,590
走生成原型、建立评测、自动优化的循环，配合少即是多、命名空间、有意义的返回、精简词元、工程化描述这五条原则。

145
00:15:12,590 --> 00:15:19,272
最后提醒一句，工具设计和提示词设计不是两件事，而是同一件事的两面。

146
00:15:19,272 --> 00:15:25,294
描述本身就是提示词的一部分，参数结构本身就是交互流程的一部分。

147
00:15:25,294 --> 00:15:31,027
把它们放在一起考虑，而不是分给两个人分别优化，效果会好得多。

148
00:15:31,027 --> 00:15:36,027
这五条的共同点是，工具质量决定智能体的能力上限。

149
00:15:36,027 --> 00:15:41,892
它不会自己变聪明，你能给它什么样的工具，它就能做到什么样的事。