从 OpenClaw 到 Hermes：用自建 Honcho 管理 Agent 记忆
我在使用 Agent 的过程中逐渐发现，记忆文件一多，检索就会变得很慢。把所有对话都堆进一个文件，短期内省事，时间一长，重要信息容易被淹没，上下文也会越来越重。
我最开始使用 OpenClaw，采用的是一套以文件和定时任务为主的记忆方案。后来我把 Agent 运行环境换成了 Hermes，记忆管理也随之独立出来：自己部署 Honcho，再接入 LLM 负责记忆抽取、整理和更新。
现在的重点已经从“把记忆文件分好”转向“让记忆能够被持续处理和按需取回”。下面先回顾 OpenClaw 阶段的文件方案，再说明我为什么换到 Hermes + Honcho。
从 OpenClaw 换到 Hermes
OpenClaw 阶段，我主要依赖 workspace 里的 Markdown 文件、定时任务和命令行检索。它的优点是透明，打开文件就能看到 Agent 记住了什么，出现问题时也容易手动修改。对于个人项目和早期探索，这种方式足够轻量。
随着会话变多，文件记忆逐渐暴露出边界：哪些内容应该长期保留，需要额外判断；摘要、归档和索引要靠定时任务维持；换一个 Agent 运行环境后，原来的注入和脚本也要重新适配。记忆层和 Agent 本身绑得越紧，迁移时需要一起搬动的东西就越多。
切换到 Hermes 后，我把 Agent 的执行环境和记忆服务拆开。Hermes 负责日常对话、任务执行和工具调用，Honcho 单独保存会话与事件，并通过 LLM 对这些内容进行记忆处理。这样换 Agent 时，记忆服务仍然可以作为独立的一层继续使用。
自建 Honcho：把记忆管理独立出来
我部署的是自己的 Honcho 实例，没有直接把所有记忆交给托管服务。这样做主要是为了掌握数据存放位置、模型服务和处理流程，也方便根据自己的使用量调整成本和排查问题。
目前这套流程可以概括成四步：
1 | Hermes 对话与工具事件 |
记忆写入之后，LLM 会参与判断哪些内容值得保留、哪些内容需要合并，以及旧信息是否已经失效。检索阶段再根据当前问题取回相关上下文，避免每次都把完整历史塞进 Prompt。
这套方式和单纯保存向量片段的思路有些不同。向量检索擅长找相似内容，LLM 参与的记忆管理还要处理“这是谁的偏好”“这条决策是否已经被更新”“几段对话能不能合并成一个稳定事实”等问题。最终送回 Hermes 的内容需要足够短，也要尽量保留来源和时间线索。
自建 Honcho 也带来了额外工作：服务部署、数据库、模型调用、异步处理和失败重试都需要自己维护。它没有消除记忆工程，只是把原本散落在 Agent 配置和脚本里的事情集中到了一个可以观察、调试和迭代的服务里。
OpenClaw 阶段的文件方案
下面这套目录是我在 OpenClaw 阶段使用过的方案。即使现在主要由 Honcho 负责记忆处理，它仍然帮助我理解了长期记忆、工作记录和历史归档之间的边界。
1 | workspace/ |
MEMORY.md：只放稳定信息
这个文件适合存放用户偏好、当前项目、已经确认的关键决策和经常使用的资源位置。我的判断标准是：以后如果没有这条信息，是否容易重复犯错。
为了避免它不断膨胀，我给长期记忆设了一个约 80 行、5KB 的上限。日常细节留在每日文件里，经过筛选、以后还会反复用到的内容再进入这里。
每日文件：先记录，再判断
当天的会话摘要、临时方案和待办放进 memory/YYYY-MM-DD.md。这些内容不需要一写入就被判定为“长期事实”，否则很容易把短期状态误写成永久偏好。
archive：整理前先留副本
每次整理长期记忆前，先把旧文件备份到 archive/。记忆压缩本身也可能出错，保留历史版本至少能让问题有迹可循。
OpenClaw 阶段的两个定时任务
我把后台流程分成“同步”和“整理”两步。
记忆同步
同步任务按固定间隔运行，主要做这些事情：
- 找出最近一段时间有活动的会话。
- 跳过消息过少或已经处理过的会话。
- 提取事实、决策和待办，生成短摘要。
- 写入当天的记忆文件。
- 重新建立索引。
这里不追求把每句话都保存下来。对 Agent 来说，记录太完整有时和没有记录差不多，因为真正有用的信息反而很难被找到。
记忆整理
每天再运行一次整理任务，把每日记录里的稳定信息提炼到 MEMORY.md。我通常会问四个问题：
- 没有它，未来是否容易犯错？
- 之后是否会重复使用？
- 脱离原始对话后，单独看能不能理解？
- 长期记忆里是否已经有重复内容？
答不上来的内容，就继续留在每日记录里，不急着升级。
为什么 OpenClaw 阶段使用 isolated session
同步和整理都属于后台工作，不应该卡住主会话，所以定时任务使用独立会话执行。
这样做之后，主会话不需要等待索引或摘要完成，后台任务失败时也比较容易单独排查。不过独立会话有一个要求：任务提示词必须把读取范围、跳过条件、写入位置和完成后的汇报方式说清楚，否则任务可能执行了，主会话却不知道结果。
从 OpenClaw 命令到 Honcho 检索
在 OpenClaw 阶段，我会通过命令检查索引，再用关键词或语义搜索找回旧内容：
1 | openclaw memory status |
换到 Hermes + Honcho 后，检索链路变成了“写入 session → LLM 整理 → 查询相关记忆 → 注入当前上下文”。关键词检索适合定位明确名词，语义检索适合找回意思相近的内容，LLM 则负责把检索结果整理成当前 Agent 能直接使用的上下文。
embedding provider、记忆处理模型和检索参数仍然要以当前自建环境为准。我的做法是用几条已知事实反复验证：能不能找回来，是否混入相似但无关的内容，旧事实更新后是否还会被错误召回。
凭据和隐私
记忆文件有可能包含个人偏好、服务器信息和项目上下文，不能把它当成普通文档处理。
- API Key 不写进 Markdown，也不提交到公开仓库。
- 配置使用环境变量或受保护的凭据文件。
- 公开文章中的服务器地址、账号和内部路径全部脱敏。
- 定期检查归档文件，删除已经不需要的敏感信息。
如果只是为了写一篇配置分享，宁可少展示一段，也不要把真实凭据和内部环境带出去。
目前还不够完善的地方
接入 Honcho 和 LLM 后，记忆管理的能力更完整了，判断错误的可能性也仍然存在。模型可能漏掉上下文，把一次性的表达误判成长期偏好，或者在新旧事实冲突时没有给出正确的优先级。语义搜索和混合检索也可能返回“意思接近但并不相关”的内容。
自建服务还要考虑异步队列、模型调用成本、失败重试和数据备份。新消息写入后，记忆表示未必会立刻更新，Agent 读取到的内容需要区分实时会话和后台整理结果，不能把所有状态都当成已经稳定的长期事实。
我现在比较重视每条记忆的来源、更新时间、置信度和失效方式。能被找到很重要，知道它从哪里来、什么时候应该失效，也同样重要。Honcho 让这套处理链路更容易独立演进，记忆治理仍然需要持续维护。
