修复一个代码问题，AI 可能需要反复搜索文件、读取日志、修改代码、运行测试，再根据失败信息继续调整。一次任务背后，往往包含很多轮模型调用。

因此，给编程智能体选择模型，需要同时考虑完成质量和整项任务的费用。

Fireworks 在 9 月 14 日发布的评测中给出了一组值得关注的结果。DeepSeek-V4.1-Flash 在 DeepSWE 上达到与 GPT-6 Astra 相近的准确率，平均每任务成本约为后者的十五分之一。Fireworks 原文

这项结果为持续代码检查、批量修复和测试生成提供了一个新的选型方向。理解它的实际价值，可以从任务表现、缓存机制和模型分工三个方面展开。

如果你需要在工作流中接入API，自由切换全球200+大模型，魔芋提供合规保障、财务开票、企业级网关、技术支持与定制服务，助力更高效地管理应用AI能力。

Konjac AI — Unified AI API for China & Global LLMsThe Konjac AI Large Model Aggregation Platform (Large Model Gateway Platform) specializes in delivering high-performance, low-cost AI model services across multiple categories, empowering developers and enterprises to focus on product innovation.https://www.konjac.ai/sign-up?aff=qBX9

DeepSWE 测什么？看模型能否完成软件工程任务

编程智能体需要在代码环境里连续工作。它接收任务，查找相关文件，调用工具，实施修改，再检查结果。

DeepSWE 用来评估这类软件工程任务。表中的 Pass@1，可以理解为一次尝试完成任务的成功率；Cost/Task 则是评测中的平均每任务成本。

模型	推理设置	DeepSWE Pass@1	平均每任务成本
DeepSeek-V4.1-Flash	max	74.34%	$0.430
GPT-6 Astra	xhigh	74.12%	$6.524
Gemini 3.8 Flash	high	73.83%	$2.362
Claude Opus 5	max	73.65%	$11.838

Fireworks 将这组成绩归为相近的准确率区间，主要差异体现在成本上。以上数字均对应其评测配置。DeepSWE 评测结果

对开发团队而言，这意味着可以把一些频繁发生、结果容易验证的任务纳入自动化流程。

例如，每次提交后检查潜在回归，为已有错误补充复现测试，或者对多个类似问题分别生成修复方案。这些工作执行次数多，单任务成本的差异会逐渐累积。

低成本从哪里来？先看智能体怎样使用上下文

聊天时，用户可能只输入几句话。编程智能体的输入则可能包含代码、工具输出、历史修改和测试日志。

每一轮继续工作，它都需要利用这些信息。任务越长，重复上下文在累计输入中的比重往往越高。

这里涉及两个概念。

KV Cache 是模型处理上下文时保存的中间计算状态，有助于后续生成复用已经计算过的信息。

输入缓存命中 是推理服务识别并复用已有输入计算的情况，通常对应单独的计费规则。

DeepSeek 官方模型卡介绍，V4.1-Flash 对读取输入和生成输出采用不同的激活参数规模，分别为 8B 和 16B，并优化了 KV 缓存占用。模型支持最长一百万 Token 上下文，以及原生图文输入。DeepSeek 官方模型卡

这些设计与编程智能体的工作特点相契合。代码任务需要阅读大量内容，最终交付的修改可能只有一小部分。

Fireworks 的 DeepSWE 运行中，输入缓存命中率达到 99.6%，缓存输入费用仍占总账单约六成。这说明，反复读取上下文已经是智能体的重要成本来源。缓存与费用分析

开发者优化应用时，可以重点检查下面几项。

优化位置	可以怎样处理	希望改善什么
固定任务说明	保持项目规则和工具说明稳定	提高重复输入的可复用性
文件读取	先搜索，再读取相关范围	减少无关代码进入上下文
测试日志	保留失败原因与关键堆栈	控制冗长工具输出
长任务状态	定期整理已完成事项和下一步	减少重复探索
用量统计	分别记录缓存输入、普通输入和输出	找到实际费用来源

这些是应用层的优化建议。具体缓存策略应根据所选服务的接口规则实施，并通过返回用量验证效果。

哪些开发任务适合先试

选择第一批任务时，可以优先考虑输入清楚、范围集中、验收方式明确的工作。

应用场景	提供什么材料	要求什么结果
Bug 修复	报错、复现步骤、相关代码	修复补丁与验证结果
回归测试补充	历史缺陷和预期行为	能覆盖问题的测试
批量代码维护	明确的修改规则和文件范围	一致的修改与检查记录
PR 初步审查	代码差异、相关调用关系	问题位置、触发条件、验证建议
失败构建排查	构建日志、环境信息	原因定位与修复方案

以 Bug 修复为例，可以这样组织任务。

根据报错和复现步骤定位问题，先确认触发条件，再修改相关代码。补充能够覆盖该问题的回归测试，运行受影响的测试，并说明修改原因、验证结果和仍需人工确认的事项。

这份任务包含完整的工作顺序，也让结果容易检查。

对于批量维护，建议把每个修改单元拆得足够清楚。例如某类 API 调用的参数迁移，可以按模块分别执行，再集中审查变更。任务拆分后，也更容易统计哪些类型成功率高、哪些需要升级处理。

与 Astra 怎么选？按任务类型安排

Fireworks 还测试了终端任务和学术推理任务。结果表明，两款模型的优势会随任务变化。

评测	DeepSeek-V4.1-Flash	GPT-6 Astra
Terminal-Bench 2.1	86.5%	87.5%
HLE	34.52%	50.40%

HLE 是覆盖高难度学术问题的评测。在这组结果中，Astra 在复杂学术推理上有明显优势。其他任务表现

据此，可以设计一套待验证的任务分配方案。

让 DeepSeek-V4.1-Flash 先处理常规修复、测试补充和批量维护；涉及高难度研究、复杂推理，或者连续尝试仍未解决的问题，再交给 Astra。

在编程场景中，切换模型的依据最好来自可观察的结果。例如测试持续失败、修改范围不断扩大、同一错误反复出现，或任务需要重新制定方案。

切换时，把已定位的问题、相关文件、尝试过的修改和失败证据一起交给下一个模型。这样可以减少重新阅读和重复尝试。

多模型组合，怎样发挥各自长处

Fireworks 还做了一项“理想路由”实验，将两款模型的 HLE 答案进行选择，组合得分达到 54.80%。

这里的理想路由，是在能够判断答案对错的条件下选择结果，用来观察模型之间的互补空间。它说明两款模型能解决的问题存在差异，实际系统则需要额外的判断机制。组合评测说明

软件工程任务有一个实用优势，很多结果可以通过工具验证。

应用可以利用测试、静态检查和构建结果判断候选补丁是否满足要求，再决定接受、继续修改或升级模型。

一套简单流程可以这样安排。

分配任务 → 生成修改 → 运行验证 → 整理失败信息 → 继续处理或升级模型

开发者需要认真设计的是验证环节。测试应覆盖原始问题和相关行为，检查结果也要保留，方便人工审查。