AI Agent 沙箱隔离的两种模式：隔离工具还是隔离 Agent？

做 ofox.ai（多模型聚合平台）的过程中，Agent 安全一直是我们重点关注的方向。最近 Browser Use 团队分享了他们在 Agent 沙箱基础设施上的实践，提出了两种清晰的隔离模式，值得每个做 Agent 产品的团队认真思考。

问题的本质

当你的 AI Agent 能执行代码、运行 shell 命令、操作文件系统时，它本质上拥有了机器上的所有权限——环境变量、API Key、数据库凭证、内部服务，全都暴露了。

这不是理论风险。任何允许 Agent 执行任意代码的产品，都必须解决隔离问题。

两种隔离模式

模式一：隔离工具（Isolate the Tool）

Agent 本身运行在你的基础设施上，但危险操作（代码执行、终端访问等）被放进一个独立的沙箱容器里。Agent 通过 HTTP 调用沙箱，代码在一个「什么都没有」的环境中运行。

这是最直觉的做法——哪里危险隔离哪里。实现简单，改造成本低。

但问题在于：Agent 循环本身还是跑在你的后端上。重新部署？所有运行中的 Agent 全挂。某个 Agent 吃满内存？你的 API 跟着慢。两种截然不同的工作负载共享同一个进程，这在规模化之后是不可接受的。

模式二：隔离 Agent（Isolate the Agent）

把整个 Agent 扔进沙箱。沙箱里零秘密、零凭证。Agent 通过一个控制平面（Control Plane）与外部世界通信，所有敏感信息由控制平面持有。

这样 Agent 就变成了可抛弃的（disposable）。没有秘密可以泄露，没有状态需要保存。你可以随时杀掉它、重启它、独立扩缩容。控制平面持有所有真相。

Browser Use 从模式一起步，最终迁移到了模式二。

工程实现的关键细节

Browser Use 的做法有几个值得注意的点：

统一镜像，多环境部署。同一个容器镜像在生产环境跑 Unikraft 微虚拟机，在本地开发跑 Docker。一个配置开关搞定，开发和生产的一致性得到了保证。

Unikraft 微虚拟机。每个 Agent 独占一个微虚拟机，启动时间不到一秒。相比传统 VM 的分钟级启动和容器的安全妥协，微虚拟机在隔离强度和启动速度之间找到了很好的平衡点。

最小化暴露面。沙箱只接收三个环境变量：会话令牌、控制平面 URL 和一个标识符。Agent 需要的一切能力都通过控制平面按需获取，而不是预先注入。

这对 Agent 产品意味着什么

如果你正在构建一个让 AI Agent 执行代码的产品，建议直接从模式二开始设计。模式一看似简单，但在真实的生产环境中，你迟早会遇到模式一无法解决的问题——资源隔离、独立扩缩、故障爆炸半径控制。

更深层的设计原则是：让 Agent 无状态、可抛弃、最小权限。这和我们在微服务架构中学到的教训是一样的——信任边界要画得尽量小。

2026 年会有越来越多的 Agent 产品上线。沙箱不是可选项，是必选项。早点把隔离架构做对，后面会省很多事。