MCP是不是真凉了？

在2025年11月25日发布的2025-11-25规范版本中,MCP团队引入了四项核心更新,这些更新既展现了协议的进化,也暴露出其初始设计的局限性。

首先是Task任务抽象的引入(SEP-1686)。这次更新中最引人注目的是实验性的Task原语,它允许智能体发起一个任务后立即返回句柄,稍后再获取结果。这种"现在调用、稍后获取"的模式终于为MCP带来了异步工作流的支持。Task支持working、input_required、completed、failed、cancelled等多种状态,开发者可以通过轮询机制追踪任务进度。然而值得注意的是,这一特性被标记为"实验性",这意味着在MCP发布整整一年后,长时任务支持仍未达到生产级稳定性。对比之下,Google的A2A协议从第一天起就将Task作为核心抽象,这种设计差异反映了两种协议对智能体能力边界的不同预判。

其次是Client Registration机制的重大调整。MCP团队放弃了此前复杂的动态客户端注册(Dynamic Client Registration),转而采用基于URL的客户端身份元数据文档(Client ID Metadata Documents, CIMD)。在新方案中,客户端直接使用一个受控URL作为client_id,授权服务器通过解析这个URL获取客户端的元数据配置。这种设计简化了注册流程,支持去中心化的信任体系,也降低了生态系统的准入门槛。但这种简化背后,也反映出MCP在OAuth集成上的反复试错——初始的Dynamic Client Registration方案显然未能满足实际部署需求,导致协议在一周年时不得不进行架构性调整。

第三是安全与企业级特性的强化。新规范增加了本地服务器安装的客户端安全要求(SEP-1024),规范了授权中的默认作用域定义(SEP-835),并引入了OAuth客户端凭证(Client Credentials)支持机器对机器(M2M)授权(SEP-1046)。更重要的是,新增的企业身份提供商策略控制(SEP-990)允许组织统一管理AI应用的跨应用访问权限。这些更新表明,MCP正在努力弥补其在安全设计上的先天不足。此前多份安全研究报告(Strobes、Bitdefender、Docker)都指出MCP存在命令注入、令牌泄露、会话劫持等高危漏洞,CVSS评分高达9.6。一周年更新中的这些安全补丁,本质上是对过去一年中暴露问题的修复,而非前瞻性的安全设计。

最后是Sampling with Tools的引入。新规范允许MCP服务器发起自己的采样请求(sampling requests),并在请求中包含工具定义(tool definitions)。这使得服务器端可以运行自己的智能体循环,利用客户端的令牌执行多步推理任务。这一特性对于构建复杂的多智能体系统至关重要,但它的姗姗来迟也说明MCP在初始设计时并未充分考虑服务器端的主动智能体能力。相比之下,这种双向通信能力正是A2A协议的核心设计理念之一。

总体来看,MCP一周年的更新更像是一次"亡羊补牢"式的修复。Tasks、CIMD、安全强化、服务器端智能体能力,这些本应在协议设计之初就考虑周全的特性,却在一年后以"实验性"或"补丁"的形式陆续加入。这种渐进式的演进固然体现了社区驱动的灵活性,但也暴露出MCP在架构前瞻性上的不足。

如果说MCP代表了"工具连接器"时代的思维惯性,那么A2A则开启了"智能体协作"的新纪元。这两种协议的差异,不仅仅是技术实现的不同,更是对AI智能体本质理解的分野。

MCP的核心设计理念是单向通信。它假设存在一个中心化的"宿主"(Host),比如Claude Desktop或Zed编辑器,这个宿主通过MCP客户端连接到多个MCP服务器,从服务器获取资源(Resources)、提示词(Prompts)和工具(Tools)。整个交互是同步的、短时的、由客户端发起的。这种设计在简单的工具调用场景下非常高效——比如让AI助手查询数据库、读取文件、调用API。但当场景复杂化,需要多个智能体协作完成长时任务时,MCP的单向、同步模型就显得力不从心了。

A2A则从一开始就瞄准了多智能体协作场景。它定义的是"智能体与智能体"之间的对等通信,每个智能体既可以是客户端也可以是服务器,双向异步通信是协议的基础能力。A2A引入了Agent Card(智能体名片)机制,每个智能体通过一个JSON格式的卡片自我描述,包含支持的能力、联系方式、协议版本等信息。客户端智能体通过Agent Card发现远程智能体的能力,协商合作方式,然后通过Task抽象管理长时工作流。Task在A2A中不是"实验性"的补丁,而是核心设计——每个Task都有完整的生命周期管理,支持状态追踪、进度更新、Artifact(工作成果)输出。这种设计天然适配复杂的多步骤、多智能体协作场景。

在安全性上,A2A采取了"Secure by Default"的设计哲学。协议从底层就内置了企业级身份认证、基于角色的访问控制(RBAC)、审计日志等特性。它基于HTTP、Server-Sent Events(SSE)、JSON-RPC等成熟的Web标准,安全模型经过数十年互联网实践的验证。相比之下,MCP的安全性是"后补"的——OAuth集成经历了多次迭代,会话管理存在URL中暴露sessionId的风险,工具描述未经签名验证可能被恶意篡改。这种"先上线、后打补丁"的做法,在企业级应用中风险极高。

更深层次的差异在于协议的扩展性。MCP在一周年更新中引入了Extension(扩展)机制,允许在不修改核心规范的情况下添加新能力。但这种设计本身就暗示了MCP核心协议的僵化——当协议无法灵活应对新需求时,才需要通过扩展机制打补丁。这种做法虽然避免了频繁的核心协议变更,但也带来了生态碎片化的风险:不同厂商可能实现不兼容的扩展,导致互操作性问题。A2A则通过Agent Card和Task抽象提供了更灵活的扩展空间,新能力可以通过Agent Card中的能力声明自然融入,无需额外的扩展机制。

从生态系统的角度看,A2A获得了更广泛的行业支持。Google Cloud联合Atlassian、Salesforce、Workday、GitLab等50余家科技巨头共同推动A2A标准,这种"联盟式"的发展模式降低了单一厂商的控制风险,也更容易在企业市场获得信任。MCP虽然也在迅速增长(官方注册表已收录近2000个服务器),但其生态主要集中在开发者工具和个人生产力场景,在需要严格安全和合规审计的企业场景中,部署难度明显更高。

在智能体通信协议快速演进的今天,技术决策者和开发者需要一个高质量的交流平台,深入理解这些变化背后的技术逻辑和实践路径。2025年11月16-17日举办的Agentic AI峰会,正是这样一个不容错过的机会。

本次峰会聚焦汇聚了来自京东、快手、阿里、OPPO等头部科技公司的技术专家。峰会议题覆盖智能体技术栈的全链路,从底层模型到开发工具,从单智能体决策到多智能体协作,从理论探索到工业实践。

在多智能体协作方向,峰会将深入探讨"基于上下文工程与多智能体的自主服务新形态"议题。这一议题直接对应本文讨论的MCP到A2A的演进——如何设计安全、高效、可扩展的智能体间通信协议?如何平衡单向工具调用与双向协作的需求?如何在保证互操作性的同时避免生态碎片化?这些问题的答案,将直接影响未来几年智能体技术的发展方向。

在智能体决策与执行方向,"Agent的多请示与执行"以及"增强agent的决策"两大议题,将聚焦智能体的自主性与可控性平衡。MCP一周年更新中引入的Sampling with Tools特性,正是为了增强服务器端智能体的决策能力;而A2A的Task抽象,则提供了更完善的长时决策链管理机制。峰会将通过实际案例,展示这些技术在生产环境中的应用效果。

此外,峰会还将涵盖"Agent Dev Tool"、"AgentOS AI智能体生态"等议题,帮助开发者了解最新的智能体开发工具链,以及如何在复杂的智能体生态中进行技术选型。对于技术决策者而言,这些议题将提供从技术债务规避、投资回报率评估到团队能力建设的全方位视角。

MCP一周年的更新,既是对过去一年实践的总结,也是对未来方向的探索。Tasks、CIMD、安全强化、服务器端智能体能力等特性的引入,让MCP在工具连接场景之外有了更多可能性。但与此同时,A2A协议的崛起,预示着智能体通信正在从"工具调用"向"协作网络"演进。这不是一场非此即彼的竞争,而是技术演进中的自然分化:MCP适合单智能体、短时、工具密集型场景;A2A则更适合多智能体、长时、协作密集型场景。

对于技术决策者而言,理解这种演进趋势至关重要。选择MCP还是A2A,不仅仅是选择一个协议,更是选择一种技术路线和生态立场。而Agentic AI峰会,正是深入理解这些选择、避免技术债务、把握行业趋势的绝佳机会。在智能体技术快速迭代的今天,保持对前沿技术的敏感度,参与行业对话,将是每个AI从业者不可或缺的能力。