开发过程中有些细节容易被忽略，今天挑几个重点聊一聊。
让 NAS 里的 AI 真正常驻：Hermes 接入微信，从本地 Agent 到远程管理
把 RK3566 小主机变成 AI 管家：飞牛 NAS 部署 Hermes，接入微信还能远程访问
前言
最近我一直在折腾“让 AI Agent 长期跑在家里设备上”这件事。
之前也试过 OpenClaw 一类工具，能力很完整，平台接入也不少。但真正把这类 Agent 放到 NAS 上长期运行时，我更在意的不是功能列表有多长，而是几个很实际的麻烦：部署麻不麻烦、配置维护重不重、消息入口是否顺手，以及一台性能并不算强的小主机能不能长期承担这个角色。
所以这次我把目标换得更具体一点：拿一台已经刷好飞牛 NAS ARM 版的 RK3566 小主机，实际跑一遍 Hermes。
我想验证四件事：
- Hermes 能不能在这台小主机上正常部署；
- DeepSeek 模型能不能顺利接入并搞定对话；
- 微信能不能变成一个真正可用的日常消息入口；
- 如果人在外面，还能不能远程打开 Hermes 的 Web 控制台。
9119 WebUI 的公网访问、固定地址和 HttpAuth。
这篇这篇不是想证明“NAS 一定要变成 AI 管家”，而是看一台 24 小时在线的 RK3566 小主机，究竟能不能把 Hermes 变成一个真正随时可用的常驻 AI 助手。
1 Hermes 是什么？我为什么想把它放到 NAS 上？
Hermes 是一个开源的 AI Agent 项目，可以通过 终端、Web 控制台和消息平台 进行交互。
和普通“打开网页问一句、关掉就搞定”的聊天工具相比，我更关注 Hermes 这种常驻 Agent 的用方式：它可以一直运行在一台长期在线的设备上，消息从不同入口进来，再交给同一个 Agent 处理。
NAS 恰好具备这个条件。
一台飞牛 NAS 本来就会长期在线，也已经具备 Docker、网络服务和远程管理能力。把 Hermes 放进去，不要再单独准备一台专用电脑。真正要验证的是：像 RK3566 这种并不算高性能的小主机，能不能稳定承担 Agent 的“常驻入口”角色。
所以后面不会只停留在“容器启动成功”，而是继续验证模型、微信和 WebUI。
2 Docker 一键部署 Hermes
这次测试用的是一台已经刷好飞牛 NAS ARM 版的 RK3566 小主机。
飞牛 NAS 本身支持 Docker，所以这里不要额外安装 Docker。部署前只做两件事：确认 Docker 服务已经开启，再打开 SSH，后面的 Hermes 初始化都通过终端搞定。
这一阶段的判断标准也很轻松：先把 Hermes 本体跑起来，并确认终端对话和 Web 控制台都能访问。
首先打开飞牛 NAS 桌面的【Docker】，确认 Docker 服务已经开启。然后进入【系统设置】里的【SSH】，把 SSH 服务打开，后面的命令要通过终端执行。
然后进入【系统设置】中，选择【SSH】，将其启用：
接着，电脑摁下【Win + X】键，选择【终端（管理员）】打开PowerShell窗口：
然后在终端输入如下ssh命令，进行远程连接你的飞牛Nas终端：
ssh n1@192.168.50.212
如下图所示：
接着，在终端执行如下命令，切换至root用户（输入密码时不会显示）：
sudo -i
2.2 部署Hermes
切换到 root 用户以后，开始执行部署脚本。这里先完成 Hermes Agent 本体安装，再进入初始化向导配置模型：
curl -fsSL https://gitee.com/jun-wan/script/raw/master/fnos-hermes/fnos-hermes.sh -o /tmp/fnos-hermes.sh && chmod +x /tmp/fnos-hermes.sh && /tmp/fnos-hermes.sh
脚本启动后按原文步骤直接回车进入 Hermes 初始化向导，并等待镜像拉取完成：
拉取完成后，会出现如下选项，直接选择快速开始即可（Quick setup）：
进入 Select provider 后，这次继续选择 DeepSeek。这里主要是验证 Hermes 能否正常用一个外部模型提供商，而不是测试本地大模型性能：
接着， 访问deepseek官方keys页面，进行创建一个apikey:
https://platform.deepseek.com/api_keys
复制好key后，填写到终端（粘贴不会显示）：
模型保持默认的 deepseek-chat。消息平台先选择第二项暂时跳过，这样可以先把“模型与 Hermes 本体”单独验证，不把微信配置麻烦混进来：
初始化完成提示出现后，说明基础配置已经写入。下一步直接运行 Hermes 做一次实际对话：
我们回车，运行这个hermes：
Hermes 启动以后，先用一条轻松麻烦确认它是否能正常回答，同时观察它能否识别当前运行环境和所接模型：
你好，你是谁？你当前运行在什么操作系统上，接入的是什么模型？
如下图所示：
从原文测试结果看，它可以返回当前运行在 Docker 容器中，并识别到接入的是 DeepSeek。说明“容器运行 + 模型接入 + 基础对话”这一段已经跑通。
接着输入退出指令，继续完成后面的配置：
/exit
退出后继续验证 Web 控制台。终端能聊天只是一个入口，9119 页面能否打开决定了后面远程管理是否有意义：
http://192.168.50.212:9119
如下图：
3 将Hermes接入至微信
终端和 Web 控制台都能正常使用以后，接下来验证我更关心的一点：能不能把 Hermes 从“需要专门打开页面”变成一个平时就在用的聊天入口。
原文选择的是微信，因此重新执行同一套部署脚本进入消息平台配置：
curl -fsSL https://gitee.com/jun-wan/script/raw/master/fnos-hermes/fnos-hermes.sh -o /tmp/fnos-hermes.sh && chmod +x /tmp/fnos-hermes.sh && /tmp/fnos-hermes.sh
输入6进行配置聊天平台网关:
然后会进入到如下页面，选择【WeiXin】然后回车：
接着会提示是否开始扫码登录，直接回车：
扫码连接完成后，按原文设置继续使用默认的配对审批模式，并禁用群聊消息，然后使用当前连接账号：
最后会回到消息平台选择菜单，选择【Done】退出：
接着回到菜单，选择【8】重启一下hermes服务：
服务重启后先直接给 Hermes 发一条消息，验证微信侧是否已经能触达 Agent：
此时消息已经可以触达 Hermes，但当前用户还需要完成配对审批。这个步骤说明“微信连接成功”和“用户获得使用权限”是两件事：
hermes pairing approve weixin QKHBWHAJ
回到菜单，选择选项【10】执行容器内 Hermes 原生命令：
输入审批授权的命令：
审批命令执行成功后，这个微信用户就获得了配对授权。接下来再直接发消息验证完整链路：
你好，你是谁？请你介绍一下你自己，你都能干什么？
如下图所示：
这次消息可以正常返回，说明 微信 → Hermes → DeepSeek → 微信回复 这条链已经跑通。
接着原文又用一个更具体的任务做了验证：
请你给我写一个用于旅游的好看点儿的宣传落地页
效果（DeepSeek-chat模型）：
从原文结果看，Hermes 能够继续完成这类东西生成任务。
到这里，本地部署和微信接入已经完成。对于只打算通过微信调用 Agent 的人来说，其实已经可以停下；下面继续配置公网访问，主要是为了在外面也能打开 Hermes 的 Web 控制台做查看和调整。
4 穿透 Hermes WebUI 以实现公网访问
前面的测试已经证明：Hermes 在 NAS 上能运行，DeepSeek 能对话，微信也能作为日常入口。
这时公网访问就不再是“为了让 Hermes 能用”，而是一个补充能力：人在外面时，是否还能打开 9119 Web 控制台。
如果日常只通过微信使用，公网 WebUI 并不是务必配置；如果需要远程查看状态、调整设置或临时进入控制台，再增加这一层更合理。
下面使用 cpolar把飞牛 NAS 本地的 9119 端口映射到公网。Hermes 仍然负责 Agent 和消息处理，cpolar 只负责 WebUI 的外部访问。
4.1 什么是 cpolar？
在这套结构里，cpolar 的职责很单一：把已经在局域网正常运行的 9119 Web 服务提供到外部网络。它不参与 Hermes 的模型调用，也不参与微信消息处理。
cpolar 是一款内网穿透工具，可以把局域网内运行的服务映射到公网。
轻松来说，只要服务已经在本地跑起来，比如本文中的 Hermes Web 控制台 9119 端口，就可以通过 cpolar 创建公网访问地址。这样外部设备不需要配置路由器端口转发，也能远程访问本地服务。
cpolar 支持 Windows、macOS、Linux、树莓派、群晖 NAS 等平台，也适合飞牛 NAS 这类支持 SSH 和 Docker 的设备使用。
4.2 安装 cpolar
回到 SSH 终端窗口，也就是前面连接飞牛 NAS 的终端，执行下面命令安装 cpolar：
sudo curl https://get.cpolar.sh | sh
如下图所示：
安装完成后，执行下面命令查看 cpolar 服务状态：
sudo systemctl status cpolar
如下图所示：
如果状态中显示 active (running) 就说明 cpolar 已经正常启动。
接着，在浏览器中输入下面地址，访问 cpolar 的 Web UI 控制台，比如我这里的飞牛 NAS IP 是 192.168.50.212，所以访问地址就是：
http://192.168.50.212:9200
如下图所示：
能够打开 cpolar Web UI 后，说明安装与服务状态都正常。接下来只需要把隧道指向 Hermes 的 9119 页面。
4.3 将 Hermes WebUI 映射到公网
注册好账号以后，回到该页面进行登录即可，登录成功后，进入侧边的【隧道管理>隧道列表】，可以看到有2条隧道:
选择website这条隧道，点击编辑进行修改（也可以创建新的隧道）：
创建或者更新完成后，接着点击状态>在线隧道列表，可以看到同一个隧道生成了两个公网访问地址，一个是 http，另一个是 https：
这里以https为例，访问测试一下：
公网地址能够打开 Hermes 管理界面，说明 9119 的远程访问链路已经打通。
到这里验证的是“WebUI 可以从外网访问”，微信消息链本身并不依赖这一条隧道。
5 固定二级子域名
前面的随机地址已经完成最重要的验证：Hermes WebUI 能从公网打开。
如果只是临时进入控制台，随机地址已经够用；如果准备长期保存书签或固定使用这个管理入口，再配置二级子域名更合适。原文这里继续使用固定二级子域名方案。
5.1 设置二级子域名
首先，进入官网的预留页面：
https://dashboard.cpolar.com/reserved
然后，选择预留菜单，即可看到保留二级子域名项，填写其中的地区、名称、描述（可不填）项，然后点击保留按钮，操作步骤图如下：
列表中显示了一条已保留的二级子域名记录：
- 地区：显示为China Top。
- 二级域名：显示为hermes01。
5.2 修改隧道为子域名方式
进入侧边菜单栏的【隧道管理】下的【隧道列表】，可以看到名为【hermes01】的隧道：
点击【编辑】按钮进入编辑页面，修改域名类型为【二级子域名】，然后填写前面配置好的子域名，点击更新按钮：
接着来到【状态】菜单下的【在线隧道列表】可以看到隧道名称为【hermes01】的公网地址已经变更为【二级子域名+固定域名主体及后缀】的形式了：
这里以https访问测试一下：
固定地址能够正常打开 Hermes WebUI 后，说明二级子域名已经绑定到当前隧道。
但这里也出现了一个新的边界问题：地址越稳定，越适合长期使用，也越应该考虑谁能打开这个控制台。因此下一步继续增加 HttpAuth 访问认证。
6 设置 HttpAuth 访问认证
固定公网地址解决的是“长期怎么访问”，HttpAuth 解决的是“谁可以先进入这个入口”。
它并不会改变 Hermes 自己的账号或权限体系，只是在公网 WebUI 外面增加一层基础认证。对于个人测试或远程管理场景，这种额外限制比直接把控制台裸露在固定地址上更稳妥。
6.1 配置 HttpAuth
回到 cpolar Web UI 控制台，点击左侧菜单栏的【隧道管理】→【隧道列表】，找到前面配置好的 hermes01 隧道，点击右侧的【编辑】：
在编辑页面中，展开【高级】选项，找到 HttpAuth 配置项，填写自定义的用户名和密码，格式参考如下：
admin:123456
注意，中间使用的是英文冒号 :。用户名和密码可以自定义，但不建议使用 admin:123456 这类弱密码。
如下图所示：
设置完成后，点击【更新】保存配置：
接着再次访问前面配置好的 Hermes WebUI 公网地址，就会先弹出一个认证窗口，需要输入刚才设置的用户名和密码：
认证通过后，才能继续进入 Hermes WebUI 页面。
到这里，远程访问这一层的逻辑才算完整：随机地址先验证、固定域名用于长期访问、HttpAuth 再补一层基础入口认证。
安全提醒：HttpAuth 只是基础访问认证，适合给个人测试环境增加一层保护。公网访问地址不要随意公开，密码也尽量设置复杂一些。
总结
这次在 RK3566 小主机上把 Hermes 从头跑一遍以后，我更关注的不是“NAS 多了一个 AI 功能”，而是它能不能真正变成一个常驻服务。
实际验证下来，整条链可以拆成四层：
- Hermes：负责 Agent 本身以及任务处理；
- DeepSeek：提供模型能力；
- 微信：把 Agent 变成日常消息入口；
- cpolar：只负责把
9119Web 控制台提供到外部网络。
前面先在终端里确认 Hermes 能正常运行并识别 DeepSeek，再打开 9119 Web 控制台；随后接入微信，并通过配对审批完成真实对话。到了这一步，即使不做公网穿透，Hermes 其实已经可以作为一个常驻 AI 助手使用。
公网访问属于后续管理需求。随机地址适合验证连通性，固定二级子域名适合长期保存，HttpAuth 则在固定入口外再增加一层基础认证。
对我来说，这次最大的变化不是“RK3566 变成了 AI 主机”，而是一台原本就 24 小时在线的小设备，多了一个持续运行、可以从微信随时调用的 Agent。
这类方案真正适合的，恰恰不是追求本地大模型算力的人，而是已经有 NAS、小主机或 N1 这类长期在线设备，希望把 AI Agent 变成日常服务的人。
后面如果继续扩展，重点也不应该只是“再接更多平台”，而是根据自己真正会反复使用的任务，逐步增加值得长期保留的能力。
以上就是这次整理的全部内容，希望对你有所启发。如果有不同见解，欢迎在评论区交流讨论。
评论 (0)
暂无评论