MCP 中台 Tool 数量治理成熟架构方案

一、问题背景

随着 MCP 中台接入的第三方 MCP Server 越来越多，Tool 数量会快速增长。

如果把所有 Tool 一次性暴露给 Agent，会导致：

• Tool Schema 占用大量 Context
• Agent 可选择的 Tool 数量过多
• 相似 Tool 容易产生选择错误
• 不同业务的 Tool 权限边界不清晰
• Tool 长期增长后出现重复、能力重叠

因此可以从运行时治理 + 离线治理两个方向解决。

---

二、整体架构

                         用户任务 / Agent 查询
                                   │
                    ┌──────────────┴──────────────┐
                    │                             │
              自研 Agent                    Cursor / Codex
              Tool Router                   search_tools
                    │                             │
                    └──────────────┬──────────────┘
                                   ↓
                          MCP 中台运行时
                                   │
                          ① Server 业务域隔离
                                   │
                          ② Scope 权限隔离
                                   │
                          ③ Tool Discovery
                                   │
                     第三方 MCP / Tool Registry ····· ④ 离线治理
                                   │                    │
                          Tool Call / 结果       定时 → 相似 → Judge → 人工

图 1. MCP 中台 Tool 数量治理流程（主链漏斗，不是双列）。实线是 tools/list / tools/call 热路径；虚线从 Registry 旁出，定时治理，不是调用的下一步。①②③ 串行缩小候选，④ 防止 Registry 膨胀。

---

三、四层治理体系

① Server：按业务域隔离

按照业务能力将 Tool 划分到不同 MCP Server。

MCP Platform
├── Feishu Server
│   ├── read_doc
│   ├── write_doc
│   └── comment_doc
│
├── Order Server
│   ├── query_order
│   ├── create_order
│   └── cancel_order
│
└── GitHub Server
    ├── read_repo
    ├── create_issue
    └── create_pr

物理上不需要部署多个 Service，可以：

一个 Spring Boot Service
        ↓
多个逻辑 MCP Server / Endpoint

例如：

/mcp/feishu
/mcp/order
/mcp/github

Server 层主要解决：

业务域隔离 + 第一层减少 Tool 数量。

---

② Scope：权限与访问隔离

通过 Token / Scope 控制 Agent 可以访问哪些业务和 Tool。

例如：

Token A
scope = feishu:read

Token B
scope = order:write

请求流程：

Agent
 ↓
Token
 ↓
Scope / Permission
 ↓
允许访问的 Server / Tool

这一层使用确定性规则，不需要 LLM。

主要解决：

身份认证、权限控制、租户隔离以及 Tool 访问范围。

因此：

Server → 业务隔离
Scope  → 权限隔离

两者可以叠加使用。

---

③ Tool Discovery：动态检索与选择

如果一个业务域里面仍然有大量 Tool，例如：

Feishu Server
    ↓
300 Tools

这时候使用 Tool Discovery / Tool Retrieval。

自研 Agent

因为可以控制 Agent Runtime，所以可以直接：

User Query
    ↓
Tool Router
    ↓
权限 / Metadata Filter
    ↓
BM25 + Vector Retrieval
    ↓
Top-K
    ↓
Reranker
    ↓
Top-N
    ↓
LLM
    ↓
Tool Call

Cursor / Codex

无法控制其内部 Tool Selection，因此 MCP 中台提供：

search_tools(query)

Agent：

Cursor / Codex
       ↓
 search_tools
       ↓
MCP Platform
       ↓
权限过滤
       ↓
BM25 + Vector
       ↓
Reranker
       ↓
返回少量 Tool
       ↓
Agent 最终选择
       ↓
动态获取 Schema
       ↓
Tool Call

也就是渐进式披露 / Dynamic Tool Discovery。

这一层主要解决：

当 Tool 仍然很多时，动态找到当前任务最相关的 Tool。

---

④ Tool Governance：离线 Tool 治理

随着 Tool 长期增长，可能出现大量重复或相似能力。

例如：

Tool A：查询飞书文档
Tool B：读取飞书文档
Tool C：获取飞书文档内容

可以通过定时任务进行治理：

Tool Registry
      ↓
定时 Governance Job
      ↓
Embedding / Similarity Search
      ↓
发现高相似 Tool
      ↓
LLM Judge
      ↓
重复 / 相似 / 不重复
      ↓
治理建议
      ↓
人工审核 / 灰度

这里不能简单地让 Agent 自动删除或合并，因为：

语义相似不代表功能完全相同。

所以更合理的方式是：

相似度召回 + LLM 语义判断 + 人工审核。

这一层解决：

Tool Registry 长期增长后的重复、膨胀和能力重叠问题。

---

四、最终总结

MCP 中台解决 Tool 过多问题，可以形成四层治理体系：

层级	核心方案	解决的问题
Server	按业务域拆分	业务范围隔离
Scope	Token / Permission	访问权限隔离
Discovery	BM25 + Vector + Reranker	运行时 Tool 选择
Governance	Similarity + LLM Judge	离线 Tool 去重治理

其中：

Server + Scope 是“先缩小 Tool 范围”，Tool Discovery 是“从剩余 Tool 中找最相关的”，Tool Governance 是“防止 Tool Registry 长期失控”。

对于不同 Agent：

自研 Agent
→ Routing / Retrieval 放 Agent Runtime

Cursor / Codex
→ 无法控制内部 Selection
→ MCP 中台提供 Tool Search / Dynamic Discovery
→ 通过渐进式披露间接控制 Tool 暴露范围

最终 MCP 中台的定位不再只是：

MCP Proxy / 第三方 MCP 统一接入层

而是：

MCP Server 接入 + Tool Registry + 权限治理 + Tool Discovery + Tool Lifecycle Governance 的统一 Tool Middle Platform。