技能介绍

要解决的问题

Agent 代码里最常见的写法是把 model 参数写死。这种做法有两个后果：要么所有请求都跑在最贵最强的模型上，分类、抽取这类轻任务白白付溢价，延迟也被拉高；要么为了省成本选了便宜模型，等遇到长上下文或工具调用密集的循环才发现能力不够，只能在线上临时打补丁。

更麻烦的是决策过程没留下痕迹。谁定的这个模型、为什么选它、失败时回退到哪——这些信息通常只存在于某个人的脑子里，交接和复盘时全靠口述。

RouterBase 把这件事显式化：它不替你选模型，而是给 Agent 一套可执行的路由规划流程，最终产出带取舍说明的方案。

核心能力与关键步骤

第一步：工作负载盘点。 先把流量拆成不同类别：便宜的分类任务、高上下文分析、工具调用密集的 Agent 循环、媒体生成，以及最终面向用户的综合输出。分类的粒度直接决定后续策略能不能落地。

第二步：逐类配置。 每个类别都要确定几件事：

主模型与一到两个备用模型
重试上限与超时预算
日志方案：记录路由决策本身，但不保存敏感提示词与凭证

第三步：验证。 用一组小规模提示词跑通每条路由，对比输出质量，检查错误处理路径。同时明确写出：系统应该在什么情况下 fail closed，而不是静默降级到一个不支持该能力的模型上。

适用边界

这是指导型技能，输出的是规划文档和决策规则，不是可运行的路由服务。它不会告诉你某个模型的实际延迟或价格，这些数字需要自己压测和核对。如果你的工作负载只有单一类型，硬编码可能更简单——路由本身的开销就不划算。另外，fallback 链上相邻模型的能力差异越大，静默降级的风险越高，文档里必须显式标注能力边界。