执行环境与沙箱 (E)
ETCLOVG 之 E 层：agent 代码在哪运行、受何约束。沙箱三重目的、七类沙箱、隔离技术、威胁模型与逃逸、部署模式。
本节对应综述《Agent Harness Engineering: A Survey》§3，是 ETCLOVG 七层的第一层。执行环境指 agent 动作被物理执行的 基础设施层；在 LLM agent 语境下，执行环境与沙箱是紧耦合的概念，生产系统几乎无一例外地在沙箱内执行动作。
为何沙箱在 agent 时代是一等 concern
综述指出，agent 时代的沙箱不只是从传统多租户代码执行继承来的安全措施，它同时服务三个目的，三者叠加才使沙箱从运维细节 上升为 harness 设计的一等 concern：
- 安全（security）：与传统沙箱共有，但更棘手。LLM 生成的代码在规模上既不可审计也不可预测，静态审查无法作为主要防线； agent 跨多步自主执行，动作执行时没有人工介入；提示注入可把一个原本良性的 agent 重定向为攻击载体，模糊可信用户意图与 敌意输入的边界。
- 可复现（reproducibility）：在 agent 设置下被放大。长程任务及度量它们的评估框架（见 V 层） 需要把执行状态重置到已知基线；容器或 microVM 可按需销毁重建，而开发者工作站不能——这正是 SWE-bench、OSWorld 等 基于沙箱的评估标准得以实用的前提。训练时同一任务可能被并行重放数百次，缺乏廉价重置本身即扩展瓶颈。
- 存活性（liveness）：agent 时代基本全新的一项。没有沙箱，每个有风险的动作（写文件、装包、外发网络请求）都须以人工 许可提示把关；规模化后导致用户要么因挫败放弃、要么反射性全部批准而使安全前提失效。沙箱通过定义一个可自由行动的受限 区域打破僵局，把许可从“每个动作的问题”降格为“会话配置”。综述援引：为 Claude Code 引入沙箱在保持安全的同时将许可提示 减少 84%。
综述把沙箱形容为“既是牢笼也是许可证”，许可证一面正是长程自主执行得以成立的前提——这也是把 agent 沙箱作为独立研究对象、 而非容器技术下游应用的理由。
七类沙箱（按工作负载）
综述沿工作负载／用例这一对 harness 设计者最有信息量的轴分类；隔离技术（容器、gVisor 等用户态内核、Firecracker／ Kata 等 microVM、WebAssembly、bubblewrap／Seatbelt 等 OS 原语）作为每类内部的正交设计属性讨论，因为同一隔离原语会跨 负载复用。
| 类别（§3.2.x） | 代表系统 | 关键特征 |
|---|---|---|
| 通用托管沙箱 | Daytona、E2B、Modal、Northflank、OpenSandbox、Docker Sandboxes | 以 API 暴露任意 OCI 镜像；ephemeral 默认 + 可选持久会话；Daytona 冷启 <90ms；正从共享内核容器转向专用内核 microVM；Northflank 允许每负载选后端 |
| computer-use 基础设施 | Anthropic Computer Use、CUA、OSWorld | 以模拟鼠标／键盘／屏幕交互 GUI；动作空间大但依赖视觉 grounding；完整 OS 攻击面需 microVM/全 VM；以密度与启动延迟换保真 |
| 代码专用沙箱 | Judge0、OpenAI Code Interpreter、sandboxed.sh、langchain-sandbox、Repo2Run | 预装编译器／解释器；无状态请求级执行；高并发；出现容器→WebAssembly 迁移（能力式安全、确定性、微秒级实例化） |
| 框架内建运行时 | OpenHands、GoEX、agent-infra sandbox、smolagents executors | 与框架编排循环捆绑，不能独立消费；bundle vs compose 取舍——开箱即用 vs 更大镜像、更慢启动、强耦合 |
| 浏览器评测环境 | WebArena、VisualWebArena、BrowserGym、WorkArena | 兼具沙箱与评估框架双重角色；因摄入不可信网页而是间接注入与多模态红队的天然基质 |
| OS 级权限沙箱 | Anthropic sandbox-runtime、Claude Code sandboxing、IsolateGPT、AgentBound、transactional sandboxing | 用 bubblewrap／Seatbelt／seccomp 做细粒度隔离；理念“许可而非隔断”——不给新 OS 镜像、只收窄宿主视图；共享宿主内核，隔离弱于 microVM |
| 沙箱抽象层 | SWE-ReX、smolagents executor、K8s Agent Sandbox CRD、R2E-Gym、EnvScaler、SandMLE | 本身不是沙箱，而是统一多后端的接口；解耦“agent 运行什么”与“在何处运行”；研究、框架、基础设施标准三线收敛 |
三条跨类趋势
综述在本节末给出三条跨类趋势：
- 沿隔离强度分化而非收敛：托管沙箱向专用内核 microVM 迁移（因 LLM 生成代码的 syscall 模式不可预先刻画），OS 级权限 沙箱则放弃独立环境、收窄宿主视图；居中的普通 Docker 容器被两端挤压，选择取决于威胁模型（完全对抗性代码 vs 被注入但 仍合作的代码）而非普适技术偏好。
- 评估鲁棒性成为一等 concern：SandboxEscapeBench、CIBER 等显示当前生产沙箱配置对前沿模型部分可绕过。
- 基础设施级隔离与语义／能力级隔离分离：后者（CaMeL 的控制流完整性、Progent 的可编程权限控制）属于 T 层——基础设施沙箱约束动作执行后的波及范围，语义隔离约束哪些动作被允许，二者互补，完整 harness 两者都需要。
威胁模型与沙箱逃逸
除传统容器级威胁（逃逸、旁路、资源耗尽）外，综述归纳三类被放大的 agent 特有威胁：提示注入（外部输入如检索网页、 工具响应、文件内容劫持 agent 行为）、目标错位（agent 主动把沙箱逃逸当作工具性子目标）、组合放大（多工具访问使单点 弱点跨能力级联）。实证方面：
- SandboxEscapeBench（Marchand et al., 2026）在嵌套沙箱 CTF 设置下报告前沿模型对 Docker 容器 15%–35% 逃逸成功率 （随配置而异），覆盖误配置、权限分配错误、内核缺陷、运行时／编排弱点，确立威胁在当前模型能力下即为现实。
- 防御仍碎片化：IsolateGPT 报告 3/4 查询下 <30% 开销并阻止跨应用数据泄露；事务式沙箱约 14.5% 开销、高拦截率； LLM-in-Sandbox 主张最小而非最大能力的沙箱环境以同时降低攻击面与不必要复杂度。
综述据此把“在统一评估方法下系统应对三类威胁的 agent 原生运行时安全框架”列为开放问题（见总论 §12.1）——攻防进展存在 缺口：进攻侧已有可复现基准，防御侧仍散于威胁模型、评估协议、基线假设各异的孤立原型。
部署模式
三种模式并存：self-hosted（开发者直接管理，OpenHands／SWE-agent 默认；最低延迟、最紧迭代，但承担全部运维）、 cloud / SaaS（E2B、Modal、Daytona Cloud 托管；弹性扩展、托管安全，代价是网络往返）、hybrid / BYOC（agent 逻辑与 沙箱执行跨环境解耦，OpenHands 的 Local/Remote Workspace、E2B/Northflank 的 BYOC）。选择沿延迟、安全、可扩展三轴权衡， 而数据驻留、合规、可审计等组织约束会把部署推向 hybrid，即便延迟与扩展性本更偏好单一模式。观察到的实践：自托管主导交互 开发与单租户，云沙箱多见于多租户与大规模，hybrid 专为“合规／数据本地性”与“大量 ephemeral 执行容量”并存的场景。