AKernel 0.1.0 到 0.1.6rc1：蚂蚁智能体内核六版演进全记录

一句话结论

蚂蚁 inclusionAI 的智能体内核 AKernel 在一个多月里密集迭代：从 7 月 22 日的首次公开版本 v0.1.0，到 8 月 31 日的 v0.1.6rc1，六个公开版本累计 50 次提交，把「智能体申请一个隔离沙箱」这件事从最小可用推到了生产可用——Kata Containers 与 Firecracker 两种新运行时、NVIDIA GPU 整卡沙箱、创建时网络策略、Dockerfile 直接启动、同节点故障恢复相继落地。本站此前介绍过 AKernel 的体系全景、sandboxd 沙箱管理组件以及 0.1.6 线的 rc2、rc3 更新，本文把这六个版本的演进链完整补上，也是理解后续版本的基础。

v0.1.0：最小可用的智能体沙箱

7 月 22 日发布的 v0.1.0 是 AKernel 的第一个公开版本，核心内容是把「申请沙箱、执行命令、读写文件」做成一套 Python SDK 和 CLI：with Sandbox(cpu=2000, memory=4096) 申请一个指定 CPU 与内存配额的隔离沙箱，沙箱内可以执行命令、操作文件系统和 PTY 终端。运行时默认采用 gVisor（系统调用拦截隔离），镜像是一次性构建的 all-in-one 仓库镜像，部署覆盖单机、私有云和公有云三种形态，监控和 Dragonfly 分布式存储为可选项。

这一版确立的项目定位值得注意：AKernel 不做基础设施供给（那是 Kubernetes、Terraform 的领域），而是做运行时——智能体、强化学习训练和数据流水线需要的弹性、动态工作流和对数据中心能力的程序化访问。站内的体系全景文章对此有完整分析。

v0.1.1：Kata Containers 第二运行时

7 月 26 日的 v0.1.1 补上了第二种隔离技术：Kata Containers 4.0。KVM 节点（有 /dev/kvm 设备）可以在创建沙箱时指定 Sandbox(runtime="kata") 切换到轻量虚拟机隔离，gVisor 仍是默认值，SDK 里附了可运行的示例。Kata 的集成覆盖单机、Helm 私有云、阿里云和华为云部署形态；没有 KVM 的节点继续跑 gVisor 工作负载，不广播 Kata 能力。底层同步升级到 openYuanRong SDK 0.9.2，改善了反向隧道可靠性，构建可复现性与 CI 覆盖也有提升。

对选型隔离技术的团队，这版的实际意义是：AKernel 开始把「隔离强度与启动速度的取舍」变成一个 SDK 参数，而不是部署期的全局决策。

v0.1.2：网络策略、GPU 沙箱与 Rust 运行时默认化

8 月 14 日的 v0.1.2 是这批版本里功能密度最高的一个，四条主线：

网络管控。创建沙箱时可以设置整段封锁网络、精确或通配符 DNS 黑名单策略——对执行不可信代码的智能体平台，这是「默认不给网、按需放行」的基础能力。实验性 TC eBPF bpfnat 作为 NAT 的新后端加入，iptables 仍是默认。

GPU 沙箱。实验性整卡 NVIDIA GPU 沙箱基于 gVisor 的 nvproxy 实现，创建时指定 GPU 型号与数量（如 gpu:l20:1），沙箱内 nvidia-smi 可见设备；配套的可写 rootfs 配额也改为可配置。两者当前都要求 runsc 运行时。对跑推理、训练任务的智能体工作流，这把「申请一张指定型号的卡」变成了一个 SDK 参数。

双后端与运行时。Rust 实现的 RRT 配置成为默认档；SDK 同时支持默认的 openyuanrong-sandbox 后端和可选的 actor 模式 openyuanrong-sdk 后端，升级到 openYuanRong 0.9.7。cgroup v1/v2 透明支持消除了一层宿主机差异。

v0.1.4：存储可移植与轻量部署

8 月 17 日的 v0.1.4 把默认存储切到可移植的 loop-backed ext4 文件存储，XFS 保留为选项——降低了对节点文件系统类型的依赖；all-in-one 镜像允许省略 Kata 负载，没有 KVM 的环境也能用官方镜像部署；SDK 网关默认值修复与沙箱清理可靠性改进属于工程修复面。

v0.1.5：Dockerfile 直接启动沙箱

8 月 21 日的 v0.1.5 解决「沙箱里跑什么」的高频问题：直接用一个经过校验的严格 Dockerfile 子集和本地构建上下文启动沙箱，不需要 BuildKit、Docker daemon 或推送镜像仓库。这对智能体代码执行平台意味着可以直接复用团队现有的容器化定义,而不是为沙箱单写一套。runc 运行时在此版成为可选项（跨镜像构建、单机、Helm、Terraform 全线支持），gVisor 保持默认；沙箱清单、CPU、内存的 Grafana 监控面板基于 sandboxd 当前指标恢复；组件升级到 openYuanRong 0.9.9，配置的 OCI 代理被确保生效。

v0.1.6rc1：Firecracker microVM 与同节点恢复

8 月 31 日的 v0.1.6rc1 开启 0.1.6 线：KVM 节点接入 Firecracker microVM 支持（覆盖单机、Helm、Terraform 三种部署），SDK 新增 Sandbox(failover=True) 和 Sandbox.reload() 实现同节点恢复——runsc 和 Firecracker 负载可以 checkpoint 后重载同一逻辑沙箱，沙箱挂掉不必换节点重来。配置独立网关时，命令执行与文件传输保持在 AKERNEL_SERVER_ADDRESS 上,避免跨网关路由绕行；运行时镜像保留静态链接的 tini 作为 PID 1，规范容器内进程信号处理。

0.1.6 线后续的 rc2 补齐了 Firecracker 的 OCI/Nydus 镜像支持与双向网络策略，rc3 做运行时感知调度与节点级修复，站内均有成文。

对使用者的实际意义

这条版本演进链对三类使用者有直接参考价值。构建智能体代码执行平台的团队：v0.1.2 的创建时网络策略、v0.1.5 的 Dockerfile 直接启动、v0.1.6rc1 的同节点恢复，分别对应「不可信代码怎么控网」「沙箱环境怎么复用既有定义」「沙箱挂了怎么快速恢复」三个高频工程问题，且都以 SDK 参数而非部署改造的方式解决。选型隔离技术的团队：gVisor（默认）、Kata（v0.1.1）、Firecracker（v0.1.6rc1）、runc（v0.1.5）四种运行时在一个 SDK 下统一抽象，按沙箱粒度切换，隔离强度与启动速度的取舍从架构决策降为参数决策。给智能体分配 GPU 资源的团队：v0.1.2 的整卡 NVIDIA 沙箱把设备申请做成了 SDK 参数，沙箱内 nvidia-smi 可见。

版本间隔也能看出节奏：7 月两版、8 月四版，功能主线（网络→GPU→存储→镜像→恢复）每版聚焦一条，预发布版本（rc 线）与正式版并行推进。仓库当前 39 星，Apache-2.0 协议，2026-07-11 创建。

原文信息

原文地址： 作者：inclusionAI（蚂蚁集团开源组织） 开源协议：Apache-2.0 项目地址：