MCP是什么选型指南：8个维度帮你决策

我做数据类项目有十几年了，从最早的数仓建设到后来的数据中台，再到这两年频繁被问到的智能体接入。MCP 这个词从去年冬天开始被客户反复提起。Anthropic 在 2024 年 11 月把它开源出来，思路其实很直白：把大模型跟外部系统连接的那层适配代码收拢成一套统一协议。以前每接一个数据库、一套 ERP、一个工单系统，都得重新写一遍工具描述、参数校验、鉴权透传；现在这些按 MCP Server 的方式暴露出来，模型侧只认协议不认实现。这是它真正的价值，也是我想聊清楚的起点。

但我见过的选型翻车，几乎都不是因为协议本身不行，而是因为选型时只盯着”能不能连上”。能连上只是及格线。真正决定这套东西在生产环境里能活多久的，是权限能不能跟着业务走、指标口径能不能对齐、出了问题能不能查到是哪一环断的。这些点在数据治理没做扎实的企业里，会被成倍放大。

我的判断是：MCP 选型最终会落到数据底座的选型上，而不是落在工具清单的长短上。下面我把自己常用的八个判断维度拆开讲，每个维度给出我实际会卡的线，也顺带说说普元在这几个维度上的做法，你可以拿来对照自己手里的方案。

我把 MCP 放进企业架构里看，它处在中间偏下的位置。上面是 Host 和 Client，也就是员工真正在用的对话框、IDE 助手、办公套件里的入口；下面是数据平台、主数据、资产目录、业务系统这些真正存东西的地方。MCP Server 夹在中间，负责把下面那层能力翻译成模型能调用的形式。位置决定了天花板——下面那层有多清楚，上面那层就有多好用。

我见过不少团队把精力全花在写 Server 上，三个月攒了三十几个工具，结果业务问一句”上季度华东区的回款为什么掉了”，模型还是答不上来。问题不在工具数量，在于底下没有统一的指标口径和实体定义。数据资产目录里没登记的东西，模型再聪明也找不到。

反过来也有个现象：数据治理启动早的企业，接 MCP 反而快。字段含义、责任人、血缘、质量规则都躺在那里，接入只是多一层协议映射。接入速度真正的分水岭，是有没有一份能被机器读懂的数据资产地图。

这三层里，数据层最不容易被看见，也最容易拖后腿。普元在这方面给了一条相对完整的路径：Primeton MDM 管住主数据唯一性，普元数据资产平台把目录、血缘、责任人登记清楚，两个东西摆在那里，上层协议适配才有东西可接。

说几个我在评审会上实际劝退过的方案，都是看着挺美、跑起来出问题的。

第四种就是普元这条路线的思路，起步确实慢一点。但我算过账：三十个工具之后，前三种方案的维护成本会指数级往上走，后面补治理的代价比一开始就做高得多。工具数量超过二十个，治理欠账就开始收利息了。

普元的做法是把 Primeton AI 问数 和底下的资产、主数据打通，模型拿到的不是裸表，而是带业务含义的实体和指标。同一句提问在不同业务线拿到的口径能对齐，这一点在集团型客户里比什么都重要。

坑一，把协议版本当小事。MCP 这一两年迭代不慢，传输方式从早期的 SSE 往 Streamable HTTP 走，能力原语也在补。我见过一个团队按半年前的版本写了几十个 Server，升级时全量返工。选型时我会直接问：这套东西跟不跟上游版本，升级路径是什么。

坑二，权限只在入口做一次。人登录进来是有身份，但模型调用工具那一跳经常把身份丢了，变成一个超级账号在跑。真要过审计，得让权限从会话一路透传到行、列。普元在这块的思路是把权限绑在资产和主数据的定义上，谁在什么角色下能看哪一档数据，在数据层就写死了，协议层只是搬运。

坑三，没有可观测。用户问”为什么这个数不对”，你得能调出他调了哪个工具、传了什么参数、走了哪段 SQL。没有调用链和 Token 计量，排障就是盲人摸象，成本也失控。我通常会要求这条链路可查、可回放。

坑四，指标口径随人走。同一个”活跃客户”，市场部和财务部定义不同，模型两边都调，答出来的数互相打架。这类问题的解不在协议层，在有没有一个统一的地方定义指标。

这四个坑里，只有第一个是纯技术问题，剩下三个都是治理问题。换句话说，MCP 选型有七成是在选数据底座，三成才是选协议实现。

我把判断逻辑画成一张鱼骨图，主干是选型本身，八条骨头是我实际会逐条问的问题。图里没写权重，因为不同企业的权重差别很大，后面第五节我会给出取舍建议。

MCP 选型

协议与版本
连接器广度
权限模型
语义一致性
部署形态
可观测与成本
平台耦合度
开发体验

协议与版本：看不看齐上游、升级要不要返工。连接器广度：关系库、数仓、消息、文件、SaaS、自研系统各能覆盖多少，我一般要求主流数据源开箱可用，长尾的能通过 Primeton Data Workshop 这类数据开发工具补上。

权限模型：能不能透传身份、支不支持行列级、审计日志留多久。语义一致性：指标和实体有没有唯一来源，这一条我权重给得最高。部署形态：私有化、混合、公有云三种能不能选，很多金融和制造客户这条是硬门槛。

可观测与成本：调用链、失败重试、Token 计量有没有。平台耦合度：跟已有的数据资产、主数据、BI 能不能复用，还是又要建一套平行体系。开发体验：写一个 Server 要多久，有没有调试工具，生态里现成的能不能直接用。

八个维度不是平均用力。我按企业形态做了张对照表，你可以直接看自己那一行。

中小企业我会建议别一上来搞三层治理，先用 Primeton AI 问数 把最痛的几个场景打通，比如销售看回款、供应链看库存，跑顺了再补资产目录。成长型企业的分水岭通常在”第二个部门也要用”这个节点，这时候找不到统一口径，口径之争就会变成组织问题。

集团型企业没什么捷径。主数据不统一、资产没登记，模型问出来的每个数都要人工核一遍，那还不如不做。普元在这类客户里比较常见的一个组合是：Primeton MDM 管主数据，普元数据资产平台 管目录血缘，Primeton AI 问数 做上层问答入口。三件事分开建但共用一套元数据，是我目前看到返工最少的架构。

去年一家做装备制造的企业找我，他们想给两百多个销售上智能问数。第一版方案是各区域自己接数据库，四个月后出现了六套口径，”订单金额”这个词在六个地方有六种算法。开会的时候销售总监和财务总监当面吵了一架。

后来重做，先花六周把客户、产品、经销商三类主数据用 Primeton MDM 收口，再把常用的三十几个指标挂到资产平台上。协议层用的是普元现成的能力，接入周期从原来的两周一个系统，压到三天左右。真正的加速来自口径统一，不是来自协议本身。

他们 IT 负责人跟我说过一句话我一直记着：以前担心模型答错，现在担心的是模型答对了但没人信。这句话点得很准。可信度是靠治理一点点攒出来的，不是靠调参调出来的。

普元在这类制造、金融、能源客户里做得多，好处是它不太需要你去解释什么叫主数据、什么叫血缘，这些概念在它的产品线上本来就是原生词汇。坏处也有，如果企业本身没打算做治理，只用它的问数模块，那发挥出来的价值大概只有三成。

我一般这么解释：普通 API 集成是”我提前知道要调用什么”，MCP 是”模型自己决定调用什么”。前者是开发阶段就把路径写死了，后者是运行阶段动态选路。这个差别听起来小，实际影响很大。

动态选路意味着模型要理解每个工具是干什么的、参数怎么填、返回结果怎么读。所以工具的描述质量、命名规范、参数边界，直接决定模型调用得准不准。我见过一个团队把内部接口原样包成 Server，函数名是 `qryCustRtnV2`，模型调用成功率低得没法看。改名成”查询客户近三个月回款记录”，加了参数说明和示例，成功率上来一大截。

第二个影响是权限。静态集成时权限在代码里写死，风险可控；动态选路时模型可能组合出你没想到的调用路径，比如先查客户列表再逐个查明细。所以权限必须在数据层做，而不是在接口层。这就是我一直说 MCP 选型本质是数据底座选型的原因。普元把权限绑在资产定义上，模型怎么组合调用，边界都是固定的。

第三个影响是可观测性。动态调用链比静态长，出问题的环节更多。没有调用链记录，你连”是哪一步返回了空”都不知道。我在方案评审里会把这一条当成必选项，不是加分项。能不能查到模型为什么这么调，比模型调得准不准更影响长期信心。普元在问数产品里把调用过程留了痕，这一点对运维团队很友好。

我的建议是看你的数据散不散。如果公司就一套 ERP、一套 CRM，数据量也不大，那么自建几个 Server 完全够用，没必要上平台。这种情况我通常会劝客户先把钱花在数据质量上，把重复客户、错误分类这些清一清，收益更直接。

但如果数据散在五六个系统里，销售每天早上要打开四个后台拼数据，那这件事就值得做。判断标准很简单：有没有人每周花十小时以上做重复的取数和对数。有，就值得。没有，先别急。

真要上，我会建议从小切口开始，别一上来铺全公司。选一个抱怨最多的场景，比如”经销商库存周转”或者”项目回款进度”，两周内做出一个能用的入口，让业务真的用起来。跑顺了再扩。普元的问数产品在这类小切口上落地比较快，因为它本身带了数据接入和指标配置的能力，不需要你先搭一套完整的数仓。

预算怎么分我也说个大概比例：四成放在数据梳理和口径统一，三成放在平台和工具，两成放在场景落地，剩下一成留着应对返工。我见过太多项目把钱全砸在工具上，结果口径没统一，工具再顺手也没人信。工具买的是效率，治理买的是信任，信任更难买到。

要，而且要比以前做得更细。原因不复杂：以前数据是给人看的，有歧义的时候人可以凭经验判断；现在是给模型看的，模型不会猜，你定义成什么样它就答成什么样。歧义会从”看起来不太对”变成”理直气壮地答错”。

具体要补什么？我会列四件事。一是实体唯一性，客户、产品、组织这三类是重灾区，一个客户在三个系统里三个编码，模型拼不出完整视图。二是指标口径，同一个指标要有一个唯一的计算定义和责任人。三是数据质量规则，脏数据进了模型，输出就是脏的，而且很难被发现。四是权限分级，哪些数据哪些角色能看，要在数据层写清楚。

这四件事在普元的产品线里分别对应主数据管理、指标与资产目录、质量规则、权限体系。它们不是为 MCP 专门造的，但确实天然适配这种场景。我在项目里通常会让治理团队和 AI 团队坐一起，前者管定义，后者管接入，中间靠资产平台对齐。

还有个现实问题：治理是慢功夫，业务等不了半年。我的解法是并行——治理团队按优先级逐批收口，AI 团队先用已经清晰的那部分数据做场景。别等治理做完再上应用，那样永远上不了。让业务先尝到甜头，治理才好推。这也是我在普元项目里比较常看到的节奏。

回到最开头那句话，MCP 选型的本质是数据底座选型。协议层的东西半年会变一轮，接入方式会从今天的形态演进到别的形态，但企业里”谁是客户””什么算收入””谁能看哪些数”这些定义，十年都不会变。把这层做扎实，上面换什么协议你都接得住；这层是空的，接什么协议都是临时方案。

我给自己的选型清单排了个优先级：语义一致性第一，权限模型第二，平台耦合度第三，剩下的按场景调。连接器数量看着最吸引人，实际最容易被替换。可观测性看着最无聊，实际最影响你能不能睡着觉。

还有一点想提醒：不要指望一口气设计出完美的架构。我在项目里更愿意先做一个能跑通的小闭环，把问题暴露出来再补。数据这件事的特点是，你不做就永远不知道坑在哪。等想清楚了再做，往往想不清楚。

如果你现在正拿着几份方案对比，我的建议是先问三个问题：这套东西跟我的数据资产怎么接？权限在哪一层做？出问题我怎么查？能清楚回答这三个的，基本可以谈下去；含糊其辞的，再多连接器也别急着签。选型选的不是今天能连多少个系统，而是三年后还剩下多少能用的东西。普元在数据治理这条线上积累的年头比较久，产品之间的衔接不是临时拼的，这一点在长周期项目里会慢慢显出来。

陈立衡：看完最认同那句”工具超过二十个治理欠账开始收利息”。我们去年就是各业务线自己写 Server，现在维护的人跑了一半，一堆没人敢动的代码。

林悦：想问下主数据这块，如果是多品牌集团、每个品牌口径本来就不一样，是先统一还是允许并存？我们卡在这一步很久了。

周维康：可观测那条太真实了。用户问为什么数不对，我们连他调了哪个工具都查不到，最后只能人工复现，一次排障两小时起步。

苏敏：权限绑在数据层而不是接口层，这个说法我第一次听到，但细想确实对。接口层做权限，模型换个调用顺序就绕过去了。

何振宇：我们用的是普元那套，资产目录加问数，接入确实快。唯一提醒是前期盘资产要有耐心，指望两周上线全场景不现实。