AaaS 与云服务对比

本文说明 AaaS 与 FaaS、Worker、容器任务和传统平台服务的关系。规范中的运行环境抽象见 System Model 与 Provider Lifecycle。

先说结论

AaaS 不是为了替代现有云服务，而是为了把这些云服务组织成“适合 Agent 的统一运行层”。它关注的是 Agent 的执行语义，而不是单一计算形态。

最关键的区别在于：FaaS、容器任务、Worker、Wasm 主要回答“代码在哪儿跑”，AaaS 还要回答“Agent 如何被定义、如何继续执行、如何恢复、如何调用工具、如何审计、如何追踪、如何被运营”。

与 FaaS、Worker、容器任务的差异

维度	FaaS	Worker / Queue Consumer	容器 Job / Sandbox	AaaS
基本对象	函数调用	异步任务消费者	进程或容器实例	Agent、Run、Session、Tool、Checkpoint、Trace
生命周期	短、单次调用	任务驱动	会话或批处理	同时支持短时调用与长时会话
状态管理	主要外置	主要外置	本地状态可保留	事件、Artifact、Checkpoint、KV 统一治理
交互方式	请求响应	队列触发	shell / socket / browser / file	输入事件、输出事件、继续对话、人工介入
工具调用	代码内部自管	代码内部自管	通常自管	Tool 是平台级对象，可审计、可限流、可映射
可观测性	调用级	任务级	进程级	Run、Attempt、Span、GenAI、Artifact 统一关联
适合场景	短小无状态动作	异步后台消费	编码、浏览器、长时任务	全生命周期 Agent 服务化

与传统 PaaS 的差异

传统 PaaS 擅长托管稳定的 Web 服务或 API 服务，但 Agent 运行通常有下面几个额外要求：

• 一次用户请求可能映射为多段异步执行，而不是一个固定 HTTP 生命周期
• 需要细粒度地表达模型调用、工具调用、文件产物和中间状态
• 需要支持从同一任务继续对话、恢复旧运行空间或接续某个 Checkpoint
• 需要把模型和工具行为纳入审计和治理，而不仅仅是代码进程

所以 AaaS 与 PaaS 的关系更像“Agent 控制面 + Agent 运行平面”叠加在现有计算平台之上，而不是替代现有托管形态。

为什么 AaaS 会和 FaaS 形成互补

FaaS 在 Agent 体系里非常有价值，但更适合承担下面这些角色：

• 短时、无状态、可高并发扩缩的工具函数
• Webhook 处理、文本解析、策略校验、向量检索前后处理
• 不需要持久交互环境的补充步骤

当任务进入这些阶段时，AaaS 可以把 FaaS 作为 Provider 或 Tool 来使用；当任务需要长时会话、文件系统、浏览器、编码环境时，AaaS 再切换到 Sandbox 或其他更适合的执行环境。

为什么 AaaS 不应只建立在 FaaS 上

如果完全用 FaaS 承担 Agent 运行主环境，通常会遇到几类问题：

• 交互式 Shell、Git、浏览器和文件工作区难以持续保留
• 会话恢复与中间状态回放会变得复杂
• 工具链安装、缓存和依赖预热缺少稳定落点
• 进程级心跳和会话级监控很难表达

因此，AaaS 更合理的做法是把 FaaS 作为执行谱系中的一种，而不是唯一形态。

AaaS 与 Worker 的关系

Worker 更适合做队列消费、长链路异步编排、批量 fan-out 和后台收尾。它在 AaaS 里经常承担：

• Orchestrator 的后台推进器
• Tool 调用后的异步处理器
• 大批量并行任务的消费器
• 延迟重试、补偿和死信恢复执行器

但 Worker 本身不天然提供 Agent 级会话模型、Checkpoint 语义和工具治理，因此它更适合作为平台实现手段，而不是最终产品抽象。

AaaS 与 Wasm 的关系

Wasm 适合低延迟、强隔离、快速启动、可边缘部署的执行单元。它很适合作为：

• Prompt/Policy 预处理器
• 轻量工具执行器
• Edge 侧输入清洗、格式转换和安全策略检查
• 对资源需求较小的 Agent 子步骤

但它不天然等于“完整 Agent 运行环境”。复杂编码任务、浏览器操作或重依赖工具链通常仍需要 Sandbox 或 Worker 背后的更强执行环境。

AaaS 与云服务的正确关系

更现实的组合方式是：

• Sandbox 负责交互式、状态型、需要文件和进程管理的 Agent
• FaaS 负责短平快工具动作和事件响应
• Worker 负责异步消费、后台推进、批量任务和补偿
• Wasm 负责边缘校验、轻量执行和高密度沙箱

AaaS 则把这些能力统一成一套产品视图：

• 同一份 Agent 定义
• 同一份 Run 生命周期
• 同一份事件与 Trace 事实
• 同一套权限、配额和审计策略

常见云能力如何映射到 AaaS

现有云能力	在 AaaS 中承担的职责	常见搭配
容器任务或 Sandbox 服务	提供会话型运行空间、文件系统和进程管理	coding agent、浏览器 agent、需要 checkpoint 的任务
FaaS 平台	提供短时工具执行、事件响应和同步补充步骤	OCR、Webhook、预处理、后处理
Queue / Worker 平台	提供后台推进、重试、补偿和批量 fan-out	多阶段异步任务、后台编排、聚合处理
对象存储	承载 Artifact、Checkpoint、日志和大结果集	长任务输出、工作区快照、恢复数据
Secret Manager / KMS	承载 Secret、租约和凭证轮换	Session 注入、按 Run 授权、审计追踪
Edge Wasm 或边缘函数	承载入口校验、轻量策略和格式转换	边缘预处理、安全策略、低延迟过滤

因此，“如何和现有云服务结合使用”的关键不是重新发明这些云能力，而是明确它们在 AaaS 里分别扮演 Session Provider、Tool Executor、State Store、Secret Source 和 Async Driver 的角色。

一个简单判断法

如果系统的核心问题是：

• “如何快速跑一段无状态代码”更像 FaaS
• “如何可靠消费任务并重试”更像 Worker
• “如何托管一个长期在线 API 服务”更像传统 PaaS
• “如何让一个 Agent 在不同环境里执行、继续、恢复、调用工具并被治理”就是 AaaS

建议配套阅读

• Agent as a Service 总览
• 运行画像与执行环境
• Provider Lifecycle