AI Sandbox：安全工具执行与隔离的底座
工具执行的安全隔离是智能体系统迈向企业级治理的关键，AI Sandbox 是不可或缺的底座。
工具执行的本质：不可信输入驱动的可控执行
智能体的所有工具调用都具备一个共同特性：输入来自大语言模型（LLM, Large Language Model），这些输入可能不可信，甚至被误导、越权或执行危险动作。因此，工具执行不能直接运行在应用容器、智能体主进程或后端服务本体，必须实现隔离。
AI Sandbox 的目标不是简单运行代码，而是控制代码的能力边界。工具调用的标准执行模型如下：
- Agent 推理生成 Action（工具调用描述）
- Action 被发送到 Tool Executor（工具执行器）
- Tool Executor 在 Sandbox（沙箱环境）内执行
- Sandbox 输出受控结果
- 运行时仲裁输出是否可信
任何背离此模型的系统，当前尚难进入企业级环境。
权限模型：可授权、可审计、可撤销
工具权限治理是 AI Sandbox 的核心。传统微服务的权限依赖 API 网关、RBAC、Token 等机制，而智能体工具权限需做到：
- 工具级能力授权
- 会话级授权
- 参数级审计
- 单次调用级撤销
- 执行轨迹可追溯
权限模型要求：
- 工具只能做声明的事情
- 工具的输入参数必须可验证
- 工具不能访问未声明的系统资源
- 执行痕迹必须可观测
Agentic Runtime（智能体运行时）需内置权限仲裁器（Permission Arbiter），否则安全边界难以控制。
短生命周期执行：避免持久态风险
Sandbox 必须具备短生命周期特征。每次工具调用都应在全新执行环境下完成：
- 无持久文件系统
- 无持久网络访问
- 无跨调用状态泄漏
- 调用结束立即回收
这样设计的原因在于：LLM 生成的 Action 本质上不可预测，多智能体协作时工具链输入路径复杂，任何一次越权都需在即时执行层切断。短生命周期保证工具执行是安全的原子性单元。
隔离技术：gVisor / Firecracker / Wasm
AI Sandbox 并非单一技术，而是一类执行形态。下文介绍主流隔离技术，并在每节前补充说明。
gVisor（用户态内核）
- 强隔离
- 兼容 OCI 容器生态
- 不需要完整虚拟机
- 适合文件处理、网络 API 调用、轻量逻辑
Firecracker（MicroVM）
- 虚拟机级隔离
- 冷启动快
- Serverless 平台主流技术
- 适合高风险工具、企业级数据处理、受控 Python runtime
Wasm（WebAssembly）
- 无系统调用
- 轻量级
- 多语言支持
- 高可移植性
- 适合规则执行、DSL runtime、内部工具链
Sandboxed Compute（托管沙箱）
- 例如 OpenAI Code Interpreter、Cloudflare Workerd、Google WASM Sandbox
- 适合无需自维护基础设施、工具执行轻量但安全要求高的场景
为什么智能体必须拥有沙箱
智能体系统缺乏沙箱会带来结构性风险。下文分点说明沙箱的必要性。
大语言模型不可信
- 可能误调用危险工具
- 构造恶意参数
- 生成高风险系统调用
- 越界访问未授权资源
沙箱是实现硬隔离的关键技术。
工具链本身可能存在漏洞
- 第三方工具可能任意文件读写、网络扫描、提权、命令注入
- 必须隔离运行，降低风险
多智能体协作放大攻击面
- Team / DAG 执行链复杂，一个错误可能影响全局
企业内部要求可审计
- 审计需记录每次工具的输入、执行环境、执行结果、资源使用、执行失败原因
- 沙箱是审计的基础单元
运行时治理要求明确边界
- Agentic Runtime 需具备控制、限制、仲裁、否决等能力
- 普通容器难以直接施加这些治理
总结
AI Sandbox 是 Agentic Runtime 的底层基座，其价值在于隔离、受控执行、权限模型、审计、工具链安全和可治理性。没有沙箱的智能体系统难以进入企业级生产环境。AI 时代的运行时是推理 + 工具 + 状态 + Sandbox + 调度，Sandbox 是其中不可替代的执行底座。