跳转至

企业级MCP网关的混合语义工具发现：架构与实现

文章背景与核心概要

随着大语言模型（LLM）代理越来越依赖外部工具来扩展其预训练知识之外的推理能力，模型上下文协议（MCP）等架构为暴露这些能力提供了标准化方式。然而，企业级环境面临着严峻的扩展挑战：将数百个后端服务器聚合在单个代理后面，会产生上下文工程瓶颈（完整的工具模式会饱和模型的上下文窗口）以及工具可发现性障碍（难以从数千个选项中识别出最优工具）。

为了解决这些挑战，PayPal的研究人员推出了 SCOUT（面向通用工具的选择性上下文优化，Selective Context Optimization for Universal Tooling）。SCOUT将工具暴露重新定义为一个动态的上下文选择问题，通过混合检索（结合BM25稀疏匹配和使用倒数排名融合的稠密向量搜索）仅注入与当前用户查询步骤相关的工具。在PayPal的生产环境中，SCOUT成功将MCP工具的Token消耗从 140.2k个Token（占上下文的70.1%）降低至1.3k个Token（0.8%）——实现了惊人的 99%的削减，在企业规模下显着降低了每查询的推理成本，同时保持了完全与模型无关的特性。

论文概述

  • arXiv 标识符： arXiv:2608.23992 [cs.IR]
  • 主要学科： 信息检索 (cs.IR)
  • 次要学科： 人工智能 (cs.AI)
  • 提交日期： 2026年8月25日
  • 作者： Olympia Saha, Amy Wang, Srinivasan Manoharan

Paper Overview

  • arXiv Identifier: arXiv:2608.23992 [cs.IR]
  • Primary Subject: Information Retrieval (cs.IR)
  • Secondary Subjects: Artificial Intelligence (cs.AI)
  • Submission Date: August 25, 2026
  • Authors: Olympia Saha, Amy Wang, Srinivasan Manoharan

背景与挑战

企业级LLM网关通常会聚合分布在200多个后端MCP服务器上的2,000多个索引工具，以提供安全认证、策略执行和可观测性。这种方法带来了两个复合瓶颈：

  1. 上下文饱和： 预先暴露完整的工具模式会消耗模型上下文窗口的大量部分（例如，超过70%），甚至在处理任何用户提示词之前就已经如此。尽管提示词缓存有助于降低重新处理的成本，但它既不能释放上下文容量，也无法提高代理的准确性。
  2. 可发现性障碍： 在处理数千个潜在工具时，用户和自主代理都难以针对特定任务识别出最相关的单一工具。

Background & Challenges

Enterprise LLM gateways often aggregate over 2,000 indexed tools distributed across more than 200 backend MCP servers to provide secure authentication, policy enforcement, and observability. This approach introduces two compounding bottlenecks:

  1. Context Saturation: Surfacing full tool schemas up front consumes a massive portion of the model context window (e.g., over 70%) before any user prompt is even processed. While prompt caching helps lower reprocessing costs, it neither frees up context capacity nor improves agentic accuracy.
  2. Discoverability Barriers: When dealing with thousands of potential tools, both users and autonomous agents struggle to identify the single most relevant tool for a specialized task.

SCOUT 的架构

SCOUT（面向通用工具的选择性上下文优化）通过按步骤动态注入工具，而不是全局暴露整个目录，来解决这些问题。

核心组件

  • 元工具接口： SCOUT向代理暴露了两个标准的MCP元工具：
  • tool_search：执行混合检索，为当前指令筛选出前 \(k\) 个（top-\(k\)）相关工具。
  • execute_tool：动态运行所选的目标工具。
  • 混合检索引擎： 结合了 BM25稀疏匹配 与 稠密向量搜索，通过 倒数排名融合（RRF） 融合结果，以保证高精度的工具发现。
  • 零停机目录更新： 由后台索引管道驱动，可持续更新工具目录，而不会中断生产网关的流量。

Architecture of SCOUT

SCOUT (Selective Context Optimization for Universal Tooling) solves these issues by dynamically injecting tools on a per-step basis rather than exposing the entire catalog globally.

Key Components

  • Meta-Tools Interface: SCOUT exposes two standard MCP meta-tools to the agent:
  • tool_search: Executes hybrid retrieval to surface the top-\(k\) relevant tools for the current instruction.
  • execute_tool: Runs the selected target tool dynamically.
  • Hybrid Retrieval Engine: Combines BM25 sparse matching with dense vector search, fusing the results via Reciprocal Rank Fusion (RRF) to guarantee high-precision tool discovery.
  • Zero-Downtime Catalog Updates: Powered by background indexing pipelines that continuously update the tool catalog without interrupting production gateway traffic.

在 PayPal 的生产环境影响

在PayPal的企业级规模下部署后，SCOUT展示了卓越的性能指标：

  • Token 消耗骤降： 将MCP工具Token的开销从 140.2k个Token（占总上下文窗口的70.1%）降低至 1.3k个Token（仅占0.8%）。
  • 效率提升： 工具Token利用率实现了 99%的削减，直接转化为更低的单次查询推理延迟和降低的运营成本。
  • 模型无关性： 由于SCOUT完全通过标准的MCP元工具运行，它无需客户端修改，并且能够在不同的LLM后端之间无缝运行。

Production Impact at PayPal

Deployed at enterprise scale within PayPal, SCOUT demonstrates exceptional performance metrics:

  • Token Consumption Drop: Reduced MCP tool-token overhead from 140.2k tokens (representing 70.1% of the total context window) down to 1.3k tokens (just 0.8%).
  • Efficiency Gains: Achieves a 99% reduction in tool-token utilization, directly translating into lower per-query inference latency and reduced operational costs.
  • Model Agnosticism: Because SCOUT operates entirely through standard MCP meta-tools, it requires no client-side modifications and functions seamlessly across different LLM backends.