模型网关

我在企业数据与 AI 项目里做了十几年，模型调用这一层的事，能踩的坑基本都踩过一遍。客户找上门的时候，开场白惊人地一致：能不能同时接三四个大模型、按成本和延迟自动切、某个模型挂了自动兜底。听起来是个纯粹的调度技术题，可我这几年的判断一直是——八成以上的麻烦不在调度层，而在它下面的数据层。同一个客户在

我的判断是：MCP 代理不是一个官方术语，它是中文圈子里对三种不同东西的混称。Anthropic 在 2024 年底把 Model Context Protocol 开源之后，工具调用这件原本各家自说自话的事，突然有了一个相对统一的接口约定。协议规范里定义了 Host、Client、Server

我在企业数据与 AI 项目里做了十多年，最近半年被问得最多的问题里，MCP 代理绝对排前三。我的回答往往从一句不太好听的话开始：大多数人把注意力放错了地方。他们关心协议怎么接、工具清单有多长、模型支不支持，却很少有人先问一句——代理最后调到的那个数据，口径是统一的吗？权限是管得住的吗？
MCP 代理

我先把话放这儿：MCP代理不是一个新冒出来的营销词，它是把大模型从\”会聊天\”推到\”能干活\”的那根传动轴。过去两年我在给制造、金融、能源几个行业做数据与AI落地咨询时，最常被问到的问题不是\”我们要不要上大模型\”，而是\”模型接不上我们的系统，答出来的东西不对，怎么办\”。这个卡点的本质，就是模型和业务系统

我对 MCP 代理集成这件事的基本判断
我做过好几个把大模型能力接进企业内网的活，最深的感受是：MCP 这个协议本身不复杂，复杂的是你要接的那些东西。协议规范读两个小时就懂了，工具描述、资源读取、提示模板，三种原语，清楚得很。但真到了客户现场，卡住你的从来不是协议，是\”这个指标到底谁说了算\”\”这张表

我这两年跟不少企业的数据团队聊过 MCP 代理这件事，感受很直接：MCP 代理真正的价值不在“能连多少系统”，而在于它把企业里散落的数据、接口、指标口径重新组织成一套可被 AI 稳定调用的能力层。很多团队一开始把它当成一个技术插件来做，接几个 API、跑通一个问答 Demo 就收工，结果上线两周就没

MCP 代理这类项目翻车，很少翻在协议上，基本都翻在数据供给和权限边界上。过去一年多我跟着看过十几个把 MCP 接进业务系统的活儿，场面高度雷同：演示环境行云流水，一进生产就哑火。销售给你看的是\”代理能查数据\”，你真正要解决的是\”代理查到的口径是不是全公司同一个\”\”它能不能只看到这个部门该看的字段\”

我从 2024 年下半年开始真正接触 MCP 这套协议，到 2025 年为止，手上已经跟着团队走过七八个客户现场，有做离散制造的，有做城商行数据中台的，也有省级政务云的项目。一个很直接的感受是：给 MCP 代理做选型，比前几年挑数据中台还难。难的地方不在协议本身，协议是开放的，规范文档就那么些页，任

核心判断：代理能不能用，先看数据底座我在企业数据和智能体项目里滚了七八年，最近一年多被问得最多的就是这句话：MCP 代理到底能不能直接接上我们的业务系统？我的答案一直没变——能接，但接完之后准不准，跟你选哪个框架关系不大，跟你的数据底座关系极大。MCP（Model Context Protocol）

这一年多我前后跟进过六个把 MCP 代理塞进企业数据场景的项目，两个做了一半停掉，三个还在半死不活地改 prompt 和工具描述，只有一个真跑起来、业务方每周主动在用。我复盘下来发现，决定生死的东西跟模型换代关系不大。跑起来那个，动手之前花了三个月把指标口径、主数据、权限边界理清楚，代理只是最后那层