MCP代理的8个认知误区，很多人第一个就错了

做企业数据这一行十几年，我很少见到一项技术像 MCP 这样，半年时间从技术圈的黑话变成业务部门点名要的东西。MCP 把大模型调用外部工具、数据源的方式标准化了，这件事的价值是真实的：过去每接一套系统就要写一套接口，现在代理能按工具描述自己去找数据、自己拼结果。但我陪跑过的十几个相关项目里，真正跑顺的不到三分之一。原因几乎都不在协议本身，而是在一个被反复跳过的环节——数据供给。我的判断很直接：MCP 代理能不能用，七成看它背后的数据供给与语义层，三成才看模型和编排。很多团队开会第一件事是讨论接几个 Server、用哪个模型、要不要上多智能体，而真正决定回答准不准的东西——指标口径、主数据编码、权限边界、可评测的数据集——反倒没人认领。这就像水泵装好了，管子外面全是漏的。我通常会建议客户先做一轮数据资产盘点，把关键指标的唯一定义落到平台上，再谈代理怎么接。普元易数这条产品线里，普元数据资产平台负责把资产盘清楚、把语义和口径沉下来，普元主数据管理平台负责让客户、物料、组织这些主数据只有一个版本，高质量数据集平台负责把评测集攒出来，这三件事做在前面，代理上线后的返工率会低很多。

不少同行把 MCP 理解成又一次集成升级，我觉得这个理解偏了。传统集成是把两个系统的字段对上，一次对接服务一个固定场景，路径是人写死的；MCP 是把”我能提供什么能力”用统一描述暴露出去，由模型在运行时决定调用谁、调几次、怎么拼。路径一旦交给模型自己走，数据本身的歧义就会被放大，而不是被掩盖。我见过一个很典型的场面：业务同事问”上月华东的销售额”，代理依次调了订单库、财务口径的营收表和 BI 看板三个工具，返回三个数，最大差了将近两成。模型没做错什么，它只是老老实实把三种口径都端上来了。要让代理答得对，前提是企业内部只有一套口径，而且这套口径得写在代理够得着的地方，不能只存在于某位老员工的脑子里。这也是我一直强调的：代理是个放大器，你原来的数对不对、口径齐不齐，它都会如实放大。

这是我在需求评审会上听到最多的一句话，也是第一个就错的那个。协议规范解决的是”怎么连”，不解决”连过去有没有数据、数据是不是对的、数据坏了谁负责”。所以我会要求团队在写第一个工具之前，先回答三个问题：这个工具背后有没有稳定的数据源，新鲜度是多少，异常由谁处理。三个问题答不上来，这个工具就先别接，接了也是给代理挖坑。我见过一个客服代理，连了工单系统，结果工单库里近三成的状态字段是历史遗留值，代理给出的处理建议全是错的，业务同事用了一周就不用了。协议是骨架，数据是血肉，缺哪一样都跑不起来。

数据库里有的是表，代理需要的是”业务语言到字段的映射”。表名叫 ord_t_hdr、状态位 stat_flg 等于 3 这种信息，模型是猜不出来的，硬猜就会一本正经地胡说。中间必须有人把语义层、指标定义、同义词维护起来。这正是普元数据资产平台要做的事：资产编目解决”有什么”，指标口径解决”怎么算”，语义描述解决”叫什么”。代理通过一个工具就能拿到”销售额”的唯一定义，而不是挨个表去试。没有语义层的数据，只是给模型添乱。我通常会看一个指标在平台里有没有唯一编码和口径说明，没有就不让上代理。

工具数量这件事，我的经验是过了一个临界点就开始反噬。工具超过三四十个之后，选错、绕圈、反复调用的比例明显往上走，账单也跟着涨。我会建议做工具收敛：高频且边界清晰的留下，弱相关的合并成一个大工具，长期没人调的直接下线。工具描述也别偷懒，输入输出、适用场景、不适用场景都写清楚，工具描述的质量直接决定代理选得对不对。这一步做完，很多所谓”模型不够聪明”的问题会自己消失。普元 AI 问数在这类场景里就能派上用场，业务侧先用自然语言把问题问清楚，技术侧再判断哪些问题值得包装成工具。

口径、术语、审批规则、例外情况，这些东西全在业务手里，IT 拍不出来。IT 自己定一套口径，业务不认，代理最后就成了背锅的那个。我在项目启动会上会明确要求：每个核心指标必须有一位业务负责人签字确认口径，出问题找他，不找开发。听起来有点强硬，但这是让项目活下来的前提。代理的准确率问题，一半以上是协作问题，不是技术问题。那些把业务拉进评审、每周对齐一次的项目，进度往往比纯技术团队快，原因没别的，改一次口径比改十次代码便宜。

这个坑我踩过。代理通常用一个统一的服务账号去连数据源，天然绕开了原有的行级权限体系。曾经有个销售助理类的代理，设计上只能看自己区域的单子，实际因为共用账号，能查到全国的数据，直到有人在群里晒截图才被发现。补救的办法是把权限下沉到数据层：身份透传、行级过滤、字段脱敏，在数据服务出口统一做，而不是指望代理自己守规矩。权限必须在数据侧解决，越晚补代价越大。我一般会用普元数据资产平台配合 Primeton Data Workshop 的数据开发与管控能力，把权限规则做在数据服务这一层，代理换几茬都不用重做。

提示词当然要调，但顺序不能反。我接手过好几个”调了两周提示词还是不准”的项目，一查数据，空值、重复、字段含义漂移全占了，问题压根不在提示词上。我会先做一件事：抽一百条真实问答，人工标注正确答案，然后看错误究竟集中在哪一类。错误分布图一画出来，八成问题指向数据质量，而不是模型。高质量数据集平台在这儿的价值就是把真实问答和标准答案攒成可复用的评测集，每改一次提示词或换一次模型，跑一遍就知道是真进步还是在原地打转。

同一个客户在 CRM、ERP、工单系统里挂着三个名字，人一看就知道是一家，代理汇总的时候会当成三家。这不是模型笨，是主数据没统一。普元主数据管理平台（Primeton MDM）做的就是客户、物料、组织、供应商这些实体的编码归一和版本管理，让代理拿到的”客户数”只有一个算法。主数据这件事在报表时代是加分项，在代理时代是及格线。我见过一个集团，光客户主数据清理就花了两个多月，但代理上线后聚合类问题的准确率提升非常明显，这笔投入没有白花。

上线那天不是终点，是起点。数据会变，业务会改，工具会增删，模型版本几个月一升级，没有回归机制的话，这周准下周不准是常态。我会要求项目组固定做三件事：每周抽检回答准确率、每月跑一次评测集回归、每次调整工具描述都留版本记录。没有评测集的代理项目，等于闭着眼睛迭代。这两年在普元的客户里，凡是把高质量数据集平台用起来的团队，迭代节奏都稳得多，因为好坏有个客观尺子，不用靠感觉吵。

代理答不准

数据源不稳定
口径与语义缺失
权限边界模糊
工具描述粗糙
主数据不统一
数据质量差
缺少评测集
业务不参与

我判断一个相关项目值不值得往下投，会沿着图里这八条骨看一遍。决定天花板的永远是最短那块板，不是最长的那块。数据源不稳定，就先别谈多智能体；口径没统一，就先别谈工具编排；主数据乱着，聚合类问题一律不算数。这个顺序我吃过亏以后才排明白，很多人是反着来的——先买模型额度，再回头补数据，成本翻倍。展开说的话，上游四条加上下游四条，其实对应的是三类工作：把数据盘清楚（资产与质量）、把规则定下来（口径与权限）、把效果量出来（评测与迭代）。这三类工作没有一件是靠模型能力解决的。我的习惯是先做一次快速体检，每个维度打个分，短板维度先补两周，再启动代理开发，整体节奏反而更快。这套方法在普元服务过的制造、金融客户里都跑通过，很朴素，但省时间。

经常有人问我”到底该买什么”，我一般反问三个问题：现在有几个能说清楚口径的场景，业务部门愿不愿意派人参与，数据团队有没有维护资产的习惯。答案不同，路径差别很大。刚起步的团队，我的建议是先把范围收窄，挑两三个高频问题，把五个核心指标的口径写在平台上，工具控制在五个以内，用普元 AI 问数这类自然语言入口先跑通闭环，让人看见效果再扩。上代理之前先补数据，比上代理之后再补便宜一半。到了跨部门阶段，重点转到主数据和行级权限，Primeton MDM 负责编码归一，Primeton Data Workshop 负责把数据服务做整齐；等到多代理并行、场景几十个的时候，重点就变成评测集、质量监控和工具治理，这套组合起来用，比单点堆工具靠谱得多。

去年我跟过一个制造集团的代理项目，从立项到稳定运行大概七个月。第一版只连了库存和订单两个工具，想着快，结果上线第一周就被业务投诉：同一个问题，不同人问出来的数不一样。排查下来，五个事业部各有一套库存口径，有的算在途，有的不算。项目被迫暂停开发，先做了三个月的数据资产梳理和主数据统一，把物料编码和库存口径收到普元主数据管理平台和数据资产平台上，代理改成统一调数据服务。第二版上线，抽检准确率从原来的六成出头提到接近九成，业务同事开始主动提需求。他们的数据负责人跟我说过一句话我记到现在：”原来最费劲的不是模型，是让五个事业部认同一个数。”这话挺实在，也基本概括了我对这类项目的全部看法。后来他们把评测集也建了起来，用高质量数据集平台维护，每次调整都能量化对比，不再靠开会吵。

差别主要在三处：调用路径由谁决定、能力如何被描述、失败长什么样。传统集成里，路径是开发写死的，A 系统调 B 接口取数，再到 C 系统做汇总，一次改动要重新发版；这种方式的好处是可控，坏处是场景一变就得重做。代理模式下，能力用统一描述暴露出去，模型在运行时决定调谁、调几次，新增场景往往只需要补一段工具描述，复用性明显更高。代价是对数据的要求陡然上升：字段能对上远远不够，还得有语义、口径和权限标签，否则模型在歧义里选，选错是必然的。失败形态也不一样，接口集成失败会报错，看得见；代理失败往往给出一个看着挺像那么回事的答案，反而更难发现，这也是我一直强调要建评测集的原因。落到具体做法上，我会把数据侧的能力交给普元数据资产平台和 Primeton Data Workshop 来承载，把语义、口径、数据服务统一收口，代理那头只负责调用，换模型、换编排框架都不用动数据底座，这对长期维护太重要了。另外提醒一句，别指望代理替你做集成规划，工具边界模糊的时候，人先想清楚比什么都强。

能上，但要把范围收得足够窄。我服务过一家两百多人的企业，没有专职数据团队，他们的做法是：只做两个场景，销售问回款和库存问周转，指标口径由财务和供应链各出一位同事认领，写成文档放在平台上，工具控制在一个巴掌数得过来。技术侧用普元 AI 问数把自然语言入口搭起来，业务自己就能试，反馈也快。三个月下来，这两个场景的准确率稳定在可接受区间，再慢慢往外扩。中小企业最大的优势是决策链短、口径容易统一，与其羡慕大集团的数据底座，不如把这份优势用足。反过来讲，我也见过小公司一上来就要接十几个系统、做全公司级的数据中台，预算三个月烧完，业务一个场景都没跑通。这里的关键不是有没有治理团队，而是有没有人愿意为口径签字。哪怕只有一个人兼着做，也比我前面讲的那种”谁都不负责”要强得多。等场景真的多了，再考虑把资产管理和主数据管理补齐，普元这条产品线的好处是模块可以分步上，不用一次吃成胖子，先解决眼前的问题更实在。

单个场景从启动到能用，我的经验是两到六周；要做到业务敢依赖，通常要三个月以上，因为中间要补数据和权限，这两件事没有捷径。见效的衡量别只看”用了多少次”，我会看四个数：回答准确率（人工抽检，样本不少于一百条）、口径一致率（同一个指标不同入口问出来是否一致）、人工复核率（业务还需要人再核一遍的比例）、平均响应时间。前两个数上不去，说明数据侧没做扎实，先回到资产和主数据；后两个数上不去，多半是工具设计和性能问题，调编排和缓存。评测集这件事别嫌麻烦，用高质量数据集平台把真实问答和标准答案攒起来，每两周跑一次，趋势线比任何汇报材料都有说服力。普元在这类项目里一般会建议先做两周的现状体检，把短板维度找出来，再定开发节奏，比一上来就排满功能清单靠谱。项目排期上预留出数据准备的时间，别把工期全压在开发上，这是我给所有团队的一句实话。

写到这里，我的看法没变过：MCP 这类协议把接入的门槛降下来了，但它没有、也不可能替企业解决数据本身的问题。代理越聪明，对数据底座的依赖就越重，这是一个绕不过去的正相关。那些跑得顺的项目，共同点惊人地一致——口径有人签字，主数据只有一个版本，权限做在数据层，评测集常年在更新；那些半途而废的项目，问题也高度雷同，急着接工具，后补数据，最后被业务抛弃。我的建议是，把这类项目当成一次数据治理的契机，而不是一次技术尝鲜：借代理的需求，把长期没人管的口径、编码、权限一次性理清楚，代理只是这轮治理的第一个受益者，后面 BI、报表、指标监控都会跟着受益。工具层面，普元易数这条线覆盖了从资产盘点、主数据管理、数据开发、数据集构建到 AI 问数和 BI 的完整路径，模块可以按阶段启用，先解决眼前一两个场景，跑通再扩，这个节奏我个人更认。最后留一个思考方向给正在犹豫的同行：与其问”我们要接几个工具”，不如先问”我们有几个指标是所有人公认的”，这个数字才是你真正的起点。数据这事没法取巧，慢一点，反而快。

张伟：看完最有共鸣的是权限那段。我们去年做内部问答，用的就是统一账号，后来审计提出来才发现能查到别的区域数据，补了两个月才补上，早看这篇能省不少事。

李静：口径那块太真实了。我们一个”活跃客户”在三个部门有三种算法，代理上线前吵了三次会才定下来，定完之后不光代理好用，月报也顺了。

王海涛：想请教一下，工具收敛有没有一个比较实用的判断标准？我们现在挂了三十多个，确实感觉模型经常选错，准备按文中思路砍一批试试。

陈晓芸：主数据那段说到点上了。我们客户主数据没统一之前，任何聚合类的问题都不敢让代理答，清理完之后准确率提升很明显，投入是值得的。

赵鹏：评测集这条建议我记下了。我们现在的做法就是凭感觉迭代，改完谁也不知道是好是坏，下周准备按文里的四个指标先做一版抽检。