**摘要：**

Agent 能力越来越多以后，一个很现实的问题开始出现：

**到底该调用哪个 Tool、加载哪个 Skill、连接哪个 MCP？**

5 个工具时，让 LLM 自己选可能没什么问题。

但当能力数量变成 50 个、100 个甚至更多，路由本身就开始成为 Agent Harness 的核心问题。

而 Jev 这类 Decision Model，正在尝试接管其中一部分工作。

---

## 一、Agent 的问题，开始从“没能力”变成“能力太多”

早期做 Agent，大家最关心的是：

> 怎么给模型增加能力？

所以我们不断往里面加：

```text
Tool
MCP
Skill
Subagent
知识库
浏览器
数据库
代码执行
```

但当这些能力越来越多以后，新的问题来了：

**Agent 到底该选哪个？**

比如一个测试 Agent 同时拥有：

```text
Playwright Skill
Appium Skill
接口测试 Skill
SQL Skill
日志分析 Skill
性能测试 Skill
安全测试 Skill

GitHub MCP
Jira MCP
禅道 MCP
数据库 MCP

浏览器
Shell
Python
HTTP Client
```

用户说一句：

> 帮我看看今天支付接口为什么失败这么多。

Agent 首先要解决的并不是：

**怎么分析问题。**

而是：

**这次任务到底应该加载哪些能力？**

这就是 **Agent Routing**。

---

## 二、为什么不能把所有 Tool 都直接塞给 LLM？

最简单的方案当然是：

```text
用户任务
↓
所有 Tool / Skill / MCP 描述
↓
LLM
↓
选择能力
```

工具少的时候没什么问题。

但随着能力增加，会出现三个问题。

### 1. 上下文越来越重

50 个 Tool，每个都有：

名称、描述、参数、Schema、使用限制。

全部塞进 Prompt，本身就会消耗大量 Context。

### 2. 选择空间越来越大

工具越多，名称和功能越容易接近。

比如：

```text
search_web
search_docs
search_code
search_database
search_logs
```

模型不仅要理解用户需求，

还要重新理解几十个工具的区别。

### 3. 路由错误会向后放大

如果第一步 Skill 就选错了：

后面的 Planning、Tool Call、Context 都可能跟着错。

所以很多 Agent 做到一定规模以后都会发现：

**Routing 不再只是一个 Prompt，而是一个独立的工程模块。**

---

## 三、Jev 为什么特别适合被拿来做 Routing？

这恰好是 Jev 比较擅长的问题。

Vercel 在 Jev 上线 AI Gateway 时，列出的第一个典型场景就是：

**选择 Agent 下一步使用的 Tool 或 Subagent。**

因为路由本质上很像：

```text
当前状态
+
有限候选集合
↓
选择哪个？
```

比如：

```text
用户任务：
分析支付接口失败原因

候选能力：

日志分析 Skill：82%
接口测试 Skill：71%
SQL Skill：36%
Playwright Skill：4%
```

程序可以根据概率：

先筛出两个候选，

再交给 Agent 继续处理。

Jev 的一个特点就是：它直接返回 **Choice、Score、Boolean 以及对应概率**，而不是先生成一段自然语言再让程序解析。Vercel 目前也把 Jev 定位在 classification、routing、scoring 和 verification 这类结构化决策任务中。 

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/c569bc94756edfe6323be7b0d34266c0.png)

---

## 四、但 Jev 也不能直接解决所有 Routing 问题

这里特别容易产生一个误区：

> 有了 Jev，以后 500 个 Tool 全部扔进去让它选就行。

并不是。

真正的大规模 Agent Routing，至少应该拆成三步。

### 第一层：规则和元数据过滤

先处理确定性条件。

比如：

```text
用户没有数据库权限
→ 直接排除数据库 Tool

任务是移动端测试
→ 优先保留 App 相关 Skill

当前环境没有浏览器
→ 排除 Playwright
```

这些事情根本不需要 AI。

---

### 第二层：Decision Model 做候选路由

经过第一轮筛选以后：

```text
100 个能力
↓
剩 15 个候选
```

再让 Jev 进行：

```text
分类
评分
路由
```

例如选出 Top 3：

```text
日志分析：91%
接口测试：84%
SQL 查询：62%
```

这一层解决的是：

**哪些能力最值得进入下一步。**

---

### 第三层：LLM 做复杂选择和执行

到了最后：

```text
日志分析 Skill
接口测试 Skill
SQL Skill
```

LLM 再根据完整上下文决定：

先调用谁？

参数是什么？

调用结果意味着什么？

下一步做什么？

这才是复杂推理真正应该发挥作用的地方。

---

## 五、未来比较合理的 Agent Routing，可能是三级架构

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/4f8ba9f9b1362545bb278fcb4644e024.png)


这其实也是我们前面一直在讨论的：

**智能分层。**

确定性问题，不需要模型。

高频判断，不一定需要最强模型。

真正复杂的问题，再调用 LLM。

Vercel 对 Jev 在 Agent Loop 中的建议也类似：让 Jev 位于明确的决策点，负责选择下一步或检查拟执行动作；Tool 执行和权限策略仍放在应用代码中，而生成式模型继续负责复杂解释和响应。 

---

## 六、Tool Routing 和 Skill Routing 其实还有一点不同

这里还有个很值得 Agent 工程师注意的问题。

### Tool Routing 更像：

> **下一步我要调用什么？**

比如：

```text
浏览器
数据库
搜索
HTTP
Shell
```

它通常发生在 Agent Loop 中。

### Skill Routing 更像：

> **当前任务需要加载哪些专业能力？**

比如测试支付系统：

```text
接口测试 Skill
日志分析 Skill
SQL Skill
```

Skill Routing 往往发生得更早。

它甚至可以决定：

**这次 Agent 到底应该看到哪些 Tool。**

所以更成熟的架构可能是：

```text
用户任务
↓
Skill Routing
↓
加载对应能力
↓
缩小 Tool 空间
↓
Tool Routing
↓
执行
```

这样做还有一个额外好处：

**Context 会明显变干净。**

---

## 七、从测试角度看，Routing 本身也要测

当 Routing 变成独立系统以后，它自然也会变成新的测试对象。

比如：

### Top-K 命中率

真正需要的 Skill，有没有进入 Top 3？

### 错路由率

Web 测试任务，有多少被错误送进 Appium Skill？

### 路由稳定性

同一类任务换一种说法：

```text
测试登录页面

帮我检查登录功能

看看登录有没有 Bug
```

最终路由是否基本一致？

### 能力增加后的回归

原来系统只有 20 个 Skill。

增加第 21 个以后：

**旧任务的路由结果有没有发生大面积变化？**

这和传统软件测试很不一样。

以前我们测试的是：

> 某个 Tool 能不能正常工作。

以后还要测试：

> **Agent 能不能在正确的时候找到这个 Tool。**

---

## 八、Jev 真正解决的不是“工具太多”，而是中间那一层

所以回到标题：

> **Jev 能解决 Agent 路由吗？**

更准确的答案是：

**它可以成为 Routing Layer 的一部分，但不能替代整个路由系统。**

大规模 Routing 仍然需要：

```text
规则
+
元数据
+
权限
+
候选召回
+
Decision Model
+
LLM
```

Jev 比较适合解决的是中间这一段：

> **候选已经相对明确以后，快速判断哪个更匹配。**

这和搜索系统其实有点像。

搜索并不是：

> 全互联网所有网页一起交给一个大模型判断。

而是：

```text
召回
↓
粗排
↓
精排
↓
最终结果
```

Agent Routing 很可能也会逐渐走向类似的架构。

---

## 写在最后

Agent 发展到现在，一个有意思的变化已经出现：

以前我们担心的是：

**Agent 没有工具可用。**

接下来越来越大的问题可能是：

**Agent 有太多工具，却不知道该用哪个。**

当 Tool、MCP、Skill 不断增加以后，

Routing 会越来越像 Agent Harness 的基础能力。

未来一个成熟的 Agent，可能不会把所有东西一股脑塞给 LLM。

而是：

**先过滤，再判断，再推理，最后执行。**

Jev 真正值得关注的地方，也正在这里：

它不是帮 Agent 增加更多能力，

而是在尝试解决另一个越来越重要的问题——

**让 Agent 在拥有很多能力之后，仍然知道什么时候该用谁。**

但当能力数量变成 50 个、100 个甚至更多，路由本身就开始成为 Agent Harness 的核心问题。

Tool、MCP、Skill 越来越多，Jev 能解决 Agent 路由吗？

人工智能

架构设计

开发工具

Agent路由正成为能力激增后的核心挑战。当工具从5个增至100个，直接塞给LLM会导致上下文过载与选择偏差。Jev这类决策模型擅长结构化路由，通过评分过滤候选，但需配合规则过滤与LLM推理形成三级架构。未来成熟方案是分层处理：先规则排除，再Jev粗选，最后LLM精判，确保Agent在众多能力中精准调用。

日志分析

安全测试

软件测试

性能测试

代码解释

数据库

路由

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Tool、MCP、Skill 越来越多，Jev 能解决 Agent 路由吗？-腾讯云开发者社区-腾讯云

Tool、MCP、Skill 越来越多，Jev 能解决 Agent 路由吗？

Tool、MCP、Skill 越来越多，Jev 能解决 Agent 路由吗？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐