摘要：Dagger 团队发布了一个名为 Container Use 的开源工具，旨在通过为每个基于 AI 的编码代理提供自己的容器化沙箱和 Git 工作树来简化操作，实现无冲突的并行工作流。得益于 Container Use 管理的隔离开发环境，开发者不再需要手动处

Dagger 团队发布了一个名为 Container Use 的开源工具，旨在通过为每个基于 AI 的编码代理提供自己的容器化沙箱和 Git 工作树来简化操作，实现无冲突的并行工作流。得益于 Container Use 管理的隔离开发环境，开发者不再需要手动处理克隆或 git stash，可以在同一代码库上安全地运行多个代理而不会相互干扰。

例如，在 Zed 编辑器中 激活 Container Use 时，它会使用轻量级容器（通过 Dagger）和 Git 工作树自动创建新的代理环境。每个环境独立运行，但开发者可以轻松使用 container-use list、watch、log 或 diff 等命令切换上下文。这些容器支持交互式调试、服务隧道和终端访问，允许对每个代理任务进行全面控制。

使用 Zed 编辑器时，用户可以启用一个专用的“后台”配置文件，Container Use 可以在其中管理代理任务而不影响交互式编辑会话。在需要时，开发者可以进入代理终端，查看命令历史记录，或直接干预，但又不影响其核心项目环境的稳定性。

根据 Dagger 团队的介绍，为了防止冲突，传统的代理工作流通常涉及复杂的目录结构或精细的分阶段处理，特别是在单体存储库或多代理设置中。Container Use 旨在通过将容器的隔离性与 Git 工作树的灵活性相结合来改进这一流程，提供实时可见性、简单干预点和开发者友好的界面。

需要注意的是，Container Use 尚处于早期开发阶段，因此存在一些已知的问题和需要进一步改进的地方。有一位用户在 GitHub 上提出了一个 请求，希望能够直接从终端执行 container-use 工具，这凸显了这个工具当前在可访问性和调试功能方面的不足：

“我发现，当调试工具失败的原因时，能够从终端调用相同的工具会很有用。”

有几个工具提供了类似的功能，通过在独立的容器或沙箱中运行 AI 生成的代码来确保安全和并行执行：

SandboxAI 是一个开源运行时，用于在基于 Docker 的隔离沙箱中执行 AI 生成的 Python 代码和 shell 命令。它通过 Docker 来支持本地执行，并计划支持 Kubernetes。SandboxAI 与 AI 代理框架（如 CrewAI）集成，实现了安全、可扩展的代理工作流。

Modal Sandboxes 提供了一个可扩展的无服务器环境，开发者可以在其中用一行 Python 代码定义沙箱会话。这些沙箱在 Modal 的容器基础架构上启动，支持基于 gVisor 的隔离，为 AI 代码执行提供快速、安全和自动扩展的理想基础设施。

E2B 是一个为 AI 代理量身定制的开源运行时，支持沙箱快速启动（不到 200 毫秒）、多语言执行（Python、JavaScript、Ruby、C++）及使用 Firecracker microVM 增强安全性。对于需要完整控制权的企业，它还提供了自托管选项。

Code Sandbox MCP 提供了一个轻量级的 MCP 服务器，用于在容器内运行 AI 代理的代码片段。它支持在本地执行 Python 和 JavaScript 代码，实现了基于工具的代理集成，并保持了代码隐私和隔离。

Uzi 也同样值得注意。这是一个 CLI 工具，它使用 tmux 为每个代理编排隔离的 Git 工作树，从而并行运行多个 AI 编码代理。虽然不是基于容器，但它基于工作树的隔离有助于防止单体存储库环境中代理工作流之间的相互干扰。

这些工具突出了一个日益增长的趋势：通过容器化、虚拟化或文件系统工作树隔离 AI 代理任务来增强安全性、可扩展性和开发者控制权。无论是使用 Docker、无服务器沙箱、microVM 还是 Git 隔离，这些框架都使开发者能够利用自主 AI 工具，而又不会损害其代码库或环境的完整性。

原文链接：

声明：本文为 InfoQ 翻译，未经许可禁止转载。

今日好文推荐

来源：极客邦科技