A resource allocation method and system based on risk prediction and multi-agent cooperation

Abstract

The application provides a resource allocation method and system based on risk prediction and multi-agent cooperation, wherein when a user intention is captured through an interceptor, a user prompt and a code context related to the user prompt are collected, a composite metric index representing an architecture risk and an impact score is predicted based on the user prompt and the code context related to the user prompt, and a customized execution plan is actively constructed according to the composite metric index and the current user intention, so that the complexity and rigor of the execution plan are proportional to the risk level.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence-assisted technologies, specifically to a resource allocation method and system based on risk prediction and multi-agent collaboration. Background Technology

[0002] As the number of large language models (LLMs) grows, LLM routers, acting as "intelligent traffic controllers," can dynamically select the most suitable model based on queries to balance cost, performance, latency, and compliance. Currently, existing router decisions are entirely based on user-hinted analysis, lacking in-depth analysis of the target code artifacts and failing to understand the code's risks, technical debt, or historical uncertainties. For example, the hint "refactor this function" is handled the same regardless of the complexity of the target code. Summary of the Invention

[0003] The purpose of this invention is to provide a resource allocation method and system based on risk prediction and multi-agent collaboration. While capturing user intent through an interceptor, it collects user prompts and code context related to the user prompts. Based on the user prompts and the code context related to the user prompts, it predicts a composite metric that represents the risk and impact score of the architecture. Based on the composite metric and the current user intent, it proactively constructs a customized execution plan, so that the complexity and rigor of the execution plan are proportional to the risk level.

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

[0005] A resource allocation method based on risk prediction and multi-agent collaboration includes:

[0006] S1. When the interceptor receives a prediction request generated by capturing the current user intent, the orchestration engine is started. The process of generating the prediction request is as follows: while intercepting the user command, the interceptor encapsulates the user prompt obtained through the user command and the code context related to the user prompt into a prediction request.

[0007] S2. The orchestration engine extracts multi-dimensional features from user prompts and their related code context, combines the multi-dimensional features into a single feature vector, and inputs the single feature vector into a pre-trained machine learning model to quantify it into a composite metric for representing architectural risk and impact scores.

[0008] S3. Generate a single-step or multi-step execution plan based on the composite metrics and the current user intent, and assign subtasks to at least one agent according to the execution order in the execution plan.

[0009] A further preferred technical solution is that the user instruction refers to the instruction issued by the user through a shortcut key or command panel. If the instruction includes code generation, code refactoring, code explanation, or chat prompts to answer questions, it is used as a user prompt. At the same time, the relevant code context is collected, which includes the currently active file, the code block selected by the user's cursor, and multiple open files related to the current task.

[0010] A further preferred technical solution is that the multi-dimensional feature extraction includes the following steps:

[0011] The code context related to user prompts is parsed into an abstract syntax tree in advance. Based on the abstract syntax tree, the syntactic and semantic information of the code context related to user prompts is captured, and code indicator features are obtained by analyzing the syntactic and semantic information of the code.

[0012] Historical dynamic indicators are obtained by mining historical data warehouses in advance and analyzing historical volatility through code context related to user prompts.

[0013] A technical debt quantification sub-model is obtained in advance, and the code context related to user prompts is quantified using the technical debt quantification sub-model to obtain quantitative indicators;

[0014] Predefined task types are obtained in advance, semantic analysis is performed on user prompts, and the analysis results are matched with the predefined task types. The successfully matched task types are taken as the current user intent.

[0015] Multidimensional features include indicator features, historical dynamic indicators, quantitative indicators, and current user intent.

[0016] A further preferred technical solution is that the code metric features include complexity metrics and object-oriented metrics. The complexity metrics are used to measure the code complexity in the code context related to user prompts; the object-oriented metrics are used to measure the impact of object-oriented aspects of the code context related to user prompts.

[0017] A further preferred technical solution is that the historical volatility analysis process is as follows: find relevant historical records in the historical database through the code context related to user prompts, and obtain corresponding historical dynamic indicators by analyzing the historical records. The historical dynamic indicators include code dropout rate, defect introduction history, user experience, and submission frequency.

[0018] A further preferred technical solution is that the process of quantifying the code context related to user prompts through the technical debt quantification sub-model to obtain quantitative indicators is as follows: the technical debt quantification sub-model quantifies the code context related to user prompts based on factors such as code smells, lack of test coverage, and dependency aging, and obtains quantitative indicators presented in the form of scores; among them, the factors of code smells, lack of test coverage, and dependency aging are all used to represent the degree of risk generated when the code area is modified.

[0019] A further preferred technical solution is that the process of generating a single-step or multi-step execution plan based on the composite metric and the current user intent is as follows: obtain a pre-set strategy rule model, take the composite metric, the current user intent, and the preset project configuration as inputs into the strategy rule model, and output a single-step or multi-step execution plan by setting the priority of the current user intent to be higher than the priority of the composite metric in the strategy rule model.

[0020] A further preferred technical solution is that the intelligent agent is an independent logical unit, which encapsulates one or more AI models or tools, so that each intelligent agent is responsible for different sub-tasks. Then, the corresponding intelligent agent is selected according to the sub-task in the execution plan, and the corresponding intelligent agents are configured for the sub-tasks in sequence according to the execution order of the sub-tasks.

[0021] A resource allocation system based on risk prediction and multi-agent cooperation, employing the aforementioned resource allocation method based on risk prediction and multi-agent cooperation, includes:

[0022] Interception module: When the interceptor receives a prediction request generated by capturing the current user intent, it starts the orchestration engine; the generation process of the prediction request is as follows: while intercepting the user command, the interceptor encapsulates the user prompt obtained through the user command and the code context related to the user prompt into a prediction request;

[0023] Risk prediction module: The orchestration engine extracts multi-dimensional features from user prompts and their related code context, combines the multi-dimensional features into a single feature vector, and inputs the single feature vector into a pre-trained machine learning model to quantify it into a composite metric for representing architectural risk and impact score.

[0024] Multi-agent collaboration module: Generates single-step or multi-step execution plans based on composite metrics and current user intent, and assigns subtasks to at least one agent according to the execution order in the execution plan.

[0025] The beneficial effects of this invention are:

[0026] This invention provides a system based on risk prediction and multi-agent collaboration. It proposes a router comprised of an IDE interceptor plugin, an orchestration engine, and a pool of specialized agents. Through the collaborative work of these three components, a closed loop from request interception to task execution is formed. Compared to existing technologies, the dynamic nature of the workflow within this closed loop is transformed into one driven by the inherent risk of the code. This transforms the system from a passive "selector" to an active "planner." A customized execution plan is constructed primarily through a composite metric representing architectural risk and impact score obtained from the routing engine. The complexity and rigor of the execution plan are proportional to the risk level. This workflow transformation is significant. It can be seen that the composite metric representing architectural risk and impact score not only determines which model to use but also how the entire task is executed and the degree of automated verification required. This enables the router proposed in this invention to become an intelligent system capable of automatically adjusting its operational rigor based on the inherent vulnerabilities of the code. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating the resource allocation method in Embodiment 1 of the present invention;

[0028] Figure 2 This is a schematic diagram of the decision matrix in Embodiment 1 of the present invention. Detailed Implementation

[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the present invention or its application or use. 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.

[0030] Unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of the invention.

[0031] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0032] Furthermore, for clarity and brevity, descriptions of well-known structures, functions, and configurations may have been omitted. Those skilled in the art will recognize that various changes and modifications can be made to the examples described herein without departing from the spirit and scope of this disclosure.

[0033] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0034] In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0035] The present invention will now be described in detail with reference to the accompanying drawings and embodiments:

[0036] Example 1

[0037] In this embodiment, a resource allocation method based on risk prediction and multi-agent cooperation is proposed, such as... Figure 1 As shown, the resource allocation method mainly includes the following steps:

[0038] S1. When the interceptor receives a prediction request generated by capturing the current user intent, the orchestration engine is started. The process of generating the prediction request is as follows: while intercepting the user command, the interceptor encapsulates the user prompt obtained through the user command and the code context related to the user prompt into a prediction request.

[0039] S2. The orchestration engine extracts multi-dimensional features from user prompts and their related code context, combines the multi-dimensional features into a single feature vector, and inputs the single feature vector into a pre-trained machine learning model to quantify it into a composite metric for representing architectural risk and impact scores.

[0040] S3. Generate a single-step or multi-step execution plan based on the composite metrics and the current user intent, and assign subtasks to at least one agent according to the execution order in the execution plan.

[0041] A further preferred technical solution is that the user instruction refers to the instruction issued by the user through a shortcut key or command panel. If the instruction includes code generation, code refactoring, code explanation, or chat prompts to answer questions, it is used as a user prompt. At the same time, the relevant code context is collected, which includes the currently active file, the code block selected by the user's cursor, and multiple open files related to the current task.

[0042] A further preferred technical solution is that the multi-dimensional feature extraction includes the following steps:

[0043] The code context related to user prompts is parsed into an abstract syntax tree in advance. Based on the abstract syntax tree, the syntactic and semantic information of the code context related to user prompts is captured, and code indicator features are obtained by analyzing the syntactic and semantic information of the code.

[0044] Historical dynamic indicators are obtained by mining historical data warehouses in advance and analyzing historical volatility through code context related to user prompts.

[0045] A technical debt quantification sub-model is obtained in advance, and the code context related to user prompts is quantified using the technical debt quantification sub-model to obtain quantitative indicators;

[0046] Predefined task types are obtained in advance, semantic analysis is performed on user prompts, and the analysis results are matched with the predefined task types. The successfully matched task types are taken as the current user intent.

[0047] Multidimensional features include indicator features, historical dynamic indicators, quantitative indicators, and current user intent.

[0048] A further preferred technical solution is that the code metric features include complexity metrics and object-oriented metrics. The complexity metrics are used to measure the code complexity in the code context related to user prompts; the object-oriented metrics are used to measure the impact of object-oriented aspects of the code context related to user prompts.

[0049] A further preferred technical solution is that the historical volatility analysis process is as follows: find relevant historical records in the historical database through the code context related to user prompts, and obtain corresponding historical dynamic indicators by analyzing the historical records. The historical dynamic indicators include code dropout rate, defect introduction history, user experience, and submission frequency.

[0050] A further preferred technical solution is that the process of quantifying the code context related to user prompts through the technical debt quantification sub-model to obtain quantitative indicators is as follows: the technical debt quantification sub-model quantifies the code context related to user prompts based on factors such as code smells, lack of test coverage, and dependency aging, and obtains quantitative indicators presented in the form of scores; among them, the factors of code smells, lack of test coverage, and dependency aging are all used to represent the degree of risk generated when the code area is modified.

[0051] A further preferred technical solution is that the process of generating a single-step or multi-step execution plan based on the composite metric and the current user intent is as follows: obtain a pre-set strategy rule model, take the composite metric, the current user intent, and the preset project configuration as inputs into the strategy rule model, and output a single-step or multi-step execution plan by setting the priority of the current user intent to be higher than the priority of the composite metric in the strategy rule model.

[0052] A further preferred technical solution is that the intelligent agent is an independent logical unit, which encapsulates one or more AI models or tools, so that each intelligent agent is responsible for different sub-tasks. Then, the corresponding intelligent agent is selected according to the sub-task in the execution plan, and the corresponding intelligent agents are configured for the sub-tasks in sequence according to the execution order of the sub-tasks.

[0053] Based on the above principles, the present invention will be further described as follows:

[0054] Since the core function of LLM routers is to dynamically select the most suitable model to process requests based on the input query, and the decision-making logic of LLM routers is entirely based on the analysis of user input prompts, this prompt-centric routing mechanism can be summarized into the following steps: (1) receiving the user's natural language query; (2) classifying the query and determining its intent, such as whether it is a "summarizing task" or a "code generation task"; (3) routing the query to the most suitable model based on the classification result. It can be seen that this method is only prompt-centric, and its fundamental limitation lies in its context-blindness to the "target" of the query.

[0055] For example, consider a developer suggestion: "Refactor this function to improve readability." For an existing router, whether the suggestion points to a 10-line helper function with no dependencies or a 500-line complex core business logic method with high cyclomatic complexity and frequent bugs in its version history, the router will process it the same way. It will only see the word "refactor" and not the inherent properties of the code being refactored.

[0056] Therefore, a crucial, unmet need is the lack of in-depth analysis of the modified "code artifacts" themselves in routing decisions. Existing systems lack "architectural awareness"; they fail to understand the inherent risks, technical debt, or historical uncertainties of the code they are required to modify. Therefore, this invention proposes a resource allocation method based on risk prediction and multi-agent collaboration, which can create a system whose routing logic is primarily driven by the re-evaluation of the target code, rather than merely by prompts.

[0057] First, this invention proposes a router consisting of an IDE interceptor plugin, an orchestration engine, and a pool of professional intelligent agents. Through the collaborative work of the IDE interceptor plugin, the orchestration engine, and the pool of professional intelligent agents, a closed loop is formed from request interception to task execution.

[0058] The IDE Interceptor Plugin is a lightweight plugin designed to be integrated into mainstream IDEs (such as Visual Studio Code). Its main responsibilities are: (1) Capturing developer intent: intercepting instructions issued by developers through specific shortcut keys or command panels, such as code generation, refactoring, code explanation, or chat prompts to answer questions; (2) Extracting context: while capturing instructions, the plugin automatically collects relevant code context, including the currently active file, the code block selected by the developer's cursor, and even multiple open files related to the current task; (3) Encapsulation and forwarding: encapsulating the captured developer prompts and code context into a standardized request object and sending it to the system's orchestration engine through the API.

[0059] The orchestration engine receives requests from the IDE interceptor and performs the following key functions: (1) Invoking the risk-aware routing engine: Passing the code context in the request to an internal risk-aware routing engine, which returns a quantified “Architecture Risk and Impact Score” (ARIS), a composite metric used to represent the architecture risk and impact score; (2) Formulating an execution plan: Unlike traditional routers that simply select a model, the orchestration engine dynamically generates a single-step or multi-step execution plan based on the ARIS score and the task type (such as “new feature” or “refactoring”) parsed from the developer’s hints; (3) Task allocation and coordination: The orchestration engine allocates subtasks to the most suitable agent in the “Specialist Agent Pool” below according to the generated plan.

[0060] A pool of specialized intelligent agents is a modular collection of agents, each an independent logical unit that encapsulates one or more specific AI models or tools. This design makes the system highly scalable, allowing for easy addition, updating, or replacement of agents to adapt to evolving AI technologies.

[0061] Specifically, the initial pool of agents may include the following roles:

[0062] Agent A (Architect): This agent encapsulates the most powerful but also the most expensive model, such as Cursor's advanced agent pattern or OpenAI's GPT-4. Its expertise lies in handling complex, zero-based code generation tasks, such as building a complete new page or module.

[0063] Agent B (Refactorer): This agent encapsulates a cost-effective model that performs well in code processing, such as Anthropic's Claude Code or a finely tuned open-source model (such as Qwen-Coder). Its main task is to perform code modifications, iterative improvements, and low-risk refactoring.

[0064] Agent C (Test Engineer): This is an agent specifically designed to generate unit tests, integration tests, or end-to-end test scripts. It may use a model that has been fine-tuned on a large amount of test code to improve the accuracy and coverage of the generated tests.

[0065] Agent D (Code Reviewer): This agent is responsible for automatically reviewing the code generated by other agents. It can call specialized tools or models to scan for potential security vulnerabilities, performance bottlenecks, non-compliance with coding standards, or code that does not meet compliance requirements such as HIPAA / PCI / DSS.

[0066] Based on this, the core of this invention lies in the dynamism of the router workflow. Compared with the existing technology, the dynamism of the workflow in the closed loop from request interception to task execution is changed to be driven by the inherent risk of the code. The inherent risk of the code is realized through the dynamic risk-aware routing engine in the orchestration engine, so that the system transforms from a passive "selector" into an active "planner".

[0067] The dynamic risk-aware routing engine shifts the decision-making basis for AI model selection from traditional, prompt-based analysis to a multi-dimensional, quantitative architectural risk assessment of the target code artifact. Specifically, this invention proposes that the dynamic risk-aware routing engine output a composite metric, ARIS, representing the architectural risk and impact score. ARIS is a floating-point number between 0.0 and 1.0, designed to quantify the probability of negative consequences that may result from modifying a specific code artifact. It can be seen that a high ARIS score means that modifying that code segment is likely to introduce defects, break existing functionality, reduce system performance, or increase future maintenance costs.

[0068] ARIS's computation relies on a complex prediction model whose accuracy depends on the quality and breadth of its input features. In this embodiment, information sources from four different dimensions are integrated to construct a comprehensive and three-dimensional code profile.

[0069] The first method is static code analysis using an abstract syntax tree:

[0070] The modified code is parsed into an Abstract Syntax Tree (AST). Based on the AST, syntactic and semantic information of the code context related to user prompts is captured. Code metrics features are obtained by analyzing the syntactic and semantic information of the code. Here, AST is a tree-like data structure that can accurately represent the syntactic structure of code, ignoring unimportant formatting details (such as parentheses and semicolons), thus enabling the extraction of deep-level structural features. It can be seen that compared with traditional token-based methods that treat code as plain text, AST-based methods can better capture the syntactic and semantic information of code and understand its inherent complexity. Specifically, a series of code metrics features are extracted from the AST, including:

[0071] Complexity metrics: (1) Cyclic complexity: measures the number of independent execution paths in the code. High cyclomatic complexity usually means that the code is difficult to understand, test and maintain, and is positively correlated with the defect rate; (2) Cognitive complexity: measures the difficulty of understanding the logic of the code. It punishes structures that interrupt the linear reading process (such as nested loops and condition judgments) and is a powerful indicator of code maintainability.

[0072] Object-Oriented Metrics (based on the CK Metrics Suite and its extensions): (1) Coupling between objects: The number of other classes a class depends on. High coupling means that modifying a class may have a ripple effect on other parts of the system, increasing the risk of introducing errors. (2) Lack of method cohesion: Measures whether the methods of a class serve a common goal. A high LCOM value (low cohesion) indicates that the class assumes too many unrelated responsibilities, which is a sign of poor design and is usually associated with a higher defect rate. (3) Inheritance tree depth: The depth of a class in its inheritance hierarchy. An excessively deep inheritance tree increases complexity and makes the behavior of the class unpredictable. (4) Number of subclasses: The number of direct subclasses of a class. A high NOC value may indicate that the base class is an unstable abstraction, and its changes will affect a large number of subclasses.

[0073] Size metrics: (1) Lines of code: Although simple, LOC is still one of the most stable and powerful single metrics for predicting defects; (2) Number of public methods: The size of a class’s public interface can reflect the complexity and potential instability of its external exposure.

[0074] The second method involves mining software repositories through Git history:

[0075] Since the current state of the code only tells part of the story, the version control history reveals its past evolution patterns, stability, and ease of maintenance. Therefore, this invention extracts highly predictive features by analyzing Git logs, namely historical dynamic indicators obtained through historical volatility analysis, specifically:

[0076] Change frequency: The number of times a file is modified (committed). Files that are frequently changed are usually the core of the business logic or have design problems, so they are more likely to be changed again in the future.

[0077] Defect introduction tendency: By linking "git blame" with issue tracking systems (such as Jira), it is possible to identify which lines of code have been associated with defect fixes in the past. A file that has frequently introduced errors in the past is likely to become a breeding ground for errors again in the future.

[0078] Last Modification Time: Code that has been recently modified may not have been fully tested, and its stability is uncertain.

[0079] Code ownership: Is a file centrally maintained by a few developers (high ownership) or piecemeal modified by many different developers (low ownership)? Low ownership is often associated with a higher defect rate due to a lack of consistent design vision and coding style.

[0080] The third method is the quantification of technological debt.

[0081] Technical debt refers to suboptimal technical decisions made for short-term gains (such as rapid deployment). These decisions will generate "interest" in the future in the form of increased maintenance costs and reduced development speed. Consequently, code areas with high technical debt are usually more vulnerable and riskier to modify. Therefore, this invention integrates a technical debt quantification sub-model to quantify technical debt, which can give a score based on the following factors:

[0082] Code smells: Identify the number of bad programming practices such as "long methods" and "large classes";

[0083] Missing test coverage: Analyze the test coverage related to the target code. Low coverage means that the risk of modification cannot be fully verified by automated tests.

[0084] Dependency aging: Check whether the libraries or frameworks that the code depends on are outdated. Using outdated dependencies can lead to security and compatibility risks.

[0085] The fourth type is classified by developer intent:

[0086] Semantic analysis can be performed on natural language prompts from developers, categorizing them into predefined task types. Examples include: New Feature, Refactor, Bug Fix, Test Generation, and Documentation. This categorization provides crucial context for risk assessment; for instance, a modification aimed at fixing a known defect is fundamentally different in nature from adding a completely new feature.

[0087] The above four methods for extracting features from information sources of different dimensions are used to obtain multi-dimensional features. Then, the multi-dimensional features are combined into a single feature vector, and the single feature vector is input into a pre-trained machine learning model to predict a composite metric that represents the risk and impact score of the architecture.

[0088] Specifically, when choosing a machine learning model, if the input is structured tabular data, a gradient boosting machine (such as XGBoost or LightGBM) or a random forest regressor can be selected. These ensemble models have good robustness and high performance in handling heterogeneous features (numerical and categorical). Next, data training is performed: model training requires a large, labeled historical codebase. This can be achieved by analyzing the Git history of open-source projects and using methods such as the SZZ algorithm to automatically identify which commits introduced defects. For each historical commit, a feature vector of its modified files can be calculated (as the model input X), and whether it introduced a defect can be used as a label (as the model output y, where 1 represents a defect and 0 represents no defect). Finally, the model outputs: after training, the model can output a probability value, ARIS, for any given code modification request (and its feature vector).

[0089] Building upon this, the present invention proposes an intelligent framework for router decision-making driven by ARIS. This decision-making process dynamically adjusts the behavior of each task based on its risk profile, rather than a rigid set of rules. The dynamic decision-making process can be summarized as follows: Figure 2 The decision matrix shown takes ARIS, developer intent classification, and basic project configuration (such as budget constraints) as input to output a clear intention command. The strategy function can be a rule function, which dynamically orchestrates single-step or multi-step execution plans through preset rule functions.

[0090] If, when a developer inputs the message: "Refactor this processPayment function to improve its readability and add more robust error handling logic," the system's response flow is as follows:

[0091] Step 1: Interception and Analysis: The IDE interceptor captures the prompts and the complete code of the processPayment function;

[0092] Step 2, Routing and Planning: (1) AST Analysis: The function was found to have extremely high cyclomatic complexity and cognitive complexity; (2) Git History Analysis: The file was found to be associated with 5 defect fix submissions in the past six months, indicating that its historical volatility is extremely high; (3) Technical Debt Quantification: The technical debt model marked that there are serious design debt and insufficient test coverage in this area; (4) Comprehensive Score: An extremely high ARIS score was calculated, for example, 0.92, which indicates high risk;

[0093] Step 3, orchestration engine generation plan: The high-risk score triggered the most prudent and comprehensive safety-first workflow, specifically: (1) to carry out a well-thought-out, high-quality refactoring; (2) to route to agent C, requiring it to generate detailed unit tests for the new error handling path and verify that the existing functionality has not been broken.

[0094] If, when the developer enters the prompt: "Create a new user profile page, including editable name, email, and bio fields, as well as an area to display recent activity," the system's response flow is as follows:

[0095] Step 1: Interception and Analysis: The IDE interceptor captures the prompt. Since this is a new file creation request with an empty code context, code-based risk analysis is not applicable. Meanwhile, the Developer Intent Classification module identifies the prompt as new feature development.

[0096] Step 2, Routing and Planning: If the intention to develop new features has a high priority in the routing engine's policy rules, then even if ARIS defaults to low, the system will still choose the highest quality pointing path to ensure the integrity of the initial architecture.

[0097] In summary, this invention is based on a composite metric that predicts the risk and impact score of the representation architecture and multi-agent collaboration. It proactively constructs a customized execution plan based on the composite metric and the current user intent, making the complexity and rigor of the execution plan proportional to the risk level.

[0098] Example 2

[0099] A resource allocation system based on risk prediction and multi-agent cooperation, employing the aforementioned resource allocation method based on risk prediction and multi-agent cooperation, includes:

[0100] Interception module: When the interceptor receives a prediction request generated by capturing the current user intent, it starts the orchestration engine; the generation process of the prediction request is as follows: while intercepting the user command, the interceptor encapsulates the user prompt obtained through the user command and the code context related to the user prompt into a prediction request;

[0101] Risk prediction module: The orchestration engine extracts multi-dimensional features from user prompts and their related code context, combines the multi-dimensional features into a single feature vector, and inputs the single feature vector into a pre-trained machine learning model to quantify it into a composite metric for representing architectural risk and impact score.

[0102] Multi-agent collaboration module: Generates single-step or multi-step execution plans based on composite metrics and current user intent, and assigns subtasks to at least one agent according to the execution order in the execution plan.

[0103] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Based on the technical essence of the present invention, any simple modifications, equivalent substitutions, and improvements made to the above embodiments within the spirit and principles of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A resource allocation method based on risk prediction and multi-agent cooperation, characterized in that, include: S1. When the interceptor receives a prediction request generated by capturing the current user intent, the orchestration engine is started. The process of generating the prediction request is as follows: while intercepting the user command, the interceptor encapsulates the user prompt obtained through the user command and the code context related to the user prompt into a prediction request. S2. The orchestration engine extracts multi-dimensional features from user prompts and their related code context, combines the multi-dimensional features into a single feature vector, and inputs the single feature vector into a pre-trained machine learning model to quantify it into a composite metric for representing architectural risk and impact scores. The multi-dimensional feature extraction includes the following steps: The code context related to user prompts is parsed into an abstract syntax tree in advance. Based on the abstract syntax tree, the syntactic and semantic information of the code context related to user prompts is captured, and code indicator features are obtained by analyzing the syntactic and semantic information of the code. Historical dynamic indicators are obtained by mining historical data warehouses in advance and analyzing historical volatility through code context related to user prompts. A technical debt quantification sub-model is obtained in advance, and the code context related to user prompts is quantified using the technical debt quantification sub-model to obtain quantitative indicators; Predefined task types are obtained in advance, semantic analysis is performed on user prompts, and the analysis results are matched with the predefined task types. The successfully matched task types are taken as the current user intent. Multidimensional features include indicator features, historical dynamic indicators, quantitative indicators, and current user intent; S3. Generate a single-step or multi-step execution plan based on the composite metrics and the current user intent, and assign subtasks to at least one agent according to the execution order in the execution plan.

2. The resource allocation method based on risk prediction and multi-agent cooperation according to claim 1, characterized in that, The user instructions refer to the instructions issued by the user through shortcut keys or command panels. Instructions include code generation, code refactoring, code explanation, or chat prompts to answer questions. These are then used as user prompts. At the same time, the relevant code context is collected, which includes the currently active file, the code block selected by the user's cursor, and multiple open files related to the current task.

3. The resource allocation method based on risk prediction and multi-agent cooperation according to claim 1, characterized in that, The code metrics include complexity metrics and object-oriented metrics. The complexity metrics are used to measure the code complexity in the code context related to user prompts. The object-oriented metrics are used to measure the impact of object-oriented aspects in the code context related to user prompts.

4. The resource allocation method based on risk prediction and multi-agent cooperation according to claim 1, characterized in that, The process of historical volatility analysis is as follows: find relevant historical records in the historical database through the code context related to user prompts, and obtain the corresponding historical dynamic indicators by analyzing the historical records. The historical dynamic indicators include code dropout rate, defect introduction history, user experience, and commit frequency.

5. The resource allocation method based on risk prediction and multi-agent cooperation according to claim 1, characterized in that, The process of quantifying the code context related to user prompts using the technical debt quantification sub-model is as follows: The technical debt quantification sub-model quantifies the code context related to user prompts based on factors such as code smells, lack of test coverage, and dependency aging, and obtains quantitative indicators presented in the form of scores; among them, code smells, lack of test coverage, and dependency aging are all used to represent the degree of risk generated when modifying code areas.

6. The resource allocation method based on risk prediction and multi-agent cooperation according to claim 1, characterized in that, The process of generating a single-step or multi-step execution plan based on composite metrics and current user intent is as follows: Obtain a pre-set strategy rule model, input the composite metrics, current user intent, and preset project configuration as inputs into the strategy rule model, and output a single-step or multi-step execution plan based on the priority of the current user intent being higher than the priority of the composite metrics set in the strategy rule model.

7. The resource allocation method based on risk prediction and multi-agent cooperation according to claim 1, characterized in that, The intelligent agent is an independent logical unit that encapsulates one or more AI models or tools. Each intelligent agent is responsible for different sub-tasks. The corresponding intelligent agent is selected according to the sub-task in the execution plan, and the corresponding intelligent agents are configured for the sub-tasks in the order of execution.

8. A resource allocation system based on risk prediction and multi-agent collaboration, characterized in that, The resource allocation method based on risk prediction and multi-agent cooperation as described in any one of claims 1-7 includes: Interception module: When the interceptor receives a prediction request generated by capturing the current user intent, it starts the orchestration engine; the generation process of the prediction request is as follows: while intercepting the user command, the interceptor encapsulates the user prompt obtained through the user command and the code context related to the user prompt into a prediction request; Risk prediction module: The orchestration engine extracts multi-dimensional features from user prompts and their related code context, combines the multi-dimensional features into a single feature vector, and inputs the single feature vector into a pre-trained machine learning model to quantify it into a composite metric for representing architectural risk and impact score. Multi-agent collaboration module: Generates single-step or multi-step execution plans based on composite metrics and current user intent, and assigns subtasks to at least one agent according to the execution order in the execution plan.

Images