A dynamic self-adaptive agent method and system in the field of water conservancy

Abstract

The application relates to the technical field of artificial intelligence, in particular to a dynamic self-adaptive Agent method and system in the field of water conservancy. The method dynamically loads a tool and generates a system instruction through an external configuration file, so that the core Agent code does not need to be changed when water conservancy functions are added, deleted or modified, the flexibility and maintainability of the system are greatly improved, and the system is convenient for quickly responding to changes in business requirements; the system instruction generated dynamically ensures that the Agent always knows the exact function set available at present and the calling mode thereof, the accuracy and reliability of intention recognition in a specific water conservancy field are improved; a hybrid execution strategy decouples time-consuming operations from the core of the Agent, asynchronous processing and streaming response SSE are realized through an API service layer, long-time waiting is avoided, the response speed of the system and the fluency of user interaction are significantly improved, and the user experience and system efficiency are optimized; the application can flexibly adapt to changes in water conservancy business functions, efficiently process different types of tasks, and has good expansibility and practicality.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and more specifically, to a dynamic adaptive agent method and system for the field of water conservancy. Background Technology

[0002] The water conservancy industry is a vital foundational industry related to the national economy and people's livelihood. Its informatization is crucial for improving the efficiency and scientific nature of water resource management, flood control and drought relief, and water conservancy project scheduling. Traditional water conservancy information systems typically provide fixed user interfaces and functional modules. Users need to interact with the system by clicking menus and filling out forms, resulting in relatively fixed operating procedures and a low level of intelligence.

[0003] In recent years, with the development of Large Language Models (LLM) and intelligent agent technologies, it has become possible to control complex systems and complete specific tasks using natural language interaction. General-purpose agent systems can understand user intent and execute tasks by calling predefined tools (APIs, functions, etc.). However, directly applying general-purpose agent technology to specialized fields (such as water conservancy) faces many challenges: Fixed functionality and poor scalability: Traditional agent systems typically define their available toolset during the development phase. When it is necessary to add, delete, or modify water conservancy business functions (such as integrating new hydrological models or adding new data query interfaces), it is often necessary to modify the core code of the agent and retrain or adjust the model, resulting in high maintenance costs and poor flexibility.

[0004] Low efficiency in handling complex tasks: Some tasks in the water resources field may involve complex calculations, invoking external time-consuming services (such as running hydrological models to simulate flood evolution), or processing large amounts of data. If the process relies entirely on the synchronous execution logic within the Agent, it may result in long waiting times for users, slow response times, and a poor user experience.

[0005] Limited Response Patterns: Different water conservancy tasks may require different response formats. For example, simple data queries may expect quick, structured results, while complex contingency plan generation may require a step-by-step presentation of the analysis process and final recommendations, possibly accompanied by charts and graphs. General-purpose agent systems often employ a single response pattern, making it difficult to meet diverse interaction needs.

[0006] Insufficient domain adaptability: The system prompts of general agents are usually fixed and cannot accurately reflect the business logic and currently available functions of a specific domain (such as water conservancy), which may lead to inaccurate intent identification or invocation of the wrong tools.

[0007] For example, Chinese patent document CN115018298A discloses a real-time flood control dynamic adaptive scheduling method for reservoir groups based on a cyber-physical system. This method includes: establishing a real-time flood control dynamic scheduling cyber-physical system for reservoir groups; establishing an agent-based dynamic scheduling model for reservoir groups and storing it in the real-time flood control dynamic scheduling cyber-physical system; employing a spatial-magnitude dual random flood sample simulation method, simulating the diversity of future flood scenarios through random sampling of flood magnitude and spatial random combination, obtaining a simulated random flood sample set, and storing it in the real-time flood control dynamic scheduling cyber-physical system for reservoir groups; and importing the simulated real-time flood sample set into the agent-based dynamic scheduling model for reservoir groups to achieve dynamic adaptive scheduling of flood control for the reservoir groups. However, this method has a relatively rigid system architecture, relying on predefined physical models and parameters. It cannot dynamically load or unload business tools through configuration files, nor does it have the ability to extend new data sources or analysis functions without modifying the core code. This makes it difficult to solve the problems of rigid interaction and high maintenance costs for function expansion in water conservancy business software.

[0008] For example, Chinese patent document CN119129561A discloses a method for constructing an intelligent agent driven by tools in the water conservancy field based on a large language model. This method aggregates external services and general tools needed by users into toolsets specifically for water conservancy projects. For registered toolsets, it registers corresponding water conservancy-related tools. It fine-tunes the large language model to obtain the adjusted model weights, enhancing the accuracy of inference during the toolset selection phase. Based on the toolset selection method, it analyzes the user's problem and selects a toolset that can solve it. It then constructs an adaptive toolflow based on the user's intent, creating an executable solution for a tool. The toolflow results are verified, and the execution results are fed back to the user. Finally, the large language model is used to summarize the results and output multiple modal formats. However, to ensure the accuracy of tool calls, it employs a computationally expensive "multi-model voting verification mechanism," resulting in an excessively long system inference chain and extremely high response latency, making it difficult to meet the stringent real-time requirements of scenarios such as water conservancy emergency command. Furthermore, this method lacks an asynchronous streaming feedback mechanism for long-running tasks, leaving users in a state of blind waiting during task execution; and it does not design a non-intelligent fast channel for simple, high-frequency commands such as page navigation, resulting in all operations having to go through complex model reasoning, which wastes computing resources and reduces interaction efficiency.

[0009] Therefore, existing technologies for applying intelligent agents to specialized fields such as water conservancy suffer from problems such as difficulty in dynamically adjusting functions, low efficiency in handling complex tasks, and room for improvement in user interaction. There is an urgent need for a new technological solution that enables agent systems in the water conservancy field to adapt more flexibly to functional changes, efficiently handle different types of tasks, and provide a superior user interaction experience. Summary of the Invention

[0010] This invention aims to overcome the problems of existing intelligent agent systems in the water conservancy field, such as fixed functions, poor scalability, slow response when handling complex or time-consuming tasks, and insufficient domain adaptability. It provides a dynamic adaptive agent method and system for the water conservancy field. This method and system can flexibly adapt to changes in water conservancy business functions, efficiently handle different types of tasks, and optimize the user interaction experience.

[0011] The detailed technical solution of this invention is as follows: A dynamic adaptive agent method for the water conservancy field, the method comprising: S1. Read the preset configuration file, which defines multiple water conservancy field functional tools and their respective activation status; S2. Based on the configuration file described in step S1, automatically identify the currently enabled set of tools; S3. Adaptive System Command Generation: Based on the set of enabled tools identified in step S2, dynamically generate or modify the Agent's system-level commands so that the system-level commands contain only the calling rules and descriptions of the enabled tools. S4. Configure the Agent module using the dynamically generated or modified system-level instructions described in step S3; S5. The configured Agent module receives user queries in the field of water conservancy, performs intent recognition based on the system-level instructions, determines whether the user needs to call and which enabled water conservancy function tool to call, and extracts the necessary parameters. S6. Based on the preset hybrid execution strategy, determine the task execution category corresponding to the intent identified by the Agent module in step S5.

[0012] According to a preferred embodiment of the present invention, step S1 involves reading a YAML-formatted configuration file containing a set of tools, "API_EXECUTED_TOOLS", that is executed directly and independently by the API execution layer.

[0013] More preferably, the tool entries in the tool set include the tool's unique name "name", the path of the Python module that implements the tool "module", the tool's class name "class", and a boolean enable status flag "enabled".

[0014] More preferably, the unique name of the tool "name" includes the intelligent scheduling plan generation tool "generate_scheduling_plan" and the pump station status query tool "get_pump_station_status".

[0015] According to a preferred embodiment of the present invention, step S2 includes: S21. Parse the configuration file and iterate through all tool entries in the toolset; S22. Filter out tool entries with the enabled status flag set to "true"; S23. Extract the names of the enabled tools entries to form an enabled tools set.

[0016] According to a preferred embodiment of the present invention, the system-level instructions for dynamically generating or modifying the Agent module based on the set of enabled tools identified in step S2, as described in step S3, include: S31. Load a predefined system-level instruction template “SYSTEM_PROMPT_TEMPLATE” that contains all possible tool invocation rules and descriptions, wherein the system-level instruction template uses specific tags to delineate instruction text blocks associated with each tool; S32. Traverse all tool names that are defined in the configuration file but not identified as enabled in step S2; S33. For each unenabled tool name, use regular expressions or other string processing methods to remove the corresponding instruction text block from the system-level instruction template; S34. Output the abridged system-level instruction template as the final dynamic system-level instruction used to configure the Agent module.

[0017] More preferably, the specific marker includes TOOL_BLOCK:<tool_name> START and TOOL_BLOCK:<tool_name> END.

[0018] According to a preferred embodiment of the present invention, step S4 includes: When initializing the Agent module, the system-level instruction generated in step S3 is passed to the Agent module as the system message role="system"; Alternatively, when the Agent module processes each user query, this system-level instruction can be provided to the Agent module as the first message in the dialogue context.

[0019] According to a preferred embodiment of the present invention, step S5 includes: The S51 Agent module combines user queries with contextual information containing dynamic system-level instructions, and leverages its internal large language model capabilities to analyze the intent of user queries based on the rules and tool descriptions defined in the system-level instructions. S52. Determine whether the user's intent matches the functionality of an enabled tool; S53. If a match is found, determine the name of the tool to be called and extract the required parameters from the user query according to the tool definition; if no tool is matched, determine that the tool will not be called.

[0020] Preferably, the preset hybrid execution strategy described in step S6 is as follows: The system determines whether the identified intent belongs to the predefined list API_EXECUTED_TOOLS. If it is in the list, it is determined to be a specific type of task requiring external interaction or time consumption; if it is not in the list, it belongs to other task types. The predefined list API_EXECUTED_TOOLS includes: Intelligent scheduling plan generation tool (generate_scheduling_plan): Used to generate flood control scheduling suggestions based on user intent and hydrological models, including the parameter query (the user's complete query text). Pump station status query tool (get_pump_station_status): Used to obtain the current unit operating status and instantaneous flow data of the pump station, with no input parameters.

[0021] For specific task types that require external interaction or are time-consuming, the task is delegated to the API service layer for asynchronous execution and the results are returned in a streaming manner; other tasks are handled internally by Agen.

[0022] Further preferably, if the task type belongs to a predefined specific task type that requires external interaction or is time-consuming, the Agent outputs the intent recognition result, including the selected tool name and parameters extracted from the user query, and passes the result to the API service layer; the API service layer performs the corresponding operation according to the received tool name and parameters, and returns the execution result asynchronously; If the task type does not fall into the above categories, the Agent will directly handle the tool invocation and execution, and generate a response.

[0023] More preferably, the API service layer performs corresponding operations based on the received tool name and parameters, and returns the execution result asynchronously, including: By using server-side event sending (SSE) method, intermediate information or final results during the execution process are gradually pushed to the user end in the form of streaming data blocks, achieving rapid feedback and a smooth interactive experience.

[0024] Preferably, after performing data query operations, the API service layer can dynamically format the obtained structured data into a user-friendly text format, and can further call a large language model to intelligently summarize the data or answer the user's original questions based on the data.

[0025] This invention also provides a dynamic adaptive agent system for the water conservancy field, the system comprising: The configuration storage module is used to store configuration files that define multiple functional tools in the water conservancy field and their activation status; The tool loading and registration module is used to read the configuration file when the system starts, load the enabled tools, and register their instances or references to the set of enabled tools; The instruction generation module interacts with the tool loading and registration module to dynamically generate or modify system-level instructions for the Agent to use, based on the currently enabled set of tools. The Agent module is configured with dynamically generated or modified system-level instructions to receive user queries in the water conservancy field, perform intent recognition, determine whether to call and which enabled water conservancy function tools to call, and differentiate the processing tasks according to a preset hybrid execution strategy: for tasks that require external interaction or time-consuming operations, the intent recognition result (tool name and parameters) is output; for other tasks, the tool call and execution are completed internally. The API service layer module receives the intent recognition result from the Agent module, searches the tool registry to obtain the corresponding tool execution logic, performs operations that require external interaction or are time-consuming, and returns the result asynchronously to the user.

[0026] Preferably, the API service layer module uses a Server Sending Event (SSE) server to asynchronously push execution results in the form of streaming data blocks.

[0027] Preferably, the API service layer module further includes a data formatting and summarizing unit, which is used to convert the structured data obtained by the query tool into a preset text format, and can call the large language model LLM service to summarize the results.

[0028] Compared with the prior art, the present invention has the following significant advantages: (1) This invention proposes an intelligent agent method and system for the field of water conservancy information technology, particularly an agent system and method that can dynamically adapt to functional changes and adopt a hybrid execution strategy. By dynamically loading tools and generating system instructions through external configuration files, adding, deleting or modifying water conservancy functions does not require modification of the core agent code, which greatly improves the system's flexibility and maintainability and facilitates rapid response to changes in business needs.

[0029] (2) Enhanced domain adaptability: Dynamically generated system instructions ensure that the Agent always knows the exact set of functions currently available to it and how to invoke them, improving the accuracy and reliability of intent identification in specific water conservancy fields.

[0030] (3) Optimized performance and user experience: The hybrid execution strategy decouples time-consuming operations from the Agent core, and avoids long waiting times through asynchronous processing and streaming response (SSE) of the API service layer, which significantly improves the system's response speed and the smoothness of user interaction, and optimizes user experience and system efficiency.

[0031] (4) Enhanced intelligence level: It integrates special tools for the water conservancy field (such as intelligent scheduling plan generation and hydrological parameter extraction), and combines LLM for data summarization and natural language generation, which improves the intelligence level and practicality of the system in handling water conservancy professional tasks.

[0032] (5) Good scalability: The modular design makes it easy to add new water conservancy functions and tools, and the system has good scalability. Attached Figure Description

[0033] Figure 1 This is a flowchart of a method for a dynamic adaptive agent system in the field of water conservancy, as described in this invention; Detailed Implementation The present invention will be further described below with reference to the accompanying drawings and a specific embodiment, so that users can more clearly understand the technical solution of the present invention. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.

[0034] Example 1 This embodiment provides a dynamic adaptive agent method for the water conservancy field, such as... Figure 1 As shown, it includes the following steps: S1. Read the preset configuration file, which defines multiple water conservancy field functional tools and their respective activation status, such as enabled / disabled; Dynamic configuration loading and identification: When the system starts or runs, it first reads the preset configuration file, such as the YAML file agent / config / tools_config.yaml. This file contains a set of tools "API_EXECUTED_TOOLS" that is executed directly and independently by the API execution layer. The tool entries in the set of tools include the unique name of the tool "name", the path of the Python module that implements the tool "module", the class name of the tool "class", and a boolean enable status flag "enabled".

[0035] The unique name of the tool "name" includes the intelligent scheduling plan generation tool "generate_scheduling_plan" and the pump station status query tool "get_pump_station_status".

[0036] S2. Based on the configuration file described in step S1, automatically identify the currently enabled tool set: S21. Parse the configuration file and iterate through all tool entries in the toolset; S22. Filter out tool entries with the enabled status flag set to "true"; S23. Extract the names of the enabled tools entries to form an enabled tools set.

[0037] S3. Adaptive System Prompt Generation: Based on the set of enabled tools identified in step S2, dynamically generate or modify the Agent's system-level prompts, so that the system-level prompts contain only the calling rules and descriptions of the enabled tools; This process is achieved by loading a template containing all possible tool rules and removing instruction blocks corresponding to disabled tools, ensuring that the final system instructions are accurate and only contain the functions available to the current Agent and their invocation rules. Specifically: S31. Load a predefined system-level instruction template "SYSTEM_PROMPT_TEMPLATE" that contains all possible tool invocation rules and descriptions, wherein the system-level instruction template uses the specific flag boundary TOOL_BLOCK.<tool_name> START and TOOL_BLOCK:<tool_name> END is the instruction text block associated with each tool; S32. Traverse all tool names that are defined in the configuration file but not identified as enabled in step S2; S33. For each unenabled tool name, use regular expressions or other string processing methods to remove the corresponding instruction text block from the system-level instruction template; S34. Output the abridged system-level instruction template as the final dynamic system-level instruction used to configure the Agent module.

[0038] S4. Agent Configuration: Configure the Agent module using the dynamically generated or modified system-level instructions described in step S3; When initializing the Agent module, the system-level instruction generated in step S3 is passed to the Agent module as the system message role="system"; Alternatively, when the Agent module processes each user query, this system-level instruction can be provided to the Agent module as the first message in the dialogue context.

[0039] S5. The configured Agent module receives user queries in the field of water conservancy, performs intent recognition based on the system-level instructions, determines whether the user needs to call and which enabled water conservancy function tool to call, and extracts the necessary parameters. The S51 Agent module combines user queries with contextual information containing dynamic system-level instructions, and leverages its internal Large Language Model (LLM) capabilities to analyze the intent of user queries based on the rules and tool descriptions defined in the system-level instructions. S52. Determine whether the user's intent matches the functionality of an enabled tool; S53. If a match is found, determine the name of the tool to be called and attempt to extract the required parameters from the user query based on the tool definition (parameters); if no tool is matched, determine that the tool will not be called.

[0040] S6. Based on the preset hybrid execution strategy, determine the task execution category corresponding to the intent identified by the Agent module in step S5.

[0041] The preset hybrid execution strategy specifically determines whether the identified intent belongs to the predefined list API_EXECUTED_TOOLS. If it is in the list, it is determined to be a specific task type requiring external interaction or time consumption; if it is not in the list (e.g., the hydrological parameter extraction tool extract_hydrology_parameters), it belongs to other task types. The predefined list API_EXECUTED_TOOLS includes: Intelligent scheduling plan generation tool (generate_scheduling_plan): Used to generate flood control scheduling suggestions based on user intent and hydrological models, including the parameter query (the user's complete query text). Pump station status query tool (get_pump_station_status): Used to obtain the current unit operating status and instantaneous flow data of the pump station, with no input parameters.

[0042] The corresponding task execution categories include: For specific types of tasks that require external interaction or are time-consuming, the task is delegated to the API service layer for asynchronous execution and the results are returned in a streaming manner; other tasks are handled internally by Agen.

[0043] API Layer Execution Path: If the task belongs to a predefined category requiring external interaction or time-consuming operations, such as calling an external hydrological model, querying a database, or generating complex contingency plans, the Agent only outputs the intent recognition result, including the tool name and parameters, and passes this information to the API service layer. Upon receiving this information, the API service layer is responsible for executing the specific operation and asynchronously returning the result to the user.

[0044] Agent internal execution path: If the task does not belong to the above categories, such as simple parameter structure extraction, the tool call and execution are directly completed by the Agent, and a response is generated.

[0045] Asynchronous and streaming responses apply to API layer execution paths: For tasks executed by the API service layer, the results can be returned asynchronously.

[0046] Specifically, the server-side event sending (SSE) technology is used to gradually push intermediate information or final results during the execution process to the user end in the form of streaming data blocks, thereby achieving rapid feedback and a smooth interactive experience.

[0047] Results processing and presentation: After performing data query operations, the API service layer can dynamically format the obtained structured data into a user-friendly text format (such as Markdown tables), and can further call a large language model (LLM) to intelligently summarize the data or answer the user's original questions based on the data.

[0048] Example 2 This embodiment provides a dynamic adaptive agent system for the water conservancy field, the system comprising: The configuration storage module is used to store configuration files that define multiple functional tools in the water conservancy field and their activation status; The tool loading and registration module is used to read the configuration file when the system starts, load the enabled tools, and register their instances or references to the set of enabled tools; The instruction generation module interacts with the tool loading and registration module to dynamically generate or modify system-level instructions for the Agent to use, based on the currently enabled set of tools. The Agent module is configured with dynamically generated or modified system-level instructions to receive user queries in the water conservancy field, perform intent recognition, determine whether to call and which enabled water conservancy function tools to call, and differentiate the processing tasks according to a preset hybrid execution strategy: for tasks that require external interaction or time-consuming operations, the intent recognition result (tool name and parameters) is output; for other tasks, the tool call and execution are completed internally. The API service layer module receives the intent recognition result from the Agent module, searches the tool registry to obtain the corresponding tool execution logic, performs operations that require external interaction or are time-consuming, and returns the result asynchronously to the user.

[0049] The API service layer module uses a Server Send Event (SSE) server to asynchronously push execution results in the form of streaming data blocks.

[0050] The API service layer module also includes a data formatting and summarizing unit, which is used to convert the structured data obtained by query tools into a preset text format and can call a large language model (LLM) service to summarize the results.

[0051] Example 3 Process the user query "Rainfall 200, generate a dispatch plan". This embodiment simulates the entire process of how the dynamic adaptive agent method and system for the water conservancy field described in this invention handles the user's query "rainfall 200, generate scheduling plan" through the user interface (UI).

[0052] S1-S2: System Initialization and Configuration Loading Upon system startup, steps S1 and S2 have already been executed. Specifically, the "tool loading and registration module" reads the preset YAML configuration file "agent / config / tools_config.yaml". This file defines water conservancy-related functional tools, including "generate_scheduling_plan" (intelligent scheduling plan generation tool) and "get_pump_station_status" (pump station status query tool), and their "enabled" status. The loading module identifies that the "generate_scheduling_plan" tool is currently enabled (enabled: true) and registers it along with other enabled tools into the toolset (such as TOOL_REGISTRY).

[0053] S3-S4: Dynamic Command Generation and Agent Configuration Based on the set of enabled tools identified in step S2 (including "generate_scheduling_plan"), the "instruction generation module" processes the system-level instruction template (SYSTEM_PROMPT_TEMPLATE). Since the "generate_scheduling_plan" tool is enabled, its corresponding instruction text block is retained in the final generated dynamic system-level instructions. However, if a tool in the configuration file (such as "get_pump_station_status" – a pump station status query tool) is disabled, its corresponding instruction block is removed. The generated dynamic system-level instructions are then used to configure the "Agent module," for example, as the initial system message when processing user requests.

[0054] S5: User Query Reception and Intent Recognition The user enters the query "Rainfall 200, generate scheduling plan" through the user interface. This query is sent to the "API service layer module" and routed to the "Agent module" via the API entry point. The Agent combines the current user query with the dynamic system-level instructions configured in step S4, utilizing its internal Large Language Model (LLM) capabilities for intent recognition. Since the query contains the keyword "generate scheduling plan," and this keyword matches the calling rules defined for the "generate_scheduling_plan" tool in the dynamic instructions, the Agent determines that the user's intent is to invoke the "generate_scheduling_plan" tool. Simultaneously, based on the tool's parameter definition (requiring the user's complete original query text as the "query" parameter), the Agent extracts "{"query": "Rainfall 200, generate scheduling plan"}" as the calling parameter.

[0055] S6: Hybrid Execution Strategy Judgment The Agent then determines the task type of the "generate_scheduling_plan" tool based on the preset hybrid execution strategy. It queries the predefined list "API_EXECUTED_TOOLS" and finds that "generate_scheduling_plan" is included in the list. Therefore, the Agent determines that the task belongs to the category that needs to be executed by the API service layer (requiring external interaction or time-consuming operations).

[0056] API layer execution path Agent outputs intent results: The Agent stops generating its own response and outputs the intent recognition result { "tool_name": "generate_scheduling_plan", "tool_params": "{\"query\": \"Rainfall 200, generate scheduling plan\"}"} to the API service layer.

[0057] API Layer Reception and Execution: The API service layer receives the result. Based on the tool name "generate_scheduling_plan", it looks up the corresponding tool class "GenerateSchedulingPlanTool" in the tool registry. The API layer instantiates the tool and calls its instance's "call" method, passing in necessary information including the query text and the knowledge base name obtained from the request context.

[0058] Internal execution of the tool (taking generate_scheduling_plan as an example): The “call” method first extracts the rainfall “200” from the “query” parameter (and may confirm the unit or default it, such as mm).

[0059] The rainfall pattern is determined based on the knowledge base name (e.g., "Water Conservancy - Bailang River Reservoir"), and the "calculate_rainfall" function is called to generate a rainfall sequence.

[0060] Call "db_query" to asynchronously query the database to obtain the current water level of the reservoir.

[0061] Call "run_hydrologic_model" to run the hydrological model asynchronously to obtain the runoff process.

[0062] Calculate the future water level process curve using "WaterLevelCalculator" and the water level-capacity relationship of the reservoir.

[0063] Obtain the reservoir's scheduling rule text "SCHEDULE_DICT".

[0064] The system constructs prompts that include forecast results (such as peak flow, flood volume, water level process, and whether the flood limit is exceeded) and scheduling rules, and calls LLM to generate natural language scheduling plan suggestions.

[0065] The "call" method is designed as an asynchronous generator that gradually "yields" text containing forecast information, graphical data (such as rainfall-runoff relationships and water level process data), and LLM-generated contingency plan text blocks.

[0066] Asynchronous and Streaming Response: The API service layer uses Server Send Events (SSE) technology. It asynchronously receives each data block (whether text fragments or chart data) from the "call" method of the "generate_scheduling_plan" tool and immediately encapsulates these data blocks into SSE events and pushes them to the front-end user interface. Users will first see information from the analysis process (such as predicted runoff depth and flood peak information), then charts, and finally the generated scheduling plan text, presented step by step without waiting for the entire process to complete.

[0067] Example 4: Process the user query "10cm of rainfall in Yi County".

[0068] S1-S2: System Initialization and Configuration Loading Upon system startup, steps S1 and S2 have already been executed. Specifically, the "tool loading and registration module" reads the preset YAML configuration file "agent / config / tools_config.yaml". This file defines water conservancy-related functional tools, including "generate_scheduling_plan" (intelligent scheduling plan generation tool), "extract_hydrology_parameters" (hydrological parameter extraction tool), and "get_pump_station_status" (pump station status query tool), and their "enabled" status. The loading module identifies that the "generate_scheduling_plan" tool is currently enabled (enabled: true) and registers it along with other enabled tools in the "tool registry" (such as TOOL_REGISTRY).

[0069] S3-S4: Dynamic Command Generation and Agent Configuration Based on the set of enabled tools identified in step S2 (including "generate_scheduling_plan" (intelligent scheduling plan generation tool) and "extract_hydrology_parameters" (hydrological parameter extraction tool)), the "instruction generation module" processes the system-level instruction template (SYSTEM_PROMPT_TEMPLATE). Since the tools "generate_scheduling_plan" (intelligent scheduling plan generation tool) and "extract_hydrology_parameters" (hydrological parameter extraction tool) are enabled, their corresponding instruction text blocks are retained in the finally generated dynamic system-level instruction. Assuming that a certain tool in the configuration file (such as "get_pump_station_status" (pump station status query tool)) is set to disabled, its corresponding instruction block will be removed. The generated dynamic system-level instruction is then used to configure the "Agent module", for example, as the initial system message when processing user requests.

[0070] Agent Internal Execution Path At step S5, Agent identifies the intention to call the "extract_hydrology_parameters" tool. During the judgment at step S6, it is found that this tool is not in the "API_EXECUTED_TOOLS" list. Therefore, Agent directly calls the "call" method of "ExtractHydrologyParametersTool" internally. This method performs parameter extraction and unit conversion (10 cm -> 100 mm) and generates the result JSON string {"basin_name": "Yixian", "rainfall_amount": {"value": 100, "unit": "mm"}}. Agent then returns this JSON string as the final response to the API layer, and the API layer sends it to the user interface at once.

[0071] To verify the technical advantages of the "dynamic adaptive Agent construction method" proposed in this invention in terms of intention recognition accuracy, system response speed, and interaction experience, this specification sets up an experimental comparison between the method of this invention and two comparative examples.

[0072] Comparative Example 1: Static Instruction Construction Method (1) Construction Method Method of this invention: The system reads the configuration file and only dynamically loads the tool descriptions with the status of enabled: true into the system prompt, that is, System Prompt.

[0073] Comparative Example 1: Using the existing static build method. The system does not recognize the enabled state and concatenates the description information of all registered tools in the tool library, including disabled, testing, or functionally redundant tools, into SystemPrompt.

[0074] (2) Experimental scenario: Set the user query as: "Please extract hydrological parameters based on the current water and rainfall situation". Prerequisite: In the configuration file, generate_scheduling_plan is disabled, and extract_hydrology_parameters is enabled only.

[0075] Results: The example accurately hit the target; Comparative Example 1 caused confusion (illusion) for the Agent because the Prompt contained a similar disabling tool, as shown in Table 1.

[0076] Table 1. Comparison of the effects of the method of the present invention and Comparative Example 1

[0077] Comparative Example 2: Single Agent Execution Strategy (1) Construction method: The method of this invention employs a "hybrid execution strategy". The Agent is only responsible for identifying the intent, while time-consuming tasks (such as plan generation) are intercepted and distributed to the API layer, and intermediate results are streamed through SSE (Server-Sent Events).

[0078] Comparative Example 2: A single agent synchronous execution strategy is used. No API_EXECUTED_TOOLS interception mechanism is set; all tools are called synchronously within the agent. The model must wait for the tools to finish running and obtain all returned results before it begins generating a response.

[0079] (2) Experimental scenario: The user query is set as: "Rainfall 150mm, generate scheduling plan." (Typical long-time calculation task) Example: Within 0.5 seconds, the user receives the feedback "Calculating...", followed by a real-time display of runoff charts and flood peak data on the screen within 5 seconds, and finally the contingency plan recommendations are displayed word by word.

[0080] Comparative Example 2: The user interface spins for about 35 seconds (in a seemingly frozen state) until all model calculations are completed in the background, at which point all results are displayed at once.

[0081] Table 2 Comparison of the effects of the method of the present invention and Comparative Example 2

[0082] Through the above embodiments and comparative examples, it is demonstrated how the method and system of the present invention can flexibly and efficiently process natural language queries in the water conservancy field through dynamic configuration, adaptive instructions, hybrid execution strategies, and streaming responses, especially for tasks involving complex calculations and requiring step-by-step feedback (such as scheduling plan generation), providing an optimized user experience. This reflects the beneficial effects of the present invention, such as flexibility, domain adaptability, performance optimization, and improved intelligence.

Claims

1. A dynamic adaptive agent method for the field of water conservancy, characterized in that, The method includes: S1. Read the preset configuration file, which defines multiple water conservancy field functional tools and their respective activation status; S2. Based on the configuration file described in step S1, automatically identify the currently enabled tool set; S3. Adaptive System Command Generation: Based on the set of enabled tools identified in step S2, dynamically generate or modify the Agent's system-level commands so that the system-level commands contain only the calling rules and descriptions of the enabled tools. S4. Configure the Agent module using the dynamically generated or modified system-level instructions described in step S3; S5. The configured Agent module receives user queries in the field of water conservancy, performs intent recognition based on the system-level instructions, determines whether the user needs to call and which enabled water conservancy function tool to call, and extracts the necessary parameters. S6. Based on the preset hybrid execution strategy, determine the task execution category corresponding to the intent identified by the Agent module in step S5.

2. The dynamic adaptive agent method for the water conservancy field according to claim 1, characterized in that, In step S1, a YAML-formatted configuration file is read. This file contains a set of tools "API_EXECUTED_TOOLS" that is executed directly and independently by the API execution layer. Preferably, the tool entries in the tool set include the tool's unique name "name", the path of the Python module implementing the tool "module", the tool's class name "class", and a boolean enabled status flag "enabled". More preferably, the tool's unique name "name" includes the intelligent scheduling plan generation tool "generate_scheduling_plan" and the pump station status query tool "get_pump_station_status".

3. The dynamic adaptive agent method for the water conservancy field according to claim 2, characterized in that, Step S2 includes: S21. Parse the configuration file and iterate through all tool entries in the toolset; S22. Filter out tool entries with the enabled status flag set to "true"; S23. Extract the names of the enabled tools entries to form an enabled tools set.

4. The dynamic adaptive agent method for the water conservancy field according to claim 1, characterized in that, The system-level instructions for dynamically generating or modifying the Agent module based on the set of enabled tools identified in step S2, as described in step S3, include: S31. Load a predefined system-level instruction template "SYSTEM_PROMPT_TEMPLATE" that contains all possible tool invocation rules and descriptions, wherein the system-level instruction template uses specific tags to delineate instruction text blocks associated with each tool; S32. Traverse all tool names that are defined in the configuration file but not identified as enabled in step S2; S33. For each disabled tool name, remove the corresponding instruction text block from the system-level instruction template; S34. Output the abridged system-level instruction template as the final dynamic system-level instruction used to configure the Agent module; preferably, the specific flags mentioned in step S31 include TOOL_BLOCK:<tool_name> START and TOOL_BLOCK:<tool_name> END.

5. The dynamic adaptive agent method for the water conservancy field according to claim 1, characterized in that, Step S4 includes: When initializing the Agent module, the system-level instruction generated in step S3 is passed to the Agent module as the system message role="system"; Alternatively, when the Agent module processes each user query, this system-level instruction can be provided to the Agent module as the first message in the dialogue context.

6. The dynamic adaptive agent method for the water conservancy field according to claim 1, characterized in that, Step S5 includes: The S51 Agent module combines user queries with contextual information containing dynamic system-level instructions, and leverages its internal large language model capabilities to analyze the intent of user queries based on the rules and tool descriptions defined in the system-level instructions. S52. Determine whether the user's intent matches the functionality of an enabled tool; S53. If a match is found, determine the name of the tool to be called and extract the required parameters from the user query according to the tool definition; if no tool is matched, determine that the tool will not be called.

7. The dynamic adaptive agent method for the water conservancy field according to claim 2, characterized in that, The preset hybrid execution strategy mentioned in step S6 is as follows: The agent determines whether the identified intent belongs to the predefined list API_EXECUTED_TOOLS. If it is in the list, it is determined to be a specific task type that requires external interaction or is time-consuming. If it is not in the list, it belongs to other task types. Preferably, if the task type belongs to a specific task type that requires external interaction or is time-consuming, the agent outputs the intent identification result, including the selected tool name and the parameters extracted from the user query, and passes the result to the API service layer. The API service layer performs corresponding operations based on the received tool name and parameters, and returns the execution result asynchronously. If the task type does not belong to the above categories, the Agent directly completes the tool invocation and execution, and generates a response. More preferably, the API service layer performs corresponding operations based on the received tool name and parameters, and returns the execution result asynchronously, including: using the server to send events (SSE) to gradually push intermediate information or final results during the execution process to the user terminal in the form of streaming data blocks.

8. A system for implementing the dynamic adaptive agent method in the water conservancy field as described in any one of claims 1-7, characterized in that, The system includes: The configuration storage module is used to store configuration files that define multiple functional tools in the water conservancy field and their activation status; The tool loading and registration module is used to read the configuration file when the system starts, load the enabled tools, and register their instances or references to the set of enabled tools; The instruction generation module interacts with the tool loading and registration module to dynamically generate or modify system-level instructions for the Agent to use, based on the currently enabled set of tools. The Agent module is configured with dynamically generated or modified system-level instructions to receive user queries in the water conservancy field, perform intent recognition, determine whether to call and which enabled water conservancy function tools to call, and differentiate the processing tasks according to a preset hybrid execution strategy: for tasks that require external interaction or time-consuming operations, the intent recognition result is output; for other tasks, the tool call and execution are completed internally. The API service layer module receives the intent recognition result from the Agent module, searches the tool registry to obtain the corresponding tool execution logic, performs operations that require external interaction or are time-consuming, and returns the result asynchronously to the user.

9. The system according to claim 8, characterized in that, The API service layer module uses a server-sending event (SSE) server to asynchronously push execution results in the form of streaming data blocks.

10. The system according to claim 8, characterized in that, The API service layer module also includes a data formatting and summarizing unit, which is used to convert the structured data obtained by query tools into a preset text format and can call the large language model LLM service to summarize the results.

Images