MuleSoft治理Agent泛滥：一键识别重复API、MCP服务器与智能体

当“注册中心”解决不了Agent泛滥问题

随着企业在API、MCP服务器和AI智能体上的投入快速增长，一个被忽视的问题正浮出水面：资产泛滥（Asset Sprawl）。KPMG的技术负责人Fasir在一次交流中点出了关键痛点——“所有人都把注册中心当成Agent泛滥的解药，但没人提供一个真正能找出泛滥的方法。”

他的诉求简单直接：给我一个按钮，能告诉我哪些资产是独一无二的，哪些是冗余的，哪些处于灰色地带。这个需求之所以重要，是因为每一个重复的资产都会让企业付出两次成本——一次是构建它，另一次是持续运行和保护它。

基于这个洞察，本文介绍的方案围绕MuleSoft Anypoint平台构建，目标就是把“泛滥”这件事可视化、可操作化。

按“含义”而非“措辞”比对资产

传统的资产盘点往往依赖命名和文本匹配，这在实际环境中极易失效：两个功能完全相同的API，可能因为命名习惯不同而被当成两个独立资产。

该方案的核心区别在于——它按能力的语义含义进行比对，而不是单纯比对字符串。系统会读取Anypoint Exchange中的每一个资产，解析出它的全部能力：每一个API操作、每一个MCP工具、每一个智能体技能，然后在语义层面做对比。对于难以判定的灰色地带案例，则交由一个充当“裁判”的AI模型来裁定。

裁判模型可以灵活选择：Flash作为快速默认选项，而Pro则是推理能力更强的模型，用于处理需要深度判断的边界情况。

三步工作流：扫描、资产、泛滥

整个方案分为三个清晰的步骤：扫描（Scan）、资产清单（Assets）、泛滥分析（Sprawl）。

一切从扫描Exchange开始。用户可以自由选择纳入范围——REST API、MCP服务器、智能体。一个值得关注的工程细节是：很多MCP服务器在发布时并未附带工具清单（tool list）。遇到这种情况，扫描器会直接连接到运行中的服务器，实时获取它实际暴露的工具。扫描在后台运行，不需要用户干等，完整扫描通常需要几分钟。

扫描完成后得到的是一份完整清单，覆盖目录中的每一个资产。清单中的“能力数”表示一个资产能做多少件不同的事；“来源”则标明这些能力的出处——是来自API规范、MCP元数据，还是从运行中的服务器直接读取。

**MCP（Model Context Protocol）**是Anthropic于2024年底推出的开放协议，旨在标准化AI模型与外部工具、数据源之间的交互方式。MCP服务器本质上是一个工具宿主，向AI客户端暴露一组可调用的"工具（Tool）"，每个工具附带名称、描述和输入参数Schema。由于MCP协议本身对"发布时是否必须携带工具清单"没有强制约束，现实中许多MCP服务器在API目录里只有基本元信息，实际暴露的工具只有在运行时才能通过协议握手获取。这正是文中扫描器需要"直连运行中服务器"来实时拉取工具列表的原因，也是MCP资产治理比传统REST API治理更复杂的地方之一。

四种状态：读懂每一个资产的处境

每个资产会被标记为几种状态之一，这正是方案价值的集中体现：

冗余（Redundant）：例如某个API同时负责“提交人寿保险申请”和“查询状态”，被标记为冗余，因为目录中另一个“新业务提交API”做的是完全相同的两件事——2/2、100%覆盖，这就是潜在的泛滥。

独特（Unique）：某些SAP或MCP服务器恰好只暴露底层系统API的三个操作，这类资产是独一无二的。

门面（Facade）：当团队有意为某个API启用MCP能力时，扫描器能识别出这种模式并标记为“facade”，避免误判为重复。同样的逻辑也适用于调用自身MCP工具的智能体。

灰色地带与缺口（Gaps）：那些发布时没有工具清单或规范的资产，扫描器缺乏足够细节判断其唯一性，这些正是需要优先清理的候选对象。

"门面"（Facade）模式在微服务和API架构中是一种常见的合理设计——团队有意在同一套底层能力之上构建不同的接口层，例如为AI模型调用提供MCP封装、同时保留原始REST API供传统系统使用。如果不加以识别，泛滥检测器会将这类"一体两面"的资产错误标记为冗余，导致团队误删有价值的接口。通过识别Facade模式并单独标记，系统能区分"无意复制出的重复资产"与"有意设计的多态接口"，避免治理行动反而破坏既有架构。

从全局视角看泛滥：搜索、建议与热力图

当把所有资产放在一起看，泛滥才真正显现。在示例中，系统分析后发现85个冗余资产、72个独特资产、59个灰色地带，外加若干未文档化资产。

方案提供了几个实用的治理工具：

构建前搜索：在动手开发任何新功能前，团队应先搜索目录。比如搜索“创建支持工单”相关能力，如果能找到提供同类能力的现有API、MCP服务器或智能体，就应该复用而非重建。这是每个团队都该养成的习惯。

清理建议：系统会生成一份类似待办清单的推荐。例如发现四个MCP服务器暴露相同能力，建议就是“整合为一个”。

重叠热力图：热力图直观展示哪些资产相互重叠——颜色越深，两个资产做的事越相同。深色方块就是优先排查的对象。带星标的资产是推荐标准化保留的那一个，其余则建议退役。

灰色地带裁定：对于相似但未必相同的能力，由AI模型阅读描述并给出判断与理由。例如两个都处理“预订”的接口，可能因为分别对应完全不同的业务对象（高尔夫球场 vs 餐厅）而被判定为不同资产。

结语：一个按钮背后的治理价值

这套方案最终回应了Fasir最初的诉求——用一个按钮，就能看清企业在API、MCP服务器和智能体层面哪些是独特的、哪些是冗余的。在AI智能体和MCP生态快速扩张的当下，资产泛滥治理不再是可选项，而是控制成本、降低安全风险的必要能力。语义级比对加上AI裁判的组合，为企业提供了一条从“盘点”走向“治理”的可行路径。

背景补充

语义比对依赖的底层技术是向量嵌入（Vector Embedding）：系统将每个API操作或MCP工具的描述文本转化为高维数值向量，语义相近的内容在向量空间中距离更近。传统字符串匹配只能捕捉表面措辞的相似性，而向量相似度计算（如余弦相似度）可以识别"创建工单"与"新建服务请求"这类表达不同但含义等价的情况。当相似度得分落在高度相似与明显不同之间的模糊区间时，单纯依赖阈值截断容易产生误判，这正是引入大语言模型担任"裁判"的原因——它能结合业务上下文进行更细粒度的语义推理，而不是机械地比较数字。