给 AI 跑代码，别把生产机当沙盒

让 Agent 跑一条命令，现在已经不稀奇了。真正让人头皮发紧的，是它把命令跑在哪儿。

它要读仓库，装依赖，生成文件，访问一个内部 API。为了省事，很多原型会直接给它一台开发机、一个带权限的容器，或者干脆沿用 CI 的凭据。Demo 很顺，直到某次工具调用写错路径、某个依赖安装脚本开始碰网络、一个本不该出现在进程环境里的 token 被日志带走。

这不是模型犯不犯傻的问题。是运行时边界根本没画出来。

Perplexity 这周把自家智能体执行环境开源成了 SPACE。它用 Firecracker microVM 跑 Agent 或用户代码，把创建环境、执行命令、读取输出、暂停恢复和删除，都收在一套 API 里。仓库公开时已有约 1,138 个 Star；官方说它已承载 Perplexity Computer 的全部会话，过去一周处理了数百万次沙盒创建，启动速度比旧方案快 3–5 倍。官方说明里最值得看的并不是这些数字，而是一个很朴素的判断：Agent 的执行环境，得当成产品的一部分来设计。

图：代码执行不是一条 run 命令，而是一条需要分层约束的路径。

先把「模型权限」和「代码权限」分开

很多 Agent 设计到这里会混成一团：模型能调用工具，于是工具就能拿到它需要的一切。这个推理看上去顺，实际上把两种权限捆死了。

模型权限，决定它能请求什么动作；代码权限，决定那个动作在什么文件系统、什么网络和什么身份下发生。前者可以随着任务变，后者必须有硬边界。

SPACE 的做法是把模板和沙盒分开。模板提供起始环境，沙盒则是有独立虚拟机与可写文件系统的实例；一个沙盒可以连续运行多个命令。这样做的重点不是「把 Docker 换成更酷的名词」，而是让工作区有生命周期：什么时候新建，什么时候暂停，什么时候销毁，谁能恢复它，留下一条可追的记录。

如果你的 Agent 只是给开发者跑一次格式化脚本，一次性隔离环境可能就够了。可一旦它要处理多小时任务、持续积累文件、等待用户补资料，环境又不能像临时容器那样随手蒸发。长期状态和最小权限，开始互相拧巴。

这也是为什么「给个容器不就行了」常常只解决了第一天。第二天你会补持久目录；第三天要补重连；第四天发现重试让同一条写入执行了两次。然后，这个容器慢慢长成了一套没人愿意碰的运行时。

先做一张很小的边界表

在决定要不要部署 SPACE、E2B 或自己搭一层之前，我更建议把下面四项写进 Agent 的任务设计。它比仓促挑一个框架有用。

要问的问题	最低要求	一旦答不出来会发生什么
任务能看到哪些文件？	工作目录按任务挂载；默认不给宿主目录	Agent 的一次误操作会越过项目边界
它用什么身份访问外部服务？	短时、任务级凭据；不要把长期密钥塞进环境变量	日志、子进程或依赖脚本可能把凭据带走
网络能去哪里？	出站按域名或服务白名单，而不是默认全开	下载脚本和工具调用拥有了意外的外部通道
出错怎么停、怎么撤？	超时、终止、输出留档，以及可验证的清理动作	重试会变成重复写入，事故也没有回放线索

这张表不要求你马上上 microVM。它只是先把「能执行」拆成四个真正需要做决定的地方。

图：先判断边界，再决定用容器、微虚拟机还是托管沙盒。

为什么命令流也要当成安全接口

SPACE 的文档里有个很容易被略过的细节：管理请求用 API token，命令输出则使用会话级 attachment token；创建命令并不等于已经开始执行，客户端要连到对应的会话才能启动它。首个沙盒示例还要求调用方核对退出码、错误和未完成的帧。

看着有点麻烦。但这正是 Agent 运行时和「在服务器上 exec 一下」的分水岭。

假设你的产品允许用户让 Agent 处理一个压缩包。管理面可以负责：这个任务是否允许创建环境、额度还有多少、它能使用哪种模板。真正的命令会话只负责：在这个已经批准的环境里跑哪一条指令，输出如何回来。两者不要共用一把万能钥匙。

这样做以后，失败也更容易被说清楚。是请求没获批？环境没就绪？命令没附着成功？还是进程本身退出非零？如果这些状态都混在一行「执行失败」里，模型只会开始重试；人则会在日志里考古。

别把隔离当成「放进去就安全」

Firecracker microVM、容器、Kubernetes，名字再硬也不会自动替你完成风险设计。SPACE 的本地部署文档本身就要求 Linux x86_64、KVM 和 Kind/Kubernetes 环境；它是一个给需要长期、隔离执行的团队准备的平台，不是给每个脚本套上的魔法护盾。安装说明写得很诚实：先满足主机条件，再配置、认证、验证和清理。

对于大多数刚开始做 Agent 的团队，顺序可以更克制一点：

1. 先让每个任务有独立工作目录和明确的超时。
2. 再把可访问的文件、网络和凭据列成允许清单。
3. 任务开始变长、需要暂停恢复、要服务多个租户时，再评估微虚拟机或专门的沙盒平台。

不是所有人都要部署 SPACE。但所有给 Agent 开了 shell 的人，都值得回答这四个问题。

模型进步会让 Agent 更敢动手，真正昂贵的却不是它多写了几行代码，而是它开始碰你真实的系统。把执行环境做成可授权、可观测、可回收的东西，才有资格慢慢放宽权限。

如果你的 Agent 今天已经能运行命令：你最不愿意让它默认碰到的，是生产凭据、真实用户数据，还是无约束的网络？

小岛 AI