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的配置核心结构大致如下{ 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 时固定使用temperature0让分诊结果尽可能稳定。同时Router 并不会收到完整的 Agent 历史和所有工具消息会对输入做压缩最多保留最近 4 条user/assistant纯文本消息每条历史最多 200 个字符当前用户输入最多 700 个字符跳过 system、tool 和带tool_calls的消息注入上一次的tier帮助短追问保持路由连续性。这是一项很实际的工程取舍Router 只需要理解任务不需要重放整个 Agent 执行现场它的上下文越小路由开销和延迟越可控。2.4 一次 turn一次路由整轮冻结Harness 工程的一个关键原则是执行策略一旦确定就要在本轮内保持稳定。系统不是每调用一次 LLM 就重新选择一次模型而是在本轮任务调用一次路由决策决策包含如下信息selected_model本轮业务模型selected_provider本轮业务 providertierlow、mid、highsource路由模型、强制档位、默认回退或错误回退confidence、reason路由模型给出的判断信息temperature第二阶段加入的本轮采样参数。模型选择被确定后会沿着这条链路传递这条”冻结”语义很重要假设一个任务第一轮判断为high后面它连续调用 5 次工具模型不应该因为某一轮文本突然变短就在中途悄悄切到low——一次任务的模型能力应该稳定否则执行轨迹会出现不可解释的抖动。这正是 Harness 工程区别于”简单路由”的地方Harness 不只决定用哪个模型还负责保证这个决策在整轮执行中不被破坏。3. 第二阶段从”选模型”升级到”选生成策略”如果说第一阶段是 Harness 工程在”模型能力”维度上的约束那第二阶段就是在”生成策略”维度上的补充。第一阶段解决了“用什么能力的模型”但它仍然没有回答另一个问题这次输出到底应该更确定还是更发散例如精确修改代码、调试 bug、填写工具参数需要低随机性架构设计虽然复杂但仍然需要严谨、稳定的推理头脑风暴、创意命名、开放式写作则希望模型探索更多可能性。所以第二阶段把路由决策从一个维度扩展成两个正交维度模型能力tier low / mid / high 采样策略temperature 确定性 ───────────── 发散性3.1temperature解决的是确定性不是模型能力路由提示词明确要求temperature与tier独立判断。推荐的语义区间是temperature输出倾向适合场景0.0–0.2精确、稳定、低发散代码修改、调试、工具编排、事实查询、结构化输出0.3–0.5默认平衡普通问答、常规分析、正常执行0.6–0.9发散、开放、多样头脑风暴、创意写作、多方案生成注意复杂度和发散度不是同一回事一个high档的架构设计任务可能需要temperature0.1因为它要求严谨一个简单的产品名改写任务可能只需要low或mid模型但可以使用temperature0.8因为它希望多给一些创意。因此以下组合是合理的任务tiertemperature把一句话翻译成英文low0.1–0.3修复一个函数的 bugmid0.1–0.2设计一个高风险系统架构high0.1–0.3头脑风暴十个产品名low/mid0.7–0.93.2 动态 temperature 如何进入执行链路当前实现已经把temperature接入了完整的 turn 链路3.3 为什么子 Agent 也要继承 temperature子 Agent 不是一个与父任务无关的新会话它往往是父 Agent 在本轮执行中通过spawn拆出来的子任务。因此SubagentManager会在 spawn 时冻结三元组父任务如果使用temperature0.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-promid档使用glm-5.2或claude-sonnet-5high档使用claude-opus-4.8在开源测试集上路由方案的准确率相比全量 opus 只下降了 2%–5%落在了可接受范围以内。考虑到费用节省 20% 的收益这个精度损失是值得的。换句话说用最强模型做所有事情和用路由把简单任务分流给更便宜的模型最终的结果差异很小——但后者省下的成本是实打实的。5. 结语智能路由是 Harness 工程的一个切面这套智能路由经历了一个很自然的演进第一阶段的价值是成本和能力匹配简单任务不要浪费高能力模型复杂任务不要冒险使用能力不足的模型。第二阶段的价值是执行策略和任务目标匹配代码、调试和工具编排需要确定性创意写作和头脑风暴需要发散性。最终一个成熟的 Agent 系统不应该只有一个”最强模型”按钮而应该具备一套可观察、可降级、可复现的决策机制——这正是 Harness 工程的目标。智能路由是其中负责模型调用的切面它和工具约束、上下文管理、执行回退等机制共同构成了完整的 Harness用tier选择合适的模型能力用temperature控制本次输出的确定性用 turn 级冻结保证主 Agent、工具循环和子 Agent 的策略一致用 Harness 约束执行过程减少工具调用漂移和无效返工用llm_usage和路由 metadata 验证到底省了多少 token、提升了多少成功率。Harness 工程的本质不是让每个请求都变得更聪明而是让每个请求都用刚刚好的能力、刚刚好的随机性在受控的执行框架内完成刚刚好的工作。