目前，大多数平台团队 (Platform Teams) 都在讨论一个核心问题：是否应该允许基于人工智能的编程代理 (AI Coding Agents) 提交拉取请求 (Pull Requests) 来修改基础设施？真正的答案不在于代理的可信度，而在于平台本身吸收错误且具有破坏性的变更并在其扩散之前进行拦截的能力。
著名的 Replit 事件体现了这种风险：一个 AI 代理由于失误删除了生产数据库并创建了数千个虚假账户。这凸显了自动化并不能区分好坏变更，它只会加速结果的产生，无论结果是正确的还是灾难性的。
GitOps 时代的自动化风险
大多数现代云平台都依赖 GitOps 方法论，其中 Git 仓库代表了基础设施的期望状态。尽管 GitOps 在审计和一致性方面具有优势，但自动化在这里充当了“错误放大器”；一个错误可能会在几秒钟内扩散到整个基础设施。随着 AI 代理的引入，变更请求的频率呈爆炸式增长，而人工审查的能力仍然有限，这使得人工审查成为了技术生产线上的“最稀缺资源”。
构建云弹性的五个层级
为了确保平台的安全性，必须构建多层保护机制，这种机制不依赖于执行变更者的身份，而是依赖于系统本身的稳健性：
- 第一层：早期测试：使用测试驱动开发 (TDD) 和金丝雀 (Canary) 环境，在变更到达用户之前，在完整环境中观察其行为。
- 第二层：抽象与配置 (Abstraction)：通过提供简化的接口而非原始的 YAML 文件来减少错误空间。可以使用 kro (Kube Resource Orchestrator) 将复杂的资源组转换为简单的 API，或使用 Score 项目来简化开发人员的需求。这使得变更具有确定性 (Deterministic)，并防止 AI 在未知字段中“即兴发挥”。
- 第三层：Kubernetes 原生保护：启用访问控制策略 (RBAC)，使用 Kyverno 作为“控制塔”来拦截任何不符合平台标准的请求，此外还包括 Pod 破坏预算 (Pod Disruption Budgets)。
- 第四层：云供应商保护：在核心资源级别启用“删除保护” (Deletion Protection) 功能，以防止意外删除。
- 第五层：人工审查：通过 CODEOWNERS 等机制保留专家的角色，以确保任何变更都不会绕过人工审查。
“单一标志”概念与零信任模型
本文建议通过“单一标志” (One Flag) 来简化流程，而不是让每一层保护都成为一个独立的决策。当在资源定义中将某个字段设置为 protected: true 时，平台会自动在云端启用删除保护、禁止更改地理区域，并激活严格的 Kyverno 策略。这种方法将 零信任 (Zero Trust) 原则应用于基础设施自动化；即不假设代理或人类是可信的，而是设计系统使得在没有易于在审查期间检测到的明确且清晰的授权请求的情况下，无法进行破坏性的变更。
实际发生了什么变化？
这一趋势将安全负担从“监控用户”转向了“加固平台”。对于平台工程师而言，这意味着停止试图限制 AI 的能力，转而开始构建使错误在技术上不可能发生，或者至少影响范围有限 (Bounded Blast Radius) 的系统。目标是达到这样一个阶段：团队之所以采用该平台，是因为它是最快且最安全的路径，而不是因为它强加了阻碍工作的限制。