跳转到内容
全部开发指南

AI Agent 执行代码怎么避免伤到本机？用 OpenSandbox 搭一个 Docker 沙箱

AIGoCode发布于 更新于

AI Agent 执行代码怎么避免伤到本机？用 OpenSandbox 搭一个 Docker 沙箱 封面

AI Agent 现在越来越敢动手了：它会自己写一段脚本跑起来，会执行你没仔细看的命令，会打开浏览器点来点去。方便是真方便，但它跑的这些东西，其实没法百分百信任。可能是模型幻觉写出的危险命令，也可能是网页里藏了一段注入指令，把它带偏了。这些操作如果直接落在自己的机器上，出了事就是真出事。

OpenSandbox 是一个开源的 AI 沙箱平台，要解决的就是这个问题：给 Agent 一个隔离的环境去执行代码、运行命令、管理文件，甚至操作浏览器和桌面，跑坏了也碰不到宿主机。本地可以用 Docker 起步，规模大了可以部署到 Kubernetes，两种方式用同一套沙箱 API。

截至 2026 年 11 月，OpenSandbox 的 GitHub 仓库 star 数超过 1.6 万，代码协议是 Apache-2.0。这篇文章讲它解决什么问题、隔离有哪几档、怎么在本地跑起来，以及接入 Claude Code 这类编程 Agent 时要注意什么。

OpenSandbox 的来历

项目最初由阿里开源，仓库原来在 alibaba 组织下，现在的官方仓库是 opensandbox-group/OpenSandbox，旧地址会自动跳转。官方 README 页首把它标注为 Agentic AI Foundation（AAIF）的项目。Java、npm、NuGet 等 SDK 的包名里仍然保留着 alibaba 的字样，这是正常的，不是装错了包。

OpenSandbox 原文配图 1

它解决的是什么问题

一句话：给 AI 的动手能力套一个安全边界。

Agent 去处理数据、写脚本、跑测试，真正执行的时候，本质上是在某台机器上敲命令、读写文件、访问网络。如果这台机器就是你自己的电脑，等于把钥匙交了出去。沙箱的做法是给它一个一次性的、隔离的房间：创建、在里面执行、用完销毁，外面不受影响。

对个人用户，这是一份省心；对做 Agent 平台的团队，则更接近刚需，总不能让大量用户的 Agent 都在同一台服务器上直接运行。

OpenSandbox 原文配图 2

隔离有哪几档

默认的本地方案是 Docker 容器，这是基础档。官方配置文档里有一个 [secure_runtime] 配置段，对应更强的安全容器方案，支持 gVisor、Kata Containers 和 Firecracker，在容器和宿主机之间再加一层隔离。

有一个细节值得注意。官方的网络出站文档写明，每个沙箱的出站策略和后面要讲的凭证保险库，依赖 iptables 或 nftables 的能力，而 gVisor 不支持这些能力，文档给出的建议是在这种场景下改用 Kata，它的隔离强度相近，且支持完整的出站控制。所以选隔离方案时，不能只看“越强越好”，要同时看你需要哪些网络功能。

在 Kubernetes 上，README 还提到一个 Fast Sandbox 运行时：基于 Firecracker 的沙箱创建时间是 64 毫秒（P50，串行）和 125.4 毫秒（P99，10 个并发），并且支持保留内存和磁盘状态的暂停与恢复。这是官方给出的数字，具体表现取决于你的集群。

网络和凭证

除了进程隔离，OpenSandbox 还管网络：

  • 入口：通过统一的入口网关路由流量。
  • 出口：可以给每个沙箱单独设置出站策略，限制它能连哪些地址。
  • 凭证保险库（Credential Vault）：真实的密钥由宿主侧的 SDK 写入出站代理（sidecar），沙箱里的进程拿到的只是假值或空值。沙箱向允许的地址发起 HTTPS 请求时，代理再把认证头加上去。这样即使沙箱里的代码被注入指令带偏，也很难直接拿到真实密钥。

凭证保险库有一些前置条件，官方文档列得很清楚，包括：服务端出站模式要设为 dns+nft；创建沙箱时要带上出站网络策略，并建议默认拒绝（defaultAction="deny"），再逐个放行需要的主机；沙箱所在的 Pod 里不能再有额外的服务网格 sidecar（例如 Istio 注入）。这几项没满足，功能就不能安全启用。

这类“沙箱不是完整安全边界”的话题，之前在 AI 编程工具的沙箱不是完整安全边界，从 Codex 漏洞看防护 里讲过，建议结合着看。

在本地跑一个

前置条件是 Docker（本地执行必需）和 Python 3.10 或更高版本。

先用 uvx 生成配置并启动沙箱服务：

uvx opensandbox-server init-config ~/.sandbox.toml --example docker
uvx opensandbox-server

再安装 Python SDK：

uv pip install opensandbox

下面是 README 里的最小例子，用 alpine 镜像创建一个沙箱，在里面执行一条命令，最后销毁：

import asyncio

from opensandbox import Sandbox


async def main() -> None:
    sandbox = await Sandbox.create("alpine")

    try:
        execution = await sandbox.commands.run("echo 'Hello OpenSandbox!'")
        print(execution.logs.stdout[0].text)
    finally:
        await sandbox.destroy()


if __name__ == "__main__":
    asyncio.run(main())

同一份 README 里还有写文件、读文件、再执行脚本的完整示例，可以在这个基础上扩展。

生产环境要设 API Key。 官方配置文档写明：只有设置了 server.api_key，服务端才会校验请求头 OPEN-SANDBOX-API-KEY；留空时服务端不做任何认证。在 Docker、Kubernetes、CI 这类非交互环境里，还需要设置 OPENSANDBOX_INSECURE_SERVER=YES 来确认你知道这个风险。文档的原话是生产环境一定要设置。

怎么接入你的 Agent

OpenSandbox 不挑语言，也不挑 Agent 框架：

  • SDK：Python、Java/Kotlin、TypeScript/JavaScript、C#/.NET、Go。
  • 命令行 osb：用 pip install opensandbox-cli 或 uv tool install opensandbox-cli 安装，可以在终端里创建沙箱、运行命令、传文件、看诊断、管理出站策略。
  • MCP 服务：pip install opensandbox-mcp 后运行 opensandbox-mcp --domain localhost:8080 --protocol http，可以让 Claude Code、Cursor 这类支持 MCP 的客户端具备在沙箱里执行代码的能力。README 里给出的最小 stdio 配置如下：
{
  "mcpServers": {
    "opensandbox": {
      "command": "opensandbox-mcp",
      "args": ["--domain", "localhost:8080", "--protocol", "http"]
    }
  }
}

官方示例目录按用途分了几类：编码 Agent（Claude Code、Codex CLI、DeerFlow）、代码执行与数据分析（Code Interpreter）、浏览器与桌面自动化（Playwright、Chrome、Desktop）、Agent 评测（Harbor）。更多框架集成和 Kubernetes 部署的例子在完整示例目录里。

在沙箱里跑 Claude Code

官方的 Claude Code 示例是这样做的：用 code-interpreter 镜像（里面带 Node.js）起一个沙箱，在里面用 npm 装 Claude Code，再发一条简单请求。认证通过 ANTHROPIC_AUTH_TOKEN 传入，接口地址和模型名可以用 ANTHROPIC_BASE_URL 和 ANTHROPIC_MODEL 覆盖。如果你想了解 Claude Code 接入第三方 Base URL 的通用步骤，可以看 AIGoCode 使用指南。

示例文档还特别提到了无人值守运行的权限问题。非交互的 -p 模式下没有终端回答权限提示，需要工具的任务可能会失败，常见的处理有两种：

  1. --dangerously-skip-permissions：不弹提示直接执行工具。文档的说法是，在一次性的 OpenSandbox 容器里这是常见选择，因为沙箱本身就是隔离边界。
  2. --permission-mode dontAsk：只运行你用权限规则预先批准的工具，更保守，是锁定的 CI 里的标准做法。

要注意第一种只适合“沙箱真的是边界”的前提，上面讲的出站限制和凭证保护就是为这个前提服务的。

适合谁，有哪些限制

OpenSandbox 偏底层，是一个基础设施项目，不是拿来即用的小工具。

  • 适合：做 Coding Agent、GUI Agent、Agent 评测、强化学习训练的团队，以及需要把模型生成的代码放进隔离环境执行的平台。
  • 个人用户：偶尔让 AI 跑跑脚本，感受可能没那么强。但只要你开始担心 AI 在本机执行代码的安全，它是一个正经的选择。
  • 限制：本地 Docker 的隔离强度是基础档，更强的隔离要自己配置安全运行时，并留意各功能与运行时的兼容关系。
  • 限制：凭证保险库、出站策略都有前置条件，不是装上就自动生效。

如果你已经在 AIGoCode 上接入了 Claude Code 或 Codex，可以先按上面的步骤在本地起一个 Docker 沙箱，把 Agent 的代码执行放进去试一轮，再决定要不要上更强的隔离方案。

参考链接

AI Agent 执行代码怎么避免伤到本机？用 OpenSandbox 搭一个 Docker 沙箱