Hermes VPS 部署与双 Telegram Bot 稳定运行实战指南

引言：部署的真正挑战不是安装，而是稳定运行

本文旨在解决一个核心问题：如何将 Hermes 稳定、持久地部署在 VPS 上，并实现两个 Telegram Bot 长期共存且互不干扰？许多人的误区在于，认为看到 hermes --version 有输出就代表部署成功。事实上，真正的挑战在于确保服务稳定运行、Telegram 成功接入、系统进程被有效管理，以及实现双 Bot 的资源隔离。本文将基于一次完整的实战踩坑经验，为你梳理出一条清晰、稳定的部署路径。

图片来源：Unsplash

第一部分：基础部署——从安装到服务上线

1. 为什么必须使用 VPS？

核心问题：本地电脑运行 Hermes 有何局限，VPS 如何解决这些问题？

在本地电脑运行 Hermes 命令行工具（CLI）进行临时测试是可行的。但一旦你的需求转变为以下任何一项，VPS 就成为必选项：

• Hermes 需要 24/7 长期在线。
• Telegram Bot 需要随时响应调用。
• 未来计划扩展为多个 Bot。
• 服务需要在服务器重启后自动恢复。

本地运行的根本缺陷在于：关机或断网会导致服务中断，且无法保证长期在线。部署到 VPS 上，本质上不是解决“安装”问题，而是解决“运行环境”的稳定性问题。

2. 部署第一步：安装 Hermes 本体与规避常见误判

核心问题：如何正确安装 Hermes 并避免将“安装成功”误判为“服务上线”？

使用官方提供的安装脚本即可完成 Hermes 本体的安装。安装完成后，通过 hermes --version 命令检查是否输出版本信息。

关键认知：hermes --version 命令成功，仅证明 CLI 工具本身安装正确，绝不等于 Telegram Bot 服务已经上线。这是最常见的误判点，许多人因此卡在后续步骤。

3. 环境准备：避开两个关键陷阱

核心问题：在正式部署前，需要在 VPS 环境上做哪些关键准备？

陷阱一：避免使用网页版 SSH 终端

许多 VPS 控制面板提供网页版 SSH 终端，但这不适合正式部署。它存在以下问题，会严重影响部署和排错效率：

• 连接不稳定，容易中断，导致上下文丢失。
• 长命令粘贴可能失败。
• 输出与输入混杂，难以阅读。
• 输入错误不易察觉。

解决方案：使用本地专业的 SSH 客户端（如 FinalShell、Termius）进行连接，确保一个稳定的“施工环境”。

陷阱二：系统软件源（APT 镜像）故障

安装过程中可能遇到 E: Failed to fetch ... 404 Not Found 类错误。这并非 Hermes 脚本的问题，而是 VPS 系统的软件源（用于安装依赖包）不可用。

解决方案：修复系统软件源。例如，将默认的云服务商镜像源替换为官方源：

sudo sed -i 's|http://旧镜像源地址|http://archive.ubuntu.com/ubuntu|g' /etc/apt/sources.list
sudo apt update && sudo apt upgrade -y
sudo apt install -y ripgrep ffmpeg # 安装 Hermes 依赖

重要逻辑：必须先确保 apt update 命令正常运行，再进行后续操作。系统依赖链的问题会引发一系列看似是 Hermes 的故障。

第二部分：从“能用”到“稳定”——服务化与配置验证

4. 核心跨越：将 Hermes Gateway 安装为系统服务

核心问题：如何让 Hermes 在后台稳定运行，并实现开机自启？

Hermes 部署有三个层次：CLI 可用、Gateway 可运行、服务可托管。真正的稳定部署，目标是达到第三层，即使用 systemd 托管服务。

安装 Gateway 为系统服务时，可能会遇到两个报错：

1. System gateway install requires root. Re-run with sudo.：需要 root 权限。
2. sudo: hermes: command not found：sudo 环境下找不到 hermes 命令路径。

这是因为 Hermes 默认安装在当前用户的本地目录（例如 /home/ubuntu/.local/bin/hermes），该路径不在 sudo 的默认 PATH 中。

正确操作流程：

# 使用绝对路径执行安装
sudo /home/ubuntu/.local/bin/hermes gateway install --system
# 启用服务（开机自启）
sudo systemctl enable hermes-gateway
# 启动服务
sudo systemctl start hermes-gateway
# 检查服务状态
sudo systemctl status hermes-gateway

最终验证标准：执行 sudo systemctl status hermes-gateway 后，输出中必须包含 Active: active (running)。没有这一行，就不算真正上线。

5. Bot 无响应排查：遵循正确的诊断顺序

核心问题：Telegram Bot 不回复消息时，应该如何系统性地排查？

当 Bot 不回复消息时，立即怀疑 Token 错误是低效的。应遵循以下优先级进行排查：

1. 未点击“开始”：在 Telegram 私聊中，必须先给 Bot 发送一次 /start 命令或点击“Start”按钮，Bot 才会开始响应。这是 Telegram 平台的交互规则。
2. 用户 ID 限制：如果在 Hermes 配置中设置了 Allowed User ID，但发送消息的用户 ID 不在允许列表内，Bot 将保持静默。
3. Gateway 服务未运行：这是最常见的技术原因。使用以下命令检查：

   sudo systemctl status hermes-gateway
   journalctl -u hermes-gateway -f # 查看实时日志
   

4. Token 格式错误：Telegram Bot Token 的标准格式通常为 123456789:AAxxxxxxxxxxxxxxxxxxxxxxxx。格式错误会导致认证失败。

反思/教训：排错顺序至关重要。先查服务状态，再看日志，最后核对配置（Token、User ID），能大幅提升效率。顺序错误会导致在无关环节浪费大量时间。

第三部分：进阶挑战——实现双 Bot 稳定共存

6. 双 Bot 的误区：为何简单的目录隔离会失败？

核心问题：为什么在同一用户下创建两个 Hermes 目录，无法实现双 Bot 并行运行？

一个常见的误解是，认为在同一系统用户（如 ubuntu）下，创建两个独立的配置目录（例如 ~/.hermes 和 ~/hermes-trader），就能运行两个 Bot。实际操作中会立即遇到错误：Gateway already running。

这个错误的含义非常明确：冲突发生在运行实例层面，而非文件层面。两个 Bot 尝试绑定相同的系统资源（如端口、进程锁），导致第二个实例无法启动。文件目录的隔离，不等于运行环境的隔离。

7. 稳定方案：用户级隔离

核心问题：实现双 Bot 稳定共存的最可靠架构是什么？

经过验证，最稳定的方案是 “用户级隔离”。即为每个 Bot 创建独立的系统用户，在每个用户环境下独立安装和配置 Hermes。

架构示例：

• Bot 1 (主助手)

  • 系统用户：ubuntu
  • 服务名：hermes-gateway
  • 用途：技术部署、内容助手等。
• Bot 2 (交易助手)

  • 系统用户：trader
  • 服务名：hermes-trader-gateway
  • 用途：市场分析、交易信号等。

为第二个 Bot 创建用户并安装 Hermes 的步骤：

# 1. 创建新用户
sudo adduser trader
sudo usermod -aG sudo trader # 可选：赋予sudo权限
# 2. 切换到新用户
sudo -iu trader
# 3. 在新用户环境下重新安装 Hermes
curl -fsSL <官方安装脚本URL> | bash
source ~/.bashrc
which hermes # 验证安装路径
hermes --version
# 4. 为第二个Bot进行独立配置
hermes setup # 此处将配置第二个Bot专属的Token、User ID等

8. 为第二个 Bot 创建独立的系统服务

核心问题：如何让第二个 Bot 也实现开机自启和后台稳定运行？

第二个 Bot 必须拥有自己独立的 systemd 服务配置文件，绝不能复用第一个 Bot 的服务。

1. 创建服务文件：

   sudo nano /etc/systemd/system/hermes-trader-gateway.service
   

   文件内容示例如下（注意 User、WorkingDirectory 和 ExecStart 路径均指向 trader 用户）：

   [Unit]
   Description=Hermes Trader Gateway
   After=network.target
   
   [Service]
   Type=simple
   User=trader
   WorkingDirectory=/home/trader
   ExecStart=/home/trader/.local/bin/hermes gateway run --replace
   Restart=always
   RestartSec=5
   
   [Install]
   WantedBy=multi-user.target
   

2. 加载并启动服务：

   sudo systemctl daemon-reload
   sudo systemctl enable hermes-trader-gateway
   sudo systemctl start hermes-trader-gateway
   sudo systemctl status hermes-trader-gateway
   

最终验证：同样，确保 systemctl status 输出 Active: active (running)。至此，两个 Bot 才算真正独立、稳定地运行起来。

第四部分：总结、清单与常见问题

一次成功的部署：六步标准流程与终极检验清单

对于首次部署，严格按照以下顺序操作可以最大程度避免返工：

1. 连接稳定 SSH：使用本地客户端连接 VPS。
2. 安装 Hermes 本体：运行官方安装脚本，验证 hermes --version。
3. 检查并修复系统依赖：运行 sudo apt update，如有404错误则更换软件源，并安装 ripgrep、ffmpeg。
4. 执行 Hermes 配置：运行 hermes setup，配置第一个 Bot。
5. 安装 Gateway 为系统服务：使用绝对路径执行 gateway install --system，然后启用、启动并检查服务状态。
6. 最终测试：关闭 SSH 连接，测试 Bot 是否仍可回复；重启 VPS，测试服务是否自动恢复。

部署完成检验清单：

实战反思：从命令到架构的认知升级

这次部署经历最深的体会是：Hermes 部署的难点，很少是某条具体的命令，而更多在于整体的架构设计。许多看似是“命令报错”的问题，根源在于运行环境的冲突或配置的错位。

一个简洁的总结可以概括为：“单 Bot 看安装，双 Bot 看隔离，生产可用看 systemd。” 理解并实践“用户级隔离”和“systemd 服务化管理”，是从实验走向生产环境的关键一步。

常见问题解答 (FAQ)

Q1: 执行 hermes gateway install --system 时提示需要 sudo，但用 sudo 又提示命令找不到，怎么办？
A: 这是因为 hermes 安装在用户目录，sudo 环境下找不到。请使用 hermes 的绝对路径执行命令，例如：sudo /home/你的用户名/.local/bin/hermes gateway install --system。

Q2: 双 Bot 部署时报错 “Gateway already running”，如何解决？
A: 这表明两个 Bot 运行在同一个系统用户下，产生了冲突。解决方案是实施“用户级隔离”，为第二个 Bot 创建全新的系统用户，并在该用户环境下重新安装和配置 Hermes。

Q3: 第二个 Bot 所在的用户执行 hermes 命令提示不存在，为什么？
A: Hermes 是安装在用户本地目录的，不会系统全局共享。切换到第二个用户后，必须重新执行安装脚本，为该用户独立安装一份 Hermes。

Q4: 两个 Bot 都显示在线，但回复消息混乱或错位，可能是什么原因？
A: 最可能的原因是两个 Bot 的配置没有完全独立。请确保在每个用户下分别执行 hermes setup，为每个 Bot 配置了专属的 Telegram Token、Allowed User ID 和频道权限。

Q5: VPS 重启后，只有一个 Bot 自动启动了，另一个没有，怎么排查？
A: 首先，检查第二个 Bot 的服务是否已启用：sudo systemctl is-enabled hermes-服务名。如果未启用，执行 sudo systemctl enable hermes-服务名。其次，确保在创建或修改服务文件后执行了 sudo systemctl daemon-reload 以重载配置。

Q6: 如何实时查看 Bot 的运行日志以进行调试？
A: 使用 journalctl 命令。例如，查看第一个 Bot 的日志：journalctl -u hermes-gateway -f (-f 参数表示跟踪实时输出)。查看第二个 Bot 则替换为对应的服务名。

Q7: 为什么强调不要用 VPS 的网页版 SSH 终端进行部署？
A: 网页终端连接不稳定，容易中断，且存在命令粘贴失败、输入输出混乱等问题，会严重降低部署和排错的效率与准确性。使用本地专业 SSH 客户端能提供稳定的会话环境。