简介

Model Context Protocol（简称 MCP）是一种开放协议，用于将 AI 应用连接到外部上下文来源和可执行能力。应用可以通过一致的交互模型使用 MCP 访问文件、查询服务、调用业务逻辑或复用提示词模板。其核心思想是职责分离：应用负责编排对话，而 MCP 服务器则为数据或操作提供受控接口。

这种分离很重要，因为 AI 应用通常需要集成许多服务。如果没有共享协议，每个应用都必须针对每项服务分别定义连接器格式、发现机制、身份验证流程和工具模式。MCP 为主机和服务器提供了通用契约，减少与具体集成相关的代码，也让能力更容易被检查。MCP 本身不会提高语言模型的准确性，也不会取代授权系统，更不能保证外部操作是安全的。

一个实用的心智模型是把它看作一座受控桥梁：模型提出某项能力可能有用，主机决定请求是否获准，MCP 客户端发送协议请求，服务器执行或拒绝该操作。随后，结果通过客户端返回主机，由主机决定如何将结果呈现给模型和用户。

核心架构

MCP 主机是用户与之交互的完整 AI 应用。桌面助手、代码开发环境或自定义智能体服务都可以充当主机。主机负责对话流程，通常还决定配置哪些服务器、应用哪些权限、如何将工具结果插入模型上下文，以及某项操作是否必须经过用户批准。

MCP 客户端是由主机管理的协议组件。在常见架构中，主机会为每个 MCP 服务器创建一个客户端连接。客户端负责协议通信、初始化、能力协商、请求关联、通知以及传输相关的具体细节。客户端不是语言模型，也不是服务器实现，而是连接主机与单个服务器的连接层。

MCP 服务器是通过 MCP 暴露能力的程序。根据部署方式和客户端支持情况，它可以作为子进程在本地运行，也可以通过网络传输在远程运行。服务器可以从获准的数据源读取数据、调用外部服务或实现领域逻辑。服务器应当暴露范围明确且易于理解的接口，并自行执行输入验证，而不应假定主机或模型已经检查了每一项输入。

模型通常不会直接向服务器打开原始网络连接。相反，宿主会提供通过 MCP 发现的功能，并将相关结果纳入模型交互。这一边界有助于提升控制力和可观测性，因为宿主可以在执行外部操作之前记录请求、要求确认、应用策略并处理故障。

协议流程

MCP 会话从初始化开始。客户端和服务器会确认协议信息，并交换用于描述双方所支持功能的能力信息。在使用服务器的常规功能之前，客户端必须完成这一生命周期步骤。客户端还应处理服务器不支持某项可选能力的情况，而不应假设每台服务器都实现了所有功能。

初始化完成后，客户端可以发现服务器提供的功能。工具用于描述可通过结构化输入调用的操作，例如搜索问题跟踪系统或创建日历事件。资源表示可作为上下文读取的数据，例如文档或数据库查询结果。提示词表示服务器可以提供给宿主的可复用消息结构或工作流。这些类别的用途各不相同，不应将其视为可以互换的标签。

典型的工具调用流程包含多个阶段。宿主向模型提供工具定义，模型提出带参数的调用请求，宿主评估策略和用户是否同意。如果获得批准，客户端便向服务器发送请求。服务器验证参数，在允许的情况下执行操作，并返回结果或错误。随后，宿主决定应将结果展示给用户、传回模型，还是同时执行这两项操作。

MCP 消息采用基于 JSON-RPC 概念的结构化协议，因此请求、结果、错误和通知各自具有明确的作用。具体传输方式与消息含义相互独立。本地集成通常使用基于进程的连接，例如标准输入和标准输出；远程集成则可能使用实现所支持的基于 HTTP 的传输方式。传输方式负责承载消息，但不决定某项操作是否获得授权。

实际集成场景

设想一个连接到两台服务器的内部支持助手。一台工单服务器提供搜索工单和添加内部备注的工具。另一台文档服务器提供包含已批准故障排查页面的资源。宿主通过彼此独立的 MCP 客户端连接到两台服务器，并在启动期间发现它们所支持的功能。

当支持工程师询问某个已知错误的可能原因时，宿主可以让模型使用工单搜索工具和文档资源。搜索结果可能会找出相关事件，而文档资源则提供经批准的技术上下文。宿主可以将这两类结果及其来源信息一并提供给模型，使模型能够基于现有数据起草答案。

如果工程师要求助手向工单添加备注，工作流就会发生变化，因为该操作会产生外部副作用。宿主应显示目标工单和拟添加的备注，确认用户拥有相应权限，并在适当情况下请求确认。服务器仍应验证工单标识符、备注长度和授权上下文。一层的批准并不能免除其他层的验证责任。

最有价值的测试应覆盖完整的边界，而不只是最终答案。应验证初始化是否成功、是否正确处理不支持的能力、格式错误的参数是否产生受控错误、被拒绝的操作是否不会改变外部状态，以及服务器超时是否不会导致宿主显示虚构的成功消息。这些测试会明确集成行为，也更便于诊断问题。

常见故障模式

一个常见错误是将 MCP 与自主智能体框架混为一谈。MCP 定义了通信方式和能力暴露机制；它并不规定特定的规划算法、模型提供商、记忆系统或用户界面。智能体可以使用 MCP，但智能体循环仍然属于应用设计决策。另一个错误是把服务器的每项功能都视为工具，这可能会促使系统执行不必要的操作，而在这些情况下，只读资源可能更为合适。

安全漏洞往往源于过度信任。工具描述是有用的元数据，但并不是完整的安全边界。应在服务器端验证输入，限制文件和网络访问，保护凭据，并在操作边界实施授权。当一个小型的领域专用操作就能满足使用场景时，应避免暴露通用的命令执行工具。

运行故障通常涉及生命周期和传输处理。客户端可能会在初始化之前尝试发送请求，假定某项能力存在，在连接断开时未清除状态，或将超时误判为成功结果。应记录服务器身份、请求类型、关联信息、耗时以及经过清理的错误详情。不要仅为了简化调试而记录令牌、密码或敏感的用户内容。

另一个问题是允许工具结果在未经检查其来源或相关性的情况下进入模型上下文。外部内容可能包含误导性指令，或包含不适合再次传播的不安全数据。主机应在指令、检索到的数据和用户批准的操作之间保持清晰边界，同时由应用程序定义如何处理不受信任的内容。

摘要

MCP 为 AI 应用提供了一种标准方式，使模型能够连接到外部上下文和能力。主机负责应用体验和策略决策，客户端管理协议连接，服务器则暴露经过验证的数据或操作。明确区分这些职责，可以让集成更易于理解、推理和测试。

核心工作流程包括初始化、能力协商、发现、受控调用或检索，以及结果处理。工具适用于可调用的操作，资源适用于上下文数据，提示词适用于可复用的交互模板。协议可以通过不同的传输方式承载消息，但传输方式的选择不能替代身份验证、授权、验证或可观测性。

设计 MCP 集成时，应从最小且有用的服务器接口开始。明确服务器要暴露的内容，识别哪些操作具有副作用，决定哪些环节需要征得同意，并在连接模型之前规定失败行为。可靠的应用会将模型输出视为提案，由主机和服务器执行策略约束，并在报告成功之前验证外部结果。