核心事件：基础设施范式正在重构

在 2026 年 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 大会上，CNCF 与 OpenInfra 基金会高层共同确认：AI Agent 正对云基础设施的传统设计前提构成根本性挑战。

过去十年，基础设施由人主导操作——管理员提交 YAML、工程师发布部署、平台团队设定策略；即使存在自动扩缩容，其逻辑也完全预设。而现在，Agent 作为新类型的基础设施调用者，开始自主决定何时申请资源、调用工具、调整实例与改变状态——它已不仅是“被调度的工作负载”，而逐步成为基础设施的主动“用户”。

关键变化包括：

• Kubernetes 引入 DRA（Dynamic Resource Allocation）机制，允许 GPU 等加速器通过插件方式灵活接入，而非将所有硬件能力写死于核心代码
• CNCF 推出 Kubernetes AI Conformance，将兼容性标准从传统云原生延伸至 AI 基础设施
• OpenInfra（原 OpenStack 基金会）明确自身定位：负责底层硬件暴露与安全控制，而非替代 Kubernetes 的编排职责

Agent 为何撼动传统基础设施？

Infrastructure-as-Code 与自动化工具 decade 以来并未改变交互模型本质：所有操作链仍围绕人类意图展开。而 AI Agent 带来的核心反差在于：其资源调用行为具有高度动态性与上下文依赖性——一个 Agent 可能根据任务实时决定所需硬件类型、内存容量甚至网络拓扑，事后依据执行结果自动进入下一阶段调用链。

这种变化在三个层面带来影响：

1. 资源语义复杂化：计算资源不再仅是 CPU/内存。GPU、NPU、专用加速器构成异构资源池，同一 GPU 可切分，不同负荷（训练/预填充/解码）对资源需求迥异。传统 Kubernetes 调度在 CPU/内存场景已高度成熟，但在异构资源调度上面临能力缺口

2. 控制链分层重构：生产环境典型部署链为“Linux → OpenStack（裸金属管理）→ Kubernetes（容器编排）→ PyTorch/vLLM（推理）”。当 Agent 跨层调用资源时，Kubernetes 需要知道如何编排，但更底层必须有人（或组件）安全暴露硬件；若涉及 PCIe 直通、特殊网络配置等，则需 OpenInfra 生态协同。

3. 安全模型升级：传统隔离关注容器之间、容器与宿主机之间边界；Agent 场景下需新增“可审计性”（Auditability）与“可逆性”（Reversibility）要求——不仅要记录 Pod 是否启动，更需回答：为何申请？调用了什么？修改了哪些状态？操作是否可撤销？

技术应对：两边生态的协同演进

CNCF 与 OpenInfra 并非单点突破，而是基于各自定位展开协同响应：

DRA 是 Kubernetes 适应 AI 异构化的关键设计：它允许 GPU 厂商独立开发适配插件，将芯片能力（如 GPU 切分策略、任务亲和性）暴露给 Kubernetes，而无须修改核心代码。CNCF 执行总监 Jonathan Bryce 强调，目标是实现“任何芯片、任何云、任何 Agent”的兼容生态。

在安全侧，Kata Containers 被 OpenInfra 总经理 Thierry Carrez 视为 AI 安全核心项目。它提供超轻量虚拟机级别的工作负载隔离，不仅隔离不同工作负载，还能隔离工作负载与宿主机，适用于对数据访问与合规要求严格的场景。但 Thierry 也明确表示，这仍不足够——未来需要补充可审计性与可逆性能力。

读者建议：基础设施升级路径选择

• 适合当前采用者：已部署 GPU 训练/推理集群、接入多Vendor 加速器的团队，可评估 DRA 在现有 Kubernetes 集群中的可行性；需构建 Agent 操作可审计性日志基线
• 建议继续观望者：计划将 Agent 作为生产核心负载的企业，可等待 Kubernetes AI Conformance 通过较多厂商认证后再推进——当前相关标准仍在早期

写在最后

AI Agent 正迫使云原生从“抽象硬件”转向“理解硬件”：过去十年，云计算努力隐藏底层差异；现在，模型性能与成本要求系统必须穿透抽象层，根据硬件特性做细粒度选择。这场范式转移不是替换某个组件，而是重构整个控制面的语义与责任边界。