凌晨两点被 PagerDuty 震醒，爬起来查日志、翻指标、追踪链路，半小时后才发现是某个 Pod 内存泄漏的老问题。你是不是也经历过这样的 on-call 夜？

2026 年，这条链路正在被 AI Agent 改写。Agentic SRE —— 让 Agent 替你完成告警接收、日志分析、根因定位、甚至自动修复的完整闭环——已经从概念进入落地阶段。关键是，三款主流开源工具已经跑起来了。

一、Agentic SRE：从告警降噪到自主修复

传统 AIOps 解决的核心问题是「告警降噪」——把几百条告警合并成几个事件，但分析根因和修复还得人来做。Agentic SRE 的跃迁是：Agent 不仅能识别异常，还能调用工具查日志、查指标、查追踪，综合推理出根因，然后执行 runbook 修复。

这个转变相当于从「告警通知员」升级到「值班 SRE 实习生」——他可能还不能完全独立，但常规问题已经不用你半夜爬起来看了。

现在的开源生态里，有三款值得关注：

工具	Stars	创建时间	定位
HolmesGPT	2.8k	2024.05	通用 SRE Agent，CNCF Sandbox
K8sGPT	8k	2023.03	K8s 集群专精，CNCF Sandbox
Aurora	369	2026.01	LangGraph 多 Agent 架构，跨云

二、HolmesGPT 实战：从安装到端到端告警调查

HolmesGPT 是 Robusta 联合 Microsoft 开源的 SRE Agent，2026 年进入 CNCF Sandbox。它能接收 Alertmanager 或 PagerDuty 的告警，拉取关联的日志和指标，用 LLM 分析根因，最后把结论写回 Slack。

安装很简单，三选一：

# 方式一：Homebrew（macOS/Linux）
brew tap robusta-dev/homebrew-holmesgpt && brew install holmesgpt

# 方式二：pip
pip install holmesgpt

# 方式三：Docker
docker run -it robustadev/holmesgpt:latest

装好之后，配置一下 LLM Provider。HolmesGPT 支持 OpenAI、Anthropic、以及本地部署的模型：

# ~/.holmesgpt/config.yaml
llm:
  provider: openai
  model: gpt-4o
  api_key: ${OPENAI_API_KEY}

toolsets:
  - kubernetes
  - prometheus
  - pagerduty

核心玩法是这个命令——手动触发一次告警调查：

holmesgpt investigate --alert 'pod CrashLoopBackOff in namespace production'

HolmesGPT 会执行多步推理：查 K8s API 确认 Pod 状态 → 拉 Prometheus 看指标趋势 → 分析日志 → 输出根因和修复建议。整个过程几十秒，输出的结论直接回写到 PagerDuty 或 Slack。

CNCF 有一篇博客介绍了这家公司用 HolmesGPT 结合自定义 Python playbook（约 200 行）覆盖了标准工具集覆盖不到的场景。那个 playbook 做的事就是：当 HolmesGPT 查不到足够信息时，自动执行一组额外的诊断步骤。

三、K8sGPT：一键诊断你的集群

如果你的栈纯粹在 K8s 上，K8sGPT 可能是更轻量的选择。8k stars、CNCF Sandbox、社区比 HolmesGPT 大一个数量级。

安装：

# Homebrew
brew tap k8sgpt-ai/k8sgpt && brew install k8sgpt

# 配置 LLM
k8sgpt auth --backend openai --model gpt-4o

使用更简单——一条命令扫整个集群的异常资源：

k8sgpt analyze --explain

它会逐个检查所有异常 Pod、Service、Deployment，用 LLM 解释原因和修复建议。也可以按类型和命名空间过滤：

k8sgpt analyze --filter=Pod --namespace=production --explain

K8sGPT 的优势是零配置——装好就能用。缺点是它只管「分析」，不做「修复」，也不对接 PagerDuty 等告警源。它是 SRE 工具箱里的一把螺丝刀，不是整套工具柜。

四、Aurora：多 Agent 协作的根因分析

Aurora 是三款中最年轻的一个（2026 年初才开源，369 stars），但它的架构设计是最有野心的——用 LangGraph 编排多个 Agent 协作，支持跨云（AWS/Azure/GCP/K8s）调查，集成 22+ 工具。

安装方式：

git clone https://github.com/Arvo-AI/aurora.git
cd aurora
make init      # 初始化配置
make prod-prebuilt  # 用 Docker Compose 启动生产环境

部署起来之后，Aurora 能做的事情远超单纯的一条命令查问题。它的核心流程是：

1. 告警触发：PagerDuty / Datadog / Grafana 等 webhook 推过来一个告警
2. 多 Agent 协同调查：一个 Agent 查 K8s 集群状态，另一个查云资源，第三个查知识库里的历史事故记录
3. 知识图谱分析：Memgraph 维护的基础设施依赖图能告诉你「这个 Pod 挂了会影响哪些下游服务」
4. 输出根因 + 修复建议：合成一份结构化 RCA，支持导出到 Confluence

Aurora 还支持自定义 LLM Provider，包括本地部署的 Ollama，适合内网环境使用。不过它比较重——不是一条命令能跑起来的工具，需要 Docker Compose 或 Helm Chart 部署全套服务栈。

五、三款工具怎么选

场景	推荐	理由
K8s-only 团队，快速诊断	K8sGPT	零配置上手，一键扫全集群
多云/混合架构，需要端到端管线	HolmesGPT	告警接入→根因分析→回写闭环
需要跨云分析（AWS/Azure/GCP+K8s）	Aurora	LangGraph 多 Agent，支持更多云数据源
刚起步，想先试试	K8sGPT	5 分钟就能看到效果
有自定义诊断逻辑	HolmesGPT + 自定义 playbook	200 行 Python 就能覆盖团队独有的诊断场景

HolmesGPT 是目前三款中最平衡的选择：插件架构灵活、CNCF 社区背书、有实际生产部署案例（已有多篇 CNCF 官方博客）。Aurora 的 LangGraph 架构设计最先进，但 369 stars 说明社区还没跑起来。

六、自愈管线的架构：告警 → 分析 → 修复

一个完整的 Agentic SRE 管线是这样跑的：

1. 感知层：Alertmanager / PagerDuty 产生告警
2. 接入层：HolmesGPT 接收告警，拉取关联数据（日志/指标/追踪）
3. 推理层：LLM 综合分析，输出根因 + 修复方案
4. 执行层：执行预定义的 runbook（扩缩容/重启/回滚），或回写分析结论到 Slack

你不需要一次性全部搭起来。可以从第 2 步开始——先用 HolmesGPT 做手动告警调查，让团队信任它的分析结果，再逐步接入自动执行。

不过有几点要注意：HolmesGPT 每次调查都会消耗 token 调用 LLM，高频告警场景的推理成本不低；K8sGPT 只覆盖 K8s 场景，VM 和数据库不管；「自动修复」在大多数工具里还是「建议修复方案」，真正的 auto-remediation 需要自定义 runbook 和安全护栏。

国内云环境（阿里云/腾讯云/华为云）的数据源支持也需要额外验证——三款工具主要针对 AWS/Azure/GCP 设计，用到国内云上需要自己适配。

七、落地建议

如果你今天想试试，推荐这条路径：

第一步：装 K8sGPT，跑一次 analyze --explain，看看它对你的集群能说出什么来。花不了 5 分钟。

第二步：如果觉得有用，装 HolmesGPT，配置接你的 Alertmanager，专门挑一两个低频但耗时的告警场景做手动调查验证。

第三步：跑通之后再考虑写自定义 playbook 或接入自动修复。别一上来就想全自动——先让团队信任 Agent 的分析能力，再考虑放权给它执行。

2026 年，Agent 帮你查根因不再是 demo 里的段子，是已经在生产环境跑起来的事。HolmesGPT 的 CNCF 官方博客已经展示了几家公司在生产环境用它做告警调查的真实案例，K8sGPT 的 8k stars 也说明这个方向已经被社区验证过了。核心区别不是谁家模型更强，而是你的团队有没有迈出第一步：装一个试试。

项目地址：

• https://github.com/HolmesGPT/holmesgpt
• https://github.com/k8sgpt-ai/k8sgpt
• https://www.aurorasre.ai/