没有银弹，但有飞轮｜运维治理与AI的协同演进

Agentic Ops实践中一个规律越来越清晰：AI在运维场景的落地效果，根本上取决于运维数据、流程和知识体系的治理质量。没有扎实的运维治理底座，AI能力只能停留在“理想很美好”阶段。

但这并不意味着「先把治理做好，再来建AI」。我们观察到一个更有价值的模式：治理与AI可以协同演进，相互加速——扎实的治理让AI落地更可靠，而AI本身也可以成为持续提升治理质量的有力工具。配置数据质量运营Agent可以替代人工月度核查，监控运营Agent可以持续分析告警规则优化空间，知识库运营Agent可以将故障案例沉淀从「依赖主动填写」变为「自动提取确认」……

核心观点： AI不是运维治理的替代品，也不需要等待治理「完美」才能引入。治理是AI落地的基础，AI是治理持续改善的加速器。两者协同演进，是Agentic Ops落地最优路径。

01 智能体典型场景落地

在进入治理讨论之前，我们先梳理当前Agentic Ops最具代表性的落地场景。正是因为有了这些场景的目标，我们才能回溯每个场景对治理底座的具体依赖。

1.1 故障诊断智能体

1 场景描述

故障诊断是Agentic Ops最核心、也最具挑战性的场景。统一故障入口（告警/事件单/故障单等多源信号）触发主智能体，经过Agentic编排（已知/未知双通道）、故障识别（问题理解与分派）、假设推理（多假设并行验证）、结论裁判（证据汇总与输出）四个主流程，协同六类专项分析子智能体并行执行，同时调用排障知识库（历史故障库/运维手册库/应急预案库）和场景小模型（时序异常检测、知识图谱RCA、维度下钻、告警降噪聚合）进行诊断分析，最终输出置信度排序的根因结论与可执行处置建议。

2 核心工具链与子智能体

3 治理核心依赖

• 可观测拓扑完整性：CMDB服务依赖关系准确性决定影响面评估的可靠性；监控覆盖率决定根因链路是否存在盲区
• 多维数据可关联性：指标-日志-Trace的关联能力是多模态根因推断的基础，数据孤立则推断片面
• 历史案例结构化程度：知识与历史Agent的能力上限由故障案例库的覆盖率和结构化程度决定
• 告警质量：大量噪音告警会严重干扰告警分析Agent的信号识别，有效率不足时诊断结论失真

关键论断： 没有完整的可观测性拓扑关系和高质量的监控数据，就不可能构建可靠的故障诊断智能体。这条链路上任何一个节点的数据质量不达标，都会导致根因推断偏差，进而让运维人员失去对Agent的信任。

1.2 ITSM 流程数字人智能体

1 场景描述

流程数字人（AI员工）是面向特定任务场景的智能执行单元，打破传统AI场景封闭模式，构建可无限拓展的智能服务体系。核心理念是：不是角色，是任务执行人——AI员工是具体任务的执行者，不再仅限于问答。整体架构由调度中心（意图识别/LLM分析/AI员工调度）、AI员工本体（职责/目标/行动计划/工具集）、知识中心（按职责限定知识范围）、员工中心（界面化零代码配置与全生命周期管理）、工具中心（通用工具注册与内置MCP服务）五个模块构成；触发方式支持用户对话、例行任务（周期性）、流程引擎（AI节点驱动）多路并行。

2 核心工具链与子智能体

3 治理核心依赖

• ITSM流程数字化程度：事件/变更/请求管理流程必须足够标准化，且深度打通运维工具能力，形成数字化的流程，Agent才能更好驱动流程推进
• SOP覆盖率与可执行性：AI员工可自主执行的操作范围严格受限于已文档化的SOP，SOP越精确、覆盖越广，AI员工能力上限越高
• 工单分类体系准确性：通过结构化的工单表单设计，形成工单分类体系，有助于AI员工持续沉淀经验，作为后续执行任务的参考，持续提升AI准确性
• 权限管控机制：操作权限必须按职责最小化配置，高风险操作由AI员工给出审批建议，强制HITL审批，缺乏权限边界的AI员工存在较大安全风险

关键论断： 流程数字人的能力天花板由SOP覆盖范围和ITSM流程数字化程度决定。未文档化的操作只能转交人工，未数字化的流程无法被Agent驱动。知识治理和流程治理的深度，决定了流程数字人规模化的边界。

1.3 自动化巡检智能体

1 场景描述

运维团队每日需手动查看监控和告警、执行脚本获取服务器/中间件/数据库/网络设备运行状态、手动点击页面检查业务健康度，耗时费力且依赖个人经验，覆盖不全面。

巡检智能体实现全链路分层自动巡检（服务器/网络设备→中间件/数据库→应用进程→系统页面），经过多维分析流程，包含异常深度分析、时序对比分析、拓扑分层分析，生成标准化结构化智能化报告，并针对巡检异常自动转工单/告警。

2 核心工具链与子智能体

3 治理核心依赖

• 巡检指标库和脚本库：巡检的全面性直接取决于巡检指标库和巡检脚本的覆盖范围，从主机，到网络/存储/安全设备，到中间件/数据库，到应用/URL/页面，整体的覆盖面
• CMDB对象完整性：巡检对象范围由CMDB中的资产记录决定，异常项的影响范围和关联，也依赖CMDB的关联关系，CMDB缺漏即意味着巡检遗漏
• 报告模板标准化：巡检报告需有统一结构化模板，才能形成跨周期可比较的健康度趋势

关键论断： 巡检智能体的价值在于「用一致的标准持续扫描全栈IT对象」，而非「偶尔深度分析」。巡检覆盖率和CMDB对象完整性是巡检智能体能否做到「无死角」的硬性前提。

1.4 智能问答与查询智能体

1 场景描述

运维人员在日常工作中频繁面临两类需求：一是知识检索（如查询故障处置方法、操作规范），依赖关键词匹配检索和个人经验总结，效率低、门槛高；二是数据查询（如统计指定版本的CMDB模型实例数量、查询资产关联关系），依赖对CMDB接口参数的熟悉程度，有一定学习成本。智能问答与查询智能体通过自然语言交互，将这两类需求统一承接，实现知识问答与数据查询的双轨覆盖。

2 核心工具链与子智能体

3 治理核心依赖

• 知识库覆盖率与结构化程度：知识库覆盖范围决定问答的有效率；知识必须结构化（而非纯文档），RAG检索才能准确命中
• 知识时效性：过期的知识比没有知识更危险，架构变更时相关知识必须同步更新，否则Agent会给出错误答案
• CMDB数据准确率与字段标准化： CMDB查询结果的可信度完全取决于数据准确率，字段口径不统一会导致查询结果产生歧义
• 数据关联关系完整性：关联查询（如「该IP运行了什么软件，归属哪个系统」）依赖CMDB中完整的CI关系模型

关键论断： 知识问答的「幻觉」风险本质上是知识治理问题：知识库不完整导致Agent依赖模型参数知识进行猜测；知识过期导致Agent给出已失效的操作建议。解决幻觉的核心手段是提升知识库的覆盖率、结构化程度和时效性。

1.5 场景与治理依赖速览

可以看看这几个典型场景的Agent落地和基础设施的关系：

而更多智能体建设则需要更为完善的基础设施：

02 智能体需要什么样的一体化运维基建

一体化运维平台是Agentic Ops的「上下文和触手」：AI的感知能力来自可观测数据，行动能力来自自动化工具，认知能力来自CMDB和知识库。没有丰富、准确、标准化的一体化运维基建，Agent只是一个无法落地的逻辑框架。

2.1 嘉为蓝鲸Agentic Ops四层架构：从基建到生态

Agentic Ops的整体架构由四个层次构成，自底向上层层依赖：

这四层并非独立模块，而是严格的依赖关系：智能体生态（第四层）的可靠性由开发平台（第三层）的完善度、大模型（第二层）的能力边界、以及一体化基建（第一层）的治理质量共同决定。基建层的任何数据质量问题，都会沿依赖链向上传导，最终体现为智能体的误判或失效。

2.2 MCP：标准化接入，让Agent驱动一体化运维

MCP（模型上下文协议）是智能体调用运维操作能力的标准化接口层。通过复用API网关，将原有一体化运维平台API快速转化为LLM可调用的MCP接口，实现智能体对运维系统的标准化、安全化调用。

• 统一规范：统一MCP Server的发布规范，集中管控，支持各开源/私有大模型的集成对接。
• 安全认证：与权限体系融合，解决MCP协议本身无安全与认证的问题；集中管控、会话保持、日志审计、MCP路由。
• 能力复用：与API Gateway集成，复用权限、限流、熔断等能力，API网关支持一键发布至MCP市场。

当前已覆盖的MCP能力：配置平台MCP（CMDB读写）、可观测中心MCP（指标/日志/Trace查询）、自动化运维中心MCP（作业执行）、IT服务管理MCP（工单操作）、应用发布中心MCP（发布触发）等核心模块。

2.3 Skills：封装运维最佳实践，沉淀可复用原子能力

Skills是将反复使用的原子操作封装为标准化技能单元，供多个Agent复用，是运维最佳实践的代码化体现。平台提供Skill托管和分享功能，支持开源Skill包兼容，提供开发工具包支持快速生成和调试。

典型Skills类型：

• 数据处理类：告警聚合Skill、日志聚类Skill、指标异常识别Skill、数据脱敏Skill
• 推理分析类：根因分析Skill（RCA排序）、影响面评估Skill、RunBook匹配Skill、风险评分Skill
• 操作执行类：标准重启Skill、配置下发Skill、流量切换Skill、回滚执行Skill
• 输出生成类：报告生成Skill、通知推送Skill、图表渲染Skill

2.4 Agent的构成要素：从能力组件到可信执行

除MCP和Skills外，一个生产可用的Agent还依赖以下关键要素共同构成：

2.5 知识层：让Agent成为业务专家

知识层解决Agent的「长期记忆」问题，分三个层次管理：

03 运维治理：AI落地的关键

Agentic Ops的落地效果，根本上取决于各运维治理领域的成熟度。每个领域围绕「最佳实践建设维度+核心建设内容+持续运营机制」三个维度展开。

3.1 CMDB配置治理

CMDB是Agent的「认知地图」，服务依赖关系、资产归属、环境配置都在这里。CMDB不准确，意味着Agent对整个IT环境的认知是失真的。

治理关键点： CMDB的准确性不是一次建设可以解决的问题，而是持续运营的结果。范围聚焦原则：优先治理核心业务系统（30%的系统覆盖80%的价值），逐步扩展。变更驱动是保持准确性的核心机制，定期核查是兜底手段。

3.2 可观测性治理

可观测性是故障诊断Agent的「感知神经系统」。指标、日志、Trace三支柱缺一不可，拓扑关联是多维数据发挥价值的关键。

治理关键点： 告警降噪是可观测性治理最直接的价值产出：大量噪音告警会让故障诊断Agent的信号识别能力大幅下降。建议将「告警有效率」作为可观测性治理的核心KPI，持续追踪改善。

3.3 ITSM流程治理

ITSM流程是流程数字人的「行为规则集」。流程的数字化程度决定了Agent能够自主执行的范围边界；未数字化的流程，即使逻辑设计合理，Agent也无法驱动执行。

3.4 知识治理

知识是Agent推理的「经验记忆」。知识的结构化程度和时效性，直接决定了知识问答Agent的准确性和故障诊断Agent的历史参照能力。

3.5 自动化能力治理

自动化是Agent的「手脚」。Agent的自主执行能力完全依赖自动化工具层的覆盖范围和可靠性；自动化能力薄弱，Agent只能「出谋划策」而无法「亲自执行」。

3.6 发布投产治理

发布变更是运维风险最集中的场景，也是变更执行Agent落地的核心依托。发布流程的规范化程度，直接决定了AI能否安全介入发布决策。

3.7 灾备应急治理

灾备应急治理决定了Agent在故障高压场景下是否敢用、能用。核心不是准备几份预案，而是把应急/灾备预案演练、故障分级、应急指挥协同、故障排查分析、故障复盘沉淀做成可检索、可执行、可度量的闭环。

3.8 资源与容量治理

资源容量治理是容量规划Agent和FinOpsAgent的数据基础。资源数据的准确性和口径一致性，直接决定了预测模型的置信度和成本优化决策的可靠性。

治理领域全览（不限于）

• CMDB配置治理→统一建模·自动采集·流程驱动·数据消费·数据运营
• 可观测性治理→统一对象建模·指标体系·告警治理·观测数据关联·覆盖管理
• ITSM流程治理→流程数字化·工单分类·变更规范·SLA治理
• 知识治理→分类建模·故障沉淀·SOP可执行化·时效管理·显性化
• 自动化能力治理→场景覆盖·操作标准化·权限最小化·回滚能力
• 发布投产治理→统一标准·策略规范化·风险量化·质量复盘
• 灾备应急治理→预案数字化·可执行化·演练常态化·RTO/RPO量化
• 资源与容量治理→映射完整·口径统一·基线动态·成本整合

04 治理路径与实践方法

运维治理不是一次性的技术改造，而是以业务价值为导向、以数据驱动为核心、以支撑AI效果落地的系统性变革工程。

4.1 第一阶段：基础夯实

核心定位：解决"数据孤岛、标准缺失、操作混乱"的基础问题，为AI建立可信的数据输入和可靠的执行通道，实现从"人工被动救火"到"标准化主动运维"的转变。

本阶段是整个治理体系的基石，其质量直接决定了后续AI能力的上限。没有准确、完整、实时的数据，任何AI算法都只能产生不可信的结果。建立统一的数据底座和操作规范，使AI具备基本的感知和执行能力。

第一阶段可解锁的AI能力：告警降噪与智能归并、日志异常分析、知识问答（基础）、CMDB辅助查询、巡检报告自动生成。

4.2 第二阶段：深化融合

目标：打通各领域数据壁垒，实现"指标-日志-链路-事件-配置"五维数据融合，构建全局运维视图，使AI具备推理和辅助决策能力，实现从"标准化运维"到"智能化运维"的转变，解锁Lv.2→Lv.3（人机协同）的AI能力。

第二阶段可解锁的AI能力：故障诊断Agent（辅助模式）、ITSM流程数字人（标准场景）、SQL风险排查Agent、CMDB智能查询、发布风险评估Agent。

4.3 第三阶段：智能运营

目标：实现全链路智能自治，构建"感知-决策-执行-优化"的闭环运维体系，使AI具备自主决策和执行能力，实现全链路智能自治，向「无人值守运维闭环」演进。

第三阶段可解锁的AI能力：故障诊断Agent（自主模式）、变更执行Agent、容量规划Agent、自愈Agent、多Agent协同。

4.4 度量体系：让治理投入可见

运维治理最容易陷入"投入可见，产出不可见"的困境。建立科学、全面的度量体系，是证明治理价值、争取持续资源投入、推动治理工作不断深化的关键。我们建议分阶段建立以下四类度量指标。

度量关键原则： 每个Agent上线前，必须建立价值基线（Before数据）；上线后，定期回顾数据对比。没有Before，就没有After，场景就永远是Demo。治理指标的持续改善，是AI能力持续提升的前提。

4.5 AI技术就绪度：MCP与工具生态治理

运维治理的成熟度决定了AI能力的数据上限，而AI技术本身的就绪度决定了这些数据能否被Agent有效利用。在实践中，我们发现一类容易被忽视的瓶颈：运维数据已经足够好，但Agent调用工具时频繁出错——根本原因不在数据，而在MCP工具本身的质量。从API到可靠MCP工具，这条路径同样需要系统性治理。

工程实践教训： 我们在某客户的实践中发现：CMDB数据准确率已达85%，但CMDB查询MCP的description中对「服务」和「应用」两个概念的描述混用，导致Agent在查询服务依赖关系时约30%的概率调用了错误的查询接口。修复description后，调用准确率从70%提升至95%。

这说明MCP工具的质量问题有时比数据质量问题更隐蔽，却同样致命。建议将MCP工具质量（description完整性、测试覆盖率、调用成功率）纳入AI技术就绪度的常规评估指标。

05 AI加速运维治理：飞轮的另一面

至此，我们已经充分讨论了「治理如何支撑AI落地」。但飞轮的转动是双向的——AI同样可以反过来加速运维治理本身。治理工作长期面临一个核心困境：数据核查靠人工、问题发现靠巡查、执行监督靠规范。这些工作耗时、低效，且难以持续坚持。

AI治理智能体的价值在于：将原本依赖人工周期性执行的治理动作，转变为持续自动运行的治理闭环。治理的持续运营质量提升，反过来进一步扩大AI落地的空间，形成加速飞轮。

飞轮逻辑： 治理夯实数据基础→AI落地效果提升→AI辅助治理运营→治理质量持续改善→AI可覆盖更多场景→……

关键转折点：当AI开始辅助治理本身，治理不再是纯粹的「人工负担」，而成为一个可持续自运转的质量保障体系。

5.1 配置数据质量运营智能体

CMDB是Agent的「认知地图」，服务依赖关系、资产归属、环境配置都在这里。CMDB不准确，意味着Agent对整个IT环境的认知是失真的。

1 解决的核心问题

CMDB数据准确率的持续维护是运维治理中最耗时的工作之一：人工核查覆盖面有限、问题发现滞后、责任人推送依赖手工统计。配置数据质量运营Agent将这个过程自动化。

2 核心能力

• 数据质量巡检：定期对CMDB数据执行多维度质量检查：字段完整性（必填项缺失）、数据一致性（自动发现与手工维护的差异）、关系合理性（孤立CI、断裂的依赖链）、时效性（长期未更新的资产记录）。
• 异常自动识别：基于规则引擎+LLM辅助推断，识别可疑数据：IP地址冲突、资产状态与监控数据不符、人工录入拼写错误修正、服务依赖关系与实际调用链路不匹配等。
• 责任人智能推送：将识别出的数据问题按CI责任人自动分发，生成结构化的问题清单和修复建议，支持直接在IM或工单系统中处理。
• 修复效果追踪：持续追踪问题修复进度，对超期未处理的问题自动升级，数据准确率趋势可视化。

3 治理价值

将CMDB数据准确率的维护从「月度人工核查」转变为「持续自动监控+精准推送」，异常发现时效从月级压缩至天级，人工核查工作量降低60%+。

5.2 监控运营智能体

1 解决的核心问题

告警有效率的持续提升是可观测性治理最难坚持的部分：噪音告警的识别需要分析大量历史数据，告警规则的优化建议难以系统性产出，监控覆盖盲区的发现依赖人工经验。

2 核心能力

• 告警质量分析：自动统计各告警规则的触发频次、响应率、误报率、处理时长，识别「高频低效」告警（频繁触发但长期被忽略/沉默的告警），生成告警规则优化建议
• 噪音告警识别：基于历史处理记录，识别与故障无关的噪音告警模式；对持续产生的噪音告警自动推荐沉默规则或阈值调整方案，供运维负责人审核确认
• 覆盖盲区发现：对比CMDB资产清单与监控覆盖情况，自动识别「有资产无监控」的盲区；对新上线资产的监控配置完整性进行自动验收
• 运营报告与治理复盘：自动生成日报、周报、月报和专项治理报告，展示告警有效率、噪音下降率、覆盖提升率、MTTA/MTTR变化、规则优化成效和待治理清单，支撑团队复盘和管理。
• 知识沉淀与规则推荐：将已确认的噪音模式、有效规则、处置经验、复盘结论和SOP沉淀为知识库内容，在后续规则配置、告警分析和运营报告中复用。

3 治理价值

告警有效率从典型的40-50%提升至70%+的目标，不再依赖运维人员的经验判断，而是由Agent持续分析并产出可操作的优化建议，将告警治理从「被动应对」变为「主动优化」。

5.3 知识库运营智能体

1 解决的核心问题

知识库的持续更新是知识治理最难坚持的环节：故障案例沉淀依赖工程师主动填写（实际执行率普遍偏低），知识时效性检查依赖人工定期审核，SOP可执行性评估缺乏系统化方法。

2 核心能力

• 故障案例自动提取：故障处理结束后，Agent自动从工单记录、操作日志、对话记录中提取结构化草稿（根因/影响/处置步骤/预防措施），推送给处理人确认入库，将「主动填写」变为「被动确认」，大幅提升沉淀率。
• 知识时效性巡检：定期扫描知识库中的文档，识别「长期未更新」的知识；结合变更记录和架构文档的变化，自动标记可能已失效的知识并推送责任人复核。
• SOP可执行性评估：对SOP文档进行结构化分析，评估其可执行性：步骤是否有明确的执行命令、前置条件是否清晰、异常处理路径是否完整；低分SOP自动推送改进建议。
• 重复知识合并：识别知识库中语义相似的重复文档，推荐合并或引用，避免知识库膨胀导致RAG检索准确率下降。

3 治理价值

故障案例沉淀率从通常不足30%提升至70%+，知识库的覆盖率和时效性持续改善，直接提升故障诊断Agent和知识问答Agent的推理质量。

5.4 ITSM流程质量运营智能体

1 解决的核心问题

ITSM流程的数字化建设完成后，流程质量的持续运营同样需要系统化支撑：意图识别及调度的准确率监控、SLA达标趋势的分析、高频问题的识别与推进——这些工作如果依赖人工统计，往往滞后且片面。

2 核心能力

• 调度质量分析：持续监控调度中心性能与调度准确性，以及低响应度、低满意度AI员工，提供配套的AI运营看板
• SLA趋势分析与预警：持续追踪各类工单的SLA达标率趋势，识别持续恶化的场景并提前预警；对即将SLA超时的工单自动推送提醒。
• 高频问题识别：对工单内容进行聚类分析，识别重复出现的高频问题；对已有SOP但仍重复出现的问题，推送知识库覆盖情况供责任人评估。
• 变更质量复盘：定期汇总变更成功率、回滚率、影响时长等质量指标，生成变更质量分析报告，识别高风险变更类型和高频失败场景。

5.5 自动化覆盖运营智能体

1 解决的核心问题

自动化覆盖率的提升需要持续识别：哪些业务系统还没有使用自动化，哪些IT对象还不支持自动化，哪些操作还没有自动化，但这个识别过程本身耗时且依赖经验。

自动化覆盖运营Agent通过结合CMDB业务系统和IT资源对象、ITSM变更工单、主机操作日志等多维度数据，自动统计业务/IT对象/标准操作等多维度的自动化覆盖率，自动识别高价值的自动化空白场景。

2 核心能力

• 业务系统覆盖分析：结合CMDB、ITSM和自动化平台数据，统计各业务系统是否接入自动化能力，识别未接入、低使用和绕行自动化的系统。
• IT对象覆盖分析：结合CMDB各类IT对象数据，按操作系统、数据库、中间件、网络设备、安全设备、存储、应用、页面UI等对象类型统计自动化通道覆盖情况，识别对象和型号覆盖盲区。
• 标准操作覆盖分析：梳理巡检、重启、清理、查询、扩缩容、配置变更、回滚等标准操作，判断哪些已有自动化、哪些仍依赖人工处理。
• 运营看板与任务推动：输出业务系统、IT对象、标准操作、脚本质量等多维度覆盖看板，自动生成治理任务并推送给责任人跟踪闭环。

5.6 AI辅助治理的整体价值

将上述治理智能体汇总来看，其核心价值在于将「周期性人工治理」转变为「持续自动治理」：

这些治理智能体本身也是Agentic Ops智能体生态的一部分，只不过它们的「用户」是运维治理负责人和平台团队，而非一线运维工程师。飞轮的双向转动，正是体现在这里：AI落地场景和AI治理工具共享同一套基建和平台，相互促进，协同演进。

06 客户案例实践

6.1 案例：某大型组织——从0到30+运维数字员工

CMDB是Agent的「认知地图」，服务依赖关系、资产归属、环境配置都在这里。CMDB不准确，意味着Agent对整个IT环境的认知是失真的。

1 背景

该组织运维场景复杂，覆盖测试环境管控、生产环境可靠性保障等运维全链路场景。在启动Agentic Ops建设之前，已完成一体化运维平台基础建设，具备相对完整的治理底座：CMDB准确率和监控覆盖率维持在较高水平，核心运维流程已数字化。

2 建设思路

核心思路：场景从效率出发+场景构建要平台化+一体化运维能力要丰富（MCP+数据+知识）。关键策略分三条主线并行推进：

• 丰富一体化运维能力：通过复用API网关将平台API快速转化为MCP接口，沉淀结构化运维数据和历史事件知识库，确保Agent「不仅会说话，更会干活」。
• 平台化构建：建立统一智能体开发底座，集成RAG知识库、MCP接口管理、Skill管理等能力，新场景快速复用已有组件，避免重复建设。
• 提效场景驱动：每个Agent参照运维服务目录清单，明确职责边界，以可量化的工时效率提升为核心目标，而非追求宏大的顶层设计。

3 典型场景成效

4 当前规模与关键启示

目前已生成30+每天工作量超过8小时的运维数字员工，调度500+智能体，各类典型场景持续迭代优化中。

• 场景落地反向推动治理：Agent对数据质量和工具接口的要求，倒逼一体化运维能力持续完善，形成正向飞轮。
• 治理底座决定AI天花板：当CMDB准确率从60%提升到85%，故障诊断Agent的误判率从30%+下降至个位数，治理质量与AI效果线性正相关。
• 平台化是规模化的前提：统一的智能体开发底座使新场景快速复用已有组件，30+数字员工的规模依赖平台化而非逐一开发。

07 结 语

没有银弹，但有飞轮。

AI大模型本身的进步会持续压低算法层的壁垒——通用推理能力会趋向商品化。但运维数据资产和MCP工具生态是难以快速复制的积累，将成为Agentic Ops时代的核心竞争壁垒。能够最先建立起运维数据、MCP工具生态、Agent能力库这三类资产的组织，将在Agentic Ops时代获得持续领先优势。

Agentic Ops的演进，不依赖某个单一技术的突破，而依赖治理与AI能力的持续相互强化。治理夯实AI落地的数据基础，AI反过来加速治理的持续运营——每一次循环都让飞轮转得更快，让AI覆盖更多场景，让治理质量再上一个台阶。