TLDR：大多数 Agent 重启后就会遗忘。以下是我构建的精确记忆栈，让我的 Agent 能在重启后共享上下文、协调工作而不互相干扰，并将决策保留数月之久。
没人解决的问题
这是典型的 AI Agent 记忆设置。把重要内容塞进系统提示词。祈祷上下文窗口不会用完。重启后一切归零。
我运行了两个协调工作的 Agent（Ella 在 OpenClaw 上，Lyra 在 Hermes 上），在 6 个月里经历了数百次会话。让它们真正有用的最大因素不是模型或工具，而是记忆架构。
当 Lyra 在凌晨 2 点修复了一个问题，Ella 早上就知道了。当我在 1 月份决定了如何存储密钥，两个 Agent 在 7 月份仍然遵循这个决定。当一次会话在任务中途崩溃时，下一次会话会从它中断的地方精确接续。
以下是精确的 4 层系统。
第 1 层：会话内上下文
每次会话开始时都会读取两个文件。身份文件是 Agent 的固定身份。不是埋在配置里的系统提示词，而是一个我可以编辑的实际 Markdown 文件。它包含了 Agent 应该如何表现、优先考虑什么、未经询问绝不做什么，以及它与其他 Agent 的关系。
记忆索引文件是所有值得跨会话记住的内容的索引。不是向量数据库，不是嵌入向量。只是一个指向各个记忆文件的纯文本目录。每个记忆文件都是一个简短的笔记，包含名称、描述、类型和简短正文。索引始终被加载。各个文件在相关时按需读取。
为什么用 Markdown？因为我可以阅读、编辑和调试它。当 Agent 行为异常时，我打开索引找到错误的指令。当我想改变某个行为时，我编辑文件。无需 API，无需仪表盘，无需重新训练。
第 2 层：会话后保留（Hindsight）
纯 Markdown 记忆的问题在于：它只捕获了有人明确写下的内容。大多数有价值的上下文是隐性的。运行过程中做出的决策。从任务中推断出的事实。那些最终被证明重要的事情。
Hindsight 是一个运行在 localhost 上的本地事实保留后端。在每个有意义的会话结束时，Agent 会自动将一组精选的保留事实推送到一个命名的存储库中。每个 Agent 都有自己的存储库。
保留的内容包括：会话期间做出的决策、关于用户或项目的非显而易见的事实、失败模式及我们采用的修复方案，以及用户确认或纠正过的偏好。
当新会话开始时，在 Agent 回答之前会查询 Hindsight 以获取相关上下文。这不是对完整对话记录的全文搜索。而是经过策划的事实，按类型标记，Agent 已经学会哪些值得延续。
推荐的路径：Hindsight 事实 → 人工审核 → 记忆索引条目。自动保留，带有人工审批关卡。
第 3 层：共享长期状态（Nexus）
当你添加第二个 Agent 时，单 Agent 记忆就会崩溃。它们会漂移。一个认为 X 是当前项目状态，另一个认为 Y。一周之内它们就会互相矛盾。
解决方案是一个共享的、可检查的状态文件，两个 Agent 都可以读写。我们使用一个我称之为 Nexus 的 Obsidian 知识库。它包含一个实时上下文日志，两个 Agent 在每个有意义的轮次后都会追加内容；一个项目状态文件；一个决策日志；以及每个 Agent 的工作上下文检查点，在长时间任务中每几次工具调用后更新。
实时上下文文件是实时的握手协议。不变规则：每次回复前，读取它。每个有意义的轮次后，追加到它。
当 Lyra 在凌晨 2 点完成一个 PR，而 Ella 正在回答我早上的问题时，Ella 已经知道了。她读取了日志。无需消息传递，无需 Agent 间 API，无需轮询。一个共享文件，两个 Agent，仅追加日志。
第 4 层：可搜索知识（gbrain）
前三层处理情景记忆。发生了什么，决定了什么，哪些值得延续。gbrain 是语义层。它是一个编译好的维基，作为 MCP 服务器运行在 Nexus 知识库之上。对所有已记录的内容进行全文和语义搜索。
当 Agent 需要回答一个研究问题、查找先前的综合信息、或查找我们之前如何处理某类问题时，它会查询 gbrain，而不是重新读取每个文件。输出是一个带有来源的、按相关性排序的页面列表。Agent 读取相关的内容。它不会把整个知识库都塞进上下文。
这就是记忆和回忆之间的区别。第 1 层到第 3 层处理 Agent 携带的内容。第 4 层处理 Agent 可以查找的内容。
跨 Agent 同步不变规则
两个 Agent，一个实时上下文文件。风险：它们互相覆盖，或者错过彼此的条目。我们运行的不变规则：每个条目都带有 Agent 名称、渠道、类型和一行摘要的签名。仅追加。绝不编辑他人的条目。如果 Lyra 记录了相关的内容，Ella 会在下一次回复中明确确认。对于重大决策，两个 Agent 还会将带有时间戳和理由的条目写入决策日志。
这在数百次会话中运行良好。我们只遇到过一次冲突：在一次交接过程中，两个 Agent 在同一分钟内追加了内容。解决方案：读取两个条目，在下一个轮次中协调。无需自动合并。
这取代了什么
在此架构之前：五个断开的聊天会话，每个都有自己的过时上下文。Agent 互相矛盾，因为彼此都看不到对方知道什么。三周前我给过的指令，被遗忘了。决策只存在于我的脑海里，而不是文件中。
在此之后：两个 Agent 在每次回复前都会自我简报。一个共享状态日志，两者都无法否认。保留的决策能跨越数月的上下文重置。每个行为偏好都在一个我可以编辑和验证的文件中。
诚实的权衡：这个系统需要纪律。你必须把事情写下来。你必须维护这些文件。你必须在保留的内容成为永久之前进行审查。这不是一个神奇的永远在线系统。这是一个结构化的手动纪律加上自动化在接缝处发挥作用。
如何开始
你不需要两个 Agent 或一个完整的知识库来运行第一个版本。
第 1 步：一个身份文件加上一个记忆索引。创建它们。在会话开始时读取它们。当你第二次因为同一件事纠正 Agent 时，将每个行为偏好写入索引。
第 2 步：一个共享状态文件。如果你运行多个 Agent，或者在多个窗口中使用 Claude，创建一个实时上下文文件。每次会话在结束时追加到它，并在开始时读取它。
第 3 步：一个保留规则。当一次会话产生了一个应该保留的决策时，手动将其写入索引。在你信任这个模式之前，手动操作。然后自动化标记。
第 4 步：每个事实一个文件，而不是一个大文档。索引指向各个文件。这使得删除过时的记忆变得容易，而不会影响其他记忆。
完整的 4 层栈花了大约 6 个月才稳定下来。第 1 层和第 3 层花了一个周末。从那里开始。
要点
大多数 Agent 记忆设置只是上下文窗口管理，多了一些步骤。它们在窗口重置或你添加第二个 Agent 时就会失效。
持久的 Agent 记忆是一个基础设施问题，而不是提示词工程问题。答案是具有不同时间跨度的多层架构：会话内上下文、跨会话事实、共享状态、可搜索知识。
我们所有的都是纯 Markdown。没有向量数据库。没有嵌入向量。没有重新训练。只是我可以打开、编辑和调试的文件。
真正有用的 Agent 不是那些拥有最大上下文窗口的。而是那些记住重要的事情、忘记不重要的事情的 Agent。
如果你正在构建你希望信任其处理实际工作的 Agent，从记忆架构开始，然后再添加更多工具。
引用的工具
Hindsight（本地记忆保留）：https://github.com/vectorize-io/hindsight
gbrain（编译维基 / 语义搜索）：https://github.com/garrytan/gbrain
OpenClaw（Agent 运行时）：https://openclaw.ai
Hermes（Agent 运行时）：hermes-agent.nousresearch.com
