A flood emergency scheme generation method and system based on a large model agent

Abstract

This application provides a method and system for generating flood emergency response plans based on a large-scale intelligent agent, relating to the field of emergency management technology. The method includes: constructing a context object based on the target dataset of the flood-affected city at the current time step, inputting it into a large-scale intelligent agent for text reasoning, and outputting structured tool invocation instructions; invoking corresponding tools through these instructions, executing them based on execution parameter data, and outputting corresponding execution results; based on the context object and execution results, the large-scale intelligent agent processes and generates a structured rescue action plan for the current time step; implementing the structured rescue action plan based on the current time step, and updating the rescue event list and resource list. The updated rescue event list and resource list will serve as input to the large-scale intelligent agent for the next time step to dynamically generate structured rescue action plans. This aims to improve the spatial accuracy and dynamic adaptability of flood relief plan generation.

Description

Technical Field

[0001] This application relates to the field of emergency management technology, specifically to a method and system for generating flood emergency response plans based on a large model intelligent agent. Background Technology

[0002] Flood emergency rescue involves disaster assessment, route planning, resource allocation, and personnel transfer. Disaster situations change over time and are constrained by geographical conditions. During a disaster, conditions such as rising water levels and road blockages are constantly changing, requiring a high degree of timeliness and accuracy in emergency command and decision-making.

[0003] Traditional flood emergency response relies on human experience or static plans. When facing large-scale floods, human command struggles to process diverse and heterogeneous data within a short timeframe. While some systems have introduced automated path planning algorithms, they lack the ability to coordinate the overall logic of the rescue effort.

[0004] Current research combines knowledge graphs with large language models for emergency decision-making recommendations. For example, by constructing an emergency knowledge graph and guiding a large language model to reason along the graph, text-based decision-making recommendations can be provided to emergency commanders. Other research enables large language models to interact with geographic information systems by generating code, achieving public-facing flood risk Q&A.

[0005] However, in existing emergency decision-making systems based on large language models, the models may fabricate non-existent coordinates or fictitious routes during the generation process, leading to insufficient accuracy in emergency plans. Furthermore, existing systems are mostly single-round question-and-answer or single-time plan generation, lacking the ability to revise existing plans as the flood situation continues to change. For example, if a road becomes blocked at a certain time step, the generated route plan may become invalid, but existing systems lack mechanisms to identify changes in the situation and locate affected items. Summary of the Invention

[0006] In view of this, this application provides a method and system for generating flood emergency response plans based on large-scale intelligent agents. It aims to solve or partially solve the problems existing in the background technology.

[0007] The first aspect of this application provides a method for generating flood emergency response plans based on a large-scale intelligent agent model, the method comprising: Based on the target dataset of the city experiencing flooding at the current time step, a context object is constructed. The target dataset includes at least: a resource list, a rescue event list, a set of blocked road sections, a list of affected items, a structured rescue action plan from the previous time step, and the corresponding execution results. The list of affected items records rescue plans that existed in the previous time step and need to be revised in the current time step. The target dataset for the first time step does not include the structured rescue action plan and the corresponding execution results from the previous time step. The context object at the current time step is input into the large model agent for text reasoning, and a structured tool invocation instruction is output. The tool invocation instruction contains the execution parameter data required for the invoked tool to execute. The invoked tool includes at least a path planning tool and a resource query tool. The corresponding tool is invoked through the tool invocation command, and the execution is performed based on the execution parameter data, outputting the corresponding execution result; In the first round of the current time step, based on the context object and the execution result, the large model agent generates the structured rescue action plan corresponding to the first round. In the non-first rounds of the current time step, by inputting the context object, the structured rescue action plan output by the large model agent in the previous round of the non-first round, and the execution result returned by the tool call in the previous round of the non-first round, the large model agent is controlled to generate the structured rescue action plan for the non-first round. After generating the structured rescue action plan for a preset number of rounds, the structured rescue action plan generated in the last round is determined as the final structured rescue action plan for the current time step. Based on the final structured rescue action plan, the rescue action is carried out, and the rescue event list and resource list are updated. The updated rescue event list and resource list will be used as input to the large model agent in the next time step to dynamically generate a structured rescue action plan.

[0008] A second aspect of this application provides a flood emergency response plan generation system based on a large-model intelligent agent, the system comprising: The context object construction module is used to construct a context object based on the target dataset of the city where the flood occurred at the current time step. The target dataset includes at least: a resource list, a rescue event list, a set of blocked road sections, a list of affected items, a structured rescue action plan from the previous time step, and the corresponding execution results. The list of affected items records rescue plans that existed in the previous time step and need to be revised in the current time step. The target dataset of the first time step does not include the structured rescue action plan and the corresponding execution results from the previous time step. The tool invocation instruction generation module is used to input the context object of the current time step into the large model agent for text reasoning and output a structured tool invocation instruction. The tool invocation instruction contains the execution parameter data required for the invoked tool to execute. The invoked tool includes at least a path planning tool and a resource query tool. The tool invocation processing module is used to invoke the corresponding tool through the tool invocation command, execute it based on the execution parameter data, and output the corresponding execution result. The scheme generation module is used to generate a structured rescue action scheme for the first round in the current time step, based on the context object and the execution result. In the non-first rounds of the current time step, the module controls the large model agent to generate a structured rescue action scheme for the non-first round by inputting the context object, the structured rescue action scheme output by the large model agent in the previous round, and the execution result returned by the tool call in the previous round. After generating a preset number of structured rescue action schemes, the structured rescue action scheme generated in the last round is determined as the final structured rescue action scheme for the current time step. The implementation and update module is used to implement rescue operations based on the final structured rescue operation plan, and update the rescue event list and resource list. The updated rescue event list and resource list will be used as input to the large model agent in the next time step to dynamically generate a structured rescue operation plan.

[0009] The flood emergency response plan generation method based on a large model intelligent agent provided in this application has the following advantages: The flood emergency response plan generation method based on a large-model intelligent agent provided in this application, at discrete time steps, outputs a total structured rescue action plan at each time step based on the collaborative execution of flood situation construction, intelligent agent reasoning, and tool invocation, and only revises the rescue plan affected by changes in the flood situation. This significantly improves emergency response speed and decision-making accuracy, thereby enhancing the spatial accuracy and dynamic adaptability of flood rescue plan generation. Attached Figure Description

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

[0011] Figure 1This is a flowchart illustrating a flood emergency response plan generation method based on a large model intelligent agent, as shown in one embodiment of this application; Figure 2 This application illustrates a flowchart of a flood emergency response plan generation method based on a large model intelligent agent, showing the process of determining the list of affected items in one embodiment of the present application; Figure 3 This is a flowchart illustrating constraint verification in a flood emergency response plan generation method based on a large model intelligent agent, as shown in one embodiment of this application; Figure 4 This is a schematic diagram illustrating a flood emergency response scheme generation system based on a large model intelligent agent, as shown in one embodiment of this application. Detailed Implementation

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

[0013] refer to Figure 1 , Figure 1 This is a flowchart illustrating a flood emergency response plan generation method based on a large model intelligent agent, as shown in one embodiment of this application. Figure 1 As shown, the method includes: Step S01: Based on the target dataset of the city where the flood occurred at the current time step, construct a context object. The target dataset includes at least: the resource list, rescue event list, road blockage set, affected item list, structured rescue action plan and corresponding execution results of the previous time step; the affected item list records the rescue plans that existed in the previous time step and need to be revised in the current time step.

[0014] In this embodiment, the emergency response process for generating a city-wide overall rescue action plan (which comprises rescue plans corresponding to multiple rescue events, with one rescue event corresponding to one rescue plan) is discretized into multiple time steps for dynamic decision-making, as follows: First, obtain the target dataset of the city where the flood occurred at the current time step. This target dataset includes at least the resource list, rescue event list, road blockage set, affected item list, structured rescue action plan and corresponding execution results of the previous time step.

[0015] The resource list for the current time step records the total amount, usage, and availability of various resources in each rescue center within the current time step.

[0016] The rescue event list for the current time step records the rescue events to be executed and the rescue events currently being executed within the current time step. These rescue events include newly added rescue events that did not exist in the previous time step, as well as rescue events that existed in the previous time step. The rescue event list is a pre-configured list or a list of rescue events that are accessed in real time by an external disaster response system. Each record in the rescue event list corresponds to one rescue event, and each record includes at least the rescue event identifier, the time of occurrence of the rescue event, the rescue event category, the severity level, the number of people affected, the location of the rescue event, and the type of resources required.

[0017] The current time step's blocked road segment set records all road segments in the flood-affected city where the water depth sampled exceeds the blocking threshold within the current time step, to which this flood emergency response plan generation method is applied. The flood raster data of the flood-affected city at the current time step is read, and water depth sampling is performed on each road segment in the city's road network map. When the water depth sampled for a road segment exceeds the blocking threshold, the road segment is marked as a blocked road segment and added to the blocked road segment set. The blocking threshold is a pre-set critical value for determining whether a road segment is impassable due to water depth.

[0018] The list of affected items in the current time step records rescue plans that existed in the previous time step but need to be revised in the current time step due to the flood situation. It also records revision markers for these revised rescue plans. Revision markers include at least route revision markers and resource reallocation markers. For rescue plans that existed in the previous time step and have route revision markers recorded in the list of affected items, it indicates that the rescue plan is affected by the flood situation, and its previous rescue route has blocked sections that make it impassable (or unable to reach the designated rescue point within the specified timeframe), requiring revision of its rescue route.

[0019] For rescue plans that existed in the previous time step and have a resource reallocation marker recorded in the list of affected items, it means that the rescue plan is affected by the flood situation and the resources allocated to it are unavailable in the current time step (e.g., the resources allocated to the rescue plan have been reallocated to rescue plans corresponding to rescue events that are more urgent or require the resources more), and the resources need to be reallocated.

[0020] The structured rescue action plan of the previous time step represents the set of all rescue plans generated in the previous time step for the flooded city. The corresponding execution result is the execution status of each rescue plan in the previous time step, such as recording rescue events that have been completed in the previous time step. These completed rescue events will not appear in the rescue event list of the current time step.

[0021] In this embodiment, when the current time step is the first time step in the emergency response process, since no structured rescue action plan has been constructed before this first time step, the target dataset for this first time step does not include the structured rescue action plan and corresponding execution results from the previous time step. This application determines the traffic status of road sections by sampling water depth from flood raster data, constructs a complete disaster situation by combining the list of affected items and the resource list, and identifies changes in blocked roads between adjacent time steps through a dynamic state comparison mechanism, providing accurate input information for subsequent reasoning by large model agents and reducing the possibility of large model agents missing situation changes in long texts.

[0022] Step S02: Input the context object of the current time step into the large model agent for text reasoning, and output a structured tool invocation instruction. The tool invocation instruction contains the execution parameter data required for the invoked tool to execute. The invoked tool includes at least a path planning tool and a resource query tool.

[0023] In this embodiment, after obtaining the context object of the current time step through step S01, the context object is input into the large model agent for text reasoning. This text reasoning first yields a textualized tool invocation plan. Its core purpose is to allow the large model agent to fully consider and reason before generating structured tool invocation instructions, thus generating the textualized tool invocation plan. Then, based on this textualized tool invocation plan, the final structured tool invocation instructions are output. These instructions contain execution parameter data required for the invoked tool to execute, and the invoked tools include at least a path planning tool and a resource query tool.

[0024] For example, let's illustrate a text-based tool invocation plan corresponding to a route planning tool: For rescue event E001: Route replanning is required; invoke the route planning tool; starting point is rescue center C01; destination is event location P01; the set of road segments to be avoided is the set of blocked road segments at the current time step; the purpose of the invocation is to obtain the passable route, estimated arrival time, and maximum water depth along the route. Except for the invocation of the route planning tool, all other information is execution parameter data contained in the tool invocation command. Let's also illustrate a text-based tool invocation plan corresponding to a resource query tool: For rescue event E002: It is necessary to confirm whether resources are sufficient; invoke the rescue resource query tool; the query target is rescue center C02; the required resource is one ambulance; the purpose of the invocation is to determine whether the center can handle the rescue event. Except for the invocation of the resource query tool, all other information is execution parameter data contained in the tool invocation command.

[0025] In this embodiment, a newly added rescue event at the current time step corresponds to a tool call instruction for a path planning tool, and a rescue plan requiring path revision at the current time step also has a corresponding tool call instruction for a path planning tool. A rescue plan with a resource reallocation marker at the current time step has a corresponding tool call instruction for a resource query tool.

[0026] Step S03: Invoke the corresponding tool through the tool invocation command, execute based on the execution parameter data, and output the corresponding execution result.

[0027] In this embodiment, after generating each tool call instruction through step S02, for any tool call instruction among all the tool call instructions, the execution is performed based on the execution parameter data in the tool call instruction, and the corresponding execution result is output.

[0028] In cases where the tool invocation command corresponds to a resource query tool, the resource query tool is invoked via this command. Based on the execution parameters in the command, the tool queries whether the resources for the corresponding rescue plan are sufficient. This resource query primarily targets rescue plans marked with resource reallocation. For these plans, the resource query tool checks whether the resource list contains sufficient resources of the corresponding type and quantity available for reallocation to the rescue plan. The query result is then used as the execution result, which, along with the context object of the current time step, is input into the large model agent to guide the generation of a structured rescue action plan.

[0029] An alternative implementation involves providing a corresponding tool call instruction for a resource query tool for a rescue plan that already existed in the previous time step and does not have a resource reallocation marker. In this case, the resource query tool queries whether the resources allocated to the rescue plan are available, ensuring accurate confirmation of resource availability. Similarly, the query result is used as the corresponding execution result, which, along with the context object of the current time step, is input into the large model agent to guide the generation of a structured rescue action plan.

[0030] In this embodiment, since the structured rescue action plan for any time step (such as the current time step) is obtained through multiple rounds of iteration, the specific implementation method of the iteration will be described in subsequent embodiments. Therefore, for a new rescue event at the current time step, although no corresponding rescue plan is generated for it in the first iteration, a corresponding rescue plan will be generated after the first iteration. Therefore, for a new rescue event at the current time step, except for the first iteration which will not have a corresponding resource query tool invocation instruction, each subsequent iteration will have a corresponding resource query tool invocation instruction.

[0031] In the case where the tool invocation command is a tool invocation command corresponding to the path planning tool, the path planning tool is invoked through this command. Based on the execution parameter data in the tool invocation command, a rescue route is generated for the rescue plan corresponding to the rescue event pointed to by the tool invocation command. This rescue route is then used as the corresponding execution result, which, along with the context object of the current time step, is input into the large model agent to guide it in generating a structured rescue action plan.

[0032] In this application, when the invoked tool is a path planning tool, the corresponding tool is invoked through the tool invocation command, executed based on the execution parameter data, and the corresponding execution result is output, including: Based on the set of starting points, ending points, and blocked road sections of the rescue event in the execution parameter data, the path planning tool performs a risk-weighted shortest path search on the road network map; By returning infinite weights to blocked road sections through a dynamic weighting function, road sections are eliminated, and the path planning results corresponding to the rescue event are obtained. The path planning results include route polylines, distances, estimated arrival times, and maximum water depths along the way. The dynamic weighting function is: w(e)=l(e)×(1+α×max(0,d(e)-d_ref)), where l(e) is the road segment length, d(e) is the current water depth of the road segment, d_ref is the safe reference water depth, and α is the risk penalty coefficient.

[0033] In this embodiment, when the invoked tool is a route planning tool, the tool responds to the received tool invocation command and then performs a risk-weighted shortest path search based on the execution parameter data in the command (including the start point, end point, and set of blocked road segments for the corresponding rescue event). During the search, blocked road segments are excluded by returning infinite weights to them through a dynamic weight function. The core principle is to calculate the shortest path on the road network map using road segment risk as the weight; the higher the water depth, the greater the weight, thus prioritizing the selection of lower water depth segments in the planned route. In the dynamic weight function, α is the risk penalty coefficient, controlling the influence of water depth on the weight of road segments; d_ref is the safety reference water depth, and road segments below this depth are not subject to additional penalty. Therefore, through this risk-weighted shortest path search, the route planning result corresponding to the rescue event is obtained, which includes the route polyline, distance, estimated arrival time, and maximum water depth encountered.

[0034] This application incorporates road segment water depth information into the path search process through a dynamic weight function, enabling the planned route to automatically avoid road segments with high water depth. When the water depth of a road segment exceeds the blocking threshold, it is excluded by returning an infinite weight, thus prioritizing the selection of lower-risk paths while ensuring the route is passable.

[0035] In this embodiment, for each tool call instruction, a dedicated tool registration module uniformly executes the call, injecting a unique tool call identifier into the execution result and into the tool call trajectory. The tool call identifier represents a unique identifier injected by the tool registration module each time a tool is called, used in subsequent verification phases to trace the source of the rescue route calculation.

[0036] For example, for rescue event 'a', at the current time step, a path planning tool is invoked to calculate the rescue path for the subsequent rescue plan to be generated corresponding to rescue event 'a'. After the rescue path is calculated, a unique tool invocation identifier is injected into the rescue path, and the same tool invocation identifier is also injected into the tool invocation trajectory at the current time step. Subsequently, after the large model agent generates the rescue plan for the current time step for rescue event 'a', it traces the tool invocation identifier in the rescue path of that rescue plan. If the tool invocation identifier also appears in the tool invocation trajectory at the current time step, it is determined that the generation of the rescue path is valid and has a planning basis. If the tool invocation identifier does not appear in the tool invocation trajectory at the current time step, it is determined that the generation of the rescue path is invalid, and the rescue path was not planned by the path planning tool. In this case, it is determined that there is a problem with the overall structured rescue action plan generated by the large model agent, and the large model agent is controlled to regenerate the structured rescue action plan.

[0037] In this application, the large model agent is only responsible for reasoning and decision-making orchestration, while spatial computation is performed by a path planning tool, and the computation results are bound to a unique tool invocation identifier. By separating spatial computation from reasoning and decision-making, it is ensured that the rescue routes in the structured rescue action plan are generated from deterministic geographic computation rather than by the large model agent. This approach reduces spatial fictitious information and improves the executability of the generated rescue plan.

[0038] Step S04: In the first round of the current time step, based on the context object and the execution result, the large model agent generates the structured rescue action plan corresponding to the first round; in the non-first rounds of the current time step, by inputting the context object, the structured rescue action plan output by the large model agent in the previous round of the non-first round, and the execution result returned by the tool call in the previous round of the non-first round, the large model agent is controlled to generate the structured rescue action plan for the non-first round; after generating the structured rescue action plan for a preset number of rounds, the structured rescue action plan generated in the last round is determined as the final structured rescue action plan for the current time step.

[0039] In this embodiment, after obtaining the execution results corresponding to each tool call command through step S03, all execution results, together with the context object of the current time step, are input into the large model agent to guide it in generating the overall structured rescue action plan for the current time step.

[0040] In this embodiment, the structured rescue action plan for a given time step is obtained through multiple rounds of iteration. This application uses the current time step as an example to illustrate the specific implementation process of obtaining the final structured rescue action plan for that current time step through multiple rounds of iteration, as follows: First, in the first round of the current time step, based on the context object of the current time step and the execution result returned by the initial tool call, the large model agent processes and generates the corresponding structured rescue action plan for the first round.

[0041] Then, in non-first rounds (such as the 2nd round, 3rd round, etc.) at the current time step, the large model agent is input with the context object of the current time step, the structured rescue action plan output in the previous round (non-first round), and the execution result returned by the tool call in the previous round (non-first round). Based on these inputs, the large model agent is controlled to perform text reasoning, tool call instruction generation, tool call execution, and structured rescue action plan generation for the non-first round, thereby obtaining the structured rescue action plan for the non-first round.

[0042] After generating a pre-defined series of structured rescue action plans for the current time step, the last generated structured rescue action plan is determined as the final structured rescue action plan for that current time step. For subsequent implementations involving constraint checks, the constraint checks target the final structured rescue action plans for each time step. This iterative reasoning approach avoids the large model fabricating rescue routes and resource query results out of thin air.

[0043] Step S05: Based on the final structured rescue action plan, implement the rescue action and update the rescue event list and resource list. The updated rescue event list and resource list will be used as the input of the large model agent in the next time step to dynamically generate a structured rescue action plan.

[0044] In this embodiment, after obtaining the final structured rescue action plan for the current time step through step S04, the rescue action is implemented using this final structured rescue action plan. This includes implementing rescue operations for newly added rescue events according to the generated rescue plan, updating revised rescue plans (such as updating their latest resource allocation and latest rescue paths), and continuing to implement rescue operations for rescue plans that do not require revision according to the previous path planning and resource allocation. Simultaneously, after obtaining the final structured rescue action plan for the current time step, due to changes in resource allocation (such as resource allocation changes for newly added rescue events or resource reallocation changes for rescue plans requiring resource reallocation), the resource list is updated based on the final structured rescue action plan for the current time step. Furthermore, during the implementation of each rescue plan, rescue events may be completed at any time, and new rescue events may be added at any time. Therefore, when a completed rescue event is detected, the rescue event list is updated, completed rescue events are deleted, and new rescue events are added. The latest updated rescue event list and resource list are used as input to the large model agent for the next time step to dynamically generate structured rescue action plans.

[0045] The structured rescue action plan includes rescue plans for multiple rescue events. Each rescue plan item for a rescue event includes at least the following: rescue event identifier, action type (add, revise, maintain, complete, etc.), dispatch rescue center (i.e., which dispatch rescue center is assigned to implement the rescue plan), rescue method (e.g., land rescue, boat rescue, etc.), rescue route, tool call identifier, resource allocation, evidence citation identifier, and status description.

[0046] Finally, the final structured rescue action plan for the current time step, the execution results of each tool, and the context object are packaged into a time step snapshot for storage, which is used to generate the structured rescue action plan for the next time step. In subsequent implementations, if constraint checks are also included, the check results will also be packaged into a time step snapshot for storage.

[0047] This application executes a structured rescue action plan at each time step and stores the execution results as a snapshot. The snapshot is then read at the next time step for dynamic state comparison, forming a rolling response cycle across time steps. This enables the system to continuously generate structured rescue action plans under the condition that the disaster situation continues to evolve.

[0048] The flood emergency response plan generation method based on a large-model intelligent agent provided in this application, at discrete time steps, outputs a total structured rescue action plan at each time step based on the collaborative execution of flood situation construction, intelligent agent reasoning, and tool invocation, and only revises the rescue plan affected by changes in the flood situation. This significantly improves emergency response speed and decision-making accuracy, thereby enhancing the spatial accuracy and dynamic adaptability of flood rescue plan generation.

[0049] In this application, the maintenance rules for the resource list include: during runtime initialization, reading the initial inventory of various resources of each rescue center from the scenario configuration and writing it into the resource list; after the final structured rescue action plan is determined at each time step, registering the corresponding resource occupancy for the rescue plan corresponding to the new rescue event, updating the registered resource occupancy for the revised rescue plan, and maintaining the original resource occupancy registration for the unrevised rescue plan; and releasing the resource occupancy of the rescue plan corresponding to the rescue event when the rescue event is completed.

[0050] In this embodiment, the resource list in this application is a persistent data structure that records the total amount, occupancy, and availability of various resources in each rescue center in real time, and persists throughout the entire operational cycle of the flood emergency plan (i.e., the structured rescue action plan generated at each time step). During this process, this application employs the following maintenance rules to maintain the resource list: First, during the initialization of the entire flood emergency response plan, the initial inventory of various resources available for dispatch in the various rescue centers of the flood-affected city is read from the scenario configuration, and the read information is written into the resource list.

[0051] After the final structured rescue action plan is determined at each time step, since the rescue plan corresponding to the newly added rescue event in the latest time step's final structured rescue action plan has just been allocated resources, the corresponding resource occupancy is registered for the rescue plan corresponding to the newly added rescue event in the structured rescue action plan. Registering resource occupancy means allocating resources to the corresponding rescue plan in the corresponding resource center and recording the resources allocated to the corresponding rescue plan as occupied. These resources will not be allocated to other rescue plans under non-emergency circumstances.

[0052] Meanwhile, the latest time step's final structured rescue action plan contains rescue plans that existed in the previous time step but have been revised. These rescue plans may also involve resource reallocation, therefore the resource usage of these revised rescue plans in the structured rescue action plan is updated and registered.

[0053] For rescue plans that existed in the previous time step but were not revised in the latest time step's final structured rescue action plan, since these plans do not involve resource reallocation, their registered resource occupancy can be maintained. During the implementation of the rescue plan, the resource occupancy of the rescue plan corresponding to that rescue event is released upon completion. For example, if rescue event 1 involves rescuing 10 trapped people in area a of a flooded city, and rescue event 1 is completed after the 10 people are safely rescued to a resettlement point, then the resource occupancy of the rescue plan corresponding to that rescue event is released accordingly.

[0054] In this embodiment, for a revised rescue plan, the resource occupancy registered in the previous time step is retrieved based on the rescue event identifier of the corresponding rescue event. If the resource center allocated to the rescue event and / or the resource quantity changes, the original occupancy is released or offset before re-registering the resource occupancy. If the resource configuration remains unchanged, it is maintained as is, and resource occupancy is not re-registered. The maintenance of the resource list is performed after the final structured rescue action plan for the corresponding time step is generated, based on the generated structured rescue action plan. For example, after the final structured rescue action plan for time step a1 is generated, the resource list is updated and maintained using this structured rescue action plan; similarly, after the final structured rescue action plan for time step a2 is generated, the resource list is updated and maintained using this structured rescue action plan.

[0055] In this application, a list of affected entries is generated, including steps S01_1a to S01_1d: Step S01_1a: Compare the set of blocked road segments in the current time step with the set of blocked road segments in the previous time step, and mark the newly added blocked road segments in the current time step as newly added blocked road segments.

[0056] In this embodiment, the list of affected entries for the current time step is generated as follows: like Figure 2 As shown, the set of blocked road segments at the current time step is first obtained through analysis. This set is then compared with the set of blocked road segments from the previous time step, and any newly added blocked road segments in the current time step are marked as newly added blocked road segments. Specifically, in the first time step, every blocked road segment in the set of blocked road segments for that first time step is a newly added blocked road segment.

[0057] Step S01_1b: Determine whether the rescue routes of each rescue plan in the final structured rescue action plan of the previous time step pass through the newly added blocked road section; mark the route revisions for the rescue plans that pass through the newly added blocked road section.

[0058] In this embodiment, the system then identifies which rescue plans from the previous time step's final structured rescue action plan have incomplete rescue events that still exist in the current time step's rescue event list. After obtaining the rescue plans for these incomplete rescue events from the previous time step, it determines whether the rescue routes for these plans pass through newly added road obstructions in the current time step.

[0059] In this embodiment, if the rescue route of any of these rescue plans passes through a newly added blocked section at the current time step, it is determined that the rescue plan cannot continue along the previous rescue route at the current time step. At this time, a route revision mark is made for the rescue plan, that is, a mark is added indicating that the route needs revision, so that the large model agent can make targeted route revisions for this rescue plan when generating structured rescue action plans.

[0060] Step S01_1c: Determine whether the resources allocated to each rescue plan in the final structured rescue action plan of the previous time step are still available; mark the rescue plans whose allocated resources are unavailable for resource reallocation.

[0061] In this embodiment, it simultaneously obtains which rescue events corresponding to the final structured rescue action plan from the previous time step are incomplete and still exist in the rescue event list of the current time step. After obtaining the rescue plans for these incomplete rescue events from the previous time step, it determines whether the resources allocated to these rescue plans are still available. For example, if the previous time step recorded that 10 Class A resources marked 1 to 10 in Resource Center 1 were allocated to rescue plan x, and the current time step obtains that the 10 Class A resources marked 1 to 10 recorded in Resource Center 1 were allocated to rescue plan y, then it is determined that the 10 Class A resources allocated to rescue plan x are unavailable and need to be reallocated.

[0062] In this embodiment, if any of the rescue plans has unavailable resources, a resource reallocation marker is set for that rescue plan. This marker indicates that resource reallocation is required, allowing the large-scale model agent to perform targeted resource reallocation when generating structured rescue action plans. Since a rescue plan requires various resource types and quantities, and some or all of a certain type of resource may be unavailable, the resource reallocation marker for that rescue plan records the types and quantities of resources requiring reallocation.

[0063] Step S01_1d: Generate a list of affected entries based on the rescue plan with route revision markers and the rescue plan with resource reallocation markers.

[0064] In this embodiment, the rescue plans marked with the need for route revision and resource reallocation are summarized into an affected list. This affected list serves as input to the large model agent, which then only revises the affected rescue plans, leaving the others stable. It should be understood that new rescue events at the current time step require the large model agent to generate a corresponding rescue plan for the first time. Specifically, at the first time step, all rescue events are considered new rescue events.

[0065] In this application, the dynamic state comparison between the current time step and the previous time step is completed by the deterministic module, rather than being left to the large model agent to judge changes in long state texts. This avoids the large model agent missing situational changes or making incorrect judgments. Simultaneously, by marking affected rescue plans and their corresponding markers (including route revision markers and resource reallocation markers), the large model agent is driven to process only the rescue plans that need revision. Unaffected rescue plans directly inherit the content from the previous time step, reducing unnecessary changes to rescue plans.

[0066] In this application, the target dataset further includes: candidate response strategy suggestions based on matching rescue event type and rescue event severity level, and text evidence fragments retrieved from the emergency knowledge base. The candidate response strategy suggestions and the text evidence fragments are used to provide the large model agent with a normative basis for generating structured rescue action plans. Retrieving text evidence fragments from the emergency knowledge base includes: filtering a set of candidate files from a pre-maintained file-level metadata index based on the city where the floods occurred; retrieving matching text evidence fragments from the candidate file set based on the type and severity of the rescue event; and binding evidence citation identifiers to the text evidence fragments.

[0067] In this embodiment, to enable the large model agent to generate more professional and structured rescue action plans that better meet rescue standards, the target dataset of this application may also include candidate response strategy suggestions based on matching the rescue event type and severity level, as well as text evidence fragments retrieved from the emergency knowledge base.

[0068] The candidate response strategy recommendations are pre-established basic rescue strategies that match the type and severity level of the rescue event. These candidate strategies include at least minimum resource requirements, recommended resource allocation, and recommended rescue methods (e.g., land rescue, boat rescue, etc.). Based on the rescue event type and severity level, matching candidate response strategy recommendations can be directly retrieved from the database. These recommendations are used to constrain and guide the subsequent decision-making of the large-scale model agent.

[0069] The text evidence fragments retrieved from the emergency knowledge base include: the fragment identifier, source document identifier, document title, region, and relevance score to the current rescue event. These retrieved text evidence fragments provide policy, contingency plan, and regulatory basis for the large-scale intelligent model, supporting its generation of rescue plans.

[0070] In this embodiment, the specific process of retrieving text evidence fragments from the emergency knowledge base is as follows: Firstly, this application pre-maintains a file-level metadata index, which includes the file title, region, document type, and authority level. The file-level metadata index represents an index built for each document in the emergency knowledge base, recording the title, region, document type, and authority level of each document, used to narrow down the candidate scope before retrieval.

[0071] First, candidate files are filtered based on the cities where floods occurred in the file-level metadata index. Then, within this candidate file set, vector similarity retrieval is performed based on the type of rescue event (e.g., personnel evacuation, medical transport, material support, temporary resettlement, and flood drainage) and the severity of the rescue event to obtain matching text evidence fragments. These fragments are then sorted by regional relevance and authority level, with each fragment bound to a source file identifier and an evidence citation identifier. The authority level indicates the document's level of authority; for example, a national-level plan has a higher authority level than a local-level plan.

[0072] This application improves retrieval efficiency and reduces interference from irrelevant documents by first filtering candidate documents by region in the file-level metadata index and then performing vector similarity retrieval within the narrowed scope. After reordering by authority level, evidence from high-authority sources is returned first, providing a traceable basis for the agent's decision-making.

[0073] In conjunction with the above embodiments, in one implementation, this application also provides a method for generating flood emergency response plans based on large-scale intelligent agents. This method further includes: Step S06: Perform constraint checks on the final structured rescue action plan. The constraint checks include at least one of the following: geospatial empirical check, rescue resource consistency check, rescue event coverage check, and minimum revision consistency check. The geospatial empirical verification includes: verifying whether the rescue routes of each rescue plan in the final structured rescue action plan are bound to valid tool call identifiers, and whether the tool call identifiers exist in the tool call trajectory at the current time step; the rescue resource consistency verification includes: checking whether the total resource allocation of all rescue plans in the final structured rescue action plan exceeds the available amount in the resource list, and checking whether the resource allocation of each rescue plan meets its own lower limit of resource requirements; the rescue event coverage verification includes: checking whether all rescue events have corresponding rescue plans in the final structured rescue action plan; and the minimum revision consistency verification includes: checking whether rescue plans that do not need revision are consistent with the rescue plan for the rescue event at the previous time step, and checking whether rescue plans that need revision have corresponding revision markers.

[0074] In this embodiment, to ensure the accuracy of the structured rescue action plan generated by the large model agent, this application provides another implementation method for constraint verification of the generated structured rescue action plan, as follows: For the large model agent that generates the final structured rescue action plan at the current time step, the structured rescue action plan is subjected to constraint testing, which includes at least one of the following: geospatial empirical test, rescue resource consistency test, rescue event coverage test, and minimum revision consistency test.

[0075] The geospatial empirical test refers to verifying whether the rescue routes of each rescue scheme in the structured rescue action plan are bound to valid tool call identifiers, and simultaneously determining whether these valid tool call identifiers exist in the tool call trajectory at the current time step. If the rescue routes of each rescue scheme are bound to valid tool call identifiers, and it is determined that these valid tool call identifiers also exist in the tool call trajectory at the current time step, then the geospatial empirical test is considered passed.

[0076] For example, for rescue event 'a', at the current time step, a path planning tool is invoked to calculate the rescue path for the subsequent rescue plan to be generated for this rescue event. After the rescue path is calculated, a unique tool invocation identifier is injected into the rescue path, and the same identifier is also injected into the tool invocation trajectory at the current time step. Subsequently, after the large model agent generates the rescue plan for the current time step for this rescue event, the tool invocation identifier in the rescue path of that rescue plan is traced. If the tool invocation identifier also appears in the tool invocation trajectory at the current time step, it is determined that the generation of the rescue path is valid and has a planning basis. If the tool invocation identifier does not appear in the tool invocation trajectory at the current time step, it is determined that the generation of the rescue path is invalid, and the rescue path was not planned by the path planning tool. In this case, it is determined that there is a problem with the overall structured rescue action plan generated by the large model agent, and it needs to be regenerated.

[0077] The consistency check of rescue resources refers to checking whether the total resource allocation of all rescue plans in the structured rescue action plan exceeds the available amount in the resource list, and whether the resource allocation of each rescue plan meets its own lower limit of resource demand. If the total resource allocation of all rescue plans does not exceed the available amount in the resource list, and the resource allocation of each rescue plan meets its own lower limit of resource demand, then the consistency check of rescue resources is considered passed. This lower limit of resource demand is calculated based on the number of people affected by the rescue event, rounded up to the nearest integer as the ratio of the number of affected people to the unit carrying capacity. The large model agent then makes a resource allocation decision for the rescue event between this lower limit of resource demand and the available amount in the resource list. This application uses a resource list throughout the entire operation cycle to uniformly record resource occupation and release across time steps, and checks whether the total allocation exceeds the available amount during the verification phase, thus avoiding the problems of duplicate allocation and over-allocation caused by independent resource allocation between different time steps.

[0078] The rescue event coverage check refers to verifying whether all rescue events in the rescue event list at the current time step have a corresponding rescue plan within the structured rescue action plan. If a corresponding rescue plan exists for each event, the rescue event coverage check is considered passed.

[0079] The minimum revision consistency test involves checking whether the rescue plan that requires no revision is consistent with the rescue plan for the same event in the previous time step, and whether the rescue plan that requires revision has a corresponding revision marker. If the rescue plan that requires no revision is consistent with the rescue plan for the same event in the previous time step, and the rescue plan that requires revision recorded in the list of affected items in the current time step is marked with a corresponding revision marker (including route revision marker and resource reallocation marker) in the structured rescue action plan of the current time step, then the minimum revision consistency test is considered passed. The minimum revision consistency test indicates that it checks whether the large model agent only performs revisions on the affected rescue plans, while maintaining the original rescue plans and ensuring consistency with the previous time step.

[0080] Step S07: If any test fails, the failed test information is converted into structured feedback and input into the large model agent, which then re-reasons and outputs the repaired structured rescue action plan.

[0081] In this embodiment, as Figure 3 As shown, when the constraint checks include multiple checks, if any one or more checks fail, the final structured rescue action plan generated by the large model agent for the current time step is determined to be invalid. This structured rescue action plan lacks accuracy and does not meet the corresponding constraints. In this case, the failed check information is transformed into structured feedback and input into the large model agent. Based on this structured feedback, the context object of the current time step, and the execution results, the large model agent re-infers and outputs a corrected structured rescue action plan.

[0082] Step S08: If the repaired structured rescue action plan passes the constraint test, the rescue action shall be carried out based on the repaired structured rescue action plan.

[0083] In this embodiment, the repaired structured rescue action plan, which is re-inferred and output by the large model agent, is subjected to constraint testing. If the repaired structured rescue action plan passes the constraint test, it is determined to be effective, and the rescue action is then carried out based on the repaired structured rescue action plan.

[0084] Step S09: If the repaired structured rescue action plan fails the constraint test, the large model agent is controlled to repair the rules based on predefined rules, and the constraint test is performed after each rule repair.

[0085] If the repaired structured rescue action plan still fails the constraint check, then the repaired structured rescue action plan is determined to be invalid. At this time, the large model agent is controlled by predefined rules to repair the rules. After each rule repair, the constraint check is performed on the large model agent after rule repair.

[0086] In this embodiment, the large model agent in this application adopts a reasoning-action-verification architecture to perform alternating cycles of reasoning and tool invocation. This architecture represents the working structure of the large model agent in each cycle, sequentially executing three stages: reasoning analysis, tool invocation, and result verification. In the reasoning stage, the large model agent analyzes the disaster situation and plans action strategies; in the action stage, the agent selects and invokes registered tools to obtain calculation results; and in the verification stage, constraint verification is performed on the generated structured rescue action plan.

[0087] In this application, the predefined rules in the rule repair include: performing downsizing or changing the dispatch center for rescue plans with over-allocated resources; re-invoking the path planning tool to generate new rescue paths for rescue plans with infeasible rescue routes; generating corresponding backup rescue plans based on the context object of the current time step for rescue events with missing coverage; restoring the rescue plan to the rescue plan of the previous time step for rescue plans that do not require revision but have been revised; and issuing revision control for rescue plans that require revision but have not been revised.

[0088] In this embodiment, if the geospatial empirical test fails, it is determined that there is no valid tool call identifier bound, or a valid tool call identifier is bound but the tool call identifier does not exist in the tool call trajectory at the current time step. The path planning tool is then invoked again to generate a new rescue route. The processing result is fed back to the large model agent to control the large model agent to regenerate a structured rescue action plan.

[0089] If the consistency check of rescue resources fails, the rescue plan with over-allocated resources will be downgraded or the dispatch center will be replaced, prioritizing the replacement with a rescue center that has sufficient resources; if no resource center is available, the resources will be downgraded according to the current availability. The processing results will be fed back to the large model agent to control the large model agent to regenerate a structured rescue action plan.

[0090] If the rescue event coverage test fails, the path planning tool and resource query tool are invoked for the missing rescue event to generate a corresponding backup rescue plan based on the context object of the current time step.

[0091] If the minimum revision consistency check fails, for a rescue plan that originally did not require revision but was modified accordingly (e.g., the rescue plan is not in the list of affected items in the current time step, but the check finds that the rescue plan is inconsistent with the rescue plan in its previous time step), the rescue plan is modified to be consistent with the rescue plan in its previous time step.

[0092] For rescue plans that originally needed to be revised but were not revised (e.g., the rescue plan is in the list of affected items in the current time step, but the check finds that the rescue plan is consistent with the rescue plan in the previous time step), feedback is given to the large model agent to control the large model agent to regenerate a new rescue plan for the rescue plan.

[0093] In this application, the constraint test further includes an evidence binding test; the evidence binding test includes: checking whether the evidence citation identifier of the text evidence fragment referenced in the final structured rescue action plan is the evidence citation identifier of the text evidence fragment retrieved at the current time step.

[0094] In this embodiment, if the target dataset also includes text evidence fragments retrieved from the emergency knowledge base, the constraint test may further include an evidence binding test. This evidence binding test refers to checking whether the evidence citation identifier of the text evidence fragment referenced in the final structured rescue action plan at the current time step is the same as the evidence citation identifier of the text evidence fragment retrieved at the current time step. For example, a unique evidence citation identifier is generated for the text evidence fragment retrieved at the current time step. This identifier is recorded in the text evidence fragment and also in the evidence citation trajectory at the current time step (e.g., recorded in a database and bound to the current time step). Then, it is determined whether the evidence citation identifier in the input text evidence fragment of the large model agent during the generation of the final structured rescue action plan for the current time step is consistent with the evidence citation identifier of the text evidence fragment recorded in the evidence citation trajectory at the current time step. If they are consistent, the evidence binding test is considered passed. If they are inconsistent, the input text evidence fragment is considered invalid, and the evidence binding test fails.

[0095] In this embodiment, there are also predefined rules for evidence binding verification in the rule repair process. Specifically, if the evidence binding verification fails, invalid evidence text fragments input into the large model agent are deleted, and evidence text fragments that were previously retrieved and whose own evidence citation identifiers exist in the evidence citation trajectory at the current time step are obtained. These evidence text fragments are then input into the large model agent to regenerate the structured rescue action plan.

[0096] Step S10: If the structured rescue action plan obtained after rule repair within a preset number of times passes the constraint test, the rescue action is carried out based on the finally repaired structured rescue action plan.

[0097] In this embodiment, the generated final structured rescue action plan for the current time step can undergo a maximum of a preset number of rule repairs, with a constraint check performed after each rule repair. If the structured rescue action plan passes the constraint check in any rule repair within the preset number of repairs, the repair process ends, and a valid structured rescue action plan for the current time step is obtained.

[0098] Step S11: If the structured rescue action plan obtained after a preset number of rule repairs fails the constraint test, a guaranteed structured rescue action plan for the current time step is generated using deterministic rules.

[0099] In this embodiment, if the structured rescue action plan after rule repair within the preset number of attempts still fails the constraint test, the large model agent will no longer be used to generate a structured rescue action plan. Instead, deterministic rules will be used to generate a backup rescue plan based on the priority of the rescue event corresponding to the rescue plan that fails the constraint test, ensuring that the system can produce a rescue plan without interruption under any circumstances.

[0100] This application employs a three-tiered progressive repair mechanism: large-model agent self-repair, predefined rule repair, and deterministic rule generation. When the agent outputs abnormalities, it sequentially attempts repair methods from mild to severe to ensure continuous system availability. Agent self-repair utilizes the agent's reasoning ability for targeted correction; predefined rule repair executes predefined repair operations for known types of violations; and deterministic rule generation serves as a final safety net to ensure uninterrupted system operation.

[0101] In flood disaster emergency scenarios, the disaster situation continuously evolves over time. The proposed solution first constructs the current disaster situation at each time step. Then, a large-scale model agent analyzes the disaster situation and uses geographic information tools to generate structured rescue action plans. Next, constraint checks and hierarchical repairs are performed on the structured rescue action plans to ensure spatial accuracy and resource consistency. Finally, the structured rescue action plans are executed, and the results are passed to the next time step. Through this rolling cycle, the system can continuously generate executable rescue plans as the disaster situation evolves, rather than providing static suggestions all at once.

[0102] In this application, the invoked tool further includes: an intelligent retrieval tool; the execution parameter data in the tool invocation instruction of the intelligent retrieval tool is the query question that the large model agent wants to ask, generated by the context object at the current time step.

[0103] In this embodiment, the invoked tool in this application may further include an intelligent retrieval tool. The execution parameter data in the tool invocation instruction of the intelligent retrieval tool is the query question that the large model agent wants to ask based on the context object of the current time step. That is, the large model agent itself wants to rely on information that is not present in the context object of the current time step and the execution results of other tools in order to generate a structured rescue action plan. The large model agent will generate a corresponding query question to invoke the intelligent retrieval tool to perform the retrieval, and input the corresponding retrieval result as the execution result into the large model agent to guide the structured rescue action plan of the large model agent. For example, the proposed query question is: Retrieve the following from the database: national or local flood emergency plans, emergency response specifications, policies and regulations, rescue resource dispatch rules, historical flood response cases, and response experience related to the current flood-affected city, rescue event type, and severity level.

[0104] In summary, in a complete implementation of the method provided in this application, in a flood disaster emergency scenario, this application employs an alternating cycle of reasoning and tool invocation, along with structured output. Spatial computation is handled by geographic information tools (i.e., the three tools mentioned above), while the large model agent is only responsible for reasoning and decision-making. Tool computation results are bound to unique identifiers and can only be written into structured rescue actions after spatial empirical verification, thereby reducing fictitious spatial information and improving the executability of the plan. A dynamic state comparison mechanism marks situational changes and affected items between adjacent time steps. Based on this, the large model agent only revises affected items (i.e., affected rescue plans), while keeping other items (i.e., unaffected rescue plans) stable, ensuring that rescue plans are updated as the situation changes while avoiding unnecessary modifications. A resource list throughout the operating cycle uniformly records resource occupation and release across time steps and verifies allocation consistency during the verification phase, avoiding resource over-allocation and duplicate allocation. When the large model agent outputs abnormalities, the system sequentially performs three levels of processing: agent self-repair, preset rule repair, and deterministic rule generation, ensuring that action instructions can be generated without interrupting operation under any circumstances. It can output a dynamic and adjustable rescue plan that combines empirical geographic information at each time step, significantly improving the speed of emergency response, the accuracy of decision-making, and the spatial accuracy and dynamic adaptability of the rescue plan.

[0105] Based on the same inventive concept, this application provides a flood emergency response plan generation system based on a large-scale intelligent agent model, such as... Figure 4 As shown, the system 400 includes: The context object construction module 401 is used to construct a context object based on the target dataset of the city where the flood occurred at the current time step. The target dataset includes at least: a resource list, a rescue event list, a set of blocked road sections, a list of affected items, a structured rescue action plan from the previous time step, and the corresponding execution results. The list of affected items records rescue plans that existed in the previous time step and need to be revised in the current time step. The target dataset of the first time step does not include the structured rescue action plan and the corresponding execution results from the previous time step. The tool call instruction generation module 402 is used to input the context object of the current time step into the large model agent for text reasoning and output a structured tool call instruction. The tool call instruction contains the execution parameter data required for the called tool to execute. The called tool includes at least a path planning tool and a resource query tool. The tool invocation processing module 403 is used to invoke the corresponding tool through the tool invocation instruction, perform execution based on the execution parameter data, and output the corresponding execution result. The scheme generation module 404 is used to generate a structured rescue action scheme corresponding to the first round in the current time step based on the context object and the execution result; in the non-first rounds of the current time step, by inputting the context object, the structured rescue action scheme output by the large model agent in the previous round of the non-first round, and the execution result returned by the tool call in the previous round of the non-first round, the module controls the large model agent to generate the structured rescue action scheme for the non-first round; after generating a preset number of structured rescue action schemes, the structured rescue action scheme generated in the last round is determined as the final structured rescue action scheme for the current time step; The scheme implementation and update module 405 is used to implement rescue operations based on the final structured rescue action scheme, and update the rescue event list and resource list. The updated rescue event list and resource list will be used as input to the large model agent in the next time step to dynamically generate a structured rescue action scheme.

[0106] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily necessary for the embodiments of this application. As for the system embodiments, since they are basically similar to the method embodiments, the description is relatively simple; relevant details can be found in the descriptions of the method embodiments.

[0107] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0108] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0109] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0110] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0111] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0112] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0113] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0114] The above provides a detailed description of the flood emergency response plan generation method and system based on a large model intelligent agent provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for generating flood emergency response plans based on large-scale intelligent agents, characterized in that, The method includes: Based on the target dataset of the city experiencing flooding at the current time step, a context object is constructed. The target dataset includes at least: a resource list, a rescue event list, a set of blocked road sections, a list of affected items, a structured rescue action plan from the previous time step, and the corresponding execution results. The list of affected items records rescue plans that existed in the previous time step and need to be revised in the current time step. The target dataset for the first time step does not include the structured rescue action plan and the corresponding execution results from the previous time step. The context object at the current time step is input into the large model agent for text reasoning, and a structured tool invocation instruction is output. The tool invocation instruction contains the execution parameter data required for the invoked tool to execute. The invoked tool includes at least a path planning tool and a resource query tool. The corresponding tool is invoked through the tool invocation command, and the execution is performed based on the execution parameter data, outputting the corresponding execution result; In the first round of the current time step, based on the context object and the execution result, the large model agent generates the structured rescue action plan corresponding to the first round. In the non-first rounds of the current time step, by inputting the context object, the structured rescue action plan output by the large model agent in the previous round of the non-first round, and the execution result returned by the tool call in the previous round of the non-first round, the large model agent is controlled to generate the structured rescue action plan for the non-first round. After generating the structured rescue action plan for a preset number of rounds, the structured rescue action plan generated in the last round is determined as the final structured rescue action plan for the current time step. Based on the final structured rescue action plan, the rescue action is carried out, and the rescue event list and resource list are updated. The updated rescue event list and resource list will be used as input to the large model agent in the next time step to dynamically generate a structured rescue action plan.

2. The flood emergency response plan generation method based on a large model intelligent agent according to claim 1, characterized in that, The method further includes: The final structured rescue action plan is subjected to constraint tests, which include at least one of the following: geospatial empirical test, rescue resource consistency test, rescue event coverage test, and minimum revision consistency test. If any test fails, the failed test information is transformed into structured feedback and input into the large model agent, which then re-reasons and outputs a repaired structured rescue action plan. If the repaired structured rescue action plan passes the constraint test, the rescue action shall be carried out based on the repaired structured rescue action plan; If the repaired structured rescue action plan fails the constraint test, the large model agent is controlled to repair the rules based on predefined rules, and the constraint test is performed after each rule repair. If the structured rescue action plan obtained after rule repair within a preset number of attempts passes the constraint test, the rescue action shall be carried out based on the finally repaired structured rescue action plan. If the structured rescue action plan obtained after a preset number of rule repairs fails the constraint test, a guaranteed structured rescue action plan for the current time step is generated using deterministic rules. Among them, the geospatial empirical test includes: verifying whether the rescue routes of each rescue plan in the final structured rescue action plan are bound to valid tool call identifiers, and whether the tool call identifiers exist in the tool call trajectory at the current time step; The consistency check of rescue resources includes: checking whether the total resource allocation of all rescue plans in the final structured rescue action plan exceeds the available amount in the resource list, and checking whether the resource allocation of each rescue plan meets its own lower limit of resource requirements; The rescue event coverage verification includes checking whether all rescue events have corresponding rescue plans in the final structured rescue action plan; The minimum revision consistency check includes: checking whether the rescue plan that does not require revision is consistent with the rescue plan for the rescue event in the previous time step, and checking whether the rescue plan that needs revision has a corresponding revision mark.

3. The flood emergency response plan generation method based on a large model intelligent agent according to claim 2, characterized in that, The predefined rules in the rule repair include: For rescue plans with over-allocated resources, implement down-allocation or replace the dispatch center; For rescue plans that are not feasible, the route planning tool is invoked again to generate new rescue routes; For rescue events with missing coverage, a corresponding backup rescue plan is generated based on the context object at the current time step; For rescue plans that are implemented without requiring revision, the rescue plan is restored to the rescue plan of the previous time step; and for rescue plans that require revision but are not implemented, revision control is issued for the rescue plan.

4. The flood emergency response plan generation method based on a large model intelligent agent according to claim 1, characterized in that, The maintenance rules for the resource list include: During runtime initialization, the initial inventory of various resources of each rescue center is read from the scenario configuration and written into the resource list; After the final structured rescue action plan is determined at each time step, the resource occupancy corresponding to the rescue plan for the newly added rescue event is registered, the resource occupancy of the revised rescue plan is updated, and the original resource occupancy registration is maintained for the unrevised rescue plan. When a rescue event is completed, the resource occupation of the rescue plan corresponding to that rescue event is released.

5. The flood emergency response plan generation method based on a large model intelligent agent according to claim 1, characterized in that, Generate a list of affected entries, including: Compare the set of blocked road segments in the current time step with the set of blocked road segments in the previous time step, and mark the newly added blocked road segments in the current time step as newly added blocked road segments; Determine whether the rescue routes of each rescue plan in the final structured rescue action plan of the previous time step pass through the newly blocked road section; The rescue plan that passes through the newly blocked road section will be revised and marked accordingly; Determine whether the resources allocated to each rescue plan in the final structured rescue action plan of the previous time step are still available; Mark the rescue plans for which allocated resources are unavailable with resource reallocation; generate a list of affected entries based on the rescue plans with route revision marks and the rescue plans with resource reallocation marks.

6. The flood emergency response plan generation method based on a large model intelligent agent according to claim 1, characterized in that, The target dataset also includes: candidate response strategy suggestions based on matching rescue event type and rescue event severity level, and text evidence fragments retrieved from the emergency knowledge base. The candidate response strategy suggestions and the text evidence fragments are used to provide the large model agent with a normative basis for generating structured rescue action plans. Retrieve textual evidence fragments from the emergency knowledge base, including: Based on the cities affected by flooding, a set of candidate files is selected from a pre-maintained file-level metadata index; Based on the type and severity of the rescue event, matching text evidence fragments are retrieved from the candidate file set, and evidence citation identifiers are bound to the text evidence fragments.

7. The flood emergency response plan generation method based on a large model intelligent agent according to claim 6, characterized in that, The constraint test also includes the evidence binding test; The evidence binding verification includes checking whether the evidence citation identifier of the text evidence fragment referenced in the final structured rescue action plan is the same as the evidence citation identifier of the text evidence fragment retrieved at the current time step.

8. The flood emergency response plan generation method based on a large model intelligent agent according to claim 1, characterized in that, When the invoked tool is a path planning tool, the corresponding tool is invoked through the tool invocation command, executed based on the execution parameter data, and the corresponding execution results are output, including: Based on the set of starting points, ending points, and blocked road sections of the rescue event in the execution parameter data, the path planning tool performs a risk-weighted shortest path search on the road network map; By returning infinite weights to blocked road sections through a dynamic weighting function, road sections are eliminated, and the path planning results corresponding to the rescue event are obtained. The path planning results include route polylines, distances, estimated arrival times, and maximum water depths along the way. The dynamic weighting function is: w(e)=l(e)×(1+α×max(0,d(e)-d_ref)), where l(e) is the road segment length, d(e) is the current water depth of the road segment, d_ref is the safe reference water depth, and α is the risk penalty coefficient.

9. The flood emergency response plan generation method based on a large model intelligent agent according to claim 1, characterized in that, The invoked tool also includes: an intelligent retrieval tool; the execution parameter data in the tool invocation instruction of the intelligent retrieval tool is the query question that the large model agent wants to ask, generated by the context object at the current time step.

10. A flood emergency response plan generation system based on a large-scale intelligent agent model, characterized in that, The system includes: The context object construction module is used to construct a context object based on the target dataset of the city where the flood occurred at the current time step. The target dataset includes at least: a resource list, a rescue event list, a set of blocked road sections, a list of affected items, a structured rescue action plan from the previous time step, and the corresponding execution results. The list of affected items records rescue plans that existed in the previous time step and need to be revised in the current time step. The target dataset of the first time step does not include the structured rescue action plan and the corresponding execution results from the previous time step. The tool invocation instruction generation module is used to input the context object of the current time step into the large model agent for text reasoning and output a structured tool invocation instruction. The tool invocation instruction contains the execution parameter data required for the invoked tool to execute. The invoked tool includes at least a path planning tool and a resource query tool. The tool invocation processing module is used to invoke the corresponding tool through the tool invocation command, execute it based on the execution parameter data, and output the corresponding execution result. The scheme generation module is used to generate a structured rescue action scheme for the first round in the current time step, based on the context object and the execution result. In the non-first rounds of the current time step, the module controls the large model agent to generate a structured rescue action scheme for the non-first round by inputting the context object, the structured rescue action scheme output by the large model agent in the previous round, and the execution result returned by the tool call in the previous round. After generating a preset number of structured rescue action schemes, the structured rescue action scheme generated in the last round is determined as the final structured rescue action scheme for the current time step. The implementation and update module is used to implement rescue operations based on the final structured rescue operation plan, and update the rescue event list and resource list. The updated rescue event list and resource list will be used as input to the large model agent in the next time step to dynamically generate a structured rescue operation plan.

Images