人工智能代理不会取代 Kubernetes：如何安全划分控制职责？

不应将人工智能代理和 Kubernetes Operator 视为控制回路中两个相互等价的替代方案。Operator 的设计目标是监控实际状态，将其与期望状态进行比较，然后以可重复的方式执行既定规则，使系统逐步接近声明的结果。而当结果已知、但实现路径需要调查、信息收集和权衡取舍时，代理更有价值。

由 Cloud Native Computing Foundation (CNCF) 赞助的本文指出，将代理引入云原生架构后，确定权限边界就成为设计问题，而不只是 convention。最安全的方式是让代理负责推理、上下文和建议，同时由 Operator、策略引擎和确定性系统保留执行权。

将推理与执行分开的运维回路

该模型提出了一个由六个阶段组成的实际流程：监控、诊断、建议、批准、协调，最后是验证。在最初几个阶段，代理可以检查资源、日志、事件、指标和文档，但不会自动获得应用变更或修改、删除资源的权限。非敏感的读取操作可以自动执行，而有影响的变更则需经过明确批准或策略网关。

kagent 项目是一个例子。它是 CNCF Sandbox 下的开源项目，可将代理作为 Kubernetes 资源运行，并将其连接到 Kubernetes、Helm、监控工具和定制工具，从而能够调查问题或协调专业化代理，同时不消除分析与执行之间的隔离。

为什么不应使用语言模型取代 Operator？

Karpenter 的案例清楚地说明了二者的差异。Karpenter 是一个处理调度约束并协调 NodePools 与 NodeClaims 资源的 Operator。如果出现未充分利用的节点、Spot 资源波动或等待调度的工作负载，运维代理可以检查 NodePool 和 EC2NodeClass 配置、事件和日志、Pod Disruption Budgets 以及 Prometheus 指标，以寻找原因。

调查可能发现，禁用驱逐的策略阻止了合并，或者中断预算妨碍了驱逐，或者 consolidateAfter 的值导致可避免的波动，出现在变化中的负载上。但所需结果不是“优化 NodePool”之类的笼统建议，而是一个具体的配置补丁，其中说明证据和权衡、可能受影响的节点数量，以及稳定性监控时长。

获得批准后，Karpenter 会依据自身现有的调度和中断逻辑执行变更。随后，代理监控结果，验证合并是否得到改善，同时不会增加工作负载的等待时间或造成有害中断。如果未达到验收标准，则可以通过同一路径提出回滚建议。

另一个例子：Argo CD 与 Helm 升级

在由 Argo CD 管理的 Helm Chart 升级中，在 Git 中修改版本相对容易，但评估其对正在运行的应用的影响则更困难。代理可以比较发行说明、当前值和生成的数据，例如发现用于设置 readiness probe 的值采用了新名称，可能导致系统悄然回退到默认值。

应将这一结果转化为一个聚焦的合并请求，更新版本和受影响的值，说明运行风险，并明确部署前检查。审查并合并后，Argo CD 会依据应用策略生成数据并进行同步。仅凭同步成功不足以证明升级安全；还必须检查延迟指标、错误率和可用性。如果检查失败，代理可以提出反向变更或恢复计划，但需考虑到数据或架构变更可能无法完全回滚。

自主性是逐步获得的

本文建议首先使用仅具备读取和调查能力的代理，然后允许其创建补丁或合并请求，之后再执行低风险且范围明确的变更，并为这些变更设定清晰的回滚条件。只有当操作可理解且可衡量时，才应实现自主执行。

编辑部解读：这里真正的变化并不是增加一个能够调用 kubectl 或 Helm 的代理，而是重新设计控制回路，避免将概率性推理转化为不受限制的执行权限。该模型的实际价值取决于可审计的授权、有限的范围、监控能力以及逆转影响的可能性。确定从建议走向自主执行的速度，仍然是人的责任；此外，本文并未证明这种方法能够消除错误风险，或使所有情况下的回滚都成为可能。