System and method based on dynamic registration and management of heterogeneous AI function interface

Abstract

The invention relates to the technical field of software frameworks, and provides a system and a method based on dynamic registration and management of a heterogeneous AI function interface, the system comprises a core layer which comprises a characteristic registry and a characteristic manager, the characteristic manager is used for obtaining a characteristic definition list available in a current environment through a preset mechanism, registering the characteristic definitions in the characteristic definition list into a characteristic manager; the message rendering subsystem comprises a core message renderer, a message component registry and a message component; and the input area subsystem comprises a plug-in manager, an input area core component, an input plug-in registry, an input plug-in and a plug-in context module. According to the method, the integration process is greatly simplified, the iteration period is accelerated, the maintenance difficulty and risk are effectively reduced, changes can be flexibly adapted without redeployment, the components and the plug-ins are efficiently multiplexed and support independent evolution through standardized interfaces and registration mechanisms, and the expandability and maintainability of the system are further improved.

Description

Technical Field

[0001] The present application relates to the field of software framework technology, and specifically to a system and method based on dynamic registration and management of heterogeneous AI functional interfaces. Background Art

[0002] In existing technologies, integrating or building applications that incorporate multiple AI capabilities into software systems presents the challenge of managing this diversity. For example, an AI assistant might need to simultaneously provide multiple functions, including text question answering, copywriting generation, image generation, internal knowledge querying, business data analysis, and specific task execution.

[0003] These functions exhibit significant heterogeneity in the user interaction interface: the input method may evolve from a simple text box to one with specific options, complex forms, or even the need to call external processes; the AI's response content may also expand from plain text and Markdown to interactive buttons, data cards, images, or components that require special rendering.

[0004] Currently, a common implementation method is to hard-code each function, writing the interface rendering logic, interaction processing logic, and back-end communication logic of a specific function directly into the front-end code. This method has the following significant drawbacks: Inefficient development and iteration: Adding or modifying AI features, especially complex features with unique interaction methods, requires extensive modification, testing, and redeployment of core code, resulting in long development cycles and difficulty in quickly responding to business needs.

[0005] High maintenance cost and prone to errors: The logic of different functions is tightly coupled or intertwined through complex conditional judgments, resulting in a complex code base that is difficult to understand and maintain, and it is very easy to introduce regression errors when making modifications.

[0006] Poor flexibility and dynamism: It is difficult to flexibly control the user-visible feature set and its interface performance in real time based on user permissions, background configuration, or other runtime conditions, such as dynamically enabling / disabling an input assist plug-in.

[0007] High coupling and code redundancy: There is a high degree of coupling between various system layers (UI display, interaction logic, state management, back-end communication) and between different functional modules, and a lack of unified abstraction leads to poor reusability and code redundancy. Summary of the Invention

[0008] In order to help solve the above technical problems, the present application provides a system and method based on dynamic registration and management of heterogeneous AI functional interfaces.

[0009] In a first aspect, the present application provides a system based on dynamic registration and management of heterogeneous AI functional interfaces, which adopts the following technical solutions: A system based on dynamic registration and management of heterogeneous AI functional interfaces, wherein the system includes: The core layer includes a feature registry and a feature manager. The feature manager is used to obtain a feature definition list available in the current environment through a preset mechanism and register the feature definitions in the feature definition list with the feature manager. The message rendering subsystem includes a core message renderer, a message component registry, and a message component. The core message renderer is used to search and load the corresponding message component from the message component registry according to the component type field in the message data, and render the message content on the interface. The message component registry is used to manage the message components, and the message components are used to register through the component type field. The input area subsystem includes a plug-in manager, an input area core component, an input plug-in registry, input plug-ins, and a plug-in context module. The input area plug-in manager is used to load, instantiate, and manage the life cycle of input plug-ins based on the configuration of the currently activated features. The input area core component is used to integrate the user interface rendered by the input plug-in. The input plug-in registry is used to manage the input plug-ins. The plug-in context module is used to provide a standardized API interface for the input plug-in.

[0010] Preferably, the system further includes a feature definition module and a configuration service module. The feature definition module is used to transmit feature definitions to the core layer. The feature manager loads feature definitions that are available in the current environment or that the user has permission to access through the configuration service module.

[0011] Preferably, the feature definition includes a feature identifier, metadata, permission logic, and a list of interface component identifiers and input plug-in identifiers required for its operation.

[0012] Preferably, the preset mechanism includes reading a local configuration file, scanning a specific code directory and loading it through a dynamic input function, and requesting a remote configuration service.

[0013] In a second aspect, the present application provides a method for dynamically registering and managing heterogeneous AI function interfaces, which adopts the following technical solutions: A method using the system based on dynamic registration and management of heterogeneous AI functional interfaces as described in any one of the first aspects, wherein the method includes a system initialization and feature loading sub-method, a dynamic message rendering sub-method, and a plug-in input area management sub-method, wherein the system initialization and feature loading sub-method includes: A1, application startup: the core layer first performs initialization operations, including initializing the feature manager and feature registry; A2, loading mode: the core layer scans or imports the feature definition module from a local file, or the core layer sends a request to the configuration service module to obtain a feature definition list; A3, Local Discovery Process: If the local discovery process is selected, the core layer scans a preset directory to find all the feature definition modules, or dynamically imports the configured feature definition modules. For each feature definition module found, the core layer registers the feature definition of the feature definition module in the feature registry; A4, remote configuration process: If the remote configuration process is selected, the core layer sends a request to the remote configuration service and obtains a list of features available in the current environment or a complete feature definition based on the configuration service module; A5, execute registerFeature() to the registry: the core layer registers the feature definition obtained from the configuration service module into the feature registry, the message rendering subsystem registers the message component into the message component registry, and the input area subsystem registers the input plug-in into the input plug-in registry; A6, Feature Manager Reads Registry: The Feature Manager reads the definitions of all registered features from the feature registry; A7, application permission filtering: the core layer performs application permission filtering on the read feature definition; A8, Generate Available Feature List: Based on the filtered feature definitions, the core layer generates an available feature list, which contains information about all features that the user is authorized to access and use; A9, UI layer displays available features: the core layer displays the generated available feature list on the UI layer of the application; A10, End: The core layer waits for the next feature switch or interactive operation by the user to start a new workflow.

[0014] Preferably, the dynamic message rendering sub-method includes: B1, receiving message data: receiving, through the message rendering subsystem, the message data including the component type field transmitted by the feature manager; B2, the core message renderer obtains the message data of the component type field: the core message renderer extracts the component type field from the received message data; B3, querying the message component registry: querying the message component registry through the core message renderer to find the registration information corresponding to the extracted component type field; B4, determine whether the registration information is found: If the registration information corresponding to the component type field is found in the message component registry, the process will continue to execute. If not, the error handling process will be executed, which includes logging, rendering the default component, or prompting an error message; B5, asynchronously loading component code: asynchronously loading the corresponding message component code through the core message renderer according to the registration information found in the message component registry; B6, execute mapToProps to convert data: the core message renderer calls the message content mapping function to convert the JSON string in the message content into the properties required by the component. The properties contain all the data required for component rendering; B7, obtaining a standard interaction processor: obtaining a standard interaction processor through the core message renderer, the interaction processor being used to process interaction events within the message component, and the core message renderer passing the interaction processor to decouple the interaction between the message component and the message rendering subsystem; B8, rendering component: using the converted attributes and the interaction processor to render the message component through the core message renderer to generate a message interface element visible to the user; B9, Component Interaction Process: The rendered message component contains interactive elements. When the user interacts with the interactive elements, the message component calls the corresponding interaction method on the passed-in interaction processor, thereby triggering the interaction logic defined by the application; B10, End: When the message component is successfully rendered and the user completes the interaction with the message component or no interaction occurs, the dynamic message rendering process ends, and the message rendering subsystem waits to receive the next message data to start a new dynamic message rendering sub-method process.

[0015] Preferably, the plug-in input area management sub-method includes: C1, user switching characteristics: the user selects to switch user characteristics through the user interface module in the application layer; C2, obtaining feature definition: receiving a user request to switch features through the feature manager, retrieving the feature definition of the new feature from the feature registry, the feature definition including a list of input plug-ins that need to be activated for the feature, C3, notifying the plug-in manager: notifying the plug-in manager of the list of input plug-ins that need to be activated through the property manager; C4, querying the plug-in registry: querying the plug-in registry through the plug-in manager according to the received input plug-in list to obtain the definition and loading information of each plug-in; C5, asynchronously loading the plug-in code: if the plug-in code has not been loaded into the memory, asynchronously loading the corresponding plug-in code through the plug-in manager; C6, instantiate plug-in: instantiate the plug-in object through the plug-in manager, call the corresponding onLoad method, and pass in the plug-in context module containing the API; C7, Get UI: Call the plug-in's UI generation method through the plug-in manager to request the plug-in to generate UI elements. The plug-in returns the UI elements through the UI generation method so as to be rendered in the input area. C8, Rendering the plug-in UI to a slot: Rendering the UI elements generated by the plug-in to a predefined slot through the input area core component. The slot is a location in the input area reserved for displaying the plug-in UI. The plug-in UI elements are displayed to the user through the slot for user interaction; C9, user interaction with plug-in UI: the user interacts with the plug-in UI elements rendered in the input area; C10, plug-in processing interaction: the plug-in responds to user interaction operations through internally defined interaction logic; C11, the input area core notifies the plug-in manager: during the user interaction process, the input area core component notifies the plug-in manager of events related to the user interaction; C12, the plugin manager calls the plugin: When the input content changes, the plugin manager calls the plugin's onInputChange(text, context) method to respond to the change in the input content; C13, user clicks send: After the user completes the input, he clicks the send button to trigger the operation of sending the request; C14, the input area core prepares an initial payload: The input area core component prepares an initial send payload, which includes at least the content input by the user and the data temporarily stored by the plug-in; C15, the plug-in manager calls the plug-in beforeSend method to modify the payload: the plug-in manager calls the beforeSend method of all currently activated plug-ins in a predetermined order. The plug-in reads the information stored internally or in the plug-in context module through the beforeSend method and merges it into the send payload as the final send payload; C16, the input area core sends the final payload through onSend: After receiving the final send payload returned by the plug-in manager, the input area core component sends the final send payload to the backend communication layer for processing; C17, the input area plug-in workflow ends: the input area subsystem waits for the user's next interaction or feature switching to start a new input area management sub-method process.

[0016] In summary, this application has the following advantages: Improve development and iteration efficiency: New feature development is carried out in the form of cohesive modules (feature definitions, components, plug-ins), which can be accessed through registration, greatly simplifying integration work and accelerating iteration.

[0017] Reduce maintenance costs: Clear architectural layering and low-coupling design make the code easier to understand, modify, and test, reducing maintenance difficulty and risks.

[0018] Enhanced flexibility and dynamism: enabling / disabling functions, adding / removing interface elements (via plug-ins), and even adjusting some interaction processes can be dynamically implemented based on configuration (possibly from remote sources) without the need for redeployment.

[0019] Reduce coupling and improve reusability: Standardized interfaces and registration mechanisms make components and plug-ins easy to reuse and evolve independently. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 This is a schematic block diagram of an embodiment of a system based on dynamic registration and management of heterogeneous AI function interfaces of the present application; Figure 2 This is a flowchart of an embodiment of the system initialization and feature loading sub-method of the present application; Figure 3 This is a flowchart of an embodiment of the dynamic message rendering sub-method of the present application; Figure 4 This is a flowchart of an embodiment of the plug-in input area management sub-method of the present application. DETAILED DESCRIPTION

[0021] The present invention will be further described below with reference to the accompanying drawings. The structure and principle of the present invention will be very clear to those skilled in the art. It should be understood that the specific embodiments described herein are only intended to explain the present invention and are not intended to limit the present invention.

[0022] The English nouns in this article include: Feature Manager: Responsible for dynamically loading feature definitions available in the current environment or accessible to the user during application startup or runtime, and registering them in the feature registry. It also maintains a list of available features and, when the user switches features, drives other subsystems (such as the message rendering layer and input area management layer) to load corresponding configurations for adaptation.

[0023] FeatureRegistry: Serves as a unified management center for all features (or "scenarios"). Each feature is described by its FeatureDefinition, which includes key information such as the feature identifier, metadata (such as name and icon), permission logic, and the interface component identifiers and input plugin identifier list required for the feature to run.

[0024] Message Rendering Layer: This layer searches for and loads the corresponding message display component from the message component registry based on the widgetType field in the message data, and is responsible for rendering the message content on the interface.

[0025] MessageWidgetRegistry: A message component registry. Responsible for managing different types of message display components. These message components are dynamically registered using the widgetType identifier (for example, by the feature module they belong to when loading) and support asynchronous loading, thereby improving system startup speed and operational efficiency.

[0026] Input Area Management Layer: This layer includes the InputAreaCore component, the InputPluginRegistry, the PluginManager, and the PluginContext module.

[0027] InputAreaCore: The core component of the input area. As the core component of the input area, it is responsible for integrating the user interface (UI) rendered by input plugins and displaying it in the application's input area. The Input Area Core component provides users with a unified input entry point and supports multiple input methods and plugin extensions.

[0028] InputPluginRegistry: The input plugin registry. Responsible for managing all available input plugins. These plugins are dynamically registered using pluginId and provide rich input functionality extensions for input areas.

[0029] PluginManager: The plugin manager. Based on the currently active feature configuration, it is responsible for loading, instantiating, and managing the lifecycle of input plugins (for example, calling plugin onLoad, beforeSend, and other methods). It ensures that input plugins run correctly according to the feature definition and interact with the core input area components.

[0030] PluginContext: Plugin context module. Provides standardized API interfaces (such as setInputText and setSendPayloadValue) for input plugins, enabling plugins to interact with the core components of the input area and the data sending process.

[0031] widgetType: Component type field. A key field in the message data that determines which type of message display component to render next.

[0032] MessageRenderer: The core message renderer. It extracts the widgetType from the received message data, queries the message component registry to find the corresponding registration information, and uses the converted properties and interaction handlers to render the message display component.

[0033] mapMessageContentToProps: Message content mapping function. Converts the JSON string in the message content into the properties (props) required by the component. These properties contain all the data required for component rendering.

[0034] Handlers: Interaction handlers. Contains a series of methods used to handle interaction events within the message display component, such as button clicks, link jumps, etc.

[0035] featureId: Feature identifier. Used to uniquely identify a feature. When users switch between different features through the application interface, they pass featureId to indicate the target feature.

[0036] inputPluginIds: A list of input plugin identifiers. A list included in the feature definition specifies the input plugins that need to be activated for this feature.

[0037] onLoad(context): Plugin loading method. After the plugin manager instantiates the plugin object, it calls this method and passes in the plugin context to initialize the plugin and provide the ability to interact with other parts of the system.

[0038] renderSlot(): Plugin rendering method. The plugin manager calls this method to ask the plugin to generate its UI elements so that they can be rendered in the input area.

[0039] setPluginState: Sets the plugin state method. The plugin updates its internal state or communicates with the input area core component through this method.

[0040] setSendPayloadValue: Sets the send payload value method. The plug-in uses this method to temporarily store the user-entered data, which will be attached to the send request when the user clicks the send button.

[0041] onInputChange(text, context): This method handles input content changes. When the input content changes, the plugin manager calls this method to respond to the change, allowing the plugin to process user input in real time.

[0042] beforeSend(payload, context): Pre-send processing method. The plugin manager calls this method before sending a request, allowing the plugin to modify the send payload.

[0043] onSend: Send callback method. The input area core component uses this method to send the final send payload to the upper-layer application logic.

[0044] ImageResultWidget: Image result display component. A message display component used to render message content containing images, such as AI-generated image results.

[0045] onTriggerAction: Trigger action method. When an interactive element (such as a download button) in a message display component is clicked, this method is called to trigger the interaction logic defined by the application.

[0046] Figure 1 This is a schematic block diagram of an embodiment of a system for dynamically registering and managing heterogeneous AI functional interfaces. The system includes a core layer, a message rendering subsystem, an input area subsystem, a feature definition module, a configuration service module, and a backend communication layer.

[0047] Specifically, the Feature Manager is responsible for dynamically loading feature definitions that are available in the current environment or that the user has access permissions to, and registering them in the feature registry during application startup or runtime. It also maintains a list of available features and, when the user switches features, drives other subsystems (such as the message rendering layer and input area management layer) to load the corresponding configuration for adaptation.

[0048] The Feature Registry serves as a unified management center, responsible for managing all functional features (or "scenarios"). Each feature is described by its Feature Definition, which includes key information such as the feature identifier, metadata (such as name and icon), permission logic, and the interface component identifiers and input plug-in identifier list required for the feature to run.

[0049] The Message Rendering Layer searches and loads the corresponding message display component from the message component registry based on the widgetType field in the message data, rendering the message content on the interface. By passing standardized interaction handler interfaces (MessageInteractionHandlers) to the rendered message components, it decouples the interaction logic within the message components from the core application logic, improving system flexibility and maintainability.

[0050] The MessageWidgetRegistry manages different types of message display components. These components are dynamically registered using the widgetType identifier (for example, when the feature module to which they belong is loaded) and support asynchronous loading, thereby improving system startup speed and operating efficiency.

[0051] The Input Area Management Layer includes: The InputAreaCore component, the core component of the input area, integrates the user interface (UI) rendered by input plugins and displays it in the application's input area. The InputAreaCore component provides a unified input entry point and supports multiple input methods and plugin extensions.

[0052] The InputPluginRegistry manages all available input plugins. These plugins are dynamically registered using pluginId and provide rich input functionality extensions for input areas.

[0053] The Input Zone Plugin Manager (PluginManager) is responsible for loading, instantiating, and managing the lifecycle of input plugins (for example, calling their onLoad and beforeSend methods) based on the currently active feature configuration. It ensures that input plugins run correctly according to the feature definition and interact with the core Input Zone components.

[0054] The PluginContext module provides standardized APIs (such as setInputText and setSendPayloadValue) for input plugins, enabling them to interact with the core input area components and the data sending process. Through the plugin context, input plugins can easily retrieve and set information such as input text and sent payload values, achieving seamless integration between plugins and core system functionality.

[0055] Figure 2 This is a flow chart of an embodiment of the system initialization and feature loading sub-method of the present application. Figure 2 It can be understood that the method includes the following contents.

[0056] When an application starts, the system first performs initialization operations, which include initializing the feature manager and feature registry. The feature manager is responsible for subsequent feature loading and registration, while the feature registry is a central repository for all registered feature definitions.

[0057] The system then needs to determine how to load the feature definitions. This is generally done in two ways: local discovery and remote configuration.

[0058] Local discovery: The system scans or dynamically imports feature modules directly from the local file system. This method is suitable for scenarios where feature definitions are pre-deployed on the device.

[0059] Remote configuration: The system sends a request to the remote configuration service to obtain the latest feature list or definition. This approach allows feature definitions to be remotely managed and dynamically updated, increasing system flexibility.

[0060] Scan or dynamically import feature modules: If you select the local discovery method, the system scans the preset directory to find all feature modules, or dynamically imports configured feature modules.

[0061] Execute registerFeature() to the registry: For each feature module found, the system calls the registerFeature() function to register its feature definition in the feature registry. The feature definition contains information such as feature metadata, permission logic, required components and plug-ins, etc.

[0062] Remote configuration process: Request the configuration service to obtain the feature list / definition: If the remote configuration method is selected, the system will send a request to the remote configuration service to obtain the feature list or complete feature definition available in the current environment.

[0063] Optional on-demand definition loading: Based on the information returned by the remote configuration service, the system can choose to load feature definitions on demand, that is, the complete definition of a feature is loaded only when needed, to reduce system startup time and memory usage.

[0064] Execute registerFeature() to the registry: Similar to the local discovery method, the system registers the feature definition obtained from the remote configuration service into the feature registry.

[0065] The Feature Manager reads the registry: The Feature Manager reads the definitions of all registered features from the feature registry. These definitions contain information about all features supported by the system and are the basis for subsequent system operation.

[0066] Application permission filtering: The system applies application permission filtering to the feature definitions it reads. This step ensures that users can only access and use features for which they have permission, improving system security.

[0067] Generate an available feature list: Based on the filtered feature definitions, the system generates an available feature list. This list contains information about all features that the user has the right to access and use, and serves as the basis for the user to select functional features.

[0068] Displaying available features on the UI layer: The system displays the generated list of available features on the application's UI layer, allowing users to intuitively see and select the features they need. Users can interact with the list of available features by clicking or touching, selecting and switching to different features.

[0069] End: The dynamic registration and loading process for feature modules has concluded. The system has been initialized and is ready to dynamically load and display different features based on user selections. The system awaits the next feature switch or interaction from the user to begin a new workflow.

[0070] Figure 3 This is a flow chart of an embodiment of the dynamic message rendering sub-method of this application. Figure 3 It can be understood that the method may include the following contents.

[0071] Start: Receiving message data. The dynamic message rendering process begins when the system receives message data containing a widgetType. This widgetType (component type field) is key information, determining which type of message display component to render next.

[0072] The core message renderer obtains the widgetType: The core message renderer (MessageRenderer) extracts the widgetType from the received message data. This step is key to dynamic message rendering because the widgetType directly points to the specific component to be rendered.

[0073] Query the Message Widget Registry: The core message renderer queries the MessageWidgetRegistry to find the registration information corresponding to the extracted widgetType. The Message Widget Registry is a centralized management place for all available message display components. It stores the component type, loading method, and mapping relationship with the message content.

[0074] Determine whether the registration information is found: If the registration information corresponding to the widgetType is found in the message component registry, the process will continue to execute; if not found, the error handling process may be executed, such as recording logs, rendering default components, or prompting error messages.

[0075] Asynchronously load component code (this step is optional): Based on the registration information found in the message component registry, the core message renderer may asynchronously load the corresponding message display component code. This step is optional because some components may already be pre-loaded into memory, while others may need to be loaded dynamically when needed to reduce system startup time and memory usage.

[0076] Execute mapToProps to convert data: The core message renderer calls the message content mapping function (such as mapMessageContentToProps) to convert the JSON string in the message content into the properties (props) required by the component. These properties contain all the data required for component rendering, such as text content, image URLs, button configurations, etc.

[0077] Obtaining Standard Interaction Handlers: The core message renderer obtains standard interaction handlers from the upper-level application logic. These handlers contain a series of methods for handling interaction events within the message display component, such as button clicks and link jumps. By passing these handlers, the core message renderer decouples interactions between the message display component and the core application logic.

[0078] Rendering components: The core message renderer uses the converted props and interaction handlers to render the message display component. This step combines the component code, data, and interaction logic to ultimately generate the message interface elements visible to the user.

[0079] Component Interaction Process: A rendered message display component may contain various interactive elements, such as buttons, input fields, and links. When a user interacts with these elements (for example, by clicking a button), the component calls the corresponding method on the passed interaction handler, triggering the application-defined interaction logic. This design allows the message display component to focus on interface presentation, while leaving complex business logic to the upper-layer application.

[0080] Execute error handling: If any errors occur during component loading, data parsing, rendering, or interaction (such as component loading failure, data parsing errors, rendering anomalies, etc.), the system will execute the corresponding error handling process. This may include recording error logs, rolling back operations, and prompting users with error information to ensure system stability and reliability.

[0081] End: When the message display component renders successfully and the user completes the interaction with the component (or no interaction occurs), the dynamic message rendering process ends. The system waits for the next message data to start a new rendering process.

[0082] Figure 4 This is a flow chart of an embodiment of the plug-in input area management sub-method of this application. Figure 4 It can be understood that the method may include the following contents.

[0083] Start: User Switching Features (featureId): The user switches to a different feature (featureId) through the application interface. This action is the starting point of the input area plug-in workflow, triggering the system to load and configure the corresponding input plug-in based on the new feature.

[0084] Feature Manager Operation: Get Feature Definition: After receiving a request to toggle a feature, the Feature Manager retrieves the complete definition of the new feature from the Feature Registry. The feature definition includes the list of input plugins (inputPluginIds) that need to be activated for the feature.

[0085] Notify the Plugin Manager: The Feature Manager notifies the Plugin Manager (PluginManager) of the list of input plugins that need to be activated, triggering the plugin loading and instantiation process.

[0086] Plugin manager operation: Query the plugin registry: The plugin manager queries the plugin registry (InputPluginRegistry) based on the received input plugin list to obtain the definition and loading information of each plugin.

[0087] Asynchronously load the plugin code (this step is optional): If the plugin code has not yet been loaded into memory, the plugin manager may asynchronously load the corresponding plugin code. This step ensures that the plugin can be dynamically loaded when needed.

[0088] Instantiate the plugin and call onLoad(context): The plugin manager instantiates the plugin object and calls its onLoad(context) method, passing in the plugin context object containing various APIs. This step initializes the plugin and provides it with the ability to interact with the input area core components and the data sending process.

[0089] Call the plugin renderSlot() method to get the UI: The plugin manager calls the plugin's renderSlot() method to ask the plugin to generate its UI elements. The plugin returns its UI elements through this method so that it can be rendered in the input area.

[0090] Input area core components: Rendering plugin UI to slots: The InputAreaCore component is responsible for rendering plugin-generated UI elements into predefined slots. These slots are reserved locations within the input area for displaying plugin UI. Through this step, the plugin's UI elements are presented to the user, allowing them to interact with them.

[0091] User interaction process: User interaction with the plug-in UI: Users interact with the plug-in UI elements rendered in the input area, such as entering text, selecting options, clicking buttons, etc.

[0092] Plugins handle interactions: Plugins respond to user interactions through their internally defined interaction logic. Plugins may update their internal state or communicate with the input area core component through APIs provided by the plugin context (such as setPluginState).

[0093] The input area core notifies the plug-in manager: During the user interaction process, the input area core component may notify the plug-in manager of user interaction events as needed, so that the plug-in manager can coordinate the interaction between multiple plug-ins.

[0094] Plugin temporary data storage: Plugins may temporarily store user input data through the API provided by the plugin context (such as setSendPayloadValue). This data will be attached to the send request when the user clicks the send button.

[0095] The plugin manager calls the plugin's onInputChange(text, context): When the input content changes (for example, the user enters new text), the plugin manager may call the plugin's onInputChange(text, context) method to respond to the change in input content. This allows the plugin to process user input in real time and update its UI or internal state.

[0096] Sending process: User clicks Send: After the user completes the input, he clicks the Send button to trigger the operation of sending the request.

[0097] Input area core prepares initial payload: The input area core component prepares the initial payload to be sent. This payload includes the user input content, plug-in temporary data, and other related information.

[0098] The plugin manager calls the plugin's beforeSend(payload, context) method to modify the payload: The plugin manager calls the beforeSend(payload, context) method of all currently active plugins in a predetermined order. In this method, plugins can read information stored internally or through the plugin context and merge it into the sent payload, thereby modifying the final content.

[0099] The input area core sends the final payload through onSend: After receiving the final send payload returned by the plugin manager, the input area core component sends the payload to the upper-layer application logic through its onSend callback. The upper-layer application logic then sends the payload to the backend service for processing, completing the entire sending process.

[0100] End: The input area plug-in workflow ends. The system waits for the next user interaction or feature switch to start a new workflow.

[0101] In order to more clearly illustrate the technical solution of the present invention, a specific user usage scenario is described below as an embodiment with reference to the accompanying drawings.

[0102] Scenario: In the embedded AI assistant, the user first uses the "General Conversation" function, then switches to the "AI Image Generator" function, enters a description, selects a style, and generates an image.

[0103] Steps: System initialization and feature loading (see attached Figure 2 ): When the application starts, the core feature management module (FeatureManager) is initialized.

[0104] The FeatureManager obtains a list of feature definitions available in the current environment through a predefined mechanism (for example, reading a local configuration file, scanning a specific code directory and loading it through dynamic import(), or requesting a remote configuration service). For example, the list includes "General Dialog" (featureId: 'general') and "AI Image Generator" (featureId: 'imageGen').

[0105] For each acquired feature definition, FeatureManager calls the registerFeature function to register the feature definition (including metadata, permission logic, required inputPluginIds such as ['imageStyleSelector'], extraMessageRendererId, beModule flag, etc.) in the feature registry (FeatureRegistry).

[0106] During or before this process, each functional module (or the module responsible for managing them) has also registered the message rendering components (such as TextWidget, ImageResultWidget) and input plug-ins (such as ImageStyleSelectorPlugin) it provides in the corresponding message component registry and input plug-in registry through their respective registration functions registerMessageWidget and registerInputPlugin.

[0107] User selection and feature switching: The application interface displays optional function entrances (for example, an Action Bar at the bottom or a welcome interface) to the user based on the list of available features obtained from the FeatureManager and filtered by permissions. Initially, the user may be in the "general" feature.

[0108] Users can choose to switch to the imageGen feature by clicking the "AI Image Generator" icon or button on the interface.

[0109] The interface notifies the FeatureManager of the user's selection (featureId: 'imageGen').

[0110] Feature toggle processing (coordinated by FeatureManager): The FeatureManager receives the switch request and records the currently active feature as imageGen.

[0111] It retrieves the complete FeatureDefinition of imageGen from the FeatureRegistry.

[0112] Based on this definition, FeatureManager drives other subsystems to update and adapt their status: Notify the input area subsystem (see attached Figure 4 ): FeatureManager passes configuration information such as inputPluginIds (such as ['imageStyleSelector']), inputPlaceholder ("Describe the picture you imagine...") and possible customFooterComponentId (if defined) specified in the imageGen definition to the input area plug-in manager (PluginManager).

[0113] Configure the backend communication layer: (If necessary) Instruct the backend communication layer that subsequent requests should use the beModule flag or other specific parameters corresponding to imageGen.

[0114] (Possibly) notify the message rendering subsystem: if a feature toggle needs to affect some general behavior of the message list (though primarily driven by widgetType).

[0115] Dynamic adaptation of input area (see attached Figure 4 ): The PluginManager receives a command to activate the ['imageStyleSelector'].

[0116] It queries the input plugin registry and finds the plugin definition (including loader, lifecycle methods, etc.) corresponding to imageStyleSelector.

[0117] The PluginManager (possibly asynchronously) loads the plugin's code.

[0118] Instantiate ImageStyleSelectorPlugin and call its onLoad(context) method, passing in the PluginContext object that contains various APIs.

[0119] The PluginManager calls the renderSlot('bottom') method of the plugin instance (assuming the plugin defines rendering the UI in the bottom slot).

[0120] The InputAreaCore component gets the React node returned by the plugin (such as a set of style selection buttons) and renders it into the predefined "bottom slot" area.

[0121] At the same time, InputAreaCore updates the placeholder of its internal TextArea component to the "Describe the picture you imagine..." received from FeatureManager.

[0122] User interaction and plugin work: The user enters a description of the image in the TextArea, such as "a cat wearing an astronaut helmet on the surface of the moon."

[0123] The user clicks on the bottom button rendered by ImageStyleSelectorPlugin and selects the "Cyberpunk" style.

[0124] The click event handler for the "Cyberpunk" button (defined inside ImageStyleSelectorPlugin) is triggered.

[0125] This handler calls the API provided by the PluginContext, such as context.setSendPayloadValue('style_preference', 'cyberpunk'). This operation temporarily stores the user's selected style information, ready to be appended to the request data when it is sent. The plugin may also update its own UI state (for example, highlighting the "Cyberpunk" button).

[0126] Send a request (see attached Figure 4 ): The user clicks the "Send" button.

[0127] The InputAreaCore component prepares the basic send payload, which contains the user-entered text {text: "A cat wearing an astronaut helmet on the surface of the moon"} and any attachments.

[0128] InputAreaCore notifies the PluginManager that a request is about to be sent.

[0129] The PluginManager calls the beforeSend(payload, context) lifecycle method of all currently active plugins (here ImageStyleSelectorPlugin) in a predetermined order (if there are multiple plugins).

[0130] The beforeSend method of ImageStyleSelectorPlugin reads the style information (style_preference: 'cyberpunk') stored internally or through the context, merges it into the incoming payload, and returns the modified payload: { text: "...", style_preference: "cyberpunk"}.

[0131] InputAreaCore receives the final payload (which may have been modified by the plugin) and passes it to the upper-layer application logic through its onSendProp callback.

[0132] The upper-layer application logic sends the final payload to the AI ​​backend service based on the backend information configured by the current feature (imageGen).

[0133] Receiving responses and rendering dynamic messages (see attached Figure 3 ): The backend AI service processes the request, generates an image, and returns message data containing a specific widgetType, for example: { ..., messageContent: [{ widgetType: 'imageResult', content: '{"imageUrl": "http: / / example.com / cat.png", "prompt": "A..."}'}]}.

[0134] The application logic receives the response, creates a new message object and updates the session state.

[0135] The component responsible for rendering the message list passes the new message data to the core message renderer (MessageRenderer).

[0136] MessageRenderer gets widgetType: 'imageResult'.

[0137] It queries the message component registry and finds the registration information corresponding to imageResult (including componentLoader and mapMessageContentToProps).

[0138] The MessageRenderer (possibly asynchronously) loads the ImageResultWidget component code.

[0139] Call mapMessageContentToProps to parse the content JSON string, extract data such as imageUrl and prompt, and generate widgetProps.

[0140] MessageRenderer gets the standard interaction handlers from the upper layer.

[0141] MessageRenderer renders the ImageResultWidget component, passing it widgetProps (including the image URL, etc.) and handlers.

[0142] The ImageResultWidget component renders an image display interface based on the passed props. If the component includes interactive elements (such as a download button), its click event calls the corresponding method on the passed handlers, such as handlers.onTriggerAction('downloadImage', { url: 'http: / / ...'}), triggering the app-defined download logic without the component itself having to worry about the specific implementation.

[0143] Summary of the embodiments: This example clearly demonstrates how the system of the present invention dynamically loads input area plugins and adjusts the input interface when a user switches between features, coordinated by the feature management module; how plugins respond to user interactions and influence the data to be sent through the plugin context API; and how the message rendering module dynamically loads and renders different message components based on widgetType, achieving interaction decoupling through standardized handlers. This entire process requires no modifications to the core framework code, fully demonstrating the advantages of the present invention in terms of flexibility, scalability, and low coupling, effectively overcoming the shortcomings of the existing technology.

Claims

1. A system based on dynamic registration and management of heterogeneous AI functional interfaces, characterized in that: The system comprises: The core layer includes a feature registry and a feature manager. The feature manager is used to obtain a feature definition list available in the current environment through a preset mechanism and register the feature definitions in the feature definition list with the feature manager. The message rendering subsystem includes a core message renderer, a message component registry, and a message component. The core message renderer is used to search and load the corresponding message component from the message component registry according to the component type field in the message data, and render the message content on the interface. The message component registry is used to manage the message components, and the message components are used to register through the component type field. The input area subsystem includes a plug-in manager, an input area core component, an input plug-in registry, input plug-ins, and a plug-in context module. The input area plug-in manager is used to load, instantiate, and manage the life cycle of input plug-ins based on the configuration of the currently activated features. The input area core component is used to integrate the user interface rendered by the input plug-in. The input plug-in registry is used to manage the input plug-ins. The plug-in context module is used to provide a standardized API interface for the input plug-in.

2. The system based on dynamic registration and management of heterogeneous AI functional interfaces according to claim 1, characterized in that: The system further includes a feature definition module and a configuration service module. The feature definition module is used to transmit feature definitions to the core layer. The feature manager loads feature definitions that are available in the current environment or that the user has permission to access through the configuration service module.

3. The system based on dynamic registration and management of heterogeneous AI functional interfaces according to claim 1, characterized in that: The feature definition includes a feature identifier, metadata, permission logic, and a list of interface component identifiers and input plug-in identifiers required for its operation.

4. The system based on dynamic registration and management of heterogeneous AI functional interfaces according to claim 1, characterized in that: The preset mechanism includes reading a local configuration file, scanning a specific code directory and loading it through a dynamic input function, and requesting a remote configuration service.

5. A method using the system based on dynamic registration and management of heterogeneous AI functional interfaces according to any one of claims 1 to 4, characterized in that: The method includes a system initialization and feature loading sub-method, a dynamic message rendering sub-method and a plug-in input area management sub-method, and the system initialization and feature loading sub-method includes: A1, application startup: the core layer first performs initialization operations, including initializing the feature manager and feature registry; A2, loading mode: the core layer scans or imports the feature definition module from a local file, or the core layer sends a request to the configuration service module to obtain a feature definition list; A3, Local Discovery Process: If the local discovery process is selected, the core layer scans a preset directory to find all the feature definition modules, or dynamically imports the configured feature definition modules. For each feature definition module found, the core layer registers the feature definition of the feature definition module in the feature registry; A4, remote configuration process: If the remote configuration process is selected, the core layer sends a request to the remote configuration service and obtains a list of features available in the current environment or a complete feature definition based on the configuration service module; A5, execute registerFeature() to the registry: the core layer registers the feature definition obtained from the configuration service module into the feature registry, the message rendering subsystem registers the message component into the message component registry, and the input area subsystem registers the input plug-in into the input plug-in registry; A6, Feature Manager Reads Registry: The Feature Manager reads the definitions of all registered features from the feature registry; A7, application permission filtering: the core layer performs application permission filtering on the read feature definition; A8, Generate Available Feature List: Based on the filtered feature definitions, the core layer generates an available feature list, which contains information about all features that the user is authorized to access and use; A9, UI layer displays available features: the core layer displays the generated available feature list on the UI layer of the application; A10, End: The core layer waits for the next feature switch or interactive operation by the user to start a new workflow.

6. The method according to claim 5, characterized in that The dynamic message rendering sub-method includes: B1, receiving message data: receiving, through the message rendering subsystem, the message data including the component type field transmitted by the feature manager; B2, the core message renderer obtains the message data of the component type field: the core message renderer extracts the component type field from the received message data; B3, querying the message component registry: querying the message component registry through the core message renderer to find the registration information corresponding to the extracted component type field; B4, determine whether the registration information is found: If the registration information corresponding to the component type field is found in the message component registry, the process will continue to execute. If not, the error handling process will be executed, which includes logging, rendering the default component, or prompting an error message; B5, asynchronously loading component code: asynchronously loading the corresponding message component code through the core message renderer according to the registration information found in the message component registry; B6, execute mapToProps to convert data: the core message renderer calls the message content mapping function to convert the JSON string in the message content into the properties required by the component. The properties contain all the data required for component rendering; B7, obtaining a standard interaction processor: obtaining a standard interaction processor through the core message renderer, the interaction processor being used to process interaction events within the message component, and the core message renderer passing the interaction processor to decouple the interaction between the message component and the message rendering subsystem; B8, rendering component: using the converted attributes and the interaction processor to render the message component through the core message renderer to generate a message interface element visible to the user; B9, Component Interaction Process: The rendered message component contains interactive elements. When the user interacts with the interactive elements, the message component calls the corresponding interaction method on the passed-in interaction processor, thereby triggering the interaction logic defined by the application; B10, End: When the message component is successfully rendered and the user completes the interaction with the message component or no interaction occurs, the dynamic message rendering process ends, and the message rendering subsystem waits to receive the next message data to start a new dynamic message rendering sub-method process.

7. The method according to claim 5, characterized in that The plug-in input area management sub-method includes: C1, user switching characteristics: the user selects to switch user characteristics through the user interface module in the application layer; C2, obtaining feature definition: receiving a user request to switch features through the feature manager, retrieving the feature definition of the new feature from the feature registry, the feature definition including a list of input plug-ins that need to be activated for the feature, C3, notifying the plug-in manager: notifying the plug-in manager of the list of input plug-ins that need to be activated through the property manager; C4, querying the plug-in registry: querying the plug-in registry through the plug-in manager according to the received input plug-in list to obtain the definition and loading information of each plug-in; C5, asynchronously loading the plug-in code: if the plug-in code has not been loaded into the memory, asynchronously loading the corresponding plug-in code through the plug-in manager; C6, instantiate plug-in: instantiate the plug-in object through the plug-in manager, call the corresponding onLoad method, and pass in the plug-in context module containing the API; C7, Get UI: Call the plug-in's UI generation method through the plug-in manager to request the plug-in to generate UI elements. The plug-in returns the UI elements through the UI generation method so as to be rendered in the input area. C8, Rendering the plug-in UI to a slot: Rendering the UI elements generated by the plug-in to a predefined slot through the input area core component. The slot is a location in the input area reserved for displaying the plug-in UI. The plug-in UI elements are displayed to the user through the slot for user interaction; C9, user interaction with plug-in UI: the user interacts with the plug-in UI elements rendered in the input area; C10, plug-in processing interaction: the plug-in responds to user interaction operations through internally defined interaction logic; C11, the input area core notifies the plug-in manager: during the user interaction process, the input area core component notifies the plug-in manager of events related to the user interaction; C12, the plugin manager calls the plugin: When the input content changes, the plugin manager calls the plugin's onInputChange(text, context) method to respond to the change in the input content; C13, user clicks send: After the user completes the input, he clicks the send button to trigger the operation of sending the request; C14, the input area core prepares an initial payload: The input area core component prepares an initial send payload, which includes at least the content input by the user and the data temporarily stored by the plug-in; C15, the plug-in manager calls the plug-in beforeSend method to modify the payload: the plug-in manager calls the beforeSend method of all currently activated plug-ins in a predetermined order. The plug-in reads the information stored internally or in the plug-in context module through the beforeSend method and merges it into the send payload as the final send payload; C16, the input area core sends the final payload through onSend: After receiving the final send payload returned by the plug-in manager, the input area core component sends the final send payload to the backend communication layer for processing; C17, the input area plug-in workflow ends: the input area subsystem waits for the user's next interaction or feature switching to start a new input area management sub-method process.

Images