UniDebugger: Hierarchical Multi-Agent Framework for Unified Software Debugging

1 Introduction

• Prior LLM debugging methods typically automate isolated fault-localization or repair phases, while peer-to-peer agent frameworks risk redundant negotiation and poor resource allocation across bugs.The paper positions UniDebugger as an end-to-end approach that addresses these limitations through structured coordination.Source: §1 · p. 1
• UniDebugger treats agents as components of a unified cognitive process, escalating from quick repairs to deeper analysis, tool use, and external information when earlier levels fail.Its three levels accumulate knowledge incrementally rather than relying on mesh-based, bidirectional negotiation.Source: §1 · pp. 1–2
• Seven agents handle online research, repository analysis, code summarization and slicing, root-cause localization, patch generation, and patch optimization.L1 uses Locator and Fixer; L2 adds Summarizer and Slicer and then invokes Locator, Fixer, and FixerPro; L3 activates all agents, with Helper and RepoFocus support and code-analysis tools available on L2 and L3.Source: §1 · p. 2
• UniDebugger correctly fixed 197 Defects4J bugs with 286 plausible fixes, fixed all QuixBugs bugs, and generated 2.2× more plausible fixes on Codeflaws.It outperformed strong baselines including ChatRepair, which uses ground-truth root causes with 10× sampling; ablations showed significant improvements across LLM backbones.Source: §1 · p. 2

Software Debugging

• Test-driven debugging combines fault localization (FL) and automated program repair (APR), which prior work has automated through traditional, learning-based, and LLM-based methods.FL methods include spectrum- and mutation-based approaches, while APR includes patch search, specification inference, neural machine translation, and LLM prompting or code synthesis.Source: §2 · pp. 2–3
• Unlike user-oriented techniques that respond to problems discovered by users, this work targets CI to help developers proactively detect and resolve bugs before production.User-oriented debugging responsively updates software based on user-discovered problems (Xia et al., 2024; Jimenez et al., 2024).Source: §2 · p. 3

LLM-based Multi-Agent (LLM-MA)

• LLM-based multi-agent studies for software engineering commonly emulate roles such as product managers, programmers, and testers, collaborating through communication (Qian et al., 2024; Hong et al., 2024; Dong et al., 2023; Huang et al., 2024; Islam et al., 2024).Hong et al. (2024) and Dong et al. (2023) use a shared information pool to reduce overhead.Source: §2 · p. 3

3.1 Profiles of Agents

• The seven agents share one-shot role prompts and bug metadata; Helper retrieves tailored references, while RepoFocus, Summarizer, and Slicer focus inspection on relevant files and code segments.Summarizer produces code summaries for L2 and L3; Slicer narrows large-code inspection and can use static or dynamic analysis tools.Source: §3.1 · pp. 3–4
• Locator marks faulty or missing lines, Fixer proposes a diff and checks Locator’s markings, and FixerPro reviews and optimizes the patch or generates one if Fixer fails.Locator annotates the original code through contextual string matching; FixerPro assesses potential vulnerabilities and suggests refactoring for simplicity and maintainability.Source: §3.1 · p. 4

3.2 External Interactions

• UniDebugger applies patches by matching invariant context, then compiles and tests them; its toolbox includes static and dynamic analysis, search, and RAG, with tool results reused downstream.Plausible patches that pass all test cases are sent to developers for manual correctness verification.Source: §3.2 · pp. 4–5

3.3 Hierarchical Coordination

• L1 handles straightforward bugs with Locator and Fixer; failed repairs escalate to single-file L2 and then cross-file L3 with all seven agents.At L2, Slicer and Summarizer prepare the suspicious segment and code summary before Locator, Fixer, and FixerPro work in sequence; L3 adds Helper and RepoFocus and summarizes related files.Source: §3.3 · p. 5
• When L3 yields no plausible patch, UniDebugger requests reflection in reverse workflow order, first from FixerPro and then Fixer, and reruns until a resource threshold if needed.Plausible patches are returned to developers for manual verification; if none is produced, UniDebugger displays FixerPro’s analysis report.Source: §3.3 · p. 5

4.1 Experimental Setup

• The evaluation covers four bug-fix benchmarks, 14 APR baselines, and seven LLM backbones; Defects4J results span versions 1.2 and 2.0.The framework uses a default gpt-4o backbone, samples plausible ConDefects fixes for correctness checks, and uses local rather than web search during evaluation to avoid retrieving ground-truth solutions online.Source: §4.1 · pp. 5–7

4.2 Comparison with baselines

• On Codeflaws, UniDebugger plausibly fixes 3,130 of 3,982 bugs, 2.2x GenProg’s plausible fixes, and fixes all QuixBugs bugs across both languages.On Codeflaws, its correctness rate is 95%, 60.81% above CoCoNuT; the paper also reports 19.28% more plausible fixes than Claude 3.5 Sonnet at the same correctness rate. The takeaway reports all QuixBugs bugs fixed and 19.28% more plausible fixes on ConDefects with the highest correctness rate.Source: §4.2 · p. 7
• On Defects4J, UniDebugger correctly fixes 197 bugs, outperforming ChatRepair by ∼25.48%.It also correctly fixes 42 bugs that the top four baselines have never fixed.Source: §4.2 · p. 7

4.3 Performance on Different LLMs

• UniDebugger-Lite improves plausible fixes over its LLM backbones by 21.60%–52.31%; with LLaMA2 it reaches 280, near gpt-3.5-turbo-ca’s 282.DeepSeekCoderV2 with UniDebugger plausibly fixes 376 bugs, similar to gpt-4o’s 390; gains narrow the open-source/proprietary gap, while overall performance remains tied to backbone coding ability.Source: §4.3 · pp. 7–8, Table 3 · p. 8

4.4.1 Impact of Different Agents

• Adding agents beyond Fixer consistently increases plausible fixes, with higher levels improving performance when lower levels fail.L2-to-L1 gains are more pronounced than L3-to-L2 because L2 adds agents and tool use, while L3 adds reference solutions and cross-file information; Helper adds 46 plausible fixes, underscoring that internet search alone may not supply solutions.Source: §4.4.1 · p. 8, Table 2 · p. 8

4.4.2 Impact of External Interactions

• External interactions, including testing feedback to FixerPro and toolbox use, add 23–121 plausible fixes on Defects4J.The reported gains support the contribution of environment interactions to debugging quality.Source: §4.4.2 · p. 8, Table 4 · p. 8

5 Conclusion

• UniDebugger is presented as the first end-to-end framework using LLM-based multi-agent synergy for unified software debugging.Its three-level architecture manages cognitive steps with minimal communication and dynamically adapts to bug complexity.Source: §5 · pp. 8–9
• 1.25–2.56× bugs are fixed on the repo-level benchmark, UniDebugger fixes all QuixBugs bugs, and its lite version achieves the most plausible fixes on the other two competition benchmarks.The paper also reports that UniDebugger outperforms state-of-the-art repair approaches and base LLMs across four benchmarks.Source: §5 · p. 9
• The effective implementation of Hale and Haworth’s cognitive model for debugging opens pathways for research on LLM-based multi-agent frameworks for complex coding tasks.Source: §5 · p. 9

6 Limitation

• UniDebugger assumes failing test cases guide fault localization and repair, using tests as the primary oracle to validate fixes in a test-driven workflow.The paper frames this as matching developer workflows and a structured, reproducible evaluation setting.Source: §6 · p. 9
• Extending UniDebugger to issue-driven repair, such as SWE-bench, would require natural-language understanding and reproducing user-described failures; this remains future work.Issue-driven repair often lacks explicit test cases or formal specifications, unlike test-driven APR.Source: §6 · p. 9
• Effectiveness on broader bug classes, including configuration errors, remains unknown; future work includes reducing token use, improving adaptability, and integrating external tools more smoothly.The stated goals are faster and more reliable debugging through smoother tool integration.Source: §6 · p. 9

7 Ethics Consideration

• LLM-generated patches may introduce unintended software vulnerabilities or errors, so the authors urge caution, especially in production, and thorough validation and testing.These measures are presented as ways to mitigate negative consequences.Source: §7 · p. 9
• The authors state that they adhere to the license agreements of the LLM models and open-source tools mentioned.Source: §7 · p. 9

• Codeflaws, QuixBugs, ConDefects, and Defects4J are academic datasets created to evaluate program repair techniques.Source: §8 · p. 9
• Baseline APR tools, including Angelix, Semfix, and CoCoNuT, are used according to their original research implementations.Source: §8 · p. 9
• LLM backbones such as gpt-4o and claude-3.5-sonnet are accessed through official APIs under research-only agreements.Source: §8 · p. 9
• SonarQube and GZoltar are used as open-source static-analysis utilities under their LGPL licenses.Source: §8 · p. 9

A.1 Unique Fix Example

• The appendix illustrates UniDebugger's ability to fix a bug that was not fixed by the other methods discussed.Source: §A.1 · p. 14
• The example bug requires adding missing code to process a branching condition, which failing-test-coverage fault localization cannot directly identify.The appendix introduces it as a bug fixed only by UniDebugger.Source: §A.1 · p. 14
• Template-based and NMT-based repair tools handle common syntax or simple logic errors but struggle to generate new business logic.Source: §A.1 · p. 14
• Repairing the bug also requires understanding Jackson deserialization features defined in the databind.DeserializationFeature package.Source: §A.1 · p. 14
• Previous LLM-based repair often relies on local prompt context and statistical correlation, limiting comprehension of other project files.UniDebugger's three repair levels access related repository information and testing feedback.Source: §A.1 · p. 14
• UniDebugger correctly fixes a complex bug by combining extra repository information, testing feedback, and divide-and-conquer reasoning.Its three repair levels provide access to templates and repository-level documents while enhancing reasoning ability.Source: §A.1 · p. 14

A.2 Alogrithm of UniDebugger; A.3 System Prompts

• The appendix provides the framework’s pseudocode and the specific system prompts for its seven agents.The prompts are presented individually, including prompts for Helper, RepoFocus, Summarizer, Slicer, Locator, Fixer, and FixerPro.Source: §A.2 · p. 14, §A.3 · p. 14, Figure 7 · p. 17

A.4 A Demo of the Execution

• The appendix says UniDebugger initializes its agents with bug information and demonstrates a real-world Defects4J bug at level-3 repair.The example bug is Lang-1.Source: §A.4 · p. 14, §A.4.1 · p. 14

A.4.1 Bug Metadata

• JUnit failure information and the buggy file exposed a missed hexadecimal range case: 16-digit values beginning above 7 can exceed Long’s range, with similar issues for int.The appendix identifies NumberUtils.java as the bug-located file and points to the failing test oracles.Source: §A.4.1 · p. 14, Figure 14 · p. 24, Figure 15 · p. 25

A.4.2 L3 Repair

• Helper generated a short debugging guide from the test information and buggy code for the other agents to use.The example presents this as part of the level-3 repair process.Source: §A.4.2 · p. 14, Figure 17 · p. 26

A.2 Alogrithm of UniDebugger; 11 End; 27 End; 37 End

• The repair pseudocode accepts attempt limits and bug metadata, tests candidate patches, and includes a FixerPro refinement step.The extracted algorithm also shows L3 file summarization before invoking L2 repair, and testing checks within the debugging flow.Source: §A.4.2 · p. 15, §11 · p. 15, §27 · p. 15

27 End

• RepoFocus listed bug-related files, and Summarizer produced a code summary for each identified file.The example notes that two additional files would not affect number creation except in particular exception-handling or Unicode-parsing cases.Source: §27 · p. 15, §56 · p. 16

56 End

• Slicer narrowed the 1,427-line buggy code to 168 suspicious lines, from which Locator pinpointed the root causes.This let subsequent agents focus on the relevant logic conditions.Source: §56 · p. 16, Figure 20 · p. 27, Figure 21 · p. 28
• FixerPro corrected Fixer’s Lang-1 patch by counting significant hexadecimal digits and adjusting the 16-digit and 8-digit boundary checks.Fixer’s attempt mishandled strings with many leading zeros and compared raw string lengths; FixerPro’s version considers only significant digits when checking Integer and Long ranges.Source: §56 · p. 16, Figure 22 · p. 29, Figure 23 · p. 30