🧠手把手教你用NAS实现Hermes Agent跨设备记忆共享（含踩坑记录）

飞牛OS NAS + Windows Desktop 实战 —— 让你的 AI 助手不再"失忆"

📅 2026-07-08 · 📍 实战案例 · 🏷️ Hermes Agent / Hindsight / 飞牛OS / Docker

🔥 全网首发原创 · 抄袭必究

一、痛点：你的 AI 助手有"多个人格"吗？

如果你像我一样，家里有台 飞牛OS NAS 跑着 Hermes Studio（Web UI），办公电脑上又装了 Hermes Desktop —— 你会发现一个很割裂的现象：

• 在 NAS 上跟 Hermes 聊过的项目背景、偏好设置，Windows 这边的 Hermes 一概不知
• Windows 上调整过的工作流规范，NAS 那边还得重新说一遍
• 明明用的是同一个 AI 框架，却感觉在跟两个陌生人对话

原因很简单：默认情况下，每个 Hermes 实例的记忆各自存在本地，互不相通。

本文记录了我如何利用 Hindsight 的 local_external 模式，在飞牛OS NAS 上用 Docker 自托管一个共享记忆后端，让家中所有 Hermes 实例共用同一套「长期记忆」的真实全过程。零基础也能跟着做。

**💡 先说结论：**整个配置只需要改一个 JSON 文件里的一行字段，不需要写任何代码。核心就是改 "mode": "local_external"。

二、我的环境

**📌 说明：**Hermes Agent 是目前 GitHub 上很火的开源 AI 代理框架（Nous Research 出品，200K+ Stars），核心卖点是自带学习闭环：自动保存记忆、自动提炼技能、跨会话持久化。Hermes Studio 是社区开发的 Web 管理面板，Hermes Desktop 是官方 Electron 桌面客户端。两者底层都用相同的 Hermes 运行时。

网络连接方式：多种方案供你选

要让 Windows 能访问 NAS 上的 Hindsight API（端口 8888），有几种常见的组网方式。根据你的网络环境和设备情况选择一种即可：

💡 选择建议：* 同局域网 → 直接用内网 IP，最简单

• 远程访问 → 推荐 节点小宝 或 Tailscale，零配置 P2P 直连
• 有公网服务器 → 可以用 Nginx/Caddy 反代，加 HTTPS 更安全。注意 1Panel 的 OpenResty 反代需手动设置 proxy_pass，不会自动透传
• FN Connect → 适合浏览器访问 Hindsight 控制面板（:9999），但不适合 Hermes 客户端直连 API，因为需要 Web 登录认证

配置中 api_url 的填写方式也因方案而异，后面实操部分会详细说明。

📸 图1：NAS Hermes Studio 端记忆迁移完成后的提示 —— 两侧 100+ 条记忆已汇聚到共享库

三、架构原理：三个"记忆层"一次讲清

在动手之前，必须理解 Hermes 的三层记忆体系，否则后面配置错了都不知道问题在哪：

我们的目标是让 **第三层（语义记忆）**从「各自本地」改为「NAS 共享」。来看看改完之后的数据流向：

原理出奇地简单：两边指向同一个 API 地址、使用同一个 bank_id，Hindsight 自动保证记忆互通。

**🧠 官方背书：**Hindsight 官方文档专门有指南 "Hermes Shared Memory Across Agents Setup" 和 "Give Hermes Cross-Device Memory with Hindsight Cloud"，明确说了：
Multiple agents do not need a special federation layer. They just need to point at the same Hindsight backend and the same bank_id.
—— 多个代理不需要特殊联邦层，只需要指向同一个后端和同一个 bank_id。

四、实操部署（小白也能照做）

第1步：在飞牛OS NAS 上部署 Hindsight API Server

打开飞牛OS 的 Docker 界面 → Compose，粘贴以下内容：

📄 docker-compose.yml飞牛OS Docker Compose

services:
  # ---------- PostgreSQL + pgvector ----------
  db:
    image: pgvector/pgvector:pg18
    container_name: hindsight-db
    restart: unless-stopped
    environment:
      POSTGRES_USER: hindsight_user
      POSTGRES_PASSWORD: 你的密码       # ← 改这里
      POSTGRES_DB: hindsight_db
    volumes:
      - hindsight_pg_data:/var/lib/postgresql/18/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U hindsight_user -d hindsight_db"]
      interval: 10s
      timeout: 5s
      retries: 5

  # ---------- Hindsight API Server ----------
  hindsight:
    image: ghcr.milu.moe/vectorize-io/hindsight:latest  # 国内镜像加速
    container_name: hindsight-app
    restart: unless-stopped
    ports:
      - "8888:8888"   # API 服务
      - "9999:9999"   # 控制面板
    environment:
      - HINDSIGHT_API_DATABASE_URL=postgresql://hindsight_user:你的密码@db:5432/hindsight_db
      - HINDSIGHT_API_LLM_PROVIDER=deepseek
      - HINDSIGHT_API_LLM_API_KEY=你的DeepSeek API Key
      - HINDSIGHT_API_LLM_MODEL=deepseek-v4-flash
      - HINDSIGHT_API_LLM_BASE_URL=https://api.deepseek.com
      - HINDSIGHT_API_WORKER_ID=hindsight-nas-prod
      - HINDSIGHT_API_RUN_MIGRATIONS_ON_STARTUP=true
      - HF_ENDPOINT=https://hf-mirror.com    # HuggingFace 国内镜像
    depends_on:
      db:
        condition: service_healthy

volumes:
  hindsight_pg_data:

部署后验证：

curl http://你的NAS地址:8888/health
# 预期返回: {"status":"healthy","database":"connected"}

**⚠️ 国内网络注意：**官方镜像在 ghcr.io，下载较慢。上面的 docker-compose 已使用 ghcr.milu.moe 国内镜像源加速。如果下载失败，也可以先拉取 slim 版本：ghcr.milu.moe/vectorize-io/hindsight:latest-slim，slim 版本只有 500MB 左右。

**📌 资源需求：**Hindsight full 镜像约 1.5GB 内存，slim 约 512MB。PostgreSQL 约 512MB。飞牛OS 空闲 8GB 内存完全够用。

🔧 真实踩坑：LLM Provider 选择
docker-compose 里 HINDSIGHT_API_LLM_PROVIDER 这个字段非常关键。一开始我填了 openai_compatible（想着 DeepSeek 兼容 OpenAI 格式），但 Hindsight 的 slim 版和完整版都不支持这个 provider 值。服务日志里反复报错，启动后一直 pending_consolidation 不干活。

修正方案：直接用 deepseek 作为 provider，同时设置 HINDSIGHT_API_LLM_BASE_URL=https://api.deepseek.com。改完之后重启容器，consolidation 立刻开始工作。

🔧 真实踩坑：镜像标签的选择
一开始用了 latest-slim（想着体积小），但 slim 版需要外部 embedding/reranker 服务。如果你没有配置外部 embedding 服务（比如 OpenAI Embeddings 或自建 TEI），建议直接用 latest 完整版，它内置了本地 BGE 嵌入模型和 cross-encoder 重排序器，开箱即用。

最终我换成了 ghcr.milu.moe/vectorize-io/hindsight:latest（完整版约 9GB 镜像，但运行内存也只占 1-1.5GB），省去了配置外部 embedding 的麻烦。

🔧 真实踩坑：数据库密码填法
docker-compose 中 HINDSIGHT_API_DATABASE_URL 里的密码需要和 PostgreSQL 的 POSTGRES_PASSWORD 完全一致。一开始用了 *** 占位符，容器日志报数据库连接拒绝。修改成统一密码后，PostgreSQL healthcheck 通过，Hindsight 成功连接。

另外建议同时设置 HF_ENDPOINT=https://hf-mirror.com，Hindsight 启动时会下载 HuggingFace 模型，国内网络不用镜像几乎下不动。

**💡 部署调试口诀：**翻日志 → 定位错误 → 修配置 → 重启容器 → 验证。我们前后迭代了 3 轮才把所有配置修对。耐心翻 docker compose logs hindsight 是解决问题的关键。

第2步：备份并修改 Windows 端配置

找到配置文件：

%LOCALAPPDATA%\hermes\hindsight\config.json

先备份：

copy %LOCALAPPDATA%\hermes\hindsight\config.json
     %LOCALAPPDATA%\hermes\hindsight\config.json.bak

然后改为（根据你的网络方案选择 api_url）：

📄 config.jsonWindows ~/.hermes/hindsight/

{
  "mode": "local_external",
  "api_url": "http://你的NAS地址:8888",  // ← 看下面选哪个
  "bank_id": "hermes",
  "recall_budget": "mid",
  "timeout": 120
}

api_url 填写对照表：

第3步：修改 NAS Hermes Studio 的配置

找到 Hermes Studio 数据目录下的配置：

# 默认在 Docker volume 映射的路径下
./hermes_data/hindsight/config.json

同样改为 local_external，注意 bank_id 必须完全一致（大小写敏感）：

{
  "mode": "local_external",
  "api_url": "http://localhost:8888",
  "bank_id": "hermes",
  "recall_budget": "mid",
  "timeout": 120
}

**⚠️ 最容易踩的坑：**两边 api_url 可以不同（NAS 用 localhost，Windows 用 NAS 的内网 IP），但 bank_id 必须一模一样。如果一边写 "hermes" 另一边写 "my-hermes"，它们就是两个独立的 bank，互不相通。

🔧 真实踩坑：共享 bank 首次为空
两边的 local_external 都配置好之后，我发现 Hindsight API 报错说 bank 不存在。因为 Hindsight 的 bank 是按需创建的，但首次写入时如果 API 没自动创建，就需要手动创建。

解决：直接通过 API 创建一个 bank 即可，不需要额外工具：

# 手动创建 hermes bank
curl -X POST http://localhost:8888/v1/default/banks \
  -H "Content-Type: application/json" \
  -d '{"bank_id": "hermes"}'

创建后两边就可以正常读写共享记忆了。

📸 图2：Windows Hermes Desktop 端部署完成的交付清单 —— 双向验证通过，114 条记忆成功汇聚

五、验证：双边真的互通了吗？

配置改完之后，重启两边的 Hermes。然后在 任意一端 说：

请记住：我的跨设备记忆测试通过了，另一端应该也能收到这条信息。

然后到另一端问：

帮我 recall 一下，另外那台机器上最近有什么新记忆？

如果两边都能 recall 到对方写入的信息，就说明成功了。

你也可以直接通过 API 查看共享库状态：

# 查看 bank 统计
curl http://你的NAS地址:8888/v1/default/banks/hermes/stats

# 列出所有记忆
curl http://你的NAS地址:8888/v1/default/banks/hermes/memories/list?limit=10

我们的实际成果

共享库里包含了用户画像、技术栈偏好、工作流铁律、NAS 环境配置、政策知识库结构、Codex 协作约定等关键信息。下面是 Windows 端 recall NAS 端记忆的实际截图：

✅ NAS 的关键信息成功在 Windows 端被 recall：
"Hermes Studio 运行在 NAS 飞牛OS 上，systemd 服务端口 8648"
"政策知识库有 354 份政策文件，存储在 /vol1/1000/Wiki/raw/policies/"
"异地组网隧道会拦截 WebSocket 连接，5 个客户端 Socket.IO 连接需强制使用 polling 模式"
"1Panel OpenResty 反代需手动设 proxy_pass"

六、旧记忆怎么办？

切换后，旧的本地记忆（local_embedded 模式下的 pg0 数据）不会丢失，但也不会自动进入共享库。你需要做一个 "半迁移"：

1. 在切换前，让 Hermes 用 hindsight_recall 工具把你的本地记忆 dump 出来
2. 切换后，用 hindsight_retain 写回共享库
3. 或者更简单：读取 MEMORY.md / USER.md 中的关键信息，让 Hermes 重新存入

我们的迁移清单（NAS 端 13 条）

Windows 端迁移了 7 条用户画像和环境配置，加上两边 auto-retain 自动积累的 90+ 条 observation，共享库总计 114 条记忆。

**💡 核心原则：**语义记忆才值得共享，具体对话细节不需要。Hindsight 的 observation 层会自动从对话中提炼可共享的事实，这是它比直接同步 state.db 更优雅的地方。

📌 持久化防踩坑：迁移完成后，务必把部署参数、API 地址、bank_id、踩坑记录等关键信息也写进共享记忆。这样下次调试或重装时，直接问 Hermes "之前的共享记忆是怎么配置的" 就能回忆起来，不用再翻文档。我已经把这篇文章的要点全部存入了持久记忆。

七、翻车了怎么办？回滚指南

整件事最让人放心的一点：新老数据完全隔离，旧记忆从未被删除。 回滚只需要 10 秒：

旧记忆在本地 pg0 中毫发无损。切换只是改了一行 "mode" 而已。

八、下一步：Webhook 互相维修通道

目前的记忆共享方案解决了「信息同步」的问题，但还有一个场景没覆盖：

如果一边出问题了，另一边怎么远程修复？

我的下一步计划是利用 Hermes 自带的 Webhook 功能，在两边各开一个 HTTP 通道：

工作流程：

• Windows 端发现某技能失效 → 本地决策修复方案 → POST 一个修复指令到 NAS 的 webhook
• NAS 端收到后自动执行修复 → 反馈结果
• 反过来也一样

这样两边不仅能「共享记忆」，还能「互相维修」，形成一个真正的自愈闭环。等实现了我再写续篇。

九、总结

跨设备记忆共享这件事，其实没有大多数人想象的那么复杂。Hindsight + Hermes 的组合已经把基础设施搭好了，你要做的只是：

• 🐘在 NAS 上用 Docker Compose 起 PostgreSQL + Hindsight API✅
• 🔧两边各改一个 JSON 文件（"mode": "local_external"）✅
• 🔗确保 bank_id一致✅
• 🧪验证双边 recall✅

整个过程不需要写代码、不需要理解复杂的网络协议、不需要第三方的云服务。前后花了一个晚上，收益是：以后你在任何一台设备上跟 Hermes 聊过的内容，另一台设备自动就知道。

如果你也遇到了同样的问题，或者有自己的跨设备方案，欢迎在评论区讨论 👇

附录：常用 API 速查

© 2026 饭海辛 · 原创技术文章

🚫 本文系原创，抄袭必究。转载请联系作者。

欢迎在评论区提问、纠错、分享你的方案
如果本文对你有帮助，点个赞让更多人看到 🙏