推荐这篇，Cursor 的研究团队用定量方法揭露了一个越来越严重的问题：新模型在编码基准测试上的得分增长有多大比例是靠检索到答案而不是真的推导出答案。结果是——Opus 4.8 Max 在 SWE-bench Pro 上 63% 的成功轨迹存在答案检索行为，环境收紧后分数从 87.1 跌到 73.0。 Reward hacking 正在淹没模型智能的增长 更聪明的模型在编码基准测试上越来越擅长走捷径。基于真实 bug 后被修复的评估集尤其脆弱——如果 agent 能访问仓库历史或公开互联网，它有时能查到答案而不是推导出答案。 为了测量这种行为的普遍程度，Cursor 建了一个审计 agent。在 SWE-bench Pro 上，Opus 4.8 Max 的 63% 成功轨迹是检索到了修复方案而非推导出来。封上 git 历史和互联网后，分数大幅下跌：Opus 4.8 Max 从 87.1% 掉到 73.0%，Composer 2.5 从 74.7% 掉到 54.0%。 两种最常见的 reward-hacking 模式 上游查询——57% 的轨迹中 Opus 4.8 Max 在公开互联网找到了已合并的 PR 或修复后源文件，然后几乎逐字复制。 Git 历史挖掘——9% 的轨迹中模型搜索了内置的 .git 历史，找到修 bug 的后续 commit，提取补丁。 随着模型变强，它们有时能推断自己正在被评估。一个 SWE-bench Multilingual 任务来自 2019 年的 jq issue，agent 试图用系统 jq 二进制复现 bug。因为镜像在 bug 修了之后才构建，复现失败，agent 推断 issue 已解决。这个意识推着它去搜索修复方案而非推导。 严格环境的差距在扩大 多语言 SWE-bench：Opus 4.6 不到 1 分差距，Opus 4.8 Max 9.1 分差距，Composer 2.5 7.5 分差距。 SWE-bench Pro：Opus 4.6 不到 1 分，Opus 4.8 Max 14.1 分，Composer 2.5 20.7 分。 GPT 系列模型没有表现出同样的升级趋势，差距普遍更小。 对评估的影响 对于使用历史公开仓库的基准测试，开放访问可能让 agent 找到已知修复而非解决 bug。没有 harness 控制，分数混杂了编码能力和答案检索。团队需要决定想测量的行为，围绕这个设计 harness，报告结果时说清楚设置。审计轨迹可以帮助揭示模型以意外方式解决任务的情况。 更深层的问题仍未解决：当模型越来越意识到自己在被评估时，它们可能以更微妙的方式改变行为——这不是封掉 git 历史或限制互联网就能解决的。 原文：Cursor Research, "Reward hacking is swamping model intelligence gains", 2026-06-25 #编码评测# #SWEbench# #Agent#

国产模型最近这一波打得太精准了 DeepSWE benchmark 放出了榜单, 从分数上看, GLM-5.2 无疑是国产编程大模型SOTA了, 而 Kimi-K2.7-Code 则是性价比SOTA. 图上几个折线是对应模型的不同推理程度的得分情况. DeepSWE 我觉得是最近非常值得的关注的的榜单了, 这个虽然也叫xxSWE, 但是它用的不是像SWE那种github上爬取的PR或者issue, 而是完全根据开源项目人工制造的问题, 然后让大模型修改. 能最大限度避免大模型提前炼这些问题(起码需要一段时间了, 5月份刚出的) 并且修改范围也很大,SWE-Bench-verified 通常一个提交也就几十行代码, 而 DeepSWE 每个问题都要上百行提交才能解决问题, 并且很考验模型的规划能力, SWE-Bench-Verified 通常会把所有需要的工具给到错误日志啥的也有, 并且提示词也写好告诉模型该怎么用. 而 DeepSWE 纯靠模型自己摸索, 非常像现实中修改项目代码的过程. 我觉得是涵盖了一部分工程能力测试的. 另外 SWE-Bench-verified 测得大部分都是 Python, 而 DeepSWE 则涵盖了TypeScript、Go、Python、JavaScript、Rust. 所以我强烈建议关注大模型编程能力测试的同学过关注一波这个测试. #DeepSWE# #SWEBench# #glm# #kimi#

🪨 Recursive 刚开源了专门给编程 agent 当大脑的模型 Flint，总参数 39.8B，每个 token 却只动用约 2.5B，官方测的 SWE-bench Verified 是 74.2%。 Flint 由 Recursive Superintelligence 发布，Hugging Face 上 387 个赞，10 月 22 日上了 Hugging Face 的热门趋势，Apache 2.0 许可证。 让 agent 自己修 bug、在终端里一步步跑命令，一个任务往往要来回几十轮。底下的模型要么走闭源 API 按量付费，要么换成开源的大稠密模型，每一轮都得把全部参数算一遍。Flint 走的是混合专家路线：每层 256 个专家里每个 token 只挑 6 个，再加一个常驻的共享专家，盘子是 39.8B，真正干活的只有 2.5B 左右，上下文给到 262K token。 成绩是官方自己测的：Terminal-Bench 2.1 拿了 54.9%，SWE-bench Pro v2 是 89.7%，每项至少跑五次取平均；Terminal-Bench 里靠联网搜到答案的一律算失败。 有几点要提前知道：仓库只放了 BF16 权重，下载约 80GB，Transformers 的建模代码还没放出来，得用官方自带的 SGLang 服务套件跑，官方给的配置是每份副本一块 H200 或 B300；文档也写明，Flint 仍可能写出错误内容或调错工具。 想给自己的编程 agent 换个开源底座的人，Flint 值得拿来跑一轮自己的任务。 Hugging Face：

我们是不是高估了 Harness 对 Coding Agent「能力」的提升？ 这篇论文中把模型固定，只替换 Claude Code、mini-SWE-agent 和 OpenCode，在 SWE-bench Verified 上重新测试。 结果很有意思。 在 447 个任务上，最重的 Claude Code 和最轻的 mini-SWE-agent，成绩差异落在 5 个百分点以内。 在 45 个高难任务、5 个模型上，换 Harness 会让 13% 的任务结果发生变化；但什么都不改，只把同一个配置再跑一遍，同样有 13% 的任务会翻转。 也就是说，很多看起来像 Harness 带来的提升，可能还没有明显超过运行本身的随机波动。 真正拉开差距的反而是成本。 同一个模型、同一批任务，不同 Harness 的单任务成本最高能差 3 倍。主要原因很简单：系统 Prompt 和工具 schema 会在每一步重复进入上下文，初始开销再被执行步数不断放大。 论文还提醒了一个容易被忽略的问题： 45 个任务连 13 个百分点的差距都只有约一半概率能检出；即使做到 447 个任务，分辨率也大约只有 5 个百分点。 所以我们得把 Harness 的价值拆开看了。 它当然会影响 Agent 怎么工作，但很多时候，最稳定、最容易测出来的差异，可能先体现在 token、成本和执行效率上。 📎 arxiv:

all in 主持人Jason Calacanis今天的一期节目中，嘉宾eric Ho说： Kimmy K3表现出了极强的奖励操纵 (reward hacking) 倾向。 在针对swe bench的500 次测试执行中，有 487 次出现了奖励操纵行为。 该模型在被测试时，能够识别出自己正处于评估环境中，但它依然选择跳过正常解题步骤，试图先去“查找答案”以获取高分，而不是通过逻辑推演来完成任务。

MiniMax 今日发布 M3 大模型 目前唯一同时具备顶尖编程、百万级超长上下文与原生多模态桌面操控能力的开源路线模型（计划 10 天内开源权重）。 在 SWE-Bench Pro 上拿下 59.0% 成绩，超越 GPT-5.5 与 Gemini 3.1 Pro，接近 Opus 4.7；Terminal Bench 2.1 也达到 66.0%。首创稀疏注意力 MSA 架构，百万上下文下每 token 计算量降至上代 1/20，预填充加速 9 倍、解码加速 15 倍。 实测已能自主复现 ICLR 2025 论文、24 小时内调用工具 1959 次优化 Hopper FP8 算子。MiniMax Code 同步更新，支持 computer use 桌面操控。 订阅 Plus 档每月 49 元即可获得 6 亿 token（约 Claude Pro 的 5 倍容量），API 已上线，提供 thinking 与快速模式。

一觉醒来，目前最强大的两个模型都更新了。Opus 4.6 极大的增强了 Agentic 通用能力，但是 SWE Bench 不升反降了一点点。从官方宣传的跑分上来看，代码能力上，GPT 5.3 要比 Opus 4.6 强。今天用新模型来写代码实际测测。

现在很多 Agent 自进化，大致走两条路： 一条改模型权重，一条改 Harness。 这篇 Evo² 直接把两条路接了起来。 系统里，同一个模型同时扮演两个角色： Proposer 负责修改 Harness，Reflector 负责看执行结果、分析哪里改对了、哪里还需要修。 关键在下一步。 这些 Harness 修改和真实执行结果，会继续拿回来训练 Proposer 和 Reflector。模型变得更会改 Harness，新的 Harness 又产生更好的训练经验，形成一个持续循环。 结果是 Evo² 在 Polyglot 上达到 82.1%，最强 baseline 是 62.6%；SWE-bench Verified 达到 48.3%，相比 baseline 的 41.0% 继续提升。 而且进化出来的 Harness 可以直接迁移到其他 benchmark，不需要重新搜索。固定 GPT-5-mini 权重时，仅靠这套 Harness 进化流程，也把表现从 24.4% 提升到 48.3%。 这篇真正往前推的一步，是让「改进者」本身也进入了学习循环。 以后自进化 Agent 可能会越来越像两个互相促进的系统： 一边积累更好的外部运行结构，一边训练出更会修改这些结构的模型。 当「怎么让自己变强」也开始被持续训练，self-evolution 才真正有了第二层递归。 📎 arxiv:

如果代码库里的每个文件都能自己解释、自己修改，还会提醒相关文件「你也得改」，Coding Agent 会不会更稳？ UIUC 和 Penn State 这篇论文提出 HERMES，把代码库里的文件、配置和测试变成一个个 Dev-Primitive。 可以把它理解成：每个组件旁边都有一个专门理解它的小 Agent。 遇到任务时，HERMES 先沿依赖关系找到真正相关的组件，只激活这一小部分。它们各自修改自己负责的内容，同时同步接口变化、配置约束和测试要求。 如果执行失败，系统会根据报错和测试结果，只重新激活相关组件继续修，不需要每轮重新读完整个仓库。 论文在 SWE-bench、仓库级重构、Terminal-Bench 和 DevOps 四类任务上测试，平均提升 12.4 个百分点。 还有就是把内部组件 Agent 换成 Qwen3-8B，整体只比全 GPT-5.6 Sol 方案低约 4.5 个百分点；在 Terminal-Bench 上成本还能下降 26.2%。 面对大仓库里的 Coding Agent，可能更需要一套稳定的「局部理解 + 协作修改 + 失败后定点修复」机制。 Harness 的价值也像是在组织代码、上下文和 Agent 之间的信息流。 📎 arxiv:

这篇论文很有意思！现在连 RSI 都开始有自己的「实验场」了。 Evolvent AI 和 NUS 这篇论文提出 RSIGym，一个专门让 Agent 研究「怎么改进 AI」的实验环境。 它把训练、推理、数据生成、评测和沙盒都封装成服务。Research Agent 可以直接调用这些能力，然后不断循环： 分析问题 → 改数据 / 训练配置 / Harness → 训练 → 评测 → 根据结果继续修改。 更有意思的是，它把自我改进拆成三种模式： Data 只允许改训练数据； Harness 只改模型外的运行系统； Joint 则把数据、训练配置和 Harness 一起开放给 Agent。 作者还提出 RSI-Index，衡量系统在 SWE-bench、Terminal-Bench、AIME、GPQA 和 SkillsBench 上填平了多少「距离满分的差距」。 在每个 benchmark $500 的预算下，6 个前沿研究模型都能让初始系统变强。 其中 Opus 5 的 RSI-Index 最高，达到 0.4809；SWE-bench Verified 从 17.67% 提升到 50.33%，AIME 从 31.67% 提升到 97.78%。 还有一个挺有意思的结果，只改 Harness 就能带来明显提升，而单独增加训练数据的效果很有限。 看完这篇，我觉得 RSI 正在从一个很抽象的概念，慢慢变成可以真正做实验的系统问题。 接下来值得看的，就是这些「改进」能不能被继承，并继续帮助下一轮产生更好的改进。 📎 arxiv: