AI中的MCP是什么？模型上下文协议解释

AI 为什么需要外部连接

AI 助手可能擅长解释代码或起草会议议程。但要求它检查实时存储库问题或该问题背后的私有文件时，就会出现差距。您的日历或内部知识库也是如此。该模型可能能够解释这些信息，但应用程序仍然需要一种受控的方式来检索它。

开发人员传统上一次建立一个连接。一个助手获得存储库集成。另一个需要日历连接器，而第三个通过不同的界面访问同一问题跟踪器。随着 AI 应用程序和外部系统的增加，它们的集成也随之增加。每个连接都涉及身份验证和权限决策，随后是持续的维护和数据处理责任。在大规模情况下，一次性连接变成了重复的工程工作。

缺失的部分不是更智能的模型。它是 AI 应用程序和外部上下文或操作之间的可重用连接边界。本指南定位该边界并追踪通过它的一个请求。然后它分离附近的概念并帮助您判断其适用性。

什么是 MCP 以及为什么存在

Model Context Protocol (MCP) 是一个开放标准，使兼容的 AI 应用程序能够以一致的方式连接到提供数据、工具和可重用工作流的外部系统。这是对官方介绍的重述。”开放标准”意味着供应商可以实现共享的公共规则，而不是某一产品的私有连接器格式。实际上，通过 MCP 发布的功能可以服务于多个兼容的主机，受限于每个主机支持和允许的内容。

常见的类比是”AI 应用程序的 USB-C”。产品可以实现共享的连接标准，而不是为每一对配置发明不同的插头。类比的局限性同样重要。兼容性不能证明系统是安全的、授权的或高质量的。它也不意味着每个主机都支持相同的功能。

Anthropic 在 2024 年 11 月 25 日推出了 MCP，随后在 2025 年 12 月将其贡献给 Linux Foundation 的Agentic AI Foundation。它现在是一个开放治理的跨供应商项目，而不是仅限 Anthropic 的专有功能。主要 AI 应用程序和开发者工具中的支持广泛，尽管实现和批准行为各不相同。

MCP 架构：主机、客户端和服务器

MCP 主机是面向用户的 AI 应用程序。它协调界面、模型和与外部系统的连接。主机策略决定了哪些功能出现以及何时需要批准。主机还将结果返回给用户。模型在其内部运行；它通常不直接连接到外部系统。

MCP 客户端是主机为服务器连接创建或管理的协议通信组件。每个连接的服务器对应一个客户端。产品界面可能会隐藏它，但客户端和主机仍然是不同的。单独的客户端将连接和公开的功能保持在主机控制之下。

MCP 服务器是通过 MCP 公开功能的程序——不是硬件类。同一服务器可能在笔记本电脑上运行，并在用户账户下处理选定的本地文件。将其作为远程服务运行时，网络身份和可用性成为运营问题。其 MCP 角色在两个位置保持不变。

服务器公开三种主要功能类型。工具是一种操作，例如检索问题或创建日历事件。资源是可读的上下文，例如文件、记录或架构。提示是可重用的交互模板，例如事件审查提示。

User request
     ↓
┌─ MCP host: AI application ───────────────────────────┐
│ Interface + model + policy/approval + result handling│
│                                                     │
│ ├─ MCP client A ────────────────────────────────────┼─⇄ Local MCP server
│ └─ MCP client B ────────────────────────────────────┼─⇄ Remote MCP server
└─────────────────────────────────────────────────────┘          │
                                                                 ├─ each exposes tools / resources / prompts
                                                                 ├─ local server ⇄ local files or application
                                                                 └─ remote server ⇄ external API, database, or service

Request/action travels →        Result/context returns ←

官方架构概述更深入地介绍了这一点。服务器可能位于现有 API 或数据库前面。它还可以公开对命令行界面、文件系统或业务服务的访问。MCP 标准化了公开和交换；底层系统存储数据或执行操作。

用服务台的术语来说，主机协调访问。每个客户端是分配给一个服务台的协议通信员，而每个服务器发布一个功能菜单。该菜单显示可用性，而不是安全性。

MCP 请求的工作原理

考虑该架构的实际运作。开发者要求编码助手检查一个问题和相关的代码库文件，然后解释可能的原因。该任务是只读的：调查，但不编辑、提交、合并或部署。

典型的概念流程有六个阶段：

1. 主机连接。助手被配置为通过其 MCP 客户端到达问题和代码库服务器。
2. 主机发现并过滤功能。客户端了解其服务器提供的内容；主机通过配置、相关性和权限缩小范围。
3. 用户提出问题。主机向模型提供请求、可用上下文和仅相关的功能描述。
4. 模型提出操作。它选择适当的读取工具。主机应用策略并在需要时请求批准；行为因主机和配置而异。
5. 服务器执行工作。它调用问题跟踪器、代码库接口或 API，并通过客户端返回结构化结果。
6. 模型解释证据。主机将返回的信息添加到模型上下文，模型向用户解释。

这里，功能发现意味着客户端了解服务器当前提供的内容，而不是依赖硬编码到应用程序中的菜单。提供者可以演进该菜单，而无需在每个主机内单独重新定义它。

如图所示，请求从主机移动到客户端、服务器和底层系统。结果沿相同路径返回，然后模型使用它们。

小的、特定于任务的功能集通常优于完整目录。范围缩小限制了不必要的权限。更少的描述也减少了令牌使用、成本和延迟，同时使工具选择不那么混乱。发现提供选项；主机决定哪些选项进入交互。

MCP、API、函数调用、Agent 和 RAG

MCP、API、函数调用、Agent 和检索增强生成 (RAG) 经常被视为竞争对手。它们解决不同的问题，并经常协同工作。

分层链可能如下所示：底层服务/API → MCP 服务器 → MCP 客户端/主机 → 模型工具选择 → 可选 Agent 循环。

在存储库示例中，API 提供数据，MCP 服务器公开限定范围的读操作。函数调用让模型提议该操作。可选的 Agent 循环可能会重复批准的读取。该服务保持其现有接口，同时兼容主机获得发现操作的标准方式。

“连接器”和”插件”是产品标签，不是 MCP 同义词。两者都可能使用 MCP 或专有集成；仅凭名称无法揭示协议。

MCP 的实际用例

MCP 用例有两种实际形式。上下文和读取操作收集证据而不改变源。后果性操作产生外部影响，例如更新数据或发送消息。MCP 可以公开两者；安全部分解释了第二组所需的更严格控制。

因此，最安全的首个项目是范围窄且读取繁重的：

开发团队可以针对相同的存储库和问题使用编辑器、聊天界面和审查工具。共享功能为每个主机提供相同的范围内证据，减少调查开始前的设置工作。

对于业务团队，直接价值是更快的准备。已批准的知识库或 CRM 上下文可以支持响应草稿或会议摘要，因此员工在审查前花费更少的时间收集背景信息。

自托管用户可以使用相同的模式检查私有文件和家庭实验室服务，无需在多个界面之间切换。云和 IT 团队可以将日志、指标和运行手册纳入一次调查，使事件证据更容易关联。

在所有四行中，有用的首个项目具有命名源、明确的任务和可观察的结果。这使其价值在范围扩大之前更容易判断。

本地与远程 MCP

MCP 服务器是一个软件角色，可以存在于两个常见的位置。本地服务器是主机启动或通过 stdio 访问的进程，意味着本地进程之间的直接标准输入/输出。它位于本地文件和应用程序附近，通常服务于一个客户端，可能以用户的权限运行。

远程服务器是一个持续可访问的服务，通过 HTTPS 使用 MCP 的远程传输（目前为 Streamable HTTP）访问。它可以服务于一个或多个兼容的主机。”远程”意味着可由其预期的网络客户端访问，不一定暴露于公网。

Local:  AI host → stdio → local MCP process → scoped local files/app
                        [same-machine trust boundary]

Remote: AI host → HTTPS → remote MCP service → API/database/business system
                        [network + identity trust boundary]

远程运行 MCP 会产生普通的服务责任。访问和密钥需要保护，而日志和监控使行为可见。补丁、可用性和网络边界也成为运营问题。下一部分全面涵盖这些控制。

标准的 AlexHost VPS 可以适合小型、始终在线的远程 MCP 服务或网关。AlexHost AI 托管仅在自托管模型推理是单独的、计算密集型工作负载时才重要。MCP 本身不需要 GPU。

MCP 安全和信任

当数据和操作跨越边界时，兼容性成为一个安全问题。服务器可能接收选定的数据或公开触发外部操作的工具。工具的名称和描述是软件声明，而非安全行为的证明。同样的谨慎也适用于其注释。

位置改变风险。本地服务器是可执行代码，可能继承用户的文件和网络访问权限。远程服务器通过网络接收数据，因此其身份和授权控制很重要。连接还取决于传输保护和对运营者的信任。

⚠️ 警告：连接兼容性不是信任证书。与 USB-C 一样，互操作性不决定组件是否应该接收您的数据或权限。

使用以下六部分基线：

1. 有意识地选择。优先选择官方、经过审查或内部控制的服务器。在运行本地代码前检查确切的命令和包。
2. 保持暴露范围狭窄。仅允许必要的服务器、功能、目录、记录和工具。从只读开始并应用最小权限原则——仅授予所需的最小访问权限。
3. 控制重要操作。对发送、删除、支付、部署、权限更改等操作要求明确批准或硬性政策。
4. 保护远程访问。使用适当的身份验证和授权、HTTPS、作用域凭证和谨慎的密钥处理。
5. 隔离本地进程。在实际可行的地方对其进行沙箱处理，特别是当它们不需要广泛的文件系统或网络访问时。
6. 保留有用的日志。记录连接、数据共享、工具调用、批准、失败和结果以供审计。

注册表有助于发现，开源许可证允许检查，有效的实现建立兼容性。单独任何一个都不能保证安全。官方 MCP 安全指南为实现者提供了更深入的信息。

安全是共享的。主机控制暴露，服务器执行其边界。运营者保护部署和凭证，而底层系统授权每个请求。

何时使用 MCP

当独立提供的功能需要在兼容主机之间重用时，MCP 的额外边界就体现出了价值。当这些功能随时间变化时，运行时发现也可能很重要。共享边界可以保持治理的一致性，同时允许功能和主机分别演进。

如果一个应用程序只需要一个小的、稳定的集成，直接 API 调用或应用程序自有函数可能更简单。如果代码已经知道操作顺序，使用确定性工作流：一个预定义的序列，优先考虑可预测性和可审计性而非模型选择的步骤。

使用这六个问题作为实用过滤器：

1. 是否有多个兼容的 AI 主机会重用该功能？如果否，直接集成可能就足够了。
2. 功能是否必须独立于主机演进或需要动态发现？如果否，应用程序自有函数可能更简单。
3. 应该由模型在操作之间选择，还是序列已经已知？已知序列更适合确定性代码。
4. 团队能否治理这个边界？如果不能，暂不添加重要的 MCP 工具；先应用安全部分的控制措施。
5. 增加的延迟、功能选择错误和服务运营是否由重用来证明其合理性？如果否，保持边界更小。
6. 目标主机是否支持项目所需的原语和批准行为？如果不确定，在标准化 MCP 之前验证兼容性。

动态发现的”是”不是暴露完整目录的理由。过多的描述会消耗令牌、增加成本和延迟，并使选择变得不太可靠。更多工具不能保证更好的应用程序。

从最简单的可行集成开始。仅当检查清单指向相比直接集成有明确优势时，才选择 MCP。

结论

返回到最初的助手。MCP 没有改变模型的推理能力。它为主机提供了一种定义明确的方式来检索选定的外部上下文。

心智模型很简单：服务器暴露；客户端连接；主机控制；底层系统执行工作。MCP 是更大的 AI 堆栈中的一个连接层。

在采用 MCP 之前，请确定一个狭窄的、只读的功能，该功能对多个 AI 主机都有益。如果您无法命名一个，请改为直接集成。