AI Agent协作协议——A2A/MCP标准化进展

互联网之所以成为互联网，不是因为TCP/IP协议本身有多精妙，而是因为所有人都同意使用它。一个协议的价值不在于技术的优雅程度，而在于它创造了一个可以让无数参与者自由互联的生态系统。2026年的AI Agent行业，正在经历一个类似的协议标准化时刻。

两个协议正在推动整个行业走向真正的互操作：Google主导的A2A（Agent-to-Agent）协议定义了Agent之间如何发现彼此、交换任务、共享上下文。而Anthropic主导的MCP（Model Context Protocol）定义了Agent如何连接外部工具、数据源和系统。这两个协议的分工非常清晰——MCP管Agent到工具的连接，A2A管Agent到Agent的连接。当两者结合，一个开放的、可互操作的Agent生态系统就成为可能。

一、为什么Agent行业需要标准协议？

2025年是企业Agent百花齐放的一年。LangChain、AutoGen、CrewAI、Semantic Kernel、Dify——每个框架都有自己的Agent定义方式、自己的工具接口规范、自己的Agent通信机制。一个用LangChain构建的销售Agent无法与一个用AutoGen构建的客服Agent直接通信——两个Agent虽然都叫"Agent"，但它们在技术层面是两种完全不同的生物。

这个问题的本质是缺乏互操作性。它导致了三个严重的后果：（1）厂商锁定——一旦你选择了某个Agent框架，你就很难引入使用其他框架构建的Agent能力。你的Agent团队中的每一个成员都必须来自同一个框架。（2）重复建设——每个Agent框架都得自己实现与CRM、ERP、数据库等企业系统的连接器，这些连接器的功能大同小异但互不兼容。（3）孤岛效应——不同供应商提供的AI Agent无法协作——就像只能用同一个品牌的手机才能互相打电话。

协议标准化的目标不是让所有Agent都一样——而是让不同来源、不同框架的Agent能够在保持各自差异的前提下互操作。就像HTTP协议不规定网页应该长什么样，但它让任何浏览器都能访问任何网站。

二、MCP协议深度解析：Agent的统一工具接口

MCP（Model Context Protocol）是Anthropic在2025年底发布、2018-2026年快速演进的开放协议。它的核心思想极其简洁：为AI模型和外部世界之间的交互定义一套统一的接口规范。

MCP定义了三种核心原语：Resources（资源）——Agent可以读取的数据。文件、数据库记录、API响应、实时传感器读数——从Agent的角度看，它们都是"资源"。Tools（工具）——Agent可以调用的操作。发送邮件、创建订单、更新数据库、控制设备——这些是"工具"。Prompts（提示模板）——预定义的交互模板，让Agent和工具的交互更加高效和标准化。

MCP的架构是经典的Client-Server模式。工具或数据源被封装为一个MCP Server——它可能是你本地文件系统的一个MCP Server（让Agent能读写文件），也可能是你CRM系统的一个MCP Server（让Agent能查询和更新客户数据），或者是数据库的一个MCP Server。Agent作为MCP Client，通过标准化的协议与所有这些Server通信——它不需要知道每个Server内部的实现细节，只需要知道它提供的Resources和Tools。

2026年下半年MCP的几个关键进展：

MCP Server生态爆发。2026年上半年，社区贡献的MCP Server数量从几十个增长到了数千个。几乎每一个主流的企业系统——Salesforce、SAP、ServiceNow、Jira、GitHub、Slack、Notion——都有了官方或社区维护的MCP Server。这意味着一个Agent可以通过MCP在一小时内接入10个不同的企业系统，而不需要写任何定制连接代码。

MCP的动态发现机制。2026年的MCP v1.2引入了动态能力发现——Agent在连接到一个MCP Server时，不依赖预先配置的工具列表，而是动态地查询Server的"能力清单"（有哪些Resources、有哪些Tools、每个Tool的参数schema是什么）。这让Agent能够适应MCP Server的能力变化，而不需要人工重新配置。

MCP的流式传输。对于需要持续数据流的场景（实时监控、日志追踪、流式数据分析），MCP引入了双向流式传输机制。Agent可以"订阅"一个MCP Resource的更新——当CRM中某个客户的订单状态发生变化时，MCP Server主动推送更新给Agent，而不是Agent需要不断的轮询。

三、A2A协议深度解析：Agent之间的通用语言

A2A（Agent-to-Agent）是Google在2025年发布、2026年与50+合作伙伴共同推进的开放协议。如果说MCP解决的是"Agent怎么用工具"，A2A解决的是"Agent怎么和其他Agent协作"。

A2A定义了Agent之间交互的三个核心概念：Agent Card（Agent卡片）——每个Agent公开暴露一个描述自己能力的JSON文档。包括Agent的名称、描述、支持的技能列表、输入输出格式、端点URL。其他Agent通过读取Agent Card来发现和了解这个Agent能做什么。Task（任务）——Agent之间通过Task来传递工作。一个Task包含一个目标描述、输入数据、期望的输出格式。A2A支持同步Task（请求-响应模式）和异步Task（发送任务后不等待立即响应，通过回调或轮询获取结果）。Artifact（产出物）——Task的执行结果，可以是文本、结构化数据、文件、或者对其他Artifact的引用。

A2A在2026年的关键进展：

A2A和MCP的深度集成。2026年上半年最重要的协议进展是A2A和MCP的协同工作模式被正式定义。当一个Agent A通过A2A向Agent B派发一个任务，Agent B可能需要通过MCP调用各种工具来完成这个任务。A2A定义了如何在Task中传递"如果你需要更多上下文，可以通过MCP访问以下资源"的元信息。这种协同使得多Agent系统的工作链能够在标准协议上无缝运行。

A2A的Agent发现服务。在一个有几十个Agent的企业环境中，各个Agent怎么知道其他Agent的存在？A2A定义了一个Agent发现服务——一个中央注册表，Agent可以向它注册自己的Agent Card，也可以查询它来发现其他可用的Agent。这个发现服务本身也是通过A2A协议通信的，形成了一个自指的优雅设计。

A2A的安全与信任模型。当Agent A要把一个任务交给Agent B时，A需要确保B真的是它宣称的那个Agent（不是伪造的），并且B只会做它被授权的操作。A2A在2026年引入了一套基于OAuth 2.0和JWT令牌的认证与授权机制。每个Agent拥有自己的身份凭证，在向其他Agent发起请求时需要出示令牌，被请求的Agent可以根据令牌中的权限声明来决定是否接受和执行任务。

四、MCP+A2A协同：构建企业Agent团队的完整协议栈

MCP和A2A各自解决了Agent基础设施的一半问题。当把它们组合在一起时，就形成了一个完整的Agent协议栈：

最底层（L0：连接层）——MCP负责。Agent通过MCP Server连接到企业系统——CRM、ERP、数据库、文件系统、邮件系统。每一个系统对Agent来说就是一个或多个MCP Server。这一层解决的是"Agent能看到和操作哪些系统"。

中间层（L1：协作层）——A2A负责。Agent通过A2A协议互相发现、交换任务、共享结果。一个Supervisor Agent通过A2A向各个专业Agent分发任务、收集结果、协调冲突。这一层解决的是"Agent之间怎么协作"。

最上层（L2：编排层）——应用逻辑负责。这一层不归属于任何协议，而是企业的具体应用逻辑。一个业务流程（如"处理一个新客户订单"）被建模为一个跨Agent的工作流。L2层定义了这个工作流的步骤、条件、回退策略。Agent在该工作流中各自承担的角色。

五、协议标准化对企业的实际价值

协议标准化对于一个CTO来说意味着什么？以下是从企业IT决策者角度的五个实际价值：

第一，摆脱框架锁定。如果企业所有的Agent都依赖一个框架的专有通信机制，那么这个框架就成了一个单点故障和单点锁定。A2A和MCP的标准化意味着你可以用最适合的工具构建每个Agent——用LangChain做复杂的推理Agent，用Dify做简单的问答Agent，用自定义Python脚本做高度定制的数据处理Agent——它们通过标准协议互操作。你可以随时替换其中任何一个Agent，而不会影响整个Agent团队的运作。

第二，保护连接器投资。为CRM系统开发一个MCP Server是一个一次性的投资——所有Agent，无论用什么框架构建，都通过这同一个MCP Server访问CRM。你不需要为每个Agent框架重复开发CRM连接器。在大型企业中，这个投资保护的价值是巨大的。

第三，渐进式Agent化。协议标准化让企业可以采用"渐进式"的Agent部署策略。你可以先部署一个简单的客服Agent（通过MCP连接工单系统），6个月后再部署一个销售Agent（通过MCP连接CRM），再3个月后让这两个Agent通过A2A协作。每一步都可以独立验证价值，不需要一步到位地构建一个大型Agent系统。

第四，跨供应商协作。企业可以从不同的AI供应商购买不同的Agent能力——从A公司买一个HR Agent，从B公司买一个财务Agent，从C公司买一个合规Agent——如果它们都遵循A2A和MCP协议，它们可以无缝协作。供应商之间的竞争将从"谁的生态更封闭"变成"谁在开放协议上做得更好"——这对企业买家是有利的。

第五，生态复用。协议标准化意味着企业可以复用社区贡献的工具和Agent。如果你的企业使用Salesforce，社区已经有现成的Salesforce MCP Server——你不需要自己开发。如果你需要一个通用的"合同审核Agent"，社区可能有现成的开源Agent——你可以直接部署并通过A2A集成。

六、协议标准化面临的三重挑战

尽管前景光明，协议标准化的道路并非一帆风顺。在2026年下半年，三个关键挑战仍然摆在面前：

挑战一：两大阵营的微妙竞争。Google主导A2A，Anthropic主导MCP。虽然两个协议在技术上是互补的，但主导方的商业利益并非完全一致。Google更关注的是Agent在Google Cloud生态中的运行，Anthropic更关注的是Agent如何高效地使用Claude模型。如果两大阵营在标准化的过程中将各自的商业利益凌驾于开放互操作之上，那么"标准化"可能变成"两个阵营各自的标准"——这是一个需要行业持续警惕的风险。

挑战二：协议实现的碎片化。有标准协议和所有人都正确实现标准协议，是两件完全不同的事。HTTP协议已经标准化了几十年，但不同的HTTP客户端的实现仍然有微妙的差异。A2A和MCP作为更复杂的协议，实现碎片化的风险更高。目前行业需要的是更多的合规性测试套件和认证机制——确保一个声称"支持A2A"的Agent，真的可以被所有其他A2A Agent正确理解。

挑战三：遗留系统的适配成本。企业有大量已经上线运行的Agent，它们使用的是框架专有的通信机制。将这些Agent迁移到A2A/MCP协议上是有成本的——包括代码修改、测试、重新部署。在迁移的过渡期，企业需要同时维护两套通信机制（旧的专有协议和新的标准协议），这增加了复杂度。

TCP/IP协议用了十年才从学术网络变成全球互联网的基础设施。A2A和MCP正走在一条类似的路上——它们可能只需要三年。不是因为技术更简单，而是因为整个行业对协议标准化的需求更迫切。当一个新技术的基础设施还没有标准化时，生态中的每个玩家都在重复造轮子、都在经历不必要的摩擦。一旦标准化完成，整个生态的发展速度将上一个台阶。

宝软数字的EIOS平台已经全面支持A2A和MCP协议。我们相信企业AI的未来不是一个封闭的花园，而是一个开放的、互联的生态系统。EIOS Agent不仅能在内部的Agent团队中协作，还能通过标准协议与企业现有的SaaS工具和未来的第三方Agent互通。

下一篇：代码生成2.0——AI写的不再是demo而是生产级代码。