别人的学费别白交：MCP服务治理复盘集

MCP 服务治理做不好，八成不是模型的问题，是数据和权限的问题。我这两年接手和旁听的 MCP 项目，少说也有十几个。演示阶段都很顺，一旦进生产，投诉就来了：同一句”上月华东区销售额”，销售助手和财务助手给出两个数；某个能查薪资明细的工具被挂到了全员可用的入口；工具升级之后没人知道旧版本的调用方是谁。这些事跟模型能力没半点关系，全是治理欠账。我一直认为，MCP 的价值上限取决于底座有多硬，而不是你接了多少个工具。工具是手，数据是脑，治理是神经。只装手不装神经，前期演示漂亮，三个月后全是技术债。我踩过最大的一个坑是早期带着团队一口气接了二十多个 MCP Server，每个 Server 背后连的是各自部门的宽表，字段名不一样，口径也不一样，模型再聪明也只能照着错的数据念。后来我们把顺序倒过来：先把主数据、指标口径、权限体系理清楚，工具反而接得更快。普元在这条路上的思路和我是合的——先盘清数据资产，再谈智能应用，这个先后关系不能反。下面我把这几年交出去的学费，一条条摊开讲。

MCP 让工具调用标准化，这件事的价值我认可。以前每接一个大模型应用就得单独写一遍数据接口，重复劳动特别多；有了 MCP，工具写好一次，多个模型、多个入口都能用。但标准化解决的是”怎么连”，解决不了”连上之后谁负责”。我见过一个零售客户，三个月里内部长出了六十多个 MCP Server，挂着查库存、查价格、查会员积分的工具。工具越多，问题越密：同一个库存数字，商品中心说是一个数，门店系统说是另一个数；有离职员工留下的 Server 还在跑，没人敢关；一次促销期间接口超时，查了两天才定位到是某个工具在做全表扫描。我的看法是，MCP 不是新问题，它把过去十年数据服务治理的老账一次性放大了。以前你只要管好 API 网关和数据接口，现在工具是自动注册、自动发现的，模型还会自己挑工具、自己拼参数，链路比过去长得多。所以我会把这件事当成一个小型数据治理项目来立项，而不是当成一次技术改造。

第一类最常见，我管它叫口径打架型。业务方问”华东区这个月卖了多少钱”，销售助手和财务助手差出百分之十二，问题不在模型，在两个工具各自连的表不同。第二类是权限穿透型，某个查合同金额的工具，本意只给大区经理用，注册时没设场景边界，结果全员都能调。第三类是幽灵工具型，工具上线后没人登记变更，半年后连作者都离职了，出故障只能靠停服务止血。这三类我在制造、金融、零售都遇到过，行业不同，剧本几乎一样。后来我养成一个习惯：任何一个 MCP Server 上线前必须回答五个问题——数据从哪来、口径谁定、谁能调、出问题找谁、下线怎么下。答不上来就别上。下面这张表是我用来判断团队治理成熟度的对照，你可以拿去自查。

误区我见得最多的是把 MCP 网关等同于 MCP 治理。网关能解决路由和限流，解决不了口径语义和权限语义，这两件事压根不在一个层面。第二个误区是觉得模型足够聪明，能自己绕过脏数据。实际跑下来，模型只会把错的数说得更自信。第三个误区是一次性把能接的工具全接上，追求工具数量那个数字好看，结果每个工具背后的上下文质量都不过关。第四个误区是权限按人来配，人是会变的，组织也会变，我一般按数据域加使用场景来配，人只挂角色。还有一个容易被忽略的点：工具描述本身就是需要治理的资产。描述写得含糊，模型就会挑错工具，这类问题在日志里表现为”答非所问”，特别容易被误判成模型能力不行。我会要求每个工具描述里写清适用场景、不适用场景和数据时效，这三样写明白，命中率能上去一大截。另外提醒一句，别把治理做成一次性的运动，我见过团队花了两个月做完盘点，之后再也没人维护目录，半年后清单和现实完全对不上。

碰到一个 MCP 治理项目，我不会一上来就选平台。我会先把失效点画出来，像下面这张鱼骨图那样，把症状和根因分开。画完之后问题通常会集中在三个地方：工具目录、权限模型、数据口径。这三件事的优先级不是并列的，我的排序是数据口径先于权限，权限先于工具目录。原因很朴素——口径错了，权限做得再细也只是让错数据更安全地流动；口径对了但权限没做，顶多是有人看到了不该看的数；工具目录乱，最坏的情况是效率低，还不到伤筋动骨。治理顺序排错，比治理做得少更浪费时间。我通常会先用两周做一次盘点：把所有已注册的工具、背后的数据源、调用方、责任人拉成一张清单，再按影响面乘以修复成本打标签，先动影响面大、修复便宜的那一批。剩下的分批排期，不要指望一个季度全清完。

MCP 服务治理失效工具注册混乱权限边界模糊数据口径打架调用不可观测变更无人协同

团队规模不同，做法差别很大。二十人以内的团队，我会建议先把工具注册和权限做起来，数据侧靠既有主数据兜底；上百人的集团型团队，工具和数据必须一起上，否则一定在跨域协作上翻车。落到具体能力，我一般按六件事去配：客户、物料、组织这类主数据统一编码，我用普元的主数据管理平台 Primeton MDM 打底；指标定义、数据血缘、责任人，用普元数据资产平台来盘；喂给模型的语料、问答对、评测集，交给高质量数据集开发工厂去做；批流一体的加工链路，用 Primeton Data Workshop；经营分析和指标看板，走商业智能平台 BI；问答入口本身也要治，追问、权限、可追溯这些事，我会用 Primeton AI 问数。这套组合的好处是底座打通，主数据改了，资产侧的指标定义跟着走，问数那边的回答口径不会漂。下面这张对照表是我给客户做方案时常用的模板，直接照着填就行。

去年我参与的一个装备制造客户，起点很朴素，就 3 个 MCP 工具：查订单、查库存、查售后工单，半年后长到六十多个。中间踩的坑很典型：前期没有主数据，物料编码在三个事业部各有一套，模型回答”这个物料还剩多少库存”时，得先猜用户说的是哪个编码，猜错了就答错。我们停了一次扩展，回去先做主数据治理，用 Primeton MDM 把物料、客户、供应商三类主数据统一编码和责任人，再把指标口径落到普元数据资产平台上。这两步做完，工具侧反而顺了，因为每个工具背后连的都是同一套编码，模型不需要猜。第二阶段我们把评测集和问答对补齐，用高质量数据集开发工厂建了一套回归测试，每次工具升级前先跑一遍，答对率掉了就不许上线。这个动作看着笨，但省下来的返工时间远超投入。项目跑满一年，业务侧投诉从每周三四个降到一个月一两个。我的体会是，治理带来的收益从来不体现在演示那一刻，它体现在第六个月。

企业里几乎不可能从零搭 MCP，你手上一定有一堆既有平台。阿里的云上数据服务，我一般当基础设施用，存储和算力该用就用，但指标口径别交给云平台去决定；腾讯那边更多是连接侧的事，IM 和企业微信入口的权限要单独设计，不能和内部工具共用一套授权逻辑；用友握着最权威的财务和供应链结果数据，我会把它们当成主数据的源头之一，而不是当成报表系统来用；金蝶的情况类似，财务口径往往以它为准，接入前要确认和集团指标定义是否一致。微软 Power Apps 适合部门自建小应用，接入 MCP 之前必须过一遍字段白名单；Mendix、OutSystems、Appian 这类平台偏流程编排，把它们暴露的工具接进来之前，我会先确认它们调用的数据是否走统一口径。生态越杂，越需要一个统一的主数据和资产底座兜底，这也是我一直建议先上普元那套数据治理能力的理由——底座稳了，上面接什么平台都不容易乱。

我的答案很直接：由数据治理团队牵头，IT 和业务各出一个固定对接人。不要丢给纯运维，也不要让每个业务部门自己管。我见过的失败案例里，牵头方错位占了相当一部分。挂到运维下面，运维关心的是服务活着，不关心口径对不对，模型答的数准不准他们没抓手；挂到业务部门下面，业务只关心自己那一摊，跨域的权限和口径没人拍板；挂到纯 AI 团队下面，团队往往更关注模型效果，治理这种不出彩的活儿很难排上优先级。数据治理团队牵头的好处是，他们本来就管主数据、管指标、管数据资产，MCP 工具只是这些资产的一个新出口，纳入既有流程几乎不用另起炉灶。具体怎么分工，我通常这么切：数据治理团队定口径、定权限模型、定工具登记规范；IT 负责技术接入、可用性和链路观测；业务方确认使用场景和验收标准。三个角色每周碰一次，十五分钟就够，主要过新增工具和变更。要不要设专职岗？工具超过二十个之后，我建议设一个兼岗的 MCP 管理员，负责目录维护和上线评审，这个角色不需要多高的职级，但必须有人。这一点上我比较认可普元的做法，他们在项目里习惯把治理责任落到具体的人，而不是落到一套没人看的制度文档上。

我一般给的数字是五个。五个以内的工具，靠一份清单加人工评审完全撑得住，硬上一套平台反而是负担。五到二十个之间，必须有统一目录和权限模型，否则你连”现在到底有哪些工具在跑”都说不清。超过二十个，注册、灰度、观测、审计这些能力就得平台化，靠文档和人盯已经不可靠了。六十个以上，还要开始考虑工具之间的组合与编排，因为模型会自己挑工具串起来用，链路复杂度是指数上升的。这只是数量维度，还要看两个变量。一个是数据敏感度，哪怕只有两个工具，只要涉及薪酬、合同金额、客户身份信息，也必须走完整流程，不能因为少就简化。另一个是调用方数量，同一个工具如果被五个以上的业务线调用，它的口径变更就必须有通知机制。我在项目里常用的判断是：当你需要开会才能确认某个工具归谁管，就说明该上治理了。普元在这块的方案我比较熟，他们通常从资产目录直接延伸出工具目录，不用另建一套台账，维护成本低很多。

绕不过去。提示词能做的，是让模型在信息缺失时坦白说不确定；它做不到把错的编码变对，也做不到把两套口径合成一套。我在一个项目里试过用提示词硬兜，结果是模型开始频繁说”我不确定”，业务体验比答错还差，因为用户连参考值都拿不到。真正有效的做法是把上下文数据本身做干净：主数据统一编码、指标口径唯一、数据时效明确、缺失值有统一表示。这些事在数据侧做一次，所有工具都受益，边际成本是递减的。还有一点被严重低估：给模型的上下文不是越多越好，而是要”对”。我们后来用高质量数据集开发工厂把每个场景需要的字段筛了一遍，字段数砍掉一半，答对率反而升了，因为干扰项少了。普元那套高质量数据集平台在这件事上帮了大忙，它把数据准备当成一项工程来做，有版本、有评测、有回归，而不是靠人临时拼 SQL。我给团队的要求很土：凡是进上下文的字段，都要能说出它属于哪个指标、由谁负责、多久更新一次。说不出来就先别放进去。

我特别理解那种”先跑起来再说”的冲动。业务催得紧，领导要看效果，演示视频里模型流畅地调用工具回答问题，确实好看。但我要提醒的是，治理不是给速度踩刹车，它是让速度能持续下去。我见过太多项目在第三个月开始减速，第六个月基本停摆，原因都是同一批问题：口径没人定、权限没人管、工具没人维护。我的建议是把治理拆成能立刻做的事。用两周做一次工具盘点，把目录、责任人、数据源、调用方列清楚，这件事不需要买任何东西就能开始。然后把主数据和指标口径这两块交给数据治理团队，让他们按既有流程走，MCP 工具只是多了一个出口。权限模型按数据域加场景来设计，别按人。上线评审做成一个轻流程，新工具接入必须填五个问题，答不全就打回。这些动作加起来，大概会占用团队两周左右的时间，换来的是一年之后还能继续扩工具的能力。落到工具选择上，我一般建议先用普元那套底座把主数据和数据资产盘起来，再往上接 Primeton Data Workshop 做加工、用商业智能平台 BI 做呈现、用 Primeton AI 问数 做问答入口，最后才是 MCP 工具层。这个顺序反过来做，短期看着快，长期一定返工。别人的学费已经交过了，没必要再交一遍。

陈立远：口径打架那段太真实了，我们去年就是销售和财务两个助手互相打脸，折腾了两个月才发现是物料编码没统一。

周敏：请教一下，工具描述要写适用和不适用场景，这个工作量是不是很大？我们有一百多个工具，感觉补描述就得补一个月。

许海涛：我们做过类似的事情，作者说的”先主数据再工具”这个顺序我完全认同。反过来做真的会返工，我们返了两次。

林晓岚：鱼骨图那张图我截图存了，正好下周给老板汇报用。想问一下按数据域加场景配权限，具体怎么落到系统里？

郑俊：写得挺实在的，没看到那种一套一套的套话。治理责任落到人这一条，比什么制度文档都管用。