Large model edge collaborative decision method and system for dynamic scene

Abstract

The application discloses a large model edge cooperative decision method and system for dynamic scenes, relates to the technical field of data processing and analysis, and comprises the following steps: after an emergency event occurs, original monitoring nodes are called to form an original monitoring topology structure; a first demand data is established by activating an identification and analyzing a function loss after communication verification; an emergency scene and second demand data are configured, a temporary edge intelligent agent is configured and networking is performed after demand analysis; after successful networking, the edge intelligent agent reads monitoring data and independently makes a decision to form a first decision result; finally, communication interaction and role evolution conflict game analysis are performed to generate a second decision result. The application solves the technical problems that the traditional data processing method is difficult to adapt to environmental changes, has a delayed response and cannot coordinate multi-agent decision conflict in a dynamic scene, and achieves the technical effects that data processing is timely and efficient, decision making is accurate and reliable, and the cooperative decision making demand in the dynamic scene is met.

Description

Technical Field

[0001] This invention relates to the field of data processing and analysis technology, and in particular to a method and system for edge collaborative decision-making of large models for dynamic scenarios. Background Technology

[0002] In dynamic scenarios (such as emergency events), timely and accurate decision-making is crucial to the effectiveness of event response, and data processing is the core support for decision-making. Current technologies largely rely on fixed-node monitoring and centralized data processing for decision-making, which is highly effective in stable scenarios. However, in dynamic scenarios, the environment changes in real time, and fixed monitoring nodes are prone to communication interruptions and insufficient coverage. Traditional centralized data processing suffers from response delays and difficulty adapting to local dynamics, leading to untimely data processing, frequent decision conflicts, and an inability to meet the needs of rapid collaborative decision-making in dynamic scenarios, thus affecting the efficiency and accuracy of emergency response. Summary of the Invention

[0003] This application provides a method and system for collaborative decision-making at the edge of a large model in dynamic scenarios, which addresses the technical problems of traditional data processing methods being unable to adapt to environmental changes, response delays, and coordination of multi-agent decision-making conflicts in dynamic scenarios.

[0004] The first aspect of this application provides a large-scale model edge collaborative decision-making method for dynamic scenarios. The method includes: after an emergency event occurs, calling the original monitoring nodes of the original scenario to construct an original monitoring topology; after verifying communication with the original monitoring nodes, identifying the activation of the original monitoring topology based on the communication verification results, performing a functional deficiency analysis of the original monitoring topology based on the activation identification, and establishing first requirement data; after configuring an emergency scenario based on the emergency event, configuring second requirement data based on the emergency scenario, performing requirement analysis on the first and second requirement data, configuring temporary edge agents, and configuring mobile sensors to form a temporary edge agent network; after successful network formation, reading monitoring data from monitoring nodes within the network based on the edge agents, executing independent decision-making by the edge agents, and establishing a first decision result; after executing communication interaction between the edge agents, performing conflict game analysis on the first decision result to generate a second decision result, wherein the conflict game analysis is a role evolution conflict game analysis.

[0005] The second aspect of this application provides a large-scale edge collaborative decision-making system for dynamic scenarios. The system includes: an original monitoring topology construction module, used to call the original monitoring nodes of the original scenario to construct an original monitoring topology after an emergency event occurs; a first requirement data acquisition module, used to verify the communication of the original monitoring nodes, activate the original monitoring topology based on the communication verification result, perform functional loss analysis on the original monitoring topology based on the activation identifier, and establish first requirement data; a temporary edge agent construction module, used to configure an emergency scenario based on the emergency event, configure second requirement data based on the emergency scenario, perform requirement analysis on the first requirement data and the second requirement data, configure temporary edge agents, and configure mobile sensors to form a temporary edge agent network; a first decision result construction module, used to, after successful network formation, execute independent decision-making by the edge agents based on the monitoring data read from the monitoring nodes within the network, and establish a first decision result; and a second decision result acquisition module, used to perform conflict game analysis on the first decision result after executing the communication interaction of the edge agents, and generate a second decision result, wherein the conflict game analysis is a role evolution conflict game analysis.

[0006] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0007] This application achieves efficient collaborative decision-making in dynamic scenarios by calling upon the original monitoring nodes to build a topology structure and analyzing functional deficiencies after an emergency occurs, configuring temporary edge agents and mobile sensor networks, enabling edge agents to read monitoring data and make independent decisions, and then generating the final decision result through role evolution conflict game analysis of interactive data. Combined with decision verification and compensation mechanisms, this achieves the technical effect of timely and efficient data processing, accurate and reliable decision-making, and meeting the collaborative decision-making needs in dynamic scenarios. Attached Figure Description

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

[0009] Figure 1 This is a flowchart illustrating the edge collaborative decision-making method for large models in dynamic scenarios provided in this application embodiment.

[0010] Figure 2 This is a schematic diagram of the structure of the large-model edge collaborative decision-making system for dynamic scenarios provided in the embodiments of this application.

[0011] Figure labeling: Original monitoring topology construction module 1, first requirement data acquisition module 2, temporary edge agent construction module 3, first decision result construction module 4, second decision result acquisition module 5. Detailed Implementation

[0012] This application provides a method and system for collaborative decision-making at the edge of a large model in dynamic scenarios, which addresses the technical problems of traditional data processing methods being unable to adapt to environmental changes, response delays, and coordination of multi-agent decision-making conflicts in dynamic scenarios.

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0014] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0015] Example 1, as Figure 1 As shown, a collaborative decision-making method for large-scale models in dynamic scenarios is provided, wherein the method includes:

[0016] Step A100: After an emergency occurs, call the original monitoring nodes of the original scene to build the original monitoring topology.

[0017] In this embodiment, the original monitoring nodes are devices already deployed in the original scenario for monitoring the environmental status. These nodes may include various sensors, detectors, etc.

[0018] Specifically, after an emergency occurs, the original monitoring nodes already deployed in the original scenario are invoked first. These nodes include temperature sensors, vibration detectors, cameras, etc., which store historical monitoring data of the scenario, such as the average monitoring frequency of a certain area over the past three months and the equipment response time.

[0019] After invoking these original monitoring nodes, they are connected to form an initial monitoring topology based on their physical distribution and pre-defined communication protocols. Specifically, the ID information and location coordinates of each node are first read. Then, the connection relationship is determined by detecting the communication signal strength and communication delay between nodes. For example, a signal strength ≥ -70dBm is considered as capable of direct communication, and a delay ≤ 50ms is considered as capable of stable communication. Finally, a topology containing effective connection links is constructed, forming an initial monitoring topology covering the core area of ​​the emergency scenario. This allows each node to perform initial data transmission and information exchange according to this structure, providing a basic framework for subsequent communication verification and functional analysis.

[0020] By dynamically calling the original nodes and building the topology based on the communication status, valid nodes can be quickly selected, ensuring the validity of the topology and the basic stability of data transmission, providing a reliable network framework for subsequent communication verification and functional analysis.

[0021] Step A200: After verifying the communication of the original monitoring node, activate the original monitoring topology based on the communication verification result, perform a functional loss analysis of the original monitoring topology based on the activation identifier, and establish the first requirement data.

[0022] In this embodiment, the activation identifier is a status mark made on the nodes in the original monitoring topology based on the verification result after the original monitoring node has been verified for communication. The mark distinguishes between nodes with valid communication and nodes with invalid communication.

[0023] Optionally, after the original monitoring topology is established, communication verification is performed on the original monitoring nodes. During this process, the system sends standardized communication test commands to each node. These commands include parameters such as data packet size and transmission frequency; for example, a 500-byte test data packet is sent each time, lasting 10 seconds, and sent 10 times per second. Simultaneously, the system records the response time, data packet reception integrity, and link stability data for each node. The response time must be ≤100ms, the data packet reception integrity rate must be ≥95%, and the link fluctuation amplitude must be ≤15%. These indicators collectively constitute the core standards for communication verification.

[0024] After the above verification, the test data of each node were summarized and analyzed. For example, the original monitoring topology contained 20 nodes, of which 16 nodes had a response time of less than 80ms, a data packet reception integrity rate of 98%, and a link fluctuation amplitude of less than 10%, which met the preset effective communication standards; among the other 4 nodes, 2 had a response time of more than 150ms, 1 had a data packet reception integrity rate of only 80%, and 1 had a link fluctuation amplitude of 30%, all of which failed the verification.

[0025] Based on the communication verification results, the original monitoring topology is marked as active. For the 16 nodes that passed verification, the system marks them as active and retains their original link connections within the topology; the 4 nodes that failed verification are marked as inactive and temporarily removed from the valid links in the topology. After activation, only the active nodes and their valid communication links remain in the original monitoring topology. For example, the 16 active nodes form multiple stable links, providing a reliable communication foundation for subsequent functional deficiency analysis.

[0026] Finally, adaptive functional clustering is performed based on the communication and physical structures of the original monitoring topology, and labels are established. These labels are used to verify the functional implementation of the activation identifier. Functional missing analysis is completed through functional time limit verification results, thereby establishing the first requirement data. The specific steps are explained in detail in A210-A220.

[0027] By quantitatively verifying the communication capabilities of the original monitoring nodes, valid nodes were selected based on objective data and activated, ensuring that the nodes participating in subsequent processes in the original monitoring topology have stable communication conditions, thus laying a solid communication foundation for subsequent demand analysis and decision execution.

[0028] Step A300: After configuring the emergency scenario based on the emergency event, configure the second demand data according to the emergency scenario, perform demand analysis on the first demand data and the second demand data, configure temporary edge agents, and configure mobile sensors to form a temporary edge agent network.

[0029] In this embodiment, the second requirement data is the minimum feasible combination of capabilities that must be met under the current situation, configured based on the emergency scenario, and is used to achieve task convergence. It represents all core requirements that must be met. The temporary edge agent is a temporary intelligent entity configured based on the analysis results of the first and second requirement data, undertaking core functions such as data processing, decision-making, and collaboration.

[0030] In one embodiment of this application, after an emergency event occurs, an emergency scenario is configured based on the specific type and scope of the event. For example, when an earthquake occurs in a certain area, the emergency scenario needs to cover a 300-meter radius around the epicenter and clearly define key monitoring areas, including areas where buildings are damaged, areas where people may be trapped, and secondary disaster risk points.

[0031] Next, based on the configured emergency scenario, the second set of required data is further determined. Since this second set of required data represents the minimum feasible combination of capabilities that must be met under the current circumstances to achieve task convergence, it is necessary to clearly define the core monitoring indicators and coverage requirements. For example, in the earthquake scenario mentioned above, the second set of required data specifically includes: building structural vibration monitoring points must cover all damaged buildings, with at least 3 monitoring points per building; personnel vital sign detection must cover areas where people may be trapped, with a detection radius ≥ 5 meters; and aftershock early warning data sampling frequency ≥ 20 times / second. All of these indicators are indispensable and must be met.

[0032] The first requirement data represents the maximum capability boundary of the scenario under non-emergency conditions. For example, under non-emergency conditions, the area originally had 12 vibration sensors, each with a coverage range of 20 meters; and 6 environmental monitoring nodes, with a sampling frequency of 10 times / second. When conducting requirement analysis on the first and second requirement data, if there is overlap between the first and second requirements, the original deployment method of the first requirement can be referenced. For example, if the first requirement requires vibration sensors to be deployed along the building's load-bearing walls, which overlaps with the deployment requirements for building structural vibration monitoring points in the second requirement, then this original deployment method can be referenced when adding new monitoring points, adding one vibration sensor every 15 meters on the load-bearing walls of the damaged building. However, if the sampling frequency of the environmental monitoring nodes in the first requirement cannot meet the 20 times / second requirement of the second requirement, then the configuration should be strictly based on the second requirement, without referring to the relevant data from the first requirement.

[0033] Then, based on the above requirements analysis results, temporary edge agents are configured. According to the core indicators of the second requirement, the number and functions of the agents are determined. For example, for vibration monitoring and vital sign detection, 6 temporary edge agents are configured, of which 4 are responsible for real-time vibration data parsing, supporting 30 data processing operations per second, and 2 are responsible for the fusion analysis of vital signs and location information, with a response latency of ≤150ms.

[0034] Simultaneously, mobile sensors are configured to form a temporary edge agent network. The type and number of mobile sensors are determined based on the gaps in the second requirement. For example, the second requirement for aftershock early warning requires 8 monitoring points, while the first requirement does not have relevant deployments. Therefore, 8 mobile seismic wave sensors are deployed and connected to the temporary edge agents via wireless communication. The communication distance is ≥80 meters, and the data transmission delay is ≤30ms, forming a temporary network covering all key areas to ensure that the agents can acquire and process monitoring data in real time.

[0035] By combining the maximum capability boundary of the first requirement and the essential requirements of the second requirement, and configuring temporary edge agents and mobile sensor networks after requirement analysis, a real requirement that fits the emergency scenario was established, providing accurate data support and network foundation for subsequent collaborative decision-making.

[0036] Step A400: After successful network formation, based on the monitoring data of the monitoring nodes in the network read by the edge agent, the edge agent performs independent decision-making and establishes the first decision result.

[0037] Specifically, after successful networking, the network formed by temporary edge agents and mobile sensors has achieved full coverage of the target area. For example, in an emergency scenario, eight temporary edge agents networked with 50 mobile sensors to cover an emergency area of ​​about 2,000 square meters. The sensor types include temperature sensors, vibration sensors, and personnel positioning sensors. The data transmission delay is stable within 50ms, ensuring the real-time nature of the monitoring data.

[0038] Based on this, each edge agent begins reading data from monitoring nodes within its assigned area. Taking edge agent number 2, responsible for the damaged building area, as an example, it needs to read data from 12 sensors in that area, including real-time temperature values ​​from 8 temperature sensors (range -20℃ to 150℃) and vibration frequencies from 4 vibration sensors (range 0 to 50Hz). During the reading process, the edge agent performs preliminary data preprocessing, removing obvious outliers, such as false 200℃ readings from temperature sensors, and standardizing the data format to JSON for easier subsequent processing. Preprocessing time is controlled within 100ms.

[0039] Subsequently, the edge agent executes independent decisions. Each agent has a built-in local decision-making model trained on historical emergency data. The model input is preprocessed monitoring data, and the output is preliminary decision suggestions for the area. The construction of the local decision-making model first requires the collection of a large amount of historical emergency event data, including monitoring node data in different scenarios, such as multi-dimensional indicators like temperature, vibration, and personnel location, corresponding decision schemes, and execution effect feedback. Next, the data is cleaned, outliers are removed, missing items are filled, and key features such as data fluctuation trends and the number of times anomaly thresholds are triggered are extracted through feature engineering. Then, a lightweight model architecture suitable for the computing power of edge devices is selected, such as an improved decision tree or a lightweight neural network. The model is trained using preprocessed historical monitoring data as input and historical effective decisions as output. Gradient descent is used to iteratively optimize parameters. The model's decision accuracy (target ≥90%) and response latency (target ≤200ms) are monitored in real time using a validation set. Hyperparameters such as the number of network layers and nodes are adjusted multiple times to finally obtain a model that is adapted to the local computing power of the edge agent and can quickly output reliable preliminary decision suggestions.

[0040] For example, when edge agent 2 reads that the temperature in a certain area exceeds 60°C for three consecutive times and the vibration frequency is consistently higher than 30Hz, it makes an independent decision based on the model to activate the sprinkler cooling system in that area and increase the sampling frequency of the sensors within a 5-meter radius to 5 times / second. When edge agent 5, which is responsible for the personnel search and rescue area, reads the personnel location signal, it decides to dispatch two nearby mobile sensors to move closer to the signal source to enhance the positioning accuracy.

[0041] Each edge agent completes its independent decision-making process locally, without relying on other agents. The decision-making time varies from 200ms to 500ms depending on the amount of data, ultimately forming its own first decision result, which will serve as the basis for subsequent conflict game analysis.

[0042] By reading and processing monitoring data in real time through edge agents and combining them with local models to make independent decisions, the system can quickly generate first-order results for each region, providing timely and localized preliminary basis for collaborative decision-making in dynamic scenarios.

[0043] Step A500: After executing the communication interaction of the edge agent, perform conflict game analysis on the first decision result to generate a second decision result. The conflict game analysis is a role evolution conflict game analysis.

[0044] Specifically, during the communication interaction of edge agents, each edge agent relies on the communication link formed by the network to transmit information such as its independent decision results, current operating status, and task execution progress. Through this interaction, each agent can know the decision-making tendencies and real-time status of other agents, achieving information sharing and state synchronization. This provides a foundation for subsequent conflict perception of the first decision result, data fusion to establish global conflict indicators, and ensures that conflict game analysis can be carried out based on comprehensive interactive information.

[0045] The first decision result is analyzed by conflict game theory. First, all edge agent roles are modeled, conflicts are perceived and data is integrated to establish a global conflict index, conflict game channels are activated and role fitness is calculated, then role evolution is reconstructed based on the role mutation pool, and finally the second decision result is established by game theory analysis based on the reconstruction result. The specific steps are explained in detail in A510-A540.

[0046] Furthermore, step A500 in the method provided in this application embodiment includes:

[0047] A510: Perform role modeling on all edge agents and generate role modeling results.

[0048] A520: Executes the conflict perception of the first decision result, integrates the state information and communication interaction data of the edge agent, and establishes a global conflict index.

[0049] A530: Activate the conflict game channel using the global conflict index, and call the role fitness function to calculate the role fitness of the edge agent in the current conflict environment, and generate the role fitness.

[0050] A540: Based on the aforementioned role fitness, perform role evolution reconstruction based on the role mutation pool, and based on the role evolution reconstruction results, conduct game analysis of the conflict game channel to establish a second decision result.

[0051] Specifically, when conducting conflict game analysis on the first decision outcome, role modeling is first performed on all edge agents. Based on each agent's preset functions, responsible areas, and task types, role attributes are defined, such as area monitoring, resource scheduling, and coordination, clarifying the task boundaries, data processing permissions, and interaction rules for each role. For example, in an emergency scenario, six edge agents are modeled into two area monitoring agents focused on data collection and preliminary analysis; three resource scheduling agents responsible for allocating mobile sensors; and one coordination agent responsible for coordinating information interaction. The final result generates role modeling results that include role functions, priorities, and collaborative relationships.

[0052] Next, conflict perception of the first decision result is executed, collecting state information from each edge agent, such as current computing resource utilization, remaining battery power, and communication interaction data, such as decision commands and data requests sent to each other. This information is then transformed into quantifiable conflict parameters through a fusion algorithm. For example, when two resource scheduling agents simultaneously request the same set of mobile sensors, it is recorded as a resource contention conflict; when the decision result of an area monitoring agent deviates from the core requirements of the emergency scenario by more than 15%, it is marked as a decision deviation conflict. These conflict parameters are then aggregated to calculate global conflict indices, such as conflict occurrence rate (current number of conflicts / total number of decisions) and resource conflict degree (resource contention frequency / total number of resource requests). Higher index values ​​indicate more significant conflicts.

[0053] Then, the conflict game channel is activated using a global conflict index. The channel is activated when the index value exceeds a preset threshold (e.g., conflict occurrence rate ≥ 30%). The construction process of the aforementioned conflict game channel and role fitness function is as follows:

[0054] The construction of the conflict game channel requires using a global conflict index as the core trigger condition, setting an activation threshold (e.g., activating when the global conflict index value is ≥0.6), and building a multi-layered processing architecture. Its core processing layer needs to integrate a role / task identification module, a conflict coupling analysis module, and a game coordination module. The role / task identification module is used to analyze the task boundaries and objectives after role evolution and reconstruction. The conflict coupling analysis module is linked to a conflict sensitivity index library, storing the conflict probability and impact weight of different task types. The game coordination module provides a rule framework for interaction and negotiation among multiple intelligent agents, ensuring that the channel can effectively support the entire process from conflict identification to game analysis.

[0055] The construction of the role fitness function needs to comprehensively consider the core elements of the current conflict environment, taking the role matching degree, task completion efficiency, resource utilization rationality, and collaborative compatibility of the edge agent as key input parameters. By assigning dynamic weights to each parameter, such as increasing the task priority weight to 0.4 and the resource load weight to 0.2 in high-conflict scenarios, a weighted summation or nonlinear mapping algorithm is used to transform the parameter values ​​into fitness values ​​in the range of 0-1. The higher the value, the stronger the role adaptability of the agent in the current conflict environment, providing a quantitative basis for subsequent role evolution and reconstruction.

[0056] Then, the role fitness function is invoked to calculate the role fitness of each edge agent in light of the current conflict environment. The function inputs include role task completion rate, such as the sensor allocation success rate of resource scheduling agents; collaborative efficiency, i.e., the speed of information interaction response with other agents; and conflict resolution contribution, i.e., the number of times the agent participates in resolving conflicts. This generates role fitness results containing the fitness values ​​of each agent.

[0057] Finally, based on role fitness, role evolution reconstruction is performed using a role mutation pool. Mutated roles are located based on role fitness and synchronized to the role mutation pool based on historical evolutionary memory. Through mutated role template matching and local evolutionary simulation based on game task requirements, the role evolution reconstruction is completed. Specific steps are detailed in A541-A544. Next, the conflict game channel processing layer is invoked. Based on the role evolution reconstruction results, role tasks are identified, and conflict points are identified through conflict coupling analysis. Then, a second decision result is established through multi-party collaborative agent game analysis. Specific steps are detailed in A545-A546.

[0058] By using role modeling, conflict perception, fitness calculation, and role evolution reconstruction, the system systematically resolves decision-making conflicts of edge agents, generates better second decision results, and improves the rationality and efficiency of collaborative decision-making in dynamic scenarios.

[0059] Furthermore, step A540 in the method provided in this application embodiment includes:

[0060] A541: Based on the aforementioned role fitness, locate the mutated role and generate the location result.

[0061] A542: Synchronize the positioning results to the character mutation pool, which is a mutated character template constructed based on historical evolution memory.

[0062] A543: Perform the matching of the mutated character template of the positioning result in the character mutation pool to establish the matching result.

[0063] A544: Perform local evolution simulation on the matching results based on game task requirements, node resource status, and local topology location, and complete role evolution reconstruction based on the local evolution simulation results.

[0064] Optionally, when reconstructing roles based on a role mutation pool according to role fitness, the mutated roles are first located based on role fitness. Assuming there are 8 edge agents with role fitness of 0.92, 0.88, 0.55, 0.76, 0.49, 0.81, 0.58, and 0.79 respectively, and a fitness threshold of 0.6 is set, then the 3rd, 5th, and 7th agents with fitness below the threshold are located as roles that need to be mutated, generating a location result that includes these agent IDs, current role type, and functional shortcomings.

[0065] Next, the location results are synchronized to the role mutation pool, which stores mutated role templates built based on historical evolutionary memory, such as dynamic resource coordination type, rapid response monitoring type, and cross-regional collaboration type. Each template is accompanied by historical application effect data. For example, the dynamic resource coordination type has reduced resource conflicts by an average of 40% in the past 10 similar scenarios. During the synchronization process, the functional shortcomings of the agents in the location results (such as the high resource allocation conflict rate of the 3rd agent and the excessive response latency of the 5th agent) are associated with the template tags in the pool.

[0066] Then, the mutated role template is matched in the role mutation pool, and the appropriate template is selected based on the functional requirements in the positioning results. For example, a dynamic resource coordination template is matched for the third agent with a high resource allocation conflict rate, a fast response monitoring template is matched for the fifth agent with excessive response latency, and a cross-regional coordination template is matched for the seventh agent with insufficient local coordination, generating a matching result that includes the matching template and the matching degree.

[0067] Subsequently, local evolution simulations were performed on the matching results based on the game task requirements, node resource status, and local topology location. If the current game task requirement is to prioritize reducing resource conflicts, the node resource status of the third agent is 60% computational load, and the local topology location is in a resource-intensive area, then the simulation shows the effect of the dynamic resource coordination template under these conditions, and the simulation shows that its resource conflict rate is reduced. Similarly, the simulations for the fifth and seventh agents respectively verified that the response latency was shortened to within the threshold and the cross-regional collaboration efficiency was improved. Based on these simulation results, the template parameters were adjusted, and finally the role evolution reconstruction was completed.

[0068] By locating the roles that need to be mutated, matching historical templates, and combining simulation optimization with actual scenarios, the evolution and reconstruction of roles were realized, making the edge agent more adaptable to the current conflict environment and providing a more reasonable role basis for subsequent conflict game analysis.

[0069] Furthermore, step A540 in the method provided in this application embodiment includes:

[0070] A545: Call the processing layer of the conflict game channel, identify role tasks based on the role evolution reconstruction results, perform conflict coupling analysis based on the conflict sensitivity index library based on the role tasks, and identify task conflict points.

[0071] A546: Based on the aforementioned task conflict points, conduct multi-party collaborative agent game analysis to establish a second decision result.

[0072] Specifically, when conducting game theory analysis of the conflict game channel based on the role evolution and reconstruction results to establish a second decision outcome, the processing layer of the conflict game channel is first invoked. This processing layer, as the core module for data interaction and task parsing, receives detailed information after role evolution and reconstruction, including the new role type, functional boundaries, and task scope of each edge agent. For example, after reconstruction, agent 3's role is adjusted to core area temperature monitoring, sampling every 10 seconds; agent 5's role is peripheral resource scheduling, covering a radius of 50 meters. The processing layer parses this role information one by one, clarifying the core task objective of each agent, the other roles requiring cooperation, and the time window for task execution, forming a structured role and task list.

[0073] Subsequently, based on the identified roles and tasks, a conflict coupling analysis was conducted using a conflict sensitivity index library. This library contains the probability of conflict, the degree of impact, and association rules between different task types. For example, the conflict sensitivity between resource scheduling and monitoring tasks in terms of resource usage is 0.7 (ranging from 0 to 1, with higher values ​​indicating greater conflict risk), while the conflict sensitivity between monitoring tasks in the same area in terms of data acquisition frequency is 0.5. During the analysis, parameters such as task type, execution resources, and time intervals in the role task list were matched with the index library to calculate the coupling degree between tasks. If the monitoring task of agent 3 and the resource scheduling task of agent 5 overlap in the usage time of sensor A, both requiring invocation between 10:00 and 10:10, the coupling degree calculation result is 0.8, exceeding the preset threshold of 0.6, thus identifying it as a task conflict point. Simultaneously, it was found that the monitoring ranges of agents 2 and 4 overlapped by 60%. However, because the conflict sensitivity for the same type of task is lower at 0.4, it did not reach the threshold and was not listed as a conflict point. This resulted in a list containing multiple high-risk conflict points.

[0074] Finally, a multi-party collaborative agent game analysis is conducted based on the task conflict points. Through this collaborative game, all task conflict points are resolved, resulting in a second decision that balances overall efficiency and task priority. The specific steps are explained in detail in A546-1-A546-5.

[0075] By accurately identifying roles and tasks, scientifically analyzing conflict points, and promoting multi-party collaborative game, contradictions in task execution were effectively resolved, and a second decision result adapted to the needs of dynamic scenarios was generated, improving the coordination and feasibility of the decision.

[0076] Furthermore, step A546 in the method provided in this application embodiment includes:

[0077] A546-1: Obtain the task priority of the edge agent, and establish a first evaluation feature based on the task priority.

[0078] A546-2: Obtain the computing resource load information of the edge agent, and establish a second evaluation feature based on the computing resource load information.

[0079] A546-3: Obtain the average response delay of the edge agent, and establish a third evaluation feature based on the average response delay.

[0080] A546-4: Obtain the collaborative features of the edge agent, and establish a fourth evaluation feature based on the collaborative features.

[0081] A546-5: Configure a fitness function based on the first evaluation feature, the second evaluation feature, the third evaluation feature, and the fourth evaluation feature, and perform intelligent agent game analysis and evaluation based on the fitness function.

[0082] Specifically, when conducting multi-party collaborative agent game analysis based on task conflict points, the first step is to obtain the task priorities of the edge agents and establish primary evaluation features. Task priorities are divided according to factors such as the urgency and scope of impact of tasks in emergency events. For example, personnel search and rescue guidance is set as Level 1 (highest priority), equipment status monitoring as Level 2, and environmental data recording as Level 3. Then, through quantization mapping, the priorities are converted into feature values ​​in the 0-1 range, with Level 1 corresponding to 0.9, Level 2 to 0.6, and Level 3 to 0.3, thereby clarifying the differences in the importance of each agent's task.

[0083] Next, the computational resource load information of the edge agent is obtained to establish the second evaluation feature. The computational resource load includes indicators such as CPU utilization and memory usage. For example, if the current CPU utilization of an agent is 70% and the memory usage is 65%, the comprehensive load is calculated by weighted averaging (CPU weight 0.6, memory weight 0.4) as 70%×0.6+65%×0.4=68%. This is then converted into the feature value 1-68%=0.32. The higher the value, the lower the resource load and the stronger the ability to process new tasks.

[0084] Subsequently, the average response latency of the edge agent is obtained to establish the third evaluation feature. The average response latency is the average time taken for the agent to process the most recent 10 task requests. If the average response latency of an agent is 150ms, and the maximum acceptable latency in this scenario is assumed to be 500ms, then the feature value is 1-(150 / 500)=0.7. This value directly reflects the real-time response efficiency of the agent.

[0085] Next, the collaborative features of the edge agents are obtained to establish the fourth evaluation feature. The collaborative features include the success rate of information interaction with other agents and the completion rate of collaborative tasks. For example, if an agent has a 92% success rate of interaction with other agents and an 88% on-time completion rate of collaborative tasks, the average of the two (90%) is taken as the feature value of 0.9, which reflects its ability to cooperate in collaboration.

[0086] The fitness function is configured based on the four evaluation features mentioned above. The function adopts a weighted summation form, and the weights are allocated according to the core demands of the task conflict points. For example, when the task conflict involves resource competition, the weights are: task priority 0.4, computational resource load 0.2, average response latency 0.2, and collaborative features 0.2. If the four feature values ​​of an agent are 0.9, 0.32, 0.7, and 0.9 respectively, then its fitness is 0.9×0.4+0.32×0.2+0.7×0.2+0.9×0.2=0.784.

[0087] Finally, the agents participating in the game are evaluated based on the fitness function. Agents with higher fitness values ​​are given priority in task allocation and resource usage. For example, in a conflict over sharing a mobile sensor, agent A has a fitness of 0.784 and agent B has a fitness of 0.652. In this case, agent A is given priority in using the sensor, while agent B shares data with agent A through cooperative features, thereby resolving the conflict and completing the agent game analysis and evaluation.

[0088] By constructing multi-dimensional evaluation features and configuring fitness functions, the intelligent agents participating in the game are quantitatively evaluated, which enables the scientific resolution of task conflict points and improves the rationality and efficiency of multi-party collaborative decision-making.

[0089] Furthermore, step A200 in the method provided in this application embodiment includes:

[0090] A210: Based on the original monitoring topology, perform adaptive functional clustering based on communication structure and physical structure, and establish functional clustering labels.

[0091] A220: Use the functional clustering labels to verify the functional implementation of the activation identifier, and use the functional time limit verification results to complete the functional missing analysis in order to establish the first requirement data.

[0092] Specifically, after an emergency occurs, for the original monitoring topology that has been activated, adaptive functional clustering is first performed based on its communication and physical structures. The communication structure considers the strength of communication links between nodes, such as using a threshold of -70dBm to distinguish between strong and weak connections; and the data transmission frequency, such as ≥5 times / second for high-frequency transmission. The physical structure focuses on the spatial distribution of nodes, such as node density per 100 square meters; and coverage area, such as a monitoring radius of ≥20 meters for a single node. Through analysis of this data, nodes with similar functions are clustered. For example, eight nodes with strong communication links, concentrated physical locations, and all used for temperature monitoring are clustered into a high-temperature warning group; and six nodes with overlapping coverage areas and primarily used for vibration detection are clustered into a structural safety group. A functional clustering label is established for each cluster, clearly specifying information such as monitoring type, effective coverage area, and data processing capabilities.

[0093] Next, these functional clustering labels were used to verify the functionality of the activated nodes. For example, the labels for the high-temperature warning group required a node sampling frequency of ≥10 times / second and a temperature measurement error of ≤±0.5℃. Each of the eight activated nodes in this group was tested individually. The results showed that six nodes met the requirements, while two nodes had a sampling frequency of only 8 times / second and an error of ±0.8℃, failing to achieve the function corresponding to the label. Simultaneously, a time-limit verification was performed, requiring the nodes to enter a stable working state within 3 minutes of an emergency event being triggered. Records showed that 12 activated nodes were stable within 2 minutes, while 2 nodes only stabilized after 4 minutes, exceeding the time limit standard.

[0094] Then, by combining the results of functional implementation verification and functional time limit verification, a functional deficiency analysis is completed. For example, the structural safety group requires 6 nodes to meet the vibration frequency monitoring requirement of ≥20 times / second, but only 4 nodes actually meet the requirement, resulting in functional deficiencies in 2 nodes; among the overall activated nodes, 2 failed to respond in time due to timeouts, indicating a lack of response timeliness. These deficiencies are then summarized with the maximum capabilities of cluster groups, such as the maximum coverage of 500 square meters for the high-temperature warning group, and the performance parameters of existing stable operating nodes, to form the first requirement data. This data represents the maximum capability boundary under non-emergency conditions.

[0095] Since the first requirement data represents the maximum capability boundary, and the second requirement data represents the minimum feasible capability combination that must be met under the current situation (i.e., all of them must be met), in the subsequent requirement analysis with the second requirement data, if there are functions in the first requirement data that overlap with the second requirement data, such as both requiring temperature monitoring, then the original deployment method of that function in the first requirement data should be referenced for deployment, thereby establishing a real requirement that fits the emergency scenario.

[0096] By performing functional clustering based on communication and physical structure, and verifying functions and time limits, functional gap analysis is formed. This establishes the first requirement data that characterizes the maximum capability boundary and provides a reference for its integration with the second requirement data, thus laying a precise requirement foundation for the subsequent configuration of temporary edge agents.

[0097] Furthermore, step A500 in the method provided in this application embodiment includes:

[0098] A610: Establish a scheduling verification window based on the second decision result.

[0099] A620: Perform emergency decision execution verification in the scheduling verification window and establish node verification results.

[0100] A630: Perform adaptive decision compensation based on the node verification results, and perform emergency management based on the adaptive decision compensation.

[0101] In one embodiment, after generating the second decision result, a scheduling verification window is first established based on this result. The scheduling verification window needs to cover all execution nodes and task cycles involved in the second decision result. For example, if an emergency decision involves 8 edge agents and 12 specific tasks, the window duration is set to 1.5 times the decision execution cycle. If the task cycle is 20 minutes, the window duration is 30 minutes. The verification scope is defined as the core area affected by the decision. The window integrates a real-time data acquisition module, an execution status monitoring module, and an anomaly warning module to ensure that the dynamic process of decision execution can be fully captured.

[0102] Within the scheduling verification window, the execution verification of emergency decisions is conducted, and node verification results are established. Verification content includes the task startup time of each edge agent (must start within 3 minutes of the decision being issued); the compliance rate of key parameters, such as verifying the real-time compliance rate of a cooling decision requiring the target area temperature to drop below 30℃; and the accuracy of resource allocation, such as the deviation rate between the number of mobile sensors allocated and the decision requirement being ≤5%. For example, verification of 8 agents showed that 6 fully met the requirements, 2 had startup delays of 4 minutes and 5 minutes respectively, and the compliance rate of one temperature indicator was only 80%. These results are recorded by node category, forming node verification results with three labels: pass, slight deviation, and serious deviation.

[0103] Next, adaptive decision-making compensation is performed based on the node verification results. For nodes marked with slight deviations, such as a 3% deviation rate in resource allocation for a certain agent, compensation is made by fine-tuning the resource allocation ratio (increasing the sensor quota by 5%). For nodes with severe deviations, such as insufficient temperature index compliance rate, the analysis indicates that the cause is local sensor aging. The compensation measure is to temporarily add two mobile temperature sensors and adjust the agent's data analysis algorithm, such as increasing the outlier filtering threshold. After compensation, a second verification is performed within the window to ensure that the compliance rate of the deviation nodes is increased to over 95%.

[0104] Finally, emergency management is based on adaptive decision-making compensation, integrating verification results with compensation measures to form the final emergency response plan. For example, the compensation results of temperature control are synchronized to the rescue command center to guide rescue personnel in adjusting the timing of entering the target area; the compensation records of resource allocation are incorporated into the emergency resource dispatch system to optimize subsequent resource allocation strategies and ensure the efficiency and stability of the emergency response.

[0105] By establishing verification windows, implementing multi-dimensional verification, and carrying out precise compensation, closed-loop management of emergency decision-making is ultimately achieved, effectively improving the reliability of decision execution and the dynamic adaptability of emergency management.

[0106] Furthermore, step A500 in the method provided in this application embodiment includes:

[0107] A640: Based on the results of communication interactions, predict the development of emergency events and establish decision bias factors based on the development prediction results.

[0108] A650: After game compensation using the aforementioned decision bias factor for conflict game analysis, a second decision result is generated.

[0109] Optionally, after the communication interaction of the edge agents, the development prediction of the emergency event is first made based on the interaction results. The communication interaction will gather real-time monitoring data from each agent, such as the temperature in a certain area rising by 3°C every 5 minutes, the vibration frequency remaining above 20Hz; the progress of task execution, such as the sensor deployment completion rate of agent 3 being 70%; and changes in environmental parameters, such as the wind speed increasing from 1m / s to 3m / s. Based on this data, a time series prediction model (such as LSTM) is used to model the development trend of the event. For example, it is predicted that within the next hour, the fire may spread to a range of 200 meters to the northeast, the probability of aftershocks will increase to 65%, or the diffusion speed of hazardous substances will accelerate by 1.2 times, forming a development prediction result that includes the trend direction, the scope of impact, and the risk level.

[0110] Next, based on this development forecast, a decision-making bias factor is established. The bias factor is set according to the predicted risk level and scope of impact. For areas with higher risk and greater impact in the forecast, a relatively higher bias factor is set to reflect the priority consideration of these areas in decision-making; for areas with lower risk, the bias factor value is relatively lower to ensure that the allocation of resources is clearly prioritized.

[0111] Using the aforementioned decision bias factors, game compensation is applied to conflict game analysis. When conflicts exist in the decisions of various peripheral agents, such as multiple agents simultaneously requesting the same batch of key resources, the weights of each agent in the game are adjusted according to the bias factors. This allows agents with higher bias factors to receive priority consideration in conflict coordination, such as prioritizing the fulfillment of resource requests from agents in high-risk areas or adjusting the task sequence of agents in low-risk areas to avoid conflict.

[0112] After such game-theoretic compensation, the resulting second decision can better balance the current situation with the predicted trend of events, resolving the conflict in the original decision and making arrangements in advance for possible future changes.

[0113] By establishing decision-making bias factors based on development predictions using communication interaction data, targeted compensation is provided for conflict game analysis. The resulting second decision is more in line with the dynamic changes of emergency events, improving the foresight and adaptability of decision-making.

[0114] Furthermore, step A500 in the method provided in this application embodiment includes:

[0115] A660: Read the execution effect of the second decision result, bind the execution effect reading result, the second decision result, and the emergency event into a decision record.

[0116] A670: Use the decision records as a reference dataset to perform decision execution compensation for subsequent emergency events.

[0117] In one embodiment, after generating the second decision result, the execution effect of that result is first read. Key indicators related to the decision effect are collected in real time through monitoring nodes deployed in the decision execution area, such as temperature sensors, location trackers, and resource counters. These indicators include task completion rate (e.g., the percentage of rescue orders completed); resource utilization rate (e.g., the actual activation rate of deployed mobile sensors); event control effect (e.g., the rate of decrease in risk indicators within the emergency area); and response timeliness (e.g., the time elapsed from decision issuance to goal achievement). This data is then aggregated and processed to form the execution effect reading result.

[0118] Subsequently, the execution effect reading results, the second decision results, and the emergency event are data-bound. Emergency event information includes event type (e.g., earthquake, fire), occurrence time, impact range, and initial risk level. The second decision results cover specific measures, such as deploying 8 edge agents and designating 3 key monitoring areas; resource allocation schemes, such as allocating 20% ​​of computing power for data transmission. Through a data association algorithm, the three are bound by a unique event identifier, such as event IDEQ2023051201, forming a complete data chain containing event characteristics, decision content, and execution effect. For example, the association record for earthquake (3 blocks) - deployment of 8 agents - search and rescue completion rate of 92%.

[0119] The bound data is stored as decision records, using a distributed database for structured storage. Each record contains fields such as event metadata, decision text, performance metrics, and timestamps, and is categorized and indexed by event type and decision domain, such as earthquake-related and resource scheduling-related records. Simultaneously, the records undergo quality verification, removing invalid records with a data missing rate exceeding 10% or abnormal performance metrics (such as completion rate > 100%) to ensure the reliability of the dataset.

[0120] Finally, these decision records are used as a reference dataset for decision execution compensation in subsequent emergency events. When a new emergency event occurs, a feature matching algorithm (such as cosine similarity calculation) is used to retrieve historical records from the dataset with a feature similarity ≥80% to the new event. For example, a newly occurring fire event (affecting 2 city blocks, Level 2 response) has an 85% similarity to a historical fire (2.5 city blocks, Level 2 response). Analysis of the decision-making effect of this historical record shows that insufficient firefighting equipment allocation in the original decision led to low efficiency; the compensation measure is to increase the equipment quota by 15%. Based on this, the second decision result for the new event is adjusted to replenish equipment resources in advance, achieving decision execution compensation.

[0121] By recording and reusing data throughout the entire decision-making process, a closed-loop accumulation and application of decision-making experience has been formed, effectively improving the pertinence and execution of subsequent emergency decisions and achieving continuous optimization of decision-making capabilities in dynamic scenarios.

[0122] In summary, the edge collaborative decision-making method for large models in dynamic scenarios provided in this application has the following technical effects:

[0123] This application achieves efficient collaborative decision-making in dynamic scenarios by calling the original monitoring nodes to build a topology after an emergency occurs, obtaining the first requirement data through communication verification and functional deficiency analysis, and configuring temporary edge agents and networks in combination with the second requirement data configured in the emergency scenario. The edge agents read the monitoring data and make independent decisions, and then generate the second decision result through communication interaction and conflict game analysis. This enables efficient collaborative decision-making in dynamic scenarios, making emergency decisions more accurate and reliable. It achieves the technical effect of timely and efficient data processing, accurate and reliable decision-making, and meeting the collaborative decision-making needs in dynamic scenarios.

[0124] Example 2, as Figure 2 As shown, based on the same inventive concept as in Embodiment 1 above, this application provides a large-model edge collaborative decision-making system for dynamic scenarios, the system comprising:

[0125] Original monitoring topology construction module 1 is used to call the original monitoring nodes of the original scene to build the original monitoring topology after an emergency event occurs.

[0126] The first requirement data acquisition module 2 is used to verify the communication of the original monitoring node, identify the activation of the original monitoring topology based on the communication verification result, analyze the functional defects of the original monitoring topology based on the activation identifier, and establish the first requirement data.

[0127] Temporary edge agent construction module 3: After configuring an emergency scenario based on the emergency event, the temporary edge agent construction module 3 configures second demand data according to the emergency scenario, performs demand analysis on the first demand data and the second demand data, configures temporary edge agents, and configures mobile sensors to form a temporary edge agent network.

[0128] The first decision result construction module 4 is used to, after successful networking, execute the independent decision-making of the edge agent based on the monitoring data of the monitoring nodes in the network, and establish the first decision result.

[0129] The second decision result acquisition module 5 is used to perform conflict game analysis on the first decision result after executing the communication interaction of the edge agent, and generate a second decision result. The conflict game analysis is a role evolution conflict game analysis.

[0130] Furthermore, the second decision result acquisition module 5 is used to perform the following steps:

[0131] Role modeling is performed on all edge agents to generate role modeling results; conflict perception is performed on the first decision result, and the state information and communication interaction data of the edge agents are fused to establish a global conflict index; the global conflict index is used to activate the conflict game channel, and the role fitness function is called to calculate the role fitness of the edge agents in the current conflict environment to generate role fitness; role evolution reconstruction is performed based on the role fitness and the role mutation pool; game analysis of the conflict game channel is performed based on the role evolution reconstruction result to establish a second decision result.

[0132] Furthermore, the second decision result acquisition module 5 is used to perform the following steps:

[0133] Based on the role fitness, mutated roles are located, and a location result is generated; the location result is synchronized to the role mutation pool, which is a mutated role template constructed based on historical evolution memory; the mutated role template of the location result is matched in the role mutation pool to establish a matching result; the matching result is subjected to local evolution simulation based on game task requirements, node resource status, and local topology location, and the role evolution reconstruction is completed based on the local evolution simulation result.

[0134] Furthermore, the second decision result acquisition module 5 is used to perform the following steps:

[0135] The processing layer of the conflict game channel is invoked to identify role tasks based on the role evolution reconstruction results, and to perform conflict coupling analysis based on the conflict sensitivity index library based on the role tasks to identify task conflict points; based on the task conflict points, multi-party collaborative agent game analysis is performed to establish a second decision result.

[0136] Furthermore, the second decision result acquisition module 5 is used to perform the following steps:

[0137] The process involves: acquiring the task priority of the edge agent and establishing a first evaluation feature based on the task priority; acquiring the computing resource load information of the edge agent and establishing a second evaluation feature based on the computing resource load information; acquiring the average response latency of the edge agent and establishing a third evaluation feature based on the average response latency; acquiring the collaborative features of the edge agent and establishing a fourth evaluation feature based on the collaborative features; configuring a fitness function based on the first, second, third, and fourth evaluation features, and performing agent game analysis and evaluation based on the fitness function.

[0138] Furthermore, the first demand data acquisition module 2 is used to perform the following steps:

[0139] Based on the original monitoring topology, adaptive functional clustering based on communication and physical structures is performed to establish functional cluster labels; the functional cluster labels are used to verify the functional implementation of the activation identifier, and the functional time limit verification results are used to complete the functional missing analysis to establish the first requirement data.

[0140] Furthermore, the second decision result acquisition module 5 is used to perform the following steps:

[0141] A scheduling verification window is established based on the second decision result; the execution verification of emergency decisions is performed in the scheduling verification window, and node verification results are established; adaptive decision compensation is performed based on the node verification results, and emergency management is performed based on the adaptive decision compensation.

[0142] Furthermore, the second decision result acquisition module 5 is used to perform the following steps:

[0143] Based on the communication interaction results, the development of emergency events is predicted, and a decision bias factor is established based on the development prediction results. After game compensation using the decision bias factor for conflict game analysis, a second decision result is generated.

[0144] Furthermore, the second decision result acquisition module 5 is used to perform the following steps:

[0145] The execution effect of the second decision result is read, and the execution effect reading result, the second decision result, and the emergency event are bound together and stored as a decision record. The decision record is used as a reference dataset to execute decision execution compensation for subsequent emergency events.

[0146] The large-model edge collaborative decision-making system for dynamic scenarios provided in the embodiments of the present invention can execute the large-model edge collaborative decision-making method for dynamic scenarios provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0147] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0148] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application. In some cases, the actions or steps described in this application can be performed in a different order than that shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A large model edge collaborative decision-making method for dynamic scenarios, characterized in that, The method includes: After an emergency occurs, the original monitoring nodes of the original scenario are invoked to reconstruct the original monitoring topology. After verifying the communication of the original monitoring node, an activation identifier for the original monitoring topology is generated based on the communication verification result. Based on the activation identifier, a functional deficiency analysis of the original monitoring topology is performed to establish the first requirement data. After configuring an emergency scenario based on the emergency event, configure second demand data according to the emergency scenario, perform demand analysis on the first demand data and the second demand data, configure temporary edge agents, and configure mobile sensors to form a network of temporary edge agents. After the network is successfully formed, the edge agent reads the monitoring data of the monitoring nodes in the network and then executes the independent decision-making of the edge agent to establish the first decision result. After the communication interaction of the edge agent is executed, the first decision result is subjected to conflict game analysis to generate a second decision result. The conflict game analysis is a role evolution conflict game analysis.

2. The large model edge collaborative decision-making method for dynamic scenes according to claim 1, wherein, The conflict game analysis of the first decision result includes: Role modeling is performed on all edge agents, and role modeling results are generated. Execute the conflict perception of the first decision result, fuse the state information and communication interaction data of the edge agent, and establish a global conflict index; The conflict game channel is activated by using the global conflict index, and the role fitness function is called to calculate the role fitness of the edge agent in the current conflict environment, thus generating the role fitness. Based on the aforementioned role fitness, role evolution and reconstruction are performed using a role mutation pool. Based on the role evolution and reconstruction results, game analysis is conducted on the conflict game channel to establish a second decision result.

3. The large model edge collaborative decision-making method for dynamic scenes according to claim 2, wherein, The step of reconstructing character evolution based on the character mutation pool according to the character fitness includes: Based on the aforementioned role fitness, the mutated role is located, and a location result is generated; The location results are synchronized to the character mutation pool, which is a mutated character template constructed based on historical evolution memory; The mutated character templates of the positioning results are matched in the character mutation pool to establish matching results; The matching results are subjected to local evolution simulation based on game task requirements, node resource status, and local topology location. Role evolution reconstruction is completed based on the local evolution simulation results.

4. The large model edge collaborative decision method for dynamic scene as claimed in claim 3, wherein, The game analysis of the conflict game channel based on the role evolution reconstruction results, and the establishment of the second decision result, include: The processing layer of the conflict game channel is invoked to identify role tasks based on the role evolution reconstruction results, and to perform conflict coupling analysis based on the conflict sensitivity index library based on the role tasks to identify task conflict points. Based on the aforementioned task conflict points, a multi-party collaborative agent game analysis is conducted to establish a second decision result.

5. The large model edge co-decision method for dynamic scene as claimed in claim 4, wherein, The agent game analysis based on the task conflict points includes: Obtain the task priority of the edge agent, and establish a first evaluation feature based on the task priority; Obtain the computing resource load information of the edge agent, and establish a second evaluation feature based on the computing resource load information; The average response latency of the edge agent is obtained, and a third evaluation feature is established based on the average response latency. Obtain the collaborative features of the edge agent, and establish a fourth evaluation feature based on the collaborative features; A fitness function is configured based on the first evaluation feature, the second evaluation feature, the third evaluation feature, and the fourth evaluation feature, and the agent game analysis and evaluation are performed based on the fitness function.

6. The large model edge co-decision method for dynamic scene as claimed in claim 1, wherein, The analysis of functional deficiencies in the original monitoring topology based on the activation identifier, and the establishment of the first required data, include: Based on the original monitoring topology, adaptive functional clustering based on communication structure and physical structure is performed, and functional clustering labels are established. The function clustering labels are used to verify the functionality of the activation identifier, and the function time limit verification results are used to complete the function missing analysis in order to establish the first requirement data.

7. The large model edge co-decision method for dynamic scene as claimed in claim 1, wherein, After generating the second decision result, the process includes: Establish a scheduling verification window based on the second decision result; The execution verification of emergency decisions is performed in the scheduling verification window, and node verification results are established. Adaptive decision-making compensation is performed based on the node verification results, and emergency management is carried out based on the adaptive decision-making compensation.

8. The edge collaborative decision-making method for large models in dynamic scenarios as described in claim 1, characterized in that, After the communication interaction of the edge agent is executed, it includes: Based on the results of communication interactions, predict the development of emergency events, and establish decision bias factors based on the development prediction results; After game compensation using the aforementioned decision bias factor for conflict game analysis, a second decision result is generated.

9. The large model edge co-decision method for dynamic scene as claimed in claim 1, wherein, After generating the second decision result, the process further includes: The execution effect of the second decision is read, and the execution effect reading result, the second decision result, and the emergency event are bound together and stored as a decision record; The decision records are used as a reference dataset to implement decision execution compensation for subsequent emergency events.

10. A large model edge collaborative decision system for dynamic scenarios, characterized in that, The system is used to implement the large-model edge collaborative decision-making method for dynamic scenarios according to any one of claims 1-9, the system comprising: The original monitoring topology construction module is used to call the original monitoring nodes of the original scene and build the original monitoring topology after an emergency event occurs. The first requirement data acquisition module is used to verify the communication of the original monitoring node, and then, based on the communication verification result, activate the original monitoring topology, perform a functional loss analysis of the original monitoring topology based on the activation identifier, and establish the first requirement data. The temporary edge agent construction module configures an emergency scenario based on the emergency event, configures second demand data according to the emergency scenario, performs demand analysis on the first demand data and the second demand data, configures temporary edge agents, and configures mobile sensors to form a network of temporary edge agents. The first decision result construction module is used to establish the first decision result after the edge agent reads the monitoring data of the monitoring nodes in the network after the network is successfully formed. The second decision result acquisition module is used to perform conflict game analysis on the first decision result after executing the communication interaction of the edge agent, and generate a second decision result. The conflict game analysis is a role evolution conflict game analysis.

Images