MCP 就是新一代的微服务：AI 工具生态正在重蹈分布式系统的覆辙

如果你经历过 2015–2018 年的微服务爆发期，那么 MCP 的现状应该会让你感到不安的熟悉。一个真正有用的协议出现了。它很容易搭建。每个团队都搭建了一个。没有人追踪什么在运行、谁负责维护、如何保障安全。不到十八个月，你就会盯着一张工程师私下称为"死星"的依赖关系图。

Model Context Protocol 正在沿着同样的轨迹发展，速度大约是三倍。非官方注册中心已经索引了超过 16,000 个 MCP 服务器。GitHub 上有超过 20,000 个公开仓库在实现它们。Gartner 预测到 2027 年 40% 的 agentic AI 项目将失败——不是因为技术不行，而是因为组织在自动化有缺陷的流程。MCP 泛滥正是这个问题的症状。

我们不断重复的模式

这个周期是可预测的，因为我们在容器、Lambda 函数、Kubernetes 集群和微服务上都见过。新技术出现。它确实有用。它容易采用。采用速度超过治理速度。治理差距变成危机。平台团队被雇来收拾残局。

在微服务时代，承诺是独立部署、团队自治和多语言自由。大规模的现实是依赖关系爆炸、版本不兼容、单个不稳定服务导致的级联故障，以及远超它所替代的单体架构的运维负担。Uber 的微服务生态系统变得如此复杂，以至于工程师无法追踪服务之间如何交互。Netflix 构建了一整套开源基础设施层，仅仅是为了让他们的服务可观测。

MCP 正在 AI 工具层重演这个模式。"再加一个 MCP 服务器"就是新版的"再加一个服务"。每个单独看都合理。复合效应才是致命的。

为什么 MCP 泛滥如此之快

微服务在大多数组织中花了数年才达到临界质量。MCP 服务器的激增在数周内就发生了，原因有三个结构性因素。

创建门槛几乎为零。 任何开发者都可以在几分钟内搭建一个 MCP 服务器。没有配置审查，没有架构审批，没有容量规划。协议的设计目标就是易于实现，它在这方面做得太成功了。

AI 智能体创造了需求压力。 智能体需要访问的每个新系统都成为新 MCP 服务器的候选。与微服务不同——在那里人类架构师可能会反对不必要的拆分——智能体工作流以编程方式生成集成需求。智能体需要一个工具，有人构建了一个服务器，然后它就存在于你的基础设施中了。

没有内置的治理层。 MCP 不解决认证、审计追踪、可观测性、合规性、速率限制或错误处理。规范明确将安全性留给各个实现。在分析的 5,200 个开源 MCP 实现中，88% 需要凭证，但只有 8.5% 使用 OAuth。超过一半依赖长期有效的静态密钥——从不轮换的 API 密钥和个人访问令牌。

失败模式完全相同

MCP 泛滥导致系统崩溃的具体方式，直接映射到业界花了十年才学会处理的微服务失败模式。

单个不稳定服务器导致的级联故障。 当智能体依赖六个 MCP 服务器来完成一个工作流时，一个缓慢或不可用的服务器会降级整个链条。协议中没有内置断路器模式。没有重试标准化。没有舱壁隔离。每个集成点都是潜在的单点故障，而智能体积累集成点的速度远超人类编写的系统。

上下文膨胀取代了网络开销。 在微服务中，代价是网络延迟和序列化成本。在 MCP 中，代价是上下文窗口消耗。50 多个 MCP 服务器的工具定义可以在智能体处理单个用户请求之前消耗数万个 token。连接的服务器越多，智能体实际思考的空间就越少。这不是性能问题——这是智能体能力的根本性退化。

影子服务器倍增。 正如当团队在没有中央可见性的情况下部署时影子微服务泛滥一样，当开发者配置本地工具连接时就会出现影子 MCP 服务器。研究人员发现大约有 1,000 个暴露在互联网上且没有任何授权机制的 MCP 服务器。这些不是测试实例——它们是攻击面。

版本漂移悄无声息地破坏系统。 MCP 服务器没有标准化的版本控制。当服务器的工具签名发生变化时，连接的智能体不会收到编译错误——它们会出现性能下降或不正确的行为。失败模式是无声的准确性损失，这比 500 错误更难检测和调试。

适用的服务网格模式

加载中…