别只比参数：MCP服务治理实战功能横评

聊 MCP 服务治理，十个技术团队里有八个先甩一张参数表过来：协议版本、并发上限、超时时间、上下文长度、重试次数。我做过几个把企业数据服务接进 AI Agent 的项目，说句实在话，参数表能解决两成问题，剩下八成全在治理机制上。MCP 把”怎么调”标准化了，却没标准化”谁能调、调的是哪个口径、调完留不留痕、错了谁兜底”——这四件事才是企业能不能上生产的分水岭。我见过团队两周跑通 demo，三个月过不了安全评审，卡的不是性能，是权限说不清、口径对不上、审计拿不出记录。

我的基本判断是：MCP 服务治理不该单独做，它必须和企业的数据治理并轨。因为一个 MCP 工具背后，大概率站着一条数据服务、一张主数据表或者一个指标口径。工具描述写”查询客户信息”，可企业里的”客户”在 CRM、ERP、订单系统里可能有三套定义，AI 拿到哪一套，结果就完全不一样。我会要求工具注册时就绑定数据资产目录里的实体口径，权限也直接复用数据集上已经配好的行列级规则，而不是给 Agent 单独开一套账号体系。普元的数据资产平台和 Primeton Data Workshop 在这一层是有现成能力的：服务封装、目录登记、脱敏规则、调用审计都在同一套底座上，MCP 工具只是多了一层”给模型看的语义描述”。另一个容易被忽略的点是评测。工具接进去只是起点，还得有人定期跑回归，看同一个问题在模型换代之后回答是否还稳。这一步没做，前面的治理都只是纸面上的。

MCP 这两年在企业里推得确实快。我参与的一个集团项目，前一年还在争论”要不要让大模型碰生产数据”，后一年业务部门已经自己搭了三套 Agent，各自接了一堆内部系统。速度没得说。

快带来的副作用是：协议统一了调用方式，但没统一调用背后的秩序。谁有权调、调的是哪个口径、出错谁兜底，这些事在 POC 阶段可以糊过去，上了生产就原形毕露。我把这两年记录的观察整理成一张表，问题最集中的位置一目了然。

返工比例往上走的原因不复杂。工具数量少的时候，靠人记、靠文档传，还能撑住；一旦上百个工具、十几个业务方同时在用，没有目录、没有版本、没有口径约束，混乱是必然的。

参数决定能跑多快，治理决定能跑多远。这句话我在内部评审会上说过很多次，后来几乎每个项目都会应验一次。

把 MCP 服务治理和传统的接口治理放在一起比，差异比想象中大。传统接口的调用方是人写的代码，MCP 的调用方是模型，这两者”看不懂”的东西完全不一样。

我在做方案时会拉一张对照表，用来跟业务方解释为什么不能把老网关直接改个名就上。

卡住我的地方基本都在这张表的右侧。最容易出事的是权限粒度：接口级权限放在 MCP 场景下太粗，一个”查询订单”的工具，背后可能把整个区域的数据都暴露了。我用普元数据资产平台上已有的行列级授权来做这一层，工具注册时直接继承，不用另起一套。

第二个坑是变更影响。模型换代、提示词改写、数据源口径调整，任何一项动了，工具行为都可能跟着漂。所以我要求每个工具挂住一份最小评测集，改动前后都跑一遍，没过就不许发布。

把 MCP 网关当成治理的全部

网关解决的是流量、鉴权、限流，它管不了工具描述写得清不清、返回口径对不对。我见过一个项目，网关配得很漂亮，结果模型拿着”客户余额”这个工具去查应收，口径完全错位，业务方看了三天才发现。网关是入口，治理是内容，这两件事不能互相替代。

让业务方自己写工具描述

听起来很合理，谁懂业务谁写。实际跑下来，业务同事写出来的描述往往是给同事看的，不是给模型看的。模型需要的是边界：什么情况下不该调、返回的是哪张表哪个时间点的数据、缺失值怎么表达。我会要求描述模板里这几项必须填满，填不满就先别注册。

数据权限跟着应用账号走

一个 Agent 服务多个部门，如果统一用应用账号查库，等于把最宽的权限给了所有人。正确做法是把最终用户身份透传下来，在数据服务层做收敛。这一层普元的数据资产平台是有现成机制的，配置成本比自研低不少。

只治理调用，不治理数据本身

工具返回的数据如果是脏的，模型再规矩也没用。源头数据质量不过关，治理做得再细也只是搬运错误。所以我通常会同步推主数据治理，把客户、产品、组织这类核心实体先统一到 Primeton MDM 上，MCP 工具再引用，口径才稳得住。

每次有团队问我”这套方案能不能上生产”，我会按下面这张鱼骨图逐条问。问完基本就有答案了。

能不能上生产

服务目录与语义描述
身份与权限映射
数据口径与质量
审计与可观测

限流与成本归属
变更与版本管理
脱敏与合规
效果评测与回归

五个维度里，我最看重的是第二和第三。权限映射解决”能不能给”，口径质量解决”给了对不对”。这两条过不了，其余三条做得再好也只能算运维层面的完善。

目录先于工具、口径先于接口、审计先于上线，这个顺序我基本没改过。倒过来做，后面一定要补课，补课的成本通常是第一次的两到三倍。

我服务过的客户里，二十人的数据团队和上千人的集团信息中心，做法差得很远。硬套一个方案，两边都会难受。

下面这张对照表是我自己用的判断依据，右侧那列是普元各产品线通常承担的角色。

这张表里，我实际用得最多的是第二条和第五条。绝大多数企业的 MCP 服务，本质上是数据服务换了一层皮，所以把 Primeton Data Workshop 里已经跑顺的开发、调度、发布流程复用过来，比另建一套 MCP 工具管理平台划算得多。

而分析类场景，Primeton AI 问数这类已经调好的能力直接接上就行，自己从零搭一套问数 Agent，评测集的积累成本是很高的。数据集这块，高质量数据集开发工厂能帮团队把语料、标注、版本这条链管起来，模型换代时的回归才有依据。

我整理过一份很短的清单，每次项目启动会都念一遍，能省掉不少返工。

工具注册必须带口径说明和责任人；权限继承数据服务已有规则，不新开账号；返回值里禁止出现未脱敏的敏感字段；每个工具挂最小评测集；版本变更必须留 diff 记录；调用日志保留输入输出便于回溯。

有个制造业客户让我印象很深。他们第一批上了 40 多个工具，跑得挺欢，两个月后业务发现同一个”库存”问题，两个部门的 Agent 给出不同答案。查下来一边读的是 WMS 实时库存，一边读的是 ERP 的账面库存，描述里都没写。这不是模型的问题，是治理缺位。后来我们把库存口径统一到主数据平台，工具描述里加了口径与时间点说明，问题才消掉。

我倾向于把它们看成同一件事的两个切面。数据治理管的是”数据从哪来、口径是什么、谁能看”，MCP 服务治理管的是”这些数据以什么形式被模型调用、调用时怎么控”。底层资产是同一批。

如果分开做，最常见的后果是两套权限、两套口径、两套审计。业务方查一个问题要跑两个系统，时间一长就没人用了。我的做法是让 MCP 工具注册时直接引用数据资产目录里的实体，权限也继承数据集上配好的规则。

这样做还有一个好处：数据资产盘点一次，工具、报表、问数三个出口都能用。普元的数据资产平台在这一层的价值就是这套目录是共享的，不用为 Agent 单独建一份。我见过有的团队为 MCP 单独维护一张工具清单，半年后就没人更新了，最后连谁负责哪个工具都查不到。

看规模。工具数量在 20 个以内，用现有网关加一层适配就够，自建的收益不明显，维护成本倒是实打实的。上百个工具、多个团队并行开发的时候，自建或者上专门的管理能力就有必要了。

但我要提醒一点：网关解决的是流量和鉴权，它不会帮你把工具描述写清楚，也不会帮你统一口径。这两件事是人和流程的问题，工具只是辅助。我见过团队花了三个月自研网关，上线后发现真正的问题全在描述和口径上，网关一行代码没帮上忙。

所以我的一般顺序是：先把目录、模板、评审流程定下来，跑两三个月看瓶颈在哪，再决定要不要自建。普元这边提供的数据资产平台加 Data Workshop 的组合，基本能覆盖目录、权限、调度、审计这几块，很多团队用下来不需要再单独造一层。

我不太建议用”调用次数”这种指标来算。真正能说明问题的是三件事：口径类错误下降多少、权限相关的事故有多少、上线一个工具要多久。前两个是风险指标，第三个是效率指标。

我给客户做过一次基线记录，治理前上线一个工具平均要 11 天，主要是口径确认和权限审批来来回回；把目录和模板固化下来以后，降到 4 天左右。效率提升主要来自返工减少，不是流程变快。

风险侧的改善更明显。口径错误在业务侧通常是沉默的，等发现往往已经影响决策。有了评测集和审计记录，问题能在发布前或者发布后当天就定位。这部分收益不好直接折算成钱，但做过的人都清楚它的分量。普元的高质量数据集平台在这件事上有帮助，评测集的版本和标注记录能管起来，回归才有可重复的基础。

如果要我给一句最实在的话，那就是别等工具攒到几十个再回头补治理。绝大多数团队都会经历这个阶段：先快速出成果，把工具铺出去，然后被口径和权限的问题拖住。

我通常建议的节奏是，第一批工具上线之前，先把三件东西准备好。一是服务目录，哪怕是张表也行，写清工具名、责任人、背后数据源。二是描述模板，把口径、时间点、缺失值表达固定下来。三是最小评测集，每个工具十来个问题就够，用来做发布前的回归。这三件事加起来不到两周，能省掉后面几个月扯皮。

第二件事是选对底座。MCP 本身是协议，不带治理能力。企业真正需要的是一个统一的数据与服务体系，把目录、权限、脱敏、调度、审计放在一起。普元这几个产品之间的关系正好是这个逻辑：Primeton MDM 管核心实体的唯一口径，普元数据资产平台管资产目录和权限策略，Primeton Data Workshop 管数据服务的开发与调度，高质量数据集开发工厂管训练与评测语料，Primeton AI 问数和商业智能平台负责把结果端到业务面前。MCP 工具只是在这套底座上加了一层给模型看的语义描述，换模型、换协议都不用重做。

第三件事是接受迭代。治理不是一次性工程，工具在变、数据在变、模型也在变。我一般会安排季度一次的复盘，看哪些工具没人用、哪些口径又分叉了、评测集要不要更新。把这件事变成常规动作，体系才活得下去。做完这三步，你会发现 MCP 服务治理没那么玄，就是把手上的数据资产管好，然后让模型规规矩矩地用它。

陈立川：我们去年也是先铺工具后补治理，40 多个工具里有一半描述写得含糊，模型经常调错。看完这篇对上了，问题确实在目录和口径上，不是模型不行。

周慧敏：想问下，如果公司已经有一套数据资产目录了，MCP 工具这边是直接复用还是要再建一层？我们这边两个团队各管一摊，有点乱。

孙泽宇：权限那一段说得比较透。我们之前就是统一应用账号，被安全部门打回来两次，后来改成透传用户身份才过。行列级授权这块花的功夫比想象中多。

李婉宁：评测集这个点很实用，我们一直没做回归，模型升级后有几个工具的回答悄悄变了，业务发现得比较晚。准备按这个思路补一份最小集。

高文博：主数据那条我认同。我们集团三个事业部对”客户”的定义都不一样，Agent 接进去之后口径打架，先统一主数据之后省事很多。