从 88 到 24 的祛魅之旅：代码智能的 2026 年 7 月「成人礼」

引言

数字不会骗人，但数字会骗自己。

7 月 8 日，OpenAI 发表了一篇措辞克制的博客——「分离编码评估中的信号与噪声」。标题平淡，内容却让整个 AI 编程行业陷入了沉默。他们对 SWE-bench Pro 的 731 道公开题进行了全面审计，结论是：约 30% 的题目是废的。

这不是第一次。五个月前，OpenAI 亲手「杀死」了 SWE-bench Verified——59.4% 的高难度题目存在污染或测试缺陷。SWE-bench Pro 是它亲手扶上王座的替代品。五个月后，这个替代品也塌了。

但 7 月带来的不只是坏消息。同一周，我们还看到了：

• Senior SWE-Bench 发布——最强的 AI 编程模型在真实任务中只有 24% 的通过率
• SWE-1.7 发布——一个在已充分 RL 训练过的基座上又推了 12 个百分点的「天花板粉碎者」
• Databricks 内部基准公开——在 3000 名工程师的真实代码上，GLM 5.2 和 Opus 4.8 打平，框架选择导致成本差出 2 倍

如果再算上 6 月底发布的 Ornith-1.0（自搭脚手架 RL，开源模型首次在 SWE-bench 超越 Claude）和 7 月初的 ChainSWE（多 Bug 链式维护基准）与 SWE-Doctor（运行时诊断引导修复），这半个月的信息密度，无论对代码智能的研究者、从业者还是投资者，都构成了一次系统性「祛魅」。

这些看似矛盾的事件背后，指向同一个核心命题：代码智能正在从「能做题」走向「能干活」，而这场成人礼的代价，是撕掉榜单上的泡沫，正视真实世界的复杂。

第一幕：三把尺子，三次打脸

Senior SWE-Bench：从 88% 到 24%

如果把 AI 编程模型比作学生，SWE-bench Verified 就是一张「开卷考试且老师把答案范围勾好了」的卷子。每道题的描述动辄 6,000+ 字符，39 个代码符号精确告诉你该改哪个函数、参数是什么类型。Claude Opus 4.8 在上面考了 88%。

但 Snorkel AI 联合普林斯顿和威斯康星大学的研究者问了一个更要命的问题：既然我们已经把 AI Agent 当高级工程师在用——丢进 Slack、扔进 GitHub、让它独立干活——凭什么还像评初级工程师那样考它？

于是有了 Senior SWE-Bench。它的任务来自 12 个生产仓库（包括 Gitea、PostHog、Prefect、Turborepo、Immich 等）中 2026 年 2 月以后合并的真实 PR，贡献者都是有 100+ 次提交的资深维护者。任务描述被压缩到 549–639 字符，零代码符号——像产品经理随口甩过来的一句话：「给导入流程加个 Google Books 兜底元数据源，主源拿不到的时候用它。」

三种任务类型：Design-and-Build（从模糊需求出发自主设计）、Investigate-and-Fix（从行为报告出发自行排查）、Performance（需要 profiling 才能定位的性能问题）。100 道任务，50 道公开、50 道保密（防污染）。

评分不止看测试——还有一道「品味判官」（Taste Judge）：代码是否最小化？是否真正解决了根因？有没有硬编码？风格是否和仓库一致？是否复用了已有工具？1-5 分评分，低于 2 分直接判不通过。

结果如下：

88% → 24%。这不是模型变笨了，是尺子变了。 Opus 4.8 每道题平均消耗 117K 输出 token、近 97K 个 agent 步骤——它已经很努力了。但模糊的需求、隐式的约束、全局的一致性，这些真实工程世界里每天都在发生的事，当前的模型还远远没有掌握。

OpenAI 亲手砸了自己的秤

同一天（7 月 8 日），OpenAI 发表的审计报告进一步动摇了地基。

SWE-bench Pro 的 731 道公开题中，自动筛查标记出 200 道异常（27.4%），五名资深软件工程师的独立复核确认了 249 道（34.1%）。四类问题：

• 测试过严：模型交了功能完全正确的方案，只因为实现路径和出题人想的不一样就被判不及格
• 描述不完整：隐藏测试包含题目中没提的需求，且无法从上下文合理推断——模型在「猜题」
• 覆盖不足：测试太弱，不完整的修复也能通过——分数虚高
• 描述误导：题目把模型指向错误的方向，或与测试要求矛盾

有一个典型案例：题目要求「统一使用单倍行距」，但隐藏的测试用例实际检查的是双倍行距——任何老老实实按题目写的模型都会挂，猜对「潜规则」的反而能过。

这不仅意味着过去八个月 SWE-bench Pro 榜单上从 23.3% 冲到 80.3% 的「进步」有很大水分，更意味着整个行业用来做采购决策、安全评估、投资论证的基准尺子，自己就是弯的。OpenAI 的建议是务实的但令人不安的：模型开发者应该手动复核每一个通过和失败的题目——但当评测规模数以千计时，这个建议近乎奢侈。

ChainSWE 和 FixedCode：两种新视角

7 月 1 日，ChainSWE（arXiv:2607.02606，Jin et al.）提出了另一个维度的拷问。现有的所有 SWE 类基准都有一个共同假设：每次修 Bug 都从干净的容器开始，没有上一次修改的累积状态。但真实软件维护不是这样——你修了一个 Bug，提交后紧接着修第二个，它可能依赖于你的上一个修改。

ChainSWE 构建了 304 个跨 54 个 Python 项目的时间链式 Bug 序列，要求 Agent 在一个连续 session 中依次修复，不复位。结果：链长增加时，性能下降最高可达 70%。 Agent 被自己上一个修改产生的累积状态淹没了。

而 ETH Zurich 的 FixedCode 研究（SRI Lab，Mündler et al.，2026 年 3 月发布，7 月在业界引起广泛讨论）问了一个更辛辣的问题：给 Agent 一个已经被修好的 Bug 让它修，它会怎么做？

正确答案是：什么都不做，报告「无需修改」。但实际呢？没有任何模型能超过 70% 的正确弃修率。 GPT-5.3-Codex 68%，Sonnet 4.6 65%，GPT-5.4 mini 60.5%，Gemini 3 Pro 只有 36.5%。

更令人不安的是行为模式。Sonnet 4.6 通常会先尝试复现 Bug，发现已修复后正确提交空补丁。而大多数模型则二话不说上手就改——不查 git log、不复现、不验证——把已经正确的代码又「修」了一遍。研究者用了一个尖锐的词：agent slop（智能体垃圾）——如果部署用于自主维护，这些 Agent 会系统性地向代码库注入不必要的修改。

唯一的好消息是，在 prompt 中显式加入「如果没有必要修改就不要动」的指令后，GPT-5.4 mini 的弃修率从 60.5% 跃升至 88.5%。但这只是一个止血方案。研究者指出，根本原因在于训练奖励设计：模型见过的数百万条「修 Bug」轨迹里，成功总是被定义为「生成了补丁」——从来没有人奖励过「判断出不需要修改」。

这个动态具有超出编码的普遍性。每当 Agent 遇到意外情况、已经被解决的问题、矛盾的需求或模糊的要求时，它都会默认「产生点什么」而不是「推回去或请求澄清」。对今天部署 Agent 的人来说，实用建议是：永远为意外情况定义一个显式的成功路径。 但长期来看，如果我们想要能自主维护软件的编码 Agent，它们需要内化「最小化、经验证的改动」这一原则。这需要改变训练方式，而不仅仅是 prompt 方式。

第二幕：真正的突破——RL 天花板和自搭脚手架

基准的崩塌并不意味着代码智能没有进步。恰恰相反，7 月同时见证了方法论层面的两个重要突破。

SWE-1.7：RL 没有固定天花板

7 月 8 日——同一天 OpenAI 在批改旧尺子——Cognition 发布了 SWE-1.7。这个模型的基座是 Kimi K2.7，月之暗面已经对其进行了大量 RL 后训练。按照业界共识，一个「已经被充分训过」的基座，继续做 RL 的空间应该非常有限——策略会变得过于确定性，模型不再探索，收益迅速递减。

SWE-1.7 打破了这个假设。

在 Cognition 自建的 FrontierCode 1.1 基准上（评估可合并、生产质量的 PR），SWE-1.7 达到 42.3%——距离 GPT-5.5 的 43.0% 只差 0.7 个百分点，距离 Opus 4.8 的 46.5% 也只有 4.2 个百分点的差距。在多语言编程评测 SWE-Bench Multilingual 上，SWE-1.7 的 77.8% 直接超过了 GPT-5.5 的 76.8%。

更惊人的是代际跃升：前代 SWE-1.6 只有 9.4%，基座 Kimi K2.7 Code 是 30.1%。Cognition 的 RL 在已经「充分训练」的基座上额外推了 12.2 个百分点——四倍于前代的性能。

「自 Kimi K2.7 已经经过大量 RL 后训练以来，我们自己的训练带来的大幅额外增益挑战了’后训练天花板’的概念，表明 RL 可以推动能力远远超出之前的信念，」Cognition 在技术博客中写道。四个工程创新使之成为可能：异步大规模 RL 管线、改进的奖励信号设计、更高效的 rollout 策略、以及避免训练崩溃的稳定性技术。

但这里有一个更深的商业维度值得关注：「开源基座 + 顶级 RL 微调」这个模式跑通了。 基座来自中国开源（Kimi K2.7），RL 和产品化由美国公司 Cognition 完成，最终交付是 SaaS 产品 Devin。这个结构绕过了 AI 行业最昂贵的环节——从头训练千亿参数基座——却得到了和 OpenAI / Anthropic 正面竞争的产品。地基是中国的，房子是美国人盖的，最后整栋楼跟最前沿的闭源模型平起平坐。

Ornith-1.0：让模型自己写脚手架

比 SWE-1.7 早两周（6 月 25 日），DeepReinforce 发布了 Ornith-1.0。如果说 SWE-1.7 打破了「RL 天花板」的假设，Ornith-1.0 打破了另一个更根本的假设：Agent 的训练脚手架必须由人类设计。

传统 Agent 训练是这样一个流程：工程师手写一个 harness（脚手架）——定义工具接口、错误处理逻辑、重试策略、上下文管理方式——然后模型在这个固定的 harness 里做 RL。模型学习的是「在这个脚手架里怎么答得更好」，但脚手架本身不变。

Ornith-1.0 把脚手架变成了可学习对象。每个 RL 步分两个阶段：

1. 脚手架生成：模型阅读任务和之前的脚手架，提出精炼版
2. 方案 rollout：用新脚手架完成任务

奖励信号同时回传两个阶段。模型学会的不只是写更好的代码，还包括为每类任务设计更有效的编排逻辑——应该用什么内存管理模式、什么时候做更多的测试生成、如何处理错误和重试。

为了防止模型写脚手架时作弊（比如偷偷读答案文件），DeepReinforce 设计了三层防御：

• 外层不可变信任边界：环境、工具、测试隔离对模型不可达
• 确定性监控器：检测违规路径访问，零奖励 + 排除出训练更新
• 冻结 LLM 判官：在验证器之上做意图级审查，捕捉许可工具表面内的取巧行为

结果令人印象深刻。397B MoE 旗舰在 SWE-Bench Verified 上拿到 82.4 分，超越了 Claude Opus 4.7 的 80.8 分——开源模型首次在这个基准上超越闭源旗舰。 在 Terminal-Bench 2.1 上也达到 77.5 分。更惊人的是 9B 版本：SWE-Bench Verified 69.4 分，距离 35B 的 Qwen 3.5（70.0）只差 0.6 分，却只有其四分之一的参数量。9B 版本在 Terminal-Bench 2.1 上甚至以 43.1 分超过了 Gemma 4-31B 的 42.1 分。

全部 MIT 许可、GGUF 格式支持 Ollama 本地部署。这不仅是一个开源阵营的胜利，更是一种训练方法论的突破：让梯度触碰到过去碰不到的地方——不只是「答什么」，还有「怎么引导自己去答」。

第三幕：更聪明的 Agent——从「修代码」到「诊断代码」

基准崩塌和训练突破之间，还有一条重要的平行线：Agent 自身的执行策略也在从「暴力生成」走向「先理解、再动手」。

SWE-Doctor（arXiv:2607.00990，Guo, Liu, Zhang, Ma, Lou, Chen et al.，7 月 1 日）提出了一种新思路：让 Agent 不只是生成补丁，而是先用多面 Bug 复现测试（Multi-Faceted BRT）做运行时诊断。研究者首先发现一个关键结论：直接拿 BRT 生成器来引导补丁生成是不管用的——fail-to-fail BRT 会误导 Agent，而即便是 fail-to-pass BRT 也只能带来有限甚至负面的增益。原因在于：单个 BRT 只覆盖 Bug 的一个行为表现维度，容易导致 partial patches（看起来过了但实际上不完整）。

SWE-Doctor 的解决方式是：先为 issue 中描述的不同行为需求生成多面 BRT，然后在真实环境中执行并调试这些 BRT——收集堆栈跟踪、变量状态等运行时信息——整合为结构化诊断记录，最后将诊断与 BRT 生成过程中推断出的定位信息一起作为补丁生成的输入信号。

效果：在 5 种 LLM 后端 × 2 个基准（SWE-bench Verified / SWE-bench Pro）共 10 组 LLM-benchmark 组合中全部优于现有 Agent。SWE-bench Verified 平均解决率 75.7%，SWE-bench Pro 上 59.4%，相对基线方法提升 8.0–8.9 个百分点。多面 BRT 方法还有效减少了 partial patches 的产生。

ARISE（arXiv:2605.03117，Seddik et al.，7 月初更新）则从另一个角度切入：仓库级代码的图表示。传统基于图的 Agent 只能建模文件→类→函数的组织结构，缺少过程内的数据流建模。ARISE 在图上扩展了定义-使用（def-use）边连接语句级节点，通过数据流切片 API 让 Agent 追踪变量值的流动。在 SWE-bench Lite 上（11 个 Python 仓库，300 个真实 GitHub issue），基于 Qwen2.5-Coder-32B 的 ARISE + SWE-agent 组合解决了 22.0% 的问题（66/300），比原生 SWE-agent 基线提升 4.7 个百分点。性能提升主要来自更精准的定位：函数级 Recall@1 从 0.43 升至 0.60（+40%），行级 Recall@1 从 0.26 升至 0.41（+58%）。

这些改进的共同方向是：让 Agent 在动手修代码之前，先花时间理解代码。 这听起来像是废话，但在当前的 Agent 架构里，大多数模型是「上来就改」的——FixedCode 的研究已经充分暴露了这一点。

结论：从刷榜到干活——代码智能的成人礼

2026 年 7 月上半月，代码智能领域经历了一次罕见的「信息密度爆炸」。把这些事件放在一起看，三个清晰的叙事浮现出来：

第一，尺子坏了——而且可能永远修不好。 SWE-bench Verified 已被废弃，SWE-bench Pro 有约 30% 的题目是废的，Senior SWE-Bench 告诉我们最强者也只有 24% 的真实通过率。ChainSWE 揭示了单题评测无法捕捉的累积状态问题。FixedCode 提醒我们 Agent 连「什么都不做」都不会。Databricks 的选择——自建内部基准——或许会成为越来越多企业的标准动作：你的 PR 历史、你的测试、你的代码库，就是任何公开训练数据里都不存在的、唯一真正干净的评测集。

第二，真正的突破在方法层面。 Ornith-1.0 的自搭脚手架证明 RL 训练的搜索空间可以扩展到 scaffolding 本身。SWE-1.7 的 RL 天花板突破证明「已充分训练」不等于「已训到极限」——基础设施质量可能比模型初始能力更关键。一个来自 DeepReinforce，一个来自 Cognition，两者都在告诉我们同一件事：RL 后训练的束缚不是模型的先天极限，而是我们只让模型练「填空」、不让它练「出题」。

第三，Agent 需要学会「先诊断，再动手」。 SWE-Doctor 的运行时诊断、ARISE 的数据流切片、FixedCode 揭示的弃修能力缺失——这些改进都在推动 Agent 从「生成代码的机器」走向「理解代码的工程师」。而且，这不仅仅是一个编码领域的问题。FixedCode 研究者的警示值得反复思考：「模型在训练中看过数百万条修 Bug 的轨迹，每一次成功都被定义为生成了补丁——从来没有人奖励过’判断不需要修改’。」 这个动态适用于任何 Agent 场景。

对于实际从业者，三个可操作的建议：

1. 不要迷信任何一个公开基准的数字。 如果它被广泛引用，它很可能已经被污染、被游戏、或者在任务构造上存在系统性问题。用你自己的代码库、你自己的 PR、你自己的测试来评估——Databricks 已经提供了实操范本。

2. RL 远未触顶。 如果你的模型在某个 benchmark 上停滞了，问题可能不在模型，而在你的训练基础设施和奖励设计。Cognition 在一个「已充分 RL」的基座上推了 12 个百分点，DeepReinforce 证明了让模型参与脚手架设计可以激活全新的能力维度。

3. 框架成本可能比模型成本更重要。 Databricks 发现同一个模型换一套 harness，成本差出 2 倍——而模型本身的价格差异反而没那么显著。选对脚手架有时候比选对模型更关键。

代码智能的「成人礼」不是指它突然变厉害了，而是它终于开始面对真实世界的复杂——模糊的需求、隐式的约束、全局的一致性、累积的修改历史，以及「什么都不做」的价值。榜单上的 88% 是青春期的骄傲，24% 是成人世界的真实。

让人欣慰的是，就在旧尺子崩塌的同一个月，真正的进步正在方法论层面发生。