人看得懂界面，能自己推斷該做什麼。Agent 不能。它需要一份明確的契約：有哪些動作可用、每個動作需要什麼輸入、會返回什麼。
一旦某個品類裡有一款產品能被 agent 驅動，選型問題就從「誰功能更好」變成「哪一個我的工具能直接操作」。
有人從一個內部系統讀出一個數值，再敲進另一個系統。那是一個人在整天做 API 該做的事，而且會打錯。
你可能已經有一套相當不錯的 REST API。但 agent 仍然需要能發現有哪些能力、判斷什麼時候該調用哪一個，並且被限制在「當前用戶有權觸及的範圍」之內。
單租戶的概念驗證幾天就能做完。真正的工作量在多租戶隔離、鑑權、審計，以及讓失敗行為可預期。
基於官方 SDK 開發，接到你既有的系統上，部署在你自己掌控的基礎設施中。
多數合作從單一系統的概念驗證開始 —— 正是為了讓雙方在投入生產級範圍之前，先看清 agent 的實際表現夠不夠好。
確認 agent 應該能執行哪些動作、針對哪些系統，以及權限邊界該劃在哪裡。
工具清單、說明文字與輸入輸出 schema，在開始實現之前以書面形式確認。
對接你的 API 完成實現，再做鑑權與租戶隔離 —— 從演示到生產，大部分距離在這一步。
在真實客戶端中調整行為直到工具選擇穩定，隨後連同文檔一併部署交付。維護為可選項，單獨計價。
Model Context Protocol 是一項開放標準，用於把一套系統的能力暴露給 AI agent。它避免了「每個產品各自發明一種被 agent 驅動的方式、每個 agent 客戶端又要為每個產品單獨寫適配代碼」。你的系統發布一組工具，任何符合規範的客戶端都能發現它們、理解每個工具的作用並調用。
不需要。MCP 服務器位於你既有系統之前，是一層翻譯與權限控制，而不是替代品。只要你現有的 API 能完成某件事，工作就是把它正確地暴露出來，而不是重做一遍。
OpenAPI 文檔描述的是端點，讀者是一位「讀一遍然後寫代碼」的開發者。MCP 描述的是能力，使用者是一個必須在運行時、沒有人參與的情況下判斷「此刻該用哪項能力」的 agent。實際差別體現在說明文字上：為開發者寫的端點摘要，通常簡短到 agent 無法據此做出正確選擇。
任何實現了該協議的客戶端。實務上包括目前主流的 agent 與編程客戶端，而且這個名單還在增加 —— 這正是「實現一項標準」而非「為每家廠商單獨做集成」的意義所在。
服務器對調用方進行身份認證，並依據該身份在你產品中既有的權限來解析每一次請求，而不是相信 agent 自稱在為誰服務。租戶隔離施加在數據訪問層，而不僅僅寫在工具說明裡 —— 說明文字是給語言模型的指引，永遠不能當作安全控制。
跑在你自己的基礎設施上。請求從 agent 客戶端到你的服務器、再到你的 API。我們不會插入一個託管的中間層，正常運行下也不存在任何讓你客戶的數據流經我們的安排。
會需要偶爾維護 —— 所以維護是一個單獨的可選項，而不是假裝不存在。基於官方 SDK 開發能吸收大部分協議層面的變動；真正會影響到你的變化，通常來自你自己的 API 演進，而不是協議本身。
這正是我們建議的起步方式。一套系統、少量工具、真實客戶端測試 —— 足以在投入多租戶生產範圍之前，看清 agent 在你的業務場景中是否真的有用。如果結論是否定的，這也是一次代價很低的驗證。