--- title: 'MCP 协议解读与意义' video_id: 7j_NE6Pjv-E url: https://youtu.be/7j_NE6Pjv-E title_en: "Model Context Protocol (MCP), clearly explained (why it matters)" channel: Greg Isenberg published: 2025-03-14 duration: "20:18" topics: [MCP 与工具调用] noted: 2026-07-05 value: S views: '131.5万' --- [![封面](https://i.ytimg.com/vi/7j_NE6Pjv-E/maxresdefault.jpg)](https://youtu.be/7j_NE6Pjv-E) > Greg Isenberg · 20:18 · 发布 2025-03-14 · 131.5万次观看(截至抓取) · [观看原视频](https://youtu.be/7j_NE6Pjv-E) > 🔥 观众最高回放 [07:30](https://youtu.be/7j_NE6Pjv-E?t=450) — 用语言翻译层比喻解释 MCP 协议的作用 ## 主旨 由 Professor Ross Mike 用大白话讲清 MCP(Model Context Protocol)到底是什么:它不是黑科技,只是给"LLM 接外部工具"这件事定的一个统一标准——把各服务五花八门的接口翻译成 LLM 能听懂的同一种语言,让 AI 从"只会预测下一个词"进化到"能真正做事"。 ## 核心论点 1. **LLM 单独一无是处**——它本质只会预测下一个词,任何"做事"能力都来自外接工具。([[#2-llm-单独一无是处只会预测下一个词-0244|→ 详解2]]) 2. **给 LLM 粘工具能用,但堆叠多工具是工程噩梦**——逐个接能跑,一旦要多工具协同、还得扛第三方 API 变更,就崩;这才是至今没有 Jarvis 的原因。([[#3-第二次进化llm--工具以及粘合地狱-0352|→ 详解3]]) 3. **MCP 本质是一层"翻译层 / 统一语言"**——把各服务异构的接口统一成 LLM 通用的接入方式。([[#4-mcp-是什么一层翻译层--统一语言-0741|→ 详解4]]) 4. **MCP 生态是四件套:client / protocol / server / service**——各司其职地把外部能力送到 LLM 面前。([[#5-mcp-生态四件套client--protocol--server--service-1116|→ 详解5]]) 5. **Anthropic 的高招是把"造 server"甩给服务商**,自己只定标准,于是全行业自发抢建 server。([[#6-anthropic-的3d-象棋把造-server-甩给服务商-1203|→ 详解6]]) 6. **技术上 MCP 只是个标准**——类比 REST / HTTP / SMTP,没有奇迹;但历史上标准一旦跑通,上面都长出大生意。([[#7-现实的坑与为什么是现在-1350|→ 详解7]]) 7. **现在仍太早、标准未定**——非技术者该做的是观望学习,等标准落定再出手。([[#8-对-builder-的启示观望-vs-出手-1650|→ 详解8]]) ## 知识点详解 ### 1. 先理解"标准":工程世界的通用语 [01:58](https://youtu.be/7j_NE6Pjv-E?t=118) 程序员最爱标准,因为标准让互相独立的系统能对话。最出名的例子是 REST API——几乎每家公司构建接口时都遵循它,工程师才能彼此连接。 理解这点是理解 MCP 的前提:MCP 之所以重要,不是因为它多聪明,而是因为它是又一个让大家"说同一种话"的约定。 ### 2. LLM 单独一无是处,只会预测下一个词 [02:44](https://youtu.be/7j_NE6Pjv-E?t=164) 早期的 ChatGPT,你让它发封邮件,它只会回"我做不到"。LLM 单独能做的最多就是回答问题、讲讲历史人物,做不了任何"有意义"的实际动作。 它的本质是预测下一段文本:你说"My Big Fat Greek",它凭训练数据判断下一个词是"wedding"[03:30](https://youtu.be/7j_NE6Pjv-E?t=210)。仅此而已——嘉宾直言,LLM 本身"其实很笨"。 ### 3. 第二次进化:LLM + 工具,以及粘合地狱 [03:52](https://youtu.be/7j_NE6Pjv-E?t=232) 开发者随后学会给 LLM 接工具:工具可以理解成一个 API。Perplexity 就是例子——LLM 本身不能上网,但外接了搜索工具后就能抓取信息呈现给你。接上 Zapier / n8n 这类自动化,LLM 就"有点用"了。 问题在堆叠。想造一个既搜网、又读邮件、又做总结的助手,你就沦为"到处粘工具的人"——非常繁琐易碎。[05:40](https://youtu.be/7j_NE6Pjv-E?t=340) 让单个工具跑起来是一回事,把多个工具叠在一起、让它们协同不打架是另一场噩梦。这正是为什么"钢铁侠级 Jarvis 助手"感觉近在咫尺却始终没出现。 ### 4. MCP 是什么:一层翻译层 / 统一语言 [07:41](https://youtu.be/7j_NE6Pjv-E?t=461) 把每个要接的工具想成一门不同的语言:工具一说英语、工具二说西班牙语、工具三说日语。不是没有 API 标准,而是每家服务商实现方式都不同,要传的参数、要配的东西各异,本质仍是"东拼西凑"。[08:10](https://youtu.be/7j_NE6Pjv-E?t=490) [[MCP]] 就是夹在 LLM 与各服务/工具之间的一层,它把这些不同的"语言"翻译成 LLM 完全听得懂的统一语言。[08:43](https://youtu.be/7j_NE6Pjv-E?t=523) 它是"LLM + 工具"的进化版:第二阶段有大量手工步骤、逐步规划和易失败的边界情况,MCP 则让 LLM 连接外部数据源、数据库(如 Convex、Supabase)变得简单——一句"帮我在数据库里建条记录",它就通过 MCP 知道怎么做。 ### 5. MCP 生态四件套:client / protocol / server / service [11:16](https://youtu.be/7j_NE6Pjv-E?t=676) 生态由四部分组成:client、protocol、server、service。 **client** 是面向 LLM 的一端,比如 Tempo、Windsurf、Cursor;**protocol** 是 client 与 server 之间的双向连接;**server** 负责把某个外部 service 的能力翻译给 client。client 与 server 之间跑的就是 MCP protocol。 ### 6. Anthropic 的"3D 象棋":把造 server 甩给服务商 [12:03](https://youtu.be/7j_NE6Pjv-E?t=723) 嘉宾认为最精妙的一步在架构:MCP server 由服务提供方自己来建。假如你和 Greg 开了家数据库公司、想让别人的 LLM 能用你的库,那么建 server 就是你的活。 于是 Anthropic 相当于说:我想让 LLM 更强,但接入的活你们自己搞定——这就是为什么各家外部服务商都在抢着建自己的 MCP server 和 repo。从技术看,他们做的只是"造了一个标准",而这个标准看起来所有公司和工程师都会遵从。[12:54](https://youtu.be/7j_NE6Pjv-E?t=774) 原因很朴素:你可以随心所欲地设计系统,但只要想规模化、想让别的开发者和企业来对接,接口就必须以对他们有意义的方式呈现——标准让大家能互相沟通。 ### 7. 现实的坑,与"为什么是现在" [13:50](https://youtu.be/7j_NE6Pjv-E?t=830) 不全是阳光彩虹。真在 MCP client 上配过 server 的人都知道很烦:一堆下载、挪文件、复制粘贴,大量本地操作,还有不少毛刺待磨平。 但一旦这些被打磨定型(或有人拿出更好的标准),我们就进入"LLM 越来越能干"的世界——而这恰恰就是 MCP 的全部意义:让 LLM 更有能力,如此而已。[14:22](https://youtu.be/7j_NE6Pjv-E?t=862) Greg 追问"为什么是现在":历史上每次协议被普及(如 HTTPS、SMTP),上面都会长出一批大公司,像是打开了机会之门。[16:06](https://youtu.be/7j_NE6Pjv-E?t=966)嘉宾也提醒,值得注意的是好工程师在 LLM 时代依然吃香——正因为对接、维护第三方 API 变更这类脏活难活始终存在。 ### 8. 对 builder 的启示:观望 vs 出手 [16:50](https://youtu.be/7j_NE6Pjv-E?t=1010) 技术侧,嘉宾抛出一个免费点子:做个"MCP App Store"——现在到处是 MCP server 的 repo,若能有个站点让人浏览这些 server、看 GitHub 代码,点一下 install/deploy 就部署好、给一个 URL,再粘到 MCP client 里用,会很酷。[17:14](https://youtu.be/7j_NE6Pjv-E?t=1034)(他说自己连域名都买了,idea 白送) 非技术侧,他的建议是"按兵不动、贴身观察":现在太早,MCP 未必最终胜出,可能被挑战、可能 Anthropic 改标准、也可能明天 OpenAI 出个标准大家又全迁过去。该做的是紧盯最终标准往哪走,等标准定型、服务商纷纷建好 server,那时再上车整合会顺畅得多。[17:55](https://youtu.be/7j_NE6Pjv-E?t=1075)理解了它怎么运作,你就理解了"下一个东西"怎么运作,标准一落定就能抢跑。 ## 可执行步骤 - [ ] 用"翻译层 / 四件套(client-protocol-server-service)"这套心智模型,向自己复述一遍手边某个 AI 产品(Cursor / Claude 等)是如何接外部数据的。 - [ ] 挑一个你真在用的服务(如 Supabase、GitHub、Slack),查它是否已有官方 MCP server,在一个 MCP client 里实际配一次,亲身感受"配置很烦"的痛点。 - [ ] 建立观察清单:定期看主流平台(client 侧)在如何扩展 MCP 能力,判断标准是否趋于稳定,再决定要不要投入做集成。 ## 关联 - 印证:[[Harness]] 把"工具 / MCP"明确列为 harness 的构成要素之一(你唯一能优化的可控层)。本片正好把这一要素单独讲透——MCP 是什么、为何出现、生态如何组织。 - 印证:[[Harness]] 的核心论点是"价值在模型外围的工程层,而非模型本身";本片"LLM 单独很笨、能力全靠外接工具,好工程师因对接脏活难活依然吃香"是同一判断在工具接入维度的具体化。 ## 术语 - MCP(Model Context Protocol)——LLM 与外部工具/服务之间的统一接入标准。 - REST API——各公司构建服务接口普遍遵循的既有标准,MCP 的类比参照物。 - Tool / 工具——给 LLM 外接的外部服务(搜索、数据库、自动化等),可理解为一个 API。 - MCP Client / Server / Protocol——面向 LLM 的一端 / 服务商构建的翻译端 / 两端之间的连接协议。 - Jarvis——《钢铁侠》里无所不能的 AI 助手,此处喻理想的多工具智能助手。 - Tempo / Windsurf / Cursor——视频点名的 MCP client(AI 编程/助手产品);嘉宾任职于 Tempo。 - Manus——靠大量工具堆叠、工程化实现的通用 agent 产品,视频举为"第二阶段(LLM+工具)"的范例。 ## 金句 > "llms by themselves are incapable of doing anything meaningful." → 一句话点破 LLM 的天花板:再炫的模型,不接工具就只是个复读机。 > "all they did was create a standard." → MCP 的价值不在技术奇迹,而在"约定"本身——让所有人说同一种话。 > "even in the age of llms good Engineers will still get paid." → AI 越强,把混乱的真实世界接口捏合起来的脏活越值钱。 ## 立场与利益 Greg Isenberg 是创业/AI 方向的内容博主,视频中段插播了自家私享社群 Startup Empire(startupempire.co)。嘉宾 Professor Ross Mike 就职于 AI 创业公司 Tempo,而 Tempo 正是他点名的 MCP client 之一——讲 MCP 生态对其存在利益相关,需留意。 属技术共识的部分:MCP 是一个标准、LLM 单独能力弱、多工具集成困难。属个人立场/判断的部分:MCP "尚早、未必最终胜出、可能被 OpenAI 标准取代"是嘉宾的预测;"当前没有明确创业机会、先观望"也是其立场而非定论;"MCP App Store"是他随口抛出的点子。(补记:本片录于 2025-03 MCP 刚爆火时;其"未必胜出"的疑虑是彼时的谨慎表态。) ## 价值定位 - 适合谁:想理解 agent 如何接外部工具/数据、却被技术黑话劝退的 AI builder 与非技术创业者。 - 解决什么:用"翻译层 / 统一语言 / 四件套"把 MCP 讲成大白话,帮你建立准确、够用的心智模型,不再人云亦云。 - 认知 vs 实操:几乎纯认知与格局背景——嘉宾明确说当下没有可落地的商业动作,别指望拿到操作清单。 - 与 [[Harness]] 重叠:harness 概念页把 MCP 列为构成要素之一,本片独有的是把这一要素的机制与由来(为何是标准、生态怎么分工)讲透。 ## 自检问题 1. 为什么说"LLM 单独一无是处"?它单独能做的极限是什么? **答案**:因为它本质只是预测下一段文本,做不了发邮件、查数据库等实际动作;单独能做的极限就是回答问题/续写文本(如 "My Big Fat Greek"→"wedding")。见详解2。[03:30](https://youtu.be/7j_NE6Pjv-E?t=210) 2. 用一句话说清 MCP 到底是什么?它和"LLM + 工具"是什么关系? **答案**:MCP 是夹在 LLM 与各服务之间的一层,把异构接口翻译成 LLM 通用的统一语言;它是"LLM + 工具"的进化版,让接入不再靠手工粘合。见详解4。[08:43](https://youtu.be/7j_NE6Pjv-E?t=523) 3. MCP 生态的四个组成部分是什么?server 由谁来建,这一设计的精妙之处在哪? **答案**:client、protocol、server、service;server 由服务提供方自己建,Anthropic 只定标准,于是把接入的活推给全行业,各家自发抢建 server。见详解5、6。[12:03](https://youtu.be/7j_NE6Pjv-E?t=723) 4. 对非技术创业者,嘉宾给的建议是什么?为什么现在不建议贸然出手? **答案**:观望学习、紧盯最终标准往哪走,等标准定型再整合;因为现在太早,MCP 未必胜出,可能被改、被 OpenAI 标准取代,贸然投入风险高。见详解8。[17:55](https://youtu.be/7j_NE6Pjv-E?t=1075) 5. 为什么"标准"值得如此重视?视频用了哪些类比? **答案**:标准让互相独立的系统/公司能"说同一种话"、互通规模化;类比 REST API、以及历史上普及后长出大量大公司的 HTTPS、SMTP。见详解1、7。[16:06](https://youtu.be/7j_NE6Pjv-E?t=966) > [!quote] 💬 热门评论 top-10 主 + 10 回(抓取 2026-07-07) > > [1] **@konkan-m6p**:从基础LLM到工具连接系统的演变说明了为什么MCP是必要的。我有时依赖nocodeapi来处理多个应用连接，这个协议似乎是下一个合乎逻辑的步骤。 👍 27 > [3] **@PranshuKumar-m6s**:将MCP理解为AI模型的通用翻译器很巧妙。我一直在探索NoCodeAPI进行各种集成，这个概念与我想实现的目标很契合。 👍 24 > [4] **@ANKU03-0**:MCP简化LLM和工具之间的通信是颠覆性的。我最近一直在用nocodeapi连接API，它让这些概念更容易理解。谢谢你的见解！ 👍 201 > [5] **@RohanRathor295**:MCP标准化LLM的工具连接方式令人大开眼界。这类似于我用nocode api连接API的方式，让复杂任务更易管理。 👍 32 > [7] **@Yadav.Bhaibrand**:理解MCP如何简化多个工具与LLM的集成对开发者来说是颠覆性的。我用nokoadeapi设置了一些连接，节省了时间和精力。 👍 36 > [10] **@galporgy**:MCP = LLM的ODBC 👍 28 > ——其他 4 条:感谢/夸赞([2]@GregIsenberg、[6]@lucface、[8]@sunilbudke、[9]@astrofolia4515) >
英文原文[1] @konkan-m6p:The evolution from basic LLMs to tool-connected systems shows why MCPs are necessary. I sometimes rely on nocodeapi to handle multiple app connections, and this protocol seems like the next logical step. 👍 27
[2] @GregIsenberg(UP):GIVE IT UP FOR RAS MIC! LEGEND! 👍 242
  ↪ @TrainerBlakeA:Legend!! 👍 3
  ↪ @Chirag-Madhu:💯 👍 1
  ↪ @vincent7050:Great explanations indeed, thanks for this video.
  ↪ @RahulKahani_:I saw the mcp workflow visual notes and thought, “Oh Greg started doing note taking like Rasmic.” It was Rasmic’s notes.
  ↪ @SterlingSellsHomes:Yes sir!!!
[3] @PranshuKumar-m6s:Understanding MCPs as a universal translator for AI models is brilliant. I've been exploring NoCodeAPI for various integrations, and this concept fits well with what I'm trying to achieve. 👍 24
[4] @ANKU03-0:MCPs simplifying the communication between LLMs and tools is a game-changer. I've been using nocodeapi lately for connecting APIs, and it makes these concepts much more accessible. Thanks for the insights! 👍 201
[5] @RohanRathor295:The way MCPs standardize tool connections for LLMs is eye-opening. It's similar to how I connect APIs with nocode api, making complex tasks more manageable. 👍 32
[6] @lucface:i watched 20 MCP videos. Love that this dude just made it make sense. Please ASK HIM FOR A MORE DEEPER DIVE!! 👍 765
  ↪ @Satheeshkumar-dv1uu:Who's this guy Where is the channel. name? 👍 7
  ↪ @Jefferson-l5t:One of interesting cases of applying MCP is to connect voice ai like MiniMax or ElevenLabs to your call or your voice agent so it can automatically answer questions for you instead of just machine talking 👍 3
  ↪ @odedomer5628:You said it well :-) Ras Mic is great! 👍 1
  ↪ @svv1863:Yeah I agree 👍 1
  ↪ @noelthenurse1:700th reply!
[7] @Yadav.Bhaibrand:Understanding how MCPs streamline the integration of multiple tools with LLMs is a game-changer for developers. I manage to set up some connections using nokoadeapi, which saves time and effort. 👍 36
[8] @sunilbudke:He deserves to be called the "Professor." Great video. Thank you. 👍 67
[9] @astrofolia4515:Who is this guy!? I haven't listened to someone that has instantly hooked me like this with his engagement and charisma Great guest 👍 73
[10] @galporgy:MCP = ODBC for LLMs 👍 28