Skip to content

PhoenixRepair: Rethinking Repair Strategy Exploration in Software Agents

🕒 Published (v1): 2026-07-21 08:49 UTC · Source: Arxiv · link

Why this paper was selected

Daya Guo (DeepSeek); novel repair-strategy exploration for software-agent issue resolution

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

PhoenixRepair is a multi-agent framework for automated software issue resolution that addresses two core deficiencies in existing approaches: insufficient exploration of candidate edit locations and insufficient iterative refinement at each location. It achieves 76.0% Pass@1 on SWE-bench-Verified under MiniMax-M2.5, the highest reported resolved rate among compared methods.

Problem

Existing agent-based issue-resolution methods commit prematurely to a single edit location during fault localization. Probabilistic LLM sampling bias causes repeated trajectories to cluster at high-confidence (but potentially incorrect) locations, and even correct-location attempts often fail because a single repair pass is insufficient. Two distinct gaps: (P1) limited diversity across candidate edit locations, and (P2) limited iterative reflection within each location.

Method

PhoenixRepair extends SWE-agent with three sequential phases:

  1. Multi-location sampling: A localization sampling agent runs \(N\) sequential iterations, using previously identified locations \(\{\ell_1, \ldots, \ell_{i-1}\}\) as negative references in iteration \(i\) to force exploration of alternatives. Duplicates (same file, same program entity, overlapping line range) are removed to yield \(L'\). For tasks where \(|L'| > k\) (hard localization), a graph-based localization agent (LocAgent) constructs a heterogeneous repository graph (imports, call graphs, inheritance hierarchies), ranks code entities via cross-iteration confidence estimation, and augments \(L' \cup L_{\text{graph}} = L''\) after deduplication.

  2. Iterative reflection and refinement: A coder agent generates one patch per location in \(L_{\text{final}}\). A selection agent ranks patches by a weighted combination of (a) Reproduction & Edge Test Quality \(Q_{\text{test}}(\tau_i)\) — assessed on a compressed trajectory — and (b) Regression Test Pass Rate \(R_{\text{pass}}(p_i)\) — measured against a filtered regression set \(T_{\text{final}}\). The top \(\lceil w/2 \rceil\) locations are retained; the loop repeats until one location remains.

  3. Final-round generation: An analysis agent distills insights from all historical trajectories at the surviving location \(\ell_{\text{final}}\) and injects guidance into the coder agent's system prompt for final patch generation.

Key Contributions

  • Multi-location sampling with sequential negative-reference prompting to break LLM locality bias in fault localization.
  • Graph-based localization augmentation (heterogeneous repo graph with multi-hop dependency traversal) activated adaptively for hard tasks.
  • Iterative patch selection loop using dual quality signals (test quality + regression pass rate) with trajectory compression to reduce noise.
  • Distilled-guidance injection at the final round leveraging full attempt history.
  • Demonstrated plug-in generalizability: the mechanisms integrate into Mini-SWE-agent and Live-SWE-agent with consistent gains.

Results

  • 76.0% Pass@1 on SWE-bench-Verified (500 tasks) with MiniMax-M2.5 — highest reported among all compared methods.
  • +7.8% relative over SWE-agent under DeepSeek-V3.1 (66.0% vs. 61.2%).
  • +7.2% relative over SWE-agent under DeepSeek-V3.2 (74.4% vs. 69.4%).
  • +6.4% relative over SWE-agent under both Qwen-Coder-Plus (69.6% vs. 65.4%) and GLM-4.7.
  • +5.3% relative over SWE-agent under MiniMax-M2.5 (76.0% vs. 72.2%).
  • +9.1% to +11.9% relative over Agentless across all model configurations.
  • Fault localization (DeepSeek-V3.2): File Acc@1 85.64% (+3.13% over SWE-agent), Module Acc@1 76.82% (+3.50%), Function Acc@1 66.64% (+5.08%).
  • Fault localization (Qwen3-Coder-Plus): File Acc@1 82.24% (+3.29%), Module Acc@1 74.22% (+3.11%), Function Acc@1 64.42% (+5.19%).

Limitations

  • Compute overhead is higher than single-attempt baselines due to multi-location sampling (\(N\) iterations), iterative refinement loops, and graph construction; RQ5 results on inference cost are referenced but not included in the provided text.
  • Graph-based localization relies on LocAgent, an external dependency not fully described here, which may introduce its own failure modes.
  • Evaluation is confined to SWE-bench-Verified (500 tasks); generalization to other benchmarks or proprietary codebases is untested.
  • The hard-task threshold \(k\) and graph-entity count \(l\) are manually tuned hyperparameters (set to 4 and 2 respectively), with sensitivity analysis not shown in the provided text.
  • Trajectory compression heuristics (merging repeated failures) could suppress diagnostic signals in edge cases.

Relevance to Agentic AI / LLM Agents

PhoenixRepair directly targets a fundamental failure mode of agentic LLM systems — the tendency of probabilistic sampling to collapse onto high-confidence but incorrect action sequences — and proposes a principled multi-agent solution combining location diversity, iterative self-reflection, and distilled-history guidance injection. The approach is a practical instance of test-time compute scaling for agents: rather than simply running more parallel samples, it structures the search with progressive elimination and knowledge accumulation across rounds. The plug-in generalizability to Mini-SWE-agent and Live-SWE-agent shows that the core mechanisms (diversified exploration, reflective refinement) are scaffold-agnostic and applicable to the broader class of tool-using LLM agents operating on long-horizon software tasks.