Radar 实测：给编码智能体补上集群上下文，再考虑买 AI SRE

如果你正在评估 AI SRE 产品，你可能已经拥有其中大部分了。你的工程师使用的编码代理，无论是 Claude Code、Codex 还是 Cursor，都已经能够调查 Kubernetes 集群。它通常缺少的是上下文：当前什么在失败，以及失败之前发生了什么变化。

我们衡量了这个差距有多重要。同一个代理和模型两次处理 50 个故障集群，一次使用 shell 和原始 kubectl，一次使用返回该上下文的只读工具。有了上下文，它得出答案的速度大约快了三倍，而且准确率略高。

所以在你购买 AI SRE 之前，先给你已有的代理提供这些上下文，并进行衡量。

你实际购买的是什么

AI SRE 是作为一体销售的多个产品：

如果你的团队为编码代理付费，它已经有一个推理循环。上下文是本文要讨论的那一行。在我们的运行中，上下文组使用了 Radar 的只读 MCP 工具，这些工具在 kubectl 返回的内容之上增加了四样东西：

• 当前故障，已经检测到。 当前损坏内容的排名列表，因此第一次调用就从失败的内容开始，而不是从完整清单开始。
• 变更时间线。 规范变更和 Helm 发布历史，在 Kubernetes 事件过期后仍保留。事件默认持续一小时，而且许多变更根本不会产生事件（更多关于原因）。
• 资源与其关系关联。 所有者、拓扑和相关问题随对象一起返回，因此代理不必逐个获取它们。
• 日志过滤到错误。 诊断行优先，密钥已脱敏。

我们构建了 Radar，所以请带着这一点阅读其余内容。它的调查不附带代理：它们针对这些工具运行你已有的 CLI（Claude Code、Codex、Cursor CLI 或 OpenCode）。下面的数字测试了这种设置。

证据：相同的代理、相同的模型、50 个故障

我们在一个实时的 3 节点 Amazon EKS 集群上运行了来自 SREGym 的 50 个故障，SREGym 是微软和 UIUC 的开放 Kubernetes 故障基准。两组都通过 Amazon Bedrock 在 Claude Sonnet 5 上使用 Claude Code。一组有 shell 和原始 kubectl。另一组有 Radar 的只读 MCP 工具，并阻止了 kubectl，因此它无法回退到 shell。SREGym 的评判者，温度为 0 的 Claude Opus 5，对每次运行提交的第一个诊断进行评分。

有了上下文，代理的准确率略高：46 个正确对 45 个，平均评判分数为 0.936 对 0.905。两组在相同的 44 个故障上都正确。

更大的差异在于时间，而这在故障活跃期间至关重要：当用户不断遇到错误时，没人愿意等上十五分钟让 AI 去调查。有了上下文，智能体在 86% 的故障上能在两分钟内给出正确诊断，而仅靠 shell 时只有 60%。使用 shell 时，每十个故障中就有一个耗时超过十分钟。差距最大的是那 14 个所有 Pod 都报告 Ready 但应用已损坏的故障：使用 shell 平均需要 326 秒，而有上下文时只需 79 秒。

我们还将此设置与 AI SRE 产品进行了对比测试。一天前，在同样的 50 个故障上进行的单独运行中，Claude Code 在 Radar 的只读工具上比我们测试的五款 AI SRE 工具都更准确、更快速、更便宜，每个故障的模型 token 成本为 0.27 美元（结果）。

上下文并没有解决模型的判断问题。两组都漏掉了同样的三个故障。其中一个故障中，一个变更 webhook 在准入时重写了 Pod 的内存限制。另一个故障中，一个被错误地设为全局默认的 PriorityClass 改变了新建 Pod 的优先级并触发了抢占。在这两种情况下，两个智能体都没有指出负责的对象。在第三个故障中，两者都发现了一个真实但不相关的错误配置，并报告了它，而不是 DNS 故障。相同的模型，相同的错误。

两组在权限上也不同，因为只有 shell 可以写入，所以这次运行无法说明四种上下文中的哪一种起了作用。Nadav 的基准测试报告涵盖了其机制，两组的所有工具调用都在回放中。

智能体要求了什么

一个故障显示了差异。在 OpenTelemetry Astronomy Shop 中，frontend Deployment 丢失了它的 CART_ADDR 环境变量。所有 Pod 都报告 Ready，没有任何重启。两组都得到了正确答案：

Shell + kubectl: 58 tool calls, 701.6 s (excerpt)
  2.1s  kubectl get pods -n astronomy-shop -o wide
  2.2s  kubectl get events -n astronomy-shop --sort-by=.lastTimestamp
 10.3s  kubectl logs -n astronomy-shop product-catalog-77497fdc44-f5nx9 --previous
   ...
423.6s  kubectl run catsrc ...; kubectl cp astronomy-shop/email...
665.8s  helm get values astronomy-shop -n astronomy-shop
674.6s  kubectl get secret sh.helm.release.v1.astronomy-shop.v1 ... | base64 -d | base64 -d | gunzip
701.6s  submitted: "The frontend Deployment in astronomy-shop is missing the
        CART_ADDR environment variable..."
 
Read-only cluster context: 7 tool calls, 34.8 s
  1.0s  ToolSearch         (loads the MCP tool definitions)
  4.6s  issues             namespace=astronomy-shop
  4.9s  get_changes        namespace=astronomy-shop
 11.8s  get_resource       deployment/frontend
 12.3s  get_workload_logs  frontend
 19.8s  get_workload_logs  frontend
 20.4s  diagnose           deployment/product-catalog
 34.8s  submitted: "The frontend Deployment in astronomy-shop is missing its
        CART_ADDR environment variable, which was removed from the container spec..."

使用 shell 时，智能体花了近十二分钟处理它，最后通过解码 Helm 的 release Secret 来手动对比已部署的清单。而如果集群的最近变更只需一次调用就能获取，它本可以在 35 秒内得到答案。

在所有 50 个故障中，记录显示同样的情况。没有上下文时，智能体对每个故障都以 kubectl get pods 和 kubectl get events 开始。在其中 24 个故障上，它随后去寻找历史记录，在 ReplicaSets、发布历史或 Helm release values 中查找，因为它能读取的任何东西都没有告诉它发生了什么变化。

它还会即兴发挥，这就是表格中治理那一行的意义所在。它在 13 个故障上启动了自己的 Pod，并在 21 个故障上运行了 exec、cp、port-forward 或 debug。在 4 个故障上，它将 Secret 数据拉入其上下文，并在其中 3 个上解码了它（为什么即使只读访问也很重要）。在 Social Network 应用的一个故障上，它启动了一个 Pod，在该应用的两个 MongoDB 集合上运行 drop() 来测试一个假设，然后提交了错误的诊断。SREGym 的提示允许所有这些：它告诉智能体接下来是修复阶段，说它的 kubectl 可以“检查和修改资源”，并告诉它不要请求确认。一个被授予写入权限并被要求修复问题的智能体，会在仍在调查时使用该权限，因此 AI SRE 以什么身份运行，以及它可以更改什么，与它能读取什么同样重要。

有了上下文，智能体几乎每次都会首先要求同样的两样东西。当前故障是它在所有 50 个故障上的第一次调用，变更时间线是它在 35 个故障上的第二次调用。这两样东西正是 shell 智能体必须从 get pods、get events 和发布历史中拼凑出来的。

如果你在评估 AI SRE，这意味着什么

从产品能读取什么开始。检查它是否：

• 在 Kubernetes 事件过期后仍保留变更历史
• 从已经出现故障的地方开始

在我们的运行中，没有这些上下文的 agent 把时间花在了重建上下文上。

然后检查它以什么身份运行。它应该：

• 以只读身份运行，没有 exec，也无法访问 Secrets
• 记录它发出的每一次调用，这样你就能看到它读取了什么

上下文也不局限于某一个 agent。一个 MCP server 可以把同样的只读上下文提供给编码 agent 或 SRE agent：HolmesGPT 是 CNCF Sandbox 项目，接受远程 MCP server 作为 toolset。这样你就可以分别测试上下文和 agent。

如果你那个拥有良好上下文的编码 agent 诊断得和你正在试用的 AI SRE 一样好，那就根据那张表的其他行来评判产品，从触发方式开始。编码 agent 要有人要求它才会去调查。AI SRE 可以在告警触发时启动，在你睡觉时运行，等你打开 Slack 时答案已经等在那里。这是真正的优势，也正是 Radar Cloud 在开源上下文之上增加的东西：它在告警触发时运行我们基准测试过的配置——Claude 搭配 Radar 的只读工具——并把根因连同背后的证据发布到 Slack。

自己测试一下

给每个参试者相同的模型和相同的只读身份。Kubernetes 内置的 view 角色不包含 Secrets，也不授予 exec。这会生成一个 kubeconfig，其中只包含一个绑定到该角色的 service account，这样任何参试者都无法回退到你的管理员凭据：

kubectl create serviceaccount ai-eval -n default
kubectl create clusterrolebinding ai-eval-view --clusterrole=view --serviceaccount=default:ai-eval
TOKEN=$(kubectl create token ai-eval -n default --duration=8h)
ADMIN_USER=$(kubectl config view --minify -o jsonpath='{.users[0].name}')
kubectl config view --minify --flatten > ai-eval.kubeconfig
export KUBECONFIG=$PWD/ai-eval.kubeconfig
kubectl config set-credentials ai-eval --token="$TOKEN"
kubectl config set-context --current --user=ai-eval
kubectl config delete-user "$ADMIN_USER"
kubectl auth can-i get secrets   # should print "no"

运行相同的故障。SREGym 有适用于 Claude Code、Codex、Copilot、Cursor、Gemini CLI 和 OpenCode 的 driver，其包含 17 个问题的 Lite 套件可在 8 vCPU 和 16 GB 内存的 kind 上运行（setup）：

uv run main.py --suite sregym-lite --agent claudecode --model claude-sonnet-5 \
  --judge-model <a model none of your contenders use> --stages diagnosis --n-attempts 3

对于 SREGym 没有对应 driver 的 AI SRE 产品，--use-external-harness --problem <id> 会注入故障并让集群保持故障状态，供你指向该产品。

在固定时限内评分，并重复运行。使用与你的响应目标相符的时限；我们报告两分钟和五分钟的结果。每个故障运行不止一次，因为单次运行中两三个故障的差距可能是噪声。

然后在 staging 上重放两三个你自己的事故，使用相同的身份。基准测试会把故障注入到刚部署的应用中，而你的事故不会长那样。

这没有展示什么

• 我们构建了 Radar，上下文这一组使用的是 Radar 的 MCP server。每个故障的数据是公开的，所以你可以核对我们对它的解读。
• 每一组对每个故障只运行了一次。
• SREGym 在部署应用几分钟后就注入每个故障。这有利于任何跟踪近期变更的东西，包括 Radar。
• 我们衡量的是诊断，不是修复。

从上下文开始

在你试用 AI SRE 之前，先让你已有的 agent 以只读方式访问集群当前的故障和近期变更，并在固定时限内衡量它。把它作为你试用任何东西的基线：先比较诊断，再比较产品在其周围增加的东西。

Radar 是开源的（Apache-2.0）。用 brew install skyhook-io/tap/radar 安装它，然后用上面的只读 kubeconfig 把你的 agent 指向 Radar 的只读 MCP 端点 /mcp-readonly。