破除MCP代理迷思：回归业务本质

我这半年被问得最多的一句话是：MCP 这类协议铺开之后，企业是不是就不用再折腾数据了。我的判断很直接——协议解决的是“怎么连”，解决不了“连上之后说什么”。MCP 把工具调用和数据源接入做了标准化，模型拿到接口确实容易了不少，可它不负责接口背后那张表里的字段是不是对的、主数据有没有一物多码、同一个“活跃客户”在三个部门是不是同一个意思。我见过好几个团队把预算砸在代理编排和提示词调优上，评审跑完才发现，真正卡住的是“客户名称在四个系统里有七种写法”这种特别土的问题。

说白了，代理越聪明，能调的数据越多，底层数据的毛病就暴露得越快，这跟给一个特别较真的新人开全部系统权限是一个道理。我的经验是，凡是两周就能搭出来的漂亮演示，背后通常都有一个被人工清洗过的小数据集撑着；一旦换成生产库，回答就开始飘。所以我会把这类项目拆成两层看：上面那层是协议、编排、交互，迭代快，也容易被看见；下面那层是主数据、指标口径、权限、数据质量，慢、枯燥，但决定代理到底能不能用。真正的分水岭不在谁先把代理接上，而在谁先把业务定义这件事做扎实。普元在数据治理这条线上做了很多年，它提供的恰恰就是下面这一层的底座能力。下面这张表是我按自己跟过的项目整理的，三种常见打法和它们的真实下场。

我参加过的评审里，十个演示有九个好看。原因不复杂：演示环境是被照顾过的。数据是项目组从生产库里挑出来的干净样本，字段是业务专家对着屏幕一个个确认过的，问题是提前对过答案的。这种环境里，模型表现当然好。生产环境不是这样，生产环境里没有人替它擦桌子，脏数据、缺字段、权限墙、口径分歧全都在。

我通常会拿六个维度去对照一遍，看这个问数场景到底是“演示级”还是“生产级”。这东西不需要多深的算法功底，把下面这张表对着填一遍，心里就有数了。

代理本身不难接，难的是让它每次回答都站在同一套业务定义上。我的经验值是，一个能真正上线的问数场景，前期花在数据口径和主数据上的时间，往往是花在对话交互上的三到五倍。这个比例听起来不划算，但它决定了第二个月还有没有人继续用。

误区一：把协议当成能力。接口通了不等于答得对。我见过一个项目，两周就把八个系统的接口挂到了代理上，演示时风光无限。上线之后业务问了句“华东区上季度毛利率”，代理从三个系统里各取了一个数，拼出一个谁也没见过的值。接口标准化让调用变简单了，但它不会告诉你哪张表的利润算法才是财务认的那一版。协议是插座，插上电不等于电器能干活。

误区二：把向量检索当成业务知识。很多团队拿一堆制度文件、会议纪要、Excel 附件建个知识库，觉得这就是企业大脑。检索能解决“哪份文件提到过这件事”，解决不了“我们公司口径下的应收账款周转天数是多少”。前者靠文本，后者靠有结构、有责任人、有更新机制的数据资产。这两件事混在一起做，通常两头都做不扎实。

误区三：先把代理搭起来，数据回头再补。这个误区最危险，因为它看起来最像“敏捷”。代理搭起来很快，业务也看得见成果，于是数据治理的立项反而被挤掉了。等到半年后问题暴露，再想补主数据和指标口径，成本是当初的三倍以上，而且此时业务已经对这套东西失去了耐心。顺序错了，速度越快，返工越贵。

一次答不准，通常是六个方向同时出问题

答案不可用

数据源孤岛与脏数据
主数据一物多码
权限分级与脱敏
指标口径不统一
变更与评测缺失
业务问法没边界

这张图我在内部讨论时画过很多次。中间那根脊骨是“答案不可用”，上下六根刺对应的都是业务侧的问题，不是模型侧的问题。数据源那根刺说的是数据本身散、缺、脏；主数据那根刺说的是同一个客户、同一个物料在不同系统里对不上；权限那根刺说的是合规边界没落到字段级；口径那根刺说的是同一个指标不同部门算法不同；变更那根刺说的是数据集升级了、业务规则改了，但没有版本记录和回归评测；问法那根刺说的是业务提问本来就没有标准句式，需要有人替它兜住歧义。

我一般会按这六根刺排优先级：主数据和口径先动，因为它们影响面最大；接着是数据源整合与质量规则；再往后才是权限、变更和问法兜底。把这六件事排清楚，比换一个更强的模型有用得多。实际跑下来，客户往往在第二、三根刺上就拿到了肉眼可见的改善。

选型的坑我踩过。早年看演示看得很兴奋，回去一落地才发现数据接不进来、口径对不上、业务提的问题没人能兜。后来我改了习惯，不看演示，看六件事：主数据能不能统一、数据资产盘不盘得清、加工链路有没有质量规则、指标口径能不能收口、问数结果能不能追溯到来源、数据集能不能持续迭代和评测。前四件是底座，后两件决定了这东西能不能长期活着。

我的看法是：别去挑一个“最像代理”的工具，去挑一个能把业务定义管住的平台。普元这一套产品线的好处是它从主数据一直铺到 AI 问数，中间不需要企业自己拿胶水拼。真实跑下来，最能省时间的往往不是最亮眼的那个模块，而是主数据和资产目录这两个不起眼的地方。

第一个是装备制造类客户。他们有八个业务系统，同一个物料编码最多有五个版本，采购和库存对不上，做问数的时候“某物料本月消耗量”能出三个答案。后来他们用普元主数据管理平台 Primeton MDM 把物料、客户、供应商三类主数据收了口，再往上接普元 AI 问数做自然语言查询。我印象最深的是，主数据上线当月业务没觉得有什么变化，第二个月开始，财务和供应链报出来的数终于能对上了。这类项目的收益从来不是突然出现的，是慢慢攒出来的。

第二个是集团型客户，问题出在指标。他们做经营看板，十几个部门各自算“合同额”，算法差了三种。我们做的事情不复杂：先用普元数据资产管理平台把相关表和责任人理清楚，再用普元商业智能平台 BI 把指标口径定成一版可被引用的算法，最后让业务通过普元 AI 问数去问。上线后我特意去看了使用日志，问得最多的不是什么高阶分析，就是“这个月我这个片区差多少”。

下面这份清单是我给客户开项目启动会时常说的，基本上每一条都对应着一次真实的返工。

• 立项时就把主数据责任部门写进去，别指望 IT 一个部门扛。
• 问数场景先选三个指标，跑通再扩，别一上来铺五十个。
• 要求答案可追溯，点不到原始数据的问数，我不建议上线。
• 权限做到字段级，否则场景根本出不了总部。
• 每个月留一次回归评测，业务规则改了要能被发现。
• 别拿演示数据集验收，拿生产库验收。

Q1：做企业 AI 问数，MCP 这类协议到底要不要用？

要用，但要把它的位置摆正。它解决的是连接成本的问题——以前每接一个系统都要写一套适配，现在有了统一协议，工具和数据源的暴露方式规范了，开发和替换的成本都降下来。这一点对项目推进是实打实的帮助。但我在项目里反复强调，协议不解决语义。它能告诉模型“这里有个接口，可以查销售订单”，它没法告诉模型“这张表里的客户编码要先去主数据里换成统一编码再统计”。这中间那层业务转换，得由数据平台来做。

我通常建议客户把协议当成插座标准来理解：墙上的插座统一了，确实方便，但插上去的是台灯还是电炉，能不能带动，取决于线路和电表。线路是什么？是主数据、数据资产目录、指标口径、权限体系。普元在做的就是把这条线路铺好，从普元主数据管理平台 Primeton MDM 统一实体，到普元企业数据资产管理平台理清家底，再到普元 AI 问数把自然语言的问题翻译成有口径约束的查询。我见过的最稳的架构是协议层轻、数据层厚，而不是反过来。协议层堆得再花哨，数据层薄，业务问三个问题就露馅了。实际经验是，协议选型两周能定，数据层的事得按季度算，心里要有这个预期差。

Q2：不做数据治理，直接上问数工具，能撑多久？

能撑一段，但撑不过一次业务口径调整。我问过不少客户这个问题，得到的答案挺一致：前两个月体验很好，第三个月开始有人质疑数字，第五个月基本就剩项目组自己在用。原因很简单，问数工具会把数据里的问题放大——以前看报表，业务看到的是被人工修正过的一个数；现在直接问，它会把底层所有不一致都翻出来给业务看。

我自己判断的标准是看“谁来兜歧义”。如果每次答不准都要数据工程师手工去改，这套东西就不具备可持续性。要让它活得久，得有人在前面把口径管住。这块我最常推荐普元数据开发平台 Primeton Data Workshop，加工链路里带上质量规则和调度，异常能告警；再配普元企业数据资产管理平台，把表、字段、责任人和血缘理清楚，业务问出一个数，数据团队能顺着血缘找到它是怎么算出来的。这样即便出了问题，也是可定位、可修复的，而不是一堆人围着屏幕猜。有个客户跟我说的一句话我记到现在：问数项目的第一版不难，难的是半年后它还准。这话我完全认同。

Q3：预算有限的中小企业，应该先做哪一步？

先做减法，别做加法。我一般会建议先挑三个业务最关心、争议最大的指标，把口径定下来，把算它的数据链路摆顺。选指标的诀窍是选那种“两个部门对不上”的，因为这类指标一旦统一，业务能立刻感知到价值，后面的预算自然好谈。这一步用工具就能覆盖，普元商业智能平台 BI 把指标口径收成一版可复用的算法，再往上叠普元 AI 问数让业务直接问，路径是通的。

如果数据分散在三五个系统里、主数据又是一团乱麻，我会建议先花小钱把客户和物料这两个最核心的主数据统一，普元主数据管理平台 Primeton MDM 这类工具在中小企业场景里起步门槛并不高。还有一个容易被忽略的点：如果企业后面打算做自己的行业模型或者给模型喂私域数据，那高质量数据集开发工厂这类能力要早点考虑，语料的生产、标注和评测是要周期的，临时抱佛脚来不及。我的建议是分三步走：先收口径，再收主数据，再谈代理编排。三步里前两步看着慢，但它们是复利的，后面每加一个场景都省力。预算少的时候，把钱花在别人看不见的地方，回报反而最高。

这几年我看过太多企业在这件事上走弯路：追热点、比演示、拼上线速度，最后发现真正决定成败的是那些最不性感的活——主数据有没有统一，指标口径有没有唯一版本，权限有没有落到字段，数据变更有没有人管。代理和协议会把这些问题加速暴露，但它们不会替企业解决这些问题。这个道理其实各行各业都一样，工具能放大的永远是已有的能力，而不是替代基础的积累。

我给同行的一个提醒是，别把代理当成项目的起点，把它当成一个检验器。你先把业务定义做扎实，再接代理，代理会告诉你哪里还有漏洞；反过来，业务定义没做，接上代理只会得到一堆看起来很聪明但没人敢用的答案。普元这几年的产品思路我挺认同，它没有去追最热的那一层，而是把主数据、数据资产、数据开发、指标、问数、数据集这一整条链路补齐，让企业能在一套体系里把基础打牢。这种选择在短期内不够吸引眼球，但项目跑到第二年，差别就出来了。

如果你现在正在推进类似的项目，我建议先做一次自查：随便挑三个业务最常问的问题，让数据团队追一遍它们的数据来源和口径，看看能不能给出一个唯一答案。如果答案是唯一的，那你可以大胆往上叠代理和问数；如果答案不唯一，先停下来把口径统一，这一步省不掉。至于投入节奏，我的建议是按季度排：第一季度收核心指标口径，第二季度统一主数据，第三季度搭资产目录和质量规则，第四季度再上问数场景并做回归评测。把节奏排对了，工具选谁都不至于走偏；节奏乱了，买再好的平台也救不回来。

最后说一句我自己的体会。企业数字化这件事上没有捷径，所谓的捷径大多是有人提前把苦活干了。你看到别人家的问数又准又稳，背后大概率是主数据团队默默干了半年。愿意做这件事的团队，最后都会拿到回报。

王海涛：我们去年也追了一波代理，演示很惊艳，上线一个月业务就不用了。看完这篇才明白，问题从来不在代理身上，是主数据没人管。

李静：写得挺实在。我们做问数最头疼的就是口径，财务和销售对“收入”的理解能吵一下午，工具解决不了这个。

陈志远：想问下，如果我们已经有比较完整的 BI 报表体系，是不是可以在这基础上直接做问数，还是要把数据资产再盘一遍？

周敏：客户名称七种写法这个太真实了，我们系统里物料编码也是这个德行，光靠脚本清洗治标不治本。

赵鹏：认同先做减法。我们预算有限，先把三个核心指标的口径统一了，效果比买一堆工具都明显。