让 Agent 帮你算数、处理一批表格、跑个脚本，它就得真的执行代码。而只要它开始执行代码，它就在你的机器上有了手脚——能读文件、能改文件、能联网、能装包。能力是从这里来的，风险也是从这里来的。
这就是「Agent 沙箱」要解决的问题。很多人把它理解成「套个容器就完了」，其实沙箱要隔离的不是一样东西，而是四样，缺一样都等于没隔离。这篇按「为什么要沙箱 → 隔离什么 → 四种方案怎么选 → 怎么落地」的顺序讲。
先明确：为什么不能干脆不让 Agent 跑代码
有三条路可以绕开代码执行：让模型自己算、把能力封成工具、或者干脆不让它碰。三条都不够用。
模型自己算不可靠。整数乘法、日期推算、大数统计这类任务，模型凭「感觉」给的答案经常错得离谱，而且错得很自信。只要涉及金额、数量、日期，就不该让它心算。
把每个能力都封成工具不够灵活。工具化是对的方向，做法见 AI Agent 工具怎么设计才好用。但业务里的临时需求是无限的——今天要合并三个表、明天要抽一段日志——你不可能为每个一次性的需求都写一个工具。
所以「给一个能执行代码的环境」几乎成了标配。问题只剩下：这个环境怎么圈住。
沙箱要隔离的是四样东西，不是一样
这是最容易漏的地方。很多人做了容器化就以为安全了，结果凭证还写在环境变量里、网络还是通的。
（1）进程与系统调用。它能不能开子进程、能不能装包、能不能读 /etc、能不能提权。这是最基础的一层。
（2）文件系统。它能看见哪些目录、能不能写。一个只挂载了临时目录的沙箱，和一个挂载了整个家目录的沙箱，风险差好几个量级。
（3）网络。这是最容易被放过的一层。网络通着，前面两层做得再好也可能被绕过——下载一个二进制、把数据外发、连上内网某台没设防的服务。
（4）凭证与身份。沙箱里有没有 API Key、数据库密码、云账号。这一层出事最严重：前三层是「它可能做坏事」，这一层是「它手里拿的是真钥匙」，权限怎么分层参考 AI Agent 权限管理怎么做。
四层叠起来，才叫一个像样的沙箱。少了任何一层，攻击面只是变窄，没有消失。
Agent 沙箱和普通代码沙箱，有三个不同点
如果你按「跑用户提交代码」的经典沙箱模型去设计 Agent 沙箱，会踩坑，因为三点不一样。
第一，写代码的和跑代码的是同一个东西。经典场景里，代码是用户写的、环境是你定的；Agent 场景里，代码是模型现场写的，而且它会根据报错自己改写、重试、装依赖。这意味着威胁不是一次性的，而是持续迭代的对抗过程——第一次被拦住，它可能换个写法再来。
第二，它需要外部资源才能干活。经典沙箱的默认答案是把网络全关掉；但 Agent 处理数据往往要读文件、调接口、拉依赖。所以不能简单切断，只能做白名单化的出网——这比全关难得多，也更需要人维护。
第三，它有状态，而且状态要跨轮保留。会话、临时产物、中间结果往往要在多轮之间留存。沙箱「用完即毁」的原则，和「Agent 要记得上次跑了什么」直接冲突。折中做法是：执行环境用完即毁，产物通过指定出口取出并单独存放，环境本身不留任何东西。
四种隔离方案，从轻到重怎么选
（1）进程级隔离。用独立账号跑、限制资源（CPU、内存、磁盘、超时）、只给一个临时目录。最轻，几乎不增加成本。缺点也明显：隔离不彻底，文件和网络基本靠约定，只适合「自己写、自己跑、不碰外部数据」的场景，比如本地开发时让 Agent 跑一段脚本。
（2）容器级隔离。一个任务一个容器，只挂载必要目录，出网走白名单，超时后直接销毁。这是目前最主流的选择，成熟、生态好、启动快。要注意的是：容器不是安全边界的神话——共享内核意味着内核漏洞仍可能逃逸，而配置没做好的容器（把宿主目录整个挂进去、挂载了 Docker 守护进程、开了特权模式）等于没隔离。
（3）微虚机 / 轻量虚机。每个任务一个独立内核，逃逸难度高一个数量级，启动速度也做到了接近容器。适合要处理不可信内容、需要更强隔离的团队。代价是运维复杂度和成本都更高。
（4）托管沙箱服务。由平台提供执行环境，你只管传代码、拿结果。省掉一整块运维，通常自带出网控制、资源限额、会话恢复。代表做法可以看 OpenAI Agents API 把沙箱打包进托管服务 这条线。两个要提前问清的点：数据驻留在哪、出网策略能不能改。
选型判断不复杂：代码是谁写的、数据有多敏感、要不要长期跑。自己写的、数据不敏感，进程级就够；模型现场写、要碰业务数据，至少容器级；要处理外部不可信内容，上微虚机或托管。也可以混着用——低风险任务走轻量方案，高风险任务走重隔离，没必要一刀切。
落地清单：七条
（1）默认拒绝出网。需要访问哪个域名，就单独开哪个，而不是默认全开再想办法往回拦。
（2）只挂载必要目录，并明确读写权限。大部分任务只需要读一个输入目录、写一个输出目录。整个家目录挂进去，前面做的全白费。
（3）沙箱里不放长期凭证。需要调外部接口时，用短时效的临时凭证，或者由沙箱外的代理来完成调用。长期密钥一旦进了沙箱，就等于交给了模型。
（4）资源限额要给全。CPU、内存、磁盘、执行时长、输出体积，五样都要限。只限时间不限磁盘，一个死循环就能把盘写满。
（5）用完即毁，产物单独取出。不要复用执行环境，避免上一轮的残留影响下一轮。产物通过约定通道导出，导出内容本身也要检查。
（6）执行过程要留痕。跑了什么代码、访问了哪些地址、产生了什么文件，都得记下来。字段怎么设计参考 AI Agent 审计查询字段怎么设计，完整留证思路见 AI Agent 证据包怎么留。
（7）把沙箱当成防线的一层，而不是全部。沙箱解决的是「跑起来的代码不能乱来」，解决不了「模型决定去跑什么」。提示词注入、越权调用、被诱导删库这类问题，得靠权限、确认和监控一起兜。整体分层思路参考 AI Agent 安全怎么防。
优缺点说清楚
优点：Agent 的能力上限被打开，不用为每个临时需求都写工具；出事故时影响范围被圈在一个可预期的盒子里；权限和合规上说得清楚，安全评审好过。
缺点：多一层隔离就多一份延迟和成本，冷启动尤其明显；出网白名单会经常拦到「本来是正常需求」的调用，需要人持续维护规则；调试变难——沙箱里跑不通，很多时候不是代码问题，而是权限没给够。另外，隔离做严了，Agent 解决问题的能力也会跟着下降，这个权衡绕不开。
适合人群
适合：Agent 要处理 Excel、日志、数据文件，或者需要现场写脚本的团队；会把外部内容（网页、用户上传文件、第三方接口返回）喂给 Agent 的场景；要通过安全评审、被问过「它要是乱跑怎么办」的项目。不适合：Agent 只做查询和文本生成、完全不执行代码的场景——这时候讨论沙箱属于过度设计，把权限和提示词管好就够了。
六个坑
坑一：以为用了容器就安全了。挂载了宿主目录、开了特权模式、把守护进程挂进去，等于把墙拆了。坑二：网络全开。前三层做得再细，出网一开，绕过路径就回来了。坑三：密钥跟着代码一起进沙箱。这是最容易出大事的一条。坑四：只限执行时间，不限磁盘和输出体积。写满磁盘能把整台机器拖死。坑五：复用执行环境图省事。上一轮的残留文件会被下一轮读到，结果变得不可解释。坑六：把沙箱当万能药。它挡的是执行侧的风险，挡不住「模型决定跑什么」这一层的风险，工具层面的排错见 AI Agent 工具调用失败怎么排查。
总结
AI Agent 沙箱，一条主线：先承认「要跑代码」这件事绕不开，再明确要隔离的是进程、文件、网络、凭证四样；Agent 沙箱和经典沙箱的三点差别在于代码由模型现场写、需要受控出网、有需要跨轮保留的状态；方案上按风险从进程级、容器级、微虚机到托管沙箱逐级升级；落地执行七条——默认拒绝出网、只挂必要目录、不放长期凭证、限额给全、用完即毁、全程留痕，并把沙箱当作安全体系的一层而不是全部。一句心法：沙箱的意义不是让 Agent 变笨，而是让它搞砸的时候，只搞砸一个可以随时扔掉的盒子。
