Agent-oriented simulation model tool encapsulation and autonomous deduction method and system

Abstract

The application discloses an agent-oriented simulation model tool packaging and autonomous deduction method and system, generates a tool description mode containing function semantics, input and output constraints, preconditions, state declarations and calling protocols for a simulation model, registers to a model registration center and establishes a semantic index, analyzes a natural language deduction task into a structured subtask, retrieves a candidate model according to the tool description mode, generates a model calling chain, executes the model calling chain, writes output into a deduction state context, and realizes automatic filling of a previous output into a subsequent input through field mapping, saves a snapshot of a global state and a stateful model internal state, supports branch deduction and abnormal recovery, and generates a deduction conclusion. The application combines agent reasoning and simulation calculation, supports autonomous deduction based on real numerical simulation, and improves deduction efficiency and reliability.

Description

Technical Field

[0001] This invention relates to the fields of complex system simulation and artificial intelligence technology, specifically to a tool-based encapsulation and autonomous inference method and system for simulation models oriented towards intelligent agents. Background Technology

[0002] Complex system simulation is widely used in scenarios such as aerospace mission planning, marine engineering equipment operation, offshore engineering construction, industrial system operation, and energy allocation. A complete simulation typically requires the collaborative computation of multiple heterogeneous simulation models, covering model types such as orbital mechanics, attitude control, sea state environment, equipment load, path planning, resource scheduling, state evolution, and risk assessment. Traditional simulation methods rely on professional operators manually setting model parameters, determining the order of calls, interpreting calculation results, and deciding on subsequent operations. Simulation efficiency is limited by operator experience and cross-disciplinary collaboration costs, making it difficult to support the needs of large-scale, high-frequency, and multi-scheme comparison simulations.

[0003] In recent years, Large Language Models (LLMs) have made groundbreaking progress in natural language understanding, logical reasoning, and task planning. In particular, the maturity of tool use / function calling mechanisms enables LLMs to understand the functional descriptions of external tools, autonomously decide which tool to call and with what parameters, and continuously plan subsequent actions based on the tool's returned results. This provides a key technological foundation for introducing LLMs into the field of complex system simulation and deduction.

[0004] In existing technologies, one approach is a multi-agent inferential text generation method based on large language models. This typically establishes a multi-level agent collaborative structure, generating text materials containing task background, inference process, and event records through multi-turn natural language dialogues between agents. However, the essence of this approach is that the large language model generates natural language text; the inference process does not invoke a real mathematical simulation model. System state changes and action results are mainly generated directly by the model's language generation capabilities, which cannot guarantee compliance with physical laws, operating rules, or engineering constraints. It is difficult to output quantitative results with engineering significance, such as resource consumption, travel time, risk diffusion range, and equipment load changes. Furthermore, large language models suffer from inconsistencies in the logic of generated long texts, and these inconsistencies cannot be verified using simulation data, resulting in low credibility of inference conclusions and a high risk of factual illusion.

[0005] Another approach is the traditional distributed simulation architecture (such as HLA / DIS). This architecture organizes heterogeneous simulation models developed by different organizations into a federation through services like federation management, declaration management, and object management, coordinating simulation timelines and data exchange. Each model member communicates with other members through runtime infrastructure, and the model's inputs and outputs are described using predefined object models. However, this architecture relies entirely on professional operators setting initial parameters, initiating simulations, and manually interpreting results through dedicated interfaces for each model. A single complete simulation requires a large number of operators with specialized knowledge, and simulation efficiency is limited by the scale and expertise of human resources. Furthermore, its model interfaces are described through FOM files (XML format) and programming APIs, catering only to software programmers and engineers familiar with the protocols. They lack any semantic information for AI systems to understand, making it impossible for AI systems to comprehend the model's purpose, applicable scenarios, and parameter meanings based solely on the interface descriptions. AI systems also cannot autonomously decide when to call which model. Moreover, integrating a new simulation model into the HLA federation requires writing federation member code conforming to HLA specifications, designing FOM data structures, and conducting federation-level integration testing—a massive undertaking that severely restricts the rapid expansion and on-demand combination capabilities of the simulation system.

[0006] It is evident that existing technologies have significant gaps in combining large language models with complex system simulation: inference systems based on large language models mostly remain at the level of text generation or process arrangement, lacking a stable interface with real simulation models; although traditional simulation architectures have numerical computation capabilities, their interfaces are mainly geared towards programmers or professional engineers, lacking semantic descriptions for intelligent agents to autonomously understand, retrieve, and invoke.

[0007] Therefore, how to realize the deduction of complex systems driven autonomously by intelligent agents and based on real numerical simulation is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0008] In view of the above problems, the present invention is proposed to provide a tool-based encapsulation and autonomous inference method and system for intelligent agent simulation models that overcomes or at least partially solves the above problems.

[0009] To achieve the above objectives, the present invention adopts the following technical solution:

[0010] In a first aspect, embodiments of the present invention provide a tool-based encapsulation and autonomous inference method for simulation models of intelligent agents, comprising the following steps: S1: Obtain model information for multiple simulation models, including native call interfaces, input parameters, output results, running constraints, and status information; S2: Tool description patterns for generating each simulation model based on model information. The tool description patterns are structured metadata, including at least: model identifier, functional semantics, input parameters, output results, calling constraints, state declarations, and calling protocols. S3: Storage tools describe schemas and build model indexes; S4: The agent receives the natural language inference task, parses it into structured subtasks based on the tool description pattern, and writes them into the inference state context; the structured subtasks include the required model type, initial task parameters, target output fields, constraints, and dependencies between subtasks; S5: The agent retrieves candidate simulation models based on the model index retrieval function, semantic matching, and output results that cover the target output fields, according to the required model type and target output fields. It also generates model call chains and standardized call parameters based on the dependencies between subtasks. The edges of the model call chain carry field mapping rules. S6: The execution engine converts standardized call parameters into call instructions for the native call interface, calls the simulation model according to the model call chain, writes the native return value of the simulation model into the deduction state context according to the tool description mode, and fills the output results of the preceding simulation model into the input parameters of the subsequent simulation model according to the field mapping rules. S7: Save a state snapshot during the simulation. The state snapshot contains the global simulation state in the simulation state context. S8: After the model call chain is completed, the agent obtains the final output result in the inference state context and generates the inference conclusion by comparing it with the target output field and the constraints.

[0011] Preferably, the input parameters in the tool description mode include at least parameter name, data type, physical unit, value range, whether it is required, and semantic description, which are used by the agent to generate the standardized calling parameters and by the execution engine to perform parameter verification; the output results include at least output field name, data type, physical unit, field meaning, and field mapping rules between the output field and the input parameters of the subsequent simulation model.

[0012] Preferably, the calling constraints include: Preconditions are used to indicate the conditions that must be met before calling the corresponding simulation model, including the input parameters or status fields involved in the condition judgment, comparison rules, thresholds, data sources, and applicable time ranges. Dependency model, used to indicate other simulation models that need to be called before calling the corresponding simulation model; Estimated execution time indicates the expected execution time of a single call to the corresponding simulation model; Concurrency limits are used to indicate the limit on the number of simulation models that can be called simultaneously for the corresponding simulation model; The status declaration includes: Status identifiers are used to indicate whether the corresponding simulation model has an internal operating state that affects the subsequent calculation results of the model; A state structure, used to indicate the data composition contained in the internal operating state; The state management interface is used to initialize, reset, serialize and save the state, and restore the state serialization at the state snapshot time.

[0013] Preferably, in step S6, the standardized calling parameters based on the tool description pattern are converted into calling instructions required by the native calling interface through an adapter, and the native return values ​​of each simulation model are converted into output results defined by the tool description pattern through the adapter; the adapter receives the standardized calling parameters verified by the tool description pattern.

[0014] Preferably, the model indexing includes: constructing index text from the fields in the tool description pattern and generating corresponding semantic vectors; in step S5, retrieving candidate simulation models includes: Based on the required model type and target output field in the structured subtask, the agent returns a list of tool description patterns for semantically matched simulation model sets through vector similarity calculation; The simulation model set is filtered to remove at least one of the following simulation models: the calling constraints are not met, the required input parameters cannot be provided by the initial task parameters or the output results of the preceding simulation model, the time scale specified in the functional semantics does not match the time range of the structured subtask, and the agent role calling permissions are not met. For the simulation model that passes the filter, the comprehensive fit score is determined according to at least one of the following: matching parameters of functional semantics, attribute parameters of whether the input parameters meet the standardized call parameter conversion requirements of the tool description mode, attribute parameters of whether the output results meet the attribute description of the target output field, and attribute parameters of whether the call constraints meet the constraint conditions. Candidate simulation models are graded based on the comprehensive adaptation score, and candidate simulation models for generating the model call chain are selected from the filtered simulation models based on the graded scores.

[0015] Preferably, in step S5, the step of generating the model call chain includes: Candidate call chains are generated using candidate simulation models according to the following labeling rules: Each candidate simulation model call is taken as a node, and the data flow direction is taken as a directed edge, with the field mapping rules marked on the edge; For nodes whose input parameters are provided by the initial task parameters, mark their corresponding edges as external input edges; For cases where the input parameters are provided by the output field of another simulation model through the field mapping rule, a data edge is established between the two nodes; For nodes that do not have a preceding simulation model and a subsequent simulation model, mark them as parallelizable nodes; For nodes whose input parameters depend on the judgment values ​​of the output fields of the preceding true model, mark them as conditional branch nodes; The model call chain is generated by selecting the candidate call chain with the fewest non-executable gaps, wherein nodes whose required input parameters cannot be obtained from the initial task parameters or the output result fields of the preceding simulation model are marked as non-executable gaps.

[0016] Preferably, the state snapshot further includes the internal operating state of the simulation model with an internal operating state; in S6, for the simulation model whose state declaration indicates it has an internal operating state, its internal operating state is obtained and written into the inference state context; the method further includes: When performing branch deduction or abnormal node recovery of the model call chain, select the target state snapshot of the branch node or abnormal node from the state snapshot, and restore the deduction state context to the time corresponding to the target state snapshot; The simulation model, which indicates that the state declaration has an internal operating state, calls its state recovery interface to restore the internal operating state to the time corresponding to the target state snapshot; Once the recovery is complete, the subsequent model call chain is regenerated or updated based on the new data in the structured subtask.

[0017] Preferably, step S8 further includes: the agent reading the final output result in the inference state context and comparing it with the target output field and the constraints to make a judgment: If the inference conclusion does not fully answer the natural language inference task, then identify the non-executable gap, adjust the input parameters or add a new simulation model call, and enter a new round of iteration; If it is necessary to compare different schemes for the same structured subtask, the state snapshot is rolled back to the node of the model call chain corresponding to the comparison scheme, and the model call chain is re-executed according to the comparison scheme.

[0018] Preferably, it also includes the step of multi-agent collaborative simulation according to a round-based protocol: Configure a set of callable simulation models and a state access range for agents with different roles. The set of callable simulation models includes simulation models that the agent with the role has the right to call. The state access range is the range of data that the agent with the role has the right to read in the context of the inference state. Each round includes: The global real state is maintained by the evaluation and review agent, and the global real state includes the real state of the simulated entity reflected by the output result fields of each simulation model; The evaluation and review agent performs masking processing on data in the global real state that exceeds the state access permissions of the agent of each role, according to the global real state and the state access permissions of the agents of each role, to generate the observation state corresponding to the agent of that role, and stores the observation state corresponding to the agent of each role in the data partition corresponding to the agent of that role in the inference state context. Each role's intelligent agent reads the observation state from its corresponding data partition in the inference state context, generates a structured action plan for the simulated entity based on the observation state, and submits it to the evaluation and review intelligent agent; The evaluation and review agent calls the corresponding arbitration simulation model based on the structured action plan submitted by the agents of each role. The arbitration simulation model calculates the interaction results between the actions of the multiple parties and writes the calculation results into the global real state. The evaluation and review agent regenerates the observation state corresponding to each role's agent according to the updated global real state and the state access permissions of each role's agent. Advance the global simulation clock to proceed to the next round.

[0019] Secondly, embodiments of the present invention provide a tool-based encapsulation and autonomous inference system for intelligent agent-oriented simulation models, used to implement the tool-based encapsulation and autonomous inference method for intelligent agent-oriented simulation models described in the first aspect, including: The model information acquisition module is used to acquire model information of multiple simulation models, including native call interfaces, input parameters, output results, running constraints, and status information; The tool description generation module is used to generate tool description patterns for each simulation model based on model information. The tool description pattern is structured metadata, which includes at least: model identifier, functional semantics, input parameters, output results, calling constraints, state declarations, and calling protocols. A model registry is used to store tool description patterns and build model indexes. The task parsing module receives natural language inference tasks, parses them into structured subtasks based on the tool description pattern, and writes them into the inference state context. The structured subtasks include the required model type, initial task parameters, target output fields, constraints, and dependencies between subtasks. The call chain planning module is used to select candidate simulation models based on the model index retrieval function semantic matching and output results that cover the target output fields, according to the required model type and target output fields. It also generates model call chains and standardized call parameters based on the dependencies between subtasks. The edges of the model call chain carry field mapping rules. The simulation adaptation engine is used to convert standardized calling parameters into calling instructions of native calling interfaces, call simulation models according to model calling chains, write the native return values ​​of simulation models into the inference state context according to the tool description mode, and fill the output results of the preceding simulation model into the input parameters of the subsequent simulation model according to the field mapping rules. The simulation state manager is used to save state snapshots during simulation. The state snapshots contain the global simulation state in the simulation state context. The result analysis module is used to obtain the final output result in the deduction state context after the model call chain is completed, and to generate the deduction conclusion by comparing it with the target output field and constraint conditions.

[0020] The present invention can produce the following beneficial technical effects: This invention standardizes and encapsulates simulation models through tool description patterns and adapters, enabling existing simulation models to be integrated without modifying the main code, thus achieving unified management and on-demand combination of heterogeneous simulation models.

[0021] The intelligent agent of this invention autonomously retrieves candidate simulation models and generates model call chains based on model indexing and hard constraint filtering, reducing the workload of manually specifying the model call order and parameter mapping, and improving the efficiency of multi-model combination inference.

[0022] This invention achieves automatic transfer of the output of the preceding simulation model to the input of the subsequent simulation model by inferring the state context and field mapping rules, ensuring the consistency and traceability of data transfer during multi-step simulation.

[0023] The state snapshot of this invention simultaneously saves the global deduction state and the internal running state of the stateful simulation model, supports branch deduction, scheme comparison and historical rollback, and after restoration, the global state and the internal state of the model are at the same calculation time, ensuring that the calculation starting point of branch deduction is consistent.

[0024] The conclusions drawn in this invention are based on real numerical simulation calculations and are subject to constraints on physical units, value ranges, calling constraints, and output fields in the tool description mode. They can be traced back to model call records, field mapping relationships, and state snapshots, thereby improving the credibility and verifiability of the conclusions drawn.

[0025] Overall, this invention bridges the technical gap between the reasoning capabilities of intelligent agents and the simulation and computational capabilities of complex systems, enabling the deduction of complex systems that are autonomously driven by intelligent agents, based on real numerical simulations, and with consistent and traceable states. Attached Figure Description

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

[0027] Figure 1 A flowchart illustrating the tool-based encapsulation and autonomous inference method for agent-oriented simulation models provided in this embodiment of the invention; Figure 2 This is an architecture diagram of the agent-oriented simulation model tool encapsulation and autonomous inference system provided in the embodiments of the present invention. Detailed Implementation

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

[0029] This invention specifically discloses a tool-based encapsulation and autonomous inference method for simulation models oriented towards intelligent agents, such as... Figure 1 As shown, it includes the following steps: S1: Obtain model information for multiple simulation models, including native call interfaces, input parameters, output results, running constraints, and status information.

[0030] S2: Generate a tool description pattern for each simulation model based on the model information. The tool description pattern is structured metadata and includes at least the following fields: model identifier, functional semantics, input parameters, output results, calling constraints, state declaration, and calling protocol.

[0031] In one embodiment, the input parameters in the tool description mode include at least the parameter name, data type, physical unit, value range, whether it is required, and semantic description, which are used by the agent to generate standardized calling parameters and by the execution engine to perform parameter verification; the output results include at least the output field name, data type, physical unit, field meaning, and field mapping rules between the output field and the input parameters of the subsequent simulation model.

[0032] In one embodiment, the calling constraints include: Preconditions are used to indicate the conditions that must be met before calling the corresponding simulation model, including the input parameters or status fields involved in the condition judgment, comparison rules, thresholds, data sources, and applicable time ranges. Dependency model, used to indicate other simulation models that need to be called before calling the corresponding simulation model; Estimated execution time indicates the expected execution time of a single call to the corresponding simulation model; Concurrency limits are used to indicate the limit on the number of simulation models that can be called simultaneously for the corresponding simulation model; Status declarations include: Status identifiers are used to indicate whether the corresponding simulation model has an internal operating state that affects the subsequent calculation results of the model; State structure, used to indicate the data composition contained in the internal operating state; The state management interface is used to initialize, reset, serialize and save the state, and restore the state serialization at the state snapshot time.

[0033] S3: Stores tool description patterns for multiple simulation models and builds a model index for semantic retrieval.

[0034] S4: The agent receives the natural language inference task, parses the natural language inference task into structured subtasks based on the tool description pattern, and writes the structured subtasks into the inference state context. The structured subtasks include the required model type, the user-set initial task parameters, the target output fields, constraints, and dependencies between subtasks.

[0035] S5: The agent retrieves candidate simulation models based on the required model type and target output field in the structured subtask, using the model index retrieval function to semantically match and the output results cover the target output field. Based on the input parameters, output results, calling constraints, and dependencies between subtasks of the candidate simulation models, the agent generates a model call chain and standardized call parameters based on the tool description pattern. The edges of the model call chain carry field mapping rules.

[0036] In one embodiment, model indexing includes: constructing index text from fields in the tool description pattern and generating corresponding semantic vectors; in step S5, retrieving candidate simulation models includes: Based on the required model type and target output field in the structured subtask, the agent returns a list of tool description patterns for semantically matched simulation model sets through vector similarity calculation; Perform filtering on the set of simulation models to remove at least one of the following simulation models: those whose calling constraints are not met, whose required input parameters cannot be provided by the initial task parameters or the output results of the preceding simulation model, whose time scale specified in the functional semantics does not match the time range of the structured subtask, and whose agent role calling permissions are not met. For the simulation model that passes the filter, the comprehensive fit score is determined based on at least one of the following: matching parameters of functional semantics, attribute parameters of whether the input parameters meet the standardized call parameter conversion requirements of the tool description mode, attribute parameters of whether the output results meet the attribute description of the target output field, and attribute parameters of whether the call constraints meet the constraint conditions. Candidate simulation models are graded based on their comprehensive fit scores, and then selected from the filtered simulation models to generate model call chains based on these graded scores.

[0037] In this embodiment, step S5, the step of generating the model call chain, includes: Candidate call chains are generated using candidate simulation models according to the following labeling rules: Each candidate simulation model call is used as a node, and the data flow direction is used as a directed edge, with the field mapping rules labeled on the edge; For nodes whose input parameters are provided by the initial task parameters, mark their corresponding edges as external input edges; For cases where the input parameters are provided by the output fields of another simulation model through field mapping rules, a data edge is established between the two nodes; For nodes that do not have a preceding simulation model and a subsequent simulation model, mark them as parallelizable nodes; For nodes whose input parameters depend on the judgment values ​​of the output fields of the preceding true model, mark them as conditional branch nodes; The candidate call chain with the fewest non-executable gaps is selected to generate the model call chain. Among them, nodes whose required input parameters cannot be obtained from the initial task parameters or the output result fields of the preceding simulation model are marked as non-executable gaps.

[0038] S6: The execution engine converts the standardized call parameters into the call instructions required by the native call interface, calls each simulation model according to the model call chain, converts the native return values ​​of each simulation model into the output results defined by the tool description mode and writes them into the inference state context, and fills the output results of the preceding simulation model in the model call chain into the input parameters of the subsequent simulation model according to the field mapping rules.

[0039] In one embodiment, in step S6, the standardized calling parameters based on the tool description pattern are converted into calling instructions required by the native calling interface through an adapter, and the native return values ​​of each simulation model are converted into output results defined by the tool description pattern through an adapter; the adapter receives the standardized calling parameters verified by the tool description pattern.

[0040] In one embodiment, for a simulation model whose state declaration indicates that it has an internal operating state, its internal operating state is obtained and written into the deduction state context.

[0041] S7: Save a state snapshot during the simulation. The state snapshot contains the global simulation state in the simulation state context.

[0042] In one embodiment, for a simulation model with an internal running state that is included in the model call chain, the state snapshot includes the global inference state and the internal running state in the inference state context.

[0043] In this embodiment, the method further includes: When performing branch deduction or abnormal node recovery of the model call chain, select the target state snapshot of the branch node or abnormal node from the state snapshot and restore the deduction state context to the time corresponding to the target state snapshot. For simulation models whose state declaration indicates that they have an internal operating state, call their state recovery interface to restore the internal operating state to the time corresponding to the target state snapshot; Once the recovery is complete, the subsequent model call chain is regenerated or updated based on the new data in the structured subtask.

[0044] S8: After the model call chain is completed, the agent obtains the final output result in the inference state context and generates the inference conclusion by comparing it with the target output field and the constraints.

[0045] In one embodiment, step S8 further includes: the agent reading the final output result in the inference state context and making a judgment by comparing it with the target output field and the constraints. If the inference conclusion does not fully answer the natural language inference task, then identify the non-executable gap, adjust the input parameters or add a new simulation model call, and enter a new round of iteration; If it is necessary to compare different solutions for the same structured subtask, the process is to roll back to the node of the model call chain corresponding to the comparison solution based on the state snapshot, and then re-execute the model call chain according to the comparison solution.

[0046] In one embodiment, the method further includes a step of performing multi-agent collaborative simulation according to a round-based protocol: Configure a set of callable simulation models and a state access range for agents with different roles. The set of callable simulation models includes simulation models that the agent with the role has the right to call. The state access range is the range of data that the agent with the role has the right to read in the inference state context. Each round includes: The global real state is maintained by the evaluation and review agent, which includes the real state of the simulated entity reflected in the output fields of each simulation model. Based on the global real state, the evaluation and review agent performs masking processing on data in the global real state that exceeds the state access permissions of the agent of each role, according to the state access permissions of each role's agent, generates the observation state corresponding to the agent of that role, and stores the observation state corresponding to the agent of each role in the data partition corresponding to the agent of that role in the inference state context. Each agent reads the observation state from its corresponding data partition in the inference state context, generates a structured action plan for the simulated entity based on the observation state, and submits it to the evaluation and review agent. The evaluation and reviewing agent calls the corresponding arbitration simulation model based on the structured action plan submitted by the agents of each role. The arbitration simulation model calculates the interaction results between the actions of multiple parties and writes the calculation results into the global real state. The assessment and review agent regenerates the observation state corresponding to each role's agent according to the updated global real state and the state access permissions of each agent. Advance the global simulation clock to proceed to the next round.

[0047] Based on the same inventive concept, combined with Figure 2 As shown, this embodiment of the invention also provides a system for tool-based encapsulation and autonomous inference of agent-oriented simulation models, based on an agent-oriented simulation model tool-based encapsulation and autonomous inference method. The technical features of this system are also applicable to the execution steps of the agent-oriented simulation model tool-based encapsulation and autonomous inference method. The system includes: The model information acquisition module is used to acquire model information of multiple simulation models, including native call interfaces, input parameters, output results, running constraints, and status information; The tool description generation module is used to generate tool description patterns for each simulation model based on model information. The tool description pattern is structured metadata, which includes at least: model identifier, functional semantics, input parameters, output results, calling constraints, state declarations, and calling protocols. A model registry is used to store tool description patterns and build model indexes. The task parsing module receives natural language inference tasks, parses them into structured subtasks based on the tool description pattern, and writes them into the inference state context. The structured subtasks include the required model type, initial task parameters, target output fields, constraints, and dependencies between subtasks. The call chain planning module is used to select candidate simulation models based on the model index retrieval function semantic matching and output results that cover the target output fields, according to the required model type and target output fields. It also generates model call chains and standardized call parameters based on the dependencies between subtasks. The edges of the model call chain carry field mapping rules. The simulation adaptation engine is used to convert standardized calling parameters into calling instructions of native calling interfaces, call simulation models according to model calling chains, write the native return values ​​of simulation models into the inference state context according to the tool description mode, and fill the output results of the preceding simulation model into the input parameters of the subsequent simulation model according to the field mapping rules. The simulation state manager is used to save state snapshots during simulation. The state snapshots contain the global simulation state in the simulation state context. The result analysis module is used to obtain the final output result in the deduction state context after the model call chain is completed, and to generate the deduction conclusion by comparing it with the target output field and constraint conditions.

[0048] The execution steps of the task parsing module, call chain planning module, and result judgment module in the intelligent agent.

[0049] Specific Implementation Scenario 1: The following example, using a marine engineering equipment offshore operation simulation scenario, demonstrates the complete process of tool-based encapsulation and registration of complex system simulation models. This scenario involves multiple categories of simulation models, including sea state forecasting, ship motion response, lifting loads, equipment attitude, operation windows, energy consumption, and risk assessment. The models are numerous and their inputs and outputs vary significantly, exhibiting typical characteristics of complex system deduction. The method in this embodiment encapsulates these simulation models into standardized tools that can be invoked by intelligent agents and registers them to a centrally managed model registry. This allows intelligent agents to autonomously discover and invoke the required simulation models through natural language queries.

[0050] Step 101: Design the Tool Description Schema: The tool description schema is the core data structure for encapsulating simulation model tools, stored in the form of structured metadata. This schema is not limited to a specific syntax format and can be implemented using JSON, XML, YAML, or database table structures. Its fields consist of model identifier, functional semantics, input parameters, output results, calling constraints, state declarations, and calling protocols. Specifically, the content of each field includes: The model identifier includes: model number, model name, version number, and model category; it is used to uniquely locate the simulation model and supports version management and category retrieval. Functional semantics includes: natural language function description, applicable scenarios, applicable scale, and time scale; enabling agents to understand the model's purpose and match it with task requirements; Input parameters include: parameter name, data type, physical unit, value range, required attributes, default value, and semantic description; it supports automatic generation of standardized calling parameters by the agent and supports runtime verification. The output includes: field names, data types, physical units, field meanings, and field mapping rules with subsequent simulation models; it supports automatic reading of subsequent models and parameter refeedback. Call constraints include: preconditions for calling the simulation model, dependent models, estimated execution time, and concurrency limits; used to construct the call chain and identify nodes corresponding to inoperable gaps; The state declaration includes: whether there is an internal state, the state structure, initialization, reset, serialization and saving interface, and state serialization and recovery interface at the state snapshot time; it supports snapshots and rollbacks of simulation models with internal states in multiple rounds of simulation. The calling protocol includes: synchronous or asynchronous mode, timeout threshold, retry strategy, and error code; it supports unified scheduling and exception handling by the execution engine.

[0051] Taking the offshore lifting operation window assessment model as an example, its tool description mode can include the following: The model identifiers include: model number is offshore-lifting-window-001, model name is "Offshore Lifting Operation Window Evaluation Model", and model classification is sea state model and equipment load model; Functional semantics include: calculating the available operation window that meets the constraints of lifting attitude, load and safety threshold within a future time period based on the coordinates of the operation sea area, the parameters of the target equipment, the parameters of the lifting vessel type and the sea state conditions; Input parameters include: coordinates of the work site, location of the target equipment, vessel type identification, initial heave amplitude, and predicted sea state conditions; among which the predicted sea state conditions include wave height, wave period, wind speed, current speed, and visibility; The output includes: available operation window sequence, continuous operation duration, vessel motion status, operation feasibility assessment results, and key constraint margins; Invocation constraints include: the work site is located within the sea state forecast coverage area, the work site and target equipment positions meet the basic coordinate constraints, and the model can declare the estimated calculation time and concurrency limits; Abnormal results include: when there is no safe operating window within the prediction period, ship type parameters are missing, or the calculation times out, a standardized error code and its description will be returned.

[0052] Step 102: Adaptation and encapsulation of simulation models: For existing simulation models, the adapter pattern is used for encapsulation to keep the original model code stable.

[0053] First, we analyze the native calling interface of the simulation model, including the function signature, parameter meaning, and return value structure; Then, the Tool Schema for the model is written according to the field specifications of the tool description pattern. The simulation model's native call interface and the corresponding Tool Schema jointly define the parameter names, data types, physical units, value ranges, and default values ​​of the input parameters. The agent does not define the model parameters itself.

[0054] When invoked, the agent forms a structured subtask, target model identifier, and candidate parameter values. The execution engine obtains the parameter values ​​according to the priority of the initial task parameters with explicit numerical values ​​or conditions given by the user in the natural language task instructions, the current inference configuration, and the default values ​​of the Tool Schema, and verifies the required attributes, data types, physical units, value ranges, and invocation constraints.

[0055] After the verification is passed, a standardized structured call request, i.e. a structured subtask, is generated. The adapter maps the field names, data structures and call order required by the native call interface, and completes the type conversion and unit conversion. After the simulation model returns its return value, the adapter converts the return value into structured, standardized output result fields defined by the tool description pattern, and returns error codes, unmet fields, and conversion logs. For simulation models with internal operating states, the adapter also provides state interfaces, including state serialization and state recovery interfaces; internal states include simulation time, dynamic entity states, resource or task occupancy states, and iteration progress that affect subsequent calculation results, and also include stochastic states for stochastic processes in the simulation.

[0056] Step 103: Build the model registry: The model registry provides the following functions: Firstly, model registration and storage: receiving the encapsulated simulation model's Tool Schema, storing it in the model metadata database, and generating semantic vector embeddings for each model for subsequent semantic retrieval.

[0057] Secondly, the semantic retrieval interface receives the natural language task requirement description submitted by the agent, calculates vector similarity, and returns a list of Tool Schemas for the Top-K simulation models that best match semantically.

[0058] Third, Access Control Lists (ACLs): Supports configuring callable model subsets for intelligent agents with different roles (such as task planners, on-site executors, and evaluation and reviewers) to achieve permission isolation in multi-agent collaborative simulations.

[0059] Fourth, version management and compatibility verification: maintain the historical versions of each simulation model, check the backward compatibility of the Tool Schema when the model is updated, and ensure the stable operation of the existing call chain.

[0060] The implementation of the simulation model toolkit includes the following key parts: The multi-layered semantic structure of the Tool Schema: The Tool Schema simultaneously carries natural language semantic descriptions for LLM understanding and structured constraints for program execution within the same structured metadata object. This allows the same metadata to be used for semantic matching by the AI ​​system and for parameter validation and type conversion by the runtime execution engine. This metadata object can be implemented using JSON, XML, YAML, or database table structures.

[0061] Tool Schema-Constrained Adaptation and Encapsulation: The adapter pattern itself can adopt existing implementations. The key point of this implementation is that the adapter only accepts standardized call requests (i.e., structured subtasks) validated by the Tool Schema, and performs transformations according to the declared field name mappings, data types, physical units, value ranges, and state interfaces. The adapter also converts the return values, error messages, and internal states of the native call interfaces into a unified, structured, standardized output field representation, enabling existing models to access, call, and restore states under unified constraints.

[0062] Model retrieval based on semantic vectors and hard constraint filtering: The model registry constructs index text and generates semantic vectors from the model name, model category, functional semantics, input parameters, output results, and preconditions in the Tool Schema. The task query vector is used to recall the Top-K simulation models with similar semantics. Subsequently, the execution engine filters candidate models based on required input parameters, physical units, value ranges, preconditions, permissions, and accuracy level requirements, avoiding model selection based solely on natural language similarity.

[0063] Multi-role access control: The registry maintains a role-level access control list for each model, enabling fine-grained isolation of model access permissions in multi-subject collaborative simulation scenarios.

[0064] The results of this scenario are as follows: In one implementation of the above-mentioned offshore equipment operation simulation scenario, the initial model library includes simulation models categorized as sea state forecast, ship motion response, lifting load, equipment attitude, operation window, energy consumption, and risk assessment. Each model is tool-encapsulated according to the method of this embodiment. The system can generate the following observable output formats: Encapsulation results: Each model generates a corresponding tool description pattern, adapter, and invocation constraint specification. Models of the same category can be retrieved by model number, model classification, applicable scenario, and version number. When adding a new model, the same description fields, adapter interfaces, and registration process can be reused.

[0065] Semantic retrieval performance: For the query example "Assess the risk of offshore equipment hoisting operations and equipment load in a certain sea area within the next 48 hours", candidate tools such as sea state forecast model, ship motion response model, equipment load model, and operation window assessment model are returned. The search results include model function descriptions, input parameter requirements, preconditions, and output fields, which can be used by the agent to continue planning the call chain.

[0066] System management capabilities: The model registry center supports model registration, version management, semantic retrieval, permission verification, and compatibility checks. The runtime engine can determine synchronous calls, asynchronous calls, retries, or alternative model selection based on the model's calling constraints and state declarations.

[0067] Specific Implementation Scenario 2: This embodiment uses a multi-model simulation of a space mission as an example to demonstrate a method for autonomous simulation and simulation state management based on tool invocation. In the scenario, operational personnel issue simulation task instructions in natural language (such as evaluating a spacecraft's orbital maneuvers, attitude adjustments, telemetry and control links, and energy consumption schemes within a given mission window). The intelligent agent needs to autonomously complete the entire process of task decomposition, simulation model selection, call chain planning, multi-round simulation execution, and conclusion evaluation. The simulation process involves the serial and parallel invocation of multiple heterogeneous simulation models, with complex data dependencies between models, and the simulation may require multiple iterations and branch comparisons. The execution objective of this embodiment is: how to enable the intelligent agent to autonomously manage the entire simulation process and maintain global state consistency throughout the multi-step simulation process.

[0068] This embodiment demonstrates a state management mechanism that runs throughout the entire simulation process, including the following steps: Step 201: Task Intent Analysis: The agent receives inference task instructions from the user in natural language and decomposes them into several executable simulation subtasks. This embodiment of the invention does not require training or modifying a basic large language model; instead, it utilizes an existing agent with tool invocation capabilities, constraining its task parsing behavior at runtime through structured task field templates, Tool Schema, and validation rules. The task parsing module provides the agent with fixed structured task field templates and field value rules. The structured subtasks output by the agent must be validated for field completeness, required attributes, data type, physical unit, value range, and invocation constraints before being written into the inference state context. If validation fails, missing fields or conflicting constraints are returned to the agent for re-parsing, or the subtask is marked as needing to be supplemented. Each subtask includes a subtask number, objective description, required simulation calculation type, dependencies, time range, analysis object, and constraints.

[0069] This invention does not require training or modifying a basic large language model. Instead, it utilizes an existing agent with tool-calling capabilities, constraining its task parsing behavior at runtime through structured task field templates, Tool Schema, and validation rules. The task parsing module validates the completeness, data type, and task constraints of the subtasks output by the agent. If validation fails, missing fields or conflicting constraints are returned to the agent for re-parsing, or the subtask is marked as needing to be supplemented, thus making the decomposition results searchable, verifiable, and executable.

[0070] In one alternative implementation, the structured task object includes at least the following fields.

[0071] Subtask ID: Uniquely identifies a simulation subtask to be executed; Subtask objective description: used for matching with the model's functional semantic fields; The target output fields include: the target output fields and their physical meanings, which are used to filter candidate simulation models that can produce the desired results; The analysis objects include: analysis entity objects, entity numbers, or spatial ranges, which are used to form the object boundaries of the model input parameters; The time window includes: the start and end time of the simulation, the time step, or the task window, which is used to constrain the time scale and state progression of the model; Required model type: Used to narrow down the search scope in the model registry; Dependencies include: the preceding subtask number and dependency fields, used to generate data edges in the call chain; Constraints include: accuracy requirements, resource limitations, prohibition conditions or safety thresholds, used for candidate model screening and pre-execution verification; Initial parameters include: initial task parameters, default rules, or initial parameters provided by the preceding context, used to generate the parameters for the first round of model calls; Missing parameters include: required parameters for which there is no source and the reason for their absence, which are used to trigger parameter filling, alternative model selection, or termination of the current subtask; Source fragments include: source fragments or rule sources corresponding to the natural language task, used to trace the basis for task parsing.

[0072] For example, the spacecraft energy reserve assessment subtask can be represented as follows: the subtask objective is "calculate the energy reserve change over the next 72 hours," the target output fields are energy reserve and low power risk, the analyzed entity is the target spacecraft, the time window is the next 72 hours, and the dependency fields include the attitude maneuver time period output by the attitude control model and the communication window output by the telemetry, tracking, and command (TT&C) link model. Through the above structured task objects, the agent's task decomposition results are transformed into searchable, verifiable, and executable model invocation requirements.

[0073] Step 202: Model Selection and Combination Evaluation: For each structured subtask, candidate simulation models are queried through the semantic retrieval interface of the model registry, and the retrieval results are evaluated. During the evaluation, it is first verified whether the model set can cover the computational requirements of the subtask, and then it is checked whether the preconditions and dependencies can be met; when there are candidate models with overlapping functions, the model is selected based on the estimated time consumption of the model calling constraints and the accuracy level requirements determined by the calling constraints.

[0074] Each precondition in the Tool Schema includes at least a condition identifier, input or state fields involved in the judgment, comparison operators, threshold or target value, data source, and applicable simulation time range. The execution engine first parses the condition fields in the initial task parameters, inference state context, and output of the preceding simulation model, and then performs comparison judgments according to the corresponding physical units; only when all preconditions have traceable sources and are judged to be satisfied are the candidate models and their dependent edges marked as executable. The accuracy level, maximum inference duration, time step, and initial parameters are determined in the following order of priority: explicit requirements of the user task, default values ​​of the inference configuration, and default values ​​of the Tool Schema; if no simulation model is available or the conditions cannot be met, the system supplements upstream nodes, selects alternative simulation models, or terminates the call chain.

[0075] The candidate model evaluation process can be performed by combining hard constraint filtering with rule scoring: First, filter out models that do not meet the preconditions, have missing input parameters, mismatched time scales, or do not meet the calling permissions.

[0076] Then, the overall fit is calculated for the remaining candidate models. The overall fit can be composed of the following dimensions: functional semantic matching degree, target output field coverage, required input satisfaction degree, physical unit and value range compatibility, model accuracy level, estimated time consumption, concurrency limit, and historical version compatibility.

[0077] If the required inputs of a model cannot be satisfied by the initial task parameters or the output of the preceding simulation model, the model is marked as an unexecutable candidate. If the model's output fields can cover the subtask objectives but the accuracy level or time consumption does not meet the constraints, it is retained as a downgraded candidate or an alternative candidate. This evaluation rule ensures that model selection does not rely solely on textual judgments from a large language model, but is constrained by structured fields in the Tool Schema.

[0078] Candidate model evaluation records may include the following: Functional semantic matching: The evaluation criteria are the subtask objective and the model's functional semantic fields; if the criteria are not met, the candidate ranking is reduced or the candidate set is removed.

[0079] Target output coverage: The evaluation is based on the subtask target output field and the model output field; if the target output cannot be generated, the model is eliminated.

[0080] Satisfaction of required inputs: The evaluation criteria are the model input parameters and initial parameters, and the preceding output fields; if the conditions are not met, the missing parameters are marked, and attempts are made to supplement the upstream nodes or replace the model.

[0081] Precondition satisfaction: The evaluation is based on the precondition fields of the model; if the preconditions are not satisfied, the model is eliminated when there is no source to satisfy the preconditions.

[0082] Unit and range compatibility: The evaluation is based on the physical units of input and output and the range of values; if the conditions are not met, the system will mark the system as unexecutable if the conversion is not possible or if the values ​​are out of bounds.

[0083] State snapshot support: The evaluation criteria are model state declaration and serialization interface; if the criteria are not met, the model needs to be rolled back but snapshots are not supported, so it is downgraded to a stateless candidate or eliminated.

[0084] Call protocol matching: The evaluation criteria are synchronous / asynchronous mode, timeout threshold, and retry strategy; if the criteria are not met, the task will be downgraded or eliminated if the task time limit or execution strategy is not met.

[0085] Permissions and version compatibility: The evaluation criteria are access control lists and model version compatibility; if the requirements are not met, the system will be eliminated if there is no access permission or the version is incompatible.

[0086] Step 203: Model Call Chain Planning: Based on the dependencies between subtasks and the dependency fields of each model, construct a directed acyclic graph (DAG) of model calls. Treat each simulation model call as a node in the graph, and the data flow as directed edges, labeling the edges with parameter mapping rules (i.e., which output field of the preceding simulation model maps to which input parameter of the subsequent simulation model). Simultaneously identify nodes that can be executed in parallel (nodes without a common predecessor and with independent input data), and plan parallel execution strategies; identify conditional branch nodes (nodes whose subsequent path depends on a certain condition output by the preceding simulation model), and generate branch execution logic.

[0087] The generation of a call chain DAG can include the following rules: Rule 1: For each structured subtask, obtain the Tool Schema of the candidate model from the model registry center, and select the model that can generate the target output field of the subtask as the candidate node.

[0088] Rule 2: For each candidate node, read its input parameters, preconditions, and dependent model fields; if an input parameter can be provided by the initial task parameters, mark it as an external input edge; if it can be provided by the parameter mapping rules or semantic matching relationships of the output fields of another model, establish a data edge between the two model nodes.

[0089] Rule 3: For required inputs that cannot be satisfied by the output fields of the initial task parameters or the preceding simulation model, mark them as unexecutable gaps; if there is an alternative model that can output the field, add the alternative model to the candidate call chain.

[0090] Rule 4: Nodes that do not have data dependencies and do not share mutually exclusive resource constraints are marked as parallelizable nodes; nodes that depend on the output judgment value of the preceding sequence are marked as conditional branch nodes.

[0091] Rule 5: Based on the model's estimated time consumption, accuracy level, call constraints, and whether the preconditions are met, sort the candidate call chains and select the call chain that satisfies the task objective and has the fewest unexecutable gaps.

[0092] Taking multi-model simulation of a space mission as an example, the call chain can include: the orbit calculation model reads the spacecraft's initial orbital parameters, mission time window, and orbital maneuver scheme, and outputs the orbital state and orbital maneuver time period; the attitude control model reads the orbital maneuver time period, target attitude, and attitude adjustment constraints, and outputs the attitude adjustment result and attitude maneuver time period; the telemetry, tracking, and command (TT&C) link model reads the orbital state, mission time window, and TT&C resource constraints, and outputs the communication window and link availability; the energy consumption model reads the attitude maneuver time period, communication window, and initial energy state, and outputs the energy reserve and low power risk; the risk assessment model reads the orbital maneuver, attitude adjustment, TT&C link, and energy consumption results, and outputs the mission scheme risk assessment result. The attitude control model and TT&C link model can be executed in parallel after the orbit calculation model outputs the desired conditions, the energy consumption model is executed after obtaining the attitude maneuver time period and communication window, and the risk assessment model summarizes the output results of the aforementioned models. Each edge in the above call chain stores field mapping relationships. For example, the orbital maneuvering time period output by the orbital calculation model is mapped to the input field of the attitude control model, the communication window output by the telemetry and control link model is mapped to the input field of the energy consumption model, and the energy reserve output by the energy consumption model is mapped to the input field of the risk assessment model.

[0093] The field mapping record in the call chain must include at least the source node number, source output field, source field unit, target node number, target input field, target field unit, conversion rule, type validation result, value range validation result, precondition reference, and mapping status. Mapping status includes satisfied, parameter to be added, unit to be converted, range out of bounds, and unmappingable. Only when the field semantics, data type, unit conversion, and preconditions are all satisfied is the corresponding data edge in the call chain marked as an executable edge; otherwise, the data edge is written to the intermediate result area and processed by the model selection and exception handling process.

[0094] Step 204: Simulation Execution: Following the topological order of the call chain DAG, execute the simulation model calls of each node sequentially or in parallel. For sequential nodes, wait for the predecessor node to complete, read the dependent parameter values ​​from the deduction state context, fill the input of the current node, initiate the simulation model call, and write the return result to the deduction state context. For parallel nodes, initiate multiple model calls simultaneously, wait for all parallel nodes to complete, and then merge the results of each path into the deduction state context. For conditional branch nodes, dynamically select the subsequent execution path based on the judgment field values ​​in the deduction state context.

[0095] Step 205: Result Evaluation and Iteration: The agent reads the final calculation results from the simulation state context and evaluates them against the target requirements in the task instructions. If the simulation conclusion fully answers the task instructions (the task objective has been achieved or is clearly unachievable), proceed to the report generation step. If the simulation conclusion is incomplete (e.g., some simulation models return downgraded results due to parameters exceeding the range), identify the gaps, adjust the parameters, or add new simulation model calls, and enter a new round of iteration. If scheme comparison is required (e.g., comparing the simulation results of different orbital maneuvering strategies, attitude adjustment strategies, or telemetry and control window configuration schemes), roll back to the fork point based on the state snapshot mechanism and re-execute the call chain according to the new scheme.

[0096] Step 206: Generating the simulation report: Summarize the full simulation data in the simulation state context, and generate a structured simulation report by the agent, which includes the task background, scheme overview, simulation data (quantitative results) at each stage, simulation conclusions, confidence assessment, and explanation of the main uncertainty factors.

[0097] Step 207: Deduction State Management Mechanism: The deduction state manager runs through the entire process described above and maintains the following core data structures.

[0098] Step 2071: Global Deduction State Context Structure: The global deduction state context maintains the unified state of this deduction using structured data objects, and includes at least the following data fields: The simulation identifier includes: a unique simulation number, start time, and current step number, supporting unique location and progress management during the simulation process; The simulation timeline includes: virtual time, time step, current simulation time, and historical time nodes, which uniformly manage the time progression relationship between multiple models; The entity status table includes: entity location, operating status, remaining energy, propellant, equipment capacity, communication resources, and capacity degradation coefficient, recording the status changes of objects such as spacecraft, ships, equipment, and operational nodes; The model call log includes: call steps, model number, input parameters, output results, call time, and call timestamp, supporting result traceability, anomaly location, and subsequent parameter refeedback; The intermediate results area includes: the output of the preceding simulation model, field mapping relationships, and parameters to be filled in the following simulation model, and supports data transfer across models in the call chain; The state snapshot area includes: snapshot number, snapshot creation time, global context copy, and internal state of the stateful model, supporting key node rollback, solution branching, and historical review.

[0099] In one optional implementation, a model call record in the derivation state context includes at least: call node number, model number, model version, call input, normalized output, mapping relationship between output fields and subsequent input fields, call start time, call end time, error code, number of retries, and snapshot number to which the node belongs. Through this structure, subsequent simulation models do not directly read the raw output of preceding simulation models, but instead read the normalized fields after unit conversion, type verification, and semantic confirmation through the field mapping relationship in the intermediate results area.

[0100] Step 2072: State Snapshot and Rollback Mechanism: State snapshots are automatically created at the following times: before the simulation begins (initial state), after each iteration, and at key decision nodes marked by the agent. When a rollback is needed, the target snapshot is selected from the state snapshot area, the global simulation state context is restored, and the state recovery interface of all stateful simulation models is called to restore the internal state of the model to the snapshot time.

[0101] The state snapshot data structure can include a snapshot number, the corresponding simulation number, the corresponding branch number, the snapshot creation time, the corresponding calling node number, a copy of the simulation timeline, a copy of the entity state table, a copy of the intermediate result area, a model call log index, a set of internal states of the stateful model, and a snapshot verification value. The set of internal states of simulation models with internal states is stored as key-value pairs using the model number, model version, and state serialization result. The snapshot verification value is used to confirm that the snapshot data has not been corrupted before restoration. Through this structure, the system can distinguish different scheme branches within the same simulation and restore the global simulation state and the internal states of each stateful model to the same calculation time. The snapshot field of the state snapshot data structure can include the following: The snapshot number includes: a snapshot number that uniquely identifies a recoverable state; The parent snapshot number includes: the parent snapshot number, which indicates the inheritance relationship between the branches of the scheme; Branch numbering includes: branch number, which distinguishes the original scheme from the re-engineered scheme; Triggering reasons include: initial state, critical decision point, abnormal recovery point, or solution fork point, explaining the reason for snapshot creation; Simulation time includes: current simulation time and time step, and recovery of multi-model time progression state; The entity state table copy includes: an entity state table copy that restores the object's location, resources, capabilities, and runtime status; The intermediate result area copy includes: the intermediate result area copy, the restored field mapping, and the parameters to be filled; The model call log index includes: the model call log index, which traces call records before and after the snapshot; The internal state set of the simulation model includes: the internal state set of the stateful model, which restores the internal computational state of the stateful model; The set of nodes to be executed includes: a set of nodes to be executed, which will be regenerated or cleaned up after recovery; The snapshot consistency verification field includes: the snapshot consistency verification field, which performs integrity verification before restoration.

[0102] State snapshots and rollbacks can be performed according to the following process: When creating a snapshot, the simulation state manager copies the entity state table, simulation timeline, model call log, and intermediate results area from the global simulation state context.

[0103] For simulation models declared as stateful in the Tool Schema, call their state serialization interface to obtain the internal state data of the model, and bind and save the internal state data with the snapshot number.

[0104] When an agent selects a historical snapshot for branch inference, the inference state manager first restores the global inference state context, and then calls the state recovery interface of each stateful model to restore the internal state of the model to the state corresponding to that snapshot.

[0105] After the recovery is complete, clear the pending nodes and intermediate result references after the snapshot, and regenerate or update the subsequent call chain based on the new scheme parameters.

[0106] The call logs generated by the execution of the new branch are saved with different branch numbers than those of the original branch, so that the system can retain the basis for comparison between the original and new solutions at the same time.

[0107] Through the above process, rollback does not only restore the dialogue history of the agent, but also restores the simulation time, entity state, model output, intermediate parameters and internal state of the stateful model, so that branch inference has a consistent computational starting point.

[0108] Step 2073: Structured Transfer Rules for Intermediate Results: In the call chain DAG, the input parameters of subsequent simulation models and the output result fields of preceding simulation models are automatically filled in through parameter mapping rules. The mapping rules are automatically inferred by the agent based on the semantic descriptions in the Tool Schema of each model during the DAG generation stage, and can be manually revised by the user during the derivation configuration stage.

[0109] Field mapping prioritizes explicitly declared mappable relationships in the Tool Schema. When no explicit declaration exists, matching is then performed based on field semantics, physical units, data types, and value ranges. After mapping is established, the execution engine performs type validation, unit conversion, and range validation before writing input to subsequent simulation models. If field semantics match but units differ, conversion is performed according to the unit definitions in the Tool Schema. If the converted value exceeds the value range of the subsequent simulation model, the input is marked as unsatisfactory, triggering parameter correction, alternative model selection, or termination of the current call chain. If multiple candidate output fields can be mapped to the same input field, the output field with higher accuracy, simulation time closer to the current node, and not marked as downgraded is prioritized.

[0110] Before each call, the simulation execution engine reads the mapping records in the intermediate result area, performs field extraction, unit conversion, type conversion, and range validation, and writes the validated standardized input to the current calling node. After the model call is completed, the execution engine writes the standardized output, mapping results, unmet fields, conversion logs, and error codes back to the inference state context. The result evaluation module reads the validated standardized fields to generate conclusions; for fields that fail validation or have undergone downgrade processing, they are only used as explanations of uncertainties or supplementary calling criteria.

[0111] Step 2074: Exception Handling and Degradation Strategy: When a model call times out, returns an error code, or fails input validation, the execution engine handles the situation according to the calling protocol and preset degradation rules. First, retries are performed according to the retry count, timeout threshold, and error code type specified in the Tool Schema. If the retry still fails, an alternative model with identical output field coverage, acceptable input conditions, and minimum accuracy requirements is searched in the model registry. If multiple alternative models exist, the model with higher precondition satisfaction, shorter estimated execution time, and version compatibility is prioritized. Only when approximate calculations are declared allowed in the Tool Schema or inference configuration is a preset approximate calculation model or analytical formula used to replace the original model. All degradation processing is written to the model call log, and the affected nodes, degradation reasons, and applicable conclusions are marked in the inference report.

[0112] Abnormal degradation decisions can include the following rules: The criteria for determining a timeout are: "exceeding the timeout threshold in the calling protocol", and the handling method is: "retry according to the retry strategy, and if it still fails, retrieve the alternative model"; The criterion for determining that the precondition is not met is: "Precondition field validation failed". The handling method is: "Roll back to the most recent snapshot, supplement the upstream node or terminate the critical link". The criteria for determining input out of bounds is: "The input value exceeds the range of Tool Schema values", and the handling method is: "Attempt parameter correction or model replacement; if critical inputs cannot be corrected, terminate the current node"; The criteria for determining that no result is feasible are: "The model returns business error codes such as no safe window or no reachable path", and the handling method is: "Mark this branch as infeasible, and roll back to the solution fork point if necessary"; The criteria for judging internal errors in the model are: "The model returns an internal error code or execution exception", and the handling method is: "Retry and retrieve an alternative model"; The criterion for determining the absence of a replacement model is: "The registry center has not found a candidate model that can be mapped to the same output". The handling method is: "The critical node is terminated, and the non-critical node is marked as missing and further analysis is carried out". The criteria for allowing approximate calculations are: "The deduction configuration or Tool Schema declares that approximation is possible", and the processing method is: "Invoke the preset approximation model and mark the applicable scope and the reason for downgrading".

[0113] The implementation of autonomous inference by the intelligent agent in this embodiment includes the following key parts: Task decomposition and call chain planning: The agent decomposes natural language task instructions into structured subtasks. Based on the data dependencies of each subtask and the tool schema constraints of the available simulation model, it automatically constructs a call chain in the form of a directed acyclic graph (DAG), supporting serial, parallel, and conditional branch execution modes.

[0114] Global management of simulation state context: Design a structured global simulation state context data object to uniformly manage entity states, simulation timelines, model call logs, and intermediate calculation results, providing a unified interface for parameter passing and state querying in multi-step simulation processes.

[0115] State snapshot and rollback mechanism: Automatically create a complete snapshot of the simulation state at key decision nodes (including the global context and the internal states of all stateful models), support state recovery at any historical moment, and provide underlying support for branch simulation and scheme comparison analysis.

[0116] Anomaly degradation and self-repair strategy: Construct a multi-level degradation mechanism constrained by the calling protocol. When the simulation model call fails, it will attempt to retry, replace with an alternative model, and perform approximate calculation degradation with preset permission in sequence. The affected nodes, degradation reasons and applicable scope of conclusions will be marked in the simulation report to make the simulation process traceable.

[0117] The results of this scenario are as follows: Taking a space mission simulation scenario as an example, the intelligent agent receives a natural language mission instruction to "evaluate the orbital maintenance, attitude adjustment, telemetry and control link, and energy consumption of a spacecraft within the next 72 hours, and form a comparative conclusion of multiple mission schemes." The autonomous simulation process executed according to the method of this embodiment can generate the following output format: Independent deduction capability: The natural language processing task is decomposed into sub-tasks such as trajectory calculation, attitude control, telemetry and control link, energy consumption, and risk assessment. The corresponding simulation model is automatically retrieved and selected based on the requirements of each sub-task. A model call chain containing serial nodes, parallel nodes, and conditional branches is generated.

[0118] Simulation execution log: Records the input, output, call time, and abnormal states for each model call. Determines whether supplementary calls, alternative calls, or scheme iterations are needed based on the model's returned results. Supports comparison of different orbital maneuvering strategies, attitude adjustment strategies, and telemetry and control window configuration schemes.

[0119] State management records: State snapshots are saved at the initial state, key decision nodes, and solution forks. It supports restoring the simulation state from any saved snapshot and re-executing subsequent call chains. The simulation report retains the call chain, state changes, and the basis for the conclusions, supporting subsequent review.

[0120] Specific Implementation Scenario 3: This embodiment uses a multi-agent collaborative support simulation of an offshore engineering project as an example to demonstrate an extended implementation method based on scenario two of the specific embodiment. This method involves multi-agent role-based collaborative simulation and arbitration, where each agent plays a different role and makes decisions alternately under a unified simulation clock. The evaluation and review agent calls an arbitration-type simulation model to calculate the interaction results of the multi-party actions and maintains a dual-track data structure of global real state and the observed states of each party. In this scenario, the task planner is responsible for the overall operation plan and resource allocation, the on-site execution agent is responsible for the operation of vessels, equipment, and personnel, and the evaluation and review agent is responsible for calling the arbitration-type simulation model to calculate the interaction results of the multi-party actions. The parties make decisions alternately under conditions of incomplete information: the task planner has access to the global plan and resource constraints, the on-site execution agent has access to local sea conditions, equipment status, and execution progress, and the evaluation and review agent has access to the global real state and is responsible for round progression. The simulation process needs to maintain information isolation and observation differences among the parties; each party can only make decisions based on the state data visible to its own role.

[0121] The overall system structure includes: a task planning agent, an on-site execution agent, and an evaluation and review agent. Specifically, The callable models of the task planning agent include: job planning model, resource allocation model, and global risk assessment model. Its observable data includes: overall job plan, resource constraints, and summarized job risk information. Its output includes: planning scheme and resource allocation scheme for this round. The callable models of the on-site execution agent include: ship motion model, equipment status model, and local path planning model. Its observable data includes: sea state of the operation area, task instructions, and on-site execution status. Its output results include: the execution plan for this round and on-site feedback. The callable models of the assessment and reviewing agent include: resource conflict resolution model, sea state impact model, and equipment load constraint model. Its observable data includes: global real state, proposals submitted by all parties, and common constraints. Its output results include: arbitration results, global state updates, and the observed states of all parties.

[0122] The specific execution steps are as follows: Step 301: Role Definition and Permission Isolation Mechanism: During the initialization phase, the system configures the following attributes for each role's agent. The task planning agent's callable simulation model set includes work plan models, resource allocation models, global risk assessment models, etc. The information visibility scope includes the overall work plan, resource constraints, and summarized work risk information. The initial task objective is input by the user in natural language. The on-site execution agent has an independent subset of callable models and a local observation perspective. It can call ship motion models, equipment status models, local path planning models, etc. The information visibility scope includes the sea state, task instructions, and on-site execution status of the work area. The evaluation and review agent's callable simulation model set includes public arbitration models (resource conflict resolution models, sea state impact models, equipment load constraint models, etc.). It has read and write permissions to the global real state and is responsible for round progression and status publication. Permission isolation is achieved through the access control list (ACL) of the model registry: each model number corresponds to a role access permission configuration. When an agent submits a model call request, the registry verifies whether the requesting role is in the allowed call list for that model.

[0123] Step 302: Round-based deduction protocol: The deduction is conducted in rounds, and each round contains the following four phases: Step 3021: Decision-Making Phase: The task planning agent and the on-site execution agent each receive their respective observation states and independently complete task planning and simulation model invocation within their respective decision windows, generating a structured action plan for this round. The plan includes fields such as action type, action entity, target location, equipment used, ships, personnel, and energy, and is then submitted to the evaluation and review agent. The decision-making processes of each party are isolated from each other, and neither party can access planning content beyond their assigned role's permissions.

[0124] Step 3022: Solution Phase: After receiving the action plans from multiple parties, the evaluation and reviewing agent calls the corresponding arbitration simulation model based on the action type. For resource contention, the resource conflict resolution model is called; for operation path adjustment, the sea area accessibility model and path conflict arbitration model are called; for equipment operation, the equipment load constraint model is called; for environmental perception, the sensor reliability assessment model is called. The calculation results of each arbitration model are written into the global real state.

[0125] Step 3023: State Update Phase: The evaluation and reviewing agent generates corresponding observation states for each role's agent based on the global real state. Specifically, this is done by applying information masking (hiding sensitive fields, replacing real values ​​with interval values ​​or estimated values) to entities or states outside the agent's visibility range, based on the agent's sensor model, task permissions, and data anonymization rules. The observation states are stored in the structure of the inferred state context, but each agent can only access its own observation state partition.

[0126] Step 3024: Round Advancement: Advance the global simulation clock to proceed to the next round.

[0127] Step 303: Information Asymmetry and Observation Filtering Mechanism: The assessment and review party maintains two sets of parallel data structures. The first set is the global real state, containing the real location, state, and capabilities of all entities, resources, and environmental variables, which is read and written by the assessment and review party's intelligent agent. The second set is the observation state of each party, generated from the global real state through "perception filtering" and permission filtering, containing information that the party can perceive, receive, or is authorized to use in the current round. Entities that are not perceived or authorized are represented in the observation state by historical location, estimation interval, or desensitized fields. The perception filtering process is as follows: For each entity in the global real state, the party's sensor model or data credibility model is called, and parameters such as sensor coverage, data update time, and current environmental impact are input to obtain the observation credibility. Based on the observation credibility, the entity's presentation in the observation state is determined, and corresponding measurement errors are applied to the location and state information according to the error model. The LLM inference context of each party's intelligent agent is constructed from its own observation state, forming an inference input boundary consistent with the role's permissions.

[0128] Step 304: Visual Mapping of Simulation Status: The structured data in the simulation status context is mapped to visual elements of a virtual sandbox, nautical chart, or business map. Entity location coordinates are mapped to marker points on the map, with icon styles selected based on entity type (ships, equipment, personnel, risk points, operational nodes, etc.); entity status fields (normal, restricted, faulty, disabled) are mapped to the visual status of the icons; trajectory data is mapped to movement path lines on the map. The system supports switching between two display modes: a global perspective (displaying the overall real status for review and auditing) and a subjective perspective from each party (displaying only the observation status of that party, including information masking effects).

[0129] Step 305: Recording and Branching of the Simulation Process: At the end of each round of the simulation, a snapshot of the state for that round (including the global real state and the observed states of each party), the action plans of each party, and the evaluation and review results are automatically saved, forming a complete simulation event log. The system supports the following analysis modes: Historical Replay – Reproducing the simulation process in round-by-round order, showing the decisions and state changes of each round; Key Node Retrospective – Selecting any historical snapshot restores the simulation state to that moment, allowing for readjustment of parameters or plans for branching simulations; Simulation Debriefing – Showcasing the decision-making logic, information perception differences, and key turning points of each party in each round from a global perspective.

[0130] The implementation of multi-agent collaborative inference includes the following key parts: Role-based access control: Through the access control list of the model registry center, each role's agent is configured with an independent subset of callable models, ensuring that the scope of model calls by each party is consistent with its task responsibilities, data permissions, and observation status.

[0131] Dual-track maintenance of global real state and observation state: The evaluation and review agent maintains a global state containing real information of all entities, while generating a local observation state for each party through perception filtering and permission filtering mechanisms, which only contains information that the party can perceive, receive, or is authorized to use, thus achieving accurate modeling of information asymmetry.

[0132] Round-based arbitration protocol: The four-stage round-based protocol of design decision-making, solution, update and advancement is used by the evaluation and reviewing agent to call the arbitration simulation model to uniformly solve the interaction results of the actions of all parties, so that the results of the actions of multiple parties are subject to unified state updates and physical constraints.

[0133] Full simulation recording and branch backtracking: Each round automatically saves a complete snapshot containing the global state and the observation states of each party, supporting historical playback, key node backtracking, and branch simulation, providing complete data support for simulation review and scheme optimization.

[0134] The results of this scenario are as follows: Taking the above-mentioned multi-agent collaborative support simulation scenario of an offshore engineering project as an example, the multi-agent collaborative simulation process executed according to the method of this embodiment can produce the following output format: Multi-agent collaborative capability: The task planner, on-site executor, and evaluation and reviewer each maintain independent model access permissions and observation status. Each party submits action plans according to a unified simulation clock, and the evaluation and reviewer centrally calculates the interaction results. The system records the action plans, arbitration results, and status update results for each round.

[0135] Execution efficiency assessment: The reviewing party selects the corresponding arbitration simulation model based on the action type. The system tracks the calculation process for each round based on the model call log. When resource conflicts or environmental factors render the solution unexecutable, the system generates alternative solution suggestions or rolls back to the previous snapshot for branch simulation.

[0136] Information isolation and observation consistency: Each party's LLM inference context only injects its own observation state. The global true state is maintained by the evaluation and review party, and each party's observation state is generated by perception filtering and permission filtering. The system retains records of observation state generation to support subsequent review and accountability.

[0137] In addition to the three specific embodiments described above, the present invention can also be applied to the following fields: In the field of aerospace and aviation mission planning, this includes spacecraft orbital maneuvering scheme simulation, attitude control scheme verification, telemetry and control window evaluation, energy margin analysis, and flight mission profile optimization. The intelligent agent can autonomously invoke orbital mechanics models, attitude control models, atmospheric environment models, propellant consumption models, and telemetry and control link models to generate multi-scheme comparison results.

[0138] In the field of marine engineering equipment and offshore engineering, this includes marine equipment installation, maintenance, offshore lifting, vessel operations, operational window assessment, and sea state risk analysis. The intelligent agent can autonomously invoke sea state forecast models, vessel motion response models, equipment load models, operational path models, and risk assessment models to generate feasibility assessments and operational process simulations.

[0139] In the field of industrial system simulation, this includes bottleneck analysis of complex production processes, assessment of the impact of equipment failure propagation, simulation of energy allocation schemes, and comparison of factory layout schemes. Intelligent agents can utilize production line simulation models, equipment status models, resource scheduling models, and risk assessment models to autonomously complete production optimization analysis.

[0140] In complex operational systems such as transportation, energy, and public utilities, this includes multi-source data access, operational status simulation, resource allocation, and multi-scheme evaluation. The intelligent agent can select the appropriate model based on the task objectives, maintain the simulation state context, and output traceable quantitative analysis results.

[0141] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0142] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A tool-based encapsulation and autonomous inference method for simulation models of intelligent agents, characterized in that, Includes the following steps: S1: Obtain model information for multiple simulation models, including native call interfaces, input parameters, output results, running constraints, and status information; S2: Tool description patterns for generating each simulation model based on model information. The tool description patterns are structured metadata, including at least: model identifier, functional semantics, input parameters, output results, calling constraints, state declarations, and calling protocols. S3: Storage tools describe schemas and build model indexes; S4: The agent receives the natural language inference task, parses it into structured subtasks based on the tool description pattern, and writes them into the inference state context; the structured subtasks include the required model type, initial task parameters, target output fields, constraints, and dependencies between subtasks; S5: The agent retrieves candidate simulation models based on the model index retrieval function, semantic matching, and output results that cover the target output fields, according to the required model type and target output fields. It also generates model call chains and standardized call parameters based on the dependencies between subtasks. The edges of the model call chain carry field mapping rules. S6: The execution engine converts standardized call parameters into call instructions for the native call interface, calls the simulation model according to the model call chain, writes the native return value of the simulation model into the deduction state context according to the tool description mode, and fills the output results of the preceding simulation model into the input parameters of the subsequent simulation model according to the field mapping rules. S7: Save a state snapshot during the simulation. The state snapshot contains the global simulation state in the simulation state context. S8: After the model call chain is completed, the agent obtains the final output result in the inference state context and generates the inference conclusion by comparing it with the target output field and the constraints.

2. The tool-based encapsulation and autonomous inference method for simulation models oriented towards intelligent agents according to claim 1, characterized in that, The input parameters in the tool description mode include at least parameter name, data type, physical unit, value range, whether it is required, and semantic description, which are used by the agent to generate the standardized calling parameters and by the execution engine to perform parameter verification; the output results include at least output field name, data type, physical unit, field meaning, and field mapping rules between the output field and the input parameters of the subsequent simulation model.

3. The tool-based encapsulation and autonomous inference method for simulation models oriented towards intelligent agents according to claim 1, characterized in that, The calling constraints include: Preconditions are used to indicate the conditions that must be met before calling the corresponding simulation model, including the input parameters or status fields involved in the condition judgment, comparison rules, thresholds, data sources, and applicable time ranges. Dependency model, used to indicate other simulation models that need to be called before calling the corresponding simulation model; Estimated execution time indicates the expected execution time of a single call to the corresponding simulation model; Concurrency limits are used to indicate the limit on the number of simulation models that can be called simultaneously for the corresponding simulation model; The status declaration includes: Status identifiers are used to indicate whether the corresponding simulation model has an internal operating state that affects the subsequent calculation results of the model; A state structure, used to indicate the data composition contained in the internal operating state; The state management interface is used to initialize, reset, serialize and save the state, and restore the state serialization at the state snapshot time.

4. The tool-based encapsulation and autonomous inference method for simulation models oriented towards intelligent agents according to claim 1, characterized in that, In step S6, the standardized calling parameters based on the tool description mode are converted into calling instructions required by the native calling interface through the adapter, and the native return values ​​of each simulation model are converted into the output results defined by the tool description mode through the adapter. The adapter receives standardized calling parameters that have been validated by the tool description pattern.

5. The tool-based encapsulation and autonomous inference method for simulation models oriented towards intelligent agents according to claim 1, characterized in that, The model indexing includes: constructing index text from the fields in the tool description pattern and generating corresponding semantic vectors; in step S5, retrieving candidate simulation models includes: Based on the required model type and target output field in the structured subtask, the agent returns a list of tool description patterns for semantically matched simulation model sets through vector similarity calculation; The simulation model set is filtered to remove at least one of the following simulation models: the calling constraints are not met, the required input parameters cannot be provided by the initial task parameters or the output results of the preceding simulation model, the time scale specified in the functional semantics does not match the time range of the structured subtask, and the agent role calling permissions are not met. For the simulation model that passes the filter, the comprehensive fit score is determined according to at least one of the following: matching parameters of functional semantics, attribute parameters of whether the input parameters meet the standardized call parameter conversion requirements of the tool description mode, attribute parameters of whether the output results meet the attribute description of the target output field, and attribute parameters of whether the call constraints meet the constraint conditions. Candidate simulation models are graded based on the comprehensive adaptation score, and candidate simulation models for generating the model call chain are selected from the filtered simulation models based on the graded scores.

6. The tool-based encapsulation and autonomous inference method for simulation models oriented towards intelligent agents according to claim 1, characterized in that, Step S5, the steps for generating the model call chain include: Candidate call chains are generated using candidate simulation models according to the following labeling rules: Each candidate simulation model call is taken as a node, and the data flow direction is taken as a directed edge, with the field mapping rules marked on the edge; For nodes whose input parameters are provided by the initial task parameters, mark their corresponding edges as external input edges; For cases where the input parameters are provided by the output field of another simulation model through the field mapping rule, a data edge is established between the two nodes; For nodes that do not have a preceding simulation model and a subsequent simulation model, mark them as parallelizable nodes; For nodes whose input parameters depend on the judgment values ​​of the output fields of the preceding true model, mark them as conditional branch nodes; The model call chain is generated by selecting the candidate call chain with the fewest non-executable gaps, wherein nodes whose required input parameters cannot be obtained from the initial task parameters or the output result fields of the preceding simulation model are marked as non-executable gaps.

7. The tool-based encapsulation and autonomous inference method for simulation models oriented towards intelligent agents according to claim 6, characterized in that, The state snapshot also includes the internal operating state of the simulation model with an internal operating state; in S6, for the simulation model whose state declaration indicates that it has an internal operating state, its internal operating state is obtained and written into the inference state context; the method further includes: When performing branch deduction or abnormal node recovery of the model call chain, select the target state snapshot of the branch node or abnormal node from the state snapshot, and restore the deduction state context to the time corresponding to the target state snapshot; The simulation model, which indicates that the state declaration has an internal operating state, calls its state recovery interface to restore the internal operating state to the time corresponding to the target state snapshot; Once the recovery is complete, the subsequent model call chain is regenerated or updated based on the new data in the structured subtask.

8. The tool-based encapsulation and autonomous inference method for simulation models oriented towards intelligent agents according to claim 6, characterized in that, Step S8 further includes: the agent reading the final output result in the inference state context and comparing it with the target output field and the constraints to make a judgment. If the inference conclusion does not fully answer the natural language inference task, then identify the non-executable gap, adjust the input parameters or add a new simulation model call, and enter a new round of iteration; If it is necessary to compare different schemes for the same structured subtask, the state snapshot is rolled back to the node of the model call chain corresponding to the comparison scheme, and the model call chain is re-executed according to the comparison scheme.

9. The tool-based encapsulation and autonomous inference method for simulation models oriented towards intelligent agents according to claim 1, characterized in that, It also includes the step of multi-agent collaborative simulation according to a round-based protocol: Configure a set of callable simulation models and a state access range for agents with different roles. The set of callable simulation models includes simulation models that the agent with the role has the right to call. The state access range is the range of data that the agent with the role has the right to read in the context of the inference state. Each round includes: The global real state is maintained by the evaluation and review agent, and the global real state includes the real state of the simulated entity reflected by the output result fields of each simulation model; The evaluation and review agent performs masking processing on data in the global real state that exceeds the state access permissions of the agent of each role, according to the global real state and the state access permissions of the agents of each role, to generate the observation state corresponding to the agent of that role, and stores the observation state corresponding to the agent of each role in the data partition corresponding to the agent of that role in the inference state context. Each role's intelligent agent reads the observation state from its corresponding data partition in the inference state context, generates a structured action plan for the simulated entity based on the observation state, and submits it to the evaluation and review intelligent agent; The evaluation and review agent calls the corresponding arbitration simulation model based on the structured action plan submitted by the agents of each role. The arbitration simulation model calculates the interaction results between the actions of the multiple parties and writes the calculation results into the global real state. The evaluation and review agent regenerates the observation state corresponding to each role's agent according to the updated global real state and the state access permissions of each role's agent. Advance the global simulation clock to proceed to the next round.

10. A tool-based encapsulation and autonomous inference system for agent-oriented simulation models, used to implement the agent-oriented simulation model tool-based encapsulation and autonomous inference method according to any one of claims 1 to 9, characterized in that, include: The model information acquisition module is used to acquire model information of multiple simulation models, including native call interfaces, input parameters, output results, running constraints, and status information; The tool description generation module is used to generate tool description patterns for each simulation model based on model information. The tool description pattern is structured metadata, which includes at least: model identifier, functional semantics, input parameters, output results, calling constraints, state declarations, and calling protocols. A model registry is used to store tool description patterns and build model indexes. The task parsing module receives natural language inference tasks, parses them into structured subtasks based on the tool description pattern, and writes them into the inference state context. The structured subtasks include the required model type, initial task parameters, target output fields, constraints, and dependencies between subtasks. The call chain planning module is used to select candidate simulation models based on the model index retrieval function semantic matching and output results that cover the target output fields, according to the required model type and target output fields. It also generates model call chains and standardized call parameters based on the dependencies between subtasks. The edges of the model call chain carry field mapping rules. The simulation adaptation engine is used to convert standardized calling parameters into calling instructions of native calling interfaces, call simulation models according to model calling chains, write the native return values ​​of simulation models into the inference state context according to the tool description mode, and fill the output results of the preceding simulation model into the input parameters of the subsequent simulation model according to the field mapping rules. The simulation state manager is used to save state snapshots during simulation. The state snapshots contain the global simulation state in the simulation state context. The result analysis module is used to obtain the final output result in the deduction state context after the model call chain is completed, and to generate the deduction conclusion by comparing it with the target output field and constraint conditions.

Images