远程 MCP 服务器成趋势，但面临身份验证、安全风险和生态碎片化等挑战。API Gateway 可解决这些问题，实现身份验证、负载均衡和开发者引导。Kong AI Gateway 等工具助力将 MCP 扩展到生产级，为 LLM 提供安全可靠的工具访问。
译自：Remote MCP Servers: Inevitable, Not Easy
作者：Michael Field
随着我们深入 2025 年，人们对 Anthropic 的 模型上下文协议 (MCP) 的兴趣和热情有增无减。但仍然存在很多不确定性：它真的是一个游戏规则改变者，还是只是炒作周期中的最新一部分？在本系列中，我试图帮助你回答这些问题。
在第 1 部分中，我深入研究了 MCP——它是什么，不是什么，以及为什么你需要将其纳入你的基础设施。在第 2 部分中，我研究了围绕它如此多炒作的主要原因：启用 Agentic AI 工作流程。在这第三个也是最后一个部分中，我将解释本地 MCP 服务器的问题，你在远程 MCP 之旅中可能遇到的问题，以及为什么一个熟悉的工具可以帮助你解决这些问题。
如今，绝大多数 MCP 服务器都在本地运行，并利用标准输入/输出 (stdio) 传输进行本地通信。这意味着每个 MCP 服务器都必须与 MCP 客户端一起在本地安装。虽然这对于快速测试来说很棒，但这大大阻碍了拥有更大的工具代理网络的能力，原因如下：
- 互操作性有限：MCP 的美妙之处在于它能够帮助为大型语言模型（LLM）和代理建立一个多样化的、有弹性的服务生态系统。本地 MCP 服务器不能轻易地在团队、工具或代理之间共享——即使有注册表，每个用户也必须手动安装和配置它们，这会使生态系统碎片化。
- 没有中央更新：更新需要每个客户端手动重新安装或重新同步，从而增加了维护开销以及跨环境的版本漂移的风险。
- 更难安全和审计：当每个实例都在本地和独立运行时，更难应用集中式安全策略、监视使用情况或审计工具行为。
- 消费者糟糕的开发者体验：其他开发者或代理无法简单地“调用”你的服务器或发现其工具，除非他们克隆你的整个设置，这会扼杀重用性和可组合性。
随着 Anthropic 最近对 MCP 规范的更新，它显然正在为远程服务器的爆炸式增长奠定基础，这将有助于解决上述问题。这在为“可流式 HTTP”传输添加实验性支持以取代现有的 HTTP+SSE 方法中最为明显。这消除了对持久的、有状态的连接的硬性要求，并默认为无状态 MCP 服务器。
此外，Anthropic 最近更新了 MCP 规范，引入了基于 OAuth 2.1 的 MCP 授权。虽然这是远程 MCP 服务器的必要步骤，但围绕这种方法引入的问题已经进行了很多讨论——即，要求 MCP 服务器同时充当资源服务器和授权服务器。
MCP 服务器走向远程是不可避免的，但并非毫不费力。虽然转向远程优先的 MCP 服务器有望实现可扩展性和重用，但它也引入了一系列新的运营和架构挑战，需要引起重视。当我们远离紧密集成的本地工作流程并拥抱分布式可组合性时，我们必须面对许多威胁开发者体验和系统弹性的关键问题。
MCP 规范建议使用 OAuth 2.1 作为安全远程访问的基础，但其实现细节仍然复杂且存在问题。MCP 服务器预计将同时充当授权服务器和资源服务器。这种双重责任打破了传统的安全模型，并增加了配置错误的风险。
与可以依赖完善的身份和访问管理 (IAM) 模式的传统 API 不同，MCP 引入了新的身份挑战，尤其是在具有不同访问策略的嵌套服务器之间链接工具时。
MCP模型中一个更为微妙但至关重要的漏洞最近由Invariant Labs指出。 在其所谓的“工具中毒攻击 (Tool Poisoning Attacks, TPAs)”中，恶意行为者可以将有害指令直接注入到 MCP 工具的元数据中。 由于这些描述被 LLM 解释为自然上下文，因此中毒的工具可能会悄悄地破坏代理推理，并强制其泄露敏感数据、执行意外操作或破坏决策逻辑。
当 MCP 服务器可以公开发现或在组织边界之间共享，并且没有明确的边界来验证或约束哪些工具是值得信赖的时，这些风险会加剧。
当本地工具出现故障时，这只是个人的不便；当远程 MCP 服务器出现故障时，这是一个系统性故障，可能会蔓延到整个代理工作流程。 在这个世界中，高可用性成为一项硬性要求，尤其是在工具链依赖于服务器链接时。 单个上游服务器离线可能会导致整个计划执行停滞。
然而，如今，MCP 缺乏内置的负载均衡或故障转移机制。 这些是需要解决的关键差距，因为我们越来越依赖分布式组合。
随着 MCP 服务器的激增，可发现性成为一个紧迫的问题。 开发者如何找到受信任、维护良好的服务器？ 他们如何知道有哪些工具可用或如何调用它们？ 虽然 Anthropic 已经暗示了其路线图中的注册表系统，但目前还没有可靠的发现解决方案。
如果没有明确的文档、入门和治理策略，开发者将被迫在一个碎片化的生态系统中摸索，从而导致可重用性和协作受到影响。
远程组合听起来很优雅，但当你意识到添加到会话中的每个服务器都会扩大 LLM 上下文窗口时，你就不会这么认为了。 工具元数据、参数模式、提示模板——所有这些都会累加起来，尤其是在高流失率、多代理环境中。
一旦工具被注入到上下文中，就无法保证它们会被明智地使用。 LLM 通常偏向于调用上下文中出现的工具，即使是不必要的。 这可能会导致冗余调用、臃肿的提示链和低效的工作流程。 注册的远程服务器数量的增加将加剧这个问题。
对于那些沉浸在 API 中的人来说，许多这些挑战听起来很熟悉。 身份验证怪癖？ 负载均衡？ 开发者入门？ 这些是现代 API 管理工具（尤其是 API 网关）十多年来一直在解决的问题。
MCP 不会取代 API。 它只是引入了一个新的接口层，使 API 更易于 LLM 使用。 事实上，许多 MCP 服务器只是现有 API 的巧妙包装器。 因此，与其重新发明轮子，不如让我们探讨如何将经过实战考验的 API 网关应用于新兴的远程 MCP 服务器世界。
网关在管理身份验证和授权方面已经非常出色，尤其是在企业环境中。 你可以委托给与适当的身份提供商和授权服务器对接的中央网关进行身份验证，而不是依赖于每个 MCP 服务器充当其自己的 OAuth 2.1 提供商（这种模式会引入安全性和操作复杂性）。
这简化了令牌处理，支持集中式策略实施，并遵循组织已经信任的真实 IAM 模式。
网关可以充当重要的安全层，过滤和强制执行哪些 MCP 服务器和工具甚至有资格传递到 LLM 上下文中。 这为组织提供了一个自然的检查点，以实施允许列表、扫描工具中毒模式，并确保只有经过审查的、受信任的来源才能包含在代理工作流程中。
从本质上讲，网关成为一个可编程的信任边界，位于你的代理和开放式的 MCP 世界之间。 如果使用得当，仅此一项就可以消除一大类工具中毒攻击。
当 MCP 服务器在网关后面注册时，你将获得自动的好处：负载均衡、故障转移、健康检查和遥测。 网关专为高可用性而构建，它们旨在将请求路由到最健康的上游服务器。
这对于代理工作流程至关重要，因为一个环节的失败可能会中断整个链。 添加监控和断路器，你就拥有了 MCP 目前缺乏的可靠、可观测性基础设施层的基础。
现代 API 网关不仅仅是路由流量，更是整个开发者生态系统的基石。API 门户、内部目录、使用情况分析和引导流程在当今的 API 管理堆栈中都得到了很好的支持。MCP 没有任何理由应该有所不同。
通过类似网关管理的开发者门户公开 MCP 服务器，可以提供一致的发现、文档和访问控制，将分散的服务器蔓延转变为精选的功能市场。
最后两个问题——LLM 上下文膨胀和偏差——是更难啃的骨头。但这就是未来更智能的网关可以发挥作用的地方。
想象一下，网关不仅仅是一个代理，而是一个自适应的 MCP 服务器：它连接到上游 MCP 服务器，检查它们的工具，并根据用户的提示选择性地注入相关的上下文。它可以维护持久的上游连接并动态处理工具注册，从而减少生成冗余客户端进程的需要，并最大限度地减少 LLM 上下文中的 token 膨胀。
像 mcpx 这样的工具已经开始了这条道路，但在网关中集中和扩展这种能力是有意义的。毕竟，它已经是您组织 API 的前门。
随着 AI 代理从新奇事物发展成为现代软件的核心组件，它们对结构化、可靠地访问工具和数据的需求变得至关重要。MCP 引入了一个强大的新接口来公开该功能，使代理能够跨服务进行推理、计划和行动。但是，随着 MCP 服务器转向远程优先模型，开发和运营的复杂性急剧上升。
从身份验证和负载均衡到上下文管理和服务器发现，通往远程 MCP 的道路并非没有坑洼。然而，对于那些在 API 基础设施领域花费时间的人来说，许多这些挑战都很熟悉。这就是为什么长期以来一直被信任用于保护、扩展和公开 HTTP 服务的 API 网关，可能是将 MCP 扩展到生产级、企业就绪领域的完美解决方案。
在 Kong，我们相信这种融合已经发生。借助 Kong Konnect 平台和 Kong AI 网关，组织可以开始将经过验证的网关模式应用于像 MCP 这样的新兴 AI 接口。从可扩展的身份验证到负载均衡和开发者引导，远程 MCP 所需的大部分内容已经存在。