An AI workflow plug-in capability contract management method and system

Abstract

The application belongs to the technical field of workflow management, and discloses an AI workflow plug-in capability contract management method and system; including: receiving the capability original description information actively pushed by each business module, executing namespace regularization and contract standardization encapsulation, generating a standard capability contract object, and establishing a capability contract index set; according to the capability contract index set, receiving a life cycle event and a dynamic resource state event, and forming a runtime capability state graph; according to the runtime capability state graph, extracting a standard capability contract object in an orchestratable state, and performing input / output structure matching, compatibility matching and budget feasibility matching to form an orchestration-ready capability relationship set; according to the orchestration-ready capability relationship set and the runtime capability state graph, providing an external capability directory summary interface and an incremental event subscription interface; the application can comprehensively improve the accuracy, real-time performance and reliability of artificial intelligence workflow automatic orchestration.

Description

Technical Field

[0001] This invention relates to the field of workflow management technology, and more specifically, to a method and system for managing AI workflow plug-in capability contracts. Background Technology

[0002] With the widespread application of artificial intelligence technology, current AI workstation platforms generally adopt a plug-in architecture to support heterogeneous AI capabilities such as large language models, computer vision, and speech processing, in order to decouple the underlying algorithm logic from the front-end interactive interface. In the existing typical plug-in architecture, there is usually a UI module layer for front-end interaction and a skill logic layer for code reuse. Developers register modules with the system through declarative files, and the front-end can dynamically render navigation menus and operation forms accordingly. However, the core design goal of this traditional two-layer abstract architecture is only configuration-driven UI and code dependency management. What it declares to the outside world is often just static UI layout and code component versions, without standardizing the service interface semantics of the AI ​​capabilities themselves (such as HTTP call paths, JSON mode of input and output parameters, streaming response characteristics, and hardware resource consumption). As a result, when the platform needs to support the upper-layer system to freely combine the underlying capabilities to build complex workflow scenarios, the system cannot provide a machine-readable structured capability directory. Neither the scenario definition module nor the intelligent code generation model can automatically understand the call parameters and return structures of various capabilities in the system based on the existing static declaration files, and therefore cannot automatically generate cross-module data flow connections and interface call code.

[0003] Furthermore, in complex AI workflow orchestration scenarios, the availability of various AI capabilities is not static but tightly bound to the loading status of underlying dynamic resources such as models. For example, the service availability of a large AI model varies significantly at different stages, such as unloaded, loading, ready, or unloaded. Existing microservice registry centers or plugin registration mechanisms typically only manage the start and stop of the overall module process and do not establish a linkage mechanism between the module lifecycle and the specific AI capability operation status within the module. On the one hand, when the status of underlying dynamic resources changes, the system cannot map it to fine-grained capability availability changes in real time and synchronize it externally, causing the upper-level orchestrator to easily make invalid calls to capability nodes that are in an unavailable state. On the other hand, when a business module is completely unloaded, the system also lacks a cascading cleanup mechanism for its exposed capabilities, making it easy for invalid capability catalog entries to remain in the registry center. Therefore, how to achieve standardized definition of heterogeneous AI capability contracts and build a contract management and discovery mechanism that coordinates with the module lifecycle and dynamic resource status has become the key to improving the efficiency of automatic orchestration of artificial intelligence workflows.

[0004] In view of this, the present invention proposes an AI workflow plug-in capability contract management method and system to solve the above problems. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the existing technology and achieve the above objectives, the present invention provides the following technical solution: a method for managing AI workflow pluggable capability contracts, comprising: After each business module completes its own initialization, it receives the original description information of the capabilities pushed by each business module, including capability identifier field, belonging module field, category field, associated skill field, calling field, mode field, streaming field, resource field and initial state field; Based on the original capability description information, namespace regularization and contract standardization encapsulation are performed to generate standard capability contract objects. Based on the capability identifier field and the belonging module field, a primary index and a module auxiliary index are established to form a capability contract index set. Based on the capability contract index set, the system receives lifecycle events generated by the module registry center and dynamic resource status events reported by each business module. It maps lifecycle events and dynamic resource status events to runtime state changes of corresponding standard capability contract objects, and performs state updates and batch cascaded deregistration by module to form a runtime capability state diagram. Based on the runtime capability state diagram, extract standard capability contract objects that are in the orchestration-ready state. Perform input / output structure matching based on the pattern field, compatibility matching based on the streaming field, and budget feasibility matching based on the resource field on the extracted standard capability contract objects to generate data flow compatibility relationships and execution feasibility relationships, and form an orchestration-ready capability relationship set. Based on the orchestration-ready capability relationship set and runtime capability state diagram, it provides an interface for summarizing the capability catalog and an interface for subscribing to incremental events.

[0006] Furthermore, methods for performing namespace regularization and contract standardization encapsulation include: Perform category enumeration value validation on the category field and determine whether to write it to the category subfield; perform format compliance validation and call enumeration value validation on the call field and determine whether to write it to the call endpoint subfield and call method subfield respectively; perform JSON Schema compliance validation on the pattern field and determine whether to write it to the input pattern subfield and output pattern subfield respectively. Perform boolean type compliance checks on streaming fields and determine whether to write to streaming support subfields; perform non-negative integer compliance checks on resource fields and determine whether to write to memory consumption estimation subfields and GPU memory consumption estimation subfields respectively; perform state enumeration value checks on initial state fields and determine whether to write to runtime state subfields. Define a three-part namespace, perform namespace normalization on the capability identifier field and the belonging module field to form a normalized globally unique capability identifier; assemble the normalized globally unique capability identifier with each subfield to form a complete standard capability contract object.

[0007] Furthermore, methods for forming a capability contract index set include: A primary index and module auxiliary indexes are established and used together as the capability contract index set. The primary index uses a globally unique capability identifier as the key and the corresponding standard capability contract object as the value. The module auxiliary index uses the belonging module field as the key and the list of capability identifiers corresponding to the belonging module field as the value. The capability identifier list is a list of all globally unique capability identifiers corresponding to the belonging module field. After each standard capability contract object is received, the primary index is updated based on the globally unique capability identifier formed by the capability identifier field and the belonging module field, and the module auxiliary index is updated based on the belonging module field.

[0008] Furthermore, methods for mapping to runtime state changes include: Two independent lifecycle event channels and dynamic resource status event channels are established, and lifecycle events and dynamic resource status events are received respectively. The lifecycle event includes the module to which it belongs and the event type identifier. Based on the event type identifier, it is determined whether to map the lifecycle event to a batch cascading deregistration change. If so, the batch cascading deregistration execution process by module is initiated. The dynamic resource status event is mapped to a single capability status update change and the status update execution process is initiated.

[0009] Furthermore, methods for forming runtime capability state diagrams include: The runtime state subfield corresponding to the standard capability contract object is marked as the runtime state value. Based on the globally unique capability identifier and the runtime state value, a runtime capability state graph is constructed. The runtime capability state graph is a hash mapping structure with the globally unique capability identifier as the key and the runtime state value of the corresponding standard capability contract object as the value, and it is a dynamic structure.

[0010] Furthermore, methods for performing input / output structure matching based on pattern fields include: All standard capability contract objects in a programmable state are aggregated to form a set of programmable capability contract objects, and all ordered capability pairs are enumerated from it. For each ordered capability pair, field name existence verification and field type compatibility verification are performed based on the input pattern subfield and the output pattern subfield. Based on the verification results, it is determined whether there is a data flow compatibility relationship. For ordered capability pairs with data flow compatibility relationships, a data flow compatibility relationship entry and field name mapping list are recorded.

[0011] Furthermore, methods for performing compatible matching based on streaming fields include: For each data flow compatibility relationship entry, based on the streaming support subfield of each standard capability contract object in the corresponding ordered capability pair, determine whether the corresponding ordered capability pair meets the streaming compatibility conditions; based on the determination result, mark the streaming compatibility status of each group of ordered capability pairs, and add the streaming compatibility status to the corresponding data flow compatibility relationship entry.

[0012] Furthermore, methods for performing budget feasibility matching based on resource fields include: Obtain the total available memory and total available GPU memory, and calculate the effective memory limit and effective GPU memory limit based on the preset resource safety margin ratio; perform a full resource aggregation for the set of programmable capability contract objects to obtain the estimated memory consumption and GPU memory consumption of the entire workflow, and compare them with the effective memory limit and effective GPU memory limit respectively, and generate executable relationship entries based on the comparison results.

[0013] Furthermore, the methods for providing the capability catalog aggregation interface and incremental event subscription interface to external parties include: The capability catalog aggregation interface is exposed externally in the form of a REST API to receive capability catalog query requests. After receiving a capability catalog query request, it determines whether the capability catalog query request contains category filtering parameters, and forms a set of capability objects to be aggregated based on the determination result. For the set of capability objects to be aggregated, it performs information aggregation and response data organization processes to obtain structured response data. After serializing the structured response data in JSON format, it is returned to the querying party through the capability catalog aggregation interface. The incremental event subscription interface is exposed to the outside world in the form of a WebSocket long connection. During system operation, it continuously receives capability registration events, capability status change events, and capability batch deregistration events, and performs corresponding broadcast operations through the incremental event subscription interface.

[0014] An AI workflow plug-in capability contract management system, implementing the method, includes: The capability access module is used to receive the original capability description information pushed by each business module after each business module has completed its own initialization. This includes capability identifier field, belonging module field, category field, associated skill field, call field, mode field, streaming field, resource field, and initial status field. The contract standardization module is used to perform namespace standardization and contract standardization encapsulation based on the original capability description information, generate standard capability contract objects, and establish a primary index and a module auxiliary index based on the capability identifier field and the belonging module field to form a capability contract index set. The status linkage module is used to receive lifecycle events generated by the module registry center and dynamic resource status events reported by each business module according to the capability contract index set, map the lifecycle events and dynamic resource status events to the runtime status changes of the corresponding standard capability contract objects, and perform status updates and batch cascaded deregistration by module to form a runtime capability status diagram. The orchestration matching module is used to extract standard capability contract objects in the orchestrable state based on the runtime capability state diagram, perform input-output structure matching based on the pattern field, compatibility matching based on the streaming field, and budget feasibility matching based on the resource field on the extracted standard capability contract objects, generate data flow compatibility relationships and execution feasibility relationships, and form an orchestration-ready capability relationship set. The catalog service module is used to provide an interface for summarizing the capability catalog and an interface for subscribing to incremental events, based on the orchestration-ready capability relationship set and the runtime capability state diagram.

[0015] The technical effects and advantages of the AI ​​workflow plug-in capability contract management method and system of this invention are as follows: By introducing a third-layer capability registry center orthogonal to the module registry center and skill registry center into the pluggable AI workstation platform, deep decoupling of UI layout contracts and service call contracts is achieved, enabling business modules to independently adjust the granularity of exposed capabilities without modifying the front-end declaration file. By defining standard capability contract objects that include JSON patterns for input parameters and output parameters, streaming support identifiers, capability categories, and hardware resource consumption estimates, a machine-readable AI capability interface semantic description system is constructed. This allows the code generation model to automatically discover, understand, and consume various capabilities within the system without requiring manual reading of business module source code or interface documentation. By employing a mechanism combining proactive business module push and dual-event channel status linkage, capability registration, status updates, and the actual readiness of dynamic resources are precisely bound, eliminating the inconsistency between capability descriptions and actual availability caused by platform-driven scanning. By introducing a three-segment namespace regularization mechanism and a collaborative management mechanism of the main index and module auxiliary index, the uniqueness and traceability of capability identifiers worldwide are ensured, and automatic batch cascading cleanup of all capability contracts is achieved when a business module is uninstalled, avoiding the risk of invalid calls caused by residual invalid directory entries. By combining JSON-based... The system employs schema field compatibility analysis for input / output structure matching, streaming support for consistency checks, and resource budget feasibility estimation for full combinations and non-empty true subsets. This allows the system to identify incompatible interface semantics, mismatched transmission methods, and resource overruns in capability combinations before the orchestration phase. It directly outputs field name mapping information and remaining resource margin information as an orchestration-ready capability relationship set, enabling the code generation model to automatically generate data flow connection code that satisfies both interface contract constraints and actual resource carrying capacity. Simultaneously, through the collaborative design of the REST capability directory aggregation interface and the WebSocket incremental event subscription interface, the external orchestration system can continuously maintain a local capability view consistent with the capability registry center with low network overhead. Furthermore, it can promptly reassess the effectiveness of workflow paths when capability availability dynamically changes, thereby comprehensively improving the accuracy, real-time performance, reliability, and adaptability of AI-powered automated workflow orchestration. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of an AI workflow plug-in capability contract management system according to Embodiment 1 of the present invention; Figure 2 This is a flowchart of an AI workflow plug-in capability contract management method according to Embodiment 2 of the present invention. Detailed Implementation

[0017] 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.

[0018] Example 1: Please refer to Figure 1 As shown in this embodiment, the AI ​​workflow plug-in capability contract management system operates as an independent capability registry center in the underlying software architecture, and is orthogonal and decoupled from the existing module registry center and skill registry center; specifically, it includes a capability access module, a contract standardization module, a status linkage module, an orchestration and matching module, and a directory service module; the modules are connected through software communication mechanisms such as internal interface calls or event message buses to realize data transmission and business collaboration between modules.

[0019] The capability access module is used to receive the original capability description information pushed by each business module after each business module has completed its own initialization. This includes capability identifier field, belonging module field, category field, associated skill field, call field, mode field, streaming field, resource field, and initial status field.

[0020] Methods for receiving the raw capability description information pushed by each business module include: During system startup, the module registry (a system management component for managing business module registration, route mounting, and lifecycle) scans and loads each business module, while the skill registry (a system management component for managing skill unit code instantiation and dependency resolution) scans and instantiates each skill unit. The capability access module does not actively scan any directories; it only initializes and mounts its own receiving endpoint. The design logic of using module-driven push rather than system-driven scanning is that the true readiness of dynamic resources within each business module (such as the loading progress of a specific model instance in a large language model engine) is only perceived by the business module itself. If the platform uses active scanning, capability discovery cannot be triggered at the correct time, leading to capability registration before resources are ready, causing a fundamental inconsistency between capability description and actual availability. After completing its own initialization and ensuring its internal dynamic resources are ready, each business module actively calls the registration interface exposed by the capability access module to push the original description information of the capabilities supported by the corresponding business module. This original capability description information specifically includes capability identifier fields, belonging module fields, associated skill fields, call fields, mode fields, streaming fields, resource fields, and initial state fields. The capability identifier field is used to uniquely identify the original identifier name of the corresponding capability. It is filled in by each business module when pushing the capability and usually includes components such as operation type and resource instance identifier. It is used for namespace normalization processing in the subsequent contract normalization module. The belonging module field is used to identify the unique code of the business module that pushes the original description information of the corresponding capability. It is filled in by each business module when pushing the capability and is used to establish a module auxiliary index in the subsequent contract normalization module. The category field is used to identify the capability category to which the corresponding capability belongs. It is filled in by each business module according to the functional semantics of the corresponding capability when pushing the capability and is used to support filtering by category in the subsequent directory service module. The associated skill field is used to identify the skill unit that the corresponding capability depends on (can be empty). It is filled in by each business module as needed when pushing the capability and is used to record the association between the capability and the skill unit registered in the skill registry in the capability contract. The call field contains the relative call path and HTTP call method of the corresponding capability. It is filled in by each business module according to its own registered API endpoints when pushing the capability and is used as the basis for the caller to initiate the actual network request in the subsequent directory service module. The pattern field contains the JSON pattern definitions for the input and output parameters of the corresponding capabilities. These are defined by each business module according to the JSON format during push notifications. The Schema standard field is used for standardizing contract encapsulation in the subsequent contract standardization module and for matching input / output structures in the orchestration matching module. The Streaming field indicates whether the corresponding capability supports streaming responses (including server-side push events and WebSockets). Each business module fills in a boolean value based on its own API implementation when pushing the data, and this is used for streaming compatibility matching in the subsequent orchestration matching module. The Resource field contains the statically estimated memory consumption and statically estimated GPU memory consumption of the corresponding capability, both in megabytes. Each business module estimates and fills this field based on its internal model configuration information (such as model parameter size, quantization accuracy, context length, etc.) when pushing the data, and this is used for resource budget feasibility matching in the subsequent orchestration matching module. The Initial State field indicates the initial availability state of the corresponding capability upon initial registration. Each business module fills this field based on the actual readiness of the current dynamic resources when pushing the data, specifically including Available, Loading, Unloaded, Error, and Busy. This is used to assign the initial runtime state of the standard capability contract object in the subsequent contract standardization module.

[0021] The contract standardization module is used to perform namespace standardization and contract standardization encapsulation based on the original capability description information, generate standard capability contract objects, and establish a primary index and a module auxiliary index based on the capability identifier field and the belonging module field to form a capability contract index set.

[0022] Methods for performing namespace curvature include: A three-segment namespace is defined, with the format: Module Identifier Segment, Operation Type Segment, and Resource Instance Segment. The three segments are separated by colons, resulting in the overall format: Module Identifier Segment: Operation Type Segment: Resource Instance Segment. Based on this three-segment namespace, namespace regularization is performed to form a regularized globally unique capability identifier. Specifically, the capability identifier field and the module identifier field are extracted from the original capability description information. The module identifier field is used as the module identifier segment, ensuring that the correspondence between the globally unique capability identifier and its associated business module can be directly read from the globally unique capability identifier. An operation mapping table is preset, which is used to... The operation type contained in the capability identifier field is mapped to a standard operation type; the operation mapping table is pre-configured by those skilled in the art based on the typical operational semantics of various AI capabilities within the platform (such as dialogue, reasoning, recognition, transcription, synthesis, etc.); the operation type in the capability identifier field is obtained, and the operation type is converted into the corresponding standard operation type through the operation mapping table, and used as the operation type segment; the resource instance identifier in the capability identifier field is obtained, and used as the resource instance segment; the resource instance identifier usually corresponds to a specific model identifier, dataset identifier, or hardware resource identifier; the belonging module identifier segment, the operation type segment, and the resource instance segment are concatenated in sequence to form a globally unique capability identifier.

[0023] The methods for standardizing and encapsulating contract execution include: For the category field, the value of the category field is extracted from the original capability description information, and a category enumeration value verification is performed. This verification ensures that the value of the category field belongs to a preset capability category set. The capability category set is pre-defined by those skilled in the art based on typical classification systems of AI capabilities within the platform, including but not limited to large language model categories, computer vision categories, speech processing categories, and multimodal categories. If the category field passes the category enumeration value verification, it is written into the category subfield of the standard capability contract object. If the category field fails the verification, the current contract standardization encapsulation request is rejected, and an alarm log is recorded. The alarm log includes the belonging module field and the category field that failed the category enumeration value verification. For the associated skill field, extract its value from the original capability description information and determine if it is empty. If the associated skill field is not empty, use its value as the query key to send a query request to the skill registry center to verify if it corresponds to an instantiated skill unit. If the skill registry center confirms the existence of the corresponding skill unit, write it into the associated skill sub-field of the standard capability contract object. If the skill registry center returns that no corresponding skill unit exists, set the associated skill sub-field to empty and record an alarm in the operation log. The alarm includes the belonging module field and the associated skill field to help troubleshoot missing skill unit dependencies. If the associated skill field is empty, set the associated skill sub-field of the standard capability contract object to empty. For the call field, the value of the call field is extracted from the original capability description information, and the relative call path and HTTP call method are parsed from it. A format compliance check is performed on the relative call path, and a call enumeration value check is performed on the HTTP call method. The format compliance check requires that the relative call path must begin with a forward slash character and must not contain any spaces, non-ASCII characters, or illegal URL characters. The call enumeration value check requires that the HTTP call method must be one of GET, POST, PUT, or DELETE. If both the format compliance check and the call enumeration value check pass, the relative call path is written to the call endpoint subfield of the standard capability contract object, and the HTTP call method is written to the call method subfield of the standard capability contract object. If either the format compliance check or the call enumeration value check fails, the contract standardization encapsulation request is rejected, and an alarm log is recorded. The alarm log includes the belonging module field and the relative call path or HTTP call method that failed the corresponding check. For the schema field, the JSON schema definitions for input parameters and output parameters are extracted from the original capability description information. JSON Schema compliance checks are then performed on both the input and output parameter JSON schema definitions to verify whether they meet the basic structural requirements of the JSON Schema specification. The JSON Schema compliance check method is a standard technique in this field, and the specific process will not be elaborated upon here. If both the input and output parameter JSON schema definitions pass the JSON Schema compliance check, the input parameter JSON schema definition is written to the input schema subfield of the standard capability contract object, and the output parameter JSON schema definition is written to the output schema subfield of the standard capability contract object. If either the input or output parameter JSON schema definition fails the JSON Schema compliance check, the contract standardization encapsulation request is rejected, and an alarm log is recorded. The alarm log includes the attribution module field and the input or output parameter JSON schema definition that failed the JSON Schema compliance check. For streaming fields, the values ​​are extracted from the original capability description information and Boolean type compliance checks are performed to ensure that the value of the streaming field is either true or false. Boolean type compliance checks are a standard technique in this field, and the specific process will not be elaborated upon here. If the streaming field passes the Boolean type compliance check, it is written into the streaming support subfield of the standard capability contract object. If the streaming field fails the Boolean type compliance check, the contract standardization encapsulation request is rejected and an alarm log is recorded. The alarm log includes the attribution module field and the streaming field. For the resource field, the static estimated memory consumption and static estimated GPU memory consumption are extracted from the original capability description information. Non-negative integer compliance checks are performed on both static estimated memory consumption and static estimated GPU memory consumption to ensure that both values ​​are integers greater than or equal to zero. If both static estimated memory consumption and static estimated GPU memory consumption pass the non-negative integer compliance check, the static estimated memory consumption is written to the memory consumption estimation subfield of the standard capability contract object, and the static estimated GPU memory consumption is written to the GPU memory consumption estimation subfield of the standard capability contract object. If either static estimated memory consumption or static estimated GPU memory consumption fails the non-negative integer compliance check, the contract standardization encapsulation request is rejected, and an alarm log is recorded. The alarm log includes the belonging module field and the static estimated memory consumption or static estimated GPU memory consumption that failed the non-negative integer compliance check. For the initial state field, its value is extracted from the original capability description information, and a state enumeration value validation is performed. This validation ensures the initial state field's value is one of "available," "loading," "unloaded," "error," or "busy." If the initial state field passes the validation, it is written to the runtime state subfield of the standard capability contract object and used as the initial runtime state of the corresponding capability contract object during its first registration. If the initial state field fails the validation, the standardization encapsulation request is rejected, and an alarm log is recorded. The alarm log includes both the belonging module field and the initial state field. The standardized globally unique capability identifier is assembled with each subfield to form a complete standard capability contract object. The standard capability contract object itself does not carry any execution logic. After obtaining the standard capability contract object, the caller directly initiates a network request to the original API of the corresponding business module based on the corresponding call endpoint subfield and call method subfield. The capability registry center only acts as a directory service and does not forward requests, thereby ensuring that the introduction of the capability registry center will not have any intrusive impact on the API routing layer of the existing business modules.

[0024] Methods for forming a capability contract index set include: Two independent hash mapping structures are established: a primary index and a module-level secondary index. These two indexes together form the capability contract index set. The primary index uses a globally unique capability identifier as the key and the corresponding standard capability contract object as the value, supporting precise single-item retrieval based on the globally unique capability identifier. The module-level secondary index uses the belonging module field as the key and a list of capability identifiers corresponding to that field (i.e., a list of all globally unique capability identifiers corresponding to the belonging module field) as the value, supporting batch capability retrieval based on the belonging module field. Both hash mapping structures are initially empty sets and are gradually filled as each business module actively pushes its original capability description information. Upon receiving a standard capability contract object, the main index is updated based on the globally unique capability identifier formed by the capability identifier field and the home module field, and the module auxiliary index is updated based on the home module field. The method for updating the main index is as follows: extract the globally unique capability identifier from the standardized standard capability contract object, and use the corresponding globally unique capability identifier as the key to determine whether an entry containing the corresponding standard capability contract object already exists in the main index. If it does not exist, insert a new entry into the main index with the corresponding globally unique capability identifier as the key and the corresponding standard capability contract object as the value, completing the initial registration of the corresponding standard capability contract object. If it already exists, overwrite the standard capability contract object in the corresponding entry with the standard capability contract object currently corresponding to the globally unique capability identifier, completing the update of the corresponding standard capability contract object. The method for updating the module auxiliary index is as follows: Extract the belonging module field from the original capability description information. Using the corresponding belonging module field as the key, determine whether the corresponding entry (i.e., the corresponding capability identifier list) already exists in the module auxiliary index. If it does not exist, insert a new entry into the module auxiliary index using the corresponding belonging module field as the key and a new capability identifier list containing only the corresponding globally unique capability identifier as the value. If it already exists, further determine whether the corresponding globally unique capability identifier already exists in the corresponding capability identifier list. If it does not exist, append the corresponding globally unique capability identifier to the corresponding capability identifier list. If it already exists, keep the corresponding capability identifier list unchanged.

[0025] The status linkage module is used to receive lifecycle events generated by the module registry center and dynamic resource status events reported by each business module according to the capability contract index set. It maps the lifecycle events and dynamic resource status events to the runtime status changes of the corresponding standard capability contract objects, and performs status updates and batch cascading deregistration by module to form a runtime capability status diagram.

[0026] Methods for receiving lifecycle events and dynamic resource status events include: Two independent event channels are established: a lifecycle event channel and a dynamic resource status event channel. Each channel has a continuously running event listener waiting to receive events. The reason for the independence of these two event channels is that lifecycle events are generated by the module registry center, and their triggering is driven by the module registry center's routing mounting and unmounting processes, completely unrelated to the state changes of specific dynamic resources within the business modules. Dynamic resource status events, on the other hand, are generated by each business module itself, and their triggering is driven by the resource management logic within the business module. Separating these two types of event channels ensures that their respective transmission paths are clear and do not interfere with each other, preventing delays in lifecycle event processing from affecting the response speed of high-frequency dynamic resource status events. For lifecycle events, when a business module enters a predetermined lifecycle node, the module registry center outputs the corresponding lifecycle event and writes it into the lifecycle event channel. Lifecycle nodes include, but are not limited to, initialization completion nodes, route mounting completion nodes, and unmounting completion nodes. An initialization completion node indicates the completion of business module code loading and instance creation; a route mounting completion node indicates the completion of business module external access route registration; and an unmounting completion node indicates the completion of business module route removal and instance destruction. After a lifecycle event is written into the lifecycle event channel, a continuously running event listener reads the lifecycle event from the channel. Each lifecycle event includes an attribution module field and an event type identifier, with the event type identifier identifying the corresponding lifecycle node. For dynamic resource status events, when the running status of a dynamic resource changes within a business module, the business module proactively initiates a status reporting request and writes the corresponding dynamic resource status event into the dynamic resource status event channel. The dynamic resource status event includes a globally unique capability identifier and a target runtime status value. The target runtime status value is filled in according to the actual changes in the current dynamic resource, and specific values ​​include available, loading, unloaded, error, and busy. After the dynamic resource status event is written into the dynamic resource status event channel, a continuously running event listener reads the dynamic resource status event from the channel. Upon reading the dynamic resource status event, a status enumeration value verification is performed on the target runtime status value. If the target runtime status value passes the status enumeration value verification, the corresponding dynamic resource status event is received; if the target runtime status value fails the status enumeration value verification, the corresponding dynamic resource status event is discarded.

[0027] Methods for mapping lifecycle events and dynamic resource state events to runtime state changes of corresponding standard capability contract objects include: For lifecycle events, the event type identifier is determined. If the event type identifier is an unloading completion node, the corresponding lifecycle event is mapped to a batch cascading deregistration change and the module-by-module batch cascading deregistration execution process is initiated. If the event type identifier is an initialization completion node, a route mounting completion node, or other lifecycle nodes, the corresponding lifecycle event is determined not to trigger any runtime state changes. For dynamic resource state events, the corresponding dynamic resource state event is mapped to a single capability state update change and the state update execution process is initiated.

[0028] Methods for performing status updates and batch cascading deregistration by module include: Using the globally unique capability identifier corresponding to the dynamic resource status event as the key, the corresponding entry is retrieved from the main index within the capability contract index set. If the corresponding entry does not exist in the main index, it is determined that the capability corresponding to the globally unique capability identifier has been deregistered or never registered, and the corresponding dynamic resource status event is discarded. If the corresponding entry exists in the main index, the runtime status value corresponding to the globally unique capability identifier is further retrieved from the runtime capability status diagram. If the retrieved runtime status value is the same as the target runtime status value in the dynamic resource status event, it is determined that this dynamic resource status event is a duplicate report, and no status update operation is triggered. If the retrieved runtime status value is different from the target runtime status value in the dynamic resource status event, the runtime status value of the entry corresponding to the globally unique capability identifier in the runtime capability status diagram is updated to the target runtime status value, completing the refresh of the runtime capability status diagram. At the same time, the runtime status subfield of the corresponding standard capability contract object in the main index within the capability contract index set is synchronously updated to the target runtime status value to ensure that the status records of the standard capability contract object in the main index are consistent with those in the runtime capability status diagram. Using the attribution module field corresponding to the lifecycle event as the key, a retrieval operation is performed in the module auxiliary index within the capability contract index set to obtain the capability identifier list corresponding to the attribution module field, and mark it as the capability identifier list to be deregistered. If the capability identifier list to be deregistered is empty or no capability identifier list is obtained, it is determined that the corresponding business module did not register any capabilities before being uninstalled, and the subsequent deregistration operation is skipped. If the obtained capability identifier list to be deregistered is not empty, the following two operations are performed sequentially for each globally unique capability identifier in the capability identifier list to be deregistered: First, using the globally unique capability identifier as the key, delete the corresponding entry in the primary index within the capability contract index set; Second, using the globally unique capability identifier as the key, delete the corresponding status entry in the runtime capability status diagram to ensure that the runtime capability status diagram no longer contains the status information of deregistered capabilities. After the above two operations are completed for all globally unique capability identifiers in the capability identifier list to be deregistered, using the corresponding attribution module field as the key, delete the corresponding entry in the module auxiliary index, so that the module auxiliary index is restored to the initial state where the corresponding business module has never registered any capabilities. After the status update is completed, a capability status change event is pushed to the event broadcast channel of the directory service module; after the batch deregistration by module is completed, a batch capability deregistration event is pushed to the event broadcast channel of the directory service module. The capability status change event contains the globally unique capability identifier and the target runtime status value from the dynamic resource status event. This allows the directory service module to broadcast the event to all external connections through the incremental event subscription interface, notifying the orchestrator and front-end connections to be aware of the dynamic changes in capability availability in real time. The batch capability deregistration event contains the globally unique capability identifiers of all deregistered capabilities and the module field that triggered the batch deregistration operation by module. This allows the directory service module to broadcast the event to all external connections through the incremental event subscription interface, enabling the orchestrator and front-end connections to promptly remove the corresponding invalid capability records from their local cache in batches.

[0029] Methods for generating runtime capability state diagrams include: The runtime state subfield corresponding to the standard capability contract object is marked as the runtime state value. A runtime capability state graph is constructed based on the globally unique capability identifier and the runtime state value. The runtime capability state graph is a hash mapping structure with the globally unique capability identifier as the key and the runtime state value of the corresponding standard capability contract object as the value. The runtime capability state graph is not a static structure generated all at once at a specific moment, but a dynamic structure maintained collaboratively by the following three types of operations: First, when the contract regulation module generates a new standard capability contract object, it obtains the globally unique capability identifier and runtime state value corresponding to the new standard capability contract object, and based on the globally unique capability identifier and runtime state value, establishes a corresponding state entry for the corresponding standard capability contract object in the runtime capability state graph; Second, when a dynamic resource state event enters... The state update execution process is as follows: when the target runtime state value differs from the runtime state value in the runtime capability state diagram, the runtime state value of the corresponding state entry in the runtime capability state diagram is updated to the target runtime state value. Thirdly, when a lifecycle event enters the batch cascaded deregistration execution process by module, all state entries in the corresponding module field of the runtime capability state diagram are deleted in batches. Through the coordination of these three types of operations, the runtime capability state diagram always accurately reflects the real-time runtime state of all standard capability contract objects in the capability contract index set, providing a reliable data foundation based on the latest state for the subsequent orchestration and matching module when filtering standard capability contract objects with orchestratable states. At the same time, it enables the directory service module to quickly obtain a snapshot of the current runtime state of all capabilities without traversing the main index when responding to capability directory summary query requests.

[0030] The orchestration matching module is used to extract standard capability contract objects in the orchestrable state based on the runtime capability state diagram, perform input-output structure matching based on pattern field, compatibility matching based on streaming field, and budget feasibility matching based on resource field on the extracted standard capability contract objects, generate data flow compatibility relationships and execution feasibility relationships, and form an orchestration-ready capability relationship set.

[0031] Methods for extracting standard capability contract objects in an orchestratable state include: Traverse all state entries in the runtime capability state graph, filter out globally unique capability identifiers whose runtime state values ​​are available, and form a set of programmable capability identifiers. Using each globally unique capability identifier in the set of programmable capability identifiers as a key, retrieve the corresponding standard capability contract object in the main index within the capability contract index set, and summarize all retrieved standard capability contract objects to form a set of programmable capability contract objects. It should be understood that each standard capability contract object in the set of programmable capability contract objects has been encapsulated through contract standardization, and has compliant and complete input mode subfields, output mode subfields, streaming support subfields, memory consumption estimation subfields, and GPU memory consumption estimation subfields, which meet the data integrity prerequisites required for subsequent three-dimensional matching.

[0032] Methods for performing input / output structure matching based on pattern fields include: Enumerate all ordered capability pairs from the set of programmable capability contract objects. Each ordered capability pair consists of any two standard capability contract objects from the set of programmable capability contract objects, and label the two standard capability contract objects in each ordered capability pair as capability A and capability B, respectively. Capability A serves as the predecessor node of the data flow, and capability B serves as the successor node of the data flow. For each ordered capability pair in the set of programmable capability contract objects, extract the corresponding output pattern subfield from the standard capability contract object of capability A, and extract the corresponding input pattern subfield from the standard capability contract object of capability B. Perform necessary input field extraction operation on the input pattern subfield of capability B to obtain the necessary input field set of capability B. Perform available output field extraction operation on the output pattern subfield of capability A to obtain the available output field set of capability A.

[0033] Specifically, all attribute names are enumerated from the properties object of the input pattern sub-field corresponding to capability B, and then the intersection of this intersection with the required attribute names declared in the required array is taken to obtain the set of necessary input fields for capability B. If the set of necessary input fields corresponding to capability B is empty, it is directly determined that there is a data flow compatibility relationship between capability A and capability B, without performing subsequent field name existence verification and field type compatibility verification. All attribute names are enumerated from the properties object of the output pattern sub-field corresponding to capability A to obtain the set of output fields that capability A can provide.

[0034] For each necessary field in the set of necessary input fields corresponding to capability B, perform field naming existence verification and field type compatibility verification in sequence. The specific process of field naming existence verification is as follows: if there is no output field in the set of output fields corresponding to capability A that is the same as the necessary field, it means that the corresponding necessary field cannot be satisfied by the output of capability A, and it is determined that there is no data flow compatibility relationship between capability A and capability B; if there is an output field in the set of output fields corresponding to capability A that is the same as the necessary field, then continue to perform field type compatibility verification. The specific process of field type compatibility verification is as follows: Obtain the `type` attribute value of the necessary field in the corresponding input pattern sub-field of capability B and mark it as the input attribute value; obtain the `type` attribute value of the necessary field in the corresponding output pattern sub-field of capability A and mark it as the output attribute value; if the input attribute value and the output attribute value are the same, the corresponding necessary field is determined to be compatible, i.e., the field type compatibility verification passes; if the input attribute value and the output attribute value are different, further determine whether there is an implicit compatibility relationship based on the preset JSON Schema type compatibility relationship judgment rules; wherein, the JSON Schema type compatibility relationship judgment rules are preset by those skilled in the art according to the JSON Schema specification, for example, the integer type is compatible with the number type; if there is no implicit compatibility relationship, it indicates that the corresponding necessary field is incompatible, and it is determined that there is no data flow compatibility relationship between capability A and capability B; if there is an implicit compatibility relationship, the corresponding necessary field is determined to be implicitly compatible, i.e., the field type compatibility verification passes.

[0035] If all necessary fields in the set of necessary input fields for capability B pass the field name existence verification and field type compatibility verification, then a data flow compatibility relationship is determined to exist between capability A and capability B. The globally unique capability identifiers corresponding to the two standard capability contract objects in the corresponding ordered capability pair are recorded as a data flow compatibility relationship entry. At the same time, the mapping relationship between all necessary fields in this verification process and the corresponding output fields in the set of output fields that capability A can provide is recorded in the data flow compatibility relationship entry, forming a field name mapping list. The field name mapping list is the direct field binding basis for the code generation model when automatically generating cross-capability data flow connection code, so that the code generation model does not need to re-infer the correspondence between fields. After all ordered capability pairs in the orchestratable capability contract object set have completed field name existence verification and field type compatibility verification, all data flow compatibility relationship entries and their corresponding field name mapping lists are summarized to form a data flow compatibility relationship set. The data flow compatibility relationship set is the core component of the orchestration-ready capability relationship set, and each data flow compatibility relationship entry directly corresponds to an automatically orchestratable cross-capability data transfer path.

[0036] Methods for performing compatible matching based on streaming fields include: For each data flow compatibility relationship entry in the data flow compatibility relationship set, obtain the standard capability contract object of the corresponding ordered capability pair, and extract the value of the streaming support subfield as the streaming Boolean value. If the streaming Boolean value of capability A is the same as that of capability B, the corresponding ordered capability pair is determined to meet the streaming compatibility condition, the streaming compatibility status is marked as compatible, and the streaming compatibility status is added to the corresponding data flow compatibility relationship entry. If the streaming Boolean value of capability A is different from that of capability B, the corresponding ordered capability pair is determined to not meet the streaming compatibility condition, the streaming compatibility status is marked as incompatible, and the streaming compatibility status is added to the corresponding data flow compatibility relationship entry. In the corresponding data flow compatibility relationship entries, data flow compatibility relationship entries with a streaming compatibility status of incompatible are not deleted from the data flow compatibility relationship set, but are retained in their entirety with the incompatible label. The purpose is to provide the code generation model with complete compatibility information, enabling the code generation model to proactively decide whether to introduce a streaming-to-batch adaptation layer or a batch-to-stream adaptation layer between streaming-incompatible ordered capability pairs when generating orchestration code. After compatibility matching is completed, each data flow compatibility relationship entry in the data flow compatibility relationship set contains two pieces of information: a field name mapping list and a streaming compatibility status, which together constitute a complete compatibility description at the interface semantic level.

[0037] Methods for performing budget feasibility matching based on resource fields include: The total available memory and total available GPU memory of the current system are obtained from the system resource management component (i.e., the system-level monitoring component used to monitor the available computing resources of the current host machine or GPU cluster in real time), both in megabytes. A preset resource safety margin ratio is set by those skilled in the art based on the typical baseline resource usage of the host operating system and background resident services, with a value range of greater than zero and less than or equal to one. The product of the total available memory and the resource safety margin ratio is calculated to obtain the effective memory limit. The product of the total available GPU memory and the resource safety margin ratio is calculated to obtain the effective GPU memory limit. The effective memory limit and the effective GPU memory limit together define the hardware resource boundary that the current system can actually allocate to AI workflow instances. For the set of programmable capability contract objects, a full resource aggregation is performed. Specifically, the estimated memory consumption subfield of all standard capability contract objects in the set of programmable capability contract objects is summed to obtain the estimated memory consumption value for the entire workflow; the estimated GPU memory consumption subfield of all standard capability contract objects in the set of programmable capability contract objects is summed to obtain the estimated GPU memory consumption value for the entire workflow; the estimated memory consumption value for the entire workflow is compared with the effective memory limit, and the estimated GPU memory consumption value for the entire workflow is compared with the effective GPU memory limit; if the estimated memory consumption value for the entire workflow is less than or equal to... If the effective memory limit is less than or equal to the estimated GPU memory consumption of the entire workflow, then the set of programmable capability contract objects is recorded as an executable feasible relation entry. The remaining memory margin and remaining GPU memory margin are recorded in the executable feasible relation entry, and marked as having sufficient resources. The remaining memory margin is calculated as follows: the difference between the effective memory limit and the estimated memory consumption of the entire workflow is used to obtain the remaining memory margin. The remaining GPU memory margin is calculated as follows: the difference between the effective GPU memory limit and the estimated GPU memory consumption of the entire workflow is used to obtain the remaining GPU memory margin. If the estimated memory consumption of the full workflow exceeds the effective memory limit, or the estimated GPU memory consumption of the full workflow exceeds the effective GPU memory limit, then a subset enumeration is performed on the set of programmable capability contract objects, enumerating all non-empty true subsets within the set. For each non-empty true subset, the sum of the estimated memory consumption subfields and the sum of the estimated GPU memory consumption subfields of all standard capability contract objects within it are calculated to obtain the subset memory consumption estimate and the subset GPU memory consumption estimate, respectively. The subset memory consumption estimate of each non-empty true subset is compared with the effective memory limit, and the subset GPU memory consumption estimate of each non-empty true subset is compared with the effective GPU memory limit. The comparison is performed. If the estimated memory consumption of the subset is less than or equal to the effective memory limit, and the estimated GPU memory consumption of the subset is less than or equal to the effective GPU memory limit, then the corresponding non-empty true subset is recorded as an executable feasible relation entry. The corresponding remaining memory margin value and the remaining GPU memory margin value of the subset are recorded in the corresponding executable feasible relation entry. The calculation method for the remaining memory margin value of the subset is as follows: calculate the difference between the effective memory limit and the estimated memory consumption of the subset to obtain the remaining memory margin value of the subset. The calculation method for the remaining GPU memory margin value of the subset is as follows: calculate the difference between the effective GPU memory limit and the estimated GPU memory consumption of the subset to obtain the remaining GPU memory margin value of the subset. Methods for forming an orchestration-ready capability relation set include: All executable feasible relationship entries are summarized to form an executable feasible relationship set, which is then summarized and integrated with the data flow compatibility relationship set that has completed compatibility matching to form an orchestration ready capability relationship set. Among them, the orchestration ready capability relationship set is the core output structure that provides orchestration information to the outside world, the data flow compatibility relationship set provides connection feasibility and field binding information at the interface semantic level, and the executable feasible relationship set provides combination feasibility and remaining resource margin information at the resource level. Together, they provide a complete basis for the code generation model to automatically generate AI workflow orchestration code that meets interface semantic constraints and resource constraints.

[0038] The catalog service module is used to provide an interface for summarizing the capability catalog and an interface for subscribing to incremental events, based on the orchestration-ready capability relationship set and the runtime capability state diagram.

[0039] The methods for providing a capability catalog summary interface to external parties include: The capability catalog aggregation interface is exposed externally in the form of a REST API, receiving capability catalog query requests from the scenario definition module or the code generation model. The design logic of the capability catalog aggregation interface is that before generating AI workflow orchestration code, the code generation model needs to obtain a complete description of all available capabilities in the system at once, including calling specifications, interface semantics, interconnect compatibility and resource constraint information. By providing a structured aggregation interface with a single entry point, the code generation model can obtain all the information required to generate orchestration code in a single network request, without having to query each business module one by one. Upon receiving a capability catalog query request, it is determined whether the request contains category filtering parameters. The values ​​of these parameters are pre-defined by those skilled in the art based on the typical classification system of AI capabilities within the platform, and are consistent with the values ​​of the category sub-fields in the standard capability contract objects. If the capability catalog query request contains category filtering parameters, then category pre-filtering is performed on the standard capability contract objects in the main index of the capability contract index set according to the category filtering parameters, retaining only the standard capability contract objects whose category sub-fields match the category filtering parameters, and forming a set of capability objects to be aggregated. If the capability catalog query request does not contain category filtering parameters, then all standard capability contract objects in the main index of the capability contract index set are aggregated to form a set of capability objects to be aggregated. For the set of capability objects to be aggregated, an information aggregation process is performed. Specifically, each standard capability contract object in the set of capability objects to be aggregated is traversed, and the corresponding runtime state value is read from the runtime capability state diagram using the corresponding globally unique capability identifier as the key. The read runtime state value is then updated to the runtime state sub-field of the corresponding standard capability contract object to ensure that the runtime state sub-field returned to the querying party can reflect the latest availability status. At the same time, the set of data flow compatibility relationships and the set of execution feasibility relationships related to the set of capability objects to be aggregated are read from the orchestration-ready capability relationship set, and the field name mapping list and streaming compatibility status of each ordered capability pair are extracted. After information aggregation is completed, a response data organization process is executed. Specifically, for each standard capability contract object in the set of capability objects to be aggregated, the corresponding globally unique capability identifier, calling endpoint subfield, calling method subfield, input mode subfield, output mode subfield, streaming support subfield, memory consumption estimation subfield, GPU memory consumption estimation subfield, runtime status subfield, and the list of data flow compatibility relationships established between the corresponding standard capability contract object and other standard capability contract objects when the corresponding standard capability contract object is used as the predecessor node of the data flow are jointly organized into capability entries for the corresponding standard capability contract object. Among them, the data flow compatibility relationship list contains multiple relationship records, and each relationship record contains the globally unique capability identifier of the successor node of the data flow, the field name mapping list, and the streaming compatibility status. All capability entries and the set of executable feasible relationships are serialized together into structured response data. The structured response data is serialized in JSON format and returned to the querying party. The code generation model summarizes the structured response data of the interface through the consumption capability directory. Without the need for manual reading of the source code or interface documentation of any business module, it can fully obtain the calling specifications, interface semantics and interconnection compatibility information of all currently available AI capabilities in the system. Then, it can automatically generate cross-module data flow connection code based on the field name mapping list between each capability, and automatically select a workflow combination scheme that meets the current system resource constraints based on the set of executable feasible relationships.

[0040] Methods for providing incremental event subscription interfaces to external parties include: A WebSocket connection manager is established, and all currently active WebSocket connections are maintained in memory using a hash mapping structure. The incremental event subscription interface is exposed externally in the form of a long WebSocket connection, allowing the scenario definition module, code generation model, or front-end connection to continuously receive status change pushes from the capability registry after establishing a long connection. The design logic of the incremental event subscription interface is as follows: In the AI ​​workflow orchestration scenario, the built workflow instance is extremely sensitive to changes in the availability of the capability nodes it depends on. If the external system relies on polling the capability directory summary interface to perceive status changes, there will be a delay in status perception and a large number of invalid queries. By implementing event-driven incremental status push through a long WebSocket connection, the external system can receive a notification the moment the capability status changes, and only perform local cache updates on the changed parts without having to fetch the full directory data again. When a new connection initiates a WebSocket handshake request, the WebSocket connection manager completes the handshake protocol processing and registers the new connection to the active connection hash map of the WebSocket connection manager; when a connection actively initiates a disconnection request or does not respond to the heartbeat probe packet within the preset heartbeat timeout period, the WebSocket connection manager removes it from the active connection hash map and releases the corresponding connection resources; the heartbeat timeout period is preset by those skilled in the art based on the typical connection stability requirements of the platform network environment; During system operation, the following three types of events are continuously received from the event broadcast channel, and the corresponding broadcast operations are executed: The first type of event is the capability registration event. After the contract standardization module completes the establishment of the main index and module auxiliary index of the capability contract index set for the new standard capability contract object, it pushes the event to the event broadcast channel. After receiving the capability registration event, the directory service module extracts the globally unique capability identifier of the new standard capability contract object from the capability registration event. Using the corresponding globally unique capability identifier as the key, it retrieves the corresponding standard capability contract object in the main index within the capability contract index set, and serializes it together with the corresponding runtime state value in the runtime capability state diagram into JSON format. This JSON, along with the event type identifier (capability registration event), is encapsulated into a capability registration event message and broadcast to all active connection ends through the WebSocket connection manager. After receiving the capability registration event message, the external connection end can directly append the content to the locally cached capability directory without having to fetch the full directory data again. The second type of event is the capability status change event. When the dynamic resource status event enters the status update execution process and the target runtime status value is different from the runtime status value in the runtime capability status diagram, the status linkage module pushes it to the event broadcast channel. After receiving the capability status change event, the directory service module extracts the globally unique capability identifier that has changed and the target runtime status value from the capability status change event. It encapsulates the two together with the event type identifier (capability status change event) into a capability status change event message and broadcasts it to all active connection ends through the WebSocket connection manager. After receiving the capability status change event message, the external connection end locates the corresponding capability record in the local cache with the globally unique capability identifier as the key, updates the corresponding runtime status value to the target runtime status value contained in the capability status change event message, and re-evaluates the validity of the workflow paths corresponding to the capabilities that depend on the globally unique capability identifier that has changed. The third type of event is the batch capability deregistration event. This event is pushed to the event broadcast channel by the status linkage module after the module-by-module batch cascading deregistration operation is completed. Upon receiving the batch capability deregistration event, the directory service module extracts all globally unique capability identifiers that have been deregistered and the field of the module that triggered the current module-by-module batch cascading deregistration operation. These two identifiers, along with the event type identifier (batch capability deregistration event), are encapsulated into a batch capability deregistration event message, which is then broadcast to all active connection endpoints via the WebSocket connection manager. Upon receiving the batch capability deregistration event message, the external connection endpoint removes the corresponding invalid capability records from the local cache in batches based on the deregistered globally unique capability identifiers. Simultaneously, it re-evaluates the validity of the execution path for all workflow instances involving the capabilities corresponding to the deregistered globally unique capability identifiers. If the evaluation result indicates that the workflow path has been interrupted due to capability failure, it triggers the corresponding alarm or re-arrangement process. By broadcasting three types of events in real time, the incremental event subscription interface enables external systems to maintain a local capability status view consistent with the capability registry center in an event-driven manner. This eliminates the inherent state awareness delay problem of the polling method, enabling the AI ​​workflow orchestration system to respond to dynamic changes in capability availability with the fastest workflow path adjustment speed.

[0041] This embodiment introduces a third-layer capability registry center, orthogonal to the module registry center and skill registry center, into the pluggable AI workstation platform. This achieves deep decoupling between UI layout contracts and service call contracts, enabling business modules to independently adjust the granularity of exposed capabilities without modifying the front-end declaration file. By defining standard capability contract objects that include JSON patterns for input parameters and output parameters, streaming support identifiers, capability categories, and hardware resource consumption estimates, a machine-readable AI capability interface semantic description system is constructed. This allows the code generation model to automatically discover, understand, and consume various capabilities within the system without requiring manual reading of business module source code or interface documentation. By employing a mechanism combining proactive push from business modules and dual-event channel status linkage, capability registration, status updates, and the actual readiness of dynamic resources are precisely bound, eliminating the inconsistency between capability descriptions and actual availability caused by platform-driven scanning. By introducing a three-segment namespace regularization mechanism and a collaborative management mechanism for the main index and module auxiliary index, the uniqueness and traceability of capability identifiers worldwide are ensured, and automatic batch cascading cleanup of all capability contracts is achieved when a business module is uninstalled, avoiding the risk of invalid calls caused by residual invalid directory entries. By combining JSON-based... The system employs schema field compatibility analysis for input / output structure matching, streaming support for consistency checks, and resource budget feasibility estimation for full combinations and non-empty true subsets. This allows the system to identify incompatible interface semantics, mismatched transmission methods, and resource overruns in capability combinations before the orchestration phase. It directly outputs field name mapping information and remaining resource margin information as an orchestration-ready capability relationship set, enabling the code generation model to automatically generate data flow connection code that satisfies both interface contract constraints and actual resource carrying capacity. Simultaneously, through the collaborative design of the REST capability directory aggregation interface and the WebSocket incremental event subscription interface, the external orchestration system can continuously maintain a local capability view consistent with the capability registry center with low network overhead. Furthermore, it can promptly reassess the effectiveness of workflow paths when capability availability dynamically changes, thereby comprehensively improving the accuracy, real-time performance, reliability, and adaptability of AI-powered automated workflow orchestration.

[0042] Example 2: Please refer to Figure 2 As shown, for parts not described in detail in this embodiment, please refer to the description in Embodiment 1. This embodiment provides a method for managing AI workflow plug-in capability contracts, the method including: After each business module completes its own initialization, it receives the original description information of the capabilities pushed by each business module, including capability identifier field, belonging module field, category field, associated skill field, calling field, mode field, streaming field, resource field and initial state field; Based on the original capability description information, namespace regularization and contract standardization encapsulation are performed to generate standard capability contract objects. Based on the capability identifier field and the belonging module field, a primary index and a module auxiliary index are established to form a capability contract index set. Based on the capability contract index set, the system receives lifecycle events generated by the module registry center and dynamic resource status events reported by each business module. It maps lifecycle events and dynamic resource status events to runtime state changes of corresponding standard capability contract objects, and performs state updates and batch cascaded deregistration by module to form a runtime capability state diagram. Based on the runtime capability state diagram, extract standard capability contract objects that are in the orchestration-ready state. Perform input / output structure matching based on the pattern field, compatibility matching based on the streaming field, and budget feasibility matching based on the resource field on the extracted standard capability contract objects to generate data flow compatibility relationships and execution feasibility relationships, and form an orchestration-ready capability relationship set. Based on the orchestration-ready capability relationship set and runtime capability state diagram, it provides an interface for summarizing the capability catalog and an interface for subscribing to incremental events.

[0043] Example 3: This application also provides an electronic device. The electronic device may include one or more processors and one or more memories. The memories store computer-readable code, which, when executed by the one or more processors, can perform an AI workflow pluggable capability contract management method as described above.

[0044] The method or system according to the embodiments of this application can also be implemented using the architecture of the electronic device shown in this application. The electronic device may include a bus, one or more CPUs, ROM, RAM, a communication port connected to a network, input / output, a hard disk, etc. The storage device in the electronic device, such as ROM or hard disk, may store the AI ​​workflow pluggable capability contract management method provided in this application. Furthermore, the electronic device may also include a user interface. Of course, the architecture shown in this application is merely exemplary; when implementing different devices, one or more components in the electronic device shown in this application may be omitted according to actual needs.

[0045] Example 4: One embodiment of this application discloses a computer-readable storage medium. The computer-readable storage medium stores computer-readable instructions. When the computer-readable instructions are executed by a processor, an AI workflow pluggable capability contract management method according to an embodiment of this application, as described with reference to the above figures, can be executed. The storage medium includes, but is not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc.

[0046] Furthermore, according to embodiments of this application, the processes described in the above-referenced flowcharts can be implemented as computer software programs. For example, this application provides a non-transitory machine-readable storage medium storing machine-readable instructions that can be executed by a processor to perform instructions corresponding to the method steps provided in this application, such as an AI workflow pluggable capability contract management method. When this computer program is executed by a central processing unit (CPU), it performs the functions defined in the method of this application.

[0047] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0048] All formulas in this manual are dimensionless and calculated numerically. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0049] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the invention.

Claims

1. A method for managing AI workflow plug-in capability contracts, characterized in that, include: After each business module completes its own initialization, it receives the original description information of the capabilities pushed by each business module, including capability identifier field, belonging module field, category field, associated skill field, calling field, mode field, streaming field, resource field and initial state field; Based on the original capability description information, namespace regularization and contract standardization encapsulation are performed to generate standard capability contract objects. Based on the capability identifier field and the belonging module field, a primary index and a module auxiliary index are established to form a capability contract index set. Based on the capability contract index set, the system receives lifecycle events generated by the module registry center and dynamic resource status events reported by each business module. It maps lifecycle events and dynamic resource status events to runtime state changes of corresponding standard capability contract objects, and performs state updates and batch cascaded deregistration by module to form a runtime capability state diagram. Based on the runtime capability state diagram, extract standard capability contract objects that are in the orchestration-ready state. Perform input / output structure matching based on the pattern field, compatibility matching based on the streaming field, and budget feasibility matching based on the resource field on the extracted standard capability contract objects to generate data flow compatibility relationships and execution feasibility relationships, and form an orchestration-ready capability relationship set. Based on the orchestration-ready capability relationship set and runtime capability state diagram, it provides an interface for summarizing the capability catalog and an interface for subscribing to incremental events.

2. The method according to claim 1, characterized in that, Methods for performing namespace regularization and contract standardization encapsulation include: Perform category enumeration value validation on the category field and determine whether to write it to the category subfield; perform format compliance validation and call enumeration value validation on the call field and determine whether to write it to the call endpoint subfield and call method subfield respectively; perform JSON Schema compliance validation on the pattern field and determine whether to write it to the input pattern subfield and output pattern subfield respectively. Perform boolean type compliance checks on streaming fields and determine whether to write to streaming support subfields; perform non-negative integer compliance checks on resource fields and determine whether to write to memory consumption estimation subfields and GPU memory consumption estimation subfields respectively; perform state enumeration value checks on initial state fields and determine whether to write to runtime state subfields. Define a three-part namespace, perform namespace normalization on the capability identifier field and the belonging module field to form a normalized globally unique capability identifier; assemble the normalized globally unique capability identifier with each subfield to form a complete standard capability contract object.

3. The method according to claim 2, characterized in that, Methods for forming a capability contract index set include: A primary index and module auxiliary indexes are established and used together as the capability contract index set. The primary index uses a globally unique capability identifier as the key and the corresponding standard capability contract object as the value. The module auxiliary index uses the belonging module field as the key and the list of capability identifiers corresponding to the belonging module field as the value. The capability identifier list is a list of all globally unique capability identifiers corresponding to the belonging module field. After each standard capability contract object is received, the primary index is updated based on the globally unique capability identifier formed by the capability identifier field and the belonging module field, and the module auxiliary index is updated based on the belonging module field.

4. The method according to claim 3, characterized in that, Methods for mapping runtime state changes include: Two independent lifecycle event channels and dynamic resource status event channels are established, and lifecycle events and dynamic resource status events are received respectively. The lifecycle event includes the module to which it belongs and the event type identifier. Based on the event type identifier, it is determined whether to map the lifecycle event to a batch cascading deregistration change. If so, the batch cascading deregistration execution process by module is initiated. The dynamic resource status event is mapped to a single capability status update change and the status update execution process is initiated.

5. The method according to claim 4, characterized in that, Methods for generating runtime capability state diagrams include: The runtime state subfield corresponding to the standard capability contract object is marked as the runtime state value. Based on the globally unique capability identifier and the runtime state value, a runtime capability state graph is constructed. The runtime capability state graph is a hash mapping structure with the globally unique capability identifier as the key and the runtime state value of the corresponding standard capability contract object as the value, and it is a dynamic structure.

6. The method according to claim 5, characterized in that, Methods for performing input / output structure matching based on pattern fields include: All standard capability contract objects in a programmable state are aggregated to form a set of programmable capability contract objects, and all ordered capability pairs are enumerated from it. For each ordered capability pair, field name existence verification and field type compatibility verification are performed based on the input pattern subfield and the output pattern subfield. Based on the verification results, it is determined whether there is a data flow compatibility relationship. For ordered capability pairs with data flow compatibility relationships, a data flow compatibility relationship entry and field name mapping list are recorded.

7. The method according to claim 6, characterized in that, Methods for performing compatible matching based on streaming fields include: For each data flow compatibility relationship entry, based on the streaming support subfield of each standard capability contract object in the corresponding ordered capability pair, determine whether the corresponding ordered capability pair meets the streaming compatibility conditions; based on the determination result, mark the streaming compatibility status of each group of ordered capability pairs, and add the streaming compatibility status to the corresponding data flow compatibility relationship entry.

8. The method according to claim 7, characterized in that, Methods for performing budget feasibility matching based on resource fields include: Obtain the total available memory and total available GPU memory, and calculate the effective memory limit and effective GPU memory limit based on the preset resource safety margin ratio; perform a full resource aggregation for the set of programmable capability contract objects to obtain the estimated memory consumption and GPU memory consumption of the entire workflow, and compare them with the effective memory limit and effective GPU memory limit respectively, and generate executable relationship entries based on the comparison results.

9. The method according to claim 8, characterized in that, The methods for providing the capability catalog aggregation interface and incremental event subscription interface to external parties include: The capability catalog aggregation interface is exposed externally in the form of a REST API to receive capability catalog query requests. After receiving a capability catalog query request, it determines whether the capability catalog query request contains category filtering parameters, and forms a set of capability objects to be aggregated based on the determination result. For the set of capability objects to be aggregated, it performs information aggregation and response data organization processes to obtain structured response data. After serializing the structured response data in JSON format, it is returned to the querying party through the capability catalog aggregation interface. The incremental event subscription interface is exposed to the outside world in the form of a WebSocket long connection. During system operation, it continuously receives capability registration events, capability status change events, and capability batch deregistration events, and performs corresponding broadcast operations through the incremental event subscription interface.

10. An AI workflow plug-in capability contract management system, implementing the method according to any one of claims 1-9, characterized in that, include: The capability access module is used to receive the original capability description information pushed by each business module after each business module has completed its own initialization. This includes capability identifier field, belonging module field, category field, associated skill field, call field, mode field, streaming field, resource field, and initial status field. The contract standardization module is used to perform namespace standardization and contract standardization encapsulation based on the original capability description information, generate standard capability contract objects, and establish a primary index and a module auxiliary index based on the capability identifier field and the belonging module field to form a capability contract index set. The status linkage module is used to receive lifecycle events generated by the module registry center and dynamic resource status events reported by each business module according to the capability contract index set, map the lifecycle events and dynamic resource status events to the runtime status changes of the corresponding standard capability contract objects, and perform status updates and batch cascaded deregistration by module to form a runtime capability status diagram. The orchestration matching module is used to extract standard capability contract objects in the orchestrable state based on the runtime capability state diagram, perform input-output structure matching based on the pattern field, compatibility matching based on the streaming field, and budget feasibility matching based on the resource field on the extracted standard capability contract objects, generate data flow compatibility relationships and execution feasibility relationships, and form an orchestration-ready capability relationship set. The catalog service module is used to provide an interface for summarizing the capability catalog and an interface for subscribing to incremental events, based on the orchestration-ready capability relationship set and the runtime capability state diagram.

Images