智能体平台还有一条很容易被忽略的链路：沙箱
从 DeepSeek 公开的 DSec 沙箱基础设施出发，聊聊企业智能体平台里那条容易被忽略的链路——Sandbox：它的启动风暴、并发口径、隔离边界，以及我们现在该怎么测。
前几天刷到一个视频，讲的是 DeepSeek 最近公开的 DSec（DeepSeek Elastic Compute）。
视频标题里最显眼的是一个数字：38 万个 Agent 同时运行。
一开始我也以为重点是"DeepSeek 怎么把几十万个 Agent 跑起来"。
但后来看了下它背后的论文，我反而开始关注另一个问题：
这些 Agent 到底运行在哪里？
现在很多 Agent 已经不是简单地"调用一次大模型，然后返回一段文字"了。
它可能要读文件、生成 PPT、执行 Python、分析 Excel、操作浏览器、下载依赖，甚至临时启动一个服务。
这意味着一个智能体任务的背后，除了模型推理，还开始多出另外一个东西：执行环境。
而很多平台为了避免 Agent 生成的代码直接运行在宿主机上，都会选择在任务执行过程中动态启动一个 Sandbox。
我们最近也在做类似的智能体平台，这里面同样存在沙箱启动的动作。所以看完 DeepSeek 这篇论文后，我越来越觉得：
对智能体平台来说，Sandbox 可能不是一个简单的安全组件，而是未来性能、稳定性和安全性都会经过的一条关键链路。
这块可能也需要开始认真测了。
一、以前性能测试主要盯模型，现在链路已经变了
传统大模型应用的性能链路相对容易理解。
大体就是：
用户请求 → 应用 → 模型 → 返回结果
所以我们通常关注：
- TTFT
- TPOT
- Token/s
- 模型并发
- 请求排队时间
- 端到端响应时间
但 Agent 出来以后，链路明显变长了。
比如一个"帮我分析这个 Excel，然后生成一份报告"的任务，实际可能变成：
用户请求
↓
模型理解任务
↓
决定调用 Python
↓
创建 Sandbox
↓
准备 Python 环境
↓
挂载用户文件
↓
执行 Python
↓
读取执行结果
↓
模型继续推理
↓
再次执行工具
↓
生成最终结果
所以我现在越来越倾向于把 Agent 的一次请求理解成：
模型推理 + 环境准备 + 工具执行 + 多轮模型调用。
也就是说：
End-to-End Latency = 模型时间 + 沙箱等待时间 + 沙箱启动时间 + 环境准备时间 + 工具执行时间 + 多轮编排时间
这里有一个问题很容易被忽略。
我们可能花了很大精力把模型的 TTFT 从 15 秒优化到 8 秒，结果用户点了一次"数据分析"，Sandbox 创建和初始化用了十几秒。
对于用户来说，还是卡住了。
所以以后评价一个 Agent 平台"快不快"，可能不能只看模型 TTFT。
图 1 · 一次 Agent 请求完整执行链路：模型推理与沙箱/工具执行共同构成端到端延迟
二、DeepSeek 的数据让我注意到了一个很反常识的现象
DSec 是 DeepSeek 为大规模 Agent 训练和评测建设的一套沙箱基础设施。
一个生产规模单元大约 160 个节点，每天运行约 300 万个 Sandbox，生产环境峰值超过 38 万个并发 Sandbox，创建速度超过 5000 个/秒。
当然，这个规模和普通企业智能体平台完全不是一回事。
DSec 主要面对的是 Agentic RL 训练和评测，不能简单拿"38 万并发"来推导企业 Agent 应该怎么建设。
但论文里面有几个数据，我觉得非常值得做 Agent 平台的人注意。
其中一个是：
大约 90% 的 Container 和 microVM Sandbox，平均 CPU 使用率不超过申请 CPU 的 5%。
为什么？
因为 Agent 的运行方式本身就是断断续续的。
它可能：
思考一下 → 执行一条命令 → 等模型 → 再执行 → 再等模型。
所以 Sandbox 大部分时间其实在"等"。
但问题在于：
CPU 虽然没怎么用，Sandbox 不能销毁。
因为里面可能已经：
- 解压了附件；
- 修改了文件；
- 安装了 Python 包；
- 生成了临时文件；
- 启动了某个进程；
- 保存着当前 Agent 的执行上下文。
DeepSeek 的数据里，Container Sandbox 的中位生命周期达到 17.4 分钟，microVM 是 15.5 分钟，而 P99 都超过了 3 小时。
这就形成了一个很有意思的资源模型：
CPU 使用是脉冲式的，但内存、文件和状态却是持续占用的。
这和传统 Web 应用很不一样。
三、这会直接改变我们对"并发"的理解
以前做系统性能测试，我们习惯问：
这个系统能支持多少并发请求？
但 Agent 平台可能还得再问一个问题：
这个系统能同时养着多少个 Sandbox？
比如某个时刻有 100 个用户正在使用 Agent。
真正执行 Python 的可能只有 10 个。
但后台可能还存在：
- 70 个等待下一轮模型推理的 Sandbox；
- 20 个正在执行工具的 Sandbox；
- 10 个刚完成任务、等待 TTL 回收的 Sandbox。
所以：
Agent 并发 ≠ CPU 并发 ≠ Sandbox 并发。
这三个东西以后可能必须分开统计。
我甚至觉得，以后做智能体平台容量测试时，可以形成三个容量指标：
- Conversation Capacity —— 能同时维持多少活跃会话
- Execution Capacity —— 能同时执行多少 Tool
- Sandbox Capacity —— 能同时维持多少有状态执行环境
这三个指标之间未必是 1:1。
而真正决定平台容量的，有时候可能不是模型。
反而可能是：
内存、磁盘、镜像分发、Sandbox 数量或者调度能力。
四、还有一个容易被低估的问题：启动风暴
假设一个企业智能体平台平时只有几十个人使用。
看起来 Sandbox 启动没什么压力。
但如果上午 9 点：
200 个用户同时打开 Agent，其中一半的人上传文件，然后同时触发代码执行或者数据分析。
这时候平台面对的就不是：
100 个正常请求。
而可能是：
100 个 Sandbox 同时创建。
DeepSeek 把这种现象叫做 Bursty Demand。
他们生产环境里的单个任务甚至可能在很短时间内要求创建数千甚至数万个 Sandbox，最大的生产任务可以一次申请到 32K 个环境。
规模我们当然比不了。
但问题形态是一样的。
Sandbox 创建并不是免费的。
启动过程中可能包括：
- 调度节点；
- 分配 CPU / Memory；
- 拉取 Image；
- 创建 Container / VM；
- 初始化文件系统；
- 挂载 Workspace；
- 注入工具；
- 设置网络策略；
- 加载用户文件；
- 启动 Runtime。
这些动作都会消耗：
CPU + Disk IO + Network IO + Memory。
所以特别容易出现一种情况：
单独测一个 Sandbox：2 秒启动完成。
然后测试报告就写：Sandbox 启动时间 2 秒。
但真正上线以后，50 个一起创建：可能变成 8 秒。100 个一起创建：15 秒。200 个一起创建：开始超时。
所以我觉得 Sandbox 性能测试里非常有必要单独增加一种测试：
Sandbox Creation Burst Test。
不是测稳态 QPS。
而是测 0 → 10、0 → 50、0 → 100、0 → 200 这种瞬时启动。
看 P50、P95、P99 的 Sandbox Ready Time 怎么变化。
五、我现在反而比较担心的是安全
性能问题最终可能只是慢一点。
但 Sandbox 的安全问题要复杂得多。
很多人第一反应可能是：
"不是已经放进容器了吗？"
实际上这句话可能远远不够。
DSec 论文里有一段我觉得特别有意思。
DeepSeek 在实际运行过程中发现，Agent 会尝试：
- 查找平台日志；
- 从残留文件中寻找答案；
- 构造 RPC 请求；
- 访问 Unix Socket；
- 尝试覆盖 /bin/bash；
- 扫描网络端口；
- 访问外部代码仓库和包管理代理。
这里面有些是为了在强化学习过程中"找捷径"。
但另外一些问题甚至不是 Agent 有意攻击。
论文记录过一个例子：Agent 从根目录递归执行 grep，遍历到了 /proc，结果触发了内核 Bug，把 Kernel 搞崩了。
还有一个 Agent 执行了 yes 命令。因为输出被平台持续记录，最后产生了几十 GB 的 stdout。
这个问题对企业 Agent 平台其实非常现实。
因为我们不能默认：
模型生成的代码一定是合理的。
甚至不能默认：
模型生成的代码一定知道自己正在做什么。
所以 Sandbox 安全真正要防的，至少有两类。
第一类是：Agent 主动突破边界。
比如：网络扫描、读取敏感文件、访问系统接口、越权调用其他服务。
第二类是：Agent 无意中把系统搞坏。
比如：死循环、Fork Bomb、大量日志、磁盘写满、内存打爆、递归扫描文件系统、大量创建进程。
第二种其实可能更加常见。
六、"用了 Sandbox"不等于"安全问题解决了"
所以我现在会比较警惕一句话：
"代码已经在 Sandbox 里执行，所以是安全的。"
Sandbox 只是划了一条边界。
真正应该问的是：这条边界到底在哪里？
比如：
- Sandbox 能不能访问互联网？
- 能不能访问企业内网？
- 能不能访问 Agent 平台控制面？
- 能不能访问 Redis？
- 能不能访问对象存储？
- 能不能读取宿主机目录？
- 能不能访问其他用户 Sandbox？
- Sandbox 内是不是 root？
- 能创建多少进程？
- 最多占多少内存？
- 最多写多少磁盘？
- 日志最多允许多大？
- 生命周期结束以后数据有没有真正清理？
这些可能才是我们测试阶段真正应该验证的东西。
DeepSeek 自己也没有说"一个 Sandbox 就能解决所有问题"。
他们使用 AppArmor 对文件、Socket 权限进行控制，同时通过 eBPF 对不同 Sandbox 实施细粒度网络白名单，但论文仍然明确指出：这些措施只能解决部分问题，无法形成对所有破坏行为的通用防御。
这一点我觉得非常重要。
Sandbox 是安全边界，不是安全结论。
七、如果让我现在设计一次智能体 Sandbox 测试，我会先测这些
结合这次 DSec 的材料，我觉得我们后面做企业智能体平台测试时，可以把 Sandbox 单独拆成一个测试对象。
而不是把它藏在"Agent 功能测试"里面。
第一类：启动能力
测试：
- 冷启动；
- 热启动；
- 单 Sandbox 启动；
- 批量并发启动；
- 镜像未缓存启动；
- 镜像已缓存启动；
- 大 Workspace 启动；
- 多种 Runtime 同时启动。
至少记录 Sandbox Create P50 / P95 / P99，以及 Sandbox Ready Success Rate。
第二类：资源隔离
可以专门制造一些"坏邻居"。例如一个 Sandbox：CPU 100%；另一个：Memory 持续增长；另一个：大量 Disk IO；另一个：持续产生 stdout。
然后观察：正常 Sandbox 的执行时间是否明显恶化。
这个其实和我们以前做数据库、微服务性能测试里的资源争抢场景很像。
只不过现在：制造坏邻居的可能是 Agent 自己。
第三类：资源耗尽
我觉得至少应该有：
- CPU 打满；
- Memory OOM；
- Disk Full；
- PID Exhaustion；
- 大文件；
- 海量小文件；
- 无限 stdout；
- 无限 stderr；
- 长时间后台进程；
- 子进程未退出。
然后验证：一个 Sandbox 出问题，会不会拖垮整个节点。
这就是所谓的 Blast Radius。
第四类：网络边界
这个可能尤其重要。
至少要验证：
- Sandbox → Internet
- Sandbox → 企业内网
- Sandbox → 数据库
- Sandbox → Redis
- Sandbox → 对象存储
- Sandbox → Agent Control Plane
- Sandbox → 其他 Sandbox
哪些允许，哪些禁止。
而且最好不是只看配置。
实际从 Sandbox 里面去访问。
第五类：生命周期
包括：创建 → 使用 → 暂停 → 恢复 → 超时 → 销毁。
特别是：
- Agent 被用户主动停止以后，Sandbox 是不是还活着？
- 任务异常退出以后，Sandbox 有没有回收？
- 网络断开以后，后台进程还在不在？
- TTL 到期以后，Workspace 有没有删除？
如果这一块做不好，很容易出现所谓的 Zombie Sandbox。
这种问题短时间可能看不出来。
但系统运行几天以后，资源会越来越少。
八、可能还需要重新定义几个 Agent 性能指标
以前我们已经习惯 TTFT。
但对于有 Sandbox 的 Agent，我觉得以后甚至可以增加几个新的观测指标。
Sandbox Ready Time
从创建请求发出，到 Sandbox 可以真正执行第一条命令。
这个指标我觉得至少要有 P50 / P95 / P99。
Time To First Action
这个名字不一定是行业标准，我只是觉得可以内部这样理解。
从用户提交任务，到 Agent 第一次真正执行 Tool。
因为对于 Code Agent、Data Agent 来说，用户真正关心的可能不是模型什么时候吐出第一个 Token。
而是：它什么时候开始干活。
Active Sandbox / Active User
这个指标可以观察：一个活跃用户平均维持多少 Sandbox。
如果这个值越来越高，很可能存在 Sandbox 回收或者编排上的问题。
Sandbox Reuse Rate
有多少任务重新利用已有 Sandbox，多少任务重新创建。
这个比例会直接影响平台成本和启动延迟。
Orphan Sandbox Rate
已经没有有效 Agent Session，但是 Sandbox 仍然存活。
我觉得这个指标在长期稳定性测试里会非常有价值。
图 2 · Agent 平台的性能观察正在从 Model 扩展到 Execution Environment
九、另外一个很值得关注的是"超卖"
DeepSeek 的一个做法也很有意思。
既然大量 Sandbox 平均 CPU 使用率很低，那么完全按照申请资源 1:1 分配显然非常浪费。
所以他们做了高密度 Overcommit。
在生产中，他们观察到单节点可以稳定运行至少 3200 个 Container Sandbox 或 800 个 microVM Sandbox。这只是实际运行点，并不是所谓的平台理论上限。
但超卖一定会带来另外一个问题：如果它们突然一起醒了怎么办？
所以 DeepSeek 又把任务区分成 Latency Sensitive 和 Best Effort。
低优先级 Sandbox 在高优先级任务需要 CPU 时主动让路。
他们甚至发现，只降低调度优先级效果不够，因为 SMT 的兄弟线程还会争抢同一个物理 Core，最后又结合了 Linux Core Scheduling。
这个思路其实很值得企业 Agent 平台借鉴。
因为以后平台里的任务天然就不应该都是一个优先级。
比如用户正在等待的在线代码执行，可能是高优先级。
而后台的文件索引、预处理、批量分析，完全可以是低优先级。
这样平台容量就不一定需要按照最坏情况简单堆机器。
十、所以我现在看 Agent 平台，开始多看了一层
以前我看一个智能体平台，大概会分成：模型层 → Agent 编排层 → Tool 层。
现在我觉得还应该增加一层：Execution Layer。
完整一点可能是：
用户
↓
Agent
↓
Model
↓
Orchestration
↓
Tool
↓
Sandbox / Browser / Runtime
↓
OS / CPU / Memory / Storage / Network
当 Agent 只是聊天时，最重要的是模型。
当 Agent 开始真正执行任务以后，它其实已经开始变成一个小型分布式计算系统。
模型只是负责：决定下一步干什么。
但那个"下一步"最终还是要落到：CPU、Memory、Disk、Network 和 Process 上。
所以很多我们以前做传统系统测试时熟悉的问题：资源争抢、调度、隔离、限流、超时、重试、幂等、状态恢复、故障域……可能都会重新回来。
只不过这一次，系统里多了一个很特别的"用户"：Agent。
而且这个用户不仅调用 API。
它还会：写代码、执行命令、修改环境，并且偶尔做一些连它自己都不知道后果的事情。
这可能才是我看完 DSec 后最大的感受。
最后
"38 万个 Agent 同时运行"当然很震撼。
但对我们这种正在建设企业智能体平台的人来说，我觉得更值得关注的不是这个数字。
而是 DeepSeek 已经开始把非常多工程精力投入到一个以前很少被讨论的问题上：
如何给 Agent 提供一个可以被大量创建、可以保存状态、可以被随时回收，同时又不会把整个系统搞坏的执行环境。
这意味着 Agent 的竞争可能正在从"谁的模型更强"，慢慢扩展成"谁能把模型真正安全、稳定、高效地放进一个可以执行任务的系统里"。
对于测试也是一样。
以后我们测 Agent，可能不能只测试："它回答得对不对"。
还要开始测试："它真正动手以后，会发生什么。"
我觉得 Sandbox，就是一个很好的切入口。
图 3 · 企业智能体 Sandbox 测试地图：把沙箱从 Agent 功能细节中单独拆出来，作为独立测试对象
参考资料
DeepSeek, DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale, arXiv:2609.22978，2026 年 9 月 19 日。
论文描述的 DSec 面向大规模 Agentic RL 训练与评测，因此本文主要借鉴其负载特征、平台设计和风险案例，不直接将其容量数据等同比套用到企业在线智能体场景。
