AI Agent 不再只是“生成一段文本”。它会读文件、调用 API、运行脚本、安装依赖，甚至修改仓库。能力越接近真实开发者，风险也越接近真实开发者：误删文件、泄露密钥、执行不可信代码、污染宿主环境。Docker Captain Karan Verma 讨论的核心问题正是这一点：AI 工作流需要隔离，而 Docker SBX 和 Sandbox Kits 这类工具的价值，是把 Agent 的行动边界变成可执行的工程约束。
Agent 的风险来自“能动性”
传统 LLM 请求通常是输入提示词、返回文本。Agent 不一样，它会根据目标拆步骤，并在循环中使用工具。比如：
- 读取项目目录，理解代码结构；
- 运行测试或构建命令；
- 通过包管理器安装依赖；
- 调用外部服务；
- 生成、编辑、删除文件。
这些动作在开发机上看起来很自然，但对自动化系统来说，每一步都可能越界。一个错误的 shell 命令可能把工作区清空；一个被投毒的依赖安装脚本可能读取环境变量；一个提示注入可能诱导 Agent 把 .env 上传到外部端点。
所以隔离不是“安全团队的额外要求”，而是 Agent 基础设施的一部分。没有隔离，Agent 的权限通常等于运行它的用户权限；有了隔离，权限可以被压到任务所需的最小范围。
Docker SBX 解决的是执行边界
从摘要看，Docker SBX 被用于支持更安全的 AI 工作流。可以把它理解为围绕沙盒执行环境的一类能力：让 Agent 的代码执行、依赖安装、文件修改发生在受控空间中，而不是直接落到开发者机器或生产环境里。
工程上要关注三个边界：
- 文件系统边界：Agent 能看到哪些目录？能写哪些目录？
- 网络边界：Agent 是否能访问公网、内网、元数据服务或私有 API？
- 进程边界：Agent 能否启动长期进程、消耗大量 CPU/内存、调用宿主 Docker socket？
Docker 的优势在于这些边界已经是容器模型的一部分。即使不依赖某个特定产品 API，也可以用容器实践最小权限：只挂载必要目录、限制资源、去掉危险 capability、使用只读根文件系统、避免传入宿主密钥。
可以这样实践：给 Agent 一个一次性工作箱
下面是一个可以直接改造的最小示例。假设你要让某个 Agent 或脚本在当前项目里运行测试，但不希望它写出项目目录之外，也不希望它继承你的所有环境变量。
创建一个 agent-sandbox.sh：
#!/usr/bin/env bash
set -euo pipefail
IMAGE="python:3.12-slim"
WORKDIR="/workspace"
# 改这里：把命令替换成你的 Agent 入口、测试命令或代码生成命令。
AGENT_COMMAND=${1:-"python -c 'import os; print(\"sandbox cwd:\", os.getcwd()); print(\"files:\", os.listdir())'"}
docker run --rm \
--name ai-agent-sandbox \
--cpus="2" \
--memory="2g" \
--pids-limit="256" \
--network="none" \
--read-only \
--tmpfs /tmp:rw,noexec,nosuid,size=256m \
--mount type=bind,src="$PWD",dst="$WORKDIR",rw \
--workdir "$WORKDIR" \
--cap-drop=ALL \
--security-opt no-new-privileges \
"$IMAGE" \
sh -lc "$AGENT_COMMAND"
运行：
chmod +x agent-sandbox.sh
./agent-sandbox.sh
./agent-sandbox.sh "python -m compileall ."
这个例子刻意做了几件事：
--network="none"：默认不让 Agent 访问网络，避免提示注入后外传数据；--read-only：容器根文件系统只读，临时写入只允许到/tmp；--mount ... rw：只把当前项目挂进去，写入范围清楚；--cap-drop=ALL和no-new-privileges：减少容器内进程提权空间；--cpus、--memory、--pids-limit：避免 Agent 失控消耗宿主资源。
如果 Agent 需要安装依赖，上面的 --read-only 可能会太严格。可以改成允许一个专门的缓存目录，而不是开放整个宿主环境：
mkdir -p .agent-cache/pip
docker run --rm \
--cpus="2" \
--memory="2g" \
--network="none" \
--mount type=bind,src="$PWD",dst=/workspace,rw \
--mount type=bind,src="$PWD/.agent-cache/pip",dst=/root/.cache/pip,rw \
--workdir /workspace \
--cap-drop=ALL \
--security-opt no-new-privileges \
python:3.12-slim \
sh -lc "python -m pip --version && python -m pytest"
注意：如果需要 pip install 从公网下载包，就不能使用 --network="none"。更稳妥的做法是在 CI 里预构建镜像，或使用内部包缓存，再把 Agent 运行阶段设为无网络。
Sandbox Kits 的意义：把隔离做成可复用工作流
单个 docker run 命令能说明原则，但团队落地时还需要标准化。摘要提到 Sandbox Kits，重点就在这里：把沙盒环境、权限配置、常见 Agent 任务封装成可复用套件，减少每个项目重复拼安全参数的成本。
可以这样设计一个简化版项目结构：
agent-workflow/
├── Dockerfile.agent
├── sandbox.policy.env
├── run-agent.sh
└── workspace/
Dockerfile.agent 示例：
FROM python:3.12-slim
RUN python -m pip install --no-cache-dir pytest
WORKDIR /workspace
USER nobody
run-agent.sh 示例：
#!/usr/bin/env bash
set -euo pipefail
docker build -f Dockerfile.agent -t local/agent-sandbox:latest .
docker run --rm \
--cpus="2" \
--memory="2g" \
--pids-limit="256" \
--network="none" \
--mount type=bind,src="$PWD/workspace",dst=/workspace,rw \
--workdir /workspace \
--cap-drop=ALL \
--security-opt no-new-privileges \
local/agent-sandbox:latest \
sh -lc "pytest -q"
这种封装的价值不是命令少了几行，而是团队可以审查一份沙盒策略，然后让不同 Agent 任务共享它。对平台团队来说，这也更容易接入日志、配额、镜像扫描和 CI 审批。
落地时别只看“能跑”
Agent 隔离会带来取舍。无网络环境更安全，但会让依赖安装、文档检索、API 调试变麻烦；只读文件系统能减少污染，但某些工具默认要写缓存；资源限制能保护宿主机，但也可能让大型测试误判失败。
实用的采用清单可以是：
- 默认无网络，只有明确任务才打开网络；
- 不把
$HOME、Docker socket、云厂商凭证目录挂进沙盒； - 项目目录按任务拆分读写权限，生成物输出到固定目录；
- 为常见语言预构建 Agent 镜像，避免运行时临时安装过多依赖；
- 在 CI 中记录 Agent 执行命令、镜像摘要、挂载目录和网络策略；
- 对高风险任务使用一次性工作区，完成后只保留 diff 或产物。
AI Agent 的关键变化，是把“模型建议”变成“系统动作”。Docker SBX 和 Sandbox Kits 指向的工程方向很清楚：不要假设 Agent 永远做对事，而是把它放进一个即使出错也可控的执行空间。隔离不是阻碍 Agent 自动化，相反，它是让团队敢把 Agent 接入真实工作流的前提。