编程 Kubernetes Agent Sandbox 深度拆解：当 K8s 决定「给 AI Agent 造一个正经的家」——从 Sandbox CRD 到 WarmPool 预热池，一个 SIG 级开源项目如何用「声明式隔离 + 单容器 VM 体验」重新定义云原生 AI Agent 运行时的终极形态

2026-08-06 08:15:49 +0800 CST views 13

Kubernetes Agent Sandbox 深度拆解：当 K8s 决定「给 AI Agent 造一个正经的家」——从 Sandbox CRD 到 WarmPool 预热池，一个 SIG 级开源项目如何用「声明式隔离 + 单容器 VM 体验」重新定义云原生 AI Agent 运行时的终极形态

AI Agent 不是微服务，不是有状态副本集，也不是批处理作业。它需要属于自己的 Kubernetes 原语。

2026 年 5 月 20 日，Google 在 GKE 上宣布 Agent Sandbox 正式 GA，同时 Kubernetes SIG Apps 旗下的同名开源项目（kubernetes-sigs/agent-sandbox）迅速成为社区焦点。从 KubeCon NA 2025 的预览发布到 GA 不到半年，GKE 上的 Sandbox 使用量暴涨 16 倍，LangChain 和 Lovable 等早期客户已在上面运行百万级 Agent 实例。

这不是又一个"在 Kubernetes 上跑 xxx"的套壳项目。它标志着 K8s 社区正式承认了一件事：AI Agent 是一种全新的工作负载类别，它需要自己的声明式 API、自己的隔离模型、自己的生命周期管理。

本文将从问题本质出发，深度拆解 Agent Sandbox 的架构设计、核心组件、隔离机制、预热池策略、与 AI Gateway 的协同，以及它与 AWS Bedrock AgentCore 的路线之争。

一、问题本质：为什么 Deployment 和 StatefulSet 都不够用

在深入方案之前，我们先搞清楚问题到底出在哪。

1.1 AI Agent 的三重特殊性

AI Agent 工作负载有三个核心特征，让它与传统 Kubernetes 工作负载格格不入：

长时间运行 + 有状态：Claude Code 跑起来动不动几个小时甚至几天不停，中间要执行代码、读写文件、调用各种工具链。它的内存里存着对话上下文和中间推理状态，不能像无状态微服务那样随意杀掉重启。

执行不可信代码：Agent 执行的代码是 LLM 生成的——你信不信得过它？2026 年社区里已经有人分享案例，某 Coding Agent 在修复 bug 过程中执行了 rm -rf /tmp，把同节点其他 Pod 的临时文件全删了。

高频短生命周期子任务：Agent 的主进程可能跑几天，但它发起的工具调用、代码执行等子任务是亚秒级的——进进出出，chatter 不断。这种模式会把 Kubernetes API Server 打崩。

1.2 传统方案的四大痛点

痛点	具体表现	根因
生命周期管理	Pod 空闲时占着资源不能杀，暂停/恢复需要自己写控制器	K8s 原生不支持 Pod 暂停
安全隔离	标准容器共享宿主机内核，一个内核漏洞影响全部 Pod	namespace 隔离不够
冷启动延迟	scale down 后恢复需要半分钟（调度+拉镜像+加载上下文）	没有预热机制
资源调度	StatefulSet 副本数设 1 浪费资源，设多又不安全	缺少单实例语义

之前的做法基本是"土法炼钢"：StatefulSet 副本数设 1 + PVC 存状态 + headless Service 给 DNS + CronJob 清理过期 session。能跑，但维护成本高、功能跟不上需求变化。

二、Agent Sandbox 核心架构：四个 CRD 打天下

Agent Sandbox 是 Kubernetes SIG Apps 下的开源项目，提供了一组 CRD 和一个控制器，专门用来管理"隔离的、有状态的、单实例的工作负载"。

2.1 Sandbox：核心资源

一个最简单的 Sandbox 定义：

apiVersion: agents.x-k8s.io/v1alpha1
kind: Sandbox
metadata:
  name: code-review-agent
spec:
  podTemplate:
    spec:
      containers:
      - name: agent-runtime
        image: my-agent-runtime:latest
        resources:
          requests:
            cpu: "2"
            memory: "4Gi"
          limits:
            cpu: "4"
            memory: "8Gi"

创建之后，你的 Agent 就有了：

稳定的 hostname：code-review-agent.sandbox-ns.svc.cluster.local
可选的持久存储：通过 persistentVolumeClaim 挂载 PVC
完整的生命周期管理：创建、定时删除、暂停、恢复
单实例语义：保证同一时刻只有一个 Pod 在运行

控制器帮你搞定底层的 Pod 创建、存储绑定、DNS 注册这些脏活累活。开发者只需要声明"我要一个沙箱"，不用关心 Pod 怎么调度、存储怎么绑定。

2.2 SandboxTemplate：标准化 Agent 运行环境

这是平台团队最关心的资源。它定义了一套标准的 Agent 运行环境配置：

apiVersion: agents.x-k8s.io/v1alpha1
kind: SandboxTemplate
metadata:
  name: coding-agent-template
spec:
  sandboxSpec:
    podTemplate:
      spec:
        runtimeClassName: gvisor
        containers:
        - name: agent-runtime
          image: coding-agent:latest
          resources:
            requests:
              cpu: "4"
              memory: "8Gi"
    storage:
      size: "50Gi"
      storageClass: fast-ssd
    networking:
      allowedEndpoints:
      - "https://api.anthropic.com"
      - "https://api.openai.com"

设计思路有点像 StorageClass——定义一次，到处引用。开发者创建 Sandbox 时引用这个模板：

apiVersion: agents.x-k8s.io/v1alpha1
kind: Sandbox
metadata:
  name: my-review-agent
spec:
  templateRef:
    name: coding-agent-template
  # 可以覆盖模板中的部分配置
  overrides:
    podTemplate:
      spec:
        containers:
        - name: agent-runtime
          env:
          - name: MODEL
            value: "claude-sonnet-4"

这对大团队来说太重要了——否则每个业务组都自己拼 YAML，配置漂移是迟早的事。

2.3 SandboxClaim：消费者接口

SandboxClaim 解耦了"我要一个沙箱"和"沙箱底层长什么样"这两个关注点：

apiVersion: agents.x-k8s.io/v1alpha1
kind: SandboxClaim
metadata:
  name: langchain-tool-execution
spec:
  templateRef:
    name: coding-agent-template
  requirements:
    minCpu: "2"
    minMemory: "4Gi"
    maxDuration: "30m"

上层框架（LangChain、Google ADK 等）通过 SandboxClaim 来请求一个沙箱执行环境。这意味着你换底层的隔离实现（比如从 gVisor 切到 Kata），上面的 Agent 框架代码一行不用改。

这种抽象层次的设计非常聪明——它让基础设施团队和应用开发团队各管各的，互不干扰。

2.4 SandboxWarmPool：冷启动的终极解法

这才是解决冷启动的真正杀手锏。

apiVersion: agents.x-k8s.io/v1alpha1
kind: SandboxWarmPool
metadata:
  name: coding-agent-pool
spec:
  templateRef:
    name: coding-agent-template
  minReady: 10        # 至少保持 10 个 ready 状态的沙箱
  maxReady: 50        # 最多 50 个
  maxSuspended: 100   # 悬挂状态下最多 100 个

控制器会提前创建一批已经 ready 的 Pod 放在那里"热着"，新请求来了直接从池子里分配一个现成的 Sandbox，不用走完整的 Pod 创建流程。

Google 在 GKE 上的实测数据：

每集群每秒能分配 300 个 Sandbox
90% 的分配操作在 200 毫秒内完成
200ms 对交互式场景来说几乎感知不到

WarmPool 还有一个巧妙的两级缓存设计：

┌─────────────────────────────────────────┐
│              Warm Pool                   │
│   ┌──────────┐    ┌──────────┐          │
│   │  Ready   │    │Suspended │          │
│   │ (热备)   │←──→│ (冷备)   │          │
│   │ 立即可用 │    │ 存储级成本│          │
│   └──────────┘    └──────────┘          │
└─────────────────────────────────────────┘
         ↑ 分配请求 (200ms P90)

Ready 池：Pod 已经跑起来了，分配延迟 < 100ms
Suspended 池：Pod 被挂起到磁盘，只收存储费不收计算费用，恢复到 Ready 级别约 1-2s

Google 用 suspended VM 做"冷池"来补充 warm pool——这个思路自建集群也可以借鉴，用 KubeVirt 或者节点休眠方案来实现类似的效果。

三、安全隔离：gVisor vs Kata Containers

安全隔离是 Agent 场景的硬需求。你让一个 LLM 生成代码然后直接执行，这事本质上跟跑不可信的第三方代码没区别。

Agent Sandbox 在隔离上做了一个很聪明的设计决策：它本身不绑定任何特定的隔离技术，而是通过 Kubernetes 的 runtimeClassName 来对接。

3.1 gVisor：用户态内核拦截

gVisor 是 Google 搞的系统调用拦截器。它在用户态实现了一个叫 Sentry 的组件，拦截 workload 的所有系统调用，只转发一小部分到真实内核。

┌──────────────────────────┐
│      Agent Workload       │
│   (LLM 生成的代码)        │
├──────────────────────────┤
│        gVisor Sentry      │  ← 用户态内核
│   拦截系统调用，过滤转发    │
├──────────────────────────┤
│      Host Linux Kernel    │  ← 真实内核（隔离）
└──────────────────────────┘

优势：

开销小、启动快（毫秒级）
大部分 AI Agent 场景够用
不需要嵌套虚拟化支持

局限：

不是所有系统调用都支持，某些底层操作会失败
文件系统性能有一定损耗
不适合需要 raw socket 或特殊内核模块的场景

适用场景：内部团队的 Coding Agent、文档分析 Agent、数据处理 Agent。

3.2 Kata Containers：硬件级 VM 隔离

Kata Containers 让每个 Pod 跑在一个独立的轻量级 VM 里面，真正的硬件虚拟化隔离。

┌──────────────────────────┐
│      Agent Workload       │
├──────────────────────────┤
│     Kata Guest Kernel     │  ← 独立内核
├──────────────────────────┤
│    Cloud Hypervisor       │  ← 轻量级 VMM
├──────────────────────────┤
│      Host Linux Kernel    │  ← 完全隔离
└──────────────────────────┘

优势：

每个 Sandbox 有自己的内核
一个 Sandbox 里的内核漏洞完全不影响其他 Sandbox 和宿主机
隔离强度最高

局限：

启动延迟较大（VM boot 内核，约 1-3s）
内存开销更高（每个 VM 需要独立的内核内存）
需要嵌套虚拟化支持（裸金属或支持 VT-x 的云实例）

适用场景：面向外部客户的 Code Sandbox、SaaS 产品里的用户代码执行、金融/政务等高安全要求场景。

3.3 选型决策矩阵

维度	gVisor	Kata Containers
启动延迟	< 100ms	1-3s
内存开销	低	中-高
隔离强度	中（用户态拦截）	高（硬件虚拟化）
系统调用兼容性	部分	完全
嵌套虚拟化要求	不需要	需要
典型场景	内部 Agent	外部 Code Sandbox

在 SandboxTemplate 里指定就行：

spec:
  sandboxSpec:
    podTemplate:
      spec:
        runtimeClassName: gvisor  # 或 kata

四、与 AI Gateway 的协同：三层架构各司其职

2026 年 3 月 9 日，K8s 社区宣布成立 AI Gateway Working Group，11 天之后就发了 Agent Sandbox 这篇博客。这个时间间隔绝对不是巧合——这俩是一套组合拳。

4.1 AI Gateway：智能路由层

传统的 Ingress 或 Gateway API 做 L7 路由，本质上就是匹配 host、path 然后转发给后端。但模型推理的流量不一样——你不能把请求随便丢给一个健康的 Pod 就完事。

AI Gateway 引入了 InferencePool 的概念，让网关在路由推理请求时能感知模型服务器特有的指标：

用户请求 → AI Gateway → InferencePool（感知 KV-cache、队列深度、LoRA 加载状态）→ 推理后端

4.2 Agent Sandbox：运行时层

Agent Sandbox 解决的是"Agent 运行时怎么安全地跑在集群里"——长时间运行、有状态、需要隔离、需要快速分配和回收。

4.3 完整的请求流程

用户请求
  ↓
AI Gateway（路由层：感知模型状态，智能分发）
  ↓
推理后端（模型推理，决定调用工具）
  ↓
Agent Sandbox（运行时层：隔离执行工具调用，返回结果）
  ↓
推理后端（整合结果，生成回复）
  ↓
AI Gateway
  ↓
用户

网关不是沙箱，沙箱不是路由器。各管各的，清晰明了。

4.4 Agent Substrate：更薄更快的控制面

Google 同时发布了一个叫 Agent Substrate 的新开源项目。这个项目的目标很疯狂——它认为标准 Kubernetes 的控制面不够用了。

K8s API Server 设计上是为数千个长时间运行的 Service 优化的，但 Agent 场景是数百万个亚秒级的工具调用进进出出，这种 chatter 会把 API Server 打崩。

Agent Substrate 用一个极简的控制面绕过 K8s 的一些瓶颈，同时保留安全运行时和快照能力。

有点当年 containerd 从 Docker 里剥出来的味道——大方向不变，但为了极致性能场景定制一个更薄更快的层。

五、生产环境实战指南

5.1 安装部署

# 安装 Agent Sandbox CRD 和控制器
export VERSION="v0.1.0"
kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${VERSION}/manifest.yaml
kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${VERSION}/extensions.yaml

# 验证安装
kubectl get sandbox
kubectl get sandboxtemplate
kubectl get sandboxwarmpool

5.2 WarmPool 成本管理

WarmPool 的大小直接影响两个指标：冷启动延迟和闲置成本。池子太大，一堆 Pod 白白占着资源没人用；池子太小，高峰期又不够分配。

推荐的分层策略：

apiVersion: agents.x-k8s.io/v1alpha1
kind: SandboxWarmPool
metadata:
  name: production-agent-pool
spec:
  templateRef:
    name: coding-agent-template
  # 热备：立即可用，但有计算成本
  minReady: 5
  maxReady: 20
  # 冷备：只收存储费，需要时恢复
  maxSuspended: 100
  # 自动扩缩策略
  scaling:
    targetAllocationRate: 0.7  # 当池子使用率 > 70% 时扩容
    scaleUpIncrement: 5
    scaleDownDelay: "10m"       # 缩容前等待 10 分钟

5.3 网络策略：安全底线

Agent 执行的是 LLM 生成的不可信代码，网络必须做 default-deny：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-sandbox-network
  namespace: agent-system
spec:
  podSelector:
    matchLabels:
      agents.x-k8s.io/sandbox: "true"
  policyTypes:
  - Ingress
  - Egress
  ingress:
  # 只允许健康检查
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
    ports:
    - port: 8080
      protocol: TCP
  egress:
  # 白名单：LLM API
  - to:
    - ipBlock:
        cidr: 104.18.0.0/15  # Anthropic API
    ports:
    - port: 443
      protocol: TCP
  # 白名单：内部服务
  - to:
    - podSelector:
        matchLabels:
          app: internal-service

就算 Agent 里跑了恶意代码想外联，网络层直接拦住。

5.4 可观测性搭建

Agent Sandbox 项目本身不带 metrics 和日志聚合方案，生产环境至少要做到：

# 自定义 Prometheus ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: agent-sandbox-metrics
spec:
  selector:
    matchLabels:
      app: agent-sandbox-controller
  endpoints:
  - port: metrics
    interval: 15s

关键监控指标：

Sandbox 分配延迟：P50/P90/P99
WarmPool 利用率：Ready/Suspended 数量变化
资源使用率：每个 Sandbox 的 CPU/内存/存储
异常事件：Sandbox 异常终止、OOM、网络拒绝

5.5 持久存储 vs 临时存储

场景	存储类型	生命周期
Coding Agent（保留依赖、git 缓存）	PVC	跟 Sandbox 生命周期一致
一次性代码执行	EmptyDir	Sandbox 销毁即释放
模型缓存、LoRA 权重	hostPath + cache	节点级共享

混用两种模式的时候注意 PVC 的生命周期管理，设好 scheduledDeletion 避免存储泄漏。

六、SDK 编程模型：从 YAML 到代码

Agent Sandbox 除了 kubectl 声明式管理之外，还提供了 Python 和 Go 两套 SDK。

6.1 Python SDK：Agent 框架集成

from agentsandbox import SandboxClient, SandboxClaim

client = SandboxClient(namespace="agent-system")

# 从预热池分配一个沙箱
claim = SandboxClaim(
    template_ref="coding-agent-template",
    requirements={"min_cpu": "2", "min_memory": "4Gi"}
)
sandbox = client.claim(claim)

try:
    # 执行代码
    result = sandbox.exec(
        code="""
import pandas as pd
df = pd.read_csv('/data/sales.csv')
print(df.groupby('region')['revenue'].sum())
""",
        timeout=30
    )
    print(result.output)
finally:
    # 释放沙箱回池子
    client.release(sandbox)

整个过程对 Agent 的编排逻辑来说就是一次函数调用，底层的 Pod 创建、隔离、网络配置全被 SDK 屏蔽掉了。这种编程模型很像 AWS Lambda 的 invoke——你不用关心函数跑在哪台机器上，只管调用和拿结果。

6.2 Go SDK：平台级集成

package main

import (
    "context"
    "fmt"
    agentsandbox "github.com/kubernetes-sigs/agent-sandbox/sdk/go"
)

func main() {
    client, _ := agentsandbox.NewClient("agent-system")
    
    // 创建一个持久化沙箱
    sandbox, _ := client.CreateSandbox(context.Background(), &agentsandbox.SandboxSpec{
        TemplateRef: "coding-agent-template",
        Metadata: map[string]string{
            "user-id": "u-12345",
            "session-id": "s-67890",
        },
    })
    
    // 执行工具调用
    result, _ := sandbox.Exec(context.Background(), &agentsandbox.ExecRequest{
        Command: []string{"python3", "/workspace/tool.py", "--input", "/data/input.json"},
        Timeout: 60,
    })
    
    fmt.Printf("Exit code: %d, Output: %s\n", result.ExitCode, result.Output)
    
    // 暂停沙箱（释放计算资源，保留状态）
    sandbox.Suspend(context.Background())
}

6.3 与其他方案的对比

方案	隔离	编排	冷启动	灵活性	运维成本
直接调 Docker API	弱	无	快	低	高
Lambda / Cloud Functions	强	有	慢（秒级）	低	低
自写 StatefulSet Controller	中	有	慢	中	高
Agent Sandbox	可插拔	声明式 + SDK	200ms P90	高	中

七、与 AWS Bedrock AgentCore 的路线之争

AWS 走的是另一条路。Bedrock AgentCore 提供的是全托管的 Agent 执行环境——你不需要关心底层是 K8s 还是别的什么，把 Agent 代码交给平台就行。

7.1 两条路线的本质差异

维度	Agent Sandbox（自建路线）	Bedrock AgentCore（托管路线）
控制力	完全控制	黑盒
数据主权	数据在你的集群	数据在 AWS
定制性	极高（自定义内核、网络）	有限
运维成本	中（需自建集群）	低
灵活性	高	受限于 AWS 服务边界
厂商锁定	无	强

7.2 选型建议

选 Agent Sandbox 的场景：

金融、政务等对数据主权有严格要求
需要对执行环境做深度定制（特殊网络拓扑、自定义内核参数）
已有 Kubernetes 集群和运维团队
需要多云或混合云部署

选 Bedrock AgentCore 的场景：

快速出活，不想操心底层
团队没有 K8s 运维经验
纯 AWS 技术栈
对延迟和性能没有极端要求

八、架构设计的深层思考

8.1 为什么是 CRD 而不是 Operator Pattern

Agent Sandbox 选择了 CRD + 控制器的模式，而不是传统的 Operator Pattern。这个选择背后的考量是：

声明式 vs 命令式：CRD 让你声明"我想要什么"，控制器负责"怎么达到"。这与 Kubernetes 的哲学一致。
可组合性：Sandbox、SandboxTemplate、SandboxClaim、SandboxWarmPool 四个 CRD 可以自由组合，覆盖各种场景。
生态兼容：CRD 天然兼容 K8s 生态中的所有工具（kubectl、Helm、ArgoCD 等）。

8.2 SandboxClaim 的抽象价值

SandboxClaim 的设计体现了基础设施领域一个重要的抽象原则：消费者不应该知道提供者的实现细节。

上层的 Agent 框架只需要说"我需要一个沙箱，要有 2 个 CPU 和 4G 内存"，不需要知道底层用的是 gVisor 还是 Kata，不需要知道 Pod 怎么调度、存储怎么绑定。

这种解耦让基础设施团队可以独立演进隔离方案，而应用团队完全无感。

8.3 WarmPool 的经济学

WarmPool 不只是一个技术方案，更是一个经济学问题。

设 C_warm 为维持一个 Warm 状态 Sandbox 的每小时成本，C_suspended 为 Suspended 状态的成本，L 为冷启动延迟的业务损失，R 为请求到达率。

最优 WarmPool 大小满足：

P(请求到达时有 Ready Sandbox) ≥ SLA 目标
min(C_warm × N_warm + C_suspended × N_suspended)

Google 的实践表明，200ms P90 延迟对应的 WarmPool 大小约为峰值 QPS 的 1.5 倍。

九、局限性与演进方向

9.1 当前局限

API 还是 alpha：v1alpha1，随时可能 breaking change
生态还在早期：没有 production-ready 的 Helm Chart，文档案例不够丰富
厂商支持有限：目前只有 GKE 正式支持，其他云厂商尚未跟进
监控方案需自建：不带内置的 metrics 和日志聚合

9.2 社区演进方向

从 SIG Apps 的 Roadmap 来看，接下来几个关键里程碑：

v1beta1 API（预计 2026 Q4）：稳定核心 API，冻结 CRD 字段
多租户支持：ResourceQuota 和 LimitRange 集成
GPU 感知调度：为 AI Agent 场景优化 GPU 资源分配
快照与恢复：Pod Snapshot 做热挂起，Agent 空闲时暂停到磁盘，有请求时秒级恢复
生态集成：LangChain、CrewAI、AutoGen 等框架的官方 Sandbox 集成

十、总结：AI Agent 需要自己的 Kubernetes 原语

Agent Sandbox 的出现标志着 K8s 社区正式承认了一件事：AI Agent 是一种全新的工作负载类别。它不是微服务，不是有状态副本集，也不是批处理作业。它需要属于自己的 Kubernetes 原语。

这个认知转变比具体的技术实现更重要。

从更大的架构视角看，AI Gateway + Agent Sandbox + 传统 K8s 负载（Deployment/StatefulSet/Job），三层各司其职，构成了云原生 AI 平台的基座：

┌─────────────────────────────────────────────┐
│                  用户请求                     │
├─────────────────────────────────────────────┤
│  AI Gateway（路由层：感知模型状态，智能分发）    │
├─────────────┬───────────────┬───────────────┤
│  推理后端    │ Agent Sandbox │  传统 K8s 负载  │
│  (Deployment)│ (Sandbox CRD) │ (Job/StatefulSet)│
└─────────────┴───────────────┴───────────────┘

如果你正在搭建 AI Agent 平台或者 SaaS 产品的代码执行引擎，Agent Sandbox 值得现在就开始跟踪。但也不建议无脑上——API 还没稳定之前，简单场景用 Deployment 和 Job 就够了，别为了尝鲜引入额外复杂度。

适合上 Agent Sandbox 的信号：

需要用户级别或任务级别的隔离
长时间运行的有状态 Agent
需要执行不可信代码
对冷启动延迟敏感的交互式应用

云原生 AI 的基础设施正在从"能跑"走向"跑得好"。Agent Sandbox 是这个演进过程中的一个重要里程碑。

本文基于 kubernetes-sigs/agent-sandbox 项目（2026 年 7 月最新代码）、Google GKE Agent Sandbox GA 公告、以及社区实践案例整理。文中代码示例基于 v1alpha1 API，实际使用时请以最新文档为准。

参考资源：

Kubernetes Agent Sandbox 项目：https://github.com/kubernetes-sigs/agent-sandbox
Google GKE Agent Sandbox：https://cloud.google.com/kubernetes-engine/docs/concepts/agent-sandbox
AI Gateway Working Group：https://github.com/kubernetes-sigs/ai-gateway
Agent Substrate：https://github.com/google/agent-substrate
K8s 社区博客：Running Agents on Kubernetes with Agent Sandbox