在过去两年里，RAG 几乎成为 AI 应用的标准配置。它解决了一个核心问题：让模型能够找到信息。

但当系统开始接入越来越多工具时，一个新的问题开始出现：模型不仅需要找到信息，还需要找到正确的****能力。

在一个真实的 AI 工程团队中，他们为开发 Agent 接入了 120 个工具接口。这些工具几乎覆盖了所有开发任务：代码搜索、日志分析、数据库查询、CI 触发等。理论上，这个 Agent 的能力已经非常强。

但在一次调试中，团队发现了一件非常奇怪的事情。

用户提出一个简单请求：“找到这个函数在哪个文件里。” Agent 连续调用了 17 次工具，却始终没有选择正确的能力。它先尝试了日志查询，然后调用数据库检索，甚至触发了一次 CI 流程。真正需要的能力其实只有一个：代码搜索。

这个案例后来在团队内部被反复讨论，因为它揭示了一个非常反直觉的现象：Agent 的能力越多，错误率反而越高**。**

当一个 Agent 从 5 个工具扩展到 50 个、100 个工具时，系统通常会出现几个典型问题：

• LLM 开始频繁选错工具
• Tool Call 成功率明显下降
• 推理 Token 成本快速上升
• 系统延迟明显变慢

换句话说：Agent 的问题，往往不是不会用工具，而是不知道该用哪个工具。

这正是 Harness 在其 AI 工程系统中重点解决的问题之一：Tool Router**。**

如果用一句话来理解它的作用：RAG 让模型学会找「信息」，而 Tool Router 让模型学会找「能力」****。

一、Tool Explosion：Agent 的第一个规模问题

在真实系统中，工具数量的增长几乎是不可避免的。

原因很简单：Agent 的能力并不是内置在模型里的，而是通过工具接口提供的。

当系统能力不断增加时，工具数量也会持续增长。最初可能只有几个能力接口，例如代码搜索、日志查询或数据库访问。但随着系统复杂度提升，很快就会扩展到几十甚至上百个工具。

这种能力规模的快速膨胀，在工程领域通常被称为：Tool Explosion。

当系统进入这个阶段之后，问题就不再只是“模型是否聪明”，而是系统结构是否合理。因为当工具数量达到几十甚至上百个时，模型面对的已经不再是简单选择，而是一个 巨大的****能力空间。

二、Agent 的规模问题：能力搜索问题

从系统角度来看，Agent 的执行流程其实非常简单。

用户提出一个请求，系统需要完成两件事：首先确定应该使用哪种能力，其次执行这个能力。

在工具数量很少的时候，这个决策非常简单。但当工具数量不断增加时，问题会逐渐发生变化。

工具选择不再只是推理问题，而开始演变为一个 搜索问题。

模型需要在一个庞大的能力集合中找到最相关的一项。

这也是为什么很多 Agent 系统在工具数量增加后会迅速变得不稳定。问题并不在模型，而在系统结构。

从工程角度看，这其实是一个非常典型的问题：Agent 的规模问题，本质上是能力搜索问题。

三、Harness 的角色：管理 Agent 的能力空间

在真实的 AI 工程系统中，模型通常不会直接与所有工具交互。中间往往存在一个执行层，用来管理系统能力、调度工具调用，并控制整个执行流程。这个执行层在很多系统中被称为 Harness。

Harness 的职责并不是做推理，而是负责 管理能力接口。

当工具数量很少时，Harness 的角色并不明显。但随着系统能力不断扩展，一个新的问题就会逐渐出现：模型能够看到的能力空间正在迅速膨胀。

如果所有工具都直接暴露给模型，系统复杂度会很快失控。模型不仅需要阅读大量工具描述，还必须在这些能力之间做出正确选择。

因此 Harness 需要承担一个新的职责：控制模型能够看到的能力空间**。**

为了解决这个问题，很多 AI 工程系统都会引入一个新的组件：Tool Router**。**

四、Tool Router：能力检索系统

Tool Router 的核心思想其实非常简单：不要让 LLM 直接面对全部工具**。**

在模型进行决策之前，系统会先筛选出一小部分候选能力，再交给模型进行最终选择。整个流程变成：

User Query
↓
Tool Router
↓
Candidate Tools
↓
LLM Tool Selection

从系统结构上看，这其实是一种 两阶段决策****结构。

第一阶段由 Router完成，它负责在大量能力接口中进行初步筛选。

第二阶段由模型完成，它负责在候选能力中进行最终选择。

如果从信息检索的角度来看，这个结构其实非常熟悉：

Recall
↓
Ranking

Router 负责 Recall，而 LLM 负责 Ranking。

换句话说，Tool Router 本质上是一个能力检索系统。

在早期的 LLM 应用中，RAG 被认为是最重要的基础设施，因为它解决了模型无法访问外部知识的问题。但随着 Agent 系统的发展，另一个问题逐渐浮现：模型并不缺信息，而是缺能力。

RAG 让模型学会找「信息」，而 Tool Router 让模型学会找「能力」。

五、Harness 的三层 Tool Router 架构

在真实工程系统中，Tool Router 通常不会只依赖一次检索，而是采用 分层路由****结构。

这样做的原因很简单：当能力规模达到上百个时，单次检索往往不够稳定。

一个常见的设计是三层路由结构。

第一层负责识别用户意图。例如用户提出“查询昨天销售额”，系统首先需要判断这是一个数据查询任务，而不是文档搜索或通信任务。这一层通常使用轻量模型或 embedding 相似度完成，可以在几十毫秒内完成判断。

第二层负责能力分组筛选。在大多数企业系统中，工具通常会按照领域进行组织，例如数据工具、搜索工具、CRM 工具或 DevOps 工具。当系统识别出用户意图之后，就可以快速过滤掉大量不相关的能力接口。 例如在一个拥有 100 个工具的系统中，这一步往往可以将候选能力减少到 10 个左右。

第三层是语义召回。在选定的工具组内部，Router 会根据语义相似度召回最相关的几个工具。常见做法是为每个工具生成 embedding，并通过向量搜索找到最匹配的能力接口。最终返回的候选工具通常只有 3 到 5 个。

此时模型需要面对的能力空间已经从最初的 100 个工具缩小到了几个候选项，选择难度也大幅降低。

六、Tool Router 的工程实现

从工程角度看，Tool Router 往往是一个独立的系统组件，而不是简单的函数调用。

在很多生产系统中，Router 会以服务形式存在，并与工具注册系统和向量索引协同工作。一个典型结构通常包括三个部分：Tool Registry、Tool Embeddings 和 Router Service。

Tool Registry 用来维护系统中所有工具的定义，包括名称、描述、权限信息以及调用方式。Router Service 在运行时会从 Registry 中读取工具信息，并为这些能力生成语义表示。

为了进行语义检索，每个工具通常会被转换为一个 embedding。这个 embedding 往往由工具名称、功能描述以及使用示例组合生成。例如：

embedding(tool) =
tool_name
+ description
+ usage_examples
+ tags

这样，当用户请求到来时，Router 可以将 Query 转换为 embedding，并在工具向量空间中找到最相关的能力接口。

在实际系统中，Router 通常不会只返回一个工具，而是会召回一个候选集合，例如 Top-5 或 Top-8 工具。随后再由 LLM 在这些候选能力中进行最终选择。这种设计既能提高准确率，又可以保持系统稳定性。

七、Tool Router：LLM 时代的 API Gateway

如果从系统架构的角度来看，Tool Router 的角色其实非常类似于传统系统中的 API Gateway。

在微服务架构中，API Gateway 负责管理和调度大量服务接口，并控制客户端能够访问哪些能力。

而在 Agent 系统中，Tool Router 正在承担类似的职责。

模型本身并不直接执行任务，而是通过 API 调用系统能力。从这个角度来看，一个 Agent 的能力其实就是一组 可调用的 API 接口集合。

随着系统能力不断扩展，工具接口也会持续增长。如果没有一个能力管理层，模型很快就会被海量接口淹没。

Tool Router 正是这一层能力管理系统。

它位于模型与工具之间，负责筛选和管理系统能力，并确保模型始终在一个可控的能力空间中运行。

因此可以说：Tool Router，本质上是 LLM 时代的 API Gateway。

八、从 RAG 到 Tool Router：Agent 系统的下一层基础设施

在早期的 LLM 应用中，RAG 被认为是最重要的基础设施，因为它解决了模型无法访问外部知识的问题。

通过检索外部文档，模型可以突破训练数据的限制，从而获得更强的信息获取能力。

但随着 Agent 系统不断发展，问题开始发生变化。

模型面临的挑战不再只是：如何找到正确的信息。

而是：如何找到正确的能力。

如果说 RAG 扩展的是模型的知识边界，那么 Tool Router 扩展的则是模型的能力边界。

大规模 Agent 系统，需要同时包含这两层结构：

• RAG 负责信息检索
• Tool Router 负责能力调度。

最后

当 Agent 只拥有少量工具时，模型可以直接完成工具选择。

但随着系统能力不断扩展，工具数量很快会增长到几十甚至上百个。此时系统面临的问题已经不再只是「推理」，而是「能力搜索」问题。

Tool Router 的出现，本质上是在 Harness 中引入一层能力管理机制。通过控制模型能够看到的能力空间，系统才能在拥有大量能力的情况下仍然保持稳定运行。

换句话说：

模型决定 Agent 的能力上限，而****Tool Router 决定 Agent 是否能正确使用这些能力。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】