什么是模型上下文协议（MCP）？连接 AI 与工具和数据的标准

模型上下文协议（MCP）是一项开放标准，允许 AI 应用通过一致的接口连接外部工具、数据、提示以及其他功能。 与其为每种模型与系统组合构建定制集成，开发者可以在 AI 主机与 MCP 服务器之间实现共享协议。

MCP 常被描述为 AI 的通用连接器，但这种类比并不完整。该协议并非仅仅传输数据。它定义了参与者如何建立能力、公开资源和操作、交换结构化消息以及维护安全边界。这使其成为新兴 AI 助手和代理基础设施的重要组成部分。

MCP 存在的原因

单独的模型无法查看公司的私有文档、检查本地代码库、查询实时数据库或调用内部服务。过去，开发者通过一次性插件和特定应用的 API 将这些功能连接起来。

这种做法会导致集成问题。如果十个 AI 应用各自需要连接十个系统，团队可能需要维护数十个定制适配器。每个适配器对工具、上下文、身份验证、错误和更新的表示方式可能各不相同。

MCP 创建了一个通用合约。兼容 MCP 的应用可以与以已知格式公开能力的 MCP 服务器进行通信。官方 模型上下文协议规范 定义了该协议，而各个主机和服务器则自行决定支持哪些功能和安全策略。

MCP 架构

MCP 将 AI 应用的对话和模型逻辑与每个数据源或服务所需的集成逻辑分离。主机可以同时维护多个客户端连接——一个用于文件系统服务器，一个用于数据库服务器，另一个用于业务应用——并通过一致的接口向模型展示它们的功能。

服务器不一定是远程互联网服务。它可以在桌面应用旁本地运行、在公司网络内部运行，或作为远程服务。部署方式会改变传输方式和信任边界，但核心关系不变：客户端从服务器发现功能并与其交换结构化消息。

MCP 采用主机‑客户端‑服务器架构。

• 主机： 用户交互的 AI 应用，例如助手、编码环境或代理平台。
• 客户端： 由主机创建的协议组件，用于维持与特定 MCP 服务器的连接。
• 服务器： 向 MCP 客户端公开选定工具、资源或提示的程序。

主机可以一次连接多个服务器。一个服务器可能提供文件仓库的访问，另一个提供项目管理系统的访问，第三个提供内部数据库的访问。主机仍然负责用户体验、模型编排、授权以及放入模型上下文的信息。

消息采用 JSON‑RPC 约定进行结构化。在初始化期间，参与者协商协议版本和功能。此协商很重要，因为客户端和服务器并不需要实现所有可选特性。

工具、资源与提示

MCP 将服务器提供的功能组织为若干原语。最常见的三类是工具、资源和提示。

工具

工具是 AI 应用可以调用的可执行函数。例如搜索客户数据库、创建问题、运行查询或检索当前库存。工具定义包括名称、描述和输入模式，以便模型和运行时了解预期的参数。

工具的使用可能会更改外部系统，因此主机应显示有意义的描述、验证输入、应用权限，并对重要操作要求确认。

资源

资源是应用可以读取的上下文，例如文件、数据库记录、文档页面或生成的报告。资源使用标识符并可公开元数据，如名称和媒体类型。它们为主机提供一种标准化的方式来发现和获取信息，而不必把每一次读取操作都视为一次动作。

提示

提示是服务器向主机提供的可重用模板或工作流。它们可以帮助用户正确调用功能、提供结构化参数，或将领域特定指令与相关上下文相结合。

MCP 也支持相反方向的能力。根据协商的内容，服务器可能请求主机获取模型完成结果或用户输入。重要的设计原则是显式的能力协商，而不是假设每个参与者都能执行所有操作。

MCP 工具调用期间会发生什么？

考虑一个连接到代码库分析服务器的 AI 编码助手。

1. 主机连接到 MCP 服务器并协商支持的能力。
2. 客户端请求可用工具列表。
3. 服务器返回结构化的工具定义，包括它们的输入模式。
4. 主机向模型提供所选工具的描述。
5. 模型提出工具调用，例如搜索函数的引用。
6. 主机检查策略，并在必要时请求用户批准。
7. 客户端将已验证的请求发送给服务器。
8. 服务器执行操作并返回结构化内容或错误。
9. 主机决定向模型提供结果的哪一部分用于下一步。

MCP 标准化了交互，但它并不决定模型是否可信以调用工具。此决定属于主机及其策略层。

MCP 并不取代 API

MCP 服务器通常封装现有的 API、软件开发工具包、命令行工具或数据库驱动程序。这些底层接口仍然执行实际工作。MCP 在其之上添加了面向 AI 的发现和交互层。

这种区别说明了 MCP 与 REST、GraphQL 以及其他应用接口是互补的。支付服务可以保留其成熟的 API，同时 MCP 服务器以模型友好的描述和模式公开受限的操作子集。

MCP 与函数调用的比较

函数或工具调用是模型的能力：模型可以返回结构化请求以调用函数。MCP 是用于发现和与工具及上下文提供者通信的协议。

两者常常协同工作。MCP 服务器告知主机存在哪些工具。主机向模型展示选定的定义。模型发出工具调用。随后主机使用 MCP 将该请求发送至相应服务器。

MCP 与 Agent2Agent 的比较

MCP 将 AI 应用连接到能力和上下文。Agent2Agent（或 A2A）侧重于不同系统或组织拥有的自主代理之间的通信。

实际系统可以同时使用两者。代理可能使用 MCP 访问其工具和数据，然后使用 A2A 将更大的任务委派给另一代理。MCP 回答“该应用如何使用该能力？”而 A2A 回答“这些代理如何协同工作？”

安全风险与控制措施

安全主机维护服务器和工具的显式白名单，在授予访问权限时显示有意义的同意，并将每一次调用关联到授权的用户或工作负载身份。工具模式应足够严格，以拒绝意外参数；审计日志则应记录服务器、功能、输入、结果状态以及批准路径。

返回的资源和工具结果同样是提示注入的攻击面。通过 MCP 读取的文档可能包含要求模型忽略指令或泄露数据的文本。主机必须保持不可信内容与系统策略之间的区分，并应防止一个服务器的输出悄悄扩大另一个服务器的权限。

标准化提升了互操作性，但并不能使服务器可信。MCP 服务器可能泄露敏感数据、提供误导性的工具描述、执行不安全操作或包含受损的依赖。通过资源检索的不可信内容也可能携带旨在操控模型的提示注入指令。

重要控制包括：

• 最小特权： 为每个服务器仅提供其目的所需的凭证和范围。
• 服务器信任： 在连接之前验证服务器的来源、代码、所有权及更新路径。
• 用户可见性： 明确哪个服务器将接收数据以及它将执行的操作。
• 输入验证： 在模型之外强制执行模式和业务规则。
• 批准边界： 确认敏感、外部、金融或破坏性操作。
• 数据最小化： 当仅需小部分时，避免发送完整文档或对话。
• 日志记录与撤销： 记录调用、监控异常，并使凭证和连接易于禁用。

MCP 项目持续完善其架构和安全指南。项目的 2026 规范更新 展示了标准如何围绕更简化的基础设施、授权和生产部署而演进。

开发者何时应使用 MCP？

MCP 在多个 AI 客户端需要对同一功能保持一致连接、工具需在运行时可发现，或团队希望将 AI 编排与系统特定集成代码分离时，是一个强有力的选择。

对于只有一个严格受控后端的小型应用，直接函数调用可能更为简洁。采用该协议则伴随自身的运维工作：服务器生命周期管理、兼容性测试、身份验证、可观测性以及治理。

关于模型上下文协议（MCP）需记住的要点

MCP 是 AI 应用与其工具和上下文之间的通用语言。其价值在于用可发现、结构化且可扩展的协议取代孤立的集成约定。

该标准并未消除细致工程的必要性。主机仍需决定信任哪些服务器、暴露哪些功能、共享何种数据以及何时需要人工批准操作。MCP 使连接可移植；治理则确保其安全且有用。