五大开放源码自建 AI SRE Agent 底座横评，使运维告别 “人肉筛查”

作者：老甄说运营维护 2026-09-17 10:12:32 ** 运维** 人力智慧 本文精选五个最具代表性的开源 AI SRE Agent 底座，从定位、架构、中枢本领到适用情形，做一次全盘横评。凌晨三点，预警风暴来袭，On Call 项目师还在睡梦中 —— 假如你也曾经历过这种情形，那这篇文章值得一读。

开篇：为什么我们须要 AI SRE Agent？

2026 年的运营维护小组面临一个尴尬的矛盾：底座设施越来越复杂，不过人力预算越来越紧。Kubernetes 机群、微支撑结构、多云上线 —— 每一次手段演进都在增添 “凌晨被叫醒” 的概率。老牌预警系统的问题是 “只会叫，不会查”：Prometheus 告诉你 CPU 飙了，Grafana 给你画了条线，不过从 “告警响了” 到 “找到根源” 之间的那段路，还是得靠人肉筛查。

AI SRE Agent 的核心价值，就是把这段 “人肉排查” 变成自动化闭环：接收告警 → 关联上下文（日志、指标、Trace、部署记录）→ 推理根因 → 给出修复建议（甚至直接修复）。最近，Git Hub 上涌现了一批高质量的开源 AI SRE Agent 平台，它们不约而同地选择了自建部署、LLM 驱动、工具链集成的路线。本文精选五个最具代表性的项目，从定位、架构、核心能力到适用场景，做一次全面横评。

五大底座一览

Open SRE：打造 SRE 赛道的 SWE-bench

工程锚定

Open SRE 的野心很大 —— 它不只是做一个 AI SRE Agent，反倒要做 SRE 赛道的 SWE-bench：一个开放的强化钻研环境，使 AI 能在模拟的产出异常中反复训练，最终拥有真切的事件响应能力。这个思路很对。编码赛道有 SWE-bench 使范式刷 benchmark，不过产出环境异常（分布式体系崩溃、级联故障、设定漂移）远比代码 bug 繁复，缺乏基准化的调参和评估环境。Open SRE 试图填补这个空白。

中枢本领

• 结构化事件调查：跨日志、指标、Trace、上线记录、设定改动的联系根源拆解
• Runbook 感知推理：自助读取并运用团队现有的 Runbook
• 敏感信息脱敏：在触发外部 LLM 前，自动掩码 Pod 名、机群 ID、账号 ID 等
• 好几类交互界面：交互式 REPL Shell、无头 CLI（适配 CI/CD 整合）、Python API、一键从告警文件启动调查
• 会话管理：具备断点复原，每个会话追踪 token 消耗
• 本地 Agent 观测：能监控 Claude Code、Cursor、Codex 等编码 Agent 的运转状态

整合体系

60+ 整合涵盖主流技术栈：
– LLM 带来商：Anthropic、Open AI、Codex、Ollama、Gemini、Open Router、NVIDIA NIM、Bedrock
– 可观测性：Grafana 全家桶（Loki/Mimir/Tempo）、Datadog、Honeycomb、Coralogix、Cloud Watch、Sentry、Elasticsearch、Splunk、New Relic
– 底座基建：Kubernetes、AWS 全栈（S 3/Lambda/EKS/EC 2/Cloud Trail）、GCP、Azure、Argo CD、Helm
– 资料库：Postgre SQL、My SQL、Mongo DB、Click House、Redis、Snowflake
– 事件管控：Pager Duty、Opsgenie、Jira、Alertmanager、incident.io、Service Now
– 通信：Slack、Discord、Telegram、Google Docs

事务机理

复制

CODE
告警触发 → 获取告警上下文 + 关联日志/指标/Trace/近期部署
 → 可选：敏感标识符脱敏
 → 工具调用循环中推理，验证假设
 → 生成结构化调查报告（根因 + 证据链）
 → 建议下一步（可选：直接执行修复）
 → 推送摘要到
Slack/PagerDuty/Telegram
1.
2.
3.
4.
5.
6.
7.
8.

适用情形

• 希望搭建定制化 AI SRE Agent 的中大型小组
• 须要跨多云、多资料源的统一事件调查
• 重视稳妥合规（脱敏、审计）的公司环境
• 想参与 AI SRE 探究和基准评估的技术小组

Keep：预警管控的 “瑞士军刀”

工程锚定

Keep 的自我定位是 “开放源码 AIOps 和预警管控底座”，不过它更像是一个告警编排中枢—— 把分散在 38+ 监控利器中的告警汇聚、去重、联系、富化，然后通过 YAML 事务流无人化处置。假如说 Open SRE 是 “AI 侦探”，Keep 就是 “预警调度中心”。它不一定自己去查根源，但它保证对路的预警在正确的时间到达正确的人。

中枢本领

• 归一告警视图：38+ 观测利器（Datadog、Prometheus、Grafana、Elastic、Splunk、New Relic、Cloud Watch、Dynatrace、Sentry、Zabbix……）的告警汇聚到一个面板
• 智能预警处置：去重、联系、过滤、富化，把告警风暴变成可运维的事件
• YAML 事务流引擎：类似 “Git Hub Actions for 观测”，声明式定义触发器 → 流程 → 动作
• AIOps 2.0：AI 推动的预警关联和摘要
• 公司级稳妥：SSO/SAML/OIDC/LDAP + RBAC/ABAC，具备私有化上线和气隙环境

事务流示例

复制

YAML
# 当 Critical 告警来自支付服务时，自动创建 Jira 工单并通知 Slack
workflow:
 triggers:
 - type: alert
 filters:
 severity: critical
 service: payment
 steps:
 - name: enrich
 provider: datadog
 action: get_related_logs
 actions:
 - name: create_ticket
 provider: jira
 action: create_issue
 with:
 project: SRE
 summary: "{{ alert.name }} - {{ alert.service }}"
 - name: notify
 provider: slack
 action: send_message
 with:
 channel: "#incidents"
 message: "🚨 {{ alert.name }} on {{ alert.service }}"
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.

整合体系

Keep 的整合广度令人印象深刻：
– AI 后端：Anthropic、Open AI、Deep Seek、Ollama、Llama CPP、Grok、Gemini
– 可观测性：38+ 利器
– 资料库：Big Query、Click House、Mongo DB、My SQL、Postgre SQL、Snowflake
– 通信：Slack、Teams、Discord、Telegram、Pager Duty、Ops Genie
– 工单体系：Jira、Git Hub、Git Lab、Service Now、Linear、Asana、Trello
– 镜像调度：Kubernetes、Argo CD、Open Shift、AKS、GKE
– 资料管道：Python、Bash、SSH、Webhook、Kafka、SQS、Airflow

适用情形

• 预警出处分散、须要归一收口的团队
• 想要用声明式事务流替代 ad-hoc 脚本
• 须要在多云/混合云环境中维持预警管控的一致性
• 重视预警去重和降噪，压缩 On Call 疲劳

Versus Incident：会自钻研的 AI SRE

工程锚定

Versus Incident 的中枢卖点是自研习****—— 它不须要你手动设定预警规范，反倒自己钻研体系的正常行为方式，只在浮现切实异常时才通知你。这化解了一个运营维护小组的经典难点：预警规范要么太灵敏（天天告警风暴），要么太迟钝（该告的时候没告）。老牌策略是靠人反复调阈值，而 Versus 使 AI 来做这件事。

中枢本领

• 三时期渐进式发布：

****1）training 模式：静默观察，学习日志模式，不产生告警 2）shadow 模式：学习并记录 “如果上线会触发什么告警”，但不真正发送
3）detect 方式：正式发布，对未见过的异常模式带来预警

• AI 预警摘要：每个告警附带 AI 产出的摘要、严重度评级和建议的下一步
• 方式目录：可视化所有已学习的记录模式，具备人力审查和修正
• 敏感资料脱敏：自助识别并掩码密码、Token、邮箱等
• Regex 预过滤：控制哪些记录行进入聚类管道，压缩噪音
• 管控仪表盘：浏览器中查看已钻研的模式和过往事件

整合体系

• 预警出处：Alertmanager（Prometheus）、Grafana Alerts、Sentry、Cloud Watch SNS、Fluent Bit
• On-Call 底座：Pager Duty、AWS Incident Manager、Opsgenie、incident.io、Service Now
• 通知渠道：Slack、MS Teams、Telegram、Viber、Email、Lark
• 消息队列：AWS SNS、AWS SQS、GCP Pub/Sub、Azure Event Bus

上线方法

镜像化上线（P0），依赖 Redis 做状态持久化 —— 特别是 Agent 的光标位置追踪（保证重启后不重复处置）和 On Call 队列管控，提供 Kubernetes Manifest 和 Helm Chart。

适用情形

• 厌倦了手动保养告警规范的小组
• 希望用 “调参 → 影子 →检 测” 渐进方式搭建对 AI 预警的信任
• 中小小组，想要一个轻量不过智慧的异常检测方案
• 已有 Prometheus/Grafana 预警不过苦于告警风暴

Ongrid：全能型底座基建 AI Agent

工程锚定

Ongrid 可能是五个底座中功能最全盘的 —— 它不只是一个 AI SRE Agent，更像是一个完整的运维平台，自带可观测性栈、网管控、Kubernetes 生命周期管理、甚至浏览器 SSH。它的口号是 “理解你的基础基建，找到根源，复原它 —— 就在 Slack 或 Telegram 里”。

中枢本领

• 协调器+专家 Agent 结构：总编排 Agent 将作业分发给 SRE、网、数据库等领域专家 Agent
• 预警推动自动调查：告警触发时，Investigator Agent 自动启动 RCA Worker，将调查成效写回聊天窗口
• ：反向隧道访问任意主机，无需 SSH Key 或跳板机，全程审计
• 零入站端口：Edge Agent 只出站拨号，主机上不开任何端口（22/80/443 全关）
• Kubernetes 生命周期管控：机群注册、工作负载巡检、升级管理、K 8s 资源镜像到拓扑图
• 网络设备管控：从 Edge 主机发现邻居、SNMP 校验、API轮询、主机-设备链路映射
• 内置可观测性栈：预装 Prometheus、Loki、Tempo、Grafana，Agent 自己写查询
• 多范式具备：Anthropic、Open AI、GLM（智谱）、Deep Seek、Gemini、Kimi，支持热切换
• 工作流搭建器：将触发器、Agent、利器、条件、通知串联成可重复的自助化流程
• 知识库：索引 Runbook、笔记、历史事件、代码库，人和 Agent 共享运营维护上下文文
• 核准与写入门：高风险运维需显式审批后才能落实

根因拆解机理

Ongrid 的 RCA 方法很独特：它通过遍历拓扑图来推理左右边界，关联指标（m）、记录（l）、Trace（t），最终锚定到细化的源代码行。这种 “拓扑爆炸半径分析+证据推动调查” 的组合，比单纯的记录搜索更有结构性。

上线方法

一行命令部署，具备 Ubuntu 22.04+、Debian 12+、RHEL/Rocky 9，自托管。架构是 Edge/Server 方式：Edge Agent 上线在各主机上，出站连通到中央 Server。中国大陆有 CDN 镜像。

适用情形

• 想要一个 “全家桶” 式运营维护 AI 底座的团队
• 多环境（物理机+K 8s+网设备）混合底座基建
• 重视稳妥（零入站端口、核准门控、全程审计）
• 希望通过 Slack/Telegram 做完大一块运营维护运维

Flawless (CISRE)：Kubernetes 的 AI SRE 回路引擎

工程锚定

Flawless 的中枢观念是 CISRE（Cloud Infrastructure Site Reliability Engine）—— 将 “隐患发现 → 证据收集 → 根源诊断 → 人力审批 → 受控变更 → 复原验证” 串成一个可审计的回路。它最鲜明的特征是对稳妥边界的极度执着：
– 范式、浏览器、外部组件都不被允许直接落实任意命令；
– 所有变更运维须要逐项人力核准；
– 恢复确认务必来自真实目的的新证据，而并非 API 返回成功或范式声称成功。

中枢本领

• SRE Run：证据收集 → 诊断 → 审批 → 落实 → 复原校验的完整回路
• AI 巡检：定时或手动触发隐患发现，让用与 SRE Run 一致的运营维护内核
• 拓扑左右拆解：可视化资源依赖、吞吐模式和爆炸半径
• 技能库：每个 Skill 含有触发条件、渐进式证据收集、动作、回滚链路和成功标准
• Agent Trace：可视化完整的调查链路 —— 上下文文摘要、范式决策、Skill 触发、插件调用、工具采用、核准记录、改动和校验 Span

Kubernetes 回路具备

Flawless 对 Kubernetes 有完整的回路本领：
– 借助 Rancher、上传 kubeconfig、或机群内 Service Account 接入
– 所有改动运维让用逐项人力审批
– MCP Server 为 Kubernetes 运维带来类型化工具和落实界限
– 组件化结构：新领域能力以插件形式交付，不修改中枢调度

稳妥范式

Flawless 的稳妥构建值得关注：复制

CODE
禁止项：
- 外部插件不能直接获取 kubernetes:mutate、ops:execute、secrets:read 权限
- 不能注入任意 Bash、SQL 或 HTTP 变更
- 模型和浏览器不能直接执行任意命令
恢复确认：
- 不是 API 返回成功就算恢复
- 不是模型声称成功就算恢复
- 只有当真实目标的新证据满足恢复契约时，才算恢复
1.
2.
3.
4.
5.
6.
7.
8.
9.

适用情形

• Kubernetes 为主的云原生底座基建
• 对稳妥合规要求极高（金融、医疗、政务）
• 需要改动可审计、可回滚的运营维护小组
• 希望 AI 参与运营维护不过又不放心 “全自动” 的公司

中枢角度对比

结构与构建哲学

本领方阵

整合与体系

选型建议

按小组体量

按中枢难点

按手段栈

总结

这五个底座代表了 AI SRE Agent 的五种演进路径：
1. Open SRE：走 “基准化训练与评估” 路线，试图搭建 SRE 领域的 SWE-bench，适配有探究本领和定制化诉求的大团队。
2. Keep：走 “告警编排中枢” 路线，不做深度根源拆解，但保证告警被对路处置和流转，适合告警管控是首要难点的小组。
3. Versus Incident：走 “自研习异常检测” 路线，让 AI 替代人力保养预警规范，适配想迅速上线 AI 告警的中小小组。
4. Ongrid：走 “全能运营维护底座” 路线，从预警到 SSH 到网络管理一站式解决，适配底座基建复杂且希望压缩利器切换的小组。
5. Flawless (CISRE)：走 “稳妥回路” 路线，每一步都要审计、核准、校验，适合对合规要求极高的行业。

没有 “最好” 的平台，只有最适合你团队当前阶段和痛点的选择。如果你的团队正在评估 AI SRE Agent，建议从最痛的那个点切入，而不是追求 “大而全”。：AI SRE Agent 在 2026 年进入了真正的 “实用期”。去年，我们还在讨论 “AI 能不能做运维”，今年的问题已经变成 “哪个 AI 运维平台最适合我的团队”。这个领域的进化速度，比大多数人预想的要快得多。