MCP係咩，點解而家每個AI工具都突然識講佢？

過去十年大部分時間，將一個AI模型連接去公司嘅工具，即係每一對都要各自做一套整合。Model Context Protocol係Anthropic喺2024年11月推出嘅開放標準，用一個邊度都插得入嘅插頭取代咗嗰種做法——而OpenAI、Google同Microsoft之後都採用咗佢。以下講解佢實際點運作，以及喺你將佢連接到團隊數據之前，一份真正用得着嘅檢查清單。

打開Claude嘅桌面應用程式，叫佢睇吓你團隊未關閉嘅pull request，佢真係做得到。唔係因為Anthropic喺Claude入面內建咗一套GitHub整合。而係因為某個地方——你嘅IT團隊、一間供應商、又或者GitHub上面一個開發者——有人寫咗一個細小嘅程式，識講一種叫做MCP嘅協定，而Claude已經識得同任何識講呢種協定嘅嘢溝通。而家ChatGPT、Google嘅Gemini同Microsoft Copilot都係咁。呢種匯合，比起任何一次單一功能發佈都重要，正正就係點解過去一年幾乎每一間AI供應商都喺度為MCP做支援。

MCP實際上係咩

MCP即係Model Context Protocol。Anthropic設計咗佢，並且喺2024年11月25日將規格連同第一批SDK一齊開源。佢自己嘅發佈材料用咗一個深入民心嘅比喻：將MCP想像成AI應用程式嘅USB-C接口——一個統一嘅實體接頭標準，而唔係每件配件都要一條唔同嘅線。發佈當日，Anthropic點名咗一班已經喺自己產品入面做MCP支援嘅早期採用者，包括企業軟件公司Block同Apollo，以及開發工具廠商Zed、Replit、Codeium同Sourcegraph。Claude嘅桌面應用程式同一日推出，已經可以喺一個人自己部電腦上面本地運行MCP伺服器。

佢解決嘅問題：N個工具乘M個數據來源

MCP解決嘅問題，工程師平時有個口頭叫法：N乘M整合問題。假設一間公司用緊五個需要對公司數據採取行動嘅AI工具——Claude、ChatGPT、GitHub Copilot、Cursor，同埋一個內部支援機械人——而呢啲數據散落喺八個地方：Slack、GitHub、一個Postgres資料庫、Salesforce、Notion、Google Drive、Jira，同一條內部API。冇一個共用協定，要將每個工具都有效咁連去每個來源，最多要做四十套分開嘅整合——五乘八——每一套都有自己嘅認證方式、自己嘅錯誤處理，以及每次其中一條API改咗形狀就要再付一次嘅維護成本。再加第六個AI工具，個數就跳到四十八。現實入面，冇人真係做齊四十套。每間AI供應商只做咗佢覺得值得花工程時間嘅嗰幾套，其餘全部靠人手：複製、貼上、再解釋一次，然後重複。

MCP將乘法變成加法。一間公司想Claude由佢嘅Postgres資料庫讀數據，唔使做一個專為Claude而設嘅Postgres連接器。佢只要建立——或者重用別人已經發佈咗嘅——一個暴露Postgres嘅MCP伺服器，嗰個伺服器就可以俾Claude、ChatGPT、Gemini，或者任何其他相容MCP嘅代理使用，唔使再寫多一段程式。Anthropic自己喺發佈時列出嘅預建伺服器，包括Google Drive、Slack、GitHub、Git、Postgres，同一個叫做Puppeteer嘅瀏覽器自動化工具。重點從來唔係Anthropic會將全部都自己做齊。而係任何人都可以做，而現有伺服器嘅目錄，已經遠遠超出任何一間公司自己請得起人去維持嘅規模。

協定實際上點運作

抽走包裝，MCP其實係一套相當樸素嘅客戶端－伺服器協定，刻意設計得唔華麗。佢定義三個角色。Host係一個人真正打開嘅應用程式——Claude Desktop、好似Cursor咁嘅IDE、ChatGPT應用程式。Host入面嵌入一個MCP Client，佢會同MCP Server開一條直接、有狀態嘅連接——MCP Server係一個細小嘅程式，暴露一個特定系統：一個資料庫、一個工單工具、一個檔案系統、一條內部API。客戶端同伺服器之間交換嘅訊息格式係JSON-RPC 2.0，一種喺現有基建入面已經好常見嘅輕量遠端程序呼叫格式，經由兩種傳輸之一：stdio，當伺服器係喺同一部機器上面本地運行嘅程式；或者Streamable HTTP，當佢係喺其他地方運行嘅託管服務。

一個伺服器可以暴露嘅嘢，歸結為三種原語。Tools係模型可以呼叫嚟採取行動嘅函數——create_task、run_query、send_message——模型會根據對話決定幾時呼叫。Resources係唯讀嘅上下文，Host可以自己拉入嚟交畀模型，唔使模型開口問——一個檔案嘅內容、一個資料庫結構、一張支援工單。Prompts係可以重用、由使用者觸發嘅範本——一句預設嘅「總結呢條討論串」或者「起草一份狀態更新」，由人明確叫出嚟，而唔係模型自己決定去做。一個做得好嘅伺服器，會清楚講明某一項能力屬於呢三種入面嘅邊一種，因為呢個分別正好決定一個已連接嘅AI工具只可以睇，定係可以改。

仲有邊個採用咗，幾時採用

MCP頭幾個月只係Anthropic自己嘅項目。之後轉得好快，而且轉法喺AI界真係少見：直接嘅競爭對手匯合到同一間公司嘅協定上面，而唔係各自出自己一套。OpenAI喺2025年3月將MCP支援加進佢嘅Agents SDK，等開發者可以將代理工作流連去任何MCP伺服器，唔使再做專為OpenAI而設嘅工具整合。下一個月，Google DeepMind確認Gemini同佢自己嘅代理開發套件都會支援MCP——Google同時配咗自己一套互補協定Agent2Agent，目標係讓獨立嘅代理彼此協調，而唔只係同工具協調。到2025年5月，Microsoft已經透過佢叫做Windows AI Foundry嘅東西，將原生MCP支援帶入Windows 11，支援亦同時落喺GitHub Copilot同Copilot Studio入面。

呢四間公司喺模型架構、定價或者平台策略上，幾乎冇咩一致。而家四間都出貨識講同一套協定、用嚟將代理連去工具嘅產品。喺呢個行業，呢件事已經夠罕見，足以成為真正嘅故事——比起MCP促成嘅任何單一功能都更重要。

點解呢個係信任問題，唔只係接線

呢種匯合的確有用，亦正正係點解MCP值得審視，而唔係盲目信任。一套令代理可以輕鬆連去你公司系統嘅協定，同樣令一條做得差或者設定得差嘅連接可以輕鬆觸及同一批系統。MCP本身阻止唔到呢件事。規格只定義客戶端同伺服器點樣對話——佢冇講邊個有權批准一條連接、呢條連接可以掂到啲咩，或者出事嘅時候會唔會有人察覺。呢啲選擇完全落喺做或者設定你面前嗰個具體伺服器或客戶端嘅人身上。有啲供應商會好小心咁將呢啲全部做好。有啲根本唔做，而協定唔會阻止佢哋。

連接之前嘅檢查清單

喺你嘅團隊連接一個MCP伺服器之前——無論係供應商嘅產品、有人喺GitHub搵到嘅開源工具，定係內部自己做嘅——六條問題分開一條受治理嘅連接同一道敞開嘅門。冇一條需要你去讀規格。佢哋只要求有人喺撳批准之前先問，並且真係去讀連接畫面交返嚟嘅答案。

一條做得好嘅連接實際係點樣

FabricLoop自己嘅MCP設定，係對呢份清單嘅一個具體答案——唔係因為佢特別，而係因為每一件都直接對應上面六條問題之一，而且值得講明實際機制，而唔係行銷版本。FabricLoop同時擔任兩個角色：佢係一個外部工具連入嚟嘅MCP伺服器，所以Cursor、Claude或者ChatGPT可以用某一個人自己嘅FabricLoop權限去建立任務、加留言或者讀筆記——佢亦係一個向外連接嘅MCP客戶端，所以一個頻道可以拉入供應商嘅MCP應用程式，好似GitHub或者Linear，然後好似@提及一位隊友咁提及佢。

呢啲都唔係甚麼奇異嘅工程。佢係一組細小、刻意唔華麗嘅決定，並且一致咁重複：限定範圍、綁定到一個人、記錄落嚟、撤銷嘅時候唔會傷及旁邊。呢個同本網站對可判讀性更廣泛嘅論點一樣——你可以叫得出名、可以記錄、可以撤銷嘅存取，好過冇人需要去諗嘅存取——而MCP只有喺有人咁樣去建嘅時候，先至交到呢樣嘢。協定將接線標準化。佢唔會令治理自動發生。

真正要緊嘅決定

MCP唔會消失，而家先反對佢，有少少好似反對USB。每一間主要模型供應商而家都出貨佢，可用伺服器嘅清單持續增長，而一個觸及唔到你工具嘅代理，對大部分真正嘅工作嚟講，就係一個做唔到幾多嘢嘅代理。有趣嘅決定唔係應唔應該讓一個AI工具連去你嘅系統——呢個決定愈嚟愈係已經有人替你做緊，一次整合一次，當你團隊已經用開嘅工具靜靜雞喺一個你撳入去但冇讀細則嘅功能底下加上MCP支援。仍然真正屬於你嘅決定，係你喺撳批准之前檢查啲咩。