# 告警至处置的自动化鸿沟：AI Agent 的破局思路探索

> 作者/来源: UCloud官方/历史归档
> 发布时间: 2026-05-20T07:53:16.000Z
> 分类: AI专区
> 标签: AI Agent, 安全防护, 自动化
> 原文链接: http://117.50.162.249:3000/yun/articles/2662

---

# 基于 Hermes-Agent 原生能力构建智能安全防护的研究与探索。

## 困境：从告警过载到处置断点

20 台云主机，每天 35 万次 SSH 暴力破解，20 个沉积数月未处置的木马告警，3万6444 个漏洞，其中 6 台主机受高危漏洞影响。

这组数字来自一个真实的生产环境。它说明的不是告警系统不灵敏，恰恰相反，它说明了一个安全运营领域的结构性矛盾：

**告警是持续产生的，人的注意力是稀缺的。**

检测工具越来越多，HIDS、WAF、EDR 各种告警源不断涌入。但在"检测"和"处置"之间，始终存在一条鸿沟：告警生成了，却没有被及时响应。不是安全团队不想处理，是真的处理不过来。

这篇文章介绍的，就是我们试验如何用一个本地 AI Agent 框架 **Hermes-Agent** 的原生能力，构建了一套名为 **Sentinel** 的安全防护子系统，来填补这条鸿沟。

## Hermes-Agent：不是 API，是持续在线的智能体

要理解 Sentinel 为什么能工作，先要理解它的载体。

Hermes-Agent 不是一个"调一次 API 拿个回答"的工具，而是一个**持续在线的本地 AI Agent 框架**。它运行在你的服务器上，作为一个常驻进程，具备五项关键的原生能力：

能力

一句话描述

**Hook（生命周期钩子）**在进程启动、会话开始等关键节点自动触发预注册的逻辑

**Memory（跨会话记忆）**在多次对话之间保持对事实、偏好、态势的持久记忆

**Tool（工具系统）**AI 的"手"：调用封禁 IP、隔离进程、查询情报等实际操作

**Skill（场景化技能）**将安全 SOP 编码成 AI 可读可执行的操作手册

**Cron（定时调度）**用自然语言描述任务目标，定时触发 AI 独立完成

Sentinel 就是在这五项能力之上构建的。它不是一个独立产品，而是 Hermes-Agent 的一个子系统：**用框架的原生能力，组合出一条"感知→判断→处置→记忆→复盘"的自治闭环**。

## 整体架构：一条完整的链路

先建立全局视图。整套系统在 Hermes 的网关进程内运行，从数据采集到处置通知形成一条完整的链路：

![](https://ucloud-blog.cn-bj.ufileos.com/articles/wechat/images/d6344d9f0a1aa609.png)

五项原生能力各就各位：Hook 负责启动和会话感知，Memory 负责跨会话持久化，Tool 负责实际执行，Skill 负责场景化决策流程，Cron 负责无人值守的定期巡检。

接下来逐一拆解。

## 能力一：Hook - 让安全防护"无感启动"

### 问题

安全监控最怕两件事：一是忘了启动，二是启动了但用户不知道当前态势。

### Hermes 怎么解决

Hermes 的 Hook 系统允许在进程生命周期的关键节点注册回调函数。Sentinel 利用了两个时机：

**启动时刻（gateway:startup）**：当 Hermes 网关进程启动，Sentinel 自动以后台线程拉起，初始化数据库、启动数据采集、注册定时任务、建立事件总线。整个过程与主线程并行，不阻塞正常对话。

**会话开始时刻（session:start）**：每当用户开启一次新对话，Sentinel 自动把过去 24 小时的安全摘要注入到 AI 的系统提示中。用户什么都不用问，AI 已经知道"过去一天有 3 条高危告警，封了 2 个 IP"。

还有一个不起眼但很重要的**第三个 Hook**：同样挂在 session:start 上，负责扫描 30 天前的未结案事件记录并自动清理，防止历史数据无限膨胀。

### 设计巧妙之处

这套机制的核心价值在于**反向控制**：Hermes 核心框架对 Sentinel 的存在完全无感，是 Sentinel 主动把自己挂载进来。这意味着安全模块可以独立部署、升级、甚至回滚，不需要动 Hermes 的一行主体代码。

从用户体验看，效果是**安全感知完全透明，**不需要记得"先查一下有没有告警"，AI 在对话开始时已经带着当前安全态势进入。

## 能力二：三层记忆 - 安全防护的"长期记忆"

### 问题

安全运营有一个隐性痛点：**今天的处置结论，明天就忘了**。谁加过白名单？为什么加的？上周那个事件处理到什么程度了？这些信息散落在工单系统、聊天记录、甚至某个人的脑子里。

### Hermes 怎么解决

Sentinel 把记忆拆成三层，各管各的：

**第一层：运行时事实（SQLite 数据库）**

存储每一条原始告警和处置后的威胁事件，附带主机标识、指纹哈希、CVSS 评分等结构化字段。指纹字段做唯一索引，同一来源的重复告警自动去重，不会反复触发处置。这一层还提供关联查询"这个 IP 过去 7 天有过攻击记录吗"，有的话当前告警自动升一个威胁等级。

**第二层：跨会话摘要（JSON 文件）**

存储已封禁 IP、最近的事件摘要、按主机分组的风险状态。这是被注入到 AI 系统提示的那层数据。多主机场景下，它会自动渲染成这样的格式：

-
-
-
-
-
-
-
-
-
-

```
`## Sentinel 主机安全状态（最近 24 小时）``覆盖主机: 19 台 | 活跃告警: 47 条 | 已封锁 IP: 12 个``### 🔴 ALERT  web-prod-01  [env=prod, role=web]``最高级别: HIGH | 事件数: 3``  · [HIGH] SSH 爆破成功，攻击源 1.2.3.4``### 🟡 WATCH  db-prod-03  [env=prod, role=db]``最高级别: MEDIUM | 事件数: 5``  · [MEDIUM] 基线配置违规 5 条``### 🟢 GOOD   app-prod-07  [env=prod, role=app]``最高级别: INFO | 事件数: 0`
```

AI 在接下来的对话里直接引用这份摘要，不需要再查一遍数据库。

**第三层：用户偏好（Markdown 文件）**

这是 Hermes 的 auto memory 系统。Sentinel 用它存两类信息：白名单变更历史（"谁在什么时间把哪个 IP 加白，理由是什么"）和未结案事件的当前状态（30 天自动清理）。

### 三层隔离的意义

事实层只追加、不覆盖；摘要层周期刷新、不积累；偏好层长期保留、有 TTL 兜底。**三层之间没有交叉写入路径，**告警事实不会误写进用户偏好，用户说的白名单也不会被当成攻击记录处理。

实际效果是：用户今天说"1.2.3.4 是我们合作方的 IP，不要封"，明天开新会话，AI 和关联引擎仍然记得这个决定。

## 能力三：工具系统 - AI 的"手"

### 问题

AI 再聪明，如果不能实际操作系统，就只能给建议、不能动手。安全处置偏偏是要动手封 IP、杀进程、回滚文件，一个都不能少。

### Hermes 怎么解决

Hermes 的工具系统采用"自动发现"机制：在指定目录下放一个工具文件，启动时通过语法树扫描自动识别并加载：新增工具不改配置，禁用工具注释一行。

Sentinel 注册了五个专用工具：

工具

职责

**sentinel_status**查询当前威胁态势：告警统计、近期事件、封锁 IP 列表，支持按主机过滤或聚合

**sentinel_monitor**触发即时扫描：端口、文件完整性、配置合规，发现异常自动生成告警

**sentinel_respond**执行处置动作：封禁 IP、隔离进程、回滚文件、紧急网络隔离

**sentinel_intel**IP 情报查询：是否为已知攻击者、历史记录、攻击次数统计

**sentinel_config**查看运行时配置：监控文件列表、扫描间隔、通知目标

### 关键分工

这五个工具构成了 AI 操作安全系统的"双手"，但设计上严格区分了两类判断：

- • **"应该做什么"** 由 AI（结合规则引擎）决定

- • **"怎么做"** 由工具里的确定性代码执行

AI 调用工具后拿到结构化的 JSON 结果，据此决定下一步动作。整条调用链是透明的：AI 的推理过程可审查，工具执行结果可追踪，审计日志不可篡改。

## 能力四：Skill - 把安全 SOP 变成 AI 可执行的操作手册

### 问题

安全团队不缺 SOP 文档。问题是 SOP 写在 Wiki 里，执行靠人记着。新人来了要培训，老人走了带走经验。

### Hermes 怎么解决

Hermes 的 Skill 系统可以把复杂的多步操作封装成 AI 能理解和执行的标准流程。用编程语言做类比：**AI 是解释器，Skill 里的 runbook 是脚本，工具是系统调用**。

我们研究实验中构建了名为 **security-guardian（AI 安全管家）** 的技能，覆盖 8 类安全场景：SSH 爆破、木马、WebShell、异常登录、恶意 cron、C2 外联、漏洞、基线违规。每个场景都有专属的处置手册（runbook），但内部统一遵循 **6 步工作流**：

![](https://ucloud-blog.cn-bj.ufileos.com/articles/wechat/images/12990a7713654b5e.png)

### 规则引擎与 AI 的边界

这里有一个非常关键的设计决策：**定级用规则，不用 AI**。

Step 2 里调用的规则引擎输出的是确定性的处置建议，逻辑是明确的：

- • 同一 IP 5 分钟内失败 ≥ 5 次 → 中危；≥ 20 次 → 高危

- • 爆破成功 → 高危；目标是 root / admin → 严重

- • 命中白名单 → 信息级，流程终止

- • 历史已知攻击者 → 当前级别 +1

这部分是确定的、可测试的、不会因为模型版本变化而漂移的。

AI 负责的是规则做不了的事：把结构化事实串成可读的事件叙述、推断攻击意图、评估残留风险、判断是否需要通知业务团队。这些是开放性的文本生成任务，适合 AI，不适合硬编码。

**分工清晰，各取所长：**关键处置路径的确定性由规则保证，叙述和推理的灵活性由 AI 提供。

### 主动感知

当新会话开始时注入的安全摘要显示最高告警级别 ≥ HIGH，AI 会在用户说第一句话之前主动询问："检测到高危安全事件，是否进入处置流程？"，这是 Hook（摘要注入）和 Skill（触发条件判断）协同工作的结果。

## 能力五：Cron - 不只是定时，是"会思考的巡检"

### 问题

传统 cron 跑的是固定命令：到点执行 `nmap`，输出到日志，有人看就看，没人看就沉没。扫到异常端口和扫到正常端口，处理方式完全一样，因为脚本不会判断。

### Hermes 怎么解决

Hermes 的 Cron 调度的不是命令，而是**自然语言描述的任务目标**。到点触发时，框架新建一个独立会话，把任务描述作为指令交给 AI，让它根据实际情况自主决定具体操作。

Sentinel 注册了三个永久任务：

任务

调度频率

目标

**端口巡检**每 6 小时

扫描监听端口，发现异常立即处置

**完整性验证**每天 02:00

文件完整性校验，发现篡改立即回滚

**态势日报**每天 08:00

汇总 24 小时安全数据，生成中文日报

关键区别在于：同样是端口扫描，发现一个新开放的 31337 端口和发现一个新开放的 8080 端口，AI 会做出完全不同的判断，前者大概率直接触发处置，后者可能只记录一条信息级告警。这是写死的 shell 脚本做不到的。

每次 Cron 执行的完整会话记录都被保留，比 shell history 更具可追溯性。任务注册做了幂等处理，网关重启不会重复创建。

## 案例：SSH 爆破事件的完整处置链

把五项能力串起来，看一次真实事件是怎么被自动处理的：

![](https://ucloud-blog.cn-bj.ufileos.com/articles/wechat/images/b119562f669aa4bf.png)

**从检测到处置：60 秒内完成。人类收到的不是"有个告警你去处理"，而是"已经处理好了，以下是详情"。**

## 两种部署形态

Sentinel 的数据采集层是可插拔的。不管数据从哪来，上层的五项能力逻辑完全一致。

### 形态 A：接入云端 HIDS（如 UCloud UHIDS）

通过云端 API 差分轮询告警，复用云厂商的木马查杀、漏洞匹配、异常登录画像等能力。优点是开箱即用、天然多主机视图；约束是绑定厂商，且 API 通常只返回统计数据，事件明细需要本地日志补充。

### 形态 B：纯本地检测

直接解析系统日志和 auditd 事件，检测规则以正则表达式维护。优点是零云依赖、规则可审计可修改、事件级原始信息；约束是威胁知识库（木马签名、WebShell 特征、C2 域名等）需要团队自主维护。

### 选型参考

场景

建议形态

理由

全部主机在同一云厂，已购 HIDS 服务

A

复用云端检测，Hermes 只做编排层

多云混合或自建 IDC

B

检测与处置全部本地化

云主机 + 少量自建机

A + B

各取所长

安全团队小，希望开箱即用

A

规则维护交给云厂商

对规则自治要求高

B

所有规则在代码仓库里，可审计可回归测试

**不变的部分**：无论哪种形态，Hermes-Agent 承担的"判断→处置→记忆→巡检→复盘"逻辑完全一致。HIDS 替换的只是采集层的一种实现。

## 三个关键设计决策

### 1. 自动处置是显式授权，不是失控

Sentinel 在中高危告警下直接执行处置，绕过了常规的人工审批流。这不是漏洞，是设计选择：安全防护的权威来自管理员在配置里启用 Sentinel 的那一刻，而不是每次封个 IP 都等一次点击。

但有两道安全线：

- • **每次处置都写入不可变的审计日志**，随时可查可追溯

- • **唯一保留人工确认的动作是全网络隔离**（network_lockdown），代价不可逆，必须人类拍板

### 2. AI 只做语义层，不做决策层

分析引擎在中危及以上级别才调用 AI，用途是提取结构化字段和生成可读摘要。**定级、关联、评分、处置路由全部是确定性代码，不经 AI**。

这保证了关键处置路径的确定性：无论 AI 模型怎么升级，同样的告警输入走同样的处置 Playbook。AI 的价值在于把事实串成"故事"，根因分析、风险推断、复盘报告，这些是硬编码做不了的。

### 3. 能力是组合的，不是堆砌的

这套系统的价值不在任何单项能力上。Hook 单独存在只是启动回调；记忆单独存在只是持久化存储；工具单独存在只是 API 封装。

**五项能力组合在一起，才形成了完整的自治闭环。** 拿掉 Hook，跨会话感知消失；拿掉 Skill，处置退化成单点操作；拿掉 Cron，巡检需要人触发；拿掉记忆，每次对话都是冷启动；拿掉工具，AI 没有"手"。

## 五项能力与安全 SOP 的对应关系

SOP 阶段

负责能力

关键产出

持续采集告警

数据采集层（适配器）

原始告警进入事件总线

去重 + 关联 + 评分

分析引擎层

威胁事件 + 等级判定

自动处置

**工具（Playbook 执行）**不可变审计日志

即时通知

**工具 + 通知层**IM 消息推送

跨会话态势感知

**Hook + **记忆****AI 系统提示注入安全摘要

无人值守巡检

**Cron + **工具****新告警注入主流程

场景化处置决策

**Skill + **工具** + **记忆****6 步流程完整产物

复盘报告生成

**Skill + 通知层**结构化报告 + 自动推送

记忆卫生

**Hook（TTL 清理） + **记忆****过期记录按时回收

每一项能力填补了 SOP 上不可缺少的一个环节。拿掉任意一项，链条就会断。

## 写在最后

这套系统不是要替代安全工程师，而是接管那些"机械性的值班工作"，持续监视、及时封禁、自动归档、按时巡检、定期出报告。

![](https://ucloud-blog.cn-bj.ufileos.com/articles/wechat/images/3fa9f360207db8e1.png)

**让 AI 做 AI 擅长的事，让人做人擅长的事。**

35 万次暴力破解，AI 可以 24 小时不间断地逐条处理。但"这个告警是不是误报"，"要不要通知业务方"，"这次事件暴露了什么架构问题"，这些判断，仍然需要安全工程师的专业经验。

Sentinel 的定位是**单机或小集群的 AI 值班副官**，不是 SOC/SIEM 的替代品。它的全部代码约 7,000 行 Python，分布在 80 个文件里，可以在任何 Hermes-Agent 实例上运行。

如果你也面对着告警堆积的困境，也许可以考虑一下：与其等着告警变成事故，不如让 AI 先把能处理的处理掉。

*本文基于 Hermes-Agent 开源框架和 Sentinel 安全子系统的实际实践撰写。文中涉及的真实环境数据已做脱敏处理。*