从AIOps到Agentic Operations：智能运维如何从建议走向自动执行-北京尧图网络

我大概是在三年前开始正儿八经接触 AIOps 的当时团队里的监控告警一天能刷出两千多条靠人肉盯根本看不过来于是上了智能降噪、异常检测、告警聚类那一套。效果确实有告警从两千条降到两百条但我的实际体感是它只是帮我把问题“找出来”了真正要去处理问题的时候还是得靠人拉群、查日志、改配置、重启服务。到了今年大模型 Agent 的能力出来以后整个运维圈子都在聊一个词叫 Agentic Operations也就是把 AIOps 从“发现问题的参谋”升级成“能执行动作的作战单位”。这篇文章就聊聊我对 AIOps 到 Agentic Operations 这段演进的重新理解。不是什么教科书式的推演更多是我自己在实际业务里踩过坑之后的复盘。如果你正在做监控平台、告警治理、运维自动化或者你只是想搞清楚“AI 运维到底能替我干多少活”这篇应该能给你一个比较清晰的全景图。1. AIOps 为什么不够用了最后还是靠人1.1 从“监控大屏”到“告警风暴”的真实场景先说个场景某电商平台的订单服务在晚高峰出现超时监控大屏上立刻红了三个模块订单服务、支付回调、用户中心。告警平台在 10 分钟内弹出了 80 多条相关告警涉及 CPU、延迟、错误率、线程池、数据库连接池。以前我们用 AIOps 的时候系统能做什么它能通过聚类把 80 条告警归并成 3 个事件还能通过调用链分析给一个建议根因大概率是数据库连接池打满。听起来已经很智能了对吧但问题在于这个“根因”是概率值它只是一个推荐结果。真正处理的时候值班工程师还是要自己去连数据库看一眼连接池水位确认是不是慢 SQL 堆积然后决定是重启连接池、杀掉会话、还是走紧急扩容流程。这一套动作下来通常已经过去了 10 到 15 分钟。在核心链路故障的场景里每一分钟都在损失订单量。1.2 AIOps 的能力边界到底在哪AIOps 这个词本质上是把 AI 能力用到 IT 运维的各个环节包括告警降噪、异常检测、根因分析、容量预测这些。它解决的问题在多数时候是“感知”和“理解”层面的。我常用的一个类比是AIOps 像一个极其勤奋的体检医生它能帮你把异常指标标红把相关联的线索整理成报告但它不会替你动手术。它告诉你肝指标异常、和最近熬夜喝酒高度相关但它不会直接逼你睡觉、替你挡酒。具体拆一下AIOps 的典型能力有三层感知层通过采集系统指标、日志、链路数据做实时异常检测。一般用时序预测、统计模型或者孤立森林这类算法。关联层把多个告警做聚类和因果关联减少告警噪音定位出可能的根因范围。推荐层基于知识库或历史故障库给出现场处理建议。这三层跑下来输出物基本都是一个“结论”或者“工单信息”。从技术上来说AIOps 已经解决了“信息过载”的问题但它和“解决问题的动作”之间仍然隔着一个巨大的鸿沟——人。1.3 智能运维的真正痛点只“建议”不“执行”我在一个故障复盘会上跟其他同事讨论时大家最深的感受是AIOps 把“找到根因”的效率提高了但没有把“解决故障”的效率提高多少。一次典型的故障处理时间线大概是这样00:00 服务报警AIOps 3 秒内聚类给出疑似根因。00:01 值班工程师被叫醒打开电脑。00:03 人肉确认告警详情查看上下文。00:08 登录跳板机连数据库人工验证根因假设。00:10 执行变更动作比如 kill 会话或者限流。00:15 服务恢复整理复盘报告。AIOps 解决的只是第 1 步而从第 2 步到第 6 步都是人在做。如果故障发生在凌晨值班工程师被叫醒后的效率是会打折扣的。所以我的结论是AIOps 时代机器是“分析者”人是“决策者执行者”。而 Agentic Operations 要改变的恰恰是后面这些环节。2. Agentic Operations 到底改了什么2.1 什么是目标驱动的智能体闭环Agentic Operations 这个词拆开看就是 Agent 化的运维体系。和 AIOps 最大的区别它不止步于“告诉你该做什么”而是直接去调用工具、执行动作、观察结果、调整方案形成一个完整的闭环。我们可以把它理解为你不是给 AI 提了一个问题而是给 AI 布置了一个目标。比如“订单服务超时率高于 1%请处理到恢复正常水平”。之后Agent 自己会去拆解这个目标先查监控确认当前超时率是多少再看日志或者链路尝试定位瓶颈是在数据库、缓存还是代码逻辑然后调用运维平台 API 执行动作比如限流、扩容、重启某些异常实例做完之后再看指标有没有回落如果没回落换下一个假设继续尝试。整个过程里人的角色从“操作员”变成了“目标制定者和监督者”Agent 把之前 AIOps 留下的“建议”和“人工操作”之间的空白填上了。2.2 感知、推理、执行、反思的决策循环从技术实现上看Agentic Operations 的底座是一个大模型驱动的决策循环通常包含四个阶段感知不许拍脑袋先获取现实世界数据。这一步比 AIOps 更重不只拉指标还要拉事件上下文、变更记录、架构拓扑、历史故障档案全部汇聚成 Agent 的上下文。推理大模型基于上下文做多步推理把复杂故障拆解成若干子任务规划出执行顺序。这里会用到思维链之类的推理技巧但更重要的是要有领域知识约束不能纯靠通用模型的“常识”去瞎猜。执行调用外部工具执行动作。工具包括监控系统的 API、运维编排平台、云厂商的 OpenAPI、数据库客户端等等。这一步的关键在于工具都必须是“具象化”的Agent 才能正确选择和使用。反思执行完动作后再次拉取结果数据对比目标是否达成。如果不理想就修正假设进入下一轮循环。反思阶段是 Agent 架构和 AIOps 最本质的分水岭——它不是一次性的而是循环的、迭代的。这四个阶段组合在一起本质上就是“自己干活、自己验收、不行就再来一遍”。2.3 它和自动化脚本、AIOps 的边界在哪里有人可能会问这不就是加了点调度的自动化脚本吗其实不是。传统自动化脚本是“确定性执行”写好了逻辑遇到预期内的情况就按部就班跑遇到预期外的就卡住报废。Agent 的优势在于处理“非确定性”场景。我建议用下面这张表理解三者的差异维度传统自动化AIOpsAgentic Operations核心模式固定流程脚本智能分析人工执行目标驱动自主闭环输入明确的步骤和触发条件监控数据和告警业务目标环境感知输出确定性的动作建议/根因报告完成状态过程记录异常处理能力差基本靠人中能识别但不去做强多步尝试和反思人的角色编写脚本和触发决策与执行设定目标和审核价值重心替代重复劳动替代“看”替代“救火”从传统自动化到 Agentic Operations其实是运维自动化的一次“升维”从“替手”变成“替脑替手”。当然这也意味着落地 Agentic Operations 的安全控制要求会比传统自动化更高不然一个判断失误可能整个集群都被带偏。3. 落一个 Agent 运维体感架构和关键模块3.1 感知层让 Agent 有足够的信息做判断很多人做 Agent 运维上来就挂一个大模型 API然后让它自由发挥。我见过的翻车现场基本上都是因为“感知层”没做好——Agent 连服务拓扑都不知道连故障前后的变更记录都没拿到它就开始推理了那推理出来的大概率是幻觉。感知层要做的事是把可观测性数据结构化、语义化变成大模型能理解的形式。我们当时做了这么几件事把指标、日志、调用链三类数据统一接入到一个事件总线上给每条数据打好标签包括服务名、实例 IP、资源类型、时间范围。把常见的告警规则转成自然语言描述喂给 Agent。比如“订单服务错误率连续 5 分钟超过 2%”这件事不能给 Agent 只抛一个“alert-189233”而是直接告诉它“订单服务错误率异常持续约 5 分钟最近一小时变更通知里有发布记录”。把 CMDB 的拓扑关系图和变更记录表也要暴露给对方。Agent 查“这个服务依赖哪些下游 DB”是可以直接通过工具查询得到的。我自己的经验是感知层的建设成本占了整个项目的 40% 以上但也是最值得投入的部分。没有数据质量就没有推理质量。3.2 决策层从ReAct 模式到任务编排感知做好了接下来就是决策。这一层说白了就是让 Agent 的“大脑”跑起来。常见的实现模式是 ReAct即让大模型交替进行“思考Reason”和“行动Act”。大模型先读当前状态想一步“订单超时可能是数据库问题我应该先查一下 DB 的当前连接池状态”然后调用一个查 DB 的工具拿到结果后再思考下一步。不过真实场景里单靠一个大模型裸奔会比较吃力因为故障治理经常会涉及多个并发线程。比如既要查日志又要看调用链还要拉数据库状态。所以我们当时的做法是引入了“任务编排器”也就是一个轻量级的编排框架节点一故障定位 Agent负责多数据源分析产出候选根因列表。节点二止血 Agent负责执行紧急动作例如限流、摘流量、重启。节点三恢复验证 Agent负责在动作执行后继续观察指标变化。编排器负责任务之间的大前提止血 Agent 必须在节点一给出明确候选根因之后才启动避免没头没脑乱操作。还有一种思路是让一个主 Agent 动态创建子 Agent分发任务。这个对规划能力要求高比较考验模型的上下文管理能力。我在实际过程中体感企业级运维场景现阶段的稳妥方案还是“固定编排局部动态决策”混合模式全动态规划可以作为探索方向。3.3 执行层安全护栏和变更通道这一步是整个系统里最敏感的地方因为 Agent 要触碰“变更”了。我见过一些团队做 Agent 运维的 Demo觉得很酷Agent 自动执行 shell 命令、自动改配置。但真要上生产这一层必须有非常严格的安全设计。我们当时的原则是“默认拒绝、显式放行、全流程审计”。每个工具调用都经过一个策略引擎策略引擎干三件事检查动作类型如果动作属于“读操作”查日志、查询指标可以放行。如果动作属于“写操作”改配置、重启、扩容、降级就必须匹配预先定义的“安全动作名单”并且还得带上工单号和变更审批编号。超出名单的操作一律直接拒绝甚至不进入“需人工审批”流程直接从源头阻断。除此之外执行通道要做双人复核机制的设计。我们给关键变更动作配置了“复核座席”Agent 发起变更后系统会生成一条待办醒目标注变更内容、影响范围、回滚方案由值班人员一键确认或驳回。有一些非关键变更比如清理缓存、重置连接池可以设定为自动执行但对于服务重启级以上的操作自动人工复核是标配。最后是全流程审计。Agent 的每一步推理、每一次工具调用、每一个输出结果都要落日志这些日志不仅为了回溯故障更是后续优化 Agent 策略时的训练素材。出了问题不认账没有完整审计日志任何团队都不敢让 Agent 在核心链路里干活。4. 从传统运维平滑迁移到 Agentic Operations 的路径4.1 第一步把 Runbook 变成可执行的剧本Agent 要运行起来一个基本前提是它得知道“故障处理的标准步骤”是什么。传统团队里这些经验都存在老师傅脑子里或者写成了 Runbook 文档放在 wiki 里。我们当时做了一个动作把最高频的 50 个故障场景的 Runbook 全部结构化转成“可执行剧本”。剧本有两种形态一种是与环境无关的自然语言描述比如“会话线程池打满时第一步记录线程 dump第二步检查慢 SQL第三步 kill 异常会话第四步观察恢复情况”。给 Agent 读。另一种是带 API 调用参数的 Action Schema 定义比如“limit_service(service_name, qps_limit)”“kill_sessions(mysql_id, statement_pattern)”“restart_pods(service, namespace, count)”。给 Agent 的工具调用器用。这一步做完之后效果立竿见影。即使没有上 Agent光是剧本加自动化执行就把人肉救火的平均耗时降低了 30%。所以说Agent 化不是一个从零开始的新工程而是一个“整理存量经验”的过程。4.2 第二步人机协同做 Agent 的“副驾驶”而不是直接自动驾驶我特别不建议一上来就搞全自治。我们当时也是从“人机协同”模式切入的。在那个阶段Agent 的定位是一个“高级运维助理”它会在收到告警后自动完成信息收集、根因假设生成、处理方案推荐然后推送到值班群里。值班人员只需要按“确认”按钮Agent 才会去执行操作。如果值班人员觉得方案有问题可以直接在群里给指令“不要限流的那个方案改用对某个特定入口进行流量摘除”Agent 会重新理解并调整。这个模式的好处是人始终在决策闭环里风险可控同时 Agent 的所有行为有人背书团队能逐步建立信任感。我常说这一阶段人不是“操作工”而是“副驾驶”等着把驾驶权逐步交给 Agent。4.3 第三步面向目标的自治运营当我们积累了足够多的“人机协同通过案例”之后就可以开始切自治模式了。但自治也不是完全撒手不管而是从“指令级”进化到“目标级”。比如非核心链路的一个缓存服务出现延迟抖动原先在协同模式下你告诉 Agent“去执行清理缓存命令”现在在自治模式下你告诉它“这个服务的 P99 延迟稳定在 200ms 以下你来看着办”。Agent 自己去选择查看当前容器 CPU 和内存水位分析是不是缓存命中率下降导致穿透决定清理部分热点 key 还是扩容副本数然后在低峰期执行动作做完再验证效果。在自治模式下人应该关注的不是每一步怎么做而是目标本身合不合理。所以我们在建设自治能力的同时也补了“目标治理”这一层定期审视 Agent 的目标边界明确哪些场景只给“观察权”哪些场景给“限制执行权”哪些场景完全禁止 Agent 介入。5. 常见问题、排查与避坑实录5.1 Agent 乱执行怎么办护栏还是要靠“最小权限显式白名单”我见过最典型的翻车案例是一个测试环境里的 Agent 在排障时根据日志推理出“磁盘占用过高需要清理”然后它执行了一个rm -rf清理命令因为盘符拼接逻辑失误直接把一个数据目录给清了。这个案例里问题不在大模型的判断力而在工具定义太糙。避坑建议给 Agent 的所有工具参数一律用枚举或正则约束绝不能让模型自由拼路径。比如清理磁盘这个动作应该定义成clean_disk(mount_point, max_size_gb)mount_point 只能从预设列表选max_size_gb设上限而不是让模型自己填一个目录路径。同时配合“最小权限原则”用专用运维账号跑 Agent账号除非必要不应该有 root 权限和跨服务访问权限。5.2 大模型上下文越用越乱怎么解Agent 在多次循环之后会把大量日志、监控数据塞进上下文导致模型“找不到重点”做出的一些判断会莫名其妙地被早期信息带偏。我们当时的解法是两层一是压缩工具返回监控数据不直接把原始 JSON 全量丢给模型而是预先做摘要化、切片化把“最近 5 分钟的 CPU 曲线趋势是上升还是下降”“错误日志的前三条关键词”这些精华信息喂进去二是引入记忆管理机制早期对话记录定期归档只保留精简的事件摘要保证阶段性的推理窗口始终聚焦在当前目标上。如果用的是开源模型部署本地模型本身上下文窗口不长哪怕号称 128K也要注意长 Prompt 的推理延迟是灾难级别的。线上故障 Agent 如果反应时间超过两分钟那基本上不具备实战价值这一点务必提前压测。5.3 数据质量差Agent 再聪明也白搭很多团队在评估 Agent 能力时只知道对比大模型的推理分数忽略了一个事实Agent 吃的数据才是它表现的天花板。如果告警名称本身模糊、指标口径不一致、日志格式混乱Agent 推理出来的根因大概率也是错的。我们做过一个内部评测同一套 Agent 框架接一套治理干净的数据故障定位准确率能到 85%接一套脏乱差的数据直接掉到 35% 以下。所以如果你的 Agent 总是给出离谱的结论先别急着换更强的大模型回头去看看接入的数据质量。我当时在团队里搞了一个数据体检清单每月过一遍主要查这几类问题告警规则有没有过期重复、指标标签有没有命名不一致、日志解析有没有在切版本后失效、CMDB 拓扑和实际部署架构有没有偏差。听起来很基础但运维稳定性的提升很多时候根本不是靠炫技而是靠把这些基础做扎实。Agentic Operations 常见问题排查速查表现象排查方向处置建议Agent 反复执行同一个动作不收敛检查反思模块确认工具调用后有没有回读指标增加“无变化即终止”的重试上限工具调用参数生成错误工具 Schema 描述不清晰或参数缺约束给参数加枚举范围重新生成工具描述根因判断与实际问题偏差大可观测数据队友语义缺失补拓扑、变更、依赖等上下文字段执行动作后故障加重没有预演直接动生产强制先跑“影响面分析”再做变更Agent 响应速度慢推理链过长、上下文过大摘要裁剪子 Agent 并发压降推理延迟误杀非目标服务权限过大动作边界不明最小权限账号白名单工具集双重校验结尾说实在的AIOps 到 Agentic Operations并不是简单的技术换新而是一次运维工作模式的迁移从“机器报警、人来决策”逐步走向“机器感知、机器执行、人做监督”。我自己的体会是这一步的跨度远超过“上一个新平台”那么简单它更接近一次团队能力和流程体系的升级。尤其在做第一个自治场景试点时我们花了大半时间在梳理流程规范、权限边界和数据治理上真正调模型的时间反而没那么多。后来我也想通了Agent 化运维本质上是在跟团队里的老师傅学经验把那些“在关键时刻快速判断、果断执行”的能力沉淀成系统能力这个过程急不得。如果你所在的团队也在考虑往 Agentic Operations 方向走我建议从两个事情开始第一件拉出你这半年高频出现的 20 个故障场景把 Runbook 结构化。第二件挑一个低风险、非核心链路的场景做一次封闭测试让 Agent 在沙箱里跑透再考虑进生产。运维是稳字当头的领域不用迷信一步到位把每一步走扎实就已经比大多数团队走得更远了。

从AIOps到Agentic Operations：智能运维如何从建议走向自动执行

相关推荐

全景拼接中的相位相关算法：从频域位移估计到鲁棒图像对齐

点云车辆检测与注意力机制：从算子到训练全解析

LVGL按钮矩阵实战：用map数组高效构建嵌入式UI键盘

更多资讯

开源代码审查增强工具 open-code-review：从规则引擎到团队工程实践

open-code-review：用AST和复杂度指标重塑代码评审流程

安卓蓝牙示波器实战：从蓝牙SPP数据传输到ADC波形绘制的完整链路

从零掌握Makefile：依赖规则、增量构建与多目录实战避坑指南

pv+tar：Linux命令行进度条与实时解压测速实战

开源代码审查方法论：CLI+Git+本地LLM实战指南

今日更新

悟空开源无代码平台实战：从实体建模到应用设计避坑指南

基于.NET9的多租户权限系统：数据权限与动态API落地实践

场地预约小程序毕设实战：SSM+微信小程序+MySQL数据库设计到避坑

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？