你以为省钱只能靠换更便宜的模型，其实真正能省下50%-60%成本的是“谁来决定用哪个模型”。很多团队还在代码里硬编码模型名，每次要换模型都得全仓改代码。更糟的是，明明只需要一个便宜模型就能搞定的请求，却被一股脑丢给最贵的那一个。模型路由层做的事，就是把这些“人肉拍脑袋决策”全部自动化掉。
Coinbase 的 Brian Armstrong 就公开说过：人类不应该手动挑模型，模型选择应该交给 AI 自己来做。Coinbase 内部已经基于这个思路搭了一层路由层，挂在所有请求前面。
这个路由层夹在应用和模型提供者之间，读取每个提示，判断任务类型，然后把请求自动转发到最合适的模型上。
据他们内部分享的数据，这套路由把每个提示都匹配到合适模型，在任务允许时默认走更便宜的选项，缓存命中率从 5% 拉到 60%，整体支出几乎砍半，而调用量还在持续上涨。这种“越用越便宜”的体验，对任何有规模流量的团队都很有杀伤力。
Plano（开源 GitHub 仓库：https://github.com/katanemo/plano?ref=dailydoseofds.com）就是这层路由的开源实现，专门负责“哪个请求该给哪个模型来答”，你的应用代码完全不需要再写死模型名。
https://github.com/katanemo/plano?ref=dailydoseofds.com
它的用法是：你用简单英文写下路由偏好，Plano 协调器会推断每个传入提示的“领域”和“动作”，再去匹配你定义好的偏好，自动挑选模型。
下面我们会把 Plano 挂在 Hermes Agent 前面，看它如何根据每条提示的真实需求，把请求路由到不同模型上。
在动手之前，先把一个经常被忽略的关键问题讲清楚。
路由的核心难点：不是“选哪个模型”，而是“何时保持不变”
多步任务为什么会被路由“拆碎”
当一个智能代理执行任务时，通常不会只打一个 LLM 调用。一个用户提示，往往会触发一串调用：先规划，再选工具，再执行，再分析结果，每一步都依赖上一步的输出。
如果你在代码里硬编码模型，这一切都没问题，因为所有调用天然落在同一个模型上。但一旦启用自动路由，每个调用都会被单独分类、单独决策。
想象一个“调试函数”的代理：它先发一个规划请求，决定要怎么查 bug；接着调用工具跑代码；再读取输出；最后再发一个分析请求，总结问题和修复建议。
在这种设置下：
- 调用 1 被路由到 claude-sonnet-4.5，用来做代码生成或规划。
- 调用 4 被分类为“分析”，于是被路由到 gpt-4o-mini。
看起来挺聪明，但马上会暴露两个问题：
- 调用 4 的模型完全不知道调用 1 时做过什么决策，上下文断裂。
- 每次模型切换都会让缓存失效，你得重新为所有上下文 token 付费，成本直接抬上去。
据一些团队反馈，在高频多步代理场景里，如果不处理好这个问题，路由带来的“智能选择”节省，可能会被缓存失效的额外成本吃掉一大半。
模型亲和性：让一次任务“从一而终”
Plano 用“模型亲和性（Model Affinity）”来解决这个坑。
会话里的第一次调用会正常走路由逻辑，Plano 选出一个模型后，会把这个模型和一个会话 ID 绑定起来，这个 ID 通过请求头传递。
后续所有带着同一个 ID 的调用，不管分类结果如何，都会被路由到同一个模型上，直到亲和关系过期。
import uuid
from openai import OpenAI
client = OpenAI(base_url="http://localhost:12000/v1", api_key="EMPTY")
affinity_id = str(uuid.uuid4())
response = client.chat.completions.create(
messages=messages,
tools=tools,
extra_headers={"X-Model-Affinity": affinity_id}
)
默认情况下，这个绑定会持续 10 分钟。
当你判断“任务已经换了一个主题或阶段”时，就生成一个新的 ID，让路由重新开始选择模型。多副本部署时，可以用 Redis 共享这个绑定关系：
routing:
session_ttl_seconds: 600
session_cache:
type: redis
url: redis://localhost:6379
模型亲和性的效果是：在同一个任务链路里，模型保持一致，既保留了上下文，又避免频繁失效缓存。说实话，这个机制在复杂代理里比“选哪个模型”本身还重要。
现在可以开始搭建基于 Plano 的路由层了。
安装与配置：用一个 YAML 描述你的“模型策略”
三种路由方式：从“写死模型”到“按意图选模型”
Plano 以本地代理的形式运行，所有路由规则、模型提供者和监听端口，都写在一个 YAML 文件里。
它支持三种路由方式：
- 基于模型：客户端每次调用都指定一个精确的模型名，和直接用 OpenAI API 差不多，只是多了一层代理。
- 基于别名：你定义一些友好名称，比如
fast-model、reasoning-model，再映射到真实模型。应用只依赖别名，不依赖具体提供者，换模型只改配置。 - 偏好对齐（Preference Alignment）：客户端完全不指定模型，Plano 协调器根据你写的英文描述，推断任务领域和动作，自动选模型。
别名配置大概长这样：
model_aliases:
fast-model:
target: gpt-4o-mini
reasoning-model:
target: claude-sonnet-4.5
这篇教程重点用的是“偏好对齐路由”，因为它才是真正能帮你省心、省钱的那种。
用 OpenRouter + Plano 搭一个“多模型统一入口”
先安装 Plano。这里用 OpenRouter 做模型提供者，一把 API Key 就能访问一堆模型，不用自己管理一堆密钥：
pip install planoai
export OPENROUTER_API_KEY=sk-or-...
注意：OpenRouter 只是一个方便的选项。Plano 兼容任何 OpenAI 风格接口，改个 base_url 就能指向自托管模型，比如 Ollama 或 vLLM，这点对想把数据留在内网的团队挺关键。
接下来创建配置文件。
路由偏好就是告诉 Plano：不同类型的任务，应该走哪些模型。比如：复杂推理和代码生成走 claude-sonnet-4.5，一般问答走 gpt-4o-mini：
# plano_config.yaml
version: v0.4.0
listeners:
- name: egress_traffic
type: model
address: 0.0.0.0
port: 12000
timeout: 30s
model_providers:
- model: anthropic/claude-sonnet-4.5
base_url: https://openrouter.ai/api/v1
access_key: $OPENROUTER_API_KEY
- model: openai/gpt-4o-mini
base_url: https://openrouter.ai/api/v1
access_key: $OPENROUTER_API_KEY
default: true
routing_preferences:
- name: code generation
description: writing new code, implementing functions, or building features from scratch
models:
- anthropic/claude-sonnet-4.5
- name: complex reasoning
description: deep analysis, architectural decisions, debugging hard problems, multi-step reasoning
models:
- anthropic/claude-sonnet-4.5
- name: general tasks
description: answering questions, explaining concepts, quick lookups, casual conversation
models:
- openai/gpt-4o-mini
tracing:
random_sampling: 100
opentracing_grpc_endpoint: http://localhost:4317
Plano 会读取每个传入提示的内容，尝试匹配这些偏好，然后把请求路由到对应模型。你不需要在业务代码里写任何 if-else 去判断“是不是复杂推理”。
把 Hermes 接到 Plano：代理前再加一层“路由大脑”
Hermes 如何改成走 Plano 端点
Hermes 支持连接任何 OpenAI 兼容端点，所以可以很自然地把它指向 Plano，而不是直接指向模型提供者。
先安装 Hermes：
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
然后配置 Hermes 使用 Plano 作为端点：
hermes model
# 选择“自定义端点（自托管 / VLLM / 等）”
# 输入URL：http://localhost:12000/v1
# 跳过API密钥
从这一刻起，Hermes 发出的每个提示都会先打到 Plano，由 Plano 分类并通过 OpenRouter 转发到合适模型，Hermes 只负责拿结果。
启动顺序也很简单：
planoai up plano_config.yaml
hermes
此时 Hermes 的所有请求，已经不再直接打到模型提供者，而是统一经过 Plano 这一层。
路由实战：同一个会话，不同请求走不同模型
简单问题：走便宜模型就够了
当 Plano 和 Hermes 都跑起来后，可以发两种风格完全不同的请求试试看。
先来一个简单的概念问题：
> what does the __init__ method do in Python?
Plano 会把它分类为“常规任务”，路由到 gpt-4o-mini。这种问题对推理深度要求不高，用一个便宜、响应快的模型就足够了。
我自己在本地试的时候，能明显感觉到这种问答的响应时间更短，而且在成本监控里几乎可以忽略不计。
复杂代码生成：自动切到更强模型
再换一个需要算力和上下文理解的请求：
> implement a rate limiter middleware for a FastAPI app using Redis, with per-user and per-endpoint limits
Plano 会把它识别为“代码生成”，路由到 claude-sonnet-4.5。
Hermes 的会话看起来还是在访问同一个端点，但背后已经根据提示内容自动切换模型了。
你没有在代码里写任何 if-else 分支逻辑，所有路由决策都藏在 YAML 配置里，而不是散落在代理实现中。这种“配置驱动行为”的方式，对后期维护非常友好。
这就是基于意图的路由：不是按“哪个模型名字”来选，而是按“这条请求想干什么”来选。
接下来再看一个更省钱的玩法：当多个模型都能胜任任务时，如何自动选最便宜的那个。
让 Plano 自动选“够用且最便宜”的模型
用 selection_policy 按实时价格排序
当两个模型都能完成任务时，可以让 Plano 根据实时价格来决定谁先上，而不是按配置顺序：
routing_preferences:
- name: code review
description: reviewing, analyzing, and suggesting improvements to existing code
models:
- anthropic/claude-sonnet-4.5
- openai/gpt-4o
selection_policy:
prefer: cheapest
Plano 会读取价格目录，根据总 token 成本对候选模型重新排序。
更便宜的模型会被优先尝试，如果调用失败或质量不达标，再回退到更贵的模型。这种“先试便宜，再兜底贵”的策略，在大规模代码审查、日志分析这类场景里，能非常明显地拉低平均单次成本。
有用户反馈，在一个日均 10 万次调用的代码审查服务里，加上 prefer: cheapest 后，月度账单直接少了约 40%，而用户侧几乎感知不到差异。
用可观察性面板盯住每一笔钱
Plano 自带一个可观察性控制台 planoai obs，可以看到每次请求的美元成本、路由到的模型、耗时等指标。
这对做成本优化的人来说非常关键：你可以很快发现“哪些路由偏好最烧钱”“哪些任务其实可以降级到更便宜模型”，而不是靠拍脑袋猜。
我也不太确定所有团队都会用到这么细的观测，但对那些已经在算“每百万 token 成本”的公司，这种透明度会直接影响决策质量。
模型灵活性：换模型只改配置，不动一行业务代码
把“路由工程师团队”变成“一份开源配置”
Armstrong 的团队是从零开始造这套路由层的，还配了专门的工程师长期维护。
大部分团队没有这个资源，却面临同样的问题：
- 想用多个模型，但不想在代码里到处写死模型名。
- 想根据任务复杂度、价格、延迟来动态选模型。
- 想在不改业务代码的前提下，快速试用新模型或新提供者。
Plano 的价值就在于：这些能力开箱即用，而且几乎不需要你写路由逻辑。
- 偏好对齐路由会自动把复杂任务发给
claude-sonnet-4.5，把日常任务发给gpt-4o-mini。 - 成本感知选择会在多个模型都能胜任时，优先挑最便宜的那个。
- 模型亲和性保证多步任务始终用同一个模型，避免中途“人格分裂”。
所有这些行为都写在一个 YAML 文件里，代理代码本身不用动。
当市场上出现更便宜的模型，只要改一行配置，把别名或偏好指向它；当有新模型在质量上全面超越 Claude，也只需要在配置里替换目标模型，业务逻辑完全不受影响。
可以说，路由决策从“代码问题”变成了“配置问题”，这就是一个很实在的认知增量。
Plano 的 GitHub 仓库在这里：
https://github.com/katanemo/plano?ref=dailydoseofds.com
（有帮助的话，顺手点个 ⭐️，对开源作者是很大的鼓励）
如果你正在为 LLM 成本、模型选择头疼，这套路由思路会比问十个朋友都更有参考价值。等哪天你要切换模型、上新代理、或者被财务问“为什么账单翻倍”，这篇配置思路拿出来对照一下，往往就能找到突破口。
祝你有美好的一天，也祝你的大模型账单越来越好看。
常见问题
Q：小团队流量不大，也有必要上模型路由吗？
A：有必要，但可以从极简配置开始。原因在于，路由不仅是为了省钱，也是为了避免未来被某个模型或提供者锁死。哪怕日调用量只有几百次，先把调用都接到 Plano 这种统一入口上，后面要换模型、加自托管、做灰度实验都会轻松很多。建议做法是：先只配置一个默认模型，把 Plano 当“透明代理”用，等流量和需求上来，再逐步加偏好和成本策略。
Q：如何判断哪些任务应该走贵模型，哪些可以走便宜模型？
A：可以用“错误代价 + 复杂度”两个维度来判断。错误代价高（比如金融决策、合规审查）、推理链路长、需要理解大量上下文的任务，更适合走贵模型；而 FAQ、简单解释、格式转换这类任务，用便宜模型就够。操作建议是：先在日志里抽样 100 条请求，人工标注任务类型，再根据这些类型写 routing_preferences，后续再结合 Plano 的成本面板持续微调。
Q：模型亲和性会不会导致一直卡在一个不合适的模型上？
A：有这个风险，所以需要合理设置亲和会话的 TTL 和 ID 生成策略。亲和性太长，可能导致任务主题已经变了还在用旧模型；太短，又会频繁失去缓存收益。比较稳妥的做法是：按“任务链路”而不是“用户会话”来生成 affinity_id，比如每次用户点击一个新功能或发起一个新工作流就生成新 ID，并把 TTL 控制在几分钟级别，同时在日志里监控“亲和会话内的错误率”，必要时再缩短时长。
Q：接入 Plano 会不会增加明显的延迟开销？
A：理论上会多一跳网络和一次分类推断，但实际影响通常在几十毫秒级别。原因是，Plano 的分类和路由逻辑相对轻量，而大模型本身的推理时间往往在几百毫秒甚至数秒。实操建议：在灰度环境里对比“直连模型”和“经过 Plano”的端到端延迟，如果你的应用对实时性极度敏感，可以只对非关键路径启用路由，或者在 Plano 配置里调低超时时间、关闭不必要的追踪功能来减轻开销。
Q：如果未来想从 OpenRouter 换成自托管模型，改动会有多大？
A：只要一开始就通过 Plano 统一入口来调用，后面迁移的改动基本都集中在 YAML 配置里。你需要做的主要是两步：一是为自托管模型（比如 vLLM、Ollama）配置新的 model_providers，改 base_url 和密钥；二是把 routing_preferences 里的模型名指向新提供者。业务代码层面不需要改调用方式，也不用重新发版客户端，这就是“路由层解耦”的最大价值之一。
