协议战争的第二回合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 事件速览事件时间主体它试图解决什么它没有解决什么draft-zeng-opsawg-applicability-mcp-a2a-012026-10-14/15 前后个人提交的 IETF 草案opsawg 相关[1]把 MCP/A2A 的适用性讨论纳入网络运维管理语境个人提交草案不等于 IETF 标准具体状态需在 Datatracker 核实AI Passport同期ServiceNow [1]为每个 Agent 签发加密签名凭证使 Agent 可识别凭证格式、签名算法、撤销机制未见一手说明Agent Gateway同期Google Cloud [1]在基础设施层做协议感知的策略执行点首个协议原生网关属厂商宣称第三方认定未见值得注意的不是任何单条事件的爆点而是三者落在同一空白层的不同切口草案走标准化路线Passport 走凭证化路线Agent Gateway 走基础设施路线。三种切口同时出现通常意味着行业对当前协议栈的缺层已有共识只是对补层方式尚未达成共识。1.2 为什么可以说MCP 收敛了工具调用执行层MCPModel 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 上移一层调用能执行不等于调用被允许执行层收敛后三个空洞会立刻暴露在生产环境里谁在调用——一个 Agent 背后可能是某个用户、某个团队、某个自动化流水线也可能是另一个 Agent 转发的请求。当前工具调用链路默认把调用方当成应用而不是有责任主体的行为体。谁允许它调用——OAuth 式授权解决的是用户授权应用但 Agent 会自主决策调用哪个工具、调用几次。授权粒度是应用级行为粒度却是动作级两者错位。出事能否撤销与追责——长期有效的 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 MCPAgent 与工具之间的标准接口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 A2AAgent 与 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_cartAgent 直接调用而不必猜测按钮位置或处理下拉菜单的渲染时序 [4]。这对网站开发者意味着新的义务声明哪些能力可以被调用、每个能力的权限边界在哪里、是否需要用户确认。WebMCP 与 MCP 的关系是 MCP 在网站侧的延伸、还是独立提案在本文依据材料中未见规范原文说明属于需回溯一手来源的部分可以确定的是它改变的是工具定义的所有权——从 Agent 侧猜测转向网站侧声明。2.5 收束四者是分层叠加不是四选一层次机制解决的问题不解决的问题模型接口层Function Call模型如何表达调用意图跨应用复用、工具发现工具执行层MCPAgent ↔ 工具的标准化接入Agent 间协作、身份治理网站侧工具声明WebMCP网站结构化暴露可调用能力调用方身份、授权撤销协作层A2AAgent ↔ Agent 的任务交接单次工具调用的执行细节信任治理层凭证 / 网关 / 握手协议谁在调、谁批准、能否撤销具体业务的权限语义三、组合关系与选型决策3.1 四种典型组合场景最小协议栈复杂度主要风险单 Agent 调用本地函数Function Call低几乎无跨进程风险审计价值有限单 Agent 接入外部工具/数据源Function Call MCP中工具权限过宽、凭证长期有效多 Agent 共享工具池MCP 编排层任务/状态管理中高任务重复、状态漂移、责任不清跨组织 Agent 协作MCP A2A 身份与网关层高跨域信任、撤销链路、审计归属社区的选型判断与此一致调用本地函数用 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 / 工具资产登记表自拟非标准 APIagent_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_minutes30):recordregistry.lookup(agent_id)# 必须先登记assertrecord.ownerandrecord.purpose# 无主不发证tokensigner.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):claimsverifier.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 授权与审计把人工介入前置到行为分级行为分级例子处置策略只读查询订单、读取文档自动执行记录审计有限写创建草稿、更新标签自动执行 事后抽查高影响资金操作、删除数据、变更权限人工确认后执行双人复核对外发送发邮件、发消息、调用外部 API人工确认 白名单目标 速率熔断分级的目的不是阻塞而是把有限的人工注意力投到真正不可逆的动作上。熔断条件应包含调用频率突增、越权尝试、同一任务重复触发失败、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 个月值得跟踪的信号观察信号在哪里看何种变化意味着格局改变草案draft-zeng-opsawg-applicability-mcp-a2a-01的状态IETF Datatracker从个人草案进入工作组讨论ATH 的协议版本与开源实现信通院官方发布与代码仓库出现跨厂商互操作测试网关产品的协议支持面各云厂商文档同时原生支持 MCP 与 A2A 并开放互操作凭证格式的开放性厂商技术文档采用可验证凭证等开放格式并支持跨域校验互认进展厂商联合公告出现凭证或审计格式的跨厂商互认三种收敛路径都可能成真身份层先标准化、网关层形成事实标准、或多方案长期并存并由适配层消化差异。对工程团队而言真正稳健的策略不是押注某一方而是把自己的身份登记、最小权限、即时撤销与任务级审计先做扎实——这些能力在任何一种收敛路径下都不会过时而缺失这些能力的系统无论采用哪种协议都很难通过下一轮的生产与合规评审。参考资料[1] 深度Agent 协议战争上移MCP 赢了执行层身份与治理成了新战场CSDNhttps://blog.csdn.net/summerliyang/article/details/168333394 该文提及 IETF Datatracker、ServiceNow、Google Cloud、信通院 ATH 等一手来源本文依据资料未附其可访问链接相关细节需回溯核实[2] AI Agent 通信协议深度解析从 MCP 工具互联到 A2A 多智能体协作CSDNhttps://blog.csdn.net/gitblog_00349/article/details/166480559[3] 多智能体架构实战MCP、A2A、Skills 与编排模式全解析CSDNhttps://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 国家标准实施信息CSDNhttps://blog.csdn.net/IT_ORACLE/article/details/169804659[9] imhassla/mcp-hub多 Agent 编排 MCP Server含任务租约与 KPI/SLO 观测GitHubhttps://github.com/imhassla/mcp-hub[10] 深入理解 AI Agent 架构从理论到 MCP 协议实践掘金https://juejin.cn/post/7623768662602121225