模型上下文协议（MCP）

构建 AI 智能体，尤其是采用检索增强生成（RAG）的智能体时，一个主要挑战是如何持续向语言模型提供丰富、一致的上下文，同时减少为每个数据来源或工具单独编写集成代码的工作。传统方法通常将检索文档、工具输出和记忆加入提示文本。每个新数据连接器或工具往往需要单独实现，容易形成分散且难以维护的方案。

模型上下文协议（Model Context Protocol，MCP）旨在处理这些问题。它为 AI 模型连接外部数据和能力提供统一标准，常被比喻为“AI 应用的 USB-C 接口”：遵循协议的智能体可以通过同一种接口访问遵循协议的数据来源或工具。共同协议将集成关系从 N×M 简化为 N+M：每个模型和每个工具分别实现一次 MCP，即可建立连接。AI 系统因此更容易接入新的知识库、业务应用或服务，减少逐项编写连接代码的需要。

在 Agentic RAG 中，MCP 连接语言模型与其通常缺少的最新信息及领域知识。它支持模型与外部来源之间的实时双向通信，使助手能够获取当前事实、搜索内部知识库，或在执行期间查询 API。

MCP 也支持构建更完善、更自主的智能体。单轮问答机器人能力有限，智能体系统则需要多步骤推理、工具调用、历史交互记忆和复杂任务执行。通过在多次交互及工具使用中传递结构化上下文，系统可以保持规划和操作的连续性。协议面向智能体系统，帮助 AI 承担机械性工作，让人类集中处理创造性任务。它为 AI 应用提供统一的上下文连接基础，使应用能够以一致方式向模型提供记忆、工具和目标等信息。

MCP 架构

MCP 采用客户端与服务端架构，将智能体的推理逻辑与外部数据、工具来源分开。典型部署包含三类角色。

Host 进程，也就是智能体运行环境：Host 是主要 AI 应用，例如 IDE 插件，或 Amazon 购物助手的聊天界面。用户在此交互，语言模型也由此调用。Host 负责组织整体工作流程，并通过 MCP 管理与外部资源的连接。
MCP Client：Host 为连接的外部来源或工具服务创建轻量客户端。每个 Client 与一个 MCP Server 保持专用的一对一连接，使用 MCP 通信，并帮助隔离不同服务的交互。Host 可以同时运行多个 Client，每个连接一个 Server，从多个来源获得上下文。
MCP Server：Server 是实现 MCP 规范的本地或远程程序，提供特定数据或能力。它通常连接一个数据来源、知识库或外部服务，例如公司 Google Drive 或向量数据库，并通过统一协议向 Host 提供内容或功能。主要形式包括 resources，即可读取的数据；tools，即可执行函数或操作；以及 prompts，即预定义提示模板。Server 专注自身领域，为 Host 使用的模型提供上下文和操作。语言模型运行及完整对话管理通常由 Host 负责。

MCP主机、客户端与服务器 — MCP主机中的客户端分别连接MCP服务器，服务器再访问本地数据源或互联网服务。

这些组件可以将智能体连接到以下来源。

本地数据来源：MCP Server 能够安全访问的计算机文件、数据库和服务。
远程数据来源：通过互联网提供的外部系统，例如可由 MCP Server 访问的 API。

这种架构明确划分职责。Host 和智能体负责高层推理及决策，Server 负责领域数据或操作，Client 确保通信遵循协议，并隔离不同连接。Server 应只接收完成自身功能所必需的信息，无需读取完整对话或智能体拥有的其他上下文。Host 管理信息流并执行安全与隐私规则。例如，通过 MCP Server 查询内部数据库时，Host 可以先要求用户同意，再发送查询，同时不向该 Server 提供无关对话或其他数据来源的内容。这样的隔离有助于安全管理，并减少系统之间不必要的依赖。

Client 与 Server 通过有状态的 JSON-RPC 2.0 消息通信，底层使用适当传输方式。本地服务可以使用 stdio 管道，远程服务可以使用安全 HTTP(S)，相关传输方式也可以使用 Server-Sent Events（SSE）。每次交互都是结构化消息：Request 请求执行操作，例如读取文件或调用工具；Response 或 Result 返回结果；Notification 发送更新或事件等单向消息。结构化消息便于管理多步骤通信。连接初始化时还可以协商能力：Server 声明支持的 resources、tools 等功能，Client 则声明是否支持由服务端发起的请求，例如让 Server 请求模型生成内容的 sampling。

从系统工程角度看，这种分离便于独立开发与维护轻量服务。一个团队可以实现 Confluence Server，另一个实现 JIRA Server，还有团队负责库存 Server。只要遵循 MCP，各服务就能独立演进或扩展。Host 保持通用，只需连接 MCP Client，无需为每个集成写入专门逻辑。开发者可以启动新的 Server 或复用开源 Server，通过标准接口接入新来源。Host 还可以按需汇集多个 Server 的结果，以结构化方式加入模型上下文。有状态连接支持资源更新订阅，例如文件变化通知，也有助于在任务期间持续跟踪资源。各组件可以独立开发、扩展和实施安全措施，形成更模块化的系统。

通过 MCP 组织模型上下文

MCP 提供标准结构来表达和交换模型需要的上下文材料。应用可以利用这些结构管理长期记忆、当前目标、可用工具、中间观察结果和系统指令，使上下文能够被机器读取，并便于不同智能体框架共享和复用。以下概念分别对应智能体中的不同组成部分。

Resources：Server 向 Client 提供的只读上下文数据，可以是文件、数据库记录、文档或其他有助于推理的信息。资源通过 URI 标识，可以使用 resources/list 和 resources/read 列出及读取。资源是智能体按需获取的知识或数据；具有结构和地址后，应用可以系统地检索、索引和读取，再按需加入对话。读取资源用于观察信息，不应因此改变外部环境。
Tools 与工具说明：Server 可以公布多个工具，并为每个工具提供元数据，例如功能说明、参数 schema，以及适用的其他信息。统一工具描述后，智能体可以一致地理解工具，并结合可获得的成本、速率限制或延迟信息决定何时使用。传统应用可能在提示中写入工具规则，或依赖特定厂商的 function calling；MCP 通过 tools/call 等 JSON-RPC 请求调用工具，使协议层不依赖某一家 LLM API。工具可以是计算器，也可以执行数据库查询或调用外部 API。连接提供工具的 Server 后，应用即可通过统一接口使用；使用说明可以放在结构化工具描述和相关提示材料中。
系统消息与 Prompts：Server 可以提供可复用的消息模板或工作流程提示，帮助模型或用户完成特定领域的任务。应用可以将角色、语气和高层行为等系统指令作为上下文材料管理，按需获取适当模板。这样能够保持使用方式一致，并将提示作为数据在服务端管理和版本控制，减少将全部提示写入智能体代码的需要。
上下文对象：在应用设计中，可以使用结构化对象保存当前任务的状态和知识，包括先前交互或知识库提供的记忆、当前目标、可用工具说明，以及以前操作的结果或环境反馈。这相当于把原本很长的提示材料分为明确字段。通常采用 JSON 等结构后，可以保存、版本化或在系统间传递。例如，分别保存相关文档、中间结论和工具用法，使上下文同时具备完整性和机器可解析性。
任务与目标的表达：智能体当前任务是重要上下文。应用可以将任务状态放入自己的上下文对象，或通过协议支持的消息和资源交换相关信息。例如，Host 可以向 Server 提供完成请求所需的目标说明，Server 也可以按任务类型提供相应提示或资源。
Observations：观察结果是智能体执行操作后获得的反馈，例如网页搜索结果或环境变化。MCP 返回的资源或消息可以由应用记录到状态中，供后续推理引用。结构化记录让工具调用和结果形成清楚的执行轨迹，便于调试和后续训练。观察结果因此可以持续保存，并在组件之间分析和共享。
调用元数据：应用还可以管理模型或工具调用的相关信息，例如目标 API 或模型、预期延迟和成本、时间或计算预算，以及输出格式要求。工具相关资料也可以说明调用是否昂贵或需要限制频率。Host 可以据此选择较低成本的模型，或在交互时限不足时避开耗时工具。模型描述还可以区分纯文本 LLM 和需要图像输入的视觉模型，帮助选择适当模型及模态。上下文对象描述任务内容，调用元数据和路由信息描述执行方式及位置；将这些资料一致管理，有助于构建涉及多个模型或替代路径的复杂应用。

控制职责的划分

MCP能力的控制主体 — MCP的提示、资源和工具分别对应用户、应用和模型主导的控制方式。

Prompts 由用户控制：Server 开发者可以提供适合处理其数据的提示，应用将这些提示呈现给用户，并用于与 LLM 交互。
Resources 由应用控制：资源可以是文本或二进制数据。应用开发者通常负责规定如何使用这些信息；具体选择通常由应用逻辑管理，LLM 无需参与。
Tools 由模型控制：需要赋予应用与环境交互的自主能力时，可以使用工具。Server 提供工具列表、说明和参数要求，应用将其传给 LLM，由模型判断任务需要哪些工具以及如何调用。

将事实材料、工具及相关任务信息以声明式结构表达，可以使 AI 应用之间的上下文更加一致，并便于共享。MCP 不依赖具体模型，相关内容可以用于不同 LLM 或多模态模型。它可以作为分层 AI 架构中的上下文连接层：类似网络层统一通信方式，MCP 统一上下文的封装和交换，使上层智能体逻辑与下层模型执行保持相对独立。

通过 MCP 集成 RAG、记忆与工具

MCP 可以通过一致接口连接检索增强生成、长期记忆和工具使用。传统实现可能分别使用文档检索流程、保存记忆的向量数据库、工具 API 封装，以及组织推理的自定义代码。通过 MCP，这些能力可以采用同一种接入机制，简化集成工作。

例如，一个助手需要查询内部库存回答客户问题，更新购物车，并长期记住对话或用户需求。可以建立三个 Server：Inventory MCP Server 提供库存知识；Shopping Cart MCP Server 提供 addItem 工具；Memory MCP Server 保存和读取对话记忆或用户资料。Host 同时连接三者。用户提问时，应用从 Inventory Server 获取相关文本或商品 ID，通常通过检索工具完成；同时从 Memory Server 获取相关用户信息。结果以结构化内容返回，Host 再有控制地将文档文本等材料加入模型上下文。如果用户要求“请将第三款耳机加入购物车”，应用通过 tools/call 调用购物车工具，传入所需参数。操作结果，例如更新 ID 或确认信息，再用于形成回复。智能体通过统一 MCP 接口访问各外部系统，无需了解购物车底层 API 或记忆存储细节。新增能力时沿用相同模式，可以减少开发者的集成负担。

通过 MCP 使用工具时，执行过程包括以下步骤。

通过MCP完成工具调用 — Agent通过MCP客户端获取并调用服务器能力，把工具结果交给模型生成回答。

将用户查询传给智能体应用，通常是 Python 应用。
应用实现 MCP Client，并通过 Client 获取 Server 提供的工具列表。
将工具列表与用户查询一起传给 LLM，由模型选择需要调用的工具和参数。
应用再次通过 Client 连接 Server，发送执行请求，并接收工具结果。
将用户查询和工具返回的数据一起传给 LLM。
生成回答，并通过智能体应用返回用户。

MCP 还支持更具交互性的检索和工具使用。传统 RAG 可能在回答前只检索一次，有状态会话和通知机制则可以支持多轮交互。例如，Server 可以发送更新，具备相应能力时也可以请求澄清；智能体可以订阅资源，在任务期间资源变化时收到通知。这有助于智能体持续参与环境中的交互。

在功能完整的 Agentic RAG 中加入 MCP 后，可以采用以下流程。

通过MCP接入Agentic RAG — 查询分析、检索、重排序、回答生成和检查组成循环，Agent通过多个MCP服务器获取外部数据。

分析用户查询：将原始查询交给基于 LLM 的智能体，必要时一次或多次改写，形成一个或多个后续查询，并判断是否需要补充数据。
需要补充数据时触发检索，来源可以包括实时用户数据、内部文档和网页信息。

MCP 在数据访问部分发挥以下作用。

各数据领域可以管理自己的 Server，并提供使用数据的具体规则。
各领域可以在 Server 层实施安全和合规控制。
新增数据领域可以通过标准方式加入 Server 集合，使数据服务与智能体独立演进。
平台开发者可以通过标准接口向外部使用者提供数据，便于访问网络数据。
AI 工程人员可以继续专注于智能体流程结构。

汇集检索数据，使用比普通 embedding 模型能力更强的模型进行重排，缩小候选范围。
不需要补充数据时，直接通过 LLM 生成一个或多个回答，或者一组操作。
分析、归纳并评估回答的正确性和相关性。达到要求时返回用户；仍需改进时，改写查询并重复生成循环。

MCP 也有助于集成记忆。Memory Server 可以连接向量数据库或其他存储，对智能体而言则是另一个信息提供者，类似与 Mem0 交互。长期记忆可以由 Server 保存，按需返回相关片段。记忆因此能够跨会话保留，并按需读取，避免全部受限于单次模型上下文窗口。多个智能体还可以使用同一记忆来源：Agent A 完成部分任务后，Agent B 从相同存储读取已完成内容并继续。MCP 提供共享记忆的统一接口，支持这种连续协作。智能体内部仍负责规划和决定何时使用工具；MCP 为其提供可访问的数据和操作。推理步骤使用已有上下文决定操作，操作通过 MCP 请求执行，观察结果以结构化响应返回，并加入下一次推理。统一结果格式也便于通过提示或微调训练模型识别错误及结果 schema，再据此调整计划。这种一致性有助于上下文工程和可靠性。记录请求与结果后，开发者可以查看执行轨迹，分析提示和失败位置。

对于开发者，MCP 使同一种接口范式可以用于多种集成。Python、TypeScript 等 SDK 可以处理大量请求与响应细节，简化 Server 和 Client 实现。例如，本课程的搜索功能可以通过一个小型 MCP Server 接入网页服务，使用 SDK 定义资源或工具；遵循协议后，当前智能体和其他兼容智能体都可以使用。某些集成可以通过配置已有 Inventory Server 完成。生态中也有网页搜索、Obsidian、Notion、云 API 和代码仓库等服务，开发者可以组合项目需要的能力。除方法名称和参数不同外，调用数据库和发起网页数据获取都可以采用相同接口方式。

通过 MCP 管理连接后，开发者能够集中处理智能体逻辑和策略。检索上下文、执行操作和访问状态均可通过标准接口组织。增加图像模型等新模态，或者新的知识来源时，可以新增对应端点和服务，减少对核心智能体的重构。开发者因而能够更多关注高层行为，以及模型是否有效使用所提供的上下文。

实际应用与示例

MCP 由 Anthropic 于 2024 年末开源，随后在多类实际项目中得到采用。相关应用包括以下领域。

开发工具：Sourcegraph 的 Cody 编程助手通过 MCP 访问大型代码库和文档，按需获取代码上下文，改善建议。协作代码编辑器 Zed 也集成 MCP，使 AI 功能能够连接开发工具和代码仓库。这类助手可以通过 Server 获取文件内容或 pull request 差异，再用于生成代码或审核意见。
企业知识助手：Anthropic 曾介绍 Block（原 Square）和 Apollo 等早期采用者，通过 MCP 将助手连接到内部系统。企业可以控制对政策文档、数据库或 Slack 讨论的访问。统一接口支持工具和团队之间的协作，并使信息访问更便于管理。
网页与数据智能体：Apify 提供 MCP Server，将网页数据获取 Actors 暴露给智能体。智能体可以请求获取网站数据，再分析或展示结果，将检索与网页自动化结合。网页搜索 Server 也可以提供实时网络信息。Notion 或 Obsidian 等连接则支持按用户要求读取和更新笔记或知识库。
研究应用：一些实验性多智能体系统使用 MCP 作为统一环境接口。例如，MCPWorld 等基准研究 API 和图形界面任务中的智能体能力。使用表示任务或工具的标准 Server 后，研究者可以替换推理模型，并在相同环境中比较结果，减少连接方式不同造成的影响。

MCP 周围也形成了开源生态，包括 Python、TypeScript、Java 等 SDK，以及 Google Drive、Git、Slack、PostgreSQL 等示例 Server。社区持续贡献更多连接器，并通过 GitHub 或 Smithery 等目录分享。连接日历或 CRM 时，可能已有可复用 Server 或模板。正式规范、公开讨论和社区协作，使 MCP 能够作为持续发展的集成标准。