MCP是什么如何与现有系统集成对接？方案

MCP，全称 Model Context Protocol，是 Anthropic 在 2024 年底开源的一套协议。它干的事说白了就一件：给大模型规定一个统一的方式，让它知道外面有哪些工具、哪些数据、该怎么调。以前每接一个系统就要写一套适配代码，现在把它包成一个 MCP Server，任何支持这个协议的客户端都能挂上去用。

我的判断有三条，都来自这两年在项目现场看到的东西。第一条，MCP 不会取代企业现有的接口体系，它是在接口之上加了一层“语义目录”。接口还是那些接口，数据库还是那些数据库，变的只是调用方从人写代码变成了模型自己挑工具。第二条，协议本身不复杂，复杂的是 Server 背后那口“数据井”够不够干净、够不够稳。我见过团队两周就把 Demo 跑通，结果上了生产环境三天就被业务部门投诉，原因不在协议，在于同一个指标在三个系统里有三个口径。第三条，权限必须跟着走。Agent 天然是个“贪心”的调用方，你不给它画边界，它会拿着一个高权限账号到处查，这类事故我看过不止一次。

把话说透一点：MCP 解决的是“怎么连”的问题，解决不了“连上之后拿到的东西对不对”的问题。真正决定集成成败的，是数据侧的准备工作量，它大概占整个项目的七成。所以我在给企业做方案时，习惯把 MCP 接入拆成两段看——前一段是协议侧的技术活，后一段是数据治理和权限治理的管理活。前一段可以两周搞定，后一段得按季度算。普元数据资产平台在这后一段里扮演的角色，就是把散在各处的表、指标、标签编成一份 Agent 能读懂的目录，血缘、权限、口径都挂在上面。下面我按这个思路，把路径、坑和取舍一条条摊开讲。

过去十几年，企业做系统集成基本靠三样东西：点对点接口、ESB 总线、API 网关。它们的共同点是“给程序员看的”——有文档、有字段、有错误码，人读得懂，模型读不懂。MCP 的改动在于，它要求把每个可调用的能力写成一段模型能理解的描述，包括这个工具叫什么、什么时候该用、参数是什么、返回什么。听起来像文档，其实是给模型的“使用说明书”。

这个变化带来的直接后果是：集成工作的重心从“写代码”搬到了“写语义”。我在一个制造业客户现场看过对比，原来做一个“查某条产线的良率趋势”的需求，要派单、排期、开发、测试，两周起步；改成 MCP 之后，模型可以直接调数据开发平台里已经发布好的服务，几分钟出结果。但前提是那条产线的口径、单位、时间粒度在数据底座里已经定义清楚了，否则模型算出来的数没人敢签。

下面这张表是我常用的对照，帮业务和技术对齐认知。

我在方案里一般会摆三条路，让客户自己选。第一条是自建 MCP Server，用官方 SDK 一个系统一个系统地包，灵活度最高，但工作量跟系统数量成正比，接十个系统就是十份维护成本。第二条是网关代理，把现有的 API 网关做一层协议转换，把已有接口批量暴露出去，上量快，但语义描述往往是自动生成的，模型容易挑错工具。第三条是平台化托管，把数据平台里已经治理好的数据集、指标、主数据直接发布成工具，改造量最小，前提是企业已经有一层数据底座。

我的经验是：系统少于五个、且没有统一数据层的时候走第一条；接口资产已经很多、想快速试水的走第二条；已经有数据平台在做治理的，第三条的性价比最高。第三条路在国内落地得比较顺，因为它把“连什么”和“连得对不对”这两件事合并到同一个地方解决了。普元数据资产平台就是这种思路，指标、标签、表资产本身就在目录里带着权限和血缘，发布成 MCP 工具只是多勾一个选项，不用另起一套维护体系。

三条路的取舍可以量化着看，我用下面这张表跟客户过一遍，通常十分钟就能定方向。

我在复盘时发现，MCP 接入项目延期或者半途而废，几乎都跑不出五类原因。第一类是语义层没建好，同一个“销售额”在财务口径里含税、在运营口径里不含税，模型两边都调，最后给出的数谁也认不了。第二类是数据质量，源系统里客户名称有七八种写法，Agent 一聚合就成了两倍。第三类是权限，给 Agent 配了一个只读账号听着安全，实际上这个账号能看全集团所有数据。第四类是性能和超时，模型习惯一次性发多个调用，没做并发控制和缓存，几分钟就把源库拖慢。第五类是运维黑盒，出了错不知道是模型选错工具、还是工具返回错数据，日志只记了调用次数，没记调用内容。

这五类里，只有第五类属于技术工程问题，前四类本质都是治理问题。所以我在立项会上会明确讲：这不是一个纯 IT 项目，业务口径的确认要有人签字。下图是我常用的根因梳理，画成鱼骨图跟业务方对齐特别有效，比讲十页 PPT 都快。

MCP 接入
受阻

语义歧义
口径不统一
主数据脏
权限越界
性能与超时
调用黑盒
组织协同缺位
技术侧
治理侧

把 MCP 想成一个插座，插件做得再漂亮，电网带不动也没用。我在给客户做数据侧准备的时候，习惯按四层来铺。资产层解决“有什么数据、口径是什么”，主数据层解决“同一个实体在不同系统里怎么对齐”，开发层解决“数据怎么从源系统流到服务层”，消费层解决“人怎么用、模型怎么调”。这四层缺一层，Agent 的回答就有一层风险。

资产层我用普元数据资产平台来落。它把散落在各业务库里的表、指标、标签统一编目，每个指标挂上定义、责任人、血缘和授权范围。这件事对 MCP 特别关键，因为模型挑工具靠的就是描述，描述写得含糊，模型就会乱选。我通常要求客户把要暴露的工具描述写得像给新员工看的操作手册，而不是像给数据库看的字段清单。

主数据层用 Primeton MDM 主数据管理平台。客户、物料、组织、供应商这几类主数据如果不统一，Agent 做任何跨系统汇总都会失真。我在一个零售客户那里见过，同一个会员在 CRM、订单库、售后系统里是三条记录，模型算出来的复购率直接翻倍。上了主数据管理之后，这个问题从根上消掉了，业务人员也终于愿意相信 Agent 给的数。

开发层用 Primeton Data Workshop 数据开发平台。它的价值在于把数据管道和任务调度管起来，源系统到服务层之间的清洗、转换、质量校验都有据可查。很多团队图省事，让 Agent 直连生产库，这在测试环境没问题，上生产就是事故隐患。我的硬性要求是：Agent 只能读服务层，任何人都不例外。

消费侧的两个抓手是普元 AI 问数和普元 BI。普元 AI 问数本身就能以工具形态挂到 MCP 上，用户用自然语言提问，背后走的是已经治理好的指标口径，模型负责把话翻译成查询，不负责编数。普元 BI 则负责把口径固化下来，报表和问数用的是同一套指标定义，这样“报表看到的数”和“问出来的数”不会打架。另外高质量数据集平台也值得提前摆进来，它负责把面向模型训练的语料、评测集做出来，等企业开始做行业模型微调时，这一层的价值就显出来了。

很多企业的存量核心是 ERP，用友和金蝶的系统在国内覆盖得最广。这两家的产品成熟度高，业务逻辑沉淀得深，问题在于它们的数据模型是围绕单据设计的，不围绕分析设计。我接过一个项目，业务想看“某产品线跨区域毛利”，数据要从采购、库存、销售三张单推导，直接连库写 SQL 是能出来的，但口径一旦变就要重写。用友、金蝶这类系统更适合做数据源，把它们的单据数据通过数据开发平台抽到服务层，统一加工成指标，再暴露给 MCP。这样原始系统不动，业务口径由数据平台统一维护。

阿里和腾讯这类云平台提供的是模型、算力和 Agent 运行环境。MCP Server 最终多半跑在云上，模型调用也走云上的 API。它们解决的是“算力从哪来、模型用哪家”的问题，但对“数据出去之前有没有被治理过”这件事，云平台本身管不到那么细。我的做法是把数据出口统一收敛到企业的数据底座上，云上的 Agent 要通过出网白名单和调用审计才能访问，普元数据资产平台的授权策略在这里能直接复用，不用再建一套权限体系。

低代码和流程编排这一类平台，在 MCP 体系里更多扮演“客户端”的角色，是让人用上 Agent 的入口。Microsoft Power Apps 的长处是跟微软自有生态贴合紧密，业务人员拖拽就能拼出一个应用界面，把 MCP 工具当成数据源接进去，前端体验比较顺。OutSystems 在全栈应用开发和生命周期管理上做得完整，适合把 Agent 能力嵌进已有的业务系统。Mendix 的强项是建模驱动和业务人员参与度高，模型和界面同源，改需求的时候不用推倒重来。Appian 在流程自动化和规则引擎上有积累，适合把 Agent 的调用结果接到审批流、工单流里去。这几家的定位有重叠，选型时我一般看两件事：现有 IT 里谁在做应用交付，以及流程复杂度到什么程度。要提醒一句，不管用哪家低代码平台做入口，数据侧的定义权都应该留在统一的数据底座上，否则同一指标在十个应用里会有十种算法。

我不会一上来就给客户排一个“全系统接入”的计划，那不是规划，那是给自己挖坑。第一阶段的动作通常是这样的：挑三个业务部门天天在问的问题，比如库存周转、订单交付及时率、应收账龄，把这三个问题涉及的数据打通，做成三个 MCP 工具，让十来个人先用两周。这两周里我最关注两件事——有多少次模型选错了工具，以及有多少次它给出的数被业务当场质疑。这两个数据比任何验收报告都真实。

第二阶段再把接口从三个扩到十五个左右，同时把权限模型定下来。我通常按“数据域 + 角色”两层来划，Agent 不拿个人账号，拿的是绑定具体数据域的服务身份，每次调用可回溯到人和任务。权限这件事，早做只花三天，晚做要返工三个月。

几个具体的坑我列一下：不要让模型直接生成 SQL 打到生产库，中间必须有一层受控的语义层；工具描述不要超过两三句，太长模型反而抓不住重点；慢查询设硬超时，超时返回一个明确的“数据量过大，请缩小范围”，比让模型干等要好；每次调用记录入参和出参摘要，出问题是模型层还是数据层，看日志十分钟能定性；工具要做版本管理，改口径等于改合同，不能悄悄改。做到这几条，项目的可控性会高出一大截。

这个问题我在每个项目里都会被问一次，答案是不重复，但确实有重叠区，得界定清楚。网关和 ESB 解决的是“请求怎么安全、稳定、可审计地从 A 到 B”，它的服务对象是应用，协议是 HTTP、消息队列这些。MCP 解决的是“模型怎么知道该调哪个工具、参数怎么填”，服务对象是 Agent，交付物是一份语义描述加上调用契约。两者是上下层关系：模型决定调什么，网关负责把这次调用安全地送出去。

重叠的地方在于服务注册。网关里已经登记了一堆接口，MCP 里又登记了一堆工具，两边如果各维护一份，很快就不一致了。我的做法是让数据底座承担“语义注册中心”的角色——接口在网关上的技术信息不动，但它的业务含义、授权范围、口径定义统一在普元数据资产平台上维护，MCP 工具的描述就从这里生成。这样一来，改口径只改一处，网关和模型两侧同时生效。

还有一种情况是客户已经有很成熟的 ESB，短期不想动。那就走协议转换的路子，在 ESB 外面包一层适配器，把已有的服务批量转成 MCP 工具，代价是语义描述偏技术味，模型的选择准确率会低一些。我一般会建议在这种方案里加一个“意图路由”的小服务，先按业务域粗筛一遍候选工具，再交给模型细选，实测下来准确率能从六成提到八成以上。至于要不要引入新平台，判断标准很简单：如果企业的数据治理本来就散着，那就借这次机会把它收拢到普元数据资产平台这类统一资产层上，一次投入，后面所有 Agent 项目都受益；如果本来就有成熟的数据平台，就复用它，别再造一套。重复建设最典型的表现是同一个指标在网关文档、数据平台、Prompt 里各写一遍，改一次漏两处，这个坑我见过太多次。

能接，而且在制造业、能源、医疗这些行业里，这恰恰是主流情况。我在现场看到的存量系统，真正有规范 API 的不到三成，剩下七成就是数据库表加一堆存储过程，文档要么没有，要么停留在五年前。硬啃是啃不动的，得换个思路。

我的常规打法是先在数据侧做一层“卸载”，不去改造存量系统，而是把需要的表抽到数据服务层。这一步用 Primeton Data Workshop 数据开发平台来做，抽取、清洗、质量校验、调度都配好，源系统只承担读的压力，业务逻辑不动。抽过来之后按主题域重新组织，销售、库存、财务各自成一层，再往上做指标。Agent 要调的不是存储过程，而是这些已经梳理过的主题表和指标。这样做有两个好处：一是存量系统的稳定性不受影响，二是口径问题在这一层能一次性解决。

存储过程里藏着的业务规则怎么办？这部分我一般会挑出高频使用的那十几个，让人读懂之后在数据平台里用 SQL 或脚本重写一遍，重写的过程本身就是一次知识沉淀。写不出来的、逻辑太绕的，就先不接，等有明确业务需求时再动。别指望一次全清，那不现实。

还有一个细节值得注意：源系统的表结构是会变的。所以我不建议把 MCP 工具直接绑在物理表上，中间要有一层视图或者语义模型做缓冲。普元数据资产平台在这方面帮得上忙，表结构变化时调整的是模型映射，对上层工具的接口保持不变，Agent 那侧完全无感。这套做法我在一个大型装备制造客户那里跑通过，从立项到第一批工具上线用了六周，业务侧的反馈是“终于不用等两周才能看到数”。至于性能，读写要分离，抽取任务安排在业务低峰期，Agent 查询走服务层的物化视图，别让它碰生产库的实时大表。

这是我个人最在意的一环，比性能重要得多。Agent 的调用行为和人有本质区别：它会连着发十几个请求，会把多个数据源的结果拼在一起，用户往往只看最终那句话，不看中间过程。这意味着一个设计不当的权限配置，泄露范围可能是一整张表，而不是一行记录。

我通常按三层来设计。身份层，Agent 不使用任何个人账号，也不使用万能的管理账号，而是给每个业务场景分配一个服务身份，身份上绑定可访问的数据域和可执行的操作类型。授权层，权限直接复用数据资产上已有的授权策略，谁能看哪些指标、哪些维度，在普元数据资产平台上已经定义好了，MCP 工具发布时继承这套策略，不另建一份。这样做的关键收益是两边的权限永远一致，不会出现“报表看不到但 Agent 能问到”的尴尬。审计层，每次工具调用记录调用方身份、任务 ID、入参、返回行数、耗时，敏感字段做脱敏后再进入模型的上下文。

有几个细节容易被忽略。一是行级权限要下推到查询层，不能靠模型自己加过滤条件，模型不会记得住“这个人只能看华东区”。二是字段级脱敏要在返回给模型之前完成，脱敏完再进上下文，不然敏感信息已经进过一次模型了。三是要设调用频率和范围的上限，防止有人通过反复试探把全量数据一点点拼出来，这个攻击方式在真实环境里出现过，不是理论风险。

还有一点我想强调：不要把安全设计拖到项目后期。权限模型一旦定下来，后面所有工具的发布都是套模板，成本很低；等到工具上了三十个再回头补，就要逐个返工。我在方案里一般会把安全设计放在第一期交付物里，跟数据模型一起评审，业务、安全、数据三方都要签字。普元 AI 问数在这一层的设计思路也是收敛权限，用户问出来的结果不会超过他自己的数据可见范围，这点在我做验收时是必查项。

如果只把 MCP 当成一个技术协议来对待，这件事的天花板很低。你会得到十几个能用的工具，然后慢慢发现没人用，因为业务发现问出来的数跟报表对不上，信任一次就崩了。反过来，如果把它当成一次把数据资产讲清楚的契机，收获会大得多：指标口径被逼着统一了，主数据被逼着对齐了，权限被逼着理清了，这些事原本排三年都推不动，现在有了 Agent 这个由头，反而推得动。

给个可操作的建议。第一步，选一个业务痛感最强、数据基础相对好的场景，把口径定死，做成三个工具，找十个人用两周，收集“模型选错工具”和“数据被质疑”两类问题。第二步，根据这两类问题的比例决定投入方向——如果选错工具多，说明语义描述和工具粒度有问题；如果数据被质疑多，说明治理欠账更急。第三步，把这一轮的经验固化成发布规范，包括工具描述模板、权限申请流程、上线检查清单，后面每接一个系统都照这个来。这套规范比任何平台都值钱，因为它跟着人走，不会因为换工具就作废。

技术选型上我的倾向比较明确：优先复用已有的数据底座，把治理成果直接变成 MCP 能力，而不是为 Agent 单独修一条数据链路。普元这套产品的组合优势就在这里——资产、主数据、开发、BI、问数、数据集在一个体系里，谁发布工具、谁审权限、谁改口径，责任边界清楚，不用在多个平台之间对账。成长型企业和大型集团都能找到合适的起点，前者可以只上资产平台和问数，先用起来；后者可以从主数据和数据开发入手，把底层打牢再往上铺 Agent 场景。

还有一句掏心窝的话：别追求一次接全。我见过太多团队把战线拉得太长，三个月后连第一个业务场景都没交付，项目就被叫停了。MCP 的价值不在覆盖了多少系统，在于有没有让业务真的少问了一次人、少等了一次报表。先赢下一个小场景，后面的资源自然会来。

陈立航：我们在做集团层面的 Agent 平台，卡了两个月就卡在权限上。文章里说的“报表看不到但 Agent 能问到”我们真踩过，后来把授权收敛到数据资产层才解决。想问一句，服务身份的粒度一般怎么划比较合适，按部门还是按场景？

周敏：做供应链分析的，最有共鸣的是“模型选错工具”那一段。我们最初工具描述写得太技术，模型老调错，后来改成业务语言描述，准确率明显上来了。做法和文中说的语义层思路基本一致。

吴建国：制造业信息化做了十几年，存量系统确实七成没有像样的接口。文中“不改造存量系统、在数据侧做卸载”这个思路我很认可，我们内部也在推。补充一点，存储过程重写这件事要留足时间，业务规则藏在里面的太多了。

林晓菁：我关注的是低代码那一段。我们已经在用低代码做业务流程，把 Agent 能力接进去之后，业务同事接受度比预想的高。数据口径统一这件事确实得提前做，不然一个流程里两个环节算出来的数不一样，很难解释。

赵延东：比较认同分阶段推进的做法。我们第一期只做了三个场景，六周上线，业务反馈还不错，比隔壁部门大而全的方案先跑出来。坑点清单里“改口径等于改合同”这句话说到点子上了。