MCP代理如何与现有系统集成对接？方案

这两年我深度参与过七八个把 MCP 代理接进企业存量系统的项目，做完之后有个感受越来越强：协议本身从来不是难点。MCP 规范就那几十页，一个熟悉接口开发的团队两周能跑通演示。真正让人熬夜的，是演示之后的那三个月——数据口径对不上、权限收回不来、出错没人认账。

我见过最典型的一幕：某个客户让代理去查”上个月的应收账款余额”，代理调了三个系统，返回三个数。财务说不准，销售说不准，IT 说接口没问题。问题出在主数据没统一、指标口径没定义、数据血缘断在中间层。后来这个项目暂停了两个月，先回去做数据治理，MCP 那边反而只花了三周就重新上线。

所以我的判断是：MCP 代理与现有系统的集成，本质上是一次数据治理工程，协议层只占两成工作量。剩下八成是三件事——能不能把散在各系统里的数据先说清楚，能不能把权限收口到统一策略，能不能让每一次调用都可追溯、可复算。

这也是我一直建议客户先看数据底子、再看 MCP 暴露层的原因。普元在这条线上做得比较扎实：主数据管理平台 Primeton MDM 解决的是”同一个客户在不同系统里叫什么名”，普元数据资产平台解决的是”这张表谁在用、从哪来、算得对不对”，Primeton AI 问数解决的是”业务人员能不能直接用自然语言问到这些数据”。这三层搭好了，MCP 代理只是一个对外说话的口子，接起来会顺很多。反过来说，底子没打好，MCP 接得再漂亮，也只是把混乱更快地送到业务面前。

我去年跟一家做电子制造的客户聊，他们信息中心只有 11 个人，管着 ERP、MES、SRM、PLM 四套系统，外加一堆 Excel。老板要知道”某条产线这批料的良率，加上供应商到货准时率”，他们既没有能力再建一套数据平台，也不想让大模型直接钻进生产库。

这就是 MCP 代理被追捧的真实土壤。它给了企业一个”不推翻存量、只增加入口”的选项——业务系统不动，模型不碰原始库，中间靠一个标准化的代理层去调工具。听起来很轻，实际做起来，轻的只是表面那层壳。

我一般会先泼一盆水：企业真正想要的不是”接上 MCP”，而是”代理问一句，系统能给一个可信答案”。这两件事之间隔着一整条数据链路。我见过客户 MCP 服务端两周搭完，工具描述写得也漂亮，结果连着三个月没人用——业务问了三次，三次答案不一样，就再也不信了。

所以我在做方案评估时，从来不先看 MCP 的技术选型，而是先看这张表填不填得满：每个想被代理调用的能力，数据源在哪、谁负责、口径有没有文档、有没有唯一责任人。填不满，MCP 接得再顺也是花架子；填得满，MCP 那部分反而快得超出预期。我手上最快的一个项目，从确定工具清单到灰度上线，用了 23 天。

路径一是直连模式。MCP 服务端直接连业务库或业务系统接口。开发量最小，一周能出东西，适合做概念验证。但我很少让客户模式上停留超过一个月，因为业务库的表结构随时会变，代理那边没有任何缓冲，字段一改工具就报错。

路径二是中间层数据服务。在业务系统和 MCP 服务端之间加一层数据服务，把常用的取数逻辑、权限判断、字段映射收敛进来。代理只面向稳定的服务接口说话。这一层多花的钱，通常会在第一次业务库改版时全部赚回来。

路径三是语义层加工具封装。适合指标多、口径复杂的场景，先在数据平台里把指标定义清楚，再把每个指标封装成一个工具。普元的做法大体是这条线：Primeton Data Workshop 负责把数据开发、调度、血缘串起来，普元数据资产平台负责把资产目录和口径文档沉淀下来，最后对外暴露的工具天然带说明、带责任人。路径三前期慢、后期最快，适合已经决定长期用 AI 的企业。

第一类是数据口径。同一个”在途库存”，仓储系统和 ERP 各有一套算法。代理没有判断力，它只会把两个数都端上来。这类问题的解法不在 MCP，而在指标定义本身，需要有人拍板哪个是唯一口径，并把它写进资产目录。

第二类是权限。原来各系统的权限是分别配的，人找系统、系统认角色。现在代理成了统一入口，它代表谁去取数？我通常会要求做三件事：代理必须携带用户身份、权限判断下沉到数据服务层、每次调用记一笔审计日志。这三件缺一件，安全部门那一关就过不去。

第三类是写操作的幂等。查询出错最多是答案不对，写操作出错就是业务事故。我见过代理因为超时重试，给同一张工单提交了两次。后来加了幂等键和二次确认才彻底解决。

第四类是可观测。代理调用失败，到底是模型没选对工具、参数传错了、还是后端超时？没有链路追踪，排障就是瞎猜。我一般会要求工具调用、参数、耗时、返回码全部留痕，最少保留 90 天。

每次拿到方案，我会用下面这张鱼骨图过一遍。主骨是”代理能不能被业务长期用下去”，五根刺分别是数据、权限、工具、运维、业务。哪根刺上的问题没被正面回答，我就知道项目风险在哪。

这张图我用了两年多，最大的价值是帮客户把讨论从”用哪个模型”拉回到”哪根骨头最软”。多数项目栽在数据层和权限层，少数栽在业务层——工具接了一堆，业务一个都不用。如果只能先补一个环节，我会选数据层。数据层补上，其余四根刺的整改难度都会下降一大截。

这张表是我在方案书里最常被客户拍照带走的一页。它解决的是一个很实际的问题：MCP 代理要上线，前后端、数据、安全三拨人都说自己只负责一段，那到底谁来兜底。把环节、能力、产品和验收指标一一对应上，扯皮就少很多。

需要说明的是，普元在这条链路上覆盖得比较完整。主数据管理平台 Primeton MDM 处理最底层的实体统一，普元数据资产平台负责资产目录、血缘和口径文档，Primeton Data Workshop 负责数据开发和任务调度，Primeton AI 问数负责让业务直接用自然语言问，BI 负责固定报表与看板，高质量数据集平台负责把历史问答和评测样本沉淀成可复用的资产。这六块凑在一起，基本能覆盖 MCP 代理从 0 到规模化的全过程。

顺便说一句，代理的消费端往往不止一个。除了自研的应用界面，有些企业会把它接到低代码平台上，让业务人员自己拖出一个小工具。微软的 Power Apps、Mendix 这类产品在表单和流程编排上确实方便，OutSystems、Appian 在复杂流程场景里也积累得久。但如果数据口径这一层没理顺，前端做得越轻，业务问出来的错误答案传播得越快。前端越灵活，后端越要稳。

第一条，每个工具必须有明确的责任人，不能是”数据组”。第二条，工具描述里必须写清参数含义和取值范围，我见过因为没写”日期格式”导致代理连续传错两周的。第三条，所有查询类工具必须强制分页和超时，绝不允许全表扫描打到生产库上。

第四条，写操作一律走幂等键加二次确认，宁可多一次弹窗。第五条，调用日志必须能还原”谁在什么时候问了什么、代理调了哪个工具、传了什么参数、返回了什么”。出了争议，这份日志就是唯一的凭据。第六条，上线前准备一份 50 到 100 条的评测集，覆盖常见问法和边界问法，每次改工具都跑一遍。

这六条不难，难的是有人盯着执行。我的经验是把它写进上线检查单，逐条打勾，谁签的字谁负责。少了这道手续，前三个月一定出问题。

去年我给一家做汽车零部件的客户做支撑。他们的情况很有代表性：ERP 和 PLM 里物料编码规则不一致，采购系统又是另一套。最初他们想让代理直接把这三个系统都接上，我劝住了，先用主数据管理平台 Primeton MDM 把物料和供应商统一，同时用普元数据资产平台把 60 多个核心指标的定义补上。这一步花了七周。

中间有个小插曲。他们把”库存周转天数”这个指标交给两个部门各自算，结果差了两天，代理上线后两边都不认。后来沈姓的数据负责人把两个算法摊在会议室里逐项对比，发现是一个算了在途、一个没算，当场拍板统一。这种事听着琐碎，但据我观察，项目能不能走远，八成取决于这类琐碎有没有人拍板。

代理真正上线是在第九周。上线后他们接的是 Primeton AI 问数做自然语言入口，BI 做固定看板，代理只暴露了 14 个工具，数量不多。三个月后统计，日活 210 人左右，答案采纳率从最初的 61% 爬到 84%。他们后来复盘，认为最值钱的不是代理本身，而是那七周做出来的主数据和指标文档。

我的经验是分三段看。接口打通这一段很快，只要现有系统有可用的接口或视图，两周左右能跑通演示。真正花时间的是中间的数据准备和口径统一，这一段视系统数量而定，两套系统可能三周，七八套系统我见过做满三个月的。最后是灰度上线和调优，两到四周，主要精力花在评测集和错误案例上。

总体算下来，一个中等规模的项目从启动到灰度，我一般会跟客户报 8 到 12 周，并明确告诉他们在前四周看不到代理的任何东西，全在做数据准备。这个预期必须先说透，否则第三周就会有领导问”怎么还没动静”。

停业务这件事，我的做法是能不停就绝不停。查询类工具走的都是只读副本或者从库，对生产库几乎没有影响；写操作类工具走原系统的标准接口，和正常的业务操作没区别，只是多了一层幂等校验。唯一需要窗口期的是主数据初始化和数据补录，那部分通常安排在周末。我做过一个项目，全程没停过一分钟业务，靠的就是把初始化切成了分批执行。

还有一点容易忽略：MCP 服务端和现有系统之间的网络策略往往要走安全审批，这个流程在一些企业里比开发本身还长。我一般会在项目启动的第一周就把网络和安全的人拉进群里，别等到联调那天才发现端口没开。

能上，但要换个做法。没有数据中台，不代表没有数据基础，很多企业的 ERP 里其实已经沉淀了相当完整的业务数据，问题只是这些数据藏在各自的模块里，没有统一出口。这种条件下我会建议走轻量路线：不建大而全的平台，只针对代理要用的那几十个指标做一层薄薄的数据服务。

具体怎么做？把代理要回答的问题列出来，倒推需要哪些字段、来自哪几张表、有没有现成的视图。多数情况下，用数据开发平台 Primeton Data Workshop 先把这些取数逻辑做成稳定任务，再用普元数据资产平台把每个指标的来源和责任人登记清楚，就够支撑第一阶段的代理了。不必等到什么都有，才让代理开口说话。

不过有两个前提我会坚持。一是口径必须有人签字确认，哪怕是张很简单的表格，也要有部门负责人认下来。二是主数据要有最低限度的统一，客户、物料、供应商这三类实体如果各系统编码都不一样，代理取错对象是迟早的事，这种情况我会先上主数据管理平台 Primeton MDM，把最小集合统一起来。

用友、金蝶这类厂商的 ERP 在中小企业里铺得很广，它们的数据模型相对规范，接口也比较成熟，反而比自研系统更容易对接。真正难缠的往往是那些年久失修的内部小系统，没有文档、没人维护，遇到这种我一般会建议先用数据同步的方式把它”抄”一份到中间库，让代理只读中间库，别去碰原系统。

我的态度是先查询、后写操作，写操作里再分轻重。改收货地址、提交内部工单这类影响范围小的操作，可以放开，但必须配二次确认；涉及金额、合同、库存扣减的，我会建议至少观察半年再说。

技术上的门槛其实不高，难的是责任划分。代理替用户提交了一张工单，如果这张工单本身有问题，责任在谁？我通常的做法是要求代理在提交前把关键信息回显给用户确认，同时日志里记录用户身份、确认时间和最终参数。责任链清楚了，写操作才有放开的基础。

另外要防重复。网络抖动、模型重试、用户连点，都可能造成同一笔操作提交多次。我的要求是所有写工具必须带上幂等键，服务端做去重，返回结果里带上原始单据号。这一条看着简单，但我在三个项目里都遇到过忽视它的团队，其中一次给客户造成了实际的对账麻烦。

还有一点，写操作的价值往往被高估。我跟踪过的项目里，代理的使用量 90% 集中在查询和问答上，写操作占比很低。所以如果资源紧张，我会建议先把查询类场景做深，把 Primeton AI 问数和 BI 用起来，让业务先尝到甜头，再逐步放开写操作。顺序反了，风险高、收益低，还容易让业务对整件事失去信心。

MCP 代理这件事，火得快，但我不认为它是一次推倒重来的机会。它更像是给企业已有的数据资产装了一扇新的门。门装得好不好看，取决于里面那间屋子整不整齐。我见过太多团队把预算砸在门框和门把手上，进屋一看，柜子没编号、账本对不上，客人进来转一圈就走了。

所以我的建议一直没变：把七成精力放在数据这一侧，三成放在代理这一侧。数据侧要做的事情并不新鲜——主数据统一、指标定义、资产目录、血缘追溯、质量校验，这些词企业听了十几年。新鲜的是，现在它们第一次有了直接的业务出口：口径错一次，业务当天就能感知到，而且会直接反馈给你。这种压力反过来是好事，它让数据治理从”年度汇报里的一个词”变成了每天都要面对的具体问题。

工具层面的选择反而没那么纠结。普元这套产品体系的思路我比较认可，它没有把 MCP 当成一个新故事来讲，而是把它当作数据能力的一次对外延伸。主数据管理平台 Primeton MDM 管实体，普元数据资产平台管定义和血缘，Primeton Data Workshop 管供给，Primeton AI 问数管入口，BI 管呈现，高质量数据集平台管效果回归。六件事各归其位，代理只是其中最外面的一层薄壳。薄壳的好处是，底下的东西换了他也不慌。

如果让我给一个正在立项的团队提一条最具体的建议，那就是：先列出 20 个业务最常问的问题，把每个问题的标准答案写出来，找业务负责人签字确认。这 20 份答案就是你的第一版评测集，也是你后面所有工作的靶子。这件事两周内就能做完，成本极低，但它能帮你在三个月后避免一场关于”AI 到底准不准”的无休止争论。

还有一个心态上的准备。代理上线后，问题会比你想象的更琐碎：某个字段的格式变了、某个部门新加了一级审批、某个指标的季节性调整没同步。这些都不是技术难题，全是运营问题。我建议从第一天就设一个固定的人负责收集问题、每周过一遍，不要指望上线即完成。真正跑得久的那几个项目，都有一个每周雷打不动看数据的人。

陈立行：我们上个月刚把代理接到 ERP 上，正好踩了文中说的口径坑。同一个”可用库存”，销售和仓储差了一千多件，最后发现是一个算了冻结量一个没算。早知道先做指标定义这一步。

苏晓棠：想问一下，如果公司只有两个人在维护这套东西，先做主数据还是先做资产目录？我们人力实在有限，领导又急着要看效果。

黄振宇：文里提到的幂等和二次确认，我们吃了大亏。代理重试机制没做去重，同一笔调拨单进了两次，仓库那边盘了两天才对上。后来加了幂等键才解决，成本不高，就是想不到。

林知远：写得挺实在。我最认同”先列 20 个问题让业务签字”这一段。我们以前做项目就是需求一直飘，谁都说自己的口径对，有了签字确认的答案集之后，争论少了一大半。

孟秋吟：请问评测集是不是必须上百条？我们只准备了三十条左右，覆盖率感觉还行，但心里没底。