Zed 与 Kubernetes MCP：把集群上下文留在缓冲区旁边

发生了什么

containers 组织的 Kubernetes MCP 直连 API Server，助手可通过结构化工具查询工作负载、事件、Helm 发布与日志，而不是把 shell 输出整块贴进对话。Zed 把 AI 动作放在缓冲区附近；在本机接入该 MCP（或与 Cursor 并存）时，你正盯着交付 chart 的仓库，就不必先复制几大屏 kubectl 输出再解释。

为什么重要

若模型只靠残缺日志猜测，排障很容易跑偏。面向 Kubernetes 的 MCP 返回类型化对象：可以指定 Namespace、对比 ReplicaSet 世代、在服务端 RBAC 配置下尾随日志。再叠上可观测性基线（错误率、延迟窗口、饱和度检查），Agent 在提议改配置之前就有「何谓健康」的参照。

对目录的意义

Zed 承担轻量编辑器锚点；Cursor 仍是许多团队已在跑的多文件 Agent。Kubernetes MCP 与 Sentry MCP 互补：前者回答「集群此刻在做什么」，后者回答「哪次发布带回了这条错误签名」。需要验证假设时，仍要回到系统化调试的节奏。

接下来观察什么

只读默认、拒绝访问的资源（例如 Secret）、以及专用 ServiceAccount，会随着安全团队审查生产集群里的 MCP 而成为标配。若 stdio 之外再普及 HTTP 传输，与集群身份绑定的工具调用审计导出会更受关注。