scheduler
image distribution
storage
CPU
memory
network
全部瞬间被打爆。
---
# 问题二：Sandbox 并不一直吃 CPU
这个特别重要。
一个 Agent 的生命周期：
LLM 思考
↓
sandbox idle
LLM 生成 action
↓
sandbox CPU burst
↓
执行 command
↓
sandbox idle
LLM 再思考
↓
sandbox idle
...
因此：
CPU utilization
████░░░░░░░░░░░░░░░░
但是：
memory
████████████████████
因为：
* 文件还在那里
* Python process 还在那里
* cache 还在那里
* service 还在那里
* guest memory 还在那里
论文观测到 container / microVM 的 median lifetime 分别约 **17.4 / 15.5 分钟**，p99 超过 3 小时。([arXiv][1])
所以 Agent Sandbox 有一个非常反直觉的性质：
> CPU 很闲，但 memory 很贵。
这直接导致 DSec 必须做：
CPU overcommit
+
memory sharing
+
memory reclamation
---
# 问题三：Sandbox 的 image 根本不是几个
Production 一周：
Container:
11,266 base images
102,171 workspaces
MicroVM:
2 base images
53,590 workspaces
4,889 snapshots
总 artifact 超过 **130 TB**。([arXiv][1])
而且 image fanout 非常低。
也就是说：
image-A → 3 个 sandbox
image-B → 2 个 sandbox
image-C → 1 个 sandbox
image-D → 28 个 sandbox
而不是：
image-A → 10000 sandbox
因此传统：
registry
↓
pull entire image
↓
unpack
↓
local disk
↓
start
非常浪费。
---
# 更狠的问题：Agent 根本不会读完整个 image
论文统计：
| 语言 | Image Size | 实际访问 |
| ---------- | ---------: | ----: |
| C++ | 4.9 GB | 8.7% |
| Go | 4.1 GB | 13.3% |
| Java | 12.1 GB | 9.2% |
| JavaScript | 9.6 GB | 4.2% |
| Python | 6.0 GB | 6.0% |
也就是说：
> 你给 Agent 一个 6GB Python image，它可能只真正访问 360MB。
([arXiv][1])
这就是 DSec 后面 EROFS + 3FS + on-demand loading 的根本原因。
---
# 所以 DSec 的真正问题定义
把上面全部压缩一下：
Agentic RL
│
├── massive burst
│
├── stateful
│
├── long-lived
│
├── sparse CPU
│
├── memory-heavy
│
├── heterogeneous isolation
│
├── huge image corpus
│
├── low image reuse
│
├── only tiny fraction of image accessed
│
├── agents are untrusted
│
└── training jobs can be preempted
所以 DSec 不是：
> “一个更快的 Docker。”
而是：
> 针对 Agentic RL workload 特征重新设计的 distributed sandbox execution platform。
这个定位非常重要。
---
# 第三课：DSEC 到底有几层？
现在进入系统架构。
论文的实际架构可以拆成：
libdsec
│
▼
┌────────────┐
│ API Server │
└─────┬──────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
IAM Placement Watcher
│
▼
┌────────────┐
│ Edge │
│ per host │
└─────┬──────┘
│
┌─────────┼──────────┐
▼ ▼ ▼
FnCall Container MicroVM / VM
│
Aether
│
Chronus
│
sandbox process
再下面：
3FS
│
┌─────────┴─────────┐
▼ ▼
EROFS OverlayBD
│ │
container microVM
---
# 1. libdsec
这是用户看到的入口。
例如论文给的接口：
client = DSecClient()
await client.open()
args = DSecContainerRunArgs(
container_image="...",
memory_limit_mb=4096,
cpu_cores_limit=4,
ttl_running_stop=300,
network_rules={
"npm": False,
"pypi": True
},
init_user="root",
)
sandbox = await client.run_container(args)
result = await sandbox.run_shell(
"echo hello world"
)
await sandbox.stop()
([arXiv][1])
所以从 Agent Harness 的角度：
Agent
│
│ create sandbox
▼
libdsec
│
▼
DSec
---
# 2. IAM
负责：
Authentication
Authorization
Quota
Project
Sub-project
Resource limit
特别有意思的是：
> Agent 和 Human 使用同一个 management API / authorization model。
而且 project 可以嵌套：
Project A
│
├── quota = 1000
│
├── Agent Project
│ ├── quota = 300
│ └── permissions
│
└── Research Project
└── quota = 700
子项目不能突破父项目权限和 quota。([arXiv][1])
这其实是在解决：
