当向人工智能代理授予对隔离环境（Sandbox）的访问权限时，会出现一个核心问题：如何组织代理将要操作的文件。Docker Sandbox 平台（简称 sbx）提供了三种主要的源代码管理模型，每种模型都对开发人员的工作流程和与代理的交互产生直接影响。
1. 直接挂载（Shared Mounts）
此选项允许直接与隔离环境共享自主机当前的工作路径。从项目文件夹运行 sbx run 时，该文件夹会被挂载到环境内的相同绝对路径。此模型非常适合单任务中的紧密协作，因为开发人员可以在其本地编辑器中立即看到更改，并且本地开发服务器可以通过热重载（Hot Reload）功能捕获修改。
警告：必须注意依赖项冲突；包含原生二进制文件（Native Binaries）的包可能在隔离的 Linux 环境中运行而在 macOS 或 Windows 系统上失败，因此建议统一运行环境或分离依赖项安装。
2. 使用 Git 工作树（Git Worktrees）
此选项适用于同时执行多个任务。它为每个任务赋予其自己的文件夹和分支，从而允许将每个工作树挂载到单独的隔离环境中。这里的优势是任务完全隔离，但仍存在一个技术限制：.git 文件指向挂载范围之外的元数据，这意味着诸如检查状态（git status）或切换分支等操作必须从主机完成。
3. 克隆模式（Clone Mode）
在此模式下，sbx 工具在隔离环境中创建代码的独立副本，并将主机代码挂载为只读。这赋予了代理对环境中 Git 的完全访问权限，使其在管理分支和提交（Commits）时完全独立。工作结束后，开发人员可以通过远程 Git 仓库（Remote）拉取更改。
这如何改变开发人员的工作流程？
选择合适的方法取决于任务的性质和您直接干预的意愿：
- 紧密协作：如果您想实时监控代理的工作，请使用直接挂载。
- 独立性：如果您想为代理提供管理任务的空间而不影响本地工作环境，请使用克隆模式或完全隔离的环境（Mountless）。
- 多项目管理：可以使用工作区管理器（Workspace Managers）将多个仓库聚合到一个环境中，从而方便代理处理相互关联的项目（例如前端和后端）。
请记住，不依赖主机文件挂载的隔离环境（Mountless）需要手动管理端口（Ports）以便从本地浏览器访问开发服务器，这是一种增强隔离安全性的做法，但会增加一些额外的设置步骤。