面向智能体训练的弹性沙箱基础设施：DSec设计与落地

搞了大半年智能体批量训练，我最大的感受不是模型效果难调，而是环境问题比模型问题更磨人。训练数据要投喂、工具调用要跑、并发任务要排队，稍不注意两个训练任务就会互相污染，甚至把宿主机搞挂。前阵子我把整套流程收敛成了一个还算顺手的方案，内部叫它 DeepSeek 弹性计算，代号 DSec，本质是一套为大规模高效智能体训练设计的沙箱基础设施。这篇文章聊聊它解决的问题、整体架构、关键配置，以及我在落地过程中踩过的坑，给正在做同类事情的人一个参考。

1. 为什么智能体训练需要一套专门的沙箱基础设施

1.1 智能体训练到底难在哪

很多人以为智能体训练和传统模型训练差不多，无非是准备好数据集、跑训练脚本、等 loss 下降。真上手会发现完全不是一回事。智能体训练的核心单元是一轮完整的"感知-决策-行动-反馈"轨迹，它不是一个固定shape的批数据，而是长串动态执行的交互记录。

这就带来几个非常现实的问题。第一，轨迹长度不可控。一次任务可能几十轮对话，也可能几百轮工具调用，上下文窗口占用忽高忽低，显存频繁抖动。第二，每个智能体任务都有独立状态。不管是模拟浏览器会话，还是操作一份临时文件，任务和任务之间不能共享任何可变状态，否则训练出来的轨迹全是脏数据。第三，强化学习场景下，训练器要不断向运行环境发起交互并等待真实反馈，一旦环境崩溃、超时或者返回了莫名其妙的错误，整条轨迹就废了，甚至可能带偏策略模型。

传统训练框架处理不了这种高动态、长周期、强交互的负载，它们假设数据是静态的、任务是可切分的。智能体训练反过来，它要求环境本身能够被创建、被隔离、被回滚，并且要能清楚地回答一个问题：这条轨迹是从什么样的初始世界状态开始的？

1.2 沙箱不是安全模块，是训练环境本身

很多团队第一次听说"沙箱基础设施"，第一反应是安全加固，防止 agent 执行危险操作。这个理解只对了一半。在智能体训练里，沙箱的本质是给每个 agent 提供一个干净、一致、可复现的"小世界"，它不只是围栏，更是舞台。

我用一个例子解释：假设你要训练一个擅长数据分析的智能体，它需要在临时目录里生成 CSV、调用 pandas 做统计、再用 matplotlib 画图保存。如果所有 agent 共享一个裸环境，A 任务生成的 /tmp/result.csv，可能下个任务就读取到了，而 B 任务安装的某个依赖版本一变，C 任务的评估结果就完全不同。这种状态下，你根本没法判断模型能力的变化是来自训练策略，还是来自环境噪声。

所以沙箱需要保证四个最基本的能力：文件系统隔离、网络访问可控、运行资源配额、状态可复现。只要这四点做到位，训练轨迹才有可比性，奖励模型的分数才真正反映智能体能力，而不是环境运气。

1.3 弹性计算解决的成本与效率矛盾

智能体训练的负载曲线和传统业务也完全不一样。白天可能同时跑着几百个评测任务，深夜强化学习探索阶段只剩几十个，周末可能还要跑一波全量回归。如果按峰值静态分配资源，GPU 大部分时间在空转，成本根本压不住。如果按最小值静态分配，任务排队排到天荒地老，训练迭代速度被拖垮。

弹性计算要解决的就是这个矛盾：让沙箱实例数实时跟着任务队列走，有任务就快速拉起足够多的并行环境，队列清了就立刻回收资源。这比常规的微服务弹性伸缩更硬核，因为智能体沙箱不仅是计算资源，还包含模型推理服务、工具运行环境、数据集快照，牵一发而动全身。

2. DSec 的整体架构与核心选型

2.1 三层架构：控制面、训练面、沙箱面

DSec 的设计我刻意分成三层，每层职责单一，互相之间只通过接口通信。

第一层是控制面，负责所有任务的生命周期管理。它维护一个任务队列，接收来自训练框架的沙箱创建请求，调度到具体的物理节点，监控运行状态，处理异常重试。控制面本身没有任何业务逻辑，它只回答三个问题：这个任务该在哪跑、现在跑到什么程度了、失败了怎么处理。

第二层是训练面，也就是我们跑训练算法的地方。无论你用 Ray、自研策略梯度框架还是某个开源 RLHF 工具，训练逻辑都在这层。训练面不直接操作容器和镜像，它只通过 HTTP/gRPC 接口把任务描述扔给控制面，然后异步等待结果。

第三层是沙箱面，是每个智能体任务真正运行的地方。一个沙箱实例内部封装了 DeepSeek 模型推理服务、Python 运行时、各类工具 SDK、数据缓存和监控组件。外部看到的是一个整体容器，内部则是一个微型工作台。

这样设计的好处是，训练框架可以随时替换，沙箱配置也可以随时调整，只要两边接口不变，任何一层的改动都不会牵连整个系统。

2.2 沙箱隔离方案选型：Docker、K8s、gVisor 的取舍

沙箱隔离方案我前前后后对比过好几轮，这里直接给结论和理由。

我在 DSec 里实际采用的是双层沙箱。外层是 K8s Pod，跑的是 DeepSeek 模型服务和通用工具集，网络策略由 NetworkPolicy 控制。内层是在需要执行不可信代码时，才把任务下沉到 gVisor 或 Firecracker。这么折腾的原因很简单：模型推理服务的性能敏感，不适合全部跑在强隔离里，但智能体训练又必须面对大量不可信的、由模型生成的代码片段，完全没有进程隔离我不敢让它碰真实文件系统。

如果你只想快速落地，可以只做 Docker 容器层。但千万记得加白名单和资源配额，不然一个死循环的 agent 能把你整个节点搞到不可用。

2.3 弹性伸缩策略：队列驱动而不是指标驱动

传统做微服务伸缩，看的是 CPU、内存、QPS。这套思路放在智能体沙箱上效果很差，因为沙箱内任务的资源消耗波动巨大，CPU 指标还没触发，任务队列可能已经堆了几百个了。

DSec 的伸缩策略是队列驱动的。控制面实时维护待调度任务数，伸缩器通过 Prometheus Adapter 暴露自定义指标，HPA 根据指标伸缩沙箱实例。更直接的方式是写一个 Scale Controller，监听队列深度，直接调整 Deployment 的副本数。

这里给一个可落地的计算公式。设当前等待队列深度为 Q，单个任务平均执行时长为 T_task，你期望的新任务排队时间上限为 T_limit，那么需要保持的并发沙箱数 N 可以粗略估算为：

N = Q × T_task / T_limit

举个例子，队列里有 20 个任务，每个任务平均跑 600 秒，你希望新提交的任务最多排队 60 秒，那 N 至少是 20 × 600 / 60 = 200。这个公式给了我们一个很直观的直觉：任务越重、队列越深，沙箱数越要果断拉大。实际运行中可以给 N 设置上下界，比如最小 10 个、最大 500 个，避免冷启动瞬间把集群打爆。

3. 核心细节解析与实操要点

3.1 沙箱镜像设计：把模型服务当成环境的一部分

智能体沙箱和普通应用容器最大的区别在于，沙箱里不仅仅跑你的业务进程，还要跑一个完整的模型推理引擎。我在 DSec 中默认用 vLLM 作为 DeepSeek 模型的推理后端，因为它的吞吐和显存管理比原生 transformers 好很多。

沙箱镜像设计必须遵循一个原则：模型权重不烧进镜像。第一次我把权重直接 COPY 进镜像，结果镜像膨胀到 30GB，每次拉取都像灾难。后来改成模型权重放在共享存储上，通过只读 PVC 挂载进容器，镜像里只放推理服务的代码和依赖。这样镜像体积控制在 4GB 以内，冷启动速度快了几个量级。

镜像里还需要预装工具执行环境。比如 Python 数据分析、Node.js、浏览器自动化脚本、SQLite 等等。每个工具的版本要严格固定，因为智能体在执行过程中会产生对环境的依赖，一个 pandas 版本升级都可能改变轨迹结果。版本不一致，训练复现就是一句空话。

我习惯在镜像中加一个VERSION文件，记录基础镜像 tag、依赖版本和模型版本，每次训练任务都把这个版本号写入轨迹元数据。后期做实验对比时，一条命令就能筛出所有跑在相同环境版本上的任务，非常方便。

3.2 会话与状态管理：无状态沙箱，有状态训练

沙箱本身一定要设计成无状态的。如果一个沙箱崩了，它内部的所有东西都能被丢弃，控制面可以从训练状态存储中恢复一个新的沙箱继续跑。但智能体训练整体又必须是有状态的，对话历史、已经执行的工具调用、产生的中间文件，这些都不能丢。

我的处理方式是：每个训练任务分配一个持久化卷，里面存放智能体的工作目录和状态文件。沙箱容器启动时挂载这个卷，任务结束或容器崩溃后，卷仍然保留。训练器通过回调接口重新获取新沙箱地址时，可以继续读取之前的卷数据，实现断点续跑。

对话上下文这种高频状态不放在磁盘里，而是放在 Redis 中。每次工具调用完成后，智能体的完整对话记录写回 Redis，并维护一个全局递增版本号。训练器读取时只要带上版本号，就能拿到一致性的快照。

这套设计下，一个沙箱挂掉并不可怕，最多让当前这条轨迹从头开始那一轮思考。但如果状态管理没做好，沙箱挂掉意味着整个任务白跑，可能浪费几十分钟的训练时间。

3.3 与训练框架的接口设计：gRPC + 任务描述文件

训练框架和 DSec 控制面之间需要一个稳定清晰的接口。我用的是 gRPC，主要因为训练框架往往由 Python 编写，智能体沙箱内部服务也是 Python，gRPC 的双向流式调用非常适合长轮次交互。

每个训练任务用一个 YAML 描述文件定义，DSec 把它翻译成沙箱实例规范。文件内容大概长这样：

task_id: "exp-20240615-001" image: "registry.internal/dsec/agent-sandbox:2.3.1" model: backend: "vllm" model_path: "/models/DeepSeek-Chat-7B" gpu: "1" resources: cpu_request: "4" memory_limit: "16Gi" disk_quota: "10Gi" tools: - "python" - "bash" - "sqlite3" - "httpx" network: egress_allow: ["api.internal", "cdn.objects"] ingress_deny: true state: persistent_volume: "task-exp-20240615-001"

训练框架调用CreateSandbox(task_spec)后，控制面返回一个沙箱 ID 和访问地址。之后训练器就可以往这个沙箱里推送智能体系统的下一步动作，沙箱内的运行时负责执行工具并返回执行结果。接口只传指令和结果，不传原始数据，避免网络传输放大开销。

gRPC 接口设计中最容易出错的是超时和重试逻辑。智能体的一轮工具调用可能持续几十秒，必须把 gRPC 的 deadline 设置得足够长，同时做好幂等控制。我的做法是为每次调用生成一个 request_id，服务端处理完结果后缓存起来，重复请求直接返回缓存结果，避免同一工具执行两遍。

3.4 安全边界：工具调用的权限收敛

智能体训练中最让人头疼的是模型自己生成的代码，它可能开一个无限循环、删掉某个关键目录、监听一个端口，甚至尝试读取宿主机的环境变量。权限收敛不能靠事后补，要在沙箱设计时就做好。

第一层限制是账号和权限。沙箱内进程用非 root 用户运行，文件系统挂载为只读，只有工作目录可写。第二层是命令白名单。不要在镜像里安装完一堆工具后不做任何限制，而是根据任务需要，显式列出允许执行的命令。第三层是网络策略。沙箱内的 agent 默认无法访问外部网络，只有任务声明了egress_allow才能访问特定域名或 CIDR。

端口监听问题要多说一句。我碰到过 agent 在沙箱里启动 HTTP 服务，然后另一个任务扫描端口把它当成了训练目标的先例。后来我直接禁止沙箱内监听 0.0.0.0，任何临时服务只能通过 Unix socket 暴露，训练器进程和沙箱通过固定的 socket 文件通信。

资源配额是最后一道防线。每个沙箱的 CPU、内存、磁盘都要设硬限制，进程数也要限制。Linux 的 cgroup和 ulimit 是现成的工具，不要嫌麻烦，用完这些确实能挡住大部分模型生成代码引发的安全事故。

4. 实操过程：从零搭建一套 DSec

4.1 基础设施准备：K8s 集群与 GPU 资源池

DSec 的底座是 Kubernetes。我在搭建时把节点分成两类：GPU 节点池运行 DeepSeek 推理服务，CPU 节点池运行不需要 GPU 的工具执行沙箱。为什么要分离？因为 GPU 节点很贵，如果被 CPU 密集型的工具任务占满，推理延迟会飙升，训练质量直接受影响。

GPU 节点需要提前安装 NVIDIA 驱动和 device plugin。更建议用 GPU Operator 统一管理，省去手动配置的麻烦。存储方面，我用 NFS 作为共享存储池，所有任务卷都建在上面，这样智能体的状态文件可以在不同节点间平滑迁移。

如果你只有一台物理机，也可以先用 Docker Compose 搭一个简易版本，控制面、Redis、一个沙箱容器跑在一台机器上，验证流程后再上 K8s。心急吃不了热豆腐，先跑通再扩容是比较稳妥的做法。

4.2 构建智能体训练沙箱镜像

沙箱镜像的核心要素是推理环境加工具环境。我这里给一个可参考的 Dockerfile 片段，具体版本号按自己的模型和依赖更新：

FROM nvidia/cuda:12.1.1-runtime-ubuntu22.04 ENV DEBIAN_FRONTEND=noninteractive \ PIP_CACHE_DIR=/tmp/pip-cache RUN apt-get update && apt-get install -y \ python3.10 python3-pip git curl bash \ sqlite3 jq && \ rm -rf /var/lib/apt/lists/* RUN pip install --no-cache-dir \ vllm==0.4.2 \ transformers==4.40.0 \ fastapi==0.111.0 \ httpx==0.27.0 \ pydantic==2.6.0 COPY --chown=nobody:nogroup ./tools /opt/dsec-tools COPY --chown=nobody:nogroup ./sandbox-entrypoint.sh /sandbox-entrypoint.sh RUN chmod +x /sandbox-entrypoint.sh USER nobody ENTRYPOINT ["/sandbox-entrypoint.sh"]

镜像构建完成后推送到私有镜像仓库，然后记得在 K8s 节点上预热镜像。如果你不想提前拉，也可以用拉取策略IfNotPresent，但这会导致第一个任务冷启动很慢，后面再说。

4.3 配置弹性伸缩与任务调度

任务调度我推荐用一个独立的 Scale Controller 实现，比单纯依赖 K8s HPA 更可控。Controller 每隔几秒读取一次 Redis 里的任务队列长度，根据前面提到的公式计算期望沙箱数，然后调整对应 Deployment 的副本数。

K8s Deployment 配置里有个细节值得注意：资源 requests 和 limits 不要设成一样。requests 设置得稍微低一点，让调度器能把任务塞进节点，limits 设置得严格一些，防止沙箱爆炸影响到邻居。GPU 的 requests 倒是必须精确，否则一个节点被多个假请求超卖，推理任务会直接 OOM。

网络策略必须默认拒绝，然后单开一个 namespace 存放 DSec 组件，通过 NetworkPolicy 允许训练面访问控制面，允许控制面访问沙箱实例，其余全部关闭。这一步做踏实了，后面几乎不会出网络事故。

4.4 训练框架接入：以 Ray 为例

Ray 是我用得比较顺手的分布式训练框架。接入 DSec 的方式很简单：在 Ray 的 Actor 里实例化一个 DSec 客户端，每个训练轮次向控制面提交任务。

import ray from dsec.client import SandboxClient @ray.remote class AgentTrainer: def __init__(self, endpoint="localhost:50051"): self.client = SandboxClient(endpoint) def train_one_rollout(self, task_spec): sandbox = self.client.create_sandbox(task_spec) result = sandbox.execute("python run_trajectory.py") return self.client.collect_trajectory(sandbox.id)

这里有个很关键的实践：不要一个沙箱对应一个 Actor 再长时间持有。我把沙箱设计成"单任务生命周期"，训练器每次推进一步都从控制面获取最新地址，上一个沙箱不回收，而是由控制面根据 idle 超时自动销毁。这样避免了任务卡在某个沙箱上导致资源泄漏。

如果你用的不是 Ray，而是自研的训练框架，只需要实现创建沙箱、提交指令、获取结果、异常重试这几个接口，就能平滑接入 DSec。

4.5 监控与日志采集：把每个沙箱变成可观测单元

监控这一块我吃了不少亏，最开始以为训练任务跑起来能出结果就行，直到有一次某个智能体在凌晨三点疯狂生成日志，把整个 ES 集群磁盘塞满，我才意识到可观测性必须前置。

每个沙箱启动时自动注册到 Prometheus，暴露几个关键指标：任务启动时间、推理 token 数、工具调用次数、超时次数、沙箱退出码。这些指标足以支撑资源伸缩和异常诊断。

日志统一输出为 JSON 格式，每个字段都带上 task_id 和 sandbox_id，采集到 Loki 后按任务维度聚合。重点记录四类事件：

• 推理请求的开始和结束，包括输入 token 数、输出 token 数、耗时。
• 每次工具调用的命令、参数、退出码和标准输出摘要。
• 网络请求的目标地址和返回状态。
• 沙箱被 OOMKill 或被强杀时的完整堆栈和内存快照。

有了这些日志，排查问题就等于做 SQL 查询，而不是靠肉眼翻容器 stdout。这个改造救了我无数次。

5. 常见问题与排查技巧实录

5.1 沙箱冷启动慢到让人崩溃

现象是任务提交后要等两三分钟才能开始跑，高峰期排队更严重。排查后找到三个瓶颈：镜像体积大、模型权重冷缓存、每个沙箱都重复初始化同一套依赖。

解法分三步。第一，用镜像预拉策略，K8s 节点启动时就把常用沙箱镜像拉好，不要等任务到达才去拉取。第二，模型权重缓存到节点本地 SSD 上，通过 DaemonSet 定时预热，沙箱挂载时直接读本地文件，不穿透 NFS。第三，把 Python 依赖的 pip 缓存层烧进镜像，不要在容器启动时临时装包。

做好这三步之后，我的实测冷启动时间从 170 秒降到了 30 秒以内，基本上符合"有任务就能跑"的心理预期。

5.2 GPU 利用率上不去的真实原因

智能体训练的 GPU 利用率天然比传统训练低，因为每个轨迹要等待工具执行结果，推理进程大部分时间在空转。提升利用率有两个思路。

一个思路是提高单次推理的 batch size。同一时间到达的不同智能体请求可以拼成一个 batch，vLLM 的 continuous batching 做得很好，可以把它当成一个共享推理池，多个沙箱通过同一个推理服务发送请求，而不是每个沙箱独立拉起一个推理进程。

另一个思路是调度级别的聚合。把当前活跃任务尽量调度到同一个 GPU 节点的几个沙箱里，这样可以共享 L2 缓存和 CPU 资源，减少跨节点通信。实测下来，共享推理池的方式能把单卡利用率从 30% 提到 70% 左右。

5.3 智能体工具调用把沙箱搞挂

最经典的事故是 agent 写了个死循环：while True: os.fork()。这个调用几秒钟内就把宿主机进程数打到上限，整个节点上的沙箱全被连坐。

排查后加固了四层。第一层是资源限额，每个沙箱限制最大进程数为 128，超过直接 OOMKill。第二层是命令白名单，不再允许 agent 随便执行未注册的 Python 代码。第三层是超时控制，任何工具调用超过 120 秒直接杀掉进程并返回超时错误。第四层是在沙箱入口包了一层 wrapper，只暴露一个经过校验的执行接口，所有命令必须先通过参数解析器才能进入 shell。

5.4 日志与轨迹数据爆炸

一次全量训练跑下来，轨迹原始日志轻松到几个 TB。直接保存原始 IO 既贵又难查，所以我在日志管线里加了分级采样策略。

这里的关键心得是：不是所有数据都需要高保真。训练调参要看的是奖励曲线和任务成功率，模型分析要看的才是个别轨迹的完整细节。分级之后，存储成本降了约 70%，查询体验反而变好了，因为小表查起来快得多。

5.5 网络策略导致任务互相踩脚

还有一次事故是两个智能体任务在不同沙箱里同时启动了一个 HTTP 服务，一个监听 8080，一个监听 8081，本不该互相影响。但其中一个 agent 在工具调用时硬编码了另一个沙箱的 IP 地址，尝试拉取它的数据。当时如果没有 NetworkPolicy 兜底，这个任务可能已经把另一个任务的中间结果偷走了。

所以网络策略不能只写在文档里，必须落到 K8s 资源上。默认的隔离规则是：沙箱内禁止一切入站连接，出站只允许控制面和训练面的固定服务端口。如果某个任务确实需要访问外部 API，必须由任务描述文件显式声明，控制面校验后才在 NetworkPolicy 中放行。训练中后期再想临时改白名单，一定要走审批流程，否则改着改着就把隔离墙打穿了。

写在后面

最后说点未必专业但非常真实的心得。DSec 这个东西，不是把几套开源软件拼起来就完事，真正的价值在于把智能体训练的长期主义内建到基础设施里。我最后悔的是最初没把可观测性往前放，日志体系是后补的，补得相当痛苦。如果你也在搭类似的系统，不管规模多小，第一天就把所有沙箱事件的 trace 埋好、把每个任务的版本钉死，后面会少掉无数个深夜。另外，沙箱方案不要一上来就追求最强隔离，先把 Docker 层跑通，再把不可信代码逐步下沉到 gVisor，这样每一步都可验证，不至于一次改动引入一堆新问题。做基础设施的人，稳比炫技值钱。