AI Agent 记忆困境：从手动管理到自动注入的跨越

你每天在给 Agent 做「人肉记忆」

每次打开 AI Agent 的新会话，你做的第一件事几乎都一样：粘贴技术栈信息、项目规范、上周二那个关于鉴权流程的决策、以及三月尝试过但失败了的方案。你或许有一个 CLAUDE.md 文件，像维护维基百科一样手动更新它；或许维护着五个 markdown 笔记文件，它们本质上就是你替软件执行的手动记忆功能。

如果每天都在用 Agent，这已是你的肌肉记忆——关闭前「保存上下文」、编辑没人认领的规则文件、用「正如我之前讨论过的」来碰运气。有趣的是，你机器上最聪明的工具，却是唯一什么都不记得的工具。编辑器记得你的设置，终端记得你的历史命令，而 Agent——那个最需要「被交代」的工具——每天早晨从零开始。

我们尝试了市面上已有的解决方案，发现它们都无法通过同一个测试，于是决定自己构建一个能通过测试的方案。

三种「本应解决问题」的方案为何失败

判断任何记忆工具只需一个问题：当下一个提示词到来时，Agent 实际知道什么？ 不是存储了什么，不是能找到什么，而是此刻模型面前有什么。

Markdown 文件方案（CLAUDE.md 及其同类）。 它们在会话开始时加载一次，然后就被冻结了。你周二写下的内容，Agent 整个星期都据此行事。没人维护这个文件，因为维护本身就是你想逃避的手动苦差。不出一个月，它就变成杂物抽屉：三条互相冲突的指令、两个项目前的技术栈清单、一条已经不再成立的自我备忘。这是快照，不是记忆。

Agent 需主动调用的记忆工具。 存储能力很好，但它们等待被询问：除非 Agent 在回答过程中决定去搜索并记得执行，否则在它回答之前什么都不会到来。会话结束时的交接，取决于下一个会话想起来要问什么。一个你必须记得去使用的图书馆，算不上记忆。

搜索钩子。 更好的版本确实会在每次提示时推送一些匹配的原始文本片段。这是真正的注入，但还是不够——片段是检索，不是简报。它们找到碎片，但不携带你的长期规则，不会用后来决定的内容去校正碎片，也不附带原因。Agent 得到的是搜索结果，而不是被告知什么是真实的。

三种方案失败的方式完全相同：知识存在于某处，但在提示词发生的那一刻——唯一重要的时刻——什么也没有到达。

工作记忆必须通过的三个测试

一个真正有效的工作记忆必须在三个时刻给出答案：

• 会话开始。 在你开口之前就有一份简报：上次停在哪里、当前生效的规则、计划中下一步是什么。
• 每次提示。 与当前提示相关的记录随提示一同到达——而不是每轮都把全部记忆倾倒入上下文窗口。
• 「为什么会这样？」 决策本身、日期、原因，以及它击败的那个选项——用当时对话中的原话来呈现。

这是规格说明。其余一切是实现细节。

RAG（检索增强生成） 是「搜索钩子」类方案背后的常见范式：把历史内容切分成片段、建立向量或关键词索引，在提问时检索出最相关的若干片段，拼进提示词再交给模型生成。它的优势是能处理海量知识且按需取用，但局限也很明显——检索的目标是「相似」，而非「当前为真」。它不区分已被推翻的旧决策和仍然生效的新决策，也不携带规则之间的优先级，更不会主动说明某条记录的来龙去脉。文中批评搜索钩子只给碎片、不给简报，正是针对这一范式：检索解决的是「找到」，而工作记忆要解决的是「此刻该相信什么」。

用「大脑」替代「记忆」后的一天

据该方案的开发者描述，他们自己的公司从 2025 年 12 月起就在用自己的记忆系统运行工作，自 4 月以来归档了每一次对话。这不是演示脚本，这是真实的周二。

早晨。 打开机器，启动会话，说「继续」。简报已经就位——上次会话的交接笔记、项目规则、计划的后续步骤、该项目操作手册的索引。不需要重新解释，不需要「快速回顾一下仓库」。会话直接从计划的顶部开始执行。

中午。 每个提示词到来时都已预先简报。不是所有东西——只是与那个提示相关的记录，别的一概没有。当我问限流器的问题时，关于限流器的对话记忆随问题一同到来。开发者表示从三月起就不再维护 markdown 文件了，也没有想念它们；没有「保存上下文」的仪式，因为没有什么需要保存——内容的整理在对话过程中就已发生。

下午。 两个 Agent 负责同一个项目：一个前端，一个后端，各有自己的密钥，从同一个记忆中工作。不需要告诉任何一个 Agent 另一个做了什么决定——前端的对话一旦被整理，后端 Agent 下一个涉及该内容的提示就会携带已确定的事项。后来，前端 Agent 为设置页面建议一个方案时检查记忆，答案已经在那里：那个选项三月被否决了，这是日期，这是原因，用的是那次对话的原话。没有重新争论已死选项的情况，因为没人忘记它已经死了。

所有这一切都通过「说出来」发生。不需要归档任何东西，不需要调用保存工具，不需要运行同步。Agent 自己管理记忆，因为记忆在需要被管理之前就已经出现在它的上下文中。

一个诚实的权衡：注入消耗上下文。简报和每次提示的记录占用 token——这就是注入的本质。你换回来的是工具调用次数、对话轮次和搜寻时间。据开发者描述，几个月来这个权衡明显有利于他们。

底层机制：三层结构

• 整理后的记录是当下的真相。记忆以五个对话轮次为窗口读取你的对话，保留对话中「已确定」的内容——用新事实校正旧事实，静默退役那些描述已被你替换的事物的记录。
• 决策图谱是到达当前状态的过程。每个决策是一条线：有日期，附带当时所说的原因，以及它击败的选项。反转是新的一条线——历史从不被改写，所以「为什么会这样」永远有答案。
• 完整历史保留一切，可按关键词或语义搜索。记录是真实的，图谱是发生的，档案是两者的底座。

两个实践上重要的细节：

项目之间相互隔离。 每个项目有自己的记录、规则、图谱和计划；除非你主动发起跨项目搜索，否则它们不会相互渗透。在托管版本中，作用域密钥让你能把队友、客户或外包人员的访问权限精确限定在你指定的项目上——读写、只读或不可见——别的什么都碰不到。

规则不会腐烂成杂物抽屉。 每条规则有上限，规则池有上限，达到 80% 时会警告，会导致超限的保存会被拒绝并附上修复方案。你写的东西永远不会被悄悄裁剪或丢弃。

隐私方面，开发者强调：你的记忆存在你的机器上（本地容器，除此之外不存于任何地方）或加密的云端。他们的中枢处理部分内容以生成记忆和撰写简报，但不保留任何这些片段。

上下文窗口（Context Window） 是大语言模型单次推理时能「看到」的 token 总量上限，包括系统提示、历史对话、注入的记忆和当前输入。它决定了 Agent 每一次回答所依据的全部信息边界，一旦超出，最早的内容会被截断或丢弃。这正是「注入式记忆」必须精打细算的原因：每一条简报、每一条相关记录都实实在在占用窗口空间，挤占留给代码、文档和用户输入的部分。

Token 是模型处理文本的最小单位，大致相当于英文的单词片段或中文的若干汉字。接口计费和上下文长度都以 token 计量。因此「用 token 换时间」这一权衡可以量化：注入记忆增加的 token 成本，能否被减少的工具调用轮次、更少的重复解释和更快的方案收敛所抵消。对于上下文窗口本就紧张的项目，例如需要一次性塞入大量源码的场景，这种权衡可能反转。

多源视角与适用场景

该方案来自 Brethof 团队，本质上是一个 AI Agent 的持久化记忆层。它支持 Claude Code、Codex、OpenClaw^广告、Hermes 等主流 Agent 运行环境，安装方式是通过一句话指令让 Agent 自行拉取客户端并配置钩子。

对于每天使用 AI 编程助手的开发者来说，这种「自动注入」式记忆的价值在于消除了重复交代的环节。特别适合多 Agent 协作的项目——前端和后端 Agent 可以共享同一份决策记忆，避免因信息不对称导致方案冲突。

不过需要注意，注入式记忆本质上是用 token 换取时间。如果你的上下文窗口本就紧张，或者项目决策变动频繁，需要评估这种方案的净收益。对于轻量级、单次使用的场景，传统的 markdown 文件可能已经足够。

该方案提供免费入门选项，采用本地或托管两种部署模式。本地模式通过设备端验证码授权，Agent 全程不接触密钥；托管模式需要手动粘贴密钥和密码短语。

Agent 运行环境（Agent Runtime / Harness） 指承载 AI Agent 的外层框架，负责管理对话循环、提供工具调用接口、注入系统提示和钩子。文中提到的 Claude Code、Codex、OpenClaw、Hermes 都属于这一类。不同运行环境的钩子机制和配置方式各异，这也是记忆方案需要逐一对接的原因——它必须在每个环境的「提示词组装」环节插入自己，才能做到在会话开始和每次提示时自动注入简报，而不依赖 Agent 主动调用。

本地容器与加密云端 是该方案给出的两种隐私边界。本地模式下记忆存放在设备上的隔离容器中，密钥不经过 Agent，适合对数据外流敏感的场景；托管模式下记忆加密存储于云端，由服务方的中枢处理部分内容以生成摘要和简报，但声明不保留原始片段。选择哪种模式取决于团队对合规、协作便利性和运维成本的权衡。