Agent as a Service 总览

本文是说明性白皮书内容。规范性定义请参考 System Model、Terminology、Agent 和 Interaction Request。

什么是 Agent as a Service

Agent as a Service，简称 AaaS，是把 Agent 从“嵌在某个应用里的逻辑”提升为“可发布、可调度、可治理、可观测的云服务对象”。

它不是单纯的模型调用代理，也不是把 prompt 包一层 API。一个完整的 AaaS 平台通常同时提供下面几层能力：

• Agent、Tool 与 McpServer 作为稳定身份资源：有目录身份、权限、展示卡片和治理入口
• AgentRevision、ToolRevision、McpServerRevision、CallableGrant 与 ReleaseChannel 作为一等发布与共享对象：把“资源是谁”“当前跑哪个版本”以及“谁可跨组织调用”拆开
• Protocol Profile 与 Protocol Binding 作为一等协议面：前者在 AgentRevision / McpServerRevision 上声明能力，后者声明实际 endpoint、transport 和安全要求
• Run 作为一等运行单元：每次执行有输入、状态、Attempt、输出流、终态和恢复语义
• InteractionRequest 作为一等交互阻塞对象：审批、补充输入、鉴权和确认都有统一模型
• RunSpace、Session 与 Runtime Connection 作为一等执行上下文：分别表达“代码实际跑在哪”“谁在合法占用这个空间”以及“runtime 正通过哪条连接与平台通信”
• Tool 作为一等能力：平台能管理工具目录、工具作用域、工具审计和工具调用结果
• callableRefs[] 与 CallableGrant 作为一等依赖与共享边界：平台能统一 Agent 到 Agent、Tool、MCP Server 的调用、授权和观测
• Checkpoint、Artifact、Trace 作为一等可治理对象：便于恢复、审计、调试、性能分析和多阶段执行

从产品层看，AaaS 的核心目标是把“Agent 能力开发”与“Agent 运行治理”解耦。团队可以继续使用最熟悉的模型、Framework 和工具，但运行、隔离、监控、策略、审计、配额和多租户治理由统一平台承接。

为什么需要这一层

当 Agent 从单轮问答走向真实业务执行时，系统会立刻遇到传统 API 服务和传统工作流平台难以完整覆盖的问题：

• Agent 不是一次纯函数调用，而是可能持续数分钟到数小时的会话型执行
• Agent 不只返回文本，还会调用工具、写文件、生成工件、保存检查点、继续对话
• Agent 的运行环境差异极大：交互式 Sandbox、短时 FaaS、异步 Worker、边缘 Wasm 都可能同时存在
• Agent 的问题排查不是只看一条请求日志，而是要看 Prompt、模型调用、工具调用、文件变更、网络访问和中间状态
• Agent 的风险治理不只是鉴权，还包括沙箱隔离、Secret 注入、内容捕获策略、审计保留和策略门控

如果没有统一的平台层，团队通常会在每个 Agent 项目里重复实现这些能力，结果是：

• 每个 Agent 都有不同的状态机、日志格式和恢复方式
• 不同框架和工具无法稳定接到同一个控制面
• 现有 A2A、ACP、AG-UI、MCP 生态无法稳定对齐到同一个平台真源
• 监控与审计分散在多套私有 SDK 和脚本里
• 迁移运行环境时缺少统一的 core / platform SDK 边界，常常需要重写大量业务逻辑

AaaS 的价值就在于把这些重复且高风险的基础设施沉淀为平台能力。

AaaS 带来的产品价值

对平台团队

• 用统一的资源模型管理 Agent、Tool、McpServer、CallableGrant、Revision、ReleaseChannel、Run 和执行画像
• 用统一的运行协议接入不同语言 runtime 和不同执行环境
• 用统一的事件与 Trace 平面做审计、计费、告警、SLO 和容量治理

对业务团队

• 保留现有 Agent 框架、工具调用方式和业务逻辑，不必强制重写成平台私有 DSL
• 让 Agent 的版本、发布通道、回滚、重试、恢复和观测方式标准化
• 更容易把一个实验型 Agent 推向生产环境
• 可以先在 worker / faas 上启动，再随着本地工具、文件系统或浏览器能力演进升级到 sandbox

对企业治理

• 更容易做多租户隔离、组织边界、权限控制和密钥管理
• 更容易实现运行审计、数据保留策略和安全基线
• 更容易把模型供应商切换、执行环境切换和工具集变化控制在平台层

如果你正在接现有生态

AaaS 的重点不是替换你现在已经在用的框架、工具和云服务，而是把它们收敛到统一治理平面。下面四篇专题分别回答最常见的落地问题：

• 云服务与 AI Framework 对接： 讨论如何接入现有云服务、LangGraph、OpenHands 一类 framework 或 runtime。
• AI 工具兼容： 讨论 Claude Code、Codex、OpenCode 一类工具如何被托管、治理和观测。
• 协议互操作性： 讨论为什么平台需要原生对齐 A2A、ACP、AG-UI、MCP，以及如何避免协议和平台模型双重失控。
• AaaS 与云服务对比 与 运行画像与执行环境： 讨论 Sandbox、FaaS、Worker、Wasm 应如何分工，以及它们如何和现有云能力组合。
• 运行保障与可观测性： 讨论 Sandbox 场景下的 CI/CD、环境准备、Agent 安装、进程监控，以及 FaaS、Worker、Wasm 的等价监控模型。

整个体系长什么样

一个可落地的 AaaS 平台，通常由下面几层组成：

• Control Plane
• 管理组织、Agent、Tool、McpServer、CallableGrant、Revision、ReleaseChannel、ProtocolBinding、Webhook、配额和策略
• Protocol Gateway
  • 暴露 A2A、ACP、AG-UI 等北向协议面，负责发现、能力协商、恢复与字段转译
• Orchestrator
  • 负责 Run 生命周期、Attempt 管理、重试、超时、取消、恢复和 Provider 选择
• Runtime Connection Gateway
  • 连接运行中的 Agent 进程，提供输入分发、输出回传、Heartbeat、Secrets、KV、配置与 capability 协商
• Provider Layer
  • 抽象 Sandbox、FaaS、Worker、Wasm 或自定义环境，统一 prepare、start、keepAlive、release 语义
• Event Log + Projection
  • 持久化运行事实，投影出消息、Artifact、Checkpoint、Webhook 和读模型
• Telemetry / Trace Plane
  • 接收 Span、GenAI 详情、运行指标和日志关联信息，形成诊断与审计事实

这意味着 AaaS 平台并不要求所有 Agent 都跑在同一种基础设施上。它更像是一个“统一控制面 + 统一运行协议 + 统一观测面”的协调层。

典型执行闭环

一个典型的执行闭环如下：

1. 用户、上游系统或某个外部协议客户端选择 Agent 并提交输入
2. 控制面解析 ReleaseChannel 到确定 revision，创建 Run，编排器根据冻结的 executionProfileSnapshot 选择 Provider
3. Provider 准备 RunSpace 并创建对应 Session，例如 Sandbox workspace、FaaS 调用空间或 Worker 任务槽位
4. Runtime attach 到平台，建立 Runtime Connection，绑定当前 Session，协商 core / platform capability，领取输入并开始执行
5. Runtime 按统一事件模型回传文本、工具调用、状态更新、Artifact 和 Checkpoint
6. 如执行需要审批、补充输入或鉴权，平台创建 InteractionRequest，并由客户端通过统一写路径解决
7. 平台把事件持久化并投影成 UI 可读的消息流、交互视图和工件视图
8. Runtime 导出 Trace、Span 和 GenAI 详情，用于调试、审计和性能分析
9. 运行结束后平台释放运行空间，或按画像保留 Session 供继续交互

典型应用场景

软件研发与代码代理

• 代码生成、补丁提交、测试运行、依赖升级、仓库巡检
• 需要 PTY、文件系统、Git、浏览器和长时会话的交互式运行环境

企业流程自动化

• 工单处理、审批前检查、报表生成、知识库检索、跨系统回填
• 需要强审计、可恢复、可回放和多系统工具编排

数据与运维操作

• SQL 生成与执行、批处理分析、日志排查、云资源巡检、故障处置建议
• 需要工具受控、权限边界清晰、输出带审计

研究与多阶段任务

• 市场研究、合规比对、长链路资料整理、多轮计划执行
• 需要 Checkpoint、Artifact、长时间运行和人工介入能力

非目标

AaaS 不等于下面这些东西：

• 不是模型 API 的简单代理层
• 不是所有工作流系统的替代品
• 不是底层容器、虚机、对象存储、消息队列的替代品
• 不是单一 Agent Framework 的包装品牌

更准确地说，AaaS 是把这些基础设施和 Agent 运行语义组织成统一的平台产品。

为什么协议也要成为平台能力

只把协议支持留在外部 adapter 层，通常会导致平台内部没有统一的互操作约束。更稳妥的做法是：

• 平台统一声明 revision 支持哪些协议面，以及它们通过哪些 binding 对外暴露
• 平台统一定义任务、交互、恢复和工具的 canonical 语义
• 外部协议共享同一套审计、SLA、恢复和治理机制

这正是 AaaS 把 Protocol Profile、Protocol Binding 和 InteractionRequest 提升为一等模型的原因。

与规范的关系

白皮书强调产品形态，规范强调可实现且可验证的契约。推荐配套阅读：

• System Model
• Runtime SDK
• Runtime Connection Protocol
• Run
• Tracing