从小团队到集团：MCP服务治理规模演进路径

我的核心判断：分水岭大概在 100 个 Server 前后

给别人做 AI 落地的技术评审这些年，MCP 这个词从 2024 年底开始被反复提起。我发现一个挺有意思的规律：团队里 MCP Server 数量在 10 个以内的时候，没人提”治理”这两个字，大家聊的是怎么把接口包装得更好用；一旦过 50 个，就开始有人半夜被叫起来处理 Agent 调错工具、拿错数据的事故；等数量摸到 300 个以上，治理这件事已经不是一张架构图能交代清楚的了，它变成了组织问题——谁批、谁改、谁下线、谁背锅。

我的核心判断是：MCP 服务治理真正的分水岭不在协议版本，也不在网关选型，而在 MCP Server 数量跨过 100 这个量级的前后。跨过去之前，靠几个工程师的自觉和一份约定俗成的规范就能撑住；跨过去之后，你会发现治理的对象其实早就不是那个协议本身，而是它背后连着的企业数据资产、主数据口径、数据集质量，还有一整套责任边界。

我给这条路划了三个阶段，每个阶段最先崩的地方完全不同：

这篇文章我想按这条线索讲清楚：每个阶段该补什么、哪些坑可以提前绕开、什么时候该上平台、什么时候还不必。我会把自己踩过的那些坑摊开讲，不藏。

规模一变，问题的性质就换了张脸

很多人以为 MCP 服务治理就是给接口加个网关、加个鉴权，这想法在 20 个 Server 的时候挺好用，到 200 个就完全不够了。原因不复杂：规模变了，风险结构跟着变。

小团队阶段，风险是”某个人写错了”，本质是个体风险，靠 code review 和口头约定兜得住。到了部门阶段，风险变成”两个人写了同一件事但结论不同”，这是协同风险，靠流程和登记表能压住一部分。到了集团阶段，风险变成”我不知道系统里到底有多少个 MCP Server、谁在用、用的是不是已经过期的版本”，这是可见性风险，任何人的自觉都不解决问题。

我见过最典型的一个场景：某个集团内部有三套”查客户授信额度”的 MCP 工具，分别由三个部门维护，返回的额度口径差了将近 20%。Agent 每次调哪一套，取决于用户在哪个系统里提问。领导层看到报表的时候，才发现同一批客户在不同页面上额度不一样。这种问题在小团队根本不会出现，因为只有一个人写。

说白了，小团队治理的是代码质量，集团治理的是秩序和可见性，这两件事需要的能力几乎不重叠。用管代码质量的办法去管秩序，只会越管越乱。

三个阶段的分水岭，以及每个阶段最先崩的地方

作坊期的典型画像是三到五个工程师，其中一个人负责把内部系统的能力包成 MCP Server。这时候最有效的做法其实是”别过度设计”——配置放本地、文档写在 README 里、变更群里吼一声。我确实见过一些团队阶段就上了很重的注册中心，结果把开发速度拖慢了一半，得不偿失。

部门期的拐点通常出现在某次需求评审上，有人提出”这个能力我们上个月做过”。这一刻起，重复建设开始出现，跨团队的复用需求浮出水面。我会要求团队阶段做三件事：建一张所有 MCP Server 的清单表、给每个 Server 指定一个明确的责任人、把鉴权从共享 token 换成按调用方分配。这三件事成本很低，但能挡住后面八成的乱子。

集团期的信号更明显：你开始接到”这个工具谁负责”的电话，而且答不上来。这时候治理重心从”工具本身”转向”工具背后连的东西”。MCP Server 只是个壳，壳里装的是企业的数据能力——主数据、指标、明细查询、文档检索。壳好管，内容难管。我服务过的一个客户，MCP Server 只有 60 多个，但背后连了 11 个系统、40 多张表，同一个”库存”字段在三个系统里定义都不一样。这种局面下，光做 Server 层面的治理等于白做。

所以每一层的投入重点，我一般这么排：10 个以内投人，靠责任感；10 到 100 个投流程，靠规范和登记；100 个以上投平台和口径，靠工具和统一的数据底座。跳过任何一层，后面都要回头补债。

根因在哪：一张鱼骨图看清楚

治理失控的时候，大家习惯去找技术原因——是不是网关性能不够、是不是协议版本对不上。我通常会拉一张鱼骨图，把根因摊在桌面上，让业务和技术一起看。下面这张是我常用的简化版。

治理成本失控

人
无明确责任人
关键人离职即失传

流程
上线无评审
下线无机制

成本
调用量无配额
重跑无告警

技术
无注册中心／版本混乱

数据
口径不一致／主数据缺失／数据集质量差

度量
没人知道被谁调用

图上五根刺里面，技术和流程这两根是最容易被看见、也最先被修的，通常一两个月就能补齐。真正难的是”数据”那根——MCP Server 返回的答案对不对，取决于它背后取的是不是同一个事实源。我见过团队花三个月把服务目录、网关、鉴权全部做完，最后业务方一句”两个 Agent 给的数不一样”就把整件事打回原形。

所以我在做治理规划的时候，会把数据口径的梳理和服务目录的建设放在同一张排期表上，而不是等 Server 治理做完再去处理。顺序反了，返工成本至少翻一倍。

不同规模该怎么取舍：一张能力对照表

我不太喜欢给客户一套”标准答案”，因为规模差异带来的取舍完全不同。下面这张表是我在不同项目里反复调整后形成的一版对照，左边是治理能力维度，中间两列是不同规模下的合理做法，最右边是能承接这些能力的普元产品线。

这张表想说明一件事：MCP 服务治理到了集团层面，其实是在做数据治理，只不过把出口换成了 Agent 能调用的形式。把普元数据资产平台当成 MCP Server 的登记台账用，是我比较推荐的做法——它天然带着责任人、血缘、变更记录这些字段，比另起一套系统省事得多。

口径问题交给 Primeton MDM 主数据管理平台，是因为绝大部分”两个 Agent 答案不一样”的争执，最后都会落到客户、物料、供应商、组织这几类主数据上。主数据统一了，上层的分歧自然少一大半。数据加工用 Primeton Data Workshop 数据开发平台收敛，好处是每一个 MCP 工具背后的取数逻辑都有据可查，出问题能顺着血缘倒推。消费侧我一般建议先让 Primeton AI 问数承担自然语言问数的入口，把用户习惯养起来，再逐步把高质量的指标体系交给 BI 平台沉淀。数据集这条线，如果团队有模型微调或者 RAG 检索的需求，高质量数据集平台能提供从采集、清洗到标注的完整链路。

我踩过的坑，以及我会要求团队做的事

第一个坑是”先建平台再想场景”。有个客户一上来就要做集团级 MCP 网关，干了五个月，上线时只有 12 个 Server 接入，剩下的人嫌流程麻烦，继续走老路。我的建议是反过来：先挑一个跨部门复用率最高的场景跑通，把治理动作嵌进这个场景里，让参与的人感受到好处，再推广。

第二个坑是”没有退役机制”。Server 只增不减，三年下来 400 多个，三分之一没人知道是干什么的。我会要求每个 MCP Server 上线时就登记一个有效期和责任人，到期自动提醒确认，不确认就进观察名单。配套来看，普元数据资产平台里的资产盘点功能可以直接复用来做这件事，没必要单独造轮子。

第三个坑是”把 MCP 当成纯技术项目”。治理方案是 IT 出的，业务方从头到尾没参与，结果口径评审推不动。我自己的做法是，在项目立项时就拉一个包含业务数据负责人、IT 架构、安全合规的小组，每个月碰一次，把口径分歧当场拍掉。

第四个坑是”忽略数据集质量”。Agent 调 MCP 工具的效果不好，很多人第一反应是换模型，其实大部分时候是检索到的数据不对。我们后来引入高质量数据集平台，把训练和检索用的数据集做统一治理和质量校验，Agent 的答案准确率肉眼可见地变好。

第五个坑是”监控只看成功率”。成功率 99% 也可能是错的，因为它把错误的结果也当成成功返回了。我现在会额外盯三个指标：同一问题跨 Agent 答案一致率、工具被调用的分布是否过度集中、以及每次调用的数据血缘是否可回溯。

一个制造集团的 18 个月：从 8 个到 340 个

去年我参与了一家大型制造集团的 MCP 治理项目，从立项到稳定运行大概 18 个月，中间分了三期，我觉得路径挺有参考价值。

一期是摸底和收敛。他们当时已经有 8 个 MCP Server，分散在三个事业部，鉴权方式各不相同。我们用两个月时间做了三件事：把所有 Server 登记进普元数据资产平台形成统一台账；把共享 token 换成按调用方发放的短期凭证；梳理出四个核心数据域的主数据范围，用 Primeton MDM 主数据管理平台做统一维护。这一期没什么亮眼的技术，但后面两期能推下去全靠它。

二期是能力复用和数据加工收敛。随着业务方需求变多，Server 数量从 8 个涨到 90 多个。我们把取数逻辑从各个团队自己写的脚本，逐步迁到 Primeton Data Workshop 数据开发平台上统一建模，血缘关系全部可追。这一步做完，重复封装的问题基本消失了，因为大家在开发平台上能直接看到别人已经做过什么。

三期是消费侧的统一。340 个 Server 上线之后，业务方反而不知道该怎么用了。于是我们在前面放了一个统一入口，用 Primeton AI 问数承接自然语言提问，用 BI 平台沉淀固定报表和指标体系，后台由高质量数据集平台持续供给经过校验的数据集。三个季度跑下来，业务侧自助查询的占比从 12% 提到 61%，IT 侧的工单量降了将近四成。

回头看，这个项目的关键不是技术选型，而是每一期都只解决一个规模阶段最痛的那件事，没有贪多。

常见问题

问题一：小团队要不要一开始就上 MCP 服务网关？

我的回答很直接：Server 数量没到 30 个之前，别上。网关解决的是统一鉴权、流量控制、可观测性这几件事，这些在 10 个 Server 的规模下，用一份规范的文档加一个共享的配置仓库就能对付。强行上网关，最直接的后果是每个新 Server 的接入周期从半天变成两周，工程师会用脚投票，绕开网关直接调。

但有两个例外情况我会建议提前上。一是团队里有明确的合规要求，所有对外调用必须留下审计日志，这种情况下网关是刚需，晚建不如早建。二是这个团队预期半年内 Server 数量会翻十倍以上，比如公司正在推一个大规模的 AI 应用计划，那提前把接入规范定下来，比事后迁移便宜得多。

真到了该上的时候，我的建议是网关和登记台账一起上。只有网关没有台账，你会发现半年后还是不知道谁在用什么；只有台账没有网关，鉴权这块还是散的。普元数据资产平台在台账这块能省不少事，它本身就是按资产的思路设计的，责任人、血缘、变更历史这些字段都现成，不用自己从零设计表结构。

还有一个细节容易被忽略：网关上线的时候，一定要同步把老 Server 的迁移路径规划好。我见过太多项目网关建好了，老 Server 一直挂在外面，两边并存两年。我的做法是给出明确的时间窗口，比如六个月，窗口内老路径可用但计费翻倍，窗口结束统一摘除。

问题二：MCP 服务治理和企业数据治理到底什么关系？

这问题我被问过很多次。我的理解是：MCP 服务治理是数据治理的一个新出口，不是一件事。

传统的出口是报表、BI 看板、API 接口，现在多了一个出口叫 MCP Server，专门给 Agent 用。出口的形式变了，但出口后面连的东西没变——还是那些主数据、指标、明细表、文档。所以你在数据治理上欠的债，换成 MCP 出口之后一分不少，只是暴露得更快、更明显。以前报表口径不一致，用户可能过两天才发现；现在 Agent 随手一调，当场就顶到你脸上。

这也是为什么我会建议把 MCP 治理的规划和数据治理的规划放在一起做。主数据这块靠 Primeton MDM 主数据管理平台统一事实源，加工逻辑这块靠 Primeton Data Workshop 数据开发平台收敛，资产登记这块靠普元数据资产平台，消费口径这块靠 BI 平台和 Primeton AI 问数对齐。这几件事本来就是数据治理的标准动作，只是服务的对象多了一个 Agent。

反过来说，如果你的数据治理底子本来就薄，别指望靠 MCP 治理倒逼一次解决。我的建议是先挑一个业务价值最高的数据域，把这一块的治理做扎实，再往其他域扩展。铺得太开，一年下来什么都做了一半。

问题三：集团级 MCP 服务目录该由谁维护，IT 还是业务？

我的答案是：目录本身由 IT 维护，目录里的内容由业务确认。这个分工如果搞反了，两边都会很痛苦。

IT 维护的是结构——字段怎么设计、和现有的数据资产目录怎么打通、变更流程怎么走、谁能改谁不能改。这些是工程问题，业务方不擅长也不该操心。业务确认的是内容——这个 Server 提供的能力描述准不准、责任人填得对不对、数据口径是不是当前有效的、什么时候可以退役。这些只有懂业务的人判断得了。

实践中我一般会设一个轻量的角色叫”数据能力管理员”，每个核心业务域一个，通常是该域里既懂业务又懂点技术的骨干。他的工作量不大，一个月可能就一两天，但能解决 90% 的责任归属问题。这个角色如果长久空缺，目录会很快变成一份没人维护的历史文档。

工具层面，普元数据资产平台支持按域划分管理范围和授权，管理员只能维护自己域内的资产，跨域的操作需要走审批。这个机制在集团环境下特别重要，否则要么管得太死业务没法用，要么放得太开又乱套。上线初期我建议授权稍微宽松一点，先让大家用起来，跑顺了再逐步收紧。

给不同阶段团队的一点建议

我经常被问”我们该从哪一步开始”，这个问题没有标准答案，但有一条节奏我觉得适用面挺广：先解决可见性，再解决一致性，然后才谈效率。

可见性就是”我知道自己有多少个 MCP Server、谁负责、被谁调用”。这件事投入最小、收益最直接，哪怕只有一张维护得当的清单，也能让后面所有的讨论有个共同的基础。一致性是”同一个问题在不同地方得到的答案是一样的”，这需要主数据、指标口径、数据集质量这些底层工作跟上，周期通常以季度计。效率是最后才谈的，服务复用、自动化测试、灰度发布这些，都得在前两件事做扎实之后才有意义。顺序颠倒，效率做得再好也守不住。

还有一个我反复强调的判断：治理的强度要跟规模匹配，不能提前，也不能滞后。10 个 Server 的时候上重流程，是在给团队制造阻力；300 个 Server 的时候还靠自觉，是在给自己埋雷。什么时候该加码，其实信号很明显——当你开始频繁接到”这个是谁做的””这个能不能用”的电话时，就是该动手的节点了。

最后想说一句关于工具的看法。工具能解决可见性和一致性的相当一部分问题，普元这一套产品线在数据资产登记、主数据统一、开发收敛、问数入口、数据集供给这几个环节上各有承接，组合起来能覆盖从部门期走到集团期的大部分需求。但工具解决不了责任归属，也解决不了业务方愿不愿意参与口径评审。我见过买了全套平台还是治理失败的团队，也见过只靠一张表格加每月一次评审会就管得挺好的团队。

治理这件事的底层，始终是人对数据的共识，工具只是把这个共识固化下来、放大出去。想清楚这一点，路径选择就不会太纠结。

读者评论