01 定位

本章导读｜预计 8 分钟

第 0 章建立了「沙箱 = Agent 的计算机」这个直觉。这一章把它变成一个可对齐、可写进设计文档的定义： Agent 沙箱到底和传统沙箱差在哪？它精确的边界是什么？在 Agent 架构里占哪个位置？

1.1 两种沙箱的对比

传统沙箱和 Agent 沙箱共享同一批底层技术（namespace、cgroup、seccomp、VM），但设计目标相反。

维度	传统安全沙箱	Agent 沙箱
目的	防坏代码破坏系统	让 Agent 安全地做事
主视角	防御	赋能
生命周期	长期、固定	短、一次一换（也支持持久）
接口	系统调用拦截	API / SDK / MCP
用户	人（运行程序的人）	程序（Agent 自己调用）
状态	通常无状态、可弃	有状态、需保留工作区
头号风险	沙箱逃逸	数据外泄
失败代价	系统被攻破	任务失败 / 数据泄漏 / 账单失控

为什么「用户不同」这一点很关键？

传统沙箱的调用者是人：人知道自己在干什么，会判断命令是否合理。Agent 沙箱的调用者是 LLM：它会幻觉、会被注入、会写出语法正确但意图错误的命令。所以 Agent 沙箱不能假设调用者「有常识」，必须用机制兜住它的错误。

1.2 一句话定义

Agent 沙箱 = 一个远程、可编程、一次性（或可持久）的计算环境，通过 API / SDK / MCP 暴露给 Agent 调用。

拆开看关键词：

关键词	含义	反面（不满足会怎样）
远程	通常在云端 / 独立主机，不和 Agent 主进程同命	同进程执行，Agent 崩溃或越权会拖垮主服务
可编程	能被 API 创建、执行、销毁	靠人工开机器，无法规模化、无法自动化
一次性 / 可持久	两种模式都支持，按任务选	只有一次性 → 做不了长任务；只有持久 → 残留与成本失控
API / MCP	Agent 通过工具调用来使用它	没有标准接口，每个框架都要自造轮子
计算环境	有文件系统、Shell、运行时，不只是一次函数调用	退化成 FaaS，做不了多步有状态任务

和「普通云主机」的区别：普通云主机是给人长期运维的；Agent 沙箱是给程序按需创建、用完即毁的。前者强调稳定持久，后者强调快速、隔离、可编程、可回收。

1.3 它在 Agent 架构里的位置

┌─────────────┐     tool call      ┌──────────────┐
│  LLM / Agent │ ─────────────────► │   Sandbox    │
│   （大脑）    │ ◄───────────────── │  （手脚）     │
└─────────────┘   执行结果 / 文件    └──────────────┘

这个位置带来三条架构含义：

1. 解耦：换模型（大脑）不影响沙箱（手脚），换隔离后端也不影响 Agent 逻辑。
2. 有边界：所有副作用都被收敛到沙箱内部，主服务保持干净。
3. 可观测：沙箱是天然的审计点——所有命令、文件改动、网络请求都从这里经过。

如果把执行逻辑直接塞进主进程（很多早期 Agent 的做法），上面三条全部失效：一次 rm -rf / 就能带着你的服务一起走。

1.4 边界：沙箱「不」负责什么

明确定义也包括明确不该由它承担的事，避免把安全问题都甩给沙箱：

不是沙箱的职责	应该在哪一层解决
判断命令是否「意图恶意」	策略引擎 / human-in-the-loop（沙箱只执行）
防止模型被 prompt injection 操纵	输入过滤、权限最小化、默认断网（沙箱是其中一道）
保护沙箱内主动外发的敏感数据	出网白名单 + 凭据代理（沙箱配合）
业务逻辑正确性	Agent / 应用层
用户身份与业务鉴权	控制面 / 网关（沙箱只认短期 token）

一句话：沙箱管「边界」，不管「意图」。 它是一个强制的物理约束，不是决策者。

1.5 本章要点

1. Agent 沙箱与传统沙箱目标相反：一个为赋能，一个为防御。
2. 精确定义是「远程、可编程、一次性 / 可持久的计算环境，经 API / MCP 暴露」。
3. 它在架构里是「手脚」，带来解耦、隔离边界、天然审计三个好处。
4. 沙箱不负责判断意图，只负责强制边界。

动手练习 1

用自己的话写三句话，分别回答：

1. 沙箱对 Agent 意味着什么？
2. 它和「一个普通的云主机」有什么不同？
3. 为什么说它既是笼子又是手脚？
4. （进阶）举一个「不该由沙箱负责」的安全问题，并说明应该放在哪一层。

---