[GH-ISSUE #117] 解读 #37

New issue

Closed

opened 2026-10-29 14:18:40 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented 2026-10-29 14:18:40 +00:00

Owner

Copy link

Originally created by @vislee on GitHub (Aug 3, 2026).
Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/117

AgentENV 完全解读：当大规模多 Agent 强化学习需要一台"快照电脑"

本文是一篇深度技术分析文章，全面介绍 AgentENV——一个专为大规模多 Agent RL 训练设计的开源沙箱运行时平台，由月之暗面（Moonshot AI）与 KVCache.ai 联合开发，2026 年 7 月随 Kimi K3（2.8T 参数开源模型）一同开源。

---

目录

1. 第一篇：什么是多 Agent RL 训练？
2. 第二篇：AgentENV 是什么？
3. 第三篇：同类产品横向对比
4. 第四篇：为什么 AgentENV 更适合多 Agent RL？
5. 总结

---

第一篇：什么是多 Agent RL 训练？

1.1 从 RLHF 到 GRPO：一个快速回顾

强化学习（Reinforcement Learning, RL）在 LLM 训练中的经典用法是 RLHF（Reinforcement Learning from Human Feedback）。典型流程如下：

基础模型 → SFT（监督微调）→ RM（奖励模型）→ RL（PPO 强化学习）

RL 阶段的核心循环（以 PPO 算法为例）：

1. 输入一个 Prompt（如"用 Python 写一个二叉树"）
2. LLM 生成一段 Response
3. 把这段 Response 放到真实环境中执行/验证
   - 代码沙箱：运行代码，看是否能通过测试用例
   - 数学题：最终计算结果是否等于标准答案
   - Agent 任务：能否完成浏览器操作、工具调用等多步流程
4. 根据执行结果计算 Reward（奖励分数）
5. 用 Reward 更新 LLM 参数
6. 回到步骤 1，不断迭代

这里第 3 步极其重要：你必须把 LLM 生成的代码/操作放到真实环境里运行，才知道它好不好。这个"真实执行环境"就是沙箱（Sandbox）。

近年来，DeepSeek 提出的 GRPO（Group Relative Policy Optimization） 逐渐成为主流。它不再需要单独的 Reward Model，而是对同一个 Prompt 采样一组（Group）输出，在组内做相对比较——谁比谁好，不需要人类标注分数。这让 RL 训练更适合大规模自动化执行。

1.2 当"一个 Agent"变成"一群 Agent"

传统的 RL 是一个 Prompt → 一个输出 → 验证 → 更新 的单线循环。

多 Agent RL 则完全不一样：

                同一个 Prompt
                      │
      ┌───────────────┼───────────────┐
      │               │               │
   Agent A         Agent B         Agent C
      │               │               │
   沙箱 1           沙箱 2           沙箱 3
      │               │               │
  执行结果 A       执行结果 B       执行结果 C
      │               │               │
  Reward A        Reward B        Reward C
      │               │               │
      └───────────────┼───────────────┘
                      │
              汇聚回训练器
                 更新参数

一个 LLM 的多个副本（或同一模型的不同采样参数）同时生成多个 Response，每个 Response 在各自独立的沙箱中执行，得到多份 Reward 信号。这些信号汇聚回训练器，用来更新模型参数。

1.3 为什么需要"多 Agent"？

原因一：探索（Exploration）

同一个 Prompt，LLM 可以生成无数种不同的 Response。哪些好、哪些差？只有都跑一遍才知道。PPO 和 GRPO 都要求对每个 Prompt 采样 N 个 completions，N 通常取值 8-64，甚至更高。N 越大，Reward 信号越可靠，但需要的并行沙箱数也越多。

原因二：多任务并行

RL 训练集可能有几十万甚至上百万条数据（代码题、数学题、工具调用任务）。每条都需要沙箱验证。如果串行跑，时间成本无法承受。必须大规模并行。

原因三：自我对抗与博弈

高级训练场景中，Agent 之间会互相对抗：Agent A 写攻击代码，Agent B 写防御代码，互相检验对方是否能突破防御。这不仅仅是并行，而是多个 Agent 之间有状态依赖——Agent B 需要从 Agent A 的输出状态继续执行。

原因四：多步推理链（Chain-of-Thought with Execution）

现代 Agent 的训练不仅要求生成答案，还要求生成中间步骤并在真实环境中验证。想象一个场景：Agent 需要先写代码、编译、运行、看输出、再调试。这个过程可能持续几十步甚至上百步。AgentENV 的快照和分叉能力让这种长轨迹训练变得可行。

1.4 大规模多 Agent RL 的五个硬需求

#	需求	说明
1	大规模并行	同时运行数千到数万个沙箱实例，每个实例独立
2	长轨迹 pause/resume	Agent 等待 LLM 决策时可暂停沙箱释放资源，LLM 返回后从快照恢复
3	分叉（Fork）	从某个中间状态复制出多个子沙箱，并行探索不同路径
4	高保真环境	必须是完整 Linux VM（真实内核、网络栈、文件系统），不能是模拟器或容器
5	强隔离	每个 Agent 独立内核，恶意代码不影响同机其他 Agent

这不是传统 Docker 容器能解决的问题，也不是 E2B 这种托管的 API 服务能解决的。

这就是 AgentENV 出现的原因。

---

第二篇：AgentENV 是什么？

2.1 一句话定义

AgentENV 是一个自托管的 AI Agent 沙箱运行时平台，基于 Firecracker 微虚拟机（microVM），专门为大规模多 Agent RL 训练设计，支持极速快照、恢复和分叉。

它是月之暗面（Moonshot AI）与 KVCache.ai 联合开发的 Kimi K3 训练基础设施的核心组成部分。

2.2 核心能力

2.2.1 隔离沙箱

每个 Agent 运行在一个独立的 Firecracker microVM 中，拥有自己的 Linux 内核、文件系统、网络栈——真正的硬件级隔离。

┌─────────────────┐    ┌─────────────────┐
│  Firecracker VM   │    │  Firecracker VM   │
│  ┌─────────────┐ │    │  ┌─────────────┐ │
│  │ Agent A     │ │    │  │ Agent B     │ │
│  │ Python 3.12 │ │    │  │ Node.js 20  │ │
│  │ Ubuntu      │ │    │  │ Ubuntu      │ │
│  └─────────────┘ │    │  └─────────────┘ │
│  独立内核         │    │  独立内核         │
│  独立文件系统     │    │  独立文件系统     │
│  独立网络命名空间 │    │  独立网络命名空间  │
└───────┬─────────┘    └───────┬─────────┘
        │                      │
        └────── KVM ───────────┘
        硬件辅助虚拟化（硬件级隔离）

Firecracker 是 AWS 开源的 VMM（Virtual Machine Monitor），专为无服务器计算与微虚拟机场景优化，启动速度快、资源开销低。

2.2.2 极速快照（Snapshot）

对运行中的沙箱捕获全状态快照：

指标	值
暂停时间	<100ms
恢复时间	<50ms
快照大小	增量（数 MB 级）
存储后端	本地文件系统 / S3 兼容对象存储
快照内容	内存状态（进程、网络连接、缓冲区）+ 文件系统增量

Running ──> Pausing ──> Paused（快照已存储，零资源占用）
            │
            └──<50ms── Resuming ──> Running（原封不动继续执行）

关键优势：暂停后零资源占用——CPU、内存全部释放，仅在需要时恢复。这使得超大规模并行（远超实际可用的物理内存）成为可能。

2.2.3 分叉（Fork）

从一个运行中的沙箱克隆出多个子沙箱，共享原始状态作为基础：

沙箱 A（已执行 10 步代码，环境处于某个中间状态）
     │
     ├── fork → 沙箱 B：从第 10 步继续，尝试不同的算法实现
     ├── fork → 沙箱 C：从第 10 步继续，尝试不同的参数
     └── fork → 沙箱 D：从第 10 步继续，继续原有逻辑

Fork 时源沙箱仅短暂暂停（毫秒级），子沙箱完全独立运行。这个能力在 RL 训练中极其宝贵：当 Agent 在某个中间决策点有多种可能路径时，你可以 fork 出多个沙箱并行探索每条路径，然后在所有路径完成后对比结果，计算 Reward。

2.2.4 E2B 兼容 API

AgentENV 暴露的 HTTP API 与 E2B 完全兼容。这意味着现有的 E2B Python/JavaScript SDK 可以直接对接：

# 用 E2B SDK 直接操作 AgentENV 服务器
from e2b import Sandbox

sandbox = Sandbox.create(api_base="http://your-agentenv:8000")
sandbox.commands.run("python3 main.py")

已有的 E2B 应用可以零成本迁移到自托管。

2.2.5 多节点集群

AgentENV 支持多节点集群部署，包含三个核心组件：

    Client
      │
      ▼
  Gateway(:8080) ──gRPC──> Scheduler(:9090)
      │                          │
      │    ┌─────────────────────┘
      │    │ node selection / lookup
      ▼    ▼
 Node A(:8000)    Node B(:8000)    Node C(:8000)
      │               │               │
  ┌──────┐        ┌──────┐        ┌──────┐
  │ 沙箱  │        │ 沙箱  │        │ 沙箱  │
  │ 100×  │        │ 200×  │        │ 150×  │
  └──────┘        └──────┘        └──────┘

• Gateway：HTTP 反向代理，从请求头中提取 sandbox ID 并路由到正确的节点
• Scheduler：gRPC 服务，负责节点选择（round_robin/random）、绑定管理、心跳接收、P2P 端点发现
• Runtime Node：每个节点运行一个 AgentENV server 二进制，管理本机的 Firecracker 沙箱

部署模式：

• 单节点：make start-server 快速启动
• Docker Compose：make deploy-up 一键启动 gateway + scheduler + 2 个后端节点
• Kubernetes：DaemonSet 模式，每个宿主机一个 runtime Pod

2.3 架构全览

┌─────────────────────────────────────────────────────────────┐
│                    AgentENV Server（单节点）                    │
│  ┌──────────┐  ┌──────────┐  ┌──────────────────┐          │
│  │ Sandbox  │  │ Snapshot │  │ Template Builder │          │
│  │ Manager  │  │ Manager  │  │                  │          │
│  └────┬─────┘  └────┬─────┘  └───────┬──────────┘          │
│       │              │               │                     │
│  ┌────▼──────────────▼───────────────▼──────────┐          │
│  │              Orchestrator                     │          │
│  │（生命周期状态机 + 自动驱逐 + 运行时指标）        │          │
│  └───────────────────────────────────────────────┘          │
│                       │                                     │
│  ┌────────────────────▼────────────────────────────────┐    │
│  │                 Sandbox Subsystem                     │    │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────────────┐   │    │
│  │  │ Envd     │  │ Network  │  │ Warm Pools       │   │    │
│  │  │ (Agent)  │  │ Manager  │  │ (网络/块设备/FC)  │   │    │
│  │  └──────────┘  └──────────┘  └──────────────────┘   │    │
│  └────────────────────┬─────────────────────────────────┘    │
│                       │                                     │
│  ┌────────────────────▼────────────────────────────────┐    │
│  │              Storage Layer                            │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌───────────┐  │    │
│  │  │  overlaybd   │  │  ublk        │  │ Snapshot  │  │    │
│  │  │ 分层块设备    │  │ 用户态块驱动  │  │ Repository│  │    │
│  │  └──────────────┘  └──────────────┘  └───────────┘  │    │
│  └────────────────────┬─────────────────────────────────┘    │
│                       │                                     │
│  ┌────────────────────▼────────────────────────────────┐    │
│  │           Firecracker（微虚拟机 VMM）                  │    │
│  │          每个沙箱 = 1 个 Firecracker 进程              │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘

2.4 关键技术深度解析

2.4.1 overlaybd——分层块设备

overlaybd 是 AgentENV 最核心的存储创新。它是一个基于 LSMT（Log Structured Merge Tree） 的自研分层镜像格式。简而言之，它让镜像按需加载和增量存储成为可能。

OCI Registry（远程镜像仓库，如 Docker Hub / GHCR）
      │
      │ 按需拉取（on-demand loading）
      ▼
overlaybd 运行时缓存（本地磁盘）
  ┌─────────────┐  ← 底层 Base Layer（只读，所有沙箱共享）
  │  Base Layer  │
  └─────────────┘
  ┌─────────────┐  ← 上层 Delta Layer（读写，写时复制）
  │  Delta Layer │
  └─────────────┘
      │
      ▼
Linux 块设备（通过 ublk 暴露给内核）
      │
      ▼
Firecracker microVM 的根文件系统

关键技术特性：

• 按需加载：沙箱启动时不需要下载完整镜像（可能是几个 GB），只拉取需要的块，边用边加载。冷启动在 1-3 秒内完成。
• 写时复制（CoW）：多个沙箱共享同一 Base Layer，各自有独立的 Delta Layer。100 个沙箱共享同一个 Ubuntu 镜像，磁盘上只有一份 Base Layer + 100 个小 Delta。
• 增量快照：快照时只保存 Delta Layer 的变化部分，通常是 KB 到 MB 级，而非全量 GB 级。
• 远程 Registry：支持从任意 OCI 兼容的镜像仓库拉取（Docker Hub、GHCR、私有仓库），也支持 OverlayBD 原生镜像。

overlaybd 的层文件格式剖析：

每个 Layer 文件：
┌──────────────────────────────────┐
│         HeaderTrailer            │
│  Magic: "LSMT\0\1\2"            │
│  UUID、Flags                    │
│  Index/Data 偏移量               │
├──────────────────────────────────┤
│   DiskSegmentMapping 数组        │
│  （每个 16 bytes，bit-packed）    │
│   • 50-bit 偏移量                │
│   • 14-bit 长度                  │
│   • 55-bit 物理偏移量            │
│   • Zeroed 标志                  │
│   • Layer 标签                   │
├──────────────────────────────────┤
│        数据块（zstd 压缩）        │
│   • zstd level 3                 │
│   • 随机访问跳表                  │
│   • CRC32C 校验                  │
└──────────────────────────────────┘

读取时，ImageFile 从顶层往下搜索层，第一个包含目标块映射的层提供服务。写入时，所有追加写入都落到 Upper Layer。

2.4.2 ublk——用户态块设备驱动

ublk 是 Linux 内核从 6.0+ 开始提供的用户态块设备框架，允许用户态进程暴露块设备给内核。相比 qemu 的 virtio-blk，ublk 方案延迟更低、吞吐量更高。

AgentENV / ublk-daemon（用户态进程）
      │ 通过 io_uring 与内核 ublk 驱动通信
      ▼
Linux 内核 ublk 驱动
      │ 创建 /dev/ublkbN 块设备
      ▼
应用程序/内核可以像普通块设备一样使用
      │
      ▼
Firecracker microVM 的根文件系统（/dev/vda）

ublk 在 AgentENV 中的具体架构是：

┌────────────────────────────────┐
│     ublk-daemon (独立进程)       │
│                                │
│  ┌──────────┐  ┌────────────┐ │
│  │Overlaybd │  │BasicCow    │ │
│  │Target    │  │Target      │ │
│  └──────────┘  └────────────┘ │
│  ┌─────────────────────────┐  │
│  │   ublk 设备管理器       │  │
│  │   (/dev/ublkb0-999)    │  │
│  └─────────────────────────┘  │
│         │ Unix Socket         │
│         ▼                     │
│   UblkDaemonClient           │
└──────────┬────────────────────┘
           │
    AgentENV Node Server

设备管理通过一个独立进程（uvm-ublk-daemon）完成，与主 Node Server 通过 Unix Domain Socket 通信。这种架构隔离保证了 io_uring 控制权的专属和 ublk 设备的生命周期管理。

ublk 支持两种 Target 实现：

• OverlaybdTarget：包装 overlaybd ImageFile，提供完整的分层镜像 I/O
• BasicCowTarget：基于 Chunk 的写时复制，在只读源文件之上提供读写层

2.4.3 内存快照恢复

AgentENV 的内存快照恢复使用ublk 驱动的 overlaybd 设备（而非常见的 userfaultfd 方案）：

暂停时：
  Firecracker diff snapshot ──> mem.bin（稀疏文件，仅含脏页）
        │
        ▼
  convert_sparse_mem_to_overlaybd ──> overlaybd 层文件（增量）

恢复时：
  内存 overlaybd 层堆叠 ──> ublk 只读块设备
        │
        ▼
  Firecracker mmap 块设备
        │
        ▼
  COW 到匿名内存（第一次写入时拷贝）

优势：

• 共享：多个从同一快照启动的沙箱共享同一个内存 ublk 设备（引用计数），Linux 页缓存也被共享，同等内存页的 I/O 大幅减少
• 增量：每次暂停只保存变化的内存页，而非全量 dump
• 速度：恢复时间通常 <50ms

2.4.4 快照仓库（Snapshot Repository）

快照仓库存储了所有提交的快照及其关联数据：

/snapshot-store/
  repository/
    catalog/
      aliases/          # 名字 → ID 映射
    snapshots/<id>/
      snapshot.json      # 运行时配置、层引用
      firecracker-manifest.json  # 启动元数据
      vm_state.bin        # VM 内存状态
    managed-layers/
      <digest>.overlaybd.commit  # 增量文件系统层

一个快照包含三部分：

1. 内存状态（vm_state.bin）：VM 的完整内存快照，包括所有进程、网络连接、内核缓冲区
2. 文件系统增量（.overlaybd.commit）：Base Layer 之上的所有变更
3. 运行时配置（snapshot.json）：环境变量、工作目录、端口映射

恢复流程：

1. 组合文件系统层：overlaybd 将快照层堆叠到 Base Layer 上（~10ms）
2. 加载内存状态：ublk 读出 vm_state.bin 给 Firecracker（~30ms）
3. 恢复执行：KVM 从暂停点恢复指令执行

2.4.5 预热池（Warm Pool）

为了进一步降低延迟，AgentENV 维护了多级预热池：

预热池	功能	效果
网络池	预先创建好的网络命名空间 + veth + tap + iptables 规则	创建沙箱时跳过网络配置（~100ms 节省）
块设备池	预先分配的 overlaybd 设备（镜像相关）	创建沙箱时跳过块设备创建（~50ms 节省）
Firecracker 池	预先启动的 Firecracker 进程 + 网络槽位	沙箱恢复时跳过 FC 进程启动和 API socket 等待

预热池配合低/高水位线（low/high watermark），由后台工作者线程异步维护，确保资源供需平衡。

2.4.6 P2P 传输

在集群场景中，AgentENV 提供可选的 P2P 传输层（基于 iroh + iroh-blobs），让节点之间直接交换快照/层数据：

节点 A（有快照）─── P2P 传输 ───→ 节点 B（需要快照）
      │
      └── 回退：从 S3 拉取

P2P 传输的优势在于：

• 避免存储后端瓶颈：所有节点同时拉取同一个快照时，P2P 让节点之间互相分享，而不是全部命中对象存储
• 自愈：获取后的节点自动成为提供者，快照在集群中传播
• 调度器集成：节点心跳时上报本地的 P2P 端点，调度器维护一个轻量级的 artifact-to-node 索引

2.4.7 沙箱生命周期状态机

AgentENV 定义了清晰的沙箱状态转换：

Creating ──> Running ──> Pausing ──> Paused
                │                      │
                ├──> Snapshotting      └──> Resuming ──> Running
                ├──> Forking
                └──> Killing

状态	说明
Creating	VM 正在启动，块设备正在挂载，网络正在配置
Running	VM 已就绪，可执行命令、转发流量、计时器行走
Pausing	正在捕获内存和磁盘快照
Paused	VM 已停止，快照已存储，零资源消耗
Resuming	正在从快照恢复
Snapshotting	正在捕获持久快照，完成后回到 Running
Forking	正在克隆子沙箱，源沙箱完成后回到 Running
Killing	正在销毁 VM 和释放资源

2.4.8 沙箱网络

AgentENV 的网络隔离基于 Linux 网络命名空间 + veth pairs + iptables 规则：

宿主机网络栈
  │
  ├── veth0 ── tap0 <──> [Firecracker VM A]
  │
  ├── veth1 ── tap1 <──> [Firecracker VM B]
  │
  └── iptables NAT/Masquerade（出网访问）

• 每个沙箱有独立的网络命名空间，互不可见
• 支持出站访问策略：per-sandbox 的 allowOut（CIDR/IP/域名）和 denyOut（CIDR/IP）
• 通过 iptables 实现出网 NAT，AgentENV 拥有宿主机上的完整网络控制权

---

第三篇：同类产品横向对比

3.1 全景对比

方案	隔离机制	启动时间	每实例内存	快照	分叉	分布式	开源	典型场景
Docker	Namespace + cgroup	~200ms	几十 MB	❌	❌	✅	✅	应用部署
gVisor	用户态内核	~100ms	较高	❌	❌	✅	✅	Cloud Run
Kata Container	轻量 VM	~1s	较高	❌	❌	✅	✅	高安全容器
Firecracker（裸）	microVM	~125ms	~5MB+guest	❌	❌	❌	✅	需自行集成
E2B Cloud	Firecracker	~150ms	~1GB 配额	❌	❌	✅	部分	Agent 托管
ZeroBoot	KVM CoW fork	0.79ms	~265KB	❌	❌	❌	✅	一次性代码
Cube Sandbox	RustVMM+KVM	~60ms	~5MB	❌	❌	❌	✅	轻量沙箱
OpenSandbox	Docker	~500ms	容器级	❌	❌	✅	✅	AI Agent
AgentENV	Firecracker+自研存储	~50ms(恢复)	~5MB+guest	✅	✅	✅	✅	多Agent RL

3.2 关键能力对比

能力	AgentENV	E2B Cloud	ZeroBoot	Docker	OpenSandbox
pause → resume	✅ <100ms	❌	❌	❌	❌
fork 分叉	✅ 毫秒级	❌	❌	❌	❌
增量快照	✅ 数 MB	❌	❌	❌	❌
按需加载镜像	✅ overlaybd	❌	❌	✅ layers	❌
内存热扩容	✅ ballooning	❌	❌	❌	❌
多节点集群	✅	✅	❌	✅	✅
E2B API 兼容	✅	原生	❌	❌	❌
自托管	✅	❌	✅	✅	✅
完整 Linux 内核	✅ Firecracker	✅ FC	✅ KVM	❌ 共享内核	❌ 共享内核

3.3 深入对比：AgentENV vs E2B Cloud

E2B Cloud（Execute 2 Build）是最知名的托管沙箱平台，被 Manus、Perplexity 等产品采用。AgentENV 可以看作 E2B 的自托管开源等价物，但远不止于此。

维度	E2B Cloud	AgentENV
运行方式	SaaS 托管	自托管
快照	❌ 不支持	✅ 增量快照，<100ms
分叉	❌ 不支持	✅ 毫秒级 fork
开放程度	部分开源（Python SDK）	完全开源
自定义镜像	有限	任意 OCI 镜像
大规模并行	有限，受配额限制	无限制，自托管集群
成本	按使用付费	自持硬件，边际成本低

关键区别：E2B 是产品，AgentENV 是基础设施。AgentENV 提供了 E2B 没有的快照/分叉能力，这是多 Agent RL 训练的核心需求。

3.4 深入对比：AgentENV vs ZeroBoot

ZeroBoot（ICICLE 项目）是另一个极简方案，基于 KVM CoW fork 实现 0.79ms 启动。但 ZeroBoot 的目标场景与 AgentENV 完全不同。

维度	ZeroBoot	AgentENV
启动时间	0.79ms	50ms（从快照恢复）
快照	❌ 无持久快照	✅ 持久化快照
文件系统	CoW fork（同父 clone）	overlaybd 分层镜像
网络	无隔离	独立命名空间 + iptables
分布式	❌ 单机	✅ 多节点集群
适用场景	一次性代码执行	长轨迹 RL 训练

ZeroBoot 的启动时间确实惊艳，但它不支持持久化快照、不支持分布式、不支持复杂网络隔离。AgentENV 牺牲了启动时间（50ms vs 0.79ms），但换来了完整的多 Agent RL 训练所需的所有能力。

3.5 深入对比：AgentENV vs Docker

Docker 是最简单的沙箱方案，但它的缺陷在多 Agent RL 场景中无法忽略：

维度	Docker	AgentENV
隔离	共享内核（namespace）	独立内核（microVM）
安全	cgroup 逃逸风险	硬件级隔离（KVM）
pause/resume	❌ pause 后容器停止	✅ 完整状态恢复
fork	❌ 基于镜像重复启动	✅ 毫秒级 fork
高保真	共享宿主机内核	完整 Linux 内核
镜像存储	全量层下载	overlaybd 按需加载

共享内核的代价：Docker 容器共享宿主内核，这意味着：1）容器内的 syscall 逃逸可能影响宿主机和其他容器；2）容器看到的 /proc 等内核接口不真实；3）暂停只能 docker pause（冻结进程，非状态快照），恢复后网络连接等内核状态会丢失。

---

第四篇：为什么 AgentENV 更适合多 Agent RL？

4.1 核心论点

多 Agent RL 训练要从传统 RL 的单线程循环升级为"生成 → 执行 → 反馈 → 更新"的大规模并行流水线。AgentENV 是这个流水线中负责"执行"环节的高性能、可快照、可分叉的沙箱基础设施。

4.2 逐一对应五个硬需求

硬需求	AgentENV 如何满足	技术原理
大规模并行	预热池 + 快照恢复 <50ms + 多节点集群	预热池跳过网络/块/FC 创建，快照恢复比冷启动快 10×+，集群横向扩展
pause/resume	暂停 <100ms，恢复 <50ms，零资源占用	overlaybd 增量快照 + ublk 内存恢复 + 快照仓库
分叉（fork）	毫秒级从运行中沙箱克隆子沙箱	共享 Base Layer + 独立 Delta + ublk 共享内存
高保真环境	Firecracker microVM，独立内核	KVM 硬件虚拟化，完整 Linux 内核
强隔离	独立 VM，KVM 硬件隔离	iptables + netns + 独立内核

4.3 pause/resume 的实际价值

想象一个典型的 RL 训练循环：

for each prompt in dataset:
    LLM 生成 completion（GPU 推理，几秒到几十秒）
    Agent 在沙箱中执行（CPU 密集型，可能几分钟）
    计算 Reward
    更新模型参数

如果没有 pause/resume，Agent 执行期间沙箱一直占用内存。如果同时有 10,000 个 Agent 实例在等待 LLM 推理结果，就需要 10,000 倍物理内存——这在现实中不可能。

有了 pause/resume：

1. Agent 在沙箱中执行到某一步（如运行到一半的测试）
2. Agent 等待 LLM 生成下一步决策 → **pause 沙箱（~50ms）** → 释放内存
3. LLM 返回决策 → **resume 沙箱（~30ms）** → Agent 继续执行
4. 循环 n 步后结束

实际效果：10,000 个沙箱并发只需要 2,000 份物理内存——8,000 个处于 paused 状态，零资源占用。这称为时间片复用（time-sliced oversubscription），是大规模 RL 训练的关键经济性来源。

4.4 fork 的实际价值

分叉能力在以下场景中极其有用：

场景一：探索多条路径

Agent 在调试一个 bug——找到了 3 个可能的根因
    │
    ├── fork → 沙箱 B：验证根因 1（安装调试工具，检查路径 A）
    ├── fork → 沙箱 C：验证根因 2（修改配置，检查路径 B）
    └── fork → 沙箱 D：验证根因 3（打补丁，检查路径 C）

所有 fork 完成后，对比结果
哪个根因正确就取哪个路径

场景二：多轮对抗训练

Agent A 生成了一组 yaml 文件
    │
    ├── fork → Agent B：编写 Prompt 注入攻击，尝试突破 Agent A 的安全性
    ├── fork → Agent C：验证配置正确性
    └── fork → Agent D：执行性能测试

三个 fork 独立运行，互不干扰

场景三：超参数探索

一段已完成训练的基准代码
    │
    ├── fork → 变体 1：调整 prompt style
    ├── fork → 变体 2：增加思考步数
    ├── fork → 变体 3：更换工具调用方式
    └── fork → N：更多变体...

没有 fork，你就要为每个变体从零启动沙箱、重新安装所有依赖、重新初始化环境。有了 fork，一次基准初始化，所有变体共享。

4.5 多步推理链 + 快照的组合优势

Agent 在复杂场景中需要多步推理链（Chain-of-Thought with Execution）。例如，一个代码生成 Agent 可能需要：

Step 1: 写代码 → 生成二进制文件
Step 2: 运行 → 检查输出
Step 3: 发现错误 → 根据错误信息修改代码
Step 4: 重新编译运行
Step 5: 重复直到通过测试
...
Step N: 完成

每一步之间都有 LLM 推理延迟。如果没有快照：

• 整个执行过程可以长达数十秒到数分钟
• Agent 必须全程占用沙箱资源
• 如果 LLM 推理失败（OOM、超时），Agent 的工作全部丢失，需要从头重来

有了快照：

• 每完成一步就显式创建快照（保存 checkpoint）
• LLM 推理期间沙箱处于 paused 状态，零资源消耗
• 如果 LLM 或 Agent 崩溃，从最近的 checkpoint 恢复，而不是从头开始
• 真正实现了"训练过程可暂停、可恢复、可检查"，这对于百万轮次的训练是必备的

4.6 成本与效率

大规模 RL 训练的成本主要由两部分构成：

1. GPU 算力（训练推理）
2. 沙箱资源（CPU + 内存 + 磁盘）

AgentENV 的优化直接作用于第二部分：

优化	效果
overlaybd 按需加载	无需为每个沙箱完整下载镜像，共享 Base Layer
增量快照	快照大小数 MB 而非数 GB
pause/resume	内存利用率提高 5-10×（时间片复用）
共享页缓存	同一镜像/快照的多个沙箱复用 Linux 页缓存
内存 ballooning	归还可回收的客户机内存给宿主机，维持高超配比

4.7 真正的场景：Kimi K3 训练

AgentENV 的诞生直接服务于 Kimi K3（2.8T 参数的混合专家模型，MoE）的 RL 训练。Kimi K3 在多项基准测试（AIME 2025、GPQA、LiveCodeBench、SWE-bench）中超越了 GPT-5 和 Claude 4。

Kimi K3 的 RL 训练需要：

• 同时运行数万个 Firecracker 沙箱
• 每个沙箱运行完整的 Linux 环境
• 支持长轨迹（代码编写 + 运行 + 调试 + 验证的多轮循环）
• 支持分叉以并行探索不同的 Agent 行为路径
• 支持快照暂停/恢复以实现资源的时间片复用

AgentENV 的训练流程简化示意：

训练数据集（百万级 Prompt）
    │
    ▼
┌────────────────────────────┐
│  GPU 集群（LLM 推理/训练）  │
│  （每个 Prompt 采样 N 份） │
└──────┬─────────────────────┘
       │ N 份 completions
       ▼
┌────────────────────────────┐
│   AgentENV 沙箱集群         │
│   （数万个 microVM）        │
│                            │
│   Sandbox 1: 执行 completion A
│   Sandbox 2: 执行 completion B
│   ...                       │
│   Sandbox N: 执行 completion N
│                            │
│   支持 pause/resume/fork   │
└──────┬─────────────────────┘
       │ N 份执行结果
       ▼
┌────────────────────────────┐
│  Reward 计算（GRPO）       │
│  组内相对比较，计算奖励     │
└──────┬─────────────────────┘
       │ Reward 信号
       ▼
┌────────────────────────────┐
│  模型参数更新（训练器）    │
└────────────────────────────┘

---

第五篇：快速上手指南

5.1 安装

# 方式一：安装脚本（Ubuntu 24.04）
curl -fsSL https://raw.githubusercontent.com/kvcache-ai/AgentENV/main/scripts/install.sh | sudo bash
sudo systemctl start aenv

# 方式二：Docker
curl -fsSL https://raw.githubusercontent.com/kvcache-ai/AgentENV/main/scripts/docker-setup.sh | sudo bash
docker pull ghcr.io/kvcache-ai/aenv-server:latest
docker run -d --privileged -v /dev:/dev -p 8000:8000 ghcr.io/kvcache-ai/aenv-server:latest

# 安装 CLI（macOS/Linux 均可）
curl -fsSL https://raw.githubusercontent.com/kvcache-ai/AgentENV/main/scripts/install-cli.sh | bash

前提条件：

• Linux 宿主机，内核 6.8+
• /dev/kvm 访问权限
• 建议 Ubuntu 24.04

5.2 快速入门

# 认证
aenv auth

# 拉取模板并启动沙箱
aenv pull ubuntu:22.04 --name ubuntu
aenv start ubuntu          # 启动并进入交互式 shell

# 沙箱管理
aenv ls                    # 列出所有沙箱
aenv pause <sandbox-id>    # 暂停沙箱（保存快照）
aenv resume <sandbox-id>   # 恢复沙箱
aenv delete <sandbox-id>   # 删除沙箱

# 分叉（fork）
aenv fork <sandbox-id>      # 克隆一个子沙箱

# CLI 参考
aenv pull docker.io/library/ubuntu:latest --name ubuntu  # 从 Dvckr Hub 拉取
aenv template list         # 列出所有模板
aenv start ubuntu --detach # 后台启动
aenv cn <sandbox-id>       # 重新连接到沙箱 shell
aenv exec <sandbox-id> ls  # 执行单次命令
aenv timeout <sandbox-id> 600  # 延长超时

---

总结

AgentENV 的独特性

1. 它是第一个为 RL 训练设计的沙箱平台——已有的沙箱方案（Docker、微虚拟机、E2B）都面向"运行应用"或"一次性代码执行"，没有一个专注解决 RL 训练中的快照、pause/resume、fork 需求。

2. 它填补了 RL 基础设施的关键空白——RL 训练领域已有成熟的训练框架（vLLM、DeepSpeed、TRL）、数据集工具、评估基准，但沙箱基础设施一直是一个"自己手搓"的黑盒子。AgentENV 将这个黑盒子变成了标准的开源平台。

3. 它证明了"基础设施创新推动 AI 能力"——Kimi K3 的出色表现背后，AgentENV 是关键的支撑。没有高效的沙箱基础设施，大规模多 Agent RL 训练的成本会高到不经济。

4. 它降低了自托管门槛——E2B 兼容 API 意味着迁移成本极低，已有的 Agent 工作流可以直接复用。

适合的场景

场景	推荐
多 Agent RL 训练（代码生成、工具调用、Agent 任务）	✅ 强烈推荐
大规模并行沙箱（100+ 实例）	✅ 强烈推荐
长轨迹 Agent 验证（多步推理链）	✅ 强烈推荐
对抗训练 / 博弈训练	✅ 推荐
需要 pause/resume 的场景	✅ 推荐
一次性代码运行（几十毫秒级）	⚠️ ZeroBoot 更适合
简单 web 应用部署	❌ Docker 够用

一句话总结

AgentENV 是把"多 Agent 大规模强化学习"从只能大厂秘密造轮子的黑盒，变成了每个人都能部署的开源基础设施。它是 Kimi K3 背后的"隐藏引擎"，是理解 AI 后训练时代不可或缺的一环。

---

参考链接

• AgentENV GitHub 仓库
• AgentENV 官方文档
• Kimi K3 开源说明
• Firecracker microVM
• OverlayBD 项目
• ublk 内核文档
• GRPO: Group Relative Policy Optimization (DeepSeek)
• E2B Platform

Originally created by @vislee on GitHub (Aug 3, 2026). Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/117 # AgentENV 完全解读：当大规模多 Agent 强化学习需要一台"快照电脑" > 本文是一篇深度技术分析文章，全面介绍 AgentENV——一个专为大规模多 Agent RL 训练设计的开源沙箱运行时平台，由月之暗面（Moonshot AI）与 KVCache.ai 联合开发，2026 年 7 月随 Kimi K3（2.8T 参数开源模型）一同开源。 --- ## 目录 1. [第一篇：什么是多 Agent RL 训练？](#第一篇什么是多-agent-rl-训练) 2. [第二篇：AgentENV 是什么？](#第二篇agentenv-是什么) 3. [第三篇：同类产品横向对比](#第三篇同类产品横向对比) 4. [第四篇：为什么 AgentENV 更适合多 Agent RL？](#第四篇为什么-agentenv-更适合多-agent-rl) 5. [总结](#总结) --- ## 第一篇：什么是多 Agent RL 训练？ ### 1.1 从 RLHF 到 GRPO：一个快速回顾 强化学习（Reinforcement Learning, RL）在 LLM 训练中的经典用法是 **RLHF（Reinforcement Learning from Human Feedback）**。典型流程如下： ``` 基础模型 → SFT（监督微调）→ RM（奖励模型）→ RL（PPO 强化学习） ``` RL 阶段的核心循环（以 PPO 算法为例）： ``` 1. 输入一个 Prompt（如"用 Python 写一个二叉树"） 2. LLM 生成一段 Response 3. 把这段 Response 放到真实环境中执行/验证 - 代码沙箱：运行代码，看是否能通过测试用例 - 数学题：最终计算结果是否等于标准答案 - Agent 任务：能否完成浏览器操作、工具调用等多步流程 4. 根据执行结果计算 Reward（奖励分数） 5. 用 Reward 更新 LLM 参数 6. 回到步骤 1，不断迭代 ``` 这里第 3 步极其重要：**你必须把 LLM 生成的代码/操作放到真实环境里运行，才知道它好不好**。这个"真实执行环境"就是沙箱（Sandbox）。 近年来，DeepSeek 提出的 **GRPO（Group Relative Policy Optimization）** 逐渐成为主流。它不再需要单独的 Reward Model，而是对同一个 Prompt 采样一组（Group）输出，在组内做相对比较——谁比谁好，不需要人类标注分数。这让 RL 训练更适合大规模自动化执行。 ### 1.2 当"一个 Agent"变成"一群 Agent" 传统的 RL 是一个 **Prompt → 一个输出 → 验证 → 更新** 的单线循环。 多 Agent RL 则完全不一样： ``` 同一个 Prompt │ ┌───────────────┼───────────────┐ │ │ │ Agent A Agent B Agent C │ │ │ 沙箱 1 沙箱 2 沙箱 3 │ │ │ 执行结果 A 执行结果 B 执行结果 C │ │ │ Reward A Reward B Reward C │ │ │ └───────────────┼───────────────┘ │ 汇聚回训练器 更新参数 ``` 一个 LLM 的多个副本（或同一模型的不同采样参数）同时生成多个 Response，每个 Response 在各自独立的沙箱中执行，得到多份 Reward 信号。这些信号汇聚回训练器，用来更新模型参数。 ### 1.3 为什么需要"多 Agent"？ **原因一：探索（Exploration）** 同一个 Prompt，LLM 可以生成无数种不同的 Response。哪些好、哪些差？只有都跑一遍才知道。PPO 和 GRPO 都要求对每个 Prompt 采样 N 个 completions，N 通常取值 8-64，甚至更高。N 越大，Reward 信号越可靠，但需要的并行沙箱数也越多。 **原因二：多任务并行** RL 训练集可能有几十万甚至上百万条数据（代码题、数学题、工具调用任务）。每条都需要沙箱验证。如果串行跑，时间成本无法承受。必须大规模并行。 **原因三：自我对抗与博弈** 高级训练场景中，Agent 之间会互相对抗：Agent A 写攻击代码，Agent B 写防御代码，互相检验对方是否能突破防御。这不仅仅是并行，而是多个 Agent 之间有状态依赖——Agent B 需要从 Agent A 的输出状态继续执行。 **原因四：多步推理链（Chain-of-Thought with Execution）** 现代 Agent 的训练不仅要求生成答案，还要求生成中间步骤并在真实环境中验证。想象一个场景：Agent 需要先写代码、编译、运行、看输出、再调试。这个过程可能持续几十步甚至上百步。AgentENV 的快照和分叉能力让这种长轨迹训练变得可行。 ### 1.4 大规模多 Agent RL 的五个硬需求 | # | 需求 | 说明 | |---|------|------| | 1 | **大规模并行** | 同时运行数千到数万个沙箱实例，每个实例独立 | | 2 | **长轨迹 pause/resume** | Agent 等待 LLM 决策时可暂停沙箱释放资源，LLM 返回后从快照恢复 | | 3 | **分叉（Fork）** | 从某个中间状态复制出多个子沙箱，并行探索不同路径 | | 4 | **高保真环境** | 必须是完整 Linux VM（真实内核、网络栈、文件系统），不能是模拟器或容器 | | 5 | **强隔离** | 每个 Agent 独立内核，恶意代码不影响同机其他 Agent | **这不是传统 Docker 容器能解决的问题，也不是 E2B 这种托管的 API 服务能解决的。** 这就是 AgentENV 出现的原因。 --- ## 第二篇：AgentENV 是什么？ ### 2.1 一句话定义 > **AgentENV 是一个自托管的 AI Agent 沙箱运行时平台，基于 Firecracker 微虚拟机（microVM），专门为大规模多 Agent RL 训练设计，支持极速快照、恢复和分叉。** 它是月之暗面（Moonshot AI）与 KVCache.ai 联合开发的 Kimi K3 训练基础设施的核心组成部分。 ### 2.2 核心能力 #### 2.2.1 隔离沙箱 每个 Agent 运行在一个独立的 Firecracker microVM 中，拥有自己的 Linux 内核、文件系统、网络栈——真正的硬件级隔离。 ``` ┌─────────────────┐ ┌─────────────────┐ │ Firecracker VM │ │ Firecracker VM │ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │ │ Agent A │ │ │ │ Agent B │ │ │ │ Python 3.12 │ │ │ │ Node.js 20 │ │ │ │ Ubuntu │ │ │ │ Ubuntu │ │ │ └─────────────┘ │ │ └─────────────┘ │ │ 独立内核 │ │ 独立内核 │ │ 独立文件系统 │ │ 独立文件系统 │ │ 独立网络命名空间 │ │ 独立网络命名空间 │ └───────┬─────────┘ └───────┬─────────┘ │ │ └────── KVM ───────────┘ 硬件辅助虚拟化（硬件级隔离） ``` Firecracker 是 AWS 开源的 VMM（Virtual Machine Monitor），专为无服务器计算与微虚拟机场景优化，启动速度快、资源开销低。 #### 2.2.2 极速快照（Snapshot） 对运行中的沙箱捕获全状态快照： | 指标 | 值 | |------|-----| | 暂停时间 | **<100ms** | | 恢复时间 | **<50ms** | | 快照大小 | 增量（数 MB 级） | | 存储后端 | 本地文件系统 / S3 兼容对象存储 | | 快照内容 | 内存状态（进程、网络连接、缓冲区）+ 文件系统增量 | ``` Running ──> Pausing ──> Paused（快照已存储，零资源占用） │ └──<50ms── Resuming ──> Running（原封不动继续执行） ``` 关键优势：**暂停后零资源占用**——CPU、内存全部释放，仅在需要时恢复。这使得超大规模并行（远超实际可用的物理内存）成为可能。 #### 2.2.3 分叉（Fork） 从一个运行中的沙箱克隆出多个子沙箱，共享原始状态作为基础： ``` 沙箱 A（已执行 10 步代码，环境处于某个中间状态） │ ├── fork → 沙箱 B：从第 10 步继续，尝试不同的算法实现 ├── fork → 沙箱 C：从第 10 步继续，尝试不同的参数 └── fork → 沙箱 D：从第 10 步继续，继续原有逻辑 ``` Fork 时源沙箱仅**短暂暂停（毫秒级）**，子沙箱完全独立运行。这个能力在 RL 训练中极其宝贵：当 Agent 在某个中间决策点有多种可能路径时，你可以 fork 出多个沙箱并行探索每条路径，然后在所有路径完成后对比结果，计算 Reward。 #### 2.2.4 E2B 兼容 API AgentENV 暴露的 HTTP API 与 E2B 完全兼容。这意味着现有的 E2B Python/JavaScript SDK 可以直接对接： ```python # 用 E2B SDK 直接操作 AgentENV 服务器 from e2b import Sandbox sandbox = Sandbox.create(api_base="http://your-agentenv:8000") sandbox.commands.run("python3 main.py") ``` 已有的 E2B 应用可以零成本迁移到自托管。 #### 2.2.5 多节点集群 AgentENV 支持多节点集群部署，包含三个核心组件： ``` Client │ ▼ Gateway(:8080) ──gRPC──> Scheduler(:9090) │ │ │ ┌─────────────────────┘ │ │ node selection / lookup ▼ ▼ Node A(:8000) Node B(:8000) Node C(:8000) │ │ │ ┌──────┐ ┌──────┐ ┌──────┐ │ 沙箱 │ │ 沙箱 │ │ 沙箱 │ │ 100× │ │ 200× │ │ 150× │ └──────┘ └──────┘ └──────┘ ``` - **Gateway**：HTTP 反向代理，从请求头中提取 sandbox ID 并路由到正确的节点 - **Scheduler**：gRPC 服务，负责节点选择（round_robin/random）、绑定管理、心跳接收、P2P 端点发现 - **Runtime Node**：每个节点运行一个 AgentENV server 二进制，管理本机的 Firecracker 沙箱 部署模式： - **单节点**：`make start-server` 快速启动 - **Docker Compose**：`make deploy-up` 一键启动 gateway + scheduler + 2 个后端节点 - **Kubernetes**：DaemonSet 模式，每个宿主机一个 runtime Pod ### 2.3 架构全览 ``` ┌─────────────────────────────────────────────────────────────┐ │ AgentENV Server（单节点） │ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │ Sandbox │ │ Snapshot │ │ Template Builder │ │ │ │ Manager │ │ Manager │ │ │ │ │ └────┬─────┘ └────┬─────┘ └───────┬──────────┘ │ │ │ │ │ │ │ ┌────▼──────────────▼───────────────▼──────────┐ │ │ │ Orchestrator │ │ │ │（生命周期状态机 + 自动驱逐 + 运行时指标） │ │ │ └───────────────────────────────────────────────┘ │ │ │ │ │ ┌────────────────────▼────────────────────────────────┐ │ │ │ Sandbox Subsystem │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │ │ │ Envd │ │ Network │ │ Warm Pools │ │ │ │ │ │ (Agent) │ │ Manager │ │ (网络/块设备/FC) │ │ │ │ │ └──────────┘ └──────────┘ └──────────────────┘ │ │ │ └────────────────────┬─────────────────────────────────┘ │ │ │ │ │ ┌────────────────────▼────────────────────────────────┐ │ │ │ Storage Layer │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │ │ │ │ │ overlaybd │ │ ublk │ │ Snapshot │ │ │ │ │ │ 分层块设备 │ │ 用户态块驱动 │ │ Repository│ │ │ │ │ └──────────────┘ └──────────────┘ └───────────┘ │ │ │ └────────────────────┬─────────────────────────────────┘ │ │ │ │ │ ┌────────────────────▼────────────────────────────────┐ │ │ │ Firecracker（微虚拟机 VMM） │ │ │ │ 每个沙箱 = 1 个 Firecracker 进程 │ │ │ └─────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ ``` ### 2.4 关键技术深度解析 #### 2.4.1 overlaybd——分层块设备 overlaybd 是 AgentENV 最核心的存储创新。它是一个基于 **LSMT（Log Structured Merge Tree）** 的自研分层镜像格式。简而言之，它让**镜像按需加载**和**增量存储**成为可能。 ``` OCI Registry（远程镜像仓库，如 Docker Hub / GHCR） │ │ 按需拉取（on-demand loading） ▼ overlaybd 运行时缓存（本地磁盘） ┌─────────────┐ ← 底层 Base Layer（只读，所有沙箱共享） │ Base Layer │ └─────────────┘ ┌─────────────┐ ← 上层 Delta Layer（读写，写时复制） │ Delta Layer │ └─────────────┘ │ ▼ Linux 块设备（通过 ublk 暴露给内核） │ ▼ Firecracker microVM 的根文件系统 ``` 关键技术特性： - **按需加载**：沙箱启动时不需要下载完整镜像（可能是几个 GB），只拉取需要的块，边用边加载。冷启动在 1-3 秒内完成。 - **写时复制（CoW）**：多个沙箱共享同一 Base Layer，各自有独立的 Delta Layer。100 个沙箱共享同一个 Ubuntu 镜像，磁盘上只有一份 Base Layer + 100 个小 Delta。 - **增量快照**：快照时只保存 Delta Layer 的变化部分，通常是 KB 到 MB 级，而非全量 GB 级。 - **远程 Registry**：支持从任意 OCI 兼容的镜像仓库拉取（Docker Hub、GHCR、私有仓库），也支持 OverlayBD 原生镜像。 overlaybd 的层文件格式剖析： ``` 每个 Layer 文件： ┌──────────────────────────────────┐ │ HeaderTrailer │ │ Magic: "LSMT\0\1\2" │ │ UUID、Flags │ │ Index/Data 偏移量 │ ├──────────────────────────────────┤ │ DiskSegmentMapping 数组 │ │ （每个 16 bytes，bit-packed） │ │ • 50-bit 偏移量 │ │ • 14-bit 长度 │ │ • 55-bit 物理偏移量 │ │ • Zeroed 标志 │ │ • Layer 标签 │ ├──────────────────────────────────┤ │ 数据块（zstd 压缩） │ │ • zstd level 3 │ │ • 随机访问跳表 │ │ • CRC32C 校验 │ └──────────────────────────────────┘ ``` 读取时，`ImageFile` 从顶层往下搜索层，第一个包含目标块映射的层提供服务。写入时，所有追加写入都落到 Upper Layer。 #### 2.4.2 ublk——用户态块设备驱动 ublk 是 Linux 内核从 6.0+ 开始提供的用户态块设备框架，允许用户态进程暴露块设备给内核。相比 qemu 的 virtio-blk，ublk 方案延迟更低、吞吐量更高。 ``` AgentENV / ublk-daemon（用户态进程） │ 通过 io_uring 与内核 ublk 驱动通信 ▼ Linux 内核 ublk 驱动 │ 创建 /dev/ublkbN 块设备 ▼ 应用程序/内核可以像普通块设备一样使用 │ ▼ Firecracker microVM 的根文件系统（/dev/vda） ``` ublk 在 AgentENV 中的具体架构是： ``` ┌────────────────────────────────┐ │ ublk-daemon (独立进程) │ │ │ │ ┌──────────┐ ┌────────────┐ │ │ │Overlaybd │ │BasicCow │ │ │ │Target │ │Target │ │ │ └──────────┘ └────────────┘ │ │ ┌─────────────────────────┐ │ │ │ ublk 设备管理器 │ │ │ │ (/dev/ublkb0-999) │ │ │ └─────────────────────────┘ │ │ │ Unix Socket │ │ ▼ │ │ UblkDaemonClient │ └──────────┬────────────────────┘ │ AgentENV Node Server ``` 设备管理通过一个独立进程（`uvm-ublk-daemon`）完成，与主 Node Server 通过 Unix Domain Socket 通信。这种架构隔离保证了 io_uring 控制权的专属和 ublk 设备的生命周期管理。 ublk 支持两种 Target 实现： - **OverlaybdTarget**：包装 overlaybd `ImageFile`，提供完整的分层镜像 I/O - **BasicCowTarget**：基于 Chunk 的写时复制，在只读源文件之上提供读写层 #### 2.4.3 内存快照恢复 AgentENV 的内存快照恢复使用**ublk 驱动的 overlaybd 设备**（而非常见的 userfaultfd 方案）： ``` 暂停时： Firecracker diff snapshot ──> mem.bin（稀疏文件，仅含脏页） │ ▼ convert_sparse_mem_to_overlaybd ──> overlaybd 层文件（增量） 恢复时： 内存 overlaybd 层堆叠 ──> ublk 只读块设备 │ ▼ Firecracker mmap 块设备 │ ▼ COW 到匿名内存（第一次写入时拷贝） ``` 优势： - **共享**：多个从同一快照启动的沙箱共享同一个内存 ublk 设备（引用计数），Linux 页缓存也被共享，同等内存页的 I/O 大幅减少 - **增量**：每次暂停只保存变化的内存页，而非全量 dump - **速度**：恢复时间通常 <50ms #### 2.4.4 快照仓库（Snapshot Repository） 快照仓库存储了所有提交的快照及其关联数据： ``` /snapshot-store/ repository/ catalog/ aliases/ # 名字 → ID 映射 snapshots/<id>/ snapshot.json # 运行时配置、层引用 firecracker-manifest.json # 启动元数据 vm_state.bin # VM 内存状态 managed-layers/ <digest>.overlaybd.commit # 增量文件系统层 ``` 一个快照包含三部分： 1. **内存状态**（vm_state.bin）：VM 的完整内存快照，包括所有进程、网络连接、内核缓冲区 2. **文件系统增量**（.overlaybd.commit）：Base Layer 之上的所有变更 3. **运行时配置**（snapshot.json）：环境变量、工作目录、端口映射 恢复流程： 1. 组合文件系统层：overlaybd 将快照层堆叠到 Base Layer 上（~10ms） 2. 加载内存状态：ublk 读出 vm_state.bin 给 Firecracker（~30ms） 3. 恢复执行：KVM 从暂停点恢复指令执行 #### 2.4.5 预热池（Warm Pool） 为了进一步降低延迟，AgentENV 维护了多级预热池： | 预热池 | 功能 | 效果 | |--------|------|------| | **网络池** | 预先创建好的网络命名空间 + veth + tap + iptables 规则 | 创建沙箱时跳过网络配置（~100ms 节省） | | **块设备池** | 预先分配的 overlaybd 设备（镜像相关） | 创建沙箱时跳过块设备创建（~50ms 节省） | | **Firecracker 池** | 预先启动的 Firecracker 进程 + 网络槽位 | 沙箱恢复时跳过 FC 进程启动和 API socket 等待 | 预热池配合低/高水位线（low/high watermark），由后台工作者线程异步维护，确保资源供需平衡。 #### 2.4.6 P2P 传输 在集群场景中，AgentENV 提供可选的 P2P 传输层（基于 iroh + iroh-blobs），让节点之间直接交换快照/层数据： ``` 节点 A（有快照）─── P2P 传输 ───→ 节点 B（需要快照） │ └── 回退：从 S3 拉取 ``` P2P 传输的优势在于： - **避免存储后端瓶颈**：所有节点同时拉取同一个快照时，P2P 让节点之间互相分享，而不是全部命中对象存储 - **自愈**：获取后的节点自动成为提供者，快照在集群中传播 - **调度器集成**：节点心跳时上报本地的 P2P 端点，调度器维护一个轻量级的 artifact-to-node 索引 #### 2.4.7 沙箱生命周期状态机 AgentENV 定义了清晰的沙箱状态转换： ``` Creating ──> Running ──> Pausing ──> Paused │ │ ├──> Snapshotting └──> Resuming ──> Running ├──> Forking └──> Killing ``` | 状态 | 说明 | |------|------| | **Creating** | VM 正在启动，块设备正在挂载，网络正在配置 | | **Running** | VM 已就绪，可执行命令、转发流量、计时器行走 | | **Pausing** | 正在捕获内存和磁盘快照 | | **Paused** | VM 已停止，快照已存储，零资源消耗 | | **Resuming** | 正在从快照恢复 | | **Snapshotting** | 正在捕获持久快照，完成后回到 Running | | **Forking** | 正在克隆子沙箱，源沙箱完成后回到 Running | | **Killing** | 正在销毁 VM 和释放资源 | #### 2.4.8 沙箱网络 AgentENV 的网络隔离基于 Linux 网络命名空间 + veth pairs + iptables 规则： ``` 宿主机网络栈 │ ├── veth0 ── tap0 <──> [Firecracker VM A] │ ├── veth1 ── tap1 <──> [Firecracker VM B] │ └── iptables NAT/Masquerade（出网访问） ``` - 每个沙箱有独立的网络命名空间，互不可见 - 支持出站访问策略：per-sandbox 的 `allowOut`（CIDR/IP/域名）和 `denyOut`（CIDR/IP） - 通过 iptables 实现出网 NAT，AgentENV 拥有宿主机上的完整网络控制权 --- ## 第三篇：同类产品横向对比 ### 3.1 全景对比 | 方案 | 隔离机制 | 启动时间 | 每实例内存 | 快照 | 分叉 | 分布式 | 开源 | 典型场景 | |------|---------|---------|-----------|------|------|--------|------|---------| | **Docker** | Namespace + cgroup | ~200ms | 几十 MB | ❌ | ❌ | ✅ | ✅ | 应用部署 | | **gVisor** | 用户态内核 | ~100ms | 较高 | ❌ | ❌ | ✅ | ✅ | Cloud Run | | **Kata Container** | 轻量 VM | ~1s | 较高 | ❌ | ❌ | ✅ | ✅ | 高安全容器 | | **Firecracker（裸）** | microVM | ~125ms | ~5MB+guest | ❌ | ❌ | ❌ | ✅ | 需自行集成 | | **E2B Cloud** | Firecracker | ~150ms | ~1GB 配额 | ❌ | ❌ | ✅ | 部分 | Agent 托管 | | **ZeroBoot** | KVM CoW fork | **0.79ms** | ~265KB | ❌ | ❌ | ❌ | ✅ | 一次性代码 | | **Cube Sandbox** | RustVMM+KVM | ~60ms | ~5MB | ❌ | ❌ | ❌ | ✅ | 轻量沙箱 | | **OpenSandbox** | Docker | ~500ms | 容器级 | ❌ | ❌ | ✅ | ✅ | AI Agent | | **AgentENV** | Firecracker+自研存储 | **~50ms**(恢复) | ~5MB+guest | **✅** | **✅** | **✅** | **✅** | **多Agent RL** | ### 3.2 关键能力对比 | 能力 | AgentENV | E2B Cloud | ZeroBoot | Docker | OpenSandbox | |------|----------|-----------|----------|--------|-------------| | pause → resume | ✅ <100ms | ❌ | ❌ | ❌ | ❌ | | fork 分叉 | ✅ 毫秒级 | ❌ | ❌ | ❌ | ❌ | | 增量快照 | ✅ 数 MB | ❌ | ❌ | ❌ | ❌ | | 按需加载镜像 | ✅ overlaybd | ❌ | ❌ | ✅ layers | ❌ | | 内存热扩容 | ✅ ballooning | ❌ | ❌ | ❌ | ❌ | | 多节点集群 | ✅ | ✅ | ❌ | ✅ | ✅ | | E2B API 兼容 | ✅ | 原生 | ❌ | ❌ | ❌ | | 自托管 | ✅ | ❌ | ✅ | ✅ | ✅ | | 完整 Linux 内核 | ✅ Firecracker | ✅ FC | ✅ KVM | ❌ 共享内核 | ❌ 共享内核 | ### 3.3 深入对比：AgentENV vs E2B Cloud E2B Cloud（Execute 2 Build）是最知名的托管沙箱平台，被 Manus、Perplexity 等产品采用。AgentENV 可以看作 E2B 的自托管开源等价物，但远不止于此。 | 维度 | E2B Cloud | AgentENV | |------|-----------|----------| | 运行方式 | SaaS 托管 | 自托管 | | 快照 | ❌ 不支持 | ✅ 增量快照，<100ms | | 分叉 | ❌ 不支持 | ✅ 毫秒级 fork | | 开放程度 | 部分开源（Python SDK） | **完全开源** | | 自定义镜像 | 有限 | 任意 OCI 镜像 | | 大规模并行 | 有限，受配额限制 | **无限制**，自托管集群 | | 成本 | 按使用付费 | 自持硬件，边际成本低 | **关键区别**：E2B 是产品，AgentENV 是基础设施。AgentENV 提供了 E2B 没有的快照/分叉能力，这是多 Agent RL 训练的核心需求。 ### 3.4 深入对比：AgentENV vs ZeroBoot ZeroBoot（ICICLE 项目）是另一个极简方案，基于 KVM CoW fork 实现 0.79ms 启动。但 ZeroBoot 的目标场景与 AgentENV 完全不同。 | 维度 | ZeroBoot | AgentENV | |------|----------|----------| | 启动时间 | 0.79ms | 50ms（从快照恢复） | | 快照 | ❌ 无持久快照 | ✅ 持久化快照 | | 文件系统 | CoW fork（同父 clone） | overlaybd 分层镜像 | | 网络 | 无隔离 | 独立命名空间 + iptables | | 分布式 | ❌ 单机 | ✅ 多节点集群 | | 适用场景 | 一次性代码执行 | 长轨迹 RL 训练 | ZeroBoot 的启动时间确实惊艳，但它不支持持久化快照、不支持分布式、不支持复杂网络隔离。AgentENV 牺牲了启动时间（50ms vs 0.79ms），但换来了完整的多 Agent RL 训练所需的所有能力。 ### 3.5 深入对比：AgentENV vs Docker Docker 是最简单的沙箱方案，但它的缺陷在多 Agent RL 场景中无法忽略： | 维度 | Docker | AgentENV | |------|--------|----------| | 隔离 | 共享内核（namespace） | 独立内核（microVM） | | 安全 | cgroup 逃逸风险 | 硬件级隔离（KVM） | | pause/resume | ❌ pause 后容器停止 | ✅ 完整状态恢复 | | fork | ❌ 基于镜像重复启动 | ✅ 毫秒级 fork | | 高保真 | 共享宿主机内核 | 完整 Linux 内核 | | 镜像存储 | 全量层下载 | overlaybd 按需加载 | **共享内核的代价**：Docker 容器共享宿主内核，这意味着：1）容器内的 syscall 逃逸可能影响宿主机和其他容器；2）容器看到的 /proc 等内核接口不真实；3）暂停只能 `docker pause`（冻结进程，非状态快照），恢复后网络连接等内核状态会丢失。 --- ## 第四篇：为什么 AgentENV 更适合多 Agent RL？ ### 4.1 核心论点 > **多 Agent RL 训练要从传统 RL 的单线程循环升级为"生成 → 执行 → 反馈 → 更新"的大规模并行流水线。AgentENV 是这个流水线中负责"执行"环节的高性能、可快照、可分叉的沙箱基础设施。** ### 4.2 逐一对应五个硬需求 | 硬需求 | AgentENV 如何满足 | 技术原理 | |--------|------------------|---------| | **大规模并行** | 预热池 + 快照恢复 <50ms + 多节点集群 | 预热池跳过网络/块/FC 创建，快照恢复比冷启动快 10×+，集群横向扩展 | | **pause/resume** | 暂停 <100ms，恢复 <50ms，零资源占用 | overlaybd 增量快照 + ublk 内存恢复 + 快照仓库 | | **分叉（fork）** | 毫秒级从运行中沙箱克隆子沙箱 | 共享 Base Layer + 独立 Delta + ublk 共享内存 | | **高保真环境** | Firecracker microVM，独立内核 | KVM 硬件虚拟化，完整 Linux 内核 | | **强隔离** | 独立 VM，KVM 硬件隔离 | iptables + netns + 独立内核 | ### 4.3 pause/resume 的实际价值 想象一个典型的 RL 训练循环： ``` for each prompt in dataset: LLM 生成 completion（GPU 推理，几秒到几十秒） Agent 在沙箱中执行（CPU 密集型，可能几分钟） 计算 Reward 更新模型参数 ``` 如果没有 pause/resume，Agent 执行期间沙箱一直占用内存。如果同时有 10,000 个 Agent 实例在等待 LLM 推理结果，就需要 10,000 倍物理内存——这在现实中不可能。 有了 pause/resume： ``` 1. Agent 在沙箱中执行到某一步（如运行到一半的测试） 2. Agent 等待 LLM 生成下一步决策 → **pause 沙箱（~50ms）** → 释放内存 3. LLM 返回决策 → **resume 沙箱（~30ms）** → Agent 继续执行 4. 循环 n 步后结束 ``` 实际效果：**10,000 个沙箱并发只需要 2,000 份物理内存**——8,000 个处于 paused 状态，零资源占用。这称为**时间片复用（time-sliced oversubscription）**，是大规模 RL 训练的关键经济性来源。 ### 4.4 fork 的实际价值 分叉能力在以下场景中极其有用： **场景一：探索多条路径** ``` Agent 在调试一个 bug——找到了 3 个可能的根因 │ ├── fork → 沙箱 B：验证根因 1（安装调试工具，检查路径 A） ├── fork → 沙箱 C：验证根因 2（修改配置，检查路径 B） └── fork → 沙箱 D：验证根因 3（打补丁，检查路径 C） 所有 fork 完成后，对比结果 哪个根因正确就取哪个路径 ``` **场景二：多轮对抗训练** ``` Agent A 生成了一组 yaml 文件 │ ├── fork → Agent B：编写 Prompt 注入攻击，尝试突破 Agent A 的安全性 ├── fork → Agent C：验证配置正确性 └── fork → Agent D：执行性能测试 三个 fork 独立运行，互不干扰 ``` **场景三：超参数探索** ``` 一段已完成训练的基准代码 │ ├── fork → 变体 1：调整 prompt style ├── fork → 变体 2：增加思考步数 ├── fork → 变体 3：更换工具调用方式 └── fork → N：更多变体... ``` 没有 fork，你就要为每个变体从零启动沙箱、重新安装所有依赖、重新初始化环境。有了 fork，一次基准初始化，所有变体共享。 ### 4.5 多步推理链 + 快照的组合优势 Agent 在复杂场景中需要多步推理链（Chain-of-Thought with Execution）。例如，一个代码生成 Agent 可能需要： ``` Step 1: 写代码 → 生成二进制文件 Step 2: 运行 → 检查输出 Step 3: 发现错误 → 根据错误信息修改代码 Step 4: 重新编译运行 Step 5: 重复直到通过测试 ... Step N: 完成 ``` 每一步之间都有 LLM 推理延迟。如果没有快照： - 整个执行过程可以长达数十秒到数分钟 - Agent 必须全程占用沙箱资源 - 如果 LLM 推理失败（OOM、超时），Agent 的工作全部丢失，需要从头重来 有了快照： - 每完成一步就**显式创建快照**（保存 checkpoint） - LLM 推理期间沙箱处于 paused 状态，零资源消耗 - 如果 LLM 或 Agent 崩溃，从最近的 checkpoint 恢复，而不是从头开始 - **真正实现了"训练过程可暂停、可恢复、可检查"，这对于百万轮次的训练是必备的** ### 4.6 成本与效率 大规模 RL 训练的成本主要由两部分构成： 1. **GPU 算力**（训练推理） 2. **沙箱资源**（CPU + 内存 + 磁盘） AgentENV 的优化直接作用于第二部分： | 优化 | 效果 | |------|------| | overlaybd 按需加载 | 无需为每个沙箱完整下载镜像，共享 Base Layer | | 增量快照 | 快照大小数 MB 而非数 GB | | pause/resume | 内存利用率提高 5-10×（时间片复用） | | 共享页缓存 | 同一镜像/快照的多个沙箱复用 Linux 页缓存 | | 内存 ballooning | 归还可回收的客户机内存给宿主机，维持高超配比 | ### 4.7 真正的场景：Kimi K3 训练 AgentENV 的诞生直接服务于 Kimi K3（2.8T 参数的混合专家模型，MoE）的 RL 训练。Kimi K3 在多项基准测试（AIME 2025、GPQA、LiveCodeBench、SWE-bench）中超越了 GPT-5 和 Claude 4。 Kimi K3 的 RL 训练需要： - 同时运行数万个 Firecracker 沙箱 - 每个沙箱运行完整的 Linux 环境 - 支持长轨迹（代码编写 + 运行 + 调试 + 验证的多轮循环） - 支持**分叉**以并行探索不同的 Agent 行为路径 - 支持**快照暂停/恢复**以实现资源的时间片复用 AgentENV 的训练流程简化示意： ``` 训练数据集（百万级 Prompt） │ ▼ ┌────────────────────────────┐ │ GPU 集群（LLM 推理/训练） │ │ （每个 Prompt 采样 N 份） │ └──────┬─────────────────────┘ │ N 份 completions ▼ ┌────────────────────────────┐ │ AgentENV 沙箱集群 │ │ （数万个 microVM） │ │ │ │ Sandbox 1: 执行 completion A │ Sandbox 2: 执行 completion B │ ... │ │ Sandbox N: 执行 completion N │ │ │ 支持 pause/resume/fork │ └──────┬─────────────────────┘ │ N 份执行结果 ▼ ┌────────────────────────────┐ │ Reward 计算（GRPO） │ │ 组内相对比较，计算奖励 │ └──────┬─────────────────────┘ │ Reward 信号 ▼ ┌────────────────────────────┐ │ 模型参数更新（训练器） │ └────────────────────────────┘ ``` --- ## 第五篇：快速上手指南 ### 5.1 安装 ```bash # 方式一：安装脚本（Ubuntu 24.04） curl -fsSL https://raw.githubusercontent.com/kvcache-ai/AgentENV/main/scripts/install.sh | sudo bash sudo systemctl start aenv # 方式二：Docker curl -fsSL https://raw.githubusercontent.com/kvcache-ai/AgentENV/main/scripts/docker-setup.sh | sudo bash docker pull ghcr.io/kvcache-ai/aenv-server:latest docker run -d --privileged -v /dev:/dev -p 8000:8000 ghcr.io/kvcache-ai/aenv-server:latest # 安装 CLI（macOS/Linux 均可） curl -fsSL https://raw.githubusercontent.com/kvcache-ai/AgentENV/main/scripts/install-cli.sh | bash ``` 前提条件： - Linux 宿主机，内核 6.8+ - `/dev/kvm` 访问权限 - 建议 Ubuntu 24.04 ### 5.2 快速入门 ```bash # 认证 aenv auth # 拉取模板并启动沙箱 aenv pull ubuntu:22.04 --name ubuntu aenv start ubuntu # 启动并进入交互式 shell # 沙箱管理 aenv ls # 列出所有沙箱 aenv pause <sandbox-id> # 暂停沙箱（保存快照） aenv resume <sandbox-id> # 恢复沙箱 aenv delete <sandbox-id> # 删除沙箱 # 分叉（fork） aenv fork <sandbox-id> # 克隆一个子沙箱 # CLI 参考 aenv pull docker.io/library/ubuntu:latest --name ubuntu # 从 Dvckr Hub 拉取 aenv template list # 列出所有模板 aenv start ubuntu --detach # 后台启动 aenv cn <sandbox-id> # 重新连接到沙箱 shell aenv exec <sandbox-id> ls # 执行单次命令 aenv timeout <sandbox-id> 600 # 延长超时 ``` --- ## 总结 ### AgentENV 的独特性 1. **它是第一个为 RL 训练设计的沙箱平台**——已有的沙箱方案（Docker、微虚拟机、E2B）都面向"运行应用"或"一次性代码执行"，没有一个专注解决 RL 训练中的快照、pause/resume、fork 需求。 2. **它填补了 RL 基础设施的关键空白**——RL 训练领域已有成熟的训练框架（vLLM、DeepSpeed、TRL）、数据集工具、评估基准，但沙箱基础设施一直是一个"自己手搓"的黑盒子。AgentENV 将这个黑盒子变成了标准的开源平台。 3. **它证明了"基础设施创新推动 AI 能力"**——Kimi K3 的出色表现背后，AgentENV 是关键的支撑。没有高效的沙箱基础设施，大规模多 Agent RL 训练的成本会高到不经济。 4. **它降低了自托管门槛**——E2B 兼容 API 意味着迁移成本极低，已有的 Agent 工作流可以直接复用。 ### 适合的场景 | 场景 | 推荐 | |------|------| | 多 Agent RL 训练（代码生成、工具调用、Agent 任务） | ✅ **强烈推荐** | | 大规模并行沙箱（100+ 实例） | ✅ **强烈推荐** | | 长轨迹 Agent 验证（多步推理链） | ✅ **强烈推荐** | | 对抗训练 / 博弈训练 | ✅ **推荐** | | 需要 pause/resume 的场景 | ✅ **推荐** | | 一次性代码运行（几十毫秒级） | ⚠️ ZeroBoot 更适合 | | 简单 web 应用部署 | ❌ Docker 够用 | ### 一句话总结 > **AgentENV 是把"多 Agent 大规模强化学习"从只能大厂秘密造轮子的黑盒，变成了每个人都能部署的开源基础设施。它是 Kimi K3 背后的"隐藏引擎"，是理解 AI 后训练时代不可或缺的一环。** --- ## 参考链接 - [AgentENV GitHub 仓库](https://github.com/kvcache-ai/AgentENV) - [AgentENV 官方文档](https://kvcache-ai.github.io/AgentENV/) - [Kimi K3 开源说明](https://kimi-k3.github.io/) - [Firecracker microVM](https://firecracker-microvm.github.io/) - [OverlayBD 项目](https://github.com/containerd/overlaybd) - [ublk 内核文档](https://docs.kernel.org/block/ublk.html) - [GRPO: Group Relative Policy Optimization (DeepSeek)](https://arxiv.org/abs/2402.03300) - [E2B Platform](https://e2b.dev)

bsakaguchi closed this issue 2026-10-29 14:18:40 +00:00

bsakaguchi referenced this issue 2026-10-29 14:19:10 +00:00

[GH-ISSUE #259] Add scheduler HA using Kubernetes Lease leader election #71

bsakaguchi referenced this issue 2026-10-29 14:20:37 +00:00

[PR #89] [MERGED] feat(cli): add shell completion scaffolding #172

bsakaguchi referenced this issue 2026-10-29 14:21:09 +00:00

[PR #163] [MERGED] experiment(cli): evaluate clap dynamic completion #219

bsakaguchi referenced this issue 2026-10-29 14:21:09 +00:00

[PR #164] [CLOSED] experiment(cli): evaluate AgentENV-owned completion hook #221

bsakaguchi referenced this issue 2026-10-29 14:21:41 +00:00

[PR #231] [MERGED] docs(cli): restore shell completion section #272

bsakaguchi referenced this issue 2026-10-29 14:21:52 +00:00

[PR #250] [MERGED] feat(cli): complete template and snapshot names dynamically #291

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

coverage-data

gh-pages

v0.3.0-rc.1

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.3

v0.1.2

v0.1.1

v0.1.0

Labels

Clear labels   

bug

  

documentation

  

enhancement

  

enhancement

  

pull-request

Mirrored from GitHub Pull Request

No labels

bug

documentation

enhancement

enhancement

pull-request

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

kvcache-ai/AgentENV#37

No description provided.