从云原生到 AI 原生

信息技术的发展史，是一部计算范式不断演进的历史。从大型机时代的集中式计算，到客户端 - 服务器架构的分布式计算，再到过去十年由微服务和容器化技术定义的云原生时代，每一次范式的跃迁，都旨在解决前一个时代的根本性矛盾，并释放出新的生产力。如今，我们正站在第四次计算浪潮的黎明 ——AI 原生时代。

云原生时代的核心是应用。我们围绕应用构建了以 Kubernetes 为事实标准的容器编排系统，以阿里云函数计算为代表的无服务器计算（Serverless/FaaS），以及一套完整的 CI/CD、可观测性和服务治理理论。这些技术的共同目标是：将单体应用拆解为更小、更独立、更具弹性的微服务，并高效地在云基础设施上进行部署、扩展和管理。这个范式取得了巨大的成功，但其核心假设仍然是：计算任务是由人类预先编写的、逻辑确定的代码驱动的。

然而，LLM 的崛起，催生了一种全新的计算实体 —— 自主智能体（Autonomous Agent）。Agent 的行为不再由确定性的代码逻辑严格限定，而是由一个宏大的目标和一个或多个模型所驱动。它能够自主地进行规划、推理、决策，并调用外部工具来与数字世界和物理世界进行交互，以达成指定目标。一个 AI 软件工程师 Agent 的工作流，不再是执行一段固定的 main () 函数，而是一个动态的、长周期的、充满不确定性的 “思考 - 行动” 循环。

这种根本性的转变，使得我们开始重新审视云原生时代构建的基础设施。为运行持久化应用而设计的虚拟机和传统容器，因其沉重的资源占用、缓慢的启动速度和高昂的闲置成本，无法适应 Agent 所需的极致弹性和成本效益。而为处理确定性、无状态、短周期的 HTTP 请求而设计的传统 Serverless 架构，也无法承载一个需要数小时上下文记忆、拥有完整文件系统、并能与浏览器进行复杂交互的 Agent。我们需要为 AI 应用而生的原生运行时。

Agentic AI 应用的典型场景

为了更清晰地理解 AI 原生应用的需求，我们以云上企业客户落地 AI 业务场景为例，并尝试拆解这些典型应用的业务行为。

场景一：交互式智能内容创作助手

• 场景描述：市场营销科技公司的经理在一个富文本编辑器中输入初稿，AI 助手可以实时地进行润色、扩写、总结。它还能进一步执行指令，如 “帮我配一张科技感的头图”“将这段翻译成英文” 等。
• 应用行为拆解：
• 多轮对话：整个创作过程是一个持续的多轮人机交互会话。
• 上下文记忆：AI 必须记住之前的文稿版本、用户的修改指令和偏好，才能提供连贯的创作建议。
• 模型自托管：助手生成图片、润色文本等任务需要调用不同的模型。例如，生成符合公司过往风格的图片，可能需要依赖对公司素材进行微调后的垂类模型，并将其托管在如 ComfyUI 这样的服务上。
• 异构任务流：这个过程混合了多种任务。文本润色前的内容预处理，然后交给 LLM，而配图则需要调用文生图的扩散模型。
• 流式响应：为了更好的用户体验，AI 的回答，特别是长文本，需要像打字机一样逐字流式输出。

场景二：个性化 AI 客服

• 场景描述：某电商平台的 “主动式导购 Agent”。当一个用户在某个昂贵的商品页面停留超过 3 分钟，并反复查看评论和规格时，AI Agent 不是被动等待提问，而是主动发起对话：“您好！我是您的专属 AI 导购......”。
• 应用行为拆解：
• 事件驱动：Agent 的启动是由复杂的业务事件（如用户行为日志、定时器）触发的，而不是简单的 API 请求。
• 企业数据：在发起对话前，Agent 需要瞬间拉取并整合多个数据源：用户的历史订单（CRM）、商品知识库（向量数据库）、实时库存（ERP）等。
• 实时在线：Agent 需要全天候在线，随时准备响应触发事件。

场景三：通用 Agent 平台 + 病毒式传播的 AIGC 创意应用

• 场景描述：某科技企业是国内一家头部的基础大模型服务公司，利用自己的大模型结合面向 C 端的 Agent 平台开展全栈开发，让平台用户可以通过提示词写出一个完整的项目工程，并且可以一键部署和分享出去。
• 应用行为拆解：
• Agent 智能体：通过和用户对话，根据用户输入，以休闲益智类游戏为例，通过 LLM 生成游戏项目代码。
• 代码执行验证：Agent 智能体通过 LLM 生成代码，然后需要一个 Code Interpreter Sandbox 来执行验证。
• 部署与分享：LLM 生成的游戏项目完成验证后，用户可以快速部署为一个独立服务，然后通过分享对外发布。
• 脉冲式流量：应用可能因为网红的推荐而流量激增，并发请求在几分钟内从 10 个飙升到 10000 个。
• 大文件处理：应用需要处理用户上传的高清照片进行游戏互动，并生成高清结果图，涉及较大的数据负载（Payload）传递。

AI 原生应用运行时的核心能力

从上述真实实践中，我们可以清晰地勾勒出 AI 应用的共同画像：它们是会话式的、工具增强的、事件驱动的、异构算力的，并且需要极致弹性与精益成本的。这要求运行时基础设施具备以下核心能力：

1、面向会话的状态管理与安全隔离

Agent 的核心概念是会话（Session），它是持久的、有状态的。Agent 在其生命周期中积累的上下文信息，包括内存中的变量、本地文件系统中的代码和数据等等，是其能够进行多步复杂推理的基础。因此，基础设施必须为每个 Agent 会话提供一个完全隔离且状态持久的运行时。

由于 Agent 执行的代码很大一部分是由 LLM 动态生成的，其行为具有不可预测性，必须被视为不可信的第三方代码。传统的基于操作系统的容器隔离共享同一个内核，这为内核漏洞利用和容器逃逸等攻击留下了风险。因此，硬件虚拟化级别的强隔离（例如 MicroVM）是必不可少的，以确保最基本的运行时安全边界。运行时需要提供会话管理和资源调度，以实现会话维度的运行时隔离和存储隔离，确保数据安全，并实现强隔离、快启动。

2、大规模实时弹性与精益成本管理

Agent 应用的负载模式通常是高度动态和不确定的。例如，一个集成到热门应用中的 AI 助理，需要在流量高峰的几秒钟内，从数百个并发会话扩展到数千甚至数万个。同时，许多 Agent 应用场景是交互式的，用户需要近乎实时的响应。这就要求 Agent 的运行环境必须能够瞬时启动，将冷启动时间控制在毫秒级。传统的虚拟机启动需要数分钟，容器冷启动也通常在数秒到数十秒之间，都难以满足需求。

此外，Agent 的工作模式并非持续的高强度计算。在漫长的空闲或等待时间里，传统基础设施的计费仍在持续，导致巨大的资源浪费。理想的基础设施，必须能够将成本与 Agent 的真实工作量严格挂钩。平台需要通过精细的运行时状态监控和调度引擎，精确区分 Agent 或工具的 “忙时（Active）” 和 “闲时（Idle）” 状态，提供面向 “忙闲时” 的计费模型，真正实现为价值付费。

3、异构算力与标准化工具连接能力

AI 应用通常需要精细化调度 CPU、GPU 等多种异构资源。CPU 提供毫秒级弹性，而 GPU 提供秒级弹性能力。业务侧需要能够方便地组合不同类型的算力，平台侧则需要提供开箱即用的算力使用能力，实现快速交付和极致的成本效益。

同时，AI 智能体、AI 工具和各种沙箱环境之间需要标准、安全的连接能力。协议层需要原生支持以 MCP、A2A 等标准协议连接智能载体，原生支持流式请求响应，并结合 AI 网关提供灵活、安全的访问鉴权能力，方便各种组件的集成。此外，平台还需具备原生异步化处理能力，自动应对大规模的异步请求，并提供平台错误处理能力，以支持 Agent 及工具常见的长时任务处理方式。

模型运行时

模型是 AI 应用的核心基石。当前企业在模型部署上面临两种技术路径的权衡：模型即服务（MaaS）虽免运维却受限于数据合规与定制化瓶颈；自托管（Self-hosted）方案虽可控却深陷 GPU 利用率低下、弹性不足、运维复杂的困局。经过大规模生产实践验证，Serverless 运行时成为模型的最优解。

企业模型使用的核心痛点

• 案例 1：景区 AI 生图的资源浪费困局

某 4A 景区设计师希望为游客照片生成国风特效，使用 ComfyUI 部署绘图模型。但景区流量波动极大：节假日单日处理 10 万张图，平日仅千张。传统虚拟机方案被迫包月预留峰值 GPU 资源，导致 90%+ 算力闲置，月成本超 5 万元。更致命的是，突发流量时扩容 > 5 分钟，游客排队超时投诉激增。

• 案例 2：儿童阅读 App 的冷启动灾难

某儿童阅读平台用 CosyVoice 模型生成故事语音。其 2 万 + 绘本中，热门内容日均调用 10 万次，而长尾绘本月均不足 10 次。自建容器集群无法为低频模型保持实例存活，家长点击冷门绘本时需等待 60+s 冷启动，体验断裂导致用户流失。

• 案例 3：智能家居企业的定制化困境

某智能家居企业用 Qwen 模型分析家庭安防视频。需适配不同硬件终端（摄像头 / 门锁 / 电视），每个场景需定制化微调模型。自建 IaaS 平台每次部署新模型需配置 GPU 环境、压测验证，迭代周期长达 3 天，严重拖慢产品创新速度。

当 AI 从实验室走向万千真实企业场景，传统方案在成本、弹性和效率上的短板被急剧放大，而 Serverless 模型运行时以无服务器理念重塑 AI 生产关系：

• 对开发者：告别 “GPU 环境配置 - 集群管理 - 模型部署” 的非核心工作，专注场景创新；
• 对企业：破解 “不用时浪费，用时又不足” 的算力悖论，使规模化不再伴随成本失控；
• 对产业：当景区设计师、儿童产品经理、智能家居工程师都能轻松用好领域模型，AI 应用才会真正繁荣。

Serverless 模型运行时的核心能力

1、异构算力和 1/N 卡切分使用

在算力层，Serverless 模型运行时通过 GPU 虚拟化技术将单张 GPU 显卡划分为 N 个独立计算单元，每个实例具备隔离的显存空间与算力资源，不同实例通过 GPU 分时复用技术实现并行推理。以 16GB 显存的 Tesla 卡系列为例，Serverless 模型运行时具备将单张卡切分为 16 个实例，每个实例均拥有 1GB 显存和 1/16 算力，使 < 1GB 的小参数模型可运行在单个实例，实例间互不影响，实现资源隔离和数据隔离，进而大幅简化开发范式，减少稀缺 GPU 资源的碎片化浪费。

Serverless 模型运行时通过池化技术，将 CPU/GPU/XPU 统一纳管到一个资源池，开发者可根据模型特性按需配置算力类型 —— 语音识别等轻量任务分配 CPU，图像生成等算力密集型任务分配 GPU 碎片，大语言模型等显存密集型任务分配 GPU 整卡或多卡。某服装企业实测显示，Stable Diffusion 服务采用 1/8 卡虚拟化后，GPU 利用率从 18% 提升至 89%，成本降幅达 83.2%，逼近理论极限值 87.2%。这种碎片化供给模式，从根本上重构了算力经济模型。

2、负载感知调度和毫秒级闲置唤醒

在调度层，Serverless 模型运行时通过负载感知调度系统实时监测请求队列深度、GPU 显存利用率、实例健康状态等多维指标，基于池化技术构建三级响应机制：请求优先分配至活跃实例；当资源吃紧时，毫秒级唤醒闲置实例；仅在极端流量下触发冷启动。其核心技术突破在于利用 CRIU（用户空间检查点 / 恢复）技术冻结显存状态，并将显存数据临时置换至内存，在新的请求调度前实现毫秒级 / 秒级状态恢复，较传统虚机 / 容器方案提速百倍。某语音类应用接入后，长尾模型冷启动延迟从 47 秒压缩至 0.8 秒，流量高峰期的 RT 抖动减少 80%，配套的成本模型使闲置实例仅按 15% 标准计费，实现弹性与经济的平衡。

3、集成加速框架和开发调试工具链

在开发层，Serverless 模型运行时预集成加速框架深度优化模型运行效率：vLLM 框架的 Paged Attention 技术通过显存分页管理提升 3 倍吞吐量；SGLang 的 Radix Attention 实现注意力机制并行编译，降低 60% 推理延迟；TensorRT-LLM 的量化融合策略提升 2 倍能效比。

开发工具链提供 DevPod 交互式环境，开发环节实现白屏操作和实时反馈，集成在线 IDE（如 VSCode/JupyterLab/SSH 终端），开发者在云端环境具备比本地环境更高的生产效率；生产部署环节实现革命性简化 —— 上传模型文件后，系统在 30 秒内自动生成 Dockerfile，构建推理服务、输出 OpenAPI 文档及 SDK。某智能家居企业模型迭代周期因此从 3 天缩短至 30 分钟。企业级运维能力涵盖金丝雀发布（支持 5%/10%/20% 阶梯放量）、动态弹性扩展（实例数量根据定时策略或水位策略在 0~N 间自适应调整）、全观测体系（实时追踪 50 + 指标如 GPU 显存利用率、SM 利用率）等关键特性。

这三层技术并非孤立存在，而是形成深度协同的模型运行时能力增强：GPU 碎片化技术提供原子级算力单元，为智能调度奠定资源基础；负载感知引擎通过毫秒级实例弹性，将碎片化算力转化为即时服务能力；开发工具链则构建自动化流水线，使技术红利直达开发者工作台。某 4A 景区实践表明，当三项技术叠加应用时，AI 生图服务峰值吞吐量提升 12 倍，同时成本降低 78%。这种协同效应标志着 AI 模型托管从手工作坊时代迈入工业自动化时代，将企业从算力枷锁中解放，重归业务创新的本质。

Serverless 模型运行时 ——AI 大脑的终极载体

从 Serverless 到 Serverless AI，本质是从资源效率优化迈向智能生产力释放。而 Serverless 模型运行时作为承载 AI 大脑的核心基座，通过异构算力革命、智能调度进化、开发范式升级三重突破，让企业真正实现：所想即所得的模型服务，无需担忧算力枷锁，专注智能本身，灵活扩展和不断创新。

智能体运行时

AI 应用形态的持续演进

1、“请求 - 响应” 模式：无状态的事务性 AI 任务

在 AI 应用的早期阶段，其交互模式很大程度上继承了传统 Web 服务和微服务的 “请求 - 响应” 模型。其核心是执行一个独立的、原子性的任务，具有显著的无状态性。

这种模式下，AI 更像一个高效、自动化的工具，其无状态的特点与 Serverless FaaS 架构非常契合。因为计算层是无状态的，平台可以近乎无限地水平扩展，通过并行启动成百上千个独立的、可互换的函数实例来应对流量洪峰，实现了极高的弹性和容错性。

2、“对话” 模式：有状态的协作式 Agentic AI 应用

AI 应用的关注点从单纯驱动 LLM 完成指令，转移到了如何利用外部工具和知识库构建更加智能的交互式智能体（Agent），一个任务需要经历多轮交互才能最终完成，具有显著的会话特征。

从事务性到对话式的转变，应用的用户界面发生了很大的变化，会话上下文贯穿整个交互的生命周期。在 Agent 应用中，会话状态的持久化及会话执行上下文共享，成为了解决 Agent 应用性能的先决条件，应用的架构优先级发生了根本性变化，会话及状态管理成为了架构关注的第一要素。

Agent 运行时的核心架构目标

1、围绕会话请求和资源调度模型，维持长时运行的状态延续

Agent 运行时的架构设计，以会话（Session）作为不可分割的原子单元，构建一个原生支持状态持久化的大规模实时弹性系统。这个目标与云原生时代常见的 “请求 - 响应” 模型形成了鲜明的对比。后者的弹性，本质上是一种无状态弹性，通过快速复制无状态的计算实例来应对流量变化。然而，在面对需要记忆和上下文共享的 Agent 应用时存在较大的适配负担，状态被迫成为需要被外部化管理的包袱。

我们认为，会话本身，连同其内部状态，是实现下一代弹性的核心。因此平台设计的出发点不再是 “如何高效地处理一个瞬时请求”，而是 “如何将一个完整的、有状态的、长周期的 Agent 会话作为一个整体，进行高效、安全、经济的生命周期管理”。然后将 Agent 会话（包含其代码、内存、文件系统）封装成一个可冻结、可恢复、可迁移的独立单元。基于这种能力，能够将会话的逻辑生命周期与物理计算资源的分配彻底解耦。这种解耦是实现大规模实时弹性的关键。

2、实现面向 Active-Idle 资源管理，解决长时运行的成本困境

Active-Idle 资源管理，简单来说就是基于应用 “忙 - 闲” 时的资源管理，结合 Agent 运行特征，我们可以将一个会话所需的资源分解为两个部分，要突破成本困局，本质是要提供一种基于会话生命周期的动态资源解耦方案。

• 状态资源：包括持久化文件系统和冻结的内存快照。这些资源的特点是存储成本低廉。
• 计算资源：包括活跃的 VCPU 和内存。这些资源是昂贵的，也是传统模型中造成浪费的主要来源。

Active-Idle 模型的核心，就是根据 Agent 的实时活动，动态地、透明地为会话 “挂载” 或 “卸载” 昂贵的计算资源，同时始终保持其廉价的状态资源在线。

现有架构支撑 Agent 运行时对比分析

结合 Agent 运行时需求，本节将对目前几种主流解决有状态 Serverless 架构模式进行系统性的对比分析。它们在性能、成本、复杂性和可扩展性等方面存在显著的差异。

技术方案	状态外置适配无服务器架构	传统尽力会话亲和	平台原生状态抽象
状态范围	请求级，外部持久化	会话级，内存中（脆弱）	实体级，平台持久化
弹性效率	极高（按请求独立扩展）	低（破坏水平扩展）	高（按实体独立扩展）
系统容错性	高（函数本身无状态）	低（实例故障导致状态丢失）	高（状态由平台持久化保证）
业务性能	中（受网络延迟影响）	高（内存访问）	中（持久化状态访问有开销）
开发复杂度	中（需手动管理状态读写和一致性）	高（路由复杂，状态易丢失，调试困难）	低（状态管理由平台抽象）
成本模型	按请求付费 + 状态存储成本	按请求付费（但通常需预置实例以保证状态）	按操作 / 状态存储付费
理想场景	状态需求简单、对延迟不敏感的应用	迁移需要粘性会话的遗留应用	事件溯源、复杂工作流编排

分析与建议：

• 业务状态外置：架构的优点是简单、清晰，保持了计算层的完全无状态，但实际改造过程中常常面临两个常见的架构适配难题而被放弃：状态解耦编程模型复杂度高，状态外置引入性能和成本问题。
• 传统会话亲和：应被视为一种过渡性的手段。亲和性无法得到保证，属于尽力亲和；同时在会话维度共享实例，无法提供隔离能力，无论是系统升级，还是业务异常，调度不确定导致应用容错无法保障。
• 内置状态抽象：架构理念先进，但需要依赖特定产品能力，同时需要适配状态内置的编程模型，更适合需要可靠状态管理和复杂工作流编排的场景，并不适合作为编程模型自由度较大的 Agent 运行时。

为 AI 原生的 “会话式” Serverless 运行时

这种架构认识到，AI 应用的会话既需要状态持久化，又需要高性能的本地计算和会话维度隔离能力。在这种趋势下，Serverless 业界领导者阿里云和亚马逊云科技（AWS）不约而同给出了自己的答案：

阿里云凭借在大规模、高并发等极致业务场景的实践，依托 Serverless 产品函数计算突破架构边界，原生提供会话管理能力，支持为每一个用户会话动态配置一个专用的、持久化实例，支持会话维度的动态挂载实现存储隔离，会话绑定的实例可以持续存活长达 8 小时，未来最长可达 24 小时，并能够保持请求的优雅结束。

AWS 凭借其先发优势和对市场的定义能力，发布了 AWS Bedrock Agent Core 产品作为构建 Agentic AI 应用的底层基础设施；其核心架构创新在于，它为每一个用户会话动态配置一个专用的、持久化的实例，该实例可以持续存活长达 8 小时。

这种 “一个会话，一个独立运行时” 的模型解决了传统 Serverless 的所有状态难题：

1. 原生会话状态保持：将 “会话（Session）” 提升为状态、请求和资源管理的 “一等公民”，在一个会话的生命周期内，会话上下文、中间计算结果和临时文件都可以直接存储在实例的内存和本地文件系统中。这消除了因状态与外部系统交互而产生的网络延迟，为 Agent 的多步推理提供了性能保障。只有第一次调用可能经历冷启动。后续的所有交互都在同一个 “热” 的上下文中执行，响应时间稳定在毫秒级。
2. 灵活可靠的安全隔离：运行时底层计算实例，基于 MicroVM 提供了硬件辅助的虚拟化隔离。每个实例都有自己独立的内核和内存空间，从根本上杜绝了传统容器逃逸和旁道攻击的风险。同时平台提供了会话级别的强隔离选项，每个会话可以选择运行在独立的 MicroVM 实例中。这对于处理敏感数据、执行不可信代码的多租户 Agent 应用，有效防止了会话间的数据泄露。
3. 毫秒级的弹性速度：根据 Firecracker 官方数据，运行时底层基于的 MicroVM 冷启动时间可以稳定在～100 毫秒。每个 MicroVM 的内存开销仅为 5MB 左右，使得可以在一台物理服务器上高密度地运行数千个独立的 MicroVM 实例，解决会话粒度的实例弹性问题。

这种架构可以被称为 Agent 原生 “会话式” Serverless 架构，既保留了 Serverless 的免运维、按需扩展的优势，又提供了传统长连接服务才有的状态保持和高性能，在此基础上同时兼顾了安全性。同时，平台负责解决了 Serverless 架构有状态环境中生命周期管理、业务升级和成本等一系列难题：

• 会话生命周期管理：计算实例的生命周期不再是单个请求，而是整个会话。例如，Runtime 的会话有明确的生命周期状态：Active（活动）、Idle（空闲）、Expired（过期）、Deleted（删除）。平台需要提供 API 允许开发者主动管理（如提前终止）这些长生命周期的会话，便于业务集成，将会话管理的权利交给用户，提升用户使用的灵活性。
• 优雅升级与灰度发布：当更新一个正在处理有状态会话的函数时，不能简单地用新版本替换所有实例。平台需要支持优雅升级：新的会话请求被路由到新版本的实例，而持有旧会话的实例则继续服务，直到其关联的会话自然结束，从而实现平滑过渡。
• 匹配运行特征的成本模型：通过实施以会话为中心的 Active-Idle 资源管理模型，平台能够让开发者无需关心底层资源的复杂管理，就能享受到永远在线的会话体验和按真实计算付费的经济效益，从而解决开发者和企业构建 Agent 的成本困局。

工具与云沙箱

AI Agent 与工具：从概念到能力

白皮书第 5 章完整介绍了 Agent 是如何借助外部工具来执行具体的任务，从而与外部世界交互，最大限度地释放 LLM 的潜力。这一节我们将聊聊工具的运行时与云沙箱。

由于 AI 工具已经不再是简单的 API 调用，而是演变为需要复杂运行时才能管理和安全保障的执行环境。因此，我们先在下表格提炼了 Agent 常用工具的类型，并进一步剖析了它们背后对底层运行时的核心诉求，这为我们理解 AI 原生应用的新型执行范式奠定了基础。

工具	描述	核心运行时需求
MCP（模型上下文协议）	实现互操作性，允许 LLM 通过结构化 API 动态理解并调用外部工具。	稳健的 API 服务与运行时紧密集成。运行时具备轻量、弹性能力。
File Search（文件搜索 / 检索）	在预定义的私有文档语料库中执行语义检索，实现检索增强生成（RAG），提高回答的准确性。	高效的向量检索服务与运行时紧密集成。运行时需要具备上下文缓存，提升检索性能。
Image Generation（图像生成）	赋予模型文生图和程序化图像处理的能力，将自然语言描述转化为视觉内容。	高性能计算、高效稳定的 API 调用能力。运行时具备异构算力。
Code Interpreter（代码解释器）	为模型提供一个有状态的、沙箱化的多语言执行环境（Python、Nodejs、Go 等），用以执行复杂的计算和程序化任务。这将模型的能力从语言推理扩展到逻辑分析领域，使其能够进行量化数据分析、算法执行和动态数据可视化等操作。	强隔离与安全、持久化会话、丰富的科学计算环境。
Browser Use（浏览器使用）	赋予模型以编程方式控制 Web 浏览器实例（通常是无头模式，headless mode）的能力，以执行复杂的网页自动化任务。这超越了简单的信息搜索，涵盖了导航、表单提交、与动态网页元素交互，以及直接从渲染后的网页内容中提取信息。	强隔离、会话管理、可观测性与人机协同能力。
Computer Use（计算机使用）	使模型能作为一个视觉代理（visual agent），直接与计算机的图形用户界面（GUI）进行交互。它通过模拟人类的键鼠操作来操控缺少程序化 API 的桌面应用和遗留系统，从而实现端到端的数字化工作流自动化。	强隔离、具备 GUI 的完整操作系统、会话管理、可观测性。
Mobile Use（移动端使用）	赋予操作系统更强的语义理解和跨应用操作能力，使手机能够自主完成复杂任务，将手机转变为一个能够真正理解用户需求的 “智能助手”。	专用、持久化的运行时环境，能够进行跨应用和 OS 级的操作，并需要支持会话管理以保留对话上下文和记忆。

从上述分析可以看出，像代码解释器、浏览器使用和计算机使用这类复杂工具，其核心需求已超越了传统单次、无状态的 API 调用。它们需要一个有状态的、沙箱化的环境。为满足这一需求，云计算基础设施正在演进，而我们常说的 AI Sandbox，正是一个严格控制的隔离环境。它允许 Agent 在其中安全地执行代码、与应用交互和访问资源，同时有效防止对主机系统或敏感数据的危害。AI Sandbox 的核心价值在于，它为创新提供了安全保障，是推动 Agent 技术走向成熟和商业化应用不可或缺的基础设施。

复杂工具运行时的核心诉求

Agent 的出现，对底层的运行时环境提出了三大根本性的、前所未有的技术挑战。这些挑战解释了为何传统基础设施无法高效、安全地支持复杂的 AI 工具运行时。

1、隔离与安全（Isolation & Security）

这是首要且不容妥协的要求。执行由 LLM 动态生成且不可信的代码，引入了巨大的安全漏洞，例如沙箱逃逸、代码注入和权限提升等。传统的软件沙箱技术在应对这种动态、复杂且可能具有对抗性的 AI 工作负载时，正变得力不从心，漏洞频发证明了其不足。Agent 对运行时隔离性的要求达到了前所未有的高度。

2、状态管理与成本（State Management & Cost）

Agent 的工作模式是对话式和持续性的，这需要每个沙箱都拥有一个持久的、有状态的会话来维持上下文、记忆和交互环境。这种特性与传统无状态的 FaaS（函数即服务）设计产生了根本性冲突。若为每一个潜在的用户会话都预置一个长期运行的虚拟机（VM），将导致惊人的闲置资源成本和巨大的运维负担。

3、可扩展性与运维（Scalability & Operations）

Agent 应用的流量往往是突发且不可预测的。基础设施必须能够瞬时、动态地扩展以应对峰值，并在空闲时迅速缩减以节约成本。然而，从零开始构建并维护一个既安全隔离又具备弹性伸缩能力的沙箱环境，需要极其专业的 DevOps 知识和大量的人力投入，这对大多数开发团队而言都是一个难以逾越的障碍。

上述挑战共同指向一个结论：Agent 的兴起催生了一种独特的云工作负载类型，它不完全符合传统 IaaS 的模式，也对现有的 FaaS 平台在状态管理和隔离性上提出更高的要求，使其兼具虚拟机级的强隔离、状态化管理与 Serverless 的极致弹性与经济性。

Serverless 作为 AI Sandbox 的理想基座

一个成熟的 Serverless 平台，特别是以 FaaS（如函数计算）为代表的技术形态，通过其底层架构的演进，已成为解决上述所有核心诉求的理想起点，从底层硬件到上层应用提供了一套无缝集成的、端到端的解决方案。

1、计算隔离，硬件级与内核级双重保障

安全性是 AI Sandbox 的基石，其保障始于最底层的物理硬件。例如，阿里云函数计算采用的 “神龙裸金属 + MicroVM 安全容器” 架构，构建了一个从硬件到应用运行时的端到端、纵深防御安全体系。神龙架构通过自研的 MOC 芯片将虚拟化功能从主 CPU 卸载，实现了在共享硬件上的租户间 “硬隔离”。在此基础上，函数计算为每个函数实例提供独立的 MicroVM 安全容器，使其运行在拥有独立客户机内核的微型虚拟机中。这确保了 AI Agent 生成和执行的代码被完全封装在自身的内核空间里，其影响范围被严格限制在单个、即用即毁的实例内部。这种双重安全模型共同构建了坚固的壁垒。

2、会话管理，原生支持有状态应用

传统的 Serverless 架构被设计为处理无状态的、短暂的事件，而 AI Sandbox 本质上是有状态的。若采用将函数实例数固定为 1 的 “静态预留” 变通方案，虽然可以模拟会话粘性，但很快会暴露其致命缺陷：管理成本高昂、破坏自动伸缩能力、丧失按需付费优势等。

而以函数计算为代表的 AI 原生 Serverless 架构通过原生能力解决了这一矛盾。核心能力是强会话亲和性（Session Affinity）、会话物理隔离（Session Isolation）以及会话管理接口（Session Management Interface）。

• 强会话亲和性：是一个智能路由层，它确保在一次会话的整个生命周期中，所有来自同一客户端的请求都会被精确地路由到同一个函数实例上，从而为每个用户会话分配了一个固定的函数实例，保证了交互的连续性和上下文的完整性。平台提供了多种灵活的亲和方式，包括专为 Agent 场景设计的 MCP SSE 亲和，以及适用于 Web 场景的 Header Field 亲和和 Cookie 亲和。
• 会话物理隔离：解决了多租户环境下的安全问题。在启用该能力后，平台会为每一个会话独占一个完整的函数实例，将单实例会话并发度强制设置为 1。这意味着租户间的内存、临时文件和进程空间在物理上（基于神龙裸金属）和逻辑上都是分离的，从而提供了金融级别的多租户安全保障。
• 会话管理接口：将这些强大的底层能力通过简洁的控制台配置和 API 接口开放给开发者。开发者无需编写复杂的外部编排和调度逻辑，平台在后台自动处理了会话生命周期与实例生命周期的精确映射和管理，极大地降低了开发门槛。

这三种能力协同工作，共同构建了一个全新的 Serverless 原语：“按需生成的、隔离的、有状态的运行时环境”，完美解决了 AI Agent 对有状态环境的根本需求。

3、存储隔离，解决状态持久化难题

一个完整的 AI Sandbox 解决方案，不仅需要解决计算层的状态管理，还必须应对存储层的持久化和隔离挑战。函数计算通过创新的技术和完善的最佳实践，为 Agent 的两类核心存储需求，本地临时存储和持久化共享存储，提供了端到端的解决方案。

（1）本地临时存储，利用快照技术实现极速恢复

对于需要快速恢复本地环境状态的会话，函数计算引入了基于快照的运行时环境恢复机制。当一个函数实例进入空闲时，系统会自动为其完整的本地磁盘状态创建一个快照，并在下次请求到达时，从该快照 “秒级唤醒” 一个全新的实例。这种机制巧妙地平衡了成本与性能，为用户提供了持久化会话的体验，而其计费模式却依然遵循 Serverless 的按需使用原则。

（2）持久化共享存储，提供会话级别的数据沙箱

在物理共享的存储资源上实现租户之间数据的严格隔离是一个严峻的挑战。

Serverless 平台将会话亲和与会话隔离能力从计算层延伸至存储层，通过 “会话级存储亲和”（Session-level Storage Stickiness）机制将会话与一个持久化的、归属于特定租户的存储子目录进行强绑定，从而在共享存储之上构建了一个独立的、目录级别的 “数据沙箱”，从文件系统层面杜绝了会话间数据交叉的可能性。

在会话级存储亲和的基础上，函数计算还提供了基于 POSIX 标准的多租户安全实践框架，给用户提供了一套可落地的多租户存储安全最佳实践。包括：

• UID 隔离：为每个租户 / 会话颁发唯一的 POSIX 用户 ID（UID），确保每个租户或会话在文件系统层面就有了自己独立的 “身份”。
• SecurityContext 继承：确保用户进程在创建文件时主动继承挂载目录的权限，保证挂载目录的权限只为其所有者，从源头上防止了权限混乱。
• 主进程 UID 切换：Agent 的代码本身就运行在受限的、非 root 的用户身份下，极大地缩小潜在的攻击面。
• 目录配额：借助存储平台的目录级配额能力，为不同租户 / 会话的目录设置配额，有效防止某个恶意或行为异常的租户耗尽资源。
• UID 复用：确保 UID 回收后，文件内容被清理后才能被再次使用。

4、对极致存储性能的持续探索

对于需要极致 I/O 性能的 Agent 应用，例如大规模代码编译或高频读写海量小文件的场景，函数计算正与高性能存储团队合作提供更高性能的原生挂载能力，支持在会话粒度上为每一个独立的 Sandbox 动态挂载专属的高性能存储盘，以满足最严苛的性能需求。

至此，我们阐述了 Serverless 之所以能作为模型、智能体、工具的理想运行时的原因，下一节我们将从成本角度讲讲 Serverless 的差异化优势。

AI 应用运行时的降本路线

在云计算的发展过程中，计费方式往往是开发者最直观的感知。最初用户需要直接购买资源，按小时计费；后来，Serverless 函数计算将计费粒度细化到按请求执行的毫秒级。很多开发者第一次接触一款云产品时，关注的往往不是架构，而是账单。因为账单背后映射的，正是云厂商在资源抽象、调度方式、安全隔离与开发体验上的关键选择。

Serverless 函数计算的演进史，其实也是一部计费方式的演化史。透过计费这一窗口，我们可以一管窥全豹，清晰地看到背后产品形态在技术与体验上的深刻变化，以及技术架构随应用场景不断演化的能力。

阶段一：从资源租用到按请求计费

在 Serverless 函数计算发展的最初阶段，最大突破点在于计费方式的根本转变：用户不再像租用虚拟机一样，为实例的持续运行付费，而是只在函数被真正调用、执行时支付费用。换句话说，在没有请求执行的时间段，用户无需承担任何闲置成本，这一阶段的创新，让 “只为代码运行时刻付费” 成为 Serverless 的立身之本，也迅速降低了开发者的使用门槛。如下图所示。

支撑这种计费模式的关键技术包括：

• 精准识别请求边界：请求的生命周期就是计费的生命周期，平台必须在微秒 / 毫秒级准确地识别 “开始” 和 “结束”，保证账单公平与精确。
• 按请求分配独占资源：每个请求都获得确定的 CPU / 内存资源，避免资源竞争导致性能抖动，从而保障账单的可控性。
• 低延时大并发的冷启动能力：实例不常驻，而是按需启动。平台必须优化冷启动延时，在大规模并发场景下快速分配资源，同时在空闲时立即回收，避免浪费。
• 1ms 完成活跃 / 闲置状态转化：在无请求时通过冻结函数实例的 CPU 调度，转成闲置状态，确保不再消耗时间片，请求来到时候，实时转成活跃状态，允许 CPU 调度，这是实现毫秒级精确计费和公平性的保障。

这一阶段让函数计算真正区别于虚拟机和容器租用模式，奠定了按请求计费的核心心智模型。

阶段二：多并发 + 毫秒级计费 —— 面向 Web 应用的优化

随着函数计算逐渐普及，除了事件驱动触发外，Web Server I/O 型场景也开始采用 Serverless 架构。如果继续采用单请求独占计费，对比传统多并发的服务模型，原有单实例单并发模型的成本很难接受，因此进入了第二阶段的演化。

核心变化是：突破单并发限制，按函数实例的活跃时间段计费，并将粒度精细化到 1ms，从而支撑 Web 应用、API 服务等主流场景，如下图所示。

支撑这一演化的关键技术包括：

• 识别活跃时间段作为计费边界：从 “单请求时长” 转变为 “活跃区间”，只要实例内有请求在执行，即视为活跃计费，不管并发多少请求。
• 引入 CustomRuntime/Container Runtime：支持用户平滑迁移主流 Web 框架（如 Express、Flask、Spring Boot），这些框架天然支持多并发，能够降低成本并收敛数据库连接数，减少连接暴涨带来的风险。
• 缩短计费粒度：从 100ms 到 1ms：大多数 Web 请求延时低于 100ms，如果仍按 100ms 粒度计费，用户成本过高。精细化到 1ms，使账单更公平。
• 极致优化平台全链路延迟：Web 应用对端到端延迟极其敏感，平台必须在鉴权、路由、调度、转发等环节做性能优化，避免平台开销成为主要瓶颈。

这一阶段的价值在于：从 “为单个请求买单” 转变为 “为活跃区间买单”，辅以更精细的粒度和运行时灵活性，让函数计算从事件驱动扩展到主流 Web/API 服务场景。

阶段三：按实际资源消耗计费 ——AI 时代的价值计费

AI 应用具有长会话、强交互、低延迟的特点：

• 模型对话需要保持上下文；
• 语音 / 流式生成需要实时响应；
• 会话中可能包含多种工具调用与后台任务。

这类应用往往是稀疏型负载：大多数时间处于低负载，仅维持长连接和上下文。传统请求边界 = 活跃，闲置时冻结 CPU 的机制不再适配：如果一律计为活跃，用户在 “低价值” 的保活状态下将付出过高成本。

因此，第三阶段的核心转变是：在识别请求边界的基础上，引入按实际资源消耗动态区分活跃 / 闲置的计费模型。低负载状态下减免 CPU 费用，同时仍然允许 AI 应用运行后台任务。

支撑这种演化的关键技术包括：

1、支持会话亲和性

• 引入会话亲和性机制，使得同一会话的请求路由到同一个实例，避免上下文丢失。
• 用户可通过配置 IdleTimeout 主动控制会话保留时间。
• 平台针对 AI 应用提供强亲和及会话隔离能力，确保会话绑定实例的有效存活时间。

2、按实际资源消耗判断活跃 / 闲置

• 在过去 “有请求 = 活跃” 的基础上，引入根据资源利用率感知活跃 / 闲置的机制。
• 如果 CPU 使用超过阈值，则记为 “活跃” 并计算 CPU 费用；如果只是心跳 / 轻量保活，CPU 使用极低，则记为闲置，免去 CPU 费用，仅收内存 / 网络成本。

3、执行期间低负载的减免机制

• 在有请求执行时，函数计算以秒为周期采样，如果 CPU 使用低于阈值，自动减免该周期的 CPU 费用。
• 在 MCP、Websocket 等典型低负载场景默认启用，平台主动让利，避免 “在线 = 计费” 的粗暴逻辑。

4、支持不冻结，允许后台任务持续运行

• 在 AI 场景中，冻结会导致长连接中断、缓存失效，恢复代价高。
• 函数计算支持不冻结模式，允许请求结束后继续运行后台任务，如缓存预热、索引更新、回调处理。
• 这类任务的费用仍然根据实际资源消耗判定为活跃或闲置，差异化计费。

第三阶段的价值在于：从 “为活跃区间买单” 进一步演化为 “按资源消耗分层计费”，账单更好地对齐到有效计算，避免因长连接或低负载保活而产生额外成本，让 Serverless 真正适配 AI 时代的长会话与强交互负载。

函数计算的演化方向是把产品形态与用户价值更紧密地对齐

阿里云函数计算的计费方式经历了三个阶段：

• 阶段一：按请求计费 —— 降低门槛，让用户只为调用付费；
• 阶段二：活跃区间计费 —— 扩展场景，让 Web/API 应用也能高效低成本运行；
• 阶段三：按资源消耗计费 —— 贴近价值，让 AI 应用在长会话与低负载下也能公平付费。

在 AI 时代，函数计算一直坚持走向让开发者只关心业务逻辑，云厂商自动完成一切资源管理与调度的愿景，最终让计算像水、电一样随时可得、按实际使用价值付费。