（二）专用沙盒环境

业界实践解读 · 对应 ETCLOVG E 层（执行与沙箱）。以下是对原文的解读，保留其核心概念、 关键指标与设计决策；完整叙述、架构图与代码请读原文：https://aws.amazon.com/cn/blogs/china/agentic-ai-sandbox-practice/

沙箱为什么是 Agent 的刚需

原文的出发点值得先立住：Agent 从”对话式 AI”变成了”行动式 AI”——它不只是回话，而是主动执行代码、操作程序、分析数据。 一旦 Agent 开始”动手”，它执行的代码是大模型现场生成的、不可预先审计、也不可预测。于是问题从”模型答得对不对”变成了”它动手时 会不会越界”。专用沙箱正是为了承接这类不可预测的自主行为：给它一个划定好边界、可以放手行动的空间。

原文把 Agent 的沙箱需求拆成两类场景，而这两类对沙箱的要求其实是相反的：

• 代码执行环境——典型是数据分析 Agent：分析师上传 1GB 销售数据，只说一句”分析去年趋势、找最佳品类、出可视化报表”， Agent 就自动生成读取/处理/分析代码并反复启动沙箱执行，整个流程可能”需要数小时的连续计算”。再往上是 AI Bot 生态平台， 开发者在沙箱里用 Claude Code / Amazon Q CLI 造 Agent、一键部署成 Web 服务，终端用户直接用——“AI 辅助开发→一键部署→即用 即取”的闭环。这类场景要的是无头、高吞吐的执行（命令行 + 高阶代码解析，运行时按需切 Python Runtime 或 VSCode Server）。
• 可视化操作环境（Computer Use / Browser Use）——Agent 像人一样点按键盘鼠标，去操作那些根本没有 API、只能靠视觉操作 的程序（竞品调研、软件测试、在线订票）。这类要的是完整桌面/浏览器环境 + 可视化回放，牺牲密度换保真。

理解这个分叉很重要：它解释了后面为什么会有 Code Interpreter（无头、按秒计费、高并发）和 Browser Tool（完整浏览器、VM 1:1） 两个不同产品——同一个”沙箱”抽象下藏着两种截然不同的负载。

四个技术诉求，本质是同一个三难

原文列了便捷接入、简化管理、完善生命周期、完备安全四个诉求。它们看似并列，但读进去会发现指向同一个张力——安全、速度、 成本三者难以同时最大化：

• 便捷接入 / 简化管理降的是”用起来的门槛”：简洁 SDK、一键启停，以及关键的模板化理念——“先创建模板、再用一个 template ID 启动运行时”。这个决策不只是方便，它是后面毫秒级启动与环境一致性的前提（模板可缓存、可复用）。
• 完善生命周期里最该记住的是 pause/resume：Agent 的多阶段推理、多分支探索会让会话状态高度不确定，能暂停释放资源、 再从快照恢复，才谈得上”断点续传”和高密度部署。这不是锦上添花，而是长程 Agent 经济性的核心。
• 完备安全回答的是”为什么不能就用普通容器”：Agent 执行的是外部生成的代码、还要访问第三方数据，所以需要硬件级隔离、 系统调用最小化、网络/文件系统精细权限，以及真正的故障边界隔离——一个沙箱崩了不能波及其他节点。

技术细节：每个机制在解决什么

安全的多层隔离——原文给了四层，但核心决策是用 Firecracker microVM 取代容器做硬件级隔离。为什么？因为 LLM 生成的 代码”syscall 模式无法预先刻画”，容器共享内核的弱边界压不住这种不可预测性；microVM 给每个沙箱独立内核，才真正隔开。 其余三层是配套：每沙箱独立 IP 网络槽（可从完全断网到受限访问）、基于只读模板的临时根文件系统（用完自动清理，防残留）、 资源上限 + 最大存活时间 + 每 30 秒健康检查（阻止长时间恶意代码）。贯穿其上的是最小权限原则。

快速启动为什么值得六种优化——因为冷启动延迟直接等于”用户等待时间 + 并发上限”，对交互式 Agent 是硬约束。六个机制分别 攻击启动路径上的一个瓶颈：模板内存缓存（消除磁盘 I/O）、预分配网络资源池（零配置延迟）、UFFD 按需内存页加载（内存页 被访问时才从模板加载，砍初始内存）、微虚拟机（毫秒级 VM 创建）、异步并发初始化（网络/内存/文件系统并行准备）、快照恢复 （从预创建状态直接恢复、跳过初始化，结合增量快照与脏页跟踪”比新建快数十倍”）。落到数字：本地缓存命中时启动 100–800ms。

状态转换的四个策略——理解主线是”把沙箱当可暂停可恢复的资源，而不是一直占着的进程”：PAUSED 态释放 CPU 与大部分内存 （支撑高密度）、基于快照的亚秒级扩缩容（比重建快 10–100×）、增量差异只存变更内存页（省存储）、原子性状态转换（零停机、 要么全成要么回滚）。关键指标是那个 10–100×——它是”预热 + 快照”相对”每次新建”的量级差，决定了大规模并发下的经济性。

虚拟化定性对比（原文的核心决策依据）——安全隔离：VM ★★★★★、容器 ★★☆☆☆、Firecracker ★★★★★；启动时间：VM 慢， 容器与 Firecracker 快（容器前提是镜像已在本地）；资源效率：容器最高、Firecracker 次之、VM 最低。这张表的结论是一句话： Firecracker 同时拿到了强隔离和快启动——传统上要在”VM 的安全”与”容器的速度”之间二选一，microVM 打破了这个取舍，所以 成了 agent 时代临时沙箱的默认。

亚马逊云上的三个方案（及各自的关键决策）

• E2B on AWS——把开源 E2B（Firecracker microVM）搬进企业自有 AWS 账户，核心卖点是数据主权与合规：数据完全自主、 支持中国区与 Graviton、支持暂停/恢复与增量快照，代价是自主运维。架构分 Server/API/Builder/Client 四类集群，其中 Client 集群须裸金属以保证 Firecracker 性能——这是个具体而重要的部署约束。
• Bedrock AgentCore Code Interpreter——托管 microVM，每会话独立、结束即销毁并清内存。关键规格即关键决策：内置 Python/JS/TS，内联上传 100MB、S3 5GB，会话超时默认 15 分钟、最长 8 小时，以及按 vCPU/内存实际秒数计费 （不含 I/O 等待）——这个计费模型意味着”只为真正的执行时间付费”，是相对”按实例运行时间计费”的成本决策。
• AgentCore Browser Tool——为可视化场景托管浏览器，最关键的安全决策是 VM 级隔离 + 用户会话↔浏览器会话 1:1；模型 无关，提供 interact()/parse()/discover() 自然语言接口、兼容 Playwright/Puppeteer，靠截图理解页面、支持会话回放，并集成 CloudTrail 审计、临时会话用后重置。

选型：这才是要带走的决策

原文对比 Lambda / 普通容器 / AgentCore / E2B 后，归结为一条清晰的决策规则：

• 选容器——当且仅当：只跑大模型生成的简单代码、能接受极少发生的内核 crash 与跨容器攻击风险、且对成本极敏感。
• 选 microVM（AgentCore 或 E2B）——当：不能接受容器的”邻居效应”与系统级影响、对隔离有严格要求、需要复杂可视化操作、 或是企业级高稳定/高安全场景。其中炫酷的 Computer Use 选 E2B（Desktop SDK 丰富），浏览器操作选 AgentCore Browser Tool。

一句话记住这篇：Agent 沙箱的本质是”既是牢笼也是许可证”——牢笼保证安全，许可证让 Agent 敢放手长程执行；而 Firecracker microVM 之所以成为默认，是因为它第一次让”强隔离”和”快启动”不再互斥。

本页是对原文的解读，保留其核心概念/指标/决策；架构图、代码与完整叙述请以 AWS 原文 为准。