This report, written by researchers at ByteDance with a co-author from the Harbin Institute of Technology (Shenzhen), introduces MarsCode Agent, a framework that uses LLMs to automate bug fixing in real-world code repositories. The authors start from the observation that fixing bugs in real projects requires understanding complex codebases, dependencies between files and context-specific issues, and that developers’ tasks — failing tests, output that does not match expectations, feature extensions, simple defect fixes — cannot all be handled well by one fixed approach.
Their answer is a multi-agent collaboration framework with six roles (Searcher, Planner, Reproducer, Programmer, Tester and Editor), each given only the tools its task needs. The Planner classifies each issue into either a dynamic debugging workflow, in which a reproduction script is run in a Docker-based sandbox and the Programmer iterates until the Tester confirms the issue is resolved, or a static repair workflow, in which the Editor generates several candidate fixes and a vote selects one. Supporting this are code retrieval through a code knowledge graph and the language server protocol, an edit tool called AutoDiff, and LSP-based static diagnostics of each edit.
Evaluated on SWE-bench Lite, the report states that MarsCode Agent resolved 102 of the 300 issues (34%), and it compares its file and code-snippet localization with other publicly traceable solutions.
Key Points
- The framework allocates a static or a dynamic solving pipeline to each issue according to its nature, instead of using one fixed approach for every issue.
- Agents are deliberately not given every tool: each role’s toolset is limited to reduce the difficulty of each phase and improve stability.
- A code knowledge graph, built with program analysis over code and documentation, represents code entities as vertices and their relationships (calls, references, inheritance, file structure) as edges; the report states it supports 12 programming languages.
- LSP-based retrieval is added to cover definitions outside the target project and same-named entities, with fuzzy positioning because the agent’s numerical positioning is weak.
- The authors report that asking LLMs for unified diffs, for start and end line numbers, or for whole-file rewrites all failed or were impractical in their experience, which led to the AutoDiff edit format modelled on Aider’s approach.
- On SWE-bench Lite, the report states 102 of 300 issues resolved (34%), correct file localization in 265 of 300 (88.3%) and correct code-snippet localization in 206 of 300 (68.7%).
- 84 of 300 issues (28%) were judged suitable for dynamic solving and 216 (72%) for static solving; dynamic debugging resolved 32 of 84 (38.1%) and static repair 70 of 216 (32.4%), which the authors attribute to the reproduction and verification steps in dynamic debugging.
Notes
The evaluation is confined to SWE-bench Lite, a 300-instance subset of SWE-Bench. The report’s own results table lists the share of issues that progressed to static repair as 202 of 300 (72.0%), while its analysis gives 216 of 300; the resolution figures above are the ones stated in the text. The authors list future work on reducing LLM call costs, improving user-agent collaboration, supporting dynamic debugging within real user workspaces to avoid environmental contamination, and improving the accuracy of error localization and code modification. The work belongs to the line of LLM-based Automated Program Repair and Software Issue Resolution systems, and the report situates it alongside SWE-Agent, AutoCodeRover and Agentless.