AI代理的执行沙箱：架构、风险和现实世界模式

主页 » Python » AI代理的执行沙箱：架构、风险和现实世界模式

让 AI 代理运行代码、修改文件、打开浏览器和调用 API，就能让它们从花哨的自动补全功能变成更接近拥有机器 root 权限的初级工程师的功能。 正是这种额外的力量让它们感觉神奇——也正是它们危险的原因。一个配置错误或存在漏洞的代理程序可能会擦除数据库、将 API 密钥泄露到互联网上，或者在不真正“理解”哪里出了问题的情况下，将一个损坏的版本部署到生产环境中。

真正的问题不再是“模型有多准确？”，而是“当模型出错、被欺骗或过于自信时，它能达到什么程度？” 代理的执行沙箱是工程上的理想解决方案：它提供严格限定的环境，代理可以在其中读写代码、运行 shell、启动服务器或打开浏览器，而您可以严格控制文件系统、网络、凭据和生命周期。这样一来，您无需信任模型，而是可以限制其影响范围。

为什么编码代理需要专用的执行沙箱

像 Claude Code、LangChain Deep Agents、Docker 的编码沙箱和类似工具这样的现代编码代理不再像具有文件访问权限的简单聊天机器人那样运行。 它们可以读取整个代码库、编辑文件、运行 shell 命令、操作 Git、启动 Docker 构建、与外部 API 通信，甚至可以通过浏览器运行完整的桌面环境。供应商文档对此有非常明确的说明：Claude Code 被定位为敏捷开发助手，可以检查代码库、进行编辑并运行命令；LangChain Deep Agents 将沙箱后端作为执行 shell 命令、管理文件系统并将工作委派给子代理以实现隔离的场所。

正是这种能力组合使得这些特工变得有用，但也带来了操作风险。 一旦模型可以运行 pytest安装 npm 包、打开分支或调试构建失败，只需调用几个工具，就能修改部署脚本、推送损坏的镜像、调整 CI 配置，甚至通过 HTTP 请求窃取令牌。OpenAI 自身的代理安全指南和 NIST 关于代理劫持的研究都强调了提示注入：隐藏在文件、网页或日志中的恶意指令可以悄无声息地引导代理执行你从未授权的操作。

许多团队一开始都采用简单的“请求批准”流程来执行每个命令，但很快就会发现这种流程无法扩展。 Anthropic 公开表示，用户批准了 Claude Code 93% 的权限提示；Docker 的 Claude 沙箱甚至可以启动 Claude Code。 --skip-permissions 默认情况下，系统会依赖运行时隔离，而不是铺天盖地的对话框。用户会感到审批疲劳，尤其是在并行运行多个代理程序并在众多提示之间频繁切换上下文时。此时，确认对话框就沦为形式，而非可靠的控制手段。

执行沙箱将安全模型从“信任用户会阅读每个提示”转变为“假设某些命令是错误的或具有对抗性的，并限制它们可能造成的损害”。 沙箱成为代理可以接触的文件、进程、网络和秘密的硬性边界，即使代理受到提示注入的操纵或只是犯了错误。

从开发者体验的角度来看，还有一个基本论点：代理需要足够的空间才能真正发挥作用。 如果过度限制沙箱环境，例如使用过于粗糙的限制，那么像构建或测试这样简单的命令就会不断因莫名其妙的权限错误而失败。像 Cursor 在 macOS/Linux/Windows 上部署的系统，或者 Cloudflare、Heroku 和 Google Cloud 为托管工作负载提供的系统，都力求在严格的边界内为代理提供“真实计算机”般的体验。

代理执行沙箱究竟隔离了什么？

一个合适的代理沙箱不仅仅是“运行代码的另一个地方”——它是一系列明确定义爆炸半径的边界。 您可以想到在 Docker 沙箱、Cloudflare 沙箱、GKE Agent 沙箱、Freestyle VMs、E2B 或 Daytona 等领先平台中反复出现的五个主要限制。

首先是文件系统边界：代理程序应该只能看到您有意共享的工作区。 LangChain 的文档将沙箱描述为阻止代理程序访问主机文件的屏障；Docker 的沙箱模型则非常明确地指出，微型虚拟机只能看到显式挂载的项目目录。该目录树之外的任何内容都是不可见的或只读的，因此代理程序无法随意读取这些内容。 ~/.ssh 或者重写系统配置。

其次，进程和内核边界：代理工作负载不应该共享原始主机内核或进程表。 Docker 的沙箱架构将每个环境隔离在各自的环境中。 microVM 和 Linux 内核Firecracker（被多家供应商底层使用）将虚拟机边界视为第一层隔离，然后在其上添加安全组合、命名空间、cgroups 和类似 jail 的限制。谷歌的 GKE Agent Sandbox 使用 gVisor 在 Kubernetes 内部实现了类似的效果：一个“哨兵”层拦截系统调用并协调对底层节点的访问。

第三，网络边界：如果没有网络策略，沙盒代理仍然是数据泄露机器。 现在大多数主流平台默认都启用“拒绝所有出站流量”功能。例如，Docker 沙箱会阻止 HTTP/HTTPS 连接，直到用户明确允许为止；它会切断原始的 TCP/UDP/ICMP 协议；并且除非用户配置例外，否则会禁止访问私有 IP 地址范围和本地主机。Cloudflare、Google 等公司则在其沙箱中设计了可编程代理，允许出站请求通过这些代理服务器，用户可以在这些代理服务器上注入身份验证信息、过滤目标地址并审计流量使用情况。

第四，凭证边界：在沙箱内暴露原始密钥应被视为最后的手段，而不是默认做法。 Docker 的设计是通过主机端代理路由 HTTP 调用，该代理可以将令牌或 API 密钥附加到请求中，而无需将这些原始值放入虚拟机内部。Cloudflare 沙箱也类似地在网络层注入凭据，而不是通过环境变量。这样，即使提示注入导致代理“打印所有环境变量”，也无法窃取任何有价值的信息。

第五，生命周期边界：代理工作空​​间很少只为一个命令而存在；它们需要明确的语义来实现启动、暂停、快照、分支和拆除。 E2B 提供隔离的文件系统、后台命令和卷，这些功能可以超越单个沙箱的生命周期。Freestyle 专注于极速启动、挂起和恢复虚拟机，并支持内存状态的快照和分支管理。Daytona 在快照沙箱的基础上增加了自动停止、自动归档和自动删除策略，使您可以长期保留某些环境，并将其他环境视为一次性环境。

一旦你了解了这五个维度——文件系统、进程、网络、凭证和生命周期——你就可以把任何沙盒产品页面看作是一系列权衡取舍。 具有大型主机挂载点但出口规则严格的共享内核容器，与不挂载主机但网络权限更宽松的微型虚拟机截然不同。对于需要安装依赖项、运行浏览器或构建 Docker 镜像的编码人员来说，更严格的虚拟机式边界往往是更安全的默认选择。

macOS、Linux 和 Windows 上的本地编码代理沙盒

在开发人员的笔记本电脑上，你不可能总是启动重量级的微型虚拟机沙箱，因此团队不得不发挥创造力，利用操作系统原生隔离来实现隔离。 Cursor 最近在本地沙箱方面的工作就是一个很好的例子，它针对 macOS、Linux 和 Windows 的具体情况进行了调整，同时保持了代理层的统一 API。

在 macOS 上，我们评估了几个选项：App Sandbox、通用容器、完整虚拟机以及一项名为 Seatbelt 的长期存在但已被“弃用”的技术。 应用沙箱需要对代理可能执行的每个二进制文件进行签名，这将显著增加复杂性，甚至赋予生成的二进制文件传递信任。Linux 容器会迫使 macOS 用户使用仅限 Linux 的二进制文件，而完整的虚拟机则存在无法接受的启动延迟和内存开销，不利于交互式编码流程。

安全带，可通过以下方式取用 sandbox-exec尽管年代久远，但最终还是务实的选择。 它允许您在沙盒配置文件下运行命令，该配置文件使用细粒度的策略语言约束整个进程树：您可以将特定的系统调用列入白名单或阻止，并将读/写权限限制到目标文件或目录。Cursor 会根据工作区和管理员设置以及用户的权限在运行时动态生成这些策略。 .cursorignore因此，被忽略的路径在沙箱内将变为不可访问。

在 Linux 系统中，内核公开了正确的原语——seccomp 用于系统调用过滤，Landlock 用于文件系统限制——但将组合操作留给了用户空间。 与其依赖现有的不支持仓库特定忽略的开源软件封装器，不如像这样： .cursorignoreCursor 选择直接协调 Landlock 和 seccomp。Seccomp 禁止危险的系统调用；Landlock 强制执行基于路径的读/写规则，甚至允许这些规则覆盖用户工作区，从而使被忽略的文件完全无法访问，或者被沙盒进程无法读取或修改的受保护副本所替换。

Linux 的一个微妙之处在于性能：重新挂载或重写所有忽略的文件是沙箱设置中最慢的部分。 macOS 式的延迟过滤可以在系统调用时看到确切的文件路径，这将简化此过程，但 Linux 的 seccomp-bpf 无法轻松进行路径检查，因此在严格的隔离和启动速度之间存在着真正的工程权衡。

在 Windows 系统上，构建一个真正等效的原生沙箱仍然更加困难，因为大多数隔离原语都是针对浏览器优化的，而不是针对通用开发工具优化的。 Cursor 目前在 WSL2 中为 Windows 用户运行一个 Linux 沙箱，本质上是利用 Linux 的隔离机制，直到更完善的基础功能可用。他们正与微软合作，开放必要的功能，以便最终让 Windows 代理能够享受到一流的原生沙箱体验，而无需依赖 WSL。

这些针对特定操作系统的方法的共同之处在于，它们都采用了统一的沙箱 API。 从代理的角度来看，它只是一个功能和规则清晰的“外壳工具”。在底层，Seatbelt、Landlock/seccomp 或基于 WSL2 的隔离机制会根据不同的平台以不同的方式强制执行这些规则。

教导智能体理解并尊重沙盒环境

只有当代理能够预测沙箱内部哪些操作有效，以及何时需要提升权限或离开沙箱时，沙箱才能发挥作用。 这听起来显而易见，但实际上，对于提供编码代理的供应商来说，这需要一些令人惊讶的深入提示和工具设计迭代。

许多团队采取的第一步是改进工具描述，特别是 shell 执行方面的描述。 该工具的描述并非泛泛地使用“运行 shell 命令”这样的通用工具，而是明确指出其可访问的资源：根据用户配置，该命令是否拥有文件系统访问权限、Git 访问权限、网络访问权限，或者是否支持完全离线环境。此外，它还说明了代理如何在必要时请求提升权限（例如，访问公共互联网）。这种提示性的工程工作往往非常依赖经验：团队运行常见的部署流程，观察模型在哪些方面预测有误，然后调整工具描述并重复此过程。

然后使用“Cursor Bench”或类似的内部基准测试或评估套件来比较有沙箱和无沙箱情况下的代理性能。 早期出现的一个故障模式非常稳定：代理会盲目地反复尝试同一个失败的终端命令，而不是意识到它遇到了沙箱限制。由于没有明确的失败原因，模型无法学习这种模式。

解决方法是在工具输出中明确显示沙箱错误，通常还会提示下一步该怎么做。 当命令因文件系统或网络规则而被阻止时，shell 工具会开始提供简短的解释，例如“被沙箱阻止：此会话已禁用出站网络访问”，并且在某些情况下，还会提示代理可以请求提升权限。此项更改后，代理的恢复能力显著提高：它们不再循环执行无效命令，而是调整执行计划或请求所需的权限。

线下评估很有帮助，但它只能说明部分情况。 为了真正了解沙盒机制是否会降低用户体验，各团队已在生产环境中逐步部署沙盒支持，并密切关注错误率、完成时间和反馈渠道。实践表明，在兼容平台上，相当一部分查询现在完全在沙盒内运行——NVIDIA 等企业客户是早期采用者之一——而且在实际工作流程中，沙盒代理的审批暂停次数减少了约 40%，从而节省了数小时的人工审核时间，同时降低了风险。

展望未来，人们对“原生沙箱代理”（直接根据其环境约束进行训练的模型）非常感兴趣。 这些代理不再将 shell、浏览器或文件系统视为抽象工具，而是会意识到它们运行在一个范围严格的运行时环境中，可以编写长时间运行的脚本和程序，并且必须遵守诸如“禁止出站网络”或“工作区只读”之类的边界条件。这种训练能够使它们更好地规划安全高效的操作序列，避免碰壁。

云沙箱：Cloudflare、Google Cloud、Heroku 等

在开发者的笔记本电脑之外，一大批基础设施提供商正在竞相提供专门针对人工智能代理的托管沙箱。 它们的目标相同——隔离、控制和性能——但在云规模下，权衡取舍的情况看起来略有不同。

Cloudflare Sandboxes 构建于 Cloudflare Containers 之上，现已正式推出，旨在为代理提供外观和感觉上都像完整的开发环境。 每个沙箱都是一个持久的、隔离的工作区，您可以通过名称来访问它。如果它处于休眠状态，则会在需要时启动；如果它处于空闲状态，则会自动暂停以节省计算资源，并在下次请求时恢复。开发人员（或代理）可以通过类型化方法与它进行交互，例如 exec, gitCheckout, writeFile以及更多功能，使用 JavaScript/TypeScript SDK。

云计算领域最棘手的问题之一是代理沙箱内部的安全身份验证。 代理经常需要访问私有服务，但您不希望原始凭据随意存储在环境变量中。Cloudflare 在网络代理层注入凭据，通过主机将出站请求映射到自定义逻辑，该逻辑会从安全存储中附加令牌。沙箱进程永远不会看到真正的密钥，但调用仍然会经过身份验证。这种设计支持动态的、身份感知的凭据注入，并且与 Workers 绑定完美兼容。

对于终端密集型工作流程，Cloudflare 添加了通过 WebSocket 和 xterm.js 连接的完整 PTY（伪终端）体验。 代理和用户都可以打开实时 shell 会话，中断进程，稍后重新连接并重放之前的输出。每个 PTY 都有自己的工作目录和环境，输出会在服务器上进行缓冲，以便重新连接的客户端可以查看错过的日志。

除了提供原始 shell 访问权限外，Cloudflare 还为 Python、JavaScript 和 TypeScript 等语言提供持久的“代码执行上下文”。 与许多将每个片段独立执行的代码片段运行器不同，这些上下文会在调用之间保留变量、导入和状态，就像 Jupyter Notebook 一样。代理可以在一次调用中加载数据，在另一次调用中转换数据，并渲染图表或 HTML 表格，而无需不断地重新解析和重新导入所有内容。

对于 Web 开发任务，Cloudflare 沙箱支持后台进程、健康检查和实时预览 URL。 代理人可以开始 npm run dev 作为后台任务，监视日志直到服务器准备就绪，然后将端口暴露给公共预览 URL。类似这样的方法 waitForPort() or waitForLog() 让代理根据真实的准备信号而不是简单的指令来安排行动顺序 sleep(2s) 猜测。

事件驱动型工作流受益于 Linux inotify 机制支持的文件监视原语。 代理人可以订阅以下变更 /workspace/src 当 TypeScript 文件被修改时，它会自动重新运行测试或构建。这与人类开发者所依赖的反馈循环相同，但通过 API 等方式使其对代理而言更加原生。 sandbox.watch() 以及服务器发送的事件流。

为了完善生命周期，Cloudflare 正在推出真正的快照——虚拟机级别的状态捕获，可以在几秒钟内从 R2 存储中恢复。 快照会持久保存文件系统状态、操作系统配置、已安装的依赖项和数据文件；未来的版本还将恢复实时内存状态，以便即时恢复。代理（或协调器）可以通过编程方式触发快照，用于检查点或扇出场景，然后从同一个快照派生多个沙箱，以便在隔离的环境中并行探索各种假设。

在定价方面，Cloudflare 采用了“仅使用活跃 CPU”的模式：您只需为实际使用的 CPU 周期付费，而无需为代理等待 LLM 时的空闲时间付费。 结合“轻量级”和大型实例的巨大并发上限，这使得运行大量代理而无需在休眠容器上浪费资金成为可能。

相比之下，Google Cloud 的 GKE Agent Sandbox 与 Kubernetes 和 gVisor 深度集成。 其理念是让您在自己的集群内部的隔离 Pod 中运行代理工作负载。您可以创建一个 GKE 集群（Autopilot 可以自动启用 gVisor，而标准集群则需要显式的运行时类和启用 gVisor 的节点池），然后通过版本化的清单部署代理沙箱控制器。

该模型由两个核心自定义资源驱动： SandboxTemplate 和 SandboxWarmPool. SandboxTemplate 充当可重用的蓝图，指定 pod 模板（镜像、端口、资源等）。 runtimeClassName: gvisor等等）适用于沙盒运行时环境，例如 Python 环境。 SandboxWarmPool 保持一定数量的预热舱随时待命，以便快速领取，避免代理在不到一秒的时间内需要全新环境时出现冷启动的情况。

A Sandbox Router 然后，该服务充当客户端与这些隔离的 pod 之间流量的网关。 在开发过程中，你可以通过隧道传输流量。 kubectl port-forward 无需暴露公网 IP 地址。在生产环境中，通常需要在路由器前端配置合适的入口路由和 mTLS。在客户端，Google 提供了一个 Python 库“Agentic Sandbox”，它封装了完整的生命周期：从模板创建沙箱声明、等待沙箱准备就绪、运行 shell 命令，并在完成后进行清理。

这一切底层仍然“只是 Kubernetes”，但被打包成一个连贯的故事，供代理运行时使用。 gVisor 提供进程和系统调用隔离，SandboxTemplate 规范配置，WarmPool 解决启动延迟问题，路由器加上 Python 客户端使其对以 LLM 为中心的应用程序来说很方便。

而 Heroku 则依赖于一个非常成熟的构建模块：一次性 dyno。 多年来，Heroku 用户一直在按需启动、完成后即销毁的临时 dyno 中运行临时任务，例如迁移、维护脚本和管理任务。Heroku 将这一基础设施重新用于代码执行沙箱，并与 Managed Inference 和 Agents 服务一同推出。Agent 编写 Python、Ruby、Node 或 Go 代码片段；Heroku 在生命周期较短的 dyno 中执行这些代码片段，并将结果流式传输回服务器，从而将影响范围限制在临时容器内。

您可以通过 Heroku Agents API 中的内置工具或部署开源模型上下文协议 (MCP) 服务器来访问这些沙箱。 MCP 服务器公开标准化的工具端点，因此像 Agentforce、Claude Desktop 或 Cursor 这样的客户端可以将 Heroku 的沙箱视为通用的远程代码执行后端。每个服务器都支持运行时特定的限制（例如 max_calls 每个代理循环）以防止代理陷入紧密、代价高昂的循环。

LangChain 的深度代理通过与 Runloop、Daytona 和 Modal 等第三方沙箱提供商集成，增添了另一个维度。 模式很简单：深度代理程序可以持续在您想要的任何位置（本地或云端）运行，但每当它需要运行命令、创建文件或执行代码时，这些操作都会被转发到远程沙箱。设置脚本可以预加载环境变量、克隆代码库、安装工具等等，从而确保每个代理程序都能获得一个干净、受控的环境。上下文管理器负责创建和清理这些沙箱，但文档强烈建议监控提供商的控制面板，以防遗漏任何长时间运行的沙箱。

性能、状态和分支：为什么速度对智能体至关重要

速度慢但安全性极高的沙箱在实践中会被绕过；开发者工具的成败取决于延迟。 编码智能体并非像夜间批处理作业那样运行。它们执行交互式循环：读取代码、提出修改建议、运行测试、分析日志、调用工具、等待人工干预，然后重复上述过程。在实际会话中，它们还会探索问题的多个分支，放弃某些路径，稍后再返回尝试其他路径。

这就是为什么像 Freestyle 这样的平台如此重视亚秒级的虚拟机生命周期时间和丰富的状态语义。 他们的虚拟机是完整的 Linux 系统，具备 root 权限、systemd 服务、嵌套虚拟化支持和完整的网络功能。文档声称，从 API 调用到虚拟机运行，部署时间不到 800 毫秒，挂起/恢复时间不到 100 毫秒，并且能够在执行过程中对虚拟机进行快照或创建子虚拟机，性能损失极小。他们明确指出浏览器状态是这项技术的受益者：如果代理将浏览器驱动到某个特定状态，它可以从同一个快照创建该虚拟机 20 次子虚拟机，而无需从头开始重新创建该状态。

Google 的 SandboxWarmPool for GKE 用 Kubernetes 术语表达了相同的理念：保留一个预热 pod 池，这样代理就不会在每次新运行时支付完整的冷启动惩罚。 Daytona 基于快照的工作区以及自动停止/存档/删除策略，可针对不同类型的会话调整生命周期：活跃的开发环境、短暂的实验和长期存在的基线。

E2B 对后台作业、可监视目录、隔离文件系统和可重用卷的重视，是同一枚硬币的另一面。 这些功能允许代理在探索代码变更时保持开发服务器或测试环境运行，或者在多个临时沙箱之间共享持久卷。如果没有这些功能，代理最终只能执行一次性命令并丢失上下文，从而严重影响工作效率。

评估任何用于代理工作的沙箱的一个有效方法是提出一些直截了当的问题。 我能否在不到一秒的时间内启动一个全新的环境？我能否干净利落地保存和恢复状态，包括部分构建或浏览器会话？我能否创建多个状态副本以进行并行探索？我能否为“稍后再来”的流程保留长期运行但资源高效的工作区？您得到的“是”的答案越多，您的代理就越能像真正的工程师那样工作，而不是无状态的脚本运行器。

密钥、网络策略和工作区信任才是真正的控制平面

即使主机隔离完美，如果忽略密钥、网络策略和工作区信任，也很容易构建不安全的系统。 Docker 的沙箱文档在这方面坦诚得令人耳目一新。微型虚拟机及其私有的 Docker 守护进程构成了与宿主机之间的主要信任边界。然而，在虚拟机内部，代理拥有完全的 root 权限，并且共享工作区以读写模式挂载。默认情况下，任何文件编辑都会立即反映到宿主机上。网络出口默认被拒绝，仅允许通过显式规则访问，HTTP 请求使用宿主机端代理，该代理可以在不将原始密钥暴露给虚拟机的情况下注入凭据。

这意味着隔离主机只是第一步；你仍然需要考虑代理会对工作区和外部世界做什么。 Docker 的文档明确警告说，如果代理编辑了稍后由人类执行的脚本——例如 Git 钩子、CI 配置、IDE 任务定义等， Makefile 目标， package.json 脚本——当这些脚本运行时，损害可能会“跳转”回主机或持续集成系统。他们甚至强调了 Git 钩子在 .git/ 不要出现在 git diff这使得恶意逻辑更容易在后台静默运行。

凭证代理功能强大但又不易察觉。 Docker 的出站代理确保密钥保留在虚拟机外部，但仍然允许代理使用这些身份对授权主机执行操作。某些流程（例如将自定义环境变量写入文件） /etc/sandbox-persistent.sh – 通过故意将密钥存储在虚拟机内来打破此界限，但这只有在您真正信任代理和沙箱时才是安全的。

配置范围与密钥同等重要。 Docker 的常见问题解答中提到，用户级配置，例如 ~/.claude or ~/.codex 主机上的配置不会复制到沙箱中；只有共享工作区中的项目级配置才可见。Anthropic 的配置文档强调，项目级设置（工具、权限、MCP 服务器、钩子等）会覆盖用户级设置，并在团队之间共享。换句话说，您附加到代码库的任何策略、指令和插件都将成为代理程序可见的主要界面。

OpenAI 的技能指导用略有不同的措辞强调了类似的观点。 技能（工具包）可能会引入由提示注入驱动的数据泄露风险。文档警告不要将未经审核的公开技能市场直接暴露给最终用户，因为恶意 SKILL.md 文件可以绕过策略、触发破坏性操作或泄露私人数据。文档建议对开发者技能进行审核，将其范围限定于特定工作流程，将高影响操作隐藏在额外的审批和策略检查之后，并将技能纳入威胁模型。

把这些部分组合起来，代理沙箱的“真正”控制平面跨越了四层。 主机隔离保护您的机器和集群节点。工作区信任保护未来运行沙箱内生成文件的人员或配置项 (CI)。网络策略保护外部系统和私有数据源。凭证管理保护代理程序所使用的身份。一个稳健的设计应该能够兼顾所有这四点，而不仅仅是第一点。

除此之外，你还需要对快速注射和代理人劫持保持一定的怀疑态度。 NIST、OWASP 和 OpenAI 都描述了同一种模式的不同变体：不受信任的输入（例如 README 文件、网页或日志文件）嵌入了恶意指令，从而重定向智能体的行为。检索增强生成和微调并不能神奇地解决这个问题。一个配置完善的沙箱加上良好的策略无法完全阻止模型被欺骗，但可以显著降低被欺骗带来的负面影响。

云平台和代理运行时开始将这些经验教训编码到系统中。 秘密代理、允许列表出站域、仓库范围配置、功能较窄的子代理、基于钩子的审批流程和可复现的沙箱，都是同一个难题的组成部分：接受模型会出错，并设计环境，使这种出错的成本保持在可控范围内。

无论在本地还是云端环境中，代理的执行沙箱最好被理解为一条精心划定的界限：它不会让模型更智能，而是让它的错误不那么具有灾难性，更容易被观察到。 通过对文件系统、进程、网络、密钥和生命周期控制进行适当的组合，再加上对代理进行关于其环境的智能教学，您可以让 AI 系统克隆存储库、运行测试、启动浏览器，甚至接触类似生产环境的系统——而无需将您关心的一切的密钥交给它们。

这意味着隔离主机只是第一步；你仍然需要考虑代理程序可能对工作区和外部世界造成的影响，包括风险因素。 远程代码执行. Docker 的文档明确警告说，如果代理编辑了稍后由人类执行的脚本——例如 Git 钩子、CI 配置、IDE 任务定义等， Makefile 目标， package.json 脚本——当这些脚本运行时，损害可能会“跳回”主机或 CI 系统。