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

基于 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 的网关进程内运行，从数据采集到处置通知形成一条完整的链路：

五项原生能力各就各位：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 系统提示的那层数据。多主机场景下，它会自动渲染成这样的格式：

shell 复制代码

## 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 步工作流：

规则引擎与 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 爆破事件的完整处置链

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

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

两种部署形态

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

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

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

形态 B：纯本地检测

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

选型参考

场景

建议形态

理由

| :-- | :-- | :-- |

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

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

多云混合或自建 IDC

检测与处置全部本地化

云主机 + 少量自建机

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 上不可缺少的一个环节。拿掉任意一项，链条就会断。

写在最后

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

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

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

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

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

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