HotPursuit

Show HN: Smart model routing directly in Claude, Codex and Cursor - infra 架构解读

HackerNews入库于 2026/6/27|
模型路由成本优化代理架构Claude Code大模型基建

作者：dodo

原文：https://github.com/workweave/router 发布时间：2026-06（约） 解读视角：大模型基础建设架构设计 沉淀时间：2026-06-27

一句话核心

Workweave Router 以"单端点透明代理 + <50ms 嵌入聚类路由"架构，将多模型路由能力无侵入地嫁接到 Claude Code/Codex/Cursor 等现有 AI 编码工具，实测降本 40-70%，其核心价值在于演示了如何将路由决策从业务代码中完全剥离、用可观测的代理层承载，对设计大模型基建的成本优化层有直接参考价值。

文章背景与问题域

AI 编码工具的 LLM 调用成本快速增长（以 Opus 4.7 tokenizer 变更引发成本飙升为例），但直接降级模型又会牺牲复杂任务质量。核心矛盾：

  • 开发者不想为每个简单 prompt 支付 frontier 模型的高价
  • 但也不想手工判断"这个请求用哪个模型"（认知负担高、不可维护）
  • 现有 AI 工具（Claude Code/Codex/Cursor）不支持动态模型选择

Workweave Router 的解法：在客户端和上游 API 之间插入一个透明代理，由代理自动完成路由决策，开发者零感知。

核心架构 / 方案解析

系统架构

┌─────────────────┐     rk_... Bearer token     ┌──────────────────────────┐
│  AI 编码工具     │ ─────────────────────────▶ │    Workweave Router       │
│ Claude Code     │  POST /v1/messages          │    localhost:8080          │
│ Codex           │  POST /v1/chat/completions   │                           │
│ Cursor          │  POST /v1beta/models/...     │  ┌──────────────────────┐ │
└─────────────────┘                              │  │  Cluster Scorer       │ │
                                                 │  │  (Avengers-Pro 算法)  │ │
                                                 │  │  <50ms 嵌入+分类      │ │
                                                 │  └──────────┬───────────┘ │
                                                 │             │              │
                                                 │  ┌──────────▼───────────┐ │
                                                 │  │  Provider Dispatcher  │ │
                                                 └──│  Anthropic/OpenAI/   │─┘
                                                    │  Gemini/OpenRouter    │
                                                    └──────────────────────┘

路由决策机制

基于论文 Avengers-Pro 的 cluster scorer：

  1. 嵌入计算：对每个请求计算 prompt 嵌入（on-box，非调用 LLM）
  2. 聚类匹配：将嵌入与预训练的任务聚类匹配，判断任务类型（代码生成/推理/问答/...）
  3. 模型选择：根据聚类 → 选择最优性价比模型
  4. 路由延迟：< 50ms（本地嵌入，不走网络）

API 兼容层

端点协议用途
POST /v1/messagesAnthropic MessagesClaude Code 等
POST /v1/chat/completionsOpenAI Chat CompletionsCodex、Cursor
POST /v1beta/models/:actionGemini generateContentGemini 客户端
POST /v1/route内部协议路由决策预览（不实际调用上游）

关键工程决策与权衡

决策点选择放弃的方案理由
路由决策位置代理层（应用外）业务代码内嵌零侵入，支持所有现有工具无需修改
路由特征提取本地小模型嵌入+聚类用 LLM 判断"这个请求该用哪个模型"避免"用 LLM 决定用哪个 LLM"的递归成本问题，<50ms 满足实时链路
密钥管理BYOK，密钥加密存储在本地密钥托管在路由服务安全优先，密钥不离开用户机器
部署形态托管云版本 + 本地自托管双模式纯 SaaS 或纯自托管开箱即用（npx）满足个人开发者，自托管满足企业合规需求
可观测性OTLP 标准 traces + 本地 Dashboard私有日志格式与 Honeycomb/Datadog/Grafana 等生态无缝集成

大模型基建视角专项解读

系统架构与分层设计

Workweave Router 展示了一个教科书级的"代理模式分层"：

用户工具层    ──→  统一接口（/v1/messages 或 /v1/chat/completions）
路由决策层    ──→  嵌入+聚类（与业务逻辑完全解耦）
Provider 层   ──→  Anthropic / OpenAI / Gemini / OpenRouter

关键设计原则：路由决策与 API 兼容层分离。POST /v1/route 端点允许"只查看路由决策，不实际调用"，这是将决策逻辑外置、便于调试和审计的典型做法。

并发与调度模型

路由器是无状态的请求处理器，天然支持水平扩展。路由决策的 <50ms 延迟约束要求：

  • 嵌入计算必须在本地完成（不能走网络）
  • 聚类匹配必须使用预训练索引（不能实时训练）

这是典型的"用预计算换实时延迟"的调度模式。

安全与权限隔离

双密钥体系设计：

  • sk-ant-/sk-or-/sk-...：上游 Provider key，存于 .env.local，不离开路由器
  • rk_...：Router key，客户端使用，即使泄露也只能调用路由器而不能直接访问上游 Provider

这种双密钥设计实现了"客户端能力最小化"——客户端只持有路由权限，不持有上游 API 权限，符合最小权限原则。

可扩展性设计

插件化 Provider 接入：通过"Architecture" 文档描述的"recipes for adding endpoints/providers/strategies"，路由器的 Provider 和策略层设计为可插拔。

零侵入安装：npx @workweave/router --claude 只修改 Claude Code 的 baseURL 配置，不修改任何业务代码。卸载时只移除"托管配置块"，不影响用户其他配置。这是典型的"配置驱动、代码零侵入"扩展模式。

评测与可观测性

POST /v1/route 端点是一个隐藏的 eval 利器：可以批量导入历史 prompt，查看路由器对每个请求的"路由决策"，不用实际消耗 token，从而离线评估路由策略质量。

OTLP traces 支持让路由决策可追溯：每个请求的"选择了哪个模型、为什么"都有 trace 记录，这是 LLM 成本归因和优化的基础。

工程模式提炼

模式名文章中的实现大模型基建启示
透明代理路由层在客户端和上游 API 之间插入代理，多协议统一接口LLM 调用的成本优化和能力路由，无需修改业务代码，通过代理层承载
预计算索引路由本地嵌入+预训练聚类，<50ms 决策实时路由决策必须用预计算；用 LLM 决策"用哪个 LLM"是反模式
双密钥最小权限Router key（客户端持有）+ Provider key（路由器持有）分离对外暴露能力时应最小化凭证权限，客户端只持有调用路由器的权限
决策预览端点POST /v1/route 返回路由决策但不调用上游eval 和调试场景中，路由决策与实际执行应可独立触发，便于离线批量评估
配置块隔离安装npx 安装只修改/删除"托管块"，不影响用户其他配置工具嫁接到现有工作流时，修改范围必须最小化且可完全回滚
OTLP 标准可观测性路由 traces 直接接入 Honeycomb/Datadog/GrafanaLLM 推理基础设施的可观测性应优先采用 OTLP 等标准协议，避免私有格式锁定

反常识点梳理

反常识点常规认知文章实际做法背后原因
不用 LLM 来决定"用哪个 LLM"用智能模型做智能决策用小嵌入模型+聚类（<50ms）做路由决策用 LLM 决定路由会引入额外 token 成本和延迟，且路由决策本身不需要"理解力"，只需要"分类能力"
路由器不感知 prompt 语义内容路由需要理解请求意图嵌入+聚类是统计特征，非语义理解聚类方法在实践中已足够准确，且计算成本极低

延伸思考

  1. 聚类路由的局限性与升级路径：Avengers-Pro 聚类路由对于"代码生成 vs 推理 vs 问答"等粗粒度分类效果好，但对于"需要 function calling vs 不需要"、"需要长上下文 vs 不需要"等细粒度路由是否同样有效？当 Agent 的工具调用序列跨越多轮时，每轮单独路由是否最优，还是需要"会话级路由策略"？

  2. 路由器的 cold-start 和状态问题：路由器本身是无状态代理，但上游 LLM 的 KV Cache 是有状态的（prefix caching）。如果路由决策导致同一会话的请求被路由到不同的模型或 Provider，就会破坏 prefix cache 利用率，导致实际成本上升。这个"路由收益 vs 缓存损失"的权衡如何量化？

  3. 大规模 Agent 基础设施的集成路径：对于有 10+ 个 Agent 节点的分布式 Agent 系统，Workweave Router 的本地代理模式（localhost:8080）需要升级为集中式路由服务。集中式部署下，路由层的 SLA（<50ms）是否仍然成立？如何在路由服务自身的可用性和路由决策延迟之间取得平衡？

← 返回文章列表