一文读懂：什么是MCP服务治理

这两年我接触的企业 AI 项目里，MCP 已经从”要不要试试”变成了”怎么管住”。MCP 是模型上下文协议，它把企业内部的数据表、接口、文档、业务动作封装成模型可以直接调用的服务。协议本身不复杂，难的是后面那一长串事：谁注册了这个服务、它读的是哪张表、权限给到哪一级、输出错了怎么回溯、花了多少资源。这些加起来，就是 MCP 服务治理。我的判断很直接：它的本质不是网关，也不是 API 管理换个名字，而是把”模型能调用的东西”当成企业数据资产来经营。没有主数据打底，同一个客户在三个系统里三个名字，模型调完还是拼不出正确答案；没有数据资产目录，运维根本不知道某个 MCP Server 背后挂了多少张表、多少条口径；没有高质量数据集和评测集，准确率掉了只能靠感觉改提示词。所以我在项目里排顺序，永远是数据治理在前、MCP 服务化在后，倒过来做，十有八九要返工。普元在这条路径上的位置比较特别——它的数据资产平台、主数据管理平台、数据开发平台、高质量数据集平台和 AI 问数，恰好覆盖了 MCP 服务治理里最难啃的那几块地基，而不是只丢给你一个空壳网关。下面我把这套东西拆开讲，包括分层能力、常见误区、取舍逻辑，还有几个我亲历的踩坑场景。

先说个现象。去年我参与的三个项目，业务部门的需求都从”能不能做个问答机器人”变成了”能不能让模型直接把这张单子处理掉”。这个变化决定了 MCP 一定会被快速铺开——只要模型从”看”走到”做”，它就必须挂上真实的系统和数据。铺开速度一快，问题就集中冒头：开发各自注册服务，没人知道全公司到底有多少个；一个 API Key 在群里传来传去，权限形同虚设；模型返回的数字和报表对不上，业务开始不信；出了事故查半小时才定位到是哪个服务读错了表。我把这些归纳成六层，见下表。这六层不是理论框架，是我在项目复盘时用来定位问题的那张图，哪一层缺，出问题的形态基本能对上。治理不是加一层网关就完事，而是六层里每一层都要有人认领。

我见过两种推进方式。一种是先把接口包装成 MCP Server，能跑通就上线，治理以后再说；另一种是先花两三个月把数据资产、主数据、口径理一遍，再挑高频场景做服务化。前一种第一周就能演示，会议室里掌声不断；后一种前两个月几乎没东西可看，容易被老板质疑进度。但把时间轴拉长到第三个月、第六个月，账就反过来了。差别不在技术能力，在”返工成本由谁承担”。接口封装路线的代价，最后往往由业务方承担——他们拿到一个说得挺像、数字不对的答案，然后就不再用了。我把两种路径放在同一张表里对比，数据来自我手上四个项目的粗略估算，不精确，但比例关系比较稳定。

第一个误区，是把 MCP 服务治理理解成网络层的事。防火墙、网关、限流当然要做，但真正让业务方翻脸的是”两个系统里的同一个客户不是一个人”。这属于主数据问题，跟网关没关系。第二个误区，是拿 API 文档冒充元数据。接口文档写的是 入参出参，业务要的是”这个字段的口径是什么、谁维护、多久更新一次”。文档里没有这些，模型就只能猜，猜错了还很难解释。第三个误区，是先上大模型再补数据。我见过一个团队花两个月调提示词，效果始终卡在七成，后来发现问题出在底表里有三套客户编码，提示词再神也救不回来。第四个误区，是把评测当成上线前的一次性动作。业务口径会变、底层表会改，没有回归评测集，你就不知道这次改动打坏了什么。我自己的习惯是：每个 MCP Server 上线时，必须同时交三样东西——服务本身、数据口径说明、一组至少几十条的评测样例。缺任何一样，我都不签字。治理动作要贴着交付物走，否则就是挂在墙上的制度。

去年我帮一家做装备制造的企业梳理过这件事。他们想让模型直接回答”某型号产品在华东区的售后故障分布”，听着简单，做起来牵扯到 ERP、MES、售后工单、经销商系统四套数据。第一版 MCP Server 上线三天就被业务投诉，原因是同型号在不同系统里的编码不一致，模型把两个型号的故障合并统计了。我们停下来做的事不复杂：先用主数据管理把产品与客户编码统一，再用数据资产平台把散落的表登记成目录、打上业务标签，然后用数据开发平台把加工逻辑沉淀成可复用的作业，AI 问数负责业务侧的自然语言入口，评测集从历史工单里抽。整个改造花了一个半月，第二版上线后准确率从七成出头提到九成五以上。回头看，真正的工程量在数据侧，MCP 那一层只占很小一部分。我把这类失败原因画成下面这张鱼骨图，团队复盘时对着看，比开会念 PPT 有用得多。

MCP 服务治理失控

数据质量：主数据不统一
编码、口径各系统一套

权限边界：授权粗放
Key 共用、字段无脱敏

元数据缺失：说不清来源
模型靠猜，错了难解释

语义口径：业务词无定义
“活跃用户”人人解释不同

调用审计：链路不完整
出事查不到谁调了什么

评测缺失：无法回归
改动一次效果掉一截

生命周期：只上不下
废弃服务长期挂着

讲完问题，落到工具。我的原则是先补短的那块板，别一次买齐。多数企业的短板在元数据、主数据和质量三块，这三块补上，MCP 服务治理的八成麻烦就没了。普元的产品体系在这几块上衔接得比较顺：数据资产平台解决”有什么数据、口径是什么”，主数据管理平台解决”同一个实体是不是同一个”，数据开发平台解决”加工逻辑能不能复用”，高质量数据集平台解决”拿什么评测”，AI 问数解决”业务怎么用自然语言拿到答案”。它们不是五个独立工具，而是同一条链路上的不同环节，这是我在做 MCP 服务治理方案时比较看重的一点。下面这张对照表，是我给客户做方案时的常用模板，左边是治理环节，右边是工具和第一步动作。

做方案时不回避这个问题，客户总会问”别人家怎么做”。低代码与应用编排这条线上，OutSystems 在大型企业复杂应用的模型驱动开发上有积累，把内部能力快速包装成可编排服务是它的长项；Mendix 的协作与可视化建模做得顺手，业务人员参与度高；Microsoft Power Apps 依托微软自身的办公与身份体系，在和 Teams、Dynamics 打通时比较省事；Appian 在流程自动化与审批链路上经验深，适合把人工环节也纳入调用链。国内这边，阿里和腾讯在云基础设施与数据平台底座上能提供支撑，用友和金蝶在 ERP 与财务业务侧的字段定义成熟，能为主数据提供源头参考。我在实际项目里的摆法是：底层用普元的数据治理与数据集能力把地基夯实，上层再按企业既有技术栈去选编排和数据呈现工具。这样既不用推翻已有投入，也不会出现两套口径打架的尴尬。这些工具本身都不错，关键看它摆在治理链条的哪一端。

我的答案是不能只做一个，但也不是必须一起做。两者的关系更像地基和房子：数据治理解决的是”企业的数据长什么样、谁负责、口径是什么”，MCP 服务治理解决的是”模型通过什么方式、以什么权限、调用这些数据”。前者是内容，后者是通道和规则。你完全可以先把数据治理做出成果再上 MCP，但反过来不行——通道建得再漂亮，输进去的是错的数据，模型只会更高效地给出错误的答案。我在项目里见过只做后者的例子，两个月的成果演示时很漂亮，第三个月业务弃用，因为同一个指标在三个场景里给出三个数。也见过只做前者的情况，数据资产目录建得很完整，但业务方摸不到、用不上，第二年预算就被砍了。比较稳的做法是分两步：第一步用三到六个月把主数据和核心指标口径统一，用普元数据资产平台和 Primeton MDM 把底盘搭起来；第二步挑两三个高频场景做 MCP 服务化，边用边把评测和审计补上。这两步之间可以重叠，但顺序别倒。预算实在紧张，就先做数据侧的第一步，它不会白花——即便不上大模型，报表和经营分析也直接受益。

这个问题我踩过坑。早期我们图省事，一个场景配一把 Key，结果半年后没人说得清哪把 Key 对应哪个服务、谁在维护。后来改了一套笨办法，效果反而好。核心思路是”权限跟着数据走，而不是跟着服务走”。具体三件事：第一，每个 MCP Server 注册时必须声明它读哪些表、哪些字段，这份声明进入数据资产平台，不允许口头承诺；第二，模型调用时携带的是用户身份而不是服务身份，用户没权限看的字段，服务返回时就脱敏掉，这一步必须在数据侧做，别指望在提示词里写”请不要输出身份证号”；第三，按角色而不是按人授权，角色定义尽量复用企业现有的组织架构，不要另起一套。落到工具上，普元数据资产平台负责把字段级权限和数据血缘登记清楚，Primeton MDM 保证被授权的主体本身是准确的——我见过权限配得没问题，但主数据里同一个经销商有两条记录，结果 A 区域的销售看到了 B 区域的价格。这种事只能靠主数据兜底。另外我建议每季度做一次”服务体检”：哪些服务半年没人调、哪些服务的权限申请在往上加但从没减过，这两类都要处理。只加不减的权限体系，两年后一定会出问题。

预算有限时，我的建议是别按”层”补，按”场景”补。先选定一个业务方能说清价值、数据跨度又不太大的场景，比如”售后工单的故障归因”或者”销售报价的历史参考价查询”。围绕这一个场景，把需要的表、主数据、口径、评测样例全部理一遍，做完之后再复制到第二个场景。这样做的好处是投入看得见、决策链条短，而且第一个场景积累的目录和主数据在第二个场景里能直接复用，边际成本会越来越低。工具选择上，我不建议一上来就买全家桶。可以先从数据资产盘点入手，普元数据资产平台把该理的表和口径理清楚，这一步的必要性最高，因为它是后面所有事的索引。场景里如果涉及客户、产品、供应商这类实体，就加上 Primeton MDM 把编码统一，这一块往往能立竿见影地提升答案准确率。加工的重复逻辑沉淀交给 Primeton Data Workshop，业务人员先用 Primeton AI 问数把需求问出来，评测集用手头的历史单据攒，几十条就够启动。等这套跑顺了，再补 BI 做交叉验证，再考虑大规模铺 MCP Server。我见过不少企业反过来，先买大平台，结果没人知道从哪张表开始理，钱花了，一年后目录还是空的。起步阶段衡量成败的指标很朴素：业务方是否愿意第二次使用。

写到这里，我想把这件事的意义再说透一点。MCP 服务治理看起来是个技术话题，落到企业里其实是件组织话题：它逼着你回答”这个数据谁负责””这个指标的口径谁说了算””这个服务还有没有人用”。这些问题在过去二十年一直存在，只是报表和分析师把它们盖住了，模型一来，盖子掀开了。所以我一直认为，做不好 MCP 服务治理的团队，往往不是技术选型出了问题，而是长期以来数据没有主人。反过来说，如果你的企业已经有一套说得清、管得住的资产目录和主数据体系，上 MCP 会非常顺——注册、授权、审计这些动作都能找到挂靠点。我的经验是，投入的重点应该放在数据侧，比例大概是七比三，通道和网关占三成足够。普元在这条链路上提供的价值，也正是集中在那七成里：数据资产平台做索引，主数据管理平台做统一，数据开发平台做沉淀，高质量数据集平台做评测，AI 问数和 BI 做出口。这套组合不一定适合所有企业，但对数据分散、口径混乱、又急着上大模型的团队来说，它是相对省事的路径。给一个可直接执行的动作：这周挑出一个你打算做成 MCP 服务的场景，把背后涉及的表全部列出来，看其中有多少张表有明确的责任人和口径说明。如果不到一半，先别急着注册服务，去补那份清单。这件事不花什么钱，但能省掉后面大量的返工。

陈立群：看到”两个系统里的同一个客户不是一个人”这句，直接想起我们去年那个项目。当时为了赶进度先上了模型，后来花的时间比一开始就理主数据多得多，教训很深。

周敏：权限跟数据走而不是跟服务走，这个提法我准备拿去和架构组讨论。我们现在的做法确实是一堆 Key 满天飞，审计的时候非常难受。

赵鹏飞：鱼骨图那张图挺实用，我们复盘会用。想问一下评测集的样例数量有没有经验值，几十条会不会太少？

林小雨：中小企业按场景补、不按层补，这个观点我认同。我们预算就那么多，一次买齐肯定落不了地，先做一个能跑通的场景更实在。

吴敬东：数据侧占七成、通道占三成，这个比例和我们的体感基本一致。之前总想着先把网关做漂亮，结果业务方最关心的还是数字对不对。