ranl's website

新闻

在云服务器上部署 Hermes，并接入 Telegram：Bot 没反应，到底卡在哪一层？

从 Hermes 终端安装到 Telegram 实际对话，记录网络出口、用户权限、数字 ID 白名单和重复网关服务的排查过程。

约 8 分钟读完 工程实践HermesTelegram个人助理部署

我想要的个人助理，是能随时打开 Telegram 发消息，而不是每次先给电脑开机、启动程序，再连接终端。

所以这次先把 Hermes Agent 装到云服务器上，再接入模型服务，最后把 Telegram 作为聊天入口。

实际做下来，安装程序只是第一步。网络出口、模型认证、用户权限和后台进程，每一层都可能让人遇到同一个现象：Bot 没反应。

这篇记录的是这次实际遇到的问题。版本和路径沿用本次部署，不把它当成适用于所有 Hermes 版本的一键安装教程。

1. 先把终端版跑起来，暂时不追求所有界面

这次安装的是官方稳定版 Hermes Agent v0.22.2，使用传统 Python CLI。服务器是 Alibaba Cloud Linux 3，x86_64，运行时选用了 Python 3.14.7。本次使用的官方版本

我一开始的需求只是终端使用，因此没有继续构建 Web、桌面界面和 Node TUI，也没有把浏览器自动化等可选组件一并装上。

对于这台约 4GB 内存的服务器，先把当前需要的链路跑通，比一次把所有入口都搭起来更容易定位问题。

Hermes 使用独立的普通用户运行，没有给它 root、sudo 或 Docker 管理权限。这样它和服务器上的 AgentMall 也有了基本的权限边界。

2. 同样是 Linux，也要看架构、系统库和安装缓存

本机准备文件、再上传服务器时，遇到了两类很容易被忽略的差异。

第一类是运行平台。目标不仅是“Linux”，还包括 x86_64、系统库兼容性和具体 Python 版本。安装缓存需要按目标环境准备，不能直接拿本机环境凑出来的依赖替代。

第二类是 macOS 打包时混进来的元数据。

从 Mac 准备源码和缓存归档后，出现过 ._ 开头的 AppleDouble 文件。这些文件进入 Git 或依赖缓存目录，会干扰对目录结构的判断，例如让原本不应该被识别为索引或缓存条目的东西被扫描到。

这次处理时，对确认属于 Mac 元数据的文件做了清理，再继续校验安装。后续从 Mac 打包时，可以用 COPYFILE_DISABLE=1 减少这类附带文件；PAX 扩展头等问题仍需根据所用的打包工具检查。

我没有把“所有 ._ 文件都删掉”当成可以对整台机器执行的通用操作。先确认生成来源和清理范围，比直接套一条批量删除命令稳妥。

3. 一个短横线，也能把问题带偏

安装后我试过这样启动：

hermes -cli

结果出现了一个很奇怪的提示：

No session found matching 'li'.

这次并不是安装损坏，而是命令写法不对。在当前安装版本里，明确进入 CLI 使用的是两个短横线：

hermes --cli

遇到这种和预期完全不相干的报错，先检查参数，再去查依赖，会省下不少时间。

我也把版本、帮助命令、诊断命令和真正打开终端界面分开验证。能打印版本号，只能说明入口能运行，还不能证明模型已经接通。

4. 先区分：程序装好了，还是模型登录成功了？

最初我想连接 ChatGPT，但服务器上的设备授权请求返回了 403：

Device code request returned status 403.

当时服务器访问相关服务也有网络问题。结合这些现象，网络出口是需要排查的方向，但不能只凭一个 403 就确定唯一原因，更不能把它直接等同于账号有问题。

因为授权没有成功，终端虽然已经出现 Hermes 欢迎界面，发送消息时仍然提示没有已认证的模型服务。

后面我先改用 DeepSeek，在服务器里私下完成模型配置，没有把 API Key 发到聊天或提交到仓库。

这次最终完成验收的是 DeepSeek 加 Telegram 的对话链路。ChatGPT 授权没有在这次验收中完成，不能因为后面 Telegram 网络通了，就顺带认定 ChatGPT 也已经可用。

5. Mac 能访问 Telegram，不代表服务器也能访问

配置 Telegram 前，先在服务器测试了：

curl -I --connect-timeout 10 --max-time 15 https://api.telegram.org

结果是连接超时。

这说明即使 Bot Token 完全正确，服务器也可能到不了 Telegram API。继续反复配置 Token，解决不了这一层问题。

我平时在 Mac 上使用 Clash 类客户端，但 Mac 的网络环境不会自动延伸到云服务器。尤其要注意，服务器上的 127.0.0.1 指向服务器自身，不是我的 Mac。

这次的方案是在服务器上安装 Mihomo，并私下导入已有的网络出口配置。可以把它理解为把相应的代理内核部署到了服务器上；它和 Mac 上带图形界面的客户端，仍然是两个独立运行的程序。

代理入口和控制接口都只绑定服务器本机，没有开放到公网，也没有为了这件事开启 TUN 或改动整台服务器的默认路由。Mihomo 本机监听相关配置

导入订阅后，43 个节点加载成功，经代理访问 Telegram 得到了 HTTPS 302。重启代理服务后再次检查，结果仍然正常。

但这个 302 只说明请求得到了响应。Bot Token 是否有效，还要通过 Bot API 身份验证；能否处理聊天，还要继续往后测。

6. 订阅链接和代理地址，是两种东西

配置过程中，我还把这两个概念混在了一起：

内容 作用
Clash/Mihomo 订阅链接 提供节点配置，交给 Mihomo 导入
本机代理地址 给 Hermes 等应用使用，例如 http://127.0.0.1:17890

订阅链接不应该直接填进应用的 HTTP 代理变量里；Mac 上的本机代理地址，也不能直接当作服务器上的代理地址。

这次为部署写了私密配置辅助工具，让订阅通过隐藏输入进入服务器配置，再由应用连接本机代理。这些辅助命令是本次项目自己的工具，不是 Hermes 官方默认就存在的命令。

终端会话和后台服务的环境也要分别确认。只在当前 shell 中设置变量，不能据此认定 systemd 启动的网关一定会继承。

所以这次同时检查了 Hermes 的终端环境和网关使用的代理配置，并保留原有模型密钥。

7. root 和 hermes 用户下的 ~，不是同一个目录

网络配置好后，我在 root 终端执行过：

source ~/.hermes/network.env

结果报错，说文件不存在。

配置文件实际上放在 /home/hermes/.hermes/ 下，而 root 用户的 ~ 指向 /root。路径展开没有出错，是我用错了用户上下文。

这次正确的终端使用顺序是：

su - hermes
source ~/.hermes/network.env
hermes --cli

后面还出现了另一个权限问题：Hermes 无法在自己的 .local 下创建状态目录。检查后发现父目录的所有权不合适，于是修复所属用户并创建了对应状态目录。

这类问题没有通过 chmod 777 处理，也没有把整个助理切成 root 运行。先查清具体目录和运行用户，再修改对应权限。

8. Bot 已连接，消息却被自己的白名单拦住了

Telegram Token 配好后，身份验证通过，网关状态也显示连接成功。但我发“你好”，仍然没有回复。

最后发现，允许用户列表里填的是用户名。Hermes 这里需要的是 Telegram 的数字用户 ID。本次版本的 Telegram 配置说明

这几个字段看起来都和“账号”有关，实际用途不同：

字段 用途
Bot Token 让网关以这个 Bot 的身份连接 Telegram
个人数字用户 ID 用于确认谁可以和助理交互
Home Channel 接收主动通知、定时任务结果等内容的目标会话

这次我把个人私聊作为 Home Channel，因此这里也用了自己的数字用户 ID。群聊等场景需要按目标会话重新确认，不能直接照搬。

下面只是示例，数字必须替换成自己的：

TELEGRAM_ALLOWED_USERS=123456789
TELEGRAM_HOME_CHANNEL=123456789

排查时没有为了让 Bot 先回话就开放所有人访问。先核对被拒绝的账号确实是我本人，再把它设为唯一允许用户。

白名单修好以后，需要重新发消息。之前已经被拦截的内容，不会因为修改配置就自动重试。

9. 两套 systemd 服务，是这次最绕的一段

另一个坑来自重复启动。

配置向导可以安装用户级网关服务，部署时又安装了系统级网关服务。两者都叫 hermes-gateway.service，但处在不同的管理范围。

# 在 hermes 用户下查看用户级服务
systemctl --user status hermes-gateway

# 在 root 下查看系统级服务
systemctl status hermes-gateway

服务名一样，不代表查到的是同一个实例。

这次出现过已有网关占用实例锁，另一个网关拒绝启动的情况。重复实例也会让“谁在接收消息、谁在自动重启”变得很难判断。

最后我保留系统级服务，由普通的 hermes 用户运行；停用并备份用户级服务，避免两套管理机制同时拉起网关。

系统级服务不等于进程必须以 root 运行。这次把开机管理交给系统，把实际运行权限留给普通用户。

另外，网关设置为在本机代理服务之后启动，减少开机时代理还没准备好带来的连接问题。配置完成后也不再手工另外运行一份 hermes gateway run。

10. 什么才算这次真的部署完成？

这次验收一层层往前推进，而没有停在“服务显示 active”：

  1. Hermes 命令和终端界面能够运行。
  2. 模型服务完成配置。
  3. 服务器经本机代理能访问 Telegram。
  4. Bot Token 身份验证通过。
  5. 网关显示已连接，服务交由单一管理入口维护。
  6. 白名单与个人账号匹配。
  7. 我在 Telegram 实际发消息，并收到了正常回复。

最后还确认了 Hermes 和 Mihomo 的后台运行及开机自启，以及原有 AgentMall 服务仍然正常。

这意味着关闭我的电脑、退出 Termius，都不会停止服务器上的助理。服务器、模型服务和网络出口仍然需要正常工作。

后面如果继续增加记忆、定时任务或更多工具，我会把这些能力单独验证。当前最重要的一步已经完成：能在 Telegram 找到自己的助理，它能收到消息，也能正常回复。