跳转到主要内容
HermesAgent.Work
安装部署

如何把 Hermes Agent 部署到 VPS 上长期运行

讲清 Hermes Agent VPS 选择、进程守护、日志、环境变量、定时任务和低权限用户的基础部署思路。

更新 2026-10-0711 分钟阅读安装部署VPS部署运维

最后更新 2026-10-07 · HermesAgent.Work 编辑组 整理维护（内容维护说明）· 步骤过时或无法复现可反馈

为什么需要 VPS

本地电脑适合试验，VPS 适合长期运行。日报、周报、监控、提醒这类工作流需要 7×24 小时在线，不能依赖你的笔记本是否开机。

部署清单

  • 新建低权限用户
  • 配置 SSH Key 登录
  • 安装 Git、curl、xz-utils（Python 和 Node.js 由安装脚本处理）
  • 使用 .env 或服务配置管理环境变量
  • 配置进程守护和日志轮转
  • 定期更新系统安全补丁
ssh deploy@your-server
mkdir -p ~/apps/hermes-agent

推荐目录

把配置、日志和工作流分开，后面排错会轻松很多。不要把 Token、日志和模板都堆在一个目录里。

~/.hermes/              # Hermes 自己读取的目录
  .env                  # API Key、Bot Token
  skills/
  logs/
~/apps/hermes-agent/    # 你自己的工作区
  workflows/
  logs/
  README.runbook.md

~/.hermes/.env 保存服务端环境变量，技能放在 ~/.hermes/skills/——Hermes 只认这个目录，放到工作区里它读不到；想换位置，用 HERMES_HOME 环境变量指定整个目录。工作区的 logs 保存你自己的运行记录，README.runbook.md 记录启动、重启、更新、排错和回滚步骤。以后换服务器或交给别人维护时，这个文件比临时聊天记录可靠。

进程与日志

长期运行最容易被忽略的是日志。建议至少记录启动日志、任务执行日志、外部 API 错误和消息推送失败。没有日志的自动化，出了问题基本只能靠猜。

# 示例：先把日志输出到文件，确认稳定后再接进程守护
mkdir -p ~/apps/hermes-agent/logs
hermes doctor | tee ~/apps/hermes-agent/logs/doctor.log

环境变量和密钥

API Key、Bot Token、Webhook Secret 都只放服务端，不进前端代码、不进公开仓库，也不要截图发到群里。配置变更后要重启进程，因为后台进程经常还拿着旧环境变量。

上线顺序

第一步在 VPS 上跑 hermes doctor 和短问答；第二步跑一个只读工作流；第三步接测试群；第四步才接正式群或定时任务。每一步都保留日志，不要一口气把模型、Gateway、定时器和多个工作流全部打开。

成本提醒

VPS 费用和模型 API 费用都需要你自行承担。小规模个人任务可以从低配机器开始，不要一开始就买高配服务器。真正要监控的是失败重试、长输入和高频触发，它们比 VPS 配置更容易让成本失控。

gateway install 还是 gateway run：按宿主类型二选一

Gateway 要在 VPS 上长驻，先定运行形态。标准 Linux 发行版装成系统服务：

sudo hermes gateway install --system
hermes gateway restart
hermes gateway uninstall

install 在 Linux 上注册 systemd 服务、macOS 上注册 launchd。VPS 上一定要加 --system：不加装的是用户级服务，用户退出登录后就会停，开机也不会自己起来（除非先运行 sudo loginctl enable-linger <用户名>）。系统服务的开机自启和崩溃拉起都交给系统；改完配置用 restart 重载；迁移下线时 uninstall 干净移除。装完别急着收工，把 VPS 重启一次，确认服务自动拉起、平台消息能继续进来——自动恢复才是 install 路线的核心收益，没验证过等于没装。临时停机检修用 stop，修完 start 拉回来，不必动服务注册；之后每次 hermes update 升级，也记得 restart 一次让服务切到新版本。宿主是 WSL、Docker 容器或 Termux 时，官方推荐改走前台模式：

hermes gateway run

这三类环境的 systemd 通常缺失或不完整，前台运行把进程存活交给外层管理反而更稳。判断标准只有一条：这台宿主有没有完整可用的 systemd。

一台 VPS 跑多个实例：profile 隔离与容器重建

个人助理和团队机器人同机部署时不要共用一份配置——凭证串台、模型设置互相覆盖都是常见事故。hermes profile 提供完全隔离的实例：

hermes profile create team-bot
hermes profile use team-bot
hermes profile list
hermes gateway list

每个 profile 自带一套配置与凭证，互不污染；gateway list 能横向看到所有 profile 的 gateway 状态。什么时候才值得开第二个 profile：两套互不相干的凭证、两个不同的默认模型、或者两组独立的平台入口；只是想多跑一个工作流，用不着新实例。profile 支持 export 和 import，还能直接从 git URL 安装成发行版，换服务器时整套搬走。偏好容器路线的话，仓库自带 Dockerfile 与 docker-compose.yml，Windows 宿主另有 docker-compose.windows.yml，容器内配合前台模式运行即可；这条路的核心收益是机器可重建——环境定义进了版本控制，新 VPS 拉下来就能起，省掉逐项还原配置的过程。最后补一条很多人漏掉的：新机器装好后先跑一次 hermes doctor，看 node、浏览器、ripgrep、ffmpeg 这些非 Python 依赖齐不齐，缺什么它会给出安装命令；也可以用安装脚本只补依赖、不重装：curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --ensure node,browser,ripgrep,ffmpeg。旧教程里的 hermes postinstall 新版已删除，省得日后功能缺失时到处找原因。

还没有真实场景？可以先领取 Free Starter 模板包，从低风险只读任务开始试跑。

常见问题

把搜索里最常见的疑问集中放在这里，适合排查时快速确认方向。

个人任务需要多高配置的 VPS？+
日报、摘要、消息提醒这类轻量任务可以从低配 VPS 开始，重点不是 CPU，而是网络稳定、日志可读、进程能自动恢复。
Hermes Agent 部署到 VPS 后最容易漏什么？+
最容易漏日志、环境变量备份、进程守护和失败提醒。能跑一次不等于能长期运行。
要不要一开始就接正式群？+
不建议。先在 VPS 上跑 CLI 和测试群，连续几天稳定后，再接入正式频道。