文章目录
- 每日一句正能量
- 前言
- 1 hermes-web-ui解决的不是“聊天”，而是后台不可见
- 2 Web控制台让状态更集中，但不是“展示全部内部推理”
- 3 TTS、模型和Channel确实是WebUI的重要组成部分
- 4 安装方式一：让Hermes Agent自己装
- 5 让Agent执行安装时，要把权限边界写进任务
- 6 安装完成后会返回8648和认证信息
- 7 先从局域网访问8648
- 8 当前项目仍然使用8648作为本地Web端口
- 9 当前npm包名已经出现变化
- 10 手动安装前先检查Node和npm
- 11 手动npm安装
- 12 启动WebUI
- 13 源步骤通过.token文件修改登录Token
- 14 本机访问
- 15 当前认证机制已经不只Token一种
- 16 WebUI和Hermes Agent之间还有运行时桥接
- 17 定时任务做一个实际验证
- 18 “每天8点推天气”依赖的不只是WebUI
- 19 到这里，本地使用已经够了
- 20 cpolar这一段是Mac示例，不是所有环境都照抄
- 21 Mac先检查Homebrew
- 22 安装cpolar
- 23 注册并进入cpolar管理页面
- 24 把8648映射出去
- 25 先用随机公网地址验证
- 26 公网WebUI不是普通展示页面
- 27 固定二级子域名
- 28 固定地址解决的是稳定，不是权限
- 29 这篇真正跑通的架构
- 总结
每日一句正能量
承受重量，保持体面
懂事的人，连崩溃都会选好时间。
深夜、独处、不影响他人的时刻，才敢放任情绪决堤。这不是虚伪，而是成年人为维系秩序所做的沉默牺牲。
前言
这篇完整走一遍 Hermes Agent 增加 Web 控制台的过程。源步骤提供两条路线：一条是直接把安装任务交给已经能执行终端操作的 Hermes Agent；另一条是自己检查 Node.js 和 npm，再全局安装 hermes-web-ui 并启动8648端口。
进入页面以后，继续验证对话、模型Provider、频道、TTS、插件、日志和定时任务，并用“每天早上8点推送天气”做一次执行测试。
后半部分再通过 cpolar 把8648提供给外部浏览器访问，并配置固定二级子域名。
整篇重点放在“Hermes Agent—WebUI—8648—认证—任务—远程访问”这条链路上，同时说明当前npm包名已经出现变化、Token不是新版唯一认证方式，以及公网控制台为什么必须比普通网页更谨慎。
这篇也不会只停在“页面能打开”。真正值得验证的是WebUI有没有和Hermes Agent接通：对话能不能返回、模型和Channel能不能读到、任务能不能执行、日志能不能辅助排错。只有这些都跑通，8648这个页面才算真正有用，而不是单独启动了一个前端壳子。
另外，源步骤后半段使用Mac安装cpolar，所以远程访问部分必须把主机关系说清楚。WebUI如果跑在NAS或其他服务器上，不能因为示例是Mac就机械照抄本地端口。
1 hermes-web-ui解决的不是“聊天”，而是后台不可见
Hermes Agent接到微信、飞书这类平台以后，用户通常只能看到：
消息发出去 → 最终回复回来。
中间发生了什么并不直观。
比如一次天气询问：
从聊天窗口里很难马上判断：
- 是模型响应慢；
- Tool调用慢；
- API异常；
- 网络异常；
- 还是Agent本身已经卡住。
hermes-web-ui的价值就是给这套后台流程增加一个浏览器入口。
2 Web控制台让状态更集中，但不是“展示全部内部推理”
Web控制台：
请求过程：
等待时还有界面动效：
这些功能能让：
- 会话状态；
- 流式响应；
- 部分运行信息；
- 日志；
- 配置
更容易被观察。
但更准确的说法应该是：
运行过程更可观察。
而不是：
模型全部内部思维都能被直接看到。
3 TTS、模型和Channel确实是WebUI的重要组成部分
TTS设置：
模型页面：
频道页面：
当前项目主线仍然覆盖：
- 模型与Provider；
- 多平台Channel；
- TTS / STT；
- Skills；
- Memory；
- Plugin；
- Logs；
- Scheduled Jobs。
所以它已经明显不只是一个网页聊天框。
4 安装方式一：让Hermes Agent自己装
源步骤给Agent的提示词：
请帮我在当前设备上安装 hermes-web-ui。先检查 Node.js 和 npm 是否可用，如果环境正常，就使用 npm 全局安装 hermes-web-ui。安装完成后启动 hermes-web-ui，并告诉我本地和局域网访问地址还有登录的密码是什么，并且告诉我如何修改密码。如果端口被占用，请先提示我，不要删除任何文件。
实际发送：
执行完成后：
这种方式确实很省事，但成立有一个前提：
Hermes Agent必须已经具备Shell / Terminal执行能力，而且当前权限允许安装npm全局包。
如果Agent只有聊天权限，它不会凭空完成系统安装。
5 让Agent执行安装时，要把权限边界写进任务
这段提示词里有两个地方很好：
- 端口占用先提示；
- 不要删除任何文件。
如果Agent还拥有sudo能力，更建议继续限制：
- 不修改无关服务；
- 不覆盖Hermes配置；
- 高权限命令先提示；
- 失败后停止，不自动做大范围修复。
Agent能执行命令，不等于应该无限授权。
6 安装完成后会返回8648和认证信息
结果示例：
本 地：http://localhost:8648
局域网：http://192.168.50.161:8648
登录 Token (即密码)：
[已隐藏，请使用启动时实际生成的 Token]
源稿这里包含一条完整Token。
我已经在改写稿里做了脱敏。
因为Token本质上就是访问凭据，公开文章不应该继续暴露它。
7 先从局域网访问8648
浏览器打开：
然后进入登录：
这一步证明：
浏览器 → 主机8648 → hermes-web-ui
已经正常。
如果局域网访问都失败，后面不应该先排查公网。
8 当前项目仍然使用8648作为本地Web端口
当前主线项目的CLI和环境变量里，默认端口仍然是：
8648
所以源步骤里的端口没有明显过时。
不过Docker Compose模式可能使用不同宿主机端口。
因此长期文章更适合写：
npm/CLI模式默认8648，实际以启动输出为准。
9 当前npm包名已经出现变化
源步骤手动安装使用的是：
hermes-web-ui
但当前项目最新Quick Start已经出现：
@quanthermes/hermes-web-ui
的推荐方式。
同时旧发行线仍能看到原包名。
所以真正复现时应该：
先看当前项目README，再决定安装哪个包名。
不要把某个时间点的npm名称写成永久不变。
10 手动安装前先检查Node和npm
执行：
node -v
npm -v
源步骤写Node.js 23或更高。
当前项目package配置仍然声明：
node >=23.0.0
所以这一点目前仍然有依据。
11 手动npm安装
执行：
npm install -g hermes-web-ui
这条命令按这次实操保留。
但如果今天重新部署，建议先核对当前Quick Start里实际推荐的包名。
12 启动WebUI
执行：
hermes-web-ui start
当前CLI仍然支持：
- start；
- stop；
- restart；
- status；
- update / upgrade。
启动后会在后台运行WebUI服务。
13 源步骤通过.token文件修改登录Token
执行：
echo "你的新密码" > ~/.hermes-web-ui/.token
hermes-web-ui restart
这种做法对应早期Token认证方式。
Token文件通常位于：
~/.hermes-web-ui/.token
但当前主线已经加入：
- Token认证；
- 用户名/密码；
- 管理员账户；
- 登录锁定恢复。
所以新版出现账户登录时，不应该只盯着.token文件排错。
14 本机访问
默认地址：
http://localhost:8648
局域网页面：
做到这里，两种安装方式都已经汇合到同一个结果：
8648 Web控制台能够正常打开。
15 当前认证机制已经不只Token一种
这篇截图演示的是Token登录。
但当前项目已经增加账户数据库，并支持管理员账号体系。
因此更准确的长期表述是：
不同版本可能使用Token、用户名/密码或两者并存，按启动输出和当前README配置。
如果版本存在默认管理员账号，第一次登录后应该立即修改默认凭据。
16 WebUI和Hermes Agent之间还有运行时桥接
hermes-web-ui不是一个静态页面。
它后面还负责和Hermes Agent Runtime通信。
所以：
页面打开
只说明Web服务正常。
真正聊天还要继续验证：
WebUI → Hermes Agent → Provider / Tool
这一层。
17 定时任务做一个实际验证
源步骤使用：
让 Hermes Agent 每天早上 8 点，自动给我推送当天的天气情况。
任务面板：
执行以后：
可以看到运行结果和历史。
这说明这套环境里的：
定时任务 → Hermes Agent → 已配置Channel
已经实际跑通过一次。
18 “每天8点推天气”依赖的不只是WebUI
这个任务能够成功，还需要：
- Hermes Agent本身正常；
- 微信等Channel已经接入；
- 能获取天气数据；
- 模型Provider正常；
- 调度服务正常。
所以不能理解成：
只安装hermes-web-ui就自动拥有天气推送。
WebUI负责的是任务配置和观察入口。
19 到这里，本地使用已经够了
已经验证：
- 安装；
- 8648；
- 登录；
- 对话与状态；
- 模型；
- Channel；
- TTS；
- 任务。
如果只在局域网管理Hermes Agent，到这里已经足够。
后面解决：
人在外面怎样打开8648。
20 cpolar这一段是Mac示例，不是所有环境都照抄
源步骤后面以Mac为例安装cpolar。
首先打开终端：
Mac终端：
这里必须先明确网络关系：
cpolar需要运行在能访问hermes-web-ui 8648端口的位置。
最简单的是：
WebUI和cpolar运行在同一台主机。
如果WebUI跑在NAS而cpolar装在Mac，则Mac必须能够访问NAS的8648，而且隧道目标也要按实际地址填写。
21 Mac先检查Homebrew
执行：
brew -v
如果未安装Homebrew：
# 官方安装脚本（需要良好的网络环境）
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
这一段只适用于macOS。
Linux、NAS和Windows应该使用各自对应的安装方式。
22 安装cpolar
执行：
brew tap probezy/core && brew install cpolar
安装服务：
sudo cpolar service install
启动：
sudo cpolar service start
查看版本：
cpolar version
23 注册并进入cpolar管理页面
注册：
注册页：
管理地址：
http://127.0.0.1:9200
打开：
登录：
如果cpolar运行在本机Mac：
127.0.0.1:9200
成立。
如果cpolar运行在其他机器，应使用对应设备的实际管理地址。
24 把8648映射出去
隧道列表：
编辑website隧道或者新建隧道：
核心参数：
- 名称：
hermesweb - 协议：HTTP
- 本地地址：
8648 - 地区：
China Top
前提依旧是：
cpolar和WebUI在同一台主机。
如果不是，本地地址应该根据实际网络拓扑指向WebUI主机。
25 先用随机公网地址验证
在线隧道：
使用HTTPS访问：
页面能打开以后，说明：
外部浏览器 → 公网入口 → 8648 → hermes-web-ui
网络链已经通了。
26 公网WebUI不是普通展示页面
WebUI里可能包含：
- 会话历史；
- Provider配置；
- Channel；
- Tasks；
- Logs；
- Skills；
- Memory；
- Plugin；
- 文件和运行时信息。
所以这个入口应该按照：
高权限AI管理后台
来保护。
至少做到：
- 强Token或强管理员密码；
- 不公开管理地址；
- 不在截图里展示凭据；
- 使用HTTPS；
- 定期更新；
- 不需要时关闭外部入口。
27 固定二级子域名
进入预留页面：
https://dashboard.cpolar.com/reserved
预留：
示例二级域名：
hermes01
然后回到隧道列表：
修改隧道：
更新后查看：
再用HTTPS访问：
最后登录：
这样固定入口就完成了。
28 固定地址解决的是稳定，不是权限
固定二级子域名的价值是：
- 手机好收藏；
- 浏览器不用反复换地址；
- 长期管理更方便。
但它不会自动解决：
- Token泄露；
- 默认管理员密码；
- Provider API Key；
- Channel凭据；
- WebUI自身漏洞。
固定地址只代表：
入口更稳定。
29 这篇真正跑通的架构
本地控制台：
浏览器 → 8648 → hermes-web-ui → Hermes Agent
管理：
WebUI → 模型 / Channel / Tasks / Logs / Skills
任务：
定时任务 → Hermes Agent → 已配置Channel
远程：
外部浏览器 → 公网地址 → 8648 → WebUI
真正完成：
- 两种WebUI安装方式；
- 8648访问；
- Token登录；
- 对话和状态查看；
- 模型页面；
- Channel；
- TTS；
- 定时任务；
- cpolar；
- 随机公网访问；
- 固定二级子域名。
需要特别注意：
- 当前npm包名正在演进；
- Node仍要求>=23；
- Token不是新版唯一认证方式；
- 公开稿中的真实Token必须脱敏；
- Agent自安装依赖Shell权限；
- cpolar要部署在能访问8648的位置；
- 公网WebUI属于高权限后台；
- 固定地址不等于安全。
总结
整套流程可以拆成三层：Hermes Agent负责真正的Agent能力，hermes-web-ui负责浏览器里的会话和管理，公网入口负责让外部设备访问8648。
本文已经跑通WebUI安装、认证、对话、模型、Channel、TTS、定时任务，以及随机和固定地址访问。
最需要修正的是长期维护思路：当前项目的npm安装方式和认证机制已经继续演进，不能只按旧包名和Token文件机械操作；同时源稿中的真实Token也不适合继续出现在公开文章里。
把版本、认证和网络拓扑处理清楚以后，hermes-web-ui更适合被定义成Hermes Agent的可视化运维与交互入口，而不是“把后台全部内部过程完整暴露出来”的万能监控台。
转载自：https://blog.csdn.net/u014727709/article/details/168013898
欢迎 👍点赞✍评论⭐收藏，欢迎指正
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/u014727709/article/details/168013898
