设计能充分释放智能体潜力的沙盒

# 设计能充分释放智能体潜力的沙盒

你好，我是村本典一（Norikazu Muramoto）。（https://x.com/1amageek）

2026年8月，Anthropic将自动模式设为Claude Code专业版、Max版和团队版的默认设置。公告描述了一项实验：通过一家研究机构招募了1,053名付费测试者。在测试环境中，参与者被依次展示一系列权限提示，其中一条提示被替换为明显危险的命令。在1,053名测试者中，仅有143人（即13.6%）注意到了这条危险命令。而自动模式在89%的情况下拦截了相同的命令：1,053次中共拦截937次。

逐一审批几乎已无法作为安全机制发挥作用。2026年5月，Anthropic说明了其在各产品中约束Claude的方式：

> 我们不是监督智能体的行为，而是通过强制执行访问边界来监督它能做什么——例如借助沙盒、虚拟机和出口控制。

如果安全责任从人工审批转移到环境本身，那么设计该环境也就决定了智能体能够完成什么。

本文聚焦于智能体的沙盒环境。沙盒通常被视为一种安全机制，但对智能体而言，它是工作发生的计算机。哪些命令可用？能否访问网络？能否安装软件包？能否在第二天继续工作？这些环境选择决定了我们能从同一模型中挖掘出多少能力。限制危险命令固然重要，但删除无害命令会削弱智能体，而仅凭命令名称来判断危险性的系统在安全方面同样会持续失效。

本文信息截至2026年9月。

## 一、能力并非仅由模型决定

智能体的运行不仅仅依赖模型本身。智能体循环驱动模型的输出；工具链为该循环提供工具和上下文；环境接收工具的执行；其外则是外部世界。

模型——决定下一步行动 ↓ 智能体循环——推理 → 行动 → 读取结果 ↓ 工具链——工具、上下文、审批 ↓ 环境/沙盒——命令实际运行的地方 ↓ 外部世界——Git、软件包、API、生产系统

即便使用相同的模型，改变这些层次也会改变结果。针对终端任务的基准测试Terminal-Bench 2.0报告了同一款Claude Opus 4.5在不同工具链下的不同得分：

Terminus 2——模型：Claude Opus 4.5；Terminal-Bench 2.0：57.8%。

Claude Code——模型：Claude Opus 4.5；Terminal-Bench 2.0：52.1%。

OpenHands——模型：Claude Opus 4.5；Terminal-Bench 2.0：51.9%。

不过，该论文同时指出，在提升性能方面，模型的选择通常比工具链的选择更为重要。

那么环境呢？2026年1月，中国人民大学和微软研究院的研究人员比较了同一批模型在直接作答与在沙盒内作答时的表现差异。沙盒是一个配有bash、文件编辑工具、互联网访问权限以及执行期间安装软件包能力的Docker容器。借助bash，模型可以安装软件包、运行程序，并即时构建所需工具。

结果因模型不同而呈现出截然相反的走向。

GPT-5 ——任务：数学；单独使用模型：87.8；配合沙盒：97.9。

Claude Sonnet 4.5（思考版）——任务：指令遵循；单独使用模型：59.3；配合沙盒：72.0。

GPT-5 ——任务：生物医学；单独使用模型：55.8；配合沙盒：49.0。

Qwen3-4B — 任务：数学；模型单独运行：46.0；配合沙盒：32.5。

更强的模型能够直接从环境中获益，而较弱的模型在沙盒内的表现反而更差。即便是强模型，在生物医学等任务上也会有所退步——因为环境在这类任务中的用处有限。只有当模型和任务都能充分利用环境时，环境才能真正发挥作用。

有效能力 = f(模型, 执行框架, 环境)

这是我的诠释，而非一个经过测量的函数。这个表达式旨在说明：能力源于三者的交互。随着模型不断增强，它们能从环境中汲取更多，因此受限环境所带来的代价也随之增大。

在选定模型之后，再着手设计环境。针对你将使用的特定模型和任务，衡量扩展环境所带来的效果。

## 2. 沙盒是智能体的计算机

2025年9月，Anthropic 将 Claude Code 背后的机制作为 Claude Agent SDK 对外发布，并阐明了其核心设计原则：

> Claude Agent SDK 背后的关键设计原则，是为你的智能体提供一台计算机，让它们像人类一样工作。

OpenAI 的 ChatGPT 智能体同样运行在自己的虚拟计算机上，在推理与行动之间灵活切换。Manus 将文件系统用作上下文存储——容量无限、持久保存，且可供智能体直接访问。那些无法放入上下文窗口的研究发现和中间成果，可以写入文件，之后再行读取。文件系统既是工作场所，也是智能体记忆的延伸。

剥夺一名人类工程师的 Shell、网络访问权限和包安装能力，他所能完成的工作将大打折扣。对智能体而言，同样如此。以下是计算机各组成部分的作用，以及缺失时所带来的损失。

操作系统 — 对智能体的作用：运行命令和程序的基础；缺失时的损失：执行能力本身。

文件系统 — 对智能体的作用：存储代码、产出物和笔记；缺失时的损失：中间进度以及超出上下文窗口的记忆。

Shell — 对智能体的作用：组合本地程序的通用执行机制；缺失时的损失：处理意外任务的能力。

运行时 / 包 — 对智能体的作用：语言运行时、构建工具和测试工具；缺失时的损失：通过构建和测试进行验证的能力。

网络 — 对智能体的作用：获取依赖项、阅读文档、调用 API；缺失时的损失：解决工作中途发现的依赖问题的能力。

进程 — 对智能体的作用：在检查行为时保持数据库或服务器持续运行；缺失时的损失：验证各组件协同工作的能力。

凭证 — 对智能体的作用：操作外部服务的授权；缺失时的损失：对外部服务进行变更的能力。

持久状态 — 对智能体的作用：第二天可以继续工作；缺失时的损失：已积累的配置和进度。

在构建 Docker 沙盒的过程中，我亲身经历过这一点。我忘记在镜像中加入 `python` 等命令，导致智能体无法运行 Python，在验证环节举步维艰。我并非因为它存在危险而将其移除，只是单纯地遗忘了。就是这样一处疏漏，便剥夺了智能体的验证手段——正如"运行时"一行所描述的那样。

设计沙盒，就是在设计智能体的能力边界。在决定禁止什么之前，先决定要提供上述哪些组件。

## 3. 当我们移除命令时，智能体会失去什么？

首先说明证据的局限性：在我审阅的研究中，没有找到逐一移除可用命令并衡量成功率下降情况的实验，也没有找到仅改变网络访问或软件包安装条件的对比研究。现有的是在相关条件下进行的消融实验。

2024年SWE-agent论文将专为智能体设计的命令集——智能体-计算机接口（ACI）——与仅使用shell的配置进行了比较，两者均采用相同的 GPT-4 Turbo。在SWE-bench Lite上，使用ACI的解决率为18.0%，仅使用shell为11.0%：相较于仅用shell的方案，相对提升达64%。论文还逐一移除ACI各组件进行测试：移除编辑命令后，分数降至10.3%；移除搜索工具后，分数降至15.7%。没有编辑命令时，模型只能通过重定向或sed修改文件。论文得出结论：繁琐的接口会损害模型性能。

到2026年，随着前沿模型的出现，情况已有所改变。极简的仅用bash的mini-SWE-agent配合Claude Opus 4.5，在SWE-bench Verified上解决了76.8%的问题。SWE-bench官方网站列出的最先进结果，均来自只给智能体提供bash shell和问题本身的方案。

2026年7月，罗切斯特理工学院的研究人员比较了Claude Code（使用Claude Sonnet 4.6）与Codex CLI（使用 GPT-5.5 ）在三种工具配置下的表现：

- 默认工具。

- 仅bash，禁用文件编辑工具。

- 单一的Python和Bash执行工具。

在四种模式与三种配置的所有组合中，成功率差异均不超过三个百分点。差异体现在成本上。对于工件创建任务，使用Claude Code配合单一执行工具，经缓存调整后的成本降低了24.6%。

Verdent 2025年11月的技术报告也描述了对Claude Sonnet 4.5进行的工具消融实验。将智能体限制为仅使用基本的bash、读取、写入和编辑工具，其SWE-bench Verified性能几乎没有变化。

还有一个生产环境的案例。2025年12月，Vercel将其内部智能体d0（用于将自然语言问题转换为SQL以服务其分析平台）中的17个专用工具，替换为一个在沙箱中运行bash的工具和一个执行SQL的工具。在使用Claude Opus 4.5测试的五个问题中，成功率从五题中答对四题提升至全部答对，耗时则从274.8秒缩短至77.4秒。这是一次小规模内部测试，且依赖于该分析平台已有良好文档记录的语义层。环境中的文件承担了原本嵌入专用工具中的知识功能。

以下是按移除内容整理的实验汇总：

执行反馈——保留：单次作答；结果： GPT-4 SQL：73.7% → 9.1%；来源：InterCode。

计算机环境——保留：仅模型本身；结果： GPT-5 数学：97.9 → 87.8；来源：LLM-in-Sandbox。

编辑命令——保留：shell及剩余ACI；结果： GPT-4 Turbo：18.0% → 10.3%；来源：SWE-agent。

文件编辑工具——保留：bash或单一执行工具；结果：差异不超过3个百分点；来源：Yang, Yu, Desell。

高级工具——保留：bash、读取、写入、编辑；结果：几乎不变；来源：Verdent。

17个专用工具——保留：bash和SQL执行；结果：5题中答对4题 → 全部答对；来源：Vercel。

最大的损失来自于移除执行手段和检查结果的能力。只要shell作为通用执行机制得以保留，减少专用工具几乎不会影响前沿模型的性能。

我的解读是，2024年和2026年的结果并不相互矛盾。在 GPT-4 Turbo 时代，易于使用的命令弥补了模型自身的局限。而今天的模型，只要拥有bash，就能重建专用工具的功能。纵观两个时代，失去编辑、执行和反馈能力都会导致性能大幅下降。重要的不是工具的数量，而是通用执行机制所能触达的范围。

如果要精简工具，从专用工具入手。保留shell、文件编辑以及访问执行结果的能力。

限制工具所带来的安全成本也已得到量化。AgentDojo是一个用于评估提示注入攻击的测试环境，其中测试了一种工具过滤器，该过滤器会预先筛选出某项任务所需的工具。使用 GPT-4o 后，无攻击情况下的实用性从69.0%提升至73.13%，而攻击成功率则从57.69%降至6.84%。单独来看，这表明更严格的限制效果更好。论文同时也指出了这一防御机制失效的情形：

> 然而，当无法提前规划所需工具列表时（例如，因为某次工具调用的结果会告知智能体下一步需要执行哪些任务），或者当解决任务所需的工具同样足以实施攻击时（在我们17%的测试案例中确实如此），该防御机制就会失效。

来自UC伯克利和UC圣塔芭芭拉研究人员的Progent对第一个局限性进行了量化。在使用 GPT-4o 对AgentDojo进行的重新测量中，无防御时的实用性为79.38%，使用静态工具过滤时为65.98%。而Progent能够在执行过程中按需扩展权限，实现了76.29%的实用性。在Slack任务上，启用权限动态更新后，无攻击情况下的实用性从61.9%提升至90.5%。部分必要的工具调用无法仅从用户的初始请求中推断出来。

静态限制的代价取决于能否预测未来的需求。智能体自主工作的时间越长，就越会在执行过程中才发现下一步的需求。对于可以从初始请求中确定所需工具的任务，使用预先筛选的工具过滤；对于长期运行的智能体，则使用能够在执行过程中扩展权限的机制，或使用第6节中讨论的基于边界的设计。

我们能否简单地禁止危险命令？在沙箱化之前，Claude Code会自动允许被认为安全的命令（如echo和cat），并要求对大多数其他操作进行审批确认。但命令的名称并不能反映其风险的大小。

第一行看起来危险，但它只是删除工作目录中可以重新生成的构建产物。第二行看似无害，但取决于scripts/analyze.py的内容，它可能会读取主目录中的密钥并将其发送至外部。

危险性取决于命令所能触达的范围，而非命令本身的名称。

GTFOBins记录了通过看似无害的命令启动shell的各种方式。这些命令均可以普通非特权用户身份运行。

npm install同样会执行包的生命周期脚本，例如preinstall和postinstall。一个原本只是用于安装依赖的命令，实际上可以运行任意代码。

Anthropic在其2026年3月关于自动模式的说明中承认了这一问题。进入自动模式时，它会移除已知会允许任意代码执行的权限规则：

- 全面的 shell 权限。

- 针对 python、node、ruby 等解释器的通配符权限。

- 包管理器运行命令的权限。

该系统同时承认，这份排除列表并不完整，且来源于观察到的实际使用情况。

此类规则在用户中广泛存在。截至 2026 年 6 月，49.5% 的活跃 CLI 用户创建了自定义 Bash 权限规则。其中 5% 的用户允许所有 shell 命令，另有 43% 的用户设置了诸如 Bash(python:*) 或 Bash(node:*) 之类的解释器规则——这些规则在效果上与前者并无二致。

我的解读是：许多试图减少审批次数的用户以为自己是按名称授权了某个命令，实际上却开放了整个 shell。用户自己反而瓦解了基于名称的限制体系。

命令列表防御机制在实践中已被多次绕过：

Cursor——披露时间：2025 年 7 月，Backslash Security；绕过方式：四种绕过自动运行拒绝列表的方法；该拒绝列表已在 1.3 版本中被移除。

Cursor——披露：CVE-2025-54131；绕过方式：通过反引号或 $(cmd) 将另一条命令嵌入已允许的命令中。

Claude Code——披露：CVE-2025-54795 和 CVE-2026-24887；绕过方式：echo 和 find 命令的解析错误使任意命令得以在未经审批的情况下执行。

Claude Code——披露：CVE-2025-64755；绕过方式：被视为只读操作的 sed 可以写入任意文件。

Gemini CLI——披露时间：2025 年 7 月，Tracebit；绕过方式：一条伪装成合法 grep 命令的指令窃取了环境变量。

GitHub Copilot——披露：CVE-2025-53773；绕过方式：智能体修改了 .vscode/settings.json 以禁用审批机制。

Backslash Security 将这一局限性表述为一条定理：

> 定理：对于 Cursor 拒绝列表中的每一条命令，都存在无限多条不在该列表中的命令，它们在执行时具有完全相同的行为。

Anthropic 对自动模式的选择，同样是评估操作的实际效果，而非其调用字符串。

命令列表在两个层面上都难以为继。在安全性方面，它们无法阻止同一行为的变体写法；在能力方面，它们会仅仅因为某个命令名称与危险命令相似，就将无害的工作一并拦截。与其依赖命令白名单或黑名单作为安全机制，不如通过环境来限制智能体所能触达的范围。

## 4. 审批机制对长时运行的智能体失效

对于命令列表无法分类的操作，传统上会交由人工审批。Claude Code 此前会在每个操作轮次向用户请求权限，以防止意外行为的发生。

智能体提出命令 → 审批提示 → 批准：执行 / 拒绝：停止并重试 → 下一条命令。

随着提示不断积累，审批疲劳开始反噬这一流程：用户不加阅读地点击确认。

2026 年 3 月和 5 月，Anthropic 报告称用户批准了约 93% 的权限提示。其 8 月的公告将这一数字更新为 97%，并指出人工审查可能会演变为一种习惯性动作。5 月的文章解释道：随着人们看到越来越多的审批请求，他们对每一条请求的关注程度不断下降，监督质量也随时间推移持续退化。

在文章开头描述的实验中，随着会话时长增加，人类表现有所下滑。参与者在会话初期能识别出约17%的危险命令，但在看过50个以上提示词后，识别率仅剩约5%。无论会话长度如何，自动模式的拦截率保持不变。该五月份文章还指出，不应期望非工程师人员阅读并判断bash命令。

代理工作越久，负担越重。持续的代理工作时长已以小时为单位讨论：

METR，Claude Opus 4.6——数据：约12小时；衡量内容：以50%的概率完成人类专家约需12小时才能完成的任务；非代理实际运行时长。

GPT-5-Codex ——数据：超过7小时；衡量内容：在测试期间持续独立处理大型复杂任务。

Claude Sonnet 4.5——数据：超过30小时；衡量内容：在复杂多步骤任务中保持专注。

我的理解是，在如此长度的工作过程中每隔几分钟请求审批，等于把人类变成了速度瓶颈。而且正如开头实验所示，随着会话推进，人类会漏掉越来越多的危险命令。审批机制既无法可靠保障安全，又阻碍了自主性。

分类器（如自动模式）可缓解这一问题。但Anthropic报告指出，Claude Code自动模式在执行前能拦截约83%的越权操作，同时放行约17%。该分类器被定位为沙箱内部的一道防线，而非沙箱的替代品。

对于跨越边界的操作，应使用审批机制。边界内部的操作应无需审批即可进行；如果使用分类器，它仍是沙箱内部的一个防御层。

## 5. 什么是完全自主代理？

让我来定义本文旨在支持的代理类型。

本文所称"完全自主代理"，是指能够在较长时间内自主朝着给定目标工作，无需人类逐步操作或逐步审批的代理。

这并非赋予它为所欲为的权限。人类不再审批单个操作，而是定义目标与边界。代理在这些边界内不间断地工作，跨越边界的操作则另行处理。

2025年10月，Meta提出了"代理二选一规则"，作为划定边界的决策框架。其核心思想是：在单次会话中，以下三个属性最多允许同时具备两个：

A——含义：处理不可信输入。

B——含义：访问敏感系统或私有数据。

C——含义：改变状态或对外通信。

Meta的立场是：如果三者均不可或缺，且代理无法在新会话中以全新上下文窗口重启，则不得自主运行。至少需要通过可靠的验证手段进行监督，例如人工审批。

编码代理无法回避A和C。网页、问题单、依赖项README均属不可信输入；修改文件和运行测试则会改变状态。

我的理解是，实现持续自主运行需要通过环境设计来移除B。如果代理工作的环境无法访问敏感数据或生产系统，那么它在保留A和C的同时仍可自主运行。

Simon Willison对Meta图表中将A加C视为安全的做法提出了质疑。Meta研究员Mick Ayzenberg在Hacker News的一条回复中，将运行于强沙箱或与生产环境隔离的代理作为这种状态的示例。

一个完全自主的 Agent 在强边界内运行。要让其长时间自主工作，首先需要提供一个无法访问敏感数据或生产系统的环境。

## 6. 通过隔离赋予自由

扩展 Agent 自由度的方式，是用边界固定其可达范围，并允许它在边界内自由行动。

弱隔离：共享宿主机权限 → 审查每条命令 → 限制自由。

强隔离：强制执行可达边界 → 边界内无需审查 → 扩展自由。

沙箱强度与 Agent 自由度无需相互冲突。强隔离正是实现充分自由的前提。

这是一种设计解释。目前没有研究直接测量从隔离到自由再到自主性与结果的完整因果链。以下证据支持这一设计方向。

2025 年 10 月，Anthropic 报告称在 Claude Code 中引入沙箱后，内部使用的权限提示减少了 84%。这衡量的是提示次数，而非任务成功率。同一篇文章指出，定义一个 Claude 可以自由行动的边界，能够同时提升安全性与自主性。OpenAI 的 Codex 文档同样描述了对强制执行的边界的信任，而不仅仅是对 Agent 意图的信任。Anthropic 2026 年 5 月的文章更进一步：强边界允许更少的监督，Claude Code 的参考 devcontainer 就是为无人值守操作而设计的，无需对每个动作逐一审批。

边界需要同时包含文件系统隔离和网络隔离。没有网络隔离，被入侵的 Agent 可以将 SSH 密钥等敏感文件外传。没有文件系统隔离，它可以突破沙箱并获得网络访问权限。

在某些情况下，模型的判断力是不够的。2026 年 2 月，Anthropic 研究人员在一次内部红队演练中，通过网络钓鱼诱使员工以恶意提示启动 Claude Code。该提示看起来像一个普通工作流，但在执行过程中要求 Agent 读取 ~/.aws/credentials，对其编码并通过 POST 请求外传。在使用相同提示的 25 次尝试中，Claude 有 24 次完成了数据泄露。

> 在这种情况下，唯一有效的防御是环境本身——具体而言，是阻止 POST 请求的出口控制，以及将 ~/.aws 置于可达范围之外的文件系统边界。

凭据是首先需要保留在边界之外的东西。各产品以不同方式对其进行隔离：

- Claude Code 云端执行：Git 凭据和签名密钥保留在沙箱之外。

- Codex 云端环境：密钥仅在安装脚本中可用，Agent 开始工作前即被移除。

- Claude Cowork 初始版本：在 macOS 上，它运行在使用 Apple Virtualization 框架的虚拟机中；凭据保留在宿主机的密钥链中，不会进入虚拟机。

网络白名单有一个容易被忽视的特性。Claude Cowork 允许访问 api.anthropic.com，因为产品本身需要它。工作区中的一个恶意文件包含攻击者的 API 密钥和隐藏指令。Claude 遵循了这些指令，并通过 Files API 将工作区文件上传至攻击者的账户。

> 沙箱完美运作，数据却依然被泄露了。

Anthropic得出结论，允许列表更应被理解为能力授权：通过已允许域可访问的每一个函数都成为攻击面的一部分。Claude Code的CVE-2026-54316具有相同的结构。由于WebFetch预先批准了huggingface.co，对攻击者模型仓库的访问未经审批便通过了。一条被记录为下载的请求变成了数据泄露的通道。选择允许的域时，应审查它们所暴露的全部能力，而不仅仅是目标名称。

隔离机制在强度上也各有不同。

操作系统沙箱——内核关系：与宿主机共享；示例：macOS上的Seatbelt、Linux上的bubblewrap。

容器——内核关系：与宿主机共享；示例：Docker。

用户态内核——内核关系：不直接访问宿主机内核；示例：gVisor。

microVM——内核关系：每个客户机拥有独立内核；示例：Firecracker、Kata Containers。

容器共享宿主机内核，因此容器内的系统调用会到达同一个内核，内核漏洞可能导致逃逸。在由英国AI安全研究院与牛津大学合作完成的SandboxEscapeBench研究中，GPT-5 与Claude Opus 4.5在难度三级的容器逃逸场景中达到了40%的成功率。该论文认为单纯的Docker隔离在默认情况下是不够的，并推荐使用更强的隔离机制。

在gVisor中，一个运行于用户态的Go应用内核接收系统调用；没有任何调用被直接透传给宿主机。Firecracker论文描述了一种传统的权衡关系——高安全性、高开销的虚拟化与低安全性、低开销的容器之间的取舍。Firecracker为AWS Lambda和Fargate提供支持，其设计初衷正是为了避免这一两难困境：它以一个轻量级虚拟机监视器取代QEMU，同时保留KVM。每个microVM占用不到5 MB内存，启动时间不超过125毫秒，在单台宿主机上每秒最多可创建150个microVM。上述数据基于最小化的客户机内核。

根据Anthropic五月份的文章，其产品中使用的hypervisor、seccomp以及gVisor均按预期运行；出问题的是其自定义的允许列表代理。应选择避免共享内核的隔离方案，并使用经过验证的成熟隔离机制，而非自定义组件。

边界本身也可能存在漏洞。在Codex CLI的CVE-2025-59532中，模型生成的工作目录被视为可写的沙箱范围。模型的输出不得用于定义边界。Claude Code的CVE-2026-55607利用符号链接和git fsmonitor，在git worktree操作期间改写了home目录下的.zshenv文件，并在macOS沙箱之外执行了代码。沙箱本身也是软件：它同样需要更新和验证。

这一切是有代价的。auto模式文章承认沙箱是安全的，但在运营上要求较高。新功能需要进行配置，而需要网络或宿主机访问的工作也给隔离带来挑战。尽管如此，回顾网络钓鱼和允许列表事件，五月份的文章指出，在模型层面没有任何异常可供检测。文章得出结论：

> 当所有概率性手段都失效时，确定性边界便是最后的防线。

## 7. 沙箱的要求

下表是我对前述讨论的综合归纳。对于每个要素，它将环境内部的自由度与边界处的保证分开阐述。

文件系统——内部自由：读取、写入和删除工作区文件；边界保障：不访问主目录、密钥或配置文件。

进程——内部自由：启动服务器和数据库；长时间运行；边界保障：不干扰宿主进程。

运行时——内部自由：自由使用语言运行时和构建工具；边界保障：无共享内核，或不直接访问内核。

包管理——内部自由：安装工作过程中发现的依赖；边界保障：限制来源并保留记录。

网络——内部自由：查阅文档并获取依赖；边界保障：限制目标地址和操作；记录所有流量。

浏览器——内部自由：操作和验证 Web 应用程序；边界保障：不导入真实账户会话。

身份——内部自由：以代理专属权限运行；边界保障：不复用他人账户。

凭证——内部自由：通过代理执行必要的外部操作；边界保障：将机密本身保留在外部。

资源——内部自由：使用 CPU、内存和磁盘；边界保障：设置限制，防止失控的工作影响外部。

持久化——内部自由：将环境和工作延续到次日；边界保障：与生产数据保持隔离。

恢复——内部自由：允许破坏后重试；边界保障：对整个环境进行快照并支持回滚。

可观测性——内部自由：自由试验；边界保障：保留命令、流量和变更的审计日志。

策略——内部自由：不审查内部操作；边界保障：仅评估跨越边界的操作。

审批是上表中策略的组成部分之一。无需对每项操作逐一申请审批，而是针对跨越边界的行为（例如生产部署或向未批准目标传输数据）进行评估。审批次数减少后，人员可以将注意力集中在每个决策上。

## 8. 让代理自行构建其运行环境

准备沙箱的一种方式是预先安装所有所需内容。但需求往往只有在任务执行过程中才会明朗，因此环境配置本身也是代理工作的一部分。

现有的大多数基准测试在依赖已预先安装的环境中评估代理。微软的 SetupBench 则截然相反：代理从一个空白 Linux 沙箱出发，需自行安装软件包、解决依赖冲突、初始化数据库并配置后台服务。在 93 项任务中，Claude 4 Sonnet 的成功率为 62.4%，GPT-4o 的成功率为 34.4%。约 17–26% 的代码库配置失败源于未安装测试工具。在 EnvBench 中，即便是最优方法，也仅成功配置了 6.69% 的 Python 代码库和 29.47% 的 JVM 代码库。

Terminal-Bench 2.0 允许通过互联网访问来安装软件包和进行网络调研。然而最常见的失败原因是调用了缺失或不在 PATH 中的可执行文件，占失败总数的 24.1%。这并非一项限制性实验。即便拥有网络访问权限，发现并安装缺失命令也会成为解决原始问题之前的一项中间任务。修复环境，是解决任务路径上不可绕过的一环。

执行配置的主体不同，也会改变其成本。在SWE-Gym中，人工为11个代码仓库准备依赖项约耗费200小时。在SWE-smith中，智能体为128个代码仓库准备了环境，人工审查约需18小时。这两者采用的是不同的配置流程，并非受控对比实验。尽管如此，将环境配置委托给智能体提供了一条可扩展的路径。

2025年9月，OpenAI宣布Codex能够定位并执行常见的配置脚本，从而自行准备运行环境。在配置了互联网访问的情况下，它可以通过pip install等命令获取新发现的依赖项。Codex云端环境将执行过程划分为两个阶段。在配置阶段，环境可以访问网络、安装依赖项并使用密钥。在智能体阶段，密钥将被移除，互联网访问默认处于封锁状态。若启用互联网访问，可将其限制为特定域名以及GET、HEAD和OPTIONS这几种HTTP方法。

我的理解是：已知依赖项应在配置阶段安装，而在工作过程中发现的依赖项则需要能够在智能体阶段安装。正如第3节中AgentDojo和Progent的测试结果所示，排除未预见的依赖需求可能会导致智能体中途停止。然而，即便将请求限制为GET方法，仍然存在数据传输通道。在前文讨论的Hugging Face案例中，一个被记录为下载操作的请求，正是数据泄露的路径。

在配置阶段安装已知依赖项，并允许在边界范围内于工作过程中安装依赖项。限制软件包来源，并记录所有流量。

## 9. From Disposable Environments to Persistent Computers

对于能够自行构建环境的智能体而言，每次都从头开始是一种损耗。SetupBench报告了若干失败案例，其中全局安装的工具无法在跨shell会话时留存。在某一案例中，智能体安装了pnpm，但当评估框架开启新shell时，该工具便不可用了。

Anthropic关于长时运行智能体框架的文章，将跨上下文窗口的工作比作一支工程师团队轮班作业。接班的工程师不记得上一班次发生了什么。其设计方案在第一个会话中创建三项内容：

- 一个用于启动环境的脚本。

- 一个记录进度的文件。

- 一个初始git提交。

后续会话在每轮工作完成后为下一个会话留下线索。记忆存储于环境之中。

2026年1月，Fly.io的Kurt Mackey认为一次性沙箱已经过时，不应在每次使用后就被丢弃。他描述了智能体真正需要的东西：

> 它们不需要容器。它们不需要"沙箱"。它们需要的是计算机。

在Fly.io的定义中，计算机不必在一项任务结束时消失；它具备持久化存储。各服务提供商在状态保留方式上已存在差异。

Fly.io Sprites —— 隔离方式：microVM；状态保留：100 GB持久化存储，无时间限制，支持检查点与恢复。

E2B —— 隔离方式：Firecracker；状态保留：暂停的环境可无限期保留；快照包含内存状态。

Vercel Sandbox —— 隔离方式：Firecracker；状态保留：默认持久化；停止时自动对文件系统进行快照。

Modal —— 隔离方式：gVisor；状态保留：默认保留五分钟，最长可达24小时；支持文件系统快照。

Cloudflare Containers —— 隔离方式：每个容器独占一个虚拟机；状态保留：临时磁盘；目录备份至R2。

Codex 云 — 隔离方式：容器；状态保留：容器状态最多缓存 12 小时。

Web 版 Claude Code — 隔离方式：每个会话独立虚拟机；状态保留：安装结果以文件系统快照形式保留约七天。

Claude 托管智能体 — 隔离方式：每个会话独立容器；状态保留：每次会话使用全新容器，无共享文件系统。

Web 版 Claude Code 会在安装脚本执行完毕时对文件系统进行快照，并将该快照作为下一个会话的起点。脚本写入磁盘的内容得以保留，而仅处于运行状态的进程则不会保留。其他设计方案（如 Claude 托管智能体）则对每个会话使用全新容器。这种一次性设计的优势在于不会将此前的故障或污染带入新会话。这一选择需要权衡累积工作成果的价值与状态受到污染的风险。

沙盒的运行单元正从单次会话向持续使用的计算机转变。对于安装成本较高的任务，应选择能够保留安装结果的环境。如果还需要恢复运行中的服务器和进程状态，则应选择同时包含内存和文件系统的快照。持久化环境同样会积累故障。

## 10. 为安全失败而设计

拥有较高自由度的智能体终究会犯错。以下是已经发生的事故：

Replit，2025 年 7 月 — 事件经过：一个开发智能体在代码冻结期间删除了生产数据库数据；根本原因：开发数据库与生产数据库未进行隔离。

Google Antigravity，2025 年 12 月报道 — 事件经过：在 Turbo 模式下，一次删除缓存的操作删除了 D 盘根目录，且绕过了回收站；根本原因：智能体可以访问整个磁盘驱动器。

Gemini CLI，2025 年 7 月 — 事件经过：在执行文件夹整理请求后，文件丢失；根本原因：执行过程未在沙盒中进行。

Antigravity 事件由《The Register》根据一名用户的陈述报道。

在 Replit 事件中，SaaStr 的 Jason Lemkin 曾试图通过指令阻止该行为。《The Register》引用了他的话：

> 我明确用全大写告诉它十一次不要这样做。

Lemkin 还表示，Replit 等氛围编程应用程序没有办法强制执行代码冻结。Replit CEO Amjad Masad 在 X 上发帖表示，这种情况绝不应该发生，并于当周末开始推出开发数据库与生产数据库的自动隔离功能。这一应对措施旨在通过环境隔离从根本上杜绝此类事件的发生，而非依赖对智能体的指令约束。

指令无法创建边界，必须由环境来强制执行。

恢复机制同样存在局限。Claude Code 的检查点功能可以撤销通过智能体文件编辑工具所做的更改，但无法追踪通过 bash 命令修改的文件。Replit 的回滚功能也不会自动恢复生产数据库。智能体越多地使用 shell，工具级别的撤销操作就越显不足，而整体环境恢复也就越发必要。Fly.io 将 Sprites 检查点比作面向整个系统的 git。E2B 快照可同时捕获运行中沙盒的文件系统和内存状态。仅包含文件系统的快照无法恢复运行中的服务器或 shell 的状态。

智能体也可能破坏自己的沙盒。在长时间运行的 SandboxEscapeBench 实验中，在未能成功逃逸的试验里，Claude Mythos Preview 的 14 次试验中有 14 次沙盒变得无响应，Claude Opus 4.6 的 31 次试验中有 20 次出现同样情况。智能体运行了破坏性的漏洞利用程序，往往在尝试早期就损坏了自己的沙盒：中位数发生在转录记录进行到 11% 时。这些数据来自尝试沙盒逃逸的专项设置，但它们证明了智能体确实可能破坏自身运行环境。如果被破坏的环境可以丢弃并恢复，那它就只是一次尝试，而非一起事故。

Anthropic 内部收集的事故记录包括以下越界操作：

- 因误解指令而删除了远程 git 分支。

- 将一名工程师的 GitHub 身份验证令牌上传到内部计算集群。

- 尝试对生产数据库执行迁移操作。

沙盒快照无法撤销上述任何一项操作。

我的理解是，回滚适用于已捕获边界的内部。资源限制将失控的执行控制在边界之内，审计日志则提供了一种事后确认发生了什么的手段。

安全失败需要满足两个条件。沙盒无法撤销其变更的目标——例如生产数据库、远程代码仓库和凭证——不得从内部直接访问到。在边界范围内，应恢复整个环境，而非各工具单独的变更。目标是构建一个智能体失败后能够在边界内逆转的运行环境。

## Conclusion

综合来看，这是一台边界清晰划定的计算机：

H：定义目标和边界。

智能体计算机，强隔离：智能体 → Shell、运行时、软件包、持久化文件系统、浏览器；快照和回滚覆盖整个环境。

外部访问：智能体计算机 → 出口代理，限制目标和操作 → 策略，评估边界跨越 → Git、软件包和 API。

凭证：计算机外部的密钥库通过代理提供凭证。

审计：计算机本身及其出站流量均生成审计日志。

智能体的能力并非仅由其模型决定。同一模型在被赋予 Shell、依赖安装、执行反馈和持久化工作空间后，可以产生截然不同的结果。移除执行与验证能力对能力的影响最大；专用工具的数量并非决定性因素。

禁止危险命令名称既无法阻止相同行为的替代表达方式，也会阻碍无害的工作。逐一审批的方式随着时间推移会遗漏越来越多的危险操作，并妨碍长期自主运行。真正需要控制的是智能体的触达范围。

设计顺序如下：

1. 通过足够强的隔离建立文件系统和网络边界，以避免共享宿主内核。

1. 将凭证和生产数据保留在这些边界之外。

1. 允许在内部使用 Shell 和安装软件包，并使环境持久化。

1. 对跨越边界的操作进行评估，并使边界内的一切作为整体可恢复。

沙盒是赋予智能体自由的边界。

## References

## Models, Harnesses, and Environments

- Merrill et al. (2026) Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces. arXiv 相同模型、互联网访问及缺失命令失败情况下的测试框架差异。(https://arxiv.org/abs/2601.11868)

- Cheng et al. (2026) 《计算机环境在大型语言模型中激发通用智能体能力》。arXiv 沙盒访问权限对较强与较弱模型的相反影响。(https://arxiv.org/abs/2601.16206)

- Anthropic (2025) 《使用 Claude Agent SDK 构建智能体》 赋予智能体计算机的原则。(https://claude.com/blog/building-agents-with-the-claude-agent-sdk)

- OpenAI (2025) 《介绍 ChatGPT 智能体》 在虚拟计算机上运行的智能体。(https://openai.com/index/introducing-chatgpt-agent/)

- Manus (2025) 《AI 智能体的上下文工程：构建 Manus 的经验》 将文件系统用作上下文。(https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus)

## 限制与性能

- Yang et al. (2024) 《SWE-agent：智能体-计算机接口赋能自动化软件工程》。NeurIPS ACI 与仅使用 shell 的操作对比及组件消融实验。(https://arxiv.org/abs/2405.15793)

- Yang et al. (2023) 《InterCode：标准化并基准测试带执行反馈的交互式编程》。arXiv 执行反馈的效果。(https://arxiv.org/abs/2306.14898)

- SWE-agent. mini-SWE-agent 一个最简化的仅使用 bash 的智能体。(https://github.com/SWE-agent/mini-swe-agent)

- SWE-bench. SWE-bench Verified 仅使用 bash 的智能体排行榜。(https://www.swebench.com/verified.html)

- Yang, Yu, Desell (2026) 《何时将编程智能体限制为 execute_code 有帮助？一项制度 × 智能体设计消融研究》。arXiv 各工具配置之间成功率差异低于三个百分点。(https://arxiv.org/abs/2607.10569)

- Verdent (2025) 《Verdent SWE-bench Verified 技术报告》 仅使用基础工具时性能几乎不变。(https://www.verdent.ai/blog/swe-bench-verified-technical-report)

- Qu (2025) 《我们移除了智能体 80% 的工具》。Vercel 一次用 bash 替代专用工具的内部部署实践。(https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools)

- Debenedetti et al. (2024) 《AgentDojo：用于评估大型语言模型智能体提示注入攻击与防御的动态环境》。NeurIPS 工具过滤的有效性，以及在无法提前规划工具需求时的局限性。(https://arxiv.org/abs/2406.13352)

- Shi et al. (2025) 《Progent：面向大型语言模型智能体的可编程权限控制》。arXiv 静态限制与运行时权限扩展的对比。图示使用 v1 版本；当前标题为"Progent: Securing AI Agents with Privilege Control"。(https://arxiv.org/abs/2504.11703)

## 审批与许可名单

- Dworken, Weller-Davies (2025) 《超越权限提示：让 Claude Code 更安全、更自主》。Anthropic 权限提示减少 84%，以及文件系统与网络隔离。(https://www.anthropic.com/engineering/claude-code-sandboxing)

- Hughes (2026) 《我们如何构建 Claude Code 自动模式：一种更安全的跳过权限方式》。Anthropic 移除允许任意代码执行的权限规则；沙盒运营成本。(https://www.anthropic.com/engineering/claude-code-auto-mode)

- Anthropic (2026) 《我们如何在各产品中约束 Claude》 监督触达范围而非行为、网络钓鱼演练，以及基于许可名单的数据外泄防控。(https://www.anthropic.com/engineering/how-we-contain-claude)

- Anthropic (2026) 《自动模式现已成为 Claude Code Pro、Max 和 Team 计划的默认设置》 针对 1,053 名测试者的实验及权限规则使用情况。(https://claude.com/blog/auto-mode-default-in-claude-code)

- OpenAI. 《智能体审批与安全 – Codex》 对强制边界的信任。(https://developers.openai.com/codex/agent-approvals-security)

- GTFOBins 通过常见命令启动 shell 的方式。(https://gtfobins.github.io/)

- npm Docs. scripts 由 npm install 执行的生命周期脚本。(https://docs.npmjs.com/cli/v11/using-npm/scripts)

- Backslash Security (2025) 《拒绝名单的幻觉：Cursor 的自动运行让智能体 AI 门户大开》 四种拒绝名单绕过方式及所述定理。(https://www.backslash.security/blog/cursor-ai-security-flaw-autorun-denylist)

- Cursor. GHSA-534m-3w6r-8pqr (CVE-2025-54131) 允许命令中的命令替换。(https://github.com/cursor/cursor/security/advisories/GHSA-534m-3w6r-8pqr)

- Anthropic. GHSA-x56v-x2h6-7j34 (CVE-2025-54795) 通过 echo 解析错误绕过审批。(https://github.com/anthropics/claude-code/security/advisories/GHSA-x56v-x2h6-7j34)

- Anthropic. GHSA-qgqw-h4xq-7w8w (CVE-2026-24887) 使用 find 绕过审批。(https://github.com/anthropics/claude-code/security/advisories/GHSA-qgqw-h4xq-7w8w)

- Anthropic. GHSA-7mv8-j34q-vp7q (CVE-2025-64755) 通过绕过 sed 验证实现任意文件写入。(https://github.com/anthropics/claude-code/security/advisories/GHSA-7mv8-j34q-vp7q)

- Tracebit (2025) 通过欺骗执行代码：Gemini AI CLI 劫持——通过伪装成 grep 的命令窃取环境变量。(https://tracebit.com/blog/code-exec-deception-gemini-ai-cli-hijack)

- Embrace The Red (2025) GitHub Copilot：通过提示注入实现远程代码执行 (CVE-2025-53773)——通过修改设置禁用审批。(https://embracethered.com/blog/posts/2025/github-copilot-remote-code-execution-via-prompt-injection/)

## 威胁模型与安全事件

- Meta (2025) 智能体二选二原则：AI 智能体安全的实用方法——一个将智能体限制为三个属性中两个的框架。(https://ai.meta.com/blog/practical-ai-agent-security/)

- Willison (2025) 新提示注入论文：智能体二选二原则与攻击者后发制人——关于二选二原则的疑问以及 Mick Ayzenberg 的澄清。(https://simonwillison.net/2025/Nov/2/new-prompt-injection-papers/)

- The Register (2025) 氛围编程服务 Replit 删除了生产数据库——在代码冻结期间删除生产数据库。(https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/)

- Masad (2025) X 帖子——自动分离开发环境与生产环境数据库。(https://x.com/amasad/status/1946986468586721478)

- The Register (2025) Google 的氛围编程平台删除了整个云端硬盘——关于在 Turbo 模式下删除云端硬盘的报告。(https://www.theregister.com/2025/12/01/google_antigravity_wipes_d_drive/)

- google-gemini/gemini-cli Issue #4586 关于在无沙盒环境下文件丢失的报告。(https://github.com/google-gemini/gemini-cli/issues/4586)

- Anthropic. GHSA-fg94-h982-f3mm (CVE-2026-54316) 通过预先批准的 Hugging Face 域名进行数据窃取。(https://github.com/anthropics/claude-code/security/advisories/GHSA-fg94-h982-f3mm)

- OpenAI. GHSA-w5fx-fh39-j5rw (CVE-2025-59532) 一个将模型生成的工作目录误作沙盒范围的漏洞。(https://github.com/openai/codex/security/advisories/GHSA-w5fx-fh39-j5rw)

- Anthropic. GHSA-7835-87q9-rgvv (CVE-2026-55607) 利用 git worktree 在沙盒外执行代码。(https://github.com/anthropics/claude-code/security/advisories/GHSA-7835-87q9-rgvv)

## 隔离与持久化

- Anthropic. 安全部署 AI 智能体——容器共享宿主内核带来的风险。(https://code.claude.com/docs/en/agent-sdk/secure-deployment)

- Marchand 等人 (2026) 量化前沿 LLM 的容器沙盒逃逸能力。arXiv SandboxEscapeBench：容器逃逸与智能体自毁沙盒。(https://arxiv.org/abs/2603.02277)

- Agache 等人 (2020) Firecracker：面向无服务器应用的轻量级虚拟化。NSDI——轻量级微虚拟机设计与性能。(https://www.usenix.org/conference/nsdi20/presentation/agache)

- gVisor. 安全模型——一种不将系统调用直接传递给宿主机的设计。(https://gvisor.dev/docs/architecture_guide/security/)

- Kata Containers——通过虚拟机隔离的容器。(https://katacontainers.io/)

- Mackey (2026) 代码与共存。Fly.io——从一次性沙盒到持久化计算机。(https://fly.io/blog/code-and-let-live/)

- Ptacek (2026) Sprites 的设计与实现。Fly.io——100 GB 持久化存储与检查点。(https://fly.io/blog/design-and-implementation/)

- E2B. 沙盒持久化——无限期暂停状态保留及包含内存的快照。(https://docs.e2b.dev/sandbox/persistence)

- Vercel. 理解沙盒——默认持久化的沙盒。(https://vercel.com/docs/sandbox/concepts)

- Modal. 沙盒——运行时限制与文件系统快照。(https://modal.com/docs/guide/sandboxes)

- Cloudflare. 容器架构——每个容器独立虚拟机与临时磁盘。(https://developers.cloudflare.com/containers/concepts/architecture/)

- OpenAI. 云环境 – Codex——两阶段执行、密钥移除与 12 小时缓存。(https://learn.chatgpt.com/docs/environments/cloud-environment)

- OpenAI. 智能体互联网访问 – Codex web——域名白名单与 HTTP 方法限制。(https://learn.chatgpt.com/docs/cloud/internet-access)

- Anthropic. 配置云环境——每会话虚拟机与文件系统快照缓存。(https://code.claude.com/docs/en/cloud-environments)

- Anthropic. 云环境设置 托管代理为每个会话使用全新容器。(https://platform.claude.com/docs/en/managed-agents/environments)

- Anthropic. 检查点 不追踪 bash 更改的检查点。(https://code.claude.com/docs/en/checkpointing)

- Replit. 检查点与回滚 不自动恢复生产数据库的回滚。(https://docs.replit.com/features/version-control/checkpoints-and-rollbacks)

## 环境设置与长时间自主运行

- Arora et al.（2025）SetupBench：评估软件工程代理引导开发环境的能力。arXiv 引导空环境及未能保存更改的问题。(https://arxiv.org/abs/2507.09063)

- Eliseeva et al.（2025）EnvBench：自动化环境设置基准测试。arXiv Python 和 JVM 仓库的设置成功率。(https://arxiv.org/abs/2503.14443)

- Pan et al.（2025）使用 SWE-Gym 训练软件工程代理与验证器。ICML 约 200 小时的手动依赖项设置。(https://arxiv.org/abs/2412.21139)

- Yang et al.（2025）SWE-smith：为软件工程代理扩展数据。arXiv 针对 128 个仓库的代理驱动设置。(https://arxiv.org/abs/2504.21798)

- OpenAI（2025）介绍 Codex 的升级 超过七小时的独立工作与自动环境设置。(https://openai.com/index/introducing-upgrades-to-codex/)

- Anthropic（2025）介绍 Claude Sonnet 4.5 超过 30 小时的持续专注工作。(https://www.anthropic.com/news/claude-sonnet-4-5)

- METR. 时间跨度 以人工工作时间衡量的任务跨度。(https://metr.org/time-horizons/)

- Young（2025）长时间运行代理的有效框架。Anthropic 轮班工作类比与存储于环境中的交接信息。(https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)