圍繞著 MCP 這波討論，我真正留下了什麼

最早撞上 MCP 問題的那個下午

去年底，我接到一個需求：把內部幾個 AI 工具鏈的上下文共享起來。當時選型清單裡有 MCP、OpenAI Functions、還有手寫 WebSocket。我選了 MCP，核心原因是它宣稱「標準化情境傳輸」——聽起來像是對所有工具說同一種語言。

第一次整合是在一個從 Claude 到本地資料庫的查詢連結。我按照文件配置了一個 filesystem server，打算讓 AI 直接讀寫本機 JSON 檔案。結果跑起來之後，Claude 能正確列出目錄，但一旦涉及嵌套路徑或檔案名稱包含中文，傳回的 JSON 就會出現編碼錯誤。這不是大問題，但讓我意識到 MCP 的「標準」其實是建立在底層協定的一個假設上：IO 通道必須是位元組安全的、無狀態的。中文路徑、空間路徑、符號連結－這些實際環境中常見的元素，在 MCP 的早期實作裡幾乎沒有測試。

做完之後真正改變我判斷方式的幾個結論

MCP 不是萬用膠水

許多介紹把 MCP 描述成「AI 的萬能上下文傳輸層」。但實際上，它的設計哲學更接近「輕量 IPC + 有限狀態校驗」。它不保證資料傳輸的語意完整性－例如你傳一個長上下文過去，MCP 只保證它被完整地從一個端點送到另一個端點，不關心接收方怎麼解析。這意味著如果兩端的資料模型不一致，MCP 傳輸成功，但應用層失敗。在我那個檔案查詢場景裡，MCP 成功傳回了位元組流，但 Claude 的 JSON parser 遇到了非法字元。錯不在 MCP，而在我假設它「智能到能自動轉碼」。

效能瓶頸往往在對方端

我做了一個簡單測試：把一個大檔案（2MB）通過 MCP 從檔案系統傳給 Claude。傳輸耗時不到 50ms，但 Claude 處理這個檔案內容花了接近 4 秒。這讓我重新理解了 MCP 的「效能優化」應該要關注什麼。如果你在建立一個即時互動的 Agent，MCP 本身不是瓶頸，真正慢的是模型推理和工具端的資料處理。因此，最佳化點應該放在減少無效傳輸、提前在工具端做資料精簡，而不是給 MCP 加上快取或壓縮。

標準化是雙面刃

MCP 的標準化在單一廠商的場景下很爽——所有工具都以同一套規範實現。但一旦跨團隊、跨技術棧，標準化反而引入摩擦。例如我們的另一個團隊用 Python 實作了一個資料處理 server，他們依照 MCP 規格把輸出格式定義為 text，但前端 Claude 期望的是 json。這種 mismatch 花了兩天排查，最後發現規格裡 content_type 只是一個可選屬性，沒有強制校驗。所以如果你把 MCP 當作協定規範來用，一定要在團隊內部約定更嚴格的子集。

筆記本畫面上顯示 MCP 遷移 checklist，包含千層餅測試步驟和失敗場景清單。

當時踩過的坑和後來怎麼修正

**坑 1：過度信任預設配置。 ** 第一次設定 MCP server，我直接用了官方範例裡的 stdio 傳輸模式，以為這樣最通用。結果在 Windows 環境下，stdio 的換行符處理不同，導致 server 端一直讀到空行，程式掛起。修正方案是：在初始化腳本裡強制指定為行分隔符，並且在文件中註明跨平台注意事項。

**坑 2：以為 MCP 會幫我管理連線狀態。 ** 剛開始寫 Agent 循環時，我在每個工具呼叫前都會重新建立一次 MCP 連線。這樣做了幾天，發現系統頻繁出現「connection refused」。原來 MCP server 在短時間內接收太多連線請求會進入拒絕狀態。修正方法是：複用單一長連接，用請求 ID 來做多路復用。這其實回到了最基本的網路程式常識，但 MCP 的抽象層太簡潔，容易讓人忘記底層還是 TCP socket。

**坑 3：忽略傳輸體的冪等性。 ** 有一次我們想實現“AI 重複執行某個工具直到成功”，結果因為 MCP 傳輸本身不是冪等的，同一個請求發了兩次，工具端執行了兩次寫操作，數據重複了。修正方案：在應用層實作請求去重，或強制工具端做冪等設計。這件事讓我意識到，MCP 的「可靠傳輸」不等於「業務冪等」。

桌上攤開的兩份對比筆記：左邊是 MCP 整合方案優缺點，右邊是 WebSocket 替代方案的比較。

如果你也在做類似工作，最值得先抄寫的一步

在把 MCP 接入任何核心連結之前，先寫一個千層餅測試（layered test）：

第一層：單獨測試 MCP 傳輸通道（例如在終端機啟動 server，用 nc 或 telnet 發一個簡單請求，看回傳值）。這一步確認網路和進程通訊沒問題。
第二層：用固定的 payload 在兩端測試資料格式。例如發一個已知的 JSON 物件過去，看回傳值是否與預期一致。這一步排查序列化/反序列化錯誤。
第三層：模擬你的真實業務場景，但用最簡單的工具端實作（例如寫一個只回傳當前時間的函數）。這一步驟排除業務邏輯幹擾，確認 MCP 存取後的延遲和穩定性。

我當時跳過了前兩層，直接寫了完整業務邏輯，結果出了問題很難定位。如果你能把這個「千層餅測試」當作所有 MCP 整合的起點，至少可以省下一半的調試時間。

什麼時候該繼續投入，什麼時候該換路線

繼續投入 MCP 的場景：

你的工具鏈主要運行在單一技術堆疊內（例如全是 JavaScript，或全是 Python）。
你只需要發送短上下文（<100KB），對傳輸延遲要求不極端。
你能忍受一些邊緣 case（如編碼、分隔符號、跨平台行為差異）並願意修。

換路線的號誌：

你需要在不同程式語言、不同作業系統之間頻繁地傳輸大量或結構化上下文。這時 MCP 的序列化開銷和相容性問題會放大，不如用 gRPC 或 WebSocket + Protobuf。
你的 Agent 需要處理串流、部分失敗復原。 MCP 目前對流式的支援還很初步，不如直接用 SSE。
你的團隊已經深度使用了另一個情境管理方案，例如 LangChain 的 SharedMemory 或 OpenAI Assistants。遷移到 MCP 的成本可能大於效益。

對我來說，最終在三個專案中保留了 MCP，在兩個專案中換成了 WebSocket + 自訂協定。這個決策不是技術優劣比較，而是團隊熟悉度和維修代價的權衡。

下一步

如果你覺得自己在 MCP 上的踩坑經歷跟我類似，或者正在考慮從傳統後端轉向 Agent 工程，那麼「MCP 整合實戰」只是整個轉變中的一小塊。真正重要的是如何設計 agent loop、如何處理上下文失效、如何做工具編排。這些我花了很多時間在文檔調試和失敗複盤裡摸索。如果你想跳過這些坑，建議直接進入更有系統的學習路徑——我後續會把這篇經驗對應的完整實戰錄成付費課程，裡麵包含可運行的程式碼範例和 checklist。