论文一：CrossSWE: Benchmarking Cross-Repository Joint Development for Coding Agents 数据集：CrossSWE-Bench (Hugging Face) 论文二：Do Coding Agents Catch Their Own Bugs? (They Don’t.) (Foresight-SWE) 论文三：Harvesting SWE Benchmarks from Wild Vibe Coding Sessions (SessionFarmer) ｜ 代码：bytedance/SessionFarmer ｜ 基准：SessionFarmer-CropChat1 发表时间：均为 2026 年 11 月（arXiv 2611.01484 / 2611.01181 / 2611.02440） 机构：CrossSWE——上海交通大学、西安电子科技大学、新加坡管理大学（高校合作，无企业）；Foresight-SWE——纽约大学、普林斯顿大学、斯坦福大学（纯学术三校）；SessionFarmer——上海科技大学、字节跳动、上海人工智能实验室（企业+高校深度合作，多人共同一作双 affiliation） 领域标签：cs.SE（软件工程基准与编码智能体评测）
一、论文背景
要从"为什么是这三篇"讲起，得先看清编码智能体评测现在站在哪里。
SWE-bench 范式及其成功。 2024 年的 SWE-bench 确立了"仓库级议题解决"这一评测范式：给智能体一个真实 GitHub 仓库的 base commit 和一条人工撰写的 issue，让它自主探索、修改代码，最终以隐藏测试套件是否通过来判分。这条范式之所以成功，是因为它同时满足了真实（真仓库、真缺陷、真测试）与可复现（Docker 环境、F2P/P2P 测试划分）两个此前难以兼得的要求。此后一代代基准沿两个方向扩展复杂度：更多语言（Multi-SWE-bench）、更长任务（SWE-bench Pro）、更大改动（SWE-bench ProMax，56.1% 对比值的参照系）、更完整的开发生命周期（FEA-Bench/FeatureBench 从修 bug 走向功能实现）。
但复杂度的增长始终被锁在一个边界内。 无论代码库多大、任务多长，智能体需要理解的上下文和需要修改的范围，始终被单仓边界封死。CrossSWE 的开篇论证正建立于此：真实软件开发天然跨越多个相互依赖的仓库——API 演进、依赖迁移、provider-consumer 协同、client-server 对齐，改一处往往必须同步改多处。论文给了一个干净的真实案例：oauth2-proxy 与 Higress 两个仓库，会话刷新时多个 Set-Cookie 被错误合并成一个 HTTP 头导致认证失败；修复必须两侧同时动手——oauth2-proxy 侧把 cookies 保留为列表，Higress 侧逐条发出。只改任何一侧，共享接口要么类型断言失败，要么刷新后的 cookie 被静默跳过。
第二个盲区：需求永远是显式给出的。 SWE-bench 系基准把完整需求写在 issue 里，模型的目标函数就是"满足陈述需求"。但真实软件任务的代价大头恰恰在未陈述的部分。Foresight-SWE 用 Django 的 tracker 数据量化了这一点：2021 年 8 月至 2026 年 8 月共 4,225 张工单，47.05% 被归类为 bug，947 个被修复——大约隔天修一个 bug，中位涉及 4 名参与者、5 条评论、5.3 天；未在一个月内修复的 22%，中位拖到 121 天，期间缺陷一直活在已发布代码里。这些后续修复的缺陷，相当一部分是最初变更引入的。人类工程师的常识是"改代码时要预判它会引入什么问题"，而现有基准完全不测这件事。
第三个盲区：评测任务与开发者真实工作流脱节。 公开基准的任务类型、语言分布、代码架构与一支团队自己的生产环境相去甚远，榜单分数无法预测"这个改动在我的工作流里有没有用"。与此同时，对话式开发（vibe coding）已成日常：Stanford 的 SWE-chat 数据集显示 41% 的会话中几乎所有提交代码都由 agent 撰写。这些野生会话留下了大量"需求-实现"的真实记录，但原始日志是碎片化且带噪声的：需求跨轮演化、无关会话与代码提交同时发生、一个工程目标横跨多个会话。怎么把这种日志变成可复现的评测任务，此前没有完整答案——最近的 REAP 路线主要从单条用户消息或单个会话抽取任务，天然会漏掉后到的需求。
三篇论文正好是三块拼图。 CrossSWE 把评测的空间轴从单仓拉到跨仓联合；Foresight-SWE 把评测的时间轴从"当下满足陈述需求"拉到"未来不引入未陈述缺陷"；SessionFarmer 把评测的任务来源从人工策展的 GitHub issue 拉到开发者真实协作会话。合起来，它们共同把编码智能体评测从"单仓、显式需求、孤立任务"推向"真实工程协作"。
二、论文定位和关联工作
三篇论文各自处在一条研究谱系的延长线上，定位各不相同。
2.1 CrossSWE：从"多仓上下文"到"多仓联合修改"
- 单仓加复杂度路线：SWE-bench → SWE-bench Pro（长程任务）→ SWE-bench ProMax（专家策展的大规模多语言重构）。这条路线回答"单仓内还能多难"，但没有触碰仓库边界。
- 多仓上下文路线：BeyondSWE 引入跨仓推理、依赖迁移等知识范围；DepBench 研究依赖破坏性变更的修复，上游发布说明作为修复证据。但论文的关键观察是：在这些基准里，其他仓库只是上下文——agent 读它们来理解 API 或依赖，写补丁和跑测试仍然落在一个仓库里。
- CrossSWE 的差异化：它要求补丁本身横跨多个相互依赖的仓库，并用可执行手段验证"联合必要性"（详见第三、四部分）。与 DepBench 的区别一针见血：DepBench 的上游仓库是修复证据的来源，验证仍在单仓内执行；CrossSWE 的解本身就在多个仓库里。
2.2 Foresight-SWE：从"被告知找 bug"到"实现时自发预见"
- 主动找 bug 路线：Active-SWE、SWE-Sweep 隐去 issue 报告，让 agent 在仓库快照中自主找 bug 并修复，最好成绩分别只有 20.0% 与 9.5%。RepoAudit 只做识别不做修复（40 个真阳性、78.43% 精度）。共同点：agent 知道自己在找 bug，任务指令本身就是搜索指令。
- 安全子域：SecureVibeBench 测 agent 是否复现人类开发者引入的漏洞，但限于 C/C++ 与安全类静态/动态分析，只覆盖可靠性开发的一个切面。
- 缺陷预测路线：JIT-SDP 用代码变更属性预测"哪个变更易引入缺陷"，ReDef 把它搬到 LLM，CodeFlowLM 定位到行——这些工作预测缺陷会出现，但不要求 agent 在实现任务本身时规避它。
- 多 PR 演化路线：SWE-Milestone、SWE-Chain、ChainSWE、SWE-CI 等评测连续 PR 序列上的任务完成与正确性保持，但它们执行的是显式指定的变更序列。
- Foresight-SWE 的差异化：只给 agent 原始任务（PR1 的陈述），用未来 PR2 的测试来判定 agent 是否预见并规避了未声明的缺陷。agent 不知道有 bug 要找——它只是在做一件普通的开发任务，而评分标准里藏着 88 天（中位）后人类才发现的坑。
2.3 SessionFarmer：从"任务边界给定"到"任务边界待发现"
- SWE-bench 式构建：issue-PR 链接给出天然任务边界，后续工作（SWE-rebench、SWE-bench goes Live、Multi-SWE-bench）自动化了挖掘与环境搭建——但边界始终是给定的。
- 反污染路线：DeepSWE 让工程师从零编写任务与验证器，避免预训练污染，质量极高但人力成本大（同类人工基准 FrontierCode 报告每任务超过 40 小时维护者工时）。
- 野生会话路线：SWE-Chat 提供真实交互数据集；RealClawBench 从开放 telemetry 收集任务；SWE-Together 用用户模拟器重放多轮会话；最接近的 REAP（Meta，ASE 2026 Industry Showcase）从企业生产日志构建执行式基准，但主要从单条用户消息或单会话抽取任务陈述。
- SessionFarmer 的差异化：直面"日志记录单元与工程任务边界不重合"这一根本问题，以工作 episode（围绕单一工程目标的会话+提交区间）为任务单元，并补齐环境重建、任务陈述、质量 rubric、测试构造的全链路自动化，最后请原作者审计。
2.4 三篇合起来的定位
| 维度 | 之前的路线 | 本组三篇的突破 |
|---|---|---|
| 修改范围 | 单仓内加复杂度（Pro/ProMax）；多仓仅作上下文（BeyondSWE/DepBench） | CrossSWE：解本身跨仓，2^N 穷举验证联合必要性 |
| 需求形态 | 需求显式给出（SWE-bench 系）；或被告知去搜索缺陷（Active-SWE/SWE-Sweep） | Foresight-SWE：需求未声明缺陷，用未来 PR 的测试度量前瞻性 |
| 任务来源 | 人工策展 issue/PR 对；或从单条消息/单会话抽取（REAP） | SessionFarmer：野生会话按 episode 级重组，跨轮跨会话收敛需求 |
| 验证器 | 沿用 PR 自带测试（已知有误判） | SessionFarmer：mutant+盲求解器双闭环精炼；CrossSWE：2^N 必要性测试；Foresight-SWE：四状态执行验证 |
三、问题定义
三篇论文各自完成了一次干净的问题抽象，值得逐一拆开。
3.1 CrossSWE：把"联合必要"变成可执行谓词
具体问题：怎么区分"一个涉及多仓的任务"和"一个必须联合修改多仓才能完成的任务"？前者只是叙事属性，后者才是能力测点。
抽象洞察：如果 N 个参与仓库各自的 gold patch 已知，那么整个系统有 2^N 个混合版本配置（每个仓库取 base 或 patched 状态）。联合必要性可以被定义为这 2^N 个配置上的测试行为谓词：全 base 配置与所有部分打补丁配置都必须 FAIL，只有全打补丁配置 PASS。
形式化：给定实例含 N 个仓库、各自 base 状态与 gold patch，目标测试集 T。对任意配置 c ∈ {0,1}^N，记 T(c) 为其通过性。保留该实例当且仅当：
- T(0,…,0) = FAIL（基线确实坏）
- 对所有非全 1 配置 c ≠ (1,…,1)：T(c) = FAIL（任何单侧/部分修复都不够）
- T(1,…,1) = PASS（联合修复确实有效）
精妙之处在于它把"任务是否真的需要跨仓协调"从人工判断降为机械可验证的性质，堵住了"涉及多仓但单仓可解"的假阳性。这也是同类基准中第一个可执行的必要性证明。
3.2 Foresight-SWE：把"前瞻性"定义为合取指标
具体问题：怎么测量"agent 在完成明确任务时顺带规避了未声明的潜在缺陷"？
抽象洞察：利用软件演化的自然结构——PR1 引入缺陷、PR2 修复它——PR2 的 F2P 测试就是"缺陷不存在"的可执行定义。于是前瞻性不需要任何主观评分：
- resolve rate = 通过全部 PR1 的 F2P+P2P 测试（任务完成且无回归）
- anticipation score = PR2 F2P 测试通过率的均值（部分预见）
- FRR（foresight resolve rate）= 同时通过全部 PR1 F2P+P2P 与全部 PR2 F2P 的实例比例
FRR 是一个合取：完成 ∧ 预见。这个定义的精妙处在于它把"预见"锚定在真实人类后续验证过的缺陷上（缺陷必须通过四状态执行验证确认在 PR1 head 已存在），既避免"过度防御性代码"被奖励（只测特定真实缺陷），又避免主观评分。
3.3 SessionFarmer：把任务边界从记录单元解耦
具体问题：原始日志的记录单元（会话、commit checkpoint）与真实工程任务边界不重合，怎么重组？
抽象洞察：一个工程目标 G 的证据散落在时间上相邻的多个 checkpoint 与多个会话里，而 telemetry 的 session-checkpoint 链接只记录"提交时哪些会话开着工作区"，不证明贡献。任务边界重构本质是一个聚类+切分问题：先按时间（Δt ≤ 24h）与共享会话把 checkpoint 连成工作簇（界定搜索空间），再用"会话是否真的驱动了代码变更"过滤边，最后沿 checkpoint 边界把簇切成单一目标的 episode。类比来说：原始日志像一盘多机位混剪的录像，SessionFarmer 先按场景聚类，再删掉闯入镜头的群演，最后按剧情线重新剪辑。
episode 定义为四元组：base checkpoint（工作前仓库状态）+ final checkpoint（完成后状态）+ 两者 git diff（金标补丁）+ 确认会话的全量转录（注意保留完整转录而非按 checkpoint 时间戳截断——开发者常在首次提交前讨论设计）。
3.4 三个定义的共性
| 测点性质 | 验证手段 | 挡住的假象 | |
|---|---|---|---|
| CrossSWE | 跨仓协调修改能力 | 2^N 混合配置测试 | 多仓背景阅读冒充联合开发 |
| Foresight-SWE | 未声明缺陷的前瞻规避 | 未来 PR 的 F2P 测试 | 会修 bug 冒充有预见 |
| SessionFarmer | 真实工程目标的自包含重建 | 原开发者审计+mutant+盲求解器 | 日志切片冒充完整任务 |
三者共享同一个元思想：当"任务是否测到 X"本身可以被可执行地验证时，基准的构造才从策展艺术变成工程。
四、问题解法
4.1 CrossSWE：四阶段构建管线
阶段一：候选收集。 GitHub API 挖掘 2025 年 1 月至 2026 年 9 月活跃仓库的开发历史，按跨仓关系线索搜索：API 演进、依赖迁移、provider-consumer、client-server；再通过跨仓显式引用（issue/PR/commit/仓库名出现在另一代码库中）补充候选。设计取向是高召回。
阶段二：人工筛查。 逐条检查候选及其源 PR、时间线、被引用仓库与对应 commit。保留标准：源证据指向一个具体软件变更，且至少两个仓库有实质实现改动、彼此有因果/依赖/协同关系。仅文档性参与（文档、release notes、changelog）的候选剔除。
阶段三：环境构建与联合必要性验证（核心设计）。 为每个候选构建单一 Docker 镜像：N 个仓库各自检出验证过的 base commit，全部依赖装在同一环境，仓库保持干净 git 状态，agent 镜像中剔除固定 checkout、gold patch、隐藏测试等工件。然后重建每个仓库各自的 gold patch，在同一环境内穷举 2^N 混合配置，只改"哪些仓补丁被应用"这一个变量，在每个配置上跑目标 FAIL_TO_PASS 测试。双仓情形即 (A0,B0)、(A1,B0)、(A0,B1) 三者全 FAIL 且 (A1,B1) PASS。
阶段四：问题陈述构建。 参照 SWE-bench ProMax 的做法，从修复前视角写自包含自然语言任务描述：陈述可观察失效、期望行为与跨仓需求，不规定实现细节；显式删除解决方案相关信息（gold patch、修复 commit、评估器元数据）；人工核对陈述、源证据与测试三者一致，且显式说明跨仓目标行为，避免隐藏测试去测 gold 特有的函数名/字段名/路径。
评测设定。 MINI-SWE-AGENT v2.4.6 统一 scaffold（轻量 shell 交互式仓库级 agent 框架），五个前沿模型，高推理档，统一配置；每实例上限 300 步与 $10；Pass@1 以通过完整评测套件计。
4.2 Foresight-SWE：从 11,609 个候选到 212 个实例
步骤一：候选 PR 对挖掘。 两条线索找 (PR1, PR2) 对：一是显式作者证词（“introduced in PR1”、“broken by PR1"等），依赖仓库惯例；二是 changelog、Trac 工单（Django）、CVE/GHSA 公告，再用经典 SZZ 算法回溯——把 PR2 删除/改写的行用 git blame 追到引入它们的 commit，映射回 PR，取"引入最多受影响行"的 PR 作候选 PR1。初始池 11,609 对、35 仓库、4 语言。
步骤二：双 LLM-judge 过滤。 第一个 judge 判 PR2 是否修复了一个可预期的真实缺陷（排除新功能、重构、纯 revert、与社会性回退纠缠的变更——judge 的判据设计得很细，如安全修复即便对合法用户无可观察缺陷也算真缺陷）；第二个 judge 只审 SZZ 推断的对，验证” blame 落点 ≠ 责任者"的经典陷阱（PR1 只是把有缺陷的旧代码搬了位置，或缺陷来自中间 commit）。同时要求两个 PR 都改测试文件（PR1 可被评分、PR2 提供 anticipation 测试），并限制在 2021-2026 五年窗口内保证可重建。剩 2,262 对。
步骤三：四状态执行验证。 每对重建四个仓库状态：PR1 的 base/head、PR2 的 base/head。参照 SWE-ReBench V2 用 LLM agent 推断安装与测试命令（论文附录给出相当完整的 installer agent 提示词设计，如"failing tests are expected and are not your problem"防止 installer 去修代码）。执行验证条件：PR1 与 PR2 的测试各自在 base 失败、head 通过；且 PR2 的测试在 PR1 head 上失败——这条是关键，它可执行地证明缺陷在 PR1 合并后就已存在。通过后剩 815 对。
步骤四：问题陈述生成。 LLM 基于 PR1 标题、描述与源补丁生成自包含问题陈述，经两道检查：不泄露潜在缺陷、不规定参考实现；且充分具体可让 agent 满足 PR1 测试。再经清晰度与泄漏审计，492 对留档，分层抽样 212 实例。最终含 958 个 anticipation 测试、4,307 个任务测试、301,659 个回归测试。
评测协议。 闭源模型用原生 harness（OpenAI 用 Codex、Anthropic 用 Claude Code——用户实际交互且被官方优化过的接口），开源模型统一 mini-swe-agent。
4.3 SessionFarmer：全链路收割框架
(a) episode 重构。 前述聚类+切分之外，两处工程细节值得注意：其一，会话相关性过滤采用三次独立投票全正才确认的严格规则（direct/partial 贡献需引用具体转录事件）；episode 切分要求两次独立 LLM 调用在 (repository, base, final) 三元组上完全一致才保留，以对抗 LLM 非确定性。其二，机械资格过滤：实现改动 100-5000 行（排除平凡与不可复现）、确认会话数 ≤ 5、非核心/测试/生成文件占比 ≤ 80%、跨 fork 无重复区间。
(b) 环境重建。 vibe coding 会话大量隐式调用仓库清单未声明的工具（gh CLI 出现在 79 个任务、版本管理器 46 个、agent CLI 25 个……）。两步处理：LLM 从命令形状与用户消息中提出候选工具假设；确定性机械校验要求每个可执行名或用户引文逐字出现在会话转录里，挡掉幻觉（42 条伪主张被弃）。Environment Builder agent 在隔离沙箱中对 base 仓库+依赖差迭代试错产出 Dockerfile，断网冷启动验证（base/final 两树均可切换、指定测试选择器一过一挂、依赖版本可查询）后冻结为密闭镜像。
(c) 任务陈述与 rubric。 Task Author 在冻结环境内读 base/final 两状态与全部确认会话转录，把任务陈述写成原子义务条款的扁平列表，每条引用其来源对话事件 ID；需求只能来自开发者指令与被显式批准的 agent 提议，金标补丁只用来确认"哪些讨论过的行为最终真的完成了"。独立 LLM 校验器审来源保真、需求完整、实现开放性，3 次提交不过即弃。随后同会话撰写三维等权 rubric：Clarity（命名/控制流/局部可读性）、Design（抽象边界/职责分离/避免重复）、Repository fit（邻近文件结构/工具约定/配置风格），0-2 分制（0=阻断合并的实质缺陷，1=可合并，2=明显优秀）。金标质量门：金标补丁自身必须过 QualityResolved（3 次独立评审中位总分 ≥3 且任一维度最多一次 0 分），过不了就弃任务——同时过滤掉低质量原始提交与过于严苛的 rubric。
(d) 测试构造闭环（方法学上最有意思的部分）。 背景：57.9% 的 CropChat 金标根本不改测试文件，测试只能从零合成，而未经校准的 LLM 生成测试同时有假阳性（放过不完整方案）与假阴性（过拟合金标实现细节而误杀合理替代实现）。两段闭环：
- 标准精炼（对 mutant）：Task Author 构造"需求破坏 mutant"——金标补丁的变体，每个恰好破坏陈述中的一条需求条款，充当不完整/捷径方案的负对照。Test Author（对 mutant 补丁完全盲，只可见被违反条款+触发条件+预期错误行为）提交的测试套件须满足：金标上 3 次全新运行全过；未修改 base 上至少 1 个针对目标变更的场景失败；每个 mutant 都被绑定其违反需求条款的场景击破。论文给了一个具体例子：IP 白名单任务，mutant 把空列表判断从
&&改成||，使 CIDR-only 白名单错误放行所有人；第一版测试只测了混合白名单，第二版补上 CIDR-only 外部访问者得 403 的用例才抓住它。 - 求解器精炼（对盲求解）：一个盲求解器以与被评 agent 完全相同的协议解题；Test Author 维持连续会话上下文，对求解器补丁做独立语义裁决，与机械测试判决比对——不一致即暴露假阳或假阴，测试必须修到机械判决与语义裁决一致，同时还得重新通过金标/base/mutant 全部检查。
构建成本。 242 个任务全链路共 4,406.6M 输入 token（89.5% 是缓存读）、41.1M 输出、427.7 活跃工时；摊到每个终版任务 18.2M 输入 token、约 106 分钟活跃工时——对照人工基准 FrontierCode 的 40+ 小时/任务，大约 20 倍的量级缩减。
五、评估指标与实验证据
5.1 CrossSWE：分数塌陷与失败模式定位
主指标 Pass@1（通过完整测试套件），辅以 token/步数/成本刻画资源开销。
| 模型 | Pass@1 | 单语言 | 多语言 | 输入 token | 步数 | 成本 |
|---|---|---|---|---|---|---|
| GPT-6.1 Sol | 58.48% | 60.34% | 54.55% | 0.97M | 32.9 | $0.35 |
| DeepSeek V4.1 Flash | 52.63% | 52.59% | 54.55%→52.73% | 17.54M | 152.7 | $0.29 |
| Claude Sonnet 5.5 | 50.29% | 52.59% | 43.64% | 1.31M | 29.2 | $0.52 |
| Qwen3.8-Flash-Next | 45.03% | 45.61% | 43.86% | 13.31M | 182.1 | $0.29 |
| GLM-5.3 Flash | 43.86% | 45.69% | 40.00% | 9.74M | 141.7 | $0.34 |
支撑核心论点的三组证据：
- 分数塌陷：最强模型 GPT-6.1 Sol 的 58.48% 显著低于其在 DeepSWE v1.1 的 75.2%——跨仓联合是单仓复杂度增长覆盖不到的独立难度维度。
- 单侧对照实验（证明难度来自联合而非多仓上下文）：从 165 个双仓实例派生 330 个单侧任务——两仓仍在环境中，但只需改一仓。GPT-6.1 Sol 单侧 64.55%（+6.07pp）且步数 32.90→18.54；DeepSeek 单侧 61.81%（+9.18pp）且步数 −25.76。同环境、同上下文、只去掉联合要求，分数就回升——干净地分离出联合修改的独立贡献。
- 失败模式分析：人工分析失败轨迹并归为五类，跨仓不一致是全部五个模型的第一大失败模式（GPT 44.2%、Claude 41.2%、DeepSeek 29.2%、GLM 40.7%、Qwen 41.3%），其次实现不完整（约 25%）。跨仓不一致包括接口/协议/工件不兼容及相关编译构建失败——正是任务设计针对的接口一致性能力。
5.2 Foresight-SWE：71 点鸿沟与干预的代价
| 模型 | Resolve Rate | Ant. Score | FRR |
|---|---|---|---|
| Qwen3.8 Flash Next | 91.98% | 22.88 | 20.75 |
| Claude Opus 5 | 77.83 | 30.57 | 24.53 |
| GPT-5.6 Sol | 84.43 | 23.98 | 18.40 |
| GPT-5.6 Terra | 74.53 | 23.91 | 15.09 |
| DeepSeek-V4 Flash | 58.49 | 31.76 | 18.87 |
| Claude Sonnet 5 | 59.91 | 28.76 | 16.98 |
| （其余 5 个开源模型） | 18.40-80.66 | 19.64-28.37 | 6.13-11.32 |
核心实验链：
- 总体鸿沟：11 模型平均 resolve 60.7%，平均 FRR 仅 14.8%（区间 6.13-24.53%）。没有任何模型能在超过四分之一的实例上既完成任务又规避后来的缺陷。
- 指明缺陷消融（瓶颈定位）：给 5 个模型 PR2 的任务描述（缺陷被显式指出），平均 resolve 91.23%；同一批缺陷不指明、要求自发预见时 FRR 只有 19.91%。71 点鸿沟直接证明：模型基本都会修（能力在），但识别不出（预见缺）。一个讽刺的细节：有实例只要求调整字段构造顺序，PR2 修复只是把生成器输出包成 tuple 一行改动，11 个模型全部失败。
- 分层：PR2 难度 easy→hard，FRR 从 18.3% 跌到 2.1%（GPT-5.6 Sol 在 hard 上得 0 分）而 resolve 基本不变——越难的缺陷越预见不了，且这与任务完成能力无关。major 缺陷比 minor 低 5.0pp；silent 缺陷（代码跑通但返回错误结果，无报错信号）FRR 12.5% vs loud 缺陷 18.5%——没有错误信号时要靠推理预期行为，难度陡增。
- 干预实验：proactive 提示（明确要求考虑边缘情况）让 GPT-5.6 Sol FRR +13.20pp、Claude Opus 5 +8.02pp，但代价是 resolve 各降约 2pp；self-review 让 Opus FRR 到 35.85%，却让 GPT-5.6 Sol 的 resolve 掉 14.62pp；Claude Sonnet 5 上 proactive 反而降 FRR 3.3pp。提升预见常以任务完成为代价，且效果因模型而异、不可靠。aiohttp 的定性案例说明机制：baseline 的 Opus 复现了 PR1 的做法（resolve 但漏缺陷）；加 proactive 后 Opus 预见了 PR2 的修复，却因额外清理改动把 PR1 测试搞挂了。
5.3 SessionFarmer：开发者审计与 harness 方差
12 个模型-harness 配置（4 模型 × Codex/Pi/OpenCode）× 每任务 3 次独立 rollout：
| 发现 | 数据 |
|---|---|
| 任务仍然很难 | 最高 kimi-k3+Codex Pass@1 39.3%（Pass@3 57.3%、Pass3 23.8%）；最低 glm-5.2+Pi 21.1%；26.0% 任务在全部 36 次 rollout 中无一解出 |
| harness 敏感性是模型相关的 | gpt-5.5/terra 换 harness 只动 1.1-1.2pp；glm-5.2 动 3.2pp；k3 从 Codex 到 Pi 掉 8.4pp（timeout 率 6.1%→12.7%） |
| rollout 方差可观 | 22.8% 的任务-配置对在 3 次重复中判决不一致；60.9% 三连败、16.2% 三连胜 |
| 质量门拦截率 | CropChat 上功能通过的 rollout 仅 2.1% 被 rubric 拦；CropEnterprise 上 12.6% 被拦（OpenCode 下 terra 机械通过率与 Codex 持平 21.4%，但 QualityResolved 掉 16pp） |
| 测试闭环收益 | 精炼前条件假阴率 terra 68.0%/gpt-5.5 80.9%（初始 LLM 测试过拟合金标细节）；精炼后降 34.0/32.0pp，BAcc +8.9/+7.2pp，落在 SWE-Bench-Pro 官方测试（63.8）与 DeepSWE（76.3）之间 |
| 原开发者审计 | 4 位原作者 × 28 任务 × 2 独立评审：episode 边界 94.6%、会话归属 96.4%、任务陈述 100% 接受（84.6% 精确匹配）、三维 rubric 97.0-99.6% 认可 |
| episode 必要性 | 87.6% 任务的需求依赖开场消息之后的补充；14% 跨会话；多会话任务中"后段会话首次写下的金标代码占比"与"只在后段会话提出的需求占比" Spearman ρ=0.69；后段会话 88.1% 的角色是实质需求更新（36.8% 加行为、27.6% 改需求、18.4% 澄清约束） |
| 上下文消融 | 多会话任务陈述的需求全覆盖率：仅首消息 26% → 仅首会话 54% → 全 episode 75%；单会话任务 49% → 78% |
这组数字共同支撑论文的两个主张：其一，单轮/单会话抽取（REAP 路线）在结构上注定丢需求（87.6% 这个数字是直接证据）；其二，可靠的模型比较必须模型与 harness 联合评测并报告多次运行——单次 Pass@1 掩盖了大量轨迹方差。
六、效果优势的根源解释
按模板要求，本部分分三个子节：先给因果链并标注证据等级，再用外部检索交叉验证，最后综合判断未决问题。
6.1 根源机制与证据链
CrossSWE：为什么跨仓联合比单仓更难？
- 因果链 A（上下文边界）：现有基准的复杂度增长都在单仓内，agent 的探索-修改循环被训练和评测都限定在一个代码库内 → 跨仓任务要求在 N 个代码库间维护共享接口的心智模型（依赖推理、变更传播、接口一致性）→ 这是未被现有训练分布覆盖的能力 → 体现为分数从 75.2%（DeepSWE）塌到 58.48%。【论文实验已支持：分数对比与单侧对照】
- 因果链 B（失败定位）：跨仓不一致占五模型失败首位的 29.2-44.2%，且单侧化后步数骤降（GPT −14.36 步）→ 难度不仅来自"更多要改的代码"，而来自必须同时在两侧产出相互兼容的修改——部分正确（只改对一侧）在这个任务结构下等于全错。【论文实验已支持：失败模式分布+单侧对照的步数与分数双变化】
- 阅读者推测：跨仓一致性失败的具体机制可能是 agent 在两仓间切换时丢失了"另一侧的接口假设"（上下文管理问题）而非单纯的知识缺失——论文未做逐步轨迹的上下文级分析，此为待验证假设。【阅读者推测】
Foresight-SWE：为什么预见与修复差 71 个点？
- 因果链 A（训练目标错位）：SWE-bench 系基准全部把需求显式给出 → 训练与对齐的优化目标是"满足陈述需求"，未陈述的正确性不在目标函数里 → 模型具备修复能力（指明后 91.23%）但从未被要求在实现时搜索"我的改动会引入什么失败模式"。【论文实验已支持：指明/未指明消融是最直接的因果证据】
- 因果链 B（信号依赖）：silent 缺陷 FRR（12.5%）低于 loud（18.5%），major 低于 minor 5.0pp，PR2 难度升级时 FRR 崩塌而 resolve 不变 → 无显式错误信号时需要从代码与预期行为推理，这恰是当前模型未被训练的路径；缺陷越严重越常落在高频无信号路径上。【论文实验已支持：分层统计】
- 因果链 C（干预的副作用）：proactive/self-review 提升预见但拉低 resolve，且模型间不稳定 → “更广的检查"与"完成原始任务"在当前对齐下是竞争目标；扩大审查范围会引入对原任务的回归（aiohttp 案例）。【论文实验已支持：干预实验+定性案例】
- 阅读者推测：结合外部文献（见 6.2 的 Reality Is the Final Verifier），self-review 提升有限更深层的原因可能是自评共享写作时的同一组假设——同一模型写又同一模型查，盲点同源。论文数据（self-review 对 GPT 有大副作用）与此一致，但论文本身未做跨模型 review 的对照。【阅读者推测】
SessionFarmer：为什么 episode 级重组与双闭环测试有效？
- 因果链 A（任务边界）：真实工程目标与日志单元不重合，87.6% 任务靠后续轮次补充需求、14% 跨会话 → 单轮/单会话抽取结构性地丢失需求 → episode 级重组把跨轮跨会话的需求演化收敛为自包含规范（全覆盖 75% vs 首消息 26%）。【论文实验已支持：上下文消融】
- 因果链 B（测试假阴的机制）：初始 LLM 生成测试的条件假阴率高达 68-81%，根因是过拟合金标实现细节（断言私有 helper 名、文件路径）→ 盲求解器提供"与金标不同的合理实现"作为校准点，语义裁决与机械判决不一致处即假阴所在 → 精炼砍掉 34pp 假阴。mutant 负对照则反向压假阳。BAcc 提升由此而来。【论文实验已支持：Table 3 前后对照+mutant 机制描述】
- 因果链 C（企业单仓的质量门差异）：CropEnterprise 质量门拦截 12.6% vs CropChat 2.1% → 成熟单仓有严格架构边界与本地约定，功能测试覆盖不了评审标准 → 说明纯机械验证在强规范代码库上系统性高估通过率。【论文实验已支持：两基准对照】
- 阅读者推测：harness 敏感性模型相关（k3 掉 8.4pp 而 gpt 系只动 1.1pp）可能与模型输出格式健壮性有关（如 malformed tool call 在某些 harness 被优雅处理）——论文报告了现象但未做机制归因。【阅读者推测】
6.2 相关工作检索与对照
围绕上述因果链，检索外部相似尝试与相近结论（检索时间 2026-11-04，检索词覆盖 cross-repository benchmark / proactive bug finding / foresight / session-mined benchmark / harness sensitivity / test refinement 等）：
| 研究（可核验链接） | 相似尝试 | 相关结论 | 与本组论文的差异与适用边界 | 对根源解释的影响 |
|---|---|---|---|---|
| SWE-Bench Illusion (arXiv:2506.12286) | 诊断 SWE-bench 记忆化：仅凭 issue 描述定位缺陷文件达 76% 准确率 | SWE-bench 高分部分来自记忆而非推理；需要抗污染基准 | 诊断性研究，不建新基准；与本组三篇共同构成"显式需求+可能污染的旧范式需要替代"的背景 | 支持（背景）：三篇各自以不同方式缓解污染——CrossSWE 用 2025-2026 新实例、Foresight-SWE 测"复现已知缺陷反而是问题”、SessionFarmer 用私有/新收割会话 |
| Active-SWE (arXiv:2608.04682) | 无 issue 报告的主动找 bug 基准，1,663 任务 | 最好 agent 仅 20.0%——找已知存在但未指明的 bug 极难 | agent 被告知要找 bug；Foresight-SWE 测实现任务时的自发预见（无搜索指令） | 补充+限定：两者共同说明"未指明的缺陷"是公共短板；但 Active-SWE 的设定不能区分识别与实现瓶颈，Foresight-SWE 的 71 点消融补上了这一环 |
| REAP (arXiv:2604.01527, ASE 2026 Industry) | 从企业生产会话自动构建基准（Meta，Harvest） | 生产衍生基准可行且能揭示公开基准看不到的差异 | 主要从单用户轮次/单会话抽取任务陈述；scope 限单轮对话 | 支持（对照）：SessionFarmer 的 87.6% 需求依赖后续轮次直接量化了 REAP 路线的结构性丢失——这正是 episode 重组的动机证据 |
| DeepSWE (arXiv:2607.07946) | 从零编写 113 任务+手写验证器，反污染 | 审计出 SWE-bench Pro 验证器 8% FP/24% FN；LLM judge 与其验证器分歧仅 1.4% vs 32.4% | 人工编写成本极高；SessionFarmer 测试精炼协议（gpt-6-astra 标签）即参照 DeepSWE | 支持：验证器误判不是小事——直接支撑 SessionFarmer 双闭环的必要性；同时 CrossSWE 用 DeepSWE 分数（75.2%）做塌陷对照 |
| SWE-chat (arXiv:2604.20779) | 野生会话 telemetry 数据集（Stanford，COLM 2026） | 41% 会话近乎全部由 agent 写码（vibe coding 双峰）；agent 代码存活率仅 59% | 数据集而非基准；SessionFarmer 的 CropChat 即从其 v1 快照构建 | 支持（数据基础）：野生会话作为评测素材的丰度与噪声并存——为过滤管线（5,851 会话→3,805 合格）提供现实必要性 |
| Scaffold Effect (arXiv:2607.22585) | 固定模型仅换 harness 的受控研究（3 harness × 2 模型 × 50 任务） | harness 造成 0-8pp 通过率差与 40 倍 token 差；失败指纹跨模型复现（是 scaffold 属性非模型属性） | 任务载体是 Terminal-Bench Pro，非 SWE 任务 | 支持：与 SessionFarmer 的 harness 敏感性发现（k3 8.4pp）量级吻合，互相印证"harness-model 对"应作为评测单元 |
| Model Rankings Reverse (arXiv:2610.00917) | 66 个模型-harness 配置横评 | 模型排名随 harness 反转（Claude 与 GPT 差距摆动 38pp）；厂商原生 harness 未必最优 | 覆盖通用/终端任务三基准 | 支持：把 SessionFarmer 的"必须联合评测模型与 harness"建议从 SWE 推广到更广的 agent 评测 |
| Reality Is the Final Verifier (arXiv:2609.12039) | 两缺口框架：需求缺口+环境缺口统一 reward hacking 与幻觉 | 同模型自评共享写作假设，结构性弱；执行是更强的验证器 | 概念/框架论文，非实验基准 | 补充（机制）：为 Foresight-SWE 的 self-review 副作用与 SessionFarmer 盲求解器设计提供独立理论解释——前者是"共享盲点的自评"，后者恰是引入独立实现作校准 |
| SWE-STEPS (arXiv:2604.03035) | 顺序 PR 链评测（对话式/PRD 式两种模式） | 孤立 PR 评测比状态保持评测虚高最多 20pp；agent 即便解题也增大认知复杂度与技术债 | 限 Python 六仓库；评估累积效应而非单任务质量 | 支持（背景）：孤立任务高估能力——与 Foresight-SWE（时间维）和 SessionFarmer（质量 rubric 维）的动机同源互补 |
在本次检索范围内未发现：与 2^N 联合必要性验证直接相似的其他基准构建机制（最接近的是 DepBench 的依赖破坏修复，但其验证仍单侧）；对"前瞻性缺陷规避"在 2026-10 之前的先行测量工作（Foresight-SWE 自称首提，检索未见反例，但不能断言不存在）。
6.3 综合判断与未决问题
得到多项研究共同支持的机制：
- 单任务显式需求评测系统性高估 agent 能力——SWE-STEPS 的 20pp 虚高、SWE-Bench Illusion 的记忆化、本组三篇各自的分数塌陷（75.2→58.5；60.7→14.8；最强 39.3%）从三个独立方向收敛到同一结论。
- harness 是与模型同阶的评测变量——SessionFarmer（8.4pp）、Scaffold Effect（0-8pp、40 倍 token）、Rankings Reverse（反转）三处独立证据一致。
- 验证器可靠性是基准的一等公民——DeepSWE 的 8%FP/24%FN 审计、SessionFarmer 初始测试 68-81% 条件假阴率、Foresight-SWE 四状态验证，共同说明"测试本身要被测试"。
仍属合理猜测的机制：跨仓一致性失败的上下文管理假说（6.1 链 A 的推测部分）；自评盲点同源假说（有外部理论支持但本组未直接检验）；harness 敏感性的格式健壮性归因。
优势的适用条件：CrossSWE 的必要性验证以 gold patch 为参照——若存在与金标不同但同样满足联合必要性的解，2^N 验证依然成立（它只约束配置行为），但实例规模 171 偏小且双仓为主（165/171），向大型依赖网络外推未知；Foresight-SWE 只收录"人类维护者最终发现并修复"的缺陷，未发现的缺陷不在测量范围，且 FRR 不惩罚过度防御性泛化（作者自陈）；SessionFarmer 的构建管线本身依赖强模型（gpt-5.6-sol/deepseek-v4-flash），在弱模型上能否复现同等质量未知，CropEnterprise 仅 56 任务且不公开。
可能的失效条件：若未来训练数据大规模纳入跨仓联合开发的轨迹，CrossSWE 的难度优势会收窄（正如单仓基准的老化）；proactive 提示已被 Foresight-SWE 证明可部分唤起预见——若对齐训练把"预见自身失败模式"纳入目标，71 点鸿沟可能快速收窄，届时该基准需要向更隐蔽的缺陷演化；SessionFarmer 的会话收割依赖 telemetry 记录习惯（Claude Code 转录格式等），记录生态变化会影响管线存活率。
七、必要知识反推
假设让一个没有背景的人从零完成这组工作，最少需要哪些知识？
领域知识层：
- 真实软件工程的跨仓协作形态（API 演进、依赖迁移、provider-consumer）——不懂这个就提不出"联合必要"这个测点，也不知道该挖什么线索（CrossSWE 阶段一的检索词全部来自这类知识）。
- 软件演化动力学：缺陷如何被引入、存活、暴露与修复（SZZ 算法的 blame 逻辑、“blame 落点≠责任者"的陷阱）——Foresight-SWE 的双 judge 设计直接建立在对 SZZ 失效模式的理解上。
- vibe coding 的实际工作形态：需求如何跨轮涌现、开发者如何用会话驱动 agent、telemetry 的 session-checkpoint 链接语义——SessionFarmer 的 episode 抽象来自对"记录单元≠任务单元"的洞察。
- Django/Pytest 等真实项目的维护节奏（Foresight-SWE 的动机量化）。
方法论知识层：
- 基准构建的因果陷阱清单：污染（记忆化）、验证器误判（假阳/假阴）、金标泄漏到问题陈述、任务可从上下文猜出——三篇的每道关卡都是针对某个具体陷阱设计的。
- 可执行验证思想：把主观性质（联合必要、缺陷存在、需求覆盖）翻译成测试谓词（2^N 配置、四状态、mutant 击破）。
- LLM 流水线的可靠性工程：多数投票一致规则、机械逐字校验挡幻觉、独立校验器、盲化（Test Author 不见 mutant、盲求解器不见金标）。
- 消融与对照设计：单侧派生任务（CrossSWE）、指明/未指明（Foresight-SWE）、三种证据级别的上下文（SessionFarmer）——每个核心主张都配了一个"关掉关键设计看退化多少"的对照。
工程知识层：
- Docker 环境构建与断网验证、多语言安装命令推断（uv/pnpm/corepack/go mod 的锁定安装语义）。
- agent scaffold 生态（mini-swe-agent/Codex/Claude Code/Pi/OpenCode）及统一配置的公平性意义。
- token/成本核算与构建漏斗的量化记账（SessionFarmer 附录的成本表细到组件级）。
知识融合的关键节点：
- SZZ（2005 年的软件考古技术）× LLM-as-judge × 执行验证 = PR 对挖掘管线——老技术提供候选，新技术做语义过滤，执行做最终裁决。
- 组合数学的 2^N 枚举 × Docker 环境共享 = 联合必要性验证——看似暴力，但 N≤5 时只有 ≤32 个配置，工程上完全可行。
- mutant testing（变异测试）× 盲求解器 = 测试闭环——mutant 压假阳、独立实现压假阴，两个方向的负对照互补。
- 会话转录的事件 ID 引用 × 需求条款列表 = 可审计的任务陈述——每条需求都能指着对话说"它从这里来”，这是原开发者审计能达到 100% 陈述接受率的结构基础。
八、论文中可以提取的通用性灵感
灵感一：把"必要性"做成可执行谓词，而不是评审意见。
- 核心思想：一个评测任务是否真的测到目标能力，应当可以被机械验证，而非依赖构造者的自信。
- 论文证据：CrossSWE 的 2^N 配置穷举（全 base 与所有部分补丁必须 FAIL）、Foresight-SWE 的四状态验证（PR2 测试在 PR1 head 失败证明缺陷已存在）。
- 推广场景：(1) 教育测评——验证一道题确实需要目标技能而非可套模板；(2) RL 环境设计——验证奖励确实依赖目标行为而非捷径；(3) 数据合成——验证合成样本的标签确实由目标属性决定；(4) 安全评测——验证攻击路径确实绕过了目标防线而非环境缺陷。
灵感二：用"未来的后果测试"度量现在的隐性能力。
- 核心思想：要测一个系统是否具备当下不可观察的能力（预见性、稳健性），可以锚定到真实演化中后来才暴露的后果上。
- 论文证据：FRR 用中位 88 天后人类修复的缺陷的测试来给当下的实现打分；silent 缺陷更难（12.5% vs 18.5%）说明无信号推理是独立短板。
- 推广场景：(1) 产品决策评测——用后续市场反馈回溯测模型的前瞻判断；(2) 医疗诊断 AI——用随访结果测初诊的完备性；(3) 基础设施变更审查——用线上事故库回溯测变更方案的隐患排查；(4) agent 安全校验——VeriHarm 式"任务成功∧伤害测试"的合取结构。
灵感三：记录单元不是任务单元——评测素材需要边界重构。
- 核心思想：从真实工作流收割数据时，原始记录的边界（会话、工单、提交）与语义单元（一个目标、一次决策）天然错位，先重构边界再谈数据质量。
- 论文证据：87.6% 的任务依赖开场后的补充需求；首消息 vs 全 episode 的需求覆盖 26% vs 75%；会话-checkpoint 链接只证明共现不证明贡献（需要引用具体事件的确认规则）。
- 推广场景：(1) 客服质检——把碎片工单重组为完整服务事件再评质量；(2) 医疗过程评价——按病程而非单次就诊切分；(3) 会议纪要与知识管理——按决策目标而非时间窗归档；(4) 用户研究——按任务目标而非日志会话分析行为。
灵感四：测试本身需要负对照校准——mutant 与独立实现双向夹逼。
- 核心思想：任何自动生成的评判标准都同时存在假阳与假阴，要用"故意的错误样本"和"独立产生的正确样本"从两个方向夹逼校准。
- 论文证据：初始 LLM 测试条件假阴率 68-81%（过拟合金标细节）；mutant 每个破坏一条需求条款作负对照、盲求解器提供异于金标的正样本，双闭环后 BAcc +7.2-8.9pp。
- 推广场景：(1) LLM-as-judge 校准——用植入错误的样本测 judge 的漏判、用多模型正样本测误判；(2) 面试题库——用错误答案变体验证题目区分度；(3) 回归测试集建设——变异测试定级测试强度；(4) 审核规则设计——用历史误判案例双向校验规则。
灵感五：harness 与模型是共轭变量，评测单元应是配对而非单体。
- 核心思想：当系统能力同时取决于核心模型与外围运行时，任何只报单边的排名都系统性误导。
- 论文证据：同模型换 harness Pass@1 摆 1.1-8.4pp 且敏感度因模型而异；22.8% 任务-配置对三次运行判决不一致，单次 Pass@1 掩盖方差。
- 推广场景：(1) 推理引擎选型——模型×量化方案×批处理配置联合评测；(2) 搜索系统——排序模型×召回策略配对调优；(3) 机器人——策略×控制器频率×感知管线联合评测；(4) 报告规范——任何部署决策报告都应附完整运行时规格与多次运行方差。
附录：三篇论文的产出物一览
| 论文 | 产出 | 规模 | 获取 |
|---|---|---|---|
| CrossSWE | CrossSWE-Bench 数据集 | 171 实例/165 仓库/20 域/13 语言 | HuggingFace 公开 |
| Foresight-SWE | 基准+代码+榜单 | 212 实例/35 仓库/4 语言；958 anticipation 测试 | 承诺公开（原文占位符） |
| SessionFarmer | 框架代码+CropChat+构建谱系+rollout 轨迹 | 242 任务/61 仓库/14 语言；CropEnterprise 56 任务（内部） | GitHub+HuggingFace 公开 |
注：核心实验数据已并入第五部分，本附录只汇总可复用资源。三篇论文均声明 AI 辅助仅限代码草稿与语言润色，实验设计与结论由作者核实。