MCP Server

本地部署和遠端部署的 MCP Server，在資料安全性上具體差在哪裡？我該怎麼判斷該用哪一種？

核心差異在於「資料在傳遞和處理過程中，會不會離開你自己能直接控制的範圍」，這直接影響資料外洩或被第三方存取的風險等級。

本地部署:MCP Server 運行在使用者自己的電腦或自己管理的伺服器上,Agent 呼叫這個伺服器時,所有的資料處理都發生在你自己的機器內部,不會傳送到任何外部第三方的伺服器。這對處理敏感資料(例如個人檔案、公司內部文件、私密的財務資訊)的場景特別重要——你可以完全掌控資料的流向,不需要信任任何外部服務商的資料保護措施。缺點是,本地部署需要使用者自己有能力安裝、設定、維護這個伺服器,對非技術背景的使用者門檻較高,而且如果 MCP Server 本身需要呼叫外部 API(例如查詢即時股價),資料還是會離開本機去外部服務,只是「MCP Server 本身」的運行環境是本地的,不代表這個 MCP Server 內部完全不與外部世界通訊。

遠端部署:MCP Server 由第三方服務商託管,使用者透過網路連接使用,不需要自己安裝維護。優點是使用門檻低、通常伺服器方會持續更新和維護；缺點是,你的請求和相關資料,必須傳送到這個第三方的伺服器上處理,這代表你把資料的控制權部分交給了對方,需要信任對方的資料處理和儲存政策。

判斷原則:如果你要處理的資料本身高度敏感(個人隱私、公司機密、財務憑證等),優先考慮本地部署,即使設定門檻較高,也值得投入這個成本,避免敏感資料經過不熟悉的第三方伺服器;如果資料本身不敏感(例如查詢公開的天氣資訊、公開的市場數據),遠端部署帶來的便利性通常大於風險,可以優先選擇。判斷的核心不是「本地一定比較安全、遠端一定比較危險」這種絕對化的規則,而是要具體評估「這次要處理的資料,離開我的直接控制範圍後,會造成多大的實際風險」。

如果一個 Agent 同時連接了多個 MCP Server，其中一個 MCP Server 本身有安全漏洞或惡意設計，這個風險會不會擴散影響到其他 MCP Server 或整個 Agent 系統？

會,而且這個風險擴散的機制,和前面 Prompt Injection 詞條討論過的「輸入隔離」原則直接相關——如果 Agent 對所有連接的 MCP Server 一視同仁地信任,沒有做任何隔離設計,一個有問題的 MCP Server 確實可能影響到整個系統。

具體的擴散機制:一個惡意或有漏洞的 MCP Server,可能在它回傳給 Agent 的工具執行結果裡,夾帶惡意內容(例如前面 Prompt Injection 詞條提到的、試圖操縱 Agent 推理過程的文字)。如果 Agent 對所有 MCP Server 回傳的內容一視同仁地信任、直接放進後續的推理過程裡,一個被入侵或惡意設計的 MCP Server,理論上可以成為一個新的 Prompt Injection 攻擊入口——這代表連接 MCP Server 這個動作本身,擴大了 Agent 的攻擊面,連接的 MCP Server 數量越多、來源越不受信任,潛在的風險入口也越多。

防禦設計的具體做法:

信任分級。不是所有連接的 MCP Server 都給予相同的信任等級,對來源明確、經過驗證的 MCP Server(例如官方維護的、或你自己團隊開發的),可以給予較高的信任;對來源不明或第三方提供的 MCP Server,回傳的內容應該被標記為「需要額外驗證的外部資料」,套用前面討論過的輸入隔離原則,不能直接觸發高權限動作。

權限範圍限制。每個 MCP Server 連接,應該只被授予完成特定任務所需要的最小權限(呼應前面最小權限詞條),而不是一旦連接就給予這個 MCP Server 對整個 Agent 系統的完全存取權——即使某個 MCP Server 出問題,受影響的範圍應該被限制在它被授權的那個小範圍內。

來源審查。連接任何一個 MCP Server 之前,應該對這個伺服器的來源做基本的審查(是誰維護的、有沒有公開的安全稽核紀錄、社群評價如何),而不是看到一個聲稱能提供有用工具的 MCP Server 就直接連接——這呼應了前面框架選擇文章討論過的「不是所有看起來方便的工具都該直接採用,要評估背後的可信度」這個原則,只是套用在 MCP Server 這個具體場景。

作為 Agent 開發新手，我什麼時候該考慮自己寫一個 MCP Server，而不是直接連接現成的？

判斷標準應該回到「你需要的工具能力，現成的 MCP Server 生態系裡有沒有已經覆蓋」，而不是預設「自己寫比較好」或「用現成的比較好」。

優先考慮直接連接現成 MCP Server 的情況:如果你需要的工具能力,是相對常見、通用的需求(例如讀取檔案系統、查詢公開的網頁內容、操作常見的雲端服務如 Google Drive),生態系裡通常已經有維護良好的現成 MCP Server 可以直接使用,這種情況下自己重新寫一個,除了浪費時間,還可能因為自己實作的品質不如成熟的現成方案,反而引入額外的風險或錯誤。對新手而言,直接使用現成、經過驗證的 MCP Server,能讓你更快把心力集中在「Agent 本身的推理和決策邏輯」這個核心問題上,而不是把時間耗在重新發明一個已經被解決過的工具整合問題。

該考慮自己寫 MCP Server 的情況:如果你需要存取的是高度客製化、專屬於你自己場景的資料或系統(例如你公司內部的專屬資料庫、一個沒有任何現成整合方案的內部工具),這種情況下,生態系裡不太可能已經有現成的 MCP Server 覆蓋這個需求,自己寫一個是必要的選項。

新手自己寫第一個 MCP Server 的建議起點:不要一開始就想著要包山包海,提供所有可能用得到的功能,先從「你目前這個 Agent 專案實際需要的、最小範圍的工具能力」開始寫,寫出一個能動、覆蓋核心需求的簡單 MCP Server,之後再根據實際使用中發現的需求逐步擴充——這個漸進式的做法,呼應了前面框架選擇文章討論過的「先求能動起來,再逐步深入」的學習原則,只是套用在「寫自己的 MCP Server」這個更進階的實作情境。

實務上,多數 Agent 開發者的第一個專案,通常會混合使用「連接一到兩個現成的 MCP Server(處理通用需求)」加上「自己寫一個小型、客製化的 MCP Server(處理專屬需求)」這種組合方式,不是非黑即白的二選一。

在多 Agent 系統裡，如果多個 Sub-agent 需要用到同一個 MCP Server 提供的工具，應該每個 Sub-agent 各自建立獨立的連接，還是共用同一個連接？

這個問題涉及效率和隔離性之間的取捨,答案取決於這些 Sub-agent 之間的信任關係和權限需求是否相同,不是單純看「共用連接比較有效率」就直接選共用。

適合共用連接的情況:如果多個 Sub-agent 彼此高度互補、屬於同一個任務流程的不同環節(呼應前面 Handoff 詞條討論過的情境),而且它們需要的權限範圍本質上相同(例如都只需要唯讀存取同一份資料),共用同一個 MCP Server 連接可以減少重複建立連接的系統開銷,也簡化資源管理——不需要為每個 Sub-agent 各自維護一份連接狀態。

不適合共用連接、應該各自建立獨立連接的情況:如果不同 Sub-agent 對這個 MCP Server 需要的權限範圍不同(例如一個 Sub-agent 只需要唯讀查詢,另一個 Sub-agent 需要寫入或修改的權限),共用同一個連接會導致「權限範圍被迫統一成最大公約數」的問題——如果為了讓兩個 Sub-agent 都能用同一個連接,把連接的權限設定成兩者需求的聯集(涵蓋讀取和寫入),原本只需要唯讀權限的 Sub-agent,也意外獲得了寫入權限,這直接違反了前面反覆強調的最小權限原則。這種情況下,即使有一些額外的連接管理開銷,也應該為不同權限需求的 Sub-agent,各自建立獨立的、範圍精確對應的連接。

另一個該用獨立連接的情境:如果不同 Sub-agent 的信任等級不同(例如一個是核心、經過完整測試的 Sub-agent,另一個是還在實驗階段、行為不確定性較高的 Sub-agent),即使它們理論上需要相同的權限範圍,也建議用獨立連接,這樣如果實驗性 Sub-agent 的行為出現異常(例如異常頻繁地呼叫某個工具,觸發前面異常行為偵測詞條討論過的機制),可以單獨限制或暫停那一個連接,不會波及到核心 Sub-agent 的正常運作。

簡單的判斷原則:先問「這些 Sub-agent 需要的權限範圍是否完全相同」,不同就該用獨立連接;再問「這些 Sub-agent 的信任等級和穩定性是否相同」,不同也該用獨立連接;只有在兩個問題的答案都是「相同」時,共用連接帶來的效率提升,才不會犧牲掉隔離性帶來的安全價值。