SWE-Router 说明了什么：AI 编程任务需要更细的模型路由

AI 编程工具正在从“帮我补一段代码”变成“帮我理解仓库、定位问题、修改文件、跑测试并解释结果”。这类任务看起来是一次请求，实际却是一条多阶段工作流。每个阶段对模型能力的要求不同，用同一个模型从头跑到尾，往往不是最优解。

SWE-Router 这类研究关注的正是这个问题：软件工程任务中的模型路由，不能只看用户最开始输入的那一句话。

编程任务为什么不适合单次路由

很多模型路由方案会根据用户请求本身判断难度，然后选择便宜模型或强模型。这个方法适合简单问答，但放到 AI 编程任务里会变得粗糙。

一次真实的 issue 修复，通常会经历这些步骤：

这些步骤的难度并不一致。文件检索和摘要可能不需要最强模型，关键代码修改和测试失败分析则更依赖强推理能力。如果只根据第一条 prompt 做一次模型选择，就会出现两个问题：要么一路使用强模型导致成本过高，要么一路使用便宜模型导致关键步骤质量不足。

更合理的方式，是把模型路由放进任务执行过程里。

SWE-Router 的思路，是让路由器理解软件工程任务中的执行轨迹，而不是只理解单个问题。它强调代码修复这类任务有持续上下文，路由策略应该根据过程中的信息变化进行判断。

这对团队很有现实意义。AI 编程代理一旦接入真实仓库，调用量会很快上升。一次失败的修复可能触发多轮读取、分析、修改和重试。即使单次 API 价格不高，多个阶段叠加后也会形成明显成本。

如果团队没有路由层，就很难回答这些问题：

这些问题不能只靠供应商控制台解决，因为团队通常会同时使用多个模型和多个工具。

一个更实用的编程任务路由策略，可以按阶段拆分。

第一阶段是上下文整理。包括读取 issue、摘要文件、提取相关路径、识别技术栈。这类任务可以优先使用低成本模型，只要输出结构清楚、召回足够即可。

第二阶段是问题定位。需要模型理解代码关系、调用链和可能的错误原因。这里可以使用中高能力模型，尤其是跨文件逻辑复杂时。

第三阶段是代码修改。这个阶段对准确性要求最高，应该优先使用强模型，或者至少由强模型进行最终校验。

第四阶段是测试和修正。如果测试失败，路由策略应该根据失败类型决定是否继续使用当前模型、切换强模型，或者停止自动重试并要求人工介入。

第五阶段是总结和记录。生成变更说明、PR 描述和风险提示时，可以使用较低成本模型，但关键风险仍需要保留检查。

这种阶段化路由比“这个任务用哪个模型”更接近真实工程需求。

AI 编程工具的成本问题，往往不是某个模型太贵，而是调用链路太长。

例如一个代理在仓库里反复读取大文件、反复生成相似补丁、反复解释同一段测试失败，即使使用中等价格模型，最终账单也可能很高。相反，如果路由层能识别重复上下文、限制重试次数、记录失败原因，并在关键步骤切换模型，整体成本会更可控。

团队还应该按项目设置预算。研发环境、CI 自动修复、生产事故分析和普通代码问答，不应该共用同一套额度规则。不同场景的容错率、时效性和质量要求都不同。

当 AI 编程工具和模型提供方之间有一层统一调用入口，团队就能把路由和记录能力集中起来。

对团队来说，这意味着：

这样做不是为了让模型路由复杂化，而是把复杂性收进一个可管理的位置。

AI 编程代理越强，越不能只按一次 prompt 决定模型。真实的软件工程任务是多阶段、多上下文、多次反馈的过程。每个阶段都可能有不同的成本和质量要求。

SWE-Router 给团队的提醒很清楚：模型路由应该理解任务过程，而不是只理解入口请求。对于正在把 AI 编程工具接入团队研发流程的公司，统一 API 路由、预算控制、重试策略和调用观测会越来越重要。

当 AI 编程从个人工具进入团队基础设施，模型选择就不再是个人偏好，而是一项工程治理能力。