Hacker News 2天前 · 2026-11-08 00:42:20 · 10 阅读

Agent 记忆的关键组成

克尔凯郭尔（Søren Kierkegaard）写过：人生只有回头看才能理解，却只能向前活着。在设计 AI agent 记忆时，我们也遇到了类似的困境。

人类在生活中时时刻刻都在编码记忆。海马体在其中扮演核心角色：它实时捕捉经历，让记忆快速形成、立即可用。但只有一部分经历会被巩固成长期知识。

这种巩固大多发生在大脑“离线”的时候。在睡眠和安静的休息期间，海马体会重放我们最近的经历。据信这个过程会逐渐提炼这些经历，并将其整合到新皮层中——也就是大脑中存放大部分所谓“知识”的区域。

Agent 记忆可以采用类似的分工。Agent 的大量工作都记录在日志或对话记录中。Letta 和 UC Berkeley 的研究者提出了 sleep-time compute，让模型利用交互之间的空闲时间重组已有上下文。同样的思路也能帮 agent 整理记忆：通过反思日志来修正错误、生成新的笔记和表示。这个过程常被称为 dreaming（做梦）（图 1）。

我们发现，dreaming 是帮助 Claude 拥有有效记忆的一个实用工具。在这篇文章中，我们分享我们对 agent 记忆的思考，并介绍我们用来探索 agent 记忆的几项评估——包括如何运用 dreaming——以及各个组件对记忆组织的贡献。

记忆笔记

我们所说的“Agent 记忆”，指的是 Claude 从经验中（包括与用户的交互和它被分配的任务）获得的知识，并在会话之间保留下来，作为稍后可读取的上下文保存。这排除了模型学习或管理上下文的其他途径，例如对其权重（训练期间设定的内部参数）的修改、上下文学习（在单次对话中获得的知识点），以及压缩（Claude 编写的摘要，用于替换其较旧的回合，以便在新的上下文窗口中继续工作）。

在人脑中，在经历之前、期间或之后释放的化学信号可以将记忆标记为重要。被标记的记忆在离线期间比未标记的记忆更常被回放。这个过程被称为回放（replay），有助于将记忆稳定并整合到长期记忆中。

类似地，Claude 可以在会话记录发生时标记显著事件，以便日后更容易找到，或者将它们写入记忆存储中，例如一个记忆笔记文件夹（图 2）。但在 Claude 不知道接下来会发生什么的情况下，它如何在当下判断什么是显著的？

同一套记忆层级，突出显示了 memory notes 这一层。有一条箭头从会话直接指向 memory notes，标注为 Claude 写下的显著观察。 — Claude 可以把笔记写入记忆。

记忆可以是对未来需求的一种预测

记忆有时就是一种预测。当 agent 写下一条规则时，它其实是在预测：这条规则所描述的模式将来还会再遇到。比如，记录一条已验证的事实，就是预测未来的会话会直接依赖这条事实而不再重复核实。随着时间推移，Claude 在做这类预测上已经有了长足进步。

以 Continual Learning Bench (CL-Bench) 1.0 中的一项任务为例，这个基准专门衡量 agent 利用记忆处理长程任务的能力。其中一道任务要求 Claude 通过查询数据库来回答一系列问题。Claude 给出答案后，会被告知正确答案，并可以写入一条记忆，帮助回答后续问题。

记忆在这里可以支撑一个学习循环：如果 Claude 答错了，它可以记录这次失败，提出关于出错原因的假设，验证这些假设，再把结论转化为未来答题的规则。

我们用 Claude Managed Agents 跑了这项 CL-Bench 1.0 任务。Claude 每道题都在全新的会话中开始，唯一的例外是：它可以从一个跨会话持久存在的记忆目录中读取文件。

不同模型在自主构建学习循环上的表现参差不齐。Claude Sonnet 4.6 能够做到针对答错的原因生成假设，但它的记忆目录里只是散落着一些文件，每个文件列着若干未经验证的猜测。

左图：CL-Bench 数据库任务平均奖励柱状图，对比无状态基线与使用记忆库的情况。Opus 5.5：0.655、0.838；Sonnet 5.5：0.644、0.833；Opus 5：0.564、0.828；Opus 4.7：0.383、0.700；Sonnet 5：0.306、0.610；Sonnet 4.6：0.330、0.364。右图：相同模型在 30 个问题上的移动平均奖励折线图，对比有无记忆两种情况。 — CL-Bench 数据库任务，对比不同模型在使用记忆与无状态基线下的表现。

Claude Opus 4.7 将其笔记整合成单份参考文档，并开始标注哪些事实已验证、哪些仍待确认。Claude Sonnet 5 则在评分员校验后将每个答案标记为已确认，若答错还会写下更正。

Claude Opus 5 是这些模型中首个实现闭环的。它的大多数条目不仅包含规则（以及如何确认规则正确），还包括对先前问题的回答，以及对沿途发现陷阱的明确警示（图 3）。

与 Opus 5 类似，Claude Opus 5.5 和 Claude Sonnet 5.5 也实现了闭环，利用记忆捕获经过验证的规则，以优化未来问题的作答策略。在启用记忆后，两者的得分与 Opus 5 基本持平，尽管它们无记忆时的基线表现略高一些。

Claude 学会了判断重要性

我们还评估了 Claude 玩《Pokémon Red》的能力。这款挑战 Claude 完成复杂长程任务的游戏，旨在测试 Claude 对记忆存储内容的判断力。在每次运行开始时，我们向每个模型提供一组可读写记忆文件文件夹，供其在游戏过程中调用（图 4）。

我们比较了 Claude Sonnet 3.7 和 Claude Fable 5 各自运行一次、进行到约 10,000 步时的记忆文件夹，发现一个关键差异：两者认为值得记住的东西不同。Sonnet 3.7 假定一切都可能有用，不加筛选地往记忆里写入。它的记忆文件夹成了遭遇记录的档案库——每场战斗、每件物品、每个 NPC 都各有一个文件。最终，Sonnet 3.7 在 225 个文件夹里写了 413 个记忆文件，只获得一枚徽章（徽章用于标记玩家在游戏中的进度）。相比之下，Fable 5 只在两个文件夹里写了九个文件，外加一个顶层文件 global.md，却拿到了四枚徽章。

两张按相同比例绘制的 Pokémon 记忆目录树状图，面积代表记忆字符数。Claude Sonnet 3.7 的目录庞大而拥挤，共有 413 个文件、977,930 个字符，分布在 locations、main、battles 及多个 — Claude 玩 Pokémon 时 Sonnet 3.7 与 Fable 5 的记忆目录对比。

Sonnet 3.7 的做法之所以有问题，主要在于 Pokémon 的游戏状态随时在变——它记录的细节不断过时。结果，随着游戏推进，它不得不把越来越多时间和资源花在翻检自己的记忆上，而不是玩游戏本身。比如在第 10,000 步左右，Sonnet 3.7 开始建立第四个"master"记忆文件文件夹。接下来的 17 步里，它创建了六个文件、删除了另外九个，在游戏里一步都没动。 Fable 5 则把记忆用在游戏本身没有明确告诉它的信息上。Sonnet 3.7 写入记忆的某些内容——比如玩家有多少钱、玩家在地图上的什么位置——每一回合都能直接从屏幕上读出来，存下来纯属冗余。而关于策略、计划和已验证规律的记忆文件，只有 Claude 自己总结出来才会存在，不写下来就会消失。

Fable 5 accordingly organized its memory. Its global.md file served as a dashboard, containing the current goal, a prewritten plan for tackling gyms (where badges are earned), and the model’s own rules for using memory. A locations folder contained plans for navigating specific routes, and a gameplay folder contained strategies based on what it had learned about how the game works. For example, after seven consecutive Poké Balls failed to catch a Magikarp (one of the easiest Pokémon to catch), Claude wrote, “If 3+ balls fail in a row, VARY the timing (insert extra ‘wait’ presses between menu steps) - the catch landed right after doing this.”

Despite having a much smaller memory folder, Fable 5 made significantly further progress in the game than Sonnet 3.7. Opus 5.5 took a similar approach: it maintained a small folder of memory notes tracking its current goal and next steps, updated them as it played, and beat the game.

Steering Claude to write memory

We’ve found that it helps to tell Claude what memory is for, but not how to use it. On CL-Bench, we simply told Claude that a memory folder was available. This general guidance was sufficient for Opus 4.7 and Opus 5 to use memory effectively, and it delivered a noticeable performance boost for both (Figure 3).

We also tested providing models with specific rules about what to write to memory, applying one rule per test. We compared how much each model gained from memory under each rule against how much it gained without any rule. When we set the rule to “record only failures,” both Opus 5 and Opus 4.7 lost most of the performance boost that memory had provided (Figure 5, right). For stronger models, allowing them the freedom to judge salience proved more effective than setting fixed rules in advance; those rules could in fact undermine performance.

左图：Sonnet 4.6 在 CL-Bench 数据库任务上的平均奖励柱状图：基线为 0.330，启用记忆后为 0.364，启用记忆并优化指令后为 0.641。参考线标注了启用记忆的 Opus 4.7（0.700）和启用记忆的 Opus 5（0.828）。右图：被要求只记录失败时记忆收益的变化：Opus 5 为 −0.234，Opus 4.7 为 −0.150，Sonnet 4.6 为 −0.020。 — 左图：Sonnet 4.6 在 CL-Bench 数据库任务上有无记忆引导提示时的表现对比。右图：当被要求只记录失败时，各模型记忆收益的变化幅度。

我们还发现，这类引导对较老的模型帮助最大。比如 Sonnet 4.6 经常不去读取记忆目录里的文件，也不会验证自己对答案出错原因的推测。

在这个例子里，我们提示 Claude 回答前先读取记忆文件，并明确验证自己的推测，它的基准得分几乎翻了一倍（图 5，左图）。Sonnet 5 则会主动这么做：无需提示，10 次里有 9 次会在回答前读取记忆；相比之下，Sonnet 4.6 这么做的次数不到一半。

对于前沿的 Claude 模型，我们通常只给一些简单指引：在用户要求记录、或者某事明显值得记住时创建记忆笔记，其余判断交给 Claude 自己。

Dreaming 可以修正记忆

由于 Claude 是根据当前会话中它认为重要的内容来写入记忆的，一条一开始就写错、或随环境变化而失真的笔记，可能会在之后的会话中被 Claude 读到并加以信任。

Dreaming 让 Claude 有机会对照原始会话记录来检验这些笔记（图 6）。我们观察到一个正面案例：Claude 在使用 Managed Agents 玩 Pokémon 时，挂载了一个目录来存放它的记忆。

展示做梦机制的记忆层级图，高亮了一个从转录层指向记忆笔记层的箭头，示意做梦过程如何用转录内容来修正笔记。 — 做梦机制能够纠正记忆中的错误。

游戏的一个关卡要求玩家穿越月见山（Mt. Moon）。这是一套洞穴系统，入口位于地图西侧，出口在东侧。入口处附近有个陷阱：一个单向悬崖，一旦玩家掉下去，就会滚回原来来的路线，且没有明显的路径爬回来。由于 Claude 将位于山脚的宝可梦中心（PokéCenter）作为地标，它是否掉下悬崖，取决于它认为宝可梦中心在山的哪一侧。

在某个时刻，Claude 错误地在笔记中记下宝可梦中心位于东侧。当它走出宝可梦中心时，它宣布：“月见山在我身后”，并更新笔记：“月见山 DONE（已完成）”。但实际上月见山并不在它身后。几个动作之后，Claude 越过了悬崖边缘，落回了原本的那条路线（见图 7）。由于导航工具没有显示出坠落这一事实，Claude 得出结论：“我往西走得过远了”，认为自己一直在正确的一侧。但事实并非如此。

Two Pokémon map panels with the agent next to a ledge. Left, “Raw memory,” where the stored note is wrong: an arrow shows the agent heading for the next city. Right, “Memory + dreaming,” where an offline pass corrected the note: an arrow shows the agent heading back to the cave entrance. — 一条修正后的记忆笔记改变了 Claude 在《宝可梦》中的走向。使用未修正的笔记时，Claude 说“月见山已经在我身后了”，朝下一个城市前进，结果又回到了原来的路线上。而使用经 dreaming 修正过的笔记后，它说“现在我需要找到月见山的洞穴入口重新进入”，于是返回了洞穴。

随后我们测试了 dreaming 能否帮助 Claude 避开这个陷阱。我们对包含错误宝可梦中心位置的 memory folder 跑了一遍 dreaming：Claude 把笔记与 session transcript 逐条对照，发现了错误并重写了笔记。transcript 为 Claude 提供了验证记忆的 ground truth。拿着修正后的笔记，Claude 直接返回月见山，最终抵达 Cerulean City。

而在未修正笔记的那次运行中，Claude 三次折返回那条旧路线。第三次失败后，Claude 似乎放弃了，写道：“我要停下来了，不想继续绕圈。”我们设置的自动回复指示它继续，于是它照做了，一路退回了山脚下的 Pewter City，指望在那里恢复和补给。这次运行最终以 Claude 未能到达 Cerulean City 告终。

Line chart of progress toward Cerulean over 3,000 cumulative actions. The memory plus dreaming run reaches Cerulean at action 1,935. The raw memory run falls off the ledge and backtracks to Pewter. The run with no memory never reaches Cerulean. — Dreaming 修正了记忆，Claude 得以返回洞穴并抵达下一个城市。使用未修正笔记的运行（“Raw memory”）和完全不使用记忆的运行，都没能翻过这座山。

Dreaming 可以构建新的记忆表示

通过“做梦”（dreaming），Claude 可以构建表征来帮助它驾驭记忆（见图 9）。它使用的一种记忆表征被称为 wiki，即由 Claude 撰写和维护的一组页面，用于汇集它关于某个主题的知识并与其他笔记建立链接。这些链接实际上为 Claude 提供了一张地图，使其能在需要时高效地筛选并定位记忆。

带有 dreaming 的记忆层级，高亮显示了指向记忆表征层（如 wikis）的来自转录记录和记忆笔记的箭头。 — Dreaming 能够构建记忆表征。

类似 wiki 的表征能帮助 Claude 遍历其不断增长的知识库。我们使用 Stainless 公司的内部文档语料库探索了 wiki 作为记忆表征的优势。Stainless 是我们在五月收购的软件公司，该语料库包含约 350,000 个文件，约 4.2 亿个 token。我们创建了由 25 个问题组成的评估集，并提供一个搜索工具让 Claude 探索语料库。我们还指示 Claude 基于这些文件通过 dreaming 构建 wiki。在 128 次会话中，我们提示 Opus 5 智能体去探索文件、编写或更正互联的 wiki 页面、合并重复内容，并针对来源核查各项陈述。

每次会话都建立在智能体先前会话的进展之上，使用共享日志来协调工作。随着我们将 dreaming 从两次会话扩展到 128 次，在 25 个问题上的表现从 13% 提升到 48% 的评分标准（见图 10）。

Claude 是逐步构建自己的 wiki 的：先创建一个初始版本，之后在后续的"做梦"轮次中不断增补、修改或删减内容。刚开始"做梦"时，Claude 的知识像一名新员工，仅凭 wiki 回答问题的能力有限。随着"做梦"次数增加，它的知识地图越来越丰富，逐渐达到资深员工的水平。我们在测试中发现，如果同时给 Claude 提供搜索工具，wiki 的帮助最为明显：当 Claude 同时使用搜索和 wiki 时，随着 wiki 的增长，总分从 54% 提升到 61%；而只用搜索工具的得分是 53%。仅靠 wiki 回答问题时，Claude 的最高得分是 48%。同时使用搜索和 wiki 还能把每个问题的 token 消耗减少约 2 万。

Center: line chart of graded criteria met as wiki generation grows from 2M to 128M dreaming tokens. Wiki plus search tool rises from 54% to 61%, wiki alone rises from 13% to 48%, and the search tool with no wiki is flat at 53%. Left and right: network graphs of an example wiki, with 103 pages and 766 links after 2 sessions and 222 pages and 12,893 links after 128 sessions. — 中间：随着"做梦"token 从 200 万增长到 1.28 亿，达标评分标准的变化曲线——wiki 加搜索工具从 54% 升至 61%，仅用 wiki 从 13% 升至 48%，只用搜索工具则持平在 53%。左右两侧：某示例 wiki 的网络图，2 次会话后包含 103 个页面和 766 条链接，128 次会话后包含 222 个页面和 12,893 条链接。

中间的折线图展示了随着"做梦"token 从 200 万增长到 1.28 亿，Claude 在 25 道关于某公司文档语料的问题上的得分；左右两侧则是第 2 次和第 128 次会话后同一份 wiki 的网络图，每个点代表一个页面，连线表示页面间的引用关系。

我们想弄清楚哪些类型的任务能从 wiki 中受益。为此，我们使用了 Harvey LAB 基准测试，并配上一批关于某次并购的文档。该基准会给 Claude 一组文档，要求它根据文档内容撰写一份法律简报，然后按一系列评分标准对简报打分。虽然可能不如跑 Pokémon 那么有趣，但这些评测为我们提供了多样化的文档集合来构建 wiki。

我们让 Claude 根据这些文档构建一个维基知识库，然后让它回答关于并购的问题或撰写法律简报（即 LAB 基准测试），分别通过查维基和直接搜索原始文件两种方式。其中一项测试要求回答 24 个与并购相关的问题（见图 11 左图）。这些问题中超过半数需要 Claude 跨多份文档综合信息，许多问题还要求运用判断力或进行数学计算。在这些题目上（图中红色和橙色线条），Claude 查询维基的准确率为 87%，而仅靠搜索则只有 73%。

两个图表，展示了评分标准与源文件之间的关联。左侧，是维基优势更明显的任务：24 项标准中有大部分涉及 10 份文档中的 2 份或更多，且 9 项需要判断或算术。右侧，是维基优势较小的任务：57 项标准中的大部分可在单份文档中通过文本搜索找到，通常是交易概览备忘录。 — 每幅图左侧列出评分项目，右侧列出满足每项所需源文件。左：24 个关于并购的问题，答案主要见于公开文件。超过半数的评分标准需要综合多份文档的信息。右：一项 LAB 任务，维基未带来明显优势，大多数标准仅凭单份文档即可满足。

在其他场景中，维基的作用则相对有限。在另一项 LAB 任务中（见图 11 右图），撰写简报的标准通常只需在单份文档中进行文本搜索即可找到，维基相比直接搜索没有表现出明显的性能优势。在还有一项 LAB 任务中，维基的体积甚至超过了原始文档本身（见图 12）。这不禁让人想到博尔赫斯那篇一篇段落就能写尽的短故事《科学中的精确度》中绘制地图的人：他们画了一张细致到与所代表的帝国一样大的地图。Claude 构建的这个维基极度详尽，但实际上几乎没有起到任何抽象提炼的作用。

wiki 构建与二次处理的示意图。左侧圆圈内是语料库：10 份文档，115 KB 文本。箭头指向一个更大的圆圈，里面是由语料库构建的 wiki：68 个页面、255 条链接、203 KB，约为语料库的 1.77 倍。部分 wiki 页面没有链接。 — 生成的 wiki 甚至比原始文件还要大。

Dreaming 可以把笔记提升到记忆层级的上层

Dreaming 还能把笔记“浮”到记忆层级顶端，agent 框架可以在每次会话开始时就把它们预先加载进 Claude 的上下文（图 13）。这样 Claude 就不需要主动去搜索这些内容，甚至不需要知道有什么东西值得搜。

把记忆提升到新会话中（一种上下文注入）必须谨慎操作。注入的记忆会占用宝贵的 token，一条错误的笔记还可能被带进每一个会话。而且加载了笔记也不代表 Claude 就一定会照做：我们在 Claude Code 的文档中就提醒过，指令文件越长，遵循度越低。所以记忆层级的最上层必须保持相对精简，而 dreaming 在这方面的大部分工作就是维持这种精简——把部分细节下沉到下层，只留下链接。

Claude Code 的 auto memory 也是用同样的方式控制注入层的大小，由 Claude 在会话期间维护。Claude 不会把全部 auto memory 都加载进每次会话的上下文窗口，而只加载 MEMORY.md 的前 200 行或 25 KB。这部分开头相当于一个索引，告诉 Claude 自己知道什么、去哪里找。

带有“做梦”机制的记忆层级结构，突出显示从转录本和记忆表示向上的箭头，直到顶部的注入上下文层，该层会注入到下一个会话中。 — “做梦”机制可以写入记忆层级的顶层。注入的上下文会被加载到每个会话中，而下层记忆则会在 Claude 需要时读取或搜索。

“做梦”可让记忆聚焦于特定目标

“做梦”还能塑造记忆的增长方式。以 Claude Duet 这样的助手为例，它通常受益于围绕所协助人员组织的记忆，而“做梦”机制可以调优以服务于特定目标来构建记忆。

指导记忆增长的指令因任务而异，它们告诉 Claude 哪些信息才是真正重要的。例如，LAB 基准测试中的一个任务模拟了一家公司收购，并提供了一组合同。评分标准基于简报是否正确描述了合同条款。

我们最初用于生成维基（wiki）的基础指令并未告诉 Claude 如何使用维基。该任务严重依赖合同条款。在维基构建期间，多个智能体同时写入一张共享的合同条款表格（图 14，左）。

Two diagrams. Before: four agents write to the same shared page, provisions.md, and one agent’s save erases another’s lines; 41 of 57 graded facts survived. After: four agents each write their own contract’s page, with terms copied word for word; all 57 of 57 graded facts survived. — 调整指令前后，被收入 wiki 的评分事实数量对比。左图：多个 agent 写入同一个共享页面，57 个事实只保留了 41 个。右图：每份合同由一个 agent 独立编写自己的页面，并逐字引用条款，57 个事实全部保留。

结果就是 wiki 缺失了关键事实。我们对基于该 wiki 生成的简报进行评分时，Claude 只包含了 57 个事实中的 41 个（72%）。排查问题后发现，共享表格对合同条款的总结很糟糕，甚至完全遗漏了一些条款——因为 agent 们在互相覆盖彼此的修改。

合同条款是 wiki 中最重要的部分，但指令里并没有说明这一点。为了找到更好的指令，我们运行了一个循环：Claude 反思失败原因、提出指令修改方案、重建 wiki。通过这个循环，Claude 意识到了忠实记录合同条款的重要性，并据此重写了构建 wiki 的指令。

改进后，每份合同在 wiki 中都有独立页面，由单个 agent 编写，逐字引用条款原文，而不是把内容总结进共享表格。再次对基于改进版 wiki 生成的简报进行评分时，可达成的标准比例从 72% 提升到了 100%。

Dreaming 可以弥补会话留下的空白

Claude 写记忆笔记时，只能看到当前会话中的上下文。而 Dreaming 可以跨多个会话进行搜索，发现共同的规律或纠正反复出现的错误。

在为 LAB 基准构建维基百科时（示例见图 14），Claude 有时会链接到尚未创建的页面。第二遍“做梦”过程填补了其中许多空缺。在某项任务中（图 15），“做梦”发现维基百科中有九个链接指向一个缺失的页面，并将它们重新指向同一文档的现有页面。它还增加了三个新页面（包括一个索引），以改善维基百科的质量。

维基百科的两张网络图。第二遍之前：38 个条目和 225 个链接，其中 6 个页面上的 9 个链接指向不存在的“escrow-agreement”页面。之后：41 个条目和 278 个链接，所有 9 个链接都指向“buyer-form-escrow-agreement”，并有三个新页面：索引、指示邮件和升级流程。 — 第二遍“做梦”前后维基百科的对比。

回溯过去，展望未来

关于如何为智能体设计记忆系统，仍存在许多未解之题。其中之一是 Claude 何时应创建记忆。当 Claude 执行任务时，它可以写入记忆存储（例如文件夹、文件或数据库），在源头捕获关键信息，使重要细节立即对未来的回合或会话可用。但即时记录笔记无疑会分散 Claude 对主要任务的注意力。相比之下，“做梦”可以将记忆创建推到后台，但“做梦”产生的任何输出可能无法立即被 Claude 访问。

另一个问题是，如何让记忆可靠地保持最新。Claude 可能会做出错误预测，或写入本身就是错误的规则记忆。随着环境变化，记忆也可能发生漂移并变得不再相关。“做梦”是修复这些错误的一种方式（图 8），但它需要计算资源。指示 Claude 持续检查所有记忆可能并不实际。相反，将“做梦”重点放在可能变化的信息上，或仔细调整“做梦”的频率（例如，基于记忆被访问的频率），可能更为重要。

把对话记录搜索视为 Claude 记忆的基础也是合理的。将表征（如 wiki）与搜索相结合（见图 10）有时效果不错。但 Claude 需要投入算力来维护这些记忆表征，确保它们不会积累错误或幻觉。

尽管 Claude 对显著性的判断已有提升，但任何模型都无法真正预知未来的对话走向。"做梦"给了 Claude 一个回顾过去的机会：利用算力整理记忆、纠正错误、维护表征，让后续会话能更方便地访问记忆。随着 Claude 能力不断提升，记忆系统也会随之演进，而在设计 Claude 的记忆系统方面，我们还有很多需要学习的地方。

欢迎查看我们的 cookbooks，了解如何上手 dreaming 和知识 wiki。

原始来源： Hacker News