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

摘要：

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

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

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

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

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

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

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

怎么给模型增加能力？

所以我们不断往里面加：

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

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

Agent 到底该选哪个？

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

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？

最简单的方案当然是：

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

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

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

1. 上下文越来越重

50 个 Tool，每个都有：

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

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

2. 选择空间越来越大

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

比如：

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。

因为路由本质上很像：

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

比如：

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

候选能力：

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

程序可以根据概率：

先筛出两个候选，

再交给 Agent 继续处理。

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

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

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

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

并不是。

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

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

先处理确定性条件。

比如：

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

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

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

这些事情根本不需要 AI。

第二层：Decision Model 做候选路由

经过第一轮筛选以后：

100 个能力
↓
剩 15 个候选

再让 Jev 进行：

分类
评分
路由

例如选出 Top 3：

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

这一层解决的是：

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

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

到了最后：

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

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

先调用谁？

参数是什么？

调用结果意味着什么？

下一步做什么？

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

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

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

智能分层。

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

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

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

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

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

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

Tool Routing 更像：

下一步我要调用什么？

比如：

浏览器
数据库
搜索
HTTP
Shell

它通常发生在 Agent Loop 中。

Skill Routing 更像：

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

比如测试支付系统：

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

Skill Routing 往往发生得更早。

它甚至可以决定：

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

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

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

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

Context 会明显变干净。

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

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

比如：

Top-K 命中率

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

错路由率

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

路由稳定性

同一类任务换一种说法：

测试登录页面

帮我检查登录功能

看看登录有没有 Bug

最终路由是否基本一致？

能力增加后的回归

原来系统只有 20 个 Skill。

增加第 21 个以后：

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

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

以前我们测试的是：

某个 Tool 能不能正常工作。

以后还要测试：

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

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

所以回到标题：

Jev 能解决 Agent 路由吗？

更准确的答案是：

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

大规模 Routing 仍然需要：

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

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

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

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

搜索并不是：

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

而是：

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

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

写在最后

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

以前我们担心的是：

Agent 没有工具可用。

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

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

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

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

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

而是：

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

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

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

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

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