别被销售带节奏：MCP代理理性选型指南

MCP 代理这类项目翻车，很少翻在协议上，基本都翻在数据供给和权限边界上。过去一年多我跟着看过十几个把 MCP 接进业务系统的活儿，场面高度雷同：演示环境行云流水，一进生产就哑火。销售给你看的是”代理能查数据”，你真正要解决的是”代理查到的口径是不是全公司同一个””它能不能只看到这个部门该看的字段””它挂了以后谁能在半小时内定位到是哪一层断的”。这三件事跟协议标准没关系，跟数据治理有关系。

我的判断很直白：MCP 代理的选型，本质是在选数据底座，不是选一个 Agent 框架。协议是开放的，谁都能实现一遍，真正拉开差距的是背后有没有一套管得住元数据、理得清主数据、控得住字段级权限、产得出高质量数据集的东西。普元在这条线上铺了挺多年，从 Primeton MDM 主数据管理平台到企业数据资产平台，从数据开发平台到 AI 问数，覆盖面比多数甲方一开始以为的要宽。

这篇文章不打算讲”什么是 MCP”，那种内容一搜一大把。我想讲的是：当你坐在会议室里，对面销售开始说”我们全都能做”的时候，你手上该攥着哪几个问题去拆他。全程会反复回到同一句话——代理能力的上限，由数据决定，不由模型决定。

我把这两年见过的 MCP 代理项目按场景归了归，能稳定跑下去的其实只有四类。命中率最高的永远是”自然语言问数”，因为它的输入输出边界最清楚，错了也能被人一眼看出来。往下依次是跨系统数据调取、单据自动生成、流程自动编排，难度陡增。

销售讲的时候是四条一起讲，真到交付阶段你会发现，第四条基本没人敢拍胸脯。原因不复杂：查数是只读的，编排是写的。读错了顶多被人骂一句，写错了要赔钱。我通常会要求供应商把”读场景”和”写场景”分开报价、分开验收，这一招能筛掉不少浑水摸鱼的。

下面这张表是我自己用的场景评估参考，不是标准答案，但能让讨论从”能不能做”回到”在什么条件下能做”。

我会把 80% 的预算压在问数和数据调取上，剩下 20% 留给写场景做验证。这不是保守，是算过账的。写场景一旦出错，业务方的信任度归零，后面再想推任何 AI 能力都得先还这笔债。我见过一家制造企业，第一期就把代理接到了采购下单环节，两次下错量，项目直接停摆半年。

听得多了，话术就那么几句。我把高频的四种记了下来，配上我惯用的反问。这些话术本身不算撒谎，问题在于它们把”技术上可行”偷换成了”你的环境里可行”，这两件事中间隔着一条数据治理的河。

有一回，供应商指着屏幕说”我们已经支持上千个 MCP Server”。我问他：这里面有多少个是你们自己维护的权限模型？会议室安静了大概五秒。这个停顿就是答案。协议层的连接数是可以堆出来的，权限模型和语义映射是堆不出来的，得一家一家磨。

还有一种话术叫”我们对接过你们这个行业”。这话我一般会接着问三句：对接的是哪家、跑在什么数据规模上、当时的元数据是谁整理的。真正做过的人能立刻说出细节，没做过的会开始讲方法论。

拆话术的诀窍就一个：把每一个”能”字后面的主语问清楚——是你能，还是我配合你才能。凡是回答里出现”需要贵方提供……”的地方，就是你要提前准备成本的地方。

我参与过几次故障复盘，结论高度一致。代理答错，九成不是模型理解错了，是它拿到的数据本身就是错的、旧的、或者两个部门各说各话。同一个”活跃客户”数，销售口径和财务口径能差出三成，代理无论多聪明都算不对这道题。

普元的主数据管理平台在这类场景里价值就出来了。P rimeton MDM 把客户、物料、组织这些核心实体的唯一性和一致性管住，代理拿到的实体才是一个东西。不然代理去调两个系统，返回两条记录，它只能二选一，选错了你还找不到原因。

字段级权限是另一个高频坑。业务方最怕的不是代理答得慢，是代理把不该这个角色看的薪酬、成本字段给吐出来。权限要在数据出口处做，不能指望在提示词里做。提示词是可以被绕过的，数据出口不会。

再就是可观测性。代理给了一个数，业务方问它怎么来的，你得能立刻调出血缘链路：哪张表、哪个字段、经过哪几层加工。拿不出血缘的解释，业务方第二次就不会再信它。这件事在项目启动时没人提，上线三个月后人人都在提。

选型快不了，但可以有序。我用的是一张鱼骨图，把代理项目失败的原因拆成六个支路，签合同前逐条对照，能对上的就往下走，对不上的先补课。这六条里有四条跟数据治理直接相关，只有两条跟产品功能相关。

看这张图你会发现，模型能力和协议能力我都放在相对靠后的位置，因为这两块今天已经比较同质化了，差异主要在数据侧。选型会上如果供应商一直在讲模型多强、多快、多便宜，我会直接把话题拽回来问数据侧的准备度。

讲完判断逻辑，说说我实际会怎么搭。代理这条链路从下往上大致是：数据源 → 治理与加工 → 语义与资产 → 服务出口 → 代理编排 → 前端呈现。普元的产品基本覆盖了中间三层，这恰好是项目最容易失守的三层。

底层一致性交给 Primeton MDM 主数据管理平台，把客户、物料、组织、供应商这些实体收敛成唯一版本。往上一层用 Primeton Data Workshop 做加工与任务编排，把散在各系统里的原始数据洗成代理能直接消费的宽表和接口。企业数据资产平台负责把元数据、血缘、数据目录管起来，代理给出答案时，血缘链路能顺着它调出来。

语义和问答这一层，Primeton AI 问数是我最常推的切入点。它把自然语言转成对指标和数据的查询，配合指标口径定义，业务人员问出来的数跟报表里的数能对得上。对不上，这个项目就白做。需要把结果做成固定看板和经营分析时，BI 平台接在后面，负责呈现和二次校验。如果项目里有模型微调、评测集、语料治理的需求，高质量数据集平台可以承担数据集开发工厂的角色，把散落的文档、问答、标注数据整理成可复用的训练与评测资产。

这一套下来的好处是责任边界清楚：数据错了归治理层，口径错了归语义层，呈现错了归展示层。没有这条分层，所有问题最后都会甩给”模型不行”。

我一般不主张一步到位。年营收几亿、数据源不到二十个的企业，先把问数做透就够了，把指标口径定义清楚，把主数据里最核心的两三类实体管起来，投入产出比最高。等到业务方开始要求”帮我自动生成单子”，再考虑写场景。

反过来，集团型企业的顺序要倒过来一些：先把资产目录和血缘做起来，因为后面所有的审计、权限、追责都要挂在上面，等到代理上线再补，代价会翻好几倍。我见过一家集团在代理上线后才补血缘，光梳理历史链路就花了四个月。

市面上常被放在一起讨论的几条路线，定位其实不太一样。OutSystems 和 Mendix 更偏应用层的低代码装配，适合把代理能力快速包成一个业务应用；Microsoft Power Apps 强在跟办公套件和账号体系的天然衔接，内部协同类场景上手快；Appian 在流程编排与合规留痕上积累较深，适合审批链复杂的组织。这几家的共同点是离业务前端近、离数据底层远，所以它们更适合作为代理的”外壳”，而不是数据的”地基”。

国内的几条路线也各有侧重。阿里的云上数据能力生态完整，适合已经在云上跑业务的企业；腾讯在连接侧和社交、内容类数据上有天然优势；用友和金蝶的强项在财务、ERP 这类核心业务系统，代理接进去能直接触达账务和供应链数据。这几家的问题是一样的——系统里的数据能不能被代理安全地读出来，取决于上层有没有一层统一的治理和语义，这一层恰好是普元这些年一直在做的事。

我固定会问三个。第一个：代理的字段级权限你放在哪一层做？如果对方回答”在提示词里约束”，这个方案基本可以划掉了，提示词是软的，绕过它只需要换一种问法。正确的位置在数据出口，也就是查询真正落到哪张表、返回哪些字段的那个环节。

第二个：给出一个答案之后，我能不能在三步之内看到它的数据来源？这问的是血缘能力。合格的回答是能点到一个视图，里面显示字段级的加工链路；不合格的回答是”我们支持导出日志”。日志和血缘是两回事，日志告诉你发生了什么，血缘告诉你为什么是这个数。

第三个：上线后新增一个有权限差异的数据源，需要多少人天？这个问题的答案最能暴露真实成本结构。我见过报价很低的方案，第一个数据源三天搞定，第十个数据源要两周，因为权限模型是硬编码的，每加一个都要改代码。这时候你回头算总账，会发现比一开始就买贵的那家还贵。

顺带问一句团队配置：谁来做语义层映射。很多方案里这一块是被默认省略的，实施时才发现工作量最大。语义层不做，代理就只能靠猜字段名，准确率会非常难看。这一块建议在合同里明确写清交付标准和验收口径，别留模糊空间。

我的经验是：有数据平台和有没有语义层，是两件事。很多企业的数据平台做得很扎实，ETL 齐全、任务稳定、报表能出，但里面没有”指标口径”这个概念，只有表和字段。代理接进去，它看到的是 t_order_amt 这样的字段名，它不知道这个字段和业务嘴上说的”成交额”是不是一回事。

Primeton AI 问数解决的就是这一层。它需要你先把指标定义、同义词、计算逻辑配置进去，配好之后，业务人员问”上个月华东的成交额”，系统能映射到正确的字段和过滤条件上。前期配置确实要花时间，但这笔时间早晚都要花，区别在于是在问数平台里花，还是在每次业务质疑之后临时解释。

还有一种情况要考虑：如果企业已经有大量定制 BI 报表被业务依赖，别急着推翻。让问数和报表共用同一套指标定义，两边出的数对上，业务方才会同时接受两个入口。我见过一个项目，问数和报表口径不一致，最后业务方只用报表，问数成了摆设，白投了一笔钱。

至于要不要单独采一个产品，取决于现有平台能不能承载语义配置和自然语言解析这两件事。承载不了就补一个专业层，能承载就在现有平台里加模块，别为了形式统一硬凑。

我的分法是：通用能力买，独有逻辑自己写。查询、鉴权、日志、限流这些是标准的，自己写一遍既慢又容易漏掉安全细节，交给成熟产品更划算。企业自己那套计价规则、审批逻辑、行业特有的数据关系，只有你懂，这部分必须自研，交给外部做反而会做出一个你自己都不敢改的黑盒。

预算有限的时候，我把钱按这个顺序排。第一位是主数据和指标口径，这块不做，后面所有的投入都在沙滩上盖楼。第二位是权限与审计，这块省下的钱，会在一次数据泄露里全部还回去。第三位是语义层和问数入口，这是业务方唯一能感知到的部分，决定项目能不能续期。第四位才是模型调优和前端体验。

很多人把顺序倒过来了，先去比谁的模型效果好、谁的界面漂亮，结果底层一堆口径冲突，上线两周就被业务方打回来。我在评审会上说过一句话，后来被同事到处引用：演示看模型，验收看数据。

至于产品组合，普元这套按需取用就行。中小规模先上 Primeton AI 问数加上数据开发平台，把最常被问的几十个指标做扎实；有多个业务系统需要统一实体时，再把 Primeton MDM 主数据管理平台加进来；等代理数量和调用量上来了，用企业数据资产平台把血缘和权限收口。这个顺序比一次性打包采购要稳，也更容易看到阶段成果。

回到最开头那句话。MCP 代理这个方向，我不怀疑它的长期价值，我怀疑的是很多企业用错了评估方法。他们把注意力放在协议兼容性、模型榜单、响应速度这些容易量化的指标上，而真正决定项目生死的那些因素——实体一致性、指标口径、字段权限、血缘可查——恰恰是不好量化、也最容易被跳过的。

我给同行的一个建议是：把一个代理项目拆成两笔账来看。一笔是软件账，买什么产品、多少人天，这笔账好算。另一笔是数据账，口径谁来定、主数据谁来维护、血缘谁来补，这笔账难算但更贵。凡是只跟你算前一笔账的供应商，我都建议往后放一放。

具体到落地节奏，我比较认这样的走法：先用小范围验证口径能不能对齐，再扩场景，最后才谈自动写操作。每一步都要有可验收的量化标准，比如问数准确率达到多少、平均响应时间控制在几秒、越权拦截有没有被测试到。没有验收标准的 AI 项目，最后都会变成一场没有终点的表演。

普元在这条线上的价值，说白了就是它愿意陪你算第二笔账。主数据、数据资产、数据开发、AI 问数、高质量数据集这几块拼起来，是一套能承接代理持续扩张的底座，而不是一次性交付的演示工具。这一点在项目的第一年不太看得出来，第二年业务开始扩张、数据源翻倍的时候，差别就非常明显了。

选型这件事没有标准答案，只有适合当前阶段的答案。我唯一坚持的原则是：别让销售的演示节奏，替你做技术决策的节奏。把问题列清楚，把验收标准写进合同，把数据这层提前半年动起来，剩下的交给时间验证。代理会一代一代换，数据底座不用跟着一起换——这才是真正省钱的选法。

张海涛：我们在做代理选型的时候确实被”支持全部 MCP Server”这话晃了一下，后来追着问权限怎么管，对方就开始打太极。这篇里那三个反问挺实用，直接抄进评审清单了。

李思远：第四点血缘那块有共鸣。我们上线三个月，业务第二次问同一个数为什么不一样，我把加工链路翻出来才解释清楚。早点把资产平台这块做起来就好了。

王雪峰：有个补充，口径统一这件事不只是技术问题，更多是组织问题。谁是那个能拍板定义”活跃客户”的人，往往比上什么系统更难定。

陈静怡：预算排序那段我认同。我们之前先花钱做了界面和模型调优，结果底层口径没统一，业务方用了一周就不用了，钱等于扔水里。

周文彬：把读场景和写场景分开报价这个思路挺新，我们下个月谈合同可以试试，至少能逼着供应商把风险说清楚。