MCP协议将吞噬API经济

技术领域有一个如此可靠地重复出现的模式，你会以为人们应该开始注意到了。一个新协议出现。它看起来像个玩具。严肃的工程师忽视它。然后五年后，它吞噬了一切。

HTTP对专有网络协议做了这件事。REST对SOAP做了这件事。GraphQL啃食了REST的边缘。现在MCP正在对整个"API集成"概念做这件事。

Model Context Protocol不仅仅是另一种连接事物的方式。它是对我们二十年来一直问错的问题的根本不同的答案：软件应该如何向其他软件暴露其能力？

REST API是为构建UI的人类设计的。你有端点。你阅读文档。你编写代码，按正确的顺序用正确的参数调用这些端点。每个集成都是定制的。

当消费者始终是人类开发者时，这运作得很好。但LLM不是人类开发者。它们不会阅读你的Swagger文档并编写fetch调用。它们需要不同的东西——一个结构化的描述，说明有哪些工具可用，每个工具做什么，以及调用时会发生什么。

MCP恰好提供了这些。不是"这是一个端点，自己搞清楚"，MCP说"这是一个工具，这是它的功能，这是它的输入模式，这是你会得到的返回"。这就是给人一张地图和给人一个GPS的区别。

使MCP具有变革性的不是任何单一功能。而是可组合性。

当每个服务都将自己暴露为MCP工具时，AI代理可以在运行时发现并使用它们。没有硬编码的集成。没有自定义中间件。没有"让我检查一下我们是否支持那个提供商"。代理看到存在哪些工具，理解它们做什么，然后使用它们。

这是应用于AI的Unix哲学：小而专注的工具可以组合。只不过现在的组合者不是shell脚本——而是一个能够推理应该组合哪些工具以及以什么顺序组合的LLM。

我们即将看到一场能力爆炸，让App Store显得古朴。

当然有个陷阱。总是有陷阱的。

当你让AI代理连接到任意工具变得轻而易举时，你也让它们连接到恶意工具变得轻而易举。工具投毒——工具的描述说一件事，但其实现做另一件事——是MCP时代的SQL注入。

今天发布MCP服务器的大多数团队都没有考虑这个问题。他们专注于让事情运作，而不是让事情安全。这正是科技史上每一次重大安全危机开始的方式。

在MCP经济中获胜的团队不是最快的团队。而是那些在不得不以痛苦方式学习之前就搞清楚安全的团队。

如果你正在构建将被其他软件消费的软件，你现在就应该考虑MCP。不是因为它时髦。而是因为经济效益不可抗拒。

一个REST API集成需要开发者数天或数周。一个MCP工具只需几分钟。当你让某件事简单100倍时，你不会得到100倍的相同东西——你会得到全新的类别，那些以前不值得构建的东西。

每个SaaS产品最终都会暴露MCP工具。每个内部服务都会有MCP接口。每个开发者工具都会原生支持MCP。

唯一的问题是你是为这个未来而构建，还是对它做出反应。