前阵子和几个常年做运维平台的同学聊天，大家不约而同地提到一个尴尬的现状：AIOps 这个概念喊了快十年，落地时却总卡在同一个地方——系统确实在帮我们发现故障，却很少能替我们决定该怎么办。白天还好，一到凌晨告警风暴，值班同学面对一屏根因分析结论，还是要靠人肉翻文档、拉群、求爷爷告奶奶地执行变更。最近 Agentic Operations 这个词开始频繁出现，我花了大半个月把相关实践和同行案例梳理了一遍，越看越觉得这不是 AIOps 换了个马甲，而是对 AI 运维的一次重新理解。
这篇文章我想把这件事讲透：AIOps 这些年到底沉淀了什么，Agentic Operations 改动的是哪一层，以及真正落地时那些文档里不写、但踩过坑才懂的关键设计。适合正在做运维平台、SRE 体系，或者被"智能运维"折腾过、想换个思路的工程师。
1. AIOps 沉淀下来的家底，和最后一公里失灵
聊 Agentic Operations 之前，先得承认一件事：AIOps 不是白折腾的。过去这些年，我们其实攒下了不少能用的智能能力，只是它们各自孤立，没形成闭环。
1.1 已经跑起来的智能能力：看得见、看得懂
以我接触到的大部分中大型系统为例，真正在线上稳定发挥价值的 AIOps 能力，基本集中在四类：
- 异常检测：对指标序列建模，识别出人力难以通过固定阈值发现的缓慢变化、季节性异常、多维下钻后的指标拐点。
- 告警降噪与收敛：把几百条原始告警聚合成一两个真正需要处理的故障事件，压缩比常常能做到 90% 以上。
- 根因分析：结合调用链、日志、指标做关联分析，给出疑似根因的排序。处理过 1000 个以上微服务节点的人都知道，这个能力哪怕只有 60% 准确率，都能省下大量排查时间。
- 趋势预测与容量分析：对资源使用率、业务流量做短中期预测，在故障发生前给出扩容建议。
这些能力解决的是"看得见、看得懂"的问题。它们的共同特征是只出不进——系统计算、分析、输出结论，然后把结论推给人。问题恰在这里。
1.2 最后一公里的断裂：从结论到动作
我见过最典型的场景是这样的：某核心数据库连接数持续攀升，AIOps 平台在凌晨 1 点 47 分发出告警，并给出根因分析——某新上线接口存在连接泄漏，疑似未关闭连接池。分析得非常准确。然后呢？值班同学拿着这个结论，开始走流程：翻通讯录找接口负责人、确认是否可重启、申请变更权限、分批重启实例、观察指标确认恢复……整套动作下来 40 分钟起步。
这 40 分钟里，AIOps 平台帮上忙了吗？严格说，只帮了一半。它把过去"从零开始排查"的 2 小时压缩成了"拿着答案做动作"的 40 分钟，但剩下那 40 分钟恰恰是最痛的——凌晨时分、人在困倦、操作步骤琐碎、每一步都有风险，这才是值班压力最大的来源。
我把这个断崖叫作"最后一公里失灵"：诊断智能已经很接近可用的底线，执行却依然百分之百依赖人肉。不是大家不想做自动化，而是认真评估过的团队都知道这件事有多难：
- 不敢：变更动作直接作用于生产环境，模型给错建议可能比不给建议更糟。
- 不能：很多运维平台的历史包袱重，操作接口缺失，脚本年代留下的自动化碎片根本没法被统一调度。
- 不准：模型缺乏业务上下文，不知道哪些接口可以短时不可用，不知道数据库的主从切换窗口，给出的处置方案经常"聪明但无用"。
1.3 知识割裂是更深层的病因
还有一个经常被忽视的问题：运维知识和系统状态是割裂的。AIOps 模型学习的是指标和日志的统计规律，但老师傅脑子里装的是另外一套知识——"业务方说大促前的数据预热必须在凌晨 2 点前完成""这个存储集群扩容超过 30% 需要提前报备""历史出现过磁盘坏道，重启前必须确认落盘策略"。
这些知识要么散落在聊天记录里，要么写在不更新的 Wiki 里，根本不可能被传统 AIOps 系统调用。模型不知道业务约束、不知道变更时序、不知道风险偏好，所以即便它的分析能力再强，也无法做出真正负责任的处置决策。这也是为什么我的基本判断是：AIOps 本身并没有做错什么，它只是缺少一个把这些能力、知识、动作串起来的"执行大脑"。
2. Agentic Operations 到底改了什么：从预测到行动的闭环重构
Agentic Operations 之所以被看作一次范式转换，核心在于它把 AI 在运维中的角色从"分析师"变成了"参与者"。这个转变不是某个新算法带来的，而是用大语言模型驱动智能体（Agent），通过感知、推理、决策、执行、验证的循环，把之前断掉的那一公里重新接上。
2.1 一个更容易理解的定义
我给 Agentic Operations 下的定义是：以智能体为核心，在 AIOps 提供的可观测性和分析能力之上，自主或半自主地完成运维任务的发现、诊断、决策、执行与验证闭环。这里有三个关键词：
- 自主不是全自动，而是在设定边界内主动推进。
- 闭环是指动作执行完不算完，必须验证效果并反馈给决策者。
- 智能体的核心能力不是"会说话"，而是"会调用工具"。
如果你做过自动化运维，可以把 Agentic Operations 理解成"长了脑子的自动化"。传统自动化（脚本、RPA、定时任务）是固定剧本，每一步做什么都提前写死，遇到剧本外的情况就死机。Agentic Operations 不一样，它读懂了目标之后，可以在允许的动作空间里自己规划步骤，根据实时反馈动态调整。打个比方：传统自动化是个按轨道跑的火车，Agent 是个能看路况、能自己变道的司机。
2.2 重新定义的三个环节
在这个框架下，感知、决策、执行三个环节的内涵都发生了变化。
感知层面，Agent 不只接收结构化告警，还能主动去查——拉取日志、查询指标、对比最近一次变更记录、甚至进入只读模式查看配置状态。这就像老值班员接到告警后不是等平台喂料，而是自己动手翻看各种仪表盘。
决策层面，Agent 会用大模型做推理规划，但关键动作受到严格约束。它不能自由发挥，而是在预置的预案模板、工具白名单、参数边界内做组合选择。比如它知道连接池泄漏这类问题，合法的动作空间只有"重启连接池""限制入口流量""通知服务负责人"三个选项，每个选项又有独立的触发条件。
执行层面，Agent 直接调用运维平台的 API 完成操作，比如执行容量变更、跑批处理、切换流量、触发回滚。每一步动作都有审计记录，支持中途人工接管。执行之后它还会自动检查指标是否恢复、错误率是否下降，用结果反向验证自己之前的判断对不对。
2.3 为什么说这不是 AIOps 的简单延续
我见过不少厂商把 Agentic Operations 包装成"升级版 AIOps"，这是种误导。两者的差异不在模型有多强，而在系统边界完全不同。
AIOps 系统的边界基本到"产出洞察"为止，交付物是一份报告、一条告警、一个根因结论；Agentic Operations 的边界至少要延伸到"变更动作完成且效果被确认"。这意味着它必须具备工具调用、状态管理、错误处理、权限控制、回滚能力，这些根本是另一套系统工程。
换句话说，AIOps 解决的是"如果我知道，就能更快定位"；Agentic Operations 解决的是"如果我决定，就要确保执行正确且可回退"。这个"决定权"和"执行权"的转移，才是范式转换的本质。它把智能从旁观者位置拉到了操作者位置，代价是必须用更严格的工程约束去兜住模型的不确定性。
3. 工程落地不能省的硬功夫：确定性、权限与可观测性
很多团队第一次尝试 Agentic Operations，都是从拿大模型跑通一个"自动处理告警"的 Demo 开始的。Demo 跑通很容易，难的是你敢不敢让它碰生产。我总结了几个工程上必须优先解决的问题，这些问题不做扎实，Agent 再聪明也上不了线。
3.1 确定性优先于智能性
大模型的天然属性是概率生成，同一句话问十次，十次措辞可能都不一样。运维系统最不能接受的就是"随机应变"，生产环境的变更讲究可预期、可复现、可控。
所以我们落地时做的第一件事，不是调模型让它更"聪明"，而是给 Agent 划定一个极度收敛的动作空间。我把这个设计叫作"电梯按钮原则"——你不需要让电梯自己发明楼层，你只需要让它在一组明确的按钮里做选择。
具体做法包括几类：
- 工具白名单：Agent 只能调用预先注册好的、参数模式固定的一系列运维工具，每个工具的描述、入参、出参都写成结构化文档由模型读取，不允许动态拼命令。
- 预案模板约束：任务的执行路径必须先匹配到预案模板。比如"数据库连接池耗尽"对应模板 A，"磁盘水位过高"对应模板 B。Agent 的自主性体现在模板内的参数选择和顺序调整，而不是发明新流程。
- 置信度阈值：模型在决策前必须对当前状态给出置信度评估，低于阈值时必须征询人类确认，不许硬着头皮下操作。
- 沙盒强制演练：任何新预案上线前，先在仿真环境中注入同样的故障，观察 Agent 的完整决策链，通过后才会开放生产权限。
只有把模型限制在一个有边界的游乐场里，它的"自主性"才是可靠的；否则它越自由，事故越大。
3.2 最小权限与审批门禁：再聪明的 Agent 也要听话
Agentic Operations 落地中最容易翻车的，是权限模型没设计好。我见过一个典型案例：某模拟项目的运维团队给 Agent 授权了等同于管理员账号的权限集，认为"既然要它干活，就得给它足够权限"。结果在一次演练中，Agent 因为对某参数理解偏差，险些把一组还在承接流量的节点同时重启。万幸发生在沙盒里，但这件事给所有人上了一课。
我现在的权限设计准则是"默认只读，单动作授权，破坏性操作双人审批"。具体拆开看：
- 默认只读：Agent 在没有明确任务目标前，只能读取指标、日志、配置信息，任何写操作、变更操作都需要在任务上下文中显式启用。
- 单动作授权：即使 Agent 拿到一个大任务，也要拆解成一个个具体动作分别鉴权。比如"重启连接池"是一个动作，"批量扩容"是另一个动作，每个动作独立判定是否在授权范围内。
- 破坏性操作双人审批：涉及删除、重启、流量切换、配置变更等高危动作，必须有第二个人在审批接口确认，Agent 才能执行。审批人看到的不是一句简单的"是否同意"，而是完整的前置分析、影响范围、回滚方案。
为什么双人审批这么重要？因为大模型即使被约束得再好，也可能在复杂上下文里做出人类难以预料的判断。这道人工闸门不是为了阻止 Agent 工作，而是为系统的行为加上一道安全语义校验。尤其在多 Agent 协作的场景里，单 Agent 的错误会被传递和放大，人工闸门可以及时切断事故链路。
3.3 全链路可观测：每一步都要能被审计
Agentic Operations 引入了一个此前运维体系里没有的观测对象——Agent 自身的思考与行为过程。传统监控看的是指标、日志、链路，现在还得看模型的输入输出、工具调用参数、决策中间态、执行结果反馈。我称之为"策略可观测性"。
这块落地时我踩过不少坑，最核心的体会是要从一开始就记录 Agent 的每一步痕迹，而不只是最终结果。我们要求每次任务执行都会留存一份完整的轨迹数据，至少包含：
- 输入事件：是什么触发了这次决策（哪条告警、哪个指标异常、哪条用户指令）。
- 推理摘要：模型当时读了哪些数据，得出了什么中间判断。
- 工具调用记录：调用了哪个工具，传了什么参数，返回了什么结果。
- 决策与动作：最终选择了哪个动作，为什么选它，放弃了哪些候选。
- 执行中反馈：执行过程中监测到的实时指标变化，有没有触发中断或回退。
- 人工介入节点：哪个环节出现了人工确认，审批人是谁，审批耗时多久。
这些轨迹不能只存不查，还要保证能快速检索回放。每次线上事故复盘时，如果有 Agent 参与了处置，我们第一件事就是拉出它的完整决策链，看它在事发前后到底做了什么判断、依据是什么。如果没有这套数据，Agent 就是个无法解释的黑盒，你再怎么强调"它很准"都不会有人敢信任。
3.4 回滚必须是第一公民
最后一条硬功夫是把回滚设计成第一公民，而不是事后补救。Agent 每次执行变更动作前，必须生成对应的回滚计划，并且在流程上强制校验：这个动作如果失败，我们能不能恢复到执行前状态？如果不能，该动作不允许执行。
这套机制我做了三层：第一层是快照回滚，存储系统、配置中心在动作执行前自动打快照，执行后可一键恢复；第二层是语义回滚，针对的是无法简单回退的操作，比如流量切换，需要设计反向切换动作并验证；第三层是降级回滚，当完整回滚不可用时，至少能把系统切换到安全降级模式，保证核心链路不中断。
有了这三层垫底，Agent 才敢真正动手。换句直白的话：一个没有回滚能力的 Agent 和一把没有保险的枪没什么区别，而我们要做的是先给它装上保险，再谈射击准度。
4. 一个故障演练实例：Agent 怎么从感知一路干到验证
理论说了不少，上一段实操。我以某电商模拟项目的促销前容量保障为例，完整走一遍 Agentic Operations 的执行链路，读者可以对照自己平台的现状，看哪些环节已经具备，哪些还需要补。
4.1 故障注入：凌晨的数据库连接池告警
场景设定：某电商模拟项目在大促前夜进行全链路压测，压测过程中，核心订单库连接数突然飙升，新申请连接的响应时间从 2ms 涨到 900ms。监控平台按预设规则发出告警事件，这个消息推给了值班 Agent，同时抄送了值班工程师。
这一阶段 Agent 的感知动作是：先读取告警详情，再主动查询数据库连接数曲线、活跃会话数、慢查询数，并调用变更记录接口查看最近 30 分钟内是否有新部署。注意，Agent 不是被动等数据，而是像值班员一样主动围绕告警去收集信息。这一步的关键设计是数据源要有配套的工具接口，如果平台只能看图表不能查数据，Agent 就寸步难行。
4.2 诊断推理：定位到慢 SQL 和新发布接口
几路数据回来后，Agent 的推理模块开始工作。它注意到两个交叉信号：一是慢查询集中在某条新上线的订单查询接口产生的 SQL 上，平均执行时间从 50ms 涨到 1200ms；二是该接口的发布变更时间恰好是连接数开始飙升的前 5 分钟。
基于这两个信号，Agent 在根因候选列表里把"新上线接口 SQL 执行计划退化"排在第一位，并把"数据库连接池配置异常"和"压测流量超预期"排在备选位。注意，Agent 不是只靠大模型猜，它的判断是通过一小段分析逻辑完成的——先找出时间关联，再用查询计划对比找出 SQL 执行路径变化。大模型在这里更多承担的是"把这些结构化证据组织成推理链路"的角色。
这一步结束时，Agent 产出了一个简短结论："新增接口查询未命中索引，导致大量慢 SQL，连接占用持续堆积。建议优先执行预案 C-07：慢查询会话清理与连接池重连；同时暂停该接口灰度流量，观察是否恢复。"
4.3 决策与审批：动作空间里的有限选择
预案 C-07 是已经预置好的操作模板，Agent 的"决策"实际上是在模板允许的参数范围内做选择：清理慢查询会话的超时阈值设多少秒、重启连接池前要不要先摘流量、有没有低峰窗口可以利用。
它随后生成了一条必须经过人工审批的变更请求，包含的影响范围、预计耗时、回滚方案都一并列出。值班工程师在审批面板上看到的信息不是一堆晦涩的模型输出，而是结构化描述："将对订单库执行 15 个慢会话清理，预计影响范围限定在订单库 3 号节点，回滚方案为连接参数回退，预计耗时 2 分钟。"
这里体现了人工确认环节的价值。值班工程师对 Agent 的分析结论整体认可，但对"暂停该接口灰度流量"这一项有犹豫，因为大促前暂停流量可能影响链路验证进度。工程师在审批界面把这一项勾掉，只批准了慢会话清理动作，并留言："流量暂停先不做，观察清理后效果。"Agent 接收指令，调整了执行计划。
4.4 执行与验证：每一步都要确认效果
Agent 按照调整后的计划，通过运维平台 API 执行了慢会话清理。清理完成后它并没有直接宣布解决，而是进入验证阶段：再次查询数据库活跃连接数、慢 SQL 数量、接口 P99 响应时间。
结果比预想复杂——连接数有所回落，但 P99 响应时间仍在 400ms 左右徘徊。Agent 判断这不仅仅是历史会话堆积，新接口的查询计划问题依然存在，因此继续触发第二条预案：对该接口做降级开关切换，将其部分流量切到备用查询链路。
这条动作又在审批面板弹了出来，值班工程师这次没有犹豫，直接批准。流量切换后，订单库连接数在 10 分钟内回落到正常水平，接口响应时间恢复到 50ms 以下。Agent 自动记录收尾信息，输出一份完整的事件报告，包括根因分析、处置动作、验证数据、后续建议（如优化索引、补个缓存）。
4.5 这个例子告诉我们什么
这个演练最值得琢磨的其实不是"Agent 很聪明"，而是整条链路里的人类与机器分工发生了变化。传统 AIOps 模式下，系统负责诊断，人负责所有动作；Agentic Operations 模式下，系统负责诊断、规划、执行和验证，人负责在关键决策节点上做价值判断，比如"暂停流量影响太大，先不做"。
这种分工让值班人员的精力从"如何操作"变成"该不该操作"。在我个人看来，这才是 Agentic Operations 对运维组织最大的改变——它不是在替代人，而是把人从繁琐的执行细节里解放出来，去做更有判断力的决策。
还有一个容易忽略的细节：每一步执行后的验证。很多团队做自动化只关注"执行成功"而忽略"效果符合预期"。在这个例子里，Agent 正是因为"执行成功但指标未恢复"，才触发了后续的降级预案。如果只认执行不认结果，这个故障根本不能算真正解决。这是我强烈建议每个做 Agentic 运维的团队都要刻进骨子里的原则——验证闭环比执行本身更重要。
5. 渐进式演进路径：从建议模式开始的五步走
最后一个部分是落地路线。很多团队看完上面的例子会说：我们连 AIOps 都还没做好，直接上 Agentic Operations 是不是太远了？我的答案是不会，但也不能一步跳过去。它应该是一个渐进式的演进过程，核心原则是"先让 Agent 说话，再让 Agent 动手"。
5.1 盘点自己的"操作家底"
启动前，先做一次家底盘点是必要的。Agentic Operations 的地基不是大模型，而是运维平台本身的操作能力。我建议列一张清单，逐项确认：
- 可观测性平台是否提供体系化的查询接口，能拿到指标、日志、调用链。
- 配置中心和资源管理是否有清晰的变更记录，能区分版本历史和责任人。
- 有没有一套可编程地执行变更的 API 或运维编排平台，而不是散落一堆手工脚本。
- 之前的故障处置经验是否沉淀为标准化的预案/运行手册，本身有没有被执行过验证。
如果这些底子薄，比如操作还要靠人 SSH 登录服务器敲命令，那就先不要上 Agent，而是先把基础操作接口化。这是最朴素也最被低估的前置工作。没有干净的操作接口，Agent 就像手里没有工具的工人，模型再聪明也做不了事。
5.2 三阶段推进：建议、半自动、全自动
我推荐的落地节奏是三个阶段：
第一阶段是"建议模式"，Agent 不执行任何操作，只负责把故障诊断、处置方案、预估影响、回滚计划整理成结构化建议，推送给值班人员。这个阶段的价值在于让团队熟悉 Agent 的思考方式，并逐步校正它的判断偏差。别小看这一步，它相当于让 Agent 先当一段时间"实习值班员"，能让你以极低风险积累大量有效反馈数据。
第二阶段是"半自动模式"，针对低频且低风险的重复性操作，比如日志清理、临时文件处理、只读巡检，开放 Agent 自动执行权限；而涉及生产变更的高危动作必须保留人工审批且默认拒绝。这个阶段最容易暴露权限设计漏洞，我建议每个动作都单独绑定最小授权，不要图省事搞全量授权。
第三阶段是"全自动模式"，面向充分演练过的顶级场景，比如标准化的容量扩展、容器实例重建、固定模式的自愈恢复，允许 Agent 全链路自主完成。但即使在这个阶段，破坏性动作、批量变更、影响范围跨系统的操作依然需要人工闸门。真正的全自动不是"所有动作都自动"，而是"自动与人工闸门达到最优配比"。
5.3 知识工程：把老师傅的经验变成 Agent 能用的语言
推进 Agentic Operations 的过程中，知识工程的重要性会被前所未有地放大。传统 AIOps 时代，经验知识是写在文档里的静态内容；Agentic 时代，知识要被结构化地注入到 Agent 的工具描述、预案模板、判断规则里，成为它决策的一部分。
这里我特别想强调"接口描述"的写法。Agent 调用工具前，主要依靠工具描述来理解这个工具是干什么的、什么时候该用、有什么限制。描述写得好不好，直接影响 Agent 的选型准确率。我们内部有一条经验：描述里一定要写清楚"什么时候不要用"以及"用了会有什么副作用"。比如一个磁盘清理工具，如果只写"清理磁盘空间"，Agent 可能在任何磁盘告警时都想用它；如果补充"仅限运行备份类任务，不应清理任何数据库相关目录"，误用率会大幅下降。
预案模板则可以参考故障复盘报告来迭代。每一次真实故障处置结束后，复盘结论中那些"当时应该怎么做"的部分，就是新预案或旧预案调整的最佳素材。我们有一半以上的预案模板，不是专家凭经验写的，而是从 Agent 建议被人工修改的记录里逆向提炼出来的。这个逆向反馈回路，是纯人力沉淀知识做不到的效率。
5.4 组织与流程上的几个准备
最后说几句组织层面的准备。Agentic Operations 落地不只是技术项目，它会改变值班的工作方式。我建议提前把三件事做好：
- 重新定义值班职责：值班人员要增加"审批 Agent 动作"的能力，他们要能快速判断 Agent 的方案是否合理。这意味着值班培训要从"教会操作步骤"转向"教会判断逻辑"。
- 建立 Agent 行为审计机制：指定专人定期抽查 Agent 决策轨迹，发现规律性问题就回溯修正预案。这个角色有点像"Agent 的教练"，不是看结果有没有造成事故，而是看决策过程有没有潜在风险。
- 明确责任边界：在流程文件里写清楚，哪些场景 Agent 可以自主决策，哪些必须人工确认，哪些不允许 Agent 触碰。写得越具体越好，不要留模糊地带。
这些工作没有多少技术含量，但恰恰决定了 Agentic Operations 能不能在团队里真正扎根。技术上的坑尚且有迹可循，信任和习惯的建立反而是最难的。
我在实际落地中的体会是，AIOps 和 Agentic Operations 并不是替代关系，而是一层递进：AIOps 提供的是能看能想的感知能力，Agentic Operations 提供的是能动手的执行能力，两者合在一起，才有机会让 AI 运维从"给出答案"走到"解决问题"。而最终决定这套系统能不能长期跑下去的，往往不是模型有多强，而是那些最朴素的工程底子——操作接口稳不稳定、观测数据全不全、权限边界严不严。
系列的第一篇就先讲到这里，后面我打算继续拆 Agent 的工具调用框架、故障演练沙盒的设计细节，以及几个真实压测案例里的参数调优过程。如果你们团队也在往这个方向走，欢迎在评论区聊聊你们卡在哪一关，我尽量用实际踩过的坑来回应。
