运维自动化：AI+RPA 结合大模型，实现系统巡检与告警处理自动化实践

凌晨两点，告警电话再次响起。某台核心节点的磁盘使用率突破 95%，值班工程师从被窝里起来，登录堡垒机、敲命令、清日志、回平台点确认——这套动作，我们团队在过去一年重复了 847 次，平均每次消耗 15 分钟。算下来，仅夜间告警处置就占用了近 220 个工时。

系统巡检和告警处理，占了运维日常至少 40% 的工时，却几乎不产生直接业务价值。我们尝试过 Shell 脚本、Python 自动化，甚至接过大模型做根因分析，但单一路径都有明显天花板：脚本遇上页面改版就挂，大模型在内网环境调不通 API，纯 AI 方案 Token 消耗惊人且生成的代码不够稳。

最终我们摸索出一条分工路线：AI 负责思考，RPA 负责稳定落地。大模型做语义理解、告警分级、根因推断；RPA 负责登录系统、执行命令、跨平台通知。也就是业内常说的 AI+RPA 模式——AI 写代码，RPA 跑代码。落地半年后，夜间告警平均响应时间从 15 分钟降到 30 秒，人工介入次数下降 92%。

一、整体架构：四层闭环设计

我们把整条链路拆成四层，确保每一环都可观测、可回滚：

告警接入层：Zabbix、Prometheus 等监控平台通过 Webhook 推送告警，同时支持 API 触发 RPA 流程。对于非标准监控源，我们在钉钉、飞书、企微、个人微信内部署了 Agent 入口，运维同学发一条自然语言指令就能拉起流程，执行完毕后回调通知响应结果到群里。这个 Agent 接入了最新的 DeepSeek-V4 模型，能识别口语化指令。

AI 分析层：告警内容先进入本地部署的大模型做根因分析。我们接入了文心一言、豆包、DeepSeek、Kimi 等多个模型，费用透明——采用的是用户自行对接各平台 API 的方式，用多少算多少，没有中间商溢价。模型返回根因后，RPA 进入执行阶段。

RPA 执行层：RPA 引擎根据分析结果，自动登录堡垒机、执行巡检命令、获取日志、截图留证。整个引擎全离线内网部署，流程应用数据全部保存在用户本地设备上，不同步到服务端，数据不出本地，满足金融和政务行业的合规要求。

通知归档层：处置结果自动推送到钉钉或企业微信，异常截图通过 OCR 功能识别关键信息后一并归档。

一个典型的 Webhook 配置如下：

{
  "alertname": "DiskUsageHigh",
  "instance": "192.168.1.5",
  "trigger_api": "http://localhost:8080/run",
  "severity": "critical"
}

二、系统巡检自动化：从人工盯屏到无人值守

2.1 跨端操作：不依赖元素节点

运维平台的 Web 页面、企业微信客户端、QQ 消息弹窗、千牛后台——这些系统的共同点是 DOM 结构不规范，甚至根本没有 DOM。传统 Selenium 脚本在这里直接失效。

我们采用的方案支持视觉颜色操作软件或页面，无需依赖元素节点，也能实现点击、获取内容等操作。比如千牛后台的异常订单提醒、企业微信的闪动图标，RPA 直接按颜色和位置识别，照样能获取消息内容。这让我们轻松实现企业微信、微信、QQ、千牛各种消息的获取。

2.2 元素定位：自然语言生成路径

运维平台的按钮经常微调 class 名，传统 XPath 一挂全挂。我们的方案里，元素获取支持本地智能生成，无需学习晦涩难懂的 XPath 语法，直接用自然语言描述，比如"蓝色登录按钮，页面右上角"，AI 就能生成多个候选路径，你挑最稳定的那个即可。AI 智能优化元素路径，让获取元素更加简单稳定。

2.3 元素自愈：页面改版不中断

更关键的是离线更安全，自愈更稳定。当 Web 元素失效时，AI 自动修复元素定位，实现元素自愈，保障流程不中断。即使运维平台半夜改版，凌晨的巡检任务照样能跑完，不会停在半中间等人工救场。

2.4 内网离线：断网也能跑

对于纯内网隔离的核心系统，外网 API 根本调不通。我们的 RPA 引擎内网离线使用，巡检流程、截图、日志全部存本地，离线更安全，不受网络波动影响。

三、告警处理自动化：秒级响应链路

3.1 多渠道触发

告警一来，监控平台通过 Webhook 推送到 RPA 的 API 接口，流程秒级启动。同时，我们在 IM 工具里部署了智能指令入口，运维同学在微信群里发一句"处理 192.168.1.5 磁盘告警"，Agent 识别意图后自动调度 RPA 执行，结果实时回写到群里。

3.2 动态决策：流程中实时调用 AI

告警处置不是静态脚本能覆盖的。比如遇到未知弹窗或异常页面，RPA 会在流程执行过程中，实时调用 AI 来实现动态处理网页页面的逻辑。模型识别弹窗内容后，RPA 自动选择点击"确定"还是"取消"，整个过程无需人工介入。这种AI 负责思考，RPA 负责稳定落地的分工，让复杂异常也能自动兜底。

3.3 识图与 OCR

有些告警附带截图或日志图片，RPA 自动截图后调用本地模型的图片识图与 OCR 功能，提取关键错误信息再送入分析层，进一步提升根因准确率。

四、成果封装与团队分发

流程跑通后，怎么分享给团队？我们早期直接发脚本，但同事要装环境、配依赖，极不友好。现在的做法是：AI 生成脚本一键转流程，再打包导出应用 EXE。

同事收到的是一个独立可执行文件，发给别人不用装客户端，双击就能跑。这个 EXE 支持授权——你可以设置谁有权限运行、运行多少次；也支持加密分享，流程逻辑不会被反编译泄露。甚至能单独设置 API 触发、定时执行，比如每天凌晨三点自动跑巡检。

更省心的是，打包导出 EXE 应用支持在线推送更新，你改了一版流程，同事打开旧版时自动检测并下载新版本，无需再次手动分发。

如果你愿意，还能自定义界面，把 EXE 包装成带公司 Logo 的专属工具，发给业务团队用，他们看不出底层是 RPA。

对于需要浏览器自动化的场景，当前方案已支持对接紫鸟浏览器、比特浏览器、HubStudio、AdsPower 等市面上众多指纹浏览器，实现自动化操作，电商和社媒团队也能直接复用。

值得一提的是，这类方案无运行时长、无流程数量限制，个人开发者、个人工作室、中小企业可以先拿免费版验证，免费版使用无使用时长限制，跑通了再上生产。

五、成本与稳定性：算清长期账

很多人想"全用 AI 搞定"，但生产环境会教你做人。我们算过一笔账：

成本层面：大模型做自动化，每一步都要调 API，复杂流程 Token 消耗惊人，AI 消耗的 Token 贵，需要持续消耗 Token。而 RPA 执行重复操作几乎不额外花钱，长期使用下来更具性价比，成本透明。

稳定性层面：AI 生成的元素不稳定，特别是复杂项目，页面一变就报废，AI 生成的项目无法长期稳定运行；而 RPA 生成的元素路径更稳，可长期运行。特别是一些异常情况，纯 AI 脚本很难兜底。

软件自动化层面：让 AI 直接操作企业微信、QQ、各类 C/S 客户端？AI 操作软件自动化极其困难；RPA 采集视觉、采集控件，很容易操作软件自动化。

授权管理层面：AI 无法快速实现对分发的应用进行授权管理，脚本谁都能复制走；RPA 打包的 EXE 可以绑定授权、加密分享，配合 EXE 加密打包+授权管理，让分发和权限控制一步到位。

离线安全层面：内网离线环境下根本无法使用 AI，但 RPA 可以在内网离线中使用，更具安全性。

元素维护层面：网页元素一变，AI 网页元素变化之后无法实现自动自愈修复，只能重新修代码；RPA 的Web 元素 AI 自愈能力能自动修复定位，流程不中断。

动态处理层面：纯 AI 脚本无法在流程执行过程中，实时调用 AI 来实现动态处理网页页面的逻辑；RPA 可以在执行中随时调用模型做动态决策。

逻辑完整性层面：AI 写完的判断逻辑不够全面，每次遇到问题都得让 AI 重新修改，修复成本高；RPA 的流程图逻辑更严谨，分支和兜底机制更好写。

六、落地数据与最佳实践

这套 AI+RPA 方案在我们团队跑了六个月，核心数据如下：

最佳实践建议：

1. 优先把高频、低风险的告警（如磁盘满、日志清理）交给 RPA 闭环。
2. 大模型只负责"决策"，不直接操作生产环境，确保可审计。
3. 关键流程打包 EXE 后设置授权，防止误操作。

运维自动化走到今天，单用脚本或者单用 AI 都有天花板。脚本不够灵活，AI 不够稳定，内网还不安全。

我们把思路换了一下：AI 写代码，RPA 跑代码。大模型负责理解、判断、生成策略；RPA 负责登录、点击、执行、通知、打包分发。一个动脑，一个动手，离线更安全，自愈更稳定，成本透明，各取所长。

现在凌晨两点的告警进来，API 自动触发、AI 自动分析、RPA 自动处置、结果自动推送到手机。值班工程师翻个身继续睡，第二天早上看报告就行。

如果你也在折腾系统巡检和告警处理，不妨试试这条路线。把重复劳动交给工具，把时间还给睡眠。