# 伺服器也能主動找客戶端說話？MCP 是雙向協議，單向理解全錯了 這是 Anthropic Academy《Model Context Protocol:… · @swordBluesy · TwKit

@swordBluesy

# 伺服器也能主動找客戶端說話？MCP 是雙向協議，單向理解全錯了 這是 Anthropic Academy《Model Context Protocol: Advanced Topics》第 9 課的實作教學，標題直譯是《JSON message types（JSON 消息類型）》。先把結論放在前面，因為它反常識： **MCP 不是客戶端問、伺服器答的單向協議——伺服器也能主動發起通信。這個雙向特性，在選傳輸方式時至關重要，有些傳輸會限制消息的流向。** 先說清詞。**JSON 消息（JSON message）**，是 MCP 通信的全部載體，客戶端與伺服器之間傳的每句話都是一條 JSON 消息。**請求-結果（request-result）**，是成對出現的消息：一個請求，一定對應一個結果。**通知（notification）**，是單向的消息，發出去就完事，不需要回覆。**傳輸（transport）**，是消息怎麼傳的管道，例如 STDIO、StreamableHTTP。 一個真實例子：Claude 要調伺服器的工具時，客戶端發一條 Call Tool Request，伺服器處理後回一條 Call Tool Result。一問一答，看起來像單向；但伺服器也可以反過來發請求、發通知，客戶端同樣要接、要回。 他們還點名了一種「眼熟的舊路線」：把 MCP 當成普通 API，以為只有客戶端能發請求、伺服器只能回覆。官方的拆台很直接：**消息類型按發送方分，客戶端消息與伺服器消息是兩套**，伺服器消息裡既有發給客戶端的請求，也有廣播通知。 先把話說全：不是所有消息都要回覆。滿足下面任何一條，就不需要回： - 它是通知，單向發出，規範就不要求回覆； - 它是廣播，發給所有人聽，不是點對點問答； - 它是狀態變化，例如工具清單變了、資源更新了，告訴你一聲就好。 ## 一、把消息理解成單向的三種翻車方式 - **伺服器請求沒人接**：以為伺服器不會主動發請求，客戶端根本沒寫接伺服器請求的程式碼。 - **通知等回覆等到超時**：通知本來不需要回覆，硬要等回覆，流程直接卡住。 - **選錯傳輸**：選了限制消息流向的傳輸，伺服器發起的請求發不出去，功能上線才壞。 ## 二、替代方案：兩大類、四個方向，先分清再寫程式 兩大類是這樣分的：請求-結果成對出現，Call Tool、List Prompts、Read Resource、Initialize 等請求各有對應結果；通知單向、無需回覆，Progress、Logging Message、Tool List Changed、Resource Updated 都屬這一類。按發送方分又是兩套：客戶端消息是發給伺服器的請求與通知；伺服器消息是發給客戶端的請求與廣播通知。寫程式前先分清這一條消息是哪一類、哪個方向，再決定要不要回、怎麼回。 ## 三、目標形態：消息類型表刻在腦子裡 理想狀態是開發者看到一條消息，立刻能說出它的類別與方向：是請求還是通知、是客戶端發的還是伺服器發的、需不需要回覆。完整消息類型清單在 MCP 官方規範倉庫，與各語言 SDK 倉庫分開，是權威來源；用 TypeScript 書寫只是為了清晰描述資料結構，不是真的跑 TypeScript。 ## 四、遷移三步走：從單向理解改成雙向理解 ### 第一步：先查規範倉庫的消息清單 不要只看 SDK 的範例，規範倉庫的清單才是全的，先對一遍你用到的消息都在哪一類。 ### 第二步：把伺服器消息的接法補上 客戶端除了發請求，還要能接伺服器發來的請求與通知，接法漏了，雙向就是假的。 ### 第三步：選傳輸前先問流向 選傳輸方式時先問一句：伺服器發起的消息在這條傳輸上走得通嗎？走不通，功能就要打折。 ## 五、團隊怎麼共建同一套消息理解 消息理解最大的坑不是技術，是兩邊理解不一致：伺服器以為通知要回，客戶端以為請求不用回。團隊要先約好三條：消息分類以規範倉庫為準，不要各憑感覺；通知一律不回，不要寫等回覆的程式碼；新消息類型上線前先標清類別與方向，標不清不上線。 ## 六、官方工具包之外還要記得的事 這課沒有給出完整工具箱，但它把邊界講得很清楚：理解消息類型，對使用不同傳輸尤其關鍵——後面 StreamableHTTP 的那些限制，根子全在消息流向這裡。消息類型沒分清，傳輸選型就是蒙的。 ## 結尾：原則比架構重要 協議不是管道，是對話。**原則比架構重要——先分清誰能說話、誰要回覆，再談傳輸怎麼搭，順序反了，搭出來的全是單向管道。** 可重複的動作規則是：下次處理一條 MCP 消息，先問三句——它是請求還是通知、是誰發的、要不要回——三句答得上，才動手寫程式碼。 原文連結：https://anthropic.skilljar.com/model-context-protocol-advanced-topics 原文：Anthropic Academy（由 S1哥 編譯） ## S1哥觀點 這課最狠的地方，是它把一堆人的「客戶端問、伺服器答」幻想一刀砍掉：過去大家把 MCP 當普通 API 用，現在官方說，伺服器也能主動找你說話。真正貴的從來不是多寫幾行接伺服器請求的程式碼，是你按單向理解搭了一整套，上線才發現伺服器發起的功能全壞了。 我站這一邊：協議要按雙向理解。一個只會接客戶端請求、不會接伺服器請求的客戶端，比一句「我不知道」更危險——前者讓你帶著「已經接通」的錯覺上線，後者至少讓你停下來。 所以問一句：你現在的客戶端裡，有幾處是根本沒寫接伺服器請求的程式碼的？評論區報個數，敢不敢說實話。

曝光 111 · 评论 2 · 点赞 0 · 书签 1