夜雨聆风「老板，出事了。AI 把生产数据库给删了。」
这不是段子，是真实发生的事故。某公司做了一个数据分析 Agent，让用户用自然语言查询数据，Agent 自动生成 SQL 并执行。某天用户问了一句「帮我清理一下测试数据」，Agent 很「聪明」地执行了 DROP TABLE。
结果就是半夜抢修，恢复备份，损失惨重。
当 AI Agent 获得代码执行权限时，一场潜在的灾难可能正在酝酿。今天这篇文章，我们就来聊聊代码执行安全沙箱的选型，以及那些必须跳过的坑。
为什么 AI Agent 需要执行代码？
代码执行让 Agent 从「会说话的搜索引擎」变成「能干活的助手」。
数据分析场景，用户说「分析一下上个月的销售数据，按地区统计」，Agent 需要生成 SQL、执行查询、计算结果、生成图表。自动化操作场景，用户说「帮我把这些图片都转成 PNG 格式」，Agent 需要遍历目录、调用图像处理库、批量转换。API 集成场景，用户说「帮我查一下快递到哪了」，Agent 需要调用 API、解析结果、整理输出。
能力越大，风险越大。让 AI 执行代码，风险主要有四类：误操作（AI 理解错误用户意图）、提示词注入（恶意用户诱导执行危险操作）、资源滥用（死循环、内存泄漏）、越权访问（读取敏感文件、获取密钥）。
这些风险任何一个爆发都是事故。所以我们需要把 AI 执行代码的环境「关起来」，这就是沙箱。
很多团队在选型时容易走极端：要么全部用 Docker 容器，启动慢但求心安；要么全部用轻量方案，快是快了但防护不够。
四类主流方案各有优劣：
Docker 容器是最常见的方案，隔离性好，容器崩了不影响宿主机，资源可控。但冷启动需要 1-3 秒，每个容器都有资源开销，适合执行频率不高、对延迟不敏感的场景。
WebAssembly 是新兴方案，启动快到毫秒级，资源消耗小，天然内存安全。但生态不完善，很多库不支持，Python 支持有限，适合纯计算任务和轻量级脚本。
云端沙箱服务（AWS Lambda、Google Cloud Functions 等）免运维、天然隔离、弹性扩展。但按执行次数计费成本高，有网络延迟，代码在别人服务器上跑存在数据安全担忧，适合早期验证。
进程级沙箱（seccomp、AppArmor）启动最快、资源开销最小、可精细化控制。但配置复杂容易出错，跨平台性差，安全性依赖配置质量，适合有专业安全团队的场景。
正确做法是混合方案：低风险操作用进程级沙箱（快），高风险操作用 Docker 容器（稳），超高风险操作直接拒绝。实测数据显示，90% 的操作是低风险的，用快速沙箱处理，平均延迟只有 180ms；高风险操作虽然延迟 2.1 秒，但出问题也不怕。
风险分级是混合方案的核心，但很多团队的分级规则要么太松要么太紧。
经过实战验证的分级规则：
低风险包括纯计算（数学运算、字符串处理）、读取预定义的数据、调用白名单内的 API。这类操作用进程级沙箱即可。
中风险包括文件读取（但限定目录）、数据库查询（但只读）、网络请求（但只能访问白名单域名）。这类操作需要更严格的隔离。
高风险包括文件写入、数据库写入、任意网络请求。这类操作必须用 Docker 容器。
超高风险直接拒绝，包括系统命令执行、访问敏感路径、删除操作。开头那个 DROP TABLE 的案例，如果有这层防护，根本不会发生。
分级的好处是速度快、安全、成本低。不用所有操作都开 Docker，省资源；高风险操作用强隔离，出问题也不怕。
很多团队把全部希望寄托在沙箱隔离上，忽略了一个更高效的防线：在执行代码之前先做静态分析。
静态审计能拦截 60% 以上的危险代码，检查项包括：有没有危险函数（os.system、eval、exec）、有没有访问敏感路径、有没有无限循环的嫌疑、import 的库是否在白名单内。
如果发现危险代码，直接拒绝执行，根本不进沙箱。这一层防护成本极低，效果极好。
但 Python 的动态特性让静态分析很难覆盖所有情况。import os 然后 os.system 这种太明显了能拦住，但 from os import system as s 然后 s() 呢？或者 import('os').system() 呢？甚至 getattr(import('os'), 'system')() 呢？
解决方案是多层防护：静态分析做第一道防线，运行时用 seccomp 限制系统调用，Docker 做最后一道隔离。三层防护，层层递进。
AI 生成的代码可能有死循环、内存泄漏等问题。一个递归函数忘了终止条件，CPU 就跑满了；下载一个超大文件，磁盘就爆了。
必须设置的资源限制：
超时控制：简单计算 5 秒，数据查询 30 秒，复杂任务 2 分钟。超时就强制终止，宁可失败也不能卡住。
资源上限：内存 256M，CPU 0.5 核，存储 100M。Docker 容器天然支持这些限制。
网络隔离：默认禁止所有网络访问。如果任务需要网络（比如调用外部 API），需要显式声明，且只能访问白名单域名。
日志审计：所有代码执行都有完整日志——谁执行的、什么时候执行的、执行了什么代码、执行结果是什么、资源消耗多少。出了问题可以追溯，也方便后续分析优化。
Docker 不是配上就安全了，配置不当可能让隔离形同虚设。
符号链接攻击：AI 生成的代码可能创建符号链接，指向沙箱外的敏感文件，然后读取它。解决方案是禁止创建符号链接，文件操作前检查路径是否在允许范围内。
环境变量泄露：Docker 容器如果配置不当，可能继承宿主机的环境变量，而环境变量里经常存着各种密钥、密码。解决方案是容器启动时显式设置环境变量，不继承宿主机。
容器逃逸：Docker 不是 100% 安全的，历史上出现过多次容器逃逸漏洞。解决方案是及时更新 Docker 版本，使用 rootless 容器，容器内用非 root 用户运行，宿主机也做安全加固。
这些细节看起来不起眼，但任何一个疏漏都可能成为攻击入口。
实战效果验证
按照上述方案部署三个月后的数据：日均执行 5000+ 次，静态分析拦截 62% 的危险代码，执行成功率 94%，安全事故 0，平均延迟低风险 180ms、高风险 2.1 秒。
0 安全事故是最重要的指标。
写在最后
让 AI 执行代码是 Agent 能力的重要扩展，但能力越大风险越大。沙箱不是万能的，但没有沙箱是万万不能的。
核心原则四条：最小权限，只给 AI 需要的权限，不多给；分级处理，不同风险等级用不同方案；多层防护，静态分析 + 运行时限制 + 隔离环境；可追溯，出了问题能查到原因。
安全这个事，宁可过度设计，也不能心存侥幥。
本文部分图片来源于网络，版权归原作者所有，如有疑问请联系删除。
