★ FEATURED ARTICLE 做了多年的运维我见过指标告警从人工翻日志到监控大盘再从阈值规则到智能基线现在又亲眼看着AI运维这个概念被推向下一个阶段。微信群里大家聊的还是AIOps落地难、告警疲劳、根因定位靠猜行业里已经有人在讨论 Agentic Operations 了。从AIOps到Agentic Operations表面上是把Ops前面那个词从AI换成了Agentic但背后其实是一整套对智能运维到底该干什么的重新定义。这个变化不是概念炒作它真的在改运维的工作方式。AIOps那套东西解决的是让系统帮人看问题而Agentic Operations要解决的是让系统自己把问题处理掉。从辅助人到替代执行这个跨越听着不大做起来是全新的一摊事。1. AIOps 当时解决的核心问题1.1 智能运维的起点从告警洪峰到根因推断AIOps这个概念刚火起来的时候整个行业的痛点非常明确——监控数据太多、告警太多、人不够用。一套中等规模的系统一天产生几亿条指标数据几千条告警值班工程师一晚上处理几百个工单翻日志翻到手抽筋。传统监控通过阈值规则来触发告警但规则是静态的系统是动态的白天高峰时段和凌晨低峰时段的同一指标正常范围完全不一样。AIOps的解决方案是用算法来代替一部分人工判断。比如动态基线检测通过历史数据学习指标的周期性规律然后对当前数据做偏差判断取代简单的静态阈值再比如关联分析利用时序数据的时间序列相关性把多个异常指标聚合成一个故障场景减少单点告警轰炸还有根因定位通过拓扑关系、调用链数据、指标变化的时序因果推断帮助定位到底是哪个服务先出问题的。这套技术栈在我实际用过之后确实有效果。最明显的变化是告警量降了一大截动态基线比阈值规则聪明得多。一个常态运行的服务,即使业务流量波动很大,系统也能自动调整判断区间。告警量下降之后,值班工程师不再是什么都看,而是只看智能系统筛选出来的、带有一定根因推断结论的告警,效率确实提升了不少。1.2 三大核心能力异常检测、根因定位、智能诊断如果要给AIOps的能力做一个归类,我一般会分成三层。第一层是异常检测,就是解决有没有出问题第二层是根因定位,解决到底哪里出了问题第三层是智能诊断,解决问题为什么发生、影响多大。异常检测这一层最成熟。基于时序数据的算法有很多现成方案,比如3Sigma、EWMA、Prophet、Isolation Forest,还有一些基于深度学习的变体。这一层讲究的是误报率和漏报率之间的平衡,不光要看检测灵敏度,还要看后期的人工确认成本。我见过不少团队,一开始把模型灵敏度调得很高,结果误报一堆,大家骂声一片,最后又得把阈值往回收。根因定位这一层就复杂得多了。常见的技术路线质量参差不齐。基于拓扑的定位,前提是你的服务依赖关系要维护得很精确,很多团队的配置图谱和实际调用链路是脱节的,定位结果自然不准。基于日志和调用链的定位,效果相对好一些,但前提是日志规范、链路完整。还有一个现实问题——同一时刻多个服务同时异常时,到底哪个是根因,哪个是下游的连锁反应。智能诊断这一层,就是AIOps的终极形态了。它不只要告诉你是哪个服务出了问题,还要告诉你问题是怎么发生的。这一步需要大量运维知识库、故障预案和案例积累,纯靠算法是做不出来的。这一层也是后来向Agentic Operations演进的关键接口,因为它本质上需要知识推理。1.3 行业落地的时候,AI运维为什么越做越累AIOps在各家落地几年之后,一个普遍的感觉是——智能运维项目越做越累,但效果越来越难提升。这不是算法不够好,而是产品形态碰到了瓶颈。第一个瓶颈是能看懂、不能动手。AIOps的产出物是告警、分析报告、根因推断结论,这些信息最终还是要一个值班工程师去确认,然后手工去执行恢复动作。系统分析得再准,只要人没有及时响应,故障时长并不会被有效压缩。换句话说,AIOps把发现的效率提升了,但没有改变恢复的方式。第二个瓶颈是场景割裂。一个典型的故障处理流程,涉及监控告警、日志查询、指标分析、配置变更、服务重启、消息通知等多个环节。AIOps工具最多覆盖到前三个环节,后面几个环节还是要人切到不同的系统里操作。这个割裂本身就是巨大的效率损耗,信息在工具链之间传递的时候,还要靠人肉拷问。第三个瓶颈是运维知识的模型化表达。AIOps项目最常见的失败原因是知识库建设失败。运维专家觉得写文档太费时间,写出来的东西不够结构化,算法团队又不知道怎么把这些文本变成可用规则。到头来,所谓的智能诊断还是靠一堆if-then规则凑出来的,根本谈不上智能。2. Agentic Operations 到底变了什么2.1 从智能分析到自主行动的思想跃迁Agentic Operations的核心变化,是把智能的位置从分析环节挪到了执行环节。AIOps的逻辑是感知→分析→建议,Agentic Operations的逻辑是感知→决策→执行→验证→总结。这个变化里面隐含着一个关键假设:系统不仅能够像人一样理解问题,还要能够像人一样动手操作。这个动手是质的飞跃。一个系统要能动手,必须具备几个基本能力。第一,它得能理解自然语言描述的目标,比如把订单服务的错误率降到0.1%以下,然后自己拆解任务。第二,它得知道有哪些工具可以用,怎么调用这些工具——这些工具可能是命令行、API、运维平台的操作接口,也可能是旧有的AIOps分析模块。第三,它得能在执行过程中根据反馈动态调整策略,这一步就不是传统的自动化脚本能覆盖的了。以Agent为单位的AI运维,本质上是对之前人围着系统转的模式做了一次反转。以前是工程师登录堡垒机,逐条执行命令排查故障;现在是Agent主动观测异常,自主执行诊断流程,调用变更工具进行处置,最后生成一份完整的处理报告。运维工程师从执行者变成了定义者,他的任务是告诉Agent期望状态是什么,而不是告诉它每一步怎么操作。2.2 Agentic Operations 的五个关键支柱想象一个运维场景:凌晨三点,线上服务出现异常。如果是一个Agentic Operations体系,它会怎么做?它会先通过指标异常检测发现问题,然后把异常信息放到一个工作上下文里;接着它调用可观测性平台查询最近的变更记录和日志;再根据知识库里的故障处理手册匹配处置方案;最终通过运维自动化平台执行操作,比如回滚发布、扩容实例、调整流量。整个流程不需要任何人参与,这就是Agentic Operations的核心能力框架。这个框架需要五个支柱来支撑。第一个是感知层,负责从指标、日志、链路追踪、事件平台中获取信息,建立对系统当前状态的准确理解。第二个是决策层,负责根据感知到的信息,结合预设的目标、策略和知识,选择下一步动作。第三个是执行层,负责通过API、命令行、自动化编排平台,把决策转化为具体操作,并且把操作结果反馈给决策层。第四个是记忆层,负责保存历史故障的处理经验、操作的结果反馈、业务的领域知识,让Agent能够在类似场景中越做越好。第五个是安全层,所有Agent的操作必须有权限边界、审批流程、风险预判和行为审计。这五个层负责把过去分散在监控、日志、流程编排、手工操作中的能力整合起来,形成一个闭环。感知是眼睛、决策是大脑、执行是手脚、记忆是经验、安全是边界,缺少任何一个环节,这个体系都转不起来。2.3 三种落地形态:辅助、协同、自治Agentic Operations不是一步到位的,在真实的工程实践里,我倾向于把它分成三个成熟度级别。第一级是辅助Agent,核心特征是Agent建议、人执行。这个阶段Agent能够理解故障场景,给出处置建议,但它不直接操作生产环境。它的价值在于把分析师和操作手的角色合并了,减少工程师分析上下文的时间。这个级别最容易落地,不用改造现有运维体系,只要把大模型能力和现有AIOps平台做一个融合就可以。第二级是协同Agent,核心特征是人审批、Agent执行。Agent可以操作生产环境,但关键动作需要人来确认。这个级别适合变更操作、故障处置这些需要一定风险管控的场景。协同Agent上线的前提是权限体系要细化到操作级别,而不能停留在系统级别。第三级是自治Agent,核心特征是Agent执行、Agent汇报。系统在预设的范围内自主操作,事后再生成处理报告。自治Agent适合那些标准化程度高、风险可控的故障场景,比如实例重启、流量摘除、自动扩容。从协同到自治,最难的不是技术,而是信任问题——怎么证明Agent的决策是可靠的?怎么兜底?这需要逐步积累信心,从低风险场景慢慢扩大授权范围。3. 从 AIOps 到 Agentic Operations 的演进路径3.1 不是推翻重来,而是能力升级很多人一听到Agentic Operations就觉得是另起炉灶,把之前AIOps的投入全推翻了。实际上不是。Agentic Operations本质上是在AIOps已经建立的感知和分析能力之上升级,之前建设的监控数据平台、异常检测模型、根因定位系统,这些都不会浪费。Agentic Operations里的Agent,在执行理解当前系统状态这个动作的时候,底层仍然需要调用AIOps的异常检测模型;在做根因分析的时候,仍然需要利用AIOps的关联分析和调用链数据。区别在于,以前AIOps输出的分析结论是给人类看的,现在输出是给Agent的决策模块吃的。所以Agentic Operations不是替代AIOps,而是把AIOps从一个终端产品变成了能力底座。这个视角很重要。如果从零开始做Agentic Operations,而不利用已有的AIOps数据管道和算法资产,成本高得离谱。反过来,如果已经有一堆AIOps算法,但不知道怎么和Agent体系关联,这些算法也会变成一个个信息孤岛。所以架构设计上要考虑如何让AI能力可以被编排和调用。3.2 从感知到执行,中间要经历四个阶段的跃迁具体到工程演进,我把它拆成四个阶段。第一阶段是数据基础整合。把监控、日志、链路追踪、变更事件这些数据源统一在一个平台上,并且用统一的数据模型来描述。这一步做不到,后续都是空中楼阁。很多团队做Agentic Operations失败,第一坑就是数据源仍然是割裂的,Agent想查一个服务的完整上下文,需要访问四五个系统,每个系统的格式都不一样。第二阶段是分析能力服务化。把AIOps平台里的异常检测、根因分析、关联分析等这些能力,封装成可以被API调用的服务。这样Agent就可以像使用工具一样调用这些分析能力,而不是读一段文本报告再做判断。这一步最大的难点是让分析结果结构化,比如输出服务A在12:30错误率上升,和部署版本1.2.3有关系,置信度0.85,这个结构化的输出才能真正给Agent用。第三阶段是操作能力工具化。把运维操作进行API化处理,比如重启、回滚、扩容、开关流量、修改配置。没有这一步,Agent就是一个只会分析不会操作的评论员。很多团队卡在安全管控上——运维操作API化了之后,怎么控制权限范围、怎么审批、怎么审计,都必须设计清楚。第四阶段是决策能力的模型化。用大语言模型和编排框架,加上运维知识库,把故障处理的决策逻辑沉淀成策略。这一步要让Agent知道:什么场景下选择诊断流程、什么场景下选择回滚、什么场景下要呼叫人工。这个决策逻辑不再是if-then规则,而是基于海量运维知识的动态推理。3.3 场景闭环:从小的自动化场景开始Agentic Operations的落地,绝对不是直接建一个万能Agent,让它处理所有故障。正确的做法是从一个高频、标准化、低风险的场景开始,比如发布后的自动验证与回滚。这个场景非常典型。一次发布上线之后,Agent自动检测错误率、延迟、饱和度这些黄金指标,如果发现异常,自动触发回滚动作。这个流程逻辑相对简单,每一步都有明确的判断标准,而且回滚是一个标准化操作,风险可控。把它做成一个Agent,让它在小流量场景先跑起来,然后逐步扩展到全量场景。场景跑通之后,再迁移到更复杂的场景,比如多指标联合异常时的分层排查。这时候Agent要理解更多上下文,涉及更多工具的调用,决策逻辑也更复杂。但核心思路不变的——从一个闭环场景拿出来做扎实,跑出信任度,再扩展下一个场景。比试图一次搞定所有故障场景,这个路径靠谱得多。3.4 多Agent协作:运维界的团队重构当单Agent能力成熟之后,一个更有意思的问题出现了——多个Agent之间如何协作。一个全能的运维Agent在现实中很难一次训练成型,更合理的设计是把运维工作拆成多个专业Agent,每个Agent负责一个域:告警处理Agent、日志分析Agent、变更执行Agent、容量规划Agent,等等。多Agent协作的核心是任务编排和上下文传递。比如故障处理时,告警处理Agent发现异常,会生成一个故障工单,然后通知根因分析Agent去分析,分析完毕之后把结论交给变更执行Agent去处置,处置完成后通知通知Agent对外同步。整个过程像一个数字化的运维团队在协作。这个领域还有很多坑。比如Agent之间的通信协议怎么定义?故障工单的数据结构怎么设计?多个Agent同时操作时怎么避免冲突?这些都没有现成的标准答案,更多是结合具体业务场景去摸索。但方向是对的——像团队一样重组运维能力和运维流程,才能让Agentic Operations真正处理复杂故障。4. 实战场景推演:白天和夜晚的两种Agent工作流4.1 白天场景:变更风险评估 Agent先看一个我自己觉得特别有落地价值的场景——变更风险评估。变更,包括发布、配置修改、扩容缩容,是引起故障的最大来源之一。传统做法是运维专家凭经验判断变更影响面,但这个判断过程极其依赖个人经验,而且很难标准化。用Agent来做这个场景,逻辑是完全不同的。变更风险评估Agent会先解析变更内容,比如这次的发布涉及哪个服务、修改了哪些配置项;然后自动检索关联拓扑,把该服务的上游、下游依赖都拉出来;接着分析变更影响面,比如修改了数据库连接池配置,可能影响的调用方有哪些;再结合历史故障库,检查类似变更之前是否出过问题;最后输出变更风险评分、影响服务清单、回滚建议。这个过程原来要一个资深运维花半小时进行分析,Agent可以在1分钟内出结果,而且分析逻辑是沉淀的、可复用的。还有一个好处——Agent可以结合当前系统状态做个性化评估。比如今天这个服务的流量本来就很高,再变更的风险自动上调,这是传统Checklist做不到的。4.2 夜间场景:故障处置 Agent夜间故障处置是运维的梦魇。凌晨两点被叫起来,困得要死,还要快速查日志、看指标、查变更、定位根因、执行恢复。人在这时候的判断力是大打折扣的。Agent在这个场景里能发挥巨大作用,因为它不会困、不会慌、不会漏看数据。故障处置Agent的工作流大致是这样的:接收到告警事件之后,第一步做时效判别,判断这个异常的模式是否和已知故障相似;第二步做关联分析,调取拓扑关联数据和黄金指标,确认影响范围;第三步做变更关联,查询最近一小时的变更记录,看有没有变更时间和故障时间匹配;第四步按预设的处置策略生成操作计划,比如自动回滚相关变更、自动扩容缓解压力;第五步执行操作,并在执行过程中持续观察指标变化;第六步生成故障报告,写清楚时间线、根因、影响、处置动作、后续建议。每一步都对应着确定性动作,每一步之间有清晰的决策判断。相比一个被吵醒的工程师,Agent在凌晨三点保持的处理一致性其实更高。等人工介入的时候,Agent已经完成了初步诊断和低风险处置动作,需要人来处理的只剩下高风险操作和深度根因分析。故障处理的效率和准确度,都会有明显提升。4.3 Agent工作流的核心:状态机与知识沉淀把上面两个场景抽象一下,都能看到一个共同内核——工作流加状态机。Agent的工作流不是大模型自由发挥,而是由一个清晰的流程框架来约束的。每一步做什么,什么情况下进入下一步,什么情况下停止并呼叫人工,这些都是预定义的。大模型的价值在于理解非结构化信息(比如日志内容、故障描述文本)和执行灵活的推理(比如根据当前的系统状态选择优先策略),而流程本身必须稳定,这就像人的SOP一样,规程是确定的,但是具体操作可以灵活应对异常情况。知识沉淀更是Agentic Operations能不能持续变强的关键。每次故障处理完成后,Agent会把这次的处理过程、决策逻辑、执行结果、后续反馈记录下来,形成案例库。下次遇到类似问题,Agent就可以参考历史案例来做判断。案例积累得越多,Agent的处置能力就越强。这个机制和人类工程师的成长路径是完全一致的,通过经历积累经验。5. Agentic Operations 的冷思考:哪些坑必须防5.1 安全第一:自主执行带来的失控风险给Agent开放执行权限,是一件必须谨慎对待的事。Agent的決策能力再强,它始终是一个概率模型,不可能做到100%正确。在故障处置场景,一个错误的操作可能会造成更大的故障——原本只是轻微异常,Agent却误判为需要重启,结果导致服务间歇性不可用。所以Agentic Operations落地的时候,安全层设计是最优先的。第一个原则是最小权限,Agent在各场景中只需要获取执行操作所需的最小权限,能不开的权限坚决不开。第二个原则是审批闸门,高风险操作必须经过人工审批,只有低风险操作才允许自动执行。第三个原则是可回滚能力,Agent执行的每一个操作都要有对应的回滚方案,确保出问题时能快速恢复到操作前的状态。第四个原则是操作审计,Agent的每一次决策和操作都要留痕,输出供事后审计和复盘。这些原则落到技术上,会形成一个治理层——Agent产生的操作请求不是直接发到生产环境的,而是经过一个治理网关,由网关去做权限验证、风险分级、人工审批、操作审计。5.2 幻觉问题:大模型在生产环境里不能自由发挥大模型的幻觉问题是Agentic Operations绕不开的坎。在对话场景里,模型偶而编造一个事实,问题不大;但在运维场景里,一个幻觉可能直接导致错误的根因结论或者错误的变更操作。我对抗幻觉有三个做法。第一,尽量用检索增强生成来约束模型。Agent做判断前,先从知识库、指标库、日志库检索到对应的真实数据,把数据作为模型推理的上下文,而不是让模型凭记忆生成答案。第二,给Agent定义不能做什么的边界。允许Agent在明确的工具清单里选择工具,不允许它自由生成代码或命令。能调用哪些工具、能操作哪些对象,都是预制授权的。第三,设置不确定性检测。当模型自身对判断的置信度较低时,它要主动触发人工介入流程,而不是硬着头皮继续执行。做了这三层防护,幻觉的危害是可以被压制到可控范围的。5.3 运维知识库建设,为什么会失败做AIOps的时候,知识库建设的失败率就很高。到了Agentic Operations,这个问题仍然存在,而且更加突出——Agent的推理质量直接依赖知识库的质量。很多团队在做知识库的时候,会陷入追求大而全的误区,想把所有故障场景的处置手册都写全了再启动Agent,结果项目一拖再拖,最终不了了之。我现在的经验是先窄后宽——先选一个高频故障场景,把它的处置知识梳理出来,形成高质量的知识条,让Agent先跑起来。在Agent运行的过程中,再根据它碰到的实际问题逐步扩展知识库。这样既保证了知识库的质量,又能让Agent快速产生价值。知识库本身也要有生命周期管理,定期校验,发现过时的信息,及时更新。运维知识库的问题,其实不是怎么把文档写出来,而是怎么让知识可以执行。传统的知识库是一篇篇文章,人看着没问题,但Agent用起来很费劲。Agent需要的知识,必须是结构化的——场景、输入条件、判断逻辑、执行动作、回滚方法,这些都要分字段存清楚。否则知识面再广,Agent也用不上。5.4 人机协同与信任曲线最后说一个最容易忽视的问题——人的信任。再高效的Agent,如果运维团队不信任它,落地也会失败。信任建设不是靠宣传,是靠使用。从辅助模式开始,让Agent先做分析建议,人做执行,然后逐步观察Agent的准确率,再慢慢放开授权。根据我的经验,信任曲线会经历几个阶段。刚开始是怀疑阶段,大家觉得这玩意儿靠谱吗,这个时候最需要的是透明的逻辑展示,让Agent把做判断的依据写清楚,而不是给一个黑盒结论。然后是验证阶段,运维人员会拿历史故障来测试Agent,能不能处理已知问题,验证通过之后再慢慢接受。最后是依赖阶段,Agent处理常规故障已经成为常态,人只在关键环节介入。这个过程没有捷径,只有等Agent的准确率和稳定度通过时间检验。但有一点是可以加速的——Agent的决策日志必须完整、可解释、可回溯,让运维人员的每一次信任决策都有据可依。可靠性和可解释性,是信任的基石。6. 运维团队面对的升维挑战,以及第一件该做的事6.1 运维工程师的新技能树与岗位重构Agentic Operations的落地,表面上是对技术架构的改造,深层是对运维团队能力的重新定义。以前运维工程师的核心能力是操作性技能,会登服务器、会查日志、会配监控、会写脚本。但今后,操作性技能会逐渐被Agent取代,或者至少被Agent接管大部分日常工作。运维工程师的核心价值会从会操作转向会定义。这个转变需要新的技能树。首先是运维知识工程能力——怎么把专家经验转化为Agent可以理解的结构化知识;其次是流程编排能力——怎么设计清晰可控的Agent工作流;第三是模型调优能力——怎么利用标注数据和反馈机制持续提升Agent的决策准确率;第四是风险治理能力——怎么在安全边界的约束下最大化Agent的自主性。这不是说运维工程师要人人变成算法专家。更现实的路径是团队内部产生角色分化:一部分人专注Agent工作流设计与运维知识工程,另一部分人专注Agent运行治理与应急响应。Agent不会让运维工程师失业,而是让运维工程师从救火队员变成防灾体系的设计师。6.2 给自己团队的第一张路线图如果你想在团队里启动Agentic Operations,我建议按这个节奏来。第一步,选择一个高频、低风险、边界清晰的场景,把它作为Agentic Operations的试点。第二步,梳理这个场景下现有的监控、分析、操作工具和数据流,看看哪些可以API化、哪些数据还没有打通。第三步,搭建一个最小的Agent闭环,哪怕只是感知→分析→建议的阶段,先把流程跑通。第四步,逐步加入执行能力,在审批可控的前提下,让Agent完成一些低风险操作。第五步,建立评估体系,用平均故障恢复时间、变更成功率、告警误报率这些硬指标,来验证Agent的实际效果。整个落地周期不用太急。以我自己的实践经验,从启动到第一个场景稳定运行,通常需要三个月到半年。但这个投入是值得的——一旦第一个场景跑通,后续场景的复制成本就会大幅下降。Agentic Operations不是一个一步到位的项目,它是一个持续演进的过程。6.3 从AIOps到Agentic Operations,运维价值的一次重新定位写到这里,我相信你已经理解了我的核心判断——AIOps做的是智能化的分析,Agentic Operations做的是智能化的执行,从分析到执行,就是运维从辅助人走向替代人的一个关键跨越。这个跨越的意义,不仅在于技术能力的提升,更在于重新定义了运维岗位的价值——从人围着系统转转向运维专家围绕Agent体系做治理。再往大一点说,Agentic Operations也顺应了一个行业趋势:大模型技术正在从对话工具升级为任务执行体。运维领域由于其高数据密度、强流程性、重操作场景的特性,恰恰是大模型技术最适合的落地土壤之一。而Agentic Operations,就是这片土壤上生长出的最有价值的果实。我对这套体系的前景是偏乐观的。但乐观不等于盲目,我始终相信,任何技术在运维领域的落地,都要遵循一个朴素的原则——先建立信任,再扩大边界。从AIOps到Agentic Operations,不是一句口号,而是一条要靠一场景一场景打磨的实路。
阅读完成 · 觉得有帮助？
