Reader

MCP+A2A引爆Agent生态?

| 人人都是产品经理 | Default

探索MCP与A2A协议如何共同塑造Agent生态的未来,本文深入分析了这两种技术如何使AI智能体从单一工具演变为能够跨厂商协作的“同事”,并预示着软件工程领域的一场新变革。

还没来得及消化MCP(《5000字详解科技圈爆火的MCP》)带来的冲击,谷歌又放出了更震撼的技术拼图。昨天Agent-to-Agent协议(A2A)宣布开源,这项让不同AI智能体实现「跨厂商组队」的技术,与MCP可以互补协同,满足大家对Agent的究极想象。

至此,AI不再只是执行命令的「工具人」——它们开始像真正的同事般组建项目组:财务Agent自动联动法务Agent审核合同,营销Agent实时协调设计Agent迭代方案,底层MCP服务则如同专业工具箱被精准调用……

更重要的是,这会不会开启任务委托给智能而非软件的变化?

一、A2A :会“加微信”的智能体

A2A通过一套标准协议让不同出身(研发公司)和背景(技术框架)的Agent能互相沟通、协作,共同完成复杂任务,从“工具”进化成“同事”。

不同的Agent之间怎么干活呢?这里还涉及到Agent之间的身份区别。Clien Agent和 Remote Agent。终端用户只面对Clien Agent,剩下的活,Clien Agent会找擅长各个技能的Remote Agent完成。就像甲方发标给总集成,总集成招募每个模块的分包服务商一起做个大项目。

具体而言,A2A通过4大机制和模块设计保障不同Agent一起和谐的干活。

能力发现:技能说明书

Agent Card。该协议通过能力发现机制实现代理间的智能匹配,每个代理均可通过JSON格式的“Agent Card”公开自身技能,例如“财务数据分析”“物流时效预测”或“多模态内容生成”,如同数字名片般展示其擅长的任务类型、接口地址和权限要求。

在A2A协议下, 每个Agent都会生成一张“能力说明书”,用JSON格式写成,里面写着它能做什么、擅长什么。比如:

  • “我叫财务助手,能处理税务问题,支持文本和表格输入,需要API密钥认证。”
  • “我叫设计师助手,能生成图片和视频,支持用户上传素材。”

当你问自己的Agent一个复杂问题,比如“帮我找适合的房源并装修设计”,Agent会查看其他Agent的“代理卡”,找到擅长找房源的“房产助手”和擅长设计的“装修助手”,然后联系它们。//任务管理:件件有着落,事事有回响

任务管理模块是A2A区别于传统API的核心创新。协议将“任务”定义为具有完整生命周期的对象,从创建、执行到终结均纳入统一管理框架。

具体包含两个部分:

1)任务生命周期。每个任务都有从“创建”到“完成”的阶段,比如:

(1)即时任务:比如问“今天天气如何?”,远程Agent立刻返回结果。

(2)长期任务:比如“帮我分析季度财报”,可能需要几个小时,期间会不断同步进度:

  • “数据已加载,正在计算……”
  • “图表生成完成,需要人工审核。”
  • “任务完成,生成报告附件。”

2)工件(Artifact)。任务完成后产生的结果,可能是文本、图片、表格等。比如分析财报后生成的PDF报告。就像你在公司发起一个项目,项目经理(客户端Agent)分配任务给各部门(远程Agent),实时跟踪进度,最后汇总成果。//协作:Agent之间互相“发微信”

Agent之间先互相认识,加个好友。当要一起干活的时候,agent之间可以互相“发微信”商讨怎么干活。Agent之间可以传递:

  • 上下文:比如“用户需要的房源在市中心,预算200万”。
  • 中间结果:比如“房产助手找到了5套房,已标注在地图上”。
  • 指令:比如“请根据用户喜好调整装修风格为现代简约”。

就像团队开会时,项目经理(客户端Agent)协调设计师、程序员等(远程Agent),大家互相传递信息,共同完成项目。//用户体验协商:自动“适配”你的设备和需求

Agent之间传递的消息,允许客户端和远程代理协商所需的正确格式协商。假设消息是一个“智能快递箱”:每个箱子里装着不同类型的包裹(文字、图片、视频等),并且贴了明确的标签(比如“4K视频包裹”“医疗CT扫描件”)。当快递员(远程代理)送货时,会和收件人(客户端代理)商量:“您家门口的智能快递柜有高清屏幕吗?我带的这个3D模型包裹需要AR眼镜才能拆封,如果没有我就转换成2D平面图”。

这种对话机制让双方能根据用户设备自动调整内容,比如:

  • 如果用户用手机访问,可能优先显示简洁的图文;
  • 如果用电脑,可以展示复杂的表格或视频。
  • 如果用户设备支持iframe(嵌入网页),就用它展示动态内容,否则换成静态图片。

就像你点外卖,App会根据你的手机屏幕自动调整图片大小,或根据你的偏好推荐“少辣”选项。

整体的运转逻辑,谷歌还在官网放出了一个通过 A2A 协作,招聘软件工程师的案例。

在 Agentspace 这样的统一界面中,用户(例如招聘经理)可以委托其代理寻找符合职位列表、工作地点和技能要求的候选人。然后,代理会与其他专业代理互动,以寻找潜在候选人。用户收到这些建议后,可以指示其代理安排进一步的面试,从而简化候选人寻找流程。面试流程完成后,可以联系另一位代理协助进行背景调查。

目前有50多家企业都支持了A2A,都是各个领域如雷贯耳的存在。不过OpenAI和Anthropic不在其中。

二、A2A+MCP

纵横交错构成完整Agent生态不可避免地会将A2A与MCP联想,两者是竞争替代还是不同的技术路径?谷歌自己回答是互补,“智能体应用需要 A2A 和 MCP。我们建议工具使用 MCP,代理使用 A2A”。

事实上,两者的确各有侧重。如果解决一个问题需要一个团队,MCP解决的是纵向上的单个Agent知识深度和工具丰富度,提升员工能力上限;A2A解决的是横向上多Agent协同办公,让不同工种协同作战。

可以说MCP是赋予智能体“生存技能”,A2A则是教会它们“社会化生存”。两者交叉,极大程度上完整了大家对Agent运转逻辑的想象,不少人甚至把今年称为Agent的元年。

具体来看👇

MCP的核心价值在于消除工具使用的认知壁垒 。传统AI系统需要开发者明确告知“遇到Excel文件时调用表格处理函数”,而MCP让智能体通过图标、界面布局等上下文信息自主关联工具——就像人类看到螺丝刀自然联想到拧螺丝。这种能力使得单个智能体能够快速适应新环境,例如在从未接触过的企业系统中,依然能通过观察界面元素推测出“提交按钮”的功能。

而A2A的突破在于构建智能体间的协作网络 。它不关心单个智能体如何完成任务,而是定义了一套群体协作的规则:如何发现队友、如何分配任务、如何同步进度。这类似于人类职场中的分工体系——设计师不需要懂代码,只需向工程师说明需求;法务专员不必理解算法,但能快速审核合同条款。当MCP让每个智能体成为“多面手”,A2A则让它们学会在群体中找准定位,通过互补形成超个体能力。

不过。这里产生一个问题——为什么不能一个Agent调用所有server?就像把所有人的技能都加在一个人身上一样?

试图让单一Agent直接调用海量MCP服务是不现实。如同要求一名工程师同时精通芯片设计、建筑力学和分子生物学——看似全能实则低效臃肿。A2A通过引入专业Agent层实现能力解耦:每个专业Agent如同垂直领域的“技能胶囊”,封装特定领域的MCP调用逻辑(如税务计算Agent内置全球税法数据库接口)。

当用户需要跨国财报分析时,综合Agent只需向“财务专家Agent”发起请求,后者自动调度底层的汇率转换、税法解析等MCP服务,最终返回精炼结论。这种分层设计既避免了综合Agent陷入API调用的泥潭,又让专业Agent能持续优化垂直场景的效能(如缓存高频数据、预加载行业模型),本质上是用软件工程的模块化思维,将“万物互联”的愿景转化为可落地的协作拼图。

但两者之间有交叉的地带,A2A 和 MCP 在一起采用的时候,Remote Agent 同时扮演还MCP 的 Host/Client,如果把所有的 Agent 都当做是 MCP 的 Host/Client,是否MCP一种协议也能完成所有的协同?

对于相对简单的任务的确如此,但谷歌在官网中也有介绍,A2A更擅长长期复杂任务,没个两三天搞不定的那种,这种就依赖于Agent之间的相互通信。

API:别争了,我觉得你俩都是我的子集

三、当软件“活”过来:从工具到同事

MCP+A2A的意义远不止于此。以一家跨国电商为例,当销售部门的智能体发现某个爆款商品库存告急时,它能通过A2A自动调用仓储系统的物流智能体计算补货周期,同时联动人力资源智能体调整客服排班。整个过程无需预先设计接口,而是基于动态的任务协商。

这本质上带来的想象是,A2A与MCP的叠加效应,或许引发整个软件工程的体系化变革——功能不仅仅是调用,现在需要协商——任务委托给智能而非软件。

在传统开发中,功能实现依赖预先编写的逻辑链条——如果用户点击A,则触发B,再跳转到C。但智能体生态下,软件的行为由实时协商决定。以客服系统为例,当用户抱怨物流延迟时,智能体可能自主组合“情感分析→运单追踪→赔偿政策查询→工单生成”的流程,甚至调用外部法律顾问智能体评估风险。这种动态工作流的背后,是MCP提供的工具泛化能力与A2A支持的资源调度能力的深度融合。

这种转变对开发者提出了全新要求。过去我们编写代码,现在我们需要定义智能体的能力边界与协作规则 。例如物流智能体只需声明“我能预测运输时效(误差率<3%)”,而无需暴露路径优化算法;设计智能体可以公开“支持3D建模渲染”,但隐藏GPU资源占用的细节。这类似于人类社会的专业分工——我们不需要知道厨师如何控制火候,只需相信他能端出美味菜肴。

这不仅是技术的迭代,更是认知的升级。开发者需要学会像“团队管理者”一样思考——不是事无巨细地控制每一步操作,而是设定目标、建立规则、培育协作文化。未来的软件系统或许不再有“最终版本”,而是像生物体一样持续进化。当某天,你的智能体同事主动建议优化代码架构时,请不要惊讶——那只是这个新时代的日常。

当然,状态管理、推理开销导致的资源消耗以及授权和可审计性等等复杂问题,都要重新看待了。

不过,这能阻挡一个完美Agent生态建成吗?

本文由人人都是产品经理作者【鹅厂技术派】,微信公众号:【鹅厂技术派】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。