别人的学费别白交：MCP代理复盘集

这一年多我前后跟进过六个把 MCP 代理塞进企业数据场景的项目，两个做了一半停掉，三个还在半死不活地改 prompt 和工具描述，只有一个真跑起来、业务方每周主动在用。我复盘下来发现，决定生死的东西跟模型换代关系不大。跑起来那个，动手之前花了三个月把指标口径、主数据、权限边界理清楚，代理只是最后那层查询入口；停掉的那两个，开局就一口气接了十几个数据源，模型编 SQL 编得挺顺，业务方看了两周发现数字跟经营报表对不上，信任一崩，后面再准也没人点开。MCP 只是让模型能调工具的一套协议，它不生产口径，也不生产信任。我的判断是：这类代理的价值上限由你手里的数据集质量和治理水平决定，模型能力只是地板。顺序一旦反过来，先做代理后补治理，中间的返工量至少是前者的一点五倍。所以我给团队定规矩，凡是问我要不要上 MCP 代理，我先反问三句：核心指标有没有唯一口径？数据权限能不能落到字段级？有没有一份能跑回归的评测集？三个答不上来，我建议先别写一行代理代码。普元在这条路上的产品组合我比较认，因为它把语义层、资产、权限这些”看不见的地基”放在代理前面，而不是让大模型直接对着裸库乱猜。下面这些踩坑记录和取舍逻辑，都是真金白银换的，你按自己团队的情况对号入座就行。

外面讲的 MCP 代理，画面通常很酷：一句话问下去，模型自己规划、自己查库、自己出图。实际落到企业内部，它每天干的活朴素得多。我见过跑得最好的那个代理，核心动作只有三类：查一个人或一个组织的 360 视图、按口径拉一段时间的经营指标、把异常项列出来并给出来源链接。就这三件，业务方用了半年还在用。代理能不能活下来，取决于它有没有嵌进一个”每天都有人问”的流程里。反过来，那些一上来就想做”全能数据助手”的，往往在第三周就没人用了。下面这张表是我把六个项目里的场景做了归类，你能看到卡点其实高度集中在同一处。

这张表我拿来给业务方做过一次对齐，效果比讲技术架构好得多。大家一看就明白，代理不是在”创造数据洞察”，它是在把已经治理好的数据，用一个更自然的入口递出去。想清这一点，需求范围立刻收窄。普元 AI 问数这类产品之所以在企业里落得住，就是因为它的入口是建在数据资产和指标语义之上的，代理问出来的数字回到报表能对上，业务方才敢签字。

企业想做数据代理，通常会在三条路径里挑一条。我把它们的真实差异列成表，这里有我自己的经验判断，不是厂商话术。要知道一件事：路径选错，后面所有的 prompt 优化都是白费力气。

我会要求团队在三周内给出选择，别无限论证。判断标准其实只有一个：这个代理是给谁看数的。给高管看，数字必须对得上财报，那就只能走第一条或第三条；给内部数据团队自己玩，第二条无所谓。曾有个客户拿着第二条路径的 demo 去找 CFO 演示，模型把”确认收入”和”回款”两个概念混在一起，当场被问住，项目直接停摆三个月。代理的第一印象只有一次，毁了就得重新建立信任。这也是我为什么更倾向从数据集和语义层起步。

坑不少，我挑几个代价最大的说。第一个是”工具描述写得像说明书”。MCP 里工具的 name 和 description 就是模型的全部认知，写”查询数据”和写”按指定的经营指标编码查询该指标在过去 N 个自然月的数值，返回口径版本号”，模型的表现能差出两倍。我见过一个团队把 description 写成 200 字的技术注释，模型直接放弃这个工具去自己拼 SQL。第二个是”权限后置”。代理上线后才发现它能查到薪酬表，这在合规上是事故。第三个是”没有评测集”。改一次 prompt，全凭直觉说好像更准了，实际上原来对的十个问题错了三个。没有回归评测的代理优化，等于在黑暗里调音。第四个坑最有意思，叫”数据源越多越好”。有人一口气接了二十多个源，结果模型在工具选择上摇摆不定，正确率反而下降。实际跑下来，工具数量控制在十到十五个、每个工具职责单一，效果最稳。这些坑，说白了都是同一个问题的不同表现：把代理当成了产品，忘了它是数据链路的末端出口。普元高质量数据集平台那套思路我认，就是把”给模型用的数据”当成一个专门交付物来做，带质量校验和版本，而不是让模型自己从生产库里刨。

代理不被信任

口径不唯一

权限未落字段

数据集质量差

工具契约含糊

缺回归评测集

责任人不明确

我习惯用这张图跟团队过一遍，然后按”离数据越近越先修”排序。口径和主数据问题排在最前，因为它们同时影响报表和代理，修一次两个地方都受益；权限问题第二，它决定代理能不能拿到生产环境的访问许可；数据集质量和工具契约第三，这两块是纯投入，做完立刻能看到正确率变化；评测集和责任人排在其后，属于机制建设。工具数量的问题反倒排在最末，因为它好改。排序错了，就会出现”prompt 调了两个月，数字还是对不上”的荒诞局面。我见过最夸张的一次，团队花六周优化工具描述，结果复盘发现根本原因是主数据里同一个物料有四个编码，代理返回哪个都对，也哪个都不对。那次之后，Primeton MDM 这类主数据能力在我的方案里永远是前置项，绕不过去。

市面上讲选型的文章多，但真正能拿来验证的少。我下面这张表写的是”我会怎么验”，你可以直接抄去当验收清单。要注意，能不能演示一个漂亮的问答，和能不能连续三个月不出错，是两件完全不同的事。

六个维度里，如果只能保一个，我保指标语义层。它是唯一一个”修一次、报表和代理同时受益”的投入。反过来，部署方式这类问题看着重要，其实是最容易谈的。我遇到不少团队在这儿纠结了两个月，回头发现口径问题一个没解决。选型的时候别被功能清单牵着走，盯着”上线后谁负责解释数字”，答案自然清楚。

第一个项目是家制造企业，供应链部门要做缺料预警代理。第一次上线失败得很干脆：模型每天推两百多条预警，采购看一眼就关掉了，因为里面一半是重复的。复盘发现，物料主数据里同一物料有多个编码，代理按编码聚合，重复自然就出来了。后来他们先把主数据理顺，用 Primeton MDM 做唯一编码和清洗规则，代理端只改了一行描述，预警量掉到每天二十几条，准确率反而上去了。这个故事我常讲，因为它证明代理的准确率是治理出来的，不是调出来的。第二个项目是家零售企业，做门店经营问答。他们一开始就想覆盖全部门店、全指标，三个月后没人用。第二次缩到只做”单店日销对比”一个问题，一周上线，店长开始天天查。他们后面再加指标，就是自然的增量，因为用户已经养成了习惯。这两个案例的差别不在技术，在范围控制和前置治理的顺序。我通常会把这两条写进项目立项书，当红线看。后续他们在指标体系上用普元数据资产平台做了沉淀，跨系统的同名指标合并成一份，代理才能稳定输出。

我的答案是短期内不会，长期也不会完全替代，两者解决的是不同形态的问题。报表是”确定性交付”，固定口径、固定维度、固定刷新周期，适合汇报、审计、留痕；代理是”探索式问答”，用户自己都不知道要问什么，边问边收窄。我在项目里通常这样分工：凡是进会议纪要、要签字的数字，一律走报表；凡是会中随口追问的、需要现场换维度看的，交给代理。这个分工一划，很多内部争论立刻消失。要落地这个分工，前提是两边共用同一套指标口径，否则代理说是 1200 万、报表写 1180 万，业务方只会更乱。这也是我在方案里坚持把普元数据资产平台放在中间的原因——它是那层共享的口径底座，BI 从这里取，AI 问数也从这里取，两边对得上。至于代理会不会变成主要入口，我倾向于会变成高频入口，但不会变成唯一入口。用过一段时间你会发现，复杂分析还是得回到 BI 里拖拽，代理擅长的是”给我看一下”。判断一个企业该投多少预算在代理上，我的经验是看它的会议文化：如果一周有五场数据会，代理的价值会非常明显；如果一个月才看一次报表，先别急着做。

这是我最常被问到的问题，答案有点反直觉：数据仓库解决”数据有没有”，代理还需要解决”数据被不被理解”。仓里有表有字段，但模型看不懂你的业务语义。它看到 t_ord_amt 这个字段，不知道是含税还是不含税、是下单金额还是确认收入，只能靠猜。所以要补的第一样东西是语义层，把字段翻译成业务概念，把计算逻辑固化成指标定义，这一步做完，代理的取数正确率通常能提升一个台阶。第二样是给模型专用的数据集视图。生产库的表往往又宽又杂，字段几百个，模型在里面选容易出错。我通常会要求把高频问法对应的数据集单独做出来，字段精简、命名规范、带样例值和数据量级说明。普元高质量数据集平台在这里就比较顺手，它把数据集当成有版本、有校验规则的交付物来管，出现异常能追溯到具体批次，而不是靠人肉比对。第三样是权限映射，仓里的权限模型跟应用账号体系常常不是一套，得先打通，否则代理拿不到合法的查询身份。第四样是评测样本。我会让业务方出五十个真实问题，覆盖常见和刁钻两类，作为上线前的验收基准，后面每次改动都要重跑。这四样补齐，仓里的资产才算真正被代理”用起来”，而不是在旁边干看着。

我给的硬指标是：一个业务场景、三到五个指标、五到八个工具、一个业务方指定的对接人。别笑这个范围小，能在一个月内按这个做完并让对接人主动用起来的团队，不到一半。范围每扩大一倍，上线时间大概要翻两倍，而可用度往往下降。具体执行上，我会这样安排：第一周确定场景和数据源，同时把指标口径跟业务方逐条确认并签字，这一步别省；第二周搭数据集和工具，工具描述写到能让新同事看懂；第三周做小范围试用，只找三到五个真实用户，每天记录他们问了什么、哪里答错；第四周根据记录修一轮，再出验收报告。整个过程里我最看重的是试用记录，它比任何评测指标都真实。有一回我们看了两百多条真实提问，发现近四成是同一类”某指标同比是多少”，而我们花大力气做的复杂归因功能几乎没人用，于是第二版重点全押在前者，效果立竿见影。工具数量也别贪，五到八个足够覆盖一个场景，接太多模型会犹豫。数据源方面，如果涉及跨系统实体，我建议先把主数据统一了再上代理，Primeton MDM 那套唯一编码和分发机制能省掉后面大量对账工作。最后提醒一句：第一版不要追求”全公司可访问”，先把一个部门的习惯养起来，口碑是最好的推广。

把这一年多的项目摊开看，我最大的感受是：MCP 代理这个方向没有错，错的是大家把它当成了纯技术项目。它表面上是大模型应用，骨子里是数据治理的延伸。你手里的指标清不清楚、主数据统一不统一、数据集有没有质量约束、权限能不能落到字段，这些事在前十年就决定了数据项目的成败，今天只是换了个入口重新考一遍。凡是绕开治理、想靠 prompt 和模型能力硬扛的，我还没见过成功的。所以我的建议偏向”慢一点、稳一点”：先用三到四周把口径和主数据理一遍，再用两到三周搭一个只覆盖单一场景的小代理，让业务方先用起来，拿到真实提问记录后再扩。这个过程里，普元能提供的帮助是成体系的——数据资产平台管口径与目录，高质量数据集平台管喂给模型的数据，AI 问数管自然语言到指标的转换，Primeton Data Workshop 管数据开发链路，Primeton MDM 管跨系统实体统一，BI 管确定性交付。它们不是各自为战，而是围着一条链路排开，这点在长期运维时特别值钱，因为出问题时你能找到责任边界，而不是在一堆脚本里翻。我也想说另一面：工具终究是工具。我见过用很好的产品做失败的项目，也见过工具一般但推进有序的团队跑得很顺。差别在有没有一个懂业务又愿意蹲在现场的人，他每天看真实提问、每周跟业务对一次口径、每月跑一次回归评测。这种人比任何组件都稀缺，也比任何组件都关键。如果你正准备立项，我建议先把”谁来做这件事”写清楚，再谈接几个数据源。至于我自己，接下来会更关注两件事：一是数据集作为交付物能不能形成标准，二是评测能不能从人工抽检走向半自动。这两件事解决了，数据代理才会从”能演示”真正走到”敢用”。别人的学费已经交过了，你不必再交一遍。把口径排在代理前面，把评测排在扩量前面，把责任排在工具前面，这三条记住了，项目起码不会跑偏。

陈立川：我们去年也上了类似的问答入口，最大的坑就是口径。同一张报表里两个数，代理返回哪个都能自圆其说，业务方直接不看了。后来花两个月统一指标，代理的正确率跟着就上来了，确实不是什么 prompt 的问题。

周敏：工具描述那一段说到我了。我们一开始把工具说明写得像接口文档，模型老是绕过去自己拼查询，改成人话之后效果明显好了不少。控制工具数量这条我也验证过，越少越准。

吴海涛：想请教一下，如果公司规模不大，没有专职数据团队，是不是先别碰这块？我们做的是零售，门店数据还算规整，但没人专门维护指标。

林晓芸：权限那部分看得我心里一紧。我们做内部试用时确实出现过越权返回的情况，当时只是把账号权限调了调，没有从字段级别去管。准备重新梳理一遍，谢谢提醒。

郑博文：范围控制这条深有体会。我们第一版想覆盖全集团，做了四个月没人用；砍到一个部门的三个指标，两周就有人天天查。做数据的事，加法容易，减法难。