Hermes模型路由配置

Hermes模型路由配置 是做什么的？

根据实时账户可用性和本地实测性能，配置Hermes主模型、回退模型及辅助路由。优化的是实际配置的路由，而非通用排行榜。

操作步骤

1. 在推荐或更改之前，先发现当前活跃状态。

   • 加载 hermes-agent 技能，然后检查 ~/.hermes/config.yaml、hermes auth list、hermes fallback list 和 hermes config check。
   • 检查经过身份认证的模型选择器目录或缓存，获取确切的免费模型ID，记录其刷新时间，并将 :free 可用性视为易变的。
   • 查询每个目标本地端点的实时标签，并使用基准测试中使用的确切标签。

2. 建立路由策略。

   • 仅在用户明确声明策略的情况下，且仅针对非敏感工作，默认使用当前可用的免费云模型。
   • 对于专有仓库、机密、客户数据和私有图片，始终提供明确的本地路由；云默认无法推断数据敏感性。
   • 将独立托管的本地端点放入有序的 fallback_providers 中；每个条目使用 provider: custom 加上端点的 /v1 基础URL。

3. 筛选并分配模型。

   • 在最终Hermes路由将使用的上下文窗口下进行基准测试，几乎填满该窗口，并分别保存提示和解码速率。
   • 将因超时或解码吞吐量而被排除的候选模型从比较排名和所有自动路由中剔除。仅提及该模型可能不适合该主机/上下文，而不是对基础模型能力的评判。
   • 将压缩、策展和审查路由到有能力的本地模型，因为它们可以接收累积的对话或仓库上下文。
   • 仅在确认短任务性能足够后，将廉价的本地模型分配给审批、标题生成和个人资料描述。
   • 仅在非私有图片上使用云视觉，并在可用时提供明确的本地视觉回退。

4. 生成可审查的配置片段。

   • 以具体的YAML格式给出默认模型、有序回退以及每个辅助任务，包含确切的provider/model/base URL值。
   • 说明该片段是“推荐”还是“已应用”。未经用户明确请求，不要编辑活跃配置文件。
   • 验证生成的YAML；应用编辑后，运行 hermes config check 并回读 hermes fallback list。

常见陷阱

• 当选择了主提供商时，配置显式的辅助 fallback_chain；Hermes不会在显式路由后面静默地耗用其他已认证的无关提供商。
• 使用 fallback_providers 而非旧式的单一回退键；列表保留了预期的顺序，且这是Hermes回退管理器写入的方式。
• 保持免费云默认和私有数据路由的隔离；账户可用性并不意味着有权将专有输入发送到外部。
• 不要将基准测试门控排除的模型放入自动回退或辅助路由中；违反操作阈值的回退只会将故障向下游转移。
• 在配置中保留确切的模型标签；名称相似的Ollama标签在烘焙上下文、提示模板或放置位置上可能不同。