Emergency collaborative decision-making method and device based on dynamic knowledge graph and agent

Abstract

The application discloses an emergency collaborative decision-making method and device based on a dynamic knowledge graph and an intelligent agent, and belongs to the technical field of the cross between artificial intelligence and water conservancy emergency management. The method comprises the following steps: constructing a water conservancy knowledge graph based on multi-source heterogeneous data in the field of water conservancy and establishing a synchronization mechanism; receiving a natural language instruction of a user, performing field adaptive user intention recognition, and decomposing the recognized user intention into a structured task sequence; building an intelligent agent, the intelligent agent receives the task sequence, performs multi-step correlation reasoning and dynamic planning based on the dynamically synchronized water conservancy knowledge graph, autonomously calls a tool library to plan and generate an emergency decision-making scheme; and integrating the decision-making results of the intelligent agent and comprehensively presenting the results in a multi-modal form. The application solves the problems of data islands in traditional water conservancy emergency decision-making, low efficiency of man-machine interaction and reliance on manual decision-making, and improves the response speed, scientificity and reliability of emergency decision-making, and is suitable for the field of water conservancy emergency command and intelligent decision-making support.

Description

Technical Field

[0001] This invention relates to an emergency collaborative decision-making method and device based on dynamic knowledge graphs and intelligent agents, belonging to the interdisciplinary field of artificial intelligence and water conservancy emergency management. Background Technology

[0002] In recent years, global climate change has intensified, and extreme weather events have become more frequent, making emergency events such as floods and droughts faced by water conservancy projects increasingly complex and unpredictable. Traditional water conservancy emergency decision-making mainly relies on human experience and scattered professional models, which suffers from slow response speed, insufficient knowledge integration, and limited scientific rigor in decision-making, making it difficult to meet the high requirements of modern water conservancy emergency management for real-time performance, accuracy, and coordination.

[0003] In existing technologies, water conservancy emergency decision support systems mostly adopt a single data source or a limited model integration approach, lacking unified management and deep integration of multi-source heterogeneous data. Specifically: (1) At the data level, there are serious data barriers between various business systems, and information is fragmented. More importantly, there is a lack of a mechanism to efficiently integrate real-time dynamic data with static domain knowledge, making it difficult to form a unified and vivid global situation view. The decision-making basis is often outdated or incomplete. (2) At the interaction level, the human-computer interaction mode of traditional systems is rigid, and the ability to understand natural language instructions is very limited. It is unable to accurately identify and resolve complex and ambiguous domain professional instructions, resulting in low interaction efficiency and requiring a lot of manpower to translate instructions and operate the system. (3) At the decision-making level, the decision-making process relies heavily on manual interpretation and expert experience, lacking an intelligent core capable of autonomously planning and executing multi-step complex analysis and reasoning tasks. When faced with complex disasters that occur simultaneously at multiple points and evolve rapidly, this model has problems such as response delay, information omission, and suboptimal decision-making, making it difficult to meet the requirements of modern emergency command for high timeliness and high scientificity.

[0004] While knowledge graph technology has been applied to knowledge management in some fields, in water conservancy emergency scenarios, existing implementations are mostly limited to static knowledge bases, lacking real-time data synchronization mechanisms and dynamic update capabilities, thus failing to support the timeliness requirements of emergency decision-making. Meanwhile, intelligent interactive systems based on large-scale language models have made progress in general domains, but when directly applied to specialized fields such as water conservancy emergency response, they suffer from issues such as missing domain knowledge, inaccurate intent recognition, and insufficient professional reasoning capabilities, making it difficult to guarantee the reliability of generated decision solutions. Therefore, there is an urgent need for a collaborative decision-making method and system for water conservancy emergency response that can integrate multi-source heterogeneous data, support dynamic knowledge updates, and possess domain-adaptive intent recognition and agent autonomous decision-making capabilities, in order to improve the efficiency, accuracy, and interpretability of emergency decision-making and fill the gaps in existing technologies. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes an emergency collaborative decision-making method and device based on dynamic knowledge graphs and intelligent agents, which can solve problems such as data silos, low efficiency of human-computer interaction, and reliance on manual decision-making.

[0006] The technical solution adopted by this invention to solve its technical problem is as follows: In a first aspect, the present invention provides an emergency collaborative decision-making method based on dynamic knowledge graphs and intelligent agents, comprising the following steps: Step 1: Construct a water conservancy knowledge graph based on multi-source heterogeneous data in the water conservancy field, and establish a synchronization mechanism for the water conservancy knowledge graph so that when the water conservancy knowledge graph is created or modified, the graph information used for subsequent question-and-answer retrieval is also updated synchronously. Step 2: Receive the user's natural language instructions, and perform domain-adaptive user intent recognition by combining a multi-stage hybrid strategy of retrieval enhancement and generative model inference, and decompose the recognized user intent into a structured task sequence; Step 3: Build an intelligent agent. The intelligent agent receives the task sequence and performs multi-step association reasoning and dynamic planning based on a dynamically synchronized water conservancy knowledge graph. It autonomously calls the tool library to plan and generate emergency decision-making schemes. Step 4: Integrate the decision results of the intelligent agent and present them in a multimodal format that includes geographic information visualization, data charts, and natural language reports.

[0007] As one possible implementation of this embodiment, step 1 includes the following steps: Step 11: Extract water conservancy-related data from multi-source heterogeneous data, including structured data, semi-structured data, and unstructured data; Step 12: Construct a water resources knowledge graph, converting the extracted water resources-related data into entities, attributes, and relationships in the graph; Step 13: Establish a split storage architecture, which includes using a graph database as the main storage engine to store authoritative graph fact data, and constructing a vector index for fast semantic retrieval by vectorizing entity information in the main storage. Step 14: Establish a synchronous update mechanism based on the application programming interface. When entities in the knowledge graph are added, deleted, or modified, ensure that the operation is performed in the main storage first, and update the retrieval index synchronously after the operation is successful, so as to ensure the consistency of information between the two and the authority of the main knowledge base.

[0008] As one possible implementation of this embodiment, in the step of extracting water conservancy-related data from multi-source heterogeneous data... The extraction strategy for structured data is as follows: connect to the water conservancy business relational database through the JDBC interface, read the data of the reservoir, hydrological station and flood control project business tables, map the fields in the table to entity attributes, map the foreign key associations between tables to the relationships between entities, and generate structured data entries containing entity ID, attribute key-value pairs and relationship types. The extraction strategy for semi-structured data is as follows: Subscribe to the IoT message queue through the stream processing framework, receive real-time data in JSON format reported by the sensors, parse out the monitoring point ID, monitoring value, collection time and data status fields, filter abnormal data through preset verification rules, and retain valid data that meets the water conservancy monitoring standards. The extraction strategy for unstructured data is as follows: an information extraction model based on a large language model is adopted to identify "entity-relationship-attribute" triples from water conservancy emergency plans, expert reports, and historical disaster documents. Specifically, water conservancy entities are extracted through named entity recognition, the "reservoir-flood control limit water level" and "flood-affected area" associations are identified through relation extraction, and the feature parameters of entities are obtained through attribute extraction.

[0009] As one possible implementation of this embodiment, step 1 further includes: Step 15: Embed a log module in the synchronization API to record the operation type, entity ID, main storage operation result, index synchronization result, and time consumption information for each synchronization operation, and generate a traceable synchronization log. Step 16: If the main storage operation is successful but the index synchronization fails, the retry mechanism is automatically triggered. If the retry fails, it is marked as "synchronization error" and an alarm is sent. Every day at midnight, the consistency check between the main storage and the index is performed. 1% of the entity IDs are randomly selected to compare the consistency of their attributes and vectors. If they are inconsistent, a full synchronization repair is triggered.

[0010] As one possible implementation of this embodiment, step 2 includes the following steps: Step 21: Build an intent knowledge base offline, establish a standardized intent tagging system, and construct the correspondence between user query text and intent tags; Step 22: Vectorize the user query text and store the generated vector and the corresponding intent tag as metadata in the vector index; Step 23: After receiving the user's instruction online, first vectorize it and perform a similarity search in the vector index to obtain one or more reference cases containing similar query text and corresponding standard intent labels; Step 24: Combine the reference case with the user's original instruction to form an enhanced prompt, and use a large language model to infer based on the prompt to determine the user's final intent; Step 25: Based on the user intent determined by the large language model, decompose it into a sequence of structured tasks that can be executed in subsequent steps.

[0011] As one possible implementation of this embodiment, step 3 includes the following steps: Step 31: Provide the intelligent agent with a tool library containing various types of tools, the types of which include at least: knowledge graph query, water conservancy professional model calculation, data visualization generation, and information sending; Step 32: The agent runs in the loop execution process, and in each loop, it thinks according to the task objective, selects and calls the tools in the tool library; Step 33: Update the agent's internal state based on the results returned by the tool to plan the next action until the task is completed; Step 34: Based on the dynamically synchronized water conservancy knowledge graph, perform multi-step association reasoning and dynamic programming to autonomously generate emergency decision-making solutions; Step 35: When performing knowledge graph queries, a two-stage query reasoning is adopted: first, entity linking is performed, and the natural language entity name is fuzzily matched to the entity ID in the knowledge graph; then, attribute acquisition is performed, and the structured attributes and relationships are obtained based on the entity ID.

[0012] As one possible implementation of this embodiment, the loop execution process of the intelligent agent includes the following stages: Thinking phase: Analyze the current task objective, combine the intermediate results in the internal state, select suitable tools from the tool library, and verify the parameters required by the tools; Action phase: When parameters are complete, the tool is invoked; when parameters are missing, a preceding subtask is generated and inserted into the task queue. Observation phase: Receive the results returned by the receiving tool, or capture call exceptions; Update phase: Store valid results in the intermediate result library, mark task status, and adjust task queue priority.

[0013] As one possible implementation of this embodiment, step 4 includes the following steps: Step 41: Collect geospatial data, statistical data, and conclusive text generated during the execution of the intelligent agent; Step 42: Call the geographic information visualization component to convert the geospatial data into a visualization layer; Step 43: Call the data chart generation component to convert the statistical data into chart format; Step 44: Call the natural language generation model to convert the concluding text into a natural language report; Step 45: On a unified human-computer interaction interface, all generated visualization layers, charts, and natural language reports are displayed comprehensively, providing interactive functions to support decision-makers in conducting in-depth analysis and drill-down.

[0014] As one possible implementation of this embodiment, the data processing rules in the step of collecting geospatial data, statistical data, and conclusive text generated during the execution of the intelligent agent include: Geospatial data processing rules: Convert the latitude and longitude coordinates of the water conservancy entities output by the agent into the CGCS2000 national geodetic coordinate system, and store them as GeoJSON in the format of "entity ID-type-spatial coordinates-attributes", where the attributes include dynamic parameters such as "real-time water level and risk level"; Statistical data processing rules: Time series data are timestamped, missing values ​​are filled in using linear interpolation, outlier data exceeding physical thresholds are removed, and a standardized time series data table is formed; The processing rules for conclusive texts are as follows: Extract the core conclusions of "scheduling measures, risk assessment, and implementation suggestions" from the agent's decision-making scheme, and structure them according to "conclusion type-content-confidence level-data source" to ensure logical consistency with the numerical data.

[0015] Secondly, an emergency collaborative decision-making device based on dynamic knowledge graphs and intelligent agents, provided by embodiments of the present invention, includes: The knowledge graph construction and synchronization module is used to construct a water conservancy knowledge graph based on multi-source heterogeneous data in the water conservancy field, and to establish a synchronization mechanism for the water conservancy knowledge graph so that when the water conservancy knowledge graph is created or modified, the graph information used for subsequent question-and-answer retrieval is also updated synchronously. The intent recognition and task decomposition module is used to receive users' natural language instructions, perform domain-adaptive user intent recognition by combining a multi-stage hybrid strategy of retrieval enhancement and generative model inference, and decompose the recognized user intent into a structured task sequence. The intelligent agent decision-making and planning module is used to build an intelligent agent. The intelligent agent receives a task sequence and performs multi-step correlation reasoning and dynamic planning based on a dynamically synchronized water conservancy knowledge graph. It autonomously calls the tool library to plan and generate emergency decision-making schemes. The multimodal generation and interaction module is used to integrate the decision results of the intelligent agent and present them in a comprehensive manner in a multimodal form that includes geographic information visualization, data charts and natural language reports.

[0016] The beneficial effects of the technical solutions of the embodiments of the present invention are as follows: This invention constructs a dynamic knowledge graph, employs retrieval-enhanced generation technology for intent recognition, and enables intelligent agents to perform multi-step reasoning and planning, ultimately presenting the decision results in a multimodal format. This not only solves the problems of data silos, low human-computer interaction efficiency, and reliance on manual decision-making in traditional water conservancy emergency decision-making, but also meets the high requirements of modern water conservancy emergency management for real-time performance, accuracy, and collaboration. Furthermore, it significantly improves the response speed, scientific rigor, and reliability of emergency decision-making, making it applicable to the fields of water conservancy emergency command and intelligent decision support.

[0017] Compared with the prior art, the present invention has the following significant features: (1) Comprehensive and real-time situational awareness: By constructing a dynamic and synchronized knowledge graph and vector index, scattered multi-source heterogeneous data are integrated into one, and the near real-time update of knowledge is ensured in an event-driven manner. This fundamentally overcomes the problems of data silos and outdated information, and provides a comprehensive, reliable and highly timely situational basis for decision-making.

[0018] (2) Highly efficient and accurate intelligent collaboration: Based on Retrieval Augmentation (RAG) intent recognition technology, it accurately understands complex natural language instructions; combined with the agent's multi-step associative reasoning and dynamic programming capabilities, it realizes an automated process from high-level instructions to specific execution steps. This frees decision-makers from tedious data querying and model operation, transforming them into supervisors and confirmers of decisions, greatly improving the efficiency of human-machine collaboration.

[0019] (3) Significantly improved emergency response timeliness: The automated risk analysis, solution generation and simulation process, especially the efficient reasoning mode of the intelligent agent "first lock the core and then expand the association", combined with the high-performance query of the underlying graph database, greatly shortens the decision cycle from problem proposal to solution generation, and wins valuable time for disaster relief.

[0020] (4) Enhanced scientificity and reliability of decision-making: It integrates dynamically updated domain knowledge, structured reasoning logic of intelligent agents, and scientific computing models called through the tool library to generate decision suggestions with real-time data support, clear logical deduction, and multiple options for comparison. This effectively avoids the one-sidedness that may be caused by relying solely on expert experience and comprehensively improves the scientificity and reliability of decision-making. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating an emergency collaborative decision-making method based on dynamic knowledge graphs and intelligent agents, according to an exemplary embodiment. Figure 2 This is a schematic diagram of the structure of an emergency collaborative decision-making device based on dynamic knowledge graphs and intelligent agents, according to an exemplary embodiment. Figure 3This is a flowchart illustrating the specific process of emergency collaborative decision-making using this invention. Detailed Implementation

[0022] To more clearly illustrate the technical features of the present invention, the present invention will be described in detail below through specific embodiments and in conjunction with the accompanying drawings.

[0023] like Figure 1 As shown in the figure, an emergency collaborative decision-making method based on dynamic knowledge graph and intelligent agent provided by an embodiment of the present invention includes the following steps: Step 1: Construct a water conservancy knowledge graph based on multi-source heterogeneous data in the water conservancy field, and establish a synchronization mechanism for the water conservancy knowledge graph so that when the water conservancy knowledge graph is created or modified, the graph information used for subsequent question-and-answer retrieval is also updated synchronously. Step 2: Receive the user's natural language instructions, and perform domain-adaptive user intent recognition by combining a multi-stage hybrid strategy of retrieval enhancement and generative model inference, and decompose the recognized user intent into a structured task sequence; Step 3: Build an intelligent agent. The intelligent agent receives the task sequence and performs multi-step association reasoning and dynamic planning based on a dynamically synchronized water conservancy knowledge graph. It autonomously calls the tool library to plan and generate emergency decision-making schemes. Step 4: Integrate the decision results of the intelligent agent and present them in a multimodal format that includes geographic information visualization, data charts, and natural language reports.

[0024] As one possible implementation of this embodiment, step 1 includes the following steps: Step 11: Extract water conservancy-related data from multi-source heterogeneous data, including structured data, semi-structured data, and unstructured data; Step 12: Construct a water resources knowledge graph, converting the extracted water resources-related data into entities, attributes, and relationships in the graph; Step 13: Establish a split storage architecture, which includes using a graph database as the main storage engine to store authoritative graph fact data, and constructing a vector index for fast semantic retrieval by vectorizing entity information in the main storage. Step 14: Establish a synchronous update mechanism based on the application programming interface (API). When entities in the knowledge graph are added, deleted, or modified, ensure that the operation is performed in the main storage first, and update the retrieval index synchronously after the operation is successful, so as to ensure the consistency of information between the two and the authority of the main knowledge base.

[0025] As one possible implementation of this embodiment, in the step of extracting water conservancy-related data from multi-source heterogeneous data... The extraction strategy for structured data is as follows: connect to a water conservancy business relational database (including MySQL and PostgreSQL) through a JDBC interface, read business table data such as reservoirs, hydrological stations, and flood control projects, map the fields in the table to entity attributes (such as "reservoir name", "dam height", "year of construction"), map foreign key relationships between tables (such as "reservoir-belonging basin" and "hydrological station-monitoring object") to relationships between entities, and generate structured data entries containing entity IDs, attribute key-value pairs, and relationship types; The extraction strategy for semi-structured data is as follows: Subscribe to IoT message queues (Kafka or RabbitMQ) through a stream processing framework (Flink or Spark Streaming), receive real-time data (including water level, flow rate, and rainfall) in JSON format reported by sensors, parse out the fields of "monitoring point ID", "monitoring value", "collection time" and "data status", filter out abnormal data through preset verification rules (such as water level range of 0-500 meters and data sampling interval ≤ 5 minutes), and retain valid data that meets the water conservancy monitoring standards. The extraction strategy for unstructured data is as follows: an information extraction model based on a large language model (LLaMA or GPT series) is adopted to identify "entity-relationship-attribute" triples from water conservancy emergency plans, expert reports, and historical disaster documents. Specifically, this includes: extracting water conservancy entities such as reservoirs, hydrological stations, and watershed boundaries through named entity recognition (NER); identifying relationships such as "reservoir-flood control limit water level" and "flood-affected area" through relation extraction; and obtaining the characteristic parameters of entities (such as "Nishan Reservoir-total storage capacity-120 million cubic meters") through attribute extraction.

[0026] The water conservancy entities include entities categorized as water conservancy engineering facilities, equipment and sensors, hydrology and water resources, water conservancy professional models, emergency management, spatial geography, and organizations and personnel. The water conservancy engineering facilities entities include: reservoirs (such as the Three Gorges Reservoir and Nishan Reservoir), sluice gates, pumping stations, dikes, river channels / sections, hydrological stations, irrigation areas, and flood storage and detention areas. The equipment and sensor entities include: water level sensors, rain gauges, video monitoring points, and data transmission equipment. The hydrology and water resources entities include: water level (such as "real-time water level"), flow rate (such as "inflow" and "outflow"), precipitation, evaporation... The water resources entities encompass a wide range of elements, from physical facilities, hydrological data, professional models, and emergency resources to spatial location and management entities. These entities form a complete water resources knowledge graph foundation, supporting multi-step reasoning and emergency decision-making by intelligent agents. The water resources professional model entities include: flood evolution models, optimal scheduling models, inflow forecasting models, and water resource allocation models. Emergency management entities include: emergency plans, scheduling plans, early warning information, protection targets (such as "downstream key protection targets"), risk levels, and emergency material reserve points. Spatial geographic entities include: watersheds, administrative divisions, inundation areas (GeoJSON format), and locations of key facilities (such as reservoirs and dams, key towns). Organizational and personnel entities include: water resources management departments, emergency command centers, experts, and on-duty personnel.

[0027] As one possible implementation of this embodiment, the specific steps for constructing the water conservancy knowledge graph include: Assign unique identifiers (such as “Reservoir_Nishan Reservoir_001”) to the extracted water conservancy entities, establish an entity alias mapping table (such as mapping “Three Gorges Dam” to the main entity “Three Gorges Reservoir”) to achieve entity standardization; Unify different expressions of the same attribute into a standard field (e.g., unify "dam crest elevation" and "dam height" into "dam crest elevation"), and unify data units (e.g., unify "meter" and "m" into "meter") to achieve attribute standardization; Based on the ontology of the water conservancy field (including core relationship types such as "belonging", "monitoring", "impact", and "dispatch"), the extracted relationships are mapped to a predefined relationship system to form triple data containing entities, attributes, and relationships (in the format of <head entity, relationship, tail entity> or <entity, attribute, attribute value>), thus realizing the relationship definition.

[0028] As one possible implementation of this embodiment, the specific steps for establishing the split storage architecture include: Using a distributed graph database (NebulaGraph or Neo4j Enterprise) as the main storage engine, the triple data is imported in the format of "node table" (containing entity ID, type, and attributes) and "edge table" (containing relation ID, head entity ID, tail entity ID, and relation type) through the graph database batch import tool (Nebula Exchange or Neo4j Import Tool), forming an authoritative knowledge base that supports complex relational queries; The system calls upon a vector encoding model optimized for the water conservancy field (BGE-M3 or Sentence-BERT) to vectorize the "type + core attribute" text of each entity in the main storage (e.g., "Reservoir: Name = Nishan Reservoir, Location = Shandong Province, Flood Control Limit Water Level = 150 meters"), generating 768-dimensional or 1024-dimensional vectors. Based on the generated vectors, a Milvus or FAISS vector index is constructed to establish a mapping relationship of "vector-entity ID-attribute summary" to support semantic similarity retrieval.

[0029] As one possible implementation of this embodiment, in the synchronous update mechanism... The synchronization logic for adding new entities is as follows: When a new water conservancy entity is added, the synchronization API first calls the INSERT interface of the main storage to write the entity node and its association relationship; after the main storage returns a "successful addition" response, the API automatically triggers the vector encoding model to generate the vector of the entity, calls the index interface to insert "vector + entity ID + attribute summary" into the vector index, and updates the index metadata (such as the number of vectors and the last update time). The synchronization logic for entity deletion is as follows: When deleting a water conservancy entity, the synchronization API first calls the DELETE interface of the main storage to delete the target entity node and all related relationships; after the main storage returns a "deletion successful" response, the API performs an exact match query in the vector index based on the entity ID and deletes the corresponding vector record; if the vector index is a non-dynamic index (such as FAISS's IVF index), then the vector data of non-deleted entities are selected and retained, and the index fragments are rebuilt to maintain query efficiency; The synchronization logic for entity modifications is as follows: When an entity attribute is modified (such as updating the real-time water level of a reservoir), the synchronization API first calls the UPDATE interface of the main storage to update the specified attribute value of the target entity; after the main storage returns a "modification successful" response, the API regenerates the "type + core attribute" text of the entity and calls the vector encoding model to generate a new vector, deletes the old vector record in the vector index and inserts the new vector to ensure that the vector is consistent with the latest attribute of the entity.

[0030] As one possible implementation of this embodiment, step 1 further includes: Step 15: Embed a log module in the synchronization API to record information such as "operation type (add / delete / modify), entity ID, main storage operation result, index synchronization result, and time consumption" for each synchronization operation, and generate a traceable synchronization log. Step 16: If the main storage operation is successful but the index synchronization fails, the retry mechanism is automatically triggered (up to 3 retries). If the retry fails, it is marked as "synchronization error" and an alarm is sent. Every day at midnight, the consistency check between the main storage and the index is performed. 1% of the entity IDs are randomly selected to compare the consistency of their attributes and vectors. If they are inconsistent, a full synchronization repair is triggered.

[0031] As one possible implementation of this embodiment, step 2 includes the following steps: Step 21: Build an intent knowledge base offline, establish a standardized intent tagging system, and construct the correspondence between user query text and intent tags; Step 22: Vectorize the user query text and store the generated vector and the corresponding intent tag as metadata in the vector index; Step 23: After receiving the user's instruction online, first vectorize it and perform a similarity search in the vector index to obtain one or more reference cases containing similar query text and corresponding standard intent labels; Step 24: Combine the reference case with the user's original instruction to form an enhanced prompt, and use a large language model to infer based on the prompt to determine the user's final intent; Step 25: Based on the user intent determined by the large language model, decompose it into a sequence of structured tasks that can be executed in subsequent steps.

[0032] As one possible implementation of this embodiment, in the step of offline construction of the intent knowledge base, the standardized intent tagging system adopts a three-level structured naming rule of "domain-action-object", specifically including: Domain level: Limited to water conservancy emergency scenarios, including sub-domains such as "hydrology", "flood control", and "emergency dispatch". Action hierarchy: Defines the core operations within this domain, such as "query", "generate", "notify", and "simulate". Object level: Clearly defines the specific water conservancy entity or data that performs the action, such as "water_level", "dispatch_plan", and "risk_area". The overall format of the tags is "domain.action.object" (such as "hydrology.query.water_level" or "emergency_dispatch.generate.plan"), ensuring that the tags are deeply linked to water conservancy emergency response operations.

[0033] As one possible implementation of this embodiment, the specific method for constructing the correspondence between user query text and intent tags in the offline construction of the intent knowledge base step is as follows: Collect seed query texts in the water conservancy field (each tag corresponds to 50-100 seed texts, such as "query reservoir real-time water level" corresponding to the tag "hydrology.query.water_level"). A large language model is used for domain-specific synonym rewriting, generating 20-50 synonymous questions for each seed text, while retaining water conservancy-specific terms such as "flood limit water level" and "discharge flow" during the rewriting process; Manual annotation and verification, screening, and confirmation of the original meaning. Figure 1 Enhanced text with ≥90% consistency is used to form a "query text - intent label" mapping dataset to ensure the accuracy of the mapping relationship.

[0034] As one possible implementation of this embodiment, the step of vectorizing the user query text employs a vector coding model optimized for the water conservancy field, specifically including: The basic model is either BGE-M3 or Sentence-BERT, and it is fine-tuned for the domain using a water conservancy emergency corpus (including emergency plans, historical Q&A, and business documents). Vectorized input is a combination of "query text + intent label" (e.g., "query water level of Nishan Reservoir hydrology.query.water_level"), which enhances the discriminative power of vectors for domain intents; The generated vectors are 768 or 1024 dimensional and are processed using L2 normalization to ensure that semantically similar query texts in the vector space are closer together.

[0035] As one possible implementation of this embodiment, the vector index is constructed using a hybrid storage strategy: Vector data is stored in Milvus or FAISS vector databases, and IVF_FLAT or HNSW index structures are established to support millisecond-level similarity retrieval. Metadata (including raw query text, intent tags, and domain classification) is stored in a relational database and associated with the vector database through a unique text ID; The index is optimized regularly (every 24 hours) by merging semantically repetitive vectors through clustering algorithms and removing noisy data (such as isolated vectors with similarity ≤ 0.3) to improve retrieval efficiency.

[0036] As one possible implementation of this embodiment, in the similarity retrieval step after receiving the user instruction online, the retrieval strategy is as follows: Set the similarity threshold to 0.7-0.8 (based on cosine similarity calculation), and return the top-3 to top-5 similar query texts and their corresponding intent tags; If multiple intent tags exist in the search results, sort them by the frequency of occurrence of the tags, and use the tag with the highest frequency as the candidate intent graph; When no search results meet the threshold (zero-sample scenario), a fallback mechanism is automatically triggered, returning a list of high-frequency intent tags in the domain (such as "hydrology.query.water_level" and "emergency_dispatch.generate.plan") as a reference.

[0037] As one possible implementation of this embodiment, the structured components of the enhanced prompt include: Role definition: "You are an expert in water conservancy emergency intent recognition, and you must strictly determine the intent of user commands based on knowledge in the field of water conservancy." Reference Cases Section: Search results are listed in the format of "Similar Query Text: [Text Content] → Intent Tag: [Tag] (Similarity: [Value])"; User instruction area: clearly marked "User instruction: [Original input text]"; Output constraints: "Output only 1-3 intent labels for water conservancy emergency response, in the format of [label1, label2, ...], and the labels must be selected from the preset label system"; Structured prompts help prevent the model from generating irrelevant intents or non-standardized labels.

[0038] As one possible implementation of this embodiment, step 3 includes the following steps: Step 31: Provide the intelligent agent with a tool library containing various types of tools, the types of which include at least: knowledge graph query, water conservancy professional model calculation, data visualization generation, and information sending; Step 32: The agent runs in the loop execution process, and in each loop, it thinks according to the task objective, selects and calls the tools in the tool library; Step 33: Update the agent's internal state based on the results returned by the tool to plan the next action until the task is completed; Step 34: Based on the dynamically synchronized water conservancy knowledge graph, perform multi-step association reasoning and dynamic programming to autonomously generate emergency decision-making solutions; Step 35: When performing knowledge graph queries, a two-stage query reasoning is adopted: first, entity linking is performed, and the natural language entity name is fuzzily matched to the unique entity ID in the knowledge graph; then, attribute acquisition is performed, and the structured attributes and relationships are obtained based on the entity ID.

[0039] As one possible implementation of this embodiment, the technical features of each tool in the tool library are as follows: Knowledge graph query tool: Encapsulates a graph database query interface (supports nGQL / Cypher statements), with input parameters being "entity ID / attribute conditions / relationship type", and outputting JSON format results, including entity attributes (e.g., "Reservoir_1001: {water level: 152m, flood limit water level: 150m}") and relationships (e.g., "Reservoir_1001-downstream protection-town_2001"). Water conservancy professional model calculation tool: includes inflow forecast model, flood evolution model, and reservoir optimal scheduling model. The input parameters are "basin characteristic parameters (from knowledge graph) + real-time monitoring data (water level / rainfall)" and the outputs are "flow process line, water level forecast curve, and scheduling scheme time series table". Data visualization generation tool: Supports converting time series data into a joint trend chart of "water level-flow", converting spatial data into GIS layers, outputting SVG / GeoJSON format, and annotating key indicators such as flood control thresholds; Information sending tool: integrates SMS and flood control command platform interfaces. The input parameters are "recipient ID (from knowledge graph contact database) + message content", and it returns a sending status receipt.

[0040] As one possible implementation of this embodiment, the loop execution process of the intelligent agent includes the following stages: Thinking phase: Analyze the current task objective (e.g., "generate Nishan Reservoir scheduling plan"), combine the intermediate results in the internal state, select suitable tools from the tool library (e.g., "need to call flood evolution model + scheduling model"), and verify the parameters required by the tools (e.g., "missing precipitation data for the next 24 hours"). Action phase: When all parameters are complete, the tool is invoked (entering parameters such as entity ID and time range); when parameters are missing, a preceding subtask (such as "query future precipitation forecast") is generated and inserted into the task queue. Observation phase: Receive the results returned by the receiving tool (such as the outflow sequence output by the model), or capture call exceptions (such as model timeout); Update phase: Store valid results in the intermediate result library, mark task status ("complete / pending retry"), and adjust task queue priority.

[0041] As one possible implementation of this embodiment, the internal state of the intelligent agent includes: Task queue: Sort by "dependency priority + creation time" and stores tasks to be executed (including task_id, target, parameters, and dependency list). Intermediate Results Repository: The results are returned by a structured storage tool based on "Task ID-Data Type-Value-Timestamp" and can be retrieved by entity ID / time range; Inference Log: Records "the reasons for tool selection (e.g., "calling the scheduling model to generate a leak solution as needed"), parameter passing process, and result evaluation" for decision traceability; Knowledge graph version identifier: Records the snapshot ID of the currently associated knowledge graph to ensure that inference is based on the latest synchronized data.

[0042] As one possible implementation of this embodiment, the specific logic of the multi-step association reasoning is as follows: Entity-based reasoning expands from task entities (such as "Nishan Reservoir") to related entities (such as "Nishan Hydrological Station" and "Sihe River Basin") based on the relationship between "reservoir-hydrological station-watershed" in the knowledge graph. Attribute-linked reasoning integrates and extends the dynamic attributes (such as "real-time rainfall at hydrological stations") and static attributes (such as "catchment area of ​​watershed") of entities to form a set of decision parameters. Constraint verification reasoning verifies whether the parameters conform to the domain rules in the knowledge graph (such as "discharge flow ≤ river flood capacity"). If a violation occurs, a parameter adjustment subtask is triggered.

[0043] As one possible implementation of this embodiment, the dynamic programming implementation strategy is as follows: Short-term plan: For emergency tasks lasting 1-6 hours, a greedy algorithm will be used to prioritize critical sub-tasks (such as "prioritizing the acquisition of real-time water level data"). Mid-term plan: For scheduling tasks that take 1-3 days, use dynamic programming algorithm to optimize scheduling timing (such as the phased adjustment plan for outgoing traffic). Conflict handling: When multiple tasks compete for the same resource (such as calling the same model at the same time), they are queued according to task priority (levels 1-5). High-priority tasks can interrupt low-priority tasks and reuse intermediate results.

[0044] As one possible implementation of this embodiment, the technical details of the two-stage query reasoning are as follows: Entity linking stage: Vectorize the natural language entity name (e.g., "Nishan Reservoir"), perform Top-1 similarity retrieval (threshold ≥ 0.85) in the knowledge graph vector index, and match the unique entity ID (e.g., "Reservoir_1001"); if multiple entities are retrieved (e.g., "Nishan Reservoir" and "Nishan Power Station"), generate an entity confirmation request (e.g., "Please confirm if you are referring to Nishan Reservoir?"). Attribute Acquisition Stage: Based on the entity ID, the knowledge graph query tool is called to retrieve data in the priority order of "static attributes (dam height / reservoir capacity) → dynamic attributes (real-time water level / flow rate) → association (downstream towns / flood control projects)". The results are formatted as "attribute type-value-update time".

[0045] As one possible implementation of this embodiment, the calling logic of the water conservancy professional model calculation tool is as follows: Model selection: Automatically match the model based on the task type (e.g., select "Flood Evolution Model" for the "Flood Warning" task); Parameter injection: Obtain "basin characteristic parameters (fixed values)" from the knowledge graph and "real-time monitoring data (dynamic values)" from the intermediate results library, and automatically populate the model input parameter table; Iterative calculation: If the model output exceeds the knowledge graph constraint range (such as water level exceeding historical extreme value), the sensitive parameters (such as roughness coefficient ±10%) are automatically adjusted and recalculated, with a maximum of 3 iterations.

[0046] As one possible implementation of this embodiment, the rules for generating the emergency decision-making scheme include: Content structure: Includes "basic data summary (water level / flow rate), scheduling measures (time-segmented release plan), risk assessment (predicted inundation area), and implementation recommendations"; Data source annotation: The source of each value must be indicated (e.g., "real-time water level 152m (knowledge graph, updated at 10:30)"). Priority ranking: When multiple feasible solutions are generated, they are ranked according to "risk reduction rate (weight 60%) + implementation cost (weight 40%)", and the optimal solution is recommended.

[0047] As one possible implementation of this embodiment, the tool selection mechanism in the thinking phase adopts a hybrid decision-making strategy: Rule priority: For standardized tasks (such as "querying water level"), the knowledge graph query tool is directly invoked according to preset rules; Model-assisted: For complex tasks (such as "cross-basin flood risk assessment"), a reinforcement learning model (trained on historical task-tool matching cases) is invoked to recommend tool combinations; Feedback optimization: Record the success rate of tool calls. If a tool fails 3 times in a row, automatically switch to the alternative tool (e.g., "Switch to model B when flood evolution model A fails").

[0048] As one possible implementation of this embodiment, step 4 includes the following steps: Step 41: Collect geospatial data, statistical data, and conclusive text generated during the execution of the intelligent agent; Step 42: Call the geographic information visualization component to convert the geospatial data into a visualization layer; Step 43: Call the data chart generation component to convert the statistical data into chart format; Step 44: Call the natural language generation model to convert the concluding text into a natural language report; Step 45: On a unified human-computer interaction interface, all generated visualization layers, charts, and natural language reports are displayed comprehensively, providing interactive functions to support decision-makers in conducting in-depth analysis and drill-down.

[0049] As one possible implementation of this embodiment, the data processing rules in the step of collecting geospatial data, statistical data, and conclusive text generated during the execution of the intelligent agent include: Geospatial data processing rules: Convert the latitude and longitude coordinates of water conservancy entities (reservoirs, hydrological stations, watershed boundaries) output by the intelligent agent into the CGCS2000 national geodetic coordinate system, and store them as GeoJSON in the format of "entity ID-type-spatial coordinates-attributes". The attributes include dynamic parameters such as "real-time water level and risk level". Statistical data processing rules: Time series data (inflow, water level change, rainfall) are timestamped (accurate to the minute level), missing values ​​are filled in using linear interpolation, and abnormal data exceeding physical thresholds (such as water level ≤ 0) are removed to form a standardized time series data table; The processing rules for conclusive texts are as follows: core conclusions such as "scheduling measures, risk assessment, and implementation suggestions" are extracted from the agent's decision-making scheme and structured according to "conclusion type-content-confidence level-data source" to ensure logical consistency with numerical data (such as the safety threshold in the chart corresponding to "water level control target").

[0050] As one possible implementation of this embodiment, the functions of the geographic information visualization component include: Basic layer rendering: Loads the watershed electronic base map (including rivers, administrative divisions, and topographic elevation), supporting scaling (1:1000 to 1:100000 scale), panning, and rotation operations; Entity labeling: Differentiated icons (blue circles for reservoirs, yellow triangles for hydrological stations) and color coding (green → red for increasing risk) are used to label entities. When the mouse hovers over an entity, an attribute pop-up window is displayed (including "entity name, real-time water level, and difference from warning value"). Dynamic process simulation: Based on the results of the flood evolution model, the changes in the inundation range in the next 24 / 48 hours are dynamically demonstrated in the layer, and semi-transparent color blocks are overlaid to display the changes. The transparency of the color blocks corresponds to the probability of inundation (the lower the transparency, the higher the probability).

[0051] As one possible implementation of this embodiment, the chart types and generation rules supported by the data chart generation component are as follows: Time series composite chart: It integrates three types of data, namely "inflow, outflow, and reservoir water level", into a dual-axis chart (the left axis is the flow rate in m³ / s, and the right axis is the water level in m). The horizontal axis of time supports switching between hourly and daily granularity, and the flood control limit water level is marked with a red dashed line. Comparison bar chart: Shows the comparison between "current data and historical data of the same period" and "risk values ​​before and after implementation of the plan". Items with significant differences (difference ≥ 30%) are highlighted in orange. Heatmap: Presents the influence relationship between "reservoir and downstream town" in matrix form, with cell color depth indicating influence weight (such as the correlation of flood risk). All charts support hovering over data points to view details, selecting a region to zoom in, and exporting to PNG / Excel format.

[0052] As one possible implementation of this embodiment, the structured specifications for the natural language generation model's generated report include: Fixed framework: It includes 5 chapters: "Decision Background (Disaster Overview), Data Basis (Key Indicators), Dispatch Measures (Time-Segmented Plans), Expected Results (Risk Reduction Rate), and Emergency Recommendations"; Terminology standardization: Adopt standard water conservancy industry terminology (such as "flood control level", "pre-discharge", "flood discharge capacity") to avoid vague expressions (unify "water release" as "discharge flow"); Data citation: Each quantitative conclusion must be marked with its source (e.g., "According to knowledge graph data, the current water level is 152.3m, exceeding the flood limit by 2.3m"), and key values ​​should be highlighted in bold.

[0053] As one possible implementation of this embodiment, the layout design of the unified human-computer interaction interface is as follows: Top navigation area: Includes function buttons for "Solution Overview, Data Details, Historical Comparison, Export & Print", allowing users to quickly switch between operations; Main display area: occupies 70% of the interface area, and displays data charts by default. You can switch to the geographic information layer or the full report via tabs. Side information area: divided into "Core Indicator Card" (real-time water level, risk level, dispatching recommendations) and "Related Entity List" (downstream towns, related reservoirs), which can be clicked to jump to the corresponding details; Bottom interactive area: Includes "Parameter Adjustment", "Regenerate", and "Confirm Execution" buttons to receive user operation commands.

[0054] As one possible implementation of this embodiment, the interactive function includes a multimodal linkage mechanism: Chart-Map Linkage: Clicking on the water level data at a specific time point in the time series chart will automatically locate the corresponding reservoir in the geographic layer, highlighting the risk spread range for that period; Report-Chart Linkage: When the "Pre-release 48 Hours" section is selected in the report, the data chart will automatically enlarge to display the corresponding 48-hour flow change curve and be labeled "Pre-release Execution Period"; Map-Report Linkage: When a downstream town is selected on the geographic layer, the side report automatically scrolls to the risk assessment section for that town, simultaneously displaying protection measure recommendations.

[0055] As one possible implementation of this embodiment, the geographic information visualization component also supports custom layer management: Layer control: Provides toggles for layers such as "base map, entity distribution, risk warning, and scheduling measures," which users can show / hide as needed; Symbol configuration: Allows adjustment of entity icon size (based on entity importance) and risk color threshold (e.g., adjusting the high-risk threshold from 150m to 148m); Labeling settings: Supports showing / hiding entity attribute labels (e.g., only showing "reservoir name + real-time water level") to avoid overloading layer information.

[0056] As one possible implementation of this embodiment, the natural language generation model also has adaptive adjustment capabilities: Length adaptation: The report detail is automatically adjusted according to the user role (commander / technician) (commander version ≤ 500 words, technician version ≥ 1000 words). Highlighting key points: For high-risk scenarios (such as risk level ≥ orange), add an "Emergency Notice" section at the beginning of the report, highlighting the core response measures in red font; Multilingual support: It can generate bilingual reports in Chinese and English to meet the needs of cross-departmental collaboration, and the terminology translation conforms to the standard translation method of the water conservancy industry.

[0057] As one possible implementation of this embodiment, the unified human-computer interaction interface also includes a decision tracing function: Process replay: Records key decision-making nodes of the intelligent agent (tool calls, parameter adjustments, scheme generation), and supports replaying the multimodal data changes of each node along the timeline; Version Comparison: When the solution is iterated and optimized, historical versions are automatically saved, and it is possible to compare the differences in chart data, map risk areas, and report conclusions between different versions; Log Export: Can export audit logs containing "interaction operation records, data change trajectories, and decision basis chains" in PDF or JSON format.

[0058] As one possible implementation of this embodiment, the data chart generation component also supports the annotation and interpretation of abnormal data: Anomaly labeling: When the data exceeds the normal range (e.g., a sudden increase in water level ≥ 2 m / h), mark it with a red star on the chart and add the message "Data anomaly: Possible sensor malfunction"; Cause tracing: Clicking the anomaly marker will automatically display the anomaly cause analysis (combining historical data from the knowledge graph and real-time operating conditions), such as "Compared with the same period in history, the water level increase during this period is abnormal, and it is recommended to check the sensors"; Correction suggestion: Provide data correction options (such as "use data interpolation from adjacent hydrological stations to replace"), and automatically update all related charts and reports after correction.

[0059] As one possible implementation of this embodiment, step 5 includes the following steps: like Figure 2 As shown in the figure, an emergency collaborative decision-making device based on dynamic knowledge graph and intelligent agent provided by an embodiment of the present invention includes: The knowledge graph construction and synchronization module is used to construct a water conservancy knowledge graph based on multi-source heterogeneous data in the water conservancy field, and to establish a synchronization mechanism for the water conservancy knowledge graph so that when the water conservancy knowledge graph is created or modified, the graph information used for subsequent question-and-answer retrieval is also updated synchronously. The intent recognition and task decomposition module is used to receive users' natural language instructions, perform domain-adaptive user intent recognition by combining a multi-stage hybrid strategy of retrieval enhancement and generative model inference, and decompose the recognized user intent into a structured task sequence. The intelligent agent decision-making and planning module is used to build an intelligent agent. The intelligent agent receives a task sequence and performs multi-step correlation reasoning and dynamic planning based on a dynamically synchronized water conservancy knowledge graph. It autonomously calls the tool library to plan and generate emergency decision-making schemes. The multimodal generation and interaction module is used to integrate the decision results of the intelligent agent and present them in a comprehensive manner in a multimodal form that includes geographic information visualization, data charts and natural language reports.

[0060] like Figure 3 As shown, the specific implementation process of water conservancy emergency collaborative decision-making using the scheme described in this invention is as follows.

[0061] S1. Construct and dynamically synchronize knowledge graph information. The core task of step S1 is to transform multi-source heterogeneous data into graph-based knowledge and construct a system that supports efficient retrieval and can be dynamically synchronized with the core knowledge graph.

[0062] (1) Data source processing: Data sources in the field of water conservancy emergency response are mainly divided into three categories, which require different technical approaches for processing: a. Structured data: Source: Relational databases (such as MySQL) used in business systems; Method: Develop a data processing module to connect to the source database. Map rows in the table to points in the graph, and map foreign key associations to edges. Output: Generates CSV files containing the points and edges, such as vertex_stru.csv and edge_stru.csv; b. Semi-structured data: Source: Sensor data and log files reported by IoT devices; Method: Build a stream processing application that subscribes to real-time data streams from message queues such as Kafka; after parsing and verifying each message, directly call the real-time dynamic synchronization API defined later in this embodiment; this API will complete two core tasks: updating the core knowledge base and synchronizing the retrieval index; in this way, ensure that the data of the two systems remain consistent in real time; Output: No intermediate CSV files are generated; data is written to and synchronized to all relevant storage in real time. c. Unstructured data: Sources: Emergency response plan documents, expert reports, historical records, etc.; Methods: An information extraction module is constructed, and entity and relation triples are extracted from the text using a large language model through prompt word engineering; Output: Generates new vertex and edge CSV files, vertex_unstru.csv and edge_stru.csv.

[0063] This invention adopts a two-stage architecture that separates the main storage (NebulaGraph) and the retrieval index (LlamaIndex VectorStoreIndex); all operations follow the principle of updating the main storage first and then synchronizing to the retrieval index to ensure data consistency and authority.

[0064] (2) Storage and updates.

[0065] a. Initial storage process: When the system first builds or reconstructs the knowledge graph, it calls the / index / build interface to perform the following operations: Using the Nebula Exchange tool, all CSV files generated after the structured and unstructured data processing in step 1 are read, and massive amounts of data are efficiently loaded into the NebulaGraph database in a high-throughput, parallel manner. Connect to the NebulaGraph graph database that has just been populated with data, pull all entity, relationship and attribute data in batches, build a complete LlamaIndex VectorStoreIndex retrieval index in memory, and persist it to the local disk for use by subsequent retrieval services; b. Implementation mechanism and algorithm for incremental synchronization in the later stage: For incremental updates to the system (whether from real-time data streams from the Internet of Things or in response to online user actions), all are executed through a unified real-time synchronization API to ensure data consistency between the main storage and the retrieval index. The core of the dynamic knowledge graph synchronization mechanism described in this invention is to ensure data consistency between the graph database main storage (main storage), which serves as the authoritative data source, and the local vector retrieval index (retrieval index), used for fast semantic retrieval. This embodiment provides a complete implementation scheme including API interfaces, a synchronization control module, and specific execution algorithms.

[0066] This invention adopts a modular system architecture, and the synchronization mechanism consists of the following core modules: Synchronous API Interface Layer: Implemented based on a web framework (such as FastAPI), it provides a set of standardized RESTful API endpoints (such as / sync / add, / sync / update, / sync / delete) to receive synchronization commands triggered by external systems (such as the database management platform). Synchronization Control Module (MultiSpaceGraphAgent): As a central coordinator, it is responsible for managing index instances of one or more knowledge graph spaces; it receives requests from the API layer and distributes them to the index managers of the corresponding knowledge graph spaces; The index management module (VectorIndexManager) is responsible for the lifecycle management of vector indexes within a single knowledge graph space. It encapsulates the interaction with the main storage, the transformation of node data, and atomic operations such as adding, deleting, modifying, and querying retrieval indexes (e.g., VectorStoreIndex of LlamaIndex). The data acquisition and transformation module (_fetch_nodes_as_documents) is responsible for connecting to the main storage based on the specified node ID, executing a graph query language (such as nGQL), obtaining the latest attribute data of the node, and converting it into a semi-structured text Document object suitable for vectorization.

[0067] This invention employs the following core synchronization algorithm: 1) Algorithm for node data acquisition and document conversion: This algorithm is the basis for all synchronization operations, ensuring that the data used for indexing always comes from the latest state of the main storage; 11) Input: A list of one or more node IDs; 12) Process: The index management module establishes a connection with the graph database main storage; Construct a graph query statement to accurately retrieve all properties and labels of the nodes corresponding to the input ID list. Execute the query and iterate through the result set; for each returned node data, perform the following transformation operations: Extract core information from nodes, such as "entity type" and "attribute set"; Parse a structured collection of attributes (usually in JSON format) into multiple key-value pairs; According to the preset text template, each key-value pair is converted into a natural language description. The template used in this embodiment is: "{entity type}'s {attribute name} is {attribute value}". Combine the descriptions of all attributes with the entity type itself into a coherent and informative text summary; The generated text summary and node metadata (including the original node_id, label, etc.) are encapsulated together into a standardized Document object; 13) Output: A list of Document objects, each representing a node information retrieved from and transformed from the main storage.

[0068] 2) Incremental synchronization operation algorithm: 21) New node synchronization algorithm (implementation of / sync / add): Input: The ID of the single or batch node to be added.

[0069] process: When the API interface receives a request, it calls the synchronization control module and passes the node ID. The index management module executes the "node data acquisition and document transformation algorithm" to retrieve the Document object of the new node from the main storage; If no node is found, an error is returned and the operation is terminated; Call the insert method of the retrieved index to embed the new Document object into the existing vector index; Call the persist method of the retrieved index to write the updated index state in memory to the local disk file. 22) Node deletion synchronization algorithm (implementation of / sync / delete): Input: The ID of a single or batch of nodes to be deleted; process: The API interface receives requests and distributes them to the index management module; The index management module first reads all existing Document objects from the currently loaded index into memory; Iterate through the list of Document objects in memory, filter them according to their node_id in their metadata, and keep all objects whose IDs are not in the list to be deleted, forming a "to be kept" list; The index management module performs file system-level deletion operations to completely remove the old index file directory from the local disk. If the "to be retained" list is not empty, the module takes that list as input and builds a new, clean vector index from scratch. Persist this newly built index to the original disk location; 23) Update node synchronization algorithm (implementation of / sync / update): Input: The ID of the single node to be updated.

[0070] process: The API interface receives requests and distributes them to the index management module; The index management module first calls the "delete node synchronization algorithm" to completely remove the old information corresponding to the node ID from the search index; Immediately afterwards, the module invokes the "new node synchronization algorithm" to retrieve the latest data from the main storage with the same node ID and add it as a new node to the retrieval index.

[0071] S2. Perform domain-adaptive intent recognition. The core of step S2 is to use an advanced method based on retrieval-enhanced generation to accurately parse the user's fuzzy natural language instructions into a unique, structured task that the system can execute.

[0072] The implementation of this method includes two stages: offline intent knowledge base construction and online recognition and reasoning. (1) Offline construction of intent knowledge base: a. Define standard intent labels: First, a set of standardized, unique, and machine-readable standard intent labels are predefined within the system. These labels use a structured naming convention (e.g., domain.action.object, query.hydrology.water_level), and each label precisely corresponds to a specific function or workflow of the system. Its core function is to act as a unique instruction code; once any ambiguous question from the user is identified and mapped to this unique label, the system backend can, like calling a function, precisely trigger a predefined, fixed business process or task template based on this label. b. Construction of the intent corpus: For each standard intent tag, a batch of "seed query" samples were collected, and data augmentation was performed using a large language model (LLM) to generate a large number of synonymous question samples covering multiple expressions; This move aims to significantly improve the accuracy and robustness of intent recognition, ensuring the system can understand the ever-changing ways users ask questions; examples are as follows: Standard intent label: query.hydrology.water_level; Seed query: "Query the real-time water level of the Three Gorges Reservoir"; Enhanced synonymous question samples: "What is the current water level of the Three Gorges Reservoir?", "I would like to know the current water situation of the Three Gorges Reservoir", "Where is the water level of the Three Gorges Reservoir?", "Please report the water level of the Three Gorges Reservoir for me"; c. Constructing vector indexes: Text vectorization: Traverse the intent knowledge base and extract only the "user query text" part of each (user query text, standard intent label) correspondence; use a text vectorization model (such as bge-m3, etc.) to convert these texts into high-dimensional mathematical vectors one by one; Indexing and metadata storage: The generated vectors are stored in a dedicated vector database (such as FAISS or Milvus); when storing each vector, the original text of the vector and its corresponding "standard intent label" must be stored together with the vector as metadata.

[0073] (2) Online search enhancement intent determination: This process employs a two-stage Large Language Model (LLM) invocation strategy, clearly decoupling intent determination from task decomposition to improve the stability and accuracy of the entire process. For example, consider the user command "I want to know the current water level of Nishan Reservoir and generate a scheduling plan for me": a. First stage: Determining the intent for enhanced retrieval: Similar intent retrieval: The system first vectorizes the user's command and performs a similarity search in the vector database to retrieve reference cases that are highly related to both the intents of "querying water level" and "generating contingency plan". Intent determination prompt construction and execution: The system dynamically constructs a structured enhanced prompt, which includes four parts: role and task instructions, a list of optional intent labels, retrieved reference cases, and the current user's instructions. Through this prompt, LLM can accurately determine the user's complex intent and is constrained to output a formatted list of intent labels, such as: ["query.hydrology.water_level","generate.dispatch.plan"]; b. Second phase: Intent-based task decomposition: Task decomposition prompt construction and execution: After successfully obtaining and verifying the intent label list, the system will construct a second prompt and call LLM again; the task of this prompt is no longer classification, but planning; the prompt mainly consists of: the user's original instruction, the intent label list determined in the first stage, and the explicit instructions for task decomposition. Task identification and dependency analysis: Based on the context of the second prompt, LLM can recognize that this is a composite task, and that "generating a scheduling plan" logically depends on the query result of "current water level" as input; therefore, it will generate a task sequence with a sequential order and dependencies. c. Robust design of the system: To improve system reliability, the present invention also includes the following design: Zero-shot backoff mechanism: If vector retrieval fails to find any similar reference cases, the system will construct a hint that does not contain a "reference case area", causing LLM to enter "zero-shot" mode for intent determination, in order to ensure the ability to handle new question types; Ambiguity handling mechanism: When the user's instruction is very ambiguous, the system can be designed to generate a clarifying question to return to the user (e.g., "Do you want to query information or generate a plan?") to improve the efficiency and accuracy of human-computer interaction.

[0074] (3) Final output: Structured task sequence: After the online identification and decomposition process described above, the system will finally generate a structured task sequence JSON object as the final output of this step; taking the above example as an example, the JSON object is as follows: { "user_intent":["query.hydrology.water_level","generate.dispatch.plan"], "task_sequence": [ { "task_id": 1, "task_name": "Query knowledge graph" "parameters": { "entity_name": "Nishan Reservoir" "attributes": ["real-time water level"], } }, { "task_id": 2, "task_name": "Generate scheduling plan" "parameters": { "entity_name": "Nishan Reservoir" }, "dependencies": [1], } ] }

[0075] S3. Decision-making and planning by an intelligent agent. Step S3 is executed by an autonomous intelligent agent, which is the core of the system's decision-making and execution. It receives the structured task sequence generated by module S2, and through reasoning, planning, and autonomous invocation of tools, ultimately formulates a decision plan.

[0076] (1) Tool library definition: The capabilities of an agent are defined by its callable tool library; the system provides agents with a set of extensible, well-defined, and powerful API-based tools; each tool includes its functional description and the definitions of the parameters required for execution; the following are some examples of the core tools included in this tool library: a. Knowledge graph query tool: knowledge_graph_query(entity: str, attributes: List[str]) -> Dict; its function is to query the attributes of a specified entity in the question, as well as the relationships and other entities related to that entity; b. Professional model calculation tool: run_hydrological_model(model_name: str, params: Dict) -> Dict; its function is to call the backend water conservancy professional model, such as "inflow forecast", "flood evolution" or "optimized scheduling", etc.; the metadata of this tool clearly marks the required parameters for different models. c. Information sending tool: send_notification(message: str, channel: str); its function is to send alerts or notifications through specified channels, such as sending alert information to specified DingTalk groups, SMS gateways or mailing lists.

[0077] (2) Formal execution and planning algorithms for intelligent agents: The core operating mechanism of the agent is a formal execution and reasoning loop algorithm based on the ReAct (Reason-Act-Observe) concept; this algorithm ensures that the agent can complete the structured task sequence passed in by S2 in an orderly and autonomous manner.

[0078] Agent state management: During operation, the intelligent agent dynamically maintains an internal state, also known as a "scratchpad"; this state is a structured object that contains at least: Task queue: An ordered list of tasks to be done, generated based on the task sequence and its dependencies field passed in step S; Completed tasks: Records the tasks that have been successfully executed and their IDs; Intermediate Results and Observations: Store all data returned after the tools are executed (such as queried water levels, model calculation results) and supplementary information from users; Reasoning history: Records the thought process in each step of the loop, used for decision tracing and debugging.

[0079] b. Algorithm: Decision and Planning Execution Loop: Initialization: The agent receives the structured task sequence from step S2, parses its dependencies, initializes the "internal state", and puts all independent initial tasks into the "task queue". Looping execution: As long as the "task queue" is not empty, continuously loop through the steps of "task selection -> thinking -> action -> observation -> status update". i. Task Selection: Retrieve a currently executable task t from the head of the "task queue". i (All its dependent tasks are already in the "Completed Tasks" list); ii. Reasoning: This is the core of the agent's planning process; Target Analysis: Analyze Task t i Targets and parameters; Tool pre-selection: Traverse the tool library and select tools that can achieve t based on their functional descriptions. i Candidate tools for the target; Parameter validation and dynamic programming: Check whether all the necessary parameters required to execute the candidate tool already exist in the "Intermediate Results and Observations" of the "Internal State".

[0080] If all parameters are complete, a clear action plan will be generated, which involves calling the selected tool and passing in all parameters.

[0081] If the parameters are incomplete (e.g., "Inbound Traffic Forecast" is missing when executing "Generate Scheduling Plan"), a new pre-task will be dynamically generated. The goal of this subtask is to retrieve the missing parameters; the action plan will be modified to execute this subtask, for example, by calling `run_hydrological_model` to calculate traffic or generating a request to ask the user a question. This newly generated subtask will be inserted at the head of the "Task Queue" and executed first. iii. Action: Execute the action plan developed in the "Thinking" step. This could be a tool API call (such as knowledge_graph_query(...)) or an action that sends a query request to the user interface; iv. Observation: Receive and record the results of actions (e.g., JSON objects output by tools or supplementary information entered by the user through the interface). v. State Update: Appends the current loop's thoughts, actions, and observations to the corresponding fields in the "Internal State"; if task t i If a task is successfully completed, it is removed from the "Task Queue" and added to the "Completed Tasks" list. Termination: When the "Task Queue" is empty, it means that all tasks have been completed, and the loop terminates.

[0082] c. Implementation of Two-Phase Query Reasoning: "Two-phase query reasoning" is a specific implementation mode of the above-mentioned iterative algorithm when executing a knowledge graph query tool. When the agent needs to query entity information, the "Action" step is refined as follows: Phase 1 (Entity Linking): First, a semantic retrieval module based on vector indexing is called to fuzzy match the natural language entity names (such as "Nishan Reservoir") in the task parameters to the unique entity IDs (such as "nishanshuiku_001") in the knowledge graph. The second stage (attribute retrieval): After obtaining the precise entity ID, the graph database's precise query interface is called (e.g., executing an nGQL statement) to retrieve its structured attributes and relationships based on the ID. This approach, combining fuzzy search and precise query, balances the flexibility and accuracy of the query.

[0083] (3) Specific implementation process of emergency dispatch plan generation. The following will demonstrate the execution flow of the above algorithm through the task "Query the water level of Nishan Reservoir and generate a dispatch plan" passed in step S2: Initialization: The agent receives the task sequence and adds task_id: 1 (query water level) to the task queue; First loop (processing task 1): Task selection: Select Task 1 "Query Knowledge Graph"; Reason: The goal is to query the real-time water level of "Nishan Reservoir"; the plan is to call the knowledge_graph_query tool. Action: Execute "two-phase query reasoning". The first phase links the entity ID "nishanshuiku_001", and the second phase queries the attributes; Observe: The tool returns {"Real-time water level": "152.3 meters"}; State Update: Store the water level results in "Intermediate Results" and mark Task 1 as completed; the dependencies of Task 2 (Generate Plan) have been satisfied, so add it to the task queue; Second loop (processing task 2): Task selection: Select Task 2 "Generate Scheduling Plan"; Reason: The goal is to call the run_hydrological_model tool; the agent performs parameter verification and finds that the inflow_forecast parameter is missing; the algorithm's dynamic programming mechanism is triggered, generating a new subtask: "Request precipitation forecast information from the user"; Action (Act): Executes a subtask, sending a question to the user interface; Observe: Received user reply: "The forecast is for heavy rain over the next three days, with a total rainfall of 90 mm"; State Update: Stores user responses in "intermediate results"; Third loop (processing the subtask of obtaining traffic forecasts): Reason: To complete the inflow_forecast parameter, we plan to call the run_hydrological_model tool and specify the model as inflow_forecast; Action: Call run_hydrological_model, passing in the precipitation information provided by the user; Observe: The tool returns detailed inbound flow process data; State Update: Stores traffic data in "intermediate results"; Fourth cycle and subsequent (final execution of task 2): Reason: The agent re-verifies and finds that all parameters required to generate the plan have been met; to ensure the safety of the plan, further planning is made to query relevant constraints from the knowledge graph before final execution (such as the downstream flood control guarantee water level). Action: Calls knowledge_graph_query to retrieve constraints; Observe: Obtain the flood control guarantee water level for key downstream protected targets; State Update and Final Execution: After storing the constraints in the "intermediate results", the `run_hydrological_model` function is finally called with all parameters passed in to generate an optimized scheduling scheme; Task 2 is complete. Termination: The task queue is empty, and the loop ends.

[0084] (4) Decision result output: After the loop terminates, the AI ​​will integrate all key information recorded in its "internal state," including the final generated decision, all intermediate queried data, user supplementary information, and relevant constraints, into a structured JSON object. This JSON object will serve as the final output of step S3 and will be passed to the module in step S4 for multimodal generation and presentation.

[0085] S4. Perform multimodal generation and interaction. Step S4 is responsible for transforming the machine-readable structured decision results output by the agent in step S3 into a multimodal decision support interface that human decision-makers can intuitively understand and that provides comprehensive information.

[0086] (1) Integration of decision-making results: First, we receive a structured JSON object output by the agent in step S3 after completing all tasks. This object is a comprehensive collection of information, containing key data from the entire decision-making process. Taking the example of generating the scheduling plan above, this JSON object contains: Final solution: A time series of optimized scheduling data containing the recommended hourly discharge flow and forecasted water level for the next 72 hours; Key input: Precipitation forecast information provided by the user; Intermediate data: Real-time water level of "Nishan Reservoir" queried during task execution; Contextual constraints: Constraints such as flood control guarantee water level of downstream key protection targets retrieved from the knowledge graph.

[0087] (2) Multimodal content generation: After receiving the integrated decision result object, the system will distribute it to multiple parallel content generation components, each responsible for a presentation modality; a. Natural Language Report Generation: A large language model (LLM) is invoked as the natural language generation engine; Use the complete JSON object output from step S3 as context, and use a preset prompt for generating a scheduling scheme report to instruct the model to summarize; The model will generate a professional, concise natural language text containing key conclusions and operational recommendations; for example: "The dispatch plan has been generated; based on the forecast of a total rainfall of 90 mm over the next three days, in order to ensure the flood control safety of key downstream protected targets, it is recommended that Nishan Reservoir gradually increase the discharge flow to XXXX cubic meters per second for pre-discharge starting from XX:00 on XX:00. It is expected that the water level can be controlled below the safe level of XXX meters by XX:00 on XX:00."

[0088] b. Data chart generation: Call a data visualization component (which can be implemented based on chart libraries such as ECharts and D3.js); This component extracts the time-series data of the scheduling plan from the JSON object output in step S3, including "forecasted inflow", "suggested outflow", and "forecasted reservoir water level". A joint scheduling diagram of the cascade reservoir group is generated. This diagram plots the three key data curves mentioned above on the same coordinate system with time as the horizontal axis. Simultaneously, the diagram uses horizontal dashed lines to mark key thresholds such as the "flood control limit water level," allowing decision-makers to intuitively compare the relationship between forecast water levels and safe thresholds.

[0089] c. Geographic information visualization: If the output of step S3 includes geospatial data (e.g., in the case of flood evolution analysis, the inundation extent would be output in GeoJSON format), the Geographic Information System (GIS) component will be activated. The GIS component can highlight key protected areas of the Nishan Reservoir and its downstream areas on the watershed map and dynamically adjust the risk level colors of these areas based on the risk assessment results of the scheduling plan.

[0090] (3) Unified interface presentation: All generated multimodal content will eventually be integrated into a unified, interactive human-computer interface (e.g., a command and decision-making cockpit) for comprehensive presentation; Layout: The main area of ​​the interface is used to display the most core visualization content, namely the "Joint Dispatch Chart"; the sidebar is used to present detailed "Natural Language Reports" and key parameter indicators (such as current water level, maximum discharge flow, etc.); if there is map information, it can be displayed through tabs or split screens. Interactivity: The interface is dynamic and interactive; decision-makers can hover the mouse over the curve of the scheduling graph to view the precise values ​​at any given time; they can also click on entities on the map to query their detailed attributes in the knowledge graph, enabling in-depth analysis and drill-down.

[0091] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. An emergency collaborative decision-making method based on dynamic knowledge graphs and intelligent agents, characterized in that, Includes the following steps: Step 1: Construct a water resources knowledge graph based on multi-source heterogeneous data in the water resources field, and establish a synchronization mechanism for the water resources knowledge graph; Step 2: Receive the user's natural language instructions, and perform domain-adaptive user intent recognition by combining a multi-stage hybrid strategy of retrieval enhancement and generative model inference, and decompose the recognized user intent into a structured task sequence; Step 3: Build an intelligent agent. The intelligent agent receives the task sequence and performs multi-step association reasoning and dynamic planning based on a dynamically synchronized water conservancy knowledge graph. It autonomously calls the tool library to plan and generate emergency decision-making schemes. Step 4: Integrate the decision results of the intelligent agent and present them in a multimodal format that includes geographic information visualization, data charts, and natural language reports.

2. The emergency collaborative decision-making method based on dynamic knowledge graphs and intelligent agents according to claim 1, characterized in that, Step 1 includes the following steps: Step 11: Extract water conservancy-related data from multi-source heterogeneous data, including structured data, semi-structured data, and unstructured data; Step 12: Construct a water resources knowledge graph, converting the extracted water resources-related data into entities, attributes, and relationships in the graph; Step 13: Establish a split storage architecture, which includes using a graph database as the main storage engine to store authoritative graph fact data, and constructing a vector index for fast semantic retrieval by vectorizing entity information in the main storage. Step 14: Establish a synchronous update mechanism based on the application programming interface. When entities in the knowledge graph are added, deleted, or modified, ensure that the operation is performed in the main storage first, and update the retrieval index synchronously after the operation is successful, so as to ensure the consistency of information between the two and the authority of the main knowledge base.

3. The emergency collaborative decision-making method based on dynamic knowledge graphs and intelligent agents according to claim 2, characterized in that, In the step of extracting water conservancy-related data from multi-source heterogeneous data, The extraction strategy for structured data is as follows: connect to the water conservancy business relational database through the JDBC interface, read the data of the reservoir, hydrological station and flood control project business tables, map the fields in the table to entity attributes, map the foreign key associations between tables to the relationships between entities, and generate structured data entries containing entity ID, attribute key-value pairs and relationship types. The extraction strategy for semi-structured data is as follows: Subscribe to the IoT message queue through the stream processing framework, receive real-time data in JSON format reported by the sensors, parse out the monitoring point ID, monitoring value, collection time and data status fields, filter abnormal data through preset verification rules, and retain valid data that meets the water conservancy monitoring standards. The extraction strategy for unstructured data is as follows: an information extraction model based on a large language model is adopted to identify "entity-relationship-attribute" triples from water conservancy emergency plans, expert reports, and historical disaster documents. Specifically, water conservancy entities are extracted through named entity recognition, the "reservoir-flood control limit water level" and "flood-affected area" associations are identified through relation extraction, and the feature parameters of entities are obtained through attribute extraction.

4. The emergency collaborative decision-making method based on dynamic knowledge graphs and intelligent agents according to claim 2, characterized in that, Step 1 further includes: Step 15: Embed a log module in the synchronization API to record the operation type, entity ID, main storage operation result, index synchronization result, and time consumption information for each synchronization operation, and generate a traceable synchronization log. Step 16: If the main storage operation is successful but the index synchronization fails, the retry mechanism is automatically triggered. If the retry fails, it is marked as "synchronization error" and an alarm is sent. Every day at midnight, the consistency check between the main storage and the index is performed. 1% of the entity IDs are randomly selected to compare the consistency of their attributes and vectors. If they are inconsistent, a full synchronization repair is triggered.

5. The emergency collaborative decision-making method based on dynamic knowledge graphs and intelligent agents according to claim 1, characterized in that, Step 2 includes the following steps: Step 21: Build an intent knowledge base offline, establish a standardized intent tagging system, and construct the correspondence between user query text and intent tags; Step 22: Vectorize the user query text and store the generated vector and the corresponding intent tag as metadata in the vector index; Step 23: After receiving the user's instruction online, first vectorize it and perform a similarity search in the vector index to obtain one or more reference cases containing similar query text and corresponding standard intent labels; Step 24: Combine the reference case with the user's original instruction to form an enhanced prompt, and use a large language model to infer based on the prompt to determine the user's final intent; Step 25: Based on the user intent determined by the large language model, decompose it into a sequence of structured tasks that can be executed in subsequent steps.

6. The emergency collaborative decision-making method based on dynamic knowledge graphs and intelligent agents according to claim 1, characterized in that, Step 3 includes the following steps: Step 31: Provide the intelligent agent with a tool library containing various types of tools, the types of which include at least: knowledge graph query, water conservancy professional model calculation, data visualization generation, and information sending; Step 32: The agent runs in the loop execution process, and in each loop, it thinks according to the task objective, selects and calls the tools in the tool library; Step 33: Update the agent's internal state based on the results returned by the tool to plan the next action until the task is completed; Step 34: Based on the dynamically synchronized water conservancy knowledge graph, perform multi-step association reasoning and dynamic programming to autonomously generate emergency decision-making solutions; Step 35: When performing knowledge graph queries, a two-stage query reasoning is adopted: first, entity linking is performed, and the natural language entity name is fuzzily matched to the entity ID in the knowledge graph; then, attribute acquisition is performed, and the structured attributes and relationships are obtained based on the entity ID.

7. The emergency collaborative decision-making method based on dynamic knowledge graphs and intelligent agents according to claim 6, characterized in that, The cyclic execution process of the intelligent agent includes the following stages: Thinking phase: Analyze the current task objective, combine the intermediate results in the internal state, select suitable tools from the tool library, and verify the parameters required by the tools; Action phase: When parameters are complete, the tool is invoked; when parameters are missing, a preceding subtask is generated and inserted into the task queue. Observation phase: Receive the results returned by the receiving tool, or capture call exceptions; Update phase: Store valid results in the intermediate result library, mark task status, and adjust task queue priority.

8. The emergency collaborative decision-making method based on dynamic knowledge graphs and intelligent agents according to any one of claims 1-7, characterized in that, Step 4 includes the following steps: Step 41: Collect geospatial data, statistical data, and conclusive text generated during the execution of the intelligent agent; Step 42: Call the geographic information visualization component to convert the geospatial data into a visualization layer; Step 43: Call the data chart generation component to convert the statistical data into chart format; Step 44: Call the natural language generation model to convert the concluding text into a natural language report; Step 45: On a unified human-computer interaction interface, all generated visualization layers, charts, and natural language reports are displayed comprehensively, providing interactive functions to support decision-makers in conducting in-depth analysis and drill-down.

9. The emergency collaborative decision-making method based on dynamic knowledge graph and intelligent agent according to claim 8, characterized in that, The data processing rules for the step of collecting geospatial data, statistical data, and conclusive text generated during the execution of the intelligent agent include: Geospatial data processing rules: Convert the latitude and longitude coordinates of the water conservancy entities output by the agent into the CGCS2000 national geodetic coordinate system, and store them as GeoJSON in the format of "entity ID-type-spatial coordinates-attributes", where the attributes include dynamic parameters such as "real-time water level and risk level"; Statistical data processing rules: Time series data are timestamped, missing values ​​are filled in using linear interpolation, outlier data exceeding physical thresholds are removed, and a standardized time series data table is formed; The processing rules for conclusive texts are as follows: Extract the core conclusions of "scheduling measures, risk assessment, and implementation suggestions" from the agent's decision-making scheme, and structure them according to "conclusion type-content-confidence level-data source" to ensure logical consistency with the numerical data.

10. An emergency collaborative decision-making device based on dynamic knowledge graphs and intelligent agents, characterized in that, include: The knowledge graph construction and synchronization module is used to construct a water conservancy knowledge graph based on multi-source heterogeneous data in the water conservancy field, and to establish a synchronization mechanism for the water conservancy knowledge graph. The intent recognition and task decomposition module is used to receive users' natural language instructions, perform domain-adaptive user intent recognition by combining a multi-stage hybrid strategy of retrieval enhancement and generative model inference, and decompose the recognized user intent into a structured task sequence. The intelligent agent decision-making and planning module is used to build an intelligent agent. The intelligent agent receives a task sequence and performs multi-step correlation reasoning and dynamic planning based on a dynamically synchronized water conservancy knowledge graph. It autonomously calls the tool library to plan and generate emergency decision-making schemes. The multimodal generation and interaction module is used to integrate the decision results of the intelligent agent and present them in a comprehensive manner in a multimodal form that includes geographic information visualization, data charts and natural language reports.

Images