运维智能体能自动到什么程度：信通院三级分级与 Azure SRE Agent 对照

运维 Agent 能自动到什么程度？把这个问题拆开，至少要回答三件事：Agent 负责哪些环节、谁批准它动手、出错后能不能追责。

信通院的三级成熟度

中国信通院/云计算开源产业联盟在 2025 可信云大会发布《运维智能体（SRE AGENT）能力要求》，参编单位含信通院、移动云、华为云、蚂蚁、农业银行、小米、百度等。分级只有三级，高级别宜包含低级别，每级满足 90% 能力项即认为达到该级：

• 1 级 Initial Level 初始级：智能运维体通过数据收集支撑运维人员开展日常运维工作。
• 2 级 Comprehensive Level 全面级：智能体具备分析和解决方案输出能力，在运维人员审批情况下具备可执行能力。
• 3 级 Excellent Level 优秀级：智能体具备自主收集、分析、执行和自主迭代能力。

分界点很明确：1 级不碰执行，2 级执行但必须有人审批，3 级才把执行和迭代一起交给智能体。

四层框架

1. 运维场景层：流程管理、变更管理、故障管理（异常检测、根因定位与自愈）、风险管理（预判性监控与容错）、运维管理（资源调度与配置优化）。
2. 协同能力层：多智能体协同（任务分配与联动作业）、跨系统协同（对接 CMDB、监控等）、智能体安全（数据加密、权限控制、行为审计）。
3. 智能体层：感知能力读取运维数据（指标/日志/链路）、环境数据（硬件状态/网络拓扑）、交互数据（用户指令/反馈）；控制能力做信息理解（数据语义解析与特征提取）、记忆（知识图谱构建与经验存储）、计划（任务拆解与决策路径生成）；行动能力执行修复、扩缩容等物理操作，也支持工单生成、告警通知等人机协同。
4. 智能体底座：模型接入（兼容 AI 大模型与专业算法引擎）、软件质量（高可用架构与性能保障）、自维护（自监控、自升级与故障隔离）。

故障定位单独做了三级示例，分现象定位、对象定位、原因定位三种：

• 1 级：具备故障现象定位能力，通过现象关联分析实现故障初步定位及影响范围识别。
• 2 级：具备故障对象定位及部分原因定位，能结合多源数据做多维度根因分析。
• 3 级：精准分析故障原因与趋势，输出处置预测报告。

Azure SRE Agent 的落点

Azure SRE Agent 概述（2026-08 更新）给了一个具体实现。它连接 Azure 资源、可观测工具、事件平台与源代码仓库，在一个地方调查带运维上下文的问题，并在配置的权限、运行模式和策略内运行受控自动化。

典型内存事件流程：查询 Application Insights 识别告警前 40 分钟开始的内存趋势 → 关联到两小时前 GitHub 仓库的部署事件 → 定位具体 commit，建议重启受影响 Pod 或调整 HPA 内存扩缩阈值 → 创建 ServiceNow/PagerDuty/事件通道工单，附完整调查摘要。

三种工作方式：

• 事件自动化处理：告警触发，查询监控、关联跨系统信号、识别根因、提出缓解。
• 自动化预定工作流程：安排主动健康检查、合规扫描、常规运维任务。
• 调查和建议：用自然语言提问，如“上一小时发生了什么变化？”“为什么这项服务会被降级？”，得到有来源的答案。

五个扩展点：技能（独立能力，含 Marketplace Runbook 与 Azure CLI 脚本，无需写代码）、定制代理（面向特定运维领域，可在 Agent 构建器自建）、Python 工具（自定义逻辑、数据转换、API 集成）、MCP 服务器（连接 Datadog、Splunk、New Relic、Dynatrace、Elasticsearch 等预配置连接器，或任何自定义工具）、智能体挂钩（在工具执行后或智能体停止时触发，用于强制策略、发出遥测、接入外部审批流）。

集成面覆盖 Azure Monitor、Application Insights、Log Analytics、PagerDuty、ServiceNow、GitHub、Azure DevOps、Azure 数据资源管理器（Kusto）、MCP 服务器、Teams、Outlook，也可通过托管连接器接 Google Drive、SharePoint、Notion、Confluence 等 SaaS。

治理决定了自动执行能不能落地

每个拟议的工具调用在运行前都经过治理控制。安全侧包括：VNet 集成、NSG 规则、私有 DNS 解析，可访问私有端点/内部 API/锁定资源；代理用托管身份认证，在 Azure RBAC 下运行，GitHub Enterprise 支持“自带 GitHub App”以受治理的服务身份认证。

工具级访问控制把每个工具设为允许/请求/拒绝，管理员设全局护栏，团队负责人定制每个定制代理，用户在对话中批准工具。基础设施走 Bicep 模板与 Azure CLI 声明式部署，代理、网络配置、身份和工具策略与其他 Azure 资源共用同一套 CI/CD。平台团队通过私有插件市场把批准技能发布到私有 GitHub 仓库，整个租户的智能体从统一治理目录安装获批技能。运行模式上，审核模式下需要审批的写操作由 SRE 代理管理员在执行前批准；自主模式下代理无需等待即可应用。计费按使用量，以 Azure 代理单位（AAU）计量，含持续监控的固定常开部分与按用量计费的主/被动工作部分。

级别 vs 能力 vs 是否自动执行

对照 Azure 的实现，2 级对应审核模式：写操作等管理员批准后执行；3 级对应自主模式：代理不等待直接应用。工具级 allow/request/deny、行为审计、Bicep 声明的工具策略、私有插件市场这些机制，本身不提升智能体的分析能力，但决定了前面那些自动化动作能不能被允许进入生产环境。