Anthropic 的 Lamis Mukta 谈 Agent 记忆：从 CLAUDE.md 到「做梦」这一步

Anthropic 应用 AI 团队的 Lamis Mukta 在 AI Native DevCon 伦敦站（2026 年 6 月）讲了一场 31 分半的分享，题目是《Learning while you sleep: Beyond memory to dreaming》。正片约 27 分钟，最后 4 分钟是现场问答。她的团队介于研究、产品、商业化之间，既做内部项目，也直接服务一线构建 Agent 的客户，她本人主要对接初创公司和创始人。

一句话主旨：模型本身不会在组织里自动变聪明，得先把组织知识喂进去（上下文工程）；再把「整理记忆」这件事从会话里搬出去，交给一个会「做梦」的后台流程。

补一句背景：她讲的这套「做梦」，在 Anthropic 官方文档里已经是 Claude Managed Agents 下的研究预览能力（beta 头 dreaming-2026-04-21），2026 年 8 月 1 日起支持 Claude Opus 5。

一、她一开始就把路线图交代了

一共四块：

回顾上下文工程过去一年走过哪些路，哪些做法真的好用
讲当下记忆管理的最先进水平
讲生产环境落地要补什么，也就是理论之外的工程问题
讲持续学习的方向，落到一个新概念：做梦

二、为什么这件事值得做

核心判断是：智能不会自动复利。

新模型一代比一代强，但它开箱并不知道你组织怎么运转、你偏好什么。这部分上下文跟模型本身的智能是两回事，她用的词是「正交」。所以花在上下文工程上的功夫，会随时间把模型的能力放大。

她列了三个大家都熟的毛病：Agent 不熟悉代码库；不了解你的偏好；同一个任务做第二遍也没变强，因为它不从错误里学习，也就没有持续学习的效果。

三、一年时间线：从 CLAUDE.md 到文件系统

Anthropic 的信条是「做简单且有效的事」。这条线只走了一年。

CLAUDE.md。 随 Claude Code 推出的一份 markdown，只给几条简单指示：代码库怎么走、组织什么样、你的偏好是什么。会话开始时注入到上下文开头，效果出奇地好。问题是它会变长，一长就撞上上下文膨胀，时间久了还不好管理。

记忆工具。 换个思路：让 Agent 自己管记忆，自己决定什么时候读、什么时候写、什么时候更新。这些动作都在带内完成，也就是会话上下文之内。自主性效果不错，于是越做越放手，对工具该长什么样预设得越来越少。

Skills 与渐进式披露。 这一站是为了治上下文膨胀。它适合「流程类工作」，也就是你对整个流程有明确想法、希望 Agent 端到端照着你认定的路子走。Agent 先只读文件顶部那几行说明，加载之前不碰正文；正文想写多细都可以。这样深度细节留得住，上下文又不会被撑爆。

她打了个书架的比方：有人来跟你讲话，你先扫一眼书目，看哪本相关就抽出来翻。比如对方突然用法语跟你说话，你手边正好有本法语词典，取出来就行，不必先上七年法语课把所有词都装进脑子。

瓶颈是：Skills 仍然要人和 Agent 一起驱动。哪块内容该做成 Skill，还是人在拍板。

文件系统即记忆。 这是她眼中当下的最佳实践。把记忆系统直接建成文件系统，往里面堆 markdown，让 Agent 用 bash、grep 这类常规工具自己搜，而不是规定它只能走某几个专用工具。这种搜索本身呼应了渐进式披露。索引建好，Agent 检索就聪明。

一年下来的三条经验：markdown 适合当记忆；记忆可以放心长大，但得给 Agent 快速检索的工具；写入这一侧要多给自主权。

四、一上生产就出事

方案在理论上成立，扔进生产环境就是另一回事了：很多 Agent 同时跑，运行周期很长，代码库还很复杂。她举了几种真实翻车：

多个 Agent 同时写同一个记忆文件
某个 Agent 去改全局共享的上下文，而所有 Agent 都在读它，写错一次就扩散到全体
人和 Agent 一起维护记忆，出了事不好追是谁改的
记忆会过期，过去的经验今天未必还成立；也可能写错，甚至被人恶意注入

五、四条生产原则

版本管理。 要能存版本、能回滚。还得记清楚这次更新基于什么上下文——是哪次会话、哪份记录让你想这么改；以及是谁做的，哪个 Agent、哪个人。

并发用哈希。 Agent 决定写入时，先取一次哈希，起草修改，落笔之前再取一次。两次对不上，说明期间有别人动过，这一笔就不能写。它会重新拉取记忆、重新起草、再尝试提交。

权限控制。 记忆是分层的。最上面是组织级知识，比如组织要实现的目标、精心维护的代码库原则；往下是面向特定团队或交叉领域的内容；最下面是 Agent 的草稿本，记它的工作记忆，也最个性化。全局上下文最好只读，Agent 自己的草稿本才给写权限。

可移植性。 这一条看着外围，其实同样重要。记忆系统维护起来很费功夫，是组织、用户、任务多个层面一起在投入，你肯定希望它能被多个产品端、多套系统共用。所以要用一套干净的可移植 API 来设计。

六、做对了之后能看到什么

她给了几条大规模部署后的观察：

准确率上去了。同一个任务，Agent 第二遍做得明显更好，因为它记下了上次哪里出错。

再接着是二阶效应，落在速度和成本上：token 花得更少，更容易一次做对，因为它们确实知道自己手上在做什么。

最后一条是人的时间被腾出来了。Agent 开始自己书写记忆之后，开发者可以腾出手来做产品本身，后台那个自我学习的循环照常转。

但她补了一句：这套基础设施搭好之后两者配合很顺，可瓶颈总会再来。这次的问题出在带内记忆。

七、带内记忆的两个天花板

先说清楚，带内记忆指 Agent 在单个会话里读写记忆。拿 Claude Code 举例，你新开一个会话，它读写记忆基本只看当前上下文。

从整个 Agent 集群要持续学习这个目标看，这种模式有两处硬伤：

一是注意力和资源被拆开了。你让它完成任务的同时，还让它花精力迭代记忆，好让「未来的自己」表现更好。这本身就是个很难的优化问题：多少力气给未来，多少用来干眼前的事。另外还有延迟之类的副作用。

二是视野天然受限。它只知道自己会话里发生了什么，看不见跨会话反复出现的模式。你气它老犯同一个错，它完全意识不到你有多郁闷，因为每次都是新的上下文。你在不同环境里跑多组 Agent，单个 Agent 也不知道别人踩过哪些坑。

八、做梦：把整理记忆搬到带外

为什么这个思路成立，她先讲了个学校的比方：学生交大量作业，老师负责批改，还有一位校长负责复核一切。现实里这套制度行之有效，一来有人专门负责帮人学习，这种投入很值；二来有人能看到全局，发现规律、调整课程安排。

她还补了一句自己「漏讲的限制」：记忆会过期，所以需要一道检查工序，确认写进去的东西仍然正确。于是就有了做梦，一个架在记忆之上的二阶工序。

具体怎么跑：

拿一个现成的记忆库，也就是一组记忆，通常就是目录里的 markdown 文件
再取一段时间里 Agent 交互的会话记录。这里不只是对话文本，还包括工具调用、用过的 Skills 等元数据
交给一个 Agent 通读，对照记忆库找可以改进的地方
输出一份新的记忆库，里面带着对现有记忆的修改建议

说白了，就是把 token 花在「让 Agent 学得更好」这件事上，找出它反复失败的模式，把记忆库改得更有用。第二天再跑，这些 Agent 就真的更聪明。

她举了几个例子，还是用学校那把尺子：

所有地理学生都答错了同一道题，答案写得一塌糊涂。老师顺着记忆库一看，发现整个知识板块是空的，于是提出对课程的修改，第二天学生就补上了这块知识。

数学考试里所有答案错得一模一样，全是把角度当弧度算了。她说不知道有没有人考 GCSE 数学时也被这个坑过。总之可以给一条指令，告诉他们计算器该怎么设置。对应到 Agent 身上，就是在会话记录里发现某个工具配置出了问题，比如某个工具调用一直失败。

她特意提醒：翻这些记录时不能只读对话文本，还要看影响 Agent 表现的元数据。

还可能发现集群级或者组织级的问题。比如所有人都在滥用破折号，你不满意，就加一条全局说明，告诉大家别再这么写。

九、生产中怎么搭这套系统

输入是记忆库加一批会话记录。做法是：调度器派出一群子 Agent 去分析所有记录；你可以「引导」这些 Agent，也就是告诉它们在你的场景里哪些事重要且相关、哪些不重要——所以记忆和做梦流程是能按组织定制的。调度器再把子 Agent 的结果汇总，判断哪些模式足够普遍、值得改记忆，然后对记忆库给出一条条具体修改。

生产版的实现里还多给两样东西：触发这个模式的记录实例，以及问题有多普遍、为什么值得更新记忆库。整套跑完交给人拍板，哪些修改接受、哪些拒绝。

她把两条线并排放着讲：

记忆是带内的，只花一部分资源，但见效快，下一个会话它就变强；代价是资源要跟完成任务的资源互相抢，视野也有限。

做梦是带外的，视野更宽，还有专属的算力投入，专门用来帮 Agent 学得更好。

有人会问这也太贵了。她的回答是回头看收益：记忆库建好之后，一堆成本反而降下来了，因为 Agent 更容易一次把事情做对，手上有更全的信息。

十、收尾给的建议

先做简单且有效的事。上下文管理对 Agent 表现的影响非常大。

落地 CLAUDE.md、Skills 这些，再让 Agent 自主管理系统，已经大有帮助。

一旦要扩到多 Agent 架构、长时间运行的 Agent，或者长期演进的代码库，就该考虑加护栏，让 Agent 用安全、可验证、可审计的方式管记忆。

别以为这只跟编码有关。她做演示时也一直用记忆，里面记着自己偏好的写法、喜欢的排版风格，而且会不断积累。

想把这件事做完整，可以再加一层带外的做梦：整合记忆，删掉不再相关的，补上 Agent 缺失的，把整个记忆系统清理整理一遍。

最后她说，这段上下文工程的旅程，很多都发生在过去一年，这仍然是个非常开放的研究与开发领域，未来价值巨大，很期待看到现场各位的贡献。「希望大家继续思考，继续学习，继续做梦。」

十一、现场问答（约 27:00–31:30）

问：记忆库该用什么实现方案，你有没有推荐的？ 她先坦白自己在演讲里有点含蓄，因为不被允许做产品推介。既然被问了就说了：这套架构正是他们记忆基础设施所用的、托管 Agent 方案的参考架构；她讲的那些生产化要素，版本管理、哈希等等，都已经内置在托管 Agent 的记忆与做梦 API 里。想要开箱即用的方案可以去那里看。

问：企业里几百个用户、权限各不相同，做梦怎么规模化，又怎么保证它也遵守这些护栏？ 她说这两件事可以组合得很好。配置做梦流程时，你能精确决定附上哪些会话记录，完全可以搭一套流程去镜像你现有的权限体系。触发做梦任务时也不一定要全量抓某个时间段的所有记录，也可以只检索权限跟记忆库一致的记录，保证两边对得上。

问：你讲到版本管理、并发、持久性，我们是不是又在从零重造数据库？ 她说这个问题很有意思，也是她没讲到的点。他们想做的是找到一条合适的边界：一边让 Agent 自主行动，一边确定哪些事该做成程序化规则、固化在执行框架里。一开始确实是让 Agent 随便往 markdown 文件里写，现在看清了哪些范式真好用，正考虑把它们固化进框架。哈希和版本管理这些，确实是在回到那些被验证过的软件工程原则，只是要让自主 Agent 也能高效地跟它们打交道。之所以敢这么做，是因为现在信号足够多，已经有足够证据说明这些事就该用确定性的方式做，没必要重造轮子。

十二、术语速查

上下文工程：把组织、任务相关的信息喂给 Agent，让它能完成具体工作
带内（in-band）：在会话上下文之内发生的读写
带外（out-of-band）：独立于会话、异步批量运行的工序
记忆库：一组记忆，通常就是目录里的 markdown 文件
做梦：带外的记忆整理工序，读会话记录、改记忆库
渐进式披露：先只给摘要，需要时再加载细节
引导（steering）：人为告诉做梦流程，在你的场景里哪些事重要、哪些不重要

十三、几个可以留意的点

这场演讲是从踩坑里长出来的，不是先有理论再落地。 四条生产原则每一条都对应一个具体事故——并发写、写坏全局、追不到改动人、记忆过期。

她承认了方案的边界。 「带内记忆的天花板」这一段，本质上是承认单会话自治走不远。先把问题说透，再引出做梦，逻辑上是站得住的。

「做梦」这个词容易误读。 它跟模型训练、微调、RLHF 都没有关系，纯粹是上下文层面的整理工序，改的是 markdown 记忆库，不是模型权重。演讲里没有专门澄清这一点，但这是理解整套方案的前提。

商业信号藏在问答里。 正片刻意不做产品推介，只在被追问时才说出「托管 Agent 的记忆与做梦 API」已经内置了版本管理、哈希这些能力。说明这套东西已经从内部实践变成了对外产品。