大模型网关

我经常被问“MCP 这东西到底是个啥”。问的人分两类：一类是做技术的，想知道它跟函数调用、跟传统 API 网关有什么不一样；另一类是做数据或者做业务的，只关心它能不能让自己那堆散在各处的数据被 AI 用上。这两类问题听起来差很远，落点其实一样——MCP 的价值不在协议本身写得多精巧，而在于它逼着企业

我做数据类项目有十几年了，从最早的数仓建设到后来的数据中台，再到这两年频繁被问到的智能体接入。MCP 这个词从去年冬天开始被客户反复提起。Anthropic 在 2024 年 11 月把它开源出来，思路其实很直白：把大模型跟外部系统连接的那层适配代码收拢成一套统一协议。以前每接一个数据库、一套 E

一、MCP 的本质：不是多一个接口，而是多一层上下文契约MCP 常被翻译成模型上下文协议，英文是 Model Context Protocol。我见过不少团队把它理解成“又一个 API 规范”，甚至有人问我是不是把 REST 接口换个名字。实际跑下来，它更像模型、Agent、工具、数据源之间的一层

我前后参与过五个把 MCP 接进企业内部系统的项目，结果差得很远。有的上线两周，日均调用掉到个位数，后台日志里翻来覆去就那几个名字；有的三个月后，还有六成员工每周至少主动调用一次，甚至有人把常用的问法做成了自己的快捷指令。这两类项目的模型能力差距没那么大，差别几乎全在体验设计上。
MCP 被讨论得最

我这两年做数据和 AI 落地的陪跑，被问得最多的不是\”选哪个大模型\”，而是\”AI 接了内部系统之后，这事怎么才算过关\”。这个问题的答案，从来不在法务那份检查表上。真正决定能不能过关的，是数据从哪个口子进来、以什么身份进来、出去的内容被谁看见、有没有留下能回放的痕迹。我把它拆成五层：身份与权限、数据来

一、先给判断：参数是入场券，不是决胜项
我陪跑过七八个数据智能平台的选型，最近两年被问得最多的一句话是：模型灰度到底该怎么评。多数团队一上来就拉参数表，上下文窗口多大、单次推理多少钱、并发多少路，一行行看下来挺有仪式感。灰度跑两周，问题全出在别的地方。业务问一句\”上季度华东的退货率是多少\”，系统给了

做AI产品这几年，我被问得最多的不是模型怎么训，而是模型怎么发。线上那套跑了一年多的策略，突然要换成新一代的，敢不敢一次性全推？我的答案基本固定：不敢，也不该。模型灰度这件事，说白了就是把“新模型上线”从一个开关，拆成一条有时间、有流量、有指标、有退路的通道。通道建得好，团队半夜敢睡觉；通道没建好，

核心判断：模型路由落地，先把数据与场景管住，再谈模型切换
我做过不少企业AI项目的梳理，也见过团队一上来就讨论“用哪个模型”。但真正跑到生产环境里，问题往往不在模型本身，而在路由规则背后的数据口径、权限边界、评测集和运营机制。模型路由说白了，就是让不同的问题、不同的用户、不同的业务场景，找到合适的模

这两年我在做企业数据治理咨询的时候，被问得最多的一句不是\”该买什么平台\”，而是一句听上去很像术语、又说不清边界的话。有人把它写进招标文件的建设内容里，有人把它当成一个可以直接采购的产品名，还有人在内部汇报的 PPT 上把它放在架构图最上面一层。每次遇到这种情况，我都会先停下来问一句：你说这四个字的时

我做企业数据与 AI 落地咨询十多年，近两年被问得最密集的一句话就是：MCP 到底是什么，是不是企业接大模型的标配。我的答案一直很直接——MCP 是一根管子，不是一锅饭。它解决的是\”模型怎么调用外部工具和数据源\”这件事，把过去各家私有插件格式的乱象收敛成一个相对统一的接口约定。但管子通不通，跟饭好不