当 Agent 开始替你跑代码，为什么只套一层 Docker 不够

Wed, 15 Jul 2026 00:00:00 +0000

当 Agent 开始替你跑代码，为什么只套一层 Docker 不够

你把 Agent 接进内部系统后，最危险的那一步通常不是模型回答错了。

而是它开始替你执行代码：装一个包，跑一段 Python，拉一个仓库，开 Chromium 点几个页面，再顺手访问外网。演示里这是一条 run_code()；线上，它意味着一段由模型拼出来、由用户输入影响、依赖链也未必干净的程序，正在拿你的 CPU、网络和文件系统做事。

很多团队的第一反应是：丢进 Docker，不就隔离了吗？

Docker 当然不是不能用。它有 namespace、cgroup、capability、seccomp，也能配 AppArmor、SELinux 和 rootless。问题在于，Agent 这类负载把它推到了一个更难的位置：你不是在跑一组自己写、自己发布的服务，而是在高频创建执行环境，里面的命令、依赖、网页和输入都更不受控。容器仍与宿主共享内核；一旦把 Docker daemon、宿主目录或过宽的 capability 暴露进去，隔离边界就会被你自己打穿。[1]

这时该换的问题了。

Agent 沙箱不是“能不能把代码跑起来”的组件，而是“代码跑错了，最多能碰到哪里”的运行时。

Cube Sandbox 值得看，正是因为它没有把重点放在再包一层执行 API，而是把 MicroVM、模板快照、网络出口和凭据边界一起做成了面向 Agent 的运行时。它还很年轻，远没有到“装上就高枕无忧”的程度；但它提醒了后端团队一件容易被忽略的事：Agent 执行层，本身就是一套基础设施。

真正要防的，不是那一段 Python

假设你的 Agent 被允许“分析一个 CSV 并生成图表”。过几周，需求会自然长出下一层：

能不能 pip install 一个缺失库？
能不能读取用户上传的压缩包？
能不能抓一个网页再做摘要？
能不能调用企业内部 API 补充数据？
能不能保留上轮生成的文件，下一轮继续修改？

每加一个“能不能”，都不是单纯的工具功能，而是在扩大执行边界。

最直观的风险是任意代码。更难处理的是旁路：代码可以借网络带走数据，可以从环境变量或文件里摸到密钥，可以耗尽 CPU、内存和磁盘，也可能借浏览器自动化碰到本不该访问的后台页面。即使没有逃逸漏洞，只要权限、挂载和出口策略给得太宽，沙箱也会变成“专门给不可信代码准备的跳板”。

所以后端开发者不该只盯着 prompt injection。Prompt injection 是诱因；执行环境、网络策略、密钥注入和审计是否收口，才决定诱因最后能造成多大损失。

一条很实用的判断是：只要 Agent 能执行用户可影响的命令，就先按多租户、不可信工作负载设计；即使今天只有一个内部用户。 因为能力一旦接进产品，使用边界通常只会往外扩，不会自己缩回去。

MicroVM on Zampo Blog

当 Agent 开始替你跑代码，为什么只套一层 Docker 不够

当 Agent 开始替你跑代码，为什么只套一层 Docker 不够

真正要防的，不是那一段 Python