大模型开发必看：轻松掌握MCP协议，让AI应用如虎添翼！

MCP模型上下文协议是一套让AI应用以统一方式发现、读取和调用外部能力的开放协议。它解决了外部能力接入AI应用时的重复适配问题通过规范工具描述、调用请求和结果返回使同一套业务能力可以支持多个AI应用。本文以“查询订单”为例详细解析了MCP的工作流程包括工具定义、模型生成调用意图、应用路由并发送MCP调用请求、服务端执行工具返回结果等步骤帮助开发者更好地理解和应用MCP协议。日常讨论中常有人把 MCP 与传统 API 画上等号或认为MCP只是多套了一层壳直接调用API会比MCP来得快。产生这种印象并不奇怪主流开发框架和客户端已经屏蔽了底层协议细节开发者往往只需填一段 JSON 配置工具就自动出现在 Agent 列表里了。01MCP 统一了什么如果一个 AI 应用只需要连接一个固定工具开发者直接阅读接口文档、编写调用代码即可并不需要额外协议。但当工具数量增多且同一套业务能力需要接入不同 AI 应用时重复适配的工作就会增多描述格式不一不同应用各自约定工具的定义结构和注册方式调用方式各异有的请求远程 HTTP 接口有的拉起本地脚本交互细节碎片化工具清单获取、参数校验和错误处理缺乏统一标准。MCP 为 AI 应用客户端和能力提供方服务端约定了共同的通信规则如何发现能力、如何描述工具、如何发送调用、如何返回结果。能力提供方实现 MCP ServerAI 应用通过内置的 MCP Client 访问它。从广义上看MCP 本身也是一组程序接口。因此讨论“MCP 与 API 的区别”时通常是在比较两个层面的事情业务 API针对具体业务设计的接口回答“这项业务怎么调用”MCP 协议面向 AI 应用的能力暴露与访问标准额外统一了“可用能力如何被发现、参数如何向模型描述、请求与结果如何标准化组织”。接下来我们结合一个具体的业务场景看看这两者是如何配合的。02用查询订单的例子把 MCP 放进来假设公司有一套订单系统提供如下查询接口●●●CODEGET /api/orders/123返回结果●●●CODE{ order_id: 123, status: 已发货}在传统软件中开发者在程序中处理请求地址、参数、认证方式和返回值就能完成调用。但如果现在要让 AI Agent 回答“帮我查一下订单 123 发货了吗”会发生什么大模型并不会因为读懂了这句话就自动知道公司内部接口的地址也不会天然持有接口凭据。应用程序必须先告诉模型当前有一个名为get_order的工具可用于查询订单状态调用时需传入 order_id。模型据此生成调用意图再由应用程序代为执行。这一基本机制与是否使用 MCP 无关。即便完全不用 MCP应用也可以把 API 包装成模型可识别的工具模型负责表达调用意图外围程序负责执行操作并回填结果。在这个流程中引入 MCP改变的是“应用程序如何访问外部工具”这一段——将其从私有对接改为按统一协议通信在这里订单 API 依然负责处理核心业务而 MCP Server 则负责把“查询订单”这项能力按 MCP 规范对外暴露。注封装现有 HTTP API 只是常见实现方式之一。MCP 工具内部完全可以直接查询数据库、读写本地文件或执行本地计算并不要求背后一定存在一个 HTTP 接口。03把模型、应用和服务端分开看日常交流中我们常把整个 AI 应用统称为“客户端”。但在 MCP 架构下还需要区分模型、Host、Client 和 Server 各自的职责组成部分在本例中对应谁核心职责大模型LLM应用所调用的模型理解用户问题选择工具并生成参数根据执行结果组织最终回答Host宿主应用Agent 应用本身管理对话上下文、模型调用、权限控制、工具路由与整体执行流程MCP ClientHost 内部的连接实例与MCP Server 建立连接并收发协议消息MCP Server订单工具服务暴露工具定义校验调用请求执行订单查询并返回标准化结果它们之间的连接关系可以分为两条独立链路可以看到模型 API 的工具格式与 MCP 的协议消息格式分别用于两条不同的通信链路。Host 负责在两条链路之间搭桥。 严格来说工具格式的转换属于 Host 的模型适配层而 MCP Client 专注于与 Server 的协议通信。工程实现上两者常被封装在一起但理解架构时应当区分清楚。正因如此MCP 与具体的大模型厂商解耦也不绑定任何特定的 Agent 推理循环如 ReAct。04一次工具调用完整走一遍下面我们沿着用户提问“帮我查一下订单 123 发货了吗”完整走一遍底层的五步流转过程本文协议报文均基于 MCP 2026-07-28 版本。第一步应用获取工具定义Host 通过 MCP Client 向服务端发送tools/list请求获取当前可用的工具清单●●●CODE{ jsonrpc: 2.0, id: 1, method: tools/list, params: { _meta: { io.modelcontextprotocol/protocolVersion: 2026-07-28, io.modelcontextprotocol/clientCapabilities: {} } }}tools/list用于拉取清单无需指定具体工具名或业务参数。params._meta用于携带协议版本与客户端能力声明空对象{}表示本次请求未声明额外的客户端能力。若服务端工具较多并启用了分页响应中会包含 nextCursor客户端拉取下一页时将其作为 params.cursor 传回首次请求可省略同时保留 _meta。服务端返回的单个工具定义如下●●●CODE{ name: get_order, description: 根据订单编号查询订单状态, inputSchema: { type: object, properties: { order_id: { type: string, description: 订单编号 } }, required: [order_id], additionalProperties: false }}其中name在单个服务端内唯一标识工具description帮助模型理解工具用途inputSchema则通过 JSON Schema 严格定义入参结构。拿到这份定义后Host 会将其转换为当前大模型 API 所需的工具格式不同模型厂商的字段结构略有差异。当可用工具很多时Host 可以自行缓存、筛选或按需加载MCP 并不要求每次都将全部工具塞进模型上下文。第二步模型生成调用意图Host 将用户问题与转换后的工具定义一并传给大模型。模型判断需要调用工具返回如下结构的信息此处为原理示意●●●CODE{ call_id: call_order_01, name: get_order, arguments: { order_id: 123 }}需要注意此时订单查询尚未发生。模型只是通过 Function Calling表达了“打算调用哪个工具、传入什么参数”的意图。第三步应用路由并发送 MCP 调用请求Host 识别到模型的调用意图后先确认该工具归属哪个 MCP Server完成参数与权限检查再通过对应的 MCP Client 发送 tools/call 请求。Host 是如何知道工具归属的在第一步向各个服务端拉取 tools/list 时Host 就已经记录了每个工具与所属 MCP Server及其对应 Client 连接的映射关系即路由表。如果同时连接了多个 MCP Server还可能遇到同名工具冲突。例如订单服务和物流服务都提供了 search 工具Host 可以在传给模型前加上不同的前缀提供给模型的工具名路由表记录的目标 MCP Server服务端原始工具名orders__search订单 MCP Serversearchshipping__search物流 MCP Serversearch当模型请求调用orders__search 时Host 查表定位到订单 MCP Server通过对应的 Client 连接还原为原始名称search发起调用。前缀是应用可采用的一种区分方式并非 MCP 强制规定。第四步服务端执行工具并返回结果订单 MCP Server 解析调用请求找到 get_order 对应的处理函数内部调用订单系统 API最后将结果封装为 MCP 标准格式返回。在这个过程中接口凭据和访问权限仍由服务端或宿主程序管理。工具定义不应包含底层密钥服务端也需要校验请求者是否有权访问对应订单。第五步应用将结果回填给模型Host 收到 MCP 响应后将其转换为大模型 API 要求的工具结果消息并通过 call_order_01 与第二步的调用请求关联起来。模型读取到“已发货”的状态后就可以据此回答用户“订单 123 已发货。”如果当前信息仍不足以回答问题模型还可以发起下一轮工具调用例如继续调用物流明细工具。回顾整条链路Host 在中间完成了三次关键适配Function Calling 解决模型如何表达调用意图MCP 解决应用如何标准化地发现与调用外部能力而 Host 负责把整套流程串联起来。05 MCP消息的内容格式理解了流转过程我们再直接看看通信管道里实际传输的报文。MCP 采用 JSON-RPC 2.0 作为消息格式一次标准请求主要包含四个核心字段字段含义jsonrpc协议版本固定为2.0id请求标识符用于将响应与对应的请求关联起来method要执行的 MCP 协议方法名如tools/list、tools/callparams该方法所需的参数对象以第三步的工具调用请求为例实际传输的 JSON 报文如下●●●CODE{ jsonrpc: 2.0, id: 7, method: tools/call, params: { name: get_order, arguments: { order_id: 123 }, _meta: { io.modelcontextprotocol/protocolVersion: 2026-07-28, io.modelcontextprotocol/clientCapabilities: {} } }}服务端收到这条消息后会经历两次分发执行成功后服务端返回的 JSON-RPC 响应如下●●●CODE{ jsonrpc: 2.0, id: 7, result: { resultType: complete, content: [ { type: text, text: 订单 123 已发货。 } ], structuredContent: { order_id: 123, status: 已发货 }, isError: false }}阅读这段响应时可以留意以下细节结果承载方式content 支持文本、图片等多种内容块适合直接供模型阅读structuredContent 则可携带结构化 JSON方便宿主程序做后续处理或 UI 渲染。双层 ID 映射请求和响应的 id: 7 用于 MCP 客户端与服务端之间的配对它与模型侧生成的call_order_01 属于两套独立的标识由 Host 负责维护映射。两类错误区分协议层错误如方法名不存在、JSON 格式非法直接通过 JSON-RPC 顶层的 error 字段返回工具执行错误如调用上游接口失败仍在 result 中返回并将 isError 设为true以便模型感知业务失败并决定如何向用户解释或重试。MCP Server 要完成的工作包括收消息、校验请求、分发方法、执行业务和返回结果。SDK 封装了其中许多重复的协议处理业务函数仍然需要开发者编写。06消息怎样传递stdio 与 HTTP前文介绍的是 MCP 消息的内容格式而消息如何从客户端送达服务端则取决于传输方式。MCP 最常用的两种传输方式是 stdio 和 Streamable HTTP它们底层承载的都是同一套 JSON-RPC 消息。1.stdio通过子进程的标准输入输出通信采用 stdio 时Agent 应用Host会先将 MCP Server 作为本地子进程启动随后通过操作系统的标准输入stdin和标准输出stdout管道收发消息这里有一个常见误区业务调用参数并不是每次通过命令行参数传入的。 命令行参数仅用于启动和初始化进程运行期的所有工具调用请求都是在进程启动后通过 stdin/stdout 管道持续流转的。Node.js 读取 stdin 的核心代码如下仅展示读取过程并非完整服务端实现●●●CODEimport { createInterface } from node:readline; const reader createInterface({ input: process.stdin, crlfDelay: Infinity}); reader.on(line, line { const request JSON.parse(line); // 接下来校验请求根据 method 和工具名分发执行});处理完成后服务端将响应序列化并加上换行符写回 stdout●●●CODEprocess.stdout.write(JSON.stringify(response) /n);为什么必须加换行符 因为操作系统管道传输的是连续字节流单次读取可能只拿到半条消息也可能粘连了多条消息。stdio 模式约定以换行符作为消息边界readline 模块正是据此完成缓冲与切分的。为什么日志要与协议消息分开 在 stdio 模式下客户端会逐行读取服务端的 stdout并把每一行当作 MCP 的 JSON 消息解析。Node.js 的console.log() 默认也写入这个通道如果打印一句“服务启动成功”客户端就会把这句话当作 JSON 解析因而报错。所以协议消息写入 stdout运行日志则用 console.error() 等方式写入独立的 stderr 通道。虽然叫“标准错误流”stderr 也可以承载普通日志并不代表程序发生了错误。2.npx 示例启动进程再走 stdio 通信日常配置中常见的 npx 写法可以结合上面的 stdio 过程理解●●●CODE{ command: npx, args: [-y, your-scope/order-mcp1.0.0]}这是启动配置示意包名为占位符具体字段以所用应用为准。Host 通过 npx 运行指定 npm 包的程序入口npx 会在需要时获取该包。假设程序采用 stdioHost 随后就通过它的 stdin/stdout 收发 MCP 消息。因此npx 只负责启动程序stdio 才负责协议通信。 你完全可以换成 node、python 或编译好的二进制文件来启动本地进程并使用 stdio反过来npx 也可以用来启动一个监听端口的 HTTP 服务——两者并没有绑定关系。3.Streamable HTTP向远程服务地址发送消息当工具服务需要独立部署或供多端远程访问时通常会采用 Streamable HTTP。此时 MCP Server 作为独立的 Web 服务运行对外暴露一个端点如 https://example.com/mcp。客户端将 JSON-RPC 请求放入 HTTP POST 请求体中发送。在 MCP 2026-07-28 版中一次工具调用的典型请求头如下●●●CODEPOST /mcp HTTP/1.1Content-Type: application/jsonAccept: application/json, text/event-streamMCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: get_order服务端从请求体解析出 method、name 和 arguments同时按规范校验请求头与正文的一致性执行函数后返回结果。需要注意两点普通 HTTP 接口 ≠ MCP Server仅仅提供一个/mcp 路由接收任意 JSON 并不构成 MCP 服务端。其消息结构、能力发现、Schema 描述以及结果与错误语义都必须严格遵循对应版本的 MCP 规范。单次响应与流式响应Streamable HTTP 允许服务端直接返回单个 application/json 响应适合简单查询也允许返回 text/event-streamSSE流式响应。通用客户端需同时支持这两种形式此外协议层的 SSE 响应流可以承载进度通知等消息和最终响应。stdio 通过本地进程管道通信常用于本地工具HTTP 通过服务地址通信适合独立部署与远程访问。两者在传输和运行方式上有所不同协议解析、工具分发和业务逻辑则可以复用。07 MCP配置文件为什么看起来什么都做了回到文章开头的问题为什么平时我们只写了几行 JSON 配置工具就能直接用了因为 Host 和Server SDK 已经实现了相应的连接和协议处理。当你在客户端配置文件里填入启动命令或服务地址后Host 会在后台自动拉起进程或建立连接、确认协议版本、发送 tools/list 获取工具清单并筛选出合适的工具注入模型上下文当模型发起调用时Host 又自动完成了路由查找、权限拦截、组装 tools/call 请求以及回填执行结果。配置文件只是告诉应用“去哪里找服务”的入口。同理在服务端使用 FastMCP 或官方 SDK 时你只需写一个业务函数并加上装饰器框架就会自动根据类型注解生成 JSON Schema、注册 tools/list 与 tools/call 处理器并处理请求响应关联和底层传输。如果脱离框架手写还需要自行处理参数校验、超时控制、子进程生命周期管理以及版本兼容等一系列工程问题。08MCP 不只有工具本文之所以围绕“工具Tools”展开是因为它在 Agent 开发中最常用。实际上MCP Server 还可以对外提供另外两类核心原语核心能力作用定位典型场景示例Tools工具可执行的操作可用于查询、计算或修改数据查询订单状态、创建售后工单、发送邮件Resources资源供应用读取的上下文数据类似只读文件/数据源产品知识库文档、数据库表结构说明、日志文件Prompts提示词模板服务端预置的可复用指令模板与工作流订单异常排查模板、代码审查规范模板除此之外MCP 规范还涵盖授权Authorization、进度通知Progress等机制。但在实际落地时完全不需要一次性实现所有特性按业务需求从 Tools 切入即可。从这些能力也能理解“模型上下文协议”这个名称外部系统提供的既有可执行的工具也有可以放进模型上下文的数据和指令模板。至于这些内容何时加载、如何拼装进模型的上下文窗口最终仍由 Host 统一调度。09总结回看一次工具调用各部分的职责可以这样区分大模型理解意图决定调用哪个工具、传什么参数HostAI 应用管理执行流程负责模型格式转换、工具路由与权限管控MCP Client / Server按统一的 JSON-RPC 协议发现能力、交换调用请求与结果stdio / HTTP负责把协议消息从客户端搬运到服务端最后再回应开头关于“MCP 与 API”的两个常见争论直接调 API 比走 MCP 更快MCP 多了协议处理和额外的网络跳转延迟开销在多数场景下可观测减少协议处理或额外通信可能降低延迟。但差距并非恒定需在相同条件下测量在需要结构化数据处理的复杂任务上MCP 反而可能更快。同时不能把模型推理耗时都算到 MCP 头上。是否采用 MCP还要看工具需要被多少应用复用——工具只服务单一应用时直接 API 更简单高效需被多个异构应用复用时 MCP 的标准化封装才摊薄成本、显现长期收益不能只比较一次调用的快慢。MCP 只不过把 API 又封装了一层“封装 API”只是 MCP Server 的一种常见实现方式它背后同样可以直接连接数据库或本地文件协议本身并不限定后端形态。MCP 的核心在于运行时能力发现客户端连接后获取工具列表及其参数描述JSON Schema并按统一规范发起调用而非在调用方代码中预先硬编码接口定义。如果你的应用只对接两三个固定接口直接写代码调用完全够用但当一套业务能力需要被多个团队、多种 AI 客户端共同接入和复用时MCP 的标准化封装可以减少重复适配让一套 Server 被多种兼容客户端直接复用。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取