Warehouse-level code merge conflict automatic resolution method based on agent workflow

Abstract

The application relates to the field of artificial intelligence and software engineering automation, in particular to a warehouse-level code merging conflict automatic resolution method based on an agent workflow, which comprises the following steps: initializing an agent tool set, wherein a code attribute graph tool is used to obtain context information of a conflict block at a warehouse level; then, a fine-tuned code large model is used for conflict block feature classification, and the agent subsequently selects a suitable tool according to the conflict type obtained through classification; subsequently, similar historical conflict cases in the warehouse are obtained as a reference for the agent to resolve the current conflict; finally, a dynamic circulation process is entered, a tool scheduling request is generated based on the state of a conflict information pool, and a verification and execution tool is used until a task termination condition is met, and a conflict resolution scheme is output. Through the introduction of a conflict block feature type and a warehouse-level conflict context, the application provides an automatic code merging conflict resolution scheme.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and software engineering automation, specifically to a method for automatically resolving warehouse-level code merging conflicts based on intelligent agent workflow. Background Technology

[0002] The Git version control system typically uses the diff3 algorithm, also known as the recursive three-way merge algorithm, when performing line-by-line merges using the "git merge" command. This process treats source code files as lines of code, ignoring semantic information and comparing two versions only at the line level. Specifically, given two modified development branches A and B, and their common base version O, the diff3 algorithm initiates a bidirectional difference comparison by aligning the version of branch A or branch B with version O at the line level, and then temporarily stores these changes. However, when both A and B have modified the same line, automatic reconciliation becomes impossible. In this case, the diff3 algorithm generates a conflict file, requiring manual intervention. The conflict content, or conflict block, is the portion between "<<<<<<<" and ">>>>>>>", which needs to be reviewed and resolved by the developer. However, manually resolving merge conflicts is time-consuming and labor-intensive.

[0003] Existing conflict resolution tools also have certain limitations. First, existing research largely focuses on summarizing and classifying solutions to historically existing conflict blocks. However, regardless of whether solutions are categorized into five or nine types, the solution space is pre-limited to a limited number of strategies, making it difficult to adapt to complex and ever-changing real-world conflict scenarios. Second, existing solutions tend to use a single tool to handle all conflict blocks, ignoring the inherent differences in conflicts caused by variations in code structure, semantic context, or modification type. Different solutions should be adopted based on the characteristics of the conflict block itself. Third, existing conflict resolution tools typically limit the analysis scope to the conflict block itself, failing to effectively incorporate the contextual information of the conflict block. Most current methods only use the conflict block as input, or only consider a few lines before and after it as local context, failing to cover the semantic environment at the function, module, or project level. This localized approach may lead to the loss of key semantic information or even introduce misleading signals, thereby reducing the accuracy and reliability of the resolution strategy. Summary of the Invention

[0004] The purpose of this invention is to provide an automated method for resolving repository-level code merging conflicts based on intelligent agent workflow, so as to solve the problems mentioned in the background art.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0006] An automated code merging conflict resolution method based on agent workflow, using three conflicting segments as input, includes the following steps:

[0007] S1. Obtain conflict block metadata and initialize the agent toolset and conflict information pool;

[0008] S2. Input the three-way merged conflict fragments into the fine-tuned pre-trained code large model, classify the conflict block features, output the conflict type confidence ρ and conflict label y, and record them in the conflict information pool.

[0009] S3. Based on the repository address of the current conflicting block, retrieve the top-k similar historical conflicting blocks using similarity matching, and write the corresponding solutions into the conflict information pool.

[0010] S4. If the type label y output by the model in S2 belongs to a predefined subset of labels, the tools in the agent toolkit are called in sequence to obtain the warehouse-level conflict context, and then the dynamic scheduling loop is entered. Otherwise, if it does not belong to the subset, the dynamic scheduling loop is entered directly.

[0011] S5. Generate a structured tool scheduling request based on the state information in the conflict information pool, input it into the large language model, and obtain the target tool or task termination instruction to be executed by parsing the output of the large language model.

[0012] S6. Tool scheduling constraint verification: Based on the conflict type label y in the conflict information pool and the field of the called tool list, perform call order legality verification, uniqueness verification and termination legality verification on the target tool to be executed.

[0013] S7. Termination condition judgment and result output. The preset termination conditions include reaching the maximum number of tool iterations T or obtaining the task end instruction. When the preset termination conditions are met, the final conflict resolution solution is output and the processing flow ends. Otherwise, the next round of scheduling is entered, and S5 is repeated until the preset termination conditions are met.

[0014] Preferably, the intelligent agent toolset in step S1 includes: data acquisition tools, data processing tools, and scheduling and control tools within the warehouse scope;

[0015] Repository-wide data acquisition tools include: tools for building repository code property graphs, tools for obtaining the three lines of code before and after a conflict block, tools for obtaining commit messages, tools for obtaining the parent commit of a conflict, tools for obtaining author information, and tools for obtaining pull requests;

[0016] Data processing tools include: tools for building lexical-level conflict blocks and code summarization tools;

[0017] Scheduling and control tools include: feedback tools, parsing tools, and termination tools;

[0018] The tool for constructing repository code attribute graphs downloads the complete repository source code using the URL address of the repository where the conflict block is located. Based on static program analysis technology, it constructs a code attribute graph G=(V,E) containing code structure relationships, call relationships, and data dependency relationships. Starting from the node set corresponding to the conflict code, it slices the code attribute graph according to the preset slice radius r and depth dependency d to obtain a context subgraph G_c, thus obtaining the repository-level conflict context.

[0019] The tool for constructing word-granular conflict blocks and the code digest tool split the specific edited content of the three versions of the original line-granular conflict block into independent words for each line, place each word in the corresponding version file, and then apply the diff3 algorithm to perform a three-way merging operation on the three files to obtain word-granular conflict blocks.

[0020] The feedback tool reads some fields from the information pool, including the conflict type label y, the return results of the invoked tools, and the list of uninvoked tools, generates a problem description, and sends a tool scheduling request to the agent.

[0021] The parsing tool is responsible for parsing the response results of the large language model, obtaining the target tool or task termination instruction to be executed, and outputting the final conflict resolution solution.

[0022] Preferably, the conflict information pool in step S1 records at least the following fields:

[0023] The content includes the conflict block identifier (id), the original conflict block content, the URL of the repository containing the conflict block, the conflict commit hash, the file path of the conflict block, the list of tools called, the list of tools not called, and the input and output data of the tools called.

[0024] Preferably, step S2 specifically includes:

[0025] The finely tuned pre-trained code large model receives the original conflict block and outputs a predicted probability distribution vector. The value at each position of the vector corresponds to the confidence of a conflict type. The maximum value in the vector is taken as the highest confidence ρ. When ρ < 0.6, the corresponding conflict is marked as requiring manual review, and the highest confidence ρ and the corresponding conflict label y are recorded in the conflict information pool.

[0026] Preferably, the conflict label y is one of the predefined conflict type label sets Y;

[0027] The predefined conflict type label set Y contains at least seven conflict types: comment or string conflict, import or dependency conflict, function or class conflict, variable conflict, code formatting conflict, logical semantic conflict, and resource configuration conflict.

[0028] Preferably, the fine-tuned pre-trained code model replaces the original output layer of the CodeBERT model with a completely new fully connected layer. The input dimension of this fully connected layer is consistent with the final hidden layer dimension of the CodeBERT model, and the output dimension is equal to the total number of conflict types. During model fine-tuning, the original conflict blocks and labeled type tags of the training set are used as input, and the AdamW optimizer is used as the optimization objective. This process adjusts the model parameters, including the attention mechanism and the weights of relevant network layers, mapping the key features of the conflict blocks to predefined conflict types. After training, the model performance is evaluated using a validation set.

[0029] Preferably, step S3 specifically includes:

[0030] Extract all historical conflict cases from the warehouse containing the conflict block to be resolved. Use an embedding model to convert the current conflict block to be resolved and all historical conflict blocks in that warehouse into vectors. Then, use the cosine similarity formula to perform similarity matching between the current conflict block vector and the historical conflict block vectors. The specific cosine similarity formula is as follows: ;

[0031] Where q represents the embedding vector of the current conflict block to be resolved, d represents the embedding vector of the historical conflict blocks in the code repository, and n represents the dimension of the vector. The similarity between the vectors is measured by calculating the cosine value between them. The closer the cosine value is to 1, the more similar they are.

[0032] A similarity threshold α∈[0.7,0.9] is set. When the threshold α is below 0.7, it indicates that the relevance of the retrieved historical cases has decreased significantly and noise is easily introduced. When the threshold is above 0.9, it indicates that fewer cases are recalled and insufficient reference information can be provided to the agent.

[0033] Finally, the retrieved Top-k conflict blocks and their solutions are written into the conflict block information pool as a reference for the agent to resolve the current conflict block, where k∈[3,5]. This range of values ​​can achieve a balance between providing sufficient reference information and avoiding information overload.

[0034] Preferably, step S4 specifically includes:

[0035] When the type label y ∈ {import or dependency conflict, function or class conflict, variable conflict, resource configuration conflict} output by the pre-trained code large model, the tool for building lexical granularity conflict blocks and the tool for building repository code attribute graphs are called in a fixed order: first, the tool for building lexical granularity conflict blocks is used to refine the line-level conflict blocks into lexical granularity to obtain the core conflicting lexicals; then, the tool for building repository code attribute graphs is used to locate the conflict context in the repository code attribute graph based on the core conflicting lexicals; finally, the dynamic scheduling loop is entered.

[0036] Conversely, if the type label y does not belong to the predefined subset of labels, the dynamic scheduling loop is entered directly.

[0037] Preferably, step S5 specifically includes:

[0038] Using the feedback tool, based on the status information of the conflict information pool, the conflict status information including the conflict type label y, the return results of the invoked tools, and the list of uninvoked tools is extracted, and populated into the prompt word template of the above feedback tool to generate a tool scheduling request, which is then input into the large language model.

[0039] Use parsing tools to analyze the output of the large language model and obtain the target tool name or task termination command.

[0040] Preferably, the tool scheduling constraint verification in step S6 is used to reduce the number of invalid tool calls. The target tool can only be executed if it passes the scheduling constraint verification, wherein the constraint conditions include at least:

[0041] Constraint 1: When an agent dynamically selects to call the tool for obtaining conflicting parent commit codes, it must directly call the code digest tool afterward and use the obtained parent commit codes as input to the tool.

[0042] The purpose of this constraint is to automatically summarize the parent commit code and extract the intent to change it;

[0043] Constraint 2: In the entire conflict resolution process, each tool, including the tool for building word-level conflict blocks and all data acquisition tools, can only be called once.

[0044] Once any of the above tools is invoked, it needs to be marked as "invoked" in the information pool and removed from the list of available tools in subsequent decision rounds. Since the output of each execution of the above tools is consistent, repeated invocation will not generate new information. Therefore, the purpose of this constraint is to prevent the agent from getting stuck in an invalid loop and reduce time loss.

[0045] Constraint 3: The termination tool and the parsing tool must be the last two tools invoked by the agent;

[0046] Whether the maximum number of tool iterations is reached or the agent actively decides to end conflict resolution, the "end tool" must be called to terminate the conflict resolution, requiring the agent to provide a final conflict resolution solution. The "parse tool" then parses the agent's response and outputs the final conflict resolution solution.

[0047] Preferably, the preset termination condition in step S7 includes:

[0048] Condition 1 is forced termination. When the number of tool calls reaches the preset maximum number of iterations T, the agent will call the termination tool and the parsing tool to output the conflict resolution solution, where the maximum number of iterations T∈[5,10].

[0049] Condition 2 is active termination. When the parsing tool parses the response result of the large language model in S5 during a certain round of scheduling, if a task end instruction is issued, the agent will call the end tool and the parsing tool to output a conflict resolution solution.

[0050] If neither condition is met, the conflict is not resolved and S5 is repeated to request the invocation of a new tool.

[0051] Compared with the prior art, the beneficial effects achieved by the present invention are:

[0052] 1. Constructing a candidate toolset for intelligent agents, particularly a repository-level conflict information acquisition tool. This invention does not employ a general conflict resolution method to resolve all types of conflicts. Instead, it constructs numerous candidate tools, allowing the intelligent agent to dynamically select the appropriate tool for conflict resolution. The "code attribute graph construction tool" acquires the repository-level context information of conflicting blocks, enabling resolution strategies to be based on the semantic dependencies of the code. The data acquisition and data processing tools constructed in this invention can not only assist intelligent agents but also be invoked independently in other software engineering tasks without additional configuration.

[0053] 2. Automatic Conflict Block Classification Mechanism Based on Feature Learning. Unlike other conflict resolution strategies that ignore the characteristics of conflict blocks themselves, the goal of this invention is to resolve conflicts by using different combinations of tools based on the characteristics of each conflict block. The pre-trained code large model fine-tuned in this invention achieves automatic classification of conflict block types.

[0054] 3. Obtain historical conflict cases similar to those in the same repository. This invention uses vectorization technology to match similar historical conflict cases in the repository containing the conflict blocks to be resolved, providing reference cases that conform to the repository style for the agent to resolve and merge conflicts.

[0055] 4. Construct a conflict information pool to ensure inference consistency. This information pool not only persistently records the metadata of conflict blocks, but also records information during the conflict resolution process, including but not limited to the input, output, and call status of each tool. As a knowledge base for the conflict blocks to be resolved, the information pool ensures the consistency of conflict-related information and the uniqueness of tool scheduling under multi-turn dialogue.

[0056] 5. A state-guided intelligent agent workflow engine. This engine performs dynamic reasoning based on the state of the conflict information pool and combines it with predefined tool scheduling constraints to ensure the stability of the resolution process. Attached Figure Description

[0057] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0058] Figure 1 This is a schematic diagram illustrating the steps of the present invention for automatically resolving code merging conflicts;

[0059] Figure 2 The flowchart shows the execution sequence of the intelligent agent of this invention to complete a single code merging conflict resolution.

[0060] Figure 3 A flowchart for constructing a repository code attribute graph to obtain conflict contexts for this invention. Detailed Implementation

[0061] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] Please see Figures 1-3 The present invention provides the following technical solution:

[0063] Example 1: As Figure 1 and Figure 2 As shown, the automated code merging conflict resolution method for repository-level code based on intelligent agent workflow takes three conflicting segments as input and includes the following steps:

[0064] S1. Obtain conflict block metadata and initialize the agent toolset and conflict information pool;

[0065] Preferably, the conflict block metadata input in S1 includes the original conflict block, the URL address of the repository where the conflict block is located, the conflict commit hash value, and the file path where the conflict block is located.

[0066] Preferably, the tools in the agent toolkit can be divided into three categories: data acquisition tools and data processing tools are added to the list of available tools after initialization, while scheduling and control tools control the dynamic reasoning direction of the agent.

[0067] There are six data acquisition tools.

[0068] 1) A tool for building repository code attribute graphs, used to obtain the context of conflict blocks within the repository, is implemented based on static program analysis technology. Its process is as follows: Figure 3 As shown, firstly, the source code of the repository containing the conflicting block is downloaded according to its URL. Based on the Joern platform, the "joern-export" command is used to export a code attribute graph G=(V,E), which integrates the abstract syntax tree, control flow graph, data dependency graph, program dependency graph, and function call graph. Nodes V in the code attribute graph include at least method type nodes and variable type nodes, and the relationships between nodes are represented by labeled directed edges E. Next, the corresponding node set V_c in the code attribute graph is located based on the line number or keyword of the conflicting code. Subsequently, a post-slicing algorithm is used to slice the code attribute graph, starting from V_c, to extract the subset of nodes related to the conflict, which is the context subgraph G_c. Finally, based on the line number information of the nodes in G_c, the corresponding original code fragment is reconstructed, thereby extracting the data flow or function call chain of the conflicting block and providing the agent with the semantic context of the conflict.

[0069] The aforementioned backward slicing algorithm is based on the program dependency graph. Starting from the node V_c where the conflict block is located, it traverses backwards along the program dependency graph to find all data dependency edges and control dependency edges that can reach that node, thereby achieving the effect of "source tracing" and finding statements in the repository associated with the conflict block, or code modifications that cause the current conflict state, thus narrowing the scope of analysis. The slice radius r∈[1,3] is set, which limits the traversal level of dependency edges starting from V_c. r=1 captures the most direct dependencies and is suitable for local conflicts, while r=3 can cover most logically related contexts within a function or small module. The depth dependency d∈[1,5] controls the maximum length of backward tracing along the dependency path during slicing. This parameter captures the code cause that leads to the current conflict state. d=1 only considers direct causes, while d=5 allows tracing a longer causal chain. Therefore, limiting the slice radius and depth dependency parameters to the above ranges is ideal. Preferably, when r=2 and d=3, the context coverage and computational overhead can be effectively balanced.

[0070] 2) A tool to obtain the three lines of code before and after a conflict block. Based on regular expression matching, it identifies standard Git conflict markers ("<<<<<<<", "|||||||", "=======", and ">>>>>>>") in the conflict file, locates the boundary of the conflict block, and obtains and stores the three lines of code before and after the conflict block as the direct context of the conflict block.

[0071] 3) Obtain commit messages using the Python Requests library to retrieve the HTML source code of the repository page, and use XPath technology to parse and locate the HTML document structure to extract commit messages. The commit messages may contain the reason, content, or function of the code changes in that branch.

[0072] 4) Tools for obtaining conflicting parent code commits, obtaining author information, and obtaining pull requests are all implemented based on the Python PyGithub library.

[0073] There are two data processing tools.

[0074] 1) A tool for constructing lexical-level conflict blocks refines conflict blocks from the line level to the lexical level to extract fine-grained difference information. The word segmentation rule is based on natural delimiters in the code, including at least spaces and tabs. The original conflict blocks are compared at the line level using the diff3 algorithm. This tool splits the specific edited content of the three versions of the line-level conflict block into independent lexical units for each line, places each lexical unit in a separate version file, and then applies the diff3 algorithm again to perform a three-way merging operation on these three files to obtain lexical-level conflict blocks.

[0075] 2) Code summarization tool: By calling the official interface of the large language model, this invention uses the DeepSeek official API, which can be replaced by other large language models with equivalent effects, to summarize the input code snippets or code files and output their functions.

[0076] There are three scheduling and control tools.

[0077] 1) The feedback tool is used to send tool scheduling requests to the agent, reads certain fields from the information pool, including the conflict type label y, the return results of the invoked tools, and the list of uninvoked tools, generates a problem description, guides the agent to analyze the current resolution status, and considers the most appropriate next action. The content of the placeholders "{}" in the following prompt template is obtained from the conflict information pool;

[0078] Specific prompt word templates are as follows:

[0079] "You are a code merging conflict resolution expert. Your task is to determine which tool to invoke next to advance the conflict resolution process, based on the given conflict information and the results of the tools already executed. The current conflict information is as follows:"

[0080] Conflict block content: {conflict}

[0081] Conflict type: {y}

[0082] Tools used and results: {Result of tool 1: result1, result of tool 2: result2…}

[0083] List of available tools: {Tool 1, Tool 2, ...}

[0084] In the decision-making process, you must strictly adhere to the following rules:

[0085] 1. When you choose to invoke the 'Get Conflicting Parent Commit Code Tool', you must immediately invoke the 'Code Summary Tool' afterward and use the obtained parent commit code as input to that tool.

[0086] 2. In the entire conflict resolution process, the 'tool for building lexical-level conflict blocks' and all data acquisition tools can only be called once.

[0087] 3. The 'Termination Tool' and 'Parsing Tool' must be the last two tools invoked by the agent.

[0088] 2) Parsing tool, responsible for parsing the response results of the large language model. After parsing, it can obtain the target tool to be executed or the task termination instruction. This tool is called after the termination tool, and can parse and output the final conflict resolution solution.

[0089] 3) The termination tool's triggering condition depends on the parsing tool. When the parsing tool parses the task termination instruction or reaches the maximum tool iteration count, the termination tool will use a predefined prompt word template to request the agent to output a conflict resolution solution.

[0090] The content in the placeholders "{}" below represents similar conflict cases retrieved in S3, with the following prompts:

[0091] "You are a code merging conflict resolution expert. Your task is to combine historical dialogues and retrieved similar historical conflict cases to output conflict resolution solutions. Please note that you should avoid excessive text descriptions and directly generate replaceable conflict resolution solutions."

[0092] Similar historical conflict cases in the warehouse include: {Case 1, Case 2, ...}.

[0093] Preferably, the conflict information pool records all data information during the conflict resolution process and manages the uniqueness of tool calls by maintaining the fields of the called tools. The conflict block metadata fields include at least the original conflict block, the name of the repository where the conflict block is located, the conflict commit hash value, and the file path where the conflict is located. The fields that appear during the conflict resolution process include at least the input and output of the called tools.

[0094] S2. Input the three-way merged conflict fragments into the fine-tuned pre-trained code large model, classify the conflict block features, output the conflict type confidence ρ and conflict label y, and record them in the conflict information pool.

[0095] Preferably, the conflict tag y belongs to the predefined conflict type tag set Y, which mainly includes the following seven types: comment or string type conflict, which involves changes to comment content, docstrings or other string literals; import or dependency conflict, which involves modifications to import lines or dependencies; function or class conflict, which involves changes to the signature, parameters, or implementation of functions or classes; variable conflict, which involves changes to variable names, variable types, or variable values; code formatting conflict, which involves changes to formatting aspects such as indentation, spaces, and newlines; logical semantic conflict, which involves changes to code logic or refactoring operations; and resource configuration conflict, which involves changes to file paths, configuration parameters, or resource references.

[0096] This invention achieves automatic type classification of conflict blocks through fine-tuning a pre-trained large code model. First, based on the conflict resolution dataset MergeBERT-history published in the paper "Program merge conflict resolution via neural transformers," 500 data points are randomly sampled proportionally according to different conflict resolution scheme categories, and manually labeled with the seven label definitions mentioned above. Then, 400 samples are selected as the training set, and the remaining 100 data points are used as the validation set. The pre-trained large code model CodeBERT is then fine-tuned under supervision using the training set.

[0097] Specifically, the original output layer of CodeBERT is replaced with a completely new fully connected layer. The input dimension of this fully connected layer is consistent with the final hidden layer dimension of the CodeBERT model, and the output dimension is equal to the total number of conflict types. During model fine-tuning, the original conflict blocks and labeled type tags of the training set are used as input, cross-entropy loss is used as the optimization objective, and the AdamW optimizer is used for training.

[0098] The batch size was set to 16, the learning rate to 2e-5 to 5e-5, and the number of training epochs to 3 to 5. This process adjusted model parameters, including the attention mechanism and the weights of relevant network layers, to map the key features of conflict blocks to predefined conflict types. After training, the model performance was evaluated using a validation set. Testing showed that the fine-tuned model achieved a classification accuracy of over 85% on the validation set, indicating its effective ability to distinguish conflict block feature types.

[0099] Preferably, the conflict blocks to be classified are input into the fine-tuned model. The model outputs a predicted probability distribution vector, where each value represents the confidence level that the conflict block belongs to the corresponding conflict type. The type with the highest confidence level is taken as the label y predicted by the model, where y∈Y. The confidence threshold is set to 0.6. When the highest confidence level ρ<0.6, the result is marked as requiring manual review. This threshold is set because the uncertainty of the model prediction increases significantly when the confidence level is below 0.6, and manual intervention can ensure the reliability of the classification. Using this fine-tuned pre-trained code model to automatically label the feature types of conflict blocks is a key prerequisite for achieving automated resolution based on conflict types.

[0100] S3. Based on the repository address of the current conflicting block, retrieve the top-k similar historical conflicting blocks using similarity matching, and write the corresponding solutions into the conflict information pool.

[0101] Preferably, historical merge conflicts similar to those in the same warehouse are obtained, which is achieved based on semantic vector retrieval technology.

[0102] First, extract all historical conflict cases from the repository containing the conflict block to be resolved, convert them into 768-dimensional vectors using the embedding model "BAAI / bge-base-zh-v1.5", and store them in the vector database Milvus. This can be replaced with other embedding models capable of generating code-intensive vectors, or other databases with vector storage capabilities, depending on the task.

[0103] Next, the currently unresolved conflict blocks are transformed into query vectors of the same dimension using the same embedding model, and then matched in the vector space using a cosine similarity algorithm. A similarity threshold α∈[0.7,0.9] is set. When the threshold α is below 0.7, the relevance of the retrieved historical cases decreases significantly, and noise is easily introduced; when the threshold is above 0.9, fewer cases are recalled, which cannot provide sufficient reference information for the agent.

[0104] Finally, the retrieved Top-k conflict blocks and their solutions are written into the conflict block information pool as a reference for the agent to resolve the current conflict block, where k∈[3,5]. This range of values ​​can achieve a balance between providing sufficient reference information and avoiding information overload.

[0105] In the vector retrieval process, q represents the embedding vector of the current conflict block to be resolved, d represents the embedding vector of historical conflict blocks in the code repository, and n represents the dimension of the vector. The similarity between vectors is measured by calculating the cosine value. The closer the cosine value is to 1, the more similar they are. The formula for calculating cosine similarity is as follows:

[0106] .

[0107] S4. If the type label y output by the model in S2 belongs to a predefined subset of labels, the tools in the agent toolkit are called in sequence to obtain the warehouse-level conflict context, and then the dynamic scheduling loop is entered. Otherwise, if it does not belong to the subset, the dynamic scheduling loop is entered directly.

[0108] Preferably, when the type label y ∈ {import or dependency conflict, function or class conflict, variable conflict, resource configuration conflict} of the model output in S2, the "build lexical granularity conflict block tool" and the "build repository code attribute graph tool" are called in a fixed order.

[0109] The goal is to refine conflict blocks from the line level to the lexical level, obtain a set of core conflict lexicals, and locate conflict contexts with direct dependencies in the code attribute graph based on these core conflict lexicals. However, when the conflict block type label y∈{comment or string conflict, code formatting conflict, logical semantic conflict}, refining to the lexical granularity may introduce irrelevant contexts, so calling the "build lexical granularity conflict block tool" is not mandatory.

[0110] S5. Generate a structured tool scheduling request based on the state information in the conflict information pool, input it into the large language model, and obtain the target tool or task termination instruction to be executed by parsing the output of the large language model.

[0111] Preferably, a feedback tool for regulating the behavior of the intelligent agent is used to extract conflict status information from the conflict information pool, which includes at least the conflict type label y, the return result of the invoked tool, and the list of uninvoked tools. This information is then filled into the prompt word template of the aforementioned feedback tool to generate a tool scheduling request.

[0112] Subsequently, the structured tool scheduling request is input into the large language model, and its output is parsed by the parsing tool to obtain the target tool or task termination instruction to be executed.

[0113] S6. Tool scheduling constraint verification: Based on the conflict type label y in the conflict information pool and the field of the called tool list, perform call order legality verification, uniqueness verification and termination legality verification on the target tool to be executed.

[0114] Preferably, the tool scheduling constraint verification is a deterministic rule that must be followed in the conflict resolution process. The target tool can only be executed if it passes the scheduling constraint verification. The specific constraints are as follows:

[0115] Constraint 1: When an agent dynamically selects to call the tool for obtaining conflicting parent commit codes, it must then directly call the code digest tool and use the obtained parent commit codes as input to that tool.

[0116] The purpose of this constraint is to automatically summarize the retrieved parent commit code and extract the intent of the change.

[0117] Constraint 2: In the entire conflict resolution process, the tool for building word-level conflict blocks and all data acquisition tools can only be called once.

[0118] Once any of the above tools is invoked, it needs to be marked as "invoked" in the information pool and removed from the list of available tools in subsequent decision rounds. Since the output of each execution of the above tools is consistent, repeated invocation will not generate new information. Therefore, the purpose of this constraint is to prevent the agent from getting stuck in an invalid loop and reduce time loss.

[0119] Constraint 3: The termination tool and the parsing tool must be the last two tools invoked by the agent.

[0120] Whether the maximum number of tool iterations is reached or the agent actively decides to end conflict resolution, the termination tool must be called to end conflict resolution. The agent is required to provide a final conflict resolution solution, and the parsing tool parses the agent's response and outputs the final conflict resolution solution.

[0121] S7. Termination condition judgment and result output. The preset termination conditions include reaching the maximum number of tool iterations T or obtaining the task end instruction. When the preset termination conditions are met, the final conflict resolution solution is output and the processing flow ends. Otherwise, the next round of scheduling is entered, and S5 is repeated until the preset termination conditions are met.

[0122] Preferably, there are two conditions for ending conflict resolution.

[0123] Condition 1 is forced termination. When the number of tool calls reaches the preset maximum number of iterations T, the agent will call the "end tool" and the "parse tool" to output the conflict resolution solution, where the maximum number of iterations T∈[5,10].

[0124] Condition 2 is active termination. When the "parse tool" parses the response result of the large language model in S5 during a certain round of scheduling, if a task end instruction is issued, the agent will call the "end tool" and the "parse tool" to output a conflict resolution solution.

[0125] If neither of the above two conditions is met, the conflict is not successfully resolved, and S5 is repeated to request the invocation of a new tool.

[0126] It should be noted that the code attribute graph construction platform, pre-trained large code model, large language model, embedding model, and vector database involved in the above embodiments are merely one specific implementation method to achieve the corresponding functions. Within the scope of the technical concept of this invention, those skilled in the art can also use other equivalent program analysis platforms, code pre-training models, or vector retrieval algorithms to replace them, and the technical effects achieved will be the same, all of which should be covered within the protection scope of this invention.

[0127] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for automated resolution of repository-level code merging conflicts based on intelligent agent workflow, using three-way merging conflict segments as input, characterized in that... Includes the following steps: S1. Obtain conflict block metadata and initialize the agent toolset and conflict information pool; S2. Input the three-way merged conflict fragments into the fine-tuned pre-trained code large model, classify the conflict block features, output the conflict type confidence ρ and conflict label y, and record them in the conflict information pool. S3. Based on the repository address of the current conflicting block, retrieve the top-k similar historical conflicting blocks using similarity matching, and write the corresponding solutions into the conflict information pool. S4. If the type label y output by the model in S2 belongs to a predefined subset of labels, the tools in the agent toolkit are called in sequence to obtain the warehouse-level conflict context, and then the dynamic scheduling loop is entered. Otherwise, if it does not belong to the subset, the dynamic scheduling loop is entered directly. S5. Generate a structured tool scheduling request based on the state information in the conflict information pool, input it into the large language model, and obtain the target tool or task termination instruction to be executed by parsing the output of the large language model. S6. Tool scheduling constraint verification: Based on the conflict type label y in the conflict information pool and the field of the called tool list, perform call order legality verification, uniqueness verification and termination legality verification on the target tool to be executed. S7. Termination condition judgment and result output. The preset termination conditions include reaching the maximum number of tool iterations T or obtaining the task end instruction. When the preset termination conditions are met, the final conflict resolution solution is output and the processing flow ends. Otherwise, the next round of scheduling is entered, and S5 is repeated until the preset termination conditions are met.

2. The automated code merging conflict resolution method for repository-level code based on intelligent agent workflow as described in claim 1, characterized in that, The intelligent agent toolset in step S1 includes: data acquisition tools, data processing tools, and scheduling and control tools within the warehouse scope; Repository-wide data acquisition tools include: tools for building repository code property graphs, tools for obtaining the three lines of code before and after a conflict block, tools for obtaining commit messages, tools for obtaining the parent commit of a conflict, tools for obtaining author information, and tools for obtaining pull requests; Data processing tools include: tools for building lexical-level conflict blocks and code summarization tools; Scheduling and control tools include: feedback tools, parsing tools, and termination tools; The tool for constructing repository code attribute graphs downloads the complete repository source code using the URL address of the repository where the conflict block is located. Based on static program analysis technology, it constructs a code attribute graph G=(V,E) containing code structure relationships, call relationships, and data dependency relationships. Starting from the node set corresponding to the conflict code, it slices the code attribute graph according to the preset slice radius r and depth dependency d to obtain a context subgraph G_c, thus obtaining the repository-level conflict context. The tool for constructing word-granular conflict blocks and the code digest tool split the specific edited content of the three versions of the original line-granular conflict block into independent words for each line, place each word in the corresponding version file, and then apply the diff3 algorithm to perform a three-way merging operation on the three files to obtain word-granular conflict blocks. The feedback tool reads some fields from the information pool, including the conflict type label y, the return results of the invoked tools, and the list of uninvoked tools, generates a problem description, and sends a tool scheduling request to the agent. The parsing tool is responsible for parsing the response results of the large language model, obtaining the target tool or task termination instruction to be executed, and outputting the final conflict resolution solution.

3. The automated code merging conflict resolution method for repository-level code based on intelligent agent workflow as described in claim 1, characterized in that, The conflict information pool in step S1 must record at least the following fields: The content includes the conflict block identifier (id), the original conflict block content, the URL of the repository containing the conflict block, the conflict commit hash, the file path of the conflict block, the list of tools called, the list of tools not called, and the input and output data of the tools called.

4. The automated code merging conflict resolution method for repository-level code based on intelligent agent workflow as described in claim 1, characterized in that, Step S2 specifically includes: The finely tuned pre-trained code large model receives the original conflict block and outputs a predicted probability distribution vector. The value at each position of the vector corresponds to the confidence of a conflict type. The maximum value in the vector is taken as the highest confidence ρ. When ρ < 0.6, the corresponding conflict is marked as requiring manual review, and the highest confidence ρ and the corresponding conflict label y are recorded in the conflict information pool. The fine-tuned pre-trained code model replaces the original output layer of the CodeBERT model with a completely new fully connected layer. The input dimension of this fully connected layer is consistent with the final hidden layer dimension of the CodeBERT model, and the output dimension is equal to the total number of conflict types. During model fine-tuning, the original conflict blocks and labeled type tags of the training set are used as input, and the AdamW optimizer is used as the optimization objective. This process adjusts the model parameters, including the attention mechanism and the weights of relevant network layers, mapping the key features of the conflict blocks to predefined conflict types. After training, the model performance is evaluated using a validation set.

5. The automated code merging conflict resolution method for repository-level code based on intelligent agent workflow as described in claim 1, characterized in that, Step S3 specifically includes: Extract all historical conflict cases from the warehouse containing the conflict block to be resolved. Use an embedding model to convert the current conflict block to be resolved and all historical conflict blocks in that warehouse into vectors. Then, use the cosine similarity formula to perform similarity matching between the current conflict block vector and the historical conflict block vectors. The specific cosine similarity formula is as follows: ； Where q represents the embedding vector of the current conflict block to be resolved, d represents the embedding vector of the historical conflict blocks in the code repository, and n represents the dimension of the vector; A similarity threshold α∈[0.7,0.9] is set. When the threshold α is below 0.7, it indicates that the relevance of the retrieved historical cases has decreased significantly and noise is easily introduced. When the threshold is above 0.9, it indicates that fewer cases are recalled and insufficient reference information can be provided to the agent. Finally, the retrieved Top-k conflict blocks and their solutions are written into the conflict block information pool as a reference for the agent to resolve the current conflict block, where k∈[3,5].

6. The automated code merging conflict resolution method for repository-level code based on intelligent agent workflow as described in claim 1, characterized in that, Step S4 specifically includes: When the type label y ∈ {import or dependency conflict, function or class conflict, variable conflict, resource configuration conflict} output by the pre-trained code large model, the tool for building lexical granularity conflict blocks and the tool for building repository code attribute graphs are called in a fixed order: first, the tool for building lexical granularity conflict blocks is used to refine the line-level conflict blocks into lexical granularity to obtain the core conflicting lexicals; then, the tool for building repository code attribute graphs is used to locate the conflict context in the repository code attribute graph based on the core conflicting lexicals; finally, the dynamic scheduling loop is entered. Conversely, if the type label y does not belong to the predefined subset of labels, the dynamic scheduling loop is entered directly.

7. The automated code merging conflict resolution method for repository-level code based on intelligent agent workflow as described in claim 1, characterized in that, Step S5 specifically includes: Using the feedback tool, based on the status information of the conflict information pool, the conflict status information including the conflict type label y, the return results of the invoked tools, and the list of uninvoked tools is extracted, and populated into the prompt word template of the above feedback tool to generate a tool scheduling request, which is then input into the large language model. Use parsing tools to analyze the output of the large language model and obtain the target tool name or task termination command.

8. The automated code merging conflict resolution method for repository-level code based on intelligent agent workflow as described in claim 1, characterized in that, The tool scheduling constraint check in step S6 is used to reduce the number of invalid tool calls. The target tool can only be executed if it passes the scheduling constraint check, and the constraint conditions must include at least: Constraint 1: When an agent dynamically selects to call the tool for obtaining conflicting parent commit codes, it must directly call the code digest tool afterward and use the obtained parent commit codes as input to the tool. Constraint 2: In the entire conflict resolution process, each tool, including the tool for building word-level conflict blocks and all data acquisition tools, can only be called once. Constraint 3: The termination tool and the parsing tool must be the last two tools invoked by the agent.

9. The automated code merging conflict resolution method for repository-level code based on intelligent agent workflow as described in claim 1, characterized in that, The preset termination conditions in step S7 include: Condition 1 is forced termination. When the number of tool calls reaches the preset maximum number of iterations T, the agent will call the termination tool and the parsing tool to output the conflict resolution solution, where the maximum number of iterations T∈[5,10]. Condition 2 is active termination. When the parsing tool parses the response result of the large language model in S5 during a certain round of scheduling, if a task end instruction is issued, the agent will call the end tool and the parsing tool to output a conflict resolution solution. If neither condition is met, the conflict is not resolved and S5 is repeated to request the invocation of a new tool.

Images