09 何时不需要沙箱

本章导读｜预计 8 分钟

走完前面 9 章，这一章是刹车。沙箱有实打实的成本，滥用会拖慢产品、烧掉预算。 目标：给你一把尺子，判断「这个功能到底该不该上沙箱」。

9.1 不需要的情况

• 只是结构化函数调用（查天气、查数据库、调内部 API）
• 只在自家可信环境跑固定流程
• 执行的是你自己写的、输入可控的代码
• 没有任意代码 / shell 执行，只有预定义参数
• 单租户、内部使用

9.2 需要的情况

• 任意代码 / 任意 shell 执行
• 不可信输入（用户内容、外部网页、第三方文档）驱动执行
• 多租户、面向公众
• 需要安装未知依赖（pip install 任意包）
• Agent 会读取外部内容且拥有网络 / 写文件能力（间接注入风险）

判断口诀：只要出现「任意代码 / 任意 shell / 不可信输入驱动执行」，就上沙箱。

9.3 决策树

需要执行代码吗？
├─ 否 → 普通 tool 调用即可，不需要沙箱
└─ 是
   ├─ 代码是「固定流程、你自己写的、输入可控」吗？
   │  ├─ 是 → 直接跑，加基本限额即可
   │  └─ 否
   │     ├─ 输入来自不可信来源吗？（用户 / 网页 / 文档）
   │     │  ├─ 否 → 视风险，可先用 Docker
   │     │  └─ 是 → 必须沙箱（默认断网 + microVM/gVisor）
   │     └─ 多租户 / 面向公众吗？
   │        └─ 是 → 强隔离 microVM + 每会话独立

9.4 过度设计的代价

代价	说明	量化直觉
延迟	每次执行多一次环境创建 / 网络往返	冷启动 + 数百 ms～数秒
成本	环境常驻、资源浪费	空闲环境也在烧内存 / 计费
复杂度	多一层编排、多一处故障点	新增一条排障链路
体验	简单任务被拖慢	用户感知「卡」
安全错觉	上了沙箱就以为万事大吉，忽略注入	反而放松了对出网的管控

最后一条最危险：错误的沙箱会给人虚假的安全感。如果隔离很强但网络全开，注入照样能把数据带走。

9.5 中间态：先分级，再决定

不是「上或不上」的二选一，可以分级：

级别	措施	适用
L0 无沙箱	普通 tool 调用	纯查询、可信代码
L1 限额执行	子进程 + 超时 + 资源限制	自己写的、输入可控的脚本
L2 容器沙箱	Docker / bwrap + 默认断网	可信用户、可控输入
L3 强隔离沙箱	microVM / gVisor + 白名单 + 审计	不可信 / 多租户 / 外部输入

按**「代码是否任意 + 输入是否不可信 + 是否多租户」**三维度选级别，而不是全站一刀切 L3。

9.6 常见误判

• ❌ 「用了 LLM 就得配沙箱」→ 很多 Agent 只做函数调用，不需要。
• ❌ 「生产环境所以必须最强隔离」→ 内部工具用 microVM 是浪费。
• ❌ 「沙箱能解决注入」→ 沙箱管边界，不管意图；注入要靠断网 + 最小权限 + 审计组合。
• ✅ 「先问执行的是不是任意代码，再问输入可不可信，最后才问隔离强度。」

动手练习 9

1. 回顾你系统里所有工具，标出哪些其实不需要沙箱（可以降级为普通 tool）。
2. 给你现在的 Agent 执行需求定一个 L 级别，并写出升级触发条件（出现什么信号就升一级）。

---