AI的隱藏危機：工具過載如何拖慢LLMs

Model Context Protocol（MCP）伺服器已成為AI開發者的重要基礎設施，使外部工具能整合進大型語言模型（LLMs），以提升功能性與效率。這些伺服器作為中介，讓LLMs能利用外部資料來源或工具，而無需直接編碼或API整合。然而，近期的討論與分析突顯出對於MCP伺服器濫用、過度安裝及潛在安全風險的日益關注，特別是在缺乏適當監管的情況下部署時。

專精於商業編碼助手的工程師Geoffrey Huntley最近在部落格文章中，深入探討了在LLMs的context window中安裝過多MCP工具所帶來的問題。Huntley估計，在最近一次活動中，Visual Studio Code移除了128個工具的限制，導致開發者普遍困惑，許多人在不了解其影響的情況下安裝了大量MCP伺服器。他強調，每個註冊於context window中的工具都會消耗tokens，這將直接影響模型的效能。例如，一個用於列出檔案和目錄的工具大約會消耗93個tokens。隨著多個工具的加入，可用的context window會迅速縮小，導致輸出品質下降和行為不可預測[1]。

這一問題因工具提示和描述缺乏標準化而更加嚴重。不同的LLMs對提示的反應方式各異。例如，GPT-5在遇到大寫字母時會變得猶豫，而Anthropic則建議使用大寫字母以強調重點。這些差異可能導致工具行為不一致及非預期結果。此外，MCP工具缺乏命名空間控制，增加了多個執行相似功能工具之間產生衝突的風險。如果註冊了兩個用於列出檔案的工具，LLM可能會不可預測地調用其中之一，為系統引入不確定性[1]。

安全性是另一個亟需關注的問題。Simon Willison在其部落格文章「The Lethal Trifecta」中指出，允許AI代理與私人數據、不受信任內容及外部通訊互動而無防護措施，存在極大危險。Huntley則進一步引用了近期Amazon Q供應鏈攻擊事件，一個惡意提示導致系統刪除了AWS資源。他認為，部署缺乏監管的第三方MCP伺服器，會增加類似事件發生的風險。相比之下，企業自行設計工具與提示的第一方解決方案，能更好地控制供應鏈風險[1]。

儘管面臨挑戰，MCP伺服器的部署已變得越來越簡化。像Northflank這樣的平台，現已提供建置、部署及管理MCP伺服器的安全自動擴展服務。用戶可利用FastMCP與Starlette等工具將MCP伺服器容器化，然後透過自動健康檢查及運行時機密進行部署。此基礎設施同時支援HTTP/SSE與WebSocket協議，為客戶端與伺服器的互動方式提供彈性[2]。

展望未來，開發者與組織被鼓勵採取更具策略性的MCP伺服器使用方式。Huntley主張限制context window中的工具數量，以維持效能與安全性。他同時建議僅在工作流程相關階段部署工具——例如在規劃階段使用Jira MCP，之後即停用——以降低風險並優化資源分配。隨著生態系統的發展，標準化與最佳實踐將成為確保MCP伺服器提升而非阻礙AI生產力的關鍵[1]。

Source: