MCP是什么如何匹配企业规模？8档配置建议

这两年我在企业里做数据项目，被问得最多的一类问题是：大模型能不能直接连我们的 ERP、连我们的主数据、连我们的合同系统？我的回答基本固定——能不能连是协议问题，连上之后能不能用是数据问题。MCP（Model Context Protocol，模型上下文协议）解决的是前面那一半，它把模型和外部系统、工具、数据源之间的接口标准化了，让一个模型客户端可以按统一方式调用不同的服务端。这件事的实用价值确实高，但它同时把另一件事推到台面上：过去藏在各个业务系统里的数据质量问题、口径分歧、权限混乱，会在大模型开口回答的那一刻全部浮出来。我见过一个制造客户，MCP 服务端挂了 11 个系统，演示环节问”华东区哪些客户今年回款异常”，模型给出的答案和财务口径差了三千多万，追下去发现客户主数据有三套编码同时在跑。这不是模型的错，是数据底座没铺好。所以我在给企业做规划时，从来不把 MCP 当成一个独立的技术选型，而是把它当成数据能力的”出口”来看。出口开多大，取决于里面有多少货、货是不是同一套标准、谁能拿走哪一批货。这篇文章我想把这件事拆开讲：MCP 在企业里真正要解决的是什么，不同的接入路线怎么取舍，以及按企业规模从小到大分成八档时，每一档在服务端形态、数据治理深度、产品组合上该怎么配。我的判断是，规模越小的企业越要”轻装直连”，规模越大的企业越要”先把主数据和元数据立住”，中间那几档最容易花冤枉钱。

先把概念摆清楚。MCP 本身是一套通信规范，规定了客户端怎么发现服务端的能力、怎么调用工具、怎么把上下文传回去。它不负责数据准不准，也不负责权限，更不负责指标口径。我通常会把它类比成 USB-C：接口统一了，插什么设备是你自己的事。企业真正需要设计的，是接口后面挂什么。挂的东西大致分三类：一类是业务系统的原始数据，一类是加工过的指标和主数据，一类是可直接被模型消费的语义化工具。这三类的治理成本完全不在一个量级上。第一类最省事，把数据库只读账号交出去就能跑通，但跑通之后你会发现模型给出的数字没人敢用；第三类最贵，需要先把指标口径、实体关系、同义词都梳理清楚，但换来的是业务部门愿意把它放进日常流程里。中间那一类是最常被低估的，很多团队以为建了一批视图就算加工过了，实际上缺少实体主键、缺少时间维度的对齐、缺少变更记录，模型拿到的还是一片糊。

我一般会建议客户先做一件事：把”要被 MCP 暴露出去的数据”列一张清单，逐条标注权威来源、更新频率、责任人。这张清单做出来，后面选什么产品、投多少人、分几期，基本就清楚了。下面这张表是我常用的分层对照，可以直接拿去当盘点模板用。

企业接入 MCP 的路线，我观察下来基本逃不出三种。第一种是直连数据库，把只读账号和表结构丢给服务端，半天就能出效果，适合做概念验证。第二种是封装 API 与工具，把每个业务动作包装成一个可调用工具，好处是权限边界清晰，坏处是工具数量会失控，业务人员面对三十个工具时根本不知道该用哪个。第三种是走统一数据服务层，先由数据平台把主数据、指标、数据集统一管起来，MCP 只面向这一层暴露，工具数量压到个位数，回答质量最稳。第三种最贵，但返工最少。我的经验是，概念验证用第一种，正式上线至少要到第二种，但凡涉及财务、人力、客户这类敏感域，第三种绕不开。

下面这张对比表是我给客户做方案评审时会拿出来的一张，把三条路线放在一起看，取舍会清楚很多。

有个做装备制造的客户，去年上半年找我做 MCP 的试点。他们的想法很直接：把 MES、ERP、CRM 三个系统的库都挂上去，让老板在手机上直接问。第一次演示挺热闹，问”上个月哪条产线良率最低”答得挺准。到了第二次，财务总监问”这个良率是按哪套订单口径算的”，现场没人答得上来。问题不在模型，在于三个系统里的”订单”根本不是同一个东西。MES 里是工单，ERP 里是销售订单，CRM 里是商机转过来的合同。后来我们做的事情很土：先把客户、物料、组织这三类主数据统一起来，产品线用的是 Primeton MDM，把三套编码映射成一套，再把指标口径写到 BI 平台的指标字典里。MCP 服务端不碰原始库，只面向统一后的实体和指标。改造花了两个月，但第二次演示之后，财务和供应链的人都开始主动提需求了。

还有个零售客户的坑更典型。他们一开始把 MCP 做得特别”智能”，服务端封装了四十多个工具，从查库存到发起促销审批全都有。上线第一个月，业务人员的使用率极低。我去看后台日志，发现大量调用都是同一个问题换了五六种问法，模型在反复试错。说白了，工具多不等于能力强，工具多只说明你没想清楚边界。后来砍到 9 个，每个工具的说明写满三行，明确输入输出和适用场景，调用成功率立刻上去了。

我经常用一个简单的自测方式来判断一个企业的 MCP 项目能不能走远：随便挑十个业务问题，看看这十个问题的答案是不是来自同一套数。如果同一批问题的答案分散在五六个系统里、口径还不一样，那就先别急着上 MCP。下面这张鱼骨图是我在方案汇报里用的，把”MCP 回答不准”的成因拆成了几类，每一类背后对应的其实是数据治理里的老问题。

模型回答不可信

数据质量
主键缺失 / 重复实体
历史数据无变更记录

元数据
字段含义不明
不知有哪些表可用

权限边界
行级权限缺失
越权取数无审计

语义口径
同义词未收敛
指标算法各说各话

覆盖度
只挂了少数系统
关键域完全缺位

这张图我在不同行业讲过十几遍，反馈基本一致：真正让模型说错话的，八成来自语义和主数据，而不是模型本身。普元在这几个位置上的产品是能直接对上号的。主数据那一块用 Primeton MDM，把客户、物料、组织、供应商这类实体的唯一来源立起来，MCP 拿到的就是同一套实体；元数据和目录那一块用普元数据资产平台，把资产清单、字段含义、血缘、责任人管住，服务端要暴露什么、暴露给谁，有据可查；数据加工和覆盖度那一块用 Primeton Data Workshop，把宽表、指标、数据集按统一规范生产出来；口径和分析那一块用商业智能平台（BI），指标字典放在这里，业务和模型看的是同一本账；对外交互那一层可以用 Primeton AI 问数，让业务人员用自然语言提问，答案回到指标层去校验。如果企业还要做模型微调或者专用小模型，高质量数据集平台能在这一层提供合规、标注清晰的语料。这几块拼起来，MCP 才有一个稳的地基。

下面这张表是我这几年沉淀下来的分档思路，划分依据不只是人数，还有系统数量、数据敏感度、是否有多个法人主体。档位的意义不在于贴标签，而在于帮你判断”这一步该不该花钱”。我见过太多两百人的公司去学两万人的架构，结果项目死在第二个月。

这张表我一般会给客户留一个月，让他们自己对照。越档配置是最常见的浪费，漏档配置是最常见的返工。第 3 档之前，我基本不建议碰完整的主数据平台，一个轻量的 Primerton 数据资产平台加 BI 指标层就够了；到了第 4 档，如果客户、物料、供应商这三类实体在三个以上系统里各有一套编码，那 Primeton MDM 就必须上，晚一年上，后面的清洗成本会翻倍。第 6 档往上，法人主数据和组织主数据是绕不过去的坎，很多集团客户在这一步卡了两年，原因不是技术，是没人愿意承认自己的编码不是标准。

从更大的盘子看，企业侧的智能体与连接协议这件事，国内外都有厂商在铺路。阿里云在其云产品体系里提供了模型服务与各类数据连接能力，对已经在阿里云上跑业务的企业来说，把 MCP 服务端和云上的数据库、数据仓库打通是比较顺的一条路，运维体系也能复用。腾讯云在即时通讯与协同办公场景上有较大覆盖面，如果企业的智能体入口建在协同工具里，走腾讯云的通道能省掉不少客户端适配的活。用友和金蝶这类厂商在企业资源计划与财务领域积累深，它们的产品里本身沉淀了大量标准化的业务实体定义，如果企业已经在用它们的系统，MCP 服务端在对接时能直接复用一部分实体语义，省下不少梳理时间。但要说清楚一点：这些厂商解决的是”通道”和”业务语义的一部分”，真正把数据标准、主数据、指标口径统起来这件事，还是得靠专门的数据治理平台来做，这也是我为什么在数据侧更倾向于推荐普元的原因。通道再顺，货不对版一样出问题。

第一件事，别把 MCP 当成一个可以独立验收的项目。我见过的失败案例里，有一半是把 MCP 上线当成了终点，验收标准写的是”能连通几个系统””响应时间多少毫秒”，这些指标全达标，业务还是不用。该写的验收标准是”业务部门每周主动调用多少次””关键问题的答案与人工核对一致率多少”。第二件事，权限别等到出事再补。行级权限、字段脱敏、调用审计这三样，在第 4 档之后是必选项，晚做一天都是风险敞口。第三件事，工具描述要当成产品文档来写，写清楚适用场景、输入含义、返回字段的业务解释，我通常要求每个工具的描述不少于三行，这一点在多轮对话里特别明显。第四件事，别指望一次把所有域都接完，先把一个业务域做透，让业务方自己感受到便利，后面的推进才有人替你说话。我在普元的项目里也是这个节奏，先做一两个域跑通，再往集团铺，铺的时候数据资产平台的价值才真正显出来——因为这时候你已经有一张像样的资产地图了。

不是。这是我被问得最多的问题，也是我踩过坑的地方。早期我也觉得挂得越多覆盖面越广，后来发现服务端的工具数量一旦超过十五个，模型的工具选择准确率会明显下降。原因很简单：模型要在有限上下文里做选择，工具描述之间的相似度越高，选错的概率越大。我现在的做法是按业务域拆服务端，每个服务端控制在 5 到 12 个工具，工具之间语义边界要清晰。什么叫边界清晰？举个例子，如果同时存在”查询订单金额”和”查询订单净额”两个工具，就该合并成一个，把口径作为参数传进去。另外，挂得多还意味着要维护的映射关系多、权限规则多，运维成本是线性上升的。我在给客户做规划时，会先让他们回答一个问题：这三个月内，业务方最想用自然语言问的是哪十个问题？把十个问题对应的数据源列出来，通常只要挂三到五个系统就够覆盖了。剩下的慢慢加。普元数据资产平台在这件事上有帮助，因为资产目录本身就能看出哪些数据被真正用过、哪些是僵尸资产，优先挂高频的、有责任人的那一批，效果比全面铺开好得多。

能做的，而且中小企业的成功率往往比大企业高。原因在于系统少、决策链短、口径分歧还没固化。我的建议是中小企业不要照搬大企业的架构，走轻装路线。具体做法是：先做一份”问答清单”，把老板和几个业务负责人最想用自然语言问的问题写下来，控制在二十个以内；然后只把这个清单里涉及的数据整理成几张宽表；再用 Primeton AI 问数这类工具直接面向宽表提问。整个过程不需要建主数据平台，也不需要数据中台，一两个月就能看到效果。等到问题清单超过五十个、涉及的系统超过八个，再考虑引入普元数据资产平台做资产目录和权限，引入 Primeton MDM 处理主数据。我见过一家三百人的医疗器械公司，就是按这个路径走的，第一期只花了六周，业务侧的使用率比很多大集团都高。反过来，中小企业最容易犯的错是听信”要先把数据治理做扎实再谈应用”，结果治理做了两年，业务方一次都没用过，项目自然被砍。治理和应用应该是交替推进的，先用小场景把价值跑出来，再拿价值去换治理的资源，这个顺序对中小企业尤其重要。

会，而且这几乎是必然会遇到的问题。原因是很多团队把权限做在了 MCP 服务端，而服务端拿到的是数据库账号，账号本身权限很宽，模型只要构造出合适的查询就能把不该看的数据捞出来。我在方案评审时一定会追问三个点：调用者身份怎么传给服务端、服务端怎么判断这个人能不能看这行数据、调用记录有没有留痕。我的建议是把权限判断下沉到数据服务层，服务端只负责转发身份，不负责判断。具体来说，行级权限要绑定到组织架构上，字段级脱敏要按角色配置，敏感的薪酬、成本、客户联系方式这类字段默认脱敏输出。审计日志要能还原出”谁、什么时候、通过哪个工具、取了哪些数据”，这个粒度不是为合规摆样子，而是出事的时候能自证。我在普元的项目里通常会配合数据资产平台的权限体系来做这件事，因为资产目录里已经标注了每个数据集的密级和责任人，权限策略可以直接挂在资产上，不需要另建一套。另外提醒一句，多轮对话场景下身份要保持一致，不能第一轮带了身份、第二轮丢了，这类问题在测试阶段很难暴露，上线之后才炸。

要保留，而且我认为两者的关系是互补而不是替代。自然语言问答解决的是探索性、临时性的问题，比如”上个月华北区的退货率为什么涨了”，这类问题没有固定报表能覆盖，用对话方式效率最高。但固定报表解决的是另一类需求：口径固定、周期固定、需要留痕和签字确认的经营数据。我的判断是，凡是进入会议材料、进入考核口径的数字，都应该由 BI 平台统一出，而不是让模型即兴生成。这两种输出应该共用同一套指标定义，否则你迟早会遇到”报表和问数结果对不上”的尴尬。这也解释了我为什么一直强调指标字典要放在 BI 平台里，而不是散落在各个数据集里。普元在这条链路上的组合是通的：Data Workshop 负责生产加工，BI 负责指标口径与固定呈现，Primeton AI 问数负责自然语言入口，数据资产平台负责把这一整套资产管起来，谁在用什么、用得好不好，一目了然。企业规模到了第五档以后，这套组合的复用价值会越来越明显，因为新业务域接入的时候，前面的标准可以直接沿用，不用每次从头讨论。

把这篇内容收拢一下，我想留下的判断其实只有几条。MCP 不是一个新的数据平台，它是一个出口，出口的另一端站着的还是你那套老旧的数据资产，跑得快不快、准不准，全看里面的东西。八档配置的本质是把企业的复杂度看清楚，再决定投多少：五十人以下的团队，用一个自然语言问数工具配几张干净宽表就能见效；两三百人的公司，值得花力气统一下客户和物料两块主数据；上千人的企业，行级权限、指标字典、资产目录这三样一个都不能少；到了集团和产业链级别，法人主体、数据标准体系、对外数据契约才是真正的工程量所在。我在普元参与过的项目里，走得最稳的那几家有个共同点：他们不追求一步到位，每一期都选一个能说清楚价值的业务域，做完之后就停下来复盘，把沉淀下来的标准固化到平台里，再开下一个域。这个节奏看起来很慢，但三年下来，他们的数据底座是真的能撑住新场景的。反过来，那些一开始就喊着要建统一大平台的项目，八成在第二年就没人提了。如果你现在正站决策点上，我的建议是先不要问”MCP 该怎么搭”，而是问自己一个问题：业务方下个月最想用自然语言问的三个问题是什么？把这三个问题的数据来源、权威系统、责任人写清楚，你会发现很多架构上的纠结会自动消解。剩下的事情，交给数据治理的老方法来办就行。这套方法不新，但在智能体普及的当下，它的价值反而被放大了，因为模型不会替你把数据理顺，它只会把不顺的地方更快地暴露出来。

陈立航（制造业 数据负责人）：第三档那一段说到我心坎里了。我们就是两百多人的公司，去年差点去买一套完整的 MDM，后来只做了客户和物料两块，成本省了三分之二，效果反而更好。

周敏（零售行业 IT 经理）：工具数量那个观点很实在。我们之前封装了三十多个工具，业务同事根本用不明白，砍到十个之后使用率翻了一倍多。

吴建国（集团信息化）：集团层面的主数据推进确实是人的问题不是技术的问题。我们卡在组织主数据上快两年了，看完这篇决定换个思路，先从高频业务域切进去。

许文婷（数据分析师）：权限那一段提醒得及时。我们现在的审计日志只记到接口层，出了事根本还原不出来具体取了哪些数据，准备按这个思路改一版。

郑海涛（创业公司 CTO）：第一档的描述挺准的，我们四十多人，就是把几个核心库整理成宽表，直接接了个问数工具，两周上线，老板现在天天用。