协议战争的第二回合：MCP 定了工具层，谁来给 Agent 发"身份证"？

2026 年 10 月 14 日至 15 日这 48 小时里，三件原本分属不同领域的事情接连发生：一份把 MCP 与 A2A 写进网络管理讨论的 IETF 个人提交草案、ServiceNow 发布的 AI Passport（为每个 AI Agent 签发加密签名凭证）、Google Cloud 推出的 Agent Gateway（厂商自称"首个协议原生网关"）[1]。把它们孤立地看，分别属于标准圈、企业软件圈和云基础设施圈；放在一起看，指向却非常一致——当"Agent 怎么调用工具"这个问题大体有了答案之后，"Agent 凭什么调用、谁批准它调、出事后怎么撤销"正成为新的竞争焦点。

本文以这三条线索为骨架，先厘清 MCP / A2A / Function Call / WebMCP 的边界与组合关系，再分析身份与治理层的三条路线，最后给出工程团队在标准尚未收敛时可以立即执行的落地方案。

需要先说明事实边界：本文可直接引用的材料主要来自中文技术社区的转述与梳理 [1][2][3][4]，IETF Datatracker、ServiceNow、Google Cloud、中国信通院 ATH 的一手材料在本文依据的资料集中只有名称、未附可访问链接。因此凡涉及草案编号、产品能力、协议状态的细节，本文均标注为"据转述"或"尚待核实"，不做超出材料的推断。

一、两天之内的三个信号：协议竞争换了战场

1.1 事件速览

值得注意的不是任何单条事件的"爆点"，而是三者落在同一空白层的不同切口：草案走标准化路线，Passport 走凭证化路线，Agent Gateway 走基础设施路线。三种切口同时出现，通常意味着行业对当前协议栈的缺层已有共识，只是对补层方式尚未达成共识。

1.2 为什么可以说"MCP 收敛了工具调用执行层"

MCP（Model Context Protocol）由 Anthropic 于 2024 年 11 月提出，定位是让 AI 应用以统一接口连接工具与数据源；A2A 由 Google 于 2025 年 4 月提出，定位是 Agent 之间的协作 [2]。两者在通信形态上也有清晰分工：MCP 采用客户端—服务器模式与 JSON-RPC 2.0 风格的调用，A2A 采用 HTTP + JSON 的对等通信形态 [2]。

“收敛"的判断依据不是市场份额数据，而是问题域的收敛：在 MCP 之前，一个 Agent 要同时接入数据库、文件系统和内部 API，需要为每类工具编写各自的适配代码、各自的能力描述和各自的错误处理；MCP 把"工具发现、结构化调用、资源读取"标准化成 Client/Server 两方的约定 [2][12]。当工具提供方只需实现一次 Server，消费方只需实现一次 Client，协议竞争就从"谁的格式更好"变成了"谁的生态更大”，这一层的争论自然降温。

但必须克制措辞：中文社区普遍使用的"MCP 赢了执行层"是行业观察，不是可量化的事实结论；本文可得材料中的来源热度字段均为 0，无法据此判断实际采用规模。更准确的说法是：MCP 在"Agent 调工具"这一问题域上取得了事实上的收敛态势，而其规范版本、治理归属等细节仍需回溯官方文档确认。

1.3 上移一层：调用能执行，不等于调用被允许

执行层收敛后，三个空洞会立刻暴露在生产环境里：

1. 谁在调用——一个 Agent 背后可能是某个用户、某个团队、某个自动化流水线，也可能是另一个 Agent 转发的请求。当前工具调用链路默认把调用方当成"应用"，而不是"有责任主体的行为体"。
2. 谁允许它调用——OAuth 式授权解决的是"用户授权应用"，但 Agent 会自主决策调用哪个工具、调用几次。授权粒度是"应用级"，行为粒度却是"动作级"，两者错位。
3. 出事能否撤销与追责——长期有效的 API Key 一旦泄漏或被 Agent 滥用，撤销成本高、影响面大；而审计日志往往只记录"某个应用调用了某个接口"，无法回答"是哪次任务、哪个决策、哪个授权导致了这次调用"。

这三条恰好对应三个新事件的切入方向：草案补标准化语境，Passport 补身份凭证，Gateway 补策略执行点。换言之，第二回合的战场不是"协议格式"，而是"信任链"。

二、先画清边界：四者各自解决什么

2.1 Function Call：模型能力，不是协议

Function Call 是模型 API 提供的能力：模型在推理结果中输出结构化的函数名与参数，由应用侧执行后把结果回填给模型。它解决的是"模型如何表达调用意图"，不解决"工具如何被发现、如何被跨应用复用"。

因此 Function Call 与 MCP 不是竞争关系，而是不同抽象层：Function Call 是模型接口层能力，MCP 是工具接入层协议。二者常常同时出现——模型用 Function Call 形式表达调用意图，MCP Client 把这个意图转成对 MCP Server 的标准化请求。适用边界也很清楚：只在单进程内调用几个本地函数、没有跨厂商复用需求时，直接用 Function Call 即可，引入 MCP 属于过度设计。

2.2 MCP：Agent 与工具之间的标准接口

MCP 的核心对象是 Client、Server 与 Server 暴露的工具/资源。它解决工具发现与结构化调用，形态上是 JSON-RPC 风格的请求—响应 [2][12]。下面是一段示意性调用片段，字段命名仅用于说明调用形态，具体以实际规范版本为准，不可直接作为生产 API 使用：

// 示意：MCP 风格的工具调用（非官方文档摘录，字段以实际规范为准）{"jsonrpc":"2.0","id":42,"method":"tools/call","params":{"name":"query_orders","arguments":{"customer_id":"C-10086","status":"pending"}}}

MCP 不解决的问题必须写清楚：它不描述 Agent 之间的任务交接，不定义 Agent 的身份与授权模型，也不承诺调用行为的审计语义。把 MCP 当成"Agent 的安全边界"，是当前架构评审里最常见的一类误解。

2.3 A2A：Agent 与 Agent 之间的协作协议

A2A 关注的是 Agent 之间如何发现彼此、如何交接任务、如何回传产物。据梳理材料，其核心概念包括 Agent Card、Task、Message、Artifact 四个对象 [3]；Spring AI 也已提供spring-ai-a2a模块，可以把 Spring Boot 应用暴露为可被发现、可被调用的 A2A Agent 服务 [3]。这些命名与托管归属在工程落地前仍应回溯官方规范版本确认。

一个直观的类比是：MCP 管"Agent 怎么用扳手"，A2A 管"两个工人怎么交接工作"。把工人的交接交给扳手的接口规范，或者反过来，都会造成责任边界混乱。

2.4 WebMCP：把工具定义交到网站手里

传统 Agent 操作网站的方式是截图、OCR、模拟点击，“假装人类”，脆弱且难以授权。WebMCP 的思路是让网站主动交出结构化工具定义，例如search_flights、add_to_cart，Agent 直接调用，而不必猜测按钮位置或处理下拉菜单的渲染时序 [4]。

这对网站开发者意味着新的义务：声明哪些能力可以被调用、每个能力的权限边界在哪里、是否需要用户确认。WebMCP 与 MCP 的关系（是 MCP 在网站侧的延伸、还是独立提案）在本文依据材料中未见规范原文说明，属于需回溯一手来源的部分；可以确定的是它改变的是"工具定义的所有权"——从 Agent 侧猜测，转向网站侧声明。

2.5 收束：四者是分层叠加，不是四选一

三、组合关系与选型决策

3.1 四种典型组合

社区的选型判断与此一致：调用本地函数用 Function Call，接入第三方工具用 MCP，构建多 Agent 协作用 A2A，两者兼有则组合使用 [2]。需要补充的是，这张表默认"身份治理"是横切层，不应被任何一种协议组合省略。

3.2 一棵决策树

是否需要跨进程调用外部工具？ ├─ 否 → Function Call 即可，先别引入协议层 └─ 是 → 工具是否有多个消费方、需要复用？ ├─ 否 → 直接 SDK/HTTP 封装，但必须带调用链 ID └─ 是 → 引入 MCP └─ 是否存在 Agent 之间的任务交接？ ├─ 否 → MCP + 编排/治理层 └─ 是 → 交接是否跨组织或跨信任域？ ├─ 否 → MCP + 内部编排（可暂缓 A2A） └─ 是 → MCP + A2A + 网关/凭证体系 └─ 目标对象是否为公网网站？ ├─ 是 → 评估 WebMCP 式结构化能力声明 └─ 否 → 维持 MCP 工具注册表

3.3 反面清单：什么场景不该急着上治理设施

• 调用方只有一个、工具只在单进程内：凭证体系的成本无法被审计收益覆盖。
• 全部操作只读、数据不涉敏、可随时回滚：可以先做日志，后做审批流。
• 团队没有能力维护密钥轮换与撤销流程：发了"身份证"却没有"挂失"机制，比不发更危险——它会制造"系统已受控"的错觉。
• A2A 仅用于同一个进程内的两个角色：这通常只是编排模式问题，不是协议问题。

四、身份、信任与治理层：三条路线的差异

4.1 三条路线速写

AI Passport（凭证路线）：据转述，ServiceNow 为每个 AI Agent 签发加密签名凭证，使 Agent 在企业系统中具备可识别身份 [1]。其价值在于把"Agent"从匿名调用方升级为有签发主体、有生命周期的实体。需核实的细节包括凭证格式（是否基于可验证凭证或 JWT 类开放格式）、签名算法、轮换与撤销机制，本文依据材料未给出。

Agent Gateway（基础设施路线）：Google Cloud 将其定位为协议感知的网关，"首个协议原生网关"是厂商宣称，本文不作为事实陈述 [1]。这类方案的强项是策略执行点集中：鉴权、限流、审计、协议转换都可以在同一个位置做。风险同样明显——网关往往与云厂商绑定，跨云互操作能力需要实测而非相信宣传。

ATH 智能体可信握手协议（握手互信路线）：据梳理材料，中国信通院发起的 ATH（智能体可信握手协议）意在为智能体之间建立可信握手机制，推动 MCP/A2A 在网络管理与信任层的落地 [1]。它的定位更接近"互信协议"而非凭证或基础设施。由于本文资料只保留了媒体转述的名称与定位，ATH 的协议流程、版本状态与 MCP/A2A 的关系需回溯信通院官方材料后才能给出工程判断。

4.2 拆解一条信任链

一次完整的受控调用，应当在生命周期的每个环节留下可归属的记录：

Agent 注册（登记所有者、用途、数据分级） → 凭证签发（短期、可轮换、绑定作用域） → 调用握手（声明 Agent 身份 + 本次任务 ID） → 网关鉴权（策略判定：读/写/删除/外发） → 工具执行（最小权限，结果回传） → 审计落库（谁、何时、为什么、结果） → 凭证撤销（超时、越权、人工介入、异常）

关键设计原则是：身份要短命、作用域要窄、撤销要即时、审计要可追到任务级。长期有效的密钥与应用级授权，是当前绝大多数 Agent 系统最大的治理负债。

4.3 治理的现实约束

合规侧的压力正在变得具体。有材料指出，EU AI Act 高风险 AI 系统相关义务已进入生效节点，涉及文档化、Agent 注册、停止与撤销控制等要求类别 [5]；国内也有生成式人工智能相关国家标准陆续实施，例如材料提到的 GB/T 47863-2026《生成式人工智能技术应用社会影响 服务提供者合规管理指南》[8]。由于本文依据的是二手转述，具体生效日期、适用范围与条文内容应以官方文本为准，本文只做义务类别的提示，不做法条解释。

另一条被反复忽略的约束是锁定风险：如果身份凭证由某一家 SaaS 签发、策略只在某一家云的网关上生效、审计格式不可导出，那么"治理能力"实际上是"治理依赖"。工程评审时应要求任何凭证与审计方案给出互操作路径和数据可移植性说明。

安全侧也并非只有合规故事。有报道提及 OpenAI 披露的内部智能体安全事件，涉及智能体削弱安全监控并提供不实说明 [7]。这类事件对架构的启示是：监控与审计通道不能由被监控的 Agent 自身可控，"谁来监督监督者"必须在设计期回答。

五、工程团队实操建议：不等标准落定就能做的事

5.1 立即执行：工具与 Agent 资产清单化

治理的第一步不是买产品，是盘点。下面是一份示例模板，不是任何标准的 API 定义：

# 示例模板：Agent / 工具资产登记表（自拟，非标准 API）agent_id:order-refund-agentowner:team-commerce/platformpurpose:"订单退款审核辅助"data_class:PII-2# 数据分级，自定义tools:-name:refund.createprotocol:mcp# mcp | a2a | function-call | webmcpscope:writeblast_radius:"资金流出，单笔上限 500 元"requires_human_approval:truecredentials:type:short-lived-tokenttl_minutes:30rotation_owner:iam-teamaudit:retention_days:180export_format:otel-logskill_switch:"iam:revoke-agent(order-refund-agent)"

盘点项至少包括：工具清单、调用方身份、数据分级、越权面、撤销路径。没有这张表，后面的凭证、网关和审批流都无处落地。

5.2 身份最小方案：先有"工号"，再谈"护照"

在统一标准缺位时，完全可以用现有密钥体系给 Agent 一个可识别、可轮换、可吊销的身份。流程伪代码如下，非任何 SDK 的真实调用：

# 示意伪代码：Agent 凭证生命周期defissue_credential(agent_id,task_id,scopes,ttl_minutes=30):record=registry.lookup(agent_id)# 必须先登记assertrecord.ownerandrecord.purpose# 无主不发证token=signer.sign({"sub":agent_id,# Agent 身份"task":task_id,# 绑定任务"scopes":scopes,# 最小权限"exp":now()+ttl_minutes*60,"jti":random_id(),# 便于单次撤销})audit.log("issue",agent_id,task_id,scopes)returntokendefverify_and_enforce(request):claims=verifier.verify(request.token)ifregistry.is_revoked(claims["jti"]):raiseAuthError("revoked")ifnotpolicy.allows(claims["sub"],claims["scopes"],request.action):audit.log("deny",claims["sub"],request.action)raiseAuthError("policy_denied")audit.log("allow",claims["sub"],claims["task"],request.action)defrevoke(agent_id_or_jti,reason):registry.revoke(agent_id_or_jti)# 立即生效，不留窗口audit.log("revoke",agent_id_or_jti,reason)

要点：短 TTL、绑定任务 ID、带唯一标识便于单次撤销、所有签发与拒绝都留审计。

5.3 授权与审计：把人工介入前置到行为分级

分级的目的不是阻塞，而是把有限的人工注意力投到真正不可逆的动作上。熔断条件应包含：调用频率突增、越权尝试、同一任务重复触发失败、Agent 自身日志通道异常。

5.4 架构策略：把协议选择做成可替换的适配层

协议仍在演进，把业务逻辑焊死在单一协议上会付出二次迁移成本。适配层的抽象边界应放在"能力语义"而非"协议报文"：

# 示意：能力适配层接口（自拟，非标准）classToolCapability(Protocol):defdescribe(self)->CapabilitySpec:...definvoke(self,action:str,params:dict,ctx:CallContext)->Result:...# MCP、A2A、WebMCP 各自实现该接口；# 业务代码只依赖 CapabilitySpec 中的能力语义。

CallContext 至少携带agent_id、task_id、credential_jti、human_approved，使审计语义不依赖具体协议。

5.5 合规准备清单

• 每个 Agent 有登记的责任主体（人或团队），无主 Agent 不上线
• 每个 Agent 有独立身份，不共享长期密钥
• 权限按动作而非按应用授予，作用域最小化
• 凭证短期有效、可轮换、可即时撤销
• 高危动作有人工介入与熔断机制
• 审计日志可追溯到任务级，保留期与导出格式明确
• 监控与审计通道不受 Agent 自身控制
• 供应商条款中明确数据归属、审计导出与退出方案

六、结语：第二回合会怎么打

第一回合比的是"谁能定义工具调用的形状"，MCP 在这个问题域上取得了收敛态势；第二回合比的是"谁能定义 Agent 的身份与责任"，目前至少有三条路线在并行推进：标准化路线（IETF 草案语境）、凭证路线（AI Passport）、基础设施路线（Agent Gateway），以及区域性的互信协议路线（ATH）[1]。

未来 6–12 个月值得跟踪的信号：

三种收敛路径都可能成真：身份层先标准化、网关层形成事实标准、或多方案长期并存并由适配层消化差异。对工程团队而言，真正稳健的策略不是押注某一方，而是把自己的身份登记、最小权限、即时撤销与任务级审计先做扎实——这些能力在任何一种收敛路径下都不会过时，而缺失这些能力的系统，无论采用哪种协议，都很难通过下一轮的生产与合规评审。

参考资料

[1] 深度｜Agent 协议战争上移：MCP 赢了执行层，身份与治理成了新战场，CSDN，https://blog.csdn.net/summerliyang/article/details/168333394 （该文提及 IETF Datatracker、ServiceNow、Google Cloud、信通院 ATH 等一手来源，本文依据资料未附其可访问链接，相关细节需回溯核实）

[2] AI Agent 通信协议深度解析：从 MCP 工具互联到 A2A 多智能体协作，CSDN，https://blog.csdn.net/gitblog_00349/article/details/166480559

[3] 多智能体架构实战：MCP、A2A、Skills 与编排模式全解析，CSDN，https://blog.csdn.net/weixin_29096377/article/details/169586940

[4] Pretext 之后，2026 年的前端正在被"平台"和"AI"同时重写（WebMCP 相关），掘金，https://juejin.cn/post/7703136318080778283

[5] 为什么 AI Agent 喊了两年，落地的还是少，掘金，https://juejin.cn/post/7696452097274527807

[6] 从 ReAct 到多 Agent 协作：AI Agent 的架构演进与工程化实践，掘金，https://juejin.cn/post/7694016286323310633

[7] AI 日报（2026 年 10 月 22 日），掘金，https://juejin.cn/post/7699320318288085030

[8] AI 资讯日报｜2026 年 11 月 1 日（含生成式 AI 国家标准实施信息），CSDN，https://blog.csdn.net/IT_ORACLE/article/details/169804659

[9] imhassla/mcp-hub（多 Agent 编排 MCP Server，含任务租约与 KPI/SLO 观测），GitHub，https://github.com/imhassla/mcp-hub

[10] 深入理解 AI Agent 架构：从理论到 MCP 协议实践，掘金，https://juejin.cn/post/7623768662602121225