AI 智能体在企业落地过程中通过 MCP 标准协议获取数据，随着可用的 MCP 工具越来越多，逐步达到几十万个 MCP 工具，甚至几百万个，MCP 工具通过系统提示词注册给大模型时候，将会导致以下两个问题：

第一、基于系统提示的方法将所有 MCP 工具注入大模型上下文中，会导致提示词过长且效率低下。

第二、基于检索增强的方法通过一次性匹配用户查询来选择工具，这可能导致工具选择不准确或不充分，尤其是在多轮对话场景中。

因此需要新的架构设计来解决海量 MCP 工具，本文通过一种新的架构设计模式（简称：MCP-Zero）：LLM 规划 + 按需工具库的协同模式来解决上述问题。

MCP-Zero 的核心理念是将 LLM 从一个“无所不知”的全能工具箱转变为一个“智能规划者”。在这个角色下，LLM 在执行任务时，如果发现自己缺少某种能力，不会停滞不前，而是会主动、按需向外部的“工具库”（由检索器管理）发出请求，获取完成当前步骤所需的特定工具，并使用它。通过不断迭代循环，LLM 能够逐步完成任务。

这种模式无需对 LLM 进行专门的训练或微调来学习使用新工具。只要工具的描述被添加到工具库中，LLM 就可以通过“提问-获取-使用”的方式调用它，从而赋予 AI 智能体系统极高的扩展性。

下文详细剖析之。

1.三种海量 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）任务自动化。

2.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 能够处理复杂的多步骤任务。

3.MCP-Zero 新架构设计总结

MCP-Zero 的新架构设计理念十分精妙：它并没有将 LLM 视作一个需要熟记所有工具使用方法的“全能技工”，而是将其塑造为一位“智慧的总规划师”。在执行任务的过程中，这位规划师会启动一个动态的、迭代式的“思考-请求-执行”循环：

• 对任务进行拆解，精准识别出完成当前步骤所需的关键能力，比如“读取文件”；

• 主动生成按需请求，用自然语言清晰描述所需工具的类型与功能；

• 外部检索器依据请求，在庞大的工具库中精准检索并返回对应工具的使用说明；

• LLM 调用该工具，顺利推进当前步骤；

• 循环往复，直至将复杂任务逐步攻克，最终达成目标。

它巧妙地攻克了两大核心难题：

• 破解“长上下文”瓶颈：摒弃传统的一次性加载所有工具信息的做法，转而采用按需检索，大幅削减了计算成本与延迟，有效规避了因上下文过长引发的性能损耗，确保 LLM 能始终聚焦于手头的任务。

• 化解“一次检索局限”：凭借迭代循环机制，赋予 LLM 处理多工具、多步骤复杂任务的能力，完美弥补了传统检索增强方法在多步任务场景下易“卡壳”的短板。