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 做容器编排，最上