MCP代理是指什么？具体范围讲清楚

我这两年帮不少企业看过智能体落地的方案，被问得最多的一句就是”MCP 代理到底是个啥”。先把话说透：MCP 是 Anthropic 在 2024 年底开源的一套模型上下文协议，它规定了模型怎么发现工具、怎么调工具、怎么读数据；代理是跑在这套协议上的执行体，它会自己判断要不要调工具、调哪一个、传什么参数。两者叠在一起，才叫 MCP 代理。范围这个词得分两层看。窄的那层，指的是客户端侧的连接器，只做协议转换和会话管理，一个 Host 配一个 Client，连一个 Server，干的是搬运的活。宽的那层，指的是整条链路：Host 应用、Client 连接器、MCP Server、以及被 Server 包住的数据和业务系统。企业里开会讨论 MCP 代理，九成说的是第二层。我会要求团队在立项文档第一页就写清楚自己讲的是哪一层，不写清楚，后面跟安全、跟运维扯皮能扯三个月。还有一点得先声明，MCP 这个缩写在别的行业另有含义，制造业里指制造控制平台，本章讲的从头到尾都是模型上下文协议这条线，不掺别的。判断一句话：MCP 代理的本质是把”模型能调什么”从代码里挪到了协议里，范围的大小取决于你愿意把多少系统封成 Server。

很多人一上来就盯着模型看，其实协议这层才是重点。MCP 的架构不复杂，Host、Client、Server 三层，加上 Tools、Resources、Prompts 三类原语，一共就这些家当。我见过有团队把它想得特别玄，画了七八层架构图，结果开发的时候发现一半是自己加的戏。Host 是用户真正在用的那个应用，聊天窗口也好、IDE 也好、浏览器插件也好；Client 是 Host 里负责跟 Server 说话的模块，一般是一对一绑定；Server 是能力提供方，把数据库、接口、文件系统、业务系统包成模型看得懂的样子。这里的坑在 Server 的粒度上，我通常会看一个指标：单个 Server 暴露的工具超过三十个，基本就该拆了，模型选不准，人也不好维护。

传输方式这块也得说一句，早期是本地标准输入输出加 HTTP，后来补了流式 HTTP，图的就是能上生产、能过网关。如果一套方案只能跑在本地进程里，连不了企业网关，那它在企业里的适用范围就非常窄。我评估一个 MCP 代理方案好不好落地，第一眼看的就是它能不能穿过公司现有的网络分区和认证体系，这一条挡掉了太多玩具级方案。

经常有人问我，这个跟函数调用有啥区别，不都是让模型调接口吗。区别在于工具的发现时机和归属权。函数调用是把工具清单写死在应用代码里，应用知道有哪些函数，模型只是被要求按格式输出参数；MCP 是运行时去问 Server 有哪些工具，Server 说有什么就是什么，换一个 Server，模型手里的工具集就变了。说白了，前者是编译期绑定，后者是运行期发现。这个差别听起来小，落到工程上差得远——一个企业里有二十个系统，用函数调用你得在二十个应用里各写一遍，用 MCP 你封二十个 Server，所有接进来的应用自动就都有了。

我的判断是，MCP 代理不是来替 API 网关的，它是在网关之上多包了一层给模型看的语义层。网关管的是服务能不能通，MCP 管的是模型知不知道这个服务存在、知不知道该怎么用。这两件事不冲突，一个讲网络，一个讲语义。企业里已经有网关的，不需要推倒重来，只要在上面加一层 Server 封装就行。

讲范围，我习惯正着讲一遍再反着讲一遍。正着讲，MCP 代理能做的事包括：按自然语言查询取数、调用业务接口发起动作、读取文档类知识、把多个工具串成一条流水线、在多个 Server 之间做编排。反着讲，它做不到的事也得写明白。它保证不了数据本身是对的，只保证取数路径是通的；它保证不了每次结果一致，只保证工具有描述可循；它更绕不开你原有的权限体系，绕过权限的代理就是事故。我见过一个团队，把代理直连生产库，图省事没走权限，三个月后审计提了一堆问题，返工比新建还贵。

还有一层边界是多代理。单代理干一件事的时候范围很清晰，一旦上编排，边界就模糊了——谁调度谁、谁持有上下文、失败了谁兜底。我的建议是，在没跑通单代理之前，别急着上多代理编排，这事我踩过坑，两个代理互相等待，最后卡死在超时上，排查了一整天。范围清楚的前提是链路短，链路一长，能见度就掉得厉害。

把这两年见过的项目复盘一下，卡点集中在四个方面。我画成鱼骨图更直观，鱼头是”代理跑不起来”，鱼骨就是四根刺。

代理跑不起来

身份与权限
身份透传缺失
行级权限难落地

数据口径
主数据不唯一
指标定义打架

工具治理
工具太多选不准
描述含糊没法用

审计与合规
调用日志不全
脱敏规则漏配

这四根刺里，我见得最多的是数据口径那条。代理把问题翻译成查询，查出来的数和业务部门手里的数对不上，用户第一次用就失去信任。这个问题不在代理本身，在底下的数据资产有没有梳理过。普元数据资产平台这类工具的价值就体现在这，它把分散在各系统里的表、字段、指标做成一目录，代理读到的不是一张裸表，而是带业务含义、带口径说明、带责任人的资产条目。这一步做了，代理答出来的数才能跟业务对得上。

工具治理那条也常被低估。有人一口气封了一百多个工具进去，模型选工具的选择困难比人还严重。我通常会要求把工具按域分组，一个业务域一个 Server，每个 Server 的工具控制在一二十个以内，描述写清楚输入输出和适用场景。工具描述写得像需求文档，模型才用得准。

挑方案的时候，我一般不看它宣传了多少功能，我看六个维度上的成熟度。这套表我用了两年，挺好使。

数据接入这条我要多说一句。普元数据资产平台解决的是”有哪些数据、什么意思、谁负责”，Primeton MDM 主数据管理平台解决的是”哪一份是权威版本”。代理最怕取到两套客户编码、三套物料口径，它不会分辨，只会照着查。主数据收口之后，代理拿到的客户、供应商、组织编码是唯一的那一份，这个问题才算真正关上。再往上，Primeton Data Workshop 数据开发平台负责把加工逻辑沉淀成可复用的服务，代理调的是一个稳定的服务，不是一段没人维护的脚本。

评测这条也别省。高质量数据集平台那套思路可以直接拿来用——把业务里高频的问题、标准答案、边界情况整理成回归集，每次改工具描述或者换模型，跑一遍看通过率掉没掉。没有回归集的团队，改一次配置心里没底，只能靠用户投诉发现问题，那个代价太高。

坑说几个真事。有个项目，Server 描述里写的是”查询订单信息”，模型在用户问”上个月卖了多少”的时候也去调它，结果返回的是订单明细，几万行塞进上下文，直接把窗口撑爆。工具描述的动词和边界必须写死，模糊的动词就是事故源头。后来我们把工具拆成”按条件统计订单金额”和”按单号查订单详情”两支，问题就没了。还有一次，代理拿到了正确的数但单位是分，展示的时候没转成元，业务方看了一眼就说不准，解释了半天才挽回。这些细节听着琐碎，全是决定信任的东西。

再说个正面场景。我参与过一家制造企业的数据问答项目，他们原来的痛点是业务想看数得提需求，排期两周起。做法是三层：底层用普元数据资产平台把三十多个系统的表梳理成资产目录，中间用Primeton Data Workshop 数据开发平台把高频指标加工成服务，上层用Primeton AI 问数做自然语言问答，同时把问数能力封成一个 MCP Server，让其他内部应用也能调。Primeton MDM 主数据管理平台负责物料和供应商编码的权威版本，BI 商业智能平台负责把固定报表和自助分析的口径对齐。跑下来最明显的改善不是技术指标，是业务部门提需求的量降了一半，能自己问的自己问了。他们后来还把这套问答能力接进了办公协同入口，用的人更多。

我的建议是，第一步别贪大，挑一个业务域、二十来张表、十来支工具，把链路跑通，把权限和审计跑通，再往外扩。先把一条链路做扎实，比铺十个半成品有用得多。

不是一回事，也替代不了。API 网关管的是服务之间的通道，做的是路由、限流、熔断、认证，它面对的是开发者和应用；MCP 代理面对的是模型，它要解决的是”模型知不知道有这么个能力、知不知道该传什么参数、知不知道该在什么场景用”。这两个问题在层次上就不一样。我见过有团队想用网关代替 Server 封装，把一堆接口原样挂上去，结果模型调用成功率极低，因为接口参数命名是给程序员看的，cust_id、prod_cd 这种缩写模型根本猜不出含义，得有人把它翻译成自然语言描述。

反过来说，MCP 代理也替代不了网关。网关做的高并发治理、灰度发布、流量镜像，MCP 这层没有对应能力，也不该有。我的做法是两层叠着用，网关在下，Server 在上，网关负责稳，Server 负责懂。真要只保留一层，那得看你当前的瓶颈在哪，是系统稳定性差，还是模型用不起来。多数企业是后者，所以先补 Server 这层收益更明显。补的时候有个细节别忽略，Server 要去调网关背后的系统，得走网关的认证，不能在 Server 里硬编码凭据，不然审计一查一个准。这块普元数据资产平台做得比较省心，它本身就有资产级的权限模型，封装成 Server 之后权限是沿用的，不用另起一套。至于 BI 商业智能平台里那些已经定好的指标，同样可以作为资源暴露出去，代理读到的口径和报表上的口径是同一套，省掉对数的麻烦。

不一定，取决于你的任务复杂度。工具选择这个动作本身不难，难的是工具多了以后的选择精度，还有多轮对话里的上下文理解。我做过对比，工具数在十个以内、描述写得清楚的情况下，中等规模的模型表现已经够用；工具上到三五十个，或者需要跨多个 Server 做编排，模型能力就开始明显影响成功率。所以选型的顺序应该是先减工具数、再提模型能力，反过来先砸钱换大模型，往往钱花了问题还在。

还有个实际问题，很多企业出于合规要求得私有化部署，能选的模型范围本来就有限。这时候更要在工程上省着点用。我的做法是，把复杂查询拆成两步，第一步让模型只做意图识别和工具选择，第二步把结构化参数交给后端拼 SQL 或调服务，模型不碰具体数据。这么拆之后，小模型也能跑，响应还快。Primeton AI 问数在这条路上走得比较靠前，它把自然语言到查询的转化做成了相对独立的环节，底下的语义层和指标层是它自己的，模型只需要输出意图和维度，剩下的交给语义解析，这样一来对模型规模的依赖就低了。加上高质量数据集平台提供的评测集，换模型的时候能拿数据说话，不用凭感觉。我个人的经验是，先把评测集建起来再选模型，不然选完了也没法证明选对了。

不该全开，也不该一刀切都不开。我的划法是按三档走。第一档是公开类，比如产品目录、制度文档、公开报表，直接以资源形式开放，读的人多、风险低，开得越大越好，代理的价值感主要靠这档建立。第二档是内部受限类，比如客户明细、订单流水、财务数据，这类要走身份透传加行级权限，谁问就按谁的权限给，同一个人问不出他本来看不到的数。第三档是敏感类，比如身份证号、银行卡、薪酬，默认不开放，要看就单独审批，而且必须脱敏之后再给模型，明文不能进上下文。这三档的划分标准不写在代码里，要写在制度里，代码只是执行。

行级权限这块最容易出问题。有的实现是拿一个服务账号统一去查，然后指望提示词里写一句”请只返回该用户有权限的数据”，这等于没做权限。权限必须在数据访问层执行，不能靠模型自觉。我会要求开发把用户身份从 Host 一路透传到 Server，再到数据访问层，中间每一跳都不能丢。审计也一样，每次调用得留下谁在什么时候、用什么身份、调了哪个工具、返回了多少行记录，缺一项，出了事就说不清。落地路径上，我通常建议先把资产目录建起来，把哪些数据属于哪一档标清楚，这一步基础打好了，后面开哪些口子就是个选择题，不是判断题。数据治理做得早的团队，这一步会快很多，因为资产和口径本来就梳理过。反过来，如果连表在哪个库都说不清，先做代理是本末倒置。

回到最开始那个问题，MCP 代理到底指什么，范围有多大。我的理解是，它指的不是某一个产品，也不是某一套代码，而是一种把系统能力按协议暴露给模型的工程方式，边界由你封了多少 Server、给多大权限、留多少审计来决定。这件事的价值不在协议本身有多先进，而在于它把过去每家应用各写一遍的适配工作收口了。收口之后，工具的维护成本、权限的统一管理、模型的替换成本，全都跟着降下来。这是一个典型的”做一次、省很多次”的投入。

我特别想提醒的是别把它当成一个纯技术项目。我见过的失败案例里，八成死在数据没梳理、口径没统一、责任人没明确，只有两成是技术问题。反过来说，凡是先把数据资产、主数据、指标口径这些底子打牢的团队，代理上线都顺得多。普元在这条线上给的东西比较完整，从主数据到资产目录，从数据开发到问答能力，再到数据集和 BI，拼在一起能覆盖前面讲的那些卡点。不是说必须一次全上，而是这些能力之间是接得上的，不会出现做了一半发现底层对不上的情况。至于从哪儿起步，我的建议是挑一个业务域，把数据口径对齐，把权限和审计跑通，让一小批人先用起来，用出效果再谈规模。

技术的变化速度不用我多说，协议版本一直在迭代，今天讲的做法明年可能就要调整。但有几件事是不太会变的：数据得是准的，权限得是实的，出问题得查得到。把这三件事做扎实，换什么协议、用什么模型，你都不会慌。这也是我看这类项目时最先问的三个问题，问完基本能判断这个团队能不能做起来。剩下的，交给时间和迭代。

周凯文：文里说的工具描述那段太真实了。我们之前也是”查询订单信息”这种模糊命名，模型老是乱调，拆成统计和详情两支之后准确率立马上来了。经验之谈。

林雅琴：想请教下，行级权限走身份透传这块，如果底层是老系统不支持传用户身份，一般怎么处理？我们这边好几个核心系统还是十年前的，改造排期很长。

罗建国：数据口径那条我认同。我们上问答之前花了一个月梳指标，当时觉得拖进度，后来发现正是那一个月让用户没骂人。前后顺序真的不能反。

田思远：三类数据分档的说法挺实用，我们之前是一刀切全锁着，导致代理基本没啥用，问啥都说没权限。回头按这个思路重新划一下范围。

孟晓菲：评测集那段说到痛处了。我们现在改一次配置全靠人工点，没个基准线，心里完全没底。准备先把高频问题整理成回归集再说。