1 前言

之前，我写过《从零理解 RAG》这个系列，一共有 3 篇（第 3 篇是两个常用框架 LlamaIndex 和 LangChain 的对比，因为我觉得内容比较单调，优先级不高，一直在给其他优先级更高的文章让位置，所以还没机会发出来），目的本来是为搭建博客聊天机器人这个项目做准备。

不过，为什么一直没有继续往下写呢？倒也不完全是因为懒，而是碰到了一个真实的问题：RAG 这个概念从理论到工程落地之间存在着一条不小的鸿沟。

我当时规划的路线其实很简单：理论 → 最小 Demo → 技术框架选择 → 真正可用的系统。然而，当走到第四步时，就会自然而然遇到一系列工程问题：

文档切片策略
Embedding 模型选择
向量数据库
Chunk 检索策略
Rerank
查询改写
在线更新
数据同步

继续深入下去，本质上已经不是在理解 RAG，而是在搭建一个完整的小型 AI 检索系统。而我的博客一直更关注技术为什么会出现、底层原理是什么，以及它解决了什么问题。因此，再继续深入这些实现细节，反而会逐渐偏离这个系列最初的目标，变成单调的 RAG 工程搭建步骤记录——而这种记录型文章，网上到处都是。

更关键的问题在于，随着新技术的不断出现与升级，大模型获得外部知识的途径也在逐渐增多。因此，我对 RAG 机制本身的研究仍然会继续，不过它在我当前关注的问题中的优先级，已经不像最初那么高了。

后来，在不断研究 AI Agent、知识工程以及各种 AI 应用的过程中，我慢慢发现，自己的关注点开始发生变化：过去，我一直在思考：如何让 AI 获得更多知识。而现在，我更关心另一个问题：AI 是如何从“知道更多”，逐渐发展到“做到更多”的？

2 当 AI 应用开始需要连接外部能力

早期的 AI 应用主要围绕文本交互展开：用户提出问题，应用调用模型生成回答。随着大语言模型(LLM)能力不断增强，模型在理解、推理和生成方面的能力逐渐提升，基于这些模型构建的 AI 应用也开始能够处理越来越复杂的任务，例如总结信息、编写代码、分析文本等。

但无论模型本身多么强大，AI 应用仍然存在一个天然限制：模型所掌握的知识主要来自训练数据，而训练数据存在明确的时间边界，也无法覆盖用户自己的私有数据。 这意味着，即使模型具备很强的理解和推理能力，它所掌握的信息仍然可能过时，也无法天然了解某个用户或组织内部的数据。

RAG 正是在这种需求下出现的：它通过引入外部知识库，在生成回答之前检索相关内容，再将检索结果提供给模型分析，从而让 AI 应用能够利用模型训练数据之外的信息。企业文档、个人笔记、产品资料等，都可以通过这种方式成为模型回答时可以利用的信息。

但当 AI 应用进一步面对真实世界中的具体任务时，仅仅获得外部知识仍然不够。例如，一个用户让 AI 分析服务器最近为什么变慢，AI 可能需要查看实时监控数据、查询日志、分析配置变化，甚至执行修复操作。这时，问题已经从 “如何获得外部知识” 进一步变成了 “如何访问外部系统并执行操作”。

这也是 Agent 概念出现的重要原因：Agent 让 AI 应用能够围绕目标进行任务规划，并通过 Tool Calling 调用查询接口、数据库、文件系统、代码执行环境等外部能力，从而完成更加复杂的任务。

到这里，可以看到 AI 应用的能力实际上经历了一个逐步向外扩展的过程：

RAG 让 AI 应用能够利用模型之外的知识，而 Agent 则在此基础上进一步增加了任务规划以及访问外部系统、执行操作的能力。

但当外部能力越来越丰富时，新的问题又出现了：如果每一个 AI 应用都需要为每一种工具单独开发连接方式，那么工具生态很快就会变得复杂——一个工具可能需要适配多个 AI 应用，而一个 AI 应用也需要维护大量不同工具的接口。

于是，问题进一步演变为：AI 应用如何以统一的方式理解和调用各种外部能力？

3 MCP：AI 应用连接外部能力的新方式

3.1 从点对点连接到统一协议

MCP（Model Context Protocol，模型上下文协议）正是在这样的背景下提出的一种开放协议。简单来说，MCP 的作用不是增强 AI 应用本身的推理能力，也不是让模型获得更多知识，而是在 AI 应用与外部能力之间建立一层标准化的连接方式——它更像是一套共同遵循的约定：规定 AI 应用如何发现、理解和调用外部能力，以及这些能力如何以统一的方式向 AI 应用提供信息和服务。

在这样的连接关系中，MCP 对连接的双方也有明确的角色定义：AI 应用通常作为 MCP Client，而外部能力则通过 MCP Server 对外提供。

过去：

  AI 应用
    |
 自定义适配
    |
  外部能力

而 MCP 希望变成：

  AI 应用（MCP Client）
        |
     MCP 协议
        |
    MCP Server
        |
    外部能力

这样一来，MCP 实际上把 AI 应用与具体外部能力之间的连接关系从“点对点适配”，转变成了基于统一协议的标准化连接——对于 AI 应用来说，它提供了一种统一的连接机制；对于外部能力提供方来说，则提供了一种标准化的能力开放方式。

3.2 MCP 如何连接 AI 应用与外部能力？

如果只是建立 AI 应用与外部系统之间的连接，传统 API 本身已经能够完成这样的工作。那么，为什么还需要专门为 AI 应用设计 MCP？

而 AI 应用面对的场景更加动态——一个 Agent 在执行任务时，并不一定事先知道自己将会遇到哪些外部能力，也不一定与这些能力的提供方存在预先建立的对应关系。当它面对一个此前并不了解的外部能力提供方时，首先需要解决的并不是“怎么调用”，而是 “你是谁、你能做什么、我应该怎么使用你”。

这意味着，对于 AI 应用而言，仅仅提供一个 API 调用入口还不够，还需要一种能够让 AI 应用理解外部能力的标准化描述方式。

MCP 的设计正是针对这一点：它不仅规定了 AI 应用与外部能力之间如何建立标准化的连接，还进一步规定了外部能力应该如何向 AI 应用进行描述和暴露。这样，AI 应用就可以通过统一的协议发现和理解这些外部能力，而不需要针对不同的外部系统分别设计一套理解和调用机制。

在 MCP 中，外部能力主要通过 Tool、Resource 和 Prompt 三种方式进行描述。

1、Tool（工具）

Tool 用于告诉 AI 应用可以执行哪些操作，例如：查询数据库、创建文件、调用外部服务、执行某个操作。它解决的是：AI 应用可以做什么。

2、Resource（资源）

Resource 用于告诉 AI 应用可以获取哪些外部信息，例如：文件内容、数据记录、文档资料、系统状态。它解决的是：AI 应用可以获取什么信息。

3、Prompt（提示模板）

Prompt 用于向 AI 应用提供可复用的交互模板，例如：固定的分析流程、特定任务的处理方式、标准化操作步骤。它解决的是：AI 应用可以如何使用这些能力。

4 MCP 的实际应用：从 Chatbox 看 AI 应用如何扩展能力

4.1 Chatbox 内置 MCP服务器介绍

文章前面介绍了 MCP 的概念和架构，但对于实际使用 AI 应用的用户来说，一个更直接的问题是：MCP 在实际应用中到底是什么样子的？

目前，一些 AI 客户端已经开始提供 MCP 支持。例如，Chatbox(相关介绍可参考文章：最便捷的 AI App 前端：Chatbox 全面介绍 + 使用指南) 就针对订阅其 Chatbox AI 服务的用户提供了一些内置 MCP Server，让用户无需自行部署 MCP 服务，就可以直接为 AI 应用增加新的外部能力。

下面就以 Chatbox 的内置 MCP Server 为例，简单介绍 MCP 在实际 AI 应用中的表现形式。

Fetch：让 AI 应用直接获取指定网页内容

Fetch MCP Server 提供了网页内容获取能力。AI 应用可以通过它访问网页，并将 HTML 内容转换为更适合 LLM 处理的 Markdown 格式。

例如，用户希望 AI 总结一篇网页文章。传统方式下，用户通常需要先打开网页，将正文复制下来，再粘贴到聊天窗口中，让 AI 进行分析。

而启用 Fetch MCP Server 后，用户只需要将网页地址发送给 AI 应用，例如：请帮我总结这个网页：https://example.com/article。此时，AI 应用会识别当前任务需要获取网页内容，并调用 Fetch MCP Server 提供的网页读取能力。Fetch 获取网页内容后，将结果返回给 AI 应用，再交由LLM 进行理解和总结：

┌─────────────────┐
│ AI 应用          │
├─────────────────┤
│ LLM + Agent     │
└─────────────────┘
          |
          |
       MCP
          |
          |
┌─────────────────┐
│ Fetch Server    │
└─────────────────┘
          |
          |
       网页内容

在这个过程中，Fetch 并不是让 LLM 本身能够直接访问网页，而是通过 MCP 向 AI 应用提供了一种网页内容获取能力。

Context7：让 AI 应用访问最新技术文档

Context7 是一个面向开发场景的 MCP Server，它提供了一种让 AI 应用获取最新技术文档和代码示例的能力。

对于开发者来说，一个常见问题是：LLM 虽然掌握了大量编程知识，但这些知识存在时间边界。例如：某个框架在 LLM 训练之后发布了新版本；某个库修改了 API；某个工具增加了新的配置方式。这时候，如果完全依赖 LLM 自身已有知识，AI 可能会给出过时甚至错误的答案。

传统解决方式通常有两种。一种是用户主动提供资料，例如：自己找到官方文档，然后复制相关内容，再粘贴给 LLM，然后让 LLM 根据文档回答；另一种方式是搭建专门的知识库，通过 RAG 将文档提前处理并提供给 LLM 查询。

而 Context7 提供的是另一种思路：用户只需要提出开发相关问题，AI 应用就可以通过 MCP 调用 Context7。Context7 负责从对应技术库中获取最新文档和示例代码，并将结果返回给 AI 应用，最终由 LLM 结合这些信息生成回答。

这里 MCP 扮演的角色并不是替代 RAG，而是提供了一种标准化访问外部知识来源的方式。

arXiv：让 AI 应用连接专业论文资源

arXiv MCP Server 提供了一种让 AI 应用访问学术论文资源的能力。arXiv 是一个包含大量科研论文的开放平台，覆盖计算机科学、物理学、数学等多个研究领域。

对于 LLM 来说，虽然训练过程中已经学习了大量公开信息，但它并不一定掌握最新发表的研究成果，也无法实时获取某篇具体论文的内容。例如，一个用户希望了解某个 AI 领域的最新研究：“最近关于大语言模型 Agent 的研究有哪些进展？”

传统方式下，用户可能需要：自己搜索相关论文，然后下载论文，阅读摘要或者正文，再让大语言模型帮助总结。而通过 arXiv MCP Server，AI 应用可以直接连接论文资源，根据用户需求查询相关论文，并将论文信息提供给 LLM 进行分析。

它展示了 MCP 的另一种应用方式：除了网页和技术文档之外，AI 应用还可以通过统一协议连接特定领域的数据源和知识服务。

Sequential Thinking：为 AI 应用提供结构化问题分析能力

前面介绍的 Fetch、Context7 和 arXiv，都属于比较典型的信息获取类 MCP Server：它们帮助 AI 应用连接外部数据源，让模型能够获得更多上下文信息。

而 Sequential Thinking 展示的是另一种类型的能力：它并不负责提供外部数据，而是为 AI 应用提供一种辅助复杂问题分析的工具。

在处理简单问题时，AI 应用通常可以直接根据用户需求生成回答。但面对复杂任务时，仅仅一次性生成答案往往不够，例如：分析一个复杂技术问题、制定一个项目方案、排查系统故障原因、对多个因素进行综合判断等，这类任务通常需要拆解问题、逐步分析，并根据中间结果不断调整方向。

Sequential Thinking MCP Server 提供的就是这样一种结构化处理能力。AI 应用可以通过 MCP 调用它，将复杂任务拆分成多个步骤，并在分析过程中逐步整理思路。

这里需要注意，Sequential Thinking 并不是替代 LLM 的推理能力，而是为 AI 应用提供了一种更结构化的任务处理方式。

从 MCP 的角度看，它说明了外部能力并不一定都是“数据来源”或者“执行工具”，也可以是帮助 AI 应用完成任务的辅助能力。

EdgeOne Pages：让 AI 应用具备部署和执行能力

前面介绍的几个 MCP Server，主要解决的是 AI 应用如何获取信息或者辅助分析问题。而 EdgeOne Pages 展示了另一类能力：通过 MCP 让 AI 应用调用外部服务完成实际操作。

EdgeOne Pages MCP Server 提供了将 HTML 内容部署到 EdgeOne Pages，并生成公开访问地址的能力。例如，用户可以让 AI 应用完成类似这样的任务：“帮我创建一个简单的网页，并部署上线。”

如果没有外部工具支持，AI 应用最多只能生成 HTML 代码，并将代码返回给用户。后续的文件保存、部署、发布，仍然需要用户手动完成。

而通过 EdgeOne Pages MCP Server，流程可以变成：

用户需求
    |
    ↓
AI 应用
    |
    ↓
   MCP
    |
    ↓
EdgeOne Pages Server
    |
    ↓
网页部署
    |
    ↓
返回访问地址

在这个过程中，AI 应用负责理解用户需求、生成内容并决定调用什么能力；EdgeOne Pages MCP Server 则负责执行具体的部署操作。

这里 MCP 扮演的角色，并不是替代部署平台，而是提供了一种让 AI 应用能够调用外部服务的标准化连接方式。

从这个例子可以看到，MCP 所连接的外部能力并不局限于“查询数据”。它同样可以连接具有实际执行能力的服务，让 AI 应用从获取信息进一步走向完成任务。

4.2 自定义 MCP：让 AI 连接更多外部服务

上一节介绍的 5 个 Chatbox 内置 MCP Server，是 Chatbox AI 订阅服务提供的一键集成能力。对于没有订阅该服务的用户来说，虽然无法直接使用这些内置 MCP Server，但 Chatbox 仍然支持手动添加自定义 MCP Server，让用户根据自己的需求扩展 AI 应用能够连接的外部能力。

例如，用户可以添加第三方提供的 MCP Server，也可以连接自己部署的 MCP Server，只需要在”自定义 MCP 服务器”中自行添加即可：

从来源来看，Chatbox 中可以添加的 MCP Server 主要可以分为两类：官方提供的 MCP Server 和社区开发的 MCP Server。

官方提供的MCP Server常用的有Brave Search(让 AI 应用具备搜索能力，对应 Fetch，但区别是主动搜索，而不是读取指定网页)、GitHub(让 AI 应用直接连接代码仓库)、Google Driver(让 AI 应用能够直接连接谷歌网盘)等等：

社区提供MCP服务器如下，我就不一一介绍了：

当然，如果有自建的MCP服务器，也可以直接手动添加：

有远程和本地两种类型可选：

大家按照自己的需求选择适合的方案即可。

4.3 一个实际例子：通过 GitHub MCP Server 分析代码仓库

前面的文章介绍了 MCP Server 可以提供哪些能力，但这些能力真正接入 AI 应用后，会产生什么变化？下面通过一个 GitHub MCP Server 的例子来说明。

先添加一个GitHub的MCP Server，我使用的本地(stdio)模式添加：

成功后可以就看到MCP Server支持的工具：

然后点击保存即可：

接着，在Chatbox里创建一个新的对话，这时对话框下方的MCP功能会自动选择刚刚创建的GitHub MCP server：

配置完成后，就可以进入实际应用场景的测试了。

为了验证 GitHub MCP Server 是否能够帮助 AI 应用访问外部代码仓库，我让 Qwen 尝试分析我公开在 GitHub 上的 WordPress 多活架构方案。分析过程中，Chatbox 通过 MCP Server 多次调用 GitHub 提供的工具，例如获取仓库信息、读取文件内容、搜索代码等，最终让 Qwen 基于这些外部信息完成仓库分析：

然后给出了分析结果(部分截图)：

测试成功，可以看到Qwen的确通过 GitHub MCP Server 获得了访问 GitHub 仓库的能力。

另，我的方案地址如下：https://github.com/tangwudi1979/multiwp-tunnel，感兴趣的朋友也可以直接访问，评估一下Qwen的分析是否准确。

5 MCP 的意义：从能力调用到 AI 生态连接

回顾前面的内容可以发现，AI 应用的发展并不只是模型能力越来越强，也是在不断扩大 AI 与外部信息、工具和服务之间的连接范围：RAG 让 AI 应用能够访问模型之外的知识，Agent 让 AI 应用能够围绕目标调用外部工具，而 MCP 进一步解决了不同外部能力如何被统一连接的问题。

因此，RAG、Agent 和 MCP 并不是相互替代的技术，而是在 AI 应用架构中承担不同层面的职责：

RAG

解决：
AI 应用如何获取外部信息
----------------------------------
Agent

解决：
AI 应用如何规划任务并调用外部能力
----------------------------------
MCP

解决：
AI 应用如何统一连接外部能力

其中，MCP 的价值在于降低接入外部能力的开发和维护成本：AI 应用只需要支持 MCP，就可以通过统一的方式接入不同开发者、不同平台提供的 MCP Server，而能力提供方也不需要针对每个 AI 应用分别开发适配方案。

例如，一个个人 AI 助手未来可以连接个人知识库、文件系统、邮件、日历、企业内部数据、开发工具和网络服务等各种能力。随着 MCP 生态不断扩大，AI 应用能够接入的能力也不再局限于几个固定功能，AI 应用本身也可能逐渐成为一个连接各种外部能力的智能入口。

当越来越多的数据、工具和服务能够被 AI 应用统一连接时，AI 的角色也可能从单纯的“回答问题”，进一步延伸到更广泛的软件生态中，参与信息处理、决策辅助和任务执行。

当然，MCP 并不会自动解决 AI 应用发展的所有问题。模型能力、任务规划、数据质量、安全权限以及具体业务流程设计，仍然决定着 AI 应用最终能够达到的效果。

虽然 MCP 为 AI 应用连接外部能力提供了一种更加通用、标准化的方式，但这并不意味着它会取代 AI 应用原有的工具调用机制。实际上，同一个 AI 应用完全可以同时采用不同的方式连接外部能力。

以 ChatGPT 为例，在“设置”-“插件”中可以看到一些内置提供、可以直接启用的功能：

这些内置功能背后采用的实现方式并不完全相同，既有 ChatGPT 自身基于 Function Calling 提供的能力，也有通过 MCP 等方式接入的外部能力。与此同时，ChatGPT 还支持用户直接连接自定义的 MCP Server：

相比之下，对于 Cursor、各种 AI Agent 以及其他第三方 AI 应用而言，MCP 的价值更加直接：它们不需要针对每一种外部服务分别开发专用适配，而可以通过统一协议接入 MCP Server。

因此，对于第三方 AI 应用，MCP 更像是连接外部能力生态的一种通用基础设施，可以降低重复开发和维护的成本。而对于官方客户端，则更多是现有工具体系之外的一种开放扩展方式。

📌 内容结构提示：

这篇内容属于「AI 学习地图」的一部分，你可以从这里查看完整内容路径： AI 学习地图。

分享这篇文章