什么是 memory store
挂载为目录的文本文件集合
字面定义：“Memory store 是一个针对 Claude 优化的、工作区范围内的文本文件集合。”
而其机制正是值得赞赏的部分：“当你将 store 附加到会话时，它会被挂载为会话沙箱内的一个目录。Agent 使用它用于文件系统其余部分的相同文件工具来读写它，并且描述每个挂载的说明会自动添加到系统提示词中，告诉 Agent 去哪里寻找。”
模型无需学习新工具，无需调用检索 API。Agent 已经知道如何读写文件，因此记忆成为了它已经在操作的文件系统的一部分——并且系统提示词会获得一个指针，以便它知道该目录的存在。这是一种将持久性暴露给模型的极低摩擦的方式。
一个如果遗漏会悄无声息导致出错的设置要求：“这些交互需要 Agent 工具集；请确保在创建 Agent 时启用它。”
根据文档，该 store 旨在承载：“用户偏好、项目规范、先前的错误和领域上下文。”
不可变版本与真实的审计追踪
这是我想特别指出的设计部分：“对记忆的每次更改都会创建一个不可变的记忆版本，为你提供 Agent 写入的所有内容的审计追踪和时间点恢复。”
想想这解决了什么问题。当一个自主 Agent 维护自己的记忆时，大家最担心的失败模式是 Agent 写错了某些内容，然后自信地在此基础上继续构建。不可变版本控制意味着这是可诊断且可逆的——你可以看到条目何时发生变化，并回滚到之前的状态。极少有记忆系统（包括我们的在内）将写入历史视为一等公民。这是一个很好的决定，而且这种事情往往只有在发生第一次糟糕的写入后才会显现出其重要性。
每个记忆都通过路径寻址且可直接编辑
“Store 中的每个记忆都通过路径进行寻址，并可以直接通过 API 或 Claude 控制台进行读取和编辑，从而允许进行微调、导入和导出。”
路径寻址意味着你可以对组织结构进行推理——这是一个稳定的布局，而不是一个不透明的二进制大对象（blob）。通过 API 或控制台直接读取/编辑意味着该 store 从外部来看不是只写的：你可以初始化它、纠正它，并将内容提取出来。导入和导出被明确提及，这值得注意，因为可移植性往往是记忆功能中最先丢失的东西。
description 字段是接口的一部分
创建 store 需要 name 和 description，而描述不仅仅是为了显示在你的仪表板上：“描述会传递给 Agent，告诉它 store 中包含什么。”
因此，描述是提示词表面的一部分。文档自带的示例“每个用户的偏好和项目上下文”会告诉 Agent 何时去那里寻找。模糊的描述会让 Agent 难以很好地使用一个内容丰富的 store。请将该字段视为指令，而不是标签。
在自托管沙箱上，它是同步副本，而不是实时挂载
如果你不知道这个区别，可能会浪费你一个下午的时间。在托管情况下，store 是被挂载的。而在自托管沙箱上：“该目录不是实时挂载。相反，SDK 的环境工作线程会在 Agent 的工具运行之前将每个附加的 store 下载到你的沙箱中，并保持该副本与 store 同步。”
自托管文档从数据流的角度描述了相同的边界：“Agent 的技能以及附加到会话的任何 memory store 的内容都由 Anthropic 存储，并在会话期间复制到你的沙箱中；Agent 对记忆文件所做的更改会同步回 store。”为了完整说明计算发生在哪里，它还指出：“工具的输入和输出仍然流向 Anthropic 的控制平面（Claude 运行的地方），以便模型可以查看结果并决定下一步做什么。”
实际理解：在自托管基础设施上，Agent 是针对同步的本地副本进行工作的。对于你控制的沙箱来说，这是正确的设计，这意味着你脑海中应该构建的模型是“工具运行前下载，写入后同步回”，而不是“实时共享目录”。
Beta 请求头可能会让你踩一次坑
这不是设计缺陷，只是一个会产生令人困惑的错误细节。Managed Agents 请求使用 managed-agents-2026-04-01 beta 请求头，“但 memory store 端点除外，它们使用 agent-memory-2026-07-22。”SDK 会为你设置正确的请求头。
如果你手动设置请求头，请注意明确的警告：“不要在 memory store 请求中将 agent-memory-2026-07-22 与 managed-agents-2026-04-01 混用：同时发送两者会返回 400 错误。”请替换而不是添加。而将 store 附加到会话是一个会话（session）端点，因此该调用仍使用 managed-agents-2026-04-01。
在构建同步任务之前，还有一个关于分页的注意事项值得一读：自 2026 年 7 月 22 日起，旧的请求头在 GET /v1/memory_stores/{memory_store_id}/memories 上采用了相同的列表行为，并且“在没有该请求头的情况下发起的请求所获得的分页游标（Page cursors）在带有该请求头时无效，因此请从第一页重新开始。”
Memory store 的局限与边界
这里的任何内容都不是批评——这些是明确声明的范围决策，了解它们是决定在其上构建什么的关键。
工作区范围（Workspace-scoped）。 定义中就是这样写的：memory store 是一个工作区范围内的集合。你的架构继承了这一边界，因此跨工作区的知识需要一个方案。
针对 Claude 优化。 同样来自定义。该 store 是为 Claude 的读取方式而定制的文本文件，存在于 Anthropic 的平台中。如果 Claude 是你的 Agent 运行时，这正是你想要的——但也意味着第二个运行时无法读取同一个 store。
设计上面向 Agent。 该 store 被挂载到会话中供 Agent 使用。它的定位并不是你团队日常使用的助手（assistants）和编辑器（editors）的共享知识层。
Beta 阶段。 请求头说明了这一点。正如 7 月 22 日的分页说明所示，行为和端点仍在发生变化。
人们会用它做什么
按预期使用，作为 Agent 的工作记忆。 如果你基于 Managed Agents 进行构建，这是显而易见且正确的做法。先前的错误和项目规范正是文档中写明的使用场景。
试图将一个 store 变成公司知识库。 这很有诱惑力，但它与工作区范围限制相冲突，而且只有 Claude Agent 会读取它。你的编辑器和其他助手则不会。
跳过 description 字段。 这样虽然快，但它移除了 Agent 用来决定该 store 是否相关的指针。
让 Agent 自由写入且从不查看。 不可变版本控制使这变得可恢复而不是致命的，这也是该功能的意义所在——但恢复仍然需要有人注意到问题。
手动编写请求头并因 400 错误浪费一个小时。 使用自动设置请求头的 SDK 可以避免这种情况。
假设自托管的行为与托管相同。 文档中之所以精确地说明了同步副本的区别，正是因为它们的行为不同。
解决方案：决定哪些内容属于平台 Store，哪些属于外部
有用的思考框架不是“哪种记忆系统获胜”。而是 Agent 工作记忆和组织知识是具有不同生命周期的不同事物，它们最好分开保存。
将 Agent 工作记忆放入 store 中。 先前的错误、Agent 在操作时应应用的规范、该工作区中每个用户的偏好。通过路径组织它，编写真实的描述，并在写入看起来不对时使用版本历史记录。
保持持久知识的可移植性。 决策、限制、被否决的方法、领域词汇——这些在不同运行时之间保持正确、比任何单一 Agent 寿命更长、且对你团队中的人类和编辑器同样有用的材料。这一层不应该被限制在单一平台上的单一工作区内。
这就是 MemoryLake 的定位：一个你的助手和 Agent 通过 MCP 或 API 读取的记忆层，保存不特定于单一 Agent 运行时的知识。设置只需三个步骤。
步骤 1：创建 API 密钥
登录 MemoryLake 并创建 API 密钥。一个凭证即可跨越你连接的所有工具。
步骤 2：上传你的第一批记忆
简短的条目，每条包含一个主张。哪些内容属于可移植层，而不是 Agent 的工作 store：
决策及其背后的限制。 使规范正确的推理，以便它在 Agent 框架发生变化时依然适用。
已被排除的方法。 重新发现这些方法的成本很高，而且对每个 Agent 和每个工程师都有用，而不仅仅是学到它的那一个。
领域知识。 你所在领域的词汇和规则。不针对特定工作区，不针对特定运行时。
你纠正过不止一次的错误。 无论是 Agent 还是人犯的错误，条目都是相同的。
步骤 3：连接你的 AI 和 Agent
连接你使用的工具。MemoryLake 可以通过 MCP 和 API 访问，因此 MCP 原生 Agent（包括 Claude Code、Codex 和 OpenClaw）通过指向 MCP 服务器进行连接，而其他助手则通过 API 读取相同的记忆。
三个坦诚的限制。MemoryLake 不会接入 Anthropic 的 memory store——它不是该功能的集成，它无法读写 memory store，如果你基于 Managed Agents 进行构建，你应该按照文档使用平台 store 来存储 Agent 的工作记忆。它只保存你或你的 Agent 写入其中的内容。而且它不是一个合规或保留系统。
这在实践中改变了什么
Managed Agents 上的 Agent 不再冷启动。 文档中记录的问题——会话结束并带走其状态——现在有了一个官方的解决方案，而且是一个很好的方案。
糟糕的 Agent 写入变得可恢复。 具有时间点恢复的不可变版本是自主系统的一项重要安全属性，值得被更广泛地借鉴。
记忆变成了文件系统层面的关注点。 将记忆暴露为挂载目录，让 Agent 使用普通文件工具进行读取，从而消除了一整类工具使用失败的情况。从架构上讲，这是该版本中最有趣的想法。
自托管部署需要一个心智模型。 工具运行前下载，写入后同步回。而不是实时挂载。
范围决策变得明确。 工作区范围和 Claude 优化是清晰的边界，这比模糊的边界要好。了解它们可以告诉你应该在其他地方保留什么——大致轮廓请参阅持久化记忆的含义。
Agent memory store 的最佳实践
在创建 Agent 时启用 Agent 工具集。 这是 Agent 与 store 交互所必需的。容易遗漏，调试时令人困惑。
像 Agent 会阅读它一样编写 store 描述——因为它确实会读。 说明里面有什么以及它何时相关。
刻意使用路径。 记忆是通过路径寻址的。在第一天就设计一个稳定的布局是值得的。
让 SDK 设置 beta 请求头。 如果你必须手动设置它们，请替换而不是合并——在 memory store 请求中同时发送两者会返回 400。
通过 API 或控制台进行初始化和纠正。 支持直接读取和编辑，包括导入和导出。store 不必空着开始，也不必一直错下去。
在无人值守运行后审查版本历史记录。 审计追踪的存在就是为了让你使用它。
在请求头更改后重新开始分页。 在没有新请求头的情况下发起的请求所获得的分页游标在带有新请求头时无效。
将独立于运行时的知识保留在运行时之外。 任何对你的编辑器、你的助手以及你下一个 Agent 框架同样适用的内容，都属于一个它们都不拥有的层——这也是 MCP 与无状态 Agent 记忆背后的逻辑。
结论
Memory store 是一个构建良好的原语。将记忆挂载为目录，让 Agent 使用普通文件工具进行读取，避开了大量的工具使用复杂性；在系统提示词中添加关于挂载的说明是一个让其变得可用的细节；而具有时间点恢复的不可变版本控制，则是将自主写入从风险转变为可审计过程的那种功能。如果你基于 Claude Managed Agents 进行构建，请使用它，启用 Agent 工具集，编写真实的描述，并记住自托管沙箱获得的是同步副本而不是实时挂载。
边界也写得很清楚：工作区范围、针对 Claude 优化、处于 beta 阶段。这不是缺点，而是一个范围——它告诉你应该在其他地方保留什么。Agent 的工作记忆属于 Agent 的平台。而无论你下个季度使用哪个运行时，那些依然正确的决策、限制和被否决的方法，都属于一个不与它们中任何一个绑定的层。