Dream 究竟在做什么
两个输入，一个新输出
一次 dream 是 "一个异步任务"，它恰好接收两种输入："一个预先存在的记忆库： Claude 会对其进行验证、去重和重组；以及 1 到 100 个会话（sessions）： 过去的对话记录，Claude 会从中挖掘模式和洞察，并将其融入到输出中。"
它所产生的结果同样被精确地描述为："一个新的、重组后的记忆库：合并重复项、用最新值替换过时或矛盾的条目，并呈现新的洞察。"
注意第三项。合并重复项和替换过时条目属于清理工作。而从对话记录中呈现新的洞察则是另一回事——它读取了记忆库从未捕获过的会话，并写下它们所暗示的内容。如果你有对话记录但还没有记忆库，文档给出了权宜之计："先创建一个空的记忆库，并将其作为 memory_store 输入传入。"
输入绝不会被修改
正是这个设计选择让其余部分可以安全使用：
"输入存储库绝不会被修改，因此你可以审查输出，如果对结果不满意，可以直接丢弃。"
稍后在文档中以更强烈的语气重申："Dream 本身绝不会删除或修改其输入。" 即使在失败时也是如此——在 failed 或 canceled 的 dream 中，"输出记忆库将保持原样，保留失败前写入的所有内容，" 并且 "输出库将保留部分内容，以便你可以检查停止前生成的内容。"
因此，糟糕的 dream 的失败模式只是一个需要你删除的存储库。而不是一个你必须重新构建的存储库。
它可以引导，但它不是编辑器
可选的 instructions 字段上限为 4,096 个字符，"引导 dreaming 管道合成的内容。它应用于整个管道：仔细阅读什么、合并或丢弃什么，以及如何构建输出记忆库。" Anthropic 自己的例子是一个侧重点声明："专注于编码风格偏好；忽略一次性的调试笔记。"
接下来是一个可以避免人们白白运行任务的警告：
"该管道是对输入进行合成处理，而不是对存储库文本进行编辑，因此针对特定行的命令式指令（"将句子 X 更改为 Y"、"修复 Z 部分中的计数"）通常不会产生任何变化。"
对于有针对性的修改，文档将你引向别处："直接在输出存储库上使用 Memory Stores API。" Dreams 适用于调整存储库的整体形态，而不是进行行级编辑。
耗时因情况而异，且你可以实时观察
"Dreams 异步运行，通常需要几分钟到几个小时，具体取决于输入对话记录的数量。" 生命周期为 pending、running，然后是 completed、failed 或 canceled 之一。
有一个值得注意的操作细节："在 dream 开始 running 后不久，一旦工作流克隆了输入存储库，输出存储库 ID 就会出现在 dream 的 outputs[] 中；运行中的 dream 可能会短暂地报告一个空的 outputs[]。" 早期出现空数组并不是错误。
你还可以观察工作过程：运行中的 dream 的 session_id "指向运行该管道的底层会话，" 你可以流式传输其事件 "以实时观察 dream 正在读取和写入的内容。" 该会话 "在 dream 达到终态时会被归档（而不是删除），因此对话记录在此之后仍然可用。"
结束的两种方式
当 dream 完成时，其输出 "是工作区中的一个普通记忆库。" 从那里，有两条文档记录的路径。利用它： "将其作为 memory_store 资源附加到未来的会话中，以代替（或与……并存）输入记忆库。" 丢弃它： 删除或归档该存储库。
并存（alongside） 是那句话中一个低调的选项。你无需在整理后的存储库和原始存储库之间做出非此即彼的选择。
这改变了什么，又没有改变什么
它确实解决了一个真正的结构性问题。 增量写入会积累矛盾。这并不是 Anthropic 实现中的 bug；而是以追加为主的存储库的必然结果。带有审查关卡的定期合成处理是一个合理的解决方案，它所操作的存储库机制在 Claude's agent memory stores 中有详细介绍。
它不会自动运行。 没有日程表，没有后台触发器。你创建一个 dream，选择模型，轮询状态，审查输出，然后附加或丢弃。其中的每一步都是一次显式调用。
它有双重门槛，且门槛非常具体。 "Dreaming 是一项研究预览功能，" 需要申请访问权限。而且请求头很重要："Dream 端点受 dreaming-2026-04-21 Beta 请求头的限制；仅凭 managed-agents-2026-04-01 请求头无法获得 dreams 的访问权限。" 会话和记忆库调用只需要后者。
它按比例消耗 Token。 "Dreams 按你选择的模型的标准 API Token 费率计费，" 并且 "成本与输入会话的数量和长度大致呈线性关系。" Anthropic 自己的建议是从小规模开始："先从一小批会话开始，在对整理质量满意后再扩大规模。"
它无法防止你在运行途中删除其输入。 文档中有一个警告："在运行途中归档或删除输入记忆库（或删除输入会话）将导致 dream 失败，并报错 input_memory_store_unavailable 或 input_session_unavailable。" 输入对 dream 来说是只读的，但并没有对你锁定。
它有你可能会触及的大小限制。 错误列表包括 input_memory_store_too_large、针对达到存储上限的组织的 memory_store_org_limit_exceeded，以及当 "管道超出了其运行时间预算" 时的 timeout。
人们会从中得出什么误解，以及为什么不应该这样想
"Claude 现在会自动维护自己的记忆。" 对于 Managed Agents 来说，并不是通过 Dreams 实现的。这是一个你需要使用显式输入、选择模型并在最后做出决定的任务。
"它能修复错误的记忆。" 它会根据输入所支持的内容，用最新值替换 "过时或矛盾的条目"。如果你想修改某个特定的句子，那应该在输出存储库上使用 Memory Stores API——文档指出，行级的命令式指令 "通常不会产生任何变化。"
"审查是可选的。" 审查正是这项功能的核心价值所在。将未经审查的 dream 直接附加到生产会话中，会丢弃使该设计安全运行的唯一属性，也违背了保留输入的初衷。
"会话越多越好。" 更多的会话意味着更高的成本和更长的耗时，指导原则是在你满意质量之后再扩大规模——而不是在此之前。成本和运行时间都与对话记录的体量挂钩。
"这和 ChatGPT 做的是同一件事。" 不同的层面，不同的易用性逻辑。OpenAI 的 Dreaming 在后台整理消费者记忆。Anthropic 的 Dreams 是一个由开发者触发的合成任务，它会生成一个可审查的工件，且绝不修改其源数据。
"取消可以撤销它。" 取消只是停止运行，并不会进行清理。取消的 dream 会留下其部分输出存储库供你检查或删除。归档 dream 也 "不会触碰其输出记忆库，" 而且对于 dream 本身，"没有取消归档的操作。"
解决方案：将整理视为一种习惯，而非一项功能
步骤 1：在整理存储库之前，先确定“过时”对它意味着什么
合成处理的效果取决于你给它的判断标准。在运行任何内容之前，写下你的存储库中哪些类别的条目允许更改，哪些必须保留。
instructions 字段就是放置这种判断标准的地方，它最适合作为高层指导：用 Anthropic 的话来说，就是 "重点领域……保持不变的内容，或者你希望在整个存储库中应用的输出约定。" "优先选择最新的编码偏好陈述" 是合适的抽象高度。而 "修复第三部分中的数字" 则不是。
步骤 2：构建一个你真正会执行的审查步骤
保留输入存储库是为了让审查成为可能。通过提前决定两件事来让它在实践中落地：你将对比（diff）什么，以及什么情况会让你选择丢弃。
一个有用的默认做法是在一段时间内将输出与输入并存附加，而不是直接替换它（文档明确允许这样做），并观察智能体的行为是否有所改善。需要寻找的是记住的条目之间的冲突，这一通用习惯在 detecting conflicts in AI memory 中有详细介绍。
在 dream 运行时，流式传输其会话事件可以告诉你它正在读取和写入什么。这至少值得做一次，因为看到它依赖哪些对话记录是了解你的会话选择是否正确的最高效方式。
步骤 3：保持你整理的存储库独立于任何单一厂商的管道
这就是结构性问题所在，这并不是对 Dreams 的批评。其机制是健全的，审查关卡也是正确的设计。但它也仅限于单一平台上的记忆库，处于研究预览标志背后，且仅适用于以特定方式构建的智能体。
与此同时，衰退最快的记忆是那些分散在你所使用的所有工具中的记忆——你在聊天中表达的偏好、你给编码智能体的纠正、在其他地方的会话记录中记录的决定。重复和矛盾在不同工具之间积累的速度甚至比在单个存储库内部还要快，而没有任何单一厂商的整理处理能够看到它们。
一个由你掌控的记忆层才是这个整合存储库的归宿，并且同样的习惯也适用于此：读取它、纠正它、修剪它、保留版本历史。MemoryLake 只需三步即可设置完成。
步骤 1：创建 API 密钥
登录并从你的仪表板生成一个 API 密钥。你自己的存储库是你可以直接打开和检查的，这使得上述审查习惯变得切实可行，而不仅仅是停留在设想阶段。Anthropic 的记忆库仍保留在原处，通过 Anthropic 自己的 API 进行管理。
步骤 2：上传你的第一批记忆
放入持久的事实：决定及其原因、领域词汇、长期偏好、你给出过不止一次的纠正。这些正是 dream 会合成的材料，保存在你使用的每个工具都能访问到的地方。
步骤 3：连接你的 AI 和智能体
将你的智能体指向该存储库。这样，整理就变成了你针对知识本身只需做一次的事情，而不是针对每个厂商的记忆系统都要做一次——正如 syncing AI memory across your tools 中所阐述的观点。
这在实践中改变了什么
第一个改变是，"我的智能体的记忆随着时间的推移变差了" 变成了一种可诊断的状况，而不再是模糊的抱怨。Anthropic 为其确定了名称和机制：增量写入、重复、矛盾、过时条目。
第二个改变是，审查成为任何整理功能的默认预期。Dreams 通过绝不修改输入树立了一个良好的先例。这是对你采用的每个记忆系统提出合理要求的基础。
第三个改变是，范围问题变得更加尖锐。针对每个平台的整理处理只能帮助它能看到的存储库。它看不到的是同一个人告诉其他四个工具的所有内容，这就是将 auditing what your AI remembers 作为一个整体任务而不是多个分散任务来执行的论据。
整理智能体记忆库的最佳实践
- 从一小批会话开始。 成本和运行时间都随对话记录的体量而增加，Anthropic 建议仅在对质量满意后才扩大规模。
- 在合适的抽象高度编写
instructions。 重点领域和输出约定是有效的；行级的命令式指令通常不会产生任何变化。 - 在替换之前先并存附加。 输出可以放在输入存储库旁边，而不是直接替换它。
- 不要在运行途中触碰输入。 归档或删除输入存储库或会话将直接导致 dream 失败。
- 做好
outputs[]短暂为空的准备。 一旦输入被克隆，输出存储库 ID 就会在 dream 开始运行后不久出现。 - 使用 Memory Stores API 进行精确编辑。 Dreams 用于重塑形态；API 用于编辑。
- 取消后进行清理。 取消和失败的 dreams 会特意留下部分输出存储库。
- 在它结束预览阶段时重新检查。 Dreaming 是一项研究预览功能，有其自己的 Beta 请求头，预览行为可能会发生变化。
结论
这里值得借鉴的机制并不是合成本身。而是围绕它做出的保证：读取存储库、读取对话记录、写入一个新的存储库，并保持原始存储库完好无损，以便人类可以拒绝。
这种设计将记忆严肃地视为可能会出错的东西。无论你是否能访问 Dreams，这种习惯都是通用的——深思熟虑地整理、在采用前进行审查，并将重要的知识保存在你自己可以读取的地方。