重磅！Volcano发布AgentCube，构建AI Agent时代的云原生基础设施

本文分享自华为云社区《重磅！Volcano发布AgentCube，构建AI Agent时代的云原生基础设施》

云原生批量计算引擎Volcano 社区全新子项目AgentCube现已正式发布。AgentCube的诞生基于 Volcano 在大规模高性能计算调度领域多年的生产实践积累，它将这种高并发、高吞吐的调度能力延伸至 AI 领域，构建了一套面向智能体（Agent）工作负载的 Serverless 编排层，旨在为高并发、长会话、对延迟极度敏感的智能体（Agent）工作负载提供Serverless 化的编排与极速调度能力。

从 Kubernetes 到 Agent Native

随着大语言模型（LLM）技术的成熟，技术架构正从“无状态推理”向“自主智能体（Autonomous Agents）”演进。

在这一进程中，Kubernetes 凭借其成熟的生态和对异构算力的标准化管理，已成为构建 AI 基础设施的事实标准。虽然原生 Kubernetes 提供了通用的容器编排原语以及多样化的工作负载抽象，但在面对 AI Agent 这种“高并发、短时效、强状态依赖”的新型负载时，仍存在着显著的粒度错配与机制缺位：

启动延迟与交互体验的矛盾
Agent 的交互通常要求毫秒级响应。然而，原生的 K8s Pod 启动流程（调度、IP 分配、镜像拉取、容器启动）往往在秒级甚至分钟级。对于需要频繁拉起 Code Interpreter（代码解释器）或临时子 Agent 的场景，这种冷启动延迟是用户无法接受的。
资源利用率的挑战：Agent 是典型的IO 密集型负载。在一次会话中，90% 的时间 Agent 可能都在等待 LLM 生成 Token 或等待外部工具响应。如果在 K8s 上为每个 Agent 独占一个 Pod，会导致大量的 CPU/Memory 资源在等待期间被闲置浪费，却无法被其他任务复用。
会话状态管理的缺失：K8s 对“无状态（Stateless）”工作负载天然友好，但 Agent 高度依赖“上下文（Context/Memory）”。在原生 K8s 中，Pod 重启意味着内存数据丢失，开发者被迫在应用层通过外部存储重建上下文，这带来了巨大的复杂性和网络开销。
安全隔离难题：高级 Agent（如 Data Analyst）需要运行由 LLM 生成的不可信代码。但普通的 runC 容器如果运行 rm -rf / 具有极高风险。企业级 Agent 平台迫切需要一种既能快速启动，又能提供强隔离（如 MicroVM）的沙箱环境。

为了在 Kubernetes 坚实的算力底座之上，填补上述机制空白，AgentCube 应运而生。

AgentCube 是什么？

AgentCube是一个构建在 Volcano 之上的高性能 AI Agent 编排层。它通过扩展 Kubernetes API，将Agents和 Tools（Code Interpreters、BrowserUse等）提升为集群的一等公民。

它不仅仅是一个 CRD，更是一套面向 Agent 的 Serverless 操作系统。

核心架构与抽象

AgentCube 引入了两个核心的 CRD 来定义 Agent 工作负载：

AgentRuntime:面向长会话、复杂的对话式 Agent。
- 支持定义会话的生命周期、资源配额以及持久化策略。
CodeInterpreter:面向短任务、高频的代码执行环境。
- 强调“用完即毁”和极致的安全隔离，天然适配 MicroVM（如 Kuasar, Kata Containers, Firecracker）。

AgentCube后续还将提供BrowserUse、ComputerUse、MobileUse等工作负载抽象支持。

AgentCube 关键技术亮点

为了解决上述痛点，AgentCube 在架构设计上引入了多项创新：

1. 极速启动

为了消除冷启动的挑战，AgentCube 实现了Warm Pool（预热池）机制。系统会预先启动并暂停一组持有基础环境的 MicroVM 沙箱。当 Agent 请求到来时，AgentCube 能够通过"Claim-and-Go"的方式，在毫秒级将预热的沙箱分配给会话，实现近乎零延迟的启动体验。

2. 极速调度

借助 Volcano 的Agent Scheduler，AgentCube显著提升了Agent调度的吞吐和时延。

高吞吐、低时延：针对 Agent 突发流量，采用了乐观并发控制和精简的调度策略，大幅提升调度 TPS。
统一调度支持：Volcano 的 Agent Scheduler 可以与原有的 Batch Scheduler 无缝配合，在协调 Agent 与传统的 Batch 作业潜在调度冲突的同时，确保整体集群的资源利用率和关键业务的 SLA。

3. 原生会话管理

AgentCube 引入了Session ID作为核心路由标识，便于保证业务上下文的连续性。

请求路由：AgentCube Router 能够识别请求中的 x-agentcube-session-id，自动将其路由到对应的活跃沙箱。
自动的沙箱激活：当前会话对应的沙箱处于休眠状态时，AgentCube Router 能够自动激活沙箱。
基于会话的端到端隔离：AgentCube 会自动为每个会话分配独立的沙箱环境，确保计算、内存与文件系统的完全隔离，防止跨租户的数据泄露。

4. Serverless 化的弹性伸缩

AgentCube 能够根据会话的活跃度自动管理沙箱生命周期。闲置的沙箱会被自动回收或休眠，释放物理资源供其他高优先级任务使用，真正实现资源按需分配与极致利用。

AgentCube 架构概览

AgentCube 采用了经典的控制面与数据面分离的架构设计，确保了系统的高可用性与扩展性：

数据面 :由AgentCube Router承载。它作为流量入口，负责鉴权、限流以及基于 Session ID 的智能路由。对于新会话，它向控制面申请资源；对于活跃会话，它直接将请求转发至对应的Sandbox (MicroVM)。
控制面 :核心组件Workload Manager负责沙箱的全生命周期管理。它监控预热池 (Warm Pool) 的水位，自动补充 MicroVM 实例，并根据会话活跃度策略（如 TTL）执行沙箱的回收与垃圾清理。
调度层:集成Volcano Agent Scheduler，通过异步并行调度和乐观锁机制，实现高并发下的毫秒级资源分配。

生态协作：共建标准化的 Agent 基础设施

作为开源中立的基础设施项目，AgentCube 旨在通过标准接口连接上下游生态，协作解决从容器编排到智能体应用落地的“最后一公里”难题。

1. 南向兼容：基于标准接口的运行时适配

AgentCube 坚持开放架构设计，通过深度集成 kubernetes-sigs/agent-sandbox 接口及 OCI 标准，实现对底层异构运行时的统一抽象与无感适配。

运行时解耦：支持通过 RuntimeClass 机制接入 Kuasar、Kata Containers、Firecracker 等安全容器技术，允许用户根据安全与性能需求灵活选择底层隔离方案。
前沿探索：社区正在评估 Wasm (WebAssembly) 技术，计划在未来版本中探索其在极轻量级 Agent 任务中的应用，以提供更多样化的算力供给。