Nested ai behavior scheduling service communication application generates dlf trusted device

Abstract

The application discloses a trusted device for generating a DLF through nested AI behavior scheduling service communication application, constructs a service registration module, an intelligent scheduling engine module, a service nesting and dynamic analysis module, a cross-service context transmission and state module, an intention-driven scheduling execution module, a cross-service scheduling module, a running monitoring module, and a credential aggregation module, and through the combination of the above modules, for behavior scheduling, process arrangement capability calling and other behaviors in an artificial intelligence scene, complete encapsulation of each user input, a model inference process, a knowledge base or evidence relied on, an intermediate inference chain, a final output result and inference confidence and other information into an independent OFD electronic credential is realized, all inference credentials are organized according to the order of multi-round interaction and logical dependency relationship through a DLF credential set, an AI trusted inference chain that is traceable and reproducible is formed, and thus a technical trusted basis is established in complex nested service scheduling.

Description

Technical Field

[0001] This invention belongs to the field of process scheduling technology, specifically a trusted device for generating DLFs by nested AI behavior scheduling service communication applications. Background Technology

[0002] Process orchestration refers to the orderly combination, coordination, and execution of multiple independent services, tasks, or systems according to specific business logic to achieve a complete business objective. In traditional process orchestration, the execution process is not clearly visible, resembling a black box where the flow of data transmission is unclear and different business needs cannot be responded to quickly. Summary of the Invention

[0003] The purpose of this invention is to provide a trusted device for generating DLFs by communicating with nested AI behavior scheduling services, in order to solve the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a trusted device for generating DLF through nested AI behavior scheduling service communication applications, including a service registration module, an intelligent scheduling engine module, a service nesting and dynamic parsing module, a cross-service context transmission and status module, an intent-driven scheduling execution module, a cross-service scheduling module, a runtime monitoring module, and a credential aggregation module. The service registration module is used to register interfaces on the platform and to perform full lifecycle classification and management of the registered information; after the registration process is completed, it automatically generates a service registration OFD credential, recording the metadata, tags, and timestamps of the registered service. The intelligent scheduling engine module is used to generate directed acyclic graphs (DAGs) from various nodes on a visual interface. It supports automatic import and matching of various external data formats, including flowcharts, Xmind, and requirement files. After the DAG is generated or imported, it automatically generates OFD (Organizational Documentation) vouchers, recording node types, data mapping rules, and error handling strategies. The service nesting and dynamic parsing module is used for semantic understanding to retrieve and match candidate services from the service registry. It supports the dynamic construction of multi-level nested service chains in a recursive, loop, or serial-parallel manner. After the nesting relationship is determined, it automatically generates service matching and nesting OFD credentials, and records the retrieval statement, matching results, and nesting hierarchy. The cross-service context passing and status module is used to synchronize parameters with the unified node when scheduling service bodies and maintain the real-time execution status of the entire process; each time context synchronization or status change occurs, context passing OFD credentials are automatically generated to record parameter mapping, intermediate results and process status identifiers. The intent-driven scheduling and execution module is used to parse user input commands, extract user intents, and trigger subsequent nested intelligent scheduling and execution processes by calling the API of the service nesting management module. Before intent parsing is completed and scheduling is triggered, an intent parsing and scheduling trigger OFD credential is automatically generated, recording the original command, the parsed intent, and the API information called. The cross-service scheduling module is used to execute nested main processes and sub-processes, and return the final result data. The operation monitoring module generates a unique TraceID for each behavior scheduling, which runs through the entire nested call chain, records the time and status of each service node, and automatically generates service call OFD credentials before and after the execution of each service node, recording input parameters, output results, time and status. The certificate aggregation module is used to aggregate all automatically generated OFD electronic certificates into a DLF dynamic format file according to the execution time sequence and nested call level, and apply an overall digital signature and consistency verification to the DLF file to generate a set of trustworthy DLF electronic certificates that is navigable, traceable, and tamper-proof.

[0005] Preferably, the interfaces registered on the platform in the service registration module include API service interfaces, database call interfaces, RPA robots, MCP service interfaces, vertical model datasets, and multimodal information datasets. Each registered service is tagged with multi-dimensional labels related to function, performance, and scenario. After registration, the metadata, interface definitions, and tag information of the registered services are structured and written into the DLF dynamic logic file to achieve integrated encapsulation of service description and scheduling logic. At the same time, a corresponding service registration OFD credential is generated and stored in the credential set directory of the DLF file.

[0006] Preferably, the intelligent scheduling engine module is a system that supports the construction of task flows through various methods such as drag-and-drop interface and parsing XMind structure. The operation methods include dragging and dropping orchestration nodes, parsing text logic or XMind content, automatically retrieving and matching component nodes, and dynamically generating scheduling tasks. The node types include AI dialogue nodes, knowledge base question and answer nodes, condition judge nodes, specified reply nodes, MCP call nodes, file splitting nodes, batch processing nodes, API interface nodes, and RPA robot nodes. Each node object covers type, service ID, input data mapping rules, and error handling strategy. The overall scheduling logic is based on a directed acyclic graph (DAG) representation, where nodes represent service calls and edges define the execution order and data dependencies. This is used to intelligently parse the entire process of automated task scheduling. After the DAG is generated or imported, an orchestration OFD certificate is automatically generated, recording the complete structure of the DAG and all node configuration information, and the certificate is associated with the DLF file of the current scheduling task.

[0007] Preferably, the nesting method in the service nesting management module supports recursion, and multi-level nesting is implemented in a loop; the service settings include synchronous, asynchronous, serial, and parallel. After each nesting relationship is determined, a service matching and nesting OFD certificate is automatically generated, recording the current level of nesting method, the candidate service matching list, and the finally selected service ID, and the certificate is stored in the DLF file according to the nesting depth index.

[0008] Preferably, the cross-service context transfer and status module realizes data transfer and status synchronization between the main process and each sub-process during the multi-layered nested service scheduling process, ensuring that the context information of parameters and intermediate results flows accurately and consistently between different levels or service nodes; at the same time, it maintains and updates the execution status of the entire process in real time, and the execution status specifically includes status indicators of in progress, paused, completed, and abnormal, which is used to support the collaborative control of the process, abnormal response, and full-link status visualization management. Each time a context transfer or status change occurs, an OFD certificate for context transfer is automatically generated, recording the parameter mapping, intermediate result snapshot, and changed status indicator of the transfer, and the certificate is appended to the DLF file in chronological order.

[0009] Preferably, the intent-driven scheduling execution module relies on a language understanding architecture or rule logic engine to perform deep semantic deconstruction and logical scheduling mapping on unstructured instructions or semantically ambiguous interactive content input by the user. It extracts behavioral intentions and the constraint variables bound to them, and triggers the dynamic weaving and process-oriented collaborative execution mechanism of subsequent multi-level services by calling the standardized interface defined by the service nesting management module. Before the intent parsing is completed and the scheduling is triggered, an intent parsing and scheduling trigger OFD credential is automatically generated, recording the user's original instruction, the parsed intent tag, the extracted constraint variables and the API interface information called, and storing the credential as a trusted trigger for the scheduling behavior in the DLF file.

[0010] Preferably, the cross-service scheduling module is used to control the start, pause, resumption and termination of the main process and sub-processes at all levels, schedule and manage the execution logic of serial, parallel and conditional branches between service nodes, and aggregate and return the final results of multiple branches in a unified manner. The supported nesting methods include recursion, loop and chaining; realize the delivery of context and state synchronization. The intermediate results and visual snapshots generated in this process are saved to the corresponding service call credentials in the form of OFD attachments and are uniformly included in the DLF file during the final aggregation.

[0011] Preferably, each time the operation monitoring module performs behavior scheduling, it generates a unique TraceID that runs through the entire nested call chain. It saves the time, status, and metric information of each service node in the DLF dynamic file. Specific parameters include: QPS, success rate, average response time, and nesting depth statistics. At the same time, the DLF provides a real-time graphical execution dashboard for the data generated after scheduling. It dynamically displays the execution progress of the process, the current node, and the status of each node in a highlighted and streaming form. When the process ends or an anomaly occurs, it automatically generates a monitoring OFD certificate, records the global TraceID, the aggregated metrics of all nodes, and the final execution dashboard snapshot, and stores this certificate as the summary index certificate of the DLF file in the file header.

[0012] Preferably, it also includes a service secondary registration module. Any workflow created by the user in the dynamic orchestration module generates a new, reusable service unit. The service unit will be automatically registered back to the service registration module to become a new "composite service". When the workflow is published as a new service, a composite service registration OFD certificate is automatically generated, which records the original workflow ID, the newly generated service ID, the interface definition and the registration time. The certificate is stored in a DLF file to form a trusted record of the service reuse chain.

[0013] Compared with the prior art, the beneficial effects of the present invention are: (1) This invention addresses behaviors such as behavior scheduling and process orchestration in artificial intelligence scenarios by encapsulating each user input, model inference process, the knowledge base or evidence used, intermediate inference chains, final output results, and inference confidence into an independent OFD electronic certificate. All inference certificates are organized through a DLF certificate set according to the order of multiple interactions and logical dependencies, forming a traceable and reproducible AI trusted inference chain.

[0014] (2) This invention creates a mechanism that not only makes each AI action have an immutable “trustworthy identity certificate”, but also makes the reasoning process change from a “black box” to a “white box”. Users can trace back in both directions along the DLF credential set—from the final output result back to the original input and intermediate reasoning nodes, or from the original data forward to the final conclusion.

[0015] (3) This invention uses DLF credential set to independently verify and audit the input and output of any node in the reasoning process, effectively solving the industry pain points of AI reasoning process being difficult to explain, results being difficult to verify, and responsibility being difficult to define. It provides a complete and credible traceability chain for artificial intelligence behavior from the source of data to the reasoning result, meeting the rigid requirements of various industries for auditable and regulated AI behavior.

[0016] (4) During the execution of the task, the present invention can clearly define the progress of the task, making the task process transparent and controllable. It can also manage the data transmission and status synchronization between all links, so that users can adjust the process at will and quickly respond to different business needs without rewriting complex code.

[0017] (5) The present invention can save the established intelligent agent as a new service, so that it can be used directly to build more complex "platform services", which can be used repeatedly and recombined, and the more it is used, the more powerful the function becomes. Detailed Implementation

[0018] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. 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 of ordinary skill in the art without creative effort are within the scope of protection of the present invention. Example

[0019] This invention provides a trusted device for generating DLFs for nested AI behavior scheduling service communication applications. Dynamic Layout Files (DLFs) are digital document encapsulation formats existing in the form of file packages. Based on my country's independent layout document standard OFD (Open Fixed-layout Document, GB / T 33190-2016), they aggregate multiple OFD files and their interrelationships and display relationships to form a set of layout files capable of carrying dynamic interactive behaviors. The definition of DLF is not limited to static web page archives but can also be extended to the solidification of interaction logic at the application system level. Through structured extraction and modeling techniques, the interaction logic of the application system is completely recorded in the DLF file.

[0020] The internal logic structure of DLF consists of two core components: (1) Navigation File: The DLF contains a navigation file, which mainly records the relationships between files, the entry address of the files, the storage path of each OFD file, and the trigger positions and jump events between OFD files. The navigation file is the core component of the DLF to achieve the design goal of "a group of OFD files and their relationships". It records the nested hierarchical structure, execution order and data dependencies of the main process and each level of sub-process. The format of the navigation file is usually based on XML description (such as DXM format), which has a clear structure and is easy to parse.

[0021] (2) OFD file group: The DLF contains several OFD files. Each OFD file is a formatted document conforming to the GB / T 33190-2016 standard, which independently records the static and dynamic content of a specific page or sub-process.

[0022] DLF parsing rules and interaction methods: 1. First, select the DLF file and parse it to obtain the file structure. During parsing, the hash value of the file content will be verified; if the file has been tampered with, it will be displayed as unreadable. Next, obtain the navigation pages in the DLF file package, parse the association and jump relationships between the various pages, and read the entry file address recorded in the navigation file to obtain the path of the homepage OFD.

[0023] 2. Next, load the homepage OFD file, and open and render it using the reader. While loading the homepage, simultaneously retrieve the clickable text or locations within the current OFD recorded in the navigation file, add jump models to the specified content, and add URL links pointing to other OFDs to the jump models. Simultaneously, the reader preloads the associated file information for each address path on the current page, creating multiple threads to preload the OFD files to be executed at the next level, so that they can be directly displayed when clicked.

[0024] 3. For dynamic content, during reading, N layers (from bottom to top, 1 to N) are first constructed on the base layer. The first layer is displayed by default, while the remaining layers are transparent. Combinations of dynamic operations are set as primary key IDs and mapped one-to-one with the corresponding layers. When an operation is clicked, the corresponding layer is located based on the primary key ID, the dynamic effect is loaded and displayed, and other layers are set to transparent. During reading, clicking a link immediately displays the pre-loaded target OFD, simultaneously parsing the navigation file and setting the corresponding dynamic jump relationships.

[0025] This device includes a service registration module, an intelligent scheduling engine module, a service nesting and dynamic parsing module, a cross-service context passing and status module, an intent-driven scheduling execution module, a cross-service scheduling module, a runtime monitoring module, and a credential aggregation module.

[0026] This device registers corresponding API service interfaces, database call interfaces, generated vertical model datasets, RPA robots, MCP service interfaces, and multimodal information dataset results on the platform through a service registration module. It performs full lifecycle classification and management of the registered information, even including external behavior scheduling nodes. Each registered service is tagged with multi-dimensional labels related to function, performance, and scenario, automatically generating service registration OFD credentials and recording the metadata, tags, and timestamps of the registered services. After registration, the metadata, interface definitions, and tag information of the registered services are structured and written into the DLF dynamic logic file, achieving integrated encapsulation of service description and scheduling logic. Simultaneously, a corresponding service registration OFD credential is generated and stored in the credential set directory of the DLF file. Then, through the intelligent scheduling engine module, users can drag and drop and parse various nodes, including Xmind structures, on a visual interface, automatically retrieving and matching component nodes and dynamically generating scheduling tasks. This engine implements A... The system supports various node types, including dialogue nodes, knowledge base question-and-answer nodes, conditional judgment nodes, specified reply nodes, MCP call nodes, file splitting nodes, batch processing nodes, API interface nodes, and RPA robot nodes. Each node object includes attributes such as type, service ID, input data mapping rules, and error handling strategies. These nodes are then used to generate directed acyclic graphs (DAGs). The overall scheduling logic is based on this DAG representation and supports automatic import and matching of various external data formats, including flowcharts, Xmind, and requirement files. Each registered service is tagged with multi-dimensional labels related to functionality, performance, and scenario. After registration, the metadata, interface definitions, and tag information of the registered services are structured and written into the DLF dynamic logic file, achieving integrated encapsulation of service description and scheduling logic. After DAG generation or import, an OFD (Organizational Function Descriptor) certificate is automatically generated, recording the complete structure of the DAG and all node configuration information, and this certificate is associated with the DLF file of the current scheduling task. After registration, DAG generation / import, each nesting relationship is determined, each context synchronization or state change occurs, intent parsing is completed and before scheduling is triggered, before and after each service node is executed, when the process ends or an exception occurs, and when the workflow is published as a new service, the coupling between these timings and the business process is achieved through the credential generation logic embedded in each module. Each module automatically calls the credential generation interface while executing its core functions and stores the credentials in the credential set directory of the DLF file in sequence, establishing a connection through the global TraceID and nesting depth index.

[0027] Each OFD credential defines a standardized content structure and fields. All credentials are carried by OFD documents, with machine-readable structured data (XML format recommended, following a unified namespace) embedded in their "Custom Metadata" area. The visual content can also include human-readable summary descriptions.

[0028] Taking the service registration OFD certificate as an example:

[0029] The field names are: ServiceID, ServiceName, ServiceType, Endpoint, Tags, Metadata, RegistrationTime, Status; the corresponding data types are: string, string, string, string, array, object, datetime, string; the required fields are: Yes, Yes, Yes, Conditional, No, Yes, Yes, Yes, Yes; the corresponding descriptions are: unique identifier of the registered service, service name, service type enumeration: API / DB / RPA / MCP / Model / Dataset / Other, interface address or call path (API / RPA / MCP class), multi-dimensional tag list, such as ["ocr", "high concurrency"], metadata: including creator, version, description, input / output schema, etc., registration timestamp, active / inactive / deprecated.

[0030] Triggering time: Any service interface in the platform, such as API, database, RPA, MCP, dataset, etc., after registration is completed.

[0031] After service registration is completed, users can use the service nesting and dynamic parsing module to retrieve the service set existing in the platform by voice in the interface. The service registration module can retrieve the candidate service set that matches the function. The nesting method supports recursion and loops to achieve multi-level nesting. It supports the setting of synchronous, asynchronous, serial, and parallel services. After each nesting relationship is determined, a service matching and nesting OFD certificate is automatically generated, which records the current nesting method, the candidate service matching list and the finally selected service ID. The certificate is then stored in the DLF file according to the nesting depth index. By leveraging cross-service context passing and status modules during service scheduling, data transfer and status synchronization between the main process and each sub-process are achieved in multi-layered nested service scheduling. This ensures accurate and consistent flow of context information for parameters and intermediate results across different levels or service nodes. Simultaneously, the execution status of the entire process is maintained and updated in real time, such as in progress, paused, completed, and exceptions. This completes the entire process from intelligent parsing to automated task scheduling, supporting collaborative control of the process, exception response, and full-link status visualization management. It ensures that parameters remain synchronized and consistent between nodes during scheduling across different service entities, thus completing the entire process from intelligent parsing to automated task scheduling. The engine's ultimate goal is to achieve automated and intelligent scheduling of business logic across technology stacks and systems, rather than being limited to building front-end dialog applications. Each time a context is passed or a status changes, an OFD credential is automatically generated, recording the parameter mapping, intermediate result snapshot, and changed status identifier for that pass, and this credential is appended to the DLF file in chronological order.

[0032] When a user inputs a command, the intent-driven scheduling and execution module parses the user's input command. It uses a Natural Language Processing (NLP) model, such as a BERT-based text classifier or rule engine, to parse the user's input natural language or structured command, extracting the user's intent and key parameters. By calling the API of the service nesting management module, it triggers subsequent nested intelligent scheduling and execution processes. The intent-driven scheduling and execution module relies on a language understanding architecture or rule logic engine to perform deep semantic deconstruction and logical scheduling mapping on the user's unstructured command or semantically ambiguous interactive content. It extracts the behavioral intent and the constraint variables bound to it. By calling the standardized interface defined by the service nesting management module, it triggers the dynamic weaving and process-oriented collaborative execution mechanism of subsequent multi-level services. Before the intent parsing is completed and the scheduling is triggered, an intent parsing and scheduling trigger OFD credential is automatically generated. This credential records the user's original command, the parsed intent label, the extracted constraint variables, and the API interface information called. This credential is stored in the DLF file as a trusted trigger for the scheduling behavior. Therefore, this credential can record the information of the execution at that time.

[0033] In the execution flow, the cross-service scheduling module executes the nested main process and sub-processes, returning the final result data. The cross-service scheduling module controls the start, pause, resumption, and termination of the main process and all levels of sub-processes, schedules and manages the execution logic of serial, parallel, and conditional branches between service nodes, and aggregates and returns the final results of multiple branches. It supports nesting methods including recursion, looping, and chaining; implements context passing and state synchronization, thereby enabling precise control over the start, pause, resumption, and termination of the main process and all levels of sub-processes, managing the serial, parallel, and conditional branching logic between service nodes, and is responsible for... The final result aggregation and return involves generating service call OFD credentials before and after each service node execution, recording the node's input parameters, output results, execution time, return status, and associated TraceID. All service call credentials are then organized and stored in a DLF file according to the execution order. Simultaneously, before execution orchestration, a queue is used to limit the number of concurrent executions. For cases of infinite loops, the corresponding orchestration rules are validated during behavior orchestration saving; if an infinite loop exists, a modification prompt is given. In actual operation, security restrictions are imposed on the executed tasks, and errors are proactively reported.

[0034] During task execution, the monitoring module generates a unique TraceID each time it performs behavior scheduling. This TraceID runs throughout the entire nested call chain, storing the execution time, status, and metrics of each service node in a dynamic DLF file. Specific parameters include: QPS, success rate, average response time, and nesting depth statistics. Simultaneously, the DLF provides a real-time graphical execution dashboard for the data generated after scheduling, dynamically displaying the process execution progress, the current node, and the status of each node in a highlighted and streaming format, making the process execution completely transparent. Each behavior scheduling generates a unique TraceID, which runs throughout the entire nested call chain, recording the execution time and status of each service node. Metrics include: QPS, success rate, average response time, and nesting depth statistics. This module also provides a real-time graphical execution dashboard, dynamically displaying the process execution progress, the current node, and the status of each node (e.g., success / failure / in progress) in a highlighted format. When the process ends or an anomaly occurs, a monitoring OFD credential is automatically generated, recording the global TraceID, aggregated metrics for all nodes, and a snapshot of the final execution dashboard. This credential is stored as a summary index credential in the DLF file header.

[0035] The device engine also includes a service secondary registration module. Any valid and stable workflow (such as an agent) created by a user in the dynamic orchestration module can be "published" or "saved as" a new, reusable service unit. This service unit is automatically registered back to the service registration module, becoming a new "composite service." Subsequently, this agent can be directly retrieved, referenced, and nested by other users when building new processes, just like a native service of the platform. Through the service secondary registration module, when a workflow is published as a new service, a composite service registration OFD certificate is automatically generated, recording the original workflow ID, the newly generated service ID, the interface definition, and the registration time. This certificate is then stored in a DLF file, forming a trusted record of the service reuse chain. This invention encapsulates all service interface scheduling logic, node status, execution sequence, and result data in a DLF file, forming a complete, tamper-proof, and traceable chain of execution evidence. This mechanism not only ensures that the business process can be reproduced and audited at any node, but also ensures that the final output has a clear logical source and proof of process integrity, thus establishing a technically trustworthy foundation in complex nested service scheduling. Finally, through the credential aggregation module, all automatically generated OFD electronic credentials are aggregated into a DLF dynamic format file according to the execution time sequence and nested call level. A comprehensive digital signature and consistency verification are applied to this DLF file, generating a guideable, traceable, and tamper-proof DLF trusted electronic credential set. This invention uses the DLF credential set to independently verify and audit the input and output of any node in the inference process, effectively solving the industry pain points of AI inference processes being difficult to explain, results being difficult to verify, and responsibility being difficult to define. It provides a complete and trustworthy traceability chain for artificial intelligence behavior from the data source to the inference result, meeting the rigid requirements of various industries for auditable and superviseable AI behavior.

[0036] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the invention. Therefore, the embodiments are to be regarded in all respects as exemplary and not restrictive, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, it is intended that all variations falling within the meaning and scope of equivalents of the claims be included within the present invention.

Claims

1. A nested AI behavior scheduling service communication application generates a trusted device of DLF, characterized in that: It includes a service registration module, an intelligent scheduling engine module, a service nesting and dynamic parsing module, a cross-service context passing and status module, an intent-driven scheduling execution module, a cross-service scheduling module, a runtime monitoring module, and a credential aggregation module. The service registration module is used to register interfaces on the platform and to perform full lifecycle classification and management of the registered information; after the registration process is completed, it automatically generates a service registration OFD credential, recording the metadata, tags, and timestamps of the registered service. The intelligent scheduling engine module is used to generate directed acyclic graphs (DAGs) from various nodes on a visual interface. It supports automatic import and matching of various external data formats, including flowcharts, Xmind, and requirement files. After the DAG is generated or imported, it automatically generates OFD (Organizational Documentation) vouchers, recording node types, data mapping rules, and error handling strategies. The service nesting and dynamic parsing module is used for semantic understanding to retrieve and match candidate services from the service registry. It supports the dynamic construction of multi-level nested service chains in a recursive, cyclic, and serial-parallel manner. After the nesting relationship is determined, it automatically generates service matching and nesting OFD credentials, recording the retrieval statement, matching results, and nesting hierarchy. The nesting method in the service nesting and dynamic parsing module supports recursion and cyclic implementation of multi-level nesting. The service settings include synchronous, asynchronous, serial, and parallel. After each nesting relationship is determined, it automatically generates service matching and nesting OFD credentials, recording the current level of nesting method, candidate service matching list, and the finally selected service ID. The credentials are then stored in a DLF file indexed by nesting depth. The cross-service context passing and status module is used to synchronize parameters with the unified node when scheduling service bodies and maintain the real-time execution status of the entire process; each time context synchronization or status change occurs, context passing OFD credentials are automatically generated to record parameter mapping, intermediate results and process status identifiers. The intent-driven scheduling and execution module is used to parse user input commands, extract user intents, and trigger subsequent nested intelligent scheduling and execution processes by calling the API of the service nesting management module. Before intent parsing is completed and scheduling is triggered, an intent parsing and scheduling trigger OFD credential is automatically generated, recording the original command, the parsed intent, and the API information called. The cross-service scheduling module is used to execute nested main processes and sub-processes, and return the final result data; The operation monitoring module generates a unique TraceID for each behavior scheduling, which runs through the entire nested call chain, records the time and status of each service node, and automatically generates service call OFD credentials before and after the execution of each service node, recording input parameters, output results, time and status. The certificate aggregation module is used to aggregate all automatically generated OFD electronic certificates into a DLF dynamic format file according to the execution time order and nested call level, and apply an overall digital signature and consistency verification to the DLF file to generate a set of DLF trusted electronic certificates that is viewable, traceable, and tamper-proof. It also includes a service secondary registration module. Any workflow created by the user in the dynamic orchestration module generates a new, reusable service unit. The service unit will be automatically registered back to the service registration module to become a new "composite service". When the workflow is published as a new service, a composite service registration OFD certificate is automatically generated, which records the original workflow ID, the newly generated service ID, the interface definition and the registration time. The certificate is stored in a DLF file to form a trusted record of the service reuse chain.

2. The nested AI behavior scheduling service communication application generation DLF trusted device of claim 1, wherein: The service registration module registers interfaces on the platform, including API service interfaces, database call interfaces, RPA robots, MCP service interfaces, vertical model datasets, and multimodal information datasets. Each registered service is tagged with multi-dimensional labels related to functionality, performance, and scenarios. After registration, the metadata, interface definitions, and tag information of the registered services are structured and written into the DLF dynamic logic file to achieve integrated encapsulation of service description and scheduling logic. At the same time, a corresponding service registration OFD credential is generated and stored in the credential set directory of the DLF file. 3.The trusted device for generating DLF by nested AI behavior scheduling service communication application according to claim 1, wherein: The intelligent scheduling engine module is a system that supports the construction of task flows through various methods such as dragging and dropping nodes and parsing XMind structures. The operation methods include dragging and dropping to arrange nodes, parsing text logic or XMind content, automatically retrieving and matching component nodes, and dynamically generating scheduling tasks. The node types include AI dialogue nodes, knowledge base question and answer nodes, condition judge nodes, specified reply nodes, MCP call nodes, file splitting nodes, batch processing nodes, API interface nodes, and RPA robot nodes. Each node object includes type, service ID, input data mapping rules, and error handling strategy. The overall scheduling logic is based on a directed acyclic graph (DAG) representation, where nodes represent service calls and edges define the execution order and data dependencies. This is used to intelligently parse the entire process of automated task scheduling. After the DAG is generated or imported, an OFD certificate for process orchestration is automatically generated, recording the complete structure of the DAG and the configuration information of all nodes. This certificate is then associated with the DLF file of the current scheduled task.

4. The nested AI behavioral scheduling service communication application DLF trusted device generating of claim 1, wherein: The cross-service context transfer and status module enables data transfer and status synchronization between the main process and each sub-process during multi-layered nested service scheduling. This ensures that the context information of parameters and intermediate results flows accurately and consistently between different levels or service nodes. Simultaneously, it maintains and updates the execution status of the entire process in real time. The execution status specifically includes status identifiers such as in progress, paused, completed, and abnormal. This supports collaborative control of the process, abnormal response, and full-link status visualization management. Each time a context transfer or status change occurs, an OFD credential for context transfer is automatically generated, recording the parameter mapping, intermediate result snapshot, and changed status identifier for that transfer. This credential is then appended to the DLF file in chronological order.

5. The nested AI behavioral dispatch service communication application DLF trusted device generating of claim 1, wherein: The intent-driven scheduling and execution module relies on a language understanding architecture or rule logic engine to perform deep semantic deconstruction and logical scheduling mapping on unstructured instructions or semantically ambiguous interactive content input by the user. It extracts behavioral intentions and the constraint variables bound to them, and triggers the dynamic weaving and process-oriented collaborative execution mechanism of subsequent multi-level services by calling the standardized interface defined by the service nesting management module. Before the intent parsing is completed and the scheduling is triggered, it automatically generates an intent parsing and scheduling trigger OFD credential, records the user's original instruction, the parsed intent label, the extracted constraint variables, and the API interface information called, and stores this credential as a trusted trigger for the scheduling behavior in the DLF file.

6. The trusted device that generates DLFs for nested AI behavior scheduling service communication applications of claim 1, wherein: The cross-service scheduling module is used to control the start, pause, resume and terminate of the main process and sub-processes at all levels, schedule and manage the execution logic of serial, parallel and conditional branches between service nodes, and aggregate and return the final results of multiple branches in a unified manner. It also supports nesting methods including recursion, loop and serial. To achieve context delivery and state synchronization, service call OFD credentials are generated before and after the execution of each service node. The node's input parameters, output results, execution time, return status and its TraceID are recorded, and all service call credentials are organized and stored in the DLF file in the execution order.

7. The nested AI behavioral dispatch service communication application DLF trusted device generating of claim 1, wherein: The cross-service scheduling module, during AI semantic question answering or file querying, presents the process scheduling data and analysis process in a real-time interactive streaming manner using a think-based orchestration approach. It runs the node and status information, and during result derivation, it uses a DLF dynamic layout file to capture the running results in real time and analyze the running status. Based on a dynamic approach, it draws the progress of the running results in real time, visually displaying the running steps and orchestrating the complete results. Intermediate results and visual snapshots generated during this process are saved as OFD attachments to the corresponding service call credentials and are uniformly included in the DLF file during final aggregation.

8. The trusted device that generates DLFs for nested AI behavior scheduling service communication applications of claim 1, wherein: Each time the operation monitoring module performs behavior scheduling, it generates a unique TraceID that runs through the entire nested call chain. It saves the time, status, and metric information of each service node in the DLF dynamic file. Specific parameters include: QPS, success rate, average response time, and nesting depth statistics. At the same time, the DLF provides a real-time graphical execution dashboard for the data generated after scheduling. It dynamically displays the execution progress of the process, the current node, and the status of each node in a highlighted and streaming form. When the process ends or an anomaly occurs, it automatically generates a monitoring OFD certificate, records the global TraceID, the aggregated metrics of all nodes, and the final execution dashboard snapshot, and stores this certificate as the summary index certificate of the DLF file in the file header.