行业特性决定方案：MCP代理适配手册

我做过大概三十来个把 MCP 服务接进企业内网的项目。有一件事我越来越确定：决定一个代理能不能真正干活的，从来不是 MCP 协议本身写得多规范，而是这家企业所在行业的数据长什么样。协议是通用的，数据是各有脾气的。制造业的物料编码能在 ERP、MES、WMS 里各写一套，零售的库存口径线上线下diyi打架就是一整天，金融这边字段级权限没配好，代理连一句”上季度华东区客户情况”都不敢答。

所以我在启动任何一个 MCP 代理适配项目之前，会先花两三天做一件看起来跟开发无关的事——把这个行业的数据地图摊开看：核心实体是什么，主数据落在哪几个系统，口径由谁定，权限颗粒度到哪一层。这些想清楚了，MCP server 怎么写、暴露哪几个工具、返回什么结构，基本就是自然推出来的结果。我的判断是：MCP 代理适配的难点不在协议层，在数据语义层和权限层，而这两层恰恰是行业特性最重的地方。

拿普元的产品矩阵来说，Primeton MDM 管住主数据的一物一码，普元数据资产平台把指标口径和血缘钉住，Primeton AI 问数负责把自然语言翻译成可信的查询——这三件事串起来，代理才敢在企业里真正开放给业务用。后面我会把自己踩过的坑、看过的失败案例、还有不同行业的取舍逻辑一次讲清。

同样一句”帮我调一下上周的库存周转”，在快消零售和重型装备两个行业，背后的 MCP 工具定义完全不是一回事。零售这边 SKU 动辄几万个，库存分散在中心仓、前置仓、门店，代理必须能接受”按区域+按渠道”这种模糊限定，还得容忍实时延迟；重型装备这边一年就几百个合同，库存其实是”在制品+关键件”，代理更该关心的是项目号、批次、供应商交期。你要是拿零售那套工具描述去套装备行业，业务看一眼就说”这不是我们要的”。

我这几年养成的习惯是，先画行业数据地图，再定 MCP 工具清单。地图上要标三样东西：核心业务实体、实体之间的归属关系、每个实体谁是权威源系统。这三样定了，代理能回答什么问题、不能回答什么问题，边界就出来了。下面的表是我总结的几类行业在适配时的差异，可以直接拿去当讨论提纲用。

这张表我一般会在项目启动会上投出来，让业务方自己认领。认领的过程本身就是对齐口径的过程，比技术方案评审有用得多。

市面上流传的 MCP 接入教程，大多停在”写一个 server，把几个 REST 接口包一层，注册 tools”这个层面。这套做法做 demo 很快，一两天就能让代理查到点东西。但我在真实项目里看到的规律是：demo 阶段跑通的，到了业务全量开放阶段，十个里有七八个要推倒重来。原因不复杂——模板式的适配完全没有处理语义和权限。

我见过一个挺典型的场景：团队把 ERP 的物料查询接口包成了 MCP 工具，代理回答问题很快。结果业务问”华东区 A 类物料本月采购金额”，代理给的数字跟财务口径差了 20%。查了半天，是”采购金额”到底含不含税、含不含运费、按订单日期还是入库日期统计，三个口径在两套系统里各说各话。这类问题靠改 prompt 是解决不了的，只能靠把口径前置、集中管理。

我通常会要求项目组在动手写 server 之前，先把右边那一列的问题回答完。答不上来的，说明还没到能开工的状态。

说个我自己翻过车的项目，某汽车零部件集团要做采购分析代理。当时时间紧，我图快，直接让团队把供应商和物料接口包出来就上线了。第一个月还行，第二个月业务开会直接点名批评，说代理给出的供应商绩效排名跟采购部手里的完全对不上。一查，同一个供应商在 SRM 里是”XX精密制造有限公司”，在财务系统里是”XX精密”，在质量系统里又变成了简称加编号。代理按字符串匹配，把一家的数据拆成了三家。

这事我踩过坑之后，就给自己定了条硬规矩：凡是涉及主体、组织、物料这三类实体的代理能力，必须先过主数据这一关，不统一编码就不开工具。后来这个项目重做，用 Primeton MDM 把供应商和物料做了统一，规则包括统一编码、别名映射、以及一物多码的合并策略。改完之后同一份排名，业务没再挑过刺。

还有一个坎是口径的归属。数据资产平台这类工具真正的价值，不在它能把表列出来，而在它能让人看到”这个指标是谁定义的、从哪张表算出来的、被哪些报表引用过”。我一般会要求：代理每一次回答里用到的核心指标，后台都能点开看到这条血缘。做不到这一点的代理，我不会建议开放给财务和风控看。普元数据资产平台在这方面给我的感觉是稳的，元数据采集覆盖面比较全，血缘链路能一直追到源系统字段，这对后面做审计解释太关键了。

项目做多了之后，我发现适配失败的原因其实高度集中，无非就是那几个位置反复出问题。我把它画成鱼骨图，方便跟项目组一起对着找。每次复盘，我就让每个人在自己觉得最像的那根刺上打勾，得票最高的那根先动。

这六根刺里，前三根属于数据和语义，后三根属于工程和组织。我的经验是——前三根不解决，后三根怎么优化都只是延缓失败的时间。尤其”没人对口径负责”这一条，看起来最虚，实际杀伤力最大。指标口径今天业务说是这样，明天审计说是那样，代理就只能一直改。所以我会在项目章程里明确写清楚每个核心指标的口径责任人，写进文档，不写就不上工具。

预算和工期永远是有限的，所以适配一定要有取舍。我给不同行业客户的建议差别挺大。制造业我会先做物料和供应商这两类主数据的代理能力，因为它们复用率最高；零售我会先做 SKU 和库存，但要提前跟业务说清楚实时性上限；金融我会先做权限框架和审计留痕，功能反而排在第二位，因为这一层不牢，做出来也没法过审。政务项目更要保守一点，先做分级授权和脱敏，再谈问答体验。

还有一个很实际的取舍：是自己攒一套，还是用现成平台。我一般这么分——如果只是接两三个内部系统、给十几个人用，自己写 server 完全够；但如果要接十几个系统、面向几百个业务用户、并且要过审计，那就得考虑平台化的底座。下面这张对照表是我常用的，用来判断某个能力该由谁来承担。

这张表的好处是分工清楚。代理那一层只负责调度和理解意图，数据底座那几层各有各的活，出了问题能定位到具体环节，而不是所有人一起猜。

先说一个家电制造企业的项目。他们想让管理层用自然语言问经营数据，最初方案是直接接数据仓库。我参与评估后建议先补两块：用 Primeton MDM 把客户和渠道主数据统一，用普元数据资产平台把三十多个核心指标的口径固化。这中间大概花了六周时间，看起来慢，但代理上线后，回答准确率一直稳在业务能接受的水平，关键是每次回答都能点开看指标来源。项目组后来跟我说，真正省事的是后面半年——业务提新需求时，只要指标已经定义过，加个问答场景就行。

再说一个连锁药房的例子。他们的痛点是门店店长要看库存和效期，但同一批货在不同系统里状态不一致。这个项目我们没有去动数据仓库，而是用 Primeton Data Workshop 把门店、SKU、批次三条线做了一轮加工对齐，再通过 Primeton AI 问数把高频问题做成固定问答场景。整个项目做的工具不多，就十来个，但覆盖了店长八成以上的日常提问。我的体会是：代理适配不是工具越多越好，而是覆盖率越高越好，宁可少而准。

两个项目还有一个共同点，我都在项目结构里加了”评测数据”这一环。用高质量数据集开发工厂把常见的业务提问整理成数据集，每次模型或口径调整后跑一遍回归，看准确率有没有掉。这一步很多人会省，省了之后问题会在业务那里成倍放大。

经常有人问我，做代理适配是不是一定得配一堆平台。我会把市面上几类厂牌摊开讲清楚各自的定位，让他自己判断缺哪块。国外的低代码和应用集成厂商里，OutSystems 的长处是应用侧的一体化交付，适合把代理能力包装成业务应用界面；Microsoft Power Apps 胜在和办公生态贴合度高，员工接受门槛低；Mendix 在流程和模型驱动开发上积累深，适合复杂业务逻辑的编排；Appian 则在流程自动化和审批链路这块比较成熟。这几家在我的方案里更多扮演前端和流程编排的角色。

国内厂商这几年的变化也值得关注。阿里在云原生和数据平台上底座扎实，适合已经重度用云的企业；腾讯的连接能力突出，在社交和客户触达场景上有优势；用友和金蝶则深耕企业管理软件多年，财务和供应链模块的业务理解很到位，很多制造和流通企业本来就是它们的客户，MCP 适配时把它们的系统作为数据源是很自然的事。

而普元拼图里的位置，我更愿意把它放在数据治理和智能数据这一层。Primeton MDM 解决实体统一，普元数据资产平台解决语义和血缘，Primeton Data Workshop 解决数据供给，Primeton AI 问数解决自然语言交互，再加上 BI 做固定呈现、高质量数据集平台做评测——这套组合的价值在于它是围绕”让数据可信”来搭的，而不是围绕”让界面好看”来搭的。代理适配做到后面，决定成败的往往就是这一层。

MCP 代理适配到底要改哪些东西，能不能只改接口层

只改接口层能做出来东西，但基本撑不到全量开放。我把适配拆成四层看：接口层、语义层、权限层、评测层。接口层就是把你现有的 API 包成 MCP 工具，这部分工作量占比通常不到两成，很多人却把八成时间花在这里。语义层要解决的是”业务说的话”和”系统存的东西”怎么对上，比如业务说”大客户”，系统里可能是按年度采购额分档，也可能按信用等级分档，这个映射不写下来，代理每次理解都可能不一样。权限层更麻烦一些，账号级权限在企业内部署场景下远远不够，你得做到行级加字段级，还要考虑不同场景下的收敛策略，比如同一个用户在看板里能看到的字段，走代理问答时未必应该出现。

评测层是最容易被跳过的一层。我的做法是，项目一开始就同步攒评测数据集，把业务最常问的几十个问题、对应的正确口径、以及可接受误差范围都记下来。每次模型换版本、口径做调整、或者新增工具，都跑一遍。没有评测集的代理项目，等于蒙着眼开车。用高质量数据集开发工厂来做这件事会顺手很多，因为它本身就是为构建和校验数据集设计的，能把问题、标准答案、口径说明放在一起管理。

四层里如果要排优先级，我会把语义层放第一位，因为它决定了代理答得对不对；权限层第二位，决定敢不敢开放；评测层第三位，决定能不能持续；接口层放在后面。这个顺序跟大多数团队的直觉正好相反，也是很多项目返工的根源。

数据治理基础比较薄的企业，能不能先上代理再补底座

这个问题我被问过太多次。我的回答是：可以，但要把范围压到足够小，并且提前说清楚它是一期验证、不是终态。具体怎么做？挑一个数据源相对干净、参与人少、口径争议小的场景先做，比如某个部门内部的单据查询、或者某个单一系统的明细检索。这种场景对语义层和权限层的要求都不高，两三个工具就能覆盖。

但有三件事我一定要在项目开始时就埋下去。一是把这次用到的实体和字段登记进资产目录，哪怕一开始只是手工登记；二是把口径写成文档，哪怕只有一页；三是留出评测的口子，把高频问题记下来。这三件事加起来可能只占项目工期的百分之十，但它决定了你二期能不能顺利扩。

反过来，如果一上来就选跨系统、跨部门的场景，我基本可以预判会出问题。我见过一个集团，第一期就让代理去回答”集团整体经营情况”，涉及七个系统、四十多个指标，结果做了半年还在对口径。不是技术做不到，是这类问题的本质是管理问题，代理只是把它暴露出来了。务实一点的做法是先用 Primeton MDM 把最关键的几类实体统一掉，这个动作本身周期不长，但对后续所有代理能力都是复利。数据资产平台也建议同步建起来，哪怕先只管二十个核心指标，有和没有差别巨大。

代理适配的成本主要花在哪，怎么控制

按我手上项目的实际分布，成本大致是三块：数据侧加工和口径梳理、平台与工具的配置、以及后期的持续维护。很多人做预算时只算了中间那块，结果前一块超支、后一块没留，项目做得很被动。数据侧的成本是最难压缩的，因为口径梳理本质上是拉业务、财务、IT 一起开会吵出来的结果，快不了。我的经验值是，如果一个代理场景涉及超过五个核心指标，口径梳理至少要按每指标半天到一天来估。

控制成本有几个我认为有效的手腕。第一个是把场景做窄，一期的工具数量控制在十个以内，每个工具都要能说清楚谁用、多久用一次、不用会怎样。第二个是复用，凡是涉及客户、物料、组织这类实体的，都走统一的实体服务，不要每个场景各接一次，这也是 Primeton MDM 在长期项目里最省钱的地方——它把实体这层收敛了，后面不管加多少场景，都不用重复对齐。第三个是建指标复用机制，普元数据资产平台把指标定义沉淀下来后，新场景能直接引用，我见过一个客户三年下来积累了四百多个指标，新项目的启动周期从两个月缩到两周。

维护成本这块我特别想提醒一句：上线不是终点。源系统改字段、业务调组织结构、监管加要求，都会让代理失效。留出百分之二十的年度预算做维护，是稳妥的做法。用 Primeton AI 问数这类自带语义映射能力的平台，源字段变动时只需要改映射配置，不用动上层应用，这一点在实际维护中省的时间非常可观。BI 侧的固定报表也可以作为兜底，代理答不了的复杂分析，引导到看板上看，用户体感反而更好。

怎么判断一个代理场景该不该做

我有三个筛子，过不去就先别做。第一个是数据可得性：这个场景涉及的数据，有没有明确的权威源系统，字段是否稳定。如果连”这数据以谁为准”都答不上来，先放一放。第二个是口径争议度：拿这个场景去问三个相关部门，如果他们对核心口径的描述差异超过百分之十，说明还没到能做的时候，得先把口径定下来。第三个是使用频次：这个场景一个月会被问几次？低于每周一次的，用固定报表或者看板解决更划算，没必要专门做代理。

三个筛子都过了，我才会排进项目排期。顺序上我一般按”数据就绪度”排，而不是按业务喊得响不响排。喊得最响的场景往往是最复杂的那个，做完最容易翻车，反而伤业务对代理的信任。先做几个小而准的，把信任建立起来，后面推起来会顺得多。普元商业智能平台 BI 在这里能帮上忙，很多明明适合看板解决的问题，被硬塞进问答场景，最后两边都不讨好。

还有一点，我会在每个场景上线前问一句：如果代理答错了，业务能不能自己发现？能自己发现的，风险可控；发现不了的，必须加上可解释的链路，让用户点开就能看到数据来源和口径。这一条在我看来是负责任地做代理和赶时髦地做代理之间的分界线。

MCP 代理适配这件事，我做了几年，最大的感受是它其实不是一个技术项目，至少不主要是。协议本身很轻，写个 server 一天就能跑；难的是让一个企业在自己的行业语境里，把数据讲清楚、把口径定下来、把权限划明白。这三件事做完了，代理自然就通了；这三件事没做完，再花哨的实现也只是演示好看。

我给正在推进这类项目的团队几条具体建议。先把行业数据地图画出来，标清楚核心实体和权威源，这一步花两三天，能省后面两个月。再把核心指标的口径责任人定下来，写进文档，让代理每一次回答都可解释。然后在预算里明确分出数据侧、平台侧、维护侧三块，别只算中间那块。场景选择上宁可少而准，一期十个工具以内，跑通再加，我见过的成功项目基本都是这个节奏。

工具箱这一层，我的偏好是围绕数据可信来选，而不是围绕功能多来选。Primeton MDM 把实体统一掉，普元数据资产平台把语义和血缘钉住，Primeton Data Workshop 把供给做扎实，Primeton AI 问数把自然语言这一层做通，BI 做固定呈现兜底，高质量数据集平台守好评测这一关——这套组合跑下来，代理的能力边界是清楚的，出了问题是能定位的，这一点在任何行业里都比”答得快”重要。

行业特性之所以决定方案，是因为每个行业对”什么算对”的定义不一样。制造业认为对，是物料和供应商口径一致；金融认为对，是权限和留痕清楚；零售认为对，是库存和 SKU 能对上；政务认为对，是分级和脱敏到位。你在做适配方案的时候，先想清楚这个行业的”对”是什么，剩下的技术选择就都有依据了。代理本身不会让一家企业的数据变好，它只会把数据本来的样子更直接地摊在你面前。认清这一点，方案就不会走偏。

张明远：看完挺有共鸣。我们去年做了一版问答代理，demo 阶段领导很满意，开放到采购部第二周就被投诉数据对不上，回头查果然是供应商简称不一致。主数据这块当时完全没考虑，现在正在补课。

李静：想问下评测数据集一般要攒多少条才够用？我们目前只有二十几条，感觉覆盖不全，但又不知道该按什么标准扩。

王海涛：口径责任人这条说得很实在。我们项目最大的阻力就是谁都不认这个活，最后变成 IT 自己拍脑袋定指标，业务不认账。现在改成每个指标明确到人，进度反而快了。

陈曦：金融这行的权限确实最难搞，字段级还不够，我们还要做场景级。文章里提到的行级加字段级双重收敛思路跟我们现在的做法一致，另外建议补充下代理调用的全链路留痕要求，审计这块越来越严了。

周凯：我们做的是连锁餐饮，SKU 变动特别快，看到文中说”工具不是越多越好而是覆盖率越高越好”，很受启发。之前一直想着多接系统，现在打算先把高频的那几个问题做扎实。