我们如何构建安全可扩展的智能体沙箱基础架构¶

Ch01.1207 我们如何构建安全可扩展的智能体沙箱基础架构¶

📊 Level ⭐⭐ | 4.9KB | entities/我们如何构建安全可扩展的智能体沙箱基础架构.md

来源: 高可用架构

发布日期: 2026-02-27

原文链接: https://mp.weixin.qq.com/s/BN6BeP_sb8_MGqmvLwBswQ

导读：给 AI 智能体执行代码的权限，等于把服务器底裤交出去？本文分享了 Browser Use 运行百万级智能体的架构演进。他们放弃传统的工具隔离，转而采用“基于控制面的微型虚拟机”来彻底隔离智能体。

在 Browser Use ，我们运行着数百万个网页智能体（Web Agents）。起初，我们使用 AWS Lambda 运行纯浏览器智能体，其优势在于每次调用都是隔离的、扩展是即时的，且无需担心密钥安全。

随后，我们增加了代码执行功能。智能体可以编写并运行 Python 代码、执行 Shell 命令、创建文件。我们将此构建为一个被智能体视为“工具”的隔离沙箱。安全性表现良好：代码在沙箱中运行，而非在后端运行。

但问题在于：智能体循环（Agent Loop）仍然与我们的 REST API 运行在同一个后端。重新部署 API？所有运行中的智能体都会崩溃。智能体占用大量内存？API 响应变慢。两种截然不同的工作负载在共享同一个进程。

当一个智能体可以执行任意代码时，它理论上可以访问机器上的任何内容：环境变量、API 密钥、数据库凭据、内部服务。因此，它必须与你的基础设施和秘密（Secrets）隔离。实现这一点有两种方式：

模式 1：隔离工具（Isolate the tool）。智能体运行在你的基础设施上。危险操作（代码执行、终端访问）在独立的沙箱中运行。智能体通过 HTTP 调用沙箱。代码在没有泄露风险的地方运行。
模式 2：隔离智能体（Isolate the agent）。整个智能体都运行在一个没有任何密钥的沙箱中。它通过一个持有所有凭据的控制面（Control Plane）与外界通信。

智能体变成了“即用即弃”的。没有可窃取的秘密，没有需要保留的状态，你可以随时杀死它、重启它、独立扩展它。控制面掌握着“真相”。

我们最初采用了模式 1，后来转向了模式 2。

相同的容器镜像在任何地方都能运行。在生产环境中，它作为 Unikraft 微型虚拟机 (micro-VM) 运行；在本地开发和评估（Evals）中，它作为 Docker 容器运行。通过一个简单的配置开关 ( sandbox_mode: 'docker' | 'ukc' ) 即可控制环境。

每个智能体拥有独立的 Unikraft 微型虚拟机，启动时间不到一秒。我们通过 Unikraft Cloud 的 REST API 在 AWS 的专用裸金属服务器上进行配置。

沙箱仅从外界接收三个环境变量： SESSION_TOKEN 、 CONTROL_PLANE_URL 和 SESSION_ID 。没有 AWS 密钥，没有数据库凭据，也没有 API 令牌。

Unikraft 提供了开箱即用的 “缩容至零”（Scale-to-zero）功能。当沙箱空闲时，VM 会挂起；当下一个请求进入时，它会立即恢复。在查询间隙，沙箱几乎不产生费用，但能瞬间唤醒执行后续任务。

我们跨多个 Unikraft 区域