WorkWeave Router：给每个 API 请求配一个前台调度员，50ms 内决定用哪个模型
你在 Claude Code 里敲一行"帮我重构这个函数"，背后发生了什么？你以为是一次模型调用，其实是三到五次：读代码用便宜模型、写代码用旗舰模型、审查用中等模型。问题是——你自己根本不知道哪一步该用谁。
你在 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——中等模型就行，但你怎么切换？
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
四、和 OpenRouter Auto 的区别：两条路线
| 维度 | OpenRouter Auto | WorkWeave Router |
|---|---|---|
| 路由信号 | 社区消费数据（55T token/周） | 请求本身的语义嵌入 |
| 路由粒度 | per-prompt | per-action |
| 更新频率 | 7 天滚动 | 实时 |
| 部署方式 | 托管 | 本地或托管 |
| 数据流向 | 经过 OpenRouter | 直连 provider |
两条路线各有道理。OpenRouter 的优势是数据量大，能捕捉到"大家没想到但效果好"的搭配。WorkWeave 的优势是对新任务类型反应快——一个全新的 prompt 类型不需要等 7 天社区数据积累，第一次出现就能被正确路由。
五、HMM 策略：可选的"冻结策略"侧车
README 里提到一个可选组件：HMM（Hidden Markov Model）策略侧车，跑在 :8093 端口。默认不启用，需要 make up-hmm 手动启动。
这个设计有意思。默认的集群评分器是"实时嵌入匹配"，灵活但可能不稳定——同一个 prompt 在不同时间可能路由到不同模型（如果嵌入空间有微小扰动）。HMM 策略是"冻结的"——预先训练好的策略，行为可预测，适合需要审计的场景。
默认灵活，可选稳定——这个分层设计很聪明。大多数用户用默认就行，企业用户可以启用 HMM 获得可审计的路由决策。
六、成本账：40-70% 怎么来的
假设一个 agentic 工作流有 10 个动作：
| 动作 | 传统（全用旗舰） | 路由后 |
|---|---|---|
| 读文件 ×3 | 3 × $0.015 | 3 × $0.001（便宜模型） |
| 写代码 ×2 | 2 × $0.08 | 2 × $0.08（旗舰） |
| 审查 ×3 | 3 × $0.04 | 3 × $0.005（中等） |
| 对话 ×2 | 2 × $0.02 | 2 × $0.001（便宜） |
| 总计 | $0.305 | $0.187 |
但这里有个隐含假设：便宜模型在"读文件"和"对话"上和旗舰模型效果一样。这个假设在大多数情况下成立——读一个 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