主题
Agent as a Service 总览
本文是说明性白皮书内容。规范性定义请参考 System Model、Terminology 和 Agent。
什么是 Agent as a Service
Agent as a Service，简称 AaaS，是把 Agent 从“嵌在某个应用里的逻辑”提升为“可发布、可调度、可治理、可观测的云服务对象”。
它不是单纯的模型调用代理，也不是把 prompt 包一层 API。一个完整的 AaaS 平台通常同时提供下面几层能力：
Agent作为一等资源：有身份、配置、版本、权限、灰度和展示卡片Run作为一等运行单元：每次执行有输入、状态、Attempt、输出流、终态和恢复语义Runtime Session作为一等连接：允许长连接、保活、断线恢复、KV、Config、Secrets 和工具桥接Tool作为一等能力：平台能管理工具目录、工具作用域、工具审计和工具调用结果Checkpoint、Artifact、Trace作为一等可治理对象：便于恢复、审计、调试、性能分析和多阶段执行
从产品层看，AaaS 的核心目标是把“Agent 能力开发”与“Agent 运行治理”解耦。团队可以继续使用最熟悉的模型、Framework 和工具，但运行、隔离、监控、策略、审计、配额和多租户治理由统一平台承接。
为什么需要这一层
当 Agent 从单轮问答走向真实业务执行时，系统会立刻遇到传统 API 服务和传统工作流平台难以完整覆盖的问题：
- Agent 不是一次纯函数调用，而是可能持续数分钟到数小时的会话型执行
- Agent 不只返回文本，还会调用工具、写文件、生成工件、保存检查点、继续对话
- Agent 的运行环境差异极大：交互式 Sandbox、短时 FaaS、异步 Worker、边缘 Wasm 都可能同时存在
- Agent 的问题排查不是只看一条请求日志，而是要看 Prompt、模型调用、工具调用、文件变更、网络访问和中间状态
- Agent 的风险治理不只是鉴权，还包括沙箱隔离、Secret 注入、内容捕获策略、审计保留和策略门控
如果没有统一的平台层，团队通常会在每个 Agent 项目里重复实现这些能力，结果是：
- 每个 Agent 都有不同的状态机、日志格式和恢复方式
- 不同框架和工具无法稳定接到同一个控制面
- 监控与审计分散在多套私有 SDK 和脚本里
- 迁移运行环境时需要重写大量业务逻辑
AaaS 的价值就在于把这些重复且高风险的基础设施沉淀为平台能力。
AaaS 带来的产品价值
对平台团队
- 用统一的资源模型管理 Agent、Tool、Run 和执行画像
- 用统一的运行协议接入不同语言 runtime 和不同执行环境
- 用统一的事件与 Trace 平面做审计、计费、告警、SLO 和容量治理
对业务团队
- 保留现有 Agent 框架、工具调用方式和业务逻辑，不必强制重写成平台私有 DSL
- 让 Agent 的版本、灰度、回滚、重试、恢复和观测方式标准化
- 更容易把一个实验型 Agent 推向生产环境
对企业治理
- 更容易做多租户隔离、组织边界、权限控制和密钥管理
- 更容易实现运行审计、数据保留策略和安全基线
- 更容易把模型供应商切换、执行环境切换和工具集变化控制在平台层
如果你正在接现有生态
AaaS 的重点不是替换你现在已经在用的框架、工具和云服务，而是把它们收敛到统一治理平面。下面四篇专题分别回答最常见的落地问题：
- 云服务与 AI Framework 对接： 讨论如何接入现有云服务、LangGraph、OpenHands 一类 framework 或 runtime。
- AI 工具兼容： 讨论 Claude Code、Codex、OpenCode 一类工具如何被托管、治理和观测。
- AaaS 与云服务对比 与 运行画像与执行环境： 讨论 Sandbox、FaaS、Worker、Wasm 应如何分工，以及它们如何和现有云能力组合。
- 运行保障与可观测性： 讨论 Sandbox 场景下的 CI/CD、环境准备、Agent 安装、进程监控，以及 FaaS、Worker、Wasm 的等价监控模型。
整个体系长什么样
一个可落地的 AaaS 平台，通常由下面几层组成：
Control Plane- 管理组织、Agent、Tool、Execution Profile、Webhook、配额和策略
Orchestrator- 负责 Run 生命周期、Attempt 管理、重试、超时、取消、恢复和 Provider 选择
Runtime Session Gateway- 连接运行中的 Agent 进程，提供输入分发、输出回传、Heartbeat、Secrets、KV 和配置能力
Provider Layer- 抽象 Sandbox、FaaS、Worker、Wasm 或自定义环境，统一 prepare、start、keepAlive、release 语义
Event Log + Projection- 持久化运行事实，投影出消息、Artifact、Checkpoint、Webhook 和读模型
Telemetry / Trace Plane- 接收 Span、GenAI 详情、运行指标和日志关联信息，形成诊断与审计事实
这意味着 AaaS 平台并不要求所有 Agent 都跑在同一种基础设施上。它更像是一个“统一控制面 + 统一运行协议 + 统一观测面”的协调层。
典型执行闭环
一个典型的执行闭环如下：
- 用户或上游系统选择某个
Agent并提交输入 - 控制面创建
Run，编排器根据executionProfile选择 Provider - Provider 准备运行空间，例如 Sandbox 会话、FaaS 实例或 Worker 任务槽位
- Runtime attach 到平台，建立 Session，领取输入并开始执行
- Runtime 按统一事件模型回传文本、工具调用、状态更新、Artifact 和 Checkpoint
- 平台把事件持久化并投影成 UI 可读的消息流和工件视图
- Runtime 导出 Trace、Span 和 GenAI 详情，用于调试、审计和性能分析
- 运行结束后平台释放运行空间，或按画像保留 Session 供继续交互
典型应用场景
软件研发与代码代理
- 代码生成、补丁提交、测试运行、依赖升级、仓库巡检
- 需要 PTY、文件系统、Git、浏览器和长时会话的交互式运行环境
企业流程自动化
- 工单处理、审批前检查、报表生成、知识库检索、跨系统回填
- 需要强审计、可恢复、可回放和多系统工具编排
数据与运维操作
- SQL 生成与执行、批处理分析、日志排查、云资源巡检、故障处置建议
- 需要工具受控、权限边界清晰、输出带审计
研究与多阶段任务
- 市场研究、合规比对、长链路资料整理、多轮计划执行
- 需要 Checkpoint、Artifact、长时间运行和人工介入能力
非目标
AaaS 不等于下面这些东西：
- 不是模型 API 的简单代理层
- 不是所有工作流系统的替代品
- 不是底层容器、虚机、对象存储、消息队列的替代品
- 不是单一 Agent Framework 的包装品牌
更准确地说，AaaS 是把这些基础设施和 Agent 运行语义组织成统一的平台产品。
与规范的关系
白皮书强调产品形态，规范强调可实现且可验证的契约。推荐配套阅读：