三个正在改变 AI 产品的缩写词

当下，有三个缩略词（Acronyms）正在重塑真实世界的 AI 产品构建方式：RAG、MCP 和 A2A。

大多数开发者对其中至少一个有所了解，但能清晰划清三者边界的人却寥寥无几。而这个认知鸿沟，恰恰解释了为什么一个 Agent 在 Demo 中可以看起来很"魔法"，到了生产环境却变得缓慢、混乱，甚至真的不安全。

所以，让我们把这些碎片拼接起来。我们将跟随一个名为 Atlas 的 Agent，一层一层地构建它。先用大白话讲清楚脉络，再层层叠加技术实现，最后串起整张协作全景图。每当 Agent 撞上一堵墙，我们就引入栈中恰好解决那个问题的那个组件。到本文结束时，你将真正理解这些系统是如何配合在一起的。

---

起点：API——软件通信的基石

要看清 AI 软件的走向，我们首先需要理解软件几十年来是如何通信的。这个故事从 API 开始。

API 是两个程序之间的合约。它定义了你可以请求什么、请求必须如何格式化、以及返回什么。如果你向预期的端点发送预期的输入，你就会得到一个可预测的响应。这种可预测性，正是 API 的全部意义所在。

现代互联网的大部分都运行在 API 之上：天气应用查询预报、在线商店处理支付、即时通讯服务发送通知——所有这些都是 API 的工作。传统软件之所以能可靠地处理这些任务，是因为开发者在事前就规划好了整个执行序列。

---

当 LLM 闯入这个精细编排的系统

然后，我们把一个大语言模型放进了这个被精心编排的系统里。

输入不再是一个整齐的表单了。有人可能会说：

“帮我找个好航班，避开过夜转机，确保我不会错过周一的会议。”

现在，系统必须理解这个模糊的自然语言请求，从中拆解出用户的真实意图；接着查询多个彼此独立的服务——航班、日历、报销政策；必要时追问后续问题来补全缺失信息；还要在拿到新数据后动态调整自己的计划，而不再是沿着一条预设路径一路走到底。

模型或许能理解目标，但 API 依然需要精确的指令：调用哪个端点、发送哪些字段和数据类型、使用什么凭证、出错时如何处理。

这就像一个才华横溢的新员工被扔进一个满是控制面板却没有标签的房间——他知道该做什么，但面对密密麻麻的按钮和接口，他不知道哪个是"查航班"、哪个是"看日历"、哪个是"发邮件"——智能并不会自动生成接口。

---

第一个权宜之计：暴力描述

我们最初的对策是"暴力法"：把每一个函数都描述给模型。例如，“当用户查询航班时，调用这个函数，提供这些字段，期望返回这种格式的数据”。

在小规模下这确实可行。但如果加上 10 个工具，指令文本就会膨胀到不可维护。每当你需要修改一个 Schema，有些东西就可能悄无声息地失败。

本质上，我们是在把一层灵活的推理系统附着在一堆僵硬的集成之上——一次一个自定义连接器。

必须有更干净的方法。但在到达那里之前，我们需要一个带有真实任务的 Agent。

---

认识 Atlas：你的终极旅行助手

在接下来的内容中，我们将一起构建一个假想的 AI Agent。来认识一下 Atlas。

Atlas 只有一个工作：成为终极的个人旅行助手。

你对 Atlas 说：“帮我规划三月的东京之旅。”

Atlas 应该理解你的偏好、查看你的日程、搜索航班和酒店、在必要时请求审批、并帮助你完成预订。

这听起来只是一个请求，但从架构上看，它是一堆完全不同的问题。Atlas 几乎立刻就撞上了第一堵墙。

---

第一堵墙：知识，但没有知识

你看，Atlas 由一个大语言模型驱动。模型可能对东京了如指掌——街区、美食、地铁线路、常见的旅行建议——但它不知道你的护照将在四月过期、你拥有航空里程积分、以及你公司规定可报销的航班上限。

这些事实是私有的、特定于你的，而且随时可能变化。它们从未出现在模型的训练数据中。而当一个模型即使不知道答案也能听起来充满自信时，它可能会用一个貌似合理但实际错误的答案来填补空白。

这就是幻觉（Hallucination）。

你可能会本能地反问：“为什么不直接用我的数据训练模型？”

微调 Atlas 确实可以教会它行为模式、语气和重复的工作流程。但它不是一个可靠的、用于频繁变化的事实的数据库。当你续签护照或消费积分后，模型存储的知识就过时了。

更聪明的做法

更聪明的做法很简单：不要强迫模型记住变化的事实。让应用程序在需要时检索相关事实。

这就是 RAG——检索增强生成（Retrieval Augmented Generation）。

把它想象成"开卷考试"。模型依然进行推理，但它首先会收到一个包含与当前问题最相关信息的小型证据包。

RAG 的基本流水线

1. 1. 导入文档：旅行政策、偏好设置、行程笔记等
2. 2. 切分为有用的片段并建立索引：索引可以使用关键词搜索、语义嵌入（semantic embeddings），或二者的混合
3. 3. 当请求到达时：系统应用用户权限，检索最强匹配项，并将这些段落放入模型的上下文中，然后才开始生成

所以，Atlas 不是在"记住"你的护照记录——它是在需要的那一刻读取一份被授权的副本。这让答案更加新鲜，也更容易验证。

这就是 RAG 出现在如此多的文档助手、客服机器人、企业搜索工具和编程产品中的原因。

RAG 的本质是一种系统模式：检索有用的证据，然后在证据的上下文中生成答案。

---

但 Atlas 仍然不能行动

到了这个阶段，Atlas 可以找到你的特定数据了。但如果你在买咖啡时登机口变更了，聊天框里的答案毫无用处——Atlas 必须真的触达你。

更重要的是，RAG 给了 Atlas 上下文，但没有给它能力和权限。

RAG 可以告诉 Atlas 一项政策说了什么，但它不能让 Atlas 修改预订或批准付款。检索到的材料也需要被谨慎处理：

• • 一份过时的政策可能误导模型
• • 一份恶意文档可能包含旨在劫持模型的指令
• • 一条护照记录可能暴露远超当前任务所需的个人信息

Atlas 现在能给出更有依据的建议了，但一个文档索引不会查询实时票价、不会锁定舱位、也不会更新你的日历。

检索回答了"Atlas 需要知道什么"，但没有回答"Atlas 可以做什么"。

我们给了 Atlas 一个值得信赖的文件夹，却让它被困在一张够不着操作面板的桌子后面——知道该做什么，却什么也做不了。

知识，却没有行动。这是 Atlas 的第二堵墙。它需要工具。

---

函数调用：行动的第一步

显而易见的下一步，是把 Atlas 的主程序连接到航班 API、日历 API 和邮件 API。

函数调用（Function Calling） 给了 Atlas 一种结构化的方式来请求一个行动。它可能提议 search_flights，附带出发地、目的地和旅行日期。

主程序检查请求、运行代码，然后将结果送回给 Atlas。Atlas 再决定下一步做什么。

这个循环——模型发起请求、主程序检查、工具执行任务、结果返回——是大多数有用的 AI Agent 背后的基本引擎。

但函数调用并不能一键连接所有东西。对于每个服务，开发者仍然需要做大量手工工作：

• • 阅读服务的 API 文档
• • 在编码时匹配其数据格式
• • 决定模型到底被允许看到什么、做什么

然后团队还要为酒店、日历、邮件、支付和内部数据库重复同样的工作。其他团队又在构建他们自己版本的相同连接器。最终的结果是一大堆把一切粘合起来的自定义代码，而且每当一个服务改变了数据格式，开发者就得更新和维护那些代码。

整个行业在用略微不同的方式反复解决同一个连接问题。

---

MCP 登场：模型上下文协议

这就是 MCP 进入故事的时刻。

**MCP（Model Context Protocol，模型上下文协议）**由 Anthropic 于 2024 年 11 月作为开放标准引入，使不同公司可以使用相同的方法。此后，许多 AI 产品和开发者工具都采纳了它。

它之所以传播开来，一个原因是：几乎所有 AI Agent 都需要同一件事——一个让主程序连接到外部工具和服务的清晰方式。MCP 提供了那个共享的连接点。

USB-C 的类比

流行的说法是：MCP 是 AI 应用的 USB-C。

这个类比很有用，前提是我们理解它承诺了什么、不承诺什么。

USB-C 给设备提供了通信连接的通用方式。但使用 USB-C 配件并不自动意味着它是安全的、经过批准的、或与所有功能兼容。

MCP 以类似的方式工作。它标准化了 AI 应用如何与外部工具或服务对话，但它并不会替你处理一切。你仍然需要登录检查、权限控制、数据验证和应用程序自身的业务规则。

MCP 如何工作

假设一个日历服务运行了一个 MCP 服务器。该服务器可以发布一个名为 find_open_time 的工具、解释其功能、并提供一个机器可读的输入 Schema。航班服务可以用同样的方式提供 search_fares 和 hold_itinerary 等工具。

因为两个服务都使用 MCP，每个 AI 应用都以相同格式接收工具描述和输入要求。开发者不再需要为每个 AI 应用创建不同的连接格式。

在另一边，运行 Atlas 的应用程序是 MCP 主机（Host）。主机内部会为每一个 MCP 服务器创建一个对应的 MCP 客户端（Client）——就像给每个外部服务分配了一个专属的"翻译官"。主机维护着一张工具注册表，记录了"哪个工具属于哪个客户端"。

连接的触发时机通常有两种：一是应用程序启动时主动建立，提前备好工具清单；二是收到用户请求后按需建立，延迟到真正需要某个服务时才连接。无论哪种方式，一旦连接启动，流程如下：

1. 1. 握手：客户端与服务器相互介绍，约定各自支持的协议能力
2. 2. 发现工具：客户端向服务器询问"你能提供哪些工具？"，服务器返回一份包含工具名称、功能描述和输入 Schema 的清单
3. 3. 汇总注册：主机将所有服务器返回的工具清单汇总，并记下每条工具的"归属"——find_open_time 来自日历服务器、search_fares 来自航班服务器
4. 4. 注入模型：主机将汇总后的工具描述列表提供给模型，模型据此在推理时决定调用哪个工具
5. 5. 路由执行：当模型建议"调用 search_fares"，主机查注册表，找到对应的航班服务器客户端，由该客户端将请求发送到正确的服务器

底层消息使用更新版的 JSON-RPC。本地服务器通常通过标准输入/输出通信，远程服务器通常通过 Streamable HTTP 通信。

核心思想很简单：每个兼容的连接都遵循相同的对话语法。这才是真正的变革。

Atlas 的主程序不再需要为每个集成自定义一种发现方式。每个连接的服务都可以用相同的标准格式描述自己能做什么。

如果你在用 Codex 这类 Agent 工具，一个再常见不过的场景就是它自动打开浏览器帮你操作网页、调试代码——这背后正是通过 MCP 把 node_repl 注册为本地子进程，让 LLM 能安全地执行 JavaScript 来控制浏览器。关于 node_repl 的完整技术拆解（协议握手、懒启动、工具注册、首次调用时序、架构图等），我会在后续专题中深入展开，欢迎关注。

---

两个重要的澄清

1. MCP 不会取代 API

营销话术有时会让架构听起来比实际更"魔法"。事实上，MCP 服务器可能架设在现有的 REST API 之上。API 依然是使用服务的底层规则集。MCP 只是给 AI 应用提供了一种标准方式来发现和使用该服务。

所以，选择不是"MCP 还是 API"。在许多真实系统中，MCP 工作在 API 之上。

2. MCP 服务器提供的不仅是"动作"

MCP 服务器还可以提供：

• • 资源（Resources）：文件或数据库记录
• • 提示（Prompts）：用于启动交互的可复用模板

例如，RAG 流水线中的文档可以被暴露为 MCP 资源。但 MCP 并不会替我们搜索这些文档或生成答案——它只是给应用程序提供了一种标准方式来访问源材料。应用程序仍然需要搜索文档、按相关性排序结果、检查谁有权查看、并将支持性证据传入模型的上下文。

---

从工具到协作：Atlas 的第三堵墙

到这一步，Atlas 已经强大得多了。它的主程序连接到日历服务器、航班搜索服务器和邮件服务器。Atlas 现在可以检查日程冲突、临时锁定票价、并草拟确认邮件。

注意这些措辞：搜索、锁定、草拟。我们还没有给 Atlas 自行花钱的权限。主程序仍然需要护栏：只允许受信任的服务器、给每个服务器它所需的最小凭证。

Atlas 现在可以检索它需要的信息，也可以请求使用它需要的工具了。这肯定意味着我们大功告成了吧？

这正是许多 Agent 架构图停下来的地方。

但在真实组织中，Atlas 很快会撞上第三堵墙。挑战不再是简单地访问一个工具——Atlas 现在必须与另一个拥有自己规则和职责的独立系统协调工作。

我们给它的选项越多，它就越有可能选错工具、追踪过多信息、或在意想不到的地方失败。

---

专业化：Agent 的角色分离

真实的组织不会把每一项职责都交给同一个员工。他们使用专家：每个专家负责一个较小的任务，并把工作交给其他人。

Agent 系统可以使用相同的模式：Atlas 处理旅行，而财务 Agent 和航空公司 Agent 处理各自的领域。这分离了职责和权限，但也带来了延迟、协调问题和安全风险。

然而，这些 Agent 仍然需要一种方式彼此对话——尤其是当它们以不同方式构建或由不同公司拥有时。

---

A2A：Agent 间的通信协议

如果两个 Agent 位于同一个应用内部，应用通常可以直接协调它们。**Agent-to-Agent（A2A）**在 Agent 属于不同团队或公司、需要一个共享的协作方式时变得有价值。

Google 于 2025 年 4 月推出了 A2A，得到了众多技术公司的支持。它的目标很简单：

帮助独立的 AI Agent 协同工作，即使它们由不同团队或公司使用不同技术构建。

A2A 给 Agent 提供了一种共享的方式来：

• • 发现彼此的能力
• • 交换消息
• • 管理任务
• • 交付最终结果

Agent Card：服务卡片，而非社交主页

A2A 的一个重要组件是 Agent Card（Agent 卡片）——一张机器可读的信息表，告诉其他系统如何与某个 Agent 协作。

卡片可以包含：Agent 的名称、在哪里联系它、它能做什么、接受和返回哪些数据格式、以及用户如何登录。

把它想象成一张服务卡片，而不是社交主页。它告诉你 Agent 声称自己能做什么，但它不证明 Agent 是安全或可信的。

这个区分很重要。Atlas 只应该通过受信任的来源找到财务 Agent——比如公司的官方域名、直接配置、或一个经过批准的目录。

接下来，Atlas 使用要求的登录方式证明自己的身份。最后，财务服务决定 Atlas 被允许做什么。

仅仅找到一张 Agent 卡片并不会赋予 Atlas 分享公司数据或批准采购的权限。

A2A 的协作流程

一旦连接建立，Atlas 可以请求财务 Agent 批准特定的旅行计划。如果审核需要时间，财务 Agent 可以：

• • 创建一个任务
• • 分享更新（如"已提交"、“处理中”）
• • 要求补充缺失信息
• • 返回最终的批准记录
• 

---

MCP vs A2A：最简单的区分方式

协议	核心用途
MCP	帮助 AI 应用使用来自另一个系统的工具
A2A	帮助独立的 AI Agent 协同工作完成一个任务

---

Atlas 的完整旅程：一个请求的全貌

最后，让我们走一遍 Atlas 为你预订机票的完整过程——从一个请求开始。

你说：“Atlas，帮我预订三月第二周的东京之旅。”

第一步：获取事实（RAG）

Atlas 通过 RAG 只检索它需要的信息：

• • 你的偏好
• • 公司政策
• • 积分余额
• • 护照到期日（而不是完整的护照扫描件）

如果有什么看着有风险，Atlas 会标记它，而不是猜测。

第二步：调用工具（MCP）

MCP 让 Atlas 得以检查你的日历、搜索实时票价。主程序批准每个工具调用、验证每个请求、记录每个操作。

Atlas 找到了合适的航班并锁定了票价。

第三步：跨 Agent 协调（A2A）

票价超出了公司的报销上限，所以 Atlas 只将行程和价格通过 A2A 发送给财务 Agent。

财务 Agent 返回一份绑定到该具体行程、金额和有效期限的批准。

第四步：确认与执行

Atlas 仍然不直接购买。它重新检查价格、向你展示最终金额、等待你的确认。

当你说"是"，Atlas 执行预订且不会产生重复购买的风险。它保存收据、更新日历、发送行程。

---

一个请求，四个清晰的角色。

从最初的 API 到 LLM 的接入，从 RAG 弥补知识的缺口，到 MCP 标准化工具的连接，再到 A2A 让 Agent 之间可以协作——这就是一个生产级 AI Agent 的全栈图景。

这些协议不是互相替代的零和博弈，而是一层一层叠加的能力：RAG 解决"知道什么"，MCP 解决"能做什么"，A2A 解决"和谁协作"。理解它们在栈中的确切位置，才是从 Demo 走向生产的关键。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】