4-5 为什么企业争相推出 MCP 伺服器?

在之前的单元中，我们分别讨论了什么是 MCP (Model Context Protocol)，以及在 Curse 当中如何使用 MCP，并且如何开发自己的 MCP。在这个单元中，我们将进一步探讨为什么企业竞相推出自己的 MCP 伺服器。

回顾 MCP

首先，让我们回顾一下 MCP 的含义：

M (Model，模型): 指的是大家熟知的人工智慧模型，例如 GPT 模型或 Claude 模型。
C (Context，脉络): 指的是提供给模型的额外资料。
P (Protocol，协定): 指的是一个通用的标准。

MCP 的核心意义在于提供一个统一的协定，让 AI 模型能够与外部资料和工具进行对接。

透过 MCP，我们可以实现统一化的好处。以下图为例，假设 GitHub 开发了自己的 MCP 伺服器，这个伺服器就能被 Claude、GPT 或 Gemini 等不同的 AI 模型所对接。同时，在图表的右侧可以看到，诸如 Curse 或 Visual Studio Code Copilot 等工具，也可以透过 GitHub 的 MCP 进一步与后端的 AI 模型连接。

这样的架构带来的好处是，开发者无需为不同的模型开发不同的 API 呼叫方式。从开发商或开发者的角度来看，这能节省大量的时间与精力。

MCP 最早由 Anthropic 提出，Anthropic 是 Claude 模型背后的公司。在 Anthropic 之后，各大模型商也纷纷跟进支持 MCP 协定。例如，OpenAI 和 Google 都已宣布支持 MCP。Google 的执行长甚至在推文中公开表示对 MCP 的支持。

在这样的背景下，任何服务只要支援 MCP，就能轻松对接到不同的 AI 模型。这也解释了为什么企业竞相推出自家 MCP 伺服器。

企业推出 MCP 的动机

从企业的角度来看，对接到不同 AI 模型是一个重要的竞争优势。然而，有些人可能会担心，随着 AI 的发展，某些产品或服务可能被 AI 取代。以下我们以 GitHub 为例，分析为什么企业无需担心这一点。

GitHub 的核心服务是为工程师提供一个储存程式码的平台，透过 Git 进行版本控制。随着发展，GitHub 衍生出许多其他服务，但其核心功能始终是程式码储存。透过 MCP，GitHub 能够将服务与不同的 AI 模型对接，进而创造更高的价值。

具体来说，透过 MCP，GitHub 可以有的延伸价值

自动化 Pull Request：假设开发者透过 GitHub 的 MCP，在完成程式码后，可以让 AI 自动发起 Pull Request。
程式码审查（Code Review）整合：当同事在 Pull Request 中留下审查意见，开发者可以透过 GitHub 的 MCP，将这些意见导入 Curse，然后请 AI 协助根据回馈修改程式码。

在 GitHub 推出 MCP 后，其他程式码储存工具也开始推出自己的 MCP。如果竞争对手未跟进，他们的服务可能仅停留在程式码储存和版本控制的基础功能。而 GitHub 除了这些基础功能外，还能透过 MCP 让开发者自动化许多工作流程。相较之下，GitHub 提供的 MCP 创造了显著的差异化优势。

GitHub 的核心功能是提供程式码储存的空间，这就像现实生活中的房间或衣柜一样，是不可或缺的。即使 AI 技术再进步，工程师仍然需要一个地方来储存和管理程式码。因此，GitHub 的核心服务不会被 AI 取代。

相反，GitHub 需要思考的是，如何在其核心价值上整合 AI 以放大价值。透过 MCP，GitHub 成功对接 AI 模型，同时保留其核心功能，这正是企业推出自家 MCP 的动机。

思考框架：是否该推出自家 MCP?

在看了 GitHub 的案例，相信读者们会思考「该不该为自家的产品推出 MCP?」

建议读者进一步思考以下问题：

核心需求是否不可取代：你所在的公司或团队提供的服务，是否有一个即使 AI 出现也不会被取代的核心需求？
如何透过 AI 放大价值：在这个核心需求的基础上，能否整合不同的 AI 模型或工具来提升价值？

如果你的答案是肯定的，且能透过 AI 放大价值，那么推出自家 MCP 伺服器将是一个值得考虑的策略。

此系列文章为 《给工程师的 Cursor 工作流 — 透过 AI 代理全方位提升开发生产力》 搭配的教材。希望透过这系列文章，将过去协助导入 AI 工具及使用 Cursor 的经验扩展并分享给想提升生产力的读者。如果对课程感兴趣的读者，可以加入 E+ 成长计划，观看影片学习。