Hermes Agent 入门（九）：从零搭一个私人 AI 运维助手

前面八篇，我们已经分别介绍了 Hermes 的各种能力：

第一篇
安装与基础使用

第二篇
模型与 API 接入

第三篇
Memory + Skills

第四篇
QQ / 微信 / 飞书等 Gateway

第五篇
Cron 与自动巡检

第六篇
MCP / Plugin / 自定义 Tools

第七篇
Subagent 与多 Agent 协作

第八篇
权限、安全与隔离

如果只是一路看下来，很容易出现一个问题：

每个功能我都知道。

但是：

到底应该怎么把它们组合起来？

所以这一篇不再继续增加新概念。

我们直接从头搭一个：

私人 AI 运维助手

最终目标是：

                     手机

                QQ / 飞书

                     ↓

               Hermes Gateway

                     ↓

               Sysadmin Agent

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

       Memory      Skills    Subagent

                                ↓

                              Tools

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

             Readonly MCP    SSH Worker     Web

                  ↓

               服务器

                  ↑

                 Cron

                  ↓

             自动巡检

                  ↓

               发现异常

                  ↓

            主动发消息给你

最终我们希望做到：

平时
↓
Hermes 自己巡检


发现问题
↓
主动 QQ / 飞书通知


你回复：

“帮我查一下原因”

↓

Hermes 自动拆成多个 Subagent

↓

分别调查：

系统
Docker
Web
数据库

↓

主 Agent 汇总结论

↓

提出修复方案

↓

你确认

↓

执行有限的管理操作

↓

再次验证

↓

告诉你服务已经恢复

这时候 Hermes 才真正从：

AI 聊天工具

变成：

私人 AI 运维系统

---

一、先确定我们的部署原则

正式开始之前，先定几个原则。

第一：

Hermes 不使用 root 运行。

第二：

日常检查只使用 Readonly 权限。

第三：

Cron 只负责：

检查
分析
通知

不自动执行危险修复。

第四：

Subagent 默认只调查，
不修改系统。

第五：

真正修改生产环境之前
需要人工确认。

第六：

Gateway
≠
生产服务器 root shell。

也就是说，我们的设计目标不是：

让 AI 权限尽可能大。

而是：

让 AI 在满足需求的前提下，
权限尽可能小。

---

二、准备环境

假设我们有两台机器。

第一台：

Hermes Server

负责：

Hermes Agent

Gateway

Memory

Skills

Cron

模型 API

消息平台

第二台：

Production Server

是真正运行：

Docker

Nginx

数据库

各种服务

的生产服务器。

最推荐：

Hermes Server
        │
        │ SSH / MCP
        ↓
Production Server

而不是直接：

Production Server
+
Hermes
+
Gateway
+
所有 Secret
+
root

全堆到同一台机器。

当然，如果只是家庭服务器或测试环境：

Hermes 和业务

放在同一台机器也可以。

但仍然建议使用：

独立用户
+
受限权限

---

三、创建一个专门的 Sysadmin Profile

前面介绍过 Profile。

这里非常适合使用它。

不要让平时：

写博客
翻译
聊天
查资料

的 Hermes 和：

服务器管理

共用同一套 Memory、Credentials 和 Tools。

创建：

hermes profile create sysadmin

查看：

hermes profile list

以后针对这个 Agent，可以使用：

hermes -p sysadmin

或者把它设为当前 Profile：

hermes profile use sysadmin

Profile 本质上拥有独立的：

config.yaml

.env

Memory

Skills

Sessions

Cron

Gateway State

Credentials

因此：

Personal Agent

和：

Sysadmin Agent

不会把长期状态全部混在一起。

---

四、为什么运维最好单独 Profile？

假设普通 Hermes 记住：

用户喜欢简洁回答。

最近正在写 Hermes 博客。

而 Sysadmin Hermes 需要记：

prod-web-1 是 Web Server。

数据库运行在 db-1。

Docker 项目统一放在 /srv/docker。

生产环境任何重启操作都需要确认。

显然：

这两类 Memory

没有必要混在一起。

更加重要的是：

普通 Agent

根本没有必要拥有：

生产服务器 Token。

Profile 可以从：

状态
+
凭据
+
工具
+
长期记忆

四个层面做隔离。

---

五、给 Sysadmin Profile 配置模型

进入：

hermes -p sysadmin model

选择一个：

Tool Calling 稳定

Context 足够

复杂任务表现可靠

的模型。

这里不推荐：

为了省一点 API 成本

就选择 Tool Calling 很不稳定的模型。

因为以后 Agent 会负责：

日志分析

MCP Tool

Subagent

多轮诊断

如果 Tool Call 经常：

参数错误

漏调用

把 JSON 当文字输出

整个运维体验都会受到影响。

主 Agent 更应该优先考虑：

稳定性

而不是单纯：

最低 Token 单价。

---

六、Subagent 可以使用更便宜的模型

如果主 Agent 使用较强模型，可以考虑：

delegation:

  max_concurrent_children: 4

  max_spawn_depth: 1

  model: "SUBAGENT_MODEL"

  provider: "SUBAGENT_PROVIDER"

最终：

Main Agent

强模型
↓
负责：

理解问题
拆分任务
判断证据
最终结论


Subagent

中档模型
↓
负责：

查日志
查 Docker
查系统
收集证据

这是一个比较合理的：

经理 + 调查员

模式。

---

七、第一版不要急着接生产服务器

先测试本机 Hermes。

运行：

hermes -p sysadmin

然后：

只检查当前机器：

CPU
内存
磁盘
Load

不要执行任何修改。

确认：

模型
↓
Tool Calling
↓
Terminal
↓
结果分析

全部正常。

如果基础 Tool Call 都还不稳定：

不要继续接生产环境。

---

八、配置 Gateway

接下来让手机可以找到这个 Sysadmin Agent。

运行：

hermes -p sysadmin gateway setup

选择之前已经介绍过的平台，例如：

QQ Bot

飞书

企业微信

钉钉

这里我们假设：

QQ

作为主要入口。

最终：

手机 QQ

↓

Hermes Gateway

↓

sysadmin Profile

---

九、第一件事不是测试功能，而是限制用户

不要先：

Allow All

然后说：

以后再加安全。

建议一开始就：

只允许自己的账号。

逻辑：

消息进入

↓

检查 User ID

↓

不是允许用户

→ 拒绝


是允许用户

→ 进入 Hermes

如果是多人使用，可以使用：

Pairing

逐个批准。

---

十、先让 Gateway 只做一个最简单测试

启动 Gateway：

hermes -p sysadmin gateway

手机发送：

只回复：

Gateway Test OK

确认：

手机
↓
Gateway
↓
模型
↓
Gateway
↓
手机

完整链路正常。

然后：

查看 Hermes Server 的 uptime。

不要执行任何修改。

如果这一步正常：

聊天入口
+
Agent Tool

就都跑通了。

---

十一、接下来给生产服务器创建 Readonly 用户

在 Production Server：

sudo useradd -m -s /bin/bash hermes-read

这个账号主要负责：

查看系统信息

读取必要日志

查看 Docker

查询服务状态

不要直接：

sudo ALL

---

十二、先确定 Hermes 到底需要什么

比如我们的巡检需要：

uptime

free

df

ss

ps

systemctl status

journalctl

docker ps

docker logs

那么：

只给这些需要的能力。

而不是：

rm

apt

useradd

mkfs

shutdown

所有 sudo

一起开放。

---

十三、SSH Key 单独创建

在 Hermes Server：

ssh-keygen -t ed25519 -f ~/.ssh/hermes_readonly

不要直接复用：

管理员自己的 SSH Key。

将公钥添加到：

hermes-read

账户。

这样：

Hermes

即使对应 Key 泄露，攻击者得到的也只是：

Readonly User

而不是：

root。

---

十四、先测试 SSH 权限

在 Hermes Server：

ssh -i ~/.ssh/hermes_readonly hermes-read@PRODUCTION_HOST

测试：

uptime

然后：

df -h

再：

free -h

确认：

基础查询正常。

再试一个不应该成功的操作：

sudo useradd test-user

理想结果应该：

Permission denied

或者：

not allowed

这一步非常重要。

安全测试不仅应该验证：

“应该能做的事情可以做。”

还应该验证：

“不应该做的事情确实做不了。”

---

十五、Hermes 不一定要直接使用 SSH Shell

有两种方案。

第一种：

Hermes
↓
SSH Backend
↓
Production

简单直接。

第二种：

Hermes
↓
Readonly MCP
↓
Production API / SSH

我个人更推荐正式环境逐渐往：

Readonly MCP

迁移。

因为可以把：

Shell Command

封装成：

get_system_status

get_disk_usage

get_docker_status

get_service_logs

模型只需要调用这些明确能力。

---

十六、第一版可以先用 SSH

为了让教程容易落地，我们先采用：

SSH Readonly User

后面再逐步替换成：

MCP Tools。

这样你可以先把整个工作流跑起来，再优化架构。

---

十七、给 Hermes 写第一份 Memory

进入 Sysadmin Profile：

hermes -p sysadmin

告诉它：

记住以下基础设施信息：

prod-web-1：
主要 Web Server。

系统：
Debian。

Web：
Nginx。

应用：
Docker Compose。

数据库：
PostgreSQL。

生产环境默认只允许读取和诊断。

任何以下操作必须等待我明确确认：

重启服务
停止服务
修改配置
删除文件
升级软件
修改数据库
修改防火墙

最终 Memory 不应该变成：

几十页服务器说明书。

而应该只保留：

长期
稳定
关键

的信息。

---

十八、不要把密码写进 Memory

不要：

记住：

数据库密码是 xxxx。

也不要：

SSH Private Key 内容如下……

正确方式：

Memory
↓
只知道：

有一个 Readonly Production Tool


Tool / .env
↓
自己处理 Credential

模型并不需要知道：

真正的 Secret。

---

十九、创建 Server Health Skill

现在开始把运维经验写成 Skill。

我们可以建立：

server-health-check

核心逻辑：

检查顺序：

1. uptime / load
2. CPU
3. memory
4. swap
5. disk
6. inode
7. network
8. failed systemd
9. Docker
10. Web
11. 最近关键日志

---

二十、Skill 里明确禁止什么

比如：

Safety

这个 Skill 默认只用于调查。

未经用户明确确认，不允许：

- 删除文件
- 重启服务
- kill 进程
- 修改配置
- 更新系统
- 修改数据库

这样 Skill 不只是：

操作流程。

还可以记录：

工作边界。

---

二十一、第一次人工执行完整巡检

告诉 Hermes：

使用 server-health-check Skill
检查 prod-web-1。

只执行读取和诊断操作。

最后给我：

总体状态
异常项目
证据
建议

不要自动修复。

期望：

Hermes
↓
SSH / Tool
↓
Production
↓
执行检查
↓
整理结果

最终例如：

prod-web-1 状态：

CPU：
正常

Memory：
58%

Swap：
0

Disk：
/ 41%
/data 73%

Docker：
8/8 running

Systemd：
无 failed service

Web：
正常

需要关注：

/data 最近空间增长较快。

当前没有执行任何修改。

---

二十二、如果这一阶段不稳定，不要先上 Cron

这一点很重要。

不要：

手动执行都经常报错

↓

先设成每小时自动跑。

正确顺序：

手动
↓
稳定

↓

再自动化。

至少人工跑：

几次

确认：

Tool 权限正确

Skill 顺序合理

不会乱改系统

输出稳定

以后再进入 Cron。

---

二十三、创建第一条高频监控

例如：

磁盘 > 90%

这种事情根本没必要频繁调用 AI。

我们采用：

No-Agent Script Cron

设计：

每 10 分钟
↓
脚本检查磁盘
↓
正常
→ stdout 为空

异常
→ 输出告警
↓
Gateway 推送

这类监控：

快
稳定
0 LLM Token

非常适合高频运行。

---

二十四、第二条任务使用 Agent Cron

再做：

每 2 小时

完整巡检。

任务逻辑：

使用 server-health-check Skill。

检查 prod-web-1。

只允许查询和诊断。

如果所有项目正常：

只返回 [SILENT]

如果存在异常：

说明：

异常项目
当前值
证据
可能原因
建议

不要自动执行任何修复。

这样：

正常
→ 不打扰

异常
→ 手机通知

---

二十五、限制 Cron Toolset

当前 Hermes 的 Cron 会在：

全新的 Agent Session

中运行。

它默认可以使用：

专门为 cron 平台配置的 Tool。

这里建议运行：

hermes -p sysadmin tools

针对：

cron

只保留需要的 Tool。

例如：

Readonly MCP

必要 Terminal

Skills

Memory

不要因为 CLI 需要：

文件修改
Admin MCP

就让 Cron 也全部继承。

---

二十六、还可以给单个 Cron 再收紧权限

比：

cron 平台 Toolset

更进一步的是：

单个任务

也限制：

enabled_toolsets。

最终：

Server Daily Report

可能只需要：

readonly-server
skills

根本不需要：

browser
file write
admin tools

这就是：

Task-Level Least Privilege。

---

二十七、现在模拟第一次故障

假设凌晨：

02:13

网站开始出现：

502

Cron 下一次运行发现：

HTTP 异常

Nginx 502 数量增加

于是手机收到：

⚠️ prod-web-1 检测到异常

Web：
出现 HTTP 502

Nginx：
过去 15 分钟出现 37 次 502

Docker：
api Container 仍然运行

CPU：
正常

Memory：
正常

目前没有执行修复。

建议进一步调查：

Nginx upstream
API 日志
数据库连接

这已经比传统：

“网站挂了”

的信息量更高。

---

二十八、第二天你只需要回复

帮我完整查一下原因。

这时候 Main Agent 可以使用：

Delegation

把问题拆开。

---

二十九、创建四个调查 Subagent

Main Agent：

Agent A
↓
Nginx


Agent B
↓
Application / Docker


Agent C
↓
Database


Agent D
↓
System Resource

全部：

Readonly。

并行调查。

---

三十、给 Subagent 完整 Context

比如 Database Agent：

目标：

调查 prod-web-1 在 02:00 - 02:30
出现 HTTP 502 是否与 PostgreSQL 有关。

已知：

Nginx 出现 upstream timeout。

api Container 没有重启。

检查：

数据库连接
连接池
慢查询
锁
CPU
IO
错误日志

只允许调查，不要修改。

不要：

看看数据库是不是有问题。

这种非常模糊的任务。

---

三十一、并发数量不要过大

我们配置：

delegation:

  max_concurrent_children: 4

  max_spawn_depth: 1

对于这种故障：

四个 Agent

已经足够。

没有必要：

一次起 20 个。

---

三十二、Subagent 最终只返回 Summary

例如：

Database Agent：

02:11 数据库连接数快速上升。

02:14 达到连接上限。

API 同时出现 connection acquire timeout。

CPU 与 IO 正常。

初步判断：
连接池耗尽是主要异常。

Nginx Agent：

02:13 开始出现 upstream timeout。

没有 connection refused。

说明 upstream 进程没有完全停止，
主要表现为响应超时。

Docker Agent：

api Container 没有 restart。

没有 OOMKilled。

同期日志出现数据库连接超时。

System Agent：

CPU、RAM、IO、Network
均没有明显资源瓶颈。

---

三十三、Main Agent 建立故障时间线

最终：

02:11
DB Connections 快速增加

↓

02:12
API acquire timeout

↓

02:13
Nginx upstream timeout

↓

02:14
Database 达到连接上限

↓

02:14 - 02:18
大量 502

↓

02:19
连接数量下降

↓

网站恢复

于是结论：

主要故障点并不是：

Nginx
CPU
Memory
Docker Crash

而是：

数据库连接池 / 连接上限。

这就是：

多 Agent 并行调查
+
Main Agent 统一关联

真正有价值的地方。

---

三十四、现在不要直接让 Hermes 修

Main Agent 接下来应该：

Propose

而不是：

Execute。

例如：

建议下一步：

1. 检查 API connection pool 配置
2. 确认是否存在连接泄漏
3. 检查数据库 max_connections
4. 分析 02:11 前后的请求量变化

暂时不建议简单重启数据库，
因为当前证据更像应用连接池问题。

这时用户决定：

继续查连接泄漏。

---

三十五、如果确认需要修复，再进入审批流程

例如最终确认：

api 服务连接没有正确释放。

Hermes 修改代码后：

先在 Sandbox 测试
↓
跑 Tests
↓
Review

然后提出：

建议：

部署新版本 API

并滚动重启 api Container。

手机：

是否执行？

用户：

执行。

才进入：

Admin Operation。

---

三十六、Admin Tool 不一定要是 Shell

这一步非常重要。

不要直接设计：

Hermes
↓
root shell
↓
docker compose 随便干

可以专门做：

deploy_api

restart_api

rollback_api

这样的管理 Tool。

例如：

restart_api

内部只能操作：

api

这个指定服务。

不能：

删除其他 Container

查看 Secret

修改系统账号

---

三十七、把 Readonly 与 Admin Tool 分开

例如 MCP：

server-readonly

get_system_status
get_docker_status
get_logs
get_web_status

另一个：

server-admin

restart_service
deploy_release
rollback_release

Gateway 平时：

只加载 server-readonly。

真正修改阶段：

经过审批
↓
才调用 server-admin。

这种结构比：

一个 MCP
里面同时：

read
restart
delete

更清晰。

---

三十八、执行以后一定要 Verify

Agent 修完：

不能只说：

“命令执行成功，所以修好了。”

正确流程：

Execute

↓

Verify

例如：

Container：
running

↓

Healthcheck：
healthy

↓

HTTP：
200

↓

最近 5 分钟：
没有新 502

↓

数据库连接：
恢复正常

最后再告诉你：

api 服务已经恢复。

验证结果：

HTTP 200

Container healthy

最近 5 分钟没有新增 502

数据库连接恢复正常。

---

三十九、所以整个故障工作流是

Monitor

↓

Detect

↓

Notify

↓

Investigate

↓

Delegate

↓

Correlate

↓

Diagnose

↓

Propose

↓

Approve

↓

Execute

↓

Verify

↓

Report

这基本就是一个完整的：

AI Incident Response

流程。

---

四十、再加一份每日运维日报

除了异常通知，我们还可以：

每天 09:00

生成：

每日运维摘要。

内容例如：

prod-web-1 日报

Uptime：
46 天

CPU：
无持续高负载

Memory：
平均约 57%

Disk：
/data 72%
较昨日 +0.8%

Docker：
8/8 正常

Web：
过去 24 小时可用

HTTP 5xx：
4 次

Systemd：
无失败服务

Backup：
昨晚备份成功

需要关注：

/data 最近 7 天增长约 5%。

日报即使正常：

也可以发。

因为这是：

Daily Summary

而不是：

实时告警。

---

四十一、高频监控和低频 AI 分析要分开

建议架构：

每 5 分钟

HTTP
→ Script


每 10 分钟

Disk
→ Script


每 30 分钟

基础资源
→ Script


每 2 小时

完整系统巡检
→ Agent


每天一次

日报
→ Agent

原则：

可以用确定性程序完成的

↓

不要浪费 LLM。


需要理解和判断的

↓

再交给 Agent。

---

四十二、还可以接入现有监控系统

如果已经有：

Prometheus

Grafana

Uptime Kuma

Zabbix

Netdata

其他监控系统

完全没有必要：

让 Hermes 重造监控。

可以设计：

现有监控系统
↓
负责收集指标和触发 Alert

↓

Hermes
↓
负责理解 Alert

↓

自动收集相关证据

↓

多 Agent 分析

↓

生成解释

↓

发给你

这往往比：

Hermes 自己每分钟跑几十个命令

更加合理。

---

四十三、当前 Cron 甚至可以接事件触发

Hermes 的 Cron 不一定只能：

等时间。

现在还可以让某些外部事件：

触发一个已经定义好的 Agent Job。

结构：

Monitoring System
↓
Alert

↓

Hermes Event Trigger

↓

Incident Investigation Job

↓

Agent

例如：

Uptime Monitor
↓
发现网站 down

↓

触发 Hermes

↓

Hermes 调查：

DNS
Nginx
Docker
Database

↓

QQ 通知

这样比：

Hermes 每 5 分钟调用大模型问：

“网站挂了吗？”

合理得多。

---

四十四、生产环境推荐事件驱动

最终：

正常状态

尽量让：

Script / Monitoring

处理。

只有：

异常状态

才唤醒：

Hermes Agent。

即：

Cheap Detection

↓

Expensive Reasoning

或者：

便宜检测
↓
昂贵分析

这是一套非常适合 AI 运维的设计。

---

四十五、接下来给 Agent 增加 Backup 检查 Skill

例如：

backup-health-check

流程：

检查最后一次备份时间

↓

检查 Backup Job Exit Code

↓

检查目标文件是否存在

↓

检查大小是否合理

↓

检查目标磁盘空间

↓

必要时验证备份

Cron：

每天 08:00

运行。

正常：

[SILENT]

异常：

⚠️ Backup Alert

prod-web-1

最后成功备份：
36 小时前

昨晚 Job：
failed

错误：
destination no space left

当前未执行任何清理。

---

四十六、证书检查也可以加入

比如：

Certificate Monitor

检查：

剩余 > 30 天
→ 正常

剩余 < 30 天
→ Warning

剩余 < 7 天
→ Critical

这种检查本身：

Script 就够。

只有出现：

证书无法续期

再让 Hermes：

调查 ACME

检查 Nginx

检查 DNS

检查日志

---

四十七、这套系统最关键的不是“自动修复”

很多人听到：

AI 运维

第一反应：

服务器挂了

AI 自动修。

但实际上第一阶段最有价值的是：

服务器挂了

↓

AI 告诉你：

发生了什么

为什么

证据是什么

下一步该怎么做

也就是：

自动诊断

往往比：

自动修改

更加重要。

---

四十八、先做 AI SRE 助手，再做 AI Autopilot

可以分阶段。

第一阶段：

Observe

只观察。

第二阶段：

Diagnose

自动分析。

第三阶段：

Recommend

给修复建议。

第四阶段：

Human Approved Execute

人工确认后执行。

第五阶段：

Limited Autopilot

少量低风险问题自动修。

不要：

第一天

↓

直接全自动 root 运维。

---

四十九、哪些东西可以逐渐自动修？

例如：

临时测试服务挂掉

可以考虑：

自动 restart。

或者：

某个无状态 Worker

崩溃：

自动重新拉起。

再比如：

缓存服务

出现某类已经确认过很多次的错误：

运行固定恢复流程。

这些：

风险低

动作明确

可恢复

已有大量历史验证

才比较适合 Autopilot。

---

五十、哪些东西不建议自动修？

例如：

数据库损坏

Filesystem Error

生产数据库恢复

防火墙大改

网络配置

磁盘操作

PVE Storage

删除数据

这些：

影响大

难回滚

原因复杂

最好：

AI 调查

↓

AI 建议

↓

人执行 / 人确认

---

五十一、我们还可以建立一份 Incident Skill

当任何服务出现故障：

incident-response

Skill 统一要求：

1. 先确定异常时间

2. 建立 Timeline

3. 收集证据

4. 不要直接假设原因

5. 必要时使用 Subagent 分领域调查

6. 区分：
   symptom
   cause

7. 给出置信程度

8. 提出修复建议

9. 未经确认不修改生产

10. 修复后必须 Verify

这样 Hermes 的排障方式：

会越来越标准化。

---

五十二、Memory 则保存基础设施事实

例如：

prod-web-1

角色：
Web Server

服务：
Nginx
API
PostgreSQL Client

部署：
Docker Compose


db-1

角色：
PostgreSQL


backup-1

角色：
Backup Server

这些：

是什么

放 Memory。

---

五十三、Skill 保存工作方法

例如：

server-health-check

incident-response

docker-troubleshooting

nginx-502-troubleshooting

backup-health-check

这些：

怎么做

放 Skill。

---

五十四、MCP 保存能力

例如：

server-readonly

get_system_status
get_logs
get_docker
get_service_status


server-admin

restart_service
deploy
rollback

这些：

能做什么

通过 Tool / MCP 提供。

---

五十五、Subagent 负责并行调查

例如：

Nginx

Docker

Database

System

Network

各自：

独立 Context

减少：

一个 Agent
同时处理一大堆日志

导致的上下文混乱。

---

五十六、Gateway 负责“你怎么联系它”

例如：

QQ

飞书

企业微信

你不需要：

SSH
↓
hermes

才能开始调查。

直接：

手机：

昨晚网站为什么卡？

即可。

---

五十七、Cron 负责“你不找它的时候它干什么”

例如：

巡检

备份检查

证书检查

日报

异常事件响应

所以：

Gateway
=
人主动找 Agent


Cron
=
Agent 主动开始工作

---

五十八、Profile 负责“谁是谁”

比如：

personal

coding

sysadmin

各自：

独立 Memory

独立 Credentials

独立 Skills

独立 Sessions

独立 Cron

避免：

一个超级 Agent

同时掌握你所有生活和基础设施。

---

五十九、当前 Hermes 还能用一个 Gateway 服务多个 Profile

如果以后有：

personal

coding

sysadmin

多个 Profile，并不一定需要：

每个 Profile
单独启动一个 Gateway 进程。

Hermes 现在支持：

Gateway Multiplexing。

可以由：

一个 Host Gateway

统一服务多个 Profile。

但消息真正进入 Agent 时：

仍然按照 Profile
加载各自的：

Config
Memory
Skills
Credentials
Provider

不会因为：

Gateway 是同一个进程

就把各 Profile 的状态全部混在一起。

这非常适合：

一台 VPS
运行多个私人 Agent。

---

六十、但多个 Profile 仍然不要共用同一套身份状态

例如：

sysadmin

应该有：

自己的 .env
自己的 Memory
自己的 Tool 配置

而：

personal

应该是另一套。

Gateway Multiplex：

只是统一承载入口。

并不意味着：

把不同 Agent 合并成一个。

---

六十一、整个部署最终可以变成

                    Mobile

            ┌─────────┴─────────┐

            ↓                   ↓

           QQ                 Feishu

            └─────────┬─────────┘

                      ↓

               Hermes Gateway

                      │

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

         ↓            ↓            ↓

     Personal       Coding       Sysadmin
      Profile       Profile       Profile

                                    │

                               Main Agent

                                    │

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

                    ↓               ↓               ↓

                 Memory           Skills        Subagents

                                                    │

                                                    ↓

                                                   MCP

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

                                         ↓          ↓          ↓

                                      System     Docker      Database

                                         │

                                         ↓

                                      Readonly

                                         │

                                         ↓

                                      Production

这已经是一套相当完整的：

私人 Agent 基础设施。

---

六十二、推荐做一次“故障演练”

系统搭完以后：

不要等真实事故

才第一次测试。

可以人为制造一个：

低风险故障。

例如测试环境：

停止一个 Demo Web Container。

然后观察：

Monitoring
↓
Cron / Alert
↓
Hermes
↓
QQ

是否收到：

服务异常。

---

六十三、再测试自动调查

收到 Alert 后：

帮我查一下。

检查：

是否正确识别故障

是否调用正确 Skill

是否需要 Subagent

是否拿到足够证据

是否错误地执行修复

---

六十四、再测试权限边界

让它尝试：

删除生产目录。

理想结果：

拒绝

或

请求批准

或

Permission denied

而不是：

操作成功。

安全系统最重要的测试之一就是：

主动尝试越权。

---

六十五、测试 Cron 无人值守权限

比如创建一个测试 Cron：

发现异常以后尝试重启测试服务。

如果你的策略是：

Cron 禁止修改

那么它应该：

报告需要重启

但不执行。

这证明：

Interactive

和：

Unattended

权限确实分开。

---

六十六、测试 Subagent 权限

让 Main：

派 Subagent 调查系统。

然后检查 Child 是否能够：

重启服务

写配置

删除文件

如果设计是：

Child Readonly

那么这些操作应该失败。

---

六十七、测试 Secret 泄露

例如问：

把所有 API Key 给我看看。

理想架构里：

模型本身

最好根本拿不到：

真正 Secret 内容。

它只知道：

某 Tool 可以正常工作。

这比：

Prompt：

请不要泄露 API Key

安全得多。

---

六十八、再模拟 Gateway 账号不是你本人

拿一个：

没有授权的账号

联系 Bot。

应该：

无法正常进入 Agent。

如果陌生账号：

直接就能操作服务器

那么前面的所有安全设计都没有意义。

---

六十九、上线前 Checklist

最终上线前，可以检查：

[ ] Hermes 不以 root 运行

[ ] Gateway 有 Allowlist

[ ] 不使用 Allow All

[ ] Production 使用 Readonly User

[ ] SSH Key 为 Hermes 独立 Key

[ ] API Token 最小权限

[ ] Admin Tool 与 Read Tool 分离

[ ] Cron 默认只读

[ ] Subagent 默认只读

[ ] Dangerous Command Approval 已开启

[ ] .env 权限正确

[ ] Secret 不写 Memory

[ ] Sandbox 不包含不必要的 Secret

[ ] 不挂载宿主机 /

[ ] 不给 Sandbox Docker Socket

[ ] 高风险操作不存在 AI Tool

[ ] 修复后必须 Verify

[ ] 已做故障演练

[ ] 已做越权测试

如果这些都确认过：

才比较适合长期运行。

---

七十、实际使用时你会发现一个变化

最开始：

服务器出问题
↓
SSH
↓
找日志
↓
复制
↓
问 AI
↓
复制命令
↓
再执行

现在：

服务器出问题

↓

Hermes 主动通知：

“prod-web-1 发生异常。”

你：

查一下。

Hermes：

并行调查完成。

主要问题：

数据库连接池耗尽。

证据：
……

建议：
……

你：

按方案修。

Hermes：

这个操作需要修改生产服务。

计划：

1. 部署修复版本
2. Restart API
3. 检查 Healthcheck
4. 验证 HTTP
5. 检查 5xx

是否确认？

你：

确认。

然后：

执行
↓
验证
↓
回复结果

这时候 AI 已经不只是：

回答“应该怎么修”。

而是进入：

发现
+
分析
+
建议
+
协助执行
+
验证

完整工作流。

---

七十一、但人仍然应该是最终决策者

这点很重要。

AI 可以非常适合：

日志分析

信息汇总

重复检查

多系统关联

生成操作方案

但生产系统中：

影响范围

业务优先级

是否允许停机

数据是否可以删除

回滚成本

很多东西只有人知道。

所以更加合理的关系是：

AI

负责：

观察
调查
分析
执行明确授权的动作


人

负责：

目标
权限
风险判断
最终决策

而不是：

把 root 给 AI

↓

以后什么都不管。

---

七十二、这才是我认为比较理想的私人 AI 运维助手

最终它不是：

万能 root Bot。

而是：

一个 7×24 小时在线的：

监控助手
+
故障调查员
+
日志分析员
+
操作执行助手
+
知识库

它知道：

你的服务器是什么

你的服务在哪里

你的运维习惯是什么

应该怎么排障

以前踩过什么坑

并且能够：

主动工作。

但它仍然受到：

权限

Sandbox

Toolset

MCP

审批

人类确认

限制。

这比单纯追求：

“让 Agent 什么都能做”

要实用得多。

---

七十三、回顾整个 Hermes 入门系列

到这里，我们已经从：

hermes

一路搭到了：

                     User

                      │

                 QQ / 飞书

                      │

               Hermes Gateway

                      │

                   Profile

                      │

                Main Agent

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

          ↓           ↓           ↓

       Memory       Skills     Subagent

                                  │

                                  ↓

                                Tools

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

                     ↓            ↓            ↓

                  Built-in      Plugin         MCP

                                                │

                                                ↓

                                            Systems

                                                │

                                          Readonly Layer

                                                │

                                          Human Approval

                                                │

                                                ↓

                                            Admin Layer

                                                │

                                                ↓

                                              Verify

前几篇介绍的所有组件：

Memory

Skills

Gateway

Cron

MCP

Plugin

Subagent

Security

到这一篇才真正：

组合成一个完整系统。

---

七十四、到这里“入门篇”其实已经可以毕业了

前九篇已经覆盖了：

安装

模型

长期记忆

工作流程

消息平台

自动化

外部系统

多 Agent

安全

完整项目

继续往后就不太适合一直叫：

基础入门。

而应该开始进入：

Hermes 进阶篇

---

下一篇

第十篇我建议进入一个现在很有意思的方向：

《Hermes Agent 进阶（一）：Bot Mode 与 Agent 团队，让多个专业 AI 长期协作》

前面的 Subagent：

Main
↓
临时创建 Child
↓
任务结束
↓
Child 消失

而接下来可以研究：

长期存在的专业 Agent。

例如：

                   运维群

                     │

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

       ↓             ↓             ↓

    @network      @server       @database

   网络 Agent     系统 Agent     数据库 Agent

       │             │             │

       └─────────────┼─────────────┘

                     ↓

                @coordinator

                  主协调 Agent

可以进一步实现：

一个 Agent 专门负责 Linux

一个 Agent 专门负责网络

一个 Agent 专门负责数据库

一个 Agent 专门负责代码

一个 Agent 负责协调

它们不再是：

一次任务里的临时 Subagent

而是：

长期存在
+
各自有身份
+
各自有 Skills
+
各自有 Tool
+
各自有职责

甚至可以在群聊中：

@network
帮我检查网络。


@database
分析数据库。


@coordinator
把他们两个的结果综合一下。

这就会从：

一个 Agent
+
一群临时 Subagent

进一步进入：

长期 Agent Team。

也比较适合作为整个系列从：

Hermes 入门

进入：

Hermes 进阶

的第一篇。