关于大模型编程能力的讨论，正在从“哪家模型更聪明”转向更具体的问题：在真实软件工程任务里，模型能否稳定地修改代码、运行测试并提交可接受的补丁？Fireworks AI 的一组对照实验给出了一个值得关注的信号：在同一个 agent harness 中，Kimi K3 与 Fable 5 完成了 1030 个真实 agent 任务，开源模型在 SWE-bench 类场景下已经接近商业模型。
这并不意味着两个模型在所有任务上完全等价，但它说明模型名称、API 价格和“闭源/开源”标签，都不能替代一套可复现的工程评测。
同一个 Harness，比单次 Demo 更有价值
这次测试最关键的地方，不只是任务数量达到 1030 个，而是 Kimi K3 和 Fable 5 被放进了同一个执行框架。对于代码 Agent 来说，模型本身只是系统的一部分，最终结果还会受到以下因素影响：
- 系统提示词如何描述任务和工具；
- 模型能否读取仓库、搜索符号和查看测试；
- 是否允许多轮思考、反复修改和重跑测试；
- 工具调用失败后如何恢复；
- 最终用什么规则判断补丁是否有效。
如果两个模型使用不同的上下文窗口、不同的工具权限或不同的重试策略，结果很容易变成“工作流对比”，而不是“模型对比”。统一 harness 的意义，就是尽量固定这些外部变量，让结果更接近模型在真实编码流程中的表现。
这也是 SWE-bench 类评测比代码补全 Demo 更接近生产环境的原因。一个补全得很漂亮的函数，并不代表模型能够定位跨文件缺陷、理解已有测试、处理回归问题，或者在不破坏其他行为的前提下完成修改。
“几乎打平”应该怎样理解
“几乎打平”是一个有价值但需要谨慎使用的结论。它至少说明，在这批真实任务和当前执行配置下，Kimi K3 的端到端任务完成能力已经逼近 Fable 5。对工程团队来说，这比单纯比较公开基准分数更有参考意义，因为最终交付通常看的是补丁是否通过测试，而不是模型在某个静态题库上的答题分数。
但这并不等于 Kimi K3 和 Fable 5 在所有维度都一样。一个完整判断还应该观察：
- 任务级通过率，而不是只看平均分；
- 不同仓库、语言和缺陷类型的分布；
- 首次尝试成功率与重试后的成功率；
- 每个任务消耗的 token、工具调用次数和运行时间；
- 补丁是否只是通过现有测试，还是也保持了合理的代码质量；
- 失败是否集中在上下文过长、复杂重构或隐含行为变化等场景。
尤其要注意测试集的构成。1030 个任务是一个有分量的样本，但样本分布仍然会影响结论。若任务主要集中在某些语言或常见修复类型，模型的优势可能会被放大；若任务包含更多大型重构、模糊需求和跨模块修改，排名也可能发生变化。
价格差异会改变模型选择逻辑
此前的讨论聚焦于一个现实问题：如果 Fable 5 的调用成本约为开源模型的三倍，商业模型是否还能通过更高的成功率和更少的人工介入证明溢价合理？现在的对照结果让这个问题变得更具体。
当两个模型的任务完成率接近时，成本就不再是边缘指标，而会直接进入架构决策。一个模型每次请求便宜三倍，并不代表总成本一定低三倍，因为 Agent 系统还要计算：
- 失败任务的重试成本；
- 测试和沙箱执行成本；
- 上下文缓存与存储成本；
- 工程师审查错误补丁的时间；
- 因回归问题产生的后续维护成本。
可以用一个简单的近似公式做第一轮估算：
总成本 = 模型调用成本 + 工具执行成本 + 人工复核成本 + 失败后的返工成本
因此，商业模型仍然可能在复杂任务、低容错任务或高价值代码库中更划算；而开源模型则可能在高并发、可私有化部署、数据不能离开内网，以及任务模式相对稳定的场景中更有吸引力。评测结果真正改变的，是“更贵就一定更强”的默认假设。
可以这样搭建一套最小对照实验
下面是一份可复制改造的命令行示例。它不依赖某个具体厂商的 SDK，而是假设你的 Agent harness 接受一个模型名，并输出每个任务的 JSON 结果。实际接入时，把 run-agent 替换成团队已有的执行入口即可。
运行前准备两个模型配置，并确保两次实验使用相同的任务列表、超时、最大轮数和测试命令：
export TASK_FILE=tasks.jsonl
export TIMEOUT_SECONDS=900
export MAX_TURNS=30
run_eval() {
local model="$1"
local output="$2"
./run-agent \
--model "$model" \
--tasks "$TASK_FILE" \
--timeout "$TIMEOUT_SECONDS" \
--max-turns "$MAX_TURNS" \
--test-command 'pytest -q' \
--output "$output"
}
run_eval kimi-k3 results-kimi.jsonl
run_eval fable-5 results-fable.jsonl
假设每行结果至少包含 passed、input_tokens、output_tokens 和 duration_seconds，可以用下面的 Python 脚本做基础汇总：
#!/usr/bin/env python3
import json
import sys
from pathlib import Path
def summarize(filename: str) -> None:
rows = [json.loads(line) for line in Path(filename).read_text().splitlines()]
passed = sum(row.get("passed", False) for row in rows)
total_tokens = sum(
row.get("input_tokens", 0) + row.get("output_tokens", 0)
for row in rows
)
total_seconds = sum(row.get("duration_seconds", 0) for row in rows)
print(f"file={filename}")
print(f"tasks={len(rows)}")
print(f"pass_rate={passed / len(rows):.3%}")
print(f"avg_tokens={total_tokens / len(rows):.1f}")
print(f"avg_seconds={total_seconds / len(rows):.1f}")
for path in sys.argv[1:]:
summarize(path)
保存为 summarize.py 后运行：
python summarize.py results-kimi.jsonl results-fable.jsonl
生产环境还应记录任务类别、重试次数、工具错误、补丁大小和人工接受结果。只有这样，团队才能区分“模型本身失败”和“执行器没有正确提供上下文”这两类问题。
对工程团队的采用建议
如果正在选择代码 Agent 模型，可以把这次结果转化为一份小型内部评测，而不是直接依据公开榜单采购：
- 从真实仓库中抽取一批脱敏任务，覆盖缺陷修复、测试补充和小型重构。
- 为候选模型固定同一套系统提示词、工具和超时策略。
- 同时记录通过率、成本、延迟、重试次数和人工复核时间。
- 对失败样本做分类，确认模型在哪些任务类型上真正落后。
- 先在低风险仓库或只读分析场景中灰度，再扩大写入权限。
开源模型的优势通常不只体现在单次调用价格，还包括部署位置、数据控制、并发容量和可调度性。商业模型的价值也不只是基准分数，还可能体现在复杂任务的稳定性、工具使用习惯和失败恢复能力。最终应比较的是一条完整的软件交付链路，而不是一个孤立的模型分数。
结语
1030 个真实 Agent 任务、统一 harness，以及 Kimi K3 与 Fable 5 接近的结果，给开源模型释放了一个明确的工程信号：在 SWE-bench 类软件开发任务中，开源与商业模型之间的差距正在缩小。
接下来更值得关注的不是谁在单次榜单上领先，而是谁能以可接受的成本，持续交付可审查、可维护、能通过真实测试的代码。对使用者而言，最稳妥的路径是用自己的仓库建立评测基线，再根据任务复杂度和风险分层路由模型。