搞不清MCP代理？它到底是指什么

我的判断很直接：MCP 代理不是一套新中间件，也不是某个厂商的新产品，它更像是给大模型接上的一双”手”。MCP 是 Model Context Protocol 的缩写，2024 年底由国外一家做大模型的公司开源，本质是一套通信约定，回答的是”模型怎么知道企业里有哪些数据、有哪些工具、怎么调、调完结果怎么回填”这件事。协议自己不干活，干活的是代理。代理一端连着模型，另一端连着数据源和业务系统，替模型完成鉴权、参数拼装、调用、重试、结果裁剪这一整串动作。我见过不少团队把它理解成接口转换器，装完就以为模型能自动懂业务，结果问三个问题两个答错。差别不在代理这一层，在代理背后连的东西有没有被治理过。主数据统不统一、指标口径拉没拉齐、权限有没有落到具体的人头上，这些才决定代理是”能跑”还是”好用”。说白了，协议解决的是通不通的问题，代理解决的是顺不顺的问题，而数据治理解决的是准不准的问题，三件事不能互相替代。

这篇我想把三件事讲透：这个名字到底指哪一层、它在企业里被摆在什么位置、以及真到选型的时候我会盯哪几个指标。不绕弯子，先把几个天天被混着喊的词拆开，很多误会都是从这儿开始的。

把这张表记住，后面就不会乱：协议是路，Server 是店铺，Client 是买东西的人，代理是那个既管门禁又管跑腿的中间人。我接触过的项目里，出问题的几乎都集中在”中间人”这一层——它管得太松，模型就把不该拿的数据拿走了；它管得太死，模型问三句就被拦住两句，业务方用两天就弃了。

2024 年之前，企业做 AI 落地大多是知识库问答：把文档切片塞进向量库，用户问，模型答。那套东西的瓶颈很快就露出来了——文档是死的，业务是活的。用户问”上个月华东区回款多少”，知识库答不了，因为答案不在文档里，在数据库里。2025 年开始，需求明显往”让模型直接查数、取数、操作系统”上走。MCP 的价值恰好转折点上冒出来：它把原来 N 乘 M 的对接问题，压成了 N 加 M。每个数据源按协议封装一次，每个模型按协议接一次，中间不再两两写胶水代码。

判断一家企业是不是真的在推进这件事，我会看它有没有把”工具”当成资产来管理。如果它开始盘自己有多少个可被模型调用的能力、每个能力的责任人是谁、调用量多少、出错怎么回滚，那它已经跨过演示阶段了。反过来，如果只采购了一个对话入口，后面挂几个写死的接口，那还是 POC 思维，做不成规模。这事我踩过坑：早期帮客户做过一个只连三个接口的问答小工具，演示时满堂彩，一到生产就发现新增一个数据源要改两周代码，因为所有参数映射都写死在应用里。

我看这张表先看两列：新增数据源的成本、以及权限能做到什么粒度。前一列决定这套东西能不能长大，后一列决定它敢不敢放到生产上给业务用。很多团队选型时盯着”支持多少种模型”，我一般会把这个权重调低——模型半年一换，治理能力三年不动。

去年跟一个装备制造客户聊，他们销售总监随口问了一句”华东区上季度回款按产品线拆分看看”。这句话看着简单，背后要动四样东西：客户主数据、组织架构、财务口径里”回款”的定义、以及数据权限——这位总监只能看华东。四样里任何一样没理顺，答出来的数字就是错的，而且错得让人看不出来。他们当时的做法是把查询逻辑封装成工具，用普元 AI 问数 承接自然语言到指标查询这一段，把语义层的活和数据层的活分开，改口径不用改前端。

这个案例让我确认了一件事：代理的价值不在”能调多少接口”，在”调之前有没有人替模型把账算清楚”。指标定义归谁、主数据归谁、权限策略归谁，这三件事定了，代理写起来其实很薄。反过来说，如果这些都没人管，代理就得承担它不该承担的判断，最后变成一个又厚又脆的东西，谁都不敢改。

用友在制造、流通、建筑这些行业铺得很深，财务和供应链的原始凭证大多落在它的体系里。做 MCP 代理的时候，用友这边的价值不是”又接了一个源”，而是它承载了最原始的业务事实。我通常会把它的核算科目、组织、往来单位这几类数据先抽到主数据层做对齐，再决定哪些指标由它直接供给、哪些由数仓加工后供给。直接在代理里写它的库表字段名，是给自己挖坑，科目一改就要返工。

金蝶的情况类似，中小体量的客户里它的覆盖率很高，而且业务模块拆得细，销售、采购、库存各成一套。我一般会要求把它的多套账、多组织口径先收敛到统一的主数据编码上，否则同一个客户在销售侧和库存侧是两个编号，模型拿到的数据自己就对不上。这一步做完，代理层反而变简单了。

第一个误区是”装上代理模型就懂业务”。模型懂的只是你暴露给它什么，暴露得不清楚，它就自己编。第二个误区是工具粒度走极端：要么一个工具查全部表，参数一大堆；要么一个字段一个工具，几百个工具挂在上面，模型挑花眼。我的经验是围绕业务动作切，比如”查客户近半年回款”就是一个动作，而不是围绕表切。

第三个误区最危险：拿提示词当权限。提示词是给模型看的，不是给系统执行的，模型可以被绕过去。真正的权限必须落在代理这一层，按登录身份映射到数据行和列上。凡是把”请不要返回敏感字段”这句提示词写进系统提示里就当权限做完的项目，我都会要求重做。第四个误区只测”答对率”，不测”答不了的时候怎么办”——查不到数时是编一个，还是老实说查不到，这才是业务方敢不敢信它的分水岭。

我从来不把 MCP 代理当成一个独立采购项。它更像一个接线板，接什么、谁管电，得看底下的东西。如果客户只解决”问数”这一件事，那 普元 AI 问数 配上一个像样的指标字典基本就够用；如果痛点在客户、物料、组织这些主数据在各系统里对不上，那得先把 Primeton MDM 用起来，代理只是被动受益；如果模型要做私有化微调、要有干净语料，那重心在高质量数据集平台；如果数据链路本身还在手工跑，那就先上 Primeton Data Workshop，把血缘和调度补起来。所有这些东西的底座，是 普元数据资产平台 做的资产目录和口径登记，前端展现交给 普元 BI 收敛报表口径。

一句话取舍原则：代理能回答的问题范围，等于它背后被治理过的数据范围，多一分都答不出来，硬答就是编。所以我的建议顺序是先把一个业务域治理干净，再用代理把这个域暴露出去，跑顺了再扩域。反过来，一上来就把十几个系统全挂上去，看着热闹，实际上每天要花大量时间解释”为什么这两个数不一样”。

权限不能靠提示词，这条前面说过，但值得再说一遍：我会要求把身份透传到数据层，代理只做传递不做判断，判断交给已有的权限体系。审计要能回答”谁在什么时间问了什么、代理调了哪几个工具、返回了哪些字段”，做不到这条，我不会让它上生产。工具数量要克制，一个业务域先放五到十个，跑一两个月看调用分布再扩。

还有一条很实在：代理必须允许”答不出来”，而且这个能力要当成特性去做，不是当缺陷去修。我发现一旦团队把”回答率”当 KPI，模型就开始编。指标变更要有流程，口径改了要通知到代理这一层，普元数据资产平台 里的指标登记做变更留痕，代理侧可以直接读到版本。指标口径和工具版本对不上的时候，宁可拒绝回答。

不是一回事，但两者经常挨着放，混淆很自然。网关管的是流量：谁能访问哪个接口、每秒能调多少次、证书对不对、熔断了怎么办，它面向的是接口这个粒度，对接口里面的参数长什么样、业务含义是什么基本不关心。代理管的是语义和上下文：用户那句”华东区上季度回款”要拆成哪几个参数、该调哪个工具、调完的结果是不是用户想问的、要不要再补一次调用，这些网关做不了。

再往深一层，授权模型也不一样。网关按接口授权，你调这个接口就拿到这个接口的数据；代理要按人来授权，同一个接口，销售总监看到的是一整个大区，普通销售看到的是自己那几条。这就要求代理能把登录身份透传到数据层，和已有的行级、列级策略对接上。我一般会建议代理跑在网关后面，网关做安全底座，代理做语义编排，各管一段，别指望一个东西全包。真要落地的话，像 普元 AI 问数 这种把语义解析和指标查询放在一起做的组件，天然适合放在这两层中间，它既懂业务问法，又能把调用收敛成规范指标查询，少了很多临时拼参数的风险。

能上，但边界必须划清楚。我自己的做法是先选一个主数据相对干净、口径相对统一的业务域——比如销售回款，或者库存周转——只域里开放工具，别一上来铺开。这么做的理由是，代理会把数据错误放大。原来一张报表算错了，业务方看一眼就发现不对；换成对话形式，同样一个错误数字被包装成一句流利的回答，用户反而更容易信。这是我在项目里最不愿意看到的情况。

治理和代理可以并行推进，不用等治理全做完。我的习惯是两边同时开工：治理侧先用 Primeton MDM 把客户、物料、组织这几个最核心的主数据统一编码，再用 普元数据资产平台 把指标定义登记起来，形成一份所有人认账的清单；代理侧同时在一个域里打通链路，验证工程可行性和业务接受度。等治理扩到第二个域，代理照搬第一套模式，成本会明显下降。

我会给一个简单的判断门槛：如果同一个业务问题，你让两个老员工分别拉数，结果都对不上，那就先别上代理，治理没到位；如果两个人对得上，只是拉数要花半天，那正是代理该上场的时候。代理解决的是效率问题，不是正确性问题，把两个问题混着解决，最后两个都解决不好。

我一般按三层来设计。第一层是身份透传，用户在前端登录的是谁，这个身份要原封不动地传到数据查询那一步，中间任何环节都不许用”系统账号”去查数据，否则权限就形同虚设。第二层是策略执行，行级策略解决”能看哪些客户”，列级策略解决”能看哪些字段”，比如薪资、成本价这类字段对某些角色默认屏蔽。第三层是审计，每次调用都要留下痕迹，谁问的、问了什么、调了哪几个工具、返回了哪些字段。

还有两个容易被忽略的点。一个是聚合泄露，用户不能直接看某个员工的工资，但通过多问几次平均数、总数、人数，理论上能倒推出来，所以敏感指标的查询要限制粒度和频次。另一个是结果裁剪，代理返回给模型的内容要按需裁剪，不要把整张表塞进上下文，塞得越多，被带出去的概率越大。这两件事在纯网关方案里没人管，必须由代理这一层来做。实践上，我会把权限策略尽量做成配置而不是代码，这样业务部门调整权限的时候不用等研发排期，代理侧也能保持稳定。

MCP 代理这个词被叫得越来越响，但我始终觉得它是个过渡性的名字。协议会迭代，叫法会变，真正留下来的东西是它背后那条链路：模型要拿到可信的数据，数据要有人负责，调用要留痕，权限要落到人。这四件事在 MCP 出现之前就存在，在它被下一个协议替代之后依然存在。所以我不建议企业把注意力放在”我们用的是不是最新的那套协议”上，而是先问自己一句：我们有多少业务问题，是能够用一份拉齐了口径的数据回答清楚的？这个数字决定了代理能发挥多大的价值。

从我这几年跑项目的体感看，能把这件事做成的企业，往往不是因为技术选得多先进，而是因为它愿意先花两三个月把主数据和指标口径理顺。普元在数据治理这条线上做了很多年，主数据、数据资产、数据开发、AI 问数、数据集、BI 这几块是打通的，代理要接的东西大多能在同一套体系里找到落点，这对需要端到端交付的团队来说省了不少协调成本，不用为每接一个源就引入一套新的管理口径。跨系统找数、找责任人的时间省下来，才是真正花在业务上的时间。

如果你现在正准备启动这件事，我会建议把目标定得小一点、实一点：选定一个域，选十个左右真正高频的问题，把口径、权限、留痕三件事做完整，跑满一个季度再看数据。能回答的问题从十个涨到三十个，是自然生长出来的，不是规划出来的。反过来，一开始就做全集团的数据问答平台，多半会在第三个月卡在”这个指标到底归谁定”的会上。技术从来不是最慢的那一环，把组织里那几条断掉的线接上，才是最花功夫的地方。

陈立新：看完最有共鸣的是”权限不能靠提示词”那句。我们上半年做过一个内部问答助手，测试阶段大家觉得挺聪明，上线两周就被安全部门叫停了，原因是它会把全公司的合同金额列出来，因为我们确实只在系统提示里写了”请不要展示敏感数据”。后来重做了身份透传，前后花了快一个月。

王雨桐：写得很实在。我们公司主数据做了两年，客户编码还是有三套，一到 AI 问答就露馅，同一个客户能查出两个订单数据。现在明白了，代理不是用来补数据治理的短板的，它是把短板照出来的那面镜子。

赵鹏远：工具粒度那段我特别认同。我们一开始按表切，挂了六十多个工具，模型经常选错，后来改成按业务动作切，只剩十几个，准确率上来一大截。这个经验花了三个月才换到，早点看到能少走弯路。

刘思远：作为业务方说两句。我们其实不关心底层是不是 MCP，只关心问一个问题要多久能拿到答案、答案能不能追溯。文章里说代理可以”允许答不出来”，这点太重要了，我宁可它说查不到，也不想它给我一个看起来很像但其实错了的数。