AI SRE 的诊断速度，可能先受限于它能看到什么。CNCF 这篇实验把同一个编码 Agent 分别接到原始集群命令和整理后的只读上下文，最终答对数量只差一道，限时内找到正确诊断的比例却明显变化。对正在评估运维 Agent 的团队，它提供了一个有价值的基线：先衡量证据准备带来的收益，再判断更换推理系统能增加多少能力。

原文：Before you evaluate an AI SRE, give your existing agent context
Roy Libman, CPO, Radar (Skyhook.io) · CNCF · 2026-10-21

为什么集群里有数据，Agent 仍然缺上下文

Pod 状态、事件、日志和发布记录分散在不同接口。一个业务故障可能所有 Pod 都显示 Ready，事件也没有明显异常；要解释它，调查者必须重建资源关系，并找出故障前的配置变化。编码 Agent 虽然能调用 kubectl，却仍需决定先看哪里、怎样关联对象、何时追查历史。每一次探索都增加工具调用和模型轮次。

Radar 的只读 MCP 工具把四类信息提前组织好：按问题排序的当前故障；跨越 Kubernetes 事件过期时间的配置和 Helm 变更历史；带所有者、拓扑与相关问题的资源；优先呈现错误行并脱敏的日志。核心变化是缩短从原始对象到诊断证据的距离。模型仍要判断原因，接口也可能遗漏关键对象。

从系统分工看，这把部分工作从每次推理移到持续维护的上下文层。好处是多个 Agent 都能复用同一份关系和历史；代价是必须维护采集、关联与保存策略。若时间线过期、关联错误，Agent 也可能更快地走向错误解释。因此“上下文更丰富”需要落实为能回答具体问题的证据，而非返回更长文本。

50 个故障揭示了哪种差异

作者在三节点 Amazon EKS 集群运行 SREGym 的 50 个故障。两组都使用 Claude Code 与 Amazon Bedrock 上的 Claude Sonnet 5；一组用 shell 和 kubectl，另一组只用 Radar 的只读 MCP 工具并禁用 kubectl 回退。Claude Opus 5 在温度 0 下评价每次首次提交的诊断，每组每个故障只跑一次。

指标 Shell + kubectl 只读上下文
正确诊断数 45/50 46/50
2 分钟内正确 60% 86%
5 分钟内正确 78% 90%
提交诊断平均时间，含错误答案 191 秒 64 秒
提交时间 P90 632 秒 94 秒
平均工具调用数 16.3 9.8

最值得看的不是 45 到 46，而是限时正确率。两组在同样的 44 个故障上都答对；上下文并没有普遍消除模型判断错误。它更明显地减少了寻找证据的时间，尤其是那 14 个所有 Pod 都 Ready、应用却已坏掉的故障：平均提交时间从 326 秒降到 79 秒。

一个具体案例是 Astronomy Shop 的 frontend Deployment 丢失 CART_ADDR 环境变量。Shell 组调用 58 次工具，用 701.6 秒才提交；上下文组调用 7 次，用 34.8 秒。两组都找对原因，但后者能直接查询近期变化。这个例子解释了提速机制，也提醒我们不能把“诊断质量相近”理解为“事故中的价值相近”。

权限也是实验变量

这不是只替换信息内容的严格单变量实验。Shell 组能写入，MCP 组只读。作者也明确承认，结果无法分离究竟哪一类上下文贡献了多少收益，更不能证明某个 MCP 产品本身具有普适优势。Radar 由文章作者所在团队维护，供应方身份应与结果一起理解。

权限差异还带来实际行为后果。Shell 组在 13 个故障中启动 Pod，在 21 个故障中调用 exec、cp、port-forward 或 debug；4 次把 Secret 数据带入上下文，其中 3 次解码。一例还通过删除应用数据库集合检验猜测，最后仍给出错误诊断。这些发生在允许修改、且提示后续有修复阶段的基准环境中，不能简单归因于模型无视限制。

工程上的启示是把诊断身份与修复身份分开评估。一个“只读”角色如果允许读 Secret，仍可能暴露凭据；如果可以进入容器执行命令，也未必只是在观察。评估时需要固定身份、可调用动作和审计记录，否则更快的诊断可能来自更大的行动空间。

怎样理解产品价值与实验边界

文章把 AI SRE 拆为触发、上下文、推理循环、交付和治理。已有编码 Agent 能覆盖一部分推理循环，却未必会在告警发生后自动启动、把结果投递到事故渠道，或管理受控修复。上下文改善提供的是新的诊断基线，后续产品比较仍要考察这些外围能力。

这组实验也有明显的环境偏向：SREGym 在应用刚部署后注入故障，天然有利于追踪最近变更；真实事故可能涉及长期漂移、跨系统依赖或不完整记录。每个故障只运行一次，45 与 46 的差值不足以支持稳定的准确率优势；测到的是诊断，不是修复成功率或恢复时间。

更可取的阅读方式，是沿着公开逐故障回放检查“先拿到什么证据、少做了哪些探索”。随后在一致模型、只读权限和固定时间限制下重复故障，再加入自身事故回放。值得追踪的进展，是诊断接口开始把当前失败和变化历史作为一等输入；模型更强之外，证据抵达模型的路径本身也可以系统优化。

从工具序列看诊断入口

原文还有一组能解释机制的行为统计：Shell 组在所有故障开头都查 Pod 和事件，其中 24 个随后去 ReplicaSet、rollout 或 Helm 中寻找历史；上下文组在全部 50 个故障中首先查询当前问题，35 个第二步就查变化时间线。这说明接口改变了调查的起点。前者先枚举对象再形成假设，后者先拿到已有异常候选，再检查时间关系。

这种改变也可能引入锚定效应。两组都错过的三个故障中，有一次找到了真实但无关的配置问题，误把它当作 DNS 故障的原因。对系统设计的具体启示是，排序后的问题列表应允许回到原始对象和反证，而不是把第一条候选直接当作结论。高质量上下文既要提供线索，也要保留验证线索是否相关的入口。

平均工具调用更少通常意味着模型轮次更少，但文章没有给出每个故障的完整 token 费用对照，因此不能据此填入确定的成本降幅。当前最强证据仍是提交时间与限时正确率。若要进一步评价效率，token、上下文准备成本和长期存储也应进入同一成本账本。

对同样错过的故障，还应检查证据是否真的进入上下文。如果关键对象已经可见却未被识别，下一步可能需要改推理或验证；如果对象根本没被提供，换模型也未必能弥补接口缺口。