--- tags: - 模組化 - 互操作性 - 脈絡工程 - LLM應用 - 系統整合 - 工具鏈 - CI/CD - 智慧代理 - 多源數據 --- # 🔗API與MCP🌐 {#sec-api-mcp} `API`（Application Programming Interface / 應用程式介面）與 `MCP`（Model Context Protocol / 模型脈絡協定）是現代 AI 工程與軟體系統實現**模組化**與**互操作性**的基石。API 提供了不同系統、服務或模組之間的標準化溝通方式；MCP 則在此基礎上，為多模組、多工具、多數據源的協作提供結構化、可編排的整合框架。 因此，`API與MCP`可視為圍繞多種數據與計算資源的「工具箱」，在成熟的商業與開放 API 生態系上，在網際網路上，讓**大語言模型**人工智慧（LLM AI） ： * 能精準依指令行動的的[提示工程](10-03-prompt_engineering.zh-hant)、 * 能基於指定知識集回答的[知識驅動生成（RAG）](10-04-retrieval_augmented_generation.zh-hant)、以及 * 能理解情境脈絡「讀懂空氣」再回應的 [脈絡工程](10-05-context_engineering.zh-hant)。 這數據與計算的「工具箱」讓 LLM AI 從封閉式生成走向創意融合。 廣義層面的`API與MCP`融合不侷限於用於 LLM AI 系統，還適用於任何需要跨模組協作的軟體架構（參見[附錄：API分類](appendix-MCP_API.zh-hant)）。本條目將專注在說明API與MCP的核心概念，特別是在支持 LLM AI 系統的開發與創新，是如何構成並引領現代 [AI工程](10----ai_engineering.zh-hant) 的發展，催生出一套強調結構化的可編排、可監控、可持續交付（CI/CD）的工程流程。 *** ## 🏷️ 核心概念 在深入探討 LLM 與 MCP 的結合之前，先認識 API 與 MCP ### 🌐📱 RESTful API RESTful API 是基於通用的 Web 標準（主要是 HTTP）、推動萬維網（WWW）動態交流的應用架構風格，已成為最主流的 `API` 形式，允許不同系統跨網溝通與互動，實現互操作性並交換資料或整合功能。核心概念如下： - 🧭 **資源**（Resources）： RESTful 系統中的每個「東西」都是一個資源，由唯一的 URL（或 URI）識別。這些通常是名詞，例如 `/users` 或 `/products/123`。 - 🛠️ **HTTP 方法**（HTTP Methods）：用於與資源互動的標準動詞，最常見方法： - 📥 **GET**： 擷取資源（安全且....等） - 📤 **POST**： 建立新資源 - 🔄 **PUT**：更新現有資源 - ❌ **DELETE** ：刪除資源 - 🧳 **無狀態性**：（Statelessness） 客戶端發送給伺服器的每個請求都包含理解該請求所需的所有資訊。伺服器不會「記住」先前的請求。 - 📦 **資料表示法**：（Data Representation）資料以機器可讀的格式傳輸，最常見的是 JSON（JavaScript Object Notation）。 值得注意的是，現代網頁瀏覽器與手機裝置（包括智慧型手機和平板電腦）都具備與 RESTful API 互動的能力，利用內建的HTTP 客戶端功能、JavaScript API、JSON 和 XML 處理、CORS（Cross-Origin Resource Sharing）安全機制等，成為構建**現代應用程式前後端**溝通的基石。 ### 🔗🔐 MCP（模型脈絡協定） 為大語言模型添加脈絡模塊，`MCP`（模型脈絡協定）有以下核心**原素**（primitives）： - 👁️‍🗨️ **提示**：**預定義範本或指令**（pre-defined templates or instructions），以指引***大語言模型互動*** - 📚 **資源**：**結構化資料或內容**（structured data or content），為模型***提供額外情境*** - 🛠️ **工具**：**可執行的函數**，允許模型***執行操作***或***檢索資訊***（perform actions or retrieve information） 這些原素構成了**客戶端**、**伺服器**和**語言模型**之間豐富互動的基礎。 ### 😵‍💫🧞‍♀️ 大語言模型的API [大語言模型](02-07-large_language_models.zh-hant)的普及，與 LLM AI 的[聊天機器人](04-02-llm_chatbots.zh-hant) 以及 API 商業模式密切相關。以 OpenAI 的 ChatGPT 為例，雲端服務透過 **Token** 作為計量單位收費，應用程式與 API 雖可分開使用，但本質上仍是「單一模型 → 單一輸入/輸出」的互動模式。 在本地端運行的 LLM（如 Meta 開源生態下的 Ollama 工具鏈）雖不需按 Token 計費，依然透過 API 與應用程式溝通，利用 URL（或 URI）識別並存取資源。然而，無論是雲端還是本地，**僅有 API 或僅有應用程式**的模式都存在幾個限制： - 📏 **上下文脈絡孤立**：API 調用往往缺乏跨請求的狀態與情境延續，難以讓模型在多步任務中保持一致性，更不能支持多輪對話。 - 🔗 **工具與數據割裂**：應用程式與外部數據源、工具之間缺乏統一的協調層，導致整合成本高、流程脆弱。 - 🧩 **多模組協作困難**：單一 API 難以同時協調多個模型驅動與非模型驅動的API服務，缺乏流程編排（orchestration）與依賴管理機制。 - 🕵️ **可觀測性不足**：缺少對 API 調用鏈路、數據流與模型決策過程的全程追蹤，降低了**可調試性**與**可信度**。要應對此問題，可參見 [智慧體可靠性與評估](10-02-agent_reliability_evaluation.zh-hant)探索相關的可靠性與評估方法。 結果就是，要不是只有「聊天機器人」這種封閉式互動，要不就是「單純 API 調用」這種點對點模式，技術融合與創新空間都受到限制，急需納入上下文脈絡（context）。這正是`MCP`**模型脈絡協定** 誕生的背景——它試圖在 LLM、工具與數據之間建立一個結構化、可編排、可觀測的協作層。 ### 🌉🔐 模型脈絡協定MCP `MCP`的核心價值在於，在於為 LLM 與多類型資源之間提供**統一的協作框架**，將模型驅動 API 以結構化方式多方整合，並在三個關鍵面向上增值： - 📦 **上下文豐富化**（Context Enrichment）： MCP 可在 API 呼叫前後注入額外任務上下文（如使用者歷史、外部資料、狀態資訊），以提升 LLM 輸出的精準度。 - 🔄 **流程編排**（Orchestration）： MCP 能定義多個 API 呼叫的順序、條件與依賴關係，形成可重複的工作流，支援 CI/CD 自動化。 - 🧩 **互操作性**（Interoperability）： MCP 提供統一的介面與協定，讓不同類型的 API 與工具能無縫協作，減少整合成本。 - 📈 **可觀測性與監控**（Observability & Monitoring）： MCP 能追蹤每次 API 呼叫的輸入、輸出與性能，便於調試與優化，特別是**智能體評價**（Agent Evaluation）。 > **小結**：MCP 是 LLM 與多工具協作的「指揮官」，確保每個模組在正確的流程時間、以正確的方式發揮作用。 ### 🗺️🤓 智能情報助理 以**MCP**的**智能代理**特性為例說明，假設我們要構建一套基於**世界銀行**（World Bank）、**國際貨幣基金組織**（IMF）、**CIA世界概況**、**OpenStreetMap**（OSM 等 API 或數據資源的**可視化智能情報助理**，將 LLM的流暢對話能力與精準數據融合，為使用者提供即時、可視化的國際情報分析。 1. 👁️🌊 **多源數據感知**： 透過 MCP 將 LLM 與多個外部 API 連接，能自動識別並擷取來自世銀、IMF、CIA、OSM 的結構化與非結構化數據，涵蓋經濟指標、地理資訊、人口統計與國家概況。（事實備註）World Bank 與 IMF 皆提供公開 REST API；CIA 世界概況可透過開放資料鏡像/ JSON 資料集取得。 2. 🫱🏼‍🫲🏿ℹ️ **交互式查詢控制**：使用者以自然語言提出問題（如「顯示巴西近五年的 GDP 與主要城市分佈」），LLM 透過 MCP 工具選擇與調用對應 API，並根據回傳數據即時調整查詢範圍與粒度。 3. 🗫🧰 **模組化數據處理**：根據不同數據類型，自動切換處理模組（經濟數據分析、地理可視化、文本摘要），確保每類數據都以最佳方式解析與呈現。 4. 🗫🗺️ **可視化與情境整合**：將經濟數據轉換為圖表，將地理數據映射到互動地圖，並將背景資訊整合成簡明的文字報告，形成多模態、上下文豐富的情報輸出。 5. 📊 **多分析型式決策支持**：允許用戶依需求進行不同類型的分析提問，並由系統自動選擇或組合對應的分析模組： * 🔵🤓📘 [描述型分析](06-04-analysis_descriptive.zh-hant)「比較東亞各國的經濟及能源使用情況？」 * 🟡😷🩺 [診斷型分析](06-01-analysis_diagnostic.zh-hant)「診斷東亞某國的經濟及能源使用問題？」 * 🟠🤠🔮 [預測型分析](06-02-analysis_predictive.zh-hant)「預測東亞各國的經濟及能源使用 5 年內的走勢？」 * 🔴🧐🧭 [指導型分析](06-03-analysis_prescriptive.zh-hant)「根據東亞某國的經濟及能源使用走勢和問題，建議採取什麼政策及能源組合轉型？」 **小結**：這種基於 MCP 的智能代理架構，能讓 LLM 不僅「會聊天」，還能「調用正確的數據源並生成可視化結果」，在國際情報、商業決策與政策分析等場景中提供高價值的即時支援。 ### 😖 主要挑戰 - 🛡️ **數據安全與可靠性：** 跨多 API 調用需處理認證、速率限制、連線穩定與來源可信度；外部服務變更（版本/模式漂移）也會影響穩定性。 - （大多可解）採用 HTTPS、金鑰輪換、帶審計的秘密管理（如 KMS）、指數退避重試、熔斷器、快取與回放機制，以及合約測試（contract testing）與模式版本化可顯著降低風險；但對第三方停機與政策變更仍屬外生風險，只能以多源備援與降級策略緩解。 - 🌐 **跨來源數據對齊：** 指標定義、時間粒度、單位與國別代碼（如 ISO 3166）常不一致，導致拼接偏差；地理資料也有投影、邊界版本差異。 - （工程上可解）建立統一詞彙表與對齊層（ontology/schema mapping）、單位正規化（含實數量綱校正）、時間對齊（freq/resampling）、國別/行政區碼映射表，以及變更日誌（changelog）可大幅降低偏差；但需持續維護成本與資料治理紀律。 - ⚡ **查詢與渲染效率：** 多 API 並行、圖表/地圖渲染與 LLM 推理疊加，易造成延遲與成本上升。 - （條件式可解）以非同步批次、請求合併、結果快取（含 CDN）、增量更新、預先匯總（pre-aggregation）、向量圖磚與流式回傳可顯著改善；但在嚴格 SLA 與高併發下，仍需橫向擴展與成本控制策略。 - 🔍 **可解釋性與透明度：** 需能追溯數據來源、轉換步驟、模型/提示版本與可視化生成邏輯，特別是在影響決策的場景。 - （大多可解）以端到端溯源（data lineage）、可觀測性（structured logging/tracing）、可再製的數據管道、輸出附帶來源註腳與版本戳（source/version stamps）可滿足多數審計需求；但對 LLM 內部推理仍非完全可解釋，只能以可控提示與決策記錄近似替代。 - ⏳ **資源與成本限制：** 模型推理成本、API 配額與付費門檻、地圖與圖表渲染資源，都會限制可用性與規模。 - （部分可解）快取、邊界條件降級（fallback to static/last-known-good）、模型選擇分層（輕量模型優先、重型模型保底）、離線預計算與成本監測來控制成本；但法規授權、商用授權與配額政策屬外部約束，需合約或升級。 - ⚖️ **授權與合規：** 不同資料/服務具備不同的授權條款，重混與再發布需審慎處理。 **小結**：解決這些挑戰，將使基於 MCP 的智能情報助理從概念驗證走向大規模應用，成為結合 LLM 對話能力與多源精準數據的強大決策支持工具。 ## 🤞❣️ 注意事項 在設計與部署 LLM AI 解決方案時，無論是採用**API 單純調用**模式，還是`API 與 MCP` **融合**的多模組協作模式，都需要留意以下關鍵風險與設計考量： - 🚫 **忽略上下文一致性**：缺乏跨請求的上下文管理，會導致 LLM 在多輪互動或多步任務中輸出不穩定、邏輯斷裂。 - ⚠️ **過度依賴單一模型驅動 API**：僅依賴 LLM 生成結果，缺乏非模型驅動 API 的確定性能力支撐，可能降低準確性與可驗證性。 - 📉 **缺乏可觀測性與監控**：沒有全程追蹤 API 調用鏈路、數據流與模型決策過程，將使問題難以及時發現、定位與修正。 - 🔍 **流程過度編排**：過於複雜的編排與依賴關係，可能增加延遲、降低韌性，並提高維護成本。 - 🛡️ **忽視授權與合規**：未檢核外部數據與 API 的授權條款，可能在再利用或跨境傳輸時引發法律與合規風險。 **小結**：在追求功能豐富與多源整合的同時，應平衡系統的簡潔性、可維護性與合規性，並建立可觀測、可追溯的協作框架。 ## 🌉 回顧與資源 - 🌟 **核心知識**：API 與 MCP 的結合是 LLM 與多工具協作的關鍵，能將模型驅動 API 與非模型驅動 API 透過結構化的上下文管理與流程編排整合起來，實現更高的互操作性與可觀測性，並支援 CI/CD 持續交付。 - 📚 **延伸閱讀**： - 📖 [RESTful API 指南](https://restfulapi.net/) — API 設計與最佳實務 - 🔗 [GraphQL 官方網站](https://graphql.org/) — 靈活的 API 查詢語言與執行環境 - 🤖 [OpenAI API](https://platform.openai.com/docs/api-reference) — 模型驅動 API 範例與文件 - 🧩 [LangChain](https://www.langchain.com/) — LLM 與工具、資料源整合框架 - 🛠️ [Temporal.io](https://temporal.io/) — 工作流與編排平台，可作為 MCP 類型協調層的參考 - 📦 [AsyncAPI](https://www.asyncapi.com/) — 事件驅動 API 的規範與工具集 **小結**：在追求功能豐富與多源整合的同時，應平衡系統的簡潔性、可維護性與合規性，並建立可觀測、可追溯的協作框架。在產品規劃與跨團隊協作中，API/MCP 的設計原則亦是 [AI 產品經理](#sec-ai-pm) 的核心考量之一。 ## 👉接下來🪸 - ⮤🚦 探究 - **5.2** ☸🛠 **[工具導向](05-02-oriented_tool.qmd)**（Tool-oriented AI） - **知識姿態**：偏向**編排性**、**模組化**與**外部資源調**用的「多工具使用」模型。 - **預設行動**：「編排」 API 調用、插件系統與工具鏈設計。 - ⮦🚦 探究 - **10.3** 🌉❔📌 [提示工程](10-03-prompt_engineering.qmd)（Prompt Engineering） * **10.4** 🌉🔗📝 [知識驅動生成（RAG）](10-04-retrieval_augmented_generation.qmd)（Retrieval-Augmented Generation） * **10.5** 🌉🪟🧭 [脈絡工程](10-05-context_engineering.qmd)（Context Engineering） * **10.6** 🎁🌱🚀 [AI 產品經理](10-06-AI_PM.qmd)（AI Product Management）