本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
什麼是 MCP？
LLMs的運作方式是根據其訓練資料，預測提示的答案。這表示 LLM 只能提供已看到之資料和事件的答案。擷取增強生成 (RAG) 和知識庫等方法可讓您包含內容資料。不過，如果您要詢問 LLM 明天的天氣預測會是什麼，或資料庫中有多少客戶，則可能會幻覺或無法提供答案，因為這些情況不在 LLM 預先訓練的知識範圍內。為了能夠回答這類問題，客服人員需要存取 LLM 原生內容之外的外部功能、資料和 APIs。
了解工具
我們可以讓 LLM 透過 工具存取其他系統和內容。 工具是提供給 LLM 以達成明確目標的函數。工具可以呼叫 API、查詢資料庫、執行計算器操作、操作程式碼沙盒、執行 Web 搜尋，甚至叫用另一個 AI 系統或agent-as-a-tool。每個工具都應包含說明，告知 LLM 工具的功能、使用時機，以及接受的參數。這可讓 LLM 根據使用者的輸入，對要叫用的工具或工具組合做出細微的決策。LLM 會被告知代理程式可使用哪些工具，讓其產生回應，指示代理程式叫用該工具。例如，當您詢問 LLM 資料庫中有多少客戶時，LLM 會將回應傳回給代理程式，要求 使用特定輸入參數執行query_database工具。LLM 會決定要叫用的工具和工具呼叫的輸入。代理程式接著會執行 工具，將自然語言輸入轉換為語法上正確的函數呼叫，並執行查詢。代理程式會根據 LLM 的指示叫用工具，並將這些結果傳回 LLM。這利用 LLM 對文字型輸入進行推理，並為任務選取適當工具的能力。
下圖顯示每個代理程式如何針對每個目標管理自己的工具集。
擴展工具存取可能會為代理式 AI 解決方案帶來挑戰：
-
如果每個開發人員都為相同的外部功能建立自己的工具，則有許多重複的工作和與這些外部功能互動的非標準化方式。這會在您的客服人員之間產生不一致的實作。雖然您可以透過在程式庫中開發標準工具並分配它們來解決這個問題，但這缺乏集中式控管。這使得實施安全政策、追蹤工具用量、跨團隊管理版本控制，或確保符合組織標準變得困難。此外，當您直接將工具嵌入代理程式時，您必須在每次建立新工具或更新現有工具時重新部署代理程式。
-
提供工具給 LLM 會使用其內容視窗。內容視窗是模型可以隨時考慮的字符數量 (LLMs處理的文字單位，通常代表單字、單字部分或標點符號）。LLMs具有內容視窗限制。工具和其文件會使用該有限內容視窗，以及系統提示和使用者提示。當內容視窗填滿時，LLMs可能會因為多種因素而遇到效能降低：識別相關資訊困難、處理複雜性提高，以及推理容量降低。當工具定義、系統提示和對話歷史記錄爭奪有限內容時段空間時，挑戰會更為複雜，因為它們在每次 LLM 調用時都會提供。
因此，工具數量及其記錄方式會直接影響 LLM 的效能，例如回應時間和準確性。
MCP 建立將客服人員連線至外部功能的通用標準。它通常稱為「USB-C for AI 應用程式」。MCP 伺服器不是直接向代理程式註冊工具，而是做為透過 JSON-RPC 2.0
下圖顯示使用 MCP 存取外部資源的客服人員。
不過，MCP 標準無法解決所有擴展和控管挑戰。MCP 伺服器的實作必須與有效的工具設計、託管和企業控管策略結合。本指南提供每個策略的最佳實務，協助您建置和使用 MCP 做為代理式 AI 解決方案的一部分。
何時使用 MCP
MCP 提供策略基礎設施，以擴展您的代理式 AI 計畫。透過集中工具管理和控管，MCP 伺服器可降低跨多個代理程式建置和維護自訂整合的累積成本。這會隨著客服人員生態系統的擴展而增加回報。
在下列情況下，MCP 可能會成為您策略的一部分：
-
您需要集中控管客服人員如何存取企業系統和服務，例如資料庫、APIs、內部工具和第三方整合。
-
開發人員花太多時間撰寫跨實作不一致的自訂整合。
-
您有重複的工具，可提供常見的功能。
-
您想要透過標準化、受管的 MCP 介面，將您的專屬工具或資料提供給外部消費者或第三方代理系統，以解鎖新的收入串流，同時維護安全性和控制能力。
在您決定 MCP 伺服器將成為策略的一部分後，請評估現有的開放原始碼 MCP 伺服器實作是否符合您的需求、是否需要增強，或是否需要建置自訂伺服器。許多預先建置的 MCP 伺服器實作可在公有儲存庫中使用，涵蓋常見的功能，例如檔案系統存取、Web 瀏覽、程式碼沙盒、資料庫存取和 API 整合。
在許多情況下，預先存在的 MCP 伺服器已足夠。例如， AWS 提供 AWS MCP 伺服器受管遠端 MCP 伺服器，它為 AI 助理和客服人員提供 AWS 服務 透過自然語言互動的安全、已驗證存取。您可以使用 AWS MCP 伺服器 來執行複雜的多步驟 AWS 任務，方法為結合對 AWS 文件的即時存取、語法上更正 API 呼叫，以及遵循 AWS 最佳實務的預先建置工作流程，稱為客服人員 SOPs。 AWS 會持續測試 AWS MCP 伺服器 ，以確保客戶客服人員可以成功使用它們。
您應該使用代理程式測試這些現有的 MCP 伺服器，以判斷它們是否符合您的使用案例。如果客服人員無法完成工作流程、產生不正確或次佳的回應、無法導覽複雜的多步驟程序，或錯過重要的領域特定最佳實務或安全性考量事項，您應該考慮在幾個方面進行增強。
當現有的 MCP 伺服器無法完全滿足您的需求，且難以正確使用現有工具或產生準確的回應時，請在建置自訂伺服器之前考慮這些增強方法：
-
豐富的代理程式內容 – 如果您的代理程式難以正確或有效地使用現有 MCP 伺服器中的工具，請考慮使用其他文件或範例來補充這些工具定義。這有助於為 LLM 提供額外的內容。
-
新增補充工具 – 使用工具擴展現有的 MCP 伺服器，以存取客服人員成功完成工作流程所需的其他組織資料或內容。
-
改善基礎 APIs – 簡化您的服務 APIs，藉由降低參數複雜性、提供更清楚的錯誤訊息，以及提供客服人員可以使用的合理預設值，讓它們更易於 LLM。
雖然使用現有的 MCP 伺服器實作可加速常見功能的開發，但當您的使用案例需要特殊功能時，建置自訂 MCP 伺服器是必要的。自訂 MCP 伺服器可協助您封裝網域專業知識、強制執行組織標準、改善複雜工作流程的代理程式可靠性，以及支援安全要求的合規性。考慮在下列情況下建置自訂 MCP 伺服器：
-
特定網域的工作流程 – 當 API 文件中未擷取必要的知識時，需要網域專業知識的多步驟工作流程應該封裝在自訂 MCP 工具中。 例如，不要讓客服人員協調複雜的醫療保健資料管道，而這些管道必須驗證健康保險流通與責任法案 (HIPAA) 合規、匿名化 PII，以及轉換為 HL7 FHIR
格式，而是提供直接嵌入網域專業知識 process_patient_data的工具。這會移除 LLM 的相依性，以正確協調和執行工作流程步驟，從而提高一致性和合規性。 -
黃金路徑抽象 – 客服人員可能難以實作最佳方法，因為他們缺乏組織內容，預設為基本模式，而不是組織最佳實務。在這些案例中，您可以在自訂 MCP 工具中封裝這些黃金路徑，以強制執行成本、效能或安全性的規範性標準。例如，提供直接嵌入組織標準的工具，
deploy_secure_infrastructure而不是讓客服人員使用可能不安全或效率不佳的預設設定來部署基礎設施。 -
複雜的多服務協同運作 – 您可以確定在 MCP 工具內建置該邏輯，而不是透過嘗試推斷每個步驟中使用的正確序列和一組服務，讓代理程式協同運作複雜的工作流程。您可能也想要提供有關客服人員可能不知道的最佳服務整合模式的專業知識。 這也可以改善代理程式的準確性和效率。
-
服務特定的最佳實務 – 這適用於以安全為重心的工具，這些工具可協助客服人員實作加密政策、存取控制，以及透過客服人員工具存取服務特有的合規模式。此外，如果有不明顯的服務特定操作最佳實務，使用 MCP 伺服器可協助您確保它們已實作，且不會讓客服人員進行說明。
