把 AI 编码代理装进安全沙箱：Docker 打通本地与云端执行环境

预计阅读时间：8 分钟

AI 编码代理不只是生成代码。它们还会读取仓库、安装依赖、执行测试，甚至运行来源不明的构建脚本。Docker Cloud Sandboxes 针对的正是这个执行层问题：在 Docker 管理的基础设施上提供托管沙箱，使用硬件强制的 microVM 隔离，同时让开发者通过一致的环境和统一的 CLI 工作流，在笔记本与云端之间迁移任务。

一致性比“能跑起来”更重要

开发者在本地使用容器，到了云端却改用另一套镜像、目录结构和启动脚本，很容易产生环境漂移。对 AI 代理来说，这类差异尤其麻烦：代理可能在本地成功安装依赖，却在远端因为 Python 版本、系统包或文件权限不同而失败。

更稳妥的做法，是把执行契约固定下来：

用镜像声明运行时和系统依赖；
约定统一的工作目录，例如 /workspace；
把测试、构建和检查命令写进仓库；
明确网络、CPU、内存和文件写入权限；
不把宿主机上的隐式状态当成依赖。

Docker Cloud Sandboxes 的价值不只是“把容器放到云里”，而是让本地和托管环境共享同一套执行模型。源码仍然可以来自本地仓库，但高风险、长时间或高资源消耗的操作可以转移到隔离的云端环境。

microVM 隔离解决了哪一层风险

普通容器主要依赖操作系统级隔离，而 Docker Cloud Sandboxes 使用硬件强制的 microVM 边界。对于会主动执行命令的 AI 代理，这提高了不同任务以及任务与宿主基础设施之间的隔离强度。

不过，microVM 并不等于“可以取消所有安全策略”。它不能自动解决以下问题：

代理读取了不该接触的 API 密钥；
恶意依赖通过网络外传源码；
提示注入诱导代理执行危险命令；
云账号授予了过大的基础设施权限；
日志、缓存或构建产物泄露敏感数据。

因此，沙箱边界之外仍要落实最小权限：默认关闭不必要的网络访问，按任务注入短期凭据，限制资源，并在任务结束后销毁环境。对于生成的补丁，也应在合并前执行测试、静态检查和人工审查。

用一个可迁移的执行契约开始

下面的示例不依赖特定的 Cloud Sandboxes CLI 版本，而是先建立一个可以直接在本地运行、也便于迁移到托管沙箱的最小项目。运行前需要安装 Docker。

mkdir -p sandbox-demo/tests
cd sandbox-demo

cat > app.py <<'PY'
def add(a: int, b: int) -> int:
    return a + b
PY

cat > tests/test_app.py <<'PY'
import unittest
from app import add


class AddTest(unittest.TestCase):
    def test_add(self):
        self.assertEqual(add(2, 3), 5)


if __name__ == "__main__":
    unittest.main()
PY

cat > Dockerfile <<'DOCKERFILE'
FROM python:3.12-slim

WORKDIR /workspace
ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1

COPY . .
CMD ["python", "-m", "unittest", "discover", "-s", "tests", "-v"]
DOCKERFILE

docker build -t sandbox-demo:local .
docker run --rm \
  --network none \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 512m \
  --cpus 1 \
  sandbox-demo:local

这段命令建立了几个值得保留的默认值：测试不需要联网，因此禁用网络；根文件系统只读；临时文件只能写入受限的 /tmp；Linux capabilities 被移除；CPU 和内存也有明确上限。

真正的编码代理通常需要修改工作区。可以为单次任务创建一次性副本，而不是直接挂载主仓库：

cd ..
rm -rf sandbox-worktree
cp -R sandbox-demo sandbox-worktree

docker run --rm \
  --network none \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 1g \
  --cpus 2 \
  -v "$(pwd)/sandbox-worktree:/workspace" \
  -w /workspace \
  python:3.12-slim \
  python -m unittest discover -s tests -v

这里的目录仍然可被容器修改，所以它适合演示工作区模型，而不是完整的敌对代码防护。迁移到 Docker Cloud Sandboxes 时，应使用当前产品版本提供的官方 CLI 创建托管沙箱，并把同一仓库、镜像或启动命令交给云端执行。由于来源摘要没有给出具体 CLI 参数，不应假设某个未经确认的命令格式。

把代理输入也纳入版本控制

环境一致还不够，任务说明也要可复现。可以在仓库中加入一份代理任务文件：

# agent-task.yaml
name: fix-and-test
workspace: /workspace
instructions: |
  修复失败的单元测试。
  不要修改公开 API。
  完成后运行：python -m unittest discover -s tests -v
policy:
  network: disabled
  max_runtime_minutes: 15
  secrets: []
artifacts:
  - patch.diff
  - test-results.txt

这是一个实践用的项目约定，并非 Docker Cloud Sandboxes 的官方配置格式。它的作用是把指令、验证命令和权限要求放在同一个可审查文件里。接入实际平台时，可以由适配脚本读取这些字段，再转换为官方 CLI 参数或 API 请求。

上云前的检查清单

采用托管沙箱时，可以从低风险任务逐步推进：

先迁移测试、lint 和依赖分析，不要一开始就授予生产权限。
固定基础镜像版本，避免本地与云端拉取到不同运行时。
默认禁用出站网络，仅为包仓库或内部服务建立允许列表。
使用短期、任务级凭据，不要把长期密钥写入镜像或仓库。
限制 CPU、内存、运行时间和产物大小，防止失控任务持续消耗资源。
保存命令、镜像摘要、代码提交和测试结果，形成可审计记录。
将沙箱视为隔离层，而不是代码审查、供应链扫描和权限治理的替代品。

Docker Cloud Sandboxes 最值得关注的地方，是把“代理在哪里执行”从临时脚本提升为稳定的工程抽象。本地容器适合快速反馈，云端 microVM 沙箱适合隔离高风险或高并发任务；当两边共享相同的运行契约时，团队才能在不牺牲可复现性的前提下扩展 AI 编码工作流。