MCP 生产环境落地：可扩展的集成模式与架构实践 - Toolsify AI Blog

Demo 与部署之间的鸿沟

MCP（Model Context Protocol）的 demo 看起来很神奇。你把 Claude 连接到文件系统、数据库、Slack 工作区，AI 助手就能读文件、查数据、发消息。Demo 永远完美运行，生产环境永远不。

过去四个月我在三个企业环境部署 MCP 架构——一家 200 人的金融科技公司、一个中型电商平台和一家开发者工具公司。协议本身很优雅，生产挑战全在协议之外：传输可靠性、认证、可观测性、规模化错误处理，以及同时编排多个 MCP 服务器这个出奇棘手的问题。

MCP 定义了 AI 模型与外部工具和数据源交互的标准协议。传输层无关——有 stdio、HTTP+SSE、WebSocket 的实现。协议规定了工具发现、参数校验和结果返回。

MCP 不定义的东西：认证、授权、限流、连接池、重试逻辑。这意味着每个生产部署都需要自己构建这些基础设施。

stdio 是默认的最简传输。MCP 服务器作为子进程运行，通过 stdin/stdout 通信。适合本地开发和单用户场景。问题在于需要多客户端连接同一服务器，或服务器需要在客户端重启后保持运行时——stdio 将服务器生命周期绑定到客户端进程。

HTTP+SSE 是大多数生产部署的主力。服务器暴露 HTTP 端点，客户端通过 SSE 连接接收工具结果。提供进程独立性、水平扩展和标准 HTTP 基础设施兼容性。

我们所有生产部署都用 SSE，但有一个坑：SSE 连接是长连接，负载均衡器不能超时空闲连接。我们被 AWS ALB 默认 60 秒空闲超时坑过。修复方案：设置空闲超时 300+ 秒。

WebSocket 提供双向通信，适用于服务器需要主动发通知的场景。我们 12 个 MCP 服务器中只有 2 个需要 WebSocket。其余 SSE 足够且更简单。

我们使用三层认证模型：

第一层：传输认证。 MCP 通信开始前验证客户端。HTTP/SSE 使用 mTLS——客户端和服务端都出示证书。

第二层：会话认证。 客户端在初始化时发送会话令牌，映射到用户上下文。

第三层：工具级授权。 每个工具维护 ACL。每次工具调用都检查权限，不仅是连接时。

三层全部实现每个 MCP 服务器增加约 2-3 天开发开销。值得每一小时。

大多数生产部署涉及多个服务器。朴素方法是让 AI 客户端直连所有 MCP 服务器——8 个服务器、40+ 工具时就会崩溃。

我们用路由代理模式解决。MCP 路由器位于客户端和所有后端 MCP 服务器之间。路由器聚合工具列表、添加服务器前缀、路由工具调用、处理健康检查和故障转移。

路由器每 30 秒 ping 每个后端服务器。连续 3 次健康检查失败则移除。每个工具调用有独立超时，不是全局超时。

MCP 工具调用失败率比预期高。正常运行时 3-8%，事故期间 15-20%。

失败类别：瞬态网络错误（~40%，应自动重试）、验证错误（~25%，不应重试，返回清晰错误信息）、授权错误（~15%，立即返回）、服务器错误（~20%，视情况处理）。

关键洞见：AI 需要理解失败原因，不只是知道失败了。"工具调用失败"毫无用处。"query_customers 失败：数据库连接超时 5 秒，建议 30 秒后重试或缩小查询范围"提供了可操作的上下文。

跟踪工具调用延迟（p50/p95/p99）、错误率、调用频率、服务器健康状态。传播 trace ID 从 AI 客户端到后端服务器。告警阈值：错误率超过 10% 持续 5 分钟则值班告警。

工具名加版本号（query_customers_v2），路由器处理版本路由。至少一个发布周期保持向后兼容。

MCP 是 AI 工具集成的正确抽象。但生产 MCP 需要远超协议规范的基础设施工作。