Hermes Agent 入门（四）：接入 QQ、微信、飞书、钉钉与企业微信，让 AI 7×24 小时在线

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

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

第二篇
配置 OpenRouter / 第三方 API / 本地模型
↓
让模型和 Tool Calling 正常工作

第三篇
Memory + Skills
↓
让 Hermes 开始积累长期记忆和工作经验

到目前为止，我们使用 Hermes 的方式基本还是：

SSH 登录服务器

↓

hermes

↓

开始聊天

这样当然能用。

但如果 Hermes 本身就运行在一台：

24 小时在线的 VPS

上，每次还专门 SSH 上去聊天，就有点浪费了。

更理想的形态应该是：

手机
 ↓
QQ / 微信 / 飞书 / 钉钉 / 企业微信
 ↓
Hermes Gateway
 ↓
Hermes Agent
 ↓
Memory + Skills
 ↓
Tools
 ↓
Linux / Docker / Web / API

于是你人在外面，只需要发一句：

检查一下服务器现在有没有异常。

Hermes 就可以在服务器上执行检查，然后把结果直接回复到手机。

这就是这一篇要做的事情：

把 Hermes 从一个 CLI Agent，变成真正 7×24 小时在线的私人 AI 助手。

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

---

一、现在 Hermes 已经原生支持不少国内平台

如果你之前看过比较早的 Hermes 教程，可能会发现大部分都在讲：

Telegram
Discord
Slack
WhatsApp

对于国内用户来说并不是特别方便。

但现在 Hermes Messaging Gateway 已经原生支持：

QQ Bot

微信 Weixin

企业微信 WeCom

飞书 Feishu

钉钉 DingTalk

腾讯元宝 Yuanbao

以及其他大量海外平台。官方 Gateway 可以同时加载多个 Adapter，由一个 Gateway 进程统一维护 Session、消息接收以及 Cron 任务。

所以现在已经可以直接做成：

                 ┌── QQ
                 │
                 ├── 微信
                 │
手机 / PC ─────→ Hermes Gateway
                 │
                 ├── 飞书
                 │
                 ├── 钉钉
                 │
                 └── 企业微信
                        ↓
                    Hermes Agent
                        ↓
                 Memory + Skills
                        ↓
                      Tools

而且这些并不是简单的“问答转发”。

QQ Bot、微信、企业微信、钉钉、飞书等 Hermes Gateway Toolset 都可以让 Agent 使用包括 Terminal 在内的完整工具集。

这意味着：

QQ 发消息
↓
Hermes 收到
↓
执行 Linux 命令
↓
分析日志
↓
继续调用工具
↓
把结果发回 QQ

完全可以实现。

---

二、国内用户应该选哪个平台？

先给一个简单的选择思路。

如果主要是：

自己个人使用

可以优先考虑：

QQ Bot
或
微信

如果是：

团队
工作
项目管理
服务器运维

我更推荐：

飞书
钉钉
企业微信

原因并不是 AI 能力不同。

真正执行任务的始终还是：

Hermes Agent

平台只是：

消息入口
+
消息出口

主要区别在：

机器人申请难度
群聊能力
权限控制
文件能力
消息格式
企业管理

---

三、我个人更推荐飞书作为第一套 Gateway

如果你只是想找一个：

配置比较正规
稳定
支持私聊
支持群聊
支持图片和文件
适合长期运行

的平台，我会更推荐先尝试飞书。

Hermes 当前对 Feishu / Lark 的支持比较完整，可以：

私聊

群聊 @机器人

图片

音频

视频

文件

Thread

Cron 通知

并且支持：

WebSocket

模式。

最大的好处是：

不需要给 Hermes 准备公网 Webhook。

Hermes 主动连接飞书服务器即可。

整个结构：

飞书
 ↑
 │ WebSocket
 │
Hermes VPS

所以即使 Hermes 在：

家庭服务器
NAT 后面
没有公网 IPv4

通常也可以使用。

---

四、配置飞书

首先运行：

hermes gateway setup

进入 Gateway 配置。

选择：

Feishu / Lark

目前官方推荐的配置方式已经支持扫码创建；如果自动创建不可用，也可以手动进入飞书开放平台创建应用，然后填写：

App ID

App Secret

并启用 Bot 能力。

手动方式对应的核心环境变量是类似：

FEISHU_APP_ID=cli_xxxxxxxxx

FEISHU_APP_SECRET=xxxxxxxxxxxxxxxx

这些凭据最终会由 Hermes Gateway 使用。

---

五、飞书机器人收到消息后怎么表现？

默认逻辑很符合正常聊天习惯。

私聊：

你：
检查服务器状态

↓

Hermes：
直接处理

不需要 @。

而在群聊：

张三：
今天服务器怎么样？

机器人默认不会插嘴。

只有：

张三：
@Hermes 检查一下服务器

才会触发。

而且 Hermes 默认可以让共享群里的不同用户拥有相互隔离的 Session，而不是所有人的上下文混到一起。

比如：

飞书群

├── 用户 A
│     ↓
│   Session A
│
├── 用户 B
│     ↓
│   Session B
│
└── 用户 C
      ↓
    Session C

这对于团队环境非常重要。

---

六、给飞书设置用户白名单

这是非常重要的一步。

例如：

FEISHU_ALLOWED_USERS=ou_xxxxxxxx

多个用户：

FEISHU_ALLOWED_USERS=ou_xxxxxxxx,ou_yyyyyyyy

这里填写的是：

Feishu Open ID

而不是显示昵称。

生产环境不要因为测试方便，就直接让任何能够联系到机器人的人都可以使用 Hermes。

因为对 Hermes 来说：

聊天机器人

背后可能实际拥有：

Terminal
文件
网页
浏览器
Memory
Skills
服务器环境

等能力。

官方也明确建议正式环境使用用户 Allowlist。

---

七、第二种：钉钉

如果平时本来就在使用钉钉，Hermes 现在也可以直接接。

而且钉钉同样有一个很适合自建 Agent 的特性：

Stream Mode

也就是：

Hermes
 ↓
主动建立 WebSocket
 ↓
钉钉

不需要：

公网 IP
域名
HTTPS
Webhook Server

官方当前就是通过钉钉 Stream Mode 实现实时双向通信。

---

八、配置钉钉

仍然从：

hermes gateway setup

开始。

选择：

DingTalk

创建好钉钉应用以后，主要需要：

Client ID / App Key

Client Secret

对应环境变量类似：

DINGTALK_CLIENT_ID=xxxxxxxx

DINGTALK_CLIENT_SECRET=xxxxxxxx

然后一定建议限制用户：

DINGTALK_ALLOWED_USERS=user-id-1,user-id-2

启动以后：

hermes gateway

Hermes 就会主动连接钉钉 Stream Gateway。

钉钉私聊中 Agent 会正常响应，而群聊默认通过 @Hermes 触发。

---

九、钉钉很适合做“运维机器人”

比如把 Hermes 放进一个：

服务器管理群

平时大家：

讨论问题

Hermes 不参与。

需要它时：

@Hermes
检查一下 API 服务器过去 30 分钟为什么出现这么多 502。

然后：

Hermes
 ↓
检查 nginx
 ↓
检查 upstream
 ↓
检查 Docker
 ↓
查看日志
 ↓
分析异常
 ↓
群里回复

这就比专门：

SSH
↓
复制日志
↓
发给 AI
↓
复制命令
↓
再 SSH 执行

方便很多。

---

十、第三种：QQ Bot

国内个人用户可能最感兴趣的还是：

QQ

Hermes 目前已经有官方 QQ Bot Adapter。

它使用的是：

腾讯官方 QQ Bot API v2

而不是：

NapCat

Lagrange

go-cqhttp

OneBot

Hook QQ 客户端

这样的第三方协议。

这一点要特别区分。

---

十一、Hermes QQ Bot 并不是登录你的普通 QQ

它不是：

输入 QQ 号
↓
扫码
↓
Hermes 变成你的 QQ 账号

而是：

QQ 开放平台
↓
创建 Bot Application
↓
获得 App ID
+
App Secret
↓
Hermes 登录 QQ Bot Gateway

所以它实际上是：

一个正规 QQ Bot

不是：

一个被程序控制的个人 QQ 号。

这两种东西完全不同。

如果以前玩过：

NapCat + OneBot

尤其要注意这一点。

---

十二、申请 QQ Bot

首先进入 QQ Bot 开放平台创建 Application。

Hermes 官方当前要求准备：

App ID

App Secret

并根据需要开启：

C2C Message

Group @ Message

Guild Message

等 Intent。

刚开始建议：

Sandbox Mode

先把机器人跑通。

等功能测试正常以后，再考虑发布正式环境。

---

十三、把 QQ Bot 接到 Hermes

还是：

hermes gateway setup

选择：

QQ Bot

然后填入：

App ID

App Secret

如果手动配置，则核心变量是：

QQ_APP_ID=your-app-id

QQ_CLIENT_SECRET=your-app-secret

然后限制用户：

QQ_ALLOWED_USERS=用户OpenID

如果需要群：

QQ_GROUP_ALLOWED_USERS=群OpenID

官方 QQ Adapter 当前通过 WebSocket 接收 Gateway 事件、REST API 回复消息，并且支持文本、Markdown、图片、语音以及文件等消息处理。

---

十四、QQ 还能直接发语音给 Hermes

QQ Adapter 当前还支持：

语音
↓
ASR / STT
↓
文字
↓
Hermes

因此理论上可以直接：

手机按住说话：

“帮我看看服务器现在磁盘还剩多少。”

然后：

QQ
↓
语音转文字
↓
Hermes
↓
执行 df -h
↓
分析
↓
回复 QQ

官方 QQ Bot Adapter 已经包含语音转写相关能力，可以使用腾讯内置 ASR 或额外配置 STT Provider。

这对于手机远程使用其实非常方便。

---

十五、接下来是大家最关心的：微信

Hermes 现在确实已经提供：

Weixin

Adapter。

而且这里说的是：

个人微信

不是：

企业微信。

官方目前通过腾讯的：

iLink Bot API

连接，并使用长轮询接收消息，因此同样不要求服务器拥有公网 Webhook。

---

十六、微信配置反而很简单

运行：

hermes gateway setup

选择：

Weixin

Hermes 会请求一个二维码。

然后：

手机微信
↓
扫一扫
↓
确认登录

完成之后，Hermes 会保存：

account_id
token
base_url

等信息。

凭据主要存放在：

~/.hermes/weixin/accounts/

中。

启动：

hermes gateway

即可开始接收消息。

---

十七、但是微信有一个非常大的限制

这一点一定要提前说。

扫码以后，Hermes 并不是：

完全控制你的普通个人微信号。

它连接的是：

iLink Bot Identity

类似：

xxxxxxxx@im.bot

这样的独立 Bot 身份。

因此不要期待：

我扫码登录我的微信

↓

以后所有微信好友都可以直接找 Hermes

↓

把这个微信号拉进任何普通微信群

↓

@我就是 @Hermes

实际并不是这样。

---

十八、尤其不要指望普通微信群完全可用

官方文档特别提醒：

iLink Bot

通常无法像普通微信联系人那样自由加入普通微信群。

而且对于多数 Bot 类型账号：

普通微信群消息

群 @

对扫码账号的 @

可能根本不会由 iLink 推送给 Hermes。

所以目前微信最现实的使用场景是：

微信
↓
直接私聊 iLink Bot
↓
Hermes

而不是把 Hermes 当成：

普通微信群机器人。

如果你最需要的是：

多人群聊机器人

那么：

飞书
钉钉
QQ Bot
企业微信

通常会更加合适。

---

十九、个人微信和企业微信不要混淆

Hermes 实际提供的是两套不同 Adapter：

Weixin
=
个人微信


WeCom
=
企业微信

个人微信：

腾讯 iLink Bot API
+
Long Polling

企业微信：

企业微信 AI Bot
+
WebSocket Gateway

两套完全不同。

---

二十、企业微信其实非常适合 Hermes

如果本来就有企业微信组织，那么 WeCom 是一个很不错的选择。

目前最简单的方式也是：

hermes gateway setup

选择：

WeCom

Hermes 现在支持扫码创建 AI Bot，也可以自己到企业微信管理后台创建。

主要凭据是：

WECOM_BOT_ID=your-bot-id

WECOM_SECRET=your-secret

用户白名单：

WECOM_ALLOWED_USERS=user_id_1,user_id_2

然后：

hermes gateway

即可。

WeCom AI Bot 同样使用 WebSocket，所以：

不需要公网 Webhook。

---

二十一、企业微信甚至有两种接法

Hermes 当前实际上支持：

WeCom Bot

以及

WeCom Callback

两种模式。

第一种：

WeCom Bot
↓
WebSocket
↓
Hermes

优点：

简单
不用公网 IP
支持群聊

适合大部分用户。

另一种：

企业微信自建应用
↓
Encrypted Callback
↓
Hermes
↓
message/send API

这种方式会让 Hermes 以：

企业微信自建应用

的形式存在。

但需要：

公网可访问 HTTP Endpoint

官方默认示例 Callback 地址类似：

http://YOUR_PUBLIC_IP:8645/wecom/callback

并涉及：

Corp ID
Corp Secret
Agent ID
Token
EncodingAESKey

等配置。

对于第一次使用，我建议：

先用 WeCom Bot。

除非你确实需要企业自建应用能力，再折腾 Callback。

---

二十二、Gateway 最重要的概念：它不只是“消息转发”

很多人可能会理解成：

QQ
↓
转给 Hermes CLI
↓
把结果发回去

实际上 Gateway 做的事情更多。

完整结构更像：

Messaging Platform

↓

Platform Adapter

↓

Gateway Runner

├── 用户授权
├── Session 管理
├── 消息附件
├── Home Channel
├── Cron Delivery
├── Gateway Commands
└── Platform Toolset

↓

AIAgent

├── Model
├── Memory
├── Skills
└── Tools

Hermes 官方 Gateway 本身就是整个消息平台接入层。

---

二十三、Gateway 和之前的 Memory、Skills 是连起来的

比如前一篇，我们告诉 Hermes：

Memory：

主服务器使用 Debian。

Docker 项目都在 /opt/docker。

任何重启服务的操作都必须先确认。

又创建：

Skill：

server-health-check

现在你直接在 QQ：

检查一下服务器有没有异常。

完整流程就是：

QQ

↓

Hermes Gateway

↓

恢复你的 Session

↓

读取 Memory

↓

发现 server-health-check Skill

↓

执行工具

↓

检查 CPU
Memory
Disk
Docker
Systemd

↓

分析

↓

QQ 回复结果

所以：

Memory
Skills
Gateway

其实并不是三个独立功能。

它们组合起来才真正形成：

长期在线的私人 Agent。

---

二十四、先前台运行，不要一上来就后台

Gateway 配置完成以后，我建议第一次先：

hermes gateway

或者：

hermes gateway run

前台运行。

然后从手机给机器人发送：

你好，只回复 Gateway 测试成功。

看看终端有没有收到消息。

确认：

消息进入
↓
Hermes 调用模型
↓
Agent 返回结果
↓
平台收到回复

全部正常之后，再配置后台运行。

---

二十五、把 Gateway 安装成 Linux 服务

在 VPS 上长期部署，就不能一直：

SSH
↓
screen
↓
hermes gateway

Hermes 已经提供 systemd 安装功能。

用户级服务：

hermes gateway install

启动：

hermes gateway start

查看：

hermes gateway status

停止：

hermes gateway stop

日志：

journalctl --user -u hermes-gateway -f

官方目前就是这样管理 Linux Gateway Service。

---

二十六、VPS 更推荐系统级 Gateway Service

如果是：

真正长期运行的 VPS

我更推荐：

sudo hermes gateway install --system

然后：

sudo hermes gateway start --system

查看：

sudo hermes gateway status --system

日志：

journalctl -u hermes-gateway -f

这种方式更适合：

服务器重启
↓
systemd
↓
自动拉起 Hermes Gateway

而不依赖用户登录状态。

官方也明确建议 VPS / Headless Host 优先考虑 System Service。

---

二十七、如果用 User Service，也能一直运行

另一种方案：

hermes gateway install

然后：

sudo loginctl enable-linger $USER

这样：

SSH 退出

以后 User Service 依然可以继续运行，并且能够在开机后恢复。

所以：

个人开发机
↓
User Service

长期 VPS
↓
System Service

是比较容易理解的选择。

---

二十八、千万别忽略 Gateway 权限

这一节可能是整篇最重要的地方。

假如 Hermes 可以执行：

ls
cat
docker
systemctl
curl
python
git

甚至：

sudo

那么一个能给 Hermes 发消息的人，本质上可能获得：

间接服务器控制能力。

比如有人给 Bot 发：

帮我读取 ~/.ssh/id_rsa。

或者：

把服务器上的配置文件发给我。

如果：

用户授权
+
Tool 权限

没有限制好，这会非常危险。

---

二十九、不要开全局 Allow All

Hermes 有：

GATEWAY_ALLOW_ALL_USERS=true

这样的配置。

但生产服务器上非常不建议这样做。

官方安全文档甚至特别把这一项标成需要极度谨慎使用。

对于私人 Hermes：

最简单的方法：

只允许自己的 User ID。

例如概念上：

QQ：
QQ_ALLOWED_USERS=自己的OpenID

飞书：
FEISHU_ALLOWED_USERS=自己的OpenID

钉钉：
DINGTALK_ALLOWED_USERS=自己的UserID

企业微信：
WECOM_ALLOWED_USERS=自己的UserID

这样最安全。

---

三十、Hermes 还有 Pairing 配对机制

如果不方便提前找 User ID，Hermes 还提供：

Pairing

模式。

例如一个未知用户第一次私聊：

用户
↓
Hermes
↓
返回 8 位 Pairing Code

然后服务器管理员：

hermes pairing approve <platform> <code>

批准。

之后：

该用户
↓
正式获得授权

官方 Gateway 当前就是通过这种机制解决动态用户授权问题。

对于小团队来说非常方便。

---

三十一、平台权限和系统权限是两层不同东西

这一点非常重要。

第一层：

谁能和 Hermes 说话？

由：

Allowlist
Pairing
Group Policy

控制。

第二层：

Hermes 能对服务器做什么？

由：

Hermes Tool
Terminal Backend
Linux User
sudo
Docker
SSH
Sandbox

控制。

所以正确设计应该：

用户
↓
Gateway Allowlist
↓
Hermes
↓
Tool Permission
↓
受限 Linux User
↓
服务器

而不是：

互联网任何人
↓
Hermes
↓
root

---

三十二、强烈建议不要直接给 Gateway Agent root

例如：

root 用户安装 Hermes
+
Terminal Backend = local
+
Gateway 对外开放

虽然非常方便，但安全边界非常差。

更合理：

hermes 用户

↓

只拥有必要目录权限

↓

必要的管理操作
通过 sudo 精确授权

例如 /etc/sudoers.d/hermes：

允许：

systemctl status nginx

docker ps

journalctl

而不是：

NOPASSWD: ALL

---

三十三、更加安全的方式：Docker Sandbox

如果主要让 Hermes：

写代码
分析文件
下载项目
跑脚本

可以考虑：

Hermes Agent

↓

Docker Terminal Backend

↓

隔离 Container

这样即使 Agent：

执行错命令
删除文件
安装奇怪软件

主要影响也限制在 Container。

如果需要管理真实服务器，则可以另外设计：

SSH Tool

↓

受限账户

↓

生产服务器

把：

Agent 环境

和：

生产环境

分开。

---

三十四、Gateway 可以同时连接多个国内平台

并不是：

配置了 QQ
↓
就不能用飞书

Gateway 本身就是多平台架构。

可以：

                QQ
                 │
                微信
                 │
               飞书
                 │
               钉钉
                 │
              企业微信
                 │
                 ↓
          Hermes Gateway
                 ↓
             Hermes

同时在线。

官方 Gateway 甚至提供：

/platform list

查看各 Adapter 状态。

还可以：

/platform pause <name>

临时暂停一个平台。

以及：

/platform resume <name>

恢复。

---

三十五、例如可以这样分工

个人：

QQ
↓
主要聊天

工作：

飞书
↓
项目和文件

公司内部：

企业微信
↓
团队使用

而：

Hermes
Memory
Skills
服务器环境

仍然是同一套。

以后甚至可以：

在 QQ 上告诉 Hermes：

把服务器检查结果发到飞书。

Gateway 本身已经具备跨平台消息架构。

---

三十六、Home Channel 是一个非常重要的概念

现在 Hermes 已经可以：

你找 Agent

但更有意思的是：

Agent 主动找你。

例如以后第五篇我们会配置：

Cron

每天：

09:00

检查服务器状态

如果发现：

磁盘 > 90%

Hermes 应该把结果发送到哪里？

这就是：

Home Channel

---

三十七、飞书可以设置 Home Chat

例如在飞书聊天中：

/set-home

即可把当前会话设为 Home Channel。

也可以：

FEISHU_HOME_CHANNEL=oc_xxxxx

以后：

Cron
后台任务
主动通知

就可以发送到这个会话。

QQ、企业微信、元宝等 Adapter 同样具有对应的 Home Channel 配置。

---

三十八、这样 Hermes 就从被动聊天变成主动 Agent

之前：

你：

检查服务器。

Hermes：

好的。

以后：

凌晨 03:20

Hermes 自动检查
↓

发现：

/data 91%

↓

发送 QQ / 飞书：

⚠️ prod-1 数据盘使用率达到 91%

主要占用：
Docker volumes 620GB
Backup 183GB

目前未执行清理操作。

这才真正开始体现：

7×24 小时 Agent

的意义。

---

三十九、我的国内平台推荐方式

如果只是自己玩：

QQ Bot

比较符合国内个人使用习惯。

但需要接受：

它是官方 Bot
不是个人 QQ 小号。

如果想要：

最完整
最稳定
群聊
文件
团队
自动化

我更倾向：

飞书。

如果公司本来就在：

钉钉

就直接用钉钉。

如果公司本来就是：

企业微信

直接 WeCom。

个人微信可以玩，但必须提前接受：

iLink Bot
≠
完全控制普通个人微信账号

以及普通微信群事件可能无法正常工作的限制。

---

四十、最终推荐架构

如果是自己搭一个私人 Hermes，我会设计成：

              手机

          QQ / 飞书

              ↓

      Hermes Gateway

              ↓

        Gateway Allowlist

              ↓

         Hermes Agent

     ┌────────┼────────┐
     ↓        ↓        ↓

   Memory   Skills    Session

              ↓

            Tools

     ┌────────┼────────┐
     ↓        ↓        ↓

    Web     Files    Docker

                       ↓

                 SSH / API

                       ↓

                 生产服务器

而不是直接：

QQ
↓
Hermes root
↓
生产服务器

这样既保留 Agent 能力，又有基本安全边界。

---

四十一、完整的新手配置流程

如果今天第一次配置，我建议按这个顺序。

首先确保 CLI 本身：

hermes

可以正常聊天和 Tool Calling。

然后：

hermes gateway setup

选择：

飞书 / QQ Bot / 钉钉 / 企业微信

只先配置一个。

接着：

hermes gateway

前台测试。

手机发送：

只回复“Gateway 测试成功”。

再测试：

查看当前服务器 uptime，
只告诉我运行时间，不进行任何修改。

全部正常以后，设置：

Allowlist

确认其他账号无法调用。

最后：

sudo hermes gateway install --system

sudo hermes gateway start --system

sudo hermes gateway status --system

检查：

journalctl -u hermes-gateway -f

确认 Gateway 在后台正常工作。

重启 VPS。

然后再从手机发：

/ping

或者普通消息。

如果仍然能够收到回复：

Hermes 7×24 小时 Gateway

就正式搭好了。

---

四十二、做到这里，Hermes 已经发生了很大变化

第一篇的时候：

Hermes
=
终端里的 AI

第二篇以后：

Hermes
=
可以自由切模型的 Agent

第三篇：

Hermes
=
拥有 Memory + Skills 的长期 Agent

到了这一篇：

Hermes
=
随时可以从手机联系的长期在线 AI

它现在已经开始有点像：

一个一直住在你服务器里的 AI 助手。

你不需要：

打开浏览器
↓
打开 AI
↓
复制日志
↓
解释服务器环境
↓
复制命令
↓
SSH 执行

而是：

QQ：

“Minecraft 服务器为什么卡？”

↓

Hermes：

查看系统
↓
查看 Java
↓
检查 TPS
↓
检查日志
↓
调用之前学会的 Skill
↓
分析
↓

QQ：

“主要异常是……”

Memory 让它知道：

你的服务器是什么。

Skills 让它知道：

应该怎么检查。

Gateway 则解决：

你随时随地怎么找到它。

三者结合以后，Hermes 才真正进入长期 Agent 的形态。

---

下一篇

现在还有最后一个非常关键的问题：

Hermes 还是只有你问它，
它才工作。

真正的 Agent 应该能够：

自己定时检查

↓

自己发现问题

↓

自己分析

↓

必要时主动找你

所以下一篇我们就进入：

《Hermes Agent 入门（五）：Cron、后台任务与自动巡检，让 AI 主动给你发消息》

实际实现：

每天 09:00
↓
自动检查服务器
↓
正常则记录
↓
异常则 QQ / 飞书通知


每 30 分钟
↓
检查 Minecraft
↓
发现没人在线
↓
按照 Skill 决定是否处理


每天凌晨
↓
检查 Docker
↓
检查磁盘
↓
检查证书
↓
检查备份
↓
生成日报


网站异常
↓
Hermes 分析
↓
主动发消息

做到这里：

聊天机器人

就会进一步变成：

长期运行
+
主动工作
+
主动通知
+
记住经验
+
可以调用真实工具

的个人 AI Agent。