Hermes Agent 入门（五）：Cron、自动巡检与主动通知，让 AI 自己开始工作

前面四篇，我们已经完成了：

第一篇
安装 Hermes
↓
让 Agent 跑起来

第二篇
接入模型 / OpenRouter / 第三方 API
↓
让 Tool Calling 正常工作

第三篇
Memory + Skills
↓
让 Hermes 记住环境和工作流程

第四篇
QQ / 微信 / 飞书 / 钉钉 / 企业微信 Gateway
↓
随时可以从手机找到 Hermes

但目前还有一个明显的问题：

你不找 Hermes
↓
Hermes 就什么都不干

比如服务器磁盘从：

70%
↓
80%
↓
95%
↓
100%

如果你没主动问：

“服务器现在磁盘怎么样？”

Hermes 并不会突然醒过来告诉你：

⚠️ /data 已经 95% 了。

所以这一篇要解决的，就是：

让 Hermes 从一个“被动回答问题的 AI”，变成能够定时执行任务、主动发现问题并通知你的 Agent。

我们会实际做出这样一套东西：

每 30 分钟
↓
自动检查服务器
↓
CPU
Memory
Disk
Load
Docker
Systemd
网站状态
↓
全部正常
↓
不打扰你

发现异常
↓
进一步分析
↓
QQ / 飞书 / 钉钉 / 企业微信
↓
主动通知

本文基于 2026 年 9 月 Hermes Agent 当前版本整理。

---

一、Hermes 的 Cron 并不是普通 Linux Cron

Linux 用户看到 Cron，第一反应一般都是：

crontab -e

例如：

*/30 * * * * /opt/check.sh

Hermes 的 Cron 和它有点像，但能力更多。

普通 Cron：

时间到了
↓
运行脚本
↓
结束

Hermes Cron：

时间到了
↓
启动一个新的 Agent Session
↓
给 AI 一个任务
↓
AI 自己调用工具
↓
分析结果
↓
生成报告
↓
通过 QQ / 飞书 / 企业微信等平台发送

Hermes 当前的 Cron 支持一次性任务、周期任务、标准 Cron 表达式、暂停、恢复、修改、手动触发、多 Skill 注入、跨平台投递，以及完全不调用 LLM 的 Script-Only 模式。

所以它更像：

Cron
+
Agent
+
Tools
+
Skills
+
Gateway

---

二、最简单的 Cron：让 Hermes 半小时后提醒你

进入 Hermes 后直接说：

30 分钟后提醒我检查 Minecraft 服务器。

Hermes 可以自己调用 Cron Tool 创建任务。

也可以直接：

/cron add "in 30m" "提醒我检查 Minecraft 服务器"

终端则可以：

hermes cron create "in 30m" \
  "提醒我检查 Minecraft 服务器"

这里：

in 30m

代表一次性任务。

执行一次以后就结束。

Hermes 当前支持类似：

in 30m
in 2h
in 1d

这样的相对时间。

---

三、周期任务更加有意思

例如：

hermes cron create "every 30m" \
  "检查服务器状态"

就是：

每 30 分钟
↓
检查服务器

还可以：

hermes cron create "every 2h" \
  "检查 Docker 服务有没有异常"

或者：

hermes cron create "daily at 9am" \
  "生成服务器每日状态摘要"

当然也支持标准 Linux Cron 表达式：

*/30 * * * *

每 30 分钟。

0 9 * * *

每天 09:00。

0 9 * * 1-5

工作日早上 09:00。

0 */6 * * *

每 6 小时。

Hermes 当前同时支持自然语言形式、固定间隔、标准五字段 Cron 表达式和 ISO 时间戳。

---

四、Cron 真正执行任务的是 Gateway

前一篇为什么一定要先讲 Gateway？

原因现在就出现了。

Hermes 的 Cron Scheduler 是由：

Hermes Gateway

长期运行并负责调度的。

Gateway 会周期性检查：

~/.hermes/cron/jobs.json

如果发现某个 Job 到时间：

创建新的 Agent Session
↓
加载任务
↓
加载指定 Skill
↓
运行 Agent
↓
发送最终结果
↓
计算下一次执行时间

当前调度器大约每 60 秒进行一次 tick。

所以如果你准备长期使用 Cron，最好确保：

sudo hermes gateway status --system

正常。

如果还没安装系统服务：

sudo hermes gateway install --system
sudo hermes gateway start --system

这样 VPS 重启以后 Gateway 也能继续工作。

---

五、一个很重要的概念：Cron 是新的 Session

这一点非常容易踩坑。

假设你刚刚和 Hermes 聊了半天：

用户：
我们现在排查的是 prod-2。

Hermes：
好的。

用户：
数据库在 10.0.0.12。

Hermes：
知道了。

用户：
每小时检查一下它。

你不能想当然认为：

一小时后的 Cron

还拥有现在完整的聊天上下文。

Hermes Cron 每次会启动一个新的 Agent Session，它不会继承你当前聊天里的临时上下文，所以 Cron Prompt 应该尽量做到“拿出来单独看也能知道自己要干什么”。

不要写：

每小时检查一下它。

更应该写：

每小时检查 prod-2。

数据库地址：10.0.0.12。

检查：
- CPU
- 内存
- /data 磁盘
- Docker
- PostgreSQL
- 网站 HTTPS

如果全部正常，保持静默。
如果异常，说明异常项目、当前状态和建议。
不要进行重启、删除文件或修改配置。

这种 Prompt 才适合长期 Cron。

---

六、如果任务已经做成 Skill，就不用把 Prompt 写得特别长

上一篇我们创建过：

server-health-check

Skill。

那么现在 Cron 可以直接加载它。

例如：

hermes cron create "every 30m" \
  "检查当前服务器运行状态。如果全部正常保持静默，发现异常则报告。" \
  --skill server-health-check \
  --name "server-health-check"

这样每次任务执行时：

Cron
↓
加载 server-health-check Skill
↓
知道应该怎么检查服务器
↓
开始执行

Hermes 当前支持给一个 Cron Job 附加一个或多个 Skill，而且 Skill 会在 Agent 执行 Prompt 之前加载。

这就是：

Cron
+
Skills

真正开始结合的地方。

---

七、我们的第一个正式任务：服务器健康巡检

假设目标是：

每 30 分钟检查一次服务器。

检查：

CPU
Load Average
Memory
Swap
Disk
Docker
systemd
网站

异常才通知。

可以创建：

hermes cron create "every 30m" \
  "执行服务器健康检查。

检查 CPU、load average、内存、Swap、磁盘容量、inode、Docker 容器状态、失败的 systemd 服务，以及本机主要 Web 服务是否正常。

只允许执行读取和诊断操作。

禁止：
- 删除文件
- 重启服务
- kill 进程
- 修改配置
- 自动更新软件

如果所有项目都正常，最终只回复 [SILENT]。

如果发现异常，请说明：
1. 异常项目
2. 当前数据
3. 可能原因
4. 建议进一步处理方式

不要自动修复。" \
  --skill server-health-check \
  --name "server-health-check"

这已经是一套比较完整的 Agent 巡检任务。

---

八、[SILENT] 非常重要

如果服务器完全正常，Hermes 每半小时都给你发：

服务器正常。

那一天就是：

48 条消息

一个月：

1440 条消息

很快你就会把机器人屏蔽掉。

Hermes 专门提供了：

[SILENT]

机制。

如果 Cron Agent 最终响应中包含这个标记，Hermes 会抑制消息投递，但执行结果仍然会保留在本地，方便后续审计。

所以监控类任务非常推荐写：

如果所有检查都正常，
最终只回复：

[SILENT]

不要附加其他文字。

于是：

正常
↓
[SILENT]
↓
不通知

异常：

磁盘 93%
↓
正常生成报告
↓
通知手机

这就是比较合理的监控方式。

---

九、最终收到的消息应该是什么样？

例如：

⚠️ 服务器巡检发现异常

主机：
prod-web-1

异常项目：
/data 磁盘使用率达到 93%

当前状态：
总容量：1.8 TB
已使用：1.67 TB
剩余：126 GB

主要占用：
/data/docker    742 GB
/data/backup    511 GB
/data/media     318 GB

其他项目：
CPU：正常
Load：正常
Memory：61%
Swap：4%
Docker：全部运行
Systemd：无失败服务
HTTPS：正常

建议：
优先检查 /data/backup 中的历史备份。

当前没有执行删除或清理操作。

而不是：

磁盘有点满，建议清理。

所以 Cron Prompt 里最好明确规定：

输出格式

---

十、把结果发到 QQ

上一篇已经配置好 QQ Bot 的话，可以：

hermes cron create "every 30m" \
  "检查服务器。如果全部正常回复 [SILENT]，否则报告异常。" \
  --deliver qqbot \
  --name "server-watch"

Hermes 当前 Cron 的 QQ 官方 Bot 投递目标名称就是：

qqbot

它会投递到：

QQBOT_HOME_CHANNEL

对应的 QQ 用户或群 OpenID。

例如：

QQBOT_HOME_CHANNEL=xxxxxxxx

配置在：

~/.hermes/.env

即可。

---

十一、飞书、钉钉和企业微信也一样

飞书：

--deliver feishu

企业微信：

--deliver wecom

微信：

--deliver weixin

钉钉：

--deliver dingtalk

这些平台都可以通过 Home Channel 接收 Cron 主动通知。

比如飞书可以在聊天里：

/set-home

把当前聊天设置为 Home Channel，也可以直接配置：

FEISHU_HOME_CHANNEL=oc_xxxxx

Hermes 的飞书 Adapter 官方就支持把 Cron 结果投递到 Home Chat。

企业微信则：

WECOM_HOME_CHANNEL=chat_id

即可作为定时任务和主动通知目标。

---

十二、也可以一个任务同时发多个平台

例如：

QQ
+
飞书

同时收到。

Hermes 支持一个 Cron Job 配置多个 Delivery Target。

甚至：

all

可以向所有已经配置 Home Channel 的平台发送。

例如概念上：

巡检发现严重异常
        ↓
        ├── QQ
        ├── 飞书
        └── 企业微信

不过一般不建议什么消息都全平台广播。

我的建议是：

个人服务器
→ QQ

团队服务
→ 飞书 / 企业微信

严重故障
→ 多平台

---

十三、Cron 可以直接从聊天里创建

其实不需要记 CLI。

比如在 QQ 里直接告诉 Hermes：

每 30 分钟检查一次这台服务器。

检查 CPU、内存、磁盘、Docker 和失败的 systemd 服务。

所有项目正常就不要通知我。

有异常才告诉我。

只诊断，不要自动修复。

Hermes 可以自己调用 cronjob Tool 创建对应任务。官方现在的 Cron 设计就是允许 Agent 自己创建、修改、暂停和删除计划任务。

以后甚至可以直接说：

把服务器巡检改成每小时一次。

或者：

今晚先暂停服务器巡检。

Hermes 都可以管理已有 Job。

---

十四、查看所有任务

终端：

hermes cron list

查看 Cron 系统状态：

hermes cron status

例如可能看到：

server-health-check

Schedule:
every 30m

Next run:
10:30

Status:
active

---

十五、修改任务

比如从：

every 30m

改成：

every 1h

可以：

hermes cron edit server-health-check \
  --schedule "every 1h"

Hermes 当前 Job 可以直接修改，不需要先删除再重新创建。

---

十六、暂停和恢复

暂停：

hermes cron pause server-health-check

恢复：

hermes cron resume server-health-check

删除：

hermes cron remove server-health-check

手动马上跑一次：

hermes cron run server-health-check

第一次创建任务以后，我非常建议马上：

hermes cron run <job>

人工触发一次。

不要等半小时以后才发现：

Prompt 写错
Skill 没加载
工具没权限
平台发不出去

---

十七、怎么看以前跑过什么？

查看最近执行：

hermes cron runs

或者指定任务：

hermes cron runs server-health-check --limit 20

Hermes 当前会记录 Cron 执行历史。

如果任务一直报错，还可以：

hermes cron incidents

查看持续失败事件。

再跑：

hermes cron doctor

检查任务配置、下一次执行时间、脚本路径、工作目录等问题。

这一套对排查：

“为什么昨天晚上没巡检？”

非常有用。

---

十八、Cron 使用的是单独的 Tool 权限

这是安全上一个很重要的点。

Cron Job 并不一定默认拿到你 CLI 里的全部 Tool。

现在 Hermes 可以针对：

cron

单独设置 Toolset。

运行：

hermes tools

然后选择：

cron

可以决定它是否允许：

Terminal
Files
Browser
Web Search
其他工具

Cron Job 当前会使用专门为 cron 平台配置的 Toolset。

这个设计非常有意义。

比如平时聊天 Hermes 可以：

Terminal
+
文件修改

但服务器自动巡检 Cron 可以只开放：

读取系统状态
+
查看日志

尽量不要让无人值守任务拥有不必要的破坏能力。

---

十九、我的建议：自动巡检和自动修复分开

很多人做到这里就会想：

既然 AI 都发现 nginx 挂了，
为什么不直接 systemctl restart nginx？

技术上当然可以。

但我不建议刚开始就这么做。

因为：

nginx 挂了

只是一个表象。

原因可能是：

配置错误
端口冲突
证书错误
磁盘满了
upstream 问题
OOM
文件系统只读

如果 Agent 一看到：

服务停止

就：

systemctl restart nginx

有时候只是掩盖问题。

更加合理的第一阶段：

检测
↓
诊断
↓
报告
↓
人确认
↓
再修复

---

二十、可以让 Hermes 把修复方案也写出来

比如 Prompt：

如果发现异常：

先完成诊断。

给出你建议执行的修复步骤和命令。

但是不要真正执行任何会改变系统状态的操作。

等待用户确认。

最终收到：

⚠️ nginx 异常

原因：
/etc/nginx/conf.d/api.conf 第 42 行存在配置错误。

nginx -t：
unexpected "}"

建议：
修复第 42 行以后执行：

nginx -t

确认通过后再：

systemctl reload nginx

目前未修改任何文件。

然后你回复：

按你的方案修。

才让交互式 Hermes 执行。

我觉得这是 AI 运维比较舒服的一种边界。

---

二十一、但有些任务根本没必要调用 AI

例如：

每 5 分钟检查 RAM 是否 > 90%

实际上完全不需要：

LLM

如果每五分钟请求一次模型：

检查 RAM

一天就是：

288 次 LLM 请求

完全没必要。

Hermes 现在专门提供：

No-Agent Cron

也就是：

Cron 照常运行，但完全不调用模型。

这种模式非常适合：

CPU 阈值
Memory 阈值
磁盘阈值
Ping
端口检查
HTTP 状态
证书天数
进程是否存在

等确定性任务。

---

二十二、例如：磁盘超过 90% 才 QQ 告警

先创建：

mkdir -p ~/.hermes/scripts

然后：

nano ~/.hermes/scripts/disk-alert.sh

内容：

#!/usr/bin/env bash

THRESHOLD=90

df -P | awk -v threshold="$THRESHOLD" '
NR > 1 {
    usage=$5
    gsub("%","",usage)

    if (usage >= threshold) {
        printf "⚠️ 磁盘告警\n挂载点：%s\n使用率：%s%%\n", $6, usage
    }
}'

权限：

chmod +x ~/.hermes/scripts/disk-alert.sh

然后：

hermes cron create "every 10m" \
  --no-agent \
  --script disk-alert.sh \
  --deliver qqbot \
  --name "disk-alert"

Hermes Script-Only Cron 要求脚本位于：

~/.hermes/scripts/

目录内。.sh / .bash 会使用 Bash 执行。

---

二十三、这个模式为什么特别适合监控？

因为：

脚本没有任何输出
↓
Hermes 不发消息

例如磁盘：

43%

脚本 stdout 为空：

''

结果：

不通知

磁盘：

93%

输出：

⚠️ 磁盘告警
挂载点：/data
使用率：93%

Hermes 就把 stdout 原样发出去。

No-Agent Job 正常退出且 stdout 为空时，会静默；stdout 有内容时才投递，而脚本非零退出或超时则会发送错误告警。

最重要的是：

0 Token
0 LLM 请求

非常适合高频监控。

---

二十四、那什么时候应该用 AI Cron？

可以按这个原则判断。

确定性判断：

磁盘 > 90%
内存 > 85%
网站 HTTP != 200
端口打不开
进程不存在

用：

No-Agent

而这种：

分析最近日志有没有异常

判断最近服务器有没有性能问题

总结过去一天发生了什么

分析 Docker Container 为什么反复重启

判断这些错误是否值得通知

就适合：

Agent Cron

可以简单记：

知道检查规则
+
知道消息该怎么写
→ Script

需要理解
+
分析
+
判断
→ Agent

官方对 No-Agent 模式的定位也是如此：Watchdog 和明确阈值用 Script，摘要和需要推理的任务交给 LLM。

---

二十五、甚至可以把两者组合

我其实更推荐生产环境这么做：

低成本脚本
↓
每 5 分钟检查
↓
正常
→ 什么都不做

异常
↓
触发 AI
↓
AI 进一步排查
↓
生成完整诊断
↓
通知

例如：

disk-alert.sh
↓
发现 /data > 90%
↓
Hermes Agent
↓
du
↓
检查 Docker
↓
检查日志
↓
分析增长来源
↓
告诉你：
是谁占了空间

这样既避免：

24 小时不停烧 Token

又保留 AI 的分析能力。

---

二十六、项目类 Cron 一定要注意 workdir

例如你想：

每天检查 /opt/my-api 项目

如果 Cron Prompt 只是：

检查当前项目。

可能会出现问题。

因为 Cron 默认并不会自动知道：

你当前 SSH 在哪个项目目录。

可以显式指定：

hermes cron create "daily at 9am" \
  "检查项目状态、Git 变化和测试结果。" \
  --workdir /opt/my-api \
  --name "my-api-check"

设置 workdir 后，Terminal、文件工具、代码执行等都会以这个目录为工作目录，而且该项目中的 AGENTS.md、CLAUDE.md、.cursorrules 等项目指令也会被加载。

这对：

代码项目
自动测试
自动 Review
定期 Git 检查

非常重要。

---

二十七、Cron Prompt 不要写得太模糊

不好：

检查服务器。

更好：

检查当前服务器健康状态。

检查范围：

1. uptime 和 load
2. CPU
3. 内存和 Swap
4. 所有磁盘和 inode
5. Docker 容器
6. failed systemd unit
7. 80/443 是否正常监听
8. https://example.com 是否正常

正常：
只回复 [SILENT]

异常：
说明异常指标、当前值、可能原因和建议。

禁止执行：
删除
重启
kill
修改配置
安装软件

Agent 越自动运行：

任务定义越应该明确。

因为凌晨三点时没有人在旁边回答：

“你刚才说的那个服务是哪一个？”

---

二十八、不要把所有检查塞进一个超级 Cron

比如：

每 5 分钟：

检查 CPU
内存
磁盘
网站
Docker
数据库
Minecraft
GitHub
天气
新闻
证书
备份
所有服务器
然后分析一遍

这种任务最后：

慢
贵
难排查
容易超时

更合理：

disk-watch
每 10 分钟
Script Only

↓

website-watch
每 5 分钟
Script Only

↓

server-health
每小时
Agent

↓

daily-summary
每天 09:00
Agent

↓

backup-check
每天 08:00
Agent

把不同性质的任务拆开。

---

二十九、一个比较合理的私人服务器方案

我会设计成：

每 5 分钟
网站 Ping / HTTP
→ Script

每 10 分钟
磁盘阈值
→ Script

每 30 分钟
CPU / Memory / Docker 基础指标
→ Script

每 2 小时
完整服务器巡检
→ Agent + Skill

每天 09:00
过去 24 小时日报
→ Agent

每天 10:00
证书 / Backup 状态
→ Agent

于是：

高频任务
→ 不烧 Token

低频复杂任务
→ AI 分析

这个结构通常比“每十分钟让大模型巡检所有东西”靠谱得多。

---

三十、Minecraft 也非常适合 Cron

例如：

每小时检查：

Minecraft 是否运行

当前玩家

最近是否有崩溃

TPS 是否异常

磁盘是否够

备份是否正常

创建：

hermes cron create "every 1h" \
  "检查 Minecraft 服务器运行状态。

检查：
- Java / Minecraft 是否运行
- 在线人数
- 最近错误日志
- 是否有 crash
- 磁盘空间
- 最近备份状态

如果正常回复 [SILENT]。

如果异常，只诊断并报告，不要自动重启服务器。" \
  --skill minecraft-server-maintenance \
  --name "minecraft-watch"

这样之前积累的：

Minecraft Skill

也就真正开始自动发挥作用。

---

三十一、每天生成一份服务器日报

这类任务很适合 Agent。

比如：

hermes cron create "daily at 9am" \
  "生成过去 24 小时服务器日报。

包括：
- CPU 和 load 是否异常
- 内存和 Swap
- 磁盘容量变化
- Docker 状态
- systemd 异常
- 网站可用性
- 重要日志异常
- 是否发生重启
- 需要关注的问题

即使完全正常，也生成一份简短日报。" \
  --skill server-health-check \
  --deliver qqbot \
  --name "server-daily-report"

每天早上：

09:00

收到：

📊 prod-1 每日运行报告

运行时间：
37 天 12 小时

CPU：
过去检查未发现持续高负载

Memory：
平均约 57%

Disk：
/        42%
/data    71%
较昨日 +1.3%

Docker：
12/12 正常

Systemd：
无 failed unit

Web：
正常

需要关注：
/data 近 7 天增长较快，
主要来自 backup。

这时候 Hermes 已经有点像：

AI 运维日报系统

了。

---

三十二、不要让同一个故障疯狂刷屏

例如网站挂了。

每 5 分钟巡检：

12:00 挂了
12:05 还挂着
12:10 还挂着
12:15 还挂着

最差设计：

每五分钟发一次。

Hermes 当前 Cron 已经会记录失败 Incident，并对重复的同类错误进行抑制，避免完全相同的问题每次运行都不停提醒；也可以通过配置控制持续失败后的重复提醒间隔。

即便自己设计监控 Skill，也建议加入状态判断：

第一次出现
→ 通知

持续存在
→ 不重复刷屏

恢复
→ 通知恢复

再次出现
→ 再通知

这样的监控才真正好用。

---

三十三、错误不等于“检测到异常”

这个区别也值得讲一下。

例如 Agent 成功执行完任务，并发现：

磁盘 95%

对于 Cron 系统来说：

Agent 本身其实执行成功了。

只是检查结果发现业务异常。

而如果：

模型 API 挂了
Agent timeout
代码抛异常

才属于 Cron Runtime Failure。

Hermes 当前还允许 Agent 用：

[CRON_FAILURE]

明确告诉调度器：

任务实际上没有完成。

这样会进入失败记录和 Incident。

一般普通用户不一定需要手动用，但理解这个区别对排障很有帮助。

---

三十四、如果连 Hermes 自己都挂了怎么办？

这是一个很现实的问题。

假设：

Hermes
↓
负责监控 Hermes 所在服务器

结果服务器直接：

死机

那么：

Hermes
Gateway
Cron

当然全部一起没了。

它不可能再告诉你：

“我挂了。”

这就是经典问题：

谁来监控监控器？

所以特别关键的可用性监控最好：

外部监控
+
Hermes

一起用。

例如：

外部 Uptime Kuma / 第三方监控
↓
负责：
机器活没活
网站通不通

Hermes
↓
负责：
为什么坏了
日志说明什么
应该怎么处理

Hermes 官方自己的 Script-Only Cron 文档也明确提醒：如果监控的是 Hermes/Gateway 所在主机本身，而要求“即使 Hermes 已经挂掉也必须告警”，应该使用独立的 OS Cron 或外部监控路径，而不能完全依赖 Gateway Scheduler。

---

三十五、最终推荐架构

一套比较舒服的个人运维系统可以变成：

                    外部监控
                   Uptime Kuma
                       │
                       ↓
                    存活检测


服务器
  │
  ├── Script Cron
  │      │
  │      ├── Disk
  │      ├── RAM
  │      ├── HTTP
  │      └── Port
  │
  └── Hermes Agent Cron
           │
           ├── 日志分析
           ├── Docker 分析
           ├── 故障诊断
           ├── 每日日报
           └── Skills
                  │
                  ↓
             Hermes Gateway
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
      QQ         飞书       企业微信

这里每一层负责不同的事情。

Script
→ 快、便宜、确定性

Agent
→ 理解、判断、总结

Gateway
→ 把信息送到你手上

Skill
→ 告诉 Agent 怎么干

Memory
→ 告诉 Agent 这是什么环境

这样 Hermes 的各个功能就真正串起来了。

---

三十六、这一篇最值得实际做的实验

如果你已经跟着前四篇做完，我建议今天先只创建两个任务。

第一个：

disk-alert

每 10 分钟。

使用：

No-Agent Script

磁盘 > 90% 才通知。

第二个：

server-health-check

每两小时。

使用：

Agent
+
server-health-check Skill

如果正常：

[SILENT]

异常：

QQ / 飞书通知

然后：

hermes cron list

确认任务存在。

接着：

hermes cron run disk-alert

以及：

hermes cron run server-health-check

先手动跑一遍。

确认：

执行
↓
工具调用
↓
结果
↓
消息投递

全部正常以后，再让它长期运行。

---

三十七、做到这里，Hermes 已经不只是聊天机器人了

现在回头看整个系列：

安装 Hermes
        ↓
配置模型
        ↓
Tool Calling
        ↓
Memory
        ↓
Skills
        ↓
QQ / 微信 / 飞书 Gateway
        ↓
Cron
        ↓
自动巡检
        ↓
主动通知

现在即使：

你一天都不和 Hermes 说话

它仍然可以：

检查服务器
检查网站
检查 Docker
检查备份
分析日志
生成日报
发现异常
主动联系你

这时候 Hermes 才真正开始从：

AI Chat

变成：

AI Agent

因为它已经拥有了：

环境
+
记忆
+
工作流程
+
工具
+
长期运行能力
+
主动任务
+
主动通知

而不是单纯：

你问一句
它答一句。

---

下一篇

做到这里以后，下一个非常自然的问题就是：

Hermes 能不能操作我自己的系统？

比如：

PVE
OpenWrt
NAS
Minecraft
自建面板
监控系统
Home Assistant
数据库
自建 API
内部业务平台

当然可以。

所以下一篇建议进入：

《Hermes Agent 入门（六）：MCP、自定义 Tools 与 API，让 Hermes 操作你自己的系统》

会实际讲：

MCP 到底是什么？

Hermes 怎么连接 MCP Server？

MCP 和 Skill 有什么区别？

MCP 和普通 API 有什么区别？

什么时候应该写 Skill？
什么时候应该写 Tool？
什么时候应该做 MCP？

怎么让 Hermes 查询 PVE 虚拟机？

怎么控制 OpenWrt？

怎么接 Minecraft 管理 API？

怎么让 Hermes 调用自己的 Web 系统？

Tool 权限怎么控制？

怎么避免 AI 获得无限权限？

还可以做一个完整案例：

QQ：

“看看 Minecraft 服务器现在有没有人。”

↓

Hermes

↓

Minecraft MCP / API

↓

在线玩家：
delilons
Player123

↓

QQ 回复


用户：

“没人以后 15 分钟关服。”

↓

Hermes

↓

调用管理 Tool

↓

设置关服任务

这一篇开始，就会从：

使用 Hermes 自带功能

进入：

把 Hermes 真正接进自己的基础设施。