上个月我在整理智能体方案时遇到一件很微妙的事我的本地知识库助手能把公司产品手册逐层问到最细但当我让它“把这份采购清单发给供应商的AI客服助手”时它只能回我一句“我没有办法访问外部助手”。这句话听起来像一句小抱怨其实是现在所有AI助手的缩影——每台AI都很聪明但彼此之间不讲话。A2A协议Agent-to-Agent Protocol智能体到智能体协议想改变的正是这件事。它由Google在2025年4月联合Salesforce、SAP、Cisco等五十多家公司提出目标是给AI助手之间定义一套通用的“对话与协作语言”让它们能像网页通过HTTP互相链接一样从一个个信息孤岛连成一张智能体互联网。这篇文章我打算从协议机制、与MCP的关系、落地场景和个人实践四条线把“孤岛走向互联网”这件事掰开讲清楚适合正在做智能体开发、做AI产品规划或者单纯想知道AI助手们以后怎么互相配合的读者。1. AI助手为什么会活成一座孤岛1.1 现在的智能体更像“单机游戏”当前市面上能看到的AI助手本质上都是一个又一个闭环系统用户输入问题LLM在上下文窗口里做推理然后调用挂在自己身上的工具、检索库和记忆模块最后把答案输出回来。这个过程可以做得非常漂亮——比如用扣子搭建一个带知识库的助手或者在企业内部署一个RAG检索机器人它们在单点场景里表现得像专家但前提是所有原料都必须在它自己的闭环里。问题来了。不同团队、不同厂商构建的这些闭环互相之间既不知道对方的存在也没有一套通用的交换语言。你现在让ChatGPT去调用一个部署在自家内网里的财务智能体或者让一个客服机器人把工单转给另一个公司的售后智能体基本上都得靠人肉搬运。这不是模型能力不够而是系统之间缺一张通用的“连接协议”。我把这种现象叫“单机智能”每个助手都很聪明但它的聪明是局域网式的聪明出了自家边界就断连。1.2 孤岛的三种形态数据、能力、信任如果细拆一下AI助手的孤岛问题可以分为三层理解这三层对你判断A2A的价值非常重要。第一层是数据孤岛。每个助手只拥有自己Prompt窗口和向量库里那点东西另一边的数据库、知识库、业务日志对它来说完全是黑盒。你让一个客服助手去查物流信息它查不到不是因为不知道物流系统的API地址而是没有任何通用机制告诉它“物流助手存在且可以提供查询能力”。第二层是能力孤岛。这个更明显。A助手接了财务APIB助手接了仓储APIC助手接的是人力资源系统它们各自都是某个领域的“单臂超人”。但因为能力都长在自己身上A没法把活儿委托给B。哪怕B做退款审核更专业A也只能对用户说“抱歉”。第三层是信任孤岛。即便两家公司愿意开放接口你依然需要一个机制来确认“对方是谁、它能做什么、它做这件事有没有得到用户授权、中间的过程能不能审计”。这一层如果不解决跨组织的智能体协作根本走不到线上。1.3 只靠暴露API解决不了智能体互通很多人的第一反应是“那我把每个智能体的能力包装成REST API不就行了吗”可以但只解决了一小半。REST API解决的是“程序调用程序”的问题它要求调用方预先知道接口路径、参数结构、鉴权方式而且通常是一问一答的同步模式。真实世界里的智能体协作完全不是这样对方的服务在哪个地址它支持哪些能力托管任务之后要跑很久怎么办中途需要人工补充信息怎么办结果以什么格式返回这些REST API都没有统一答案。所以我们需要一个更上层的协议它要负责智能体的发现、能力描述、任务下发、进度跟踪、结果传输和权限校验。A2A就是冲着这套需求来的。如果说HTTP是“网页的公共语言”那A2A想当的就是“智能体的公共语言”。有了它AI助手才第一次有可能从单机游戏变成联网游戏。2. A2A协议到底改了什么核心机制拆解2.1 Agent Card一份让智能体“自我介绍”的本领清单想在互联网上被其他人找到第一件事是让全世界知道“你是谁、你有什么”。A2A给出的方案叫Agent Card它本质上是一份JSON格式的“智能体名片”由每个智能体自己维护并暴露出去。我摘一段简化过的Agent Card结构直观感受一下{ name: 退货助手, description: 处理退货申请、判断退货资格、协调快递揽收与退款, url: https://agent.example.com/ap, capabilities: { streaming: true, pushNotifications: true, stateInteractions: true }, skills: [ { id: refund-eligibility, name: 退款资格判断, description: 根据订单状态、商品类型和售后政策判断是否可退款, tags: [retail, refund] } ], security: { schemes: [oauth2], credentials: ... } }第一部分是身份与描述告诉别人“我叫什么、我是干嘛的”第二部分是能力声明列出这个智能体支持哪些技能第三部分是通信参数比如是否支持流式推送、是否需要状态交互最后是安全策略说明调用它需要什么级别的认证。这个设计让我想到Web世界里的两个东西一个是DNS负责让别人知道你存在另一个是robots.txt负责告诉搜索引擎你能被抓取哪些页面。Agent Card把这两件事合并到一起相当于每个智能体都在互联网上挂了一块自己专属的“招牌”。没有它智能体之间连“发现”都做不到。2.2 Task生命周期从“一问一答”到“长跑协作”A2A与普通HTTP请求最不一样的地方在于它把“任务”作为一等公民。一个智能体向另一个智能体发起协作不是在等一个即时的响应而是创建了一个Task然后这个Task会经历一个明确的状态机。我在自己的demo里观察到的任务状态流转大概是这样的submitted已提交→ working处理中→ 可能进入input-required需要补充信息→ 最终到completed完成或failed失败→ 也可以被canceled取消。为什么要设计这么重的状态机因为AI协作任务压根不是“问一句答一句”的事。举个典型例子你的财务智能体想让审计智能体审核一笔报销后者可能需要调用内部系统、需要等待人工确认、甚至要花好几个小时才能给结论。如果协议只支持同步请求那调用方就只能干等期间一个网络抖动就全完了。有了Task状态调用方可以随时查询进度也可以接收推送通知双方对“工作到底进行到哪一步”始终有一致的认知。这就像你在电商平台下单后能看到“已下单—已发货—运输中—已签收”一样任务的每一步都被协议显式化智能体之间才能形成真正的协作关系而不是靠猜。2.3 消息、工件与流式推送A2A在传输什么接下来是传输层。A2A抽象了几种核心对象理解它们就理解了协议在“传什么”。Message是两者之间传递的非结构化信息可以是一段自然语言也可以是一条命令Task是上一条说过的状态化任务Artifact是任务完成之后产出的结构化结果可能是一个文件、一段JSON、一个链接Part则是消息和工件里的具体内容片段用来承载文本、图片、结构化数据等各种类型的载荷。这一套设计让我感觉A2A不只是在做一个“接口”而是在做一个“协作工作台”。它允许接收方在执行过程中持续往外面吐Part调用方通过流式推送或轮询获取这些中间结果。比如一个做市场调研的智能体它可以先把“已经采集到的渠道数据”推送给发起方再慢慢跑最终报告而不是憋到最后一次性给出结果。对开发者来说这意味着你可以做出更可视化、更可干预的智能体协作流程。值得单独提一句的是A2A支持多种传输方式包括HTTP和SSEServer-Sent Events也支持webhook回调。SSE的好处是连接成本低、断线重连逻辑简单很适合大模型那种“逐字输出”的消费习惯。我实际测试下来用SSE推送任务状态比短轮询要舒服得多几乎没有多余的网络开销。2.4 安全设计跨系统对话的信任底线跨组织的智能体通信安全绝对是第一关。A2A目前的安全设计分几层首先通信层要求TLS防止中间人窃听其次调用方和被调用方通过OAuth2等标准机制做双向身份认证也就是说不止调用方要证明“我是谁”被调用方也要证明“我是真的那个服务”第三任务和工件可以携带出处信息支持审计追踪最后用户授权仍然是最高优先级所有涉及敏感操作的调用都必须回到“用户是否同意”这条线上。我自己的理解是A2A并没有尝试解决“该不该授权”这个问题它解决的是“在已经授权的前提下怎么安全地把任务和结果传过去”。跨系统信任始终是一个业务问题协议只能提供工具。这就好比邮件协议本身不判断你该不该给某人发机密文件但它能保证信封是密封的、邮路是加密的。3. MCP和A2A别搞混一个管工具一个管“打电话”3.1 两者到底解决什么问题A2A发布之后我见过最多的误区就是把A2A和另一个热门协议MCP放在对立面甚至有人觉得“有了A2A就不需要MCP了”。这完全是搞错了位置。MCPModel Context Protocol是Anthropic主导发起、后来由Linux基金会托管的协议它解决的核心问题是“LLM应用如何统一接入外部工具和数据源”。你可以把MCP理解成智能体的“外设接口”它让模型能够去调用本地文件、数据库、各类API就像电脑通过USB接口插上键盘、鼠标、打印机。A2A则完全不同它解决的是“两个智能体之间如何协作”对应的一句话是“你去做这件事做完把结果给我”。把两者放在一张表格里对比会更清楚维度MCPA2A发起方LLM应用/智能体智能体接收方工具/数据源另一个智能体核心动作调用工具、读取资源创建任务、跟踪状态、交付结果典型协议元语Tool、Resource、PromptTask、Message、Artifact类比让Agent“伸手够到”外部能力让Agent“开口委托”另一个Agent代表人物/组织Anthropic发起Linux基金会托管Google发起多厂商联合从这个角度看MCP和A2A根本不是竞争关系而是不同层级的互补关系。MCP管的是“手”A2A管的是“嘴和耳朵”。一个智能体完全可以用MCP调用它自己的工具库然后用A2A把处理结果委托给另一个智能体。3.2 双栈架构的实际形态那在实际工程里两者怎么搭配我建议你想象这样一个企业内部架构每一个智能体都通过MCP把自己需要的业务系统接进来——比如财务智能体通过MCP读ERP系统客服智能体通过MCP读订单库——这是它的“内部数据总线”。然后每个智能体再提供一个A2A端点把自己的核心能力开放给公司内外部的其他智能体调用。这个A2A端点就像一个“对外服务的窗口”别的智能体不需要知道它内部到底用了什么工具只需要通过Agent Card发现它、创建Task、接收结果。这种双栈架构在工程上非常清晰MCP是内部集成层负责搞定“智能体和数据之间”的问题A2A是互联层负责搞定“智能体和智能体之间”的问题。我用官方SDK实际搭过一遍流程整条链路跑通之后最大的感受是MCP把每个智能体的“底座”做扎实A2A把每个智能体的“边界”做开放两者缺一个都不完整。3.3 为什么不是零和博弈还有朋友担心MCP和A2A背后站着不同公司最后会不会变成两套生态打来打去开发者选错边就完蛋。以我现在看到的行业动向来说这种担忧基本可以放下。两家协议都在往开放标准的方向走MCP进入了Linux基金会A2A也在推进多厂商共同参与两者的社区讨论方向本身就有大量交集。更关键的是你细看技术设计就会发现它们没有重叠的部分。MCP解决“一个实体怎么控制自己的工具”A2A解决“多个实体怎么交换任务”这本来就是同一套智能体系统里缺一不可的两个组件。对普通开发者来说现在最不应该做的是押注某一方而是把两边都试一遍理解各自的边界。实际项目里大概率是两套都要装内部靠MCP整合工具外部靠A2A做开放协作。4. 实际推演哪些场景现在就能试水哪些还很远4.1 企业内部最容易先跑通A2A最容易落地的地方其实不是跨公司而是企业内部。原因很简单同一个公司里网络是通的、账号体系是统一的、安全和审计规则是现成的你只需要解决“两个智能体怎么互相派活”这一个技术问题。我设想过一个很现实的场景销售智能体收到一个客户合同它发现自己没有法律条款审核能力于是通过A2A把这个任务发给法务智能体。法务智能体跑完审核返回一份带批注的结果和“可签约/不可签约”的结论。整个过程里两个智能体各自只做主业务不需要把对方的全栈能力都长在自己身上。这种场景在传统做法里需要写大量胶水代码每次新增一个智能体就要重新对接一次。用A2A之后法务智能体只需要维护好自己的Agent Card其他智能体就能自动发现它、调用它新增接入成本几乎为零。我个人认为这就是A2A现阶段最大的价值所在。如果你想自己验证我建议用Google开源的A2A SDK搭一个最小化demo。官方提供了Python、Java、Node.js等语言版本照着示例代码先在一个服务里启动一个“被调用的智能体”再在另一个脚本里作为客户端发起一个Task观察任务状态从submitted走到completed整个流程半小时内就能跑通。跑通之后你才会真正理解“任务状态机”和“Agent Card”这两个设计到底有多重要。4.2 跨企业协作真正的硬骨头是信任问题跨企业场景比内部要难一个量级。举个例子用户的AI助手发现商品有问题想直接对接电商平台的退货智能体退货智能体又需要把快递揽收任务发给物流公司的智能体最后把退款任务发给支付平台的智能体。这个链条听起来很丝滑但每一环都涉及同一个问题凭什么一个外部智能体可以替一个用户发起退货退款额度怎么控制出错了谁能负责A2A提供了传输层面的安全但它不负责定义“业务层面的授权闭环”。也就是说协议能帮你传递一个“已确认的用户授权”但“这个用户是否真的有权利退货”“退货金额上限是多少”这类问题必须由业务系统自己管。所以我的建议非常明确跨企业的A2A协作现在最适合切入的是一类低风险操作——只读查询、状态查询、公开信息的获取。比如你的AI助手去问另一个公司的物流智能体“这个订单现在到哪了”这种场景试水成本低、出错影响小。而真正涉及资金、合同、个人隐私的高风险操作等安全和责任体系更成熟了再说别抢跑。4.3 现在的开发者和产品经理能做什么如果你看完前面这些觉得A2A值得关注但又不知道从何下手我给你三个最小动作。第一选一个“外包型”的流程。注意这个流程得满足一个核心条件它原本就需要跨系统协作而且是弱耦合、低风险的。比如“让另一个智能体查一个公开状态”“让另一个智能体生成一份初稿”。不要一上来就把核心交易流程改成A2A否则出了问题你会被坑得很惨。第二给你的智能体写一份Agent Card。这一步看起来简单实际上很考验你对业务的抽象能力。你写“我能查订单状态”和写“我能根据用户角色和订单类型返回对应的物流节点与预计送达时间”对外部智能体的可用性完全是两回事。描述越具体其他智能体就越容易在它的任务里把你找出来。第三保留传统的REST API作为降级通道。A2A不可能一上来就覆盖所有场景你在实验阶段一定要留一条“实在不行直接调接口”的路。我见过不少团队在试新协议时忘了做降级设计线上出问题时只能干瞪眼。5. 关于标题问题的回答会但路径和想象中不太一样5.1 从孤岛到互联网不是“连接所有AI”而是“暴露最小接口”回到标题这个问题A2A协议会让AI助手从“孤岛”走向“互联网”吗我的答案是会但它不会是你想象的那种“所有AI助手连成一个超级大脑”。真正的互联网没有一个中心节点网页与网页之间通过HTTP互相链接每一个站点依然保持着自己的边界、自己的数据、自己的规则。A2A想推动的智能体互联网也是这样每个AI助手依然是独立的但它在边界上会长出一张“名片”和一套“协作语言”让其他智能体能发现它、理解它、委托它。从这个意义上说A2A在做的事和HTTP当年的角色几乎一样。HTTP没有让所有网站变成一个网站但它让网站与网站之间第一次有了公共的链接语法A2A也不是要让所有智能体变成一个智能体而是让它们之间第一次有了公共的任务流转语法。这才是“从孤岛到互联网”的正确理解方式。5.2 我在实验里学到的三件事在本地搭完一轮A2A实验之后我有几个很个人的体会。第一真正的瓶颈不在协议实现而在“能力描述”。写Agent Card的时候你会被迫回答一个以前从来没想过的问题我的智能体到底能做什么、边界在哪、需要什么权限。这件事比写业务代码难得多因为它要求你对系统做一次完整的自我审视。第二Task状态机不是多余的。以前做系统对接我最怕的就是“请求发出去了然后呢”这种真空地带。A2A把任务状态显式化之后调试体验好了很多——你可以清楚地看到任务卡在哪个环节是等待输入、还是处理失败排查问题的效率直接翻倍。第三和本地模型助手的结合会很有意思。现在的趋势是把大模型部署到本地形成私有的知识库助手。这类助手一旦支持A2A服务端就可以变成一个“只接收任务、不出门”的私人秘书外部智能体只能通过协议向它发起请求但拿不走数据。这可能是个人AI从“平台孤岛”变成“自愿联网”的关键一步。5.3 最后给你一个自测参考如果你现在想跟上这波趋势我建议你直接动手做一个最小实验让一个智能体A通过A2A调用一个智能体BB执行完一个固定任务后把结果作为Artifact返回给A。你不需要一开始就上复杂场景重点是体验一遍“发现Agent Card—创建Task—查询状态—接收结果”的完整链路。做完这个实验你再回头问自己三个问题我的系统里有哪些原本需要人工搬运的智能体协作这些协作里哪些是低风险可以直接试水哪些流程值得写成Agent Card开放能力想明白这三点你就不会再被“协议热度”裹着走了。我个人对A2A的判断很简单它的技术门槛没有想象中高真正的变量始终是业务信任。协议能把每一个AI助手都变成互联网上的一台“服务器”但决定这台服务器能不能被别人调用、能调度到什么程度的仍然是你的业务流程和授权机制。所以与其问“A2A会不会让AI助手从孤岛走向互联网”不如问一句你愿不愿意先在自己最不起眼的一个流程里尝试着打开那扇门。