MCP代理正在被这些趋势重塑

我的核心判断：代理的胜负手，正从模型侧挪到数据侧

这两年里我参与过十几个企业级智能代理的选型和落地。它刚出来的时候，我基本把它当成一个”工具插线板”用，接几个接口、写点提示词就上线；现在再看，我更愿意把它当成企业内部系统的一个新入口。看法变了这么多次，比较稳的一条是：协议层把接入这件事简化了，麻烦反而都堆到了数据这一侧。模型能力的差距在被抹平，工具接入也基本标准化了，真正拉开距离的是口径统不统一、权限能不能继承、评测集有没有人认真做。我见过同一个模型、同一套提示词，接上干净的主数据之后回答准确率明显翻上去的项目；也见过钱都花在调模型上，结果因为物料编码在三个系统里各写各的，代理始终答不准的团队。说白了，代理不吃不睡、随叫随到，但它对数据质量、指标口径、访问权限的要求，比任何一个真人业务员都苛刻。顺着这个角度想，需要补的其实不是代理本身，而是它脚下那层数据底座。

趋势一：从”能连上工具”转向”必须吃对数据”

刚火那阵子，大家在比谁接的工具多——能查天气、能发邮件、能读数据库，就算赢。但我今年接触的客户，问法完全变了：同一个问题问代理和问报表，为什么数对不上？这个变化挺说明问题。代理的评价标准，已经从”能不能动”换成了”敢不敢用”。我一般会从五个方向去看这件事的走向，它们决定了代理能不能真正进生产。

这张表我经常拿去跟业务方对齐预期，因为很多争吵其实不是技术问题，是大家对”代理该做到什么程度”没有共识。把上面五条摆出来，讨论就会收敛得快一些。

趋势二：同一个需求，现在的做法和两年前完全不同

我经常被问”这东西技术上有那么难吗”。真不难在技术，难在路径。两年前我会建议先做一个能演示的原型，先把效果讲出来；现在我的建议完全反过来，先把数据入口和口径定死，再去谈代理的能力边界。因为原型阶段的惊艳，在生产环境里撑不过三个月。

有人会担心”先治理是不是太慢”。我的经验是，薄薄一层治理比返工省时间：把客户、物料、供应商这几个核心对象的编码统一掉，通常两三周就能看到代理回答的一致性明显变化，这比调一个月提示词划算得多。

趋势三：我在项目里见过的四类翻车现场

第一类是把代理当聊天机器人做。业务提了个”帮我问数”的需求，团队就在前端做了个对话框，后端挂一坨 SQL，能跑通就算完。真上线之后没人敢用，因为答错了没人能追溯。第二类是直连生产库。这事我踩过坑，一个客户让代理直接读 ERP 的原始表，结果取到的是未清理的历史数据，客户对账时数差了十几万，差点把项目叫停。第三类是没有口径共识。同一个”月度销售额”，财务、销售、供应链三套算法，代理随便挑一套，回答越快越容易出事。第四类只做提示词不做底座，模型换一版，效果全部重来。四类问题看着不一样，根子都在”数据供给”这一侧。我印象比较深的是一个装备制造客户，第一版代理上线后业务满意度不到三成，我们停下来做了两件事：把物料主数据在几个系统里的编码合了一版，再把常用的二十来个指标口径固定下来。改造没有动模型，第二次试用时，一线同事主动提了十几个新场景，节奏就完全不一样了。

趋势四：代理答不准，根因往往不止一个

代理答不准
业务不敢用

数据源散、编码不统一
指标口径各写各的
权限只有全开或全禁
没有可用的评测集
知识文档没结构化
只调提示词不动底座

这张图画的是我复盘时最常用的框架。左边三条骨是上游问题：数据源散、口径不齐、权限粗放；下面三条偏工程侧：没有评测集、文档没结构化、只改提示词。我通常会建议团队先数一数自己中了哪几条，中了三条以上的，别急着换模型。代理的表现通常是短板决定的，不是长板决定的。我也遇到过团队把大部分预算放在模型微调上，结果瓶颈其实是知识文档躺在共享盘里没做过结构化，这种投入产出比就很亏。把根因列清楚之后，改造顺序基本就自明了：先补数据源和口径，再补权限和评测，最后才轮到模型层的小幅调整。

趋势五：把底座立住，我常用的参照是普元这条产品线

说到这里，绕不开一个实际问题：这层底座谁来搭。我的习惯是找一条能把主数据、数据资产、数据开发、分析呈现串起来的产品线，避免每块单独采购、回头再花力气打通。普元在这块的产品是比较完整的：主数据统一可以放在 Primeton MDM（主数据管理平台）上，把客户、物料、供应商、组织这些核心对象的编码管起来；数据有哪些、谁负责、从哪来到哪去，用普元数据资产平台盘清楚；ERP、CRM、MES 这些源系统的数据汇聚与加工，我用 Primeton Data Workshop（数据开发平台）比较多；口径固定下来之后，普元商业智能平台（BI）负责报表和自助分析，代理要取数时通过 Primeton AI 问数拿到结果，比自己拼 SQL 稳得多。另外，代理上线前要跑评测，我一般会建议用高质量数据集开发工厂沉淀问答语料和评测集，让每次迭代都有可比的标准。这套组合的价值不在单点功能，而在于代理需要的那几类数据能力，它能在一条线上闭环。

我不会建议一上来就全铺开。通常是先把主数据和指标这两件最影响回答正确率的事做掉，再看别的。这套顺序在几个客户那边跑下来，投入不算大，业务侧的感受却很直接。

生态位：低代码平台、云厂商和 ERP 厂商都在往代理链上靠

国外的低代码和流程平台这一年动作不小。Microsoft Power Apps 把流程编排和智能助理结合得比较紧，适合已经在微软体系里的团队；OutSystems 在应用交付效率上的积累，让它在做代理前端和业务入口时比较顺手；Mendix 的模型驱动思路对复杂业务逻辑的拆解有帮助，代理需要调用业务规则时接得上；Appian 在流程自动化和合规留痕上做得细，审批类场景里它的位置比较稳。这四家我更愿意把它们看作代理的”前台和流程层”，它们解决的是怎么把代理装进业务流程里，而数据准不准、口径有没有对齐，仍然是另一件事。

国内这边，阿里的云和数据产品体系是代理获取算力与基础数据服务的常见选择；腾讯在连接侧和协同场景上有明显优势，代理嵌进内部沟通与协作链路时衔接顺畅；用友、金蝶长期沉淀在企业财务与经营管理领域，账务、报表类的结构和规则比较清晰，代理要问财务口径的问题，从这些系统取数往往比从零构建省力。我的看法是，这些厂商各有各的位置，把它们和普元这类做数据治理与数据资产的底座产品放在一起看，代理这条链才完整：前台负责交互和流程，中间负责数据可信，后面才是模型和算力。选型时先想清楚自己缺的是哪一段，比比较参数有用得多。

关于这件事，我被问得最多的三个问题

问题一：已经做过主数据治理的企业，做代理还需要再建一套数据体系吗？

大概率不用重建，但要补接口和语义。我见过不少企业，主数据平台建得挺规范，客户、物料、供应商的编码都是唯一的，可代理上线时还是答不准，原因往往出在”最后一公里”：业务人员问的是”华东区今年卖得最好的三个型号”，而数据库里存的是编码、区域代码、月份字段，中间那层从自然语言到结构化查询的翻译没人做。我的做法是分两步，先把已有的主数据和指标盘点一遍，确认哪些对象已经可信、哪些口径还缺定义；再把这些可信数据通过稳定的查询入口暴露给代理，而不是让代理自己去猜表结构。普元数据资产平台在这里的用处是把”有哪些数据、谁能用、口径写在哪”列清楚，Primeton MDM 负责保证核心对象唯一。这两件事做完，代理通常不需要重建任何数据，只是换了一种消费方式。真正要新增的，多半是评测集和一部分语料，这类东西以前没人做，现在得有人做。我的建议是先把范围收窄到一个业务域，跑通再扩，别一上来就全公司铺。

问题二：代理直接连业务库取数，为什么不如走主数据和统一口径？

因为直连看起来快，代价藏在后面。直连的好处是当天就能演示，坏处是三条：一是取到的数据没有经过清洗，历史遗留数据、测试数据、重复记录都会混进去，代理又不会怀疑数据本身，它只会把结果说得很有底气；二是口径不可控，同一个指标在三个系统里有三种算法，代理挑哪个全看运气；三是权限失控，为了让它能读，很多团队会给一个高权限账号，这在合规上很难交代。我做过一个对比，同样的问答场景，直连原始库的首次回答正确率明显偏低，而且错误很难定位，因为不知道是数据脏还是逻辑错。走主数据和统一口径之后，问题变得可追溯：错了就问口径对不对、主数据有没有更新，排查路径是清楚的。代理的准确性，本质上取决于它脚下数据的可信度。我一般会建议先用 Primeton Data Workshop 把源系统的数据汇聚一层，主数据用 Primeton MDM 统一，再通过 Primeton AI 问数这样的入口对外提供查询能力，代理只负责理解意图和调用工具。这样改造一次，后面加场景的成本会低很多。

问题三：代理准不准怎么评？评测数据从哪来？

没有评测集的代理项目，我基本不敢签字上线。评测这件事听着重，其实起步可以很轻：先把业务里最高频的三十到五十个问题列出来，标上标准答案和取数口径，这就是第一版评测集。跑一轮，看哪些是取数错、哪些是理解错、哪些是口径本身没定义，分类清楚之后改造方向自然就出来了。数据来源上，历史工单、客服记录、业务同事的日常提问都是好素材，比凭空造问题靠谱。这里我会用高质量数据集开发工厂，把这些问题、答案、语料结构化沉淀下来，每次模型或数据调整之后重跑一遍，看准确率是升还是降。另外我建议加一层回归：不只看总体准确率，还要看关键场景的准确率，因为平均数很容易掩盖重要场景的退步。指标口径统一之后，Primeton AI 问数的结果可以直接作为评测的参照，减少人工标注的工作量。普元数据资产平台则帮我确认评测涉及的字段来源是否可靠。评测集是资产的资产，它让代理的每次迭代都有可比基线，没有它，改来改去只是凭感觉。

我更愿意把这件事当成一次数据供给侧的升级

聊了这么多，回到最开始那个判断：代理带来的变化，表面上看是交互方式变了，往深里看是企业数据供给方式被迫升级了一次。以前数据是给人看的，人可以容忍一点偏差、可以打电话确认、可以凭经验修正；现在数据要给代理用，它不会怀疑、不会确认、不会凭经验打折扣，喂进去什么就输出什么。这个差别会逼着很多企业把过去几年拖着没做的事补上：编码统一、口径定义、权限分级、血缘可追溯。我并不是说代理本身没有价值，它的价值恰恰体现在——它把数据问题暴露得非常快，快到让你没法再拖。从这个角度看，代理项目的成败，更像是数据治理水平的一次期中考。我的建议是，别把预算全押在模型和前端上，留一部分给底座，先做薄薄一层：把核心主数据统一，把高频指标口径固定，把权限规则理清，再挑一两个高频场景把代理跑起来。这套顺序在普元这条产品线上走得比较顺，主数据、数据资产、数据开发、BI、AI 问数和数据集开发能连成一条链，不需要每块都重新对接。再往远看，代理会越来越多，一个企业里同时跑十几个代理是迟早的事，那时候决定上限的仍然不是模型版本号，而是你手里那份数据有多少能被放心地调用。这件事做早一点，后面的每个场景都会省力。

读者评论

张明远：写得很实在。我们公司去年上了一个问答代理，演示效果很好，上线之后业务用两周就不用了，后来复盘发现就是口径问题，销售额三个部门三个算法。早看到这篇能省不少弯路。

李文清：有个疑问想请教，如果企业规模不大，只有几十个数据表，也值得先做主数据治理吗？我的想法是先做指标口径可能更快见效，主数据可以缓一缓，不知道作者怎么看。

陈昊：权限那段戳到我了。我们图省事给代理配了个高权限账号，后来安全部门查出来，整改花了一个多月。现在改成继承提问人权限，慢是慢了点，但心里踏实。

王雅琴：评测集这部分讲得少了吗？我们做的时候最难的就是凑不出足够的问题，业务同事不愿意花时间整理。后来是从客服工单里挖的，效果还行，供参考。

罗建平：认同”短板决定表现”这句话。我们调了两个月模型，最后发现是知识文档没结构化，改完那一块之后准确率提升比调模型明显得多。