LLM智能路由实践：通过 Harness 工程节约模型成本

这套智能路由不是简单地"随机挑一个模型"，而是 Harness 工程的核心组成部分------在每个 turn 开始时先做一次轻量分诊：根据当前问题和最近上下文，在 low、mid、high 三档业务模型中选择一个最匹配的档位。随后，路由结果会被冻结，贯穿本轮主 Agent、工具调用和子 Agent。

第一阶段解决的是"这件事应该交给多强的模型 "；第二阶段进一步解决"这次生成应该多确定，还是多发散 "，让路由模型额外输出 temperature。两阶段共同构成了 Harness 对模型调用的完整约束体系。

1. 为什么需要智能路由

很多 Agent 系统把模型选择交给用户：在发起任务前，用户先从模型列表中挑选一个模型。

问题在于，用户通常只能形成关于模型能力的模糊认知，很难准确判断某个任务的复杂度，也很难知道不同模型的能力边界。面对不确定性，最自然、也最常见的选择就是"一股脑选最好的模型"：简单问答如此，大规模重构也如此。这个方案看似稳妥，但它把四个问题混在了一起：

成本问题：简单任务不需要最昂贵的模型。
延迟问题：每次都走高能力模型，响应时间很难稳定。
质量问题：模型能力越强，不代表它在所有任务上都更合适。工具编排、精确编辑、结构化输出往往更依赖稳定性，而不是单纯增加推理能力。
模型选择问题：模型选择应该交给平台，而不是让用户凭模糊认知做判断。平台可以通过标准化评测、真实任务数据和持续运行反馈，建立模型能力边界与任务类型之间的映射，再由智能路由为用户自动选择更合适的模型------这比用户自行选择更专业。

这套方案的设计思路就是增加一个独立的路由层。这个路由层不是孤立的模块，而是整个 Agent Harness 工程的第一环------Harness 的职责是约束 Agent 的执行过程，让模型调用从"自由发挥"变成"受控执行"：

这里的设计不是"多了一个模型调用"，而是把模型选择从业务执行中抽离出来------Router 不负责完成用户任务，它只回答一个问题：

当前任务需要多大的模型能力，才足以安全完成？

这是一种典型的入口分诊，也是 Agent Harness 工程的第一道控制闸门。Harness 工程的核心思想是：模型能力本身不是银弹，真正决定 Agent 执行质量的是"在什么场景下、用多强的模型、以什么策略去生成"这三者的匹配度。智能路由就是负责前两者的 Harness 组件。

2. 第一阶段：low、mid、high 三档模型路由

Harness 工程的第一步，是把"选模型"这件事从用户手里收回到平台手里。具体做法是建立三档模型能力档位，由路由模型在入口处做分诊。

2.1 配置不是一个模型，而是一组模型能力档位

SessionModelRouter 的配置核心结构大致如下：

json 复制代码

{
  "model": {
    "router": {
      "base_url": "...",
      "model": "router-model",
      "api_key": "..."
    },
    "low": {
      "model": "small-model"
    },
    "mid": {
      "model": "general-model"
    },
    "high": {
      "model": "strong-model"
    }
  }
}

router 是负责分类的模型，low、mid、high 是真正执行任务的业务模型。每个档位都可以使用独立的 base_url、api_key 和模型名。一个档位还可以配置多个 endpoint，系统会通过 endpoint pool 做轮询选择，形成简单的负载均衡和多来源接入能力。

因此，路由的执行调用路径就变成如下：

2.2 三档分别适合什么场景

路由提示词并不是按照"问题字数"简单分类，而是按照任务是否需要工具、上下文、推理和风险控制来判断。

档位	主要场景	典型例子	核心特点
`low`	真正简单、独立、单轮的任务	简短翻译、基础问答、简单改写、一次性查询	不需要工具，不依赖上下文，成本最低
`mid`	普通 Agent 工作	常规编码、调试、文件编辑、多步分析、工具调用、MCP/CLI/知识库查询	系统的通用工作档
`high`	复杂、高风险、需要强推理的任务	架构设计、大规模重构、长上下文综合、多文件高风险修改、复杂算法、Skill/Workflow 编排	用更强模型换取更高的完成可靠性

有两个规则非常关键：

默认是 mid 。在 low 和 mid 之间拿不准时，选择 mid，避免因为过度节省而让任务落到能力不足的模型。
短消息不能直接判定为 low。像"继续""好的""再改下"这样的追问，必须结合最近上下文。如果上一轮正在做架构重构，用户说"继续"，它仍然应该继承复杂任务的判断。

2.3 Router 自己也要保持稳定

路由模型的职责是分类，不是创作。因此调用 Router 时固定使用 temperature=0，让分诊结果尽可能稳定。

同时，Router 并不会收到完整的 Agent 历史和所有工具消息，会对输入做压缩：

最多保留最近 4 条 user/assistant 纯文本消息；
每条历史最多 200 个字符；
当前用户输入最多 700 个字符；
跳过 system、tool 和带 tool_calls 的消息；
注入上一次的 tier，帮助短追问保持路由连续性。

这是一项很实际的工程取舍：Router 只需要理解任务，不需要重放整个 Agent 执行现场，它的上下文越小，路由开销和延迟越可控。

2.4 一次 turn，一次路由，整轮冻结

Harness 工程的一个关键原则是：执行策略一旦确定，就要在本轮内保持稳定。系统不是每调用一次 LLM 就重新选择一次模型，而是在本轮任务调用一次路由决策，决策包含如下信息：

selected_model：本轮业务模型；
selected_provider：本轮业务 provider；
tier：low、mid、high；
source：路由模型、强制档位、默认回退或错误回退；
confidence、reason：路由模型给出的判断信息；
temperature：第二阶段加入的本轮采样参数。

模型选择被确定后，会沿着这条链路传递：

这条"冻结"语义很重要：假设一个任务第一轮判断为 high，后面它连续调用 5 次工具，模型不应该因为某一轮文本突然变短，就在中途悄悄切到 low------一次任务的模型能力应该稳定，否则执行轨迹会出现不可解释的抖动。这正是 Harness 工程区别于"简单路由"的地方：Harness 不只决定用哪个模型，还负责保证这个决策在整轮执行中不被破坏。

3. 第二阶段：从"选模型"升级到"选生成策略"

如果说第一阶段是 Harness 工程在"模型能力"维度上的约束，那第二阶段就是在"生成策略"维度上的补充。

第一阶段解决了"用什么能力的模型"，但它仍然没有回答另一个问题：

这次输出到底应该更确定，还是更发散？

例如：

精确修改代码、调试 bug、填写工具参数，需要低随机性；
架构设计虽然复杂，但仍然需要严谨、稳定的推理；
头脑风暴、创意命名、开放式写作，则希望模型探索更多可能性。

所以第二阶段把路由决策从一个维度扩展成两个正交维度：

vbnet 复制代码

模型能力：tier
    low / mid / high

采样策略：temperature
    确定性 ───────────── 发散性

3.1 `temperature` 解决的是确定性，不是模型能力

路由提示词明确要求：temperature 与 tier 独立判断。

推荐的语义区间是：

temperature	输出倾向	适合场景
`0.0--0.2`	精确、稳定、低发散	代码修改、调试、工具编排、事实查询、结构化输出
`0.3--0.5`	默认平衡	普通问答、常规分析、正常执行
`0.6--0.9`	发散、开放、多样	头脑风暴、创意写作、多方案生成

注意，复杂度和发散度不是同一回事：

一个 high 档的架构设计任务，可能需要 temperature=0.1，因为它要求严谨；
一个简单的产品名改写任务，可能只需要 low 或 mid 模型，但可以使用 temperature=0.8，因为它希望多给一些创意。

因此，以下组合是合理的：

任务	tier	temperature
把一句话翻译成英文	`low`	`0.1--0.3`
修复一个函数的 bug	`mid`	`0.1--0.2`
设计一个高风险系统架构	`high`	`0.1--0.3`
头脑风暴十个产品名	`low/mid`	`0.7--0.9`