用途
当智能体的可用工具超过约 15 个后，LLM 选择工具的准确性会明显下降。agent-tool-routing 的解决思路是增加一层路由器：先发现能力（工具注册表），按轮次收窄工具集合，再只把少量聚焦工具交给 LLM。
适用场景
- 智能体有 20+ 工具且经常选错工具
- 接入多个 MCP 服务器，工具功能重叠过多
- 工具在运行时动态出现或消失（按租户、按权限）
- 需要回退链（首选工具 → 更便宜的工具 → 缓存）
- 关注成本：每个未使用的工具描述都在浪费输入 token
架构
请求 → [能力发现] → [路由器] → [Top-K 工具] → LLM。能力发现依赖注册表索引，路由器结合语义匹配与策略过滤。
工具注册表
注册表以 ToolEntry 结构描述每个工具：名称、面向 LLM 的描述、JSON Schema、用于语义匹配的向量、标签集合（billing、read、write、hitl）、每次调用成本、p95 延迟、所需权限范围、回退工具名。工具来源包括 MCP 服务器发现、本地 tools.yaml 和插件。
路由策略
- 语义 Top-K：对查询做嵌入，返回最近的 K 个工具
- 标签过滤：只保留与当轮意图匹配的标签
- 权限过滤：丢弃调用方无权限的工具
- 成本感知：质量相当时优先选择更便宜的工具
- 粘性：若上一轮工具仍然相关则复用 组合方式：权限过滤 → 标签过滤 → 语义 Top-K → 成本重排。
使用方式
资料给出的快速开始函数 route_tools 接收查询、调用方权限和 K 值：先按权限过滤注册表候选，再对查询做嵌入并按余弦相似度排序，返回前 K 个，然后把 Top-K 工具暴露给 LLM 的工具列表。
回退链由 call_with_fallback 实现：循环调用当前工具，遇到超时或不可用时切换到其 fallback 指定的工具，全部耗尽则抛出 AllFallbacksExhausted。
工具描述规范
LLM 依据描述选择工具，每条描述应回答：动作（执行什么）、触发时机（何时使用）、返回（输出结构）、副作用（改变哪些状态）、成本/延迟提示（fast、slow、expensive）。例如应写成“按邮箱或 ID 获取客户。只读，约 50ms。返回 {id, name, tier, status}。在需要账户详情以执行计费操作前使用。”而不是“查询客户。”
MCP 能力发现
通过 MCP 客户端连接服务器并调用 list_tools 获取工具列表，再逐个写入注册表，附上描述、输入 Schema、嵌入向量、推断标签、成本（示例设为 0.0）、p95 延迟（示例 200ms）、空权限集合与空回退。
限制
资料未说明该技能的具体安装方式、运行环境依赖、支持的模型或框架版本、性能基准数据、收费与价格信息，这些内容暂未提供。