kvcache-ai/AgentENV

一句话定位： 把「跑 agent 环境」做成可调度、可快照、可 fork 的分布式平台——用 Firecracker microVM + 自研 OverlayBD/ublk 块存储，在有限本地盘上支撑百万级镜像与快照。由 Moonshot AI（Kimi）与 KVCache.ai 联合开发，承载 Kimi K3 的 agentic RL 后训练。

归属澄清（易混淆）： AgentENV 不是 DeepSeek 的项目。DeepSeek 的 DSec 是另一套内部沙箱平台（未开源），两者只是共用同一套 Rust OverlayBD/ublk 存储库——DeepSeek 对该存储库有贡献，并在 DSec 论文里指向 AgentENV 的 storage/overlaybd 作为开源地址，因此容易被误认为同源产品。参见 2609.22978_deepseek-elastic-compute-dsec。

为什么值得关注

1. 这是生产系统，不是 demo，且开源归属清晰

README 与 Kimi K3 开放日公告直接定位为 “powering agentic RL training for Kimi K3”，由 Moonshot AI（Kimi）与 KVCache.ai 联合开发，随 Kimi K3 权重/技术报告一并开源。要解决的是「一天跑几百万沙箱、峰值几十万并发」的规模问题，而不是给单个 agent 挂个 shell。

它与 DeepSeek 的 2609.22978_deepseek-elastic-compute-dsec（DSec）属于同一类基础设施、同一套 Rust OverlayBD/ublk 存储技术栈，但是两个不同团队的不同系统：DSec 未开源，AgentENV 是公开可用的那个。

2. 存储子系统是真正的护城河，不是 VM 封装

多数沙箱平台只是把 Firecracker 包一层。AgentENV 的重心在 storage/：自研 OverlayBD 分层镜像格式（LSMT）、ublk 用户态块设备、ublk-daemon、共享 io_uring 抽象。核心收益是 README 里的两条硬指标：

生产环境 150 万镜像，靠 overlaybd 按需加载 + 本地盘做有界缓存（热数据留下、冷数据淘汰），聚合镜像/快照体积可以比本地盘大几个数量级，不需要预热每台主机
存储与内存快照数据共享宿主机 page cache，内存 ballooning 让生产 内存超分比达到 9.6x，环境跑久、状态发散后仍能维持密度

3. 快照/fork 延迟压到了交互级

快照驱动启动或恢复 < 50 ms，暂停 < 100 ms
内存 + 文件系统增量快照 < 100 ms，磁盘大量修改场景也成立
运行中的环境可以直接 fork 出多个独立沙箱，给并行 agent workflow 用
快照落 S3 兼容对象存储或共享分布式文件系统，不丢数据

这组数字意味着「每个 RL episode 一个全新 microVM」在成本上可行——docs/src/use-cases/miles.md 就是每个 episode 起一个 microVM 跑 Terminal-Bench-2 的真实配方。

4. 内存快照恢复改成了 ublk，而不是 userfaultfd

resume 时不为内存快照起一个 userfaultfd handler，而是建一个只读 ublk 设备喂给 Firecracker 作为 BackendType::File 内存后端，Firecracker mmap 该块设备、首次写时 COW 到匿名内存。同一快照模板启动的多个沙箱引用计数共享同一个内存 ublk 设备，page cache 复用，并发启动 I/O 大幅下降。旧方案 storage/uffd-core/ 保留为参考实现但已排除出 workspace。

5. E2B 兼容 API，接入成本接近零

暴露 E2B 兼容 HTTP API，把 E2B_API_URL 指向 AgentENV，官方 E2B Python/TypeScript SDK 不用改代码。对已有 E2B 生态的 agent 评测/训练框架（Harbor、Miles/OpenEnv 等）是顺手就能换的沙箱后端。

核心概念

概念	定义	关系
Template	可复用的命名起点，从 OCI 镜像或 Dockerfile 构建	构建产物落在底下的 committed snapshot
Sandbox	正在运行的隔离 Linux 环境（Firecracker microVM）	由 template/snapshot 启动；工具在内部执行
Snapshot	从运行沙箱捕获的持久化 checkpoint（内存+FS+卷+配置）	可反复启动出新沙箱；fork 的来源
Volume	独立管理的块文件系统，可跨沙箱删除存活	`exclusive` 单写挂载 / `ro` 共享只读挂载

工作流：OCI image / Dockerfile → template → sandbox → snapshot → 新 sandbox。aenv start --cold 也可以直接从 OCI 镜像冷启动。

技术架构

单节点（Rust workspace）

Axum API + 反向代理（HTTP/SSE/WS）
  └── Orchestrator（生命周期状态机 + auto-eviction + 指标）
        ├── Firecracker microVM
        │     ├── /dev/vda rootfs  ──┐
        │     ├── /dev/vdb extra      ├── ublk（/dev/ublkbN，用户态块设备）
        │     └── VM memory ──────────┘        └── overlaybd（LSMT 分层镜像）
        ├── envd（guest 内命令执行/文件操作/健康上报）
        ├── Snapshot Manager / Template Builder（快照提交、解析、删除）
        └── P2P artifact transport（iroh / 可禁用）

存储四件套：

组件	路径	职责
overlaybd	`storage/overlaybd/`	LSMT 分层镜像格式：不可变压缩只读层 + 单个可写 upper；zstd + 随机访问跳表 + CRC32C；后端可插拔（LocalFile/OCI registry/tar）
ublk	`storage/ublk/`	用 Linux ublk 驱动把 overlaybd 镜像暴露成 `/dev/ublkbN`；`AutoRegBuffer` 零拷贝（kernel 6.8+）
ublk-daemon	`storage/ublk-daemon/`	单进程管所有 ublk 设备，通过 Unix socket RPC 与节点通信；远端 I/O 走独立 runtime
storage-util	`storage/util/`	共享 io_uring 抽象（`AsyncIoRing`/`IoRingWorker`/`ReloadableIDAllocator`）

暂停路径 = ImageFile::create_snapshot_and_restack()：把 live upper seal 成最新 lower，再原地开新的可写 upper。内存快照则查 Firecracker dirty/present range，用 process_vm_readv 读出，直接写成 OverlayBD memory layer，父层堆叠成完整分层内存镜像。

多节点控制面（Go，`services/`）

Client → Gateway(:8080) ──gRPC──→ Scheduler(:9090)
             └── HTTP proxy ──→ Node A/B(:8000)

Gateway：HTTP 反向代理；从 header（x-agentenv-sandbox-id/e2b-sandbox-id）或 host-based 域名解析数据面路由；新建沙箱调 Schedule() 选节点，已有沙箱调 LookupNode()
Scheduler：gRPC，可插拔节点发现（static / kubernetes EndpointSlice）、内存 sandbox→node 绑定、心跳上报节点快照；策略 round_robin（默认）/random
已知限制：绑定全在内存，scheduler 重启后靠新建沙箱 + 下次心跳重建，不做副本持久化

节点以 privileged DaemonSet 运行（每主机一个 runtime Pod，带 /dev/kvm、iptables/netns 权限、hostPath 缓存）。

按需加载与 P2P

本地盘 = 有界缓存：保留热数据、淘汰冷数据，聚合 footprint 可远超本地盘容量
共享存储两种后端：POSIXFS（snapshot_store）与 OSS（S3 兼容，含 Alibaba OSS / R2 / Tigris），snapshot.repository_backend 选择
P2P artifact transport 抽象在 src/p2p/，首个后端是基于 iroh + iroh-blobs 的内容寻址传输（见 iroh）；scheduler 只存 artifact→node 提示，不存元数据也不代理字节
数据来源仍是仓库：P2P 是加速路径，publish 失败不回滚已提交的 snapshot record；OSS 解析 P2P-first，POSIX 不消费 P2P（路径本身已可直接访问）

使用方式

# 安装 server + CLI（或 Docker 一键起）
curl -fsSL https://raw.githubusercontent.com/kvcache-ai/AgentENV/main/scripts/install.sh | sudo bash
sudo systemctl start aenv
 
# 首次启动生成 API key，认证
sudo cat /var/lib/aenv/secrets/api-key
aenv auth
 
# 拉模板 → 起沙箱
aenv pull ubuntu:22.04 --name ubuntu
aenv start ubuntu            # 启动并 attach 交互 shell
aenv start ubuntu --detach   # 只启动，打印 sandbox ID
 
aenv exec <id> ls -la /
aenv pause <id> && aenv resume <id>
aenv snapshot create <id> --name checkpoint
aenv delete <id>

环境要求：Linux kernel 6.8+、/dev/kvm。无标准 KVM 的服务器走 PVM 部署（x86_64 + host kvm_pvm 模块）。KVM 是默认模式。

与相邻方案的定位

方案	层级	与 AgentENV 的关系
harbor	评测/rollout 编排	Harbor 负责 task × agent × verifier；AgentENV 是可插的沙箱执行后端之一
cloudflare-computer	Agent 虚拟电脑 SDK	Computer 是 Serverless/Durable Object 路线，轻量原型；AgentENV 是 microVM + 块存储，面向训练规模
2609.22978_deepseek-elastic-compute-dsec	另一团队的同类生产系统论文	DSec 是 DeepSeek 内部平台（未开源，来源自报）；两者同用 Rust OverlayBD/ublk 存储栈但非同一产品，AgentENV 是其中开源的实现

局限与注意

强 Linux 依赖：需要 kernel 6.8+、/dev/kvm、ublk、netns；macOS 上只能装 CLI 连远端 server，不能跑节点
API key 不加密传输：官方明确警告认证不等于加密，生产必须放到可信网络或自建 TLS 终止
多节点绑定不持久化：scheduler 重启会丢绑定，靠心跳/新建重建，长周期生产部署要接受这个窗口
文档/接口仍在快速演进：仓库 2026-07 才创建，两个月内已有大量模块，跟进时以 docs 站 latest/dev 为准
存储复杂度高：OverlayBD 二进制格式、ublk、io_uring 都不是容易改的部分，二次开发门槛集中在 storage/
生产数据来自厂商自报：150 万镜像、9.6x 超分、<50ms 恢复等指标来自仓库 README / Kimi K3 技术报告（Moonshot AI + KVCache.ai），无独立复现

资源

仓库：https://github.com/kvcache-ai/AgentENV
文档：https://kvcache-ai.github.io/AgentENV/latest/
Kimi K3 技术报告：https://github.com/MoonshotAI/Kimi-K3
架构文档：docs/src/internals/architecture.md、docs/src/internals/p2p-design.md
训练配方：docs/src/use-cases/miles.md（Miles + OpenEnv + Terminal-Bench-2 GRPO）
本地 clone：~/6ai/opensources/AgentENV

zhaoweiguo 的知识库

目录

kvcache-ai/AgentENV

为什么值得关注

1. 这是生产系统，不是 demo，且开源归属清晰

2. 存储子系统是真正的护城河，不是 VM 封装

3. 快照/fork 延迟压到了交互级

4. 内存快照恢复改成了 ublk，而不是 userfaultfd

5. E2B 兼容 API，接入成本接近零

核心概念

技术架构

单节点（Rust workspace）

多节点控制面（Go，`services/`）

按需加载与 P2P

使用方式

与相邻方案的定位

局限与注意

资源

相关页面

关系图谱

目录

反向链接

zhaoweiguo 的知识库

目录

kvcache-ai/AgentENV

为什么值得关注

1. 这是生产系统，不是 demo，且开源归属清晰

2. 存储子系统是真正的护城河，不是 VM 封装

3. 快照/fork 延迟压到了交互级

4. 内存快照恢复改成了 ublk，而不是 userfaultfd

5. E2B 兼容 API，接入成本接近零

核心概念

技术架构

单节点（Rust workspace）

多节点控制面（Go，services/）

按需加载与 P2P

使用方式

与相邻方案的定位

局限与注意

资源

相关页面

关系图谱

目录

反向链接

多节点控制面（Go，`services/`）