4-2 MCP 是什么? 在解决什么问题?

在上一个单元，我们讨论了 AI 代理的相关内容。在这个单元，我们将回到本章的主轴，进一步探讨 MCP 是什么、它解决了什么样的问题，以及为什么我们需要 MCP 这样的工具。以 Cursor 为例，我们将深入说明其应用。

什么是 Model Context Protocol (MCP)?

如果我们把 MCP 的三个字分别拆开来看，他们分别代表：

Model 模型，也就是大家熟知的 AI 模型，例如 GPT 模型、Claude 模型
Context 脉络，也就是提供给模型的额外资料
Protocol 协定，也就是一个通用的标准

而把这三个字连在一起，MCP 就是指让模型能够轻易对接到外部资料的一种协定。相信这时你可能会问，MCP 是能让模型对接外部资料的协定，不过为什么需要让模型能对接到外部资料?

在《AI 代理是什么?》一文中有谈到， AI 代理的核心要件之一是工具，而对接到外部资料意味着能让 AI 去操作外部工具。之所以这么说，是因为软体程式在做的事情就是操作资料，例如多数人都很熟悉的 CRUD 就是对资料的操作。

举例来说，假如今天用 AI 代理在 Cursor 或 Windsurf 这类的 AI 驱动 IDE 写完程式码，想要直接发一个 Pull Request 到 GitHub 上，在过去是做不到的，因为即使 AI 代理非常聪明，但没有对接到外部的工具，也无法完成这类的任务。所以开发者需要自己打开 GitHub，然后点击发 Pull Request，然后手动把 AI 生成好的 PR 相关描述，加到 GitHub 的 PR 当中。

不过当有了 MCP 后，这些手动的流程都能够被 AI 做掉。因为换个角度来谈，在 GitHub 发 PR 这件事，其实就是在 GitHub 的某个程式码库中，新增一笔 PR 相关的资料。因此，当把这类 AI IDE 透过 MCP 伺服器对接到 GitHub，在 AI 代理写完程式码后，就可以直接完成新增一个 PR 的操作。

为什么需要 MCP?

读完上面的段落，读者们可能会有个疑问「上面这段描述，不就是让 AI 模型呼叫 GitHub 中用来发送 PR 的 API 吗? 这样 MCP 在这边的做用是什么?」。如果你有这个疑问，说明你的理解没有错，以上面谈到「让 AI 代理直接发 PR」这个例子，AI 代理做的事情就是透过 GitHub 的 API 来发送 PR。

只是为什么又需要多一层 MCP 呢? 要回答这个问题，或许可以反过来问，如果没有 MCP 的话，AI 模型要怎么知道如何呼叫 GitHub 的 API? 事实上，AI 很可能不知道，假如你直接问 AI 模型「如何呼叫 GitHub 的 API 来发 PR?」，AI 模型的回答可能是基于训练资料 (所以可能过时)，又或者 AI 可能会有幻觉的回答。

因此，要避免模型用过时的方式，或者用幻觉的方式来呼叫某个外部的 API，过去在业界有个做法叫函式呼叫 (function calling)，是由开发者直接定义好某个函式 (或者某个 API)，然后定义好如何呼叫该函式 (或呼叫该 API)，然后再传入相对应的格式后，让模型去呼叫该函式 (或 API)。

在看完函式呼叫，相信读者可能会问，既然已经有函式呼叫这种方式可以呼叫外部 API，为什么又需要 MCP 呢? 两者之间有什么不同?

重点在标准化

这两种方式的一大区别在于，MCP 是从协定的角度出发，但函式呼叫则是让开发者可以灵活地自由定义，不同的开发者可以自由定义函式以及如何呼叫。灵活听起来似乎很不错，但是当不同开发者定义的方式不同，就会遇到「无法通用」这个问题。从软体设计的角度来看，当无法通用的问题在于普及度会困难，且不同的开发者可能会需要重新造相似的轮子。

这种因为缺乏标准，导致重复造轮子且互不通用的状况，在软体工程的历史上出现过非常多次。事实上，在 Anthropic 最开始把 MCP 开源时，有提到希望让 MCP 成为 USB-C 一样的存在。就如同 USB-C 这个标准形式，让每一个装置都能够透过 USB-C 来连接，不会因为换了装置后就不能继续用同样的接头。

虽然 MCP 由 Anthropic 提出，但 OpenAI 也宣布支援

以 USB-C 为例来说，先前苹果独树一格用自己的 Lightning 接头，让很多人忘记带充电线时，假如周遭的其他人都是用 USB-C，就变得没办法借别人的充电线来充电。但后来苹果也统一成 USB-C 后，这个问题就不复存在，只要有 USB-C，不管是用哪牌的装置，都能够共享。

而 MCP 的存在也是同样的道理，能让 AI 应用轻易转换、搭配不同模型；同时也能让模型轻易对接到不同的资料来源与工具。因此，如果要总结「为什么需要 MCP」，最核心的点，就是提供一个标准化的接头，透过标准化能让开发 AI 应用的人，能够更轻易地把 AI 模型与外部资料与工具接在一起。

有了统一标准，开发者不需要为每种模型重写介面，这降低了开发成本，让更多工具能快速与 AI 整合。

总的来说，MCP （Model Context Protocol) 是一个统一的协定，让不同的 AI 模型和应用能够轻松对接到外部资料和工具。它解决了函数呼叫各家表述的问题，节省开发时间，并促进更多工具与 AI 的整合，这也是 MCP 在社群中如此受欢迎的原因。

MCP 具体可以如何被应用

在了解完 MCP 是什么、为什么需要 MCP 后，让我们接着从 Cursor 中具体可以如何搭配 MCP，来理解 MCP 的具体价值。

在上一个单元我们有提到的 AI 代理。AI 代理需要与不同的工具对接，才能真正发挥其最大效益。以 Cursor 为例，如果我们仅用它来撰写程式码或进行测试，这样的效果其实是有限的。虽然在第三章节中，我们介绍了许多实际应用的案例，但如果你仔细检视工程师的整个工作流程，会发现仍有许多繁琐的工作可以被自动化，而这些工作正是 AI 能够帮助解决的。

要实现这些工作的自动化，AI 必须能够与各种工具对接。假如你希望 Cursor 根据某个需求自动实现某个函数及其相关测试，你仍然需要手动将需求复制并贴到 Cursor 的对话框中。但如果我们希望省去这个手动步骤，一个理想的方式是让 Cursor 直接与专案管理工具对接，例如 Linear 或 Jira。这样，Cursor 就能自动从 Jira 中抓取相关规格或需求描述。只要打通这个流程，我们甚至不需要手动输入需求，只需告诉 Cursor「根据 Jira 的某张 ticket 来实作功能」，即可完成任务。

再举另一个例子，当我们提供功能描述和规格后，Cursor 可以根据这些内容自动撰写端到端的测试案例。如果我们进一步将 Cursor 与 Playwright 这样的端到端测试工具对接，Cursor 不仅能撰写测试案例，还能透过 Playwright 直接开启浏览器，根据自己生成的测试案例逐步执行测试并完成程式码。

此外，如上面谈到的，如果我们将 Cursor 与 GitHub 对接，事情会变得更简单：Cursor 生成 PR 描述后，可以直接透过 GitHub 的 API 发送 PR 到 GitHub，无需手动复制贴上。

从这些例子可以看出，当 AI 代理能够与其他工具对接时，在软体开发的生命周期中，工程师需要处理的工作会大幅减少。那些通常被认为繁琐的任务，都可以透过工具的整合，由 AI 代理自动完成。

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