Each language version is independently generated for its own context, not a direct translation.
这篇论文介绍了一个名为 Echo 的 AI 智能体，它的核心任务是帮程序员“重现”软件里的 Bug。
想象一下，你是一家软件公司的“侦探”。用户报告说：“我的软件有个地方不对劲！”（这就是 Bug 报告）。但是，用户往往描述得很模糊，比如“点击按钮没反应”，却不会告诉你具体是哪行代码出了问题，也没法直接给你看那个坏掉的场景。
要修好这个 Bug，程序员必须先重现它：写一段测试代码，让软件在运行这段代码时，完美地表现出那个错误。如果写不出来，或者写错了，程序员就不知道该怎么修。
以前，写这段“重现代码”非常耗时，就像让侦探在茫茫大海里找一根特定的针。Echo 就是为了解决这个问题而生的超级助手。
Echo 是怎么工作的？（用生活化的比喻）
Echo 的工作流程可以比作一个**“侦探破案 + 模拟实验”**的过程，它主要做了四件大事：
1. 像“读心术”一样精准找线索（图增强检索）
- 以前的做法：侦探（AI）拿到线索（Bug 描述），就在图书馆（代码库）里随便翻翻，或者只找几个关键词。结果往往找了一堆不相关的书，或者漏掉了关键证据。
- Echo 的做法：Echo 手里有一张**“代码关系地图”**（代码图）。它不仅能看到文件，还能看到文件之间谁调用谁、谁依赖谁。
- 比喻：就像侦探不仅知道“嫌疑人住在 A 街”，还知道"A 街的人经常去 B 咖啡馆，而 B 咖啡馆的老板是 C 的亲戚”。Echo 利用这张地图，自动优化它的“搜索提问”，精准锁定最相关的几行代码和测试案例，而不是大海捞针。
2. 自动写“剧本”并“排练”（自动生成与执行）
- 以前的做法：AI 写好了测试代码，但往往不知道怎么运行。就像演员背好了台词，但不知道剧场在哪、灯光怎么开，导致无法上台演出。
- Echo 的做法：Echo 不仅写代码，还自动去查说明书（README、配置文件），找出运行这个项目的正确命令。
- 比喻：它像个全能导演，写完剧本后，自己跑去把舞台搭好、灯光调好，然后真的让演员（测试代码）上台演一遍。如果演失败了（报错），它就把“演出录像”（错误日志）拿回来分析。
3. 制造“平行宇宙”来验证（双版本检查）
这是 Echo 最厉害的地方，也是它被称为“首创”的原因。
- 以前的做法：AI 写了一个测试，发现它报错了，就以为“太好了，Bug 重现了！”但有时候，测试报错可能是因为代码写错了，而不是因为 Bug。这就像侦探看到嫌疑人摔倒了，就以为是他干的，其实可能是路滑。
- Echo 的做法：Echo 会先让另一个 AI 尝试**“修好”这个 Bug**（生成补丁），制造一个“完美版”的软件。
- 比喻：Echo 会进行**“双版本对比实验”**：
- 在**“坏版本”（原版）上运行测试：测试必须失败**（证明 Bug 存在）。
- 在**“好版本”（打了补丁的版本）上运行测试：测试必须成功**（证明 Bug 被修好了）。
- 只有同时满足这两个条件，Echo 才敢拍胸脯说：“这个测试是真的重现了 Bug！”如果不行，它就把“演出录像”拿回去，让 AI 重新改剧本，直到完美为止。
4. 少而精，拒绝“人海战术”
- 以前的做法：很多 AI 会生成 100 个测试方案，然后挑一个最好的。这就像让 100 个侦探去猜，虽然可能猜对，但成本太高，效率太低。
- Echo 的做法：Echo 追求**“一击必杀”。它通过不断的自我修正（看录像、改剧本），只为每个 Bug 生成一个**高质量的测试。
- 比喻：它不像是在撒网捕鱼，而是像狙击手，瞄准、调整、再瞄准，直到子弹（测试代码）精准命中靶心。
成果如何？
在业界公认的“侦探考试”（SWT-Bench 基准测试）中，Echo 取得了66.28%的成功率，成为了目前开源工具中的第一名（SOTA）。
- 它比第二名强在哪里？ 它不仅更准，而且能解决很多其他工具解决不了的“疑难杂症”。
- 它贵吗？ 虽然它用了很多算力，但因为它只生成一个高质量测试，而不是生成一堆垃圾再筛选，所以性价比很高，比很多竞争对手更省钱。
总结
Echo 就像一个拥有“超级地图”、能“自动搭舞台”、还会“制造平行宇宙”进行对比实验的 AI 侦探。
它不再盲目地猜测，而是通过精准找线索、自动跑测试、用“修好版”来验证，一步步把模糊的 Bug 描述变成确凿的证据。这不仅帮程序员省下了大量时间，也让软件变得更可靠。
这篇论文的核心思想就是：与其盲目地多生几个，不如聪明地少生一个，但要确保它是完美的。
Each language version is independently generated for its own context, not a direct translation.
这是一份关于论文 《Echo: Graph-Enhanced Retrieval and Execution Feedback for Issue Reproduction Test Generation》 的详细技术总结。
1. 研究背景与问题 (Problem)
在软件开发中，准确复现用户报告的 Bug 是解决问题的关键步骤。然而，现有的 Bug 报告往往缺乏可执行的复现测试用例，导致开发者难以定位根因。手动编写此类测试用例耗时且费力。虽然已有研究利用大语言模型（LLM）自动生成复现测试，但现有方法存在以下主要局限性：
- 上下文检索不准确：现有方法多依赖简单的层级文件定位（如 Agentless 框架），难以捕捉大型代码库中的深层结构关系和长程语义，导致检索到的上下文噪声大或不完整。
- 执行环境配置困难：许多工具假设测试执行命令已知，但在真实项目中，测试运行配置分散且隐含，微小的命令差异会导致测试无法运行。
- 缺乏可靠的验证标准（Oracle）：仅靠 LLM 判断语义等价性不可靠。缺乏一种机制来验证生成的测试是否真正满足“失败 - 通过”（Fail-to-Pass）准则（即在原始代码中失败，在修复后的代码中通过）。
- 效率与成本：现有方法通常生成大量候选测试并从中筛选，导致计算成本高且效率低。
2. 方法论 (Methodology)
为了解决上述问题，作者提出了 Echo，一个基于智能体（Agent）的复现测试生成系统。Echo 的核心流程包含六个阶段，其创新点在于引入了**代码图（Code Graph）增强检索和执行反馈（Execution Feedback）**驱动的精炼机制。
核心组件与流程：
基于代码图的上下文检索 (Context Retrieval)：
- 代码图构建：将代码库建模为异构有向图（包含资源节点、解析树节点、文本片段节点），利用 Neo4j 存储，以捕捉文件结构、语法关系和文档上下文。
- 自动查询精炼：不同于固定查询，Echo 使用 LLM 自动评估初始查询的质量。如果检索到的上下文不足以生成测试，LLM 会生成后续查询进行迭代检索，直到收集到足够的“焦点代码”（Focal Code）和回归测试用例。
- 检索内容：包括与问题最相关的代码片段（焦点代码）和三个最相关的现有回归测试用例（作为格式和风格的参考）。
补丁生成 (Patch Generation)：
- 利用开源工具 Prometheus 生成潜在的修复补丁（Patch）。
- 生成的补丁用于构建“修复后的代码版本”，作为验证测试是否满足 Fail-to-Pass 准则的“预言机（Oracle）”。
测试用例生成 (Test Case Generation)：
- LLM 结合问题描述、检索到的焦点代码、回归测试示例和潜在补丁，生成一个独立的、符合项目规范的复现测试文件。
- 采用角色提示（Role Prompting），让 LLM 扮演 QA 自动化专家，生成最小化的测试用例。
自主测试执行 (Autonomous Test Execution)：
- Echo 能够自动推断项目的测试执行命令（基于 README、配置文件等），并在容器中运行生成的测试。
- 安全约束：为防止 LLM 修改环境或运行全量测试，系统设定了严格规则（如：只运行生成的测试文件、不修改文件、不安装依赖、假设环境已就绪）。
测试验证与双版本检查 (Test Verification & Dual-Version Check)：
- 执行反馈验证：LLM 分析执行日志，判断失败行为是否与问题描述语义一致。
- 双版本检查（核心创新）：这是 Echo 区别于以往工作的关键。系统将生成的测试分别在原始代码库和应用了补丁的代码库上运行。
- 如果测试在原始版本失败，在补丁版本通过，则满足 Fail-to-Pass 准则，测试有效。
- 如果不满足，系统会将执行日志反馈给生成器，进行迭代精炼（Refinement），最多重试两次。
- 与以往生成大量候选并筛选不同，Echo 致力于通过迭代精炼生成单个高质量测试用例。
3. 主要贡献 (Key Contributions)
- Echo 系统：提出了首个结合代码图增强检索、自动执行反馈和双版本验证的 Issue Reproduction Agent。
- SOTA 性能：在广泛使用的基准测试 SWT-Bench Verified 上，Echo 取得了 66.28% 的成功率，超越了所有现有的开源和闭源方法（包括使用 GPT-5-mini 和 Claude 3.7 Sonnet 的模型）。
- 开源与可复现性：Echo 已开源，提供了代码、执行日志和完整实验结果，促进了该领域的研究。
- 深入分析：详细分析了执行反馈精炼机制的有效性、Token 消耗成本以及不同项目（如 Django, Scikit-learn）上的表现差异。
4. 实验结果 (Results)
- 成功率 (Success Rate)：在 SWT-Bench Verified (433 个实例) 上，Echo 的成功率为 66.28%。相比之下，次优方法 e-Otter++ 为 62.1%，OpenHands 为 62.4%。
- 唯一性：Echo 解决了 33 个其他顶级方法（如 AssertFlip, E-Otter++）未能解决的实例，显示出其独特的解决能力。
- 精炼机制的有效性：
- 移除“执行反馈精炼”和“双版本检查”的变体（Echo w/o refinement）成功率仅为 59.12%。
- 引入精炼后，成功率提升了 7.16%，证明了利用补丁版本作为预言机进行迭代优化的有效性。
- 成本效益：
- Echo 的平均单次实例成本约为 $1.54（使用 Gemini 2.5 Pro）。
- 虽然比简单的 Zero-shot 方法贵，但比许多现有的 Agent 方法（如 e-Otter++ 使用 Claude 3.7 时约 $2.75）更具成本效益，且性能更高。
- Token 消耗主要集中在“生成与精炼”阶段（占 69.7%），输入 Token 占主导。
5. 意义与影响 (Significance)
- 提升 Bug 定位效率：Echo 能够自动生成可靠的复现测试，显著缩短开发者理解 Bug 和定位根因的时间。
- 改进 CI/CD 质量：生成的测试用例可直接集成到持续集成流程中，增强软件系统的健壮性。
- 方法论创新：
- 证明了代码图在复杂代码库上下文检索中的优越性。
- 确立了**“生成 - 执行 - 双版本验证 - 精炼”**的闭环模式优于单纯的“生成 - 多候选筛选”模式，实现了更好的成本 - 性能权衡。
- 展示了利用**潜在补丁（Potential Patches）**作为验证预言机的可行性，解决了缺乏明确断言（Oracle）的难题。
- 未来方向：论文指出了未来减少检索上下文成本、优化执行环境配置以及寻找更鲁棒的验证预言机的方向。
总结：Echo 通过引入结构化的代码图检索和基于执行反馈的迭代精炼机制，成功解决了自动复现 Bug 测试中的上下文缺失和执行验证难题，在开源工具中树立了新的性能标杆。