协议互操作性

本文解释 AaaS 为什么要原生对齐 A2A、ACP、AG-UI、MCP，以及为什么仍然坚持以 canonical 平台模型为真源。规范性定义请参考 A2A Profile、ACP Profile、AG-UI Profile、MCP Server Profile 和 Interaction Request。

为什么不能只定义私有接口

现实里的 Agent 生态已经有大量既有协议面：

• 跨 Agent 协作需要 Agent Card、任务委派和远端能力发现
• coding client 需要会话、终端、文件系统和权限确认
• Web / IDE 前端需要事件流、历史恢复和可中断交互
• 工具服务器需要可复用的 Tool catalog 与调用协议

如果 AaaS 只定义一套平台私有接口，那么每个现有生态都会被迫单独写适配器，结果通常是：

• 相同的审批、补充输入、鉴权逻辑在多个协议里重复实现
• 每个客户端各自维护暂停、恢复和历史重建语义
• 平台失去统一审计、恢复和治理能力
• 外部生态接入成本高，迁移也高

因此，AaaS 的目标不是“发明另一套封闭协议”，而是把已有广泛使用的协议收敛到统一治理平面。

AaaS 的策略

AaaS 采用的是“一个 canonical model，多条 native protocol surface”的策略：

• 平台真源始终是 Agent、Tool、McpServer、Revision、ReleaseChannel、ProtocolBinding、Run、InteractionRequest、Artifact、Checkpoint、Trace
• A2A、ACP、AG-UI 作为一等北向协议面暴露：由 revision 上的 protocolProfiles 声明能力，由 ProtocolBinding 声明 transport 和安全要求
• MCP 通过 McpServer / McpServerRevision 作为 server-first 协议面收敛，负责 tool catalog、prompts/resources 和托管 session 互操作
• 所有协议里的审批、补充输入、鉴权、确认需求统一收敛到 InteractionRequest

这意味着 AaaS 既不会把外部协议降格成“文档里的映射示意”，也不会让外部协议反过来成为平台真源。

四类协议如何分工

A2A

适合做跨 Agent 发现、Agent Card 暴露、任务创建、订阅输出和多 Agent 协作。

在 AaaS 中，它更像 Agent 目录和任务互操作层：

• Agent.card、AgentRevision.protocolProfiles.a2a 和 ProtocolBinding(a2a) 共同生成 Agent Card
• task 语义映射到 Run
• input-required、auth-required 一类等待态映射到 InteractionRequest
• resume / resubscribe 语义映射到标准 cursor

ACP

适合做强客户端语义的会话协议，尤其是终端、文件系统、权限确认和长会话。

这对 Claude Code、Codex、OpenCode 一类 coding client 或 coding runtime 很重要：

• session/new、session/prompt、session/cancel 映射到 run 命令
• session/request_permission 映射到 InteractionRequest
• fs/*、terminal/* 反映 execution profile 实际提供的能力
• session/list、session_info_update 可以作为平台读面的协议视图

AG-UI

适合做前端事件流、历史恢复、谱系展示和人机协作。

它解决的是“前端如何稳定消费 Agent 执行事实”：

• 事件流基于统一输出模型
• 历史恢复来自消息、interaction、artifact 与 replay
• 多 Agent 委派通过 RunLink 暴露谱系
• 人工审批、反馈和继续执行通过 InteractionRequest 回到统一写路径

MCP

适合做 Tool catalog、prompts/resources 与托管 MCP session 互操作。

它在 AaaS 中不是独立真源，而是通过 McpServer 收敛到 canonical 资源：

• McpServer 是稳定 server 身份，McpServerRevision 是不可变托管契约
• Tool 与 McpServer 是并行的 canonical 对象：前者适合 direct run，后者适合 server-first 暴露
• MCP 负责把工具目录、prompts/resources 和 MCP session 暴露给外部 client 或 runtime
• 工具调用结果如进入 run 输出流，仍回到统一事件模型

为什么 interaction model 是关键

协议互操作最容易失控的地方，不是“怎么发消息”，而是“怎么等待人”。

看起来不同的协议，底层其实经常在表达同一件事：

• A2A 的 input-required / auth-required
• ACP 的 permission request
• AG-UI 的 approval / intervention
• 原生 runtime 的等待输入、确认、授权

如果这些语义各自保留私有状态机，就会出现：

• 审计无法统一
• 超时和恢复策略无法统一
• 一个客户端能继续执行，另一个客户端却看不懂当前阻塞原因
• 平台无法对等待态做 SLA、告警和治理

InteractionRequest 的价值，就是把这些语义统一为平台一等对象。这样无论入口协议是什么，平台都可以：

• 在读面统一查询当前阻塞点
• 在控制面统一 resolve
• 在事件流里统一留下可回放事实
• 在超时、拒绝、取消时统一执行策略

Native Protocol，不是“适配器拼盘”

很多平台也会说自己“支持 A2A / ACP / AG-UI”，但实际只是在边角处做一些字段转译。AaaS 这里强调的是 native protocol surface：

• 协议能力是 AgentRevision 或 McpServerRevision 的结构化声明，而不是部署文档里的口头约定
• endpoint、transport、安全要求、能力协商都有结构化声明
• 协议恢复语义和平台 cursor / event ordering 明确对齐
• 交互阻塞不是协议私货，而是平台统一模型

同时，AaaS 也不把草案特性直接写进平台核心模型。还不稳定的协议能力应作为 extension，而不是污染 canonical 资源。

典型落地路径

1. 先明确你的系统在生态里扮演什么角色。
2. 如果要做跨 Agent 协作，优先对齐 A2A。
3. 如果要托管强交互 coding client 或 rich session，优先对齐 ACP。
4. 如果要做 Web / IDE 前端交互，优先对齐 AG-UI。
5. 如果要暴露 Tool catalog、prompts/resources 或托管 MCP session，优先对齐 MCP。
6. 把协议里的等待输入、审批、鉴权都收敛到 InteractionRequest。
7. 把最终事实统一写回 Run、事件流和读面。

带来的结果

这样做的直接收益不是“多了几份协议文档”，而是：

• 现有 Agent、客户端、前端和工具可以用更低改造成本接入平台
• 平台可以统一处理治理、恢复、审计和观测
• 外部协议可以演进，但平台核心模型不必跟着漂移
• 团队更容易在不同 framework、runtime、client 之间替换实现，而不重写外围系统