OpenSandbox 沙箱运行时：为什么我拿它跑 GitHub Copilot 和 Agent Framework

当 AI Agent 不再只是回答问题，而是开始执行命令、修改文件、安装工具时，一个更现实的问题就会冒出来：这些操作到底应该发生在哪里？

我围绕 GitHub Copilot CLI 和 Microsoft Agent Framework 做 OpenSandbox 示例，正是想把注意力从“Agent 能做什么”向前推一步：怎样给它一个可运行、可管理的工作环境。

OpenSandbox 是什么

OpenSandbox 是面向 AI Agent 的开源沙箱运行时。它让应用通过统一的 API 创建隔离环境，在其中执行代码和命令、管理文件，也能运行浏览器或桌面相关任务。

它并不替代模型或 Agent 框架。模型负责推理，框架负责组织任务；OpenSandbox 提供的是任务真正落地时所需的执行环境。开发者可以先用 Docker 在本地启动，再将工作负载部署到 Kubernetes；项目也提供多语言 SDK、CLI 和 MCP 接入方式。

这个分工很重要：让 Agent 拥有执行能力，不等于让它直接在宿主机上执行。

Sandbox 众多，我为什么选择 OpenSandbox

对我来说，选择沙箱不只是比较“能不能运行一条命令”，还要看它能否融入已有的 Agent 工作流。

OpenSandbox 提供沙箱生命周期、命令执行和文件操作接口，也有网络出入站控制、凭据管理等能力。这意味着示例可以围绕一个完整过程展开：创建环境 → 运行 Agent 工具 → 获取结果 → 清理环境，而不只是展示一次孤立的代码执行。

我提交的 GitHub Copilot CLI 示例，就是让 CLI 在 OpenSandbox 容器中以非交互方式运行，并在结束后清理沙箱。相关 PR 已于 2026 年 10 月合并。围绕 Microsoft Agent Framework 的示例工作，也让我从另一个角度思考：不同的 Agent 入口，能否复用同一套执行环境能力。

我期待的 OpenSandbox 生态

如果沙箱只服务于某一种 Agent，它很容易变成专用工具。OpenSandbox 更值得关注的方向，是让不同语言、框架和工具共享一套执行接口。

项目已有 Python、JavaScript/TypeScript、C#/.NET、Go 等 SDK，并提供 CLI 与 MCP 接入。结合编码 Agent、浏览器自动化和评测等示例，我期待它逐步形成这样的生态：开发者可以选择熟悉的 Agent 框架，同时用一致的方式管理运行环境。

这是一种可能的发展方向，不是说所有场景现在都能无缝迁移。接口覆盖、部署体验，以及不同工作负载下的隔离效果，仍需要持续打磨。

对 AI Agent Infra 意味着什么

过去讨论 Agent Infra，我们常把重点放在模型接入、提示词和编排上。但 Agent 一旦开始行动，执行环境就会成为架构的一部分。

我认为至少要重新审视三个问题：

• 边界在哪里？ 命令、文件和网络访问应在什么环境中发生？
• 权限怎么给？ Agent 完成任务所需的能力，能否与宿主环境和真实凭据分开管理？
• 任务如何结束？ 工作环境能否创建、观察，并在任务完成后可靠清理？

OpenSandbox 不会替我们回答每个业务场景的安全问题，却提供了一个值得实践的起点：把 Agent 的“行动空间”作为独立的基础设施来设计，而不是默认继承应用进程或开发者电脑的权限。

这也是我做这两个示例最想传达的事。Agent 越能干，我们越需要认真设计它在哪里动手。

参考资料

• GitHub Copilot CLI 与 Microsoft Agent Framework 示例相关 PR
• OpenSandbox 项目仓库与功能说明