我把 6 个小型 Python 仓库，分别交给 GLM-5.2、DeepSeek V4 Flash、Grok 4.5 Build、Qwen3.8-Max-preview 和 Codex（GPT-5.6-sol）。提示词相同，每次最多 300 秒，执行过程中不补充提示，也不人工改码。
30 次任务全部通过。 只看通过率，五款持平。
前五题包括边界 bug、跨文件功能、需求变更和限流器。第六题的公开测试从一开始就通过，缺陷只在失败重试和并发条件下暴露。我在 Agent 退出后再跑 4 个外部测试，五款也全部通过，测试文件没有被改。
通过率没有分出胜负
只看当前环境的总耗时，Grok 最快，6 题用了 210 秒；随后是 DeepSeek 378 秒、Qwen 570 秒、Codex 617 秒、GLM 723 秒。
这不是裸模型速度榜。GLM、DeepSeek、Qwen 跑在指定云机的 OpenCode；远端 Grok 账户没有额度，Codex 认证也失效，所以这两款改在本机官方 CLI 运行。比的是我真正能用起来的整套系统。
由于计费方式不同，价格不宜直接排序。Grok 六次调用实际记了约 0.485 美元，DeepSeek 这条路线约 0.017 美元；GLM 和 Qwen 走预付套餐，Codex 走订阅账号，都没有可直接对照的单次账单。
对于测试明确的小功能，这五款均能完成。在本次环境中，优先选择已经接入且响应更快的路线即可。
测试之外的代码差异
第六题要求不同订单可以并发，同一订单又不能重复入账；如果第一次入账失败，等待中的请求还得继续重试。五款都用了“按订单隔离”的办法，公开测试和外部测试全部通过。
随后的一万订单探针把差距拉开：四款的协调锁随着订单数增长，Codex 只保存正在处理的任务，结束后在 finally 中清空。
这不等于前四款会立刻内存泄漏，也不是本轮测试失败。五个实现为了防重复入账，都还保存着 1 万个已处理订单编号；真实服务本来就该把它们放进带过期策略的持久化存储。我反而更在意这个测试没管的细节：测试只验证“这次做对了”，不会提醒你临时状态准备留多久。
所以本次对比不必给五个模型排一个总冠军。在本次环境与链路下，短任务可优先使用 Grok 或 DeepSeek；若要把 Agent 的补丁放进长期运行的服务，我更认可 Codex 的版本。它与其他模型同样是 6/6，额外协调状态却在任务结束后得到回收。
