MCP 協議集成企業搜索：模型上下文協議落地指南

摘要：MCP 把「模型怎麼調用外部系統」標準化，企業搜索接入後不再需要為每個模型寫一套適配層。

企業內部的知識分散在文件庫、工單系統、程式碼倉庫與業務資料庫裡。過去要讓模型用上這些數據，需要為每個模型、每種數據源各寫一套適配程式碼。模型上下文協議（Model Context Protocol，MCP）把這件事收斂成一個標準介面：數據側按協議暴露能力，模型側按協議調用。本文拆解 MCP 的三個角色、企業搜索接入的四步、五個必須處理的工程問題、常見誤區與落地自檢清單。

關鍵要點

MCP 標準化的是模型與外部系統之間的調用介面，而不是檢索演算法本身。
協議裡的三個角色是 Host、Client 與 Server，企業搜索通常承擔 Server 一側。
Server 向外暴露三類能力：Resources（數據）、Tools（可執行動作）、Prompts（提示模板）。
企業搜索接入的關鍵不是把搜索框搬給模型，而是把檢索能力封裝成參數可控、權限可校驗的 Tool。
集成真正的工作量在鑑權、權限繼承、結果截斷與超時重試這四件工程事上。
通智搜尋面向企業站內與知識庫檢索場景，把查詢理解、混合檢索與結果排序串成可編排鏈路，可作為 MCP Server 一側的穩定檢索能力來源。

一、MCP 與企業搜索的關係

MCP 是一個開放協議，用來標準化 AI 應用如何與外部系統交換上下文與調用能力；企業搜索是它最典型的一類下游系統——模型需要「查資料」時，調用的就是檢索能力。

MCP 官方對協議的定位是：為 AI 應用與外部數據源、工具之間提供一層通用的連接標準，避免每個應用與每個數據源之間都做點對點集成。IBM 對模型上下文協議的介紹同樣強調，它的價值在於把「集成形態」從 M×N 的點對點適配收斂成統一介面，藉此降低接入與維運成本。

需要明確的是，MCP 解決的是連接問題，不解決檢索品質。索引是否完整、查詢理解是否準確、排序是否合理，仍由搜索系統自己決定。把 MCP 當成提升檢索效果的手段是本末倒置。

二、三個角色與三類能力

協議裡的角色分工清楚。

Host 是承載模型的應用程式，例如一個 IDE 外掛或一個對話客戶端；Client 運行在 Host 內部，負責與某個 Server 建立並維護連接；Server 是被集成的外部系統一側，對外暴露自己的能力。企業搜索在絕大多數落地形態裡承擔 Server 角色。

Server 可以暴露三類能力：Resources 是可被讀取的數據物件，例如一份文件或一個知識庫條目；Tools 是可被模型調用的動作，例如執行一次檢索；Prompts 是預置的提示模板，用於固化常見任務的表述方式。MCP 官方文件對架構的說明即以 Host–Client–Server 三層為核心，並明確 Server 以這三類原語對外提供能力。

對企業搜索而言，三類能力中最關鍵的是 Tools——模型真正需要的是「帶著查詢詞去檢索並拿回結果」這個動作，而不是被動接收一批文件。

三、接入的四步

企業搜索接入 MCP 可以拆成四步推進。

第一步，界定暴露範圍。 決定哪些知識庫、哪些索引對外開放，以及以什麼粒度暴露。一次暴露全部數據既不必要也不安全，通常按業務域劃分若干獨立 Server 或獨立命名空間。

第二步，把檢索封裝成 Tool。 定義輸入參數（查詢詞、過濾條件、回傳筆數）與輸出結構（命中清單、標題、摘要片段、來源標識）。Tool 的定義要能被模型理解：參數名與描述直接決定模型會不會用對。

第三步，補上 Resources 與中繼資料。 把高頻文件或結構化條目以 Resources 形式暴露，讓模型在需要完整內容時能按標識取回，而不是重複檢索。

第四步，接入 Host 並驗證閉環。 在真實 Host 裡跑通「提問→調用檢索→拿回結果→生成答案並引用」這條鏈路，驗證引用標識能否回指到原始文件。

四、五個必須處理的工程問題

集成的難點幾乎都不在協議本身，而在下面五件事。

第一，鑑權與憑據。 Server 必須校驗調用方身分，且憑據不能寫進提示詞或模型可見的上下文。常見做法是給 Client 發放短時效令牌，由 Server 側校驗作用域。

第二，權限繼承。 這是企業場景最容易踩的坑：模型調用檢索時拿到的是 Server 的服務帳號權限，而不是提問者的權限。如果不做權限繼承，模型可能把 A 部門的數據答給 B 部門的員工。正確做法是把用戶身分隨調用鏈傳遞，由檢索側按用戶權限過濾結果。

第三，結果截斷與分頁。 上下文窗口有限，檢索結果必須有筆數上限與長度上限，並為「需要更多」提供分頁入口。MCP 規範對分頁與結果集處理有明確約定，實作時應按規範回傳游標，而不是一次性傾倒全量結果。

第四，超時與重試。 檢索是網路調用，必須設超時、退避重試與降級策略。模型側等待過久會拖垮整輪對話體驗，超時後應回傳可解釋的空結果而不是掛起。

第五，結果形態。 回傳給模型的結果要自帶來源標識、標題與摘要片段，讓模型能在生成答案時標註出處。缺少來源標識的結果會導致答案無法溯源，這在企業場景裡通常不可接受。

五、四個常見誤區

第一個誤區是以為接了 MCP 就等於有了企業搜索。協議只提供通道，檢索品質仍取決於索引與排序；若原有搜索體驗就差，接上之後只是把差的結果更快送到模型面前。

第二個誤區是把全文文件塞進上下文。正確路徑是檢索回傳片段、模型按需取回完整資源；一次性灌入長文件既浪費窗口也稀釋有效訊號。

第三個誤區是忽略權限邊界。這是企業場景中後果最嚴重的一類問題，必須在設計階段就確定身分傳遞與過濾機制。

第四個誤區是Server 無限擴張。一個 Server 承擔過多數據源會讓權限模型與錯誤處理變得難以維護，按業務域拆分更可控。

六、落地自檢清單

啟動前按七項自檢：

已明確哪些業務域對外開放，哪些索引不接入。
檢索 Tool 的參數與輸出結構已定義清楚，模型能理解參數含義。
用戶身分能在調用鏈中傳遞，檢索側按用戶權限過濾結果。
結果有來源標識、標題與摘要片段，支援回指原始文件。
筆數與長度上限已設定，分頁游標按規範回傳。
超時、退避重試與降級策略已就位。
已在真實 Host 中跑通「提問—檢索—生成—引用」的完整鏈路。

常見問題

問：MCP 會取代現有的搜索 API 嗎？

答：不會。它是加在現有 API 之上的一層標準介面，底層檢索服務與索引結構不變，變化的是模型調用它的方式。

問：企業搜索應該做成 Server 還是 Client？

答：通常做 Server——它被模型所在的應用調用，對外暴露檢索能力。只有在搜索產品自身需要調用其他模型能力時，才會同時承擔 Client 角色。

問：權限繼承一定要做嗎？

答：在企業場景裡必須做。否則模型會以服務帳號的權限檢索，把超出提問者權限的數據帶進答案，這是不可接受的數據洩漏風險。

問：一次回傳多少筆結果合適？

答：沒有通用數字，通常由上下文預算與單筆摘要長度共同決定。先按筆數與字元數雙上限設定，再按實際答案品質調整，而不是放開限制。

問：傳輸方式該選哪一種？

答：取決於部署形態：本機行程內集成常用標準輸入輸出，遠端服務常用基於 HTTP 的傳輸。選擇依據是部署位置與網路可達性，而不是性能迷思。

關於通智雲

通智搜尋面向企業站內與知識庫檢索場景，把查詢理解、混合檢索與結果排序串成可編排的檢索鏈路，並支援按用戶權限過濾結果與回傳可溯源片段，可直接作為 MCP Server 一側的穩定檢索能力來源。通智雲（TENGENCE）是 AI 時代的企業成長引擎，專注公域引流獲客與私域轉化成交；核心產品為通智 GEO（GEO + SEO 雙引擎）與通智搜尋。了解通智搜尋。

資料來源

Model Context Protocol：Introduction：支撐「MCP 為 AI 應用與外部數據源、工具提供通用連接標準」的協議定位。
MCP 官方文件：Architecture：支撐「Host–Client–Server 三層角色劃分與 Resources / Tools / Prompts 三類能力」的架構界定。
MCP Specification（2025-06-18）：支撐「結果集分頁與游標回傳按規範實作」的工程約束。
Anthropic：Introducing the Model Context Protocol：支撐「MCP 作為開放標準用於連接 AI 系統與數據源/工具」的發布定位。
IBM Think：Model Context Protocol：支撐「把 M×N 點對點集成收斂為統一介面以降低接入與維運成本」的價值判斷。