shield_lock
金大哥
← 返回 Skill 列表
extension
分类: 开发与工程API Key 暂未确认

omniroute模型更新skill

刷新本地 OmniRoute LLM 网关（127.0.0.1:20128）的 provider 模型目录，把“新增且经探测可用”的模型按角色分配到我建的 7 个组合（heavy-duty / main-coding / ultra-fast / daily-balanced / free-pool / zh-writing / coding）。用户说“更新/刷新 OmniRoute 模型信息”“把新增可用模型分配给组合”“重新扫描 OmniRoute 模型并更新组合”“combo 里加点新模型”时使用——即使没提“模型”这个词，只要是让 OmniRoute 的模型/组合保持最新就应触发。

person作者: qingqingtianhubModelScope
open_in_new仓库download下载资源包

omniroute-model-refresh

把本地 OmniRoute 网关（http://127.0.0.1:20128）的 provider 模型目录刷新到最新， 只把探测确实可用的新模型按角色加入我建的 7 个组合，并保持组合健康。

适用场景

  • “好久没更新模型了，给 omni 更新一下模型信息”
  • “把新增的可用模型分配给我那 7 个组合”
  • 想要让 combo（heavy-duty / main-coding / ultra-fast / daily-balanced / free-pool / zh-writing / coding）用上各家 provider 最新上架的模型

关键事实（务必先读）

  • 两套凭据，别搞混：
    • x-omniroute-cli-token（HMAC-SHA256(注册表 MachineGuid, "omniroute-cli-auth-v1")） 只够 /api/combos、/api/keys、/api/providers（读）。
    • 同步/目录接口要 manage scope 的 Bearer 密钥： /api/providers/{id}/sync-models、/api/synced-available-models、 /api/provider-models。用 CLI token 会 403 “Invalid management token”。 脚本会自动 POST /api/keys 现建一把 {"name":"sync-runner","scopes":["manage"]} 并缓存到工作目录，避免反复积累密钥。
  • 温和探测是硬约束：并发 ≤3，超时宽松。6+ 并发曾把整个网关打到超时、 把 node 进程打到 ~750MB 内存、用户被迫重启。脚本已固定 3 并发。
  • 推理模型（claude/kimi/qwq/cohere/多数 flash）输出在 reasoning 字段： 探测用 max_tokens≈150 且“有 content 或 reasoning 即算通过”，否则会被误判为空。
  • 免费的会限流：:free 上游常 “model is busy”（超时/402），kilocode 的 401/402 是会话/额度瞬时抖动（可自愈），pollinations 的社区 gguf 多数 “model not found”。 这些是“目录里列了但不一定可用”——只把探测 PASS 的加进组合，符合“可用模型”。
  • 直接探测某个 provider/模型：POST /v1/chat/completions，model="<provider>/<modelId>" （第一个 / 前是 provider 前缀，模型 id 里可再含 /）。

三个脚本（在本 skill 的 scripts/ 下）

所有中间产物在 %TEMP%\omni_model_refresh\。逐个运行，每步之间看一眼输出。

cd <skill_dir>/scripts      # 让 `import omni_common` 生效
python omni_sync.py         # 步骤1：刷新目录 + diff -> new_models.json
python omni_probe.py        # 步骤2：探测新模型 -> verified_models.json（≤3 并发）
python omni_distribute.py --dry   # 步骤3a：预览分配方案（不写）
python omni_distribute.py        # 步骤3b：确认无误后真正写入 7 个组合
  • omni_sync.py：对每个激活的 provider 连接串行调 sync-models（~1.2s 间隔）， 对比前后 syncedAvailableModels，输出净新增模型。
  • omni_probe.py：读 new_models.json，构建探测清单（“干净”provider 全测； 新模型数 >30 的聚合型 provider 如 kilocode/pollinations 取均匀抽样）， 3 并发探测，输出通过的 verified_models.json。
  • omni_distribute.py：读 verified_models.json，按角色（free/fast/heavy/code/zh） 映射到对应组合；priority 组合（heavy-duty、ultra-fast）新成员置顶，其余追加； coding 组合很小且已调校，只补最多 1 重 + 2 快（跳过易抖的 kilocode）。 --dry 只打印计划不写入。

步骤说明

  1. 确认网关活着：python -c "import urllib.request;print(urllib.request.urlopen('http://127.0.0.1:20128/api/health').read())"。 挂了就先帮用户重启（网关是裸 node 跑 dist/server-ws.mjs，不是 pm2）。
  2. 跑 omni_sync.py：看净新增数量。若 0 个新增，说明目录没变，可跳过 2、3。
  3. 跑 omni_probe.py：看 PASS/FAIL 分布。FAIL 多是限流/付费/找不到，正常。
  4. 先 omni_distribute.py --dry：核对每个组合要加哪些模型、加多少。 分类是启发式（omni_distribute.py 顶部的关键词表），可随手改； 不满意就直接编辑关键词或临时手挑。
  5. 确认无误再跑 omni_distribute.py：它 PUT 每个组合并回读核对成员数。
  6. 端到端冒烟：对改过的组合发一个简单题（如 15*22=?），确认组合路由正常、 新模型能被选中且答案正确： 
    # 见 report；或直接对 combo/<name> 调 /v1/chat/completions
  7. 收尾：写一份简短报告（新增/通过/各组合变化），并更新 omniroute-model-inventory 记忆（新日期 + 各组合最新成员数 + 新发现）。

注意 / 边界

  • 若用户只想“刷新目录”不想动组合，只跑 omni_sync.py 即可。
  • 若某 provider 同步报 502（无 token / 401 授权失败），它会回退到本地缓存目录， 属正常，不用管；必要时提醒用户重新登录该 provider。
  • 只加“可用”的：宁可少加（漏掉的聚合型模型下次再扫），也别把未验证的大量 目录条目塞进 priority 组合导致回退链变长。
  • 组合 PUT 后要 GET 回读确认；若 409/乐观锁失败，重拉最新 payload 再写。