1. 引言

大模型与智能体（Agent）技术的爆发，让「代码执行」「工具调用」「浏览器操作」「文件处理」成为 AI 应用的核心能力。然而，让一个由大模型驱动、行为不可完全预测的智能体直接运行在生产环境的宿主机上，是一次对安全边界的极限考验。提示词注入、越权访问、恶意依赖、资源耗尽、横向逃逸……每一个环节都可能在一次看似无害的任务执行中被触发。

智能体沙箱（Agent Sandbox）由此成为 AI 基础设施中与算力、模型、数据同等重要的一环。它要解决的核心矛盾是：既要让智能体拥有完成任务所需的完整执行能力，又要确保这些能力被严格约束在可控、可观测、可回收的边界之内。当这条边界需要同时支撑成千上万个并发任务时，问题就从「安全隔离」升级为「高并发下的资源隔离」——一个横跨操作系统、容器、虚拟化、调度与平台的系统性工程问题。

本文试图给出一个生产级的参考答案。我们将从威胁模型出发，梳理从进程级到微虚拟机级的隔离技术全景，深入 Linux 内核隔离原语，对比 gVisor、Firecracker、Kata Containers 等主流沙箱运行时，然后落到平台架构、资源配额、CPU/内存/IO/网络/文件系统的隔离策略，最后讨论多租户、安全加固、可观测性、故障自愈与容量规划。文章面向平台架构师、SRE、安全工程师以及 AI Infra 开发者，力求做到「原理讲透、选型有据、工程可落地」。

2. 智能体沙箱的威胁模型与隔离需求

2.1 智能体执行的典型场景

在进入技术细节之前，先明确我们要保护的对象和执行的对象。一个典型的智能体沙箱需要承载以下几种工作负载：

• 代码解释器（Code Interpreter）：执行由模型生成的 Python、JavaScript、Shell 脚本，常见于数据分析、图表生成、格式转换等场景。
• 工具调用链：智能体调用外部工具（搜索、API、数据库、文件系统），工具的输出又成为下一轮模型输入。
• 浏览器自动化：通过 Playwright、Puppeteer 驱动无头浏览器完成网页操作、信息抓取、表单提交。
• 长时任务编排：多步任务中穿插人工确认、模型推理与外部调用，单个沙箱生命周期可能从秒级延长到小时级。

这些负载的共同特征是：代码路径由模型动态生成，输入可能来自不可信的外部世界，执行具有不确定性。

2.2 威胁模型

把智能体沙箱抽象为一个「不可信执行环境」，威胁来自四个方向：

表 2-1 智能体沙箱威胁向量

威胁源	典型攻击	后果
提示词注入	用户输入中植入指令劫持模型行为	诱导智能体执行恶意代码、泄露上下文
恶意生成代码	模型生成删除文件、反弹 shell、挖矿脚本	宿主机受损、算力被盗、数据泄露
恶意依赖	安装或导入带后门的 PyPI/npm 包	供应链攻击、持久化后门
资源滥用	死循环、超大内存分配、磁盘写满、网络扫描	宿主机资源耗尽、影响其他租户

基于此，隔离需求可以被分解为七个维度：

1. 边界完整性：沙箱内的代码无法突破边界访问宿主机或其他租户。
2. 资源确定性：任何单个沙箱的 CPU、内存、磁盘、网络、进程数都在配额之内。
3. 可回收性：沙箱终止后，其创建的一切资源（进程、文件、网络连接、挂载点）能被完全清理。
4. 可观测性：所有关键动作可被记录、审计与追踪。
5. 性能可接受：隔离带来的开销不显著侵蚀任务执行效率。
6. 横向公平：高并发下，单个「吵闹邻居」不能拖垮同宿主机的其他租户。
7. 弹性与自适应：平台能根据负载动态扩缩，故障能自动隔离与恢复。

2.3 隔离强度的量化

没有一种隔离是绝对的。工程上常用「攻击面收敛程度」和「内核共享程度」来衡量隔离强度。引入一个简化的分级模型：

隔离级别	共享内核	代表技术	安全性	开销	冷启动
L0 进程级	是	subprocess + seccomp	低	极低	毫秒级
L1 容器级	是	Docker + gVisor	中	低	百毫秒级
L2 微虚拟机级	否（独立内核/最小内核）	Firecracker、Kata	高	中	百毫秒到秒级
L3 完整虚拟机级	否	QEMU/KVM	最高	高	秒级

生产级智能体平台通常以 L1 或 L2 为主力，L0 用于高吞吐、低风险场景，L3 用于高等级租户或不可信第三方插件。后文会详细讨论这四级的工程取舍。

3. 隔离技术全景：从进程到虚拟机

3.1 进程级隔离：第一道防线

最简单的沙箱是把智能体生成的代码放在子进程中执行，并限制其权限。Python 的 subprocess、os.fork 是常见入口。但裸进程隔离的缺点显而易见：进程与宿主机共享同一个内核、同一个根文件系统视图、同一套系统调用接口，攻击面极大。

工程上会叠加三层补强：

• 降权：以非 root 用户运行，配合 setuid/setgid 最小权限。
• 系统调用过滤：通过 seccomp-bpf 白名单过滤危险系统调用。
• 资源限制：通过 rlimit 限制 CPU 时间、内存、文件大小、进程数。

这种方案适合「高吞吐、低价值、短任务」场景，例如一次性的格式化转换、正则匹配、简单的数学计算。它的优点是启动快、编排简单，缺点是隔离强度有限，无法阻止所有内核漏洞利用。

3.2 容器级隔离：Namespace + Cgroup

容器技术把隔离推进了一大步。Linux 内核提供了两大支柱：

• Namespace（命名空间）：为进程提供独立的资源视图——PID、NET、IPC、UTS、MNT、USER、CGROUP、TIME。
• Cgroup（控制组）：对进程组的 CPU、内存、IO、PIDs 等资源做配额与记账。

以 Docker 为代表的容器运行时，把「镜像 + 命名空间 + cgroup + 联合文件系统」打包成标准单元。对智能体沙箱而言，容器提供了：

• 独立的文件系统根（rootfs），即使被删库也不会伤及宿主机。
• 独立的网络栈，可做出入网控制。
• 内核级资源限制，遏制资源滥用。
• 快速创建与销毁，适合弹性扩展。

但容器仍有隐患：所有容器共享同一个宿主机内核，一旦出现内核提权漏洞（如 Dirty COW、Dirty Pipe），容器逃逸就可能发生。因此，对安全等级要求更高的平台，会在容器之上叠加更严格的运行时（gVisor）或干脆切到微虚拟机。

3.3 用户态内核：gVisor

gVisor 是 Google 开源的进程沙箱，其核心思想是「以用户态内核拦截系统调用」。它由两个组件构成：

• Sentry：用 Go 实现的用户态内核，充当系统调用过滤与处理层。
• Gofer：文件系统代理，负责对宿主文件系统的受控访问。

应用进程通过 ptrace 或 KVM 平台被拦截，其系统调用大部分在 Sentry 内完成，只有极少部分安全地代理到宿主机内核。这样做的效果是：即使应用触发了宿主机内核漏洞，攻击者也很少有机会直接与宿主机内核交互，因为绝大多数系统调用根本不会落到宿主内核。

gVisor 的权衡也很明确：系统调用经过用户态拦截后，开销比原生容器高出数倍到数十倍，尤其是高 IO 密集、系统调用密集的负载。它非常适合「代码解释器」这类计算中等、安全性要求高的场景。

3.4 微虚拟机：Firecracker 与 Kata Containers

当需要「接近虚拟机的隔离强度」又要求「接近容器的启动速度」时，微虚拟机（MicroVM）登场。

Firecracker 由 AWS 开源，专为无服务器函数（Lambda）和容器服务（Fargate）设计。它的设计取向极为克制：

• 只支持 VirtIO 设备模型（net、block、vsock、balloon）。
• 去除 BIOS、VGA、USB 等无关设备，攻击面从传统 QEMU 的数万行设备代码缩小到极致。
• 基于 KVM，每个微虚拟机运行一个精简的 guest 内核，与宿主机内核完全隔离。
• 冷启动时间可做到 125ms 级别，配合快照恢复可接近 10ms。

Kata Containers 则走了一条「容器接口 + 虚拟机内核」的融合路线：对外保持 OCI 容器标准（与 Kubernetes 无缝集成），对内用轻量级 VM（默认 QEMU，可切换 Firecracker、Cloud Hypervisor）承载容器。它解决了 gVisor 的性能问题，也解决了容器共享内核的安全问题，是「既要又要」的折中之选。

3.5 各层级选型决策树

选择隔离级别时，可以按以下决策顺序收敛：

实际上，一个成熟平台往往多级并存：默认流量走 gVisor 或微虚拟机，内部白名单流量走轻量容器，极端敏感的租户升级到完整 VM。后文架构设计中会展开多级调度。

4. Linux 内核隔离原语

无论选择哪种运行时，最终都绕不开 Linux 内核的隔离机制。这一节把 cgroup v2、namespace、seccomp、capabilities、rlimit、Landlock 等原语梳理清楚，它们是理解一切上层沙箱的基础。

4.1 Cgroup v2 统一层级

cgroup v2 是当前生产环境的主流。与 v1 的「每子系统一树」不同，v2 采用统一层级，控制器（controller）挂载在同一棵树上，解决了 v1 中 memory 与 io 记账不一致、进程跨分组混乱等历史问题。

核心控制器包括：

• cpu / cpu.max：CPU 使用配额。
• memory / memory.max、memory.high：内存上限与软限制。
• io / io.max：块设备读写带宽与 IOPS 限制。
• pids / pids.max：进程数限制。
• cpuset：CPU 与 NUMA 亲和。
• hugetlb：大页内存限制。

示例：创建一个 cgroup 并限制 CPU 与内存

# 创建分组
mkdir /sys/fs/cgroup/agent-sandbox-42
cd /sys/fs/cgroup/agent-sandbox-42

# 限制最多使用 2 个 CPU 核心（每秒 200ms 等价）
echo "200000 100000" > cpu.max

# 硬性内存上限 512MB
echo "536870912" > memory.max

# 进程数上限 64
echo "64" > pids.max

# 将进程放入分组
echo $PID > cgroup.procs

示例：对块设备做 IO 限速

# 假设设备号 8:0（/dev/sda）
echo "8:0 rbps=10485760 wbps=10485760 riops=100 wiops=100" > io.max

4.2 Namespace 独立视图

单靠 cgroup 限制资源，无法阻止一个沙箱「看到」其他沙箱的文件、进程、网络。Namespace 补上了「视图隔离」这一环：

Namespace	隔离对象	典型用途
PID	进程号空间	沙箱内只能看到自己的进程树
NET	网络设备、路由、防火墙	独立 IP、独立 iptables 规则
MNT	挂载点	独立根文件系统、只读挂载
UTS	主机名、域名	环境隔离
IPC	System V IPC、POSIX 消息队列	防止跨容器消息注入
USER	UID/GID 映射	沙箱内 root 映射到宿主机非 root
CGROUP	cgroup 视图	防止沙箱挂载/修改宿主 cgroup
TIME	时钟命名空间	虚拟时间偏移

一个完整的沙箱创建流程，按顺序 clone 各 namespace，再 pivot_root 到独立 rootfs，最后应用 cgroup 与 seccomp。容器运行时（runc、youki、crun）把这些步骤标准化成了 OCI 规范。

手写命名空间隔离示意（Go）

// 创建新进程时，指定需要的新 namespace
cmd := exec.Command("/bin/sh")
cmd.SysProcAttr = &syscall.SysProcAttr{
    Cloneflags: syscall.CLONE_NEWPID |
        syscall.CLONE_NEWNET |
        syscall.CLONE_NEWNS |
        syscall.CLONE_NEWUTS |
        syscall.CLONE_NEWIPC |
        syscall.CLONE_NEWUSER |
        syscall.CLONE_NEWCGROUP,
    UidMappings: []syscall.SysProcIDMap{{ContainerID: 0, HostID: 10000, Size: 1}},
    GidMappings: []syscall.SysProcIDMap{{ContainerID: 0, HostID: 10000, Size: 1}},
}

4.3 Seccomp-bpf 系统调用过滤

seccomp（Secure Computing Mode）允许进程进入「安全计算模式」，只放行白名单内的系统调用。seccomp-bpf 通过 BPF 过滤器对每个系统调用做判定，支持按架构、参数做细粒度决策。

针对代码解释器沙箱，常见的危险系统调用包括：

• ptrace、process_vm_readv/writev：跨进程内存读写。
• mount、umount、pivot_root：挂载操作。
• reboot、kexec_load、init_module：内核操作。
• keyctl、add_key：内核密钥环操作。
• bpf：加载 BPF 程序。
• perf_event_open：性能事件探测。
• unshare、setns：命名空间逃逸。

seccomp 配置文件片段（Docker 风格 JSON）

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "archMap": [
    { "architecture": "SCMP_ARCH_X86_64", "subArchitectures": ["SCMP_ARCH_X86", "SCMP_ARCH_X32"] }
  ],
  "syscalls": [
    {
      "names": ["read", "write", "openat", "close", "stat", "fstat", "mmap", "mprotect"],
      "action": "SCMP_ACT_ALLOW"
    },
    {
      "names": ["mount", "umount", "ptrace", "bpf", "reboot"],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

默认动作为 ERRNO（拒绝并返回错误码）而非 KILL，能避免脚本因误触某个系统调用被整体终止，提升可用性。

4.4 Capabilities 与降权

Linux capabilities 把 root 的超级权限拆分为细粒度能力位，如 CAP_SYS_ADMIN、CAP_NET_RAW、CAP_SYS_PTRACE 等。沙箱应遵循最小权限原则：默认 drop 所有 capabilities，只保留任务必需的少数几项。

代码解释器通常不需要任何高级 capability。浏览器自动化可能只需要 CAP_SYS_NICE（调整优先级）。在 Docker 中对应参数：

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE sandbox-image

4.5 rlimit 与 Landlock

rlimit 是进程级资源限制的老牌手段，作为纵深防御的补充仍然有效：

• RLIMIT_CPU：CPU 时间上限（秒）。
• RLIMIT_AS：虚拟地址空间上限。
• RLIMIT_FSIZE：单文件大小上限。
• RLIMIT_NOFILE：打开文件描述符数上限。
• RLIMIT_NPROC：进程数上限。

Python 中设置 rlimit 示例

import resource

# 限制 CPU 时间为 10 秒
resource.setrlimit(resource.RLIMIT_CPU, (10, 10))
# 限制地址空间 512MB
resource.setrlimit(resource.RLIMIT_AS, (512 * 1024 * 1024, 512 * 1024 * 1024))
# 限制打开文件数 128
resource.setrlimit(resource.RLIMIT_NOFILE, (128, 128))

Landlock 是较新的安全模块，采用「自主访问控制」思路，由程序自己声明可访问的文件路径，语义类似沙箱。它比 AppArmor、SELinux 更轻量，策略简单、不易配错，适合作为文件系统访问的最后一层防线。

// Landlock: 限制进程只能访问指定路径
struct landlock_ruleset_attr ruleset_attr = {
    .handled_access_fs = LANDLOCK_ACCESS_FS_EXECUTE |
                         LANDLOCK_ACCESS_FS_WRITE_FILE |
                         LANDLOCK_ACCESS_FS_READ_FILE,
};
int ruleset_fd = landlock_create_ruleset(&ruleset_attr, sizeof(ruleset_attr), 0);

5. 沙箱运行时选型对比

这一节把几个主流的沙箱运行时放在同一张表里对比，并给出面向智能体场景的选型建议。

5.1 主流运行时横向对比

表 5-1 沙箱运行时关键指标对比

运行时	隔离模型	启动速度	内存开销	系统调用性能	生态成熟度	适用场景
Docker（runc）	命名空间 + cgroup	快（百 ms）	低	原生	极高	通用容器
gVisor	用户态内核	中（百 ms）	中	低（2-10x）	高	不可信代码执行
Firecracker	微虚拟机	快（125ms+）	低（~5MB guest）	中（接近原生 IO）	高	无服务器函数
Kata Containers	容器 + 轻量 VM	中（200ms-1s）	中	中	高	K8s 安全容器
Cloud Hypervisor	微虚拟机	快	低	中	中	自研 VMM
WebAssembly(Wasm)	字节码隔离	极快（µs-ms）	极低	高	快速上升	纯计算扩展

5.2 面向智能体的维度权重

智能体场景与普通容器场景的差异在于：

1. 执行代码不可信：安全权重高于性能权重。
2. 任务短促且弹性：启动速度直接影响用户体验和成本。
3. 高并发：调度器必须能并行管理上万个沙箱实例。
4. 文件系统交互频繁：代码解释器常见「写文件-读文件-绘图」模式。
5. 生命周期极不均衡：既有 1 秒完成的评估，也有 30 分钟的复杂编排。

基于此，给出一个分场景推荐矩阵：

场景	推荐运行时	理由
纯数学/文本处理（内部可信）	runc 容器	开销最低，吞吐最高
通用代码解释器（不可信）	gVisor	安全与性能平衡，生态成熟
高等级租户 / 第三方插件	Firecracker 或 Kata	独立内核，隔离最强
浏览器自动化	runc + seccomp + 独立网络	浏览器本身已是重进程，过重隔离开销大
函数式工具调用	Wasm	启动快、隔离强，适合纯逻辑

5.3 混合运行时的必要性

单一运行时方案在生产级平台中很快会碰到边界：

• 全用 runc：一次内核漏洞即可能全线失守。
• 全用 gVisor：IO 密集任务性能明显下降，成本上升。
• 全用 Firecracker：管理面复杂度高，冷启动与镜像分发压力大。

因此，多级运行时 + 智能路由是生产级架构的普遍选择。平台根据租户等级、任务类型、历史行为评分，把工作负载路由到不同运行时池。后续架构设计章节会给出完整的路由与调度方案。

6. 生产级平台架构总体设计

从这一节开始，进入真正的「架构设计」部分。我们以一个支持万级并发沙箱的平台为目标，拆解其控制面与数据面。

6.1 总体架构图

6.2 核心组件职责

任务调度器（Task Scheduler）
接收来自 API 网关的沙箱创建请求，将任务分配到合适的 Worker 节点。调度决策考虑：节点资源水位、运行时类型、亲和/反亲和（同一租户尽量分散到不同节点以降低单点影响）、镜像是否已预热。

沙箱生命周期管理（Lifecycle Manager）
维护每个沙箱的状态机，统一处理 Create → Running → Paused → Terminated → Purged 各阶段。它是平台最大的状态中枢，需要具备幂等性、超时兜底和故障重试。

运行时路由（Runtime Router）
把「租户等级 + 任务类型 + 安全评分」转化为运行时选择。典型策略：

routing_rules:
  - tenant_tier: free
    task_type: code_interpreter
    runtime: gvisor
  - tenant_tier: enterprise
    task_type: code_interpreter
    runtime: firecracker
  - tenant_tier: trusted_internal
    task_type: data_transform
    runtime: runc

配额与多租户管理（Quota Manager）
维护租户维度的配额（并发数、总 CPU 核数、总内存、磁盘、API 调用频率），在调度前做配额校验，防止单个租户占满集群。

镜像管理服务（Image Service）
智能体沙箱镜像包含运行时、语言环境、常用库、预装工具。镜像管理服务负责构建、签名、分层缓存、按节点预热。分层缓存能让 1GB 的 Python 沙箱镜像在节点上只拉取增量层。

审计与计量（Audit & Metering）
记录每个沙箱的创建者、执行内容摘要、资源用量、生命周期事件。既用于计费，也用于安全审计与合规追溯。

6.3 节点池的异构设计

集群中的 Worker 节点按运行时分池，每个池可以有不同的硬件画像：

• runc 池：通用计算型，适合高吞吐转化任务。
• gVisor 池：安全计算型，适合默认代码解释器任务。
• Firecracker 池：高隔离型，适合企业级租户与高风险插件。
• Wasm 池：轻量函数型，低延迟弹性。

这种分池设计让运维可以独立地对每个池做扩缩容、安全加固和故障隔离。数据面与控制面通过统一调度协议解耦。

6.4 状态管理：把「无状态」进行到底

高并发平台的首要纪律是沙箱本身无状态。所有需要持久化的数据（工作目录、生成的文件、中间结果）都写入外部对象存储或持久卷，沙箱实例只是一个「执行容器」。

这样设计的好处：

1. 沙箱可以随时被杀掉、重建而不丢数据。
2. 节点故障时任务可被调度器迁移到其他节点重试。
3. 弹性伸缩无状态包袱，冷启动即可服务。

沙箱内仅保留临时工作空间（tmpfs 或临时 rootfs），任务结束后统一回收。需要「会话连续性」的场景，把状态保存为快照写入对象存储。

7. 资源配额与 QoS 设计

资源隔离的工程化，本质是**配额（Quota）、优先级（Priority）、驱逐（Eviction）与回收（Reclaim）**四者的闭环。

7.1 配额模型

为每个沙箱定义标准配额（Requests/Limits 语义）：

sandbox_quota:
  requests:
    cpu: "0.1"
    memory: "128Mi"
  limits:
    cpu: "2"
    memory: "512Mi"
    pids: 64
    disk: "1Gi"
    network_egress_bytes_per_sec: "10Mi"
    wall_time_seconds: 900

Request（保证量）：调度时据此预留资源，保证沙箱有底线性能。
Limit（上限量）：沙箱能使用的最大资源，超出即限流或 OOM。
wall_time_seconds：沙箱最长存活时间，是防「僵尸沙箱」的兜底。

7.2 QoS 分级

借鉴 Kubernetes 的 QoS 模型思想，为沙箱定义三级服务等级：

QoS 等级	特征	驱逐优先级	适用
Guaranteed	request=limit，资源独占	最低	企业付费租户、对延迟敏感任务
Burstable	request<limit，共享弹性	中	默认体验流量
BestEffort	无 request/limit 保证	最高	后台批处理、数据搬运

当节点资源压力升高，调度器按 BestEffort → Burstable → Guaranteed 的顺序驱逐。Guaranteed 沙箱几乎不被驱逐，除非节点整体健康状态恶化。

7.3 配额校验流水线

沙箱创建请求进入调度前的配额校验链：

任何一环失败即返回配额错误，避免「先分后查」造成的资源竞争窗口。

多租户配额校验伪代码

def check_quota(tenant_id: str, request: SandboxRequest) -> bool:
    tenant = quota_store.get(tenant_id)
    if tenant.active_sandboxes >= tenant.max_concurrency:
        return False
    if tenant.cpu_used + request.cpu > tenant.max_cpu:
        return False
    if tenant.memory_used + request.memory > tenant.max_memory:
        return False
    if tenant.disk_used + request.disk > tenant.max_disk:
        return False
    return True

7.4 资源回收

沙箱终止后，必须执行全链路回收：

1. 进程回收：cgroup 删除后，内核自动杀掉组内残留进程。
2. 文件系统回收：删除临时 rootfs 层、临时挂载点、容器镜像只读层引用。
3. 网络回收：释放 IP、清理 CNI 网络命名空间、回收端口。
4. 存储回收：延迟删除（滞后 5-15 分钟）以便审计取证，最终由 GC 周期清理。

回收流水线示意

回收失败必须重试并告警，因为「偷跑资源」在高并发下会快速积累，拖垮节点。

8. CPU 隔离与调度

CPU 是最核心的竞争资源。沙箱场景下的 CPU 隔离要解决三件事：配额准确性、突发处理、公平共享。

8.1 CFS 与 cpu.max

Linux 的 CFS（完全公平调度器）通过 cpu.max 的 quota period 语义做时间片限制。写入 200000 100000 表示每 100ms 周期内最多运行 200ms，即等价 2 核。

注意：quota 模型允许任务在周期内「集中使用」，可能造成瞬时延迟尖刺。例如一个 1 核限额的沙箱，可以在 100ms 内先空转 50ms、再用满 50ms，对延迟敏感的场景需要更细的调度策略。

8.2 cpuset 与 NUMA 亲和

对于数值计算类沙箱，将进程绑定到固定 CPU 集合可以减少缓存失效与迁移抖动。在多 NUMA 节点的大机器上，合理分配 cpuset 能显著提升内存带宽：

# 绑定到 NUMA 节点 0 的 CPU 0-15
echo "0-15" > /sys/fs/cgroup/agent-sandbox-42/cpuset.cpus
echo "0" > /sys/fs/cgroup/agent-sandbox-42/cpuset.mems

8.3 CPU 突发与令牌桶

生产平台常给沙箱配置「突发额度」：平时限额 0.5 核，但允许在短时间内冲到 2 核。其本质是一个令牌桶：以较低速率累积令牌，超过基线部分的运行消耗令牌，令牌耗尽即回落到基线。

这种设计兼顾成本与体验——大多数沙箱任务都有「冷启动计算密集、稳定期 CPU 空闲」的特征。

8.4 高并发下的 CPU 争抢缓解

万级并发下，即使每个沙箱都合规，节点 CPU 也可能被过度订阅。缓解手段：

• 节点超售比控制：默认 CPU 超售比不超过 3:1（总 request 与可用核之比），安全池不超售。
• CPU 抢占优先级：Guaranteed 沙箱获得更高调度权重，BestEffort 用 nice 降低优先级。
• 退避重试：调度器发现节点 CPU 持续 >85% 时，将新任务路由到其他节点。
• 告警与自动扩缩：通过 HPA/Cluster Autoscaler 联动，在 CPU 水位逼近阈值前扩容节点池。

9. 内存隔离与管理

内存是引发故障最直接的资源——OOM 会导致沙箱被杀，进而拖垮任务成功率。

9.1 内存层级限制

cgroup v2 提供两层内存控制：

• memory.max：硬上限，超出的内存分配会被拒绝，进程可能被 OOM Killer 杀掉。
• memory.high：软上限，超过后触发节流、回收，但不会立刻杀掉进程，给任务主动释放内存的机会。

推荐生产策略：max 设 2 倍 high。例如沙箱内存 request 128Mi，high 设 256Mi，max 设 512Mi。任务平时在 256Mi 内舒适运行，突发到 512Mi 仍可存活，再高就被 OOM 兜底。

设置示例

echo "268435456" > memory.high   # 256Mi
echo "536870912" > memory.max    # 512Mi

9.2 OOM 策略

cgroup 的 OOM 事件可以通过 memory.events 观测。当 oom_kill 计数增加，表明该组出现过 OOM。平台应接入事件，做以下动作：

• 记录被杀前的内存使用曲线，用于根因分析。
• 标记该租户任务为「内存异常」，下次调度时自动提升内存配额。
• 对反复 OOM 的代码模板做告警，提示可能存在内存泄漏或恶意分配。

9.3 内存压缩与交换

对高密度沙箱节点，开启内存压缩（zswap/zram）和适度 swap 能提升「超售」容忍度：

• zswap：压缩的交换缓存，介于内存与磁盘之间，减少真实 swap IO。
• zram：内存压缩块设备，适合无本地磁盘的节点。

但需注意：过度依赖压缩与 swap 会引入延迟抖动，对延迟敏感任务要限制使用。

9.4 防内存炸弹

恶意代码的经典攻击是「fork 炸弹」或「超大内存申请」。多层防线：

# 限制进程数
echo "64" > pids.max

# 限制单个进程地址空间（在沙箱内设置）
ulimit -v 536870912   # 512Mi

# 禁止过度提交超出能力的内存（宿主机内核参数）
sysctl vm.overcommit_memory=1

10. 磁盘与文件系统隔离

文件系统是智能体沙箱最频繁交互的资源，也是最容易出问题的地方：恶意代码可以写满磁盘、删除关键文件、读取敏感配置。

10.1 临时 rootfs 与只读挂载

沙箱的根文件系统应双层设计：

• 只读镜像层：包含运行时与预装库，所有沙箱共享，不可写。
• 可写临时层：tmpfs 或 overlay 上层，任务结束后整体丢弃。

对智能体代码解释器，工作目录（如 /workspace）挂载独立的 tmpfs 或限额的临时卷，防止写满系统盘。

Docker 示例

docker run \
  --read-only \
  --tmpfs /workspace:rw,size=1g,mode=1777 \
  --tmpfs /tmp:rw,size=256m \
  sandbox-image

10.2 磁盘配额

文件级配额有两种实现：

• 项目配额（Project Quota）：在 ext4/xfs 上按目录树做配额，适合 overlay 场景。
• 挂载 tmpfs/size：tmpfs 挂载时直接指定 size，天然限制上限。

代码解释器平台常用「每沙箱独立 tmpfs 工作区 + size 限制」，简单可靠。

挂载 tmpfs 限制

mount -t tmpfs -o size=1g tmpfs /var/sandbox/42/workspace

10.3 inode 与文件数限制

大模型生成的代码有时会创建海量小文件。除了容量，还要限制 inode 与文件数：

# rlimit 限制单进程打开文件数
ulimit -n 128
# 限制单目录文件数可通过内核参数或项目配额 inode 限制实现

10.4 敏感文件屏蔽

对沙箱暴露的文件系统视图，应主动屏蔽敏感路径：宿主 /proc、/sys、/etc/shadow、挂载凭据、云元数据服务（169.254.169.254）等。

• 用 hidepid 挂载 proc，限制进程信息泄露。
• 用网络策略屏蔽云元数据端点。
• 用最小 rootfs 模板避免携带无关敏感文件。

proc hidepid 挂载

mount -t proc -o hidepid=2 proc /proc

11. 网络隔离与出网控制

智能体经常需要联网（搜索、调用 API、下载依赖），但无限制的出网意味着数据外泄、内网探测、SSRF 等风险。

11.1 网络命名空间与 CNI

每个沙箱拥有独立 Network Namespace，通过 CNI（容器网络接口）插件接入虚拟网络。典型 CNI 选择：

CNI	特点	适用
Flannel	简单，VXLAN 覆盖网络	中小集群
Calico	高性能，支持网络策略	大规模、需要精细策略
Cilium	eBPF 驱动，可观测性强	安全要求高、需要网络级隔离
Bridge + iptables	原生方案	单机/小规模

11.2 出网策略：默认拒绝 + 白名单

生产级智能体平台的网络安全基线是默认拒绝所有出网流量，仅放行白名单域名/IP。这样可以：

• 阻止沙箱访问云元数据服务。
• 阻止内网横移、端口扫描。
• 阻止数据外泄到未授权端点。

Cilium 网络策略示例

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: sandbox-egress-policy
spec:
  endpointSelector:
    matchLabels:
      app: agent-sandbox
  egress:
    - toFQDNs:
        - matchName: "api.openai.com"
        - matchName: "pypi.org"
        - matchName: "files.pythonhosted.org"
    - toPorts:
        - ports:
            - port: "443"
              protocol: TCP

对于需要更细粒度控制的场景（如允许访问任意 HTTPS 但拒绝明文 HTTP），可在 L7 层代理过滤；而需要深度内容检查时，将流量引导至安全网关（类似 SWG/CASB）。

11.3 DNS 控制

DNS 是常见的隐蔽信道。沙箱应使用受控 DNS 解析器，并对解析结果做校验：

• 拒绝解析到内网/环回/元数据地址的域名（防 DNS Rebinding）。
• 记录 DNS 查询日志用于审计。
• 限制单沙箱 DNS 查询频率，防 DNS 洪水。

11.4 速率限制

对单沙箱的出网带宽与包速率做限制，防止刷流量：

# 使用 tc 或 eBPF 对 veth 设备限速
tc qdisc add dev veth-sandbox42 root tbf rate 10mbit burst 20mbit latency 50ms

12. 安全加固与逃逸防护

安全加固是纵深防御的多层叠加。即使某一层被突破，后续层仍能兜底。

12.1 内核加固

宿主机内核的安全参数直接影响所有沙箱的安全水位。关键在内核参数、安全模块与补丁三方面发力：

• 内核参数：开启 kernel.kptr_restrict、kernel.dmesg_restrict、net.ipv4.conf.all.rp_filter 等。
• 安全模块：启用 AppArmor 或 SELinux，对容器进程套用强制访问控制策略。
• 内核版本治理：保持内核在受支持且及时打安全补丁的版本；有条件可启用 grsecurity/PaX 类加固内核。

关键内核参数

sysctl -w kernel.kptr_restrict=2
sysctl -w kernel.dmesg_restrict=1
sysctl -w kernel.unprivileged_bpf_disabled=1
sysctl -w kernel.unprivileged_userns_clone=0
sysctl -w net.ipv4.conf.all.rp_filter=1

12.2 用户命名空间与 Rootless

以 rootless 方式运行沙箱运行时，是降低逃逸影响面的有效手段。原理是：沙箱内的「root」在宿主机上只是普通用户，即使逃逸，攻击者也无法直接获得宿主机 root 权限。

对 gVisor、Firecracker 这类运行时，rootless 支持已较成熟；对 Docker，可使用 rootless mode 或配合 Podman 实现。

12.3 镜像供应链安全

沙箱镜像的构建链必须可信：

• 基础镜像最小化，只包含必需组件，不携带 shell、编译器等多余工具。
• 镜像签名（cosign/notary）并在拉取时验签。
• 依赖锁定与漏洞扫描（Trivy/Grype/Snyk）纳入 CI，阻断高危依赖进入沙箱。
• 镜像内容哈希校验，防篡改。

12.4 运行时行为监测

在沙箱内部部署轻量级行为监测（如 eBPF 探针、auditd），采集异常信号：

• 异常系统调用序列（如「读 /etc/shadow 后又写网络 socket」）。
• 反弹 shell 特征（bash 以交互模式连接外网端口）。
• 批量文件加密/删除行为（勒索特征）。

这些信号汇入安全分析引擎，与规则/模型匹配后触发告警或直接终止沙箱。

12.5 逃逸后的兜底

假设最坏情况发生——沙箱逃逸拿到宿主机权限，还需有兜底：

• 节点按安全域划分，高危沙箱节点不部署敏感数据与凭证。

• 凭证不在节点本地存储，通过短期动态 Token 注入。

• 节点定期轮换、不可变基础设施（Immutable Infra）是阻断攻击者长期驻留的关键手段。节点不再接受手工打补丁或状态修改，而是通过统一的基线镜像滚动替换节点池：任何节点出现异常迹象，或存活时间超过既定轮换周期（如 12-24 小时），控制面便自动驱逐任务、隔离节点并整机销毁重建。新节点从签名验证的镜像冷启动，不携带历史凭证、残留数据与运行期配置，从根本上压缩攻击者利用已攻陷节点横向移动的时间窗口。同时，节点池采用小批次滚动替换并配合重建后自动健康检查，确保轮换过程不降低可用性。

• 单节点失陷影响面控制在最小（配几十个沙箱，而非上千个）。

安全加固检查清单

检查项	检查要点	验证方式 / 预期
内核参数加固	kptr_restrict=2、dmesg_restrict=1、非特权 BPF/USERNS 禁用等	节点初始化脚本断言 sysctl 输出
强制访问控制	AppArmor/SELinux 策略已对沙箱进程生效	测试读取宿主机敏感文件应被拒绝
运行时版本治理	runc/gVisor/Firecracker/Kata 处于受支持版本且无已知高危漏洞	漏洞扫描结果 + 版本台账
Capabilities 最小化	所有沙箱默认 cap-drop=ALL，仅按任务类型授权	进程 CapEff 检查与镜像审计
seccomp 过滤	默认拒绝动作，ptrace/mount/bpf 等危险调用被阻断	运行恶意探针验证系统调用返回错误
Rootless 与用户命名空间	宿主运行用户非 root，UID/GID 映射正确	逃逸测试无法获得宿主 root
镜像供应链	基础镜像最小化、签名验签、依赖无高危漏洞	Trivy/Grype 扫描 + cosign 验签
文件系统隔离	根文件系统只读，仅 tmpfs/临时卷可写，敏感路径屏蔽	尝试写 /etc 或读 /etc/shadow 被拒绝
出网控制	默认拒绝出网，仅白名单域名/端口可达，DNS 受控	访问内网与元数据地址应失败
行为监测与审计	eBPF/auditd 采集异常行为，审计日志集中留存并可追溯	模拟反弹 shell / 批量加密触发告警

13. 多租户架构与计费

多租户是生产级平台的标配，资源隔离必须与租户隔离、计费计量联动。

13.1 租户隔离维度

维度	隔离手段	说明
计算隔离	独立 cgroup/VM	租户间 CPU、内存互不影响
网络隔离	独立 NetworkPolicy/子网	租户流量不可互相访问
存储隔离	独立存储桶/目录配额	数据物理或逻辑隔离
身份隔离	IAM + 短期凭证	租户 A 无法访问租户 B 资源
审计隔离	独立审计日志流	合规与溯源

13.2 租户等级与资源画像

典型的租户分级：

等级	并发上限	运行时	资源上限（CPU/内存/磁盘）	最大运行时长	网络权限	API 频率	数据驻留
Free	2	gVisor（L1）	0.5 核 / 512Mi / 1Gi	15 分钟	白名单域名	60 次/分	共享对象存储（服务端加密）
Pro	20	gVisor（L1）	2 核 / 2Gi / 10Gi	2 小时	白名单 + 自定义域名	600 次/分	独立对象存储桶
Enterprise	200+	Firecracker（L2）	8 核 / 16Gi / 100Gi	8 小时（可定制）	自定义策略 / 专线 / VPN	自定义/按合同	独立桶 + VPC 打通 / 私有化部署

13.3 计费与计量

计量数据来自 cgroup 记账与平台事件。关键指标：

• CPU 核秒、内存 Gi 秒。
• 沙箱运行时长（墙面时间）。
• 网络出流量。
• 磁盘写入量（临时卷）。
• API 调用次数（模型侧费用另计）。

cgroup 读取 CPU 使用量

cat /sys/fs/cgroup/agent-sandbox-42/cpu.stat
# usage_usec 累计 CPU 微秒数

平台侧以「计费事件流」上报用量，异步聚合出账单。计量要具备幂等与防丢失能力（如按唯一事件 id 去重）。

租户配额校验与计费上报伪代码

下面的示例把「配额校验 → 用量聚合 → 计费上报」串成一个可落地的闭环：

class TenantQuotaChecker:
    """创建沙箱前校验租户配额，重点是并发数与资源总量。"""

    def check_and_reserve(self, tenant_id: str, request: SandboxRequest) -> bool:
        tenant = quota_store.get(tenant_id)
        policy = tenant.policy

        # 1. 并发数检查：已运行沙箱数 + 本次新增不得超过租户等级上限
        if tenant.active_sandboxes + request.replicas > policy.max_concurrency:
            audit.record("quota.rejected", tenant_id, reason="concurrency_exceeded")
            return False

        # 2. 资源用量聚合：从近期运行记录汇总租户当前资源占用
        usage = metering.aggregate(tenant_id)

        # 3. 资源增量检查：本次请求折算成 CPU/内存/磁盘增量后逐项校验
        delta = {
            "cpu_millicores": request.quota.cpu_cores * 1000,
            "memory_mb": request.quota.memory_mb,
            "disk_mb": request.quota.disk_mb,
        }
        for dim, limit in [("cpu_millicores", policy.max_cpu_millicores),
                           ("memory_mb", policy.max_memory_mb),
                           ("disk_mb", policy.max_disk_mb)]:
            if usage[dim] + delta[dim] > limit:
                audit.record("quota.rejected", tenant_id, reason=f"{dim}_exceeded")
                return False

        # 4. 原子预占：并发计数与资源预算一次性预留，避免并发请求绕过校验
        return quota_store.reserve(tenant_id, delta, replicas=request.replicas)


class MeteringCollector:
    """任务结束后，从 cgroup 记账与平台事件聚合实际资源用量。"""

    def aggregate(self, tenant_id: str) -> dict:
        rows = metric_store.query(tenant_id=tenant_id, window_seconds=3600)
        return {
            "cpu_millicores": sum(r.cpu_millicores for r in rows),
            "memory_mb": max(r.memory_mb for r in rows),          # 峰值内存，或按 Gi 秒累计
            "disk_mb": max(r.disk_mb for r in rows),
            "network_egress_mb": sum(r.network_egress_mb for r in rows),
            "sandbox_seconds": sum(r.runtime_seconds for r in rows),
        }


class BillingEventPublisher:
    """把聚合结果折算为计费量，并以幂等事件异步上报。"""

    def publish(self, tenant_id: str, usage: dict) -> None:
        event = {
            "event_id": generate_ulid(),
            "tenant_id": tenant_id,
            "usage": {
                "cpu_cores_seconds": usage["cpu_millicores"] / 1000 * usage["sandbox_seconds"],
                "memory_gi_seconds": usage["memory_mb"] / 1024 * usage["sandbox_seconds"],
                "network_egress_bytes": usage["network_egress_mb"] * 1024 * 1024,
                "disk_write_bytes": usage["disk_mb"] * 1024 * 1024,
                "sandbox_seconds": usage["sandbox_seconds"],
            },
            # 幂等键：同一租户同一计费周期只落地一次事件，消费端按它去重
            "idempotency_key": f"metering:{tenant_id}:{usage['period_start']}",
            "timestamp": utc_now_iso(),
        }
        event_bus.publish(
            topic="billing.events",
            key=event["idempotency_key"],
            value=json.dumps(event),
            dedup=True,
            retry=3,
        )

三个环节的要点：

• 并发数检查：先比较 active_sandboxes + request.replicas 与租户等级上限，再做原子预占，防止「先查后建」竞争窗口导致超卖。
• 资源用量聚合：按计费周期聚合 CPU、内存、磁盘、网络与运行时长；内存/磁盘可用峰值或累计量，需与定价模型对齐。
• 计费事件上报：统一折算为 CPU 核秒、内存 Gi 秒等计费量，通过 idempotency_key 和消费端去重保证幂等与防丢失。

14. 高并发性能优化

高并发不是简单地把沙箱数量堆上去，而是要在「启动速度、调度效率、资源密度、安全开销」之间找到最优平衡。

14.1 冷启动优化

冷启动延迟是高并发平台用户体验的头号杀手。优化手段分层递进：

镜像层：

• 精简镜像：只装任务必需依赖，基础 Python 沙箱镜像控制在 200-400Mi。
• 分层缓存：把常用依赖单独分层，节点预热时只需拉取冷层。
• 懒加载（lazy-pulling）：如 Nydus、eStargz，按需拉取镜像层，不等待全量下载。

运行时层：

• 预热池：预先创建一批空闲沙箱，任务到达时直接分配，把冷启动变成「热启动」。空闲池按流量预测动态调整水位。
• 快照恢复：Firecracker 支持内存快照，从快照恢复到可服务状态仅需数毫秒。
• 模板克隆：使用 fork 语义克隆进程模板（如 Cloudflare 的 isolates、Wasm 的实例化）。

调度层：

• 节点亲和：把常用镜像固定在部分节点，减少跨节点拉取。
• 预热编排：流量高峰前批量预热节点池。

下面的流程图概括了冷启动优化的分层手段：

14.2 热启动与空闲池

预热池是「以资源换延迟」的典型设计。水位公式：

空闲池目标大小 = 预测请求速率 × 平均冷启动时间 + 安全余量

例如请求速率 100 个/秒，平均冷启动 1 秒，则空闲池至少 100 个实例，加 20% 余量即 120 个。

空闲池管理器伪代码

class WarmPoolManager:
    def tick(self):
        current = len(self.pool)
        target = self.predict_demand() * self.cooldown_time * 1.2
        if current < target:
            self.scale_up(target - current)
        elif current > target * 1.5:
            self.scale_down(current - int(target))

14.3 资源密度优化

提高单节点沙箱密度的关键在「削减每个沙箱的固定开销」：

• 共享镜像层：所有沙箱共享只读镜像层，只付出 tmpfs/overlay 增量开销。
• 容器 vs 进程：对极轻量任务用「多沙箱共享一个容器，靠进程级隔离」提升密度，但需权衡安全。
• 内存去重：KSM（内核同页合并）可合并相同内存页，但会引入侧信道风险，对高安全池应关闭。

14.4 调度效率

调度器面对万级并发，性能瓶在「状态存储与决策延迟」。优化方向：

• 内存态调度：活跃调度数据常驻内存（如 Redis/in-process），落库仅做异步持久化。
• 批量调度：把同时到达的请求打包决策，摊薄单次开销。
• 分层调度：先做粗粒度节点打分（CPU/内存/磁盘），再做精确装箱（bin packing）。
• 异步任务模型：创建沙箱是耗时操作，调度器采用异步回调，避免阻塞 API 响应。

15. 可观测性与日志审计

「无法观测的隔离等于没有隔离」。高并发平台的观测体系要覆盖沙箱内、节点、调度面三个层次。

15.1 三层观测模型

层次	核心指标	采集方式
沙箱层	CPU/内存/IO/进程数/网络流量	cgroup 导出器、eBPF
节点层	CPU/内存/磁盘/连接数/内核事件	node_exporter、eBPF
调度层	队列深度/调度延迟/失败率/资源水位	应用埋点、OpenTelemetry

下面用 Mermaid 图把三层观测与汇聚链路串起来：

15.2 关键指标与告警

黄金指标：

• 沙箱创建成功率（>99.9%）
• 沙箱创建 P50/P99 延迟
• 沙箱 OOM 率
• 沙箱 CPU 节流率
• 节点资源水位（CPU/内存/磁盘 IOWait）
• 调度队列深度与等待时间
• 沙箱逃逸/安全事件数

告警阈值示例

alerts:
  - name: sandbox_create_p99_high
    expr: sandbox_create_duration_seconds{p99} > 5
    severity: warning
  - name: node_memory_pressure
    expr: node_memory_utilization > 0.9
    severity: critical
  - name: sandbox_oom_rate_high
    expr: sandbox_oom_count / sandbox_total > 0.05
    severity: warning

15.3 日志审计

审计日志需覆盖沙箱全生命周期与关键动作：

• 生命周期事件：创建者、创建时间、镜像版本、运行时类型、配额、终止原因。
• 命令级审计：沙箱内执行的 shell 命令（若启用了命令记录以排查问题）。
• 文件访问审计：对敏感路径的读写记录。
• 网络审计：出网连接目标、流量大小。

日志采用「本地缓冲 + 集中上报」，避免沙箱高并发时的日志洪峰打挂采集端。审计日志保留周期按合规要求（如 180 天），并做防篡改存储。

审计日志结构示例

{
  "event_id": "evt_01H8K3N9X",
  "tenant_id": "tenant_123",
  "sandbox_id": "sbx_42",
  "event_type": "sandbox.terminated",
  "reason": "timeout",
  "resource_usage": {"cpu_seconds": 12.3, "memory_gi_seconds": 0.8},
  "created_at": "2026-08-22T14:32:10Z"
}

16. 故障隔离与自愈

高并发平台的故障不可避免，关键在于「故障不扩散、系统能自愈」。

16.1 故障域划分

从物理到逻辑逐层划分故障域：

• 节点：单节点故障只影响其上沙箱（任务可重调度）。
• 可用区（AZ）：跨 AZ 部署，AZ 故障时流量切到其他 AZ。
• 运行时池：gVisor 池故障不影响 Firecracker 池。
• 控制面：调度器多副本，状态存储在分布式共识系统（etcd）中。

16.2 健康检查与熔断

• 节点健康检查：周期性探测节点的运行时健康、磁盘 IO、内核日志异常。
• 调度熔断：节点连续出错达到阈值（如 5 分钟内 3 次沙箱创建失败）时，停止向该节点调度新任务，触发节点修复/替换。

16.3 任务级重试

沙箱任务应设计为幂等可重试。当沙箱因节点故障、OOM、逃逸拦截等原因终止时，调度器按策略重试：

retry_policy:
  max_attempts: 3
  backoff: exponential   # 1s, 2s, 4s
  retry_on: [node_failure, oom, network_error]
  no_retry_on: [security_violation, quota_exceeded]

安全违规与配额超限不应重试，避免放大问题。

16.4 自动扩缩容

基于前面定义的黄金指标，联动水平（HPA）与垂直（VPA）自动扩缩：

• 节点池扩缩：CPU/内存水位连续超过阈值，触发新节点接入；水位回落后，对空节点优雅下线。
• 控制面扩缩：调度队列深度持续升高，扩容调度器副本。
• 预热池水位：跟随实时的请求速率预测动态调整。

扩缩容决策示例

IF avg_pool_cpu_util > 0.75 FOR 5min THEN scale_up(nodes=+2)
IF avg_pool_cpu_util < 0.30 FOR 15min THEN scale_down(nodes=-1)

17. 工程实践：代码与配置示例

这一节给出从调度 API 到沙箱运行时的一些可直接落地的工程片段。

17.1 沙箱创建 API 设计

POST /v1/sandboxes
{
  "tenant_id": "tenant_123",
  "task_type": "code_interpreter",
  "runtime": "gvisor",
  "image": "registry.example.com/sandbox/python:3.11-minimal",
  "quota": {
    "cpu_cores": 1.0,
    "memory_mb": 512,
    "disk_mb": 1024,
    "wall_time_seconds": 600,
    "max_processes": 64
  },
  "network": {
    "mode": "whitelist",
    "allowed_domains": ["pypi.org", "files.pythonhosted.org", "api.example.com"]
  },
  "env": {
    "WORKSPACE_ID": "ws_456"
  },
  "idempotency_key": "req_01H8K3N9X"
}

用 idempotency_key 保证网络重试不重复创建沙箱。

17.2 调度器核心决策伪代码

def schedule(request: SandboxRequest) -> Node:
    candidates = filter_nodes(
        runtime=request.runtime,
        cpu_available=request.quota.cpu_cores,
        memory_available=request.quota.memory_mb,
        healthy=True,
    )
    scored = [
        (score_node(n, request, image_cache), n)
        for n in candidates
    ]
    # 选得分最高的节点，装箱策略可换成首次适应/最佳适应
    return max(scored, key=lambda x: x[0])[1]

def score_node(node, request, image_cache):
    score = 0.0
    score += (node.cpu_available / node.cpu_total) * 40
    score += (node.memory_available / node.memory_total) * 40
    score += (1 - node.sandbox_count / node.sandbox_capacity) * 20
    if image_cache.has(request.image, node):
        score += 15  # 镜像命中加成
    return score

17.3 gVisor 运行时集成

用 Docker 直接跑 runsc（gVisor）运行时：

# 安装 runsc 并注册为 Docker runtime
/usr/local/bin/runsc install

# 使用 gVisor 运行时沙箱
docker run \
  --runtime=runsc \
  --cap-drop=ALL \
  --security-opt=seccomp=default \
  --memory=512m \
  --cpus=1.0 \
  --read-only \
  --tmpfs /workspace:rw,size=1g \
  registry.example.com/sandbox/python:3.11-minimal

Kubernetes 中通过 RuntimeClass 指定：

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
spec:
  runtimeClassName: gvisor
  containers:
    - name: sandbox
      image: registry.example.com/sandbox/python:3.11-minimal
      resources:
        limits:
          cpu: "1"
          memory: "512Mi"
          ephemeral-storage: "1Gi"

17.4 Firecracker 集成示意

Firecracker 通过 REST API 管理微虚拟机。核心流程：

# 启动 Firecracker 进程
./firecracker --api-sock /tmp/firecracker.sock

# 配置 guest 内核与 rootfs
curl --unix-socket /tmp/firecracker.sock -X PUT \
  http://localhost/boot-source \
  -H 'Content-Type: application/json' \
  -d '{"kernel_image_path": "/opt/vmlinux", "boot_args": "console=ttyS0 reboot=k panic=1"}'

curl --unix-socket /tmp/firecracker.sock -X PUT \
  http://localhost/drives/rootfs \
  -H 'Content-Type: application/json' \
  -d '{"drive_id": "rootfs", "path_on_host": "/opt/rootfs.ext4", "is_root_device": true, "is_read_only": false}'

# 启动实例
curl --unix-socket /tmp/firecracker.sock -X PUT \
  http://localhost/actions \
  -H 'Content-Type: application/json' \
  -d '{"action_type": "InstanceStart"}'

17.5 Wasm 沙箱示例（wasmtime）

对于纯计算型工具调用，Wasm 提供极快的隔离：

use wasmtime::{Engine, Module, Store, Config};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // 配置资源限制
    let mut config = Config::new();
    config.consume_fuel(true);          // 开启燃料计量
    config.max_wasm_stack(1 << 20);     // 1Mi 栈

    let engine = Engine::new(&config)?;
    let module = Module::from_file(&engine, "tool.wasm")?;
    let mut store = Store::new(&engine, ());
    store.set_fuel(1_000_000)?;         // 燃料上限，防死循环
    // ... 实例化并调用
    Ok(())
}

18. 压测与容量规划

生产上线前必须通过系统性压测验证隔离有效性与容量边界。

18.1 压测维度

维度	测试内容	目标
创建吞吐	持续创建/销毁沙箱	验证调度器与运行时吞吐
资源隔离	恶意资源滥用沙箱	验证配额与驱逐有效
逃逸测试	运行已知逃逸 payload	验证安全边界
并发极限	万级并发运行	找系统瓶颈
故障注入	杀掉节点、断网、磁盘写满	验证自愈能力

18.2 压测工具与脚本

使用 locust/k6 模拟沙箱创建负载：

# locustfile.py
from locust import HttpUser, task, between

class SandboxUser(HttpUser):
    wait_time = between(0.1, 0.5)

    @task
    def create_sandbox(self):
        self.client.post("/v1/sandboxes", json={
            "tenant_id": "loadtest",
            "runtime": "gvisor",
            "image": "registry.example.com/sandbox/python:3.11-minimal",
            "quota": {"cpu_cores": 0.5, "memory_mb": 256},
        })

18.3 容量规划模型

容量规划的基本公式：

需要节点数 = 峰值并发沙箱数 × 单沙箱资源请求 / 单节点可用资源 / 目标资源利用率

示例：峰值 5000 并发，每沙箱 request 0.5 核/512Mi，单节点 64 核/256Gi，目标利用率 70%，CPU 维度需 5000×0.5/(64×0.7)≈56 节点；内存维度需 5000×512Mi/(256Gi×0.7)≈14 节点。取 CPU 维度为主约束，预留 20% 冗余，约 68 节点。

还要考虑超售比：若允许 CPU 超售 2x，可减至 34 节点，但要配合强驱逐与监控策略。

19. 总结与演进路线

19.1 核心结论

智能体沙箱的高并发资源隔离，本质是在回答三个问题：

1. 隔离什么：CPU、内存、磁盘、网络、进程、文件系统、系统调用——每一层都要有边界。
2. 隔离多强：从进程级到微虚拟机级，安全与性能是一对持续博弈的变量，生产级平台应多级并存、智能路由。
3. 如何高并发：无状态设计、预热池、异步调度、自动扩缩、故障域隔离——让平台在万级并发下稳定、可回收、可观测。

没有银弹。真正的生产级能力，来自对每一层机制的扎实运用与对失败场景的持续演练。

19.2 演进路线

平台建设建议分阶段推进：

阶段一：用 runc 容器 + cgroup 快速建立 MVP，验证业务闭环。
阶段二：对不可信代码解释器替换为 gVisor，建立安全基线。
阶段三：引入 Firecracker 高隔离池，实现按租户智能路由。
阶段四：完善多租户、计量、审计、自动扩缩容，进入规模化运营。
阶段五：引入行为分析模型，对沙箱运行时行为打分，动态调整隔离等级——朝「自适应沙箱」演进。

19.3 未来方向

• WebAssembly 系统接口（WASI）：让 Wasm 从纯计算走向文件、网络等系统能力，成为新的轻量隔离标准。
• eBPF 深度观测：用 eBPF 在零侵入前提下实现更细粒度的沙箱行为监测与网络策略。
• 机密计算：结合 TEE（如 Intel TDX、AMD SEV）保护沙箱内数据，抵抗更强的攻击者。
• AI 原生安全：用模型检测恶意代码模式、异常行为序列，让隔离策略从静态规则走向动态自适应。

智能体沙箱是 AI 安全的第一道物理边界，也是 AI 应用规模化落地的信任基石。把资源隔离做到生产级，不仅需要工程深度，更需要持续的安全敬畏。