Agent 记忆不能只靠存：Claude Dreaming 如何用 4 层记忆在会话之间纠错、整理和构建知识库

作者注：解读 Anthropic 工程博客披露的 Claude Dreaming 机制。本文涵盖 4 层记忆结构、CL-Bench 与 Wiki 实验数据、纠错案例和工程风险，并说明开发者如何借鉴“会话间整理记忆”的思路，搭建自己的 Agent 记忆系统。

2026 年 11 月 6 日，Anthropic 在工程博客发布了 The components of agent memory。文章首次系统说明了 Claude Dreaming 如何在会话之间纠错、整理记忆并构建知识库。官方 X 账号同步发布了这篇文章，Claude Managed Agents 文档中也已经出现 Dreams 的研究预览接口。

这不是又一个“给 Agent 加个向量库”的概念。Anthropic 用多组实验说明：长期运行的 Agent 光保存历史还不够，还要持续验证、纠错、整合和组织记忆，旧信息才能真正帮到下一次任务。

核心价值：读完本文，你会了解 Claude Dreaming 的 4 层记忆结构和关键实验数据。你也会知道它在什么情况下有效、什么情况下有害，以及在自己的 Agent 里该如何借鉴。

Claude Dreaming 核心信息速览

理解 Dreaming 之前，先明确几个术语。Transcript 是完整会话记录，包括用户输入、Agent 输出、工具调用和结果。Memory Note 是从历史经历中提炼出来的持久事实、规则和经验。Memory Store 是跨会话保存记忆文件的持久化存储空间。Dreaming 的思路接近 Sleep-time Compute，也就是在主要交互之外，利用空闲算力处理已有上下文。

为什么 Agent 记忆不能只靠存历史对话

很多团队做 Agent 记忆的第一反应，是把所有对话存下来，需要时再检索。问题在于，历史日志、会话摘要和可检索的知识是三种不同的东西。日志只是原始事件的堆积，摘要可能丢掉关键细节，只有经过验证和组织的知识，才能稳定地帮到下一次任务。

直接保存全部对话，会带来三类隐患：信息重复，旧状态过时，错误不断累积。一条写错的记录会被后续会话反复读取，错误也就被当成事实继续执行。Anthropic 的结论很直接：记忆不是越多越好，而是需要选择、验证和组织。

Pokémon Red 实验把这个差别展示得很清楚。大约 10,000 步时，Sonnet 3.7 创建了 413 个文件、225 个文件夹，只拿到 1 个徽章。Fable 5 只创建了 9 个普通记忆文件、2 个文件夹和一个 global.md，却拿到了 4 个徽章。

差距来自“记什么”。Sonnet 3.7 大量保存不断变化的游戏状态，这些记录很快过时。Fable 5 更注重策略、已验证的规则和行动计划。由此得出一个设计原则：长期记忆应优先保留难以从当前环境重新获得的知识，每次都能直接读取的实时状态不需要记。

Claude 记忆体系的 4 个层次

Anthropic 把 Agent 记忆拆成 4 层。每一层的职责、写入频率和读取成本都不一样。

这 4 层是从“原始”逐步走向“精炼”的过程。Transcript 信息最全，但体量大、噪声多。Injected context 最精炼，可每一条都会占用新会话的上下文窗口，所以只能留给显著性（Salience）最高的信息。

Dreaming 的定位是跨层维护。它会回到 Transcript 中纠正旧记录，合并 Memory notes 里的重复信息，构建 Wiki 和索引，并决定哪些内容值得在新会话开始时预先注入（Context Injection）。

Claude Dreaming 如何纠错、整理和构建知识库

Dreaming 纠错：Mt. Moon 导航案例

Anthropic 记录过一个导航错误。Agent 把 Mt. Moon 附近 Pokémon Center 的方位记错了，后续会话一直沿着错误路线重复尝试。

Dreaming 重新检查历史 Transcript 后，找到了最初那条错误记录，并修正了记忆文件。用修正后记忆的 Agent，在第 1,935 次操作时抵达 Cerulean City。没有纠错的版本多次重复失败，最终没能完成目标。

这个案例说明，Dreaming 做的不只是摘要。它能回到原始经历，核对记忆是否仍然成立。保存的 Transcript 也因此有了新的用途：它是可以反复复核的证据库。

Claude 记忆效果：CL-Bench 实验数据

Anthropic 用 CL-Bench 1.0 中的数据库任务测试记忆效果。下表是官方报告的 mean reward。

需要注意，这组数据只针对该任务，不是通用的 Agent 记忆能力评分。更值得关注的是一个现象：模型越强，越倾向于记录经过验证的规则、错误原因和未来可能遇到的陷阱，而不是照搬历史对话。Sonnet 4.6 的提升很有限，说明记忆系统的效果和模型本身的“记录质量”密切相关。

Dreaming 构建 Wiki 知识库的效果

最大规模的实验使用了约 350,000 份内部文件，总量约 420M Token。Anthropic 通过 128 次 Dreaming 会话逐步构建出一个知识 Wiki，再用问答任务评估效果。

📊 图表说明：以上数据均来自 Anthropic 工程博客的公开实验。如果想在自己的语料上做类似的小规模验证，可以通过 API易 apiyi.com 调用 Claude 模型，比较“纯检索”和“检索 + 整理后的 Wiki”两种方案的效果与 Token 消耗。

结构化记忆的价值主要体现在两点。一是建立链接和索引，让跨多份文件的信息能够被综合起来。二是减少每次检索时需要重新读取的原文量，从而降低 Token 成本。

影响分析：Claude Dreaming 记忆整理为什么有时有效、有时有害

Anthropic 没有把 Dreaming 说成万能方案，文中给出了好几个反例。这部分对工程实践的参考价值，可能比正面数据还要大。

记忆整理的 5 类工程风险

• 过度记录：像 Sonnet 3.7 那样大量保存易变状态，记忆膨胀很快，过时也很快。
• 信息过时：环境变了，记忆还停留在旧版本，没有来源核对就会持续误导 Agent。
• 共享写入覆盖：在合同整理实验中，多个 Agent 同时写同一张汇总表，57 项关键事实只保留了 41 项，约 72%。改为每份合同一个独立页面、由单一 Agent 写入并保留原始条款后，57 项事实全部保留。
• Wiki 体积膨胀：某次测试中原始文件只有 115 KB，生成的 Wiki 却涨到 203 KB，整理反而让信息变多了。
• 简单任务无收益：单个文件就能直接检索到答案的问题，Wiki 没有带来明显提升，只增加了维护成本。

对开发者的影响

• 记忆需要分层：原始日志、经验规则、结构化知识、预注入上下文分开存放，各自有不同的写入和读取策略。
• 来源必须可追溯：每条记忆都应能回溯到对应的 Transcript，这是纠错的前提。
• 写入要串行化或分区：避免多个 Agent 并发写同一份文件，优先采用“一实体一页面”的结构。
• 定期清理：Wiki 和 Memory notes 也需要去重、合并和淘汰，不然体积只会越来越大。

对行业的影响

• Agent 记忆的研究重心正在从“检索得准”转向“记忆本身是否正确、是否在维护中”。
• Sleep-time Compute 有望成为常规架构，把整理成本放到空闲时段，减少主交互时的上下文负担。
• 结构化记忆更适合跨文件、多轮次、长期积累的任务。对于一次性简单问答，纯检索依然是更经济的选择。

开发者如何把 Claude Dreaming 思路用在自己的 Agent

官方 Dreams 研究预览的使用条件

根据 Anthropic 当前文档，Dreams 属于 Claude Managed Agents 的功能，状态为 Research Preview，需要申请访问。调用时需要携带 managed-agents-2026-04-01 和 dreaming-2026-04-21 两个 Beta Header。

它的输入是一个已有的 Memory Store 加上 1 到 100 个历史 Session，输出是一个新的 Memory Store，原始 Store 不会被修改。任务异步运行，通常需要几分钟到数小时，按所选模型的标准 Token 价格计费。支持的模型以 Opus 5.5 和 Sonnet 5.5 为主。另外，它目前不具备 Zero Data Retention 或 HIPAA 资格，处理敏感数据前需要评估。

Cookbook 中的动态工作流设计

官方 Cookbook 给出了一套可以自行搭建的多 Agent 工作流。默认由 Lead Agent 编排流程，每个 Analyzer Agent 处理一份 Transcript，Organizer Agent 负责去重、修复链接和维护索引。整理好的 Memory Store 挂载到下一次 Session，通常是只读方式，也可以用 Cron 定时执行，比如每晚整理过去一天的 Session。

Cookbook 也给出了成本示例。11 份示例 Transcript 共 283 KB，运行约 2.5 分钟，费用约 $0.36。50 份长 Transcript 约 12 MB，在成本优化设置下大约 $8，耗时约 10 分钟。这些只是特定实验的结果，不是固定报价。

用 Claude 模型自建会话间记忆整理流程

需要先说明：API易 提供的是 Claude 系列模型的调用接口，不等于提供 Managed Agents、Memory Stores 或 Dreams API。不过 Dreaming 的核心思路，也就是“后台读 Transcript、提炼经过验证的规则、交给单一写入者整理”，完全可以用普通模型调用自己实现。下面是一个最小示例，让 Claude 分析一份会话记录并输出候选记忆。

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)

transcript = open("session_001.txt", encoding="utf-8").read()
resp = client.chat.completions.create(
    model="YOUR_CLAUDE_MODEL",  # 替换为模型列表中可用的 Claude 模型
    messages=[
        {"role": "system", "content": "只提炼经过验证的规则、错误原因和未来陷阱，忽略易变状态，每条注明来源行号。"},
        {"role": "user", "content": transcript},
    ],
)
print(resp.choices[0].message.content)

import json
import pathlib
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)
MODEL = "YOUR_CLAUDE_MODEL"
MEMORY_DIR = pathlib.Path("memory_store")
MEMORY_DIR.mkdir(exist_ok=True)

ANALYZER_PROMPT = """你是记忆分析器。阅读会话记录，输出 JSON 数组，每项包含:
topic(实体或主题名), rule(经过验证的规则/错误原因/陷阱), evidence(原文出处)。
不要记录每次都能直接从环境读取的实时状态。"""

ORGANIZER_PROMPT = """你是记忆整理器。给定某个主题的旧记忆页面和新候选条目:
1. 与旧记录冲突时，以 evidence 更可靠者为准，并注明修正原因;
2. 合并重复条目;
3. 保留原始证据引用;
输出更新后的 Markdown 页面全文。"""

def analyze(transcript: str) -> list:
    resp = client.chat.completions.create(
        model=MODEL,
        messages=[
            {"role": "system", "content": ANALYZER_PROMPT},
            {"role": "user", "content": transcript},
        ],
    )
    try:
        return json.loads(resp.choices[0].message.content)
    except json.JSONDecodeError:
        return []

def organize(topic: str, items: list) -> None:
    # 一主题一页面，由单一流程串行写入，避免并发覆盖
    page = MEMORY_DIR / f"{topic}.md"
    old = page.read_text(encoding="utf-8") if page.exists() else ""
    resp = client.chat.completions.create(
        model=MODEL,
        messages=[
            {"role": "system", "content": ORGANIZER_PROMPT},
            {"role": "user", "content": f"旧页面:\n{old}\n\n新条目:\n{json.dumps(items, ensure_ascii=False)}"},
        ],
    )
    page.write_text(resp.choices[0].message.content, encoding="utf-8")

def nightly_dream(transcript_files: list) -> None:
    grouped = {}
    for f in transcript_files:
        for item in analyze(pathlib.Path(f).read_text(encoding="utf-8")):
            grouped.setdefault(item.get("topic", "misc"), []).append(item)
    for topic, items in grouped.items():
        organize(topic, items)

# 可由 Cron 每晚触发; 下次会话只读加载 memory_store 中的索引页
nightly_dream(["session_001.txt", "session_002.txt"])

🚀 快速上手建议：搭建原型时，可以通过 API易 apiyi.com 用同一个 API Key 测试不同 Claude 模型作为 Analyzer 和 Organizer 的效果。比较一下哪种组合提炼出的规则更准确、Token 消耗更低，再决定生产环境的配置。

两种路线的差别可以用下表概括：

Claude Dreaming 常见问题 FAQ

Claude Dreaming 核心要点 Key Takeaways

• 记忆不只是存储：保存全部对话会累积重复、过时和错误，需要验证和组织。
• 4 层记忆结构：Transcripts、Memory notes、Memory representations、Injected context 各司其职。
• 纠错依赖原始记录：Dreaming 回到 Transcript 核对，修正了导致反复失败的错误方位。
• Wiki 擅长跨文档任务：并购任务中 Wiki 得分 87%，纯检索为 73%，每题平均节省约 2 万 Token。
• 整理也有副作用：并发写入会丢失事实，Wiki 会膨胀，简单任务用不上。
• 自建可行：通过 API易 apiyi.com 调用 Claude 模型，可以实现简化版的会话间记忆整理。

总结

Claude Dreaming 带来的启发主要有三点：

1. 长期记忆的核心是维护：只有经过验证、去重、组织的记忆，才能稳定帮助下一次任务。
2. 记什么比记多少更重要：优先记录难以从环境中重新获得的规则、错误原因和陷阱，不要记录易变状态。
3. 结构化记忆要看场景：跨文件、多轮次、长期积累的任务值得引入 Wiki，简单检索任务不必为此增加维护成本。

如果你的 Agent 已经在跨多个会话运行，可以先从“保留 Transcript、每晚串行整理一次、只读挂载索引页”这个最小闭环做起。推荐通过 API易 apiyi.com 调用 Claude 模型快速验证这套流程，平台提供 OpenAI 兼容接口和新用户免费测试额度。

📚 参考资料

1. The components of agent memory：Anthropic 工程博客原文，介绍 4 层记忆结构与 Dreaming 实验
2. 链接： anthropic.com/research/components-of-agent-memory

3. 说明： CL-Bench、Pokémon、Wiki、合同整理等实验数据的原始出处

4. Dreaming with a dynamic workflow：Claude 官方 Cookbook

5. 链接： platform.claude.com/cookbook/managed-agents-cma-dreaming-with-a-dynamic-workflow

6. 说明： Lead、Analyzer、Organizer 多 Agent 工作流示例和成本参考

7. Anthropic 官方 X 发布动态：Dreaming 工程博客的发布说明

8. 链接： x.com/AnthropicAI/status/2118814753154064501
9. 说明： 确认发布时间和官方定位

作者：API易 技术团队
技术交流：欢迎在 API易 官网首页联系我们，更多资料可访问 docs.apiyi.com 文档中心