Agent cluster-based software automatic generation method and system

Abstract

The application discloses an Agent cluster-based software automatic generation method and system, and belongs to the technical field of software engineering. The method comprises the following steps: analyzing requirements to generate an executable constraint intermediate representation (ECIR); scheduling a coding Agent to generate code and a semantic signature containing a declaration type and an observation type; performing consistency verification based on the ECIR and the semantic signature before construction; generating a fault propagation graph when construction fails, calculating a minimum repair set and issuing a differential repair instruction; and executing local repair and monitoring the repair convergence state. The application uniformly constrains the baseline through the ECIR, moves the error discovery forward to the pre-compilation stage by using the semantic signature, realizes accurate local repair through the minimum repair set and the differential instruction, effectively avoids verified modules from being rewritten, solves the repair shock problem through convergence control, and significantly improves the stability and delivery quality of software automatic generation.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, specifically to a method and system for automatic software generation based on agent clusters. Background Technology

[0002] With the significant improvement in the natural language understanding and code generation capabilities of large-scale language models, the software engineering field is gradually exploring a shift from human-led agile development to intelligent automated development. Current technology has evolved from code completion by a single AI programming assistant to a multi-agent collaborative development model driven by structured software specifications. This type of solution parses structured requirements documents, breaks down complex tasks, and assigns them to coding agents with different specializations, simulating the division of labor and collaboration among front-end and back-end roles. Combined with continuous integration and automated testing processes, it has initially achieved automated delivery from requirements to a runnable application, providing a new technological path to improve software development efficiency.

[0003] Currently, existing technical solutions still have significant shortcomings in practical engineering implementation. First, their structured input mainly remains at the document level, failing to compile into unified executable constraint objects. This results in agents generating code based solely on textual understanding, making it difficult to maintain consistency on a unified semantic baseline. Issues such as cross-module interface conflicts and field drift often only surface during the compilation or testing phase, leading to delayed error detection and higher integration risks. Second, after build or test failures, existing solutions lack precise attribution and minimum repair scope solutions based on fault propagation relationships. They often rely on regenerating the entire module or patching extensively, easily causing verified modules to be rewritten and introducing new defects. Finally, due to the lack of effective control over dynamic behavior coverage and repair convergence, the system is prone to repeated modifications to the same location or state oscillations during multiple iterations, severely impacting the stability of the automated development process and the final delivery quality. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for automatically generating software based on agent clusters, so as to solve the problems mentioned in the background art.

[0005] To address the aforementioned technical problems, this invention provides an agent-based automated software generation method that ensures consistent requirement constraints across the generation, verification, attribution, and remediation stages. Furthermore, it enhances the controllability, interpretability, and stability of the entire automated development process through two-layer semantic signatures, boundary-constrained patching, and convergence control mechanisms. Specifically, it includes:

[0006] S100: Receive software requirements documents or structured software specifications, parse the input content, perform schema validity verification and constraint compilation, and generate an executable constraint intermediate representation (ECIR).

[0007] The ECIR generation process includes input completeness assessment and constraint determineability scoring.

[0008] When the input completeness score or constraint decisionability score is lower than the preset threshold, the verification agent review or manual confirmation mechanism is triggered.

[0009] ECIR's data structure includes a module unique identifier, interface definition, dependencies, runtime environment information, and an evidence_link field used for tracking associations.

[0010] ECIR also includes constraint objects with unique constraint identifiers, including at least interface contract constraints, state transition constraints, data structure constraints, permission boundary constraints, resource usage constraints, and acceptance criteria constraints.

[0011] S200: Based on ECIR, the overall development task is decomposed into multiple subtasks bound to a subset of constraints, and each subtask is assigned to different coding agents in the coding agent resource pool for execution.

[0012] S300 and each coded agent generate code based on the subtask description and associated constraints, perform self-tests, and output code packages and corresponding semantic signatures.

[0013] Semantic signatures include declarative semantic signatures generated through static analysis and observational semantic signatures generated through self-test execution trajectories.

[0014] S400. Before unified construction, the semantic signatures returned by each encoded Agent are compared item by item with the corresponding constraints in ECIR to perform pre-compilation consistency checks. If the check fails, a violation is marked and a repair task is generated.

[0015] Pre-compilation consistency checks should include at least one or more of the following comparisons:

[0016] The system checks for consistency in interface parameters, consistency in returned field names and types, compliance of state transition paths, consistency between data structure fields and naming rules, whether permission declarations exceed limits, whether resource access exceeds limits, detection of inter-module dependency version conflicts, and whether dynamic execution trajectories violate state rules.

[0017] A repair task refers to an instruction object generated during the automatic software generation process when the system detects that the code output does not meet the expected constraints or has malfunctioned. This object is used to guide a specific coding agent to make targeted corrections.

[0018] Repair tasks are primarily generated in the following two situations:

[0019] When pre-compilation consistency check fails:

[0020] When the consistency verification module finds that the semantic signature output by the encoded Agent conflicts with ECIR, the system will prevent the code from entering the build phase and generate a repair task.

[0021] When integration build or test fails:

[0022] When a unified build or automated test fails, the system analyzes the failure propagation, determines the minimum set of fixes, and then generates a fix task to send to the target Agent.

[0023] The repair task is used to address issues such as excessive repair scope and inadvertent rewriting of verified modules.

[0024] By carrying violation constraint markers, the agent understands the root cause of the error instead of blindly guessing. By carrying allow / prohibit modification boundaries, the agent is forced to perform local patch fixes, preventing the agent from arbitrarily modifying other normal code logic.

[0025] S500 performs unified build and automated testing on the verified code package. If the build or test fails, a fault propagation graph is generated based on the error log, call chain, module dependency relationship and violation constraint identifier.

[0026] S600: Calculates the minimum repair set based on the fault propagation graph, generates differential repair instructions containing allowed and prohibited modification boundaries, and sends them to the target coded Agent to perform patch repair.

[0027] The specific method for calculating the minimum repair set is as follows: Construct an optimization function with the objectives of minimizing repair costs and maximizing constraint correlation, and solve for the optimal set of repair nodes, as shown in the following formula:

[0028] ;

[0029] In the formula, This represents the minimum set of repairs obtained from the solution, which includes the modules, functions, or code snippets that need to be modified.

[0030] yes The abbreviation, usually with or Used together, that is or . Indicates "make the function When the minimum value is obtained The value of ".

[0031] This represents the entire set of nodes in the fault propagation graph, that is, the set of all nodes in the fault propagation graph, representing the entire range that the fault may affect.

[0032] This indicates the number of nodes in the current candidate repair set; This represents the total number of nodes in the fault propagation graph. The ratio of the two represents the repair coverage ratio.

[0033] The numerator is the size of the candidate set, and the denominator is the total number of nodes in the fault graph. The smaller this value, the smaller the scope of code involved in the fix, and the more it conforms to the principle of least intrusion.

[0034] Represents a node The regression risk coefficient is determined based on the historical repair success rate or code complexity of that node. If a node has complex logic or frequent errors in historical modifications, this value is higher, used to suppress the selection of high-risk areas.

[0035] This represents the set of currently associated violation constraint identifiers; This represents the candidate repair set.

[0036] Represents a node With violation of constraints The score represents the degree of correlation between nodes. A higher score indicates a node that directly causes a constraint violation. A negative sign for this term in the formula signifies a higher degree of correlation, a smaller overall objective function value, and a higher likelihood of selection.

[0037] , , These are weighting coefficients, used to balance the scope of repair, regression risk, and the correlation with constraints, and to adjust the priority of each indicator in decision-making.

[0038] The aim is to find an optimal scope of code fixes. As a multi-objective optimization function, it balances the "smallness" and "accuracy" of repair by minimizing the repair scope, minimizing regression risk, and maximizing constraint correlation.

[0039] This technology addresses the issue of excessively broad repair scope in current technologies. Through quantitative calculations, it precisely identifies the smallest code region that most needs modification and where the risk is manageable, enabling localized repair.

[0040] The process of generating differential repair instructions includes:

[0041] The set of AST nodes or code intervals that can be modified are determined based on the minimum repair set as the boundary of allowed modification.

[0042] Lock the verified modules or nodes to prevent modification of their boundaries.

[0043] When the patch generated by the target encoding agent reaches the boundary of prohibited modification, the patch is rejected and the repair task is regenerated.

[0044] S700: Re-execute semantic signature extraction, pre-compilation consistency verification, and integration verification on the repaired code until the acceptance criteria are met or the repair convergence control mechanism is triggered. The repair convergence control mechanism includes:

[0045] Monitor and repair cycles, count repeated violations and constraints, and repair oscillation states.

[0046] When the system is detected to be in a state of repairing oscillations, the upgrade strategy is triggered.

[0047] An upgrade strategy should include at least one of the following:

[0048] Expand the scope of observational semantic signature collection, improve the consistency verification level, switch to a higher-privilege repair agent, expand the scope of the minimum repair set solution, or enter the manual confirmation stage.

[0049] Repairing the oscillation state through the oscillation index The determination is made using the following formula:

[0050] ;

[0051] In the formula, This represents the oscillation index of the current recovery cycle. The higher the value, the more similar the current recovery state is to the historical state, and the greater the possibility of oscillation.

[0052] This indicates the total number of repair cycles within the historical observation window. Represents a set With sets Between Similarity coefficient is used to measure the degree of overlap between sets.

[0053] and Representing the current round and the number respectively A set of violation constraint identifiers from previous rounds. If the constraint causing the current error highly overlaps with the constraint causing an error in a previous round, it indicates that the problem has not been resolved and is recurring.

[0054] and Representing the current round and the number respectively The minimum set of fixes from previous iterations. If the currently modified code location highly overlaps with the location modified in a previous iteration, it indicates that the system is repeatedly modifying the same code.

[0055] and These are the weighting coefficients for similarity of violation constraints and similarity of repair range, respectively. They are used to distinguish the weights of "erroneous repetition" and "repetition of modified position" in the oscillation determination.

[0056] when When the preset oscillation threshold is exceeded, the system is determined to have entered an oscillation state.

[0057] The oscillation index formula is used to quantitatively assess whether the current repair process has fallen into a "vicious cycle" or "oscillation" state.

[0058] By calculating the similarity between the current repair scheme and historical repair schemes, it can be determined whether the system repeatedly jumps between several fixed error states or repair schemes.

[0059] This solves the problem of non-convergence in current technologies. Existing technologies lack quantitative detection of oscillation states, causing AI agents to repeatedly iterate and linger on the same abnormal problem.

[0060] The mathematical indicators provided by this formula allow the system to stop losses in a timely manner once fluctuations are detected, triggering manual intervention or strategy upgrades to avoid wasting computing power and system instability.

[0061] This invention also provides a software automatic generation system based on an agent cluster, comprising:

[0062] The Requirements Receiving and Constraint Compilation Module is used to receive software requirements documents or structured software specifications and compile them into an executable constraint intermediate representation (ECIR).

[0063] When the input is a structured software specification, the specification can be written in YAML, JSON Schema extension, XML Schema or other predefined machine-readable formats, and should include at least global metadata, a list of functional modules, unique module identifiers, interface definitions, dependencies, runtime environment information, non-functional requirements and acceptance criteria.

[0064] Instead of using this content merely as suggestive descriptions, it is further compiled into a unified intermediate representation of executable constraints.

[0065] When the input is a non-fully structured requirements document, the system prefers to first convert it into an intermediate structured draft, and then perform field completion, schema validation and constraint decidability assessment to reduce ambiguity caused by directly generating constraint objects from free text.

[0066] The task decomposition and scheduling module is used to decompose the overall development task based on ECIR and schedule the coding agent.

[0067] ECIR is used to carry and uniformly express information such as functional boundaries, interface agreements, dependencies, state rules, resource constraints, and acceptance criteria in software requirements, and is continuously referenced in subsequent task decomposition, generation, verification, attribution, and remediation processes.

[0068] ECIR is generated by the constraint compilation module based on the structured software specification and undergoes at least three processing stages: input parsing, schema validity verification, and constraint compilation.

[0069] When the input completeness score or constraint decidability score is lower than the preset threshold, the verification agent is triggered to review or the manual confirmation is required to prevent inaccurate constraints from entering the subsequent process.

[0070] ECIR should include at least the following fields:

[0071] constraint_id is a unique number used to identify a single constraint.

[0072] constraint_type is used to identify the constraint type.

[0073] module_id is used to identify the module associated with the constraint.

[0074] interface_spec is used to describe the interface contract.

[0075] dependency_spec is used to describe dependencies.

[0076] state_rule is used to describe the state transition rules.

[0077] data_schema_rule is used to describe data structure rules.

[0078] permission_scope is used to describe permission boundaries.

[0079] resource_limit is used to describe resource usage constraints.

[0080] The acceptance_rule is used to describe the acceptance criteria.

[0081] evidence_link is used to record the tracking associations between constraints and code, tests, and patches.

[0082] Among them, constraint_type includes at least interface contract constraints, state transition constraints, data structure constraints, permission boundary constraints, resource usage constraints, and acceptance judgment constraints.

[0083] ECIR differs from general formal specification languages; it is a specific intermediate object designed for coded agent interaction and automatic repair loops. In addition to the constraint body, it also contains associated fields for subsequent consistency verification, violation location, repair tracking, and acceptance mapping.

[0084] The coding agent resource pool contains multiple coding agents used to perform code generation, self-testing, and output code packages and semantic signatures.

[0085] After the constraints are compiled, the task decomposition and scheduling module decomposes the overall task into multiple independent subtasks based on the module nodes, dependencies and constraint distribution in ECIR.

[0086] Each subtask can correspond to a functional module or a local implementation unit within a module, but all are bound to a set of explicit constraints.

[0087] Subsequently, the system assigns each subtask to a different coding agent in the coding agent resource pool for execution.

[0088] Each subtask is bound to a subset of constraints in ECIR and must subsequently undergo unified consistency checks and boundary-constrained repair controls.

[0089] Each coded Agent, upon receiving a subtask, shall perform at least the following operations:

[0090] Generate code based on task description and associated constraints, perform partial self-tests, organize the output code package, and output the semantic signature corresponding to the generated code.

[0091] Semantic signatures include declarative semantic signatures and observational semantic signatures.

[0092] Declarative semantic signatures are generated by static analysis and include at least one or more of the following information:

[0093] Interface signature hash, return field digest, database schema digest, permission declaration, resource access declaration, and side effect declaration.

[0094] Observational semantic signatures are generated from self-test execution results or sandbox execution traces, and include at least one or more of the following information:

[0095] The actual set of API calls, state transition summary, side effect trajectory summary, resource access trajectory summary, exception triggering path summary, and actual dependency call trajectory summary.

[0096] By combining declarative semantic signatures with observational semantic signatures, both static structural information and dynamic execution behavior information can be covered simultaneously, thereby reducing the probability of missed detections caused by relying solely on static digests.

[0097] The consistency verification module is used to compare and verify the semantic signature with the ECIR before unified construction. It compares the semantic signature returned by each encoded agent with the corresponding constraints in the ECIR item by item.

[0098] The verification content includes, but is not limited to, the following types:

[0099] Are the interface parameters consistent? Are the returned field names and types consistent? Does the state transition path meet the preset constraints? Does the data structure conform to the agreed fields and naming rules? Does the permission declaration exceed the permission boundary constraints? Does the resource access exceed the resource usage constraints? Do the inter-module dependencies or version selections conflict with the dependency constraints? Does the dynamic execution trajectory violate the state rules or side effect boundaries?

[0100] If the semantic signature of a code package conflicts with ECIR, the code package will not be allowed to enter the subsequent unified build process. Instead, it will be marked as a violation and a corresponding repair task will be generated.

[0101] By intercepting a large number of cross-module issues before they enter the compilation stage, the number of subsequent system-level failures is reduced.

[0102] The integrated build and test module is used to perform unified builds and automated tests.

[0103] The system will only perform unified builds and automated tests after the relevant code packages have passed the pre-compilation consistency check.

[0104] The system assembles code modules according to the dependencies defined in ECIR and calls the corresponding build toolchain to complete a unified build.

[0105] Afterwards, the system automatically generates or retrieves test cases based on the acceptance criteria, executes integration tests and system tests, and verifies whether the functional, performance, and security requirements are met.

[0106] The fault handling and repair closed-loop module is used to generate a fault propagation graph, calculate the minimum repair set, generate differential repair instructions, and control the repair convergence process when the build or test fails.

[0107] When a unified build or automated test fails, the system initiates a fault propagation analysis process.

[0108] Fault propagation diagrams are used to describe the propagation path and scope of a fault between modules, interfaces, or code segments.

[0109] Construct a fault propagation graph based on the following input:

[0110] Build failure logs or test failure logs, API call chains or execution path information, module dependencies in ECIR, historical anomalies or edge conflict information recorded during the pre-compile consistency verification phase, and violation constraint identifiers associated with the current failure.

[0111] In a fault propagation graph, nodes can represent modules, functions, classes, interfaces, or code snippets, while edges represent calls, dependencies, data flows, or constraint relationships.

[0112] The fault propagation graph is not only based on the general dependency graph, but also introduces violation constraint identifiers, so that the attribution of repairs is focused not only on the program structure relationship, but also on the source of constraint violation.

[0113] Based on the fault propagation graph, the minimum repair set solving module further calculates the minimum set of objects that need to be repaired to eliminate the current fault. This set can be the minimum set of modules or the minimum scope of code changes.

[0114] Solve using one or more of the following criteria:

[0115] It has the fewest affected nodes, the smallest scope of code changes, the least disturbance to verified modules, the lowest regression risk, the highest historical repair success rate, and the highest correlation with current violation constraint indicators.

[0116] By introducing violation constraint identifiers and boundary constraints, the solution of the minimum repair set differs from simple program slicing or pure dependency analysis. Its goal is not only to find the possible error locations, but also to find the minimum range that is most suitable for implementing local repair under the current constraint context.

[0117] Differential repair instructions are generated based on the minimum repair set and sent to the target coded Agent.

[0118] Differential repair commands should include at least the following:

[0119] Violation constraint identifier, list of affected interfaces, allowed boundary modification, prohibited boundary modification, repair priority, and patch application verification rules.

[0120] Among them, the boundary can be modified through at least one or more of the following definitions: file path set, class identifier set, function identifier set, AST node identifier set, or code range set.

[0121] Prohibiting boundary modifications must be enforced through at least one or more of the following methods: patch filters, AST node locking, and post-modification hash verification.

[0122] The target encoding agent can only perform local patch generation on code snippets related to violation constraints within the allowed modification boundaries, and must not modify prohibited areas beyond the boundaries.

[0123] When the patch generated by the target coding agent exceeds the allowed modification boundary or reaches the prohibited modification boundary, the system refuses to apply the patch and regenerates the repair task or upgrades the repair level based on the boundary violation.

[0124] After the patch is returned, the system will re-execute semantic signature extraction, pre-compilation consistency verification, unified build and automated testing. If the acceptance criteria are still not met, the fault propagation analysis, minimum repair set solution and differential repair will be re-executed until the acceptance is passed.

[0125] To avoid system oscillations during multiple repair cycles, such as repeated repairs of the same violation constraint identifier or alternating rollbacks at multiple code locations, the system sets a maximum repair cycle threshold, a repeated violation constraint count threshold, and repair oscillation judgment conditions.

[0126] When multiple consecutive repair cycles hit the same violation constraint flag, or when the minimum repair set appears repeatedly within a preset number of cycles, the system determines that the current repair process has entered an oscillation state and triggers an upgrade strategy.

[0127] Upgrade strategies should include at least:

[0128] Expand the scope of observational semantic signature collection, improve the consistency verification level, switch to a higher-privilege repair agent, expand the solution range of the minimum repair set, and enter the manual confirmation stage.

[0129] Through this convergence control mechanism, the system can reduce local optima, infinite loops, and repeated retries, thereby improving the overall repair stability.

[0130] Compared with the prior art, the beneficial effects achieved by the present invention are:

[0131] Unified and executable requirements constraints: This invention elevates requirements from ordinary structured documents to an executable constraint intermediate representation, making constraints a unified intermediate object throughout the entire development, verification, and repair process. Compared to existing technologies that only use documents as prompts, this invention ensures that different coding agents work around the same constraint system when generating code, avoiding implicit cross-module conflicts caused by misunderstandings of the text, thereby maintaining consistency on a unified semantic baseline.

[0132] Shifting Error Detection Timing and Covering Dynamic Behavior: By jointly using declarative and observational semantic signatures, this invention enables consistency checks to be performed before unified construction, intercepting issues such as interface conflicts, field drift, and permission violations before the compilation phase. Compared to existing technologies that only detect problems during compilation or testing, this invention not only shifts error detection earlier but also overcomes the shortcomings of static analysis in covering runtime state transitions and side effect trajectories, reducing the probability of missing dynamic behavior issues.

[0133] Precise Scope and Boundary Control for Repairs: This invention determines the minimum repair set based on fault propagation graphs and violation constraint identifiers, precisely limiting the repair scope to the truly affected areas. This avoids invalid rewriting caused by whole-module regeneration or wide-range patches in existing technologies. Simultaneously, through a control mechanism that allows and prohibits boundary modification, it effectively protects verified modules from being modified in conjunction with other modules, reducing secondary defects and regression risks, making it more suitable for long-chain, multi-round automated iterative development.

[0134] Improved Convergence Control and Stability of the Repair Process: This invention introduces a repair convergence control mechanism. By monitoring repair rounds, repeated violation constraints, and oscillation states, it can identify and intervene in situations where the same problem is repeatedly repaired or multiple rounds of oscillation occur. Compared to existing technologies that lack convergence control, leading to local optima and infinite loops, this invention significantly improves the convergence efficiency, controllability, and final delivery quality of the automated development process by triggering an upgrade strategy. Attached Figure Description

[0135] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0136] Figure 1 This is a flowchart illustrating the software auto-generation method based on Agent clusters according to the present invention. Detailed Implementation

[0137] 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. 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.

[0138] Please see Figure 1 This invention provides an agent-based method for automated software generation, ensuring consistency of requirement constraints across the generation, verification, attribution, and remediation stages. Furthermore, it enhances the controllability, interpretability, and stability of the entire automated development process through two-layer semantic signatures, boundary-constrained patching, and convergence control mechanisms. Specifically, it includes:

[0139] S100: Receive software requirements documents or structured software specifications, parse the input content, perform schema validity verification and constraint compilation, and generate an executable constraint intermediate representation (ECIR).

[0140] ECIR refers to a unified constraint expression object that is machine-executable, verifiable, and traceable, compiled from the functional definitions, interface definitions, dependencies, state rules, resource constraints, and acceptance conditions in software requirements documents or structured software specifications.

[0141] The ECIR generation process includes input completeness assessment and constraint determineability scoring.

[0142] When the input completeness score or constraint decisionability score is lower than the preset threshold, the verification agent review or manual confirmation mechanism is triggered.

[0143] ECIR's data structure includes a module unique identifier, interface definition, dependencies, runtime environment information, and an evidence_link field used for tracking associations.

[0144] ECIR also includes constraint objects with unique constraint identifiers, including at least interface contract constraints, state transition constraints, data structure constraints, permission boundary constraints, resource usage constraints, and acceptance criteria constraints.

[0145] A unique constraint identifier is a unique number assigned to each constraint in ECIR, used to establish precise associations during task decomposition, code generation, violation location, fault attribution, and remediation.

[0146] S200: Based on ECIR, the overall development task is decomposed into multiple subtasks bound to a subset of constraints, and each subtask is assigned to different coding agents in the coding agent resource pool for execution.

[0147] S300 and each coded agent generate code based on the subtask description and associated constraints, perform self-tests, and output code packages and corresponding semantic signatures.

[0148] Semantic signatures include declarative semantic signatures generated through static analysis and observational semantic signatures generated through self-test execution trajectories.

[0149] Declarative semantic signatures refer to the structured representations extracted from the code package output by the coded Agent through static analysis, which are used to characterize interface features, data structure features, permission declaration features, resource access features, or side effect declaration features.

[0150] Observational semantic signatures are structured representations formed through self-test execution results, sandbox running trajectories, or instrumentation records, used to characterize the actual API calls, state transitions, side effect trajectories, and resource access trajectories of the code.

[0151] S400. Before unified construction, the semantic signatures returned by each encoded Agent are compared item by item with the corresponding constraints in ECIR to perform pre-compilation consistency checks. If the check fails, a violation is marked and a repair task is generated.

[0152] Pre-compile consistency verification refers to the process of verifying whether the results generated by multiple modules meet the constraints of interfaces, states, data, permissions, and resources by comparing semantic signatures with ECIR before unified construction.

[0153] The comparison should include at least one or more of the following:

[0154] The system checks for consistency in interface parameters, consistency in returned field names and types, compliance of state transition paths, consistency between data structure fields and naming rules, whether permission declarations exceed limits, whether resource access exceeds limits, detection of inter-module dependency version conflicts, and whether dynamic execution trajectories violate state rules.

[0155] A repair task refers to an instruction object generated during the automatic software generation process when the system detects that the code output does not meet the expected constraints or has malfunctioned. This object is used to guide a specific coding agent to make targeted corrections.

[0156] Repair tasks are primarily generated in the following two situations:

[0157] When pre-compilation consistency check fails:

[0158] When the consistency verification module finds a conflict between the semantic signature output by the coded Agent and the ECIR (Executable Constraint Intermediate Representation) (e.g., interface parameter mismatch, field name drift, permission out-of-bounds, etc.), the system will prevent the code from entering the build phase and generate a repair task.

[0159] When integration build or test fails:

[0160] When a unified build or automated test fails, the system analyzes the failure propagation, determines the minimum set of fixes, and then generates a fix task to send to the target Agent.

[0161] The repair task is used to address issues such as excessive repair scope and inadvertent rewriting of verified modules.

[0162] By carrying violation constraint markers, the agent understands the root cause of the error instead of blindly guessing. By carrying allow / prohibit modification boundaries, the agent is forced to perform local patch fixes, preventing the agent from arbitrarily modifying other normal code logic.

[0163] S500 performs unified build and automated testing on the verified code package. If the build or test fails, a fault propagation graph is generated based on the error log, call chain, module dependency relationship and violation constraint identifier.

[0164] A fault propagation graph is a graph structure object built based on error logs, call chains, module dependencies, and violation constraint identifiers to describe the path and scope of fault propagation.

[0165] S600: Calculates the minimum repair set based on the fault propagation graph, generates differential repair instructions containing allowed and prohibited modification boundaries, and sends them to the target coded Agent to perform patch repair.

[0166] The minimum fix set refers to the minimum set of modules or the minimum scope of code changes required to eliminate the fault in the current failure scenario.

[0167] The specific method for calculating the minimum repair set is as follows: Construct an optimization function with the objectives of minimizing repair costs and maximizing constraint correlation, and solve for the optimal set of repair nodes, as shown in the following formula:

[0168] ;

[0169] In the formula, This represents the minimum set of repairs obtained from the solution, which includes the modules, functions, or code snippets that need to be modified.

[0170] yes (Abbreviation for parameter / independent variable), usually with or Used together, that is or . Indicates "make the function When the minimum value is obtained The value of ".

[0171] This represents the entire set of nodes in the fault propagation graph, that is, the set of all nodes in the fault propagation graph, representing the entire range that the fault may affect.

[0172] This indicates the number of nodes in the current candidate repair set; This represents the total number of nodes in the fault propagation graph. The ratio of the two represents the repair coverage ratio.

[0173] The numerator is the size of the candidate set, and the denominator is the total number of nodes in the fault graph. The smaller this value, the smaller the scope of code involved in the fix, and the more it conforms to the principle of least intrusion.

[0174] Represents a node The regression risk coefficient is determined based on the historical repair success rate or code complexity of that node. If a node has complex logic or frequent errors in historical modifications, this value is higher, used to suppress the selection of high-risk areas.

[0175] This represents the set of currently associated violation constraint identifiers; This represents the candidate repair set.

[0176] Represents a node With violation of constraints The score represents the degree of correlation between nodes. A higher score indicates a node that directly causes a constraint violation. A negative sign for this term in the formula signifies a higher degree of correlation, a smaller overall objective function value, and a higher likelihood of selection.

[0177] , , These are weighting coefficients, used to balance the scope of repair, regression risk, and the correlation with constraints, and to adjust the priority of each indicator in decision-making.

[0178] The aim is to find an optimal scope of code fixes. As a multi-objective optimization function, it balances the "small" and "precise" aspects of the repair by minimizing the scope of the repair (reducing the amount of changes), minimizing the regression risk (avoiding the degradation of old functions), and maximizing the constraint correlation (accurately locating the source of the problem).

[0179] This technology addresses the issue of excessively broad repair scope in current technologies. Through quantitative calculations, it precisely identifies the smallest code region that most needs modification and where the risk is manageable, enabling localized repair.

[0180] Differential patching instructions are control instructions that only allow the target coding agent to generate local patches on code segments related to violation constraints within the allowed modification boundaries.

[0181] The process of generating differential repair instructions includes:

[0182] The set of AST nodes or code intervals that can be modified are determined based on the minimum repair set as the boundary of allowed modification.

[0183] Lock the verified modules or nodes to prevent modification of their boundaries.

[0184] When the patch generated by the target encoding agent reaches the boundary of prohibited modification, the patch is rejected and the repair task is regenerated.

[0185] Patch application verification rules refer to a set of execution rules used to verify whether a patch has made out-of-bounds modifications, touched prohibited areas, or corrupted stable area hashes.

[0186] S700: Re-execute semantic signature extraction, pre-compilation consistency verification, and integration verification on the repaired code until the acceptance criteria are met or the repair convergence control mechanism is triggered. The repair convergence control mechanism includes:

[0187] Monitor and repair cycles, count repeated violations and constraints, and repair oscillation states.

[0188] When the system is detected to be in a state of repairing oscillations, the upgrade strategy is triggered.

[0189] Repair oscillation refers to a state in which the system repeatedly attempts to repair the same violation constraint identifier or the same minimum repair set during multiple repair processes, but still fails to pass acceptance.

[0190] An upgrade strategy should include at least one of the following:

[0191] Expand the scope of observational semantic signature collection, improve the consistency verification level, switch to a higher-privilege repair agent, expand the scope of the minimum repair set solution, or enter the manual confirmation stage.

[0192] Repairing the oscillation state through the oscillation index The determination is made using the following formula:

[0193] ;

[0194] In the formula, This represents the oscillation index of the current recovery cycle. The higher the value, the more similar the current recovery state is to the historical state, and the greater the possibility of oscillation.

[0195] This indicates the total number of repair cycles within the historical observation window. Represents a set With sets Between Similarity coefficient is used to measure the degree of overlap between sets.

[0196] and Representing the current round and the number respectively A set of violation constraint identifiers from previous rounds. If the constraint causing the current error highly overlaps with the constraint causing an error in a previous round, it indicates that the problem has not been resolved and is recurring.

[0197] and Representing the current round and the number respectively The minimum set of fixes from previous iterations. If the currently modified code location highly overlaps with the location modified in a previous iteration, it indicates that the system is repeatedly modifying the same code.

[0198] and These are the weighting coefficients for similarity of violation constraints and similarity of repair range, respectively. They are used to distinguish the weights of "erroneous repetition" and "repetition of modified position" in the oscillation determination.

[0199] when When the preset oscillation threshold is exceeded, the system is determined to have entered an oscillation state.

[0200] The oscillation index formula is used to quantitatively assess whether the current repair process has fallen into a "vicious cycle" or "oscillation" state.

[0201] By calculating the similarity between the current repair scheme and historical repair schemes, it can be determined whether the system repeatedly jumps between several fixed error states or repair schemes.

[0202] This solves the problem of non-convergence in current technologies. Existing technologies lack quantitative detection of oscillation states, causing AI agents to repeatedly iterate and linger on the same abnormal problem.

[0203] Using the mathematical indicators provided by this formula, once an oscillation is detected ( If the load is too high, the system can stop the loss in time, triggering manual intervention or upgrade strategies to avoid wasting computing power and system instability.

[0204] This invention also provides a software automatic generation system based on an agent cluster, comprising:

[0205] The Requirements Receiving and Constraint Compilation Module is used to receive software requirements documents or structured software specifications and compile them into an executable constraint intermediate representation (ECIR).

[0206] When the input is a structured software specification, the specification can be written in YAML, JSON Schema extension, XML Schema or other predefined machine-readable formats, and should include at least global metadata, a list of functional modules, unique module identifiers, interface definitions, dependencies, runtime environment information, non-functional requirements and acceptance criteria.

[0207] Instead of using this content merely as suggestive descriptions, it is further compiled into a unified intermediate representation of executable constraints.

[0208] When the input is a non-fully structured requirements document, the system prefers to first convert it into an intermediate structured draft, and then perform field completion, schema validation and constraint decidability assessment to reduce ambiguity caused by directly generating constraint objects from free text.

[0209] The task decomposition and scheduling module is used to decompose the overall development task based on ECIR and schedule the coding agent.

[0210] ECIR is used to carry and uniformly express information such as functional boundaries, interface agreements, dependencies, state rules, resource constraints, and acceptance criteria in software requirements, and is continuously referenced in subsequent task decomposition, generation, verification, attribution, and remediation processes.

[0211] ECIR is generated by the constraint compilation module based on the structured software specification and undergoes at least three processing stages: input parsing, schema validity verification, and constraint compilation.

[0212] When the input completeness score or constraint decidability score is lower than the preset threshold, the verification agent is triggered to review or the manual confirmation is required to prevent inaccurate constraints from entering the subsequent process.

[0213] ECIR should include at least the following fields:

[0214] constraint_id is a unique number used to identify a single constraint.

[0215] constraint_type is used to identify the constraint type.

[0216] module_id is used to identify the module associated with the constraint.

[0217] interface_spec is used to describe the interface contract.

[0218] dependency_spec is used to describe dependencies.

[0219] state_rule is used to describe the state transition rules.

[0220] data_schema_rule is used to describe data structure rules.

[0221] permission_scope is used to describe permission boundaries.

[0222] resource_limit is used to describe resource usage constraints.

[0223] The acceptance_rule is used to describe the acceptance criteria.

[0224] evidence_link is used to record the tracking associations between constraints and code, tests, and patches.

[0225] Among them, constraint_type includes at least interface contract constraints, state transition constraints, data structure constraints, permission boundary constraints, resource usage constraints, and acceptance judgment constraints.

[0226] ECIR differs from general formal specification languages; it is a specific intermediate object designed for coded agent interaction and automatic repair loops. In addition to the constraint body, it also contains associated fields for subsequent consistency verification, violation location, repair tracking, and acceptance mapping.

[0227] The coding agent resource pool contains multiple coding agents used to perform code generation, self-testing, and output code packages and semantic signatures.

[0228] After the constraints are compiled, the task decomposition and scheduling module decomposes the overall task into multiple independent subtasks based on the module nodes, dependencies and constraint distribution in ECIR.

[0229] Each subtask can correspond to a functional module or a local implementation unit within a module, but all are bound to a set of explicit constraints.

[0230] Subsequently, the system assigns each subtask to a different coding agent in the coding agent resource pool for execution.

[0231] Each subtask is bound to a subset of constraints in ECIR and must subsequently undergo unified consistency checks and boundary-constrained repair controls.

[0232] Each coded Agent, upon receiving a subtask, shall perform at least the following operations:

[0233] Generate code based on task description and associated constraints, perform partial self-tests, organize the output code package, and output the semantic signature corresponding to the generated code.

[0234] Semantic signatures include declarative semantic signatures and observational semantic signatures.

[0235] Declarative semantic signatures are generated by static analysis and include at least one or more of the following information:

[0236] Interface signature hash, return field digest, database schema digest, permission declaration, resource access declaration, and side effect declaration.

[0237] Observational semantic signatures are generated from self-test execution results or sandbox execution traces, and include at least one or more of the following information:

[0238] The actual set of API calls, state transition summary, side effect trajectory summary, resource access trajectory summary, exception triggering path summary, and actual dependency call trajectory summary.

[0239] By combining declarative semantic signatures with observational semantic signatures, both static structural information and dynamic execution behavior information can be covered simultaneously, thereby reducing the probability of missed detections caused by relying solely on static digests.

[0240] The consistency verification module is used to compare and verify the semantic signature with the ECIR before unified construction. It compares the semantic signature returned by each encoded agent with the corresponding constraints in the ECIR item by item.

[0241] The verification content includes, but is not limited to, the following types:

[0242] Are the interface parameters consistent? Are the returned field names and types consistent? Does the state transition path meet the preset constraints? Does the data structure conform to the agreed fields and naming rules? Does the permission declaration exceed the permission boundary constraints? Does the resource access exceed the resource usage constraints? Do the inter-module dependencies or version selections conflict with the dependency constraints? Does the dynamic execution trajectory violate the state rules or side effect boundaries?

[0243] If the semantic signature of a code package conflicts with ECIR, the code package will not be allowed to enter the subsequent unified build process. Instead, it will be marked as a violation and a corresponding repair task will be generated.

[0244] By intercepting a large number of cross-module issues before they enter the compilation stage, the number of subsequent system-level failures is reduced.

[0245] The integrated build and test module is used to perform unified builds and automated tests.

[0246] The system will only perform unified builds and automated tests after the relevant code packages have passed the pre-compilation consistency check.

[0247] The system assembles code modules according to the dependencies defined in ECIR and calls the corresponding build toolchain to complete a unified build.

[0248] Afterwards, the system automatically generates or retrieves test cases based on the acceptance criteria, executes integration tests and system tests, and verifies whether the functional, performance, and security requirements are met.

[0249] The fault handling and repair closed-loop module is used to generate a fault propagation graph, calculate the minimum repair set, generate differential repair instructions, and control the repair convergence process when the build or test fails.

[0250] When a unified build or automated test fails, the system initiates a fault propagation analysis process.

[0251] Fault propagation diagrams are used to describe the propagation path and scope of a fault between modules, interfaces, or code segments.

[0252] Construct a fault propagation graph based on the following input:

[0253] Build failure logs or test failure logs, API call chains or execution path information, module dependencies in ECIR, historical anomalies or edge conflict information recorded during the pre-compile consistency verification phase, and violation constraint identifiers associated with the current failure.

[0254] In a fault propagation graph, nodes can represent modules, functions, classes, interfaces, or code snippets, while edges represent calls, dependencies, data flows, or constraint relationships.

[0255] The fault propagation graph is not only based on the general dependency graph, but also introduces violation constraint identifiers, so that the attribution of repairs is focused not only on the program structure relationship, but also on the source of constraint violation.

[0256] Based on the fault propagation graph, the minimum repair set solving module further calculates the minimum set of objects that need to be repaired to eliminate the current fault. This set can be the minimum set of modules or the minimum scope of code changes.

[0257] Solve using one or more of the following criteria:

[0258] It has the fewest affected nodes, the smallest scope of code changes, the least disturbance to verified modules, the lowest regression risk, the highest historical repair success rate, and the highest correlation with current violation constraint indicators.

[0259] By introducing violation constraint identifiers and boundary constraints, the solution of the minimum repair set differs from simple program slicing or pure dependency analysis. Its goal is not only to find the possible error locations, but also to find the minimum range that is most suitable for implementing local repair under the current constraint context.

[0260] Differential repair instructions are generated based on the minimum repair set and sent to the target coded Agent.

[0261] Differential repair commands should include at least the following:

[0262] Violation constraint identifier, list of affected interfaces, allowed boundary modification, prohibited boundary modification, repair priority, and patch application verification rules.

[0263] Among them, the boundary can be modified through at least one or more of the following definitions: file path set, class identifier set, function identifier set, AST node identifier set, or code range set.

[0264] Prohibiting boundary modifications must be enforced through at least one or more of the following methods: patch filters, AST node locking, and post-modification hash verification.

[0265] The target encoding agent can only perform local patch generation on code snippets related to violation constraints within the allowed modification boundaries, and must not modify prohibited areas beyond the boundaries.

[0266] When the patch generated by the target coding agent exceeds the allowed modification boundary or reaches the prohibited modification boundary, the system refuses to apply the patch and regenerates the repair task or upgrades the repair level based on the boundary violation.

[0267] After the patch is returned, the system will re-execute semantic signature extraction, pre-compilation consistency verification, unified build and automated testing. If the acceptance criteria are still not met, the fault propagation analysis, minimum repair set solution and differential repair will be re-executed until the acceptance is passed.

[0268] To avoid system oscillations during multiple repair cycles, such as repeated repairs of the same violation constraint identifier or alternating rollbacks at multiple code locations, the system sets a maximum repair cycle threshold, a repeated violation constraint count threshold, and repair oscillation judgment conditions.

[0269] When multiple consecutive repair cycles hit the same violation constraint flag, or when the minimum repair set appears repeatedly within a preset number of cycles, the system determines that the current repair process has entered an oscillation state and triggers an upgrade strategy.

[0270] Upgrade strategies should include at least:

[0271] Expand the scope of observational semantic signature collection, improve the consistency verification level, switch to a higher-privilege repair agent, expand the solution range of the minimum repair set, and enter the manual confirmation stage.

[0272] Through this convergence control mechanism, the system can reduce local optima, infinite loops, and repeated retries, thereby improving the overall repair stability.

[0273] Example 1: Taking a task management application called TodoApp as an example, the implementation of the present invention will be described.

[0274] Users first write a structured software specification document according to a predefined template, which defines three functional modules: "user authentication", "task creation" and "task list display", and provides their interfaces, dependencies, operating environment and acceptance criteria.

[0275] During the input evaluation phase, the system checks whether the structured software specification fully includes necessary fields such as interface definitions, permission boundaries, state transition rules, and acceptance criteria.

[0276] If any permission boundary fields or state transition fields are found to be missing, the system returns a list of missing items for completion. If, although the missing items have been completed, some fields remain ambiguous, the verification agent generates candidate constraints and requires manual confirmation before proceeding to the constraint compilation stage.

[0277] During the constraint compilation phase, the system reads the structured software specification and compiles it into ECIR.

[0278] Specifically, the following constraints are generated: For the "User Authentication" module, permission boundary constraints, state transition constraints, and login interface contract are generated. For the "Task Creation" module, transaction consistency constraints, data structure constraints, and creation interface contract are generated. For the "Task List Display" module, interface call timing constraints and return field constraints are generated.

[0279] At the same time, the system assigns a unique constraint identifier to each constraint so that it can be tracked uniformly in subsequent stages.

[0280] During the task decomposition phase, the system breaks down the overall development task into multiple sub-tasks based on ECIR and assigns them to the Authentication Coding Agent, Backend Coding Agent, and Frontend Coding Agent, respectively.

[0281] The authentication coding agent is responsible for generating login authentication-related code, the backend coding agent is responsible for generating task creation and task list interface-related code, and the frontend coding agent is responsible for generating login page, task list page, and call logic-related code.

[0282] In the output phase, each encoding agent returns a declarative semantic signature and an observational semantic signature, in addition to the code package.

[0283] The Authentication Encoding Agent returns a summary of the parameters and return values ​​of the login interface, as well as a permission access declaration. It also returns a summary of the traces of its actual calls to authentication verification functions, access to the user table, and writing to the session cache during sandbox self-testing.

[0284] The backend coding agent returns a summary of the task table structure, a summary of the task list fields, and an interface signature hash, as well as a summary of the transaction call trace when the task was created.

[0285] The front-end coding agent returns a summary of the API paths it depends on, the requested fields, and the expected returned fields, as well as a summary of the actual call order in the sandbox automated test.

[0286] During the pre-compilation consistency verification phase, the system compares the above semantic signature with ECIR item by item.

[0287] If the front-end code expects GET / tasks / list to return the field taskStatus, while the back-end code declares the field to be status, the system will determine that there is a field name drift before compilation and prevent the corresponding code package from entering the unified build phase.

[0288] The system then records the relevant violation constraint flags and triggers the corresponding repair task.

[0289] If the code passes the pre-compilation consistency check, the system will perform unified build and automated testing.

[0290] If a 401 Unauthorized error occurs during end-to-end testing, the system generates a fault propagation graph based on test logs, API call chains, module dependencies, and relevant constraint identifiers.

[0291] Analysis revealed that the system malfunction primarily stemmed from the authentication filtering module and token verification logic, while the task list display module and front-end page logic were not directly affected.

[0292] During the minimum repair set solution phase, the system determines that only the authentication filtering module and the token verification module need to be repaired, while the task list module, task creation module, and front-end display module do not need to be modified.

[0293] Subsequently, the system sends a differential repair command to the target coded Agent.

[0294] The directive explicitly states that the code that can be modified is limited to the AST node set corresponding to specific functions and the validateToken() method in AuthFilter.java, while prohibiting modification of nodes that have already been validated in TaskService.java, TaskController.java, and the front-end TaskList.jsx.

[0295] After receiving a patch, the patch application verification module first filters the patch's scope of application based on the allowed modification boundaries, then verifies whether the patch touches prohibited nodes, and performs a hash comparison after modification on the prohibited areas.

[0296] If a patch modifies a locked AST node, the system refuses to apply the patch and logs an out-of-bounds fix event.

[0297] If the system finds that the same violation constraint flag is hit in three consecutive rounds during the multi-round repair process, or if the minimum repair set appears repeatedly in the preset rounds, the convergence control module determines that the repair process has entered an oscillation state.

[0298] At this point, the system triggers an upgrade strategy, expanding the scope of observational semantic signature collection, switching to a higher-level agent to repair it, or requiring manual confirmation of constraints and patching strategies.

[0299] After the repair is completed, the system will perform semantic signature extraction, pre-compilation consistency verification, unified build, and end-to-end testing again.

[0300] Once all tests meet the acceptance criteria, the system outputs the complete target software system, including the source code, build results, and verified deliverables.

[0301] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0302] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for automatically generating software based on agent clusters, characterized in that: The method includes: S100: Receive software requirements documents or structured software specifications, parse the input content, perform schema validity verification and constraint compilation, and generate an executable constraint intermediate representation ECIR; S200. Based on the ECIR, the overall development task is decomposed into multiple subtasks bound to the constraint subset, and each subtask is assigned to different coding agents in the coding agent resource pool for execution. S300: Each coded Agent generates code based on the subtask description and associated constraints, performs self-testing, and outputs a code package and corresponding semantic signature; the semantic signature includes a declarative semantic signature generated through static analysis and an observational semantic signature generated through the self-test execution trajectory. S400. Before unified construction, the semantic signature returned by each encoded Agent is compared with the corresponding constraints in ECIR item by item, and a pre-compilation consistency check is performed; if the check fails, it is marked as a violation and a repair task is generated. S500 performs unified build and automated testing on the verified code package. If the build or test fails, a fault propagation graph is generated based on the error log, call chain, module dependency relationship and violation constraint identifier. S600. Calculate the minimum repair set based on the fault propagation graph, generate differential repair instructions containing allowed and prohibited modification boundaries, and send them to the target coded Agent to perform patch repair. S700: Re-execute semantic signature extraction, pre-compilation consistency verification, and integration verification on the repaired code until the acceptance criteria are met or the repair convergence control mechanism is triggered.

2. The software automatic generation method based on agent clusters according to claim 1, characterized in that: In S100, the ECIR contains constraint objects with unique constraint identifiers, and the constraint objects include at least interface contract constraints, state transition constraints, data structure constraints, permission boundary constraints, resource usage constraints, and acceptance judgment constraints.

3. The software automatic generation method based on agent clusters according to claim 2, characterized in that: The process of generating the ECIR also includes input completeness assessment and constraint decidability score; When the input completeness score or constraint decisionability score is lower than the preset threshold, the verification agent review or manual confirmation mechanism is triggered; the data structure of the ECIR also includes a module unique identifier, interface definition, dependency relationship, runtime environment information and fields for tracking associations.

4. The software automatic generation method based on agent clusters according to claim 1, characterized in that: In S400, the pre-compilation consistency check includes at least one or more of the following comparisons: The system checks for consistency in interface parameters, consistency in returned field names and types, compliance of state transition paths, consistency between data structure fields and naming rules, whether permission declarations exceed limits, whether resource access exceeds limits, detection of inter-module dependency version conflicts, and whether dynamic execution trajectories violate state rules.

5. The software automatic generation method based on agent clusters according to claim 1, characterized in that: In S600, the specific method for calculating the minimum repair set is as follows: An optimization function is constructed with the objectives of minimizing repair costs and maximizing constraint correlation. The optimal set of repair nodes is then solved, as shown in the following formula: ； In the formula, This represents the minimum repair set obtained by solving the problem; Represents the complete set of nodes in the fault propagation graph; This indicates the number of nodes in the current candidate repair set; This represents the total number of nodes in the fault propagation graph; Represents a node The regression risk coefficient is determined based on the historical repair success rate or code complexity of that node; This represents the set of currently associated violation constraint identifiers; Represents the candidate repair set; Represents a node With violation of constraints The correlation score between them; , , These are weighting coefficients, used to balance the scope of repair, regression risk, and the correlation with constraints.

6. The software automatic generation method based on agent clusters according to claim 1, characterized in that: In S600, the process of generating the differential repair instruction includes: The set of AST nodes or code ranges that can be modified are determined based on the minimum repair set as the boundary of allowed modifications; Lock the verified modules or nodes to prevent modification of their boundaries; When the patch generated by the target encoding agent reaches the boundary of prohibited modification, the patch is rejected and the repair task is regenerated.

7. The method for automatically generating software based on an agent cluster according to claim 1, characterized in that: In S700, the repair convergence control mechanism includes: Monitor and repair rounds, count repeated violation constraints, and repair oscillation states; When the system is detected to have entered a repair oscillation state, the upgrade strategy is triggered; The repair of the oscillation state is achieved through the oscillation index. The determination is made using the following formula: ； In the formula, This indicates the volatility index of the current recovery cycle; This indicates the total number of repair cycles within the historical observation window; and Representing the current round and the number respectively A set of violation constraint indicators from historical rounds; and Representing the current round and the number respectively The minimum set of repairs for each historical cycle; Represents a set With sets Between Similarity coefficient is used to measure the degree of overlap between sets; and These are the weighting coefficients for the similarity of violation constraints and the similarity of the repair scope, respectively; when When the preset oscillation threshold is exceeded, the system is determined to have entered an oscillation state.

8. The method for automatically generating software based on an agent cluster according to claim 7, characterized in that: The upgrade strategy includes at least one of the following: Expand the scope of observational semantic signature collection, improve the consistency verification level, switch to a higher-privilege repair agent, expand the scope of the minimum repair set solution, or enter the manual confirmation stage.

9. A software automatic generation system based on agent clusters, used to implement the software automatic generation method based on agent clusters as described in any one of claims 1 to 8, characterized in that: The system includes: The Requirements Receiving and Constraint Compilation Module is used to receive software requirements documents or structured software specifications and compile them into an executable constraint intermediate representation (ECIR). The task decomposition and scheduling module is used to decompose the overall development task based on ECIR and schedule the coded agents. The coding agent resource pool contains multiple coding agents used to perform code generation, self-testing, and output code packages and semantic signatures; The consistency verification module is used to compare and verify semantic signatures with ECIR before unified construction; The integrated build and test module is used to perform unified builds and automated tests; The fault handling and repair closed-loop module is used to generate a fault propagation graph, calculate the minimum repair set, generate differential repair instructions, and control the repair convergence process when the build or test fails.

Images