你们有没有过这种经历电脑里开着七八个软件每个软件都像一个独立王国——Chrome 里查资料Notion 里做笔记Gmail 里收发邮件本地 Python 脚本做数据处理再手动把结果粘回来。偶尔偷懒写个自动化也要处理接口文档、鉴权、回调折腾半天。最近我盯上一个谷歌开源在 GitHub 的项目5 天拿了 2 万 Star热度高得离谱。它倒是直接切中了我这个痛点也让我对“未来软件的形态”有了一个非常具体且可触摸的判断。这个项目是谷歌开源的Agent2Agent 协议A2A一套用于 AI 代理Agent之间互相发现、通信和协作的开放协议。简单说它想让智能体像人一样交换名片、分派任务、汇报结果。作为一个常年写业务代码、也折腾过不少 AI 工具的工程师我第一时间 clone 下来跑了一遍。这篇文章打算讲清楚三件事这个项目到底解决了什么问题手把手怎么跑通一个真实协作流程以及为什么我认为它代表下一代软件的组织形态。1. 两万 Star 在欢呼什么先认识这个谷歌开源项目1.1 Agent to Agent 协议要拆掉的墙不同软件之间的数据协作到今天还停留在“人工搬运”和“API 对接”两个阶段。人工搬运是常态API 对接则需要为每一个服务写适配代码——A 系统的数据结构、B 系统的鉴权方式、C 系统的限流策略全是定制活。过去我们做“软件集成”本质是在做“翻译器”把两个互不认识的产品硬拽到一张桌子上。A2A 想做的事情很直接给 Agent 之间定一套通用语言和交互流程。Agent 不需要提前认识对方不需要知道对方的数据库结构只要双方都实现 A2A 协议就能完成“发现能力 - 派发任务 - 回报结果”这条完整链路。谷歌把它做成开放协议这意味着不管 Agent 是谷歌的还是微软的、是云端大模型驱动的还是本地小模型跑的都能在同一套规则下协作。举个例子。你有一个内部客户支持 Agent一个日程管理 Agent一个邮件 Agent。以前要让它们协同处理“客户投诉并安排回访”你得自己写一个编排服务去拉不同 API。有了 A2A支持 Agent 可以直接“点名”日程 Agent 创建回访时间再让邮件 Agent 发确认信。整个过程里编排逻辑本身成为另一个 Agent而不是一把硬编码的“胶水代码”。1.2 MCP 解决了 Agent 连工具A2A 解决 Agent 连 Agent研究 A2A 的时候很多人会拿它和 Anthropic 提出的 MCPModel Context Protocol对比。我的理解是两者根本不在一个层。MCP 解决的是Agent 和工具/数据源之间的连接问题相当于给 AI 世界设计了一个 USB-C 接口让模型能标准化地调用搜索、数据库、文件系统这些工具。A2A 解决的是Agent 和 Agent 之间的连接问题类比的话更像两台电脑之间的“局域网协议”直接让设备与设备对话。用一个生活化的场景来区分。用 MCP你可以让一个 Agent 自己去查航班 API、自己去锁座但你想让“查航班的 Agent”把结果交给“订酒店的 Agent”再交给“安排日程的 Agent”MCP 就管不了这一段。Agent 之间没有标准的通信协议只能通过一个中心调度器手动流转上下文。A2A 的定位恰恰是这段。它不关心 Agent 内部是怎么调用工具的那边交给 MCP它只定义 Agent 与 Agent 之间如何交换任务和结果。所以两者不是竞争关系而是错位互补。对比项MCPA2A解决的核心问题Agent 连接工具、数据源Agent 连接 Agent类比AI 世界的 USB-C 接口设备之间的局域网协议交互方向单向模型向工具发出调用双向代理与代理协商协作典型场景Agent 搜索网页、写数据库、操纵软件多个 Agent 联合完成跨业务域任务标准化程度已在生态内广泛铺开仍在快速迭代但已开源并有多方支持我身边很多人有一个误区觉得既然 AI 模型已经很强了工具协议都会慢慢消失。实际恰恰相反模型越强它越需要一个干净利落的方式来“指挥”工具和“沟通”同类。A2A 补上的正是后一块拼图。2. 为什么说软件要从“应用 API”走向“代理 协议”2.1 Agent Card让软件学会自我介绍A2A 给我最大的启发不是技术实现而是它定义“软件对外能力”的方式。在 A2A 里每个 Agent 都要提供一个公开的Agent Card本质是一个 JSON 文件里面写着这个 Agent 的名称、描述、服务地址、能力清单、技能细节等信息。客户端一开始不关心对方是什么系统、什么编程语言、什么部署方式只拉取这个 Agent Card就知道“这个代理能帮我做什么、该怎么找它”。这就像面试时交换名片名片上写清楚你的岗位和擅长领域。过去调用第三方能力你得看几十页 API 文档A2A 之后AI 自己会看“名片”然后根据名片上的信息直接发任务。这种自上而下的能力发现机制对软件形态的影响远比我们想象的深。Agent Card 的字段并不复杂。它包含 name代理名字、description描述用于让另一个 AI 理解它的用途、url服务端点、version协议版本以及 skills 这样的能力声明。客户端会像人读简历一样读取并筛选出最适合完成当前任务的 Agent。这个过程让我想起早期互联网的 robots.txt 和 OpenAPI 规范的结合体只不过这次“读者”从人变成了 AI 代理。2.2 任务生命周期一次跨软件协作是如何被执行的光有名片还不够两个 Agent 真正协作时需要一套完整的状态机来追踪任务进展。A2A 定义了 Task 的概念一个任务在生命周期里会经历 submitted已提交、working执行中、input-required需要更多信息、completed已完成、failed失败、canceled取消等状态。这套设计非常工程化。一次跨 Agent 调用不是简单的“我发请求、你回响应”而是“我提交一个任务 - 你给出任务 ID - 我轮询状态或等待回调 - 你完成后返回结构化结果”。长耗时任务的支持尤其关键一个 Agent 要去查一个复杂报表可能得跑几分钟甚至更久客户端不能抱着连接干等。A2A 允许服务端通过回调机制在完成后通知客户端和现代异步 API 的设计思路如出一辙。我在实测里真真切切感受到这个流程客户端读取 Agent Card 后经由 POST 请求创建任务Agent 校验输入、执行内部逻辑、在可交互节点上请求用户补充信息最后把回复组织成 result 返回。状态机全程透明开发者可以在任意阶段介入而非只能悄悄等着超时。对需要多人协作或者多代理编排的业务场景这种“把过程显式建模”的方法比黑盒 API 要可靠很多。2.3 三个信号为什么说这是未来软件形态第一个信号来自行业巨头的动向。Anthropic 带头推 MCP谷歌连续开源 A2A 和配套 SDKOpenAI 也在自己的生态里做 Agent 互联能力。你发现没有大家拼命定义“协议”而不是只做应用闭环说明所有人都认识到未来 AI 软件必然要跨服务商协作谁能定义标准谁就占据生态入口。第二个信号是端侧工具开始习惯“Agent 意识”。最近一些热门搜索词里出现了“谷歌浏览器扩展设置中启用 mcp 连接”以及“claude code 怎么手动装 github 上的 skills”这类问题意味着普通用户已经开始接触 AI 代理与工具之间的连接配置。以前这些词只有服务端开发者关心现在下沉到了浏览器插件、个人配置层面。这说明代理互联正从基础设施走向普通人的日常操作。第三个信号就是 A2A 项目本身的星标速度。在开源圈里5 天 2 万 Star 已经不是一个普通工具能达到的量级。大量开发者疯狂涌入说明大家看到了同一件事软件这东西正在从“一个应用 一堆 API”的形态转向“一群 Agent 一套协议”的形态。之后很长一段时间真正的软件生态很可能不再围绕屏幕上的功能按钮转而是围绕“代理能力”转。3. 跑通 Agent 协作的完整实操记录3.1 环境准备与本地部署理论谈再多也不如跑一次真实 Demo。我拿到的版本基于官方仓库 google/agent2agent 提供了 Python SDK 和 TypeScript SDK以及若干可运行示例。本地环境准备不算复杂但有几个细节值得注意。我当时的操作路径是先把仓库 clone 到本地然后创建虚拟环境并安装 SDK 依赖。官方推荐用 uv 管理依赖如果你本地还没装 uv用 pip 建立 venv 后 install 也可以只是要注意 SDK 版本迭代较快以仓库 README 为准。git clone https://github.com/google/agent2agent.git cd agent2agent uv venv source .venv/bin/activate uv pip install -e python-sdk[a2a-server,local-client]安装完成之后仓库 samples 目录里自带了好几个可以直接启动的示例 Agent。这里有一个最容易踩的坑不要第一次就跑多 Agent 的高阶示例我建议先从一个最基础的 logger Agent 开始。它的逻辑非常简单——接收一段文本把它记录下来反馈一个结构化结果。麻雀虽小五脏俱全用来观察 Agent Card、任务启停、结果回传完全够了。启动服务后本地会跑起来一个监听固定端口的 HTTP 服务A2A Client 可以从这个端口读到 Agent Card。如果你在启动命令里加了 debug UI 相关参数浏览器会打开一个可视化调试界面能看到 Agent 收到的每一条请求和它返回的每一条消息。这对理解协议交互特别有帮助。3.2 让两个代理完成一次跨软件任务我的目标很具体客户端作为调度方同时管理一个“记账 Agent”和一个“日志 Agent”让前者把一笔费用记录转发给后者做留痕。这个任务本身简单但已经能体现 A2A 的协作逻辑。核心代码结构并不复杂。客户端先从 Agent 服务地址读取 Agent Card确认对方支持的能力然后发起一个任务请求。from a2a.client import A2AClient from a2a.types import TaskInput, JSONRPC, Message, TextPart client await A2AClient.from_url( urlhttp://localhost:5001, configNone ) task_input TaskInput( messageMessage( roleuser, parts[TextPart(text记录这条费用云服务账单 320 元)] ) ) task await client.send_task(JSONRPC(methodtask/send, paramstask_input)) print(Task ID:, task.task_id)服务端 Agent 收到任务后在自己的能力范围内处理这段文本并把结果打包回传。如果有需要它还可以在回复里主动引用另一个 Agent 的 Agent Card让客户端继续往下游派单。整个过程里我不需要维护两个服务之间的直接依赖——它们只和协议打交道不关心对方代码怎么写。实测下来的感觉是A2A 把“集成”变成了“对话”。在传统 API 集成里我要搞清楚每个接口的参数签名、错误码和重试机制在 A2A 里我只需要把一个消息塞进 TaskInput然后等待对方把结果变成结构化数据送回来。对于跨系统的任务流转这种模式确实省心很多。3.3 初跑必踩的超时与地址配置问题这部分是最有价值的实战环节。我在热词里看到一句很真实的报错“mcp client for codex_apps timed out after 30 seconds. add or adjust star”。自己跑 A2A 的时候我也遇到了类似现象。新手在本地起服务后客户端调用另一个 Agent经常在 30 秒左右直接超时看日志却发现服务端其实已经处理完了。我的排查链路是这样的。先看服务端日志有没有收到请求如果压根没收到多半是地址或端口配置错误如果收到了但没响应问题就出在处理循环或回调地址上。A2A 支持异步回调客户端必须能访问到服务端给出的回调地址在本地调试时回调地址如果写成了局域网 IP 或不可达的公网地址请求就会卡死在等待状态。修整方案非常基础但实用把所有地址统一切回http://127.0.0.1:端口并且确保客户端与服务端在同一网络可互达环境里。另一个点是依赖版本。A2A 协议才开源不久sdk 版本之间兼容性有时不够完美如果你 clone 的是最新代码但环境里装的是旧版依赖就会出现方法签名对不上、任务提交后没有回执这类诡异现象。我建议尽量用官方示例对应的依赖锁文件不要凭感觉去装最新版本。下面对照表列一下我排查出频率最高的几个问题现象可能原因处理方式30 秒超时但服务端日志有请求client 端的回调地址不可达或返回结构不满足协议使用 127.0.0.1 回调确认 callback url 正确任务被接受但没有任何后续状态Agent 内部逻辑错误异常被吞掉打开服务端 debug 模式查看堆栈读取 Agent Card 失败URL 后缀路径缺失或服务未升级到新协议确认 /.well-known/agent.json 路径可访问客户端向 Agent 提交任务时报参数错误SDK 版本不一致方法签名漂移按官方 requirements 锁定版本我建议所有准备跑 A2A 的朋友把官方仓库的 debug UI 工具用好。它把每一次任务状态切换都可视化地展示在浏览器里比看日志高效太多。遇到超时问题先不要怀疑“协议有问题”大概率是回调配置和通信细节没对齐。4. 这套思路会怎么改变开发者与普通用户4.1 对开发者从写 UI 到写 Agent 能力如果 A2A 这类协议真正铺开软件开发者的工作重心会发生明显迁移。今天我们写业务系统默认交付物是一个 Web 页面加一组 REST API未来可能要变成交付一组 Agent 的能力声明Agent Card加上任务处理逻辑。这不是停留在概念层面的想象。你现在做一个“AI 简历助手”传统交付物是用户打开网页上传 PDF然后在页面上读解析结果。在 A2A 的世界里你的产品交付的是一个“简历解析 Agent”它对外声明自己会接收 PDF 格式的文件、输出结构化候选人信息。其他 Agent 可以直接调用它把它嵌入到招聘流程里去A 公司的人力 Agent 负责筛简历读到匹配的候选人后自动调用你的简历助手做深度解析再交给面评 Agent 生成评估意见。你的软件不再要求用户“打开”它而是要求用户“连接”它。这符合我这几年的一个观察软件与软件之间的真实价值往往比软件与人之间的界面更重要。A2A 只是把这件事从“偷偷摸摸做集成”变成了“光明正大地定义能力协议”。4.2 对普通用户从管理 App 到管理 Agent 团队普通用户端的变化会更直接。以后你手机里的“软件”可能不再是一堆需要分别登录、分别授权的 App而是一队听你调遣的 Agent一个负责订行程一个负责整理会议纪要一个负责盯报价。它们之间的协作由协议完成你只需要告诉“领队 Agent”你想干什么。热门搜索词里已经出现了“如何在浏览器插件里启用 mcp 连接”“Claude Code 怎么装 GitHub 上的 Skills”这类问题说明用户已经在尝试给个人 AI 助手装配跨应用能力。等 A2A 类协议普及之后“装一个插件”会变成“引入一个 Agent 能力”软件分发的颗粒度从“整个产品”下降到“一项能力”。订阅模式也可能变化从按人头买席位走向按任务成功次数付费。你不再为一年没打开几次的 SaaS 付费而是每次喊 Agent 干活时按量计费。这个变化对普通用户最大的意义是减负。你不需要成为所有软件快捷键的专家只需要学会把任务交给正确的 Agent软件之间的协作问题由协议解决不再需要用户自己复制粘贴。4.3 值得清醒看待的边界A2A 让我看到未来的同时也让我保持一种清醒的谨慎。首先就是安全边界。Agent 与 Agent 之间互相发送任务意味着他人可以更自动地触发你的能力端点。Agent Card 如果过度暴露能力攻击者可以批量调用你的 Agent 执行付费任务造成资源盗刷。部署时必须做鉴权、限流、授权模型一整套防护不能指望协议本身来解决。其次是协议仍在早期。A2A 的版本变动相当快我刚跑通的一套流程过两周再 clone 新代码可能要改接口。想在生产环境用它承担核心业务现在还是太激进。我更建议拿它在内部工具链和实验项目里试水跟着生态一起迭代。最后就是标准竞争风险。MCP 和 A2A 目前是各立山头未来大概率会有一个融合或趋同的过程。作为开发者没必要过早把身家押在某一套协议上保持关注、持续试跑比盲目站队更稳妥。我个人在实际操作中体会到A2A 这个项目最值得玩味的地方不在于某个优化点而在于它迫使你去重新思考“软件”这个词的本义——当 AI 越来越擅长执行任务软件的交付单位是不是也该从“界面”变成“能力”如果你也被这个趋势打动最好的做法不是收藏几十篇分析文章而是现在就 clone 一个仓库下来让两个最小的 Agent 在你本地完成一次对话。跑通了那一下你对未来软件形态的感知会完全不同。如果你想动手验证一下可以顺手给自己手头的小工具加一个agent.json文件在网上放一个简单的 A2A 端点然后让一个现成的 A2A 客户端去“发现”它。这十来分钟的小实验比读十篇“AI 时代软件重构”的行业报告都直观。