模型上下文协议（MCP）：它是什么以及如何构建服务器
您团队基于大语言模型的应用程序通过一个自定义集成与搜索索引通信，通过另一个集成与代码仓库通信，通过一串 LangChain 工具与 PostgreSQL 数据库通信，并通过原始 Python 输入/输出调用与文件系统通信。每增加一个新的数据源，就意味着要编写一个新的集成。每个集成使用不同的身份验证模型，并以不同的格式返回数据。大语言模型应用程序与其接触的每个后端紧密耦合，替换其中一个需要直接修改应用程序代码。
模型上下文协议（MCP）的存在是为了用单一的标准化接口取代这种定制化的底层架构。可以将其视为大语言模型应用程序的 USB-C 端口：一种连接器形状，一种协议，任何兼容的服务器都可以插入任何兼容的客户端，而无需定制接线。
为什么标准协议很重要
在过去两年中，基于大语言模型的工具在能力上呈爆炸式增长，但集成方案并未跟上步伐。每个人工智能应用程序（集成开发环境助手、聊天客户端、代理框架）历史上都为自己的数据库、应用程序编程接口、文档存储和代码仓库构建了自己的连接器。没有共享的契约。如果您想在两个不同的人工智能助手中使用特定的代码搜索工具，则需要两个单独的集成。
MCP 借鉴了语言服务器协议的设计哲学，该协议标准化了代码编辑器如何与语言分析器通信。在语言服务器协议出现之前，每个编辑器都有针对每种语言的自己的插件。在语言服务器协议出现之后，一个语言服务器可以与所有编辑器配合工作。MCP 旨在为人工智能工具及其所需的数据源做同样的事情。
该协议是一个开放标准，最初由 Anthropic 公司创建，并根据麻省理工学院许可证发布。该规范在 2025 年 11 月 25 日版本达到稳定状态，截至 2026 年 5 月，Python 软件开发工具包（PyPI 上的 mcp）版本为 1.27.2。2026 年 6 月发布了带有更新传输层的 2.0.0 阿尔法版本。
MCP 的工作原理
MCP 使用 JSON-RPC 2.0 作为其消息格式。客户端（人工智能应用程序）通过以下三种传输类型之一连接到服务器（提供上下文的服务）：
- 标准输入/输出：客户端将服务器生成为子进程，并通过标准输入/标准输出进行通信。最适合本地单用户设置。
- 服务器发送事件：服务器作为超文本传输协议端点运行，客户端通过超文本传输协议连接。适用于跨机器通信。
- 可流式传输的超文本传输协议：一种较新的传输方式，允许通过超文本传输协议进行双向流式传输。添加于 2025 年 11 月 25 日的规范中。
以下是概念架构：
flowchart LR
subgraph Client["客户端（人工智能应用程序）"]
A["宿主<br/>集成开发环境 / 聊天 / 代理"]
B["MCP 客户端<br/>协议处理器"]
end
subgraph Server["MCP 服务器"]
C["MCP 服务器<br/>协议处理器"]
D["资源<br/>上下文数据"]
E["工具<br/>可执行函数"]
F["提示词<br/>模板化工作流"]
end
A <--> B
B <-->|JSON-RPC 2.0<br/>标准输入/输出 / 服务器发送事件 / 超文本传输协议| C
C --> D
C --> E
C --> F
每个 MCP 会话都以能力协商握手开始。客户端宣布其支持的功能（采样、根目录、 elicitation [注：此处指引导或引出信息的能力]）。服务器宣布其提供的功能（资源、工具、提示词）。在进行任何数据交换之前，双方就功能集达成一致。
服务器原语
服务器提供三大类功能：
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
