Coding Agent 降本，不能只看 Token 单价

当团队开始大规模使用 Coding Agent，模型费用很快会成为一个需要管理的问题。

最容易想到的办法，是换成更便宜的模型。比如，只是让 Agent 查询一段代码的位置，或者修复一个简单的文案问题，似乎没有必要调用最昂贵的模型。

但如果换模型之后，任务需要反复重试，生成的代码还得工程师花时间修复，最后是否真的省钱，就不好说了。

10 月 1 日，LangChain 公开了一项模型路由实验。他们在开源 Coding Agent Open SWE 中，根据任务类型和复杂度选择不同模型，并与固定使用高能力模型的方案进行了 A/B 测试。

973 条真实任务线程的实验结果显示：

LangChain 是怎样判断哪些任务可以使用低成本模型的？成本降低之后，又如何检查实际交付效果？

我们从他们的任务分析和路由实现看起。

随着 Open SWE 的使用量增长，LangChain 的模型开销也在增加。此前，Open SWE 默认使用高能力模型处理请求，但工程师交给它的任务差异很大：有的是实现新功能，有的是修复 Bug，也有的只是查询代码或执行测试。

为了判断这些任务是否都需要高能力模型，团队首先分析了 LangSmith 中一周的真实执行记录，包括任务类型、调用次数和模型成本。

结果显示，新功能开发约占 22%，Bug 修复约占 17%，测试或无实际修改类任务约占 16%。这些类别由模型根据线程标题和元数据辅助归纳，属于启发式分类。

研究团队进一步发现，功能开发中的调查任务往往需要更多轮调用、消耗更高；测试和发布相关任务则通常更短。

任务之间的差异，让团队决定尝试模型路由：为相对简单的任务使用低成本模型，将高能力模型留给复杂研发工作。

他们根据模型能力与成本的关系，选择了三档模型。

不同档位的模型来自不同提供方。

实际执行时，一个分类器读取工程师提交的任务描述，根据预先定义的标准选择档位，再交给对应模型处理。

这套方案没有修改 Open SWE 的基本工作流程，路由逻辑被放进了 Agent 的 Harness。

Harness 可以理解为 Agent 外部负责组织任务上下文、接入工具、管理执行过程的工程系统。

模型路由需要知道当前任务是什么、Agent 具备哪些工具、项目有哪些要求。通用模型网关通常掌握请求与模型参数，但未必了解这些工程上下文。

LangChain 因此将路由实现为 Harness 内的中间件，由分类器读取每个线程的第一条用户消息，选择模型档位。

这套实现目前只在线程开始时选择一次模型，后续默认沿用。如果任务中途发生变化，例如一开始只是查询代码，后来变成复杂 Bug 修复，路由器不会自动重新选择模型。

这也是当前方案仍需改进的地方。

比较模型路由前后的 Token 消耗和账单，就能判断模型开销有没有下降。但如果节省费用的同时，导致更多任务失败，这样的优化也很难在真实研发中持续使用。

LangChain 因此使用真实流量开展 A/B 测试，将 973 条任务线程随机分成两组。一组使用模型路由，另一组始终使用 GPT-6 Astra。

评估过程中，他们没有仅仅比较生成的代码数量或执行轮次，还将 PR 是否合并作为主要结果指标，并收集用户点赞、点踩等反馈。

实验得到以下结果：

合并 PR 比例的统计检验得到 p = 0.49，未检测到显著差异。

在这批真实任务中，模型路由明显降低了所测模型成本，而主要交付指标没有观察到统计显著的变化。

不过，这还不能证明两个方案的代码质量完全相同。

PR 被合并，是一个有实际意义的指标，却不能完整覆盖后续缺陷、代码可维护性、人工评审成本和返工情况。LangChain 也收集了用户反馈，但只有一小部分线程获得明确评价，因此反馈数据的覆盖范围有限。

再看模型分配情况。使用路由的线程中，34% 分配给 Fast，56% 分配给 Balanced，只有 10% 分配给 Performance。

也就是说，在这批任务中，90% 的线程最终由 Fast 或 Balanced 档位处理。

这解释了模型成本下降的重要原因：原先全部使用高能力模型的做法，为大量简单或中等复杂度的任务支付了额外费用。

LangChain 也测试过相反的方案：将一组线程全部交给最便宜的 Fast 模型处理，试图进一步降低成本。

但实验不到一天就提前停止了。工程师很快反馈，Fast 模型在部分任务上的输出质量明显不足，已经影响正常工作。由于实验提前停止，数据不足以进行有意义的统计推断。

两次实验呈现出不同的结果。全部使用高能力模型容易增加开销，全部使用低成本模型又可能影响交付。模型路由尝试根据任务要求，在能力和成本之间作出选择。

LangChain 主要根据任务选择一档模型。

GitHub 同期公开预览的 HydraFusion 则尝试让系统进一步选择执行方式，提供三种模式：

简单任务可能只需要一次生成，复杂任务则可能需要升级模型或增加评审。

不过，HydraFusion 在当时仍处于研究预览阶段，不能直接推断这些模式在所有研发任务中都能降低成本。

它展示了另一种设计思路：模型选择可以与执行策略一起优化，但这样也会增加成本计算的复杂度。

例如，模型切换可能导致原有 Prompt 缓存失效，后续模型需要重新读取上下文；增加独立评审，也会带来新的模型调用。

因此，计算任务成本时，需要把模型升级、检查和重试都包含进去。

很多 Coding Agent 会反复携带仓库规则、工程上下文和历史会话。Prompt Caching 可以复用部分已处理的输入，减少重复计算，但缓存命中率高，不一定代表整个任务费用更低。

Arize 最近发布了一项缓存对比实验，让四条不同模型与提供方路径处理相同的多轮购物助手任务。

其中一条路径的缓存读取比例达到 89.8%，但最终估算成本仍然是四组中最高的，原因之一是输出 Token 占据了较高的费用比例。

这项实验同时涉及不同模型和提供方，不能用来单独比较缓存机制的优劣，也不能将结果直接推广到 Coding Agent。

缓存命中率只能反映输入复用情况。实际费用还受到模型价格、输出量、调用次数以及执行路径的影响。

对于需要多轮修改、测试和评审的 Coding Agent，这些开销更需要放在同一条任务记录中分析。

回到研发团队的实际使用场景。

如果只想降低模型账单，可以从模型价格、缓存和 Token 消耗入手。但当 Coding Agent 开始承担更完整的研发任务，还需要回答另一个问题：

完成一项符合要求的研发任务，实际需要多少投入？

比如，同一批历史需求分别使用两套模型配置。

方案 A 的模型费用较低，却出现更多重试和人工修复；方案 B 的模型费用稍高，但首次生成通过了更多验证，工程师投入的修复时间也更少。

仅比较模型费用，可能会得到与真实交付成本相反的结论。

对于研发团队，我倾向于分三层衡量。

第一层：模型与工具成本。

记录每条任务的输入、输出 Token，模型选择、缓存使用、工具资源和调用费用。

第二层：任务执行成本。

记录任务时长、调用次数、重试、评审和验证过程，分析开销主要消耗在哪些步骤。

第三层：有效交付成本。

进一步关联任务是否通过验收、需要多少人工参与、发生多少返工。

这里需要建立稳定的任务分类和验收口径。否则，一组全是简单修改，另一组主要是复杂功能开发，两组平均成本直接比较没有意义。

LangChain 的实验仍有局限，但它已经用真实任务数据建立模型路由，再通过线上实验检查成本与交付结果。

对于准备规模化使用 Coding Agent 的团队，可以从历史需求回放开始：整理任务类型，建立一批有明确验收依据的测试集，对照不同模型配置的成本、通过情况和人工投入，再决定哪些任务适合低成本模型。

随着任务类型和模型能力变化，路由规则也需要重新评估。

Coding Agent 的成本优化，最终需要回到交付结果。

模型路由能够减少不必要的高成本调用，缓存能够降低重复输入的开销。但一项研发任务究竟省了多少钱，还要把验证、返工和人工参与计算进去。

能够持续衡量这些数据，团队才有依据判断：哪些成本可以降低，哪些投入能够换来更可靠的交付。