Agent Skill 命中率下降？问题在路由设计

面试官问：
Agent Skill 太多命中率下降怎么办？

真正考的不是模型会不会干活，而是能不能把活选对。
Skill 一多，重点从执行能力变成了路由能力。

✦ 核心观点

模型不是不会做，而是在一堆相似 Skill 里更容易选错。

本质不是能力下降，而是路由复杂度上升。问题从「怎么做」变成了「选哪个」。

◆ 为什么 Skill 一多命中率就掉？

01 候选变多 — 从几个里选变成从几十个里选，搜索空间骤增

02 描述相似 — 多个 Skill 看起来都能做，模型容易混淆

03 边界模糊 — 只写功能不写触发条件，模型不知道什么时候该用

04 误触发增加 — 不是没能力，而是被相似 Skill 抢走了

❖ 所以这本质上不是「不会做」，而是「选不准」。

★ 四招优化路由命中率

优化 Skill 描述核心

别只写功能，要写触发场景。 把描述拆成三层：

触发场景 — 什么情况下使用
输入特征 — 常见关键词与意图
输出目标 — 最终产出什么

▸ 举例不要只写「负责生成 PPT」。
更优写法：「当用户要求制作汇报材料、融资路演方案等演示文稿时使用」。
—— 触发场景一目了然，模型更容易匹配。

建立 Skill Tree

先粗分再细选，缩小搜索空间。 不要让模型一上来面对全部 Skill，而是先判定大类，再进入子类。

例如：先分成 研发类 · 运营类 · 商务类 · 设计类，
研发类下面再分「代码生成」「测试生成」「代码审查」；
运营类下面再分「活动文案」「用户分析」「数据复盘」。

💡 不在整个仓库里找钥匙，而是先找到那个抽屉，再在抽屉里找。

补充副样本

把不适用场景也写出来。 真正决定边界的往往是「不能干什么」。

▸ 举例一个用于生成 Circle 查询的 Skill，不只写「用于生成 Circle 查询语句」，
还要补充：「但不用于数据库设计、表结构规划、索引架构设计」。
—— 模型就知道它负责查询，不负责建模。

✅ 三件事一起写：正向触发 + 相邻边界 + 禁用场景。

先召回再重排

别让大模型全量硬选，而是先检索后判断。
流程：用户问题 → 识别意图 & 关键词 → 通过 embedding 或规则召回 Top K 候选 → 交给大模型结合上下文做最终判断。
如果几个 Skill 还是很像，可补一个澄清问题。

🎯 核心思路：先缩小范围，再精确判断。

✦ 渐进披露 Progressive Disclosure

❶ 发现 — 先看名称、简介、适用场景

❷ 判断 — 从候选中选出更匹配的

❸ 加载 — 命中后再加载详细说明与工具

好处：减少无关上下文，Skill 再多路由结构也能保持清晰。

❝

这不是模型智商问题，
而是 Skill 路由设计问题。

记住四个词

描述清楚分层管理补充复利检索重排

📋 面试时可以这样说

“Agent Skill 过多后命中率下降，本质不是模型能力下降，而是路由复杂度上升。
我的优化思路有四点：
❶ 优化 Skill 描述，写清触发场景、输入特征和输出目标；
❷ 建立 Skill Tree，先按大类粗筛，再进入子类细选；
❸ 补充副样本，明确不适用场景，减少误触发；
❹ 引入召回加重排，先检索后选，再让模型做最终判断。”

⚡ 一句话概括：这不是模型会不会干活，而是能不能把活选对 —— 路由设计决定上限。