00 心智模型

本章导读｜预计 8 分钟

开始之前，先把脑子里那个「沙箱 = 关坏代码的监狱」的印象修正掉。 这一章不讲实现，只讲怎么想——因为后面所有章节的取舍，都取决于你现在建立的心智模型。

0.1 一个常见误解

很多人第一次听到「沙箱」，会以为它是给不可信代码准备的牢房。这个印象来自传统安全领域：

• 浏览器沙箱：把不可信的网页关起来，别让它读到你的文件系统；
• 手机 App 沙箱：把每个 App 关起来，别让它偷看别的 App 数据。

这个定义只说对了一半。对于 Agent，沙箱还有另一半更重要、也更常被忽略的职责。

Agent 沙箱 = Agent 的计算机。 它既是「牢房」，也是 Agent 的「手和脚」。

• 没有沙箱，LLM 只能说（输出 token），不能做（产生副作用）。
• 有了沙箱，LLM 才能改文件、跑脚本、装依赖、发请求，真正把事情做完。

只把沙箱当牢房，你会设计出一堆限制，却做不出能干活的产品；只把它当执行器、忽略约束，你又会把主机和数据暴露在风险里。正确的模型必须同时容纳这两面。

0.2 两个关键词：赋能与约束

理解 Agent 沙箱，要同时抓住两个词：

词	含义	具体表现	少了它会怎样
赋能	给 Agent 一个能干活的环境	可写文件、可执行命令、可装依赖、可发请求	Agent 只会聊天，无法完成多步任务
约束	让它在受控范围内干活	断网 / 限额 / 只读根 / 短生命周期 / 审计	Agent 闯祸，一次幻觉就能删库或泄密

这两个词不是对立的，而是同一套机制的两个方向：

• --network none：约束是「不让它外泄」，赋能是「让它敢跑不可信代码」。
• 可写工作区 /work：约束是「只准动这里」，赋能是「它可以自由改文件、装依赖」。
• 用完即销毁：约束是「不留残渣」，赋能是「可以随便折腾，反正一次性」。

记住这句话：约束不是为了少做事，而是为了让你敢让它多做事。

0.3 一个直观的类比

把 LLM 想象成一个很聪明但没有手的人：

• 他只能动嘴（输出文本），知识再多也落不了地。
• 你想让他帮你改电脑上的文件、跑个脚本、抓个网页，他做不到。
• 沙箱就是给他配的一台一次性电脑：他能上去操作，但搞坏了也伤不到你的主机。

这个类比能解释几个设计选择：

现象	用类比理解
为什么沙箱要「可编程」	电脑要能被你远程开机、执行、关机，而不是手工运维
为什么沙箱是「一次性」的	借用别人的电脑，用完就还，不留痕迹
为什么沙箱要「默认断网」	借来的电脑先拔网线，防止它偷偷把你的资料传出去
为什么还要「快照 / 分叉」	同一台电脑可以「存档」，复制出多台跑不同方案

0.4 沙箱 ≠ 容器 ≠ 虚拟机 ≠ 函数计算

这几个词经常被混用，先把边界划清：

概念	隔离对象	生命周期	与 Agent 沙箱的关系
容器（Docker）	进程 / 文件系统	分钟～长期	常被用作沙箱的实现，但共享内核、隔离较弱
虚拟机（VM）	整台机器	分钟～长期	强隔离，沙箱可以建在它上面（如 microVM）
函数计算（FaaS）	单次调用	一次请求	无状态、无交互 shell，做不了「多步有状态任务」
Agent 沙箱	一整个工作环境	一次会话 / 任务	有状态、可交互、可快照，是「能养 Agent 的运行时」

一句话区分：容器和 VM 是「怎么隔离」，Agent 沙箱是「隔离起来给谁用、怎么用」。 前者是手段，后者是产品形态。后面的第 5 章会专门比较这些隔离手段。

0.5 沙箱在 Agent 循环中的位置

          ┌──────────────────────────────────────┐
          │            LLM（大脑）                │
          │   读上下文 → 推理 → 决定下一步动作      │
          └───────────────┬──────────────────────┘
                          │  tool call
                          │  run("python train.py")
                          ▼
          ┌──────────────────────────────────────┐
          │          Agent 执行框架               │
          │  （工具路由、循环控制、结果回填）        │
          └───────────────┬──────────────────────┘
                          │  SDK / HTTP / MCP
                          ▼
          ┌──────────────────────────────────────┐
          │         Agent 沙箱（手脚）            │
          │  文件系统 · Shell · 网络 · 快照        │
          │  ┌────────────────────────────────┐  │
          │  │  隔离后端 Container / microVM   │  │
          │  └────────────────────────────────┘  │
          └───────────────┬──────────────────────┘
                          │  stdout / 文件 diff / 退出码
                          ▼
                   回到 LLM 上下文

大脑负责思考，沙箱负责执行。 二者解耦，才能各自独立扩展与替换：换模型不影响沙箱，换沙箱不影响 Agent 逻辑。

0.6 三个常见错误认知

• ❌ 「上了沙箱就安全了」。沙箱防的是「逃逸」，但 Agent 场景的头号风险是借 Agent 之手把数据发出去——沙箱毫发无损，数据已经泄漏。见 第 6 章。
• ❌ 「沙箱就是 Docker」。容器是一种实现，不是定义。多租户不可信场景里，裸容器往往不够，需要 microVM / gVisor。见 第 5 章。
• ❌ 「隔离越强越好」。隔离有成本：更慢、更贵、更复杂。给「查天气」这种函数调用套 microVM 是纯浪费。见 第 9 章。

0.7 本章要点

1. 沙箱对 Agent 是赋能工具，不只是安全组件。
2. 它同时承担「能干活」（赋能）和「闯不了祸」（约束）两个职责。
3. 约束是赋能的前提：先划好安全边界，你才敢放开让 Agent 做更多事。
4. 后面每一章，都是围绕这两个职责展开的一个具体问题。

动手练习 0

1. 用一句话向同事解释：为什么「沙箱 = 牢房」对 Agent 来说是错的？
2. 列出你的 Agent 现在想让它做、却因为「不敢」而没做的三件事，并各写一条能让你「敢做」的约束。
3. 判断下面哪些属于 Agent 沙箱：手机 App 隔离、E2B、Docker、浏览器 iframe 隔离、Modal Sandbox。

---