企业官网建设流程全解析

我最早把 AI Agent 落地到业务里时，第一件事不是选模型，而是先解决一个看着很小的问题：Agent 生成的代码在哪里跑。当时我用 FastAPI + LangGraph 搭了一条工具调用链路，图省事直接 subprocess.Popen 去执行模型生成的 Python 脚本来做文件解析。结果模型在一段清洗 CSV 的代码里写了个 while True，整个实例的 CPU 被打满，我那台服务器上其他接口全部超时。那次事故之后，AI Agent 沙箱就成了我架构里的默认项，而不是可选项。

这两年我先后试过 E2B 这种基于 MicroVM 的执行沙箱、Modal 这种偏平台化的云端沙箱，也长期维护过基于 All-in-One 容器思路的自建沙箱。这篇文章不打算做纯概念科普，我按自己的理解讲讲这几条路线各自解决什么问题、适合什么规模的业务，以及真正决定选型的那几个指标。

1. 为什么 Agent 需要一个真正的执行沙箱：从一次被打爆的实例说起

1.1 Agent 不是只有"调用 API"这一个动作

传统业务代码里的风险是可控的，调用链路上的每个函数都是我们自己写的，输入输出边界清晰。但 Agent 不一样：它会把任务拆成多个工具调用，而这些工具里经常包含"生成一段代码并执行它"这类动作。

典型场景就是 Python 代码解释器。模型为了完成数据清洗、格式转换、文件处理，会生成暂时存在的脚本，你没法在运行前逐行审查。更麻烦的是，Agent 还会调用外部命令，安装依赖包、跑 shell 脚本、连接外部服务。这些动作如果直接在业务进程里执行，一旦出现死循环、内存暴涨、恶意读取系统文件，整个服务都会被拖下水。

我那次被打爆的事故，本质上就是缺少一层执行边界。subprocess 确实能启动一个新进程，但这个进程仍然共享宿主的内核、文件系统和网络栈。进程的唯一隔离手段是操作系统账号和权限，对资源消耗基本没有硬性限制。

1.2 隔离边界有四个层级，你要知道自己在哪一层

我在对比方案之前，先把自己脑子里那套"隔离坐标系"理清楚了。从宽松到严格，大致分四层：

• 子进程隔离：启动方便，共享内核，资源不可控，适合完全可信代码。
• 容器隔离：借助 Linux namespace 和 cgroup 做资源限制，密度高、启动快，但共享宿主内核，理论上存在内核逃逸风险。
• 用户态内核/轻量虚拟机：像 gVisor 这种给容器加一层用户态内核拦截系统调用，安全性和性能做了折中。
• MicroVM：像 Firecracker、Cloud Hypervisor 这种基于 KVM 的轻量虚拟化，每个执行环境有独立内核，隔离性最接近传统虚拟机，但启动延迟和内存开销都比容器高。

这四层不是谁替代谁的关系。很多做 Agent 执行底座的人会同时保留容器和 MicroVM 两条路，按任务的信任级别拆分。你首先要搞清楚自己业务里执行代码的信任边界：是内部同事提交的脚本，还是外部用户随意输入的内容，这两者的威胁模型完全不同。

1.3 你要隔离的不只是代码，还有网络和状态

选沙箱方案时，我见过很多新手只盯着"能不能跑代码"，忽略了另外两个同样重要的隔离面。第一是网络隔离。Agent 执行的代码可能需要访问公网 API，但它绝对不应该能访问你的内网数据库和管理端口。第二是状态隔离。沙箱里的工作目录、临时文件、环境变量必须和宿主隔离，否则上一次任务残留的脏数据会污染下一次任务，甚至通过磁盘文件把数据传出去。

所以我在评估一个沙箱方案时，会同时问三个问题：执行资源能不能限制死？网络进出口能不能控制？文件系统和持久化会不会泄漏？这三个问题的答案，基本决定了你最后该选 MicroVM、云端沙箱还是 All-in-One 容器。

2. E2B 的 MicroVM 路线：用一颗"迷你虚拟机"换回安全边界

2.1 E2B 的运行模型：为一个执行任务开一台微型机器

E2B 是我最早接触的 Agent 专用沙箱方案，它在技术上踩中的路线就是 Firecracker MicroVM。简单理解，每次调用 SDK 创建一个 Sandbox，实际上是在云端起了一台只有几十到几百 MB 内存的微型虚拟机，里面有完整的 Linux 用户态、shell、Python/Node 运行时，但和宿主之间隔着一层完整的虚拟化边界。

我当时用 Python SDK 写的调用大概长这样：

from e2b import Sandbox with Sandbox(timeout=60, memory_mb=256) as sbx: proc = sbx.run("python3 -c 'print(42)'") print(proc.stdout)

这段代码背后的逻辑值得展开说：Sandbox 对象代表一个独立的执行环境，timeout 控制整个沙箱的存活时间，超过之后会自动销毁，防止任务卡死烧钱；memory_mb 限制内存上限，防止脚本一个列表推导式把内存撑爆。创建完成后，可以往沙箱里传文件、执行 bash 命令、读取 stdout/stderr，甚至可以交互式地起一个 Jupyter Kernel。

这套 API 设计很明显是为 Agent tool-use 准备的：模型让沙箱去执行命令，沙箱把输出返回给模型，一次工具调用对应一个短暂的沙箱生命周期。

2.2 MicroVM 的强隔离到底强在哪里

MicroVM 和容器最本质的差别是内核边界。容器里的进程虽然被 namespace 隔开，但用的还是宿主内核，一旦某个系统调用存在漏洞，恶意代码拿到的就是宿主内核权限。而 E2B 这种基于 Firecracker 的沙箱，里面是一个独立的 guest 内核，代码再怎么提权，最多也就是把这台微型虚拟机的内核搞崩，宿主毫发无损。

这个特性决定了它最适合跑什么代码：不可信的、来自外部用户的、或者模型生成的临时脚本。如果你要做的是一个开放给用户提交代码的 AI Code Interpreter，或是一个允许第三方插件运行的 Agent 平台，MicroVM 几乎是唯一能让人安心的选择。

另一个值得说透的点是启动速度。很多人一听虚拟机就觉得要等几十秒，但 Firecracker 这类轻量虚拟化把启动过程优化得很极致，加上 E2B 用镜像模板和快照技术做预热，冷启动能压到秒级甚至更低。这个"秒级"和容器预热后的"百毫秒级"依然有差距，但在安全收益面前，对大多数 Agent 调用场景完全可接受。

2.3 什么时候不该选 MicroVM：性能和密度的真实成本

MicroVM 不是没有代价。每个沙箱都有 guest 内核和基础用户态的内存开销，同样一台物理机上能容纳的沙箱数量比容器少一个量级。对信任边界较高的内部脚本执行任务，比如跑一些固定的数据处理流程，上 MicroVM 属于杀鸡用牛刀，基础设施成本和工作量都会涨上去。

E2B 还涉及一个数据边界问题：托管的沙箱默认运行在它的云上，你的业务文件和 Agent 脚本要传到对方环境里执行。如果团队对数据出境和存储位置有强约束，就需要考虑自托管部署，自己管理 Firecracker 的虚拟机模板、镜像仓库和沙箱调度，运维复杂度会明显上升。

3. Modal 的云端沙箱：一个平台级的远程执行体系

3.1 从一次真实使用看 Modal Sandbox 的工作方式

Modal 和 E2B 不是一个物种。Modal 的核心是云端函数平台，你可以把 Python 代码定义成远程函数，不需要管服务器运维，平台自动伸缩、按量计费。Sandbox 只是它能力矩阵里的一项，更准确地说，它提供了一个可以任意执行命令的远程环境。

我当时用 Modal 做沙箱的代码大概长这样：

import modal app = modal.App("sbox_demo") sbx = modal.Sandbox.create( "python:3.11-slim", cmd=["python", "-c", "print('hello modal')"], volumes={"/workspace": modal.Volume.from_name("my-vol")}, timeout=60, ) print(sbx.get_logs())

这里有两个关键点。第一，Modal 允许你在函数或沙箱里挂载 Volume，这个 Volume 是平台上的持久化存储，多个沙箱可以共享数据卷。第二，Modal 天然有 scale-to-zero 能力，没有任务时平台会自动把资源缩掉，来任务时再拉起来，对 AI Agent 这种"低频但单次必需跑"的负载非常友好。

3.2 为什么我说 Modal 是"工作负载平台"而不是单纯沙箱

把 Modal 和 E2B 放在一起对比，很容易产生混淆，因为两个产品都能执行远程代码。但使用体验完全不同：E2B 的本体是沙箱，SDK 里围绕 Sandbox 做文章，模板、快照、命令执行都是服务于"给不可信代码一个封闭运行环境"这个目标；Modal 的本体是工作负载调度，沙箱只是它支持的运行形态之一，同样的底层能力还能跑批处理任务、跑 GPU 推理、跑定时调度、跑并行数据管道。

这个差异决定了一件事：如果你的需求只是"让 Agent 安全地执行一段不可信代码"，直接用 E2B 更顺；如果你的需求更宽，比如还要统一管理 GPU、批量任务、定时任务和数据卷，那 Modal 这类平台能把基础设施层一次性包圆。说白了，E2B 是给你一把锁，Modal 是给你一套带锁的房子，房子里的项目如果你根本用不上，那把锁就不算优势。

3.3 按量付费和云端依赖：省了运维，也交出了控制权

Modal 的计费模型是按实际使用资源计费，缩容到零时没有任何闲置成本。对个人开发者和中小团队来说，这比自托管一台沙箱服务器划算很多。但另一方面，你的任务执行变成了对云端服务的强依赖：网络延迟、平台版本变更、配额限制都会直接影响你的业务。我自己实际体验下来，Modal 的冷启动表现已经很优秀，但每次执行环境的下载和容器拉起，还是要比本地 Docker 预热池慢一个身位。

在数据敏感性不高的场景里，Modal 这类平台是很好的选择。我见过不少团队把 Agent 工具执行的负载放在 Modal 上跑，代码逻辑和结果数据都通过 Volume 管理，既省去了运维物理机的成本，又获得了一个相当不错的并发伸缩底座。

4. All-in-One 容器路线：AIO Sandbox 的"够用主义"

4.1 一体化的含义：一个容器，把运行时、依赖和工具链全部打进去

现在我重点聊聊自建方案里最常见的 All-in-One 容器路线，标题里的 AIO Sandbox 指的就是这种"一体化容器沙箱"思路。它不是一个特定产品，而是一种工程化范式：把 Agent 执行环境需要的所有东西，Python 运行时、Node 运行时、常用命令行工具、项目依赖、监控 agent、网络代理配置，全部放进一个可复现的容器镜像里。容器就是你的沙箱单元，镜像就是沙箱的模板。

一个最小化但完整的 Dockerfile 大概长这样：

FROM python:3.11-slim RUN pip install --no-cache-dir pandas numpy requests \ && apt-get update && apt-get install -y --no-install-recommends \ ca-certificates curl jq \ && rm -rf /var/lib/apt/lists/* WORKDIR /sandbox COPY entrypoint.sh /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"]

这里的关键不是把依赖装完，而是把沙箱的执行契约定清楚：固定工作目录、固定入口脚本、固定资源限制。启动时再用 docker run 把限制参数套上：

docker run --rm \ --cpus=0.5 \ --memory=512m \ --pids-limit=64 \ --network=none \ --read-only \ -v /tmp/workspaces/sbx-001:/workspace:rw \ my-aio-sandbox-image python main.py

这一行命令里没有炫技，但每一条 flag 都有明确目的：cpus 和 memory 限制 CPU 与内存，pids-limit 防止 fork 炸弹，network=none 直接断掉外部网络，read-only 让根文件系统不能再被写入，volume 只暴露一个临时工作目录。

4.2 容器沙箱的隔离强度：够用和"绝对安全"之间有一条线

容器沙箱最被人诟病的一点是共享宿主内核，这确实是真实的安全短板。但大多数内部 Agent 场景里的威胁模型，根本不需要对抗国家级攻击者。你要防的是模型写出的死循环、资源炸掉、误删文件、访问不该访问的内网端口，这些用容器限制参数就能挡掉百分之九十九。

如果还想往上补安全等级，不需要直接跳到 MicroVM，可以在容器运行时层面做文章。比如使用 gVisor 的 runsc 作为 runtime，给容器加一层用户态内核，拦截大部分危险系统调用；再比如叠加 seccomp 去限制可用的 syscall 集合。这些做的复杂度比维护一套 MicroVM 模板低得多，安全收益却非常接近。

当然我必须把话说直白：如果你的沙箱要承接的是外部用户随意提交的不可信任意代码，而且开放网络访问，那容器方案无论怎么加固都建议你再想想。这种场景直接上 MicroVM 路线更稳妥。

4.3 All-in-One 在 Agent 主流架构里为什么这么流行

现在很多 Agent 项目都是标准的三件套：FastAPI 做 API 层、LangGraph 或 LangChain 做编排、外部沙箱做执行层。AIO 容器路线在这个架构里非常丝滑，因为它不需要引入额外的云端平台，也不需要学习一套新的 SDK，所有沙箱就是容器，所有调度就是已有的 Docker/Kubernetes 能力。

我在社区里看到越来越多团队，包括做 Java 生态 Spring AI Agent 的人，都在走这条路：用一个通用沙箱容器镜像，让 Agent 的工具调用 handler 去启动它，任务结束就销毁。这种模式成本低、可解释性强、把你对基础设施的控制权留在自己手里，对那些"Agent 里跑的都是自己团队写的、相对可信的脚本"的场景，是最务实的解法。

5. 从冷启动到并发：真实选型指标与决策流程

5.1 别先看技术，先回答三个问题

很多热搜里都在问"AI Agent 怎么扛并发"，但并发方案的起点不是技术，而是任务模型。我一般会先把三个问题拍死：

• 任务时长多长？一个 bash 命令几秒跑完，和一个数据处理任务要跑十几分钟，对沙箱生命周期管理的要求完全不同。
• 调用方信任级别多高？内部自动化任务和外部用户触发的任务，隔离要求差一个量级。
• 并发曲线是什么形状？是大量短任务同时进来，还是一批长任务交错执行？

这三个问题的答案组合，直接决定了你该用哪种方案。短任务、低信任、高并发，这是 E2B 这类 MicroVM 需要做预热池才能抗下来的；长任务、内部信任、中流量，All-in-One 容器反而更经济；变动剧烈、想省运维、低频高爆发，Modal 的按量付费优势最大。

5.2 沙箱池化：真正帮 AI Agent 扛住并发的机制

并发能力的核心不在沙箱本身，而在沙箱池化。每个 Agent 任务如果都从零开始 create 沙箱，光环境加载就会把你的延迟和资源消耗推到高位。正确做法是把沙箱做成一个预热池：提前预启动 N 个沙箱，任务到达后从池子里取一个，跑完再放回去，而不是销毁重建。

我的一次实践是这样的：在 All-in-One 容器方案里，我用消息队列把任务分发给一组常驻的沙箱 worker，每个 worker 内部维护一个干净的临时目录，任务执行完清理现场，回到池子里等待下一个任务。只有遇到不可恢复的脏状态（比如进程被杀、文件系统损坏），才销毁重建。这样一个 200MB 的镜像基础上，单台 4 核 8GB 的容器实例可以稳稳扛住几十个并发沙箱任务，成本比每任务一个 MicroVM 低得多。

5.3 三套方案的关键对比

我整理了一张对比表，用来在团队里快速对齐选型思路：

表格里没有绝对的好坏，最后还是要回归到你的信任边界和成本模型。聊到这里，你会发现"AI Agent 怎么扛并发"这个问题的答案其实很朴素：并发不靠模型侧优化，靠执行层的池化和伸缩。任务的弹性和无状态化是前提，沙箱复用是手段，超时和资源限制是底线。

6. 我在沙箱落地过程中踩过的坑和现在的组合方案

6.1 镜像膨胀、状态污染和死循环：三个最容易烧钱的坑

第一坑是镜像膨胀。All-in-One 容器刚起步时，我图省事把训练推理用的依赖一股脑装进沙箱镜像，结果镜像从 300MB 一路涨到 1.5GB，每次冷启动都要多花十几秒。后来我把沙箱镜像拆成 base 层和任务层：base 只装运行时和基础 CLI，按需加载的依赖放到独立的层，甚至直接用 pip download 缓存来解决，启动时间明显降下来。

第二坑是状态污染。沙箱复用时，上一次工作目录里留下的缓存文件、临时数据会影响这一次任务的产出。我出现过 A 任务写入的文件被 B 任务误读取的乌龙。解决方案是固定契约：每任务用独立子目录，跑完强制清理，或者干脆用临时挂载卷做一次性 workdir。

第三坑是死循环。模型生成的代码里出现 while True 概率并不低，尤其是让 Agent 去爬数据、重试接口时。我第一次只设了命令级超时，忘了沙箱级 timeout，结果一个死循环任务在后台跑了半小时，按量计费的账单非常酸爽。现在的规则很简单：任何沙箱创建都必须携带 timeout，超时就是 kill，没有例外。

6.2 网络权限、持久化卷和日志：隔离边界的黑洞

网络是我后来才重视的坑。一开始我让沙箱开了全部网络，Agent 确实能访问外部 API 了，但在一次安全演练里，沙箱里的脚本居然顺利连上了同一个内网段里的 Redis，直接读到了生产缓存数据。自那以后，我所有自建沙箱都走显式代理白名单：默认只放行 Agent 运行必需的 API host，其他一律拒绝，内网 CIDR 在 iptables 层面直接丢弃。

持久化卷也有坑。Modal 的 Volume 和自建的共享卷，在多沙箱并发写同一个文件时会出现竞争。Agent 任务一旦都有"往同路径写日志"的习惯，你就等着看脏输出。规范路径是唯一的解法：每个沙箱拥有自己的命名空间前缀，写结果前先确认路径所有权。

日志则是另一个暗坑。Agent 执行命令产生的 stdout/stderr 如果全量收集，几轮工具调用下来就能把模型的上下文窗口撑爆。我给沙箱输出加了长度限制，默认只保留最后几千字符，截断时附一个标志，模型看完结果也够用，成本却能压下一大截。

6.3 我现在的默认组合：双轨制，不搞一家通吃

回到标题里那个"从 MicroVM 到 All-in-One 容器"的认知，我现在的落地做法是双轨制。外部用户触发的、代码不可信的 Agent 执行任务，走 MicroVM 路线，隔离第一，成本第二；内部自动化、数据管道、定时批处理这类信任度较高的任务，走 All-in-One 容器路线，密度第一，运维第二；Modal 这类平台则留给需要 GPU 或超强伸缩的专项任务，按量用、用完缩。

从 E2B 到 Modal 再到自建容器，切换过程中最大的收获不是学会了哪个平台，而是想明白了一个道理：沙箱选型本质上是在回答"你愿意为安全付多少成本、为密度牺牲多少隔离"。没有全能的沙箱，只有对得上业务模型的沙箱。先想清楚你的 Agent 代码从哪来、要到哪去，再回头选工具，每一步都会好走很多。