AI 编码代理不只是生成代码。它们往往还要克隆仓库、安装依赖、运行测试，甚至执行项目里的脚本。真正棘手的问题因此从“模型能否写代码”转向“这些代码应该在哪里运行”。Docker Cloud Sandboxes 提供由 Docker 托管的执行环境，并以硬件强制的 microVM 隔离承载工作负载，同时通过一致的环境抽象和统一 CLI 工作流，降低任务在开发者笔记本与云端之间迁移的成本。
统一的关键不是机器，而是执行契约
本地容器与云端 microVM 并不等价：它们在启动时间、网络拓扑、CPU 架构、存储持久性和可用凭据上都可能不同。所谓一致的 Sandbox 抽象，更适合被理解为一份稳定的执行契约：
- 使用同一个镜像或同一套构建定义；
- 明确工作目录、入口命令和输入输出位置；
- 显式声明网络、环境变量与资源需求；
- 不依赖开发者电脑中未写入配置的工具；
- 通过统一 CLI 启动、停止和查看任务，而不是为本地与云端维护两套脚本。
这对 AI 编码代理尤其重要。代理生成的命令具有动态性，仓库里的安装脚本也未必可信。如果任务直接在宿主机执行，一条错误的清理命令、带副作用的构建脚本或被提示注入诱导的网络请求，都可能影响开发者环境。将执行过程放入隔离 Sandbox，可以缩小故障与攻击的影响范围。
不过，一致环境不代表结果必然一致。没有锁定依赖版本、基础镜像标签和 CPU 架构时，同一任务仍可能在不同时间得到不同结果。Sandbox 解决的是执行边界和环境交付问题，不能代替可复现构建。
microVM 隔离解决了什么，又没有解决什么
Docker Cloud Sandboxes 的核心安全特征是硬件强制的 microVM 隔离。相较于让代理直接操作宿主机，独立虚拟化边界更适合承载来源复杂、行为难以完全预测的任务，例如：
- 编译第三方提交或陌生仓库；
- 执行代理自动生成的 shell 命令；
- 安装未经人工审查的依赖；
- 并行运行多个代理任务；
- 将长时间构建从笔记本迁移到托管基础设施。
但 microVM 不是万能保险箱。以下风险仍需在平台和任务配置层处理：
- 凭据泄露：如果把长期云密钥直接注入 Sandbox，隔离并不能阻止任务读取并外传它。
- 网络滥用：代理可能下载恶意依赖、访问内部服务，或把源码发送到外部地址。
- 供应链问题：基础镜像和依赖包本身仍需要锁定、扫描与更新。
- 持久化数据污染：复用工作目录或缓存时，上一个任务留下的文件可能影响下一个任务。
- 资源耗尽：递归构建、fork bomb 或异常测试仍可能消耗大量 CPU、内存和时间。
更稳妥的策略是把 Sandbox 当作零信任执行单元：默认不给网络和凭据，按任务临时开放；使用短期令牌；限制资源和运行时间；任务结束后销毁环境，并把日志、产物和审计记录单独保存。
可以这样实践：先建立可迁移的本地基线
下面的示例不假设 Docker Cloud Sandboxes 的具体 CLI 语法，因为来源摘要没有给出命令细节。它先用标准 Docker 命令建立一个可复制的本地执行基线；接入云端时，可以保留镜像、入口命令和挂载约定，只把最后的启动命令替换为实际安装版本提供的统一 CLI。
在安装了 Docker 的 Linux、macOS 或 WSL 环境中运行：
mkdir -p sandbox-demo/project
cd sandbox-demo
cat > Dockerfile <<'EOF'
FROM python:3.12-alpine
WORKDIR /workspace
COPY agent_task.py /opt/agent_task.py
ENTRYPOINT ["python", "/opt/agent_task.py"]
EOF
cat > agent_task.py <<'EOF'
from pathlib import Path
root = Path("/workspace")
python_files = sorted(root.rglob("*.py"))
report = ["# Sandbox report", "", f"Python files: {len(python_files)}", ""]
report.extend(f"- {path.relative_to(root)}" for path in python_files)
(root / "GENERATED.md").write_text("\n".join(report) + "\n", encoding="utf-8")
print("Wrote /workspace/GENERATED.md")
EOF
cat > project/main.py <<'EOF'
print("hello from a sandboxed workspace")
EOF
docker build -t agent-sandbox-demo:local .
docker run --rm \
--network none \
--read-only \
--cap-drop ALL \
--security-opt no-new-privileges \
--user "$(id -u):$(id -g)" \
--mount "type=bind,src=$PWD/project,dst=/workspace" \
--tmpfs /tmp:rw,noexec,nosuid,size=64m \
agent-sandbox-demo:local
cat project/GENERATED.md
这个例子刻意做了几项约束：
- 根文件系统只读，代理只能修改显式挂载的工作目录；
- 默认关闭网络，避免任务任意下载或上传数据；
- 删除 Linux capabilities，并禁止进程获取额外权限；
- 使用当前用户 UID/GID，减少生成 root 所有文件的问题；
/tmp使用有容量限制的临时文件系统。
真实编码代理通常需要联网安装依赖。不要简单地永久移除 --network none，更合适的做法是将流程拆成两个阶段：先在受控网络环境下载并缓存经过锁定的依赖，再让代理在无网络或受限网络的执行阶段修改代码和运行测试。
把同一个工作负载送到云端
要减少本地与云端偏差，可以把 OCI 镜像作为交付单元。以下命令展示了标准的构建与推送过程；请将镜像地址替换为自己的仓库：
export IMAGE=ghcr.io/your-org/agent-sandbox-demo:2025-01
docker login ghcr.io
docker buildx build \
--platform linux/amd64 \
--tag "$IMAGE" \
--push \
.
云端执行时，需要根据实际 Docker Cloud Sandboxes CLI 的版本和文档，把以下占位命令替换为真实语法：
# 示例接口，仅表示迁移方式，不是已确认的官方命令：
<cloud-sandbox-cli> run \
--image "$IMAGE" \
--workspace ./project \
--network disabled
迁移时真正需要保持稳定的是三件事：镜像中的工具链、/workspace 输入输出约定，以及网络和密钥策略。不要把“统一 CLI”误解为可以忽略底层差异；例如，本地机器可能是 ARM64，而云端目标是 AMD64，因此构建时应明确 --platform，或发布多架构镜像。
对于频繁执行的代理任务，还可以给每次运行分配独立标识，并把产物与日志放在运行目录中：
RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "runs/$RUN_ID"
cp -R project "runs/$RUN_ID/workspace"
printf '%s\n' "$IMAGE" > "runs/$RUN_ID/image.txt"
这比反复复用同一个可写目录更容易审计，也有助于复现代理为何生成某次修改。
采用前应确认的清单
Docker Cloud Sandboxes 适合需要运行 AI 编码代理、执行不完全可信代码，或希望把计算从笔记本弹性迁往托管基础设施的团队。落地前建议确认：
- 镜像是否使用不可变标签或 digest，依赖是否有锁文件；
- Sandbox 默认是否禁止访问内部网络和云元数据服务；
- 凭据是否按任务签发、权限最小且能快速过期；
- 源码、提示词、日志和构建产物分别保留多久；
- CPU、内存、磁盘、网络流量和最长运行时间是否有限额；
- 本地与云端是否使用相同架构，或者镜像是否支持多架构；
- 任务失败后能否保留足够的日志，同时销毁可写执行环境；
- 团队是否记录了从本地命令切换到云端 CLI 的明确规则。
这类平台最有价值的地方，不是简单地“把容器放到云上”，而是把 AI 代理的执行环境变成可描述、可隔离、可迁移和可审计的工程对象。先建立严格的本地执行契约，再迁移到托管 microVM，通常比直接把现有开发脚本原样搬进云端更可靠。