Kubernetes 跑 AI Agent,缺的不只是算力——AgentCube 补上了什么

举报
AGENT魔方 发表于 2026/05/11 11:36:34 2026/05/11
【摘要】 一次典型的 Code Interpreter 调用,往往从一个很小的动作开始:用户点击“运行代码”。但在一个原生 Kubernetes 环境中,这个动作背后通常意味着一整套秒级链路:调度 Pod、分配网络、拉取镜像、启动容器。对于需要多步推理、频繁调用工具、强依赖交互体验的 AI Agent 应用来说,这样的启动路径并不自然。AgentCube 提供了一组可直接落地的核心机制。

一次典型的 Code Interpreter 调用,往往从一个很小的动作开始:用户点击“运行代码”。

但在一个原生 Kubernetes 环境中,这个动作背后通常意味着一整套秒级链路:调度 Pod、分配网络、拉取镜像、启动容器。对于需要多步推理、频繁调用工具、强依赖交互体验的 AI Agent 应用来说,这样的启动路径并不自然。

1.png

这也是 AgentCube 试图解决的问题:在 Kubernetes 的算力底座之上,补齐面向 Agent 工作负载的关键机制缺口,提供一层真正理解会话、沙箱和工具调用语义的 Serverless 编排层。

AgentCube(https://github.com/volcano-sh/agentcube) 提供了一组可直接落地的核心机制。本文重点展开这些能力在实现层面的设计取舍:会话如何绑定沙箱预热池如何消除冷启动PicoD 如何替代 SSHJWT 安全链如何保护外部访问,以及系统如何自动回收不再活跃的沙箱资源

  从 Kubernetes 到 Agent Native  

随着大语言模型(LLM)技术的成熟,技术架构正从“无状态推理”向“自主智能体(Autonomous Agents)”演进。Kubernetes 凭借成熟的生态和对异构算力的标准化管理,已经成为构建 AI 基础设施的事实标准。但在面对 AI Agent 这种“高并发、短时效、强状态依赖”的新型负载时,原生 Kubernetes 仍存在几类明显的粒度错配与机制缺位。

启动延迟与交互体验的矛盾。 Agent 的交互通常要求毫秒级响应,而原生 K8s Pod 的启动流程往往是秒级甚至分钟级。对于需要频繁拉起 Code Interpreter 或临时子 Agent 的场景,这样的冷启动延迟很难被终端用户接受。

资源利用率的挑战。 Agent 是典型的 IO 密集型负载。在一次会话中,大量时间都消耗在等待 LLM 返回 Token 或等待外部工具响应。如果在 K8s 上为每个 Agent 独占一个 Pod,CPU 和内存资源会在等待期间被大量闲置。

会话状态管理的缺失。 K8s 对无状态工作负载天然友好,但 Agent 高度依赖上下文(Context / Memory)。Pod 的重建意味着内存态上下文的丢失,开发者被迫在应用层额外拼接外部状态存储,系统复杂度和网络开销都会随之上升。

安全隔离难题。 高级 Agent(如 Data Analyst)需要运行由 LLM 生成的不可信代码。普通的 runC 容器很难为这种场景提供足够强的隔离边界,企业级 Agent 平台需要一种既能快速启动、又具备强隔离能力的沙箱环境。

围绕这些问题,AgentCube 给出了一组明确的工程实现:

Kubernetes 面临的缺口
AgentCube 的对应机制
冷启动延迟高
Warm Pool 预热池,提前准备可分配的沙箱实例
会话请求需要保持上下文
Session ID 到沙箱实例的绑定式路由
不可信代码执行风险高
MicroVM 沙箱 + PicoD 执行面 + JWT 认证链
会话结束后资源容易堆积
基于空闲超时和绝对时长的双策略 GC

AgentCube 不是简单增加几条 CRD,而是在 Kubernetes 之上补上一层面向 Agent 工作负载的运行时与编排机制。

  整体架构  

AgentCube 的核心架构可以分为三部分:数据平面(Router)控制平面(Workload Manager) 和 沙箱执行面(PicoD)。系统通过 Redis/Valkey 维护会话状态和索引,使不同组件可以独立扩展。

2.png

图 1:AgentCube 整体架构 —— Router 接收请求并路由至沙箱,Workload Manager 管理沙箱生命周期,PicoD 负责沙箱内执行

核心组件一

组件
角色
关键能力
AgentCube Router
数据平面入口
HTTP 反向代理、会话路由、JWT 签名、并发控制
Workload Manager
控制平面
沙箱创建/删除、预热池管理、双策略 GC
PicoD
沙箱内守护进程
代码执行、文件 I/O、JWT 认证、路径沙箱化
Session Store
状态存储
Redis/Valkey 支持,Sorted Set 索引加速查询

一次典型请求的大致链路如下:

+----------+                  +----------+                  +------------------+
|  Client  | --- 1) HTTP ---> |  Router  | --- 2) alloc --> | Workload Manager |
+----------+                  +----+-----+                  +--------+---------+
                                   |                                 |
                          4) sign JWT                       3) create/claim
                             + proxy                          Sandbox Pod
                                   |                                 |
                                   v                                 v
                              +--------+                    +-------------+
                              | PicoD  | <-- running in --- | Sandbox Pod |
                              +---+----+                    +-------------+
                                  |
                         5) verify JWT
                            execute cmd
                            return result
                                  |
                                  v
                         stdout / stderr / exit_code

图中的 Sandbox Pod 底层是由 Kuasar 调用 CloudHypervisor 拉起的 MicroVM,PicoD 作为守护进程运行在 MicroVM 内部,负责接收来自 Router 的请求并在隔离环境中执行。

  核心特性深度解读  

一、Session-Based MicroVM Routing:让会话真正绑定执行环境

AI Agent 工作负载的一个本质特征,是有状态、交互式,并且可能跨越多次调用。一次完整的任务往往包含多步推理、工具调用、环境探查和中间结果写入。如果每个请求都被路由到新的执行环境,上下文就无法自然延续。

AgentCube 通过 Session ID -> 沙箱实例 的绑定关系解决这个问题:

  • 客户端首次调用时不携带 x-agentcube-session-id,Router 会为其分配新的沙箱实例
  • 响应头中返回 x-agentcube-session-id
  • 客户端后续请求携带该 Session ID,即可继续命中同一个会话沙箱

从客户端视角看,整个过程是透明的。它不需要理解底层沙箱的生命周期,只需要在多轮调用中带上同一个 Session ID。

Router 基于 Gin 构建,核心 handler handleInvoke() 的逻辑大致如下:

// 从请求头提取 Session ID
sessionID := c.GetHeader("x-agentcube-session-id")

// 通过 SessionManager 查找或创建沙箱
sandbox, err := s.sessionManager.GetSandboxBySession(
    c.Request.Context(), sessionID, namespace, name, kind)

// 更新会话最后活跃时间(用于 GC 判定)
s.storeClient.UpdateSessionLastActivity(ctx, sandbox.SessionID, time.Now())

// 反向代理转发至沙箱
s.forwardToSandbox(c, sandbox, path)

Router 同时支持 HTTP/2 (h2c) 透传,并内置可配置的并发请求上限(默认 1000),避免突发流量直接冲垮后端沙箱集群。

当前暴露的调用入口包括:

POST /v1/namespaces/{namespace}/agent-runtimes/{name}/invocations/*path
GET  /v1/namespaces/{namespace}/agent-runtimes/{name}/invocations/*path
POST /v1/namespaces/{namespace}/code-interpreters/{name}/invocations/*path
GET  /v1/namespaces/{namespace}/code-interpreters/{name}/invocations/*path

二、两种 CRD:两种工作负载抽象

AgentCube 在 Kubernetes 之上引入了两类核心 CRD,对应 AI Agent 领域里两种典型的运行模式:一种强调通用能力与灵活性,一种强调安全默认与沙箱约束。

AgentRuntime:面向通用 Agent 的运行时抽象

AgentRuntime 面向需要完整 Kubernetes 能力的对话式或工具调用型 Agent。它接受完整的 PodSpec 模板,因此可以挂载 Volume、注入凭据、配置 Sidecar 容器。

apiVersion: runtime.agentcube.volcano.sh/v1alpha1
kind: AgentRuntime
metadata:
  name: my-agent
spec:
  podTemplate:
    containers:
      - name: agent
        image: my-agent:latest
        ports:
          - containerPort: 8080
  targetPort:
    - pathPrefix: "/"
      port: 8080
      protocol: HTTP
  sessionTimeout: 15m
  maxSessionDuration: 8h

CodeInterpreter:面向安全代码执行的受约束抽象

CodeInterpreter 更适合 Notebook、REPL、“运行代码”按钮等多租户安全执行场景。相比 AgentRuntime,它采用更受约束的模板能力,以便将隔离、运行时和资源限制统一收敛到更安全的默认值。

apiVersion: runtime.agentcube.volcano.sh/v1alpha1
kind: CodeInterpreter
metadata:
  name: my-interpreter
spec:
  template:
    image: ghcr.io/volcano-sh/picod:latest
    runtimeClassName: kata
    resources:
      requests: { cpu: "500m", memory: "512Mi" }
      limits:   { cpu: "2",    memory: "2Gi"   }
  warmPoolSize: 3
  authMode: picod
  sessionTimeout: 15m
  maxSessionDuration: 8h

两者的核心差异在于:

  • AgentRuntime 更开放,优先满足复杂 Agent 应用的组合能力
  • CodeInterpreter 更收敛,优先满足安全沙箱场景的开箱即用

三、Warm Pool:预热池如何消除冷启动

从零创建沙箱实例,会不可避免地引入启动延迟。对于交互式 Agent 场景,这种等待通常是用户最直接感知到的体验问题。为此,AgentCube 引入了 Warm Pool 预热池机制

+-----------------------------------------------------------+
|                      Warm Pool                            |
|                                                           |
|   +-----------+   +-----------+   +-----------+           |
|   |  Sandbox  |   |  Sandbox  |   |  Sandbox  |  <- idle  |
|   |  (idle)   |   |  (idle)   |   |  (idle)   |           |
|   +-----+-----+   +-----------+   +-----------+           |
|         |                                                 |
|         v  new session --> SandboxClaim                   |
|   +-----------+                                           |
|   |  Sandbox  |  <- claimed, ready to use                 |
|   |  (active) |                                           |
|   +-----------+                                           |
|                                                           |
|   pool replenishes asynchronously                         |
+-----------------------------------------------------------+

Workload Manager 中的 CodeInterpreterReconciler 通过三层 CRD 协作完成这一机制:

1. SandboxTemplate:定义沙箱实例模板,并注入 PicoD 所需的认证公钥

2. SandboxWarmPool:声明预热副本数,维持一组可被直接认领的空闲实例

3. SandboxClaim:新会话到来时,从池中认领一个已就绪实例

这种做法的好处,是将“创建实例”和“分配实例”解耦。沙箱启动的慢路径前置到后台完成,用户请求只需走认领路径,因此可以显著缩短首跳延迟。

整个过程是幂等的。Reconciler 在调和循环中只对不一致状态做最小变更,这也使 Warm Pool 的管理方式天然贴合 Kubernetes 声明式控制器的工作模型。

面向更进一步的启动加速,社区后续计划集成 Kuasar Snapstart,通过内存快照进一步将沙箱就绪时间从秒级压缩至百毫秒量级。

四、PicoD:替代 SSH 的轻量级沙箱守护进程

传统代码沙箱方案通常依赖 SSH 进行远程执行。但对一个本质上是单请求 RPC 的场景来说,SSH 会引入过重的协议开销,包括密钥管理、多路复用协商和持久会话维护。

PicoD(Pico Daemon)就是在这样的背景下被引入的。它运行在沙箱内部,通过一组精简的 HTTP API 代替 SSH,完成命令执行、文件读写和健康检查等操作。

API 端点
方法
功能
/api/execute
POST
执行任意命令,支持超时、工作目录、环境变量
/api/files
POST
文件上传或写入(multipart 或 base64 JSON)
/api/files/*path
GET
文件下载或读取,支持流式传输
/health
GET
健康检查(免认证)

PicoD 运行在 MicroVM 内部,外部请求在触达它之前已经穿越了 VM 级隔离边界。Router 对每个请求签发短期 JWT,PicoD 校验通过后才执行——这道认证门与 MicroVM 隔离分别在两个层次上独立生效。

其执行逻辑的核心实现大致如下:

ctx, cancel := context.WithTimeout(ctx, timeout)
defer cancel()

cmd := exec.CommandContext(ctx, command[0], command[1:]...)
cmd.Dir = workspaceDir
cmd.Env = mergedEnv

if ctx.Err() == context.DeadlineExceeded {
    exitCode = 124
}

对应的防护措施包括:

  • 路径沙箱化:通过 sanitizePath() 将文件访问限制在指定 workspace 根目录下
  • 请求体大小限制:默认 32 MB,防止恶意请求耗尽内存
  • 无状态处理模型:每个请求独立处理,避免持久连接带来的额外攻击面

五、JWT 安全链:外部访问沙箱时,如何建立信任

沙箱实例是临时资源,会随时被创建和销毁。如果在集群中直接分发共享密钥,密钥轮换和安全边界都会变得脆弱。为此,AgentCube 在 Router 与 PicoD 之间建立了一条基于 RSA 非对称加密 的认证链。

+--------------+                     +-------------------------+
|    Router    |                     |    Kubernetes Secret    |
|              |  generate on boot   |  picod-router-identity  |
|  RSA-2048    | ------------------> |                         |
|  key pair    |                     |  private.pem  (Router)  |
|              |                     |  public.pem   (PicoD)   |
+------+-------+                     +------------+------------+
       |                                          |
       | sign with                    Workload Manager injects
       | private key                  PICOD_AUTH_PUBLIC_KEY
       | (5min TTL)                   into sandbox env
       |                                          |
       v                                          v
+--------------+   RS256 JWT Token   +--------------+
| Router signs | ------------------> | PicoD verify |
| (private key)|                     | (public key) |
+--------------+                     +--------------+

这条链路解决的是访问认证问题:Router 对外接收请求,对内使用私钥签发短时有效的 JWT;PicoD 持有公钥,负责校验请求是否合法。

关键设计点包括:

  • 5 分钟短有效期:即使 Token 泄漏,影响范围也能被压缩到很小
  • 1 分钟时钟漂移容忍:兼顾分布式环境中的时钟偏差
  • 私钥不出 Router:PicoD 仅做校验,不持有签发能力
  • 启动时自动生成并注入:降低运维配置复杂度

六、双策略 GC:如何回收不再活跃的沙箱

在 Agent 场景下,资源创建不是难点,难点在于如何及时、稳定地回收已经闲置的沙箱。如果会话终止后资源不能自动回收,集群最终会被大量“已经没人使用、但仍然占资源”的实例拖垮。

为此,AgentCube 在 Workload Manager 中实现了双重垃圾回收策略:

策略
触发条件
默认值
空闲超时(Idle TTL)
沙在 sessionTimeout 内无任何请求
15 分钟
绝对最大时长(Max Duration)
沙箱创建时间超过 maxSessionDuration
8 小时

GC 循环每 15 秒执行一次,每轮最多检查 100 个候选沙箱,避免单次 GC 扫描时间过长。

底层索引结构基于 Redis Sorted Set:

session:{sessionID}       -> SandboxInfo JSON
session:expiry            -> Sorted Set (score = 到期时间戳)
session:last_activity     -> Sorted Set (score = 最后活跃时间)

这种设计让系统可以用 ZRANGEBYSCORE 高效找出已过期或长期不活跃的会话。删除时,GC 会同时清理 Kubernetes 中的 Sandbox / SandboxClaim 资源和 Redis 中的会话记录,避免出现“实例删了但索引还在”或“索引删了但实例还活着”的不一致状态。

  生态集成  

除了运行时和沙箱机制,AgentCube 还提供了面向上层框架的接入能力,使应用开发者不需要直接处理底层基础设施细节。

Python SDK

from agentcube import CodeInterpreterClient

interpreter = CodeInterpreterClient()

result = interpreter.run_code("python", "print('Hello, AgentCube!')")
print(result)

interpreter.write_file(content="data", remote_path="/workspace/data.txt")
interpreter.download_file("/workspace/data.txt", "./local_data.txt")

LangChain / LangGraph 集成

AgentCube 可以作为 LangChain 的 @tool 接入 ReAct Agent 工作流,将代码执行部分自然下沉到受隔离的沙箱环境中,应用层无需直接理解底层实例调度和生命周期管理。

Dify 插件

项目仓库中的 dify-plugin 目录提供了 Dify 工具接入方式,使 Dify 用户也可以直接消费 AgentCube 的沙箱能力。

  快速上手  

前置条件

  • Kubernetes 集群 v1.24+
  • Redis 或 Valkey 实例
  • sigs.k8s.io/agent-sandbox v0.1.1 CRD 已安装

Helm 安装

helm install agentcube manifests/charts/base \
  --namespace agentcube-system --create-namespace \
  --set redis.addr=<redis-host>:6379 \
  --set redis.password="<password>"

创建第一个 CodeInterpreter

apiVersion: runtime.agentcube.volcano.sh/v1alpha1
kind: CodeInterpreter
metadata:
  name: my-interpreter
  namespace: default
spec:
  template:
    image: ghcr.io/volcano-sh/picod:latest
    resources:
      requests: { cpu: "500m", memory: "512Mi" }
      limits:   { cpu: "2",    memory: "2Gi"   }
  warmPoolSize: 2
  sessionTimeout: 15m
  maxSessionDuration: 8h

发起调用

curl -X POST \
  http://<router-host>/v1/namespaces/default/code-interpreters/my-interpreter/invocations/api/execute \
  -H "Content-Type: application/json" \
  -d '{"command": ["python3", "-c", "print(1+1)"]}'

响应头中的 x-agentcube-session-id 即为会话 ID。后续请求继续携带它,就可以复用同一个沙箱执行环境。

  致 谢  

从项目启动到今天,AgentCube 已经吸引了多位社区开发者参与共建。感谢所有为 AgentCube 做出贡献的开发者:

@YaoZengzeng
@acsoto
@hzxuzhonghu
@Sagar-6203620715
@mahil-2040
@t2wang
@FAUST-BENCHOU
@tjucoder
@LaynePeng
@yashisrani
@katara-Jayprakash
@LiZhenCheng9527
@Tweakzx
@warjiang
@LeslieKuo
@MahaoAlex
@VanderChen
@kevin-wangzefeng
@ifelseend
@cairon-ab
@RushabhMehta2005
@Sanchit2662
@qizha
@ssfffss
@wjf295004046
@Aman-Cool
@Storm1289
@sicaario



关链接

[1] GitHub 仓库https://github.com/volcano-sh/agentcube
[2] Volcano 官网https://volcano.sh
[3] 设计文档: https://github.com/volcano-sh/agentcube/tree/main/docs/design
[4] Python SDKhttps://github.com/volcano-sh/agentcube/tree/main/sdk-python

AgentCube 开源项目欢迎广大开发者参与。无论是提交 Issue、贡献 PR,还是在你的项目中试用 AgentCube,都是对项目的支持。

容器模仿.png

关注魔方公众号,获取更多前沿资讯

添加社区小助手k8s2222,进入技术交流群

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。