开篇词｜浪潮拐点——为何MCP与A2A诞生在此时此刻？

黄佳

讲述：机器人大小：6.61M时长：19:14
你好，我是黄佳。
AI 时代的时间仿佛被按下了加速键。自从 2023 年的专栏《LangChain 实战课》和 2024 年的《大模型应用开发实战课》收尾之后，我有一年时间没和大家见面了。而仅仅是这一年之间，AI 的世界已经发生翻天覆地的巨变。
AI（和人类）的世界经历着前所未有的巨变，真可谓 AI 一年，人间十年！
OpenAI 的 o1/o3 系列模型能够实现深度推理与严谨分析；AI 编程工具 Cursor、Winsurf 可以快速生成和优化代码，几近替代了初级程序员的日常工作；Anthropic 的 Computer Use 和 OpenAI 的 Operator 能够通过屏幕控件直接操控计算机的操作界面；DeepSeek-R1 以极低的训练成本和强大的推理能力，在一夜之间缩短了中美两国在 AI 大模型领域的差距；当我们还沉浸在 DeepSeek 成功的激情和喜悦中，心情尚未平复时，Manus 智能体又带着一些神秘在深夜登台……
技术更迭令人目不暇接，新工具刚问世，就有成百上千个类似的竞品紧随其后；新模型迅速取代旧模型，甚至在其广为人知之前便已被更新的技术超越。每一项技术突破都如同汹涌的海浪，不断冲击并拓展着我们对于 AI 的认知边界，重塑 AI 应用开发能力的边界。
大模型应用工程化过程的三大难题大模型尽管可以作为智能系统的“核心引擎”，但大模型应用走向深水区的背景下，工程化挑战如影随形。开发者面临三大难题：
1.模型与外部世界的割裂：大模型是基于概率计算的新范式，其思维、推理能力类似于人脑。这种新范式虽强大，但仍需要与传统的结构化计算范式相结合，也就是通过工具调用来完成精确任务。而目前传统结构化工具和大模型之间是割裂的，大模型难以直接、动态地接入实时数据、数据库或企业工具。传统的 API 调用方式零散且不标准，导致开发效率低下。
2.Agent 协作的孤岛效应：AI Agent 的兴起让“做事”的智能体成为可能，但不同框架（如 LangGraph、AutoGen、CrewAI）各自为政，缺乏统一的通信标准，跨平台协作如同“鸡同鸭讲”。
3.复杂场景的工程化瓶颈：从搜索助手到企业知识中台，RAG（检索增强生成）与多 Agent 系统需要处理多源数据、多模态交互和长时任务，现有工具链难以提供统一的解决方案。
就在此时，MCP 和 A2A 应运而生，恰如涓涓细流汇聚成江河，为“模型主控、客户端驱动”的范式提供了标准化、可扩展的协议层。它们解决了上述痛点，为大模型应用的工程化铺平了道路。
MCP 和 A2A 协议的横空出世使本就热闹的 LLM 开发生态又添波澜
对于这两个新技术，你可能还有些陌生，我们先不用特别纠结名词本身，可以先看看它们的核心理解，以及解决了什么问题，这样更容易抓住其本质。
MCP：模型主控，客户端驱动Model Context Protocol（MCP） 翻译成中文是模型上下文协议。“模型”“上下文”和“协议”这三个词我们每个都认识，拼在一起就显得有点故弄玄虚。
其实 MCP 就是一个为大模型更方便的利用外部资源（主要是工具）而设计的标准化接口，旨在打破模型与外部数据、工具之间的壁垒。
传统上，将 AI 系统连接到外部工具需要集成多个 API。每个 API 集成都意味着单独的代码、文档、身份验证方法、错误处理和维护。这些 API 就像一扇扇独立的门，每扇门都有自己的钥匙和规则。
开发人员为每个服务或数据源编写自定义集成 图源 https://norahsakal.com/blog/authors/norah/
让我们举例子来说。你看，在引入 MCP 之前，如果我要让一个 Agent 同时具备“网络搜索”“数据库查询”“文本翻译”三种能力，通常要写三套适配器：
搜索工具：手动拼 HTTP 请求，处理 OAuth 鉴权，解析 HTML 或 JSON，捕获请求超时。
数据库查询：配置 JDBC/ODBC 连接，管理连接池，拼装 SQL，逐行读取 ResultSet。
翻译服务：对接 Google Translate 或腾讯翻译 API，关注签名算法、流量限速、错误码处理。
每接入一个新工具，都要重复以上流程，代码冗余且难以维护，扩展成本极高。
MCP 则把这些繁琐细节都“藏”到服务器端：
1. 服务端只需注册好 Search、QueryDB、Translate 三个工具能力；
2. 然后 Agent 发起同一套 JSON-RPC 调用：
{
  "method": "callTool",
  "params": {
    "tool": "Translate",
    "input": "Hello, world!",
    "target_lang": "zh"
  }
}
3.MCP 服务器负责底层的 HTTP 请求、鉴权、连接管理和结果解析，最后把翻译结果一并返回给模型。
这样，开发者只需关心“模型想用哪个工具做什么”，再也不用为每个服务写一大堆样板代码，Agent 的功能扩展也瞬间变得“即插即用”。
因此，它是一个客户端 - 服务器的架构，其核心理念是“模型主控、客户端驱动服务器调用”——模型负责推理和决策，客户端则动态提供上下文、工具和资源，而这些工具和资源则由外部服务器来提供。
MCP 客户端整合了各种外部服务器资源，可以在需要时进行调用 图源 https://norahsakal.com/blog/authors/norah/
现在我们有了 MCP 这个标准化协议，就能将 AI Agent 轻松的连接到各种外部工具和数据源。你可以将其想象成一个专门为 AI 应用提供的 USB-C 端口，即插即用。所有繁琐的事情，都推给 MCP 服务器根据协议来提供。
好，看清楚了这个过程，我来考考你——传统的 OpenAI Function Calling、LangChain 框架中的 Tools 或 JSON-RPC 相比，MCP 到底有何不同？
我的答案是：尽管 OpenAI Function Calling、LangChain 的 Tools 让大模型能够实现工具调用，但它们都没能真正砍掉 Agent 或大模型应用开发的“高墙”。
1.OpenAI Function Calling 只绑在 GPT 系列上，其调用规范、参数定义和返回格式都深度耦合在 OpenAI 的 API 流程中，无法扩展到其他开源或私有模型。
2.LangChain Tools 虽然支持多种模型和工具，但所有能力都要写在 LangChain 的框架里——跨框架、跨语言、跨团队复用时，得重造一套适配逻辑。
JSON-RPC 作为通用远程调用协议，轻量却太过底层：它只管“发什么请求、收什么响应”，但显然不包含大模型的上下文管理、并发会话、流式返回、能力发现等核心需求。
它们解决了“怎么调”或“调哪个好”这一维度的问题，却没形成一套“面向大模型 + Agent 协作”的统一、可插拔、开箱即用的接口规范。
MCP 则在 JSON-RPC 之上，专门为大模型量身定制了：
统一工具描述：所有 Search、Translate、QueryDB 等能力用同一份 tool.json 注册，模型只按名字“call”就行。
会话与权限：自动管理多轮对话状态、工具访问权限与鉴权流程，模型无需关心鉴权细节。
流式与事件：内建流式数据返回、异步回调和事件订阅，让长任务、实时监控、异步通知都能自然融入推理流程。
多传输层：既可跑 HTTP/REST，也可挂 WebSocket、RPC 框架或消息队列，灵活适配不同部署场景。
MCP 真正把“模型想用什么工具干啥”这件事变得极其简单——大模型专注决策，开发者专注业务逻辑，Agent 开发门槛被一举摁平。
一套“面向大模型 + Agent 协作”的统一、可插拔、开箱即用的接口规范
这样，MCP 的统一接口让开发者无需为每个场景定制协议，显著降低了工程化成本。 正如 B 站一位视频博主所分享的那样：在他们的项目里，为了让一个智能体同时支持网络搜索、数据库查询、文件格式转换等功能，团队最初写了超过 2000 行的适配器代码；而引入 MCP 之后，所有底层细节都由 MCP 平台统一托管，团队只需保留核心决策和业务流程，代码行数骤降至 500 行以内，开发效率提升了 4 倍以上。
说清楚了 MCP，我们再来说 A2A。
A2A：Agent 间的“通用语言”Agent-to-Agent，翻译过来就是“智能代理之间的协议”，听起来又是一个高大上的名词，但本质上讲，它其实就是让不同的智能代理（Agent）能够无障碍地沟通和协作的标准语言。可以把它理解成大模型 Agent 们用来“聊天”的“通用语言”。
Agent 与 Agent 之间的交互，和人类之间的沟通有点类似：不同的人会有不同的能力，每个人只能做自己擅长的事情，但为了共同完成一项任务，必须不断地交换信息、共享知识、甚至协同合作。我们人类解决复杂问题时，会分工明确、相互协作；大模型时代的 Agent 们亦如此。但问题在于，不同的开发者、公司和团队可能会创造出各种各样的 Agent，如果每个 Agent 都有自己的一套沟通方法，那必然是鸡同鸭讲，造成混乱不堪的局面。
于是，A2A 协议应运而生了：它定义了一套清晰、标准的沟通方式，让所有智能代理可以顺畅地交流彼此的需求、能力、决策和状态。Agent 们通过 A2A 沟通，就像大家都学会了同一种语言，不管来自哪个“国家”，都能顺畅无阻地交流、互相配合完成任务。
我们还是用一个简单的生活场景来说明 A2A 的运作机制吧。这里假设我们有三个 Agent，分别是旅行规划 Agent（Travel Planner），天气查询 Agent（Weather Checker），酒店预订 Agent（Hotel Booker）。
用户向旅行规划 Agent 发送“规划北京到上海 3 天行程”的请求，旅行 Agent 通过 A2A 协议依次发出两次标准化能力调用：
向天气查询 Agent 发送“请告诉我 5 月 20–22 日上海的天气预报”
向酒店预订 Agent 发送“帮我查 5 月 20–22 日上海南京路附近的四星酒店，预算每晚 800 元内”
各 Agent 按统一消息格式（能力发现→调用→异步返回）快速响应并返回天气和酒店信息，旅行 Agent 将结果整合并生成最终行程。
A2A 协议在这个过程中所负责的要点在于：
统一协议：所有 Agent 均使用同一消息 schema 进行能力发现与调用。
异步协作：支持流式与异步返回，可并发处理多任务。
灵活扩展：新 Agent 即插即用，无需额外适配器。
解耦实现：Agent 专注业务，底层传输、鉴权、错误处理由协议层统一管理。
这样从人类用户 → 旅行规划 Agent → 天气查询 Agent → 旅行规划 Agent → 酒店预订 Agent → 旅行规划 Agent → 最后回到人类用户。 整个过程中，不仅人类不需要了解 Agent 的讨论细节，就连这三个 Agent 彼此并不直接了解对方的内部细节，也不必知道彼此的实现方式，只是通过 A2A 协议标准化的信息结构和通信方式，就顺畅地完成了信息的共享与协作。
你看，通过这样标准化的沟通模式，不管是三个、三十个，甚至更多 Agent 的协同合作，都可以做到有条不紊。
综上，Agent-to-Agent（A2A）协议是一种开放标准，用于让不同平台和框架下的 AI 智能代理能够“说同一种话”，实现无障碍的信息交换和协作。
技术上来说，A2A 通过标准化的组件（如 Agent Cards）为 Agent 间的“相互发现与握手”提供了通用语言。它在 JSON-RPC、HTTP/SSE 等底层传输之上，定义了能力发现（通过 Agent 卡片以及标准化的能力定义）、会话管理、任务生命周期管理、消息与内容单元（Part）、权限认证、流式与事件等语义，使多智能体系统能够灵活拼接、异步协作，并具备企业级安全与可扩展性。
此外，A2A 支持长时任务、多模态协作（文本、图像、音视频），并强调企业级安全性，如 OpenAPI 授权和角色访问控制。与 MCP 的资源管理结合，A2A 使 Agent 能够动态协商任务分配，实时共享数据洞察。例如，一个基于 CrewAI 的客服 Agent 可以通过 A2A 与 LlamaIndex 驱动的知识检索 Agent 协作，共同完成客户问题的精准解答。
MCP 与 A2A：相似点与不同点讲完了 MCP 和 A2A，可能你会觉得这两个协议似乎很相似。这是真的，不是你一个人这样认为。它们的确从思路上就有很大的相似之处，确实都是标准化协议，都在大模型应用场景中实现信息交互和协作——而且解决的都是 AI 应用开发过程中的沟通协作问题。
那么它们相似点和不同点具体是什么呢？
简而言之。二者尽管相似，但是彼此并非竞争，而是互补的关系，且刚好形成了一个完整的 AI 时代的通信协议方案。
说了这么多，我再稍微总结概括一下 MCP 和 A2A 的价值。MCP 提供了统一的上下文管理与工具调用接口，整合了大模型驱动的概率计算与传统工具驱动的结构化计算。A2A 则为多 Agent 协同注入了开放标准。二者的结合，将单一 AI 应用推向分布式、模块化的智能生态。
这不仅是技术的跃迁，更是生态的重塑。未来的 AI 系统将不再是孤立的模型，而是由无数 Agent 和知识模块组成的动态网络。开发者可以轻松整合 MCP 的资源接入、A2A 的协同能力，构建高效、可扩展的解决方案。从搜索到企业中台，从单体智能到协同网络，MCP 和 A2A 正在为大模型应用的“最后一公里”铺路。
既然这两个协议如此重要，我们应该如何学习呢？接下来我就说说课程的设计思路，还有学完课程能给你带来的收获。
课程设计架构本课程以 “理论奠基 → 协议拆解 → 实战应用 → 综合实践” 为核心架构，分为四个模块，第一阶段共 15 课，覆盖从基础概念到企业级部署的完整学习路径。设计理念遵循从简单到复杂、从通用到专业的技术演进路径，确保你能循序渐进地掌握 Model Context Protocol（MCP） 和 Agent2Agent（A2A）协议的精髓。
课程注重实用性，通过贴近真实业务场景的案例驱动学习，将理论知识转化为生产力，帮助你解决大模型应用开发中的上下文管理、工具调用和多 Agent 协作等核心痛点。
详细的内容安排你可以参考后面的知识地图，不难发现我准备了很多个具体的实操案例，让你能通过工程化的训练，更好地理解和运用这两个协议。
课程知识地图
这套课程还有一些额外的好处，首先，学 MCP 协议的同时，又深入探索客户端 - 服务器的架构设计。其次，学 A2A 协议的同时，又学习了多种时下流行的 Agent 开发框架，等于是在学协议的同时，学最前沿的 Agent 开发实战，更可谓一举两得。
此外，这门课程中的所有代码都在 GitHhub 上面开源，你可以在（mcp-in-action）和（a2a-in-action）仓库下载代码，一起动手实操，并可以提交 PR 共同维护 Repo。这门课程涉及到的编程语言和技术栈，我也做了表格，供你参考。
UV 工具链接在这里。
另外还想说明一下，因为 MCP 和 A2A 还处于其生命周期的早期，因此我决定在课程第一阶段更新完毕的后续半年中，以每月 1-2 篇新内容的节奏持续更新课程至年底，看看未来 MCP 和 A2A 会带给我们怎样的持续惊喜。
奔涌而来的未来MCP 和 A2A 是技术浪潮中的耀眼浪花，有人把他们比作 Agent 加速发展的双引擎，这非常形象。前者是 Agent 调用传统工具的统一标准化接口，而后者则可以视为 Agent 间的互联（如 HTTP）协议。
这样的新兴技术迭代虽然迅速，却也为我们提供了弯道超车、拓展能力的绝佳机遇。希望大家都能成为“追风者”，主动拥抱快速学习的新节奏，用不断汲取的新知来武装自己，实现持续成长。
站在 2025 年的春夏之交，我们正在见证着 AI 潜力的全面释放。MCP 和 A2A 不仅是协议，更是通向未来的桥梁。它们不仅具有代表性，能够为开发者提供实用指导；更具有生命力，能作为底层协议沉淀下来，持续创造价值。让我们共同踏上这条技术演进之路，探索大模型应用的无限可能吧！
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
深入了解
翻译
英语
中文简体
法语
德语
日语
韩语
俄语
西班牙语
解释
总结
1. AI技术领域发展迅猛，出现了一系列新工具和模型，对大模型应用工程化提出了挑战。 2. MCP是模型上下文协议，为大模型更方便地利用外部资源设计的标准化接口，打破了模型与外部数据、工具之间的壁垒。 3. MCP的统一接口降低了工程化成本，极大地提升了开发效率。 4. A2A协议定义了一套清晰、标准的沟通方式，让所有智能代理可以顺畅地交流彼此的需求、能力、决策和状态。 5. A2A通过标准化的组件为Agent间的“相互发现与握手”提供了通用语言，使多智能体系统能够灵活拼接、异步协作，并具备企业级安全与可扩展性。 6. MCP提供了统一的上下文管理与工具调用接口，整合了大模型驱动的概率计算与传统工具驱动的结构化计算。 7. MCP和A2A的结合将单一AI应用推向分布式、模块化的智能生态，为大模型应用的“最后一公里”铺路。
2025-06-07给文章提建议
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《MCP & A2A 前沿实战》，新⼈⾸单¥59
立即购买
登录后留言
精选留言

由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论