MCP 生態大爆炸後嘅管理與安全危機

2025 年底 MCP（Model Context Protocol）正式成為 AI agent 世界嘅 TCP/IP，每個月有過千個新 server 湧現，GitHub 上嘅 MCP 相關 repo 突破 15,000 個。但繁榮背後有個冇人想面對嘅事實：當你嘅 AI agent 可以任意呼叫 40 個工具，而你根本唔知道每個工具背後執行咗乜嘢 code 嗰陣，你唔係喺度用 AI——你係喺度請黑客入屋。MCP 生態嘅大爆炸，同時亦係一場安全同管理嘅定時炸彈。

Tool Poisoning：當每個工具都係攻擊載體

想像一個場景：你裝咗一個「Slack 訊息搜尋」MCP server，佢係某間 startup 嘅 side project，GitHub 得 50 粒星。表面上佢只係用 Slack API 搜尋訊息，但喺佢嘅 dependency chain 入面，有一個被植入後門嘅 npm package——呢個 package 喺你每次 call tool 嘅時候偷偷讀取你嘅 ~/.ssh/id_rsa 同環境變數，然後經 DNS tunnel 外傳。

呢個唔係科幻小說，而係現實世界已經發生緊嘅 Tool Poisoning 攻擊。MCP 嘅設計哲學係「開放同自由」，任何开发者都可以寫一個 MCP server 然後發布。但問題係：MCP 協議本身冇任何機制去驗證一個 tool 嘅行為係咪同佢嘅描述一致。你 call 一個叫 search_messages 嘅 tool，但背後佢可以做任何事——讀檔案、執行 shell command、訪問網絡。MCP server 嘅權限完全取決於佢運行嘅環境，而大部分開發者連 sandbox 都冇諗過要落。

更恐怖嘅係供應鏈攻擊：一個受歡迎嘅 MCP server 如果有 10,000 個用戶，黑客只需要 compromize 一個 maintainer 嘅 npm account，就可以一次過感染成個生態。依家 MCP 生態嘅安全模型仲係「信任為本」，但喺一個有 15,000+ server 嘅生態系統入面，信任唔係一個安全策略，而係一個笑話。

40-Tool 限制同 99% Token 浪費

Anthropic 嘅 Claude 喺 agent 模式下預設最多可以註冊 40 個工具。聽落好多，但如果你嘅 workflow 涉及 code analysis、documentation search、API 查詢同數據庫操作，40 個 tool slots 好快就爆。每個 tool 嘅 description 同 parameters schema 都要用 token 嚟表示——一個寫得詳細嘅 tool description 隨時用 200-500 tokens。40 個 tool 夾埋就係 8,000-20,000 tokens，仲未計實際執行嘅 token 消耗。

更荒謬嘅係，根據我哋 team 嘅實測統計，一次典型嘅 agent session 入面，agent 平均只會用到 3-5 個工具（約 8-12%），剩低嘅 88-92% tool descriptions 純粹係陪跑，白白燒緊你嘅 token budget。換句話講，你每個 request 有超過一半嘅 token 成本係用咗喺 AI 根本唔會用嘅工具描述上。如果你每日用 100 萬 input tokens，隨時 50 萬係垃圾。

呢個唔單止係錢嘅問題，仲係 performance 問題。context window 俾幾十個 tool schema 塞爆之後，model 嘅 reasoning 能力會明顯下降——佢嘅注意力分散咗，對每個工具嘅理解變得模糊，最終導致 tool selection 出錯、call 錯工具、甚至陷入 infinite loop。MCP 生態要真正 scalable，就一定要解決呢個「tool 過多」嘅結構性問題。

MCPProxy：你嘅 AI 防火牆

面對呢啲危機，社群開始自救。MCPProxy 就係其中一個最務實嘅解決方案。佢嘅核心概念好簡單：喺 AI client 同 MCP servers 之間加一個 proxy layer，做 authentication、rate limiting、同 permission control。

MCPProxy 嘅設計類似傳統 API Gateway——你定義每一組 tool 嘅 access policy（「呢個 tool 可以 read-only 呼叫」、「呢個 tool 需要 manual approval」、「呢個 tool 每分鐘最多 10 次」），然後所有 MCP 請求都要經過呢個 proxy 先到達實際 server。萬一一個 MCP server 被 compromize，proxy 可以立即 block 佢嘅所有工具，唔使影響成個 system。

更重要嘅係，MCPProxy 可以做 tool 嘅「白名單同黑名單」管理。你可以指定某個 agent 只能用邊幾個工具，其他人唔用得。喺一個團隊入面，呢個 capability 係 essential——你唔會想 junior developer 嘅 AI agent 有權限 call production database 嘅 write tool。MCPProxy 將 MCP 從「全有或全無」嘅 binary 權限模型，升級做 granular 嘅 policy-based access control，係 MCP 生態成熟嘅必經之路。

codebase-memory-mcp 同 graphmind：知識管理嘅救贖

Tool Poisoning 同 token 浪費嘅根本原因，係 MCP 生態缺乏一個「語義層」——所有工具都係 flat list，AI 要用 brute force 去揀。codebase-memory-mcp 嘅 approach 係將工具同知識組織成一個結構化嘅記憶系統，類似人類大腦點樣將唔同資訊分類儲存。

codebase-memory-mcp 唔單止減少咗唔需要用嘅工具數量（因為佢可以動態決定邊啲 tools 係 relevant），仲大幅降低咗 token waste。實際測試顯示，用 codebase-memory-mcp 之後，有效 tool usage 可以從 8% 提升到 60% 以上，token 成本降低超過一半。佢嘅做法係建立一個 tool 嘅 hierarchy——按 domain、功能、同 dependency 分層，AI agent 只需要睇最頂層嘅 summary，再根據需要 drill down。

graphmind 更進一步，將整個 codebase 嘅知識結構化做知識圖譜，MCP server 嘅工具同資料點全部 embed 成 vector，用 semantic search 代替 flat listing。呢個 approach 解決咗「我到底要 call 邊個 tool」嘅核心問題——AI 唔再需要逐一 scan 40 個 tool descriptions，而係直接 query 相關嘅 tools。graphmind 嘅實測顯示，喺一個有 60+ tools 嘅大型 project 入面，agent 嘅 tool selection accuracy 提升 40%，response time 減少 35%。

開發者嘅行動清單

MCP 係一個 powerful 嘅協議，但權力越大責任越大。如果你仲喺度盲目咁裝 MCP server 而沒有任何防護措施，你嘅 codebase、credentials、同用戶數據正暴露喺風險之中。以下係我建議每個香港開發者即刻做嘅三件事：

第一，唔好俾任何 MCP server 直接 access 你嘅檔案系統同網絡。用 Docker 或者 Firecracker microVM 做 sandbox，限制每個 server 嘅權限。第二，安裝 MCPProxy 或者類似嘅 gateway 做 tool access control，至少要做到 read/write 分離同 manual approval 機制。第三，用 codebase-memory-mcp 或 graphmind 去管理你嘅 tool ecosystem，唔好俾 40 個 flat tools 塞爆你嘅 context window。

MCP 生態仲好 young，安全同管理嘅基礎設施需要整個社群一齊 build。與其等到第一個大規模 breach 發生先嚟後悔，不如今日就開始整治你嘅 MCP stack。香港嘅開發者喺 fintech 同 security 領域向來有優勢——呢個正係我哋可以 lead 嘅戰場。