引子两个协议同一屋檐不同房间2026年6月25日Linux Foundation Agentic AI Foundation发布了MCP A2A融合草案。消息传出后不少人的第一反应是“终于要合并了”。但仔细读草案内容会发现不是合并是分治统一。两个协议归属于不同的子基金会——MCP在Agentic AI FoundationAAIFA2A在LF AI Data。它们没有被强行捏合成一个协议而是正式确认了分层架构Agent之间用A2A协调Agent内部用MCP连接工具。Google的比喻最准确A2A是horizontal bus横向总线MCP是vertical bus纵向总线。一个典型的生产架构是Orchestrator Agent通过A2A将任务委派给Specialist Agent后者内部通过MCP调用数据库、API、文件系统等工具。但融合草案的发布不是终点而是起点。A2A v1.0的Signed Agent Card解决了“发布者身份验证”的问题——可以验证“这个Agent是谁发布的”但不能验证“这个Agent现在在谁的委托下做什么”。跨组织Agent协作在信任层面还有一段路要走。本文沿着“治理格局 → MCP最新规范 → A2A Java SDK → 企业实践 → 信任层缺口 → Java集成路径”的主线拆解融合进展的完整图景。一、治理格局AAIF的“Kubernetes时刻”从“各家造轮子”到“vendor-neutral standard”2025年12月25日OpenAI、Anthropic、Block联合发起AAIF分别贡献agents.md、MCP和Goose作为生态基石。Google随后在2026年8月将A2A协议转入AAIF管理。这个治理结构的核心意义有三点。消除单厂商锁定风险。Anthropic不能单方面改MCPGoogle不能单方面改A2A。企业CIO敢把预算投进去因为协议不归任何竞争对手独有。允许差异化演进。两个协议可以按各自节奏迭代不需要强行统一。MCP专注Agent-Tool纵向连接A2A专注Agent-Agent横向协调。加速生态采纳。正如业界评论所言这是Agent生态的“Kubernetes时刻”——vendor-neutral standards替代了每个团队自己造轮子。扩张速度13周 vs 13个月AAIF执行总监Mazin Gilbert在MCP Dev Summit上做了一个对比CNCF用了大约13个月成为基础设施货币MCP用了大约13周。截至2026年9月AAIF成员已突破260家Google、Microsoft、Amazon、Shopify、Bloomberg等科技巨头深度参与成为Linux基金会历史上扩张速度最快的子基金会。但扩张速度是一把双刃剑。Gilbert指出“AAIF does the governance work that CNCF did over years — conformance testing, security hardening, production observability — in a compressed timeline”。压缩的时间线意味着治理工作需要更快地跟上生态扩张的速度。七大工作组打通商用全链路AAIF设立了七大专业工作组覆盖智能体商用的全链条工作组核心职责身份与信任定义跨平台认证授权机制准确性与可靠性建立确定性输出评估框架工作流与流程集成实现Agent与企业现有系统无缝嵌入智能体商业推进Agent自动交易、支付与目录查询标准安全与隐私守护数据主权与隐私计算可观测性与可追溯性提供全链路审计能力治理、风险与监管对齐紧跟欧盟AI法案等全球法规Gilbert直言行业最大的标准化瓶颈正是身份认证与商业交易规范七大工作组的设立正是直击产业痛点。Java视角AAIF的治理结构和你在Java生态中熟悉的Eclipse Foundation或Apache Software Foundation的运作模式类似。一个vendor-neutral的基金会管理核心协议确保协议不被任何单一厂商控制。七大工作组的划分方式和你用Spring Security的模块化设计解决安全问题的思路一致——身份认证、授权、审计、加密每个维度独立演进而不是用一个“大而全”的模块包揽所有安全问题。二、MCP 2026-07-28规范无状态核心与扩展生态从“有状态连接”到“无状态核心”2026年7月28日MCP发布了第五版规范被Anthropic称为“迄今为止最重要的规范发布之一”。最核心的变化是从双向有状态协议转向无状态请求/响应模型。在旧版规范2025-11-25中MCP维护协议级的会话状态Server需要保持与Client的连接以跟踪上下文。新规范删除了协议级会话每个请求都是自包含的不依赖之前的连接状态。这个变化的工程含义很直接MCP Server现在可以部署在Serverless和边缘基础设施上大幅简化了扩展和运维。正如Netlify在规范发布时的评价“The stateless core in the 2026-07-28 spec makes MCP a first-class HTTP workload with no session management to work around”。标准化扩展框架新规范引入了版本化的扩展框架。MCP Apps扩展支持在对话中内联渲染交互式UI元素图表、表单、视频播放器Tasks扩展支持异步执行长时间运行的操作支持轮询、中途输入和持久化句柄。这个设计的意义在于核心协议保持稳定扩展能力通过独立模块演进。开发者不需要因为“想加一个UI渲染能力”就修改核心协议而是通过安装MCP Apps扩展来实现。授权硬化授权方面MCP的认证机制从草案进入正式版对齐生产级OAuth 2.0和OIDC部署标准使MCP Server可以直接对接Entra、Okta等企业身份系统。这是MCP从“开发者工具”走向“企业基础设施”的关键一步——没有标准化的OAuth 2支持企业无法将MCP Server纳入现有的身份管理体系。生态规模MCP的SDK月下载量超过4亿次较一年前增长4倍。截至2026年中MCP生态已拥有超过32,600个服务器暴露超过229,800个工具。Java视角MCP从有状态到无状态的变化和Java生态中从Stateful Session Bean到Stateless Session Bean再到RESTful无状态服务的演进路径惊人相似。无状态化带来的好处——易于水平扩展、部署简化、故障恢复——也正是Java开发者从EJB时代迁移到Spring Boot微服务时体验过的价值。MCP Apps扩展框架的设计则和你用Spring Boot Starter按需引入功能模块的思路一致——核心框架保持轻量扩展能力通过独立模块提供。三、A2A Java SDK 1.0.0.Final从Alpha到GA的六个月SDK的发布历程A2A Java SDK在2026年6月10日发布了1.0.0.Final这是官方Java实现的首个GA版本。从Alpha到Final经历了六个月、七个预发布版本四个Alpha、一个Beta、一个Candidate Release由17位贡献者共同完成。SDK支持三种传输协议JSON-RPC、gRPC、HTTPJSON/REST三者被同等对待开发者可以根据需要选择任意一种或多种。集成测试套件跨SDK互操作性的保障1.0.0.Final最大的新增功能是Integration Test KitITK——一个可配置的、基于Quarkus的A2A Agent运行预定义的测试场景来验证协议合规性。ITK的目标是确保Java SDK能够与使用其他A2A SDKPython、TypeScript等构建的Agent正确互操作。这个设计的重要性在于A2A的核心价值是跨语言、跨框架的Agent通信。如果Java SDK只能和Java Agent通信那它就失去了标准化的意义。ITK的存在确保了“Python Orchestrator能委派任务给Java Specialist Agent”这个场景的可靠性。安装与依赖dependencyManagementdependenciesdependencygroupIdorg.a2aproject.sdk/groupIdartifactIda2a-java-sdk-bom/artifactIdversion1.0.0.Final/versiontypepom/typescopeimport/scope/dependency/dependencies/dependencyManagementdependencygroupIdorg.a2aproject.sdk/groupIdartifactIda2a-java-sdk-reference-jsonrpc/artifactId/dependencySDK的核心抽象是AgentCard——一份标准的JSON文档暴露在/.well-known/agent-card.json路径下描述Agent的身份、能力和技能。1.0.0.Final引入了supportedInterfaces模型支持在一个AgentCard中声明多种传输接口。Java视角A2A Java SDK的发布节奏和你在Java生态中看到的Jakarta EE规范的演进类似——从Alpha到Beta到CR到Final每个阶段有明确的兼容性保证。ITK的作用相当于TCKTechnology Compatibility Kit——你在使用Jakarta EE兼容实现时TCK确保不同厂商的实现能够互操作。A2A的ITK做的是同一件事——确保不同语言的SDK实现能够正确通信。四、企业实践MCP A2A的分层落地微软的架构指南微软在2026年8月发布的“扶手椅架构师”系列文章中给出了MCP A2A在企业中的推荐使用方式内部流程尽量采用具有子Agent的平台原生编排以保持编排的简单使用MCP进行工具和数据访问包括Microsoft 365服务工具这是推荐的方式具备企业级的安全、身份验证和审计功能使用A2A进行跨平台Agent间消息传递阿里云的企业级实践阿里云开发者社区的一篇文章以“客服工单处理”为例构建了一个最小但可扩展的协作流程分类Agent判断工单类型知识Agent提供参考执行Agent创建内部任务审核节点决定是否允许高风险操作。文章给出了一个关键判断“MCP和A2A不是完整的业务系统也不能替代身份认证、权限管理、消息队列和审计平台。工程落地时必须把协议层放在明确的边界内”。两者的职责边界被精确地定义为编排器通过A2A分派任务Agent内部通过MCP调用具体能力。A2A负责任务生命周期submitted → running → succeeded/failed/cancelledMCP负责能力执行工具、资源、提示模板的调用。文章还强调了一个容易被忽视的工程原则不要从提示词开始而应先定义任务契约。任务消息需要包含任务标识、发起方、目标Agent、输入数据、幂等键、截止时间和当前状态。状态变化由服务端记录而不是由模型自行声称“已经完成”。Agent Router智能体专用路由基础设施2026年9月10日Envoy AI Gateway迁移至AAIF并更名为Agent Router标志着智能体专用路由基础设施的成型。Agent Router的定位可以用一句话概括MCP连工具、A2A做交互、Agent Gateway执行安全策略。它相当于Agent时代的API Gateway——在MCP和A2A的协议层之上提供路由、安全、限流、审计等横切关注点的统一管理。Java视角Agent Router的定位和你用Spring Cloud Gateway管理微服务流量的思路一致。Spring Cloud Gateway提供路由、过滤器、限流、熔断等能力Agent Router为Agent间的MCP/A2A通信提供同样的能力。你在Spring Cloud Gateway中配置路由规则和过滤器链的经验可以直接迁移到Agent Router的配置上。五、信任层缺口身份 ≠ 委托A2A v1.0的“浅层”信任A2A v1.0的Signed Agent Card解决了一个基础问题验证“这个Agent是谁发布的”。通过加密签名调用方可以确认Agent Card未被篡改Agent的身份来源可信。但它不能验证“这个Agent现在在谁的委托下做什么”。这个缺口的工程含义可以用一个具体场景来说明一个Agent说“我是A公司发布的订单查询Agent”——这个可以被验证。但“我被B公司的用户委托来查询C公司的订单数据”——这个无法被验证。跨组织Agent协作在信任层面还有一段路要走。与OAuth 2的对照这个缺口和OAuth 2中的delegation问题是同构的。OAuth 2的access token能验证“谁签发的”issuer但“用户是否授权这个客户端代表他访问这个资源”需要额外的scope和consent机制。AAIF的身份与信任工作组正是为解决这个问题而设立的。工作组的目标是定义跨平台认证授权机制为智能体跨组织协作奠定信任基础。Java视角信任层的缺口和你在Java中做OAuth 2 Resource Server时遇到的delegation问题是同一类问题。你在Spring Security中配置PreAuthorize(hasRole(ADMIN))解决的是“这个用户是否有权限”但“这个用户是否授权这个客户端代表他访问”需要额外的token exchange或on-behalf-of机制。A2A的信任层建设需要类似的机制——一个Agent需要能够证明“我正在代表谁执行操作”而不仅仅是“我是谁”。六、Java开发者的MCP A2A集成路径Spring AI Alibaba Nacos的分布式Agent方案对于Java开发者当前最成熟的MCP A2A集成路径是Spring AI Alibaba Nacos。Nacos 3.1.02026年9月发布正式引入了A2A注册中心和MCP注册协议增强。A2A注册中心支持发布与发现AgentCard及Agent服务端点实现Agent元数据的统一管理。当前支持基于Agent名称的精准发现和模糊搜索未来将扩展基于技能标签、描述等多维度的检索能力。MCP注册协议增强更新了官方MCP注册协议用户可将Nacos作为私有化MCP注册中心构建企业级模型市场或服务目录。新增MCP服务器导入功能支持通过JSON文件快速注册MCP服务并支持从MCP URL自动获取工具配置。快速开发分布式Agent应用基于Spring AI Alibaba NacosJava开发者可以快速构建分布式Agent应用开发一个简单的Agent并暴露A2A协议服务同时注册到Nacos上让上游Agent应用发现并进行远程调用实现Agent的分布式部署。这个架构的工作方式是┌──────────────────────────────────────────────────┐ │ Nacos (注册中心) │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ AgentCard A │ │ AgentCard B │ ... │ │ └─────────────┘ └─────────────┘ │ └────────────────────┬─────────────────────────────┘ │ 服务发现 ▼ ┌──────────────────────────────────────────────────┐ │ Orchestrator Agent (Java) │ │ ┌─────────────┐ │ │ │ A2A Client │──── A2A ────► Specialist Agent A │ │ └─────────────┘ (Java) │ │ ┌─────────────┐ │ │ │ MCP Client │──── MCP ────► Database/API/FS │ │ └─────────────┘ │ └──────────────────────────────────────────────────┘Orchestrator Agent通过A2A将任务委派给Specialist Agent后者内部通过MCP调用数据库、API、文件系统等工具。所有Agent通过Nacos进行服务注册和发现Agent的上下线对调用方透明。代码示例A2A Server AgentConfigurationpublicclassA2aConfig{BeanpublicAgentExecutoragentExecutor(ChatClientchatClient){returnnewDefaultAgentExecutor(chatClient);}BeanpublicAgentCardagentCard(){returnAgentCard.builder().name(order-assistant).description(处理订单相关咨询和操作).url(http://localhost:8080).skills(List.of(Skill.builder().id(query-order).name(查询订单).description(根据订单号查询状态).build())).build();}}MCP Server的安全加固MCP规范强制要求HTTP暴露的Server使用OAuth 2保护。Spring AI社区提供了mcp-server-security模块spring:ai:mcp:server:name:my-mcp-serverprotocol:STREAMABLEauthorization:server:url:https://auth.example.com这个配置和你用Spring Security的OAuth 2 Resource Server保护REST API的方式几乎一致。authorization.server.url相当于spring.security.oauth2.resourceserver.jwt.issuer-uri区别在于保护的对象从HTTP端点变成了MCP工具。Java视角Spring AI Alibaba Nacos的架构和你用Spring Cloud Eureka/Nacos构建微服务体系的思路完全一致。AgentCard≈服务元数据A2A Client≈Feign ClientMCP Server≈数据访问层。你在微服务架构中积累的服务发现、负载均衡、配置管理经验在Agent的分布式部署中几乎可以一一映射。小结MCP A2A融合进展的三个关键判断第一融合草案的实质是“分层架构的正式确认”而非“协议合并”。MCP专注Agent-Tool纵向连接A2A专注Agent-Agent横向协调两者在AAIF的统一治理下差异化演进。这种“同一屋檐下、不同房间”的治理结构消除了单厂商锁定风险同时允许两个协议按各自节奏迭代。Java开发者在设计Agent系统时应该同时部署两者——用MCP连接工具和数据源用A2A连接其他Agent。第二MCP 2026-07-28的无状态化是“生产就绪”的标志性事件。从有状态到无状态的转变让MCP Server可以部署在Serverless和边缘基础设施上大幅简化了扩展和运维。这和Java生态中从EJB到Spring Boot的演进路径一致——无状态化带来的水平扩展、部署简化、故障恢复能力是MCP从“开发者工具”走向“企业基础设施”的关键一步。第三信任层是未来1-2年最确定的工程缺口也是Java工程师的机会所在。A2A v1.0的Signed Agent Card只能验证“谁发布的”不能验证“谁在委托”。这个缺口和OAuth 2的delegation问题是同构的。AAIF的身份与信任工作组正在解决这个问题但工程实现需要时间。Java开发者在Spring Security中积累的OAuth 2配置、CORS策略、会话管理经验在Agent信任层建设中可以直接迁移——你不需要学习一套全新的安全模型只需要把已有的安全实践应用到MCP和A2A这个新协议栈上。下一篇进入4.3 具身智能与Agent的结合从VLA模型和世界模型两条技术路线出发拆解具身智能Agent如何从“数字世界的执行者”走向“物理世界的行动者”以及Java开发者在机器人中间件和边缘计算中的潜在机会。 系列专栏导航 专栏导航 大模型学习其他专栏衔接 《若依框架全攻略从入门到项目实战》 《深入浅出Mybatis》 全面掌握MySQL工具 《深入浅出Maven》 《深入浅出Kafka》 《全面掌握Swagger从入门到实战》 《Lombok高效Java开发的秘密武器完全解读》 博客概览《程序员技术成长导航专栏汇总》建议按系列顺序阅读从基础到进阶逐步掌握核心能力避免遗漏关键知识点全景导航博文系列《一口气学完fastJson》《一文搞懂PageHelper》《一文搞懂MyBatis》 
长河君 · 2026/10/23 5:39:14 · 阅读 1.2k MCP + A2A协议融合进展 —— 从“协议就绪”到“信任层才是硬仗”
引子两个协议同一屋檐不同房间2026年6月25日Linux Foundation Agentic AI Foundation发布了MCP A2A融合草案。消息传出后不少人的第一反应是“终于要合并了”。但仔细读草案内容会发现不是合并是分治统一。两个协议归属于不同的子基金会——MCP在Agentic AI FoundationAAIFA2A在LF AI Data。它们没有被强行捏合成一个协议而是正式确认了分层架构Agent之间用A2A协调Agent内部用MCP连接工具。Google的比喻最准确A2A是horizontal bus横向总线MCP是vertical bus纵向总线。一个典型的生产架构是Orchestrator Agent通过A2A将任务委派给Specialist Agent后者内部通过MCP调用数据库、API、文件系统等工具。但融合草案的发布不是终点而是起点。A2A v1.0的Signed Agent Card解决了“发布者身份验证”的问题——可以验证“这个Agent是谁发布的”但不能验证“这个Agent现在在谁的委托下做什么”。跨组织Agent协作在信任层面还有一段路要走。本文沿着“治理格局 → MCP最新规范 → A2A Java SDK → 企业实践 → 信任层缺口 → Java集成路径”的主线拆解融合进展的完整图景。一、治理格局AAIF的“Kubernetes时刻”从“各家造轮子”到“vendor-neutral standard”2025年12月25日OpenAI、Anthropic、Block联合发起AAIF分别贡献agents.md、MCP和Goose作为生态基石。Google随后在2026年8月将A2A协议转入AAIF管理。这个治理结构的核心意义有三点。消除单厂商锁定风险。Anthropic不能单方面改MCPGoogle不能单方面改A2A。企业CIO敢把预算投进去因为协议不归任何竞争对手独有。允许差异化演进。两个协议可以按各自节奏迭代不需要强行统一。MCP专注Agent-Tool纵向连接A2A专注Agent-Agent横向协调。加速生态采纳。正如业界评论所言这是Agent生态的“Kubernetes时刻”——vendor-neutral standards替代了每个团队自己造轮子。扩张速度13周 vs 13个月AAIF执行总监Mazin Gilbert在MCP Dev Summit上做了一个对比CNCF用了大约13个月成为基础设施货币MCP用了大约13周。截至2026年9月AAIF成员已突破260家Google、Microsoft、Amazon、Shopify、Bloomberg等科技巨头深度参与成为Linux基金会历史上扩张速度最快的子基金会。但扩张速度是一把双刃剑。Gilbert指出“AAIF does the governance work that CNCF did over years — conformance testing, security hardening, production observability — in a compressed timeline”。压缩的时间线意味着治理工作需要更快地跟上生态扩张的速度。七大工作组打通商用全链路AAIF设立了七大专业工作组覆盖智能体商用的全链条工作组核心职责身份与信任定义跨平台认证授权机制准确性与可靠性建立确定性输出评估框架工作流与流程集成实现Agent与企业现有系统无缝嵌入智能体商业推进Agent自动交易、支付与目录查询标准安全与隐私守护数据主权与隐私计算可观测性与可追溯性提供全链路审计能力治理、风险与监管对齐紧跟欧盟AI法案等全球法规Gilbert直言行业最大的标准化瓶颈正是身份认证与商业交易规范七大工作组的设立正是直击产业痛点。Java视角AAIF的治理结构和你在Java生态中熟悉的Eclipse Foundation或Apache Software Foundation的运作模式类似。一个vendor-neutral的基金会管理核心协议确保协议不被任何单一厂商控制。七大工作组的划分方式和你用Spring Security的模块化设计解决安全问题的思路一致——身份认证、授权、审计、加密每个维度独立演进而不是用一个“大而全”的模块包揽所有安全问题。二、MCP 2026-07-28规范无状态核心与扩展生态从“有状态连接”到“无状态核心”2026年7月28日MCP发布了第五版规范被Anthropic称为“迄今为止最重要的规范发布之一”。最核心的变化是从双向有状态协议转向无状态请求/响应模型。在旧版规范2025-11-25中MCP维护协议级的会话状态Server需要保持与Client的连接以跟踪上下文。新规范删除了协议级会话每个请求都是自包含的不依赖之前的连接状态。这个变化的工程含义很直接MCP Server现在可以部署在Serverless和边缘基础设施上大幅简化了扩展和运维。正如Netlify在规范发布时的评价“The stateless core in the 2026-07-28 spec makes MCP a first-class HTTP workload with no session management to work around”。标准化扩展框架新规范引入了版本化的扩展框架。MCP Apps扩展支持在对话中内联渲染交互式UI元素图表、表单、视频播放器Tasks扩展支持异步执行长时间运行的操作支持轮询、中途输入和持久化句柄。这个设计的意义在于核心协议保持稳定扩展能力通过独立模块演进。开发者不需要因为“想加一个UI渲染能力”就修改核心协议而是通过安装MCP Apps扩展来实现。授权硬化授权方面MCP的认证机制从草案进入正式版对齐生产级OAuth 2.0和OIDC部署标准使MCP Server可以直接对接Entra、Okta等企业身份系统。这是MCP从“开发者工具”走向“企业基础设施”的关键一步——没有标准化的OAuth 2支持企业无法将MCP Server纳入现有的身份管理体系。生态规模MCP的SDK月下载量超过4亿次较一年前增长4倍。截至2026年中MCP生态已拥有超过32,600个服务器暴露超过229,800个工具。Java视角MCP从有状态到无状态的变化和Java生态中从Stateful Session Bean到Stateless Session Bean再到RESTful无状态服务的演进路径惊人相似。无状态化带来的好处——易于水平扩展、部署简化、故障恢复——也正是Java开发者从EJB时代迁移到Spring Boot微服务时体验过的价值。MCP Apps扩展框架的设计则和你用Spring Boot Starter按需引入功能模块的思路一致——核心框架保持轻量扩展能力通过独立模块提供。三、A2A Java SDK 1.0.0.Final从Alpha到GA的六个月SDK的发布历程A2A Java SDK在2026年6月10日发布了1.0.0.Final这是官方Java实现的首个GA版本。从Alpha到Final经历了六个月、七个预发布版本四个Alpha、一个Beta、一个Candidate Release由17位贡献者共同完成。SDK支持三种传输协议JSON-RPC、gRPC、HTTPJSON/REST三者被同等对待开发者可以根据需要选择任意一种或多种。集成测试套件跨SDK互操作性的保障1.0.0.Final最大的新增功能是Integration Test KitITK——一个可配置的、基于Quarkus的A2A Agent运行预定义的测试场景来验证协议合规性。ITK的目标是确保Java SDK能够与使用其他A2A SDKPython、TypeScript等构建的Agent正确互操作。这个设计的重要性在于A2A的核心价值是跨语言、跨框架的Agent通信。如果Java SDK只能和Java Agent通信那它就失去了标准化的意义。ITK的存在确保了“Python Orchestrator能委派任务给Java Specialist Agent”这个场景的可靠性。安装与依赖dependencyManagementdependenciesdependencygroupIdorg.a2aproject.sdk/groupIdartifactIda2a-java-sdk-bom/artifactIdversion1.0.0.Final/versiontypepom/typescopeimport/scope/dependency/dependencies/dependencyManagementdependencygroupIdorg.a2aproject.sdk/groupIdartifactIda2a-java-sdk-reference-jsonrpc/artifactId/dependencySDK的核心抽象是AgentCard——一份标准的JSON文档暴露在/.well-known/agent-card.json路径下描述Agent的身份、能力和技能。1.0.0.Final引入了supportedInterfaces模型支持在一个AgentCard中声明多种传输接口。Java视角A2A Java SDK的发布节奏和你在Java生态中看到的Jakarta EE规范的演进类似——从Alpha到Beta到CR到Final每个阶段有明确的兼容性保证。ITK的作用相当于TCKTechnology Compatibility Kit——你在使用Jakarta EE兼容实现时TCK确保不同厂商的实现能够互操作。A2A的ITK做的是同一件事——确保不同语言的SDK实现能够正确通信。四、企业实践MCP A2A的分层落地微软的架构指南微软在2026年8月发布的“扶手椅架构师”系列文章中给出了MCP A2A在企业中的推荐使用方式内部流程尽量采用具有子Agent的平台原生编排以保持编排的简单使用MCP进行工具和数据访问包括Microsoft 365服务工具这是推荐的方式具备企业级的安全、身份验证和审计功能使用A2A进行跨平台Agent间消息传递阿里云的企业级实践阿里云开发者社区的一篇文章以“客服工单处理”为例构建了一个最小但可扩展的协作流程分类Agent判断工单类型知识Agent提供参考执行Agent创建内部任务审核节点决定是否允许高风险操作。文章给出了一个关键判断“MCP和A2A不是完整的业务系统也不能替代身份认证、权限管理、消息队列和审计平台。工程落地时必须把协议层放在明确的边界内”。两者的职责边界被精确地定义为编排器通过A2A分派任务Agent内部通过MCP调用具体能力。A2A负责任务生命周期submitted → running → succeeded/failed/cancelledMCP负责能力执行工具、资源、提示模板的调用。文章还强调了一个容易被忽视的工程原则不要从提示词开始而应先定义任务契约。任务消息需要包含任务标识、发起方、目标Agent、输入数据、幂等键、截止时间和当前状态。状态变化由服务端记录而不是由模型自行声称“已经完成”。Agent Router智能体专用路由基础设施2026年9月10日Envoy AI Gateway迁移至AAIF并更名为Agent Router标志着智能体专用路由基础设施的成型。Agent Router的定位可以用一句话概括MCP连工具、A2A做交互、Agent Gateway执行安全策略。它相当于Agent时代的API Gateway——在MCP和A2A的协议层之上提供路由、安全、限流、审计等横切关注点的统一管理。Java视角Agent Router的定位和你用Spring Cloud Gateway管理微服务流量的思路一致。Spring Cloud Gateway提供路由、过滤器、限流、熔断等能力Agent Router为Agent间的MCP/A2A通信提供同样的能力。你在Spring Cloud Gateway中配置路由规则和过滤器链的经验可以直接迁移到Agent Router的配置上。五、信任层缺口身份 ≠ 委托A2A v1.0的“浅层”信任A2A v1.0的Signed Agent Card解决了一个基础问题验证“这个Agent是谁发布的”。通过加密签名调用方可以确认Agent Card未被篡改Agent的身份来源可信。但它不能验证“这个Agent现在在谁的委托下做什么”。这个缺口的工程含义可以用一个具体场景来说明一个Agent说“我是A公司发布的订单查询Agent”——这个可以被验证。但“我被B公司的用户委托来查询C公司的订单数据”——这个无法被验证。跨组织Agent协作在信任层面还有一段路要走。与OAuth 2的对照这个缺口和OAuth 2中的delegation问题是同构的。OAuth 2的access token能验证“谁签发的”issuer但“用户是否授权这个客户端代表他访问这个资源”需要额外的scope和consent机制。AAIF的身份与信任工作组正是为解决这个问题而设立的。工作组的目标是定义跨平台认证授权机制为智能体跨组织协作奠定信任基础。Java视角信任层的缺口和你在Java中做OAuth 2 Resource Server时遇到的delegation问题是同一类问题。你在Spring Security中配置PreAuthorize(hasRole(ADMIN))解决的是“这个用户是否有权限”但“这个用户是否授权这个客户端代表他访问”需要额外的token exchange或on-behalf-of机制。A2A的信任层建设需要类似的机制——一个Agent需要能够证明“我正在代表谁执行操作”而不仅仅是“我是谁”。六、Java开发者的MCP A2A集成路径Spring AI Alibaba Nacos的分布式Agent方案对于Java开发者当前最成熟的MCP A2A集成路径是Spring AI Alibaba Nacos。Nacos 3.1.02026年9月发布正式引入了A2A注册中心和MCP注册协议增强。A2A注册中心支持发布与发现AgentCard及Agent服务端点实现Agent元数据的统一管理。当前支持基于Agent名称的精准发现和模糊搜索未来将扩展基于技能标签、描述等多维度的检索能力。MCP注册协议增强更新了官方MCP注册协议用户可将Nacos作为私有化MCP注册中心构建企业级模型市场或服务目录。新增MCP服务器导入功能支持通过JSON文件快速注册MCP服务并支持从MCP URL自动获取工具配置。快速开发分布式Agent应用基于Spring AI Alibaba NacosJava开发者可以快速构建分布式Agent应用开发一个简单的Agent并暴露A2A协议服务同时注册到Nacos上让上游Agent应用发现并进行远程调用实现Agent的分布式部署。这个架构的工作方式是┌──────────────────────────────────────────────────┐ │ Nacos (注册中心) │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ AgentCard A │ │ AgentCard B │ ... │ │ └─────────────┘ └─────────────┘ │ └────────────────────┬─────────────────────────────┘ │ 服务发现 ▼ ┌──────────────────────────────────────────────────┐ │ Orchestrator Agent (Java) │ │ ┌─────────────┐ │ │ │ A2A Client │──── A2A ────► Specialist Agent A │ │ └─────────────┘ (Java) │ │ ┌─────────────┐ │ │ │ MCP Client │──── MCP ────► Database/API/FS │ │ └─────────────┘ │ └──────────────────────────────────────────────────┘Orchestrator Agent通过A2A将任务委派给Specialist Agent后者内部通过MCP调用数据库、API、文件系统等工具。所有Agent通过Nacos进行服务注册和发现Agent的上下线对调用方透明。代码示例A2A Server AgentConfigurationpublicclassA2aConfig{BeanpublicAgentExecutoragentExecutor(ChatClientchatClient){returnnewDefaultAgentExecutor(chatClient);}BeanpublicAgentCardagentCard(){returnAgentCard.builder().name(order-assistant).description(处理订单相关咨询和操作).url(http://localhost:8080).skills(List.of(Skill.builder().id(query-order).name(查询订单).description(根据订单号查询状态).build())).build();}}MCP Server的安全加固MCP规范强制要求HTTP暴露的Server使用OAuth 2保护。Spring AI社区提供了mcp-server-security模块spring:ai:mcp:server:name:my-mcp-serverprotocol:STREAMABLEauthorization:server:url:https://auth.example.com这个配置和你用Spring Security的OAuth 2 Resource Server保护REST API的方式几乎一致。authorization.server.url相当于spring.security.oauth2.resourceserver.jwt.issuer-uri区别在于保护的对象从HTTP端点变成了MCP工具。Java视角Spring AI Alibaba Nacos的架构和你用Spring Cloud Eureka/Nacos构建微服务体系的思路完全一致。AgentCard≈服务元数据A2A Client≈Feign ClientMCP Server≈数据访问层。你在微服务架构中积累的服务发现、负载均衡、配置管理经验在Agent的分布式部署中几乎可以一一映射。小结MCP A2A融合进展的三个关键判断第一融合草案的实质是“分层架构的正式确认”而非“协议合并”。MCP专注Agent-Tool纵向连接A2A专注Agent-Agent横向协调两者在AAIF的统一治理下差异化演进。这种“同一屋檐下、不同房间”的治理结构消除了单厂商锁定风险同时允许两个协议按各自节奏迭代。Java开发者在设计Agent系统时应该同时部署两者——用MCP连接工具和数据源用A2A连接其他Agent。第二MCP 2026-07-28的无状态化是“生产就绪”的标志性事件。从有状态到无状态的转变让MCP Server可以部署在Serverless和边缘基础设施上大幅简化了扩展和运维。这和Java生态中从EJB到Spring Boot的演进路径一致——无状态化带来的水平扩展、部署简化、故障恢复能力是MCP从“开发者工具”走向“企业基础设施”的关键一步。第三信任层是未来1-2年最确定的工程缺口也是Java工程师的机会所在。A2A v1.0的Signed Agent Card只能验证“谁发布的”不能验证“谁在委托”。这个缺口和OAuth 2的delegation问题是同构的。AAIF的身份与信任工作组正在解决这个问题但工程实现需要时间。Java开发者在Spring Security中积累的OAuth 2配置、CORS策略、会话管理经验在Agent信任层建设中可以直接迁移——你不需要学习一套全新的安全模型只需要把已有的安全实践应用到MCP和A2A这个新协议栈上。下一篇进入4.3 具身智能与Agent的结合从VLA模型和世界模型两条技术路线出发拆解具身智能Agent如何从“数字世界的执行者”走向“物理世界的行动者”以及Java开发者在机器人中间件和边缘计算中的潜在机会。 系列专栏导航 专栏导航 大模型学习其他专栏衔接 《若依框架全攻略从入门到项目实战》 《深入浅出Mybatis》 全面掌握MySQL工具 《深入浅出Maven》 《深入浅出Kafka》 《全面掌握Swagger从入门到实战》 《Lombok高效Java开发的秘密武器完全解读》 博客概览《程序员技术成长导航专栏汇总》建议按系列顺序阅读从基础到进阶逐步掌握核心能力避免遗漏关键知识点全景导航博文系列《一口气学完fastJson》《一文搞懂PageHelper》《一文搞懂MyBatis》