Moonshot AI 的 Kimi 团队与 kvcache-ai 已开源 AgentENV（AENV），这是一个面向大规模运行智能体环境而设计的分布式平台。AgentENV 用于 Kimi K3 的智能体强化学习（RL）训练；Kimi K3 是 Moonshot 的 2.8 万亿参数 Mixture-of-Experts 模型。该项目基于 MIT 许可证发布。

为什么环境基础设施会成为智能体 RL 的瓶颈

智能体 RL 需要的不只是从模型中采样文本。它要求模型在真实的计算机环境中执行操作。每次 rollout 都需要一个隔离的 Linux 环境，其中包含文件系统、网络栈和正在运行的进程。在这种训练循环中，环境是数据生成路径的一部分，因此重置速度、隔离性，以及复现或分支任务状态的能力，会直接影响可收集的有效 rollout 数量。

这一要求带来了困难的基础设施取舍。容器可以快速启动，但会共享宿主机内核，因此在执行模型生成的代码时隔离性较弱。完整虚拟机提供更强的隔离，但启动更慢，并且在空闲时仍会占用内存。

AgentENV 旨在弥合这一差距。它运行 Firecracker microVM，并力图让空闲状态、重启和分支的成本足够低，以支持训练规模的工作负载。

AgentENV 基于 Firecracker 的架构内部

每个 AgentENV 沙箱都作为一个 Firecracker microVM 运行，拥有自己的 Linux 内核、文件系统和网络命名空间。请求通过 Axum HTTP API 接收，并转发给负责管理沙箱生命周期的编排器。

存储是该设计的核心部分。根文件系统通过 ublk 用户态块设备提供服务，后端由 overlaybd 分层镜像支持。只读基础层在多个沙箱之间共享，而每个沙箱都会写入自己的上层。

在每个 guest 环境内部，一个名为 envd 的守护进程负责命令执行、文件操作和端口 49983 上的健康报告。反向代理将来自客户端的 HTTP 和 WebSocket 流量路由到虚拟机内部运行的服务。

该项目还描述了两种提升密度的机制。宿主机页缓存会在存储数据和内存快照数据之间共享。内存 ballooning 会将可回收的 guest 内存归还给宿主机，从而在环境随时间分化时帮助维持超额分配。

快照、暂停、恢复和 fork

快照、暂停、恢复和 fork 是 AgentENV 的核心功能。该系统以增量方式对内存和文件系统变更进行快照，而不是每次都写入完整镜像。

项目公布的性能数据显示，由快照支持的环境可在 50 ms 内启动或恢复，并在 100 ms 内暂停。即使在磁盘大量修改的情况下，增量快照捕获也据称可在 100 ms 内完成。

Fork 是最贴近 RL 工作负载的功能。一个正在运行的沙箱可以在同一节点上克隆出最多 16 个独立子沙箱。源环境在捕获期间会短暂暂停，然后恢复运行。每个子沙箱都会继承源文件系统、内存和资源配置。

其实际效果是，昂贵的初始化可以只执行一次。团队可以安装依赖、克隆代码库，并进入某个任务状态，然后将该精确状态分支为并行 rollout。对于需要从同一预置状态开始反复试验、但探索不同动作轨迹的智能体任务来说，这一点很重要。快照可以持久化到与 S3 兼容的对象存储，或持久化到共享分布式文件系统。

一个默认行为值得注意：每个沙箱都有 TTL，到期会触发暂停而不是删除。若要删除，需要在 create API 中传入 autoPause: false。

按需加载与快照仓库

镜像通过 overlaybd 按需加载。本地磁盘充当有界缓存，保留热数据并淘汰冷数据。

这种设计支持集群级运行，因为节点不需要预热每个镜像，也不需要存储每个快照的完整副本。可寻址镜像集因此可以超过本地磁盘容量，同时在整个集群中保持快速启动。

快照状态被组织为三层。builder 暂存工作区在构建期间保存产物。已提交的快照仓库作为持久化的事实来源。节点本地运行时缓存保存启动时派生的配置。

支持两种仓库后端：默认的 posix_fs，以及 oss。oss 路径使用共享的 S3 兼容客户端，因此需要显式指定 region。

AgentENV 还包含一个基于 iroh 的可选点对点传输机制，可向对等节点发布已提交产物。该功能默认禁用。文档明确指出，P2P 不会改变已提交快照模型。对于共享存储，文档要求至少 1 Gbps，并强烈建议 10 Gbps 或更快。

以 E2B 兼容性作为采用路径

AgentENV 暴露了与 E2B 兼容的 HTTP API。用户只需将 E2B_API_URL 指向 AgentENV 服务器，即可在不修改代码的情况下运行官方 E2B Python 或 TypeScript SDK。

这种兼容性是一项有意为之的分发选择。已经在 E2B 上运行智能体的团队，可以在不重写智能体代码的情况下自托管运行时。AgentENV 还提供原生 aenv CLI，文档建议在 AgentENV 特定工作流中使用它。

部署选项

AgentENV 要求 Linux kernel 6.8+ 并可访问 /dev/kvm；安装脚本还额外要求 Ubuntu 24.04。aenv CLI 支持 x86_64 和 arm64 上的 Linux 与 macOS。服务器本身仅支持 Linux，因为它需要 KVM。

文档描述了五种部署路径：

• 通过安装脚本将服务器作为 systemd 服务运行
• 发布在 ghcr.io/kvcache-ai/aenv-server 的 Docker 镜像
• 用于模拟多节点集群的 Docker Compose 栈
• 包含 gateway、scheduler 和节点 DaemonSet 的 Kubernetes manifests
• 使用 Rust 工具链从源码构建

多节点部署会增加一个位于 :8080 的 gateway，以及一个位于 :9090 的 scheduler。多节点控制平面在文档中被描述为原型，因此集群调度的成熟度，以及共享存储相关的运维要求，是团队评估更大规模部署时的关键细节。

AgentENV 将每个智能体环境作为 Firecracker microVM 而不是容器运行，从而提供内核级隔离。该项目报告称，基于快照的启动或恢复时间低于 50 ms，暂停时间低于 100 ms。一个正在运行的沙箱可以在同一节点上 fork 出最多 16 个独立子沙箱，并且与 E2B 兼容的 HTTP API 允许现有 E2B Python 和 TypeScript SDK 代码无需修改即可运行。