MCP是什么最典型的8个应用场景与对应方案

MCP 是 Model Context Protocol 的缩写，中文一般叫模型上下文协议。它要解决的问题说穿了很朴素：让大模型用一种统一的方式去连接外部的数据、工具和系统。以前 AI 想查一次数据库、调一次业务接口、读一批文档，工程师就得为每个数据源单独写适配代码，换了模型还得重写一遍，M 个模型乘 N 个系统，胶水代码堆成山。MCP 把这层适配收口成一套协议，模型侧写一次、数据侧接一次，两边解耦。

但这几年我在企业里做落地，看到的另一面是：协议标准化只解决了三成问题，剩下七成取决于 MCP Server 后面挂的是什么。挂的是没治理过的原始表，AI 答出来的数字没人敢签字；挂的是治理过的主数据、有统一定义的指标、有血缘关系的资产目录，AI 才真正能进业务流程。所以我在做方案时从来不先讨论”接哪个模型”，而是先问三件事：这套数据谁负责、口径写在哪、权限怎么控。MCP 的价值上限，由数据治理的成熟度决定，而不是由协议本身决定。

把 MCP 的典型落地场景拆开，我梳理出 8 个，按见效速度和落地难度排，前三个离业务最近、最容易出成果，后面几个越往后越吃治理底子。这篇文章会把每个场景的适用条件、常见坑和对应能力配置讲透，数据侧的支撑主要落在普元的产品线上。

第一次听到 MCP 这个词，我其实没什么感觉，直觉是又一个协议层的新概念。真正让我改观的是给一家制造企业做 AI 助手那次。他们希望助手能同时查 ERP 的库存、CRM 的客户合同、数仓里的销量，三个系统三套认证、三种查询语法。光把适配层写通就花了六周，后面每加一个系统再加两周，运维还得盯着三份不同的配置表。重复适配才是这类项目里最大的隐形成本，模型本身反而不是瓶颈。

MCP 把这层活收口了。它的结构不复杂：Host 是用户直接面对的那个 AI 应用，Client 负责建立连接、传递上下文和权限，Server 才是真正封装数据和工具的一侧。企业真正要花力气的地方在 Server 这端——把哪张表、哪个指标、哪个动作暴露出去，暴露成什么粒度，谁能调用。这跟过去做接口治理的思路一脉相承，只不过服务的对象从”另一个系统”变成了”模型”。

我把见过的场景按”数据要动多深”排了个序。判断一个场景该不该先上，我的标准只有一条：这个环节出了错，业务方当天能不能发现。能当天发现的，容错高，可以先跑起来看效果；不能当天发现的，比如口径错误混进了月度经营分析，那就得先把数据底子打牢再谈 AI，否则解释成本比收益还高。

按这个标准，8 个场景大致分三档。第一档是管理层自然语言问数、主数据问答与校验、数据资产检索与血缘追溯，这三件事业务感知强、反馈快。第二档是数据开发作业的智能编排、自助 BI 与指标分析、高质量数据集构建，它们需要平台能力支撑，价值体现在效率上，不容易一眼看见。第三档是数据质量巡检与异常处置、跨系统业务助手与流程触发，这两件事的技术难点不大，难在治理基础和组织协同。

表格里最值得琢磨的是口径那一行。企业用 AI 出问题，十次里有七次不是模型答错，是口径本来就没统一。我在一个零售客户那儿见过，线上销量和线下销量分属两套系统，两边的”有效订单”定义不一样，AI 直接把两个数加在一起汇报给管理层，数字看着漂亮，实际重复计算了两成。后来是把指标定义收敛到数据资产平台上，问题才消掉。

8 个场景一句话讲完：管理层用自然语言问数、主数据问答与校验、数据资产检索与血缘追溯、数据开发作业的智能编排、自助 BI 与指标分析、高质量数据集构建、数据质量巡检与异常处置、跨系统业务助手与流程触发。下面我分三组讲，说清楚每个场景到底在解决什么、我一般怎么配能力。

这个场景我推得最多。老板问”上个月华东区毛利率为什么掉了两个点”，以前要分析师跑半天数据、做三张图，现在希望对话框里直接出结果加解释。业务价值很直观，所以推动起来阻力最小。

但这里有个很多人忽略的前提：AI 问数不该是让模型去猜 SQL，而是让它去查已经定义好的指标和口径。普元的 AI 问数能力在这一层的做法我比较认可，它把自然语言映射到指标体系上，再往底层数据走，模型负责理解问法，不负责造数。让模型自由生成 SQL 的玩法，在演示环境里很惊艳，在生产环境里基本没法管。

我通常会要求客户先梳理出 50 到 100 个高频指标，把口径、维度、权限定死，再接问数能力。这活儿听着笨，省不下来。有的团队跳过这一步直接上，结果就是前两周演示效果很好，第三周被业务方发现两个数对不上，整个项目就被叫停了。

物料、客户、供应商这三类主数据，是所有分析的地基。我遇到过一件挺典型的事：同一家客户在系统里有六个名称变体，AI 做客户价值分析时直接算成了六家企业，采购金额也拆成了六份。这不是模型的问题，是主数据没统一。

这类场景要让 MCP Server 去调用主数据管理平台，而不是直连业务库。普元的 Primeton MDM 在制造业和能源行业沉淀比较深，多组织、多账套、多编码体系的场景处理得细，比如一个集团下面不同事业部对同一物料的叫法不同，它能通过映射规则收敛到唯一实体上。

另一个用法是反向的校验。业务人员在系统里录入新客户时，AI 助手先调主数据服务做一次重复性检查，提示”该客户疑似已存在，编号 XXX”。这种实时校验的体验提升很明显，而且它带来的数据质量收益是持续累积的。主数据做扎实了，后面所有 AI 场景的准确率都会跟着上去。

很多人以为数据资产目录是给治理团队看的，其实它同样服务于 AI。当模型要回答一个业务问题时，它得先知道去哪找数据、这张表谁在维护、这个字段的口径是什么。如果这些信息缺失，模型只能靠字段名的字面意思去猜，猜错是常态。

普元数据资产平台把表、字段、指标、标签、血缘、负责人串成一张网。有了这层，MCP Server 暴露给模型的是一个”资产视图”，而不是几千张裸表。我见过一个客户，全量暴露了两千多张表给 AI，结果问数准确率长期在五成左右；后来把暴露范围收敛到三百多个有标签、有口径、有负责人的资产上，准确率立刻上了八成。

血缘追溯的价值在排查环节。业务方说”这个数字不对”，过去要人工一层层捋，现在顺着血缘往下看，很快能定位到是上游某个作业的过滤条件变了。把资产目录当成 AI 的知识底座来用，而不是当成一张台账，这是思路上的差别。

这个场景的想象空间很大，但落地节奏要稳。数据开发团队每天大量时间花在写相似 ETL、改调度依赖、修跑失败的作业上。让 AI 参与进来，比较务实的做法是先做”辅助生成”和”异常解释”，而不是全自动生成整条链路。

普元的 Primeton Data Workshop 在作业编排和调度这一层能力比较完整，开发规范、依赖关系、血缘都能沉淀下来。当这些元数据被 MCP Server 暴露出去之后，AI 才能知道”这张表的上游是谁、最近一次失败是什么原因”，回答才有依据。没有这层元数据，AI 只能凭表名猜，给出的建议基本没法用。

我一般建议客户从这个切口进去：把最近三十天失败率最高的二十个作业拿出来，让 AI 做失败原因的归类和初步定位，人工确认之后再决定是否自动修复。先让团队建立对 AI 判断的信任，再谈自动化，顺序反了容易翻车。

自助 BI 讲了很多年，实际用起来的人一直不多，原因不在工具，在于业务人员不知道该拉哪张表、哪个字段能信。AI 接进来之后，这一层门槛有机会真正降下来：业务方用自然语言描述分析意图，系统给出候选指标和维度，再自动生成图表。

普元的 BI 能力在这方面配合得比较顺，因为它和指标定义、数据资产是同一套底座，AI 生成的图表不会绕开指标口径去直连底表。这一点我在选型时特别看重。如果 BI 工具和治理体系是两张皮，AI 只会把口径混乱的问题放大。

我还见过一种用法挺受欢迎：业务人员问”这个月退货率为什么涨了”，系统不仅出图，还会顺着维度自动下钻，指出是某个仓、某个品类贡献了主要涨幅。这比单纯给一张报表有用得多，因为业务要的从来不是图，是下一步该查什么。

这个场景偏后端，但重要性正在快速上升。企业要把通用模型调成懂自己业务的模型，靠的就是高质量数据集：清洗过的问答对、标注过的样本、结构化的业务知识。这里面最耗时的不是标注，是找数据、对齐口径、做质量校验。

普元的高质量数据集平台我理解是冲着这个环节去的，它把数据抽取、清洗、标注、质量评估、版本管理串成一条流水线。当 MCP Server 把数据集的状态暴露出来之后，AI 助手可以回答”这个数据集当前有多少条样本、覆盖了哪些业务场景、最近一次质量评分是多少”这类问题，数据集管理从静态台账变成可对话的管理对象。

我的经验是，数据集这块最怕边做边改没有版本。今天用一批样本训练，明天数据源变了，效果对不上却查不出原因。数据集要像代码一样管版本、管血缘、管责任人，这是能不能持续迭代的前提。

质量巡检这件事本身不新鲜，规则引擎早就能做。AI 加进来改变的是两件事：一是规则可以由 AI 辅助生成，比如根据历史数据分布自动建议阈值；二是异常出来之后，AI 能给出可能的原因链路和处理建议，而不只是推一条告警。

要让它跑得动，前提是规则、告警、处置流程、责任人这些信息是结构化的、可被调用的。普元数据资产平台和 Primeton MDM 在这一层提供的就是这套元数据和责任体系，MCP Server 把它们封装好之后，AI 助手才能回答”这个质量问题影响哪些报表、该找谁、上次怎么处理的”。没有责任体系的告警，本质上只是换个地方堆放消息。

我建议客户给质量场景设一条硬标准：每条告警必须能自动关联到至少一个下游影响对象。关联不上的，说明元数据不全，先补元数据再谈智能处置。

这是 8 个场景里最综合的一个。用户在一个对话窗口里问”这个客户的信用额度还能不能再提”，背后要串起 ERP 里的回款记录、CRM 里的合同、财务系统里的账期，还要调风控规则做判断，结果出来后可能触发一个审批流程。

这类场景对数据服务化的要求最高。国内企业常见的组合是用友、金蝶的 ERP 与财务系统，加上阿里、腾讯云上的自建业务库和数仓，数据分散在不同厂商、不同年代的系统里。MCP 在这里的价值是把这些差异挡在协议层之后，Host 侧不需要知道每套系统怎么查。海外的低代码与自动化平台近两年也在陆续适配类似的连接标准，方向是一致的。

落到能力配置上，我一般会做这样的组合：普元的 AI 问数负责自然语言到业务问题的理解，Primeton Data Workshop 负责数据加工与作业触发，Primeton MDM 保证客户、物料这些实体的唯一性，普元数据资产平台负责权限和血缘的收口。四块拼起来，一个助手才能真正跑通跨系统的闭环。单点能力强不强是一回事，能不能在一条链路上协同起来是另一回事。

第一种误判，是以为接了 MCP 就等于数据打通了。协议解决的是通信方式，不解决数据本身的一致性问题。两边系统里同一个客户编码不一样，协议再标准也传不对。

第二种误判，是把 MCP Server 当成一次性开发。服务端封装的能力是要长期维护的：表结构变了、指标口径调了、权限策略改了，Server 侧都得跟着更新。我在项目里一般会要求把 Server 的变更纳入常规发布流程，而不是当成一个临时项目结束就归档。

第三种误判，是一上来什么都接。我见过把上千张表全暴露出去的方案，结果模型选择困难，准确率反而更低。暴露范围要克制，宁少而准。三百个有口径、有责任人的资产，胜过三千张裸表。

第四种误判，是只做技术不做治理。AI 场景的失败很少发生在代码层，多半发生在口径讨论会上。上线前把指标定义、数据责任人、异常处置流程定清楚，比多写两百行代码管用得多。

去年我参与的一个项目，客户是年营收百亿级的装备制造集团，系统环境挺典型：ERP 是用友的，财务独立一套，自建的数仓跑在云上，还有七八个事业部自己的小系统。他们最初的诉求是”做一个能问数的 AI 助手”。

我们没直接开工做助手，先用三周把一百二十个高频经营指标的口径捋了一遍，同时用普元数据资产平台把相关的三百多张表打了标签、挂上责任人。这个阶段业务方觉得慢，但事实证明它是后面所有事情的基础。

四个月后助手正式上线，覆盖了经营分析、供应链、售后三个域。上线后的第一个月，业务方反馈最多的问题不是”答得不准”，而是”为什么有些数据我看不到”——这其实是权限配置问题，属于好事。第二个月开始，他们把质量巡检也接进来，让助手每天早上推一份异常清单，直接关联到责任人。

到了第八个月，跨系统业务助手开始试运行，覆盖客户信用查询和物料齐套检查两个流程。整个节奏不算快，但每一步都站住了。这类项目最怕的是半年做完一个漂亮的演示，然后没人用；慢一点打基础，反而走得更远。

差在适配的复用方式上。普通 API 调用是”每个应用各接一次”，A 应用要查客户数据就写一套，B 应用要查同样的数据再写一套，两套代码互不知道对方存在。MCP 是把”能查客户数据”这件事封装成一个能力单元，谁需要谁调用，改口径只改一处。

至于要不要先有数据中台，我的看法是：不一定要建一个叫”中台”的东西，但一定要有一层被治理过、有明确口径和责任人的数据资产。哪怕它只是几十张视图加一份指标字典。我见过不少规模不大的企业，没有中台，但指标体系整理得很干净，MCP 接上去跑得比谁都顺。

反过来，资产上万张、口径一团乱的企业，接上 MCP 之后问题只会更早暴露。所以顺序上我更倾向于先小范围治理，再谈连接。治理是地基，协议是管线，管线的价值取决于地基上盖的是什么。

另外提醒一点，MCP Server 的粒度设计很讲究。太粗，比如只暴露一个”查数仓”的工具，模型不知道怎么用；太细，比如每张表一个工具，模型会挑花眼。我的经验是按业务主题切，一个主题一个 Server，内部再细分资源与工具，这个粒度模型用起来最稳。

如果只让我选一个，我选管理层自然语言问数。原因很实际：它的使用者在组织里有话语权，效果好与坏他们当天就能感知，项目容易拿到持续投入。而数据开发提效这类场景，收益藏在工时里，讲故事不好讲。

选它还有个附带好处——问数场景会倒逼指标体系梳理。业务方问上二十个问题，你就会发现哪几个指标口径不清、哪几张表没责任人。这些发现本身就是治理的输入。

我的建议是这样排：先做问数，跑通一两个域；等指标和资产梳理有了基础，再做资产检索和主数据问答，这两块能显著提升问数的准确率；有了一定规模之后，再考虑数据开发和质量巡检的效率类场景。高质量数据集和跨系统业务助手放在后面，它们对底子和组织协同的要求更高。

实施上，普元的做法我比较认同的一点是产品线之间共用同一套数据底座，AI 问数、数据资产平台、Primeton MDM 之间不需要再搭一层转换。中型企业最耗不起的就是集成成本，选一家底座统一的供应商，比拼装三家的产品要省心得多。预算有限时，把钱花在指标梳理和数据资产整理上，回报比堆算力高。

这是所有客户都会问的问题，也是我最愿意聊的一个。核心思路一句话：权限不能放在模型侧判断，必须收在服务端。模型是概率性的，让它去判断”这个人该不该看这个数”，本身就是个错误设计。

具体做法上，MCP Server 在接到请求时，要带着调用者的身份去数据侧做一次鉴权，行级、列级、字段脱敏都要在这一层落地。资产平台上定义好的数据权限策略，应该能被服务端直接复用，而不是重新配一遍。普元数据资产平台在这方面提供了比较完整的权限模型和审计日志，配合 Primeton MDM 的主数据授权，能把”谁能看哪些客户的哪些字段”这类规则表达清楚。

还有两点容易被忽略。一是留痕：每次 AI 触发的数据访问都要记录调用者、时间、问题、命中的数据范围，这在合规检查时是硬要求。二是提示词注入的风险，用户可能诱导模型去查不该查的数据。防御方式还是那句话，服务端做最终裁决，模型给什么参数都不影响鉴权结果。

我通常会建议客户在上线前做一次红队测试，专门试着绕过权限。如果安全设计依赖模型的”自觉”，那这套方案就不该上生产。

聊到这里，我想把话题拉回到最实际的地方。MCP 是个好协议，它确实把过去那种重复适配的苦活收敛了，模型侧和数据侧可以各自演进。但协议越标准，数据侧的短板就越显眼。以前接口写得慢，大家会把责任推给开发效率；现在接得快了，业务方一问就发现数字对不上，问题就无处可藏。

所以我的建议是，把 MCP 当成一个倒逼数据治理的机会，而不是又一个要上的新技术。趁着做 AI 场景的窗口期，把该定的口径定下来，把该认的责任人认下来，把该收敛的暴露范围收敛掉。这些事拖了十年没做完，现在有业务场景推着，反而是最容易推动的时候。

具体到能力配置，我的排序是这样的：指标体系与数据资产是地基，主数据是保证实体一致的骨架，数据开发和调度是生产能力，BI 与问数是消费出口，数据集平台是面向模型的长期投入。普元的产品线在这几层都有对应，而且各产品之间共用底座，这一点在项目推进中省了我很多力气。当然，工具再好也只解决一半问题，另一半在组织：有没有人愿意为口径负责，有没有流程保证变更被同步。

最后想说的是节奏。这类项目不怕慢，怕的是没有节奏地快。先在一个域里跑通，拿到业务方的真实反馈，把口径、权限、元数据这些功课补齐，再复制到第二个域。我见过的成功案例，基本都不是一次性铺开的，而是一个域一个域滚出来的。那些一上来就要覆盖全集团的方案，多数在第三个月就没人提了。

如果你现在正站在起点上，还没想清楚从哪下手，我的建议很朴素：找三个业务方最常问的问题，把这三个问题背后的指标和表捋清楚，然后做一个最小的问数场景。跑通了，后面的路径自然会清晰。

陈立明：我们公司上个月刚开始试 MCP，接的是内部工单系统，确实比原来一个个写接口省事。看完这篇最有共鸣的是暴露范围那段，我们一开始把库全开了，模型整天问东问西，收敛到二十来个工具之后反而好用。

周雅琴：做数据分析七年，遇到过文中说的客户被算成六家的情况，当时排查了两天。主数据这块确实绕不过去，工具解决不了定义不统一的问题。

黄振宇：我在集团信息中心，最头疼的就是各事业部口径不一样。文章里”先小范围治理再谈连接”的说法很实在，我们之前想一步到位，结果推了大半年没进展。

许文婷：权限那部分写得很到位。我们法务一开始就卡在数据出境和审计留痕上，后来是把鉴权全部收到服务端才过的评审。

罗建国：制造业信息化的老兵了，说句实话，AI 能不能落地，八成看数据底子。文章里那个三百张表打标签的做法我们也在推，慢是慢，但后面省事。