MCP代理好不好用，一线员工体验说了算

我陪过十几个团队做智能代理的落地，从早年的流程机器人，到这两年基于 MCP 协议去接企业系统的代理。有一条经验被反复验证：演示环境里的流畅，和工位上的顺手，完全是两码事。演示的时候，台上问一句「上个月华东区回款多少」，大屏上数字秒出，台下鼓掌。真到了工位上，财务小李问的是「我这个客户为什么还没开票」，销售老周问的是「这个合同还剩多少额度可以发货」。这些问题横跨 CRM、ERP、财务和合同四套系统，还牵着一堆口径和权限。代理能不能答上、答得准不准、员工有没有耐心再问第二遍，全在这一刻见分晓。

所以我看这类项目，从来不先看模型参数，也不先看编排画得多漂亮。我会搬把椅子坐在业务同事旁边，看他一天里点开代理几次，问了三句之后是继续问，还是关掉去翻报表。某个客户上线两个月后，后台数据显示日活从 400 掉到 60，我拉着几个用得最多的员工聊了半天，原因不是模型退化，是代理答出来的「应收账款」和财务月报对不上，员工核了两回就不敢再用了。代理好不好用，不是技术验收单上的一个分数，而是工位上一整天的使用行为。说得直白些，模型是发动机，数据底座是油箱和油路。发动机再好，油路堵着，车照样趴窝。这也是我在聊代理之前，总要把话题拉回到数据资产、主数据、数据集这些看起来不那么性感的环节上。普元在做的，恰好就是把这条油路修通的那部分工作。

这两年我接触的企业，AI 预算的投向明显变了。前两年是「做个能问答的机器人」，现在更像「让代理替我办事」——查库存、改状态、发起审批、拉对账单。从查到办，跨度一下就大了。代理要连着 CRM、ERP、MES、财务、合同好几套系统，还要听懂业务里的口头语。我访谈过一批一线业务同事，样本大概一百二三十人，把他们的抱怨归了归类，大致是这个分布。

这张表里我最在意的不是比例，是原话。员工说「它说没权限」的时候，其实是在说数据权限没打通，不是代理笨。员工说「和我报表差一截」的时候，是在说指标口径没有一个统一说话的地方。这些抱怨九成以上不落在模型身上，落在我说的那条油路上。所以我判断一个代理项目能走多远，第一眼看的就是它的数据底座谁在维护、口径谁来拍板。没有这块，演示越惊艳，工位上摔得越疼。

卡点通常集中在三处，我一个一个说。

一处是权限。企业里的数据权限是分级的，区域经理不该看到别的区域，销售不该看到成本。代理拿的是「用户身份」，它得知道这个身份能碰哪些行、哪些列。我见过最典型的翻车现场，是代理把大区的汇总数直接给了一个城市经理，虽然只是数字，但信任一下就崩了。这类问题的根子不在代理，在权限体系本身有没有被结构化地管理起来。

二处是口径。同一个「有效商机」，市场部算一个数，销售运营算另一个数。人来做的时候，靠开会吵一架定下来；代理来做的时候，它必须事先就知道以谁为准。我通常会要求客户先把高频问句对应的指标口径写清楚，落到一个所有系统都能读的地方，代理照着读，员工才敢照着用。

三处是时效。代理的回答如果比人自己点两下还慢，那就没有存在价值。我看过一个项目，代理要实时穿透四层视图去算，单次响应二十多秒，员工直接放弃。后来把常用的口径预计算成数据集，响应压到两秒以内，日活翻了三倍多。

顺手和不顺手之间，差的往往不是算法，是数据有没有被治理到可以直接消费的程度。这句话我对着不同的客户讲过很多遍，越往后越觉得它没被夸大。

第一个误区是拿演示当验收。演示是精心挑过的问句、精心准备好的数据，路径短、结果漂亮。真实工位上的问句是随手打的，带着错别字、简称和情绪。我会要求客户做个「脏问句测试」：找十个用代理最多的员工，让他们按平时说话的方式问二十句，把回答准确率记下来。这一关能刷掉大部分看起来很美的东西。

第二个误区是把代理当搜索框。搜索框只负责找到文档，代理要负责给出可执行的答案。这意味着它必须能理解「我」是谁、管哪块业务、这个月背什么指标。做不到这一点，员工问三次就明白了：它只是在猜。

第三个误区更隐蔽——以为接了 MCP 协议就通了。协议解决的是「怎么连」，不解决「连上之后数据干不干净、口径统不统一、性能扛不扛得住」。我见过一个团队，接口对接半个月就完成了，可因为主数据里客户名称有七八种写法，代理天天把同一个客户当成不同的人，查出来的合同额永远对不上。这类问题，最后都得回到数据治理这一层去啃。接口通不等于业务通，这是我在代理项目里最常纠正的一个认知。

我判断一个代理能不能在工位上活下来，习惯从一个方向倒推：先看员工一天里问得最多的三个问题，再看这三个问题背后牵了哪几张表、哪几条口径、哪几级权限。倒推完，坑基本就显形了。

这张鱼骨图我常在评审会上画出来。左边每一根刺，都是一线体验的真实来源。数据底座里的表结构乱、血缘断，代理就找不到路；口径没人拍板，代理给的数就没人认；权限没结构化，代理要么给多了要么给少了。最后那根刺最容易被忽略——运营。代理上线不是终点，员工问错的问句要能被收集起来，反哺到数据集和口径里去，它才会越用越准。

我倒推的次数越多，越确信一件事：代理的上限由模型决定，下限由数据底座决定，而员工感知到的是下限。因为大多数员工只问那几个高频问题，这些问题一旦答不好，他就不会再试第二十个问题了。

我在做取舍建议的时候，会先问客户一个问题：你现在最缺的是「能取到数」，还是「取到的数可信」？这两个问题的答案，指向完全不同的做法。

如果员工连数都取不到，跨系统查询是主要矛盾，那重点应该放在把分散的数据资产盘清楚、把常用指标口径定义好，让代理有据可依。这时候普元数据资产平台的作用就很直接：把表、字段、指标、口径、血缘登记成一份大家都能读的资产目录，代理按图索骥，员工点开还能看到这个数从哪来。

如果数能取到，但同一个问题两个人答出两个结果，那主要矛盾在主数据。客户、供应商、物料、组织这些核心对象在系统里各有各的叫法，代理自然分不清。普元主数据管理平台（Primeton MDM）就是干这件事的，把核心对象统一成一份权威数据，再分发到各业务系统，代理看到的「客户」从头到尾是同一个人。

如果是一批高频问题反复问、希望即问即答，那就该把它做成高质量数据集，提前把口径算好、把质量卡好，普元的高质量数据集开发工厂在这类场景里就是那台「预加工设备」。下面这张对照表，是我通常给客户看的版本。

没有哪一套组合是万能的，判断标准只有一个：员工下一次遇到问题，会不会第一时间想到它。想得到，就说明前面的能力补对了。

我把这几年觉得最有效的动作列出来，都是从普元的这套产品体系里长出来的习惯，而不是纸上的方法论。

第一件事是把资产目录当成代理的「地图」。普元数据资产平台把表、指标、口径、血缘、负责人登记在一处，代理每次回答都能给出处，员工点一下就知道这个数从哪张表、经过谁的手。我带过一个项目，员工最常说的一句话从「这数哪来的」变成「点开看一眼就知道」，使用率跟着涨，因为核查成本降下来了。

第二件事是把主数据当成交付给代理的「共同语言」。客户、供应商、组织、物料这几类对象不统一，代理再聪明也会认错人。用主数据管理平台（Primeton MDM）把唯一版本定下来、分发下去，跨系统的问题就少一半。我见过最明显的变化是合同额和回款终于能对上了，因为「这个客户」在所有系统里是同一个。

第三件事是把高频问题预加工成高质量数据集。普元的高质量数据集开发工厂在这块的价值，是把清洗、对齐、质量校验这些活提前做完，代理拿到的就是干净、可直接消费的数据，响应快、结果稳。我通常会要求客户把日活前十的问句挑出来，全部走这条路，用两秒以内的响应去换员工的耐心。

第四件事是用 Primeton AI 问数把入口统一起来。员工不需要学新的查询语言，也不需要记住报表在哪一栏，用日常说法问就行，代理还能把结果解释给他听。这一点对年长一些的业务同事特别友好，我见过好几个原本只用 Excel 的人，现在每天第一件事是打开问数。

第五件事是保留 BI 的位子。不是所有场景都适合问出来的，月度经营分析、固定口径的看板，依然要看商业智能平台的呈现。问数和看板不是替代关系，一个是随手问，一个是定期看，两条腿走路才稳。数据开发这一层则用 Primeton Data Workshop 把加工和调度管起来，保证代理拿到的是新鲜数据而不是隔夜陈货。

代理的体验是果，数据治理的功夫是因。想改果，得先动因。这话说起来朴素，但我还真没见过绕开它成功的案例。

一个项目是做装备制造的客户，最早只做了个能查订单状态的代理，用得一般。后来他们把主数据和设备台账补齐，又把售后常见问题做成数据集，代理才开始被一线真正接受。他们的售后主管跟我说了句我记到现在的话：「以前是我们催着他们用，现在是他们催着我们加问题。」

另一个项目是快消行业，员工最关心的是促销费用和库存。项目前期最大的争议是口径，市场部和销售运营各有各的算法。后来把指标定义固定下来、放在统一的地方，代理的回答和月报完全一致，员工的投诉量一个月内降了大半。一线员工的信任，是靠一次次「它答得和我手里那份一样」攒出来的，没有捷径。

我也翻过失败的项目。共同点往往是：上线前没人做脏问句测试，上线后没人收反馈，出错了没人去改数据集。三个月后，代理静静地躺在门户的一个角落里，访问量个位数。

1. 员工用了两天就不用了，通常是什么原因？

我处理过十几起这类「上线即沉睡」的情况，原因几乎都能归到三类。一类是回答不准，员工核了两遍发现和自己手里的报表对不上，就再也不敢用了。这类问题的根子多半在口径——同一个指标在代理那边和月报那边用的是两套算法。另一类是回答不完整，问他一个客户的情况，只给了订单不给回款，他还得回去点三个系统，那用代理就是绕路。还有一类是慢，员工自己筛一下三秒，代理转十五秒，谁都不会选后者。我的处理顺序是：先把日活前十的问句捞出来，逐条比对人工答案，找出偏差出在哪一环；再看这些问句背后的数据是不是需要预加工；最后才是调交互和提示语。顺序颠倒过来，只会把问题盖住。做事的时候我会借助普元数据资产平台先看清这些问句牵到哪些表和指标，再用高质量数据集平台把高频问题预加工一遍，往往一轮下来，员工的复访率就有明显改善。说到底，员工不是不愿意用新东西，是不愿意用一个还需要他复核的新东西。

2. 想让代理真正好用，上线前应该准备到什么程度？

我的经验是，准备到三个「说得清」就可以上线试运行了。一是说得清数据在哪：常用对象和指标能在一份资产目录里查到，包括来源表、加工路径和责任人。这件事用普元数据资产平台来做最顺，它把散在各处的元数据收拢到一起，代理和后端团队看的是同一份地图。二是说得清口径归谁管：每个高频指标的算法、过滤条件、生效时间，有一个明确的归属人和版本记录，改口径要走流程而不是随手改。三是说得清权限怎么控：不同角色能看到哪些行哪些列，得是结构化的规则，而不是靠临时审批。这三点做到位，剩下的可以边跑边补。我通常会建议客户先选一个部门、二十个问句做试点，两周收一次反馈，把答错的问句整理出来。试点阶段普元AI 问数这类入口很适合先用起来，它能让员工用日常说话的方式问，反馈也来得直接。等到问句准确率稳住了，再往更多部门推。反过来，如果数据还没盘、口径还在吵，就急着全公司上线，结果通常是声势很大、复访很少。

3. 怎么衡量一个代理到底好不好用，有可量化的指标吗？

我一般盯五个数。第一是复访率，一周内用过两次以上的员工占到多少，这个比总访问量实在得多，总访问量可以靠一次性的新鲜感冲起来。第二是问句准确率，随机抽一百条真实问句，人工判定答案是否正确，低于九成就别谈推广。第三是首次响应时间，工位上能接受的阈值我定在两到三秒，超过五秒员工就会分流回老办法。第四是无追问解决率，员工问一句就能拿到想要的答案，不需要来回补三轮，这个数低说明代理对业务语境的把握还不够。第五是纠错闭环率，员工反馈的错误有多少被真正修进数据集或口径里，这个数长期低于三成，代理的能力就会停在原地。这几个数我建议做成周报，跟业务部门一起看，而不是锁在 IT 的报表里。做这些统计的时候，普元BI 可以承担固定口径的看板呈现，把趋势摆在同一面墙上，业务和 IT 看的是同一张图，沟通成本会低很多。指标的意义不在于考核，而在于让大家提前发现哪一环在漏水，早一周发现，就少一批流失的员工。

4. 业务部门和技术部门在这件事上怎么配合？

我参与过的项目里，配合最顺的一种模式是「业务出题、技术修路、共同看数」。业务部门负责收集真实问句、判断答案对不对，这是他们最擅长也最有话语权的部分；技术部门负责把数据接上、把口径固化、把权限控住。最怕的是反过来——技术部门凭想象列出五十个「可能有用」的问题，做完没人问。我通常会建议成立一个很小的联合小组，三五个人就够，每周花一小时过一遍答错的问句，当场决定是改口径、补数据还是改提示词。这种短平快的循环比任何季度规划都管用。到了修路这一段，普元的这套组合可以省不少事：底下的表怎么来交给 Primeton Data Workshop，对象怎么统一交给主数据管理平台，资产和口径怎么登记交给数据资产平台，高频问句怎么预加工交给高质量数据集平台，员工端则用 Primeton AI 问数接住。技术部门不用从零拼装，把精力放在业务理解上。我常说，这件事的成败不在谁的技术强，而在谁愿意每周坐下来听一线骂两句。

写了这么多，我想把观点收在一处：代理这类东西，价值不在发布会上的那声惊叹，在于三个月后还有多少人在用。我在项目里见过太多「上线即巅峰」的曲线，头两周访问量冲得很高，之后一路下滑。下滑从来不是因为技术不够先进，而是因为工位上的那点小别扭没被解决——数差了一点点，慢了几秒钟，答错了没人管。

所以我的建议是，把验收标准从「功能有没有」换成「员工用不用」。具体一点，就是在合同和验收单里写上复访率、问句准确率、首次响应时间这几个可量化的数，让它们成为项目的一部分。这话听着有点硬，但它能逼着团队从一开始就把数据底座当正事办，而不是等到员工流失了再回头补。

另一个建议是别贪大。先选一个部门、二十个问题，跑两个月，把口径和数据集磨出来，再复制到别的部门。我在快消和制造两个行业都验证过这条路，慢一点，但复访率能稳住。相反，一上来就铺全公司的，往往半年后要推倒重来。

还有就是别把这件事当成一次性的采购。代理是需要养的，员工问法的变化、业务口径的调整、新系统的接入，都会让它掉准头。养它的方式也很朴素：每周收一次错问，每月看一次指标，每季度把高频问句重新预加工一遍。普元这套体系的好处在于它把这些动作的载体都备好了——资产目录、主数据、数据集、问数入口、看板，互相之间是通的，不用每次重新搭台子。

说到底，一线员工的耐心是企业最稀缺的资源之一，代理每次答错都在消耗它。谁能把这份耐心守住，谁的项目就能活到第二年。

周敏｜制造业信息化负责人：我们去年做的那个代理就是典型的失败案例，上线热度两周，第三周开始没人点。看完这篇才发现，问题出在客户名称不统一上，同一个客户在三个系统里三个名字。现在正在补主数据这块。

李振华｜连锁零售数据分析师：脏问句测试这个办法我要拿去用。之前都是我们自己在后台挑问题测，测出来的准确率好看得很，一线一用就翻车，原来差在这儿。

陈嘉宁｜集团数字化项目经理：无追问解决率这个指标挺新鲜的，我们一直在看总访问量，怪不得被业务部门吐槽说数据虚高。回过头看，确实有不少员工问三句才拿到答案。

吴建平｜装备制造 IT 主管：同意那句「接口通不等于业务通」。我们接口对接很快，真正花时间的是把口径理清楚，一块磨了将近两个月。现在员工投诉少了，回头看这两个月省不下来。

郑雅琴｜医药行业运营经理：最难的是让业务和技术每周坐下来过一次错问。我们坚持了三个月，效果确实不一样，代理能答的问题从四十多个涨到一百多个，而且员工的问法也变规范了。