导读本文是对吴恩达与 Anthropic 联合推出的 MCP 实战课共 11 集的系统性总结涵盖课程总览、为什么需要 MCP、核心架构、问答机器人示例、创建 MCP 服务器等核心内容。课程由吴恩达与 Anthropic 技术教育负责人 Elie Schoppik 联合讲授约 100 分钟讲透从原理到部署的完整链路。文中配有可视化速览卡片与可运行的 FastMCP 代码示例建议读者先浏览速览卡片建立整体认知再结合代码示例动手实践可显著提升学习效率。本文目录导读第 1 集课程总览MCP 模型上下文协议实战课第 2 集为什么需要 MCP终结 M×N 集成地狱第 3 集MCP 架构Host · Client · Server 三层解剖第 4 集问答机器人示例模型点菜、代码炒菜的工具调用循环第 5 集创建 MCP 服务器把论文工具搬进公共能力层李沐深度学习191集课程全解析模块拆解、学习路径-CSDN博客吴恩达《面向开发者的提示词工程》-CSDN博客吴恩达 MCP 教程Model Context Protocol-CSDN博客一句话总结《MCP 模型上下文协议实战课给 AI 应用装上「USB-C 接口」》—— 这门由吴恩达与 Anthropic 技术教育负责人 Elie Schoppik 联合讲授的约 100 分钟课程教你用开放协议 MCP 标准化连接 GitHub、Google Docs、本地文件等工具与数据从架构原理到服务器 / 客户端开发与部署一次讲透。详细总结这是 MCP 首席讲师亲自带练的官方课程逻辑上分为「是什么 → 怎么用 → 动手建 → 上线」四层递进上方已生成可视化速览卡片内容如下 MCP 是什么一个开放协议标准化了 LLM 应用获取上下文工具 数据资源的方式采用客户端-服务器架构且模型无关、易于集成到多种应用。它由 Anthropic 于 2024 年 11 月推出并开源最初是让 Claude 桌面版能读写本地文件系统等外部系统的内部项目。如今生态里已有大量开源服务器可供直接接入。️ 核心架构MCP 客户端驻留在你的 AI 应用Host如聊天机器人、代理或 Claude Desktop内部每个客户端与一个 MCP 服务器保持1 对 1 连接服务器对外提供三类能力——工具Tools、提示模板Prompts与资源Resources。你的应用无需自己开发定制工具把代理接到 GitHub、Google Drive、文件系统等服务器即可完成工具执行。 课程实战路线共 11 课① 简介 / ② 为什么选择 MCP解决以往连接的痛点→ ③ 架构原理 → ④ 构建兼容 MCP 的问答机器人、⑤ 创建 MCP 服务器、⑥ 创建 MCP 客户端 → ⑦ 连接引用服务器、⑧ 添加提示与资源 → ⑨ 为 Claude Desktop 配置服务器、⑩ 创建并部署远程服务器、⑪ 总结。 适合人群想给应用快速接入外部工具的开发者免于为每个数据源重复造轮子以及拥有工具/数据、希望被更多开发者复用的团队——这正是吴恩达在片尾强调 MCP 值得学的两个方向。在线链接MCP 课程速览吴恩达 × Anthropic 模型上下文协议 —— 一句话总结 MCP 核心概念 客户端-服务器架构图 11 课学习路线可直接分享。一句话总结《为什么需要 MCP用「构建一次、处处使用」终结 M×N 集成地狱》—— 本集指出模型能力取决于上下文MCP 像 REST 之于 Web 后端、LSP 之于 IDE 一样把 AI 应用与工具 / 数据源的连接方式标准化并现场演示了用自然语言「读 GitHub Issue → 分类 → 写入 Asana」的跨系统操作。详细总结可视化速览已生成在线链接为什么需要 MCP终结 M×N 集成地狱第 2 集速览。以下按「问题 → 类比 → 演示 → 生态 → 受益者 → 常见问题」的顺序展开。1️⃣ 出发点模型再强接不上数据也白搭Elie 开篇给出本集的底层逻辑模型的能力取决于为它提供的上下文。即便拥有前沿的「超级智能」模型如果无法连接外部世界、获取所需的数据和上下文其实用性也会大打折扣。因此问题不是模型不够聪明而是 AI 应用与数据源之间的连接方式太碎片化——每个团队都在重复造轮子工具存哪里、自定义提示模板存哪里、数据访问层与认证逻辑怎么写不同 AI 应用访问相似数据源却各写一套。2️⃣ 核心思想不重新发明轮子只统一「语言」MCP 是一个开源协议标准化了大型语言模型与工具、数据源的连接与协作方式。一个关键澄清是MCP 能做的所有事不用 MCP 也能实现——它的价值不在于解锁新能力而在于统一交互方式。设想一个多种模型与多种数据源相互通信的世界如果没有统一语言就是 M×N 的定制集成矩阵3 个模型 × 3 个数据源 9 套集成有了 MCP模型与数据源各自只需实现一次即为MN模式构建一次、处处使用。可视化卡片里的左右对比图直观展示了这一点。这一思想并非凭空创新而是站在前人肩膀上REST协议标准化了 Web 应用与后端系统的通信定义协议与无状态约束微软 2016 年开发的**语言服务器协议LSP**标准化了 IDE 与语言工具的交互——否则每做一种语言的扩展都要为每个开发环境重复编码。MCP 借鉴了这些协议的标准化理念把同样的思路带进 AI 世界。3️⃣ 现场演示几行代码自然语言跨系统操作课程演示了一个「读 写」的完整链路左侧是 Claude 桌面应用通过 MCP 服务器连接 GitHub用自然语言即时检索仓库 Issue随后又接入第二个 MCP 服务器Asana流行的项目管理工具把 GitHub 中读到的问题进行分类在 Asana 中创建工单并指派给特定人员。整个过程从 GitHub「读」、往 Asana「写」浏览器中的任务列表实时更新还能继续用自然语言迭代比如改派负责人。背后是一个由 Sonnet 3.5 驱动的轻量级代理配合 MCP 提供的若干工具且界面中设有人工审核环节——执行前先确认要做的操作。这正是 MCP 的威力少量代码 自然语言 人工把关就能打通外部系统。4️⃣ 关注点分离与生态现状MCP 把责任重新划分应用侧构建或使用「MCP 兼容应用」服务器侧提供所需的数据访问——数据存储类服务器如 CRM 工具 HubSpot、Salesforce甚至版本控制系统都可以用自然语言交互。服务器最美妙之处在于可跨多个应用复用同一台 Google Drive 服务器AI 助手、代理、桌面应用都能用只要它们兼容 MCP。协议本身与模型无关、完全开源服务器可来自官方参考实现、开源社区或企业内部自建共享。生态正在快速增长大公司与前沿初创公司均有参与多语言 SDK 由开源社区开发、多家公司和 AI 开发者共同主导MCP 兼容应用已覆盖 Web 应用、桌面应用乃至代理类产品。5️⃣ 对你的三点启示结合 AI 工程师视角集成架构选择当应用要接多个数据源时优先评估现成 MCP 服务器而非自写 API 层接入只需提供一个服务器 URL。工程性价比为团队构建的任何 MCP 服务器都是可复用资产——一次构建所有 MCP 兼容应用受益这正是企业「关注点分离」的价值。安全边界演示中的人工审核提示了一个工程范式——对写操作创建工单、改数据保留确认环节读操作可以放行。❓ 本集两个常见问题一是这些服务器GitHub、Asana、Google Drive 等由谁编写答案是任何人都可以开发者自建、用官方参考服务器或社区采纳版本均可后续课程将亲手构建多个。二是 MCP 服务器是否就等于 API 调用可以说它是 API 的封装层或网关——不想直接调 API 时由 MCP 服务器代劳并用自然语言驱动但工具使用只是其功能的一部分服务器还会提供函数与模式schema下一集将深入主机、客户端、服务器概念及资源、工具、提示等底层组件。来源B站 · 吴恩达 MCP 课程第 2 集一句话总结《MCP 架构Host · Client · Server 三层解剖与一次工具调用的完整旅程》—— 本集14:53全课最长讲透 MCP 的三层架构Host 是掌控全局的 AI 应用Client 是 Host 内部与服务器 1 对 1 连接的通信管理员Server 对外提供工具、提示、资源客户端与服务器之间用 JSON-RPC 2.0 通信本地走 stdio、远程走 HTTPSSE。详细总结可视化已生成并发布在线链接MCP 架构Host · Client · Server 全解析第 3 集速览。小说明B 站该分集字幕未能直接抓取以下内容依据课程公开课件与 MCP 官方规范整理与本集「MCP架构」大纲一致。1️⃣ MCP 三层架构是什么Host、Client、Server 三种角色 Host主机 你的 AI 应用本体聊天机器人、Claude Desktop、IDE、代理。它负责编排一切决定连接哪些服务器、把哪些工具暴露给模型、权限如何审批——安全与控制的入口。 Client客户端 驻留在 Host 内部的「连接管理器」每个客户端只与一台服务器保持1 对 1 连接接了 3 台服务器就有 3 个客户端。这与第 1 集总览中「hosting 多个客户端」的架构呼应。⚙️ Server服务器 独立进程或远程服务暴露工具 / 提示 / 资源模型无关、可跨应用复用。一个直观类比Host 像浏览器Client 像浏览器里的每个标签页连接Server 就是 Web 服务器——浏览器掌控安全与沙箱连接各自独立 Kinda Technical。2️⃣ MCP 用什么协议通信JSON-RPC 2.0 与两种传输方式客户端与服务器之间统一使用JSON-RPC 2.0消息请求 / 响应 / 通知Model Context Protocol。传输层两种模式stdio本地Host 把服务器作为子进程拉起通过标准输入输出通信简单高效与HTTP SSE远程走 Web 连接服务器可主动推送消息。工程上注意两者连接生命周期不同本地切远程并非无缝替换传输层的差异是常见踩坑点。3️⃣ MCP 服务器三大原语Tools、Prompts、Resources 谁控制️ Tools工具· 模型控制LLM 自主决定何时调用可执行、有副作用如查 GitHub、写文件。 Prompts提示· 用户控制预置提示模板由用户主动选用标准化常见任务。 Resources资源· 应用控制文件、数据等上下文材料由应用决定附加给模型偏只读。这个「控制权三角」是 MCP 设计最精髓的区分直接决定权限模型与交互设计。4️⃣ 一次工具调用怎么走五步旅程拆解① 用户提问Host 汇总各服务器的工具清单 → ② 模型决策是否调用、调用哪个 → ③ 对应客户端经 JSON-RPC 转发请求 → ④ 服务器真正执行调 API / 读数据→ ⑤ 结果回传 Host模型据此生成最终回答。 AI 工程师视角的三点启示为方便快速对照下面用两张表格分别梳理三层角色与三大原语。角色职责控制权示例Host主机AI 应用本体负责编排一切决定连接哪些服务器、把哪些工具暴露给模型、权限如何审批安全与控制的入口掌控全局聊天机器人、Claude Desktop、IDE、代理Client客户端驻留在 Host 内部的「连接管理器」每个客户端与一台服务器保持 1 对 1 连接负责与服务器的通信转发不直接决定工具暴露Host 内与 GitHub 服务器、Asana 服务器分别连接的客户端Server服务器独立进程或远程服务对外暴露工具、提示、资源提供能力清单模型无关、可跨应用复用GitHub 服务器、Google Drive 服务器、arXiv 论文服务器再看三大原语的控制方与用途原语控制方用途典型场景Tools工具模型控制可执行、有副作用的操作由 LLM 自主决定何时调用查 GitHub Issue、写文件、创建 Asana 工单Prompts提示用户控制预置提示模板由用户主动选用标准化常见任务一键生成周报、按固定模板总结论文Resources资源应用控制文件、数据等上下文材料由应用决定附加给模型偏只读把本地文档、数据库查询结果作为上下文喂给模型权限收敛在 Host 层写操作务必加人工确认延续第 2 集演示的安全范式工具清单随连接数增长会挤占上下文窗口需管理暴露数量理解「原语 控制权」能帮你快速判断一个功能该做成 Tool、Prompt 还是 Resource。来源B站 · 吴恩达 MCP 课程第 3 集一句话总结《问答机器人示例模型点菜、代码炒菜的工具调用循环》—— 本集先用纯 API尚未 MCP 化搭建一个能查 arXiv 论文的聊天机器人定义 search_papers搜论文与 extract_info提取论文信息两个工具模型只负责「决定调用哪个工具 给什么参数」由应用代码执行后回传结果循环往复直到生成最终回答。详细总结可视化已生成并发布在线链接问答机器人示例模型 × 工具协作循环第 4 集速览。1️⃣ 本集任务怎么搭一个「会用工具」的机器人本集进入代码实战部分的第一课。Elie 用 Anthropic 的 Claude API 构建一个命令行聊天机器人让它能完成超出模型自身知识范围的任务搜索 arXiv 上的学术论文并提取信息。项目由一个聊天循环 两个工具组成search_papers按关键词搜论文返回论文列表与 ID和extract_info按 ID 提取标题、作者、摘要等详情。工具的核心价值是扩展模型能力、避免幻觉。2️⃣ 工具使用循环本集的核心机制这是理解后面所有 MCP 课程的关键模式模型收到用户提问后并不直接执行任何函数而是返回一个特殊结构tool_use 块指明「我要用哪个工具 参数是什么」你的应用代码监测到该结构后真正执行函数把结果附加到消息历史中再发给模型模型基于结果生成回答若还需要更多信息就继续发起工具调用如此往复直到模型给出纯文本回复。整个过程就是一个 while 循环输入 quit 退出。 BibiGPT 课程摘要3️⃣ 三个关键要点工具定义三要素每个工具需要清晰的名称、描述和参数模式模型才能正确理解和调用——描述写得越准模型调用越可靠。「模型点菜、代码炒菜」模型与工具的交互是编排式的——模型只输出调用意图执行权在应用代码手里这也是所有安全审核如第 2 集人工确认能存在的根本原因。无持久记忆当前机器人每次对话相互独立上一轮查到的论文 ID 想在下一轮使用需要手动传递。4️⃣ 本集定位MCP 化之前的基线这版机器人把工具直接「焊」在应用里换个应用就得重写、无法复用——正是 MCP 要解决的问题。第 5 集「创建MCP服务器」08:57将把同样的论文工具搬进 MCP 服务器工具定义不再属于某一个应用而是任何 MCP 兼容应用都能调用的公共能力。来源B站 · 吴恩达 MCP 课程第 4 集一句话总结《创建 MCP 服务器把论文工具搬进公共能力层》—— 本集08:57把第 4 集「焊」在应用里的 search_papers 与 extract_info 两个工具迁移进一个独立的 MCP 服务器工具定义不再属于某一个应用而是任何 MCP 兼容应用都能调用的公共能力并用 Claude Desktop 现场验证调用。详细总结本集是「动手建」阶段的关键一步承接第 4 集的基线机器人演示如何把工具从应用内部抽离成标准化的 MCP 服务器。1️⃣ 本集任务把工具从应用里「搬」出来第 4 集的机器人把 search_papers 和 extract_info 直接写在应用代码里换个应用就得重写。本集的目标是把这两个工具封装进一个独立的 MCP 服务器进程让任何 MCP 兼容应用Claude Desktop、IDE、代理等都能直接调用实现「构建一次、处处使用」。2️⃣ 服务器骨架FastMCP 快速搭建课程使用 Python 的 FastMCP 框架搭建服务器核心代码非常简洁创建一个 MCP 服务器实例用装饰器把普通函数注册为工具最后启动服务器。工具函数本身与第 4 集几乎一致调用 arXiv API 搜索论文、按 ID 提取信息区别在于它们现在暴露在 MCP 协议层而非某个应用内部。3️⃣ 关键转变工具定义与调用方解耦这是本集最核心的认知升级工具不再属于应用而是属于服务器。应用侧只需通过 MCP 客户端连接服务器、获取工具清单就能像调用本地函数一样使用远程工具。模型看到的工具描述、参数模式都由服务器统一提供调用方无需关心实现细节。4️⃣ 验证方式Claude Desktop 直连调用课程最后把服务器接入 Claude Desktop用自然语言直接提问「帮我搜一下最近关于 MCP 的论文」模型自动触发 search_papers 工具、拿到结果后再调用 extract_info 提取详情完整复现了第 4 集的工具使用循环——但这次工具来自外部服务器而非应用内嵌代码。5️⃣ 本集定位从「焊死」到「可复用」下面给出一个完整的 FastMCP 服务器示例把第 4 集的 search_papers 与 extract_info 两个工具封装进独立服务器任何 MCP 兼容应用都能直接调用。from mcp.server.fastmcp import FastMCP import urllib.request import urllib.parse import json 1. 创建 MCP 服务器实例name 会作为服务器标识暴露给客户端 mcp FastMCP(arxiv-server) 2. 用 mcp.tool() 装饰器把普通函数注册为 MCP 工具 函数名、docstring 与类型注解会自动生成工具描述与参数模式 mcp.tool() def search_papers(query: str, max_results: int 5) - list[dict]: 按关键词搜索 arXiv 论文返回论文列表与 ID。 Args: query: 搜索关键词如 MCP 或 model context protocol max_results: 最多返回的论文条数默认 5 # 调用 arXiv API把关键词拼进查询 URL base http://export.arxiv.org/api/query? params urllib.parse.urlencode({ search_query: fall:{query}, max_results: max_results }) with urllib.request.urlopen(base params) as resp: data resp.read().decode(utf-8) 用简单字符串解析提取论文 ID 与标题生产环境建议用 feedparser papers [] for entry in data.split(lt;entrygt;)[1:]: paper_id entry.split(lt;idgt;)[1].split(lt;/idgt;)[0].strip() title entry.split(lt;titlegt;)[1].split(lt;/titlegt;)[0].strip() papers.append({id: paper_id, title: title}) return papers 3. 第二个工具按论文 ID 提取标题、作者、摘要等详情 mcp.tool() def extract_info(paper_id: str) - dict: 按 arXiv 论文 ID 提取标题、作者与摘要详情。 Args: paper_id: 论文 ID例如 2401.12345 拼接单篇论文的 API 地址 url fhttp://export.arxiv.org/api/query?id_list{paper_id} with urllib.request.urlopen(url) as resp: data resp.read().decode(utf-8) 解析标题、作者与摘要 title data.split(lt;titlegt;)[1].split(lt;/titlegt;)[0].strip() authors [a.split(lt;namegt;)[1].split(lt;/namegt;)[0].strip() for a in data.split(lt;authorgt;)[1:]] summary data.split(lt;summarygt;)[1].split(lt;/summarygt;)[0].strip() return {id: paper_id, title: title, authors: authors, summary: summary} 4. 启动服务器默认走 stdio 传输供本地 Host如 Claude Desktop拉起 if name main: mcp.run()运行前先安装依赖pip install mcp。启动后Claude Desktop 等 Host 即可通过 MCP 客户端连接本服务器用自然语言触发 search_papers 与 extract_info实现「构建一次、处处使用」。对比第 4 集本集完成了从「应用内嵌工具」到「独立 MCP 服务器」的跃迁同样的工具第 4 集只能给一个应用用第 5 集能被所有 MCP 兼容应用共享。这正是 MCP 的核心价值——工具与数据源的一次构建、处处复用。下一集「创建MCP客户端」将站在应用侧演示如何连接并使用这类服务器。来源B站 · 吴恩达 MCP 课程第 5 集第 5 集MCP 生态对比MCP 与 REST、LSP、Function Calling为帮助读者快速建立坐标系下面用两张表格分别对比 MCP 与 REST、LSP 的定位差异以及 MCP 与 Function Calling 的能力边界。协议定位标准化对象典型应用场景MCP标准化 AI 应用与工具、数据源的连接方式让模型按统一协议获取上下文LLM 应用与外部工具 / 数据源之间的交互工具、提示、资源三类原语Claude Desktop 连接 GitHub、Google Drive、arXiv 论文服务器跨应用复用同一套工具REST标准化 Web 应用与后端系统的通信方式定义资源与无状态约束HTTP 接口的资源表示与操作GET / POST / PUT / DELETE浏览器 / 移动端调用后端 API、微服务之间的数据交换LSP标准化 IDE 与语言工具的交互避免为每种语言重复开发编辑器扩展编辑器与语言服务器之间的诊断、补全、跳转等能力协议VS Code 等 IDE 接入 Python、TypeScript 等语言的智能提示与错误检查再看 MCP 与 Function Calling 的差异维度MCPFunction Calling本质开放协议标准化 AI 应用与工具 / 数据源的连接模型无关、可跨应用复用模型 API 的一种能力让 LLM 输出调用某个函数的意图与参数作用范围覆盖工具、提示、资源三类原语并定义传输层stdio / HTTPSSE与服务器生命周期仅覆盖「模型决定调用哪个工具 给什么参数」这一环执行仍由应用代码完成复用性工具定义属于服务器任何 MCP 兼容应用都能调用构建一次、处处使用工具定义通常写死在某个应用里换个应用就得重写典型关系可以理解为 Function Calling 的「协议化 服务化」升级把工具调用从应用内嵌提升为公共能力层是 MCP 化之前的基线骨架第 4 集问答机器人即用此方式实现 吴恩达 MCP 教程（Model Context Protocol）（一）
导读本文是对吴恩达与 Anthropic 联合推出的 MCP 实战课共 11 集的系统性总结涵盖课程总览、为什么需要 MCP、核心架构、问答机器人示例、创建 MCP 服务器等核心内容。课程由吴恩达与 Anthropic 技术教育负责人 Elie Schoppik 联合讲授约 100 分钟讲透从原理到部署的完整链路。文中配有可视化速览卡片与可运行的 FastMCP 代码示例建议读者先浏览速览卡片建立整体认知再结合代码示例动手实践可显著提升学习效率。本文目录导读第 1 集课程总览MCP 模型上下文协议实战课第 2 集为什么需要 MCP终结 M×N 集成地狱第 3 集MCP 架构Host · Client · Server 三层解剖第 4 集问答机器人示例模型点菜、代码炒菜的工具调用循环第 5 集创建 MCP 服务器把论文工具搬进公共能力层李沐深度学习191集课程全解析模块拆解、学习路径-CSDN博客吴恩达《面向开发者的提示词工程》-CSDN博客吴恩达 MCP 教程Model Context Protocol-CSDN博客一句话总结《MCP 模型上下文协议实战课给 AI 应用装上「USB-C 接口」》—— 这门由吴恩达与 Anthropic 技术教育负责人 Elie Schoppik 联合讲授的约 100 分钟课程教你用开放协议 MCP 标准化连接 GitHub、Google Docs、本地文件等工具与数据从架构原理到服务器 / 客户端开发与部署一次讲透。详细总结这是 MCP 首席讲师亲自带练的官方课程逻辑上分为「是什么 → 怎么用 → 动手建 → 上线」四层递进上方已生成可视化速览卡片内容如下 MCP 是什么一个开放协议标准化了 LLM 应用获取上下文工具 数据资源的方式采用客户端-服务器架构且模型无关、易于集成到多种应用。它由 Anthropic 于 2024 年 11 月推出并开源最初是让 Claude 桌面版能读写本地文件系统等外部系统的内部项目。如今生态里已有大量开源服务器可供直接接入。️ 核心架构MCP 客户端驻留在你的 AI 应用Host如聊天机器人、代理或 Claude Desktop内部每个客户端与一个 MCP 服务器保持1 对 1 连接服务器对外提供三类能力——工具Tools、提示模板Prompts与资源Resources。你的应用无需自己开发定制工具把代理接到 GitHub、Google Drive、文件系统等服务器即可完成工具执行。 课程实战路线共 11 课① 简介 / ② 为什么选择 MCP解决以往连接的痛点→ ③ 架构原理 → ④ 构建兼容 MCP 的问答机器人、⑤ 创建 MCP 服务器、⑥ 创建 MCP 客户端 → ⑦ 连接引用服务器、⑧ 添加提示与资源 → ⑨ 为 Claude Desktop 配置服务器、⑩ 创建并部署远程服务器、⑪ 总结。 适合人群想给应用快速接入外部工具的开发者免于为每个数据源重复造轮子以及拥有工具/数据、希望被更多开发者复用的团队——这正是吴恩达在片尾强调 MCP 值得学的两个方向。在线链接MCP 课程速览吴恩达 × Anthropic 模型上下文协议 —— 一句话总结 MCP 核心概念 客户端-服务器架构图 11 课学习路线可直接分享。一句话总结《为什么需要 MCP用「构建一次、处处使用」终结 M×N 集成地狱》—— 本集指出模型能力取决于上下文MCP 像 REST 之于 Web 后端、LSP 之于 IDE 一样把 AI 应用与工具 / 数据源的连接方式标准化并现场演示了用自然语言「读 GitHub Issue → 分类 → 写入 Asana」的跨系统操作。详细总结可视化速览已生成在线链接为什么需要 MCP终结 M×N 集成地狱第 2 集速览。以下按「问题 → 类比 → 演示 → 生态 → 受益者 → 常见问题」的顺序展开。1️⃣ 出发点模型再强接不上数据也白搭Elie 开篇给出本集的底层逻辑模型的能力取决于为它提供的上下文。即便拥有前沿的「超级智能」模型如果无法连接外部世界、获取所需的数据和上下文其实用性也会大打折扣。因此问题不是模型不够聪明而是 AI 应用与数据源之间的连接方式太碎片化——每个团队都在重复造轮子工具存哪里、自定义提示模板存哪里、数据访问层与认证逻辑怎么写不同 AI 应用访问相似数据源却各写一套。2️⃣ 核心思想不重新发明轮子只统一「语言」MCP 是一个开源协议标准化了大型语言模型与工具、数据源的连接与协作方式。一个关键澄清是MCP 能做的所有事不用 MCP 也能实现——它的价值不在于解锁新能力而在于统一交互方式。设想一个多种模型与多种数据源相互通信的世界如果没有统一语言就是 M×N 的定制集成矩阵3 个模型 × 3 个数据源 9 套集成有了 MCP模型与数据源各自只需实现一次即为MN模式构建一次、处处使用。可视化卡片里的左右对比图直观展示了这一点。这一思想并非凭空创新而是站在前人肩膀上REST协议标准化了 Web 应用与后端系统的通信定义协议与无状态约束微软 2016 年开发的**语言服务器协议LSP**标准化了 IDE 与语言工具的交互——否则每做一种语言的扩展都要为每个开发环境重复编码。MCP 借鉴了这些协议的标准化理念把同样的思路带进 AI 世界。3️⃣ 现场演示几行代码自然语言跨系统操作课程演示了一个「读 写」的完整链路左侧是 Claude 桌面应用通过 MCP 服务器连接 GitHub用自然语言即时检索仓库 Issue随后又接入第二个 MCP 服务器Asana流行的项目管理工具把 GitHub 中读到的问题进行分类在 Asana 中创建工单并指派给特定人员。整个过程从 GitHub「读」、往 Asana「写」浏览器中的任务列表实时更新还能继续用自然语言迭代比如改派负责人。背后是一个由 Sonnet 3.5 驱动的轻量级代理配合 MCP 提供的若干工具且界面中设有人工审核环节——执行前先确认要做的操作。这正是 MCP 的威力少量代码 自然语言 人工把关就能打通外部系统。4️⃣ 关注点分离与生态现状MCP 把责任重新划分应用侧构建或使用「MCP 兼容应用」服务器侧提供所需的数据访问——数据存储类服务器如 CRM 工具 HubSpot、Salesforce甚至版本控制系统都可以用自然语言交互。服务器最美妙之处在于可跨多个应用复用同一台 Google Drive 服务器AI 助手、代理、桌面应用都能用只要它们兼容 MCP。协议本身与模型无关、完全开源服务器可来自官方参考实现、开源社区或企业内部自建共享。生态正在快速增长大公司与前沿初创公司均有参与多语言 SDK 由开源社区开发、多家公司和 AI 开发者共同主导MCP 兼容应用已覆盖 Web 应用、桌面应用乃至代理类产品。5️⃣ 对你的三点启示结合 AI 工程师视角集成架构选择当应用要接多个数据源时优先评估现成 MCP 服务器而非自写 API 层接入只需提供一个服务器 URL。工程性价比为团队构建的任何 MCP 服务器都是可复用资产——一次构建所有 MCP 兼容应用受益这正是企业「关注点分离」的价值。安全边界演示中的人工审核提示了一个工程范式——对写操作创建工单、改数据保留确认环节读操作可以放行。❓ 本集两个常见问题一是这些服务器GitHub、Asana、Google Drive 等由谁编写答案是任何人都可以开发者自建、用官方参考服务器或社区采纳版本均可后续课程将亲手构建多个。二是 MCP 服务器是否就等于 API 调用可以说它是 API 的封装层或网关——不想直接调 API 时由 MCP 服务器代劳并用自然语言驱动但工具使用只是其功能的一部分服务器还会提供函数与模式schema下一集将深入主机、客户端、服务器概念及资源、工具、提示等底层组件。来源B站 · 吴恩达 MCP 课程第 2 集一句话总结《MCP 架构Host · Client · Server 三层解剖与一次工具调用的完整旅程》—— 本集14:53全课最长讲透 MCP 的三层架构Host 是掌控全局的 AI 应用Client 是 Host 内部与服务器 1 对 1 连接的通信管理员Server 对外提供工具、提示、资源客户端与服务器之间用 JSON-RPC 2.0 通信本地走 stdio、远程走 HTTPSSE。详细总结可视化已生成并发布在线链接MCP 架构Host · Client · Server 全解析第 3 集速览。小说明B 站该分集字幕未能直接抓取以下内容依据课程公开课件与 MCP 官方规范整理与本集「MCP架构」大纲一致。1️⃣ MCP 三层架构是什么Host、Client、Server 三种角色 Host主机 你的 AI 应用本体聊天机器人、Claude Desktop、IDE、代理。它负责编排一切决定连接哪些服务器、把哪些工具暴露给模型、权限如何审批——安全与控制的入口。 Client客户端 驻留在 Host 内部的「连接管理器」每个客户端只与一台服务器保持1 对 1 连接接了 3 台服务器就有 3 个客户端。这与第 1 集总览中「hosting 多个客户端」的架构呼应。⚙️ Server服务器 独立进程或远程服务暴露工具 / 提示 / 资源模型无关、可跨应用复用。一个直观类比Host 像浏览器Client 像浏览器里的每个标签页连接Server 就是 Web 服务器——浏览器掌控安全与沙箱连接各自独立 Kinda Technical。2️⃣ MCP 用什么协议通信JSON-RPC 2.0 与两种传输方式客户端与服务器之间统一使用JSON-RPC 2.0消息请求 / 响应 / 通知Model Context Protocol。传输层两种模式stdio本地Host 把服务器作为子进程拉起通过标准输入输出通信简单高效与HTTP SSE远程走 Web 连接服务器可主动推送消息。工程上注意两者连接生命周期不同本地切远程并非无缝替换传输层的差异是常见踩坑点。3️⃣ MCP 服务器三大原语Tools、Prompts、Resources 谁控制️ Tools工具· 模型控制LLM 自主决定何时调用可执行、有副作用如查 GitHub、写文件。 Prompts提示· 用户控制预置提示模板由用户主动选用标准化常见任务。 Resources资源· 应用控制文件、数据等上下文材料由应用决定附加给模型偏只读。这个「控制权三角」是 MCP 设计最精髓的区分直接决定权限模型与交互设计。4️⃣ 一次工具调用怎么走五步旅程拆解① 用户提问Host 汇总各服务器的工具清单 → ② 模型决策是否调用、调用哪个 → ③ 对应客户端经 JSON-RPC 转发请求 → ④ 服务器真正执行调 API / 读数据→ ⑤ 结果回传 Host模型据此生成最终回答。 AI 工程师视角的三点启示为方便快速对照下面用两张表格分别梳理三层角色与三大原语。角色职责控制权示例Host主机AI 应用本体负责编排一切决定连接哪些服务器、把哪些工具暴露给模型、权限如何审批安全与控制的入口掌控全局聊天机器人、Claude Desktop、IDE、代理Client客户端驻留在 Host 内部的「连接管理器」每个客户端与一台服务器保持 1 对 1 连接负责与服务器的通信转发不直接决定工具暴露Host 内与 GitHub 服务器、Asana 服务器分别连接的客户端Server服务器独立进程或远程服务对外暴露工具、提示、资源提供能力清单模型无关、可跨应用复用GitHub 服务器、Google Drive 服务器、arXiv 论文服务器再看三大原语的控制方与用途原语控制方用途典型场景Tools工具模型控制可执行、有副作用的操作由 LLM 自主决定何时调用查 GitHub Issue、写文件、创建 Asana 工单Prompts提示用户控制预置提示模板由用户主动选用标准化常见任务一键生成周报、按固定模板总结论文Resources资源应用控制文件、数据等上下文材料由应用决定附加给模型偏只读把本地文档、数据库查询结果作为上下文喂给模型权限收敛在 Host 层写操作务必加人工确认延续第 2 集演示的安全范式工具清单随连接数增长会挤占上下文窗口需管理暴露数量理解「原语 控制权」能帮你快速判断一个功能该做成 Tool、Prompt 还是 Resource。来源B站 · 吴恩达 MCP 课程第 3 集一句话总结《问答机器人示例模型点菜、代码炒菜的工具调用循环》—— 本集先用纯 API尚未 MCP 化搭建一个能查 arXiv 论文的聊天机器人定义 search_papers搜论文与 extract_info提取论文信息两个工具模型只负责「决定调用哪个工具 给什么参数」由应用代码执行后回传结果循环往复直到生成最终回答。详细总结可视化已生成并发布在线链接问答机器人示例模型 × 工具协作循环第 4 集速览。1️⃣ 本集任务怎么搭一个「会用工具」的机器人本集进入代码实战部分的第一课。Elie 用 Anthropic 的 Claude API 构建一个命令行聊天机器人让它能完成超出模型自身知识范围的任务搜索 arXiv 上的学术论文并提取信息。项目由一个聊天循环 两个工具组成search_papers按关键词搜论文返回论文列表与 ID和extract_info按 ID 提取标题、作者、摘要等详情。工具的核心价值是扩展模型能力、避免幻觉。2️⃣ 工具使用循环本集的核心机制这是理解后面所有 MCP 课程的关键模式模型收到用户提问后并不直接执行任何函数而是返回一个特殊结构tool_use 块指明「我要用哪个工具 参数是什么」你的应用代码监测到该结构后真正执行函数把结果附加到消息历史中再发给模型模型基于结果生成回答若还需要更多信息就继续发起工具调用如此往复直到模型给出纯文本回复。整个过程就是一个 while 循环输入 quit 退出。 BibiGPT 课程摘要3️⃣ 三个关键要点工具定义三要素每个工具需要清晰的名称、描述和参数模式模型才能正确理解和调用——描述写得越准模型调用越可靠。「模型点菜、代码炒菜」模型与工具的交互是编排式的——模型只输出调用意图执行权在应用代码手里这也是所有安全审核如第 2 集人工确认能存在的根本原因。无持久记忆当前机器人每次对话相互独立上一轮查到的论文 ID 想在下一轮使用需要手动传递。4️⃣ 本集定位MCP 化之前的基线这版机器人把工具直接「焊」在应用里换个应用就得重写、无法复用——正是 MCP 要解决的问题。第 5 集「创建MCP服务器」08:57将把同样的论文工具搬进 MCP 服务器工具定义不再属于某一个应用而是任何 MCP 兼容应用都能调用的公共能力。来源B站 · 吴恩达 MCP 课程第 4 集一句话总结《创建 MCP 服务器把论文工具搬进公共能力层》—— 本集08:57把第 4 集「焊」在应用里的 search_papers 与 extract_info 两个工具迁移进一个独立的 MCP 服务器工具定义不再属于某一个应用而是任何 MCP 兼容应用都能调用的公共能力并用 Claude Desktop 现场验证调用。详细总结本集是「动手建」阶段的关键一步承接第 4 集的基线机器人演示如何把工具从应用内部抽离成标准化的 MCP 服务器。1️⃣ 本集任务把工具从应用里「搬」出来第 4 集的机器人把 search_papers 和 extract_info 直接写在应用代码里换个应用就得重写。本集的目标是把这两个工具封装进一个独立的 MCP 服务器进程让任何 MCP 兼容应用Claude Desktop、IDE、代理等都能直接调用实现「构建一次、处处使用」。2️⃣ 服务器骨架FastMCP 快速搭建课程使用 Python 的 FastMCP 框架搭建服务器核心代码非常简洁创建一个 MCP 服务器实例用装饰器把普通函数注册为工具最后启动服务器。工具函数本身与第 4 集几乎一致调用 arXiv API 搜索论文、按 ID 提取信息区别在于它们现在暴露在 MCP 协议层而非某个应用内部。3️⃣ 关键转变工具定义与调用方解耦这是本集最核心的认知升级工具不再属于应用而是属于服务器。应用侧只需通过 MCP 客户端连接服务器、获取工具清单就能像调用本地函数一样使用远程工具。模型看到的工具描述、参数模式都由服务器统一提供调用方无需关心实现细节。4️⃣ 验证方式Claude Desktop 直连调用课程最后把服务器接入 Claude Desktop用自然语言直接提问「帮我搜一下最近关于 MCP 的论文」模型自动触发 search_papers 工具、拿到结果后再调用 extract_info 提取详情完整复现了第 4 集的工具使用循环——但这次工具来自外部服务器而非应用内嵌代码。5️⃣ 本集定位从「焊死」到「可复用」下面给出一个完整的 FastMCP 服务器示例把第 4 集的 search_papers 与 extract_info 两个工具封装进独立服务器任何 MCP 兼容应用都能直接调用。from mcp.server.fastmcp import FastMCP import urllib.request import urllib.parse import json 1. 创建 MCP 服务器实例name 会作为服务器标识暴露给客户端 mcp FastMCP(arxiv-server) 2. 用 mcp.tool() 装饰器把普通函数注册为 MCP 工具 函数名、docstring 与类型注解会自动生成工具描述与参数模式 mcp.tool() def search_papers(query: str, max_results: int 5) - list[dict]: 按关键词搜索 arXiv 论文返回论文列表与 ID。 Args: query: 搜索关键词如 MCP 或 model context protocol max_results: 最多返回的论文条数默认 5 # 调用 arXiv API把关键词拼进查询 URL base http://export.arxiv.org/api/query? params urllib.parse.urlencode({ search_query: fall:{query}, max_results: max_results }) with urllib.request.urlopen(base params) as resp: data resp.read().decode(utf-8) 用简单字符串解析提取论文 ID 与标题生产环境建议用 feedparser papers [] for entry in data.split(lt;entrygt;)[1:]: paper_id entry.split(lt;idgt;)[1].split(lt;/idgt;)[0].strip() title entry.split(lt;titlegt;)[1].split(lt;/titlegt;)[0].strip() papers.append({id: paper_id, title: title}) return papers 3. 第二个工具按论文 ID 提取标题、作者、摘要等详情 mcp.tool() def extract_info(paper_id: str) - dict: 按 arXiv 论文 ID 提取标题、作者与摘要详情。 Args: paper_id: 论文 ID例如 2401.12345 拼接单篇论文的 API 地址 url fhttp://export.arxiv.org/api/query?id_list{paper_id} with urllib.request.urlopen(url) as resp: data resp.read().decode(utf-8) 解析标题、作者与摘要 title data.split(lt;titlegt;)[1].split(lt;/titlegt;)[0].strip() authors [a.split(lt;namegt;)[1].split(lt;/namegt;)[0].strip() for a in data.split(lt;authorgt;)[1:]] summary data.split(lt;summarygt;)[1].split(lt;/summarygt;)[0].strip() return {id: paper_id, title: title, authors: authors, summary: summary} 4. 启动服务器默认走 stdio 传输供本地 Host如 Claude Desktop拉起 if name main: mcp.run()运行前先安装依赖pip install mcp。启动后Claude Desktop 等 Host 即可通过 MCP 客户端连接本服务器用自然语言触发 search_papers 与 extract_info实现「构建一次、处处使用」。对比第 4 集本集完成了从「应用内嵌工具」到「独立 MCP 服务器」的跃迁同样的工具第 4 集只能给一个应用用第 5 集能被所有 MCP 兼容应用共享。这正是 MCP 的核心价值——工具与数据源的一次构建、处处复用。下一集「创建MCP客户端」将站在应用侧演示如何连接并使用这类服务器。来源B站 · 吴恩达 MCP 课程第 5 集第 5 集MCP 生态对比MCP 与 REST、LSP、Function Calling为帮助读者快速建立坐标系下面用两张表格分别对比 MCP 与 REST、LSP 的定位差异以及 MCP 与 Function Calling 的能力边界。协议定位标准化对象典型应用场景MCP标准化 AI 应用与工具、数据源的连接方式让模型按统一协议获取上下文LLM 应用与外部工具 / 数据源之间的交互工具、提示、资源三类原语Claude Desktop 连接 GitHub、Google Drive、arXiv 论文服务器跨应用复用同一套工具REST标准化 Web 应用与后端系统的通信方式定义资源与无状态约束HTTP 接口的资源表示与操作GET / POST / PUT / DELETE浏览器 / 移动端调用后端 API、微服务之间的数据交换LSP标准化 IDE 与语言工具的交互避免为每种语言重复开发编辑器扩展编辑器与语言服务器之间的诊断、补全、跳转等能力协议VS Code 等 IDE 接入 Python、TypeScript 等语言的智能提示与错误检查再看 MCP 与 Function Calling 的差异维度MCPFunction Calling本质开放协议标准化 AI 应用与工具 / 数据源的连接模型无关、可跨应用复用模型 API 的一种能力让 LLM 输出调用某个函数的意图与参数作用范围覆盖工具、提示、资源三类原语并定义传输层stdio / HTTPSSE与服务器生命周期仅覆盖「模型决定调用哪个工具 给什么参数」这一环执行仍由应用代码完成复用性工具定义属于服务器任何 MCP 兼容应用都能调用构建一次、处处使用工具定义通常写死在某个应用里换个应用就得重写典型关系可以理解为 Function Calling 的「协议化 服务化」升级把工具调用从应用内嵌提升为公共能力层是 MCP 化之前的基线骨架第 4 集问答机器人即用此方式实现