没有愚蠢的问题：什么是MCP服务器？为什么我关心它？

标题：毫无愚蠢问题：什么是 MCP 服务器？为什么我关心它？

原文链接：https://stackoverflow.blog/2026/05/08/no-dumb-questions-mcp/

Markdown 内容： 欢迎来到《毫无愚蠢问题》系列，这是 Stack Overflow 最不技术化的撰稿人菲比·萨乔与我们技术团队成员之间的一系列问答对话，她提出那些大多数人害怕问起的简单、基础的技术问题。本期访谈对象是 Stack Overflow 生态战略总监本·马罗尼，他所在的解决方案工程团队在将 MCP 功能集成到 Stack Internal 的过程中发挥了关键作用。

菲比·萨乔： 嗨，本，非常感谢你加入。我第一个必须问的问题是：什么是 MCP 服务器？ 本·马罗尼： 是的，这是个好问题。我认为市场上很多人——甚至那些已经在使用这些工具的人——都在问：“这新东西到底是什么？它会一直存在吗？”

MCP 只是一个缩写，代表 模型上下文协议。你可以把协议理解为一种标准。这个概念最初由 Anthropic 提出，大概是在 2024 年 11 月或 12 月。值得强调的是，它并不是一个长期存在的东西——这是一个相对较新的发展。其核心理念是，让大语言模型（LLMs）能够安全地连接到外部数据源。换句话说，它就像一座标准化的桥梁，将前沿的 AI 功能与软件世界中已有的各种工具和系统连接起来。通过采用统一的协议标准，我们可以更高效地构建通往这些新型 AI 系统的连接器。

PS： 当你说它是“连接器”时，我们之所以需要它，是不是因为正在开始构建需要连接多个组件的智能体工作流？另外，我对 API 其实也不太了解，但它是否能连接某种 API 或数据库？它是否让原本只存在于聊天机器人框内的工具，也能连接到这类系统？

BM： 我知道这里一堆缩写让人眼花缭乱，但在此之前，直到去年 11 月 Anthropic 发布 MCP 标准之前，几乎所有软件产品与其他工具之间的连接方式都是通过 API —— 这个词本身也是缩写，全称是“应用程序编程接口”（Application Programming Interface）。你可以把它想象成餐厅厨房与顾客之间的一扇窗户。通过这扇“窗户”，你可以以代码的形式传递信息，从而实现结构化、可重复的操作，让两个系统能够持续、稳定地互相通信。

但你的问题很好，因为问题在于：假设我们有产品 A、产品 B 和产品 C，它们来自不同的公司，在这个例子中。它们很可能各自都有自己的 API。每个产品都提供一个编程接口，允许用户通过编程语言与该系统的数据进行交互。但问题是，这三个 API 在配置上可能各不相同，运作方式也略有差异。

所以，如果我们想把产品 A、B、C 都连接到一个位于它们之上的第四款工具，并希望将所有系统集中到一个位置，那么过去虽然完全可行，但挑战在于：你需要花费大量时间去定制配置，才能理解产品 A 的 API、产品 B 的 API、产品 C 的 API。当你在构建这种高度互联的系统时，复杂性迅速上升。你必须搞懂每一个编程接口的工作原理，还要编写代码来规范它们之间的通信流程。

于是，Anthropic 提出了一个相当优雅的解决方案：他们说，“每个人都有自己的 API，也有各自的访问工具。那我们就建一个位于这些接口之上的通用工具。” 我们仍然会使用原有的编程接口，但这个新工具位于更高一层，它对底层接口进行了标准化。这样一来，当数据流向那个整合后的工具（比如大型语言模型或 AI 工具）时，AI 模型或智能体就能确切知道“接下来会收到什么”。它清楚数据的结构，理解各个字段的含义等等。这使得我们能够以前所未有的速度和便捷性，连接各种系统。

PS： 这让我终于明白了“模型上下文协议”中“上下文”这个词的含义。我学到了很多东西，真的太棒了！好了，你刚才提到这些连接器和配置，能让 API 被整合进这个工具。那之前还有其他尝试吗？我知道有 Agent2Agent 之类的缩写，还有我们刚才提到的其他术语。MCP 有什么特别之处？为什么整个行业开始更倾向于 MCP？是因为 Anthropic 提出的吗？是因为它是开源的吗？究竟是什么推动了 MCP，让它变得如此令人兴奋？

BM: 我认为你所说的每一点都有一定的道理。Anthropic 显然在人工智能和智能体（agentic AI）领域是思想领袖，这得益于他们的 Claude 模型以及 Claude Code。因此，Anthropic 希望开发一种协议或标准以实现更优的系统互联，也就合情合理了——因为这使得公司甚至终端用户能够将自己的数据连接到像 Claude 这样的模型上。这对大语言模型（LLM）的构建者来说同样具有价值。但从宏观角度来看，我们正进入一个系统间传递的数据量大幅增加的世界。我们已经从过去依赖 API 连接的模式中过渡出来，在那种模式下，要将工具 A 与工具 B 连接起来需要做大量工作和定制化配置。而现在，我们正在连接众多工具，它们未必彼此直接相连，而是都连接到大语言模型或智能体层。

你提到的另一个概念是 A2A（Agent2Agent）协议，这是来自 Google 实验室的成果。现在的情况是，必须相互沟通的系统数量突然激增，而且这个数字还在持续增长。如果你说：“嘿，本，你能做个连接器，让工具一和工具二对话吗？”理论上，只需要一条对话流通过代码完成即可。但当我需要把十个工具连接到一个智能体时，工作量就变得非常大了。如果存在十个智能体呢？或者是一万个智能体呢？因此，这个世界迫切需要一种更高效的上下文供给方式——正如你所指出的，MCP 中的“C”就是指上下文供给，为智能体层提供上下文，甚至允许这些智能体之间共享信息，从而让我们可以卸载过去人类知识工作者必须进行的大量定制化配置工作。我认为，整体思路是：这将为我们使用这些新工具带来一个更具可扩展性的未来。

PS: 这个词，“上下文”，为什么对智能体如此重要？为什么这些智能体必须拥有数据、连接到 API，或者能从 Stack Internal 中提取某些信息？为什么它们不能只待在自己的“盒子”里，完全不与其他系统连接？

BM: 在 Stack Overflow，我们有一个独特的视角，因为我们一直在与前沿实验室合作，深度优化大语言模型及其之上的智能体，使其表现卓越。尽管这项工作对公司和模型本身都带来了巨大回报，但现实是：智能体无法访问你所有的私有内部数据，因此它们在实际工作中难以做到足够智能，无法真正帮助员工达到最大生产力。近年来，大语言模型的开箱即用能力已显著提升。但上下文部分，尤其是对企业级上下文的安全访问，至关重要。根本问题在于：我们协助构建的大语言模型和智能体，并没有访问我的数据、我的公司数据、我的 Google Drive、我的 M365 数据、我的邮件、我的笔记等信息的能力。如果我们能建立一个安全的连接，并为企业数据提供安全的上下文访问，我们的智能体将变得高效得多。它们就能完成我们在安全工作环境中日常流程中已经完成的任务。这才是关键——通过 Stack Internal MCP 服务器，直接向人们正在使用的智能体提供高质量、高价值的数据。

PS: 我知道一点，人们一直在讨论训练数据，以及所有这些智能体连接到各种不同系统所带来的安全性问题。目前 MCP 处于什么阶段？是否存在关于安全性和隐私的担忧？这种安全性和隐私是否已经内建于协议本身？随着 MCP 的不断发展，我们还能期待什么？未来会不会出现更多关于其安全性的质疑？

BM: 这正是当前最核心的问题之一。许多大型企业都在担心使用 MCP 并允许跨系统的连接呈爆炸式增长。我们常用“链条”作比喻：链条的强度取决于最薄弱的一环。从企业安全的角度看，如果你让所有系统彼此通信，而其中一个智能体中包含了数据泄露或个人身份信息（PII）……如果这些信息通过基于模型上下文协议（MCP）或 A2A 框架的通信结构在整个系统中传播开来，那将给公司带来巨大的、严重的问题。所以答案是肯定的：我们确实存在重大担忧，那就是是否应该允许这些新智能体连接到所有底层软件和数据。我们能否真的放任这种情况发生？

在我们公司，针对 Stack Overflow 或 Stack Internal 的 MCP 服务器，我们必须非常谨慎地处理相关问题。我们所采用的解决方案——其他公司也在做类似的工作——是：每位用户，比如正在编写代码的工程师，当他们希望使用我们的服务器时，很可能会通过其正在使用的集成开发环境（IDE）来访问该服务器，对吧？这位工程师需要进行身份验证——实际上就是登录到我们的账户，从而在用户的编码会话与底层平台（我们的软件产品）之间建立一个安全连接，使用的是 MCP 协议。我们采用的是业界标准的身份验证框架 OAuth2，它能确保我们在数据包来回传输的过程中，始终维持安全性并准确追踪用户身份。整个设计的目的在于，让工程师能够直接在工作环境中访问优质上下文或经过验证的企业级数据，而无需频繁切换标签页、窗口，从而保持高效工作状态，随时获取所需答案。这样一来，工程师就能充分利用底层数据和上下文，在工作现场实现最大程度的生产力。

PS： Stack Internal 的 MCP 服务器有什么特别之处？我听说“双向通信”、“知识摄入”这些词被频繁提及，还有我们最新企业工具更新中提到的各种功能……这些到底意味着什么？

BM： 当前世界上已经存在许多 MCP 服务器。我想明确一点：即使是我们公司的客户，也完全有可能自行搭建自己的 MCP 服务器，并基于我们之前讨论过的 API 来构建。但作为一家公司，我们也推出了自有的一套 MCP 服务器，供客户使用。我们之所以会说：“嘿，客户 A，你应该试试我们的 MCP 服务器”，是因为在 Stack Internal 的数据仓库中，你拥有海量的问题、答案，以及丰富的社区互动内容，对吧？这些数据来自多年来持续使用平台的用户，他们为内容点赞、点踩，添加评论以澄清或更新随版本变化的包信息等。因此，当我们的 MCP 服务器访问这些数据时——例如将 Stack Internal 的上下文提取到 Cursor 或 GitHub Copilot 这类工具中——其内置的搜索功能经过优化，能够综合考虑所有使某条数据变得优质的关键特征。

举个实际很难判断的例子：假设有一条内容获得了大量互动和高票数，但内容非常陈旧。这比一条较新但互动较少的内容更可靠吗？如何相对权衡才能实现一次出色的搜索？如何准确地检索并保持上下文的时效性？因为我们自己就是这套数据的专家，所以当你调用我们的 MCP 服务器时，将获得极佳的搜索性能。

此外，我们的 MCP 服务器还具备与上述行为完全相反的能力。虽然世界上有些 MCP 服务器能做到这一点，但截至 2026 年 2 月，大多数尚未做到。在 Stack，我们非常重视保持知识库的“常青”状态。从底层数据中检索上下文并提供给大模型，这已经是常见做法；但健康的知识库必须不断更新内容。我们的 MCP 服务器会主动将数据写回数据库（即 Stack Internal），确保内容始终处于最新状态。例如，当用户在使用代码代理或在 IDE 中借助 GitHub Copilot 等工具工作时，如果找到了一个出色的解决方案，想要将其推回数据库以便后续复用，他们可以直接通过 MCP 服务器将信息发回底层数据库——Stack Internal，而无需离开当前界面。整个体验被整合在一个地方，让用户同时享受“读取”与“写入”的优势，无需上下文切换，更有效地保持专注流。

PS： 比如说，像我这样“全世界最差的程序员”，想把我们的 Stack Internal 实例连接到我私下开发的某个“蠢萌机器人”上，我该怎么操作？

BM： 其实并不难。唯一真正的要求是，你要将我们的 MCP 服务器连接到一个兼容 MCP 的工具。现实情况是，如今绝大多数 AI 平台和智能体都已具备 MCP 能力，原因显而易见——经过这次对话后，你应该就能理解了。对于这些工具而言，能够从不同资源中抓取数据，是一个巨大的价值提升。从我们这边看，我们已配置好所谓的“一键安装”流程，只需从落地页点击即可连接到开发者最常用的几款工具之一。你甚至只需点击一个按钮，就能从我们的 MCP 官网完成接入。

除此之外，设置过程极为简单，基本只需要几行代码。我们会向用户提供一个 JSON 数据包，用户只需按照我们之前讨论过的 OAuth2 登录流程完成登录，即可安装并访问 MCP 服务器中的数据。

PS： 如果你自己要用我们的 MCP 服务器打造一个酷炫的智能体，你会创建哪一个？

BM： 这是个非常好的问题。目前大家对自动化非常关注，所以我特别想把一些我自己的内部数据源连接起来，比如我的 Slack 消息和 Google Drive 文档，然后把这些内容整理成一篇文章发布到 Stack Internal 中。这样一来，所有信息都集中在一个地方了。虽然这不是我通过 MCP 服务器自定义构建的功能，但我已经把它接入了 Cursor——这是我进行大量编码实验、UI 原型设计等工作的主要工具，非常棒。实际上，我使用“写回”功能的频率几乎和“读取”功能一样高，因为我根本不想手动在文档中输入更新内容，然后再分享出去。我不太想用“懒”这个词，但也许可以说，作为一个忙碌的人，很多时候更新这个环节根本就没人做。我认为这在各个组织中都是普遍现象。如果成千上万的员工因为时间不够，实际写的文档都比应该写的少，而且说实话，写文档本身也不是什么有趣的事——那么，利用 MCP 服务器让一个智能体自动撰写文档或 README 文件，并将其回传到你的 Stack Internal 仓库，就是一场巨大的变革。我几乎每天都在用它。

PS： 嘿，在这个代理（agentic）世界里，我们都是又忙又懒的人。

BM： 没错。我们变得更高效了，同时比以前更“懒”了，大概就是这种感觉。

PS： 完全正确。