这一篇不重复安装和网关配置，直接讲更实用的一步：让 Hermes 定时巡检 VPS、把异常主动发到手机上，并帮你把备份流程做成一套可验证的日常习惯。
Hermes 最适合先做“看、报、提醒”，而不是一上来就给它自动删文件、重启服务。 每天早上收到一条机器状态摘要，磁盘或服务异常时第一时间提醒你，备份完成后再做一次恢复抽查——这三件事做扎实，VPS 就已经比大多数“装完就不管”的机器稳得多。
快速上手：先做一个每日健康报告
已经在 Telegram、飞书等平台配置好 Hermes Gateway 的用户，可以直接在与 Hermes 的对话里发送下面这段需求：
每天上午 9 点检查这台 VPS：在线时间、系统负载、CPU、内存、磁盘使用率、Docker 容器状态和 Nginx 状态；只执行只读检查，不要修改配置、不要重启服务。把结果压缩成一条中文摘要发回当前聊天；发现磁盘使用率超过 80%、Nginx 未运行或任一业务容器退出时，把对应异常放在第一行。
Hermes 会通过内置的 cron 能力创建定时任务。创建后，马上让它列出任务名称、触发时间、消息投递位置和使用的模型；第一次不要等到第二天，手动运行一次确认消息确实能收到。
这一步不需要另装监控面板，但它也不是要替代哪吒或 Komari。更舒服的分工是：探针持续收集曲线和在线率，Hermes 把你真正需要处理的变化翻译成一条人能看懂的提醒。
一、先分清：哪些事交给 Hermes，哪些不要交给它
Hermes 可以调用终端、文件和定时任务等工具，所以它不只是“把命令输出总结一下”。也正因为这样，权限边界比普通聊天机器人重要得多。
| 任务 | 建议交给 Hermes 吗 | 原因 |
|---|---|---|
| 查看负载、内存、磁盘、日志、容器状态 | 可以 | 默认是只读检查，风险低，最适合定时化。 |
| 汇总哪吒 / Komari 的异常、写成日报 | 可以 | 机器数据多，人不需要每天盯面板。 |
| 生成备份清单、检查备份文件是否新鲜 | 可以 | 能避免“以为备份了，其实早就失败”的情况。 |
| 自动更新软件、重启业务服务 | 先不要 | 更新失败、重启顺序错误都可能影响线上服务。 |
| 自动清理日志、删除旧备份、改防火墙 | 不建议直接授权 | 这些动作可逆性差，先让它给方案和待执行命令。 |
新手最容易踩的坑，是为了省事把所有命令权限和聊天入口都放开。真正省心的做法反而是先把任务拆小：巡检只读、告警只通知、修复要确认。等你连续运行一两周、知道每条任务会做什么，再考虑自动化下一步。
二、让 Hermes 先学会“日报”，而不是只会聊天
VPS 日报不用追求几十项指标。普通建站、反代、小型 Docker 服务，下面六项够用了：
- 机器是否在线、运行了多久；
- 1/5/15 分钟负载是否明显异常；
- 内存和 swap 是否持续吃紧；
- 根分区与业务数据盘是否接近满；
- Nginx、数据库、Docker 容器等关键服务是否还在运行；
- 昨天的备份是否生成，文件是否明显小于平时。
把这些项目写进任务提示词时，最好同时告诉 Hermes“哪些服务是你的业务服务”。例如你的机器只跑了 Nginx、WordPress 和一个 Docker Compose 项目，就不要让它猜；直接写清服务名和项目目录，结果会稳定很多。
可以使用这段更完整的模板：
每天 09:00 对本机做一次只读巡检：
- 检查 uptime、load average、free、df -h；
- 检查 nginx 服务是否 active；
- 检查 Docker 中是否有 exited 或 unhealthy 容器；
- 检查 /srv/backup 中最近 24 小时是否有新的备份文件；
- 不要安装软件、删除文件、修改配置或重启任何服务。
正常时用不超过 6 行中文汇总；异常时第一行以“异常：”开头，并说明建议我先检查什么。把结果发到当前聊天。
这里的重点不是命令本身，而是把边界写明。定时任务会在独立会话中运行，它不会天然知道你今天正在维护哪个站点，也不应该凭空猜测“顺手重启一下”是否合适。
三、定时任务怎么创建、怎么确认真的在跑
Hermes 的定时任务由 Gateway 常驻进程调度。也就是说：任务建好了，但 Gateway 没有运行或 VPS 重启后没有自启，日报就不会自己回来。
常用管理命令如下：
# 查看已创建的任务和下次执行时间
hermes cron list
# 查看任务调度状态
hermes cron status
# 对某项任务做只读健康检查
hermes cron doctor
# 查看某任务最近执行记录
hermes cron runs <任务ID> --limit 10
如果你是按第二篇教程把 Gateway 安装成服务，日常还应偶尔检查：
hermes gateway status
journalctl --user -u hermes-gateway -f
使用系统级 Gateway 的用户，则将上面的命令替换为带 sudo 的 systemd 服务查询方式。刚开始配置时，最稳的流程是下面四步：
- 在聊天里用自然语言或
/cron add创建任务； - 让 Hermes 列出任务详情，确认不是“只保存到本地文件”；
- 手动触发一次任务，确认手机确实收到结果；
- 第二天看一次历史记录，再决定是否调整频率。
定时任务为什么建议单独固定模型
定时任务会调用模型，也会产生费用。Hermes 的设计是：任务可以单独指定模型；如果你没有指定，它会依赖当前默认模型的快照。之后你在聊天中切换了提供商或模型，原任务为了避免悄悄换到更贵的模型，可能会停止执行并提醒你处理。
所以日报、日志摘要这类重复任务，建议使用足够便宜的模型并明确固定。你可以让 Hermes 先展示准备采用的模型和预计频率，确认后再创建；复杂排障则留给你在聊天中临时使用更强的模型。这样不会出现“日常汇总突然按高价模型连续跑一个月”的情况。
四、告警别贪多：先盯住三个真正会出事的信号
告警太多的结果，往往是所有消息都被静音。对于一台普通 VPS，先从下面三类开始就够了。
1. 磁盘使用率过高
磁盘满了会带来很多看似无关的故障：数据库写不进去、Docker 拉不到新镜像、证书续期失败，甚至 SSH 登录后都没法正常操作。
建议阈值可以先这样定：
| 状态 | 建议动作 |
|---|---|
| 低于 70% | 记录即可，不必提醒。 |
| 70%–80% | 放进日报，顺便观察增长速度。 |
| 高于 80% | 主动通知，检查日志、镜像、备份和上传目录。 |
| 高于 90% | 视为需要尽快处理的故障，先扩容或手动清理。 |
不要让 Hermes 在超过 80% 时自动执行清理命令。先让它告诉你占用最大的目录、建议检查的路径；确认后再人工处理，尤其不要把“删除旧备份”写成一个没有审查条件的自动任务。
2. 关键服务或容器退出
网站常见的关键对象是 Nginx、Caddy、数据库，或 Docker Compose 里的应用容器。你可以让 Hermes 只报告状态，不修复：
每 15 分钟检查 nginx 和 Docker 容器状态。若 nginx 不是 active，或名为 wordpress、mysql 的容器出现 exited/unhealthy，立即发一条简短告警并附上状态摘要；不要重启服务。
等你确认告警准确、知道服务正常重启的顺序以后，才考虑把“生成修复建议”加进去。自动重启看上去很方便，但若根因是磁盘已满、数据库损坏或镜像更新失败，重启只会掩盖问题。
3. 备份没有按时出现
备份的失败最安静：脚本报错、对象存储额度不足、远端密钥失效，都不会让网站立刻下线，但真出问题时才发现最后一个可用备份停在几个月前。
最简单的检查不是让 Hermes 判断“备份内容一定可恢复”，而是每天确认：备份目录或远端仓库里是否有新的备份、大小是否离谱、任务退出码是否正常。每月再做一次真正的恢复演练，这一步不能省。
五、自动备份的正确位置：Hermes 负责盯流程，不替代备份工具
Hermes 可以编排任务、查看结果、把失败通知你，但它不是备份格式，也不会凭空让数据变得可恢复。真正存数据的，仍应是你选择的备份工具和备份位置，例如 restic、borg、rsync，或者服务商快照与对象存储。
一套够用的备份方案通常包含三层：
业务数据（网站文件 / 数据库导出 / 重要配置）
↓ 每天自动生成
本机短期备份（用于误删后的快速恢复）
↓ 再同步
异机或对象存储副本（用于 VPS 故障、误操作或机房事故）
如果备份和业务数据永远在同一块磁盘上，它只能防误删，防不了整台 VPS 丢失。对于 WordPress、面板和 Docker 用户，至少要把网站文件、数据库导出、Compose 配置与反向代理配置纳入清单；不要把 API Key、Bot Token、SSH 私钥直接贴进聊天记录或提交到仓库。
让 Hermes 帮你做备份时，推荐这样提需求：
我需要为 /srv/www 和数据库导出建立每日备份。请先根据现有目录生成一份备份方案：说明备份内容、保留天数、目标位置、恢复步骤和失败告警方式；不要直接执行命令，也不要显示任何密钥。等我确认方案后，再把执行步骤拆成可逐条验证的命令。
它的价值是把“我该备份什么、怎么验证、失败后看哪里”梳理清楚。执行之前你仍应确认目标路径、保留策略和恢复方法。备份任务上线后的第一件事不是看日志显示成功，而是挑一个小文件或测试数据库，在独立目录完成一次恢复。
六、Hermes、哪吒、Komari 如何分工
如果你已经搭过监控面板，不需要为了使用 Hermes 把原来的体系推倒重来。
| 工具 | 更擅长做什么 |
|---|---|
| 哪吒监控 | 多机器在线率、资源曲线、通知、长期监控面板。 |
| Komari 探针 | 轻量展示、节点信息与资源查看。 |
| Hermes Agent | 对话式排查、日报总结、把多处状态归纳成行动建议、按流程执行已确认的任务。 |
举个实际用法：哪吒提示某台机器内存持续走高，Hermes 不必替代哪吒采集数据；你只要把异常现象告诉它，让它在指定机器上读取容器状态、最近日志和磁盘情况，再给出“先检查哪个服务”的排查顺序。这样既保留了监控面板的连续数据，也少了 SSH 后不知道从哪看起的麻烦。
有多台 VPS 时，也不要急着让一台 Hermes 拿到所有机器的 root 权限。先从一台主控机和一两台非关键业务机试起，给每台被管理机器单独准备权限最小的运维账号，并明确它允许执行的检查范围。
七、上线前的安全清单
Hermes 能操作服务器，所以“让谁能给它发指令”必须先于任何自动化。下面这些检查很朴素，但很有用：
- 消息平台使用允许名单，只允许自己的数字 ID 或团队成员 ID；不要开启全员可用模式。
- Gateway 尽量以普通用户运行，不要为了少输一次
sudo就长期用 root 跑。 - Bot Token、模型 API Key、SSH 密钥只放在受权限保护的凭据文件中，不发到群聊、不写进 Skill、不提交 Git。
- 保持危险命令审批开启；cron 的无人值守场景默认应拒绝需要人工审批的破坏性命令。
- 先设置只读巡检任务，再逐项增加能力；涉及删除、重启、更新、改防火墙的任务必须有明确的人为确认环节。
- 定期查看 Gateway 日志和 cron 运行记录；不认识的指令、反复失败的任务都应暂停后再排查。
- 每次 Hermes 更新后，抽查一次 Gateway、定时任务和消息投递是否正常。
这一套并不复杂。真正危险的不是“AI 会不会犯错”，而是把一个能运行命令的入口公开给陌生人，或让它在没有边界的情况下长时间自动执行。
八、常见问题 FAQ
Hermes 能代替哪吒监控或 Komari 吗？
不能完全代替。哪吒和 Komari 更适合稳定地采集指标、展示曲线和管理节点；Hermes 更适合把状态、日志和你的需求组合起来，给出中文结论或协助排查。三者可以共存。
VPS 只有 1GB 内存，能跑日报任务吗？
只做网关、定时摘要和少量只读检查通常可以尝试，但 1GB 机器的余量很小。若还运行网站、数据库或多个容器，建议至少使用 2GB 内存，并观察 swap 和 OOM 情况。不要因为自动化又把原本就紧张的小机器压垮。
定时任务没有发消息，先查哪里？
按顺序检查 hermes gateway status、hermes cron status、hermes cron list 和任务运行记录。先确认 Gateway 是否还在运行、任务是否有下次执行时间、投递目标是否仍然有效；不要上来就重复创建多个同类任务。
可以让 Hermes 自动重启 Nginx 或 Docker 吗？
技术上可以，但不建议作为第一步。先让它报告故障、生成建议并等待确认。等你已经验证过服务依赖、重启顺序和告警准确性，再对低风险、可回滚的动作做有限自动化。
备份显示成功，是不是就够了？
不够。成功日志只能说明任务跑完，不能证明数据能恢复。至少每月在独立目录或测试环境恢复一次文件或数据库，确认文件完整、权限正确、应用能读到数据。
结语
一台 VPS 真正难的不是装上几个服务，而是它连续运行三个月以后：磁盘有没有慢慢被日志吃满、备份是不是还在跑、某个容器挂了你能不能第一时间知道。
Hermes 的正确打开方式，就是把这些琐碎却重要的检查变成有边界的自动流程：先日报，后告警；先只读，后执行；先恢复演练，后谈放心。把这几步跑顺，它才不只是聊天机器人，而是一个能长期替你盯住 VPS 的助手。
站内相关阅读
