Engineering execution result arbitration and degradation routing method for multi-model ai research and development tasks

Abstract

The application provides a multi-model AI research and development task engineering execution result arbitration and degradation routing method. Through an engineering difference alignment mechanism, explicit and implicit conflicts between candidate results are identified according to files, functions, interfaces, database changes, permission logic, test coverage, and risk items. Consistency score, credibility score, and conflict level are used to determine whether to adopt, avoiding errors caused by single model output or ordinary text voting. When the candidate results conflict or the credibility is insufficient, the system can automatically trigger strong model rerun, enhanced verification, reduced automation level, output analysis report only, or manual takeover. Through the ability portrait reflux mechanism, the performance of different models or runtimes under different languages, frameworks, task types, and risk levels is continuously recorded and used for subsequent routing. The arbitration base records candidate results, scoring parameters, conflict items, adoption reasons, degradation reasons, and manual feedback, facilitating review, risk control, and strategy optimization.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence research and development technology, and in particular to a method and system for arbitration and degradation routing of engineering execution results of multi-model AI research and development tasks, as well as electronic devices and computer-readable storage media. Background Technology

[0002] With the development of large language models, code agents, and automated software engineering platforms, AI R&D tasks are no longer limited to generating code snippets from a single model. Instead, they have evolved into an engineering execution process involving multiple models, multiple agent roles, or multiple runtime environments. Different models or runtimes may produce different results regarding implementation schemes, scope of modifications, patch content, testing strategies, and risk assessments. If a production-ready AI R&D platform directly adopts the output of the first model, it is prone to problems such as excessive patch modifications, insufficient testing, misjudgment of the scope of impact, and omission of risks related to permission or database changes. On the other hand, if it relies entirely on human judgment, it is difficult to form stable, auditable, and reusable automated access control capabilities.

[0003] In existing technologies, the technical means for engineering execution of AI research and development tasks include the following: Multi-Agent software development: For example, the solution disclosed in the link "US20250165890A1, Automated software development workflows via multi-agent computational framework, Google Patents: https: / / patents.google.com / patent / US20250165890A1 / en" proposes to automate the software development workflow through a multi-agent computational framework, including memory-enhanced agents, critique agents, and multiple dedicated agents to achieve task allocation, context management, and quality feedback. However, its focus is on multi-agent collaboration to complete the software development process and critique agent feedback, rather than on the execution results of multiple candidate projects for the same task, establishing a unified candidate object, project difference matrix, consistency / reliability scoring, degradation routing, and capability profile backflow closed loop. General multi-model output optimization / fusion: For example, the paper "LLM-Blender: Ensembling LargeLanguage Models with Pairwise Ranking and Generative Fusion, arXiv:2306.02561: https: / / arxiv.org / abs / 2306.02561" proposes to rank multiple LLM candidate outputs pairwise and generate better outputs through a fusion module to improve the output quality of general instruction tasks; however, its ranking and fusion of general text / instruction outputs mainly compares the quality of candidate responses. Software engineering tasks also involve structured engineering products such as code patching, file modification, test coverage, risk items, build verification, and repository write operations, which cannot be directly replaced by ordinary text optimization. In addition, there are technical solutions such as real software engineering evaluation and APR patch sorting, etc.

[0004] While the aforementioned existing technologies can achieve local routing processing, a complete closed-loop solution has yet to be seen that treats "the execution results of candidate projects generated by multiple models or execution runtimes for the same AI R&D task" as a unified object, and performs structured normalization, engineering difference alignment, consistency scoring, credibility scoring, arbitration decision-making, degraded routing, capability profile backflow, and arbitration audit of the underlying records around the implementation plan, modified documents, code patches, test plans, risk statements, and expected verification evidence.

[0005] Therefore, in summary, the existing technology has the following main drawbacks: 1. Lack of a mechanism for unifying candidate results for software engineering deliverables: Existing multi-agent or model routing schemes typically focus on task allocation, role collaboration, or general text answer selection, but lack a mechanism to convert implementation plans, patches, test plans, risk statements, and expected verification evidence from different models into unified candidate objects.

[0006] 2. Lack of alignment of multiple candidate results across engineering dimensions: Existing solutions typically do not align candidate engineering results by file, function, interface, database changes, permission logic, configuration items, test cases, and risk items, making it difficult to promptly detect hidden conflicts such as "the same text description but different actual modification scope".

[0007] 3. Lack of combined arbitration of consistency score and credibility score: General model voting or LLM-as-a-Judge focuses more on the quality of the response, and APR patch ranking focuses more on whether the patch passes the test. Neither of them combines candidate result consistency, historical success rate, task suitability, test adequacy, risk conflict and cost penalty as production-grade adoption criteria.

[0008] 4. Lack of a degradation routing mechanism under risk grading: When multiple candidate results differ significantly, existing solutions often only offer options such as regeneration, manual review, or single-model criticism, lacking standardized switching rules between strong model reruns, enhanced validation, reduced automation levels, outputting only analysis reports, and manual takeover.

[0009] 5. Lack of a closed-loop model / runtime capability profile: Existing solutions typically do not record feedback such as whether candidate results are adopted, whether verification is successful, the proportion of manual modifications, reasons for failure, cost and time consumption into capability profiles, causing subsequent tasks to still rely on static model selection or experience-based routing.

[0010] 6. Lack of auditable arbitration records: Existing solutions usually only retain the final output or simple operation logs, making it difficult to trace why a certain candidate result was adopted, why other candidate results were rejected, what the conflict was, whether a downgrade was triggered, and how manual feedback was provided. Summary of the Invention

[0011] To address the technical problems existing in the prior art, the present invention provides the following technical solution: On the one hand, a method for arbitration and degradation routing of multi-model engineering execution results for AI R&D tasks is provided, including the following steps: Receive external AI R&D task requests, extract standardized task features based on the target warehouse context, and the task features should include at least the task language, warehouse type, task type, risk level, scope of change, expected output, and execution constraints. Read the pre-stored model capability profile, combine task characteristics and resource constraints to calculate candidate runtime adaptation indicators, and select at least two different models / execution runtimes as candidate sets; When all candidate models selected by the driver are executed, multiple candidate engineering execution results are generated in parallel for the same AI R&D task. Perform structured normalization processing on multiple candidate project execution results with inconsistent formats, and convert them into a set of candidate result objects with uniform fields; Perform multi-dimensional engineering difference alignment processing on the candidate result object set to generate an engineering difference matrix carrying similarity, difference type, and conflict severity; Based on the engineering difference matrix, two quantitative indicators, consistency score and conflict level, were calculated respectively. The credibility score of each candidate result is calculated by integrating six dimensions: consistency score, model historical performance, task matching degree, test completeness, risk conflict, and execution cost. Arbitration decisions are made by combining consistency score, credibility score, conflict level, and original task risk level, and corresponding scheduling instructions are output. According to the arbitration scheduling instructions, the degraded routing is executed. The routing types include strong model rerun, enhanced verification, merged adoption, automatic adoption, output report only, and manual takeover. The system collects automated testing and manual review feedback of the final engineering products to generate standardized evaluation samples, and writes the samples back to update the model capability profile; at the same time, it persistently writes the original data of the entire task chain, intermediate calculation indicators, arbitration records, downgrade records, and manual operation records into the arbitration ledger to complete the audit retention.

[0012] Preferably: The generated candidate project execution results should include at least the candidate implementation plan, candidate code patch, candidate test plan, and candidate risk description, and may also include change summary, expected verification results, running log, and execution cost; The single candidate result object obtained after structured normalization includes the following fields: CandidateId (unique candidate identifier), RuntimeId (runtime identifier), ModelVersion (model version), PlanItems (implementation plan items), ModifiedFiles (list of modified files), PatchDigest (patch summary), TestPlan (test plan), ImpactScope (impact scope), RiskItems (risk items), ExpectedEvidence (expected verification evidence), and CostMetrics (execution cost metrics).

[0013] Preferably, step S2, which filters candidate runtimes, uses the RouteScore calculation formula: In the formula: : The current candidate model to be evaluated / during runtime; Current AI research and development tasks; Configure adjustable weighting coefficients; Model-task programming language matching degree; Model-to-target warehouse type matching degree; : The historical success rate of this runtime for similar tasks; : Run adaptation indicators that are appropriate for the current task's risk level; : Estimated execution time and resource cost penalty value; The system selects multiple candidate models for runtime based on their RouteScore values ​​from high to low, while configuring diversity constraints to ensure model type differentiation.

[0014] Preferably, the comparison dimensions for engineering difference alignment include at least two items: implementation plan, modified files, functions / methods, interface definitions, configuration items, database changes, permission logic, test cases, and risk descriptions. The generated engineering difference matrix has fixed fields including candidate result pairing identifier, alignment dimension, similarity value, difference description, conflict type, conflict location, conflict severity level, and change impact scope. The alignment method supports pairwise candidate comparison and multi-candidate batch comparison. Similarity calculation at the patch and code change level is completed through AST abstract syntax tree, file path, and patch semantic vector.

[0015] Preferably, the consistency score is calculated using the following formula: In the formula: Adjustable weights for each dimension; Similarity of multiple candidate implementation plans; : Modify the overlap of the file set; Patch semantic similarity; Test coverage similarity; : The degree of consistency in risk assessment among candidates; the score range is 0 to 1, and the higher the value, the higher the degree of convergence among multiple candidates.

[0016] Preferably, the TrustScore calculation formula is as follows: In the formula: Weighted adjustment coefficient; Consistency score; : The historical verification success rate of similar tasks during runtime; The overall fit between the model and the current task; Indicators of the completeness of candidate test schemes; Quantitative value of candidate internal risk conflict; The score represents the cost penalty for execution time and resources; the credibility score ranges from 0 to 1, with a higher score indicating a higher priority for the adoption of a single candidate project result.

[0017] Preferably, the formula for calculating the ConflictLevel is as follows: In the formula: Conflict dimension weights; File overlap (derived from consistency score); : The degree of semantic conflict in the patch; : Difference in coverage of multiple candidate tests; Risk assessment disagreement indicators; : Core change conflict coefficient. Core changes include core files, database fields, permission logic, system interfaces, security policies, and rollback process changes. A higher conflict level indicates more severe engineering disagreements and security conflicts among multiple candidates.

[0018] Preferably, the arbitration decision includes five categories of determination branches: 1) Automatic branch adoption: If the consistency score is greater than or equal to the preset adoption threshold, the conflict level is lower than the conflict threshold, and at least one candidate has a qualified credibility score, the candidate with the highest credibility score is directly selected as the final product; 2) Merge adoption branches: The main body of each candidate patch converges, and only the test plan and risk warning have complementary content. The best patch is retained and the test and risk suggestions of the other candidates are merged. 3) Strong model rerun branch: When the consistency score is insufficient and the task risk is medium to high, the candidate is regenerated when the high computing power is scheduled to run, and the process is returned to the repeated normalization, alignment and scoring process; 4) Enhanced verification branch: If the test adequacy index fails to meet the standard, it will automatically supplement static code scanning, sandbox replay, and multiple rounds of regression testing before arbitration. 5) Manual takeover / Report only branch: If the conflict level exceeds the high conflict threshold and involves changes to the database, permissions, or core interfaces, reduce the automation level, output only a difference analysis report, and push it for manual processing.

[0019] Preferably, the following are the trigger conditions for degrading routes: 1) Strong model rerun trigger: consistency score < 0.75 and task risk level is medium or above; 2) Enhanced verification trigger: The completeness index of the candidate test scheme is lower than the preset test completeness threshold; 3) Merge adoption trigger: low semantic conflict in patches, and complementary information between test and risk items; 4) Manual takeover triggered: Conflict level ≥ 0.6, and there are conflicts in core files, databases, permissions, and interface changes; 5) Automatic adoption trigger: Consistency score ≥ 0.8, conflict level < 0.6, optimal candidate credibility score ≥ 0.75; After any branch is completed, the degradation type, triggering indicator, and processing time are synchronously recorded and written to the intermediate log, and stored in the arbitration ledger.

[0020] Preferably, the model capability profile feedback and arbitration ledger storage mechanism is as follows: 1) Model capability profile bucketing statistics dimensions: task language, development framework, repository type, task type, risk level, repository size, and historical failure type; update indicators include runtime historical success rate, test generation capability, manual modification rate, average execution time, and failure frequency; each time a task is completed, an evaluation sample is added to update the corresponding bucket data for the next round of candidate runtime screening; 2) The arbitration ledger permanently stores the following content: original task request, task characteristics, all candidate original outputs, normalized candidate objects, complete engineering difference matrix, consistency / reliability / conflict three-category scores, arbitration decision instructions, downgrade routing records, automated test logs, manual review opinions, final engineering products, and profile update records. The entire chain of data supports auditing, risk control, and algorithm strategy review and retrieval.

[0021] On the other hand, a multi-model engineering execution result arbitration and degradation routing system for AI R&D tasks is provided. This system is used to implement the above method and includes: Task receiving module: Receives external AI R&D task requests, parses basic task information, extracts full task features including task language, repository type, task type, risk level, scope of change, expected output, and resource constraints, and outputs standardized task feature data packets to the candidate runtime routing module; Candidate Runtime Routing Module: Input task features + model capability profile binned data, filter multiple suitable models / runtimes through adaptation scoring formula, output candidate runtime list and send it to candidate result generation module; read profile data before new task execution, and receive updated profile data after task completion to iterate its own routing strategy; Candidate Result Generation Module: Receives a list of candidate runtimes and the original AI R&D tasks, drives each runtime to independently generate candidate project execution results, and batch outputs multiple original unstructured candidate outputs to the structured normalization module; The results structured normalization module receives multiple raw candidate outputs without a uniform format, parses the text, patch, command, and report content, extracts standardized fields, encapsulates them into a unified candidate result object array, and outputs the normalized candidate set to the engineering difference alignment module. Engineering Difference Alignment Module: Input a normalized candidate result object array, perform pairwise / multi-party comparisons from seven engineering dimensions: implementation plan, files, functions, interfaces, databases, tests, and risks, generate an engineering difference matrix carrying similarity, conflict type, and conflict severity, and synchronize the difference matrix to the consistency scoring and conflict level calculation modules; Consistency scoring module: Input the engineering difference matrix, calculate the consistency score based on multi-dimensional similarity weighting, and output the score value to the credibility scoring module and arbitration decision module; The credibility scoring module takes six parameters as input: consistency score, model historical success rate, task fit, test sufficiency, risk conflict, and execution cost. It calculates the credibility score of a single candidate using a weighted formula and outputs the credibility score of each candidate to the arbitration decision module. Conflict Level Module: Calculates the conflict level based on the difference matrix, marks the weight of high-risk conflicts, and outputs the conflict level to the arbitration decision module; Arbitration decision module: It uniformly receives four inputs: consistency score, credibility score, conflict level, and original risk level of the task, matches them with preset arbitration threshold rules, and outputs arbitration branch instructions: automatic adoption, merged adoption, strong model rerun, enhanced verification, reduced automation, and manual takeover; and sends the arbitration instructions to the degradation routing module. Degradation routing module: Receives arbitration branch instructions and completes task routing and scheduling: If the instruction is to rerun, it sends back to the candidate runtime routing module to re-call the strong model; if the instruction is to enhance verification, it issues a verification execution instruction; if the instruction is to manually take over / report only, it directly pushes the task archiving signal to the verification feedback module. Verification and Feedback Module: Receives final engineering deliverables, sandbox test results, build scan reports, and manual review comments, and converts them into standardized evaluation samples (adoption status, manual modification rate, failure reasons, and time and cost). It outputs bidirectionally: ① Evaluation samples are fed back to the capability profiling module to update the profiling; ② Execution data from the entire process is pushed to the arbitration ledger module for persistent storage. Arbitration ledger module: a full-link data persistence unit that receives all raw data, normalized objects, difference matrices, various scores, conflict records, arbitration instructions, downgrade records, verification feedback, and manual operation records throughout the entire task lifecycle, and generates an auditable arbitration ledger that supports retrieval, review, and risk control tracing.

[0022] On the other hand, an electronic device is provided, comprising: a processor; and a memory storing computer-readable instructions, which, when executed by the processor, implement the method described above.

[0023] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction is stored therein, the at least one instruction being loaded and executed by a processor to implement the above method.

[0024] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following: 1. Improve the comparability of candidate results: Through a structured normalization mechanism, natural language schemes, code patches, test schemes, risk statements and verification evidence output by different models or runtimes are converted into a unified candidate result object.

[0025] 2. Enhance the ability to identify engineering conflicts: Through the engineering difference alignment mechanism, identify explicit and implicit conflicts between candidate results by file, function, interface, database change, permission logic, test coverage and risk items.

[0026] 3. Improve the reliability of automatic adoption: Adoption is determined by consistency score, credibility score and conflict level, avoiding the direct execution of erroneous patches due to single model output or ordinary text voting.

[0027] 4. Enhanced degradation handling capabilities: When candidate results conflict or lack credibility, the system can automatically trigger a strong model rerun, enhance verification, reduce the automation level, output only an analysis report, or allow manual intervention.

[0028] 5. Improve the accuracy of subsequent model selection: Through the capability profile feedback mechanism, the performance of different models or runtimes under different languages, frameworks, task types and risk levels will be continuously recorded and used for subsequent routing.

[0029] 6. Enhance audit trail capabilities: The arbitration ledger records candidate results, scoring parameters, conflict items, reasons for adoption, reasons for downgrade, and manual feedback, facilitating review, risk control, and strategy optimization. Attached Figure Description

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

[0031] Figure 1 This is a flowchart of a method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a system architecture provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structured normalization of candidate results provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of arbitration decision and degradation routing provided by an embodiment of the present invention; Figure 5 This is a schematic diagram of a model capability profile feedback loop provided in an embodiment of the present invention. Detailed Implementation

[0032] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0033] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0034] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning.

[0035] In this embodiment of the invention, sometimes a subscript such as W1 may be mistakenly written as a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0036] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0037] I. Explanation of Professional Terms 1. AI R&D tasks: These refer to software engineering tasks processed by the artificial intelligence R&D execution platform, including tasks such as defect repair, feature development, refactoring, test supplementation, interface adjustment, configuration change, and document update.

[0038] 2. AI Engineering Execution Results: This refers to the collection of engineering artifacts generated by the model, code agent, or engineering execution runtime for the same AI R&D task. These artifacts may include implementation plans, code patches, test plans, risk statements, change summaries, expected verification results, runtime logs, or execution costs.

[0039] 3. Runtime: refers to the execution environment that can call models, read code, generate patches, run tests, or generate project reports. It can be a large language model, code agent, project agent runtime, sandbox executor, or a combination thereof from different vendors.

[0040] 4. Candidate Engineering Execution Results: refers to a single comparable engineering result output by a model or runtime for a specified R&D task, including candidate implementation plans, candidate code patches, candidate test plans, candidate risk descriptions, and candidate reports.

[0041] 5. Structured normalization: This refers to the process of converting natural language, patch files, test commands, report texts, and logs output by different models or runtimes into a unified field structure for subsequent comparison, scoring, and auditing.

[0042] 6. Project Difference Alignment: This refers to mapping and aligning the execution results of multiple candidate projects according to project dimensions such as files, functions, interfaces, configuration items, database changes, test cases, and risk items, and identifying similarities, differences, and conflicts.

[0043] 7. Consistency score: refers to the result of quantitatively evaluating the similarity or degree of conflict among multiple candidate results in dimensions such as implementation path, modified files, patch semantics, test coverage, scope of impact, and risk description.

[0044] 8. Credibility score: refers to the credibility of candidate results obtained by comprehensively considering factors such as consistency of candidate results, historical performance of the model, task suitability, sufficiency of testing, degree of risk conflict, and verification cost.

[0045] 9. Model Capability Profile: This refers to profile data that records the historical success rate, failure reasons, manual modification rate, execution time, and cost of different models or runtimes under different languages, frameworks, repository types, task types, and risk levels.

[0046] 10. Degradation routing: This refers to the mechanism by which the system transfers the task to a strong model for rerun, increases the verification intensity, reduces the automation level, outputs only an analysis report, or allows manual intervention when there are significant conflicts between candidate results, insufficient credibility scores, or high task risks.

[0047] 11. Arbitration ledger: refers to the collection of audit records that document candidate results, normalization fields, scoring criteria, conflict items, reasons for adoption, reasons for downgrade, manual feedback, and final results.

[0048] II. Technical Problem to be Solved by the Invention How to select multiple candidate models or run them under the same AI R&D task, and generate comparable candidate project execution results respectively; How to uniformly convert model outputs, code patches, test plans, risk statements, and execution reports in different formats into candidate result objects; How to align the differences among multiple candidate results across engineering dimensions such as plans, documents, patch semantics, test coverage, impact scope, and risk descriptions; How to calculate the credibility score of candidate results by combining candidate result consistency, model historical performance, task suitability, test sufficiency, risk conflict and cost factors; How to determine arbitration decisions such as automatic adoption, merged adoption, strong model rerun, enhanced validation, reporting only, or manual takeover based on consistency score, credibility score, conflict level, and task risk level; How to write back the arbitration results, verification results, human feedback and failure reasons to the model capability profile to optimize the candidate runtime selection and degradation route for subsequent tasks; How to create an arbitration ledger that includes candidate results, scoring criteria, conflicting items, reasons for adoption / downgrade, and final results, to support review, auditing, and strategy optimization.

[0049] III. Technical Route of the Invention This solution can be applied to AI R&D execution platforms, especially suitable for scenarios where a single R&D task can generate candidate results from multiple models, multiple code agents, or multiple project executions. Instead of directly adopting the output of the first model or relying solely on human judgment, the platform performs structured comparisons, reliability scoring, and degradation routing among multiple candidate project results.

[0050] From the product perspective, the main features of this solution are: multiple candidate models or runtimes can be called according to the strategy for the same task; the platform automatically compares the implementation plans, code patches, test plans and risk descriptions of different candidate results; when candidate results are highly consistent and have sufficient credibility, they are automatically adopted; when results conflict or risks are high, the verification intensity is automatically increased, a strong model is used for rerun, the automation level is reduced or manual intervention is implemented; each arbitration, verification and manual feedback will write back the model capability profile and record it in the arbitration ledger.

[0051] IV. Technical Content of the Invention The following section will describe in detail the technical implementation process of this application from the perspectives of system architecture and methodology.

[0052] Example 1, System Introduction like Figure 1 As shown, this system includes: Task receiving module: Receives external AI R&D task requests, parses basic task information, extracts full task features including task language, repository type, task type, risk level, scope of change, expected output, and resource constraints, and outputs standardized task feature data packets to the candidate runtime routing module; Candidate Runtime Routing Module: Input task features + model capability profile binned data, filter multiple suitable models / runtimes through adaptation scoring formula, output candidate runtime list and send it to candidate result generation module; read profile data before new task execution, and receive updated profile data after task completion to iterate its own routing strategy; Candidate Result Generation Module: Receives a list of candidate runtimes and the original AI R&D tasks, drives each runtime to independently generate candidate project execution results, and batch outputs multiple original unstructured candidate outputs to the structured normalization module; The results structured normalization module receives multiple raw candidate outputs without a uniform format, parses the text, patch, command, and report content, extracts standardized fields, encapsulates them into a unified candidate result object array, and outputs the normalized candidate set to the engineering difference alignment module. Engineering Difference Alignment Module: Input a normalized candidate result object array, perform pairwise / multi-party comparisons from seven engineering dimensions: implementation plan, files, functions, interfaces, databases, tests, and risks, generate an engineering difference matrix carrying similarity, conflict type, and conflict severity, and synchronize the difference matrix to the consistency scoring and conflict level calculation modules; Consistency scoring module: Input the engineering difference matrix, calculate the consistency score based on multi-dimensional similarity weighting, and output the score value to the credibility scoring module and arbitration decision module; The credibility scoring module takes six parameters as input: consistency score, model historical success rate, task fit, test sufficiency, risk conflict, and execution cost. It calculates the credibility score of a single candidate using a weighted formula and outputs the credibility score of each candidate to the arbitration decision module. Conflict Level Module: Calculates the conflict level based on the difference matrix, marks the weight of high-risk conflicts, and outputs the conflict level to the arbitration decision module; Arbitration decision module: It uniformly receives four inputs: consistency score, credibility score, conflict level, and original risk level of the task, matches them with preset arbitration threshold rules, and outputs arbitration branch instructions: automatic adoption, merged adoption, strong model rerun, enhanced verification, reduced automation, and manual takeover; and sends the arbitration instructions to the degradation routing module. Degradation routing module: Receives arbitration branch instructions and completes task routing and scheduling: If the instruction is to rerun, it sends back to the candidate runtime routing module to re-call the strong model; if the instruction is to enhance verification, it issues a verification execution instruction; if the instruction is to manually take over / report only, it directly pushes the task archiving signal to the verification feedback module. Verification and Feedback Module: Receives final engineering deliverables, sandbox test results, build scan reports, and manual review comments, and converts them into standardized evaluation samples (adoption status, manual modification rate, failure reasons, and time and cost). It outputs bidirectionally: ① Evaluation samples are fed back to the capability profiling module to update the profiling; ② Execution data from the entire process is pushed to the arbitration ledger module for persistent storage. Arbitration ledger module: a full-link data persistence unit that receives all raw data, normalized objects, difference matrices, various scores, conflict records, arbitration instructions, downgrade records, verification feedback, and manual operation records throughout the entire task lifecycle, and generates an auditable arbitration ledger that supports retrieval, review, and risk control tracing.

[0053] The system's operating logic is as follows: Receive AI R&D task requests and collect task descriptions, target repositories, task types, risk levels, expected outputs, task languages, involved frameworks, execution constraints, and a list of available models / runtimes.

[0054] The candidate runtime routing module selects one or more candidate models or execution runtimes based on task characteristics, model capability profiles, cost constraints, and risk levels. This selection may include low-cost runtimes, runtimes that are proficient in specific languages, test-generative runtimes, and high-cost, model-strong runtimes.

[0055] The candidate result generation module drives the selected model or runtime to generate candidate implementation plans, candidate code patches, candidate test plans, candidate risk descriptions, and candidate execution reports, respectively.

[0056] The structured normalization module converts candidate outputs in different formats into a unified candidate result object, including the list of modified files, Diff summary, test commands, scope of impact, risk items, expected verification evidence, and execution cost.

[0057] The engineering difference alignment module aligns and compares file modifications, function modifications, interface changes, configuration changes, database changes, test coverage, and risk descriptions among candidate results, forming a candidate result difference matrix.

[0058] The consistency scoring module calculates a consistency score among multiple candidate results based on the difference matrix, which is used to identify whether the candidate results have converged and whether there is a core conflict.

[0059] The credibility scoring module combines consistency score, historical success rate of candidate models, task suitability, test adequacy, risk conflicts, and execution cost to calculate the credibility score of candidate results.

[0060] The arbitration decision module determines the final decision based on the credibility score, conflict level, and task risk level, including automatic adoption, merged adoption, strong model rerun, enhanced verification, outputting only the analysis report, reducing the level of automation, or manual takeover.

[0061] When the reliability score is insufficient, candidate results conflict, or the task risk is too high, the degradation routing module will route the task to the strong model for rerun, increase the verification intensity, reduce the automation level, or handle it manually.

[0062] The capability profiling module records the historical performance of different models or runtimes under task language, framework, repository type, task type and risk level, and provides a basis for subsequent routing.

[0063] The verification feedback module receives test execution results, build results, static scan results, manual review conclusions, and online feedback, and converts them into rewritable evaluation samples.

[0064] The arbitration ledger module records candidate results, normalization fields, scoring process, conflict items, reasons for adoption, reasons for downgrade, manual feedback, and final results.

[0065] Please refer to Example 2 below for a detailed understanding of the system's operation.

[0066] Example 2, Method Description like Figure 2 As shown, a multi-model engineering execution result arbitration and degradation routing method for AI R&D tasks includes the following steps: Receive external AI R&D task requests, extract standardized task features based on the target warehouse context, and the task features should include at least the task language, warehouse type, task type, risk level, scope of change, expected output, and execution constraints. Read the pre-stored model capability profile, combine task characteristics and resource constraints to calculate candidate runtime adaptation indicators, and select at least two different models / execution runtimes as candidate sets; When all candidate models selected by the driver are executed, multiple candidate engineering execution results are generated in parallel for the same AI R&D task. Perform structured normalization processing on multiple candidate project execution results with inconsistent formats, and convert them into a set of candidate result objects with uniform fields; Perform multi-dimensional engineering difference alignment processing on the candidate result object set to generate an engineering difference matrix carrying similarity, difference type, and conflict severity; Based on the engineering difference matrix, two quantitative indicators, consistency score and conflict level, were calculated respectively. The credibility score of each candidate result is calculated by integrating six dimensions: consistency score, model historical performance, task matching degree, test completeness, risk conflict, and execution cost. Arbitration decisions are made by combining consistency score, credibility score, conflict level, and original task risk level, and corresponding scheduling instructions are output. According to the arbitration scheduling instructions, the degraded routing is executed. The routing types include strong model rerun, enhanced verification, merged adoption, automatic adoption, output report only, and manual takeover. The system collects automated testing and manual review feedback of the final engineering products to generate standardized evaluation samples, and writes the samples back to update the model capability profile; at the same time, it persistently writes the original data of the entire task chain, intermediate calculation indicators, arbitration records, downgrade records, and manual operation records into the arbitration ledger to complete the audit retention.

[0067] The process is explained in detail below: 1. The platform receives R&D tasks and collects task descriptions, target repositories, task types, risk levels, expected outputs, task languages, involved frameworks, execution constraints, and a list of available models / runtimes, etc.

[0068] Second, the candidate runtime routing module reads the model capability profile and selects multiple candidate models or runtimes according to task type and risk level.

[0069] One or more candidate models or runtimes are selected based on task characteristics, model capability profiles, cost constraints, and risk levels; this selection may include low-cost runtimes, runtimes proficient in specific languages, test-generative runtimes, and high-cost, model-strong runtimes.

[0070] The following is one method for selecting candidates based on the RouteScore formula for runtime adaptation: RouteScore(m,t) = p1 * LangMatch + p2 * RepoMatch + p3 *TaskTypeSuccess + p4 * RiskFit - p5 * Cost Where m represents the candidate model or runtime, t represents the current task; LangMatch represents the language matching degree; RepoMatch represents the repository type matching degree; TaskTypeSuccess represents the historical success rate of similar tasks; RiskFit represents the risk level fit; and Cost represents the estimated cost or time consumption.

[0071] Third, multiple candidate models or runtimes will generate candidate implementation plans, code patches, test plans, risk descriptions, and execution reports respectively. Specifically, the selected model or runtime will generate candidate implementation plans, candidate code patches, candidate test plans, candidate risk descriptions, and candidate execution reports respectively.

[0072] Fourth, the result structuring and normalization module converts candidate results in different formats into a unified candidate result object.

[0073] Convert candidate outputs of different formats into a unified candidate result object, including the list of modified files, Diff summary, test commands, scope of impact, risk items, expected verification evidence, and execution cost.

[0074] like Figure 3 As shown, the structured normalization of candidate results is the foundation of this scheme. Different models or runtimes may output results in the form of natural language, patch files, command lists, or report text, which the system converts into a unified candidate result object.

[0075] Candidate result objects may include at least the fields shown in Table 1 below: Table 1 V. Engineering Difference Alignment Module: Compare the implementation paths, modified files, patch semantics, test coverage, scope of impact, and risk descriptions of candidate results.

[0076] Align and compare the file modifications, function modifications, interface changes, configuration changes, database changes, test coverage, and risk descriptions among the candidate results to form a candidate result difference matrix.

[0077] The engineering difference alignment module performs pairwise or multi-way alignment on multiple candidate result objects. The alignment dimensions may include: Plan alignment: Identify whether the implementation steps of candidate results point to the same technical path, and whether there are any missing or mutually exclusive steps.

[0078] File alignment: Compare the set of modified files in the candidate results, the hit rate of core files, and the status of added / deleted files.

[0079] Patch semantic alignment: Semantic similarity is identified through AST changes, function signature changes, API call chains, configuration key changes, or patch digest vectors.

[0080] Test coverage alignment: Compare whether candidate tests cover the same modules, boundary conditions, failure paths, and regression ranges.

[0081] Risk description alignment: Compare whether the candidate results are consistent in their judgments on database, permissions, interface compatibility, performance, security, and rollback risks.

[0082] The engineering discrepancy alignment module outputs a discrepancy matrix. This matrix records not only similarity but also conflict type, conflict location, and conflict severity. For example, if two candidate results both modify the same interface but return different fields, they can be marked as "interface definition conflict"; if one candidate result modifies a database field while the other fails to recognize the change, it can be marked as "missing impact scope."

[0083] VI. The consistency scoring module and the credibility scoring module output the consistency score, credibility score, and conflict level, respectively.

[0084] The system calculates the consistency score of candidate results from five dimensions: plan consistency, document consistency, patch semantic consistency, test coverage consistency, and risk description consistency.

[0085] 1. In one embodiment, the consistency score (ConsistencyScore) can be expressed as: ConsistencyScore = w1 * PlanSim + w2 * FileOverlap + w3 * PatchSim + w4 * TestCoverageSim + w5 * RiskAgreement Among them, PlanSim represents the similarity of implementation plans; FileOverlap represents the overlap of candidate result modification file sets; PatchSim represents the semantic similarity of patches; TestCoverageSim represents the similarity of test coverage; RiskAgreement represents the consistency of risk descriptions; w1 to w5 are weight parameters, and the weights can be configured by the system or learned through historical data (other weights / systems are set similarly).

[0086] This formula is only one example. In actual implementation, engineering dimensions such as interface compatibility consistency, database change consistency, permission logic consistency, and build impact consistency can be added according to the task type.

[0087] The candidate result credibility score is used to determine whether a single candidate result is acceptable. The credibility score depends not only on the model's own output, but also on its historical performance and the context of the current task.

[0088] 2. In one embodiment, the candidate result trust score can be expressed as: TrustScore = a * ConsistencyScore + b * HistorySuccess + c *TaskFitness + d * TestAdequacy - e * RiskConflict - f * CostPenalty Here, HistorySuccess represents the historical success rate of the model or runtime in similar tasks; TaskFitness represents the model's ability to adapt to the current task's language, framework, and repository type; TestAdequacy represents the sufficiency of candidate test schemes; RiskConflict represents the degree of risk conflict in the candidate results; CostPenalty represents the execution cost or time penalty; and a to f are weight parameters.

[0089] Trustworthiness scoring can use different thresholds based on the task's risk level. For example, low-risk document or test supplement tasks can use lower adoption thresholds; tasks involving permissions, data migration, payments, authentication, and core interfaces should use higher adoption thresholds and require greater validation adequacy.

[0090] 3. To avoid the mistaken adoption of candidate results when there are serious disagreements on core engineering items, the system also calculates the ConflictLevel.

[0091] In one embodiment, the conflict level can be expressed as: ConflictLevel = q1 * (1 - FileOverlap) + q2 * PatchConflict + q3 *TestGap + q4 * RiskDisagreement + q5 * CoreChangeConflict Among them, PatchConflict represents the degree of semantic conflict of patches; TestGap represents the difference in candidate test coverage; RiskDisagreement represents the degree of disagreement in risk descriptions; CoreChangeConflict represents the degree of conflict of high-risk changes such as core files, databases, permissions, and interface definitions; q1 to q5 are weight parameters.

[0092] When the ConflictLevel is higher than the preset threshold, even if a candidate result has a high TrustScore, the system will not automatically adopt it directly, but will trigger a strong model rerun, enhanced validation, or manual intervention.

[0093] VII. The arbitration decision module performs automatic adoption, merged adoption, strong model rerun, enhanced verification, reporting only, or manual takeover based on the score, conflict level, and task risk level.

[0094] like Figure 4 As shown, the arbitration decision module generates decision results based on consistency score, credibility score, conflict level, and task risk level. Decision results include at least automatic adoption, merged adoption, strong model rerun, increased validation strength, reduced automation level, outputting only an analysis report, and manual takeover.

[0095] When multiple candidate results have a consistency score higher than the first threshold, a conflict level lower than the conflict threshold, and at least one candidate result has a credibility score higher than the adoption threshold, the system adopts the candidate result with the highest credibility score.

[0096] When two or more candidate results converge on the patch body, but the test plans or risk statements are complementary, the system can perform a merge adoption, that is, adopt one candidate patch and merge the test suggestions or risk statements of other candidate results.

[0097] When the consistency of candidate results is insufficient but the task risk is low, the system can call a strong model or a higher-cost runtime for secondary arbitration.

[0098] When candidate results are not consistent enough and test coverage is insufficient, the system first triggers enhanced verification, including supplementary test generation, static scanning, build verification, impact analysis, or sandbox replay.

[0099] When conflicts arise between candidate results in core files, database changes, permission logic, interface definitions, or security policies, the system reduces its automation level, outputting only an analysis report or transferring the task to manual intervention.

[0100] Once manual processing is complete, the system will write back a capability profile including the reasons for manual acceptance, modification, rejection, and final verification results.

[0101] 8. After the task is completed, the verification feedback module will write the verification results and human feedback into the capability profile, and the arbitration record module will record the entire process.

[0102] like Figure 5 As shown, after the task is completed, the system writes back information such as whether the candidate results were adopted, whether the verification passed, the proportion of manual modifications, the reasons for failure, execution time, and cost to the model capability profile. The capability profile is at least bucketed by task language, framework, task type, risk level, repository size, and historical failure type.

[0103] For example, if a runtime generates multiple verifiable patches in a Java interface defect fixing task, its HistorySuccess score increases for its corresponding language and task type; if another runtime's patches are not adopted, but its test solutions are frequently merged and adopted, its "test generation capability" score increases. When selecting candidate models or runtimes for subsequent tasks, the candidate runtime routing module prioritizes models or runtimes that perform better in similar tasks, and can choose whether to call the strong model simultaneously based on cost constraints.

[0104] In this embodiment, the weights, thresholds, and number of dimensions in the above formula can be adjusted according to system configuration, task type, and historical samples, and should not be construed as a limitation on the scope of protection.

[0105] The following parameters are for illustrative purposes only and are not intended to limit the scope of the claims: Consistency adoption threshold: ConsistencyScore greater than or equal to 0.8; TrustScore adoption threshold: TrustScore greater than or equal to 0.75; High conflict threshold: ConflictLevel greater than or equal to 0.6; Strong model rerun trigger conditions: ConsistencyScore is less than 0.75 and the task risk level is not lower than medium; Manual takeover trigger conditions: High-risk tasks and candidate results conflict in core modules, permission logic, interface definitions or data changes.

[0106] Application Example 1 An AI R&D execution platform needs to handle a backend interface defect repair task. This task involves Java services, has a medium risk level, and the expected outputs are an implementation plan, code patches, and interface testing solutions.

[0107] System configuration: The platform integrates three candidate runtimes: Runtime-A, Runtime-B, and Runtime-C. Runtime-A has historically excelled at Java service repair, Runtime-B at test generation, and Runtime-C is a high-cost, high-model runtime.

[0108] The processing procedure is as follows: After receiving the task, the platform extracts the task characteristics, identifies the task language as Java, the task type as interface defect repair, and the risk level as medium.

[0109] The candidate runtime routing module selects Runtime-A and Runtime-B based on the capability profile to generate candidate results, and retains Runtime-C as the secondary arbitration runtime.

[0110] Runtime-A outputs patches for modifying the Controller and Service, and provides an interface testing plan; Runtime-B outputs patches for modifying the Service and Mapper, and provides a more complete interface and boundary testing plan.

[0111] The structured normalization module converts two candidate results into a unified candidate result object and extracts modified files, patch summaries, test coverage, and risk descriptions.

[0112] The engineering difference alignment module found that both candidate results involve the Service layer, but there is a difference in whether the Mapper layer is modified: FileOverlap is 0.6 and RiskAgreement is 0.7.

[0113] The Trust Score module combines historical success rate and test adequacy to calculate a TrustScore of 0.78 for Runtime-A candidate results and 0.74 for Runtime-B candidate results, but the ConflictLevel is moderate.

[0114] The arbitration decision module does not directly adopt any result, but instead calls Runtime-C for secondary arbitration. Runtime-C confirms that the Mapper layer does not require modification and supplements interface boundary tests.

[0115] The system ultimately adopted the core patch from Runtime-A and incorporated the test recommendations from Runtime-B to generate the final project execution result.

[0116] After the task is completed, the system will write the successful samples of Runtime-A in the Java interface defect repair task into the capability profile, and at the same time record the test generation advantages of Runtime-B and the arbitration role of Runtime-C.

[0117] Based on the above application method, this application has the following technical advantages: Avoid excessive modifications caused by directly adopting the results of a single model; By identifying candidate result conflicts, key differences that may require modification to the Mapper layer can be discovered. The risk of erroneous implementation paths being adopted is reduced through strong model-based secondary arbitration. By merging and adopting supplementary candidate results, the advantages of the test schemes can be improved. Improve the accuracy of candidate runtime selection for subsequent similar tasks by backflowing capability profiles.

[0118] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0119] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0120] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0121] It should be understood that, in various embodiments of the present invention, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0122] 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, or a combination of computer software and electronic hardware. 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.

[0123] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0124] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0125] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0126] In addition, the functional units in the various embodiments of the present 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.

[0127] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a 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, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0128] 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 variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included 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 method for arbitration and degradation routing of multi-model engineering execution results for AI R&D tasks, characterized in that, Includes the following steps: Receive external AI R&D task requests, extract standardized task features based on the target warehouse context, and the task features should include at least the task language, warehouse type, task type, risk level, scope of change, expected output, and execution constraints. Read the pre-stored model capability profile, combine task characteristics and resource constraints to calculate candidate runtime adaptation indicators, and select at least two different models / execution runtimes as candidate sets; When all candidate models selected by the driver are executed, multiple candidate engineering execution results are generated in parallel for the same AI R&D task. Perform structured normalization processing on multiple candidate project execution results with inconsistent formats, and convert them into a set of candidate result objects with uniform fields; Perform multi-dimensional engineering difference alignment processing on the candidate result object set to generate an engineering difference matrix carrying similarity, difference type, and conflict severity; Based on the engineering difference matrix, two quantitative indicators, consistency score and conflict level, were calculated respectively. The credibility score of each candidate result is calculated by integrating six dimensions: consistency score, model historical performance, task matching degree, test completeness, risk conflict, and execution cost. Arbitration decisions are made by combining consistency score, credibility score, conflict level, and original task risk level, and corresponding scheduling instructions are output. According to the arbitration scheduling instructions, the degraded routing is executed. The routing types include strong model rerun, enhanced verification, merged adoption, automatic adoption, output report only, and manual takeover. The system collects automated testing and manual review feedback of the final engineering products to generate standardized evaluation samples, and writes the samples back to update the model capability profile; at the same time, it persistently writes the original data of the entire task chain, intermediate calculation indicators, arbitration records, downgrade records, and manual operation records into the arbitration ledger to complete the audit retention.

2. The method according to claim 1, characterized in that: The generated candidate project execution results should include at least the candidate implementation plan, candidate code patch, candidate test plan, and candidate risk description, and may also include change summary, expected verification results, running log, and execution cost; The single candidate result object obtained after structured normalization includes the following fields: CandidateId (unique candidate identifier), RuntimeId (runtime identifier), ModelVersion (model version), PlanItems (implementation plan items), ModifiedFiles (list of modified files), PatchDigest (patch summary), TestPlan (test plan), ImpactScope (impact scope), RiskItems (risk items), ExpectedEvidence (expected verification evidence), and CostMetrics (execution cost metrics).

3. The method according to claim 1, characterized in that, The candidate runtime is selected using the RouteScore calculation formula: In the formula: : The current candidate model to be evaluated / during runtime; Current AI research and development tasks; Configure adjustable weighting coefficients; Model-task programming language matching degree; Model-to-target warehouse type matching degree; : The historical success rate of this runtime for similar tasks; : Run adaptation indicators that are appropriate for the current task's risk level; : Estimated execution time and resource cost penalty value; The system selects multiple candidate models for runtime based on their RouteScore values ​​from high to low, while configuring diversity constraints to ensure model type differentiation.

4. The method according to claim 1, characterized in that, The comparison dimensions for difference alignment include at least two items: implementation plan, modified files, functions / methods, interface definitions, configuration items, database changes, permission logic, test cases, and risk descriptions. The fixed fields of the generated project difference matrix include candidate result pairing identifier, alignment dimension, similarity value, difference description, conflict type, conflict location, conflict severity level, and change impact scope. The alignment method supports pairwise candidate comparison and multi-candidate batch comparison; similarity calculation at the patch and code change level is completed through AST abstract syntax tree, file path, and patch semantic vector.

5. The method according to claim 1, characterized in that, The formula for calculating the ConsistencyScore is as follows: In the formula: Adjustable weights for each dimension; Similarity of multiple candidate implementation plans; : Modify the overlap of the file set; Patch semantic similarity; Test coverage similarity; : The degree of consistency in risk assessment among candidates; the score range is 0 to 1, and the higher the value, the higher the degree of convergence among multiple candidates.

6. The method according to claim 1, characterized in that, TrustScore calculation formula: In the formula: Weighted adjustment coefficient; Consistency score; : The historical verification success rate of similar tasks during runtime; The overall fit between the model and the current task; Indicators of the completeness of candidate test plans; Quantitative value of candidate internal risk conflict; The score represents the cost penalty for execution time and resources; the credibility score ranges from 0 to 1, with a higher score indicating a higher priority for the adoption of a single candidate project result.

7. The method according to claim 1, characterized in that, Conflict Level Calculation Formula: In the formula: Conflict dimension weights; File overlap (derived from consistency score); : The degree of semantic conflict in the patch; : Difference in coverage of multiple candidate tests; Risk assessment disagreement indicators; : Core change conflict coefficient. Core changes include core files, database fields, permission logic, system interfaces, security policies, and rollback process changes. A higher conflict level indicates more severe engineering disagreements and security conflicts among multiple candidates.

8. The method according to claim 1, characterized in that, Arbitration decisions include five categories of determination branches: 1) Automatic branch adoption: If the consistency score is greater than or equal to the preset adoption threshold, the conflict level is lower than the conflict threshold, and at least one candidate has a qualified credibility score, the candidate with the highest credibility score is directly selected as the final product; 2) Merge adoption branches: The main body of each candidate patch converges, and only the test plan and risk warning have complementary content. The best patch is retained and the test and risk suggestions of the other candidates are merged. 3) Strong model rerun branch: When the consistency score is insufficient and the task risk is medium to high, the candidate is regenerated when the high computing power is scheduled to run, and the process is returned to the repeated normalization, alignment and scoring process; 4) Enhanced verification branch: If the test adequacy index fails to meet the standard, it will automatically supplement static code scanning, sandbox replay, and multiple rounds of regression testing before arbitration. 5) Manual takeover / Report only branch: If the conflict level exceeds the high conflict threshold and involves changes to the database, permissions, or core interfaces, reduce the automation level, output only a difference analysis report, and push it for manual processing.

9. The method according to claim 1, characterized in that, Degradation routing trigger conditions: 1) Strong model rerun trigger: Consistency score < preset consistency score value and task risk level is medium or above; 2) Enhanced verification trigger: The completeness index of the candidate test scheme is lower than the preset test completeness threshold; 3) Merge adoption trigger: low semantic conflict in patches, and complementary information between test and risk items; 4) Manual takeover triggered: Conflict level ≥ first preset level, and there are conflicts in core files, databases, permissions, and interface changes; 5) Automatic adoption trigger: Consistency score ≥ preset consistency score, conflict level < second preset level, best candidate credibility score ≥ preset credibility score; After any branch is completed, the degradation type, triggering indicator, and processing time are synchronously recorded and written to the intermediate log, and stored in the arbitration ledger.

10. The method according to claim 1, characterized in that, Model capability profile feedback and arbitration ledger storage mechanism: 1) Model capability profile bucketing statistics dimensions: task language, development framework, repository type, task type, risk level, repository size, and historical failure type; update indicators include runtime historical success rate, test generation capability, manual modification rate, average execution time, and failure frequency; each time a task is completed, an evaluation sample is added to update the corresponding bucket data for the next round of candidate runtime screening; 2) The arbitration ledger permanently stores the following content: original task request, task characteristics, all candidate original outputs, normalized candidate objects, complete engineering difference matrix, consistency / reliability / conflict three-category scores, arbitration decision instructions, downgrade routing records, automated test logs, manual review opinions, final engineering products, and profile update records. The entire chain of data supports auditing, risk control, and algorithm strategy review and retrieval.

Images