<!-- title: 别信刷榜：coding agent本周测评翻车实录 -->
<!-- domain: trending -->

# 别信刷榜：coding agent本周测评翻车实录

**导语**：本周（2026-07-08/09）海外技术圈炸了一个被国内几乎没人讨论的锅——**coding agent 的排行榜，被集体质疑已经"刷烂了"**。先是 OpenAI 发文暗示对手对 SWE-Bench Pro"过拟合刷分"，HN 评论区最高赞直接翻译成大白话："翻译一下，就是别家学会刷榜比他们更溜了"。紧接着 Databricks 用自家百万行真实代码库跑出硬数据，戳穿了三个国内人尽皆知的"常识"假象：**token 便宜 ≠ 任务便宜、模型强 ≠ 用起来强、闭源碾压开源——已经不成立了**。你还在按 SWE-Bench 分数给团队选 coding agent？这周海外用真金白银的数字告诉你：那榜单，是死的。
## 话题一：SWE-Bench 排行榜被指控"刷榜"，社区一句"benchmaxx"封神

本周 OpenAI 发布了一篇题为《Separating signal from noise in coding evaluations》的文章（HN 225 赞、82 评论），核心诉求是：**自家更严格的 SWE-Bench Pro 才是真标尺，别家的分数"水"**。但 HN 评论区根本不买账，最高赞评论一针见血：

> "翻译一下：其他实验室学会对 SWE-Bench Pro 'benchmaxx'（刷分冲榜）刷得比他们更狠了。"

这是一个"皇帝的新衣"时刻。当**指控别人刷榜的人自己也是榜单最大受益者**，社区的反应只有嘲讽。三条典型观点代表了三个阵营：

| 阵营 | 代表观点 | 信号 |
|------|---------|------|
| **怀疑派（主流）** | "实验室里要真有质变产品，AGI 早该有影子了，现在纯属营销噱头" | 榜单=营销物料 |
| **结构派** | "得搞个 Unknown-Unknowns 基准，测'未知未知'问题才不会被刷" | 现有基准方法论本身有洞 |
| **实用派** | 不看榜单，自己拿真实代码库跑 | 用脚投票 |

**对国内开发者的启示**：你打开任何一个"2026 最强 coding agent 横评"，看到一排 SWE-Bench Verified 70%+ 的数字，请默认三件事——①训练数据可能含榜单泄漏；②专门对榜单题型做了优化；③**榜单位移**：当一个榜单成为选型标准，它就立刻被异化为刷分目标（古德哈特定律）。分数越高，越说明它已经偏离真实任务。
## 话题二：Databricks 用百万行真代码，三条结论打脸"常识"

这才是本周含金量最高的帖子（HN 114 赞、45 评论）。Databricks 不是模型厂商（vendor neutral），他们用**自家数百万行的真实生产代码库**，把 OpenAI、Anthropic、开源模型丢进同一套 harness 跑，得出三条足以改变选型逻辑的结论：

### 结论 1：harness 才是杠杆，不是模型——成本能差 2 倍

> "我们用同一个模型、同样的 thinking effort，分别跑两套 harness（Claude Code/Codex vs Pi），**每任务成本差超过 2 倍，而质量完全一样**。差异主要来自每步塞进去的 context 量。"

**这条国内几乎没人讲透**。你以为换个更强的模型能省事？错。**同一颗 Opus 4.8，换一套 context 管理（CLAUDE.md 写法、MCP 工具裁剪、/compact 时机），成本直接对半砍，质量不动**。这就是为什么"调 harness"比"调模型"划算得多——模型是按月订阅的死成本，harness 是你能 100% 控制的活杠杆。

### 结论 2：token 单价便宜 ≠ 用起来便宜——Sonnet 反而更贵更差

Databricks 给了一组反直觉到家的硬数字：

> "Sonnet 5 每 token 比 Opus 4.8 便宜约 1.7 倍。但在我们的任务上，**Sonnet 每任务花 $2.09，Opus 只花 $1.94，而 Sonnet 完成率还低 6 个点（81% vs 87%）**。主要是因为 Sonnet 5 会绕更多弯。"

**这条直接打脸"用便宜模型省钱"的本能**。原因：便宜模型为了把任务做对，会**多轮试错、多读 context、多重写**，token 消耗暴涨，最终单任务成本反超大模型，质量还更烂。所以国内团队普遍犯的错是——**用单价 × 估算 token 数来选型**，而真正该比的是 **$/task（每任务真实成本）× 完成率**。这俩指标，榜单上一个字都不会告诉你。

### 结论 3：开源追平闭源，GLM 5.2 被"盖章"frontier 级

> "开源模型——尤其 **GLM 5.2——如今已能应对最高难度任务**……证据表明，是时候把它们当日常驱动来部署了。"

这是本周最该让国内开发者振奋也最该反思的一条。**Databricks 这种硅谷头部公司、用自家百万行代码实测，给智谱的 GLM 5.2 盖了"可日常驱动"的章**，与 Opus 4.8、GPT-5.5 并列。但国内很多团队仍默认"国产/开源=凑合用"。信息差就在这：**海外已经在认真把 GLM 当 frontier 用，国内还有人拿它当降级备胎**。同时帖子也强调"今天没有任何单一工具能独占 frontier，只有**模型混编**才最优"——简单任务下沉到 Haiku / GPT 5.4 Mini / GLM 5.2，硬骨头才喂给 Opus 4.8 或 Grok 4.5。

### 一条埋在脚注里的杀手锏：拒绝 LLM 当裁判

> "我们**没用 LLM judge 来判对错**，因为我们发现这会奖励'听起来对'而不是'真的对'。"

这条太狠了。国内大量"自动评测"都是拿 GPT 去给别的模型打分——**等于让一个会说话的人判卷，谁文笔好谁赢**。Databricks 人工验收，宁可慢。这也是榜单失真的根因之一。
## 话题三：开发者开始"逃离 GitHub"——AI 编码时代的基础设施独立性

本周另一条 196 赞、135 评论的热帖是《为什么开发者正在抛弃 GitHub 投奔 Codeberg 和自托管》。乍看是老话题，但评论区一条真实事故让它的信息差价值拉满：

> "我们整个组织（Lightning Dev Kit）的 CI **被关停整整 3 周**——只因为一个被误封的外部贡献者提交了 PR。多次申诉无果，被告知是永久封禁，直到我们在 Twitter 上闹大。GitHub 已经不是个好待的地方了。"

**这是 AI 编码时代的隐性风险**：当你的 CI、贡献者、代码资产全部锁死在单一闭源平台上，**一次 AI 误判的自动封禁就能让你的协作链瘫痪 3 周**。社区的迁移栈已经成型——**Codeberg（非营利）、Forgejo、Gitea 自托管**。这不是折腾，是工程上的"灾备"。国内对应物：把核心仓库**镜像到自建 Gitea/GitLab**，别把鸡蛋全放在 GitHub 一个篮子里。
## 一张图：coding agent 选型，本周海外社区的真实决策路径

```mermaid
flowchart TD
    A["想给团队换 coding agent"] --> B{"先看 SWE-Bench 排行榜?"}
    B -->|"别看·已被刷榜污染"| C["把榜单扔一边"]
    C --> D["从自家真实代码库<br/>抽 30 个 PR/issue 做任务集"]
    D --> E["固定同一套 harness<br/>只换模型·消除变量"]
    E --> F{"比什么指标?"}
    F --> G["$/task 每任务成本<br/>不是 token 单价"]
    F --> H["人工验收是否真对<br/>拒绝 LLM-judge"]
    F --> I["任务完成率 %"]
    G --> J["路由: 简单任务下沉<br/>Haiku / GPT5.4Mini / GLM5.2<br/>硬任务→Opus4.8 / Grok4.5"]
    H --> J
    I --> J
    J --> K["每月重跑任务集<br/>模型月月变·榜单是死数据"]
```
## 信息差总结：你以为的 vs 海外这周揭穿的

| 国内常见认知 | 海外社区本周揭穿的真相 |
|---|---|
| SWE-Bench 分数高 = agent 强 | 榜单已被 "benchmaxx" 污染，labs 专对榜单过拟合 |
| token 便宜 = 用起来省钱 | Sonnet 5 token 更便宜，但每任务 $2.09 > Opus $1.94 且更差 |
| 选最强模型就对了 | 同模型换 harness 成本差 2x、质量不变——harness 才是杠杆 |
| 闭源碾压开源 | GLM 5.2 被 Databricks 盖章 frontier 级，可日常驱动 |
| Python 最适合 AI 写 | 强类型（Rust/Swift/C#/TS）对 agent 更可预测、更省钱 |
| LLM 当裁判打分省事 | LLM-judge 奖励"听起来对"，必须人工验收 |
| 代码托管在 GitHub 就行 | 一次 AI 误封能让组织 CI 瘫 3 周，需自托管灾备 |
## 行动指南：你接下来可以立刻做的 7 步

1. **停止按排行榜选型**。从自己仓库抽 20–40 个真实 PR/issue，组成私有任务集——这是你唯一的可信标尺。
2. **锁定 harness 消除变量**。同一套 Claude Code/Codex 配置（同样的 CLAUDE.md、MCP 工具、/compact 策略），只换底层模型。先把 harness 本身调到 context 最省。
3. **改用 $/task 计费**，而不是 token 单价 × 估算量。记录每模型每任务的真实花费 + 完成率，做一张表。
4. **人工验收，砍掉 LLM-judge**。宁可慢，不要"听起来对"。Databricks 连"分数高得太离谱"都会手动复查。
5. **新项目骨架用强类型语言**（TypeScript / Rust）。让 agent 拥有编译器闭环——"build 报错→改→重试"比 Python 的"跑起来才知道错"省钱得多。
6. **模型路由分层**：CRUD、改配置、写测试下沉到 Haiku / GPT 5.4 Mini / GLM 5.2；架构设计、复杂调试才喂 Opus 4.8 或 Grok 4.5。别让 80% 的简单请求占用顶配。
7. **git 镜像自托管**：用 Forgejo/Gitea 把核心仓库镜像一份，避免单平台封禁拖垮整个 CI。
8. **每月重跑一次任务集**——模型和 harness 月月在变，榜单是死数据，你的私有基准才是活的。
## 参考来源

1. OpenAI《Separating signal from noise in coding evaluations》原文：https://openai.com/index/separating-signal-from-noise-coding-evaluations/
2. HN 讨论（OpenAI 榜单，82 评论）：https://news.ycombinator.com/item?id=48837396
3. Databricks《Benchmarking Coding Agents on a Multi-Million Line Codebase》：https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase
4. HN 讨论（Databricks 硬数据，45 评论）：https://news.ycombinator.com/item?id=48837696
5. HN 三方同题对比《We made Grok 4.5, GPT-5.5, Claude build the same apps》：https://news.ycombinator.com/item?id=48838772
6. HN《开发者逃离 GitHub 投奔 Codeberg》（135 评论）：https://news.ycombinator.com/item?id=48842611
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护。
> 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。
**下一步建议**：① Round 6 将循环回 new-tools，建议提前锁定本周 HN/GitHub trending 的新开源 AI 工具；② 可考虑把本次的"私有任务集测 agent"方法论沉淀为一个 51学通信风格 PPT 或短视频选题；③ 如需后续轮次同样规避限流，可直接复用本次的 HN Firebase/Algolia 直连脚本路径。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)