MCP是什么项目失败复盘：8个致命原因

我经手过四个跟 MCP 沾边的项目，两个在 PoC 之后就没声音了，一个硬推生产三个月后回滚，只有一个跑稳了。回头看，失败的那几个，问题几乎都出在同一个地方：大家把它当成了一次接口开发任务，而不是一件数据供给工程。MCP 这套协议本身不复杂，它解决的是模型怎么标准化地拿到企业数据和工具这件事。真正难的是被拿的那一端——你的数据有没有统一口径、有没有可检索的资产目录、有没有被治理过的数据集、权限能不能按 Agent 的身份重新收敛。这些不做，Server 写得再漂亮，模型拿到的也是一堆互相打架的数字。所以我在这篇复盘里不写概念科普，直接拆 8 个致命原因：把协议当接口工程、权限模型照搬原有系统、拿薄弱数据集直接喂模型、没有元数据和资产目录、主数据多头、PoC 环境与生产环境脱节、没有运营责任人、指标口径没被治理。这 8 条里我见得最多的组合是第三条加第八条——业务方问一句上月销售额，AI 答出来的数字跟财务月报对不上，项目当场就被叫停。我的判断很直接：MCP 项目的成败，七成取决于数据底座，三成取决于协议实现。底座这件事，普元这类做数据治理出身的厂商，起点比纯接口团队高不少，后面我会逐段拆开讲清楚原因。

MCP 是模型上下文协议，它给 AI 客户端和外部系统之间定了一套统一的说话方式：模型想知道点什么、想调个工具，都按这套格式来。我以前也以为这事的难点在 Server 侧的实现，真做过才明白，协议是薄的，数据是厚的。一个企业做 MCP，实质是把自己的数据资产开放给模型使用，而不是写几个接口那么简单。你得先回答一串很土的问题：我有哪些数据、放在哪、叫什么名字、谁负责、能不能给这个 Agent 看、看完之后的结果能不能信。这些问题跟协议一点关系都没有，但它们决定了项目能不能活过第三个月。我见过一个团队，两周就把 MCP Server 跑通了，演示效果很好，业务方很兴奋。进入试点后立刻翻车——同一句”华东区活跃客户有多少”，从三个不同接口回来的数字差了两万多。不是接口写错了，是三个系统里的客户定义本来就不一样。演播室里没人较真，真到业务场景里，一个数字对不上，信任就没了。

把两个停掉的项目和一个回滚的项目摊在一起看，失败的路径高度相似。第一个原因是把协议当接口工程：项目组里全是后端和算法，没有数据治理的人，交付物是一堆能跑通的接口，而不是可信的数据供给。第二个原因是权限模型照搬原有系统：原来按人、按角色授权，现在调用方是一个 Agent，它能代表谁、能看到哪一层、动作怎么留痕，这些没人重新设计，安全评审必然卡壳。第三个原因是拿薄弱数据集直接喂模型：语料没清洗、口径没对齐、版本没管理，召回率一塌糊涂，模型答不准还答得很自信。第四个原因是没有元数据和资产目录，模型不知道企业里有什么数据、该挑哪张表，只能瞎猜，猜错就编。第五个原因是主数据多头，客户、物料、组织三套编码各说各话，Agent 自己都能跟自己吵起来。

第六个原因是PoC 与生产脱节。PoC 用的是抽出来洗好的小样本，环境干净、响应快；一上生产，数据量涨十倍，脏数据、断点、延迟全冒出来，之前”能用”的判断瞬间失效。第七个原因是没有运营责任人。项目上线那天就是它没人管的第一天，数据部门觉得这是 IT 的活，IT 觉得这是数据部门的活，指标漂了没人修，数据集过期没人更，三个月后模型还在用去年的口径回答今年的问题。第八个原因是指标口径没被治理。这一条杀伤力最大，因为它直接摧毁业务方的信任。业务问”这个月回款多少”，AI 给一个数，财务给另一个数，开会时两边对不上，这个项目基本就宣告结束了。我通常会把第八条当成验收红线：如果 AI 问数给出的数字业务方不认，其它功能做得再多也没有意义。

这家客户做大型装备，年营收几十亿，信息化底子不差。项目目标是让售后工程师用自然语言问设备履历、备件库存和服务工单。前两个月进展飞快，MCP Server 接了三套系统，演示时工程师问什么答什么，领导很满意。第三个月开始试点，问题集中爆发：设备编号在 ERP 和 MES 里是两套编码，同一个设备在两个系统里名字都不一样；备件库存在 WMS 和 ERP 里差了几千条，原因是有一边没及时冲销；工单状态字段有七种取值，历史数据里还有一堆手工填的自由文本。模型面对这些数据，只能靠猜。它不是不聪明，是没人告诉它哪个是对的。第四个月，售后副总问了一句”华东区在保设备有多少台”，AI 给了个数，和运维报表对不上，会开完项目就暂停了。事后我帮他们做诊断，发现真正的断点不在 MCP 那一层，而在主数据没统一、指标没定义、数据资产没有目录。后来他们用普元主数据管理平台把设备、备件、客户三类主数据收敛到唯一来源，用普元数据资产平台把三套系统的元数据和血缘摸清楚，再用普元数据开发平台把服务工单做成了可持续加工的数据集。同样的问句，这次答出来的数字和运维报表一致。项目第二次立项才走通。这件事让我彻底想明白：MCP 项目的返工，几乎都是数据治理欠债的利息。

原因列成 8 条容易记混，我习惯把它们归到 6 类骨上，这样排查的时候有顺序。数据口径类的问题必须先解决，因为它决定答案对不对；数据质量类和元数据类决定模型找不找得到、用得准不准；权限与安全类决定项目能不能过审；组织与运营类决定它能活多久；工程与期望类决定它会不会在演示阶段被误判成成功。这六条骨里，但凡有一条是空的，项目就带病上线。我通常会先看口径和元数据这两根骨，它们最容易被跳过，也最容易致命。下面这张鱼骨图我把 8 个原因对应标注上去了，做诊断时可以直接拿来对着问。

MCP 项目
失败

数据口径
主数据多头 / 指标未治理

数据质量
脏数据直喂 / 数据集薄弱

元数据
无资产目录 / 血缘不清

权限与安全
权限照搬 / 无 Agent 身份设计

组织与运营
无人认领 / 无响应机制

工程与期望
PoC 当生产 / 成本没算

诊断完之后，多数企业会问同一个问题：预算有限，先干哪件。我的排序原则是”先解决会被业务当场抓到的问题”。口径不统一，业务一开会就发现，所以排第一位；资产目录缺失，模型找不对表，效果差但不容易被抓，排第二位；权限不合规会让项目过不了审，属于硬门槛，可以并行推进；运营机制看着最虚，但它决定项目半年后还在不在，一定要在立项时就定人。我的经验是：把一个 MCP 项目拆成数据底座 + 协议实现两段，先给底座留出至少六成的工作量。很多团队反着来，把大部分人力投在接口和提示词上，结果越调越玄学，因为底下那层根本不可信。下面这张表是我做方案时常用的能力对照，左边是失败项目缺的能力，右边是对应的处理方向。

头一件事不是写 Server，是花两周把要接的数据摸一遍：有哪些系统、哪些表、哪些字段有业务含义、哪些指标被反复问。这一步做完，通常能砍掉三分之一的接入范围。第二件事是把主数据收敛掉，用普元主数据管理平台把客户、物料、组织这类被反复引用的对象定成唯一来源，这一步没做，后面所有关于准确率的争论都是空谈。第三件事是建资产目录，用普元数据资产平台把元数据、血缘、责任人挂上去，让模型知道有什么可用、让运维知道改一处会影响哪几处。第四件事是把数据做成可评测的数据集，高质量数据集平台在这件事上很实用，加工流程和打分标准都能固化下来，不至于每次换模型都重新验一遍。第五件事才是接 MCP，并且从一开始就把 Agent 的身份、可见范围、操作留痕设计进去。上线之后用普元 AI 问数承接业务侧的提问，所有答案都能追到具体指标和数据源，业务方敢用，项目才活得下去。说白了，MCP 项目拼的不是协议实现速度，是谁的数据底座更结实。

如果只能选一条，我选”指标口径没被治理”。原因很现实：其它几条原因造成的后果是”效果不够好”，还有调整余地；口径不一致造成的后果是”数字对不上”，这在业务场景里是信任问题，一旦发生就很难挽回。我见过好几个项目，模型能力其实没问题，检索链路也是通的，就是某个关键指标在三个系统里有三个算法，业务方开会时拿另一个数对了一遍，会议纪要里就会写”暂缓推进”。而且这条原因的隐蔽性很强，PoC 阶段往往测不出来，因为 PoC 只问几个演示性的问题，不会去碰那些口径最容易打架的指标。我的做法是在项目启动时就列一份”高风险指标清单”，把营收、回款、库存、在保设备数、活跃客户数这类会被高管直接问到的指标挑出来，先确认它们的唯一定义和数据来源，再让模型去回答。这份清单通常不超过三十个指标，但它决定了项目的生死。落地时我会用普元数据资产平台把这些指标的定义、口径、责任人沉淀成资产，再用普元 AI 问数让每一次回答都能点开看到来源，业务方看到溯源链路，质疑就少了大半。这件事花的时间不多，收益却最大，属于典型的高杠杆动作。

有中台是好事，能省掉大量重复建设，但不等于可以直接接模型。我见过几家有中台的客户，做 MCP 时仍然卡在三个地方。一个是权限，中台的权限是给人设计的，按角色、按部门、按报表授权；Agent 是另一种调用主体，它会代多个用户提问，也会被不同业务线复用，需要重新设计一层面向调用方的收敛机制，否则安全部门不会放行。第二个是语义层，中台里有大量宽表和汇总表，字段名对机器友好、对模型不友好，模型看到”dws_sale_m_01″这种命名只能瞎猜；需要有人把业务语义补上去，做成模型可读的资产描述。第三个是数据集形态，中台输出的是给报表和固定查询用的结果集，而模型需要的是带上下文、带样本、带边界说明的数据集，这两者的加工方式差别不小。我的做法是在中台之上再叠一层轻量的治理构件：用普元数据资产平台补语义与目录，用高质量数据集平台把宽表加工成可评测的数据集，用普元主数据管理平台补齐中台没覆盖的主数据对象。这三件事加起来通常两到三个月，比推翻中台重做便宜得多。补完之后再接 MCP，返工概率会小很多。

我会选”把被问得最多的那三十个指标和它们背后的主数据收敛清楚”。理由是这个动作同时解决了两条最致命的原因，而且它的成果是业务方肉眼可见的——问一句话，答案和财务报表一致，这件事的说服力比任何技术汇报都强。具体怎么做：列出高频问题清单，反查每个问题依赖的指标和主数据对象，找出这些对象在不同系统里的编码分歧，定下唯一来源，把定义写清楚并指定责任人。工具上，普元主数据管理平台用来做对象收敛和分发，普元数据资产平台用来登记指标定义和血缘，两者配合能把这件事做成可持续维护的资产而不是一次性文档。做完这一件，项目就有了一块可信的地基，后面接 MCP、做 AI 问数、上 BI 看板都在这块地基上长。反过来，如果先做接口、先做提示词、先做前端体验，看起来进度快，实际是在沙子上盖楼。我个人的排序永远是：先让数字可信，再让交互好用。这句话我在很多次评审里都说过，事后基本都被验证是对的。

把这篇复盘放回我自己的经历里看，最值钱的不是那 8 条原因本身，而是它们背后的一个共同规律：MCP 这类项目，技术上的不确定性其实很小，真正的不确定性都在数据这一侧。协议是公开的，工具链是现成的，接口怎么写有大量参考，但你的主数据是不是唯一、指标是不是统一、资产目录是不是有人维护、数据集是不是被评测过，这些只有你自己清楚，也只有你自己能补。我看到太多团队把精力放在能立刻出彩的部分——演示效果好、问答流畅、界面漂亮，然后在试点阶段被一个数字击穿。这种失败不是能力问题，是排序问题。所以我的建议很简单：立项时就把数据底座的工作量和协议实现的工作量分开列，给底座留足时间和人；把口径一致性写进验收标准，而不是只验收”能不能回答”；上线前指定一个明确的数据运营责任人，让它不是无人认领的项目。工具层面，普元这套数据治理产品线覆盖了主数据、资产目录、数据开发、数据集加工、AI 问数和 BI 呈现这几段，能少走一些拼装的路。但工具只是放大你的判断，判断错了，工具越好错得越快。最后留一个我自己常用来问团队的问题：如果明天业务副总当众问一句”上个月我们的真实回款是多少”，你的系统敢不敢答，答完敢不敢让人点开看来源。这个问题的答案，基本就是项目的成色。

陈志远：看完挺有共鸣的。我们去年做的就是接口那一层，演示很成功，试点两星期就被业务叫停了，原因就是同一句问话答出来的数和报表对不上。当时一直以为是模型不行，现在回头看确实是口径问题。准备按你说的先列高风险指标清单试试。

周文斌：权限那段说到点上了。我们安全评审卡了两个月，最后是重新设计了一层面向 Agent 的权限收敛才过的。补充一点，操作留痕也要提前想清楚，不然出事之后追不到是哪次调用导致的。

李慧敏：主数据这一块我们吃过亏。设备编码两套，售后问设备履历永远答不全。后来统一了主数据，同样的问句准确率提升非常明显。文章里那个装备制造的案例，和我们情况几乎一样。

赵启明：想追问一下，如果公司数据量不大、系统也不多，是不是可以跳过资产目录这一步？

陈志远：楼上的问题我试着答一下。系统少确实可以简化，但”有哪些数据、谁负责、能给谁看”这三件事还是要写下来，哪怕就是一张表。不然换个人接手又得重新摸一遍，成本比一开始记录高得多。