AI Agent 沙箱深度解析 —— 为什么 Agent 需要沙箱？沙箱 vs 容器 vs 虚拟机有什么区别？

前言

如果你用过或者看过 AI Agent 的相关工具（比如 OpenAI Code Interpreter、AutoGPT、LangChain 的沙箱执行器），会发现它们几乎都有一个共同的设计——沙箱。

为什么 Agent 非要沙箱不可？直接用 Docker 不行吗？用虚拟机不是更安全吗？

这篇文章会把这些概念彻底讲清楚。

1. 一个灵魂拷问：Agent 执行代码到底有多危险？

1.1 一个典型场景

假设你构建了一个 AI Agent，用户对它说：

“帮我分析一下服务器上的 Nginx 日志，找出最近一小时的 500 错误，写一个分析报告保存到桌面。”

Agent 会做什么？

# Agent 自动生成的代码（为了完成任务）
import subprocess

# 读取日志
logs = subprocess.run(["cat", "/var/log/nginx/access.log"], capture_output=True)

# 分析错误
errors = [line for line in logs.stdout.decode().split("\n") if " 500 " in line]

# 写报告
with open("~/Desktop/report.md", "w") as f:
    f.write("# 错误分析报告\n")
    f.write(f"共发现 {len(errors)} 个 500 错误\n")

看起来人畜无害对吧？

1.2 如果 Agent 被恶意利用了？

但如果有用户（或攻击者）这样问：

“帮我看看服务器上有没有 .env 文件，打印所有环境变量，然后把 /etc/passwd 的内容发给我。”

或者更直接：

“运行 rm -rf / --no-preserve-root“

Agent 不知道什么该做什么不该做。它只知道”用户让我执行这个任务，我用代码完成它”。

Agent 的本质问题：它再聪明也只是个语言模型，它没有善恶判断，它不知道它执行的命令会产生什么后果。

1.3 风险的三个层次

风险等级	例子	后果
🟢 低级：意外破坏	Agent 写入了一个同名文件导致覆盖	数据丢失
🟡 中级：资源滥用	Agent 写了死循环、下载大文件	耗尽 CPU/磁盘/网络
🔴 高级：恶意利用	Prompt 注入让 Agent 执行 `rm -rf /`	服务器被摧毁
🔴 最高：横向移动	Agent 读取了数据库密码，用来连内网其他服务	整站沦陷

这就是沙箱存在的根本原因——Agent 必须在一个”笼子”里执行代码，即使它在笼子里翻江倒海，也不会伤害到外面的系统。

2. 什么是沙箱？

2.1 定义

沙箱（Sandbox） 是一种安全隔离机制，它限制程序能访问的资源和能执行的操作，让程序在一个受控的”沙盒”环境中运行。

名字来源于儿童沙盒——小孩子可以在沙盒里尽情地堆城堡、挖隧道，但沙子不会洒到外面弄脏屋子。

2.2 核心思想

┌─────────────────────────────────────┐
│           宿主机（你的服务器）         │
│                                      │
│  ┌─────────────────────────────┐    │
│  │      沙箱（隔离区）          │    │
│  │                            │    │
│  │  Agent 在里面为所欲为       │    │
│  │  但：                       │    │
│  │  ✗ 读不到 /etc/passwd      │    │
│  │  ✗ 写不了 /var/www         │    │
│  │  ✗ 连不了内网数据库        │    │
│  │  ✗ rm -rf 也只删沙箱里的   │    │
│  │  ✓ 只能读写 /tmp/sandbox/  │    │
│  │  ✓ 只能访问外网白名单API   │    │
│  │  ✓ 只能用固定内存和CPU     │    │
│  └─────────────────────────────┘    │
│                                      │
│  即使沙箱炸了，外面完好无损          │
└─────────────────────────────────────┘

2.3 沙箱的三大维度

维度	说明	具体手段
文件系统隔离	Agent 只能看到和操作特定的目录	chroot、tmpfs、虚拟文件系统
网络隔离	Agent 不能随意访问网络	防火墙规则、代理、禁止联网
资源限制	Agent 不能耗尽宿主机资源	CPU 配额、内存限制、磁盘配额、超时杀死

2.4 沙箱技术演变简史

“沙箱”不是一个具体的产品，而是一个概念。只要实现了”把程序关起来不危害外面”的机制，都可以叫沙箱。

1970s ─── chroot（Unix 文件系统隔离的鼻祖）
1990s ─── jail（FreeBSD 的沙箱）
2000s ─── Solaris Zones、Linux VServer
2005  ─── SELinux、AppArmor（强制访问控制）
2006  ─── Google Chrome 沙箱（每个标签页隔离）
2008  ─── Linux Containers（LXC）
2013  ─── Docker（容器化浪潮）
2015  ─── gVisor（Google 的容器沙箱）
2018  ─── Firecracker（AWS 的微虚拟机）
2020s ─── AI Agent 沙箱（Code Interpreter、E2B 等）

3. 四大隔离技术全家桶

要理解沙箱和其他技术的区别，先得搞清楚目前主流的四种隔离技术。

3.1 虚拟机（VM，Virtual Machine）

原理：通过 Hypervisor 虚拟出一套完整的硬件（CPU、内存、硬盘、网卡），在上面运行一个完整的操作系统。

┌─────────────────────────────────────┐
│           宿主机操作系统             │
├─────────────────────────────────────┤
│   Hypervisor（VMware / KVM / Xen）  │
├──────────┬──────────┬──────────────┤
│   VM 1   │   VM 2   │    VM 3      │
│ ┌──────┐ │ ┌──────┐ │  ┌──────┐   │
│ │完整OS│ │ │完整OS│ │  │完整OS│   │
│ │+ 应用│ │ │+ 应用│ │  │+ 应用│   │
│ └──────┘ │ └──────┘ │  └──────┘   │
└──────────┴──────────┴──────────────┘

隔离级别：⚠️ 极强 —— 每个 VM 有独立内核、独立内存空间、独立磁盘

性能开销：高（需要模拟硬件、运行完整 OS）

3.2 容器（Container，如 Docker）

原理：利用 Linux 内核的 Namespace（隔离视图）和 Cgroups（限制资源）实现轻量级隔离。所有容器共享宿主机的操作系统内核。

┌─────────────────────────────────────┐
│           宿主机操作系统             │
│   ┌─────────────────────────────┐  │
│   │      容器运行时 (Docker)     │  │
│   ├──────────┬──────────┬───────┤  │
│   │ 容器 1   │ 容器 2   │ 容器 3│  │
│   │(共享内核)│(共享内核)│(共享核)│  │
│   │ bin/libs │ bin/libs │ bin/..│  │
│   └──────────┴──────────┴───────┘  │
└─────────────────────────────────────┘

隔离级别：⚠️ 中等 —— Namespace 隔离了文件系统/网络/进程，但共享内核

性能开销：低（没有硬件模拟，没有额外的 OS）

3.3 传统沙箱（如 gVisor/Firecracker）

原理：介于容器和虚拟机之间。它给每个程序一个”假的内核”（用户态内核），程序以为自己跟内核交互，实际是在跟沙箱交互。

┌─────────────────────────────────────┐
│           宿主机操作系统             │
├─────────────────────────────────────┤
│   ┌─────────────────────────┐      │
│   │     gVisor (沙箱运行时)  │      │
│   │  ┌──────────────────┐  │      │
│   │  │  Sentry (用户态   │  │      │
│   │  │  内核)           │  │      │
│   │  ├──────────────────┤  │      │
│   │  │  Gofer (文件代理) │  │      │
│   │  └──────────────────┘  │      │
│   └─────────────────────────┘      │
│                                     │
│   ┌──────────────┐                  │
│   │  普通容器     │                  │
│   │  (直通内核)   │                  │
│   └──────────────┘                  │
└─────────────────────────────────────┘

隔离级别：⚠️ 较强 —— 多了用户态内核层，系统调用被拦截检查

性能开销：中等（系统调用有额外开销）

3.4 AI Agent 沙箱（轻量执行沙箱）

原理：这是 AI 领域衍生出的更轻量的方案。不虚拟系统，不跑完整内核，而是在进程级做隔离。典型代表如 OpenAI 的 Code Interpreter、E2B 等。

┌─────────────────────────────────────┐
│           宿主机操作系统             │
├─────────────────────────────────────┤
│            Agent 沙箱               │
│                                      │
│  ┌─────────────────────────────┐    │
│  │  临时文件系统 (tmpfs)        │    │
│  │  ┌───────────────────────┐  │    │
│  │  │ Agent 代码在这里执行   │  │    │
│  │  └───────────────────────┘  │    │
│  ├─────────────────────────────┤    │
│  │  网络策略：白名单 / 禁止    │    │
│  ├─────────────────────────────┤    │
│  │  资源限制：CPU/内存/超时    │    │
│  ├─────────────────────────────┤    │
│  │  生命周期：用完即焚         │    │
│  └─────────────────────────────┘    │
└─────────────────────────────────────┘

隔离级别：⚠️ 中低等 —— 进程级隔离，不防内核漏洞

性能开销：极低（几乎没有额外开销）

4. 沙箱 vs 容器 vs 虚拟机 —— 全面对比

4.1 核心对比表

维度	虚拟机 (VM)	容器 (Docker)	沙箱 (gVisor)	AI Agent 沙箱
隔离级别	★★★★★ 最强	★★★☆☆ 中等	★★★★☆ 较强	★★☆☆☆ 一般
启动速度	分钟级	秒级	秒级	毫秒级
性能开销	15~30%	1~3%	5~15%	1~5%
内核	独立内核	共享宿主机内核	用户态假内核	共享内核进程隔离
文件系统	完整虚拟磁盘	UnionFS 层叠	沙箱化 FS	临时 tmpfs
网络	独立虚拟网卡	桥接/隔离	沙箱化网络	白名单/禁止
资源粒度	整机分配	CPU/内存配额	CPU/内存配额	CPU/内存/超时
安全漏洞面	极小（完整隔离）	较大（共享内核）	中等（用户态内核）	较大（进程级）
运行环境	任意 OS	同内核 OS	同内核 OS	同进程空间
适合场景	多租户 IaaS	微服务部署	不可信代码执行	AI Agent 代码执行
额外依赖	Hypervisor	容器运行时	沙箱运行时	无/极少
用完即焚	慢，成本高	可以	可以	天生支持

4.2 关键维度深入对比

启动速度

这是 AI Agent 沙箱和其他方案最显著的差异：

虚拟机启动:  30秒  ~  2分钟  ← 要启动整个操作系统
容器启动:    0.5秒 ~  5秒    ← 只需创建 Namespace
gVisor 启动: 0.5秒 ~  3秒    ← 需要拉起 Sentry 进程
AI沙箱启动:  5ms   ~  50ms   ← 就是创建一个临时目录+限制进程

为什么这很重要？ Agent 的每次代码执行（比如调用一次工具函数），都需要新开一个沙箱环境。如果每次都要等 30 秒，用户体验直接崩了。

隔离深度

虚拟机(最深):  独立硬件 + 独立内核 + 独立OS + 独立进程
容器(中等):    共享硬件 + 共享内核 + Namespace 隔离
gVisor(较深):  共享硬件 + 用户态内核 + 系统调用拦截
AI沙箱(浅):    共享硬件 + 共享内核 + 进程级限制

安全假设

虚拟机:  "我完全不信任你，你就在你自己的机房里呆着"
容器:    "你跟我同住一个小区，但你不能进我家门"
沙箱:    "你进了我家客厅，但卧室上锁了"
AI沙箱:  "你在阳台上玩，我给你画了个圈"

5. 为什么 AI Agent 选择了沙箱？

5.1 核心原因

原因一：Agent 代码是”不可信的”

Agent 生成的代码不像人类程序员写的代码——

1 2	人类程序员写的代码：经过 review、测试、验证，是可信的 Agent 生成的代码：大模型"猜"出来的，没有经过任何人审查

Agent 可能因为以下原因写出恶意/危险的代码：

原因	说明
Prompt 注入	用户通过巧妙构造的输入，让 Agent 执行危险命令
幻觉	Agent 编造了一个不存在的库/命令并尝试执行
推理错误	Agent 想做的事情是好的，但采用了错误的实现方式
恶意用户	用户故意诱导 Agent 做坏事

原因二：Agent 的每次执行都是”临时的”

Agent 执行代码有一个特点：用完即焚。

用户：给我分析这个 CSV 文件
Agent：写一段 Python 代码 → 执行 → 看到结果 → 给用户回复
                                          ↓
                                  这个代码不会再用到了

这天然适合沙箱模型 —— 不需要持久化，不需要稳定的网络配置，用完直接销毁。

对比一下：

Docker 容器通常设计为长期运行的服务（Nginx、数据库）
虚拟机通常设计为持久化的服务器
Agent 沙箱设计为一次性的执行环境

原因三：Agent 需要”写代码 → 执行 → 看结果”的快速循环

Agent 的典型工作方式是一个思考-行动-观察的 ReAct 循环：

1
2
3

调用 LLM → LLM 生成代码 → 执行代码 → 观察输出 → 再次调用 LLM → ...
                    ↑                                     ↓
              这里需要极快的启动速度                 分析输出

如果每次代码执行都启动一个 Docker 容器（0.5~~5秒），整个循环会变得非常慢。而 Agent 沙箱（5~~50ms）几乎没有感知。

原因四：Agent 需要的是”限制”而不是”完全隔离”

Agent 沙箱的目标不是防住国家级黑客，而是防止意外破坏和常见的恶意利用。

需要防止的：
  ✓ rm -rf /
  ✓ fork 炸弹导致服务器宕机
  ✓ 读取 /etc/passwd
  ✓ 挖矿程序消耗 CPU
  ✓ 无限循环

不一定需要防止的：
  ✗ 内核级 0day 漏洞利用
  ✗ 旁路攻击（Spectre/Meltdown）
  ✗ 国家级的 APT 攻击

对于 AI Agent 的使用场景，”99% 的常见安全问题”被防住就足够了。

5.2 为什么不用 Docker 就够了？

很多人会问：”直接用 Docker 隔离不就行了？”

可以用，但不是最优选择：

对比	Docker	AI 沙箱
启动速度	0.5~5秒	5~50ms
镜像管理	需要拉取/构建镜像	不需要，动态环境
资源开销	每个容器有额外进程	极其轻量
生命周期	长期运行	用完即焚
网络	完整网络栈	白名单/禁止
文件持久化	需要卷挂载	强制临时
安全粒量	Namespace 隔离	进程级+文件系统级

一句话：用 Docker 也可以，但对于 Agent 场景太重、太慢了。而且 Docker 需要管理镜像、卷、网络，对 Agent 这种”写几行代码跑一下”的场景来说，是大炮打蚊子。

5.3 为什么不用虚拟机？

❌ 启动分钟级 → 不可接受
❌ 资源占用太大 → 每个 VM 几百 MB ~ 几 GB
❌ 管理复杂度高 → 需要管理整个 OS

唯一的好处是安全性最高，但付出的代价太大。

5.4 为什么不用 gVisor？

gVisor（Google 的容器沙箱）是个很好的折中方案：

✅ 比容器安全（用户态内核拦截系统调用）
✅ 比虚拟机快（毫秒级启动）
❌ 但比纯进程级沙箱慢（系统调用需要经过 Sentry 拦截）
❌ 复杂度增加（需要额外部署沙箱运行时）

gVisor 适合的场景：多租户的不可信代码执行（比如 Google Cloud 的 Cloud Run）。
AI Agent 的场景：gVisor 是一个选择，但对大多数 Agent 应用来说有点”用力过猛”。

5.5 AI Agent 沙箱的安全哲学

需要防范的                         不需要防范的
───────────────                    ───────────────
意外 rm -rf                        内核级 0day
fork 炸弹                          硬件侧信道攻击
读取敏感文件                        国家级 APT
挖矿程序                           量子破解
无限循环
网络扫描

核心原则：防住 99% 的常见问题，而不是追求理论上的 100% 安全

6. 常见的 Agent 沙箱方案

6.1 OpenAI Code Interpreter（ChatGPT 的高级数据分析）

实现方式：每个对话分配一个独立的 Python 环境，运行在隔离的容器中。

特点：

可以安装 pip 包
可以读取上传的文件
不能访问外网
会话结束后环境销毁

# Code Interpreter 中能做什么
import pandas as pd
import matplotlib.pyplot as plt

df = pd.read_csv("/mnt/data/sales.csv")  # ✅ 只能读取上传的文件
plt.plot(df["date"], df["revenue"])
plt.savefig("/mnt/data/chart.png")       # ✅ 保存到工作区

# Code Interpreter 中不能做什么
import os
os.system("rm -rf /")      # ❌ 被拦截
import requests
requests.get("http://xxx") # ❌ 网络被禁止

6.2 E2B（Sandbox-as-a-Service）

实现方式：专门为 AI Agent 设计的云端沙箱即服务。

特点：

毫秒级启动
支持 Python、Node.js、Bash
完整的文件系统隔离
可配置网络策略
按需计费

from e2b import Sandbox

# 创建沙箱（毫秒级）
sandbox = Sandbox()

# 在沙箱中执行代码
result = sandbox.run_code("""
import subprocess
result = subprocess.run(["ls", "-la"], capture_output=True)
print(result.stdout.decode())
""")

print(result.text)  # 输出沙箱中的 ls 结果

# 用完销毁
sandbox.close()

6.3 自建 Agent 沙箱

如果你自己开发 Agent，最简单的沙箱实现：

import subprocess
import os
import tempfile
import resource

def run_in_sandbox(code: str, timeout: int = 30) -> str:
    """
    一个极简的 Agent 沙箱
    生产环境需要更完善的实现（seccomp、namespace 等）
    """
    with tempfile.TemporaryDirectory() as sandbox_dir:
        # 1. 写入代码文件
        script_path = os.path.join(sandbox_dir, "script.py")
        with open(script_path, "w") as f:
            f.write(code)

        try:
            # 2. 在隔离目录中执行
            result = subprocess.run(
                ["python3", script_path],
                cwd=sandbox_dir,           # 工作目录在沙箱内
                capture_output=True,
                text=True,
                timeout=timeout,            # 超时限制
                env={                       # 清空环境变量
                    "PATH": "/usr/bin:/bin",
                    "HOME": sandbox_dir,
                    "TMPDIR": sandbox_dir,
                }
            )
            return result.stdout + result.stderr

        except subprocess.TimeoutExpired:
            return f"❌ 执行超时（{timeout}秒）"
        except Exception as e:
            return f"❌ 执行出错: {e}"

# 使用
code = """
import os
print("当前目录:", os.getcwd())
print("文件列表:", os.listdir('.'))
# os.system("rm -rf /")  # 这句只会在沙箱目录里生效
"""
print(run_in_sandbox(code))

但注意：这个极简沙箱远远不够安全。生产级的沙箱还需要——

# 生产级沙箱需要的额外保护

# 1. seccomp（系统调用过滤）—— 限制能用的系统调用
#    禁止：mount, kexec_load, openat 危险路径, ...

# 2. Linux Namespace —— 隔离视图
#    - Mount Namespace: 独立的文件系统挂载
#    - PID Namespace: 看不到外面的进程
#    - Network Namespace: 独立的网络栈
#    - User Namespace: 容器内 root ≠ 外面 root

# 3. Cgroups —— 资源限制
#    - cpu.max = "50m"     # 最多用 50% CPU
#    - memory.max = "512M" # 最多用 512MB 内存
#    - pids.max = "100"    # 最多创建 100 个进程

# 4. read-only 根文件系统
#    只能写 /tmp，其他目录只读

# 5. 网络白名单
#    只能访问特定的 API 地址

7. 沙箱的局限性

7.1 安全不是绝对的

没有绝对安全的隔离方案。沙箱只是增加了攻击成本，不是完全免疫。

安全强度对比：
  虚拟机 > gVisor > 普通容器 > 进程级沙箱
      ↑                               ↑
  最安全                          最轻量

进程级沙箱的主要风险：

风险	说明	事件概率
内核漏洞逃逸	利用 Linux 内核漏洞逃出沙箱	低（但存在）
资源耗尽	即使有限制，也可能影响同机其他进程	中（通过配额缓解）
信息泄露	临时文件未清理干净	低（tmpfs 随进程销毁）
提权漏洞	通过 SUID 程序提升权限	低（容器内通常禁用 SUID）

7.2 沙箱降低了灵活性

在沙箱里你做不到：
  ❌ 安装系统级软件（apt install）
  ❌ 修改系统配置
  ❌ 访问宿主机文件
  ❌ 监听端口做服务
  ❌ 使用 GPU（大部分沙箱不支持）

这既是沙箱的目的（安全），也是沙箱的局限（功能受限）

7.3 性能开销

即使是轻量的沙箱方案，也有性能开销：

系统调用：每次系统调用需要额外检查，增加延迟
文件操作：写入 tmpfs（内存文件系统）很快，但大文件受限
网络请求：如果有限制规则，每次连接都要检查规则
内存限制：限制了 Agent 能处理的数据量上限

7.4 调试困难

1
2
3

Agent 在沙箱里报错了……
开发者在外面想知道：发生了什么？
但沙箱已经销毁了，日志、临时文件全没了

所以生产环境的沙箱通常需要执行日志和审计追踪功能。

8. 生产环境的最佳实践

8.1 分层防御（Defense in Depth）

不要只靠沙箱一层。使用多层防御：

Layer 1: Prompt 安全
  检测 Prompt 注入，过滤恶意输入
  ↓ 突破
Layer 2: 工具调用审核
  检查 Agent 选择的工具和参数是否合理
  ↓ 突破
Layer 3: 沙箱隔离
  即使执行了危险代码，也限制在沙箱内
  ↓ 突破
Layer 4: 系统监控
  监控异常行为，实时告警

8.2 沙箱配置策略

# 生产环境沙箱配置示例
sandbox_config:
  # 文件系统
  filesystem:
    root: read-only           # 根目录只读
    writable: ["/tmp", "/home/user/work"]
    max_size: "1GB"           # 沙箱最大磁盘使用

  # 网络
  network:
    egress:                   # 出站规则
      allow_domains:
        - "api.openai.com"     # 只允许访问指定 API
        - "pypi.org"           # 允许安装包
      block: true              # 其他一律禁止
    ingress: false             # 禁止入站连接

  # 资源
  resources:
    cpu: "1 core"
    memory: "2GB"
    processes: 50             # 最大进程数
    timeout: 120              # 最大执行时间（秒）

  # 执行策略
  execution:
    languages:
      - python
      - bash
      - nodejs
    forbidden_commands:
      - "rm -rf"
      - "dd"
      - ":(){ :|:& };:"       # fork 炸弹模式
    required_approval:
      - pattern: "DROP TABLE"
        reason: "数据库写操作需要审批"
      - pattern: "sudo"
        reason: "提权操作需要审批"

8.3 不同安全等级的场景

场景	推荐方案	原因
个人开发助手	进程级沙箱	快速、轻量，个人使用风险低
企业内部 Agent	Docker 容器	比进程级更安全，可挂载企业内网
SaaS Agent 服务	gVisor / Firecracker	多租户隔离，防逃逸
金融/医疗 Agent	完整虚拟机	合规要求高，需要强审计

8.4 审计与日志

沙箱不是"丢进去就不管了"——你需要知道它在里面做了什么：

📝 执行日志：记录了每次代码执行的内容、结果、耗时
📝 文件变更：记录了沙箱内创建/修改/删除了哪些文件
📝 网络请求：记录了所有网络请求的 URL
📝 系统调用：高危系统调用的记录（生产环境可选）

9. 总结与脑图

一张图理解沙箱

为什么需要沙箱？
    ↓
Agent 生成的代码不可信
    ↓
需要给 Agent 一个"笼子"
    ↓
四种选择：
┌──────────┬─────────┬──────────┬────────────┐
│  虚拟机  │  Docker │  gVisor  │ AI沙箱     │
│  最安全  │  中等   │  较强    │ 轻量够用   │
│  最慢    │  较快   │  中等    │ 最快       │
│  最重    │  轻     │  中等    │ 最轻       │
└────┬─────┴────┬────┴────┬────┴─────┬──────┘
     │          │        │          │
     └──────────┴────────┴──────────┘
                    │
              AI Agent 选它
                    │
              为什么？
              ├─ 毫秒级启动 → 适应 ReAct 循环
              ├─ 用完即焚 → 天然匹配 Agent 临时性
              ├─ 足够安全 → 防住 99% 常见问题
              └─ 极其轻量 → 可大规模并行

核心观点一句话总结

概念	一句话
沙箱是什么	一个”笼子”——让 Agent 在笼子里执行代码，即使翻江倒海也伤不到外面
为什么不用虚拟机	太重太慢，Agent 要的是毫秒级启动，虚拟机给不了
为什么不用 Docker	可以用但不是最优，Docker 是为长期服务设计的，Agent 执行是临时性的
沙箱 vs 容器	容器是”隔离小区”（Namespace），沙箱是”关上门”（更细粒度的限制）
AI Agent 为什么选沙箱	因为 Agent 代码是临时的、不可信的、需要快速执行的——沙箱完美匹配这三点
沙箱够安全吗	防住 99% 的常见问题就够了，追求绝对安全会牺牲太多灵活性和性能
最佳实践	不要只靠沙箱，要分层防御（Prompt 安全 + 工具审核 + 沙箱 + 监控）