Code change generation method based on multi-agent proxy

Abstract

The invention discloses a code change generation method based on a multi-agent proxy library migration scene, which can accurately locate all code action ranges related to library migration in a file range by performing structured analysis on a source code file and combining source library import information and code feature recognition, and can improve the code change generation efficiency. The problems of omission and misjudgment caused by manual analysis or simple rule matching are avoided, and the integrity and accuracy of migration site recognition are improved. According to the method, the corresponding migration plan is generated by combining key information of the source library and the target library aiming at the identified action range to be migrated, so that the code change process is not limited to simple interface replacement any more, targeted adjustment can be performed according to a specific use scene, and the consistency of migrated codes in terms of semantics and behaviors is ensured. According to the method, through a collaborative code change generation and verification mechanism, the code change related to library migration is automatically generated and evaluated, and the reliability and availability of a generation result are improved while manual intervention is reduced.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary field of artificial intelligence and software engineering, and specifically relates to a code change generation method based on a multi-agent agent library migration scenario. Background Technology

[0002] In modern software development, third-party software libraries are widely used in various software systems to improve development efficiency, reuse mature functions, and reduce development costs. However, with the rapid evolution of the software ecosystem, existing libraries may gradually become unable to meet system requirements due to reasons such as discontinuation of maintenance, insufficient performance, interface changes, or security risks. This necessitates migrating the source libraries relied upon by the source code to target libraries with similar functionality or better performance. Library migration typically involves modifying a large amount of source code, including interface replacement, parameter adjustment, and call logic refactoring. Therefore, how to efficiently and accurately generate migration-related code changes has become a crucial issue in software maintenance and evolution.

[0003] As code files become increasingly complex, library migration is no longer limited to simple interface replacement, but often involves cross-module code adjustments. Manually completing library migrations is not only time-consuming and labor-intensive, but also prone to introducing new defects due to missed migration points or incorrect use of interfaces. In addition, library migrations often require developers to have a deep understanding of both the source and target libraries, which further increases migration costs and technical barriers. Therefore, using automated or intelligent methods to assist in completing library migration code changes has significant practical implications.

[0004] Existing library migration methods primarily rely on human experience or rule-based tools. These methods typically replace specific interface calls in the code using predefined rules or pattern matching, such as directly mapping function names in the source library to corresponding function names in the target library. However, due to significant differences in design philosophy, interface semantics, and usage among different libraries, simple rule replacement is insufficient to cover complex migration scenarios. When the code contains conditional logic, contextual dependencies, or multiple calling methods, the applicability and accuracy of these methods are significantly limited.

[0005] With the development of large language models, existing research has attempted to use them to generate or modify code to assist in tasks such as API (Application Programming Interface) replacement or code refactoring. For example, the paper [M. Islam, AK Jha, S. Nadi and I. Akhmetov, "PyMigBench: A Benchmark for Python Library Migration," 2023 IEEE / ACM 20th International Conference on Mining Software Repositories, Melbourne, Australia, 2023, pp. 511-515] directly generates migrated code by providing source code snippets and target library information to the language model. This demonstrates a certain degree of flexibility at the local code snippet level and can handle interface replacement problems that are not simple mappings. However, this method usually lacks a systematic analysis of the entire code file structure and dependencies. The generation process is often based on functions or code snippets, making it difficult to accurately identify all code locations related to library migration.

[0006] The challenge in generating code changes for single-file library migrations lies in the need for a comprehensive analysis of the abstract syntax structure, control flow, and library dependencies at the file level to accurately locate all code positions related to the library migration. However, existing methods typically treat migration as a one-time, holistic generation task, lacking phased processing for migration site identification, migration planning, and code generation, making it difficult to guarantee the consistency and reliability of the generated results.

[0007] Furthermore, existing methods generally lack verification mechanisms for single-file migration results. The generated code changes may be syntactically correct, but issues such as incomplete migration, incorrect API calls, or the use of deprecated methods may still exist, affecting the quality and maintainability of the migrated code. Therefore, effective technical means are still lacking for systematically evaluating and filtering the generated library migration code changes within a single source code file.

[0008] Therefore, existing methods still have significant limitations in single-file library migration scenarios: on the one hand, rule-based or string-matching-based code replacement methods lack an understanding of the source code structure and usage semantics, making it difficult to accurately identify all code locations within the file related to library migration; on the other hand, techniques that directly generate code based on language models typically use the entire file or local fragments as the generation object, lacking explicit location and differentiation of migration points, easily leading to missed or incorrect modifications. Therefore, accurately identifying library migration-related code locations within a single source code file and generating complete, reasonable code changes that conform to the target library's usage specifications remains a pressing technical challenge. Summary of the Invention

[0009] In view of the above, the present invention provides a code change generation method based on multi-agent agent library migration scenario, which can provide developers with a powerful tool to deal with file-level code change generation.

[0010] A code change generation method based on a multi-agent agent library migration scenario includes the following steps: (1) Collect the source code files to be migrated and their corresponding source library names and target library names; (2) Use search tools to determine the key identification information of the source library, construct an abstract syntax tree and control flow structure for the source code files, and combine dependency propagation and text feature matching to obtain migration-related nodes; (3) Input the scope information of the migration-related nodes and the source library name as prompt words into the localization agent, and the localization agent outputs the structured site to be migrated; (4) Input the information of the sites to be migrated, the source library name and the source code file as prompt words into the planning agent. The planning agent calls the search tool to determine the key API knowledge and generates the migration plan for each site to be migrated. (5) Input the source code file, source library name, target library name, migration site, key API knowledge and migration plan as prompt words into the change generation agent, and output the migration-related code changes; (6) Input the source code file, code changes, and scoring criteria as prompt words into the verification agent, and the verification agent scores the code changes and determines the final code changes.

[0011] Furthermore, the specific implementation of step (1) is as follows: 1.1 Obtain the existing benchmark dataset, in which each migration record contains the code repository, commit information, source repository name, and target repository name; construct an API request, clone the code repository to the local machine, extract the file locations where migrations occurred from the commit information, and read the source code files before and after the migration; 1.2 Delete data whose file directory changed before and after migration, filter library migration data with long-tail characteristics, that is, use the data programming paradigm to identify and filter library migration data related to Django library, use the difflib tool to process the source code files before and after migration, and generate corresponding code change file pairs.

[0012] Furthermore, the specific implementation of step (2) is as follows: 2.1 Construct a search request using the name of the source library, call the API of the search tool to obtain the search results, and call the API of the DeepSeek model based on the search request and search results to summarize the search results and generate the import name of the source library; 2.2 The source code before migration is parsed using an AST (Abstract Syntax Tree) tool to construct an abstract syntax tree. Based on this, the scope of the source code is divided according to modules, classes, and functions. The call relationships between different scopes are identified to construct a call dependency structure. Each node in this structure corresponds to a code scope in the source code. The code scope includes module scope, function scope, or class scope. The information stored in each node includes the scope identifier, start line number, and end line number. The edges between nodes represent the call dependencies between different code scopes. The direction of the directed edges is from the caller to the callee. 2.3 Based on the import name and abstract syntax tree of the source library, all variable access, property access, and function call nodes are traversed in the abstract syntax tree to identify syntax nodes related to the source library. When a node contains a use of the source library, it is marked as a migration-related node, and the migration-related markers are propagated along the call direction to other nodes that have dependencies on it based on the call dependency relationship. For code lines related to the source library in the module scope, consecutive or adjacent code lines are merged into module-level code fragments according to their line numbers and included as independent nodes in the call dependency relationship structure. Finally, the migration-related nodes and the start and end positions of their corresponding code scopes are output.

[0013] Furthermore, in step (3), the scope information of the migration-related nodes and the source library name are input as prompt words to the localization agent, guiding the localization agent to output the structured migration sites within the scope. The migration sites contain the following information: The name of the code region where the migration site is located: function name, class name, or module name; The start and end line numbers of the code region where the migration site is located; The specific code content of the code block for the site to be migrated.

[0014] Furthermore, the specific implementation of step (4) is as follows: 4.1 The information of the site to be migrated and the name of the source library are used as prompt words to prompt the planning agent to output a list of APIs to be migrated. The list contains the certainty of the migration knowledge of each API. When the planning agent determines how to migrate a certain API, it assumes that it has knowledge of that API and marks that API as an API that does not need to be searched. Otherwise, it is marked as an API that needs to be searched. 4.2 For the APIs marked as needing to be searched in the API list, construct search requests for each of these APIs and call the search tool to search how these APIs were migrated to the target library. Filter the knowledge content returned by the search using keywords to obtain the final list of key API knowledge. 4.3 Input the sites to be migrated, the list of APIs to be migrated, the list of key API knowledge, the source library name, the target library name, and the source code file into the planning agent, and guide the planning agent to output a structured migration plan for each site to be migrated, including migration steps, possible API mappings, rows to be deleted, content to be added, and the confidence level of the plan.

[0015] Furthermore, in step (5), the agent generates a change based on the location to be migrated in the prompt words, combined with the content of the source code file, and performs migration according to the migration plan, generating and outputting migration-related code changes.

[0016] Furthermore, the specific implementation of step (6) is as follows: 6.1 Input the code change, source library name, target library name, and multi-dimensional scoring criteria as prompt words into the verification agent. The verification agent analyzes the code change scores in the four dimensions according to the scoring criteria and uses the sum of the scores in the four dimensions as the score of the code change in this round. 6.2 The total score is set to 10 points, with a passing score of 6 points. When the score output by the verification agent in this round is greater than or equal to 6 or the current verification round number exceeds 3, the verification is exited and the currently generated code changes are output. When the score output by the verification agent in this round is less than 6 and the current verification round number is less than 3, the verification agent outputs a verification report and returns the verification report to the change generation agent. The change generation agent regenerates new code changes based on the verification report and starts a new round of verification.

[0017] Furthermore, the four dimensions of the scoring criteria analysis include: Correctness of migration: This dimension accounts for 4 points and is used to measure whether the code changes are in line with functional correctness, such as whether non-existent APIs or non-existent parameters have been introduced. Completeness of migration: This dimension accounts for 3 points and is used to measure whether the code changes have been completely migrated, whether the use of the source library has been completely removed and replaced with the use of the target library; Best practices for migration: This dimension accounts for 1 point and is used to measure whether the code changes generated during the migration process follow the recommended usage of the target library and do not use deprecated or not recommended methods; Correctness of code changes: This dimension accounts for 2 points and is used to measure whether the generated code changes have syntax errors or formatting errors.

[0018] A computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described code change generation method based on a multi-agent agent library migration scenario.

[0019] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described code change generation method based on a multi-agent agent library migration scenario.

[0020] This invention significantly improves the accuracy and reliability of library migration code generation within a single source code file by introducing a multi-agent collaborative code analysis and generation mechanism, demonstrating significant technical benefits. First, by performing structured analysis on the source code file and combining it with library dependency identification, this invention can automatically locate all code positions related to library migration within a single file, avoiding omissions and misjudgments caused by manual analysis or simple rule matching, thereby improving the completeness and accuracy of migration site identification. Second, for the identified migration sites, this invention generates corresponding migration plans based on key information from the source and target libraries, transforming the code change process from simple interface replacement to targeted adjustments based on specific usage scenarios, effectively ensuring semantic and behavioral consistency of the migrated code. Finally, through the collaborative action of code change generation and verification agents, this invention automatically evaluates and filters the generated migration code, reducing manual intervention while improving the usability and stability of the generated results. This allows developers to efficiently complete complex library migration tasks within a single source code file, significantly reducing maintenance costs and demonstrating good practical application value. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the code change generation method based on multi-agent agents according to the present invention.

[0022] Figure 2 This is a schematic diagram of the prompt word code for the localization agent in this invention.

[0023] Figure 3 This is a schematic diagram of the prompt word code for planning the intelligent agent in this invention.

[0024] Figure 4 This is a schematic diagram illustrating the modified prompt word code for generating the intelligent agent in this invention.

[0025] Figure 5 This is a schematic diagram of the prompt word code for verifying the intelligent agent in this invention. Detailed Implementation

[0026] To describe the present invention in more detail, the technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0027] like Figure 1 As shown, this embodiment provides a code change generation method for library migration scenarios based on multi-agent agents, including the following steps: Step S1: Collection of source code files, source library names, and target library names.

[0028] S1.1 Collect code files, source library name, and target library name before and after migration: For the existing Pymigbench benchmark dataset, each migration record contains the corresponding source library name, target library name, code repository, and commit record. Build an API request, clone the code repository to the local machine, and crawl the file content of the migration in the commit record.

[0029] S1.2 Delete data where file directories changed before and after migration, filter library migration data with long-tail characteristics, that is, adopt the data programming paradigm to identify and filter library migrations related to Django library, use the difflib tool to process source code files before and after migration, generate corresponding code change files, and finally obtain a total of 667 code change file pairs.

[0030] Step S2: Use search tools to determine the key identification information of the source library, construct an abstract syntax tree and control flow structure for the source code, and combine dependency propagation and text feature matching to obtain the migration-related code modules.

[0031] S2.1 Searching for the import name of the source library: In order to accurately locate the import name of the source library in the code and more accurately locate the import information of the source library, a search request is constructed using the name of the source library, the search tool's API is called to obtain the search results, and based on the search request and search results, the DeepSeek-V3.2 API is called to summarize the search results and generate the import name of the source library.

[0032] S2.2 Obtaining the Abstract Syntax Tree and Call Dependency Structure: An Abstract Syntax Tree (AST) is constructed by parsing the source code using an AST tool. Based on this, the code scope is divided according to modules, classes, and functions. The call relationships between different scopes are identified, and a call dependency structure is built. In the call dependency structure, each node corresponds to a code scope in the source code, including module scope, function scope, or class scope. Each node stores information including the scope's identifier, the start line number, and the end line number. Edges between nodes represent call dependencies between different code scopes, with directed edges pointing from the caller to the callee.

[0033] S2.3 Acquisition of migration-related scope information: Based on the import name of the source library and the abstract syntax tree, all variable access, property access, and function call nodes are traversed in the abstract syntax tree to identify syntax nodes related to the source library. When a node contains a use of the source library, it is marked as a migration-related node. Based on the call dependency relationship, the migration-related mark is propagated along the call direction to other nodes that have a dependency on it. For code lines related to the source library in the module scope, consecutive or adjacent code lines are merged into module-level code fragments according to their line numbers and included as independent nodes in the call dependency relationship structure. Finally, the migration-related nodes, the start position and end position of the code scope corresponding to the nodes are output.

[0034] Step S3: Obtaining structured sites to be migrated.

[0035] The scope information of the migration-related nodes identified in step S2.3 and the source library name are input as prompt words into the localization agent, such as... Figure 2 As shown, the guided localization agent identifies and outputs the sites to be migrated within its scope. Each site to be migrated contains the following information: The name of the code region where the migration site is located: function name, class name, module name; The start and end line numbers of the code region where the migration site is located; The specific code content of the code block for the site to be migrated.

[0036] Step S4: The planning agent generates migration plans for each site to be migrated.

[0037] S4.1 Obtaining the List of APIs to be Migrated: To better generate migration plans, search for unknown API knowledge and construct prompts from structured information about the sites to be migrated and the source library names, such as... Figure 3As shown, the planning agent is prompted to output a list of APIs to be migrated. When the planning agent determines how to migrate an API, it assumes it has knowledge of that API and marks it as an API that does not need to be searched; otherwise, it marks it as an API that needs to be searched, thus forming the final list of APIs to be migrated.

[0038] S4.2 Obtain the API knowledge list: For APIs marked as needing to be searched, construct search requests for each API, with the content of the request being "how to migrate this {API to be searched} to the {target library}". Call the search tool's API and obtain the search results. Filter the search results by keywords, retaining only sentences containing keywords such as API name and "import", to obtain the final key API knowledge list.

[0039] S4.3 Generation of migration plans: The structured sites to be migrated, the list of APIs to be migrated, the list of key API knowledge, the source library name, the target library name, and the source code file are input into the planning agent. The planning agent is guided to output a structured migration plan for each site to be migrated. The migration plan includes: migration steps, possible API mappings, rows to be deleted, content to be added, and the confidence level of the plan.

[0040] Step S5: Change the code related to the migration of the generated agent output.

[0041] Use source code files, source library names, target library names, structured migration sites, a list of key API knowledge, and a structured migration plan as prompts, such as... Figure 4 As shown, the input is sent to the change generation agent. Based on the identified migration sites and the content of the source code files, the change generation agent performs the migration according to the migration plan, generates and outputs the migration-related code changes.

[0042] Step S6: Verify the code changes generated by the agent through multiple rounds of iteration.

[0043] S6.1 The verification agent scores code changes: Input the generated code changes, source library name, target library name, and multiple scoring criteria as prompts to the verification agent, such as... Figure 5 As shown, the verification agent analyzes the code changes in four dimensions according to the scoring criteria. The final total score is the sum of the scores in the four dimensions, which are set as follows: Correctness of migration: This dimension accounts for 4 points and mainly measures whether the code changes are in line with functional correctness, such as whether non-existent APIs or non-existent parameters have been introduced. Completeness of migration: This dimension accounts for 3 points and mainly measures whether the code changes have been completely migrated, whether the use of the source library has been completely removed and replaced with the use of the target library; Best practices for migration: This dimension accounts for 1 point and is used to measure whether the code changes generated during the migration process follow the recommended usage of the target library and do not use deprecated or not recommended methods; Correctness of code changes: This dimension accounts for 2 points and mainly measures whether the generated code changes have syntax errors or formatting errors.

[0044] S6.2 Multi-round Iterative Verification of Generated Code Changes: To verify the correctness, completeness, best practices, and correctness of the generated migrations and code changes themselves, the verification agent will determine whether to regenerate based on the calculated total score. The maximum number of iteration verification rounds is set to 3, the total score is set to 10 points, and the passing score is 6 points. When the verification agent's score for the current round is greater than 6 or the current verification round number exceeds 3, the verification process exits and outputs the code changes generated in the last round. When the verification agent's score for the current round is less than 6 and the round number is less than 3, the verification agent outputs a verification report and returns it to the change agent. The change agent then regenerates new code changes based on the verification report and repeats the above verification process. The verification report output by the verification agent includes: scores in four dimensions, existing problems, suggested corrections, and a summary.

[0045] In traditional text generation tasks, word overlap rate-based evaluation metrics are widely used. However, in code change generation scenarios, such metrics often fail to effectively reflect the true quality of the generated results. This is because, for the same code change objective, there are usually multiple semantically and functionally equivalent feasible implementations, while word overlap rate metrics typically rely on matching with a single reference text, making it difficult to characterize the diversity of reference answers. Therefore, even if the generated code change is functionally and semantically reasonable and correct, it may still be assigned a lower score if its expression differs from the reference text, thus limiting the applicability of such metrics in evaluating the quality of code change generation.

[0046] To test the effectiveness of the code change generation method of this invention, we used the accuracy of deleted lines, the accuracy of added lines, and lexical-level edit similarity as evaluation metrics. Specifically, this embodiment uses the deleted lines labeled in the benchmark dataset as a reference to calculate the matching accuracy between the deleted lines in the generated code change and the benchmark deleted lines, which is used to measure the model's ability to identify and remove inapplicable code. Furthermore, by comparing the newly added lines in the benchmark dataset with the newly added lines in the generated results, the accuracy of added lines is calculated to evaluate the correctness and completeness of the generation method when incorporating relevant code from the target library. In addition, to avoid the limitations of relying solely on line-by-line precise matching, this embodiment introduces lexical-level edit similarity to measure the closeness of the generated code and the migrated source code file in terms of overall structure and content, thus tolerating equivalent but differently expressed implementations. Through the comprehensive use of the above multi-dimensional evaluation metrics, the actual effect and application value of this invention in the code change generation task can be reflected more comprehensively and objectively. The final comparison results are shown in Table 1. Table 1 As can be seen from Table 1, the present invention outperforms the Pymigbench method in terms of accuracy in deleting lines, accuracy in adding lines, and word-level edit similarity score. This demonstrates that the present invention has a better performance in accurately locating the site to be migrated and generating the correct code changes.

[0047] The above description of the embodiments is provided to enable those skilled in the art to understand and apply the present invention. Those skilled in the art can readily make various modifications to the above embodiments and apply the general principles described herein to other embodiments without creative effort. Therefore, the present invention is not limited to the above embodiments, and any improvements and modifications made to the present invention by those skilled in the art based on the disclosure thereof should be within the scope of protection of the present invention.

Claims

1. A code change generation method based on a multi-agent agent library migration scenario, characterized in that, Includes the following steps: (1) Collect the source code files to be migrated and their corresponding source library names and target library names; (2) Use search tools to determine the key identification information of the source library, construct an abstract syntax tree and control flow structure for the source code files, and combine dependency propagation and text feature matching to obtain migration-related nodes; (3) Input the scope information of the migration-related nodes and the source library name as prompt words into the localization agent, and the localization agent outputs the structured site to be migrated; (4) Input the information of the sites to be migrated, the source library name and the source code file as prompt words into the planning agent. The planning agent calls the search tool to determine the key API knowledge and generates the migration plan for each site to be migrated. (5) Input the source code file, source library name, target library name, migration site, key API knowledge and migration plan as prompt words into the change generation agent, and output the migration-related code changes; (6) Input the source code file, code changes, and scoring criteria as prompt words into the verification agent, and the verification agent scores the code changes and determines the final code changes.

2. The code change generation method based on multi-agent agent library migration scenario according to claim 1, characterized in that, The specific implementation method of step (1) is as follows: 1.1 Obtain the existing benchmark dataset, in which each migration record contains the code repository, commit information, source repository name, and target repository name; Build an API request, clone the code repository to the local machine, extract the file locations that were migrated from the commit information, and read the source code files before and after the migration; 1.2 Delete data whose file directory changed before and after migration, filter library migration data with long-tail characteristics, that is, use the data programming paradigm to identify and filter library migration data related to Django library, use the difflib tool to process the source code files before and after migration, and generate corresponding code change file pairs.

3. The code change generation method based on multi-agent agent library migration scenario according to claim 1, characterized in that, The specific implementation method of step (2) is as follows: 2.1 Construct a search request using the name of the source library, call the API of the search tool to obtain the search results, and call the API of the DeepSeek model based on the search request and search results to summarize the search results and generate the import name of the source library; 2.2 The source code before migration is parsed using the AST tool to construct an abstract syntax tree. Based on this, the scope of the source code is divided into modules, classes, and functions. The call relationships between different scopes are identified to construct a call dependency structure. Each node in this structure corresponds to a code scope in the source code. The code scope includes module scope, function scope, or class scope. Each node stores information including the scope identifier, start line number, and end line number. The edges between nodes represent the call dependencies between different code scopes. The direction of the directed edges is from the caller to the callee. 2.3 Based on the import name and abstract syntax tree of the source library, all variable access, property access, and function call nodes are traversed in the abstract syntax tree to identify syntax nodes related to the source library. When a node contains a use of the source library, it is marked as a migration-related node, and the migration-related markers are propagated along the call direction to other nodes that have dependencies on it based on the call dependency relationship. For code lines related to the source library in the module scope, consecutive or adjacent code lines are merged into module-level code fragments according to their line numbers and included as independent nodes in the call dependency relationship structure. Finally, the migration-related nodes and the start and end positions of their corresponding code scopes are output.

4. The code change generation method based on multi-agent agent library migration scenario according to claim 1, characterized in that, In step (3), the scope information of the migration-related nodes and the source library name are input as prompt words to the localization agent, guiding the localization agent to output the structured migration sites within the scope. The migration sites contain the following information: The name of the code region where the migration site is located: function name, class name, or module name; The start and end line numbers of the code region where the migration site is located; The specific code content of the code block for the site to be migrated.

5. The code change generation method based on multi-agent agent library migration scenario according to claim 1, characterized in that, The specific implementation method of step (4) is as follows: 4.1 The information of the site to be migrated and the name of the source library are used as prompt words to prompt the planning agent to output a list of APIs to be migrated. The list contains the certainty of the migration knowledge of each API. When the planning agent determines how to migrate a certain API, it assumes that it has knowledge of that API and marks that API as an API that does not need to be searched. Otherwise, it is marked as an API that needs to be searched. 4.2 For the APIs marked as needing to be searched in the API list, construct search requests for each of these APIs and call the search tool to search how these APIs were migrated to the target library. Filter the knowledge content returned by the search using keywords to obtain the final list of key API knowledge. 4.3 Input the sites to be migrated, the list of APIs to be migrated, the list of key API knowledge, the source library name, the target library name, and the source code file into the planning agent, and guide the planning agent to output a structured migration plan for each site to be migrated, including migration steps, possible API mappings, rows to be deleted, content to be added, and the confidence level of the plan.

6. The code change generation method based on multi-agent agent library migration scenario according to claim 1, characterized in that, In step (5), the agent generates a change based on the location to be migrated in the prompt words, combined with the content of the source code file, and performs migration according to the migration plan, generating and outputting migration-related code changes.

7. The code change generation method based on multi-agent agent library migration scenario according to claim 1, characterized in that, The specific implementation method of step (6) is as follows: 6.1 Input the code change, source library name, target library name, and multi-dimensional scoring criteria as prompt words into the verification agent. The verification agent analyzes the code change scores in the four dimensions according to the scoring criteria and uses the sum of the scores in the four dimensions as the score of the code change in this round. 6.2 The total score is set to 10 points, with a passing score of 6 points. When the score output by the verification agent in this round is greater than or equal to 6 or the current verification round number exceeds 3, the verification is exited and the currently generated code changes are output. When the score output by the verification agent in this round is less than 6 and the current verification round number is less than 3, the verification agent outputs a verification report and returns the verification report to the change generation agent. The change generation agent regenerates new code changes based on the verification report and starts a new round of verification.

8. The code change generation method based on the multi-agent agent library migration scenario according to claim 7, characterized in that, The four dimensions of the scoring criteria analysis include: Correctness of migration: This dimension accounts for 4 points and is used to measure whether the code changes are in line with functional correctness, such as whether non-existent APIs or non-existent parameters have been introduced. Completeness of migration: This dimension accounts for 3 points and is used to measure whether the code changes have been completely migrated, whether the use of the source library has been completely removed and replaced with the use of the target library; Best practices for migration: This dimension accounts for 1 point and is used to measure whether the code changes generated during the migration process follow the recommended usage of the target library and do not use deprecated or not recommended methods; Correctness of code changes: This dimension accounts for 2 points and is used to measure whether the generated code changes have syntax errors or formatting errors.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: The processor is used to execute the computer program to implement the code change generation method based on the multi-agent agent library migration scenario as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by the processor, it implements the code change generation method based on the multi-agent agent library migration scenario as described in any one of claims 1 to 8.

Images