从 Azure SRE Agent 到 HolmesGPT：多云 Kubernetes 环境下的 AI 运维实践

Shengxu included in AI Kubernetes DevOps Observability

2026-04-17 About 1700 words 8 minutes

多云 Kubernetes 时代，SRE 的痛点已经不只是“告警太多”，而是调查链路太长、上下文太分散、跨云排障成本太高。真正消耗人的，不是看一眼图表，而是在多个云平台、日志系统、部署记录和工单系统之间反复切换。

这也是 AI SRE Agent 开始变得有现实价值的原因。它的目标不是做一个更会聊天的 Copilot，而是在告警触发之后，主动替你完成“查日志、找关联、猜根因、给建议”的前半段高重复工作。

本文聚焦三类代表方案：Azure SRE Agent、HolmesGPT 和 SREWorks，并重点讨论一个更现实的问题：在 AKS、EKS、Grafana Stack 这类多云、多工具并存的环境里，AI 运维到底该怎么落地。

说明：本文主要信息来自官方文档、CNCF 资料与公开技术分享，个别市场背景信息参考行业媒体报道。数据核对截止日期：2026-04-17。

一、凌晨三点的告警，是所有 SRE 的公敌

凌晨 3:17，你的手机响了。PagerDuty 显示：payments-service: HTTP 5xx rate > 5%。

你打开电脑，连上 VPN，先看 AKS 上的 Grafana，发现错误率在 14 分钟前开始抬升；接着切去 EKS 上的 Datadog，排查数据库指标；再回 Slack 问同事有没有人在半小时前做过 deploy。三个屏幕、五个标签页、两杯咖啡，40 分钟之后才发现根因是 EKS 上的 RDS 连接池耗尽。

这不是边缘案例，而是多云 SRE 团队的日常。

CNCF 2025 年度云原生调查显示，82% 的容器用户已在生产环境运行 Kubernetes，98% 的组织采用了云原生技术；在运行生成式 AI 推理的组织中，约 66% 使用 Kubernetes 管理部分或全部推理工作负载。

这也是 SRE Agent 需要解决的核心问题：不是帮你画更漂亮的 Grafana 大盘，而是在告警触发时，替你完成整条初步调查链路。

二、AI SRE Agent 市场全景

2025 到 2026 年，AI 运维助手市场快速成型，但产品形态差距很大。

第一类是云厂商原生 Agent。微软 Azure SRE Agent 已于 2026 年 3 月 GA，采用 Azure Agent Unit（AAU）计费；固定成本是每个 agent 每小时 4 AAU，活动成本与模型和 token 消耗相关。AWS DevOps Agent 也已于 2026 年 3 月底 GA，定位为跨 AWS 服务以及多云、on-prem 环境的运维调查与处置助手。

这类产品的最大优势，是与各自云平台的深度集成；最大限制也同样明显：原生控制面往往是 cloud-first。 一旦扩展到跨云或本地系统，能力不是没有，但安全边界、凭证管理、权限映射和治理复杂度会明显上升。Azure SRE Agent 官方文档明确支持通过 MCP 和 Python tools 扩展到外部系统。

第二类是开源平台。阿里巴巴开源的 SREWorks 沉淀了其运维工程实践，支持多云 Kubernetes 集群纳管，更适合有平台工程投入能力的大型组织。

第三类是云中立 AI Agent，也是本文重点。HolmesGPT 由 Robusta.dev 创建，并已在 2025 年 10 月被 CNCF 接纳为 Sandbox 项目。它的定位很明确：云原生 SRE Agent，不绑定单一云厂商，也不绑定单一模型提供方。 Holmes 通过 LiteLLM 兼容多种模型来源，包括 OpenAI、Anthropic、Azure AI、AWS Bedrock，以及兼容 OpenAI API 的本地部署模型。

维度	Azure SRE Agent	HolmesGPT	SREWorks
开源	❌	✅ CNCF Sandbox（2025/10）	✅
多云支持	Azure-first，跨云依赖扩展	✅ 原生中立	✅
K8s 生态集成	AKS 深度	38+ 内置集成	阿里云生态更强
执行动作	Azure API / Azure CLI 原生	Runbook / GitHub PR / 工具链扩展	自动化工作流
部署复杂度	低（SaaS）	低（Helm / CLI / UI）	高
LLM 选择	Azure OpenAI / Anthropic	多提供方，含本地模型	自定义
成本	4 AAU/hr + token 相关成本	主要是模型调用费	自托管

表中 HolmesGPT 的“38+ 内置集成”口径，基于官方安装文档。

三、Azure SRE Agent：边界清晰的企业级选择

它真正能做什么

Azure SRE Agent 的核心价值，在于把“告警进来、人工排查、执行变更、回写工单”这条流程自动化。

典型链路是：PagerDuty 触发 incident，Agent 拉取 Azure Monitor、Application Insights、代码仓库与变更信息，生成根因分析，然后在审批后执行 Azure CLI 缓解动作，例如重启、扩容或其他 Azure 侧恢复措施。微软 GA 公告和产品文档都强调了这一点。

支持接入的数据源包括日志、代码、部署和事件等维度。Microsoft Learn setup 文档中，列出了 GitHub、Azure DevOps、Datadog、Splunk、Elasticsearch、Dynatrace、New Relic 等集成方向，事件与工单协同也覆盖 PagerDuty 等场景。

多云场景的扩展边界

下面这张图更适合解释 Azure SRE Agent 在多云环境中的能力边界。

graph TD
    subgraph AZ["Azure Cloud / 原生支持区"]
        A[AKS Cluster] -->|原生遥测 / 零配置| B[Azure Monitor]
        C[Azure VMSS] -->|原生遥测 / 零配置| B
        B --> D{{Azure SRE Agent}}
        D -->|原生 API 自动执行恢复\n如扩容/重启| A
        D -->|原生 API 自动执行恢复| C
    end

    subgraph EXT["AWS / GCP / IDC / MCP 扩展区"]
        E[EKS Cluster] -.->|需手动配置 MCP 扩展\n或 Python tools| D
        D -.->|无原生跨云执行护栏\n凭证管理与安全边界\n需用户自行承担| E
    end

    style D fill:#0078D4,color:#fff
    style E stroke:#FF9900,stroke-dasharray: 5 5

graph TD
    subgraph AZ["Azure Cloud / 原生支持区"]
        A[AKS Cluster] -->|原生遥测 / 零配置| B[Azure Monitor]
        C[Azure VMSS] -->|原生遥测 / 零配置| B
        B --> D{{Azure SRE Agent}}
        D -->|原生 API 自动执行恢复\n如扩容/重启| A
        D -->|原生 API 自动执行恢复| C
    end

    subgraph EXT["AWS / GCP / IDC / MCP 扩展区"]
        E[EKS Cluster] -.->|需手动配置 MCP 扩展\n或 Python tools| D
        D -.->|无原生跨云执行护栏\n凭证管理与安全边界\n需用户自行承担| E
    end

    style D fill:#0078D4,color:#fff
    style E stroke:#FF9900,stroke-dasharray: 5 5

graph TD
    subgraph AZ["Azure Cloud / 原生支持区"]
        A[AKS Cluster] -->|原生遥测 / 零配置| B[Azure Monitor]
        C[Azure VMSS] -->|原生遥测 / 零配置| B
        B --> D{{Azure SRE Agent}}
        D -->|原生 API 自动执行恢复\n如扩容/重启| A
        D -->|原生 API 自动执行恢复| C
    end

    subgraph EXT["AWS / GCP / IDC / MCP 扩展区"]
        E[EKS Cluster] -.->|需手动配置 MCP 扩展\n或 Python tools| D
        D -.->|无原生跨云执行护栏\n凭证管理与安全边界\n需用户自行承担| E
    end

    style D fill:#0078D4,color:#fff
    style E stroke:#FF9900,stroke-dasharray: 5 5

Azure SRE Agent 的原生控制面是 Azure-first。对 AKS 和其他 Azure 资源，它能直接接入 Azure 控制平面；对 AWS、GCP 或 IDC 资源，虽然官方支持通过 MCP 和 Python tools 扩展，但复杂度会转移给用户自身的 IAM、凭证、网络边界与审计设计。

这里的关键点不是“能不能扩”，而是扩了以后谁来为权限模型、审计链路和安全责任买单。在企业环境里，这往往比“功能支持”更决定能否上线。

数据驻留：合规场景不可忽视

根据 Learn 文档，Azure SRE Agent 的数据处理区域与所选模型提供方直接挂钩：

在 EU / EFTA / UK，默认模型提供方是 Azure OpenAI。
Anthropic 在这些区域是可选项而非默认项，且不受 EU Data Boundary 保护。
一旦选择 Anthropic，提示词、响应和资源分析内容可能在美国处理。
在 GCC、GCC High、DoD 等政府云，Anthropic 不可用。

因此，对于金融、医疗、政府等受监管行业，Azure SRE Agent 是否合规，不是只看“Agent 本身部署在哪个区域”，还要看模型提供方是谁、数据会落到哪里。

这也是 HolmesGPT 在数据主权层面更灵活的原因之一：如果组织需要，本地部署模型是可选项，而不是例外路径。

四、HolmesGPT：为多云而生的 CNCF SRE Agent

设计哲学：不是 Copilot，是 Agent

HolmesGPT 和多数 AI 助手的根本差异，在于它强调 agentic investigation，也就是主动、多轮、逐步调查。

Holmes 官方文档对其核心机制解释得很明确：当问题被抛给系统后，它不是一次性作答，而是决定下一步该查哪个工具、抓取什么数据、如何控制上下文体积，然后再继续推理。

这套思路可以拆成三个关键策略：

源端过滤（Aggregations at Source）：尽量在数据源侧做 PromQL 或其他查询过滤。
可遍历 JSON 树：对大型 API 响应按需展开，而不是一次性塞进上下文。
输出预算（Output Budgeting）：动态控制上下文体积，避免 token 溢出。

下面这张图更接近 HolmesGPT 的核心工作流。

sequenceDiagram
    participant Alert as 告警源
    participant Holmes as HolmesGPT Core
    participant Tools as 工具集
    participant LLM as LLM

    Alert->>Holmes: 1. 触发告警（如 HTTP 5xx > 5%）
    loop Agentic Reasoning Loop
        Holmes->>LLM: 2. 传递当前上下文，请求下一步动作
        LLM-->>Holmes: 3. 决策：调用特定工具
        Holmes->>Tools: 4. 执行查询
        Note over Tools: 源端过滤 + 按需展开\n只返回高价值压缩数据
        Tools-->>Holmes: 5. 返回过滤后的结构化数据
        Holmes->>LLM: 6. 验证假设，决定是否继续深挖
    end
    Holmes->>Alert: 7. 输出 RCA 并写回工单或 Slack

sequenceDiagram
    participant Alert as 告警源
    participant Holmes as HolmesGPT Core
    participant Tools as 工具集
    participant LLM as LLM

    Alert->>Holmes: 1. 触发告警（如 HTTP 5xx > 5%）
    loop Agentic Reasoning Loop
        Holmes->>LLM: 2. 传递当前上下文，请求下一步动作
        LLM-->>Holmes: 3. 决策：调用特定工具
        Holmes->>Tools: 4. 执行查询
        Note over Tools: 源端过滤 + 按需展开\n只返回高价值压缩数据
        Tools-->>Holmes: 5. 返回过滤后的结构化数据
        Holmes->>LLM: 6. 验证假设，决定是否继续深挖
    end
    Holmes->>Alert: 7. 输出 RCA 并写回工单或 Slack

sequenceDiagram
    participant Alert as 告警源
    participant Holmes as HolmesGPT Core
    participant Tools as 工具集
    participant LLM as LLM

    Alert->>Holmes: 1. 触发告警（如 HTTP 5xx > 5%）
    loop Agentic Reasoning Loop
        Holmes->>LLM: 2. 传递当前上下文，请求下一步动作
        LLM-->>Holmes: 3. 决策：调用特定工具
        Holmes->>Tools: 4. 执行查询
        Note over Tools: 源端过滤 + 按需展开\n只返回高价值压缩数据
        Tools-->>Holmes: 5. 返回过滤后的结构化数据
        Holmes->>LLM: 6. 验证假设，决定是否继续深挖
    end
    Holmes->>Alert: 7. 输出 RCA 并写回工单或 Slack

这也是 HolmesGPT 更适合多云运维的原因。它的重点不是“先有一朵云，再往外扩”，而是默认你本来就在一个杂糅环境里：Kubernetes、数据库、日志平台、告警平台、工单系统、本地 API 和多家云厂商一起存在。

安全设计：最小权限原则

Holmes 官方文档强调，多数观测类工具集以只读方式设计；但这句话不能被机械理解为“所有工具都只读”。因为 Holmes 同时提供了 bash toolset，而且当前官方文档明确写着它默认启用，边界通过 allow/deny list 控制。

更准确的说法应该是：Holmes 的默认安全理念偏只读观测，但实际生产部署仍需单独审查具执行能力的 toolset，例如 bash。

推荐的生产模式，是部署一个中心化 Holmes 实例，给它限定范围的凭证，让工程师通过统一入口去查生产数据，而不是给每个人发一套高权限凭证直连生产。这和平台工程里的最小权限原则是一致的。

当你用 HTTP connector 去接私有 API 时，Holmes 还要求显式声明允许访问的主机、路径和 HTTP 方法。这是它安全边界设计里很关键的一部分：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
toolsets:
  internal-cmdb:
    type: http
    config:
      endpoints:
        - hosts: ["cmdb.internal.company.com"]
          paths: ["/v1/assets/*"]
          methods: ["GET"]
      auth:
        type: bearer
        token: "{{ env.CMDB_TOKEN }}"

38+ 工具集覆盖整个多云技术栈

Holmes 官方安装文档显示，它支持 38+ built-in integrations。这些工具跨越 metrics、logs、traces、ITSM、CI/CD、Kubernetes、数据库和云平台。

类别	代表性支持工具
指标	Prometheus、VictoriaMetrics、Datadog、New Relic
日志	Loki、Elasticsearch / OpenSearch、Datadog、Splunk
追踪	Tempo、Datadog、New Relic
K8s 生态	Kubernetes、Helm、ArgoCD、OpenShift、Cilium
云平台	AWS RDS、Azure SQL、Azure AKS、GCP
ITSM	PagerDuty、OpsGenie、Jira、ServiceNow
数据库	PostgreSQL、MySQL、ClickHouse、MongoDB

对多云团队来说，这件事的意义不是“支持工具很多”本身，而是你终于可以把跨系统调查链路放进同一个 Agent 推理过程里，而不是靠人脑手工拼接。

五、Grafana Stack + HolmesGPT：三信号联动

对已经有 Grafana Stack 的团队，HolmesGPT 的价值不在于替换 Prometheus、Loki、Tempo，而在于把三类信号串成一条推理链。

graph LR
    subgraph OBS["多云数据底座"]
        P[(Prometheus / Mimir
Metrics)]
        L[(Loki
Logs)]
        T[(Tempo
Traces)]
    end

    subgraph HOL["HolmesGPT 智能推理层"]
        C[Context Manager
Data Summarizer]
        A{{Agentic Router}}
    end

    subgraph DEST["响应与协同端"]
        S[Slack / Teams]
        D[PagerDuty / Jira / GitHub]
    end

    P -->|PromQL| C
    L -->|LogQL| C
    T -->|TraceQL| C
    C <-->|结构化上下文| A
    A -->|RCA 报告 / 修复建议| S
    A -->|工单更新 / 开启 PR| D

    style A fill:#8A2BE2,color:#fff

graph LR
    subgraph OBS["多云数据底座"]
        P[(Prometheus / Mimir
Metrics)]
        L[(Loki
Logs)]
        T[(Tempo
Traces)]
    end

    subgraph HOL["HolmesGPT 智能推理层"]
        C[Context Manager
Data Summarizer]
        A{{Agentic Router}}
    end

    subgraph DEST["响应与协同端"]
        S[Slack / Teams]
        D[PagerDuty / Jira / GitHub]
    end

    P -->|PromQL| C
    L -->|LogQL| C
    T -->|TraceQL| C
    C <-->|结构化上下文| A
    A -->|RCA 报告 / 修复建议| S
    A -->|工单更新 / 开启 PR| D

    style A fill:#8A2BE2,color:#fff

graph LR
    subgraph OBS["多云数据底座"]
        P[(Prometheus / Mimir
Metrics)]
        L[(Loki
Logs)]
        T[(Tempo
Traces)]
    end

    subgraph HOL["HolmesGPT 智能推理层"]
        C[Context Manager
Data Summarizer]
        A{{Agentic Router}}
    end

    subgraph DEST["响应与协同端"]
        S[Slack / Teams]
        D[PagerDuty / Jira / GitHub]
    end

    P -->|PromQL| C
    L -->|LogQL| C
    T -->|TraceQL| C
    C <-->|结构化上下文| A
    A -->|RCA 报告 / 修复建议| S
    A -->|工单更新 / 开启 PR| D

    style A fill:#8A2BE2,color:#fff

配置示例

根据官方文档，如果启用了 grafana/loki，就应该关闭默认的 kubernetes/logs，否则系统会同时存在多个日志来源，影响排障路径选择。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# values.yaml
holmes:
  llmProvider: openai
  openAiApiKey: "sk-..."

  toolsets:
    prometheus:
      enabled: true
      config:
        prometheus_url: "http://kube-prometheus-stack-prometheus.monitoring:9090"

    grafana/loki:
      enabled: true
      config:
        api_url: "http://loki-gateway.monitoring:80"
        external_url: "https://grafana.yourcompany.com"

    grafana/tempo:
      enabled: true
      config:
        api_url: "http://tempo.monitoring:3100"
        grafana_datasource_uid: "tempo-uid"

    kubernetes/logs:
      enabled: false

官方推荐的安装方式为：

1
2
helm repo add robusta https://robusta-charts.storage.googleapis.com
helm install holmesgpt robusta/holmes -f values.yaml

三信号串联的实际排障效果

当 AlertManager 触发 HTTPRequestsErrorRate > 5% 时，Holmes 的调查方式通常是这样一条链：

先确定时间窗口，从 Prometheus 看错误率曲线。
再关联变更，查 Deployment 或 release 历史。
然后深挖日志，用 Loki 找异常模式。
最后验证调用链，用 Tempo 定位延迟或失败位置。

输出结论通常是：给出初步 RCA，并附带下一步修复建议。

这段更接近方法论说明，不是某个单一官方案例的逐字复述。它的重点是：HolmesGPT 的价值来自跨信号串联，而不是单点问答。

六、多云 Operator Mode：24/7 主动巡检

除了被动响应告警，HolmesGPT 还有 Operator Mode。根据官方文档，它是一个 Kubernetes-native 的健康检查控制器体系，围绕 HealthCheck 和 ScheduledHealthCheck 两类资源展开。

graph TD
    subgraph K8S["Kubernetes 多云管理集群"]
        SHC[ScheduledHealthCheck CRD
定时巡检 Cron]
        HC[HealthCheck CRD
一次性检查 Job]
        O[Holmes Operator
轻量控制器]
        API[Holmes API Server
无状态推理服务]

        SHC -->|触发 / 生成| HC
        HC -->|监听事件| O
        O -->|HTTP 任务委派| API
    end

    API -->|1. 拉取多云遥测数据| DS[(Prometheus / Loki / AWS RDS / Azure SQL)]
    API -->|2. 推送分析报告| OUT[Slack / PagerDuty / GitHub]

    style O fill:#2E8B57,color:#fff
    style API fill:#9370DB,color:#fff

graph TD
    subgraph K8S["Kubernetes 多云管理集群"]
        SHC[ScheduledHealthCheck CRD
定时巡检 Cron]
        HC[HealthCheck CRD
一次性检查 Job]
        O[Holmes Operator
轻量控制器]
        API[Holmes API Server
无状态推理服务]

        SHC -->|触发 / 生成| HC
        HC -->|监听事件| O
        O -->|HTTP 任务委派| API
    end

    API -->|1. 拉取多云遥测数据| DS[(Prometheus / Loki / AWS RDS / Azure SQL)]
    API -->|2. 推送分析报告| OUT[Slack / PagerDuty / GitHub]

    style O fill:#2E8B57,color:#fff
    style API fill:#9370DB,color:#fff

graph TD
    subgraph K8S["Kubernetes 多云管理集群"]
        SHC[ScheduledHealthCheck CRD
定时巡检 Cron]
        HC[HealthCheck CRD
一次性检查 Job]
        O[Holmes Operator
轻量控制器]
        API[Holmes API Server
无状态推理服务]

        SHC -->|触发 / 生成| HC
        HC -->|监听事件| O
        O -->|HTTP 任务委派| API
    end

    API -->|1. 拉取多云遥测数据| DS[(Prometheus / Loki / AWS RDS / Azure SQL)]
    API -->|2. 推送分析报告| OUT[Slack / PagerDuty / GitHub]

    style O fill:#2E8B57,color:#fff
    style API fill:#9370DB,color:#fff

Holmes Operator 主要负责调度和资源管理；真正的推理工作由 Holmes API 服务承担。官方文档也明确提到，Operator 模式仍在演进中，生产环境要关注版本变化和成本控制。

多云定时巡检配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: holmesgpt.dev/v1alpha1
kind: ScheduledHealthCheck
metadata:
  name: multi-cloud-hourly
spec:
  schedule: "0 * * * *"
  query: |
    Hourly multi-cloud health check:
    - AKS: pod restarts and error rates across all namespaces
    - EKS: database connection pool usage (AWS RDS tool)
    - Check Loki for cross-cluster error spikes in last 60min
    - Identify any stuck rollouts or pending pods
  destinations:
    - type: slack
      config:
        channel: "#platform-health"
    - type: pagerduty
      config:
        integration_key: "${PD_INTEGRATION_KEY}"
  timeout: 180

需要强调的是：Operator Mode 当前仍属于快速演进能力。 高频巡检会显著增加模型调用成本，生产环境更适合从低频巡检开始，而不是一上来就做高频全量扫描。

七、踩坑指南与生产建议

配置层面

启用 grafana/loki 后，关闭 kubernetes/logs，否则日志源会重复。
多云环境里配置多个同类 toolset 时，命名要清晰隔离，避免后续维护混乱。
Holmes 的 bash toolset 默认启用，生产前必须审查 allow/deny list。
安装命令、chart 路径和 operator 字段都可能随版本变化，部署前应始终以当前官方文档为准。

架构层面

先从只读调查开始，再考虑开放自动执行。
把 Agent 当作新的高权限主体来治理，而不是当普通插件。
Holmes API 服务建议做多副本，避免调查链路本身成为单点。

这里最后三条更接近生产经验判断，而不是官方硬性要求。

八、选型决策

如果你的业务以 Azure 为主，且多云扩展需求有限，那么 Azure SRE Agent 往往是更省运维成本的选择。它的优势是原生执行能力强、控制面整合深，但需要特别关注模型提供方与数据处理区域，尤其是在 EU / EFTA / UK 或更严格的合规场景下。

如果你的环境已经明显跨入 EKS、GKE、私有集群或数据主权要求更高的场景，那么 HolmesGPT 更像是自然选择。它的价值不只是“支持多云”，而是把多云、多工具、多信号这些现实复杂性当作默认前提来设计。

如果你需要的是一个更重型的平台化运维体系，并且组织本身具备持续的平台工程投入能力，那么 SREWorks 也有其位置，但部署与治理复杂度会更高。

对于已经拥有 Prometheus、Grafana、Loki 底座的团队，HolmesGPT 更像一个低改造成本的增量推理层。它不要求你推翻现有观测栈，价值主要来自把指标、日志、追踪和外部系统信息串成自动调查链路。这个判断基于产品架构与部署方式推导，不是官方宣传原文。

结语

2026 年的 SRE，不该继续主要依赖人肉熬夜去完成重复性排障。

更现实的方向，是让 Agent 去承担“收集证据、串联上下文、生成初步 RCA”这类高重复劳动，而把“权限边界设计、系统弹性、Runbook 质量、多云容灾策略”留给人来主导。

这个分工，才是 AI 运维真正有价值的部分。

参考资料

CNCF：HolmesGPT 项目页与官方博客
HolmesGPT 官方文档：安装、Why HolmesGPT、Bash toolset、Operator、ScheduledHealthCheck
Microsoft Learn / Azure 官方：Azure SRE Agent GA、模型提供方选择、Anthropic subprocessor、setup
AWS 官方：AWS DevOps Agent GA