ReProAgent：从问题报告生成缺陷复现测试的工具增强多阶段智能体方法

ReProAgent：从问题报告生成缺陷复现测试的工具增强多阶段智能体方法（中文全译）

翻译说明：本文是 arXiv 论文 ReProAgent: Tool-Augmented Multi-Stage Agentic Generation of Bug Reproduction Tests from Issue Reports（arXiv:2607.09123）的中文全译，由智测团队翻译。原作者：Quanjun Zhang、Yi Zheng、Ye Shang、Weifeng Sun、Haichuan Hu、Chunrong Fang、Zhenyu Chen、Liang Xiao。原文以 CC BY 4.0 许可发布。译文保留原文全部章节、数据与结论；参考文献列表从略。

arXiv:2607.09123v1 [cs.SE] 2026年7月10日

许可：CC BY 4.0

CCS 分类： 软件及其工程；软件测试与调试

ReProAgent：从问题报告生成缺陷复现测试的工具增强多阶段智能体方法

Quanjun Zhang

邮箱：quanjunzhang@njust.edu.cn

单位：南京理工大学计算机科学与工程学院，南京，中国

Yi Zheng

邮箱：201250182@smail.nju.edu.cn

单位：南京大学计算机软件新技术国家重点实验室，南京，中国

Ye Shang

邮箱：yeshang@smail.nju.edu.cn

单位：南京大学计算机软件新技术国家重点实验室，南京，中国

Weifeng Sun

邮箱：wfsun@smu.edu.sg

单位：新加坡管理大学，新加坡

Haichuan Hu

邮箱：huhaichuan2024@gmail.com

单位：南京理工大学计算机科学与工程学院，南京，中国

Chunrong Fang

邮箱：fangchunrong@nju.edu.cn

单位：南京大学计算机软件新技术国家重点实验室，南京，中国

Zhenyu Chen

邮箱：zychen@nju.edu.cn

单位：南京大学计算机软件新技术国家重点实验室，南京，中国

Liang Xiao

邮箱：xiaoliang@mail.njust.edu.cn

单位：南京理工大学计算机科学与工程学院，南京，中国

2026

摘要

复现测试帮助开发者确认所报告的问题，并为问题修复提供可执行反馈，但开源项目中的问题报告很少包含这类测试。近期研究探索了用大语言模型从问题报告生成问题复现测试，但现有方法大体依赖基于提示的流水线：检索文本上下文并生成测试。这限制了它们理解所报告问题在仓库规模代码库中如何表现的能力，也限制了它们灵活组织复现测试构造过程的能力。本文提出 ReProAgent，一种从问题报告生成复现测试的多阶段智能体框架。受开发者手工复现所报告问题的方式启发，ReProAgent 将任务分解为四个智能体阶段：缺陷定位、根因分析、测试规划与测试生成。为支撑这些阶段，ReProAgent 集成了面向任务的工具，用于任务分解与反思、从文本来源与仓库图中检索上下文，以及与执行环境进行运行时交互。在 SWT-bench-lite 与 SWT-bench-verified 上的实验表明，ReProAgent 成功复现了 58.43% 与 70.30% 的问题，优于全部基线，平均每个实例成本为 0.14 美元。例如，在配备 GPT-5-mini 时，ReProAgent 分别以 20.43 与 7.90 个百分点超过使用同一骨干模型的 OpenHands。ReProAgent 还能跨多种骨干大语言模型泛化，并在与现有修复方法集成时提升下游问题修复性能。

关键词： 大语言模型，复现测试生成，智能体，知识图谱

1. 引言

问题报告是在开源平台（例如 GitHub）上提交缺陷的主要机制，但它们很少包含能够复现所报告问题的可执行测试（Gonzalez 等，2017）。缺少这类测试，使开发者难以在修复前确认问题、在修复后验证补丁，从而显著增加软件调试与维护成本（Zhang 等，2023；Zhang 等，2026a）。尽管软件测试已被广泛研究，大多数现有测试生成技术关注覆盖率最大化与缺陷检测等目标（Daka 与 Fraser，2014；Zhang 等，2025）。相比之下，较少有工作关注如何生成忠实复现自然语言所描述的真实世界问题的测试；这类问题往往涉及复杂的执行上下文与隐含假设。

问题复现的重要性在近期工作中日益受到认可，SWT-Bench（Mündler 等，2024）等基准即是例证。与先前聚焦自动程序修复的基准（Jimenez 等，2024）不同，SWT-Bench 专门用于评估模型根据自然语言描述生成复现真实世界问题的测试的能力。每个实例由真实世界的拉取请求构造而成，包含问题描述、对应的修复前代码库以及参考补丁。任务是生成失败转通过（fail-to-pass）测试，即在原始有缺陷版本上失败、但在应用真实修复后通过的测试，从而作为所报告问题的可执行规约。这类复现测试还能进一步促进下游任务，包括但不限于补丁验证与自动修复。这些基准强调了问题复现测试在验证补丁正确性与支撑迭代修复工作流中的关键作用（Yang 等，2024；Wang 等，2025b）。

近来，社区对使用大语言模型（LLM）从问题报告自动生成问题复现测试的兴趣不断增长（Zhang 等，2026b）。代表性方法包括 LIBRO（Kang 等，2023），它利用带有示例问题–测试对的少样本提示；以及 Issue2Test（Nashid 等，2025），它引入元提示以推断项目特定的测试惯例，再基于执行反馈进行迭代精化。AssertFlip（Khatib 等，2025）采用不同策略：先生成通过的测试，再反转断言，其依据是观察到大语言模型更擅长产出有效的通过测试。尽管有这些进展，现有基于提示的方法大体遵循相似的上下文检索与测试生成流水线，从而带来两个根本局限。第一，复现一个问题往往需要理解跨越多个模块与文件的执行路径上的行为，而现有方法主要依赖基于文本的检索，难以捕捉所报告问题所涉及的跨文件行为依赖。第二，生成测试本质上是多步骤任务，需要缺陷定位、根因分析、测试搭建构造与测试验证，而现有方法大体将其视为从检索到的上下文直接生成，没有显式建模中间规划过程。

为应对这些挑战，我们提出 ReProAgent，一种用于问题复现测试生成的多阶段智能体框架。ReProAgent 并不把复现测试生成当作固定的提示流水线，而是将任务分解为多个智能体阶段，并为每个阶段配备面向任务的工具，以进行自主探索与决策。这一设计使 ReProAgent 既能支持仓库规模的问题理解，也能支持复现测试的结构化构造。具体而言，ReProAgent 集成三类工具：用于逐步推理的任务分解与反思工具，用于从文本来源与仓库图收集与问题相关上下文的代码检索工具，以及用于与运行时环境交互的运行时交互工具。在该工具集之上，ReProAgent 将生成过程组织为四个阶段：经由层次化分析的缺陷定位、经由执行路径的根因分析、断言感知的测试规划，以及经由三元评审的测试生成。这一设计受到开发者手工复现所报告问题时通常遵循的工作流启发：他们识别与问题相关的代码，推理失败如何被触发，设计测试搭建与断言，并执行测试以检查所观察到的失败是否与报告相符。

在 SWT-bench-lite 与 SWT-bench-verified 上的实验表明，ReProAgent 成功复现了 58.43% 与 70.30% 的问题，优于全部基线，例如相对 AssertFlip 分别提升 53.76% 与 54.51%。ReProAgent 也能跨多种骨干大语言模型泛化，在 GPT-5-mini、Qwen3-Coder、DeepSeek-V3.2 与 GLM-4.6 上分别达到 64.37%、58.47%、52.11% 与 50.43% 的平均复现率。此外，进一步的讨论表明，ReProAgent 可以与现有修复方法集成，在 SWT-bench-lite 上将 SWE-agent 成功修复的问题数从 143 增加到 153。

概括而言，本文做出如下贡献：

• 多阶段智能体。 我们提出 ReProAgent，一种面向仓库级问题复现测试生成的多阶段智能体框架，将任务分解为缺陷定位、根因分析、测试规划与测试生成。
• 面向任务的工具。 我们设计了一套专用工具集以支撑该框架，包括任务分解与反思工具、上下文检索工具以及运行时交互工具。
• 广泛评估。 我们在两个基准数据集上针对若干最先进基线开展了广泛实验。结果表明 ReProAgent 取得显著提升。消融研究验证了各个组件的有效性，与现有修复框架的集成进一步展示了其实用价值。

2. 背景与动机

2.1. 测试生成

自动测试生成在软件工程中已被广泛研究（Daka 与 Fraser，2014）。现有方法大体可归为三种范式：传统方法、基于学习的方法，以及基于大语言模型的方法。

传统方法。 这些研究主要由启发式搜索与随机测试技术代表（Korel，1990；Meyer 等，2011；Fraser 与 Arcuri，2013；Panichella 等，2015；Panichella 等，2018）。代表性例子包括 EvoSuite（Fraser 与 Arcuri，2011），它使用遗传算法使测试套件向预定义的覆盖目标演化；以及 Randoop（Pacheco 与 Ernst，2007），它通过反馈导向的随机测试生成方法调用序列。这些方法在提高结构覆盖率方面有效，但先前研究表明，高覆盖率并不必然意味着强的缺陷检测能力（Inozemtseva 与 Holmes，2014；Chekam 等，2017）。

基于学习的方法。 这些研究通常把测试生成表述为给定焦点方法上的序列到序列学习问题。例如，AthenaTest（Tufano 等，2020）构造大规模的焦点方法–测试对，并报告了在 Defects4J（Just 等，2014）上的较强性能。A3Test（Alagarsamy 等，2024）通过知识注入与测试有效性验证，进一步改进断言正确性。

基于大语言模型的方法。 近期研究表明，大语言模型能够以有希望的效果生成单元测试，同时也推动了从直接的一次性提示转向更结构化的生成流水线（Yuan 等，2024；Wang 等，2024；Ryan 等，2024；Yin 等，2025；Jain 等，2025；Zhang 等，2027；Cheng 等，2025；Gu 等，2024）。代表性方法从不同角度进一步改进这一范式。ChatUniTest（Chen 等，2024）用自适应的焦点上下文构造与自动验证增强生成；CoverUp（Altmayer Pizzorno 与 Berger，2025）引入覆盖率引导的迭代精化；IntUT（Nan 等，2025）通过显式建模测试意图（如输入、模拟对象与期望结果）来改进生成。

尽管这些方法有效，它们并非为复现测试生成而定制。现有方法通常假定给定测试目标与功能正确的实现，目标是提高覆盖率或验证期望行为。相比之下，我们的工作从有缺陷仓库上的自然语言问题报告出发，目标是生成一个失败测试来复现所报告的问题。这一设定要求理解问题语义、定位相关元素，并判断所产生的失败是否真正对应于所描述的问题，从而使该任务具有相当大的挑战性。

2.2. 缺陷复现测试生成

作为测试生成的一种特殊形式，该任务聚焦于构造测试，以复现软件问题跟踪器中所描述的问题。现有工作可从三个视角讨论：基准与面向任务的方法。

基准。 SWE-bench（Jimenez 等，2024）是一个有代表性的早期基准，用于评估大语言模型解决来自软件仓库的真实世界问题报告的能力。它由从 12 个 Python 仓库收集的真实世界问题构建而成，已成为仓库级软件工程任务广泛使用的试验台。在 SWE-bench 之上，SWT-bench（Mündler 等，2024）专门聚焦缺陷复现测试生成。它包含两个子集，SWT-bench-lite 与 SWT-bench-verified，后者是经过人工整理、正确性已核验的子集。这些基准为在真实仓库设定中研究复现测试生成提供了共同的评估基础。

面向任务的方法。 这些方法主要使用大语言模型，通过提示与基于反馈的精化，把问题描述转化为可执行的复现测试（Wang 等，2025a；Wang 等，2026；Hora 与 Fraser，2026；Ahmed 等，2025a；Fei 等，2026）。例如，LIBRO（Kang 等，2023）是该方向最早的研究之一。它采用带有问题–测试对的少样本提示，随后进行后处理与重排序以提高生成质量，但对仓库特定上下文的利用有限。Issue2Test（Nashid 等，2025）进一步纳入根因分析、面向项目特定测试惯例的元提示，以及带执行反馈的迭代精化。AssertFlip（Khatib 等，2025）探索了一种互补策略。它首先生成捕捉有缺陷行为的通过测试，再翻转断言以得到缺陷复现测试。然而，大多数现有方法仍依赖固定的提示流水线、主要以文本方式构造上下文，或使用没有显式语义评审的执行反馈。尽管 Issue2Test 等方法纳入了根因分析与执行反馈，这些能力大多被组织为预定义的流水线步骤，而不是面向任务的智能体循环。相比之下，ReProAgent 将复现测试生成组织为多阶段智能体过程，显式整合缺陷定位、根因分析、断言感知的测试规划，以及带执行反馈的三元评审。

2.3. 通用软件工程智能体

更新近的软件工程智能体面向广泛的仓库级软件工程任务，例如问题修复（Zhang 等，2026c）。在这些通用工作流中，复现测试生成常常被作为理解问题或验证候选补丁的中间步骤纳入。例如，OpenHands（Wang 等，2025b）采用 ReAct 风格的智能体（Yao 等，2023）来浏览仓库并构造验证测试。SWE-agent（Yang 等，2024）定义了一种问题修复工作流，其中缺陷定位之后是复现测试生成。Agentless（Xia 等，2025）进一步把仓库级修复重构为固定工作流，包括故障定位、补丁生成，以及用回归测试与复现测试进行过滤。这些系统展示了智能体式或基于工作流的推理对仓库级软件工程的价值。然而，由于它们的首要目标是问题修复而非忠实的复现测试生成，复现测试通常被当作辅助产物。因此，它们对系统化地核验所生成测试是否忠实复现所报告缺陷的强调有限。

图 1. SWT-bench 中的 django-15347 问题

2.4. 动机示例

我们使用真实世界问题 django-15347 来说明仓库级问题复现测试生成中的挑战。如图 1 所示，该问题涉及 Django 消息框架中 extra_tags 字段的处理。当一条带有字段 extra_tags="" 的消息被序列化再反序列化后，所得对象错误地把 extra_tags 设为 None。尽管从描述看该问题似乎简单，复现它需要推理空字符串与缺失字段之间的语义差异，并追踪这一差异如何在底层序列化与反序列化逻辑中传播。

代码清单 1： ReProAgent 为 Django-15347 生成的测试

import pytest

from django.conf import settings

from django.contrib.messages.storage.base import Message

from django.contrib.messages.storage.cookie import MessageEncoder, MessageDecoder

def test_reproduce_issue():

    if not settings.configured:

        settings.configure()

    original_message = Message(10, "Here is a message", extra_tags="")

    encoder = MessageEncoder()

    encoded_message = encoder.encode(original_message)

    decoder = MessageDecoder()

    decoded_message = decoder.decode(encoded_message)

    assert original_message.extra_tags == "", "Original extra_tags should be empty string"

    assert decoded_message.extra_tags == "", "Decoded extra_tags should be empty string"

    assert original_message.extra_tags == decoded_message.extra_tags, "extra_tags should be preserved"

该问题具有挑战性，因为问题报告并未显式揭示有缺陷的代码位置或触发缺陷的执行路径。要正确复现它，模型必须识别相关的仓库上下文，把跨函数的序列化与反序列化逻辑联系起来，并构造一条捕捉 "" 与 None 之间语义不匹配的断言。在我们的实验中，LIBRO 与 Issue2Test 都未能为该问题生成正确的复现测试。这一失败凸显了复现测试生成中的两个核心挑战：理解仓库规模的问题，以及构造生成阶段。ReProAgent 旨在通过结合缺陷定位、根因分析、测试规划与测试生成的多阶段过程来应对这些挑战。对于该问题，ReProAgent 成功生成了代码清单 1 所示的复现测试：它创建一个 extra_tags="" 的 Message 对象，对其序列化再反序列化，并断言空字符串应当被保留，而不是被转换成 None。这一例子说明，有效的问题复现测试生成需要仓库探索、语义层面的问题理解以及面向失败的验证，而不仅仅是测试生成本身。

3. 方法

3.1. 概述

如图 2 所示，ReProAgent 被设计为面向仓库级问题复现测试生成的多阶段智能体框架。具体而言，ReProAgent 为大语言模型配备三类工具：任务分解与反思工具、混合上下文检索工具，以及运行时交互工具。这些工具使智能体能够拆解复杂目标、捕获相关代码与依赖、与仓库环境交互，并根据中间反馈精化其决策。

图 2. ReProAgent 框架概览

在该工具集之上，并受开发者手工复现所报告问题的方式启发，ReProAgent 将问题复现测试生成表述为四阶段智能体工作流：经由层次化分析的缺陷定位、经由执行路径的根因分析、断言感知的测试规划，以及经由三元评审的测试生成。在缺陷定位阶段，智能体识别与所报告问题相关的可疑文件、类、函数与代码区域。在根因分析阶段，它分析相关实现、调用路径与依赖，以推断触发缺陷的执行路径及底层原因。在测试规划阶段，它检查现有测试与项目特定的测试惯例，以导出适当的复现策略，包括搭建、调用模式与期望的失败条件。在测试生成阶段，它生成候选复现测试，在基于 Docker 的沙箱中执行它们，并根据执行反馈与三元评审迭代精化。

3.2. 智能体工具集构造

在仓库级代码库上生成问题复现测试本质上具有挑战性，因为它要求理解复杂实现、跨文件依赖以及动态执行行为。与大体遵循固定提示流水线的先前方法不同，ReProAgent 采用多阶段智能体框架，在整个过程中进行迭代探索与决策。为支撑该框架，我们在每个阶段为智能体配备多维工具集，使其能够分解任务、检索相关上下文、与仓库环境交互，并根据中间反馈精化决策。

如表 1 所示，工具集由三类组成：任务分解与反思工具、混合上下文检索工具，以及运行时交互工具。这些工具在流水线中提供互补支持。任务分解与反思工具帮助智能体拆解复杂目标并修订中间推理。上下文检索工具使智能体能够检视相关代码，并识别模块、类与函数之间的依赖。运行时交互工具使智能体能够观察执行行为，并在实际仓库环境中验证假设。

表 1. ReProAgent 中配备的工具集

#### 3.2.1. 任务分解与反思工具

问题复现测试生成需要多阶段推理、长程规划与迭代适应。与遵循固定流水线的先前方法不同，ReProAgent 采用多阶段智能体框架，其中每个阶段执行细粒度任务分解，并根据中间结果与环境反馈动态调整其动作。为支撑这一过程，我们纳入 sequential-thinking（Anthropic，2025b；Anthropic，2025a）作为显式的任务分解与反思工具。它允许智能体把每个阶段拆成可管理的推理步骤，在必要时修订较早的决策，并随着新证据出现而调整策略。

在 ReProAgent 中，sequential-thinking 充当结构化分解与动态反思的高层控制器。在每一步，智能体维护一条带有步骤索引与估计总步数的显式推理轨迹，同时使用显式控制信号来决定是继续、修订先前想法，还是分支到替代推理路径。上下文检索、执行与测试生成等具体动作被委托给其他工具，其输出被反馈到后续推理步骤。这一设计形成思考–行动–观察–修订的闭环，提高了长程推理的稳定性与可解释性。

#### 3.2.2. 混合上下文检索工具

ReProAgent 提供两种互补的检索机制：基于命令行关键词的检索，以及基于知识图谱的依赖检索。

基于命令行关键词的检索。 ReProAgent 提供类 Linux 的检索工具，模仿开发者从命令行探索仓库的方式。这些工具通过类似于 ls、find、grep 与 glob 的操作，支持仓库导航、文件定位、关键词查找与行级源码检视。它们使智能体能够快速建立对仓库布局、模块组织以及与所报告问题相关的实现细节的理解。为避免浪费大语言模型的上下文窗口，过长的输出会被截断或摘要。此外，潜在危险的命令在执行前会被过滤，并且所有工具调用都在基于 Docker 的沙箱内执行，以确保安全。

基于知识图谱的依赖检索。 为支持更深的语义理解与跨文件推理，ReProAgent 还纳入代码知识图谱。该图通过用 Tree-sitter（Tree-sitter，2026）递归解析仓库来构造，从源文件中抽取类、函数定义与函数调用等程序实体。这些实体被表示为节点，而文件隶属、类引用与函数调用等关系被编码为边，形成跨文件的语义依赖网络。在该图之上，ReProAgent 提供面向依赖的检索工具，例如实体查找、类结构检视、跨文件关系查询与导入分析。与基于关键词的检索不同，这些工具直接利用语义依赖并返回结构上相关的上下文，从而提高智能体恢复调用链、依赖路径以及行为上相关的代码区域的能力。

#### 3.2.3. 运行时交互工具

上下文检索工具聚焦静态仓库信息，而运行时交互工具则暴露仓库在执行期间的动态行为。其目的是使智能体能够验证假设、检视运行时行为，并根据具体的执行反馈修订决策。

为支撑这一过程，ReProAgent 提供两类运行时交互工具。第一类是命令执行工具，允许智能体在基于 Docker 的沙箱内运行仓库级命令。它支持环境检视、依赖检查、构建执行与测试调用。第二类是交互式执行工具，允许智能体在沙箱化的仓库内直接执行 Python 片段。该工具能够对函数行为、依赖交互以及具体输入下的数据流变化进行细粒度检视。

3.3. 经由层次化分析的缺陷定位

给定问题报告与目标仓库，该模块试图识别一组经过排序的可疑程序元素，它们很可能与所报告的失败相关。为此，我们设计了一种多阶段层次化分析过程，把搜索空间从可疑文件逐步收窄到细粒度的代码行。该过程的核心是一种思维链风格的推理过程，智能体基于从问题报告与仓库上下文收集的证据，逐步形成、精化并验证定位假设。

从问题报告出发，ReProAgent 首先通过抽取关键症状、错误消息以及被引用的实体（例如来自栈追踪的文件名、类名与方法名）来构造初始查询。在该初始查询引导下，ReProAgent 通过句法与语义检索机制收集上下文证据。具体而言，它使用基于命令行的文本检索，用异常名、函数名、日志片段、行号与配置参数等关键词搜索与问题相关的文件。与此并行，它执行基于知识图谱的依赖检索，分析跨文件的调用链与模块间依赖结构，从而推断故障可能如何在系统中传播。在识别出与问题相关联的可疑文件之后，ReProAgent 使用文件读取工具阅读相关实现以理解问题。检索到的上下文随后通过推理与检索循环被迭代精化：关于潜在根因的中间假设被生成，并用于为后续检索步骤重新表述查询。

一旦候选文件被识别出来，ReProAgent 在每个文件内执行层次化定位。它首先根据函数或类与问题的语义相关性，以及它们与先前已识别元素的结构邻近性（例如通过调用关系或依赖链接相连的元素）对其进行排序。随后，它通过检查代码片段、与执行相关的语句以及上下文特定线索（包括条件、错误处理逻辑与数据流使用），把搜索进一步精化到行级。这种由粗到细的定位策略能够在保持定位精度的同时，高效探索大型代码库。

为进一步鼓励显式推理，ReProAgent 要求智能体为每个被选中的可疑区域提供自然语言理由，并附带置信度分数。这些理由外化了智能体的推理轨迹，使定位过程更可解释，而置信度分数则为在下游阶段对候选进行优先级排序提供了额外信号。最后，该模块输出一份经过排序的可疑位置列表，每一项都附有置信度估计与支持性理由。这些结果随后被传递给下游的根因分析与测试生成阶段。

3.4. 经由执行路径的根因分析

缺陷定位之后，ReProAgent 执行根因分析，以推断所报告问题背后的失败机制。给定上一阶段的可疑位置与问题描述，该阶段追踪故障如何沿执行路径被触发并传播，并为下游的问题复现测试生成产出一份结构化的根因分析报告。

ReProAgent 首先结合可疑位置分析问题报告，以识别所报告的失败症状，例如异常类型、错误消息、不正确的返回值以及异常的状态变化。基于这些症状，智能体随后通过增量检索相关程序上下文（包括依赖函数、相关类以及其他关键代码区域）来执行路径分析，并重建从入口点到失败点的执行路径。在重建执行路径之后，智能体识别底层逻辑缺陷。这一步聚焦于确定代码逻辑中哪里出错，以及它为何导致问题报告中所描述的非预期行为。通过比较问题报告所隐含的预期行为与代码所表现出的实际行为，智能体识别常见缺陷模式，例如不正确的条件检查与不当的边界处理。

智能体随后基于症状解释、执行路径分析与逻辑缺陷检视，形成根因假设。该假设为失败机制提供抽象解释：它不仅识别缺陷位于何处，也解释该缺陷为何产生所报告的症状。为提高可靠性，ReProAgent 通过迭代的推理–验证–精化循环进一步精化该假设。在此过程中，智能体持续收集支持性证据，包括相关代码片段、完整方法实现、调用依赖与模块关系，并修订假设，直到它能够一致地解释所观察到的症状与所检索到的程序上下文。最后，如图 3 所示，ReProAgent 输出一份包含五个组成部分的结构化根因分析报告：（1）根因摘要，对底层故障机制的简明描述；（2）错误类别，缺陷类型，例如逻辑错误、边界处理缺陷或 API 误用；（3）执行路径，从入口点到失败点的关键执行步骤，并标注对应的代码位置与行为；（4）触发条件，复现失败所需的环境约束；（5）置信度分数，对所推断根因可靠性的度量。

图 3. Django-15347 的根因分析结果

3.5. 断言感知的测试规划

根因分析之后，ReProAgent 执行测试规划，为下游测试生成导出结构化指导。给定根因分析报告，该阶段识别触发条件、复现搭建与断言，以复现所报告的问题，从而减少直接测试生成中经常出现的结构错误与信息遗漏。具体而言，该阶段由三个相连的步骤组成：触发条件分析、复现搭建构造，以及断言推导。

在触发条件分析中，ReProAgent 首先解析根因分析报告，以抽取关键信息，例如根因摘要、问题类别与执行路径。基于这些信息，它推导出暴露该问题所需的最小触发条件与关键约束。在复现搭建构造中，ReProAgent 确定复现所需的前置条件与环境约束，例如项目初始化过程、依赖加载机制、必要的上下文状态以及版本特定要求。它进一步识别足以复现该问题的最小测试输入、参数组合与边界值，并使用检索与运行时交互工具，使规划立足于实际仓库上下文。在断言推导中，ReProAgent 确定应当如何验证被复现的缺陷。它分析刻画问题行为的可观察失败信号与运行时输出，例如异常消息、栈追踪、不正确的返回值与异常的内部状态。基于这些观察，ReProAgent 规定有缺陷执行与预期执行之间的期望行为差异，并确定应当编码进复现测试的断言。最后，ReProAgent 输出一份包含三个组成部分的结构化测试计划：（1）环境约束，规定复现所需的搭建与初始状态；（2）测试输入构造，定义触发缺陷所需的最小输入与关键参数配置；（3）期望断言，描述有缺陷行为与预期行为之间的偏差，并规定应当如何对它们进行断言。

3.6. 经由三元评审的测试生成

测试规划之后，ReProAgent 进入测试生成阶段。该阶段以先前阶段产生的中间产物为输入，包括问题描述、可疑位置、根因分析报告与测试计划，并输出一份可执行的问题复现测试及其执行结果。其目标是把结构化分析结果转化为可运行的测试，并通过迭代执行与评审，确保所生成的测试能够可靠地复现所报告的问题。

为生成复现测试，ReProAgent 把问题描述、可疑位置、根因分析报告与测试计划组装成给智能体的统一提示。在这些输入的引导下，智能体构造单个复现测试：它针对相关的可疑代码区域，实例化问题显现所需的搭建与输入条件，并针对期望的有缺陷行为编码断言。所生成的测试被要求暴露实际的问题行为，也就是说，它应当在有缺陷版本上失败，并在问题被修复后通过。一旦生成候选测试，ReProAgent 就把它写入沙箱化的仓库，并在基于 Docker 的环境中执行。执行输出随后被用作后续精化的反馈。如果测试通过，则它未能复现该问题，智能体必须根据所观察到的执行反馈修订测试。然而，失败的测试并不会被立即接受为有效复现。相反，ReProAgent 进一步检查所观察到的失败在语义上是否与所报告的问题一致。只有其失败被确认与问题描述相匹配的测试，才被接受为有效复现测试；否则，智能体通过进一步迭代继续精化测试，直到评审成功或达到最大迭代预算。

图 4. Django-15347 的评审结果

为判断失败测试是否真正复现了所报告的问题，我们引入一种在问题报告、所生成测试与执行结果之上的三元评审过程，如图 4 所示。该过程评估：（1）所生成测试在其目标功能、触发条件与断言上是否与问题报告语义对齐；（2）所观察到的失败是否与测试逻辑一致，而不是由语法错误、缺失依赖或环境配置错误等偶然因素引起；（3）执行结果在错误消息、异常类型或整体失败模式上是否与问题报告匹配。如果所生成的测试通过评审，它就被保留为有效的问题复现测试，可供开发者用于检视、验证与回归检查。否则，智能体使用评审结果，连同先前的执行反馈与中间分析产物，进一步精化测试，包括其前置条件、输入构造与断言，然后重新执行修订后的版本。这样，ReProAgent 形成基于反馈驱动迭代与三元评审的闭环框架，使智能体能够逐步收敛到可靠复现目标问题的高质量测试。

4. 实验设置

4.1. 研究问题

为评估 ReProAgent 的有效性，我们开展实验以回答下列研究问题（RQ）：

• RQ1： 与最先进方法相比，ReProAgent 表现如何？
• RQ2： 不同大语言模型对 ReProAgent 泛化能力的影响是什么？
• RQ3： ReProAgent 中不同组件的贡献是什么？

4.2. 数据集

我们在 SWT-Bench（Mündler 等，2024）的两个子集上评估 ReProAgent：SWT-Bench-Lite 与 SWT-Bench-Verified。SWT-Bench 是一个大规模基准，用于评估模型与代码智能体为从 GitHub 仓库收集的真实世界问题生成可复现测试的能力。SWT-Bench-Verified 是经过整理的子集，包含人工核验的任务，其描述清晰、复现标准规定明确，提供更高置信度的评估集。SWT-Bench-Lite 是更小、更轻量的子集，面向快速迭代与高效基准测试。两个子集都已被近期关于真实世界问题可复现测试生成的工作广泛采用（Ahmed 等，2025b；Nashid 等，2025；Khatib 等，2025；Kang 等，2023）。

4.3. 基线

我们将 ReProAgent 与来自两类的若干代表性基线进行比较。

第一，我们纳入面向任务的复现测试生成方法。Zero-Shot-Plus（Mündler 等，2024）是 SWT-Bench 引入的零样本提示基线。LIBRO（Kang 等，2023）采用带有问题–测试对的少样本提示，随后进行后处理与重排序，以选择高质量候选测试。Issue2Test（Nashid 等，2025）采用多阶段流水线，包含根因分析、面向项目特定测试惯例的元提示，以及带执行反馈的迭代精化。Otter（Ahmed 等，2025b）执行缺陷定位，并使用基于反思的规划来迭代生成与精化测试。Otter++（Ahmed 等，2025b）用异构提示采样与集成式选择扩展 Otter。e-Otter 与 e-Otter++（Ahmed 等，2026）进一步纳入由执行反馈引导的生成与选择。AssertFlip（Khatib 等，2025）首先生成捕捉有缺陷行为的通过测试，再反转其断言以得到缺陷复现测试。

第二，我们纳入通用软件工程智能体。AutoCodeRover（Zhang 等，2024）是基于大语言模型的问题修复框架，在 SWT-Bench 中通过修改后的指令被适配为产出缺陷复现测试。SWE-Agent（Yang 等，2024）、SWE-Agent+（Mündler 等，2024）、Aider（Aider-AI，2026）与 OpenHands（Wang 等，2025b）是可被适配来生成复现测试的编码智能体。Amazon Q（Amazon Web Services，2026）是基于大语言模型的开发助手，我们使用其在 SWT-Bench 排行榜上公开报告的结果。

4.4. 评估指标

遵循先前复现测试生成工作中广泛采用的评估协议（Mündler 等，2024），我们使用失败转通过率（Fail-to-Pass Rate，FP Rate）评估 ReProAgent 的有效性。在每个问题生成一个测试的设定下，FP 率衡量既复现所报告问题、又验证其对应补丁的测试所占比例，即在补丁前（有缺陷）代码版本上失败、并在应用解决问题的补丁之后通过的测试。该指标直接刻画所生成测试是否正确刻画了有缺陷行为，并在修复之后充当可靠测试。

4.5. 实现细节

为实现 ReProAgent，我们采用 GPT-5-mini（OpenAI，2025）作为主要骨干模型。GPT-5 mini 属于 OpenAI 的 GPT-5 模型家族，该家族旨在支持涉及长上下文推理与工具交互的编码与智能体任务。这使它适合我们的多阶段工作流：智能体必须定位缺陷、分析执行路径、规划断言，并根据运行时反馈迭代精化复现测试。我们还用其他先进的、具备代码能力的大语言模型实例化 ReProAgent，包括 DeepSeek-V3.2、GLM-4.6 与 Qwen3-Coder，以评估所提出的框架是否能跨不同骨干模型泛化。整体框架构建于 LangChain（LangChain，2026a）与 LangGraph（LangChain，2026b）之上，二者用于编排多阶段推理与工具交互。我们将大语言模型配置为 temperature = 0.7、top_p = 0.8；对于开源骨干，在这些解码参数被支持时，我们额外设置 top_k = 20 与 repetition_penalty = 1.05。为控制计算成本，我们强制有界的交互预算。每个阶段最多允许 50 次大语言模型调用。在纳入反馈驱动精化与自动验证的测试生成阶段，反馈迭代的最大次数限制为 20。所有实验在运行 Ubuntu 22.04 的服务器上进行。对于知识图谱构造，我们使用 Neo4j（Neo4j, Inc.，2026），它能够高效表示与查询代码结构及依赖。

5. 评估与结果

5.1. RQ1：与最先进方法的比较

实验设计。 我们在两个广泛使用的基准 SWT-bench-lite 与 SWT-bench-verified 上评估 ReProAgent 的有效性。遵循先前的 SWT-bench 研究，我们采用 FP 率作为主要评估指标，它衡量所生成测试是否在有缺陷版本上失败、并在已打补丁版本上通过。我们将 ReProAgent 与代表性的基于提示和基于智能体的基线进行比较，包括 LIBRO、Issue2Test、Otter、Otter++、OpenHands 与 AssertFlip，以及在 SWT-bench 排行榜上有公开报告结果的其他系统。除非另有说明，基线结果取自相应原始论文或公开的 SWT-bench 排行榜。为控制骨干模型效应，我们进一步在 GPT-5-mini 下与最强基线 OpenHands 进行同骨干比较。具体而言，在 SWT-bench-lite 上，我们使用推荐的 SWT-bench 配置（SWT-bench Developers，2026）复现 OpenHands；在 SWT-bench-verified 上，我们使用 SWT-bench 排行榜报告的结果。

表 2. ReProAgent 与基线在 SWT-bench-verified 上的比较

表 3. ReProAgent 与基线在 SWT-bench-lite 上的比较

实验结果。 表 2 与表 3 给出总体比较结果。ReProAgent 在两个基准上都取得最佳 FP 率，在 SWT-bench-lite 上达到 58.43%，在 SWT-bench-verified 上达到 70.30%。在 SWT-bench-lite 上，该结果显著高于所有被比较的基线，其中最强基线达到 38.0%。在 SWT-bench-verified 上，ReProAgent 也优于最佳基线结果 62.4%。

与近期的问题到测试生成方法相比，ReProAgent 的优势也是一致的。例如，它相对 Issue2Test 在 SWT-bench-lite 上提升 92.01%、在 SWT-bench-verified 上提升 110.92%，相对 Otter++ 分别提升 119.08% 与 118.32%。与先生成通过测试再反转断言的 AssertFlip 相比，ReProAgent 在两个数据集上仍取得明显提升。总体而言，这些结果表明，所提出的多阶段框架比从检索到的上下文直接生成测试、或主要依赖事后精化更为有效。

跨仓库的有效性。 表 4 与表 5 给出不同项目上的结果。ReProAgent 在多样化的项目集合上表现稳定，而不是把增益集中在很小一部分实例上。在 SWT-bench-lite 上，它在若干主要仓库上取得高于 50% 的复现率，包括 django（64.6%）、sympy（63.4%）与 scikit-learn（68.4%）。在 SWT-bench-verified 上，同一趋势保持，在 django（74.1%）、sympy（74.0%）、matplotlib（71.9%）、scikit-learn（91.7%）与 astropy（75.0%）上结果尤其强。结果也表明，性能在各仓库之间并不均匀。某些较低的比率应谨慎解释，因为它们是由极少实例计算得到的。例如，flask 在 SWT-Bench-Lite 中只有一个实例，Issue2Test 在其上同样得到 0%。

重叠分析。 为进一步理解 ReProAgent 的增益是否主要来自更可靠地解决同样容易的实例，我们分析 ReProAgent 与代表性基线之间成功案例的重叠。图 5 给出 ReProAgent、AssertFlip、OpenHands、LIBRO 与 Issue2Test 在 SWT-bench-lite 上的重叠分析。结果表明，ReProAgent 独有地复现了 36 个四个基线都未能复现的问题。这表明 ReProAgent 的改进并不限于更可靠地解决已经容易的案例；相反，它扩大了能够生成有效复现测试的问题集合。

对 RQ1 的回答： ReProAgent 在 SWT-bench-lite 与 SWT-bench-verified 上都表现最佳，分别达到 58.43% 与 70.30%，并且在 SWT-bench-lite 上独有地复现了四个代表性基线都未能复现的 36 个问题。

表 4. SWT-bench-lite 上不同项目的结果分布

表 5. SWT-bench-verified 上不同项目的结果分布

图 5. 相对基线的重叠分析

5.2. RQ2：跨不同大语言模型的泛化能力

实验设计。 为评估 ReProAgent 是否能跨不同骨干模型泛化，我们进一步用三个开源大语言模型实现 ReProAgent：DeepSeek-V3.2（DeepSeek-AI，2024）、GLM-4.6（Team，2025）与 Qwen3-Coder。这些模型在规模与训练侧重上有所不同，但都对代码生成与智能体推理提供强支持。我们在 SWT-bench-lite 与 SWT-bench-verified 上用每个骨干运行同一条 ReProAgent 流水线，并以 FP 率作为评估指标。

表 6. 不同骨干大语言模型上的性能

实验结果。 表 6 报告了不同大语言模型骨干上的结果。总体而言，ReProAgent 在全部四个模型上都取得较强性能，在 GPT-5-mini、Qwen3-Coder、DeepSeek-V3.2 与 GLM-4.6 上分别获得 64.37%、58.47%、52.11% 与 50.43% 的平均 FP 率。其中，GPT-5-mini 表现最佳，在 SWT-bench-lite 上达到 58.43%，在 SWT-bench-verified 上达到 70.30%。Qwen3-Coder 以 56.88% 与 60.05% 位列第二，而 DeepSeek-V3.2 与 GLM-4.6 在两个基准上也取得有竞争力的结果。

这些结果表明，ReProAgent 的有效性并不依赖于单一骨干模型。相反，所提出的框架在具有不同模型规模与训练特征的大语言模型上保持有效。特别是，即使较弱的骨干仍能取得有竞争力的 FP 率，表明 ReProAgent 的增益主要来自框架设计，而不是仅来自某个特定模型。

GPT-5-mini 更强的性能很可能源于其更强的编码、长上下文推理与工具使用能力，这些能力更好地支持仓库理解、结构化推理以及由执行引导的测试生成。尽管如此，总体趋势表明 ReProAgent 能够很好地迁移到不同的先进大语言模型。

对 RQ2 的回答： ReProAgent 在不同骨干大语言模型上泛化良好，在 GPT-5-mini、Qwen3-Coder、DeepSeek-V3.2 与 GLM-4.6 上分别达到 64.37%、58.47%、52.11% 与 50.43% 的平均 FP 率。在四个骨干上，总体平均 FP 率达到 56.35%。

5.3. RQ3：不同组件的贡献

实验设计。 为考察 ReProAgent 中每个阶段的贡献，我们通过从完整框架中依次移除每个阶段来开展消融研究。由于用 GPT-5-mini 做完整消融会需要高得多的推理成本，我们使用 RQ2 中最强的开源骨干 Qwen3-Coder 进行该研究。具体而言，我们评估四个核心阶段，包括层次化缺陷定位、基于执行路径的根因分析、测试生成规划，以及带三元评审的反馈迭代。所得变体在 SWT-bench-lite 与 SWT-bench-verified 上用 FP 率评估。

表 7. 使用 Qwen3-Coder 时 ReProAgent 不同阶段的影响

实验结果。 表 7 给出消融结果。移除任一阶段都会导致两个基准上的 FP 率下降，表明所有组件都对 ReProAgent 的有效性有贡献。其中，带三元评审的反馈迭代影响最大：移除该阶段使 FP 率在 SWT-bench-lite 上从 56.88% 急剧下降到 18.84%，在 SWT-bench-verified 上从 60.05% 下降到 22.86%。这一结果凸显了基于执行的精化与评审在纠正无效测试、并确保所生成测试忠实捕捉预期的失败转通过行为方面的重要性。另外三个阶段也提供一致的收益。移除层次化缺陷定位使 FP 率在 SWT-bench-lite 上降至 47.83%、在 SWT-bench-verified 上降至 55.89%，表明细粒度定位有助于识别与所报告问题更相关的代码区域。移除基于执行路径的根因分析使 FP 率分别降至 53.26% 与 56.58%，表明对故障传播的结构化推理改进了下游测试构造。移除测试生成规划进一步使 FP 率降至 52.17% 与 57.74%，表明即使在先前分析阶段之后，显式规划仍能提供有用指导。

由于缺陷定位在为后续阶段提供可疑代码方面起着重要作用，我们进一步分析其正确性如何影响最终的失败转通过性能。表 8 按照 ReProAgent 是否正确定位有缺陷代码对实例分组。结果表明，正确定位显著提高最终 FP 率，在 SWT-Bench-Lite 上从 50.7% 提高到 67.8%，在 SWT-Bench-Verified 上从 60.8% 提高到 85.3%。这证实定位质量是生成有效复现测试的重要因素。与此同时，定位不正确的案例仍取得不可忽略的 FP 率，表明后续阶段可以通过额外的上下文检索与执行路径推理部分恢复。这些结果也表明，ReProAgent 在未来工作中可以进一步受益于更强的定位模块。

表 8. ReProAgent 对定位正确性的敏感性

对 RQ3 的回答： 四个阶段都对 ReProAgent 有正向贡献，例如带三元评审的反馈迭代影响最大。移除该阶段使 FP 率在 SWT-bench-lite 上从 56.88% 下降到 18.84%，在 SWT-bench-verified 上从 60.05% 下降到 22.86%。

6. 讨论

6.1. 问题修复中的复现测试

问题复现测试对自动修复有价值，因为它们是评估所生成补丁是否真正正确的关键判据，并支持由反馈驱动的补丁精化。受这一角色启发，我们进一步从两个视角研究 ReProAgent 生成的问题复现测试如何支持下游修复：改进现有修复框架，以及使能由反馈驱动的迭代修复。

对现有修复框架的收益。 我们将 ReProAgent 集成到两个代表性修复框架中：基于智能体的 SWE-agent（Yang 等，2024），以及基于工作流的 Agentless（Xia 等，2025）。对于 SWE-agent，我们把来自 ReProAgent 的测试注入其提示。对于 Agentless，我们在补丁过滤阶段使用来自 ReProAgent 的测试，与其原有的回归测试一并使用。考虑到运行完整修复流水线的成本，我们使用 RQ2 中的开源骨干 Qwen3-Coder 进行该分析。

表 9. 复现测试对现有修复工作的影响

如表 9 所示，所生成的复现测试在两个框架上都一致地改进了修复性能。在 SWE-bench-lite 上，成功修复的问题数对 SWE-agent 从 143 增加到 153，对 Agentless 从 93 增加到 100。在 SWE-bench-verified 上，相应数字分别从 317 上升到 327、从 188 上升到 201。这些改进表明，复现测试提供了有用信号，有助于使所生成补丁更好地与问题语义对齐，并为补丁选择提供更强的行为判据。

用复现测试进行端到端修复的可行性。 我们进一步研究复现测试是否可以在端到端修复循环中用作反馈信号。为此，我们构造一条简单的迭代修复流水线：模型首先识别可疑文件，然后生成候选补丁，对照所生成的复现测试进行验证，若验证失败则再进行一轮修复迭代，最多 5 次迭代。

表 10. 复现测试对迭代修复的影响

表 10 表明，复现测试反馈在两个基准上都一致地增加了成功修复结果的数量。在 SWE-bench-lite 上，成功案例数从 99 增加到 120。在 SWE-bench-verified 上，相应数字从 194 上升到 226。合计而言，两个基准上的成功案例数从 293 增加到 346。这些结果表明，复现测试不仅可以充当最终验证器，也可以充当修复过程中可操作的执行时反馈。尽管当前流水线有意保持简单，所观察到的增益凸显了把修复与复现测试反馈耦合起来的实际前景。

小结： ReProAgent 生成的问题复现测试一致地提高了现有修复框架的有效性，并在迭代修复中充当可操作的反馈，使成功案例数在 SWE-bench-lite 上从 99 增加到 120，在 SWE-bench-verified 上从 194 增加到 226。

6.2. 成本分析

由于 ReProAgent 是带有迭代工具使用的智能体框架，我们进一步在主要的 GPT-5-mini 设定下分析其推理成本。作为比较，若原始论文中有此类信息，我们收集代表性基线所报告的平均每实例成本。如表 11 所示，ReProAgent 平均每个实例成本为 0.14 美元。这略高于使用 GPT-5-mini 的 OpenHands，但低于若干基于 GPT-4o 或 Claude 的复现测试生成基线。由于不同方法使用不同的骨干模型与定价方案，我们并不把货币成本用作直接的优越性主张。相反，该结果表明，在同一 GPT-5-mini 骨干下提供显著更高 FP 率的同时，ReProAgent 在实践中仍然可负担。我们还考察成功案例所使用的反馈迭代次数。在所有成功复现的实例中，平均反馈迭代次数为 1.29，并且 90% 的成功案例在五次迭代内完成。这一观察表明，未来工作可以探索自适应迭代预算或早停策略，以在保持复现有效性的同时进一步降低成本。

表 11. 平均每实例成本

小结： ReProAgent 在实践中仍然可负担，平均每个实例成本为 0.14 美元。大多数成功案例只需要少量反馈迭代，平均为 1.29 次迭代，90% 在五次迭代内完成。

6.3. 效度威胁

内部效度。 内部效度关注可能影响评估公平性与一致性的潜在偏差。第一，大语言模型推理是随机的，因此重复运行可能产生不同结果。第二，骨干大语言模型可能因推理与编码能力的差异而对相同提示作出不同响应。为缓解这些威胁，我们使用标准化的 Docker 环境、统一提示、一致的工具设置，并在同一框架下跨多个骨干大语言模型评估 ReProAgent。

外部效度。 外部效度关注我们的发现是否能泛化到当前设定之外。第一，我们的实验限于 SWT-bench 数据集中的 Python 仓库，因此结果未必能泛化到其他编程语言。然而，ReProAgent 的高层工作流与语言无关，其图构造组件可以使用现有工具扩展（例如支持 19 种语言的 CodeGraphContext（Contributors，2026））。第二，基准问题可能并不能完全代表真实世界工业项目的复杂性与多样性。为降低这些威胁，我们在覆盖多个仓库与多种大语言模型的两个广泛使用的基准子集上评估 ReProAgent。

7. 结论

本文提出 ReProAgent，一种用于问题复现测试生成的多阶段智能体框架。通过整合任务分解与反思、混合代码检索以及运行时交互，ReProAgent 将生成过程组织为四个阶段：缺陷定位、根因分析、测试规划与测试生成。在 SWT-bench-lite 与 SWT-bench-verified 上的实验表明，ReProAgent 一致地优于现有基线，复现率分别达到 58.43% 与 70.30%。ReProAgent 也能跨多种大语言模型骨干泛化，并改进下游问题修复。例如，在 SWT-bench-lite 上与 SWE-agent 集成时，它使成功修复的问题数从 143 增加到 153。这些结果展示了结构化多阶段智能体设计对仓库级问题复现测试生成的有效性。

源文本止于第 7 节结论。参考文献列表从略，未另作补写。图 1 至图 5 在源文抽取中仅有图题，图中像素内容未包含在源文件中，译文仅保留图题，未编造图内细节。

署名与许可

本文翻译自 arXiv 论文 ReProAgent: Tool-Augmented Multi-Stage Agentic Generation of Bug Reproduction Tests from Issue Reports，原文以 CC BY 4.0 许可发布。

译者： 智测团队

原文链接： https://arxiv.org/abs/2607.09123

许可： CC BY 4.0