Hermes Agent 社区最近出了一个新的记忆插件叫 hermes-agentmemory。代码只有不到 600 行 Python，但它解决的问题比代码量暗示的要严肃得多。
核心观点只有一句话：如果你让 Agent 替你记住事情，你也必须能让它彻底忘掉。
现在的 Agent 记忆是怎么工作的
目前主流的 Agent 记忆方案（Mem0、Honcho、Hindsight 等）基本都是同一个架构：推送式（push-model）+ 后台整合。
流程大概是：
- 你和 Agent 对话，对话历史被存下来
- 后台有一个进程定期跑，把历史对话提炼成摘要
- 下次对话时，系统从摘要里挑相关的内容注入到上下文
这个模式的好处很明显：召回速度快，因为摘要已经提前算好了。用户无感，不需要操心记忆管理。
但问题也很明显。
问题一：删除不是真正的删除
假设你和 Agent 聊天时不小心说了一句「我的银行密码是 123456」。你发现后立刻点了删除。
在推送式架构里，「删除」做的事情是：把原始对话记录标记为已删除。
但后台整合进程可能已经跑过了。你的密码已经被提炼进了一条摘要：「用户的银行密码是 123456，应在需要时提醒用户更换」。
你删掉了原始记录，但摘要还在。Agent 下次对话时，摘要会被注入到上下文里。你的密码从来没有真正消失过。
这不是理论上的漏洞，是实际发生的事情。任何做过后台整合的记忆系统都有这个问题。有些系统试图解决它（删除原始记录时同时重新生成所有关联摘要），但这在计算上非常昂贵，很少有人真正做到位。
问题二：你不知道 Agent 在想什么
第二个问题更隐蔽。
当 Agent 回复你的时候，它的回复受到注入记忆的影响。但你看不到它实际用了哪些记忆。
你问：「帮我推荐一个餐厅。」
Agent 回复：「根据你之前的偏好，推荐这家川菜馆。」
你不知道「之前的偏好」是从哪条历史对话里来的。如果 Agent 记错了（把你室友的偏好记成了你的），你很难发现。除非结果明显离谱，否则你会以为 Agent 很了解你，其实它在用错误的信息做推理。
后台预取是一个黑箱。系统决定注入什么记忆，用户不知道，也没办法干预。
hermes-agentmemory 的做法
这个插件的设计哲学是：不做后台工作，一切都是同步和可审计的。
拉取式（pull-model）而非推送式。 不是系统自动往上下文里塞记忆，而是 Agent 主动调用 agentmemory_recall(query) 去拉取相关记忆。每次拉取都有明确的意图和返回结果，全部记录在审计日志里。
删除就是删除。 调用 agentmemory_forget(event_id) 时，原始事件直接从存储中移除。没有 tombstone（墓碑标记），没有派生产物残留。因为系统不做后台整合，所以没有「摘要里还残留着已删除信息」的问题。
每次记忆注入都有审计轨迹。 每次 Agent 调用 recall，系统都会在 trace.jsonl 里写一条记录：用了哪些 event_id、生成了什么摘要、当时的 prompt 是什么。你可以随时 tail -f 这个文件，看到 Agent 实际在用什么信息做决策。
代价是什么
作者很诚实地写了 trade-off：
每次新会话的第一轮对话会有 200ms 到 2 秒的延迟。因为没有后台预热，摘要需要实时生成。
这对追求极致响应速度的场景（比如客服机器人）可能不太合适。但对需要隐私保障的场景（个人助手、医疗、法律），这个延迟完全可以接受。
另外，摘要用的是 Claude Sonnet，不是更便宜的小模型。作者的理由是：摘要质量直接决定记忆质量，这个环节不能省。用小模型做摘要容易丢信息或产生幻觉，到头来 Agent 的回忆就会出错。
三个暴露给 Agent 的工具
插件只给 Agent 暴露三个工具：
agentmemory_recall(query, top_k?)— 检索最相关的过去事件agentmemory_forget(session_id?, event_id?)— 真正删除某个记忆agentmemory_drift()— 查看记忆的「漂移状态」，判断召回质量是否在下降
第三个工具有意思。随着时间推移，存储的事件越来越多，早期事件的相关性可能在下降。drift 给 Agent 一个信号：你的记忆可能需要清理了。Agent 可以基于这个信号主动调用 forget 来清理过时的信息。
这是一个「自我维护」的设计。Agent 不只是被动地记和取，还能主动管理自己的记忆健康度。
为什么这件事和隐私有关
欧盟的 GDPR 有一条叫「被遗忘权」（Right to be forgotten）。用户有权要求服务方删除自己的个人数据。
如果你的 Agent 用的是后台整合式的记忆系统，执行「被遗忘权」就变得非常复杂。你需要追踪一条数据被整合进了哪些摘要，然后重新生成所有受影响的摘要。这在工程上是一场噩梦。
hermes-agentmemory 的架构天然避开了这个问题。没有派生产物，删除就是彻底删除。审计日志里记录了所有曾经的访问，但原始数据一旦删除就不会再被使用。
这不是说后台整合式的方案就是错的，它在大多数场景下确实更好用。但在隐私敏感场景里，「简单且可审计」比「高效但不透明」更重要。
安装和使用
如果你已经在用 Hermes Agent，安装只需要四步：
git clone https://github.com/MukundaKatta/hermes-agentmemory \
"${HERMES_HOME:-$HOME/.hermes}/plugins/agentmemory"
pip install anthropic
hermes config set memory.provider agentmemory
export ANTHROPIC_API_KEY=...
Hermes 启动时会自动发现插件目录下的 MemoryProvider 子类，不需要额外配置。
记忆是 Agent 的性格
之前几篇文章讨论了 Agent 的能力（工具调用）、协作（多 Agent 架构）、可靠性（guardrails）。记忆是另一个维度：它决定了 Agent 的「性格」和「关系」。
一个能记住你偏好的 Agent 感觉像朋友。一个删不掉记忆的 Agent 感觉像跟踪者。区别在于用户有没有控制权。
hermes-agentmemory 的 600 行代码提供了一个参考答案：记忆系统的设计不只是技术问题，也是信任问题。
这是 AI Agent 系列的第七篇。前几篇：