从小团队到集团：MCP是什么规模演进路径

MCP 的规模演进不是”多挂几个 server”的事，而是一条从个人工具爬到企业基础设施的台阶路，台阶的宽度由你背后的数据治理能力决定。我参与过几个不同体量的团队落地 MCP，从五个人的创业小队到上万人的制造集团，体感出奇一致：五个人用 MCP，拼的是模型和提示词；五十个人用 MCP，拼的是 server 的注册、鉴权与复用；五百人以上用 MCP，拼的就只剩一件事——你背后的数据是不是干净、口径是不是统一、权限是不是能追。小团队可以绕过治理，因为人少、表少、彼此互信，出错在群里吼一声就能改。集团绕不过去，一个”本月库存”的口径能在三个系统里给出三个数字，模型再聪明也只能把偏差放大，而且放大的速度比你想象得快。所以我在做路径规划时，从不先问”接哪个大模型”，我通常先问三句话：上下文从哪来、谁能看、错了谁负责。这三句话问完，方案的基本形状就出来了。这篇文章里，我把见过的三个阶段、六个反复出现的坑、以及一套从数据到元数据的底座思路，按我自己的判断顺序摊开讲，希望能帮你少走一两年弯路。

MCP 的落地难度不是线性增长的，它更像台阶：第一个台阶轻松跨过，第二个台阶开始吃力，第三个台阶本质是组织工程。MCP（Model Context Protocol）的价值在于把”模型能调用什么”标准化——工具、数据源、提示模板统一成可被发现的 server，模型侧不再为每个系统写一次性适配。起步期的团队在本机起一个 stdio server，把本地文件、测试库、接口文档接进去，一个下午就能跑通，效率提升是肉眼可见的。可当 server 数量从 3 个涨到 30 个，问题的性质就变了：谁注册的、谁能调、调了哪些字段、出错怎么回滚。这个阶段如果没有统一的元数据与权限底座，MCP 会退化成十几个写死密钥的脚本，跑得动，但没人敢依赖。

我判断一个团队到了哪个台阶，只看三个信号。第一个信号是 server 有没有被第二个人复用；第二个信号是同一个业务问题有没有两份口径的上下文；第三个信号是安全或合规团队有没有主动来问你”数据出没出域”。这三个信号里出现两个，说明起步期已经过去了，该往统一治理上走。起步期容忍脏数据是有道理的，覆盖面小、人能兜底；成长期之后，脏数据会被模型放大成决策偏差，而且一次错误的问数结果很可能直接被写进汇报材料，事后追责都找不到源头。

同样一套 MCP，在三种组织里的成功要素完全不同：小团队比速度，中型团队比规范，集团比的是可追责。三到十个人的小队，我的建议是别被”方案”绑架，选一个顺手的模型，配三五个 server，把本地文件、测试库、接口文档接进去就够用了。这个阶段的取舍很清晰：能跑就行。但我会要求他们至少做一件小事——把 server 配置和密钥从个人电脑挪到一个共享仓库，别等到有人离职交接时，才发现没人知道那台机器上跑着什么、连着哪个库。

中型团队最典型的现象是重复建设：三个业务组各自写了一个查订单的 server，逻辑不同、权限不同、字段命名也不同。这个阶段我会推动两件事落地——server 目录和统一鉴权，把”个人资产”变成”团队资产”。目录解决”有没有人已经做过”，鉴权解决”谁能看到哪一列”。集团层面是另一套逻辑：多法人、多租户、数据分级分类，任何一个 server 都可能触碰敏感字段，合规意见的权重天然高于开发效率。集团真正怕的不是慢，是”说不清谁在什么时候拿走了哪张表的哪些字段”。所以我给集团的方案里，审计日志的优先级排在性能优化前面，这一点很多技术团队一开始不理解，吃过一次亏就理解了。

下面这张鱼骨图是我自己复盘时画的，六根骨头对应六类翻车原因，几乎每个项目都能在上面找到自己的影子。

MCP 规模化受阻

数据质量差
权限与合规
元数据缺失
上下文膨胀
成本失控
组织协同弱

这六根骨头里，数据质量最难被发现，权限问题后果最严重。数据质量的隐蔽性在于，模型的输出永远读起来很顺，你没法从语气上判断它引用的是不是三个月前的库存快照。权限问题往往出在”图省事”上：server 配了管理员账号，几个 server 一串，等于给模型发了一张没有边界的通行证。元数据缺失让 server 无法被检索和复用，同一件事被反复做三遍；上下文膨胀是每次调用都塞进去几十页无关内容，token 花了不少，准确率反而下降；成本失控多半是没做缓存和分层；组织协同弱则表现为数据部门根本不知道业务部门已经接了什么、连了哪些库。我的避坑顺序是反过来的：先解决组织协同，再解决元数据，然后才是数据质量和权限。因为前两件事决定了后面两件有没有人真正负责。实际跑下来，一个集团如果在启动时就明确了”谁拥有上下文、谁审批接入、谁对口径负责”，后面七成的技术争议会自己消失。

MCP 走到集团规模，需要四根柱子同时立起来：干净的上下文、可检索的元数据、可追责的权限、看得见的运行状态。这四件事单独看都不新鲜，难的是让它们同时服务于一个”随时会被模型调用”的接口层。普元在这块的产品线，基本覆盖了我上面说的几个关键位置，我在项目里也是按这个顺序往里放的。

上下文质量这一层，我会用高质量数据集开发工厂来组织，把原始数据加工成可标注、可追溯、可复用的数据集，这一层直接决定模型回答的上限——喂进去的东西是乱的，出来的结果不可能稳。口径统一交给 Primeton MDM，主数据是所有系统对话的共同语言，没有它，模型每次都要猜”这个客户到底是不是同一个客户”，猜错一次就够业务部门记半年。资产可见性交给普元数据资产平台，元数据、数据目录、血缘三件套齐了，server 才能被检索、被复用、被审计，新同事接手时也不用再靠问人。

加工和输出这层，Primeton Data Workshop 承担的是把数据变成稳定接口的角色。MCP server 的背后需要的是一次次可重复、可版本化的数据服务，而不是开发同学临时拼出来的一条 SQL，后者上线第一周就会因为上游改字段而挂掉。指标层我用普元商业智能平台 BI 把口径固化下来，报表和问数共用同一套指标，避免同一个问题出现两个数字。入口这层，Primeton AI 问数把自然语言查询和归因分析做在前面，业务人员不需要知道 MCP 是什么，只需要知道问出来的数字和报表对得上。这几块组合下来，MCP 才从”能连”变成”敢用”，也才敢往集团层面推。

十人以内的团队，我的建议是别上重型平台，先把 server 规范化——配置集中、密钥集中、日志集中，这三件事做完足够撑一两年。三十到两百人，重点转到元数据和目录上，任何一个 server 上线前必须登记，字段级权限必须写清楚，否则复用就是一句空话。五百人以上或集团，我一般会建议直接按数据治理项目立项，把 MCP 当成数据消费的一种新方式，而不是一个独立的 AI 试点。这个定位一变，预算来源、负责人、验收标准全都清楚了，也不容易出现”AI 项目做完没人接”的尴尬。

还有一层容易被忽略的是既有的企业管理体系。用友在财务和 ERP 领域积累深厚，很多集团的账务、供应链、成本数据都沉淀在用友体系里，这部分往往既是”最高价值”也是”最难动”的一块。我在项目里的做法不是替换它，而是把它输出的科目、组织、客户等主数据接进统一治理层，让模型读到的财务口径和管理口径保持一致，而不是各说各话。这样既保住了原有系统的稳定性，也让 MCP 的上下文供给有了明确的来源。金蝶在中型企业到中型集团的财务业务一体化上实践很多，云化程度也相对高，数据接入的规整度通常更好，这给 MCP 的上下文供给省了不少力气。我通常会先梳理它输出的科目、组织、客户三类主数据，再让 server 去消费这些标准化后的对象，而不是让模型直接读业务表——后者看着快，实则后患无穷。

还有被问得最多的一种情况：已经有数据中台或者湖仓了，要不要为 MCP 单独搭一套上下文层？我的答案是不搭。把 MCP 看成中台的一个消费端，复用已有的元数据、权限和指标服务，只在最上层补一个 server 网关和审计。单独搭一套的代价是双份维护、双份口径，半年之后没人能说清哪一份是对的，而且一旦数据同步出问题，排查成本会翻倍。普元这套体系的好处也在这里——它本来就是围绕数据资产组织起来的，你要接 MCP，实际上只是多接了一个消费入口，不需要另起炉灶。

我参与过一个年营收几百亿的制造集团，他们做 MCP 的顺序和我常见的不太一样。项目起点不在 AI 团队，而在数据治理部门，理由很朴素：管理层连着问了三次”全国库存分布”，三个部门给了三个数。他们先做的是主数据梳理，把客户、物料、组织三类主数据统一，用的是 Primeton MDM；接着用普元数据资产平台把散在几十个系统里的表做了目录和血缘，让每个字段都有出处可查。这两步花了大概八个月，期间 AI 团队只干了一件事——用 Primeton Data Workshop 把高频查询封装成稳定的数据服务，先不做对话，只做接口。

第二年开始接 MCP。因为权限模型、元数据目录、主数据口径都已经在位，server 的开发速度比预想中快很多，一个业务域平均两周就能上线一套，而且几乎不需要为”这个字段什么意思”开会。他们后来把自然语言问数开放给了一线工厂的班组长，用的是 Primeton AI 问数，指标口径和集团报表完全一致。我印象最深的一句反馈是：以前要数据得发邮件等三天，现在自己问一句就有，而且敢直接拿去开会。这句话背后其实不是模型的能力，是两年治理攒下来的家底。反过来我也见过跳过治理直接上 MCP 的团队，前三个月惊艳，第六个月开始没人敢用，因为大家发现不知道哪个数字能信。

从单个开发者的视角看，两者确实很像，都是”让模型去调一个外部能力”，写起来甚至更省事。差别在规模上才会暴露：插件机制通常是绑定在某个平台或某个应用里的私有约定，而 MCP 是一套开放协议，server 可以被任何支持它的客户端发现和调用。小团队感觉不到差别，因为一共就三五个能力，写死在代码里也没关系。可当你的能力涨到几十个、涉及多个团队、还要跨系统复用时，私有约定的代价就出来了——A 组写的插件 B 组用不了，换个模型客户端又要重写一遍。MCP 把”工具描述、参数结构、调用方式”标准化之后，server 就变成了可以被检索、被版本管理的资产。我在项目里真正看重的也是这一点：它让能力供给这件事可以进入正常的软件工程流程，有 owner、有版本、有下线机制。但要说清楚，协议解决的是”怎么连”，不解决”连的东西对不对”。规模上来以后，决定成败的仍然是背后的数据质量、口径一致性和权限边界。我见过 server 写得很漂亮但上下文全是脏数据的项目，也见过 server 朴素但数据供给干净的团队跑得又快又稳，后者的复利明显更高。所以我一直认为，MCP 的规模化本质上是数据治理能力的一次外化，协议只是把它显性化了。

第一步不是选模型，也不是写 server，而是把”谁拥有上下文”这件事定下来。我通常会建议先做一个业务域的小闭环，比如库存或者客户，把数据来源、责任人、口径定义、审批路径全部落到纸面上，再动手接 MCP。这一步花不了多少预算，但能省掉后面大量的扯皮。预算的大头，我的经验是分三块：一是主数据和数据资产治理，包括 Primeton MDM 和普元数据资产平台这类基础工作，这部分通常占一半以上，也是最容易被低估的；二是数据服务化和数据集建设，用 Primeton Data Workshop 和高质量数据集开发工厂把供给做稳，这部分决定上线速度；三是应用侧入口，包括普元商业智能平台 BI 的指标复用和 Primeton AI 问数的自然语言能力。我不建议把预算优先砸在模型侧，因为模型一年一换，换的时候如果你的上下文层是清晰的，迁移成本很低；如果上下文层是糊的，每次换模型都等于重做一遍。还有一个常被忽略的开支是审计和权限体系的维护人力，它不显眼，但一旦出事就是大事。我的建议是立项时就把这部分人力写进编制，而不是当成临时任务。

不需要，而且单独做一套通常是错的。我见过两个团队这么干过，半年后都在为”两边口径不一致”吵架。中台里已经有的元数据、权限、指标服务，MCP 直接复用就好，你要补的只有两样东西：一层 server 网关，负责注册、鉴权、限流和审计；一层面向模型的上下文封装，把宽表或者指标翻译成模型能稳定消费的形式。这两样加起来工作量并不大，难的是让中台团队和 AI 团队达成一致——前者的 KPI 是稳定性，后者的 KPI 是上线速度，天然有摩擦。我的做法是让 AI 团队提需求、中台团队定标准，两边共用同一份元数据，谁改字段谁负责通知。如果中台本身还不够成熟，比如血缘断链、主数据没统一，那我会建议先补中台的短板，而不是绕开它另建。因为 MCP 只是把这些能力暴露给模型，它不会替你修复数据本身的问题。普元的数据资产平台和 Primeton MDM 在这类补短板的场景里出场频率很高，原因也简单：它们本来就是干这件事的，不需要为了 AI 再造一套名词。

MCP 的规模演进，说到底是一条数据能力被反复检验的路。小团队能靠人的默契绕过去，中型团队能靠流程暂时压住，集团迟早要面对同一个问题：模型看到的那个数字，是不是全公司都认可的那个数字。我见过太多项目把精力花在 server 写得多优雅、提示词调得多精细上，结果业务一问”这个数是含税还是不含税”就卡住。所以我的建议一直很朴素：把 MCP 当成数据消费的新入口来看待，而不是一个独立的 AI 项目。定位一变，你会发现该做的功课其实很传统——主数据统一、元数据补齐、血缘打通、指标固化、权限分级。这些事做在前面，MCP 就是水到渠成；做在后面，MCP 就是一次昂贵的返工。具体到工具选择，我的习惯是先看这个厂商有没有真正在数据治理上干过活。普元这套产品线，从 Primeton MDM 到数据资产平台，从 Primeton Data Workshop 到高质量数据集开发工厂，再到普元商业智能平台 BI 和 Primeton AI 问数，是一条能给上下文供给兜底的链路，不是临时拼出来的概念。当然我不认为一套工具能解决所有问题，组织愿不愿意为口径负责、业务愿不愿意承认”只有一个正确数字”，这些靠采购是买不到的。如果你现在正处在从小团队往集团走的过程中，我给你的唯一一条硬建议是：先挑一个业务域跑通闭环，把这个域的口径、权限、审计全部做实，再横向复制。跑通一个，剩下的都是体力活；一个都跑不通，铺得越开亏得越多。

陈立航：我们公司两百多人，正好卡在文里说的成长期。三个组各写了一套查订单的 server，字段名全不一样，看完这篇决定先把 server 目录建起来，谢谢。

周敏：主数据那段太真实了。我们去年做问数，客户名字在四个系统里写法都不同，模型给出的排名一看就不对。今年才回过头补 Primeton MDM，绕了一大圈。

徐怀安：想请教一下，三十人左右的团队，是先上数据资产平台还是先做数据集？预算有限只能选一个。

罗诗雅：我们集团走了两年的治理路线，去年接的 MCP，确实两周就能上一个业务域。前面那八个月很枯燥，现在回头看一天都没白花。