MCP 标准化了工具，现在我们需要围绕它们的基础设施。
内容提要
MCP协议虽快速标准化了AI与工具的连接，但生产级基础设施仍缺失。从演示到落地面临认证、权限、安全、可靠性、可观测性及上下文管理等挑战，团队重复搭建相同管道。远程服务器与渐进式工具发现成为趋势，但安全风险突出。MCP正演变为独立基础设施层，协议只是起点，围绕它的系统才是关键。
延伸解读
从演示到生产：MCP 落地的核心挑战
文章指出，MCP 协议解决了模型与工具之间的通信问题，但生产环境中的认证、权限、安全、可靠性、可观测性等基础设施仍然缺失。团队在演示中只需简单连接，但生产环境涉及多用户、多服务器、凭证管理、速率限制、故障恢复等复杂问题。这些挑战无法由协议本身解决，需要围绕 MCP 构建完整的运维体系。
远程服务器与本地部署的权衡
本地 MCP 服务器通过 stdio 易于实验，但团队规模扩大后，安装配置、版本漂移、凭证分散等问题凸显。远程服务器解决了部分问题，却引入了认证、延迟、多租户、数据安全等新挑战。2026 年 7 月的规范变更（移除协议级会话和初始化握手）使远程服务器更易扩展，但并未消除对认证和运维纪律的需求。两种模式各有适用场景，并非简单替代关系。
上下文与工具发现成为基础设施问题
随着工具数量增加，将全部工具定义加载到上下文会导致 token 成本高、选择准确率下降。渐进式工具发现和动态检索成为趋势，客户端最佳实践建议延迟加载完整定义并提供搜索式元工具。文章引用 Hexum.dev 的基准测试显示，优化上下文选择可将发送给模型的 token 从 220,393 减少到 27,352（降低 87.6%），同时通过所有测试。这表明上下文管理正从模型能力问题转变为基础设施设计问题。
安全与可靠性：自主代理带来的新要求
MCP 安全不同于传统 API 安全，因为代理可以读取不可信文本、将其解释为指令并调用工具修改外部状态，从而引发提示注入、权限过宽、工具描述污染等风险。2026 年一项对 7,973 个远程 MCP 服务器的测量研究发现，40.55% 的工具无需认证即可访问，这是部署问题而非协议问题。此外，自主代理可能不会在错误时停止，因此重试、幂等性、超时行为和可观测性变得至关重要。OpenTelemetry 的 GenAI 语义约定已开始包含 MCP 相关跨度，官方 Python SDK 默认发出追踪数据。
Q&A
MCP 协议已经标准化了工具连接，为什么还需要额外的基础设施？
因为 MCP 只解决了 AI 模型与工具之间的通信接口问题，但生产环境中的认证、权限、安全、可靠性、可观测性和上下文管理等运营问题并未被协议覆盖。团队需要重复搭建这些管道，因此需要围绕 MCP 的基础设施层来确保系统可靠、安全、高效地运行。
从演示到生产，MCP 部署面临哪些主要挑战？
生产环境需要处理多代理、多用户、多 MCP 服务器、凭证管理、速率限制、权限差异、故障重试、日志、工具模式变更、上下文约束以及机器异构等问题。每一层都可能独立失败，部分失败和状态不一致需要幂等或补偿机制，而协议本身不提供这些。
远程 MCP 服务器相比本地服务器有哪些优势和劣势？
远程服务器解决了本地服务器的安装配置、版本漂移、凭证分散和可观测性碎片化等问题，但引入了跨客户端认证、延迟、多租户、数据处理、正常运行时间和供应商依赖等新挑战。两者解决不同的约束，没有绝对优劣。
MCP 中的上下文管理为什么成为基础设施问题？
因为给代理提供全部仓库上下文会导致 token 成本高、信息无关、延迟增加和推理质量下降。更大的上下文窗口并不能解决该问题，关键在于选择哪些上下文应该存在。渐进式工具发现和动态工具检索可以减少工具定义 token 并提高选择准确性，这些都需要基础设施支持。
MCP 安全风险有哪些？为什么比普通 API 安全更复杂？
MCP 安全风险包括提示注入、混淆代理、权限过宽、恶意或污染的工具描述、通过参数或结果泄露机密以及服务器供应链风险。因为代理可以读取不可信文本、将其解释为指令并调用工具改变外部状态，所以信任边界和权限模型变得至关重要。2026 年一项研究发现 40.55% 的远程 MCP 服务器暴露工具时未认证。
当代理自主执行任务时，可靠性和可观测性有哪些新要求？
自主代理可能不会在错误时停止，因此需要重试、幂等、超时处理、部分失败处理和工具结果验证。可观测性需要重建模型所相信的内容、看到的上下文、知道的工具、选择的工具、生成的参数、工具返回结果以及后续动作。OpenTelemetry 的 GenAI 语义约定和 SEP-414 等标准化遥测正在出现。
MCP 基础设施未来可能形成怎样的技术栈？
一个可能的未来栈是：顶层是模型和代理，下面是代理运行时和 MCP 客户端，再下面是处理路由、认证、权限、上下文管理、工具发现、缓存、可观测性、策略和可靠性的基础设施层，然后是 MCP 服务器本身，最后是数据库、API、代码和 SaaS 系统。这个边界尚未固定，但协议的成功正迫使这一问题浮现。
