Hermes实战案例_NAS 上跑了个 AI 管家：从信息孤岛到飞书一句话调度

---

title: NAS 上跑了个 AI 管家：从信息孤岛到飞书一句话调度

date: 2026-05-05
categories: [技术实践, Docker, AI]
tags: [NAS, Docker, AI Agent, 飞书, 思源笔记, Hermes]

NAS 上跑了个 AI 管家：从信息孤岛到飞书一句话调度

我在飞牛 NAS 上跑了一堆 Docker 服务：思源笔记、下载器、相册管理......原本每个服务都是独立的------各自登录、各自管理、互不通信，就像海上的一个个孤岛。

直到我把 Hermes Agent 部署上去。现在我只用一个入口------飞书聊天------说一句话，它就去帮我操作所有服务。

为什么选 NAS？两个理由。

第一，数据安全。 所有东西跑在自己硬件上，数据不出家门。飞书只是交互界面，笔记、配置、凭证全在 NAS 本地。

第二，NAS 本来就是 24 小时开机。 在上面多跑一个 Agent 容器，等于零额外电费和硬件成本，白嫖一台 7×24 的 AI 服务器。

所以条件很自然：家里有台常年开机的 NAS → 上面跑着 Docker → Docker 里跑着 Hermes → 通过飞书与它聊天 → 它去调度 NAS 上所有服务。

---

一、Hermes 是怎么装上去的

文章不能只讲 Agent 做了什么，得先讲清楚它自己是怎么站住的。

1.1 Docker 部署

Hermes Agent 官方提供了 Docker 镜像，直接用 Docker Compose 拉起来的：

services:
  hermes:
    image: nousresearch/hermes-agent:latest
    container_name: hermes
    restart: unless-stopped
    user: "1000:1000"
    ports:
      - "9868:9868"
    volumes:
      - ./data:/opt/data
    command: gateway run
    environment:
      - TZ=Asia/Shanghai

1.2 持久化设计

容器销毁了重新拉一个就行，但数据不能丢。所有持久数据挂在 ./data 卷上：

• config.yaml --- Hermes 主配置（模型、平台、工具集）
• .env --- API Key、服务地址、思源密码
• skills/ --- 自定义技能模块
• cron/ --- 定时任务持久化
• memory/ --- 跨会话记忆

NAS 设置了夜里定时关机。但只要 restart: unless-stopped + 持久卷，重启后容器自动恢复，配置、cron、记忆全在，真正做到了 7×24 无感。

---

二、容器里的 AI，怎么找到隔壁的邻居

2.1 孤岛问题

Hermes 跑在一个 Docker 容器里，思源笔记跑在另一个容器里。docker0 网桥默认分配 172.17.0.x 网段。Hermes 的 IP 是 172.17.0.3，其他服务通过端口映射暴露到宿主机。

问题来了：在 Hermes 容器里 curl localhost:6806，能连上思源吗？

不能。容器的 localhost 指向自己，不是宿主机。

2.2 解法：Docker 网关

最简单的方式是走 Docker 网关 IP：

curl http://172.17.0.1:6806

返回 HTTP 401！说明网络通了，只是需要认证。

从此 Hermes 可以通过 172.17.0.1:端口 访问 NAS 上任何暴露了端口映射的容器------这些孤岛被一座桥连了起来。

2.3 认证自动化

思源笔记配置了 accessAuthCode 密码保护，每次新会话都要重新登录。我把它做成了一个 skill：

• 服务地址和密码写进 .env
• skill 封装完整流程：加载 → 读变量 → POST 登录 → 拿 cookie
• 以后每次需要访问思源，Hermes 自动走这个流程

用户无感知。在飞书说一句「帮我把这篇飞书文档同步到思源笔记」，它就自己登录、拉数据、建文档、写内容------一气呵成。

---

三、飞书和私有笔记之间的数据搬运工

3.1 痛点

跟 Hermes 在飞书上聊了很多技术讨论，但内容散落在聊天记录里。需要一个私有知识库把有价值的内容沉淀下来。

3.2 技术实现

NAS 上跑着思源笔记，用它做知识库，Hermes 当中间人。飞书 API 把文档组织成树状块结构（block），每个块有类型和文本元素。Hermes 按顺序解析，转成 Markdown。

思源提供了 createDocWithMd 接口，传标题和 Markdown 正文就能创建一篇完整文档。两套 API 完全不同，Agent 做中间翻译。

3.3 效果

飞书文档 → 解析块结构 → 转 Markdown → 登录思源 → 创建文档 + 写入 → 完成。全程 10 秒左右。

这跟传统自动化脚本最大的区别在于------Agent 是活的。它自己判断调哪个 API、先认证再请求、遇到问题还能自己修。

---

四、整体架构

把结构抽象出来，三层：

【外部】
用户（手机/PC）←→ 飞书（通信平台/Open API）

【Agent 层】
Hermes（容器 172.17.0.3）
  ├─ 飞书网关（消息收发）
  ├─ Skill 层（技能模块）
  ├─ 认证层（Cookie/Token 管理）
  ├─ 工具层（HTTP/API 调用）
  └─ 持久卷 /opt/data

【服务层】
Docker 网关（172.17.0.1）
  ├─ 思源笔记（:6806）
  ├─ 其他容器服务
  └─ 飞书云文档（REST API）

关键设计原则：

原则	说明
统一入口	飞书是唯一的用户界面，不记端口不记 IP
Agent 做胶水	所有跨系统调用由 Agent 动态编排
数据私有化	API 密钥和隐私数据不经过第三方
配置即代码	地址和凭证写在 .env，封装到 skill

---

五、踩坑记录

1. 容器里 localhost 不是宿主机

经典新手坑。在容器里 curl localhost 指向自己。用 Docker 网关 172.17.0.1 解决。

2. 思源 cookie 会过期

每次新会话 session 失效。在 skill 里封装自动重登录，操作前检查 cookie。

3. 飞书文档不支持增量更新

飞书 Docx API 只能追加子块，不能修改已有块。想改只能重建整个文档。

4. NAS 定时关机

restart: unless-stopped + 持久卷保住了所有数据，重启后自动恢复，cron 任务都不丢。

---

六、一点感想

以前：登录 NAS → 打开 Docker → 查端口 → SSH → 敲命令。等操作完，已经没有分享欲了。

现在：在飞书说一句，它就干了。

从「我告诉计算机怎么干」到「我告诉计算机我要什么」------Agent 自己去拆解、找 API、认证、执行、纠错。这是交互范式的变化。

下一步计划：

• 飞书讨论定期整理归档入思源
• RSS + AI 摘要自动归档
• Home Assistant 联动，自然语言控制智能家居

写于 2026 年 5 月 | 持续折腾中