你好，我是黄佳。
AI时代的时间仿佛被按下了加速键。自从2023年的专栏《LangChain实战课》和2024年的《大模型应用开发实战课》收尾之后，我有一年时间没和大家见面了。而仅仅是这一年之间，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：模型主控，客户端驱动
Model Context Protocol（MCP） 翻译成中文是模型上下文协议。“模型”“上下文”和“协议”这三个词我们每个都认识，拼在一起就显得有点故弄玄虚。
其实MCP就是一个为大模型更方便的利用外部资源（主要是工具）而设计的标准化接口，旨在打破模型与外部数据、工具之间的壁垒。
传统上，将 AI 系统连接到外部工具需要集成多个 API。每个 API 集成都意味着单独的代码、文档、身份验证方法、错误处理和维护。这些API 就像一扇扇独立的门，每扇门都有自己的钥匙和规则。
让我们举例子来说。你看，在引入 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这个标准化协议，就能将 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 开发门槛被一举摁平。
这样，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不仅是协议，更是通向未来的桥梁。它们不仅具有代表性，能够为开发者提供实用指导；更具有生命力，能作为底层协议沉淀下来，持续创造价值。让我们共同踏上这条技术演进之路，探索大模型应用的无限可能吧！
精选留言
2025-06-18 10:01:08
2025-06-22 16:57:30
2025-06-24 18:23:59
2025-06-20 10:51:40
2025-06-09 00:45:49
基于目前的了解，市面上的AI应用平台，主要是下沉通用的工程能力，降低开发门槛。目前还没有具体动手，但预感如果简单应用和引入当前的AI应用平台，应该只能泛泛地解决浅表问题。深入的落地，还需要结合企业数据，并借鉴框架和算法的思想，不断调优。
通过最近对MCP和A2A的了解，感觉未来这些具体的优化工作可以沉淀为标准化MCP server的能力。除引入AI应用开发平台外，在企业构建MCP server，推广MCP及A2A协议，也能提升工作的复用。在开发平台上，规范agent实现A2A协议，加上编排能力，有点类似于iPaaS，在不同agent之间碰撞出火花，实现1+1>2的能力。
刚开始接触，希望能够跟着实战并迭代认知。如理解有偏差，请帮忙指正，谢谢。
2025-06-25 16:35:51
MCP让AI能更好的使用外部工具的协议，A2A是为了让不同Agent更好的协作，这些都是技术层面的。
但我一直有个疑问， 这些工具的所用者是否有动力去开放自己的能力？
- 工具类的，如果能通过api调用收费，也许有动力。
- 资讯类的或者需要用户去访问的，是否还有动力？甚至应该会抵制吧？ 比如美团开放点外卖接口？ 如果能把广告收入如何巧妙的在接口中实现，也许会开吧。 还有很多app需要用户去打开，去看广告，需要广告主去排序竞价，这些如果都让ai去访问，用户都到AI聚合平台， 那这些工具提供厂商都喝西北风去了。。。
有人不想开放，有人就会拥抱开放。 特别是盈利模式不是需要真人去访问（包括广告），比如数据库。
当然，这是个趋势，如果势能达到一定程度，也许某些行业的头部不开放，那下面的也许会拥抱ai，获得流量。
这是一场大变革，未来会有很多公司死掉，也会有很多崛起。
针对app，ai时代生存法则：要么下沉为基础设施（如顺丰接入所有电商平台），要么上浮到控制层（如Sora统治视频创作），滞留中间层的玩家最危险。 而中间层，也许就只剩下协议、通道、交互...胡思乱想，胡说八道，继续学习吧，也许就是知道的太少，想得太多。
2025-06-09 17:08:42
2025-06-10 18:15:56
2025-06-09 16:36:58
2025-06-18 22:08:14
2025-06-11 12:00:54
2025-06-09 11:30:34
这句话我觉得有一个前提，是具体实现其他人在MCP 平台帮你做好了，不然的话也没东西可以用，MCP只是协议而已
2025-06-09 09:51:31
2025-07-15 14:07:14
2025-07-10 12:19:28
2025-06-25 16:14:12
2025-06-13 12:58:44
2025-06-13 08:22:18