1. 先讲清楚：AIOps 和 Agentic Operations 到底差在哪
这几年“AIOps”这个词在我眼里，已经从最初的新鲜概念，慢慢变成了一个有点尴尬的行业术语。说它尴尬，是因为大家嘴里都在讲，但真正把它落到生产环境、并且长期跑出价值的团队，说实话不多。我自己见过不少项目，最后的落地形态基本是：告警风暴压缩了一下、日志做了一点聚类、指标加了一个异常检测，然后产出一个大屏或者一个周报，告诉管理层“我们上 AI 了”。但真到了凌晨三点系统出故障的时候，值班同学还是被一通电话叫起来，盯着十几个页面来回点，人工判断根因，再手动去操作。
这种情况持续了很长时间，我一直觉得哪里不对，但又说不太清楚问题出在哪个环节。直到最近一两年，行业内开始频繁出现一个新方向——Agentic Operations，直译过来是“智能体驱动的运维”，我更愿意把它理解为：让 AI 不只是“看”和“说”，而是真的能“想”和“做”。
先说一个最直观的差异。传统 AIOps 的定位更像一个“超级辅助”：它负责发现异常、给出提示、甚至给出建议，但最终的决策按钮和操作动作，必须由人来按下。而 Agentic Operations 的定位是一个“具备执行能力的智能体”：它不仅能发现问题和分析根因，还能在一个明确的权限边界内，直接去查询、操作、验证、回滚，把故障处理的整个闭环跑起来。人从“操作者”变成“监督者”。
这个转变听起来好像只是往前挪了一步，但实际落地的时候，背后的逻辑、架构、风险控制完全不是一个量级。这也是我最近一直在重新理解 AI 运维的原因——我们需要换一套思路来看这件事。
1.1 我对 AIOps 现状的一点观察
先聊聊我观察到的 AIOps 落地现状，因为如果不先把这里面的矛盾说清楚，后面理解 Agentic Operations 就容易浮在表面。
大多数团队引入 AIOps 的出发点是一样的：数据量太大、告警太多、人不够用。一个稍微有点规模的系统，一天产生几百万条日志、几万个指标点、几千条告警，都是很正常的事情。靠人肉去盯，根本盯不过来。所以第一波 AIOps 工具几乎都是围绕“降低噪音”来做的：用聚类算法把相似的告警归并到一起，用关联规则把同一条故障链路的时间线拼起来，用异常检测模型从指标里挑出那些真正偏离基线的点。
这套东西有没有用？有用，但边界很明显。它本质上还是在做“信息压缩”，把人需要看的内容从一万条压缩到一百条。但压缩完之后，后面的事情还是得人来干：到底是不是根因？应该怎么处置？改了会不会影响别的模块？这个判断链路，AI 没有参与进去，也没办法参与进去。
问题就出在这里：运维的瓶颈其实从来不在“看不看得过来”，而在“处理问题的速度和准确性”。告警压缩只能省掉你看告警的时间，但处理故障需要的大量上下文关联、方案推演、操作执行、影响验证，全都得靠工程师的经验。而一个团队里有经验的工程师就那几个，他们不可能 24 小时盯着。
所以后来业界开始尝试加了更多的智能化：根因分析、智能变更、故障预测。想法很好，但落地时发现一个要命的问题——这些能力的单点效果都不错，可拼在一起之后就变得很脆弱。今天根因分析给你定位到一个网络抖动，但它不会告诉你抖动的来源是云厂商的物理设备还是内网交换机；明天它定位到一条配置变更引发的服务波动，但它不会主动把那条变更先给回滚了，等你做决定的时候，业务已经抖了十分钟。
说白了，传统 AIOps 是一堆“聪明的零件”，但缺少一个把它们组织起来、持续运转、对最终结果负责的“大脑”。这个大脑，就是 Agentic Operations 想补上的那块拼图。
1.2 Agentic Operations 的核心变化
Agentic Operations 的核心变化，可以浓缩成四个关键字：感知、决策、执行、学习。这四个词拆开看都不新鲜，但组合在一起，就是一个完全不同的系统形态。
第一层是感知。这层和传统 AIOps 很像，需要接入全量的指标、日志、链路追踪、事件数据，作为系统的“眼睛和耳朵”。但区别在于，感知的颗粒度和广度要达到能让智能体真正理解系统状态的程度，而不是只为了出几个图表。
第二层是决策。这是最大的区别所在。传统 AIOps 的决策，通常是一个模型给一个结论，比如“磁盘 IO 异常，疑似云盘故障”。Agentic Operations 的决策，是一个规划过程：智能体拿到感知层的输入之后，会像一个工程师一样去思考——先排查什么、用什么手段验证、如果 A 假设不成立再试 B、操作顺序是什么、操作影响的爆炸半径有多大。它不是给你一个答案，而是给出一条从“当前状态”到“正常状态”的行动路径。
第三层是执行。智能体要通过各种接口去真的操作：调用云平台的 API 重启实例、通过运维平台执行变更脚本、向配置中心下发新的参数、甚至直接操作数据库做限流或切流量。这一层是传统 AIOps 完全不敢碰的领域，因为它涉及安全边界和操作风险。
第四层是学习。每一次故障处理完之后，智能体要能把这个过程中的经验沉淀下来。有效的方法固化成策略，无效的路径标记为低置信度，这样它的处置能力才会随着处理过的故障越来越多而持续变强，而不是像传统模型那样训完就停在原地。
这四个字放在一起，就是“Agentic Operations 从一个辅助角色变成了一个执行主体”。人还是重要的，但人的角色从“出力的”变成了“把关的”，也就是我前面说的监督者。
2. 为什么非要从 AIOps 往前走一步
你可能会想，现有 AIOps 虽然不完美，但至少够用，非要去搞 Agentic Operations，成本和风险都很高，图什么？我自己的答案是：因为故障场景不会等我们准备好，而传统的辅助式 AIOps 在几个关键问题上确实无解。
2.1 AIOps 落地时我踩过的坑
我过去在几个不同规模的团队里尝试过 AIOps，有些是平台级的，有些是单点工具级的。踩过的坑里，最有代表性的有这么几个。
第一坑：根因分析的准确率上不去。模型给出的根因结论，经常是“指标异常+疑似对应某服务”。这个结论方向没错，但离真正能指导操作还差得很远。比如它告诉你“数据库慢查询变多”，但没告诉你是因为新上线的索引失效、还是某条 SQL 的扫描量激增、还是连接池被打满。你知道了“数据库慢”之后，依然要去查一大堆中间件和应用的指标，才能定位到具体的操作目标。这导致的直接结果是：AI 给了根因，工程师还是要花 80% 的时间去做二次排查，图了个寂寞。
第二坑：处置方案没法闭环。有很多次，模型已经明确告诉我“这个异常和某模块的新版本发布有关，建议回滚”。但建议就停在建议那儿了。我还是要手动登录发布平台，找到对应的版本，点击回滚，然后等发布完成，再观测指标是否恢复。这个过程里，AI 退回到了一个“告警提示器”的角色，价值大打折扣。
第三坑：模型能力和现场脱节。生产环境的故障从来不是一个纯技术问题。一个故障往往涉及代码缺陷、配置错误、容量不足、依赖服务异常等多个因素，而且这些因素之间还有因果关系。传统 AIOps 的模型大多是基于历史数据训练的，面对一个没有见过的新组合时，泛化能力很差。说难听点，它是拿着旧地图找新路，当然找不准。
这些坑让我意识到一件事：运维闭环里最值钱的部分，不是“发现问题”，而是“定位问题并把它解决掉”。如果 AI 参与不了这两步，那 AIOps 就只是一个更贵的监控系统。
2.2 Agentic 路线带来的新可能性
Agentic Operations 的路线，恰恰是针对上面这些无解的问题去设计的，它带来的不是单点能力的提升，而是整体流程的重构。
首先，它把“处置经验”从人身上搬到了系统里。一个经验丰富的工程师能快速定位问题，是因为大脑里存了大量“特征→路径→操作”的模式。Agentic Operations 用智能体的规划能力模拟这个过程，同时把每一次实操结果反哺回系统，相当于把老师傅的思路逐步固化下来。团队不再依赖“那个最懂系统的同事在不在”，因为至少有一部分经验已经被系统学会了。
其次，它真正把 MTTR（平均修复时间）压缩了下来。这个可以说是最实际的价值。过去一个故障从发现到恢复，花的时间大头往往不在“确认问题”上，而在“等人工介入→翻阅文档→讨论方案→申请权限→执行操作”这个漫长的链路里。智能体接管之后，前面几步可以做到分钟级甚至秒级，后面几步只要权限和审批流允许，也能大幅缩短。我见过一个演示环境下的真实对比：同样一个磁盘打满的故障，人工处理平均 20 分钟，智能体处理从触发到清出 20G 临时文件、确认 IO 恢复，用了不到 3 分钟。
最后，它解锁了一种新的运维模式：主动运维。传统运维是“被动响应”——系统出事了才去处理。Agentic Operations 因为有持续感知和自动执行的能力，可以做很多预防性的动作。比如提前发现磁盘容量趋势异常，自动执行清理策略；发现某服务的错误率在缓慢爬坡，自动触发扩容预案。这听起来像自动驾驶的 L2/L3，但方向是明确的：运维正在从“救火队”变成“预防性巡检队”。
3. 平台和流程怎么搭：一套可落地的分层设计
理论讲了半天，真正动手做的时候，很多人会一头雾水：Agentic Operations 到底该从哪里下手？需要准备哪些基础组件？流程怎么设计？我这部分给它拆成一个一个可执行的模块，都是我实际搭建过程中反复调整后的最终形态。
3.1 可观测数据层怎么准备
不管上层多智能，没有可靠的数据，一切都是瞎子摸象。Agentic Operations 对数据层的要求比传统监控高很多，核心是三点：全、快、结构化。
“全”指的是数据维度要完整。指标、日志、链路追踪、事件、变更记录、配置信息、拓扑关系，能接的都接上。尤其是变更记录和拓扑关系，这两个在传统 AIOps 里常常被忽略，但对智能体决策特别重要。没有变更记录，智能体就无法把“某个服务开始抖动”和“十分钟前那个服务刚发布过新版本”关联起来；没有拓扑关系，智能体就不知道这个服务挂了会影响下面哪些调用方。
“快”指的是数据从产生到可被消费的延迟要低。智能体做实时决策，用的是过去几秒甚至几十秒的数据，而不是上一小时的聚合数据。所以数据链路里最好采用流式处理，指标用时序数据库，日志用全文检索引擎，链路用 Trace 系统，这几套数据要有一个统一的访问接口，避免智能体做一次分析要跨四五个系统去取数据。
“结构化”是我特别想强调的。原始日志和指标本身是半结构化或非结构化的，智能体很难直接拿来做推理。需要在数据入口处做一层解析和标准化，把关键字段提取出来，比如错误码、耗时、调用方、目标服务、实例 ID。这一步做得越干净，后面智能体的推理准确率越高。如果原始数据的质量不高，把希望寄托在模型“硬读”上，效果一定很差。
实操上，我建议不用一上来就追求大而全。可以先选一条最重要的核心链路，把指标、日志、链路、变更、拓扑五类数据打通，做一个最小可用的数据底座。等跑通了一个场景，再逐步扩到其他业务域。
3.2 决策和执行层怎么设计
数据准备完之后，重头戏就是决策层和执行层。这一块是我踩坑最多的部分，也是 Agentic Operations 能不能真正跑起来的胜负手。
决策层最核心的是一个“规划器”。它负责接收数据层送过来的系统状态，然后产出一系列动作序列。这个规划器通常是一个大语言模型驱动的 Agent，但它外面一定要套一层我们叫“决策框架”的东西，不能让它裸奔。决策框架里至少要包含这几样：
观察模块。负责把数据层送来的原始状态整理成一个结构化的“状态描述”，比如“支付服务错误率高于阈值、依赖的缓存集群延迟升高、最近一次变更为 15 分钟前的配置下发”。观察模块要做得足够细，因为模型的推理质量对输入质量极度敏感。
推理模块。负责生成假设和行动计划。这个模块要有标准的问题解决框架，比如“先验证最可疑的因素→定位根因→选择最小影响范围的处置方案→预估爆炸半径→执行→验证”。我会在推理模块里给模型塞入大量的领域知识和历史处置经验，比如“这类错误通常是连接池耗尽，处置方式是先摘流量再扩容”。
记忆模块。这是容易被忽略但极其重要的一块。部署一个向量数据库，把每次故障处理的完整记录——现象、分析过程、最终结论、操作步骤、结果验证——都存进去。下次再遇到类似场景时，先把相似历史案例检索出来，作为推理的参考。有了记忆模块，智能体才具备持续学习的能力，不会每次遇到都从零开始想。
执行层则是决策层和真实世界的桥梁。它不能是决策层直接调 API，那太危险。执行层要做一层“操作封装”，比如把“重启服务”“回滚版本”“扩容”“转移流量”这些高频操作封装成受控的动作函数，每个函数都有入参校验、权限校验、审批触发和失败回滚的逻辑。决策层做的是“决定做什么”，执行层做的是“保证做的时候不出大事”。
这里有一个设计原则，我是在一次故障演练之后彻底想通的：要把决策层的想象力和执行层的约束力分开。决策层可以自由地提出各种想法，但真正落地必须过执行层这一道紧巴巴的门。两者之间用接口沟通，决策层拿到的永远是执行结果的反馈，而不是被系统拒绝的冰冷异常。
4. 落地怎么走：从最小闭环开始，逐步自治化
理论说得再好，最终要回到“今天下班前我该做什么”这个问题。我梳理一下相对务实的落地路径，分成三步走，每一步的产出都清晰可见，方便你在自己的环境里验证。
4.1 先做一个最小可行闭环
不要一上来就追求“全自动处理一切故障”，那是不现实的。我建议先选一个高频、低风险、影响可控的故障场景，比如“磁盘空间满导致服务异常”或者“慢 SQL 拖垮数据库连接池”，把这个场景的自治闭环打通。
具体做法是五步。
第一步，梳理场景的完整处置 SOP。把老师傅处理这个故障时每一步怎么走的，原原本本写下来，包括怎么确认、怎么定位、操作顺序是什么、每一项操作的影响是什么、验证恢复的标准是什么。这是所有后续工作的地基。这个 SOP 写得不扎实，后面智能体一定跑偏。
第二步，把 SOP 中涉及的查询类动作全部 API 化。确保智能体可以自己去查磁盘使用率、查进程状态、查日志关键词、查实例列表。查询能力是最安全的起点，先让智能体把“看”的能力练起来。
第三步，把 SOP 中涉及的处置类动作做受控封装。比如自动清理临时日志目录、自动触发扩容流程、自动摘除异常实例。每个动作都要有详细的执行日志、参数约束、预检查条件和后检查条件。刚开始可以保留人工审批环节，也就是智能体生成操作请求，人来点确认。这个过渡期可以让你建立对系统的信任。
第四步，写决策编排逻辑。把第一步的 SOP 翻译成一套规则+模型混合的决策逻辑。规则部分用来处理确定性的判断，模型部分用来处理复杂推理和未知场景。这个编排逻辑是把 SOP 变成一个真正可执行流程的关键。
第五步，持续用历史故障数据回放验证。找过去一段时间这类故障的真实案例，把处理之前的原始数据作为输入，让系统跑一遍，看它的处置路径和老师傅的处置路径差多少。一开始肯定会有偏差，但通过不断修正编排逻辑和提示词，准确率会快速上升。
4.2 从局部自治到全局自治的演进节奏
最小闭环跑通之后，剩下的就是持续扩展场景和逐步提升自治度。我把这个过程分成三个阶段。
第一个阶段叫“单场景辅助自治”。系统可以在一个特定场景内独立完成全链路处置，但每步操作仍然需要人工确认。这个阶段的目标是让团队熟悉系统的存在，并积累对它的信任。我实话说，这个阶段要忍住，不要贪快，风险控制手段做得越扎实越好。
第二个阶段叫“多场景自动处置”。系统可以同时覆盖几十个高频故障场景，并且对一部分低风险操作实现免审批自动执行。比如磁盘清理、无用进程回收、缓存 Key 清理这类操作，可以走自动授权。中高风险操作，比如变更回滚、实例重启，仍然保留审批。这个阶段需要开始建设“可观测的决策过程”，也就是说你要能看到智能体为什么这么想、它当时看到了什么数据，否则出了事根本没法复盘。
第三个阶段才叫“全局自治调度”。系统成为整个运维体系的调度中枢，不仅能处置故障，还能主动发现容量风险、自动协调变更窗口、统筹多个智能体协同工作。这个阶段对团队的能力要求非常高，坦白讲很多团队不需要走到这一步，能到第二阶段就已经能省下大量人力了。但架构设计上，建议从一开始就留好向上演进的接口，别把自己设计死。
5. 常见问题与排查实录
这部分分享几个我从实操中遇到的典型问题，以及对应的排查和解决思路，给正在踩坑的同学当一张参考速查表。
5.1 Agent 乱动生产环境怎么办
这个问题几乎是每个初次接触 Agentic Operations 的团队都会恐惧的：智能体决策失误，把生产环境搞挂了，怎么办？我这个恐惧太合理了，但解决方案不是“不让它动”，而是“让它动，但是动得非常安全”。
首先，建立一个“动作分级”体系。把所有智能体可执行的动作按爆炸半径分成低、中、高三档。低风险动作（比如只读查询、清理临时文件）走快速通道；中风险动作（比如隔离单实例、调整限流阈值）需要动态审批；高风险动作（比如全量回滚、重启核心服务）在默认情况下直接禁止，除非在预案中明确授权。
其次，建立“沙箱预演”机制。所有中高风险动作，在执行层都有一个预演模式。预演不会真的做操作，而是基于当前系统快照，推演操作执行后的状态变化，推演没问题才进入真实的执行通道。这一步相当于给智能体套了一层“模拟器”，能把大部分低级错误挡在门外。
最后，建立“熔断恢复”机制。如果系统检测到执行某个动作后，关键指标没有按预期方向变化，甚至恶化了，那么执行层会立即触发回滚。也就是说，每类动作都要有一个配套的“撤销函数”。我在设计执行层的时候，把“动作和撤销动作成对注册”作为一个硬性规定，不满足这个条件的动作不允许上线。这是最有效的一道安全网。
5.2 模型误判和幻觉怎么兜底
大语言模型再强，也难免有分析错误或者凭空编造出不存在的情况。这个问题在运维领域尤其致命，因为你面对的是一套真实业务系统。我的经验是三层兜底缺一不可。
第一层兜底：结构化护栏。不要直接让模型输出“最终处置指令”，而是让它输出“计划动作列表”，然后用一套预定义好的语法和 schema 去做校验。凡是 schema 对不上的输出，直接拒绝。这能把大多数幻觉拦在入口处，因为模型再怎么编，没办法编出一个不在动作函数清单里的操作。
第二层兜底：真相校验。智能体在给出结论前，要求它用工具去验证，而不是直接基于记忆作答。比如它怀疑“缓存服务异常”，那就强制它调用查询函数去查缓存服务的实时状态，把结果拿到之后再继续推理。这个“先验证再断言”的机制，是我用过之后效果最好的防幻觉手段之一。
第三层兜底：人工审计机制。所有自动执行的动作，都要记录完整的推理链条和执行结果，比如它基于哪些指标判断的、选了哪个操作、操作后的指标变化如何。这个记录一方面用于事后复盘，另一方面也是持续改进模型提示词和策略的素材。出了幻觉不可怕，可怕的是没有留下任何可以追责和反哺的轨迹。
5.3 怎么评估这套体系到底有没有用
最后聊聊“怎么衡量效果”这个老大难问题。很多人做了 Agentic Operations，汇报的时候只能拿出“我们接入了多少数据、智能体处理了多少告警”这种过程指标，听着很虚。我建议建立一套更贴近业务价值的指标集合。
指标一：平均修复时间（MTTR）。这是最硬核的指标，对比系统上线前后的故障恢复耗时。需要区分“智能体参与处置”和“人工处置”两条路线分别统计，才能看出真实差异。
指标二：人工介入率。指的是故障总数中，真正需要人工接管或者人工审批后才完成处置的比例。这个指标从 100% 逐步降到 60%、30%，就是你系统自治能力上升最直观的证据。这个算出来非常鼓舞士气，比任何汇报 PPT 都有说服力。
指标三：处置成功率与回滚率。也就是智能体发起的处置动作中，成功把故障恢复的比例，以及运行过程中出发了回滚的比例。这一组指标衡量的是智能体决策的“准”，和 MTTR 衡量的“快”互补。
指标四：误操作率。在所有自动执行动作中，因为智能体决策错误而对系统造成负面影响的比例。这个指标必须长期控制在极低水平，比如千分之一以下，否则团队很难建立起对系统的信任。
我自己的体会是，没有这些指标之前，系统到底行不行全靠感觉，代码改得好不好完全没法说；有了指标之后，每天看板都在说话。每一轮迭代都变成了一个可控的实验：改一个提示词、加一个动作函数、调一个审批策略，都能从指标变化里看到效果。
6. 一点个人体会和后续想法
这套东西我从一开始的观望、到小规模实验、再到逐步铺开，前后折腾了大半年。最大的感受其实是：Agentic Operations 不是一次性推翻重来的技术革命，而是把以前运维体系里那些孤立的智能化能力，用一个主体性的框架重新串起来了。它要求你把“数据—决策—执行—学习”当成一个完整系统来看，而不是继续在某个单点上打补丁。
过程中我也反复跟自己确认过一个问题：到底什么场景适合先试？我的建议是，一定要找那种“SOP 成熟、操作可封装、影响可控、发生频率高”的场景。别嘴上说着战略性布局，实际却选了一个一个月才发生一次、操作步骤也不标准化的边缘故障当试点，那大概率会倒在验证阶段。
另外一个让我意外的事情是，做 Agentic Operations 最大的困难还不是技术，而是观念的转变。团队里很多有经验的工程师，一开始会天然地抗拒让一个智能体去动生产环境。这不是因为他们不信任技术，而是因为他们太知道生产环境的水有多深了。我后来想明白了，破解这个心结只有一条路：让它先在你眼皮子底下干成几件事，再慢慢松开手上的绳子。信任是试出来的，不是论证出来的。
后续如果条件允许，我打算在两个方向上继续深入。一个是把多智能体协同做出来，让不同职能的智能体，比如故障定位、容量规划、变更管理，各自独立工作但相互通信。另一个是把强化学习引入进来，让智能体不仅仅靠历史案例做参考，而是能够通过模拟环境不断试错，把处置策略打磨得更加健壮。这两个方向坦白说都还在非常早期，但我觉得它们才是 Agentic Operations 真正发挥潜力的地方。
好的，这篇关于我从 AIOps 到 Agentic Operations 的思考和实操记录就先聊到这儿。如果你也在琢磨怎么把 AI 运维往前推进，希望我的这些踩坑经历能给你省下一点摸索的时间。
