📌 抓包分析了MCP通信过程，直接惊呆了！ - YouTube

Original URL: https://youtu.be/IjISe8ThHvY

📌 抓包分析了MCP通信过程，直接惊呆了！ - YouTube

⓵ 【容易懂 Easy Know】：

想像一下，你想請AI幫你查「軒轅的編程宇宙」有多少粉絲。AI就像個記性不好、消息過時的小朋友，不知道最新的粉絲數。所以，我們需要一個像「小幫手」的程式，它會去「軒轅的編程宇宙」的主頁上數粉絲。但AI不能直接拜訪這個小幫手，因為小幫手住在家裡（你的電腦），AI住在遠方。這時，我們需要一個「中間人」程式，這個中間人會告訴AI：「嘿，我這有個小幫手可以數粉絲，你想用的話跟我說一聲！」然後，AI會告訴中間人它想用這個小幫手，並告訴它要怎麼用。中間人再去拜訪小幫手，拿到粉絲數，再告訴AI。這樣，AI就能回答你的問題啦！這就像請朋友幫你跑腿買東西一樣。

---
⓶ 【總結 Overall Summary】：

本影片深入探討了模型上下文協議（MCP）這一解決方案，旨在簡化大型語言模型（LLM）調用外部工具的流程。傳統上，LLM通過函數調用（Function Calling）技術，利用JSON格式描述外部工具的功能及使用方式，然而，這種方式需要為每個工具編寫繁瑣的描述文件，且存在安全風險。MCP通過引入“殼”的概念，將外部工具封裝成Server，中介程式則作為Client與這些Server進行交互，簡化了工具的描述和管理。

影片詳細介紹了MCP Client與MCP Server之間的兩種通信方式：標準輸入輸出流和HTTP協議下的SSE（Server-Sent Events）。前者適用於Server和Client位於同一台計算機的情況，後者則適用於分布式場景。通信協議基於JSON RPC 2.0。

然而，影片揭示了一個令人意外的細節：在MCP Client與AI大模型之間的通信中，並未使用函數調用技術，而是採用了最原始的方法，將所有外部工具的詳細信息（包括使用教學案例）直接塞入提示詞（prompt）中，總長度達6萬多字。這種做法的優點在於兼容性更強，理論上任何指令遵循能力良好的大模型都可以使用MCP技術，而無需依賴函數調用功能。影片最後強調，雖然MCP標準化了Client和Server之間的通信，但Client和AI大模型之間的通信方式則更加開放靈活。

---
⓷ 【觀點 Viewpoints】：

* **MCP簡化了LLM調用外部工具的流程：** 通過封裝外部工具，減少了對工具描述文件的需求，降低了開發和維護成本。
* **MCP提供了兩種Client-Server通信方式：** 標準輸入輸出流和HTTP SSE，適應不同的部署場景。
* **實際應用中，MCP Client與AI的通信方式並非預期的函數調用：** 而是採用了將工具信息直接塞入提示詞的策略，提高了兼容性，但可能犧牲了效率。
* **函數調用方式的繁瑣性催生了MCP方案。**
* **使用提示詞的方式虽然原始但更通用。**

---
⓸ 【摘要 Abstract】：

📌 MCP旨在簡化LLM調用外部工具的複雜性。
✅ MCP通過“殼”封裝外部工具成Server，Client負責交互。
⚠️ MCP Client與Server支持標準輸入輸出流和HTTP SSE兩種通信方式。
🔑 Client與Server之間的通信協議基於JSON RPC 2.0。
🤯 令人意外的是，Client並未使用函數調用與AI通信。
📝 Client將所有工具信息塞入提示詞，發送給AI。
🚀 這種方式兼容性強，但可能效率較低。
⚙️ MCP標準化了Client和Server之間的通信，但AI通信方式更靈活。

---
⓹ 【關鍵字 Key Words】：

* 模型上下文協議（MCP）
* 函數調用 (Function Calling)
* Client-Server
* 提示詞（Prompt）
* JSON RPC 2.0
* SSE（Server-Sent Events）
* 外部工具
* 封装
* ASTROPIC

✡ Oli小濃縮 Summary bot 為您濃縮重點 ✡

â–¶ https://youtu.be/IjISe8ThHvY