这套智能路由不是简单地“随机挑一个模型”，而是 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 的配置核心结构大致如下：
{
"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、填写工具参数，需要低随机性；
- 架构设计虽然复杂，但仍然需要严谨、稳定的推理；
- 头脑风暴、创意命名、开放式写作，则希望模型探索更多可能性。
所以第二阶段把路由决策从一个维度扩展成两个正交维度：
模型能力：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 |
3.2 动态 temperature 如何进入执行链路
当前实现已经把 temperature 接入了完整的 turn 链路：
3.3 为什么子 Agent 也要继承 temperature
子 Agent 不是一个与父任务无关的新会话，它往往是父 Agent 在本轮执行中通过 spawn 拆出来的子任务。
因此 SubagentManager 会在 spawn 时冻结三元组：
父任务如果使用 temperature=0.15 做精确代码修改，子 Agent 也必须保持相同的生成策略。否则就会出现：父 Agent 在严格执行，子 Agent 却以较高随机性生成工具参数或修改建议，最终把不稳定性重新引入 Harness。
这也是”按 turn 冻结”比”按调用动态变化”更适合 Agent 的原因：同一任务的主 Agent、工具 roundtrip 和子 Agent，应该共享一个可解释的执行策略。这背后是 Harness 工程的一致性原则——Harness 不只约束单次调用，而是约束整条执行链路的策略一致性。
4. 智能路由带来的真实收益：用了更多的 token，费用支出减少了 20% + 任务更精准
如下是 5–6 月 30 天使用的 token 总量：
如下是 6–7 月 30 天使用的 token 总量：
对比结论： token 使用量提升了 3 倍，费用支出减少了 20%。另外从后台数据来看，同一轮对话的质量也同步提升，并未退化。
4.1 任务更精准：质量没有显著退化
费用降了，质量会不会跟着掉？这是最自然的问题。我们在 Agent 测试集上做了对比：
- Baseline：所有任务统一使用
claude-opus-4.8 - 路由方案：
low档使用deepseek-v4-pro，mid档使用glm-5.2或claude-sonnet-5，high档使用claude-opus-4.8
在开源测试集上，路由方案的准确率相比全量 opus 只下降了 2%–5%，落在了可接受范围以内。考虑到费用节省 20% 的收益，这个精度损失是值得的。换句话说：
用最强模型做所有事情，和用路由把简单任务分流给更便宜的模型，最终的结果差异很小——但后者省下的成本是实打实的。
5. 结语：智能路由是 Harness 工程的一个切面
这套智能路由经历了一个很自然的演进：
第一阶段的价值是成本和能力匹配：简单任务不要浪费高能力模型，复杂任务不要冒险使用能力不足的模型。
第二阶段的价值是执行策略和任务目标匹配：代码、调试和工具编排需要确定性，创意写作和头脑风暴需要发散性。
最终，一个成熟的 Agent 系统不应该只有一个”最强模型”按钮，而应该具备一套可观察、可降级、可复现的决策机制——这正是 Harness 工程的目标。智能路由是其中负责模型调用的切面，它和工具约束、上下文管理、执行回退等机制共同构成了完整的 Harness：
- 用
tier选择合适的模型能力； - 用
temperature控制本次输出的确定性； - 用 turn 级冻结保证主 Agent、工具循环和子 Agent 的策略一致；
- 用 Harness 约束执行过程，减少工具调用漂移和无效返工；
- 用
llm_usage和路由 metadata 验证到底省了多少 token、提升了多少成功率。
Harness 工程的本质，不是让每个请求都变得更聪明，而是让每个请求都用刚刚好的能力、刚刚好的随机性，在受控的执行框架内完成刚刚好的工作。
