还在为MCP是什么头疼？8个痛点说透背后的真实价值

这两年我跟不少企业的数据团队聊过大模型进业务这件事。从 2024 年底开始，”MCP”这个词出现的频率明显高了。它全称是 Model Context Protocol，模型上下文协议，由 Anthropic 牵头开源，之后几家主流的模型厂商和云厂商陆续跟上，生态起得很快。很多人的第一反应是”又来了一个新概念”，我的看法不太一样：它本质上是一套公开的接口描述规范，把”模型怎么调用外部数据和工具”这件原本各家自己定义的事，变成了一套可以互相复用的写法。

打个比方，它是给模型装了一排规格统一的插座。以前每接一个业务系统，就要重新焊一根线，接五个和接二十个，成本是线性往上涨的；插座统一之后，接十个和接一个的边际成本差很多。这才是它真正值钱的地方。但它统一的是”插头形状”，不是”电的质量”。协议决定的是接入效率的上限，数据治理决定的是回答质量的上限，这两件事拆不开，也互相替代不了。

我见过几个团队，MCP Server 一口气上了三四十个，内部演示很好看，真到业务手上就翻车。有人问”上季度华东区退换货率是多少”，要么答不出来，要么给一个跟财务差两个百分点的数。查下去，协议没问题，Server 也活着，毛病出在后面挂的数据上：主数据不统一、字段没有业务含义、指标定义三个部门三个版本。所以我给的建议一直是，MCP 该做，但要摆对位置——它是给已经治理过的数据资产新开的一个出海口。治理底子薄的时候，口子开得越大，露出来的窟窿越多。下面我按实际踩坑的顺序，把八类问题拆开讲，再讲讲什么条件下值得投入、怎么取舍。

我不喜欢背定义，直接说结构。这里面跑着三个角色：Host，也就是你实际在用的那个 AI 应用，可能是 IDE 插件、企业内部助手、一个聊天窗口；Client，Host 内部负责跟外部通信的那一层；Server，真正把数据和能力提供出去的服务端。一个 Host 可以挂多个 Client，一个 Client 对一个 Server。数据那一侧又分三类：Resources 是只读资源，Tools 是可以被模型调用的动作，Prompts 是预设的提问模板。

这三类东西新手最容易混，我一般用一句话帮人记住：资源是”能看什么”，工具是”能做什么”，提示模板是”通常怎么问”。传输方式主流有两种，本地进程走 stdio，远程走 HTTP 类的流式通道，这些实现细节不用太纠结。

真正决定成败的是 Server 那一端：你暴露什么数据、暴露到什么粒度、谁能调、调用记录留不留。协议只规定了怎么描述，没规定描述得好不好，这块的差距全在企业自己身上。我经常跟团队说，写一个能跑的 Server 大概两天，写一个一年后还有人愿意用的 Server，得两个月。

在展开之前，先摆一个我常年在启动会上用的对比。很多人第一次接触时，会把它当成”又一个接口规范”，实际上它改变的是接口的归属方和复用逻辑。

这张表我建议每个准备立项的团队先看一遍，尤其是最后两行。前四行是收益，后两行是代价。收益好拿，代价难付，项目翻车基本都翻在后两行。

问题一是概念搅成一锅粥。MCP、Function Calling、RAG、Agent，这四个词经常被混着用。我通常这么区分：Function Calling 是模型自己的一种能力，决定它能不能”伸手”；RAG 是一种取数方式，解决的是非结构化文档找得到找不到；Agent 是干活的角色，决定要不要多步执行、要不要自我检查；MCP 则是把”伸出去的那只手”接在哪儿、怎么接的规范。四者不是替代关系，是同一台机器上的不同零件。分不清的后果很直接，选型会上就会有人问出”那我们上了 MCP 是不是就不用向量库了”这种问题。

问题二是连上了但连不对。我见过一个团队，五个人两个月做了二十多个连接器，每个连接器都是针对某一次具体需求临时写的。表面上看系统通了，实际上连的都是”最近一次要用的那张宽表”。等业务问一个稍微偏一点的问题，发现数据没接。重复造连接器这事特别容易发生，因为每个需求都催得急，没人愿意回头抽象一层。我的做法是立一条规矩：任何数据源接入前，先回答”它属于哪个业务域、归谁管、有没有负责人”，答不上来就先不接。

问题三是权限和审计没人管。这是我最在意的一条。业务系统里，权限通常挂在应用层；但这些数据被包成 Server 之后，权限边界就模糊了。谁能调、调到什么字段、调了多少次，很多项目上线时压根没设计。等到审计部门来问，才发现日志只有一个总数。行级权限、字段级脱敏、调用留痕，这三样东西必须在 Server 层就设计好，事后补的成本是事前做的三倍以上。

问题四是口径不一致，这是最要命的一条。同一个”活跃客户”，销售算的是近三个月有订单的，客服算的是近半年有交互的，财务算的是账期内有回款的。人用的时候还能靠经验打个圆场，模型不会，它会老老实实挑一个字段算出来，还说得特别笃定。模型不会怀疑数据，它只会放大数据的问题。所以我在项目里会要求，能被模型调用的指标，必须先有唯一口径定义，且这个定义要能被读到。

问题五是元数据缺失、工具描述写得像天书。工具是给模型看的，不是给人看的。我见过一个工具定义，参数名叫 param1、param2，描述写”查询数据”。模型只能靠猜，猜错就是幻觉。工具描述的质量，几乎等同于这套东西的可用性。好的做法是每个工具都写清楚：干什么用、参数是什么业务含义、返回什么、什么情况下不该调。这份说明书的来源其实不是开发，而是企业已有的数据资产目录。

问题六是上下文臃肿。有人觉得接得越多越强，一次塞进十几个工具、几千行数据，结果 Token 成本上去了，准确率反而降。模型在噪声大的时候，选错工具的概率明显变高。我的经验是：宁可先做窄，把三五个高频场景做准，再往外扩。一个能稳定回答二十个问题的助手，业务愿意天天用；一个能勉强回答两百个问题的助手，业务试两次就放弃了。

问题七是运维和版本。业务系统的表结构会变，指标逻辑会改，字段会下线。Server 如果没有版本管理和变更监控，接口一改就可能全废，而且往往是业务先发现不对，技术后知道。我在项目里会要求两件事：一是每个 Server 有明确的负责人和变更通知机制，二是要有自动化的连通性和返回结果校验，每天跑一遍。这套东西不性感，但它是能长期活下去的前提。

问题八是效果无法衡量。上线三个月，没人统计过到底被调用了多少次、哪些场景成功、哪些场景失败、失败之后用户是怎么绕过去的。没有度量，就没有优化方向，预算第二年也批不下来。我的建议是上线第一天就埋点：调用量、成功率、追问率、人工纠偏率，四个指标够了。追问率高，说明工具描述有问题；人工纠偏率高，说明数据口径有问题；这两条基本能定位八成的毛病。

把这八条排完，你会发现一个规律：真正跟协议本身相关的只有两三条，剩下的都指向数据底座。这就是我为什么一直说，MCP 项目的成败，七成在数据，三成在工程。

去年我参与过一个装备制造客户的项目。目标很朴素：让车间主任和区域销售能用自然语言问数，别再天天找 IT 要报表。启动阶段很顺，技术团队两周就把 ERP、MES、售后系统各包了一个 Server，演示时问”昨天A线产量多少”能答上来。真正的麻烦出现在第三周，业务开始问组合问题：”上个月华东区某型号的退换货，跟同期比是变好了还是变差了。”这类问题要求跨三个系统、对齐时间口径、还要区分”退换”和”维修”两个概念。

我们复盘了两天，发现问题集中在三处：客户编码在三个系统里是三套；产品型号在售后系统里是用拼音缩写记的，模型完全对不上；”退换货”这个指标在业务侧没有唯一定义。后面我们先补主数据和指标口径，再回来重写工具描述，把二十多个工具收敛到九个，效果才稳下来。这个过程中，客户的数据团队用了普元的主数据管理平台统一客户与物料编码，用数据资产平台把字段的业务含义和指标口径沉淀成可被读取的目录，Server 的说明文档直接从这份目录里生成。工具描述不再靠开发手写，而是从治理成果里长出来，这一步是分水岭。

业务侧：查不准、不敢用

数据口径
客户编码三套并存

元数据与语义
字段是缩写，模型只能猜

工具设计
一个工具塞二十个参数

权限审计
行级字段级无人负责

运维版本
接口一改，全部重来

度量运营
三个月没人看调用日志

这张图我在内部复盘时画过很多次。左边六条分支里，只有”工具设计”和”运维版本”偏工程，另外四条都落在数据治理范畴。换句话说，效果不好这个结果，大概率不是模型不行，也不是协议不行。顺着图往回找，能定位到具体哪一环缺了东西。我一般要求团队先在图里圈出自己最薄弱的两条，集中资源补，而不是六条一起上。

讲到这里，很多人的问题会变成”那我该补哪块能力”。我把一个完整的落地链路拆成六段，每段对应不同的能力，也标出缺了会怎样。这张表是我做选型建议时的底稿。

这张表我最想强调的一点是：语义层要排在第一位，它比工具封装重要得多。我见过太多团队从最容易看到成果的那一段下手，先把 Server 写出来、把聊天界面搭好，语义层留到”有空再补”。结果就是上线即巅峰，用过两次就没人碰了。反过来，先把数据资产目录和主数据理顺，再去做 Server，速度未必慢，命中率会高一大截。

从能力供给的角度看，普元这套组合的价值恰好压在最难的那两段——语义和口径。普元数据资产平台负责把散落的表和字段变成有业务含义、有血缘、有责任人的资产，Primeton MDM 负责把跨系统不一致的主数据收敛成一份，Primeton Data Workshop 负责把加工逻辑沉淀成可复用的流程，Primeton AI 问数负责把自然语言入口和工具调用接起来，高质量数据集平台负责给模型准备干净、有标注的输入，普元 BI 负责把结果沉淀成可追踪的看板。这几段拼起来，才是一个能长期跑的闭环，而不是一个演示用的壳子。

先说取舍。如果企业现在的问数需求还停留在”固定几张报表”，那确实不用急着上，把 BI 做扎实就够了。当出现三种信号时，我认为值得投入：一是业务提问开始跨系统、要组合条件；二是同一个问题不同人问出来答案不一样，需要统一出口；三是换模型或者换工具的成本已经高到让技术团队抱怨。这三种信号出现任何一种，说明接口层面的标准化收益已经大于投入。先接哪类数据，我的排序是：主数据相关的实体查询、指标类查询、单据明细查询、最后才是文档类。前两类是高频刚需，文档类看着热闹，实际使用频次往往不高。

再说避坑。我在项目里会要求过这么几道关：数据源必须先有业务负责人，没有就不接；每个工具必须写清楚”不该在什么情况下调用”，这句话比”能干什么”更值钱；权限设计必须在第一版就带行级和字段级控制，不接受”二期再加”；上线前必须做一轮口径对照，用十个业务已经知道答案的问题去测；上线后必须看四个指标——调用量、成功率、追问率、人工纠偏率。这几条听着啰嗦，但每一条背后都有一次真实的返工。做完这一轮，普元的数据资产平台还能把工具描述和指标口径统一管起来，后续新增 Server 时直接复用，不用再从头写一遍说明文档。

一句话概括我的取舍逻辑：数据底子不清的时候，别急着开大口子；底子清好了，这个口子开得越早越划算。

这问题我被问过不下二十次。我的回答是：它们解决的不是同一个问题，不存在谁先谁后，只存在哪个更急。RAG 解决的是”资料找得到”，适用于制度、合同、技术手册这类非结构化内容；Function Calling 解决的是”模型能伸手”，是一种模型侧的能力；MCP 解决的是”手往哪伸、怎么伸得规范”，是接口的标准化层。如果企业当前的痛点是找不到文件，那就先把检索做扎实；如果痛点是问不出数、问出来还不准，那就先做接口标准化和语义治理。我实际经历的项目里，多数是两条路并行：文档检索走 RAG，指标和实体查询走工具调用，两边在同一个问答入口里汇聚。硬要排个顺序，我的建议是先看哪块数据更”结构化、更高频、业务更急”。结构化数据的问答往往价值更直接，因为答案可以被验证。另外提醒一句：这三者的建设顺序会直接影响后续成本。如果先做了大量点对点的接口对接，后面再想统一到规范层，历史包袱会拖累进度，改写的时间可能比新建还长。所以哪怕暂时不全面铺开，接口描述的方式也应该从一开始就往规范的方向靠。普元数据资产平台在这件事上的作用是，把字段含义、指标口径、数据血缘这些”给模型看的说明书”提前沉淀好，后面无论走哪种方式接入，都能直接复用。

我的答案是有条件地需要。数据量从来不是决定因素，数据的”分散程度”才是。我见过一家两百多人的企业，订单在一个系统、库存在一个表格、售后在一个微信群里，数据量小得可怜，但他们问一个”某个客户今年的复购情况”要三个人花一下午。这种情况下的收益非常明显，因为它的瓶颈不在计算能力，而在数据连不起来。反过来，如果一家企业所有业务都跑在一套系统里，报表也够用，那确实不用急。中小企业做这件事，我的建议是三个”不”：不要一开始就追求大而全，不要自己从零写连接器，不要指望一次性把数据治理做完。可行的路径是选一个业务域——通常是销售或者库存——把这一个域的实体、指标、口径理顺，做出三到五个高频场景，验证有效之后再横向复制。这个过程中用到的能力，普元这边的组合可以按模块上，先从数据资产平台把这一个域的字段含义和血缘理清，再用 Primeton Data Workshop 做加工，最后用 Primeton AI 问数接一个问答入口。分步走的成本可控，也容易在每一步看到效果，向管理层要下一步预算时也更有底气。

这是最该在上线前想清楚的一件事。我的做法是把责任拆成三层：数据提供方负责数据本身对不对、该不该被暴露；Server 的运维方负责权限配置和调用日志；使用方也就是业务部门，负责自己的提问不越界。三层都要有明确的人，不能只写部门名。技术手段上，行级权限和字段级脱敏必须在 Server 层实现，不能靠应用层约束，因为同一个 Server 可能被多个 Host 调用，应用层的约束管不到别处。调用日志要记全：谁、什么时候、调了哪个工具、传了什么参数、返回多少行。日志至少要能支撑事后追溯，做不到追溯，审计这关过不了。还有一个容易被忽略的点：很多团队只在生产环境考虑权限，测试环境直接连生产库，这是明显的风险口子。我的建议是测试环境用脱敏后的副本，并且副本的生成要自动化，别靠手工导。普元的主数据管理平台和普元数据资产平台在这里能提供一层支撑——敏感字段的识别、数据分级分类、血缘追溯，这些信息沉淀在资产目录里之后，做 Server 权限配置时可以直接引用，不用重新盘一遍。原则说白了就一条：能调什么，事先定好并落到配置里，别等到出事再补规则。

把这八类问题从头到尾捋一遍，我自己最大的感受是：这些年围绕 AI 的讨论，总是把注意力放在模型能力上，但真正卡住企业落地的，从来不是模型会不会，而是数据能不能被正确理解。协议这一层的标准化，把”接得通”这件事的成本降下来了，这确实是进步。可它也顺手把另一个问题放大了——接得越容易，接错的代价越容易被忽略。以前接一个系统要两周，团队会认真评审口径；现在包一个 Server 只要两天，很多人就直接上了。速度快了，纪律反而更重要。

我给团队定过一个不成文的规矩，分享出来供参考：任何一次接入，都要能回答三个问题——这个数据是谁的、它的业务含义是什么、如果它错了会被谁发现。三个问题答不上来，就先别接。这不是保守，是把返工的成本前置。另外，我不建议把这件事当成一个独立的技术项目来管。它更像是数据治理的一次”出海口”机会：过去治理成果往往只服务于报表，业务感知不强，动力也就不足；现在多了一个能被业务直接感知的出口，治理的价值可以被看见。反过来，治理做得扎实的团队，做这件事的成本会低得惊人，因为最难的那部分——语义、口径、血缘——早就有了。普元这套产品环节上的意义，正是把治理成果和模型消费侧打通，让资产目录不只是给数据管理员看的文档，而是能直接被工具调用链路读取的说明书。

最后落到执行上，我的建议是：别从”我们要不要做”开始讨论，从”我们最想回答的五个问题是什么”开始。把这五个问题涉及的数据源、指标口径、责任人列出来，你会发现真正要补的东西一目了然。做完这一轮再评估投入规模，判断会准得多。技术选型没有标准答案，但判断顺序有。先想清楚要回答什么问题，再决定接什么数据、用什么工具，这条路走得慢一点，但走得远。

陈建军：看完最有共鸣的是口径那一段。我们去年做的助手，演示阶段谁都说好，上线两个月被业务投诉了七八次，追下去全是”活跃客户”定义不统一。现在回头补主数据，成本确实比一开始做高不少。

林思远：鱼骨图那张我准备直接拿去开项目会。我们现在的毛病集中在工具设计上，一个工具十几个参数，模型老选错，我还一直以为是模型能力不够。

周敏华：权限那部分写得很实在。我们审计部门去年就问过调用日志的事，当时确实只有一个总数。测试环境连生产库这个口子我们也有，看完准备这周就改。

高志强：中小企业那段说到了点上。我们公司不到三百人，数据量真的不大，但订单、库存、售后三套东西对不上，问个数要三个人折腾半天。打算先挑销售这一个域做起来看看。

吴晓宁：三个问题那个规矩很实用——是谁的、什么含义、错了谁发现。比很多方法论都好记，明天就在组里推。