Agent开始调用基础设施，Kubernetes准备好了吗？

过去十几年，云基础设施的一套基本假设相当稳定：人通过控制台、命令行或 API 发起操作，平台接收请求，再把计算、存储和网络资源分配下去。即便后来有了自动扩缩容、基础设施即代码和各种自动化运维工具，真正做决策的主体通常还是人，或者是人提前写好的固定逻辑。

AI Agent 正在打破这个前提。

在近日举行的 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 上，InfoQ 分别与 OpenInfra 基金会总经理 Thierry Carrez（阚雷）、CNCF 执行总监 &Linux 基金会云与基础设施执行总监 Jonathan Bryce（傅兰石） 进行了交流。两人的讨论都指向一个正在变得越来越具体的问题：AI 正在改变过去十多年云基础设施赖以成立的一些前提，而 Agent 带来的变化尤其明显。

Thierry 提到，他们现在关注的核心问题之一是“未来的基础设施需求”正在发生变化。过去十年的软件架构主要围绕人类操作设计，但现在，基础设施的使用者开始包含越来越多 AI Agent。Agent 未必需要经过传统的人机界面来调用资源，这意味着底层需要探索更直接的控制方式。

Jonathan 则从 Kubernetes 一侧给出了另一部分答案。他提到，面对越来越复杂的 AI 硬件，Kubernetes 已经开始通过 DRA（Dynamic Resource Allocation，动态资源分配）等插件机制，让 GPU 和其他加速器更灵活地接入 Kubernetes 集群；CNCF 也推出了 Kubernetes AI Conformance，希望把 AI 基础设施里的兼容问题从技术接口延伸到共同规则。

基础设施面对的问题，不只是“Agent 会消耗更多算力”这么简单。如果 Agent 只是又一种跑在 Kubernetes 上的应用，那么云原生基础设施面对的无非是更多 Pod、更高并发和更多 GPU；但如果 Agent 开始自己决定什么时候申请资源、调用什么工具、调整多少实例，甚至直接参与基础设施状态的改变，它就不再只是一个“被调度的工作负载”，而逐渐成为基础设施的调用者。

问题也随之变成：当调用基础设施的主体从人扩展到 Agent，过去为人设计的云原生控制面还能不能继续工作？

过去基础设施是给人用的，现在 Agent 也成了“用户”

今天企业里的基础设施操作，表面上已经高度自动化，但背后的交互模型仍然带有明显的人类设计痕迹。管理员配置权限，工程师提交部署文件，平台团队设定资源策略，应用按照事先定义好的方式运行。即使系统会自动扩缩容，它通常也只是对预先设定的指标作出响应。

Agent 的出现，让这种边界开始松动。

一个 Agent 可能根据任务临时决定需要什么资源，调用外部工具，再根据执行结果进入下一步。对于基础设施来说，调用链不再完全固定，操作主体也不再总是一个有明确身份的人类用户。

Thierry 把这种变化视为 OpenInfra 接下来需要解决的新问题之一。他认为，新型 AI 和 Agent 工作负载已经在对底层基础设施提出全新的要求，而硬件层与编排层之间，目前还缺少一个足够合适的开源项目来填补这块空白。相关创新正在发生，但很多仍处于封闭环境，他们希望这些能力最终能进入开放社区，在统一标准下协作。

过去十年，Kubernetes 已经成为事实上的容器编排基础设施。当应用需要更多计算资源时，Kubernetes 负责把工作负载放到合适的节点；节点不足，可以扩容；实例挂掉，可以重新拉起。

但 AI 时代的资源已经没那么标准。

CPU、内存之外，还有 GPU、NPU 和各种专用加速器；同一块 GPU 可以被切分，不同任务适合不同硬件，训练、预填充和解码也可能有完全不同的资源需求。Agent 如果进一步参与资源调用，调度系统面对的就不只是“把一个容器放在哪里”，而是如何在一个高度异构、动态变化的资源池里持续做选择。

也因此，Kubernetes 自己正在变化。

Kubernetes 正在从“编排容器”走向“编排 AI 资源”

Jonathan 在采访中提到了 Kubernetes 最近几年一个很重要的变化：DRA，Dynamic Resource Allocation，动态资源分配。

传统 Kubernetes 对 CPU、内存这一类资源的处理已经相对成熟，但 GPU 和其他加速器并没有这么简单。不同厂商的芯片能力不同，资源切分和使用方式也不同，很难靠 Kubernetes 核心代码把所有硬件逐一写死。

DRA 提供的是一种插件式机制。按照 Jonathan 的解释，GPU 厂商可以通过这套机制把自己的芯片能力接入 Kubernetes 集群，而不需要让 Kubernetes 本身针对每一种硬件做专门实现。

这背后的目标其实很明确。Jonathan 今年曾在中国与多家芯片和加速器厂商交流。他用这样一句话概括 Linux Foundation 体系下这些项目的方向：任何芯片、任何云、任何 Agent。要做到这一点，底层项目必须尽可能保持开放，通过插件和标准接口适配不同厂商，而不是被某一种硬件绑定。

除了技术接口，CNCF 也在补治理层。Jonathan 提到，Kubernetes 已经运行多年的 Conformance 合规体系，目前有上百家公司参与；去年又进一步推出了 Kubernetes AI Conformance，把类似的思路带到 AI 基础设施。一方面是技术兼容，另一方面是治理，希望让更多厂商能够在共同规则下接入。

这些变化都在回应同一个问题：AI 正把过去云时代尽量标准化的计算环境重新拉回异构化。

CPU 时代，云计算努力把底层差异隐藏起来。用户最好不需要知道机器在哪、是什么型号，只需要通过统一 API 获取资源。但到了 AI 时代，硬件差异本身已经直接影响模型性能和成本。什么任务跑在什么芯片上，能不能共享一块 GPU，数据在显存、内存还是高速存储之间如何流动，都开始成为系统设计的一部分。

所以 Kubernetes 今天面对的，不只是更多 AI 工作负载，而是越来越复杂的资源语义。Agent 再加入进来之后，这种复杂度还会继续增加：资源不再只由开发者提前声明，未来可能越来越多地由软件自己动态提出需求。

不过，在 OpenInfra 与 CNCF 的分工里，Kubernetes 本来也不是要解决所有底层问题。

Kubernetes 管不到最底下，硬件与编排之间还有一块空白

Thierry 对 OpenInfra 在 AI 技术栈里的位置有一个很清晰的划分。OpenInfra 更靠近底层，负责“提供并控制基础设施”：一方面把硬件能力暴露给上层，一方面控制和管理计算、网络、存储，确保这些资源能够被安全、可控地调用。再往上，才是 CNCF/Kubernetes 所在的云原生编排层，以及更上层的 AI 框架和工作负载。

现实生产环境也确实是这样叠起来的。

Jonathan 举了一条很典型的部署链作为例子：底层运行 Linux，用 OpenStack 管理服务器和硬件资源，再由 Kubernetes 做容器编排，最上面运行 PyTorch 训练或者 vLLM 推理。

这也是为什么这次 CNCF、OpenInfra 和 PyTorch 几个社区会同时出现在同一场大会里。用户本来就不会只运行其中一个项目，AI 系统一旦真正进入生产，底层算力、资源管理、容器编排、模型训练和推理天然就在一条链上。这种跨层协作也已经落到了具体项目上。例如，OpenStack 里的裸金属管理能力已经通过 CNCF 的 Metal3 与 Kubernetes 集成；CNCF 生态中的 LLMD 也在与 PyTorch 体系衔接。

Agent 带来的新问题，恰恰出现在这些技术层之间。

如果未来一个 Agent 要动态调用某块 GPU，Kubernetes 需要知道资源如何编排，但更底层还必须有人把这块硬件安全地暴露出来；如果它需要裸金属、PCIe 直通、特殊网络或存储能力，这些又不是 Kubernetes 单独能够解决的。

Thierry 所说的“硬件层和编排层之间还有空白”，指向的正是这里。

过去 OpenStack 和 Kubernetes 的边界大体清楚：一个更偏基础设施资源，一个更偏工作负载编排。但当 AI 系统开始要求更紧密地理解底层硬件，而 Agent 又可能动态改变资源需求之后，这些层之间需要交换的信息越来越多。

这并不是某一个项目要吞掉另一个项目，而是过去相对清晰的层次边界正在被重新连接。

云计算时代的主线是抽象：尽可能把复杂硬件藏起来，让应用不关心下面是什么。AI 时代却出现了反方向的压力：模型、推理引擎、调度系统越来越需要知道下面的硬件是什么，并据此做更细的资源选择。

Agent 如果进一步成为资源调用者，这套控制链还得再回答一个问题：谁允许它这么做？

Agent 需要的不只是资源，还有新的安全边界

对于传统 Web 服务，基础设施安全通常围绕几个熟悉的问题展开：工作负载之间要隔离，容器不能随意访问宿主机，用户权限必须受控。

Agent 把安全问题往前推了一步。它不仅执行代码，还会主动调用工具和外部系统。如果未来 Agent 可以更直接地碰到底层资源，那么“能不能把任务调度起来”只是第一步，还需要知道它被授权做什么、实际做了什么，以及出了问题之后能不能追溯甚至撤销。

这也是为什么 OpenInfra 旗下的 Kata Containers 在这套讨论里重新变得重要。

Thierry 把 Kata Containers 视为 OpenInfra 在 AI 安全上的核心项目之一。它不仅提供传统工作负载之间的隔离，还能进一步隔离工作负载与宿主机，因此尤其适合对数据访问和合规有严格要求的环境。与此同时，他也明确表示，这还远远不够，AI 基础设施未来还需要补上 可审计性（Auditability）和可逆性（Reversibility）。

这两个词放到 Agent 场景里尤其值得关注。所谓可审计，不只是记录一个 Pod 是否启动成功，而是能够回答：这个 Agent 为什么申请了某项资源？调用了什么？修改了哪些状态？所谓可逆，也不只是容器挂掉以后重新拉起来，而是当一个 Agent 做出错误操作后，系统有没有办法撤销已经造成的改变。

换句话说，未来 Agent 基础设施的控制面，很可能不能只管理“资源”，还要同时管理身份、权限、行为和后果。从现在的进展看，Kubernetes 已经在为 Agent 时代做准备，但这套能力还远没有定型。

CNCF 一侧，Kubernetes 已经在通过 DRA、AI Conformance 等机制适应异构 AI 资源；OpenInfra 一侧，则继续把 GPU、裸金属和更底层能力向上暴露，Kata Containers 负责补强隔离。两边其实都已经开始往 Agent 时代走，只是从 Thierry 的判断来看，真正为 Agent 原生设计的那一层基础设施，目前还没有完全出现。

对于 CNCF 和 OpenInfra 来说，Agent 带来的问题也正在逼近两者过去相对清晰的技术边界：一边要把越来越复杂的底层资源安全地暴露出来，另一边又要让上层系统足够了解这些资源，做出更精细的编排和控制。

过去十年，云原生解决的是怎样让软件更容易运行在动态基础设施上。Agent 时代接下来要解决的问题可能会反过来：当软件开始自己调用、选择甚至改变基础设施时，基础设施应该用什么方式回应它？这可能才是下一阶段 Kubernetes、OpenInfra 以及整个云原生生态真正需要面对的新问题。