Agent 需要关系与变化，不只是 YAML
Radar 把 Kubernetes 资源关系、健康状态、去重事件、变更 diff 和过滤日志同时提供给界面与 MCP。问题是 agent 直接用 kubectl 调查时，往往先花大量调用拼装同一份上下文。Radar 通过 informer 观察集群，将已有关系与近期变化整理后交给 agent，让它从异常对象沿依赖查找，而非从原始清单反复重建。
例如 rollout 卡住，界面可以显示 Pod、控制器与事件，agent 读到同一组状态再查询日志。这个设计减少上下文搬运，但拓扑和健康判断仍来自可观察资源，不能替代不存在的应用遥测。已连接模型会接收它读取的数据；“本地工具”不表示远端模型也不接触数据。
只读入口的权限范围
/mcp-readonly 不包含写工具；完整 /mcp 另提供重启、扩缩容、apply 等操作，某些诊断还会创建临时探测 Pod。只读标志限制 Radar 的 MCP 工具，不自动封住 agent 的 shell 或其他 MCP。原文也明确 ordinary UI writes 不因 MCP 只读而全部关闭。
这种边界很重要：调查结论和执行修复不是同一权限。Secret 字段被隐藏、部分日志按已知模式清理，也不能保证所有敏感内容都被识别。适用时要读清楚调查 agent 的运行方式和 Kubernetes 凭证范围，而不是把工具名字中的“只读”理解为整个进程的隔离证明。
三倍诊断速度来自哪组实验
作者在三节点 EKS 上用 SREGym 注入故障。第一组 50 故障比较相同 agent、相同模型，只改变 Radar MCP 与原始 kubectl，平均提交诊断时间分别为 64 秒和 191 秒。时间包含对与错的回答，不能称为平均成功修复时间。另两组 MCP 和完整 SRE 产品比较使用不同故障、日期及集群负载，不应跨表排序。
我的理解是，这个实验支持研究“给 agent 什么结构化上下文”，而不是仅换更强模型。结果来自产品作者，评分使用统一 LLM judge；应用到真实事故还需考虑故障分布、历史长度和缺失观测。更快生成一个答案与更快恢复服务之间，仍隔着正确诊断和经授权的修复执行。
来源：原始工程文章