Method, device and medium for code review based on role division of multiple review agents

Abstract

This invention discloses a collaborative code review method, device, and medium based on role-based division of labor among multiple review agents, relating to the field of artificial intelligence. The method includes: responding to a code review trigger event, acquiring the code to be reviewed and related context information, and preprocessing it to generate a standardized context data packet; synchronously distributing the context data packet to at least two review agents, each configured to specialize in a different code quality dimension; each review agent independently and in parallel reviewing the data packet based on a review strategy customized for its corresponding dimension, and generating structured results; aggregating all structured results and performing automated processing, including deduplication, conflict resolution, and priority ranking; and generating and outputting a code review report based on the processing results. This invention achieves deeply specialized, highly efficient, parallel, and structured automated code review.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a collaborative code review method, device and medium based on role division of labor among multiple review agents. Background Technology

[0002] In the field of automated code review, with breakthroughs in large-scale language model technology, an intelligent solution based on a single large-scale language model has emerged, representing the current mainstream direction. This solution typically utilizes a model that has been fine-tuned with code data or possesses strong general-purpose capabilities. Through carefully designed comprehensive prompts, it guides the model to analyze the input code snippets and related contexts from multiple perspectives. Specifically, the implementation process is roughly as follows: First, the system collects the code changes to be reviewed and their related documents, combining them into input text; next, it constructs a set of review prompts designed to cover multiple dimensions such as correctness, security, performance, and maintainability; then, the integrated input is submitted to the single model for processing; finally, in a single inference process, the model attempts to understand various levels of the code and generates a review opinion containing various potential issues and suggestions.

[0003] The inventors of this application have discovered inherent limitations in this centralized processing paradigm. Because all analysis tasks are handled by the same model within a single call, its internal computational resources and attention mechanisms are insufficient for performing equally in-depth specialized analysis of each professional dimension of the code. This results in limited ability to detect complex logical vulnerabilities or advanced security risks requiring deep domain knowledge. Furthermore, the model's output is typically a mixture of natural language text or simple lists containing questions of different natures and priorities. The results lack a unified, machine-understandable structure, making subsequent automatic classification, prioritization, and task assignment extremely difficult, heavily reliant on manual secondary processing, and reducing the immediacy and operability of feedback. Moreover, the entire review process is essentially serial, whether implicitly serial within the model or explicitly serial through multiple calls. The overall time consumption is the sum of the analysis time for each dimension, creating a bottleneck in review efficiency. Summary of the Invention

[0004] This invention provides a collaborative code review method, device, and medium based on role-based division of labor among multiple review agents. The technical problem it aims to solve is: how to provide an effective automated code review solution that can achieve in-depth professional analysis, efficient parallel processing, and output structured and operable results.

[0005] In a first aspect, embodiments of the present invention provide a collaborative code review method for multiple review agents based on role division of labor, comprising: In response to a code review trigger event, obtain the code to be reviewed and related context information; The code to be reviewed and related context information are preprocessed to generate a standardized context data packet; The context data packet is synchronously distributed to at least two review agents; each review agent is configured to specialize in a different code quality dimension. Each review agent independently and in parallel reviews the context data packet based on a review strategy customized for the corresponding code quality dimension, and generates a structured result containing problem information. The structured results generated by all review agents are aggregated, and the aggregated structured results are processed automatically, including at least one of deduplication, conflict resolution, and priority sorting. Based on the results of the automated processing, a code review report is generated and output.

[0006] Optionally, the method further includes: Configure the first review agent to specialize in reviewing the correctness of business logic; Configure a second review agent to specialize in code security-related reviews; Configure a third review agent to specialize in reviewing performance metrics; Configure a fourth review agent to specialize in reviewing code maintainability. Configure a fifth review agent to specialize in reviewing user experience accessibility dimensions.

[0007] Optionally, the response to the code review trigger event includes: Monitor the event stream of the integrated version control system; When a predefined code commit event occurs in the event stream, the code commit event is captured as the code review trigger event.

[0008] Optionally, the preprocessing of the code to be reviewed and related context information to generate a standardized context data packet includes: The code to be reviewed is parsed to generate an abstract syntax tree, and the abstract syntax tree is then subjected to structural normalization processing. Based on the relevant context information, collect supplementary context information associated with the code to be reviewed; Extract metadata associated with the project to which the code to be reviewed belongs; The abstract syntax tree that has undergone structural normalization, the collected supplementary context information, and the extracted metadata are assembled and encapsulated to generate the context data package.

[0009] Optionally, the method further includes: Configure dedicated system prompts containing key points of business logic review for the first review agent specializing in the correctness of business logic. For the second review agent specializing in code security, a hybrid strategy is configured that includes a security vulnerability rule base and security review-specific prompts; For a third-party review agent specializing in performance metrics, a few-shot learning strategy is configured, which includes performance anti-pattern examples and performance review-specific prompts. For the fourth review agent specializing in code maintainability, configure a hybrid strategy that includes code style rules and maintainability review-specific prompts; Configure a strategy that includes accessibility standards and user experience review-specific prompts for the fifth review agent, which specializes in the accessibility dimension of user experience.

[0010] Optionally, generating a structured result containing problem information includes: Each review agent generates one or more structured result entries based on the review results. The structured result entries include at least: a problem description field for describing the problem, a code location field for locating the code location, a severity level field for identifying the severity of the problem, and a repair suggestion field for providing modification suggestions. Each review agent encapsulates one or more structured result entries into a predefined data packet and outputs it.

[0011] Optionally, the automated processing of the aggregated structured results includes: A unique fingerprint is calculated based on the core content of the code location field and the problem description field in each structured result entry; Cluster all structured result entries based on the calculated unique fingerprints, and merge entries belonging to the same cluster into a representative entry; If multiple representative entries point to overlapping code locations and have different severity level fields, the highest severity level is selected from the different severity level fields as the final severity level of the code location, according to a predefined severity level value mapping table. Based on the final severity level, and combined with the impact scope assessment value and the repair complexity assessment value of the corresponding issues for the representative items, a comprehensive priority score is calculated for each representative item; wherein, the impact scope assessment value is determined based on the scope of files or modules affected by the issue in the code structure, and the repair complexity assessment value is determined based on the size of the code to be modified and the complexity of the associated dependencies required to repair the issue; All representative items are sorted in descending order of their overall priority scores.

[0012] Optionally, generating and outputting the code review report includes: The automated processing result set is populated according to a predefined machine-readable format template to generate a first-format review report; the first-format review report is in JSON or XML format. The automated result set is populated according to a predefined human-readable template to generate a second-format review report; the second-format review report is in Markdown or HTML format. In the second format review report, the identification information of the review agent from which the result entry originated is marked.

[0013] Secondly, embodiments of the present invention also provide a computer device, which 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 method.

[0014] Thirdly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0015] This invention provides a method, device, and medium for collaborative code review by multiple review agents based on role-based division of labor. The method includes: in response to a code review trigger event, acquiring the code to be reviewed and related context information; preprocessing the code to be reviewed and related context information to generate a standardized context data packet; synchronously distributing the context data packet to at least two review agents; wherein each review agent is configured to specialize in a different code quality dimension; each review agent independently and in parallel reviews the context data packet based on a review strategy customized for its corresponding code quality dimension, generating a structured result containing issue information; aggregating the structured results generated by all review agents, and automatically processing the aggregated structured results, the automated processing including at least one of deduplication, conflict resolution, and priority ranking; and generating and outputting a code review report based on the results of the automated processing. This invention effectively solves the core defects of existing automated code review by constructing a system architecture in which multiple specialized review agents work in parallel and collaboratively. Specifically, the comprehensive review task is broken down into multiple specialized review sub-tasks, which are executed simultaneously by various specialized review agents. This allows each review agent to conduct in-depth, focused analysis on its specific quality dimension of expertise, significantly improving the professionalism of the review and its ability to discover deep-seated issues such as complex logical vulnerabilities and advanced security risks. Furthermore, because multiple review agents work in parallel, the overall review time is determined by the processing time of the slowest individual review agent, rather than the sum of the review times for each dimension, thus greatly improving review efficiency. Furthermore, each review agent outputs standardized, structured results, which are intelligently integrated and prioritized through subsequent automated processing, directly generating clearly categorized and highly operable review reports, avoiding the burden of manually sorting through mixed results. Finally, the solution retains independent judgment across multiple dimensions and clarifies conflict resolution rules, providing developers with a clear and comprehensive technical perspective to assist them in making comprehensive decisions. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a collaborative code review method for multiple review agents based on role division of labor, provided in an embodiment of the present invention; Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0018] 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, not all, of the embodiments of the present invention. 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.

[0019] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0020] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0021] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0023] Please see Figure 1 This invention provides a collaborative code review method for multiple review agents based on role division of labor, the method comprising the following steps: S1, in response to a code review trigger event, obtains the code to be reviewed and related context information.

[0024] In practical implementation, the steps responding to code review trigger events can be achieved through a pre-defined automated listening mechanism. For example, the system can be integrated with a version control system such as Git, continuously monitoring specific activities in the code repository via webhooks or event listeners. When a developer creates or updates a pull request, the version control system generates a corresponding event notification. This event notification is received and used as a code review trigger event, automatically executing subsequent processes. Based on information in the event, such as the hash value of the code commit or branch information, the specific code file content involved in this commit is retrieved from the code repository as the code to be reviewed. Simultaneously, the system can also obtain contextual information associated with this commit, such as commit comments written by the committer, associated task management number, or requirement document identifier; however, this invention does not specifically limit the scope of this information.

[0025] In some preferred embodiments, responding to a code review trigger event includes: listening to the event stream of the integrated version control system; when a predefined code commit event occurs in the event stream, capturing the code commit event as the code review trigger event; the predefined code commit event includes a pull request creation event or a merge request creation event.

[0026] In practice, the first step is to monitor the event flow of the integrated version control system. This is specifically achieved by configuring and enabling the event hooks or webhook functionality provided by the version control system. For example, on platforms such as GitLab, GitHub, or Gitee, the administrator configures a webhook URL in the project settings that points to the endpoint receiving the review system, and specifies the types of events to be monitored, such as push events and merge request events. The review system deploys a continuously running event monitoring service that exposes an HTTP API endpoint to receive HTTP POST requests sent from the version control system. Each request payload contains detailed event data. Alternatively, another implementation method could be for the review system to periodically poll the activity status of specific repositories or branches through the API provided by the version control system to detect new events.

[0027] Furthermore, when a predefined code commit event appears in the event stream, capturing this code commit event as a code review trigger event involves event filtering and parsing. After receiving the original event notification, the event listening service first parses the event payload, extracting metadata such as the event type field, repository information, branch information, and commit hash. Next, the event listening service matches the event type against a predefined list of event types that need to trigger a review. This predefined list typically includes at least pull request creation events and merge request creation events, and may also include push events to a specific branch. When a match is successful, the event listening service marks this event as a valid code review trigger event and extracts key parameters, such as the source branch, target branch, merge request number, and associated commit hash list. These parameters are then passed to the subsequent code retrieval module for precise location and retrieval of the specific code changes requiring review.

[0028] This invention, through an automated triggering mechanism based on an integrated version control system event flow, seamlessly embeds the review process into the workflow of modern software development. This achieves both immediacy and passivity in the review process; the review action is naturally triggered by the developer's routine collaborative behavior, without requiring additional manual submissions. When a developer creates a pull request or merge request intending to integrate code, the system automatically captures this event and initiates a review, ensuring that every code change intended to be incorporated into the main branch receives timely quality control. This automated triggering method eliminates the delays and potential oversights of manual intervention, guaranteeing the mandatory and consistent nature of the review process and facilitating the early detection and remediation of defects in the software development lifecycle. Furthermore, because the trigger is directly associated with the specific code commit context, subsequent steps can accurately obtain the code differences and contextual information most relevant to the change, laying the foundation for efficient and accurate reviews.

[0029] S2, preprocess the code to be reviewed and related context information to generate a standardized context data packet.

[0030] In practice, the preprocessing step for the code to be reviewed and related contextual information aims to transform the raw, heterogeneous input data into a unified, standardized, and semantically rich information package for efficient processing by the subsequent review agent. This step involves multiple processing units. The code parsing unit is responsible for performing lexical and syntactic analysis on the acquired code to be reviewed, constructing an abstract syntax tree representing the code's hierarchical structure. Further, to eliminate noise from different code formats, the structure normalization unit performs operations such as standardizing indentation formats and standardizing identifier naming temporary representations on the abstract syntax tree. Further, the context collection unit, based on the acquired relevant contextual information, such as keywords in submission comments, further retrieves relevant design documents, interface protocol descriptions, etc., from the project document library or knowledge base to form supplementary contextual information. Further, the metadata extraction unit extracts metadata such as project type, main technical framework, key dependency libraries and their versions from the project's configuration files, such as pom.xml or package.json. Furthermore, the data assembly unit assembles and encapsulates the structure-normalized abstract syntax tree, the collected supplementary context information, and the extracted metadata into a complete context data package, such as a JSON object, according to a predefined key-value pair or serialization format.

[0031] In some preferred embodiments, the preprocessing of the code to be reviewed and related context information to generate a standardized context data package includes: parsing the code to be reviewed to generate an abstract syntax tree (AST), and performing structural normalization on the AST; collecting supplementary context information associated with the code to be reviewed based on the related context information; extracting metadata associated with the project to which the code to be reviewed belongs; and assembling and encapsulating the structurally normalized AST, the collected supplementary context information, and the extracted metadata to generate the context data package.

[0032] In practice, the first step is to parse the code to be reviewed, generate an abstract syntax tree (AST), and then perform structural normalization on this AST. This process is fundamental to understanding the static structure of the code. Specifically, the system calls a parser library that matches the project's primary programming language, such as Eclipse JDT for Java, the ast module for Python, or the Babel parser for JavaScript. The parser reads the source code text, performs lexical and syntactic analysis, and outputs a tree-like data structure representing the code's syntactic structure—the AST. Further, the structural normalization module operates on this tree, including but not limited to: traversing the tree nodes, standardizing the representation of whitespace characters and indentation; replacing specific variable names, function names, and other identifiers in the code with standardized placeholders or typed labels to achieve a certain degree of abstraction, facilitating subsequent pattern matching; and performing simple syntactic sugar transformations to convert some syntactic structures into more standard forms. The purpose of this step is to reduce noise caused by differences in code formatting and to produce a standardized structural representation that is more conducive to programmatic analysis.

[0033] Furthermore, the step of collecting supplementary contextual information associated with the code to be reviewed, based on relevant contextual information, aims to enrich the semantic background of the code. The context collection module in this embodiment utilizes initial contextual information obtained from triggering events, such as task numbers or keywords in submission comments, for extended retrieval. For example, the context collection module can connect to the project's issue tracking system and retrieve associated requirement descriptions or defect reports by task number; or, it can search the project document directory for design documents and API descriptions related to the modified file; in addition, it can analyze the differences in the submitted code, identify the relevant call chains of the modified function or method, and obtain code snippets of the caller or callee from the code repository as supplementary context, which is not specifically limited in this invention. These collected texts and code snippets are organized and appended to the context information set.

[0034] Furthermore, the step of extracting metadata associated with the project to which the code to be reviewed belongs provides project-level environment parameters for the review. The metadata extraction module further scans configuration files in the project root directory, such as pom.xml, build.gradle, package.json, and requirements.txt. From these files, the module extracts key information such as the project name, the language version used, dependencies and version numbers of major frameworks and libraries, and the project build method. This metadata further helps the subsequent review agent adjust its analysis strategy based on the project's technology stack; for example, for projects using a specific security framework, the security review agent can adjust its rule weights.

[0035] The final step in data preparation is to assemble and encapsulate the structured, normalized abstract syntax tree, collected supplementary context information, and extracted metadata to generate a context data package. Further, the assembly module organizes these three data components according to a predefined schema acceptable to all review agents. For example, it encapsulates them into a JSON object, with top-level fields including `ast`, `context`, and `metadata`. The `ast` field stores the serialized representation of the normalized abstract syntax tree; the `context` field is a list or object containing submission information, associated documents, related code snippets, etc.; and the `metadata` field stores the extracted project technology stack information. This data package is ultimately serialized into a string or binary format, ready to be distributed to each review agent.

[0036] This embodiment ensures the quality and consistency of data input to the subsequent parallel review stage by specifying detailed preprocessing steps. Generating an abstract syntax tree and performing normalization transforms the source code from text to a precise and uniform structured representation, providing a stable and reliable foundation for code structure analysis for all review agents. This eliminates interference from format differences, making syntax tree-based pattern matching and semantic analysis more accurate. Furthermore, proactively collecting supplementary contextual information overcomes the limitations of analyzing only isolated code fragments, providing review agents with crucial materials for understanding code intent and business context. For example, related requirements documents help determine the correctness of business logic implementation, significantly improving the context awareness and depth of the review. Further, extracting project metadata provides environmental parameters for the review, enabling each review agent to implement more targeted analysis strategies, such as enabling corresponding security rules based on the framework version. Finally, assembling this heterogeneous information into standardized data packets provides multiple review agents with complete and uniformly formatted input. This is a crucial prerequisite for achieving efficient and accurate parallel collaborative review, effectively solving the problem of unstable review quality caused by insufficient or inconsistent input information.

[0037] S3, the context data packet is synchronously distributed to at least two review agents; wherein each review agent is configured to specialize in a different code quality dimension.

[0038] In practice, a registry of review agents is maintained. When a context data packet is generated, the task coordinator simultaneously sends a copy of the context data packet to all active review agents in the registry, or to a specific group of review agents selected based on project metadata. This distribution can be implemented using a publish-subscribe pattern with a message queue, where the coordinator acts as a producer, publishing the data packet to a specific topic, and each review agent acts as a consumer, subscribing to the topic and receiving messages simultaneously. Alternatively, it can be implemented through parallel HTTP requests or RPC calls; this invention is not specifically limited to either method. This step ensures that each review agent begins its review work at the same time or within a very short time interval.

[0039] It should be noted that the review agent is a software functional unit in a multi-review agent collaborative code review system that undertakes specific specialized analysis responsibilities. Each review agent is pre-configured to specialize in a single code quality dimension, such as business logic correctness, code security, or performance. Its core feature is that it works according to a review strategy specifically tailored for that dimension, which defines its analysis logic and knowledge sources. The review agent receives standardized context data packets as input and independently executes its analysis process within its specialized domain, a process that is independent of the timing and resources of other review agents. After analysis, the review agent strictly follows predefined output specifications to generate structured result data containing problem location, description, severity level, and remediation suggestions. At the implementation level, the review agent is a module that encapsulates specific review capabilities and standardized interfaces. Its underlying technology can employ various methods such as rule-based engines, traditional machine learning models, large language models, or combinations thereof, and this invention does not specifically limit it. The essence of the review agent is to provide modular, scalable, and clearly defined analysis services within the collaborative system.

[0040] In some preferred embodiments, the method further includes: configuring a first review agent specializing in reviewing the correctness of business logic; configuring a second review agent specializing in reviewing the code security dimension; configuring a third review agent specializing in reviewing the performance dimension; configuring a fourth review agent specializing in reviewing the code maintainability dimension; and configuring a fifth review agent specializing in reviewing the user experience accessibility dimension.

[0041] In specific implementation, a first review agent is configured to specialize in reviewing the correctness of business logic. Specifically, this first review agent is designed to understand the business processes and rules of a specific application domain. Its implementation includes: during the initialization phase of the first review agent, loading a knowledge source containing a domain knowledge graph or business rule base; simultaneously, configuring dedicated system prompts for its large language model. These prompts explicitly instruct the model to analyze from the perspectives of business logic completeness, process compliance, and data processing accuracy, and may include few-sample examples targeting common business logic defects. When the first review agent receives the context data packet, it pays particular attention to the parts of the code related to business process control, state transitions, data validation, and calculation rules, using its specialized configuration to identify any contradictions or vulnerabilities that deviate from business requirements or design logic.

[0042] Furthermore, a second review agent is configured to specialize in code security reviews. Its implementation focuses on identifying security threats. Upon initialization, this second review agent integrates a continuously updated security vulnerability rule base, containing detection rules for known vulnerability patterns such as SQL injection, cross-site scripting, and insecure deserialization. Simultaneously, its dedicated system prompts guide the model to perform deep reasoning from attack surface analysis, data flow security, and permission verification perspectives to discover new or complex security risks that exceed the fixed rule base. During the review, this second review agent uses static rule matching and model-based semantic analysis in parallel to perform security checks on data flow, function calls, and external interface interactions within the code.

[0043] Furthermore, a third review agent is configured to specialize in performance-oriented reviews. Its implementation focuses on code execution efficiency and resource consumption. This third review agent is configured with a few-shot learning strategy that includes examples of performance anti-patterns, demonstrating common performance issues such as inefficient queries within loops, improper caching, and signs of memory leaks. Its dedicated prompts guide the model to analyze algorithm complexity, database access patterns, network request frequency, and concurrency mechanisms. By analyzing the code structure within context data packets, this third review agent identifies potential bottlenecks and optimizable code segments, and assesses their potential impact on system response time or resource utilization.

[0044] Furthermore, a fourth review agent is configured to specialize in reviewing code maintainability. Its implementation aims to assess and improve the long-term health of the code. This fourth review agent integrates a coding style rule base, including rules for checking naming conventions, function length, code duplication rate, and comment completeness. Simultaneously, its specialized prompts guide the model to evaluate from the perspectives of module coupling, cohesion, appropriate application of design patterns, and code complexity. By combining rule matching with the model's understanding of the code structure, this fourth review agent provides suggestions on code refactoring, module partitioning, and documentation improvement.

[0045] Furthermore, a fifth review agent is configured to specialize in reviewing user experience accessibility dimensions. Its implementation primarily targets front-end or user interface-related code. This fifth review agent is configured with relevant accessibility standards, such as the WCAG guidelines, and user experience design principles. Its dedicated prompt word indicator model reviews the fluency of user interaction logic, the usability of interface elements, compatibility with assistive technologies, and the appropriateness of responsive design. For front-end code, the fifth review agent analyzes event handling, state management, rendering logic, and style definitions to identify issues that may cause user confusion, operational inconvenience, or accessibility barriers.

[0046] In some preferred embodiments, a first review agent specializing in the correctness of business logic is configured with dedicated system prompts containing key points of business logic review; a second review agent specializing in code security is configured with a hybrid strategy containing a security vulnerability rule base and dedicated security review prompts; a third review agent specializing in performance is configured with a few-shot learning strategy containing performance anti-pattern examples and dedicated performance review prompts; a fourth review agent specializing in code maintainability is configured with a hybrid strategy containing code style rules and dedicated maintainability review prompts; and a fifth review agent specializing in user experience accessibility is configured with a strategy containing accessibility standards and dedicated user experience review prompts.

[0047] In practice, a dedicated system prompt word containing key points for business logic review is configured for the primary review agent specializing in business logic correctness. This is achieved by designing and refining a system instruction for initializing the large language model. This prompt word explicitly requires the model to act as a "business logic expert" and lists key review points, such as: checking the completeness of data validation rules, whether the state transitions of the business process conform to the design, whether the business calculation rules are accurate, whether exception handling covers all business exception scenarios, and whether the code logic is consistent with the accompanying user stories or requirement descriptions. The prompt word may embed project-specific business terms and rule summaries to enhance the model's domain understanding.

[0048] Furthermore, for the second review agent specializing in code security, a hybrid strategy is configured, including a security vulnerability rule base and security review-specific prompts. This implementation combines static analysis and dynamic prompts. The security vulnerability rule base is an independent rule engine, loading vulnerability detection rule sets from authoritative sources such as OWASP for different languages ​​and frameworks, used for quickly scanning known vulnerability patterns. Simultaneously, security review-specific prompts guide the model to perform more flexible, context-based reasoning, such as analyzing the propagation path of user input throughout the data flow to identify potential injection points, checking the processing and storage of sensitive data (such as keys and tokens), assessing the soundness of authentication and authorization logic, and identifying insecure dependencies or configurations. During runtime, rule base scanning and model reasoning can be performed in parallel or in series, with the results complementing each other.

[0049] Furthermore, for the third-party review agent specializing in performance metrics, a few-shot learning strategy is configured, including examples of performance anti-patterns and performance review-specific prompts. Implementation requires building an example library containing typical performance anti-pattern code snippets and their optimization schemes. These examples are encoded into the prompts provided to the model, serving as the context for few-shot learning. The performance review-specific prompts instruct the model to focus on the following aspects: identifying algorithms with high time complexity (such as nested loops), checking for duplicate computations or redundant queries, evaluating the efficiency of resource acquisition and release (such as database connections and file handles), analyzing the effectiveness of caching strategies, and addressing lock contention issues in concurrent scenarios. Through the combination of examples and prompts, the model can better identify and interpret performance bottlenecks in the code.

[0050] Furthermore, for the fourth review agent specializing in code maintainability, a hybrid strategy is configured, incorporating code style rules and maintainability review-specific prompts. The code style rule base contains a series of automatically checkable coding standards, such as checking code complexity, duplication rate, and naming conventions using tools. Maintainability review-specific prompts guide the model to evaluate at a higher level, such as assessing adherence to the single responsibility principle of modules or classes, analyzing coupling between code segments, identifying excessively long function or parameter lists, checking code testability (e.g., the presence of dependencies that are difficult to simulate), and evaluating the clarity and timeliness of comments and documentation. The model's prompt-based analysis can be combined with the quantitative results from the rule base to provide a comprehensive maintainability evaluation.

[0051] Furthermore, a strategy is configured for the fifth review agent, specializing in the user experience accessibility dimension, including accessibility criteria and user experience review-specific cue words. In implementation, accessibility criteria can be integrated in checklist form, such as a summary of WCAG 2.1 success criteria. User experience review-specific cue words guide the model in reviewing front-end code: checking the keyboard operability of user interface controls, assessing the clarity of visual feedback, analyzing the coherence and fault tolerance of interaction flows, identifying potentially confusing text or labels, and evaluating the reasonableness of operation steps from the user's perspective. For web applications, the cue words may also guide the model to consider the impact of responsive layout and loading performance on the experience.

[0052] This embodiment transforms review agents from general models into domain experts by configuring highly customized strategies for review agents across different dimensions. Furthermore, dedicated system prompts provide each review agent with a precise definition of the review task and a framework for thinking, ensuring that its analysis process is highly focused on the target dimension, thereby guiding the model to uncover deeper, more professionally compliant issues. Furthermore, the introduction of hybrid strategies, particularly combining rule-based deterministic analysis with prompt-based generative reasoning, achieves both the accuracy and efficiency of rules and the flexibility and depth of the model. For example, the security review agent can quickly locate known vulnerabilities through the rule base and discover novel attack vectors or logical vulnerabilities through model reasoning. Furthermore, the few-shot learning strategy provides the model with directly referable pattern examples, accelerating its learning and understanding of specific types of problems (such as performance anti-patterns) and improving the accuracy and practicality of review recommendations.

[0053] S4, each review agent independently and in parallel reviews the context data packet based on a review strategy customized for the corresponding code quality dimension, and generates a structured result containing problem information.

[0054] In practice, the core of the method lies in the step where each review agent independently and in parallel reviews the context data packet based on a review strategy customized for its corresponding code quality dimension, generating a structured result containing problem information. Each review agent is an independent service or process. For example, a review agent specializing in code security might have its internally configured security review prompts guiding it to focus on patterns such as injection vulnerabilities and sensitive information leaks; its integrated security vulnerability rule base can provide static rule matching. After loading the context data packet, this review agent comprehensively utilizes its prompts and rule base to perform in-depth code analysis. The analysis process is completely independent of other review agents and is not affected by the processing progress or results of other review agents.

[0055] Each review agent employs a modular architecture, with a core of dedicated prompting engineering and a strategy engine, along with a hybrid reasoning mode. The dedicated prompting engineering and strategy engine stores and manages review strategies tailored to the agent's specialized dimensions, such as specific system prompts, few-sample examples, or static rule sets. The hybrid reasoning mode means that when analyzing context data packets, the review agent does not rely solely on a large language model, but dynamically combines multiple technical means for comprehensive reasoning based on its specialized dimensions. For example, a review agent specializing in code security first uses a built-in security vulnerability rule base to perform rapid pattern matching on the abstract syntax tree to identify known vulnerabilities; simultaneously, it submits the code context and security review-specific prompts to a large language model for deep semantic analysis and contextual reasoning to discover potential, unknown security risk patterns or logical vulnerabilities. Similarly, other review agents combine the output of static analysis tools, the query results of knowledge graphs, and the generation capabilities of large language models according to their review objectives, thereby achieving in-depth, accurate, and reliable specialized reviews.

[0056] After the analysis is complete, the review agent generates one or more structured result entries according to a predefined structure, such as a JSON object containing the code file path, line number, issue type, severity, description, and recommendations, and returns them as output.

[0057] In some preferred embodiments, generating structured results containing problem information includes: each review agent generating one or more structured result entries based on the review results, wherein each structured result entry includes at least: a problem description field for describing the problem, a code location field for locating the code location, a severity level field for identifying the severity of the problem, and a repair suggestion field for providing modification suggestions; each review agent encapsulating the one or more structured result entries into a predefined format data packet for output.

[0058] In practice, the first step involves each review agent generating one or more structured result entries based on the review results. This process transforms internal analysis conclusions into standard data units. Specifically, after completing its analysis logic, each review agent iterates through all potential problem points it has identified. For each problem point, the review agent creates a new data object conforming to a predefined schema—a structured result entry. This result entry is not free text but consists of multiple fields with clear semantics. The problem description field concisely and objectively states the essence of the problem in natural language, such as "user input was concatenated into an SQL query statement without validation." The code location field precisely locates the source code where the problem occurs, typically including the repository path of the source code file, the start and end line numbers, and in some cases, column numbers or code snippet hashes. Furthermore, the severity level field is a classification label used to identify the severity of the problem, usually selected from a predefined enumeration set, such as "Severe," "High," "Medium," "Low," or "Hint." Finally, the remediation suggestion field provides specific and actionable modification suggestions, such as "It is recommended to use a parameterized query interface to construct SQL statements to avoid SQL injection risks." When the review agent populates these fields, it invokes its internal logic to determine the severity level and generates targeted remediation suggestions based on its understanding of the code.

[0059] Furthermore, the step of each review agent encapsulating one or more structured result entries into a predefined formatted data packet for output ensures the standardization of result transmission. Once all issue entries have been generated, the review agent organizes these entries into a list or array. This list, then used as core data, is encapsulated along with other possible metadata (such as the review agent's own ID, review task ID, review time, etc.) into a larger, fixed-format container. This predefined format is typically a widely supported serialization format, such as JSON or Protocol Buffers. Using JSON as an example, the final output data packet might be a JSON object containing a field named `issues` whose value is an array of JSON objects representing structured result entries. Finally, after encapsulation, the review agent sends this data packet to the result aggregation center via previously established communication channels, such as HTTP responses, message queue publications, or RPC call returns.

[0060] This embodiment creates crucial conditions for subsequent aggregation and automated processing by forcing each review agent to output structured result items with a uniform structure and encapsulating them into standardized data packets. The structured result items deconstruct key information that might otherwise be mixed in with natural language paragraphs, including problem descriptions, locations, severity levels, and recommendations, into independent data fields that can be clearly identified and processed by machines. This deconstruction allows the subsequent system to directly access and manipulate each review finding programmatically; for example, it enables rapid sorting and aggregation based on the code location field, filtering and statistics based on the severity level field, and similarity calculation based on the problem description field. Furthermore, encapsulating all items into predefined format data packets defines the data exchange protocol between different review agents and between review agents and the aggregation center, ensuring smooth communication and unambiguous parsing. Moreover, this standardized output mechanism completely changes the difficult subsequent processing situation caused by a single model outputting unstructured text, making automated deduplication, classification, prioritization, and report generation possible, greatly improving the efficiency and accuracy of the entire review system's result processing.

[0061] S5, aggregate the structured results generated by all review agents, and perform automated processing on the aggregated structured results, the automated processing including at least one of deduplication, conflict resolution and priority sorting.

[0062] In practice, the step of aggregating the structured results generated by all review agents is executed by the result aggregation center. The result aggregation center monitors the output channels of each review agent and collects the structured results they return. Since the review agents execute in parallel, the order and timing of their returned results may be uncertain. Therefore, the aggregation center needs to maintain a task ID, collect all results belonging to the same review task, and wait for all review agents to complete or for the timeout period to expire.

[0063] Furthermore, the step of automating the processing of the aggregated structured results involves integrating and optimizing results from multiple sources. Automated processing includes at least one of the following: deduplication, conflict resolution, and prioritization. For example, deduplication generates fingerprints based on the core semantics of the code location and problem description, merging substantially identical problems; conflict resolution resolves disagreements among multiple review agents regarding the severity of a problem at the same location, adjudicating the conflict according to predefined rules (e.g., taking the highest level); and prioritization considers factors such as problem severity and impact. All these processes are performed automatically by the algorithm without human intervention.

[0064] In some preferred embodiments, the automated processing of the aggregated structured results includes: calculating a unique fingerprint based on the core content of the code location field and problem description field in each structured result entry; clustering all structured result entries according to the calculated unique fingerprint, merging entries belonging to the same cluster into a representative entry; if multiple representative entries point to overlapping code locations and have different severity level fields, selecting the highest severity level from the different severity level fields as the final severity level of the code location according to a predefined severity level value mapping table; calculating a comprehensive priority score for each representative entry based on the final severity level, combined with the impact range assessment value and the repair complexity assessment value for the problem corresponding to the representative entry; wherein the impact range assessment value is determined based on the scope of files or modules affected by the problem in the code structure, and the repair complexity assessment value is determined based on the size of the code to be modified and the complexity of the dependencies required to repair the problem; and sorting all representative entries in descending order of comprehensive priority score.

[0065] In practice, the key to deduplication is calculating a unique fingerprint based on the core content of the code location field and problem description field in each structured result entry. Specifically, the fingerprint calculation module generates a unique identifier for each result entry. A common implementation method is to extract the code location field (e.g., file_path:start_line:end_line) as a base, and then combine it with core noun phrases extracted from the problem description field or standardized keywords (e.g., removing stop words and extracting the main words after stemming). These strings are then concatenated and their hash value (e.g., MD5 or SHA-256) is calculated. This hash value is the fingerprint of the problem, mapping different descriptions of the same code location and the same essential problem to the same value.

[0066] Further, based on the calculated unique fingerprints, all structured result entries are clustered, and entries belonging to the same cluster are merged into a single representative entry. The clustering module compares the fingerprints of all entries. Due to hash collisions or subtle description differences, similarity comparison may be used as an aid: entries with identical or highly similar fingerprints are directly grouped into one category; entries with different fingerprints but overlapping code locations and a cosine similarity exceeding a threshold after vectorization of the problem description text can also be classified as potential duplicates for manual rule or secondary model judgment. Each cluster is ultimately merged to produce a representative entry. Merging strategies may include: adopting the clearest description text, selecting the highest severity level, and merging all different remediation suggestions. The representative entry retains the core information of the problem while removing redundancy.

[0067] Furthermore, when multiple representative entries point to overlapping code locations and have different severity levels, the step of selecting the highest severity level from the different severity level fields as the final severity level for that code location, based on a predefined severity level numerical mapping table, is conflict resolution. In implementation, the system maintains a mapping table, for example: {"Severe": 5, "High": 4, "Medium": 3, "Low": 2, "Hint": 1}. For issues reported by different review agents within the same code block (e.g., the same function or several closely adjacent lines), if their severity levels differ, the mapping table is queried, all relevant levels are converted to numerical values, the highest value is selected, and it is then reverse-mapped back to the level label as the final severity level for that location. This rule typically follows a worst-case principle to ensure that high-risk issues are not underestimated.

[0068] Furthermore, the step of calculating the comprehensive priority score for each representative item based on the final severity level, combined with the impact scope assessment value and the repair complexity assessment value, is a refined ranking process. Specifically, the impact scope assessment value can be determined based on static code analysis: for example, by using call graph analysis to determine how many other files or modules call the function or method containing the problem; or, if the problem involves API interfaces or public configurations, its impact scope is assessed as large. The repair complexity assessment value can be based on a preliminary analysis of the problem code: for example, estimating the number of lines of code that need to be modified, analyzing whether the modification involves complex logical refactoring, or whether multiple related code or documents need to be updated simultaneously. The system assigns weight coefficients to the severity level, impact scope, and repair complexity. The formula for calculating the comprehensive priority score can be expressed as: Score = f (severity level weight) + g (impact scope assessment value) - h (repair complexity assessment value). Wherein, functions f, g, and h can be linear mappings or other mathematical relationships. The weights and function parameters can be adjusted according to the project strategy, and this invention is not specifically limited.

[0069] Further, the process involves sorting all representative items in descending order of their overall priority scores. The sorting module simply arranges all representative items in descending order based on their calculated overall priority scores, producing an ordered list where issues with higher scores are considered to require more priority attention and processing.

[0070] This embodiment effectively solves the problems of result redundancy, conflicting opinions, and decision-making burden caused by parallel review by multiple review agents by defining a complete automated processing pipeline, including fingerprint-based deduplication, rule-mapping-based conflict resolution, and multi-factor weighted priority ranking. Fingerprint-based intelligent deduplication can automatically identify and merge duplicate reports from different review agents that point to the same core issue, avoiding the hassle of developers reading multiple similar feedback reports and making reports more concise. Furthermore, when experts from different fields have inconsistent judgments on the severity of the same issue, the highest-level conflict resolution rule is selected based on a predefined mapping table, providing a clear, consistent, and conservative decision-making scheme. This ensures that potentially high-risk issues are not masked by lower evaluations, enhancing the reliability of the review results. Furthermore, the introduction of impact scope assessment and remediation complexity assessment to calculate the comprehensive priority score means that issue ranking no longer relies solely on a single severity level, but comprehensively considers the technical impact and remediation cost of the issue, thereby generating an action list that better aligns with engineering practice priorities.

[0071] In some preferred embodiments, the impact scope assessment value is used to quantify the potential spread of issues discovered during code reviews within the software system. This impact scope assessment value is calculated based on a static analysis of code structure dependencies. The specific calculation process includes: First, the system pinpoints the specific function, method, class, or module definition within the source code based on the code location field in the structured results entries. Then, the static analysis engine loads the entire project's codebase and constructs a call relationship graph between code elements. This graph uses nodes to represent code units and directed edges to represent calls, inheritance, implementations, or dependencies.

[0072] Furthermore, starting from the located nodes, a graph traversal algorithm is executed. The analysis engine analyzes outward along the call relationship graph, identifying all parent nodes that directly call the problematic code unit, as well as downstream nodes that indirectly depend on the problematic code unit through multiple call chains. The set of affected nodes is counted and merged according to the files corresponding to the nodes to obtain a list of affected source code files.

[0073] Furthermore, a basic impact metric is calculated. This metric is typically the number of affected source code files. To more accurately reflect the impact at the architectural level, code units can be categorized into core modules and peripheral modules, with higher weighting assigned to impacts on core modules.

[0074] Furthermore, the basic impact metric is converted into a standardized impact range assessment value through a predefined mapping function. This mapping function can be designed as a piecewise linear function or a lookup table. For example, when the number of affected files falls within a specific range, it corresponds to a specific impact range assessment value. This impact range assessment value provides a quantitative input for subsequent comprehensive priority calculations regarding the scope of the problem's propagation.

[0075] In some preferred embodiments, the fix complexity assessment value is used to quantify the amount of work and technical difficulty required to correct issues discovered during code reviews. The calculation of this fix complexity assessment value is based on semantic and structural analysis of the problematic code snippet and its context. The specific calculation process includes: First, the system parses the code location field in the structured result entry, extracts the precise range of source code that needs to be modified, and loads the complete syntactic structure unit containing that range.

[0076] Furthermore, the scale of the modification is assessed. The analysis engine compares the problematic code with the expected code state described in the remediation suggestions provided by the review agent. By constructing an abstract syntax tree difference, the number of syntax nodes that need to be added, deleted, or modified is accurately calculated and converted into an estimated change in the number of lines of source code, serving as a basic quantitative indicator of the modification scale.

[0077] Furthermore, the extent of the spillover effects of the related modifications is assessed. The analysis engine performs data flow and call chain analysis on all identifiers referenced within the problematic code segment. By tracing the definition point of each identifier and all its usage points globally within the project, it determines whether this fix necessarily leads to cascading changes in other related code units. The number of related code units located in different source code files that must be modified as a result of this core fix is ​​counted.

[0078] Furthermore, the complexity of technology dependencies is assessed. This assessment is achieved through static code analysis and includes the following sub-steps: Dependency Change Analysis: The analysis engine compares the import declarations or dependency management files of the code segments before and after the fix. It identifies whether the fix introduces new software library dependencies or requires version upgrades to existing dependency libraries. Each time a new or upgraded dependency is identified, its corresponding complexity weight is accumulated.

[0079] Furthermore, complex paradigm identification: The analysis engine performs pattern matching on the code context involved in the repair solution. It detects whether the modification involves recognized high-complexity programming paradigms such as concurrency synchronization mechanisms, transaction boundary management, distributed consistency protocols, or complex state machine logic. For each such complex paradigm identified, an additional preset complexity weight is assigned.

[0080] Furthermore, the interface impact assessment: If modifications are made to function signatures or persistent data schemas involving public application programming interfaces, the analysis engine evaluates the destructiveness of the change. A corresponding complexity weight is assigned based on the estimated number of affected internal or external callers.

[0081] Finally, a predefined aggregation algorithm is used to integrate the above factors. This algorithm assigns specific coefficients to the weights derived from the modification scale, the diffusion degree of related modifications, and the technical dependency complexity analysis, and then performs a weighted summation to output a standardized remediation complexity assessment value. This assessment value comprehensively reflects the depth of technical understanding and the breadth of change implementation required to implement the remediation.

[0082] S6. Based on the results of the automated processing, generate and output a code review report.

[0083] In practice, the step of generating and outputting a code review report based on the processed results is to transform the machine-processed results into a format that can be consumed by the end user. The report generator populates templates of different formats based on the processed structured result set. For example, it generates a machine-readable JSON report for subsequent integration and analysis by CI / CD tools; further, it generates a human-readable HTML report, displaying issues in a clear and categorized list format, including issue description, location, severity level, and remediation suggestions, and outputs it to developers via email, instant messaging tools, or the comment interface integrated into the code hosting platform.

[0084] This invention effectively overcomes the limitations of single-model review by constructing a collaborative workflow that includes preprocessing, parallel distribution, independent review, result aggregation, and automated processing. The scheme decomposes the overall review task into multiple sub-tasks that can be executed in parallel by specialized review agents. This allows each agent to focus on a specific code quality dimension for in-depth analysis, resulting in more accurate and in-depth review conclusions on professional dimensions such as business logic correctness, code security, and performance than a single comprehensive model, thus enhancing the professionalism and depth of the review. Furthermore, since multiple review agents work independently and in parallel based on the same context data package, the overall review time is reduced from the cumulative time of each dimension in the traditional serial mode to the time of the slowest review agent, significantly improving review efficiency and enabling rapid response to fast-iterating development processes. Moreover, the structured results output by each review agent provide a foundation for subsequent automated processing. The system can automatically integrate, adjudicate, and sort multi-source results, directly generating clearly categorized and prioritized review reports, avoiding the manual work of sorting through mixed results and enhancing the operability and decision support capabilities of the review results.

[0085] In some preferred embodiments, generating and outputting the code review report includes: filling the automated processing set of result items according to a predefined machine-readable format template to generate a first format review report; the first format review report is in JSON or XML format; filling the automated processing set of result items according to a predefined human-readable format template to generate a second format review report; the second format review report is in Markdown or HTML format; and in the second format review report, the identification information of the review agent from which each result item originates is marked.

[0086] In practice, the first step involves filling the automated result set with a predefined machine-readable template to generate a first-format review report. This aims to provide a data interface that facilitates integration with downstream tools. Specifically, the report generator maintains a machine-readable template, such as a template file that defines a complete JSON schema. This template further defines the overall structure of the report, including a metadata area (such as task ID and generation time) and a core issue list area. The generator iterates through the sorted set of representative entries, creating an object for each entry that conforms to the "issue item" definition in the schema, and filling in each field of the entry (issue description, code location, final severity level, overall priority score, remediation recommendations, etc.). All issue item objects are placed in an array and assembled with other metadata into a final JSON document. This JSON report can be provided via an API interface or written to a specified file path for parsing and consumption by other tools in the continuous integration / continuous deployment pipeline (such as automated task creation tools and quality access control systems).

[0087] Furthermore, the process of generating a second-format review report by filling the automated set of results items with a predefined human-readable template aims to provide developers with an intuitive reading experience. Human-readable templates are typically defined using markup languages ​​such as Markdown or HTML. The report generator uses the same set of representative items but renders them in a way optimized for human-computer interaction. For example, when generating a Markdown report, a document is created that begins with a review overview (total number of issues, severity distribution), followed by grouping issues by severity level (e.g., severe, high, medium, low), and then listing issues within each group in descending order of priority score. Each issue is presented with: a clear title line (containing a severity level label and a brief description), a link to the code location (clickable to jump to the code repository), a detailed description paragraph, and specific code blocks or steps for suggested fixes. When generating an HTML report, CSS stylesheets are applied to highlight issues of different severity levels with different colors, and interactive features such as collapse / expand, filtering, and sorting may be added.

[0088] Furthermore, the step of annotating the source review agent's identification information for each result entry in the second-format review report ensures the traceability of review opinions. When filling in the human-readable report template, the report generator extracts the source information from each representative entry (this information is retained during aggregation and merging, typically recording the ID of the review agent who initially reported the issue, or recording all contributor IDs during merging). Further, when presenting each issue in the report, it is noted near the issue description or in a dedicated source field, in the form of a text label or badge, such as security review, performance review, or business logic review. This allows developers to immediately understand which review agent, specializing in which area, provided the opinion, thus better understanding the background and focus of the issue, and knowing which domain's knowledge or rules to refer to when further exploration is needed.

[0089] This embodiment significantly enhances the practicality and integration friendliness of the review system's output by specifying the generation of reports in both machine-readable and human-readable formats and annotating the source of issues. Generating machine-readable reports, such as standardized JSON, allows review results to be seamlessly consumed by other automated tools in the development pipeline, enabling automatic quality gatekeeping, automatic issue submission, and automatic collection and analysis of metric data. This deeply embeds intelligent review into DevOps practices, improving the automation level of the development process. Furthermore, generating optimized human-readable reports directly serves developers in a clear, structured, and visually friendly manner. Through grouping, sorting, highlighting, and detailed remediation suggestions, it significantly reduces the mental burden and time cost for developers to understand issues and develop remediation plans. Annotating each issue with the source review agent's identification information increases the transparency and credibility of the review process, enabling developers to assess the importance of issues based on their professional sources and promoting cross-domain knowledge exchange.

[0090] Please see Figure 2 , Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0091] The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0092] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it enables the processor 502 to execute a multi-agent collaborative code review method based on role-based division of labor.

[0093] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0094] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a multi-review agent collaborative code review method based on role division.

[0095] The network interface 505 is used for network communication with other devices. Those skilled in the art will understand that the above structure is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. A specific computer device 500 may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.

[0096] The processor 502 is used to run a computer program 5032 stored in a memory to implement the steps of a multi-review agent collaborative code review method based on role division of labor provided in any of the above embodiments.

[0097] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0098] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0099] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform the steps of a role-based multi-agent collaborative code review method provided in any of the above embodiments.

[0100] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0101] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0102] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0103] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0104] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0105] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0106] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.

[0107] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A collaborative code review method for multiple review agents based on role-based division of labor, characterized in that, include: In response to a code review trigger event, obtain the code to be reviewed and related context information; The code to be reviewed and related context information are preprocessed to generate a standardized context data packet; The context data packet is synchronously distributed to at least two review agents; each review agent is configured to specialize in a different code quality dimension. Each review agent independently and in parallel reviews the context data packet based on a review strategy customized for the corresponding code quality dimension, and generates a structured result containing problem information. The structured results generated by all review agents are aggregated, and the aggregated structured results are processed automatically, including at least one of deduplication, conflict resolution, and priority sorting. Based on the results of the automated processing, a code review report is generated and output.

2. The multi-agent collaborative code review method based on role division of labor according to claim 1, characterized in that, The method further includes: Configure the first review agent to specialize in reviewing the correctness of business logic; Configure a second review agent to specialize in code security-related reviews; Configure a third review agent to specialize in reviewing performance metrics; Configure a fourth review agent to specialize in reviewing code maintainability. Configure a fifth review agent to specialize in reviewing user experience accessibility dimensions.

3. The multi-agent collaborative code review method based on role division of labor according to claim 1, characterized in that, The response to the code review trigger event includes: Monitor the event stream of the integrated version control system; When a predefined code commit event occurs in the event stream, the code commit event is captured as the code review trigger event.

4. The multi-agent collaborative code review method based on role division of labor according to claim 1, characterized in that, The preprocessing of the code to be reviewed and related context information to generate a standardized context data packet includes: The code to be reviewed is parsed to generate an abstract syntax tree, and the abstract syntax tree is then subjected to structural normalization processing. Based on the relevant context information, collect supplementary context information associated with the code to be reviewed; Extract metadata associated with the project to which the code to be reviewed belongs; The abstract syntax tree that has undergone structural normalization, the collected supplementary context information, and the extracted metadata are assembled and encapsulated to generate the context data package.

5. The multi-agent collaborative code review method based on role division of labor according to claim 2, characterized in that, The method further includes: Configure dedicated system prompts containing key points of business logic review for the first review agent specializing in the correctness of business logic. For the second review agent specializing in code security, a hybrid strategy is configured that includes a security vulnerability rule base and security review-specific prompts; For a third-party review agent specializing in performance metrics, a few-shot learning strategy is configured, which includes performance anti-pattern examples and performance review-specific prompts. For the fourth review agent specializing in code maintainability, configure a hybrid strategy that includes code style rules and maintainability review-specific prompts; Configure a strategy that includes accessibility standards and user experience review-specific prompts for the fifth review agent, which specializes in the accessibility dimension of user experience.

6. The multi-agent collaborative code review method based on role division of labor according to claim 1, characterized in that, The generation of structured results containing problem information includes: Each review agent generates one or more structured result entries based on the review results. The structured result entries include at least: a problem description field for describing the problem, a code location field for locating the code location, a severity level field for identifying the severity of the problem, and a repair suggestion field for providing modification suggestions. Each review agent encapsulates one or more structured result entries into a predefined data packet and outputs it.

7. The multi-agent collaborative code review method based on role division of labor according to claim 1, characterized in that, The automated processing of the aggregated structured results includes: A unique fingerprint is calculated based on the core content of the code location field and the problem description field in each structured result entry; Cluster all structured result entries based on the calculated unique fingerprints, and merge entries belonging to the same cluster into a representative entry; If multiple representative entries point to overlapping code locations and have different severity level fields, the highest severity level is selected from the different severity level fields as the final severity level of the code location, according to a predefined severity level value mapping table. Based on the final severity level, and combined with the impact scope assessment value and the repair complexity assessment value of the corresponding issues for the representative items, a comprehensive priority score is calculated for each representative item; wherein, the impact scope assessment value is determined based on the scope of files or modules affected by the issue in the code structure, and the repair complexity assessment value is determined based on the size of the code to be modified and the complexity of the associated dependencies required to repair the issue; All representative items are sorted in descending order of their overall priority scores.

8. The multi-agent collaborative code review method based on role division of labor according to claim 1, characterized in that, The generation and output of the code review report includes: The automated processing result set is populated according to a predefined machine-readable format template to generate a first-format review report; the first-format review report is in JSON or XML format. The automated result set is populated according to a predefined human-readable template to generate a second-format review report; the second-format review report is in Markdown or HTML format. In the second format review report, the identification information of the review agent from which the result entry originated is marked.

9. A computer device, characterized in that, The 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 method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-8.

Images