cua-swe-duet: 编码 Agent 基准的两条新轴（视觉×SWE 与 repo 级从零生成）合读

论文一链接：CUA-SWE: When Computer-Use Agents Meet Visual Software Engineering 论文二链接：E2E-SWE: Benchmarking LLMs on Building Working Codebases from Scratch 论文二代码：facebookresearch/E2E-SWE 发表时间：2026年9月（均为 arXiv 预印本） 机构：CUA-SWE——CMU（一作/通讯）+ USC + Wisconsin-Madison + Arizona State + AWS Agentic AI（产学联合）；E2E-SWE——Meta Superintelligence Labs（企业实验室） 领域标签：cs.AI / cs.SE，编码 Agent 基准

引言：饱和之后，测什么

2026 年 2 月，OpenAI 发表《Why SWE-bench Verified no longer measures frontier coding capabilities》，宣布停止报告 SWE-bench Verified 成绩：审计发现模型反复失败的 138 个任务中 59.4% 存在会拒绝正确解的测试缺陷，且所有被测前沿模型都能复现金标准补丁——训练污染与任务缺陷正在吞噬修补基准的信号价值。此后「编码 Agent 该测什么」迅速从一个技术问题变成基准设计的方法学问题。

本篇合读的两篇论文给出了两条正交的答案。CUA-SWE 沿「通道轴」推进：真实开发者不是只读代码的——他们运行软件、点界面、看截图、根据视觉反馈决定下一步改什么；现有基准却把编码 Agent（SWE-bench 系）和计算机使用 Agent（OSWorld/WebArena 系）隔离在两个世界。E2E-SWE 沿「任务尺度轴」推进：从修一个 issue 到凭一份自然语言规格从零建出整个可安装仓库，同时直面一个此前被近零分数掩盖的事实——近零分可能不是模型弱，而是任务本身不可解。

两条轴背后是同一个信念：基准的有效性（测得准）优先于基准的难度（测得难）。下文按九部分结构展开，第五、六部分分别呈现两篇论文的实验证据，第八部分回到合读视角提炼共性。

一、论文背景

1.1 修补基准的饱和与失真

先解释几个基础概念。编码 Agent（coding agent）是以 LLM 为核心、能在代码仓库里读文件、改代码、跑命令的自主系统，SWE-bench 是其标志性评估：给定一个真实 GitHub issue 和修复前的仓库，agent 产出补丁，靠隐藏测试判定是否修复。计算机使用 Agent（computer-use agent, CUA）则像人一样操作电脑：看屏幕截图、移动鼠标、敲键盘，OSWorld、WebArena、AndroidWorld 都属此类。两类 agent 的基准长期互不相通：前者测「改代码」，后者测「用软件」。

问题在 2025-2026 年集中爆发。一方面分数趋顶：SWE-bench Verified 的 SOTA 半年只从 74.9% 涨到 80.9%，剩余失败里一大半是任务自身的问题；另一方面污染曝光：基准题目取自开源仓库，而这些仓库恰恰在模型训练数据里。OpenAI 的审计结论是——分数提升越来越反映「训练时见过多少题」，而非真实开发能力。修补范式需要继任者。

1.2 被遗漏的事实：软件开发是视觉的

CUA-SWE 的出发点是一个日常但被基准忽视的事实：源代码和命令行输出并不能完全揭示软件的真实行为。一个平台跳跃游戏的角色会从平台上掉下去——游戏能编译、能启动、静态截图看起来也正常，只有真的去玩、观察起跳和落地、把看到的运动连回碰撞代码，才能定位问题。诊断运行时交互故障，要求 agent 把视觉观察与责任代码关联起来，再用一次交互验证修复。现有评估里，「视觉」最多以 issue 附图（SWE-bench Multimodal）或网页重建（Design2Code）的形式出现，没有基准要求 agent 在同一开发回合内「既写代码又用软件」。

1.3 被掩盖的事实：repo 级生成的近零分可能是任务病

E2E-SWE 的出发点则是对「近零分」的追问。此前 repo 级从零生成基准（如 NL2Repo-Bench）报告几乎所有模型 pass@1 聚集在 10% 上下——表面看是任务太难，但低分只有在任务可解（solvable）时才有意义：隐藏测试强制的每个行为都必须能从规格推导出来，且任何满足用户契约的实现都应通过测试、无论内部结构如何。单 issue 基准尚且有三到六成任务带实质缺陷（OpenAI 对 Verified 的审计、DeepSWE 对 SWE-bench Pro 的 24% 误拒审计），整库生成任务捆绑了几十个行为要求，一处规格-测试失配就会让全题无解——可解性对 repo 级评估是生死攸关的属性，却被先前工作当成了默认假设。

二、论文定位和关联工作

两篇论文各自站在一条研究谱系的延长线上，先分述再合观。

2.1 CUA-SWE 的谱系：从「用软件」与「改代码」的合流

编码基准线：HumanEval/LiveCodeBench/BigCodeBench 测函数级生成；SWE-bench/SWE-bench Pro/SWE-Lancer 测仓库级修补；Terminal-Bench 测命令行长流程。这条线的评估对象始终是「对已有代码库的变更」。

CUA 基准线：Mind2Web/WebArena/VisualWebArena 测网页任务；OSWorld/Windows Agent Arena/AndroidWorld 覆盖桌面与移动；Agent S2/UI-TARS/OpenCUA 发展出规划、grounding 与学习策略。这条线的评估对象是「在既有应用里完成用户任务」。

合流的先声：Programming with Pixels（PwP, CMU, 2025）首次让 CUA 通过视觉操作 IDE 做 SWE 任务，但它的结论其实是反直觉的——纯视觉交互显著弱于专用编码 agent，一旦给 CUA 两个文本 API（文件编辑+bash）性能就跃升；WeaveBench 评测 GUI/CLI/编码混合工作流，但依赖轨迹感知的 agentic judge；GameDevBench（ICML 2026）与 WebGen-Bench 把视觉反馈带进游戏与网页开发，但各限单一域。SWE-bench Multimodal 只是在 issue 里加了图。

CUA-SWE 的差异化定位：四域覆盖 + 同任务 code-only/Hybrid 严格配对 + 确定性验证。它不是「让 CUA 试试写代码」（PwP 的问题），而是「给编码 agent 加上软件使用通道，测这条通道的信息价值」；不用 agentic judge（WeaveBench 的软肋），每题配任务专属确定性验证器。

2.2 E2E-SWE 的谱系：从「改仓库」到「建仓库」

仓库级修补线：RepoBench/RepoCoder/CrossCodeEval/DevEval 测带跨文件上下文的补全；SWE-bench 系测 PR 级变更。

从零建库线：Commit0（ICLR 2025）从 54 个 Python 库挖空函数体；RepoZero 用 API 规格做跨语言黑盒复现，600 任务、顶级 agent 30~55%；NL2Repo-Bench 与 E2E-SWE 任务形态最接近（104 个 Python 任务、规格文档驱动整库生成），但用参考仓库原始测试评分；RepoGenesis/ProjectEval/E2EDev/CLI-Tool-Bench/Paper2Code 各覆盖一个子域。ProgramBench/MirrorCode 是有趣的对照组：给文档外加参考程序的黑盒探测权限，联合评测「需求发现」与「实现」——E2E-SWE 有意把这两者解耦，测试行为全部前置写明。

E2E-SWE 的差异化定位：域通用的整库生成 + 可解性工程化。与 NL2Repo-Bench 的对决是关键实验：同一 scaffold 下 NL2Repo-Bench 所有模型 822% 且聚集，但其参考库中位仅 1.5-4K LOC、单次 rollout token 更少——更小的任务反而更难，证明近零分是任务缺陷而非难度；E2E-SWE 在更大任务上反而拉开 11.767.7% 的 56 个百分点分布。

2.3 合观定位

三、问题定义

3.1 CUA-SWE：把「用软件做开发」形式化

CUA-SWE 将任务 u 建模为有限视野部分可观测马尔可夫决策过程 M_u=(S_u, A, O, P_u, Ω_u, R_u)：状态 s_t=(c_t, x_t, b_t) 由当前代码库、环境完整运行态和剩余动作预算组成，agent 只收到部分观察 o_t（文件内容、命令输出或运行中软件的截图）。动作空间 A = A_coding ∪ A_computer ∪ {finish}——编码动作（读写文件、跑构建测试脚本）与计算机动作（截图观察、鼠标键盘、导航缩放）由同一个视觉-语言策略 π_θ 在同一交互历史上选择。

形式化给定：指令 I_u、初始可编辑代码库 c^0_u、有限动作预算；求最终代码库 c_T；约束由三元验证器 V_u(c) = V^task_u(c) ∧ V^reg_u(c) ∧ V^perm_u(c) 决定——请求行为实现、指定既有功能无回归、修改不越权，三者均为二元判定，通过受控交互序列与对渲染界面/运行态的断言执行。这个抽象的精妙处在于评估与通道解耦：验证只看提交的代码库行为，与 agent 走了什么路无关，因此 code-only 与 Hybrid 两个条件可以用同一把尺子量。

论文还追问了一个更锋利的问题：视觉观察不仅是修复的反馈（看到 bug 才能定位），也可能是规格的唯一来源——58 个「application-material dependent」（M 类）任务里，图纸、服务契约、图形参考卡等关键需求信息只存在于运行中应用的界面里，代码级执行根本无法暴露。

3.2 E2E-SWE：把「可解性」形式化

E2E-SWE 的任务形式给定：一份自然语言规格 + 空工作区；求一个完整、可安装的仓库及 setup.sh；约束是全新容器中从干净状态跑隐藏测试，全过才算解（pass@1，无部分分）。刻意选全对齐而不用部分分是经过论证的：仓库是一体化软件制品，缺一个关键行为就可能不可用；且各题测试数量粒度不一，分数比例反映的是行为怎么切成断言、而非重建了多少。

但论文真正的核心定义是可解性：每个被测试强制的行为都能从规格推导，且任何满足所述用户契约的实现都能通过测试、无关内部分解。这个定义把「失败归因」从二值变成了三值——模型错误 / 规格欠定 / 测试过刚——并使「近零分」获得了诊断意义：若任务不可解，模型分数测量的是任务缺陷密度而非能力。类比：修补基准问「能不能修好这台机器」，E2E-SWE 先证明「这台机器确实可以被修好」，再问同样的问题。

四、问题解法

4.1 CUA-SWE：配对环境 + 三重验证 + 难度阶梯

种子式任务构造。每个任务从「一个可复现的运行时行为 + 一个开发需求」的种子出发：LLM 作者生成指令、初始缺陷代码库、gold 修复、若干貌似合理的负例修复和受保护的行为测试；人工审查确认需求有意义、视觉证据确实能通过基准界面观察到；可执行验证要求 V_u(c^0)=0 且 V_u(c*)=1（坏的必挂、对的必过），负例修复必须仍被拒绝——以此检验验证器能否区分「完整修复」与「部分修复」。例如日期掩码任务：清空日期+失焦应清除选择，输入无效日期应保留原值——一个两种情况都清除的修复必须被验证器打回。

交互开发路径验证。仅有好验证器不等于任务适合 CUA 评估：作者回放确认应用能被驱动到目标状态、相关视觉观察可用、代码修改在开发期间能生效、验证可从干净状态复现。刻意区分「开发时可得信息」与「评估时可用信息」——agent 只凭指令与交互历史推理，评估器则可使用特权应用状态（如直接检查棋盘底层状态），保证确定性而不泄漏。

难度阶梯扩展。构造期 agent 试解用于校准难度：成功→生成更难邻域变体（提高几何复杂度、延长时间依赖），失败→拆出更简单变体；每个变体独立过全部人审+可执行门。这产生「同族不同难」的任务家族而非标量难度标签，为 RLVR 后训练和基准随模型进化预留了接口。

匹配对照条件。code-only 与 Hybrid 共享同一指令与受保护测试；code-only 可跑非视觉构建、项目测试与自定义脚本（含非视觉执行反馈），但禁截图、禁 GUI 动作、禁浏览器自动化/DOM 读取；Hybrid 额外开放截图+图形交互。任务成功 S_i = P_i·U_i，其中 U_i 是轨迹有效性检查（防止越权通道，如违规 HTTP/DOM 观测）。

4.2 E2E-SWE：可解性作为工程管线

测试先行、规格后写。工程师与 LLM 协作，但顺序是关键：先写测试套件——每个测试走公共接口、只断言可观察行为，刻意不复用参考仓库的原始测试（那些测试为验证特定代码库而生，可能依赖私有辅助函数等参考实现的结构细节，一个正确的重实现不必保留）；参考测试仅用于识别预期行为与边界情况。规格在测试之后撰写且是测试驱动的：只提供通过测试所需的信息，测试未钉死的实现细节（内部分解、私有助手、源码树布局）一律留白。规格-测试对齐逐断言审计：测试依赖了规格留白的选择？要么把该选择升格为显式要求，要么放宽测试接受任何合理选择。

双静态审查 agent。Test Quality agent 不读规格、对照参考仓库查测试：覆盖主要用户功能、断言有实质、非冗余、实现无关；Spec Fairness agent 不读参考仓库、对照规格查测试：每个断言行为或显式写在规格中、或属领域标准惯例，标记依赖规格留白的测试。两个视角互补——前者防测试太浅，后者防测试太刚。

Rollout 引导审查。静态审查抓不到的缺陷靠真实模型失败暴露：审查员区分「实现未达规格」（真模型错误）与「满足规格仍被拒」（任务缺陷——欠定契约/过刚断言/flaky 测试）。独立生成的代码在测试下的行为，是静态检查难以企及的探针。修复 agent 随后修正任务。

离线容器评分。实现与评分全程断网（防检索参考实现）；评分时把 agent 代码库拷入全新容器、跑 setup.sh 安装、再跑隐藏测试——模拟用户 clone+install 的真实体验，杜绝开发期瞬态（构建缓存、草稿文件）带来的虚假通过。CTRF 语言无关测试报告格式使 11 种语言的评分统一。

五、评估指标与实验证据

5.1 CUA-SWE 的证据链

主对比：Hybrid 全面压倒 code-only。8 个前沿模型、32 个 model-domain 队列、840 配对 model-task 观测：

域级差异更极端：DevOps 域 9 个前沿模型 code-only 全部 0%（唯一例外 Claude-Fable-5 的 5%），而 Hybrid 下 GPT-6-Astra 达 80%——因为 DevOps 20 个任务全部是 M 类，规格只存在于服务界面展示的契约中。Mobile 同样全 M 类：code-only 均值 0.6% vs Hybrid 39.4%。

分层归因：增益精确落在 M 类。这是全篇最漂亮的实验设计。按规格来源分层后（8 模型均值）：

S 类任务上 code-only 与 Hybrid 打平（规格和命令行反馈已含解题所需全部信息，2048 游戏的 code-only 轨迹甚至能加载模块模拟按键事件做无头验证），全部增益集中于信息只能从 GUI 获取的 M 类——配对设计让「GUI 访问的价值」第一次可测且可归因。

可靠性：稳定能力 vs 重试覆盖。三重试 Game 研究中 GPT-6-Astra 34.5% 任务三次全解，GPT-5.6-Sol 仅 3.4%——重试能扩覆盖，但跨尝试一致性才区分稳定能力。20,000 次配对 bootstrap 重采样给出 GPT-6-Astra 对 GPT-5.6-Sol 的 pass@3 优势 31.0pp、95% 置信区间 [13.8, 48.3]，按游戏家族重采样仍稳健。

行为分析：编辑后 GUI 复核与成功强相关。对 2,040 次评估尝试中的 214 条轨迹做五阶段失败标注（观察缺口/误读/误诊/实现错误/验证缺口），发现编辑后做过 GUI 复核的尝试任务成功率显著更高（Web 45.8% vs 5.7%，DevOps 68.1% vs 5.9%，Mobile 83.7% vs 10.6%）——注意论文诚实地标注这是描述性关联而非因果证明。交互量本身与成功不单调相关：GPT-6-Astra Web 成功尝试中位 7.5 次截图 vs 失败 19 次，成功者反而更省。

SFT 学习信号。Qwen3.8-27B 在 gold 修复回放的动作前缀上微调（27/9 训练测试划分），留出任务验证器通过率 11.1%→33.3%——环境可产生监督信号，RLVR 接口已形式化（GRPO 适配到完整开发回合，二元修复奖励，KL 关闭）但留作未来工作。

一个反直觉异常：Claude-Sonnet-5 Web Hybrid 0.0% 低于其 code-only 8.3%。附录 P.5 的解剖显示：18 个 Hybrid 通过的补丁因轨迹违规（U_i=0，多涉违规 HTTP 或结构化观察）被记零——通道加了但用不好会更糟，这个异常恰好说明 U_i 检查的必要性。

5.2 E2E-SWE 的证据链

主榜：13 模型 56pp 分布（186 任务 × 4 次独立运行取均值，统一 ReAct scaffold，4 小时/1M token/1000 轮预算均未触顶）：

分布既不在地板也不在天花板——区分度充分且余量可观（最强模型仍有近三分之一任务无解）。

对照实验：NL2Repo-Bench 的「更小反而更难」悖论。同 scaffold 同推理努力下，13 模型在 NL2Repo-Bench 上 8~22% 聚集（除 Opus 5 22.1% 与 Fable 5 19.2%），每模型均低于 E2E-SWE 得分。但 NL2Repo-Bench 参考库中位 1.5-4K LOC（E2E-SWE 7.4K）、rollout 输出 token 更少——如果难度解释分数，更小的任务应该更可解；两个客观复杂度指标都说它更简单，分数却更低更挤，指向任务不可解是主因。这是「可解性工程的价值」最直接的证据。

可解性残留审计。发布后对 4 个模型各做一次全语料 rollout 审计（独立 judge：Claude Opus 5 max）：744 次尝试中 29 次（3.9%）含被归因于任务的失败，剔除后仅翻转 16 个结果（全部尝试的 2.2%）。对比修补基准动辄 24~59% 的任务缺陷率，可解性管线把噪声压掉了一个数量级——这使「全对齐才给分」的严苛指标变得有意义。论文同时诚实标注：judge 归因不等于缺陷定论，多需求交互的任务里 judge 可能误分类。

推理分布：前置单峰长推理。13 模型中 11 个的最长推理轮出现在前 12 轮内、6 个在前 4 轮——尽管轨迹长达数十上百轮。峰值推理可达 100K+ token、占比超 50%。归因于任务形态：规格前置完整给出、无既有代码库可探索，诱发「先全局规划、后实现修订」的模式。推理努力 sweep 显示 low→xhigh 单调升分后饱和（Opus 4.8 xhigh→max 烧 token 不涨分）。

记忆效应：12-gram 包含度分析。用模型无关代码感知分词器计算生成代码与参考库的 12-gram 包含度：Claude 三模型（Fable 5/Opus 5/4.8）在 2430 个任务上超 50% 包含度、813 个超 75%（最高 98.5%），其余 8 个模型无一超 50%——Claude 系确实「背过」不少参考库。但反直觉的是：高包含度组与其余任务的解题率差仅 −0.6/+9.6/+5.3pp——大量重叠远不保证解出任务。记忆能给你代码片段，不能给你一个通过全部测试的一致系统。

生成规模与风格。模型普遍产出远少于参考库的代码（参考越大差距越大）；生成 LOC 与成功无强相关，更多反映模型家族的编码风格（Claude 系偏大、GPT 系偏紧凑）而非正确性。

六、效果优势的根源解释

6.1 CUA-SWE：为什么 GUI 通道带来数量级增益

因果链一（信息通路，论文实验已支持）：M 类任务的规格（图纸、契约、参考卡）只存在于运行中应用的界面 → code-only 条件下这些信息结构性不可得 → 无论模型多强，code-only 在 M 类上必然失败（DevOps 0% 不是模型笨，是题面只发了一半）→ Hybrid 补上信息通路 → 增益全部集中于 M 类（+23.6~+48.1pp）而 S 类打平（0.0/−0.6pp）。分层实验是这条链的完美验证：如果增益来自「GUI 帮助调试」这类笼统机制，S 类也该受益，但 S 类没有。

因果链二（验证闭环，论文关联证据+阅读者推测）：交互让 agent 能在编辑后行使变更行为并观察结果 → 编辑后 GUI 复核与成功率的强关联（Web 45.8% vs 5.7%）支持「看一眼改完的软件」是关键行为；嵌套选择任务的配对轨迹是具体例证——GPT-6-Astra 修完 resize 后拖拽出容器框、发现选择丢失、二次修复 hit-testing；GPT-5.6-Sol 和 Claude-Opus-5 修完 resize 就提交，选择缺陷留在补丁里。但需标注：复核-成功关联是抽样描述性的，混杂任务难度与模型能力，论文自己也承认不支持显著性检验。

因果链三（效率机制，论文实验已支持）：视觉证据直接指向责任代码 → 更少交互轮次达成同一修复。GPT-6-Astra 在与 Grok-4.6 共同成功的 18 个 Web 任务上 83.3% 用更少响应（中位 28.5 vs 43.5）；单次成功成本 7.2 分钟/次，为八模型最低——覆盖广与交互省并存，反驳「高分靠暴力交互」。

外部检索对照：

综合判断：「GUI 是独立信息通路」由 M/S 分层实验直接支持，多研究（GameDevBench、VF-Coder）从不同场景汇聚同向证据，属多研究共同支持的机制；「GUI 复核行为导致成功」仍属论文内描述性关联+合情推测，因果性待控因实验确认。优势的适用条件：任务确有视觉独占信息或视觉可验证行为；若任务信息全部可从源码获得（S 类），GUI 通道增益趋零甚至为负（Sonnet-5 异常），因为通道切换本身有成本。

6.2 E2E-SWE：为什么这套管线能拉开 56pp 而前人近零

因果链一（规格-测试对齐消除系统性误拒，论文实验已支持）：测试先行+规格后写+逐断言对齐审计 → 每个测试行为都有规格依据、每个规格行为都有测试覆盖 → 满足契约的实现不再被参考实现的结构细节误拒 → 「全对齐才给分」的严格指标测的才是实现能力 → 对照组 NL2Repo-Bench（用参考库原始测试、无对齐审计）所有模型聚集 8~22%，且其客观复杂度更低——差异只能来自评估有效性而非任务难度。OpenAI 对 Verified 的 59.4% 审计从单 issue 场景佐证：测试缺陷是修补基准的系统性问题，整库任务捆绑行为更多、失配机会更多，E2E-SWE 把它当第一目标打击是对的。

因果链二（rollout 审计形成质量闭环，论文实验已支持）：静态审查抓不到的欠定/过刚缺陷，靠真实模型失败当探针 → 发布后残留任务归因失败仅 2.2% → 与 24~59% 的行业基线相差一个数量级 → 分数信号/噪声比足以支撑 56pp 的模型分布解释。「独立生成的代码在测试下的行为」之所以是更好的探针，是因为它模拟了评估对象的真实分布——静态审查者想象不出模型会怎么合理地走规格留白。

因果链三（从零生成解耦记忆与能力，论文实验部分支持）：断网+新写测试+12-gram 包含度度量 → Claude 系高记忆组解题率与低记忆组几乎无差（−0.6~+9.6pp）→ 记忆提供片段而非一致系统 → 分数主要测量「从规格构建一致系统的能力」。此处证据较弱（阅读者评估）：包含度是粗粒度指标，无法区分「背下关键算法」与「背下样板代码」；且高记忆组样本小。RepoZero 的跨语言约束（Python→JS、C→Rust 强制重写）是更彻底的防记忆设计，可作为 E2E-SWE 未采用更强防泄漏的解释性对照——E2E-SWE 选择了「测量并报告记忆效应」而非「设计任务使其不可能」。

外部检索对照：

综合判断：多研究共同支持的机制是「规格-测试失配是编码基准低分的系统性非能力原因，且可通过工程化管线压到个位数百分比」——OpenAI 审计（单 issue）、NL2Repo-Bench 反例（整库）、E2E-SWE 自身 2.2% 残留审计构成三级证据。仍属推测的部分：「记忆与能力已充分解耦」——包含度分析只是弱证据，E2E-SWE 的防记忆设计（断网）防的是推理时检索而非训练时记忆，Claude 系 98%+ 的包含度说明训练记忆真实存在且分布不均，其对公平性的影响未被完全量化。优势适用条件：任务源于公开仓库且模型可能见过参考实现时，分数解读需附带包含度信息；若换成私有或新建参考库，分布或需重新校准。

七、必要知识反推

假设一个没有背景知识的人要完成这两篇论文，最少需要掌握什么？

领域知识层。真实软件开发的完整工作流——不仅是写代码，还有运行、操作界面、看反馈、再修改（CUA-SWE 的任务设计直接来自对开发者行为的模仿，不理解这个循环就设计不出「编辑后 GUI 复核」这类行为标注）；软件测试理论——什么是实现无关的断言、回归测试、flaky 测试、测试对实现细节的耦合（E2E-SWE 的「不用参考库原始测试」的决策建立在此之上）；GUI 自动化与容器化技术——截图管线、鼠标键盘事件注入、离线容器、依赖预装镜像。

方法论知识层。基准评估的效度理论——区分度、污染、可解性、任务缺陷归因（两篇论文共享的方法论内核：先证明尺子准，再量东西）；POMDP 形式化与 RLVR/GRPO（CUA-SWE 的环境定义与后训练接口）；配对实验设计——同任务双条件、分层归因、bootstrap 置信区间（CUA-SWE 的 M/S 分层是其最锋利的武器）；LLM 辅助数据构造+人工审查的质量门模式（两篇共用：LLM 作者干活、人类守门、可执行验证兜底、负例检验鉴别力）。

工程知识层。CUA-SWE 侧：跨四域的应用适配与确定性验证器编写（对渲染界面和运行态做断言）、任务家族与难度阶梯的版本化管理、SFT 数据的动作前缀构造与损失掩码。E2E-SWE 侧：186 任务 × 11 语言的评分基础设施（CTRF 统一报告、setup.sh 安装协议、断网评分容器）、双静态审查 agent 的提示设计、rollout 失败归因的 judge 协议。

知识融合的关键节点。第一篇的创造性融合在于「配对条件 × 信息分层」：单独任何一个都不够——只有配对没有分层，会得出「GUI 有用」的笼统结论；只有分层没有配对，M 类的低分会被误读为模型不行。第二篇的创造性融合在于「把审计从一次性辩护变成生产管线」：OpenAI 的 Verified 审计是事后亡羊补牢，E2E-SWE 把同类审计（静态+rollout+修复循环）前置进数据构造流程，可解性从论文的讨论章节变成了流水线工位。两者共同的最大融合点：评估有效性是可以工程化的对象——这与「把基准做难」是两种完全不同的能力。

八、论文中可以提取的通用性灵感

灵感一：评估前先证明尺子准（可解性前置）。核心思想：任何「低分」只有在排除测量工具自身缺陷后才携带能力信息，且这个排除过程可以工程化为生产管线而非事后审计。论文证据：E2E-SWE 的 rollout 审计把任务归因失败压到 2.2%，对照 NL2Repo-Bench 无管线的聚集近零分。推广场景：教育测评（先校准试题可答性再排名学生）、模型安全评测（红队任务的「可触发性」验证）、RAG 评测（先确认检索目标确实存在于语料）、人机交互实验（先排除任务指令歧义再测界面可用性）。

灵感二：想测一条通道的价值，就做配对+分层（M/S 标签的威力）。核心思想：笼统的 A vs B 对比会把多股效应混在一起；给每个样本标注「关键信息是否只存在于被测通道」，增益的归因才会干净。论文证据：CUA-SWE 的 Hybrid 增益全部落在 58 个 M 类任务上，S 类打平——一句话说清了 GUI 的价值边界。推广场景：多模态模型的模态消融（标注答案是否必须看图）、工具增强 LLM（标注任务是否真需工具调用）、检索增强（标注问题是否含语料外知识）、团队评估新工具引入（标注工作项是否属于工具作用面）。

灵感三：把「需求发现」与「需求实现」分开测量。核心思想：一个复合能力低分可能来自多个子环节，混在一起测得到的是纠缠的分数；刻意把一个环节的信息全部前置，才能单独测量另一个环节。论文证据：E2E-SWE 前置全部测试行为，对照 ProgramBench/MirrorCode 的「探测即瓶颈」；CUA-SWE 的 S 类任务同理把「GUI 诊断」从「实现」中剥出。推广场景：产品经理能力评估（分离需求挖掘与方案设计）、科研训练（分离问题发现与问题解决）、医学诊断（分离病史采集与鉴别诊断）。

灵感四：用「独立生成物在测试下的行为」当质量探针。核心思想：审查一个评测集是否合理，最有效的探针不是再想一遍，而是让真实的被测对象跑一遍、看它的失败如何分布——静态审查者想象不出的缺陷模式，真实样本会替你暴露。论文证据：E2E-SWE 的 rollout 审查专门抓「满足规格仍被拒」的静态盲区；CUA-SWE 的构造期 agent 试解用于校准难度与发现任务缺陷。推广场景：出题后先用真实学生样本试答再定稿、API 设计评审时写独立客户端验证、Prompt 工程的红队测试、仿真环境的 sim-to-real 检查。

灵感五：负例是验证器强度的试金石。核心思想：一个判定规则「好的能过」只是必要条件，「貌似合理的坏答案必须挂」才是充分性的检验；负例的质量决定评估的鉴别力下限。论文证据：CUA-SWE 每个任务配备 plausible negative repairs（如两种情况都清日期的部分修复必须被拒）；E2E-SWE 的双审查 agent 中 Spec Fairness 专抓「测试依赖规格留白」。推广场景：面试题设计（配常见错误答案校验区分度）、安全过滤器测试（对抗性负样本）、法规合规检查（边界案例必须被正确拒绝）、奖学金评审规则（排除钻空子的申请组合）。

灵感六：记忆的可用性幻觉——拥有片段≠拥有系统。核心思想：在可分解、可检索的知识任务上，训练记忆 inflate 分数；但在要求全局一致的构建任务上，片段记忆的边际价值急剧衰减，因为瓶颈是一致性而非知识量。论文证据：Claude 系 12-gram 包含度高达 98% 的任务组，解题率与其余任务几乎无差；RepoZero 跨语言重写下模型仍有 30-55% 通过率（真理解可迁移）。推广场景：开卷考试设计（考综合题而非名词解释）、代码面试（考系统设计而非 API 默写）、法律 AI（考跨条款一致性推理而非单条法条背诵）、基准设计者的自查——我的任务是在测记忆还是测组合。

灵感七：重试覆盖与稳定能力是两个指标。核心思想：pass@k 衡量「够得着」，多次全解率衡量「靠得住」；工程部署关心后者，研究进步需要分开报告两者。论文证据：GPT-6-Astra 三次全解 34.5% vs GPT-5.6-Sol 3.4%，尽管两者 pass@1 差距小得多；E2E-SWE 用 4 次独立运行取均值而非单次。推广场景：自动驾驶接管评估（多次一致性）、模型部署的回归测试、人类专家可靠性研究、竞赛编程的稳定性训练。

九、局限与结语

两篇论文的局限都写得坦白。CUA-SWE：SFT 只是「早期积极信号」，可验证学习信号与规模化 RLVR 是未竟之功（长多模态轨迹上的稳定优化与跨代码/交互的信用分配仍开放）；四域之外更多领域、更长任务待扩展。E2E-SWE：judge 归因非定论（多需求交互任务中 judge 可能漏判规格蕴含关系）；任务源自公开仓库，训练记忆真实存在，包含度只是粗粒度度量；186 任务对 11 语言的覆盖不均（Python 占 55%）。

但作为一组「基准该往哪走」的答卷，两者的互补性恰到好处：CUA-SWE 沿通道轴把「agent 用自己写的软件」纳入测量，配对分层设计让每一点增益都可归因；E2E-SWE 沿尺度轴把「从一份规格到一个仓库」纳入测量，可解性管线让每一分都有信号价值。它们共同印证了 2026 年基准方法学的转向：当模型强到分数趋顶，基准的进步不再来自把任务堆难，而来自把测量的有效性工程化——控制信息通路（CUA-SWE）、净化任务本身（E2E-SWE）、对齐验证与规格、量化记忆与能力的分离。下一轮基准竞赛的胜负手，是尺子的精度，不是尺子的长度。