百倍启动加速，大规模 Agent 部署和运维的捷径是什么？

随着 AI 原生浪潮的到来，智能体（Agent）正成为企业创新的新引擎。然而，在生产环境中大规模落地 Agent，却面临开发复杂、运维困难、成本高等挑战。这些问题应该如何解决？企业内部大规模部署和运维 Agent 是否有捷径可走？针对这些问题，InfoQ 近日对话了阿里云云原生应用平台 Serverless 计算负责人杨皓然（花名：不瞋），围绕大规模 Agent 部署和运维的最佳实践等主题展开讨论。

AI 原生时代的 Serverless AI 等于 Serverless 加 AI 吗？

在 AI 原生时代，Serverless AI 绝不只是把“Serverless + AI”机械相加。AI 原生应用（Agent）具备非确定性推理、长期上下文与工具调用等特性，直接导致基础设施从无状态走向有状态、从同构调度转向异构编排，并把安全隔离从容器提升到 MicroVM 级别的沙箱。也因此，面向高并发、高稀疏、强隔离的负载形态，Serverless 的价值从“锦上添花”变为“刚需”：以毫秒级唤醒支撑稀疏会话、以精细计量降低长时空闲成本、以平台化能力统筹网关、可观测与记忆。但这并不意味着“一切皆无服务器”——例如大模型推理更适合 P/D 分离与常驻 GPU 的弹性边界管理。换言之，Serverless AI 的答案，是以 Serverless 的方式精准拥抱 AI 负载的关键环节，用体系化工程完成落地。

InfoQ：很多人都在提 AI 原生，比如 AI 原生应用、AI 原生组织等。您如何理解 AI 原生这个概念？在 AI 原生时代，基础设施的核心变化是什么？

杨皓然： 谈 AI 原生，首先可能需要定义一下 AI 原生的应用与传统应用本质上有哪些不同，这些不同决定了运行应用配套的基础设施所需要的演进。

与传统应用相比，AI 原生应用（或称 Agent 应用）确实存在显著差异。传统应用的开发方式是由程序员编写确定性的代码，程序执行过程和结果都是可预测的。而 AI 原生应用则不同，它内部包含了大量非确定性的指令推理过程。这类应用需要具备主动感知、规划能力，并能够调用各种工具来完成模糊的任务目标，而不再像以往那样，只依赖程序员或应用开发者预先编写的、固定且精确的执行逻辑。

因此，这催生了基础设施层面的三大重要变化：

• 第一，基础设施所需要支持的主流应用形态，可能正在从过去的“无状态应用”转向“有状态应用”。在微服务时代，无状态应用的典型做法是将状态数据存储在数据库或共享存储中，这样各微服务实例就可以无状态的方式启动和运行；当需要读取或写入数据时，再与数据库或键值缓存（KV cache）进行交互。然而，Agent 类应用的情况则不同。它们通常需要在较长时间内维持稀疏但连续的对话，并在此过程中保持上下文信息、连续执行一系列动作。这意味着，底层基础设施必须能够以极低的成本、可靠且高效地维持海量的有状态会话。

• 第二，任务的调度与编排模式已经从“同构任务”转变为“异构任务”。所谓“同构”，指的是传统微服务体系中，虽然应用或业务逻辑会被拆分为多个微服务并相互调用，但各服务的运行状态和特征基本一致，通常都是长期运行的容器实例。然而，在 Agent 应用的模式下，系统的负载特征呈现出高度的动态性。例如，某一时刻可能处于推理阶段，属于计算密集型任务；下一刻可能需要调用外部 API；再下一刻又可能执行由大模型生成的代码。这种动态、异构的任务形态与传统的资源调度方式存在本质差异。后者主要是为长期运行的常驻实例，或为偏离线的一次性执行任务而设计的，这两类模式在以往的系统中往往是分离的。而在 Agent 场景中，这些任务类型却需要紧密且无缝地融合在一起。因此，Agent 应用的调度模式必然与传统体系存在显著差异。从未来发展来看，若能以“工作流”的视角重新审视整个资源调度体系，并针对这一新模式进行优化，将可能成为重要的发展方向，并带来显著收益。

• 第三，新的 Agent 应用对基础设施的安全性和隔离性的要求发生了重大转变。以往的系统中，使用 Docker 或容器来执行代码已能满足需求，因为这些应用通常是可信的，其核心要求只是实现资源和性能层面的隔离即可。但在 Agent 时代，情况明显不同。由于 Agent 所执行的代码往往是由大模型自动生成的，其中可能包含潜在的恶意或不可信成分，因此必须在高度隔离的沙箱环境中运行，以确保系统安全。这种变化进一步延伸至更广泛的层面——从运行时的安全隔离，到数据安全机制的强化，再到整个执行过程中的数据管理与可信性保障。可以说，Agent 应用对基础设施提出了全新的安全体系要求，这是与传统应用相比的又一重大区别。

InfoQ：今年 9 月底的云栖大会上提到的 Serverless AI 到底是什么意思？它的核心概念是什么？

杨皓然： 在讨论“Serverless AI”这一概念时，我们的团队内部其实进行了充分的讨论，而且这个词本身也存在一定的争议。我们最担心的是，外界会误以为我们因为从事 Serverless 相关工作，就试图从这一视角去“迎合”当下的 AI 浪潮。但事实上，情况恰好相反——我们是基于对大量 AI 负载的深入分析，才逐步总结并提出了这一概念。

在这一过程中，我们发现了许多新的技术需求与能力。例如，在 AI 安全方面，传统基于 runc 的执行环境已经无法满足要求，必须采用虚拟机级别的隔离方案，如 MicroVM，以提供更强的安全沙箱。同时，Agent 的任务数量与负载动态变化程度远高于传统电商类应用。以大模型调用工具为例，这些工具的执行逻辑通常十分轻量，但对隔离强度要求极高，必须运行在不同的沙箱环境中。更复杂的是，这些调用往往呈现出稀疏且不可预测的特性——大模型可能在某一时刻同时调用多个不同的工具，从而产生强烈的动态性与突发性（bursty）负载特征。所以，我们认为这些负载的模式天然就是 Serverless 或者函数计算模式要去处理的。我们可以用几个关键词来总结一下，它本质上就是强隔离的、高并发的、高稀疏的负载特点，就是原本 Serverless 计算服务要解决的。

从我们的视角来看，可以明显感受到一个时代性的转变：在过去，我们所构建的能力对于传统微服务应用而言，或许只是“痒点”；但在新兴的 AI Agent 时代，这些能力却成为必须解决的“痛点”。正因如此，我们认为 Serverless 与 AI 的结合，能够为用户创造更大的价值，这也是我们之所以积极倡导“Serverless AI”理念的原因。

回到 Serverless AI 带来的结构性变化，从基础设施的角度来看，其核心问题在于——我们是否能够通过相关技术，让基础设施更好地适配 AI 负载的特征：包括强隔离、高并发以及高稀疏性。同时，这种适配能力需要能够在保障系统稳定性的前提下，为用户带来更优的成本效益和性能表现。

InfoQ：阿里针对高稀疏负载做了哪些优化？

杨皓然： 在高稀疏负载场景下，系统既要保持实例的状态，又要面对请求极少、指令稀疏的特性。这意味着实例在大多数时间里是闲置状态。当实例闲置时，系统会将其上下文状态保存在内存中，同时释放 CPU 资源，以便让其他实例复用这些算力资源。由于状态被保留在内存中，一旦新的请求到达，系统需要能够在 1 毫秒内完成实例的唤醒。关键问题在于如何准确判断请求已经到达某个实例。在传统的容器架构中，由于缺乏内置网关或请求路由与分发模块，系统往往无法精准地得知请求何时抵达，也不知道该将请求分配到哪个具体实例上。因此，这类架构通常依赖后台轮询或检测机制，导致请求唤醒延迟较高——通常需要约数秒左右。

相比之下，我们的系统通过设计一套专用的请求路由机制，能够精确识别请求的到达时间与目标实例。这种架构使系统可以即时唤醒目标 Sandbox 实例，从而实现毫秒级响应，极大提升了高稀疏场景下的性能与资源利用率。

InfoQ：业内也有一些公司在提 Serverless AI，阿里云的差异是什么？

杨皓然： 我们其实并没有过多去关注与友商或其他产品之间的差异。相较而言，我们更关注的是，如何真正帮助用户解决问题。面对多样化的技术选型，用户往往需要做出艰难的抉择，而我们的目标，是让他们能够通过我们的产品，更轻松、更高效地应对这些问题。

在基础设施领域，最终的评价标准始终会回归到四个核心维度：性能、成本、安全性与稳定性。我们所进行的所有技术布局与产品能力建设，实际上都是围绕这几个关键点展开的。以运行 AI Agent 为例，当用户需要使用大模型，或调用沙箱、浏览器（Browser Use）等工具来执行任务时，通常会有两种选择：要么直接使用我们提供的平台能力，要么基于一些流行的开源方案自行搭建系统。但如果综合考量性能、成本与安全等要素，就会发现，并非所有的解决方案或产品都能在这几个维度之间实现良好的平衡。而我们的目标，正是通过 Serverless AI 的架构设计与平台能力建设，帮助用户在这些核心指标上同时取得最优表现。

以开源自建为例，如今如果要实现类似 MicroVM 级别的安全隔离能力，往往需要依赖运行在裸金属（Bare Metal）环境上的特殊计算形态。然而，这类机器在云厂商体系中几乎不具备弹性，无法像普通的阿里云 ECS 虚拟机那样实现快速创建、按需释放或灵活伸缩。它们的资源形态更偏向静态，这意味着企业在采用开源方案自建系统时，不仅需要自行搭建和维护整套基础设施，还要面对资源无法弹性伸缩的问题。虽然这种方式在安全性上表现良好，但往往以牺牲弹性与成本效率为代价。

相比之下，阿里云在 Serverless AI 方向上提供的能力，能够在性能、成本与弹性之间实现更好的平衡。这正是我们的重要差异化优势之一。从产品设计的角度来看，我们无论在技术架构还是产品功能上，都针对 AI Agent 的高并发与高稀疏负载特性进行了大量优化。典型的 Agent 实例生命周期通常仅为几个小时，而在此期间，超过 90% 的时间它处于空闲或等待状态——要么在等待大模型完成推理并下达指令，要么在调用外部工具并等待返回结果。

针对这种“长时间空闲、短时高峰”的特征，我们从底层技术架构、计量计费模型和资源调度机制等多方面进行了专门设计，以实现性能与成本的双重最优。这些创新使用户能够在保障安全与稳定的同时，充分释放 Serverless 架构带来的灵活性与经济性。

我们会以更系统、更全面的视角来思考企业在当下如何真正实现 Agent 的落地。Agent 的落地绝不仅仅意味着拥有一个运行时环境那么简单。对于部分客户而言，单点的、原子化的能力可能已经足够；但对于更多企业来说，AI 时代的应用技术栈要比传统系统更加纵深，也更具复杂性。

因此，关键在于我们能否为客户提供一套完整而协调的产品组合能力。这套能力不仅应包含运行时本身，还需要覆盖流量网关、流量治理、可观测性以及记忆（Memory）等关键基础模块。只有将这些能力有机融合，构建出一个统一、连贯的体系，才能为客户提供端到端的一致体验，从而真正支持 Agent 应用的规模化落地与持续演进。

InfoQ：在落地 Serverless AI 层面，不同类型的企业会面临什么样的难点或阻力？

杨皓然： 不同类型的企业在落地 Agent 时的诉求与节奏存在明显差异。

首先，走得最快的一批企业，无疑是那些头部的基础大模型公司。由于他们在这一领域本身就具备最强的技术积累和专业能力，因此对于所有围绕大模型应用的探索，他们往往是最早的实践者。对这类企业而言，他们在落地过程中遇到的更多是 Serverless AI 或 AI Agent 运行时层面的一些单点技术痛点。如果能够在性能、成本和安全性之间找到更优的平衡点，并提供比现有方案更高效的解决思路，那么这类客户通常会非常愿意尝试并采用新的解决方案。

相对而言，另一类较为传统的企业目前还处在探索阶段。他们已经意识到 Agent 是未来的发展趋势，但还不清楚该如何与自身的现有业务体系相结合，进而真正创造业务价值。例如，哪怕只是最基本的模型工具调用，企业也会遇到诸多门槛。虽然通过一些开源工具，企业可以将存量 API 转换为 MCP Server 的形式以供大模型调用，但如何让模型进行有效、精准的工具调用，仍然是一个高门槛的问题。

因此，这类客户的诉求更倾向于寻求完整而有效的解决方案。他们希望我们不仅能帮助他们将存量业务系统转化为可被智能体调用的工具（例如将 API 转为 MCP Server 工具），还能确保这些工具能够被大模型精准识别与高效调用。进一步地，他们还希望在此基础上，将新产生的业务数据通过强化学习或模型微调的方式反哺模型，使模型能够与企业的业务逻辑形成更深层次的融合。

对于这类企业而言，他们需要的不再是单点的技术支持，而是一整套端到端的 Agent 落地解决方案，涵盖从业务系统改造到智能调用、再到模型持续优化的全流程能力。

InfoQ：对于不同类型的企业，Serverless AI 给客户带来的比较直观的优势是什么？

杨皓然： 以智谱的 z.ai 为例，他们在采用该方案后，整体部署成功率得到了显著提升。此外，吉利 作为国内领先的汽车制造企业，也在智能座舱方向上深度应用了 AI 能力。他们围绕智能座舱构建了多种与 AI 强相关的功能，例如 文生语音、意图识别、路线规划与导航等。举个例子，当用户说出诸如“我要接一个人，路上顺便找个玩具店买点东西”这样的语句时，系统需要能够精准识别用户的真实意图，并基于此进行路径规划和导航决策。这些复杂的语义理解与生成能力，都对 AI 模型提出了极高的实时计算与资源调度要求。在引入我们的函数计算之前，吉利的 GPU 资源使用相对固定且粗放，整体资源利用率较低。而采用 FC 之后，系统能够根据实例的活跃与闲置状态进行计费，实现了资源的弹性伸缩与高效复用。由于吉利的用户在使用车辆时存在明显的高峰与低谷时段，这一机制帮助他们将闲置的 GPU 资源充分利用起来，最终实现了约 30% 的成本下降。

另一类较具代表性的客户是义乌小商品市场，这是一家具有一定国企背景的上市公司。虽然整体风格偏传统，但他们在拥抱 AI 技术方面的速度非常快。在实际应用中，他们主要聚焦于文生图（Text-to-Image）场景，即如何利用 AI 快速生成商品的宣传图并完成上架。这不仅涉及 GPU 的使用，他们甚至还引入了阿里的 TPU，以进一步提升生成效率。

在这一过程中，我们为他们提供了一套完整的端到端文生图解决方案。该方案在开源软件的基础上，结合了他们自身的业务需求与商品特点，针对具体场景进行了深度优化。例如，我们根据不同商品类型和展示要求，定制了图像生成效果和模型参数的优化策略，确保生成的宣传图既符合审美，又能满足电商上架的要求。这种一站式解决方案帮助义乌小商品市场高效地完成了 AI 能力的落地，实现了从传统生产流程向智能化内容生产的快速转型。

InfoQ：针对用户提到的 Serverless AI 的难点，如启动延迟、GPU 弹性不足等有哪些补充观点？

杨皓然：Serverless AI 并不是要将技术栈的所有部分都以 Serverless 的方式实现，这样的做法并不合理。我们的思路是选择最适合采用 Serverless 模式的环节进行优化，例如 Agent 的运行时管理就非常契合这种架构。

相对而言，大模型推理并不适合采用完全的 Serverless 方式。我们目前通常采用 P/D 分离架构来实现推理服务。尽管如此，业界也在尝试引入一些 Serverless 的思想，例如在 P 与 D 分离的架构中，引入无状态化设计，使两类节点可以自由伸缩、提高资源调度灵活性。但从本质上看，大模型推理服务需要依赖高性能 GPU 来确保首包延迟，这类资源必须长期常驻，因此并不适合用完全 Serverless 的方式来实现。至于 GPU 弹性调度，在当前 GPU 资源依然极度稀缺的情况下，它的弹性是受限的弹性，无法像 CPU 那样随时按需扩缩。常见的实践方式是：用户具备一定规模的基础 GPU 资源，并在此基础上增加一定范围内的算力弹性。

从云厂商的角度讲，我们必须非常坦诚地指出：完全无限制的 GPU 弹性在当前阶段是无法实现的。我们能做的是在常驻资源的基础上，通过包年包月、按量计费或混合模式等多种方式，配合更优的资源调度与负载均衡策略，来提升 GPU 资源利用率，并进一步降低单卡成本。

Agent 时代，我们是否在叠加复杂度？

过去十年，微服务架构以“拆分、解耦、灵活”的理念帮助企业摆脱了单体系统的束缚，但也让系统边界、依赖关系与运维成本急剧上升。而当智能体（Agent）登上舞台，传统微服务的复杂度似乎并未消减，反而被进一步放大。

Agent 应用要求更高的动态性、异构性与隔离性——每一个智能体都可能在独立沙箱中运行，并随时调用外部工具或服务。这种“极度松耦合”的新常态意味着：企业不再仅仅在管理服务之间的依赖，而是在协调一个由数千智能体组成的动态生态系统。因此，关键不在于避免复杂性，而在于如何让复杂性被平台吸收。正如杨皓然所指出，企业需要从传统微服务的扩展和维护中抽身，借助更高层次的 Serverless 与 AI 平台，将精力转向智能化业务创新。Agent 时代的挑战，不是简单的架构升级，而是一场系统思维的重塑。

InfoQ：微服务的形态本身有变吗？

杨皓然： 微服务的理念在 Agent 时代依然具有很强的适用性。例如，它所强调的“松耦合”原则在这一时代不仅继续存在，甚至被进一步强化。在传统微服务的视角下，许多组件或工具之间的松耦合程度通常是有限的——例如，我们并不会刻意让它们在完全独立的沙箱中、以极度分散的方式运行。

然而，在 Agent 时代，这种高度松耦合的模式反而成为必要。由于 Agent 需要在动态、异构且不确定的环境中调用大量外部工具与服务，必须保证各组件之间具有足够的独立性与隔离性，从而确保系统的安全性、灵活性与可扩展性。

InfoQ：许多公司可能刚刚在这一波 AI 浪潮到来之前，才刚刚完成自身内部微服务体系的建设与完善。

杨皓然： 因此，一个值得深入探讨的问题是：在微服务时代，系统架构已经具备相当高的复杂度，那么在进入 Agent 时代后，企业该如何更高效地完成这一转型？在微服务时代，我们曾拥有许多优秀的平台——例如当前我们正在构建的类似 SAE（Serverless Application Engine）这样的产品——它们的目标就是帮助那些基础设施能力相对薄弱的团队，能够快速采用并运行微服务架构。

如今，随着 Agent 时代的到来，理念层面的转变显得尤为重要。企业需要重新审视资源投入的方向——不应继续将大量精力消耗在传统微服务应用的维护与扩展上，而应主动拥抱更具潜力的 Agent 架构。为了实现这一转变，关键在于选择更高效的平台与工具，让团队能够从繁琐的底层复杂性中解放出来，从而专注于构建更智能、更具创新性的应用。

TCO 平均降低 60%，百倍启动加速，AgentRun 如何搞定智能体落地难题？

AgentRun 不是单一的性能优化工具，而是一套面向智能体时代的基础设施重构方案——在保证高可用与高安全的同时，真正让“百倍启动加速、TCO 平均降低 60%”成为企业落地智能体的现实起点。

InfoQ：很多企业在部署和落地 Agent 时都会遇到挑战，你们观察到的主要问题有哪些？这些问题为什么传统模式难以解决，而你们又是如何更好应对的？

杨皓然： 举个例子，在运行时层面，由于新的负载模式已经演变为强隔离、高并发、高稀疏的特征，传统的 PaaS 或 IaaS 架构并非为此设计，因此要么弹性受限，要么安全性受到挑战。例如，智谱的大模型产品 z.ai 就是一个典型案例——作为其核心产品入口，它在落地过程中就面临了不少技术层面的挑战。

智谱的这款产品是一个偏 C 端的应用，它设计了一些非常有趣的功能，其中最具代表性的是“一键分享项目”。这一功能极大地提升了产品的传播性与用户体验，但同时也带来了较大的技术挑战。原因在于，项目被分享出去之后，何时会突然成为爆点是无法预判的。

在传统或现有的架构模式下，我们通常会为每个全栈项目在使用时单独拉起一个 Sandbox 来执行任务。然而，当这些项目被用户分享出去后，这种模式往往就无法满足需求了。因为一旦某个项目成为热门工具或爆款应用，就可能在短时间内吸引大量流量，对系统的弹性伸缩能力提出极高要求。

目前市面上大多数同类产品的设计，仍然是以“单独的 Sandbox 实例”为核心的。然而，这类项目本质上真正需要的并不是孤立的 Sandbox 实例，而是一个能够根据流量变化实现快速弹性伸缩的 Sandbox 服务。如何在保证安全的前提下实现这种高弹性、高可靠的服务架构，正是其中最大的技术挑战之一。

另一方面，可以打个比方：假设一个大型平台上存在几十万甚至上百万个项目，但其中 99.9% 的项目实际上都是处于“冷”状态的。如果为每一个项目都常驻一个运行实例，那无论从成本还是资源角度来看，都是完全无法承受的。

因此，这类系统必须具备能够自动缩容至零，并根据流量变化实现快速拉起的能力。只有这样，才能在保持高性能与高可用的同时，实现资源和成本的最优平衡。而这些问题，恰恰是当下 Serverless 架构或函数计算产品所擅长解决的。以上这些，正是我们在头部企业中看到的，在大规模落地 Agent 应用或平台化部署过程中，运行时层面最典型的技术挑战。

另外，对于一些相对传统的企业来说，在推动 Agent 落地时往往会有一个非常现实的诉求：他们拥有大量的存量业务系统，希望这些系统能够与大模型或智能体进行交互，成为可被调用的工具。这一需求非常自然，但要真正实现却并不容易。首先，企业需要将现有的业务 API 改造为类似 MCP Server 的形态，使其能够被大模型安全、规范地调用。其次，企业往往会拥有数量庞大的 API ——当这些 API 全部转换为 MCP Server 后，就会形成一个规模巨大的工具集。

然而，这其中 可能有 99% 的工具在大多数场景下都不会被调用，这就带来了新的挑战。对于大模型而言，如何在成千上万的内部业务系统 API 中精准地选择、判断并调用合适的工具，是一项极具难度的问题。如何解决大模型的工具选择效率、调用准确性以及资源管理等问题，正是企业在 Agent 落地过程中普遍面临的关键挑战之一。而这些问题，也正是我们相关产品能力要重点去解决的方向——帮助企业更高效、更智能地将传统业务系统接入大模型生态，实现人与智能体、智能体与系统之间的真正协同。

此外，可观测性依然是一个永恒的主题。在微服务时代，由于应用被拆分成大量独立的服务模块，服务之间的调用关系复杂，因此对可观测性的需求本身就非常强烈——企业需要具备全链路追踪的能力，才能有效定位问题与优化性能。

进入 Agent 时代后，类似的需求同样存在，甚至更加突出。因为如果一个 Agent 完全是“黑盒”的，企业自然不会放心将其直接部署到生产环境中。企业需要能够清楚地知道——哪些输入、哪些调用会消耗大量 token，系统的行为和资源使用情况是否可控，以及如何对这些过程进行监测与治理。

智谱在这一过程中也进行了大量的方案对比与选型，最终发现我们的解决方案能可靠的支撑大规模业务体量，并在性能、成本上取得很好的平衡，因此成为他们的最优选择。

InfoQ：此前看到阿里云的 AgentRun 平均能为企业降低 60% 的 TCO 成本，这个数据是如何测算的？在上线前后，客户会有哪些明显的指标或体验变化？

杨皓然：60% 的 TCO 降幅其实是一个相对保守的估计。在一些典型场景中，我们会对比客户采用自建方式实现类似 Agent 运行时能力所需的成本。举个例子，如果企业采用自建模式，其资源往往需要 7×24 小时常驻运行。然而在实际使用中，大多数 Agent 或其对应的工具 Sandbox 在生命周期中都是低频、稀疏活跃的，尤其在偏 C 端的应用场景下，Agent 或 Sandbox 的活跃比例通常只有个位数。这并非技术能力问题，而是由负载特性本身决定的。因此，采用传统常驻方式会导致极高的资源浪费与成本开销。

其次，从运维成本角度来看，企业如果要自行整合底层基础设施与相关工具，还需要投入人力，例如招聘两到三名具备经验的基础设施开发与运维工程师，以保障系统稳定运行。

综合来看，将资源成本与运维成本相加后，TCO 降低约 60% 已经是一个相对保守的估值，在某些场景下甚至可能更高。

InfoQ：AI 时代，安全尤为重要。阿里云的袋鼠安全容器据说实现了虚拟机级隔离和毫秒级启动，那么在 AI Agent 时代，安全容器与云原生时代相比有哪些技术差异？

杨皓然： 袋鼠安全容器在技术思路上，与亚马逊云科技主导的开源方案 Firecracker 基本一致，但在我们的系统中，其实现方式存在较大的差异。我们将袋鼠安全容器与更大范围的系统进行了深度、有机的整合。举例来说，以“拉起容器实例”这一过程为例。如果在传统的 Kubernetes（K8s） 系统中执行该操作，会发现实际的主要开销往往并不来自安全容器本身。无论是袋鼠安全容器还是 Firecracker，其自身的启动时间都能控制在百毫秒级别。但若在 K8s 环境中启动一个 Pod，从端到端的视角来看，整体耗时往往会达到数百毫秒甚至数秒，这背后存在许多需要优化的环节。

例如，镜像管理方面，可以通过高速缓存或按需加载的方式来减少启动延迟，从而避免在容器启动前必须完整加载镜像数据。同时，K8s 在容器启停过程中还存在较多管控层面的开销，如写入 etcd 等操作，这些额外流程累积起来，往往远高于使用袋鼠安全容器 MicroVM 启动的时间成本。

因此，我们的平台从全链路优化的角度出发，系统性地消除了这些非必要的开销。总体来看，我们更倾向于以系统化、垂直整合的思维来设计与优化整体运行时架构，而不仅仅局限于某个单点技术的改进。

InfoQ：Agent 的上下文怎样保持？用户中断之后怎么能接上话题？怎样让 Agent 看起来更智能？

杨皓然： 这一部分实际上涉及到负载特性的变化，即从“无状态”向“有状态”演进。为了适应这种模式，底层基础设施必须进行大量针对性的优化。

在 Agent 场景 下，如何保持上下文成为关键问题。如今，我们通常需要通过 session 机制 来实现这一点。来自同一会话的请求必须被路由到同一个实例上，而不能像传统无状态架构那样随机分配到任意实例，否则一旦请求落到新的实例，就会导致 Agent 之前的上下文丢失。这种机制本身并不复杂，但在实际实现中仍有一定挑战。因为这是有状态的对话场景，意味着实例可能需要在整个 session 生命周期内持续存在，而这期间的大部分时间，它可能处于闲置状态。

为了解决这一问题，我们在底层运行时中设计了智能判定机制，能够快速区分实例当前是活跃还是闲置。当实例处于闲置状态时，我们仅在内存中保留其实例与 Agent 上下文，将 CPU 计算资源释放出来，用户因此也无需为 CPU 占用付费。而当新的请求或大模型的指令到达时，系统可以在 1 毫秒内唤醒处于闲置状态的实例，并无缝衔接上下文继续执行。通过这种方式，我们成功适配了 高稀疏负载场景，实现了性能与成本之间的最佳平衡。这正是我们在 Agent 运行时设计中所追求的目标——既保证系统高效运行，又最大化资源利用率。

另一个常见的场景是：有些用户的 Sandbox 或 Agent 实例 可能在执行数小时后就可以关闭，但他们希望在一周之后重新启动时，系统能够接着上一次的状态继续执行。这种需求在 Agent 训练场景 或 偏 C 端的应用 中十分常见。

针对这种情况，我们需要提供一种性价比更高的解决方案。例如，如果实例在长时间（如七天）后才会被再次唤醒，那么我们显然不应继续使用内存来保存其状态。相反，可以将状态数据持久化存储，在需要时再进行恢复。此时虽然恢复速度无法像内存中那样做到 1 毫秒级，但通常只需 几百毫秒到数秒 即可完成状态恢复并继续执行。

从用户体验的角度来看，这种方案是一个性能与成本的合理平衡——虽然性能略有下降，但运行成本显著降低，整体体验依然可以接受。因此，Sandbox 或 Agent 的状态持久化与恢复能力 是运行时架构中非常关键的一环。我们目前正在持续完善这项能力，尽管尚未完全上线，但已经取得了初步成果。

InfoQ：这种上下文存储时间的极限大概是多少呢？

杨皓然： 对于用户来说，他们对于存储的时间极限肯定是不要有限制。我们现在能做到的存储极限大概是一个月之内。

InfoQ：AgentRun 的性能和传统方案比快了 100 倍，这个数字是怎么得出来的？

杨皓然： 如果状态数据被保存在内存中，用户只需为内存资源付费，并且系统可以在 1 毫秒内完成唤醒。这与传统依赖完整容器启动的方式相比，效率提升是巨大的。当前容器生态中也有一些类似的方案，但其唤醒时间通常需要约 数秒左右，而我们能够将这一过程缩短至毫秒级。

此外，函数计算（Function Compute） 在冷启动方面本身就具备显著优势。我们在此基础上进行了大量针对性优化——既继承了函数计算启动迅速的特性，又结合 有状态、高稀疏负载 的运行特征，在调度机制、唤醒速度以及计量计费体系等方面进行了深度改进。

通过这些优化，我们能够在保证极致性能的同时，实现更高的资源利用率与成本效率。

InfoQ：在计费模式上，系统怎么判断是真闲置还是假闲置？

杨皓然： 第一个维度是系统是否收到了用户请求。目前的函数计算产品与其他同类产品不同——任何用户请求都必须先通过函数计算系统的内部组件，再转发给对应的 Sandbox。这种架构设计的初衷是为了支持快速的请求伸缩，也因此具备了天然的可观测性。系统能够准确知道某个实例何时开始执行请求、何时执行结束，而在这一时间段内，该实例显然处于活跃状态。

第二个维度是针对后台任务的判断。即便实例当前没有前端请求执行，后台仍可能存在一些后台任务，用于处理异步或周期性的动作。在这种情况下，我们会利用操作系统层面的监控能力，检测实例运行过程中 CPU 时间片的消耗情况。当 CPU 使用量超过预设阈值时，我们就会认为该实例处于活跃状态。通过这两种手段结合，我们能够高精度地判断实例的活跃或闲置状态，从而在资源调度与成本优化上实现更智能、更高效的管理。

面向开发者的易用性与生态建设

在智能体（Agent）快速发展的浪潮中，开发者体验与生态建设 已成为推动落地的关键环节。杨皓然指出，阿里云并不希望 Serverless AI 仅服务于少数头部客户，而是致力于让中小企业与独立开发者也能低门槛地构建、运行和管理智能体应用。

InfoQ：从开发者的角度来说，阿里接下来有哪些提升易用性的计划？

杨皓然： 我们的产品并非只面向少数头部用户设计，而是希望同时服务大量的中小客户和开发者群体。未来，我们将持续推出多项关键能力，包括 模型服务治理网关、系统可观测性，以及 Sandbox（运行时环境） 等。其中，Sandbox 将涵盖 Code Sandbox 与 Browser Sandbox，通过深度整合这些运行时能力，进一步提升整体的开发与运行体验。

在此基础上，我们还会提供丰富的应用模板，使开发者能够将基于主流开源 Agent 框架构建的应用，快速部署到我们的平台。同时，我们将把网关流量治理、身份认证、可观测性以及记忆机制等能力有机结合，帮助用户高效落地各类 Agent 应用。总体而言，我们不仅专注于单点、原子化的产品能力打磨，更注重将这些能力系统化整合，形成面向不同客户需求的完整解决方案。

Serverless AI ：全链路保障智能体的稳定高效运行

Serverless AI 的未来演进将同时在 底层能力打磨与系统化整合两个方向上深入推进。真正让智能体成功落地的，不仅仅是强大的大模型，而是模型 + 基础设施 + 数据治理的系统性协同。可以说，Serverless AI 不只是“更轻的计算形态”，而是一套面向 AI 原生时代的全链路智能体基础设施标准——帮助企业以更低成本、更高效率实现智能体的规模化、可持续演进。

InfoQ：您怎么看待 Serverless AI 未来的演进？

杨皓然： 我们的 Serverless AI 产品体系，主要围绕两个核心方向展开。

第一，聚焦原子化能力的打磨。我们重点提升包括 运行时、可观测性、网关以及记忆机制在内的基础能力，确保在性能、成本与安全性等维度上具备足够的竞争力，从而在单点技术选型上赢得用户的信任与认可。

第二，将原子能力有机整合为完整的解决方案。在此基础上，我们进一步探索如何将这些能力系统化、场景化地结合起来，形成适配不同需求的端到端解决方案。例如，在强化学习这一未来极具潜力的垂直方向，我们正在思考如何帮助用户降低技术门槛、简化实现路径，以便他们能够更高效地构建并应用相关能力。

总体而言，我们将继续沿着这一思路，不仅打磨底层技术能力，更要构建起具备实际落地价值的 Serverless AI 整体解决方案。

在企业推进智能体落地的过程中，需要重点关注以下几个方面。我们要充分认识到智能体的落地并不只是依赖于强大的模型能力。很多人误以为只要使用性能优异的模型，就能轻松实现良好的效果，并与业务场景顺利结合，从而快速证明业务价值。实际上，这种理解是不全面的。模型能力的提升固然重要，但仅有模型远远不够。真正成功落地的智能体，必须依托完善的基础设施与系统化解决方案，包括运行环境、调度体系、数据管理、观测能力等。这些底层支撑共同构成了智能体能够稳定、高效运行的关键基础。因此，在企业智能体落地的过程中，除了要持续关注模型能力的演进，更应重视智能体基础设施的建设与完善。

对企业而言可关注三个层面事情的推进：第一，业务实现工具化。也就是说，企业需要思考如何将自身的业务功能转化为可供 Agent 调用的工具，实现与智能体的高效交互。这是落地过程中的关键起点。在实践中，需要评估现有的 API 是否能够快速封装为 MCP Server，并与 Agent 建立通信。但仅仅具备 MCP Server 还不够，如果模型无法准确调用这些接口，其价值也会大打折扣。因此，还需要配套的解决方案，使模型能够在不同场景下准确识别用户意图，并正确调用企业已有的系统工具或 API。

第二，选择合适的智能体基础设施方案。第三，重视面向智能体的数据治理。目前，使用 Agent 并不意味着它能立即在业务中发挥价值。企业需要让业务数据持续与智能体交互，以帮助模型更好地理解业务逻辑、适应业务场景。这就要求具备完善的数据治理能力，包括数据隐私保护、安全合规管理与数据质量控制等环节。