夜雨聆风Agent 投入生产之后，一个根本问题始终悬而未决：Agent 如何持续变好？
你也许已经为 Agent 配置了记忆存储，让它能在会话之间记住用户的偏好和上下文。但记忆本身不会进化——它会积累重复、矛盾和过时的信息，更不会从过去的成功或失败中抽象出可复用的行为模式。
今天，Anthropic 在第二届 Code with Claude 开发者大会上带来了一个值得认真对待的答案：Dreaming（梦境）。这不是一个花哨的市场概念，而是一套让 AI Agent 定期回顾自己的历史会话、提取跨会话的模式，并将这些发现写回为结构化知识的生产级机制。
Agent 进化的瓶颈不止是「记不记得住」
先看一个具体场景：你部署了一个 Agent 来处理客户工单。第一周它表现不错，第二周开始出现重复错误——同一个类型的查询，它在不同会话里采用了不一致的处理方式，甚至会在某些边缘场景上反复踩坑。你当然可以手动分析日志、调整 prompt、更新知识库，但这件事本质上不应该是人工操作。
现有的记忆系统解决的是「跨会话记住」的问题——Agent 可以把一段文本写入记忆存储，后续会话读取。但这只是最基础的一层。问题在于，记忆存储是一堆离散文本的集合，没有结构，没有优先级，没有去重机制。Agent 上一次遇到的问题 A 可能已经被解决了，但记忆里还留着当时的错误尝试记录；两次不同的会话可能对同一件事做了矛盾的记录。
Dreaming 要解决的就是这个更深层的需求：让 Agent 具备对自身经验的反思和整理能力。它不是一个写入记忆的操作，而是一个定期触发、在后台运行的元认知过程。
Dreaming 的技术设计
从架构上看，Dreaming 是一个异步任务。它接收两个输入：
一个已有的记忆存储（memory store），包含 Agent 在多次会话中积累的笔记和上下文 可选的一组历史会话记录，最多 100 条完整的会话 transcript
然后它产出一个新的记忆存储。注意：输入的记忆存储不会原地修改——原始数据保持不变，新生成的存储作为一个独立实体供你审查和部署。这意味着你可以在应用之前检查梦境产出的内容，确认它合理再替换上去。
Dreaming 具体做什么？三件事：
去重与合并：多轮会话中反复记录的同类信息被合并为一条，消除冗余 矛盾消解：当两次会话对同一事实产生矛盾记录时，Dreaming 会用最新或最可信的版本覆盖过时的内容 跨会话洞察：这是最有价值的部分。Dreaming 会扫描历史会话，识别出那些单个 Agent 会话无法感知的模式——比如多个 Agent 独立发现了同一个工作流优化点，或者某种错误模式在不同会话中反复出现
所有这些产出都以纯文本笔记和结构化 playbook 的形式写入记忆存储。关键在于，它不修改模型权重，不涉及微调，每一步都完全可审计。
从 Demo 看 Dreaming 的实际效果
在大会的现场演示中，Anthropic 构建了一个虚构的航空航天场景：一个多 Agent 系统需要自主控制无人机在月球表面着陆并采集资源。系统包含三个 Specialist Agent——指挥官（负责整体任务成功）、探测器（识别优质着陆点）、导航员（控制安全飞行和着陆），外加一个预定义的评分规则（软着陆、净地表、足够燃料返航）。
第一轮模拟在六个候选着陆点上的表现参差不齐。演示者直接在 Claude Developer Console 中触发了一个 Dreaming 会话。夜间，Dreaming Agent 回顾了所有历史模拟会话，撰写了一份详细的着陆 playbook——一组从多次任务运行中归纳出的启发式规则。
第二天早晨，团队将 Dreaming 产出的 playbook 注入 Agent 的记忆后重新运行模拟，之前表现不佳的着陆点出现了显著改善。
演示中的关键细节是：整个过程中没有人类介入。Dreaming 是自动触发的，playbook 是自动生成的，改进结果是在下一个迭代中自动体现的。
与 Dreaming 配套的两个能力
Dreaming 只是当天发布的三项能力之一。另外两项——Outcomes（成效定义） 和 Multi-agent orchestration（多 Agent 编排）——与 Dreaming 形成了完整的闭环。
Outcomes 提供了一个定义「成功」的框架。你可以用 rubric（评估准则）来描述一个任务达到什么样的输出才算合格——格式规范、内容标准、品牌语气等。Agent 完成任务后，一个独立的 Grader Agent 会用自己的上下文窗口来评估产出是否符合 rubric 标准。这里的设计很有意思：Grader 和 Working Agent 使用独立的上下文，Grader 不受工作 Agent 的推理路径影响，不会积累会话偏误。它只做一件事——指出差距，然后 Working Agent 根据反馈迭代，直到达标。
引入 Grader 的动机很实在：让模型在一个全新的上下文里审查另一个模型的产出，比让同一个长会话自我审查效果更好。Anthropic 产品负责人 Alex Albert 在采访中坦言，「注意力会随着长会话衰减，这是当前模型固有的局限。」
Multi-agent orchestration 则是把复杂任务拆解为子任务，分配给不同的 Specialist Agent——每个 Agent 拥有独立的模型实例、系统 prompt、工具和上下文窗口。每个子 Agent 在隔离的上下文中工作，最后合并结果。Albert 给出了一个实用的判断标准：「调查类任务适合用并行 Agent」——当你需要从大量信息中找到答案时，绝大部分搜索中间结果是最终不会用到的，没必要占用主线程的上下文。
这三项能力组合在一起，形成了 Anthropic 所说的持续改进循环：
执行 → 评估（Outcomes）→ 反思（Dreaming）→ 改进 → 再执行早期采用者的实际收益
来自真实客户的数据已经验证了这个闭环的有效性：
法律 AI 公司 Harvey 在接入 Dreaming 后，任务完成率提升了约 6 倍 医疗文档审阅公司 Wisedocs 使用 Outcomes 将文档审阅时间缩短了 50% Netflix 利用多 Agent 编排同时处理数百个构建的日志分析
这些数字传递了一个信号：当 Agent 进化的循环从人工驱动变为系统自动完成时，提升幅度远不止是增量式的。
对开发者意味着什么
这次更新最值得关注的一点，是 Agent 能力的提升正在从「模型更强」转向「系统更聪明」。
过去一年，开发者社区在 Agent 上的探索主要集中在 prompt 工程和工具调用层面。Dreaming 代表的是一种新的范式：Agent 首次具备了跨会话的元认知能力——它不仅能记住，还能反思、归纳、自我修正。
这对工程团队有几个直接影响：
维护成本下降：过去需要人工分析的错误模式和性能瓶颈，Dreaming 可以在后台自动识别并写入 playbook，减少了人工日志分析的频率 Agent 的「冷启动」周期缩短：新部署的 Agent 不再需要数周的人工调优——Dreaming 可以在数轮会话后就自动积累出有效的 playbook 审计可见性不降反增：因为 Dreaming 产出的是纯文本笔记和 playbook，而非黑盒的权重更新，团队可以阅读、修改、驳回 Agent 自行总结的任何规则
当然，信任是一个实际问题。让 Agent 自行总结知识并应用到后续会话，需要你接受一定程度的不确定性。Anthropic 的做法是让整个过程透明——你看到它写了什么，你决定用不用。
为什么这件事值得关注
如果我们把时间线拉长来看，从 2025 年到 2026 年，Agent 的能力边界发生了两次跃迁。第一次是从「单次对话」到「持久记忆」——Agent 记住了你是谁。第二次就是从「记住」到「反思」——Agent 开始理解自己为什么做对或做错，并据此调整行为。
Dario Amodei 在大会的发言中提到了一个观察：2026 年第一季度的实际增长是公司预期的 80 倍（而不是他们为 10 倍增长规划的资源配置）。这个数字背后反映的是，企业对 Agent 的需求远超预期，但真正制约采用的不是模型能力，而是 Agent 在生产中的可靠性和持续改进能力。
Dreaming 是对这个制约的一次直接回应。它不是那种刷榜的模型更新，而是直接影响生产体验的工程能力。对于正在或计划将 Agent 投入生产环境的团队来说，这是值得花时间研究和实验的方向——因为它触及的核心问题是：你的 Agent 只会在不停被使用中变得更好，还是在重复犯错中原地踏步？
#Anthropic #Claude #AI Agent #Agent工程 #大模型应用
