AI Agent Sandbox 怎么设计？Hosted vs Self-hosted、文件、Secret、网络与持久化

先给结论：Sandbox 不是“给 Agent 一台机器”，而是划清它能碰什么

当 Agent 只能生成文字时，最坏的问题通常是回答错误；当 Agent 可以运行 Shell、安装包、写文件、启动浏览器、访问 API，风险就从“内容错误”变成了执行边界错误。

生产环境里的 Sandbox 要解决的不是“让代码能跑”，而是同时回答五个问题：

1. Agent 能读写哪些文件？
2. Agent 能访问哪些网络目标？
3. Agent 什么时候、以什么权限拿到 Secret？
4. 工作目录和生成文件需要保留多久？
5. 不同用户、项目或任务之间是否真正隔离？

如果这五个问题没有独立于 Prompt 之外的确定性答案，那么“请不要读取别人的文件”“不要访问生产接口”只是文字约束，不是安全边界。

OpenAI 当前把 Sandbox 定义为带文件系统、Shell、Packages、Ports、Snapshots 和受控外部访问的隔离执行环境，并同时提供 Hosted 与 Self-hosted 两种环境模型。Anthropic 对 Claude Code 的 Sandbox 也把边界收敛到两个核心面：文件系统和网络。它们的产品实现不同，但背后的生产问题高度一致。

Hosted vs Self-hosted：先看责任边界，不要先看品牌

最容易犯的错，是把 Hosted 和 Self-hosted 理解成“云上”和“本地”两个部署地点。真正影响架构的是：谁负责创建、隔离、更新、销毁执行环境，以及你的业务必须控制到哪一层。

维度	Hosted Sandbox	Self-hosted Sandbox
环境创建与生命周期	平台负责	你负责
基础镜像与常用运行时	平台预置或模板化	完全自定义
私有网络/VPC	通常受平台能力限制	最灵活
特殊硬件/GPU/内部工具	取决于平台	最可控
网络策略	平台策略/allowlist	你负责网络层强制
Secret 接入	优先用平台 Vault/Secret	自建 Secret Manager/Proxy
持久化	平台文件/快照/挂载能力	Volume/Object Storage/快照自管
隔离补丁和底层运维	平台承担更多	团队自行承担
供应商可移植性	较低	较高
上线速度	快	慢
基础设施控制权	中	高

因此没有“Hosted 一定更安全”或“Self-hosted 一定更专业”的简单答案。

Hosted 更适合：

• 任务主要需要标准 Linux、Python/Node、常用 CLI；
• 文件和依赖可以在任务启动时注入；
• 不需要进入公司私网；
• 希望减少镜像、调度、回收和安全补丁运维；
• 能接受平台提供的网络和环境能力边界。

Self-hosted 更适合：

• Agent 必须访问私有网络、内网数据库或自建 MCP；
• 需要公司自定义镜像、系统包或合规基线；
• 需要 GPU、特殊硬件或长期常驻工具链；
• 环境必须与现有 Kubernetes、VM、IAM、SIEM、Secret Manager 接入；
• 对数据驻留和执行审计有更严格要求。

第一条硬边界：不要让多个不可信工作负载天然共享同一个文件世界

OpenAI 的 Self-hosted 文档明确提醒：共享同一环境的 Agent 能接触相同的文件、凭证和其他资源，因此应按用户或工作负载隔离。

这条原则比“容器还是 VM”更基础。

在多用户系统里，可以先按风险从低到高设计隔离粒度：

• per-task：每个任务一个短生命周期 Sandbox；
• per-chat / per-session：一段持续工作保持同一工作区；
• per-project：同一项目共享持久文件，但不同项目隔离；
• per-user：个人工作空间长期存在；
• shared worker：只有在文件、身份、Secret 和工具都能再次强隔离时才考虑。

如果一个 Agent 可以执行任意命令，那么 Unix 用户名、工作目录名称或 Prompt 中的“请不要访问”都不能替代真正的权限边界。

第二条硬边界：Secret 不应该成为 Agent 的“知识”

Secret 管理是 Agent Sandbox 最容易被低估的部分。

OpenAI 当前文档明确区分了“Sandbox 进程启动所需环境值”和“第三方长期凭证”。对于 Hosted Sandbox，官方建议使用 Vault 方式，让 Sandbox 代码看到占位值，由网络代理只在批准的目标请求上注入真实凭证；Self-hosted 则需要团队自己提供可信代理或服务端注入层。

核心原则可以压缩成一句话：

模型可以决定“我要调用哪个被允许的服务”，但不应该因此自动获得那个服务的长期明文凭证。

原因很直接：只要凭证作为普通环境变量进入执行环境，Agent 生成的代码通常就有机会读取它。Prompt Injection、恶意依赖、调试日志、错误堆栈或误写 Artifact 都可能把它带出去。

因此生产环境更推荐：

Agent → 请求意图 → Policy Gate → Secret/Network Broker → 目标服务

而不是：

Agent → 读取长期 API Key → 任意发请求

这也正好和 XBSTACK 已有的 AI Agent Policy Gate 形成上下游关系：Policy Gate 判断这次调用是否被授权，Sandbox/Secret Broker 决定即使模型想越界，底层是否真的给它凭证和网络路径。

第三条硬边界：网络不要默认“全开”

Hosted Sandbox 的一个重要生产能力，是把网络访问做成明确策略。OpenAI 当前支持 enabled、disabled 和 restricted 三种模式；restricted 模式按允许域名控制出站访问。

这给出了一个非常实用的默认值：

• 纯本地代码处理：网络关闭；
• 只访问固定 API：restricted + allowlist；
• 真正需要通用浏览/安装依赖：临时开启更宽权限，并缩短 Sandbox 生命周期。

Self-hosted 也应该实现同样的语义，只是执行手段可能是容器网络、NetworkPolicy、iptables/eBPF、出口代理或云防火墙。

尤其要警惕“安装依赖所以必须全网开放”这种偷懒设计。包管理器下载、业务 API、浏览器访问和内部服务访问，应该尽量拆成不同策略，而不是共享一张无限制出口网络。

第四条硬边界：把“工作区持久化”和“业务数据持久化”分开

很多 Agent 产品做着做着，会把 Sandbox 目录直接当数据库用。

短期看很方便：文件都在，下一轮继续读。长期问题是：

• Sandbox 被回收以后数据是否还在？
• Snapshot 能不能跨版本恢复？
• 哪些文件应该随环境销毁？
• 哪些 Artifact 应该长期保存？
• 谁能读历史工作区？
• 删除用户账号时，哪些副本必须跟着删除？

更稳妥的设计是把三类东西分开：

1. Ephemeral Workspace

临时 clone、解压目录、缓存、编译产物、可重建依赖。任务结束后可以删除。

2. Resumable Workspace

长任务需要继续工作的目录。可以通过 Snapshot、Volume 或受控持久目录恢复，但仍然属于“执行状态”。

3. Durable Business Data / Artifacts

最终文档、数据集、代码补丁、用户上传原件、正式报告等，应进入独立的对象存储、数据库、Git 或文档系统，具备权限、版本、备份和删除策略。

这能避免把“Sandbox 还活着”误当成“业务数据已经可靠保存”。

第五条硬边界：Artifact 离开 Sandbox 前仍要过一次出口检查

Sandbox 隔离主要控制“执行环境能碰什么”，并不自动保证 Agent 生成的结果安全。

如果 Agent 能读取私有资料，再生成一个 ZIP、CSV、PDF、Patch 或日志，那么最终 Artifact 可能包含：

• API Key 或 Token；
• 用户隐私数据；
• 环境配置和内部 URL；
• 不应该外发的源代码；
• Prompt Injection 留下的恶意脚本；
• 过大的中间文件或缓存。

因此 Artifact Export 最好也是一个显式动作：

Sandbox → Artifact Scanner / Policy → Durable Storage / User Download

至少检查文件类型、大小、路径、敏感信息和来源。高风险场景还应记录 hash、生成任务、用户、时间和审批人。

Sandbox 和 Policy Gate 不是同一个东西

这两个概念很容易被混在一起。

Policy Gate 回答：当前用户、当前任务、当前参数，是否允许调用这个工具？

Sandbox 回答：即使工具被调用、代码开始执行，它实际能够访问哪些计算、文件、网络和凭证？

Human-in-the-loop 回答：哪些高风险动作必须由人再次确认？

Audit 回答：最后谁、在什么上下文、通过什么 Agent，做了什么？

生产系统通常需要把四层同时存在，而不是选四选一。

选择 Hosted 还是 Self-hosted：一个更实用的决策树

1. 是否需要访问私有网络或内部系统？

需要：优先评估 Self-hosted，或者确认 Hosted 平台是否有真正符合要求的私网连接方案。

不需要：继续。

2. 是否需要特殊镜像、内核能力、GPU 或系统级工具？

需要：Self-hosted 通常更合适。

不需要：继续。

3. 团队是否愿意自己承担环境补丁、调度、回收、隔离和容量管理？

不愿意：Hosted 更有优势。

愿意，而且基础设施已经标准化：Self-hosted 的控制价值会上升。

4. Secret 能否通过 Vault / Broker / Function Tool 留在 Sandbox 外？

无论 Hosted 还是 Self-hosted，如果答案是“不行，只能把长期生产 Key 全部塞进环境变量”，架构都应该先停下来重新设计。

5. 任务状态必须跨小时/跨天恢复吗？

如果需要，必须额外设计 Snapshot/Volume/Artifact Store，而不是默认依赖某个运行中的容器永远不死。

OpenAI Hosted / Self-hosted 当前能说明什么

截至 2026 年 9 月，OpenAI 官方文档已经把两条路线的责任边界写得很清楚。

OpenAI-hosted Sandbox 提供 Linux 工作区、Python/Node/CLI、文件、环境配置和网络策略；当你需要自己的镜像、计算资源或私有网络时，官方直接建议考虑 Self-hosted。

Self-hosted 模式下，Agent harness 仍由 OpenAI 运行，而 executor 在你的环境里运行，可以是 laptop、container 或 remote sandbox。连接是由 executor 向外建立，官方同时建议把应用级 API Key 留在 Sandbox 外，只把受限的环境连接凭证交给 executor。

这里最值得迁移到其他平台的，不是某个 API 名称，而是这套责任划分：

• 托管平台管理什么；
• 你的基础设施管理什么；
• Agent 代码实际能读到什么；
• 哪些凭证永远不进入工作区；
• 网络和文件权限由谁强制。

Anthropic 的实现给了另一个重要信号：减少审批不等于放松边界

Anthropic 的 Claude Code Sandbox 重点强调文件系统隔离和网络隔离。它想解决的一个现实问题是：如果每条 Shell 命令都让用户点击“允许”，很容易出现审批疲劳。

更合理的模式是先建立可验证边界，再允许 Agent 在边界内更自主地工作。

这意味着 Sandbox 的价值不仅是“出事时挡住攻击”，还包括：

把大量细碎的人类审批，转换成少量、稳定、机器可执行的环境策略。

这对 Coding Agent、数据分析 Agent、Research Agent 和后台自动化都成立。

生产环境最低 Checklist

隔离

• 是否按用户、项目或工作负载定义了明确的 Sandbox 隔离粒度？
• 一个租户是否可能读取另一个租户的文件、缓存或凭证？
• Agent 是否能访问宿主机 Home、SSH Key、浏览器 Cookie、云 CLI 配置？

文件

• 默认可写目录是否最小化？
• 上传文件是否只挂载到当前任务需要的位置？
• 临时文件、快照和最终 Artifact 是否有不同生命周期？

Secret

• 长期第三方凭证是否尽量留在 Sandbox 外？
• 是否使用 Secret Manager、Vault、Broker 或服务端 Function Tool？
• Sandbox 内使用的凭证是否短期、最小权限、可撤销？

网络

• 不需要联网的任务是否默认断网？
• 固定 API 是否使用域名/IP allowlist？
• 是否阻止访问云 Metadata、内网管理接口和不必要的内部服务？

执行

• 是否限制 CPU、内存、磁盘、进程数和最大运行时间？
• 安装系统包、启动服务、开放端口是否需要更高权限？
• 高风险命令是否需要 Policy Gate 或人工确认？

持久化

• Sandbox 销毁后，哪些状态必须能恢复？
• 最终业务数据是否已经离开临时文件系统？
• Snapshot、Volume、Artifact 的删除和保留规则是否清楚？

审计

• 能否追踪用户 → Agent → Tool → Sandbox → Artifact 的完整链路？
• 是否记录了权限决策，而不仅是模型文本？
• 出现泄露或误操作后能否撤销 Secret、隔离环境并定位影响范围？

最后怎么选

如果团队现在只是想让 Agent 安全地执行 Python、Node、Shell、处理上传文件并返回 Artifact，Hosted Sandbox 通常是更快的起点。

如果 Agent 必须深入私有基础设施、定制系统镜像、使用特殊硬件，或者公司已经有成熟的 Kubernetes/VM/IAM/Secret/Audit 平台，Self-hosted 往往更符合长期控制需求。

但无论选择哪条路线，真正决定生产安全性的不是“Sandbox 是谁家的”，而是有没有把下面四件事做成机器强制边界：

文件最小权限、Secret 外置、网络最小开放、持久化与执行状态分离。

这四项做好以后，模型、Agent Framework 和具体 Sandbox Provider 都可以继续替换；这也是为什么这个问题比某个 SDK 版本或某个 Sandbox Bug 更值得长期维护。

相关内容

• AI Agent 工具授权怎么做？Policy Gate、HITL 与逐调用权限控制
• AI Agent Security：生产环境中的权限、提示词注入与工具风险
• OpenAI Agents API vs Agents SDK vs Responses API
• OpenClaw 安全沙箱架构

参考资料

• OpenAI: Sandbox Agents
• OpenAI: OpenAI-hosted sandboxes
• OpenAI: Self-hosted sandboxes
• OpenAI: Sandbox security
• Anthropic: Making Claude Code more secure and autonomous with sandboxing

专题入口 / AI Agent Hub

从单个 Agent 问题继续进入完整生产体系

AI Agent 专题统一组织架构、记忆、工具调用、评测、安全、部署和多智能体协作，让每篇文章都回到明确的主题主页面。

进入 AI Agent 专题 → 查看架构指南 订阅