这几天微信被曝正在测试「小微对话小微」：你让自己的 AI 助手去联系好友的 AI 助手，两个 AI 先聊、关键决策再找你拍板。很多人第一次意识到，原来 AI 之间可以直接对话、互相办事——这件事在技术圈有个专门的名字，叫 A2A（Agent-to-Agent，智能体对智能体）。
那 A2A 协议到底是什么？它解决什么问题？和这两年大火的 MCP 是什么关系？今天这篇就把 A2A 讲透：它怎么让 Agent 互相发现、怎么交接任务、什么场景真用得上，以及落地时要注意什么。
A2A 是什么：给 Agent 之间定的「协作普通话」
先说背景。现在市面上的 AI Agent 越来越多，但它们大多互不认识：你用一个框架搭了个客服 Agent，隔壁团队用另一个框架搭了个订单 Agent，两个 Agent 想合作，却发现连「怎么打招呼」都没有统一方式。A2A 就是来解决这个问题的——一套开放的、跨框架、跨厂商的智能体通信标准，让一个 Agent 能发现另一个 Agent、把任务委托给它、再拿回结果。
A2A 最初由 Google 提出，2025 年 6 月捐给了 Linux 基金会托管，之后 AWS、微软、Salesforce、SAP 等一票大厂都进了技术委员会。咱们站之前报道过 A2A 迁入 Linux 基金会 的细节。可以这么理解：如果说每个 Agent 都讲自己的「方言」，A2A 就是大家约好的一口「普通话」——不关心你内部怎么想，只要按标准开口，彼此就能听懂。
三个核心概念：Agent Card、任务交接、上下文
A2A 协议里最核心的三个概念，用大白话解释：
Agent Card（能力名片）。每个想被协作的 Agent 都要公开一张「名片」——一份 JSON 文档，写清楚自己叫什么、是干嘛的、支持哪些能力、怎么联系。名片一般放在固定路径（/.well-known/agent.json），别的 Agent 想找你合作，先来读你的名片，判断你靠不靠谱、能不能干这活。这就像加微信先看对方头像和签名，只不过格式是机器可读的。
Task（任务交接）。A2A 里 Agent 之间传递的不是一句「帮我查个数」，而是一个正式的「任务」：委托方把目标、要求和上下文打包成任务发给对方，对方用自己的模型、自己的工具独立处理，再返回结果。委托方不干预对方内部怎么干活——这也是 A2A 和普通 API 调用最本质的区别：你委托的是「一件事」，而不是「一次函数调用」。
多轮上下文。真实协作往往不是一问一答。A2A 支持用上下文标识把多轮对话串起来，让被委托的 Agent 记得前面聊到哪，支持长任务和复杂协作，不会每轮都像失忆一样重来。
A2A 工作流程：发现、委托、执行、回报
一次典型的 A2A 协作分四步：发现——委托方读目标 Agent 的 Agent Card，确认能力和地址；委托——创建 Task，把要做的事连同上下文发过去；执行——对方独立干活，遇到长任务会回报进度状态，而不是让你干等；回报——完成后把结构化结果交回来。整个过程任务状态清晰、可追踪，任务失败也能明确知道卡在哪一步。这套「任务状态跟踪 + 结果回报」的设计，和我们站上讲过的 AI Agent 长时任务 设计思路完全一致：别让 Agent 黑箱跑到底，过程要可查、可恢复。
A2A 和 MCP 的分工：一个管工具，一个管 Agent
这是大家最容易混的地方。一句话总结：MCP 是让 Agent 连上工具，A2A 是让 Agent 找到 Agent，两者是互补关系，不是竞争关系。
MCP（Model Context Protocol）解决的是「Agent 怎么调用外部工具和数据」——把文件系统、数据库、各类 API 标准化成 Agent 能调用的工具，业界爱叫它「AI 的 USB-C 接口」。咱们站之前有篇 OpenClaw 怎么接 MCP 工具 的教程，讲的就是怎么让 Agent 接上企业微信这类服务。
A2A 解决的是更高一层的问题：「一个 Agent 怎么把整件事外包给另一个 Agent」。对方是独立智能体，有自己的推理和工具，对你来说是「黑盒」——你只管委托和验收。打个比方：MCP 是你自己动手拧螺丝用的螺丝刀标准接口；A2A 是你把装修整个外包给施工队，施工队内部用什么工具你不管，你只看交付。
两者经常配合使用：一个 Agent 对内用 MCP 连自己的工具和数据，对外用 A2A 和其他 Agent 协作。这也是 A2A 官方文档反复强调的——「MCP 给 Agent 配工具，A2A 让 Agent 组团队」。想深入理解工具调用这层机制，可以先看 Function Calling 工具调用机制 这篇打底。
什么场景才真用得上 A2A
不是所有 Agent 协作都要上 A2A，判断标准看两条：对方是否需要独立判断——只是取个数、查条记录，用 MCP 或普通 API 就够了；需要对方结合自己的专业能力做推理、出结论的，才值得走 A2A。是否需要跨团队、跨系统——自家几个 Agent 配合，用你框架自带的 多 Agent 配置 或编排逻辑就行；要和外部门、外部公司的 Agent 协作，才需要 A2A 这种开放标准。
典型场景包括：跨企业的供应链协同（订单 Agent 找物流 Agent 查进度）、招聘流程（筛选 Agent 委托背景调查 Agent）、复杂服务编排（客服 Agent 把账单问题转给专业账单 Agent）。这些场景的共同点：对方是独立运营的智能体，需要保留自己的判断和工具，还要能处理长任务和上下文。
落地进展与现状
A2A 从标准走向产品已经能看到几个信号：一是 Linux 基金会托管后生态快速扩张，微软 Copilot Studio 等产品已支持接入 A2A Agent；二是国内微信被曝测试「小微对话小微」——用户让小微去联系好友的小微，这本质就是把 A2A 的「Agent 代表用户去对接另一个 Agent」做进了国民级应用；三是各类 Agent 平台开始把 A2A 当默认能力开放。协议标准层已经就绪，真正的变量在「谁愿意开放自己的 Agent 给别人调」。
注意与局限：别把黑盒当保险箱
A2A 落地有三个点要提醒：信任问题——被委托的 Agent 是黑盒，能力名片上写的未必都靠谱，重要任务建议先小范围试跑再全量委托；安全边界——委托出去的任务内容和上下文可能包含敏感信息，对方 Agent 的安全等级你控制不了，传输和授权要按 提示词注入防护 的思路设防，别让恶意 Agent 借协作之名套你的数据；责任归属——两个 Agent 协作出了问题，算谁的？委托关系、结果验收、留痕审计都要提前约定清楚，这也是 AI Agent 证据包 里强调的：过程留痕，复盘才有据可依。
优缺点与适合人群
优点：打破平台壁垒，不同框架的 Agent 能组队干活；任务级委托让协作更灵活，被委托方能发挥自己的专业能力；开放标准意味着生态越滚越大。缺点：协议还年轻，生产级实践在积累中；跨组织协作的信任和合规没有银弹；对简单场景而言是杀鸡用牛刀，引入额外的通信和状态管理成本。
适合：做跨系统、跨组织 Agent 协作的团队；想把自己的 Agent 能力开放出去当「服务」的团队；关注智能体生态演进的产品和技术负责人。不适合：只是想让自家几个 Agent 配合干活的场景——那种先用好你框架自带的多 Agent 能力，别急着上协议。
总结
A2A 协议就是给 AI Agent 之间定的「协作普通话」：用 Agent Card 互相发现，用任务交接来委托，用多轮上下文保持连贯，让不同框架、不同厂商的智能体能真正组队干活。记住它和 MCP 的分工就够用了——MCP 让 Agent 连上工具，A2A 让 Agent 找到 Agent，一个管手脚、一个管社交。微信把 A2A 概念做进大众产品，说明智能体互联不再是实验室话题。对做 Agent 的我们，现在就该想一个问题：如果你的 Agent 明天要被别人的 Agent「委托干活」，你的能力名片准备好了吗？
