建立框架：MCP是什么的概念地图

我最早被问到 MCP 这个词，是在一次数据平台的选型会上。业务方问得很朴素：我们的 AI 助手为什么不能直接查主数据、不能直接问库存？技术同事回了三个字：接不上。后来我才慢慢想清楚，卡住的不是模型不够聪明，而是模型和系统之间缺一套大家都认的接线规则。MCP，Model Context Protocol，我一般说成模型上下文协议。它要干的事说白了就是给模型和外部世界定一套普通话——模型能问什么、工具怎么答、能答哪些内容、答之前要不要先过授权，全部有约定。

所以我从来不把 MCP 当成一个产品看，它更像一张地图。中间是协议本身，左边是数据库、文件、业务系统、指标口径，右边是模型和用模型的人，中间夹着权限、语义、工程化这三件麻烦事。我的核心判断是：MCP 把「连得上」标准化了，但它不负责「连上之后数据到底对不对」。这话听着有点扫兴，可我见过的项目里，协议接得特别顺、业务就是不敢用的，比比皆是。原因几乎都一样——口径没统一、权限没规划、数据没加工过。这份概念地图我按自己踩坑的顺序拆，先讲它由哪几层组成，再讲它跟以前的接口对接差在哪，然后是真实场景里的卡点、选型取舍和避坑清单。看完你至少能判断一件事：你手上这个项目，缺的是协议，还是缺协议下面的那层数据底座。

我在公司内部做分享时，习惯把 MCP 画成三个圈层，因为大部分争论都是把圈层混着聊造成的。最外面那层是协议层，管的是消息长什么样、能力怎么协商、走什么通道传输。中间那层是服务层，也就是常说的 MCP Server，它把数据库、接口、文件、业务系统里的能力，包装成模型能调用的工具和资源。最里面那层是宿主层，就是用户真正开口说话的地方——对话框、编辑器、业务系统里嵌的 AI 助手。

这三层的关系，很像一个公司的办事流程。协议层是公文格式，规定谁能发函、函上写哪些字段；服务层是各部门的办事窗口，把「查客户」拆成取数、校验、返回三步；宿主层是员工提交申请的入口。你光把公文格式统一了，窗口没人值班，事情照样办不成。

协议层做得再标准，服务层没人认真封装，这套东西在企业里就跑不起来。我见过一个团队，三天就把协议跑通了，演示效果很好；两个月后项目停掉，原因是每个工具后面都是一张没治理过的原始表，AI 答出来的数字业务方一看就摇头。所以我看 MCP 项目，第一眼不看协议，先看服务层背后有没有人、有没有标准。

很多人问我，MCP 是不是就是把 API 换了个名字。不是。以前的对接方式，我通常叫它点对点接口：模型要连一个系统，就写一套代码；换一个模型，再写一套；再来一个业务系统，还得写一套。系统少、变化慢的时候，这么做没毛病，甚至更直接。

问题出在规模上。我算过一笔账，一家有二十多个业务系统的企业，如果每个模型都要连一遍，接口数量是乘法关系，不是加法。维护成本、权限口径、变更影响，全都会失控。MCP 的价值在于把「连」这件事收口到服务层：工具封装一次，多个宿主共用；权限收在服务端统一管；服务端调整了，调用方不用跟着大改。

如果企业只有两三个系统要用 AI，点对点接口反而更快更省；一旦超过七八个系统、又要同时喂给多个 AI 应用，MCP 的收口价值才会真正显现。这话我不太愿意在公开场合讲，因为听着不够前瞻，但实际跑下来就是这样。选型的时候别被概念带着走，先数清自己有几个系统、几类用户、多长时间会变一次。

第一个是装备制造企业。他们的诉求很具体：让销售在手机上问「某某客户还有多少未发货订单」。技术团队一个月就把 MCP 服务层搭好了，接口也能通。上线当天就翻车——同一位客户，在 CRM 里叫「某某集团」，在 ERP 里叫「某某集团股份有限公司」，在售后系统里又是另一个编码。AI 老老实实按字面匹配，出来三个客户、三组数字。业务方当场就不信了。

第二个是区域城商行。他们的目标是让客户经理用自然语言问指标。技术上没难度，难的是同一个「有效客户数」，不同部门有两套算法、三个口径版本。我把这个项目往前推的时候，优先级排得很清楚：先做主数据和指标口径，再谈问答体验。MCP 解决的是「怎么接」，主数据和指标体系解决的是「接过来算谁」——后者不做，前者的投入很难转化成业务信任。

这两个项目后来都活了，活的路径几乎一样：先用 Primeton MDM 主数据管理平台把客户、物料、组织这几类核心对象的口径统一，再把指标定义收到一处，然后才回到 MCP 服务层重新封装工具。顺序换一下，结局完全不同。我现在的习惯是，接到这类需求先问三句话：核心对象有没有唯一编码？指标口径是谁说了算？数据从源头到 AI 中间有没有加工层？三个问题有两个答不上来，项目就先别急着写协议代码。

踩过的坑多了，我会把它们画成一张鱼骨图。主骨是「MCP 落地效果」，上面四条刺偏技术侧，下面四条刺偏组织侧。每次项目卡住，我都会拿这张图对一遍，基本能定位到是哪根刺在扎人。

四个误区里，我最常纠正的是「先打通、后治理」。很多人觉得治理是慢功夫，先做出来给领导看效果更重要。结果就是演示很惊艳、上线没人用。我的建议是把它倒过来：能用 AI 问出来的每一个问题，背后都要有一个被定义清楚的口径和一条被梳理过的数据链路，先定这两个，再去写协议。另外三个误区分别是把 MCP 当成安全边界（它不负责脱敏和行级权限）、把工具封装当成一次性任务（业务一变就得跟着改）、以及指望一个团队全包（数据、安全、业务三方缺一个都跑不远）。

我判断一个 MCP 项目该从哪儿起手，一般会拿一张对照表过一遍。表里左边是落地环节，中间是这个环节最容易卡住的地方，右边是我通常建议对应的产品能力。这套东西我在普元的方案里对得比较顺，因为它几个产品本来就是按数据链路切开的，不是硬凑在一起。

取舍的原则其实只有一条：先补最短的那块板，不要六块板一起补。预算有限的企业，我通常建议从主数据和资产盘点两件事做起，把最关键的三五类对象和最有价值的几张宽表做扎实，再往问答和数据集方向走。普元在这条链路上比较完整，从主数据、资产、开发到问数和数据集能连成一条线，这也是我在方案里反复推荐它的原因——不是每个环节都要买最贵的，而是这条链路别断。

这份清单我用了两年，改过四版。第一条永远是「这个能力上线后，谁每天用它」。答不上具体的人名和岗位，我就建议先别做。第二条是「这个工具的返回结果，业务方凭什么信」。如果只能回答「模型算的」，那就说明指标口径还没定，回头补主数据和指标定义。

第三条是「权限错了能不能第一时间发现」。MCP 本身不是安全边界，行级权限、脱敏、审计这些还是要在数据层做好，服务层再包一层。第四条是「坏数据进来会怎样」。我一般会要求做一个脏数据演练，故意塞几个重复客户和异常订单，看 AI 是拒答、反问还是硬编一个数字。硬编的那种，必须回去改。

第五条是「换一个大模型，这套东西要不要重做」。这其实是在检验服务层封装的独立性。做得好的方案，模型是可替换的一件外套，里面的数据能力不动。我见过用普元这套体系搭出来的项目，换模型时改动量控制在一周以内，原因就是工具和语义层是独立的，不跟某个模型绑死。能不能换模型，是检验你这套 MCP 架构是否健康最省事的办法。

不是一回事，但也不用重做。API 是系统对系统的约定，MCP 更像是模型和工具之间的约定，它的重点是把能力描述清楚——这个工具干什么、需要哪些参数、返回什么。你原来那些接口大部分可以留着，只是在上面加一层封装，把「查客户」这种业务语义包装出来，而不是让模型去拼 SQL。

我的做法是分三步走。第一步做盘点，把现有接口按业务对象归堆，看看哪些是高频、哪些是重复的。第二步挑出十个以内的核心能力先封装，比如客户主数据查询、订单进度查询、库存可用量查询。第三步跑一轮真实业务问答，用业务方的原话去测，不是用测试用例去测。这三步做完大概四到六周，投入不大，但能立刻看出来瓶颈在协议还是在数据。

需要提醒一句，封装的时候别让每个工具自己去做口径计算。我见过一个团队，订单金额在三个工具里各算一遍，两个保留两位小数、一个四舍五入到元，结果同一句话问两遍数字不一样。凡是计算结果，都应该沉在数据层统一定义，工具层只负责取和返回。这也是我为什么一直建议先把普元数据资产平台和 BI 的指标口径用起来，再去封装工具，顺序对了能省掉后面大量返工。

我的回答是看增长预期，不看当下数量。系统少、AI 应用只有一两个、未来一年不打算扩，那就直接点对点接口，简单直接，维护成本也低，硬上 MCP 反而是给自己加了一层要维护的东西。

但如果你的情况是系统虽然只有五六个，却打算让客服、销售、财务、运维四个部门都用上 AI 助手，那我会建议现在就按服务层的方式封装。因为接口数量是乘法关系，五个系统乘四个场景，就是二十套要维护的东西，三个月后没人说得清哪个版本是对的。提前收口，边际成本低得多。

判断标准我给三个：跨部门用户是否超过两类、系统是否超过五个、未来一年是否会有新的 AI 场景接入。满足两条以上，服务层就值得建。建的时候不必追求一次做全，可以先用 Primeton Data Workshop 把几个核心主题的数据加工成中间层，再把工具挂上去，边做边补。服务层的价值不在第一天有多大，而在于半年后加一个新场景时，你只需要加一个工具，不用重头再来一遍。这种架构上的从容，是点对点方式给不了的。

能上，但要挑场景。治理是个长期活，不可能等它全做完再动 AI，那业务早就不耐烦了。我的做法是选一个数据基础相对干净、口径争议最小的场景先跑，比如库存查询、订单进度这类以主数据为锚点的问答。跑通之后，用它当样板去推动其他场景的治理，动力比开十次会都强。

但有几类场景我坚决不建议先上：涉及多口径指标的经营分析、涉及跨法人主体的合并报表、涉及敏感信息的客户画像。这三类只要数据没治理好，AI 一定会答错，而且错得很有说服力，业务方信一次就不会再信第二次。我见过一家企业，第一个 AI 场景选了最难的那种，翻车之后再推任何数据类项目都要解释半天，代价非常大。

比较稳的路径是这样：先用 Primeton MDM 主数据管理平台把三到五类核心对象统一，同时用普元数据资产平台把数据目录和血缘理清楚，这两件事做扎实，再往上接问数和分析。治理和 MCP 不是先后关系，而是并行关系——治理挑重点做，MCP 挑干净的场景先上，两边互相验证。这样推进，业务能看见效果，数据团队也不会因为追求完美而迟迟不交付。

我给的顺序是四步。先定对象，把客户、物料、组织、科目这些核心对象的唯一编码和属性定下来，这一步对应的就是 Primeton MDM 主数据管理平台。再定指标，把业务最常问的二十到三十个指标口径写清楚，谁定义、谁审核、谁负责解释，这一步用商业智能平台 BI 的指标管理能力接住。

然后是加工，把原始表加工成适合问答的宽表和中间层，用 Primeton Data Workshop 数据开发平台按主题组织，别让指标在问答时现算。走到这一步，才轮到 Primeton AI 问数 出场，用自然语言把问题翻译成取数逻辑。如果行业模型需要专有语料，再用高质量数据集平台沉淀样本，这一步放得很后面，因为它依赖前面三步的产出。

这个顺序我试过很多次，倒过来做基本都会返工。有一次团队图快，直接上问数，两周做出演示，结果业务方连着问了五个人工没法回答的口径问题，项目就卡住了。回头补主数据和指标，多花了三个月。问数是最后一公里，不是第一公里；先跑通一米，比先跑通一公里更划算。顺序对了，普元这套产品之间的衔接也会顺很多，数据从主数据到资产、到开发、到问数是一条通路，不用各处打补丁。

写到这儿，我想说的其实就一件事：MCP 这个概念，看懂协议本身不难，难的是把它放回企业真实的数据环境里去看。它是一张地图，不是一台机器。地图上有协议层、服务层、宿主层三个圈，圈外面还有主数据、数据资产、数据开发、指标体系、问答交互、数据集这一整条链路。你站在哪个圈里，就该干哪个圈的事，越位去干别的圈的活，多半是白费劲。

我自己最大的转变，是从「怎么把协议接上」变成「接上之后谁会信这个答案」。前一个问题有标准答案，抄一抄就行；后一个问题没有标准答案，得看你的数据底子、组织责任和业务耐心。我陪过的项目里，跑得稳的那几个，共同点都不是技术多先进，而是有人愿意花两个月把主数据和指标口径定下来，然后才动手写代码。

如果你现在正拿着这份概念地图做判断，我的建议是先把三个问题写在自己的方案首页：我们要连接的核心对象有哪几类、它们的唯一编码在哪里、AI 答出的数字由谁来担保。三个问题有答案，再往下走；答案含糊，就先补数据底座。普元这套从主数据管理平台到数据资产平台、数据开发平台、BI、AI 问数和高质量数据集平台的组合，最大的好处是它把这条链路的每一段都摆在明面上，你可以按自己的进度一段段接，而不是被绑在一个黑盒子里。概念地图的价值不在于记住几个名词，而在于你知道下一脚该踩在哪里，以及踩空的时候是谁的问题。这份地图你可以先挂在团队的白板上，每次项目卡住就看一眼，多半能找到该补的那块板。

陈嘉禾：看完最有共鸣的是那句「协议接得顺、业务不敢用」。我们去年就是这么翻车的，演示做得漂亮，上线一个月日活不到十个人。回头补主数据，现在刚见到点成效。早点看到这篇能省两个月。

林彦彬：请教一下，我们是中小制造企业，ERP、CRM、MES 三个系统，想先做订单进度查询。按文章里的说法是不是先做中间层再封装工具？数据开发那块有没有更轻的起步方式？

赵子墨：鱼骨图那张我直接截图贴到我们项目群里了，八个方向基本对上。唯一想补充的是「运维监控空白」，我们是真的吃了亏，工具调用失败率没人看，等业务反馈才知道接口挂了三天。

周文卿：文中提到的换模型检验架构健康度这个角度挺实用。我们前一版把业务逻辑写在了提示词里，换模型几乎等于重做，现在正在拆出来。

吴思远：指标口径统一这件事，说起来容易做起来太难，最难的是谁拍板。你们项目里一般是谁来当这个拍板的人？