六个协议层里，哪一层标准最靠不住？

一个智能体要跨五个平台干活，靠的不是某个平台的独门绝技，而是一套正在收敛的协议栈。这套栈一共六层：四层建立在开放标准上，一层在每个平台上配置方式都不同，还有一层是你自己的代码。

先说最底下的工具调用层。MCP（模型上下文协议）负责让智能体发现并调用工具。一个服务器把工具列出来，每个工具带名称、描述、输入结构，还可以有输出结构和"只读"之类的标注。智能体挑一个工具、发起调用，拿回结果或者一个带名字的错误。

发票智能体的九个工具全部是 MCP 工具：get_invoice、run_three_way_match、request_approval、post_invoice_adjustment 等等。定义一次，每个平台都能托管或调用它们。

当前规范版本是 2026-07-28。对企业构建真正重要的改动有几条：无状态核心可以跑在普通 HTTP 基础设施上，藏在你已有的负载均衡器和网关后面；授权更贴近 OAuth 和 OpenID Connect，工具访问能复用现有身份提供方；新增了面向长任务的 Tasks 扩展和面向服务器渲染界面的 MCP Apps 扩展；还确立了正式的弃用政策，让协议能演进而不弄坏已有的服务器。

第二层是智能体之间的对话。A2A（智能体对智能体协议）解决的是一个智能体如何请另一个智能体做事，包括跨厂商的情况。1.0 版是第一个稳定版本，目前由 Linux 基金会下的 Agentic AI Foundation 托管，和 MCP 放在一起。

入门只需要三个概念：

• 智能体卡片。每个智能体在 /.well-known/agent-card.json 发布一张卡片，写明技能、端点和认证方式。卡片可以带 JWS 签名来保护完整性，但签名不等于可信——接受哪些签名方仍然由你决定。
• 带生命周期的任务。一个请求会变成任务，在 submitted、working、input-required、auth-required、completed、failed、canceled、rejected 等状态间流转，适合要跑几分钟或者需要补充信息的工作。
• 三种等价绑定。JSON-RPC、gRPC 和 HTTP+JSON 功能上等价，选哪个是运维层面的决定。

第三层是网关。它夹在智能体、工具和模型之间，不是单一标准，但每个平台都有一个，要干的活也一致：允许列表决定哪个智能体能调哪个工具或智能体；数据进模型前做 PII 检测；按智能体设 token 上限，免得一句坏提示词烧掉整月预算；对 MCP、A2A 和 LLM 流量做路由、限流和审计。

这些策略作为思路是可移植的，作为配置还不行。

第四层是身份：这个智能体到底是谁？栈里每一次调用都该回答一个问题——是哪个智能体，代表谁，带着什么权限。底下的标准并不陌生：OAuth 2 和 OpenID Connect，MCP 授权和 A2A 智能体卡片都建在它们之上。厂商之间的差别在于智能体怎么获得自己的身份：有的平台在目录里给智能体一等身份，有的用工作负载或服务身份。规则是一样的——每个智能体有自己的身份，按工具最小授权，不允许任何东西跑在共享管理员账号下。

第五层不是协议，是你的流程 API，也是整条栈里最重要的一行。request_approval 为一个人创建任务，审批通过返回一个 approval_id。post_invoice_adjustment 和 notify_supplier 会拒绝任何不带它的调用，返回名为 APPROVAL_MISSING 的错误。

MCP 和 A2A 都不会替你强制执行这件事，它们也不该这么做。协议负责搬消息，业务规则决定什么可以放行。把这道闸门留在你自己的代码里，它才能在任何模型、智能体或平台更换时活下来。

第六层是遥测。要运维这条栈，你得能追踪一张发票穿过智能体、工具和模型的全过程。标准是 OpenTelemetry，它的 GenAI 语义约定定义了 invoke_agent、execute_tool 这类 span。这些约定目前仍处于 Development 状态，名字可能随版本变化。用它们，同时让仪表盘保持容易更新。

哪些是标准、哪些不是，这条分界线值得记牢。值得一次性投入的标准部分：工具契约用 MCP，智能体卡片和任务处理用 A2A，身份用 OAuth 2 和 OpenID Connect，追踪用 OpenTelemetry。应当视为可替换的厂商专属部分：智能体运行时和工作室、网关策略配置、智能体获得身份的方式、注册表、评估工具和仪表盘。永远属于你自己的：人工闸门和流程 API 里的业务规则。

这条分界线也决定了平台该怎么打分。一个把标准层支持好的平台，会让它上面的一切都可移植；一个只认自己那套版本的平台，起步可能更快，但离开的代价更高。