AI 智能体大部分时间处于空闲状态，等待人类的提示、工具结果或模型响应。Kubernetes 并非为此设计。每个会话运行一个 Pod 会为那些没有任何操作的会话占用内存，而在每轮之间删除 Pod 则会在每次都产生数秒级的冷启动延迟，并丢失智能体的状态。强化学习（RL）后训练也面临同样的瓶颈。
Agent Substrate 现已捐赠给云原生计算基金会（CNCF）Sandbox 项目，它是一个开源、经过安全加固、采用零信任架构的沙箱智能体运行时，旨在以比标准容器高 10 倍的密度安全运行数百万个智能体和工具。它将大量会话复用到一小部分工作 Pod 池中。空闲会话（包括内存和文件系统）会被存档，并在下一个请求到达时恢复到空闲的工作节点上。随着智能体基础设施碎片化为绕过 Kubernetes 的专有运行时，NVIDIA 正在向上游贡献代码，以保持这项工作的开放性。
本文将介绍哪些工作负载适合使用 Agent Substrate、上游正在构建的内容，以及该项目如何与 DSX AI Factory 平台中的 KAI Scheduler 和 NVIDIA Dynamo 组件协同工作。
智能体工作负载的形态
传统 Web 服务以相对少量的长生命周期实例运行。智能体遵循不同的模式：它们唤醒后执行一步操作——运行 shell 命令、编辑文件、调用测试套件或调用大语言模型。然后它们会等待，有时是几毫秒，有时是几分钟，才进行下一步。智能体的状态（文件系统、进程、工作目录）必须在各步骤之间保持延续。
Kubernetes 在这方面遇到困难，因为为智能体启动一个计算 Pod 需要经过 API 服务器、准入控制、etcd、调度器、kubelet、镜像拉取和网络设置。这需要几秒钟，对于运行数周的服务来说没问题，但对于一个必须出现、运行一个 10 毫秒的 bash 命令然后消失、每秒执行数百次的沙箱来说，实在太慢了。
这给平台团队留下了两个并不理想的选择：要么为每个智能体保持一个 Pod 常驻，为几乎一直闲置的计算资源付费；要么按需创建 Pod，在每一步都承受冷启动的代价。
Agent Substrate 的工作原理
Agent Substrate 使用 Kubernetes 来运行一个就绪 Pod 池。它创建了一个独立的控制平面，将大量参与者（智能体及其运行环境）映射到这个较小的工作节点池上。当一个参与者进入空闲状态时，它会从沙箱（gVisor 或 microVM）中被快照保存，其工作节点随即被释放。当该参与者再次被调用时，它会被恢复到任意一个空闲的工作节点上，并保留其内存和文件系统状态。
唤醒一个参与者不需要重新经过 API 服务器、调度器或 kubelet。Agent Substrate 会将参与者直接恢复到现有的工作节点上。工作节点 Pod 仍然是普通的 Kubernetes Pod，因此集群调度、配额和部署策略依然适用，具体内容将在后文描述。
推动需求的使用场景
我们观察到三类工作负载正在推动对 Agent Substrate 的需求：
编码助手与智能体服务：一个编码智能体在大语言模型调用与自身环境中的工作之间交替进行，例如克隆代码仓库、编辑文件、运行构建和测试。用户期望环境在各轮之间保持延续并能立即响应。为数千个此类会话提供服务的平台无法负担为每个会话配备专用的常驻沙箱。
基于智能体环境的强化学习（RL）后训练：具有可验证奖励的强化学习会同时运行 GPU 训练器和生成服务器，以及一批 CPU 密集型环境（代码沙箱、编译器、浏览器、模拟器），用于执行操作并检查结果。沙箱需求会随着 rollout 批次分派操作而呈突发式出现。一次训练任务可能从早期实验中的几百个沙箱增长到生产环境中的数十万个。最慢的环境决定了训练器何时获得下一批数据，因此该环节的冷启动会导致 GPU 闲置。
面向研究的 GPU 沙箱：研究人员的编码智能体需要 GPU，不是为了提供模型服务，而是为了编译 CUDA 代码、测试内核性能或进行数值计算。它在共享集群上启动一个 GPU 沙箱，运行任务后删除该沙箱。要在整个组织范围内支持这种模式，需要大量快速启动、公平共享有限 GPU 资源池的短生命周期隔离 GPU 沙箱。
上游工作：已落地的内容与下一步计划
以下每项贡献都源自上述某一使用场景。所有这些工作都公开在 Agent Substrate 代码库中：
当所有工作节点都繁忙时，下一个请求会等待而不是失败：在超订系统中，例如高峰期的编码助手平台或 RL rollout 突发场景，用户的下一轮请求可能在所有工作节点都忙碌时到达。过去 Agent Substrate 会立即返回错误，即便另一个参与者通常会在片刻之后释放一个工作节点。
Agent Substrate 路由器中的请求排队机制（#221）会保留请求并重试恢复操作，直到有工作节点空闲，同时设有有限的等待时间和同时等待请求数的上限。一项后续改进（#1229）确保对已运行参与者的请求不会卡在这个队列中。
在沙箱内为智能体提供 GPU：如前所述的研究用 GPU 沙箱，以及基于模拟器等的 GPU 支持的 RL 环境。
我们正在开发设备可插拔性，为 Kubernetes 动态资源分配（DRA）增加设备支持。设备厂商通过配置文件接入其设备，沙箱中的每个容器只申请自身所需的设备（#752），并且同一模型适用于 gVisor 和 microVM 两种沙箱。NVIDIA GPU 将是首个受支持的设备。
一个容器不应拖垮或杀死其他容器：智能体沙箱通常会将智能体的工作负载与用于日志记录、代理或指标采集的辅助容器一起运行，其中一些可能是不受信任的。一个失控的容器不应该占用整个沙箱的内存，进而导致智能体崩溃。
针对 microVM 沙箱的每容器 CPU 和内存限制（#859）解决了这一问题。超出内存限制的容器会被自行停止，沙箱中的其余部分继续运行。
在挂起与恢复过程中保留 GPU 沙箱状态
当智能体暂停以等待人工审核时，其沙箱应释放 GPU，并在之后恢复运行时，其已编译的构建产物和已加载的数据仍然保持原状。要支持这一点，需要同时保存和恢复智能体状态与 GPU 状态。
恢复 GPU 状态会带来硬件兼容性方面的限制。一个 GPU 检查点通常只能恢复到相同型号的 GPU 上，有时甚至需要相同的驱动版本。Agent Substrate 提出了一种设计方案来解决这个问题。
设备厂商描述如何安全地暂停其设备，以及某个快照依赖哪些设备属性。Agent Substrate 会将这些属性与每个快照一同记录，并将沙箱恢复到匹配的设备上；如果没有匹配设备可用，则回退到彻底的冷启动。该设计与厂商无关，构建在 DRA 之上。NVIDIA GPU 是首个目标对象，该设计可扩展至其他硬件类型。
NVIDIA Dynamo：连接智能体循环与推理循环
Agent Substrate 管理智能体在何处执行动作，推理运行时则管理智能体在何处进行“思考”。两者都面临类似的效率挑战：让空闲沙箱保持常驻会浪费 CPU 和内存，而在重复的模型调用中重建模型上下文则会浪费 GPU 周期。独立扩展每一层都能提升利用率。而将两者协调起来，还能降低延迟，并在智能体在工具执行与模型调用之间切换时保留可复用的上下文。
开源分布式推理框架 NVIDIA Dynamo 提供了这种协调能力。Agent Substrate 负责在一组常驻沙箱工作节点之间激活、挂起和恢复有状态的智能体环境。Dynamo 负责在 GPU 工作节点之间编排推理任务。Dynamo 路由器位于两者之间，将智能体正在执行的操作与 GPU 上正在发生的事情连接起来。
让推理具备智能体感知能力
传统的推理路由将每次模型调用视为独立请求。而在智能体场景中，每个请求都是一个更长循环中的一步，连续的请求通常会复用相同的系统提示、工具定义、对话历史和先前的观察结果。
Dynamo 的路由器能够识别可复用的键值（KV）缓存位于何处、哪些工作节点正忙于预填充或解码，以及负载在 GPU 集群中的分布情况。Agent Substrate 和智能体框架则补充了诸如会话身份、请求优先级、预期输出长度、工具调用边界和生命周期事件等信号。
两者结合，Dynamo 能够实现：
将相关的模型调用保持在已持有可复用 KV 缓存的工作节点上，而不会造成 GPU 热点过载
在推理资源池承压时，优先处理交互式轮次而非后台智能体任务
在工具调用间隙中保持系统提示、工具定义和对话历史的可用性
优先丢弃已终止子智能体、已关闭推理分支或已汇总上下文的缓存状态
在工具调用接近完成时，预先准备可能需要的上下文
将 GPU 层面的信息反馈给 Agent Substrate
这项集成中最重要的部分是，Dynamo 将推理信号暴露给 Agent Substrate，帮助其决定何时让智能体继续运行、何时挂起或何时恢复。
Dynamo 比智能体运行时更接近 GPU 执行层，它能够洞察缓存就绪状态、队列压力、正在进行的预填充和解码工作，以及一次大语言模型请求可能耗费的时间。这些信息既能用于指导推理路由，也能用于指导 Agent Substrate 如何调度智能体沙箱。
Dynamo 可以返回诸如预计首个 Token 生成时间、预计完成时间、请求进度、缓存就绪状态以及 GPU 资源池饱和度等信号。Agent Substrate 可以利用这些反馈来决定是否让某个参与者（Actor）继续保持常驻、在较长的推理等待期间将其挂起，或在模型响应即将完成时将其恢复。
在整个集群规模层面，同样的反馈信息可以帮助调整常驻工作节点的容量、调控智能体及子智能体的扩展规模，并避免在 GPU 队列已饱和的情况下激活原本会闲置的 CPU 沙箱。
这种集成建立了一种简洁的职责划分：Agent Substrate 管理智能体环境的高频生命周期，Dynamo 管理推理的高性能生命周期。Dynamo 将二者围绕定义智能体计算的核心循环连接起来：模型调用、工具调用、观察结果，再到下一次模型调用。
开始使用：结合 Dynamo 与 Agent Substrate 的编码助手
本指南提供在 Dynamo 和 Agent Substrate 上部署编码助手的分步说明。
你将学到：
（指南链接待补充）
将 Pi 编码智能体作为 Substrate 参与者运行：为每个智能体提供一个隔离的有状态环境，用于检查代码仓库、编辑代码和运行测试。
将智能体连接到通过 NVIDIA Dynamo 提供服务的 GLM-5.3-Flash：在 Substrate 管理的沙箱中完成模型推理与工具执行之间的闭环。
使用 Harbor 编排 SWE-bench Verified 上的评估任务：让智能体应对软件问题并收集结果，以评估其改动是否解决了相应任务。
Agent Substrate 仍在持续演进中。其 API 仍在变化，GPU 支持正基于新的 DRA 基础进行重构，部分 Dynamo 智能体集成功能仍处于实验阶段。现在正是参与贡献、共同塑造核心设计的好时机。
结合 KAI Scheduler 与 Dynamo 运行 Agent Substrate
Agent Substrate 运行在 Kubernetes 之上，与负责模型服务和工作负载部署的 NVIDIA 软件协同工作。Substrate 管理有状态的智能体环境，KAI Scheduler 负责部署 Kubernetes 工作负载，而 Dynamo 负责提供模型服务并与智能体运行时交换推理状态信号。
三者共同协作，将 CPU 侧的工具执行与 GPU 侧的推理协调起来，从而更高效地利用共享的集群资源。
下表展示了各组件在整体架构中所处的位置。Dynamo、KAI Scheduler 以及 Kubernetes 基础组件都是 NVIDIA DSX OS 的组成部分。
Agent Substrate 是一个独立的开源 CNCF Sandbox 项目，并非 DSX OS 的指定组件，不过 NVIDIA 正在向上游贡献代码，并开发与 DSX OS 组件的互操作性。
表 1：Agent Substrate 在用于在 Kubernetes 上运行 AI 智能体与 RL 环境的技术栈中所处的位置：各层的技术、作用及与 NVIDIA DSX OS 的关系。
KAI Scheduler 与 Agent Substrate 运行在不同的调度层级：Substrate 工作节点 Pod 是普通的 Kubernetes Pod。KAI Scheduler 目前可以将它们与所支持的 GPU 训练器和推理服务器一起部署。将工作节点池的自动扩缩容与 KAI 的队列及公平共享策略相协调，有望将跨租户的资源共享能力延伸到环境层面。
与我们一起在 KubeCon 构建智能体基础设施
Agent Substrate 社区聚会——11 月 10 日（周二），盐湖城。这是一场面向维护者、贡献者以及生态系统中任何感兴趣人士的非正式晚间活动。欢迎加入，一起讨论本文提到的各项贡献，并结识正在 Kubernetes 上构建智能体基础设施未来的开发者们。
闪电演讲——11 月 11 日（周三）下午 1:00–1:15，地点为 Google Cloud 展位 #122：主题为“从 Pod 到参与者：面向智能体工作负载的 GPU 感知基础设施”
NVIDIA 展位 #170，KubeCon + CloudNativeCon North America——11 月 10 日至 12 日。欢迎前来与我们的专家交流智能体平台、Kubernetes 上的 RL 后训练、Substrate、Dynamo 以及 KAI Scheduler 等话题。
与专家面对面——11 月 11 日（周三）下午 3:15–3:35（山地时间），地点为 NVIDIA 展位 #170，讨论 Agent Substrate 及在 Kubernetes 上运行智能体工作负载的相关话题。
了解完整的“与专家面对面”活动安排——NVIDIA 参加 2026 年 KubeCon + CloudNativeCon North America
进一步了解
如果你正在 Kubernetes 上构建智能体平台、编码助手或 RL 环境，我们很想听听你的工作负载情况。欢迎在活动现场与我们交流，查看 Dynamo 指南，或在 agent-substrate/substrate 或 ai-dynamo/dynamo 中提交 issue。加入社区会议，参与塑造接下来的发展方向。
