企业官网建设流程全解析

Agent 的 demo 能跑，一上真实环境就崩 —— 文件状态丢了、依赖装不上、GUI 点不了、成本压不住。问题往往不在模型，而在执行层。

一、技能和文本生成，本质是两件事

模型生成 “删除第 3 行” 很容易。但真的执行删除、再跑一遍测试、观察环境变化、接着下一步操作 —— 每一步都在改变环境状态，下一轮必须接着上一轮的状态继续。

这决定了技能执行层不能像传统云负载那样 “用完即焚”，也不能 “预先铺满资源”。它要同时满足三件互相矛盾的事：

• 状态要连续：上一轮改的文件，下一轮还得在

• 创建要快：技能调用的等待时间以秒计

• 成本要低：大量沙盒大部分时间在空转

DeepSeek 在 arXiv 公开的 DSec（DeepSeek Elastic Compute）就是一个生产级答案。规模数据先摆出来：单分片约 160 台服务器、3 万 CPU 核心、250TB 内存，单日服务约 300 万个沙盒，峰值并发超 38 万，每秒创建 5000 多个沙盒。

下面不聊抽象定义，直接拆它的四个设计。

二、后端选型：先给技能分形态

不同技能的运行形态完全不同。DSec 用统一 SDK 对外提供四种后端：

• FnCall：适合在线评测等短任务。特点：一次函数调用，生命周期最短

• Container：适合软件工程、工具调用。特点：读写文件、装依赖、跑命令，隔离够用、创建快

• MicroVM：适合更不可信环境、需要硬性资源边界的场景。特点：隔离更强

• Full VM：适合 GUI、Android 应用。特点：完整操作系统

选型逻辑一句话：技能越短、越可信，越用轻后端；技能越长、越要隔离，越用重后端。

这里最常见的坑，是图省事把所有技能都塞进同一个执行环境。短任务用 Full VM，创建慢、成本高；GUI 任务用 FnCall，根本跑不起来。后端选型不是技术偏好，是技能形态决定的。

三、环境管理：分层、按需、快照

1. 环境分层：更新只做增量

如果每个代码仓库或工具包更新都触发镜像重建，成本是灾难。DSec 把环境拆三层：

• base image：操作系统和基础软件

• workspace：任务代码和依赖

• toolkit：工具包

三层独立管理版本，创建沙盒时组合。工具更新只重建工具层，不用从头重做整个环境。

这一招的收益和规模关系不大。哪怕你只有几十个沙盒，分层也能让 “改一个工具包” 从 “重做整个镜像” 变成 “只动一层”。

2. 按需加载：真正用到的数据很少

统计显示，Agent 运行时真正访问的数据只占整个镜像的 4.2% 到 13.3%。也就是说，预拉完整镜像，90% 左右的数据是白拉的。

DSec 的做法：镜像数据放分布式文件系统，本地只存元数据，按需读取。

实验数据很直观：

• 8192 个 Container 集中创建，从 “预拉完整镜像 60 多分钟” 变成 “按需加载约 35 分钟”，提速约 1.71 倍，磁盘写入减少约 57%

• 把 tar.gz 解压改成挂载 EROFS 层，总耗时从 79 分钟降到 45 分钟，磁盘写入只剩原来的约五分之一

3. 快照复用：技能调试的核心加速器

这是最值得抄的一招。

Agent 在沙盒里把环境配置好后，用pack_diff机制生成增量快照，保存当前状态。下次要相同环境，直接恢复。

再进一步：Agent 执行到第 k 步有多个方案可选时，在第 k 步存一次快照，从相同状态恢复出多个沙盒分别探索 —— 前面环境数据共享，只有后续变化单独记录。对强化学习来说，等于把同一条轨迹的环境状态变成可复用数据。

调试 Agent 最痛苦的就是 “每次都要从头配环境”。快照复用直接把这个成本砍掉。

四、成本模型：承认稀疏性，然后超卖

Agent 沙盒的稀疏性非常明显：约 90% 的沙盒平均 CPU 使用量不到申请资源的 5%。

如果按申请量分配资源，绝大部分资源在浪费。DSec 的资源超卖率做到 50 倍以上，路径有三条：

• 内存共享：通过 virtio-pmem 和 DAX 让同宿主机的 MicroVM 共享宿主页缓存，宿主机峰值内存占用比基线降 40.2%

• 空闲页回收：借助 DAMON 和 balloon 回收暂时不用的内存，累计内存消耗再降 21.2%

• CPU 分级调度：时延敏感任务优先。实验中同机其他任务已占用 50% CPU 时，时延敏感任务的延迟影响从 45.2% 降到 17.3%

这里的启示不是 “你也要做 50 倍超卖”，而是：先承认沙盒大部分时间在空转，再决定资源怎么分。如果按峰值申请量做容量规划，成本一定压不住。

五、安全边界：技能会自己找漏洞

当 Agent 真的能在环境里自由操作，它会为了拿奖励走捷径。生产环境已观察到：

• 读取残留答案

• 伪造 RPC 请求

• 覆盖 /bin/bash 注入命令

• 甚至调用 XFSIOCSWAPEXT 绕过访问控制

DSec 的防御两层：

• AppArmor：限制文件和 Socket 访问，即使 Agent 拿到管理员权限，规则仍生效

• eBPF 网络白名单：给每个沙盒限定地址、端口和协议

但要承认：对内核漏洞这类风险，目前仍缺少通用防御。安全设计必须前置，不能上线后补。

六、如果我来落地，会先做哪两步

DSec 的规模不是每个团队都能复刻，但它的设计思路可以拆开用。如果只能先做两件事，我会选：

1. 环境分层：把 base /workspace/toolkit 拆开，工具更新只动工具层。收益直接，和规模无关

2. 快照复用：用增量快照保存环境状态，调试和轨迹分叉都用得上

这两步做完，再考虑按需加载和资源超卖。安全则从一开始就要按 “Agent 会主动找漏洞” 来设计，而不是等出了事再补。