MCP 原型的詛咒：為何成功的 PoC 反而走向技術債的懸崖？

在建構基於多輪對話協定（Multi-turn Conversation Protocol, MCP）的系統時，許多團隊會優先追求快速驗證，打造出功能看起來很完整的原型（PoC）。然而，一個看似成功的原型，反而可能將整個專案推向無法挽回的技術債深淵。MCP 的核心風險並不在於下游工具能否順利整合，而是在專案初始階段，如果沒有對資料綱要（schema）、權限、驗證機制與失敗邊界做出嚴謹的設計，原型越成功、功能越豐富，未來要遷移至生產環境時面臨的障礙就越巨大，我們稱之為「安全之崖」（Security Cliff）。

什麼是「安全之崖」？

在原型開發階段，為了求快，開發者經常採用標準輸入/輸出（stdio）模式來進行伺服器與工具間的通訊。這種方式在單機、低併發的環境下運作良好，能快速實現功能。但這也埋下了擴展性的惡夢。根據日本開發者 aerign 的壓力測試，基於 stdio 的 MCP 伺服器在面對僅僅 20 個並行連線時，系統就幾乎完全崩潰——在 22 次請求中，高達 20 次以失敗告終。這個數字揭示了一個殘酷的現實：從原型到生產環境的路徑並非平滑的斜坡，而是一道陡峭的懸崖。

要跨越這道鴻溝，你不能一次只加一個功能。系統需要一次性地、完整地導入一整套安全與穩定性機制，包括但不限於：

• 傳輸層安全性協定（TLS）以加密通訊
• OAuth 2.0 等級的身份驗證與授權
• 跨來源資源共用（CORS）策略
• 請求速率限制（Rate Limiting）

這些機制環環相扣，缺一不可。任何試圖「之後再補上」的想法，都會發現自己站在懸崖邊緣，進退兩難。

為什麼事後補救幾乎不可能？

問題的根源在於，安全性與設計品質在 MCP 架構中是不可分割的。許多關鍵的設計決策，一旦在初期做出妥協，後期要修正的成本極高，甚至是不可能的任務。例如，使用 Pydantic 這類工具進行嚴格的 schema 驗證，並不是一個可以事後添加的「功能」。它定義了系統內部以及與外部工具溝通的「契約」，所有業務邏輯都建立在這份契約之上。如果初期為了方便而使用寬鬆的資料結構，後期要強制加上嚴格的型別與邊界檢查，無異於將整個系統的地基抽換掉。

同樣的道理也適用於工具的設計。若一開始沒有以「Outcome」為單位來設計工具的輸出與失敗處理，而是讓工具回傳混亂、無結構的字串，那麼上層的 Agent 就難以穩定地解析與決策。當系統變得複雜，這種模糊性會引發連鎖反應，導致系統行為極度不穩定。想在後期導入一致的錯誤處理與回報機制，將會牽動所有已開發的工具，成本難以估計。

MCP 的核心挑戰，並非功能面的「能不能」，而是架構面的「該不該」。在原型階段對 schema、權限與邊界條件的任何妥協，都會在擴展時以數倍的成本反噬。

驗證機制的演進揭示了什麼？

從 MCP 伺服器驗證機制的演進，我們可以更清楚地看到這道安全之崖是如何形成的。整個過程大致經歷了三個階段，每個階段都試圖修補前一個的漏洞：

1. 靜態 API 金鑰：這是最簡單也最不安全的方式。所有工具共用同一組金鑰，這使得伺服器無法區分請求究竟來自哪個合法的工具，極易遭受「困惑的代理人」（Confused Deputy）攻擊。惡意行為者可以誘騙一個有權限的工具去執行非預期的操作。
2. 動態客戶端註冊（DCR）：為了解決金鑰共用的問題，引入了 OAuth 2.0 的動態客戶端註冊（RFC 7591）。每個工具在首次連線時動態註冊自己，取得獨立的憑證。這雖然解決了代理人問題，卻又帶來了新的釣魚風險：惡意工具可以偽裝成合法工具來註冊，竊取授權。
3. 客戶端發起的相互 DPoP（CIMD）：這是目前較為理想的解決方案。它基於 OAuth 2.0 DPoP（Demonstrating Proof-of-Possession, RFC 9449）標準，透過客戶端簽名來證明自己持有私鑰，並將存取權杖（Access Token）與特定的客戶端公鑰綁定。這確保了即使權杖被竊，也無法在其他客戶端上使用，大幅提升了安全性。

這個演進路徑清楚地表明，安全的驗證機制並非一蹴可幾，它需要深思熟慮的架構設計。如果你的原型還停留在第一階段，那麼通往生產環境的路上，還有整整兩個世代的架構需要跨越。

如何從一開始就避開懸崖？

結論非常明確：在 MCP 專案中，「先求有，再求好」的敏捷思維可能會導致災難。我們必須從撰寫第一行程式碼開始，就抱持著生產環境的思維模式。這並不是指過早最佳化，而是要優先把那些一旦定型就很難修改的基礎建設做好。

與其花費數週打造一個功能華麗但地基不穩的 PoC，不如先用幾天時間，把基於 CIMD 的驗證流程、TLS 加密通道、以及基於 Pydantic 的嚴格 schema 驗證框架搭建起來。即使一開始上面只跑一個最簡單的「Hello, World」工具，這個骨架也是穩固且具備擴展性的。唯有如此，我們才能確保原型驗證的成功，能夠平滑地過渡到一個真正健壯、安全的生產級系統，而不是在慶功香檳開啟後，才發現自己站在懸崖之上，無路可走。

延伸閱讀

• MCPサーバー実装における「セキュリティの崖」問題
• RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol
• RFC 9449: OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。