在权威SWE-Bench Verified基准测试中，JoyCode Agent凭借74.6%的高通过率，强势登榜全球Top3，并正式开源！欢迎点Star关注🌟
Github开源地址：https://github.com/jd-opensource/joycode-agent
Gitee开源地址：https://gitee.com/JD-opensource/joycode-agent
JoyCode Agent展现出了卓越的复杂编程问题解决能力。与榜单先进方案相比，JoyCode Agent在实现相近性能表现的同时，将计算资源消耗降低了30%-50%。这一成果不仅体现了JoyCode Agent高效应对复杂编码挑战的能力，更彰显了其在实际应用中的高性价比和商业价值。
摘要
SWE-bench作为当前自动软件工程修复领域的代表性基准，要求智能体具备高效的补丁生成与验证能力。随着大语言模型的发展，实际场景中的软件工程任务已经能被进一步的解决了，但基于提示词工程的方法已经不能很好的解决代码仓库级别的工程修复任务。基于上述的困境，本文提出了一种以“补丁–单测协同生成与迭代验证”为核心的自动修复框架。
具体而言，我们首先在Docker隔离环境中针对具体代码仓库生成初始补丁，并同步生成Fail2Pass和Pass2Pass两类单元测试，对补丁效果进行全面验证。当补丁通过所有自动生成的单测时，直接作为最终修复结果输出；若测试未通过，则设计一套校验流程判定问题源自补丁本身还是测试用例，并据此有针对性地重新生成补丁或单测，实现高效的错误定位与自适应迭代。最终，系统可获得高质量的补丁池，为实际软件仓库问题的自动化修复提供有力支持。实验结果表明，该方案在SWE-bench标准任务上能够显著提升补丁正确率与修复覆盖率。
JoyCode京东云开发者社区：https://developer.jdcloud.com/article/4365
一、项目背景与目标
-
代码库级理解与跨文件推理：相比于函数级别的任务，SWE-bench涉及真实项目中的复杂问题，通常需要对整个代码库有全局性的理解，能够跨文件、跨模块进行推理和修复。这要求模型不仅能生成语法正确的补丁，还要保证语义上的一致性与正确性。 -
大规模解空间与候选方案管理：由于可能的修复路径多样，候选补丁空间巨大。如何高效生成、筛选、验证和整合这些补丁，避免冗余和错误，是当前系统面临的核心技术瓶颈。 -
推理轨迹多样性与进化：LLM生成的解决方案往往趋同，缺乏真正多样化的推理路径，导致探索空间有限，难以发现创新性或边缘性的正确修复。如何让模型跳出高概率、惯性化的模式，挖掘潜在正确解，是提升成功率的关键。 -
自动化验证与反馈循环：修复补丁需要自动化测试和验证机制，以确保补丁真的解决了问题且没有引入新故障。高效的测试反馈机制和验证策略仍有很大提升空间。
-
在SWE-bench Verified的Pass@1官方评测中，目前取得74.6%的通过率。该分数来自于“补丁–单测协同生成与迭代验证”的完整流程：先生成Pass2Pass和Fail2Pass单测，再进行首轮Patch生成，并在Docker隔离环境中执行单测验证，失败样例进入“轨迹压缩+CRS检索+二轮重试”的后处理流程。
二、业界现状与优化思路
2.1 业界现状与痛点
2.1.1 提示词工程“一次性生成”在仓库级任务上失效
本质问题：单轮大模型推理难以覆盖复杂仓库的代码依赖、跨文件语义与历史上下文，容易出现“语义漂移”和“脆弱一致性”。
典型症状：Patch通过少量样例测试但在全量测试中失效；针对特定Issue的“过拟合式修复”；同一仓库的类似问题难以迁移复用，还可能引入新问题。
直接影响：成功率波动大、可复现性差，难以稳定提升Pass@1。
2.1.2 失败仅“报错不归因”，导致重试无方向
本质问题：缺乏对失败来源的系统性建模，无法区分“Patch逻辑错误”“工具定位错误”“环境/依赖异常”等根因，重试策略主要为盲目搜索。
典型症状：重复触发相同错误、无效重跑占比高；token主要消耗在“错误分布内部”的局部探索；调参靠经验，策略不可解释。
直接影响：重试效率低，导致整体吞吐和稳定性受限。
2.1.3 缺乏经验复用，长尾案例收敛慢、覆盖率受限
本质问题：多数系统将每个实例当作“独立样本”，没有构建可迁移的“成功策略表征”与“失败模式画像”，难以跨实例复用解决方案。
典型症状：相似问题反复探索同类无效路径；在复杂仓库（如 django、scikit-learn）中对同类型Bug的“重复踩坑”；调度与提示词无法受先验知识指导。
直接影响：对长尾问题的处理成本指数级上升，难以在固定预算内扩大覆盖率或稳定提升上限。
2.1.4 Token消耗爆炸，成本–收益比失衡
本质问题：将“多次独立运行 + 结果求并集 + 稳健投票”作为主路径，而非建立“有方向的闭环迭代”，导致候选规模不受控。
典型症状：海量候选采样后，仍在错误分布内做“次优选择”；投票只能在“整体质量一般”的集合里勉强挑选相对较好的方案。
直接影响：token使用量与延迟快速攀升；单位token的有效产出下降；系统工程复杂度提升但边际收益递减。
2.1.5 多轮代理的误差累积与路径依赖
本质问题：仓库级修复需要多轮工具调用与策略决策；早期的微小偏差（定位错误、解释偏误）会在后续步骤被放大，造成路径依赖与误差累积。
典型症状：代理在错误上下文中越走越偏；最终Patch与问题无关或引入副作用；即便投票，也可能只是从“同一错误簇”中选一个“相对不差”的。
直接影响：整体效率与质量被链路前段的误差所绑架，后续再多的采样与投票都难以扭转结果。
2.2 我们的优化思路及优势
2.2.1 针对“一次性生成失效”的问题
现状：单次大模型推理对仓库级修复的覆盖率不足，缺少验证闭环，难以稳定提升Pass@1。
我们的思考：仓库级修复是一个“生成–验证–修正”的闭环问题，不能只依赖一次性生成。需要将“Patch生成”和“测试生成/预验证”耦合，形成以测试为中心的工程反馈回路。
我们的优化：将补丁生成与Fail2Pass & Pass2Pass单测协同设计，并在隔离环境下进行严格验证；失败样例进入结构化后处理（归因→指向性重试）。这使得系统从“单轮采样”转为“闭环迭代”，输出具备可验证证据的补丁。
相比同类的优势：许多方案要么只做补丁生成，要么只依赖现有测试。我们采用“动态测试协同生成 + 原仓预验证”的策略，在问题前置阶段就过滤掉“测试不成立”的噪声，显著提升整体的稳定性。
2.2.2 针对“失败仅报错不归因”的问题
现状：失败后难以判断责任边界（补丁逻辑 vs 测试设计 vs 环境/依赖），导致不可控的反复重试。
我们的思考：精细化失败归因是提高重试效率的关键。只有明确问题来源，才能设计差异化的重试路径，实现更低的token消耗与更快的收敛。
我们的优化：引入“失败归因”机制，将失败拆分为可执行的类别标签；针对不同标签，选择“基础重试/测试侧修正/策略升级”等不同路径，形成可解释的再求解过程。
相比同类方法的优势：与“黑盒重跑”不同，我们通过归因实现“有方向的迭代”，减少无效探索和随机波动，稳定提升成功率。
2.2.3 针对“缺乏经验复用”的问题
现状：大多数系统对于历史成功案例“看过就忘”，在难例上重复走弯路。
我们的思考：仓库级修复常呈现模式可迁移的特性。同类问题在补丁类别、修改策略、测试构造上具有相似性；将成功经验结构化并迁移到相似样例，可显著缩短探索路径。
我们的优化：基于轨迹压缩与相似案例CSR检索，将“策略摘要”引入下一轮重试的提示，使得“重试不是从零开始”，而是“从经验启航”。
相比同类方法的优势：与单纯的多样化采样不同，“经验迁移重试”机制具备方向性与可解释性，对于难例的收敛更友好。
2.2.4 针对“Token消耗爆炸”的问题
现状：多次独立运行取并集、无效重试过多、无差别增加候选，都会导致token使用量激增，成本与时延不可控。
我们的思考：降低token的关键在于“有针对性的重试”与“早期筛除无效路径”。通过归因与协同测试，把无效路径挡在前面；通过经验迁移与单测筛选，提高单位token的有效性。
我们的优化：将“测试协同+失败归因+经验迁移+投票仲裁”纳入一个整体策略栈。投票只在必要时对候选进行“最后一跳”的稳健选择，而不是以“海量并行采样”替代系统性改进。
相比同类方法的优势：相比“海投+海选”的简单并行，我们强调“质量优先的候选构造+适度投票兜底”，以更低token成本实现更高的成功率及稳定性。
以下是JoyCode Agent调用LLM的次数分类及占比：
| 类别 | Testing （次数） | Patch （次数） | 轨迹压缩（次数） | 根因决策（次数） | 相似度检索（次数） | 投票决策（次数） | 总次数 |
| 1 | 1 | 1 | 1 | 0 | 0 | 0 | 3 |
| 2 | 1 | 2 | 1 | 0 | 0 | 1 | 5 |
| 3 | 1 | 2 | 1 | 0 | 0 | 0 | 4 |
| 4 | 1 | 2 | 1 | 1 | 0 | 1 | 6 |
| 5 | 1 | 2 | 1 | 1 | 1 | 1 | 7 |
| 类别 | 数量 | 占比 |
| 1 | 351 | 70.2% |
| 2 | 106 | 21.2% |
| 3 | 16 | 3.2% |
| 4 | 10 | 2% |
| 5 | 17 | 3.4% |
2.2.5 针对“多轮代理误差累积与候选选择”的问题
现状：长链路代理容易误差滚雪球；纯投票可能只是在错误分布内做“次优”。
我们的思考：需要在“多轮生成”的同时，构建强力的检错与纠偏机制，并明确投票的定位——用于最终仲裁，而非弥补缺乏验证与归因的欠账。
我们的优化：通过隔离环境的一致性验证、失败来源的精细化归因、经验迁移驱动的重试，将“误差累积”分段打断；在候选集构造已具备质量保证的前提下，再用投票进行稳健仲裁。
相比同类方法的优势：我们把投票放在“验证-归因-重试”之后，作为“稳定器”而非“主力军”，使得候选质量更高、仲裁更有效，减少无谓的资源消耗。
总的来说，我们针对业界在“仓库级自动修复”的关键短板进行了系统级工程优化：把补丁生成、单测生成与验证、失败归因与经验重试整合为一个可复现、可扩展、可观测的闭环流水线。这些优化直接服务于SWE-bench Verified的打榜目标，既提升Pass@1的稳健性，也为后续的策略演进提供了坚实的工程基础。
三、整体系统结构
3.1 系统简介
本系统实现了“补丁–单测协同生成与迭代验证”端到端pipeline，关键设计如下：
3.1.1 单测协同生成
通过数据集中的Issue，分析相应代码仓中的问题来源，生成Fail2Pass和Pass2Pass单测样本，并在原始代码上进行预执行校验，确保Fail2Pass单测在未修复前应当失败，Pass2Pass单测在未修复前应当成功，从而约束 Patch 生成方向。
3.1.2 首轮Patch生成与容器化验证
在Docker隔离环境中按实例启动SWE-bench对应镜像，初始化工作区与Git基线，通过Patch-Agent和Issue驱动生成Patch。
开启验证后，立即在容器内以Pytest执行生成的Fail2Pass和Pass2Pass单测，得到评测的结果作为首轮Patch的通过情况，指导后续的流程。
3.1.3 轨迹压缩+相似案例检索
从首轮存储的信息中读取轨迹信息和Patch信息，使用LLM将执行轨迹压缩为“策略/关键变更/要点”的结构化摘要，沉淀到轨迹池中。
基于压缩摘要对失败的Case进行CSR检索，即从成功案例库中检索最相似的实例，返回相似度分数、迁移理由与轨迹摘要，作为第二轮Patch生成的先验知识。
3.1.4 二轮重试
将首轮“补丁为空或单测未通过”的实例汇总为重试候选；为命中高质量相似案例的实例注入先验知识（策略 + 关键变更 + 相似度/理由），在 Retry Agent 配置下并发重试生成新补丁。
无相似案例时采用“无经验”重试路径，仍以并发方式生成候选补丁，最大化召回。
将一轮、二轮生成的Patch通过Decision Agent决策出最优结果，得到最终用于提交官方的Patch。
综上，当前实现以“Fail2Pass与Pass2Pass的单测约束 → 首轮补丁生成与容器验证 → 轨迹压缩与 CRS 检索 → 二轮重试”的闭环，形成了高质量的Patch池与可复现的工程Pipeline。
3.2 交互策略与系统流程
该Multi-Agent系统通过一套自动化的流程，将自然语言描述的软件问题（Issue）与代码仓库作为输入，最终为每个问题实例生成一个可复现、可验证且具备明确决策依据的最优代码补丁（Patch）。此流程由四个核心智能体协同执行：Testing Agent负责构建测试验证套件，Patch Agent负责实现修复，CSR Agent在特定失败场景中提供经验检索，Decision Agent则对重试前后的两个候选补丁进行最终的仲裁。
第一步，系统调用Testing Agent将问题描述转化为可执行的测试基准。在实现层面，Testing Agent可以通过Bash工具完成依赖安装、环境检测、测试文件的创建与写入等，并最终生成包含两个PASS TO PASS和一个FAIL TO PASS的测试矩阵。生成后会立即进行预验证，以确保生成的测试用例满足“一败两通”的结构规范。
第二步，系统调用Patch Agent生成初步修复补丁（Patch）。Patch Agent采用以“规划—实现—修订”为主线的工程化策略，借助一系列工具进行代码理解、错误复现与定位，并对目标代码进行精确修改等。最终，此阶段产出一个可运行的有效补丁，但是，生成的补丁也可能为空，或是未能通过第一步生成的测试套件。
第三步，系统根据前两步的结果进入分支处理，通过不同策略保证流程收敛：
测试用例生成失败（为空），但补丁成功生成：由于缺乏有效的测试验证基准，系统将启动基础重试（Base Retry），在相同的输入条件下再次调用Patch Agent生成一个新的Patch，随后，Decision Agent在两个候选补丁间进行决断，选出最优方案。
初次补丁生成失败（为空）：系统同样进行基础重试以生成一个新Patch，并将其直接采纳为当前实例的最优解。
测试用例合规生成（满足“一败两通”），且初次补丁成功通过验证：流程在此收敛，初次生成的Patch被直接确认为最优补丁。
测试用例成功生成（不为空），但初次补丁未通过验证：系统启动失败归因流程：
归因于测试用例（Test）：判定标准为测试用例本身不合规或未能准确反映issue 意图，之后，系统将触发基础重试，生成一个新补丁后进行投票决策。
归因于补丁（Patch）：判定标准为补丁自身的逻辑错误、实现缺陷或考虑不周等情况，之后，系统则会激活经验重试。首先将所有实例第一次生成Patch的轨迹信息（如工具调用策略等）进行压缩，并纳入轨迹池，然后调用CSR Agent，以当前失败实例的issue为检索条件，从历史成功案例库中检索出语义最相似的成功实例所对应的的压缩轨迹，再将“失败压缩轨迹”与最相似的“成功压缩轨迹”一并提供给Patch Agent，要求其对比分析与纠偏学习，生成一个优化后的新补丁，最终由Decision Agent在初次补丁与优化补丁之间完成投票仲裁。
在整个workflow中，Decision Agent扮演着统一的“仲裁者”角色：当面临多个候选补丁时，它会基于对问题描述与变更意图的深刻理解，从逻辑正确性、与issue的一致性、修改的最小性与风险控制、代码质量与可维护性以及边界条件覆盖等维度进行综合评估，形成明确且可追溯的投票结论。
综上，该系统通过“建立标准（Testing Agent）→ 实施修复（Patch Agent）→ 决策重试（CSR Agent）→ 最终仲裁（Decision Agent）”的Agent交互设计，确保每个问题实例都能收敛至一个最优补丁。最终汇集而成的结果集，因其具备明确的测试基准、可复现的实验路径与透明的决策依据，可直接用于后续的官方评测与对比分析。
四、Agent结构设计
4.1 Patch Agent
4.1.1 功能介绍
Patch Agent是基于响应式代理（React Agent）架构构建的核心智能体。它模拟人类开发者的工作模式，在一个持续的“观察-思考-行动”闭环中运行，根据任务的实时进展和反馈，动态地调整其策略。
观察（Observe）：从问题到洞察
任务解析：工作流始于一个GitHub Issue。Agent利用大模型的语言能力，从自然语言描述、错误日志和用户反馈中提炼出问题的核心。
代码勘探：随后，它会深入代码库，借用Bash工具，通过ls、grep、find等终端命令实现代码搜索、阅读，甚至直接运行代码以复现错误等方式，主动勘探和定位问题相关的代码区域。
思考（Think）：从洞察到策略
思维链：这是Agent的决策中枢，它构建一个适应性极强的行动计划（即思维链）。例如：“首先，为file.py中的calculate_total函数添加discount参数；然后，更新所有调用点；最后，运行单元测试验证。”
动态规划：这个计划并非一成不变。Agent采用“ 边想边做 ”的模式，可以在思考过程中穿插执行代码编辑或Bash命令来获取更多信息，并根据结果即时调整后续策略。
行动（Action）：从策略到解决问题
执行与验证：在行动阶段，Agent调用其工具箱将策略付诸实践。它使用Bash工具来配置环境（如安装依赖、运行构建脚本），并调用代码编辑工具来精确地实现代码的增、删、改。
迭代循环：每一步操作后都伴随着即时验证 。Agent会立刻运行Codebase中原生测试套件来检验修改的正确性。如果验证失败，这并不会中止流程，而是被视为新的观察输入。Agent会带着失败的日志信息，自动回到“观察”阶段，重新分析、思考并再次行动，形成一个高效、自主的迭代修复循环。
当Patch Agent成功完成所有修改并通过必要的验证后，它会将所有变更整合成一个标准的代码补丁（Patch）文件。这个补丁文件清晰地记录了所有的代码改动，可以直接被合并到主代码库中。
4.1.2 工具设计
Patch Agent的功能由一个模块化的工具集实现，每个工具都在“观察-思考-行动”循环中承担特定职责。
代码编辑工具
功能：提供对文件内容进行精确修改的接口，支持基于上下文的原子化操作，如插入、替换和删除指定的代码块。
用途：用于执行由推理过程确定的源代码修改。其精确性确保了变更的最小化，从而生成清晰、易于审查的代码补丁。
Bash 工具
功能：提供一个在项目工作空间内执行标准Shell命令的环境。
用途：主要用于信息获取（通过grep , ls等进行静态分析）、环境准备（通过pip等安装依赖）和动态验证（通过运行pytest等测试套件获取执行反馈）。
思维链工具
功能：一个结构化的内部推理组件，用于将高层任务目标分解为具体的行动序列。
用途：负责制定行动计划、根据工具执行的实时反馈进行动态调整，并协调其他工具的调用与参数传递。
4.1.3 输入输出定义
输入信息如下：
Issue
定义：对软件问题的详细文字描述，其内容通常等同于一个GitHub Issue或Pull Request。它包含了复现问题、理解背景和明确目标所需的所有信息，如错误报告、功能需求、堆栈跟踪等。
用途：这是Agent进行任务解析和构建初始计划的原始信息源。Agent通过自然语言理解的能力从该描述中提炼出具体的工程目标。
Location
定义：一个指向待修改代码仓库根目录的路径。此路径通常指向一个隔离的、容器化的文件系统环境。
用途：为Agent提供一个安全、封闭的工作沙箱。Agent的所有操作，包括文件读写、编译、测试等，都将在此目录内进行，确保了操作的隔离性与环境的一致性。
输出信息如下：
Patch
定义：一个遵循标准diff格式的字符串。该补丁精确记录了Agent为解决Issue中描述的问题而对Location内的代码所做的全部修改。
用途：这是Agent工作流程的最终交付成果。此补丁可直接被版本控制系统（如 Git）应用，提交至代码审查平台，无缝融入现有的开发工作流中。
4.1.4 应用场景
Patch Agent的核心价值在于其能够根据任务的复杂度和初始尝试的结果，动态调整其解决策略。其应用场景主要分为以下三种模式：
首次Patch生成：Patch Agent的标准工作流程始于首次patch生成 。接收任务后，Agent会启动其“观察-思考-行动”循环，通过任务解析、代码修改与测试验证，迭代生成一个能通过预设验证的初始补丁，或在达到尝试上限后暂停。
基础重试：若首次生成失败，或者因测试用例问题（测试用例生成失败、测试用例错误等）则会触发基础重试，此模式下，会再一次通过标准的Patch Agent工作流程执行补丁的重新生成，之后通过决策机制选择出两次中最优的补丁。
经验驱动重试：若因Patch的问题导致没有通过Testing Agent生成的测试用例，则会进入经验驱动重试阶段，该模式会为Agent注入两种关键经验，包括自身失败的完整轨迹，以及通过CSR Agent检索出的最相似问题的成功轨迹。Agent会对这两种经验进行辩证分析，从失败中吸取教训，从成功中借鉴策略，形成一个全新的、更具鲁棒性的行动计划。
4.2 Testing Agent
4.2.1 功能介绍
Testing Agent旨在为评估代码补丁（Patch）自动生成有针对性的测试用例，它借助大语言模型，能够深入理解错误报告（Issue）和代码库，并自动生成一套精准的测试用例，从而对每一个代码补丁进行全面、可靠的评估。
Testing Agent会创建三种不同目的的测试用例，共同构成一个完整的验证矩阵：
错误复现测试（FAIL TO PASS）：
运行逻辑：此测试源于代码仓中的原始Bug，在原始的、有缺陷的代码上要求失败 ，但在应用补丁修复后的代码上要求通过。
核心价值：这是验证补丁有效性的“黄金标准”，它直接证明了补丁确实解决了要修复的特定问题。
回归保护测试（PASS TO PASS）：
要求：此测试在修复前后的代码上都必须通过。
核心价值：保护现有功能不被破坏，确保补丁在修复bug的同时，没有引入新的问题。
边缘检测测试（PASS TO PASS）：
要求：此测试同样在修复前后的代码上都必须通过。
作用：专注于检验与Bug相关的边界条件和特殊输入。这确保了修复方案是健壮的，不仅能处理已知的失败场景，在各种极端的使用情况下也能保持稳定，不会产生意外的副作用。
生成的测试用例不会立即用于评估补丁，而是必须先通过一个“预验证”关卡。在这个阶段，所有三个测试用例都会在原始的、有缺陷的代码上运行。只有当测试结果完全符合预期：FAIL TO PASS失败，另外两个PASS TO PASS通过，这套测试用例才被确认为有效且校准精确。
在成功生成并校准测试用例后，系统将立即调用Patch Agent进入代码修复阶段，生成一个候选Patch。该Patch会立刻接受此前生成的测试用例的严格检验：如果能顺利通过所有测试，它将被初步标记为成功；反之，无论是最初未能生成合规的测试用例，还是后续生成的Patch未能通过测试，系统都将启动相应的重试策略，针对性地迭代优化，尝试解决问题。
4.2.2 工具调用
在Testing Agent的整个自动化流程中，通过Bash工具将大模型生成的抽象指令（如创建一个测试文件、运行测试等）转化为操作系统能够理解和执行的具体命令，可以说，Testing Agent的所有计划和调度最终都由Bash工具付诸实践。其核心用途主要体现在以下三个方面：
文件操作：创建与写入测试用例
核心价值：大模型并不会手动输入代码，而是通过执行Bash工具来精确地把构思好的测试代码，准确无误地生成为实体文件，存放于工作区中。
实现方式：通过调用mkdir命令确保生成存放测试文件的目录，利用cat组合指令，将包含复杂缩进和特殊字符的多行测试代码原封不动地写入到指定的.py文件中，为后续的测试执行做好准备。
环境管理：安装与检查依赖
核心价值：执行测试之前，自动确保pytest等所有必需的依赖库都已安装就绪，保证测试环境的一致性和可靠性。
实现方式：采用条件逻辑，只有检查环境的命令失败（意味着依赖缺失）时，才会触发pip install进行安装，这种智能化的检查机制避免了盲目安装以及不必要的重复操作。
测试执行：运行并反馈结果
核心价值：自动执行生成的测试用例，并捕获测试结果，为Agent的后续决策提供依据。
实现方式：Bash工具直接调用pytest命令来运行测试，执行完成会自动捕获执行完毕后的退出码（Exit Code），在该流程中，退出码为0被视为成功，否则为失败。
4.2.3 设计目的
SWE-bench旨在衡量一个Agent是否能像一名真正的软件工程师那样，完成理解、分析并最终解决一个复杂软件问题的完整链路，Testing Agent的设计正是这一理念的直接体现，是为了响应SWE-bench评测对Agent综合问题解决能力的考验，而不仅仅是为了评估其最终产出的Patch。
1）将问题理解转化为可执行的规范：面对一个issue ，一个初级的方法是直接尝试生成代码补丁，但一个高级且更符合工程实践的思路是首先深刻理解问题到底是什么以及修复的标准是什么。Testing Agent构成的测试套件，就是Agent对“修复成功”这个目标的精确定义，它清晰地展示了Agent对问题分析与拆解能力。
2）为高级 Agent 策略奠定基础：生成的测试套件并非一次性工具，而是整个修复流程中可被反复利用的核心。当Patch Agent首次生成的补丁未能通过测试用例时，可以直接尝试判断失败的原因（测试用例问题/Patch问题），然后针对性选择不同的重试机制（基础重试/经验重试），最后进行投票，决策出最优的Patch。
4.2.4 输入输出定义：
输入信息——与Patch Agent的输入信息一致：
Issue：详细描述软件问题的文本
Location：指向对应代码仓库的路径
输出信息——三个独立的测试代码文件：
Test Failure Scenario (错误复现测试)
Test Happy Path (回归保护测试)
Test Edge Case (边缘检测测试)
这是Testing Agent的核心产物，该测试套件首先用于“预验证”，确保其自身逻辑的准确性，通过后，它将作为评估后续代码补丁的“黄金标准”，从有效性、安全性和健壮性三个维度对补丁进行自动化、全方位的质量检验。
4.3 CSR Agent
4.3.1 功能介绍
该 Agent 是系统在测试用例成功生成，但代码补丁未能通过测试用例的情况下所激活的一套高级错误诊断与自我优化的调度 Agent。它通过轨迹压缩、根因决策、CSR 相似度检索和经验重试，将第一次失败的原因和过往相似的成功经验作为第二次重试的先验知识，旨在通过借鉴多维历史经验来指导并优化新Patch的生成。
1）轨迹压缩
在Patch Agent的第一次工作流程结束后，无论成功与否，其完整的执行轨迹都将被捕获和处理。
轨迹定义：一次完整的执行轨迹包含了Patch Agent从接收任务到生成最终Patch的全过程记录，主要包括其内部的思考链、每一轮的工具调用（如代码搜索、文件读写等）。
压缩目的：为了高效存储和检索，原始的冗长的轨迹会被压缩为一个结构化、信息密集的摘要。这个摘要保留了解决问题的核心逻辑和关键步骤，去除了冗长信息。
轨迹池：所有压缩后的轨迹都会被存入一个统一的“轨迹池”中，这个池子构成了系统的知识库，为后续的经验检索和学习提供了数据基础。
2）根因决策
当一个由Patch Agent生成的补丁未能通过Testing Agent所生成的测试组合时，系统并不会直接判定补丁无效，而是启动根因决策模块进行失败归因。具体的决策逻辑为，大模型作为诊断引擎，分析并判断导致测试失败的根本原因。综合分析原始的问题描述、Testing Agent生成的测试用例、失败的代码补丁（Patch）、测试结果这四个维度的信息，进行归因：
归因于测试用例：如果模型判断 Patch 验证失败是由于测试用例本身存在缺陷（例如生成的测试用例未能准确反映 issue 的真实意图），系统将触发基础重试流程。
归因于代码补丁：如果模型判断测试用例是准确的，而失败源于补丁自身的逻辑错误、实现缺陷或考虑不周等情况，系统将触发经验重试流程。
3）CSR 相似度检索
在根因决策将失败归因于代码补丁（Patch）后，CSR 相似度检索机制会被激活，为经验重试寻找可借鉴的“良师”。
检索目标：以当前失败实例的问题描述（issue）作为查询条件，进行CSR相似度检索，检索到与当前失败实例问题最相似的一个成功实例。
检索范围：历史上所有成功解决（即其生成的补丁通过了对应的生成的测试用例）的实例轨迹。
检索结果：成功实例对应的压缩轨迹，即“成功范式”。
4）经验重试
Patch Agent在此阶段会接受到其自身上次生成失败Patch的压缩轨迹以及通过CSR检索到的解决相似问题的成功轨迹。然后进行一次有指导的、基于反思的学习与再生成。
扬长：分析并借鉴成功轨迹中的优点，理解其解决问题的思路、关键代码实现和工具调用策略。
避短：反思并规划自己失败轨迹中的缺陷，找出导致错误的关键节点。
在完成上述分析后，Patch Agent生成一个经过深度优化的新补丁，最后与原始的失败补丁一起被提交给Decision Agent进行最终投票，以确保选出最优的补丁方案。
4.3.2 输入输出信息
轨迹压缩
输入信息——Raw Trajectory：第一次Patch Agent执行过程的完整、原始日志。其中包含了Agent的思维链、工具调用详情等信息。
输出信息——Compressed Trajectory：一个结构化的、信息密集的摘要，提炼了raw trajectory中的核心逻辑和关键步骤。
根因决策
输入信息：
Issue：原始的问题描述
Test Cases：用于验证的代码测试用例
Patch A：第一次生成的未能通过测试的代码补丁
Test Results：测试验证结果
输出信息：
Failure_Cause：一个明确标识失败根源的分类标签，其值为 “PATCH”（归因于补丁） 或 “TEST”（归因于测试用例）
CSR 相似度检索
输入信息：
Issue：当前失败案例的问题描述。
Trajectory Pool：一个包含所有历史上成功解决问题的压缩轨迹的集合。
输出信息：
Original Trajectory：当前失败实例所对应的生成Patch的压缩轨迹。
Similar Trajectory：与当前失败实例语义最相似的成功实例所对应的生成Patch的压缩轨迹。
经验重试
输入信息：
Issue：原始的问题描述。
Location：代码仓库的根目录路径。
Original Trajectory：第一次生成的失败补丁的压缩轨迹。
Similar Trajectory：通过CSR Agent检索到的最相似的成功轨迹。
输出信息：
Patch：经过辩证分析与经验学习后重试生成的新补丁。
4.4 Decision Agent
4.4.1 功能介绍
Decision Agent在整个工作流中扮演着关键的“仲裁者”角色，其核心职责是在系统通过重试机制产生两个候选补丁（Patch）时，通过比较投票，从中选择最优的解决方案。Decision Agent 的功能主要围绕以下两种核心重试场景展开：
基础重试（Base Retry）场景：在这种场景下，问题出在测试用例生成阶段，导致 Patch Agent 的工作缺乏有效验证。
触发条件：
Testing Agent 达到交互轮次限制，未能生成任何测试用例。
Testing Agent 生成的测试用例不符合规范，例如不满足 1 个FAIL TO PASS，2 个PASS TO PASS的要求，或经大模型判定失败根源是测试用例未能准确表达问题意图，而非补丁本身存在缺陷。
执行流程：
由于缺乏有效的测试基准，Patch Agent的初次生成结果Patch A即便已完成也无法被验证。因此，系统启动基础重试，在完全相同的输入条件下，重新执行一次Patch Agent，产生一个全新的Patch B。
此时，Decision Agent会基于其对原始问题的理解，从代码质量、逻辑清晰度、实现思路等方面综合分析并比较这两个补丁，最终票选出它认为更有可能解决问题的最优版本。
经验重试（Experience Retry）：在这种场景下，测试用例本身是合格的，但 Patch Agent 的初次实现未能通过测试，暴露出逻辑缺陷。
触发条件：
Testing Agent成功生成了合规且有效的测试用例。
Patch Agent初次生成的补丁在执行这些测试用例时失败。
执行流程：
首先，调用CSR Agent，它会在知识库中检索与当前问题最相似且已经成功通过生成的测试套件的历史案例。
对应着提取出其Patch Agent生成Patch的压缩轨迹（即关键的思考链与代码实现步骤）。
将获取到的经验信息与上次失败（未能通过生成的测试套件）的Patch的压缩轨迹传递给Patch Agent进行经验重试。
Patch Agent被要求进行“辩证学习”：一方面反思并规避自己生成失败补丁中的缺陷；另一方面分析并借鉴成功轨迹中的优点，从而生成一个经过深度优化的新补丁。
Decision Agent最终投票决定哪个补丁是最优的解决方案。
Decision Agent 通过对不同策略生成的候选方案进行严谨的比较与投票，确保了系统在面对挑战时，能够通过自我反思和外部经验学习，不断迭代出更优质的解决方案。
4.4.2 输入输出定义
输入信息：
issue（String）：详细描述软件问题的文本
Patch A（String）：第一次调用Patch Agent生成的补丁
Patch B （String）：重试调用Patch Agent生成的补丁
输出信息：
solution_index (String)：被选中的补丁对应的索引
basis_of_reasoning (String)：一段对选择该方案的推理和理由的简明摘要，旨在体现一个严谨的投票分析过程
五、典型流程示例
如下图，我们以django-16454实例为例详细阐述一个完整的工作流程，整个过程通过四个核心阶段，完成了真实代码仓库级问题的理解与解决。
第一阶段：自动化生成测试用例
环境初始化：流程启动后，首先从数据集中获取指定实例（ django-16454 ）的详细问题描述。随即，系统在一个隔离的 Docker 容器中准备代码仓库，并自动检测和安装所有必需的测试依赖包，确保了一个纯净且一致的执行环境。
测试策略规划：基于问题描述，系统会深入分析代码，定位潜在的错误根源，并检索项目中是否已存在相关的测试代码。此步骤旨在为后续生成结构化的测试用例提供充分的上下文信息。
测试用例生成与预验证：接下来，系统调用大语言模型，根据分析结果成功生成了 3 个测试用例：错误复现测试、回归测试、边缘场景测试。之后执行预验证程序，该实例生成的测试用例符合两个 PASS TO PASS，一个 FAIL TO PASS 的结构要求，成功通过了预验证程序。
第二阶段：代码补丁生成与验证
代码勘察与错误重现 ：系统利用 Bash 工具深入代码库，理解其整体架构，并再次确认错误的具体表现，为制定修复策略提供依据。
通过深度分析，系统会借助 Sequential Thinking 等工具规划出具体的修复方案。一旦方案确立，系统将利用 String Replace 工具精确地修改相关代码，生成一个初始的代码补丁（Patch）。
测试验证：该步骤使用第一阶段生成的测试用例来检验该补丁的有效性。在此 django-16454 实例中，测试验证宣告失败：该补丁不仅未能解决核心问题，反而还导致了回归测试失败。
第三阶段：重试策略选择与执行
轨迹压缩：首先会利用大模型对所有实例的 Patch 初次生成的轨迹进行压缩，构建轨迹池作为后续流程的前置条件，区分哪些实例是可参考的成功的案例，哪些是失败的案例。
失败归因：分析失败是因为测试用例的设计不当还是代码补丁本身存在缺陷。在此案例中，系统判定第一阶段生成的测试用例是准确的，但是生成的代码补丁未能有效解决问题。
相似案例检索：由于确定是补丁的问题，系统会启动 CSR 检索机制，寻找一个与当前失败案例高度相似，并且已经成功的补丁，并且获取到其生成补丁的过程对应的压缩轨迹。
经验重试：系统将检索到的成功案例的解决策略与上次失败的经验进行整合，构建出一个信息更丰富、指导性更强的新提示，然后进行经验重试，再次尝试生成一个新的代码补丁。
第四阶段：投票决策最优补丁
系统对两次生成的补丁进行评估和投票，在此案例中，第二次重试后的补丁被认为质量更优，因此被选定为最终的解决方案。
结语
本次技术报告系统梳理了JoyCode Agent在自动化软件修复领域的核心架构、创新算法及工程优化路径。从仓库级别的深层代码理解，到“补丁–单测协同生成与迭代验证”闭环，再到多智能体协作、高效经验迁移与精细化失败归因，JoyCode Agent在SWE-bench Verified全球测评中实现了高通过率与显著的资源节约，充分展现了JoyCode团队对AI软件工程的深度思考与技术积累。
展望未来，我们将持续迭代JoyCode Agent的能力边界，不断优化多Agent协同、经验复用机制和仓库级修复方案，推动自动化修复的智能化与工程化落地。下阶段，我们将进一步开源核心技术，深化与社区开发者的交流合作，拓展更多真实场景下的应用实践，助力企业和开发者以更低成本、更高质量应对复杂编码挑战。此外，我们还将陆续发布相关专利，持续提升技术创新能力，为行业发展注入更多动力。
当前时代，技术变革正在重塑软件开发的每一个环节，选择JoyCode，意味着选择一个能够与用户共同成长、不断进化的智能工具。我们始终坚持以用户需求为导向，致力于打造高效、可靠的AI编程引擎，与广大开发者携手迈向智能编程时代的新高峰。
🌟开源链接，欢迎Star收藏支持！
https://github.com/jd-opensource/joycode-agent
https://gitee.com/JD-opensource/joycode-agent
推荐阅读