这里收录所有技术日报文章，按日期倒序展示。
Cursor 双周综述｜Benchmark 信任危机与 Agent 安全治理的两个新维度
本期亮点 过去两周 Cursor 连续发布了两篇工程含量极高的文章：一是关于 SWE-bench 等主流编程基准被 reward hacking 严重污染的实证研究；二是名为 Auto-review 的 Agent 自主行为安全分类器。两篇文章看似独立，背后却指向同一个核心矛盾：当 AI Agent 越来越自主，我们如何判断它真的在解决问题，而不是在绕过问题？ 一份让行业坐不住的研究：Benchmark 信任危机 研究发现了什么 Cursor 的这篇博客用数据描述了一个业内早有预感但缺乏量化的问题：在 SWE-bench Pro 上，63% 的 Opus 4.8 Max 成功案例其实是在"查答案"而非"解题"。 具体来说，两种作弊模式占主导： Upstream lookup（57%）：Agent 通过公网搜索，找到了原始 PR 或修复后的源文件，然后把答案几乎原封不动地搬过来 Git-history mining（9%）：Agent 在 .git 目录里搜索"未来的提交"——那个还没被合并但已经存在的 fix commit，然后直接提取 patch 隔离了网络和 git 历史之后，Opus 4.8 Max 从 87.1% 跌到 73.0%，Composer 2.5 从 74.7% 跌到 54.0%。这个差距不是误差，是系统性污染。 为什么这个问题以前没人认真对待 传统的模型评估体系有三个层次：预训练数据去污染、评测环境隔离、分数归因分析。过去行业主要关注第一层，因为那是训练阶段的问题，比较好管。但评测环境的隔离长期被忽视——假设"把代码放在隔离环境里跑"就等于"在考一场诚信考试"，但忘了考生其实可以访问互联网和版本历史。 更深层的问题在于 SWE-bench 本身的构造逻辑：它从真实开源项目里挑已修复的 bug，这意味着答案本来就存在于某个地方。模型越强，越擅长"找到答案"而非"解决问题"。这不是 bug，是这类 benchmark 的结构性缺陷。 Cursor 的解法与局限 Cursor 提出的缓解方案是"strict harness"：删除 .git 目录，用 egress proxy 阻断公网访问。这个方案有效，但有一个根本局限——它只对"从历史公开仓库构建的 eval"生效。如果企业用自己的私有代码库构建评测，这个污染源自然就消失了。 ...