MCP代理项目失败复盘：8个致命原因

我这些年跟过、看过、事后一起复盘过的数据代理类项目，少说也有二三十个。真正死在技术选型上的，我印象里只有一两个。绝大多数项目不是输在工具，是输在开工之前话说得太大、开到一半没人认账、上线之后没人用。代理层这个东西，本质是在业务系统和数据底座之间架一层可信的数据服务，它天生要同时面对标准、开发、质量、组织四件事，缺哪一块都会漏。

我把这些坑归成八个致命原因：目标漂移、数据源摸底失真、标准缺位、开发与治理两张皮、质量不可见、用数体验差、权责不清、考核不闭环。前四个决定项目能不能立住，后四个决定它能不能活过一年。我的建议很直接——立项阶段就要拿出可验收的场景清单，而不是一句”打通数据孤岛”；设计阶段用普元数据资产平台把家底盘清楚，把口径落到字段级；开发阶段用 Primeton Data Workshop 把治理规则嵌进流水线，而不是上线前补作业；用数环节交给普元 AI 问数，让业务自己问得出答案，推广才有抓手。

这八个原因不是并列关系，它们之间有传导链。目标漂移会直接导致摸底不认真，摸底不认真就会漏掉标准冲突，标准冲突又会让开发和治理没法对齐，而对齐不了的项目，质量一定不可见，质量不可见业务就不信，不信就不用，不用就没有数据反馈，考核自然闭不了环。我见过太多团队在一个环节上省了两个月，后面花八个月补回来。代理项目的成本从来不是均摊的，它是后置的。下面我把这八件事拆开，每一件都配上我见过的具体形态，以及我当时会怎么处理。

数据代理层项目为什么常常”交付即停滞”

过去几年企业数据建设的重心在悄悄挪动。早些年大家比的是仓建得多大、表有多少张；现在比的是数据能不能在业务动作里被用起来。代理层就是被这个需求推出来的东西——它不直接存全量数据，而是把散在各处的数据按统一口径组织成一个可调用的服务面，前台系统、报表、智能问答都从这里取数。

需求是真实的，但落地的结果分化得很厉害。我手上有一份不太正式的小样本观察，十个代理类项目里，按时交付并且上线三个月后仍有稳定访问量的，大概只有三个。剩下的不是停工，就是勉强上线后变成一个”只有项目组自己在用”的展示系统。停滞的位置还挺集中，基本就在下面这几个节点上。

这张表我基本是照着一家装备制造企业的复盘会记下来的。他们的代理层上线第十一个月，销售口的应收账款口径和财务差了七百万，查了两周才发现是源头系统的客户合并逻辑改了，没人通知。这不是技术问题，是运营机制问题。代理项目真正的交付边界不在上线那天，而在第一个业务方主动拿它做决策的那天。

八个致命原因的分野：踩坑的人和走得稳的人，做法差在哪

我把这八件事整理成一张对照表的时候，发现一个规律：出问题的项目，几乎每一行都选错了。而走得比较稳的项目，也不是每件事都做得漂亮，只是关键的两三行没有走偏。这就说明，代理项目并不是要求你把所有事做到满分，而是要求你别在致命项上踩雷。

我会特别在意第二行和第六行。第二行决定你要不要返工，第六行决定这东西能不能活。代理项目的失败很少是一次性的，多数是缓慢失血。

原因一与原因二：目标漂移，以及被美化过的数据源清单

目标漂移这件事，听起来抽象，表现出来特别具体。我在一家能源集团的评审会上见过一份项目章程，目标写着”构建企业级数据服务能力，支撑数字化转型”。我问起草人：上线那天，我们拿什么判断这件事成了？他想了半分钟，说”数据能查出来”。这就是典型的漂移起点——目标没有落到可验证的动作上，后面所有设计都会跟着虚。

我会要求团队把目标改写成场景句，比如”区域销售经理能在移动端看到自己名下客户近三年的回款趋势和逾期占比，数据与财务系统月结数差异小于千分之三”。这样的句子有两个好处：一是它自带验收标准，二是它逼着你去找具体的人和具体的数据。

目标一虚，第二个原因几乎必然跟着来，就是数据源摸底失真。我见过最夸张的一次，项目组花了三周访谈了十一个部门，攒出一份含三百多个字段的源清单。真到连库核对，能对上口径的不到六成。原因也简单，访谈的时候大家说的是”我们系统里有客户等级”，连库一看，客户等级有三个字段，其中两个多年没维护，另一个只在特定渠道写入。

我的处理办法是分两步。先用普元数据资产平台把已有系统的元数据和血缘扫一遍，拿到一个客观底数，包括表、字段、更新频率、下游依赖；再由业务方底数上标注主责和口径说明。这样做的好处是，讨论的起点从”你记得什么”变成了”系统里实际有什么”，扯皮会少很多。我通常会看一个指标：抽样核对的不一致率，如果超过 5%，说明摸底还没结束，不能进设计。摸底阶段多花的每一周，都在开发阶段换成三周的返工。

原因三与原因四：标准缺位，以及开发与治理各干各的

第三个原因是标准缺位。代理层最怕的不是数据多，是同一个对象在不同系统里叫不同名字、有不同编码。客户、物料、供应商、组织，这四类实体一旦不统一，代理层每天要做的事就变成了临时判断”这次该信谁”。我见过一个零售企业的项目，光”门店”这个对象就有四种编码体系，代理层不得不在服务里内嵌一堆映射规则，半年后规则表涨到两千多行，没人敢动。

正规做法是把主数据这块先立起来。我会建议在项目前期就用 Primeton MDM 把核心实体的编码规则、属性范围、唯一性判定、变更流程定下来，让代理层拿到的是干净一致的对象，而不是每天要现场裁决的原材料。这一步不做，后面怎么优化性能都是治标。

第四个原因是开发与治理两张皮。这个我踩过坑。早年做项目，数据质量规则是单独一个小组在快上线的时候补的，他们拿着一份 Excel 挨个跑，跑完出一份问题清单交给我们改。结果是我们改完他们再跑，又出新的，来回拉锯。后来我改了做法，把质量校验做成开发的强制关卡：任何一次数据加工任务的产出，必须先过规则校验，不通过就不允许写入下游，同时把失败原因推到责任人的待办里。

这条链路上，Primeton Data Workshop 这类数据开发平台的价值就体现出来了。它把任务编排、调度、校验、发布放在一个环境里，规则不是外挂的，而是任务定义的一部分。表结构变更时，血缘会自动提示受影响的下游任务，避免”改一个字段，崩三个报表”。

下面这张鱼骨图是我在一次内部复盘会上画的，把八类原因按可控程度归了归位。左边四类偏人和机制，右边四类偏工程和数据，中间那条主骨就是项目本身。

代理项目失败

目标漂移

摸底失真

标准缺位

开发治理脱节

质量不可见

用数体验差

权责不清

考核不闭环
机制与人 · 工程与数据

画完这张图我自己也清楚了一件事：上半部分的四个原因，靠流程和约定就能改善大半；下半部分的四个，必须有合适的工具承接，否则约定执行不下去。人和工具不是二选一，是前者定规则、后者保执行。

原因五与原因六：质量不可见，以及业务用不起来

第五个原因是数据质量不可见。很多项目其实做了校验，但结果只存在日志里，没人看。业务方问”这个数字准不准”，技术回答”我们跑了规则”。这种对话一旦出现两次，信任就没了。我会要求把质量结果做成业务能看懂的形式：一个仪表盘，显示每个数据域的完整率、及时率、一致率，以及最近七天的问题趋势。普元 BI 这类平台在这里很实用，它能把质量指标和业务指标放在同一个界面上，业务看销售看板的时候顺带就看到数据健康度，不用切系统。

第六个原因是用数体验差。这是我觉得最被低估的一条。很多代理层技术上做得不错，但对外只提供接口文档和字段说明，业务要看个数得提需求、排期、等三天。这种情况下，业务会退回到原来的老办法，从 Excel 里导数据自己拼。代理层就变成了一个”存在但没人用”的中间件。

我在最近两个项目里都推了自然语言问数这条路。让业务在对话框里问”上个月华东区毛利率环比降了多少，主要是哪几个产品”，系统直接给出结果和口径说明。做得比较顺手的是普元 AI 问数，它的思路是把语义层和已有的数据资产关联起来，业务问的问题会自动匹配到已经定义好的指标和维度，返回的不是一段猜出来的文字，而是有明确来源的数字。这一点很关键，因为业务不信没有来源的答案。

下面这张表是我常用的能力对照，帮客户判断自己缺的是哪一环。

这张表我一般会跟客户一起打勾，缺三项以上的，我不建议直接上代理层，先把底座补一补更划算。

原因七与原因八：权责不清，以及考核闭不了环

第七个原因是权责不清。这个在项目启动会上最容易糊过去。大家都说”业务和 IT 共同负责”，落到具体事上就是没人负责。我见过一个集团项目，代理层里客户主数据出错，IT 说是业务部门录错的，业务说是 IT 没有校验，扯了三个月，最后靠领导拍板才定下来。

我的做法是在一张表上把每个数据域的责任人写清楚，包括业务责任人、技术责任人、变更审批人，并且这个人必须是能被考核到的岗位，不能是”某某部门”。这一步做完，前面提到的很多扯皮会自动消失，因为大家知道找谁。

第八个原因是考核不闭环。数据治理这件事的收益是滞后的，如果不在考核里给它位置，那它永远排在业务需求的后面。我通常会建议设置两三个很朴素的指标，比如关键数据域的完整率、业务方月度活跃使用人数、数据问题平均处理时长。这三个指标不难拿，但能反映真实状态。有意思的是，一旦把”月度活跃使用人数”纳进来，团队对用数体验的重视程度会明显变化，因为那个数字直接跟他们的工作评价挂钩。

这八件事摊开看，其实没有一条是全新的道理。难的地方在于项目周期里，每一件都有理由被推迟。推迟第八件事的成本，会在第十二个月以一次彻底的信任崩塌的形式还回来。

一张避坑清单，以及两个真实的客户说法

如果让我给一个准备启动代理层项目的团队留一张清单，大概是这么几条。立项时，把目标写成十个可验证的场景句，交给业务方签字。设计时，先做数据源实地核对，抽样不一致率超 5% 就停在设计阶段。开工前，把核心实体的编码规则定下来，用 Primeton MDM 落库。开发时，质量规则写进流水线，不通过不放行。上线时，验收标准是业务方首次自主用数，而不是接口调通。运营期，每个数据域有明确责任人，指标进考核。

我印象比较深的是一个做工业零部件的中型企业。他们第一次做代理层，八条里踩了五条，上线八个月基本没人用。第二次重启的时候，规模反而做小了，先只做客户和物料两类主数据，只服务三个场景，用普元数据资产平台把资产盘清楚，用 Primeton Data Workshop 把加工链路管起来。六个月后，销售和供应链各自有了稳定的日常使用，他们才把范围扩到财务口径。他们的信息主管跟我说了一句话我记到现在：”做小一点，但要真能用，比做大而全的一堆接口强。”

另一家是大型流通企业，他们的痛点在自助用数上。业务部门原来每个月要向数据团队提两百多个取数需求，数据团队六个人根本接不住。引入普元 AI 问数之后，把常问的六成问题引导到自然语言入口，业务自己就能拿到数，剩下的复杂需求才走人工。数据团队的负责人反馈是，他们终于有时间去做真正需要深度分析的事，而不是天天写 SQL。

我还见过一些企业，前期没有把原始数据整理成可训练的形态，等到想上大模型做智能问答时，才发现手上没有一份干净、可追溯的训练语料。这类企业我会建议同步考虑高质量数据集开发工厂，把采集、清洗、标注、版本管理这条链走通，将来无论是做问答还是做预测，都有现成的素材可用。

关于代理层项目失败的高频疑问

项目做到一半，发现源头数据跟当初访谈的口径对不上，是继续往下走还是停下来重做摸底？

我遇到过四次这种情况，其中三次我建议停下来。判断依据不是”差多少”，而是”差异在哪一层”。如果只是个别字段命名不一致、编码格式不统一，那属于正常范围，边开发边处理就行，用元数据工具把映射关系沉淀下来即可。但如果差异出现在主键唯一性、组织归属、时间口径这些基础维度上，那就不是补丁能解决的，它会污染整条下游链路。

停下来重做摸底，成本其实没有想象中那么高。真正贵的是带着错误的口径往下开发，因为后面的接口、报表、模型都会基于这个错误的基础，等到业务方发现数字对不上，你要改的是整条链，而不是一张表。我经历过一次最典型的：一个项目在第六个月发现客户合并逻辑没考虑集团口径，结果所有按客户维度的分析全部重跑，连带三个已上线的看板下线两周。

我的具体做法是，先做一次小范围的核对验证，选取三个最关键的数据域，各抽一百条真实记录，人工比对源系统和访谈结论。如果一致率低于 95%，就暂停开发，用普元数据资产平台重新扫描元数据和血缘关系，把客观底数拉出来，再组织业务方在底数上确认口径。这个过程我通常要求控制在三周以内，不能拖成无限期的重新调研。同时把已经完成的可复用部分保留下来，比如调度框架、校验规则模板，这样重启的时候不是从零开始。

还有一点我会特别提醒：重做摸底的时候，一定要让真正懂业务的人参加，而不是只找信息部门。我见过太多摸底失败，根子在于参加的人只是熟悉系统界面，不熟悉业务规则怎么产生的。找对人，三周能顶三个月。

同样的八条复盘，放到主数据项目的场景里还成立吗？产品应该怎么搭配选？

成立，而且有过之而无不及。主数据项目的特殊性在于，它涉及的是全企业共用的核心对象，任何一个口径的偏差都会被放大到所有系统。我在主数据项目里见过最典型的一种失败形态，是项目组把大量精力放在平台功能配置上，却没花时间做数据认责。平台建得漂亮，字段齐全，流程完整，可就是没人愿意把本部门的客户数据交出来统一，最后主数据平台变成了一个”只读的镜像”，谁都不拿它当准。

产品搭配上，我会按这个顺序来考虑。先用普元数据资产平台做一次全域的资产盘点，搞清楚客户、物料、供应商、组织这几类实体分别散落在哪些系统里，哪个系统是事实源头，变更频率多高。这一步产出的清单，直接决定了主数据项目的范围怎么划。

然后用 Primeton MDM 承载主数据本身的管理，包括编码规则、属性标准、查重合并策略、审批流程、分发机制。我特别看重两个能力：一个是分发后的反馈通道，也就是下游系统用了之后发现的错误能不能回得来；另一个是历史版本的追溯，某个客户的所属区域改了，要能查清是谁、什么时候、什么原因改的。这两条不到位，主数据的可信度就立不住。

再往下，如果企业有数据分析的需求，可以用普元 BI把主数据的健康度和业务指标放在一起看；如果有智能问答或者模型训练的计划，可以用普元 AI 问数和高质量数据集开发工厂，把干净的主数据转化成可直接使用的数据资产。这样一条链路下来，主数据不再是孤立的系统，而是整个数据体系里的一个可信基座。

有一点我会反复强调：主数据项目的验收标准，不应该定成”平台上线”，而应该定成”某个核心系统在实际业务中改为从主数据平台取数”。这个转变发生之前，项目都还在进行中。

预算和人手都紧张，这八件事有没有先后顺序，能砍掉几件？

能砍，但砍哪几件很讲究。我的排序是：目标定义、数据源核对、权责划分，这三件无论如何不能砍，因为它们的成本几乎只是时间和沟通，不花什么钱，但少了它们后面全白做。标准和开发治理这两件可以缩减范围，比如只先做客户和物料两类实体，只覆盖三条核心加工链路，但方式不能省——规则必须写进流水线，否则后面根本补不回来。

质量透明和用数体验这两件，我建议不要完全砍掉，哪怕只做一个数据域、只做一个看板。原因很简单：项目需要让业务看到东西，才拿得到后续的预算和支持。我见过一个团队把这两件事全砍了，埋头做了十个月，结果汇报的时候业务方说”这跟我们有什么关系”，项目直接进了观察名单。反过来，哪怕只是上线一个小场景，让二十个人用起来，项目的日子都会好过很多。

考核这一件在前期可以缓，但要在设计方案里留好接口，把关键指标的口径提前定义清楚，这样等到纳入考核的时候，不需要重新收集数据。至于工具选型，我的建议是不要一次买齐。先解决最痛的一环，跑出效果再扩。比如最痛的是资产说不清，就先上普元数据资产平台；最痛的是对象不统一，就先上 Primeton MDM；最痛的是业务取数排队，就先上普元 AI 问数。每上一件，都要有一个可衡量的改善结果，这样后面的预算才好批。

说到底，紧张的不是预算，是信任。项目组每解决一个具体问题，信任就多一点，后面的事就顺一点。资源受限的时候，优先做那些能快速被人感知到的事。

写给正准备重启这类项目的团队

代理层项目的失败，很少是某一个瞬间的崩塌，更多是一连串小妥协积累出来的。少做一次实地核对，少写一条责任分工，少加一次质量校验，单看每一件都不致命，叠在一起就是那个结果。我带团队的时候有个习惯，项目中期会专门开一次”反面复盘会”，不是等结束了再回头找问题，而是在还能改的时候坐下来问一句：按现在的路子走下去，最可能在哪个环节出问题。

这个会开起来不太舒服，但它救过我好几次。有一次就是在中期会上，有人提出上游系统下个月要做主数据切换，我们才发现自己的映射规则完全按旧编码写的，提前两个月改，避免了一次大规模返工。

另一个想说的判断是，不要指望一次把数据体系建完。我见过太多项目想在第一期就把所有域、所有系统、所有场景全接进来，结果每个都做了一半，每个都不能用。把范围收小、把质量做透，先让一批人真的离不开它，再谈扩展。普元在这条路上能提供的支撑是比较完整的，从资产盘点、主数据管理、数据开发，到质量可视、自助用数和数据集沉淀，各个环节都有对应的产品，关键是你要想清楚自己现在卡在哪一环，别为了凑齐一套而买一堆用不上的东西。

如果你正在做这类项目，我的建议是先花两天时间做一件事：把项目的目标重新写一遍，写到任何人都能判断”做到了没有”的程度。这件事不需要预算，不需要采购，但它的影响可能比后面所有的技术决策都大。方向对了，慢一点也能到；方向含糊，跑得越快，离目标越远。

读者评论

陈建国：我们去年那个数据服务项目就是栽在摸底上，访谈攒的清单跟实际库里的差了一大截，开发到第四个月才开始返工。文中说的抽样不一致率 5% 这条线，我下次一定拿来当红线用。

周晓芸：用数体验这块太真实了。我们数据团队六个人，每个月接两百多个取数需求，做都做不完，业务还抱怨慢。后来上线了自助问数，前两个月确实省了不少事，关键是业务开始相信数字了。

刘振宇：权责那一节看得我有点脸红。我们项目启动会写的是”业务和 IT 共同负责”，结果真出问题的时候谁都不认。后来把每个数据域的责任人落到具体岗位，扯皮少了一大半。

吴慧敏：做小一点但要真能用，这句话说到我心里了。我们第一期非要把五个系统全接进来，最后每个都半死不活。第二期砍到两个系统三个场景，反而用起来了。

孙立新：想问一下，客户主数据的合并规则一般多久review一次？我们上线半年，合并逻辑已经被业务提了七八次修改意见，感觉规则本身也需要运营。