一个让你肉疼的场景#

凌晨两点，你刚让 Codex 帮你修了一个小小的拼写错误。它用了 GPT-5.5。成本：$0.38。

上午十点，你让 Claude Code 帮你检查一下代码风格。它用了 Opus 4.8。成本：$0.52。

下午三点，Cursor 帮你补全了一行 import 语句。它可能也调了顶级模型。成本：你不确定，但你隐约觉得不对劲。

这些场景每天都在数以万计的开发者电脑上发生。AI 编程助手让我们效率翻倍，但也让 API 账单悄悄膨胀。问题出在哪？你只用一把「牛刀」杀了所有的「鸡」。

细看一个典型的 AI 编程会话：有时你在描述复杂架构，有时你只是让它重命名一个变量。这两种场景对模型能力的要求天差地别，但你为它们付了同样的费用。

答案：给 API 请求加一个「调度层」#

这个问题的解法很直观：不同难度的任务，用不同级别的模型。 但这说来容易做起来难。谁来判定？怎么判定？手动切换模型吗？一天切换几十次？

六月底，Hacker News 上一个项目悄然走红，收获了 140 个推荐和 88 条讨论。它就是 Weave Router，一个为 AI 编程助手量身打造的智能模型路由器。

Weave Router 的核心理念非常简洁：它像一个透明的代理，插在你的编程助手和 AI 服务商之间。每个 API 请求经过它时，它会实时判断这个请求该交给哪个模型处理，然后帮你做出最优选择，全程你不需要做任何事。

它是怎么判断「该用哪个模型」的？#

这可不是简单的「检查关键词」或「启发式规则」。Weave Router 用的是强化学习。

背后的逻辑是这样的：Weave 团队收集了上万个真实编程场景的 Agent 执行轨迹（traces），包括请求内容、最终任务是否成功完成、用了多少 Token 等。他们以此训练了一个路由模型，奖励机制很简单：选对了模型，任务成功完成，加分；选了过强或过弱的模型导致浪费或失败，扣分。

训练完成后，这个路由模型能够在接收到新请求时，快速判断出用哪个模型最合适。具体来说：

  • 当你描述一个复杂架构变更，它会把请求路由到 Opus 4.8 或 GPT-5.5，因为你确实需要顶级的推理能力；
  • 当 Codex 派生出的子 Agent 去浏览代码库收集上下文，它会用 DeepSeek V4 Flash 这样的快速模型；
  • 当你拿到计划开始具体实现，它会切换到 GLM 5.2 这类性价比更高的模型。

这不是凭感觉切换，而是基于成千上万个真实案例训练出来的决策。决策依据来自请求内容的语义特征，而非关键词匹配或硬编码规则。

无缝集成：一行命令接入#

Weave Router 设计得非常务实。它支持通过 Anthropic Messages API、OpenAI Chat Completions API 和 Gemini API 三种协议接入，这意味着它能兼容几乎所有主流的 AI 编程工具。

接入方式也极其简单：

# 接入 Codex
npx @workweave/router --codex

# 接入 Claude Code
npx @workweave/router --claude

# 接入 Cursor
npx @workweave/router --cursor

# 自己托管（跑在 localhost:8080）
npx @workweave/router --local

执行之后，它会自动修改对应的配置文件。对于 Codex，它会在 ~/.codex/config.toml 里添加一个 [model_providers.weave] 配置块；对于 Claude Code，它会调整 API 端点指向本地代理。你不用手动改任何配置，想切回原样也只需一行 npx @workweave/router off --codex。

它支持的模型列表也很全面：不仅包括 OpenAI 和 Anthropic 的前沿模型，还支持 DeepSeek、Kimi、GLM、Qwen、Llama、Mistral 等开源模型（通过 OpenRouter 接入）。你的 API Key 始终保存在本地，路由器只是帮你选择「用哪个」并转发请求。

实测效果：40% 成本下降，质量不打折#

Weave 团队自己就是第一个用户。在 Opus 4.7 发布后，由于 Tokenizer 变更，他们的 API 成本暴涨。这个路由器就是在这种压力下诞生的。

他们内部使用一个月后的数据是：Token 成本降低了 40%，而代码质量和开发速度没有可感知的下降。

这个数字背后的逻辑很清晰：一个 AI 编程会话中，大量请求其实是「简单任务」，比如读取文件内容、匹配代码模式、查找符号定义。这些任务用轻量模型完全可以胜任。真正需要顶级推理能力的请求远比你以为的少。

Hacker News 上的讨论也印证了这个趋势。有人提到：「配合把常用请求保存为可复用 Skill，应该能省掉一大截 Token 用量。」还有人分享了自己的感想：「当一个复杂变更被拆成 15 个子任务，只有 2 个需要 Opus，剩下 13 个用 DeepSeek 完全够用，这就是路由器能抓住的价值。」

路由器的局限和争议#

当然，并非所有人都被说服。HN 评论区也有不少有价值的质疑。

缓存命中率下降。 Anthropic 和 OpenAI 的 Prompt Caching 通常有 5 分钟的 TTL。频繁切换模型意味着缓存失效，可能导致一些请求的实际成本反而更高。路由器的设计者回应说，他们在 RL 训练中已经将缓存命中作为惩罚因子考虑进去了，但这仍然是一个值得关注的变量。

模型风格不一致。 不同模型对 Prompt 的理解方式不同，同一个 Prompt 在 GPT 和 Claude 上的响应风格可能差异很大。有评论者提到：「我的 Prompt 写法本身就会随模型变化，我不知道路由器能不能根据我的措辞正确判断该发给谁。」

订阅制 vs API 付费的矛盾。 有人指出，如果你用的是 Claude Pro 或 ChatGPT Plus 订阅而非 API，路由器的价值就体现不出来，因为它走的是 API 通道。

这些质疑是合理的，但也说明了模型路由这个方向还在快速迭代中，不存在完美的解决方案。

这件事的更大意义#

Weave Router 的走红不是偶然的。它反映了一个正在形成的趋势：AI 编程工具链正在从「单模型」走向「多模型协同」。

过去一年，我们看到 Codex 从最初的单模型 CLI 工具，演进为支持多 Provider 切换的 Agent 平台。Claude Code 也在不断扩展其模型接入能力。Cursor 的「Auto」模式允许按需切换模型。而 Weave Router 把这个趋势推到了一个新的高度：不是手动切换，而是自动化的、基于强化学习的、请求级别的智能路由。

这意味着我们正从「AI 辅助编程」迈向「AI 优化编程」。不止是让 AI 帮你写代码，更是让 AI 帮你管理 AI。当你的编程助手里跑着五六个不同模型时，你不需要关心谁在处理什么，一个智能调度层会替你做好所有决策。

参考来源#