从 Computer Use到 Datacenter Use：如何让 AI Agent 像调用函数一样驱动数据中心？

作者｜谈鉴锋、周天昱

编辑｜Kitty

策划｜QCon 全球软件开发大会

本文整理自 QCon 全球软件开发大会·2026（北京站）明星讲师蚂蚁集团操作系统研发经理谈鉴锋、高级开发工程师周天昱的演讲分享《From Computer Use to Datacenter Use for AI》。

以下是演讲实录。

大家好，非常荣幸有这个分享的机会。先做一个铺垫——如果这场四十多分钟下来，大家只需要记住一个词，那这个词就是Datacenter Use。这是我们目前正在全力攻克的一道题。

在 Agent 的时代，大家现在听到的都是：给 Agent 一台电脑，让它自己去工作。在这个虚拟世界里面调各种 Skill，调各种 MCP，把大模型服务高效地运转起来。

但是我们对 Agent 往下一阶段发展的判断，有两个趋势。

第一个趋势叫 Multi-Agent。将单一 Agent 拆分为多个角色——产品经理、开发者、测试工程师——通过角色协作与讨论得出更优的结果。本质上是把一个"大脑"分解为多个分工明确的角色，以协同方式完成任务。

第二个趋势，是我们这次分享想要强调的——Datacenter Use。如果拥有一个足够聪明的大脑，它真正需要的不是更多角色的配合，而是更强的执行能力——直接驱动整个数据中心的算力为其所用。

以一个具体场景为例：构建一个炒股 Agent，它所需要的远不止一个足够聪明的大模型。即便模型能力再强，也无法直接理解一整年的完整交易数据。它必须自行编写程序，遍历过往数年的历史数据，并持续迭代优化模型——这一过程的核心瓶颈在于算力。Datacenter Use 说的就是，能不能给 Agent 提供一个它马上就能直接用的算力。这是我们整体方向的出发点。

现有基础设施，有哪些问题？

理解了这个概念，我们再来审视现有基础设施存在的深层问题。

自 2015 年容器与云原生兴起以来，整个行业按照 Gartner 成熟度曲线的规律经历了炒作期、低谷期，发展至今已进入相对成熟的落地阶段。相信每家公司都有体感，尤其是中大型的公司，现有基础设施普遍呈现纵向分层、横向分域的架构——纵向涵盖IaaS、PaaS、SaaS三层，横向划分存储、计算、网络、调度四个域。这一架构虽然层次清晰，但也带来了大量跨层协调的复杂性与协同成本。

现有云原生技术在支撑大促活动、故障容灾等场景方面都表现得非常优异，但它们靠的是什么？是演练，靠日复一日地磨合。以双十一为例，最初需要长达半年的准备周期，逐步压缩至三个月、再到一个月。这种进步的背后，是大规模的人力投入与反复演练的成本。

对 AI Agent 而言，这套节奏完全无法适用。Agent 需要的是分钟级甚至秒级的即时可用算力——不是"准备好了再用"，而是"当下就要有"。

因此我们看到了一个核心的痛点：尽管云原生基础设施的工业化程度已经相当成熟，但要让 Agent 真正按需调用这些算力资源，二者之间仍存在难以忽视的鸿沟。还有一个现实约束同样无法回避：为保障 Agent 的运行而专门维护一支五十人的运营团队，无论从成本还是效率来看都难以为继，这也是我们为什么要解这个问题的核心原因之一。

我们在解的题：

Build Your Own Cluster

在 Datacenter Use 的基础上，我们还重点解决了一个问题——Build Your Own Cluster。

Agent 真正的服务对象，有可能是每一位 C 端用户。这意味着每个用户旗下的众多 Agent，都需要具备 Datacenter Use 的能力。这要求 Agent 能够在全球算力资源中自主寻找低成本的计算节点，动态完成多云环境下的集群调度与构建。Build Your Own Cluster 说的就是这件事。

在探索解题路径的过程中，我们发现 openYuanrong 的设计理念与我们的方向高度契合，这里先来回顾一下它的几个关键设计。

openYuanrong 有一个我们觉得非常厉害的点——分布式内核。openYuanrong 从立项之初便将分布式内核作为核心方向，围绕计算、网络、存储的统一设计构建整套系统。我们一直在思考如何将系统边界收窄、技术半径缩小，而分布式内核的理念与这一目标高度吻合。

此外，openYuanrong 提供了一套 native 存储系统，也就是它的 Data System。传统强一致性分布式存储的收敛时间极长，但 Agent 场景真的需要这种强一致性吗？其实不需要。Agent 真正需要的是"算力在哪里，就在哪里搭一套足够可用的存储系统"。 Data System 原生提供了 Object 对象存储与 Key-Value 存储，可以直接覆盖大多数场景的存储需求，省去了单独部署 Redis 等组件的成本。

这里还有一个值得深思的逻辑：什么是一个 Object？一个 Tensor 是不是就是一个 Object？当数据中心向智算时代演进，openYuanrong 的存储抽象与 AI 工作负载在概念层面天然契合，两套系统的融合远比表面看起来更为深入。

AKernel：三人如何

撑起一套数据中心

我们对这道题的解是 AKernel——一套为上层用户提供即时可用算力的基础设施。

在实际维护中，AKernel 不仅依赖 openYuanrong，还集成了多个开源组件，所有内容统一在同一个代码库中管理。

为什么要用统一代码库？

原因在于我们在日常研发中以 Agentic 的方式使用 AI 进行开发，统一代码库能让 AI Agent 获取完整的项目上下文，将所有子项目有效串联。

举一个简单的例子：在结合 openYuanrong 与 AKernel 底层 AFaaS 节点侧进行容器拉起时，我们曾遇到一个线上故障。当时将 Grafana 监控数据与整个大仓代码一并提供给 Claude，它在五到十分钟内便定位出了具体的故障原因。 若不同模块分散在各团队独立维护，版本对齐、接口协议、问题定界都将带来大量隐性协作成本；而大仓模式不仅让版本管理更加可控，也让 AI 辅助研发真正能够发挥效能。

这里有一个值得特别说明的数字——整个 AKernel 集群的研发与运维，不到三人。

以前维护一套完整的基础设施栈——Kubernetes、节点侧操作系统内核、上层调度系统、分布式存储——通常需要三十到五十人以上的团队。但现在我们通过极致轻量化的架构设计，结合 AI 驱动的研发模式，可以将需求分析、研发实现、测试验证与运维保障打通为单人可端到端覆盖的完整工作流。这打破了"基础设施建设必须依赖大规模团队"的固有认知。

架构详解：一个请求的完整旅程

这是 AKernel 的整体架构图。图中以三种颜色区分了不同来源的组件：

• 橙色：openYuanrong 的核心组件

• 绿色：已开源的社区组件

• 蓝色：AKernel 自研组件，计划后续开源

我们从端到端来讲述一下这套架构到底是怎么玩的？以创建一个 Agent Sandbox 为例：

• 用户通过 SDK 或 CLI 发起资源请求，流量经由公网 IP 进入 Traefik 流量网关，网关根据资源类型进行路由分发。

• 请求被路由至 openYuanrong 函数系统的 Gateway_（统一入口）_，转发至中心调度器，调度器选定空闲节点后完成任务调度。

• 节点侧部署了 Proxy 组件 （类似 Kubernetes 中 Kubelet 的角色，由 openYuanrong 提供），负责统一管理节点资源，并调用节点上的 Sandbox Daemon 创建具体的沙箱。

• 用户定义的代码——无论是自定义 Agent，还是 FaaS 的 UserCode——均在该沙箱内运行。

当不同沙箱之间需要共享数据时，请求会流转到 openYuanrong 的 Data Worker。每个节点都会部署一个 Data Worker，多个 Data Worker 共同构成完整的 Data System，支持跨节点或同节点内基于内存及扩展内存的高速数据交互。对外网络访问则通过我们自研的基于 eBPF 实现的 NAT 组件处理后出公网。

这里还有一个特别值得关注的问题——万级并发下，镜像拉取如何解决？启动单个 Sandbox 时，用户提供一个自定义 Docker 镜像，这没有问题。但当需要同时拉起一万个 Sandbox 时，面对一万个自定义镜像、每个 3-5 GB 的体量，若全部从 Docker Hub 直接拉取，带宽压力根本无法承受。

为此，我们做了一套镜像加载的优化流程，分层来解决这个问题。

第一层： Lazy Load，懒加载。节点上的镜像组件不会在沙箱启动时预先下载完整镜像，而是在用户代码真正访问到镜像内具体文件时，才按需触发对应内容的拉取。大量从未被访问的文件层完全无需下载，从而大幅降低启动阶段的 I/O 开销。

第二层： Dragonfly P2P 加速。集群内部署了 Dragonfly 镜像加速组件，在集群内建立镜像缓存层，通过 P2P 网络在节点间分发镜像内容，将大部分下载流量消化在集群内部，避免所有节点同时向外部仓库发起请求。

两层优化叠加效果显著：未优化前需要分钟级时间，优化后可稳定达到秒级。 这是支撑万级 Sandbox 并发拉起的关键基础能力。

开发者体验：像调用本地函数

一样使用数据中心

AKernel 针对不同场景提供了多种接口，以下重点介绍几个核心能力。

Sandbox API

Sandbox 接口，我们参考了 Modal 和 E2B，提供了一套通用的 Sandbox API，支持：

• 指定沙箱的资源占用 （如 CPU、Memory）

• 指定镜像来源：Docker 镜像 URL_（OCI/Nydus）_，S3、华为 OBS、阿里云 OSS (EROFS image) 均可天然接入

Checkpoint 和 Restore

可对 Sandbox 进行状态快照与恢复，用于故障恢复或状态保存。_（技术细节将在后续技术支柱部分详细展开。）

双向代理

AKernel 提供了本地与 Sandbox 之间的双向网络代理能力：

• 本地 → Sandbox：在集群内的 Sandbox 中运行一个 Server，可将其服务直接暴露至本地，实现本地对 Sandbox 内服务的直接访问。

• Sandbox → 本地：以 RL Rollout 场景为例，本地运行 vLLM 或 SGLang 推理引擎，Sandbox 部署在 AKernel 集群中，通过该代理可实现 Sandbox 对本地推理引擎的访问，完成网络层的双向打通。

多种沙箱运行时

目前，AKernel 已原生支持 Jupyter 与 PyTorch 等轻量级且具备强安全隔离能力的沙箱运行时，后续演进规划中将进一步兼容 QEMU 等更为通用的沙箱环境。除 Sandbox 外，AKernel 亦全面覆盖了 FaaS 与 Spark 等多元化 Workload 的调度与执行。

全链路可观测性

整套 AKernel 集群在拉起的时候就自带了一套完整的监控链路。_ 图 1_ 是针对每一个节点的资源监控，可全景洞察每个节点的 CPU、Memory 及磁盘 I/O 状态。_ 图 2_ 是创建一个 Sandbox 的全链路 Trace，精准记录沙箱创建的端到端耗时分布。以这个具体的例子来看，端到端耗时约 50ms，其中调度阶段耗时约 20+ms，而节点侧沙箱拉起被压缩至 10ms 以内。

三大技术支柱

支撑 AKernel 集群高速、稳定运转的，是三大硬核技术支柱：

支柱一：openYuanrong 分布式调度与数据系统

基于 openYuanRong 的函数系统完成资源的全局调度与管控，利用数据系统实现跨节点或节点内部跨 Sandbox 层次的高效数据共享。openYuanRong 的另一核心优势在于其提供了完整的运行时接入能力，SDK 原生覆盖 C++、Python 与 Go，实现敏捷接入。我们基于此封装了 AKernel SDK，让用户可以快速使用 AKernel 的资源。在数据交互层面，跨节点通信依托网络实现高速流转，而同节点内部则进一步借道共享内存机制实现微秒级提速。

支柱二：极致冷启动——

AFaaS 安全沙箱（OSDI'25）

节点侧 Sandbox 创建的底层核心，依托于我们发表于 OSDI'25 的 AFaaS 按需沙箱技术。前述 Grafana 中 10ms 级的冷启动数据，其底层机制是利用 Linux Kernel 的 clone 系统调用语义，基于预存的沙箱状态实现极速克隆。

AFaaS 的技术实现主要涵盖三大组件：

• 基于 gVisor 演进的 nanovisor，提供轻量级且高安全隔离的沙箱运行时；

• 基于 Rust FUSE 实现的 distill-fs，负责镜像的按需懒加载；

• Dragonfly P2P 加速组件，保障镜像的分发效率。

结合前述的 Lazy Load 和 P2P 镜像分发，这套组合拳使得 Agentic RL 训练 （涵盖蒸馏、评测等环节） 乃至 Agent Swarm 等高并发 Service 场景，都可以实现毫秒级的 Agent Sandbox 拉起。

支柱三：Checkpoint / Restore

全链路状态持久化

我们对 openYuanRong 的函数与数据系统进行了深度改造，以支撑全链路的 C/R_（Checkpoint/Restore）_ 能力。

上图是改造了 openYuanrong 的函数系统和数据系统之后的效果。用户可通过 SDK 或 CLI 主动对已拉起的 Sandbox 发起 Checkpoint，产出的快照镜像将直接存入 openYuanRong 的数据系统；在用户需要做 Restore 的时候，能够快速从数据系统里将这个 Checkpoint 镜像加载出来，通过它做 Restore。

整体链路既可以通过 SDK 和 CLI 让用户主动触发，也可以通过 openYuanrong 的函数系统去检测到闲置的 Sandbox，对它做自动的 Checkpoint 和 Restore。

这套能力在 Agent 时代至关重要。Agent 经常有长会话、长等待、跨阶段执行的特征，如果 Agent 在等待期间持续占用资源，会造成大量浪费；但如果直接释放资源，又会丢失当前状态。C/R 能力使得 Agent 可在待机时挂起并释放算力，唤醒后从断点继续执行，也支持带状态的快速迁移。Agent 不再是一个无状态的短任务容器，而是真正拥有状态保存、状态迁移和状态续跑能力的工作单元。

一站式部署：Terraform + Helm

10 分钟就绪

AKernel 集群从设计之初便锚定一个目标——极致降低部署门槛，让 Build Your Own Cluster 真正落地。

以往，大家更多是直接购买公有云现成资源或泛用型 Sandbox 服务，开发者如果想做一些定制化的需求，自己搭一套集群，其实是壁垒重重的。AKernel 提供的就是这一套能力。

我们想要实现的是：只要把 AKernel 的仓库代码 clone 下来，打开 Claude Code，告诉它"帮我在阿里云的香港区域部署一个 AKernel 集群"，它就会自动完成部署，你只需要提供你的阿里云 AccessKey/SecretKey，系统即自动完成全链路交付。

上图是实测的效果，整个部署过程从 23:18:27 开始到 23:27:06 结束，总耗时 8 分 39 秒，完整覆盖了从 VPC 创建、ACK 集群拉起、Node Pool 初始化到最终 Helm 部署的全链路。

目前已经支持阿里云 ACK 与华为云 CCE，底层通过 Terraform 完成资源创建，再通过 Helm 自动完成组件编排，最终由 Kubernetes 统一部署，整个过程无需人工介入任何部署细节。

运维方面同样做到了极简。我们提供了一套简洁的 CLI 工具，可以 list 集群内所有资源，包括 FaaS、Spark 或者 Sandbox，也可以像 SSH 一样，直接 exec 到 Sandbox 内部查看运行状态。Grafana 仪表盘以及完整的 Trace、日志链路，均已做到开箱即用。

核心逻辑即：对话式指令下达，十分钟集群就绪，监控地址同步返还，浏览器即刻洞察。

实践验证与未来演进

目前，AKernel 全套能力 （Agentic RL 全链路 /Serverless Function/Spark 大数据处理） 已在蚂蚁内部多重场景深耕落地。其核心支撑三要素：集群极速拉起、openYuanRong 高效调度传输、AFaaS 底层极速启动与强安全隔离。

未来，AKernel 还会持续地增加对 GPU、NPU，以及如阿里云含光 NPU 的支持。沙箱方面也将横拓 Windows、macOS、Android 等更加通用的沙箱。

最后，用三句话总结 AKernel 的核心价值：

第一，在 AI 的时代，用小规模团队完成大规模的基础设施工程——少量的人，做大量的事。

第二，在 Agent 时代，不要让基础设施的能力制约 AI Agent 的发挥，以极致优化全面释放 Agent 的算力需求。

第三，让所有的开发者拿到代码，能够即刻部署集群，真正实现 Datacenter Use。

当每个 AI Agent 都能便捷地使用数据中心级的算力，当基础设施的门槛从五十人团队降低到三人小队，AI 时代的基础设施将迎来一次全新的范式转换。

作者介绍

谈鉴锋，蚂蚁集团操作系统研发经理，长期从事操作系统与系统基础设施的研发，在蚂蚁主导打造了 DeepThesis 百 XPU 技术体系，特别是基于 GISA 架构的 Number Five 系统。

周天昱，蚂蚁集团高级开发工程师，现任蚂蚁 AKernel 项目负责人，研究方向聚焦操作系统内核、云原生系统与 AI 系统。

会议推荐

Agent 从 Demo 到工程化还差什么？安全与可信这道坎怎么过？研发体系不重构，还能撑多久？

AICon 上海站 2026，13 大重磅专题已上线，诚挚邀请你登台分享实战经验。AICon 2026，期待与你同行。快来扫码锁定 8 折专属席位或提交演讲议题