基于 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 系统提示的那层数据。多主机场景下，它会自动渲染成这样的格式：

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

---

写在最后

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

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

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

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

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

---

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