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 错误更难检测和调试。

适用的服务网格模式

微服务世界最终通过服务网格架构、API 网关和平台工程解决了其治理危机。同样的模式直接适用于 MCP 基础设施。

MCP 网关相当于 API 网关。 不是让每个智能体直接连接数十个服务器，网关提供一个单一入口点，将多个后端服务器的工具联合到一个受管理的表面。网关处理认证、策略执行、路由和遥测——这与 API 网关对大规模微服务至关重要的职责完全相同。推荐的生产架构很直接：MCP 客户端连接到网关，网关连接到后端 MCP 服务器，后端服务器连接到上游系统。

策划的工具表面取代服务目录。 生产网关不应暴露每个服务器的每个工具，而应实现白名单工具、按智能体的特定工作流视图和面向模型的使用说明。这是成熟微服务组织维护的服务目录的 MCP 等价物——你不会让每个服务调用每个其他服务，也不应该让每个智能体访问每个工具。

按需发现减少上下文开销。 智能体可以通过搜索动态发现工具，而不是预先加载所有工具定义（相当于导入每个微服务客户端库）。标记为延迟加载的工具仅在需要时才解析，在保持可发现性的同时节省上下文窗口预算。

MCP 基础设施的成熟度模型

不是每个组织从第一天就需要完整的 MCP 平台。但每个在生产中运行 MCP 服务器的组织都需要知道自己在成熟度曲线上的位置以及何时投资下一个级别。

级别 1：临时模式（1-5 个服务器）。 个别开发者将智能体连接到工具。配置存在于本地文件中。认证方式取决于开发者的设置。这对于实验来说是可以的。对于涉及生产数据的任何东西来说则不行。

级别 2：已编目（5-20 个服务器）。 内部注册表跟踪每个服务器及其所有者、用途和权限。OAuth 2.1 替代静态 API 密钥。有人能回答"我们运行了多少个 MCP 服务器？"这个问题。这是最小可行治理。

级别 3：网关管理（20-50 个服务器）。 集中式网关处理认证、速率限制和审计日志。工具表面按智能体或工作流策划。可观测性已被植入——你可以追踪从智能体通过网关到后端服务器的请求。这是大多数生产部署应该瞄准的目标。

级别 4：平台工程化（50+ 个服务器）。 MCP 基础设施被视为一个平台，具有黄金路径、预批准配置、自动化合规检查和生命周期管理（包括退役）。这是你需要专门的平台工程而不仅仅是另一个工具服务器的阶段。

做好 MCP 的组织不会是拥有最多服务器的组织。它们会是真正知道自己有多少服务器、谁负责每一个、以及当一个宕机时会发生什么的组织。

2026 路线图告诉我们什么

MCP 的维护者——现在跨越 Anthropic、AWS、Microsoft 和 OpenAI，在 Linux 基金会下——意识到了这些问题。2026 路线图直接解决了有状态会话管理与负载均衡器的冲突、水平扩展需要变通方案以及缺乏标准化服务器发现元数据等问题。

但路线图侧重于协议级别的修复。它有意将审计追踪、SSO 集成、网关行为和配置可移植性等企业需求留为未定义，寻求正在经历这些压力的团队的第一手反馈。

协议与平台之间的这个差距，与 HTTP 和微服务发生的情况完全一样。HTTP 给了你一种标准的请求方式。又花了十年时间才建立起使微服务真正可管理的服务网格、API 网关和可观测性堆栈。MCP 正处于同样的拐点。

真正的教训

错误不在于采用 MCP。该协议确实有用，对 AI 智能体架构越来越不可或缺。错误在于以我们采用微服务的方式来采用它——充满热情，没有治理，并假设运营成熟度会自行出现。

它不会。微服务时代没有，MCP 也不会。采用曲线正在超过治理曲线，而早期认识到这一点的组织将避免花接下来两年时间收拾一个完全可预测的烂摊子。

如果你今天运行了超过五个 MCP 服务器，却无法回答基本问题——我们有多少个、谁负责它们、它们持有什么凭证、当一个失败时会发生什么——你已经落后了。开始构建 MCP 平台的时机不是第一次事故迫使你这样做的时候。是现在。