代码智能体中的模型分级路由实践

作者：carzy2026.11.07 02:03浏览量：0

简介：本文讨论编程智能体执行终端命令、运行测试、解析报错与归纳日志等高频低复杂度任务时，如何通过模型分级路由把昂贵模型留给真正需要推理的环节。读者将掌握任务分层、路由策略、成本度量与工程落地的完整方法，在不牺牲交付质量的前提下显著降低Token开销。

代码智能体中的模型分级路由实践

一、问题的提出：昂贵模型在做廉价劳动

在基于大模型的编程智能体（Coding Agent）中，一个典型的工作循环往往包含大量”低智力密度”的操作：执行一条终端命令并读取退出码、运行测试套件并收集失败用例、解析编译器或运行时的报错堆栈、把冗长的构建日志压缩成几行结论、判断某个文件是否存在并读取其内容。这些动作占据了智能体交互轮次的绝大部分，却几乎不需要复杂推理。

然而，许多实现会把这些步骤全部交给能力最强、单价最高的旗舰模型来驱动。每一次”读一下这个文件””再跑一次测试”都要消耗一次完整的上下文推理，Token 成本随之线性攀升。当智能体的调用频次上升到每天数千次会话、每次会话数十轮交互时，这种浪费就会被放大为可观的账单，同时推高首字节延迟，拖慢整个反馈回路。

核心矛盾在于：任务复杂度呈长尾分布，而模型选择却常常是单一档位。解决办法不是换更便宜的模型，而是建立一套按任务复杂度动态分派的机制——即模型分级路由（Model Tiering / Model Routing）。

二、任务分层：先分清哪些活该由谁干

在谈路由之前，必须先对智能体的动作空间做分类。一个实用的划分方式是按”认知负荷”与”错误代价”两个维度切分：

第一层：确定性执行类。 包括运行 shell 命令、调用构建工具、执行测试、读写文件、拉取环境信息。这类动作的决策逻辑极简——参数已由上层规划给出，模型只需生成结构化调用并解读原始结果。错误代价低，重试成本低，非常适合小参数模型甚至规则引擎处理。

第二层：结构化解析类。 包括从测试输出中提取失败断言、从堆栈中定位首个业务代码帧、把多行日志归并成”现象—原因—影响”三段式摘要、判断报错属于环境问题还是代码问题。这类任务需要一定的模式识别与格式化能力，但不涉及开放式推理，中等规模模型即可胜任。

第三层：开放式推理类。 包括根据失败现象提出修复假设、设计跨文件的修改方案、权衡多种重构路径、处理需求歧义。这才是旗舰模型真正不可替代的场景，也是成本应当集中投放的地方。

分层的意义在于：把”生成动作”与”执行动作”解耦。上层规划一旦产出明确的指令，下层的执行与解读就应当交给更轻的模型，而不是让规划模型事必躬亲。

三、路由策略：如何决定一次请求交给谁

路由器的设计要解决三个问题：用什么信号判断、在什么时机判断、出错如何回退。

3.1 判断信号

实践中常用的信号有几类：

  • 任务类型标签：由上层规划在生成动作时附带，例如 exec、parse_log、inspect、plan、repair。这是最直接也最可靠的信号，成本几乎为零。
  • 输入规模特征：上下文 Token 数、待解析文本行数、涉及文件数量。规模大但结构规整的日志解析，往往比规模小但语义模糊的需求澄清更适合轻模型。
  • 历史成功率：对同类任务维护轻模型的通过率统计，低于阈值时自动升级到大模型。
  • 不确定性度量：轻模型输出置信度低、或多次重试仍失败时，触发升级。

3.2 路由决策的伪代码

  1. def route(task):
  2.     # 显式标签优先
  3.     if task.kind in ("exec", "read_file", "run_test"):
  4.         return LIGHT_MODEL
  5.     if task.kind == "parse_output":
  6.         return LIGHT_MODEL if task.input_tokens < PARSE_THRESHOLD else MID_MODEL
  7.     if task.kind in ("plan", "repair", "design"):
  8.         return FLAGSHIP_MODEL
  9.     # 无标签时按规模与历史表现兜底
  10.     if task.input_tokens < SMALL_THRESHOLD and success_rate(task.kind) > 0.9:
  11.         return LIGHT_MODEL
  12.     return MID_MODEL

关键在于升级路径必须存在：轻模型执行失败或产出无法解析时，同一请求应能自动重投给上一档模型，并携带失败原因作为附加上下文。这样既保证兜底质量，又避免一开始就用最贵的档位。

3.3 降级与缓存

除了向上升级，还应设计向下沉淀：当某一类任务在旗舰模型上被反复以相同模式解决时，可将其固化为模板或规则，后续直接由轻模型套用。同时，对确定性执行类动作的结果做会话内缓存，避免同一命令在同一会话中被重复推理多次。

四、成本度量：让优化可被验证

没有度量就没有优化。建议从三个维度建立观测：

  1. 每会话 Token 消耗：按模型档位拆分统计，观察旗舰模型占比是否收敛到合理区间（经验上，规划与修复类请求的 Token 占比应显著低于其请求数占比）。
  2. 每任务成本：以”完成一次测试修复”为单位计算端到端成本，而非只看单次调用价格。
  3. 质量指标：任务成功率、平均重试次数、人工接管率。成本下降若伴随成功率下滑，说明路由阈值设置过激。

需要强调的是，分级路由的收益并非来自”用便宜模型替代贵模型”这一简单替换，而是来自把贵的算力用在刀刃上。若度量显示旗舰模型仍承担了大量解析类请求，说明标签体系或阈值需要调整。

五、工程落地的几个注意点

上下文一致性。 不同档位模型的上下文窗口与指令遵循能力存在差异。轻模型接手的请求应尽量携带精简后的结构化上下文（如”失败用例列表 + 相关代码片段”），而非整段原始日志，否则容易因信息过载而失准。

输出契约统一。 所有档位应遵循同一套结构化输出协议（如 JSON Schema），使上层编排逻辑无需感知底层模型差异。解析失败即视为执行失败，触发升级。

可观测与可回放。 记录每次路由的决策依据、实际使用的档位与结果，便于事后回放分析。当某类任务的路由判断持续出错时，应能快速定位是标签缺失还是阈值不当。

安全边界。 执行终端命令、写入文件等动作应始终经过权限校验与沙箱约束，与模型档位无关。轻模型不应因为”更便宜”而获得更宽松的执行权限。

六、结语

编程智能体的成本结构，本质上反映的是任务复杂度分布与模型能力档位的匹配程度。把终端执行、测试运行、报错解析、日志归纳这类工作交给旗舰模型，短期看省事，长期看是把预算消耗在了最不需要推理的环节。建立任务分层、显式路由、失败升级、成本度量的闭环，才能在保证交付质量的同时把 Token 开销压到合理水平。对于在云平台上规模化运行智能体的团队而言，这套机制也是把单位任务成本纳入可控范围的基础设施之一。

最热文章