生成式 AI 正在迅速成为当今技术版图中的一股力量，它重塑了各行各业，也重新定义了我们解决问题的方式。从自然语言处理到图像生成，生成式 AI 在各个领域的融入，为创新与效率打开了新的可能性。
对我们开发者而言，把生成式 AI 集成到应用开发工作流并非没有复杂性。我们必须谨慎评估诸如模型准确性、伦理考量以及计算效率等因素。
在构建应用的过程中，我们需要思考如何标准化构建 AI 应用的方式。标准化意味着“一切看起来都一样”，这应当带来跨团队、跨工具更易于集成与协作的体验。
这正是 Model Context Protocol（MCP，模型上下文协议） 发挥作用的地方——它用于标准化：让 AI 驱动的应用能轻松从工具、内容与提示（prompts）中找到所需；稍后我们会详细展开。
本章涵盖以下主题：
- 我们是如何走到今天的：从 SOAP 到 REST、GraphQL、gRPC，再到 MCP
- 为什么需要一个标准
- 可能性无穷：只要会写提示词，海量 MCP 服务器任你调用
- 什么是 MCP？
我们如何走到这里：从 SOAP 到 REST、GraphQL、gRPC，再到 MCP
在深入 MCP 之前，让我们先回顾一下来时路。
我早期使用 Web 请求的记忆之一，是用 XML 发送与接收数据。那还是 SOAP（Simple Object Access Protocol，简单对象访问协议） 的年代——它是一种在 Web 服务实现中交换结构化信息的协议。它很强大，但也相当复杂且“厚重”。
随后出现了 REST（Representational State Transfer，表述性状态转移） ，这是一种更简单的构建 Web 服务的方式。它使用 HTTP 与 JSON，使开发更易上手。REST 曾经、并仍然非常好用。
REST 并没有“天生的错”，但你可以这么看：如果你有后端与前端两支团队，前端团队常常需要等待后端完成工作，才能开始前端构建。GraphQL 的出现改变了这一点——它允许你只查询所需数据，使使用 API 更加灵活。当然，它也带来其他问题，例如过取（over-fetching）与欠取（under-fetching） ，以及著名的 N+1 问题。N+1 问题是 GraphQL API 常见的性能隐患：为了获取关联数据而发生多次请求，导致效率下降与时延增加。
还有 gRPC（Google Remote Procedure Call） ——一个高性能的 RPC 框架，使用 HTTP/2 与 Protocol Buffers。gRPC 非常适合微服务，并让你以更结构化的方式定义 API，但其搭建与使用也可能较为复杂。
为什么需要一个标准
上述每种格式各有所长，但也都有自身的问题。而且，问题往往不是“选哪个协议”这么简单，而更像是在构建应用时你必须反复自问的一串问题：
- 这个应用/API 到底能做什么？ 我们如何以一种易理解、易使用的方式，清晰暴露应用的能力？当然，目前为止还没有大家都认可的统一标准——直到现在。
- 如果“提示词”成为新的交互方式，我们要如何构建应用？ 随着用户习惯于用提示词与应用交互，你会开始思考：哪一部分属于生成式 AI，哪一部分属于应用本身的能力？
- 是否应将大语言模型（LLM）与其他能力解耦？ 我是否真的需要把生成式 AI 与应用能力“堆在一起”？
- 如果二者分离，我们能获得什么？ 若能将两者拆分为客户端与服务器两部分，也许我们就能轻松消费他人构建的服务器——代理（agentic）时代由此到来。
这些问题确实值得思考。但这还不足以回答“为什么我们需要一个标准”。让我们更进一步：
- 我们开发者“太会写代码了” ：问题在于，我们太擅长把各种东西“糊”在一起。我们能构建使用多个 AI 模型的应用，也能让采用不同协议与格式的应用彼此通信。这不总是容易，但我们做得到。
- 能做得到，但代价几何？ 如前所述，能把任何东西包成一个 REST API 并让它与其他组件对话，并不代表我们就应该这么做。时间成本与工程成本究竟有多高？
- 解决之道：一个标准。现在，你应当已经看到我们为什么需要标准。好消息是：一个旨在解决这些问题的标准正在发展中，这就是 MCP。它不仅允许你以标准化方式描述资源与能力，还允许你描述如何与之交互。
这意味着：你几乎可以把 MCP 覆盖到任意应用之上，于是任何会说“MCP 语言”的客户端都能与它互动。想象这样一个场景：你有一个客户端，它可以同时与本地与远程运行的多个 MCP 服务器通信。所有这一切之所以可能，是因为你在一个 mcp.json 文件中列出了这些服务器。
突然之间，你便拥有了访问一切想象中资源的“工具箱”，从数据库到云服务，再到任何暴露 MCP 服务器的服务。你几乎不费力就变得“具备代理性（agentic） ”。可能性由此大幅拓展！
接下来，我们将进一步讨论 MCP 为我们打开的种种可能性。
无限可能：只要会写提示词，MCP 服务器的世界任你遨游
“无限”是个很大的词，那我们究竟指什么？想象一下：有些技能你今天可能还不会。在有 MCP 服务器的世界里，这不再是问题。因为当 API 由 MCP 包装之后，代理（agent）就能让你通过提示词把事办成。
以 3D 模型的创建与管理为例。Blender 是常用的 3D 建模工具。要使用它，你需要 3D 建模技能。所以你会花上数小时学习如何使用这款应用——当然，这是一项值得拥有的技能。
但有了 Blender 的 MCP 服务器，对 3D 建模知识的依赖就没那么强了。你可以直接通过一个提示词说明你想完成的目标。就像电影《黑客帝国》（The Matrix）里，主角 Neo 在把信息直接“上传”进大脑后说：“I know Kung Fu（我会功夫了） 。”未来已来。只要你会写提示词，你就是 Neo。
这里是 Blender MCP 服务器及其暴露能力的链接：github.com/ahujasid/bl…。
现在，任何内置自己 LLM 且会说 MCP“语言”的客户端，都能调用任意 MCP 服务器。因为 Blender 不是唯一示例，其他大公司也在拥抱 MCP。比如：
- GitHub MCP
- Playwright MCP
- Google Maps
想查看 MCP 服务器清单，请访问：github.com/modelcontex…。
还有更多服务器正在出现，数量每天都在增长。所以，卷起袖子，一边构建你自己的 MCP 服务器，一边善用现成的吧！
你大概也在想我在想的事：我们每个人都能拥有自己的 Jarvis（《钢铁侠》中的 AI 助手），无所不能。我们要做的，就是利用现有的 MCP 服务器，并把缺的那部分补上——用 MCP 就对了。
想象一个能帮你做任何事情的私人助理：从安排日程到管理财务。有了 MCP，这一切都成为可能。
未来正大声敲门。你准备好开门了吗？
什么是 MCP？
以下是 MCP 官方网站对它的描述：
Model Context Protocol（MCP） 是一个开放协议，旨在标准化应用向大语言模型（LLM）提供上下文的方式。你可以把它看作 AI 应用的 USB-C 接口：为把 AI 模型连接到各种数据源与工具提供了一种标准化的方法。
这对应用开发者意味着什么？
这意味着我们构建应用的方式正在改变，并变得更加标准化。学习并使用 MCP 后，你的所有应用都能以标准化方式彼此通信与共享数据。这表示你会减少为“如何把你的应用和别的应用粘在一起”而操心的时间，把更多时间花在真正重要的功能构建上。
我们会在下一章更深入地讲解这些概念的细节。但就现在而言，你已经在“万米高空”层面理解了 MCP 是什么、如何工作，以及涉及哪些核心组件。
小结与下一步：接下来做什么？
我们已经理解了问题、解决方案与几乎无限的可能性，也了解了 MCP 的一些核心概念。但在动手构建我们自己的 MCP 服务器之前，或许还需要再多了解一点。下一章我们将继续深入。
