# 客戶端到底管什麼？搞錯這一層，伺服器寫再好也白搭 很多人學 MCP，第一件事就衝去寫伺服器，結果伺服器寫好了，卻不知道誰來叫它、怎麼叫它。這就好比電話線… · @swordBluesy · TwKit

@swordBluesy

# 客戶端到底管什麼？搞錯這一層，伺服器寫再好也白搭 很多人學 MCP，第一件事就衝去寫伺服器，結果伺服器寫好了，卻不知道誰來叫它、怎麼叫它。這就好比電話線兩頭只裝了一頭，另一頭沒人接，線再好也打不通。客戶端就是那個負責接電話、問清楚、再把話傳回去的角色，搞錯這一層，後面全是白工。 ## 客戶端是通信橋樑，不是模型本身 MCP 客戶端是你的伺服器與 MCP 伺服器之間的通信橋樑，也是你的伺服器訪問 MCP 伺服器全部工具的入口。它負責處理消息交換與協議細節，讓你的應用程式不用自己操心這些。模型本身不直接跟伺服器講話，問話、拿工具、執行、回結果，都要經過客戶端這一層。 ## 傳輸方式可以換，這叫傳輸無關 MCP 的一個關鍵優點是傳輸無關：客戶端與伺服器可以按你的部署方式，用不同的協議通信。最常見的部署是客戶端與伺服器在同一台機器上，走標準輸入輸出；除此之外，也可以走 HTTP、WebSocket 等網路協議。底下走什麼，上層的消息格式不變。 ## 客戶端真正打交道的兩種消息 連上之後，客戶端與伺服器交換的消息類型由 MCP 規範定義，其中最常用的兩種是：ListToolsRequest／ListToolsResult，客戶端問伺服器「你提供什麼工具」，伺服器回工具清單；CallToolRequest／CallToolResult，客戶端請伺服器跑某個工具並帶上參數，伺服器回執行結果。 ## 一次問答走完全程是什麼樣子 使用者問：「我有哪些倉庫？」整個流程是這樣走的：使用者把問題交給你的伺服器；伺服器需要知道有什麼工具可用，於是請客戶端列工具；客戶端向伺服器發 ListToolsRequest，收到 ListToolsResult；伺服器把使用者問題加上工具清單發給 Claude；Claude 決定要呼叫工具；伺服器請客戶端執行；客戶端發 CallToolRequest，伺服器去調 GitHub API；結果經 CallToolResult 一路回流；伺服器把工具結果發給 Claude；Claude 組織成最終回答；使用者收到回答。 步驟看起來很多，但每個部件的責任都很清楚。客戶端把伺服器通信的複雜性抽象掉了，你才能專心寫應用邏輯，同時還能用上強大的外部工具與資料來源。 ## S1哥觀點 客戶端最容易被低估，就是因為它看起來只是在傳話。但傳話傳得對不對，決定了整個系統能不能跑：工具清單拿不到，Claude 就不知道手上有什麼牌；執行請求送不出去，伺服器上的工具就等於不存在。把客戶端寫成只是轉發請求的空殼，錯一來就全往模型身上推，最後除錯除到懷疑人生。 爭論點就在這裡：很多人覺得客戶端沒什麼好學，重點都在伺服器。但真相是，伺服器寫得再漂亮，沒有一個會列工具、會送執行請求、會把結果原樣帶回的客戶端，那台伺服器就等於不存在。先把客戶端這一層想清楚，再去寫伺服器，這個順序不能倒。 原文連結：https://anthropic.skilljar.com/introduction-to-model-context-protocol/296690 原文：Anthropic Academy（由 S1哥 編譯）

曝光 62 · 评论 1 · 点赞 1 · 书签 0