Agent Memory（Agent 记忆）

Agent 记忆（Agent Memory） 是指将 AI Agent（智能体） 或 Loop Engineering（循环工程） 的运行状态，写入单次对话上下文之外的持久介质中。它可以是 Markdown 状态文件、Linear/Jira 看板、GitHub Issue、PR 评论、数据库记录或运行日志。

核心原则是：Agent 会忘，仓库不会。 模型每一轮运行结束后，不能假设下一轮仍完整记得本轮上下文；长期任务必须把状态落到可读取、可审计、可恢复的位置。

Anthropic 把定义收窄了一圈

上面是本库一直用的广义：凡是写在单次对话之外、下一轮还能读到的状态，都算记忆。2026-11-06 的文章收得更窄：agent memory 只指模型从与用户的交互和被分配的任务里学到、并在会话之间以可再读上下文留下来的知识。三类相邻机制被明确排除：

• 改模型 weights（训练得到的参数）
• in-context learning（同一次对话里临时学到的东西）
• compaction（用摘要替换旧轮次，以便在新窗口里继续；见 Context Engineering（上下文工程））

这个窄定义里，记忆是模型自己写下的经验，不是仓库里所有持久文件。会话结束后再整理这些经验，他们称为 dreaming，见下面专节。本页其余部分仍用广义。

记什么

一个可用的 Agent Memory 至少记录：

• 已完成的任务和验证结果
• 当前卡住的问题与失败原因
• 已经试过但失败的路径，避免下一轮重复
• 下次继续时的入口和优先级
• 需要人工确认的风险点

这些信息不是流水账，而是循环的控制状态。没有它，自动化任务每天早上都会像第一次运行一样重新理解世界。

三段式状态文件模板

实践中最有效的状态文件结构包含三段，职责明确不重叠：

以下示例背景：Agent 正在自动处理一个 Node.js 项目的 GitHub Issue，每天定时扫描新 bug、定位根因、提交修复 PR。每次运行结束后写入状态文件，下次启动时先读它，接着上次的进度继续。

# Project memory

## Verified facts  ← 停止猜测这些
- 单元测试命令是 npm test，集成测试是 npm run test:e2e（两个不一样）
- 所有 API 错误码定义在 src/errors.ts，不在各 handler 文件里
- Issue #234 的根因已确认：并发写入时缺少锁，不是数据类型问题

## Lessons learned  ← 通用经验提炼进 Skills
- 改 src/config/ 下的文件后必须重启开发服务器，热重载不生效
- 新建 API endpoint 要同时更新 docs/api.md，否则 CI 会失败

## Last session  ← 续接，不要重启
2026-06-18 · 修好了 Issue #231 和 #233，#234 的锁方案已验证。
下一步：补 #234 的回归测试

三段的分工：Verified facts 是停止重复验证的已知事实；Lessons learned 是等待提炼进 Skill（技能）的通用经验；Last session 是下一轮开始时的精确入口。

Compound Memory 模式

让记忆真正产生复利的三步操作模式：

1. 离开前写入：每次运行结束时更新状态文件——记录经验教训、验证过的事实、下一步入口
2. 开始时读取：每次运行开始时先读状态文件和相关 Skills，实现续接而非重启
3. 蒸馏进 Skills：当某条经验具有普遍性（如"改 config 文件后必须重启服务器"），从状态文件毕业进入 Skill 文件——从此对所有未来项目生效

这三步形成复利：状态文件积累项目专属事实，Skills 积累通用经验，下一轮运行比上一轮更有效。

三种跨周期记忆形态

在 Loop Engineering（循环工程）中，记忆不是"保存聊天记录"，而是让下一轮循环比上一轮更少犯错。常见形态有三种：

原始日志解决"记得住"，周期性蒸馏解决"读得动"，显式信念解决"会更新"。三者一起，记忆才从流水账变成可指导下一轮行动的控制状态。

Claude Managed Agents（参见 Agent Automation）的 session log 是这种记忆形态的平台化版本：所有 user events、tool results、status updates 和 harness 进展都以 append-only 事件流保存。harness 崩溃后，新 harness 可以 wake(session_id)，读取 session 事件并从最后事件恢复；上下文窗口里是否保留完整历史则由单独的上下文工程策略决定。

定时自动化的记忆需求则更细，Anthropic 的 daily-brief 参考实现把它拆成三类状态文件：书签（每个来源记录已读到的最新条目时间戳，下一轮从书签续读，窗口随两次运行的实际间隔伸缩，而不是按“最近 24 小时”这类固定窗口重读）、账本（每条已报条目的来源、不变 ID 和最后已知状态，用于去重和把“仍在等”折叠成一行）、以及 preferences/state 双仓分离——用户偏好存放在 Agent 只读的 store 里且每轮重新读取文件，Agent 自己的状态放在读写 store；把偏好烤进 prompt 会让旧规则在偏好已改掉后继续生效。详见 Agent Automation。

多 Agent 共享记忆仓与人类编辑的 Diff 学习（Diff-based Memory Learning）：在业务团队的多 Agent 舰队实践中（如 Anthropic 日本团队的 Nakama 架构），记忆仓（Memory Store）从单 Agent 的孤立存储扩展为全队共享的状态底座。工作 Agent 生成初稿后交由人类审核；系统自动比对草稿与人类最终发送邮件的文本差异（Diff），提炼出人类对特定措辞、语气规范和商业策略的微调偏好，沉淀为知识笔记回写到共享记忆仓。这一机制使得负责初筛、回复或会议纪要的其他 Agent 随后均能读到更新，实现“一处纠偏，全队受益”，从根本上减轻了维护复杂长 Prompt 的负担。详见 Agent Automation。

共享写入也会互相覆盖。同一篇文章里，四个 agent 同时往一张合同条款摘要表写，57 条评分事实只留下 41 条；改成一约一页、原文照录、单写者之后，57 条都在。做法见下面的 Dreaming 一节。

循环操作状态文件（Loop Operation State File）

面向自动化 Loop 的状态文件与面向项目记忆的三段式结构侧重点不同——它追踪的是 Loop 本轮的操作运行状态：哪些任务在进行、哪些已完成、哪些被升级给人类、什么停止条件已满足。以 CI 分诊循环为例：

# Loop state · ci-triage

## Last run
2026-06-09 03:30 UTC · 7 failures classified, 3 fixes drafted, 4 escalated

## In progress
- claude/fix-auth-token-refresh — tests passing locally, awaiting CI
- claude/fix-flaky-payment-webhook — retry pattern applied, monitoring

## Completed today
- claude/bump-axios-1.7.4 → merged (CI green, deps loop verified)
- claude/lint-fix-pass-june-9 → merged

## Escalated to humans
- src/billing/refund.ts — tests failing in 3 ways, root cause unclear
- ci/staging-runner — infra timeouts, not a code issue

## Lessons learned (write here, not in chat)
- 2026-06-08: PowerShell hits TLS 1.2 issue on this Windows runner. Use bash.
- 2026-06-07: tests/e2e/checkout requires Stripe webhook secret in env. Skip if missing.

## Stop conditions met since last review
- /goal "all tests pass + lint clean" achieved on commit 3a7b8c1 at 02:14 UTC

几个关键设计决策：

• Lessons learned (write here, not in chat) 是这类状态文件的核心字段——经验必须落到文件，不能只活在对话。对话压缩后下一轮 Agent 读不到；写进仓库的文件才能跨轮存活。
• Stop conditions met since last review 防止 Loop 忘记自己已满足的完成条件，对有多个平行目标的长期循环尤其重要。
• 操作状态文件与项目记忆模板可以共存：操作状态每轮更新；通用教训待提炼后迁移进 Skill（技能）。

状态文件的两种存放模式：

状态文件与规格文件配对： 对有 Goal Drift（目标漂移） 风险的长期循环，状态文件需搭配固定的规格文件（VISION.md 或 AGENTS.md）：状态文件告诉 Agent 它在哪里，规格文件告诉 Agent 它要去哪里。每轮启动时先读规格文件再读状态文件，能防止约束随上下文轮次压缩而消失。

长时编码 Harness 的三件记忆

Anthropic 的 Long-running Agent Harness 案例把长时编码任务的记忆拆成三件互补产物：

这三件东西分别回答“还有什么没做”“上一轮为什么这么做”“代码事实到底变了什么”。只保留其中一个都不够：纯 progress file 容易变成流水账，纯 git log 不解释任务意图，纯 feature list 则看不出实现过程中的异常和经验。

init.sh 也应视为记忆的一部分：它记录了“如何让项目跑起来”这个可复用事实。长时 Agent 每轮启动先运行基础端到端 smoke test，本质上是在读取记忆之后验证记忆仍然有效，避免在已损坏环境上继续推进。

Codex 的 durable project memory

OpenAI 的 Codex 长程实验把同一原则称为 durable project memory：把 spec、plan、constraints 和 status 写入 Markdown 文件，让 Codex 能在长时间运行中反复回读，防止目标漂移并保持稳定的 “done” 定义。

这组文件不是聊天记录备份，而是任务控制状态：

这个案例补充了 Agent Memory 的一个边界：不是所有记忆都应该由系统自动提取。对长程工程任务来说，最关键的记忆往往是人和 Agent 共同维护的项目文件，因为它们进入版本控制、可 review、可被下一轮执行直接引用。Codex Memories 可以辅助跨线程偏好和经验复用，但不能替代这种受版本控制的项目状态。

Token-Rich vs Token-Poor Loop

Loop 设计的第一个结构性选择，是上下文装多少历史进来。

Token-Rich Loop：每轮上下文包含完整对话记录、详细工具日志、长文档、嵌入式计划。

• 优点：历史可见度高、更少因缺失上下文出错、模型推理透明
• 缺点：Token 成本随轮次累积飙升、响应变慢、上下文窗口溢出风险高、难以多用户/长会话扩展

Token-Poor Loop：每轮上下文只含最近 2–3 条消息、摘要、按需检索的记忆。

• 优点：Token 消耗低、响应快、上下文限制更易管理
• 缺点：幻觉和重复操作风险上升、依赖健壮的记忆/摘要基础设施

这两种极端之间的平衡，正是记忆系统的工程价值所在：把需要"每轮都有"的状态交给记忆层，而不是把全部历史堆进上下文。

Memory-First Design（记忆优先设计）

Memory-First Design 是一种 Agent Loop 组织原则：在每一轮开始时，先检索记忆、再组装上下文，而不是把所有历史直接注入 prompt。

一轮完整循环的推荐顺序：

1. 输入捕获：接收用户消息与元数据
2. 记忆检索：查询持久记忆层（用户偏好、任务状态、长期约束）
3. 上下文组装：把检索结果、近期对话、指令拼成 prompt
4. 模型推理：LLM 调用 + 工具调用检测
5. 行动执行：API 请求、文件写入、数据库操作
6. 记忆更新：把本轮结果中值得保留的内容写回记忆层

这个模式的关键在步骤 2 和步骤 6——记忆在循环开始前被读取、在结束后被写入，而不是只作为"历史消息的附加备份"。

记忆作用域

记忆按粒度分为三类：

在多 Agent 系统中，全局记忆和各 Agent 私有记忆共存：全局记忆用于协调，私有记忆防止 Agent 相互干扰。

Claude Code 的双轨实现

Claude Code 把“人给出的稳定指令”和“Agent 自己积累的经验”明确分成两条轨道：

• CLAUDE.md：由人维护，保存编码规范、工作流和架构约定；可作用于组织、用户或项目
• Auto Memory（自动记忆）：由 Claude 维护，保存工作中发现的构建命令、调试经验、偏好和模式；以 Git 仓库为作用域，同仓库的 worktree 共享

Auto Memory 默认写入 ~/.claude/projects/<project>/memory/。其中 MEMORY.md 是精简索引，每次会话只加载前 200 行或 25KB；详细内容拆到主题文件，需要时再读取。这是“索引常驻、细节按需”的 Context Engineering（上下文工程） 设计：既保留跨会话连续性，又避免把全部历史塞进启动上下文。

它也揭示了 Agent Memory 的两个边界。第一，机器本地记忆不会自动跨机器或云环境共享，团队知识仍应进入版本控制下的 CLAUDE.md、规则或项目文档。第二，记忆和指令都只是上下文，不是强制配置；安全边界必须由权限、沙箱或 Hook 执行。可用 Claude Code 的 /memory 命令审计、编辑或删除记忆，避免错误经验长期污染后续决策。

Anthropic 的 containment 经验补充了第三个边界：持久记忆会成为持久 prompt injection 的载体。产品记忆、CLAUDE.md、挂载 workspace、scheduled/long-running agent 的状态目录都会跨会话重新加载；一旦注入内容写入这些位置，它不再是一次性工具输出，而会在每次启动时重新进入上下文。长期 Agent 因此需要 session startup 阶段的记忆扫描、来源标注和人工可审计入口，而不能只在运行中扫描网页或工具结果。

撤销连接不等于删除记忆：Claude Duet

Claude Duet 的安全说明展示了跨账户 Agent 的另一种记忆边界：关闭某个应用连接会在 Claude 与 Duet 两处同步生效并停止新访问，但从该应用已经学到的内容仍保留，直到用户重置记忆。Duet 还可使用 Claude 账户早先积累的记忆；删除账户则清除 Duet 存储的全部内容。

由此可见，访问授权、派生记忆和历史记录需要分别治理。撤销 token 或断开数据源，只回答“今后还能否读取”，不回答“以前提炼出的信息是否已删除”。隐私控制应让用户能区分断开连接、重置记忆和删除账户，也不能假定删除某段聊天就等价于清空所有派生记忆。凭证则应在写入之前就被架构排除：Duet 的密码、cookie 和真实连接令牌不向模型暴露，不能依靠事后记忆清理来补救秘密泄漏。

Deep Agents 的可写 AGENTS.md memory

Deep Agents允许在创建 Agent 时通过 memory 参数传入 AGENTS.md。这些文件与按需触发的 Agent Skills不同：memory 在启动时始终加载，并存放在配置的 StateBackend、StoreBackend 或 FilesystemBackend 中。Agent 还可以根据交互与反馈更新 memory，使偏好和模式跨 thread 延续。

这是一种具体产品语义，不能据此把所有 AGENTS.md 都理解为 Agent 自动维护的记忆。许多宿主仍把它当作由人或团队版本控制的项目指令；是否允许模型写入、写到哪个 backend、如何审计和回滚，必须由 harness 明确定义。

Codex 的双轨实现

Codex 同样把两类持久上下文分开：

因此，AGENTS.md 在广义上属于“写在会话之外、供未来运行读取”的外部记忆，但在 Codex 产品语义中应称为项目指令，不能与 Memories 混为一谈。官方建议把必须稳定生效的团队规则放进 AGENTS.md 或版本控制下的文档，把 Memories 当作本机的辅助回忆层，而不是唯一规则来源。

还要区分 ChatGPT Memory 与 本地 Codex Memories：ChatGPT Web 使用前者；本地 Codex 客户端使用后者，两者不是同一个存储。ChatGPT Work 采用账号与工作区可用的 ChatGPT memory 设置，不读取本地 Codex memory，也不提供本地 memory 控制。ChatGPT 桌面应用和 Codex TUI 使用各自连接的本地 Codex host；IDE 扩展则复用其所连接 host 的本地 memory store。因此，本机记忆能否共享取决于客户端是否连接到同一个 Codex host，而不是它们是否登录了同一个 ChatGPT 账号。

Memories 默认关闭，可在 Codex 设置中开启，或在 ~/.codex/config.toml 中配置：

[features]
memories = true

开启后，Codex 不会在每个线程结束时同步写入记忆，而是等待线程空闲后在后台处理符合条件的历史。仍活跃或过短的线程会被跳过；剩余 rate limit 低于阈值时也可能暂缓生成。

flowchart LR
    T["符合条件的历史线程"] --> I["等待线程空闲"]
    I --> E["后台提取并脱敏"]
    E --> M["~/.codex/memories/"]
    M --> F["注入后续线程"]

~/.codex/memories/ 中的生成状态包括摘要、持久条目、近期输入和支撑证据。可以检查这些文件，但官方不建议把手工编辑它们作为主要控制方式。Codex 会对生成字段做秘密信息脱敏，但共享 CODEX_HOME 或记忆文件前仍应人工审查。

ChatGPT 桌面应用和 Codex TUI 的 /memories 可分别控制当前线程是否读取已有记忆，以及是否允许当前线程用于生成未来记忆；这些线程级选择不会修改全局开关。IDE 扩展连接的 host 启用 Memories 后，使用与 TUI 相同的线程级控制。

常用配置把“生成”和“使用”拆成独立开关：

旧键 memories.no_memories_if_mcp_or_web_search 仍是 memories.disable_on_external_context 的兼容别名。Chronicle 则是桌面端功能，可从屏幕活动中恢复近期工作上下文、辅助建立记忆，但不等同于 ChatGPT Memory 或本地 Codex Memories。

没有记忆层的典型问题

生产 Agent 在缺乏专用记忆层时会反复出现同类失效：

• 反复向用户询问同样的偏好或背景
• 长任务跨会话后无法续接，重新从头开始
• 用户约束（格式、禁用工具、截止日期）在几轮后消失
• 反复尝试已经失败的策略，无法跳过
• 跨会话响应风格不一致

长运行循环还会出现三种相互关联的遗忘性失效：细节丢失（遗忘文件路径、参数值等精确细节，每轮重新猜测）、目标漂移（丢失迭代计数和停止条件，循环无法判断自己已跑了多少轮）、灾难性遗忘（经过足够多次压缩后，Agent 甚至忘记自己的 pipeline 是什么）。此外还有自我强化失效：循环将自身的先前输出重新摄入，早期错误被每一轮当作事实，越来越难纠正——坏记忆不只是丢失信息，它把错误洗白成事实。

这些问题的共同根源不是模型能力不足，而是控制状态存在于上下文而非持久层。

Concept Drift（概念漂移）

长期运行的 Agent 记忆面临一个特有挑战：记忆会过期。

用户偏好变了、任务环境变了、之前"最佳路径"的约束已经解除——但记忆里存的还是旧状态。如果记忆系统不主动淘汰旧内容，过期记忆会比没有记忆更糟糕：Agent 会自信地按错误前提决策。

处理 Concept Drift 的策略：

• 为记忆条目添加时间戳和有效期
• 在每轮更新时检测新信息是否与已有记忆矛盾
• 定期让 Agent 或独立 Evaluator 审查并清理过期记忆
• 高优先级信息（如用户明确撤销的约束）立即标记失效

与上下文的区别

Context Engineering（上下文工程） 解决的是"这一轮模型应该看到什么"；Agent Memory 解决的是"多轮之间什么不能丢"。上下文是短期工作区，记忆是长期状态层。

把所有历史都塞进上下文会带来 Token 成本和 Context Rot（上下文腐烂）；把关键状态落到文件或看板、再由下一轮按需读取，才是可持续的做法。Token-Poor Loop 的可行性，正是建立在有记忆层的前提上——否则减少上下文意味着直接丢失状态。

记忆在循环规模下的现实约束

长运行循环使记忆问题比任何单次 Agent 运行都更难解决，原因有三：

上下文压缩是有损的。当窗口接近上限时，自动 compaction 会摘要历史以腾出空间，且例行丢弃 Agent 之后可能需要的细节。LongMemEval 基准测试（arxiv 2410.10813）量化了代价：商业助手在长期记忆任务上相对短上下文表现平均下降约 30%。循环面临的是二选一：保留全量历史（上下文腐烂）或压缩（丢失细节）。

循环运行到记忆系统的最弱区间。主流记忆 benchmark 上限约 1.5M tokens；一个多周的 Agent 循环可以轻松超越这个量级。Mem0（Mem0） 发布的 BEAM 基准是目前唯一在此规模测量记忆的公开数据：1M tokens 得 64.1 分，10M tokens 降至 48.6 分——越长的循环，记忆系统越弱。

召回不等于使用。MemoryArena（arxiv 2602.16313）发现：即使召回率接近饱和的系统，在记忆需要指导行动时仍然大量失败。循环需要的不是"能否回忆第 12 次尝试"，而是"给定第 1 到 46 次的全部历史，第 47 次应该做什么"——这是超出一般召回 benchmark 的更高要求。

Token 成本是真实约束。实践者测算：单 Agent 循环每轮 5 万至 20 万 token，Agent fleet 每轮 50 万至 200 万，定期循环每周数百万。把过期历史带入上下文不只是质量风险，还是每次调用都在付账的成本项。

前沿：记忆作为主动行为

记忆层正在从被动文件演变为循环中的主动步骤：

Cloudflare Agent Memory（2025）在上下文 compaction 时主动干预：不是丢弃旧内容，而是提取并去重值得保留的事实，让多周运行的 Agent 积累记忆而不是在每次压缩时丢失记忆。这把"记忆维护"从运营负担变成了系统级能力。

MemAct / Memory as Action（arxiv 2510.12635）训练 Agent 把编辑自身工作记忆作为一个可主动调用的行动——像调用工具一样调用"更新记忆"。论文报告：14B 模型在平均上下文长度减少 51% 的情况下，性能与约 16 倍大的模型持平。该论文是未经同行评审的预印本，且基于作者自有 benchmark，结论应视为方向性而非定论；但方向本身是明确的：记忆维护成为循环的一个步骤，而非事后的文件操作。

在循环工程中的位置

Agent Memory 是 Loop Engineering（循环工程） 的第六个隐含组件。自动化、工作树、Skill、连接器、子智能体让循环能跑起来；记忆让循环能接着跑。

在无人值守的循环里，记忆尤其关键：Verifier 的结论、CI 失败摘要、PR 状态、人工收件箱都必须写到外部系统，否则循环无法可靠判断"已经做过什么"和"下一步该做什么"。

长运行循环面临的细节丢失、目标漂移、灾难性遗忘和自我强化失效（见"没有记忆层的典型问题"一节），在没有外部记忆层的情况下会随轮次复利到不可控规模。

记忆是调试难点

引入记忆层后，Agent 的行为依赖于记忆内容，而记忆内容在运行时动态变化。这给调试带来新挑战：

• 同样的输入在不同时刻可能触发不同行为（因记忆不同）
• 错误行为的根因可能是若干轮前写入的某条过期记忆
• 多 Agent 系统中全局记忆的写入顺序可能引入竞争条件

因此，健壮的记忆系统需要配合完整的日志（记录每轮写入了什么、检索到了什么），才能在出错时可溯源。

记下来，是在预测以后用得上

写一条规则，就是在预测这个模式以后还会再用到。写下一条已核实事实，则是在预测未来会话可以不再复查。模型在当下并不知道接下来会发生什么，所以这种预测会错；错了以后要靠下面的 dreaming，或靠下一轮证据改，而不是靠当时的自信。

CL-Bench 1.0 的数据库任务把这个循环做成了评测：每道题新开一个会话，记忆目录跨会话保留；答完后告知正确答案，模型可以写记忆。文章只详细拆了这一项，不要把下面的分数读成整个基准的总分。纵轴是平均奖励，对照是没有记忆的无状态基线。另一张累计奖励曲线的横轴画到第 30 题。平均奖励那张图没标每个柱子跑了多少次；指导实验的图只补了其中两个：Opus 5 有记忆是 16 次，Opus 4.7 有记忆是 3 次。

有记忆之后，Opus 5、Opus 5.5 和 Sonnet 5.5 挤在 0.83 附近。增益大的是那些真的把“猜错因→检验→写成规则”走完的模型，不是只会多写几个文件的模型。

显著性：屏幕上读得到的，不必再写一遍

同一篇文章用宝可梦红比较“什么值得记”。每个模型都有一个可读写的记忆目录。约第 9989 步时（正文说大约 1 万步）：

Sonnet 3.7 把每场战斗、每件道具、每个 NPC 都存下去，还反复建“canonical / master”目录。游戏状态一直在变，这些记录随写随过期。大约第 1 万步，它开始第四个 master 目录；接下来 17 步新建 6 个文件、删掉 9 个，游戏里一步都没走。Fable 5 的 global.md 只放当前目标、道馆计划和自己的记忆规则；路线计划和打法经验分开放。它不记金钱和坐标——这些每回合屏幕上都读得到——而记游戏不会再告诉它的东西。例如连续七个精灵球都没抓到鲤鱼王之后，它写下：连续 3 次以上没抓到就改菜单节奏，多按几次等待。Opus 5.5 也是小目录、边玩边改，并且打通了游戏。徽章是游戏进度，不是独立标准分。

告诉它记忆是干什么，不要事先规定怎么写

CL-Bench 上，只说“有一个记忆目录”就足够让 Opus 4.7 和 Opus 5 用起来。再加硬规则，反而会吃掉增益。规定“只记失败”之后，相对于不加这条规则的记忆增益：Opus 5 为 −0.234（3 次），Opus 4.7 为 −0.150（3 次），Sonnet 4.6 为 −0.020（1 次，几乎没变）。强模型从记忆里得到的，大部分是验证过的规则和确认过的事实，不是失败清单。

老模型则反过来。Sonnet 4.6 经常不读记忆，也不检验自己的猜测。明确要求它先读记忆再检验理论之后，平均奖励从基线 0.330、有记忆 0.364，到 0.641（各 3 次；误差线是各次运行的标准差，0.641 那根柱子的波动不小）。文章称这一步接近把分数翻倍，对照的是无记忆基线。Sonnet 5 不用这句提示，10 次里有 9 次会先读记忆；Sonnet 4.6 不到一半。

对前沿模型，文章的做法是：人要求记，或明显值得记时再写，判断留给模型。这和下面“不要把中间过程全写进去”不冲突。一次性的失败路径仍然是噪音；但把记忆收成“只记失败”，会丢掉已验证规则。

Dreaming

Dreaming 是这篇文章里的新兴说法，不是另一个独立概念：模型不在当前任务里当场记笔记，而是在会话之间用额外算力回看日志，修正错误、写出新笔记，或生成 wiki 这类可导航的记忆表示。Claude Managed Agents 文档里的产品名是 dreams。更早的相近用法还有 Letta 与 UC Berkeley 的 sleep-time compute，以及 Google 的 SLEEP 框架（文中同样把这个过程叫做 dreaming）。检索中文社区时没有看到稳定译名，这里不把它写成“做梦”。

文章用海马体“在线编码、离线回放、再整合进新皮层”作类比。这是设计隐喻，不是神经科学结论。

在线笔记回答“这一轮什么看起来重要”。Dreaming 回答另一件事：等日志齐了，这些笔记还对不对、要不要收成别的结构、下一轮该不该一上来就看见。

四层记忆

文章把一次会话到下一次会话之间的记忆画成四层。下面两层是原料和当场笔记，上面两层是算出来的表示和每轮预装的上下文。Dreaming 从 transcript 往上改每一层，相邻的上层之间也可以双向改。会话进行中直接写 memory notes 的那条路径，不等 dreaming。

flowchart TB
    Session[本轮会话] -->|当场写下显著观察| Notes
    Session -->|留下可检索日志| Transcripts
    Transcripts[Transcripts：可检索事件日志]
    Notes[Memory notes：显著观察]
    Repr[Memory representations：例如 wiki]
    Injected[Injected context：每轮预装]
    Transcripts --> Notes
    Transcripts --> Repr
    Transcripts --> Injected
    Notes <--> Repr
    Repr <--> Injected
    Injected --> Next[下一轮一开始就看见]
    Notes -.->|需要时再读| Next
    Repr -.->|需要时再检索| Next

注入层必须小。装进去就要占 token；一条错笔记会进以后每一次会话；装进上下文也不等于模型会照做。Claude Code 文档写过，更长的指令文件会降低遵守率。因此 dreaming 在这一层的主要工作往往是把细节往下挪、只留下链接。Claude Code 的 auto memory 用同一原则，但是在会话内维护：每次只加载 MEMORY.md 的前 200 行或 25KB，这个文件头是索引，不是全部记忆。

对照 transcript 改错笔记

在线笔记按“当时觉得重要”来写，写错或环境变了之后，下一轮仍可能把它当事实读。文章用宝可梦红的月见山做了这个对照。洞口在地图西侧、出口在东侧，入口附近有一条单向悬崖，掉下去就回到来时的路。模型把入口的宝可梦中心错记成在东侧，于是走出中心时写下“月见山已经在身后 / Mt Moon DONE”，随后掉下悬崖。导航工具没显示落差，它又把这次失败解释成“往西走过了”。未修正的那次一共掉下去三次，之后退回灰灰市，跑完也没到华蓝市。对同一份错误笔记做一次 dreaming 后，模型根据 transcript 改回宝可梦中心的位置，重新进洞，并在累计第 1935 步到达华蓝市。图上的无记忆对照同样没到华蓝市。这里 transcript 充当的是当时行动的地面真相，不是另一份模型总结。

把日志收成可导航的表示

文章重点讲的表示是 wiki：由模型维护、按主题成页、页与页相连的笔记集。链接是一张地图，用来在变大的记忆里定位，而不是把原文再抄一遍。这个写法直接引用了 Karpathy 的 LLM wiki 笔记。

Anthropic 用 Stainless 的内部文档做了这个实验。文章说这家软件公司是当年 5 月收购的；文章发表于 2026-11-06，这里按 2026 年 5 月理解。语料约 35 万个文件、约 4.2 亿 token，另配 25 道评分题，并给模型搜索工具。Opus 5 在最多 128 个会话里探索文件、写或改互链页面、合并重复、把说法对回来源；会话之间用一份共享日志交接。图上的横轴是 wiki 生成的 dreaming token 预算（对数），每会话预算 100 万 token，不是实测消耗。从大约 2 个会话（200 万预算）到 128 个会话（1.28 亿预算）：

只靠 wiki 的最好成绩仍低于“只搜索”。wiki 的收益是叠在搜索上的那几个点。文章还称，搜索加 wiki 时每题大约少用 2 万 token，但没有写明对照的是哪一种读法。示例 wiki 从 2 个会话的 103 页、766 条链接，长到 128 个会话的 222 页、12893 条链接。

wiki 帮得上忙的任务也有范围。Harvey 的 LAB 要求根据文书写法律备忘录，再按标准评分。另一组是并购文件上的 24 个问题，其中大半要跨文件找信息，不少还要做判断或算术。图把标准分成“单文件能搜到”“多文件能搜到”“要判断或运算”，并注明分类是模型标的，看整体形状、不要抠某一条边。在多文件和需要判断的那些项上，查 wiki 是 87%，只搜索是 73%。另一项 LAB 任务里，多数标准能从单份文件用文本搜索命中——交易概览备忘录一张就覆盖 57 条里的 31 条——wiki 相对搜索没有明显增益。还有一项里，10 份文件共 115KB，建出的 wiki 却有 68 页、255 条链接、203KB，约是原文的 1.77 倍，而且有些页没有链接。文章用博尔赫斯《论科学的精确性》说明：表示细到和原件一样大，就没有抽象。

按目标写，并补上一轮留下的洞

Claude Duet 这类助手若要记住的是某个人，dreaming 的指令就该围绕这个人，而不是围绕一份泛泛的知识库。文章没有公开 Duet 当前是否已经跑这条离线整理，只把它当作目标可调的例子。

LAB 里的公司收购任务把这个差别测成了数字。最初的 wiki 指令没说合同条款最重要，多个 agent 同时往一张共享的 provisions.md 里写摘要表，后一次保存盖掉前一次的行，评分事实只留下 57 条中的 41 条（72%）。接着让模型看着失败改指令、再重建 wiki：每份合同单独一页、由一个 agent 写、条款照原文抄。按改进后的 wiki 生成的备忘录，57 条标准都可以满足。共享摘要表会在并行写入时丢字段；一页一个写者、原文照录，才保住了被评分的那些事实。

在线笔记只看见本轮上下文，dreaming 还可以扫很多会话补漏。一项 LAB 任务的第二遍把 wiki 从 38 个条目、225 条链接改成 41 个条目、278 条链接。之前有 6 个页、共 9 条链接指向并不存在的 escrow-agreement；第二遍把这 9 条都改指向已有的 buyer-form-escrow-agreement，并补了索引、指示邮件和升级流程三页。

还没定下来的设计问题

文章把三个问题留开，没有给出默认答案。

什么时候写。 会话中写，现场就捕获显著性，下一轮马上能读，但会把注意力从主任务上拉开。Dreaming 把整理推到后台，却不能给正在跑的这一轮用。

怎么保持不过期。 预测会错，环境也会变。对照 transcript 能改掉一批错笔记，但全库重检不一定划算。更可行的是优先检查容易变的信息，或按记忆被读取的频率调整 dreaming 的节奏。

要不要维持表示。 只搜索 transcript 可以当底座。表示加上搜索有时更好，如上面的 61% 对 53%，但表示本身会积累错误和幻觉，维持它也要算力。wiki 单独使用在那次实验里始终没超过搜索。

入门实现见官方的 dreaming cookbook 和 knowledge wiki quickstart。

写入质量：什么不该进记忆

引入记忆层后，一个常见陷阱是让 Agent 把所有中间思考都写进去——“我刚刚读了三个文件"“我准备修改某个函数”。短期看很勤奋，长期看全是噪音。

坏记忆比没有记忆更糟糕。错误记忆会在后续任务里反复影响 Agent 判断，且往往难以发现根源（因为记忆内容在运行时动态变化）。写脏的记忆层相当于把错误洗白成事实。

值得写入记忆的标准：下一个会话能否直接用到这条信息？

对应到每次任务结束时的写入模板：任务摘要、涉及的文件或模块、通过/失败的命令或测试、可复用的教训。最后这一条是核心——没有它，记忆只是流水账。

相关概念

• Loop Engineering（循环工程） — Agent Memory 是长期循环的状态层
• Mem0（Mem0） — 提供语义检索和大规模记忆 benchmark 数据的具体工具
• EverOS — 以 Markdown 为事实源的 Agent 记忆工具，Add/Flush/Search 为核心 API
• Skill（技能） — Skill 存稳定规则，Memory 存动态状态
• Context Engineering（上下文工程） — Memory 通过按需读取降低上下文负担
• Context Rot（上下文腐烂） — 长历史不宜直接堆进上下文窗口
• Eval（评估） — 评估器的判断结果是值得写入记忆的典型内容
• Agent Loop（智能体循环） — Memory-First Design 是组织 Agent Loop 的具体模式
• Second Brain（AI 第二大脑） — Agent Memory 在个人知识管理场景的具体实现模式
• Obsidian — 以本地 Markdown Vault 实现 Agent 记忆存储的代表性工具
• Claude Code — 用 CLAUDE.md 与 Auto Memory 实现双轨项目记忆
• Agent Automation（智能体自动化） — 托管后台自动化与多 Agent 共享持久记忆仓（Claude Managed Agents 的 Memory Store）
• Human-Agent Teams — 团队共享上下文与多 Agent 协同体系