Agent训练与评测的安全沙箱：多类隔离与分层镜像实践指南

最近在学习和实践 AI Agent 的过程中，我越来越强烈地感觉到一个问题：大家都在聊 Agent 的能力、推理、工具调用，但很少聊 Agent 在训练和评测阶段是怎么被安全地“关”起来的。一个 Agent 要读写文件、执行代码、调用外部工具，如果它在一个不受控的环境里跑批量的自动化任务，轻则训练任务相互干扰，重则直接污染宿主系统。尤其是大规模并行训练和评测时，你不知道哪个 Agent 会因为一个错误指令去删目录、占满 CPU，或者把上一次实验的环境变量残留带到下一轮。

所以，当看到 DeepSeek 梁文锋署名论文中提出的 DSec 时，我第一反应不是“又一个沙箱系统”，而是“这个方向终于有人认真做了”。DSec 的核心思路可以概括成两件事：一类是面向多类隔离场景的沙箱体系，另一类是分层按需的镜像分发机制。它并不是简单地把 Docker 套在 Agent 外面，而是从大规模 Agent 训练与评测的实际需求出发，设计了一套兼顾隔离粒度、资源效率和分发速度的方案。这篇文章我想把 DSec 涉及的核心概念拆开，结合我自己的理解，用一套可落地的最小实践帮读者跑通“Agent 沙箱 + 分层镜像”的基本流程，最后再聊聊工程上最常见的坑和最佳实践。

无论你是正在搭建 Agent 训练平台的开发者，还是对 Agent 工程化安全感兴趣的架构师，这篇文章都会帮你建立一个清晰的分析框架：为什么 Agent 训练和评测必须要有沙箱？多类隔离到底隔离什么？分层按需镜像解决了什么问题？以及你自己做一个轻量级方案时，可以从哪里入手。

1. 这篇文章真正要解决的问题

Agent 开发与传统后端应用开发有一个显著区别：传统服务通过 API 暴露能力，内部流程相对可控；而 Agent 的核心行为是“感知环境 → 决策 → 行动”，行动意味着真正去执行命令、操作文件、访问网络、启动进程。一个典型的 ReAct 模式 Agent，可能在几轮循环里就完成代码生成、执行、调试、再执行的过程。这里的执行发生在哪？如果直接跑在训练节点的宿主环境，后果很严重。

我们先列四个最常见的痛点：

第一是安全性。Agent 在执行任务时，可能因为模型产生幻觉而执行了危险命令，比如 rm -rf /、shutdown、篡改系统配置，或者在评测阶段提交了不安全的 Payload。评测安全策略时，你甚至在主动让 Agent 面对攻击性指令，这与传统服务的权限控制完全不同——你不能假设 Agent 永远“听话”。

第二是资源隔离。大规模训练和评测通常在同一批物理机上并行跑几十甚至上百个 Agent 任务。如果一个 Agent 出现内存泄漏、CPU 占用失控、磁盘写满，它会拖垮同节点上的其他任务。没有资源配额，整个评测结果都会失真。

第三是环境干扰。Agent 的评测结果必须可复现。如果上一次任务留下了环境变量、修改了全局配置文件、占用了端口，下一次任务启动时表现就会变化。尤其是做模型对比评测时，A 模型的脏环境可能会影响 B 模型的运行结果，最终导致“模型能力差异”变成“环境噪声差异”。

第四是镜像分发效率。每个 Agent 任务可能需要不同的工具链、Python 包、系统依赖。如果每次任务都从零构建完整环境，训练和评测的成本会急剧上升。在大量任务并行启动的时候，镜像拉取和启动速度会成为最大瓶颈。

DSec 的意义就在于同时回应这些问题。它不是一个孤立的隔离组件，而是把“隔离”和“镜像”作为一套基础设施来设计，专门面向 Agent 训练与评测的大规模场景。读完这篇文章，你会理解为什么“多类隔离沙箱”和“分层按需镜像”是配套出现的，也会知道如果自己实现一个轻量级替代方案，最小闭环需要哪些元素。

2. DSec 的核心概念与基础原理

先把概念讲清楚。DSec 名字里的 D 来自 DeepSeek，Sec 是 Security。从公开信息看，它提出了一套支撑大规模 Agent 训练与评测的安全沙箱体系。这里的关键词有三个：Agent、沙箱、镜像。

什么是 Agent？为了不把概念扩大化，这篇里我主要指“通过大模型推理驱动，能够调用工具、执行代码、操作环境来完成目标的程序单元”。比如一个写代码的 Agent，它会生成 Python 文件然后执行；一个操作浏览器的 Agent，它会模拟点击和输入；一个系统运维 Agent，它会连接服务器执行命令。这些动作都可能越过纯文本输出的边界，直接影响真实系统。

什么是沙箱？沙箱是一种隔离机制，把程序限制在一个受控环境中运行。程序以为自己拥有完整系统，实际上它的文件系统、进程、网络、设备、系统调用都可能是映射或过滤过的。常见的沙箱实现包括容器、虚拟机、gVisor、Firecracker、seccomp、namespaces、cgroups 等。沙箱的强弱和性能开销是负相关的，隔离越彻底，性能损耗通常越大。

什么是镜像？这里说的镜像不是 GitHub 镜像站那种概念，而是可部署运行环境的静态模板，类似 Docker 镜像。镜像把操作系统层、运行库、Python 解释器、依赖包、Agent 代码打包成不可变的文件系统快照。Agent 运行时从镜像启动，就能获得一个一致的环境。

DSec 的两个核心创新点，我认为可以从论文标题的措辞里拆出来。第一个叫“多类隔离沙箱”，意思是它不是只用一种隔离技术应对所有场景，而是根据 Agent 任务的风险等级、性能需求、资源边界，提供多种隔离类型。比如：低风险任务用轻量容器隔离，中风险任务加 seccomp 过滤和只读文件系统，高风险任务直接上轻量虚拟机。这样既避免了“一刀切”带来的性能浪费，也避免“全部弱隔离”带来的安全隐患。

第二个叫“分层按需镜像”。容器镜像本身就有分层概念，每一层都是一组文件系统变更。DSec 把镜像进一步按需化：基础环境层、开发工具层、评测数据集层、Agent 运行时层可以分开存储，只有某个任务真正需要某一层时才拉取。这样的好处是：公共基础层只保存一份副本，多个任务共享；大体积数据层按需挂载，而不是跟着每个任务一起复制；评测阶段可以快速切换不同版本的 Agent 运行时，而不必重新拉全套镜像。

表面上看，DSec 似乎只是“容器 + 镜像仓库”的改造。但真正的难点在于：当 Agent 任务并发规模达到几十上百，且每个任务都需要独立、可回滚、可监控的环境时，一次性启动调度、按需加载、精准回收就变成了系统工程问题。从材料看，DSec 选择从训练与评测切入，说明作者团队对“大规模场景下的实际资源开销”有明确考量。

3. 多类隔离沙箱的设计思路

为什么强调“多类”？因为单一隔离策略根本无法同时满足 Agent 训练与评测的所有需求。

先看隔离维度。沙箱隔离至少包括五个方面：

• 文件系统隔离：Agent 能读写哪些目录，是临时目录还是持久化数据目录。
• 进程隔离：Agent 看到哪些进程，能否创建子进程，能否访问宿主 PID。
• 网络隔离：Agent 是否能访问外网，是否能监听端口，能否访问内网元数据服务。
• 系统资源隔离：CPU、内存、磁盘 IO、文件描述符数的上限。
• 系统调用隔离：Agent 能调用哪些 syscall，危险 syscall 直接拦截。

对于不同的 Agent 任务，“多类”体现在选择不同的隔离组合。

比如模型训练任务和工具调用评测任务的风险就不一样。训练任务主要消耗 GPU 算力，Agent 的代码执行动作相对受限，这时候网络可以放通到白名单，文件系统用独立训练目录即可。而安全评测任务则可能要故意模拟恶意行为，或者让 Agent 尝试攻击自建靶场，这时候必须使用最强的隔离边界：无宿主敏感文件、无内网访问、无持久化写权限、系统调用最小化。

再比如编程任务和数据分析任务的资源画像不同。编程 Agent 可能会编译大型项目，需要自定义依赖，必须允许它安装系统包。数据分析 Agent 可能只需要 pandas、numpy 和读取数据集，对网络几乎没需求。如果对两类任务使用同一个沙箱模板，要么过度授权，要么过度限制。

那么 DSec 的“多类”会落在哪一层？一个合理的推测是：它在调度层定义多种 Sandbox Profile，每个 Profile 对应一组隔离参数和镜像模板，Agent 任务提交时选择对应 Profile。这样在平台层面，你可以把“隔离级别”作为一个显式的任务配置项，而不是隐藏在代码里。

用表格来对比不同隔离类型：

这里要强调一个容易踩坑的认知：沙箱并不是越强越好。如果你的评测任务只是为了验证 Agent 是否能在 pip install 后正确运行，却给每个任务起一个 Firecracker 微虚拟机，那启动恢复、内核初始化、网络配置的成本会吃掉所有并行收益。反之，如果一个高风险的评测任务只做了 Docker 容器隔离，那么容器与宿主共享内核的问题可能会让恶意代码利用内核漏洞逃逸。多类隔离的价值，就是允许你在“性能”和“安全”之间按任务粒度做权衡。

这种设计背后的工程逻辑很清晰：Agent 平台不是只有一个安全级别，而是像公有云安全组一样，允许每个任务声明自己的隔离需求。DSec 把这种逻辑抽象成基础设施，比“所有任务都丢进 Docker”更接近真实生产。

4. 分层按需镜像的工作机制

理解了隔离维度，再来看镜像。镜像分层的概念在容器生态里已经非常成熟。一个典型的 Docker 镜像由多个只读层组成：底层是基础操作系统，往上叠加依赖库、Python 环境、业务代码等。当容器启动时，会在这些只读层之上建立一个可写层。

但 DSec 把“分层”和“按需”结合到一起，解决的是 Agent 训练与评测特有的场景问题。我们可以拆解成三个机制来理解。

第一个机制是公共层复用。在一批 Agent 评测任务中，90% 的任务共享同一个基础 Python 环境和同一个基础工具集。如果每个任务的镜像都完整复制这几 GB 内容，存储和网络开销会随任务数线性膨胀。分层之后，公共层在节点上只保存一份，所有任务通过引用方式共享。对于集群节点来说，这相当于把镜像存储从“任务数乘以镜像大小”优化为“公共基础层一份 + 个性化层若干份”。

第二个机制是按需拉取。训练或评测任务并不总是需要完整镜像。比如训练阶段的第一个 epoch 只需要基础环境和训练代码，评测阶段才开始加载数据集。更极端的情况是，Agent 在某个子任务里才会用到某个大模型工具包，那这个包应该在任务走到对应工具调用分支时再拉取。按需拉取可以减少冷启动时间，尤其在多节点同时启动大量任务时，镜像仓库的带宽压力会明显下降。

第三个机制是版本化与回滚。Agent 代码、基础镜像、工具依赖都是独立迭代的。通过分层，你可以让 Agent 代码层频繁更新，但底层基础镜像稳定不动。评测时如果发现新版本工具包有兼容问题，不需要整体回滚镜像，只需要把 Agent 任务的镜像引用切回旧版工具包层的版本即可。这种“层级回滚”比整体镜像回滚高效得多。

借用现实类比：以前的做法是给每个同学发一本完整的参考资料，哪怕他只需要其中两章；DSec 的做法是准备一个公共书库，不同任务按需借阅自己需要的章节，而且借阅记录可以追溯。对于几百个 Agent 并发跑起来的场景，两者的资源占用差异非常明显。

从落地的角度看，分层按需镜像并不一定依赖全新系统。现有容器生态已经提供了基础能力：registry 支持分层存储，containerd 支持远程快照，ORAS 可以管理非容器制品。DSec 的价值更像是在这些能力之上，为 Agent 任务定义了一套标准化的镜像组成规则和调度协议。因此，如果你想自己实现一个简化版，完全可以用 Docker 或 containerd 的分层能力起步。

5. 环境准备与前置条件

理论讲完，开始实操。由于 DSec 本身还在论文与实验室阶段，公开可用的部署包可能有限，所以这篇文章的实践部分，我会演示如何用当前成熟的容器技术，实现一个“多类隔离 + 分层按需镜像”的最小闭环。你在读代码之前，需要先准备一套环境。

需要准备的核心环境包括：

• Linux 操作系统，推荐 Ubuntu 20.04 或更高版本，内核版本不低于 5.10。容器技术重度依赖 namespaces、cgroups、overlayfs，内核太老会出现兼容问题。
• Docker Engine 或 containerd。本文示例使用 Docker CLI，因为它最容易快速上手。生产环境可以考虑 containerd + nerdctl。
• Python 3.9 以上，用于编写 Agent 示例脚本。
• 可用的镜像仓库，本地或远程均可。如果只是单机验证，直接用 Docker 本地镜像即可。
• 磁盘空间，建议预留至少 20GB，因为要拉基础镜像、构建分层镜像、运行容器。
• 非 root 用户运行 docker 命令，避免直接在 root 下操作。这是工程习惯，也是对安全的尊重。

这里必须强调：以下命令和配置只演示通用方案，不是 DSec 的官方安装步骤。项目具体的版本号、命令路径，请以官方文档为准。但核心思路——隔离参数怎么配、镜像怎么分层、任务怎么验证——在 DSec 与现有容器工具链之间是共通的。

在开始之前，先确认 Docker 能正常工作：

bash复制docker version
docker info --format '{{.OSType}} {{.Architecture}}'

如果输出正常，再看 cgroup 是否启用：

bash复制docker info | grep -i cgroup

从材料看，DSec 这种规模系统通常会对内核特性有要求，如果你在自己的服务器上验证，建议先跑一遍上述命令确认环境干净。权限问题也很常见：如果你当前用户不在 docker 组，每条命令前面需要加 sudo，或者执行 sudo usermod -aG docker $USER 后重新登录。

6. 最小 Agent 沙箱实践示例

这个例子的目标不是复刻 DSec，而是用 Docker 验证“隔离”和“分层镜像”两个核心动作。我们会做三件事：

1. 构建一个基础 Python 镜像，模拟“公共基础层”。
2. 在基础镜像之上构建 Agent 运行时层，模拟“按需加载层”。
3. 用不同资源限制和安全参数运行同一个 Agent 脚本，模拟多类隔离。

先看 Agent 示例脚本。这是一段模拟 Agent 动作的 Python 代码，它会输出当前环境信息、读取文件系统内容，并尝试往系统目录写文件。写文件部分我们故意设计成“预期失败”，用来验证沙箱权限边界。

python复制# 文件路径：agent_demo/agent_task.py
import os
import platform
import sys
from pathlib import Path

print("=== Agent Task Start ===")
print(f"Python: {sys.version.split()[0]}")
print(f"Platform: {platform.system()} {platform.release()}")
print(f"Hostname: {platform.node()}")
print(f"Current User: {os.getuid()}")

# 查看当前工作目录
workspace = Path("/workspace")
print(f"Workspace exists: {workspace.exists()}")
if workspace.exists():
    print("Files in /workspace:")
    for p in workspace.iterdir():
        print(f"  - {p.name}")

# 尝试写入系统目录，预期失败
try:
    with open("/tmp/shared_test.txt", "w") as fp:
        fp.write("hello from agent")
    print("Write /tmp succeeded")
except PermissionError as e:
    print(f"Write /tmp denied: {e}")

# 尝试写入工作目录，预期成功
try:
    out_dir = Path("/workspace/output")
    out_dir.mkdir(exist_ok=True)
    (out_dir / "result.txt").write_text("task done")
    print("Write /workspace/output succeeded")
except Exception as e:
    print(f"Write /workspace/output failed: {e}")

print("=== Agent Task End ===")

接下来是基础镜像的 Dockerfile。这里故意只安装 Python 和最基本的工具，不安装任何 Agent 依赖，模拟一个“公共基础层”：

dockerfile复制# 文件路径：agent_demo/base.Dockerfile
FROM python:3.11-slim

RUN set -eux; \
    apt-get update; \
    apt-get install -y --no-install-recommends \
        curl \
        ca-certificates \
        procps; \
    rm -rf /var/lib/apt/lists/*

WORKDIR /workspace
ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1

# 创建独立用户，避免以 root 运行
RUN useradd --create-home --uid 10001 agent_user

COPY agent_task.py /opt/agent/agent_task.py
RUN chown -R agent_user:agent_user /workspace

USER agent_user
CMD ["python", "/opt/agent/agent_task.py"]

注意，Dockerfile 里我指定了普通用户 agent_user。这是沙箱实践里非常重要的一点：即使容器隔离了文件系统，如果以 root 运行，一旦发生提权或挂载逃逸，后果会严重得多。以非 root 用户运行是低成本高收益的安全基线。

先构建基础镜像：

bash复制docker build -f agent_demo/base.Dockerfile -t agent-base:latest agent_demo/

这个镜像比较小，因为是基于 slim 基础镜像。现在我们要做一个分层操作：模拟“数据集层”和“工具层”不打包进基础镜像，只在任务需要时挂载。为了验证分层效果，我会在宿主主机创建一个只读数据目录，并通过 Docker 卷挂载到容器中：

bash复制mkdir -p ~/agent_data/datasets
echo "sample dataset v1" > ~/agent_data/datasets/sample.txt
docker run --rm \
  --name agent-sandbox-demo \
  --user 10001:10001 \
  --read-only \
  --tmpfs /tmp:rw,size=16m \
  -v ~/agent_data:/data:ro \
  -v agent_workspace:/workspace \
  --cpus 0.5 \
  --memory 256m \
  --pids-limit 64 \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  agent-base:latest

这个命令值得逐项解释。

--read-only 让整个根文件系统只读，防止 Agent 修改容器内系统文件。--tmpfs /tmp:rw,size=16m 给 Agent 一个可写但容量有限的临时目录，避免写满磁盘。-v ~/agent_data:/data:ro 把宿主上的数据集目录以只读方式挂载进容器，模拟“按需加载的数据层”。-v agent_workspace:/workspace 把工作目录挂载为持久化卷，模拟“可写工作区”。--cpus 0.5 限制半核 CPU。--memory 256m 限制 256MB 内存。--pids-limit 64 限制最多 64 个进程，防止 Agent fork 炸弹。--cap-drop ALL 删除所有 Linux capabilities，去掉权限放大空间。--security-opt no-new-privileges 禁止提权。

运行后你会看到 Agent 脚本正常工作：数据集可以读，系统目录不能写，工作目录可以写。这就是沙箱的基本价值。

再看“多类隔离”怎么体现。如果这是一个高风险评测任务，你可以在上述命令基础上增加 seccomp 配置，只放行 Agent 需要的系统调用：

bash复制docker run --rm \
  --name agent-sandbox-strict \
  --user 10001:10001 \
  --read-only \
  --tmpfs /tmp:rw,size=16m \
  -v ~/agent_data:/data:ro \
  -v agent_workspace:/workspace \
  --cpus 0.5 \
  --memory 256m \
  --pids-limit 64 \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=./seccomp-profile.json \
  agent-base:latest

对应的 seccomp-profile.json 是一个最小放行配置。因为完整默认 profile 很长，这里只保留启动 Python 和基础读写需要的 syscall。需要注意，这个配置必须结合你的实际场景调整，如果缺少某个 syscall，程序会直接终止。

json复制{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": [
        "read", "write", "close", "fstat", "lseek", "mmap", "mprotect",
        "munmap", "brk", "execve", "access", "openat", "dup", "dup2",
        "dup3", "getdents64", "readlink", "uname", "getuid", "getgid",
        "geteuid", "getegid", "stat", "newfstatat", "arch_prctl",
        "set_tid_address", "set_robust_list", "rseq", "prlimit64",
        "fcntl", "ioctl", "writev", "readv", "exit_group", "exit"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

如果任务只是普通的代码生成评测，不涉及高风险系统操作，那么完全不需要这么严格的 seccomp profile，用第一组 docker run 就够了。这就是“多类”的实践：一个平台为不同风险等级准备了不同命令模板。

7. 运行结果与效果验证

先看正常输出。运行第一个普通沙箱命令后，预期输出大致如下：

text复制=== Agent Task Start ===
Python: 3.11.x
Platform: Linux 6.x.x
Hostname: <container-id>
Current User: 10001
Workspace exists: True
Files in /workspace:
Write /tmp denied: [Errno 30] Read-only file system: '/tmp/shared_test.txt'
Write /workspace/output succeeded
=== Agent Task End ===

注意“Write /tmp denied”和“Write /workspace/output succeeded”这两个结果。如果你看到这个输出，说明文件系统隔离已经生效：Agent 无法向系统目录写入，但可以在工作目录产出结果。同时，容器内看到的主机名通常是容器 ID，这也说明进程与 PID namespace 隔离成立。

如何进一步验证资源限制？在脚本里加一段压力代码，然后观察内存限制是否触发。比如在 agent_task.py 末尾追加：

python复制# 压力验证：申请 300MB 内存，超过 256MB 限制
data = []
for _ in range(10):
    data.append(b"x" * (30 * 1024 * 1024))

如果用第一个限制 256MB 的命令跑，进程大概率会在内存分配阶段被 OOM Kill，Docker 会输出类似 Killed 的状态。这时检查容器状态：

bash复制docker inspect agent-sandbox-demo --format '{{.State.OOMKilled}}'

输出 true 说明内存限制生效。如果输出 false 但执行结束，说明 300MB 还没达到限制上限，需要调整压力大小。这个验证方式可以直观确认 cgroups 对容器内存的约束。

验证 seccomp 是否生效有一个简单技巧：在上面严格的 seccomp profile 配置里故意去掉 uname syscall，然后运行脚本。Python 解释器启动时会调用 uname 获取系统信息，如果被拦截，你会看到 Operation not permitted 或进程直接报错。相反，我们保留了这个 syscall，所以程序能正常运行。这样你就知道 profile 中每个条目都有实际作用。

验证持久化工作区也很重要。第一次运行容器写入 /workspace/output/result.txt 后，即使容器被删除，持久化卷里的数据仍然存在：

bash复制docker volume ls | grep agent_workspace
docker run --rm -v agent_workspace:/workspace alpine ls /workspace/output

如果能看到 result.txt，说明工作区隔离和持久化都成功了。这一步很关键，因为训练和评测需要保留中间产物，不能因为容器退出就全部丢失。

最后验证镜像分层。我们可以用 docker history 查看镜像的层级结构：

bash复制docker history agent-base:latest

输出会显示 CREATED BY 对应的构建命令。你会在基础镜像之上看到我们增加的 apt 安装、用户创建、agent_task.py 复制等层级。这就是“分层”的最直观体现。如果后续加入工具层、数据集层，每次更新只新增一个层，公共层不会被重复构建。

如果运行失败，第一步应该看什么？先看 Docker 命令是否有拼写错误，再看是否缺少目录或权限。比如 ~/agent_data/datasets 不存在时，Docker 会用 root 自动创建目录，这可能导致卷目录权限问题。如果你看到 Permission denied，优先检查挂载目录的属主和 UID 是否匹配。

8. 常见问题与排查思路

在实际搭建 Agent 沙箱时，遇到的问题往往不是概念难，而是细节隐蔽。下面这张表总结了我在实践中比较常遇到的场景，以及对应的排查路径。

在排查这类问题时，我的建议是不要上来就怀疑安全配置，而是先去掉所有限制参数，用最简单的 docker run 跑一遍确认脚本逻辑没问题。然后再逐步加上 --read-only、--tmpfs、--cap-drop 和 seccomp。这样你能精确判断是哪一环引入了故障，而不是把所有因素混在一起。

另外，如果涉及 GPU 资源，Docker 默认不会把 GPU 暴露给容器，你需要安装 NVIDIA Container Toolkit 并加 --gpus all 参数。这个细节在 Agent 训练场景里几乎是必选项，很容易被忽略。

9. 最佳实践与工程建议

到这里，核心概念和最小实践已经跑通了。最后这部分，我想从工程化角度聊一聊在实际搭建 Agent 训练与评测平台时，可以沿用的最佳实践。

第一，把“隔离级别”变成任务配置的一等公民。不要在每个 Agent 启动脚本里手动拼一堆 docker 参数。应该在任务提交接口中定义 sandbox_profile 字段，由平台根据 profile 自动生成运行参数。比如 profile: light 对应基础容器，profile: strict 对应加 seccomp 和只读文件系统，profile: vm 对应微虚拟机。这样不仅清晰，也能避免人工拼命令时漏掉关键安全项。

第二，设计镜像分层时，要遵循“稳定层下沉，变化层上浮”。操作系统、Python 版本、公共依赖库这类很少变化的组件，应该放在镜像底层，最好提前构建并预缓存到节点。Agent 代码、评测数据集、工具包这类变化频繁的内容，应该放在镜像上层，或者通过卷挂载单独管理。这样每天发布几十次 Agent 代码，也不需要重建底层大镜像。

第三，Agent 的持久化数据要谨慎。评测任务的容器默认是临时的，但中间产物需要保留。正确的做法是把 /workspace 挂载成独立卷，并且卷路径中带上任务 ID。不要把所有任务都写进同一个 /workspace，否则并行任务一旦操作到同名文件，评测结果会互相污染。每次任务结束后，根据策略决定保留还是清理卷。

第四，日志与监控要先于故障出现。容器层面的 OOMKilled、pids-limit 触发、文件系统只读错误，都应该被收集到统一监控。Agent 的 stdout 和 stderr 也应该与任务 ID 关联。遇到批量评测失败时，第一件事就是按任务 ID 查日志，而不是去宿主机翻一堆无标签的日志文件。

第五，安全边界要默认最小化，按需放权。我在示例中使用了 --cap-drop ALL 和 --security-opt no-new-privileges，这两项应该成为默认配置。如果某个 Agent 确实需要网络，单独配置白名单，而不是直接去掉网络隔离。如果你发现某个任务必须用 root 运行，那要非常警惕，大概率是这个任务的环境没有设计好，不是非 root 不可。

第六，关注镜像分发效率，但不能牺牲安全性。分层按需镜像是很好的优化方向，但每引入一个新的公共层，都要对它做完整性校验。生产环境可以考虑使用轻量级可信镜像仓库，或者在构建流水线里加入签名和扫描步骤。毕竟 Agent 环境的可信度直接影响训练和评测结果的可信度。

第七，为回滚留好后路。每次 Agent 运行时层更新后，都要保留旧版本镜像标签。当新版本工具包导致评测结果异常时，可以快速切回旧版本，而不是重新构建整个环境。镜像 Tag 建议使用语义化版本，同时在任务记录里保存实际使用的镜像 digest。

第八，如果团队要从零搭建，不要一开始就追求完整的 DSec 体系。先按“Docker + 多 profile + 分层镜像 + 任务卷”这个最小闭环跑起来，再把工作量逐步迁移到调度、网络、监控层面。掌握了这些基础能力，再看 DSec 的源码或论文，你的理解会完全不同。

从整体来看，DSec 的方向很明确：Agent 时代不能只关注模型推理能力，还要关注 Agent 的运行环境治理。多类隔离解决的是“不同任务需要不同安全边界”的问题，分层按需镜像解决的是“大规模任务分发的成本问题”。这两个能力一旦做成基础设施，Agent 训练和评测的规模上限、安全下限和可复现性都会有质的提升。

对于读者来说，下一步可以先在单机上把我们这篇文章里的小实验重复一遍，把 Docker 命令、seccomp profile、卷挂载彻底跑熟。然后尝试把其中几个任务用脚本并发启动，观察资源隔离是否还能生效。再往后，可以考虑引入 Kubernetes 或 Nomad 做任务编排，镜像层接入本地仓库，让多个节点共享分层镜像。等你真正跑过一遍大规模 Agent 评测任务，再回来看 DSec 的设计，就会理解为什么“隔离”和“镜像”必须联动设计，而不是两件独立的事。

建议收藏这篇文章，以后搭建 Agent 沙箱或排查相关问题时，可以回来翻一翻实践部分。也欢迎在评论区交流自己在 Agent 训练与评测环境中遇到的安全或性能问题。