AI Agent如何调度多个工具？MCP与动态发现机制解析

当AI Agent连接了多个工具，它如何知道该调用哪个、按什么顺序调用？这是面试常见题，也是实际开发中的关键挑战。前AWS首席解决方案架构师Raj在视频中拆解了背后的机制，并指出MCP协议如何让工具调度从硬编码走向动态发现。

工具调度的基本架构：代码作为中枢

用户输入的提示词并不会直接送给大语言模型（LLM），因为LLM本身无法连接外部工具。提示词首先发送到一段代码，这段代码负责与LLM交互，并管理所有工具连接。工具通过MCP（Model Context Protocol）服务器接入，代码中运行着MCP客户端。

代码首先向每个MCP服务器发送tools/list请求，获取工具的名称、描述和输入参数模式。例如天气工具会返回：名称get_weather，描述“获取当前天气信息”，输入需要location字段（字符串类型，必填）。这个过程在运行时动态完成，无需提前硬编码。

随后，代码将用户提示词和所有工具信息一起打包，发送给LLM。LLM基于语义理解判断需要调用哪些工具，而不是依赖代码中的静态规则（如“旅行就用工具1-4”）。Raj强调：“LLM足够聪明，它基本上在做语义搜索。”

MCP（Model Context Protocol）是 Anthropic 于 2024 年底提出的开放协议，旨在统一 LLM 与外部数据源、工具之间的连接方式。它采用客户端-服务器架构：MCP 服务器封装具体能力（如访问数据库、调用 API、读取文件），以标准接口暴露工具、资源与提示模板；MCP 客户端运行在 Agent 侧代码中，负责与一个或多个服务器建立会话。协议基于 JSON-RPC 2.0 传递消息，核心方法包括 tools/list（枚举可用工具及其 JSON Schema 参数定义）、tools/call（执行指定工具并回传结果），以及用于通知能力变更的 list_changed 事件。正是这套标准化接口，使工具可以在运行时被发现和调用，而不必在代码中硬编码每个工具的签名与适配逻辑，也让不同厂商的工具能够以统一方式接入任意兼容 MCP 的 Agent。

ReAct循环：推理与行动的交替

LLM决定调用某个工具后，代码执行实际调用，并将结果返回给LLM。LLM根据新信息继续推理，可能触发下一个工具调用。例如规划纽约旅行时，LLM先调用天气工具，发现天气不错，再调用活动推荐工具获取户外活动列表，然后调用酒店价格工具比较选项。这个“推理-行动”循环（ReAct）持续进行，直到LLM认为信息足够，才将最终答案返回给用户。

这种方式的优点是灵活：添加新工具无需修改代码逻辑。但缺点也很明显——上下文膨胀。代码在每次请求时都会把所有工具的描述和参数塞进LLM的上下文，即使只有少数工具相关。Raj指出，一个100 token的提示词可能因此膨胀到1000 token，导致成本上升。

ReAct（Reasoning + Acting）是一种让语言模型交替进行推理与外部行动的提示与执行范式，由 Yao 等人在 2022 年提出。其核心是把模型的输出组织成“思考—行动—观察”的循环：模型先以自然语言推理当前状态与下一步目标，再选择一个动作（如调用工具并给出参数），执行环境返回观察结果，模型据此继续下一轮推理。与一次性生成答案相比，ReAct 允许模型在信息不足时主动获取外部信息，并在多步之间修正计划。在 Agent 实现中，这个循环通常由代码驱动：代码反复把对话历史与工具执行结果回传给 LLM，直到模型输出终止信号或达到最大步数。ReAct 的代价是每轮都要重新发送累积的上下文，轮次越多、工具描述越长，token 消耗与延迟就越高，这也是后文讨论上下文优化的重要动因。

进阶方案：基于向量检索的工具搜索

为解决上下文膨胀，更先进的方案借鉴了RAG（检索增强生成）思路。将所有工具的元信息（名称、描述、输入模式）存入向量数据库或内存，当用户提示词到来时，代码将其转换为向量，在工具库中进行语义搜索，只召回相关工具的信息发送给LLM。

例如提示词“根据天气规划纽约旅行”，语义搜索可能只召回天气、活动、酒店、税费四个工具，而忽略无关的AWS日志工具。这样LLM的上下文只包含必要工具，大幅节省token。Raj提到Claude可能使用了类似机制，称为“tool search”，但未公开存储细节。

这种方案尚未广泛采用，因为需要Agent侧额外实现。但随着工具数量增长（数百个），它变得非常有效。MCP协议本身也标准化了工具调用：通过tools/call并指定工具名和参数即可执行，简化了集成。

RAG（Retrieval-Augmented Generation，检索增强生成）指在生成之前先从外部知识库检索相关内容并拼入提示词的做法。其典型流程是：用嵌入模型把文档切块编码为向量并存入向量数据库；查询时把用户问题编码为同空间向量，通过余弦相似度或近似最近邻（ANN）索引召回最相关的若干片段，作为上下文交给 LLM。把这一思路迁移到工具选择上，就是把每个工具的名称、描述与参数模式编码成向量建立“工具索引”，用用户提示词去检索最匹配的工具子集。与文档检索不同的是，工具检索的目标是召回“能完成任务的工具”而非“包含答案的文本”，因此工具描述的质量直接影响召回效果——描述含糊的工具更容易被漏检。

实践启示与优化建议

对于开发者，Raj的建议是：如果某些工具不需要，就断开连接，避免上下文污染。同时，可以在Agent中启用追踪（tracing），观察代码与LLM之间的来回交互，理解调度顺序。未来，随着工具生态扩大，动态检索式的工具选择可能成为标配。

工具调度的本质是让LLM在运行时做决策，而非编写固定规则。MCP提供了标准化的发现和调用接口，而语义检索则优化了效率。这两者的结合，正推动AI Agent从简单任务走向复杂工作流。