Beyond Textual Repository Exploration: Dual-Modal Structural Reasoning for Agentic Issue Resolution Jiayi Zhang
Kai Huang∗
Yang Liu
Chunyang Chen
arXiv:2607.01929v1 [cs.SE] 2 Jul 2026
Nanyang Technological University TU Munich Nanyang Technological University TU Munich [email protected] [email protected] [email protected] [email protected]
Abstract—Recent advances in agentic program repair have significantly improved issue resolution by enabling iterative repository exploration. However, existing approaches predominantly rely on sequential, text-based code navigation, which fundamentally limits their ability to reason over large-scale longhorizon repositories with complex and long-range dependencies. As issue-resolution agents traverse repositories through fragmented textual observations, structural information such as module organization, call relationships, and dependency chains must be repeatedly reconstructed across interaction steps, often leading to exploration drift and incomplete localization. We present D UALV IEW, a dual-modal structural scaffolding framework that brings visual reasoning into repository exploration for issueresolution agents. D UALV IEW represents repository structure through four complementary graph views: Module Coupling Graph (MCG), Function Call Graph (FCG), Class Hierarchy Graph (CHG), and Program Dependence Graph (PDG), and exposes them through a queryable interface with visual and textual responses. Rather than reconstructing repository structure from a sequence of textual observations, agents can directly reason over persistent visual representations of code dependencies, enabling more effective exploration and understanding of long-horizon codebases. We evaluate D UALV IEW on SWE-bench Pro and Verified. Results show that D UALV IEW consistently improves issue-resolution performance across different agent architectures and model families. Further ablation studies demonstrate that the gains arise not only from textual structural information but also from visual externalization of repository dependencies, which better supports long-horizon repository exploration. Index Terms—Program repair, issue resolution, multimodal reasoning, code graphs, autonomous agents
I. I NTRODUCTION Recent advances in large language model (LLM)-based agents have substantially advanced automated program repair (APR), enabling autonomous resolution of software issues in real-world repositories [1]–[9]. Given an issue report, these agents iteratively explore the repository, identify the root cause, and synthesize a patch, achieving increasingly strong performance on repository-level issue resolution [10]–[12]. Existing agent systems for issue resolution typically rely on the textual interface for repository exploration. For instance, on SWE-Bench Verified [13], simply reading repository files (via tools such as grep and cat) accounts for 76.1% of a coding agent’s token budget [14], indicating that text-based repository ∗ Corresponding author: Kai Huang ([email protected]).
Text-centric Exploration
Graph-guided Exploration
Linear, fragmented search
Topology at a glance agent bash
VISUAL
FCG · graph view
TEXTUAL
$ grep "reindex_all" reindex_all
…
tasks.py:75
build_doc
$ grep –rn "update_index" update.py:88 update_index()
$ cat views.py
build.py:42
VS
?
io.py:35 update_index(…)
?
… 214 lines …
$ … $ grep "build_doc" → which file? Fragmented textual observations lead to exploration drift and hidden topologies.
◆ FO C U S
run_updates
update_index
cron.py:30
solr/update.py:88
commit cli_main manage.py:18
TE X TUAL DE TAILS
io.py:12
update_index →calls→ build_doc [solr/build.py:42]
Dual-modal graph views make multi-hop dependency chains directly perceptible.
Fig. 1: Text-centric vs. Graph-guided repository exploration. exploration dominates the agent’s workload. In practice, some refine and extend richer file-system and navigation primitives (e.g., purpose-built file viewers, search, and edit commands) to make code legible to the agent [1], [2]. Recent work such as mini-SWE-agent lets the model drive repository exploration through raw shell commands [15]. Another line replaces freeform exploration with structured retrieval over program structure (e.g., abstract syntax trees, hierarchical localization, or repository-level code graphs) whose results are serialized back to the model as text [4], [9], [16]–[18]. Despite these advances, they share a common underlying assumption: that the agent can reconstruct and maintain an accurate understanding of repository structure purely from a sequence of textual observations. As illustrated in Figure 1, existing agents explore repositories through a sequence of textual tool invocations, gradually piecing together structural relationships from fragmented observations. Although repository dependencies are inherently graph-structured, they are typically presented as linear text, leaving the underlying topology implicit. Representing these dependencies directly as graph-structured observations instead makes connectivity and multi-hop relationships immediately perceptible while preserving the semantic information required for subsequent source-level inspection. Therefore, the text-only interface imposes fundamental limitations on issue resolution. Limitation ❶: Repository exploration relies on fragmented textual observations. Issueresolution agents typically explore repositories through textual tools such as file inspection, keyword search, and shell commands [1], [4], [15]. Each interaction reveals only a small fragment of the repository, requiring the agent to gradually accumulate scattered observations across many tool invocations. Since repository relationships span modules, functions,
classes, and statements, agents must mentally reconstruct these structural connections from sequential textual evidence, making repository exploration increasingly difficult as the search space grows. Limitation ❷: Graph-structured repository information is still presented as text. Recent work has begun incorporating structural analyses such as repository graphs, call graphs, and hierarchical localization to guide repository exploration [16], [17], [19]. However, these structural relationships are almost exclusively serialized into textual descriptions or edge lists before being passed to the agent. Although such representations preserve semantic information, they linearize graph topology into sequences of tokens. As dependency structures become deeper and more interconnected, multi-hop paths, branching structures, and densely connected regions become increasingly difficult to perceive, limiting the agent’s ability to reason over long-range repository dependencies. Together, these limitations stem from a common design choice: existing agent systems interact with graph-structured repositories primarily through textual interfaces. Whether exploring repositories via sequential tool invocations or consuming graph analyses serialized as text, agents must reconstruct repository topology from textual observations before reasoning over it. This mismatch between graph-structured repository and textcentric interaction makes long-horizon repository exploration both inefficient and error-prone. Recent advances in multimodal LLMs (MLLMs) demonstrate strong visual reasoning capabilities [20]–[22]. Repository structure is naturally graph-structured, with dependencies among modules, functions, classes, and statements, yet existing agents primarily observe these relationships as sequential text. Visualizing repository graphs makes connectivity, hierarchies, and multi-hop dependency paths directly perceptible, enabling structural reasoning that is difficult to achieve from fragmented textual observations alone. This motivates a shift from text-centric repository exploration toward visual structural reasoning for issue resolution. To this end, we propose D UALV IEW, a dual-modal scaffolding framework that equips agent systems with multi-grained structural views of a repository. D UALV IEW addresses the above challenges through two key design principles. First, it externalizes repair-relevant repository relationships as graphbased structural abstractions, making dependencies directly accessible rather than requiring agents to reconstruct them from fragmented textual observations. Second, it exposes these structures through complementary visual and textual representations. The visual modality preserves topology and longrange structural patterns, while the textual modality provides precise semantic details, enabling agents to jointly reason about repository organization and dependency propagation. D UALV IEW decomposes the repository structure along four classical software-engineering (SE) graphs: Module Coupling Graph (MCG), Function Call Graph (FCG), Class Hierarchy Graph (CHG), and Program Dependence Graph (PDG). These graph views are exposed as parameterized structural probes that agents can invoke on demand. Each query returns a dualmodal response consisting of a rendered visual image and a
concise textual summary, allowing agents to combine visual inspection of structural patterns with textual inspection of semantic details during repository exploration. To evaluate the effectiveness of D UALV IEW, we integrate it into multiple representative agent systems and evaluate on both SWE-bench Pro [11] and SWE-bench Verified [13]. Across different agent architectures and frontier MLLMs, D U ALV IEW consistently improves issue-resolution performance, demonstrating that dual-modal structural reasoning serves as a general enhancement rather than a model-specific optimization. On SWE-bench Pro, D UALV IEW achieves up to 388 resolved instances, improving OpenCode with Kimi K2.5 by 46 additional resolved instances. Ablation studies further show that the gains arise not only from exposing repository structure, but also from how that structure is represented: visualized graphs outperform equivalent textual graph descriptions, while combining visual and textual graph representations yields the strongest performance. These findings suggest that dual-modal structural reasoning provides an effective interface for longhorizon repository exploration and dependency analysis. Specifically, we make the following contributions. • Dual-modal structural scaffolding framework. We propose D UALV IEW, a dual-modal structural scaffolding framework that externalizes repository structure into synchronized visual and textual graph representations. By integrating four complementary structural views, D UALV IEW enables agents to reason across both repository-level organization and finegrained program dependencies. • Comprehensive evaluation. We evaluate D UALV IEW across multiple agent frameworks, foundation models, and benchmarks. Results demonstrate consistent improvements in issue-resolution performance, while ablation studies confirm the complementary benefits of multi-grained structural views and dual-modal structural observations. • Open-source implementation. We release the implementation of D UALV IEW and further package the dual-modal structural reasoning interface as reusable tools and MCP services, to facilitate future research on multimodal repository reasoning and issue-resolution agents [23], [24]. II. A PPROACH This section presents D UALV IEW, a dual-modal structural scaffolding framework for repository-level issue resolution. Figure 2 provides an overview of the workflow. Repositorylevel issue resolution requires iterative repository exploration to collect structural evidence and source-level information for bug localization and repair. Existing agents perform this exploration primarily through textual observations, forcing repository structure to be reconstructed incrementally during reasoning. D UALV IEW augments this process by exposing repository structure as explicit dual-modal structural observations. Specifically, whenever the agent requires structural evidence during repository exploration, it invokes one of the graph-query tools provided by D UALV IEW. Each query extracts a task-specific graph view and returns synchronized visual and textual representations derived from the same graph
DualView Dual-Modal Structural Layer — four complementary graph views
MCG
repository-wide
PLUGGABLE ·EXTERNAL
FCG
cross-function
CHG
PDG
cross-class
in-function
Module Coupling Graph — coupling among modules & subsystems
Function Call Graph — caller / callee propagation paths
Class Hierarchy Graph — inheritance & overriding relations
Program Dependence Graph — statement control / data deps
VISUAL
VISUAL
VISUAL
VISUAL
AbstractSolr if seed:
solr
T EXTUAL
T EXTUAL
T EXTUAL
T EXTUAL
solr → plugins [depends-on] openlibrary/solr ·
update_key → build_data [calls]
AbstractSolr ▷ WorkSolr [overrides]
13 files
update_work.py:472
update_work.py:289
WHERE
Locate the owning subsystem
HOW
Trace behavior propagation
WHICH IMPL
seed = compute(work) [def] if seed: index(seed) [ctrl]
Resolve dispatch
WHICH STMT
Base Agent System native issue-resolution loop
#1837 solr reindex
EXISTING ·UNCHANGED
Reason
Agent Loop (MLLM)
ISSUE REPORT
→ NATIVE TOOLS
Local value flow
read_file
search
bash
run_test
→
Act
→
Observe
native (textual) evidence
REPAIRED PATCH
↻ iterate
→
- index(seed) + if seed: index(seed) update_work.py:476
Fig. 2: Overview of D UALV IEW. slice. The agent combines these dual-modal structural observations with native agent tools to navigate the codebase, inspect implementation details, and progressively localize and repair the bug. The remainder of this section first introduces the graph-view construction, then presents the dual-modal structural representations, and finally describes how D UALV IEW is integrated into existing issue-resolution agents. A. Multi-Grained Structural Views Repository-level issue resolution progressively narrows the search space from repository-level organization to concrete program statements, requiring structural evidence at different levels of abstraction [25], [26]. To support this process, D UALV IEW organizes repository structure into four complementary graph views spanning multiple granularities. These views capture four recurring classes of structural relationships encountered during repository exploration: module coupling, function invocation, class inheritance, and statement-level data/control dependence. Together, the four views provide a coarse-to-fine exploration hierarchy. Agents first identify relevant subsystems, then analyze interprocedural interactions, object-oriented relationships, and finally fine-grained dependencies around candidate implementations. Table I summarizes the four structural views provided by D UALV IEW. To provide a unified interface across views, D UALV IEW exposes them through a common view-query abstraction. Each view is represented as a typed directed graph G = (V, E) and is materialized on demand through a view query: G = V(t, s, θ),
t ∈ {M CG, F CG, CHG, P DG}
(1)
where t specifies the graph view, s is the seed entity (a function, class, or ∅ for the repository-level view), and
θ = ⟨h, δ, α, κ⟩ controls the query scope, including hop radius, expansion direction, optional intra-view focus, and node budget. The agent issues the query through a graph tool, which constructs G from a precomputed code index and returns the rendered view R(G). 1) Module Coupling Graph: To begin this top-down exploration, the agent must first navigate the overarching structure of the software system. Inspired by the concepts of modular programming [27]–[29], modern repositories group functionally related code into distinct modules that interact through clear dependencies. Because of this design, the first logical step in narrowing the search space is identifying which specific module or subsystem is responsible for the reported behavior. To provide structural evidence for this step, we introduce the Module Coupling Graph (MCG) [30]. a) Construction. The MCG is a weighted directed graph GM CG = (Vm , Ec ). Each node v ∈ Vm is a subsystem, obtained by partitioning the main source package into its top-level directories (descending through single-child package nests until a directory exposes at least three source subdirectories). Every subsystem carries a role tag ρ(v) assigned by deterministic path-pattern rules over the directory leaf name (e.g. core, io boundary, tests), a file count, a naturallanguage description mined from its README/package docstring, and its most-imported representative files. A coupling edge (A, B, w) ∈ Ec is induced by cross-subsystem imports, where the weight w(A, B) = |{(fa , fb ) : fa ∈ A, fb ∈ B, fa imports fb }| counts import references from a file in A to a file in B; an edge is retained only when w ≥ τc (e.g., τc =5) and ranked by weight. This yields a compact repositorylevel map in which edge thickness encodes coupling strength. b) Query interface. The agent issues V(M CG, ∅, κ), where
TABLE I: Graph views and parameterized query interfaces exposed to the agent by D UALV IEW. View
Graph Node v ∈ V
Graph Edge e ∈ E
Agent Query Interface V(t, s, θ)
Structural Evidence
MCG
Modules, directories, or package subsystems Functions and methods
Aggregated file-level imports and coupling with direction and weights Caller–callee invocations
Classes, interfaces, and abstract types Statements, predicates, and variable operations
Inheritance, implementation, and overriding Data and control flow dependencies
V(M CG, ∅, κ): no seed; κ caps subsystems V(F CG, f, ⟨h, δ⟩); δ ∈ {callers, callees, both} V(CHG, C, ⟨h, δ⟩); δ ∈ {upstream, downstream, both} V(P DG, f, α); α: optional focus variable / line
Repository organization and neighboring coupled modules Behavioral propagation across functions and files Implementation ownership under object-oriented dispatch Local value flow, branching guards, and state updates
FCG CHG PDG
κ limits the number of returned subsystems. This view serves as the default entry point for exploring a repository. c) Why useful. MCG narrows the search space from the entire repository to a few candidate subsystems while preserving neighboring modules that may also contribute to the issue. 2) Function Call Graph: Once the agent identifies a candidate subsystem, the exploration shifts downward to concrete program entities. However, simply finding a relevant function or method is rarely enough; reading its body in isolation does not reveal where it is called from or how it interacts with the rest of the system. To address this, the Function Call Graph (FCG) [31] exposes the caller-callee paths. a) Construction. The FCG is a directed graph GF CG = (Vf , Ecall ) whose nodes are functions and methods (each with its file and line span) and whose edges u → v denote that u may call v, weighted by a static resolution confidence c(u, v) ∈ [0, 1]. Given a seed function s, D UALV IEW materializes the ego-graph by bounded breadth-first expansion to radius h in direction δ ∈ {callers, callees, both}; expansion is direction-stable (callers continue upward, callees downward) to avoid combinatorial blow-up through hub utilities. Edges below a confidence floor are discarded, and when |Vf | > κ the least important nodes are collapsed into a summary node that reports the count of hidden callers/callees. b) Query interface. The agent issues V(F CG, s, θ) as V(F CG, f, ⟨h, δ⟩), where f is a function (optionally disambiguated by a file hint), h default 2, and δ default both. c) Why useful. FCG exposes the caller–callee context around a suspect function, enabling the agent to trace behavior propagation across functions and files before editing. 3) Class Hierarchy Graph: In object-oriented repositories, issue reports often reference an interface, base class, or abstract method, while the faulty implementation resides in a concrete subclass. To bridge this abstraction gap, we introduce the Class Hierarchy Graph (CHG) [32]. a) Construction. The CHG is a directed graph GCHG = (Vt , Eh ) where nodes are user-defined types (e.g., classes, interfaces, structs) and edges child → parent denote generalized subtype or conformance relations. Because abstraction mechanisms vary across languages, D UALV IEW constructs Eh on a best-effort static basis. Explicit declarations (e.g., extends/implements) are parsed directly from the AST. Conversely, implicit relationships (e.g., Go interfaces) are inferred by statically matching their declared methods. From a seed type C, D UALV IEW performs bounded BFS to radius
h (e.g., 1 ≤ h ≤ 5) in the requested direction, capping wide fan-outs with a summary node to maintain legibility. b) Query interface. The agent issues V(CHG, s, θ) as V(CHG, C, ⟨h, δ⟩), where C is a class name and δ dictates the trace direction (upstream, downstream, or both). c) Why useful. CHG bridges abstract API clues and their concrete implementations, enabling the agent to identify the actual implementation that should be inspected or edited. Together with FCG, it complements behavioral relationships with inheritance structure. 4) Program Dependence Graph: Once the agent reaches a candidate implementation, the remaining task is to identify which control decision or value flow causes the faulty behavior. To support this fine-grained reasoning, we introduce the Program Dependence Graph (PDG) [33]. a) Construction. The PDG is built for a single function as GP DG = (Vs , Ed ∪ Ectl ). Each node v ∈ Vs is a toplevel statement, annotated with the variables it defines and uses and its source line. A branch, loop, or try together with its body forms one node. A data-dependence edge Ed connects a definition to a later use of the same variable, where each use is linked to its nearest preceding definition, and the edge is labeled with the carried variable. A conditional edge Ectl connects a compound predicate (if/for/while) to each later statement that uses a name bound inside its body. Statements are extracted from the AST by per-language front-ends (Python ast; tree-sitter for Go, JavaScript, and TypeScript) and emitted through a shared assembler, so the dependence analysis is identical across languages. This analysis is lightweight, focusing on the dominant data and control paths rather than exhaustive intra-procedural coverage. An optional focus α slices the graph to the h-hop neighborhood of a variable or line, and the result is capped at κ statements by retaining the most-connected dependency core. b) Query interface. The agent issues V(P DG, s, θ) as V(P DG, f, α), where f denotes the seed function and α optionally specifies a variable or source line of interest. c) Why useful. PDG exposes statement-level data and control dependencies, enabling the agent to identify the value flow or control decision responsible for a defect before editing. Together, these four views follow the narrowing logic of repository exploration: MCG guides repository-level orientation, FCG and CHG connect candidate symbols to relevant implementations, and PDG focuses reasoning on statementlevel dependencies. Importantly, this top-down progression
reflects the inherent structural hierarchy of the software, rather than a mandatory execution pipeline. Depending on the initial issue report and intermediate findings, the agent can flexibly enter the exploration at any level and dynamically switch between views as needed.
⬡ Visual Structural Representation
CALLERS
periodicFunctions
reportClusterStats
srv.go:384
srv.go:452
FCG
◆ QUERY FOCUS
FOCUS
GetSites srv.go:934
B. Dual-Modal Structural Observations Modern MLLMs can jointly reason over visual and textual inputs, yet the two modalities offer complementary strengths for structural reasoning [34], [35]. Rather than relying on a single representation, D UALV IEW exposes every queried repository graph through synchronized visual and textual observations. Both observations are derived from the same graph slice and therefore represent the same structural context. The visual modality emphasizes topology perception, whereas the textual modality provides the semantic grounding required for precise repository navigation and repair. The following subsections describe the two representations in detail. 1) Visual Structural Representation: The visual representation prioritizes preserving repository topology rather than maximizing semantic density. By rendering each graph slice as a node-link diagram, structural organization, connectivity, and dependency patterns become directly observable, preserving relationships that are otherwise flattened by textual serialization. To maintain a compact and readable layout, D UALV IEW displays only lightweight node labels (e.g., symbol name, file name, and line number) while relocating complete semantic information (e.g., full paths and dependency attributes) to the synchronized textual representation. This design allows the visual modality to emphasize structural perception without cluttering the graph. Although both modalities encode the same graph, the visual layout makes several structural cues immediately perceptible: • Global Organization. Spatial grouping reveals subsystem boundaries, clusters, and highly coupled regions, helping agents quickly orient themselves within the repository. This cue is particularly useful for the MCG. • Dependency Topology. Node-link layouts expose multi-hop propagation paths, fan-in/fan-out patterns, bridge nodes, and densely connected regions without reconstructing connectivity from sequential text. This property is most evident in the FCG and PDG. • Structural Alternatives. Visual layouts present inheritance hierarchies, alternative callees, and control-flow branches simultaneously, facilitating direct comparison of competing implementations or execution paths. This cue is particularly useful for the CHG and PDG. Overall, the visual modality enables agents to perceive repository topology directly, providing structural guidance that complements conventional text-based repository exploration. 2) Textual Structural Representation: The textual representation complements the visual modality by preserving semantic information that cannot be compactly encoded in graph layouts. While visual observations emphasize topology, D UALV IEW serializes the same graph slice into a structured representation that grounds every visual node and edge in the
around GetSites · dir=both · hops=2
CALLEES
GetName
GetName
GetName
forwarder_test.go:979
fake.go:84
cluster.pb.go:112
▤ Textual Structural Representation
# FCG around GetSites (dir=both, hops=2) 6 nodes · 5 edges ## CALLERS — who calls GetSites − periodicFunctions [lib/reversetunnel/srv.go:384] —calls→ reportClusterStats − reportClusterStats [lib/reversetunnel/srv.go:452] —calls→ GetSites ## CALLEES — what GetSites calls − GetSites —calls→ GetName [lib/kube/proxy/forwarder_test.go :979] − GetSites —calls→ GetName [lib/reversetunnel/fake.go :84] − GetSites —calls→ GetName [lib/teleterm/api/protogen/golang/v1/cluster.pb.go :112]
Fig. 3: Dual-modal observation of D UALV IEW. underlying repository. The textual representation records four categories of source-grounded information: • Entity Identity. Each graph node is mapped to its exact repository entity, allowing symbols with identical display names to be distinguished unambiguously. This information is particularly important for the FCG and CHG, where overloaded methods, inherited implementations, or repeated class names frequently appear across different files. • Source Grounding. Each entity is associated with its file path and code location, enabling the agent to directly inspect the corresponding implementation. This grounding is shared across all graph views, allowing structural observations at different granularities to be traced back to source code. • Relation Semantics. Each graph relation is serialized as a structured dependency statement, preserving the semantics of module coupling (MCG), function invocation (FCG), inheritance (CHG), and data/control dependence (PDG). • Query Context. Additional metadata, including traversal direction, expansion depth, and graph statistics, record how the graph slice was extracted. These contextual cues help the agent interpret the scope of each queried structural view. Overall, the textual modality grounds structural observations in concrete repository entities, enabling the agent to seamlessly translate high-level structural evidence into sourcelevel actions such as locating implementations, inspecting dependencies, and editing the correct code. 3) Dual-Modal Observation in Practice: Figure 3 illustrates the dual-modal response returned for the same FCG query. Both the visual graph and the textual serialization are generated from an identical graph slice, ensuring that they expose the same structural information while emphasizing complementary aspects of repository reasoning. In the visual structural representation, the agent can immediately observe a caller chain from periodicFunctions to reportClusterStats and then to GetSites, as well as a downstream fan-out from GetSites to three GetName callees. This structure suggests
structural track, the following state-driven conditions further guide the agent to invoke the most appropriate graph view:
REASONING TRACE · evidence / step
Current Repair Context issue · native/dual-modal observations
Subsystem Orientation. At the initial stage of repository exploration, the agent often lacks clear modular organization. To map the issue description to high-level components, the protocol recommends querying the MCG. This repowide view identifies candidate subsystems and coupling relations before fine-grained inspection begins. • Function Propagation. If the agent isolates a suspicious function but its upstream or downstream role is unclear, the protocol triggers the FCG. This cross-function view traces multi-hop propagation chains, exposing caller-callee paths and impact boundaries. • Hierarchical Resolution. Clues pointing to an abstract class or interface often indicate that the actual faulty behavior resides elsewhere. To resolve this abstraction, the protocol directs the agent to query the CHG, which explicitly identifies concrete subclass implementations. • Local Dependencies. Having narrowed the focus to one specific implementation, the agent must identify the exact faulty state update or predicate. The protocol then suggests the PDG to expose statement-level control and data dependencies, allowing the agent to reason about variable flows before editing code contents. •
Evaluate Current Reasoning State ↻ ADAPTIVE SELECTING
Native Tool Execution
native agent tools
Focus on concrete source-level inspection/execution
TOOLS OBS
inspect
search
edit
run_test
Native Observation — source snippets · error messages · test outputs
Structural Graph Views
DualView graph views
Focus on repository structure MCG
Subsystem Orientation repo-wide
FCG
Function Propagation
cross-fn
WHEN Lacks clear modular organization
WHEN Function’s upstream/downstream is unclear
→ Identify candidate subsystems & coupling
→ Trace multi-hop propagation chains
CHG
Hierarchical Resolution cross-cls
PDG
Local Dependencies
WHEN Relates to abstract class
WHEN Narrowed to one implementation
→ Resolve concrete subclass implementations
→ Expose control / data dependencies
OBS
Dual-Modal Observation — Visible Topology · Grounded-Details
Visual
in-fn
Textual
Fig. 4: Adaptive reasoning procedure of D UALV IEW. that the behavior around GetSites may need to be understood both from its upstream use and from its downstream helper calls. The textual structural representation grounds the same structure in concrete source locations. It separates callers from callees, records each relation as a calls edge, and provides full paths and line numbers. Specifically for the three GetName callees, which share the same short name but are distinguished by the file name as the unique identifier. Thus, the agent can use the image to identify the relevant dependency pattern and then use the text to inspect the exact files and lines involved. C. Adaptive Structural Reasoning To make effective use of the multi-grained structural views and dual-modal structural observation, we propose an adaptive structural reasoning layer inside the agent’s original repair loop. As illustrated in Figure 4, issue resolution can be considered as a process of gradually turning an issue report into repair actions by collecting a series of evidence within the repair contexts [4], [10]. Existing agents rely exclusively on Native Tool Execution (e.g., source inspection, search) to focus on concrete source-level facts. D UALV IEW expands the agent’s action space by exposing four Structural Graph Views to satisfy the need for repository structure. Specifically, the agent continuously evaluates its current reasoning state by analyzing its gathered context. If its reasoning focuses on concrete source-level actions, the agent relies on Native Tool Execution (e.g., inspect, search, edit). Conversely, when the agent requires repository structural context to proceed, it transitions to Structural Graph Views. Within this
The reasoning process is therefore adaptive rather than fixed. An agent may begin with the MCG to identify a relevant subsystem, switch to native tools to inspect candidate code, invoke the FCG or CHG to refine structural hypotheses, and finally use the PDG for statement-level analysis. Each graph query returns synchronized visual and textual observations, enabling the agent to alternate naturally between structural reasoning and source-level inspection throughout issue resolution. D. Integration with Existing Agents To make the adaptive reasoning mechanism applicable to existing repair systems, D UALV IEW is implemented as an agent-agnostic structural reasoning layer. Existing agents invoke graph queries through their native tool interfaces. For mini-SWE-agent [15], graph queries are exposed as shell commands that naturally fit its bash-centric interaction loop. For OpenCode [36], the same functionality is provided through an MCP server. Since both interfaces preserve the original interaction workflow, integrating D UALV IEW requires only minimal modifications to existing agents. III. E XPERIMENT S ETUP A. Research Questions RQ1: Can D UALV IEW consistently enhance the repair capability of existing agent systems? (Overall Effectiveness) RQ2: How do multi-grained views and dual-modal observations contribute to D UALV IEW? (Ablation Study) RQ3: How well does D UALV IEW generalize to additional issue resolution benchmarks? (Generalizability Study)
B. Benchmarks SWE-bench Pro [11] is used for RQ1 and RQ2. Its Public split contains 731 long-horizon issue-resolution instances. Note that we conduct ablation studies on a 150-instance randomly selected subset of SWE-bench Pro. Evaluating multiple variants on the full benchmark would incur substantially higher costs, while the subset provides a widely adopted setting for analyzing the contribution of individual components. SWE-bench Verified [13] is used for RQ3 to evaluate generalizability. It contains 500 task instances collected from real GitHub repositories and has been widely adopted to assess the repair capabilities of repair agents or base models. We use it to examine whether the benefits of visual structural reasoning transfer across benchmarks with different repository characteristics, issue distributions, and task compositions.
TABLE II: Improvements of D UALV IEW with different agent scaffolds and base models on SWE-bench Pro public. Repo
Num
mini-SWE-agent Claude 4.5 Sonnet base
f ull
base
f ull
base
f ull
ansible (Py) openlibrary (Py) qutebrowser (Py) teleport (Go) flipt (Go) vuls (Go) navidrome (Go) webclients (JS) element-web (JS) NodeBB (JS) tutanota (TS)
96 91 79 76 85 62 57 65 56 44 20
51 47 49 29 30 33 23 35 30 17 11
55 54 51 35 29 27 25 36 32 19 12
47 41 45 25 29 27 22 28 18 24 10
55 40 47 28 31 32 22 33 29 24 10
45 46 50 30 28 26 23 33 22 27 12
47 52 53 32 33 39 25 36 30 30 11
#Total Resolved (731) $Avg. Cost
355 $0.94
375↑20 $0.89↓0.05
316 $1.40
351↑35 $1.36↓0.04
342 $0.55
388↑46 $0.50↓0.05
We evaluated D UALV IEW against two categories of baselines to systematically isolate our identified limitations. First, we select four representative text-centric agent systems: SWEagent [1], mini-SWE-agent [15], Live-SWE-agent [7], and OpenCode [36]. All of them rely primarily on text-based repository exploration. Second, to compare the closest textual graph-structured repository representation approaches, we select RepoGraph [16] and CodeGraph [17], both of which can be plugged into existing agent systems, making them the most direct baselines for evaluating the effectiveness of our proposed dual-modal structural observations. D. Experimental Configurations Since D UALV IEW is designed as a repository exploration plugin rather than a standalone issue-resolution agent, our evaluation focuses on measuring the improvement it brings to existing agent systems. We consider two representative opensource systems: mini-SWE-agent [15] represents lightweight research-oriented agent systems, and has become one of the most widely adopted foundations for issue-resolution research. OpenCode [36] represents modern open-source coding agents with a different interaction paradigm and repository exploration workflow. To evaluate the generality of D UALV IEW across base models, we instantiate each scaffold using Claude 4.5 Sonnet [37] and Kimi K2.5 [38] on SWE-bench Pro. For the cross-benchmark study on SWE-bench Verified, we additionally use Gemini 3 Flash [39] due to its low-cost multimodal support. IV. E VALUATION A. RQ1: Overall Effectiveness 1) Controlled Study: We first evaluate D UALV IEW through controlled comparisons in which the agent system and base model are fixed, and the only difference is whether dual-modal scaffolding is enabled. As shown in Table II, base and f ull denote the original and D UALV IEW-enabled agents respectively. Across all three settings, integrating D UALV IEW consistently improves issue-resolution performance. When built on top of mini-SWE-agent with Claude 4.5 Sonnet, D UALV IEW
OpenCode Kimi K2.5
TABLE III: Comparison with representative agent baselines. Agent System
C. Baselines
OpenCode Claude 4.5 Sonnet
Resolved
%Resolved
$Avg. Cost
OpenCode OpenCode
Base Model Kimi K2.5 Claude 4.5 Sonnet
342 316
46.8% 43.2%
$0.55 $1.40
mini-SWE-agent Live-SWE-agent [7] SWE-agent [40]
Claude 4.5 Sonnet Claude 4.5 Sonnet Claude 4.5 Sonnet
355 335 319
48.6% 45.8% 43.6%
$0.94 $0.73 N/A
D UALV IEW@OpenCode D UALV IEW@OpenCode D UALV IEW@mini-SWE-agent
Kimi K2.5 Claude 4.5 Sonnet Claude 4.5 Sonnet
388 351 375
53.1% 48.0% 51.3%
$0.50 $1.36 $0.89
increases the number of resolved instances from 355 to 375 (+20, 5.6%) while slightly reducing the average cost from $0.94 to $0.89. The improvements become more pronounced on OpenCode. Under Claude 4.5 Sonnet, D UALV IEW raises the number of resolved instances from 316 to 351 (+35, 11.1%), while reducing the average cost from $1.40 to $1.36. When replacing the base model with Kimi K2.5, the number of resolved instances further increases from 342 to 388 (+46, 13.5%), again with a lower average cost ($0.55 to $0.50). These isolated configurations demonstrate that the benefits of D UALV IEW are consistent across both agent scaffolds and base models. 2) Baseline Comparison: Table III further compares D U ALV IEW with representative issue-resolution agents. Across both OpenCode and mini-SWE-agent configurations, the D U ALV IEW -enabled agents consistently achieve the best repair performance under identical foundation models, outperforming existing text-centric agent systems. Beyond comparing with complete agent systems, we compare D UALV IEW with graph-based repository exploration methods, which are the closest alternatives to our structural scaffolding framework. RepoGraph [16] represents repository structure as textual graph retrieval and can be integrated into existing agents. Since it currently supports only Python repositories and is not released as an MCP service, we integrate it into mini-SWE-agent and evaluate both methods on the 266 Python instances in SWE-bench Pro. We additionally compare with CodeGraph [17], another graph-based repository exploration system released as an MCP service. Unlike RepoGraph, CodeGraph natively supports multiple languages via MCP. We therefore integrate it into OpenCode and evaluate it on the full