核心用法
cluster-agent-swarm 是一套面向 Kubernetes/OpenShift 的多智能体协同运维平台，通过 7 个专业智能体（Orchestrator、Cluster Ops、GitOps、Security、Observability、Artifacts、Developer Experience）实现平台运营的全覆盖。用户可通过 @提及 机制在智能体间派发任务，配合心跳调度（5-15 分钟间隔）实现异步协作。
关键操作流程：
1. 配置 KUBECONFIG 及可选的云凭证（AWS/Azure/GCP）
2. 执行 setup-session.sh 初始化会话上下文
3. 通过 Orchestrator（Jarvis）路由任务，或直接 @ 特定智能体
4. 生产环境变更需人工审批（声明式控制，非技术强制）
显著优点
- 角色专业化：每个智能体有明确 SOUL 定义，避免通用型 Agent 的能力模糊
- 多平台兼容：支持 OpenShift、EKS、AKS、GKE、ROSA、ARO 等主流发行版
- 模块化凭证：按需提供云凭证、GitHub Token、Vault Token，最小权限原则
- 完整审计链：
WORKING.md、LOGS.md、MEMORY.md持久化会话与操作记录 - GitOps 原生：深度集成 ArgoCD、Helm、Kustomize，支持金丝雀、蓝绿部署
潜在缺点与局限性
- 第三方代码执行风险：从 GitHub 动态拉取并执行 bash 脚本，需人工审计
- 声明式审批非技术强制："生产需人工批准"是流程约定，依赖外部审批门控
- 持久化状态扩大 blast radius：自动提交变更到跟踪文件，若仓库权限过宽风险增加
- 脚本破坏性操作：
*-cleanup.sh、*-delete.sh、*-promote.sh可能误删资源 - 供应链工具下载：运行时可能拉取 syft、cosign、trivy 等二进制，需可信源
适合人群
- 运行中等规模 K8s 平台（50+ 节点）的 SRE/平台团队
- 已采用 GitOps 工作流、需要多集群统一运维的企业
- 具备脚本审计能力、能建立外部审批门控的成熟团队
常规风险
| 风险类型 | 说明 |
|---------|------|
| 供应链攻击 | GitHub 仓库被篡改后，通过 `npx skills add` 分发恶意脚本 |
| 凭证泄露 | 云凭证配置不当导致集群/云账户被接管 |
| 误操作 | 未在沙箱验证即运行 cleanup/delete 脚本，导致生产数据丢失 |
| 权限蔓延 | 长期运行的智能体凭证未及时轮换 |
| 审批绕过 | 过度依赖智能体自声明的"人工审批"，未配置技术门控 |
缓解建议：固定版本标签（非 main 分支）、沙箱先行、独立审批门控、最小权限服务账号。