我干过最蠢的事，是坐在那儿看 Claude Code 排查一个 Kubernetes 问题。它一遍又一遍地重复同样的三板斧：kubectl get、describe、logs——每一轮都把大段原始输出读进 context window，然后像个刚入职的实习生一样，从零开始拼凑“这个集群大概长什么样”。
kubectl get pods
kubectl describe pod <出事的那个>
kubectl logs <出事的那个>
这个画面在我脑子里挥之不去。所以看到 Radar 发的 benchmark 时，我第一反应是：终于有人把这个现象量化了。
实验设计不花哨。同一个模型、同样的 prompt、同样的成功标准，在 52 个故意弄坏的 EKS 集群上排障。对照组一边只给裸 kubectl，另一边给 Radar 自家的 MCP server。结论：工具调用平均从 45.8 次降到 11.1 次，一轮平均耗时从 334 秒压到 169 秒。
快了一倍。
说实话，这个数字好到我想先喝口水缓一缓。毕竟跑实验的是 Radar 自己，被测的对象也是他们家的 MCP server——这层关系我清楚，所以第一反应是打个折。但看完整份方法说明，我倾向相信这个趋势是真的，因为原因讲得通。
作者把效率提升归因于 context，不是 protocol。我觉得这是全场最值钱的判断。
kubectl 驱动的 agent 每走一步都在“重建”集群结构——拿到的是散落的原始输出，得靠模型自己脑内拼图。Radar 那边的 resource graph 不一样，它把所有权链、服务路由这些结构当成现成上下文直接塞给模型。一次工具调用返回的是故障资源周边的完整街区地图，不是几张街景照片。
区别不是“快一点”，是量级上的。
这组数字拉开最狠的场景，也恰好是最能说明问题的场景：症状离根因很远的间接故障——出问题的组件根本不是坏掉的那个。这种故障在 kubectl 流里约等于黑暗里摸象；MCP 流一次调用就把故障资源的邻居关系、依赖链拉出来了，顺着图走，走着走着就到了真正的病灶。反过来，那种一眼 CrashLoopBackOff 的简单故障，两边处理得差不多。
工具的优势偏偏长在人类调试者也最容易抓瞎的地方。
这类 benchmark 我最烦的向来是“赢麻了”叙事，但这个报告里有两处反而让我信了一半：一处是承认精度提升并不大，pass rate 只从 77.6% 涨到 80.8%；另一处是明确写了只测了 Claude Sonnet 4.6，其他模型什么表现……不知道。
画外音：也可能是被卷怕了，先给自己摘干净。
不过别误会，我不打算因为这组数字就把 kubectl 扔了。它还是那个最通用、最不会背叛你的东西。只是——如果干活的是 agent，给它一张地图，比让它多跑十趟街景顶用。这句话我要刻在 CLAUDE.md 顶上。
本期缴税：让 agent 拿原始输出硬拼集群拓扑。别问为什么交，问就是懒。