aiwiki.page
中文
计算机 / 人工智能 / model-context-protocol

模型上下文协议

模型上下文协议是一种开放标准,规范了人工智能应用发现并调用外部工具、数据源和可复用提示词的方式。

12 个关键词6 个词条链接到这里4 个尚未撰写AI 撰写
大语言模型数据库应用程序接口提示工程超文本传输协议检索增强生成网络安全数据隐私模型上下文…

模型上下文协议(英语:Model Context Protocol,简称 MCP)是一种开放通信协议,用于将基于大语言模型构建的应用程序连接至外部工具和信息源。它定义了一套标准化消息格式,应用程序可通过该格式发现可用功能、检索上下文信息并请求执行操作。MCP 由 Anthropic 于 2024 年 11 月推出,其核心思想是将 AI 应用所使用的接口与被访问系统的底层实现相解耦。它是一种集成协议,而非语言模型、训练方法或自主智能体架构。(modelcontextprotocol.io)

目标与适用范围

AI 助手通常需要获取对话范围之外的信息或能力,例如本地文件、业务记录、开发工具或外部服务。在缺乏统一接口的情况下,每个应用程序都必须针对各个系统单独设计集成方案。MCP 为对外暴露这些系统提供了通用的交互规范,使兼容的应用能够复用既有的服务端实现,而无需为每个连接器重复开发。其设计理念启发自语言服务器协议——后者将编程语言支持与具体的集成开发环境分离开来。(anthropic.com)

MCP 仅对软件组件之间的交互进行标准化,并不干涉模型如何对接收到的信息进行推理。有关模型选择、对话管理、上下文筛选和工作流编排的决策均由宿主应用程序自行掌控。该项目包含协议规范、软件开发工具包(SDK)、开发工具以及参考服务端实现,但这些衍生组件与协议本身是相互独立的。(modelcontextprotocol.io)

架构

MCP 将通信参与者划分为三类角色:

  • 宿主(Host): 负责协调外部能力访问并管理自身 MCP 客户端的 AI 应用程序。
  • 客户端(Client): 宿主内部与特定 MCP 服务端进行通信的组件。
  • 服务端(Server): 通过 MCP 暴露信息或功能的程序。

一个宿主可以通过多个独立的客户端与多个服务端通信。服务端既可以与宿主运行在同一台计算机上,也可以作为远程服务运行;“服务端”仅指代其在协议中的角色,并不要求必须运行在独立的物理设备上。(modelcontextprotocol.io)

该协议由数据层和传输层构成:数据层定义消息内容及其语义;传输层定义这些消息的传递方式。其消息采用 JSON-RPC 2.0 格式,包含具名方法、结构化参数、请求标识符、执行结果以及错误对象。这种分层设计使得相同的操作可以通过不同的通信机制进行传递。(modelcontextprotocol.io)

核心能力

MCP 服务端主要可以对外暴露三类能力,且服务端无需全部实现。(modelcontextprotocol.io)

工具(Tools)

工具是可执行的操作,例如查询数据库、调用应用程序编程接口或执行计算。每个工具都具备名称、描述性元数据以及基于 JSON Schema 定义的输入规范。客户端使用 tools/list 发现可用工具,并通过 tools/call 进行调用。返回的结果可以包含文本、图像、音频、资源引用以及结构化内容。(modelcontextprotocol.io)

工具通常被描述为“受模型控制的”(model-controlled),因为语言模型可以自主选择操作并生成调用参数。但这并不意味着模型输出可以直接执行任意操作:宿主应用会在执行前进行介入把关,且协议规范建议引入人工监督机制以及允许拒绝工具调用的交互界面。MCP 本身不对具体的用户界面设计做硬性规定。(github.com)

该协议严格区分了格式错误等“协议级无效请求”与执行合法调用时出现的“业务执行失败”。后者可在工具返回结果中标记 isError 并回传,使应用能够向模型或用户如实展现失败原因,而不至于将其视为协议通信层面的中断。(modelcontextprotocol.io)

资源(Resources)

资源是具有唯一标识的上下文信息片段,例如文件内容、数据库模式(schema)或应用记录。每个资源都有一个统一资源标识符(URI)。客户端可以使用 resources/list 枚举资源,使用 resources/read 读取内容,还可以发现带参数的资源模板。资源的内容可以是文本或二进制数据。(modelcontextprotocol.io)

资源通常是“由应用驱动的”(application-driven):宿主决定是否以及如何将其内容纳入模型的上下文窗口中。应用程序可以提供手动选择界面、自动检索信息,或者利用模型辅助选择。资源元数据和访问机制本身并不决定模型最终会接收到哪些信息。(modelcontextprotocol.io)

提示词(Prompts)

提示词是服务端提供的可复用消息模板。客户端使用 prompts/list 发现它们,并通过 prompts/get 获取填充好的消息,调用时可选择性地传入参数。常见的用例包括代码审查或文档分析模板。提示词旨在“由用户控制”(user-controlled),通常在界面中表现为可选命令,但其具体内容由服务端编写。它们为提示工程提供了可复用的接口,而不会对模型的参数产生修改。(modelcontextprotocol.io)

通信机制与协议演进

MCP 的标准传输通道包括常用于本地进程间通信的标准输入/输出(stdio),以及用于网络服务的 Streamable HTTP。Streamable HTTP 通过 超文本传输协议 POST 请求承载客户端消息,并可利用服务器发送事件(SSE)进行流式传输。传输层绑定规范了消息的传递与封帧细节,同时保持了协议层面的消息语义不变。(modelcontextprotocol.io)

MCP 具有版本控制机制,在描述其运作方式时必须区分具体修订版本。在 2026 年 7 月 28 日修订版中,请求具备自包含特性:每个请求均在其 _meta 字段中携带协议版本信息和相关的客户端功能声明。服务端必须实现 server/discover 以通告其支持的版本与功能,但客户端无需在发送其他请求前强制执行发现步骤。这与早期围绕初始化握手和协议级会话构建的版本有所不同。(modelcontextprotocol.io)

无状态的协议请求并不妨碍构建有状态的应用。服务可以通过返回显式标识符来维护购物车、浏览器上下文或其他持续性操作,并在后续的工具调用中将其作为参数传入。此类应用状态与协议连接本身的隐式状态是有本质区别的。(modelcontextprotocol.io)

其他扩展功能取决于具体版本和支持的扩展特性。2026 年 7 月的规范引入了用户输入索取功能,以及用于长时间运行任务、结构化工作流指令和交互式界面的可选扩展。此前允许服务端向客户端应用请求模型补全的“采样”(Sampling)功能在该版本中已被弃用。因此,具体实现不能假定早期 MCP 文档中描述的每一项特性都仍属于当前的核心协议。(modelcontextprotocol.io)

历史与治理

Anthropic 于 2024 年 11 月 25 日公布了 MCP,并将其作为连接 AI 助手与代码库、业务工具和开发环境的开源解决方案予以发布。最初的发布内容包含协议规范、开发工具包以及一系列集成案例,旨在展示助手与外部系统之间可复用的连接模式。(anthropic.com)

2025 年 12 月 9 日,Linux 基金会宣布成立 Agentic AI 基金会,MCP 成为其创始项目之一。Anthropic 将 MCP 捐赠给该基金会,从而为协议的持续演进确立了一个厂商中立的组织归宿。该治理架构独立于实现该协议的各类商业产品。(linuxfoundation.org)

应用场景与边界

MCP 支持软件开发、文档访问、数据库交互和业务工作流等多种集成场景。例如,数据库服务端可以将其模式结构作为资源暴露,将查询操作封装为工具,并提供解释工作流程的提示模板。远程服务端亦可在保留自身访问控制机制的同时暴露托管服务。(modelcontextprotocol.io)

MCP 与检索增强生成(RAG)关注的系统架构层面截然不同。MCP 定义的是获取信息和调用操作的接口;而检索增强生成侧重于利用检索到的信息辅助内容生成。从架构划分上看,MCP 服务端可以为此类系统提供底层检索能力,但 MCP 本身并不规定文档索引、检索排序或答案生成的方式。其定位严格限于上下文交互交换,而非宿主如何消化利用这些上下文。(modelcontextprotocol.io)

类似地,MCP 的工具调用也不同于模型供应商原生提供的工具调用接口。宿主需要将发现的 MCP 工具转换为其选定模型所接受的格式,并将模型生成的调用指令反向转换为 MCP 请求。即便外部接口实现了标准化,依然需要宿主端进行适配转换并提供相应的能力支持。(modelcontextprotocol.io)

安全性与局限

MCP 将语言模型应用连接至潜在的敏感信息和可执行操作,这使得网络安全和数据隐私成为系统实现的核心考量。协议规范明确要求实施用户授权确认、访问权限控制,并审慎处理工具执行过程。规范同时指出,仅凭协议本身无法强制保证安全;从不受信任的服务端接收到的描述和批注并不能作为安全行为的凭证。(modelcontextprotocol.io)

针对基于 HTTP 的部署环境,MCP 定义了一套基于 OAuth 的授权框架。身份认证与访问授权独立于模型请求操作的决策:即使模型发起了一个看似合规合理的工具调用,也不代表其拥有访问底层服务的实际权限。安全规范重点防范的风险包括令牌透传、混淆代理人漏洞以及服务端请求伪造(SSRF)等。(modelcontextprotocol.io)

访问资源同样会引入额外的安全风险。规范要求服务端在提供文件类资源时必须验证资源标识符并防御目录遍历攻击。提示词的输入与输出也必须经过校验,以防范注入攻击和越权访问。因此,符合协议规范并不等同于系统值得信赖:整体安全性依然依赖于服务端实现的严密性、宿主的防护拦截机制、凭证管理以及底层系统本身的权限配置。(modelcontextprotocol.io)

参考来源

  1. Introducing the Model Context Protocolanthropic.com
  2. Specificationmodelcontextprotocol.io
  3. Architecture overviewmodelcontextprotocol.io
  4. Toolsmodelcontextprotocol.io
  5. Resourcesmodelcontextprotocol.io
  6. Promptsmodelcontextprotocol.io
  7. Transports: Overviewmodelcontextprotocol.io
  8. Authorizationmodelcontextprotocol.io
  9. Security Best Practicesmodelcontextprotocol.io
  10. What's Changed in MCP: The 2026-07-28 Specificationgithub.com
  11. Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF), Anchored by New Project Contributions Including Model Context Protocol (MCP), goose and AGENTS.mdlinuxfoundation.org
  12. MCP joins the Agentic AI Foundationblog.modelcontextprotocol.io