Model Context Protocol
MCP 讨论的不是“模型本身更强了没有”,而是“模型应用怎么用统一方式接外部世界”。
拖动客户端和服务器数量,看看“每对都单独对接”和“都说 MCP”之间,集成成本会差多少。
点卡片翻面,把“标准插口”拆成几个真正起作用的部件。
MCP 不是“模型直接冲出去乱调工具”,而是先握手、再声明能力、再按规则使用。
应用里装着模型,也装着 MCP client。它先和某个 MCP server 建立连接,准备交换信息。
连接建立后,会先声明“我支持什么”。客户端和服务器都会告诉对方自己能做哪些事、能接受哪些能力类型。
这一步相当于把“你这里有什么资料、模板和动作”列出来,让客户端后面可发现、可读取、可调用。
模型不必预装每个系统的私有接口。它只要通过客户端,用统一方式挑选资源、读取上下文、触发工具。
工具结果、资源内容或提示模板再回到客户端,由客户端继续交给模型或应用界面使用。
MCP 最核心的收益,不是“神秘增强模型”,而是减少重复适配。
如果每个客户端都要单独适配每个系统,连接越多,集成方式越碎。今天接 GitHub,明天接本地文件,后天又要重做数据库接入,每一对组合都可能要重新造一套胶水层。
一旦客户端和服务器都按 MCP 说话,新增能力时更多是在“接入一个标准口”。这不会消灭所有工程工作,但会显著减少重复的私有接线。
MCP 很容易被说成“工具调用新名字”,但其实层级更高。
“AI 世界的 USB-C”很好懂,但也别类比过头。
顺着这些概念看,MCP 会更容易放进你的脑中地图里。
答完这 3 题,基本就能分清 MCP 解决的是“协议层”还是“能力层”。