MCP+A2A融合协议落地:Agent协议层标准化,信任层才是最大硬仗
2026年6月25日Linux Foundation Agentic AI Foundation 正式发布了 MCP A2A 融合草案。说实话这个时间点选得挺有意思——正好赶在 WAIC 2026 开幕前一个月等于是给整个行业递了一张标准化路线图。如果你一直在关注 AI Agent 领域应该对这个消息不意外。MCPModel Context Protocol和 A2AAgent-to-Agent这两个协议一个管 Agent 和工具之间的通信一个管 Agent 和 Agent 之间的通信。过去半年这两个协议各自发展社区里也一直在讨论到底选哪个。现在 Linux Foundation 一句话把这事儿定了调不是二选一是互补。先搞清楚 MCP 和 A2A 分别解决什么问题MCP 最早由 Anthropic 提出解决的是 Agent 和外部工具之间的标准化连接问题。简单说以前你要让 Agent 调用一个 API、查一个数据库、读一个文件每种工具都要单独写适配代码。MCP 定义了一套统一的协议Agent 只需要实现 MCP Client工具提供方只需要实现 MCP Server两边就能自动对接。用过的都懂这就好比 USB 接口出现之前每个外设都有自己的接口标准键盘是 PS/2、鼠标是串口、打印机是并口——乱得一塌糊涂。MCP 就是 AI Agent 世界的 USB 标准。A2A 则是 Google 主推的解决的是 Agent 之间的通信和协作问题。当你有多个 Agent 需要协同工作——比如一个 Agent 负责搜索信息、一个 Agent 负责分析数据、一个 Agent 负责写报告——它们之间怎么传递任务、怎么协商优先级、怎么处理冲突A2A 就是干这个的。下面这张图把两者的分工画得很清楚A2A域MCP域MCPMCPMCPMCPMCPA2A 任务委派A2A 结果同步A2A 协商Agent A数据库工具API工具文件系统Agent B搜索工具代码执行器Agent C说白了MCP 管的是Agent 怎么用工具A2A 管的是Agent 之间怎么聊天。两者不是竞争关系而是解决不同层面的问题。融合草案到底定了什么Linux Foundation 这次的融合草案核心做了三件事第一明确了协议边界。MCP 和 A2A 不再各自为政而是有了明确的分工定义。MCP 负责 Agent ↔ Tool 的通信A2A 负责 Agent ↔ Agent 的通信。社区不用再纠结选哪个了两个都要用。第二统一了治理框架。两个协议都放在 Linux Foundation 旗下管理这意味着它们会共享相同的版本迭代节奏、安全审计标准、社区治理规则。对开发者来说不用再担心今天学了这个协议明天它被另一个协议替代了。第三定义了互通接口。融合草案里最关键的是一套桥接规范——当 Agent A 通过 MCP 调用了一个工具产生的中间结果需要传递给 Agent B 时怎么通过 A2A 把这个结果传过去草案定义了一套标准的序列化格式和传递机制。用代码来直观感受一下这个桥接过程importjsonfromdataclassesimportdataclass,asdictfromtypingimportAnydataclassclassMCPToolResult:MCP 工具调用结果tool_name:strresult:Any error:str|NoneNonedataclassclassA2ATask:A2A 任务定义task_id:strfrom_agent:strto_agent:strpayload:dictpriority:int1classMCP2A2ABridge: MCP → A2A 桥接器 将 MCP 工具调用结果封装为 A2A 任务消息 def__init__(self,agent_id:str):self.agent_idagent_id self.task_counter0defwrap_tool_result(self,mcp_result:MCPToolResult,target_agent:str)-A2ATask:将 MCP 结果包装为 A2A 任务self.task_counter1# 构建 A2A 消息体附带 MCP 调用上下文payload{source:mcp_bridge,tool_name:mcp_result.tool_name,tool_result:mcp_result.result,mcp_call_id:f{self.agent_id}_mcp_{self.task_counter},timestamp:2026-07-22T10:00:00Z}returnA2ATask(task_idftask_{self.task_counter},from_agentself.agent_id,to_agenttarget_agent,payloadpayload,priority1)# 使用示例bridgeMCP2A2ABridge(agent_idsearch_agent_01)# 模拟 MCP 调用数据库工具db_resultMCPToolResult(tool_namepostgres_query,result{rows:1500,columns:[id,name,score]})# 通过桥接器传给分析 Agenttaskbridge.wrap_tool_result(db_result,target_agentanalysis_agent_02)print(f生成 A2A 任务:{task.task_id})print(f目标 Agent:{task.to_agent})print(f载荷:{json.dumps(task.payload,ensure_asciiFalse,indent2)})这个桥接器虽然简单但体现了融合草案的核心思想MCP 和 A2A 不是两个孤岛而是通过标准化的桥接层无缝衔接。协议层就绪了信任层才是硬仗融合草案发布后社区的反应挺有意思。技术圈一片叫好觉得Agent 标准化终于有了定论。但企业级用户的态度更谨慎他们在关心另一个问题协议标准了但谁来保证 Agent 的行为是可信的说实话这确实是个真问题。回顾一下 Agent 的发展历程就能看出来2023-2024LLM 基础能力2025工具调用Function Calling2026 上半年MCP/A2A协议标准化2026 下半年信任层Agent 安全权限控制行为审计沙箱隔离结果验证当你的 Agent 可以自主调用工具、自主和其他 Agent 通信、自主执行任务时权限控制就变成了生死攸关的问题。比如一个财务 Agent 能不能直接调用银行转账 API一个代码 Agent 能不能直接 push 到生产分支这些不是协议能解决的问题需要在协议之上构建一套信任层。目前业界有几个方向在探索OAuth 2.0 扩展把 OAuth 的作用域Scope机制引入 Agent 工具调用Agent 只能访问被授权范围内的资源沙箱执行环境类似 Docker 容器的隔离机制Agent 的所有操作在沙箱内完成不影响宿主系统行为审计链用区块链记录 Agent 的每一次决策和操作实现事后可追溯对开发者的实际影响协议层标准化之后对开发者来说有几个直接的好处开发效率大幅提升。以前你要对接一个新的 API需要自己写适配层。现在只要这个 API 有 MCP Server你的 Agent 就能直接调用。社区里 MCP Server 的数量正在快速增长从数据库、搜索引擎到云服务覆盖越来越全。多 Agent 协作门槛降低。A2A 标准化之前多 Agent 系统基本都是各家自己搓的通信协议。现在有了统一标准不同团队开发的 Agent 可以直接对话——前提是大家都遵循 A2A 规范。技术栈选择更灵活。你可以用 LangChain 的 Agent 框架同事用 AutoGen 的框架只要两者都支持 MCP A2A就能互相配合。这比之前要么全用 LangChain要么全用 AutoGen的局面好太多了。下面是一个 MCP Server 的简单实现示例展示怎么把一个现有的 API 包装成 MCP 工具frommcp.serverimportServer,Toolfrommcp.typesimportTextContentimporthttpx# 创建 MCP ServerserverServer(weather-tool)server.tool()asyncdefget_weather(city:str)-list[TextContent]:查询城市天气 - 这是一个 MCP 工具asyncwithhttpx.AsyncClient()asclient:respawaitclient.get(fhttps://api.weather.com/v1/current,params{city:city})dataresp.json()return[TextContent(typetext,textf{city}当前温度:{data[temp]}°C, f湿度:{data[humidity]}%, f天气:{data[condition]})]# 启动 Serverif__name____main__:importasyncio asyncio.run(server.run())说实话这套东西写起来比想象中简单。MCP 的 Python SDK 封装得很干净核心就是定义工具函数、注册到 Server、启动服务。你的 Agent 只需要配置这个 MCP Server 的地址就能直接调用get_weather这个工具。写在最后MCP A2A 融合草案的发布标志着 AI Agent 从散兵游勇阶段进入了正规军阶段。协议层标准化是生态繁荣的前提——就像 HTTP 标准化之后 Web 才真正爆发一样。但协议层只是第一步。接下来的信任层、安全层、治理层每一个都比协议层更难啃。用 Linux Foundation 的话说“协议层已就绪信任层才是真正的硬仗。”对开发者来说现在是最好的入局时机。协议刚定下来生态还在早期现在把 MCP A2A 这套东西吃透等 Agent 真正大规模落地的时候你就有了先发优势。标签MCP协议、A2A协议、AI Agent、Linux Foundation、Agent标准化

相关新闻

OCR证件识别系统:提升数字化管理效率20倍

OCR证件识别系统:提升数字化管理效率20倍

1. 项目背景与核心价值在证件管理领域,纸质文档的数字化处理一直是个痛点。传统人工录入方式效率低下,错误率高,尤其当面对大量扫描件时,工作人员往往陷入重复劳动的泥潭。龙虾Claw系统正是为解决这一行业难题而生。这个系统最核心…

2026/7/24 0:04:31 阅读更多 →
MSPM0 ADC与温度传感器:从原理到实践的深度解析

MSPM0 ADC与温度传感器:从原理到实践的深度解析

1. MSPM0 ADC与温度传感器:从原理到实践的深度解析在嵌入式系统开发中,将物理世界的连续模拟信号(比如温度、压力、光照)转换为微控制器能够处理的数字信号,是赋予设备“感知”能力的第一步。德州仪器(TI&a…

2026/7/24 0:03:31 阅读更多 →
JPA 返回的接口 数据怎么样装到对象里边

JPA 返回的接口 数据怎么样装到对象里边

在 JPA 中,将查询结果映射到自定义对象(VO/DTO),主要有以下几种方式。结合你项目中的实际情况(同时使用了 JPA 和 MyBatis-Plus),我按推荐度从高到低列出:一、接口投影(I…

2026/7/24 0:03:31 阅读更多 →

最新新闻

《你别回头找我》为何能成为可传播的试听入口

《你别回头找我》为何能成为可传播的试听入口

《你别回头找我》写的是一种状态:《你别回头找我》把“你别”写成可听见的状态:拒绝有时是对自己的保护。听的人多半不是旁观,而是刚好走在同类路口,更适合的播放场是关掉通知、拒绝一次聚会、把话说断的路口。场景立住&#xff0…

2026/7/24 0:11:33 阅读更多 →
基于深度强化学习的电池储能系统优化控制实践

基于深度强化学习的电池储能系统优化控制实践

1. 项目概述在能源转型的大背景下,电池储能系统(BESS)作为平衡电网供需的关键技术,其运行效率直接影响着整个电力系统的经济性和稳定性。传统基于规则的充放电策略往往难以应对复杂多变的电网环境,而深度强化学习(DRL)因其强大的环境适应能力…

2026/7/24 0:10:33 阅读更多 →
影刀RPA 自动化舆情监控:关键词预警与报告生成

影刀RPA 自动化舆情监控:关键词预警与报告生成

影刀RPA 自动化舆情监控:关键词预警与报告生成 作者:林焱 写在前面 品牌负面舆情一旦爆发,几个小时内可能蔓延全网。靠人工每天刷微博、知乎、新闻,根本来不及。影刀可以帮你搭一套724小时的舆情监控系统:定时采集多…

2026/7/24 0:10:33 阅读更多 →
ArkUI Provider 和 Consumer 乱用怎么办:中式美食同类多层筛选页为什么别一路传参数

ArkUI Provider 和 Consumer 乱用怎么办:中式美食同类多层筛选页为什么别一路传参数

先把相关概念说清楚知识点在这个问题里怎么看自定义组件冻结功能用来写多页面栈、TabContent、LazyForEach 和 BuilderNode 混用时的刷新边界状态管理 V1 向 V2 迁移用来拆 State 到 Local、Param、Once、Event 的迁移判断Provider / Consumer用来解释跨层级双向同步&#xff0…

2026/7/24 0:10:33 阅读更多 →
【K8S 运维实战】11-资源管理Requests与Limits

【K8S 运维实战】11-资源管理Requests与Limits

资源管理:Requests/Limits 与 QoS 分级 一句话定位:为什么设了 Limits 还是被 OOM QoS 三级怎么用 ResourceQuota 实战。 写在前面 “我明明设了 memory limit 4G,Pod 还是 OOMKilled 了,这是什么玄学?”——这是我遇到过最经典的资源管理困惑。还有一类:“节点资源没用满,…

2026/7/24 0:10:33 阅读更多 →
OpenClaw+Kimi K2.5+Moltbook企业级AI工作流部署指南

OpenClaw+Kimi K2.5+Moltbook企业级AI工作流部署指南

1. OpenClawKimi K2.5Moltbook部署方案概述这个组合堪称当前最强大的AI工作流解决方案之一。OpenClaw作为自动化控制中枢,Kimi K2.5提供核心AI能力,Moltbook则负责交互界面呈现。三者的结合可以打造出一个智能程度极高的工作助手系统。我在实际部署过程中…

2026/7/24 0:09:32 阅读更多 →

日新闻

用Highcharts 创建可拖拽三维散点立方体3D图表

用Highcharts 创建可拖拽三维散点立方体3D图表

该案例基于Highcharts scatter3d 三维散点图实现空间立方体散点可视化,核心特色:三维 X/Y/Z 三轴空间,所有散点分布在 0~10 立方体空间内;散点使用径向渐变实现立体 3D 圆球质感;支持鼠标 / 触屏拖拽画布,…

2026/7/24 0:00:29 阅读更多 →
AppCertDlls:进程创建路径上的 DLL 入口

AppCertDlls:进程创建路径上的 DLL 入口

AppCertDlls:进程创建路径上的 DLL 入口 AppCertDlls 位于 HKLM\System\CurrentControlSet\Control\Session Manager\AppCertDlls。本文的程序功能是只读列出这个键在 64 位和 32 位注册表视图中的全部值,并显示每条值的来源、名称、类型和可安全显示的数…

2026/7/24 0:00:29 阅读更多 →
我的编程之路:第一篇博客

我的编程之路:第一篇博客

大家好,我是一名编程初学者,同时这也是我编程学习之路上的第一篇博客。在这里,我想要向大家介绍我的一些想法和规划。a.自我介绍我是一个刚刚接触编程的新手,目前在学习c语言,我对编程世界充满了强烈的好奇。当然&…

2026/7/24 0:00:29 阅读更多 →

周新闻

Go语言静态资源打包方案对比与实践指南

Go语言静态资源打包方案对比与实践指南

1. 项目背景与核心需求在Go语言开发中,我们经常需要处理静态资源文件的打包问题。无论是Web应用的模板文件、前端资源,还是配置文件、证书等,都需要随程序一起分发。传统做法是将这些文件与编译后的二进制文件放在同一目录下,但这…

2026/7/22 8:58:19 阅读更多 →
Go语言实现高性能LDAP认证服务的架构与实践

Go语言实现高性能LDAP认证服务的架构与实践

1. 项目背景与核心价值LDAP(轻量级目录访问协议)作为企业级身份认证的黄金标准,已经服务了超过80%的财富500强公司。我在金融科技领域实施统一认证体系时,发现传统Java方案存在启动慢、内存占用高等痛点。而Go语言凭借其协程并发模…

2026/7/22 19:43:43 阅读更多 →
【AI面试官实战指南】:用ChatGPT模拟10类高频技术岗面试,3天提升应答精准度92%

【AI面试官实战指南】:用ChatGPT模拟10类高频技术岗面试,3天提升应答精准度92%

更多请点击: https://intelliparadigm.com 第一章:AI面试官实战指南的核心价值与适用场景 AI面试官并非替代人类HR的“黑箱工具”,而是以可解释、可审计、可迭代的方式,赋能招聘全链路的关键基础设施。其核心价值在于将主观经验沉…

2026/7/23 17:49:47 阅读更多 →

月新闻