Task execution method and device, electronic equipment and computer readable storage medium

Abstract

Embodiments of the present application disclose a task execution method and device, electronic equipment and computer readable storage medium, and belong to the technical field of human-computer interaction. The method comprises: obtaining user request information; performing semantic understanding on the user request information based on a target processing model to generate a target execution plan; determining at least one business capability unit based on the target execution plan; routing the target execution plan to the at least one business capability unit, and governing the execution of the at least one business capability unit through a governance layer in the process of executing the at least one business capability unit; and generating user response information based on the execution result when the at least one business capability unit is executed. In this way, by converging the originally scattered and uncontrollable execution links under a unified governance framework, the failure probability caused by parameter errors or execution abnormalities and the like can be effectively reduced, and the stability and controllability of task execution can be improved.

Description

Technical Field

[0001] This application relates to the field of human-computer interaction technology, specifically to a task execution method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] Current voice interaction systems typically employ a linear processing flow of "speech recognition → intent understanding → skill routing → execution response." The system performs semantic parsing of user input, identifies the user's intent, and then routes the input to the corresponding business module for execution.

[0003] However, as business capabilities increase and user expression becomes more complex, this architecture based on intent classification and rule matching faces problems such as insufficient stability and high failure rate. Summary of the Invention

[0004] This application provides a task execution method, apparatus, electronic device, and computer-readable storage medium, which can improve the stability and controllability of task execution.

[0005] In a first aspect, embodiments of this application provide a task execution method, including: Obtain user request information; Based on the target processing model, semantic understanding of the user request information is performed to generate a target execution plan; Based on the target execution plan, at least one business capability unit is identified; wherein, the business capability unit is an executable unit formed by encapsulating business capabilities; The target execution plan is routed to at least one business capability unit, and during the execution of at least one business capability unit, the execution of at least one business capability unit is governed by the governance layer; When at least one of the business capability units has been executed, user response information is generated based on the execution result.

[0006] Secondly, embodiments of this application provide a task execution apparatus, the apparatus comprising: The information acquisition module is used to acquire user request information; The plan generation module is used to perform semantic understanding of the user request information based on the target processing model and generate a target execution plan. A capability determination module is used to determine at least one business capability unit based on the target execution plan; wherein, the business capability unit is an executable unit formed by encapsulating business capabilities; An execution governance module is used to route the target execution plan to at least one business capability unit, and to govern the execution of at least one business capability unit through a governance layer during the execution of at least one business capability unit; The information response module is used to generate user response information based on the execution result when at least one of the business capability units has been executed.

[0007] Thirdly, embodiments of this application also provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps in the task execution method described above.

[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the task execution method described above.

[0009] Fifthly, embodiments of this application also provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations described in the embodiments of this application.

[0010] In summary, this embodiment of the application involves: acquiring user request information; performing semantic understanding on the user request information based on a target processing model to generate a target execution plan; determining at least one business capability unit based on the target execution plan; routing the target execution plan to the at least one business capability unit, and governing the execution of the at least one business capability unit through a governance layer during the execution of the at least one business capability unit; and generating user response information based on the execution result when the at least one business capability unit has been completed. This embodiment of the application, by acquiring user request information and generating a target execution plan based on a target processing model, can quickly and accurately complete semantic understanding and execution planning. Furthermore, by routing the execution plan to the encapsulated business capability units and having the execution process uniformly governed by a governance layer, it can converge scattered and uncontrollable execution links under a unified governance framework, reducing the probability of failure due to parameter errors or execution anomalies, and improving the stability and controllability of task execution. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating a task execution method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a specific embodiment of the task execution method provided in this application; Figure 3 This is a schematic diagram of the structure of a task execution device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0014] It should be noted that existing voice assistant systems typically employ a linear process of "speech recognition → natural language understanding → skill routing → execution response," and can be mainly divided into two categories.

[0015] Traditional natural language understanding solutions identify user intents through intent classification and slot filling, and then the router calls the corresponding business modules. This solution performs stably when there are few business capabilities and the scenarios are relatively fixed. However, as the number of skills increases and user expressions become more complex, a tight coupling relationship forms between intents and skills. Each new business capability often requires new intents, rules, and mapping logic, resulting in high maintenance costs.

[0016] The large language model invocation scheme replaces the traditional natural language understanding module with a large language model, allowing the model to directly select skills or tools for function invocation based on user input. This approach improves the understanding of long-tail expressions, but most existing implementations remain at the level of the large language model directly selecting functions. When a request involves multiple tools or multiple steps, simple function calls are insufficient; at the same time, relying solely on function calls is also difficult to handle complex situations such as incomplete parameters, insufficient permissions, interface timeouts, and failures of some steps.

[0017] To address the issues of insufficient stability and high failure rate in current interactive systems, this application aims to provide a task execution method. By acquiring user request information and generating a target execution plan based on a target processing model, it can quickly and accurately complete semantic understanding and execution planning. Furthermore, by routing the execution plan to encapsulated business capability units and having the execution process uniformly governed by the governance layer, it can converge the scattered and uncontrollable execution links under a unified governance framework, reduce the probability of failure due to parameter errors or execution anomalies, and improve the stability and controllability of task execution.

[0018] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the priority of the embodiments.

[0019] Figure 1 The illustration shows a schematic flowchart of a task execution method according to an embodiment of this application. The execution subject of this task execution method can be a task execution device, which can be integrated into any electronic device with data processing, network communication, and program execution functions. The electronic device can be a server or a terminal, etc.

[0020] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, network acceleration services (Content Delivery Network, CDN), as well as big data and artificial intelligence platforms.

[0021] The terminal can be a mobile phone, tablet computer, laptop computer, desktop computer, smart home device, wearable smart device, or in-vehicle computer, but is not limited to these. The terminal and server can be connected directly or indirectly through wired or wireless communication, which is not limited herein.

[0022] In this embodiment, the description will be from the perspective of a task execution device, which can be integrated into a server or terminal. To facilitate the explanation of the task execution method of this application, the following will describe the task execution device integrated into a terminal in detail, that is, the terminal will be used as the execution subject in the detailed explanation.

[0023] Reference Figure 1 The diagram shows a flowchart of a task execution method according to this application. The method may specifically include steps S101 to S105, as follows: S101: Obtain user request information.

[0024] In this embodiment, the terminal first obtains user request information. This user request information refers to the task instructions or queries submitted by the user. For example, the user request information may be a voice request input by the user on the terminal device, which is converted into text form by automatic speech recognition (ASR) technology; or it may be a text request information directly input by the user through a text input interface.

[0025] In a specific implementation scenario, a user says to a smart terminal (such as a smartphone, smart speaker, or in-vehicle terminal) "I want to listen to song A and then turn up the volume". The terminal device collects the user's voice signal through the microphone, processes it through the voice recognition engine, converts the voice signal into the text form of the user's request information "I want to listen to song A and then turn up the volume", and sends the text information to the terminal's processing end.

[0026] In another specific implementation scenario, users can also directly enter the text "Help me check today's weather and set an alarm for 8 a.m. tomorrow" in the text input box of the terminal device, and the terminal directly obtains the text information as the user's request information.

[0027] In this embodiment, after obtaining the user request information, the terminal can also perform preliminary standardization processing on the request information, such as preprocessing operations such as word segmentation, removal of invalid characters, and terminology normalization, in order to facilitate subsequent semantic understanding.

[0028] S102: Based on the target processing model, perform semantic understanding of user request information and generate a target execution plan.

[0029] In this embodiment, the terminal inputs user request information into the target processing model, which performs semantic understanding on the user request information and generates a target execution plan.

[0030] In this embodiment, the target processing model can be a pre-trained large language model. In a specific implementation, the terminal can construct prompt words containing user request information, input the constructed prompt words into the large language model, and the large language model will perform inference and output a structured execution plan.

[0031] In this embodiment, the target processing model can specifically be used to identify the task intent in the user request information, analyze the business capabilities required to complete the task, and determine the parameters required to call each business capability. Taking the user request "I want to listen to song A and then turn up the volume" as an example, the target processing model can identify two task intents through semantic understanding: ① play song "Song A"; ② turn up the volume. Based on this, the target processing model generates a structured execution plan containing two candidate business capability units, for example: candidate business capability unit A is "music playback skill", with the corresponding parameter "song name = song A"; candidate business capability unit B is "volume control skill", with the corresponding parameters "action = increase, value = 10". When generating the target execution plan, the target processing model can output a structured call plan (such as a JSON format tool call list), which includes the identification information of the candidate business capability units to be called and the initial execution parameters required for the call. For simple question-and-answer type requests (such as "How is the weather today?"), the target processing model can also directly generate a natural language response without generating an executable plan.

[0032] In this embodiment, the target execution plan refers to the structured task planning scheme generated by the target processing model based on the semantic understanding of the user request information. This target execution plan includes candidate service capability units to be invoked to complete the user request and their corresponding initial execution parameters. Candidate service capability units are capability units that the target processing model initially selects from all available service capabilities of the terminal based on the semantic understanding results, and which may be related to completing the user request.

[0033] S103: Based on the target execution plan, identify at least one business capability unit.

[0034] In this embodiment, a business capability unit refers to an executable unit formed by encapsulating business capabilities. The business capability unit is the smallest schedulable and executable business logic module in the terminal. It encapsulates specific business operations (such as device control, content retrieval, and data querying) into a unified interface, shielding the complexity of the underlying business implementation for unified invocation and management by the upper-layer system. Business capability units can include two forms: Skills and Tools. Skills encapsulate more complex business capabilities and are typically composed of one or more Tools; Tools encapsulate single-point execution capabilities.

[0035] In this implementation, the terminal determines at least one service capability unit that ultimately needs to be executed from the candidate service capability units based on the target execution plan. Each service capability unit has a unified interface definition and calling specification.

[0036] In this embodiment, after determining the service capability units, the terminal forms an executable capability call chain. Multiple service capability units can be executed sequentially (e.g., playing music first and then turning up the volume) or concurrently (e.g., querying multiple information sources simultaneously).

[0037] S104: Route the target execution plan to at least one business capability unit, and govern the execution of at least one business capability unit through the governance layer during the execution of at least one business capability unit.

[0038] In this embodiment, the terminal routes the target execution plan to the identified service capability unit and initiates the execution of the service capability unit. During the execution of the service capability unit, the terminal performs unified governance and control over the execution of the service capability unit through the governance layer.

[0039] In this embodiment, routing refers to the process of distributing call requests in the execution plan to the corresponding service capability units according to a predetermined execution order and routing rules. The terminal locates the corresponding capability implementation and establishes a call connection based on the identification information of the service capability unit.

[0040] In this embodiment, the governance layer refers to the control layer that performs unified governance during the execution of business capability units. As the engineering control center between the target processing model and the actual business execution, the governance layer is responsible for governance operations such as parameter verification, routing control, permission verification, resource monitoring, anomaly compensation, and observation recording during the invocation and execution process of business capability units.

[0041] In this implementation, the governance layer ensures that the execution process of the business capability unit is under control in terms of parameters, permissions, routing, resources, observation and exception handling through the above-mentioned multi-dimensional governance operations, and converges the governance logic that was originally scattered in various business modules into a unified governance framework.

[0042] S105: When at least one business capability unit has been executed, generate user response information based on the execution result.

[0043] In this embodiment, after all service capability units have been executed, the terminal collects the execution results of each service capability unit, generates user response information based on the execution results, and returns it to the user.

[0044] It should be noted that the execution results of a business capability unit can be returned in one go, meaning the complete result is returned all at once after the business capability unit completes all business logic; or they can be returned in stages, meaning the business capability unit generates intermediate results gradually during execution and returns them in installments. For business capability units using the staged return method, the terminal can update the task progress and intermediate result fields in the execution context each time an intermediate result is received, so that the execution context can reflect the execution progress in real time, without having to wait for all execution to be completed before making a one-time update.

[0045] In this embodiment, the user response information may include a reply in natural language (such as "Playing Song A for you, volume increased") and / or control commands for the terminal device (such as playback commands, volume adjustment commands, etc.). The terminal presents the response information to the user through voice broadcast and / or interface display, and executes the corresponding control operations.

[0046] In this embodiment, when generating user response information, the terminal can organize different response content according to the status of the execution result (success, partial success, failure, etc.). For example, when all business capability units are executed successfully, a success response is generated; when some business capability units fail but have been recovered through compensation, a response containing prompt information is generated; when a business capability unit fails and cannot be compensated, a response containing error description is generated.

[0047] The technical solution adopted in this application, by acquiring user request information and performing semantic understanding based on the target processing model to generate a target execution plan, can achieve flexible task understanding and execution planning without relying on traditional intent classifiers. By routing the execution plan to the encapsulated business capability units and having the governance layer uniformly govern the execution of the business capability units during the execution process, the originally scattered and uncontrollable execution links can be converged into a unified governance framework, effectively reducing the probability of failure caused by parameter errors or execution anomalies, and improving the stability and controllability of task execution.

[0048] In one feasible implementation, refer to Figure 2 The step in S102, which performs semantic understanding of user request information based on the target processing model and generates a target execution plan, may specifically include steps S201 to S203, as follows: S201: Standardize the user request information to obtain standardized request information.

[0049] In this embodiment, the terminal performs standardized processing on the acquired original user request information, converting it into standardized request information with a uniform format and clear structure.

[0050] It's important to note that user-requested information is typically diverse and unstructured. For example, in voice interaction scenarios, user requests originate from the output text of the speech recognition engine and may contain errors introduced by speech recognition (such as homophones or inaccurate punctuation). In text interaction scenarios, user requests may contain colloquial expressions, abbreviations, non-standard punctuation, or unnecessary filler words. Furthermore, different users may express the same thing in significantly different ways; for example, different expressions like "play a song," "play a song," or "play a piece of music" may refer to the same or similar meanings. The purpose of standardization is to converge these diverse inputs into a unified form, reducing the difficulty of subsequent semantic understanding.

[0051] In this implementation, standardization processing can specifically include one or more of the following operations: text cleaning, terminology normalization, format standardization, and invalid information filtering. Text cleaning can include: removing irrelevant characters from user request information, such as redundant spaces, special symbols, and emoticons; segmenting and dividing the text into short, easily processed units; and correcting obvious spelling errors or homophone errors. Terminology normalization maps colloquial expressions, synonyms, and abbreviations in user request information to standard terms used uniformly within the system. For example, "play a song" and "play a song" are standardized to "play music"; "turn up the volume" and "higher volume" are standardized to "increase the volume"; and "what's the weather like?" and "how's the weather?" are standardized to "weather query". Format standardization standardizes date, time, and number information in user request information into a preset standard format. For example, "tomorrow morning" and "8:00 AM tomorrow" are uniformly converted to standard time format expressions. Invalid information filtering is used to remove redundant information such as interjections and filler words from user request information that do not affect semantic understanding, such as "um," "that," and "that is to say."

[0052] In a specific implementation scenario, a user inputs "Play 'Qianli Zhiwai'" via voice. The speech recognition engine converts the speech into the text "Qianli Zhiwai". During standardization, the terminal queries a pre-set terminology dictionary or song title database. It detects that "Qianli Zhiwai" is highly similar in pronunciation to the song "Qianli Zhiwai", determines it to be a homophone error introduced by speech recognition, and corrects "Qianli Zhiwai" to "Qianli Zhiwai", completing the error correction operation.

[0053] In another specific implementation scenario, a user inputs via voice, "Um, please play that song A for me, and turn the volume up a little." The speech recognition engine converts this speech into raw user request information in text form. The terminal then standardizes this raw information: removing the interjection "um" and the repeated word "that," normalizing the colloquial expression "play it" to "play," and normalizing "turn the volume up a little" to "volume up," ultimately obtaining the standardized request information "Play song A, increase the volume."

[0054] In this embodiment, the standardized request information after standardization retains the core semantic content of the user request, while having a unified data format and terminology, providing standardized and high-quality input data for the semantic understanding of the target processing model.

[0055] S202: Obtain the associated information of the user request.

[0056] In this embodiment, the associated information refers to the background information that is related to the user's current request and can help the target processing model to more accurately perform semantic understanding and execution planning.

[0057] In this embodiment, the terminal also maintains a state layer, which is used to store and manage various state information throughout the entire execution process. The state layer can be understood as a unified state management container, whose stored content may include device status (such as the current device volume level, playback status, scene page, etc.), session status (such as session history interaction records, current session round, etc.), task progress (such as completed business capability units, current execution position, etc.), and historical execution results (such as the execution return value, intermediate results, error information, etc. of each business capability unit).

[0058] In this embodiment, the associated information can be extracted from the state layer, and this associated information can provide rich background knowledge for the semantic understanding of the target processing model. The associated information may include at least one of session history, device state, and execution context.

[0059] In this implementation, the session history can be obtained by querying the historical interaction records of the session from the state management layer based on the session identifier carried in the current request. The session history records all historical question-and-answer pairs between the user and the terminal within the same session period, including the content of the user's historical requests, the content of the terminal's historical responses, and historical execution results. For example, if the user previously asked "What songs does artist D have?" in the current session, and the terminal replied with a list of songs including "Song A", "Song B", and "Song C", these historical question-and-answer pairs are recorded in the session history. When the user's current request is "Play the first song", the terminal needs to obtain this session history to understand which song "first song" specifically refers to. The session history can be stored in the form of a dialogue list or a dialogue tree, with each record containing the speaker identifier, the content of the speech, the timestamp of the speech, and the associated execution result information.

[0060] In this embodiment, the device status can be obtained in the following way: by acquiring the current device's operating status information in real time through the communication interface with the user terminal device or by reading it from the status management layer. The device status may include: the application scenario or page the device is currently in (e.g., whether it is in a music application interface, a video playback interface, or a terminal settings interface); the device's hardware parameter status (e.g., current volume level, screen brightness, playback progress); a list of installed and available applications on the device and their supported capabilities; and hardware information such as the device's network status, battery status, and audio output device status. For example, when a user requests to increase the volume, the terminal needs to obtain the current device's volume level to determine whether to "increase the volume from 5 to 10" or "increase the volume from 8 to 10," thereby generating execution parameters that match the current device status.

[0061] In this implementation, the execution context can be obtained by reading the context information of the current execution flow from the state management layer in the following ways. The execution context may include the execution progress of the current request (e.g., which steps have been completed and which execution stage it is currently in), intermediate results generated by historical execution steps (e.g., temporary data returned after the previous round of business capability unit execution), and recorded observation information for each stage (e.g., the time consumed by each stage, returned error codes, etc.). Compared to session history, the execution context focuses more on the execution status and process data of the current request, while session history focuses more on the dialogue content interaction between the user and the terminal. The execution context can help the target processing model understand the execution progress of the current task, thereby generating an execution plan that matches the current progress.

[0062] In a specific implementation scenario, the user has previously executed the task of "playing a song by artist D," and the execution context records the list of played songs and the current playback status. When the user says "next song" in the current request, the execution context obtained by the terminal can inform the target processing model of the currently playing song information, thereby accurately identifying the specific meaning of "next song."

[0063] In another specific implementation scenario, a user performs multiple consecutive device control operations (e.g., "turn on the air conditioner" in the first round, "set to 26 degrees" in the second round, and "lower the fan speed" in the third round). The session history records the operations of the first two rounds, the device status records the current operating mode, temperature, and fan speed settings of the air conditioner, and the execution context records the task progress. After the terminal obtains this related information, the target processing model can understand that the user's request in the third round is a further refinement of control based on existing operations, rather than an independent new instruction.

[0064] S203: Input the standardized request information and related information into the target processing model, and obtain the target execution plan through the target processing model output.

[0065] In this embodiment, the terminal integrates standardized request information and acquired related information, inputs them together into the target processing model, and the target processing model performs comprehensive reasoning and outputs the target execution plan.

[0066] In this implementation, the target processing model can be a large language model, whose input consists of prompt words containing multi-dimensional information. The terminal assembles standardized request information, session history, device status, execution context, and other information into a structured input sequence according to a preset prompt word template. Upon receiving a prompt word containing all the above information, the target processing model comprehensively analyzes and infers based on its pre-trained language understanding and reasoning capabilities. The model not only understands the literal semantics of the current request but also combines session history to understand referential relationships (such as pronouns like "first song," "that," and "it"), combines device status to determine the executable conditions of business capability units, and combines execution context to understand the continuity and progress status of tasks. Through this comprehensive context-aware reasoning, the model can generate a more accurate execution plan that better reflects the user's true intent.

[0067] In this embodiment, the target processing model generates and outputs a target execution plan based on the comprehensive analysis results described above. In the case of executable requests, the target execution plan is a structured invocation plan, containing a list of candidate business capability units to be invoked and their corresponding initial execution parameters. This structured execution plan can be represented in JSON format or other structured data formats for easy parsing and execution by subsequent modules. In the case of simple question-and-answer requests (i.e., questions that can be answered without invoking business capability units), the target processing model can also directly generate a natural language response as output.

[0068] In a specific implementation scenario, the standardized request information is "Play the first song". The associated information includes the session history, which shows the user's previous inquiry "What songs does artist D have?" and the song list "Song B", "Song A", and "Song C" provided by the terminal. The device status in the associated information indicates that the device is currently in the music application interface but not in playback mode. After receiving the above information, the target processing model deduces that "the first song" refers to "Song B" in the song list. Therefore, it generates a target execution plan: call the music playback skill, with the initial execution parameter being "Song Name = Song B".

[0069] In another specific implementation scenario, the standardized request information is "turn up the volume," and the associated device status indicates that the current device's volume level is 5 (volume values ​​range from 0 to 10). Upon receiving this information, the target processing model generates a target execution plan: invoking the volume control skill with initial execution parameters of "action = increase, value = 5" (turning the volume up from 5 to 10). If the device status indicates the current volume level is 10, the model may generate a different execution plan (e.g., directly returning "volume is already at maximum" without invoking the volume control skill), thus avoiding invalid calls.

[0070] By adopting the technical solution of this application embodiment, after standardizing the user request information, the associated information such as session history, device status and execution context is obtained, and the standardized request information and associated information are jointly input into the target processing model. This enables the target processing model to fully refer to multi-dimensional background information such as dialogue history, real-time device status and task execution progress when semantically understanding, which significantly improves the accuracy and rationality of execution plan generation and avoids task misunderstanding or invalid execution due to lack of context.

[0071] In one feasible implementation, after generating user response information based on the execution result, the task execution method may further include: obtaining execution process information; updating the execution context based on the execution process information to obtain the updated execution context.

[0072] In this embodiment, execution process information refers to the collection of various types of data related to execution behavior and execution status generated during the entire task execution process corresponding to the user request. Execution process information may include at least one of the following: execution result, intermediate result, task progress, and target execution parameters of at least one business capability unit.

[0073] In this implementation, the execution result is the final output data returned after each service capability unit has completed execution. After the service capability unit has completed execution, the terminal receives the execution result data packet returned by the service capability unit through a unified interface. The data format of the execution result can be a uniformly encapsulated response object, which includes fields such as execution status code (e.g., success, failure, partial success), execution return data (which varies depending on the specific function of the service capability unit), execution time, and error information (if execution fails). Taking the volume control service capability unit as an example, the execution result returned after the execution of this service capability unit may include fields such as: execution status code (e.g., 200 indicating success), execution return data (e.g., "current volume: 10"), and execution time (e.g., "150ms"). Taking the music playback service capability unit as an example, its returned execution result may include fields such as: execution status code (e.g., 200 indicating success), execution return data (e.g., "song name: song A, artist: artist D, playback status: playing"), and execution time.

[0074] In this embodiment, intermediate results are generated during the execution of business capability units, in addition to the final execution result. Intermediate results are stage data during the execution process and may not appear in the final execution result, but they are valuable for understanding the execution process. Intermediate results can be obtained in two ways: one is that the business capability unit actively writes the intermediate results into the intermediate result cache area specified by the terminal during the execution process; the other is that the governance layer captures the intermediate data on the execution link by interception and recording during the execution process. Taking the device control scenario as an example, when performing the "increase volume" operation, the intermediate results may include: the initial volume value before execution (5), the confirmation information returned by the device after the control command is sent, and the stage feedback during the gradual adjustment of the actual volume of the device. Although these intermediate results are not all reflected in the final user response, they can be recorded in the intermediate results for subsequent traceability or debugging.

[0075] In this embodiment, task progress refers to the position and degree of completion of the currently completed execution steps within the overall task plan in the entire task execution process corresponding to the user request. In task scenarios involving multiple business capability units, the terminal needs to obtain overall task execution progress information. Task progress can be obtained by continuously updating a progress counter or progress status table during execution. Specifically, the terminal can determine the total number of steps (i.e., the total number of business capability units to be executed) before execution begins. During execution, the number of completed steps is incremented after each business capability unit is executed, and the execution status of each business capability unit is updated. When all business capability units are completed, the task progress is updated to "All Completed".

[0076] In this embodiment, the target execution parameter of the business capability unit refers to the execution parameter determined by the governance layer after being used by the business capability unit during final execution. The target execution parameter can be extracted from the parameter governance result of the governance layer before execution. After the governance layer completes all verification and completion operations on the initial parameters, it transmits the finally determined valid parameter set to the business capability unit for execution. During this transmission process, the terminal also copies the target execution parameter and records it in the execution process information. For example, the volume control parameter initially generated by the target processing model is "action = increase, value = 10", but the governance layer finds that the maximum volume value of the current device is 8 during parameter governance, so it corrects the value parameter from 10 to 8, and obtains the target execution parameter "action = increase, value = 8". The terminal records the target execution parameter in the execution process information, and at the same time records the parameter governance process information "original value = 10, corrected according to the device upper limit (8)".

[0077] In this embodiment, the terminal writes the acquired execution process information into the execution context, updates the execution context, and obtains the updated execution context.

[0078] In the specific implementation, after obtaining the execution process information, the terminal writes various types of execution process information into the corresponding field areas according to the field structure of the execution context, thus updating the execution context. Specifically, the execution result can be written to the execution record area of ​​the execution context as the "execution result" field of the corresponding business capability unit; intermediate results can be written to the "intermediate result" subfield in the execution record area of ​​the execution context. Task progress information can be written to the task progress area of ​​the execution context, updating the number of completed steps, the current execution position, and the execution status of each capability unit. Target execution parameters are written to the execution context and can be stored in the "actual execution parameters" field recorded under the corresponding business capability unit in the execution record area.

[0079] By adopting the technical solution of this application embodiment, after the business capability unit is completed, the execution process information including the execution result, intermediate result, task progress and target execution parameters is obtained, and the execution context is updated in a structured manner based on the execution process information. This enables the transfer of execution status and data between different processing links of the same request, and allows the target processing model to reuse the state information of the previous execution in multi-round continuous interaction. This effectively solves the problems of state loss and inability to continue after task interruption in multi-round interaction, thereby effectively improving the user's multi-round dialogue experience.

[0080] In one feasible implementation, the target execution plan includes at least one candidate business capability unit; the step of determining at least one business capability unit based on the target execution plan may specifically include: screening and orchestrating at least one candidate business capability unit based on capability registration information and execution context, and determining at least one business capability unit and the execution order of at least one business capability unit.

[0081] In this embodiment, candidate service capability units refer to the capability units initially selected by the target processing model from all available service capability units in the terminal based on the semantic understanding of the user request information. Candidate service capability units are a candidate list output by the target processing model when generating the target execution plan, indicating that the model believes these capability units are likely to be used to execute the current task. The target execution plan may contain one or more candidate service capability units, each corresponding to initial execution parameters generated by the model.

[0082] In this embodiment, the terminal obtains a list of candidate business capability units contained in the target execution plan, and then filters these candidate business capability units based on capability registration information and execution context, eliminating those that are not applicable, and then arranges the filtered capability units to determine the final set of business capability units and their execution order.

[0083] In this embodiment, capability registration information refers to a data set that records the metadata information of all available business capability units. Capability registration information records the basic attributes, invocation specifications, and constraints of each business capability unit. Capability registration information may include one or more of the following information for each business capability unit: capability identifier (a name or ID that uniquely identifies a capability unit), capability name (a human-readable capability name), capability description (functional description and usage scenarios), input parameter definition (name, type, whether it is required, value range, default value, etc. of each parameter), output format definition (the structure and type of the returned data), preconditions (the device and environmental conditions required to invoke the capability), permission requirements (the minimum permission level required to invoke the capability), and domain or category tag, etc.

[0084] In its implementation, the terminal first verifies the availability of each candidate service capability unit in the target execution plan based on the capability registration information. After completing the initial verification based on the capability registration information, the terminal further filters the candidate service capability units based on the execution context. Information such as device status, task progress, and session status contained in the execution context helps the terminal determine whether a candidate service capability unit is applicable in the current specific execution scenario. After filtering, the terminal orchestrates the remaining service capability units to determine their execution order. The purpose of orchestration is to organize multiple independent service capability units into an ordered, executable capability call chain, enabling tasks to be completed in a logical order.

[0085] In a specific application scenario, the target execution plan includes three candidate business capability units: "Music Playback Skill," "Volume Control Skill," and "Light Adjustment Skill." After verifying the capability registration information, all three are registered capabilities with valid parameters. Based on the device state in the execution context, the terminal detects that the current device is a smart speaker and lacks light control functionality; therefore, the "Light Adjustment Skill" is excluded. Based on the task progress in the execution context, the terminal finds that the current task is in its initial stage, with no completed steps. Based on dependency analysis, there is no dependency between the "Music Playback Skill" and the "Volume Control Skill." However, considering that the semantic order of the user request "play music and increase the volume" is that playing music comes first, followed by increasing the volume, the terminal schedules the "Music Playback Skill" as the first step and the "Volume Control Skill" as the second step, executing them sequentially.

[0086] In this embodiment, the step of executing at least one business capability unit may specifically include: calling at least one business capability unit sequentially or concurrently according to the execution order, so that at least one business capability unit performs the corresponding business operation.

[0087] In this embodiment, after completing the screening and orchestration, and determining the business capability units and their execution order, the terminal invokes at least one business capability unit according to the orchestrated execution order, initiating the corresponding business operation for each business capability unit. Specifically, the terminal sequentially traverses the business capability units to be executed according to the execution order, initiating an invocation request for each business capability unit and passing in the corresponding execution parameters. The specific form of the invocation can be a function call, a remote procedure call (RPC), an HTTP request, a message queue message, etc.

[0088] In this embodiment, when there are dependencies between service capability units or the execution context requires execution in a specific order, the terminal adopts a serial invocation method. In this method, the terminal sequentially issues an invocation request for the first service capability unit, waits for the service capability unit to complete execution and return the execution result, and then issues an invocation request for the second service capability unit, and so on, until all service capability units have been executed.

[0089] In this implementation, when there are no dependencies or resource conflicts between multiple service capability units, the terminal adopts a concurrent invocation method. In this method, the terminal simultaneously issues invocation requests for multiple service capability units, and the multiple service capability units execute in parallel without blocking each other.

[0090] By adopting the technical solution of this application embodiment, the candidate business capability units are verified based on capability registration information, and the adaptability is screened in combination with the device status, task progress and session status in the execution context. This ensures the legality and adaptability of the final executed business capability unit, effectively avoiding execution failure due to calling invalid or incompatible capabilities. Furthermore, by calling at least one business capability unit sequentially or concurrently according to the execution order, the business capability unit can execute the corresponding business operations efficiently and orderly.

[0091] In one feasible implementation, the target execution plan includes initial execution parameters corresponding to at least one candidate business capability unit; after determining at least one business capability unit based on the target execution plan, the method further includes: extracting the initial execution parameters corresponding to at least one business capability unit from the target execution plan; and performing parameter governance operations on the initial execution parameters through a governance layer to obtain the target execution parameters corresponding to at least one business capability unit.

[0092] In this embodiment, after determining the final business capability units to be executed through screening and orchestration, the terminal extracts the initial execution parameters corresponding to these business capability units from the target execution plan. The target execution plan is structured data output by the target processing model, which includes a list of identifiers for candidate business capability units and an initial execution parameter field corresponding to each candidate business capability unit. The initial execution parameters exist in the target execution plan in the form of key-value pairs. For example, for the "volume control skill", its initial execution parameters can be represented as {"action":"increase", "value":10}; for the "music playback skill", its initial execution parameters can be represented as {"song_name":"song A", "singer":"singer D"}.

[0093] In this embodiment, after extracting the initial execution parameters, the terminal performs parameter governance operations on the initial execution parameters through the governance layer. Parameter governance operations may specifically include at least one of the following: format validation, content validation, type validation, and parameter completion.

[0094] In this implementation, format validation refers to checking whether the data format of the initial execution parameters conforms to the preset format specifications. Different parameter types have different format requirements. For example, date parameters need to conform to the "YYYY-MM-DD" format, time parameters need to conform to the "HH:MM" format, email parameters need to conform to the "xxx@xxx.xxx" format, and phone numbers need to conform to a specific number format, etc. The purpose of format validation is to ensure that the parameter expression is a standardized format that the business capability unit can correctly parse, avoiding parsing failures due to format errors.

[0095] In this embodiment, content validation refers to checking whether the specific numerical content of a parameter is legal, valid, and within the allowed range. For example, whether the volume parameter value is within the device's supported range of 0-10, whether the song name exists in the music library, and whether the city name is a city supported by the terminal. Content validation can include subtypes such as value range validation, enumerated value validation, existence validation, and semantic validity validation.

[0096] In this implementation, type validation refers to checking whether the data type of a parameter is consistent with the type expected by the business capability unit. For example, if a parameter of a business capability unit is defined as an integer type (Integer), but the value of the corresponding field in the initial execution parameter is the string "5", then there is a type mismatch, and the string type needs to be converted to an integer type. The purpose of type validation is to ensure that the parameters passed to the business capability unit are correct in type, avoiding program exceptions due to type mismatch.

[0097] In this implementation, parameter completion refers to the process by which the terminal automatically supplements a missing parameter when it is missing from the initial execution parameters, based on the execution context, default values ​​in the capability registration information, or other available information sources. The purpose of parameter completion is to improve the terminal's fault tolerance and user experience, reducing execution failures caused by missing parameters or situations requiring repeated user confirmation. For example, if a user requests "play music," and the "song name" field is missing from the initial execution parameters of the "music playback skill" in the target execution plan (the user did not specify a specific song), but the session history in the execution context shows that the user previously asked "what songs does singer D have?", the governance layer completes the singer to "singer D" based on this, and further completes the song name to "song B" based on the user's historical playback preferences (songs by singer D are played most frequently in the user's historical playback records), resulting in the complete target execution parameters {"song_name":"song B", "singer":"singer D"}.

[0098] By employing the technical solution of this application embodiment, the governance layer performs parameter governance operations such as format verification, content verification, type verification, and parameter completion on the initial execution parameters generated by the target processing model before the business capability unit is called. This can transform the uncertain generation results of the large language model into standardized parameters that conform to the business capability unit calling specifications. This effectively solves the problems of non-standard format, type mismatch, invalid content, and missing fields in parameter generation of the large language model, significantly improves the success rate of the first call, reduces execution failures and repeated user confirmations caused by parameter problems, and thus effectively ensures the stability and reliability of business execution.

[0099] In one feasible implementation, the step of governing the execution of at least one business capability unit through the governance layer may specifically include: when any target business capability unit in the at least one business capability unit fails to execute, performing compensation governance on the target business capability unit, the compensation governance including at least one of the following: controlling the target business capability unit to execute a preset security action; determining the backup business capability unit corresponding to the target business capability unit and replacing the target business capability unit with the backup business capability unit; and restoring the system state to the state before the target business capability unit failed to execute according to a preset rollback strategy.

[0100] In this embodiment, the target business capability unit refers to any business capability unit that fails to execute during the execution of at least one business capability unit. In a task execution scenario containing multiple business capability units, if any business capability unit fails to complete its encapsulated business logic execution for various reasons (such as unavailable external services, abnormal parameters, offline devices, timeouts, etc.), that business capability unit becomes the target business capability unit that needs to be compensated and managed.

[0101] In this embodiment, compensation governance refers to the fault response and recovery operations uniformly executed by the governance layer when a business capability unit fails. Compensation governance guides the system to a safe, stable, or recoverable state through preset response strategies, avoiding the interruption of the entire task or abnormal system state due to partial failure. Compensation governance can include various methods such as executing safe actions, backup replacements, and state rollback.

[0102] In this embodiment, the governance layer can control the target business capability unit to execute preset security actions. A security action refers to a preset operation performed by the governance layer on the target business capability unit after it fails. The specific content of the security action varies depending on the type of business capability unit and the failure scenario, and may include resource release, state reset, operation cancellation, and exception notification. When each business capability unit is registered in the system, in addition to providing normal execution logic, it can also configure one or more security action definitions in the capability registration information. The security actions are pre-implemented within the business capability unit and are invoked by the governance layer in case of failure. In a specific application scenario, a user requests to "play music." The music playback business capability unit times out when calling the music service API, resulting in execution failure. The governance layer triggers compensation governance, controlling the music playback business capability unit to execute preset security actions: (1) release the occupied network connection resources; (2) cancel the current playback request (to prevent duplicate requests during retries); (3) write the playback failure status record to the execution context.

[0103] In this implementation, when the target service capability unit fails, the terminal can switch to a backup service capability unit to continue the task without causing the entire task to fail. A backup service capability unit refers to another service capability unit with similar or equivalent functionality to the target service capability unit. Each service capability unit, during registration, can configure one or more backup service capability unit identifiers in its metadata, indicating alternative capabilities that can be attempted when the target capability fails. In a specific application scenario, a user requests "check tomorrow's weather," and the target service capability unit is "A Weather Service Provider Skill." This capability unit fails to execute due to the temporary unavailability of A Service Provider's API interface. The governance layer triggers a backup replacement, querying the capability registration information and finding that "A Weather Service Provider Skill" has configured a backup service capability unit, "B Weather Service Provider Skill." The governance layer verifies that B Service Provider Skill is available, switches the call to B Service Provider Skill, and calls B Service Provider Skill using the city and date parameters from the user's request. B Service Provider Skill successfully returns weather information, the compensation governance is successfully completed, the user obtains the expected weather query result, and is completely unaware of the A Service Provider's interface failure.

[0104] In this implementation, when a target service capability unit fails to execute, the governance layer can restore the system state to its state before the failure according to a preset rollback strategy. The rollback strategy refers to the sequence of operations used to restore the system state to its state before the execution of the service capability unit when it fails. Specifically, before executing the service capability unit, the terminal needs to save a snapshot of the current system state so that it can be restored to that state during rollback. The state snapshot is a complete or partial copy of the system state before execution, containing all key state fields that may have been modified by the service capability unit. The system state refers to the collection of state information related to the current task in the execution process. The system state is the object of the rollback strategy, and the purpose of rollback is to restore the system state to the snapshot state before execution. In a specific application scenario, a user requests to "adjust the lights to warm mode." The lighting control service capability unit sends a mode switching command to the device during execution, but when confirming the execution result, it finds that the device returns an error (lighting mode switching failed). At this point, the business capability unit had modified the "Lighting Mode" field in the execution context (changing it from "Cool" to "Warm"), but the actual device state remained unchanged, causing an inconsistency between the execution context and the actual device state. The governance layer triggered a rollback compensation, restoring the "Lighting Mode" field in the execution context from "Warm" back to its original value of "Cool" according to the preset rollback strategy, thus re-aligning the execution context with the actual device state.

[0105] By adopting the technical solution of this application embodiment, when the business capability unit fails to execute, the governance layer controls the target business capability unit to perform a preset safety action, or automatically switches to a backup business capability unit to continue to complete the task, or restores the system state to the stable state before execution according to a preset rollback strategy. This can effectively avoid the interruption of the entire task or abnormal system state due to the failure of a single link, and significantly improve the fault tolerance, self-healing ability and execution stability of the system.

[0106] In one feasible implementation, the step of governing the execution of at least one business capability unit through the governance layer may specifically include: when an unknown, illegal, or duplicate business capability unit call is detected, a routing governance operation is performed, which includes: rejecting the call or redirecting the call to a preset business capability unit; and / or, during the execution of at least one business capability unit, an observation governance operation is performed, which includes: recording the execution link identifier, the time consumed at each execution stage, the returned error code, and / or the generated intermediate results; and / or, before calling at least one business capability unit, an access control operation is performed, which includes: determining whether to allow the call to the corresponding business capability unit based on the device identifier, user identifier, and / or scenario type associated with the user request information, and intercepting the call when it is determined that the call to the corresponding business capability unit is not allowed; and / or, before or during the call to at least one business capability unit, a resource governance operation is performed, which includes: monitoring and limiting the number of execution rounds, the total timeout duration, or the resource usage quota corresponding to the user request information, and terminating the execution process corresponding to the user request information when the number of execution rounds exceeds the quantity threshold, the total timeout duration exceeds the duration threshold, or the resource usage quota exceeds the quota threshold.

[0107] In this embodiment, routing governance refers to the operation of the governance layer in uniformly managing and controlling the legality, validity, and uniqueness of call requests during the call routing process of business capability units.

[0108] In this implementation, when the governance layer receives a request to invoke a business capability unit, it first extracts the capability identifier (Skill ID or Tool ID) from the request and matches it against all registered capability identifiers in the capability registration information. If the match fails (i.e., the identifier does not exist in the capability registration information), the governance layer determines the call as an unknown call. For unknown calls, the governance layer can either directly reject the call or redirect it to a pre-set fallback business capability unit on the terminal (such as a general Q&A capability or a help / guidance capability). The fallback capability will then generate a user-friendly prompt message (such as "I do not understand the operation you want to perform; please try to describe it again"), avoiding direct error messages that could confuse the user.

[0109] In this implementation, an illegal call refers to a business capability unit call whose format, parameter structure, or calling method does not conform to the system specifications. For illegal calls, the governance layer directly rejects the illegal call request, thus preventing the illegal request from being routed to any business capability unit. Simultaneously, it records the illegal call event in the execution context and generates a secure error response to return to the user.

[0110] In this implementation, duplicate calls refer to multiple identical or highly similar calls initiated to the same business capability unit within the processing flow of the same user request. For duplicate calls, the governance layer can directly reject the duplicate call request to prevent the same capability from being executed multiple times. Simultaneously, the governance layer can redirect the call to the capability's status query interface to confirm the execution result of the first call and return the result directly to the caller, avoiding timeouts caused by call rejection.

[0111] In this embodiment, observation governance refers to the systematic recording and collection of information from each stage of the execution chain during the execution process by the governance layer. The execution chain identifier is a tracking identifier used to uniquely identify a complete user request processing flow. Through the execution chain identifier, log fragments scattered across different modules and services can be linked into a complete execution chain, enabling full-chain tracing and location. By recording key information during the execution of business capability units, observation governance provides a comprehensive data foundation for task execution analysis.

[0112] In this implementation, permission governance refers to the operation performed by the governance layer to verify permissions and control access to a call request based on device identifier, user identifier, and / or scenario type before invoking a business capability unit. Specifically, the governance layer matches the current device identifier, user identifier, and scenario type with the permission configuration in the capability registration information. If all permission matches pass, the governance layer allows the call to proceed and routes the call request to the target business capability unit. If any permission match fails, the governance layer determines that the call to the corresponding business capability unit is not allowed, immediately intercepts the call, prevents the call request from continuing to be passed to the business capability unit, generates a permission denial response (such as "You do not currently have permission to perform this operation" or "The current device does not support this function"), and records the permission denial event in the execution context.

[0113] In this implementation, resource governance refers to the operation of the governance layer monitoring and limiting the system resources consumed by a single user request before or during the invocation of a business capability unit. Specifically, at the beginning of each loop, the governance layer increments the execution round count and compares the current round count with a preset threshold (e.g., 10 rounds). When the execution round count exceeds the threshold, the governance layer determines that the execution round count of the current request has exceeded the limit, immediately terminates the execution process corresponding to the user request, and generates a message "Task execution round count exceeds limit, automatically terminated" to return to the user. During the execution of the business capability unit, the governance layer continuously monitors the total time consumption. When the cumulative total time consumption exceeds a preset duration threshold (e.g., 60 seconds), the governance layer determines that the total execution time of the current request has exceeded the limit, immediately terminates the execution process corresponding to the user request (including the currently executing business capability unit and the tasks waiting to be executed), and generates a message "Request processing timed out, please retry later" to return to the user. The governance layer can set resource consumption quota thresholds for a single user request according to system configuration (e.g., maximum allowed memory usage, maximum allowed number of external API calls, etc.). During execution, the governance layer continuously monitors the amount of resources consumed by the current request. When the resource consumption quota exceeds the preset quota threshold, the governance layer determines that the resource consumption of the current request has exceeded the limit, immediately terminates the execution process corresponding to the user request, and generates a prompt message "Request resource consumption exceeds the limit, automatically terminated" and returns it to the user. Through resource governance, it is possible to effectively prevent a single user request from consuming system resources without limit (such as the number of execution rounds, execution time, and resource quota), avoid system resource exhaustion due to malicious requests or abnormal processes, and ensure the overall availability and stability of the system.

[0114] By adopting the technical solution of this application embodiment, the governance layer performs routing governance operations, observation governance operations, permission governance operations, and resource governance operations. This can ensure the accuracy and legality of the call chain, prevent the overall availability of the system from being affected by the unlimited consumption of resources in a single request, and provide complete and traceable execution chain data for problem localization and performance optimization. It comprehensively improves the governance layer's control over the execution process of business capability units from four dimensions: permission, routing, resources, and observation.

[0115] To facilitate better implementation of the task execution method of this application, this application also provides a task execution apparatus based on the above-described task execution method. The meanings of the terms used are the same as in the task execution method described above, and specific implementation details can be found in the descriptions of the method embodiments.

[0116] Based on the same inventive concept, and referring to Figure 3 This application provides a task execution device 300, which includes: Information acquisition module 301 is used to acquire user request information; The plan generation module 302 is used to perform semantic understanding of user request information based on the target processing model and generate a target execution plan. The capability determination module 303 is used to determine at least one business capability unit based on the target execution plan; wherein, the business capability unit is an executable unit formed by encapsulating business capabilities; The execution governance module 304 is used to route the target execution plan to at least one business capability unit, and to govern the execution of at least one business capability unit through the governance layer during the execution of at least one business capability unit. The information response module 305 is used to generate user response information based on the execution result when at least one business capability unit has been executed.

[0117] In one embodiment, the planning generation module 302 includes: The standardization submodule is used to standardize user request information to obtain standardized request information; The associated information acquisition submodule is used to acquire associated information of user request information; the associated information includes at least one of session history, device status and execution context. The information input submodule is used to input standardized request information and related information into the target processing model, and the target processing model outputs the target execution plan.

[0118] In one embodiment, the task execution device 300 includes: The process information acquisition module is used to acquire execution process information; the execution process information includes at least one of the following: execution result, intermediate result, task progress, and target execution parameters of at least one business capability unit; The context update module is used to update the execution context based on the execution process information to obtain the updated execution context.

[0119] In one embodiment, the target execution plan includes at least one candidate service capability unit; the capability determination module 303 includes: The capability unit orchestration submodule is used to filter and orchestrate at least one candidate business capability unit based on capability registration information and execution context, and to determine at least one business capability unit and the execution order of at least one business capability unit. Execution governance module 304 includes: The capability invocation submodule is used to invoke at least one business capability unit sequentially or concurrently according to the execution order, so that at least one business capability unit can perform the corresponding business operation.

[0120] In one embodiment, the target execution plan includes initial execution parameters corresponding to at least one candidate service capability unit; the task execution device 300 includes: The parameter extraction module is used to extract the initial execution parameters corresponding to at least one business capability unit from the target execution plan; The parameter governance module is used to perform parameter governance operations on the initial execution parameters through the governance layer to obtain the target execution parameters corresponding to at least one business capability unit; the parameter governance operations include at least one of format validation, content validation, type validation, and parameter completion.

[0121] In one embodiment, the execution governance module 304 includes: The compensation and governance submodule is used to perform compensation and governance on the target business capability unit when any target business capability unit in at least one business capability unit fails to execute. The compensation and governance includes at least one of the following: Control the target business capability unit to execute preset security actions; Identify the backup business capability unit corresponding to the target business capability unit, and replace the target business capability unit with the backup business capability unit; The system state will be restored to the state before the target business capability unit failed to execute, according to the preset rollback strategy.

[0122] In one embodiment, the execution governance module 304 includes: The routing governance submodule is used to perform routing governance operations when unknown, illegal, or duplicate business capability unit calls are detected. These operations include: rejecting the call, or redirecting the call to a preset business capability unit; and / or... The observation and governance submodule is used to perform observation and governance operations during the execution of at least one business capability unit. These operations include: recording the execution link identifier, the time consumed at each execution stage, the returned error codes, and / or the generated intermediate results; and / or... The permission governance submodule is used to perform permission governance operations before invoking at least one business capability unit. These operations include: determining whether to allow invoking the corresponding business capability unit based on the device identifier, user identifier, and / or scenario type associated with the user request information; and intercepting the invoking if it is determined that invoking the corresponding business capability unit is not allowed; and / or... The resource governance submodule is used to perform resource governance operations before or during the invocation of at least one business capability unit. The resource governance operations include: monitoring and limiting the number of execution rounds, total timeout duration, or resource usage quota corresponding to the user request information; and terminating the execution process corresponding to the user request information when the number of execution rounds exceeds the quantity threshold, the total timeout duration exceeds the duration threshold, or the resource usage quota exceeds the quota threshold.

[0123] The technical solution adopted in this application, by acquiring user request information and performing semantic understanding based on the target processing model to generate a target execution plan, can achieve flexible task understanding and execution planning without relying on traditional intent classifiers. By routing the execution plan to the encapsulated business capability unit and having the governance layer uniformly govern the execution of the business capability unit during the execution process, the originally scattered and uncontrollable execution links can be converged into a unified governance framework, effectively reducing the probability of failure caused by parameter errors or execution anomalies, and improving the stability and controllability of task execution.

[0124] Specific limitations regarding the task execution device 300 can be found in the above description of the task execution method, and will not be repeated here. Each module in the task execution device 300 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0125] In addition, this application also provides an electronic device, such as Figure 4 As shown, it illustrates the structural diagram of the electronic device involved in this application, specifically: The electronic device may include components such as a processor 401 with one or more processing cores and a memory 402 with one or more computer-readable storage media. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 401 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 402, and by calling data stored in the memory 402, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Optionally, the processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 401.

[0126] The memory 402 can be used to store software programs and modules. The processor 401 executes various functional applications and data processing by running the software programs and modules stored in the memory 402. The memory 402 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 402 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 with access to the memory 402.

[0127] In one feasible implementation, the electronic device further includes a power supply 403 that supplies power to the various components. Preferably, the power supply 403 can be logically connected to the processor 401 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 403 may also include one or more DC or AC power supplies, recharging systems, power equipment debugging circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0128] In one feasible implementation, the electronic device may further include an input unit 404, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0129] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 401 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 402 according to the following instructions, and the processor 401 runs the applications stored in the memory 402, thereby implementing the steps in any of the task execution methods provided in the embodiments of this application.

[0130] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0131] In one feasible implementation, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the methods described in any embodiment of this application.

[0132] In one feasible implementation, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the methods described in any embodiment of this application.

[0133] In one feasible implementation, a computer program product is also proposed, comprising a computer program or instructions that, when executed by a processor, implement the methods described in any embodiment of this application.

[0134] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0135] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0136] Therefore, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor to execute the steps of any of the task execution methods provided in this application.

[0137] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0138] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0139] Since the instructions stored in the computer-readable storage medium can execute the steps of any of the task execution methods provided in this application, the beneficial effects that any of the task execution methods provided in this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0140] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes the element.

[0141] The above provides a detailed description of a task execution method, apparatus, electronic device, and computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A task execution method, characterized in that, The method includes: Obtain user request information; Based on the target processing model, semantic understanding of the user request information is performed to generate a target execution plan; Based on the target execution plan, at least one business capability unit is identified; wherein, the business capability unit is an executable unit formed by encapsulating business capabilities; The target execution plan is routed to at least one business capability unit, and during the execution of at least one business capability unit, the execution of at least one business capability unit is governed by the governance layer; When at least one of the business capability units has been executed, user response information is generated based on the execution result.

2. The task execution method according to claim 1, characterized in that, The step of semantically understanding the user request information based on the target processing model and generating a target execution plan includes: The user request information is standardized to obtain standardized request information; Obtain the associated information of the user request information; the associated information includes at least one of session history, device status, and execution context. The standardized request information and the associated information are input into the target processing model, and the target execution plan is obtained by outputting the target processing model.

3. The task execution method according to claim 2, characterized in that, After generating user response information based on the execution result, the method further includes: Obtain execution process information; the execution process information includes at least one of the following: execution result, intermediate result, task progress, and at least one target execution parameter of the business capability unit; Based on the execution process information, the execution context is updated to obtain the updated execution context.

4. The task execution method according to claim 1, characterized in that, The target execution plan includes at least one candidate business capability unit; The step of determining at least one business capability unit based on the target execution plan includes: Based on capability registration information and execution context, at least one of the candidate business capability units is screened and arranged to determine at least one of the business capability units and the execution order of at least one of the business capability units; The execution of at least one of the business capability units includes: In accordance with the execution order, at least one of the business capability units is invoked sequentially or concurrently to enable at least one of the business capability units to perform corresponding business operations.

5. The task execution method according to claim 4, characterized in that, The target execution plan includes at least one initial execution parameter corresponding to the candidate business capability unit; After determining at least one business capability unit based on the target execution plan, the method further includes: Extract at least one initial execution parameter corresponding to the business capability unit from the target execution plan; The initial execution parameters are processed by the governance layer to obtain at least one target execution parameter corresponding to the business capability unit; the parameter processing operation includes at least one of format validation, content validation, type validation, and parameter completion.

6. The task execution method according to claim 1, characterized in that, The governance of the execution of at least one of the business capability units through the governance layer includes: When any target business capability unit in at least one of the said business capability units fails to execute, compensation management is performed on the target business capability unit, and the compensation management includes at least one of the following: Control the target service capability unit to execute preset security actions; Identify the backup service capability unit corresponding to the target service capability unit, and replace the target service capability unit with the backup service capability unit; The system state will be restored to the state before the target business capability unit failed to execute, according to the preset rollback strategy.

7. The task execution method according to claim 1, characterized in that, The governance of the execution of at least one of the business capability units through the governance layer includes: Upon detecting an unknown, illegal, or duplicate service capability unit call, a routing governance operation is performed, which includes: rejecting the call, or redirecting the call to a preset service capability unit; and / or, During the execution of at least one of the aforementioned business capability units, an observation and governance operation is performed, which includes: recording the execution link identifier, the time consumed at each execution stage, the returned error codes, and / or the generated intermediate results; and / or, Before invoking at least one of the aforementioned business capability units, an access control operation is performed, the access control operation including: determining whether to allow invoking the corresponding business capability unit based on the device identifier, user identifier, and / or scenario type associated with the user request information, and intercepting the invoking when it is determined that invoking the corresponding business capability unit is not allowed; and / or, Before or during the invocation of at least one of the business capability units, a resource governance operation is performed, which includes: monitoring and limiting the number of execution rounds, total timeout duration, or resource usage quota corresponding to the user request information; and terminating the execution process corresponding to the user request information when the number of execution rounds exceeds a quantity threshold, the total timeout duration exceeds a duration threshold, or the resource usage quota exceeds a quota threshold.

8. A task execution device, characterized in that, The device includes: The information acquisition module is used to acquire user request information; The plan generation module is used to perform semantic understanding of the user request information based on the target processing model and generate a target execution plan. A capability determination module is used to determine at least one business capability unit based on the target execution plan; wherein, the business capability unit is an executable unit formed by encapsulating business capabilities; An execution governance module is used to route the target execution plan to at least one business capability unit, and to govern the execution of at least one business capability unit through a governance layer during the execution of at least one business capability unit; The information response module is used to generate user response information based on the execution result when at least one of the business capability units has been executed.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the task execution method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the task execution method as described in any one of claims 1 to 7.

Images