OmniRoute AI 网关

多供应商接入的真实痛点

把 290+ 提供商接到同一个 Agent 上，问题远不只是写几个 if-else：供应商的 429 限流和 5xx 故障没有统一语义，重试策略无法通用；同样一次 completion，不同厂商的价格可能差出一个数量级；而 Token 账单里有相当一部分是 prompt 冗余——长上下文编码任务中，重复的系统提示、文件内容往往可以在几乎不损失质量的前提下被压缩。

核心能力

OmniRoute 的思路是：在调用方和 provider 之间插入一层网关，对外只暴露一个统一端点，后面挂一整套路由抽象。

• 19 种路由策略：priority、weighted、cost-optimized、headroom、cache-optimized 等，外加零配置的 auto/coding、auto/fast 变体。路由决策可以基于价格、延迟余量或上下文类型，而不是写死的默认值。
• Token 压缩：RTK + Caveman 双层压缩，官方称平均节省约 89%，直接削减 prompt 中的冗余结构。
• 三层自愈：provider 级断路器（408/5xx 触发，60s/30s/15s 分档重置）；连接冷却（指数退避 ×2，尊重 Retry-After）；模型级锁定——只锁定出问题的模型，不牵连整条连接。
• 协议兼容：OpenAI ↔ Claude ↔ Gemini ↔ Responses API 走同一端点互转，配套 MCP server（104 工具）、A2A 协议、memory 与 guardrails。

适用边界

• 它是方法论加参考实现，不是托管服务：理解断路器和路由语义之后，仍需自行部署维护。
• 压缩策略要按任务类型评估质量损失，auto/cheap 不等于适合所有场景。
• 90+ 免费层有速率与配额限制，生产流量不宜默认依赖免费层。