本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 工具範圍
開發工具的方法有兩種：精細和粗粒。
## 精細
在精細的方法中，您會為每個 API、動作或查詢建立工具。例如，您可以為 Git `get_issue`儲存庫建立 `create_issue`、`assign_issue`、、 `add_label`和 `close_issue`工具。這可讓 LLM 對每個 API 進行精細呼叫，並視需要協調每個 API。請考慮以下提示：「為名為「僅查詢傳回部分結果」的產品服務建立問題，將其標記為錯誤和高優先順序，並將其指派給 Alice。」 下圖顯示每個 tool-per-API方法如何回應此提示。
在此方法中，系統提示和每個已註冊的工具定義會在每次呼叫時提供給 LLM。這會消耗額外的內容並產生延遲懲罰，因為每個工具呼叫都代表對 LLM 的個別呼叫。它也會增加在工作流程中處理錯誤的複雜性。
## 粗粒
粗略精細或*工作流程驅動*的方法將是工作流程導向的工具。此工具著重於end-to-end使用者對 API 結構的意圖。您有一個工具可確定地呼叫許多 APIs，而不是tool-per-API 的工具。使用先前的 Git 儲存庫範例，您可以建立由代理程式呼叫一次`create_and_setup_issue`的工具。工具實作會根據提供給工具的參數，建立問題、新增標籤，並將其指派給使用者。下圖顯示粗粒方法如何處理相同的提示。
此方法顯示 LLM 層如何隱藏所有複雜性。當協同運作邏輯內嵌在工具實作中時，工具中會決定性地執行所有循序步驟、記錄、重試邏輯、斷路器和速率限制。工作流程驅動型方法可讓 LLM 更輕鬆地使用正確的參數叫用正確的工具。請務必注意，某些 APIs可能已經提供工作流程意圖，例如 Amazon EC2 `RunInstances` API。在這些情況下，tool-per-API可能會提供您想要的工作流程導向設計。
不過，工具也可能變得太粗粒。如果您的單一工作流程工具嘗試執行太多動作，並且有許多可能的參數，則 LLM 可能會難以推理如何正確使用工具。它也可以透過參數選擇和錯誤處理來產生挑戰。因此，工具開發必須達到與使用者意圖一致的平衡，並避免在單一工具中功能太少或太多。我們建議您根據完整的使用者工作流程設計工具，綁定通常一起發生的操作 （例如三個或更多的 API 呼叫）。我們也建議您分解超過八個或更多參數的工具，或處理多個不同的使用者意圖。使用實際提示 進行測試，以確認客服人員是否可以正確使用每個工具。
如果您有複雜且動態的工作流程，無法輕鬆封裝為決定性工具，您可以考慮使用*agent-as-tool模式*。專門的代理程式可以做為工具，而不是您的主要代理程式嘗試在工作流程中協調複雜的任務。這些類型的工具可以實作進階決策和分支，而且可以處理無法在確定性程式碼中輕鬆管理的錯誤和重試邏輯。這類似於但不同於 [Agent2Agent (A2A) 通訊協定](https://a2a-protocol.org/latest/)。A2A 通訊協定是互補的，可在任何代理架構中的代理程式之間提供互通性和協同合作。
我們建議您從工作流程分析開始，映射最常見的使用者工作流程，以識別每個客服人員所需的核心功能。這會建立您的最低可行工具集。根據我們大規模開發 MCP 伺服器的經驗，我們建議下列實務。當這些實務發生衝突時，請優先考慮使用者意圖和工作流程**。**
## MCP 工具範圍的最佳實務
+ **思考使用者案例並綁定常見操作** – 工具應直接映射以完成使用者互動，而不是需要協調多個操作。如果工作流程通常需要三個以上的個別呼叫，請將它們合併為單一工具。這可減少 LLM 的認知負載、將工具呼叫次數降至最低、減少完成任務所需的內容耗用和延遲，並改善準確性和延遲。
+ 將**參數限制為八個或更少 – **如果工具超過八個參數，請將它分解為多個工具。隨著複雜性的增加，LLMs難以選擇參數。
**注意**
如果綁定操作需要超過八個參數，請優先於參數計數的綁定，因為簡化工作流程比嚴格的參數限制更有價值。
+ **個別的讀取和寫入操作 – **提供不同的工具來讀取資料並進行修改。當客服人員執行潛在破壞性操作、啟用不同的授權政策，並降低在資訊收集期間意外修改的風險時，這種區隔會使其明確。
+ **提供合理的預設值 – **設計工具，讓 LLM 只需要指定個別請求特有的參數。預設值可降低 LLM 必須考量的資訊，藉此降低參數複雜性並改善工具選擇的準確性。
+ **偏好確定性執行 – **盡可能讓工具執行和輸出確定性。確定性工具更可靠且更容易測試。對於需要智慧型協同運作、分支邏輯或進階錯誤處理的複雜工作流程，如果無法在確定性程式碼中輕鬆管理，請考慮使用專用代理程式做為工具。不過，請選擇性地使用此模式，因為它會增加複雜性。