A multi-model agent adaptive arrangement and execution method and system

Abstract

The application provides a multi-model intelligent agent adaptive arrangement and execution method and system, the method comprises the following steps: obtaining target model parameter information and reconstructing the parameter information into a parameter constraint set, performing parameter consistency, resolution consistency and physical constraint verification on the intelligent agent generation parameter execution unit, and encapsulating; scanning the state of the calculation node to build an environment vector before calling a software tool, generating an adapter according to an interaction mode and analyzing an output stream; decomposing a scientific task into a subtask sequence and building a directed acyclic graph dependency graph, generating an execution queue and identifying parallel branches, establishing a cross-model mapping channel to realize data conversion; setting a checkpoint during the execution process, performing double verification of rules and statistics on the output result, and triggering a self-healing process in case of abnormality. The application realizes a complete closed loop from parameter docking to arrangement and execution to reliability guarantee of a scientific investigation task, and is suitable for extreme environment scientific investigation.

Description

Technical Field

[0001] This invention belongs to the field of computer science and technology, specifically relating to a method and system for adaptive orchestration and execution of multi-model intelligent agents. Background Technology

[0002] Scientific expeditions, as a core means for humankind to understand nature, explore the unknown, and reveal the laws of nature, permeate multiple disciplines such as earth science, environmental science, and life science. Their findings are of irreplaceable importance for understanding the laws of natural evolution, responding to environmental changes, and developing new resources. With the increasing demands for natural exploration, the scope of scientific expeditions has gradually extended to extreme and complex environments such as the deep sea, polar regions, high altitudes, and deserts. The complexity and difficulty of expedition tasks are also continuously increasing, placing increasingly stringent requirements on expedition efficiency, data accuracy, and operational safety.

[0003] Traditional scientific expeditions, which rely on manual operation and expert decision-making, not only face prominent problems of high cost, high risk, and low efficiency in the front-end data collection stage, but also suffer from serious bottlenecks in the back-end scientific data processing, intelligent analysis, experimental verification, and results transformation stages: multi-source heterogeneous data is difficult to integrate and process efficiently and automatically; massive amounts of observational data rely on manual experience mining; and there is a disconnect between field observation and indoor experiments and numerical simulations. As a result, the scientific data obtained at high cost cannot be intelligently processed, efficiently reused, rapidly verified, and deeply applied, making it difficult to support the needs of large-scale, high-timeliness, and multidisciplinary scientific expeditions and decision-making in the new era.

[0004] In recent years, breakthroughs in artificial intelligence, robotics, and high-precision sensor technologies have laid the foundation for innovation in scientific research models. Intelligent agents are highly compatible with the needs of intelligent scientific research, capable of handling complex tasks and uncertainties, and promoting the intelligent, autonomous, and efficient development of scientific research. Their development exhibits several trends: enhanced large language models make intelligent agents more intelligent in scientific research task planning and tool invocation, enabling them to handle complex and abstract tasks; future integration of multimodal data will allow for a comprehensive and accurate understanding of tasks; they possess cross-domain collaboration capabilities, integrating multidisciplinary knowledge and tools to solve problems; and they can also adapt and self-optimize based on feedback, dynamically adjusting strategies to improve the efficiency of scientific research execution.

[0005] Although existing intelligent agent construction technology and automatic task orchestration technology have achieved relatively mature applications in many fields, they still have significant limitations when applied to spatiotemporal science tasks and cannot meet the core needs of scientific research intelligent agents.

[0006] With the rapid development of intelligent agent technology, automated task execution has become a key research direction in this field, aiming to achieve efficient and accurate processing of complex tasks and improve the practicality and adaptability of intelligent agents in real-world application scenarios. Currently, the closest solution to existing technologies for automated task execution is the "task planning and standard tool invocation scheme based on thought chain". This scheme is similar to the tool invocation pattern of the ReAct framework or LangChain in terms of technical architecture and implementation logic.

[0007] This solution fully leverages the powerful logical reasoning capabilities of large language models to meticulously break down complex user requests into a linear sequence of subtasks. The agent, through a "tool learning" interface, accurately identifies predefined external tools. These tools are typically standardized RESTful APIs or Python functions. Based on the subtask sequence, the agent generates corresponding invocation instructions sequentially, thereby enabling the invocation of these external tools.

[0008] In terms of tool integration methods, existing technologies typically rely on a crucial assumption: that external tools possess standardized interface descriptions, such as JSON Schema or OpenAPI documentation. The agent accurately fills in the required parameters based on these standardized interface descriptions, and then initiates HTTP requests or function calls. After obtaining the results returned by the external tool, the agent further plans subsequent actions based on these results to ensure the gradual progress of the task.

[0009] In terms of programming logic, existing technologies mainly adopt a "single-threaded linear execution" model. In this model, the agent executes subtasks strictly in sequence; that is, after completing step 1, it carefully plans the content of step 2 based on the result of step 1, then executes step 2, and so on, until the entire task is completed. While this linear execution model is logically clear and easy to implement, it may lack flexibility when handling complex tasks.

[0010] In terms of result reliability verification, existing technologies mainly use a combination of manual sampling and automated testing to check the rationality and accuracy of subtask decomposition in order to ensure the reliability of task execution results.

[0011] Despite the progress made in automating task execution, existing technologies still face numerous challenges and significant limitations when dealing with complex and ever-changing scientific research scenarios: (1) Difficulty in parameter alignment. Scientific models have extremely strict requirements on the units, spatiotemporal resolution, and format of input data. Large language models are prone to illusions or ignore physical constraints.

[0012] (2) It is difficult to effectively manage the complex dependencies between multiple models and build long-chain automated workflows. Compared with the traditional tool calling and execution process, the execution of scientific research tasks is inherently difficult and has a long cycle. Scientific tasks are mostly "long-field" tasks, which require intelligent agents to carry out multi-step and coherent planning. For example, completing the complete workflow of "slope analysis of a certain area → data clipping → slope clipping → result visualization" involves multiple software and steps. Any error in any link will lead to failure.

[0013] (3) The complexity of the environment and interaction has not yet been systematically addressed. Scientific software environments are far more complex than everyday applications. Scientific tools (such as Geographic Information Systems, GIS) typically have non-standard input / output flows and complex configuration logic to execute tasks. Intelligent agents need to adapt to these diverse interaction patterns and cannot rely on unified web pages or API interfaces. The interaction process heavily relies on deep domain knowledge. Intelligent agents must not only understand the operation instructions but also the scientific concepts and background knowledge behind the task in order to better complete the arrangement and invocation of tools.

[0014] (4) Low reliability of execution results. There is still a significant gap between the current low fault tolerance requirements of tasks and the reliability level of existing intelligent agents.

[0015] In summary, existing technologies for the orchestration and execution of multi-model agents in scientific expeditions still suffer from prominent problems, including difficulties in parameter alignment, complex management of multi-model dependencies, insufficient adaptation to scientific research software environments, and low reliability of execution results. How to achieve adaptive orchestration and highly reliable execution of agents across multiple models in the highly specialized, complex, and fault-tolerant application scenario of scientific expeditions has become a pressing technical challenge in this field. Summary of the Invention

[0016] This invention aims to overcome the problems of existing intelligent agent technology in scientific research task execution, such as difficulties in parameter alignment, management of complex multi-model dependencies, insufficient adaptation to scientific research software environments, and low reliability of execution results. It provides a method and system for adaptive orchestration and execution of multi-model intelligent agents. Its core lies in constructing a complete closed-loop system from model parameter specification alignment to long-link task orchestration to reliability assurance by introducing a model parameter constraint awareness and alignment mechanism, a software environment awareness and non-standard interaction adaptation mechanism, a multi-model dependency management and long-link workflow construction mechanism, and an execution monitoring and multi-dimensional result verification mechanism. Among them, the parameter constraint awareness and alignment mechanism transforms the initial parameters generated by the large language model into a final input format that conforms to the scientific model specification through physical constraint awareness and intermediate parameter representation, solving the problems of parameter illusion and physical violation; the environment awareness and adaptation mechanism generates input adapters to shield the instruction differences between different computing platforms by sensing the state of computing nodes and identifying the interaction mode of software tools, realizing adaptive invocation in multiple environments; the multi-model dependency management and long-link workflow construction mechanism manages the data flow and dependency relationships between multiple models through directed acyclic graphs, completes cross-model parameter mapping and parallel scheduling, and realizes the construction and collaborative execution of long-link scientific tasks; the execution monitoring and multi-dimensional result verification mechanism triggers a hierarchical self-healing process when execution anomalies occur through checkpoints and multiple consistency checks, meeting the high reliability requirements of low fault-tolerant tasks. The collaborative work of the various modules of the system enables the execution of scientific expeditions to form a complete closed loop, from model parameter generation, software environment adaptation, long-link orchestration and scheduling to execution monitoring and self-healing. This significantly reduces the technical threshold for the execution of scientific expeditions, improves the data processing efficiency, operational safety and reliability of scientific research results, and provides stable, intelligent and efficient technical support for scientific expeditions in extreme environments such as polar regions, deep seas and high altitudes.

[0017] To address the aforementioned problems, the first aspect of this invention provides a multi-model intelligent agent adaptive orchestration and execution method, comprising: Step S1, acquiring parameter information of the target model and reconstructing it into a parameter constraint set; performing unit consistency detection and conversion, spatiotemporal resolution consistency detection and resampling, and physical legality and constraint condition verification on the initial parameters generated by the intelligent agent based on the parameter constraint set; and encapsulating the verified parameters into the final input format required by the target model; Step S2, before calling the software tool, scanning the underlying state of the current computing node and constructing an environment state vector; dynamically generating an input adapter according to the interaction mode of the software tool; executing the software tool call and performing structured parsing on the output stream of the software tool; Step S3, decomposing the scientific task into a sequence of sub-tasks; constructing a task dependency graph in the form of a directed acyclic graph; generating an executable queue and identifying parallel executable task branches; and establishing a cross-model parameter mapping channel to realize the conversion from upstream model output to downstream model input; Step S4, identifying key steps and inserting state checkpoints during task execution; performing dual verification of the model output results by rule verification and statistical verification; and triggering a self-healing process in response to verification anomalies.

[0018] The multi-model intelligent agent adaptive orchestration and execution method provided in this application is based on the construction of a complete closed-loop process of "parameter specification matching to environment adaptation and then to task orchestration and reliable execution" through the sequential execution of steps S1 to S4. Step S1 involves acquiring the parameter information of the target model and reconstructing it into a set of parameter constraints. It performs unit consistency checks and conversions, spatiotemporal resolution consistency checks and resampling, and physical validity and constraint condition verifications on the initial parameters generated by the agent. The verified parameters are then encapsulated into the final input format required by the target model. Step S2 involves scanning the underlying state of the current computing node and constructing an environment state vector before calling the software tool. An input adapter is generated based on the interaction mode of the software tool, and the software tool is called, with its output stream structured and parsed. Step S3 involves decomposing the scientific task into a sequence of sub-tasks, constructing a task dependency graph in the form of a directed acyclic graph, generating an executable queue and identifying parallelizable task branches. A cross-model parameter mapping channel is established to convert the upstream model output to the downstream model input. Step S4 involves identifying key steps and inserting state checkpoints during task execution, performing dual verification of the model output results using both rule-based and statistical methods, and triggering a self-healing process in response to verification anomalies. The four steps work together to form a complete closed loop, from model parameter standardization and long-link task orchestration to execution reliability assurance. This significantly reduces the technical threshold for scientific expeditions, improves the data processing efficiency and reliability of scientific research results, and provides stable and efficient technical support for scientific expeditions in extreme environments.

[0019] Further, step S1 includes: Step S11, obtaining parameter information of the target model and reconstructing it into a standardized set of parameter constraints using a predefined metadata template; Step S12, in response to initial parameter data generated by the agent or input from the outside, forcibly constructing an intermediate parameter representation, wherein the intermediate parameter representation includes at least parameter name, original value, original unit, original spatiotemporal resolution, and data source identifier; Step S13, traversing each parameter in the intermediate parameter representation, semantically comparing its original unit with the target unit defined in the parameter constraint set, and generating a unit inconsistency interruption flag and suspending the parameter transmission process when a unit mismatch is detected; Step S14, when the unit inconsistency interruption flag is triggered, calling the unit knowledge graph or conversion engine, matching the conversion formula based on the principle of dimensional analysis, and executing it. Numerical conversion; Step S15: Align the time step and spatial grid size of the input data with the resolution required by the target model. When there is a resolution inconsistency, select a resampling algorithm based on the physical properties of the parameters; Step S16: Substitute the parameter data with consistent units and resolution into the constraint discrimination function group defined by the parameter constraint set for final verification. The constraint discrimination function group is used to verify at least the physical boundaries, value range, spatiotemporal applicability conditions, cross-parameter logical relationships, and conservation constraints of the parameters. When all constraint discrimination results meet the preset legality conditions, the final verification is considered to be passed. When any constraint discrimination result does not meet the legality conditions, a self-correction mechanism is triggered; Step S17: Encapsulate the parameters that have passed the final verification into the final input format required by the target model and enter the subsequent model execution stage.

[0020] Further, in step S11, the standardized set of parameter constraints is formally described as a quintuple: C M ={(p i ,t i ,u i ,r i ,Ω i )} Where, p i t is the parameter name. i For parameter data types, u i r is the physical unit of the parameter. i Ω represents the spatiotemporal resolution to which the parameters apply. i The physical boundary constraints are parameters that transform natural language constraints into machine-verifiable mathematical rules.

[0021] Further, in step S16, the self-correction mechanism is executed based on a correction rule table, which includes at least the following: for continuous interval constraints, depending on the degree of deviation, direct truncation to the boundary, truncation with alarm recording and triggering secondary verification, or rejection with intelligent weight generation; for enumeration or category constraints, correction based on a mapping table, regeneration if mapping fails; for unit or dimensional constraints, conversion and recalculation, or regeneration with manual confirmation; for cross-parameter relationship constraints, regeneration is prioritized without hard truncation; for spatiotemporal structure constraints, alignment processing is performed, regeneration if failure occurs; for conservation constraints, normalization or conservation correction, rollback and regeneration, or calling a backup algorithm are performed depending on the degree of deviation; for data quality constraints, interpolation or neighborhood patching, or blocking and regeneration are performed depending on the degree of deviation.

[0022] Further, step S2 includes: step S21, starting an environment probe before calling any software tool, scanning the underlying state of the current computing node, and constructing an environment state vector; step S22, reading the meta-description file of the software tool or executing help instructions, and classifying the interaction mode of the software tool into streaming interaction type, file-driven type, or command-line parameter type; step S23, dynamically generating an input adapter based on the parameter data output in step S1 and the interaction mode classified in step S22, and executing the software tool call; step S24, monitoring the execution output stream of the software tool and the intermediate files generated, and extracting key information from the unstructured running log using a predefined regular expression library or log parser, and converting it into a structured JSON object.

[0023] Further, in step S21, the environmental state vector is represented as: E=(OS type ,Lib versions ,Env vars Resource quota ) Among them, OS type Indicates the operating system type and version, Lib versions This represents the set of versions of key dependency libraries, compilation environments, and runtime components in the current node. vars Resource represents the set of environment variables that affect the operation of software tools. quota This indicates the available computing, storage, and scheduling resource quotas for the current node.

[0024] Furthermore, in step S23, the method of generating the input adapter includes: for file-driven software tools, using a template engine to fill the parameter data output in step S1 into a standard configuration file template; for command-line software tools, concatenating Shell command strings that conform to the syntax rules; and for streaming interactive software tools, constructing an answering machine to simulate human input.

[0025] Further, step S3 includes: step S31, receiving a scientific task described in natural language, and recursively decomposing it into a sequence of subtasks using the planning capability of a large language model, wherein each subtask corresponds to a specific computational model or data processing tool; step S32, analyzing the input and output metadata of each subtask, inferring the data flow relationship between tasks, and constructing a task dependency graph in the form of a directed acyclic graph; step S33, performing a topological sorting algorithm on the task dependency graph to generate a linear executable queue, identifying mutually independent subgraph branches and marking them as parallelizable execution blocks; step S34, establishing cross-model parameter mapping channels for adjacent nodes in the task dependency graph to realize the conversion from upstream model output to downstream model input.

[0026] Furthermore, the cross-model parameter mapping channel is implemented in the following way: cross-model parameter mapping is performed first based on a predefined mapping table; when there is no corresponding mapping item in the predefined mapping table or there are multiple candidate items, a semantic similarity matching algorithm is called to generate candidate mapping relationships, and the candidates are filtered in combination with constraints on units, formats, resolutions, and variable types; the semantic similarity matching algorithm calculates the comprehensive matching score between variable pairs based on string similarity and text embedding vector similarity according to the following formula: ; Among them, S s S represents string similarity. e The similarity of the text embedding vectors is represented; the string similarity is calculated according to the following formula: ; Where, N s N represents the source model parameters. t The target model parameters are represented by d, and the edit distance is represented by L. s L represents the character length of the source model parameter. t The character length represents the target model parameter, and max indicates the maximum value; the text embedding vector similarity is calculated according to the following formula: ; Among them, V s V represents the text embedding vector corresponding to the source model parameters. tThe text embedding vector represents the target model parameters; when the comprehensive matching score is higher than a preset threshold, semantic consistency is determined and a parameter mapping relationship is established.

[0027] Furthermore, step S3 also includes step S35, which includes: monitoring the data stream in real time during task execution; immediately verifying whether the output of the upstream model meets the input constraints of the downstream model when the upstream model completes the calculation; if not, immediately blocking the start of the downstream model, recording the anomaly type, anomaly variables, original logs and associated checkpoint information, and generating structured fault diagnosis data; determining whether repair conditions are met based on the anomaly type, and triggering a self-healing process if they are; and continuing to schedule and execute independent parallel branches that are not affected by the anomaly to avoid unnecessary interruption of the global task execution process.

[0028] Further, step S4 includes: step S41, identifying high-risk or high-computational-cost critical steps during task execution, inserting state checkpoints before and after the critical steps, backing up the current working state before execution for recovery from the most recent checkpoint in case of anomalies; step S42, performing dual verification of rule verification and statistical verification after the model outputs results; step S43, triggering a self-healing process when anomalies are detected during verification.

[0029] Further, in step S42, the rule verification includes: checking the file integrity, format correctness, and whether it contains necessary metadata; the statistical verification includes: calculating the statistical characteristics of the output result and comparing it with historical benchmark values ​​or experience distributions, and marking it as a suspicious result if the deviation exceeds a preset threshold.

[0030] Furthermore, the self-healing process includes: in response to a verification anomaly, firstly identifying the anomaly type and assessing its severity; when the anomaly manifests as local non-numerical values, minor out-of-bounds errors, numerical non-convergence, or log indications that it can be repaired by adjusting the time step or convergence threshold, performing parameter adjustment or retrying; when the anomaly manifests as missing output files, corrupted format, large-area outliers, multiple core variables being abnormal simultaneously, overall deviation of statistical distribution, or the number of parameter fine-tuning retries exceeding a preset threshold, performing path rollback, restoring the working state from the most recent checkpoint, and attempting to call a backup model or backup algorithm; when rollback and backup model or backup algorithm still cannot eliminate the anomaly, suspending the task and generating a fault diagnosis report, and requesting manual intervention.

[0031] According to another aspect of the present invention, the present invention also provides a multi-model intelligent agent adaptive orchestration and execution system, the system comprising: a data alignment module configured to acquire parameter information of a target model and reconstruct it into a set of parameter constraints, perform unit consistency detection and conversion, spatiotemporal resolution consistency detection and resampling, physical legality and constraint condition verification on the initial parameters generated by the intelligent agent based on the set of parameter constraints, and encapsulate the verified parameters into the final input format required by the target model; an environment adaptation module configured to scan the underlying state of the current computing node and construct an environment state vector before calling the software tool, dynamically generate an input adapter according to the interaction mode of the software tool, execute the software tool call and perform structured parsing of the output stream of the software tool; a task orchestration module configured to decompose the scientific task into a sequence of sub-tasks, construct a task dependency graph in the form of a directed acyclic graph, generate an executable queue and identify task branches that can be executed in parallel, establish a cross-model parameter mapping channel to realize the conversion from upstream model output to downstream model input; and a monitoring and verification module configured to identify key steps and insert state checkpoints during task execution, perform dual verification of the model output results by rule verification and statistical verification, and trigger a self-healing process in response to verification anomalies.

[0032] The multi-model intelligent agent adaptive orchestration and execution system provided in this application is based on the core of constructing a complete closed-loop architecture that connects parameter specification to environment adaptation and then to task orchestration and reliable execution through the sequential collaboration of data alignment module, environment adaptation module, task orchestration module and monitoring and verification module. The data alignment module acquires the parameter information of the target model and reconstructs it into a set of parameter constraints. It performs unit consistency checks and conversions, spatiotemporal resolution consistency checks and resampling, and physical legality and constraint condition verifications on the initial parameters generated by the agent. The verified parameters are then encapsulated into the final input format required by the target model. The environment adaptation module scans the underlying state of the current computing node and constructs an environment state vector before calling the software tool. It generates an input adapter based on the interaction mode of the software tool, executes the software tool call, and performs structured parsing on its output stream. The task orchestration module decomposes the scientific task into a sequence of sub-tasks, constructs a task dependency graph in the form of a directed acyclic graph, generates an executable queue, identifies parallelizable task branches, and establishes a cross-model parameter mapping channel to realize the conversion from upstream model output to downstream model input. The monitoring and verification module identifies key steps and inserts state checkpoints during task execution. It performs dual verification of the model output results using rule verification and statistical verification, and triggers a self-healing process in response to verification anomalies. The four modules work together to form a complete closed loop from model parameter standardization to long-link task orchestration to execution reliability, significantly reducing the technical threshold for scientific expeditions, improving data processing efficiency and reliability of results, and providing stable and efficient technical support for scientific expeditions in extreme environments.

[0033] Furthermore, the data alignment module has a built-in unit knowledge graph or conversion engine, as well as physical boundary verification logic. When it is detected that the unit of the initial parameter is inconsistent with the unit required by the target model, numerical conversion is performed. When it is detected that the parameter exceeds the physical extreme value, truncation or error processing is performed.

[0034] Furthermore, the self-healing process includes: in response to a verification anomaly, identifying the anomaly type and assessing its severity; when the anomaly is a repairable type, performing parameter adjustment or retry; when parameter fine-tuning and retry fail or the anomaly is an unrepairable type, performing path rollback, rolling back to the previous checkpoint and attempting to call a backup model or backup algorithm; when rollback and backup model or backup algorithm still cannot eliminate the anomaly, suspending the task and generating a fault diagnosis report, requesting manual intervention.

[0035] The above-described technical solution of the present invention has the following beneficial technical effects: 1. Achieved highly reliable parameter alignment and physical compliance control for multi-model agents: By introducing intermediate parameter representations as an auditable buffer between the agent and the scientific model, the parameter generation process and the parameter usage process are decoupled, effectively isolating the inherent "illusion" risk of large language models. Combining dimensional analysis from unit knowledge graphs or conversion engines, spatiotemporal resolution consistency detection and resampling, final verification based on physical constraint discriminant function sets, and a hierarchical self-correction mechanism, a complete parameter alignment chain of "detection-judgment-conversion-verification-correction" is formed. This fundamentally prevents incorrect units, mismatched resolutions, or physically non-compliant parameters from flowing into the scientific model, ensuring the rigor and reliability of scientific computing input parameters.

[0036] 2. It overcomes the limitations of non-standard scientific research software environments on automated execution, achieving multi-platform adaptive invocation: By constructing an environment state vector containing operating system type, dependent library version, environment variables, and resource quotas through environment probes, it proactively perceives the underlying state of computing nodes before task execution, identifying hidden environment problems (e.g., MPI library version conflicts, CUDA driver incompatibility, etc.), ensuring that planned tasks are "physically executable" in the current environment. Simultaneously, by identifying three interaction modes of scientific software—streaming interaction, file-driven, and command-line parameters—it dynamically generates corresponding input adapters, masking instruction differences between different computing platforms. This allows the same orchestration scheme to adaptively run on heterogeneous platforms such as local workstations, high-performance computing clusters, and cloud servers, significantly reducing the technical threshold for cross-platform deployment of scientific tasks.

[0037] 3. Automated construction and efficient collaboration of heterogeneous multi-model long-link tasks: By using a directed acyclic graph to uniformly model the data flow and dependencies between multiple models, and combining topological sorting to generate a linear executable queue and automatically identify branches that can be executed in parallel, long-link tasks that traditionally relied on manual orchestration are transformed into an automated scheduling process. Through a cross-model parameter mapping channel that combines predefined mapping tables and semantic similarity matching, variable name renaming and file format conversion (such as GRIB2 to NetCDF) are automatically completed, solving the problem of inconsistent interface definitions between scientific models, achieving seamless connection from upstream model output to downstream model input, and significantly improving the execution efficiency of multi-model collaboration.

[0038] 4. The system endows the scientific expedition agent with "scientific-grade" execution reliability and self-healing capabilities: By automatically inserting status checkpoints before and after key workflow steps and backing up the working state, combined with a dual verification mechanism of rule-based and statistical verification, the system performs multi-dimensional verification of output results regarding file integrity, format correctness, and statistical characteristics, establishing a full-process reliability assurance system of "pre-backup - in-process monitoring - post-verification." When a verification anomaly is detected, the system automatically performs self-healing processes such as parameter adjustment or retry, path rollback and backup model invocation, and manual intervention requests based on the anomaly type. This effectively avoids the cascading propagation of errors in long chains and achieves automatic fault recovery of tasks under unattended conditions, meeting the stringent reliability requirements of low-fault-tolerance scientific expedition tasks. Attached Figure Description

[0039] Figure 1 This is a flowchart of a multi-model intelligent agent adaptive orchestration and execution method in an embodiment of the present invention; Figure 2 This is a flowchart illustrating a multi-model intelligent agent adaptive orchestration and execution method in a specific embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a multi-model intelligent agent adaptive orchestration and execution system in an embodiment of the present invention. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0041] To address the challenges of parameter alignment, complex multi-model dependencies, insufficient software tool interoperability, and low reliability of execution results in existing agent technologies for scientific computing tasks, this invention proposes a multi-model agent adaptive orchestration and execution method and system. This method constructs a complete closed loop from model parameter specification alignment to multi-model task orchestration and reliability assurance through a workflow executed sequentially from steps S1 to S4. Specifically, step S1 performs model parameter constraint awareness and automatic alignment, transforming the initial parameters generated by the agent into an input format conforming to the target model specification; step S2 performs software environment awareness and non-standard interaction adaptation, masking instruction differences between different computing platforms; step S3 decomposes the task into a sequence of sub-tasks, constructing a directed acyclic graph to manage data flow and dependencies between multiple models, achieving automated construction and collaborative execution of long-link tasks; and step S4 sets checkpoints during execution and performs multiple verifications on the output results, triggering a self-healing process in response to anomalies. By executing each step in a coordinated manner, a complete closed loop can be achieved, from parameter generation, environment adaptation, task orchestration to execution monitoring and self-healing. This significantly reduces the technical threshold for scientific computing tasks and improves data processing efficiency and the reliability of results.

[0042] The following is combined with Figures 1 to 3 This paper describes the multi-model intelligent agent adaptive orchestration and execution method and system provided by the present invention.

[0043] Figure 1 This is a flowchart of a multi-model intelligent agent adaptive orchestration and execution method in an embodiment of the present invention.

[0044] like Figure 1 As shown, this embodiment provides a multi-model intelligent agent adaptive orchestration and execution method, which includes the following four main steps: I. Model Parameter Constraint Awareness and Automated Alignment S1: Obtain the parameter information of the target model and reconstruct it into a parameter constraint set. Based on the parameter constraint set, perform unit consistency detection and conversion, spatiotemporal resolution consistency detection and resampling, physical legality and constraint condition verification on the initial parameters generated by the agent. Encapsulate the verified parameters into the final input format required by the target model.

[0045] This step addresses the mismatch between the "physical illusion" and the specifications when agents generate parameters. It decouples the parameter generation process from the parameter usage process by establishing an auditable intermediate parameter representation between the agent and the scientific model.

[0046] Specifically, step S1 includes the following sub-steps: S11: Acquisition of Model Parameter Constraint Information and Standardized Modeling. Obtain the parameter information of the target model by parsing the model interface document, reading the header file, or calling the self-describing interface to obtain the original parameter specifications. Use the predefined metadata template to reconstruct the above discrete information into a standardized set of parameter constraints. The predefined metadata template includes the following: (1) Parameter identification information template, including parameter name, alias, description and module; (2) Parameter type template, including data type, data structure and dimension; (3) Parameter physical semantic template, including physical unit, dimension and physical meaning; (4) Spatiotemporal attribute template, including time resolution, spatial resolution, coordinate reference system and coverage; (5) Constraint rule template, including upper and lower bounds of values, enumeration set, condition constraints and cross-parameter dependencies; (6) Interface attribute template, including required or optional identifiers, default values, input and output directions and file format.

[0047] The set of parameter constraints is formally described as a quintuple: C M ={(p i ,t i ,u i ,r i ,Ω i )}, where p i t is the parameter name. i For parameter data types, u i r is the physical unit of the parameter. i Ω represents the spatiotemporal resolution to which the parameters apply. i The physical boundary constraints for the parameters (e.g., soil moisture content exceeding 50% and relative humidity between 0 and 100%) are used to transform natural language constraints into machine-verifiable mathematical rules. This step unifies the above information into a structured set of parameter constraints, transforming the model constraints, originally existing in natural language or unstructured form, into a standardized constraint model that can be automatically processed by the program, providing a formal basis for subsequent automatic verification.

[0048] S12: Construction of Intermediate Parameter Representation for Input Data. When the agent generates input data for the model or receives external data sources, it does not directly pass the data to the target model, but instead forces the construction of an intermediate parameter representation. This intermediate parameter representation is a structured data carrier, containing at least the parameter name, original value, original unit, and original spatiotemporal resolution, and may also include the data source identifier. Through this intermediate parameter representation, the system establishes an auditable buffer between the initial parameters generated by the agent and the precise input required by the scientific model, decoupling the parameter generation process from the parameter usage process, avoiding the agent directly outputting uncontrollable parameters, and effectively isolating the illusion risk of large models. The "illusion" here manifests specifically as follows: when generating input parameters for the scientific model, the large language model may generate parameters that do not exist in the interface definition; it may confuse internal code values, enumeration values, or ID mapping relationships; it may generate configurations that are inconsistent or conflicting between multiple parameters (e.g., start time later than end time); it may also generate parameter values ​​that exceed the physical scope, business scope, or tool-permitted range. Any of these forms of illusion may cause the scientific model to fail to execute correctly or produce incorrect results.

[0049] S13: Unit Consistency Check and Judgment. Traverse each parameter in the intermediate parameter representation, and match its original unit with the parameter constraint set (C). M The target units defined in the code are semantically compared. When a unit mismatch is detected (e.g., the input is mm / day, and the target model requires kg / m), the code will be executed. 2 / s), generates a unit inconsistency interruption flag and suspends the parameter passing process to prevent incorrect unit data from flowing into the model and causing calculation errors.

[0050] S14: Automatic Unit Conversion for Parameters. When a unit inconsistency flag is triggered, the unit knowledge graph or conversion engine is invoked to automatically convert the parameter values. The selection of either the "unit knowledge graph" or the "conversion engine" is based on the following: for simple unit conversions, solutions are first retrieved directly from the unit knowledge graph; when no corresponding conversion relationship exists in the unit knowledge graph or the conversion process is complex, the conversion engine is then used for calculation. In other words, solutions are first retrieved from the knowledge graph, and if that fails, the conversion engine is used. Based on the principle of dimensional analysis, conversion formulas are automatically matched and numerical conversions are performed to ensure consistency across different data sources at the physical dimension level.

[0051] S15: Spatiotemporal Resolution Consistency Detection and Resampling. The time step and spatial grid size of the input data are aligned with the resolution required by the target model. When resolution inconsistencies exist, a resampling algorithm is automatically selected based on the physical properties of the parameters. Specifically, different resampling strategies can be employed in the spatial and temporal dimensions depending on the variable type. For state-related variables, such as temperature, air pressure, and humidity, bilinear interpolation is typically used spatially and linear interpolation in time to obtain continuous and smooth estimates. For flux-related or cumulative variables, such as precipitation, runoff, and radiation flux, area-weighted or conservation remapping should be prioritized, with appropriate accumulation, averaging, or aggregation processing performed in the time dimension to maintain consistency in regional totals or time integrals as much as possible.

[0052] S16: Physical validity and constraint verification. After completing unit consistency (unit alignment) and spatiotemporal resolution consistency (spatiotemporal resolution alignment), the parameter data v with consistent units and resolution will be... final Substitute the parameter constraint set C M Ω i The defined set of constraint discriminant functions g i (v final The final calculation is performed. Where, v final This represents the final parameter data after unit conversion and resolution resampling; Ω i For physical boundary constraints of parameters (e.g., range of values, physical extrema, etc.); g i (v final The condition ≥ 0 is a constraint condition, indicating that the parameter data satisfies the i-th physical constraint. When this condition is not met, it means that the parameter data violates the corresponding physical constraint. This constraint discrimination function set is used to verify at least the physical boundaries, value range, spatiotemporal applicability conditions, cross-parameter logical relationships, and conservation constraints of the parameters.

[0053] When all constraint judgment results meet the preset legality conditions, the final verification is considered successful; when any constraint judgment result does not meet the legality conditions, i.e., g... i (v final When ≥0 is not true, a self-correction mechanism is triggered: specific constraint violation information is fed back to the agent (e.g., parameter X exceeds the range of 0-1), requiring regeneration or truncation of illegal values ​​to the legal range according to the constraint boundary.

[0054] This self-correction mechanism is executed based on a correction rule table, specifically including: For continuous interval constraints: when a parameter slightly exceeds the boundary (the deviation degree r ≤ 1%, and the absolute deviation is less than the tolerance ε), it is directly truncated to the boundary, where r represents the relative deviation degree of the parameter exceeding the constraint boundary (i.e., |actual value - boundary value| / boundary value), and ε represents the system preset tolerance threshold, which is used to determine whether the deviation is negligible; when the parameter moderately exceeds the boundary (1% < r ≤ 10%) and the variable is a smooth continuous quantity, truncation is performed and an alarm is recorded, and secondary verification is triggered when necessary; when the parameter severely exceeds the boundary (r > 10% or abnormality still exists after multiple retries), truncation is rejected, and intelligent body regeneration is fed back.

[0055] For enumeration or category constraints: when the parameter value is not in the legal set, correction is performed based on the mapping table; if mapping is not possible, regeneration is performed.

[0056] For unit or dimensional constraints: when the unit can be converted clearly, automatic conversion is performed followed by rechecking; when the unit semantics are unclear or the abnormality still exists after conversion, regeneration is performed or manual confirmation is requested.

[0057] For cross-parameter relationship constraints: when there is a conflict in logical sequence or dependency relationship, regeneration is prioritized, and hard truncation is not performed.

[0058] For spatiotemporal structure constraints: when grid / shape / CRS are incompatible, alignment processing is executed; if it fails, regeneration is performed.

[0059] For conservation constraints: when the total sum slightly deviates from 1 or the conserved quantity drifts slightly and the deviation is less than or equal to the conservation threshold δ, normalization or conservation correction is performed, where δ is a system preset allowable deviation threshold for the conserved quantity; when the conservation is severely violated and the deviation is greater than the threshold δ, rollback is performed followed by regeneration, or a backup algorithm is invoked.

[0060] For data quality constraints: when there are a small number of NaNs or isolated outliers in the parameter data and the proportion is less than or equal to the threshold α, interpolation or neighborhood inpainting is performed, where α is a system preset tolerance threshold for the proportion of outliers; when there are a large number of NaNs or entire missing blocks and the proportion is greater than the threshold α, blocking is performed followed by regeneration.

[0061] Through the above hierarchical self-correction mechanism, the system can automatically repair most parameter violation problems without manual intervention, which significantly improves the success rate and robustness of parameter alignment. For specific correction rules, refer to the correction rule table in Table 1.

[0062]

[0063] S17: Encapsulation and output of parameter alignment results. After all parameters pass the constraint verification, the aligned parameters are re-encapsulated into the final input format required by the target model, and the process proceeds to the subsequent model execution stage.

[0064] Through the coordinated operation of the above sub-steps, step S1 realizes the full-process parameter verification and automatic correction from the generation of agent parameters to the input of scientific models, fundamentally avoiding the problem of physical violation of parameters caused by the illusion of large language models, and ensuring the rigor and reliability of scientific computing input parameters.

[0065] II. Complex Software Environment Awareness and Non-standard Interaction Adaptation S2: Before calling the software tool, scan the underlying state of the current computing node and construct the environment state vector. Dynamically generate the input adapter according to the interaction mode of the software tool, execute the software tool call, and perform structured parsing of the output stream of the software tool.

[0066] This step addresses the challenges of implementing scientific computing environments due to their complex configurations and high heterogeneity. It uses environment state vectors to perceive the state of computing nodes and identify the interaction patterns of software tools, enabling adaptive multi-environment invocation.

[0067] Specifically, step S2 includes the following sub-steps: S21: Scientific Software Operating Environment Awareness. Before calling any software tools, first activate the environment probe to scan the underlying state of the current computing node and construct the environment state vector E=(OS type ,Lib versions ,Env vars Resource quota ) Among them, OS type Indicates the operating system type and version, Lib versions This represents the set of versions of key dependency libraries, compilation environments, and runtime components in the current node. vars Resource represents the set of environment variables that affect the operation of software tools. quota This indicates the available compute, storage, and scheduling resource quotas for the current node. These parameters are automatically obtained through operating system query commands, version query commands, environment variable enumeration interfaces, and resource monitoring interfaces. This step automatically identifies hidden environment issues such as MPI library version conflicts, CUDA driver incompatibility, and missing environment variables, ensuring that planned tasks are executable in the current environment. When the environment probe detects an anomaly, the system executes targeted environment repair or adaptation strategies based on the anomaly type, including dependency library version switching, environment variable completion, resource parameter adjustment, node migration, container replacement, and invoking backup tools. If automatic repair fails, the task is suspended, an environment diagnostic report is output, and manual intervention is requested.

[0068] S22: Tool Interaction Pattern Recognition. Read the software tool's meta-description file or execute help commands, and classify the software tool's interaction pattern into: streaming interaction type (requires real-time interaction via standard input and output), file-driven type (only accepts configuration files from specific paths), or command-line parameter type (all parameters must be flattened into command-line strings).

[0069] S23: Non-standard input construction. Based on the parameter data output in step S1 and the interaction patterns classified in step S22, an input adapter is dynamically generated: for file-driven software tools, template engines such as Jinja2 are used to fill the aligned parameters into a standard configuration file template; for command-line software tools, shell command strings conforming to syntax are automatically concatenated; for streaming interactive software tools, an automatic responder is built to simulate human input and execute software tool calls.

[0070] S24: Non-standard output parsing and structuring. Monitor the execution output stream and intermediate files generated by the software tool, and use a predefined regular expression library or log parser to extract key information from the unstructured runtime logs (e.g., Iteration 100: Loss = 0.01 or Error: Convergence failed), converting it into a structured JSON object for downstream module decision-making.

[0071] Through the coordinated operation of the above sub-steps, step S2 achieves adaptive adaptation to the non-standard interaction mode of scientific research software, shields the instruction differences between different computing platforms, and enables the same orchestration scheme to run adaptively on heterogeneous computing platforms, breaking through the limitations of non-standard scientific research software environments on automated execution.

[0072] In one specific embodiment, for the scientific task of "conducting high-resolution regional meteorological simulation of future climate scenarios in a certain river basin in Guangxi and outputting GIS-usable raster results", the specific execution process of step S2 is as follows: First, an environment probe is launched to scan the current computing node's operating system, MPI version, NetCDF dependencies, GDAL / QGIS toolchain, WPS / WRF executables, and environment variables, generating an environment state vector E=(OStype,Libversions,Envvars,Resourcequota). If qgis_process is detected as nonexistent while gdalwarp is available, the GIS data processing path is automatically switched to the GDAL command-line implementation.

[0073] Subsequently, by reading help information and meta description files, gdalwarp, ncdump, ncks, and cdo were identified as command-line parameter tools, while geogrid.exe, ungrib.exe, metgrid.exe, real.exe, and wrf.exe were identified as file-driven tools.

[0074] Next, based on the aligned task parameters, the system automatically generates namelist.wps, namelist.input, GDAL raster clipping commands, NetCDF check commands, and a WRF startup script, while monitoring stdout, stderr, and output files during execution. For gdalwarp output, the system extracts the output filename, size, and execution status; for ncdump output, it extracts variable, dimension, and attribute information; and for wrf.exe logs, it extracts the time progression status, successful completion markers, and exception information (such as NetCDF I / O errors or NaN warnings), and converts all results into structured JSON for subsequent dependency consistency checks and exception recovery modules.

[0075] III. Multi-model Dependency Management and Long-Link Workflow Construction S3: Decompose the scientific task into a sequence of subtasks, construct a task dependency graph in the form of a Directed Acyclic Graph (DAG), generate an executable queue and identify task branches that can be executed in parallel, and establish a cross-model parameter mapping channel to realize the transformation from upstream model output to downstream model input.

[0076] This step is used to automate the orchestration of multi-step, multi-model scientific tasks. It uses a directed acyclic graph to uniformly manage the data flow and dependencies between multiple models, enabling the automated construction and collaborative execution of long-link scientific tasks.

[0077] Specifically, step S3 includes the following sub-steps: S31: Structured Decomposition of Scientific Tasks. A scientific task described in natural language (e.g., simulating climate change in a region over the next 50 years and assessing crop yields) is received and recursively decomposed into a sequence of subtasks using the planning capabilities of a large language model. Each subtask corresponds to a specific computational model or data processing tool. Preferably, the scientific task is recursively decomposed into a sequence of atomic-level subtasks, for example, T = {t1, t2, ..., t...}. n}, where T represents the atomic-level subtask sequence, t nThis represents the nth atomic-level subtask, with each subtask corresponding to a specific computational model or data processing tool. By analyzing the semantic type, input-output characteristics, whether it involves solving physical mechanisms, and its runtime resource requirements, each atomic-level subtask is automatically mapped to a computational model invocation task or a data processing tool invocation task: subtasks aimed at numerical simulation and process derivation are mapped to computational models, while subtasks aimed at data preparation, transformation, cleaning, analysis, and visualization are mapped to data processing tools. The construction of computational model tasks follows a rule chain of "task semantic recognition - model selection - parameter constraint alignment - dependency binding - environment adaptation execution - result verification and feedback": the system first matches candidate computational models based on the target variables, spatiotemporal scale, and process type of the macro-task, then aligns the model's input execution unit, resolution, and physical boundary constraints, incorporates the model nodes into the directed acyclic graph workflow, and completes model invocation through an environment-aware input adapter. Checkpoints and consistency checks ensure the reliability of model execution. Data processing tools include the following major categories of operations: data download and reading, coordinate system unification, grid unification, unit conversion, band or variable extraction, spatiotemporal resampling, data fusion, outlier cleanup, and file packaging and output. Specific tools include, but are not limited to, GDAL, CDO, NCO, NCKS, GrADS, etc.

[0078] S32: Model Dependency Identification and Directed Acyclic Graph Construction. This involves analyzing the input and output metadata of each subtask, automatically inferring data flow relationships between tasks, and constructing a task dependency graph in the form of a directed acyclic graph. The task dependency graph construction process includes: obtaining a set of atomic-level subtasks; extracting and standardizing the input and output metadata of each subtask; performing input-output matching and compatibility analysis on any task pair; generating a set of candidate dependency edges; performing conflict resolution and loop detection; and finally forming a directed acyclic graph and marking independent branches that can be executed in parallel. "Automatic inference" refers to: based on the input and output metadata sets of each subtask, combined with variable name consistency, semantic similarity, predefined parameter mapping tables, data type compatibility, unit convertibility, spatiotemporal resolution alignment, coordinate reference system convertibility, and file format convertibility, automatically determining whether there are executable data flow relationships between tasks. When task t... j A certain input item can be generated by task t i When a certain output item is provided directly, or can be provided after variable renaming, unit conversion, format conversion, or resampling, a process is established from task t. i Pointing to task t j The directed edge e ijTask dependency graphs can be represented as linear serial patterns, one-to-many branching patterns, many-to-one convergence patterns, branch-convergence patterns, and hierarchical pipeline patterns. Different types of task nodes typically exhibit different typical structures in the dependency graph: data preprocessing nodes are often located at the front, forming serial or branching chains; single computational model nodes usually correspond to multi-input convergence structures; multi-model coupled systems typically form hierarchical pipelines or hub-type structures; evaluation and visualization nodes are usually located at the tail, forming convergence or terminal output structures. This task dependency graph is stored in memory in the form of an adjacency matrix or adjacency list. For example, a matrix element Aij=1 indicates that the output of model i is the input of model j.

[0079] S33: Workflow Topology Sorting and Execution Sequence Generation. A topology sorting algorithm is performed on the task dependency graph to generate a linear executable queue. Independent subgraph branches are identified and marked as parallelizable blocks, allowing them to be scheduled for parallel execution on different nodes of the high-performance computing cluster, thus improving the execution efficiency of long-chain tasks.

[0080] S34: Cross-model parameter mapping and transformation. For adjacent nodes in the task dependency graph, a cross-model parameter mapping channel is established. This channel resolves the issue of inconsistent interface definitions between models (e.g., the upstream output variable is named temp_sfc, and the downstream input variable is named T_2m). Specifically, cross-model parameter mapping is preferentially performed based on a predefined mapping table. When a corresponding mapping item does not exist in the predefined mapping table or multiple candidate items exist, a semantic similarity matching algorithm is invoked to generate candidate mapping relationships, and these are filtered based on constraints such as unit, format, resolution, and variable type. The predefined mapping table typically includes the upstream model name, variable name, unit, format; the downstream model name, variable name, unit, format; transformation rules; resampling rules; activation conditions; and priority. Depending on the actual application scenario, mapping relationships can be manually constructed based on professional names, or the table can be empty. This semantic similarity matching algorithm calculates the comprehensive matching score between variable pairs based on string similarity and text embedding vector similarity using the following formula: ; Among them, S s S represents string similarity. e The similarity of the text embedding vectors is represented; the string similarity is calculated according to the following formula: ; Where, N s N represents the source model parameters. t The target model parameters are represented by d, and the edit distance is represented by L. s L represents the character length of the source model parameter. t The character length represents the target model parameter, and max indicates the maximum value; the text embedding vector similarity is calculated according to the following formula: ; Among them, V s V represents the text embedding vector corresponding to the source model parameters. t This represents the text embedding vector corresponding to the target model parameters. When the overall matching score is higher than a preset threshold, it is determined that the upstream output variable and the downstream input variable are semantically consistent and a parameter mapping relationship is established. Using a semantic similarity matching algorithm or a predefined mapping table, the variable name is automatically renamed and the file format is converted (e.g., from GRIB2 to NetCDF).

[0081] S35: Dependency Consistency Monitoring During Execution. During workflow execution, monitor the data flow in real time. When the upstream model completes computation, immediately verify whether its output meets the input constraints of the downstream model (call the verification logic in step S2); if not (e.g., the upstream outputs a NaN value), immediately block the startup of the downstream model to prevent errors from cascading and propagating in long chains. Subsequently, record the exception type, exception variables, original logs, and associated checkpoint information to generate structured fault diagnosis data; determine whether repair conditions are met based on the exception type; if so, trigger the self-healing process, which includes parameter fine-tuning retry, local data repair, automatic format or unit conversion, and rolling back to the previous checkpoint and re-executing the current step; when automatic recovery methods are exhausted, suspend the task and generate a fault diagnosis report, requesting manual intervention; continue scheduling and executing independent parallel branches unaffected by the exception to avoid unnecessary interruptions to the global task execution process.

[0082] Through the coordinated efforts of the above sub-steps, step S3 achieves the automated conversion from natural language task description to executable workflow, transforming long-link tasks that traditionally rely on manual orchestration into automated scheduling processes, and solving the technical challenge of managing complex dependencies between multiple models.

[0083] IV. High-Reliability Execution Monitoring and Multi-Dimensional Result Verification S4: Identify key steps and insert state checkpoints during task execution, perform dual verification of model output results by rule verification and statistical verification, and trigger a self-healing process in response to verification anomalies.

[0084] This step is used to ensure the stability and reliability of results of long-term scientific simulation tasks. Through checkpoints and multiple consistency verification mechanisms, a hierarchical self-healing process is automatically triggered when anomalies occur, meeting the reliability requirements of scientific tasks with low fault tolerance.

[0085] Specifically, step S4 includes the following sub-steps: S41: Critical Step Identification and Checkpoint Setting. Identify high-risk or high-computational-cost critical steps during task execution and automatically insert state checkpoints before and after these steps. Automatically back up the current working state before execution (e.g., automatically back up a snapshot of the current working area) so that recovery can be made from the most recent checkpoint in case of failure, without having to start from scratch. High-risk steps are those with a high probability of failure, abnormal output, wide error propagation impact, or numerical instability in historical executions. High-computational-cost steps are those with long execution times, high computational resource consumption, large data read / write volumes, or high recalculation costs after failure. High-risk steps meet any of the following conditions: historical failure rate not less than 10%, abnormal output rate not less than 5%, node out-degree not less than 3, number of preceding dependent tasks not less than 4, or are numerically stability-sensitive model steps. High-computational-cost steps meet any of the following conditions: expected runtime not less than 1 hour, memory requirement not less than 32GB, output data volume not less than 10GB, or require GPU or MPI parallel resources during execution.

[0086] S42: Multiple Consistency Checks for Results. After the model outputs results, a dual check is performed: rule-based check and statistical check. Rule-based check includes: checking file integrity, format correctness, and whether necessary metadata is included. Statistical check includes: calculating the statistical characteristics of the output results (e.g., mean, variance, extreme values) and comparing them with historical benchmark values ​​or empirical distributions. If the deviation exceeds a preset threshold, the result is marked as suspicious.

[0087] In some embodiments, historical benchmarks or empirical distributions can come from historical observation data of the same research area, historical successful operation results of the same model or model chain under similar regions, scenarios, and input conditions, or authoritative external data products, domain experience thresholds, and physical constraint rules. Priorities can be set according to the reliability of the data source, with priority given to regional measured observation data, followed by authoritative reanalysis / remote sensing products, and then historical operation results of the same model or empirical distributions under similar conditions.

[0088] S43: Anomaly Detection and Automatic Rollback / Retry Mechanism. When an anomaly is detected during verification, a self-healing process is triggered: First, anomaly type identification and severity assessment are performed; when the anomaly manifests as local non-numerical, slight out-of-bounds, numerical non-convergence, or log indications that it can be repaired by adjusting the time step or convergence threshold, parameter adjustment or retry is performed (e.g., re-execute the current step after reducing the time step); parameter fine-tuning and retry include: within the allowable range of the parameter constraint set, making small adjustments to numerical solution parameters (such as time step, number of iterations, convergence threshold), data preprocessing parameters (such as filter window size, interpolation method parameters), boundary condition parameters (such as boundary values, initial condition parameters), model empirical parameters (such as empirical coefficients, adjustment factors), and runtime control parameters (such as the number of parallel threads, memory allocation strategy) to eliminate execution anomalies caused by improper parameter settings without changing the overall task logic. When an anomalies manifest as missing output files, corrupted formats, large-scale outliers, simultaneous anomalies in multiple core variables, overall deviation of statistical distribution, or an increase in the number of parameter fine-tuning retries exceeding a preset threshold, the execution path is rolled back to the previous checkpoint, and an attempt is made to call a backup model or backup algorithm. If the rollback and the backup model or backup algorithm still cannot eliminate the anomaly, the task is suspended and a fault diagnosis report is generated, requesting manual intervention.

[0089] Through the coordinated efforts of the above sub-steps, step S4 achieves full-process reliability assurance of "pre-backup, in-process monitoring, and post-verification" for the execution of scientific tasks, effectively avoiding the cascading propagation of errors in long links, realizing automatic fault recovery of tasks under unattended conditions, and meeting the stringent requirements of low-fault-tolerance scientific tasks for execution reliability.

[0090] The steps S1 to S4 described above are executed sequentially, together constituting the complete technical solution of the multi-model intelligent agent adaptive orchestration and execution method of this invention. Specifically, step S1 solves the problem of parameter alignment difficulties, step S2 overcomes the bottleneck of adapting to scientific research software environments, step S3 realizes the automated construction and collaborative execution of long-link tasks involving multiple models, and step S4 endows the system with scientific-grade execution reliability and self-healing capabilities. These four steps work together to form a complete closed loop from model parameter generation, software environment adaptation, long-link orchestration and scheduling to execution monitoring and self-healing, significantly reducing the technical threshold for automated execution of scientific tasks and improving the data processing efficiency and reliability of scientific computing results.

[0091] Figure 2 This is a flowchart illustrating a multi-model intelligent agent adaptive orchestration and execution method in a specific embodiment of the present invention.

[0092] like Figure 2 As shown, in one specific embodiment, the method is applied to a scientific expedition scenario.

[0093] First, obtain the task objectives: receive the scientific research task described in natural language, and clarify the task to be performed and the target models and software tools involved.

[0094] Subsequently, model parameter constraint verification and alignment are performed: by obtaining the target model parameter information and reconstructing it into a parameter constraint set, an intermediate parameter representation is constructed as an auditable buffer, and unit consistency detection and conversion, spatiotemporal resolution consistency detection and resampling, physical legality and constraint condition verification are performed in sequence. For non-compliant parameters, a hierarchical self-correction mechanism based on the correction rule table is triggered. After the verification is passed, the aligned parameters are encapsulated into the final input format required by the target model.

[0095] Next, the environment adaptive interaction adaptation is performed: the environment probe is started to scan the underlying state of the current computing node and build an environment state vector, identify hidden environment problems such as MPI library version conflicts and CUDA driver incompatibility and perform targeted repairs, identify software tool interaction patterns and dynamically generate input adapters to execute tool calls, listen to the execution output stream and extract key information and convert it into a structured JSON object for downstream use.

[0096] Then, a multi-model dependency workflow is constructed: the planning capabilities of a large language model are used to recursively decompose the scientific expedition task into a sequence of atomic-level subtasks, which are automatically mapped to tasks called by the computational model or data processing tools. The input and output metadata of each subtask is analyzed to automatically infer the data flow relationship and construct a task dependency graph in the form of a directed acyclic graph. Cross-model parameter mapping channels are established for adjacent nodes to automatically complete variable name renaming and file format conversion. The data flow is monitored in real time during the workflow operation. When the upstream output does not meet the downstream constraints, the downstream startup is blocked and the abnormal information is recorded.

[0097] Next, the task is executed and highly reliable results are verified: key steps with high risk or high computational cost are identified and state checkpoints are inserted to back up the current working state, and dual verification of the model output results by rule verification and statistical verification is performed.

[0098] Next, it determines whether the result passes physical or statistical verification: if the verification passes, the final scientific expedition result is output; if the verification fails, the self-healing mechanism is triggered.

[0099] After the self-healing mechanism is triggered: the anomaly type is identified and the severity is assessed. For repairable anomalies, the execution parameters are adjusted or the process is retried and then re-executed. For severe anomalies, the execution path is rolled back to the previous checkpoint and an attempt is made to call the backup model or backup algorithm. If the anomaly still cannot be eliminated, the task is suspended and a fault diagnosis report is generated to request manual intervention. After the self-healing process is completed, the process returns to the "execute task and perform high-reliability result verification" step, and the process is re-executed and the result is verified again until the verification passes or manual intervention is required.

[0100] Through the above process, this invention realizes a complete closed loop for scientific expeditions, from model parameter generation, environment adaptation, task scheduling to execution monitoring and self-healing, significantly reducing the technical threshold for automated execution of scientific expeditions and providing stable and efficient technical support for scientific expeditions in extreme environments.

[0101] Figure 3 This is a schematic diagram of the structure of a multi-model intelligent agent adaptive orchestration and execution system in an embodiment of the present invention.

[0102] like Figure 3 As shown, the system includes a data alignment module, an environment adaptation module, a task orchestration module, and a monitoring and verification module. These modules work together in sequence to form the complete technical solution of the multi-model intelligent agent adaptive orchestration and execution system of this invention.

[0103] The data alignment module addresses the "physical illusion" and mismatch between parameters generated by the agent and the specifications. This module is configured to maintain and manage a knowledge base of parameter specifications for scientific models (including physical dimensions, value ranges, and resolution requirements). It receives initial parameters generated by the agent and converts them into a generic intermediate parameter representation. Specifically, the module acquires target model parameter information and reconstructs it into a set of parameter constraints. Based on this constraint set, it performs unit consistency checks and conversions, spatiotemporal resolution consistency checks and resampling, and physical validity and constraint condition verification on the initial parameters generated by the agent. The verified parameters are then encapsulated into the final input format required by the target model. This module incorporates a unit knowledge graph or conversion engine and physical boundary verification logic. When it detects inconsistencies between the initial parameter units and the units required by the target model (e.g., inconsistent coordinate systems), it automatically performs numerical conversions. When it detects parameters exceeding physical extremes (e.g., longitude exceeding 180°), it automatically performs truncation or error handling, ultimately generating a standard input file that conforms to the strict specifications of the scientific model. This module fundamentally avoids the problem of parameter physical violations caused by the illusion of large language models, ensuring the rigor and reliability of scientific computing input parameters.

[0104] The environment adaptation module addresses the challenges of implementing scientific computing environments due to their complexity and heterogeneity. This module is configured to dynamically scan the underlying computing node's runtime environment (including operating system version, compiler type, MPI parallel library version, hardware resource distribution, etc.) before task execution and encode this as an environment state vector. During execution, the module scans the current computing node's underlying state and constructs the environment state vector before invoking software tools. It dynamically generates input adapters based on the software tool's interaction mode, executes software tool calls, and performs structured parsing of the software tool's output stream. Based on the environment state vector, the module automatically generates startup scripts and configuration files adapted to the current environment using a pre-built template engine. This masks instruction differences between different computing platforms (e.g., local workstations, HPC clusters, cloud servers), enabling automated invocation of non-standard command-line tools or interactive programs. This module overcomes the limitations of non-standard scientific research software environments on automated execution, allowing the same orchestration scheme to adaptably run on heterogeneous computing platforms.

[0105] The task orchestration module is used to automate the orchestration of multi-step, multi-model scientific tasks. This module is configured to parse the logical structure of scientific tasks, identify data dependencies between different model components (e.g., preprocessing, model computation, visualization), and construct an execution workflow in the form of a directed acyclic graph (DAG). During execution, the module decomposes the scientific task into a sequence of subtasks, constructs a task dependency graph in the form of a DAG, generates an executable queue, identifies parallelizable task branches, and establishes cross-model parameter mapping channels to convert upstream model outputs to downstream model inputs. This module manages cross-model parameter mapping channels, performs format conversions and variable renaming between upstream model outputs and downstream model inputs, and possesses dynamic scheduling capabilities. It can identify parallelizable task branches based on the DAG topology, optimizing overall execution efficiency. Through this module, long-chain tasks that traditionally relied on manual orchestration are transformed into automated scheduling processes, solving the technical challenge of managing complex dependencies between multiple models.

[0106] The monitoring and verification module ensures the stability and reliability of results for long-term scientific simulation tasks. This module is configured to monitor the runtime logs and process status in real time during task execution and perform deep verification of the output results based on physical conservation laws and statistical characteristics. Specifically, during execution, the module identifies key steps and inserts status checkpoints, performing dual verification of the model output results using both rule-based and statistical methods. It triggers a self-healing process in response to verification anomalies. This module maintains the task's checkpoint mechanism. Once a runtime anomaly (e.g., NaN overflow) or result verification failure is detected, the self-healing process is automatically triggered: anomaly type identification and severity assessment are performed upon receiving a verification anomaly; if the anomaly is repairable, parameter adjustment or retry is performed; if parameter fine-tuning and retry fail or the anomaly is irreparable, path rollback is performed, rolling back to the previous checkpoint and attempting to call a backup model or algorithm; if rollback and the backup model or algorithm still cannot eliminate the anomaly, the task is suspended and a fault diagnosis report is generated requesting manual intervention. Through this module, a full-process reliability assurance system of "pre-backup, in-process monitoring, and post-verification" is established, effectively avoiding the cascading propagation of errors in long links, realizing automatic recovery of task failures under unattended conditions, and meeting the stringent requirements of low-fault-tolerance scientific tasks for execution reliability.

[0107] The four modules described above work in tandem, from model parameter standardization to environmental adaptation, and then to long-chain task orchestration and execution reliability assurance, constructing a complete closed-loop system. This invention significantly lowers the technical threshold for automating scientific tasks, improves the data processing efficiency and reliability of scientific computing results, and provides stable and efficient technical support for the intelligent execution of complex scientific tasks such as scientific expeditions.

[0108] It should be understood that the specific embodiments described above are merely illustrative or explanatory of the principles of the invention and do not constitute a limitation thereof. Therefore, any modifications, equivalent substitutions, improvements, etc., made without departing from the spirit and scope of the invention should be included within the protection scope of the invention. Furthermore, the appended claims are intended to cover all variations and modifications falling within the scope and boundaries of the appended claims, or equivalent forms of such scope and boundaries.

Claims

1. A method for adaptive orchestration and execution of multi-model intelligent agents, characterized in that, include: Step S1: Obtain the parameter information of the target model and reconstruct it into a parameter constraint set. Based on the parameter constraint set, perform unit consistency detection and conversion, spatiotemporal resolution consistency detection and resampling, physical legality and constraint condition verification on the initial parameters generated by the agent. Encapsulate the verified parameters into the final input format required by the target model. Step S2: Before calling the software tool, scan the underlying state of the current computing node and construct the environment state vector. Dynamically generate the input adapter according to the interaction mode of the software tool, execute the software tool call, and perform structured parsing of the output stream of the software tool. Step S3: Decompose the scientific task into a sequence of sub-tasks, construct a task dependency graph in the form of a directed acyclic graph, generate an executable queue and identify task branches that can be executed in parallel, and establish a cross-model parameter mapping channel to realize the conversion from upstream model output to downstream model input. Step S4: Identify key steps and insert state checkpoints during task execution, perform dual verification of the model output results using rule verification and statistical verification, and trigger the self-healing process in response to verification anomalies.

2. The method according to claim 1, characterized in that, Step S1 includes: Step S11: Obtain the parameter information of the target model and reconstruct it into a standardized set of parameter constraints using a predefined metadata template; Step S12: In response to the initial parameter data generated by the agent or input from the outside, an intermediate parameter representation is forcibly constructed. The intermediate parameter representation includes at least the parameter name, the original value, the original unit, the original spatiotemporal resolution, and the data source identifier. Step S13: Traverse each parameter in the intermediate parameter representation, perform semantic comparison between its original unit and the target unit defined in the parameter constraint set, and when a unit mismatch is detected, generate a unit inconsistency interruption flag and suspend the parameter passing process. Step S14: When the unit inconsistency interruption flag is triggered, the unit knowledge graph or conversion engine is invoked to match the conversion formula based on the principle of dimensional analysis and perform numerical conversion. Step S15: Align the time step and spatial grid size of the input data with the resolution required by the target model. When there is a resolution inconsistency, select a resampling algorithm based on the physical properties of the parameters. Step S16: Substitute the parameter data with consistent unit and resolution into the constraint discrimination function group defined by the parameter constraint set for final verification. The constraint discrimination function group is used to verify at least the physical boundary, value range, spatiotemporal applicability, cross-parameter logical relationship and conservation constraint of the parameter. When all constraint discrimination results meet the preset legality conditions, the final verification is considered to be passed. When any constraint discrimination result does not meet the legality conditions, a self-correction mechanism is triggered. Step S17: The parameters that have passed the final verification are encapsulated into the final input format required by the target model and then proceed to the subsequent model execution stage.

3. The method according to claim 2, characterized in that, In step S11, the standardized set of parameter constraints is formally described as a quintuple: C M ={(p i ,t i ,u i ,r i ,Ω i )} Where, p i t is the parameter name. i For parameter data types, u i r is the physical unit of the parameter. i Ω represents the spatiotemporal resolution to which the parameters apply. i The physical boundary constraints are parameters that transform natural language constraints into machine-verifiable mathematical rules.

4. The method according to claim 2, characterized in that, In step S16, the self-correction mechanism is executed based on a correction rule table, which includes at least: For continuous interval constraints, depending on the degree of deviation, the following actions can be taken: directly truncate to the boundary, truncate and record alarms and trigger secondary verification, or refuse to truncate and feed back intelligent weight generation. For enumeration or category constraints, correction is based on the mapping table; if mapping is not possible, the constraint is regenerated. For unit or dimension constraints, perform the conversion and recalculate, or regenerate and request manual confirmation; For cross-parameter relationship constraints, priority is given to regeneration, and no hard truncation is performed; For spatiotemporal structural constraints, perform alignment processing; if it fails, regenerate. For conservation constraints, normalization or conservation correction is performed, or rollback and regeneration or invocation of backup algorithms are performed depending on the degree of deviation. For data quality constraints, interpolation or neighborhood patching, or blocking and regeneration, are performed depending on the degree of deviation.

5. The method according to claim 1, characterized in that, Step S2 includes: Step S21: Before calling any software tools, start the environment probe to scan the underlying state of the current computing node and construct the environment state vector; Step S22: Read the meta description file of the software tool or execute help instructions to classify the interaction mode of the software tool into streaming interaction type, file-driven type or command line parameter type; Step S23: Based on the parameter data output in step S1 and the interaction patterns classified in step S22, dynamically generate an input adapter and execute software tool calls; Step S24: Monitor the execution output stream and intermediate files generated by the software tool, and extract key information from the unstructured runtime logs using a predefined regular expression library or log parser, and convert it into a structured JSON object.

6. The method according to claim 5, characterized in that, In step S21, the environmental state vector is represented as: E=(OS type ,Lib versions ,Env vars ,Resource quota ) Among them, OS type Indicates the operating system type and version, Lib versions This represents the set of versions of key dependency libraries, compilation environments, and runtime components in the current node. vars Resource represents the set of environment variables that affect the operation of software tools. quota This indicates the available computing, storage, and scheduling resource quotas for the current node.

7. The method according to claim 5, characterized in that, In step S23, the input adapter is generated in the following ways: For file-driven software tools, the parameter data output in step S1 is filled into a standard configuration file template using a template engine. For command-line software tools, concatenate Shell command strings that conform to the syntax rules; For streaming interactive software tools, a response mechanism is built to simulate human input.

8. The method according to claim 1, characterized in that, Step S3 includes: Step S31: Receive the scientific task described by natural language, and recursively decompose it into a sequence of subtasks using the planning capability of the large language model, where each subtask corresponds to a specific computational model or data processing tool. Step S32: Analyze the input and output metadata of each subtask, infer the data flow relationship between tasks, and construct a task dependency graph in the form of a directed acyclic graph; Step S33: Perform a topological sorting algorithm on the task dependency graph to generate a linear executable queue, identify mutually independent subgraph branches and mark them as parallel executable blocks; Step S34: Establish cross-model parameter mapping channels for adjacent nodes in the task dependency graph to realize the conversion from upstream model output to downstream model input.

9. The method according to claim 8, characterized in that, The cross-model parameter mapping channel is implemented in the following way: Cross-model parameter mapping is performed preferentially based on predefined mapping tables; When there is no corresponding mapping item in the predefined mapping table or there are multiple candidate items, the semantic similarity matching algorithm is called to generate candidate mapping relationships, and the selection is carried out in combination with constraints of unit, format, resolution and variable type. The semantic similarity matching algorithm calculates the comprehensive matching score between variable pairs based on string similarity and text embedding vector similarity, according to the following formula: ； Among them, S s S represents string similarity. e Indicates the similarity of text embedding vectors; The string similarity is calculated according to the following formula: ； Where, N s N represents the source model parameters. t The target model parameters are represented by d, and the edit distance is represented by L. s L represents the character length of the source model parameter. t The character length of the target model parameter is indicated by `max`, which means taking the maximum value. The text embedding vector similarity is calculated according to the following formula: ； Among them, V s V represents the text embedding vector corresponding to the source model parameters. t This represents the text embedding vector corresponding to the parameters of the target model; When the overall matching score is higher than a preset threshold, semantic consistency is determined and a parameter mapping relationship is established.

10. The method according to claim 8, characterized in that, Step S3 further includes step S35, which includes: The data stream is monitored in real time during task execution, and its output is immediately verified to meet the input constraints of the downstream model when the upstream model completes the calculation. If the conditions are not met, immediately block the startup of the downstream model, record the anomaly type, anomaly variables, original logs and associated checkpoint information, and generate structured fault diagnosis data. Determine whether the conditions for repair are met based on the type of anomaly; if so, trigger the self-healing process. Independent parallel branches that are not affected by the anomaly will continue to be scheduled and executed to avoid unnecessary interruptions to the global task execution process.

11. The method according to claim 1, characterized in that, Step S4 includes: Step S41: Identify high-risk or high-computational-cost critical steps during task execution, and insert state checkpoints before and after the critical steps. Back up the current working state before execution so that it can be restored from the most recent checkpoint in case of an anomaly. Step S42: After the model outputs the results, perform dual verification of rule verification and statistical verification. Step S43: When an anomaly is detected during verification, the self-healing process is triggered.

12. The method according to claim 11, characterized in that, In step S42, The rule verification includes: checking file integrity, format correctness, and whether it contains necessary metadata; The statistical verification includes: calculating the statistical characteristics of the output results and comparing them with historical benchmark values ​​or empirical distributions; if the deviation exceeds a preset threshold, the result is marked as suspicious.

13. The method according to any one of claims 1 to 12, characterized in that, The self-healing process includes: In response to a verification anomaly, the anomaly type is first identified and its severity is assessed. When the anomaly is manifested as local non-numerical, slight out-of-bounds, numerical non-convergence, or log indications that it can be repaired by adjusting the time step or convergence threshold, perform parameter adjustment or retry. When an anomaly manifests as missing output files, corrupted format, large-scale outliers, multiple core variables being abnormal simultaneously, overall deviation of statistical distribution, or the number of parameter fine-tuning retries exceeding a preset threshold, the execution path is rolled back, the working state is restored from the most recent checkpoint, and an attempt is made to call a backup model or backup algorithm. If rollback and standby models or standby algorithms still fail to eliminate the anomaly, suspend the task, generate a fault diagnosis report, and request manual intervention.

14. A multi-model intelligent agent adaptive orchestration and execution system, characterized in that, include: The data alignment module is configured to acquire the parameter information of the target model and reconstruct it into a set of parameter constraints. Based on the set of parameter constraints, it performs unit consistency detection and conversion, spatiotemporal resolution consistency detection and resampling, physical legality and constraint condition verification on the initial parameters generated by the agent. The parameters that pass the verification are encapsulated into the final input format required by the target model. The environment adaptation module is configured to scan the underlying state of the current computing node and construct an environment state vector before calling the software tool, dynamically generate an input adapter based on the interaction mode of the software tool, execute the software tool call, and perform structured parsing of the output stream of the software tool. The task orchestration module is configured to decompose scientific tasks into a sequence of subtasks, construct a task dependency graph in the form of a directed acyclic graph, generate an executable queue and identify task branches that can be executed in parallel, and establish a cross-model parameter mapping channel to realize the conversion from upstream model output to downstream model input. The monitoring and verification module is configured to identify key steps and insert status checkpoints during task execution, perform dual verification of the model output results by rule verification and statistical verification, and trigger a self-healing process in response to verification anomalies.

15. The system according to claim 14, characterized in that, The data alignment module has a built-in unit knowledge graph or conversion engine, as well as physical boundary verification logic. When it is detected that the units of the initial parameters are inconsistent with the units required by the target model, numerical conversion is performed. When it is detected that the parameters exceed the physical extreme values, truncation or error processing is performed.

16. The system according to claim 14 or 15, characterized in that, The self-healing process includes: In response to verification anomalies, perform anomaly type identification and severity assessment; When the exception is a repairable type, perform parameter adjustments or retry; When parameter fine-tuning retry fails or the exception is of an unrecoverable type, the execution path is rolled back to the previous checkpoint and an attempt is made to call the backup model or backup algorithm. If rollback and standby models or algorithms still fail to eliminate the anomaly, suspend the task and generate a fault diagnosis report, requesting manual intervention.

Images