Agent、微服务、Serverless：三种执行模型的本质区别

Agent 的执行语义和生命周期完全不同于微服务和 Serverless，理解三者的本质区别，是构建 AI 原生系统的关键第一步。

开发者常将 Agent 类比为更聪明的微服务、带推理能力的函数或长会话版 Serverless。虽然这些比喻看似合理，实则存在根本性的错位。Agent 的执行语义与生命周期，与传统应用模型并非同一维度。本文将从五个核心视角，系统梳理三者的本质边界。

生命周期的差异

生命周期是理解三种模型的基础。下文分别介绍微服务（Microservice）、Serverless 和 Agent 的生命周期特点，并在每节前补充说明。

微服务（Microservice）——长驻型

• 启动后常驻进程
• 保持稳定网络接口
• 生命周期以“服务”为中心
• 支持热升级、滚动更新

Serverless——短命型

• 每次调用启动一次执行环境
• 函数执行完即销毁
• 生命周期以“请求”为中心
• 冷启动、自动弹缩

Agent——任务与会话驱动型

Agent 的生命周期完全不同：

• 推理循环（Plan → Act → Reflect → Evaluate）
• 任务状态推进（Task State Progression，任务状态推进）
• 会话级上下文（Session State，会话状态）
• 可暂停、恢复、重新规划
• 执行过程以“任务/目标”为中心

总结来看：

微服务长驻，Serverless 瞬时，Agent 连续演化。

状态管理的本质区别

状态管理是三者最容易混淆的点。下文分别介绍微服务、Serverless 和 Agent 的状态模型。

微服务：外部状态优先

• 无状态优先
• 需要状态时依赖外部存储（DB、Cache、消息系统）

Serverless：严格无状态

• 不保证本地状态可用
• 每次执行都是干净环境
• 强制使用外部系统保存状态

Agent：内生状态

Agent 必须拥有结构化状态：

• Session State（长期记忆，Session State）
• Task State（每个 Query 的执行状态，Task State）
• Working Memory（工作记忆，Working Memory）
• Intermediate Reasoning State（推理中间态，Intermediate Reasoning State）
• Tool Trace / Plan Trace（工具调用与计划轨迹，Tool Trace / Plan Trace）

这些状态是推理循环和执行图的必要组成部分。状态不是外部数据，而是 Agent 行为的一部分。

因此：

Agent = stateful by design
微服务 = external state
Serverless = stateless

并发模型的差异

并发模型决定了系统的扩展能力和协作方式。下文分别介绍三者的并发特点。

微服务：请求级并发

• 多个请求并行
• 共享线程池与资源池
• 不关心任务的内部结构

Serverless：请求隔离并发

• 每次调用一套隔离执行环境
• 并发数量由平台扩缩

Agent：图级并发

Agent 并发发生在“执行图”层：

• 多 Agent 协作（Planner / Worker / Evaluator）
• 工具链并发（多个工具并行）
• 子任务并发（Task Graph，任务图）
• 模型调用、推理循环的局部并发

这意味着：

Agent 的并发不是 request-level，而是 graph-level。

传统 Web 并发模型无法完整描述这一行为。

执行模型的根本不同

执行模型决定了系统的驱动方式和控制流。下文分别介绍三者的执行语义。

微服务：同步请求 - 响应

• REST/gRPC
• 同步、确定性、可重复

Serverless：事件驱动执行

• event → cold start → function
• 完全由外部事件触发

Agent：推理驱动执行

Agent 的执行由推理循环驱动：

Plan → Act → Observe → Reflect → Evaluate → Next Action

它不是事件驱动（像 Serverless），也不是请求驱动（像微服务），更不是定义明确的业务流程（如 BPM/workflow）。Agent 的执行本质是一种“推理控制流”（Reasoning-Controlled Execution，推理控制流），这是传统计算模型中未曾出现的运行时语义。

工作负载抽象的区别

工作负载抽象决定了系统的调度和资源管理方式。下文分别介绍三者的 workload 模型。

微服务 / 容器：Workload

• 要被调度
• 有资源规格（CPU/Mem）
• 有生命周期
• 有副本数
• 有监控指标

Serverless：函数

• 无生命周期
• 无内部状态
• 无资源策略
• 只根据事件执行

Agent：Workload，但具备推理循环

Agent 不是函数，也不是框架里的一个对象，而是由运行时调度的有状态 Workload。与微服务不同，Agent 是推理与决策执行，微服务是业务逻辑执行。微服务是 API 接口，Agent 是行为系统。

更准确的表达是：

Agent = workload × reasoning × tools × state
微服务 = workload
函数 = stateless invocation

为什么 Agent 不是微服务也不是函数

综合以上差异，结论非常明确。下文分别阐述 Agent 与微服务、Serverless 的本质区别。

Agent ≠ 微服务

微服务缺乏以下能力：

• 推理循环
• Task Graph（任务图）
• 内生状态
• 工具治理
• 模型调用语义
• Query 生命周期

微服务是业务系统，Agent 是智能系统。

Agent ≠ Serverless 函数

Serverless 函数缺乏以下能力：

• 严格无状态
• 生命周期以事件为边界
• 不可持续执行
• 无法承载推理循环
• 无法表达多 Agent 协作

Serverless 解决“调用一次就结束”的问题，Agent 解决“目标导向执行”的问题。

Agent 的执行语义独立于传统应用模型

Agent 需要：

• reasoning（推理）
• state（状态）
• execution graph（执行图）
• workload scheduling（工作负载调度）
• sandboxed tools（沙箱工具）
• cost governance（成本治理）
• trace & audit（追踪与审计）

这些能力传统运行时尚未具备。因此：

Agent 必须拥有自己的运行时语义，而不能继续绑在微服务或 Serverless 上理解。

总结

三者的本质区别可以压缩为一张表：