用途：将单个已批准的 Kubernetes 集群以观察优先模式接入 CAST AI，在开启自动化前先建立可信的成本基线，并验证身份、遥测、归属与回滚能力。
主要能力与步骤：
- 确立归属：用 Read 和 Grep 查找现有 CAST AI、autoscaler、Terraform、Helm 与 GitOps 定义；若已有其他控制器负责节点供给或 HPA 行为且无共存决策，应停止。
- 预览连接：用 Bash(castctl:*) 校验客户端、交互式登录目标组织，并运行文档化的连接 dry-run，记录检测到的提供商、集群、区域、所选功能、命名空间与拟议云变更，但不实际连接。
- 审查权限与功能：确认最小权限云访问与确切集群上下文。Cost Monitoring 始终启用；仅当授权、指标、中断与归属前提满足时，才选择 Node Autoscaling 或 Workload Autoscaling。用 Write 或 Edit 将批准的选择写入仓库 runbook。
- 连接集群：在批准窗口内运行已审查的 castctl 连接，不要用已弃用脚本流程替代受支持的 castctl 环境。保留控制台 URL 与脱敏命令回执，切勿保留浏览器令牌或 API 密钥。
- 验证观察模式：用 Bash(kubectl:*) 验证命名空间工作负载、就绪状态、事件与指标前提，确认控制台收到目标集群与成本数据，同时自动化保持批准状态。需积累足够数据后再判断节省或建议。
- 单独交接自动化：记录基线时间、当前控制器、策略候选、受保护工作负载与回滚负责人；自动化启用应作为单独审查变更，使用 castai-core-workflow-b。
前提条件：具名 kube context（EKS、GKE、AKS 或受支持的 CAST AI Anywhere）；安装所需 cluster-admin 权限与经审查的最小权限云权限；评估 Workload Autoscaling 时需 metrics-server；明确负责人、维护窗口、回滚决策与证据存放位置。
限制与错误处理：castctl 检测到错误集群时，先停止并修正 kube context；现有 provisioner 归属不明时保持优化关闭并解决架构问题；Agent 未就绪时收集事件与日志，不要启用自动化；成本数据不完整时验证遥测并等待代表性窗口。切勿回显凭据或推断权限范围。