当大模型从“对话”走向“行动”，Agent 正在成为软件的新形态。但一个被反复讨论的问题是：Agent 到底应该跑在哪里？容器、虚拟机，还是无服务器？本文尝试从工程约束出发，讨论 Serverless 为何可能成为 Agent 运行时的默认选项，以及这条路仍然存在的代价。

Agent 的运行时困境：它不像 Web 服务，也不像批处理

要讨论 Agent 该跑在哪里，先要理解 Agent 和传统软件在运行时特征上的差异。

一个典型的 Web API 是短生命周期、无状态、请求-响应式的。一个典型的批处理任务是长周期、有状态、可预测的。而 Agent 恰好卡在两者之间，并且同时具备了几种互相矛盾的属性：

第一，生命周期高度不确定。 一次 Agent 调用可能只触发一次工具查询就结束，也可能因为多轮推理、工具调用、结果校验而持续数十秒甚至更久。这种“不可预测的持续时间”让容量规划变得困难。

第二，调用频率高度突发。 Agent 往往由事件驱动——一条消息、一次工单创建、一个定时任务、一次 CI 失败。流量曲线不是平滑的，而是尖刺状的。为峰值预留资源，意味着大量时间在为空闲付费。

第三，单次执行内部是“有状态”的。 Agent 需要维护对话历史、中间推理结果、工具调用上下文。但这些状态又不应该绑定在某一台机器上，否则扩缩容和故障恢复都会变得脆弱。

第四，依赖外部资源密集。 Agent 通常要调用 LLM API、向量数据库、外部工具、内部服务。它的计算本身可能很轻，但 I/O 等待很重。

把这四点放在一起，会发现一个结论：Agent 的瓶颈通常不是持续算力，而是弹性、隔离和按需计费。 而这恰好是 Serverless 被设计出来要解决的问题。

依据现有素材判断，Agent 与 Serverless 的匹配并非偶然，而是运行时特征上的结构性契合。

为什么 Serverless 天然适合 Agent：四个工程理由

1. 事件驱动与 Agent 的触发模型同构

Serverless 的核心抽象是“事件触发函数”。而 Agent 的核心抽象是“感知—决策—行动”。两者在结构上高度相似：一个外部信号进来，触发一段逻辑，逻辑执行完毕后释放资源。

无论是用户消息、Webhook、消息队列、定时器还是文件上传，都可以直接映射为 Serverless 的触发器。这意味着 Agent 的接入层几乎不需要额外的调度框架——平台本身就在做这件事。

2. 按需伸缩匹配 Agent 的突发特征

Agent 的流量往往不可预测。新产品上线、一次营销活动、一次故障告警，都可能瞬间带来数量级的调用增长。

Serverless 的自动伸缩模型让“从 0 到 N”成为默认行为，而不是需要提前配置的能力。对于早期 Agent 产品，这一点尤其重要：你不需要在还不知道用量曲线的时候，就先买好一台常驻服务器。

3. 隔离性降低了 Agent 的风险半径

Agent 会执行代码、调用工具、访问外部系统。这意味着它的攻击面和故障面都比普通 API 更大。

Serverless 的每次调用通常运行在独立沙箱中，天然提供了进程级甚至更细粒度的隔离。即使某次执行被恶意输入影响，影响范围也被限制在单次调用内。对于需要执行不可信代码或多租户场景的 Agent，这是一个被低估的优势。

4. 计费模型与 Agent 的成本结构对齐

Agent 的成本大头往往在 LLM 调用和外部 API，而不是 CPU。Serverless 按实际执行时间计费，让“等待 LLM 返回”这段时间的成本尽可能低（取决于平台是否对 I/O 等待计费，这一点需要具体平台具体分析）。

对于低频、长尾、不可预测的 Agent 任务，这种计费模型比常驻容器更经济。

代价与边界：Serverless Agent 不是没有摩擦

如果只讲优势，这篇文章就失去了媒体应有的判断力。Serverless 跑 Agent，目前仍存在几类明确的摩擦。

冷启动。 这是最常被提及的问题。Agent 本身可能启动就要加载依赖、初始化 SDK、建立连接。如果冷启动叠加在 LLM 首 token 延迟之上，用户体验会明显受损。缓解手段包括预热、精简依赖、把重初始化逻辑外置，但这些都需要额外工程投入。

执行时长上限。 多数 Serverless 平台对单次执行有时间上限。对于需要长时间推理、多轮工具调用、或等待人工审批的 Agent，这个上限可能成为硬约束。一种常见做法是把长任务拆成多个短执行，用外部状态存储串联，但这会显著增加架构复杂度。

状态管理。 Serverless 本身不提供持久状态。Agent 的对话历史、任务进度、中间结果都需要外部存储。这带来了额外的一致性、并发和成本问题。换句话说，Serverless 把“状态”这个难题从运行时推给了架构设计者。

可观测性。 分布式、短生命周期、高频次的执行单元，让日志、追踪、指标收集变得更困难。Agent 的调试本身就因为 LLM 的不确定性而复杂，再叠加 Serverless 的碎片化执行，排障成本会上升。

供应商锁定。 不同 Serverless 平台的触发器、运行时、状态存储、超时策略差异较大。深度绑定某一平台后，迁移成本不低。

这些摩擦并不意味着 Serverless 不适合 Agent，而是说明：它适合的是特定形态的 Agent，而不是全部。

什么样的 Agent 更适合 Serverless

综合上面的分析，可以给出一个粗略的适配判断：

更适合 Serverless 的 Agent：

事件驱动、触发式，而非常驻监听

单次执行时间较短，或可拆分为多个短步骤

状态可外置到数据库、对象存储或队列

流量突发、低频长尾、难以预测

多租户或需要执行不可信代码

更适合常驻容器的 Agent：

需要长时间保持连接或会话

需要本地缓存大量模型或数据

对冷启动极度敏感

需要精细控制运行时环境

依据现有素材判断，现实中更可能的形态是混合架构：接入层和轻量工具调用走 Serverless，重推理和长会话走常驻服务，状态统一外置。这不是非此即彼的选择，而是分层设计的问题。

Agent 会推动 Serverless 的下一轮演进

如果把视角拉长，Agent 的兴起可能反过来推动 Serverless 平台本身的演进。

第一，更长的执行时间和更灵活的资源模型会成为需求。Agent 的多轮推理天然需要更长的运行窗口，平台若不能支持，就会被绕过。

第二，状态原语可能被重新引入。当大量 Agent 都需要外部状态时，平台提供托管的状态抽象会比让每个团队自己造轮子更合理。

第三，面向 AI 工作负载的运行时优化会出现。包括更快的冷启动、对 GPU 或推理加速器的按需挂载、对 LLM 调用的原生集成等。

第四，可观测性会成为差异化能力。谁能把 Agent 的推理链路和 Serverless 的执行链路统一追踪，谁就更容易被采用。

这些判断基于当前技术逻辑的推演，而非已有产品的既成事实。依据现有素材判断，它们更接近方向性判断，而非确定性预测。

结论

Agent 采用 Serverless 架构，本质上不是一次技术潮流，而是一次运行时匹配的结果：Agent 的弹性需求、事件驱动特征、隔离要求和成本结构，与 Serverless 的设计目标高度重合。

但匹配不等于万能。冷启动、执行时长、状态管理和可观测性，仍然是需要正视的工程代价。真正成熟的方案，大概率不是“全部 Serverless”，而是按 Agent 的形态分层选择运行时。

对技术团队而言，值得问的问题不是“Agent 要不要上 Serverless”，而是：我的 Agent 属于哪一类负载？它的瓶颈在弹性、在状态，还是在延迟？ 回答清楚这个问题，架构选择自然就清晰了。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。