CN120631348A - A system and method based on dynamic registration and management of heterogeneous AI functional interfaces - Google Patents

Abstract

The application relates to the technical field of software frameworks, and provides a system and a method based on dynamic registration and management of heterogeneous AI function interfaces, wherein the system comprises a core layer, a characteristic register table and a characteristic manager, wherein the characteristic manager is used for acquiring a characteristic definition list available in a current environment through a preset mechanism and registering characteristic definitions in the characteristic definition list into the characteristic manager; 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. The application greatly simplifies the integration flow, accelerates the iteration period, effectively reduces the maintenance difficulty and risk, can flexibly adapt to changes without redeployment, and further improves the expandability and maintainability of the system by efficiently multiplexing components and plugins and supporting independent evolution through standardized interfaces and registration mechanisms.

Description

System and method for dynamically registering and managing heterogeneous AI function interface

Technical Field

The application relates to the technical field of software frameworks, in particular to a system and a method for dynamically registering and managing heterogeneous AI function interfaces.

Background

In the prior art, when integrating or building applications containing a variety of artificial intelligence functions in a software system, challenges are faced in managing the diversity of these functions. For example, an AI assistant may need to provide multiple functions simultaneously, such as text questions and answers, text generation, picture generation, internal knowledge queries, business data analysis, specific task execution, and so forth.

These functions exhibit significant heterogeneity in the user interaction interface, in that the input style may evolve from simple text boxes, with specific options, complex forms, even requiring invocation of external flows, and in that the response content of AI may extend from plain text, markdown, to components containing interactive buttons, data cards, pictures, or requiring special rendering.

The common implementation mode at present is to develop hard coding aiming at each function, and directly write interface rendering logic, interaction processing logic and back-end communication logic of a specific function into front-end codes. This approach has the following significant drawbacks:

The development and iteration efficiency is low, namely when the AI function is newly added or modified, particularly when the complex function with unique interaction mode is needed, a great amount of modification, test and redeployment are needed to be carried out on the core code, the development period is long, and the service requirement is difficult to quickly respond.

The maintenance cost is high and the error is easy, the logics of different functions are tightly coupled or are judged and interweaved together through complex conditions, so that the code library is complex and difficult to understand and maintain, and regression errors are easy to introduce during modification.

The flexibility and the dynamics are poor, and the user-visible function set and the interface performance thereof are difficult to control in real time and flexibly according to the user permission, background configuration or other runtime conditions, such as dynamically enabling/disabling a certain input auxiliary plug-in.

High coupling and code redundancy, namely high coupling degree among all levels (UI presentation, interaction logic, state management and back-end communication) of the system and among different functional modules, lack of unified abstraction, and cause poor reusability and code redundancy.

Disclosure of Invention

In order to help solve the technical problems, the application provides a system and a method for dynamically registering and managing heterogeneous AI function interfaces.

In a first aspect, the present application provides a system for dynamically registering and managing heterogeneous AI function interfaces, which adopts the following technical scheme:

A system for dynamically registering and managing heterogeneous AI-function interfaces, wherein the system comprises:

The core layer comprises a characteristic registry and a characteristic manager, wherein the characteristic manager is used for acquiring a characteristic definition list available for the current environment through a preset mechanism and registering characteristic definitions in the characteristic definition list into the characteristic manager;

The message rendering subsystem comprises a core message renderer, a message component registry and a message component, wherein the core message renderer is used for searching and loading a corresponding message component from the message component registry according to a component type field in message data, rendering message content on an interface, the message component registry is used for managing the message component, and the message component is used for registering through the component type field;

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, wherein the input area plug-in manager is used for loading, instantiating and managing the life cycle of the input plug-in according to the configuration of the current activation characteristics, the input area core component is used for integrating a user interface rendered by the input plug-in, the input plug-in registry is used for managing the input plug-in, and the plug-in context module is used for providing a standardized API interface for the input plug-in.

Preferably, the system further comprises a property definition module and a configuration service module, wherein the property definition module is used for transmitting the property definition to the core layer, and the property manager loads the property definition available in the current environment or authorized to be accessed by the user through the configuration service module.

Preferably, the property definition includes a list of interface component identifiers and input plug-in identifiers that include a property identifier, metadata, rights logic, and their required for operation.

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

In a second aspect, the present application provides a method for dynamically registering and managing heterogeneous AI function interfaces, which adopts the following technical scheme:

a method employing the system based on dynamic registration and management of heterogeneous AI functionality interface of any of the first aspects, wherein the method comprises a system initialization and feature loading sub-method, a dynamic message rendering sub-method, and a plug-in input area management sub-method, the system initialization and feature loading sub-method comprising;

a1, starting an application, wherein the core layer firstly performs initialization operation, including initializing a characteristic manager and a characteristic registry;

A2, the loading mode is that the core layer scans or imports the characteristic definition module from a local file, or the core layer sends a request to the configuration service module to acquire a characteristic definition list;

A3, local discovery flow, wherein if the local discovery flow is selected, the core layer scans a preset catalog, searches all the characteristic definition modules or dynamically imports the configured characteristic definition modules, and for each found characteristic definition module, the core layer registers the characteristic definition of the characteristic definition module into the characteristic registry;

a4, remote configuration flow, wherein if the remote configuration flow is selected, the core layer sends a request to the remote configuration service, and a characteristic list or complete characteristic definition available in the current environment is obtained based on the configuration service module;

a5, executing registerFeature () to a registry, wherein the core layer registers the characteristic definition acquired from the configuration service module to the characteristic registry, the message rendering subsystem registers the message component to the message component registry, and the input area subsystem registers the input plugin to the input plugin registry;

A6, the characteristic manager reads the registry, wherein the characteristic manager reads the definitions of all registered characteristics from the characteristic registry;

A7, applying authority filtering, namely, the core layer carries out application authority filtering on the read characteristic definition;

A8, generating an available characteristic list, namely generating an available characteristic list by the core layer according to the filtered characteristic definition, wherein the available characteristic list contains information of all characteristics which a user is authorized to access and use;

A9, the UI layer displays the available characteristics, wherein the core layer displays the generated available characteristic list on the UI layer of the application;

and A10, ending, wherein the core layer waits for the next characteristic switching or interaction operation of the user to start a new workflow.

Preferably, the dynamic message rendering sub-method includes:

B1, receiving message data, namely receiving the message data which is transmitted by the characteristic manager and contains the component type field through the message rendering subsystem;

B2, the core message renderer acquires the message data of the component type field, wherein the component type field is extracted from the received message data by the core message renderer;

b3, inquiring a message component registry by the core message renderer to find registration information corresponding to the extracted component type field;

Judging 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 is continuously executed, and if the registration information is not found, the error processing process is executed, wherein the error processing process comprises logging, rendering a default component or prompting error information;

B5, asynchronously loading the component codes, namely asynchronously loading the corresponding message component codes through the core message renderer according to the registration information searched in the message component registry;

B6, executing mapToProps conversion data, namely calling a message content mapping function through the core message renderer to convert a JSON character string in the message content into attributes required by the component, wherein the attributes comprise all data required by the component rendering;

The standard interaction processor is acquired through the core message renderer, the interaction processor is used for processing interaction events in the message assembly, and the core message renderer transmits the interaction processor so as to decouple interaction between the message assembly and the message rendering subsystem;

B8, rendering the message component by the core message renderer by using the converted attribute and the interaction processor to generate a message interface element visible to a user;

The component interaction flow comprises the steps that a rendered message component contains interaction elements, and when a user interacts with the interaction elements, the message component calls a corresponding interaction method on an input interaction processor, so that interaction logic defined by an application is triggered;

and B10, ending, namely ending the dynamic message rendering flow when the message component is successfully rendered and the user completes the interaction with the message component or no interaction occurs, and waiting for receiving the next message data by the message rendering subsystem to start a new dynamic message rendering sub-method flow.

Preferably, the plug-in input area management sub-method includes:

The user selects to switch the user characteristics through the user interface module in the application layer;

C2, obtaining a feature definition, namely receiving a request of switching the feature by a user through the feature manager, retrieving a feature definition of a new feature from the feature registry, wherein the feature definition comprises an input plugin list which needs to be activated by the feature,

Notifying a plug-in manager, namely notifying an input plug-in list to be activated to the plug-in manager through the characteristic manager;

querying a plug-in registry by the plug-in manager according to the received input plug-in list to acquire definition and loading information of each plug-in;

the plug-in codes are asynchronously loaded, namely if the plug-in codes are not loaded into the memory, the corresponding plug-in codes are asynchronously loaded through the plug-in manager;

The plug-in is instantiated, namely a plug-in object is instantiated through the plug-in manager, a corresponding onLoad method is called, and a plug-in context module containing an API is transmitted;

C7, acquiring a UI, namely calling a UI generation method of a plug-in through the plug-in manager, requiring the plug-in to generate a UI element, and returning the UI element by the plug-in through the UI generation method so as to render in an input area;

C8, rendering the plug-in UI to a slot, wherein the UI elements generated by the plug-in are rendered into a predefined slot through the input area core component, the slot is reserved in the input area and used for displaying the position of the plug-in UI, and the UI elements of the plug-in are displayed to a user through the slot so as to interact with the user;

C9, the user interacts with the plug-in UI, wherein the user interacts with the plug-in UI elements rendered in the input area;

The plug-in processes interaction, wherein the plug-in responds to the interaction operation of a user through interaction logic defined in the plug-in;

C11, informing the plug-in manager of an event related to user interaction through the input area core component in the user interaction process;

C12, the plugin manager calls a plugin, wherein when the input content changes, the plugin manager calls a onInputChange (text) method of the plugin to respond to the change of the input content;

c13, the user clicks the sending button after finishing input, and triggers the operation of sending the request;

C14, preparing an initial payload by an input area core, namely preparing an initial transmission load by an input area core component, wherein the transmission load at least comprises content input by a user and plug-in temporary data;

The plug-in manager calls plug-in beforeSend to modify payload, the plug-in manager calls beforeSend methods of all active plug-ins currently according to a preset sequence, and the plug-in reads information temporarily stored in the plug-in context module or through the beforeSend method and merges the information into a transmission load to serve as a final transmission load;

The input area core sends a final payload through onSend, namely after receiving the final sending load returned by the plug-in manager through the input area core component, the input area core sends the final sending load to a back-end communication layer for processing;

And C17, finishing the input area plug-in workflow, wherein the input area subsystem waits for the next interaction or characteristic switching of the user to start a new input area management sub-method flow.

In summary, the application has the following advantages:

The development and iteration efficiency is improved, new function development is performed in the form of cohesive modules (characteristic definition, components and plugins), and the new function development can be accessed through registration, so that the integration work is greatly simplified, and the iteration is accelerated.

The maintenance cost is reduced, namely the clear architecture layering and low coupling design are realized, so that codes are easier to understand, modify and test, and the maintenance difficulty and risk are reduced.

The flexibility and the dynamics are enhanced, namely, the function is enabled/disabled, the interface elements are increased or decreased (through the plug-in), and even part of the interaction flow is adjusted, and the method can be dynamically realized based on configuration (possibly from remote) without redeployment.

The coupling degree is reduced, the reusability is improved, and the standardized interface and registration mechanism enable the components and the plug-ins to be easily reused and independently evolved.

Drawings

FIG. 1 is a schematic block diagram of one embodiment of a system for dynamic registration and management of heterogeneous AI function interfaces in accordance with the present application;

FIG. 2 is a flow chart of one embodiment of a system initialization and feature loading sub-method of the present application;

FIG. 3 is a flow diagram of one embodiment of a dynamic message rendering sub-method of the present application;

FIG. 4 is a flow chart of one embodiment of the pluggable input area management sub-method of the present application.

Detailed Description

The construction and principles of the present application will be readily apparent to those skilled in the art from the following description taken in conjunction with the accompanying drawings. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.

The english nouns in this document include:

Feature Manager. And the method is responsible for dynamically loading the characteristic definition which is available in the current environment or has authority to access by the user when the application is started or run, and registering the characteristic definition in a characteristic registry. Meanwhile, the method maintains a list of available characteristics, and drives other subsystems (such as a message rendering layer and an input area management layer) to load corresponding configurations for adaptation when the user switches the characteristics.

FeatureRegistry A characteristics registry. As a unified management center, it is responsible for managing all the functional characteristics (or "scenes"). Each property is described by its property definition (FeatureDefinition) that contains a property identifier, metadata (e.g., name, icon, etc.), rights logic, and key information such as the interface component identifier and the list of input plug-in identifiers required for the operation of the property.

MESSAGE RENDERING LAYER message rendering layer. And the message display module is used for searching and loading the corresponding message display module from the message module registry according to WIDGETTYPE fields in the message data and is responsible for rendering the message content to the interface.

MESSAGEWIDGETREGISTRY message component registry. Is responsible for managing the different types of message presentation components. These message components are dynamically registered through WIDGETTYPE identifiers (e.g., by the feature module to which they pertain when loaded) and support asynchronous loading, thereby improving the system's startup speed and operating efficiency.

Input AREA MANAGEMENT LAYER Input area management layer. Includes an input area core component (InputAreaCore), an input plug-in registry (InputPluginRegistry), an input area plug-in manager (PluginManager), and a plug-in context module (PluginContext).

InputAreaCore input area core component. As a core component of the input area, it is responsible for integrating the User Interface (UI) of the input plug-in rendering and exposing it in the input area of the application. The input area core component provides a unified input entrance for users and supports various input modes and plug-in expansion.

InputPluginRegistry entering a plug-in registry. Is responsible for managing all available input plugins. These plug-ins register dynamically through pluginId and provide rich input functionality extensions to the input area.

PluginManager plug-in manager. Depending on the configuration of the current activation characteristics, it is responsible for loading, instantiating, and managing the lifecycle of the input plug-ins (e.g., invoking the method of plug-ins onLoad, beforeSend, etc.). It ensures that the input plug-in is able to function properly as required by the property definition and interact with the input field core component.

PluginContext plug-in context module. A standardized API interface (e.g., setInputText, setSendPayloadValue, etc.) is provided for the input plug-in to enable the plug-in to interact with the input field core component and the data delivery flow.

WIDGETTYPE component type field. A key field in the message data determines which type of message presentation component is to be rendered next.

MESSAGERENDERER core message renderer. WIDGETTYPE are extracted from the received message data, the message component registry is queried for corresponding registration information, and the message presentation component is rendered using the converted attributes and interaction processor.

MapMessageContentToProps message content mapping function. The JSON string in the message content is converted to attributes (props) required by the component, which contain all the data required for component rendering.

Handlers an interaction processor. A series of methods are included for handling interactive events within the message presentation component, such as button clicks, link jumps, etc.

FeatureId a characteristic identifier. For uniquely identifying one functional characteristic, a user, upon selecting to switch different functional characteristics via the application interface, communicates featureId to indicate the target characteristic.

InputPluginIds entering a list of plug-in identifiers. A list contained in the feature definition specifies the input plug-ins that the feature needs to be activated.

OnLoad (context) plug-in loading method. After the plug-in manager instantiates the plug-in object, this method is invoked and passed into the plug-in context to initialize the plug-in and provide the ability to interact with other parts of the system.

RenderSlot (): plug-in rendering method. The plugin manager invokes this method, requiring the plugin to generate its UI elements for rendering in the input area.

SetPluginState set plug-in status method. The plug-in updates its internal state by this method or communicates with the input area core component.

SetSendPayloadValue a method for setting a transmission load value. By this means the plug-in temporarily stores data entered by the user, which data will be appended to the transmission request when the user clicks the transmission button.

OnInputChange (text) input content change processing method. When the input content changes, the plugin manager invokes the method to respond to the change of the input content, so that the plugin can process the user input in real time.

BeforeSend (payload), send preprocessing method. The plug-in manager invokes this method before sending the request, allowing the plug-in to modify the send load.

OnSend sending callback method. The input area core component sends the final send payload to the upper layer application logic in this way.

ImageResultWidget A picture result display component. A message presentation component for rendering message content containing pictures, such as AI-generated picture results.

OnTriggerAction triggering an action method. This method is invoked to trigger application-defined interaction logic when an interaction element (e.g., download button) in the message presentation component is clicked.

FIG. 1 is a schematic block diagram of one embodiment of a system for dynamic registration and management of heterogeneous AI function interfaces in accordance with the present application. The system comprises a core layer, a message rendering subsystem, an input area subsystem, a characteristic definition module, a configuration service module and a back-end communication layer.

Specifically, a Feature Manager (Feature Manager) is responsible for dynamically loading and registering Feature definitions available to the current environment or to which the user has access, into a Feature registry at the start or run of the application. Meanwhile, the method maintains a list of available characteristics, and drives other subsystems (such as a message rendering layer and an input area management layer) to load corresponding configurations for adaptation when the user switches the characteristics.

The properties registry (FeatureRegistry) serves as a unified management center, responsible for managing all functional properties (or "scenarios"). Each property is described by its property definition (FeatureDefinition) that contains a property identifier, metadata (e.g., name, icon, etc.), rights logic, and key information such as the interface component identifier and the list of input plug-in identifiers required for the operation of the property.

The message rendering layer (MESSAGE RENDERING LAYER) is used for searching and loading the corresponding message display component from the message component registry according to the WIDGETTYPE field in the message data, and is responsible for rendering the message content onto the interface. The method and the system realize decoupling of the interaction logic and the application core logic in the message component by transmitting the standardized interaction processor interface (MessageInteractionHandlers) to the rendered message component, and improve the flexibility and maintainability of the system.

The message component registry (MESSAGEWIDGETREGISTRY) is responsible for managing the different types of message presentation components. These message components are dynamically registered through WIDGETTYPE identifiers (e.g., by the feature module to which they pertain when loaded) and support asynchronous loading, thereby improving the system's startup speed and operating efficiency.

The Input area management layer (Input AREA MANAGEMENT LAYER) includes:

an input area core component (InputAreaCore) acts as the core component of the input area and is responsible for integrating the User Interface (UI) rendered by the input plug-in and exposing it in the input area of the application. The input area core component provides a unified input entrance for users and supports various input modes and plug-in expansion.

The input plug-in registry (InputPluginRegistry) is responsible for managing all available input plug-ins. These plug-ins register dynamically through pluginId and provide rich input functionality extensions to the input area.

The input area plug-in manager (PluginManager) is responsible for loading, instantiating, and managing the lifecycle of the input plug-ins (e.g., invoking the plug-in onLoad, beforeSend, etc. methods) according to the configuration of the current activation characteristics. It ensures that the input plug-in is able to function properly as required by the property definition and interact with the input field core component.

The plug-in context module (PluginContext) provides a standardized API interface (e.g., setInputText, setSendPayloadValue, etc.) for the input plug-in, enabling the plug-in to interact with the input field core component and the data delivery flow. Through the plug-in context, the input plug-in can conveniently acquire and set information such as input text, load value transmission and the like, so that seamless integration of the plug-in and system core functions is realized.

FIG. 2 is a flow chart of an embodiment of the system initialization and feature loading sub-method of the present application. As can be appreciated in connection with fig. 2, the method includes the following.

When an application is started, the system first performs an initialization operation, which includes initializing a feature manager and a feature registry. The property manager is responsible for subsequent property loading and registration work, while the property registry is a central repository storing all registered property definitions.

The system next needs to determine how to load the property definition. This is typically done in two ways, local discovery and remote configuration.

The local discovery is that the system scans or dynamically imports the feature module directly from the local file system. This approach applies to scenarios where the property definition is pre-deployed on the device.

Remote configuration the system sends a request to the remote configuration service to obtain the latest feature list or definition. This approach allows the property definition to be managed remotely and updated dynamically, improving the flexibility of the system.

And (3) scanning or dynamically importing the characteristic modules, namely if a local discovery mode is selected, scanning a preset catalogue by the system, searching all the characteristic modules or dynamically importing the configured characteristic modules.

Execute registerFeature () to registry-for each found property module, the system calls registerFeature () function to register its property definition in the property registry. The property definition contains metadata, rights logic, required components and plug-ins for the property.

The remote configuration flow is to request the configuration service to acquire a characteristic list/definition, and if the remote configuration mode is selected, the system sends a request to the remote configuration service to acquire the characteristic list or complete characteristic definition available in the current environment.

The system can select the on-demand characteristic definition according to the information returned by the remote configuration service, namely, the complete definition of a certain characteristic is loaded only when needed, so as to reduce the system starting time and memory occupation.

RegisterFeature () is executed to the registry-the system will register the property definition obtained from the remote configuration service in the property registry, in a similar manner to local discovery.

The properties manager reads the registry from which it reads the definitions of all registered properties. These definitions contain information of all the features supported by the system and are the basis for the subsequent operation of the system.

And (5) application authority filtering, namely, the system performs application authority filtering on the read characteristic definition. This step ensures that the user can only access and use the authorized feature, and improves the security of the system.

And generating a list of available characteristics, namely generating a list of available characteristics by the system according to the filtered characteristic definition. This list contains information of all features that the user has access to and uses, which is the basis for the user to select the functional features.

The UI layer displays the available characteristics, namely the system displays the generated available characteristics list on the UI layer of the application, so that a user can intuitively see and select the required functional characteristics. The user may interact with the list of available features by clicking or touching, etc., selecting and switching to a different functional feature.

And ending the dynamic registration and loading process of the characteristic module. The system is already initialized and ready to dynamically load and present different features according to the user's choice. The system waits for the next feature switch or interaction of the user to begin a new workflow.

FIG. 3 is a flow chart of an embodiment of the dynamic message rendering sub-method of the present application. As can be appreciated in connection with fig. 3, the method may include the following.

And starting to receive message data. The starting point for the dynamic message rendering flow is that the system receives message data containing WIDGETTYPE. This WIDGETTYPE (component type field) is critical information that determines which type of message-displaying component is to be rendered next.

Core message renderer acquires WIDGETTYPE the core message renderer (MESSAGERENDERER) extracts WIDGETTYPE from the received message data. This step is critical to dynamic message rendering because WIDGETTYPE is directed to the specific components that need to be rendered.

Querying a message component registry the core message renderer queries the message component registry (MESSAGEWIDGETREGISTRY) to find registration information corresponding to the extracted WIDGETTYPE. The message component registry is a place to centrally manage all available message presentation components, storing the type of component, the loading mode and the mapping relation with the message content.

It is determined whether registration information is found, if registration information corresponding to WIDGETTYPE is found in the message component registry, the process continues, and if not, an error handling process, such as logging, rendering a default component, or prompting for error information, may be performed.

Asynchronously loading component code (this step is optional) the core message renderer may asynchronously load the corresponding message presentation component code based on registration information found in the message component registry. This step is optional because some components may already be preloaded into memory, while some components may need to be dynamically loaded when needed to reduce system boot time and memory footprint.

Executing mapToProps the conversion data the core message renderer invokes the message content mapping function (e.g., mapMessageContentToProps) to convert the JSON string in the message content to the required attributes for the component (props). These attributes contain all the data required for the component rendering, such as text content, picture URLs, button configurations, etc.

Get criteria interaction Handlers the core message renderer gets the criteria interaction handler (handlers) from the upper layer application logic. These processors incorporate a series of methods for handling interactive events within the message presentation component, such as button clicks, link jumps, etc. By passing these processors, the core message renderer enables interactive decoupling between the message presentation component and the application core logic.

A rendering component the core message renderer uses the converted attributes (props) and interaction processor (handlers) to render the message-exposing component. This step combines the component code, data, and interaction logic to ultimately generate a message interface element that is visible to the user.

Component interaction flow-rendered message presentation components may contain various interactive elements such as buttons, input boxes, links, and the like. When a user interacts with these elements (e.g., clicks on a button), the component invokes a corresponding method on the incoming interaction processor, triggering application-defined interaction logic. This design allows the message presentation component to focus on interface presentation, while delivering complex business logic to upper layer application processing.

Error handling is performed-during component loading, data parsing, rendering, or interaction, if any errors occur (e.g., component loading failure, data parsing error, rendering exception, etc.), the system performs the corresponding error handling flow. This may include logging error logs, rollback operations, prompting the user for error information, etc., to ensure stability and reliability of the system.

And ending, namely ending the dynamic message rendering flow after the message presentation component is successfully rendered and the user completes the interaction with the component (or no interaction occurs). The system waits to receive the next message data to begin a new rendering flow.

FIG. 4 is a flow chart of one embodiment of the pluggable input area management sub-method of the present application. As can be appreciated in connection with fig. 4, the method may include the following.

Initially, a user switches features (featureId) by selecting a different functional feature through the application interface (featureId). This operation is the starting point for the input area plugin workflow, which triggers the process of the system to load and configure the corresponding input plugin according to the new characteristics.

The feature manager operates to retrieve the feature definition by retrieving the complete definition of the new feature from the feature registry (FeatureRegistry) upon receipt by the feature manager (FeatureManager) of a request to switch the feature by the user. The feature definition includes a list of input plug-ins (inputPluginIds) that the feature needs to be activated.

The feature manager notifies the plug-in manager (PluginManager) of the list of input plug-ins that need to be activated, triggering plug-in loading and instantiation processes.

The plugin manager operates to query a plugin registry-the plugin manager queries the plugin registry (InputPluginRegistry) based on the received input plugin list to obtain definition and loading information for each plugin.

Asynchronous loading of plug-in code (this step is optional) if plug-in code has not yet been loaded into memory, the plug-in manager may asynchronously load the corresponding plug-in code. This ensures that the plug-in can be dynamically loaded when needed.

Instantiate plug-ins and invoke onLoad (context) the plug-in manager instantiates plug-in objects and invokes its onLoad (context) methods, passing in plug-in context (PluginContext) objects containing various APIs. This step initializes the plug-in and provides it with the ability to interact with the input area core component and the data transmission flow.

Calling plugin renderSlot () to obtain the UI the plugin manager calls the plugin's renderSlot () method, requiring the plugin to generate its UI element. The plug-in returns its UI elements by this method for rendering in the input area.

Input area core component:

Rendering the plug-in UI to socket an input area core component (InputAreaCore) is responsible for rendering the UI elements generated by the plug-in into a predefined socket. These slots are reserved in the input area for exposing the plug-in UI. Through this step, the UI elements of the plug-in are presented to the user, who can interact with them.

User interaction flow:

the user interacts with the plug-in UI by interacting with the plug-in UI elements rendered in the input area, such as entering text, selecting options, clicking buttons, etc.

The plug-in processes interaction that the plug-in responds to the user's interaction operations through its internally defined interaction logic. The plug-in may update its internal state or communicate with the input area core component through an API (e.g., setPluginState) provided by the plug-in context.

The input area core informs the plug-in manager that during user interaction, the input area core component may inform the plug-in manager about events of user interactions as needed so that the plug-in manager coordinates interactions between multiple plug-ins.

Plug-in temporary data the plug-in may temporarily store data entered by the user through an API (e.g., setSendPayloadValue) provided by the plug-in context. These data will be appended to the send request when the user clicks the send button.

The plugin manager invokes a plugin onInputChange (context) that when the input content changes (e.g., the user has entered a new text), the plugin manager may invoke the plugin onInputChange (context) method in response to the change in the input content. This enables the plug-in to process the user's input in real time and update its UI or internal state.

The transmission flow is as follows:

and the user clicks the sending button after finishing input, and triggers the operation of sending the request.

Input area core prepares initial payload the input area core component prepares an initial transmit payload (payload). This payload contains the content entered by the user, plug-in data, and other relevant information.

The plugin manager invokes plugin beforeSend (context) modify plugin: the plugin manager invokes the beforeSend (context) method of all active plugins currently in a predetermined order. The plug-in may read information that is cached either internally or through the plug-in context in this method and incorporate it into the send payload, thereby modifying the final send content.

And the input area core sends the final payload through onSend, namely, after the input area core component receives the final sending load returned by the plug-in manager, the input area core component sends the load to the upper application logic through a onSend callback thereof. And the upper layer application logic sends the load to the back-end service for processing, and the whole sending flow is completed.

Ending the operation flow of the input area plug-in unit. The system waits for the next interaction or feature switch of the user to begin a new workflow.

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

The user uses the general dialogue function in the embedded AI assistant, then switches to the AI picture generation function, inputs description and selects style, and generates picture.

The steps are as follows:

System initialization and feature loading (see fig. 2):

When an application is started, a core properties management module (FeatureManager) is initialized.

FeatureManager obtains a list of property definitions available to the current environment through a pre-set mechanism (e.g., read a local configuration file, scan a specific code directory and load through dynamic import (), or request a remote configuration service). The list is assumed to contain "general dialog" (featureId: 'general') and "AI chart" (featureId: 'imageGen') and the like.

For each acquired property definition FeatureManager calls registerFeature functions, which register the property definition (containing metadata, rights logic, required inputPluginIds like [ 'imageStyleSelector' ], extraMessageRendererId, beModule identification, etc.) into a property registry (FeatureRegistry).

During or before this process, the respective functional modules (or the modules responsible for managing them) have also registered their provided message rendering components (e.g., textWidget, imageResultWidget) and input plug-ins (e.g., imageStyleSelectorPlugin) into the respective message component registry and input plug-in registry via respective registration functions REGISTERMESSAGEWIDGET and registerInputPlugin.

User selection and feature switching:

The application interface presents the user with optional function portals (e.g., bottom Action Bar or a welcome interface) based on the list of available features obtained from FeatureManager and filtered for rights. In an initial state, the user may be in a "general" feature.

The user selects to switch to imageGen features by clicking on the "AI chart" icon or button on the interface.

The interface informs FeatureManager of the user's selection (featureId: ' imageGen ').

Characteristic switching processing (coordinated by FeatureManager):

FeatureManager receives the handover request and records that the current activation characteristic is imageGen.

It retrieves the complete FeatureDefinition of imageGen from FeatureRegistry.

FeatureManager, according to this definition, drive other subsystems to perform state updates and adaptations:

The notification input area subsystem (see fig. 4) FeatureManager passes configuration information specified in the imageGen definition, such as inputPluginIds (e.g., [ 'imageStyleSelector' ]), inputPlaceholder ("describe you imagine picture.+ -.)") and possibly customFooterComponentId (if defined), to the input area plug-in manager (PluginManager).

The back-end communication layer is configured to (if necessary) indicate that subsequent requests by the back-end communication layer should use the beModule identification or other specific parameter corresponding to imageGen.

The message rendering subsystem is (possibly) informed if the feature switch needs to affect some general behavior of the message list (although driven mainly by WIDGETTYPE).

Input area dynamic adaptation (see fig. 4):

The plug-in manager (PluginManager) receives an instruction that requires activation [ 'imageStyleSelector' ].

It queries the input plug-in registry to find imageStyleSelector the corresponding plug-in definition (including loader, lifecycle methods, etc.).

PluginManager (possibly asynchronously) load the code of the plug-in.

Instantiate ImageStyleSelectorPlugin and call its onLoad (context) method, pass in PluginContext objects containing various APIs.

PluginManager invokes the renderSlot ('bottom') method of the plug-in instance (assuming that the plug-in defines rendering the UI at the bottom slot).

The input area core component (InputAreaCore) retrieves the action node (e.g., a set of style selection buttons) returned by the plug-in and renders it to a predefined "bottom slot" area.

At the same time InputAreaCore updates the placeholder of the TextArea component inside it to "describe your imagined picture" received from FeatureManager.

User interaction and plug-in work:

The user enters a pictorial description, such as "a cat wearing an astronaut helmet is on the lunar surface" at TextArea.

The user clicks on the "Saibond" style in the bottom button rendered by ImageStyleSelectorPlugin.

A click event handler (defined internally at ImageStyleSelectorPlugin) of the "sepbock" button is triggered.

The processor calls PluginContext provided APIs such as context.setsendpayloadvalue ('style_reference', 'cyberpunk'). This operation temporarily stores style information selected by the user, ready to be added to the request data at the time of transmission. The plug-in may also update its UI state (e.g., highlight the "Saibondak" button).

Send request (see fig. 4):

the user clicks the "send" button.

The input area core component (InputAreaCore) prepares the underlying transmit payload containing the text { text: "a cat wearing an astronaut helmet on the moon surface" }, and possibly accessory information, entered by the user.

InputAreaCore notify the plug-in manager (PluginManager) that a request is about to be sent.

PluginManager invokes the beforeSend (payload) lifecycle method of all active plug-ins currently (here ImageStyleSelectorPlugin) in a predetermined order (if there are multiple plug-ins).

ImageStyleSelectorPlugin the beforeSend method reads the style information (style_reference: 'cyberpunk') either internally or temporarily by context and merges it into the incoming payload, returning a modified payload: { text: ", style_reference:" cyberpunk "}.

InputAreaCore receives the final payload (which may be modified by the plug-in) and loops back to the upper layer application logic through its onSend Prop.

The upper layer application logic sends the final payload to the AI backend service according to the backend information configured by the current characteristics (imageGen).

Receive response and dynamic message rendering (see fig. 3):

The backend AI service processes the request, generates a picture, and returns message data containing a particular WIDGETTYPE, e.g., ：{ ..., messageContent: [{ widgetType: 'imageResult', content: '{"imageUrl": "http://example.com/cat.png", "prompt": " a., "}' } ].

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

The component responsible for rendering the message list passes the new message data to the core message renderer (MESSAGERENDERER).

MESSAGERENDERER obtained WIDGETTYPE: 'imageResult'.

It queries the message component registry for imageResult corresponding registration information (including componentLoader and mapMessageContentToProps).

MESSAGERENDERER (possibly asynchronous) load ImageResultWidget component code.

And calling mapMessageContentToProps to analyze the content JSON character string, extracting imageUrl, campt and other data, and generating widgetProps.

MESSAGERENDERER obtain the standard interaction processor handlers from the upper layer.

MESSAGERENDERER render ImageResultWidget component, passing widgetProps (including picture URL, etc.) and handlers to it.

The ImageResultWidget component renders the picture-presentation interface in accordance with the imported Props. If the component contains an interactive element (e.g., download button), its click event will invoke a corresponding method on the incoming handlers, such as handles.' http:// -), thereby triggering the download logic of the application definition without the component itself having to be concerned about the specific implementation.

Summary of the examples:

The embodiment clearly shows how the system of the invention dynamically loads the plug-in components of the input area and adjusts the input interface through the coordination of the characteristic management module when the user switches the functional characteristics, how the plug-in components respond to the user interaction through the plug-in context API and influence the data to be sent, and how the message rendering module dynamically loads and renders different types of message components according to WIDGETTYPE and achieves interaction decoupling through the standardization Handlers. The whole process does not need to modify the core frame code, fully embodies the advantages of the invention in the aspects of flexibility, expandability and low coupling, and effectively overcomes the defects of the prior art.

Claims (7)

1. A system for dynamically registering and managing heterogeneous AI functionality interfaces, the system comprising:

The core layer comprises a characteristic registry and a characteristic manager, wherein the characteristic manager is used for acquiring a characteristic definition list available for the current environment through a preset mechanism and registering characteristic definitions in the characteristic definition list into the characteristic manager;

The message rendering subsystem comprises a core message renderer, a message component registry and a message component, wherein the core message renderer is used for searching and loading a corresponding message component from the message component registry according to a component type field in message data, rendering message content on an interface, the message component registry is used for managing the message component, and the message component is used for registering through the component type field;

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, wherein the input area plug-in manager is used for loading, instantiating and managing the life cycle of the input plug-in according to the configuration of the current activation characteristics, the input area core component is used for integrating a user interface rendered by the input plug-in, the input plug-in registry is used for managing the input plug-in, and the plug-in context module is used for providing a standardized API interface for the input plug-in.

2. The system for dynamic registration and management of heterogeneous AI functionality interface of claim 1, further comprising a property definition module and a configuration service module, wherein the property definition module is configured to transmit a property definition to the core layer, and wherein the property manager loads the property definition available to the current environment or accessible to the user via the configuration service module.

3. The system for dynamic registration and management of heterogeneous AI functionality interface of claim 1, wherein the property definition includes a list of interface component identifiers and input plug-in identifiers that include a property identifier, metadata, rights logic, and their required for operation.

4. The system for dynamic registration and management of heterogeneous AI functionality interface of claim 1, wherein the preset mechanism includes reading a local configuration file, scanning a specific code directory, and loading via a dynamic input function, requesting a remote configuration service.

5. A method employing the system based on dynamic registration and management of heterogeneous AI functionality interface of any of claims 1-4, 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, the system initialization and feature loading sub-method including;

a1, starting an application, wherein the core layer firstly performs initialization operation, including initializing a characteristic manager and a characteristic registry;

A2, the loading mode is that the core layer scans or imports the characteristic definition module from a local file, or the core layer sends a request to the configuration service module to acquire a characteristic definition list;

A3, local discovery flow, wherein if the local discovery flow is selected, the core layer scans a preset catalog, searches all the characteristic definition modules or dynamically imports the configured characteristic definition modules, and for each found characteristic definition module, the core layer registers the characteristic definition of the characteristic definition module into the characteristic registry;

a4, remote configuration flow, wherein if the remote configuration flow is selected, the core layer sends a request to the remote configuration service, and a characteristic list or complete characteristic definition available in the current environment is obtained based on the configuration service module;

a5, executing registerFeature () to a registry, wherein the core layer registers the characteristic definition acquired from the configuration service module to the characteristic registry, the message rendering subsystem registers the message component to the message component registry, and the input area subsystem registers the input plugin to the input plugin registry;

A6, the characteristic manager reads the registry, wherein the characteristic manager reads the definitions of all registered characteristics from the characteristic registry;

A7, applying authority filtering, namely, the core layer carries out application authority filtering on the read characteristic definition;

A8, generating an available characteristic list, namely generating an available characteristic list by the core layer according to the filtered characteristic definition, wherein the available characteristic list contains information of all characteristics which a user is authorized to access and use;

A9, the UI layer displays the available characteristics, wherein the core layer displays the generated available characteristic list on the UI layer of the application;

and A10, ending, wherein the core layer waits for the next characteristic switching or interaction operation of the user to start a new workflow.

6. The method of claim 5, wherein the dynamic message rendering sub-method comprises:

B1, receiving message data, namely receiving the message data which is transmitted by the characteristic manager and contains the component type field through the message rendering subsystem;

B2, the core message renderer acquires the message data of the component type field, wherein the component type field is extracted from the received message data by the core message renderer;

b3, inquiring a message component registry by the core message renderer to find registration information corresponding to the extracted component type field;

Judging 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 is continuously executed, and if the registration information is not found, the error processing process is executed, wherein the error processing process comprises logging, rendering a default component or prompting error information;

B5, asynchronously loading the component codes, namely asynchronously loading the corresponding message component codes through the core message renderer according to the registration information searched in the message component registry;

B6, executing mapToProps conversion data, namely calling a message content mapping function through the core message renderer to convert a JSON character string in the message content into attributes required by the component, wherein the attributes comprise all data required by the component rendering;

The standard interaction processor is acquired through the core message renderer, the interaction processor is used for processing interaction events in the message assembly, and the core message renderer transmits the interaction processor so as to decouple interaction between the message assembly and the message rendering subsystem;

B8, rendering the message component by the core message renderer by using the converted attribute and the interaction processor to generate a message interface element visible to a user;

The component interaction flow comprises the steps that a rendered message component contains interaction elements, and when a user interacts with the interaction elements, the message component calls a corresponding interaction method on an input interaction processor, so that interaction logic defined by an application is triggered;

and B10, ending, namely ending the dynamic message rendering flow when the message component is successfully rendered and the user completes the interaction with the message component or no interaction occurs, and waiting for receiving the next message data by the message rendering subsystem to start a new dynamic message rendering sub-method flow.

7. The method of claim 5, wherein the pluggable input area management sub-method comprises:

The user selects to switch the user characteristics through the user interface module in the application layer;

C2, obtaining a feature definition, namely receiving a request of switching the feature by a user through the feature manager, retrieving a feature definition of a new feature from the feature registry, wherein the feature definition comprises an input plugin list which needs to be activated by the feature,

Notifying a plug-in manager, namely notifying an input plug-in list to be activated to the plug-in manager through the characteristic manager;

querying a plug-in registry by the plug-in manager according to the received input plug-in list to acquire definition and loading information of each plug-in;

the plug-in codes are asynchronously loaded, namely if the plug-in codes are not loaded into the memory, the corresponding plug-in codes are asynchronously loaded through the plug-in manager;

The plug-in is instantiated, namely a plug-in object is instantiated through the plug-in manager, a corresponding onLoad method is called, and a plug-in context module containing an API is transmitted;

C7, acquiring a UI, namely calling a UI generation method of a plug-in through the plug-in manager, requiring the plug-in to generate a UI element, and returning the UI element by the plug-in through the UI generation method so as to render in an input area;

C8, rendering the plug-in UI to a slot, wherein the UI elements generated by the plug-in are rendered into a predefined slot through the input area core component, the slot is reserved in the input area and used for displaying the position of the plug-in UI, and the UI elements of the plug-in are displayed to a user through the slot so as to interact with the user;

C9, the user interacts with the plug-in UI, wherein the user interacts with the plug-in UI elements rendered in the input area;

The plug-in processes interaction, wherein the plug-in responds to the interaction operation of a user through interaction logic defined in the plug-in;

C11, informing the plug-in manager of an event related to user interaction through the input area core component in the user interaction process;

C12, the plugin manager calls a plugin, wherein when the input content changes, the plugin manager calls a onInputChange (text) method of the plugin to respond to the change of the input content;

c13, the user clicks the sending button after finishing input, and triggers the operation of sending the request;

C14, preparing an initial payload by an input area core, namely preparing an initial transmission load by an input area core component, wherein the transmission load at least comprises content input by a user and plug-in temporary data;

The plug-in manager calls plug-in beforeSend to modify payload, the plug-in manager calls beforeSend methods of all active plug-ins currently according to a preset sequence, and the plug-in reads information temporarily stored in the plug-in context module or through the beforeSend method and merges the information into a transmission load to serve as a final transmission load;

The input area core sends a final payload through onSend, namely after receiving the final sending load returned by the plug-in manager through the input area core component, the input area core sends the final sending load to a back-end communication layer for processing;

And C17, finishing the input area plug-in workflow, wherein the input area subsystem waits for the next interaction or characteristic switching of the user to start a new input area management sub-method flow.