MCP 协议入门: 大模型连接外部工具的统一接口

上一课讲 Function Calling 时留了一个尾巴：各家 API 的工具定义互不相通，工具一多，集成工作量就爆炸。这一课要讲的 MCP（Model Context Protocol，模型上下文协议）就是冲着这个问题来的——它是 Anthropic 开源的一套开放协议，给”大模型连接外部工具和数据”这件事定了统一接口。你可以把它理解成 AI 应用世界的 USB-C：插口统一了，设备和配件才能随便组合。

学完这一课，你能回答三个实际问题。第一，MCP 到底解决什么，它和 Function Calling 是什么关系；第二，Host、Client、Server 三个角色和 tools、resources、prompts 三种原语分别是什么，聊方案时不再被术语绕晕；第三，作为产品经理，怎么评估”要不要把自家服务包成 MCP server”这笔账——这可能是接下来一两年里工具类和 To B 产品最值得算的一笔账。

先给结论：MCP 本身不产生任何新能力，它降低的是能力的”流通成本”。抓住这一点，后面所有细节都会变得好记。

本文是《AI 产品经理课》第 10 课 · 专题目录 · 学习路线 · 上一课: 第 9 课 · 下一课: 第 11 课

全部 13 篇目录

MCP 是什么: AI 应用的 USB-C

MCP 全称 Model Context Protocol，模型上下文协议，是 Anthropic 在 2024 年 11 月开源的一套开放协议。”开放协议”四个字用白话说就是：规范全文公开，谁都可以照着实现，不绑定任何一家的模型或产品——就像 HTTP 不属于某家浏览器厂商一样。

官方给它的类比是”AI 应用的 USB-C 接口”，这个类比相当贴切。回想 USB-C 出现之前的世界：每个手机一种充电口，每台相机一种数据线，出差得带一整包线材。AI 工具生态在 MCP 出现之前就是这个状态——每个 AI 应用要接每个外部工具，都得单独写一套对接代码，格式互不相通，做的事却大同小异。USB-C 统一的是物理插口和电气规范，MCP 统一的是”AI 应用和工具之间怎么握手、怎么互相说话”的消息规范。

再往下挖一层就够了：MCP 的消息基于 JSON-RPC——一种用 JSON 格式封装”请求”和”应答”的消息约定，通信双方都按同一个结构收发。产品经理不需要会写它，只需要知道一件事：正因为消息层是标准化的，”任何客户端连任何工具”的互操作才成立。

最后强调一遍定位：MCP 不是模型，不是产品，也不是某个 App，它是一份协议、一份约定。判断一个东西”支不支持 MCP”，问的是它有没有按这份约定实现接口，仅此而已。

解决什么问题: 把 M×N 变成 M+N

先算一笔集成账。假设市面上有 M 个 AI 应用（桌面助手、AI 编程工具、企业内部的对话机器人），你的团队有 N 个想接入的工具和数据源（订单系统、日历、内部 Wiki、数据库）。没有统一协议时，每一对组合都要单独开发：3 个应用乘以 10 个工具，就是 30 份胶水代码；任何一边升级，你都要回头检查这 30 份代码有没有被改坏。

MCP 把这道乘法改成了加法：应用侧只要实现一次协议支持，工具侧只要实现一次 MCP server，两边就能任意组合。3 加 10 等于 13，之后每新增一个工具，所有应用自动可用。这就是”协议”的价值——它不生产功能，只消灭重复对接。

这里要澄清一个高频误解：MCP 不是来替代 Function Calling 的，两者互补，管的是不同层面的事。第09课讲的 Function Calling 解决”模型怎么表达调用意图”——模型输出一段结构化的”我想调用 X，参数是 Y”，这件事发生在模型和应用之间；MCP 解决”工具怎么被标准化地接入和发现”，这件事发生在应用和工具之间。打个比方：Function Calling 是服务员听懂客人点菜的话术，MCP 是餐厅和所有供应商之间统一的进货单格式。点菜和进货，缺一不可，但根本不是一件事。

对企业产品经理还有一个关键信号：老系统也能上车。站内有个很典型的案例——面对几十年历史的西班牙地籍 SOAP 老接口，开发者包了一层 JSON 封装就接入了 MCP 协议。存量系统不用重写，加一层”翻译”就能进入 AI 生态。评估接入成本时，这一点经常被高估，值得拿这个案例去校准预期。

架构: Host、Client、Server 三个角色

MCP 的架构里有三个角色，名字有点抽象，配个类比就好记了：Host 是手机，Client 是手机里管蓝牙连接的模块，Server 是蓝牙耳机和音箱。

Host（宿主）：用户直接面对的那个 AI 应用，比如 Claude Desktop、Cursor 这类桌面工具。它负责界面、调用模型、把关权限——决定哪些工具可以被用、用之前要不要先问过用户。

Client（客户端）：Host 内部的连接组件，每个 Client 和一个 server 保持一对一的连接，负责消息收发。用户一般感知不到它的存在，就像你感知不到手机里的蓝牙协议栈在干活。

Server（服务端）：能力提供方。谁手里有工具、有数据，谁就把它们按 MCP 规范包装成一个 server 暴露出去。一个 Host 可以同时连接多个 server，就像一部手机同时连着耳机、手环和车机。

产品经理看这张架构图，最该记住的是责任边界：如果你的公司是”能力供给方”，你只需要关心怎么做好一个 Server；Host 和 Client 是 AI 客户端厂商的事，你完全不用碰。边界清晰意味着分工清晰——谁的问题谁修，不再需要两边工程师拉群联调三个星期。这正是标准化架构对协作成本的直接改善。

三种原语: tools、resources、prompts

“原语”这个词听着吓人，白话就是协议规定的三种基本供给类型——一个 MCP server 能对外提供的东西，就这三类。

tools（工具）：模型可以调用去”做事”的动作接口，比如查订单、建工单、发消息。这和第09课 Function Calling 里的函数是一脉相承的概念，只是按统一规范打了包。

resources（资源）：供读取的数据内容，比如一份文件、一条数据库记录、一页文档。侧重”给模型看”，而不是”让模型做”。如果你的能力主要是数据供给，可以回想第07课讲的 RAG——”把资料翻给模型看”这件事，resources 提供了另一种标准化入口，两者各有适用场景。

prompts（提示词模板）：server 预置好的提示词模板，用户可以直接取用。相当于工具方把”怎么正确使用我”的最佳实践和产品一起发货。

翻译成产品语言：tools 是你产品的动作能力清单，resources 是你愿意暴露的数据面，prompts 是随箱附赠的说明书。设计一个 MCP server 的过程，本质上是在写一份”给 AI 看的产品说明书”——哪些能力开放、哪些数据可见、推荐怎么用，全部要显式声明。这活儿和写 PRD 的思维方式高度重合，产品经理不但能参与，而且应该主导能力清单的取舍。

传输方式: 本地 stdio 还是远程 HTTP

MCP 支持两种主要的传输方式。别被术语吓住，区别就一句话：server 跑在哪。

本地 stdio：server 作为一个本地程序跑在用户自己的电脑上，AI 应用把它拉起来，两个进程通过标准输入输出（stdio）传消息——可以理解为同一台机器上的两个程序面对面说话。这种形态能触碰用户本机的文件和环境，能力很强。站内那个复用 Chrome 登录态、把浏览器控制封装成 MCP 服务的开源工具就是典型：要操作用户本机的浏览器，天然只能本地跑。

远程 HTTP：server 部署在服务端，AI 应用通过网络访问。适合 SaaS 类服务——集中部署、统一升级、可控可审计，但认证、多租户、限流这些服务端功课一样都少不了。

对产品经理来说，这个选择直接决定产品形态，可以用一个问题快速定位：你的能力离用户的机器近，还是离你的服务近？要操作本地文件、本地开发环境的，选 stdio，代价是用户要安装东西、升级分发难、出了问题排查在用户侧；能力本身在云端的，选 HTTP，代价是要把服务端那套工程做扎实。很多团队的第一版会从 stdio 起步验证需求，跑通了再视规模决定要不要服务化——这个演进路径本身没什么错，但要在规划里写明白，别让临时方案变成永久架构。

生态现状: 从尝鲜到标配

判断一个协议是不是”成了”，看两个信号：主流玩家有没有跟进，周边工具链有没有长出来。MCP 两个信号都有了。

主流的 AI 编程工具和桌面客户端目前已经普遍支持 MCP。想亲手体验的话，Claude Desktop 中文使用指南里有安装和 MCP 配置的流程；培训市场也跟进了，尚硅谷开出了针对 Cursor 与 Claude 的 MCP 实战课程——培训机构开课是个很实用的风向标，说明这项技能开始进入招聘市场的要求清单。

开源生态这边同样热闹：集成 MCP 与 Subagent 的桌面工作台 Atrium、基于 Cloudflare 架构、通过 MCP 让 AI 读写笔记的 EdgeEver，都是把 MCP 当作默认集成方式的新产品。更有意思的信号是管理工具的出现：mcpctl 专门用来统一管理多个客户端的 MCP server 配置——”装太多了需要专门的工具来管”，这件事本身就说明生态已经过了尝鲜期。

当然也别开滤镜，早期生态一定有粗糙的地方，比如站内记录过 Codex CLI 的 MCP 服务器在 logout 时吞掉 session 的问题。产品评估接入时，给兼容性测试留出时间，别按理想状态排期。想持续跟进这些工具的动态，可以看站内的 Claude Code 专题和 Codex 专题。

安全: 第三方 server 是供应链风险入口

MCP 把”接入工具”变得像装 App 一样容易。这是好事，但硬币的另一面是：风险入口也跟着变多了。

先想清楚装一个第三方 MCP server 意味着什么：它声明的工具会进入模型的候选清单，被模型自主调用；它能触达你授权范围内的数据和环境。第04课讲过，智能体的特点是自主行动——工具被调用的时机不完全由人逐次把关。给一个会自主行动的系统装插件，审慎程度应该高于给手机装 App，而不是低于。

这不是杞人忧天。站内讨论过 ChatGPT 网页版通过 MCP 协议连接本地环境的安全隐患——网页端会话能触达本地环境，攻击面就此打开。相应地，防御侧的工具也在长出来，比如支持 MCP 协议、防止 AI 引入漏洞依赖的 Deptrust CLI。

给产品经理的三条原则，够用很久：最小权限——只授予完成任务必需的权限，读和写分级管理；来源可信——优先官方实现或可审计的开源项目，来路不明的 server 宁可不用；动作留痕——高危操作必须过用户确认，并留下审计日志。第09课说过”工具的权限与审计是安全底线”，MCP 时代这句话的分量只增不减：接入越方便，清单审查越要成为制度，而不是靠个人自觉。

产品视角: 把自家服务包成 MCP server

最后回到产品经理最关心的问题：这跟我的产品有什么关系？

一句话回答：把自家服务包装成 MCP server，等于拿到进入所有 AI 入口的门票。类比移动互联网的早期——用户迁移到手机上，你就得有个 App；现在用户的工作流开始泡在 AI 客户端里，你的服务如果不在模型的工具清单里，对这部分用户来说就等于不存在。

垂直服务已经有人这么玩了：基于 Claude Code 与卖家精灵 MCP 的亚马逊爆款助手把电商数据服务变成了 AI 工作流里的原生环节，同路线的还有基于 Claude MCP 协议的亚马逊竞品分析自动化 Agent。企业侧，Dify、vLLM 与 MCP 协议融合的企业级 AI 中台架构也已经是被认真讨论的方案。这条路上跑的产品会越来越多，更多智能体方向的案例可以翻站内的 AI Agent 专题。

如果你评估后决定做，四步走：

盘点：自家 API 里哪些动作对用户高价值、低风险？从查询类动作起步最稳。
精选：第一版只暴露 3 到 5 个工具，别把整个 API 目录倒进去——第09课讲过，工具一多模型就选不准。
写好描述：每个工具的 description 用大白话写清楚”什么时候该用我”，这一句话直接决定模型的调用准确率，也是产品经理能亲手贡献质量的环节。
定权限与审计：读写分级，写操作和高危动作必须过用户确认。

再提醒一句：MCP server 是产品，不是 demo。要有版本管理、调用监控和下线预案，不能发出去就不管了。系列之外的产品经理相关文章，都归档在 AI 产品经理专题里。

FAQ

MCP 会取代 Function Calling 吗？

不会，两者管不同的层面。Function Calling 是模型表达”我要调用哪个工具、传什么参数”的机制，发生在模型和应用之间；MCP 是应用和工具之间的接入标准，解决工具怎么被发现、怎么通信。实际系统里两者是接力关系：MCP 负责把工具送到应用面前，模型再通过工具调用机制去使用它们。评估方案时如果听到”我们用了 MCP 所以不需要 Function Calling”，可以多问一句——大概率是概念混了。

我们公司应该做 MCP server 吗？

做三个判断题：你的目标用户是否已经在 AI 客户端里工作（开发者、运营、分析师是最先迁移的人群）？你的服务是否有高频、可标准化的动作或数据？你能否投入做权限与审计设计？三个都答”是”，就值得用 3 到 5 个工具做一版小试点；有”否”，先等一等，把那个”否”变成”是”再动手。

不写代码的产品经理需要亲手配置一次 MCP 吗？

建议至少体验一次：找一个桌面客户端，装一个官方提供的 server，跑通一次真实调用。目的不是学技术，而是获得两个手感——接入成本到底有多低（或者有多高），以及用户从配置到调用的体验链路长什么样。没有这个手感，评估报价和排期的时候容易被忽悠。

MCP 只能和 Claude 一起用吗？

不是。MCP 是开放协议，规范公开，任何客户端都可以实现，目前主流 AI 编程工具和桌面应用已经普遍支持。选型时建议多看一层：不只看”支持 MCP”这个标签，还要看支持到什么程度——只支持 tools，还是 resources 和 prompts 也支持，这决定你能用上的能力范围。

装第三方 MCP server 最需要担心什么？

供应链风险。server 是别人写的代码，却运行在你的授权范围内，它声明的工具还会被模型自主调用。三条底线：只用可信来源（官方或可审计的开源实现）、只给最小权限、高危操作必须过人工确认。企业环境里，建议把 MCP server 纳入与第三方依赖同级别的安全审查流程。

结语

MCP 不生产能力，它降低能力流通的成本。产品经理不必背协议细节，只需想清楚：自家服务要不要进 AI 的工具清单，以什么权限、什么形态进。下一课讲微调。