甲骨文vps部署 Hermes

Views: 3

这次不是“装个程序”那么简单，而是把 Hermes 真正落到一台甲骨文小鸡上，接上 Telegram，再把模型走通，最后做到可以在手机上直接用。

看起来像三件事：部署、接 Bot、配模型。真做起来才发现，真正费时间的不是安装，而是判断到底该走哪条配置链路，以及定位那些“看起来像 key 错了，其实是 endpoint 走偏了”的问题。

这篇就把整个过程收一下：我为什么这么选，具体怎么做，中间踩了哪些坑，最后什么配置才是真正可用的。

一、为什么选甲骨文小鸡，为什么选 Hermes

原因很现实：Hermes 这种东西，最怕“只能在本机开着”。

如果只在自己电脑上跑，等于把一个本来应该长期在线、随时能响应的 agent，做成了“电脑开机时才存在的半成品”。放到 VPS 上，至少有三个好处：

• 第一，常驻。
• 第二，能直接挂 Telegram，一旦链路通了，手机就是入口。
• 第三，和本地工作环境隔开，减少互相污染。

至于为什么选 Hermes，不是因为它最轻，而是因为它已经把“命令行 + messaging gateway + model provider + cron”这些常见组件收在一起了。对于 VPS 场景，它不是最极简的，但很适合做一个能持续工作的云端 agent。

二、这次的部署策略：先跑通，再收口

这次没有一上来就折腾 80/443、域名反代和复杂前端，只做了一个更稳的策略：

• 先在小鸡上完成 Hermes 本体安装
• 再接 Telegram Bot
• 最后把模型 provider 跑通

这样拆的好处很明显：每一层出问题时，定位范围都更小。

如果一开始就把 Nginx、Webhook、域名、Bot、模型全部绑在一起，最后只会得到一个“哪里都可能有问题”的大黑盒。

实际摸底时，这台甲骨文小鸡的基础环境是够用的：

• Ubuntu 20.04
• Docker / Docker Compose 已安装
• Python / Git 可用
• 80 和 443 已被现有 Nginx 占用

这也决定了这次不去碰现有 Web 入口，而是优先走 Hermes 自己的 gateway 服务。

三、安装本体：别一上来自己造环境

Hermes 官方已经提供了安装脚本，这次直接沿官方链路走，反而省掉了很多“自己搭了一半结果环境不一致”的问题。

安装过程里，脚本自动补了几样关键东西：

• uv
• Python 3.11
• Node 22
• ripgrep
• ffmpeg
• Hermes 主程序和依赖

最后落地位置在：

• ~/.hermes/hermes-agent
• 可执行文件在 ~/.local/bin/hermes

这一段其实很顺，真正麻烦的是后面的模型和 Telegram 配置。

四、Telegram 接入：先配对，再设 home channel

Bot 接入本身不复杂，难点在于 Hermes 默认是有安全门槛的，不是你把 token 填进去它就自动对所有人放行。

这次接入流程分成四步：

1. 写入 Telegram Bot Token
2. 启动 Hermes gateway
3. 在 Telegram 私聊 bot，拿到 pairing code
4. 在服务器侧执行 approve，完成账号授权

授权完成之后，还需要补一件事：在 Telegram 里执行 /sethome。

这一步很重要，因为 Hermes 的 cron 结果、跨平台消息、主动通知，都需要一个默认投递目标。没有 home channel，很多功能虽然“逻辑上可用”，但消息没有地方回投，最后体验会像没配好一样。

这次最终把 Telegram 私聊设成了 home channel，同时把用户 ID 固化进 allowlist。这样后面就不会每次都重新走配对流程。

五、真正最费时间的坑：MiniMax 不是“填个 key”就完了

整个部署过程中，最浪费时间的不是 Hermes，也不是 Telegram，而是 MiniMax。

一开始的错误看起来像普通 401：

Missing Authentication header

这种报错第一眼很容易让人以为是 key 没写进去。但这次真正的问题不是 key 缺失，而是配置链路错位了。

当时 provider 已经切成了 MiniMax，可 base_url 还残留在 OpenRouter：

• provider：MiniMax
• endpoint：OpenRouter

这种状态非常坑人，因为表面上看“provider 对了”，实际上请求还是发到了错误的地方。于是 Hermes 带着 MiniMax 的语义，去打 OpenRouter 的地址，最后得到的就是一个很迷惑的认证错误。

第一层坑，卡在这里。

把这个问题修掉之后，错误又变成了另一种：

invalid api key

这个时候事情才真正清晰起来：认证头已经带上了，链路也确实打到了 MiniMax 兼容接口，但 key 仍然被判无效。

继续往下对，最后才确认：这把 key 根本不是 minimax.io 国际站的，而是 minimaxi.com 国内站的。

也就是说，前面并不是“一把坏 key”，而是“拿国内 key 走了国际口径”。

六、最后跑通的正确配置

这次最终可用的口径是：

• provider: minimax-cn
• MINIMAX_CN_API_KEY=...
• base_url: https://api.minimaxi.com/anthropic
• model：MiniMax-M2.7

这里最值得记一笔的，不是最终值本身，而是判断顺序：

1. 先确认 key 属于国际站还是国内站
2. 再确认 provider 是否对应
3. 最后确认 base_url 没有残留旧值

顺序反了，排错效率会非常差。

这次切到 minimax-cn 之后，我直接在服务器上做了一次真实调用测试，不是只看配置文件，也不是只看服务状态，而是实际执行：

只回复：测试成功

模型正确返回“测试成功”，这条链路才算真正闭环。

七、这次部署里最该记住的几个注意事项

如果后面还要再部署一次 Hermes，或者把它迁到别的机子上，我觉得最该注意的是下面这几条：

1. 不要看到 401 就只盯着 key。
   401 不一定是 key 本身错，也可能是 provider 和 endpoint 混配了。
2. MiniMax 要先分清国际站和国内站。
   minimax.io 和 minimaxi.com 不是一回事，provider 和 env key 也不该混用。
3. 改 provider 以后，一定检查 base_url。
   很多问题不是“没改”，而是“没改干净”。
4. Telegram 接入别只配 bot token。
   配对、allowlist、home channel，这三件事少一件，后面都会看起来像“偶尔能用，偶尔不对”。
5. VPS 上优先先跑通服务，再谈 Web 入口。
   尤其是机器上已经有 Nginx、80/443 已占用时，先别急着折腾域名和反代，先让核心链路说话。

八、最后的结果

到这一步，这台甲骨文小鸡上的 Hermes 已经完成了三件事：

• Hermes 本体安装完成
• Telegram Bot 链路打通
• MiniMax 国内站模型调用验证通过

也就是说，它现在已经不是“装上了”，而是能真正接消息、跑模型、回结果的一套在线 agent。

这类部署里最容易浪费时间的，从来都不是安装命令本身，而是那些看起来像小问题、实际会让整条链路跑偏的细节。

把这些细节收口之后，后面再重做一遍，速度就会快很多。

这也是为什么，部署完之后，记录比部署本身还重要。