1
00:00:00,000 --> 00:00:09,800
欢迎回来。接下来又是一场精彩分享，主题深得我心——睡眠。

2
00:00:09,800 --> 00:00:19,050
欢迎 Anthropic 的 Lamis 上台。
请热烈欢迎下一位讲者！［掌声］

3
00:00:23,280 --> 00:00:32,200
大家好！很高兴今天见到各位，希望大家在 AI
DevCon 过得愉快。我就很开心。

4
00:00:32,200 --> 00:00:39,400
希望大家的上下文窗口还没装满，
还能容纳一点有关上下文的新知识。

5
00:00:39,400 --> 00:00:44,400
先介绍一下，我叫 Lamis，
是 Anthropic 的技术团队成员。

6
00:00:44,400 --> 00:00:51,360
我在应用 AI 团队工作，这个团
队介于研究、产品和市场拓展之间。

7
00:00:51,360 --> 00:00:58,640
我们既做内部项目，也直接与正在构建前沿智能体的客户合作。

8
00:00:58,640 --> 00:01:04,559
我主要服务初创公司和创始人，相信今天在座的就有不少。

9
00:01:04,559 --> 00:01:13,600
我觉得自己占据了最好的位置，因为这些用
户不断推动我们探索模型和产品的能力边界。

10
00:01:13,600 --> 00:01:20,760
因此，我们能一起乘上指数增长的浪潮。

11
00:01:20,760 --> 00:01:30,280
大家应该都知道，一个反复出现的问
题是：如何把现有模型的原始智能，

12
00:01:30,280 --> 00:01:43,600
转化为持久、可扩展且实用的产品？
其中一个关键手段就是上下文工程，也是今天的主题。

13
00:01:44,280 --> 00:01:54,520
我想先快速回顾上下文工程在过去一
年的发展。这个领域发展得非常迅猛。

14
00:01:54,520 --> 00:02:01,640
从中提炼出已被证明非常有用的基本
构件，也看看哪些做法效果相对有限。

15
00:02:01,640 --> 00:02:07,200
其次，我们会讨论当前最先进的记忆管理方法。

16
00:02:07,200 --> 00:02:16,680
第三，我们不仅谈漂亮的理论原则，
还会谈如何在生产环境中真正构建这些系统。

17
00:02:16,680 --> 00:02:25,880
最后，我们会讨论它如何走向持续学习，
特别是一种叫作 dreaming，也就是“做梦”的范式。

18
00:02:27,040 --> 00:02:35,360
我们之前说过：新模型不断发布，也越来越聪明。

19
00:02:35,360 --> 00:02:41,760
但当你把模型部署到自己的智能体、环境和组织中，

20
00:02:41,760 --> 00:02:49,400
光靠智能本身，并不会产生复利效应。
模型需要上下文，才能完成你交给它的具体任务。

21
00:02:49,400 --> 00:02:55,520
而且，这些上下文往往与模型本身的智能水平是两回事。

22
00:02:55,520 --> 00:03:05,400
比如我们刚发布的新模型，开箱即用时，
也不会知道如何在你的组织里成功完成那些任务。

23
00:03:05,400 --> 00:03:16,840
所以，投入上下文工程非常值得。随着时间推移，
即使模型不断变聪明，它也能进一步放大模型的智能。

24
00:03:16,840 --> 00:03:25,040
大家一定熟悉这些问题：智能体不熟
悉代码库，或者不了解你的个人偏好。

25
00:03:25,040 --> 00:03:33,239
此外，它第二次执行同一个任务时，也未必会做得更好。

26
00:03:33,239 --> 00:03:39,360
它可能无法从错误中学习，因此也就没有持续学习的效果。

27
00:03:39,360 --> 00:03:48,480
我们先回顾一下，上下文工程这条路目前走到了哪里。

28
00:03:48,480 --> 00:03:52,880
在 Anthropic，我们常说：用能奏效的简单办法。

29
00:03:52,880 --> 00:04:01,800
这条时间线其实只有过去一年。起点是随 Claude
Code 一起推出的 CLAUDE.md 文件。

30
00:04:01,800 --> 00:04:08,959
我们发现它的效果好得出乎意料。
一个 Markdown 文件，只需给智能体几条指令，

31
00:04:08,959 --> 00:04:14,080
介绍代码库、组织情况和你的个人偏好，

32
00:04:14,080 --> 00:04:20,799
在会话开始时放进模型上下文，
就能很好地引导它关注重要事项，

33
00:04:20,799 --> 00:04:25,880
帮助它熟悉环境，并让行为符合你的偏好。

34
00:04:25,880 --> 00:04:34,840
不过，我们也发现了这种做法的局限。
把这些内容在会话一开始就注入上下文，

35
00:04:34,840 --> 00:04:47,120
会带来上下文膨胀的问题：当这个包含重
要偏好的文件变得很长，该如何长期管理？

36
00:04:47,120 --> 00:04:50,880
于是我们重新思考，寻找改进方法。

37
00:04:50,880 --> 00:05:02,280
但有一点依然成立：一个简单、可供人阅读，
而且人和智能体都能写入的 Markdown 文件，非常有效。

38
00:05:02,280 --> 00:05:12,919
我们探索的第二条路线是记忆工具。
它很有意思，因为它提出了一个问题：

39
00:05:12,919 --> 00:05:22,800
如果让智能体自主管理自己的记忆系统，
会怎样？让它决定何时读取、写入和更新记忆。

40
00:05:22,800 --> 00:05:29,760
这些操作都在会话内进行，也就
是在同一次会话的上下文中完成。

41
00:05:29,760 --> 00:05:36,520
会话期间，智能体会考虑哪些信息值
得从记忆中提取，哪些值得写入记忆。

42
00:05:36,520 --> 00:05:41,880
在这种情况下，自主性被证明非常有效。

43
00:05:41,880 --> 00:05:50,840
后来，我们逐步发展出对工具形式预
设更少的系统。这一点我稍后会讲。

44
00:05:50,840 --> 00:05:57,040
这条路的下一站是 Skills，
也就是技能。相信大家今天已经听过很多了。

45
00:05:57,040 --> 00:06:07,280
它解决的是上下文不断增长的问题，
采用了一个很巧妙的理念：渐进式披露。

46
00:06:07,280 --> 00:06:15,960
先说技能擅长什么：它适合具有明确步骤的工作流程。

47
00:06:15,960 --> 00:06:21,960
也就是，你对流程从头到尾应如何执
行有自己的要求，希望智能体照着做。

48
00:06:21,960 --> 00:06:29,800
巧妙之处在于：加载技能之前，智
能体只看文件开头几句话的元数据。

49
00:06:29,800 --> 00:06:37,840
但在文件正文中，你仍然可以放入任意丰富的细节。

50
00:06:37,840 --> 00:06:41,240
这样既能保留深度，又不会塞满模型的上下文。

51
00:06:41,240 --> 00:06:50,400
我喜欢把它想象成房间里的书架。
每次有人跟我说话，我都可以扫一眼书单，

52
00:06:50,400 --> 00:06:57,560
看看有没有与谈话相关的书名，需要时再把那本书拿下来阅读。

53
00:06:57,560 --> 00:07:03,840
比如有人过来用法语跟我说话，而我看到
书架上有一本法语词典，就可以拿出来。

54
00:07:03,840 --> 00:07:07,600
这样，就能在对话过程中加载有帮助的上下文。

55
00:07:07,600 --> 00:07:14,200
不用先认真上完七年的法语课，把所有知识都预先装进上下文。

56
00:07:14,200 --> 00:07:18,360
所以，这是一个非常棒的创新。

57
00:07:18,360 --> 00:07:24,600
不过，它可能仍有一个瓶颈：技
能还是由人和智能体共同驱动的。

58
00:07:24,600 --> 00:07:32,840
即使让智能体与你一起编写技能，
你仍然需要较多地决定，哪些事情应该做成技能。

59
00:07:32,840 --> 00:07:39,815
这就到了这条路的最后一步，也就是
我们认为当前最先进的记忆系统形态。

60
00:07:39,815 --> 00:07:48,720
我们的做法，也就是我们认为的最佳实践，
是把记忆系统直接建模为文件系统。

61
00:07:48,720 --> 00:07:56,680
它汇集了前面的一些经验。文件系统很好，
你可以在里面存放 Markdown 文件。

62
00:07:56,680 --> 00:08:00,760
智能体也很擅长使用普通的文件系统工具，
比如 Bash 和 grep。

63
00:08:00,760 --> 00:08:08,760
因此，让它们直接搜索文件系统，
而不要预先规定它们必须用什么专用工具来读写记忆。

64
00:08:08,760 --> 00:08:14,919
这种搜索方式也呼应了渐进式披露的理念。
你可以给记忆系统建立完善的索引，

65
00:08:14,919 --> 00:08:22,160
让智能体能够智能地搜索它。这就是我们目前走到的阶段。

66
00:08:22,160 --> 00:08:29,360
再总结一下：Markdown 是很好的记忆读取格式。

67
00:08:29,360 --> 00:08:37,599
允许记忆规模增长，但要给智能体工具，
让它快速建立索引，搜索相关内容。

68
00:08:37,599 --> 00:08:42,599
最后，让智能体自主决定如何写入记忆。

69
00:08:42,599 --> 00:08:49,080
如果你照着构建这样的系统，它会很好用，
也会让你感受到持续学习的效果，

70
00:08:49,080 --> 00:08:55,000
因为智能体在你执行的具体任务上，会变得越来越好。

71
00:08:55,520 --> 00:09:04,640
不过，和所有事情一样，这个看起来很简洁的想法，
在扩展到生产环境时也会遇到问题。

72
00:09:04,640 --> 00:09:13,720
我们已经知道理论上什么方法有效
。但一旦要把它扩展到生产环境，

73
00:09:13,720 --> 00:09:23,120
让许多智能体同时协作，长时间
运行，代码库还可能越来越复杂，

74
00:09:23,120 --> 00:09:29,040
各种问题就开始出现。这些情况，我们在生产环境中一再遇到。

75
00:09:29,040 --> 00:09:37,360
举几个例子，启发大家思考：多个智能
体同时写入一个记忆文件，该怎么办？

76
00:09:37,360 --> 00:09:47,240
再想想，一个智能体遇到问题后，
决定修改所有其他智能体正在读取的组织级上下文。

77
00:09:47,240 --> 00:09:55,280
如果那里写错了，错误就会扩散到
所有智能体，后果可能非常严重。

78
00:09:55,280 --> 00:10:03,160
还有，人和智能体共同编辑记忆上
下文时，你该如何追踪发生了什么？

79
00:10:03,160 --> 00:10:12,040
最后，记忆当然也会过时。过去相关的内容，
今天可能已不适用，也可能一开始就写错了。

80
00:10:12,040 --> 00:10:19,800
甚至有人会恶意进行提示词注入，
诱导智能体把不良内容写进记忆。

81
00:10:19,800 --> 00:10:28,600
所以，必须设置足够的防护措施，
这些自主记忆系统才能在生产环境中真正奏效。

82
00:10:29,600 --> 00:10:42,680
接下来，我会介绍我们设计生产环境记忆系统时
使用的几个关键原则，确保实现前面提到的好处。

83
00:10:42,680 --> 00:10:50,422
第一个原则是版本管理。设计任何
记忆系统时，都需要能够保存版本。

84
00:10:50,422 --> 00:10:58,240
这样才能追踪变化，并在新更新效果不佳时，按需回滚。

85
00:10:58,240 --> 00:11:08,960
此外，还要考虑这次更新依据了什么上下文：
是哪次智能体会话、哪份会话记录，促成了这次更新？

86
00:11:08,960 --> 00:11:15,720
你可能还想追踪是谁做了修改：哪个智能体、哪位用户，等等。

87
00:11:15,720 --> 00:11:19,640
这一点非常重要。第二个原则是并发。

88
00:11:19,640 --> 00:11:26,000
我们刚才谈过：如果部署上千个智能体，
共用同一个记忆系统，会发生什么？

89
00:11:26,000 --> 00:11:37,800
我们采用的方案是哈希校验。智能体
决定更新记忆时，先计算一次哈希值。

90
00:11:37,800 --> 00:11:50,683
然后起草修改，正式写入前再计算一次哈希。
如果两次不一致，就不能写入，因为期间已有其他更新。

91
00:11:50,683 --> 00:11:57,440
为了处理这种情况，智能体会重新获取记忆，
重新起草更新，然后再次尝试提交。

92
00:11:57,440 --> 00:12:07,480
这些工程实践，让你能够扩展多智能体架构，
并把记忆系统扩展到这样的架构中。

93
00:12:09,560 --> 00:12:15,240
还有几个关键原则。首先，权限管理非常重要。

94
00:12:15,240 --> 00:12:31,680
大型记忆库通常包含不同层级：顶层是全组织共享的知识，
比如组织目标或精心整理的代码库原则。

95
00:12:31,680 --> 00:12:40,160
底层则可能是单个智能体的草稿本，
用来记录工作记忆，内容非常个性化。

96
00:12:40,160 --> 00:12:44,480
中间还可以包含面向特定组织或不同群体的内容。

97
00:12:44,480 --> 00:12:50,320
所以，对这些记忆设置权限方面的防护措施非常重要。

98
00:12:50,320 --> 00:12:58,400
正如我刚才所说，你大概不希望某个智能体自
行决定更新组织级上下文，可以把它设为只读。

99
00:12:58,400 --> 00:13:08,000
但对于它自己的草稿本，你会希望
它拥有写入权限。这就是权限管理。

100
00:13:08,000 --> 00:13:17,440
最后一点虽然稍偏外围，但设计记
忆系统时仍然很重要：可移植性。

101
00:13:18,160 --> 00:13:33,520
未来，你对记忆系统的整理会非常重要。
这里包含组织、用户或具体任务所需的关键上下文。

102
00:13:33,520 --> 00:13:41,160
如果投入了大量精力整理这些信息，
你很可能希望多个产品入口都能访问它，

103
00:13:41,160 --> 00:13:52,000
也希望多个系统都能访问。所以，
要通过清晰的 API 来设计它，让它易于迁移和访问。

104
00:13:52,000 --> 00:14:00,840
把这些要素结合起来：一方面是允许智
能体自主、创造性地管理记忆的经验，

105
00:14:00,840 --> 00:14:08,200
另一方面是生产环境的防护措施，
让它们能在实际应用中合理运用这些原则。

106
00:14:08,200 --> 00:14:19,080
这样会带来很好的效果。我分享一些在生
产环境部署大型记忆系统时观察到的结果。

107
00:14:19,080 --> 00:14:34,880
比如准确率提高：第二次执行任务时，
智能体确实做得更好，因为它记下了之前哪里出了问题。

108
00:14:34,880 --> 00:14:43,080
其次，这又会影响运行速度和延
迟——抱歉，是运行速度和成本。

109
00:14:43,080 --> 00:14:49,760
它使用更少的 token，更容易一
次完成任务，因为它真正知道该怎么做。

110
00:14:49,760 --> 00:14:57,880
在各种不同流程中，你都能看到智能体把任务做得更好、更快。

111
00:14:57,880 --> 00:15:05,720
最后，智能体开始自主写入自己的
记忆，也能为你释放精力和注意力。

112
00:15:05,720 --> 00:15:15,240
作为产品开发者，你可以专注于产品成果，
同时知道智能体正在后台进行自我学习和持续学习。

113
00:15:15,240 --> 00:15:21,280
只要基础设施搭建得好，这两者就能很好地相互促进。

114
00:15:21,280 --> 00:15:31,240
不过，和往常一样，我们又遇到了新
的瓶颈。这次具体涉及会话内记忆。

115
00:15:31,240 --> 00:15:41,080
前面说过，会话内记忆是指智能体
在某一次会话中读取和写入记忆。

116
00:15:41,080 --> 00:15:51,440
以 Claude Code 为例，新建会话后，
它读写记忆时，主要关注的就是当前会话的具体上下文。

117
00:15:51,440 --> 00:16:02,480
从架构或理念上讲，这对于整个智能体群的
持续学习目标都有局限。主要有两个原因。

118
00:16:02,480 --> 00:16:06,960
首先，注意力和资源天然被分散了。

119
00:16:06,960 --> 00:16:17,160
你让智能体完成任务，同时又要求它投入
精力整理记忆，好让未来的自己表现更好。

120
00:16:17,160 --> 00:16:22,800
两件事放在一起，就成了一个很难优化的问题。

121
00:16:22,800 --> 00:16:29,839
智能体该把多少能力用来帮助未来的自己，
又该把多少用来完成你当前交给它的任务？

122
00:16:29,839 --> 00:16:33,440
此外，还有延迟等其他影响。

123
00:16:33,440 --> 00:16:43,920
第二，智能体的可见范围天然有限。
它只知道自己当前会话中发生的事情。

124
00:16:43,920 --> 00:16:50,400
因此，它看不到跨会话出现的模式。你可能很恼火，
因为它在不同会话中总犯同一个错误，

125
00:16:50,400 --> 00:16:56,400
但它并不理解你有多恼火，因为每次会话，
它面对的都是一个新的上下文窗口。

126
00:16:56,400 --> 00:17:06,480
而且，当多个智能体群在不同环境中运行时，
单个智能体也不了解其他智能体遇到了哪些失败。

127
00:17:06,480 --> 00:17:13,959
基于这两个原因，我们引入了会话外
记忆整理的概念，帮助解决这些问题。

128
00:17:13,959 --> 00:17:25,760
为了说明它在理论上为什么有效，我想打个比方：
想象一所学校，许多学生提交大量作业。

129
00:17:25,760 --> 00:17:31,800
老师负责批改，校长则审阅整体情况。

130
00:17:31,800 --> 00:17:42,600
现实世界中存在这样的制度是有原因的：
让特定的人投入专门精力帮助别人学习，非常有效。

131
00:17:42,600 --> 00:17:52,080
而且，有人能够看到整个智能体群，或者所有学习者的情况，
发现共同模式，再调整上下文——在学校里就是课程。

132
00:17:52,080 --> 00:18:00,520
这也非常有效。所以，和往常一样，
我们会参考现实世界，思考如何构建这些系统。

133
00:18:00,520 --> 00:18:11,720
抱歉，我还漏掉了最后一个局限：记忆会过时。
你需要一个流程，检查其中记录的内容是否依然正确。

134
00:18:12,480 --> 00:18:20,120
因此，我们引入了 dreaming，
也就是“做梦”的概念：它是作用于记忆之上的二阶过程。

135
00:18:20,120 --> 00:18:28,200
看看它的结构：首先有实际的上下
文，智能体从中获取有用的信息。

136
00:18:28,200 --> 00:18:35,360
然后是记忆流程，让智能体自主管理这些上下文。

137
00:18:35,360 --> 00:18:49,840
再往上是 dreaming。它以批量、异步方式运行，
拥有专门分配的资源，确保记忆有效、及时更新，并帮助智能体不断学习。

138
00:18:52,240 --> 00:19:04,560
那么 dreaming 具体是什么样？
基本做法是，先取一个现有记忆库，也就是一组记忆。

139
00:19:04,560 --> 00:19:11,840
再取一段时间内，智能体交互产生的若干会话或会话记录。

140
00:19:11,840 --> 00:19:25,520
把两者一起交给一个智能体。它审阅所有
记录和记忆库，找出能够改善记忆的模式。

141
00:19:26,000 --> 00:19:32,960
然后，它输出一个新的记忆库，包含对原有记忆库提出的修改。

142
00:19:32,960 --> 00:19:40,320
正如我所说，这个智能体可以把 token
专门用于解决“如何让智能体学得更好”的问题。

143
00:19:40,320 --> 00:19:49,240
它识别智能体反复失败的模式，
提出修改建议，让记忆库更有效。

144
00:19:49,240 --> 00:19:55,760
这样，第二天再次运行这些智能体时，
它们会显得更聪明，表现也更好。

145
00:19:55,760 --> 00:20:00,760
回到刚才的比喻，我再举些例子
，说明它在实践中可能是什么样。

146
00:20:00,760 --> 00:20:13,480
假设校长审阅所有记录，发现每个地理学
生都答错了某道题，答案简直一塌糊涂。

147
00:20:13,480 --> 00:20:22,520
老师分析“记忆库”后发现，原来
整个知识点都没有包含在课程里。

148
00:20:22,520 --> 00:20:33,880
于是，老师发现这个模式，查看记忆库，建议修改课程。
第二天这些智能体再次运行时，就有了所需的信息。

149
00:20:33,880 --> 00:20:42,440
再举一个例子：老师可能发现，某场数学
考试中，所有答案都以同样的方式出错。

150
00:20:42,440 --> 00:20:48,560
学生全都输出了弧度，而题目要求的是角度。
不知道有没有人上 GCSE 数学课时也遇到过？

151
00:20:48,560 --> 00:20:54,440
老师可以给出一条指令，告诉大家计算器应该如何设置。

152
00:20:54,440 --> 00:21:05,200
换成智能体，就是从会话记录中发现工具配
置有问题。比如，某种工具调用总是失败。

153
00:21:05,200 --> 00:21:17,000
这里很重要的一点是：查看会话记录时，
我们不只看智能体与系统或用户之间来回传递的回复。

154
00:21:17,000 --> 00:21:24,120
我们还会仔细审查工具调用，以及其
他对智能体表现至关重要的元数据。

155
00:21:24,120 --> 00:21:29,960
最后，你还可能发现整个智能体群或全组织共有的问题。

156
00:21:29,960 --> 00:21:40,190
比如，大家用了太多长破折号，而你不喜欢。于是，
你想增加一条组织级通知或上下文规则，要求不要这样做。

157
00:21:40,190 --> 00:21:45,200
希望这些例子能让大家理解，为什么这种方法会非常有效。

158
00:21:45,200 --> 00:21:55,320
接下来，我会介绍如何在生产环境中设计这样的系统。

159
00:21:55,320 --> 00:21:59,960
首先，你有一个记忆库，它就是一组记忆。

160
00:21:59,960 --> 00:22:05,360
这些记忆可以只是按目录组织起
来的 Markdown 文件。

161
00:22:05,360 --> 00:22:12,480
然后，取出若干会话记录。正如我刚才所说，

162
00:22:12,480 --> 00:22:19,440
它既包含智能体之间的来回交互，
也包含工具、所用其他技能等元数据。

163
00:22:19,440 --> 00:22:27,800
在我们的设计中，编排智能体会部署
一组子智能体，去分析所有这些记录。

164
00:22:27,800 --> 00:22:39,920
这里值得强调一点：设计系统时，
你可以引导负责写入记忆和协调 dreaming 的智能体，决定如何处理问题。

165
00:22:39,920 --> 00:22:49,920
所谓引导，是指告诉它们：在你的具体场景中，
哪些事情重要且相关，哪些事情不重要或不相关。

166
00:22:49,920 --> 00:22:58,080
因此，你可以针对自己的组织，定制记
忆整理和 dreaming 流程。

167
00:22:58,080 --> 00:23:12,720
编排智能体会审阅所有子智能体的回复，
然后判断哪些模式足够普遍，值得修改记忆。

168
00:23:12,720 --> 00:23:17,240
接着，它会针对记忆库提出具体的修改建议。

169
00:23:17,240 --> 00:23:26,600
在我们的生产环境设计中，智能体还
会给出出现这些模式的会话记录示例。

170
00:23:26,600 --> 00:23:34,600
同时提供一些统计信息，说明问题有
多普遍，以及为什么值得更新记忆库。

171
00:23:35,160 --> 00:23:40,560
这样，整个流程就很清晰。你会得到这些输出，

172
00:23:40,560 --> 00:23:50,880
并自行决定哪些记忆修改应该接受，
哪些应该拒绝，等等。这种方式非常有效。

173
00:23:52,200 --> 00:23:58,440
结合起来，我们就有了两条并行运行的流程。

174
00:23:58,480 --> 00:24:12,200
第一条是记忆：智能体使用会话内的一部分上
下文和资源，把它认为重要的信息写入记忆。

175
00:24:12,200 --> 00:24:20,560
这样，下一次运行、下一次会话时，
智能体就会表现得更好，也能更快看到改善。

176
00:24:20,560 --> 00:24:31,720
但这些智能体的资源天然存在竞争：多少用于记忆，
多少用于完成任务？而且，它们的可见范围也有限。

177
00:24:31,720 --> 00:24:39,320
另一条则是 dreaming，它在会话之外运行。

178
00:24:39,320 --> 00:24:48,480
它拥有更广的可见范围，以及专门的处理能力，
也就是专门用来帮助智能体学习的 token 预算。

179
00:24:48,480 --> 00:24:51,680
你可能会想：听起来很贵啊。［笑声］

180
00:24:51,680 --> 00:24:54,760
为什么还要在这里投入额外资源？

181
00:24:54,760 --> 00:25:02,680
但回头看，有效的记忆库带来的
改善，实际上能让不少成本下降。

182
00:25:02,680 --> 00:25:12,600
因为智能体更容易一次完成任务。
它掌握了做好任务所需的更多信息。

183
00:25:14,120 --> 00:25:27,720
总结一下：至少先用能奏效的简单办法。
上下文管理，对智能体表现的影响非常大。

184
00:25:27,720 --> 00:25:38,200
使用 CLAUDE.md 文件、大家熟悉的 Skills，
并允许智能体自主管理这些系统，就已经能带来很大帮助。

185
00:25:38,200 --> 00:25:48,000
当你考虑把它扩展到包含许多智能体
、或者智能体长时间运行的架构中，

186
00:25:48,040 --> 00:25:56,960
在同一个工作区或代码库里长期持续
开发，或者处理非常复杂的领域时，

187
00:25:56,960 --> 00:26:07,360
就应该开始考虑加入一些功能和防护措施，
让智能体以安全、可验证、可审计的方式管理记忆。

188
00:26:08,040 --> 00:26:18,080
还要说明，虽然这些做法对编程任务
非常有效，但它们绝不只适用于编程。

189
00:26:18,080 --> 00:26:27,040
比如，我制作演示文稿时经常使用记忆，
保存我的写作偏好、幻灯片风格等上下文，

190
00:26:27,040 --> 00:26:30,440
而且这些偏好会随着时间变化。
所以，这并不是编程专属的做法。

191
00:26:30,440 --> 00:26:35,880
最后，如果你真的想在这里形成闭环，

192
00:26:35,880 --> 00:26:42,600
可以考虑增加一个会话外流程，也就是我们
所说的 dreaming，用来整合记忆。

193
00:26:42,600 --> 00:26:51,840
删除不再相关的内容，补充智能体缺
失的信息，并清理、组织记忆系统。

194
00:26:52,520 --> 00:27:02,360
结束前我想说：上下文工程这一路上的
许多进展，其实都是过去一年才出现的。

195
00:27:02,360 --> 00:27:08,680
它仍是一个开放的研究和开发领域
，我们认为未来会有巨大的价值。

196
00:27:08,680 --> 00:27:14,240
我们非常期待各位在这个领域做出的成果与贡献。

197
00:27:14,240 --> 00:27:22,158
所以，鼓励大家继续思考，继续学习，
也继续“做梦”。谢谢！［掌声］

198
00:27:24,280 --> 00:27:28,760
太棒了。谢谢你，Lamis，精彩的分享。

199
00:27:28,760 --> 00:27:35,400
现场有没有问题？哇，问题不少。那就先从这边开始。

200
00:27:35,400 --> 00:27:44,680
谢谢，谢谢你的分享。你有没有推荐的记忆存储实现方案？

201
00:27:44,680 --> 00:27:51,440
是论文吗？你想问我们推荐的记忆存储实现？
抱歉，你说的是论文，还是……？

202
00:27:51,440 --> 00:27:56,400
我问的是记忆存储的实现。——哦，好，明白了，有什么推荐。

203
00:27:56,400 --> 00:27:59,920
你具体想解决什么问题？

204
00:28:00,000 --> 00:28:12,920
一种做法是把内容放在笔记本电脑的文件里。
但我想找更适合企业的方案。你有什么建议？

205
00:28:12,920 --> 00:28:21,709
好的。演讲里我可能有些含蓄，因为我
们不能做产品推广。但既然你问了……

206
00:28:21,709 --> 00:28:23,160
［笑声］

207
00:28:23,160 --> 00:28:34,080
这里的很多内容，其实都参考了我们托管智
能体方案中，记忆基础设施所采用的架构。

208
00:28:34,080 --> 00:28:42,400
所以，我提到的记忆系统生产化功
能，比如版本管理、哈希校验等，

209
00:28:42,400 --> 00:28:52,280
都可以通过 Claude Managed Agents 的记忆与 dreaming API 使用。
如果你想找开箱即用的方案，我会推荐这里。

210
00:28:52,494 --> 00:28:59,760
你好。前面你谈到了防护措施和权限。

211
00:28:59,760 --> 00:29:08,120
我想，我们大多数人可能都看过 Claude Code 泄露代码里有关记忆的内容，
其中 dreaming 尤其有意思。

212
00:29:08,120 --> 00:29:14,760
但如果企业里有几百名用户，各自拥
有不同权限，该如何扩展这个机制？

213
00:29:14,760 --> 00:29:28,720
dreaming 在会话外运行，
上下文与用户使用智能体时可能不同。你如何确保它遵守同样的防护规则？

214
00:29:28,960 --> 00:29:38,160
我先确认自己理解了：我们对智能体能够访问哪
些记忆设置了权限，然后还有一个独立的流程。

215
00:29:38,160 --> 00:29:45,320
我认为这些机制能够很好地组合，
因为设置 dreaming 流程时，

216
00:29:45,320 --> 00:29:54,320
你可以精确决定附加哪些会话记录。因此，
可以构建一个与智能体权限相对应的流程。

217
00:29:54,320 --> 00:30:02,800
也就是说，触发 dreaming 任务时，
并不一定会把某个时间段内的所有内容全部拿来。

218
00:30:02,800 --> 00:30:14,560
你当然可以这样配置，但也可以只搜索与记忆库具有相同权限的会话记录，
并确保权限匹配。希望这样解释清楚了。

219
00:30:16,200 --> 00:30:24,080
你好，谢谢，分享非常有意思。前面你谈到版
本管理、并发、持久性等问题，我觉得很有趣。

220
00:30:24,080 --> 00:30:31,120
到什么程度，我们其实是在重新从
基本原理出发，发明一遍数据库？

221
00:30:31,120 --> 00:30:36,040
对，这是一个很有意思的问题。

222
00:30:36,040 --> 00:30:45,000
它也提醒了我，刚才有一点没有说。

223
00:30:45,000 --> 00:30:54,120
我们正在尝试找到一个合适的边界：
哪些事情应该让智能体自主完成，

224
00:30:54,120 --> 00:30:59,760
哪些事情则应该通过程序，直接固化在智能体运行框架中。

225
00:30:59,760 --> 00:31:08,800
你提到的是：最开始，我们只是让智能体写 Markdown
文件，想提交什么就提交什么。

226
00:31:08,800 --> 00:31:13,200
现在，看清了哪些基本构件很好用之后，
我们开始考虑把这些机制固化到运行框架中。

227
00:31:13,200 --> 00:31:21,400
所以，对于哈希校验、版本管理，
我们确实在回到过去已被证明有效的软件工程原则。

228
00:31:21,400 --> 00:31:28,640
只是要以自主智能体能很好地操作和交互的方式来实现。

229
00:31:28,640 --> 00:31:34,480
在某种程度上，我们确实正在回归这
些实践，因为现在已经有足够的证据，

230
00:31:34,480 --> 00:31:39,400
知道这些事情应该以非常确定的方
式完成，没有必要重新发明轮子。

231
00:31:39,400 --> 00:31:42,560
希望这回答了你的问题。很好。

232
00:31:42,560 --> 00:31:49,480
我们的时间完全用完了。再次感谢！
请把热烈的掌声送给 Lamis。谢谢。

233
00:31:54,586 --> 00:31:56,606
［音乐］