WorkWeave Router：给每个 API 请求配一个前台调度员，50ms 内决定用哪个模型

你在 Claude Code 里敲一行"帮我重构这个函数"，背后发生了什么？你以为是一次模型调用，其实是三到五次：读代码用便宜模型、写代码用旗舰模型、审查用中等模型。问题是——你自己根本不知道哪一步该用谁。

一句话定位

WorkWeave Router 是一个本地代理，架在 Claude Code / Codex / Cursor 和上游模型 API 之间，为每一个 API 请求（不是每一轮对话）实时选择最优模型，路由决策在 50ms 内完成，成本下降 40-70%。

一、问题：模型选择是个"全栈焦虑"

过去两年，AI 编程工具链里有一个被刻意回避的问题：一个任务里，不同步骤需要不同模型。

• 读一个 2000 行的文件做摘要——GPT-4o-mini 够了，0.15 美元/百万 token
• 写核心算法——Claude Sonnet 4.5 或 GPT-5.6，但 3-15 美元/百万 token
• 审查 diff——中等模型就行，但你怎么切换？

传统做法是"一个工具绑一个模型"。Cursor 默认用 Claude，Copilot 默认用 GPT-4o，Codex 绑 OpenAI。用户要么全用旗舰（贵），要么全用便宜模型（菜）。中间状态需要手动切换，而手动切换在 agentic 工作流里几乎不可能——agent 一轮跑 20 步，你不可能每步盯着改模型。

OpenRouter 8 月 10 日发布的新版 Auto 路由器试图解决这个问题，但它的路由策略是"市场驱动 + 7 天滚动"——用社区消费数据为每个 prompt 选模型。本质上是"大家怎么选我就怎么选"。

WorkWeave Router 走了另一条路：不问大家怎么选，问这个具体动作需要什么。

二、核心机制：per-action 路由 + 集群评分器

README 里有一句容易被忽略但很关键的话：

the router routes per action, not per turn

翻译过来：路由的粒度是"动作"，不是"对话轮次"。

一个"轮次"是用户发一条消息、agent 回一段话。但一个"动作"是 agent 内部的一次 API 调用——读文件、写代码、跑测试、审查 diff。一个轮次可能包含 5-10 个动作，每个动作的模型需求完全不同。

路由决策的核心是 Avengers-Pro 集群评分器（论文 arxiv 2508.12631），一个轻量级的 on-box embedder：

1. 把当前请求的 prompt 嵌入成一个向量
2. 和预定义的"任务集群"做相似度匹配（代码生成、代码审查、文档摘要、推理、对话……）
3. 根据集群 → 模型的映射表，选出这个集群上表现最好的模型
4. 整个过程在 50ms 内完成，用户无感

这个 embedder 是 ONNX 格式，跑在路由器进程内，不需要外部 GPU。这也是为什么它能做到 50ms——没有网络往返，没有模型加载延迟。

三、架构：你的 key 留在你机器上

WorkWeave Router 的架构图里有一句注释很说明问题：

Only the grey boxes are off your machine.

灰色的是上游模型提供商（Anthropic、OpenAI、Gemini、OpenRouter）。路由器、评分器、Postgres、你的 API key——全在你本地。

这意味着：

• BYOK（Bring Your Own Key）：你的 Anthropic / OpenAI / OpenRouter key 加密后存在本地 Postgres，不经过 WorkWeave 服务器
• 请求路径：router → provider，直连，不经过 WorkWeave 中转
• 可观测性：OTLP traces 直接发到你的 Honeycomb / Datadog / Grafana，不发给 WorkWeave

这个设计选择不是出于安全洁癖，是合规刚需。企业用户不会接受"我的 prompt 经过你的服务器"这种架构——哪怕你承诺不存。WorkWeave 的商业模式是卖托管版和管理面板，不是卖数据管道。

四、和 OpenRouter Auto 的区别：两条路线

OpenRouter Auto 是"市场智慧"路线——大家怎么选我就怎么选。WorkWeave 是"技术分析"路线——这个 prompt 长得像哪类任务，就用哪类模型。

两条路线各有道理。OpenRouter 的优势是数据量大，能捕捉到"大家没想到但效果好"的搭配。WorkWeave 的优势是对新任务类型反应快——一个全新的 prompt 类型不需要等 7 天社区数据积累，第一次出现就能被正确路由。

五、HMM 策略：可选的"冻结策略"侧车

README 里提到一个可选组件：HMM（Hidden Markov Model）策略侧车，跑在 :8093 端口。默认不启用，需要 make up-hmm 手动启动。

这个设计有意思。默认的集群评分器是"实时嵌入匹配"，灵活但可能不稳定——同一个 prompt 在不同时间可能路由到不同模型（如果嵌入空间有微小扰动）。HMM 策略是"冻结的"——预先训练好的策略，行为可预测，适合需要审计的场景。

默认灵活，可选稳定——这个分层设计很聪明。大多数用户用默认就行，企业用户可以启用 HMM 获得可审计的路由决策。

六、成本账：40-70% 怎么来的

假设一个 agentic 工作流有 10 个动作：

省了 39%。如果原本全用 Claude Opus 4（更贵），省的比例更高。

但这里有个隐含假设：便宜模型在"读文件"和"对话"上和旗舰模型效果一样。这个假设在大多数情况下成立——读一个 2000 行的文件做摘要，GPT-4o-mini 和 Claude Opus 4 的差距可以忽略。但在少数情况下（比如代码里有微妙的 bug 需要在阅读时发现），便宜模型会漏掉关键信息。

WorkWeave 的路由器不会知道你的代码里有没有微妙 bug——它只看 prompt 的语义。所以 40-70% 这个数字是"平均情况"，不是"最坏情况"。

七、30 秒上手：npx 一行命令

npx @workweave/router

安装器会问你用哪个工具（Claude Code / Codex / opencode / pi），然后自动改对应的配置文件。不需要 clone、不需要 Docker、不需要 Postgres。

自托管完整栈：

echo "OPENROUTER_API_KEY=sk-or-v1-..." >> .env.local
make full-setup

路由器跑在 :8080，管理面板跑在 :8080/ui，你的 rk_ key 打印在日志里。

八、为什么这件事重要

WorkWeave Router 代表的趋势比工具本身更重要：模型选择正在从"用户决策"变成"基础设施决策"。

2023 年：用户手动选 GPT-4 还是 Claude
2024 年：工具默认绑一个模型
2025 年：OpenRouter Auto 用市场数据选
2026 年：WorkWeave 用语义嵌入 per-action 选

每一步都是把"模型选择"从用户认知负担里往下移一层。当这层完全透明时，用户甚至不需要知道"模型"这个概念——只知道"我的 agent 在干活"。

这和操作系统的进程调度是同一个故事：1970 年代用户手动分配 CPU 时间片，2020 年代内核调度器自动做这件事。模型路由器就是 AI 时代的进程调度器。

九、风险和边界

WorkWeave Router 不是没有问题：

1. 路由错误不可见：如果路由器把一个"写核心算法"的请求路由到便宜模型，用户很难发现——输出看起来正常，只是质量稍差。需要 OTLP traces 才能审计。
2. 集群评分器的偏差：Avengers-Pro 的训练数据决定了它擅长路由哪些类型的任务。如果训练数据偏科（比如全是英文代码任务），在其他类型上可能表现差。
3. ELv2 协议：不是完全开源，是 Elastic License v2。不能作为商业服务提供给他人。个人和企业内部使用没问题。

十、结论

WorkWeave Router 把"模型选择"从用户认知负担里移到了基础设施层。per-action 路由的粒度比 OpenRouter Auto 的 per-prompt 更细，50ms 的决策延迟让用户无感。BYOK 架构和本地 Postgres 让企业用户能接受。

但更重要的是它代表的趋势：模型正在变成可替换的零件，路由器才是新的护城河。当上游模型提供商（Anthropic、OpenAI、Google）在模型能力上互相追赶时，路由器层在悄悄积累数据——谁家模型在什么任务上表现好，这些数据比模型本身更值钱。

项目地址：https://github.com/workweave/router
作者：WorkWeave（工程智能平台，Robinhood / PostHog / Reducto 等公司在用）
协议：ELv2（个人和企业内部使用免费）
语言：Go 1.25+
快速开始：npx @workweave/router