AI代理和Kubernetes控制器，到底谁该管执行？

过去18个月，代理工具从边缘项目挤进了云原生栈。CNCF已经把代理框架收进沙箱，Kubernetes SIG Apps也接下了Agent Sandbox这个子项目，专门用来安全运行代理工作负载。平台团队开始面对一个具体问题：一个代理，到底能在活着的集群里改什么？

默认情况下，这条边界靠约定划出来，不是靠设计。多数团队的做法是让代理一次只提一个拉取请求，但并没有写成文的策略。

Kubernetes其实一直在用"代理"，只是不是今天AI讨论里的那种。控制器盯着当前状态，和声明的期望状态比对，然后动手把差距补上。这层相似性让AI代理和Kubernetes操作器听起来可以互换——但它们不是一回事。

一个求确定，一个处理不确定

Kubernetes操作器的设计目标是可预测。它按编码好的规则协调资源，失败就重试，最终收敛到声明状态。AI代理的价值在另一头：目标清楚，路径不清楚。它能调查陌生情况，从多个系统收集上下文，权衡取舍，提出一条行动路线。

更安全的架构模式是把两边的长处拼起来。代理负责推理和上下文，操作器、策略引擎这类确定性系统保留执行控制权。

kagent是一个具体例子。这个开源项目属于CNCF沙箱，把AI代理当作Kubernetes资源来跑，并把它接到Kubernetes、Helm、可观测性工具和自定义工具上。代理可以检查资源、拉日志和事件、查指标、翻文档，还能协调专门的子代理。

这不等于每个工具都能随便执行。非敏感的读操作可以自动跑，而应用、打补丁、删除资源这类变更，可以要求显式批准。这样代理能做大范围调查，又不会让一个不确定的推理过程拿到集群的无限权限。

整个操作回路变成：观察、诊断、提议、批准、协调、验证。前三步吃的是代理的推理能力，协调交给Kubernetes和操作器，验证负责收口——不能因为变更被接受了，就假定它产生了预期结果。

Karpenter的例子最能说明问题

设想一个集群，Karpenter把容量开出来了，但平台团队仍然看到节点利用率低、整合慢、Spot实例频繁抖动，或者有Pod一直挂起。Karpenter本身就是操作器，它评估调度约束，协调NodePool和NodeClaim。把这套逻辑换成大模型，只会让一个可靠的控制回路变得不可预测。

基于kagent的运维代理应该工作在Karpenter之上。它可以检查NodePool和EC2NodeClass配置、挂起的Pod、Kubernetes事件、Pod中断预算、Karpenter日志和相关Prometheus指标，然后追问：为什么观察到的行为和团队目标不一致？

调查可能发现，是Pod中断预算挡住了整合；是do-not-disrupt注解把某个节点钉在原地；是consolidateAfter对突发型工作负载太激进，制造了本可避免的抖动；也可能是实例约束让Karpenter在挑Spot容量时余地太小。

代理的输出不该是"优化一下NodePool"这种模糊建议。它应该摆出证据，指出取舍，产出一个范围很窄的配置补丁。改中断预算，要说明最多影响多少个节点；改整合策略，要说明团队会观察多久的工作负载稳定性；扩大实例选择，要保住架构、可用区和负载约束。

补丁随后过批准或策略闸门。批准之后，Karpenter用它原有的调度和中断逻辑去协调。代理在约定周期内盯结果，检查整合是否改善，同时没有推高挂起Pod的延迟或造成有害中断。达不到验收标准，系统可以沿同一条受控路径建议或发起回滚。

升级场景：Argo CD执行，代理举证

再看平台团队升级一个由Argo CD管理的Helm chart。在Git里改版本号很简单，搞清这个改动对运行中应用的影响要费劲得多。Argo CD能显示哪些资源有差异，代理能帮忙解释这些差异对工作负载意味着什么。

比如新版本重命名了团队用来配置就绪探针的某个值。代理可以比对发布说明、现有值和渲染后的清单，判断这次升级会不会悄悄退回默认值。它应该把发现变成一个聚焦的拉取请求：更新chart版本和受影响的值，解释运维风险，定义上线前必须做的检查。

拉取请求通过评审并合并后，Argo CD按应用配置的同步策略渲染并同步清单。代理接着检查Argo CD的同步和健康状态，同时看应用指标。同步成功本身，不能证明升级保住了延迟、错误率和可用性。

检查没过，代理可以走同一套批准流程提议Git回滚或恢复方案，并考虑回滚无法撤销的数据或schema变更。分工始终清楚：代理调查、提议、验证；Argo CD协调被批准的期望状态。

自主权是挣来的

这套模式可以渐进引入。先做只读调查员，再允许代理生成补丁或拉取请求，然后放行经过批准、范围明确、带回滚条件的低风险变更。只有结果可度量、行为被充分理解的动作，才应该走向自主。

关键边界不在于代理能不能调用kubectl、Helm或云API，而在于每个动作是否被授权、有边界、可观测、可回滚。Kubernetes可以运行帮助管理Kubernetes的代理，前提是每个组件都守住自己最擅长的那份活：代理推理不确定局面，操作器协调声明状态，策略给两者划上限，而人，仍然对系统从建议走到自主的速度负责。