2026年 AI Agent 生態系深度研究報告

摘要

截至 2026 年 2 月 8 日，人工智慧領域已從單純的「對話式 AI」全面轉向「代理式 AI」（Agentic AI）。此一轉變的核心動力，在於**模型上下文協議（Model Context Protocol, MCP）**的普及與標準化。MCP 已成為連接大型語言模型（LLM）與外部工具、數據源的通用介面，被視為 AI 應用程式的「USB-C」標準。對於 SaaS 服務提供商而言，這意味著 API 的設計哲學必須從「供開發者閱讀」轉向「供機器自主調用」。

本報告對當前的 Agent 生態進行了詳盡的技術與市場分析。研究發現，目前的生態系統呈現「雙軌制」：一方面是以 Smithery 和 Glama 為首的開放式註冊表，它們是開發者尋找「技能（Skills）」與「MCP 伺服器」的主要入口；另一方面則是 Anthropic 等模型廠商建立的官方封閉市場，對安全性與品質有嚴格要求。

針對 SaaS 服務是否應支援 OAuth 的核心問題，本報告分析指出，Claude Desktop 對 OAuth 的強制要求僅限於遠端（Remote）MCP 伺服器。若採用本地（Local）部署模式，則可透過標準輸入輸出（stdio）繞過此限制。然而，為了實現企業級的零摩擦部署與 SaaS 的商業閉環，實作支援 RFC 7591 動態客戶端註冊（Dynamic Client Registration, DCR）的 OAuth 2.1 架構是長期的必然選擇。報告最後提供了一套分階段的技術轉型路線圖，建議初期採用混合策略，並利用託管認證基礎設施來降低開發門檻。

第一部分：2026 年 Agent 工具生態系統現況

在 2026 年初，AI Agent 的工具生態已經跨越了早期的混沌階段，形成了層次分明的基礎設施。開發者不再需要為每個模型編寫特定的整合代碼，而是透過標準化的協議發布能力。這一結構性轉變催生了全新的「供應鏈」，其中包含發現機製、分發渠道與執行環境。

1.1 「技能（Skill）」與「MCP 伺服器」的本質區別與發現渠道

在探討「去哪裡找」之前，必須先釐清「找什麼」。在 2026 年的語境下，社群對於「技能」與「MCP」的使用往往存在混淆，但在技術架構上它們涇渭分明。

MCP 伺服器（MCP Server） 是指運行在特定環境中的應用程式，它透過 MCP 協議（基於 JSON-RPC 2.0）向 LLM 暴露具體的功能（Tools）、資源（Resources）或提示詞模板（Prompts）。這是 SaaS 服務的主要載體。MCP 伺服器通常是一個完整的後端服務，負責處理業務邏輯、API 調用與狀態管理。

Agent 技能（Agent Skill） 則更多指涉「操作型知識」。它通常以 Markdown 文件（如 SKILL.md）的形式存在，包含了一組結構化的提示詞（Prompts）與流程編排指令（SOP）。技能告訴 Agent 「如何」使用工具來完成特定任務（例如：「如何使用文檔處理工具生成合規的財務報表」），而 MCP 伺服器則提供了「生成文檔」這一原子能力。

1.1.1 主要發現渠道：Smithery.ai 與 Glama.ai

目前，Agent 工具的發現機制高度集中於幾個核心註冊表（Registry），它們扮演著類似 NPM 或 Docker Hub 的角色。

Smithery.ai 是目前生態系中事實上的標準註冊表。它不僅僅是一個列表，更是一個功能完備的包管理器。

搜尋機制： Smithery 支援基於語義的搜尋。Agent 或開發者可以輸入意圖（例如「我需要處理法律文檔」），系統會推薦相關的 MCP 伺服器。
部署整合： 它提供了 @smithery/cli 工具，允許用戶透過簡單的指令（如 npx skills add @smithery/pdf-tools）將工具直接安裝到 Claude Desktop 或 Cursor 等環境中。
信任機制： Smithery 引入了「已驗證（Verified）」標章，這對於企業用戶至關重要。SaaS 廠商若能獲得此標章，將大幅提升在 Agent 自動規劃過程中的被選中率。

Glama.ai 則提供了另一個強大的選擇，其特色在於開源社群的活躍度與對實驗性功能的支援。Glama 強調「深度連結（Deep Linking）」能力，允許開發者分享特定的工具配置組合，這在 Agent 協作場景中尤為重要。

GitHub 依然是原始代碼與參考實作的「真理之源」。smithery-ai/reference-servers 與 modelcontextprotocol 組織下的儲存庫定義了標準實作模式（如 Google Drive、Slack、Postgres 的官方實作）。對於開發者而言，GitHub 是尋找「如何構建」的場所，而 Smithery 是尋找「有什麼可用」的場所。

1.2 從插件到 MCP 的演進

回顧歷史，OpenAI 的 ChatGPT Plugins 是這一領域的先驅，但其封閉性與缺乏標準化導致了生態的碎片化。2024 年底至 2025 年，由 Anthropic 牽頭開源的 Model Context Protocol (MCP) 徹底改變了局勢。到了 2026 年 2 月，MCP 已經成為跨模型、跨平台的通用標準。

這一轉變對 SaaS 廠商的意義在於：您不再需要為 ChatGPT 寫一個插件，為 Claude 寫一個工具，為 LangChain 寫一個整合。您只需構建一個標準的 MCP 伺服器，即可同時服務於 Claude Desktop、Cursor、Windsurf 以及各類自主 Agent 框架。

第二部分：標準規格與技術架構解析

要讓 SaaS 服務成功接入 Agent 生態，必須嚴格遵循 MCP 2025-11-25 版本（及後續修訂）的技術規範。這是目前 Claude Desktop 及主流 Agent 環境所支援的基準版本。

2.1 核心協議架構

MCP 採用客戶端-主機-伺服器（Client-Host-Server）架構。

主機（Host）： 指運行 Agent 的應用程式，如 Claude Desktop 或 IDE。
客戶端（Client）： 主機內部負責與 MCP 伺服器通訊的模組。
伺服器（Server）： 提供能力的單元，即您的 SaaS 服務。

通訊基於 JSON-RPC 2.0 訊息格式。這意味著所有的請求與響應都是無狀態的、結構化的文本數據。

2.2 三大原語（Primitives）

對於 SaaS 服務而言，理解並正確實作 MCP 的三大原語是產品設計的關鍵。

2.2.1 工具（Tools）

這是 SaaS 最核心的介面。工具是可執行的函數，Agent 透過傳遞參數來調用。以文檔處理服務為例，標準的工具定義應包含詳細的 JSON Schema 描述：

convert_url_to_pdf(url, options)：將網頁轉換為 PDF。
merge_documents(doc_ids)：合併多個文檔。
extract_text(doc_id)：從文檔中提取文本。

關鍵洞察： 在 2026 年，工具的 description 欄位比代碼更重要。這是 LLM 閱讀的「說明書」。描述必須精確、具備情境感，甚至包含使用範例（Few-shot prompting），以指導 Agent 在正確的時機調用。

2.2.2 資源（Resources）

資源是數據的被動視圖，類似於 REST API 的 GET 請求，但它是透過 URI 尋址的。

myservice://history/recent：讓 Agent 直接「讀取」最近的操作歷史。
myservice://templates/invoice：讀取發票模板的內容。

資源允許 Agent 在不執行操作的情況下獲取上下文，這對於減少幻覺、提升規劃準確性至關重要。

2.2.3 提示詞（Prompts）

這是 SaaS 廠商引導 Agent 行為的強力手段。您可以預定義一組 Prompt 模板，例如 generate_legal_brief。當用戶選擇此 Prompt 時，您的伺服器會將一段精心設計的系統指令注入到 Agent 的上下文中，確保生成的內容符合特定格式或規範。這相當於將您的領域知識（Domain Knowledge）封裝進了協議中。

2.3 傳輸層標準（Transports）

MCP 定義了兩種主要的傳輸方式，這直接決定了您的認證策略：

1. 標準輸入輸出（Stdio Transport）

這是**本地（Local）**伺服器的標準。Claude Desktop 透過子進程（Subprocess）啟動您的伺服器（例如執行 node index.js）。通訊透過 stdin 和 stdout 進行。

優勢： 延遲極低，部署簡單。
安全性： 依賴作業系統的進程隔離。
認證： 不需要 OAuth。敏感資訊（如 API Key）通常透過環境變數（Environment Variables）在啟動時注入。

2. 伺服器發送事件（HTTP/SSE Transport）

這是**遠端（Remote）**伺服器的標準。Claude Desktop 透過 HTTP 連接到一個遠端 URL。

機制： 使用 Server-Sent Events (SSE) 進行伺服器到客戶端的單向推播，使用 HTTP POST 進行客戶端到伺服器的請求。
優勢： 零安裝（Zero-install），便於集中更新與維護。
認證： 強制要求 OAuth 2.1。 由於暴露在公網，簡單的 API Key 被視為極不安全。

第三部分：OAuth 困境與 SaaS 認證戰略

「Claude Desktop 只支援 OAuth」是目前開發者面臨的最大痛點之一，但這是一個需要精確解讀的技術細節。

3.1 解構「Claude Desktop 只支援 OAuth」的誤解

事實上，Claude Desktop 同時支援 API Key 和 OAuth，但它們適用於不同的部署模式：

設定檔模式（Configuration Mode）： 用戶手動編輯 claude_desktop_config.json 文件。在此模式下，您可以配置 stdio 類型的伺服器，並直接在 env 欄位中填寫 API Key。Claude Desktop 會讀取此設定並啟動伺服器。這是目前絕大多數開發者工具（如 Git, Postgres 工具）的運作方式。此模式不需要 OAuth。

UI 連接器模式（UI Connector Mode）： 當用戶試圖在 Claude Desktop 的圖形介面（Settings > Developer > Connectors）中直接添加一個遠端 URL 時，Claude Desktop 會強制要求該端點支援 OAuth 流程。這是為了防止用戶將長期有效的 API Key 複製貼上到介面中，造成潛在的安全風險（如同步洩露），並確保用戶明確授權。

結論： 若您希望用戶能透過「輸入一個 URL」就完成連接（即類似 ChatGPT Plugin 的體驗），您必須支援 OAuth。若您接受用戶需要安裝一個本地轉接器（Adapter），則不需要 OAuth。

3.2 為什麼 SaaS 必須走向 OAuth 2.1 與 DCR？

對於商業 SaaS 服務，長期目標必然是支援遠端連接模式，原因如下：

企業合規： 許多企業環境禁止員工安裝未經審核的本地二進制文件（Node/Python），但允許連接經審核的 Web 服務。
使用門檻： 遠端連接只需一個連結，無需安裝 Runtime。
狀態同步： 遠端模式可以確保 Agent 操作的狀態與用戶的網頁端帳戶實時同步。

技術挑戰：動態客戶端註冊（Dynamic Client Registration, RFC 7591）

這是實作遠端 MCP 的最大技術門檻。傳統的 OAuth（如「使用 Google 登入」）要求開發者預先註冊 App 並獲得固定的 Client ID。但在 MCP 生態中，每個用戶的 Claude Desktop 實例都是一個獨立的、未知的 Client。 您無法預先為全球數百萬個 Claude Desktop 實例註冊 Client ID。因此，您的伺服器必須實作 RFC 7591：

探索（Discovery）： Claude Desktop 訪問您的伺服器，發現它需要 Auth。
註冊（Registration）： Claude Desktop 發送一個 POST 請求到您的 /register 端點，聲明自己的身份。
發放憑證： 您的伺服器動態生成一個專屬的 client_id 返回給該桌面實例。
授權（Authorization）： 桌面實例使用此 ID 發起標準的 OAuth 2.1 授權碼流程（PKCE）。

3.3 解決方案：託管認證服務（Managed Auth）

強烈建議： 不要自建。利用 Smithery Connect 等託管服務。

自行構建符合 RFC 7591 與 OAuth 2.1 標準的認證伺服器極其複雜且容易出錯。Smithery Connect 充當了一個中間層（Proxy）：

它向 Claude Desktop 暴露標準的 MCP OAuth 介面。
它處理 DCR 和 Token 交換。
它驗證用戶身份後，將帶有您所需上下文的請求轉發給您的後端。

這能將數月的開發工作縮減為數天，並確保符合安全標準。

第四部分：Claude Marketplace 與上架指南

「Claude Marketplace」正式名稱為 Claude Desktop Extension Directory（擴充功能目錄），它是整合在 Claude Desktop 應用程式內部的官方商店。

4.1 什麼是 Claude Marketplace？

這是一個由 Anthropic 官方維護的精選目錄。與開放的 Smithery 不同，這裡的每一個 Extension 都經過人工審核。

入口： 用戶在 Claude Desktop 中輸入 /plugin 或點擊設置中的 Extensions 選項即可瀏覽。
體驗： 點擊「安裝」後，系統會自動下載並配置對應的 .mcpb（MCP Bundle）文件，實現真正的「一鍵安裝」。

4.2 如何登上 Marketplace？

上架流程比開放註冊表嚴格得多，主要包含以下步驟：

封裝為 .mcpb： 您必須將您的 MCP 伺服器封裝為 Desktop Extension 格式。這是一個包含 manifest.json、伺服器代碼及所有依賴項（如 node_modules）的 ZIP 包。這確保了用戶無需預裝 Node.js 或 Python 環境即可運行。
提交審核： 透過 Anthropic 提供的 Plugin Directory Submission Form 提交申請。審核重點：
- 安全性（Security）： 是否有潛在的 Prompt Injection 風險？是否濫用文件系統權限？
- 品質（Quality）： 錯誤訊息是否清晰？工具描述是否能有效引導模型？
- 價值（Utility）： 功能是否獨特且穩定？
合規性檢查： 確保您的隱私政策（Privacy Policy）明確說明了數據如何處理，並聲明上傳的內容不會被用於訓練模型（除非用戶同意）。

4.3 社群市場的重要性

雖然官方 Marketplace 流量巨大，但切勿忽視 Smithery 和 Glama。事實上，Anthropic 的審核週期較長，而社群註冊表是即時生效的。大多數「Power User」和開發者會優先在 Smithery 搜尋最新工具。策略上，應先在 Smithery 累積星數與使用量，作為向官方申請上架時的「社群驗證」證據。

結論與技術路線圖建議

本報告建議 SaaS 服務商採用漸進式轉型策略。在初期，透過本地 MCP 伺服器與 API Key 認證快速進入市場，並同步在 Smithery 註冊以獲取開發者關注。中期利用託管認證服務實現遠端連接能力，降低技術門檻。長期則根據市場反饋與企業需求，逐步構建完整的 OAuth 2.1 基礎設施，並爭取登上 Claude 官方 Marketplace，實現最大的觸及範圍。