作者：世如
AI 应用基础设施正在经历一场深刻的范式迁移。传统的 AI 应用工作负载部署模式，以其长期预置、“始终在线”的算力特征，正面临着日益严峻的经济可持续性挑战。对于需求呈现尖峰或不可预测特征的工作负载而言，这种模式导致了严重的资源浪费和成本空转。行业分析表明，面对新的工作负载特点，为了实现成本效益与可扩展性的统一，业界正战略性地转向 Serverless 计算范式，部分企业报告称其基础设施成本节约高达 40% 至 70%。
这一转变不仅仅是企业根据业务特征，尝试成本优化的技术选型，更是由云上 AI 时代的内在需求驱动的必然架构演进。Gartner 等权威分析机构预测，生成式 AI 将成为继蒸汽机、电力和互联网之后的又一项通用目的技术，其深远影响将重塑各行各业。
为应对这一趋势，主流云服务商正积极重塑其技术堆栈，将 AI 能力原生融入所有云服务技术迭代中，催生了“AI 原生云”的诞生。阿里云等厂商凭借其在 Serverless 领域上的持续投入，特别是针对 AI 应用开发的专注投入，根据最新的 Forrester 评测结果，已被行业报告评为市场领导者，这标志着 Serverless AI 技术的市场成熟度和厂商的战略决心。将 AI 应用运行时迁移至 Serverless 平台，是应对未来智能化浪潮、实现敏捷创新和高效运营的必由之路。
AI 应用形态的持续演进
从传统应用到 AI 应用，是人机交互从“人适应机器”到“机器适应人”的范式转移。传统应用将世界数字化并置于确定的逻辑框架中，而 AI 应用以大语言模型的智能为基石，利用自然语言驱动智能；同样，AI 应用本身的形态也在伴随业务和 AI 生态的发展持续演进，尤其是在运行时与用户交互的形态发生了根本性转变。
1、“请求-响应”模式：无状态的事务性 AI 任务
在 AI 应用的早期阶段，其交互模式很大程度上继承了传统 Web 服务和微服务的“请求-响应”（Request-Response）模型。这种模式可以被看作是“事务性 AI”或“工具型 AI”，其核心是执行一个独立的、原子性的任务。
核心特点：
- 一次性交互：用户提出一个明确、独立的请求，AI 系统处理这个请求并返回一个最终结果，交互到此结束。
- 无状态：这是该模式最关键的特征。系统不会记忆之前的交互历史。每一次请求都是一个全新的开始，与上一次请求无关。服务器不存储任何关于过去请求的上下文信息，使得每个请求都可以被任何可用的计算实例独立处理。
- 任务导向明确：非常适合功能单一、目标明确的任务，其行为通常是幂等的（Idempotent），即多次相同的请求会产生相同的结果。
- 输入输出固定：用户需要将问题或数据格式化成系统能够理解的特定输入，系统则返回一个结构化的输出。
典型例子：
- 图像识别：上传一张图片（请求），系统返回“这是一只猫”（响应）。
- 文本情感分析：输入一段文字（请求），系统返回“正面”或“负面”（响应）。
- 机器翻译：输入待翻译的句子（请求），系统返回翻译结果（响应）。
在这种模式下，AI 更像一个高效的、自动化的工具。这种无状态的设计与 Serverless 架构的理念完美契合。因为计算层是无状态的，平台可以近乎无限地水平扩展，通过并行启动成百上千个独立的、可互换的函数实例来应对流量洪峰，实现了极高的弹性和容错性。
2、“对话”模式：有状态的协作式 AI 智能体
AI 应用的关注点已从单纯驱动 LLM 完成指令，转移到了如何利用外部工具（Tools）和知识库构建更加智能的 Agent。
核心特点：
- 持续性交互：交互是连续的、多轮的。用户可以不断地追问、澄清、修正或在上一轮结果的基础上提出新要求，形成一个逻辑连贯的会话。
- 有状态：AI 系统必须能够记忆和理解对话的上下文（Context）。它需要知道你们之前聊了什么，这使得对话能够层层深入。单个请求和事件的处理不再是孤立的，而是严重依赖之前的执行上下文。例如，当用户说“取消它”时，系统必须知道前一个请求是关于“预订机票”的，才能正确理解“它”的指代。
- 任务探索与迭代：非常适合复杂、开放式、甚至用户一开始都无法明确描述的任务。用户可以在与 AI 的对话中，逐步明确自己的需求，并与 AI 共同协作，迭代出最终的解决方案。
- 自然语言交互：用户可以使用最自然的日常语言进行交流，无需学习特定的命令或格式。
典型例子：
- 智能聊天机器人：你可以让它“写一首关于秋天的诗”，然后说“太悲伤了，改得欢快一点”，AI 都能在理解上下文的基础上完成。
- AI 编程助手：你不仅可以要求它生成代码，还可以让它解释代码、调试代码、甚至重构整个项目。
- 个性化旅行规划：你可以说“帮我规划一个五天的东京家庭旅行”，然后根据它的建议不断调整：“我们家有老人，行程安排得松散一点”、“把购物换成一个博物馆参观”。
从技术层面看，这种“有状态”的行为是通过“上下文窗口”（Context Window）来模拟实现的。一个关键的技术洞察是，LLM 在推理期间本身是无状态的，它的模型权重是固定的，不会因请求而改变。通过将之前的对话历史作为输入重新提交给模型，它得以模拟出记忆和状态。此外，为了提升性能和降低成本，诸如键值缓存等技术被广泛应用，它缓存了先前对话内容的计算结果，这本身就是一种必须在多次请求之间保持的状态。
因此，从事务性到对话式的转变，并不仅仅是用户界面的演进，它代表了架构优先级的根本性变化。在传统 Serverless 架构中，无状态是实现可扩展性的关键；而在现代 AI 应用中，会话状态的持久化及会话执行上下文共享成为了实现应用智能和性能的先决条件，这一根本性的变化，是所有后续架构演进的根源。
“会话”驱动对 Serverless 运行时的审视
Serverless 架构是一种事件驱动的计算模型，开发者只需上传代码片段，平台负责自动管理底层基础设施。其诸多优势：极致弹性、按需执行、按量付费、自动伸缩、资源隔离和简化运维。这完美匹配 AI 应用稀疏、不确定、脉冲式的调用模式，实现了真正的按价值付费。
然而，当这种为无状态、短周期、请求-响应式设计的计算平台，面对本质上有状态、长周期、交互式的会话模型时，继续保持产品形态定义，还是解决客户业务场景需求，一场围绕业务需求的架构演进便不可避免地爆发了。
1、Serverless 对 AI 的承诺：弹性与成本效益
在探讨挑战之前，必须首先明确为何业界如此渴望将 AI 应用部署在 Serverless 平台上。主要原因在于其对具有不可预测流量模式的工作负载的天然适应性。早期的 AI 推理任务调用往往是稀疏且突发的，例如一个内部使用的客服机器人可能在工作时间有大量请求，而在夜间则完全空闲。在这种场景下，为峰值流量预留昂贵的、持续运行的服务器是极不经济的。更大规模的 AI 智能体，工具运行时，同样要求 Serverless 平台能够根据请求量从零自动扩容到数千个实例，并在空闲时缩容到零，确保开发者只需为实际的计算时间付费，从而极大地优化了成本。
2、核心矛盾：无状态架构如何承载有状态应用
试图在经典的无状态 Serverless 平台上运行对话式 AI 应用，会引发一系列环环相扣的架构性难题。这些问题并非孤立存在，而是一个由核心矛盾引发的连锁反应。
1）状态持久化与数据局部性业务适配难题
Serverless 函数请求的生命周期通常是短暂的，请求时机通常又是不可预测的，这意味着任何存储在函数实例内存或本地临时存储中的数据都会随着实例的销毁而丢失，结合平台的调度特征，逻辑上实例会在请求结束的任何空闲时刻发生轮转。在不改变架构的情况下，为了维持会话状态，唯一的办法是将状态外置，即在每次函数执行结束前，将会话上下文保存到一个外部的持久化存储系统中，如阿里云对象存储（OSS），表格存储（OTS）或 Redis，并在下一次执行时重新读取恢复上下文。
这种模式虽然根本上解决了状态丢失的问题，但实际改造过程中常常面临两个常见的架构适配难题：
- 编程模型复杂度高： 依赖于 AI 应用针对 Serverless 架构改造，梳理其内部状态依赖，将有状态部分统一收敛到上下文的记忆存储中，彻底无状态化，这种无状态化的过程，本身伴随业务对于 Serverless 架构的适配，这种适配对于很多客户而言存在技术复杂度，同时也带来了很大的改造成本，尤其对于存量业务，这种适配通常会被拒绝；
- 状态外置引入性能和成本问题： 对于每一轮对话，函数都需要至少两次网络往返，一次读取状态，一次写回状态，与外部存储系统进行交互，尤其在需要毫秒级响应的实时对话应用中，这种额外的延迟是难以接受的，更大的风险在于这种访问引入了不确定性和业务稳定性风险，一定程度上影响了用户体验，同时会带来一定的架构成本。
2）基于函数模拟会话实例生命周期管理复杂且脆弱
除了状态外置，为了保持会话和隔离，另一种常用的做法是通过单个轻量函数模拟会话，每个会话都对应一个配置了单个预留实例的函数，这样请求都会路由到一个实例中，从而解决多轮对话状态问题。这意味着，会话的生命周期必须与函数实例的生命周期严格同步。当一个用户会话结束时，为了解决成本问题，用户需要通过更新函数的弹性策略，将实例数从 1 调整为 0，以触发实例的回收，从而避免产生不必要的闲置费用。这个过程被证明是“复杂且难以有效管理的”。即便一直保持一个预留实例的情况下，预留实例意味着只承诺在有请求的时候总是有实例存在，但并不保证处理每次请求的实例是同一个，在请求的间隔期随时可能会发生实例轮换，很难保障业务上下文的完整性。
此问题的根源在于 FaaS 平台设计的核心假设——实例是短暂且由平台自动管理的。函数计算的实例生命周期（创建、调用、销毁）是事件驱动的，其设计目标是响应请求的潮汐变化，而非维持一个与外部业务逻辑（如用户会话）同步的、长周期的状态。虽然平台提供了预留实例和生命周期挂钩（如 Initialize，PreStop）等高级功能，但这些功能的设计初衷是为了应对冷启动或实现优雅停机时的状态处理，而不是作为管理长连接会话状态的核心机制。因此，基于函数的隔离方案，更适合那些本身在业务维度具有显著配置差异、无法通过简单会话维度进行隔离的复杂场景。在这些特定情况下，函数隔离是一种最佳实践。
3）传统 Web 场景的会话亲和的局限性和可靠性挑战
业界部分 Serverless 产品，例如 Google CloudRun 支持了面向传统 Web 场景的尽力会话亲和（Session Affinity）调度能力。其核心思想是通过负载均衡机制（如基于 Cookie 或请求头）将来自同一用户的所有连续请求都路由到首次处理该用户请求的那个特定的函数实例上，这样会话状态就可以缓存在该实例的内存中，避免了频繁的数据库读写操作，只需要在对应的实例生命正真结束的时候，通过运行时提供的生命周期管理机制进行状态的保存。
然而，这种单纯尽力会话亲和，而没有在调度和隔离方面做进一步适配AI的业务需求；会话亲和将函数实例变成了持有关键会话状态的载体，这种实例的状态维持仍然采用了原有 Serverless 算力的调度方式，没有保障实例的生命周期，这个实例一旦失败，内存中的会话状态就会丢失，导致服务中断。
其根本原因在于，传统的会话亲和方案并未在资源维度上对 Serverless 实例施加额外限制，其调度层依然是请求维度的，未能结合会话进行更细粒度的适配。
- “尽力而为”的可靠性： 亲和性并非得到保证。如果那个“粘性”实例发生故障、因不活动而被回收，或者平台需要缩容，其内存中存储的会话状态将永久丢失。下一个请求将被路由到一个新的实例，从而中断对话。
- 没有提供真正的隔离： 单个函数实例仍然可以同时为来自多个不同用户会话的请求提供服务，如果在代码中处理不当，会产生跨会话数据泄露的安全风险。
- 破坏可扩展性： 单纯依赖会话亲和路由，仍然按照请求负责调度，破坏了 Serverless 的主要优势，即水平扩展能力。请求不再均匀分布在所有可用实例上，即某个实例过载而其他实例却处于空闲状态，从而产生性能瓶颈，只考虑请求亲和，而没有按会话维度进行负载均衡，最终导致了‘热点’问题。
- 成本模型的困境： “按使用付费”的核心诉求。
为了解决致命的冷启动问题，云厂商的 Serverless 产品，例如阿里云函数计算，AWS Lambda 提供了预置并发（Provisioned Concurrency）功能。它允许开发者预先启动并保持一定数量的“热”函数实例，这些实例已经完成了环境初始化和代码加载，可以立即响应请求，从而彻底消除冷启动延迟。
单纯将预置并发应用于 AI 应用会话场景，破坏了 Serverless 最核心的成本优势——“按实际执行付费”。开发者需要为这些预留的、即使在没有请求时也持续运行的实例支付费用，这本质上是回归到了传统的预留实例付费模式，这不仅增加了运营成本，也让 Serverless 的核心价值主张变得模糊。
综上所述，这些挑战构成了一个紧密耦合的架构困境：为解决状态持久化问题而引入的性能开销，促使开发者采用面向传统 Web 场景的会话亲和性；而会话亲和性又破坏了 Serverless 的弹性和容错性。同时，AI 应用单纯的缩零，放大了冷启动问题，而解决冷启动的预置并发方案又侵蚀了其核心的成本模型。这表明，简单的修补和变通已无法解决根本矛盾，行业需要一场更深层次的架构变革。
“会话”驱动的 Serverless 运行时架构演进
面对有状态 AI 应用带来的严峻挑战，站在业务机遇和架构合理性的十字路口，面对如今的 AI 场景，需要从产品、技术维度围绕业务核心特征进行架构的演进，Serverless 架构选择从“会话”进行架构升级，突破原有无状态架构的束缚，开启了一场深刻的自我演进。
1、阶段一：状态外置化，Serverless架构最佳实践
这是最早期也是最直接的解决方案。该模式严格遵守 Serverless 函数的无状态原则，将所有会话状态的管理责任完全推给外部系统。其工作流程如下：
- 一个函数实例接收到用户请求。
- 函数从外部的高性能键值存储（如 Redis）或数据库（如表格存储 OTS）中，根据会话 ID 读取当前用户的上下文信息。
- 函数执行业务逻辑，并可能会更新会话状态。
- 在将响应返回给用户之前，函数将更新后的会话状态写回到外部存储中。
- 函数实例被销毁，不保留任何状态。
这种架构的优点是简单、清晰，并且保持了计算层的完全无状态，从而保留了 Serverless 的高弹性和高容错性。然而，如前文所述，其主要缺点是性能开销，每一次交互都伴随着至少一次网络往返的延迟，对于低延迟要求的对话场景构成挑战。
对于当下 AI 应用而言，一种最佳的方式是重复利用 Agent 及工具框架提供的长时记忆（Memory）能力解决状态耦合问题。
2、阶段二：传统会话亲和性调度适配
为了缓解状态外置化带来的性能问题，会话亲和性调度应运而生。它是一种在无状态架构上模拟状态行为的“变通”方案，旨在通过将同一会话的请求路由到同一计算实例，来利用实例内存进行状态缓存，从而减少对外部存储的依赖。
平台通过多种技术手段实现亲和性调度：
- Cookie 亲和： 负载均衡器在第一次响应中向客户端植入一个包含实例标识的 Cookie。客户端在后续请求中携带此 Cookie，负载均衡器据此将请求转发到指定的实例。
- Header Field 亲和： 客户端在自定义的 HTTP 请求头（如 x-fc-session-id）中传递会话标识。服务端基于该标识进行哈希计算，将请求稳定地路由到特定实例。
尽管会话亲和性在一定程度上提升了性能，但它引入了严重的架构妥协。Google Cloud Run 的文档明确指出，这种亲和性是“尽力而为”（best effort）的，因为实例可能因自动缩容、故障或达到并发上限而被终止，从而导致会话状态丢失。阿里云函数计算采用了另一种原生做法，在会话亲和能力上，克服“尽力而为”提供一种强亲和能力，同时提供了Session维度并发控制解决会话维度的负载问题，同时提供了会话隔离能力。
3、阶段三：平台原生状态抽象
这一阶段标志着一个重要的范式转变：与其在无状态的函数上“模拟”状态，不如让平台本身提供一种原生的、有状态的编程模型。其中的典范是 Azure Durable Functions，特别是其持久实体（Durable Entities）功能 。Durable Entities 采用了“Actor”模型的设计思想，将状态和行为封装在一个个可寻址的“实体”中。每个实体拥有一个唯一的 ID 和内部状态，该状态由平台自动持久化到存储中。对实体的所有操作都以消息的形式发送，并由平台保证按顺序、串行地执行，从而天然地解决了并发和竞态条件问题 。
开发者不再需要手动管理外部数据库的读写和锁机制，而是可以直接与实体对象交互，平台在后台处理了所有的状态持久化和恢复逻辑。这种模式极大地降低了开发复杂性，同时提供了强大的容错保证。它代表了 Serverless 架构从“无视”状态到“管理”状态的重大进步，这种设计范式为 Serverless 平台的状态化困局提供了新思路：平台从过去要求应用自身‘无状态化’，转变为主动提供‘状态管理’的基础设施支持。这是一个重要的能力升级。当然，这也依赖于平台侧的能力，需要平台解决数据访问、写入和网络安全等一系列问题。
4、新前沿：为 AI 定制的“会话式” Serverless 运行时
最新的演进是为 AI 应用相关的运行时主体（包含 AI 智能体、AI 工具等）的独特需求而设计全新运行时架构。这种架构认识到，AI 会话既需要状态持久化，又需要高性能的本地计算和强隔离性。
在这种趋势下，Serverless 业界领导者阿里云和亚马逊云科技（AWS）分别给出了自己的答案：阿里云依托 Serverless 产品函数计算突破架构边界，产品原生提供会话（Session）支持，为每一个用户会话（Session）动态配置一个专用的、持久化的微虚拟机（MicroVM），确保会话隔离实例在生命周期内持续存活长达 8 小时，未来最长可达 24 小时，并能够保持请求的优雅结束，同时基于会话维度提供的实例和存储隔离能力，并在此基础上即将发布面向 AI 场景更靠近业务的基础设施套件 AgentRun，包含了构建 Agent、Sandbox 的基础运行时。
而 AWS 则通过新的 Serverless 产品，发布了 AWS Bedrock AgentCore Runtime，其运行时底层基于 AWS Lambda；其核心架构创新在于，它为每一个用户会话（Session）动态配置一个专用的、持久化的微虚拟机（MicroVM），该环境可以持续存在长达 8 小时 。这种“一个会话，一个运行时”的模型从根本上解决了传统 Serverless 的所有状态难题：
- 原生状态保持： 会话上下文、中间计算结果、甚至临时文件都可以直接存储在 MicroVM 的内存和本地文件系统中。这消除了与外部数据库交互的网络延迟，为 AI 代理的多步推理链提供了极致的性能。
- 彻底解决冷启动： 在一个会话的生命周期内（当前最长 8 小时），只有第一次调用可能经历冷启动。后续的所有交互都在同一个“热”的 MicroVM 中执行，响应时间稳定在毫秒级。
- 强大的安全隔离： 每个会话运行在独立的 MicroVM 中，提供了内核级别的强隔离。这对于处理敏感数据、执行不可信代码（如代码解释器）的多租户 AI 服务至关重要，有效防止了会话间的数据泄露。
这种架构可以被称为 “会话式” Serverless，它既保留了 Serverless 的免运维、按需扩展的优势，又提供了传统长连接服务才有的状态保持和高性能，在此基础上同时兼顾了安全性。
5、新前沿：Serverless 架构有状态环境中生命周期管理、升级与成本挑战
引入状态后，平台的管理模型也变得更加复杂。
- 生命周期管理： 计算实例的生命周期不再是单个请求，而是整个会话。例如，Runtime 的会话有明确的生命周期状态：Active（活动）、Idle（空闲）、Expired（过期）、Deleted（删除）。平台需要提供 API 允许开发者主动管理（如提前终止）这些长生命周期的会话，便于业务集成，将会话管理的权利交给用户，提升用户使用的灵活性。
- 优雅升级与灰度发布： 当更新一个正在处理有状态会话的函数时，不能简单地用新版本替换所有实例。平台需要支持优雅升级：新的会话请求被路由到新版本的实例，而持有旧会话的实例则继续服务，直到其关联的会话自然结束，从而实现平滑过渡。
- 成本管理与闲置预留： 对于需要消除冷启动的场景，预置并发（Provisioned Concurrency）仍然是关键工具。其定价模型通常分为两部分：为保持实例温热而支付的较低的预置费用，以及在实例实际执行代码时支付的较高的计算费用。平台通过动态负载探测等技术，力求在实例空闲但需保持状态时，以更低的成本计费，实现更精细的按价值付费。
架构对比分析与选型建议
为了帮助架构师和技术决策者在不同的业务场景下做出最佳的选择，本节将对前文讨论的几种主流解决有状态 Serverless 架构模式进行系统性的对比分析。每种模式都代表了 Serverless 演进过程中的一个重要阶段，它们在性能、成本、复杂性和可扩展性等方面存在显著的权衡。下表从多个关键维度对几种架构模式进行了总结和比较，旨在提供一个清晰的决策框架。
分析与建议：
- 阶段一：业务状态外置。 仍然是许多简单场景的理想选择。如果应用的状态更新不频繁，且能够容忍几十到上百毫秒的额外延迟，这种模式因其简单性和对 Serverless 核心优势的保留而具有吸引力。
- 阶段二：传统会话亲和。 应被视为一种过渡性的手段。它在本质上是对 Serverless 模型的妥协，牺牲了可扩展性和容错性来换取性能。对于无法重构以适应无状态模式的遗留应用，它可能是一个临时的解决方案，不应作为新项目的首选架构。对于传统 Web 场景，配额内存水位弹性是一个很好的选择。
- 阶段三：内置状态抽象。 为需要可靠状态管理和复杂工作流编排的场景提供了强大的解决方案。它特别适用于事件驱动的系统，如订单处理、物联网数据聚合等，其开发模型极大地简化了原本复杂的分布式状态问题。当然这种状态抽象也可以通过工作流的方式实现同样的能力。
- 阶段四：持久化运行时。 以阿里云函数计算的 AgentRun 和 AWS Bedrock 的 AgentCore Runtime 为代表的架构，代表了当前服务于 AI 代理的顶尖 Serverless 方案。当应用场景涉及长时运行、多轮交互、需要极致性能和强安全隔离的 AI 代理时，这种模式是无可争议的最佳选择。它为开发者提供了最简单的心智模型和最高的性能保证，但其成本模型也与传统的按请求付费模式有显著不同，需要根据会话的活跃度和时长进行评估。
最终的架构选择取决于业务需求的具体权衡。决策者应仔细评估应用对延迟、成本、开发复杂度和可靠性的敏感度，从而选择最符合其长期目标的演进路径。