为什么你的 AI 代理需要安全沙箱

Source: Dev.to

“Happy Path” 陷阱

大多数开发者演示看起来像这样：

agent = Agent(tools=[Browser(), FileSystem()])
agent.run("Research competitors")

这对单个用户来说运行完美。但考虑以下边缘情况：

• 用户 A 的代理调用 fs.read_file('../.env')。
• 用户 B 的浏览器工具打开了一个无限滚动的页面，消耗了 8 GB 内存。

代理基础设施的三大祸根

1. 隔离泄漏

共享运行时意味着共享机密。没有严格的内核级隔离，代理之间可以相互窥探。如果代理 A 设置了环境变量 OPENAI_API_KEY，在同一进程中运行的代理 B 可能会读取到它。

2. 资源耗尽

大语言模型喜欢循环。一次“思考循环”可能会触发 1,000 次请求或占用 100 % CPU，导致服务器对其他人不可用。传统的 Web 服务器有请求超时（例如 30 秒），但代理任务往往需要运行 5–10 分钟。

3. 僵尸进程

如果代理在 Selenium 浏览器会话中途崩溃，谁来清理 Chrome 进程？随着时间推移，这些“僵尸”进程会累积，直至服务器崩溃。

解决方案：Kubernetes‑式编排

我们意识到 代理不过是会回传信息的容器。要安全运行它们，需要云服务商使用的相同原语：

• 短暂沙箱 – 每次代理运行都会启动一个全新的、隔离的 Firecracker 微型虚拟机或容器。没有状态泄漏。
• 硬性限制 – 限制 CPU、内存，且关键的是 时间。如果代理循环 5 分钟，就将其终止。
• 出站过滤 – 防止代理扫描内部网络（例如 192.168.x.x）。在网络层阻断此类流量。

结论

从“演示”到“生产”的转变全在于处理各种失效模式。在 Runctl，我们相信开发者应专注于代理的业务逻辑，而让基础设施负责隔离、调度和清理。

本文最初发布在 Runctl Engineering Blog。我们正在构建面向自主代理的 K8s‑式运行时——如果你的规模已经超出本地环境，欢迎试用。