技能介绍

要解决的问题

Kubernetes 平台运维的痛点不在于缺少命令，而在于职责分散。集群生命周期、GitOps 发布、RBAC 与策略、监控告警、镜像供应链、开发者支持，通常散落在多个控制台和不同团队手里。当一次 P1 事故同时牵涉节点状态、ArgoCD 同步和 RBAC 变更时，协调成本往往超过排查成本。给 AI Agent 开放集群权限时，问题更尖锐：它需要清楚「该做什么、不该做什么、卡住了找谁」。

技能如何工作

Kubernetes Agent Swarm 是一套多智能体协作方案，七个专职 Agent 分工明确：Jarvis（任务路由与协调）、Atlas（集群生命周期与升级）、Flow（ArgoCD/Helm/Kustomize 发布）、Shield（RBAC、策略与密钥扫描）、Pulse（指标、日志与告警）、Cache（镜像仓库、SBOM 与 CVE）、Desk（命名空间与开发者支持）。

关键设计：

纯指令驱动：技能不含可执行脚本，Agent 依据 Markdown 指令调用主机上已装好的 CLI（如 kubectl get、kubectl describe）完成任务。
分级升级路径：Agent 先在护栏内尝试自愈，受阻则通过 @mention 呼叫其他 Agent 或升级给人类；P1 事故自动通知全部相关 Agent。
上下文落盘：约定以文件而非记忆承载跨会话状态，每次操作都留有审计记录。

适用边界

硬性要求：kubectl 在 PATH 中，且通过 KUBECONFIG 或 ~/.kube/config 提供集群凭证；oc、helm、jq 仅在对应场景下需要。
高风险操作强制人工审批：删除生产资源、修改集群级策略、绕过轮换流程直接改密钥、执行不可逆升级、批准生产发布（Agent 只能准备，批准权在人）。
这是编排层而非自治系统，Agent 的能力上限取决于主机安装的 CLI 与 RBAC 实际授予的权限。