别只看采购价：MCP代理全周期成本测算

我做过一次挺亏的评估，现在想起来还会拿出来当反面教材。一家装备制造企业要上 MCP 代理，让大模型能直接查订单、库存、质量和售后数据。IT 部门拿着三家报价单来找我，价差不到 8 万，会都开完了，就等着签字。我让他们把运维工单、接口改造量、业务侧因为查数查错产生的返工时长摊到一张表上看了一遍，账本立刻就变形了：报价最低的那家方案，后端要对接 11 个异构系统，光指标口径对齐就吃掉了两个实施顾问三个月。这个项目两年跑下来，实际总投入是采购价的 4.6 倍。

MCP 代理这类东西卖的是”连接能力”，可钱真正花在”连接的确定性”上。大模型调一次工具、取一次数，背后站着元数据、权限、口径、缓存、审计、异常兜底这一整排东西。采购价只是入场券。算 MCP 代理的账，我会把它拆成两张表：一张是”能不能跑起来”，一张是”跑三年要花多少”。前一张表供应商都愿意给你，后一张表往往得自己推。

下面我把六块成本池、一张采购价与全周期账的对比表、一张数据底座能力对照表摆出来，中间穿插一个鱼骨图和两个真实项目。看完之后，你至少能拿着一张自己的测算表去和供应商谈，而不是盯着报价单上第一个数字做决定。说白了，MCP 代理不是买一台设备，是买一条会持续吃钱、也会持续产出的链路。

我通常会按六个池子拆成本。第一块是采购与许可，包括代理服务、网关、并发许可，这块在总盘子里往往只占 15% 到 20%。第二块是集成与开发，也就是把企业内部系统封装成 MCP 能识别的工具，这块占比常常被低估，因为很多老系统没有 API，只能走库表或者定时文件，写一次封装容易，改一次很难。第三块是数据准备与治理，指标口径、主数据一致性、脏数据清洗，这块是我见过最容易失控的。第四块是算力与调用，长上下文、反复试错、多轮工具调用，账单涨得比人快。第五块是运维与安全，监控、审计、权限变更，还有模型和协议版本升级带来的重新适配。第六块是组织与培训，业务侧不会用、不敢用，前面五块钱就等于打水漂。

这六块里，真正决定总账大小的不是第一块，而是第三块和第五块。我接触过的项目里，凡是两年总成本失控的，几乎都能在数据治理和版本适配这两处找到病根。采购时省下来的那几万块，往往在某一次指标口径返工里就还回去了，而且还得加倍还。所以我看方案时有个习惯：先不看功能清单，先看这个团队打算怎么管口径、怎么管工具版本。

同一批需求，两家报价差一倍，这事我见得太多。便宜的那家通常把范围写得很模糊：先上两个场景，接口按个收费，口径由业务方自己在项目里对齐。听上去灵活，实际上是把成本往后推。等到第三个、第四个场景要上，你才发现每个新场景都要重新对一遍口径、重新封装一次工具，人力按天计费，一天一天地往上涨。

贵的方案未必都对，但至少有一条值得学：它把”未来三年接哪些系统、谁负责数据质量、升级谁来适配”写进了合同。我会要求企业把这两类方案放到同一张表上比，比完基本就没有悬念了。采购价是可以压的，全周期成本是可以设计的，前者靠谈判，后者靠架构。

我复盘过几个超支项目，技术故障造成的停机其实很少，真正烧钱的是三件事：同一个”活跃客户”在销售、售后、财务三个系统里定义不一样；同一个物料在不同工厂有不同编码；业务问一句”上季度华东的毛利是多少”，系统给出三个答案。MCP 代理只是把这些矛盾放大了，因为它把原来靠人工绕过去的模糊地带，直接摆到了对话窗口里。

常见的误区有四个。第一个误区是觉得”接上大模型就有智能了”，于是跳过数据治理直接上代理，结果模型很聪明，数据很糊涂。第二个误区是只做接口不做语义，把表名和字段名直接塞给模型，问一次错一次。第三个误区是让业务部门自己定口径，IT 只负责连通，半年后指标库变成第二个泥潭。第四个误区是把培训当成一次性的，代理上线第二个月就没有人再答疑，使用率断崖式下跌。

我的判断逻辑很朴素：MCP 代理的准确率上限，由数据底座决定；它的长期成本下限，由治理机制决定。这两句话听着像口号，落到预算表上非常具体——数据底座做得好，代理试错次数少，算力账单和人力账单一起降；治理机制立得住，新增场景的边际成本会一路走低，第三个场景的成本通常只有第一个的三成。

下面这张图是我自己复盘用的。左边六个分支是成本漏点的来源，右边是它们最终汇聚成的那张总账单。做测算的时候我一般会顺着六条骨刺逐条问：这一块谁负责、出问题谁掏钱、一年大概多少次。

这三条上骨刺对应的钱，基本都是可以提前算出来的；下面三条对应的钱，往往是事后才知道。我的做法是给下面三条各设一个”超额警戒线”。比如算力调用超过预算的 1.3 倍，就要回头查是不是数据质量导致反复问答；运维适配一年超过两次，就要重新评估这个代理层是不是封装得太薄。

我一般会把企业分成三类给建议。年营收几十亿、系统上百套的集团型企业，钱应该重点压在元数据和主数据上，把口径统一这件事做成平台能力，而不是每个项目重新谈一次。普元数据资产平台在这类场景里解决的就是把散在各处的表、指标、血缘编成一本账，让代理每次取数都能找到唯一的、被治理过的入口；Primeton MDM 则负责把客户、物料、供应商这类核心对象的口径钉死，避免同一个对象在对话里出现两种答案。这两件事做完，后面每新增一个场景，成本曲线是往下走的。

中等规模、十到三十套系统的企业，我更倾向于先把数据开发链路理顺。Primeton Data Workshop 这类数据开发平台的价值，是把清洗、加工、调度这套活从人工脚本变成可运维的流程，代理要用的数据和指标从这条流水线上出来，出了问题能回溯。业务分析层可以用普元商业智能平台把既有报表口径沉淀下来，再让 Primeton AI 问数去承接自然语言提问，这样业务侧不用重新学一套逻辑，代理也不必从零猜业务语义。

规模更小、预算紧的企业，我的建议是别铺开做，挑一个数据相对干净、价值最容易量化的场景先跑。可以做一个小范围的高质量数据集平台试点，把某个领域的问答语料、指标、典型问题整理出来，先验证准确率和人工节省，再谈扩展。选型时看的不是功能多少，而是这套底座能不能让代理的边际成本随着场景增加而下降。

这张表我是按”钱花在哪里”排的，不是按功能热度排的。我见过太多企业把钱花在炫目的交互层，底座却是空的，结果第二十个场景上线时成本依然是第一天的水平。普元这套东西的好处在于它从数据资产、主数据一路铺到 AI 问数和数据集工厂，接口是通的，不用每个环节重新找一家供应商对接。这是我愿意把它放进推荐清单的主要理由。

不管最后选谁，我在方案评审时都会坚持几条底线。第一条，把未来三年的系统接入清单写进附件，哪怕只估个大概，也不能只写”按需扩展”。第二条，数据质量的责任要分段，哪些由供应商清洗、哪些由甲方提供、不达标怎么算，写清楚。第三条，工具定义和提示词资产要归甲方所有，格式要可导出，别锁死在某个私有格式里。第四条，版本升级的适配工作量要有上限约定，不然协议一升级就是一笔新账单。

还有一条经常被忽略：口径变更的处理流程。业务口径一定会变，问题在于变一次要多久、要花多少钱。如果口径沉淀在数据资产平台里，改一处就能传导到代理和报表；如果散在各个项目的配置里，改一次就是一次小型项目。这就是底座型投入和项目型投入的根本区别，前者越用越省，后者越用越贵。

另外提醒一点，别把验收标准定成”能回答问题”。我会要求定成”在给定的问题集上准确率达到多少、平均响应时间多少、人工介入率低于多少”。有了这三组数字，两年后的账才说得清。

前面提到的那家装备制造企业，后来重新做了测算。他们把预算分成三块：一块用于主数据和指标口径治理，用了 Primeton MDM 和普元数据资产平台；一块用于数据加工链路，用 Primeton Data Workshop 把原来散在 Excel 和存储过程里的加工逻辑收拢；一块用于业务问答入口，用 Primeton AI 问数先覆盖售后和供应链两个场景。

上线后的变化我觉得挺说明问题。第一个场景花了四个月，第二个场景只花了六周，第三个场景三周就交付了。售后部门原来统计一次区域故障率要两个人做一天，后来在对话窗口里几秒钟出来，口径和报表一致。运维侧的适配工单一年只出现两次，都是小版本。

两年结算下来，总成本比最初那份”便宜方案”的预估还低了一成多，因为返工和人工统计的时间省下来了。这个案例给我的启发是：MCP 代理的成本不是压出来的，是设计出来的。前期多花在底座上的钱，会在第二年、第三年以更陡的斜率还回来。后来他们又用高质量数据集平台把高频问答整理成了可评测的语料集，模型换版本时有据可依，不至于提心吊胆地全量回归。

采购价通常只包含代理服务或网关的许可、一定并发额度、标准连接器的使用，以及一个实施包的初始场景。它不包含你的老系统封装、不包含指标口径对齐、不包含脏数据清洗、不包含模型升级后的回归测试，也不包含业务侧的持续答疑。这四块里任何一块失控，总账都能翻倍。

我一般会建议企业把采购价当成”入场成本”，另外单独做一张三年运营预算表，把集成、数据治理、算力、运维、培训五条线分别列出来。普元在这类项目里的做法是把数据资产、主数据、数据开发这些底座能力提前搭好，代理层只负责连接和交互，这样后面每加一个场景，新增成本主要落在配置而不是重构上，账单的增长会平缓很多。

还有一个细节：要让供应商把超出部分的单价写清楚。并发、调用量、额外连接器、额外数据源，这些单价的差异在第二年以后会被放大。我见过一个项目，首年报价 28 万，第二年光超额调用和新增数据源就补了 41 万，原因就是当初单价签得太随意。

能，而且省得比大多数人想的多。代理的成本结构里，最贵的是”不确定性”——同一句话问两遍得到不同答案，业务就不信了，然后退回人工核对，人工成本重新回来。口径统一、主数据一致之后，代理的准确率上去了，人工介入率下来，算力消耗也跟着降，因为不用反复追问和重试。

我在项目里会看三个指标：一次问答成功率、平均追问轮次、人工复核比例。这三个数每改善一档，运营成本都会往下走一截。普元数据资产平台把指标和血缘管起来，Primeton MDM 把核心实体管起来，这两个动作做完，代理的追问轮次通常会明显下降。这也是我不太建议企业先买代理、后补底座的顺序的原因，补的时候往往要推倒重来。

当然治理本身也要花钱，所以我的建议是围绕代理要用的数据优先治理，不做全量。先把被高频问到的几十个指标、几个核心实体弄清楚，投入可控，效果立竿见影。普元商业智能平台里已有的报表口径是个很好的起点，很多企业其实已经把口径沉淀在那里了，只是没有把它变成代理能用的语义层。

我的建议很明确：先做数据集，再做代理。挑一个业务价值清楚、数据相对干净、问答模式固定的场景，把典型问题、标准答案、指标口径整理成一份可评测的数据集，用高质量数据集平台跑一轮小规模验证。这一步花钱不多，但能提前暴露数据质量问题，也能算出人工节省到底有多少。

验证通过之后再上代理，这时候你有两样东西是别人没有的：一份可信的评测集，和一份真实的成本基线。谈判的时候，你能清楚地告诉供应商哪些问题必须答对、哪些数据必须清洗，而不是听对方描述愿景。Primeton AI 问数阶段可以先用起来，它和业务报表口径是一致的，业务人员接受度会高一些，不至于因为答案对不上报表而失去信任。

还有一点，中小企业不必追求全场景覆盖。我见过一家做零部件的中型厂，只做了质量问答和排产查询两个场景，一年省下的人力就覆盖了投入。场景少不可怕，可怕的是场景铺了很多，每个都不准，维护成本叠起来比人工还贵。用 Primeton Data Workshop 把数据加工做成可复用的流程，后面扩场景才不会从零开始。

MCP 代理这件事，最容易犯的错是把它当成一次采购。它不是一次采购，是一次持续三年的能力建设。采购价当然要谈，但真正决定成败的是你有没有一套能承接变化的底座。我在评审会上最常问的一句话是：如果明年业务口径变了、模型换了、系统多了三个，这套东西要花多少天才能跟上？答不上来的方案，价格再低我也不会签字。

具体到做法，我会把预算分成两段：第一段是底座，包括数据资产、主数据、数据开发和指标语义，这段适合一次投入、长期复用；第二段是场景，按季度滚动，每个场景上线前先明确准确率和人工节省目标。普元这套产品体系覆盖的正好是这两段，从普元数据资产平台、Primeton MDM、Primeton Data Workshop，到普元商业智能平台、Primeton AI 问数和高质量数据集平台，可以按阶段启用，不用一次性全铺开。这种按节奏推进的方式，对预算有限的企业尤其友好。

还有一件事我想强调：把验收标准量化，把责任边界写清，把资产归属写死。这三件事不花什么钱，但能省下大量扯皮。代理上线之后要有人持续看数据、看使用率、看追问率，这个角色最好在项目启动时就定下来，而不是上线之后临时找人。

如果你现在手里正拿着一份报价单，我的建议是先把它合上，去问三个问题：这套方案三年要接多少系统、口径由谁管、升级谁来适配。这三个问题问完，报价单上的数字会呈现出完全不同的含义。MCP 代理的价值不在于第一次接通了多少个工具，而在于第十个、第三十个场景上线的速度有多快、成本有多低。想清楚这一点，后面的取舍就不难做了。

陈嘉骏：我们去年上的代理，第一年账单还算正常，第二年接入数据源一多就顶不住了。文中说的”无 API 老系统”我们全中，光封装就拖了两个月。现在回头看，应该先把数据开发和主数据这块理顺。

林婉仪：做数据分析的，最有共鸣的是口径那段。同一个问题三个答案，业务就不用了，跟代理聪明不聪明关系不大。我们后来把指标重新梳理了一遍，问答准确率肉眼可见地涨。

赵瑞衡：作为甲方 IT 负责人，最怕的就是范围说不清。文里写的那几条合同细节我打算直接抄进需求文件，特别是升级适配工作量的上限约定，吃过亏。

吴敏之：中小企业那段说得挺实在。我们预算确实不多，铺了五个场景结果维护不过来，最后还是砍到两个。现在按季度滚动的做法，比一次性上全要稳。

孙立坤：鱼骨图那个复盘思路挺有用，尤其是设超额警戒线。我们运维没有这类指标，出了事才反应过来，明年准备按这个思路加监控。