你用过的大多数 AI 聊天界面，其实没有真正的记忆这种东西。它们只有一个上下文窗口，那完全是另一回事。你在同一段对话里早些时候说过的话，模型还看得见；你昨天那段对话里说过的话，没了。第二天从零开始，助手又像个陌生人一样跟你重新打招呼。
Hermes Agent 不一样。它有一层真正的记忆——和对话上下文是分开的——它会随时间慢慢了解你，把这些东西跨会话、跨平台带着走，让你每次跟这个 bot 对话时，它都像是同一个"谁"。这篇文章讲它到底是怎么跑的、哪些设计选择是要紧的，以及 v0.7.0 那套可插拔的记忆接口到底改了什么。
短期记忆 vs 长期记忆
先把要紧的那个区分讲清楚。
Hermes 里的短期记忆就是这次会话的上下文窗口。它是 agent 当下这段对话的那一片历史，配着一套主动压缩策略：上下文逼近模型上限时，Hermes 会跑一次总结压缩，把更老的轮次收成一份结构化的摘要，同时把最近的几轮原封不动地留下来。这个压缩过程隔几个版本就调一次——v0.4.0 引入了结构化摘要和迭代更新，后来又加上 token 预算的尾部保护、可配置的摘要端点、还有兜底模型支持。长对话里，它默默帮你省钱省时间，又不会把重要的上下文丢掉。
长期记忆才是有意思的那一半。它是一个装着事实、偏好、纠正和用户模型的仓库，住在对话之外。今天你在 Telegram 上告诉这个 bot "我叫 Alice"，这条信息会被写进长期记忆。明天你在 Slack 上问它事情，这条信息会被捞出来、塞进上下文，然后 agent 才看到你的消息。模型能看到的仍然只是窗口塞得下的那部分，但这个窗口已经被它该知道的、关于你的那些事情垫好了底。
短期记忆是一块缓存。长期记忆是一个人。
Honcho：它是什么，为什么重要
Hermes 默认的长期记忆提供者是 Honcho，一个专门为 AI 原生记忆做的库。它的工作就是跑在 agent 后面，做三件具体的事：
- 1.观察。 每条用户消息、每条 agent 回应都会作为事件流灌进 Honcho。Honcho 从这串流里建出一套内部的用户模型——不是原始聊天历史，而是从对话里推理出来的结构化事实和偏好。
- 2.对用户做推理。 Honcho 跑着一层小小的"辩证"逻辑，试图拼出一张关于你是谁、你想要什么、你纠正过什么的完整画像。这不是关键词提取——它是一个实时运行着的用户心智模型。
- 3.注入。 每一个新回合，Honcho 都会产出一段简短的上下文片段，总结它认为关于你的哪些事情是要紧的，Hermes 把这段拼在系统提示词的前面。Honcho 学到越多，这段片段就越在变。
有两个细节值得单独指出来，因为太容易被忽略。
第一，Honcho 的写操作是异步的。agent 不会阻塞在一次记忆写入上。它先把话说出去，记忆层在后台慢慢处理刚才那次交互。这意味着长对话不用为记忆更新交一份延迟税，记忆后端挂掉也不会拖住 bot——挂掉期间丢的是那段时间的更新，但助手照样在说话。
第二，Honcho 召回出来的那段内容是放在缓存的系统前缀之外的。Anthropic 的 prompt caching 特性（在 Claude Sonnet 4.6 这类模型上被重度使用）希望系统提示词在各轮之间保持稳定，这样缓存才能命中。Honcho 注入的那段每一轮都在变，所以 Hermes 故意把它拼在缓存的系统段后面。静态的部分照样吃缓存，动态的记忆层照样跟得上变化。这类机械层面的取舍是不会出现在 release notes 里的，但它决定了你每个月的账单是 50 美金还是 500 美金。
网关模式下的多用户隔离
Hermes 网关默认是让多个用户跑在同一个 agent 进程里的。长期记忆必须按人分开，否则 Alice 的过敏史就会跑进 Bob 要的做饭建议里。v0.3.0 这一版在网关里给 Honcho 加上了像样的多用户隔离，具体来说就是：
- •每个网关用户 ID 映射到一个独立的 Honcho peer，记忆写入按 peer 隔开作用域。
- •群聊会话默认继承"按人分会话"的行为，所以就算大家共享一个频道，记忆流仍然是每个参与者各写各的。
- •按 profile 隔离记忆（v0.5.0 / v0.6.0）意味着：你在同一台机器上跑多个 Hermes profile 时，每个 profile 的记忆都是一个独立宇宙。切换 profile 的时候，不会让一个身份的东西漏进另一个身份里。
这些东西用户是一个都看不见的。但它们加起来，才是这个 bot 不会把人记串的原因。
可插拔的记忆接口（v0.7.0）
Hermes 头五个版本里，Honcho 是被写死的。到 v0.7.0，记忆层被重构成了一套像样的 provider 接口——一个不大的 Python ABC，任何记忆后端都可以去实现它。这个改动在架构上并不激进，但在实际效果上大得吓人。
这个接口让你换记忆后端时完全不用动 Hermes 的内核：
- •Honcho 是那个参考实现（目前也仍然是默认）。它功能完整，跑着一套真正的用户模型，多用户隔离也做对了。
- •Supermemory 是 v0.8.0 加进来的第二个一等公民 provider，带多 container 支持、可配置的搜索模式，以及身份模板化。
- •mem0、OpenViking、RetainDB、Hindsight、ByteRover 都有社区写的记忆插件挂在 Hermes 的插件系统上，集成深度各不相同。
- •你也可以自己写一个。那个 ABC 很小：实现
write()、recall()，几个生命周期钩子，然后作为插件注册一下就行。
那个内置的记忆 provider——如果你什么都没配，就走的那个零依赖默认档——是一个 SQLite 作底的事实存储，做最基本的几件事：写事实、按相关度召回、按用户分作用域。它不像 Honcho 那么聪明，但它不依赖任何外部服务。对一个跑在 5 美金 VPS 上的个人助手来说，这通常就够了。
这件事悄悄解锁的可能性
可插拔记忆是那种在 release notes 里看起来像扫地工活儿的架构改动。"把记忆重构成一层 provider 接口"这句话当不了头条。但它真正做的事情，是把"一个 AI 助手到底该记住你哪些东西"这个问题，和"Hermes 是怎么跑的"这个问题彻底拆开了。
你现在可以把 Honcho 换成任何一个更适合你场景的记忆后端——想对个人知识库做语义搜索的人可以换向量库；想要显式实体关系的人可以换图数据库；不想让任何记忆数据离开自己机器的人可以换成纯本地 SQLite；团队用的场景可以接一个公司内部的记忆服务。agent 本身一点都不用动，变的只是 memory 这个接口背后那个东西。
对一个想活很多年的项目来说，这是正确的抽象层次。记忆这件事是很私人的，适合你的那个记忆后端不一定适合别人。Hermes 的本分，是对你插上来的任何一层记忆都保持良好公民的姿态，然后让开，不挡着它。