[控场AI]
· 4 分钟阅读· 2,342 字

大规模治理MCP服务器:Postman Fabric Gateway如何破解控制难题

大规模治理MCP服务器:Postman Fabric Gateway如何破解控制难题

Postman Fabric Gateway通过统一网关与渐进式工具披露,解决AI智能体接入大规模MCP服务器时的治理失控问题。

当AI智能体需要同时连接20个MCP服务器、调用600个工具时,工具发现、访问控制和可观测性三大治理难题会同步恶化。Postman推出的Fabric Gateway采用两层解法:一是在MCP客户端与服务器之间插入Agent Gateway,将身份识别、策略执行、请求路由和遥测捕获收敛到单一治理点;二是引入渐进式工具披露机制,只向智能体暴露search、get、execute三个元工具,让模型按需定位和加载工具Schema,而非一次性将600个定义塞入上下文窗口。后端服务器与工具总量不变,但智能体的视野被有意收窄,安全执行点唯一,请求路径全程可追溯。这一设计的核心价值不在于赋予智能体更多能力,而在于让团队重新掌握对工具发现与使用方式的控制权。

当一个AI智能体需要连接20个MCP服务器、调用600个工具时,开发者面对的早已不是集成问题,而是一个控制问题。这种规模下的治理挑战,正是Postman推出Fabric Gateway试图解决的核心痛点。

从一个MCP服务器到二十个:复杂度的质变

单个MCP(Model Context Protocol)服务器的场景非常简单:智能体连接、认证、看到一小组工具,然后发起调用。整条从请求到响应的路径都清晰可追溯,排查问题毫无压力。

但当规模扩大到20个MCP服务器、每个服务器带30个工具时,情况迅速恶化。每一个连接都意味着一份新的凭证、一个新的策略面、一条新的日志流,以及更多需要模型纳入考量的工具Schema。

凭证、策略面与日志流的膨胀

这种膨胀直接让三件事变得困难:找到正确的工具、判断智能体是否被允许使用该工具、以及在调用之后重建事件全貌。工具发现、访问控制和可观测性,三者同时失守。

MCP(Model Context Protocol)是由Anthropic于2024年底提出的开放协议标准,旨在为AI智能体与外部工具、数据源之间的交互建立统一接口。其设计逻辑类似于USB-C:无论底层服务是数据库、代码执行环境还是第三方API,智能体都通过同一套协议发现和调用工具,而无需为每个集成单独开发适配层。MCP服务器本质上是一个轻量级的工具宿主进程,负责声明可用工具的Schema(包括名称、参数类型和描述),并在智能体发起调用时执行对应逻辑。MCP客户端则通常嵌入在AI智能体或推理框架中,负责解析Schema、生成调用请求并处理返回结果。这套协议的普及正是大规模工具接入成为现实问题的技术背景——当越来越多的服务以MCP服务器的形式暴露能力时,智能体端的治理负担也随之线性增长。

Agent Gateway:统一的治理入口

解决思路是在MCP客户端与服务器之间插入一个Agent Gateway(智能体网关)。客户端不再直接面对散落的服务器,而是连接到单一的治理点。

这个网关承担四项职责:识别调用方身份、应用策略、路由请求、并在同一处捕获遥测数据。所有的安全执行和日志记录都收敛到一个地方,而非分散在20个连接上。

网关识别调用方、应用策略并捕获遥测

这意味着安全团队只需要维护一个执行点,而每一次请求都拥有一条可追溯的完整路径。原本碎片化的治理面被压缩成了单一的可管理层。

渐进式工具披露:解决600个Schema的上下文竞争

仅靠一个连接并不能解决600个工具定义同时争夺模型上下文窗口的问题。如果把所有Schema一次性暴露给智能体,模型反而会被淹没在选择中。

Fabric Gateway采用的方案是渐进式工具披露(Progressive Tool Disclosure)。客户端起步时只看到一个极小的接口,仅包含三个工具:

  • search:让智能体通过语义搜索找到服务器上相关的工具;
  • get:返回智能体所选工具的Schema;
  • execute:发起真正的调用。

仅暴露search、get、execute三个工具的精简接口

智能体通过search语义化地定位需要的工具,用get获取其详细定义,最后用execute执行。网关负责把这个调用映射到正确的MCP服务器上。

不变的后端,收窄的视野

关键在于:后端仍然是同样的20个服务器、同样的600个工具,但智能体此刻只看到它当下真正需要的那部分。

同样的20个服务器与600个工具,但智能体只看到所需

这种设计带来三重收益:模型的上下文不再被海量Schema挤占,安全有了单一执行点,每一次请求都有一条可追踪的路径。

上下文窗口(Context Window)是大语言模型在单次推理中能够处理的最大token数量,是当前AI智能体架构中最核心的稀缺资源之一。工具的Schema定义——包括工具名称、功能描述、参数名称与类型说明——全部需要占用这一有限空间。以GPT-4o或Claude 3.5 Sonnet为例,一个描述详尽的工具Schema通常消耗200至500个token,600个工具的完整Schema集合可能高达10万至30万token,这不仅会逼近甚至超出主流模型的上下文上限,还会显著干扰模型的工具选择精度——大量无关工具的存在会造成注意力稀释,导致模型更容易选错工具或产生幻觉式调用。渐进式披露本质上是一种按需加载策略,与前端开发中的懒加载(Lazy Loading)原理相通:只在模型真正需要时才将具体Schema注入上下文,从而将工具选择的认知成本分摊到多轮交互中,而非在对话开始时一次性堆积。

控制,而非更多工具

值得厘清的是,Agent Gateway并没有给智能体更多工具,它给的是对这些工具的控制权——包括工具如何被发现、如何被使用。

随着AI智能体接入的工具生态持续膨胀,工具发现、访问控制与可观测性这三大难题会越来越凸显。对于正在构建多MCP服务器架构的团队而言,一个统一的治理网关层或许正在从"可选项"变成"必需品"。Postman将这类能力整合进了Fabric Gateway,试图在智能体规模化的浪潮中补上治理这块短板。

分享:

相关推荐