技能雷达

问题：技能全量加载带来的上下文膨胀

当 Agent 宿主一次性加载所有已安装技能时，每个技能的 SKILL.md 说明文本都会进入上下文窗口。技能数量超过十几个后，无关技能的描述会占据大量 token，不仅推高延迟，还容易让模型在技能选择上出现困惑——真正需要的技能被淹没在无关文本里。

skill-radar 要解决的就是这个问题：在不改动框架的前提下，让 Agent 按需加载技能。

工作机制：声明式路由与评分筛选

skill-radar 的核心是一套声明式路由协议。每个技能通过 routing.yaml 声明自己的触发条件，包括名称、描述和关键词。收到用户查询后，路由脚本在本地执行正则匹配，返回一份排序后的 JSON 结果：

• Step 0：判断是否需要路由。用户显式指定技能、纯寒暄、或已安装技能少于 4 个时直接跳过。
• Step 1：执行路由脚本，传入用户原始查询。
• Step 2：解析返回的 JSON，取出匹配的技能列表。
• Step 3：只加载结果中命中的技能，其余一律不加载。若结果为空或脚本失败，回退到默认的全量加载行为，绝不阻塞用户。

评分公式上，如果查询命中了技能声明的反向模式，该技能会被直接排除，分数强制归零。默认采用 gap-based 阈值策略：当第一名与第二名的分数差大于 0.15 时，只加载第一名；否则加载所有得分超过 0.30 的技能。

集成模式与适用边界

skill-radar 支持四种集成方式，覆盖不同框架场景：

• Mode D（自路由）：Agent 自行执行路由脚本，无需修改框架，适合 ClawHub、OpenClaw、WorkBuddy 等。
• Mode A（CLI）：框架在组装系统提示词前调用命令行，仅将返回的技能注入上下文。
• Mode B（Python SDK）：供 Python 编写的 Agent 直接调用。
• Mode C（HTTP 微服务）：适合云端 Agent 架构。

需要注意的几点：

• 该技能应以高优先级加载，因为它是其他技能加载的闸门。
• 没有 routing.yaml 的技能对路由器不可见，只能通过回退路径加载。
• 路由决策完全透明，JSON 输出中会附带命中的关键词与模式，便于审计。
• 每次路由约增加 50ms 延迟，全部为本地正则匹配，不涉及网络请求。