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

2
00:00:06,382 --> 00:00:10,985
这一集要解决的是从演示到产品之间差的那一步。

3
00:00:10,985 --> 00:00:22,163
你在台上看到一个智能体跑得行云流水，回到自己工位上照着做，却发现只要任务稍微复杂一点，它就卡住、跑偏、或者把钱烧光。

4
00:00:22,163 --> 00:00:27,235
差的不是模型能力，差的是分工、权限、连接这三件事。

5
00:00:27,235 --> 00:00:29,567
为什么产品经理要关心。

6
00:00:29,567 --> 00:00:33,064
因为这三件事没有一件是纯技术问题。

7
00:00:33,064 --> 00:00:41,802
一个智能体够不够用，要你来判断；它做错了谁来负责，要你来定义；它该接哪些外部能力，要你来取舍。

8
00:00:41,802 --> 00:00:47,079
这些决定的总和，就是聊天套壳和真正产品之间的距离。

9
00:00:47,079 --> 00:00:57,211
课程里有一句话说得很重，做人工智能产品最难的不是调接口，难的是在用户看不见的地方做出一百个正确的产品决策。

10
00:00:57,211 --> 00:01:04,927
用户看到的只是冰山一角，一个聊天框、几次回复，水面之下是你要做的那一百个决策。

11
00:01:04,927 --> 00:01:13,245
这一集就是在帮你把其中最重要的十几个决策点过一遍，每一个都能直接落到你的产品评审会上。

12
00:01:13,400 --> 00:01:19,563
先说一个反直觉的结论，不是越多智能体越好，大多数时候一个就够了。

13
00:01:19,513 --> 00:01:24,862
很多团队一上手就设计一堆角色，结果协调成本比收益还大。

14
00:01:24,862 --> 00:01:28,348
真正需要分工的，只有三种场景。

15
00:01:28,348 --> 00:01:30,283
第一种是并行加速。

16
00:01:30,283 --> 00:01:39,742
真实案例是新闻简报，用户要整理今天的人工智能新闻，一个智能体要依次搜索五个网站，总耗时二十五秒。

17
00:01:39,742 --> 00:01:47,398
改成五个子智能体同时去搜，每个负责一个来源，最后主智能体汇总，总耗时五秒。

18
00:01:47,398 --> 00:01:51,845
关键在于这些搜索互不干扰，天然适合并行。

19
00:01:51,845 --> 00:01:54,033
第二种是角色分工。

20
00:01:54,033 --> 00:01:56,376
真实案例是代码审查。

21
00:01:56,376 --> 00:02:04,333
让同一个智能体写完代码再审自己的代码，它很难发现自己的错误，就像自己检查自己的作文。

22
00:02:04,333 --> 00:02:08,336
分成两个，一个写代码，一个审代码。

23
00:02:08,336 --> 00:02:15,523
审查的那一方不知道写代码的那一方在想什么，只看最终产物，反而更容易发现问题。

24
00:02:15,523 --> 00:02:18,251
角色隔离让审查真正有效。

25
00:02:18,251 --> 00:02:20,403
第三种是风险隔离。

26
00:02:20,403 --> 00:02:28,119
真实案例是复杂文档处理，主智能体在整理一份五十页的报告，其中需要解析几个附件。

27
00:02:28,119 --> 00:02:35,908
如果附件解析出错，格式损坏或者超时，直接在主智能体里做会导致整个任务崩溃。

28
00:02:35,908 --> 00:02:46,004
分出一个子智能体单独处理附件，成功了就汇报结果，失败了就报一句这个文件有问题，主智能体继续工作不受影响。

29
00:02:46,004 --> 00:02:49,634
所以加第二个之前，先问自己三个问题。

30
00:02:49,634 --> 00:02:54,718
一个智能体真的做不到吗，很多时候只是提示词没写好。

31
00:02:54,718 --> 00:03:05,932
增加的复杂度值得吗，更多智能体意味着更多协调成本和更多出错可能，你要维护的不再是一条链路，而是好几条链路之间的交接。

32
00:03:05,932 --> 00:03:12,302
有没有更简单的方案，比如用工具并行调用就能解决，不必真的分智能体。

33
00:03:12,302 --> 00:03:20,187
只有并行加速、角色制衡、风险隔离这三种明确需求时，才值得把复杂度加上去。

34
00:03:20,340 --> 00:03:24,352
决定要分多个之后，下一个问题是谁能同时跑。

35
00:03:24,302 --> 00:03:29,062
这里有一条非常清晰的界线，看可以并行，改必须排队。

36
00:03:29,062 --> 00:03:31,309
只读的操作可以并行。

37
00:03:31,309 --> 00:03:42,896
搜索网页、读取文件、查询接口、数据分析、数据库查询、读取笔记，这些操作不修改任何东西，十个智能体同时搜索也不会冲突。

38
00:03:42,896 --> 00:03:44,891
写操作必须串行。

39
00:03:44,891 --> 00:03:59,110
写入文件、发送邮件、执行命令、删除资源、支付操作、编辑笔记，这些操作会改变外部状态，两个智能体同时改同一个文件，结果就是数据覆盖、内容丢失。

40
00:03:59,110 --> 00:04:03,990
判断规则只有一句话，这个操作执行完，世界有没有变。

41
00:04:03,990 --> 00:04:07,499
没变就可以并行，变了就必须排队。

42
00:04:07,499 --> 00:04:15,047
补充一点，两个写操作如果改的是不同的东西，不同的文件、不同的数据表，也可以并行。

43
00:04:15,047 --> 00:04:19,218
冲突只发生在多个操作修改同一个资源的时候。

44
00:04:19,218 --> 00:04:24,867
课程里给了一组时间线对比，同一个任务是三次搜索加一次写入。

45
00:04:24,867 --> 00:04:32,848
三次搜索并行、写入排在最后，总耗时大约四秒；所有操作依次执行，总耗时大约八秒。

46
00:04:32,848 --> 00:04:38,220
所以设计多智能体系统的第一步，是把工具分成读和写两类。

47
00:04:38,220 --> 00:04:41,321
这一步做对了，并行才有意义。

48
00:04:41,321 --> 00:04:51,514
反过来说，如果你的任务里大部分是写操作，那么并行带来的收益会非常有限，你加再多的智能体也只是把排队的时间拉长而已。

49
00:04:51,514 --> 00:04:57,066
这个判断要在动手之前做，不要等系统搭起来才发现快不起来。

50
00:04:57,200 --> 00:05:00,443
第三种玩法不是分工，是让它们吵。

51
00:05:00,393 --> 00:05:05,813
和人类开会一样，一个人想到死，不如多个人独立思考再汇总。

52
00:05:05,813 --> 00:05:14,071
脑暴模式就是把同一个问题扔给多个智能体，让它们各自回答，最后由主持人整合共识与分歧。

53
00:05:14,071 --> 00:05:17,003
课程里有一个很具体的例子。

54
00:05:17,003 --> 00:05:19,924
问题是如何提高用户留存率。

55
00:05:19,924 --> 00:05:28,902
产品视角那一方说，优化新手引导流程，减少首日流失，增加个性化推荐，让用户更快找到价值。

56
00:05:28,902 --> 00:05:37,424
数据视角那一方说，分析流失节点数据，第三天和第七天是关键，建议针对这两个节点设计召回策略。

57
00:05:37,424 --> 00:05:45,837
用户视角那一方说，用户反馈最多的是不知道能干什么，功能并不少，核心问题是价值传递不到位。

58
00:05:45,837 --> 00:05:56,715
主持人整合出来的结果是，两条共识，核心问题是价值传递，用户没感受到产品能帮他什么；新手引导是最高优先级改进点。

59
00:05:56,715 --> 00:06:05,417
两条分歧，用数据驱动还是用户访谈来确定改进方向，先做个性化推荐还是先简化核心流程。

60
00:06:05,417 --> 00:06:10,176
分歧本身就是产出，说明这个问题值得更深入讨论。

61
00:06:10,176 --> 00:06:14,215
为什么比一个智能体想到底更好，有四条理由。

62
00:06:14,215 --> 00:06:18,590
避免思维定式，一个智能体会沿着一条线想下去。

63
00:06:18,590 --> 00:06:23,121
发现盲区，它想不到的东西另一个可能正好擅长。

64
00:06:23,121 --> 00:06:29,768
分歧即价值，三个意见一致说明方向明确，有分歧说明值得深挖。

65
00:06:29,768 --> 00:06:35,970
还有并行高效，三个同时思考，总时间等于最慢那一个，不会翻三倍。

66
00:06:35,970 --> 00:06:42,773
这里有一条硬性要求，每个智能体必须独立思考，不能看到其他智能体的答案。

67
00:06:42,773 --> 00:06:46,967
就像人类脑暴的规则，先各自写，再一起讨论。

68
00:06:46,967 --> 00:06:52,508
如果后一个能看到前一个的答案，它会被带偏，脑暴就失去意义了。

69
00:06:52,508 --> 00:07:01,547
主持人的角色也很关键，它不负责再想一遍，只负责提炼共识、标注分歧，把分歧原样交给人类去决策。

70
00:07:01,690 --> 00:07:05,233
接下来说一个能让你月账单差十倍的选择。

71
00:07:05,183 --> 00:07:09,246
让智能体每小时整理一次新闻，听起来很简单。

72
00:07:09,246 --> 00:07:15,784
但如果复用旧会话，上下文每次都在增长，二十四小时之后成本会爆炸。

73
00:07:15,784 --> 00:07:18,597
课程把这个过程算得很清楚。

74
00:07:18,597 --> 00:07:22,215
第一次执行，上下文约等于两千词元。

75
00:07:22,215 --> 00:07:24,883
第二次执行，约等于四千。

76
00:07:24,883 --> 00:07:27,202
第十次，约等于两万。

77
00:07:27,202 --> 00:07:30,147
第二十四次，约等于四万八千。

78
00:07:30,147 --> 00:07:34,114
而每一次请求，你都要为这些历史词元付费。

79
00:07:34,114 --> 00:07:36,638
换成每次新建会话呢。

80
00:07:36,638 --> 00:07:41,938
第二十四次的成本和第一次一模一样，因为不带任何历史上下文。

81
00:07:41,938 --> 00:07:49,270
而定时任务本来也不需要记忆，每次整理当前的新闻就够了，不需要知道昨天整理过什么。

82
00:07:49,270 --> 00:08:01,710
课程里做了一个成本计算器，可以拖动运行天数去看两条曲线的差距，跑的天数越多，复用会话那一条翘得越厉害，到后面几乎是直着往上走。

83
00:08:01,710 --> 00:08:07,094
所以结论非常干脆，定时任务每次新建会话，别复用旧的。

84
00:08:07,094 --> 00:08:10,904
这个一个选择之差，可以让月账单差十倍。

85
00:08:10,904 --> 00:08:17,623
而且新建会话不只是便宜，还更稳定，因为你不依赖上一次留下了什么状态。

86
00:08:17,770 --> 00:08:19,282
再来说权限。

87
00:08:19,232 --> 00:08:22,285
给全部权限，它可能搞砸一切。

88
00:08:22,285 --> 00:08:25,109
每一步都审批，用户会疯掉。

89
00:08:25,109 --> 00:08:31,311
权限设计是一条光谱，从完全自主到每步审批，中间还有三种选择。

90
00:08:31,311 --> 00:08:34,040
怎么选，取决于三个维度。

91
00:08:34,040 --> 00:08:38,198
操作的可逆性，发消息不可逆，读文件可逆。

92
00:08:38,198 --> 00:08:42,922
出错的代价，删除数据代价高，搜索信息代价低。

93
00:08:42,922 --> 00:08:47,189
用户的信任度，新用户谨慎，老用户信任。

94
00:08:47,189 --> 00:08:52,069
同一个产品里，不同功能完全可以用不同的权限模式。

95
00:08:52,069 --> 00:08:54,749
弹窗是这里最典型的矛盾。

96
00:08:54,749 --> 00:09:00,782
如果智能体每做一步都弹窗让你确认，你点五次允许之后就想卸载了。

97
00:09:00,782 --> 00:09:05,939
但如果什么都不问就自己执行，删错了文件谁来负责。

98
00:09:05,939 --> 00:09:07,850
答案是风险分级。

99
00:09:07,850 --> 00:09:18,932
低风险自动执行，读取文件、搜索信息、查看日历、格式化文本，这些操作不改变任何状态，出错也没有代价，不需要弹窗。

100
00:09:18,932 --> 00:09:27,573
高风险必须确认，删除文件、发送消息、执行支付、修改权限，这些操作不可逆或者影响大。

101
00:09:27,573 --> 00:09:31,011
那谁来判断一个操作是高危还是低危。

102
00:09:31,011 --> 00:09:43,691
三条路，产品经理在设计阶段预定义，最常用；让智能体根据上下文自己判断，更灵活但不一定准；让用户自己设置，最灵活但增加配置成本。

103
00:09:43,691 --> 00:09:50,674
好的权限设计不是要不要弹窗的二选一，它是对什么时候弹、弹什么的精细控制。

104
00:09:50,674 --> 00:09:56,155
而本质上，它在回答一个产品问题，这件事出错了，谁来负责。

105
00:09:56,155 --> 00:10:05,482
课程里还提醒了一句，同一个产品里不同功能可以用不同的权限模式，不要为了一致性给所有操作定同一个档位。

106
00:10:05,482 --> 00:10:09,436
一致性是给界面用的，不是给风险用的。

107
00:10:09,590 --> 00:10:16,114
智能体在后台跑了三分钟，调了几个工具，花了多少词元，中间有没有出错。

108
00:10:16,064 --> 00:10:20,643
如果你回答不了这些问题，你的智能体就是个黑盒。

109
00:10:20,643 --> 00:10:34,465
课程里展示了一张模拟仪表盘，一份执行报告里至少要有这些项，总耗时、循环次数、工具调用次数、总词元消耗、执行时间线、工具调用统计、词元消耗分布。

110
00:10:34,465 --> 00:10:37,975
为什么需要可观测性，两边都有理由。

111
00:10:37,975 --> 00:10:47,014
对开发者，它用来定位智能体在哪一步出了问题，发现无效循环和浪费掉的词元，优化工具调用链路。

112
00:10:47,014 --> 00:10:55,090
对产品经理，它用来理解用户真实的使用路径，量化每一个功能的成本，为下一版迭代提供数据。

113
00:10:55,090 --> 00:10:58,588
不看日志你永远不知道它出了什么错。

114
00:10:58,588 --> 00:11:07,038
一个没有仪表盘的智能体，就像一辆没有仪表盘的车，你不知道油量，不知道转速，不知道什么时候会抛锚。

115
00:11:07,038 --> 00:11:11,701
可观测性不是给工程师的玩具，它是产品化的基本功。

116
00:11:11,701 --> 00:11:22,602
尤其对于产品经理，词元消耗分布这一项几乎是刚需，它能告诉你用户真正在用的到底是哪一个功能，而不是你以为的那一个。

117
00:11:22,770 --> 00:11:24,102
再说连接。

118
00:11:24,052 --> 00:11:30,614
大多数人以为模型上下文协议就是让智能体调外部工具，但它其实是双向的。

119
00:11:30,614 --> 00:11:42,657
作为客户端，也就是消费者这一侧，它连接外部服务去调用别人提供的能力，日历、邮件、数据库、浏览器，主动发起请求，获取外部能力。

120
00:11:42,657 --> 00:11:57,721
作为服务端，也就是提供者这一侧，它把自己的能力通过同一套协议暴露出去，被外部调用，被编程工具调用，被桌面端调用，被自动化脚本定时触发，被动接收请求，提供自身能力。

121
00:11:57,721 --> 00:11:59,873
为什么双向很重要。

122
00:11:59,873 --> 00:12:04,921
单向集成只是工具调用，跟普通接口没有本质区别。

123
00:12:04,921 --> 00:12:09,645
双向集成意味着它不仅能用工具，还能成为工具。

124
00:12:09,645 --> 00:12:15,077
当多个智能体都能互相调用的时候，一个生态就自然形成了。

125
00:12:15,077 --> 00:12:18,094
这是从工具到平台的关键跨越。

126
00:12:18,094 --> 00:12:21,291
落地的时候还有一个细节叫懒连接。

127
00:12:21,291 --> 00:12:28,070
你注册了十个服务，启动时全部连接一遍，如果其中三个超时，启动就卡住三十秒。

128
00:12:28,070 --> 00:12:31,688
懒连接的思路很简单，注册不等于连接。

129
00:12:31,688 --> 00:12:39,224
启动时只声明我有哪些工具可用，不实际建立网络连接，等第一次真正需要某个工具时再连。

130
00:12:39,224 --> 00:12:43,803
这样故障也被隔离了，某个服务挂了只影响那一个工具。

131
00:12:43,803 --> 00:12:50,774
课程给的真实数据是，启动从三十秒降到零点二秒，用户感受到的是秒开。

132
00:12:50,774 --> 00:12:54,116
更激进一点，还能让它自己加工具。

133
00:12:54,116 --> 00:12:57,962
用户说帮我查日历，但你还没配日历工具。

134
00:12:57,962 --> 00:13:04,344
传统做法是报错说不支持，更好的做法是它自己去配，问你一声就行。

135
00:13:04,344 --> 00:13:19,560
三个设计要点，能力发现，它得知道有哪些工具可以加；用户授权，它不能偷偷连接新服务，必须明确告知并等你同意；即时生效，配完就能用，不用重启，当前对话无缝继续。

136
00:13:19,560 --> 00:13:22,998
敏感数据的工具要有更严格的审批。

137
00:13:22,998 --> 00:13:27,241
这一下把门槛从会配置降到了会说话。

138
00:13:27,380 --> 00:13:31,116
最后是这一集可以带走的清单，一共五条。

139
00:13:31,066 --> 00:13:34,251
第一条，先别急着加第二个智能体。

140
00:13:34,251 --> 00:13:43,409
只有并行加速、角色制衡、风险隔离这三种明确需求时才值得引入，其余时候多半是提示词没写好。

141
00:13:43,409 --> 00:13:46,630
第二条，把工具分成读和写两类。

142
00:13:46,630 --> 00:13:53,193
只读的可以并行，写操作必须排队，判断规则是执行完之后世界有没有变。

143
00:13:53,193 --> 00:13:56,558
第三条，定时任务每次新建会话。

144
00:13:56,558 --> 00:14:04,203
复用旧会话会让上下文滚雪球，第二十四次就到了四万八千词元，一个选择差十倍成本。

145
00:14:04,203 --> 00:14:08,373
第四条，权限用风险分级，不要用一刀切。

146
00:14:08,373 --> 00:14:15,945
低风险自动执行，高风险必须确认，先想清楚出错之后谁负责，再决定弹不弹窗。

147
00:14:15,945 --> 00:14:19,599
第五条，上线之前先把仪表盘做出来。

148
00:14:19,599 --> 00:14:26,727
总耗时、循环次数、工具调用、词元消耗这四项看不见，你的智能体就是黑盒。

149
00:14:26,727 --> 00:14:29,912
最后留一个可以今天就动手的作业。

150
00:14:29,912 --> 00:14:34,106
让它从会说变成会做，只需要接上一个真工具。

151
00:14:34,106 --> 00:14:54,747
一次工具调用的完整闭环只有四段，模型开口要，输出一段结构化文本说明调哪个工具、参数是什么；框架校验参数，不合法就打回重来；真实执行，这一步才碰真实世界；结果回喂，把执行结果塞回对话，让模型消化之后再组织成人话。

152
00:14:54,747 --> 00:15:01,478
四段里最容易被忘掉的是第四段，少了它，用户看到的就是一坨原始文本。

153
00:15:01,478 --> 00:15:11,346
挑工具记住三个标准，高频、低风险、输入输出清楚，挑不出来就选搜索我的某某资料，它几乎适配所有场景。

154
00:15:11,346 --> 00:15:21,009
然后把描述写成三行，什么时候该用以及什么时候不该用，每个参数的含义格式和示例值，返回什么以及拿到之后怎么用。

155
00:15:21,009 --> 00:15:28,269
跑通一次完整闭环之后，故意搞一次破坏，问一个参数含糊的问题，看它卡在第几段。

156
00:15:28,269 --> 00:15:33,257
卡死那一条记录最值钱，下一章的评测就从它开始。