企业官网建设流程全解析

2026 年再聊 Agent，真正的落地瓶颈已经从“模型会不会推理”转移到“代码在哪里安全地运行”。你让 Agent 写代码、操作浏览器、调用十几个工具，每一步背后都必须有一个可控的隔离环境。可当你真正去选型时，会发现市场上很少有人把问题讲透：E2B、Daytona、Modal、Cloudflare、Vercel 都能运行代码，但它们的冷启动机制、计费粒度和网络策略完全不是一回事。

本文不会做无意义的“厂商排名”，而是提供一套评估框架，把五款常被放一起比较的 Agent 沙箱方案放到同一张桌上，重点分析三件事：冷启动到底有多快、按什么单位计费、网络边界是否可控。读完你至少能判断：自己的业务场景到底该优先考虑哪家，以及如何用最小成本完成一次真实验证。

1. Agent 沙箱选型，真正要解决什么问题

如果只看功能列表，E2B 有模板和快照，Modal 有 GPU 和函数调度，Cloudflare 有全球边缘网络，Vercel 有极简部署链路，Daytona 有开源自托管——看起来都很强。但实际接入 Agent 项目后，真正决定方案能不能上线的是下面三个问题。

第一个问题是冷启动。多步 Agent 的特点是“频繁短任务”：每调用一次工具，可能要启动一个新环境，用完再销毁。如果冷启动需要 5 秒，而模型推理只需要 2 秒，整个 Agent 的响应体验就会被拉垮。更麻烦的是，冷启动时间不稳定时，你的超时设置会变得很难写：设置短了任务容易被误杀，设置长了用户等待太久。

第二个问题是计费粒度。Agent 任务天然是“短时高频”的，一次工具调用可能只需要几百毫秒，但也可能因为模型跑偏而连续重试几十次。按秒计费、按请求计费和按资源小时计费，得到的账单结构完全不同。按秒的平台看沙箱存活时长，按请求的平台看调用次数，如果你的任务大部分时间在等待外部 API，按请求计费反而可能更贵。

第三个问题是网络策略。Agent 要访问公网搜索资料、调用第三方 API，有时候还需要让外部系统回调沙箱。这里埋着大量隐藏风险：沙箱能不能出网，能不能被入站访问，出站 IP 是否固定，请求会不会被目标站点的 Bot 防护拦截，日志里会不会泄露敏感信息。任何一个环节没设计好，Agent 在生产环境就会突然变“哑巴”。

所以，这篇文章真正要解决的不是“谁最好”，而是帮你建立一个选型坐标系：业务场景落在哪个象限，优先看哪个指标，如何用一段最小代码验证。

2. 基础概念：隔离、冷启动、按秒计费与网络策略

2.1 Agent 沙箱到底是什么

Agent 沙箱是一个运行不可信代码的隔离执行环境。普通后端服务运行的是我们自己写的代码，出了问题可以通过代码评审和测试覆盖控制；但 Agent 沙箱运行的是模型生成的代码，代码内容在运行前不可预知，可能调用危险命令、读取敏感文件、无限占用 CPU，甚至试图访问内网。因此它必须比普通容器更强调隔离、限制、审计和回收。

“沙箱”这个词听起来像一个安全软件，但放到 Agent 场景里，它更接近一个“可编程的临时计算机”。你需要能快速创建、执行命令、读取结果、销毁，并且整个过程可以被 API 自动控制。这决定了它不能只是一个 Docker 容器，还得有生命周期管理、计费统计、网络策略等工程能力。

2.2 隔离级别的演进

从隔离强度由弱到强，大致有四代方案。

第一代是进程级隔离。用一个 Python 子进程或 Node 子进程跑 Agent 代码，实现最简单，但几乎谈不上安全。进程可以访问宿主机文件系统，可以发任意网络请求，一旦代码失控，清理成本很高。它适合个人开发自测，不适合任何多租户场景。

第二代是容器级隔离，典型代表是 Docker。Docker 把文件系统、进程、网络做了命名空间隔离，镜像机制也方便打包依赖。它的缺点是隔离边界依赖内核安全能力，高并发创建容器时冷启动和资源占用都会成问题。

第三代是微虚拟机隔离，典型代表是 Firecracker 和 Cloud Hypervisor。每个沙箱运行在一个轻量虚拟机里，有独立内核，安全边界比容器更硬。E2B 这类专做 Agent 沙箱的平台，底层普遍采用这种方案，以换取更强的隔离和更可控的启动速度。

第四代是轻量隔离，典型代表是 Cloudflare Workers 底层的 workerd isolate。它不是虚拟化一个完整操作系统，而是在同一个进程里用 V8 isolate 隔离多个请求上下文。冷启动接近零，但能运行的代码类型受平台语言模型限制，不适合所有计算任务。

理解这四代方案，才能看懂为什么各平台的冷启动指标差异巨大：本质上不是营销包装不同，而是隔离技术路线不同。

2.3 三个关键指标的直观理解

冷启动可以理解成“从你按下启动按钮，到沙箱里能执行第一条命令”的等待时间。它由镜像拉取、虚拟机或容器启动、依赖加载、网络就绪共同组成。平台如果做了预缓存和模板预构建，启动时间会明显缩短。

按秒计费可以理解成“这台临时机器开机多久，就付多久费用”。分钟级计费适合长任务，秒级计费适合短任务，请求级计费则适合“每次调用极短、平台复用运行环境”的场景。没有绝对好坏，只看你的任务结构匹配不匹配。

网络策略可以理解成“这台临时机器能往外访问什么，外网能不能访问进来，以及访问过程是否可审计”。出站网络决定 Agent 能不能调用外部 API，入站网络决定回调能不能到达，审计日志决定出事之后能不能追溯。

2.4 平台概览

这张表是起点，不是结论。下面逐个拆解。

3. 五款平台定位与关键差异

3.1 E2B：为 AI Agent 执行而生

E2B 是五款里最“专一”的，它从诞生起就是冲着“让 AI 生成的代码安全运行”去的。它的核心产品是一个可编程沙箱，开发者在 SDK 里创建沙箱、写入代码、读取输出、关闭沙箱，整个交互围绕 Agent 工具调用设计。

在冷启动方面，E2B 的卖点是模板与快照机制。你可以把常用依赖构建成模板，沙箱启动时直接复用模板，而不是现场执行pip install。对于“每次都从零启动代码解释器”的 Agent 场景，这种预构建策略比通用容器更贴近真实需求。模板还可以带快照，执行到一半的状态能被保存和恢复，这对多步 Agent 很关键。

网络策略方面，E2B 提供沙箱 API 以控制代码执行和文件读写，同时支持出站网络访问。如果你是做 Python 数据分析工具这类 Agent，E2B 的 SDK 完整度会明显降低开发成本。它的短板在于：GPU 相关能力不如 Modal，边缘加速不如 Cloudflare，如果任务涉及大规模并行训练或纯前端体验，它不是最优解。

3.2 Daytona：从开发环境到可编程沙箱

Daytona 的定位长期是“开发环境管理器”，类似 Coder 的开源替代品，可以让团队在任意基础设施上创建标准化的开发环境。但从 2025 年开始，这类平台越来越重视 API 化能力，把开发环境的创建、连接、销毁变成可编程接口，这正好也符合 Agent 沙箱的调用方式。

如果你所在团队对私有化、数据合规有硬性要求，Daytona 这种有开源控制面、可自托管环境的方案优先级会明显上升。因为 Agent 沙箱的核心痛点之一就是“代码可能泄露”：如果代码必须留在公司内网，那么把沙箱托管在云端默认不是一个可选方案。

它的优势是灵活和自主，劣势也在这里：自托管意味着你要自己维护基础设施，冷启动优化、计费统计、网络策略都需要自己搭建。Daytona 更适合已经有 Kubernetes 或裸机集群、并有运维能力的团队，拿它当“环境层底座”，而不是开箱即用的 SaaS。

3.3 Modal：GPU 与大数据任务的首选

Modal 是一个 serverless 计算平台，支持 GPU、分钟级长时间运行、按秒计费。它不是专门为 Agent 设计的，但它非常擅长运行 Agent 生成的代码，尤其是涉及机器学习推理、数据处理、批处理任务时。

冷启动方面，Modal 采用了镜像预热、函数 Fast Launch、持久化文件系统等技术，对“首次启动要下载大镜像”的问题做了大量优化。你可以在函数定义里声明依赖和镜像，平台会在调用前准备环境，尽量复用热实例。

为什么建议把它列入 Agent 沙箱对比？因为很多 Agent 任务其实不是“运行几行 Python”，而是要调用 GPU 做图像生成、跑微调脚本、执行分布式数据任务。在这种场景下，E2B 的轻量沙箱可能不够用，而 Modal 的支付模型和资源能力更合适。它的网络策略比纯沙箱平台更接近“通用服务”，你需要在函数里通过环境变量注入密钥，并自行控制外部 API 的访问频率。

3.4 Cloudflare：网络策略与边缘隔离

Cloudflare 进入这个赛道的方式不一样。它不是做一个独立的“Agent 沙箱”产品，而是提供 Workers、Agents SDK、状态存储、网络策略等一整套边缘应用基础设施。运行在 Cloudflare 上的 Agent，本质上是一个个分布在边缘节点的 isolate，冷启动极快，天然具备全球网络加速能力。

如果你是做“需要访问公网、同时又要接受大量外部请求”的 Agent 服务，Cloudflare 的价值在于网络层：入口可以直接写 Worker，出口可以通过固定 IP 或代理策略控制，Bot 防护、限流、日志都可以在平台内闭环。很多 Agent 抓数据时会被目标网站拦截，这一层如果放在 Cloudflare 生态里处理，会比自建代理简单很多。

短板也很明显：边缘 isolate 不适合长时间运行的重型计算任务，模型推理、大数据处理这类工作交给 Modal 或自建 GPU 集群更合适。如果你已经深度使用 Workers，Cloudflare 应该是默认候选；如果你需要一个通用 Python 沙箱，它的学习曲线会更陡。

3.5 Vercel：面向前端体验的轻编排

Vercel 不是沙箱平台，但它是很多 Agent 产品的“脸面”。Vercel 的主要能力是前端部署、Serverless Function 和 v0 这类 AI 生成 UI 的工具。一个典型的技术栈是：用 v0 生成前端页面，用户在前端点按钮，请求到达 Vercel Function，Function 再调用真正的 Agent 沙箱服务。

Vercel 进入这个对比名单，意义不在于执行重型代码，而在于“编排层”。如果你的 Agent 产品主入口是 Web，用 Vercel 做前端和 BFF（Backend for Frontend）会非常顺畅。但请不要把长任务、敏感代码、不可信的模型输出直接放到 Vercel Function 里执行，它不是为这种场景设计的。Vercel Function 的计费按请求和执行时间计算，长时间占用会带来不必要的成本，也不如专用沙箱平台那样强调隔离安全。

4. 冷启动：怎么测试，为什么 p95 比平均值更重要

4.1 冷启动的组成

冷启动不是一个单一数字，而是一条链路。第一次创建沙箱时，平台要完成资源调度、镜像加载、网络初始化、依赖准备。平台宣传的“毫秒级冷启动”往往只计算了“调度时间”，没有计算“镜像拉取”和“依赖安装”。因此，你在文档里看到的冷启动时间和自己实际测出来的时间可能是两个完全不同的数字。

正确的测试方法，应该以“第一条命令开始执行”为完成点，而不是以“SDK 返回沙箱 ID”为完成点。只有这样才能反映 Agent 的真实体验。

4.2 用最小代码测冷启动

下面是一段用 E2B 经典 API 写的冷启动测试。它记录从创建沙箱到执行完第一条打印语句的时间。不同版本的 SDK 在方法名上可能不同，但核心流程一致：创建、执行、关闭。

# 文件：cold_start_test.py import time from e2b_code_interpreter import Sandbox start = time.time() sandbox = Sandbox() print("沙箱创建完成，耗时：{:.2f}s".format(time.time() - start)) code = "print('first command ok')" execution = sandbox.run_code(code, timeout=30) print("第一条命令输出：", execution.text) print("包含启动和执行的累计耗时：{:.2f}s".format(time.time() - start)) sandbox.close()

运行方式：

pip install e2b_code_interpreter python cold_start_test.py

这段代码的价值不是给你一个基准答案，而是让你在真实网络环境、真实资源规格下拿到自己的数据。同一个平台在不同区域、不同镜像大小、不同时间段的冷启动差异可能很大。你应该连续跑 10 次，记录 p50 和 p95，而不是只看第一次。

4.3 各平台冷启动优化机制

E2B 依赖模板和预构建镜像，让“安装依赖”这一步从每次执行变成一次构建。Modal 则通过镜像预热和函数实例复用做到热启动极快，冷启动尽量逼近“复用已加载环境”的水平。Cloudflare 的 isolate 天然冷启动极快，但那是把运行环境压缩到极薄之后的结果，能做的事情也有限。Vercel Function 的冷启动取决于会话复用率，如果你长期保持一定流量，热实例会比较多。Daytona 如果自托管，冷启动完全取决于你的基础设施条件，这既是坏消息也是好消息：你能控制一切，但也要为一切负责。

4.4 冷启动评测的常见误区

不要用“创建成功”代替“可执行第一条命令”。不要只测一次，冷启动指标天然有波动。不要用最简单镜像测试生产环境模板，生产级模板往往带着大量依赖，启动过程完全不同。更不要忽略区域因素，跨洋请求和同区域请求的差异会直接影响你设置的超时时间。把这些误区记下来，做的测试才有参考价值。

5. 按秒计费：没有绝对便宜，只有粒度是否匹配

5.1 四种计费粒度的本质

按秒计费按沙箱存活时间收费，适合“任务临时、环境用完即焚”的 Agent 调用。按请求计费看调用次数和单次时长，适合“调用极短、平台能复用运行环境”的 serverless 模式。按资源时长收费看的则是 vCPU、内存、GPU 这类资源占用，适合计算密集任务。按环境时长计费则多见于自托管开发环境，适合长周期开发协作。

真正的重要判断是：你的任务形态和计费粒度是否匹配。一个每次都启动新沙箱、执行 3 秒后关闭的 Agent，如果平台按“请求”计费但每次请求最少计 128ms，费用不会太高；如果按“环境小时”计费，哪怕每次只运行 3 秒，一天调用一万次，费用也会迅速膨胀。反之，一个长期驻留、有状态的 Agent 服务，按请求计费可能比按秒计费便宜得多。

5.2 用一个任务模型换算成本

假设你有一个 Agent 任务，每个任务平均包含 3 次工具调用，每次工具调用在沙箱里执行 5 秒：

• 按秒计费时，成本约等于 15 秒的沙箱运行时间，再乘以每秒单价和资源规格。
• 按请求计费时，成本取决于 3 次函数调用的最小计费单位，以及平台是否会把沙箱初始化算作一次额外调用。
• 按资源小时计费时，你需要把 15 秒折算成资源小时，再乘以 vCPU 与内存价格。

不需要记住具体数字，但要记住这个换算逻辑：任何平台给出的单价都只是“标签价”，你要把任务的真实调用模式带入公式，才能知道谁划算。如果平台有免费额度，也记得把免费额度折算进月度总成本。

5.3 计费陷阱排行榜

第一是沙箱忘记关闭。创建了沙箱但代码运行时报错中断，没有走finally里的关闭逻辑，沙箱一直存活，账单默默上涨。第二是重试风暴。Agent 调用外部 API 超时后自动重试，每次重试都创建新沙箱，冷启动和运行费用被成倍放大。第三是空闲回收策略缺失。沙箱执行完任务但处于“等待外部数据”状态，如果没有平台级 TTL，它可能一直挂着。第四是存储与网络单独计费。很多平台除了计算费用，还会对持久化卷、出站流量单独收钱，这部分容易被忽略。

5.4 给 Agent 加“预算护栏”

无论选哪家平台，都应该在代码层面设置最高执行预算。一个最简单的做法是给沙箱设置 TTL，并在finally中强制关闭：

from e2b_code_interpreter import Sandbox sandbox = Sandbox() try: # 假设这是一段可能卡住或触发重试的 Agent 代码 execution = sandbox.run_code( "print('working...')", timeout=30, ) print(execution.text) finally: sandbox.close()

这样做保证无论代码是否成功，沙箱最终都会被关闭。真正生产环境里，你还需要在平台控制台设置账单告警，并建立每日用量审计任务，只看 “运行成功率” 是不够的，要看到每次任务的总时长和总费用。

6. 网络策略：Agent 沙箱最容易被忽略的安全边界

6.1 网络需求分类

Agent 沙箱的网络需求可以拆成三类：出站访问、入站回调、内部网络隔离。出站访问解决的是“沙箱里的代码能不能请求公网”，入站回调解决的是“外部服务能不能把结果通知回沙箱”，内部网络隔离解决的是“沙箱是否可能访问到你的内网资源”。这三类需求不是所有平台都默认支持，也不是开了就行，还要考虑认证、白名单、审计。

很多开发者在选型时只关心能不能上网，忽略了入站和隔离问题。结果就是 Agent 能访问公网，但也能任意访问公司内网；或者外部回调不需要认证，任何人都能向沙箱发送伪装数据。这在生产环境是严重的安全漏洞。

6.2 出站网络：白名单、固定 IP 与 Bot 识别

出站网络最理想的做法是默认关闭，按需开启并配置域名白名单。如果一个 Agent 只需要访问固定的三个 API，那就没必要让它访问全网。部分平台支持固定出站 IP，你可以把该 IP 加入目标服务的白名单。

这里还要特别提一下 Bot 识别问题。如果 Agent 抓取的是公网数据，请求到达目标站点时，目标站点可能使用 Cloudflare 等服务的 Bot 防护。Agent 请求如果缺少正常的 User-Agent、TLS 指纹，或者请求频率过高，很容易被判定为 Bot 并返回 403。这不是沙箱平台的 bug，而是网络请求策略问题。你需要合理设置 User-Agent、控制请求频率、必要时使用固定 IP 加入白名单。

6.3 入站网络：回调 API 必须认证

如果沙箱执行的是一个异步任务，外部系统需要回调结果，务必为回调入口增加认证。最直接的方式是让外部系统在请求头里携带令牌，接收方校验通过后再处理。Cloudflare Worker 这类边缘函数天然适合做这个入口，它可以把请求做一层校验和转发，同时保留日志。

6.4 Cloudflare Bot 管理给 Agent 生态带来的启示

在 Cloudflare 后台的 security → bots 下，可以观察到请求分类，了解哪些流量被识别为 Bot，哪些是正常的浏览器流量。这个能力对 Agent 开发者有两个层面的参考价值。

第一，当你维护自己的 Agent 服务时，要清楚平台侧如何识别你的请求。如果你的 Agent 是一个合理业务系统，应该在请求特征上做规范化，避免被误伤。第二，当你的 Agent 去访问别人的网站时，要主动适配对方可能的 Bot 防护策略。换言之，网络策略不只是沙箱平台的配置，更是一套完整的请求治理方案。能正确处理出站、入站、反爬识别这三个环节的平台选型，才是真正适合生产的 Agent 沙箱。

7. 完整示例：让 Agent 在沙箱里完成一次带外部网络访问的任务

7.1 示例目标与整体流程

下面这个示例模拟一个常见的 Agent 工具调用：用户让 Agent 去请求一个公开接口，并把返回结果打印出来。我们会用 E2B 执行沙箱代码，用 Modal 跑一个函数，再用 Cloudflare Worker 做一个入站回调入口。整体流程能覆盖“沙箱创建、代码执行、外部网络访问、结果接收”四个关键环节。

7.2 E2B：最小代码解释器沙箱

# 文件：e2b_agent_demo.py from e2b_code_interpreter import Sandbox sandbox = Sandbox() # 沙箱内部执行的代码：访问公开接口并提取前 200 个字符 code = """ import urllib.request with urllib.request.urlopen("https://httpbin.org/get", timeout=10) as resp: text = resp.read().decode("utf-8") print(text[:200]) """ execution = sandbox.run_code(code, timeout=30) print("stdout:") print(execution.text) if execution.error: print("执行出错：") print(execution.error) sandbox.close()

这段代码的关键是run_code会在沙箱内执行完整代码，并通过execution.text返回标准输出。如果代码运行时报错，execution.error会包含错误信息。注意sandbox.close()写在所有业务逻辑之后，确保沙箱资源被回收。若执行段较长，可以使用try...finally保证释放。

7.3 Modal：函数粒度的执行环境

Modal 的模型更接近“函数即沙箱”。你在函数里声明镜像、依赖和超时，调用时平台会准备运行环境。

# 文件：modal_agent_demo.py import modal app = modal.App("agent-sandbox-demo") image = modal.Image.debian_slim().pip_install("requests") @app.function(image=image, timeout=60) def fetch_agent_result(url: str) -> str: import requests resp = requests.get(url, timeout=10) return resp.text[:200] @app.local_entrypoint() def main(): result = fetch_agent_result.remote("https://httpbin.org/get") print(result)

运行命令：

pip install modal modal run modal_agent_demo.py

这个例子展示了 Modal 与 E2B 的差异：E2B 是“给一个沙箱，往里面塞代码”，Modal 是“定义一函数，让它在一个隔离环境里运行”。前者更像传统安全沙箱，后者更像 serverless 函数，但两者都能被 Agent 编排。

7.4 Cloudflare Worker：Agent 回调入口

当沙箱里的任务执行结束，可能需要把结果回调给业务系统。用 Cloudflare Worker 做入口，可以在入口处做认证和持久化。

// 文件：worker.js export default { async fetch(request, env) { if (request.method !== "POST") { return new Response("Method Not Allowed", { status: 405 }); } const token = request.headers.get("Authorization"); if (token !== env.AGENT_CALLBACK_TOKEN) { return new Response("Unauthorized", { status: 401 }); } const payload = await request.json(); // 将结果写入 KV 或 D1，便于后续查询 await env.AGENT_RESULTS.put(String(payload.id), JSON.stringify(payload)); return new Response("OK", { status: 200 }); } }

部署后在环境变量里配置AGENT_CALLBACK_TOKEN。Agent 回调时带上令牌，Worker 校验通过后才处理结果。这个模式比“沙箱直接对外暴露端口”更安全，也更便于运维监控：所有入口日志保留在 Worker 层。

7.5 Vercel v0：前端如何消费 Agent 结果

如果你的 Agent 产品有一个前端，最省力的方式是使用 Vercel 生态来搭建。v0 是 Vercel 推出的 AI 生成 UI 工具，你只需用自然语言描述界面需求，它就能生成 React 组件。比如：

用 React + Tailwind 做一个任务面板，包含三个步骤： 1. 显示沙箱状态 2. 展示最近执行记录 3. 调用 /api/agent-run 触发 Agent 任务

生成之后可以直接部署到 Vercel。前端的请求可以打到 Vercel Function，再由 Function 转发给 E2B 或 Modal。不要让浏览器直接携带沙箱平台 API Key，而是把所有密钥放在 Vercel Function 的环境变量里，前端只发出业务请求。

7.6 运行验证

先运行 E2B 示例，能打印 httpbin 返回的前 200 字符，说明沙箱创建、代码执行、出站网络三个环节都通了。再运行 Modal 示例，能打印同样的结果，说明函数级环境也通了。最后部署 Worker，用带正确令牌的 POST 请求测试，能返回 200，说明回调链路是通的。

如果某一步失败，优先检查网络权限：沙箱是否能访问公网？请求是否被目标地址拒绝？超时时间是否足够？再看代码错误：是不是依赖没有安装、API 写错、环境变量缺失。先分清是环境问题还是代码问题，再定位到具体平台配置。

8. 常见问题与排查思路

下面这张表覆盖了 Agent 沙箱接入初期最常见的 6 类问题。

遇到问题不要先怀疑平台，按“代码 → 权限 → 网络 → 配置”的顺序排查。很多“沙箱不可用”的问题，其实只是代码在沙箱里缺了一个包。

9. 最佳实践与工程建议

9.1 用模板管理依赖

不要把pip install留在每次沙箱运行里。把常用依赖固化成模板，让沙箱启动时直接复用。这不仅缩短冷启动时间，也减少了“代码在本地能跑、在沙箱里缺包”的偶然性问题。模板版本要纳入 CI/CD 管理，依赖升级时重新构建并回归测试。

9.2 强制超时与预算上限

所有 Agent 任务都应该有超时控制，且超时时间要小于平台计费周期的安全边界。业务层要设置“最大执行次数”和“最大重试次数”，防止一次模型跑偏导致几十次循环调用。平台层要设置预算告警，一旦当日消耗超过阈值就切断新任务创建。两层防线缺一不可。

9.3 密钥只走注入，不能写进日志

沙箱代码是不可信的，密钥绝不能写在代码里或作为参数传入后被打印。推荐通过平台的环境变量或 Secret 机制注入密钥。同时要在沙箱入口做日志脱敏：不打印完整的 Token、Key 和用户个人信息。很多数据泄露事故不是外部攻击，而是沙箱日志被误采集后泄漏。

9.4 最小权限网络

默认关闭出站网络，按任务需求开启白名单。只允许访问任务真正需要的 API 域名，不建议为“方便调试”而开放全网访问。如果平台支持固定出口 IP，优先使用固定 IP，方便在合作方那边做白名单。入站回调入口统一走 API 网关或边缘函数，做令牌校验和限流。

9.5 生产迁移应当灰度

从 demo 到生产，不要一次性把所有 Agent 任务切到新平台。先选一个低风险、低频的工具调用场景做灰度，观察冷启动、成功率和账单三项指标，再逐步放量。切换时保留旧平台的日志，方便对比。这比功能上线前做全量迁移稳妥得多。

9.6 把成本指标写进任务日志

每次 Agent 任务结束，都应该记录任务耗时、沙箱运行时长、请求次数、费用估算。有了这些数据，你才能知道哪个业务环节的成本最高，是模型调用贵还是沙箱运行贵。成本治理不是事后看账单，而是在任务日志里即时可见。

10. 总结与后续学习方向

Agent 沙箱选型没有“银弹”，但有清晰的分析路径。E2B 适合代码解释器型 Agent，Daytona 适合需要私有化和深度定制的团队，Modal 适合 GPU 与重型计算任务，Cloudflare 适合边缘和高并发场景，Vercel 适合前端编排和快速原型。关键是把冷启动、计费粒度、网络策略三个指标与自己的任务形态做匹配。

后续要深入的方向包括：沙箱镜像优化、快照与状态恢复、跨平台抽象层设计、Agent 任务的可观测性建设。建议你先写一个最小测试脚本，分别在同一份需求下跑通 E2B 和 Modal 两个平台，记录冷启动时间和账单估算。真实数据比任何技术博客都能帮助你做判断。

把冷启动时间写进 Agent 的 SLI，把沙箱预算告警放在模型性能调优之前，把网络策略当成安全评审的一等公民。这三项工作看起来很基础，却决定了你的 Agent 项目能走多远。