从上下文工程到 Dreaming：如何让 AI Agent 积累经验

Tue, 10 Nov 2026 11:16:01 +0800

一个编程 Agent 第一次进入代码库时，可能不知道测试命令、团队约定或部署流程。即使它最终完成了任务，下次会话也未必知道上次踩过的坑。更换更强的模型，不能自动补齐这些组织和任务信息。

在 AI Native DevCon 2026 的演讲中，Anthropic Applied AI 团队的 Lamis Mukta 分享了她对上下文工程和记忆管理的看法。本文根据演讲的自动转写整理，并参考 Anthropic 官方文档补充产品现状。Mukta 提到的效果来自实践观察，演讲中没有给出量化对照。她所说的持续改进，是通过更新外部上下文和记忆来改善后续表现，并不涉及更新模型权重。

从指令文件到可搜索的记忆

上下文工程可以理解为：围绕任务选择、提供和维护模型需要的信息。Mukta 介绍的实践从简单的 Markdown 指令开始，逐步发展到让 Agent 按需读取和维护记忆：

指令文件：用 CLAUDE.md 等文件记录代码库入口、团队规则或用户偏好。它容易阅读和修改，但规则持续累积后，每次加载全部内容会占用更多上下文。
会话内记忆：让 Agent 在执行任务时自行读取、写入或更新记忆，使下一次任务能够使用这些信息。代价是当前任务也要承担记忆维护的资源消耗。
Skills：把有明确步骤的工作流组织成技能。Agent 先看到简短描述，确认相关后再加载详细内容，避免每次把所有流程放进上下文。
文件系统记忆：用 Markdown 文件、索引和搜索工具组织更多记忆，让 Agent 按需查找和更新。这里的文件系统指信息的组织和使用方式，底层也可以使用适合生产环境的存储服务。

这几种方式可以组合使用。例如，把所有任务都应遵守的测试要求放在简短的指令文件中，把发布流程放进按需加载的 skill，再把项目特有的历史问题放进可搜索的记忆库。关键是让信息在需要时可获得，而不是让每次会话携带所有历史。

记忆进入生产环境后需要什么

多个 Agent 共享记忆时，仅有可读写的文件还不够。一处错误修改可能影响其他任务；两个 Agent 同时更新一份记忆，也可能相互覆盖。Mukta 提出了四方面需要考虑的工程能力：

版本和来源：保留修改历史，记录发起者、关联会话和依据，以便审查和回滚。
并发控制：Agent 读取记忆及其哈希后起草修改；提交时若版本已变化，就重新读取并处理冲突。工程实现需要将比较版本和写入作为原子操作，否则两步之间仍有竞争窗口。
权限隔离：组织级规则可以对普通 Agent 只读；团队记忆按范围授权；个人工作记录可以有更宽的写入权限。错误记忆和恶意内容也需要防止扩散到更大范围。
可移植性：通过清晰的接口访问记忆，避免组织长期维护的知识只能在单一产品界面使用。

Mukta 观察到，有了记忆，Agent 在处理类似任务时可能少走一些弯路，更容易完成任务，也可能节省时间和成本。她没有在演讲中提供对照实验、适用范围或成本数据，因此这些收益还需要在具体场景中验证。

为什么还需要会话外整理

会话内记忆可以及时保存任务中的发现，但 Agent 主要看到的是当前会话，同时还要完成用户请求。它可能发现不了其他会话中反复出现的相同错误，也未必有足够资源检查旧记忆是否过时。

为了解决这类问题，Mukta 将目光投向会话之外。她把异步整理记忆的流程称为 Dreaming：读取选定的历史会话、工具调用等轨迹以及现有记忆，寻找重复问题、缺失知识、冲突和过时内容，再提出修改建议。在她介绍的工作流中，使用者可以查看依据，决定接受或拒绝这些修改。

例如，多个 Agent 都在某个项目中使用错误的测试命令。单次会话可能只修复当前失败；跨会话整理则可能识别共同模式，建议在项目记忆中加入正确命令，并附上相关会话作为依据。另一类情况是多个会话的写作风格不符合团队偏好，整理流程可以建议修改适用范围内的写作指导。

维度	会话内记忆	Dreaming 会话外整理
时机	当前任务执行期间	选定会话后异步运行
视野	主要是当前会话	多个会话和已有记忆
用途	及时保存任务中的发现	识别跨会话模式、去重和更新旧记忆
代价	占用当前任务的时间和资源	增加后台计算、审查与权限管理成本

Dreaming 与会话内记忆互补，不保证自动得到正确结论。额外的 token 消耗是否能被后续任务节省的成本抵消，也需要实际测量。

官方实现与权限边界

截至 2026 年 11 月 10 日，Anthropic 的 Dreams 文档将该功能标为 research preview，需要申请访问。文档描述的任务读取一个已有记忆库和 1 至 100 个会话，异步生成独立的输出记忆库；输入库不会被修改，使用者可以审查或丢弃结果。这是 Anthropic 的具体产品实现，与 Mukta 在演讲中讨论的一般设计有所区别；实际可用性以官方文档和账户权限为准。

对于企业来说，能够选择输入会话，并不意味着授权问题已经解决。应先根据用户、团队和记忆库的权限范围筛选轨迹，再确保整理流程及输出的读写权限不超出原有范围。Mukta 没有在演讲中详细说明权限继承或跨租户隔离的实现。

站内的 OpenClaw Dreaming 文章介绍了另一套具体的后台记忆整理机制。两者使用相同名称，但产品实现和操作边界各自独立，不能直接套用。

从小范围开始实践

从 Mukta 的分享出发，可以按以下顺序评估自己的 Agent 系统：

找出反复解释的规则或反复出现的错误，先写成简短、可维护的上下文，并观察实际任务结果。
将特定场景的流程做成按需加载的 skill；让规模较大的知识可索引、可搜索。
明确 Agent 可以修改哪些记忆、哪些必须经人审查，并保留修改依据。
多 Agent 共享或长期运行时，补齐版本、原子并发控制和权限隔离。
如果跨会话重复问题仍然明显，再选择权限匹配的轨迹进行异步整理；结合人工审查、任务质量和额外成本评估结果。

需要判断哪些经验值得保留时，可以利用 Agent 分析；需要保证权限、版本和一致性时，仍应依靠确定性的工程机制。

来源：