Method, device, storage medium and program product for task processing
By configuring tools within skills in the task processing system, the problems of low efficiency and high complexity caused by separating the configuration of skills and tools are solved, thereby improving the convenience and stability of task processing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING ZITIAO NETWORK TECH CO LTD
- Filing Date
- 2026-04-28
- Publication Date
- 2026-06-19
AI Technical Summary
In existing task processing systems, the separation of skills and tools leads to low task execution efficiency, resource waste, and high development complexity. The increased complexity of tool selection and judgment also affects the accuracy and stability of task execution.
By pre-configuring tools into skills, tool calls can be triggered directly after a skill is selected, simplifying the operation process, reducing resource consumption, and enabling the reuse and management of functions by managing tool calls at the skill level.
It improves the convenience and accuracy of task processing, reduces resource consumption, simplifies the development process, and enhances the stability of tool selection and the consistency of task execution.
Smart Images

Figure CN122240208A_ABST
Abstract
Description
Technical Field
[0001] The examples in this paper generally relate to the field of computer science, and in particular to methods, apparatuses, devices, and computer-readable storage media for task processing. Background Technology
[0002] With the development of information technology, intelligent systems are increasingly being applied to various task processing scenarios. In these applications, the system typically completes corresponding tasks automatically based on user input and generates corresponding processing results. To improve the system's ability to handle complex tasks, task processing units are usually introduced or external resources or services are invoked during task execution. Summary of the Invention
[0003] In a first aspect, a method for task processing is provided. The method includes: presenting at least one candidate skill, each candidate skill used to support a virtual object in performing a task of a certain type; receiving a first input for selecting a first skill from the at least one candidate skill, the first skill being configured to invoke at least one tool; in response to the first input, associating the first skill with the virtual object; and in response to receiving a request for a task, presenting the execution result of the task, the task being associated with the first skill, and the execution result being obtained by the virtual object through invoking at least one tool.
[0004] In a second aspect, a method for skill configuration is provided. The method includes: presenting a first interface including a list of configuration files for a first skill, the first skill being invoked by a virtual object to support the virtual object in performing a first type of task; adding a first configuration file to the configuration file list via the first interface, the first configuration file including at least service configuration information for connecting to at least one service, the at least one service providing at least one tool; and updating the configuration of the first skill based on the first configuration file, wherein invoking the first skill triggers an invoking of at least one tool.
[0005] In a third aspect, an apparatus for task processing is provided. The apparatus includes: a presentation module configured to present at least one candidate skill, each candidate skill for supporting a virtual object in performing a task of a certain type; a receiving module configured to receive a first input for selecting a first skill from the at least one candidate skill, the first skill being configured to invoke at least one tool; an association module configured to associate the first skill with the virtual object in response to the first input; and an execution module configured to present the execution result of the task in response to receiving a request for a task, the task being associated with the first skill, and the execution result being obtained by the virtual object through invoking at least one tool.
[0006] In a fourth aspect, an apparatus for skill configuration is provided. The apparatus includes: a presentation module configured to present a first interface including a list of configuration files for a first skill, the first skill being invoked by a virtual object to support the virtual object in performing a first type of task; a configuration module configured to add a first configuration file to the configuration file list via the first interface, the first configuration file including at least service configuration information for connecting to at least one service, the at least one service being used to provide at least one tool; and an update module configured to update the configuration of the first skill based on the first configuration file, wherein an invocation of the first skill triggers an invocation of at least one tool.
[0007] In a fifth aspect, an electronic device is provided. The device includes at least one processor; and at least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor. When executed by the at least one processor, the instructions cause the device to perform the methods of the first or second aspect.
[0008] In a sixth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores computer-executable instructions that can be executed by a processor to implement the methods of the first or second aspect.
[0009] In a seventh aspect, a computer program product is provided, which is tangibly stored in a computer storage medium and includes computer-executable instructions that, when executed by a device, cause the device to perform the method of the first aspect or the second aspect.
[0010] According to various aspects of this article, task processing performance can be improved by configuring the tools used to perform tasks into skills.
[0011] It should be understood that the content described in this section is not intended to limit the key or important features of the examples in this article, nor is it intended to restrict the scope of the solution. Other features will become readily apparent from the following description. Attached Figure Description
[0012] The above and other features, advantages, and aspects of the various examples herein will become more apparent when taken in conjunction with the accompanying drawings and the following detailed description. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein: Figure 1A A schematic diagram of the example environment is shown; Figure 1B A schematic diagram of an example task processing procedure is shown; Figures 2A to 2B Example interfaces for some scenarios are shown; Figure 3AA schematic diagram illustrates an example process of invoking at least one tool based on certain scenarios; Figure 3B The diagram illustrates an example process for obtaining tool description information and tool invocation scripts under certain circumstances; Figure 4 Flowcharts of example processes for task handling are shown in some scenarios; Figure 5 Flowcharts of example processes for skills configuration are shown in some scenarios; Figure 6 A schematic block diagram of an example device for task processing in some scenarios is shown; Figure 7 Schematic block diagrams of example devices for skill configuration in several scenarios are shown; and Figure 8 A block diagram of an electronic device capable of implementing multiple illustrative scenarios is shown. Detailed Implementation
[0013] The examples in the text will now be described in more detail with reference to the accompanying drawings. While some examples are shown in the drawings, it should be understood that solutions can be implemented in various forms and should not be construed as limited to the examples presented herein. Rather, these examples are provided to provide a more thorough and complete understanding of the solutions. It should be understood that the drawings and examples in this document are for illustrative purposes only and are not intended to limit the scope of protection of the solutions.
[0014] It should be noted that the headings of any section / subsection provided herein are not restrictive. Various examples are described throughout this document, and examples of any type may be included under any section / subsection. Furthermore, examples described in any section / subsection may be combined in any way with any other examples described in the same section / subsection and / or different sections / subsections.
[0015] In the description of the examples in this document, the term "including" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an example" or "the example" should be understood as "at least one example". The term "some examples" should be understood as "at least some examples". Other explicit and implicit definitions may also be included below. The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.
[0016] The examples in this document may involve user data, data acquisition, and / or use. All of these aspects comply with relevant laws, regulations, and provisions. In the examples presented herein, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, when implementing each example, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained through appropriate means, in accordance with relevant laws and regulations. The specific methods of notification and / or authorization can vary depending on the actual situation and application scenario; the scope of the solution is not limited in this regard.
[0017] In this manual and the sample solutions, any processing of personal information will be conducted only under legal grounds (such as obtaining the consent of the data subject or being necessary for the performance of a contract) and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.
[0018] In this paper, a virtual object refers to a computational entity capable of performing information processing or interactive tasks based on a machine learning model. Virtual objects can make decisions, generate content, or perform actions based on machine learning models to achieve preset goals or complete preset tasks. Virtual objects can be implemented in software or in combination with hardware and can interact with users through a conversational interface. In some cases, examples of virtual objects may include, but are not limited to: agents, bots, chatbots, digital avatars, intelligent customer service representatives, digital assistants, etc. Alternatively, a virtual object can also be an intelligent role implemented based on a machine learning model. A "virtual object" can process user requests based on generative models (e.g., language models, multimodal models) to perform a specified type of task.
[0019] The term "machine learning model" as used in this article refers to a computational model that performs tasks by learning patterns and rules from data. Machine learning models can include, but are not limited to, neural network models, deep learning models, and large language models. In some cases, large language models are an example of machine learning models that can understand and generate natural language text and can be used to perform tasks such as task decomposition, tool invocation, and content generation.
[0020] The following describes various examples of this scheme in further detail with reference to the accompanying drawings.
[0021] Figure 1A A schematic diagram of example environment 100 is shown. (e.g.) Figure 1A As shown, example environment 100 may include electronic device 110 and electronic device 115.
[0022] In this example environment 100, electronic device 110 may run an application 120 that supports task processing. Application 120 may be any suitable type of application for task processing. User 140 may interact with application 120 via electronic device 110 and / or its attached devices. Electronic device 115 may run an application that supports skill configuration. User 145 may interact with the application for skill configuration via electronic device 115 and / or its attached devices.
[0023] exist Figure 1A In environment 100, if application 120 is active, electronic device 110 can use application 120 to present interface 150 for supporting task processing.
[0024] In some cases, electronic device 115 may present an interface 155 for supporting skill configuration.
[0025] In some scenarios, electronic device 110 communicates with server 130 to provide services to application 120. Electronic device 115 can communicate with either server 130 or electronic device 110. Electronic devices 110 and 115 can be any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, handheld computers, portable gaming terminals, VR / AR devices, personal communication system (PCS) devices, personal navigation devices, personal digital assistants (PDAs), audio / video players, digital cameras / camcorders, positioning devices, television receivers, radio receivers, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some scenarios, electronic devices 110 and 115 can also support any type of user-facing interface (such as "wearable" circuitry).
[0026] Server 130 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing 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, content delivery networks, and big data and artificial intelligence platforms. Server 130 may include, for example, computing systems / servers such as mainframes, edge computing nodes, computing devices in a cloud environment, etc. Server 130 can provide background services for applications 120 in electronic devices 110 that support task processing.
[0027] A communication connection can be established between server 130 and electronic device 110 or electronic device 115. This communication connection can be established via wired or wireless means. The communication connection can include, but is not limited to, Bluetooth, mobile network, Universal Serial Bus (USB), and Wireless Fidelity (Wi-Fi) connections. In some cases, server 130 and electronic device 110 or electronic device 115 can exchange signaling signals through their communication connection.
[0028] In some cases, electronic device 110 and electronic device 115 can be different devices, used for task processing and skill development and configuration, respectively. In other cases, electronic device 110 and electronic device 115 can be the same electronic device. Correspondingly, user 140 and user 145 can be the same user.
[0029] It should be understood that the structure and function of the various elements in environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of the scheme.
[0030] As mentioned above, with the development of artificial intelligence technology, task processing systems can understand user input through models and execute corresponding task processing tasks, thereby improving the automation level of task processing. In some scenarios, in order to complete complex tasks, task processing systems may need to call external resources or services, such as obtaining real-time data, accessing databases, or calling specific tool capabilities.
[0031] To support interaction between models and external resources and tools, a unified interaction mechanism is introduced. For example, the Model Context Protocol (MCP), as a standardized interface specification, is used to connect models with external services or data. Through this protocol, the system can translate the capabilities provided by external services into tools that the model can understand, enabling the model to call the corresponding tools to complete operations during task execution.
[0032] On the other hand, to enhance the organizational capabilities of task processing, some technical solutions can introduce task processing units, such as skills, to describe the processing logic of specific types of tasks. For example, a skill can be used to handle problems in a specific domain or to guide a model to complete a specific type of task. Task processing systems typically allow models to be configured with one or more skills to support them in performing different types of tasks.
[0033] In some scenarios, skills are functional units used to describe task processing logic, and can be configured to be invoked by the model. For example, Figure 1B A schematic diagram of an example interface 10 for task processing is shown. (For example...) Figure 1B As shown, the task processing system can respond to a trigger on control 11 by presenting a skill list 12. Through the skill list 12, the task processing system can pre-configure one or more skills for the model. During task execution, the model can select a skill relevant to the current task based on user input and execute task processing steps according to the instructions defined in that skill.
[0034] like Figure 1B As shown, skill configuration typically only involves a description of task logic and does not inherently include the ability to invoke external tools. These tools still need to be configured and provided separately. For example, the task processing system can respond to the triggering of tool configuration control 13 by displaying a tool list 14. Through tool list 14, the task processing system can pre-configure multiple services on the platform side. Upon platform startup, the task processing system can establish connections between the model and each service and obtain the functional and parameter information of all tools provided by each service. During task execution, the model can access this tool set during the inference phase and, based on user input, select and invoke the appropriate tool to complete the task.
[0035] like Figure 1B As shown, a complete task processing function typically requires the cooperation of skills and external tools. However, skills and tools are usually configured separately. For example, tools are configured uniformly at the system or platform level, while skills are configured for specific models. This separate configuration and usage makes it difficult to reuse the function as an independent and complete functional unit, reducing the efficiency of task execution.
[0036] On the other hand, since tools are configured uniformly at the system or platform level, the task processing system needs to obtain tool information from multiple services and provide it to the model in a unified manner. In this case, providing all tools to the model uniformly may result in some tools not being used in most tasks, thereby increasing unnecessary resource overhead. In addition, if the functions of the tools are similar or overlapping, the complexity of the model's judgment when selecting tools may also increase, thus affecting the accuracy of task execution.
[0037] Furthermore, for developers, since tools are typically configured uniformly at the system or platform level, developers of task processing units usually need to rely on the pre-configured tool environment on the system side when building corresponding functions. In this case, task processing units find it difficult to complete the development and testing process independently, and the development process is highly dependent on the external environment. In addition, when the task execution results are not as expected, it may be necessary to troubleshoot between the task processing unit logic and tool configuration, thereby increasing the complexity of problem localization and affecting development and debugging efficiency.
[0038] In view of this, a scheme for task processing is proposed. According to this scheme, at least one candidate skill can be presented, each candidate skill used to support a virtual object in performing a task of a certain type. Further, a first input can be received, used to select a first skill from the at least one candidate skill, the first skill being configured to invoke at least one tool. In response to the first input, the first skill can be associated with the virtual object. In response to receiving a task request, the execution result of the task can be presented, the task being associated with the first skill, and the execution result being obtained by the virtual object through invoking at least one tool.
[0039] In this way, by pre-configuring the tools used to perform tasks into skills, the corresponding tools can be directly invoked once a skill is selected, eliminating the need for separate tool selection or configuration during task execution. On one hand, compared to methods requiring separate selection of skills and tools, this simplifies the user workflow, reduces complexity, and improves the ease of task processing. On the other hand, since each skill is associated only with its required tools, virtual objects do not need to deal with the entire tool set when performing tasks, thus reducing the tool information carried in the model context. This approach reduces resource consumption and improves the accuracy and stability of the model during tool selection. Furthermore, by associating tool capabilities with skills, task processing functions can be organized and invoked on a skill-by-skill basis, facilitating function reuse and management.
[0040] The following description continues with reference to the accompanying drawings, illustrating some examples. These examples can be implemented on electronic device 110. It should be noted that the operations performed by electronic device 110 may specifically be performed by relevant applications (e.g., application 120) installed on electronic device 110. Some operations described herein with reference to electronic device 110 may require the assistance of server 130.
[0041] In some scenarios, skills can serve as functional units to support virtual objects in performing specific types of tasks. Specifically, a skill can encapsulate processing logic, invocation rules, or related resources associated with a specific type of task, enabling virtual objects to complete the corresponding task based on the skill. For example, developers can write skill descriptions, execution logic, and other related configurations to define the skill's functional scope and execution method. Furthermore, a skill can include a structured collection of multiple configuration files, organized and stored as a skill package. For instance, after completing the writing and configuration of the skill, the skill developer can encapsulate it using a compressed file format and publish it to server 130 for other users or virtual objects to obtain, load, and invoke.
[0042] In some cases, each skill can have a corresponding list of configuration files. A list of configuration files can be understood as a skill package, including multiple configuration files used to support the skill's ability to perform the corresponding type of task. For example, a list of configuration files may include: information files describing the skill (e.g., structured files indicating the skill name, version, and functional description); script files defining the skill's execution logic; and document resources for storing skill-related knowledge or reference information. Through the list of configuration files, the skill's structure, execution logic, and dependent resources can be uniformly organized and managed.
[0043] In some cases, skill developers can configure skills through a list of configuration files when writing the skill, enabling the skill to be associated with at least one tool. For example, configuration information related to tools can be defined in the skill to indicate the range of tools that the skill can call during execution, thus giving the skill the corresponding tool invocation capability when invoked by a virtual object.
[0044] In some cases, the electronic device 115 may present a first interface. The first interface may include a list of configuration files for a first skill. The first skill can be invoked by a virtual object to support the virtual object in performing a first type of task. For example, the first interface may be used to display the current list of configuration files for the first skill and support management operations on the list of configuration files, thereby configuring and adjusting the skill's execution capabilities.
[0045] In some cases, electronic device 115 can add a first configuration file to the configuration file list via the first interface. For example, in response to an operation by the skill developer on the first interface, the first configuration file can be written to the configuration file list, thereby updating the configuration of the first skill. By adding the first configuration file, the first skill can be enabled to invoke at least one tool when called by a virtual object.
[0046] In some cases, the first configuration file may be a configuration file used to describe external services and tools associated with the first skill. The first configuration file may include at least service configuration information for connecting to at least one service. At least one service is used to provide at least one tool. At least one service may be an external system or service node that provides capabilities according to a predetermined interface specification. For example, at least one service may be an MCP service used to encapsulate data access capabilities or function call capabilities.
[0047] In some scenarios, each service can be configured to provide one or more tools. Each tool can correspond to a callable functional interface or operational capability, enabling virtual objects to perform complex operations by invoking the tools. By declaring at least one service in a first configuration file, the first skill can access at least one tool provided by at least one service during execution.
[0048] In some scenarios, service configuration information can be used to describe how a primary skill accesses external services and tools during execution. Through service configuration information, a primary skill can establish a connection with at least one service upon being invoked, and further invoke at least one tool provided by that service, thereby supporting virtual objects in completing tasks related to the primary skill.
[0049] In some cases, service configuration information can indicate a description of at least one service. Each service description can represent the service's functional attributes or scope of application. For example, a service description may include a name to identify the service, descriptive information describing the service's functions, and type information indicating the service's interaction methods. By configuring service descriptions, virtual objects or related processing modules can understand the capabilities provided by the service during execution, thereby helping to determine whether to invoke the tools provided by the service.
[0050] In some cases, service configuration information can indicate connection information for at least one service. This connection information may include parameters used to establish communication with the service, such as service address information, service identification information, authentication information, or communication protocol parameters. Through this connection information, a connection can be established with at least one service during the execution of the first skill, enabling the invocation of tools provided by that service.
[0051] In some cases, service configuration information can also indicate at least one tool configured for the first skill among multiple tools provided by at least one service. The at least one tool configured for the first skill can also be referred to as the set of available tools for the first skill. Indicating the tools configured for the first skill through service configuration information can be understood as a whitelist, allowing the first skill to load or invoke tools listed in the available tool set on the server. For example, by specifying the tool set in the first configuration file, the tools provided by the service can be filtered, allowing the first skill to invoke only a subset of these tools. This method limits the scope of tool invocation for the first skill, avoiding the loading of tools unrelated to the current task, thereby reducing processing complexity and improving the accuracy of tool invocation. In some cases, if the set of available tools for the first skill is not indicated in the service configuration information, it can be assumed that the first skill can invoke and access all tools provided by the service.
[0052] In some cases, the first configuration file may also include invocation mode information. Invocation mode information can indicate the mode in which at least one tool is invoked. For example, invocation mode information can be flag information (which can be a boolean flag) used to switch between at least two different tool invocation modes.
[0053] In some situations, efficient and accurate invocation of at least one tool can be achieved based on tool description information and tool invocation scripts. Tool description information can provide details about the tool's functionality and invocation methods. Tool invocation scripts can include the specific invocation operations and parameters for calling the tool.
[0054] In some cases, tool description information can be used to describe the functional and parameter information of at least one tool. For example, tool description information may include a description of the tool's functions, input parameters, and output results. Through tool description information, virtual objects can understand the tool's functions, applicable scenarios, and invocation requirements during skill invocation, thereby selecting the appropriate tool based on task requirements.
[0055] In some scenarios, tool invocation scripts can help virtual objects determine the specific invocation operations and parameters when a tool needs to be invoked. For example, a tool invocation script may include invocation instructions for interacting with external services, enabling the virtual object to invoke at least one tool based on the script and obtain the execution results.
[0056] In some cases, during the configuration of the first skill, different invocation modes can be set to control the specific invocation process of the tool, as well as the method of obtaining the tool description information and the tool invocation script, thereby achieving a balance between development efficiency, execution performance, and control granularity. For example, in different application scenarios, different invocation modes can be selected according to the needs for the tool's dynamic adaptability or execution efficiency to optimize the overall execution effect of the skill.
[0057] In some cases, the pattern for invoking at least one tool may include a first pattern. The first pattern indicates that the tool description information and tool invocation script for at least one tool are generated based on a connection. The connection is established between a virtual object and at least one service. In this way, the model can automatically complete tool invocations based on natural language understanding, thereby improving development efficiency and system flexibility.
[0058] In some cases, the mode for invoking at least one tool may include a second mode. The second mode indicates that the tool description information and tool invocation script for at least one tool are obtained from a list of configuration files. This approach allows for more efficient tool invocation and provides developers with greater control over tool calls.
[0059] In some scenarios, electronic device 115 can update the configuration of a first skill based on a first configuration file, wherein an invocation of the first skill triggers an invocation of at least one tool. By defining configuration information related to at least one service and its tools in the first configuration file, the first skill can be enabled to invoke at least one tool when invoked by a virtual object, thereby aggregating tool invocation capabilities into the first skill.
[0060] In some cases, in response to the invocation mode information indicating a second mode, electronic device 115 can acquire tool description information and tool invocation script for at least one tool. For example, during the skill writing or configuration phase, the skill developer can manually write tool description information and corresponding tool invocation script based on the function and invocation method of the target tool, thereby clarifying the tool's usage method and invocation logic.
[0061] Furthermore, the electronic device 115 can add tool description information and tool invocation scripts to the configuration file list. For example, the electronic device 115 can store the tool description information and tool invocation scripts as resource files in the configuration file list of the first skill, thereby supporting direct retrieval and invocation of the tool from the configuration file list when the first skill is loaded or executed.
[0062] In summary, by adding configuration files for services and tools to the skill's configuration file list, a skill can be associated with at least one service and its corresponding tool. This allows for the unified organization of previously scattered task processing logic and tool invocation capabilities, thereby improving the level of skill integration.
[0063] Furthermore, the above configuration method allows the scope of at least one service to be limited to its corresponding skill. For example, services associated with a skill will only be identified and processed when the skill is loaded or activated. If the task corresponding to the skill is completed or the skill is inactive, the connections and resources associated with the service can be released. By binding the scope and lifecycle of a service to a skill, services can be prevented from remaining active globally for extended periods, thereby reducing resource consumption.
[0064] Furthermore, by limiting the range of tools that can be called upon at the skill level, it is possible to avoid loading tools unrelated to the current skill during task execution, thereby reducing the processing burden on the system and helping to improve the accuracy of tool selection and the stability of task execution. Compared to uniformly configuring tools at the platform level, this approach can effectively reduce the interference caused by the number of tools, thus improving the model's decision-making performance in the tool selection process.
[0065] Figure 2A and Figure 2B Example interfaces 200A and 200B are shown according to some scenarios. Interfaces 200A and 200B can be, for example, provided by... Figure 1A The interface shown is provided by the electronic device 110. It should be understood that the interface shown in the figures is merely an example, and various interface designs may exist in practice. The various graphic elements in the interface may have different arrangements and different visual representations, one or more of which may be omitted or replaced, and one or more other elements may also be present.
[0066] like Figure 2A As shown, interface 200A can be associated with a virtual object. A virtual object can represent an object that can interact with user 140 based on machine learning models or rule logic. It can understand user input and perform corresponding processing or actions based on the input to achieve preset goals or complete preset tasks.
[0067] In some cases, virtual objects can also take the form of intelligent systems. An intelligent system is a system capable of autonomous control based on machine learning models. For example, an intelligent system is a software object or physical entity that can make decisions and autonomously execute actions based on machine learning models to achieve preset goals or complete preset tasks. For instance, a virtual object can be an automated program that understands the user's intent and can utilize models or invoke tools to complete various types of tasks.
[0068] In some cases, interface 200A may provide an input area 215 for task input, where the user can enter a request to trigger a task and initiate the task request via the "Send" control 216. Input area 215 may support text input, such as entering text in a text input box. Input area 215 may also support voice input or indicating the user's task request by uploading attachments.
[0069] In some scenarios, electronic device 110 can present at least one candidate skill, each candidate skill used to support a virtual object in performing a type of task. Each candidate skill can encapsulate processing logic related to a type of task. For example, different candidate skills can be used to perform tasks such as information retrieval, data analysis, or content generation. By presenting at least one candidate skill, electronic device 110 can support user 140 in selecting the appropriate skill based on different task requirements, thereby enabling the virtual object to perform the corresponding type of task based on the selected skill.
[0070] In some scenarios, in response to triggering the configuration of a virtual object, the electronic device 110 may present skill description information and a selection control for at least one candidate skill. The selection control is used to receive a first input. The first input may be used to select a first skill from at least one candidate skill.
[0071] like Figure 2A As shown, electronic device 110 can present a skill list 212 in response to a trigger of skill selection control 211. Skill list 212 may include skill description information for at least one candidate skill and a selection control. User 140 can provide the electronic device 110 with a first input for selecting one or more skills through the selection control in skill list 212.
[0072] In some cases, the presentation of the skill list 212 can also be triggered in other ways. For example, the electronic device 110 can automatically present the skill list 212 based on a preset trigger identifier in the text instruction in response to receiving a text instruction entered in the input area 215, without needing to be triggered by a separate control.
[0073] In some cases, in response to a first input, electronic device 110 can associate a first skill with a virtual object. Electronic device 110 can add the first skill to the virtual object's set of available skills, enabling the virtual object to invoke the first skill to perform the corresponding task when it subsequently receives a task request related to the first skill. For example, electronic device 110 can record the identification information of the first skill in the virtual object's configuration, thus making the first skill one of the skills that the virtual object can invoke.
[0074] In some scenarios, a primary skill is configured to invoke at least one tool. For example, by establishing an association between a primary skill and at least one tool, a virtual object can invoke at least one tool corresponding to the primary skill when performing a task related to the primary skill. In this way, task processing logic and tool capabilities can be organized within the same skill, thereby reducing the need for individual tool selection during task execution and improving the consistency of task execution.
[0075] In the above scenario, the association between the first skill and at least one tool can be achieved through the aforementioned configuration process for the first skill. In other words, the configuration file list of the first skill can be configured with first configuration files related to tools, thereby enabling the first skill to trigger the invocation of at least one tool when it is invoked.
[0076] In some scenarios, electronic device 110 may, in response to receiving a task request, present the execution result of the task. The task is related to a first skill, and the execution result is obtained by a virtual object through invoking at least one tool. For example, if a task request is received, the virtual object may, based on the content of the task request and in conjunction with the description information of one or more associated skills, determine that the task is related to a first skill and trigger an invocation of the first skill. In response to the invocation of the first skill, the virtual object may perform corresponding operations according to the task processing logic defined in the first skill.
[0077] Furthermore, during the execution of the first skill, when it is necessary to call external capabilities, the virtual object can determine at least one tool that can be called based on the first configuration file contained in the first skill, and obtain the processing results related to the task by calling at least one tool.
[0078] In some scenarios, the list of configuration files for the first skill includes a first configuration file, and at least one tool is invoked based on this first configuration file. For example, the first configuration file may include service configuration information indicating at least one service. During the execution of the first skill, the virtual object can determine the services that need to be connected and the range of invoked tools based on the first configuration file, and when a tool needs to be invoked, it establishes a connection with the service and invokes the corresponding tool from the service.
[0079] In some cases, at least one tool is invoked by obtaining tool description information and a tool invocation script for at least one tool based on a first configuration file. Further, the electronic device 110 can invoke at least one tool to perform a task based on the tool description information and the tool invocation script. For example, if a virtual object determines that it needs to invoke external capabilities during the execution of a first skill, it can obtain tool description information and a tool invocation script corresponding to at least one tool based on the first configuration file. The tool description information describes the tool's function and invocation method. The tool invocation script executes the specific tool invocation operation.
[0080] As an example, Figure 3A A schematic diagram of an example process 310 for invoking at least one tool based on certain circumstances is shown. For example... Figure 3A As shown in box 311, the electronic device 110 can invoke a first skill. Specifically, after receiving a task request, the virtual object can determine the first skill related to the task based on the task content and trigger the invocation of the first skill. For example, the virtual object can enter the skill execution process by loading the initialization script corresponding to the first skill.
[0081] In box 312, electronic device 110 can parse the first configuration file. After the first skill is invoked, the virtual object can read the list of configuration files for the first skill and parse the first configuration file to obtain configuration information related to at least one tool. For example, it can obtain service configuration information, tool scope information, or invocation mode information, thereby providing a basis for subsequent tool invocations.
[0082] In box 313, electronic device 110 can register tool entry points. For example, the virtual object can determine the calling mode of at least one tool based on information obtained from the first configuration file, and establish an interface or execution entry point for calling at least one tool. For example, a tool calling interface can be generated based on tool description information, or the corresponding execution entry point can be determined based on the tool calling script, thereby enabling the virtual object to call the tool in subsequent steps.
[0083] In some cases, electronic device 110 can configure a unified tool call entry for the first skill, so that multiple tools associated with the first skill can be called through the unified tool call entry, instead of directly exposing the specific information of each tool to the model.
[0084] In box 314, electronic device 110 can determine a first tool among at least one tools to be invoked based on tool description information and a tool invocation script. Further, electronic device 110 can invoke the first tool from a first service that provides the first tool via a connection to a first service. For example, a virtual object can compare or match the functions of multiple tools based on tool description information to determine the first tool most relevant to the current task. After determining the first tool, the virtual object can establish communication with the first service that provides the first tool through the tool invocation script, send an invocation request to the first service to trigger the execution of the first tool, and receive the processing result returned by the first tool, thereby completing the corresponding task steps.
[0085] In box 315, electronic device 110 can obtain the call result. For example, the virtual object can receive the processing result returned by the first tool and complete the corresponding task steps based on the processing result, or output the processing result as part of the task execution result.
[0086] It should be noted that in the processes shown in boxes 311 to 315 above, the methods for obtaining tool description information and tool invocation scripts, as well as the timing of establishing a connection with the service, can vary depending on the invocation mode. As an example, Figure 3B A schematic diagram of example process 320 for obtaining tool description information and tool invocation scripts according to some scenarios is shown.
[0087] In box 321, electronic device 110 can parse the first configuration file to obtain configuration information related to at least one tool. For example, it can obtain service configuration information and invocation mode information. In box 322, electronic device 110 can, in response to the invocation mode information in the first configuration file indicating that the invocation mode of at least one tool is a first mode, connect to at least one service based on the first configuration file. For example, during the execution of box 312, electronic device 110 can determine the service configuration information and invocation mode information by parsing the first configuration file. In response to the invocation mode information indicating the first mode, electronic device 110 can directly establish a connection with at least one service based on the service configuration information.
[0088] In box 323, electronic device 110 can obtain functional and parameter information of at least one tool from at least one service. For example, electronic device 110 can obtain the identification information, functional description information, and input / output parameter information of each tool from at least one service through a predefined service interface or protocol method. In some cases, if the service configuration information indicates a set of available tools for the first skill, electronic device 110 can obtain only the functional and parameter information corresponding to at least one tool in the set of available tools, thereby reducing the acquisition of information about irrelevant tools.
[0089] In boxes 324 and 325, the electronic device 110 can generate tool description information and tool invocation scripts based on functional and parameter information. For example, the virtual object can automatically convert the functional and parameter information of at least one tool into structured or semi-structured tool description information for the model to read and understand. Furthermore, the virtual object can also generate a unified invocation script for calling at least one tool based on the functional and parameter information, thereby encapsulating the invocation logic for different tools.
[0090] In box 326, electronic device 110 can update the configuration of the first skill based on the generated tool description information and tool invocation script. For example, the tool description information and tool invocation script can be added as reference documents and executable resources to the configuration file list of the first skill, so that when the first skill is invoked, it can determine the tool usage method based on the tool description information and execute the corresponding tool invocation operation through the tool invocation script.
[0091] In the first mode, the virtual object can automatically complete the connection, information acquisition, and generation processes when the first skill is loaded, eliminating the need for developers to manually write tool invocation logic. This reduces the implementation complexity during skill development. Furthermore, since tool descriptions are provided to the model in document form, the model can select and invoke tools based on natural language understanding, thus improving the flexibility of tool invocation. Additionally, by limiting the scope of tools in the first configuration file, the set of tools exposed to the model can be controlled, reducing interference from irrelevant tools on model decisions and lowering context resource consumption.
[0092] In some scenarios, in response to at least one tool's invocation mode being a second mode, tool description information and tool invocation scripts are retrieved from the configuration file list of the first skill. In the second mode, the tool description information and tool invocation scripts can be pre-stored in the configuration file list of the first skill. Electronic device 110 can parse the configuration file list of the first skill to obtain configuration information related to at least one service. For example, during execution block 312, electronic device 110 can determine service configuration information and invocation mode information by parsing the first configuration file. In response to the invocation mode information indicating a second mode, electronic device 110 can simply perform configuration information reading and caching without triggering an actual service connection.
[0093] In some scenarios, during the execution of the first skill, a unified entry point can be invoked via a tool-invoking script, specifying the service identifier, tool identifier, and invocation parameters corresponding to the target tool. This allows the internal logic of the first skill to explicitly control the tool invocation process, without relying on the model's autonomous tool selection.
[0094] In some scenarios, under the first mode, if the first skill triggers a call to a tool for the first time during execution, the electronic device 110 can establish a connection with the first service providing the tool based on the configuration information in the first configuration file and execute the tool call. For subsequent calls to tools within the first service, the established connection can be reused. After the tool completes execution, its result can be returned to the execution flow of the first skill for subsequent processing or used to generate the final execution result of the task.
[0095] The above approach enables on-demand loading and invocation of at least one tool, thus avoiding resource overhead caused by unused tools. Furthermore, since the tool invocation process is controlled by the internal logic of the first skill, precise control over the timing, order, and parameters of tool invocation can be achieved, thereby improving task execution stability. Simultaneously, encapsulating tools through a unified entry point reduces the risk of the model directly invoking tools, thereby enhancing system security.
[0096] In some cases, the virtual object can receive task requests initiated by user 140. After a task request is triggered, electronic device 110 can present the user-initiated task request on interface 200B, for example, as a message 221. During task execution, the virtual object can analyze the user-initiated task request to determine task requirements, thereby generating an execution plan for the task. The task execution plan can indicate one or more subtasks required to complete the task.
[0097] During the generation of a task execution plan, a virtual object can determine the first skill relevant to the current task from at least one associated skill based on task requirements, and invoke the first skill to support task execution. For example, the virtual object can determine whether the first skill is suitable for the current task based on the skill's description information, and trigger the loading and execution of the first skill if it is determined to be suitable. By invoking the first skill, the task execution process can be based on the processing logic and tool invocation capabilities defined in the first skill.
[0098] In some cases, the virtual object can present the task execution process and results on interface 200B. After the entire task is completed, the task execution results or access points to the execution results can be presented on the interactive interface (if the execution results require navigation to other interfaces for presentation). In this way, during the task execution process, user 140 can intuitively view the virtual object's response to task requests; for example, the response could be a reply message 222 to the user's request.
[0099] In some cases, if the execution of a virtual object's task involves invoking at least one tool, the electronic device 110 can present information related to the tool invocation in message 222. For example, the triggering node, execution steps, or execution prompts for the tool invocation can be presented during task execution. In response to a user's triggering of an execution action or execution plan presented in message 222, the interface 200B can further present detailed information 223 related to the tool invocation.
[0100] In some cases, detailed information 223 may include tool capability information related to the primary skill, such as tool index information, tool function description information, parameter description information, and invocation method description. Tool capability information can be presented based on the aforementioned tool description information and tool invocation script. In this way, users can view detailed information related to tool invocation as needed during task execution, thereby improving the transparency and understandability of system interaction.
[0101] In summary, by pre-configuring the tools used to perform tasks within skills, task processing logic and tool invocation capabilities can be uniformly organized at the skill level. This allows skills to not only provide the corresponding processing logic but also possess the necessary tool invocation capabilities to complete the task. Compared to configuring task logic and tool capabilities separately, this reduces the complexity caused by multiple configurations and improves the integrity of functional organization.
[0102] On the other hand, by limiting the use of tools to within skills and linking the use of tools to the loading process of skills, tool resources can be loaded or released according to the usage of skills, thereby avoiding the continuous occupation of tool resources in the global scope.
[0103] Furthermore, in terms of development and maintenance, by incorporating tool-related configurations into the skill's configuration file list, skill developers can complete the configuration related to task processing and tool invocation in a single location, thereby reducing reliance on unified platform configurations. This approach helps simplify the development process and allows problem localization to be focused within the skill itself, thus improving development and debugging efficiency.
[0104] Figure 4 A flowchart of an example process 400 for task processing according to some scenarios is shown. Process 400 can be implemented at electronic device 110. See below for reference. Figure 1A To describe process 400.
[0105] like Figure 4 As shown, in box 410, electronic device 110 presents at least one candidate skill, each candidate skill being used to support a virtual object in performing a task of a certain type.
[0106] In box 420, electronic device 110 receives a first input for selecting a first skill from at least one candidate skill, the first skill being configured to invoke at least one tool.
[0107] In box 430, electronic device 110 responds to the first input and associates the first skill with a virtual object.
[0108] In box 440, electronic device 110, in response to receiving a request for a task, presents the execution result of the task, which is related to a first skill, and the execution result is obtained by a virtual object through invoking at least one tool.
[0109] In some cases, presenting at least one candidate skill includes: in response to triggering the configuration of a virtual object, presenting skill description information and a selection control for at least one candidate skill, the selection control being used to receive a first input.
[0110] In some cases, the list of configuration files for the first skill includes a first configuration file, and at least one tool is invoked based on the first configuration file, wherein the first configuration file includes at least service configuration information for connecting to at least one service, and at least one service is used to provide at least one tool.
[0111] In some cases, at least one tool is invoked by: obtaining tool description information and tool invocation script of at least one tool based on a first configuration file; and invoking at least one tool to perform a task based on the tool description information and tool invocation script.
[0112] In some cases, obtaining tool description information and tool invocation scripts includes: in response to at least one tool's invocation mode being a first mode, connecting to at least one service based on a first configuration file; obtaining function information and parameter information of at least one tool from at least one service; and generating tool description information and tool invocation scripts based on the function information and parameter information.
[0113] In some cases, obtaining tool description information and tool invocation scripts includes: in response to at least one tool's invocation mode being a second mode, obtaining tool description information and tool invocation scripts from a list of configuration files for the first skill.
[0114] In some cases, invoking at least one tool includes: determining a first tool among at least one tools to be invoked based on tool description information and a tool invocation script; and invoking the first tool from the first service via a connection to the first service, the first service being used to provide the first tool. In some cases, service configuration information indicates at least one of the following: a description of at least one service, access information for at least one service, or, among multiple tools provided by at least one service, a tool configured for the first skill.
[0115] Figure 5 A flowchart of an example process 500 for skill configuration based on some scenarios is shown. Process 500 can be implemented at electronic device 115. See below for reference. Figure 1A To describe process 500.
[0116] like Figure 5 As shown, in box 510, electronic device 115 presents a first interface, which includes a list of configuration files for a first skill. The first skill can be invoked by a virtual object to support the virtual object in performing a first type of task.
[0117] In box 520, electronic device 115 adds a first profile to the profile list via a first interface. The first profile includes at least service configuration information for connecting to at least one service, which provides at least one tool.
[0118] In box 530, electronic device 115 updates the configuration of a first skill based on a first profile, wherein a call to the first skill triggers a call to at least one tool.
[0119] In some cases, the first configuration file also includes invocation mode information, which indicates the mode in which at least one tool is invoked.
[0120] In some cases, the pattern includes a first pattern, which indicates that the tool description information and tool invocation script of at least one tool are generated based on a connection established between the virtual object and at least one service.
[0121] In some cases, the mode includes a second mode, which indicates that the tool description information and tool invocation script of at least one tool are obtained from a list of configuration files.
[0122] In some cases, updating the configuration of the first skill includes: in response to the invocation mode information indicating a second mode, obtaining tool description information and tool invocation script for at least one tool; and adding the tool description information and tool invocation script to the configuration file list.
[0123] In some cases, service configuration information indicates at least one of the following: a description of at least one service, connection information of at least one service, or, among multiple tools provided by at least one service, the tool configured for the first skill.
[0124] A corresponding apparatus for implementing the above methods or processes is also provided.
[0125] Figure 6A schematic structural block diagram of an example device 600 for task processing under certain circumstances is shown. Device 600 may be implemented as or included in electronic device 110. The various modules / components in device 600 may be implemented by hardware, software, firmware, or any combination thereof.
[0126] like Figure 6 As shown, the device 600 includes: a presentation module 610 configured to present at least one candidate skill, each candidate skill being used to support a virtual object in performing a task of a certain type; a receiving module 620 configured to receive a first input for selecting a first skill from the at least one candidate skill, the first skill being configured to invoke at least one tool; an association module 630 configured to associate the first skill with the virtual object in response to the first input; and an execution module 640 configured to present the execution result of a task in response to receiving a request for a task, the task being associated with the first skill, and the execution result being obtained by the virtual object by invoking at least one tool.
[0127] In some cases, the presentation module 610 is further configured to: in response to triggering the configuration of the virtual object, present skill description information of at least one candidate skill and a selection control, the selection control being used to receive a first input.
[0128] In some cases, the list of configuration files for the first skill includes a first configuration file, and at least one tool is invoked based on the first configuration file, wherein the first configuration file includes at least service configuration information for connecting to at least one service, and at least one service is used to provide at least one tool.
[0129] In some cases, at least one tool is invoked by: obtaining tool description information and tool invocation script of at least one tool based on a first configuration file; and invoking at least one tool to perform a task based on the tool description information and tool invocation script.
[0130] In some cases, the execution module 640 is further configured to: in response to the invocation mode of at least one tool being a first mode, connect to at least one service based on a first configuration file; obtain functional information and parameter information of at least one tool from at least one service; and generate tool description information and tool invocation script based on the functional information and parameter information.
[0131] In some cases, the execution module 640 is further configured to: in response to at least one tool being invoked in a second mode, retrieve tool description information and tool invocation scripts from the configuration file list of the first skill.
[0132] In some cases, the execution module 640 is further configured to: determine a first tool among at least one tools to be invoked based on tool description information and tool invocation script; and invoke the first tool from the first service via a connection to the first service, the first service being used to provide the first tool. In some cases, service configuration information indicates at least one of the following: a description of at least one service, access information for at least one service, or, among multiple tools provided by at least one service, a tool configured for the first skill.
[0133] Figure 7 A schematic structural block diagram of an example device 700 for skill configuration under certain circumstances is shown. Device 700 may be implemented as or included in electronic device 115. The various modules / components in device 700 may be implemented by hardware, software, firmware, or any combination thereof.
[0134] like Figure 7 As shown, the device 700 includes: a presentation module 710 configured to present a first interface, the first interface including a list of configuration files for a first skill, the first skill being invoked by a virtual object to support the virtual object in performing a first type of task; a configuration module 720 configured to add a first configuration file to the configuration file list via the first interface, the first configuration file including at least service configuration information for connecting to at least one service, the at least one service being used to provide at least one tool; and an update module 730 configured to update the configuration of the first skill based on the first configuration file, wherein an invocation of the first skill triggers an invocation of at least one tool.
[0135] In some cases, the first configuration file also includes invocation mode information, which indicates the mode in which at least one tool is invoked.
[0136] In some cases, the pattern includes a first pattern, which indicates that the tool description information and tool invocation script of at least one tool are generated based on a connection established between the virtual object and at least one service.
[0137] In some cases, the mode includes a second mode, which indicates that the tool description information and tool invocation script of at least one tool are obtained from a list of configuration files.
[0138] In some cases, the update module 730 is further configured to: in response to the invocation mode information indicating a second mode, obtain tool description information and tool invocation script of at least one tool; and add the tool description information and tool invocation script to the configuration file list.
[0139] In some cases, service configuration information indicates at least one of the following: a description of at least one service, connection information of at least one service, or, among multiple tools provided by at least one service, the tool configured for the first skill.
[0140] The modules included in devices 600 and 700 can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some cases, one or more modules can be implemented using software and / or firmware, such as machine-executable instructions stored on a storage medium. In addition to or as an alternative to machine-executable instructions, some or all of the units in devices 600 and 700 can be implemented at least partially by one or more hardware logic components. By way of example, and not limitation, exemplary types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Parts (ASSPs), Systems on a Chip (SOCs), Complex Programmable Logic Devices (CPLDs), and so on.
[0141] Figure 8 A block diagram of an electronic device 800 in which one or more examples may be implemented is shown. It should be understood that... Figure 8 The electronic device 800 shown is merely exemplary and should not be construed as limiting the functionality and scope of the examples described herein. Figure 8 The illustrated electronic device 800 can be used to implement electronic device 110 or electronic device 115 as discussed above.
[0142] like Figure 8 As shown, electronic device 800 is in the form of a general-purpose electronic device. Components of electronic device 800 may include, but are not limited to, one or more processing units or processors 810, memory 820, storage devices 830, one or more communication units 840, one or more input devices 850, and one or more output devices 860. Processor 810 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 820. In a multiprocessor system, multiple processors execute computer-executable instructions in parallel to improve the parallel processing capability of electronic device 800.
[0143] Electronic device 800 typically includes multiple computer storage media. Such media can be any accessible media that is accessible to electronic device 800, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 820 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof). Storage device 830 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data and can be accessed within electronic device 800.
[0144] Electronic device 800 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not explicitly stated... Figure 8 As shown, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks can be provided. In these cases, each drive can be connected to a bus (not shown) via one or more data media interfaces. Memory 820 may include computer program product 825 having one or more program modules configured to perform various methods or actions of various examples.
[0145] The communication unit 840 enables communication with other electronic devices via a communication medium. Additionally, the functionality of the components of the electronic device 800 can be implemented using a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the electronic device 800 can operate in a networked environment using logical connections to one or more other servers, networked personal computers, or another network node.
[0146] Input device 850 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 860 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 800 can also communicate with one or more external devices (not shown) via communication unit 840 as needed. External devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 800, or with any device that enables electronic device 800 to communicate with one or more other electronic devices (e.g., network card, modem, etc.). Such communication can be performed via input / output (I / O) interface (not shown).
[0147] A computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. A computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above.
[0148] The flowcharts and / or block diagrams of the methods, apparatus, devices, and computer program products referred to herein describe various aspects. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.
[0149] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.
[0150] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.
[0151] The flowcharts and block diagrams in the accompanying figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products under various scenarios. In this respect, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the figures. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0152] Various examples have been described above. The foregoing descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.
Claims
1. A method for task processing, comprising: Present at least one candidate skill, each candidate skill being used to support a virtual object in performing a task of a certain type; Receive a first input, the first input being used to select a first skill from the at least one candidate skill, the first skill being configured to invoke at least one tool; In response to the first input, the first skill is associated with the virtual object; as well as In response to receiving a task request, the execution result of the task is presented, the task being related to the first skill, and the execution result being obtained by the virtual object through invoking the at least one tool.
2. The method of claim 1, wherein presenting the at least one candidate skill comprises: In response to triggering the configuration of the virtual object, skill description information and a selection control of the at least one candidate skill are presented, the selection control being used to receive the first input.
3. The method of claim 1, wherein the list of configuration files for the first skill includes a first configuration file, and the at least one tool is invoked based on the first configuration file. The first configuration file includes at least service configuration information for connecting to at least one service, wherein the at least one service is used to provide the at least one tool.
4. The method of claim 3, wherein the at least one tool is invoked in the following manner: Based on the first configuration file, obtain the tool description information and tool invocation script of the at least one tool; and Based on the tool description information and the tool invocation script, at least one tool is invoked to perform the task.
5. The method according to claim 4, wherein obtaining the tool description information and the tool invocation script comprises: In response to the invocation mode of the at least one tool being in the first mode, at least one service is connected based on the first configuration file; Obtain the functional information and parameter information of the at least one tool from the at least one service; as well as Based on the functional information and the parameter information, the tool description information and the tool invocation script are generated.
6. The method according to claim 4, wherein obtaining the tool description information and the tool invocation script comprises: In response to the invocation mode of the at least one tool being in the second mode, the tool description information and the tool invocation script are obtained from the configuration file list of the first skill.
7. The method of claim 4, wherein invoking the at least one tool comprises: Based on the tool description information and the tool invocation script, determine the first tool among the at least one tools to be invoked; as well as The first tool is invoked from the first service via a connection to the first service, the first service being used to provide the first tool.
8. The method of claim 3, wherein the service configuration information indicates at least one of the following: Description of the at least one service. Access information for at least one service, or The tool configured for the first skill is one of the multiple tools provided by the at least one service.
9. A method for skills allocation, comprising: A first interface is presented, which includes a list of configuration files for a first skill. The first skill can be invoked by a virtual object to support the virtual object in performing a first type of task. via the first interface, a first configuration file is added to the configuration file list. The first configuration file includes at least service configuration information for connecting to at least one service, and the at least one service is used to provide at least one tool. as well as Based on the first configuration file, the configuration of the first skill is updated, wherein the invocation of the first skill triggers an invocation of the at least one tool.
10. The method of claim 9, wherein the first configuration file further includes invocation mode information, the invocation mode information indicating a mode for invoking the at least one tool.
11. The method of claim 10, wherein the mode includes a first mode indicating that the tool description information and tool invocation script of the at least one tool are generated based on a connection established between the virtual object and the at least one service.
12. The method of claim 10, wherein the mode includes a second mode, the second mode indicating that the tool description information and tool invocation script of the at least one tool are obtained from the configuration file list.
13. The method of claim 12, wherein updating the configuration of the first skill comprises: In response to the invocation mode information indicating the second mode, the tool description information and tool invocation script of the at least one tool are obtained; as well as Add the tool description information and the tool invocation script to the configuration file list.
14. The method of claim 9, wherein the service configuration information indicates at least one of the following: Description of the at least one service. Connection information of at least one service, or The tool configured for the first skill is one of the multiple tools provided by the at least one service.
15. An apparatus for task processing, comprising: The presentation module is configured to present at least one candidate skill, each candidate skill being used to support a virtual object in performing a task of a certain type. A receiving module is configured to receive a first input, the first input being used to select a first skill from the at least one candidate skill, the first skill being configured to invoke at least one tool; The association module is configured to associate the first skill with the virtual object in response to the first input; as well as An execution module is configured to, in response to receiving a request for a task, present the execution result of the task, which is related to the first skill, and the execution result is obtained by the virtual object through invoking the at least one tool.
16. A device for skill configuration, comprising: The presentation module is configured to present a first interface, which includes a list of configuration files for a first skill. The first skill can be invoked by a virtual object to support the virtual object in performing a first type of task. The configuration module is configured to add a first configuration file to the configuration file list via the first interface. The first configuration file includes at least service configuration information for connecting to at least one service, which provides at least one tool. as well as The update module is configured to update the configuration of the first skill based on the first configuration file, wherein the invocation of the first skill triggers an invocation of the at least one tool.
17. An electronic device comprising: At least one processor; as well as At least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, the instructions causing the electronic device to perform the method according to any one of claims 1 to 8 or 9 to 14 when executed by the at least one processor.
18. A computer-readable storage medium having stored thereon computer-executable instructions that can be executed by a processor to implement the method according to any one of claims 1 to 8 or 9 to 14.
19. A computer program product tangibly stored in a computer storage medium and comprising computer-executable instructions that, when executed by a device, cause the device to perform the method according to any one of claims 1 to 8 or 9 to 14.