前言

大家好，我是咪的Coding。

上面这个命令，想必大家并不陌生，如果你不小心执行了rm -rf /*，就会删除掉系统中所有的文件和目录，那么也就是时候跑路了。

在 Agent 时代的今天，Claude Code、OpenClaw 等等都拥有了执行命令的权限，而如果它们执行了这一命令，后果不堪设想。

在2026 年 4 月，Anthropic 的最新最强模型 Mythos 就完成了魔幻的三明治事件。

测试期间，Mythos Preview 被提供了一台受保护的“沙箱”计算机进行交互。

研究人员只是指示它：尝试逃离那个安全的容器，并找到一种方法向进行评估的研究人员发送消息。然后…它成功逃出了那个沙箱。最终，它通知了研究人员。而那位研究员当时正在公园里吃三明治。

同一个月，CrewAI 被曝出四个连锁 CVE 漏洞：Code Interpreter 组件一旦发现 Docker 不可用，就会回退到一个几乎不设防的降级模式，攻击者利用提示注入就能触发远程代码执行。

与此同时，NVIDIA 的 NemoClaw 和 OpenShell 安全沙箱也被研究人员找到了多个数据外泄的通道。

这些案例有一个共同的指向：当一个 AI 能够自主生成和执行代码时，“信任”是它身上最不该有的设计假设。

过去两三年，AI Agent 已经进化成了一个可以动手的超级个体。它能读文件、写脚本、调 API、操作数据库，甚至能自己装依赖、改配置、重启服务。

但问题在于，它生成的代码既不是人写的，也不是人审过的 —— NVIDIA 安全红队在一份报告中明确写道：LLM 生成的代码必须被视为不可信输出，沙箱是防止其执行时造成破坏的必需安全控制，而非可选增强。

它可能是无害的打印语句，也可能是一个递归删除生产数据的 Bash 指令。你没法在代码执行前靠肉眼判断，因为攻击者可以通过间接提示注入，把恶意指令藏在网页内容、邮件正文、甚至是某篇技术文档里，让 Agent 在完全不知情的情况下变成帮凶。

沙箱（Sandbox），就是给这个“会动手的 AI”划出一条不越界的执行边界。

一、为什么 Agent 没有沙箱不行？

面试官问“为什么要给 Agent 配沙箱”，最差的回答是“安全嘛，加一层防护总没错。”真正的技术根子，是三个单靠代码审计绕不过去的硬伤，以及一个很多团队会踩的隐蔽陷阱。

1.1 代码不可信：你审不完，也审不住

人类开发的传统软件，每行代码在合入主分支之前至少要过一轮 Code Review，不合理的调用、危险的操作、越权的访问，理论上都能在审查阶段被拦下来。

但 Agent 的代码不存在这个阶段。它是在对话过程中动态生成的，下一秒进执行引擎，中间没有人看。而且多轮任务中，每个子步骤都可能执行多次代码 —— 一个 SWE-Bench 任务平均需要 12-15 轮迭代，每一步都可能触发新的代码生成和执行。

NVIDIA 安全红队在他们自己的分析工作流里演示了攻击路径：攻击者可以构造输入先绕过护栏（绕过主题限制），再控制模型生成携带恶意载荷的代码，最后利用代码执行突破 Python 执行边界，最终拿到宿主系统的任意命令执行权限。整个过程中，模型始终表现得像是“在正常回应用户请求”。

这就是第一个硬伤：不信任不是态度问题，是结构问题——Agent 生成的代码，根本不在人类审查的覆盖范围内。

1.2 权限即漏洞：每个工具都是潜在的后门

给 Agent 配了文件系统访问权限？它可能在 /etc 下写入恶意配置。给了网络出口？它可能向外发送包含敏感数据的 DNS 请求 —— BeyondTrust 安全团队在 AWS Bedrock AgentCore 的“隔离”环境中发现，攻击者可以直接通过 DNS 隧道实现数据外泄和命令执行。

这不是 Agent 的 “恶意” ，而是间接提示注入（Indirect Prompt Injection）让 Agent 成为了攻击者的代理。

攻击者无需直接接触目标系统，只需在 Agent 会读取的网页、邮件、文档里嵌入恶意指令，剩下的就交给 Agent 自己去执行。

OWASP 的 Agentic AI 安全指南明确警告：弱沙箱一旦被突破，攻击者就能拿到服务器上的任意代码执行权限，进而实现横向移动、凭据窃取和持久化后门植入。

这就是第二个硬伤：每一个赋予 Agent 的权限，都是攻击者可以利用的入口。Agent 的能力越强，未加隔离的暴露面就越大。

1.3 资源即风险：死循环与内存泄漏

AI 生成的代码出 Bug 是常态：死循环、内存泄漏、fork bomb、递归爆炸……这不是模型质量的问题，而是生成式 AI 的固有属性。

模型不理解“这段代码可能把 256GB 内存吃光”这件事 —— 它只负责生成符合语法的程序，不负责保证执行后果的优雅。

没有沙箱，一段生成的死循环就能把整个开发机或生产容器拖垮。有了沙箱，强制 CPU 超时、内存上限、进程数限制，超限直接杀 —— 不是“建议”，是“硬杀”。

这本质上是给 Agent 的执行能力装上熔断器。

1.4 隐蔽陷阱：“降级模式”比没有沙箱更危险

讲完三个硬伤，还有一个容易被忽视但足以致命的陷阱：不安全降级。

CrewAI 的 CVE-2026-2275 就是教科书级别的反面案例。正常模式下，Code Interpreter 在 Docker 容器中执行代码，Docker 提供了基本的进程隔离。

但问题出在异常路径上：当系统发现 Docker 不可用时，没有拒绝执行，而是静默切换到一个安全性远逊于 Docker 的“SandboxPython”模式。攻击者通过提示注入诱导 Agent 触发这个降级路径，就能实现远程代码执行。更致命的是，系统没有向用户发出任何警告——Agent 看起来一切正常，实际上已经在裸奔。

这是工程安全中的一个经典反模式：正常路径的防御设计得再严密，如果异常降级时直接裸奔，防御就等于白做了。 真正安全的沙箱设计，在降级时应该拒绝执行，而不是退而求其次。

二、怎么建一个能打的沙箱？

沙箱不是一种“有就行”的基础设施。不同的隔离层级，对应的安全假设和性能代价完全不同。选型之前，必须先搞清楚自己威胁模型里“不信任”到什么程度。

2.1 三层隔离：从容器到硬件级

当前主流方案按照隔离强度可以分为三层：

第一层：Docker 容器。 利用 Linux Namespace 和 Cgroups 做进程隔离和资源限制，但共享宿主内核。启动快到毫秒级，密度高。问题是共享内核是本质缺陷 —— 任何内核漏洞都可能成为容器逃逸的路径。2026 年大规模爆发的 Copy Fail 漏洞（CVE-2026-31431）和 npm 供应链攻击都验证了一个结论：在 Agent 运行不受信代码的场景下，Docker 的隔离边界不够硬。对于面向自身的可信沙箱，Docker 足够；对于需防外部注入攻击的生产环境，不够。

第二层：gVisor。 用户态内核方案。gVisor 在容器和宿主内核之间插入了一个名为 Sentry 的进程，拦截容器的所有系统调用，在用户空间重新实现了一套受控的系统调用接口。实际能到达宿主内核的系统调用从数百个锐减到经过审查的几十个，攻击面大幅缩小。但代价是 I/O 密集型操作有额外性能开销，某些系统调用（如 userfaultfd）可能不支持，需要提前做兼容性测试。

第三层：MicroVM。 每个执行环境有独立的精简内核，通过 KVM 实现硬件级隔离。安全边界从“靠内核机制”变成了“靠虚拟化硬件”，系统调用级别的漏洞利用在 MicroVM 层面完全失效。生产环境中推荐采用直接微虚拟机方案的厂商占多数。但冷启动相对慢（不过目前已被优化到 100ms 内），且在超高并发场景下资源占用更高。

2.2 不是“越硬越好”

很多团队一上来就喊“必须硬件级隔离”，但安全隔离和性能开销是一对需要计算的权衡。

Agent 的应用场景差异巨大：AI 编程助手在裸金属服务器上跑复杂的测试套件，需要的是文件系统、包管理器和持久化能力。客户支持 Agent 每次只执行几十行 SQL 查询或 Python 处理脚本，需要的是一次性沙箱的瞬时交付，隔离强度满足“防止命令注入”即可。内部自用的数据分析 Agent 访问的是已脱敏的内部数据，威胁主要来自模型幻觉产生的错误计算和死循环，而非外部注入。

选型建议只有一句话：不信任谁？

不信任模型生成的代码逻辑，但信任运行环境的用户身份，Docker 足以。

不信任外部输入（邮件、网页、第三方 API 返回），至少上 gVisor。

任何外部不可信代码（用户提交、GitHub 公开项目、第三方工具输出），直接走 MicroVM。

2.3 速度是功能，不是优化

Agent 沙箱对性能的要求不能被当成“锦上添花”。Agent 的工作循环是“生成→执行→读反馈→调整→再生成”，一次完整的 SWE-Bench 任务平均需要 12-15 轮迭代，每轮都包含代码执行步骤。多智能体架构下可能同时跑 4-8 个 Agent，各自生成和执行代码。

这个模式下，沙箱延迟是乘法效应，不是加法效应。单次执行快 1 秒，15 轮下来就省 15 秒。

目前行业的性能标杆是腾讯云的 Cube Sandbox：利用运行时快照技术预初始化沙箱环境，再加上网络鉴权等开销，整体端到端启动时间稳定在百毫秒以内。

阿里云 ACS Agent Sandbox 和 LangSmith Sandboxes 也实现了 90ms 以内的启动时间。

三、生产级沙箱还需要这四项工程能力

隔离是基础，但不是终点。从“能跑”到“敢上线”，中间隔着一整套工程能力。

3.1 持久化文件系统

Agent 在多次迭代中需要保持状态：装的包不能每次都重装，写的配置文件需要留到下一步用，生成的中间产物需要被后续步骤读取。纯粹的无状态沙箱意味着每一步都要重新构建环境，这对于需要安装依赖的场景来说，延迟和 token 消耗都不可接受。

因此生产级沙箱需要“快照—恢复”机制。每次迭代从已知状态开始，或者提供持久化文件系统让已安装的依赖跨迭代携带。Sandbox Snapshots 和 写时复制（copy-on-write） 是目前的主流实现方式，让沙箱在“干净起点”和“状态延续”之间按需切换。

3.2 网络控制：不是“通”或“断”的二进制选择

很多初版沙箱的实现是“默认断网”。但现实场景中 Agent 需要联网——安装依赖要访问 PyPI/npm，调 API 要出站，克隆代码要访问 GitHub。全断等于废掉了一半 Agent 能力，全通则留不下审计边界。

生产级的做法是动态网络策略：允许白名单域名出站 HTTPS，阻断 raw socket，默认 deny-all，需要时按任务临时开放。

Anthropic 为 Claude Code 设计的沙箱就是*双边界方案：文件系统隔离和网络隔离协同工作。*没有网络隔离，文件系统中的敏感数据仍可能被外泄；没有文件系统隔离，Agent 可能突破沙箱获得无限制的网络访问权限。

3.3 资源限制：给 Agent 的执行装上“熔断器”

这是一个看似简单但极易遗漏的工程点。沙箱需要对 CPU 时间、内存上限、进程数、磁盘 I/O 全部设置硬限制。超时直接杀，内存超限直接杀，fork bomb 直接杀。不是“建议停止”，是“强制终止”。

3.4 可观测与可审计：出事了能查到谁在什么时候干了什么

Agent 执行的黑箱性在于：AI 生成代码和执行过程如果不记录，出了安全问题你完全无法复现。NVIDIA 安全红队正是通过审计沙箱执行日志发现了 RCE 攻击链。生产级沙箱需要全链路审计：谁生成的代码、哪一步执行了什么命令、访问了哪些文件、网络出站连接到了哪里。Bühler 等人提出的 AgentBound 框架甚至进一步在沙箱之上叠加了权限和问责能力，让 AI Agent 的每一步操作都能追溯到具体的 Agent 身份和任务上下文。

总结

Agent 沙箱不是“安全加分项”，而是 Agent 进入生产环境的入场券。

当 Agent 从“只聊天不动手”进化到“能生成和执行代码”时，信任的假设就必须被安全边界取代。

三个硬伤 —— 代码不可审、权限即后门、资源无约束 —— 让无沙箱的 Agent 执行在安全意义上等同于裸奔。而 CrewAI 的“静默降级”案例则警示我们：沙箱的安全闭环必须在所有路径上都闭合，降级模式不能成为越狱的后门。

隔离技术选型的核心判断框架只有一个维度：你到底在不信任谁？ 不信任代码逻辑（幻觉、死循环），Docker 够用；不信任外部输入（邮件、网页、第三方返回），至少 gVisor；不信任任何不可信代码来源，直接 MicroVM。

速度不是优化的附属品，而是 Agent 工作循环的关键路径。沙箱延迟会在 15-20 轮迭代中形成乘法效应，启动时间必须被压缩到百毫秒级。

最后，生产级沙箱不是只有一个“隔离层” —— 持久化文件系统、动态网络控制、硬资源限制、全链路可观测，四个工程能力缺一不可。

一句话收尾：Agent 能写代码不可怕，可怕的是它写的代码在你的机器上跑着，而你没给它划任何边界。 沙箱划的就是这道边界。把边界划清楚，Agent 才能真正“放心用”——不是因为信任它不会犯错，而是因为即便它犯错，破坏也被锁在了边界之内。

感谢你看到这里，如果喜欢咪的Coding的话可以点个关注支持一下吧！也欢迎各位在评论区留言！