我做过一个模拟项目X给某个大模型驱动的Agent配了几个工具本来只想让它帮忙清理临时目录、整理日志结果它在某次执行时递归扫描了整个工作区把里面积累的构建缓存和中间产物全删了。那次事故让我认清一件事AI Agent的判断力和执行力是两回事判断错了没事执行错了就难挽回了。从那以后我给所有需要落地的Agent动作都套上了一层沙箱也就是常说的AI Agent沙箱。这篇文章把我搭建这套隔离环境的完整思路、方案选型和踩坑记录都写出来给同样被Agent不听话折磨过的人一个可以照着做的参考。1. 为什么Agent必须被关进沙箱一次失控引发的复盘先讲那次事故。项目X的Agent被授权调用一个“执行Shell命令”的工具我当时还给这个工具配了挺详细的自然语言描述告诉它“可以清理临时目录、可以删除过期文件”它确实理解得很好但执行时它扫描了所有包含“tmp”的文件夹把项目里另一个团队共享的中间产物目录也当成了缓存直接批量删除。事后复盘时我发现这不是模型笨是我给的权限太宽了。1.1 事故复盘一个目录清理的教训我后来把Agent那次的所有日志都翻了出来。它的思路其实很直接先列出所有文件夹用关键词判断哪一些像缓存然后执行“删除旧文件”。问题出在“关键词判断”这种模糊逻辑放在文件系统上风险非常大。我给的Shell工具没有路径白名单没有后缀名限制也没有操作前确认机制等于把一整台开发机的命运交给了一个概率模型。这里有个很核心的认知Agent不是一个传统意义上的程序它不会觉得自己做错了它只会继续按照“最可能让用户满意”的方向执行。你给它一个“清理临时文件”的目标它就可能自主解释出“删除所有看起来没用的文件”这个子目标。如果我们不给它一道物理边界它在边界内的每次尝试都可能造成真实的破坏。那次事故之后我的原则变成了Agent可以想得很开放但动手必须很封闭。所有的文件写、命令执行、网络访问都默认先进沙箱由沙箱规则而不是模型意图来决定“能不能做”。1.2 Agent失控的几个真实路径我后来专门梳理了Agent失控的常见路径基本可以归纳成四类工具误用模型理解错了工具语义比如把“清理临时目录”理解成“删除所有tmp前缀目录”。无限重试Agent遇到报错后反复重试每次都执行同样的操作造成资源叠加消耗。权限侧漏工具的意图是读取某个文件但模型传入了带有路径穿越的参数超出了规定范围。外部内容诱导Agent读取到一段被污染的内容比如网页、文档、工具返回信息然后这段内容反过来影响了它后续的工具选择。这四条路径有一个共同点光靠模型本身的自律解决不了必须在模型和真实环境之间加一个强制执行层。这个强制执行层就是我们说的沙箱。它不是一个单一功能而是权限、网络、资源、审计四件事的集合。2. 沙箱的三个边界权限、网络、资源既然沙箱是给Agent划定活动范围的那范围到底要划在哪几个维度上我自己的经验是三个边界必须一起设缺一个都会有隐患。2.1 权限边界最小权限与工具清单第一个边界是权限这是最容易被想到但最容易被做错的部分。不少人觉得权限边界就是“用非root用户跑Agent”实际上这远远不够。我给模拟项目X重新设计的权限模型核心是“可枚举工具清单”。Agent不能直接执行Shell命令它只能调用我定义好的几个工具比如“列目录”、“读取文件内容”、“在指定目录创建文件”、“删除指定后缀的过期文件”。每一个工具的入参都有明确的Schema校验限制比自然语言描述严格得多。举个例子删除过期文件的工具我要求它必须传两个参数目标目录和匹配模式。然后代码层再校验目标目录必须位于工作区下匹配模式不允许未被列入白名单的递归标记。这样就算模型理解得再飘逸真正落到文件系统上的动作是受限的。可以用下面这段逻辑做个示意ALLOWED_DIRS {/workspace/project-a, /workspace/tmp-cache} FORBIDDEN_EXTENSIONS {.key, .env, .db, .pem} def validate_delete_target(path: str) - str: resolved os.path.realpath(path) base resolved ok False for d in ALLOWED_DIRS: if resolved d or resolved.startswith(d os.sep): ok True break if not ok: raise PermissionError(f目标目录不在允许列表内: {path}) ext os.path.splitext(resolved)[1].lower() if ext in FORBIDDEN_EXTENSIONS: raise PermissionError(f禁止删除该类型文件: {path}) return resolved我把这套逻辑叫做“审查器”。审查器放在模型与工具之间所有工具调用都必须先经过它才能继续。实际运行下来审查器拦截掉的危险调用比我想象的多有一段时间平均每几十次合法调用就会拦下一次异常路径。2.2 网络边界决定Agent能不能“往外跑”第二个边界是网络。很多Agent场景下大模型本身需要通过API访问但这不代表Agent所在的运行环境必须全开放网络。尤其是当Agent会读取网页、下载附件、调用第三方服务的时候如果完全不限制网络访问那沙箱的隔离价值就少了一半。我的做法是默认禁网按需开放白名单。Agent运行环境只允许访问明确列出的域名和端口。比如需要查看某几个固定的文档站点就把这些域名加进白名单其余的网络流量一律丢弃。对于需要调用外部API的工具我会把它封装成沙箱外的一个代理服务由代理服务去访问外网沙箱内只允许和这个代理建立连接。这样做的最大好处是就算Agent真的被诱导、试图下载一个恶意脚本它也没有网络出口去把东西拉进来外发的数据也传不出去。网络限制的配置可以做得比较粗也可以做得细。我用的方案是分层匹配先看目标IP和端口是否在允许列表再对URL路径做二次校验。这样既能满足业务需求也堵住了一些奇怪的迂回访问方式。2.3 资源边界没有限制就有随机故障第三个边界是资源。Agent任务有一个特点你很难提前知道它要跑多久、要占多少内存。它在思考时可能调用模型多次在执行时可能写大量临时文件。要是完全不设置配额一个失控的Agent足以把一台机器吃满甚至影响到宿主机上其他服务。我一般会给每个Agent执行环境设定这组硬限制CPU配额控制在 0.5 到 2 核之间内存限制在 512MB 到 2GB 之间超过直接杀掉磁盘写入量限制比如最多只能写 500MB单次任务最长执行时间比如 10 分钟最大进程数限制在 32 个以内最大输出日志体积防止Agent疯狂打印。这些数字不是拍脑袋定的是要根据任务类型调整的。比如单纯做文件解析的任务512MB 内存足够但如果Agent需要跑数据预处理、加载模型文件那就得放宽到 2GB 以上。关键是“有上限”而非“上限有多高”。资源边界给了系统一个容易预测的恢复路径超了就终止终止后重新调度。这比让失控任务自己跑完要可靠得多。3. 四层沙箱方案怎么选从函数级到虚拟机边界定好之后下一步是选实现方式。沙箱的隔离强度从轻到重有好几个层次我把它分成四档每一档适用的场景差异很大。3.1 轻量方案一函数级沙箱最轻的一档是函数级沙箱严格来说它没有独立的运行环境只是在Agent的调用链上做参数校验、输出约束和频率控制。比如前面提到的审查器就属于这一类。函数级沙箱的好处是几乎没有性能损耗Agent仍然在宿主机环境里执行只是每次工具调用前多了一次规则判断。缺点是隔离能力很弱Agent进程本身还在宿主机系统内一旦出现底层命令行注入光靠函数级校验挡不住。我个人的使用建议是当Agent只是进行纯信息处理不需要执行任何系统命令时函数级沙箱够用只要涉及文件修改、进程创建、命令执行它顶多只能当第一道防线不能当唯一防线。3.2 轻量方案二进程级隔离第二档是进程级隔离也是我用得最多的一档。它的思路是Agent的所有命令执行、脚本运行都放进一个独立的容器运行时里这个运行时有自己独立的文件系统视图、进程空间和资源配额。具体配置上我会把根文件系统挂载为只读Agent只能写单独挂出来的临时工作目录进程以非特权用户身份运行默认关闭网络按需打开白名单再配合资源配额和进程数量限制。这样做的好处很直接Agent在里面随便折腾折腾坏的无非就是那一个小工作目录宿主机上的其他数据碰不到。而且容器方案的启动速度足够快通常几百毫秒到一两秒就能拉起一个环境可以做到每个任务一次性的干净环境用完直接销毁不留残留。3.3 重量方案虚拟机与微虚拟机第三档是虚拟机级隔离隔离强度最高代价是启动慢、资源开销大。它对宿主机的内核不透明Agent在里面执行任何操作都相当于在另一台独立机器上操作。这类方案适合两种场景一种是运行完全不可信的代码比如从网上下载来的二进制文件另一种是需要高置信度隔离的审计场景要求绝对不能在宿主机留下痕迹。也有把它用在浏览器自动化场景里的每次页面访问都开一个干净的虚拟机环境防各类投毒和指纹追踪。轻量虚拟机是这一档里比较推荐的选型它的启动速度介于原生虚拟机和容器之间同时保留比较强的隔离。对大多数Agent运行场景来说容器方案的隔离已经足够虚拟机属于“更重但更让人安心”的可选项。3.4 方案对比为了让大家看着更直观我把四档方案的取舍列成一张表方案隔离强度启动速度资源开销维护成本适用场景函数级沙箱低几乎无感极低低纯信息处理、工具调用校验进程级隔离中高百毫秒级中中常规Agent执行环境轻量虚拟机高秒级高高不可信代码、浏览器自动化完整虚拟机极高数十秒级极高很高强隔离审计、实验环境从实践来看大部分Agent落地场景不需要直接梭哈到虚拟机先把函数级沙箱和进程级隔离做好已经能拦住绝大多数风险。真正需要虚拟机时往往意味着Agent要做的事本身就不适合放进常规工作流。4. 从零搭建一个最小可用的Agent沙箱方案选型之后我再说说具体怎么搭一个能用的Agent沙箱。这一整套东西不复杂核心就四个组件工具协议、审查器、看门狗和审计。我就按这个顺序讲。4.1 第一步定义工具协议第一步是把Agent能做的事全部转成结构化的工具调用协议。不要再让Agent直接面对命令行而是为它暴露一组JSON格式的API。我给模拟项目X定义的工具协议长这样{ tool: file_operation, op: delete_expired, params: { base_dir: /workspace/tmp-cache, pattern: *.tmp, older_than_days: 7 } }每个字段都有明确的Schema约束。比如base_dir只能从预置目录列表枚举pattern不允许包含路径分隔符older_than_days设置取值范围。模型输出一旦不符合Schema这次调用就直接报错不会进入下一步执行。这一步很关键因为它把“模型说什么”和“系统做什么”之间的距离拉开了。模型可以自由发挥但要执行真实的文件操作必须把自己的意图翻译成这种受限协议。4.2 第二步实现审查器协议定了之后审查器负责执行前校验。它的任务是多查几层我自己实现的逻辑里除了路径校验还会做这么几件事检查操作类型禁止删除类操作落在只读区域检查目标后缀禁止操作敏感配置文件检查参数组合禁止同时指定递归删除和宽泛匹配模式检查频率同一路径在短时间内不能被高频操作。举个例子文件删除类的操作我要求必须同时满足三个条件才放行目录白名单匹配、后缀不在禁止名单、且不是目录整体递归删除。任何一项不满足都会被拦下。前面已经给出了路径校验的示例代码这里再补充一下参数校验的逻辑def validate_file_operation(op: str, params: dict): base_dir params.get(base_dir) pattern params.get(pattern, ) recursive params.get(recursive, False) if op delete_expired: if base_dir not in ALLOWED_DIRS: raise PermissionError(目录不在白名单) if .. in pattern or / in pattern: raise ValueError(pattern 不允许包含路径分隔符) if recursive and pattern in (*, .*, ): raise PermissionError(禁止通配全部文件) if FORBIDDEN_EXTENSIONS.intersection(extract_exts(pattern)): raise PermissionError(操作对象包含敏感后缀)这套校验看起来简单但非常实用。Agent执行的绝大多数危险操作本质都是参数组合出了问题而不是底层漏洞。审查器把组合空间缩小到可接受范围风险自然就低。4.3 第三步加看门狗审查器管的是“能不能执行”看门狗管的是“执行之后怎么停下来”。Agent任务容易出现僵尸进程、无限循环和资源膨胀光靠审查解决不了必须在运行时加约束。我在Agent执行环境里部署了一套看门狗机制准确说是三分钟一切断时间看门狗任务超过预设时长立刻终止进程组内存看门狗内存占用超过配额触发OOM终止输出看门狗标准输出和错误日志超过固定大小后续输出直接丢弃并标记异常。这三个看门狗里时间看门狗最重要也最容易被忽略。很多人只设资源配额却不设置“任务总时长”结果Agent进入了死循环后虽然内存占用不高但一直在消耗CPU重试。给它加一个总执行时限循环再多也会被直接终止。4.4 第四步审计与影响回滚最后一步是审计。沙箱不只是防止坏事发生还要在坏事发生之后能追溯。每次Agent工具调用我都记录这几类信息请求原文和解析后的参数调用时间、耗时、资源消耗目标路径和涉及的进程最终执行结果和返回码。除了记录日志我还会对Agent可能修改的目录做写入前快照。它的工作区是独立的修改前做个归档拷贝一旦发现执行结果异常我可以直接把工作区恢复到调用前的状态。这个方法虽然原始但非常有效能够兜住大多数“文件被清空”的意外。5. 我踩过的几个坑从镜像到环境变量的连环翻车搭建沙箱的过程中我踩过不少坑有些坑当时花了我一整天排查。我把五个最容易反复出现的拿出来说说希望你能跳过。5.1 基础镜像里残留了不该有的工具第一次搭进程级隔离环境时我直接基于一个通用镜像来跑Agent里面预装了编译器、包管理器、调试工具、网络工具等一堆东西。Agent执行的很多命令本身可能没啥问题但就因为镜像里有那些额外工具它的能力边界被撑大了。比如agent 本来只需要读取文件但它发现环境里有一个功能强大的通用解释器于是自作主张地调用它去执行一段动态拼接的脚本。虽然最终没出事但这类行为完全超出了预期范围。解决办法是给不同场景制作精简镜像。Agent需要什么功能就把对应工具装进去其余的全部拿掉。我后来甚至会主动检查镜像里有没有能发起网络连接的客户端统一移除或替换为禁用版。5.2 临时目录成了公共市场另一个让我翻车的点是临时目录。多个Agent实例共享同一个全局临时目录时不同任务之间可能互相读到对方留下的文件。更麻烦的是Agent有清理临时目录的习惯它可能会把其他任务还在使用的中间文件当垃圾清掉。解决方式是在沙箱里给每个任务分配独立的临时目录并在启动时通过环境变量注入给Agent。任务结束之后整个目录直接销毁不存在共享问题。这也顺便解决了文件残留和信息泄漏的问题。5.3 环境变量里的密钥陷阱环境变量是Agent最容易泄露敏感信息的地方。很多应用默认会把自己的数据库连接串、访问令牌、内部服务地址暴露在环境变量里。Agent为了执行任务可能需要打印环境变量或者把某个环境变量的值写入文件。一旦这些敏感信息出现在它生成的日志或数据文件里等于间接泄露了一次。我的建议是沙箱环境内不配置任何真实敏感凭证。Agent需要访问某个服务时由外部网关完成身份认证沙箱内只拿到一个临时、限权的短期凭证。这样就算Agent真的往外传环境变量拿到的也是没用的东西。5.4 别再迷信“加个提示词就安全了”早期我还犯过一个错误试图用系统提示词约束Agent的行为在提示里写“千万不要删除重要文件”“不要访问外部网络”。实测下来这类软约束效果很差。模型有时候理解得很好但在上下文变长、任务变复杂后很容易被新的指令覆盖掉。一个让Agent去读取某个网页的任务本质上给了那次会话注入新规则的机会。所以现在我的态度很明确安全性和合规性不能让Agent自己负责必须由沙箱硬性执行。提示词里的约束只是锦上添花真正挡住危险动作的是协议、校验和运行限制。5.5 单点沙箱还不够别忘了外部依赖最后一个坑比较隐蔽。进程级隔离只能保护Agent运行直接所在的OS环境但如果让它访问某个数据库或外部接口所有这些下游依赖并没有被沙箱保护起来。Agent可能通过一个正常的工具接口对数据库执行了很多次查询相当于脚本小子在打你的数据库。所以我后来会给这些外部依赖也加一层防护Agent专用的数据库账号只能操作指定的表和行外部接口设置速率限制每个工具的入参都限制数据返回量。这类措施虽然不在严格意义的“沙箱”范围内但缺少它们沙箱的总体安全目标依然会破功。6. 给Agent上保险而不是限制它的可能性我看过不少团队对给Agent套沙箱这件事有抵触情绪觉得这会束缚Agent的能力让它变得“不聪明”。我的亲身体会恰恰相反沙箱去掉的只是那些不该有的风险真正留给Agent的发挥空间依然很充裕。在权限可控、网络收敛、资源有界的前提下Agent可以放心大胆地编排文件、批量处理数据、尝试不同方案。我甚至敢让它自动跑完一整条数据处理链路这在以前是完全不敢想的。沙箱给了我放手的底气也让我更愿意把更多任务交给Agent去做。另外一个小建议不要一次性把所有边界都配到最严格可以根据风险等级分步放开。先跑通最小限度环境然后观测审计日志持续根据拦截记录调整规则。这样我的Agent既保持着实用性又始终活动在一条清晰、可回滚的边界内。