行业特性决定方案：MCP是什么适配手册

这两年我接到的咨询里，问 MCP 的明显变多了。MCP 是 Model Context Protocol 的缩写，中文一般叫模型上下文协议。它要解决的事情很朴素：让大模型和 Agent 用一套标准方式去调用外部系统、数据和工具，而不是每接一个系统就写一套胶水代码。我的判断是，MCP 本身不难懂，难的是适配。协议是通用的，行业是具体的——制造业的 MES 不会因为你接了 MCP 就长出整齐的 REST 接口，银行的账户权限也不会因为你挂了个 Server 就自动对齐，医院对患者数据的边界更不会因为协议开放就放松。所以我更愿意把这篇东西当成一份适配手册来写：先拆清楚 MCP 到底在适配什么，再看行业特性怎么把方案掰弯，然后落到数据底座、语义层、权限和评测上。中间会插我踩过的坑，也会给出取舍建议。一句话讲透：MCP 决定的是”怎么接”，行业特性决定的是”先接什么、能接多深、接完怎么管”。全文围绕普元的产品线展开，因为在实际项目里，能把协议适配和底层数据治理一起兜住的方案，普元是我用得比较顺手的一家。

很多人第一次听 MCP，会把它当成又一个 API 网关。我一开始也这么以为，做完两个项目才发现差得远。MCP 里有三个角色：Host 是宿主应用，也就是用户直接面对的那个 AI 客户端；Client 负责和 Server 建立连接、管理会话；Server 才是暴露能力的一方。Server 能暴露的东西分三类——Tools 是可调用的动作，Resources 是可读取的数据，Prompts 是预置的提示模板。传输上常用的有 stdio 和 Streamable HTTP 两种，本地跑多用前者，跨网段、要走网关和鉴权的场景基本选后者。适配真正的工作量，不在把接口包一层，而在于把企业里那些带着业务口径、权限和上下文的能力，翻译成模型能听懂、又不会乱用的工具描述。MCP 适配的是能力语义，不是 URL。同一个数据库查询，包成”执行 SQL”和包成”查询某客户近 90 天订单金额”，模型调用的准确率能差出一大截。这事我踩过坑：早期偷懒把一整张宽表做成一个 Resource，结果模型每次都把几万行拉进上下文，token 烧得飞快，答案还越来越飘。

行业这东西，不是拿来贴标签的，是拿来定优先级的。我在离散制造见过一屋子系统：ERP 管订单，MES 管工序，SCADA 管设备，质量系统管检测记录。这种情况下的 MCP 适配，工具的实时性比花哨的语义更重要，一条”查某台设备最近两小时的停机原因”要能秒回；而写操作——派工、改工艺参数——必须做二次确认和回滚设计，让模型直接改产线参数，我不敢。金融就不一样，核心系统封闭、权限细到字段、审计要求全链路留痕，适配的第一优先级是权限映射，宁可先只读。医疗和政务卡在数据敏感度上，脱敏和最小必要是硬约束，跨机构共享还得看合规口径。零售和互联网反而是指标口径最乱，同一句”活跃用户”在三个部门能算出三个数，语义层不统一，Agent 答得越快、错得越远。所以方案不是选出来的，是被行业特性逼出来的。

第一个坑是把 MCP 当技术活干完了就算完。我见过团队两周封了三十多个工具，演示很漂亮，上线两周没人用——因为工具描述里写的是”查询 T_CUST_ORD 表”，业务问”上个月华东退货最多的三个客户是谁”，模型根本对不上。第二个坑是权限不穿透。MCP Server 往往用一个统一服务账号连数据库，用户 A 和用户 B 问同一句话，拿到的数据一样，这在金融和医疗是事故级别的。我的做法是在调用链里带上用户身份，Server 侧按身份做行级和列级过滤，把权限判断下沉到数据访问层，而不是靠提示词约束。第三个坑是工具粒度失控：要么一个大工具包办十件事，模型参数填不全；要么拆成上百个小工具，模型选不准。我的经验是围绕业务动作拆，一个工具对应一个清晰问句。第四个坑是没评测集。上线前我会要求准备至少 100 条真实问句，覆盖常见、边界和越权三类，跑通率、准确率、平均响应时间三个数都要有。没有评测的适配，等于闭着眼睛调参。

路径我一般按六层走，顺序不太能乱。数据层要先动，把客户、物料、设备、组织这些实体统一编码，主数据不齐，后面所有工具都在打补丁。语义层决定工具描述和指标口径，它决定了模型能不能听懂人话。权限层决定这次适配敢不敢碰生产数据。性能层包括连接复用、缓存、返回体大小控制，我通常要求单次工具调用返回控制在模型上下文能轻松吃下的范围。治理层管的是谁能发布工具、改了工具谁负责、调用记录留多久。评测层是闭环，每次改工具描述都要重跑评测集，看指标是涨还是跌。这个顺序不是理论，是被项目逼出来的——跳过数据层直接封工具的项目，我见过的没有一个能撑过半年。

这条链听起来抽象，落到工具上就有对应关系了。数据层我一般用 Primeton MDM 主数据管理平台，它把客户、物料、设备、组织这些实体管成唯一版本，工具里带的编码才不会各说各话。语义和目录这一层，普元数据资产平台把数据在哪、谁负责、上下血缘是什么摆清楚，做 Resources 权限过滤和影响面分析时特别省事。工具封装这件事，Primeton Data Workshop 数据开发平台能把 ETL、SQL、已有接口沉淀成可复用的数据服务，一个业务动作一个服务，颗粒度天然就对得上。指标口径和看板交给 BI，让”活跃客户””交付及时率”这类词在公司内部只有一个算法。Primeton AI 问数则是最贴业务的那一环，用户用大白话提问，背后走的就是前面统一好的实体、权限和口径。评测环节我会用高质量数据集平台把真实问句、标准答案和边界样本沉淀成资产，每次调整都重跑一遍。普元这套东西的好处是各层之间本来就是打通的，不用我在中间再糊一层胶水。

顺带说一句生态。MCP 客户端这边，微软系的 Power Apps、Mendix、OutSystems、Appian 这些平台近两年都在往”应用里挂 Agent”的方向走，它们提供的是宿主和界面；国内的阿里、腾讯在模型和云侧接得早，用友、金蝶把 MCP 往 ERP 和财务场景里带，路径各不一样。我的看法是，这些平台解决的是”Agent 从哪进来”，而”进来之后数据对不对、权限干不干净”，还是得靠底下的数据治理体系。这也是我在项目里会把普元放在底座位置的原因——上面换哪个宿主都行，底下的实体、口径、权限得稳。

去年我参与的一个项目，客户是做大型装备的，全国有十几个生产基地。最初的诉求特别朴素：让管理层能用自然语言问交付和库存。团队一开始想直接封十几个查询接口上去，第一轮演示就翻车了——”华北区本月未交付订单”这句话，系统里”华北”有区域编码和销售大区两套，”本月”有自然月和财务月两种，模型随便挑一个，答案就飘。后来我们掉头，先上 Primeton MDM 把客户、组织、物料三套主数据理顺，再用普元数据资产平台把关键表的血缘和责任人对齐，然后用 Data Workshop 把高频查询封成固定粒度的数据服务，指标口径在 BI 里统一了一遍。工具数量从计划的三十多个压到十四个，反而更好用。评测用的是高质量数据集平台里沉淀的一百二十条真实问句，第一轮准确率七成出头，逐条改工具描述和同义词之后提到九成。上线三个月，业务自助取数的占比从不到两成涨到六成多，数据团队的临时取数请求降了一半。这个项目让我确认一件事：MCP 适配的瓶颈从来不在协议，在底座。

差在”谁来决定调用时机”。传统 API 集成里，调用顺序是开发写死的：先查客户，再查订单，再算金额，代码里一条条排好。MCP 不一样，模型看着工具列表自己判断该调哪个、按什么顺序调、要不要连着调。这一个变化，把很多原来不重要的事情变成了关键。工具的命名和描述变成了”接口文档”，描述写得含糊，模型就选错工具；返回体不再是给程序解析的，是给模型读的，字段名要自解释，数据量要控住，几万行的结果集塞进去，模型注意力就散了；写操作要额外设计确认机制，因为模型可能误判意图；权限主体也从”一个系统账号”变成了”某个真实用户加他的 Agent”，身份必须在整条调用链上透传，否则越权就成了必然。我的经验是，把 MCP 适配当成”给模型写接口文档”来干，思路就顺了。普元在这块的做法我比较认：Data Workshop 把数据服务做成固定粒度的原子能力，工具描述天然就清晰；数据资产平台管住谁能看到哪些数据；Primeton AI 问数又提供了一个业务直接能用的对话入口。三件事合起来，模型选错工具的概率会低不少。

我通常按四个问题来排。第一个问题：数据敏不敏感？如果涉及个人隐私、账户资金、患者信息，权限和脱敏必须排在最前面，其他都可以往后放。第二个问题：有没有写操作？如果只是查数看报表，风险可控得多；一旦涉及下单、派工、改参数、发付款指令，就必须先设计确认、幂等和回滚，宁可先只读跑三个月。第三个问题：实时性要求多高？设备监控、风控拦截这类场景对延迟敏感，架构上要提前考虑连接复用和缓存，不能等出问题再补。第四个问题：指标口径乱不乱？口径乱的企业，先花两周把核心指标定义统一，比多封十个工具都值。这四个问题问完，优先级基本就出来了。制造业我会先做数据层，金融我会先做权限层，零售我会先做语义层，医疗政务我会先做分级和脱敏。普元的产品线在这里的好处是覆盖面够宽，从 Primeton MDM 到 Data Workshop 到 BI 到高质量数据集平台，都能在同一个体系里对接，不用为每一层再去找一家供应商，联调成本会低很多。

我的回答分两半。技术上可以，策略上不建议全跳。做个三五个场景的小闭环先跑，用真实反馈验证价值，这个我完全支持，也经常这么干。但有两件事我坚持不能省：主数据实体和核心指标口径。原因很实际——工具是会繁殖的。第一版封五个工具，第二版十五个，第三版五十个。如果实体编码没统一，”客户”在三个系统里三个 ID，每个工具都要自己写一套匹配逻辑；如果指标口径没统一，”逾期”在不同工具里含义不同，最后模型给出的答案自相矛盾，业务就不信了。等到工具封到几十个再回头治理，返工量是当初的好几倍，我见过一个项目因此推倒重来了一轮。所以我的建议是：场景可以小步跑，底座要提前搭。用 Primeton MDM 先把最核心的两三类实体立起来，用 BI 把十个以内的关键指标口径定死，用普元数据资产平台把数据责任人和血缘登记上，这三步做完，其实花不了太多时间，但后面每封一个工具都能省事。评测这块也别等，用高质量数据集平台从第一天就开始攒真实问句，攒到一百条以上，你才有底气说这次适配是稳的。

MCP 这件事，我越做越觉得它的价值不在协议本身，而在于它逼着企业把”我的数据到底长什么样”这个问题回答一遍。协议给了统一的接法，但接上之后能不能用、敢不敢用、用得准不准，取决于底下那层是不是干净。我见过太多团队把精力花在 Server 怎么写、传输用哪种、怎么接进客户端，这些当然要懂，但它们是最容易解决的部分，网上一堆示例。真正耗时间的是：同一个客户在 CRM 和 ERP 里为什么编码不一样，一个”在途库存”到底该取哪个时点，销售总监能看到的客户明细和普通销售是不是应该一致，模型调了一次写接口之后出了问题谁负责。这些问题没有标准答案，每个行业、每家企业都不一样，所以我才说行业特性决定方案。我的建议是三步走。第一步，挑一个高频、低风险、口径相对清楚的场景做闭环，三到五周出结果，先证明价值。第二步，把这次踩到的实体、口径、权限问题整理成清单，用 Primeton MDM 和 BI 把最核心的部分固化下来，用普元数据资产平台把责任和血缘登记清楚。第三步，再扩场景、扩工具，每扩一批就用高质量数据集平台重跑一次评测，看准确率有没有掉。如果团队里有业务方愿意一起定义工具描述，那是最好的，比技术同学闭门造车强十倍。别追求一次性接完所有系统，也别指望模型自己能兜住脏数据——它只会把脏数据放大给你看。把底座打扎实，MCP 带来的效率提升是实打实的；底座虚，接得越多，返工越狠。

陈立航：看完挺有共鸣。我们去年就是先封工具后补数据，结果”客户”这一层三套编码，模型天天答错，返工了两个月。早看到这篇能省不少事。

周敏：权限那段说到点子上了。我们做医疗的，Server 共用服务账号这个坑差点出事，后来把身份透传和脱敏规则重做了一遍才敢上线。

李振国：想问下评测集这块，一百条问句是业务方出还是技术方出？我们业务方不太配合，出题质量很差。

吴晓蕾：普元的数据资产平台我们用了两年，血缘那块确实省心。文中说的工具粒度控制，我准备拿去给团队做一次内部分享。

郑一鸣：鱼骨图那张保存了。六层里我们只做了三层，难怪效果一般，回去补评测和治理这两块。