智能体的部署形态竞争：serverless、常驻进程与边缘推理

智能体的部署形态竞争：serverless、常驻进程与边缘推理

讨论智能体架构时，注意力通常集中在模型与框架上，部署形态却常被当成无关紧要的细节。实践很快会纠正这个偏见：智能体的运行特征与传统 Web 服务截然不同——单次任务以分钟计、会话状态跨越数十轮、需要执行不可信的生成代码、对首 token 延迟敏感——这些特征让"一个无状态 HTTP 服务"的教科书答案失效。过去两年，围绕智能体的部署形态事实上形成了四个竞争方向：请求驱动的 serverless、长任务友好的常驻进程、代码执行的隔离沙箱、以及延迟与隐私驱动的边缘推理。它们不是互相替代，而是各自圈定了最适合的任务谱系。

这篇文章逐一拆解四种形态的工程权衡与适用边界，最后给出一套形态选择的决策框架。

Serverless：请求驱动的短生命周期

无服务器形态把智能体包装成按请求拉起的函数：请求进来，容器或函数实例启动，执行若干轮 LLM 调用，返回结果，实例回收。它的优势是教科书级的：按用量付费、弹性伸缩、零容量规划，团队不需要维护任何服务器。对流量稀疏或波动剧烈的产品（夜间几乎无请求、白天高峰百倍突增），这个形态的成本结构极其友好。

它的边界同样清晰。第一是执行时限：主流 serverless 平台的单次执行上限从几十秒到十五分钟不等，而智能体任务恰恰以时长不可控著称——一个编码任务跑二十分钟完全正常，超出时限的任务要么被迫拆分，要么转入异步编排（任务入队、后台执行、结果回调或轮询），而一旦引入编排，"serverless 的简单"就打了折扣。第二是冷启动：容器实例的拉起加上 SDK 初始化，通常带来一到数秒的额外延迟，对交互式场景是可感知的劣化。第三也是最容易被忽视的一点：状态与缓存的流失。无状态实例每次都从冷数据开始，多实例横向扩容会把会话的缓存命中打散——上一轮刚预热的前缀缓存在这一轮被路由到另一个实例，提示缓存的命中率显著下降，成本随之上升。对重缓存依赖的智能体，这个隐性代价可能超过 serverless 本身的成本优势。

常驻进程：长任务与会话亲和

常驻进程形态让 worker 进程长期运行，从消息队列（BullMQ、Celery、Temporal 这类编排器）领取任务，通过 SSE 或 WebSocket 与客户端保持长连接流式输出。它换来了 serverless 缺失的三样东西。一是无时限：任务想跑多久跑多久，配合队列天然获得异步执行、重试与优先级调度。二是进程内状态：会话上下文可以驻留内存，连接与 HTTP 客户端的连接池复用，本地缓存（嵌入、工具结果）跨任务持续生效。三是缓存亲和：同一会话的请求通过一致性哈希路由到同一实例，提示缓存的前缀在该实例上保持温热，命中率显著高于打散的场景。

代价是运维复杂度的回归：容量要规划（长任务占住 worker，队列堆积需要自动扩缩），发布要处理（滚动重启时运行中的任务要排空或迁移），故障要兜底（进程崩溃后的任务恢复与幂等设计）。工程上的成熟做法是"队列加常驻 worker 加会话亲和"的组合：API 网关层无状态、轻请求直接处理，重任务投递到按会话哈希分组的 worker 池，配合心跳与任务租约机制处理 worker 失联。对任务时长以分钟计、对流式输出与缓存命中率敏感的智能体产品，这几乎是 2026 年的默认答案。

沙箱执行：生成代码的隔离运行时

只要智能体会生成并执行代码（数据分析、自动化脚本、文档处理），就需要一个隔离执行环境——不能让模型生成的代码直接跑在生产主机上。沙箱形态的技术谱系从轻到重：容器隔离（Docker 加资源限额）起步成本低但隔离强度有限；gVisor 这类用户态内核拦截系统调用，安全性上一个台阶；Firecracker microVM 是当前公共云的标杆方案，AWS Lambda 的底层技术，虚拟机级隔离的启动时间在百毫秒量级。生态里的专用服务（E2B、Modal、Daytona 等）把沙箱做成 API：请求一个沙箱实例、执行代码、取回结果、销毁回收，团队不再自建这套基础设施。

沙箱的工程要点有三个。生命周期管理：沙箱实例不是免费的，空闲实例要定时回收，频繁创建又要承受启动延迟，成熟方案用"池化加快照恢复"把热启动压到百毫秒级。文件与依赖：数据分析和文档任务需要预装依赖的基础镜像（pandas、openpyxl 之类）与持久卷（跨多轮执行保留中间文件），镜像按场景预制比现场安装快一个数量级。超时与资源限额：无限循环的生成代码是常态而非例外，CPU、内存、执行时长、网络出口都要设硬限制。Anthropic 与 OpenAI 先后把代码执行做成平台能力（托管的 bash 工具与文件 API），印证了沙箱已经从可选组件变成智能体基础设施的标配层。

flowchart TB
    C["客户端"] --> GW["无状态 API 网关"]
    GW -->|"轻请求"| SL["Serverless 函数<br/>单轮补全 / 短任务"]
    GW -->|"重任务"| Q["任务队列"]
    Q --> W1["常驻 worker A<br/>会话亲和 + 本地缓存"]
    Q --> W2["常驻 worker B"]
    W1 & W2 --> SB["沙箱池<br/>microVM 执行生成代码"]
    GW --> EDGE["边缘小模型<br/>补全 / 隐私任务"]
    W1 & W2 --> LLM["云端大模型 API"]
    EDGE -.->|"复杂请求升级"| LLM

边缘推理：延迟与隐私的第二战场

边缘推理让小参数量模型（3B 到 8B，经量化后）直接运行在终端设备或边缘节点上，它圈定的是两类场景。第一是延迟敏感：输入补全、语音转写、快捷指令这类需要亚秒级响应的任务，省掉一次网络往返（公网 RTT 加排队动辄几百毫秒）就是数量级的体感差异，现代手机 NPU 上量化后的 8B 模型可以跑到每秒二三十 token，足以支撑补全类体验。第二是隐私敏感：输入内容不能出设备的场景（医疗记录、企业敏感文档、输入法数据），边缘处理是合规前提，云端只接收脱敏后的结果。

边缘的现实约束是能力天花板：小模型在复杂推理、长上下文、工具调用的可靠性上与旗舰模型差距明显，所以生产形态几乎都是分层混合——边缘小模型处理高频轻任务并做隐私过滤，复杂请求无缝升级到云端大模型，路由决策在端侧完成（按任务类型、置信度与网络状况）。这个分层正在成为端侧 AI 产品的标准架构，也是"智能体部署"与"模型推理"两个战场交汇的地方。

形态选择：四个维度的决策框架

四种形态的选型可以收敛为四个问题。任务时长：秒级到一分钟的短任务 serverless 足够，分钟级以上的长任务需要常驻进程加队列。状态需求：会话跨轮次持久、依赖进程内缓存与缓存亲和的，常驻形态显著占优。执行内容：跑生成代码就必须引入沙箱层，其余形态决定的是宿主选择。延迟与隐私：亚秒级响应或数据不出端，把边缘小模型拉进架构。多数成熟产品最终的形态是组合而非单选：无状态网关加常驻任务集群加沙箱池，辅以边缘分层——部署形态的竞争已经从"选哪种"演进为"怎么组合"。

编排层：长任务的持久化执行

常驻进程形态的深水区不是进程管理，而是任务可靠性：一个跑二十分钟的编码任务，在第十分钟 worker 进程崩溃了怎么办？裸队列方案要自己实现断点恢复，生产级的答案是把任务放进持久化执行引擎——Temporal、AWS Step Functions 或同类框架。它们的核心能力是把每一步的执行状态落库，进程崩溃后从最后一步恢复继续执行，而不是从头重跑。智能体的多步长任务与这个模型天然契合：每一轮循环是一个可持久化的活动节点，审批门的等待是原生的信号等待，超时与重试策略按步骤配置。这层抽象的代价是引入编排框架的学习成本与基础设施依赖，收益是长任务可靠性从自研工程变成平台承诺。

持久化执行带来两个配套的工程纪律。其一是幂等设计：智能体任务的每一步都可能被重试，LLM 调用天然幂等（重跑只是再花一次钱），外部副作用调用必须带去重键——创建工单、发送消息这类操作重试时不能产生双重效果，这是长任务系统最经典的事故来源。其二是人机中断的持久化：审批门意味着任务可能暂停数小时等用户确认，持久化引擎把这个"暂停—恢复"做成一等原生语义，自建方案最常见的生产事故恰恰是会话超时后审批状态丢失，任务永久卡死。

成本账也要算得完整。同等工作负载下，serverless 按量计费对波动流量友好但对常态流量偏贵，预留容量与计算节省计划可以缓解；常驻进程的固定成本对稳态流量友好，但对长尾流量是浪费；沙箱是纯粹的增量成本，按执行时长计价，生命周期策略（空闲回收、快照复用）直接决定账单；边缘推理几乎没有边际基础设施成本，但受设备能力与模型上限约束。正确的口径是月度总拥有成本——基础设施加运维人力加故障损失，而不是单看云账单。可移植性同样进决策：平台托管能力（模型厂商的托管会话状态、文件存储、代码执行）显著降低自建成本但加深绑定，自建状态层前期投入高但保持迁移自由。经验法则：核心会话状态自建（它决定迁移成本），边缘能力用托管（它们出问题时替换成本可控）——绑定越深的功能，往往是越晚才暴露问题的功能。

小结

智能体部署形态的四个方向各有明确的生态位：serverless 用极简运维覆盖短任务与突发流量，代价是时限、冷启动与缓存打散；常驻进程以运维复杂度换来无时限执行、流式长连与缓存亲和，是分钟级长任务的默认答案；沙箱执行让不可信的生成代码有了隔离运行时，microVM 与专用服务把启动压到百毫秒级，已成标配层；边缘推理用小模型圈住延迟与隐私敏感场景，以分层混合接入整体架构。选型的四个维度——任务时长、状态需求、执行内容、延迟与隐私——决定了组合方式。部署形态不是架构的最后一环，而是成本、延迟与安全三本账的共同入口。