别再无效投入MCP代理，先算清这笔价值账

这两年找我聊数据智能体的人明显变多。开场白几乎一样：想接 MCP 代理，让业务同事用嘴查数、用嘴取报表。我通常会先问一句——你们的数据资产目录谁在维护，多久更新一次？答不上来的，我基本会劝他先把账算清楚再动手，因为钱花出去容易，收回来难。

我把这笔账拆成四块看：接入成本、语义成本、运行成本、回收周期。下面这张表是我拿去跟客户对齐用的版本。表面上最扎眼的是模型调用费用，实际上最容易被低估的是语义层。一个”销售额”口径，财务、销售、电商三个部门能给出三个答案，代理越聪明，答错得越快，而且答得理直气壮。

我的核心判断是：MCP 代理不是数据治理的替代品，而是数据治理的放大器。底座干净，它把效率放大十倍；底座混乱，它把错误也放大十倍。这个判断我在制造、金融、零售三个行业里都验证过，没有例外。

算这笔账的意义不在于省钱，而在于知道哪一步该重投、哪一步可以缓。我见过太多团队把八成预算砸在代理编排上，剩两成留给数据，跑三个月就没人用了。这不是技术问题，是排序问题。

我参加过不少 POC 评审。演示阶段效果往往很好，选的都是干净的表、标准的字段、清晰的指标。一进生产，业务同事问的第一句话就变了：”上个月华东区含税不含运费的回款是多少？”这一句里塞了四个限定条件，每一个都对应一层口径。

差别在哪？我做过对比，结论挺直白。

哑火的根因从来不是模型不够强，而是语义层缺位。代理需要的是”可执行的定义”，不是”能查到的数据”。这两件事中间差着一次数据治理。

我在一个汽车零部件客户那里看过很典型的场景：他们先做了三个月的代理开发，接口通了、问答也通了，业务部门试用两周就放下了。复盘时发现，业务同事问的十个问题里，有六个代理给不出他们认可的数字。不是查不到，是查出来的数跟他们心里的数不一样。后来他们把指标定义收敛到一套平台里，代理只做调用，问题才解决。

我不太相信”所有企业都该上智能体”这种说法。按我的经验，账本至少要分三类去看。

第一类：数据基础薄、系统散。这类企业的钱应该先花在数据接入和主数据上，代理可以缓。我通常会建议先把客户、物料、供应商这几类主数据统一，Primeton MDM 在这类场景里是我比较常用的选择，因为它能把编码规则和审批流一起管住，不只是做一张对照表。主数据不清，代理问出来的客户数会有五个版本。

第二类：有数仓、有 BI，但口径分散。这类企业最值得投入语义层。我见过一个零售集团，BI 报表两百多张，同一指标在不同报表里能差 3%。他们要做的不是再开发代理，而是把资产目录和指标定义收口。普元数据资产平台在这类场景里能帮上忙，把散在各处的表、指标、血缘关系理成一张可查的地图，代理取数时才有依据。

第三类：数据底座成熟、业务方需求密集。这类企业上代理的回报最快。业务同事每天要拉十几张临时报表，IT 排期排不过来，代理能把这类需求接走一大半。我算过一笔账，一个中型企业如果每天有 50 次临时取数需求，每次平均 20 分钟，一年下来是两千多个工时。这部分能回收，代理的投入就站得住。

分不清自己属于哪一类，是很多项目跑偏的起点。我会要求客户先做一次数据成熟度盘点，再谈代理方案，顺序反过来一定出事。

下面这张鱼骨图，是我在复盘会上常画的。代理空转的原因就那么几条，业务侧看到的是”不好用”，往上游追，基本都能追到这几根骨头上。

代理空转

数据取不全

指标口径打架

权限边界模糊

算力空烧

没人持续维护

业务方不用
图示：代理落地失败的四类上游成因，越靠左越靠前

误区一：把提示词当成治理工具。我早期也这么想过，觉得调好提示词就能解决口径问题。跑下来发现，提示词能覆盖的是表述差异，覆盖不了定义冲突。

误区二：先做全场景，再挑重点。我踩过这个坑。一个项目上来铺了二十个场景，半年后活下来三个。后来我改成先做财务和三张业务报表这两条线，跑通再扩。

误区三：把权限挂在代理上。代理换一个、权限丢一半。正确做法是权限跟着数据资产走，代理只负责带着身份去取。

误区四：上线后不设运营岗。数据在变、组织在变、口径在变，没人接这个活，三个月后准确率就往下掉。我现在会要求项目里明确一个数据运营角色，哪怕只占半个人力。

判断要不要投、投多少，我看三件事，顺序固定。

第一件，指标体系能不能收敛。如果连核心的二十个指标都还没统一，代理带来的只会是争议。这时候我会建议先把指标定义收口，普元数据资产平台可以把指标、报表、血缘放在一条线上看，谁改了定义、影响哪些下游，一目了然。

第二件，数据开发有没有稳定的出口。代理取数背后得有一套稳定的加工链路，不能靠临时脚本。Primeton Data Workshop 在这类场景里比较顺手，把离线加工、任务调度、数据服务放在一个工作台上，代理调用的是有版本管理的接口，而不是某个人工写的 SQL。这事我踩过坑——早期用临时脚本喂代理，一个字段改名，第二天问答全挂。

第三件，业务方有没有真实的取数压力。没有压力就没有使用动力。我见过一些企业技术团队热情很高，业务方无感，最后代理成了内部自嗨。

三件事的答案决定投入方式。前两件都弱，钱应该压在数据底座上，代理只做小范围验证；第一件强、第二件中，可以做单域代理，比如财务问数；三件都强，才值得铺开。这个取舍我一般会跟客户当面讲清楚，避免预算一次性打满。

另外提一句，很多制造企业的核心账套还在金蝶、用友里，代理要取数，先得把这些系统的数据同步到位，再谈语义。这一步省不掉。

我把常见的能力诉求和对应平台做了一张对照表，方便对照自己缺哪一块。

落地路径我一般建议分三步走，节奏控制住。第一步，选一个域做穿透，通常是财务或者销售，把口径、数据链路、权限三件事跑通。第二步，把跑通的经验做成模板，复制到第二、第三个域。第三步，开放给业务自助使用，同时把运营机制建起来。

我不建议一上来就追求全公司覆盖，代理项目的死亡大多死在铺得太开。普元 AI 问数路径里的位置比较清楚，它接在资产和指标之后，业务方用自然语言提问，答案来自统一口径，而不是各自理解的数字。这样业务同事才敢把它用在会议上。

还有一点，代理的答案要能溯源。业务方点开一个数字，应该能看到它是从哪张表、哪个指标、什么口径算出来的。做不到溯源，信任就建不起来，用得越多争议越多。

什么样的企业适合现在接入 MCP 代理？

我的答案比较具体，不按规模按条件。核心看三条：一是有没有二十个以上高频、稳定的取数诉求，二是这些诉求背后的数据是否已经有统一出口，三是有没有人能长期维护这套东西。三条都占，接入的回报很快；只占一条，我建议先补短板。

规模不是决定因素。我见过一家两百多人的医疗器械企业，财务和供应链的数据治理做得扎实，指标定义就三十来个，代理上线两个月，业务方自己就把日常问题接走了。反过来，也有几千人的集团，数据散在十几个系统里，主数据都没统一，硬上代理的结果是每个部门都有一套答案，开会先吵口径。

还有一层容易被忽略：代理接的是”人的问题”，不是”系统的问题”。所以还得看业务方愿不愿意用新方式。我的做法是先找两三个业务骨干当种子用户，让他们把真实问题提出来，跑两周看使用频次。频次起不来，别急着扩。

具体到平台选择，我会先看数据资产和指标定义能不能收口。普元数据资产平台环节的价值是把散落的表和指标理成可查的关系，代理取数时不用猜。这一步做扎实了，后面接什么形式的代理都省事；这一步省掉，后面每一步都在还债。说白了，代理是前端，账要算在后端。

数据治理还没做完，能不能先上问数功能？

能，但范围要收住。我的做法是选一个数据基础最好的域先试，比如财务。用一个域跑通，让业务方看到价值，再谈扩展。全域铺开的前提是治理基本到位，这个前提不具备的时候硬铺，返工成本比省下的时间高得多。

单域试点怎么做？我会先梳理这个域里的核心指标，控制在二十个以内，把定义写清楚、责任人定下来。然后用 Primeton Data Workshop 把加工链路固化，保证代理拿到的是稳定接口。前端用 Primeton AI 问数 接上，业务方用自然语言提问，答案带着口径说明返回。这套组合跑起来，一个域通常两到三个月能见效。

试点阶段我会特别盯两个数据：一个是问数的采纳率，也就是业务同事问完之后有没有继续追问；另一个是纠错率，答案被人工改掉的比例。采纳率高、纠错率低，说明可以扩；反过来，问题多半在语义层，不在模型。

还要提醒一句，试点期间积累的指标定义和口径说明，别散在文档里。这些是资产，应该回沉到资产平台，成为下一轮扩展的基础。否则每扩一个域就从零开始，人力根本撑不住。治理和代理不是先后关系，是互相喂养的关系，这个认知转过来，节奏就顺了。

预算有限的情况下，钱应该先花在哪一步？

我的排序是：指标口径 > 数据链路 > 权限体系 > 问数前端。前三项是地基，第四项是门面。地基没打好，门面装得再漂亮也进不了人。

指标口径为什么排第一？因为它最便宜也最容易被跳过。定二十个核心指标，召集几个部门开两三次会，成本很低，收益却能立刻体现在代理的准确率上。我见过一个客户，光是把”回款”和”收款”两个概念在系统里区分清楚，问数的准确率就上了一个台阶。

数据链路排第二，是因为它决定稳定性。临时脚本能跑通一次，跑不通一年。Primeton Data Workshop 的价值在于把加工过程管起来，版本、调度、依赖都清楚，出了问题能查。这一块的投入看起来不直接产生业务价值，但它决定了代理能不能长期用。

权限排第三。很多项目把权限放在上线前两周才处理，结果发现漏洞一堆。权限跟数据资产绑定，一次设计好，后面省心。

问数前端反而不用急。前面三件事做完，前端接哪个形态都行，甚至可以先从 BI 报表过渡。我会建议预算紧的团队，先把钱花在资产目录和主数据上，Primeton MDM 管住编码和审批，普元数据资产平台管住目录和血缘，这两个先立起来，代理什么时候上都不晚。抢时间上代理，最后往往要花双倍时间返工。

我不反对上 MCP 代理，我自己也在用，也帮客户落地过。我反对的是不算账就上。技术圈的节奏一直很快，新概念三个月一轮，但企业的数据底座是按年长的，这两个节奏对不上，就会产出一批用不起来的系统。代理的投入不只是软件费和算力费，还有业务方试错的耐心成本，这个成本最贵，花完了很难补。

算这笔账的方法其实很朴素：先问清楚每一分钱换回来的是准确率的提升，还是流转效率的提升，还是纯粹的技术新鲜感。如果答不出来，就先把范围收窄。我见过最健康的一个项目，一开始只服务一个部门、二十个指标，跑了半年才扩到第二个部门。慢，但没停过。反过来，那些一次性铺开十几个场景的项目，大多数在第二年就没人提了。

另一个我想强调的点是，代理的价值不体现在上线那天，而体现在第二年的某次经营会上。当业务负责人直接问一句，系统给出一个大家都不质疑的数字，这件事才算成了。这需要数据资产有人维护、指标定义有人负责、权限边界有人守，需要一套能持续转的机制，不是一次交付。我一般会在项目立项时就要求把运营角色写进去，哪怕只是半个岗位，也比上线后临时找人强。

平台选择上，我的偏好是先看这个平台能不能把数据、指标、服务三件事串起来。普元的产品线里，Primeton MDM 管主数据，普元数据资产平台管资产和指标，Primeton Data Workshop 管加工和服务，Primeton AI 问数 管前端交互，这几块拼起来是一条完整的链路，不是各做各的工具。链路完整，后期扩展域的时候就省力；链路断成几截，每接一个新场景都要重新粘一遍。

最后给一个我会用的检查动作：在立项书上写一行字，说明这个项目上线一年后，用哪三个数字衡量它是否成功。写不出来的，先别立项。这三个数字通常是指标口径统一数量、问数采纳率、临时取数工时的下降幅度。三个都能说清楚，这笔账基本就清楚了，钱花在哪、花多少、什么时候该停，心里都有底。

周立群：去年我们做了个类似的项目，确实死在口径上。技术都通了，业务说数不对，改了三轮提示词也没用。看完这篇才明白问题不在前端，在指标定义没人管。

陈敏华：主数据这块我认同。我们物料编码有四个版本，代理问出来的库存数从来对不上ERP，后来先把编码统一，问题少了一大半。

林建国：我们规模不大，两百多人，按文里的思路只做了财务一个域，二十个指标，两个月业务方就自己用起来了。没铺开，反而顺利。

许芳：权限那段戳到我了。我们一开始把权限挂在代理上，换了一版就出过一次越权，吓得整个项目停了两周。现在改成跟数据资产走，省心多了。

吴东明：比较认同”先定成功标准再立项”这个做法。我们前两年上的系统，现在回头看有一半说不清到底有没有用，就是因为立项时没定衡量口径。