1
00:00:00,100 --> 00:00:02,105
你好，欢迎收听。

2
00:00:02,105 --> 00:00:08,617
前面几集我们一直在讲范式，讲智能体怎么思考、怎么规划、怎么反思。

3
00:00:08,617 --> 00:00:14,723
这一集拐个弯，讲一个更底层、也更能决定成败的东西，上下文。

4
00:00:14,723 --> 00:00:24,110
本内容改编自 Datawhale《Hello-Agents：从零开始构建智能体》，采用 CC BY-NC-SA 4.0 授权，为二次演绎配音版。

5
00:00:24,110 --> 00:00:32,968
授权再说一遍，本内容改编自 Datawhale《Hello-Agents》，采用 CC BY-NC-SA 4.0 授权，为二次演绎配音版。

6
00:00:32,968 --> 00:00:34,975
为什么说它更底层。

7
00:00:34,975 --> 00:00:43,257
因为前面讲的那些范式，跑起来之后都会遇到同一个问题，信息越滚越多，模型越来越不聚焦。

8
00:00:43,257 --> 00:00:48,425
范式决定了智能体怎么走，上下文决定了它每一步能看到什么。

9
00:00:48,425 --> 00:00:51,262
看错了，走得再对也白搭。

10
00:00:51,262 --> 00:00:52,872
我们开始。

11
00:00:53,020 --> 00:01:01,431
在经历了数年提示工程成为应用型人工智能的焦点之后，一个新的术语走到了台前，上下文工程。

12
00:01:01,431 --> 00:01:13,917
如今用语言模型构建系统，不再只是找对提示词里的句式和措辞，而是要回答一个更宏观的问题，什么样的上下文配置，最有可能让模型产出我们期望的行为。

13
00:01:13,917 --> 00:01:19,939
所谓上下文，指的是在对模型进行采样时所包含的那组词元。

14
00:01:19,939 --> 00:01:27,920
手头的工程问题，是在模型固有约束之下，优化这些词元的效用，以便稳定地得到预期结果。

15
00:01:27,920 --> 00:01:40,155
想有效驾驭模型，往往需要「在上下文中思考」，也就是说，在任何一次调用时，都要审视模型可见的整体状态，并预判这种状态可能诱发的行为。

16
00:01:40,155 --> 00:01:44,013
上下文工程和提示工程是什么关系？

17
00:01:44,013 --> 00:01:46,597
可以看成一个自然的演进。

18
00:01:46,597 --> 00:01:55,155
提示工程关注如何编写与组织模型的指令以获得更优结果，比如系统提示的写法与结构化策略。

19
00:01:55,155 --> 00:01:58,028
它回答的是，这句话该怎么说。

20
00:01:58,028 --> 00:02:09,133
上下文工程则是在推理阶段，如何策划与维护最优的信息集合，其中不仅包含提示本身，还包含其他会进入上下文窗口的一切信息。

21
00:02:09,133 --> 00:02:12,847
它回答的是，这次调用，该让它看见什么。

22
00:02:12,847 --> 00:02:22,150
在早期阶段，提示往往是主要工作，因为大多数用例都是针对单轮分类或文本生成做精调式的提示优化。

23
00:02:22,150 --> 00:02:37,659
但随着我们开始工程化地构建更强的智能体，它们要在更长的时间范围内、跨多次推理轮次地工作，我们就需要能管理整个上下文状态的策略，其中包括系统指令、工具、外部数据、消息历史等等。

24
00:02:37,659 --> 00:02:47,250
关键点在这里，一个循环运行的智能体，会不断产生下一轮推理可能相关的数据，这些信息必须被周期性地提炼。

25
00:02:47,250 --> 00:02:57,070
所以上下文工程的技艺，在于从持续扩张的候选信息宇宙里，甄别哪些内容该进入那个有限的上下文窗口。

26
00:02:57,220 --> 00:03:01,376
接下来回答一个核心问题，为什么这事儿这么重要。

27
00:03:01,376 --> 00:03:11,819
尽管模型速度越来越快、能处理的数据规模越来越大，但我们观察到一个现象，模型和人类一样，到某个点上会走神或者混乱。

28
00:03:11,819 --> 00:03:17,420
有一类叫大海捞针的基准测试，揭示了一个现象，上下文腐蚀。

29
00:03:17,420 --> 00:03:24,355
随着上下文窗口里的词元增加，模型从上下文里准确回忆信息的能力反而下降。

30
00:03:24,355 --> 00:03:31,182
不同模型的退化曲线或许更平滑，但这一特征几乎在所有模型上都会出现。

31
00:03:31,182 --> 00:03:36,386
所以上下文必须被视作一种有限资源，而且边际收益递减。

32
00:03:36,386 --> 00:03:41,735
就像人类有有限的工作记忆容量一样，模型也有一笔注意力预算。

33
00:03:41,735 --> 00:03:50,100
每新增一个词元，都会消耗这笔预算的一部分，因此我们必须谨慎地筛选哪些词元应该被提供进去。

34
00:03:50,100 --> 00:03:54,475
这种稀缺不是偶然的，它源自模型的架构约束。

35
00:03:54,475 --> 00:04:03,165
主流架构让每个词元都能与上下文中的所有词元建立关联，理论上形成 n 的平方级别的两两注意力关系。

36
00:04:03,165 --> 00:04:13,922
随着上下文长度增长，模型对这些两两关系的建模能力会被拉薄，于是在上下文规模和注意力集中度之间产生了天然的张力。

37
00:04:13,922 --> 00:04:25,593
另外，模型的注意力模式来源于训练数据的分布，短序列通常比长序列更常见，所以模型对全上下文依赖的经验更少、专门参数也更少。

38
00:04:25,593 --> 00:04:35,124
像位置编码插值这类技术，可以让模型在推理时适配比训练期更长的序列，但会牺牲一部分对位置的精确理解。

39
00:04:35,124 --> 00:04:41,326
综合起来，这些因素形成的不是一个悬崖式的崩溃，而是一个性能梯度。

40
00:04:41,326 --> 00:04:49,644
模型在长上下文下依旧强大，但相比短上下文，在信息检索与长程推理上的精度会有所下降。

41
00:04:49,644 --> 00:05:00,088
这一点很重要，因为它意味着问题不会以报错的形式暴露出来，而是以悄悄退化的形式出现，等你发现的时候往往已经跑了很久。

42
00:05:00,088 --> 00:05:06,507
基于这个现实，有意识的上下文工程就成了构建强健智能体的必需品。

43
00:05:06,652 --> 00:05:16,794
在有限注意力预算的约束下，优秀上下文工程的目标是，用尽可能少、但高信号密度的词元，最大化获得期望结果的概率。

44
00:05:16,794 --> 00:05:20,626
落实到实践，我们围绕几个组件来做建设。

45
00:05:20,626 --> 00:05:22,429
先说系统提示。

46
00:05:22,429 --> 00:05:27,874
要求很直白，语言清晰、直白，信息层级把握在刚刚好的高度。

47
00:05:27,874 --> 00:05:30,614
这里有两个常见的两极误区。

48
00:05:30,614 --> 00:05:32,729
一个是过度硬编码。

49
00:05:32,729 --> 00:05:39,220
在提示里写入复杂、脆弱的条件判断逻辑，长期维护成本高、易碎。

50
00:05:39,220 --> 00:05:47,705
你以为你在写程序，其实你在写一段模型可能不遵守的伪代码，而且它还会随着业务变化不断腐化。

51
00:05:47,705 --> 00:05:49,713
另一个是过于空泛。

52
00:05:49,713 --> 00:05:57,285
只给宏观目标和泛化指引，缺少对期望输出的具体信号，或者假定了错误的共享上下文。

53
00:05:57,285 --> 00:06:01,624
模型不知道你脑子里那个默认前提，你不说它就猜。

54
00:06:01,624 --> 00:06:10,650
建议的做法是把提示分区组织，比如分成角色、约束、工具指引、输出描述等区块，用分隔标记隔开。

55
00:06:10,650 --> 00:06:16,323
不管用什么格式，追求的是能完整勾勒期望行为的最小必要信息集。

56
00:06:16,323 --> 00:06:22,297
注意，最小不等于最短，有些信息省掉了反而要花更多词元去纠偏。

57
00:06:22,297 --> 00:06:31,900
一个好用的方法是，先用最好的模型在最小提示上试跑，看它怎么失败，再依据失败模式增补清晰的指令与示例。

58
00:06:31,900 --> 00:06:37,850
别一上来就把提示写成长篇大论，那是把失败模式提前埋进去。

59
00:06:37,996 --> 00:06:39,424
再说工具。

60
00:06:39,424 --> 00:06:48,929
工具定义了智能体与信息和行动空间的契约，必须促进效率，既要返回词元友好的信息，又要鼓励高效的智能体行为。

61
00:06:48,929 --> 00:06:51,513
好的工具应当满足三点。

62
00:06:51,513 --> 00:06:55,948
第一，职责单一、相互低重叠，接口语义清晰。

63
00:06:55,948 --> 00:07:00,756
第二，对错误鲁棒，出错时不崩、能给出可读的反馈。

64
00:07:00,756 --> 00:07:06,994
第三，入参描述明确无歧义，充分发挥模型擅长的表达与推理能力。

65
00:07:06,994 --> 00:07:15,383
最常见的失败模式是臃肿工具集，功能边界模糊，导致「选哪个工具」这个决策本身就含混不清。

66
00:07:15,383 --> 00:07:24,867
这里有一条特别实在的判断标准，如果人类工程师都说不准这种情况该用哪个工具，就别指望智能体能做得更好。

67
00:07:24,867 --> 00:07:32,523
所以精心甄别出一个最小可行工具集，往往能显著提升长期交互中的稳定性和可维护性。

68
00:07:32,523 --> 00:07:40,359
工具不是越多越好，每多一个工具，就多一份描述要占用注意力预算，也多一次选错的机会。

69
00:07:40,516 --> 00:07:44,468
第三个组件是示例，也就是常说的少样本。

70
00:07:44,468 --> 00:07:50,728
始终推荐提供示例，但不建议把所有边界条件的罗列一股脑塞进提示。

71
00:07:50,728 --> 00:07:55,872
请精挑细选一组多样且典型的示例，直接刻画期望行为。

72
00:07:55,872 --> 00:07:59,610
对模型来说，好的示例胜过千言万语。

73
00:07:59,610 --> 00:08:01,726
为什么示例这么有效？

74
00:08:01,726 --> 00:08:06,293
因为它绕开了「用语言描述你想要什么」这个天然有损的环节。

75
00:08:06,293 --> 00:08:13,721
你写一段规则，模型要理解、推断、再执行；你给两个例子，它直接照着样子做。

76
00:08:13,721 --> 00:08:20,596
尤其是那些你很难用语言说清的风格、粒度、详略程度，一个例子就能定住。

77
00:08:20,596 --> 00:08:24,178
总的指导思想是四个字，充分且紧致。

78
00:08:24,178 --> 00:08:27,363
信息要够用，但不能注水。

79
00:08:27,508 --> 00:08:31,159
讲完静态的组件，我们讲动态的检索。

80
00:08:31,159 --> 00:08:37,131
先给一个简洁的定义，智能体就是在循环中自主调用工具的模型。

81
00:08:37,131 --> 00:08:46,013
随着底层模型能力增强，智能体的自治水平就可以提升，更能独立探索复杂问题空间，并从错误中恢复。

82
00:08:46,013 --> 00:08:51,650
工程实践正在从「推理前一次性检索」逐步过渡到「即时上下文」。

83
00:08:51,650 --> 00:09:02,948
后者不再预先加载所有相关数据，而是维护轻量化引用，比如文件路径、存储查询、链接，在运行时通过工具动态加载所需数据。

84
00:09:02,948 --> 00:09:14,751
这样做的好处是，模型可以撰写针对性的查询、缓存必要结果，用按需读取的方式分析大体量数据，而不用把整块数据一次性塞进上下文。

85
00:09:14,751 --> 00:09:24,475
它的认知模式更贴近人类，我们不会死记硬背全部信息，而是用文件系统、收件箱、书签这些外部索引按需提取。

86
00:09:24,475 --> 00:09:29,727
除了存储效率，引用的元数据本身也能帮助精化行为。

87
00:09:29,727 --> 00:09:35,448
目录层级、命名约定、时间戳，都在隐含地传达目的与时效。

88
00:09:35,448 --> 00:09:46,434
举个具体的例子，测试目录下一个叫工具测试的文件，和核心源码目录下一个同名的文件，它们给模型传达的语义暗示是不一样的。

89
00:09:46,434 --> 00:09:51,037
让智能体自主导航与检索，还能实现渐进式披露。

90
00:09:51,037 --> 00:10:01,182
每一步交互都产生新的上下文，反过来指导下一步决策，文件大小暗示复杂度，命名暗示用途，时间戳暗示相关性。

91
00:10:01,182 --> 00:10:13,333
智能体得以按层构建理解，只在工作记忆里保留当前必要的子集，并用记笔记的方式做补充持久化，从而维持聚焦，而不是被大而全拖垮。

92
00:10:13,333 --> 00:10:15,208
代价也要说清楚。

93
00:10:15,208 --> 00:10:23,982
运行时探索往往比预计算检索更慢，而且需要有主见的工程设计来确保模型拥有正确的工具与启发式。

94
00:10:23,982 --> 00:10:32,203
如果缺少引导，智能体可能会误用工具、追逐死胡同或者错过关键信息，造成上下文浪费。

95
00:10:32,203 --> 00:10:42,227
在不少场景里，混合策略更有效，前置加载少量高价值上下文保证速度，然后允许智能体按需继续自主探索。

96
00:10:42,227 --> 00:10:46,807
边界怎么选，取决于任务的动态性和时效要求。

97
00:10:46,807 --> 00:10:57,840
比如可以预先放一份项目约定说明，同时提供按名匹配、按内容搜索这些原语，让智能体即时检索具体文件，绕开过时索引的坑。

98
00:10:57,988 --> 00:11:00,702
最后一节讲长时程任务。

99
00:11:00,702 --> 00:11:09,065
它要求智能体在超出上下文窗口的长序列行动中，仍然保持连贯性、上下文一致与目标导向。

100
00:11:09,065 --> 00:11:13,344
比如大型代码库迁移、跨数小时的系统性研究。

101
00:11:13,344 --> 00:11:23,224
指望无限增大上下文窗口并不能根治上下文污染和相关性退化，所以需要直接面向这些约束的工程手段，一共三招。

102
00:11:23,224 --> 00:11:25,291
第一招是压缩整合。

103
00:11:25,291 --> 00:11:34,702
当对话接近上下文上限时，对它做高保真总结，并用这个摘要重启一个新的上下文窗口，以维持长程连贯性。

104
00:11:34,702 --> 00:11:49,811
实践上，让模型压缩并保留架构性决策、未解决缺陷、实现细节，丢弃重复的工具输出与噪声；新窗口携带压缩摘要，再加上最近少量高相关工件，比如最近访问过的若干文件。

105
00:11:49,811 --> 00:11:57,863
调参上有个顺序建议，先优化召回，确保不遗漏关键信息，再优化精确度，剔除冗余内容。

106
00:11:57,863 --> 00:12:03,380
一种安全的轻触式压缩，是先清理深历史里的工具调用与结果。

107
00:12:03,380 --> 00:12:07,202
第二招是结构化笔记，也叫智能体记忆。

108
00:12:07,202 --> 00:12:14,642
智能体以固定频率把关键信息写到上下文之外的持久化存储里，后续阶段按需拉回。

109
00:12:14,642 --> 00:12:20,267
它的价值是以极低的上下文开销维持持久状态和依赖关系。

110
00:12:20,267 --> 00:12:32,587
比如维护一份待办清单、一份项目笔记、一份关键结论与阻塞项的索引，跨数十次工具调用和多轮上下文重置，仍能保持进度与一致性。

111
00:12:32,587 --> 00:12:35,772
这招在非编码场景同样有效。

112
00:12:35,772 --> 00:12:38,164
第三招是子代理架构。

113
00:12:38,164 --> 00:12:51,253
由主代理负责高层规划与综合，多个专长子代理在干净的上下文窗口里各自深挖、调用工具、探索，最后只回传凝练摘要，常见是一千到两千个词元。

114
00:12:51,253 --> 00:13:02,214
好处是关注点分离，庞杂的搜索上下文留在子代理内部，主代理专注整合与推理，适合需要并行探索的复杂研究分析任务。

115
00:13:02,214 --> 00:13:03,344
怎么选？

116
00:13:03,344 --> 00:13:05,351
三条经验法则。

117
00:13:05,351 --> 00:13:10,592
压缩整合适合需要长对话连续性的任务，强调上下文的接力。

118
00:13:10,592 --> 00:13:15,928
结构化笔记适合有里程碑、有阶段性成果的迭代式开发与研究。

119
00:13:15,928 --> 00:13:21,613
子代理架构适合复杂研究与分析，能从并行探索中获益。

120
00:13:21,748 --> 00:13:24,570
讲完方法，我们说代价和边界。

121
00:13:24,570 --> 00:13:29,520
第一，上下文工程的收益很难量化，但代价很实在。

122
00:13:29,520 --> 00:13:38,450
你花在筛选和提炼上的工程投入，不会像加一个功能那样看得见成果，但它决定了后面所有功能的稳定性。

123
00:13:38,450 --> 00:13:43,643
这块欠的债，会在长任务和复杂任务上连本带利还回来。

124
00:13:43,643 --> 00:13:47,236
第二，别把上下文窗口当成硬盘。

125
00:13:47,236 --> 00:13:52,152
它是一个昂贵、有限、会随长度退化注意力的工作台。

126
00:13:52,152 --> 00:13:56,035
能放在外面按需取的，就别常驻在里面。

127
00:13:56,035 --> 00:13:59,123
第三，压缩和笔记不是免费的。

128
00:13:59,123 --> 00:14:03,054
压缩会丢信息，笔记要花调用去写和读。

129
00:14:03,054 --> 00:14:07,657
什么时候压缩、记什么、多久记一次，都要按任务调。

130
00:14:07,657 --> 00:14:11,587
先保召回再保精确度，这个顺序别反。

131
00:14:11,587 --> 00:14:16,023
第四，自治度越高，越需要主见的工程引导。

132
00:14:16,023 --> 00:14:24,989
你给智能体越多自由度，就要配套给越明确的启发式和工具约束，否则它会把注意力预算浪费在死胡同里。

133
00:14:24,989 --> 00:14:30,025
好，我们把这一集收一下，给你几条能直接带走的判断依据。

134
00:14:30,025 --> 00:14:32,801
第一，记住两个问题的分野。

135
00:14:32,801 --> 00:14:39,616
提示工程问的是这句话该怎么说，上下文工程问的是这次调用该让它看见什么。

136
00:14:39,616 --> 00:14:47,056
后者包含系统指令、工具、外部数据、消息历史等一切会进入上下文窗口的信息。

137
00:14:47,056 --> 00:14:51,095
第二，上下文是有限资源且有边际收益递减。

138
00:14:51,095 --> 00:14:59,099
上下文腐蚀意味着词元越多，回忆能力反而越差；底层原因是架构上两两注意力关系被拉薄。

139
00:14:59,099 --> 00:15:04,664
退化是性能梯度，不是悬崖，所以它不会报错，只会悄悄变差。

140
00:15:04,664 --> 00:15:09,496
第三，三个静态组件分别是系统提示、工具、示例。

141
00:15:09,496 --> 00:15:24,688
系统提示要避开过度硬编码和过于空泛两个极端，追求最小必要信息集；工具要职责单一、错误鲁棒、入参明确，警惕臃肿工具集；示例要精挑细选，好的示例胜过千言万语。

142
00:15:24,688 --> 00:15:34,424
第四，动态检索的趋势是从一次性预加载转向即时上下文，维护轻引用、运行时按需加载，实现渐进式披露。

143
00:15:34,424 --> 00:15:38,510
它更慢，但更省、更贴近人类的认知方式。

144
00:15:38,510 --> 00:15:42,080
实际项目里混合策略往往更稳。

145
00:15:42,080 --> 00:15:48,402
第五，长时程任务的三招是压缩整合、结构化笔记、子代理架构。

146
00:15:48,402 --> 00:15:55,049
分别对应需要对话连续性、有里程碑的迭代开发、以及能并行探索的复杂研究。

147
00:15:55,049 --> 00:15:57,188
这一集我们就到这里。

148
00:15:57,188 --> 00:16:01,347
下一集我们继续讲上下文工程里的具体机制。

149
00:16:01,347 --> 00:16:04,340
感谢你的收听，我们下期见。