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

2
00:00:06,382 --> 00:00:12,680
这一集要解决的，是一个几乎所有团队都会踩的坑，一上来就搭框架。

3
00:00:12,680 --> 00:00:22,463
你看到别人家的智能体跑得漂亮，回头就找了一个框架开始搭，结果延迟上去了、成本上去了、出问题还查不到在哪一步。

4
00:00:22,463 --> 00:00:30,372
这一集给出的答案是，先搞清楚你要的是预定义流程还是模型自主决策，再决定要不要上复杂度。

5
00:00:30,372 --> 00:00:32,704
为什么产品经理要关心。

6
00:00:32,704 --> 00:00:35,625
因为复杂度是成本，不是功能。

7
00:00:35,625 --> 00:00:48,978
你每多引入一层编排，就要多付一层延迟、多付一层调用费用、多付一层调试难度，而这些都是你没法在需求文档里写清楚、却会在上线之后天天还债的东西。

8
00:00:48,978 --> 00:00:56,706
更麻烦的是，复杂度一旦加上去就很难拆下来，它会长进架构里，也会长进团队的心智里。

9
00:00:56,706 --> 00:01:06,730
这一集还会给你两套能直接用的工具，一套是复杂度阶梯，用来决定要不要上；一套是五种编排模式，用来决定上哪一种。

10
00:01:06,730 --> 00:01:15,564
听完这一集，你应该能在评审会上问出那句最关键的话，这个复杂度带来的收益，值得它额外的代价吗。

11
00:01:15,720 --> 00:01:17,869
先分清两个概念。

12
00:01:17,819 --> 00:01:30,055
预定义流程，是模型和工具通过写好的代码路径编排起来的，开发者在写代码的时候就决定了执行顺序，先做第一步，再做第二步，最后做第三步。

13
00:01:30,055 --> 00:01:34,754
关键词是确定性、可预测、开发者控制流程。

14
00:01:34,754 --> 00:01:45,307
智能体呢，是模型动态决定自己的执行流程和工具使用，它在每一步自主判断下一步做什么、要不要调用工具、什么时候结束。

15
00:01:45,307 --> 00:01:50,079
关键词是自主性、动态决策、模型控制流程。

16
00:01:50,079 --> 00:01:52,615
两个维度对比下来很清楚。

17
00:01:52,615 --> 00:01:56,918
控制权一个在开发者手里，一个在模型手里。

18
00:01:56,918 --> 00:02:04,610
可预测性一个高，输入确定则输出路径基本确定；一个低，同样的输入可能走出不同的路。

19
00:02:04,610 --> 00:02:10,511
成本一个可控，调用次数是固定的；一个不确定，循环次数未知。

20
00:02:10,511 --> 00:02:16,449
调试难度一个低，路径确定容易复现；一个高，行为不确定难以复现。

21
00:02:16,449 --> 00:02:20,019
这里要特别说一句什么时候不要用智能体。

22
00:02:20,019 --> 00:02:22,819
大多数情况下你不需要它。

23
00:02:22,819 --> 00:02:30,487
实践反复验证的规律是，对大多数应用场景，优化单次调用再配上检索增强就够了。

24
00:02:30,487 --> 00:02:37,458
常见的过度设计是，用一个框架去做本质上一次提问加一次搜索就能解决的事。

25
00:02:37,458 --> 00:02:42,879
框架引入的延迟、成本、不确定性，远大于它带来的收益。

26
00:02:42,879 --> 00:02:48,672
判断的时候可以抓住一个信号，你能不能把这件事的步骤提前写下来。

27
00:02:48,672 --> 00:02:53,684
写得清楚，说明流程是确定的，用预定义流程就够了。

28
00:02:53,684 --> 00:03:01,569
写不清楚，每一步都得看上一步的结果才知道下一步是什么，这时候才轮到智能体登场。

29
00:03:01,700 --> 00:03:10,087
既然复杂度是成本，那就要有一把尺子，让团队在动手之前有共同的判断依据，而不是各凭感觉。

30
00:03:10,037 --> 00:03:13,955
课程里给了一个复杂度阶梯，从下往上四级。

31
00:03:13,955 --> 00:03:20,926
最下面一级是单次调用，先把提问优化好，加上少样本示例，调一调温度参数。

32
00:03:20,926 --> 00:03:25,374
不够用，往上加检索增强，让它能访问外部知识。

33
00:03:25,374 --> 00:03:31,035
还不够，再上预定义流程，把任务拆成多步，用代码控制流程。

34
00:03:31,035 --> 00:03:36,732
真的需要灵活决策了，才上智能体，让模型自主规划执行。

35
00:03:36,732 --> 00:03:45,482
每往上爬一级，你都要问一句，这一级的复杂度带来的收益，值不值得额外的延迟、成本和调试难度。

36
00:03:45,482 --> 00:03:55,746
行业里有句话值得每个产品经理背下来，最成功的实现往往不是用复杂框架搭出来的，而是用简单可组合的模式搭出来的。

37
00:03:55,746 --> 00:04:01,912
这句话反过来也成立，最失败的实现，往往是一开始就选了最复杂的那个。

38
00:04:01,912 --> 00:04:05,662
这套阶梯还有一个用法，就是用来复盘。

39
00:04:05,662 --> 00:04:11,527
已经上线的功能如果效果不好，先别急着加东西，往下退一级看看。

40
00:04:11,527 --> 00:04:22,573
很多时候问题不在能力不够，而在层级选错了，你在一个只需要单次调用的场景上跑着一个完整的循环，当然又慢又贵又不稳。

41
00:04:22,720 --> 00:04:31,684
如果确定要用预定义流程，业界已经验证有效的有五种模式，由简到繁，不追求最复杂，追求最合适。

42
00:04:31,634 --> 00:04:33,365
第一种是提示链。

43
00:04:33,365 --> 00:04:39,711
把一个大任务拆成多个顺序步骤，上一步的输出直接作为下一步的输入。

44
00:04:39,711 --> 00:04:43,773
每一步都是一次独立的调用，专注做好一件事。

45
00:04:43,773 --> 00:04:49,014
步骤之间还可以插入质量门，只有通过检查才进入下一步。

46
00:04:49,014 --> 00:04:56,970
适用场景是任务能自然拆解成固定步骤、需要在中间做质量检查、愿意用准确度换延迟。

47
00:04:56,970 --> 00:05:07,872
真实例子是生成营销文案，再翻译为目标语言，再格式化为特定平台样式，中间那道门检查文案里有没有包含品牌关键信息。

48
00:05:07,872 --> 00:05:09,579
第二种是路由。

49
00:05:09,579 --> 00:05:14,314
先对输入做分类，然后导向不同的专门处理分支。

50
00:05:14,314 --> 00:05:19,110
每个分支可以有独立的提示词、模型甚至工具配置。

51
00:05:19,110 --> 00:05:24,747
核心价值是关注点分离，让每个分支只处理一种类型的输入。

52
00:05:24,747 --> 00:05:32,343
适用场景是输入类型多样、不同类型需要完全不同的处理逻辑，或者是需要成本优化。

53
00:05:32,343 --> 00:05:44,795
真实例子很典型，客服系统里简单常见问题用又快又便宜的小模型，退款相关的用强模型加订单工具，技术故障的用强模型加日志查询。

54
00:05:44,795 --> 00:05:50,781
一个分类器决定走哪条路，成本与效果就同时有了最优解。

55
00:05:50,920 --> 00:05:52,841
第三种是并行化。

56
00:05:52,791 --> 00:05:57,839
让多次调用同时执行再聚合结果，它有两种子模式。

57
00:05:57,839 --> 00:06:10,435
一种是拆分并行，把一个任务拆成独立子任务并行处理后合并，比如代码审查里一个查安全漏洞、一个查性能问题、一个查代码风格，最后汇总所有发现。

58
00:06:10,435 --> 00:06:22,634
另一种是多次投票，同一个任务用相同的提示词跑多次，取多数或者最佳结果，比如内容审核里同一段文本让三个判断分别过一遍，取多数意见。

59
00:06:22,634 --> 00:06:28,656
适用场景是子任务之间没有依赖、需要提速、或者需要提升置信度。

60
00:06:28,656 --> 00:06:31,120
第四种是编排者加工人。

61
00:06:31,120 --> 00:06:36,264
由一个中心模型动态拆解任务并分配给多个工人模型。

62
00:06:36,264 --> 00:06:46,396
它和并行化的区别在于，子任务是在运行时由编排者动态决定的，代码里没有预先定义，所以这是最接近智能体的那一种。

63
00:06:46,396 --> 00:06:49,858
适用场景是子任务不能提前预知。

64
00:06:49,858 --> 00:07:04,802
真实例子是给项目加国际化支持，编排者分析完代码库之后动态决定，第一个工人改按钮组件，第二个改页头组件，第三个创建语言文件，不同需求会产生不同数量和类型的工人。

65
00:07:04,802 --> 00:07:07,170
第五种是评估加优化。

66
00:07:07,170 --> 00:07:17,446
一个负责生成，另一个负责评判，两者形成迭代循环，生成者根据反馈不断改进，直到评判者满意或者达到迭代上限。

67
00:07:17,446 --> 00:07:24,778
适用场景是有明确的质量评估标准、迭代能显著提升质量、单次生成很难达标。

68
00:07:24,778 --> 00:07:36,460
真实例子是文学翻译，先做初步翻译，再检查信达雅和风格一致性并给出具体修改建议，然后据此改进，循环两三次之后输出终稿。

69
00:07:36,460 --> 00:07:43,359
一句话收口，从最简单的提示链开始，只在确认简单方案不够用时才升级。

70
00:07:43,500 --> 00:07:45,974
接下来是一个观念的升级。

71
00:07:45,924 --> 00:07:52,137
当我们从单轮对话走向多步智能体，仅仅优化提示词已经远远不够了。

72
00:07:52,137 --> 00:07:58,676
真正的挑战是，每一轮推理时送给模型的全部词元，你是怎么策展的。

73
00:07:58,676 --> 00:08:05,070
过去的提示词工程，关注的是怎么写指令，措辞、结构、少样本示例。

74
00:08:05,070 --> 00:08:11,825
现在的上下文工程，关注的是模型的输入窗口里放什么、怎么放、放多少。

75
00:08:11,825 --> 00:08:25,371
当你的系统里有系统提示词、工具定义、外部服务描述、对话历史、检索结果、用户偏好，这些加在一起可能占满大半个窗口，怎么管理它们就是上下文工程。

76
00:08:25,371 --> 00:08:28,207
为什么它重要，有三条理由。

77
00:08:28,207 --> 00:08:36,897
第一条叫上下文衰减，上下文越长，模型对信息的检索准确率越低，关键信息被淹没在海量的词元里。

78
00:08:36,897 --> 00:08:45,082
第二条是注意力预算有限，每一个词元都在消耗预算，无关的词元占位就等于有用的信息被稀释。

79
00:08:45,082 --> 00:08:49,962
第三条是平方级复杂度，词元数量翻倍，计算量变成四倍。

80
00:08:49,962 --> 00:08:57,450
课程里举的例子是，从五万扩展到十万，注意力计算量会变成原来的四倍，远超翻倍。

81
00:08:57,450 --> 00:09:05,058
所以上下文不是免费的，每多塞一个无关的词元，都在浪费其他词元本来能获得的注意力。

82
00:09:05,058 --> 00:09:11,861
这也是为什么有些团队把窗口从十万加到二十万之后，反而觉得模型变笨了。

83
00:09:11,861 --> 00:09:17,931
窗口变大了，但你塞进去的噪音也变多了，有效信息的密度反而下降。

84
00:09:17,931 --> 00:09:22,570
解决问题的方向不是继续加窗口，而是做减法。

85
00:09:22,720 --> 00:09:28,895
既然上下文是稀缺资源，目标就变成了找到最小的高信号词元集合。

86
00:09:28,845 --> 00:09:30,300
三个原则。

87
00:09:30,300 --> 00:09:34,074
第一个是系统提示词要找到合适的高度。

88
00:09:34,074 --> 00:09:41,093
太模糊，比如一句你是一个有用的助手，模型会缺乏方向感，输出泛泛而谈。

89
00:09:41,093 --> 00:09:49,663
太具体，比如列五十种边界情况加一百个案例，模型会被过度约束，遇到新情况就没法灵活处理。

90
00:09:49,663 --> 00:09:58,509
最佳实践是给出明确的角色定位和核心原则，大概五到十条，然后信任模型在这个框架下自主判断。

91
00:09:58,509 --> 00:10:02,764
像好的管理者一样，给方向，不给每一步的指令。

92
00:10:02,764 --> 00:10:05,360
第二个是工具集要精简。

93
00:10:05,360 --> 00:10:11,682
生产实践验证过一句话，如果人类都分不清该用哪个工具，模型也分不清。

94
00:10:11,682 --> 00:10:18,461
给它十个功能相似但描述模糊的工具，不如给五个职责清晰、命名精准的。

95
00:10:18,461 --> 00:10:25,540
每个工具的描述要像好的接口文档一样，让调用者一看就知道什么时候用、怎么用。

96
00:10:25,540 --> 00:10:29,314
第三个是少样本示例要精选，不要堆砌。

97
00:10:29,314 --> 00:10:34,446
示例是上下文里回报率最高的部分，但前提是选对了。

98
00:10:34,446 --> 00:10:41,586
正确做法是精选两三个最能代表目标行为的典型例子，覆盖最常见的输入模式。

99
00:10:41,586 --> 00:10:49,891
错误做法是堆砌十几个边界案例，不仅浪费词元，还会让模型过度关注异常情况而忽略主线。

100
00:10:49,891 --> 00:10:55,889
像编辑精修文章一样精修你的上下文，每一个多余的词都是噪音。

101
00:10:56,030 --> 00:10:58,167
最后是长任务怎么办。

102
00:10:58,117 --> 00:11:02,829
当任务跨越多个上下文窗口，每个新窗口都会失忆。

103
00:11:02,829 --> 00:11:12,684
开新窗口，它什么都不记得，会重复做已经做过的工作；继续在旧窗口工作，词元越来越多，注意力被稀释，表现下降。

104
00:11:12,684 --> 00:11:17,780
这不是理论问题，那些编程助手产品每天都在解决它。

105
00:11:17,780 --> 00:11:19,571
第一板斧是压缩。

106
00:11:19,571 --> 00:11:30,088
对话快要触达上限时，用一次调用对已有对话做摘要，保留关键信息，丢弃冗余细节，然后在压缩后的上下文上继续工作。

107
00:11:30,088 --> 00:11:37,504
关键决策是选择什么保留、什么丢弃，这是一个信息论问题，有些信息丢了就恢复不了。

108
00:11:37,504 --> 00:11:45,148
低风险的是清理旧的工具调用结果，比如文件列表、搜索输出，通常不影响后续推理。

109
00:11:45,148 --> 00:11:52,997
高风险的是丢弃架构决策的推理过程、未解决的缺陷描述，这些丢了它就会重蹈覆辙。

110
00:11:52,997 --> 00:12:05,305
还有一条实践建议，压缩出来的摘要要结构化，比如已完成是什么、未完成是什么、关键决策是什么、已知问题是什么，自由文本很难快速定位。

111
00:12:05,305 --> 00:12:07,901
第二板斧是结构化笔记。

112
00:12:07,901 --> 00:12:14,055
它在执行过程中主动把关键信息写到外部文件，不依赖对话历史。

113
00:12:14,055 --> 00:12:18,946
等上下文重置之后，再从笔记文件读回来恢复记忆。

114
00:12:18,946 --> 00:12:22,901
核心思想是把短期记忆外化为长期记忆。

115
00:12:22,901 --> 00:12:31,242
关键设计是笔记格式要固定且结构化，不能是自由散文，否则读回来还要额外花词元去理解笔记本身。

116
00:12:31,242 --> 00:12:43,814
它和压缩的区别是，压缩是压完继续用，笔记是存到外面以后取用，前者适合连续工作，后者适合可能被中断、需要跨会话延续的场景，两者可以组合。

117
00:12:43,814 --> 00:12:46,711
第三板斧是子智能体架构。

118
00:12:46,711 --> 00:13:00,256
主智能体把需要深入探索的子任务委派出去，子智能体在自己独立的上下文窗口里工作，可能消耗数万个词元，最终只返回一个一千到两千词元的精炼摘要。

119
00:13:00,256 --> 00:13:08,502
核心价值是关注点分离加上下文隔离，子智能体的工作草稿不会污染主智能体的上下文。

120
00:13:08,502 --> 00:13:23,854
一个很形象的类比是，一位负责人让三个部门经理分别去调研竞品、分析市场、评估技术，每个经理可能花了一周，但汇报上来的只有一页纸，负责人的认知带宽始终留在战略层面。

121
00:13:23,854 --> 00:13:27,628
还有一组配套选择，预加载还是按需获取。

122
00:13:27,628 --> 00:13:39,695
预加载是在对话开始时就先把信息塞进上下文，比如项目约定、核心规则、用户偏好，优点是即时可用，缺点是每次都占词元，不管这次用不用得到。

123
00:13:39,695 --> 00:13:50,789
按需获取是只在需要的时候才去检索，比如搜文件、查文档、取实时数据，优点是上下文保持精简，缺点是多一次调用的延迟。

124
00:13:50,789 --> 00:13:56,066
最佳实践是混合，高频信息预加载，长尾信息按需获取。

125
00:13:56,066 --> 00:14:04,719
类比一下就是浏览器缓存，热数据放内存，冷数据放磁盘，目标是让上下文的命中率最大化。

126
00:14:04,860 --> 00:14:08,620
最后留一份可以带走的清单，一共五条。

127
00:14:08,570 --> 00:14:11,130
第一条，先用最简方案。

128
00:14:11,130 --> 00:14:20,457
复杂度阶梯从单次调用起步，依次是检索增强、预定义流程、智能体，每爬一级都要问收益值不值得代价。

129
00:14:20,457 --> 00:14:24,219
大多数场景，一次提问加一次搜索就够了。

130
00:14:24,219 --> 00:14:27,380
第二条，分清控制权在谁手里。

131
00:14:27,380 --> 00:14:35,865
要确定性、要可预测、要成本可控，选预定义流程；任务开放、需要灵活决策，才考虑智能体。

132
00:14:35,865 --> 00:14:39,351
第三条，五种模式从提示链开始选。

133
00:14:39,351 --> 00:14:50,745
需要中间质检用提示链，输入类型多样用路由，子任务无依赖用并行，子任务无法预知用编排者加工人，有明确质量标准用评估加优化。

134
00:14:50,745 --> 00:14:53,510
不要一上来选最复杂的那个。

135
00:14:53,510 --> 00:14:57,560
第四条，把上下文当成稀缺资源来管理。

136
00:14:57,560 --> 00:15:03,558
系统提示词找中间的合适高度，工具集宁少勿滥，示例精选两三个。

137
00:15:03,558 --> 00:15:06,322
每一个多余的词元都是噪音。

138
00:15:06,322 --> 00:15:09,784
第五条，长任务先定策略再动手。

139
00:15:09,784 --> 00:15:20,072
连续不会被中断的用压缩，可能被中断或要跨会话的用结构化笔记，需要深度探索又不想污染主上下文的用子智能体。

140
00:15:20,072 --> 00:15:21,995
三者可以组合。

141
00:15:21,995 --> 00:15:27,007
这一集的核心其实只有一句话，复杂度是成本，不是功能。

142
00:15:27,007 --> 00:15:33,714
下次有人提议上框架的时候，先把这五条拿出来过一遍，再决定动不动手。