--- title: "ChatGPT Sites 能直接託管 MCP 伺服器：企業內部工具外掛化，權限與資料邊界要先想清楚" description: "ChatGPT Sites 開放託管 MCP 伺服器，開發者可在介面內完成建置與部署，再打包成外掛分發到 Web、行動與桌面端，並設定私有或公開權限。本文先整理官方流程與適用場景，再拆解企業導入前必須先確認的權限邊界、資料範圍、重新發布紀錄與觀測方式，最後附上可直接照做的五步驟檢查清單。" canonical: "https://yotron-ai.com/blog/chatgpt-sites-mcp-server-hosting-enterprise-guide" published: "2026-10-01" last-updated: "2026-10-01" --- # ChatGPT Sites 能直接託管 MCP 伺服器：企業內部工具外掛化，權限與資料邊界要先想清楚 ChatGPT Sites 開放託管 MCP 伺服器，開發者可在介面內完成建置與部署，再打包成外掛分發到 Web、行動與桌面端，並設定私有或公開權限。本文先整理官方流程與適用場景，再拆解企業導入前必須先確認的權限邊界、資料範圍、重新發布紀錄與觀測方式，最後附上可直接照做的五步驟檢查清單。 > 文／Laban（優創智能 AI 導入工程師） ChatGPT Sites 現在可以直接託管 MCP 伺服器。結論先講：**這讓「把內部知識或工具變成 ChatGPT 能呼叫的外掛」從一個需要後端工程的專案，降成一次對話就能啟動的流程，但也讓權限邊界變成使用者要自己負責的設計題。** 開發者能在 ChatGPT 介面內完成伺服器建置與部署，再把成果打包為外掛，分發到 Web、行動與桌面端，並以私有或公開權限控管誰能使用。 MCP（Model Context Protocol）本身的原理與企業用法，可先看 [MCP、API、CLI 完整指南（上）](/blog/mcp-api-cli-guide-2026-part-1)。這篇只談新變化：託管帶來什麼、企業導入前該先管什麼。 --- ## 一、官方說了什麼（已知事實） 以下整理自 OpenAI 說明文件與 DevDay 2026（2026-09-29）相關報導： - **在 Site 裡託管 MCP 伺服器**：你可以在新的或既有的 ChatGPT Site 中託管 MCP 伺服器，再透過 ChatGPT 的外掛使用這些工具。官方舉例：做一個放團隊手冊的 Site，請 ChatGPT 加入一個 MCP 伺服器，提供搜尋與讀取手冊的工具。 - **建置方式**：請 ChatGPT 或 Codex 加入 MCP 伺服器，並描述工具要讀取的資訊，以及可以修改的內容。 - **發布即產生外掛**：由 Site 擁有者發布網站後，系統建立對應外掛；若網站已發布，新增工具後須重新發布。 - **安裝**：外掛會出現在個人外掛清單中，選擇加號即可安裝。 - **分享**：ChatGPT Sites 也可以託管外掛，與同事分享。 - **同場公布的其他項目**：外掛獲得側邊欄首頁、互動面板與檔案檢視器等類 App 介面；新增 Plugin Creator 工具與改版後的外掛目錄提交流程；並支援提議中的 MCP Events 規範，讓外掛能在連接的應用程式發生事件時啟動自動化。 依使用者提供的快訊，外掛可分發至 Web、行動與桌面端，並支援細粒度的私有或公開權限。各方案的可用範圍與權限選項細節，以 OpenAI 說明頁當下顯示為準。 --- ## 二、這個變化對企業的意義（編輯分析） ### 1. 試點成本明顯下降 過去要做一個「讓 ChatGPT 查內部手冊」的工具，要有人寫 MCP 伺服器、找地方部署、處理 HTTPS 與驗證、再想辦法讓同事安裝。現在這些步驟被收進同一個介面，非工程背景的部門也有機會自己做出第一版。 ### 2. 風險也跟著下放 門檻降低的另一面，是「誰有權限做出能改資料的工具」不再只有工程部門知道。當每個部門都能做外掛，企業要處理的是： 1. **工具清單失控**：沒有人知道組織裡有多少外掛、各自能碰什麼資料。 2. **權限描述就是權限邊界**：官方流程是用自然語言描述「能讀什麼、能改什麼」，描述含糊，邊界就含糊。 3. **公開誤設**：私有／公開只差一個選項，錯設代價很高。 這些問題的共同解法，是把外掛納入和其他 AI 代理一樣的權限治理，可參考 [AI 代理權限邊界與沙箱設計](/blog/ai-agent-permission-boundary-sandbox)。 ### 3. 適合與不適合的場景 | 場景 | 建議 | | --- | --- | | 員工手冊、產品規格、公開 FAQ 的搜尋 | 適合先試，唯讀即可 | | 內部流程查詢（請假規則、報價規則） | 適合，限制為組織內部可見 | | 查詢客戶資料、訂單狀態 | 先評估資料外送與稽核需求再決定 | | 寫入類操作（改單、發信、扣款） | 不建議直接用託管版上線，需有人工確認與操作紀錄 | | 有法規要求日誌留存或固定來源 IP 的系統 | 評估自架 MCP 伺服器 | --- ## 三、企業導入前的五個步驟 ### 步驟 1：先選一個唯讀的低風險場景 挑「問的人多、答案在固定文件」的題目，例如員工手冊。第一版只做搜尋與讀取，不加任何寫入工具。 ### 步驟 2：把權限寫成清單，而不是一句話 在請 ChatGPT 或 Codex 建置前，先自己列出： 1. 工具能讀取的資料範圍（哪些文件、哪些欄位） 2. 工具不能碰的資料（個資、薪資、客戶名單） 3. 是否有任何寫入動作；沒有就明確寫「僅讀取」 建置完成後逐項檢查工具實際行為，是否與清單一致。 ### 步驟 3：預設私有，分享範圍逐步放大 先只給自己與一兩位同事，確認輸出正確後，再擴大到部門。公開權限只留給本來就公開、且完全唯讀的內容。 ### 步驟 4：建立外掛登記表 至少記錄：外掛名稱、負責人、可讀寫資料、可見範圍、上線日期、最近一次重新發布日期。**新增工具後必須重新發布**，這個動作要有人負責並留下紀錄，否則線上版本與登記內容會不一致。 ### 步驟 5：觀察兩到四週，再決定是否擴大 追蹤三個指標：每週使用次數、答錯或查無結果的比例、有無超出預期的資料被讀取。三項穩定後，才考慮加入寫入類工具，並要求人工確認與可回復機制。完整的導入節奏可參考 [AI 導入 30-60-90 天 PoC 評估](/blog/ai-implementation-poc-30-60-90-day-evaluation)。 --- ## 四、結語：把外掛當成一個要被管理的系統 ChatGPT Sites 託管 MCP 伺服器，意義不在「又多一個功能」，而在於**企業內部工具的製作門檻被拉低**。這是好事，前提是組織同步建立最小治理：唯讀起步、預設私有、有登記表、有重新發布紀錄。 如果你想評估哪些內部流程適合做成 ChatGPT 外掛，或需要把 AI 代理的權限邊界設計好，歡迎參考優創智能的 [AI 導入服務](/services)，或直接 [與我們聯絡](/contact)。 --- **參考來源** - OpenAI Help Center，〈Hosting a plugin with ChatGPT Sites〉，2026-10-01 查閱：https://help.openai.com/en/articles/20001547-hosting-a-plugin-with-chatgpt-sites - TechCrunch，〈OpenAI expands ChatGPT's plugins with app-like interfaces and automations〉，2026-09-29：https://techcrunch.com/2026/09/29/openai-expands-chatgpts-plugins-with-app-like-interfaces-and-automations/ - OpenAI Learn，〈Model Context Protocol〉，2026-10-01 查閱：https://learn.chatgpt.com/docs/extend/mcp --- ## 相關推薦與延伸閱讀 - [Meta Muse 登頂 App Store：個人 AI 代理引爆「代辦」熱潮，企業工作流自動化的落地啟示與信任邊界](/blog/meta-muse-agent-app-store-enterprise-guide)：Meta 個人 AI 代理 Muse 上線十天登上美國 App Store 免費榜冠軍，股價單日漲逾 11%。本文從企業 AI 導入視角，拆解「問答轉向代辦」的 - [5 個行政自動化場景：會議、郵件、排程與報表驗收](/blog/ai-admin-tasks-automation)：AI 行政自動化怎麼做才有效？從會議摘要、郵件草稿、社群排程到費用及定期報表，整理五類行政自動化的輸入、人工覆核與驗收方式，不把工具設定完成當成效益保證。文中附 - [AI 客服 API 當機怎麼辦？Timeout、Retry、熔斷與人工降級標準](/blog/ai-customer-service-api-outage-circuit-breaker)：AI 客服遇到上游 API timeout、429 或 5xx 時，不能無限重試。本文整理 timeout、backoff、circuit breaker 的建