1. 从告警风暴说起为什么传统 AIOps 越用越累凌晨两点手机在床头柜上震个不停。我摸黑抓起来一看监控群里已经刷了上百条消息——某个核心服务的响应时间曲线突然抬头紧接着是超时告警、线程池告警、下游依赖告警、数据库连接数告警五分钟之内涌进来四十多条。值班的同事在群里问了一句有人知道这是哪个变更引起的吗然后是一片沉默。这个场景我相信做运维的人都太熟悉了。过去几年大家应对这种局面的标准答案就是上 AIOps。买一套平台接一堆数据源做指标异常检测、日志聚类、告警收敛、根因分析。听起来很美好但真正落地之后你会发现一个尴尬的事实告警确实被收敛了但问题并没有被解决。平台告诉你这四十条告警大概率来自同一个根因然后呢然后还是得靠人去看、去查、去判断、去操作。这就是我想在这篇里聊清楚的核心问题。AIOps 这个词从诞生到现在差不多有七八年了它解决的是看得见的问题——把海量监控数据变成可理解的信号。但运维工作的终点从来不是看见问题而是把问题处理掉。从看见到处理之间隔着一条巨大的鸿沟而这条鸿沟恰恰是传统 AIOps 迈不过去的。最近一两年行业里开始频繁出现一个新说法Agentic Operations中文一般叫智能体运维或者代理式运维。它不是给 AIOps 换个马甲而是把整个运维自动化的范式往前推了一大步。简单说AIOps 是AI 帮你分析Agentic Operations 是AI 帮你干活。前者是副驾驶后者是能自己握方向盘、看路况、踩油门刹车的司机——当然关键决策还是人在把关。这篇文章我打算从一线运维的视角把从 AIOps 到 Agentic Operations 这条演进路径讲透。包括传统 AIOps 到底卡在哪、Agentic Operations 的核心机制是什么、一个可落地的智能体运维系统该怎么搭、实际跑起来会遇到哪些坑、以及我对这个方向的一些真实判断。不管你是刚接触运维自动化的新人还是已经在 AIOps 平台上投了不少钱的老兵应该都能从中找到对自己有用的东西。2. AIOps 的能力边界它到底解决了什么又卡在了哪里2.1 传统 AIOps 的三层能力模型要理解为什么需要 Agentic Operations得先把 AIOps 本身拆开看。行业里比较公认的划分方式是把 AIOps 的能力分成三层。最底层是数据层负责把指标Metrics、日志Logs、链路追踪Traces、事件Events这些异构数据统一采集、清洗、存储。这一层是地基没有它上面什么都做不了。很多团队在这一层就卡了很久因为数据源太杂、格式太乱、采样率不一致光是做数据对齐就够喝一壶的。中间层是分析层也是 AIOps 最核心的部分。这里面塞满了各种算法时序异常检测、日志模式挖掘、告警关联分析、根因定位、容量预测等等。这一层的目标是把原始数据变成洞察——告诉你哪里不对劲、可能是什么原因。最上层是展示与联动层把分析结果通过看板、告警、工单等形式呈现出来并且和现有的运维流程做对接。比如检测到异常之后自动创建工单、自动通知值班人、自动触发某个预案脚本。这三层模型本身没问题问题出在最上层的联动做得太浅。绝大多数 AIOps 平台的联动本质上还是if-then的规则引擎如果检测到 A 异常就执行 B 动作。这种联动在面对简单、确定、重复的场景时很好用但一旦场景稍微复杂一点规则就爆炸了。2.2 规则引擎的天花板在哪里我举个真实的例子。假设你有一个电商系统大促期间某个商品详情页的响应变慢。传统 AIOps 会怎么处理首先异常检测模块发现响应时间 P99 超过了阈值触发告警。然后告警关联模块发现这个告警和数据库慢查询告警、缓存命中率下降告警在时间上高度相关于是把它们聚成一条。接着根因分析模块根据拓扑关系推测可能是缓存层出了问题。最后联动层根据预设规则执行清理缓存的预案脚本。听起来很顺对吧但现实往往是清理缓存之后问题没解决因为真正的根因是某个新上线的代码逻辑导致缓存 key 设计不合理大量请求穿透到了数据库。而清理缓存这个动作不仅没帮上忙反而让缓存雪崩问题更严重了。这就是规则引擎的根本局限它只能处理已知的已知。你事先想到了什么场景就写什么规则。但运维现场绝大多数故障都是未知的未知——是多个因素叠加出来的、之前没遇到过的组合。规则引擎面对这种情况要么无动于衷要么执行一个错误的动作把事情搞得更糟。更麻烦的是规则会随着系统演进而腐化。半年前写的一条规则当时是对的但现在系统架构变了、依赖关系变了这条规则可能就变成了定时炸弹。而维护这些规则的成本随着数量增长是超线性的。我见过一个团队AIOps 平台里积累了上千条联动规则最后没人敢动因为谁也不知道删掉哪条会引发什么连锁反应。2.3 从分析到行动的断层把问题说得更本质一点传统 AIOps 的能力分布是极度不均衡的。它在分析这一侧投入了 90% 的精力做了各种花哨的算法但在行动这一侧基本还停留在脚本和规则的原始阶段。这个断层带来的直接后果就是分析结果无法有效转化为行动。平台告诉你根因大概率是 X但接下来要做什么、按什么顺序做、做完怎么验证、失败了怎么回滚这些全都得靠人。而人在凌晨两点、面对四十条告警、还带着困意的时候判断力和执行力都是打折扣的。我经常用一个比喻传统 AIOps 就像一个特别厉害的诊断医生能通过各种检查告诉你得了什么病但开药、打针、手术这些事它一概不管全得你自己来。而 Agentic Operations 想做的是让这个医生不仅能诊断还能在授权范围内直接开方、执行、观察疗效、必要时调整方案。这个跨越靠堆算法是堆不出来的它需要一套全新的架构。3. Agentic Operations 的核心机制从规则驱动到目标驱动3.1 智能体到底智能在哪里先说清楚一个概念Agentic Operations 里的Agent不是指某个具体的 AI 模型而是指一个具备自主决策能力的执行单元。它有几个关键特征缺一不可。第一是目标导向。你给它的不是一个具体的指令执行脚本 A而是一个目标让这个服务的 P99 恢复到 200ms 以内。它会自己拆解这个目标规划出需要执行的步骤。第二是工具使用能力。它能调用各种工具——查监控、看日志、执行命令、调 API、发通知——就像人一样。这些工具是它的手和脚。第三是反馈闭环。它执行完一个动作之后会观察结果判断是否接近目标如果没达到就调整策略再试。这个执行-观察-调整的循环是它和规则引擎最本质的区别。第四是边界意识。它知道自己能做什么、不能做什么遇到超出权限或能力范围的情况会主动交给人。这一点极其重要后面会专门讲。把这四点合起来看你会发现 Agentic Operations 的本质是把运维工作从执行预设动作变成了追求预设目标。这是一个范式级的转变。3.2 一个具体的对比告警处理流程的两种形态为了让大家直观感受到差异我用同一个场景——某服务响应时间突增——来对比两种形态的处理流程。传统 AIOps 的流程是这样的异常检测触发告警告警收敛合并相关告警根因分析给出可能原因然后推送给值班人。值班人打开电脑登录各种系统手动排查手动执行修复动作。整个过程中AI 的参与在推送那一刻就结束了。Agentic Operations 的流程则是异常检测触发之后一个运维智能体被激活。它首先自主收集上下文——拉取最近的相关变更记录、查看服务依赖拓扑、检查上下游指标、检索历史相似故障。然后它形成假设——比如可能是最近一次发布引入的问题。接着它验证假设——对比发布前后的指标差异、检查新版本代码的日志特征。如果假设成立它规划动作——回滚发布、观察指标、确认恢复。如果假设不成立它换一个假设继续排查。整个过程中只有在需要执行高风险动作比如回滚生产环境时才会请求人工确认。看出区别了吗传统 AIOps 把 AI 当成分析工具Agentic Operations 把 AI 当成执行主体。前者是人用 AI后者是人管 AI。3.3 支撑智能体运转的四个技术支柱Agentic Operations 不是凭空冒出来的它站在几个技术方向的交汇点上。第一个支柱是大语言模型的推理与规划能力。这是最关键的变量。过去的自动化系统之所以只能做规则是因为机器不理解目标和上下文。而大语言模型第一次让机器具备了理解模糊目标、拆解复杂任务、根据上下文调整策略的能力。它能把让服务恢复正常这种模糊目标拆解成一系列具体的、可执行的步骤。第二个支柱是工具调用与函数编排。光会想不会做没用。现在的智能体框架普遍支持工具调用——把各种运维能力查询、执行、通知封装成标准接口智能体根据需要自主选择调用。这相当于给智能体装上了手和脚。第三个支柱是可观测性数据的标准化。智能体要决策得有足够的信息输入。OpenTelemetry 这类标准的普及让指标、日志、追踪数据的格式趋于统一智能体不需要为每个系统写一套适配逻辑。这是基础设施层面的准备。第四个支柱是执行环境的安全隔离。让 AI 去操作生产环境安全是绕不过去的坎。现在主流的做法是沙箱执行 权限分级 人工审批三层防护。智能体的所有动作都在受控环境中进行高风险动作必须经过人工确认。这套机制成熟了智能体才敢真正落地。3.4 为什么是现在三个条件同时成熟有人可能会问智能体运维这个概念听着挺好为什么以前没人做答案是以前做不了因为缺条件。条件一是模型能力。两三年前的大语言模型推理能力还不足以支撑复杂的运维决策。你让它规划一个多步骤的排查流程它经常逻辑混乱、遗漏关键步骤。而现在的主流模型在复杂推理任务上的表现已经相当可靠了。条件二是工具生态。以前要让 AI 调用运维工具得自己写一大堆胶水代码。现在各种智能体框架、工具协议逐渐成熟接入成本大幅降低。条件三是成本。智能体运维需要频繁调用模型进行推理token 消耗不小。随着模型推理成本持续下降这个经济账才算得过来。一个中等规模的系统如果每次故障处理要消耗几十万 token成本能不能接受是必须算清楚的。这三个条件在最近一两年同时成熟所以 Agentic Operations 才从概念走向了落地。4. 搭建一个可落地的运维智能体架构与关键设计4.1 整体架构五层结构如果要动手搭一套运维智能体系统我建议按下面这个五层结构来设计。这是我在实际项目中验证过、比较稳妥的分层方式。第一层是数据接入层。负责对接各种可观测性数据源——指标系统、日志平台、链路追踪、变更系统、CMDB。这一层的核心任务是把数据标准化让上层智能体不用关心数据来自哪里、格式是什么。建议统一用 OpenTelemetry 的数据模型做中间格式。第二层是工具层。把运维能力封装成智能体可调用的工具。每个工具要有清晰的名称、描述、参数定义和返回值格式。工具的设计有个原则粒度要适中。太粗比如一个修复服务的工具智能体没法灵活组合太细比如一个读取某个文件第 3 行的工具智能体要调用太多次。我一般按一个完整的运维动作来切分比如查询服务指标获取最近变更执行回滚重启实例。第三层是智能体层。这是核心。里面住着各种专职智能体——有的负责告警分诊有的负责根因排查有的负责执行修复有的负责事后复盘。它们之间可以协作也可以有主从关系。这一层要解决的关键问题是任务规划和上下文管理。第四层是编排与治理层。负责智能体之间的调度、权限控制、审批流、审计日志。这一层是管智能体的确保它们不会乱来。第五层是交互层。人机交互的界面——值班人怎么查看智能体的工作过程、怎么介入、怎么审批。这一层的设计直接决定了运维人员愿不愿意用这套系统。4.2 工具设计智能体的手该怎么造工具层是很多人容易忽视、但实际最影响效果的部分。我见过一些项目模型能力很强但工具设计得糟糕导致智能体要么用不对工具要么被工具返回的一堆无用信息淹没。工具设计有几个实操要点。描述要写给模型看不是写给人看。工具的描述文本会直接进入模型的上下文所以它要清晰说明这个工具做什么、什么时候用、参数是什么、返回什么。不要写查询指标这种模糊描述要写根据服务名和时间范围查询该服务的响应时间、错误率、QPS 等核心指标返回时序数据点。返回结果要精简。工具返回的数据会占用模型的上下文窗口。如果一个工具返回几千行日志模型根本处理不过来。正确做法是在工具内部做预处理——聚合、采样、提取关键字段——只返回模型决策真正需要的信息。要有明确的失败语义。工具执行失败时返回的错误信息要能让模型理解为什么失败、能不能重试、要不要换方法。不要返回一个裸的异常堆栈。高风险工具要单独标记。比如执行回滚删除资源这类工具要在定义里明确标注风险等级编排层据此决定是否需要人工审批。下面是一个工具定义的示例结构用 JSON 表示{ name: query_service_metrics, description: 查询指定服务在指定时间范围内的核心指标包括响应时间P50/P95/P99、错误率、QPS。用于判断服务健康状态和异常程度。, parameters: { service_name: 服务名称字符串, start_time: 起始时间ISO8601格式, end_time: 结束时间ISO8601格式, metrics: 要查询的指标列表可选值latency, error_rate, qps }, risk_level: low, returns: 时序数据点数组每个点包含时间戳和值 }4.3 任务规划智能体怎么想任务规划是智能体的核心能力。给定一个目标它要能拆解出可执行的步骤序列。目前主流有两种模式。一种是先规划后执行。智能体先一次性把整个计划列出来然后按顺序执行。这种模式适合流程相对固定的场景比如标准故障排查流程。优点是执行效率高缺点是遇到意外情况不好调整。另一种是边执行边规划。智能体每执行一步根据结果决定下一步做什么。这种模式更灵活适合复杂的、不确定的排查场景。缺点是可能陷入循环或者走弯路。实际落地中我建议混合使用。对于标准化的高频场景比如常见的几类告警用预定义的规划模板智能体在模板框架内做微调。对于罕见的、复杂的场景用自由规划模式让智能体自主探索。这样既保证了高频场景的效率又保留了处理长尾问题的能力。规划过程中有个关键技巧强制智能体显式输出推理过程。让它把我现在观察到什么、我推测是什么原因、我打算做什么、为什么这么做都写出来。这不仅能提升决策质量更重要的是让运维人员能看懂它在想什么建立信任。4.4 上下文管理别让智能体失忆运维排查往往是个长过程涉及大量信息。智能体的上下文窗口是有限的怎么管理这些信息是个技术活。我的经验是分三层管理。第一层是当前任务上下文只保留当前正在处理的这一步所需的信息保持精简。第二层是任务记忆把已经排查过的假设、执行过的动作、观察到的结果用结构化的方式记录下来需要时检索。第三层是长期知识把历史故障的处理经验沉淀成知识库供所有智能体共享。这里有个容易踩的坑不要把原始数据一股脑塞进上下文。我见过一个实现把查询到的所有日志都塞给模型结果模型被无关信息干扰推理质量直线下降。正确做法是让工具层做预处理只把关键信息传给模型。4.5 权限与审批让智能体有边界这是整个系统里最不能省的部分。让 AI 操作生产环境安全底线必须守住。我的做法是三级权限模型。只读操作查询指标、看日志完全放开智能体自主执行。低风险写操作重启无状态实例、清理缓存可以自动执行但要记录审计日志。高风险操作回滚发布、改配置、动数据库必须人工审批智能体只能发起申请不能直接执行。审批流程的设计也有讲究。不要简单地弹个是否同意的框而要把智能体的完整推理过程展示给审批人——它观察到了什么、推测是什么原因、打算做什么、预期效果是什么、失败了怎么回滚。审批人基于这些信息做判断而不是盲目点同意。还有一点所有智能体的动作都要可追溯。谁发起的、什么时候、基于什么信息、执行了什么、结果如何全都要记录。这既是安全要求也是后续优化系统的数据来源。5. 实战中的坑智能体运维落地会遇到什么5.1 坑一智能体过度自信做了错误的动作这是最危险的一类问题。智能体基于不完整的信息得出了一个错误的结论然后自信满满地执行了修复动作结果把问题搞得更糟。我遇到过一个案例某服务的错误率上升智能体排查后发现是数据库连接池耗尽于是它判断需要扩容连接池直接修改了配置。但实际上连接池耗尽的根因是上游有个服务在疯狂重试导致连接被占满。扩容连接池只是治标而且掩盖了真正的问题导致上游的重试风暴持续了更久。应对方法一是强制验证假设。智能体在形成根因假设后必须找到至少两个独立的证据支撑才能进入执行阶段。二是高风险动作必须审批。像改配置这种动作无论智能体多有把握都要人确认。三是设置熔断机制。如果智能体连续几次动作都没有改善指标强制它停下来交给人处理。5.2 坑二工具返回的信息质量太差智能体的决策质量很大程度上取决于它拿到的信息质量。如果工具返回的数据又乱又多智能体就会迷失。常见的问题包括日志工具返回了海量无关日志、指标工具返回的粒度太细导致数据点过多、拓扑工具返回的依赖关系不完整。这些问题在传统监控场景下可能不明显因为是人看的人会自己过滤但对智能体来说是致命的。应对方法把工具当成产品来设计而不是接口。每个工具都要考虑模型拿到这个返回结果能不能做出有效决策。该聚合的聚合、该采样的采样、该排序的排序。我一般会要求每个工具在返回前做一次信息压缩把数据量控制在模型能有效处理的范围内。5.3 坑三智能体和现有流程两张皮很多团队上了智能体系统之后发现它和现有的运维流程是割裂的。智能体在自己的世界里跑运维人员还是用原来的工单系统、原来的告警群两边信息不同步。这个问题的根源是没有把智能体嵌入现有流程而是把它当成一个独立的系统。正确做法是让智能体成为现有流程的增强层——它接收现有告警系统的输入它的处理结果回写到现有工单系统它的审批请求走现有审批流。运维人员不需要切换系统就能看到智能体的工作。应对方法在项目初期就梳理清楚现有的运维流程找到智能体可以切入的接口点。不要试图用智能体替换整个流程而是先在一个环节上做增强跑通了再扩展。5.4 坑四成本失控智能体运维的 token 消耗可能远超预期。一次复杂的故障排查智能体可能要调用几十次模型每次都要带上大量上下文。如果没做好优化成本会很难看。应对方法一是分级处理。简单场景用规则或小模型处理只有复杂场景才动用大模型。二是缓存复用。相似的排查场景可以复用之前的推理结果。三是上下文精简。严格控制每次调用带的信息量能摘要的摘要能结构化的结构化。四是设置预算上限。给每个智能体或每个时间段设置 token 预算超了就降级处理。5.5 坑五运维人员不信任、不愿用这是最软但最要命的问题。技术做得再好运维人员不买账系统就是摆设。不信任的来源通常有两个一是看不懂智能体在干什么觉得它是个黑盒二是被智能体坑过某次它做了错误动作导致故障扩大。应对方法一是透明化。把智能体的推理过程、决策依据、执行动作全部展示出来让人能看懂。二是渐进式授权。一开始只让智能体做只读操作和建议人执行建立信任后再逐步放开低风险写操作。三是保留人工接管。任何时候运维人员都能一键接管终止智能体的动作。四是做好复盘。每次智能体处理完故障都做一次复盘把好的和不好的都记录下来持续优化。6. 从 AIOps 到 Agentic Operations 的迁移路径6.1 不要推倒重来如果你已经有一套 AIOps 平台不要想着推倒重来。Agentic Operations 不是替代 AIOps而是在它之上加一层行动能力。你现有的数据采集、异常检测、告警收敛这些能力都是智能体决策的输入是宝贵的资产。正确的迁移思路是保留 AIOps 的分析能力在其上叠加智能体层。让 AIOps 继续负责看见问题智能体负责处理问题。两者通过标准接口对接。6.2 分阶段推进我建议分三个阶段推进。第一阶段智能助手。智能体只做只读操作帮运维人员收集信息、分析问题、给出建议。这个阶段的目标是让运维人员熟悉智能体、建立信任。这个阶段大概需要一到两个月。第二阶段半自动处理。智能体可以自动执行低风险动作高风险动作走审批。这个阶段的目标是验证智能体的决策质量积累成功案例。这个阶段大概需要三到六个月。第三阶段自主处理。对于高频、标准化的场景智能体可以端到端自主处理人只在异常时介入。这个阶段的目标是提升整体效率把运维人员从重复劳动中解放出来。每个阶段都要有明确的毕业标准——比如智能体在某个场景下的处理准确率达到多少、人工介入率降到多少才能进入下一阶段。6.3 选一个合适的切入点不要一上来就做全场景覆盖选一个高频、标准化、风险可控的场景切入。什么样的场景合适高频意味着能快速积累数据、验证效果。标准化意味着流程相对固定、智能体容易上手。风险可控意味着即使智能体出错后果也不严重。我一般推荐从告警分诊这个场景切入。它的任务是收到告警后自动收集相关上下文判断告警的严重程度和可能原因决定是立即通知人、还是自动处理、还是先观察。这个场景高频、相对标准化、风险低最坏情况就是误判了严重程度非常适合作为第一个落地场景。6.4 度量体系怎么建没有度量就没有优化。智能体运维系统需要一套自己的度量体系。我建议关注这几个核心指标自动处理率多少比例的故障由智能体端到端处理、处理准确率智能体的处理结果正确的比例、平均处理时长从告警触发到问题解决的时间、人工介入率多少比例需要人介入、误操作率智能体执行了错误动作的比例、成本每次处理的 token 消耗。这些指标要持续跟踪作为优化系统的依据。特别是误操作率这是安全底线一旦上升就要立即排查原因。7. 我对这个方向的一些真实判断聊了这么多技术和实操最后说几句我个人的判断不一定对但都是从实际项目里摸出来的感受。第一Agentic Operations 不是万能药它解决的是行动效率问题不是理解深度问题。如果你的可观测性数据本身就不全、不准智能体再聪明也是垃圾进垃圾出。所以数据基础该补还得补别指望智能体帮你跳过这一步。第二人的角色会变但不会消失。智能体接管的是重复性的排查和执行工作但架构设计、容量规划、复杂故障的创造性解决这些还是得靠人。运维人员要从操作工转型成智能体的管理者和训练者。这个转型对很多人来说不容易但方向是明确的。第三短期内不要追求完全自主。让 AI 完全自主地操作生产环境风险和收益不成正比。至少在可预见的未来人在环上human-in-the-loop还是最稳妥的模式。智能体负责 90% 的常规工作人负责 10% 的关键决策这个配比是比较现实的。第四这个方向的门槛比想象中高。它不是接个模型、写几个工具就能跑起来的。它需要数据、工具、模型、流程、组织多个方面的配合。小团队如果资源有限建议先从智能助手这种轻量级形态入手别一上来就搞大而全的系统。第五别被概念忽悠回到问题本身。不管是叫 AIOps 还是 Agentic Operations核心都是用技术手段提升运维效率、降低故障影响。判断一个方案好不好就看它是不是真的解决了你的实际问题而不是看它用了多新的概念。我见过太多团队为了追概念上了一堆用不起来的系统最后反而增加了负担。我在实际项目里最大的体会是智能体运维的成败技术只占一半另一半是组织和流程。你得让运维人员愿意用、敢用、会用得把智能体嵌入现有的工作流得建立配套的度量和管理机制。这些软的东西往往比模型选型、架构设计更决定成败。如果你正在考虑往这个方向走我的建议是先别急着买平台、搭系统先花时间梳理清楚自己的运维流程找到最痛的那个点想清楚智能体在这个点上能带来什么价值。然后小步快跑从一个场景做起跑通了再扩展。这个领域变化很快保持学习、保持务实比什么都重要。 
长河君 · 2026/10/18 5:40:54 · 阅读 1.2k 从AIOps到Agentic Operations：智能体运维的架构设计与落地实践
1. 从告警风暴说起为什么传统 AIOps 越用越累凌晨两点手机在床头柜上震个不停。我摸黑抓起来一看监控群里已经刷了上百条消息——某个核心服务的响应时间曲线突然抬头紧接着是超时告警、线程池告警、下游依赖告警、数据库连接数告警五分钟之内涌进来四十多条。值班的同事在群里问了一句有人知道这是哪个变更引起的吗然后是一片沉默。这个场景我相信做运维的人都太熟悉了。过去几年大家应对这种局面的标准答案就是上 AIOps。买一套平台接一堆数据源做指标异常检测、日志聚类、告警收敛、根因分析。听起来很美好但真正落地之后你会发现一个尴尬的事实告警确实被收敛了但问题并没有被解决。平台告诉你这四十条告警大概率来自同一个根因然后呢然后还是得靠人去看、去查、去判断、去操作。这就是我想在这篇里聊清楚的核心问题。AIOps 这个词从诞生到现在差不多有七八年了它解决的是看得见的问题——把海量监控数据变成可理解的信号。但运维工作的终点从来不是看见问题而是把问题处理掉。从看见到处理之间隔着一条巨大的鸿沟而这条鸿沟恰恰是传统 AIOps 迈不过去的。最近一两年行业里开始频繁出现一个新说法Agentic Operations中文一般叫智能体运维或者代理式运维。它不是给 AIOps 换个马甲而是把整个运维自动化的范式往前推了一大步。简单说AIOps 是AI 帮你分析Agentic Operations 是AI 帮你干活。前者是副驾驶后者是能自己握方向盘、看路况、踩油门刹车的司机——当然关键决策还是人在把关。这篇文章我打算从一线运维的视角把从 AIOps 到 Agentic Operations 这条演进路径讲透。包括传统 AIOps 到底卡在哪、Agentic Operations 的核心机制是什么、一个可落地的智能体运维系统该怎么搭、实际跑起来会遇到哪些坑、以及我对这个方向的一些真实判断。不管你是刚接触运维自动化的新人还是已经在 AIOps 平台上投了不少钱的老兵应该都能从中找到对自己有用的东西。2. AIOps 的能力边界它到底解决了什么又卡在了哪里2.1 传统 AIOps 的三层能力模型要理解为什么需要 Agentic Operations得先把 AIOps 本身拆开看。行业里比较公认的划分方式是把 AIOps 的能力分成三层。最底层是数据层负责把指标Metrics、日志Logs、链路追踪Traces、事件Events这些异构数据统一采集、清洗、存储。这一层是地基没有它上面什么都做不了。很多团队在这一层就卡了很久因为数据源太杂、格式太乱、采样率不一致光是做数据对齐就够喝一壶的。中间层是分析层也是 AIOps 最核心的部分。这里面塞满了各种算法时序异常检测、日志模式挖掘、告警关联分析、根因定位、容量预测等等。这一层的目标是把原始数据变成洞察——告诉你哪里不对劲、可能是什么原因。最上层是展示与联动层把分析结果通过看板、告警、工单等形式呈现出来并且和现有的运维流程做对接。比如检测到异常之后自动创建工单、自动通知值班人、自动触发某个预案脚本。这三层模型本身没问题问题出在最上层的联动做得太浅。绝大多数 AIOps 平台的联动本质上还是if-then的规则引擎如果检测到 A 异常就执行 B 动作。这种联动在面对简单、确定、重复的场景时很好用但一旦场景稍微复杂一点规则就爆炸了。2.2 规则引擎的天花板在哪里我举个真实的例子。假设你有一个电商系统大促期间某个商品详情页的响应变慢。传统 AIOps 会怎么处理首先异常检测模块发现响应时间 P99 超过了阈值触发告警。然后告警关联模块发现这个告警和数据库慢查询告警、缓存命中率下降告警在时间上高度相关于是把它们聚成一条。接着根因分析模块根据拓扑关系推测可能是缓存层出了问题。最后联动层根据预设规则执行清理缓存的预案脚本。听起来很顺对吧但现实往往是清理缓存之后问题没解决因为真正的根因是某个新上线的代码逻辑导致缓存 key 设计不合理大量请求穿透到了数据库。而清理缓存这个动作不仅没帮上忙反而让缓存雪崩问题更严重了。这就是规则引擎的根本局限它只能处理已知的已知。你事先想到了什么场景就写什么规则。但运维现场绝大多数故障都是未知的未知——是多个因素叠加出来的、之前没遇到过的组合。规则引擎面对这种情况要么无动于衷要么执行一个错误的动作把事情搞得更糟。更麻烦的是规则会随着系统演进而腐化。半年前写的一条规则当时是对的但现在系统架构变了、依赖关系变了这条规则可能就变成了定时炸弹。而维护这些规则的成本随着数量增长是超线性的。我见过一个团队AIOps 平台里积累了上千条联动规则最后没人敢动因为谁也不知道删掉哪条会引发什么连锁反应。2.3 从分析到行动的断层把问题说得更本质一点传统 AIOps 的能力分布是极度不均衡的。它在分析这一侧投入了 90% 的精力做了各种花哨的算法但在行动这一侧基本还停留在脚本和规则的原始阶段。这个断层带来的直接后果就是分析结果无法有效转化为行动。平台告诉你根因大概率是 X但接下来要做什么、按什么顺序做、做完怎么验证、失败了怎么回滚这些全都得靠人。而人在凌晨两点、面对四十条告警、还带着困意的时候判断力和执行力都是打折扣的。我经常用一个比喻传统 AIOps 就像一个特别厉害的诊断医生能通过各种检查告诉你得了什么病但开药、打针、手术这些事它一概不管全得你自己来。而 Agentic Operations 想做的是让这个医生不仅能诊断还能在授权范围内直接开方、执行、观察疗效、必要时调整方案。这个跨越靠堆算法是堆不出来的它需要一套全新的架构。3. Agentic Operations 的核心机制从规则驱动到目标驱动3.1 智能体到底智能在哪里先说清楚一个概念Agentic Operations 里的Agent不是指某个具体的 AI 模型而是指一个具备自主决策能力的执行单元。它有几个关键特征缺一不可。第一是目标导向。你给它的不是一个具体的指令执行脚本 A而是一个目标让这个服务的 P99 恢复到 200ms 以内。它会自己拆解这个目标规划出需要执行的步骤。第二是工具使用能力。它能调用各种工具——查监控、看日志、执行命令、调 API、发通知——就像人一样。这些工具是它的手和脚。第三是反馈闭环。它执行完一个动作之后会观察结果判断是否接近目标如果没达到就调整策略再试。这个执行-观察-调整的循环是它和规则引擎最本质的区别。第四是边界意识。它知道自己能做什么、不能做什么遇到超出权限或能力范围的情况会主动交给人。这一点极其重要后面会专门讲。把这四点合起来看你会发现 Agentic Operations 的本质是把运维工作从执行预设动作变成了追求预设目标。这是一个范式级的转变。3.2 一个具体的对比告警处理流程的两种形态为了让大家直观感受到差异我用同一个场景——某服务响应时间突增——来对比两种形态的处理流程。传统 AIOps 的流程是这样的异常检测触发告警告警收敛合并相关告警根因分析给出可能原因然后推送给值班人。值班人打开电脑登录各种系统手动排查手动执行修复动作。整个过程中AI 的参与在推送那一刻就结束了。Agentic Operations 的流程则是异常检测触发之后一个运维智能体被激活。它首先自主收集上下文——拉取最近的相关变更记录、查看服务依赖拓扑、检查上下游指标、检索历史相似故障。然后它形成假设——比如可能是最近一次发布引入的问题。接着它验证假设——对比发布前后的指标差异、检查新版本代码的日志特征。如果假设成立它规划动作——回滚发布、观察指标、确认恢复。如果假设不成立它换一个假设继续排查。整个过程中只有在需要执行高风险动作比如回滚生产环境时才会请求人工确认。看出区别了吗传统 AIOps 把 AI 当成分析工具Agentic Operations 把 AI 当成执行主体。前者是人用 AI后者是人管 AI。3.3 支撑智能体运转的四个技术支柱Agentic Operations 不是凭空冒出来的它站在几个技术方向的交汇点上。第一个支柱是大语言模型的推理与规划能力。这是最关键的变量。过去的自动化系统之所以只能做规则是因为机器不理解目标和上下文。而大语言模型第一次让机器具备了理解模糊目标、拆解复杂任务、根据上下文调整策略的能力。它能把让服务恢复正常这种模糊目标拆解成一系列具体的、可执行的步骤。第二个支柱是工具调用与函数编排。光会想不会做没用。现在的智能体框架普遍支持工具调用——把各种运维能力查询、执行、通知封装成标准接口智能体根据需要自主选择调用。这相当于给智能体装上了手和脚。第三个支柱是可观测性数据的标准化。智能体要决策得有足够的信息输入。OpenTelemetry 这类标准的普及让指标、日志、追踪数据的格式趋于统一智能体不需要为每个系统写一套适配逻辑。这是基础设施层面的准备。第四个支柱是执行环境的安全隔离。让 AI 去操作生产环境安全是绕不过去的坎。现在主流的做法是沙箱执行 权限分级 人工审批三层防护。智能体的所有动作都在受控环境中进行高风险动作必须经过人工确认。这套机制成熟了智能体才敢真正落地。3.4 为什么是现在三个条件同时成熟有人可能会问智能体运维这个概念听着挺好为什么以前没人做答案是以前做不了因为缺条件。条件一是模型能力。两三年前的大语言模型推理能力还不足以支撑复杂的运维决策。你让它规划一个多步骤的排查流程它经常逻辑混乱、遗漏关键步骤。而现在的主流模型在复杂推理任务上的表现已经相当可靠了。条件二是工具生态。以前要让 AI 调用运维工具得自己写一大堆胶水代码。现在各种智能体框架、工具协议逐渐成熟接入成本大幅降低。条件三是成本。智能体运维需要频繁调用模型进行推理token 消耗不小。随着模型推理成本持续下降这个经济账才算得过来。一个中等规模的系统如果每次故障处理要消耗几十万 token成本能不能接受是必须算清楚的。这三个条件在最近一两年同时成熟所以 Agentic Operations 才从概念走向了落地。4. 搭建一个可落地的运维智能体架构与关键设计4.1 整体架构五层结构如果要动手搭一套运维智能体系统我建议按下面这个五层结构来设计。这是我在实际项目中验证过、比较稳妥的分层方式。第一层是数据接入层。负责对接各种可观测性数据源——指标系统、日志平台、链路追踪、变更系统、CMDB。这一层的核心任务是把数据标准化让上层智能体不用关心数据来自哪里、格式是什么。建议统一用 OpenTelemetry 的数据模型做中间格式。第二层是工具层。把运维能力封装成智能体可调用的工具。每个工具要有清晰的名称、描述、参数定义和返回值格式。工具的设计有个原则粒度要适中。太粗比如一个修复服务的工具智能体没法灵活组合太细比如一个读取某个文件第 3 行的工具智能体要调用太多次。我一般按一个完整的运维动作来切分比如查询服务指标获取最近变更执行回滚重启实例。第三层是智能体层。这是核心。里面住着各种专职智能体——有的负责告警分诊有的负责根因排查有的负责执行修复有的负责事后复盘。它们之间可以协作也可以有主从关系。这一层要解决的关键问题是任务规划和上下文管理。第四层是编排与治理层。负责智能体之间的调度、权限控制、审批流、审计日志。这一层是管智能体的确保它们不会乱来。第五层是交互层。人机交互的界面——值班人怎么查看智能体的工作过程、怎么介入、怎么审批。这一层的设计直接决定了运维人员愿不愿意用这套系统。4.2 工具设计智能体的手该怎么造工具层是很多人容易忽视、但实际最影响效果的部分。我见过一些项目模型能力很强但工具设计得糟糕导致智能体要么用不对工具要么被工具返回的一堆无用信息淹没。工具设计有几个实操要点。描述要写给模型看不是写给人看。工具的描述文本会直接进入模型的上下文所以它要清晰说明这个工具做什么、什么时候用、参数是什么、返回什么。不要写查询指标这种模糊描述要写根据服务名和时间范围查询该服务的响应时间、错误率、QPS 等核心指标返回时序数据点。返回结果要精简。工具返回的数据会占用模型的上下文窗口。如果一个工具返回几千行日志模型根本处理不过来。正确做法是在工具内部做预处理——聚合、采样、提取关键字段——只返回模型决策真正需要的信息。要有明确的失败语义。工具执行失败时返回的错误信息要能让模型理解为什么失败、能不能重试、要不要换方法。不要返回一个裸的异常堆栈。高风险工具要单独标记。比如执行回滚删除资源这类工具要在定义里明确标注风险等级编排层据此决定是否需要人工审批。下面是一个工具定义的示例结构用 JSON 表示{ name: query_service_metrics, description: 查询指定服务在指定时间范围内的核心指标包括响应时间P50/P95/P99、错误率、QPS。用于判断服务健康状态和异常程度。, parameters: { service_name: 服务名称字符串, start_time: 起始时间ISO8601格式, end_time: 结束时间ISO8601格式, metrics: 要查询的指标列表可选值latency, error_rate, qps }, risk_level: low, returns: 时序数据点数组每个点包含时间戳和值 }4.3 任务规划智能体怎么想任务规划是智能体的核心能力。给定一个目标它要能拆解出可执行的步骤序列。目前主流有两种模式。一种是先规划后执行。智能体先一次性把整个计划列出来然后按顺序执行。这种模式适合流程相对固定的场景比如标准故障排查流程。优点是执行效率高缺点是遇到意外情况不好调整。另一种是边执行边规划。智能体每执行一步根据结果决定下一步做什么。这种模式更灵活适合复杂的、不确定的排查场景。缺点是可能陷入循环或者走弯路。实际落地中我建议混合使用。对于标准化的高频场景比如常见的几类告警用预定义的规划模板智能体在模板框架内做微调。对于罕见的、复杂的场景用自由规划模式让智能体自主探索。这样既保证了高频场景的效率又保留了处理长尾问题的能力。规划过程中有个关键技巧强制智能体显式输出推理过程。让它把我现在观察到什么、我推测是什么原因、我打算做什么、为什么这么做都写出来。这不仅能提升决策质量更重要的是让运维人员能看懂它在想什么建立信任。4.4 上下文管理别让智能体失忆运维排查往往是个长过程涉及大量信息。智能体的上下文窗口是有限的怎么管理这些信息是个技术活。我的经验是分三层管理。第一层是当前任务上下文只保留当前正在处理的这一步所需的信息保持精简。第二层是任务记忆把已经排查过的假设、执行过的动作、观察到的结果用结构化的方式记录下来需要时检索。第三层是长期知识把历史故障的处理经验沉淀成知识库供所有智能体共享。这里有个容易踩的坑不要把原始数据一股脑塞进上下文。我见过一个实现把查询到的所有日志都塞给模型结果模型被无关信息干扰推理质量直线下降。正确做法是让工具层做预处理只把关键信息传给模型。4.5 权限与审批让智能体有边界这是整个系统里最不能省的部分。让 AI 操作生产环境安全底线必须守住。我的做法是三级权限模型。只读操作查询指标、看日志完全放开智能体自主执行。低风险写操作重启无状态实例、清理缓存可以自动执行但要记录审计日志。高风险操作回滚发布、改配置、动数据库必须人工审批智能体只能发起申请不能直接执行。审批流程的设计也有讲究。不要简单地弹个是否同意的框而要把智能体的完整推理过程展示给审批人——它观察到了什么、推测是什么原因、打算做什么、预期效果是什么、失败了怎么回滚。审批人基于这些信息做判断而不是盲目点同意。还有一点所有智能体的动作都要可追溯。谁发起的、什么时候、基于什么信息、执行了什么、结果如何全都要记录。这既是安全要求也是后续优化系统的数据来源。5. 实战中的坑智能体运维落地会遇到什么5.1 坑一智能体过度自信做了错误的动作这是最危险的一类问题。智能体基于不完整的信息得出了一个错误的结论然后自信满满地执行了修复动作结果把问题搞得更糟。我遇到过一个案例某服务的错误率上升智能体排查后发现是数据库连接池耗尽于是它判断需要扩容连接池直接修改了配置。但实际上连接池耗尽的根因是上游有个服务在疯狂重试导致连接被占满。扩容连接池只是治标而且掩盖了真正的问题导致上游的重试风暴持续了更久。应对方法一是强制验证假设。智能体在形成根因假设后必须找到至少两个独立的证据支撑才能进入执行阶段。二是高风险动作必须审批。像改配置这种动作无论智能体多有把握都要人确认。三是设置熔断机制。如果智能体连续几次动作都没有改善指标强制它停下来交给人处理。5.2 坑二工具返回的信息质量太差智能体的决策质量很大程度上取决于它拿到的信息质量。如果工具返回的数据又乱又多智能体就会迷失。常见的问题包括日志工具返回了海量无关日志、指标工具返回的粒度太细导致数据点过多、拓扑工具返回的依赖关系不完整。这些问题在传统监控场景下可能不明显因为是人看的人会自己过滤但对智能体来说是致命的。应对方法把工具当成产品来设计而不是接口。每个工具都要考虑模型拿到这个返回结果能不能做出有效决策。该聚合的聚合、该采样的采样、该排序的排序。我一般会要求每个工具在返回前做一次信息压缩把数据量控制在模型能有效处理的范围内。5.3 坑三智能体和现有流程两张皮很多团队上了智能体系统之后发现它和现有的运维流程是割裂的。智能体在自己的世界里跑运维人员还是用原来的工单系统、原来的告警群两边信息不同步。这个问题的根源是没有把智能体嵌入现有流程而是把它当成一个独立的系统。正确做法是让智能体成为现有流程的增强层——它接收现有告警系统的输入它的处理结果回写到现有工单系统它的审批请求走现有审批流。运维人员不需要切换系统就能看到智能体的工作。应对方法在项目初期就梳理清楚现有的运维流程找到智能体可以切入的接口点。不要试图用智能体替换整个流程而是先在一个环节上做增强跑通了再扩展。5.4 坑四成本失控智能体运维的 token 消耗可能远超预期。一次复杂的故障排查智能体可能要调用几十次模型每次都要带上大量上下文。如果没做好优化成本会很难看。应对方法一是分级处理。简单场景用规则或小模型处理只有复杂场景才动用大模型。二是缓存复用。相似的排查场景可以复用之前的推理结果。三是上下文精简。严格控制每次调用带的信息量能摘要的摘要能结构化的结构化。四是设置预算上限。给每个智能体或每个时间段设置 token 预算超了就降级处理。5.5 坑五运维人员不信任、不愿用这是最软但最要命的问题。技术做得再好运维人员不买账系统就是摆设。不信任的来源通常有两个一是看不懂智能体在干什么觉得它是个黑盒二是被智能体坑过某次它做了错误动作导致故障扩大。应对方法一是透明化。把智能体的推理过程、决策依据、执行动作全部展示出来让人能看懂。二是渐进式授权。一开始只让智能体做只读操作和建议人执行建立信任后再逐步放开低风险写操作。三是保留人工接管。任何时候运维人员都能一键接管终止智能体的动作。四是做好复盘。每次智能体处理完故障都做一次复盘把好的和不好的都记录下来持续优化。6. 从 AIOps 到 Agentic Operations 的迁移路径6.1 不要推倒重来如果你已经有一套 AIOps 平台不要想着推倒重来。Agentic Operations 不是替代 AIOps而是在它之上加一层行动能力。你现有的数据采集、异常检测、告警收敛这些能力都是智能体决策的输入是宝贵的资产。正确的迁移思路是保留 AIOps 的分析能力在其上叠加智能体层。让 AIOps 继续负责看见问题智能体负责处理问题。两者通过标准接口对接。6.2 分阶段推进我建议分三个阶段推进。第一阶段智能助手。智能体只做只读操作帮运维人员收集信息、分析问题、给出建议。这个阶段的目标是让运维人员熟悉智能体、建立信任。这个阶段大概需要一到两个月。第二阶段半自动处理。智能体可以自动执行低风险动作高风险动作走审批。这个阶段的目标是验证智能体的决策质量积累成功案例。这个阶段大概需要三到六个月。第三阶段自主处理。对于高频、标准化的场景智能体可以端到端自主处理人只在异常时介入。这个阶段的目标是提升整体效率把运维人员从重复劳动中解放出来。每个阶段都要有明确的毕业标准——比如智能体在某个场景下的处理准确率达到多少、人工介入率降到多少才能进入下一阶段。6.3 选一个合适的切入点不要一上来就做全场景覆盖选一个高频、标准化、风险可控的场景切入。什么样的场景合适高频意味着能快速积累数据、验证效果。标准化意味着流程相对固定、智能体容易上手。风险可控意味着即使智能体出错后果也不严重。我一般推荐从告警分诊这个场景切入。它的任务是收到告警后自动收集相关上下文判断告警的严重程度和可能原因决定是立即通知人、还是自动处理、还是先观察。这个场景高频、相对标准化、风险低最坏情况就是误判了严重程度非常适合作为第一个落地场景。6.4 度量体系怎么建没有度量就没有优化。智能体运维系统需要一套自己的度量体系。我建议关注这几个核心指标自动处理率多少比例的故障由智能体端到端处理、处理准确率智能体的处理结果正确的比例、平均处理时长从告警触发到问题解决的时间、人工介入率多少比例需要人介入、误操作率智能体执行了错误动作的比例、成本每次处理的 token 消耗。这些指标要持续跟踪作为优化系统的依据。特别是误操作率这是安全底线一旦上升就要立即排查原因。7. 我对这个方向的一些真实判断聊了这么多技术和实操最后说几句我个人的判断不一定对但都是从实际项目里摸出来的感受。第一Agentic Operations 不是万能药它解决的是行动效率问题不是理解深度问题。如果你的可观测性数据本身就不全、不准智能体再聪明也是垃圾进垃圾出。所以数据基础该补还得补别指望智能体帮你跳过这一步。第二人的角色会变但不会消失。智能体接管的是重复性的排查和执行工作但架构设计、容量规划、复杂故障的创造性解决这些还是得靠人。运维人员要从操作工转型成智能体的管理者和训练者。这个转型对很多人来说不容易但方向是明确的。第三短期内不要追求完全自主。让 AI 完全自主地操作生产环境风险和收益不成正比。至少在可预见的未来人在环上human-in-the-loop还是最稳妥的模式。智能体负责 90% 的常规工作人负责 10% 的关键决策这个配比是比较现实的。第四这个方向的门槛比想象中高。它不是接个模型、写几个工具就能跑起来的。它需要数据、工具、模型、流程、组织多个方面的配合。小团队如果资源有限建议先从智能助手这种轻量级形态入手别一上来就搞大而全的系统。第五别被概念忽悠回到问题本身。不管是叫 AIOps 还是 Agentic Operations核心都是用技术手段提升运维效率、降低故障影响。判断一个方案好不好就看它是不是真的解决了你的实际问题而不是看它用了多新的概念。我见过太多团队为了追概念上了一堆用不起来的系统最后反而增加了负担。我在实际项目里最大的体会是智能体运维的成败技术只占一半另一半是组织和流程。你得让运维人员愿意用、敢用、会用得把智能体嵌入现有的工作流得建立配套的度量和管理机制。这些软的东西往往比模型选型、架构设计更决定成败。如果你正在考虑往这个方向走我的建议是先别急着买平台、搭系统先花时间梳理清楚自己的运维流程找到最痛的那个点想清楚智能体在这个点上能带来什么价值。然后小步快跑从一个场景做起跑通了再扩展。这个领域变化很快保持学习、保持务实比什么都重要。