先说痛点：N×M 对接地狱
在 MCP 之前，想让一个 AI 应用连上公司内部系统，每接一个系统就要写一套定制对接代码；换一个模型，这套对接又得重写一遍。系统是 N 个、模型是 M 个，对接就是 N×M 套，重复劳动爆炸。这是 AI 落地的隐形高成本，很多人没意识到「接系统」比「调模型」更费钱，也更易烂尾。
MCP 是什么
MCP（Model Context Protocol，模型上下文协议）是给 AI 模型连外部系统定的一个开放标准。类比最直观：它像 USB-C，设备和接口统一了，一个口能接很多东西。模型不再为每个系统单独适配，而是通过统一的 MCP 协议去调工具、读数据，对接从「每对都重写」变成「各实现一次」，重复工作量断崖式下降。
它怎么工作
架构上是两端：MCP server 跑在你这边，负责把某个系统的能力暴露成标准接口（比如「读订单库」「发站内信」）；MCP client 跑在模型应用那端，按协议去调用这些接口。模型想查数据，就发一个标准请求，server 执行后把结果回填。模型侧不用知道订单库长什么样，只管「我要查最近订单」，由 server 翻译成真实查询。
能省掉哪些事
- 重复对接：一个 MCP server 写好，所有支持 MCP 的模型都能直接用它，不用为每个模型重写。
- 上下文膨胀：数据不用全塞进 prompt，模型按需实时调，省 token 也降幻觉。
- 维护成本：系统升级只改 server 一处，所有调用方自动跟上，不用逐一通知。
一个真实案例
客服场景：建一个「订单 MCP server」，暴露「查订单状态」「查物流」两个能力。客服 AI 接入后，用户问「我包裹到哪了」，模型直接调订单 server 拿到实时数据回答，不用把整库订单预加载进对话，也不用人工把数据复制粘贴给 AI。它省掉的是「把数据搬进 AI」这个最笨的环节，也顺带避免了数据过期导致的答非所问。
和 Function Calling 的区别
容易混的是 MCP 和模型自带的 Function Calling。Function Calling 是「模型能调函数」，但每个应用要自己定义函数、自己维护；MCP 在这之上加了一层「标准接口」，让函数定义和使用方解耦。简单说，Function Calling 解决「模型会不会调」，MCP 解决「调的接口通不通、能不能复用」。两者可叠加：MCP server 用 Function Calling 把能力暴露给模型，一个管「能不能」，一个管「接得稳不稳」。
企业落地的最小步骤
真要落地，最小动作是三步：先列清楚「AI 要能做什么动作」（别一上来想接十个系统）；再为每个动作写一个 MCP server 暴露标准接口；最后在模型应用侧接 client 并配好权限。先把一个高频场景跑通（比如查订单），验证链路，再扩。贪多一次接全公司系统，十有八九卡在权限和边界，反而慢，分步走比一把梭稳。
适用边界
MCP 适合「有稳定系统、要被多个 AI 反复调用」的场景，ROI 最高。反之，一次性临时任务不值得建 server；纯静态知识问答也不用；权限管控要跟上——server 暴露的能力一旦过宽，模型可能越权操作，安全边界得人定好。它是连接标准，不是安全方案，别指望协议替你把权限管住。
怎么判断该不该上 MCP
一个简单判据：如果你打算让两个以上的 AI 应用访问同一个系统，或者一个 AI 要访问两个以上的系统，就该考虑 MCP；如果只接一次、用完即弃，直接写对接更快。别为了「跟上标准」而引入，标准是用来减重复的，重复没发生它就没价值，强行上反而增加维护负担。
局限声明
MCP 的协议细节与生态支持随社区演进，本文基于公开规范与主流实现，具体能力以你采用的 server/client 版本为准。涉及生产系统对接时，鉴权、审计与最小权限须自行设计，协议本身不保证安全，别把便利当保险。