Interaction system, method and device based on virtual digital object and program product

Abstract

The invention discloses an interaction system, method and device based on a virtual digital object and a program product. Relates to the field of artificial intelligence, and comprises a back-end architecture used for receiving a data request through a virtual digital object, authenticating the data request, generating an operation instruction through an intelligent agent dispatching center under the condition that the data request passes the authentication, obtaining a processing result of the data request from a service system, and sending the processing result to the back-end architecture; the processing result is returned to the virtual digital object, and the service system comprises data requested by the data request; and the front-end architecture is used for calling the service plug-in to execute the operation instruction so as to obtain a processing result, and the front-end architecture adopts two deployment modes of an embedded architecture and a non-embedded architecture. Through the method and the device, the problem of low user request processing efficiency caused by difficulty in meeting diversified interaction requirements due to the fact that an MCP basic service architecture in related technologies is a universal interaction framework is solved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, and more specifically, to an interactive system, method, device, and program product based on virtual digital objects. Background Technology

[0002] In recent years, the demand for interaction between AI models and external tools has been growing. The Model Context Protocol (MCP), as a standardized interface, has emerged to address this need, aiming to achieve seamless interaction between AI models and external tools and resources, breaking down data silos and promoting cross-system interoperability. Its core architecture comprises three components: the MCP host, client, and server. It achieves bidirectional communication through the transport layer, supports dynamic tool discovery and task orchestration, and its server lifecycle covers creation, operation, and update phases. It must address security risks such as naming conflicts and installation package tampering, providing a fundamental framework for the interaction between AI applications and external systems.

[0003] Among the related technologies, (1) the basic interaction architecture based on Model Context Protocol is a general interaction framework that is not adapted to specific industry scenarios. It lacks targeted support for professional business processes, and the collaboration efficiency between general toolsets and business systems is low; the front-end interaction mode is singular, does not consider differentiated needs, and has insufficient integration flexibility; the security risk response is biased towards general scenarios, and does not combine the sensitivity of industry data to design dedicated permission management and encryption mechanisms.

[0004] (2) MCP enterprise-level security framework and zero trust implementation. This framework focuses on general enterprise security and is not optimized for the real-time and interactive characteristics of "intelligent interactive system". The multi-layer security mechanism may increase the interaction delay and is not suitable for the real-time response of equipment alarms. It does not consider the semantic conversion risk of "natural language command to tool call" in digital human interaction, which may lead to misjudgment of legitimate operation. The integration scheme with enterprise-level information system is complicated and it is difficult to directly adapt to the lightweight deployment scenario of the tower energy platform.

[0005] The MCP basic service architecture in related technologies is a general-purpose interaction framework, which is difficult to meet diverse interaction needs and leads to low efficiency in processing user requests. Currently, no effective solution has been proposed. Summary of the Invention

[0006] The main objective of this application is to provide an interactive system, method, device, and program product based on virtual digital objects, in order to solve the problem that the MCP basic service architecture in related technologies is a general interactive framework, which is difficult to meet diverse interactive needs and results in low efficiency in processing user requests.

[0007] To achieve the above objectives, according to one aspect of this application, an interactive system based on virtual digital objects is provided. The system includes: a backend architecture for receiving data requests through virtual digital objects and authenticating the data requests; if the data request is authenticated, generating operation instructions through an intelligent agent scheduling center, obtaining the processing result of the data request from a business system, and returning the processing result to the virtual digital object; wherein the operation instructions are used to process the data request to obtain the processing result; the business system includes: the data requested by the data request; and a frontend architecture for calling business plugins to execute the operation instructions to obtain the processing result; wherein the frontend architecture adopts both embedded and non-embedded architecture deployment modes.

[0008] To achieve the above objectives, according to another aspect of this application, an interaction method based on virtual digital objects is provided. The method includes: applying the virtual digital object-based interaction method to the aforementioned virtual digital object-based interaction system; the virtual digital object-based interaction method includes: receiving a data request through the virtual digital object and authenticating the data request; if the data request is successfully authenticated, generating an operation instruction through an intelligent agent scheduling center; invoking a business plugin to process the operation instruction; obtaining a processing result of the data request from the business system, wherein the business system includes: the data requested by the data request; and returning the processing result to the virtual digital object.

[0009] Further, it includes: a first processing unit, configured to receive a data request through a virtual digital object and authenticate the data request; if the data request is successfully authenticated, it generates an operation instruction through an intelligent agent scheduling center; a second processing unit, configured to call a business plugin to process the operation instruction and obtain the processing result of the data request from the business system, wherein the business system includes the data requested by the data request; and a third processing unit, configured to return the processing result to the virtual digital object.

[0010] According to another aspect of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the interactive method based on virtual digital objects.

[0011] In this application, the backend architecture receives and authenticates data requests via virtual digital objects. If the data request is successfully authenticated, an operation instruction is generated by the intelligent agent scheduling center, and the processing result of the data request is obtained from the business system. The processing result is then returned to the virtual digital object. The operation instruction is used to process the data request and obtain the processing result. The business system includes the data requested by the data request. The frontend architecture calls business plugins to execute the operation instruction to obtain the processing result. The frontend architecture employs both embedded and non-embedded deployment modes, thus solving the technical problem in related technologies where the MCP basic service architecture is a general-purpose interaction framework, making it difficult to meet diverse interaction needs and resulting in low efficiency in processing user requests. In this application, the frontend architecture uses both embedded and non-embedded deployment modes, avoiding the situation where the MCP basic service architecture in related technologies is a general-purpose interaction architecture, making it difficult to perform diverse interactions, thereby achieving the technical effect of improving the processing efficiency of user requests. Attached Figure Description

[0012] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0013] Figure 1 A hardware structure block diagram of a computer terminal for implementing an interactive method based on virtual digital objects is shown.

[0014] Figure 2 This is a flowchart of an interaction method based on virtual digital objects provided according to an embodiment of this application;

[0015] Figure 3 This is a schematic diagram of an interactive system based on virtual digital objects provided according to an embodiment of this application;

[0016] Figure 4 This is an architecture diagram of an interactive system based on virtual digital objects provided in the embodiments of this application;

[0017] Figure 5 This is a schematic diagram of the front-end architecture provided according to an embodiment of this application;

[0018] Figure 6 This is a schematic diagram of a non-embedded architecture processing flow provided according to an embodiment of this application;

[0019] Figure 7 This is a timing diagram of a non-embedded architecture provided according to embodiments of this application;

[0020] Figure 8This is a processing flowchart of an embedded architecture provided according to an embodiment of this application;

[0021] Figure 9 This is a flowchart of the relevant processing of the scheduling controller provided according to the embodiments of this application;

[0022] Figure 10 This is a timing diagram of an embedded architecture provided according to an embodiment of this application;

[0023] Figure 11 This is a schematic diagram of the backend architecture provided according to an embodiment of this application;

[0024] Figure 12 This is a schematic diagram of an interactive device based on virtual digital objects provided according to an embodiment of this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] Example 1

[0028] According to an embodiment of this application, a method embodiment of an interaction method based on virtual digital objects is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0029] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing an interactive method based on virtual digital objects is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0030] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0031] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the virtual digital object-based interaction method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned virtual digital object-based interaction method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0032] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0033] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0034] The interaction method based on virtual digital objects is applied to an interaction system based on virtual digital objects. Under the aforementioned operating environment, this application provides the following... Figure 2 The interactive method shown is based on virtual digital objects. Figure 2 This is a flowchart of an interaction method based on virtual digital objects according to Embodiment 1 of this application.

[0035] Step S201: Receive data requests through virtual digital objects and authenticate the data requests. If the data request is successfully authenticated, generate operation instructions through the intelligent agent scheduling center.

[0036] The aforementioned virtual digital object may include a digital human. In this embodiment, the user can input a question (such as "query the number of alarms for device X") through the digital human interface, and can also carry system authentication information and system_id (a collaborative identifier used to identify a specific business system or service, such as sl for the video link system). That is, the data request may include the question input by the user, and may also carry system authentication information and system identifier.

[0037] In this embodiment, data requests can be authenticated through a unified gateway. For example, the gateway can verify the request signature using a private key, and after successful verification, forward it to the video-agent (a component used for message passing).

[0038] The received data request can first be sent to the unified gateway for authentication and verification to ensure the security and legitimacy of the request source. The authentication process may include, but is not limited to: (1) User authentication: confirming whether the user making the request is an authorized user of the system; (2) System authentication: verifying whether the request comes from a pre-registered business system through identifiers such as system_id; (3) Permission check: checking whether the user has permission to perform the operation based on the user's role and request type; (4) Data integrity check: verifying the security measures such as signature and encryption in the data request to ensure that the integrity of the data is not compromised during transmission. Authentication of data requests is the key to ensuring system security and data privacy.

[0039] The authenticated data request is then processed by the intelligent agent scheduling center. Based on a DIF platform (which could be an AI scheduling or automation platform), the intelligent agent scheduling center performs in-depth analysis of the request to identify specific business scenarios and operational requirements. Then, it generates a series of operational instructions based on business logic and tool invocation rules. These instructions may include, but are not limited to: the tool name to be invoked (determined based on business requirements); tool parameters (providing specific parameters required for tool execution, such as the device ID to be queried, time range, etc.); and authentication information (containing the user's or system's authentication token to ensure the legitimacy of the tool invocation).

[0040] The aforementioned intelligent agent scheduling center is similar to an "intelligent brain," which can plan the optimal tool call path and parameters based on user requests and business rules to achieve efficient data processing and business collaboration.

[0041] Step S202: Invoke the business plugin to process the operation instructions and obtain the processing result of the data request from the business system. The business system includes the data requested by the data request.

[0042] The aforementioned business plugins may include: small application modules designed to handle a certain type of data request or operation instruction. These business plugins may include the following functions: (1) parsing operation instructions: understanding the operation instructions issued by the intelligent agent scheduling center and determining the specific tasks to be executed; (2) executing business logic: based on the requirements of the operation instructions, executing the business processing involved in the data request, such as data query, analysis, statistics, etc.; (3) calling atomic business components: if the processing of the operation instructions involves more underlying functions, the business plugin will call the pre-packaged atomic business components to complete the specific business functions. The aforementioned business system refers to the system that actually stores and processes business data.

[0043] After receiving the operation instructions generated by the intelligent agent scheduling center, the backend can use the MCP Server (Model Context Protocol Service Architecture) to call the corresponding utility methods to obtain the raw data and processing results. The frontend can then call the corresponding business plugins to execute specific business logic. After executing the business logic, the business plugins can retrieve the processing results of the data requests from the backend business system.

[0044] The processing results of data requests can include: (1) Data request forwarding: The business plugin forwards the processing instructions to the business system, requesting the execution of specific data operations. (2) Data acquisition and processing: The business system executes the data request, collects the required data, and performs necessary processing on the data to generate results that meet business requirements. (3) Result return: After processing is completed, the business system can return the processing results to the business plugin. These results may include raw data, statistical data, analysis results, etc.

[0045] After receiving the data returned by the business system, the business plugin can integrate this data to form a unified format and content in response to the initial user request.

[0046] The system utilizes an intelligent agent scheduling center for scheduling and business plugins for processing operation instructions. It retrieves processing results from the business system to ensure that user requests are accurately identified and executed, while also guaranteeing data security and smooth business process operation. This entire process embodies the layered design philosophy of the system architecture: the front end handles user interaction, the back end handles data processing and result feedback, and business plugins and the intelligent agent scheduling center facilitate the execution of business logic and the flow of data.

[0047] Step S203: Return the processing result to the virtual digital object.

[0048] When a user initiates a data request through a virtual digital object, after authentication, the request is processed layer by layer within the MCP Server architecture. This includes business scheduling at the orchestration layer and data querying and calculation at the execution layer. The final result (which may be a data summary, analysis report, operation confirmation information, etc.) is the processing result. This result can be encapsulated into a format that the virtual digital object can understand and respond to, and then returned to the digital object via the gateway through the reverse communication path of the MCP Server architecture. After receiving the processing result, the virtual digital object can generate a corresponding response based on the content of the result, presenting the processing result to the user in a user-friendly manner.

[0049] In one optional example, the process for processing user request data may include:

[0050] (1) User request initiation: The user enters a question (such as "query the number of alarms of device X", corresponding to a data request) through the digital human interface, carrying system authentication information and system_id (such as sl for the video link system);

[0051] (2) Unified gateway authentication: The gateway verifies the request signature using a private key, and forwards it to the video-agent after successful verification;

[0052] (3) Intelligent agent scheduling: The video-agent forwards the request to the intelligent interactive scheduling center (dify). The scheduling center parses the user's intent and plans the tool call sequence (such as calling the get_alarm_count_by_device_code tool (to get the number of alarm information of the device)) (corresponding to the operation command).

[0053] (4) MCP Server processing:

[0054] Tool layer: Receives instructions from the dispatch center (corresponding to the tool call sequence) and calls the corresponding tool methods (such as getDeviceCodeByName of AlarmTool (a tool for handling alarm-related content) to obtain the unique code of the device based on the device name).

[0055] Service layer: Implements business logic and connects the tool layer and API layer (e.g., calling the AlarmApi interface to query the number of alarms).

[0056] API layer (interface layer): Calls business system interfaces via HTTP (HyperText Transfer Protocol) requests to obtain raw data (such as calling the / alarm / getOrderCount interface (used to get the number of currently unprocessed alarm orders)).

[0057] (5) Result return: The MCP Server returns the processing results to the dispatch center level by level, and finally feeds them back to the user through the gateway and digital human interface.

[0058] MCP Server adopts a layered design with clearly defined responsibilities for each layer, as shown in Table 1.

[0059] Table 1

[0060]

[0061] Through the above steps, in this embodiment, the front-end architecture adopts both embedded and non-embedded architectures for deployment. This avoids the situation in related technologies where the MCP basic service architecture is a general-purpose interaction architecture, making it difficult to perform diverse interactions. This achieves the technical effect of improving the processing efficiency of user requests. Furthermore, it solves the technical problem in related technologies where the MCP basic service architecture is a general-purpose interaction framework, making it difficult to meet diverse interaction needs and resulting in low efficiency in processing user requests.

[0062] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0063] Example 2

[0064] Embodiment 2 of the present invention provides an optional interactive system based on virtual digital objects, which can be used to execute the interactive method based on virtual digital objects provided in Embodiment 1 of the present invention.

[0065] Figure 3 This is a schematic diagram of an interactive system based on virtual digital objects provided in the embodiments of this application, such as... Figure 3 As shown, it includes: front-end architecture and back-end architecture. The front-end architecture adopts two deployment modes: embedded architecture and non-embedded architecture.

[0066] The backend architecture receives and authenticates data requests via virtual digital objects. If the data request is authenticated, it generates operation instructions through the intelligent agent scheduling center, retrieves the processing results of the data request from the business system, and returns the processing results to the virtual digital object. The operation instructions are used to process the data request and obtain the processing results. The business system includes the data requested by the data request. The frontend architecture calls business plugins to execute operation instructions to obtain processing results. The frontend architecture adopts both embedded and non-embedded architecture deployment modes.

[0067] The aforementioned virtual digital objects can include digital humans. The backend architecture can adopt a layered structure of MCP Server (providing a Model Context Protocol service). The MCP Server layered structure is shown in Table 1 of Embodiment 1. The MCP Server can include: a tool layer (which can receive instructions from the dispatch center (e.g., operation instructions) and call corresponding tool methods (e.g., AlarmTool's getDeviceCodeByName); a service layer (which implements business logic and connects the tool layer and the API layer (e.g., calling AlarmApi to query the number of alarms); and an API layer (which calls the business system interface via HTTP requests to obtain raw data and processing results).

[0068] In this embodiment, data requests can first undergo an authentication process through a unified gateway. The authentication steps include, but are not limited to: (1) identity verification: confirming that the initiator of the request (user or system) has the corresponding access rights; (2) permission check: verifying whether the request contains the correct system_id and other authentication information to ensure that the request originates from an authorized business system; (3) data integrity check: ensuring the integrity of the data request during transmission and that it has not been tampered with. Authentication can guarantee the validity and security of data requests, prevent unauthorized access and attacks, and is the foundation for the stable operation of intelligent interactive systems.

[0069] Authenticated data requests can be forwarded to the intelligent agent scheduling center. The intelligent agent scheduling center, based on a DIF platform (which can be an AI scheduling platform), can parse the request, understand the user's intent, plan the order and parameters of tool calls, and generate specific operation instructions. These operation instructions can guide business plugins or components to execute specific business logic. By analyzing these operation instructions, the intelligent agent scheduling center can coordinate the collaborative work of multiple business systems and tools, handling complex business processes and data, thereby achieving efficient automation.

[0070] Based on the generated operation instructions, the business system can begin executing the business logic involved in the data request, performing data processing such as querying the database, analyzing data, and calling external APIs. After processing is complete, the business system can return the processing results, which are then integrated by the scheduling center and fed back to the unified gateway. Finally, the unified gateway transmits the results to the virtual digital object that initiated the request, completing one data request processing cycle.

[0071] The aforementioned front-end architecture can include the digital human interface and user interaction components, as well as business plugins for handling data requests. The front-end architecture supports two deployment modes: embedded and non-embedded. In the embedded architecture (i.e., iframe architecture), the digital human interface can be embedded into the system via an iframe. Event-driven communication is achieved using McpEventManager (scheduling controller), suitable for complex embedded scenarios, and supports complete event lifecycle management and multi-processor collaboration.

[0072] Non-embedded architecture (standalone deployment architecture), for example, when the digital human interface runs as a standalone application, can adopt a non-embedded architecture. It can communicate directly through a Communication Bridge without an iframe container, and is suitable for standalone business components (such as customer service ticket systems and operation management platforms), achieving efficient interaction through function calls.

[0073] In this embodiment, the front-end architecture can call the back-end business plugins to execute operation instructions and obtain processing results. Business plugins are software modules that can execute specific business logic; they can receive operation instructions from the back-end architecture, call corresponding business components or tools, and complete data processing.

[0074] The characteristics of embedded and non-embedded architectures are shown in Table 2.

[0075] Table 2

[0076]

[0077] In one alternative example, the architecture of an interactive system based on virtual digital objects is as follows: Figure 4 As shown, it includes:

[0078] (1) Application layer: includes digital human ontology and event dispatch SDK, responsible for receiving user interaction requests and passing them downstream.

[0079] (2) Application Service Layer: Authentication and authorization are completed through a unified gateway, and the intelligent agent service forwards the request to the orchestration layer.

[0080] (3) Orchestration layer: The intelligent agent scheduling center (based on dify) calls the corresponding business scenario MCPServer (such as device scenario, alarm scenario) according to the user's intention, and the MCP Server then interacts with the business system.

[0081] (4) Adaptation and scheduling layer: The environment judgment module distinguishes between iframe and non-iframe environments and adopts different scheduling paths (intelligent interactive scheduling controller SDK or document specification event reception).

[0082] (5) Execution layer: Business plugins process specific OP (Operation) instructions and call atomic business components or independent business components to complete business logic.

[0083] In this embodiment, a customized layered architecture can improve collaboration efficiency with business systems; it supports dual-mode front-end deployment (iframe embedded / non-iframe independent deployment) to adapt to diverse interaction needs in tower scenarios; and it strengthens back-end permission verification and data encryption in accordance with tower data security specifications to meet industry compliance requirements. It can also optimize the coupling between security mechanisms and interaction processes, reducing latency while ensuring security and meeting the real-time requirements of relevant equipment monitoring; it adds semantic-level security verification to reduce misjudgments in natural language commands to tool calls; and it provides a lightweight security integration solution that adapts to the tower platform's deployment environment, reducing the cost of interfacing with existing systems. Furthermore, it can integrate natural language processing and context management modules to support natural dialogue between users and the system in relevant scenarios; it designs multi-task collaboration logic based on business processes to replace signal processing-oriented collaboration modes; and it adapts to business data formats, supporting unified processing and interaction of structured and unstructured data. It can also design a parallel task scheduling mechanism to support simultaneous invocation and result aggregation of multiple business systems in the scenario; a new "fuzzy instruction parsing module" is added to automatically convert users' natural language requirements into accurate tool parameters based on the business knowledge base; and a professional knowledge graph is integrated to enhance the LLM's ability to professionally integrate results.

[0084] Optionally, the front-end architecture includes: an adaptation and scheduling layer, used to select a call path based on the runtime environment used to initiate the data request and obtain the selection result, wherein the call path includes at least one of the following: calling an embedded architecture and calling a non-embedded architecture; and an execution layer, used to call business plugins to process operation instructions in order to obtain the processing result of the data request and complete the business processing logic of the data request.

[0085] The front-end architecture can achieve efficient communication between digital humans (corresponding to virtual digital objects) and business systems through a standardized event-driven pattern. It supports two modes: iframe embedded (corresponding to embedded architecture) and non-iframe (corresponding to non-embedded architecture) independent deployment, taking into account both complex scenarios and lightweight integration needs.

[0086] The aforementioned front-end architecture can be used to connect users with the back-end architecture during the processing of data requests. The front-end architecture can include:

[0087] The adaptation and scheduling layer intelligently selects the most suitable call path based on the runtime environment in which the digital human initiates data requests through the user interface. This significantly improves system compatibility and user experience. The runtime environment involved in the call path can include the following two deployment modes: 1. Calling an embedded architecture (iframe architecture): This is typically used when the digital human needs to be embedded into another webpage or application. For example, in a complex embedded system, the digital human can exist as an iframe. If the adaptation and scheduling layer detects that the runtime environment is an iframe, it can select the path of calling the embedded architecture. In this path, the front-end can communicate with the back-end through McpEventManager (scheduling controller) using event-driven communication, utilizing the postMessage (message passing) mechanism to transmit data requests and responses. 2. Calling a non-embedded architecture (independent deployment architecture): When the digital human interface runs as an independent application, a non-embedded architecture is used. The adaptation and scheduling layer can detect that this is an independent runtime environment and select the non-embedded architecture call path. In this case, communication between the front-end and back-end can be achieved through a CommunicationBridge, which provides a more direct communication method, typically function calls, suitable for independent deployment scenarios that do not require additional encapsulation.

[0088] By determining the environment (whether it is an iframe), the adaptation and scheduling layer can automatically switch the call path, ensuring efficient communication between the front end and the back end, while also taking into account the special needs of different scenarios.

[0089] The aforementioned execution layer can call specific business plugins to process the operation instructions issued by the intelligent agent scheduling center, thereby obtaining the processing results of data requests. The execution layer is the actual execution site of the business logic, and it can perform the following operations: 1. Calling business plugins: After the adaptation and scheduling layer selects the calling path, the execution layer can call the corresponding business plugins to execute operation instructions based on an embedded or non-embedded architecture. Business plugins can be small program modules that encapsulate specific business functions, such as plugins for handling alarm analysis, device query, POI retrieval, etc. These plugins receive operation instructions from the backend and can call atomic business components or independent business components to complete the processing of data requests. 2. Processing data requests: After receiving the operation instructions, the business plugin can begin processing the data request. It can interact with the backend business system, such as querying the database, calling APIs, and executing specific algorithms, to obtain the data or information requested by the user or system. 3. Obtaining and integrating processing results: When the data request processing is complete, the business plugin can obtain the processing results from the backend. The execution layer can integrate these results, and may also need to perform some format conversion or data processing to make them meet the requirements of the front end display. Finally, the processing results are returned to the adaptation and scheduling layer, which decides how to present them to the user.

[0090] In one alternative example, the front-end architecture considers communication needs in different environments. Through an adaptation and scheduling layer, it intelligently selects the call path to ensure efficient data request interaction with the back-end architecture, whether embedded or deployed independently. The execution layer is where business plugins are executed, responsible for translating operation instructions into specific data processing actions to obtain the processing results of the requests. This layered design can flexibly handle diverse application scenarios, and through the invocation of business plugins, it achieves modularity and scalability of business logic.

[0091] Figure 5 This is a schematic diagram of the front-end architecture provided according to an embodiment of this application, such as... Figure 5 As shown, it includes: (1) Application layer: The digital human ontology interacts with the Dify platform through the event dispatch SDK to realize the transmission of user questions and the return of results. (2) Adaptation and scheduling layer: The core is the environment judgment module, which selects the iframe or non-iframe scheduling path according to the running environment. (3) Execution layer: The business plugin receives the scheduling instructions and calls the atomic components or independent components to complete the business processing (such as alarm analysis, POI query, etc.).

[0092] Optionally, the non-embedded architecture includes: a communication bridge for receiving operation instructions and forwarding the operation instructions to a first processor; and a first processor for enabling the effective execution of the operation instructions and identifying the business scenario to obtain the processing result.

[0093] The aforementioned non-embedded architecture can communicate directly using a Communication Bridge without an iframe container, making it suitable for independently deployed business components (such as customer service ticket systems and operation management platforms) and enabling efficient interaction through function calls.

[0094] Non-embedded architectures can include a communication bridge. This bridge acts as a communication hub, receiving requests from the digital human (corresponding to a virtual digital object) and forwarding them to the first processor, while simultaneously transmitting response results. The communication bridge can receive operation instructions (OP instructions) from the digital human interface. Once an OP instruction is received, the communication bridge can forward it to the subsequent processing flow, i.e., the first processor. Unlike the postMessage and event bus-based communication methods commonly used in embedded architectures, non-embedded architecture communication bridges can use function calls, directly calling the APIs or business logic functions of backend services. This reduces intermediate communication steps, improves response speed, and simplifies communication implementation complexity.

[0095] After receiving an OP instruction, the first processor can parse the instruction, determine its validity, identify the business scenario, and prepare or adjust parameters for subsequent business logic execution. For business scenario identification, the specific business scenario targeted by the current instruction can be identified based on the context of the OP instruction (such as the content of the user request, the type of associated business system, etc.), such as device management, alarm analysis, location query, etc. After determining the business scenario, the first processor can call the services of other components, read data from the database, or prepare parameter packages (tool_param) for tool calls. The first processor can forward the prepared instructions and parameters to the next processing layer or directly call the specific business component. It can also coordinate the interaction order between multiple components to ensure that the execution of the instructions conforms to logic and business rules, thereby obtaining the correct processing results.

[0096] The aforementioned first processor may include: mcp_process (processes command sequences and execution status to ensure that OP instructions are always executed) and mcp_mapping (recognizes and routes business scenarios).

[0097] In one optional example, Figure 6 This is a schematic diagram of a non-embedded architecture processing flow provided according to an embodiment of this application. The non-embedded architecture processing flow is as follows: Figure 6As shown, the process includes: (1) the digital human sends an intelligent interaction request to the CommunicationBridge; (2) the communication bridge calls the mcp_process or mcp_mapping processor; (3) the processor routes to the business component (such as the monitoring and early warning screen); (4) the business component queries and processes the business system data; and (5) the result is returned to the digital human via the bridge.

[0098] Timing diagram for non-embedded architecture as follows Figure 7 As shown, it includes: (1) Initialization registration phase: Business components register the necessary processors and custom processors through CommunicationBridge and establish mapping relationships. (2) Interaction triggering phase: After the digital human sends a request, the bridge parses the type and calls the corresponding processor (such as mcp_mapping to identify the "alarm analysis" scenario). (3) Business processing phase: Business components query and analyze business system data (such as statistics on the total number of alarms and processing progress). (4) Response feedback phase: The processing result is returned through the bridge, and the digital human generates a natural language response.

[0099] Optionally, the embedded architecture includes: a scheduling controller for distributing events in the embedded architecture and managing a second processor; and a second processor for driving business components to perform data processing based on operation instructions, obtaining processing results, and returning the processing results to a parent window, which serves as the data entry point for virtual digital objects.

[0100] Embedded architectures can utilize McpEventManager (a scheduler controller) for event-driven communication. This allows for event dispatching, processor management, and response building, ensuring smooth interaction with external business components or services. Event dispatching involves McpEventManager receiving events from the parent window (large-screen system), which can be requests initiated by the user through the digital human interface. The scheduler controller uses an event bus mechanism to listen for and dispatch these events to the appropriate processors. The event bus (…) globalEventBus allows components to communicate in the form of events, achieving loose coupling and improving the flexibility and scalability of the system.

[0101] Processor Management: McpEventManager automatically registers built-in processors (such as mcp-process) and business processors. Built-in processors handle general processes for interacting with the MCP Server, while business processors can execute tasks based on specific business scenarios. The scheduling controller manages the lifecycle of these processors, including registration, invocation, and destruction, ensuring the integrity of event processing and efficient utilization of system resources.

[0102] The second processor (business processor) can be used for alarm analysis and POI query processing. It is bound to specific business logic and can drive business components to process data based on the operation instructions passed by the scheduling controller, and finally obtain the processing results and return them to the parent window.

[0103] In this embodiment, Figure 8 This is a processing flowchart of the embedded architecture provided in the embodiments of this application, such as... Figure 8 As shown, the relevant processing flow of the embedded architecture includes: (1) The user sends a natural language request through the digital human (such as "analyze the current alarm status");

[0104] (2) The middleware parses the intent and determines that it is an iframe environment, and forwards it to McpEventManager (scheduling controller); (3) The manager schedules the corresponding business processor (corresponding to the second processor, such as the alarm analysis processor); (4) The processor calls the business component to query the business system data and process it; (5) The result is returned by the processor and middleware to generate a user-friendly reply.

[0105] Figure 9 The flowchart of the relevant processing of the scheduling controller provided in the embodiments of this application is as follows: Figure 9 As shown, the relevant processing flow of the scheduling controller includes:

[0106] Core mechanisms: (1) Processor registration: McpEventManager automatically registers the built-in mcp-process processor, and also supports the registration of business processors (such as POI query and alarm analysis); (2) Event bus: globalEventBus enables bidirectional communication between components and the manager, supporting the triggering and distribution of business events.

[0107] Process steps:

[0108] (1) The parent window (such as a large screen system) sends a request to McpEventManager (schedule controller) via postMessage (message passer);

[0109] (2) The manager (i.e., the scheduling controller) listens for business component events through the global event bus and calls the corresponding processor (e.g., Figure 9 (POI query processor, alarm analysis processor, alarm details processor in the system).

[0110] (3) The processor drives the business components to query and process business system data;

[0111] (4) The result is a standard response built by buildResponse (responder) and returned to the parent window by the manager (scheduling controller).

[0112] Figure 10 This is a timing diagram of an embedded architecture provided according to an embodiment of this application. The timing diagram of the embedded architecture is as follows: Figure 10 As shown, it includes: (1) Initialization phase: Create an McpEventManager instance, register built-in handlers and business handlers (such as analysis_alarm_stream), and bind event listeners. (2) Event triggering phase: Business components trigger events through... The emit event triggers the manager to call the corresponding handler (such as the alarm analysis handler to update alarm statistics). (3) Message sending phase: The manager builds a standard response through _buildAndSendMessage and returns it to the parent window through postMessage. (4) Destruction phase: When a component is destroyed, destroy() is called to clean up the manager's resources to avoid memory leaks.

[0113] Optionally, the backend architecture includes: an application layer for receiving data requests through a virtual digital object; an application service layer for authenticating data requests through a gateway and forwarding data requests to the orchestration layer if the data requests are authenticated; and an orchestration layer for generating operation instructions through an intelligent agent scheduling center, obtaining processing results from the business system, and returning the processing results to the virtual digital object through a gateway.

[0114] The backend architecture is the core of intelligent interaction, used to process data requests, generate operation instructions, and obtain processing results. This architecture can include: an application layer, an application service layer, and an orchestration layer. Each layer has its specific tasks and functions, working together to achieve efficient and stable data request processing.

[0115] The application layer described above is the entry point of the backend architecture. It can communicate with virtual digital objects (such as digital humans) and receive data requests sent by digital humans. These data requests can be natural language commands input by users, requests for specific business operations, or data requirements transmitted from other systems.

[0116] The aforementioned application service layer, located between the application layer and the orchestration layer, can perform secure authentication and preliminary processing of data requests. For example, it can authenticate and authorize data requests through a unified gateway, including identity verification, permission checks, data request forwarding, blocking unauthorized access and requests, and ensuring that only legitimate and secure data requests can enter the subsequent processing flow.

[0117] The orchestration layer described above is the core of the backend architecture, coordinating the interaction between the agent scheduling center and the business systems. When a data request arrives at the orchestration layer, the agent scheduling center can generate a specific sequence of operation instructions based on the content and context of the request, guiding the business systems to complete data processing. For example, the agent scheduling center can identify the intent and requirements of the data request and generate a series of operation instructions. These instructions can be used to call specific business tools (such as alarm analysis tools and device management tools), query the database, call APIs, etc., to execute the business logic involved in the data request. The orchestration layer can send the operation instructions to the business systems, which then perform data processing (such as querying, analyzing, and calculating) according to the instructions and return the processing results to the orchestration layer. The processing results are then subjected to a security check again by the orchestration layer through the unified gateway of the application service layer to ensure the security of the result transmission process. Afterward, the results are returned to the virtual digital object at the front end. It should be noted that the operation instructions generated by the agent scheduling center can be passed to the front-end architecture so that the front-end architecture can perform corresponding processing synchronously.

[0118] A schematic diagram of an optional backend architecture is shown below. Figure 11 As shown ( Figure 11 This is a schematic diagram of the backend architecture provided in the embodiments of this application, including: User layer: The digital human question interface sends requests through a unified gateway, which completes company-level security authentication (such as signature verification and permission verification). Service relay layer: The video-agent forwards requests to the intelligent interaction scheduling center (i.e., the intelligent agent scheduling center), which can plan the calling order of tools based on the dify platform. Service execution layer: Each business scenario (such as alarm scenario, device scenario) can receive scheduling instructions, call the corresponding business system interface to obtain data and return it.

[0119] Optionally, the orchestration layer also includes: an agent scheduling center, used to parse user intent in data requests, determine the call sequence of data processing tools based on user intent, obtain operation instructions, and return the processing results to the virtual digital object via a gateway, wherein the data processing tools are used to process data requests, and the call sequence includes operation instructions; and a service execution layer, used to call the data processing tools, obtain processing results from the business system, and return the processing results to the agent scheduling center.

[0120] The aforementioned orchestration layer can be used to identify user intent, plan tool call processes, and coordinate data processing in business systems. The orchestration layer may include: an agent scheduling center and a service execution layer.

[0121] The aforementioned intelligent agent scheduling center can be used to understand the user's intent in a data request and generate a sequence of tool calls accordingly, that is, the generation and scheduling of operation instructions. Specifically, the intelligent agent scheduling center can parse the user's intent in the data request. For example, it can utilize natural language processing and semantic understanding technologies to ensure that the system can accurately understand the user's requirements. Based on the parsed user intent, the intelligent agent scheduling center can determine which data processing tools (such as alarm analysis tools, device management tools, etc.) to call, and the order in which these tools are called, forming a sequence of operation instructions. The intelligent agent scheduling center generates specific operation instructions, which can then be passed to the service execution layer to guide the data processing work. The intelligent agent scheduling center can also receive the data processing results from the service execution layer, summarize and coordinate them, and ensure that the results are accurately returned to the front-end virtual digital object via the gateway, completing the feedback of the data request.

[0122] The aforementioned service execution layer can execute operation instructions, invoke data processing tools to retrieve processing results from the business system, and feed these results back to the intelligent agent scheduling center. Upon receiving operation instructions from the intelligent agent scheduling center, the service execution layer can invoke the corresponding data processing tools to process the data request. These tools may include business plugins, API interfaces, or specific database queries. After the data processing tools complete the business logic processing, the service execution layer can collect the processing results. These collected results can be returned to the intelligent agent scheduling center for further coordination, ensuring the consistency and completeness of the results before final presentation to the user.

[0123] In the backend architecture of the intelligent interaction system, the intelligent agent scheduling center of the orchestration layer and the service execution layer work closely together to complete the entire process from user intent parsing to data request processing and result feedback. The intelligent agent scheduling center can not only handle user needs but also schedule the process of tool calls, while the service execution layer executes these instructions to ensure accurate processing results are obtained from the business system. The front-end virtual digital object provides strong backup support, improving the overall user experience and system efficiency.

[0124] Optionally, the service execution layer also includes: a tool layer for calling data processing tools; a service layer connected to the tool layer and the interface layer for implementing business logic for processing data requests; and an interface layer for calling the interfaces of the business system and obtaining processing results from the business system based on user intent, wherein the business system includes the data that the user intent requires to be queried.

[0125] The aforementioned service execution layer can include: tool layer, service layer, and interface layer (api layer). Among them, the tool layer can call a series of predefined data processing tools, which can perform specific business tasks, such as data analysis, data query, decision support, etc. The tool layer is the specific executor of data processing. The service layer can be located between the tool layer and the interface layer, implementing the business logic for processing data requests, integrating the processing results of the tool layer, and forming a higher level of business output. The role of the service layer is: (1) Business logic execution: Based on the user's intent and combined with the processing results of the tool layer, execute complex business logic. Data conversion and formatting: The service layer may need to convert the data returned by the tool layer to adapt to specific business needs or the communication format of the interface layer. Error handling and status tracking: Handle abnormal situations that may occur during data processing, record the processing status, and ensure the robustness of the business process. The interface layer is the interface through which the service execution layer communicates directly with the business system. It can interact with the business system, call the interfaces provided by the business system, and thus obtain raw data or processing results. Key functions of the interface layer may include, but are not limited to: (1) Interface call: Based on the operation instructions transmitted by the intelligent agent scheduling center through the service layer, the interface layer calls the API interface in the business system to perform operations such as data query, data update, and status check; (2) Data acquisition: Obtain the data required for the data request from the business system. This data may be historical records stored in the database or the latest data generated in real time; (3) Communication protocol compliance: When communicating with the business system, the interface layer must comply with the corresponding communication protocol to ensure the secure transmission and efficient exchange of data.

[0126] In this embodiment, the result data obtained from the business system can be fed back to the service layer, further processed by the service layer, and then returned to the front end through the orchestration layer.

[0127] In one alternative example, the overall flow of the service execution layer may include:

[0128] Tool layer: Receives tasks. The tool layer receives data processing tasks from the agent scheduling center, including specific tool call instructions and related parameters. For example, it receives instructions from the agent scheduling center and calls the corresponding tool method (such as AlarmTool's getDeviceCodeByName).

[0129] Service layer: Implements business logic and connects the tool layer and API layer (such as calling AlarmAPI to query the number of alarms). For example, it can receive the processing results from the tool layer and perform more complex data transformation and business integration logic to meet user requests.

[0130] API layer: Calls business system interfaces. Based on the instructions of the service layer, it can call the interfaces in the business system to obtain or update data. For example, it can call the business system interface through an HTTP request to obtain raw data (such as calling the / alarm / getOrderCount interface).

[0131] Results feedback: The final processing result is fed back from the interface layer to the service layer, then processed by the service layer and fed back to the orchestration layer, and finally returned to the virtual digital object at the front end. For example, the MCP Server returns the processing result to the dispatch center level by level, and finally feeds it back to the user through the gateway and digital human interface.

[0132] This layered design enables automated and intelligent data processing while maintaining the flexibility and scalability of the system architecture, providing users with an efficient, accurate, and personalized service experience.

[0133] In this embodiment, front-end dual-mode adaptation reduces integration costs for diverse interaction scenarios; flexible switching between iframe and non-iframe architectures reduces customized development workload; the back-end MCP Server layered design improves business response speed; and standardized event-driven architecture reduces the probability of cross-system communication failures and lowers maintenance costs. Furthermore, by adding processor extension capabilities, the company enhances its competitiveness in the field of intelligent interaction, facilitates large-scale business replication, and improves customer satisfaction and market share.

[0134] Through this embodiment, the following effects can be achieved: (1) Improve the adaptability of industry scenarios and enhance business collaboration efficiency. Through a customized layered architecture and the design of dedicated adaptation interfaces with tower equipment monitoring systems and energy dispatching platforms, the MCP Server can directly understand professional commands such as "equipment alarm analysis" and "energy storage efficiency query". At the same time, through dynamic tool discovery and task orchestration mechanisms, it supports parallel collaboration of multiple business systems. Compared with the general MCP architecture in related technologies, the business collaboration response speed is improved, and manual intervention in cross-system data integration is reduced. (2) Optimize the flexibility of front-end interaction and reduce integration costs. It supports dual front-end modes (iframe embedded architecture and non-iframe architecture). Event-driven communication and direct function calls are implemented through McpEventManager and CommunicationBridge, respectively. This allows the system to adapt to different deployment scenarios without modifying the core architecture. Compared with the general MCP architecture in related technologies, the integration development workload of diverse interaction scenarios is reduced, and the deployment cycle is shortened. (3) Balancing security and real-time performance to meet industry compliance requirements and decouple security mechanisms from interaction processes: For device alarm commands with high real-time requirements, lightweight permission verification is adopted; for sensitive data interactions, end-to-end encryption and operation audit logs are enabled. At the same time, in conjunction with industry compliance standards, a customized data access permission matrix is ​​developed. This measure, while meeting security standards, controls the interaction latency to within 100ms, which is better than the 300ms latency of existing enterprise-level MCP frameworks. (4) Enhancing natural language interaction capabilities and improving user experience: It can integrate relevant business knowledge bases and semantic parsing modules, and can automatically convert fuzzy commands into accurate tool call parameters. At the same time, it can remember the dialogue history through a context management mechanism to achieve multi-round coherent interaction. Compared with the mechanical parameter calls of the MCP protocol in related technologies, the user command conversion rate is improved and the operation steps are reduced. (5) Supporting dynamic business expansion and reducing operation and maintenance costs: This embodiment can design a modular tool registration mechanism. When adding relevant business functions, it is only necessary to register the tool description and call logic through a standardized interface without modifying the core architecture. Meanwhile, automatic version synchronization and configuration verification ensure compatibility between the MCP Server and the existing tower system during updates. Compared to RPA or traditional MCP architectures, the new service launch cycle is shortened, and annual maintenance costs are significantly reduced.

[0135] Example 3

[0136] This application also provides an interactive device based on virtual digital objects. It should be noted that the interactive device based on virtual digital objects in this application can be used to execute the interactive method based on virtual digital objects provided in this application. The following describes the interactive device based on virtual digital objects provided in this application.

[0137] According to embodiments of this application, an apparatus for implementing the above-described interaction method based on virtual digital objects is also provided, such as... Figure 12 As shown, the device includes a first processing unit 120, a second processing unit 121, and a third processing unit 122.

[0138] In the virtual digital object-based interactive device provided in this application embodiment, a first processing unit 120 can receive data requests through the virtual digital object and authenticate the data requests. If the data request is successfully authenticated, an operation instruction is generated by the intelligent agent scheduling center. A second processing unit 121 calls the business plugin to process the operation instruction and obtains the processing result of the data request from the business system, wherein the business system includes the data requested by the data request. A third processing unit 122 returns the processing result to the virtual digital object. This solves the technical problem in related technologies where the MCP basic service architecture is a general-purpose interactive framework, which is difficult to meet diverse interactive needs, resulting in low efficiency in processing user requests. In this embodiment, the front-end architecture adopts both embedded and non-embedded architecture deployment methods, avoiding the situation in related technologies where the MCP basic service architecture is a general-purpose interactive architecture, which is difficult to perform diverse interactions, thereby achieving the technical effect of improving the processing efficiency of user requests.

[0139] It should be noted that the first processing unit 120, the second processing unit 121, and the return unit 122 mentioned above correspond to steps S201 to S203 in Embodiment 1. Each unit and the corresponding step implement the same instance and application scenario, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of the device and run in the computer terminal 10 provided in Embodiment 1.

[0140] Example 4

[0141] Embodiments of this application may provide an electronic device, which may include one or more processors, memory, storage controllers, and peripheral interfaces, wherein the peripheral interfaces are connected to a radio frequency module, an audio module, and a display.

[0142] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The processor can invoke information and applications stored in the memory through a transmission device to execute interactive methods based on virtual digital objects.

[0143] In the embodiments of this application, the front-end architecture adopts both embedded and non-embedded architectures for deployment, which avoids the situation in related technologies where the MCP basic service architecture is a general-purpose interactive architecture and is difficult to perform diverse interactions, thereby achieving the technical effect of improving the processing efficiency of user requests.

[0144] Those skilled in the art will understand that electronic devices can also be smartphones, tablets, PDAs, mobile internet devices (MIDs), PADs, and other terminal devices. Electronic devices may also include more or fewer components (such as network interfaces, display devices, etc.).

[0145] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0146] Example 5

[0147] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the interaction method based on virtual digital objects provided in Embodiment 1.

[0148] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0149] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing interactive method steps based on virtual digital objects.

[0150] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0151] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0152] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms. The units described as separate components may or may not be physically separate; the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0153] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0154] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0155] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. An interactive system based on virtual digital objects, characterized in that, include: The backend architecture is used to receive data requests through a virtual digital object and authenticate the data requests. If the data request is authenticated, an operation instruction is generated through the intelligent agent scheduling center, and the processing result of the data request is obtained from the business system. The processing result is returned to the virtual digital object. The operation instruction is used to process the data request to obtain the processing result. The business system includes the data requested by the data request. The front-end architecture is used to call business plugins to execute the operation instructions in order to obtain the processing results. The front-end architecture adopts two deployment modes: embedded architecture and non-embedded architecture.

2. The interactive system according to claim 1, characterized in that, The front-end architecture includes: An adaptation and scheduling layer is used to select a call path based on the runtime environment used to initiate the data request and obtain a selection result, wherein the call path includes at least one of the following: calling the embedded architecture and calling the non-embedded architecture; The execution layer is used to call business plugins to process the operation instructions, obtain the processing result of the data request, and complete the business processing logic of the data request.

3. The interactive system according to claim 1, characterized in that, The non-embedded architecture includes: A communication bridge is used to receive the operation instructions and forward the operation instructions to the first processor; A first processor is configured to effectively execute the operation instructions and identify the business scenario in order to obtain the processing result.

4. The interactive system according to claim 1, characterized in that, The embedded architecture includes: A scheduling controller is used to distribute events in the embedded architecture and manage the second processor; The second processor is used to drive the business components to perform data processing based on the operation instructions, obtain the processing result, and return the processing result to the parent window, which is the data entry point of the virtual digital object.

5. The interactive system according to claim 1, characterized in that, The backend architecture includes: The application layer is used to receive data requests through virtual digital objects; The application service layer is used to authenticate the data request through the gateway, and forward the data request to the orchestration layer if the data request is successfully authenticated. The orchestration layer is used to generate operation instructions through the intelligent agent scheduling center, obtain the processing results from the business system, and return the processing results to the virtual digital object through the gateway.

6. The interactive system according to claim 5, characterized in that, The orchestration layer also includes: The intelligent agent scheduling center is used to parse the user intent in the data request, determine the calling sequence of the data processing tool based on the user intent, obtain the operation instruction, and return the processing result to the virtual digital object through the gateway. The data processing tool is used to process the data request, and the calling sequence includes the operation instruction. The service execution layer is used to invoke the data processing tool, obtain the processing result from the business system, and return the processing result to the intelligent agent scheduling center.

7. The interactive system according to claim 6, characterized in that, The service execution layer also includes: The tool layer is used to invoke the data processing tools; The service layer, connected to the tool layer and interface layer, is used to implement the business logic for processing the data requests; The interface layer is used to call the interface of the business system and obtain the processing result from the business system based on the user intent. The business system includes the data that the user intent needs to query.

8. An interaction method based on virtual digital objects, characterized in that, The virtual digital object-based interaction method is applied to the virtual digital object-based interaction system according to any one of claims 1 to 7, wherein the virtual digital object-based interaction method includes: Data requests are received through virtual digital objects and the data requests are authenticated. If the data request is successfully authenticated, an operation instruction is generated through the intelligent agent scheduling center. The business plugin is invoked to process the operation instruction, and the processing result of the data request is obtained from the business system, wherein the business system includes: the data requested by the data request; The processing result is returned to the virtual digital object.

9. An interactive device based on virtual digital objects, characterized in that, include: The first processing unit is used to receive data requests through virtual digital objects, authenticate the data requests, and generate operation instructions through the intelligent agent scheduling center if the data request is successfully authenticated. The second processing unit is used to call the business plugin to process the operation instruction and obtain the processing result of the data request from the business system, wherein the business system includes: the data requested by the data request; The third processing unit is used to return the processing result to the virtual digital object.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the interaction method based on virtual digital objects as described in claim 8.

Images