当前位置: 首页 > news >正文

AIOps探索:Hermes可能是现阶段最适合做AIOps的Agent(附可行性落地思路)

01|为什么Hermes适合做AIOps

真正的运维工作,从来不是一次性的。

它是连续的、上下文密集的、经验驱动的。它需要记住你们系统的历史问题,理解你们业务的依赖关系,知道某类告警在你们环境里意味着什么,知道哪个指标抖动是噪音,哪个日志模式其实是事故前兆。

说白了,运维最值钱的部分,不是“会查资料”,而是会积累经验,会复用经验,会把经验越滚越厚

而这,恰恰是我觉得Hermes最有意思的地方。它不是只想做一个会调用工具、会跑任务的agent。它真正想做的是一个带学习闭环的agent

  • 会在交互中积累上下文
  • 会保留长期记忆
  • 会沉淀技能
  • 会在后续任务里复用这些技能
  • 甚至可以继续改进自己的技能和工作方式

这意味着它天然就非常适合那些不是一次性任务,而是长期演化型任务的场景。而AIOps,恰恰就是这种场景。

为什么说AIOps这个方向,Hermes天然合适?因为运维、排障、故障定位、根因分析,本质上都特别依赖三件事:

第一,经验。很多问题不是“有没有标准答案”,而是“你有没有见过”。

第二,上下文。一次故障从来不是孤立的,它背后往往挂着变更记录、依赖关系、历史告警、拓扑结构、机器状态、日志模式、链路异常。

第三,持续优化。真正厉害的运维体系,不是每次从头排障,而是同类问题下次再出现时,可以更快定位、更快处置、更少踩坑。

你会发现,这三件事,刚好都不是传统问答式 AI 最擅长的。但它们却非常符合 Hermes这种“会记、会学、会沉淀”的agent形态。

02|基于Hermes做AIOps平台的思路

我觉得运维这件事,最有价值的并不是你做出来多么牛逼的一个运维平台,而是平台背后越来越厚的经验。

比如:

  • 你们系统里,哪个告警经常是虚报、假报
  • 哪类错误日志通常意味着上游依赖超时
  • 某个业务在大促前后,哪些波动其实是正常现象
  • 某个服务抖动时,先查什么最有效
  • 某个故障在你们组织内部,最靠谱的处理路径是什么

这些东西,不太像“固定规则”,更像“组织经验”。而组织经验最适合由什么来承载?

它不是一个死规则引擎,也不是一个一次性回答器,而是一个持续工作并且能持续进化的载体。Hermes不就是这样的载体吗?

所以我更看好的一种思路是:不要只想着把大模型接进运维平台。而是反过来:把Hermes这个智能体放到AIOps运维平台正中间。也就是说,把Hermes当成其核心引擎,然后围绕这个引擎,再去补企业级平台能力。

如果按这个思路去设计,一个比较合理的架构会是这样:

一层:Hermes负责“思考、决策、学习”

它是整个 AIOps 平台的大脑,主要负责:

  • 理解告警和运维指令
  • 组织上下文
  • 调用工具
  • 串联排障流程
  • 做阶段性判断
  • 生成诊断结论
  • 从一次次故障处理中沉淀经验
  • 把经验转化成可以复用的 skill

换句话说,它不只是“接问题”,而是接管整个智能闭环。

二层:在Hermes外围补齐平台能力

这个平台层,至少应该补四块:

  • MCP 中心
  • Skill 中心
  • 用户和权限体系
  • API 能力

我觉得这四块,基本就是把Hermes产品化、平台化、企业化的关键。

03|AIOps平台的4个核心能力

1)MCP 中心:把所有运维系统都接到Hermes身上

如果Hermes是大脑,那MCP中心就是它的“神经系统”。因为运维现场最怕的不是“AI 不聪明”,而是“AI 什么都看不到”。

它如果拿不到监控数据、日志、链路、拓扑、变更记录、工单、发布信息、集群状态,它再聪明也只能猜。

所以第一件事,就是把企业现有的运维生态,统一接到Hermes上:

  • 监控系统
  • 日志系统
  • 链路系统
  • CMDB
  • 发布系统
  • 工单系统
  • 值班系统
  • Kubernetes / 云资源平台
  • 数据库和中间件控制面
  • 内部知识库 / Runbook / Wiki
  • ChatOps / IM / 邮件告警

这样,Hermes才不是一个“会说运维术语的聊天机器人”,而是一个真的能进现场、看数据、拉上下文、做动作的运维智能体

但MCP中心不能只做“连接器市场”。它还必须承担平台治理角色,比如:

  • 工具注册与发现
  • 接入规范
  • 版本管理
  • 权限控制
  • 调用审计
  • 高风险操作审批
  • 安全隔离

因为一旦agent真正开始接生产系统,你会发现最重要的已经不是“接没接上”,而是“接上之后怎么安全地用”。

2)Skill 中心:把运维经验变成平台资产

这是我觉得最有想象力的一层。很多公司做运维智能化,最后容易卡在一个地方:系统很强,但经验不沉淀。

今天某个专家处理了一个复杂故障,很精彩。明天另一个同学再遇到类似问题,还是得从头来一遍。这就很可惜。

而Hermes的skill机制,刚好给了一个很好的承载方式。我们完全可以把Skill中心做成“运维经验的产品化平台”,用来沉淀这些东西:

  • 告警分级策略
  • 服务排障 SOP
  • 数据库诊断流程
  • 中间件故障处置套路
  • 发布失败回滚步骤
  • RCA 分析模板
  • 事故复盘模式
  • 各业务线特有的故障经验

更关键的是,它不应该只是人工录入的知识库。它应该是一个动态闭环:

一次真实故障处理完成后,Hermes从中抽取可复用步骤 → 生成skill草稿 → 专家审核 → 上线复用 → 后续继续优化。

这个闭环一旦跑起来,平台的价值就不只是“帮你处理故障”,而是:每处理一次故障,都在给平台增加能力。

这种模式就像是一个“会长大的运维系统”,这不正是我们想要的吗?

3)用户和权限体系:决定它能不能真的上生产

运维场景天然就是高权限、高风险场景。查日志和重启服务,根本不是一个风险等级。看监控和改流量,也不是一个风险等级。

所以如果Hermes要成为AIOps核心引擎,那它外面必须有完整的用户和权限体系:

  • 用户身份管理
  • 组织隔离
  • 团队角色
  • 环境隔离
  • 工具级权限
  • 数据级权限
  • 动作审批
  • 审计留痕

比如:

  • 研发可以看指标、查日志,但不能执行生产动作
  • 值班 SRE 可以执行低风险自动化
  • 数据库动作必须走 DBA 权限
  • 涉及生产变更、重启、流量切换的操作必须审批
  • Agent 每一次调用什么工具、拿了什么数据、做了什么判断,都必须能回溯

只有把这层补齐,Hermes才能从“聪明”变成“可用”。

4)API能力:让AIOps平台变成全公司都能调用的智能底座

这一层也非常关键。因为真正的平台,不能只停留在一个聊天框。

如果Hermes只是一个对话界面,那它最多是个助手。但如果它有标准API,它就能变成整个企业的智能运维底座。比如提供如下API:

  • 告警接入API
  • 智能诊断API
  • 根因分析API
  • Runbook执行API
  • 事故复盘API
  • Skill 查询/ 发布 API
  • MCP管理API
  • 权限和审计API

这样它就可以接到各种系统里:

  • 监控平台触发自动诊断
  • 工单系统自动拉取RCA结果
  • ChatOps机器人查询排障建议
  • 发布平台做变更风险分析
  • 运营平台展示故障处理链路
  • 领导驾驶舱读取事故总结和趋势

到这一步,它就不再是一个孤立的agent产品,而是企业运维系统里的“智能核心服务”。

04|先从简单场景落地开始

基于以上思路,我觉得最适合落地起步的,是下面三个场景。

场景一:告警智能助手

这个最容易切进去,也最容易体现价值。当告警来了以后,Hermes自动去拉:

  • 指标变化
  • 关联日志
  • 最近变更
  • 依赖服务状态
  • 历史相似故障
  • 责任团队信息

然后给出一个结构化结果:

  • 告警摘要
  • 影响范围
  • 疑似根因
  • 排查建议
  • 推荐升级路径
  • 建议通知人

这个场景的价值非常直接:把值班同学从“到处翻系统”变成“直接接收上下文完整的诊断入口”。

场景二:故障排查Copilot

这比告警助手更进一步。它不是只“告诉你发生了什么”,而是能按skill去引导整个排障过程。比如:

  • 先查最近变更
  • 再查上游依赖
  • 再聚类错误日志
  • 再看关键指标转折点
  • 再检索历史相似案例
  • 最后生成阶段性判断

这个时候,Hermes的优势就会特别明显。因为这已经不是单轮问答,而是真正的“连续故障处理”。

场景三:根因分析和复盘助手

这可能是长期价值最高的场景。因为它不仅帮助你在事故过程中动态分析,还能在事故结束后,把整个过程沉淀下来:

  • 还原时间线
  • 汇总关键信息
  • 归纳疑似根因
  • 生成复盘初稿
  • 抽取可复用经验
  • 形成skill候选

你会发现,一旦做到这一步,事故处理和经验沉淀就真正连起来了。这个能力可能是AIOps最稀缺的地方。

学AI大模型的正确顺序,千万不要搞错了

🤔2026年AI风口已来!各行各业的AI渗透肉眼可见,超多公司要么转型做AI相关产品,要么高薪挖AI技术人才,机遇直接摆在眼前!

有往AI方向发展,或者本身有后端编程基础的朋友,直接冲AI大模型应用开发转岗超合适!

就算暂时不打算转岗,了解大模型、RAG、Prompt、Agent这些热门概念,能上手做简单项目,也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料,手把手帮你快速入门!👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型(GPT、文心一言等)特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架(LangChain等)实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块,看似清晰好上手,实则每个部分都有扎实的核心内容需要吃透!

我把大模型的学习全流程已经整理📚好了!抓住AI时代风口,轻松解锁职业新可能,希望大家都能把握机遇,实现薪资/职业跃迁~

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

http://www.jsqmd.com/news/679740/

相关文章:

  • 如何在3分钟内完成Windows系统激活:智能激活脚本完整教程
  • 终极iOS 15-16 iCloud绕过方案:如何重新激活被锁定的苹果设备?
  • C#怎么操作WPF数据模板 C#如何用DataTemplate定义集合项的显示样式和布局【控件】
  • AI模型热更新失败?.NET 11 AssemblyLoadContext + ONNX模型热重载方案(含Assembly卸载泄漏检测工具)
  • 如何快速调整任何窗口大小:WindowResizer终极免费窗口调整工具指南
  • mysql如何配置临时账号权限_mysql带期限的用户授权
  • TVA检测技术在普通电子元器件领域的全维度解析(1)
  • 群核科技悉数行使超额配股权:额外募资1.74亿港元
  • 从麦克风阵列到声源坐标:手把手实现Python版SRP-PHAT定位(含代码)
  • 如何使用 shallowRef 优化大数据量渲染?显著提升页面性能的干货
  • 从康托集这个‘怪胎’出发,逆向理解Borel集、Sigma代数与拓扑空间的层层递进关系
  • [具身智能-406]:硅基觉醒:大模型“破壁”的三条路径,每天,这个世界上无数的生物人,在这三条主线,为硅基智能的极速的进化在孜孜不倦的努力。
  • Agent 上下文越来越长?一个 task 工具的秘密
  • 2026年可移动垃圾房怎么选:保安岗亭/可移动垃圾房/台州岗亭/嘉兴岗亭/宁波岗亭/浙江岗亭/湖州岗亭/移动卫生间/选择指南 - 优质品牌商家
  • 大疆无人机开源项目实战:用Eclipse Paho库搞定MQTT双通道通信(TCP vs WebSocket)
  • PTP协议精讲(2.16):守护时间的金库——PTP安全机制深度解析
  • Ubuntu多硬盘加密后,如何安全地自动挂载数据盘?(附开机脚本与Trim优化)
  • 3组共11人获2026科学突破奖物理学新视野奖,其中三位华人学者
  • C语言学习笔记 - 5.C概述 - C的应用领域
  • 【硬核实战】Spring AOP 从原理到落地:3 个可运行案例带你吃透切面编程
  • 良品铺子年营收55亿:同比降23% 净亏1.5亿 拟派息1亿 控股股东3500万债务违约
  • 别再只会用定向天线了!聊聊农村、郊区基站背后的‘全向高增益’技术(附5种主流结构对比)
  • STM32F407ZGT6高级定时器驱动二自由度舵机云台:从PWM原理到安装校准全解析
  • 别再为Instant-NGP发愁!Win11下用Anaconda搞定tiny-cuda-nn环境(附VS2019编译避坑指南)
  • “太空智算互联网”专家观点分享
  • 别再手动改代码格式了!用IntelliJ IDEA的CheckStyle插件,5分钟搞定团队代码规范
  • 从CPU到硬盘:数据的一生之旅,揭秘RAM、Cache、ROM如何接力跑
  • python packer
  • 从光编到绝编:为什么你的伺服项目该考虑SSI/BISS编码器了?
  • 手把手教你用Verilog驱动JFM25F32A Flash:从状态机设计到时序参数避坑