1. 写在前面：为什么我盯上了这套组合
先把话说清楚，这篇不是拿官方文档翻译一遍的流水账，而是我在真实服务器上从零部署 Rocky Linux + Hermes Agent + Hermes-Web-UI 的完整记录。如果你正在头疼这三件事：Hermes Agent 怎么在 RHEL 系发行版上跑起来、Web-UI 怎么跟 Agent 稳定对接、以及装完之后遇到会话丢失这类诡异问题怎么排查，那这篇应该能帮你省掉不少折腾时间。
先交代一下这套东西是干什么的。Hermes Agent 是一个可以独立部署的智能体运行时程序，装上之后你可以通过自然语言给它派活，它自己会拆解任务、调动工具、执行流程。而 Hermes-Web-UI 是把 Agent 能力搬到浏览器里的一层可视化面板，支持多会话管理、任务历史追溯、参数微调这些操作。两者组合起来，相当于给个人或小团队提供了一个完全自控的 AI 工作台——没有第三方平台的额度焦虑，也不存在把内部系统接口暴露给外部服务的问题，数据链路全部在自己的服务器上闭环。
我这次选择的宿主系统是 Rocky Linux 9.6，选它的理由也不复杂：RHEL 系生态在服务器领域积累深，很多企业的生产环境就是这套底子；Rocky 作为社区重建版，稳定性有保障，而且跟 CentOS 时代的运维习惯能无缝衔接。如果你手里是 Rocky 8.10 或 9.x 的其他小版本，这篇的步骤也基本通用，个别差异我会在正文里指出来。
适合看这篇的人，我大致分成三类：一是想在公司内网搭一个自托管 AI Agent 服务的运维工程师，二是对 Agent 技术感兴趣、手里刚好有一台闲置 x86 服务器想练手的开发，三是已经在用 Hermes Agent、但 Web-UI 一直配不顺、会话老是丢的苦主。无论你是哪一类，跟着下面的思路走一遍，应该都能得到一个能稳定跑起来的组合环境。
2. 部署前的全局规划：别急着敲命令，先把架构想明白
2.1 这套系统的核心链路
很多人装这类服务喜欢拿到安装包就往下冲，结果装到一半发现端口冲突、依赖缺包、目录权限乱七八糟，最后只能推倒重来。我的习惯是先把整个系统的调用链路画在脑子里，再动手。
这一套组合的典型链路是这样的：外部浏览器访问 Hermes-Web-UI 的 8082 端口，UI 服务本身负责跟用户交互、渲染会话界面。当你在对话框里提交任务，UI 后端的逻辑层会把任务封装成请求，转发给真正干活的 Hermes Agent 进程。Agent 收到任务之后开始拆解规划，需要外部知识库或模型能力时就调用大模型接口（这个可以配置成本地 Ollama 服务，也可以是云端兼容 API），需要联网或操作内部系统时就调用内置工具。最后 Agent 把执行结果回传给 Web-UI，UI 再把整个思考过程、工具调用记录、最终结论展示在浏览器里。
搞明白这条链路之后，你会发现有几个关键的决策点必须在部署前就定下来。
2.2 架构决策：单机一体还是分离部署
第一个决策点是组件部署形态。如果只是自己用、或者给一个十人以内的小团队用，我强烈建议单机一体部署，也就是 UI、Agent、配套数据库全部装在同一台 Rocky Linux 上。理由有三点：第一是运维成本低，升级、重启、看日志都是一台机器上的事，不用 SSH 到三四台机器上分别操作；第二是网络问题少，组件之间走 127.0.0.1 回环地址通信，既没有跨主机防火墙拦截风险，也没有延迟抖动；第三是资源利用率高，这套系统的性能瓶颈通常在 Agent 任务执行阶段，Web-UI 层本身吃资源不多，没必要单独给它开一台机器。
如果是几十人同时使用或者在跑生产级自动化任务，再考虑把 Agent 单独拆到一台性能更强的机器上，UI 保持独立。但这是后话了，新部署的同学先按单机来。
2.3 网络规划：固定 IP、防火墙与端口这些事
单机部署最容易被忽略的就是网络规划。服务器不像你的笔记本，IP 地址随时可能因为 DHCP 租约到期而变动。一旦 IP 变了，Web-UI 的对外访问地址就失效了，Agent 回调地址也得跟着改，到时候排查起来非常痛苦。所以我给 Rocky Linux 安装系统的第一步永远是配置静态 IP，具体操作后面章节会写。
端口方面，需要留意三组：Hermes-Web-UI 默认监听 8082 端口用于浏览器访问；Hermes Agent 的 API 服务默认监听 8081 端口，这是 Web-UI 与 Agent 通信的通道；如果你还要用 Ollama 跑本地大模型，它默认是 11434 端口。这三个端口加上 SSH 的 22 端口，就是一台完整服务需要的全部对外通道。用 firewalld 管理的话，一条规则把 8081、8082 放行即可，11434 如果只在本机调用就不用暴露到外网。
2.4 数据安全准备：密钥存放与备份意识
这套系统涉及两类敏感数据：一是调用大模型 API 时的密钥（无论是云端服务商的还是本地 Ollama 的），二是 Web-UI 里的会话记录、任务日志、用户配置信息。前者的保护方式是配置文件的权限收敛，我后面会给出标准做法；后者的保护方式是部署前就规划好数据目录的备份策略。Web-UI 内部使用 SQLite 或类 SQLite 的轻量库存储会话数据，这意味着备份的时候只需要物理拷贝几个数据文件就能完成整个状态的存档。
我见过太多人用了一段时间 Web-UI 之后突然会话全部丢失，排查半天发现是因为数据目录写在系统临时分区里，一次重启就全没了——这种坑完全可以在规划阶段就避开。
3. 实操前奏：Rocky Linux 系统层面的硬准备
3.1 系统安装与静态 IP 配置实操
如果你装系统的时候网络用的 DHCP，装完第一件事就是改成静态 IP。Rocky Linux 9.6 的网络管理默认使用 NetworkManager，推荐用 nmcli 命令行来改，既适合本地操作也适合通过 SSH 远程修改。
先查看当前连接的网卡名称：
nmcli connection show一般服务器上会有一个名为 ens160 或 ens3 之类的连接，记下它的 NAME。然后执行：
sudo nmcli connection mod ens160 \ ipv4.method manual \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns "223.5.5.5 8.8.8.8"这里 192.168.1.100 换成你实际的规划 IP，网关和 DNS 按你们机房的规范来。改完之后重启连接：
sudo nmcli connection down ens160 && sudo nmcli connection up ens160用ip addr show ens160确认 IP 已经生效。这里特别提醒一句：如果你是远程 SSH 操作，改 IP 之前先把新地址记清楚，一旦连接断开就用新 IP 重新连，别慌。另外，用 nmcli 修改时如果网卡连接名带空格或特殊字符，记得用引号包起来。
3.2 阿里云镜像源替换：解决 Rocky Linux 更新慢或源失效
系统装好后第一件事就是配置 yum 源。Rocky Linux 9.6 内置的源指向官方服务器，在国内网络环境下速度经常惨不忍睹，而且 8.10 这类老版本如果不及时处理，官方源可能已经进入 archive 状态，不换源的话yum install会直接报 404。解决方案是用阿里云的镜像源替换。
先备份原有源配置：
sudo mkdir -p /etc/yum.repos.d/backup sudo mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/然后写新的源配置文件。以 Rocky 9 为例，创建一个/etc/yum.repos.d/rocky-aliyun.repo：
[base] name=RockyLinux-$releasever-Base baseurl=https://mirrors.aliyun.com/rockylinux/$releasever/BaseOS/$basearch/os/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9 [extras] name=RockyLinux-$releasever-Extras baseurl=https://mirrors.aliyun.com/rockylinux/$releasever/extras/$basearch/os/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9 [appstream] name=RockyLinux-$releasever-AppStream baseurl=https://mirrors.aliyun.com/rockylinux/$releasever/AppStream/$basearch/os/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9 [epel] name=EPEL for Rocky Linux $releasever baseurl=https://mirrors.aliyun.com/epel/$releasever/Everything/$basearch/ gpgcheck=0 enabled=1如果你是 Rocky 8.10，把 URL 里的$releasever对应的仓库路径替换成 8.10 即可，结构一样。写完源之后执行：
sudo dnf clean all sudo dnf makecache实测换完阿里云源之后，dnf 安装软件的速度会有一个数量级的提升。
3.3 常规依赖与时间同步
这套系统里 Agent 任务调度对时间比较敏感，时钟漂移可能会导致任务记录时间错乱、证书校验失败。安装完系统后顺手把 chrony 时间同步搞定：
sudo dnf install -y chrony sudo systemctl enable --now chronyd timedatectl set-timezone Asia/Shanghai然后安装后面会用到的常规依赖包：
sudo dnf install -y tar gzip curl wget git python3 python3-pip firewalld这里面 python3 和 pip 是 Hermes 系列组件很多脚本的运行时依赖，tar 和 gzip 用于解压安装包。如果你计划用 Docker 方式跑 Web-UI，还需要：
sudo dnf install -y yum-utils sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo sudo dnf install -y docker-ce docker-ce-cli containerd.io sudo systemctl enable --now docker我个人建议能直接用进程方式跑的就别绕一层 Docker，少一个中间层就少一类问题。
3.4 SELinux 与防火墙的前置处置
Rocky Linux 默认开启 SELinux，运行策略是 enforcing。Hermes Agent 和 Web-UI 不是为 SELinux 专门适配过的程序，在某些操作场景下（比如 Agent 尝试读取用户目录下的配置文件并写入日志）可能被 SELinux 拦截，报错还不直观。很多新手在这里卡到怀疑人生。
我的处理建议是分两步走：先给可能涉及到的目录打上兼容标签，如果还是有问题就临时把 SELinux 设为 permissive 观察。不建议直接永久关闭，毕竟服务器安全还是很重要的。临时代命令：
sudo setenforce permissive想永久放宽的话编辑/etc/selinux/config把SELINUX=enforcing改成SELINUX=permissive，然后重启系统。等你确认这套服务完全正常之后再考虑要不要收紧回来。
防火墙这边我习惯先把 8081、8082 放行：
sudo systemctl enable --now firewalld sudo firewall-cmd --permanent --add-port=8081/tcp sudo firewall-cmd --permanent --add-port=8082/tcp sudo firewall-cmd --reload注意：如果端口有冲突需要改默认配置，记得先改配置文件再放行新端口，顺序反了会造成端口明明是通的但服务连不上这种诡异情况。
4. Hermes Agent 安装全流程：从下载到后台运行
4.1 安装前的关键选型：源码、脚本还是容器
Hermes Agent 的安装方式大致有几种：官方提供的安装脚本、下载预编译二进制包、通过容器镜像跑。搜索引擎里很多人问“hermes agent 安装要登录网站怎么回事”，我推测是下载安装引导脚本时访问的托管站点做了访问控制或需要交互确认。这种事很正常，开源项目经常会在下载页加一道 GitHub Release 跳转或人机验证，并不是你的服务器出了问题。
如果你在下载安装脚本时卡住，我个人实测最稳的路线是：直接用 wget 去拉 GitHub Release 里的预编译包，绕过交互脚本。这需要你先在官方 Release 页面确认最新版本号，然后在服务器上执行：
sudo dnf install -y tar cd /opt sudo wget https://github.com/your-hermes-repo/hermes-agent/releases/download/v1.x.x/hermes-agent-linux-amd64.tar.gz这里把路径替换成你看到的实际地址。如果服务器访问 GitHub 慢或者超时，可以先在本地下载好了再 scp 传上去。这不是什么丢人的操作，反而是生产环境常见的离线部署方式，省时省力。
4.2 目录规划与安装执行
安装到哪个目录是有讲究的。我强烈建议统一装在/opt/hermes下，把 Agent 程序、配置、日志、数据分开存，方便后续备份和管理：
sudo mkdir -p /opt/hermes/{bin,config,data,logs} sudo tar -xzf hermes-agent-linux-amd64.tar.gz -C /opt/hermes/bin/解压之后检查一下目录结构：
ls -la /opt/hermes/bin正常情况下会出现几个可执行文件。接着把主程序加入环境变量方便手动调试：
echo 'export PATH=/opt/hermes/bin:$PATH' | sudo tee /etc/profile.d/hermes.sh source /etc/profile.d/hermes.sh4.3 配置文件生成与核心参数释义
首次运行 Hermes Agent 之前需要生成配置文件。不同版本的配置项写法会有差异，但核心参数大致包括：监听地址、监听端口、模型服务地址、API 密钥、数据存储路径等。
一个典型的初始化命令可能是：
cd /opt/hermes /opt/hermes/bin/hermes-agent --init执行后会在当前目录或者 config 目录生成一份配置文件。找不到的话搜一下：
find /opt/hermes -name "*.yaml" -o -name "*.yml" -o -name "*.toml" 2>/dev/null配置文件的主要内容会包含这样一个骨架（以 YAML 为例）：
server: host: "127.0.0.1" port: 8081 model: provider: "openai-compatible" api_base: "http://127.0.0.1:11434/v1" api_key: "ollama" model_name: "qwen2.5:14b" storage: type: "sqlite" path: "/opt/hermes/data/agent.db" log: level: "info" output: "/opt/hermes/logs/agent.log"这里面的几个决策点我说一下思路：
- 监听地址设置成 127.0.0.1 说明只在本地接受请求，安全；如果你的 Web-UI 跑在另一台机器上，就改成 0.0.0.0 并配合防火墙做访问控制。
- 模型服务这里我配的是本地 Ollama 地址，这是最省事也最可控的选择。如果你打算接云端服务，就把 api_base 换成服务商地址并填写真实的 api_key。
- storage 配置成 sqlite 文件存储，存放在 /opt/hermes/data 目录下，这样备份只需要拷贝这个文件。
配置文件改好后，建议设置严格的权限：
sudo chown -R root:hermes /opt/hermes/config sudo chmod 640 /opt/hermes/config/config.yamlapi_key 这种东西明文躺在配置文件里，如果权限是 777 那等于给整台机器开了门。640 权限意味着只有属主和属组能读，其他用户一概不能碰。
4.4 用 systemd 守护 Agent 进程
直接命令行前台运行 Agent 不是不行，但服务器一重启进程就没了，还得手动拉起来，太原始。用 systemd 把它注册成系统服务才是正经做法。创建/etc/systemd/system/hermes-agent.service：
[Unit] Description=Hermes Agent Service After=network-online.target Wants=network-online.target [Service] Type=simple User=hermes Group=hermes WorkingDirectory=/opt/hermes ExecStart=/opt/hermes/bin/hermes-agent --config /opt/hermes/config/config.yaml Restart=on-failure RestartSec=10 Environment="HOME=/opt/hermes" [Install] WantedBy=multi-user.target注意我在服务配置里指定了一个专门的用户 hermes。强烈建议不要用 root 身份跑 Agent，原因有两个：安全上，Agent 有权限执行各种工具，被攻破后如果它是 root 身份后果不堪设想；运维上，Agent 生成的文件如果都归 root，后续排查日志和备份会有很多权限麻烦。创建用户的命令：
sudo useradd -r -s /sbin/nologin hermes sudo chown -R hermes:hermes /opt/hermes开机自启与启动：
sudo systemctl daemon-reload sudo systemctl enable --now hermes-agent sudo systemctl status hermes-agent如果状态是 active (running)，说明 Agent 已经在后台稳定运行了。用journalctl -u hermes-agent -f可以实时看它的日志输出。
4.5 验证 Agent 工作状态
Agent 启动后怎么确认它是真活着而不是僵尸进程？最直接的方式是调用它的健康检查接口：
curl http://127.0.0.1:8081/health返回 JSON 里面包含 status ok 之类的字样基本就没问题了。如果 health 接口不存在，那就看日志里的启动完成标志，或者尝试用 Agent 对应的命令行工具跑一个最简单的任务：
/opt/hermes/bin/hermes-cli run "你好，请回复收到"能收到回复就说明 Agent 的核心链路是通的，模型服务、路由、日志都没问题。
5. Hermes-Web-UI 部署：给 Agent 配上可视化控制台
5.1 为什么需要 UI 层，以及常见的部署形态
Agent 跑起来之后你可能会问：既然命令行能操作，为什么还要装一个 Web-UI？答案是：命令行只适合单次问答或调试，当你需要管理多个历史会话、对比不同参数的执行效果、查看工具调用的完整链路时，UI 的价值就体现出来了。而且团队协作场景中，UI 意味着其他人不需要学会命令行就能使用这套 Agent 能力。
Hermes-Web-UI 在部署形态上有两种主流选择：直接跑预编译二进制包，或者用 Docker 容器。二进制的优势是少一层虚拟化，资源占用小，故障链路短，适合追求可控性的玩家。Docker 的优势是环境和依赖被打包好了，升级时直接换镜像。我这次的部署用的是二进制方式，因为做这套组合部署的人大多对服务器有较强的掌控欲，而且把数据文件映射出容器再处理权限问题也挺烦的。
5.2 下载并初始化 Web-UI
和 Agent 的安装一样，先从官方 Release 渠道获取 Hermes-Web-UI 的 Linux 二进制包，放进/opt/hermes-web目录：
sudo mkdir -p /opt/hermes-web cd /opt/hermes-web sudo wget https://github.com/your-hermes-repo/hermes-web-ui/releases/download/v1.x.x/hermes-web-linux-amd64.tar.gz sudo tar -xzf hermes-web-linux-amd64.tar.gz -C /opt/hermes-web首次运行之前先看看有没有初始化命令：
cd /opt/hermes-web sudo ./hermes-web --init有的话会在当前目录生成默认配置。如果没有 --init 参数，就直接运行一次让它自动生成默认配置。默认情况下它会监听 8082 端口。如果服务器上 8082 已经被别的服务占用，需要在配置里改掉。我找了个端口查看的方法：
sudo ss -tlnp | grep 80825.3 核心配置：Agent API 对接与会话存储路径
Web-UI 最关键的配置是 Agent 的 API 地址。打开生成的配置文件，找到类似于 backend、api_base 的字段，把它指到 Hermes Agent 的地址：
agent: base_url: "http://127.0.0.1:8081" api_key: "your-agent-api-key"如果你没给 Agent 设置 api_key，这里就留空。另外注意 UI 的会话数据目录默认可能指向用户主目录，生产环境建议指定到数据盘或独立目录下，比如/opt/hermes-web/data：
server: port: 8082 host: "0.0.0.0" storage: data_dir: "/opt/hermes-web/data"重要提示：一定不要把 data_dir 指向
/tmp或/var/tmp，否则系统一清理临时文件你的全部会话记录就没了。搜索热词里"我的 hermes-web-ui 的会话老是丢失"十有八九就是这个原因。
5.4 以服务方式注册 Web-UI
同样给 Web-UI 创建一个独立的运行用户，然后注册 systemd 服务：
sudo useradd -r -s /sbin/nologin hermes-web sudo chown -R hermes-web:hermes-web /opt/hermes-web创建/etc/systemd/system/hermes-web.service：
[Unit] Description=Hermes Web UI Service After=hermes-agent.service Wants=hermes-agent.service [Service] Type=simple User=hermes-web Group=hermes-web WorkingDirectory=/opt/hermes-web ExecStart=/opt/hermes-web/hermes-web --config /opt/hermes-web/config.yaml Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target启动并设置开机自启：
sudo systemctl daemon-reload sudo systemctl enable --now hermes-web sudo systemctl status hermes-web现在打开浏览器，访问http://你的服务器IP:8082，应该能看到 Web-UI 的登录或设置界面了。首次使用可能会要求填一次 Agent API 地址和模型参数，按上面配置文件里的内容填好就行。
6. 接入本地模型：让 Ollama 成为 Hermes 的推理引擎
6.1 Ollama 安装与配置
Hermes Agent 本身不包含推理能力，它需要对接一个大模型作为大脑。选型的时候我有两个方向：接云端大模型 API 或者本地部署 Ollama。考虑到很多人在意的隐私可控和长期成本问题，本文重点讲本地 Ollama 方案，顺便提一句云端方案就是改一下 api_base 的事。
Ollama 在 Rocky Linux 上的安装很简单：
curl -fsSL https://ollama.com/install.sh | sh sudo systemctl enable --now ollama安装完成后默认监听 127.0.0.1:11434。如果你想在 Agent 配置里访问它，先确认服务正常：
curl http://127.0.0.1:11434/api/tags能返回模型列表 JSON 就正常。接下来下载一个可用的对话模型：
ollama pull qwen2.5:14b注意 14b 模型跑起来大概需要 12GB 内存以上，如果你的服务器内存小于 16GB，建议换qwen2.5:7b或者qwen2.5:3b。这不是越强越好，而是得能稳定跑起来、响应速度可接受才行。
6.2 在 Hermes Agent 中配置模型服务
回到 Hermes Agent 的配置文件，把 model 段的 api_base 指向 Ollama：
model: provider: "ollama" api_base: "http://127.0.0.1:11434" model_name: "qwen2.5:14b"重启 Agent：
sudo systemctl restart hermes-agent然后到 Web-UI 里实测一下，在对话框中输入“你好，帮我写一份 Rocky Linux 安装 Python 3.12 的操作步骤”，看看能不能完整输出。这里提醒一句：第一次调用模型可能有点慢，因为模型需要加载到内存，后续就快了。
6.3 Agent 任务执行链路自测
装完 UI、Agent、模型三件套，必须做一个端到端的分步验证，确保链路是通的。我在每次部署完都会跑这样一套诊断顺序：
- 验证 Ollama 模型正常：
ollama run qwen2.5:14b "ping"，能响应说明模型没问题。 - 验证 Agent 能调用模型：命令行执行
hermes-cli run "ping"，能回复说明 Agent 的核心路由正常。 - 验证 UI 到 Agent 的通路：浏览器里发一条消息，能回复说明整个数据链路已经打通。
- 验证 UI 的会话记录：发完消息后刷新页面，看历史消息是否仍然存在。
这条链路如果一次性通过，恭喜，整套环境已经可以日常使用了。
7. 常见问题排查与避坑实录
7.1 Web-UI 会话频繁丢失：先查数据目录，再查服务权限
这是我看到搜索热词里出现频次最高的问题。会话丢失的现场通常是这样的：明明上一次的对话还在，重启了一下服务或者隔了一天再打开，所有历史会话全部不见了，就像失忆一样。
排查路径按照以下顺序来：先确认 Web-UI 配置的数据目录指向哪里，如果指向/tmp、当前用户主目录或者容器内匿名卷，那么进程重启后数据落在临时空间或无法持久化，丢会话就是必然的。解决办法是把数据目录指向/opt/hermes-web/data这种持久化路径，并且创建目录时要确保运行 Web-UI 的用户对这个目录有写权限。
还有一种情况是权限问题导致的假性丢失：你明明配置了正确的数据目录，但运行用户没有写权限，Web-UI 初始化一个空的内存数据库顶上，一重启就回归初始状态。遇到这种情况，用ls -ld /opt/hermes-web/data看一下目录权限，确保属主是 hermes-web 用户。再往深处排查可以看日志，如果日志里出现 permission denied 或 database disk image is malformed 之类的报错，基本都是权限或者磁盘问题。
7.2 Agent 安装时"要登录网站"是怎么回事
很多人在安装 Hermes Agent 时会遇到安装脚本中途要求登录某个网站，然后进度就卡住不动了。据我推测，官方脚本可能是从某个带访问控制的发布平台拉取资源，触发验证机制后脚本并不知道如何继续。
应对方案很粗暴但高效：不要用安装脚本，直接去 GitHub Release 页手动下载对应的 linux-amd64 压缩包，上传到服务器自己解压、自己写配置、自己注册 systemd 服务。整个流程虽然多敲几条命令，但每一步都是可控的，比卡在脚本里干瞪眼强多了。另一个经验是尽量避免在代理网络里运行安装脚本，它涉及多个外部跳转，代理环境下极其容易卡住。
7.3 桌面版安装报错：识别出这不是同一回事
搜索热词里还有"hermes agent 桌面版安装报错"和"hermes agent 桌面"这种说法，很可能有人在 Windows 上试图安装一个带图形界面的桌面版客户端。这跟我们在 Rocky Linux 服务器上部署的服务端 Agent 不是同一个东西，报错内容大概率也不具备参考价值。如果你是想在本地 Windows 上找桌面 GUI 程序来连接服务器上已经跑起来的 Agent，那应该去看官方文档里关于远程客户端或本地前端的部分，而不是在服务器上硬找桌面版安装包。
7.4 Rocky Linux 8.10 yum 源失效
Rocky 8 的生命周期进入末期后，官方把仓库迁移到 vault 归档，直接按照原来的 mirrorlist 拉包就会失败。解决办法很简单：将 repo 文件里的 baseurl 替换为阿里云提供的 8.10 vault 地址，格式是https://mirrors.aliyun.com/rockylinux-vault/8.10/...，具体目录结构看一眼浏览器就能明白。这段折腾完，dnf makecache就能正常通过。
7.5 一台机器上跑 Ubuntu 容器字节码的杂音
搜索热词里出现"用一个升级包，让 rocky linux 跑进 ubuntu 服务器"这种说法，大概率是某种跨发行版兼容或容器方案的讨论。我要提醒一句：Rocky Linux 和 Ubuntu 的发行版底座、内核配置、glibc 版本都不一样，别轻信用一个包就能打通所有兼容性。Hermes Agent 这类程序建议严格按照目标发行版的二进制版本安装，图省事去拿 Ubuntu 的包在 Rocky 上跑，遇到段错误和动态链接库缺失只是时间问题。
7.6 进程活着但 Web-UI 连不上 Agent
这种问题其实是最磨人的。明明systemctl status hermes-agent显示 active，但 Web-UI 里一直提示无法连接 Agent 后端。我的排查步骤是：先在服务器本机curl http://127.0.0.1:8081/health，如果通，说明 Agent 本身没问题，问题在 Web-UI 到 Agent 的网络路径上；接着看 Web-UI 的配置里 agent base_url 是否写成了127.0.0.1，如果 Web-UI 跑在同一台机器上没问题，如果是容器方式跑就要改成宿主机 IP 或 docker 网关地址；最后确认防火墙放行了 8081 端口——我吃过一次亏，firewalld 放行了 8082 忘了 8081，本地 curl 通，但 UI 一转发就超时。
7.7 单用户模式与维护场景
搜索热词里有"rocky linux 如何进入单用户模式"，虽然这不算日常操作，但如果你改了配置导致 Agent 服务崩溃、甚至系统启动异常，单用户模式就是最后的救星。在 GRUB 启动界面按 e 编辑内核启动参数，在 linux 那一行末尾加上single或rd.break，按 Ctrl+X 启动就能进入维护模式。单用户模式下可以修复配置、重置密码、矫正错误的服务设置。这套技能平时用不到，但关键时刻能省下重装系统的代价。
8. 稳定运行三板斧：权限、日志与备份
8.1 配置文件与密钥的权限收敛
不管 Agent 还是 Web-UI，配置文件里都包含模型 API 的访问凭据。我上线之前习惯做一次全局巡检：
sudo find /opt/hermes -type f -name "*.yaml" -o -name "*.toml" | xargs ls -l发现权限超过 640 的一律改掉：
sudo chmod 640 /opt/hermes/config/config.yaml sudo restorecon -Rv /opt/hermes 2>/dev/nullrestorecon 那步是把 SELinux 上下文修正一下，避免因为文件标签不对导致进程读取被拒。
8.2 systemd 服务日志的有效使用
这两个服务我都开了 systemd journal 日志记录，排查问题时这是第一手资料。常用命令收藏好：
journalctl -u hermes-agent -n 100 --no-pager journalctl -u hermes-web -n 100 --no-pager如果有追踪实时输出的需求：
journalctl -u hermes-agent -f在 systemd 服务文件里我加了Restart=on-failure，进程意外崩溃时最多 10 秒后就自动拉起，对无人值守的服务器很友好。注意如果连续崩溃，systemd 会进入 start-limit 状态不再重启，这时候用systemctl reset-failed hermes-agent重置计数并手动排查原因。
8.3 一套最简单可靠的备份策略
整套系统中需要备份的数据并不复杂，就三样：Hermes Agent 的数据文件（对应它的会话记录和任务历史）、Hermes-Web-UI 的数据目录、两个服务的配置文件。写一个简单的 cron 定时任务：
sudo mkdir -p /backup/hermes sudo tee /usr/local/bin/backup-hermes.sh <<'EOF' #!/bin/bash TS=$(date +%Y%m%d%H%M) tar czf /backup/hermes/agent-data-$TS.tar.gz -C /opt/hermes data config 2>/dev/null tar czf /backup/hermes/web-data-$TS.tar.gz -C /opt/hermes-web data config 2>/dev/null find /backup/hermes -name "*.tar.gz" -mtime +7 -exec rm -f {} \; EOF sudo chmod +x /usr/local/bin/backup-hermes.sh echo "0 3 * * * root /usr/local/bin/backup-hermes.sh" | sudo tee -a /etc/crontab每天凌晨 3 点打包一次，保留 7 天，恢复的时候解压覆盖对应目录再重启服务就行。这套方案不华丽，但真实场景下绝对够用。
9. 写在最后：这套组合的运维心法
把整套流程走完，回到最开始的问题：在 Rocky Linux 上部署 Hermes Agent 和 Hermes-Web-UI，到底难不难？我的结论是不难，但非常考验对细节的耐心。整个过程踩过的坑，归纳起来就是三句话：
第一，系统层面先搞定网络和源，静态 IP 配好、仓库换到国内镜像、SELinux 和防火墙规则理顺，后续所有安装都是顺水推舟；第二，应用层务必将配置、数据、日志目录分离，无论是 Agent 还是 Web-UI，都用独立用户和 systemd 托管，不图省事用 root 跑，也不让进程裸奔在终端里；第三，数据层的战线得拉长到备份，会话状态、任务记录、配置文件这几样东西，定期打包到一个安全位置。
我自己的体会是，这套环境跑起来之后，最值钱的不是终于有了一个自托管的 Agent 对话界面，而是它把"AI 能力接入内部系统"这扇门彻底打开了——后端的 Agent 可以通过工具扩展去读数据库、调接口、操作内部运维平台，Web-UI 只是这整套能力的一个前台入口而已。所以如果你装完 UI 之后只是拿它闲聊，那属实有点暴殄天物。建议下一步试着给 Agent 配置一两个自定义工具，让它能帮你查日志、统计服务器指标、甚至自动发消息通知。等到那一步你会感受到，这整套东西真正的主菜不是安装本身，而是 Agent 和你的系统之间那层可以无限扩展的自动化边界。
最后再分享一个操作习惯：每次改动配置之前，先把配置文件复制一份带日期的备份；每次升级前，先看 Release Notes 里有没有破坏性变更。这个习惯保我在各种开源软件升级里少踩了至少一半的坑。Rocky Linux 本身就是以稳定为卖点的系统，配合敬畏变更的使用习惯，Hermes Agent 和 Web-UI 在这台服务器上安安稳稳跑上一年半载是完全可预期的。
