DSec弹性计算：大规模智能体训练沙箱基础设施解析

我最近一直在折腾一件事：把一批智能体搬到沙箱里做大规模训练。折腾完以后最大的感受是，很多人对"训练智能体"这件事的理解还停留在"调模型"——写个 prompt、拉个微调脚本，跑起来就行。但真到了几十个 agent 并发在线、每个都要执行代码、调用工具、读写文件、互相协作的规模，问题的性质就完全变了。它不再是单纯调参的问题，而是实打实的基础设施问题：环境、资源、隔离、恢复、观测，每一项都能卡住整个训练流程。

DeepSeek弹性计算（DSec）这个方向，解决的就是这一层问题。简单说，它是一套面向大规模高效智能体训练的沙箱基础设施：把每个智能体的运行环境隔离在可控沙箱里，按训练需求弹性分配算力资源，同时提供全生命周期的调度、快照和回收机制。这篇文章我想从设计思路、架构拆解、实操落地到排障实录，完整聊一遍这个方案，既有原理也有可直接复制的配置和命令。如果你正在跑多智能体并发训练，或者打算把 Agent 训练平台化，这篇应该能帮你避开不少弯路。

1. 为什么智能体训练必须上沙箱：三个绕不过去的现实问题

先说结论：传统深度学习训练脚本和智能体训练，在"行为可预期性"上完全不是一个物种。理解了这个区别，你才能理解沙箱为什么是必需品，而不是可选项。

1.1 智能体是"会写代码并执行代码"的新型工作负载

传统训练任务是什么样的？数据集路径写死，模型结构写死，训练循环写死，整个脚本的行为在启动前就可以完全穷举。你只需要保证 GPU 驱动、CUDA、PyTorch 版本对得上，任务就基本能跑完。

智能体完全不是这样。它的核心循环是：接收任务 → 生成计划 → 调用工具或执行代码 → 观察结果 → 修正策略。在训练过程中，智能体会自己写 Python 脚本、安装新依赖、创建临时文件、启动子进程、调用系统命令，甚至可能尝试访问网络端口。这些操作在每一轮迭代里都不同，行为空间是开放的，没法提前穷举。

我在早期做 Agent 训练时犯过一个错：直接把训练进程裸跑在一台开发机上。结果一个 agent 为了"完成目标"，往/tmp里写了几万个中间文件，把一个 256GB 的磁盘直接写满。另一个 agent 调了一个正则写炸了的工具，递归 fork 子进程，机器当场卡死。这种事故在传统训练里几乎不可能出现，但在智能体训练里是日常。

所以沙箱的第一层意义：把不可预期的行为，装进一个可控的边界里。智能体可以在沙箱内部为所欲为地实验，但它的文件系统、进程空间、网络权限都被限制在隔离区内，再怎么折腾也不会波及宿主环境和其他训练任务。

1.2 多智能体并发的资源竞争与"占着茅坑不拉屎"问题

第二个问题是资源调度。单智能体训练的资源需求是恒定的——一个训练循环占多少显存、多少 CPU，基本可预测。但多智能体训练里，每个 agent 的资源需求是动态抖动的：有的 agent 在跑一轮很耗时的工具调用，GPU 利用率极低但进程还活着；有的 agent 同时生成了大批代码段，需要突然吃下大量 CPU 做并发执行；还有的 agent 可能进入死循环等待外部响应，资源被白白占住。

打个比方，传统训练像工厂流水线，每个工位产出时间固定，排产简单；智能体训练像超市收银台，每个顾客的购物车大小完全随机。如果你给每个"收银台"都固定分配两台收银机，高峰期不够用，低峰期又大量闲置。

固定资源分配在这种场景下只有两种结果：要么按峰值配置资源，大部分时间浪费；要么按均值配置，高峰期任务排队卡死。DSec 这类弹性沙箱要解决的，就是让资源分配跟随任务实际需求动态变化：任务空闲时自动缩容回收，任务吃紧时自动扩容补上，同时保证同一批任务之间的公平性——不能让一个死循环 agent 把所有 GPU 都占着。

1.3 隔离不是洁癖，是数据安全与多租户的底线

第三个问题最容易被低估：数据安全。当你把智能体训练平台化之后，往往不是一个人在用——不同的团队、不同的项目共享同一批 GPU 资源池。训练数据、Prompt 数据、中间检查点、工具返回的结果，都是敏感内容。

智能体训练还有一个特殊风险：agent 的代码执行能力意味着它可以读文件。如果训练环境不做隔离，一个沙箱里的 agent 理论上可能读到另一个任务的训练数据。这不仅是工程洁癖问题，而是实打实的安全底线。

沙箱在这里承担的角色是"最小权限"原则的工程化落地：每个训练任务只拥有自己该有的数据挂载、只暴露自己该用的模型服务端点、只具备必要限度的系统权限。从进程级隔离、容器级隔离到完整虚拟机级隔离，隔离粒度越粗安全性越高，但性能开销也越大。DSec 的设计里会根据任务风险等级做分级隔离：低风险实验任务用容器级隔离，跑敏感数据或外部不可信代码的任务用更重的隔离方案，而不是一刀切。

2. DSec 到底是什么：从命名看设计哲学

理解一个系统最直接的方式，是拆它的名字。DeepSeek弹性计算，简称 DSec，里面的每个词都不是白放的。

2.1 "DSec"的拆解：弹性、沙箱、基础设施

先把定义摆清楚：DSec 是一套面向大规模智能体训练场景的沙箱基础设施。它的核心职责是管理智能体训练任务的全生命周期——环境准备、资源分配、任务调度、状态快照、异常回收——让训练框架只需要关心模型和策略，不需要关心运行环境。

"弹性计算"这四个字的含义，是要把算力资源变成像水电一样按需取用的东西，而不是像传统 HPC 集群那样通过排队等待固定节点。在 Agent 训练场景下，弹性体现在三个不同维度：

资源弹性：每个训练任务能拿到多少 CPU、GPU、内存、磁盘，不是写死在配置里的，而是根据任务实际负载动态调整。任务吃紧时多分配，任务空闲时自动少占。

任务弹性：训练任务本身可以随时启动、暂停、快照、扩容副本。一个多智能体对抗训练要加一个 agent 进来，不需要重启整个任务，直接在沙箱编排层动态拉起新实例。

环境弹性：不同的训练任务可以指定完全不同的运行环境——Python 版本、依赖库、系统工具链，互不污染。A 任务的沙箱里装了 torch2.5，B 任务的沙箱里还在用 torch1.13，两者可以同时跑在同一张物理机上。

"沙箱基础设施"则强调它不是一个单点工具，而是一层平台能力。它在底层资源池和上层训练框架之间，提供标准化的接口，让训练任务像提交一份表单一样简单地把环境要求和资源需求声明出来。

2.2 和普通容器编排平台的差异：调度语义不同

很多人第一反应是：这不就是 Kubernetes 上跑容器吗？确实，DSec 这类系统可以构建在容器编排平台之上，但它的调度语义和普通工作负载有本质差异。

普通容器编排调度的是什么？是无状态的微服务——启动 N 个副本，流量均摊，扩缩容看 QPS。而智能体训练沙箱调度的是什么？是带状态的、需要和模型推理服务深度互动的、生命周期可能从几分钟到几小时不等的训练会话。

一个典型的智能体训练沙箱，需要同时具备这几个和普通容器不同的能力：

模型服务感知。沙箱里的 agent 每一步推理都要访问 LLM 服务。调度系统必须知道模型服务跑在哪、服务当前负载如何、沙箱与模型服务之间的网络路径是否通畅。这是普通容器编排完全不会关心的。

会话快照。训练中途被打断、资源被抢占，都要求沙箱能对当前状态做快照，之后在新节点恢复。普通容器重启就是从头再来，智能体训练的重启代价高得多，必须有断点续训的能力。

生命周期上限。智能体训练任务经常跑飞（死循环、上下文失控），所以沙箱必须有强制的生命周期管理——设置 max runtime，超时自动回收。普通容器平台很少会默认强制杀掉一个运行中的服务，但沙箱必须这么做。

下面这张表可以对比普通方案和 DSec 强化方案的差异：

2.3 DSec 风格系统的分层架构

DSec 这类基础设施从下到上大致分四层。我实际搭建时完全按这个分层来做，每一层职责清晰，出问题也好排查。

最底层是资源池层：GPU 物理机、CPU 节点、共享存储。这一层负责把裸金属资源统一抽象成可分配的资源池，记录每台机器的显存总量、已分配量、健康状态。

第二层是沙箱编排层：这是 DSec 的核心。它管理镜像仓库、任务队列、调度策略、配额控制、生命周期管理。每个训练任务的创建、启动、监控、回收都在这一层完成。

第三层是模型服务层：DeepSeek 模型的推理服务（vLLM 部署或其他方式）在这一层运行。它和沙箱编排层之间有标准接口，沙箱内的 agent 通过注入的环境变量拿到模型服务的访问地址和密钥。

最上层是训练框架层：跑多智能体训练逻辑的代码、数据流、评估脚本。这一层不关心底层资源，只和沙箱编排层暴露的 API 交互——提交任务、查询状态、拉取日志。

这个分层最大的好处是每一层都可以独立演进。模型服务不够了就横向扩模型服务；沙箱资源不够了就加物理机；训练框架逻辑改了不动底层。我后来把训练框架从单机脚本迁到这套架构上，几乎没动底层代码，只改了你提交任务的方式。

3. 实操落地：从零构建一套 DSec 样式的训练沙箱

讲了这么多设计，现在进入实操环节。我会用一套实际上能跑通的技术栈来演示怎么搭建——这套组合不一定是最优解，但经过我验证，作为起步方案非常稳：Docker + NVIDIA Container Toolkit + Redis（队列）+ vLLM + 训练侧 Agent 框架。如果你团队里已经有 Kubernetes 和 Ray，也可以平滑替换对应组件。

3.1 基础环境与工具链选型

先别急着装系统，把工具链的关系理清楚。沙箱的隔离核心靠容器，这一步可以用 Docker 也可以用 containerd；GPU 透传需要 NVIDIA Container Toolkit；模型服务我用 vLLM 部署 DeepSeek 模型，因为 vLLM 对开源模型的支持最成熟，而且自带 OpenAI 兼容的 API Server；弹性调度和任务队列需要一个轻量的协调器。

以一台 Ubuntu 22.04 + 四卡 A100/A800 的机器为例，基础环境准备大致是这几步：

# 1. 安装 Docker curl -fsSL https://get.docker.com | bash systemctl enable --now docker # 2. 安装 NVIDIA 驱动（需匹配 CUDA 版本，建议 550+） apt install -y nvidia-driver-550 # 3. 安装 NVIDIA Container Toolkit curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \ | gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \ | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#' \ > /etc/apt/sources.list.d/nvidia-container-toolkit.list apt update && apt install -y nvidia-container-toolkit # 4. 让 Docker 识别 GPU nvidia-ctk runtime configure --runtime=docker systemctl restart docker # 5. 验证 GPU 容器可运行 docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

到这里，GPU 容器的基础能力就有了。注意第 5 步的验证一定不能省——我见过很多环境装上 toolkit 后忘了重启 Docker，容器里根本看不到 GPU，排查了半天才发现是 daemon 没加载新 runtime。

3.2 沙箱镜像标准化：让每个训练任务有统一的"起跑线"

镜像设计直接决定沙箱的稳定性和构建效率。经验法则是把镜像分成三层做：基础层、依赖层、项目层。

基础层是整个团队共享的根镜像，包含操作系统、Python 运行时、系统依赖库。这一层尽量少变，一个月更新一次就够了。依赖层包含 AI 训练框架的通用依赖——PyTorch、transformers、numpy、openai SDK、以及 DeepSeek 相关的工具库。项目层才放具体训练任务的代码和私有依赖。

三层分离的核心收益是缓存命中率。我实测下来，如果基础层和依赖层不变，项目层代码更新后重建镜像只需要几十秒；如果不分层，每次改一行代码都要重新安装几个 GB 的依赖，团队同时跑十几个任务时镜像构建能把磁盘和网络带宽吃满。

一个典型的 Agent 训练沙箱 Dockerfile 大概是这样的：

# 依赖层 FROM dsec/base:py311-torch245 AS deps RUN pip install --no-cache-dir \ vllm==0.6.3 \ openai==1.35.0 \ transformers==4.44.2 \ agent-sdk==0.3.1 \ networkx==3.2.1 # 项目层 FROM deps AS project WORKDIR /workspace COPY ./train_loop.py /workspace/ COPY ./tools/ /workspace/tools/ COPY ./requirements.txt /workspace/ RUN pip install --no-cache-dir -r requirements.txt ENTRYPOINT ["python", "/workspace/train_loop.py"]

构建完之后，把项目层单独 push 到私有镜像仓库，给每个任务打上唯一 tag（比如train-run-001）。这样做的好处是：镜像即版本。哪个任务跑了哪个镜像、依赖是什么版本，查 tag 就能回溯。我在上线初期没做好这点，结果出了问题根本不知道任务是跑在哪个依赖组合上，排查成本极高。后来强制要求每个训练任务必须保留镜像 tag 和训练日志的关联索引，整个可追溯性才补上来。

3.3 资源配额与弹性策略：给每类任务匹配"刚好够用"的资源

沙箱的资源管理，我建议采用"配额硬约束 + 调度弹性"的组合。配额是硬性的：每个任务最大能用多少 GPU 显存、多少 CPU、多少内存，在任务提交时就通过声明式配置写死，运行时不能越界。弹性则体现在合理设置优先级队列，让重要任务可以抢占次要任务的资源。

实际跑的配置示例：

# 任务资源声明示例 resources: cpu: 4 # 单任务最多 4 核 mem: 16Gi # 最多 16G 内存 gpu: 1 # 1 张卡 disk: 50Gi # 沙箱工作区最多 50G runtime_limit: 6h # 硬性生命周期上限，到点自动快照并回收

注意，这里的 CPU 和内存是"上限"而不是"申请量"。调度器在任务启动时只保证最低资源（比如 2 核起步），但允许任务在物理机有余量时向上用到配额上限，不够用再被限制。这种"上限弹性"的思路比传统容器平台的"申请多少就是多少"更适合智能体训练——因为训练任务的资源需求动态波动大，固定申请要么浪费要么不够。

3.4 与 DeepSeek 模型服务的三种对接方式

沙箱里的 agent 每一步推理都要访问模型服务，这是整个链路里最关键的集成点。我按场景不同试过三种方式，各有适用场景。

第一种：官方 API 方式。直接在沙箱环境变量里注入 API Key 和 Endpoint，agent 通过 OpenAI SDK 调官方接口。这种最简单，适合小规模试验、快速验证想法。缺点是训练量大时代价高，而且依赖网络链路稳定性。

第二种：vLLM 本地部署。自己在 GPU 资源池上起一个开源模型的服务，沙箱内的 agent 通过内网地址访问。这种适合大规模训练，一次部署多次复用。启动命令如下：

python -m vllm.entrypoints.openai.api_server \ --model /models/DeepSeek-R1-Distill-Qwen-32B \ --tensor-parallel-size 4 \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --port 8000 \ --host 0.0.0.0

关键参数里，--tensor-parallel-size决定模型切到几张卡上，四卡机器可以设 4，但要确认卡间互联（NVLink/PCIe）带宽够；--gpu-memory-utilization设 0.92 表示给模型预留 92% 显存，留 8% 给 KV cache 管理和其他开销。跑起来之后，vLLM 会在 8000 端口暴露一个和 OpenAI 兼容的接口，沙箱里的 agent 只需要把 base_url 指过去：

from openai import OpenAI client = OpenAI( base_url="http://vllm-service:8000/v1", api_key="internal-service-key", # 本地服务无所谓，填一个占位符即可 ) resp = client.chat.completions.create( model="DeepSeek-R1-Distill-Qwen-32B", messages=[{"role": "user", "content": "..."}], )

第三种：模型网关统一接入。把 DeepSeek 官方 API、私有化部署、开源模型服务统一收敛到一个网关后面，沙箱里只需要配置网关地址。网关层可以做路由、限流、请求级 token 统计。当你的组织里同时有多个模型来源、要给不同训练任务分配不同模型时，强烈建议走这一层，否则每个任务都要自己管模型地址和密钥，维护成本会随任务数量线性增长。

4. 核心环节实现：任务提交、调度与回收的全流程

架构和基础环境就绪后，最关键的是把任务的生命周期跑顺。这一步是最容易出问题的——沙箱创建出来了，但任务提交格式不标准、调度不均、回收不彻底，系统很快会变成一团乱麻。

4.1 标准化的任务定义：把"怎么跑"交给声明式配置

沙箱基础设施的核心价值在于标准化。所有训练任务必须通过同一套声明式任务描述提交，不能允许"直接 ssh 到机器上跑脚本"这种野路子。我用的任务定义格式大致如下：

agent_task: name: "multi_agent_evolve_round_12" image: "registry.internal/dsec/agent-runtime:run-0123" entrypoint: ["python", "train_loop.py", "--round", "12"] resources: cpu: 8 mem: 32Gi gpu: 2 disk: 100Gi runtime_limit: "8h" mounts: - name: training-data path: /workspace/data type: read-only - name: checkpoint-store path: /workspace/ckpt type: read-write env: LLM_ENDPOINT: "http://vllm-gateway:8000/v1" TRAIN_CONFIG: "configs/evolve_v3.yaml" hooks: on_exit: "snapshot_and_recycle" heartbeat_interval: "60s"

每个字段背后都有实际考量。mounts里数据卷分只读和读写——训练数据只读挂载，防止 agent 修改原始数据；检查点目录读写，因为要持续保存训练状态。runtime_limit是硬性上限，不是建议值——超过 8 小时不管任务跑没跑完，强制触发快照然后回收。我踩过太多次"任务挂着忘了杀，GPU 被占了一周"的坑，后来把 runtime_limit 做成所有任务的强制默认值，只有在特别审批的情况下才允许延长。

hooks里的 heartbeat 很关键。沙箱里的训练进程需要每隔 60 秒向协调器上报心跳，心跳断了 5 分钟以上，协调器会判定任务异常，自动干掉沙箱并触发快照和告警。这是防"死循环占资源"的最后一道闸门。

4.2 调度与冷启动优化：把 P99 启动时间压到分钟级以内

训练任务对调度延迟的容忍度很低。如果一次任务提交要排队等 20 分钟环境才就绪，整个训练平台的效率会非常难看。冷启动时间主要花在镜像拉取和依赖加载上，优化手段就围绕这两点展开。

镜像预热是最直接有效的优化。提前把常用镜像从仓库拉取到每台物理机，任务调度时优先选择镜像已就绪的节点。我实测下来，这一项能把沙箱启动时间从分钟级压到十秒级。具体做法是写一个预热守护进程，监听任务队列的镜像请求，提前在节点上 pull。

第二个优化是数据局部性。训练数据通常很大（几十 GB 到几百 GB），如果每次任务启动都要从共享存储拖数据，网络会成为瓶颈。做法是让调度器记录每个数据分片在哪些节点上已经缓存了，调度任务时优先指派到数据就近的节点。带着一张大 Table 做数据迁移的代价，远高于随机调度的便利，所以这个优化非常值。

还有一个细节：不要在任务启动时做依赖安装。所有依赖必须在镜像构建阶段装好，沙箱启动后直接执行 entrypoint。有人图方便，在沙箱启动命令里加一段pip install -r requirements.txt，这会在每次任务创建时引入不可控的变数——依赖源抖动、网络晚高峰、版本索引漂移，任何一个都能让任务启动失败。镜像构建是一次性的，任务启动是高频的，把不可控因素都放在低频阶段处理。

4.3 训练状态与日志的可观测性：黑盒子是最恐怖的故障源

智能体训练出问题的时候，最大的困难是"不知道 agent 刚才干了什么"。普通训练看 loss 曲线就够了，智能体训练需要看的是完整的决策轨迹——agent 调了什么工具、传了什么参数、工具返回了什么、agent 如何根据返回修正策略。

沙箱基础设施需要把这类观测数据作为一等公民来处理。我在实践中对沙箱日志做了三级设计：

基础级：容器 stdout/stderr 全量收集，按任务聚合，支持按关键字搜索。这是排查一切问题的基础。

结构化级：Agent 框架通过 SDK 主动上报结构化事件——每次 LLM 调用、每次工具执行、耗时、token 消耗。这类日志会进入专门的事件流，按会话聚合回放成完整训练轨迹。

快照级：关键节点（训练轮次结束、checkpoint 保存、异常退出前）自动对沙箱工作区做快照。快照内容包括代码、数据文件、工具输出、以及一个序列化的上下文记忆文件。有余力的话可以对接对象存储，把快照和事件流关联起来，让任何一个训练任务都能完整回溯。

这一层我建议在系统搭建之初就做好，不要等出问题了再补。因为训练轨迹的回放能力，直接决定了你在面对"某个 agent 在某一步突然行为异常"时，是花 10 分钟定位还是花 3 天复现。

4.4 会话上限与断点续训：长任务的沙箱级解法

智能体训练的会话不像单轮推理，上下文会随着训练轮次不断增长。很多训练框架会遇到对话上限的问题——一轮训练跑到一半，上下文窗口满了，新对话又不记得前面的状态。在沙箱基础设施层面，可以配合训练框架做三件事。

第一，定期序列化会话状态。训练框架在每轮迭代的间隙，把当前会话的上下文摘要、关键记忆、工具调用记录序列化成结构化记忆文件，写入沙箱挂载的记忆存储。

第二，拆轮次跑。利用沙箱的运行时生命周期机制，把一个长任务拆成多个短任务。每个子任务跑固定轮次后优雅退出并保存状态快照，下一个子任务通过加载快照继续。这样就绕开了单任务运行时长被斩断的问题——每一个子任务都足够短，不会触发资源被占满的警告，但整体训练跨度可以拉得非常长。

第三，上下文接力。当一个新任务需要承接上一个任务的上下文时，它在启动时读取记忆文件与状态快照，把之前的核心信息注入到新的 prompt 里。这对应社区里常见的问题"到达对话上限之后怎么让新对话承接上一个对话"——在工程上这就是把上下文外移到沙箱持久化存储，需要时再加载回来，而不是一直撑在单线程的内存里。

这部分的实现并不复杂，难的是训练框架要配合做状态序列化。在选定 Agent 训练框架时，一定要确认它支持会话状态导入导出，否则基础设施再完善，训练任务也无法共享推进上下文。

5. 实战排障实录：我踩过的那些坑

基础设施类的项目，调试时间往往比开发时间还长。这套 DSec 样式的沙箱体系我从零搭到现在，踩过的坑可以单开一个合集。挑几个有代表性的写出来，很多是常规文档里不会提的。

5.1 权限问题是一大片：从 Win32 报错到容器内 UID

权限类问题是我遇到最多的一类，表现形式五花八门。其中一个典型的跨平台场景：开发者在 Windows 工作站上通过工具客户端同步沙箱工作区时，弹出SetNamedSecurityInfoW failed (win32)的报错。这个报错看着莫名其妙，实际是 Windows 上安全策略拦截了客户端对文件/目录 ACL（访问控制列表）的修改操作——沙箱工作区同步工具试图设置权限位，被系统安全策略拒绝了。

遇到这类问题，排查顺序是：先确认是不是杀毒软件/安全软件把同步进程当成可疑行为拦了；再检查当前用户对工作区目录是否有完全控制权限；最后看是否要调整同步工具的配置让它不要尝试修改 ACL。最简单的临时绕过是换一个非系统盘的工作目录，但根治办法还是在安全软件的白名单里放行同步进程。

容器内的权限问题更常见。典型场景是挂载数据卷后，容器内进程没有写权限。原因是宿主机目录的所有者是 UID 1000 的开发用户，但容器内进程以 UID 0（root）运行，或者反过来。解决方案有几种：在 Docker 运行时用--user参数把容器内 UID 映射到宿主机所有者；或者在挂载时指定:U标签（对 SELinux 环境）；K8s 环境可以设置 Pod 的securityContext.fsGroup。我的经验是：团队内部统一约定"宿主机目录所有者和容器内运行 UID 保持一致"最省心，否则每个任务配一次权限，迟早配错。

5.2 镜像和依赖版本：装不上、跑不对、回了头

镜像构建失败是排障的另一大来源。最常见的是 pip 源问题——沙箱容器默认访问公网 PyPI，国内网络环境下拉包经常超时。解决方法是把 pip 源指向内网镜像源，并且在基础镜像里写死：

RUN pip config set global.index-url http://mirrors.internal/pypi \ && pip config set global.trusted-host mirrors.internal

还有一个容易忽略的坑：基础镜像的pip.conf不会自动继承到上层镜像。我在构建依赖层时明明配好了内网源，但项目层重新安装依赖时又走了公网源。后来把所有镜像的 pip 配置统一放到一个pip.conf文件里，COPY 到镜像的全局配置目录，这个问题才彻底消失。

版本回退的坑也值得说。有时候依赖升级后训练结果出现细微波动，需要把镜像回退到旧的依赖组合。回退很简单，但团队里的成员如果不习惯用镜像 tag 管理版本，直接在容器里手动改依赖，就会造成"镜像版本和实际环境不一致"的幽灵问题——你永远不知道哪个任务是哪个版本跑出来的。强制的做法是：禁止在容器运行期间安装任何依赖，镜像一旦构建完成就不可变，任何依赖变更都通过重新构建镜像来完成。

5.3 资源泄漏：僵尸进程与 GPU 显存黑洞

沙箱回收机制如果不彻底，几个任务跑下来资源池就满了。我遇到最多的是僵尸进程问题——训练任务的主进程退出了，但 agent 为完成目标 fork 出的子进程还活着，继续占着显存或 CPU。

解决分两道防线。第一道是进程树管理：沙箱创建时给整个任务放进同一个 Cgroup，回收沙箱时直接杀掉整个 Cgroup 内的所有进程，而不是只杀主进程。裸的docker stop有时候不会清理后代进程，配合 Cgroup 才能连锅端。第二道是强制宿主层巡检：每台物理机上跑巡检脚本，扫描超期未释放的 GPU 进程，发现即自动清理。

GPU 显存泄漏的另一个隐蔽来源是推理上下文未释放。Agent 在循环里不断调用模型服务，如果客户端 SDK 没有正确管理连接和缓存，显存占用会随训练轮次缓慢爬升。这类问题在 Agent 侧很难定位，所以在沙箱层做兜底：对单任务的 GPU 显存设置软上限和硬上限，超过软限时报警，超过硬限时自动重启沙箱并从最近快照恢复。

5.4 网络连通性：模型服务与沙箱之间的"最后一跳"

当模型服务和沙箱不在同一台机器上，网络连通性就是最容易出诡异问题的环节。我遇到的典型场景是：模型服务在节点 A，训练任务调度到节点 B，沙箱内的 agent 访问模型服务地址时偶尔超时。排查后发现不是网络不通，而是节点 B 上的防火墙规则只放行了一部分端口，vLLM 服务的端口被拦了。

这类问题最容易在分布式环境里出现，因为每个节点的网络策略可能不完全相同。我采取的做法是：所有模型服务的访问统一走内网网关域名，沙箱内不直接配置节点 IP 和端口。网关背后的路由和防火墙规则由平台统一管理，有变动只在网关层操作，不用逐台机器改配置。同时，沙箱编排层启动任务时会先做一次"模型服务连通性预检"，不通直接报错不启动任务，避免任务跑起来才发现模型访问不了。

5.5 常见问题速查表

把高频问题整理成一张表，遇到类似情况可以直接对照排查：

提示：遇到任何诡异问题，第一个动作永远是"看日志、查指标、恢复现场"。日志和快照体系如果前期做好了，这里的排查时间至少能省一半。

经验和一些体感建议

这套沙箱基础设施从设计到落地，我自己的体会可以浓缩成三条铁律：Always snapshot、Always quota、Always kill。任何训练任务都要能拍快照，任何时候都要有资源配额上限，任何失控任务都要能被强制回收。只要这三条做到了，其他的问题都只是磨刀的时间问题。

还想提醒一句：不要一上来就追求完整的大平台。先在一台机器上把最小闭环跑通——镜像构建、单个沙箱、模型服务对接、任务提交、日志回收——再逐步扩展调度、快照、多节点。一次性铺开反而容易在环境层面栽跟头，到时候连问题出在哪一层都难判断。

DSec 这个方向后续还能往深走不少：把沙箱和模型服务做更紧密的联动，根据 agent 的推理请求量动态扩缩容模型服务的 VPU 配额；把多轮训练的中间数据回流做自动数据蒸馏；甚至可以做跨集群的联邦调度线程，把空闲 GPU 的资源池盘活。基础设施的创新往往不是某个单点突破，而是每一层都顺手一点，最终让上层训练效率发生质变。希望这篇内容能帮你少走一些弯路，也期待看到更多针对智能体训练场景的基础设施方案出现。