关注【索引目录】服务号，更多精彩内容等你来探索！
我们已经看到Google对 MCP 的支持，OpenAI 也为 MCP 提供支持，Dockerhub 上也专门开设了 MCP 版块。这意味着 MCP 将会继续存在，并被所有巨头广泛采用。
好了，我们已经讨论了模型上下文协议 (MCP)——它的目标是成为“AI 的 USB-C”，为 AI 模型创建一种获取所需数据和工具（即“上下文”）的标准方式。听起来很棒，不是吗？一个标准接口满足所有需求。但这里有一个实际问题：当你的 AI 助手需要使用 MCP 获取某些上下文时，提供该上下文的 MCP 服务器在哪里？它是在你的电脑上运行，还是在互联网上的某个地方？
主要有两种类型：本地 MCP 服务器和远程 MCP 服务器（通常称为基于服务器）。了解它们的区别是理解这些连接如何工作、它们的适用性以及哪种设置可能支持你的 AI 工具的关键。让我们来详细分析一下。
本地 MCP 服务器
本地 MCP 服务器与 MCP 客户端运行在同一台机器上，主要通过 stdio（标准输入/输出）进行通信。这是一种简单有效的本地集成方法，例如访问本地文件或运行本地脚本。当客户端和服务器在同一台机器上运行时，本地 MCP 服务器使用 stdio 传输。
工作原理：
- 位置
：在本地机器（笔记本电脑或台式机）上生存和呼吸。 - 设置
：用户需要自行安装和配置；这是一个自托管设置。这可能涉及在终端或 Docker 镜像中运行命令，并直接提供 API 密钥。 - 通信
：通常使用标准输入/输出（stdio）与 AI 客户端对话。 - 凭证与安全
：您通常在本地管理必要的机密信息（例如 API 密钥）。这赋予您直接的控制权，并意味着您有责任确保这些机密信息的安全。 - 可访问性
：通常，只有在同一台计算机上运行的 AI 客户端才能与其对话
优点（优点）：
- 速度
：由于通信是在本地进行的，因此速度可以非常快。 - 掌控一切（隐私）
：数据处理可能完全在您的计算机上进行（取决于服务器的功能）。用户可以直接监督服务器进程及其密钥。非常适合敏感文件。 - 离线工作
：如果服务器连接的数据或工具也是本地的，那么即使您的 Wi-Fi 断线，它也可以工作。 - 开发者游乐场
：非常适合构建和测试新 MCP 集成的开发人员。
缺点（缺点）：
-
繁琐的设置：正确安装和运行需要运行 docker 镜像或 npm 命令，然后进行设置。并非每个人都能做到“即插即用”。 -
基于用户的维护：用户需要处理更新并确保其保持顺利运行。 -
计算资源有限：它占用了运行 MCP 的部分机器资源（CPU、内存）。 -
卡在一台机器上：在您的 Web 浏览器中运行或由同事使用的 AI 代理无法轻松访问您的本地 MCP 服务器。
远程 MCP 服务器
远程 MCP 服务器可通过互联网访问。用户只需登录并使用熟悉的授权流程向 MCP 客户端授予权限即可。这些服务器大多由公司或组织托管在云端（例如 Neon 用于其数据库的远程服务器，或未来可能由其他公司托管的服务器）。这些 MCP 通过 SSE（服务器发送事件）使用 HTTP，客户端通过 HTTP 连接到服务器。
工作原理：
-
位置：在云端其他地方托管的强大服务器上运行。 -
设置：对于最终用户来说通常非常简单。无需安装任何东西，只需通过浏览器登录或授权访问即可，通常使用 OAuth 等安全的 Web 标准。 -
通信：使用标准互联网协议。来自服务器的消息通常通过服务器发送事件 (SSE) 发送（非常适合流式更新），而发送至服务器的消息则使用常规 HTTP POST 请求。这需要互联网连接。 -
凭证与安全：身份验证通过 Web 标准 (OAuth) 进行安全处理。服务器托管服务提供商负责管理其安全性，您只需授予特定权限即可。 -
可访问性：任何具有互联网访问权限的授权 MCP 客户端都可以连接 - 桌面应用程序、IDE，以及至关重要的基于 Web 的 AI 代理（例如 Replit 中的代理、浏览器中的编码助手等）。
优点（优点）：
-
轻松设置：无需本地安装。通常只需在登录流程中点击“允许”即可。 -
随时随地访问：使基于 Web 的 AI 代理能够使用工具和数据。使该功能得到广泛应用。 -
始终保持最新：提供商处理更新，因此您始终无需动手即可获得最新的功能和安全补丁。 -
可扩展性：可以利用强大的云基础设施实现可靠性并处理大量用户。
缺点（缺点）：
-
需要 Wi-Fi（互联网）：没有互联网，就没有连接。 -
可能会有轻微延迟（延迟）：通过网络发送消息比本地直接管道发送消息的时间略长。通常不明显，但有可能出现。 -
信任主机（提供商依赖）：依赖第三方提供商来确保服务器的正常运行时间、安全实践以及他们如何处理隐私。 -
数据传输（传输）：您的请求以及潜在的数据片段通过网络传输到远程服务器（尽管这通常使用 HTTPS 保护）。
正面交锋：本地与远程一览
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
何时使用哪个？找到合适的
那么，哪一个“更好”呢？关键的区别在于 MCP 服务器的部署位置。如果需要像任何基于服务器的应用程序一样进行访问，那么基于 SSE 的全局 MCP 是最佳选择。如果您只是测试一下，那么可以使用本地 MCP。
我分享了一份详细的分析：
在以下情况下选择本地 MCP 服务器：
-
您是一名正在积极 构建或测试 MCP 服务器或集成的开发人员。 -
您需要您的 AI 助手来访问 绝 不能 离开本地机器的高度敏感数据。 -
您需要绝对 最低的延迟，并且服务器仅与本地文件或工具交互。 -
您更喜欢 直接控制 服务器进程并自己管理其密钥。
在以下情况下选择远程 MCP 服务器：
- 您需要基于 Web 的 AI 代理
可以访问的工具和数据 ——这是远程服务器的巨大驱动力！ -
您希望 为最终用户提供简单、零设置的体验。 - 您必须为许多不同的用户
或客户提供对特定工具或数据库的轻松访问 。 -
您很乐意让 提供商处理更新 和维护。
结论
在本地和远程 MCP 服务器之间进行选择，需要权衡利弊，并根据具体任务选择合适的工具。本地服务器提供针对特定任务的控制力和速度，而远程服务器则提供无与伦比的可访问性和易用性，尤其适用于为 Web 代理提供强大的工具，从而支持多个用户访问 MCP。
最终选择取决于您的具体用例、安全要求、用户群和部署需求。
关注【索引目录】服务号，更多精彩内容等你来探索！