Agent Substrate：为大规模AI Agent重构Kubernetes

当整个行业都在讨论如何让 AI Agent 跑得更快、更聪明时，一个更基础的问题正在浮出水面：Agent 的运行环境本身，是不是设计错了？NVIDIA 开发者博客近日发布的 Agent Substrate 项目，正是冲着这个底层假设去的——它试图回答的问题是，Kubernetes 这套为长期运行服务而生的编排系统，能否以及如何被改造为适合大规模 AI Agent 的运行时。

Agent 的工作负载，Kubernetes 的盲区

原文开篇点出了一个被忽视的事实：AI Agent 大部分时间处于空闲状态，等待人类提示、工具返回结果或模型响应。这与 Kubernetes 的设计假设形成了根本冲突。

Kubernetes 的核心抽象是为持续在线的服务进程准备的。一个 Pod 一旦被调度，就默认它要长期占用资源、保持存活、持续对外提供服务。但 Agent 的执行模式截然不同：它会在瞬间爆发大量推理和工具调用，然后在等待外部输入时长时间休眠。如果延续一个 Pod 对应一个 Agent 的做法，集群里会堆积大量闲置却仍占着调度单元和资源配额的 Pod，横向扩展的成本迅速失控。

这个矛盾不是调优能解决的，它要求对编排层的抽象重新做一层建模。

Kubernetes 中的 Pod 是最小可调度单元，一个 Pod 通常封装一个或多个容器，共享网络命名空间与存储卷。调度器（kube-scheduler）将 Pod 绑定到节点后，kubelet 负责维持其运行状态，而资源配额（ResourceQuota）和请求/限制（requests/limits）机制则按 Pod 的持续存在来核算资源。这种模型对 Web 服务、数据库等长期在线进程非常自然，但它的隐含前提是：工作负载的生命周期与进程生命周期基本一致。Agent 的"爆发—休眠"模式打破了这个前提，因为进程虽然存在，资源需求却随时间剧烈波动，按 Pod 静态核算的方式因此产生系统性浪费。

在 Kubernetes 生态中，针对间歇性或事件驱动负载已有一些既有机制，例如基于队列深度的 Horizontal Pod Autoscaler、KEDA 的事件驱动伸缩，以及 Job/CronJob 对短生命周期任务的建模。但这些方案主要解决"副本数量"的伸缩问题，而非"单个 Agent 内部的活跃度"问题。Agent 的挑战在于：同一个逻辑实体在空闲时几乎不消耗计算，却在被唤醒的瞬间需要低延迟地拿到推理资源。这更接近"有状态会话 + 弹性计算"的组合，超出了原生 Deployment/ReplicaSet 抽象的舒适区。

Agent Substrate 的核心思路

Agent Substrate 的定位可以理解为：在 Kubernetes 之上加一层专门面向 Agent 生命周期的抽象，让调度粒度与 Agent 的实际活跃状态对齐，而不是与进程的存在状态对齐。

原文给出的关键线索是「Running one Pod per...」——即传统上一个 Pod 承载一个 Agent 的映射方式，在大规模场景下难以为继。Agent Substrate 要解决的正是这种映射带来的资源浪费与调度僵化问题，让集群能够以更贴合 Agent 行为特征的方式来承载成千上万个 Agent 实例。

这一思路的意义在于，它把 Agent 当作一类独立的工作负载类型来看待，而不是把普通微服务的运行模式硬套在 Agent 上。对于需要在生产环境中运行多 Agent 系统的团队来说，这直接决定了单位成本与可扩展上限。

"一个 Pod 承载一个 Agent"的映射之所以在大规模下失效，可以从数量级上理解：若一个集群要运行上万个 Agent，而每个 Agent 平均活跃时间占比只有百分之几，那么按 Pod 常驻方式部署意味着绝大多数调度单元和内存预留处于空转。更关键的是，Kubernetes 的调度和健康检查（liveness/readiness probe）都是围绕"进程是否健康存活"设计的，而 Agent 的"健康"更应定义为能否在需要时快速获得推理与工具调用能力。把调度粒度与活跃状态对齐，本质上是在编排层引入一层"逻辑 Agent 到物理执行单元"的动态映射，让空闲 Agent 释放计算资源、唤醒时再重新绑定。

对 Agent 基础设施竞争格局的影响

过去一段时间，Agent 框架层的创新非常密集，但运行时与编排层的进展相对滞后。Agent Substrate 把注意力拉回到了基础设施这一层。

它的价值不只在于技术方案本身，更在于提出了一个清晰的问题框架：当 Agent 成为集群中的主要工作负载时，调度、资源配额、生命周期管理这些基础机制需要怎样重新设计。围绕这个问题的讨论，会直接影响企业部署多 Agent 系统的架构选型——是继续在通用编排系统上打补丁，还是引入专门为 Agent 设计的运行时层。

对于构建大规模 Agent 应用的工程团队而言，值得关注的是这一方向能否形成可复用的实践模式。NVIDIA 以开发者博客的形式发布该项目，也意味着后续可能会有更具体的实现细节与集成路径释出。

Agent 框架层（如 LangGraph、AutoGen、CrewAI 等）主要解决 Agent 的编排逻辑、工具调用与多 Agent 协作问题，运行在应用进程内部；而运行时与编排层关心的是进程如何被调度、资源如何分配、状态如何持久化。两者之间的边界长期模糊，导致许多团队用应用层代码来弥补基础设施的不足，例如自行实现会话排队、空闲回收和并发限流。Agent Substrate 这类项目的意义，是把这些本应由基础设施承担的职责上移，使框架层可以专注于 Agent 行为本身。判断这一方向是否成熟，关键看它能否提供稳定的 API 抽象、与现有 Kubernetes 工具链（如 Operator、CRD、可观测性体系）的兼容性，以及在真实负载下的调度延迟表现。

写在最后

Agent Substrate 触及的是一个容易被忽略却无法绕开的瓶颈：Agent 的智能程度在快速提升，但承载它们的运行时如果仍然按传统服务的方式设计，规模化部署的成本和复杂度就会成为实际落地的天花板。把 Kubernetes 改造为真正适配 Agent 负载的系统，或许是让 Agent 从演示走向生产的关键一步。