AI 智能體在企業(yè)落地過程中通過 MCP 標(biāo)準(zhǔn)協(xié)議獲取數(shù)據(jù)，隨著可用的 MCP 工具越來越多，逐步達(dá)到幾十萬個(gè) MCP 工具，甚至幾百萬個(gè)，MCP 工具通過系統(tǒng)提示詞注冊給大模型時(shí)候，將會導(dǎo)致以下兩個(gè)問題：

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

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

因此需要新的架構(gòu)設(shè)計(jì)來解決海量 MCP 工具，本文通過一種新的架構(gòu)設(shè)計(jì)模式（簡稱：MCP-Zero）：LLM 規(guī)劃 + 按需工具庫的協(xié)同模式來解決上述問題。

MCP-Zero 的核心理念是將 LLM 從一個(gè)“無所不知”的全能工具箱轉(zhuǎn)變?yōu)橐粋€(gè)“智能規(guī)劃者”。在這個(gè)角色下，LLM 在執(zhí)行任務(wù)時(shí)，如果發(fā)現(xiàn)自己缺少某種能力，不會停滯不前，而是會主動、按需向外部的“工具庫”（由檢索器管理）發(fā)出請求，獲取完成當(dāng)前步驟所需的特定工具，并使用它。通過不斷迭代循環(huán)，LLM 能夠逐步完成任務(wù)。

這種模式無需對 LLM 進(jìn)行專門的訓(xùn)練或微調(diào)來學(xué)習(xí)使用新工具。只要工具的描述被添加到工具庫中，LLM 就可以通過“提問-獲取-使用”的方式調(diào)用它，從而賦予 AI 智能體系統(tǒng)極高的擴(kuò)展性。

下文詳細(xì)剖析之。

一、三種海量 MCP 工具選擇架構(gòu)設(shè)計(jì)

三種海量 MCP 工具選擇架構(gòu)設(shè)計(jì)如下圖所示：

1、架構(gòu)設(shè)計(jì)方式一：系統(tǒng)提示詞中的 MCP 信息

讓我用一個(gè)具體的例子來說明為什么 RAG 作為記憶系統(tǒng)是不合適的？

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

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

2、架構(gòu)設(shè)計(jì)方式二：檢索增強(qiáng)型工具選擇

這是一種改進(jìn)的架構(gòu)設(shè)計(jì)方法，稱為檢索增強(qiáng)型工具選擇（Retrieval-Augmented Tool Selection）。當(dāng)用戶提出一個(gè)查詢（Query）時(shí)，系統(tǒng)會通過檢索器（Retriever）在所有可用的 MCPs 中進(jìn)行搜索，找到與當(dāng)前查詢最相關(guān)的工具，并將其信息提供給 LLM。

這種架構(gòu)設(shè)計(jì)方法在處理簡單、單步驟任務(wù)時(shí)可能有效，但對于復(fù)雜的多步驟任務(wù)就不夠用了。比如：吃西餐需要使用叉子、刀子和勺子，檢索增強(qiáng)型工具選擇可能在任務(wù)開始時(shí)只檢索到第一步最需要的工具（比如：叉子）。當(dāng) LLM 完成第一步后，它可能不知道接下來該做什么，因?yàn)楹罄m(xù)步驟所需的工具（比如：刀和勺子）信息并沒有被提供。

3、架構(gòu)設(shè)計(jì)方式三：MCP-Zero 新架構(gòu)設(shè)計(jì)

MCP-Zero 新架構(gòu)設(shè)計(jì)，它通過動態(tài)的、迭代的推理-檢索循環(huán)來實(shí)現(xiàn)任務(wù)的逐步解決。

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

這張圖生動地展示了 MCP-Zero 新架構(gòu)設(shè)計(jì)方法的優(yōu)勢：

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

因此，MCP-Zero 架構(gòu)設(shè)計(jì)方法的核心是一種“讓 LLM 進(jìn)行規(guī)劃，讓檢索器提供執(zhí)行輔助”的協(xié)同工作模式。LLM 負(fù)責(zé)高級推理和任務(wù)分解，而檢索器作為外部知識庫，在需要時(shí)為其提供精確、即時(shí)的工具信息，從而實(shí)現(xiàn)高效、準(zhǔn)確且可擴(kuò)展的零樣本（Zero-shot）任務(wù)自動化。

二、MCP-Zero 新架構(gòu)設(shè)計(jì)案例剖析

1、代碼調(diào)式任務(wù)案例剖析（如下圖所示）：

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

2、階段一：讀取文件

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

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

執(zhí)行：LLM 現(xiàn)在清楚了如何使用這個(gè)工具。它構(gòu)建了一個(gè) ??<function_call>???，調(diào)用 ??read_file???，并傳入正確的參數(shù) ??path="src/train.py"??。

獲取結(jié)果：系統(tǒng)執(zhí)行了該調(diào)用，并在 ??<function_call_response> ???中返回了??src/train.py ??文件的實(shí)際內(nèi)容。

3、階段二：修復(fù)代碼

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

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

獲取結(jié)果：系統(tǒng)執(zhí)行了文件修改操作，并確認(rèn)文件已被成功更新。

4、階段三：驗(yàn)證修復(fù)

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

檢索與執(zhí)行：AI 智能體檢索到 ??run_cmd??? 工具。LLM 接著調(diào)用這個(gè)函數(shù)，命令很可能是 ??python src/train.py??。

獲取結(jié)果：AI 智能體執(zhí)行該命令并返回輸出。假設(shè)代碼成功運(yùn)行且沒有報(bào)錯(cuò)，AI 智能體便可以確認(rèn) Bug 已經(jīng)修復(fù)。

最終匯報(bào)：LLM 向用戶匯報(bào)最終結(jié)果：“Great! The bug is now fixed :)"（太棒了！Bug 已經(jīng)修復(fù)了 :)）。

MCP-Zero 新架構(gòu)設(shè)計(jì)方法的優(yōu)勢

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

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

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

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

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

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

第四、跨領(lǐng)域（Across Three Domains）

MCP-Zero 無縫地使用了來自不同“服務(wù)器”或環(huán)境的工具（文件系統(tǒng)和終端），展示了該方法的靈活性和通用性。這種跨領(lǐng)域的工具調(diào)用能力使得 LLM 能夠處理復(fù)雜的多步驟任務(wù)。

三、MCP-Zero 新架構(gòu)設(shè)計(jì)總結(jié)

MCP-Zero 的新架構(gòu)設(shè)計(jì)理念十分精妙：它并沒有將 LLM 視作一個(gè)需要熟記所有工具使用方法的“全能技工”，而是將其塑造為一位“智慧的總規(guī)劃師”。在執(zhí)行任務(wù)的過程中，這位規(guī)劃師會啟動一個(gè)動態(tài)的、迭代式的“思考-請求-執(zhí)行”循環(huán)：

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

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

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

本文轉(zhuǎn)載自???玄姐聊AGI??  作者：玄姐