Multi-agent confrontation generation method and system based on generative large language model

Abstract

The invention discloses a multi-agent confrontation generation method and system based on a generative large language model. The invention relates to the technical field of artificial intelligence. A heterogeneous agent model is initialized, and agent units of different roles are defined as agents (development engineer agents, product manager agents and QA role agents) of an LLM model. A basic operation unit of the heterogeneous agent model is called as an agent unit. In the technical scheme, the agent unit A is equivalent to an agent. According to the method, the roles and responsibilities of all agents are defined, and the reasonable state transition rules are set, so that the software development process is more orderly and efficient. The information sharing and cooperation mechanism between agents reduces the communication cost and waiting time, and accelerates the project progress; according to the method, the optimization problem is set, so that a development engineer agent can reasonably disassemble and generate code sub-modules according to task requirements and resource conditions, and optimal configuration of resources is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of artificial intelligence, specifically to code generation and development based on the LLM model, and particularly to a multi-agent adversarial generation method and system based on a generative large language model. Background Art

[0002] With the rapid development of artificial intelligence technology, large model applications have emerged increasingly, providing a strong basic support for the construction of intelligent agents. Among them, the intelligent agent technology constructed with the Large Language Model (LLM) as the core has been widely applied and promoted in many fields due to its powerful language understanding, generation, and inductive summary capabilities.

[0003] As a system entity with autonomous decision-making and interaction capabilities, the core competitiveness of an intelligent agent lies in how to efficiently integrate and utilize the various functions of the LLM. An intelligent agent can not only make full use of the inductive summary ability of the LLM to quickly refine and integrate massive information, but also achieve effective interaction with the external environment through built-in or external tool plugins. These tool plugins cover multiple aspects such as data processing, information retrieval, and automated operations, enabling the intelligent agent to complete a series of complex and diverse tasks. In the current intelligent agent technology framework, the single-agent scenario dominates. The core of a single agent lies in how to achieve seamless cooperation between the LLM and tool plugins, and how to conduct multiple efficient interactions with users during task processing. During task execution, a single agent needs to autonomously decide when to use which tool plugin, and dynamically adjust strategies according to the task progress and user feedback until it determines that the task is completed. This autonomous decision-making and interaction ability enable single agents to demonstrate strong application potential in many fields.

[0004] However, a complete software development process usually involves multiple roles, including product managers, engineers, and Office Automation (OA) personnel, etc. These roles each undertake different responsibilities and tasks during the software development process and need to cooperate with each other to jointly promote the smooth progress of the project. However, traditional single agents are difficult to cope with such a complex software development process due to the lack of multi-role collaboration and interaction capabilities. Therefore, the present invention proposes a multi-agent adversarial generation method and system based on a generative large language model. Summary of the Invention

[0005] In view of this, the present invention aims to provide a multi-agent adversarial generation method and system based on a generative large language model to solve or alleviate the technical problems existing in the prior art, that is, to achieve effective interaction and collaboration among multiple agents (agents) in the software development process and complete the entire process from requirements analysis to code generation and testing; the technical solution of the present invention is implemented as follows:

[0006] In the first aspect, a multi-agent adversarial generation method based on a generative large language model:

[0007] (I) Overview:

[0008] The present invention aims to optimize the interaction and collaboration of agents in the software development process by constructing a heterogeneous agent model. By defining agents with different roles, each agent is responsible for different links in the software development process. By setting the states (revenue state and non-revenue state) of the agents and the state transition rules, the dynamic behavior of the agents in the software development process is simulated. At the same time, an optimization problem is set for the engineer agent, that is, given a prototype document, how to disassemble and generate the optimal number of code sub-modules, and the characteristics of revenue and the dynamic vector of assets are considered. Finally, through the test task allocation and optimization mechanism of the QA role agent, the quality of software development is ensured.

[0009] (II) Technical solution:

[0010] To achieve the above technical objectives, the present invention selects to perform the following operating steps.

[0011] 2.1 Step S1, initialize the heterogeneous agent model:

[0012] Initialize the heterogeneous agent model, and define agent units with different roles as agents of the LLM model (development engineer agent, product manager agent, QA role agent).

[0013] 2.1.1 Step S100, initialize the agent unit:

[0014] The basic operating unit of the heterogeneous agent model is called an "agent unit". In this technical solution, the agent unit A is equivalent to an agent; each agent A i is equivalent to a different agent. For example:

[0015] Development engineer agent A1: The role objective is to decompose the modules through the product prototype document output by the product and complete the functions of each module.

[0016] Product manager agent A2 for development: The role objective is to refine the user's requirements into an executable product prototype document.

[0017] Define the QA role agent A3: The role goal is to generate test cases based on the prototype document of the product manager agent A2.

[0018] 2.1.2 Step S101, Initialize the running state:

[0019] For each agent unit A i it should include two states:

[0020]

[0021] When an agent unit is in state A i0 it means it is performing a generation task based on the generative large language model. To conform to the traditional terminology form of the heterogeneous agent model, in this technology it is called the "revenue state"; and when an agent unit is in state A i1 it means it is on standby, and in this technology it is called the "non-revenue state".

[0022] 2.2 Step S2, Brainstorming stage:

[0023] When the user interacts with the development product manager agent A2 based on the interaction interface or page provided by the generative large language model, the development product manager agent A2 diverges the user's product development requirements and records them as a prototype document; until the user requirement communication is completed, the development product manager agent A2 conveys the prototype document to the engineer agent A1.

[0024] 2.3 Step S3, Code generation and its optimization problem setting:

[0025] The utility (input) of the engineer agent A1 follows the expected discounted utility rule, considering the future revenue value (the number of code sub-module splits). Construct a state transition matrix according to the state densities λ1 and λ2, and calculate the steady-state distribution. Given the revenue and interest rate, calculate the asset dynamic vector of the engineer agent A1. The expected revenue of the engineer agent A1 consists of the average value of the sum of each business order and the specific productivity.

[0026] 2.3.1 Step S300, Optimization problem setting:

[0027] The optimization problem faced by engineer agent A1 is how to disassemble and generate code sub - modules according to the prototype document. For engineer agent A1, in the optimization problem, there exists a continuous infinite number of agent units A; according to the theory of the heterogeneous agent model (reference: "Salamon, Tomas (2011). Design of Agent - Based Models: Developing Computer Simulations for a Better Understanding of Social Processes. Bruckner Publishing. ISBN 978 - 80 - 904661 - 1 - 1"), the corresponding assets (the current prototype document) and income (the code sub - modules that can be disassembled and generated based on the current prototype document) are a and y respectively. The utility (i.e., input) of engineer agent A1 follows the standard expected discounted utility rule, and its future expected discounted utility E0 is:

[0028]

[0029] where e is the natural constant, t is the time step, ρ is the time discount rate and ρ≥0, and the utility function u is a strictly concave function; C t refers to the "revenue value" of agent unit A1 when generating task t in each round

[0030] (i.e., the number of disassembled code sub - modules), and it is only considered when C t is greater than or equal to 0.

[0031] 2.3.2 Step S301, calculate the income characteristics:

[0032] The utility (input) of engineer agent A1 follows the expected discounted utility rule, considering the future revenue value (the number of disassembled code sub - modules).

[0033] The literature "Huggett M. The Risk - free Rate in Heterogeneous - agent Incomplete insurance Economies[J]. Journal of Economic Dynamics and Control, 1993, 17(5)" points out that the income y of engineer agent A1 t has a characteristic that it follows an exogenous two - state Poisson process. Then for this technical solution, the following constraints are introduced:

[0034]

[0035] Among them, y1 and y2 are two different levels of income observed in these two-state Poisson processes. The former is the lower input state, and the latter is the higher input state.

[0036] Since this is a two-state process, the observable output is income y t , and the hidden states are "non-revenue state" and "revenue state"; if the model is currently in the state associated with y1, then the observed income is y1; conversely, if the model is currently in the state associated with y2, then the observed income is y2. Furthermore, the state densities of the two states are λ1 and λ2 respectively, that is, the probability of the process transitioning from one state to another is λ1. Correspondingly, the probability of transitioning from the above-mentioned other state to the above-mentioned one state is λ2. Therefore. Based on this, a state transition matrix Π can be obtained as:

[0037]

[0038] Therefore, the steady-state distribution π* of the income of engineer agent A1 is:

[0039]

[0040] Among them, u* and e* are the non-revenue rate (uncoded sub-module) and revenue rate (coded sub-module) of the steady state of engineer agent A1 respectively;

[0041] 2.3.3 Step S302, calculate the expected income:

[0042] Introduce the calculation factor of the "expression form of personal wealth" of the agent model given in the literature "Aiyagari S R. Uninsured Idiosyncratic Risk and Aggregate Saving [J]. The Quarterly Journal of Economics, 1994, 109(3)", that is, the so-called "non-productive bonds with fixed supply"; when we regard the so-called "bonds" as asset a, given income and interest rate r t (calculated based on the non-revenue rate and revenue rate mentioned above), the asset dynamic vector of engineer agent A1 is abstractly expressed as:

[0043] Among them, a t is the "turnover" of engineer agent A1 (generation of coded sub-module), which is continuously updated starting from time step t0.

[0044] After the above information is clarified, the engineer agent A1 can be made to perform the work and generate code; where the expected income y of the engineer agent A1 Ai is composed of the average value w of the sum of each business order ti and the specific productivity z ti ; At the same time, the turnover a of the engineer agent A1 t needs to consider the existence of a "borrowing constraint factor a ci " to avoid solution chaos (see the previous literature for details), that is: -∞ < a ci ≤ 0;

[0045] That is, clarify the relationship formula of the expected income y of the engineer agent A1 Ai as:

[0047] At this time, it is possible to normally guide the engineer agent A1 to generate a reasonable number of code sub-modules expected by it based on the expected income y Ai .

[0048] 2.4 Step S4, development stage and testing stage:

[0049] For the QA role agent A3, the core is to allocate more business test intentions to the QA role agent A3, that is, the optimization problem of the model can be clarified as: given the asset dynamic vector of the engineer agent A1 and the expected income y Ai (under the constraint conditions), call the test tool to optimize (predict) the future expected discounted utility E0 of the engineer agent A1 to reflect the unit test cases of different sub-modules:

[0050] When the future expected discounted utility E0 of the engineer agent A1 shows an abnormal trend in future profit growth and development (such as exceeding the preset threshold), it is regarded as a bad test result, then it is recorded and returned to the engineer agent A1 for the generation task or handed over to manual processing. On the contrary, if the future expected discounted utility E0 of a certain engineer agent A1 shows an abnormal decreasing trend in future profit development (such as exceeding the preset threshold), it is regarded as a good test result.

[0051] (III) Mechanism for solving technical problems:

[0052] 3.1 Heterogeneous agent model construction:

[0053] Each agent represents a role in the software development process, such as a development engineer, a product manager, and a QA personnel. These agents have different attributes and behavior rules, and can simulate their actual behaviors in software development. Each agent is set with two states: revenue state and non-revenue state. In the revenue state, the agent is performing generation tasks, such as a development engineer writing code, a product manager refining requirements, etc.; in the non-revenue state, the agent is in a standby or preparation stage. Through the state transition rules, the agent can flexibly switch states according to the current environment and task requirements, realizing dynamic interaction and collaboration.

[0054] 3.2 Optimization Problem Setting and Solving:

[0055] For the development engineer agent, an optimization problem is set, that is, given a prototype document, how to disassemble and generate the optimal number of code sub-modules. By considering revenue (the value of code sub-modules) and cost (the time and effort of writing code), the engineer agent can make the most reasonable decision. In this process, the expected discounted utility rule is introduced to evaluate future benefits and ensure long-term optimization.

[0056] 3.3 Testing and Optimization Mechanism:

[0057] The QA role agent is responsible for task assignment and optimization in the testing phase. By invoking testing tools, the code generated by the engineer agent is verified to ensure software quality. At the same time, according to the feedback of the test results, the behavior of the engineer agent is adjusted and optimized to achieve continuous improvement.

[0058] 3.4 Agent Interaction and Collaboration:

[0059] In the entire software development process, effective interaction is achieved among agents through information sharing and collaboration mechanisms. For example, the product manager agent passes the refined requirement document to the development engineer agent, and the development engineer agent writes code according to the requirements and passes the results to the QA role agent for testing. This agent-based interaction and collaboration model can significantly improve the efficiency and quality of software development.

[0060] Second, a multi-agent adversarial generation system based on a generative large language model:

[0061] Such as Figure 2 As shown, this system is used to implement the multi-agent adversarial generation method based on the generative large language model described above, and it includes:

[0062] (1) Presentation layer (or user interface layer): Responsible for interacting with users, receiving user requirements and instructions, and displaying software operation results. It includes a development product manager agent responsible for generating product prototype documents;

[0063] (2) Business Logic Layer: Implements the core business logic of the software, processes data, performs calculations, and makes decisions. It includes engineer agents responsible for writing code and generating software modules. It is the core part of software development and closely collaborates with the Data Access Layer;

[0064] (3) Data Access Layer: Responsible for data reading and writing operations, and interacts with databases or other data storage systems. It is implemented by agents (development engineers) in the Business Logic Layer through API calls. It provides data support for the Business Logic Layer to ensure data accuracy and integrity.

[0065] (4) Testing and Optimization Layer: Responsible for software testing, verification, and optimization to ensure software quality. It includes QA role agents responsible for task assignment and execution of testing, and feedback of test results and optimization suggestions. It runs through the entire software development process to ensure that the software meets high-quality standards before release.

[0066] Compared with the prior art, the beneficial effects of the present invention are:

[0067] I. Improve development efficiency: By clarifying the roles and responsibilities of each agent and setting reasonable state transition rules, the present invention makes the software development process more orderly and efficient. The information sharing and collaboration mechanism among agents reduces communication costs and waiting time, and speeds up the project progress.

[0068] II. Optimize resource allocation: The setting of the optimization problem in the present invention enables development engineer agents to reasonably disassemble and generate code sub-modules according to task requirements and resource conditions, achieving optimal allocation of resources. By considering revenue and cost factors, long-term project benefits and sustainability are ensured.

[0069] III. Enhance software quality: The introduction of QA role agents and the implementation of the testing and optimization mechanism in the present invention comprehensively verify and test the software, ensuring software quality and stability. The feedback of test results and the adjustment mechanism of agent behavior achieve continuous improvement and quality enhancement.

[0070] IV. Enhance flexibility and scalability: The construction of the heterogeneous agent model in the present invention enables the solution to adapt to software development projects of different scales and complexities. By adding or modifying the attributes and behavior rules of agents, the functions and application scopes of the solution can be easily extended. Description of the Drawings

[0071] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0072] Figure 1 It is a schematic flowchart of the method of the present invention;

[0073] Figure 2 It is a schematic diagram of the system composition of the present invention;

[0074] Figure 3 It is a schematic flowchart of step S1 of the present invention;

[0075] Figure 4 It is a schematic flowchart of step S3 of the present invention;

[0076] Figure 5 It is a schematic flowchart of step S4 of the present invention;

[0077] Figure 6 It is a schematic diagram of multi-agent interaction of the present invention. Detailed implementation manners

[0078] To make the above objects, features, and advantages of the present invention more obvious and understandable, the following will make a detailed description of the specific implementation manners of the present invention in conjunction with the drawings. Many specific details are set forth in the following description in order to fully understand the present invention. However, the present invention can be implemented in many other ways different from those described herein. Those skilled in the art can make similar improvements without departing from the connotation of the present invention. Therefore, the present invention is not limited by the specific embodiments disclosed below;

[0079] It should be noted that the embodiments in this specification are described in a progressive manner, and the key points of each embodiment are the differences from other embodiments. The same or similar parts among the embodiments can be referred to each other. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method part.

[0080] Explanation of related terms:

[0081] (1) Revenue status (Ai0): It refers to the status where the agent is performing a generation task (such as writing code), and in this status, the agent generates income or value.

[0082] (2) Non-revenue status (Ai1): It refers to the status where the agent is in a standby or preparation stage, and in this status, the agent does not directly generate income.

[0083] (3) Optimization problem: This is the task faced by the agent of the development engineer, that is, under given conditions, how to break down and generate the optimal number of code sub-modules to maximize the overall benefit.

[0084] (4) Utility function: It is used to evaluate the benefits or satisfaction of the agent in different states and guide the agent to make optimal decisions.

[0085] (5) Income characteristics: Describe the value attributes of code sub-modules or tasks, which affect the agent's decision-making and income distribution.

[0086] (6) State transition matrix: Define the probability or rule for the agent to transfer from one state to another state to achieve dynamic interaction.

[0087] (7) Asset dynamic vector: Represents the state of the agent's assets (such as code volume, skill level) changing over time, reflecting its growth and development.

[0088] (8) Bond: In this solution, it is analogized to the work obligations between agents.

[0089] (9) Expected income: The agent's estimate of the "income" that may be obtained in the future, which affects its current decision-making and behavior.

[0090] (10) Test task assignment: Refers to how the agent in the QA role reasonably assigns test tasks to ensure software quality and feedback optimization suggestions.

[0091] Example 1: As Figures 1 to 5 shown, this example discloses a multi-agent adversarial generation method for generative large language models:

[0092] In this example, regarding step S1: Initialize the heterogeneous agent model:

[0093] Step S100: Initialize the agent unit

[0094] Agent A1 of the development engineer: According to the prototype document provided by the product manager, decompose the module and complete the functional code writing for each module. A1 can parse the functional requirements in the document and generate the corresponding code framework and logical implementation.

[0095] Agent A2 of the product manager: Refine the user's requirements into an executable product prototype document. A2 collects requirements by interacting with the user and uses tools (such as Axure, Sketch) to draw prototype diagrams to form a detailed document.

[0096] Agent A3 in the QA role: Generate test cases according to the prototype document of the product manager.

[0097] A3 can automatically parse the prototype document, identify function points, and generate corresponding test scripts or test case documents.

[0098] Initialize the heterogeneous agent model, and define agent units with different roles as agents of the LLM model (development engineer agent, product manager agent, QA role agent).

[0099] For each agent unit A i it should include two states:

[0100]

[0101] When an agent unit is in state A i0 it means it is performing a generation task based on the generative large language model. To conform to the traditional terminology form of the heterogeneous agent model, it is called the "revenue state" in this technology; and when an agent unit is in state A i1 it means it is on standby, which is called the "non-revenue state" in this technology.

[0102] In this embodiment, regarding step S2, the brainstorming stage: When the user interacts with the development product manager agent A2 based on the interaction interface or page provided by the generative large language model, the development product manager agent A2 diverges the user's product development requirements and records them as a prototype document; until the user's requirement communication is completed, the development product manager agent A2 conveys the prototype document to the engineer agent A1.

[0103] In this embodiment, regarding step S3, code generation and its optimization problem setting: The utility (input) of the engineer agent A1 follows the expected discounted utility rule, considering the future revenue value (the number of code sub-module splits). Construct a state transition matrix according to the state densities λ1 and λ2, and calculate the steady-state distribution. Given the income and interest rate, calculate the asset dynamic vector of the engineer agent A1. The expected income of the engineer agent A1 consists of the average value of the sum of each business order and the specific productivity.

[0104] Specifically, in step S300, the optimization problem setting: A1 needs to disassemble and generate code sub-modules according to the prototype document. The utility (input) of A1 follows the expected discounted utility rule, considering the future revenue value (i.e., the number of code sub-module splits). Constructed according to the state densities λ1 and λ2, it is used to calculate the steady-state distribution, reflecting the transition probability of A1 between different states (revenue and non-revenue).

[0105]

[0106] where e is the natural constant, t is the time step, ρ is the time discount rate and ρ ≥ 0, and the utility function u is a strictly concave function; Ct Refers to the "revenue value" when the agent unit A1 generates a task t in each round

[0107] (i.e., the number of splits of the code sub-module), and is only taken into account when C t is greater than or equal to 0.

[0108] Specifically, in step S301, calculate the revenue characteristics: The revenue y_t of A1 follows an exogenous two-state Poisson process, where λ1 and λ2 respectively represent the transition probabilities from the non-revenue state to the revenue state and from the revenue state to the non-revenue state. Then calculate the steady-state distribution π* of A1's revenue, which is used to reflect the proportions of A1 in the revenue state and non-revenue state in the long term:

[0109]

[0110] Among them, y1 and y2 are two different levels of revenue observed in this two-state Poisson process. The former is the lower input state, and the latter is the higher input state.

[0111] Since this is a two-state process, the observable output is the revenue y t , and the hidden states are the "non-revenue state" and the "revenue state"; if the model is currently in the state associated with y1, then the observed revenue is y1; conversely, if the model is currently in the state associated with y2, then the observed revenue is y2. Furthermore, the state densities of the two states are λ1 and λ2 respectively, that is, the probability of the process transferring from one state to another is λ1, and correspondingly, the probability of transferring from the above-mentioned other state to the above-mentioned one state is λ2. Therefore. Based on this, a state transition matrix Π can be obtained as:

[0112]

[0113] Therefore, the steady-state distribution π* of the revenue of the engineer agent A1 is:

[0114]

[0115] Among them, u* and e* are respectively the steady-state non-revenue rate (un-generated code sub-module) and revenue rate (generated code sub-module) of the engineer agent A1;

[0116] Specifically, in step S302, calculate the expected revenue: The asset dynamic vector of the engineer agent A1 is abstractly expressed as:

[0117] where a t is the "turnover" of the engineer agent A1 (generation of code sub-modules), which is continuously updated starting from time step t0.

[0118] After the above information is clarified, the engineer agent A1 can be made to perform the work and generate code; among them, the expected income y of the engineer agent A1 Ai is composed of the average value w of the sum of each business order ti and the specific productivity z ti ; at the same time, the turnover a of the engineer agent A1 t needs to consider the existence of a "borrowing constraint factor a ci " to avoid solution chaos, that is: -∞ < a ci ≤ 0;

[0119] That is, to clarify the relationship formula of the expected income y of the engineer agent A1 Ai is:

[0121] At this time, it is possible to normally guide the engineer agent A1 to generate a reasonable number of code sub-modules expected by it based on the expected income y Ai

[0122] In this embodiment, regarding step S4, the development stage and the testing stage: for the QA role agent A3, the core is to allocate more business test intents to the QA role agent A3, that is, the optimization problem of the model can be clarified as: under the constraint conditions of the given engineer agent A1 asset dynamic vector and the expected income y Ai ((constraint conditions)), call the test tool to optimize (predict) the future expected discounted utility E0 of the engineer agent A1 to reflect the unit test cases of different sub-modules:

[0123]

[0124] When the future expected discounted utility E0 of the engineer agent A1 shows an abnormal trend in future profit growth and development (such as exceeding the preset threshold), it is regarded as a bad test result, then it is recorded and returned to the engineer agent A1 for the generation task or handed over to manual processing. On the contrary, if the future expected discounted utility E0 of a certain engineer agent A1 shows an abnormal decreasing trend in future profit development (such as exceeding the preset threshold), it is regarded as an excellent test result.

[0125] In this embodiment, as Figure 6 shown, regarding multi-agent interaction:

[0126] (1) Interaction between A2 and the user: Ensure accurate collection of requirements and provide a solid foundation for subsequent development.

[0127] ​(2)Interaction between A2 and A1: By passing requirements through the prototype document, A1 can clearly understand the development tasks.

[0128] (3)Interaction between A1 and A3: The code generated by A1 is tested by A3 to ensure code quality.

[0129] Multiple agents work in parallel, reducing waiting time and accelerating the development cycle. The automated testing of A3 ensures code quality and reduces human errors. Through state transition and expected revenue calculation, A1 can dynamically adjust the development strategy to adapt to demand changes.

[0130] Embodiment 2: On the basis of Embodiment 1, the MATLAB execution program of the solution described in Embodiment 1 is further provided as follows:

[0131] % Step S1: Initialize the heterogeneous agent model

[0132] % Initialize the agent unit

[0133] A1 = struct('role', 'development engineer','state', 0, 'utility', 0, 'codeModules', []);

[0134] A2 = struct('role', 'product manager','state', 0, 'prototypeDoc', ");

[0135] A3 = struct('role', 'QA role','state', 0, 'testCases', []);

[0136] % Agent state description: 0 - non-revenue state, 1 - revenue state

[0137] % Step S2: Brainstorming stage

[0138] A2.prototypeDoc = 'the content of the prototype document of user requirements';

[0139] % A2 transmits the prototype document to A1

[0140] disp(['Product manager A2 conveys the prototype document to development engineer A1:', A2.prototypeDoc]);

[0141] % Step S3: Code generation and its optimization problem setting

[0142] % Parameter setting

[0143] rho = 0.95; % Time discount rate

[0144] lambda1 = 0.3; % Transition probability from non - revenue to revenue

[0145] lambda2 = 0.7; % Transition probability from revenue to non - revenue

[0146] y1 = 2; % Revenue in non - revenue state

[0147] y2 = 5; % Revenue in revenue state

[0148] % State transition matrix

[0149] Pi = [1 - lambda1, lambda1; lambda2, 1 - lambda2];

[0150] % Calculate the steady - state distribution

[0151] % Use linear algebra method to solve π * Pi = π and π * [1, 1]' = 1

[0152] I = eye(2);

[0153] A = [Pi(1, 1) - 1, Pi(1, 2); Pi(2, 1), Pi(2, 2) - 1];

[0154] b = [0; 1]; % Since π is a probability distribution, π2 (the second element of π) can be obtained by 1 - π1

[0155]

[0156] disp('Test result: Poor, re - return to A1 or manual processing');

[0157] else

[0158] disp('Test result: Excellent');

[0159] end

[0160] All of the above embodiments only express the implementation manners of the relevant practical applications of the present invention. Their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several deformations and improvements can still be made, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the invention patent should be subject to the appended claims.

[0161] For those skilled in the art, it can be further realized that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of the present invention.

[0162] At the same time, those skilled in the art can understand that all or part of the processes of implementing the methods of all the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, storage, database, or other medium provided in the present application and used in the embodiments can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

Claims

1. A multi-agent adversarial generation method based on a generative large language model, characterized in that: include: S1, initialize the heterogeneous agent model and define agent units with different roles as the intelligent agents of the LLM model; S2, when the user interacts with the development product manager agent A2, it is recorded as a prototype document; S3, makes the utility of engineer agent A1 follow the expected discounted utility rule, considers the future revenue value and constructs the state transfer matrix according to the state density λ1 and λ2, and calculates the steady-state distribution; given the income and interest rate, calculates the asset dynamic vector of engineer agent A1; the expected income of engineer agent A1 consists of the average value of the sum of each business and the specific productivity; S4, given the engineer agent A1 asset dynamic vector and expected income y Ai Next, the test tool is called to optimize the future expected discounted utility E0 of the engineer agent A1 to reflect the unit test cases of different sub-modules.

2. The multi-agent confrontation generation method according to claim 1, characterized in that: The execution process of S1 includes: S100, each agent A i Equivalent to different agents, including: Development Engineer Agent A1: Decompose the modules through the product prototype document output by the product and complete the functions of each module; Development Product Manager Agent A2: Refine user requirements into executable product prototype documents; Define QA role agent A3: Generate test cases through the prototype document of product manager agent A2; S101, for each agent unit A i For:

3. The multi-agent confrontation generation method according to claim 1, characterized in that: In S2, when the user interacts with the development product manager agent A2 based on the interactive interface or page provided by the generative large language model, the development product manager agent A2 disseminates the user's product development requirements and records them as a prototype document; until the user requirements are communicated, the development product manager agent A2 conveys the prototype document to the engineer agent A1.

4. The multi-agent confrontation generation method according to claim 1, characterized in that: The implementation method of S3 includes: S300, optimization problem setting: the corresponding asset a is regarded as the current prototype document, and the income y is regarded as the code submodule that can be disassembled and generated based on the current prototype document; the utility of the engineer agent A1 follows the standard expected discounted utility rule, and its future expected discounted utility E0 is: Where e is a natural constant, t is the time step, ρ is the time discount rate and ρ ≥ 0, and the utility function u is a strictly concave function; C t It refers to the revenue value of agent unit A1 when it generates task t in each round; S301, calculation of income characteristics: The utility of engineer agent A1 follows the expected discounted utility rule, taking into account future revenue values, and obeying an exogenous two-state Poisson process, introducing the following constraints: Among them, y1 and y2 are two different levels of income observed in the two-state Poisson process, the former is a lower input state, and the latter is a higher input state.

5. The multi-agent confrontation generation method according to claim 4, characterized in that: In the S301, the state transfer matrix Π is obtained: The steady-state distribution π* of engineer agent A1’s income is: Among them, u* and e* are the steady-state unrevenue rate and revenue rate of engineer agent A1 respectively.

6. The multi-agent confrontation generation method according to claim 5, characterized in that: In S3, given the income and interest rate r t In the case of for: Among them, a t is the "turnover" of engineer agent A1. It is continuously updated starting from time step t0, which allows engineer agent A1 to perform work and generate code.

7. The multi-agent confrontation generation method according to claim 6, characterized in that: When generating code, the method to avoid solution confusion is: -∞＜a ci ≤0； Among them, a ci is the borrowing constraint factor; The expected income of engineer agent A1 is Ai The relationship is: Based on expected income y Ai To guide engineer agent A1 to generate a reasonable number of code sub-modules as expected.

8. The multi-agent confrontation generation method according to any one of claims 1 to 7, characterized in that: In S4, the method of reflecting the unit test cases of different submodules is: When the future expected discounted utility E0 of engineer agent A1 has an abnormal trend of future profit growth, it is regarded as a bad test result, which is recorded and returned to engineer agent A1 for task generation or manual processing; on the contrary, if the future expected discounted utility E0 of an engineer agent A1 has an abnormal trend of future profit decrease, it is regarded as an excellent test result.

9. A system for implementing the multi-agent confrontation generation method according to any one of claims 1 to 8, characterized in that: The system comprises: Presentation layer: responsible for interacting with users, receiving user requirements and instructions, and displaying software operation results; Business logic layer: implements the core business logic of the software, processes data, performs calculations and makes decisions; includes engineer agents who are responsible for writing code and generating software modules; Data access layer: responsible for data reading and writing operations, interacting with databases or other data storage systems; Testing and optimization layer: responsible for software testing, verification and optimization.

10. The system according to claim 9, characterized in that: The presentation layer includes developing a product manager agent; The business logic layer includes engineer agents; The data access layer includes a QA role agent.

Images