AI 智能體在企業落地過程中通過 MCP 標準協議獲取數據，隨著可用的 MCP 工具越來越多，逐步達到幾十萬個 MCP 工具，甚至幾百萬個，MCP 工具通過系統提示詞注冊給大模型時候，將會導致以下兩個問題：

第一、基于系統提示的方法將所有 MCP 工具注入大模型上下文中，會導致提示詞過長且效率低下。

第二、基于檢索增強的方法通過一次性匹配用戶查詢來選擇工具，這可能導致工具選擇不準確或不充分，尤其是在多輪對話場景中。

因此需要新的架構設計來解決海量 MCP 工具，本文通過一種新的架構設計模式（簡稱：MCP-Zero）：LLM 規劃 + 按需工具庫的協同模式來解決上述問題。

MCP-Zero 的核心理念是將 LLM 從一個“無所不知”的全能工具箱轉變為一個“智能規劃者”。在這個角色下，LLM 在執行任務時，如果發現自己缺少某種能力，不會停滯不前，而是會主動、按需向外部的“工具庫”（由檢索器管理）發出請求，獲取完成當前步驟所需的特定工具，并使用它。通過不斷迭代循環，LLM 能夠逐步完成任務。

這種模式無需對 LLM 進行專門的訓練或微調來學習使用新工具。只要工具的描述被添加到工具庫中，LLM 就可以通過“提問-獲取-使用”的方式調用它，從而賦予 AI 智能體系統極高的擴展性。

下文詳細剖析之。

一、三種海量 MCP 工具選擇架構設計

三種海量 MCP 工具選擇架構設計如下圖所示：

1、架構設計方式一：系統提示詞中的 MCP 信息

讓我用一個具體的例子來說明為什么 RAG 作為記憶系統是不合適的？

將所有 MCPs（完整的工具說明書）全部注入LLM 的系統提示詞（System Prompt）中，會導致“長上下文”問題：

• 當 MCPs 數量眾多（比如：幾十萬個工具）時，輸入 LLM 的上下文會變得極為冗長。
• 這不僅會增加計算成本和延遲，還可能超出 LLM 的上下文窗口限制。
• 此外，過多的信息容易讓 LLM “困惑”，導致其性能下降，難以準確選擇正確的工具，如上圖中頭暈的機器人所示。

2、架構設計方式二：檢索增強型工具選擇

這是一種改進的架構設計方法，稱為檢索增強型工具選擇（Retrieval-Augmented Tool Selection）。當用戶提出一個查詢（Query）時，系統會通過檢索器（Retriever）在所有可用的 MCPs 中進行搜索，找到與當前查詢最相關的工具，并將其信息提供給 LLM。

這種架構設計方法在處理簡單、單步驟任務時可能有效，但對于復雜的多步驟任務就不夠用了。比如：吃西餐需要使用叉子、刀子和勺子，檢索增強型工具選擇可能在任務開始時只檢索到第一步最需要的工具（比如：叉子）。當 LLM 完成第一步后，它可能不知道接下來該做什么，因為后續步驟所需的工具（比如：刀和勺子）信息并沒有被提供。

3、架構設計方式三：MCP-Zero 新架構設計

MCP-Zero 新架構設計，它通過動態的、迭代的推理-檢索循環來實現任務的逐步解決。

• 開始：LLM（機器人）接收到用戶的初始查詢（Query）。
• 推理與請求（Reasoning & Request）：LLM 首先進行推理（用卷曲箭頭和燈泡表示），將復雜任務分解為第一步。它判斷出當前最需要的是“叉子”，于是生成一個內部請求 Fork。
• 按需檢索（On-demand Retrieval）：這個 Fork 請求被發送到 MCPs + Retriever 模塊。檢索器此時開始工作，從所有 MCPs 中精確找到“叉子”的詳細說明和用法。
• 響應與執行（Response & Execution）：檢索器將“叉子”的信息返回給 LLM。LLM 接收到信息后，知道如何使用叉子來完成第一步操作。
• 循環迭代：完成第一步后，LLM 繼續推理，發現還需要“刀子”。于是它再次發出請求 Knife，重復上述檢索-響應-執行流程。這個過程一直持續，直到它獲取并使用了所有必要的工具（叉子、刀子、勺子）。
• 完成：當所有子任務都通過這種“按需檢索”的方式完成后，整個復雜任務（吃完一頓飯）也就成功了，最終達到“Finish!”的狀態。

這張圖生動地展示了 MCP-Zero 新架構設計方法的優勢：

• 對比架構設計方式一：它避免了一次性加載所有工具信息，解決了長上下文帶來的低效和性能下降問題。其上下文是動態的、精簡的。
• 對比架構設計方式二：它不是一次性檢索，而是將任務分解，并在每一步都進行按需檢索。這使得 LLM 能夠像人一樣，逐步思考和行動，從而完成需要多個工具協作的復雜任務，解決了“一次檢索不夠用”的問題。

因此，MCP-Zero 架構設計方法的核心是一種“讓 LLM 進行規劃，讓檢索器提供執行輔助”的協同工作模式。LLM 負責高級推理和任務分解，而檢索器作為外部知識庫，在需要時為其提供精確、即時的工具信息，從而實現高效、準確且可擴展的零樣本（Zero-shot）任務自動化。

二、MCP-Zero 新架構設計案例剖析

1、代碼調式任務案例剖析（如下圖所示）：

• 用戶向 LLM Agent 發出了一個指令：Debug my code: 'src/train.py'
• 整個過程分為三個清晰的階段，每個階段都是一個完整的“請求-檢索-執行”循環。

2、階段一：讀取文件

思考與請求：LLM 接收到用戶的指令后，首先分析任務需求。它意識到：“好的，我要修復代碼。首先，我需要讀取這個文件。” 接著，它將這一需求轉化為一個具體的工具請求，放入 ??<tool_assistant> ??標簽中，明確指出需要一個來自“文件系統（File system）”服務器的工具，該工具能夠“按文件名讀取文件(Read file by filename)”。

檢索：語義匹配模塊接收到這個描述后，迅速在工具庫中進行匹配，找到了 ??read_file ???這個工具。它在 ??<tool_response> ???中返回了該工具的正式定義，包括工具名以及所需的參數 ??path??。

執行：LLM 現在清楚了如何使用這個工具。它構建了一個 ??<function_call>???，調用 ??read_file???，并傳入正確的參數 ??path="src/train.py"??。

獲取結果：系統執行了該調用，并在 ??<function_call_response> ???中返回了??src/train.py ??文件的實際內容。

3、階段二：修復代碼

思考與請求：在分析了文件內容后，LLM 找到了問題所在。它意識到：“很好，我找到問題了，現在需要修改代碼。” 為了實現這一目標，它需要一個新的工具能力：編輯文件。于是，它生成了一個新的  ??<tool_assistant>??  請求，明確指定了需要一個能夠“用新字符串編輯目標文件（Edit target file with new string）”的工具。

檢索與執行：系統再次啟動檢索流程，找到了  ??edit_file ??? 工具。LLM 隨即調用該工具，并傳入必要的參數（比如：文件路徑和修改后的新代碼內容，具體內容在圖中用 ??...?? 省略）。

獲取結果：系統執行了文件修改操作，并確認文件已被成功更新。

4、階段三：驗證修復

思考與請求：代碼已經修改完成，但任務尚未結束。AI 智能體需要驗證修復是否有效。它心想：“最后，我來運行一下代碼，看看問題是否解決了。” 這需要來自另一個領域的工具能力：在終端中運行命令。于是，它生成了一個 ??<tool_assistant>?? 請求，明確指定了需要一個來自“終端環境（Terminal environment）”的工具，用于“運行命令并獲取返回值（Run command and get return value）”。

檢索與執行：AI 智能體檢索到 ??run_cmd??? 工具。LLM 接著調用這個函數，命令很可能是 ??python src/train.py??。

獲取結果：AI 智能體執行該命令并返回輸出。假設代碼成功運行且沒有報錯，AI 智能體便可以確認 Bug 已經修復。

最終匯報：LLM 向用戶匯報最終結果：“Great! The bug is now fixed :)"（太棒了！Bug 已經修復了 :)）。

MCP-Zero 新架構設計方法的優勢

第一、逐步與迭代（Progressive & Iterative）

MCP-Zero 不是一次性解決問題，而是將任務分解為多個步驟，逐步推進。這種分步解決的方式使得任務更加清晰，也更容易管理。

第二、識別能力差距（Identifies Capability Gaps）

在每一步（讀文件、改文件、運行代碼），LLM 都能意識到自身需要一個外部工具來彌補能力不足。這種自我認知使得 LLM 能夠主動請求所需的工具，而不是被動等待。

第三、按需請求（On-demand Requests）

LLM 只在需要時才請求工具。比如：它只在讀完文件后才去尋找 ??edit_file??? 工具；只在改完文件后才去尋找 ??run_cmd?? 工具。這種方式不僅高效，還避免了不必要的上下文開銷。

第四、跨領域（Across Three Domains）

MCP-Zero 無縫地使用了來自不同“服務器”或環境的工具（文件系統和終端），展示了該方法的靈活性和通用性。這種跨領域的工具調用能力使得 LLM 能夠處理復雜的多步驟任務。

三、MCP-Zero 新架構設計總結

MCP-Zero 的新架構設計理念十分精妙：它并沒有將 LLM 視作一個需要熟記所有工具使用方法的“全能技工”，而是將其塑造為一位“智慧的總規劃師”。在執行任務的過程中，這位規劃師會啟動一個動態的、迭代式的“思考-請求-執行”循環：

• 對任務進行拆解，精準識別出完成當前步驟所需的關鍵能力，比如“讀取文件”；
• 主動生成按需請求，用自然語言清晰描述所需工具的類型與功能；
• 外部檢索器依據請求，在龐大的工具庫中精準檢索并返回對應工具的使用說明；
• LLM 調用該工具，順利推進當前步驟；
• 循環往復，直至將復雜任務逐步攻克，最終達成目標。

它巧妙地攻克了兩大核心難題：

• 破解“長上下文”瓶頸：摒棄傳統的一次性加載所有工具信息的做法，轉而采用按需檢索，大幅削減了計算成本與延遲，有效規避了因上下文過長引發的性能損耗，確保 LLM 能始終聚焦于手頭的任務。
• 化解“一次檢索局限”：憑借迭代循環機制，賦予 LLM 處理多工具、多步驟復雜任務的能力，完美彌補了傳統檢索增強方法在多步任務場景下易“卡殼”的短板。

本文轉載自???玄姐聊AGI??  作者：玄姐