给 Hermes 接外挂记忆库：真实踩坑全记录

原文链接：https://mp.weixin.qq.com/s/1ZF7TsStconHzfhoLAp7Gw

给 AI 加记忆不难，难的是加完之后还能控制、能回滚、不会炸。

大家好，我是顾海，欢迎来到碎碎念的小盒子。

给 AI 加记忆不难，难的是加完之后还能控制、能回滚、不会炸。

大家好，我是顾海，欢迎来到碎碎念的小盒子。

最近我在折腾 Hermes 的自动记忆。

原来 Hermes 已经有一套记忆系统，能记住不少东西。但它更像是”默认记忆”——助手自己判断什么时候写、写多少。时间一长，问题就暴露了：部署细节、架构决策、事故复盘越积越多，但记忆之间没有结构，搜出来的东西经常是一堆碎片，缺上下文、缺时间线、缺因果关系。

我真正想要的是”记住之后还能查、能整理、能回滚”。

 
记忆全是碎片：从混乱到有序的漫画

所以这次我把 AgentMemory 作为 MCP 工具接了进去。不动主记忆，先做外挂。

为什么选这条路而不是别的？这背后有一个我自己的判断：AI 记忆的核心矛盾不是容量，是可控性。

🧠 为什么不是直接替换？

一开始我也想过：AgentMemory 有 embedding、图谱、压缩、反思，能力挺全，直接让它接管主记忆不是更简单？

部署完之后我反而更倾向先并联。这个判断来自三个观察。

第一，生产记忆不能轻易换底座。 AI 助手的记忆不只是”能搜到东西”——还涉及什么时候写、写多少、什么结构、会不会污染上下文。这些行为模式一旦养成，换底座等于换掉助手的”习惯”，影响所有日常对话。

第二，高级能力是加分项，但也是风险源。 embedding 检索很快，但总结、压缩、图谱抽取都要调模型。模型服务一抖，端到端体验跟着抖——这是所有依赖 LLM 做”智能处理”的工具共同的结构性风险，AgentMemory 只是刚好撞上了。

第三，MCP 工具层的可观测性比内部替换好得多。 我能看到 Hermes 有没有识别 MCP server、发现了多少工具、某次有没有调用、调用了哪个。这比直接塞进内部记忆链路更适合灰度测试。出问题的时候，我可以直接关掉 MCP 配置，主记忆完全不受影响。

所以这次的方案是：主记忆不动，AgentMemory 先以 MCP 工具层接入。

一句话：有收益，但不把主链路绑死。

 
替换 vs 并联：两种接入策略的漫画对比

 
架构：AgentMemory 作为可回滚外挂记忆库接入 Hermes

看图就清楚了：用户对话进来，Hermes Runtime 读配置注册 MCP server，只暴露 9 个精选工具。AgentMemory 提供保存、搜索、图谱、反思，底层走 NPI 网关。主记忆继续用 mem0，两条链路互不干扰。

这个架构的好处是：你可以随时比较两条链路的输出。 主记忆记了什么、AgentMemory 记了什么、它们搜出来的结果有什么差异——这些都可以在实际使用中观察。如果 AgentMemory 某天搜出来的东西明显更好，再考虑让它承担更多；如果不行，关掉就是了。

🏗️ 部署层：装了什么、绑了哪些端口

AgentMemory 装在入口服务器上，四个端口全绑本机：REST API、WebSocket、Viewer、iii engine。

systemd 管三个服务：agentmemory.service、agentmemory-firewall.service、hermes-webui.service。

 
服务与端口状态

这里有个细节值得注意：49134 看起来监听在 0.0.0.0，所以我单独加了防火墙服务做保护。REST、Viewer、Streams 都只绑定 127.0.0.1，不给公网直接访问。

这个部署选择反映了一个更一般的判断：本地服务默认不暴露公网，需要的时候再开。 很多 AI 工具的默认配置是监听 0.0.0.0，好像所有人都应该直接访问它一样。但在生产环境里，尤其是涉及记忆数据的服务，最小权限原则比方便调试更重要。

用的 npm 包是 @agentmemory/agentmemory@0.9.21，embedding 走 BAAI/bge-m3，LLM 走 mimo-v2.5-pro，高级能力全开：压缩、上下文注入、slots、reflect、图谱抽取、consolidation。

 
AgentMemory 运行状态

这个状态页能证明进程和本地 REST 链路是通的。但我踩过一个坑：状态页”绿了”不等于端到端可用。 MCP 是否真的能被 Hermes 识别和调用，还要看 Hermes 自己的检测。不要被”服务正常”四个字骗了——中间还隔着 MCP 协议握手、工具发现、权限匹配好几层。

🔌 Hermes 怎么接的

没有改主记忆 provider，而是在 Hermes 配置里加 MCP server。

我没有用 npx 动态下载的方式，而是固定指向本机已安装的二进制。这个选择的理由很简单：生产环境里，依赖确定性比版本新鲜度重要。 npx 每次运行可能拉不同版本，出问题的时候你甚至不知道跑的是哪个版本。固定路径、固定版本，排查的时候少一个变量。

配置里只开放 9 个工具，覆盖记忆保存、搜索、图谱查询、整合、反思、槽位管理六个方向。

为什么不全开？因为 AgentMemory 实际工具有 53 个，Hermes 一次能全部发现。但生产里不适合一口气放出来。

这里有一个我自己的经验：工具数量和模型行为质量之间存在反比关系。 工具越多，模型越容易”选择困难”——它可能在该直接回答的时候去调工具，也可能在该调工具的时候犹豫不决。53 个工具里有很多是管理类、调试类的，日常对话根本用不上。精选 9 个核心记忆操作，模型的调用决策反而更准确。

 
53个工具全开 vs 精选9个：工具越多越迷糊的漫画

接好之后用 hermes mcp list 和 hermes mcp test agentmemory 验证。

 
Hermes 已识别 AgentMemory MCP

这张截图是整个部署里最关键的一张。 它说明两件事：Hermes 已经识别 agentmemory 这个 MCP server，并且连接成功、发现了完整工具面（53 个）。但暴露给 Hermes 的只有精选的 9 个。这个”发现全量、暴露精选”的设计，我觉得是 MCP 接入最值得借鉴的地方。

⏱️ 实测：快的地方和慢的地方

直连 AgentMemory 做检索很快，大约 70ms 级别。这个速度是可以接受的。

但 Hermes 端到端调用不是这个速度。因为它要走完整链路：解析用户意图 → LLM 判断是否需要工具 → 调用 MCP → AgentMemory 查询 → LLM 整理回答。

之前显式调用检索时端到端约 32 秒，让 Hermes 自己判断要不要查时约 42 秒。

AgentMemory 本身不是慢点，慢的是”LLM 决策 + 工具调用 + 总结回答”的完整链路。

这 32 秒和 42 秒的差距，其实就是”人告诉它去查”和”它自己决定要不要查”的区别。后者多出来的 10 秒，花在了 LLM 思考”这个场景需不需要调工具”上。

 
32秒 vs 42秒：让AI自己想还是直接命令的漫画对比

这个发现让我重新思考了”自动记忆”的定位。 很多人（包括我一开始）的理想是：AI 助手自动判断什么时候该存、什么时候该查、什么时候该整理。但实际上，这个”自动判断”本身就是一次完整的 LLM 推理，它有成本、有延迟、有可能判断错。

所以我现在的策略变成了：存的时候手动触发，查的时候也尽量显式指定。 技术上能做到自动，但性价比目前还不够高。等模型更快、更便宜的时候再放开也不迟。

这次重新做公众号素材时，我又跑了一次真实端到端测试，结果遇到了上游模型服务 503。

 
真实端到端测试里的上游 503

这张截图我反而觉得比成功的截图更有价值。因为它暴露了一个很容易被忽略的事实：你接的不是”一个工具”，而是一整条依赖链。 MCP 协议层是通的，AgentMemory 本地服务也是通的，但端到端体验取决于 NPI 网关和模型供应商的稳定性。任何一个环节 503，用户的体验就是”助手变慢了”或者”助手没反应”。

这也是我坚持”先做外挂、不替换主记忆”的核心原因之一。主记忆的链路更短、依赖更少，出问题的概率天然更低。

说到”看起来正常”和”确实正常”的区别，WebUI 那边也有一个小坑。

🖥️ WebUI 侧的小坑

Hermes WebUI 不是最适合验证 MCP 的地方。

我试过直接访问 WebUI 的 MCP API，返回需要登录态。

 
Hermes WebUI API 需要登录态

这并不是坏事，说明后台 API 有保护。但也带来一个现象：WebUI 里有时候能看到 MCP server 配置，却不一定能直观看到完整工具列表。

真正判断 MCP 是否可用，我更信这两个命令：hermes mcp list 和 hermes mcp test agentmemory，以及真实的一次 oneshot 调用。

这个小坑的教训是：不要用 UI 的”看起来正常”来代替 CLI 的”确实正常”。 尤其是涉及协议握手、工具发现这种底层行为，CLI 的输出比 UI 的状态指示更可靠。

💡 这套东西适合怎么用

我现在给它的定位不是”让 AI 永远记住一切”。

说实话，”让 AI 记住一切”这个想法本身就是有问题的。记忆越多，噪音越大。搜索出来的结果越杂，模型越难做出准确判断。好的记忆系统不是记更多，而是在对的时候给出对的东西。

所以 AgentMemory 在我这里的定位是：给 Hermes 准备一个可查询、可沉淀、可回滚的运维知识库。

适合写进去的内容：两台服务器之间的真实架构、Tailscale 替换 SSH 隧道的决策、各服务的部署路径和端口关系、某次故障的原因和修复过程、用户自己的长期偏好。

不适合写进去的：临时闲聊、一次性命令输出、明文 token 和密码、不确定的猜测。

我把这条线画得很清楚： 只有那些”下次还会用到”且”用错了会有后果”的信息，才值得进 AgentMemory。其他的，聊天记录里留着就行了。

🤔 最后的判断

这次接入是成功的，但我不会马上让 AgentMemory 替换主记忆。

当前最稳的状态是：主记忆继续用 mem0，AgentMemory 作为 MCP 辅助记忆库，embedding 用 bge-m3，LLM 用 mimo-v2.5-pro，工具只开放 9 个精选项，真实使用中观察稳定性和响应时间。

但我更想说的是这次部署背后的一个更大判断：

AI 工具的能力越来越强，但”能不能用”和”该不该用”是两个问题。 AgentMemory 的图谱、压缩、反思确实很酷，但每多一层”智能”，就多一层依赖、多一层延迟、多一层出错的可能。在生产环境里，简单可靠永远是第一位的。先把外挂接上、用起来、踩完坑，再决定要不要让它承担更多。

这不只是对 AgentMemory 的判断，也是对所有”给 AI 加能力”的判断。先并联，再观察，最后才决定要不要替换。 这个节奏，比”功能越强越好”重要得多。

碎碎念的小盒子

这里是顾海，继续把 AI 工具、开源项目和真实上手体验拆给你看。

碎碎念的小盒子，觉得有用就点个赞，评论区聊聊 👇

---

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。