6.3 MCP 介绍#

在前面两节内容中，我们已经围绕 Skill 进行了系统介绍。可以看到，Skill 解决的是把一类任务所需的方法与资源沉淀为可复用能力的问题。但是，无论 Skill 本身设计得多么完善，它最终仍然需要依赖具体的工具来完成实际动作，例如访问数据库、读写文件、查询第三方接口等。这就引出一个新的工程问题：在 Agent 需要调用大量外部工具时，这些工具应该如何被组织、被发现、被复用的？

为了回答这一问题，本节将介绍一种被称作 MCP（Model Context Protocol）的开放协议。围绕“为什么需要 MCP、MCP 是什么、MCP 能够帮我们做什么”这 3 个核心问题展开。

6.3.1 MCP 出现的背景与动机#

在「第 4.2 节中介绍 Function Calling」 时我们已经看到，让大模型调用外部工具的标准做法，是把工具的 schema 注册到模型的工具列表中，并在模型发出调用请求后由程序实际执行工具。这种方式在小规模、单一团队的 Agent 项目中已经能够稳定工作，但是，当 Agent 应用逐渐走向复杂以后，这种模式会暴露出一系列新的局限。

首先，工具能力难以跨应用复用。同一个工具（例如数据库查询、文件检索、日志分析）往往会被多个 Agent 应用同时需要。如果每个应用都重新写一遍工具定义、连接逻辑和错误处理，那么这些工具就无法在组织内部被沉淀下来。

其次，工具实现与 Agent 逻辑深度耦合。当工具需要访问某个内部系统时，开发者通常会直接在 Agent 工程中编写调用代码。这虽然能够快速验证效果，但也使得工具实现与具体的 Agent 框架绑定在一起，例如迁移到另一个 Agent 框架时往往需要重写整套适配层。

最后，外部服务接入缺乏统一规范。随着 Agent 应用接入的服务越来越多，每接入一个新的服务都需要重新约定接口格式、鉴权方式和错误处理。这一过程中，开发者更关注业务逻辑，但不得不在工程层面重复处理大量与业务无关的样板代码。

可以看到，这些问题的根源并不在某一个具体的工具或某一个 Agent 框架，而在于整个生态缺少一套统一的工具供给协议。MCP 的出现正是为了从协议层面给出解决方案，让 Agent 与外部工具之间能够按照统一的方式进行发现、调用与扩展。

6.3.2 MCP 的基本定义#

模型上下文协议（Model Context Protocol，MCP）是一套面向大模型应用与外部工具之间交互的开源协议标准，它由 Anthropic 于 2024 年 11 月正式开源，其目标是为 Agent 应用与外部能力之间定义一套标准化的通信接口，从而让任意一个符合 MCP 规范的 Agent 应用都能够无缝使用任意一个符合 MCP 规范的外部工具服务。

有了 MCP，像类似 Claude 或 ChatGPT 这样的 AI 应用程序就可以直接连接到数据源（例如本地文件、数据库）、工具（例如搜索引擎、计算器）和工作流程，从而访问关键信息并执行任务。因此，我们可以将 MCP 想象成 AI 应用程序的 USB-C 接口——正如 USB-C 提供了一种连接电子设备的标准化方式一样——它提供了一种将 AI 应用程序连接到外部系统的标准化方式。

如图6-4所示便是基于 MCP 的 AI 应用访问外部能力的工作流程。从结构上看，MCP 协议定义了 3 个核心角色：MCP Host、MCP Client 与 MCP Server。

• MCP Host 是直接面向用户的 Agent 应用，例如 LangChain、Claude Desktop、Cursor 等，它负责承载对话、管理模型与上下文，并向用户提供交互界面。

• MCP Client 是 Host 内部用于与外部 MCP Server 通信的组件。一个 Host 中可以存在多个 Client，每个 Client 对应一条与某个 MCP Server 的连接。Client 负责协议握手、能力发现、请求转发与响应解析。

• MCP Server 是真正提供工具能力的进程，它既可以运行在与 Host 相同的本地环境中，也可以部署在远程服务器上。Server 负责把具体的工具、资源或提示词模板封装为 MCP 协议所规定的标准格式，并对外提供调用接口。

总结起来就是，Host 启动 Client，Client 连接到 Server，双方完成能力协商，Client 把 Server 提供的能力转换为 LangChain 等框架能够识别的工具，最终由大模型在「ReAct 循环」中按需调用。

6.3.3 MCP 提供的核心能力#

在明确了 MCP 的基本定义之后，更值得关注的是 MCP 在协议层面定义了哪些类型的能力。从公开规范看，MCP Server 可以向 Host 暴露 3 类核心能力：工具（Tools）、资源（Resources）与提示词模板（Prompts），如图6-4所示，并且这3类能力分别对应 Agent 在不同阶段可能需要的不同支持。

• 工具（Tools）：工具是 MCP 中最常见的能力形态，也是最贴近第 4.2 节中 Function Calling 的部分。每个 Tool 对应一个具体的可执行动作，例如执行一次数据库查询、发起一次 HTTP 请求、读取一个本地文件等。Tool 的描述与参数 schema 会被 Server 主动注册到 Client 一侧，并最终通过 LangChain 等框架注入到大模型的工具列表中，模型可以像调用本地工具一样调用这些由 MCP Server 提供的远程工具。

• 资源（Resources）：资源强调的是可被读取的结构化或非结构化数据，例如日志片段、配置文件、文档片段、本地代码片段等。资源与工具的差别在于，资源通常是被动读取的数据，而工具则是带有副作用的可执行动作。Host 既可以主动读取资源，也可以在 ReAct 循环中由模型按需读取。

• 提示词模板（Prompts）：MCP 还允许 Server 提供一组预定义的提示词模板，这些模板对应一些常见的交互模式，例如“生成代码评审意见”、“基于当前文件给出修改建议”等。Host 在需要时可以按名称加载这些模板，并将其拼接到对话上下文中，从而为模型提供更稳定的指导。

综上，我们可以把这 3 类能力的定位理解为工具解决能做什么动作，资源解决能读取什么信息，提示词模板解决可以怎样组织对话，三者共同构成了 MCP Server 向 Agent 应用提供的完整能力集合。

6.3.4 小结#

本节围绕 MCP 协议的基本概念进行了系统介绍。我们首先从工具复用、跨框架接入与外部服务扩展 3 个角度说明了 MCP 出现的动机，在此基础上进一步介绍了 MCP 在协议层面所提供的 3 类核心能力，分别是工具、资源与提示词模板。

至此，关于 MCP 的概念性介绍就告一段落。可以看到，MCP 的真正价值并不在于它引入了某一个全新的能力，而在于它把 Agent 应用接入外部工具的方式标准化、协议化。在后续内容中，我们将进一步介绍如何在 LangChain 中实际接入 MCP 服务，并说明如何开发一个可被复用的 MCP Server。

引用#

[1] Anthropic. Model Context Protocol. https://modelcontextprotocol.io/

[2] Anthropic. MCP Specification. https://modelcontextprotocol.io/specification/2025-06-18

[3] LangChain. MCP (Model Context Protocol). https://docs.langchain.com/oss/python/langchain/mcp