Multi-agent asynchronous cooperative communication protocol and state machine management method

Abstract

The application discloses a multi-agent asynchronous cooperation communication protocol and a state machine management method, system, electronic equipment and storage medium, wherein the method writes non-text industrial data generated in a design-simulation-audit process into a version warehouse as a complete version object, and compresses and encodes the industrial feature state token containing a version identifier, a timestamp, a previous token identifier and a complete version object reference into a token chain and is asynchronously transmitted through a message queue; a design agent releases computing resources except for a listening context during waiting for simulation, and is awakened by a matching event; an audit agent generates a state migration event according to an engineering acceptance criterion, a cooperation state manager performs a legal migration check, and each agent only synchronizes an incremental patch; when not passed, a history version is traced back along a token chain and a rollback branch token is generated. The application can reduce communication load and resource occupation, and improve state consistency, version traceability and rollback security.

Description

Technical Field

[0001] This invention relates to the field of distributed message communication technology, and in particular to a multi-agent asynchronous cooperative communication protocol and state machine management method. Background Technology

[0002] The design optimization of industrial products is inseparable from simulation verification. Simulation solutions, represented by computational fluid dynamics (CFD) and finite element analysis (FEA), often take several hours for a single run, while modifying a design parameter usually only takes a few seconds. To shorten the R&D cycle, the industry has begun to introduce multi-agent systems based on large language models: the design agent is responsible for modifying parameters and generating solutions, the simulation interface system is responsible for modeling, mesh generation, and calling the solver, and the review agent is responsible for reading the results and giving conclusions. The three parties work together to complete the closed-loop iteration of "design-simulation-review".

[0003] Patent application CN120337777A discloses a multi-agent computer-aided engineering and computer-aided design method, which uses multi-agents based on a large language model to achieve autonomous planning and automatic execution of CAE simulation and CAD design optimization tasks. This scheme focuses on automating task planning and software invocation, with each agent working in turn around the task steps. However, it does not answer a fundamental engineering question: how to maintain consistency in the collaborative context between stages with vastly different speeds, such as simulation taking hours and design completed in seconds?

[0004] Some engineering practices have attempted to use general message queues to solve asynchronous communication between agents, such as multi-agent asynchronous communication schemes based on lightweight topics, which decouple the sender and receiver through request topics and response topics. These schemes address the issue of message delivery, with message payloads still primarily consisting of text or general structured fields. However, in industrial simulation scenarios, the objects that truly need to be exchanged—3D geometric models, mesh quality indicators, convergence curves—cannot be contained within a few lines of text: directly stuffing raw data into the message body results in a volume too large for the queue to handle; excessive simplification, on the other hand, renders downstream agents unable to function on it.

[0005] Another type of workflow orchestration framework uses state machines to manage agent collaboration processes, supporting checkpoint-based state saving and replay. This type of framework is designed for dialogue and text tasks, where checkpoints save the context as full snapshots. However, in long-cycle simulation iterations, a full copy of the current state is saved after each iteration, leading to continuously increasing storage and transmission overhead with each iteration. Furthermore, its snapshots do not distinguish the semantics of industrial data, and rollbacks can only revert to the entire design version, failing to pinpoint a specific design version.

[0006] In summary, existing technologies have three main shortcomings. First, contextual gaps: simulations can easily take several hours, and once the design agent submits its version, it cannot track the simulation progress. Similarly, when the review agent receives the results, it struggles to determine which parameter version those results correspond to. Second, resource idleness: after submitting parameters, the design agent remains idle, continuously consuming computational resources. In multi-task parallel processing, this can easily escalate into resource contention or even deadlock. Third, difficulties in non-textual data transfer: complex data such as geometric models, mesh quality, and convergence curves lack standardized, lightweight representations, leading to information asymmetry between agents and making it difficult to correlate review conclusions with the design version.

[0007] The common root cause of the above-mentioned defects is that the existing solutions address individual problems in task automation, message transmission, or process orchestration, but none of them provide a collaborative mechanism that integrates state representation, asynchronous communication, and version management for long-cycle industrial simulation iterations. Summary of the Invention

[0008] The technical problem to be solved by this invention is to provide a multi-agent asynchronous cooperative communication protocol and state machine management method, system, electronic device and storage medium, specifically: (1) The coexistence of long simulation cycles and short design cycles leads to asynchronous context states of multiple agents; (2) The computing resources are ineffectively occupied while the agent is waiting for the simulation results, which leads to resource contention and deadlock; (3) Non-textual industrial data such as three-dimensional geometric models, mesh quality indicators, and simulation convergence curves lack standardized representations that can be transferred between agents, and direct transmission leads to excessive communication load; (4) Asynchronous execution of multiple agents is prone to state disorder, untraceable version and error rollback. When the simulation result fails, it is impossible to accurately locate and return to the previous design version, and the iteration can only start from the beginning.

[0009] To solve the above problems, the present invention adopts the following technical solution: In a first aspect, the present invention provides a multi-agent asynchronous collaborative communication protocol and state machine management method, applied to an industrial simulation iteration scenario including a design agent, a simulation integration system, an audit agent, and a collaborative state manager. The method includes: during the iterative optimization process of industrial design-simulation-audit, after the design agent completes local design parameter modifications, it writes the non-text industrial data generated in this iteration as a complete version object into a version repository, and performs feature extraction and compression encoding on the non-text industrial data to generate an industrial feature state token; the industrial feature state token includes at least a token identifier, a task identifier, a current version identifier, a generation timestamp, and a prequence pointer pointing to the directly preceding industrial feature state token. The token identifier, the object reference or object hash of the complete version object, and the encoded feature representation are used to establish a mapping relationship between the industrial feature status token and the complete version object. Multiple industrial feature status tokens are chained together through the preceding token identifier to form a traceable token chain. The design agent publishes the industrial feature status token to the first topic of the message queue, and releases computing resources other than the listening context after successful publication, and enters a waiting state. The listening context includes at least the task identifier, the token identifier, and the subscription handle. The simulation connection system subscribes to the message queue, consumes the industrial feature status token in the first topic, and determines the token based on the object reference or object hash. The complete version object is obtained from the version repository and industrial simulation is performed to generate a simulation result token and a simulation completion event. The simulation completion event includes at least the task identifier, input token identifier, result token identifier, and simulation execution status. The auditing agent consumes the simulation completion event, evaluates the simulation result token according to preset engineering acceptance criteria, and generates a pass, rollback, or redesign state transition event. The collaborative state manager performs a valid transition check based on the current global state, the event type of the state transition event, and the token version relationship. When the check passes, the global collaborative state machine is updated to generate a new global state version and incremental patch. The global collaborative state machine defines a design state. The system includes a state, simulation state, review state, pass state, and rollback state, as well as transition rules between each state. Each agent, based on the difference between its local state version and the new global state version, only acquires and applies the fields that have changed in the incremental patch. When the state transition event is a rollback event, the collaborative state manager traverses the token chain from the failure token along the preceding token identifier, selects a historical design version, and generates a rollback branch token. The rollback branch token includes at least the selected historical version identifier, the failure token identifier, the branch identifier, and the new token identifier. The design agent obtains the corresponding complete version object based on the historical version identifier and continues to iterate from the historical design version.

[0010] Preferably, the industrial feature state token further includes a mode version field to identify the field structure version of the token; the preceding token identifier of the root token in the token chain is empty or a preset value; the simulation completion event, the state transition event, and the state update message all carry event identifiers, and the receiver performs idempotent processing on duplicate event identifiers; the message event also carries the expected current global state version, and if the version does not match, it is temporarily stored or rejected to cope with the out-of-order arrival of asynchronous messages.

[0011] Preferably, when the non-text industrial data is a three-dimensional geometric model, its boundary representation (B-Rep) topological adjacency relationship and geometric feature parameters are extracted, and the faces, edges, vertices and adjacency relationships are normalized and sorted to generate a topological sequence. Then, it is combined with the quantized geometric feature parameters according to a preset splicing rule to calculate a feature hash sequence used for version consistency verification.

[0012] Preferably, when the non-text industrial data is simulated grid data, the encoded feature representation includes a grid quality score vector, which is mapped from at least the minimum Jacobian determinant, the average Jacobian determinant, the proportion of negative Jacobian cells, the maximum aspect ratio, the average aspect ratio, the maximum warpage, and the average warpage. Each component is normalized to the interval between 0 and 1 and is used as the engineering acceptance criterion of the auditing agent.

[0013] Preferably, when the non-text industrial data is simulation convergence curve data, key control points are extracted according to residual slope, curvature change, oscillation point and convergence event, curve fitting is performed, and the fitting model type, fitting parameters, fitting error and final convergence state are recorded to form the encoded feature representation.

[0014] Preferably, when the design agent releases computing resources, it suspends the local design task process and returns at least one of GPU memory, CPU quota, memory cache, and model inference instance; the listening context also includes the expected global state version and minimum state cache; when an evaluation result notification matching the task identifier and token identifier appears in the message queue, the design task process is woken up, computing resources are re-requested, and the corresponding full version object is obtained; when the waiting timeout occurs, a retry is performed, manual processing is transferred, or the corresponding state transition is rejected and the exception is recorded.

[0015] Preferably, the valid migration verification includes: verifying whether the migration path between the event type of the state migration event and the current global state exists in the transfer rules; verifying whether the version relationship of the event-associated token in the token chain is consistent with the current version recorded in the current global state; migration is allowed only if both of these conditions are met.

[0016] Preferably, the global collaborative state machine generates a monotonically increasing global state version after each legitimate migration; the incremental patch includes the field path, the old hash of the field, the new hash of the field, and the new value; the collaborative state manager only issues patches that are higher than the agent's local state version, the agent verifies the old hash of the field, applies the patch, and returns confirmation; in case of conflict, the token chain causality and the latest legitimate global state version are used as the arbitrators, and manual arbitration is triggered when the arbitrators cannot be determined.

[0017] Preferably, during rollback, the historical design version that is closest to the failure token and whose simulation execution was successful is selected, or selected according to the preset backtracking depth k; the branch where the failure token is located is marked as closed and does not participate in subsequent state synchronization; a causal relationship is established between the rollback branch token and the failure token.

[0018] Secondly, this invention provides a multi-agent asynchronous cooperative communication protocol and state machine management system, including a design agent, a message queue, a simulation interface system, an audit agent, a cooperative state manager, and a version repository, configured to execute the above-described method. Thirdly, this invention provides an electronic device including a memory and a processor, wherein the processor implements the above-described method when executing a computer program in the memory. Fourthly, this invention provides a computer-readable storage medium, wherein a computer program stored thereon implements the above-described method when executed by a processor.

[0019] Compared with the prior art, the present invention can achieve the following technical effects: Industrial feature status tokens compress non-textual industrial data such as 3D geometric models, mesh quality indicators, and convergence curves into standardized, lightweight status representations. The message queue transmits tokens and incremental patches, rather than complete CAD models, mesh files, and convergence curves. The version identifier and timestamp in the token make it possible to determine "which result corresponds to which version of parameters".

[0020] After the intelligent agent issues a token, it immediately releases all computing resources except for the listening context and enters a waiting state. It is awakened by a matching event in the message queue that carries the task identifier and the token identifier. During the waiting period, the resources are returned to the system for unified allocation. When multiple tasks are running in parallel, there will be no contention or deadlock due to continuous occupation of resources.

[0021] The collaborative state manager performs a valid transition check for each state transition. Combined with a monotonically increasing global state version, incremental patching based on field hashing, and idempotency and out-of-order handling of message events, it enables all agents to converge to the same global state in an asynchronous concurrent environment, and the communication overhead does not accumulate with each iteration round.

[0022] The preceding token identifier links all tokens into a causal chain. Failure tokens and rollback branch tokens are interconnected. Any agent that obtains the same token can restore the same version of the design from the version repository through object reference or object hash.

[0023] Rollback does not overwrite the failure chain, but generates a rollback branch token with a branch identifier from the selected historical version. The failure path is retained as auditable, and the cost of a single rework is reduced from the entire iteration process to the difference between two adjacent versions. Furthermore, subsequent incremental synchronization always has a clear version baseline.

[0024] The preceding token in the token chain serves three functions simultaneously: message routing and wake-up matching (F5), version relationship verification for legitimate migration checks (F8), and historical version location during rollback (F10). The same data structure runs through the three stages of communication, verification, and rollback; if any stage is missing, the remaining stages degenerate into the existing scheme. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the overall architecture of a multi-agent asynchronous cooperative system provided in an embodiment of the present invention; Figure 2 A schematic diagram of the industrial feature status token data structure and token chain provided in this embodiment of the invention; Figure 3 A timing diagram for asynchronous message publishing / subscription and computing resource release / wake-up provided in embodiments of the present invention; Figure 4 This is a schematic diagram of a legal transition of a global cooperative state machine provided in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the version chain, rollback branch, and incremental state synchronization provided in an embodiment of the present invention.

[0026] In the diagram: 100, Design Agent; 110, Message Queue; 111, First Topic; 112, Second Topic; 113, Third Topic; 120, Simulation Connection System; 130, Review Agent; 140, Collaborative State Manager (Global Collaborative State Machine); 150, Token Chain (State Chain); 160, Version Repository; 200, Industrial Feature State Token; 210, Current Version Identifier; 211, Token Identifier; 212, Task Identifier; 220, Generation Timestamp; 230, Preceding Token Identifier; 240, Feature Hash Sequence; 250, Quality Score Vector; 260, Curve Fitting Parameters; 270, Object Reference / Object Hash; 280, Pattern Version; 310, Design State; 320, Simulation State; 330, Review State; 340, Pass State; 350, Rollback State. Detailed Implementation

[0027] The embodiments of the present invention will be further described below with reference to the accompanying drawings. The following embodiments are used to explain the present invention, and not to limit the scope of protection of the present invention; the parameter value ranges given are preferred ranges for engineering implementation, and those skilled in the art can adjust them around these ranges according to specific working conditions and computing power conditions. For clarity, the terminology throughout the text is uniformly agreed as follows: "failed" includes two situations: "simulation execution failed" and "engineering acceptance failed". The former refers to the solver reporting an error, solving timeout, or incomplete result file, while the latter refers to the simulation execution being successful but the preset engineering acceptance criteria not being met; "industrial feature status token" refers to the standardized status representation generated according to the data field structure defined in this specification; "preceding token identifier" is the reference information pointing to the directly preceding industrial feature status token in the token chain.

[0028] I. System Overall Architecture Figure 1 The overall architecture of a multi-agent asynchronous collaborative system is shown. The system includes a design agent 100, a message queue 110, a simulation interface system 120, an auditing agent 130, a collaborative state manager 140, and a version repository 160. The message queue 110 is internally divided into topics according to communication direction: the first topic 111 carries industrial feature status tokens (design submission / simulation requests) sent from the design agent 100 to the simulation interface system 120; the second topic 112 carries simulation result tokens and simulation completion events sent from the simulation interface system 120 to the auditing agent 130; and the third topic 113 carries state transition events sent from the auditing agent 130 to the collaborative state manager 140, as well as evaluation result notifications sent to the design agent 100. The collaborative state manager 140 maintains the global collaborative state machine, does not directly participate in data computation, records the current global state of the collaborative process, performs valid transition checks on state transition events, and broadcasts state updates and incremental patches to each agent through the message queue 110. Version repository 160 is used to persistently store the complete version objects of each iteration; the industrial feature state tokens generated in each iteration are sequentially linked to form token chain 150 (also known as state chain). Each agent stores a copy of the global state locally and only applies the fields that have changed after receiving a broadcast.

[0029] II. Industrial Feature Status Tokens, Full Version Objects, and Token Chains Figure 2 The data structure of the industrial feature status token 200 is shown. It is important to emphasize that the token is not used to replace complete industrial data; it is only used for asynchronous communication, message routing, status verification, and rapid evaluation. Complete industrial data is stored as complete version objects in the version repository 160 (which can be implemented as object storage, a versioned file system, or shared storage). A one-to-one mapping relationship is established between the token and the complete version object. The token consists of a header and a payload. The header fields and their meanings are shown in Table 1.

[0030] Table 1 Industrial Feature Status Token Header Fields

[0031] The token's payload segment contains coded feature representations, carrying three types of encoding based on the type of non-textual industrial data: First, a feature hash sequence 240, derived from the boundary representation (B-Rep) of the 3D geometric model. After extracting topological adjacency relationships and geometric feature parameters, the topological sequence is generated by normalizing and sorting the faces, edges, vertices, and adjacency relationships. This sequence is then combined with the quantized geometric feature parameters according to a preset splicing rule. The preferred length is 128 bits to 512 bits. The hash algorithm should be selected to ensure that models of the same version will inevitably obtain the same sequence, and that different versions of the model will hardly collide. Cryptographic hash truncation or locality-sensitive hashing can be used. Second, a quality score vector 250, mapped from the mesh quality indicators of the simulated mesh, covering at least the minimum Jacobian determinant, average Jacobian determinant, proportion of negative Jacobian cells, maximum aspect ratio, average aspect ratio, maximum warpage, and average warpage. The vector dimension is preferably 3 to 16 dimensions, and each component is normalized to the interval between 0 and 1. Third, the curve fitting parameter 260 is obtained by extracting key control points from the simulation convergence curve and fitting the curve. The control points are extracted according to the residual slope, curvature change, oscillation point and convergence event, and the number is preferably 8 to 64. At the same time, the fitting model type, fitting parameters, fitting error and final convergence state are recorded.

[0032] The total data size of the token is controlled to the KB level, preferably not exceeding 64KB; the serialization format can use structured formats such as JSON or Protocol Buffers. The original geometric model, mesh file, and simulation result file are still stored in the version repository 160. The token only retains the object reference or object hash 270. The message queue only transports the token, not the original files. The downstream receiver obtains the complete version object from the version repository 160 based on the object reference or object hash 270, and can verify the integrity of the obtained object through the object hash.

[0033] Multiple industrial characteristic status tokens are chained together via preceding token identifiers 230 to form a traceable token chain 150. Logically, the token chain is a directed chain: each token points to its direct preceding token, and the preceding token identifier of the root token is empty or a preset value. During rollback, the collaborative state manager 140 traverses the token chain hop-by-hop along the preceding token identifiers 230, starting from the failed token, selecting a historical design version, and generating a rollback branch token with the token corresponding to the selected historical version as the parent node. This causes the token chain to fork at the rollback position, forming a version directed acyclic graph (DAG). Tokens on the rolled-back branch are retained in the chain and marked as closed for later traceability and auditing.

[0034] III. Message Queue Topic Division, Event Fields, and Reliability Rules Message queue 110 is divided into three topics according to the communication direction: topic 111 is used for design submission / simulation requests; topic 112 is used for simulation completion / result notification; and topic 113 is used for state transition / evaluation result notification. All types of message events flowing through message queue 110 adopt a unified associated field structure, as shown in Table 2.

[0035] Table 2 Message Event Related Fields

[0036] Based on the aforementioned associated fields, the system executes the following reliability rules: First, idempotency processing: the receiver maintains a set of processed event identifiers; when duplicate messages with the same event_id arrive, state transitions or business actions are not executed repeatedly. Second, out-of-order processing: message events carry expected_state_version; if the expected_state_version does not match the current global state version recorded by the receiver, the event is temporarily stored for sorting or rejected and an exception is recorded. Third, failure processing: message delivery times out and is retried a preset number of times; after the retries are exhausted, the message is transferred to a dead-letter queue and an alarm is triggered. Fourth, persistence: messages in the message queue are persistently stored, with 2 to 3 replicas being preferred. The message queue middleware can be any product that supports publish / subscribe and persistence, such as Kafka, RabbitMQ, or RocketMQ; this invention does not depend on any specific product for implementation.

[0037] IV. Global Collaborative State Machine and Legitimate Transition Verification Figure 4 The state transition relationships of the global collaborative state machine are shown. The state machine defines five states: design state 310, simulation state 320, review state 330, pass state 340, and rollback state 350. All state transitions are uniformly performed by the collaborative state manager 140 to verify legality. The verification is based on three factors: the current global state, the event type of the state transition event, and the version relationship of the event-associated token in the token chain. The legal transition rules (event-condition-action mapping) are shown in Table 3.

[0038] Table 3. Legal Transition Table for Global Cooperative State Machine

[0039] The evaluation criteria for the auditing agent 130 include two categories of judgments: first, execution judgments, namely whether the simulation is completed, whether the solver reports an error, whether it times out, and whether the result file is complete; second, engineering acceptance judgments, namely quantitative indicators corresponding to the product's operating conditions, such as maximum stress, maximum displacement, temperature, pressure loss, aerodynamic drag, convergence residual, mesh quality threshold, etc. Evaluation conclusions are mapped according to the following rules: simulation execution failure results in an exception / retry or rollback; simulation execution success but engineering acceptance judgments are not met (engineering acceptance fails), results in rollback or redesign; all judgments are met, results in approval; missing judgments or mismatch between the version relationship of the event-related token and the current global state result in rejection of state transition and recording of an exception. After each valid transition, the collaborative state manager 140 generates a monotonically increasing global state version (state_version) and corresponding incremental patches, which are broadcast via message queue 110.

[0040] V. Incremental State Synchronization and Conflict Handling Each agent maintains a copy of the global collaborative state machine locally and only synchronizes incremental changes relative to the local state. The specific steps are as follows: (1) The global collaborative state machine generates a monotonically increasing global state version after each valid migration; (2) The collaborative state manager 140 generates an incremental patch based on this, which includes the field path, the old hash of the field, the new hash of the field, and the new value; (3) Each agent reports its local state version; (4) The collaborative state manager 140 only sends incremental patches higher than its local state version to the agents and does not transmit the full context that has not changed; (5) After the agent verifies that the old hash of the field in the patch is consistent with the local field, it applies the patch and writes the new value; (6) After successful application, an acknowledgment message (ack) is returned. If the verification is inconsistent, a request is made to resynchronize the baseline state; (7) When a conflict occurs, arbitration is carried out based on the causal relationship in the token chain 150 (version DAG) and the latest valid global state version. If it cannot be determined, manual arbitration is triggered. The above mechanism enables the state writing errors in asynchronous out-of-order and message duplication scenarios to be intercepted by both the version baseline and the field hash.

[0041] VI. Computing Resource Release and Reawakening Mechanism After the design agent 100 publishes the token to the first topic 111 and confirms successful publication, it suspends the local design task process and releases computing resources except for the listening context. The released resources include at least one of the following: GPU memory, CPU quota, memory cache, model inference instance, and simulation pre-context. The retained listening context is a minimal set, including at least the task identifier, token identifier, and subscription handle, and may also include the desired global state version and minimal state cache. When an evaluation result notification matching the retained task identifier and token identifier appears in the message queue 110, the design agent 100 is awakened: it re-requests computing resources, loads the minimal state cache in the listening context, retrieves the corresponding complete version object from the version repository 160 based on the object reference or object hash 270, restores the design context, and continues working. If the waiting time exceeds a preset threshold, the system retryes, transfers to manual processing, or rejects the corresponding state transition and records the exception. Therefore, the design agent 100's use of computing resources is limited to the period when actually executing parameter modifications and no longer spans the entire simulation solution process.

[0042] VII. Rollback Branches and Version DAG Figure 5 This illustrates the relationship between the version chain, rollback branches, and incremental state synchronization. When a state transition event is a rollback event, the collaborative state manager 140 starts from the failure token and traverses the token chain 150 along the preceding token identifier 230, selecting a historical design version according to the following rules: by default, it selects the historical design version closest to the failure token that has been successfully simulated; or, according to a preset backtracking depth k, it selects the kth historical design version preceding the failure token. After selection, the token corresponding to this historical version is used as the new chain tail parent node to generate a rollback branch token; the rollback branch token includes at least the selected historical version identifier, the failure token identifier, the branch identifier, and the new token identifier, thus establishing a causal relationship with the failure token. The branch containing the failure token is marked as closed and does not participate in subsequent state synchronization; after the design agent 100 is awakened, it obtains the corresponding complete version object according to the historical version identifier in the rollback branch token, continues iterating from this historical design version, and the newly generated token is connected to the rollback branch. Therefore, rollback is not an overwrite of the failure chain, but a branched evolution that retains failure records, is auditable, and has a clear version baseline. VIII. Overall Method Flow Combination Figure 3 Based on the temporal relationship, the complete process of this method includes the following steps: S101, the design agent 100 completes local design parameter modification and generates non-textual industrial data such as the three-dimensional geometric model of the current iteration; S102, the design agent 100 writes the non-text industrial data of this round as a complete version object into the version repository 160, and then performs feature extraction and compression encoding to generate an industrial feature status token 200. The token identifier 211, task identifier 212, current version identifier 210, generation timestamp 220, previous token identifier 230, object reference or object hash 270 and encoded feature representation are written into the token and the complete version object. The mapping relationship between the token and the complete version object is established. S103, the design agent 100 publishes the token to the first topic 111 of the message queue 110. After confirming the successful publication, it suspends the local design task process, returns computing resources such as GPU memory and CPU quota, retains only the listening context, and enters the waiting state. After verification, the collaboration state manager 140 migrates the global collaboration state machine from the design state 310 to the simulation state 320. S104, the simulation connection system 120 subscribes to the new token in the first topic 111, retrieves the complete version object from the version repository 160 based on the object reference or object hash 270 and restores the design site, and starts the simulation calculation after completing the mesh generation and solver configuration; after the calculation is completed, the mesh quality index is encoded as a quality score vector 250, the convergence curve is encoded as a curve fitting parameter 260, a simulation result token is generated, and a simulation completion event carrying the task identifier, input token identifier, result token identifier and simulation execution status is pushed to the second topic 112; S105, the auditing agent 130 responds to the completion event in the second topic 112 to start the evaluation process, reads the quality score vector 250 and curve fitting parameters 260, and gives the evaluation conclusion by comparing the execution criteria and the engineering acceptance criteria in turn, and sends the state transition event of pass, rollback or redesign to the third topic 113. S106, the cooperative state manager 140 performs a valid migration check on the state transition event: the migration path between the event type and the current global state exists in the transition rules, and the version relationship of the event-associated token is consistent with the current version of the current global state record. Both of these conditions must be met before migration can proceed. When the check passes, the global cooperative state machine is updated, a new global state version and incremental patch are generated and broadcast, and each agent refreshes its local copy according to the incremental synchronization steps described in Part 5. S107, if the evaluation conclusion is that all criteria are met, the global collaborative state machine transitions from review state 330 to pass state 340, the current iteration ends, and the review agent 130 notifies the design agent 100 through the third topic 113; if the optimization goal is not achieved, a new iteration is started according to the migration rule E6. S108, if the evaluation conclusion is that the project acceptance has failed, the global collaborative state machine enters the rollback state 350. The collaborative state manager 140 starts from the failure token and locates the selected historical design version along the preceding token identifier 230, and generates a rollback branch token containing the historical version identifier, the failure token identifier, and the branch identifier. After the design agent 100 is awakened by the evaluation result notification that matches the task identifier and the token identifier, it re-applies for computing resources, obtains the corresponding complete version object according to the historical version identifier, restores the design state of that version, and continues to iterate. If the evaluation conclusion is that the simulation execution has failed, it performs a retry or rollback according to the migration rule E7 and records the exception.

[0043] IX. Example 1: Fully Automated CFD Iteration for Aircraft Engine Compressor Blade Profile Optimization In this scenario, the design agent 100 is responsible for adjusting the geometric parameters of the blade profile and reconstructing the blade model. The simulation integration system 120 sequentially completes the computational domain extraction, mesh generation, and CFD solution. Each solution takes several hours. The review agent 130 determines whether the result of this round passes based on aerodynamic evaluation indicators. For each version of the blade profile modified, the design agent 100 first writes the blade model and design parameter set as a complete version object into the version repository 160, and then encodes the boundary representation of the blade model into a 256-bit feature hash sequence 240. After the simulation integration system 120 completes the mesh generation, it maps seven indicators—minimum Jacobian determinant, average Jacobian determinant, negative Jacobian cell ratio, maximum aspect ratio, average aspect ratio, maximum warpage, and average warpage—into a 7-dimensional quality score vector 250. After the solution is completed, 32 key control points are extracted from the residual convergence curve according to the changes in residual slope and curvature. The curve fitting parameters are obtained by B-spline fitting 260, and the fitting error and final convergence state are recorded. The three types of codes, along with the header fields, are packaged into an Industrial Feature Status Token 200, which is published via Topic 111.

[0044] Collaboration proceeds according to the process described in Part 8. After design agent 100 issues a token, it releases GPU and memory quotas, which are available for other iterative tasks during the waiting period. Several hours later, the simulation completes, and the completion event awakens audit agent 130 via topic 112. The engineering acceptance criteria are set as follows: pressure ratio not less than 98% of the design point target value, efficiency not less than 97% of the target value, convergence residual less than 10 to the power of -4, and each component of the mesh quality score vector not less than 0.6. These thresholds are preferred examples and do not constitute a limitation on the scope of protection. If the efficiency index fails to meet the criteria in a certain round of evaluation, the engineering acceptance fails, and audit agent 130 issues a rollback event. After the collaboration state manager 140 verifies the error, it locates the third iteration version closest to the failure token and meeting the execution criteria along the token chain and generates a rollback branch token. After being awakened, Design Agent 100 obtains the third complete version object, restores the template parameters, and continues to modify them. Although the exploratory modifications after the fourth round are abandoned, their tokens remain on the chain and are marked as closed, allowing designers to clearly see the cause and effect of each fork during post-mortem analysis. Throughout the entire process, Design Agent 100's consumption of computing resources is limited to the periods when it actually performs parameter modifications.

[0045] 10. Example 2: Synchronization of FEA Iteration and Digital Twin State of Drive Motor Housing in New Energy Vehicles In this scenario, the design agent 100 adjusts the arrangement of the shell reinforcing ribs and the wall thickness parameters, the simulation connection system 120 performs structural finite element analysis, and the review agent 130 verifies the strength, stiffness, and modal indicators. The engineering acceptance criteria are: the maximum stress is less than 80% of the allowable stress, the first-order modal frequency avoids the excitation frequency band by ±10%, and the maximum displacement is less than 0.5mm. The above thresholds are preferred examples and do not constitute a limitation on the protection scope. The difference from Embodiment 1 is that a cost assessment agent is added during the system's operation: this agent only needs to subscribe to the second topic 112 to receive tokens for each iteration, calculates the manufacturing cost based on the quality score vector 250 and the current version identifier 210, without modifying the existing protocols and processes between the three parties, and the loosely coupled architecture remains open to the access of heterogeneous agents.

[0046] During the digital twin operation and maintenance phase, the same token mechanism is reused for long-term state synchronization between the physical prototype and the digital model: design changes triggered by field sensor data are also registered on the chain in the form of tokens. Operation and maintenance personnel can query the model version at any time and its corresponding simulation verification conclusion along the token chain, realizing version traceability in predictive maintenance.

[0047] XI. Main Parameters and Optimal Range The main parameters and their preferred ranges involved in the above embodiments are summarized as follows: feature hash sequence length 128 bits to 512 bits; quality score vector dimension 3 to 16 dimensions, components normalized to 0 to 1; convergence curve key control points 8 to 64; timestamp accuracy in milliseconds; single token data size not exceeding 64KB; message queue messages persistently stored, with 2 to 3 copies; status update messages only carry incremental patches. The above values ​​are preferred engineering values ​​for implementing this invention and do not constitute a limitation on the scope of protection.

[0048] XII. Effect Analysis To illustrate the technical effects of this invention, three comparative schemes are analyzed: Scheme A involves full data synchronization plus polling, where the complete CAD model, mesh file, and convergence curve are transmitted in the message channel in each iteration, and the agent waits for the results in a polling manner while occupying computing resources throughout the process; Scheme B uses asynchronous tokens plus full state synchronization, employing the token mechanism of this invention, but the state update message carries the full context; Scheme C is the scheme of this invention, which involves asynchronous tokens plus incremental state synchronization. The qualitative comparison of the three schemes in key indicators is shown in Table 4.

[0049] Table 4 Qualitative Comparison of Comparison Schemes

[0050] Based on the structural parameters of this invention, analysis shows that: in terms of communication load, the data volume of a single token does not exceed 64KB, while the complete geometric model, mesh, and result file in industrial scenarios are usually in the MB to GB range. The data volume of a single round of messages in Scheme C is reduced by more than two orders of magnitude compared to Scheme A. In terms of resource consumption, the resource consumption of the intelligent agent in Scheme A spans several hours throughout the simulation process, while in Scheme C, the consumption is limited to the design period of seconds. The ratio of the consumption time is comparable to the ratio of the design and simulation time. In terms of state consistency, Scheme C uses legal migration verification, global state version, field hash verification, and idempotent / out-of-order processing to form multiple interceptions, so out-of-order and duplicate messages will not lead to incorrect state writing.

[0051] The above description is merely a preferred embodiment of the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A multi-agent asynchronous cooperative communication protocol and state machine management method, applied to an industrial simulation iteration scenario including a design agent, a simulation connection system, an audit agent, and a cooperative state manager, characterized in that, The method includes: In the iterative optimization process of industrial design-simulation-review, after the design agent completes the local design parameter modification, it writes the non-text industrial data generated in this iteration into the version repository as a complete version object, and performs feature extraction and compression encoding on the non-text industrial data to generate an industrial feature status token. The industrial feature status token includes at least a token identifier, a task identifier, a current version identifier, a generation timestamp, a preceding token identifier pointing to the directly preceding industrial feature status token, an object reference or object hash of the complete version object, and an encoded feature representation. A mapping relationship is established between the industrial feature status token and the complete version object, and multiple industrial feature status tokens are chained together through the preceding token identifier to form a traceable token chain. The design agent publishes the industrial feature status token to the first topic of the message queue, and after successful publication, releases computing resources except for the listening context and enters a waiting state; the listening context includes at least the task identifier, the token identifier, and the subscription handle. The simulation connection system subscribes to the message queue, consumes the industrial feature status token in the first topic, retrieves the complete version object from the version repository according to the object reference or object hash, and performs industrial simulation, generating a simulation result token and a simulation completion event; the simulation completion event includes at least the task identifier, input token identifier, result token identifier, and simulation execution status; The auditing agent consumes the simulation completion event, evaluates the simulation result token according to the preset engineering acceptance criteria, and generates state transition events for passing, rolling back, or redesigning. The collaborative state manager performs a valid migration check based on the current global state, the event type of the state transition event, and the token version relationship. When the check passes, it updates the global collaborative state machine, generates a new global state version and incremental patch, and broadcasts the state update message to each agent. The global collaborative state machine defines a design state, a simulation state, a review state, a pass state, and a rollback state, as well as the transition rules between each state. Each agent, based on the difference between its local state version and the new global state version, only obtains and applies the fields that have changed in the incremental patch; When the state transition event is a rollback event, the collaborative state manager traverses the token chain from the failure token along the preceding token identifier, selects a historical design version, and generates a rollback branch token. The rollback branch token includes at least the selected historical version identifier, the failure token identifier, the branch identifier, and the new token identifier. The design agent obtains the corresponding complete version object based on the historical version identifier and continues to iterate from the historical design version.

2. The multi-agent asynchronous cooperative communication protocol and state machine management method according to claim 1, characterized in that, The industrial feature status token also includes a mode version field, which is used to identify the field structure version of the industrial feature status token; the predecessor token of the root token in the token chain is empty or a preset value.

3. The multi-agent asynchronous cooperative communication protocol and state machine management method according to claim 1, characterized in that, The simulation completion event, the state transition event, and the state update message all carry event identifiers. The receiver performs idempotent processing on duplicate messages with the same event identifier and does not perform state transitions repeatedly. The simulation completion event and the state transition event also carry the expected current global state version. If they do not match the current global state version recorded by the receiver, the corresponding message event will be temporarily stored or rejected.

4. The multi-agent asynchronous cooperative communication protocol and state machine management method according to claim 1, characterized in that, When the non-text industrial data is a three-dimensional geometric model, the generation of the encoded feature representation includes: extracting the boundary representation topological adjacency relationship and geometric feature parameters of the three-dimensional geometric model, normalizing and sorting the faces, edges, vertices and adjacency relationships to generate a topological sequence; combining the topological sequence with the quantized geometric feature parameters according to a preset splicing rule to calculate a feature hash sequence for version consistency verification.

5. The multi-agent asynchronous cooperative communication protocol and state machine management method according to claim 1, characterized in that, When the non-text industrial data is simulated grid data, the encoded feature representation includes a grid quality score vector; the grid quality score vector is mapped from at least the minimum Jacobian determinant, the average Jacobian determinant, the proportion of negative Jacobian cells, the maximum aspect ratio, the average aspect ratio, the maximum warpage, and the average warpage, with each component normalized to the interval between 0 and 1, and used as the engineering acceptance criterion.

6. The multi-agent asynchronous cooperative communication protocol and state machine management method according to claim 1, characterized in that, When the non-text industrial data is simulation convergence curve data, key control points are extracted according to residual slope, curvature change, oscillation point and convergence event. Curve fitting is performed on the extracted key control points, and the fitting model type, fitting parameters, fitting error and final convergence state are recorded to form the encoded feature representation.

7. The multi-agent asynchronous cooperative communication protocol and state machine management method according to claim 1, characterized in that, The release of computing resources other than the listening context includes: suspending the local design task process and returning at least one of GPU memory, CPU quota, memory cache, and model inference instance; the listening context also includes the expected global state version and minimum state cache; when an evaluation result notification matching the task identifier and the token identifier appears in the message queue, the design task process is woken up, computing resources are re-requested, and the corresponding full version object is obtained according to the object reference or object hash; when the waiting time exceeds a preset threshold, a retry is performed, manual processing is initiated, or the corresponding state transition is rejected and the exception is recorded.

8. The multi-agent asynchronous cooperative communication protocol and state machine management method according to claim 1, characterized in that, The valid migration verification includes: verifying whether the migration path between the event type of the state migration event and the current global state exists in the transfer rules; verifying whether the version relationship of the token associated with the state migration event in the token chain is consistent with the current version recorded in the current global state; performing state migration when both verifications pass, and rejecting migration and recording an exception when either verification fails.

9. The multi-agent asynchronous cooperative communication protocol and state machine management method according to claim 1, characterized in that, The process of acquiring and applying only the changed fields in the incremental patch includes: the global collaborative state machine generating a monotonically increasing global state version after each valid migration; the incremental patch containing the field path, the old hash of the field, the new hash of the field, and the new value; each agent reporting its local state version, and the collaborative state manager only issuing incremental patches higher than the local state version; the agent applying the incremental patch after verifying that the old hash of the field matches the local field, and returning a confirmation message after successful application; in the event of a conflict, arbitration is conducted based on the causal relationship of the token chain and the latest valid global state version, and manual arbitration is triggered if it cannot be determined.

10. The multi-agent asynchronous cooperative communication protocol and state machine management method according to claim 1, characterized in that, The selection of a historical design version includes: selecting the historical design version that is closest to the failure token and has been successfully simulated, or selecting a historical design version according to a preset backtracking depth k; the branch where the failure token is located is marked as closed and does not participate in subsequent state synchronization; a causal relationship is established between the rollback branch token and the failure token.

11. A multi-agent asynchronous cooperative communication protocol and state machine management system, characterized in that, include: The design agent is configured to write non-text industrial data as a complete version object into a version repository and generate an industrial feature state token. After publishing the token to the first topic of a message queue, it releases computing resources except for the listening context. The message queue is configured to transmit the token, simulation completion event, state transition event, and state update message by topic. The simulation integration system is configured to retrieve a complete version object from the version repository based on the object reference or object hash in the token and perform industrial simulation, generating a simulation result token and a simulation completion event; The auditing agent is configured to evaluate the simulation result token and generate a state transition event based on preset engineering acceptance criteria. The collaboration state manager is configured to perform valid migration checks on the state transition events, update the global collaboration state machine, and generate a global state version and incremental patch; and the version repository is configured to persistently store the complete version object; the system performs the method described in any one of claims 1 to 10.

12. An electronic device, characterized in that, The method includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 10.

Images