当 AI Agent 从“回答问题”开始走向“真正执行任务”，一个很快就会遇到的问题是：
你敢不敢真的让它运行代码、修改文件、打开网页，甚至执行系统命令？
如果没有任何限制，让模型直接操作宿主机，本质上相当于把一个能够自动生成命令、自动调用工具，并且可能连续执行几十步操作的程序直接接到了你的电脑上。
这显然不现实。
于是，Agent 系统里通常会引入一个非常重要的组件：
Sandbox，也就是沙箱。
它为 Agent 提供一个受限制、可销毁、可控制的执行环境。
为什么 Agent 需要沙箱
传统的大语言模型本身并没有真正的“执行能力”。
你问：
帮我运行这个 Python 程序普通模型只能生成：
print("Hello World")它并不会真的执行。
但 Agent 不一样。
Agent 可以通过 Tool Calling 调用外部工具：
LLM
↓
Tool Call
↓
Python / Shell / Browser / File System
↓
Execution Result
↓
LLM一旦拥有这些能力，模型就可能执行类似：
python main.py
npm install
git clone ...
rm file.txt甚至可能根据网页中的内容自动生成新的命令。
问题也随之出现：
这些命令到底在哪里执行？
一种最简单的方案是直接在服务器上执行。
Agent
↓
Shell
↓
Host OS但这样 Agent 就可能访问：
/etc
/home
SSH Key
环境变量
数据库凭证
其他用户文件因此真正的 Agent 系统通常会在中间加入一层 Sandbox：
Agent
↓
Tool Calling
↓
Sandbox
↓
Python / Shell / Browser / FilesAgent 可以在这里自由操作，但它看到的并不是真正的宿主机环境。
沙箱可以理解成 Agent 的“临时电脑”
理解 Sandbox 最简单的方法，就是把它想象成：
系统临时给 Agent 分配的一台电脑。
比如你让 Agent：
下载这个 GitHub 项目，安装依赖，运行测试，然后修改 Bug。系统可能创建一个临时环境：
/sandbox
├── repo
│ ├── src
│ ├── package.json
│ └── README.md
│
├── tmp
└── outputAgent 可以在里面：
git clone
npm install
npm test
python script.py也可以修改：
repo/src/App.tsx但通常不能访问：
宿主机其他目录
其他 Agent 的任务
服务器内部配置
未授权凭证任务结束以后，这个 Sandbox 还可以直接销毁。
Create Sandbox
↓
Run Agent
↓
Execute Tools
↓
Generate Artifact
↓
Destroy Sandbox这也是为什么沙箱非常适合 Agent。
因为 Agent 的执行过程天然具有两个特点：
自动化程度高，以及 行为并不完全可预测。
沙箱到底隔离了什么
一个成熟的 Agent Sandbox 通常不仅仅是“创建一个文件夹”。
它可能同时限制几个维度。
文件系统
Agent 通常只能看到指定目录。
例如：
/workspace模型可以执行：
cd /workspace
ls
python main.py但是访问：
cat ~/.ssh/id_rsa可能直接失败。
这就是文件系统隔离。
进程
Agent 执行的程序通常运行在独立环境里。
例如：
Agent A
↓
Sandbox A
↓
Process A
Agent B
↓
Sandbox B
↓
Process B两个 Agent 的程序互相不可见。
这样即使某个任务运行了一个异常程序，也不会直接影响其他任务。
网络
网络往往是 Agent Sandbox 中非常重要的一层限制。
系统可能规定：
允许：
github.com
npmjs.com
pypi.org
禁止：
内网数据库
Metadata Service
内部管理系统有些环境甚至默认：
Network = Disabled只有 Agent 明确需要访问互联网时才开放网络。
这可以防止程序随意向外发送数据。
资源
Agent 生成的代码有可能出现死循环：
while True:
pass也可能疯狂创建进程或者占用内存。
因此 Sandbox 通常会限制：
CPU
Memory
Disk
Execution Time
Process Count比如：
Memory: 2 GB
CPU: 2 Core
Timeout: 300s
Disk: 5 GB如果超过限制，系统直接终止 Sandbox。
沙箱和 Docker 是一回事吗？
很多人第一次看到 Agent Sandbox，会直接想到 Docker。
两者确实非常接近，但严格来说：
Docker 是实现 Sandbox 的一种方式，而 Sandbox 是一个更大的概念。
一个 Agent Sandbox 可以基于：
Docker
Containerd
Firecracker
gVisor
Kubernetes
MicroVM
WebAssembly实现。
比如最简单的 Agent 平台可能直接：
每个任务 -> 创建 Docker Container而安全要求更高的平台可能使用 MicroVM：
Agent
↓
MicroVM
↓
Isolated KernelDocker Container 通常共享宿主机 Kernel：
Container A ─┐
Container B ─┼─> Host Kernel
Container C ─┘MicroVM 的隔离更接近真正的虚拟机：
Agent
↓
MicroVM
↓
Guest Kernel
↓
Host所以对于执行大量未知代码的 Agent 平台来说，MicroVM 往往会提供更强的安全边界。
Agent 如何使用 Sandbox
假设用户给 Agent 一个任务：
帮我分析这个 GitHub 项目为什么启动失败。Agent 首先可能规划：
1. 下载项目
2. 阅读 README
3. 安装依赖
4. 运行程序
5. 查看错误日志
6. 修改代码
7. 再次运行接下来 Agent 会调用工具。
例如：
{
"tool": "shell",
"command": "git clone ..."
}Agent Runtime 收到 Tool Call 后，并不会一定直接在服务器运行。
而是：
LLM
↓
Tool Call
↓
Agent Runtime
↓
Sandbox Manager
↓
Sandbox
↓
ShellShell 返回：
npm ERR! dependency conflict结果再被送回模型：
Sandbox
↓
Tool Result
↓
Agent Runtime
↓
LLM模型分析错误之后继续调用：
npm install ...于是就形成一个执行闭环：
Think
↓
Tool Call
↓
Sandbox Execute
↓
Observation
↓
Think这其实就是很多 Coding Agent 的核心运行方式之一。
Sandbox Manager
如果真的要做一个 Agent 平台，通常不会让 LLM 直接操作 Docker。
中间一般还有一层：
Sandbox Manager。
它负责管理 Sandbox 的生命周期。
例如：
createSandbox()
executeCommand()
uploadFile()
downloadFile()
getStatus()
destroySandbox()系统结构可能类似：
┌─────────────┐
│ LLM │
└──────┬──────┘
│
Tool Calling
│
┌──────▼──────┐
│ Agent Runtime│
└──────┬──────┘
│
┌──────▼──────┐
│Sandbox Manager│
└──────┬──────┘
│
┌────────────┼────────────┐
↓ ↓ ↓
Sandbox A Sandbox B Sandbox CAgent Runtime 负责：
任务规划
上下文管理
Tool Calling
状态管理Sandbox Manager 负责：
环境创建
命令执行
权限控制
资源限制
环境销毁把两者分开非常重要。
因为 LLM 的职责是：
决定做什么。
Sandbox 的职责则是：
决定它最多能做到什么。
沙箱不是唯一的安全机制
有一个很容易出现的误区：
有 Sandbox = Agent 安全实际上并不是。
Sandbox 只能解决其中一部分问题。
真正的 Agent 安全通常是多层的。
例如：
LLM
↓
Tool Permission
↓
Policy
↓
Sandbox
↓
Network Policy
↓
Resource Limit比如 Agent 想执行：
curl xxx.com | bash系统可能在 Tool 层就拒绝。
即使允许执行，在 Sandbox 层依然存在网络限制。
这是一种典型的纵深防御设计。
沙箱和 Tool Permission 是两件不同的事情
这两个概念非常容易混淆。
Tool Permission 控制：
Agent 能不能调用某个工具Sandbox 控制：
这个工具运行以后能影响多大的范围例如：
Shell Tool = Enabled意味着 Agent 可以运行 Shell。
但 Sandbox 可能规定：
只能访问 /workspace
不能访问内网
最多运行 5 分钟
最多使用 2 GB 内存于是：
Tool Permission
↓
能不能做
Sandbox
↓
最多能做到什么程度两者共同构成 Agent 的执行边界。
为什么 Coding Agent 特别依赖 Sandbox
Coding Agent 是 Sandbox 最典型的应用场景之一。
因为 Coding Agent 经常需要：
读取项目
修改代码
安装依赖
运行程序
执行测试
调用编译器
启动浏览器
查看日志这已经远远超过普通聊天机器人的能力范围。
比如一个完整 Coding Agent 的执行链可能是：
User
↓
Agent
↓
Clone Repository
↓
Read Code
↓
Edit Code
↓
npm install
↓
npm test
↓
Start Server
↓
Browser Test
↓
Fix Bug
↓
Generate Patch如果没有 Sandbox，这些行为全部发生在真实服务器环境里，风险会非常高。
有了 Sandbox，每一个 Coding Task 都可以拥有自己的独立工作区：
Task 001 -> Sandbox 001
Task 002 -> Sandbox 002
Task 003 -> Sandbox 003执行结束后：
Sandbox -> Destroy真正需要保存的只有：
Git Patch
Generated Files
Logs
ArtifactsArtifact 为什么重要
Sandbox 通常是临时的。
但用户真正需要的结果不能跟着 Sandbox 一起删除。
例如 Agent 在 Sandbox 中生成：
report.pdf
result.csv
patched-project.zip这些文件通常会被提取为：
Artifact。
过程类似：
Sandbox
│
├── temp
├── repo
├── cache
└── output
└── report.pdf
↓
Artifact然后 Sandbox 可以销毁：
Destroy SandboxArtifact 则被保存下来交给用户。
这也是很多 Agent 系统中：
Workspace
Sandbox
Artifact三个概念经常同时出现的原因。
Persistent Sandbox
并不是所有 Sandbox 都必须在任务结束后销毁。
有些 Agent 会使用：
Persistent Sandbox。
也就是长期存在的执行环境。
例如：
Project A
↓
Sandbox A用户第二天回来继续：
继续昨天那个项目。Agent 仍然可以看到：
node_modules
Git Repository
Build Cache
Previous Files这样就避免每次重新初始化环境。
因此 Sandbox 通常又可以分为：
Ephemeral Sandbox
临时沙箱
Persistent Sandbox
持久沙箱临时沙箱更安全、更干净。
持久沙箱更适合长期 Coding Agent 和复杂项目。
Sandbox 让 Agent 真正拥有“行动空间”
LLM 本身只负责生成 Token。
Tool Calling 让模型开始能够调用外部世界。
而 Sandbox 则给这些 Tool 提供了一个真正可以执行的环境。
可以把三者理解为：
LLM
负责思考
Tool
负责行动
Sandbox
负责提供行动空间和边界当 Agent 越来越接近真正的数字员工以后，Sandbox 的重要性还会继续提高。
因为未来 Agent 可能会同时操作：
代码
浏览器
Terminal
文件
数据库
桌面应用这时候真正困难的问题已经不只是：
模型会不会调用工具？而是：
我们应该允许它在什么范围内调用这些工具。
Sandbox，就是这个范围最核心的一道边界。