Task execution engine generation method, system, electronic device, and program product

Abstract

The application is suitable for the field of data processing, and provides a method, system, electronic device and program product for generating a task execution engine, wherein the method comprises: analyzing a user task to obtain at least one subtask, a target function requirement corresponding to each subtask, and an execution sequence rule between the subtasks; determining a tool existence state of each target tool for executing each subtask based on the target function requirement corresponding to each subtask; based on the tool existence state, obtaining the target tool satisfying the target function requirement from a locally created model context protocol tool library, and / or generating an agent using a locally deployed tool to generate the target tool satisfying the target function requirement; and according to the execution sequence rule, arranging the target tool to generate an agent-based task execution engine. The scheme can generate an agent-based task execution engine in a private deployment scenario.

Description

TECHNICAL FIELD

[0001] The application belongs to the field of data processing, and particularly relates to a task execution engine generation method and system, an electronic device, and a program product. BACKGROUND

[0002] An AI agent refers to an intelligent entity capable of understanding instructions and performing tasks. An AI agent can be generated based on a function call or a model context protocol (MCP) tool, and a task execution engine of an AI agent architecture can be generated to facilitate automatic execution of user tasks. Compared with a function call, the MCP tool has a significant advantage in interface specification and can more efficiently support the generation and collaboration of AI agents. Today, it is difficult to generate a task execution engine based on an AI agent in a private deployment scenario through an MCP tool. SUMMARY

[0003] Embodiments of the application provide a task execution engine generation method, system, electronic device, and program product to solve the problem that it is difficult to generate a task execution engine based on an AI agent in a private deployment scenario through an MCP tool.

[0004] A first aspect of embodiments of the application provides a task execution engine generation method, comprising:

[0005] parsing a user task to obtain at least one subtask, a target function requirement corresponding to each subtask, and an execution sequence rule between the subtasks;

[0006] determining a tool existence state of each target tool for executing each subtask based on the target function requirement corresponding to each subtask; the target tool is a model context protocol tool, and the tool existence state is a tool already exists state or a tool to be generated state;

[0007] based on the tool existence state, obtaining the target tool satisfying the target function requirement from a locally created model context protocol tool library, and / or generating the target tool satisfying the target function requirement by using a locally deployed tool to generate an AI agent;

[0008] arranging the target tool according to the execution sequence rule to generate a task execution engine based on an AI agent.

[0009] A second aspect of embodiments of the application provides a task execution engine generation system, comprising:

[0010] a parsing module configured to parse a user task to obtain at least one subtask, a target function requirement corresponding to each subtask, and an execution sequence rule between the subtasks;

[0011] determining module, configured to determine a tool existence state of each target tool for executing each subtask based on the target function requirement corresponding to each subtask; the target tool is a model context protocol tool, and the tool existence state is a tool already existing state or a tool to be generated state;

[0012] an obtaining module, configured to obtain the target tool meeting the target function requirement from a locally created model context protocol tool library based on the tool existence state, and / or generate the target tool meeting the target function requirement by using a locally deployed tool to generate an agent;

[0013] a generating module, configured to arrange the target tool according to the execution sequence rule, and generate an agent-based task execution engine.

[0014] A third aspect of the embodiment of the application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the method according to the first aspect when executing the computer program.

[0015] A fourth aspect of the embodiment of the application provides a computer program product, including a computer program, and the computer program implements the steps of the method according to the first aspect when executed by a processor.

[0016] A fifth aspect of the embodiment of the application provides a computer readable storage medium, which stores a computer program, and the computer program implements the steps of the method according to the first aspect when executed by a processor.

[0017] As can be seen from the above, the application analyzes a user task to obtain at least one subtask, a target function requirement corresponding to each subtask, and an execution sequence rule between subtasks, dynamically determines a tool existence state of each target tool for executing each subtask based on the target function requirement corresponding to each subtask. Based on the tool existence state, the target tool is obtained through at least one of the following two local obtaining approaches, i.e., the target tool is obtained from a locally pre-created model context protocol tool library and / or the target tool is generated in real time by using a locally deployed tool to generate an agent, the obtained target tool is arranged according to the execution sequence rule, and an agent-based task execution engine is generated. The target tool of the engine is obtained locally and does not depend on an external platform, i.e., the purpose of generating an agent-based task execution engine through an MCP tool in a private deployment scenario is achieved. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only some of the embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0019] Figure 1 is a flow chart of a task execution engine generation method provided by an embodiment of the present application;

[0020] Figure 2 is an architecture schematic diagram of a task execution engine based on an agent provided by an embodiment of the present application;

[0021] Figure 3 is a structure diagram of a task execution engine generation system provided by an embodiment of the present application;

[0022] Figure 4 is a structure diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0023] In the following description, for the purpose of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application can be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

[0024] It should be understood that the term "comprising" as used in the specification and the appended claims indicates the presence of the recited features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0025] It should also be understood that the terms used in the present application specification are only for the purpose of describing specific embodiments and are not intended to limit the present application. As used in the present application specification and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an", and "the" are intended to include the plural forms.

[0026] It should be further understood that the term "and / or" as used in the present application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes these combinations.

[0027] As used in the specification and the appended claims, the term "if' can be construed to mean "when" or "upon" or "in response to determining" or "in response to detecting" depending on the context. Similarly, the phrase "if it is determined" or "if [a described condition or event] is detected" can be construed to mean "upon determining" or "in response to determining" or "upon detecting [the described condition or event]" or "in response to detecting [the described condition or event]" depending on the context.

[0028] In particular implementations, the terminals described in the embodiments of the present application include, but are not limited to, other portable devices such as mobile telephones, laptop computers, or tablet computers with touch-sensitive surfaces (e.g., touch screen displays and / or touch pads). It should also be understood that, in some embodiments, the device is not a portable communication device, but is a desktop computer with a touch-sensitive surface (e.g., a touch screen display and / or a touch pad).

[0029] In the following discussion, a terminal that includes a display and a touch-sensitive surface is described. It should be understood, however, that a terminal can include one or more other physical user-interface devices, such as a physical keyboard, a mouse and / or a joystick.

[0030] The terminal supports a variety of applications, such as one or more of the following: a drawing application, a presentation application, a word processing application, a website creation application, a disk authoring application, a spreadsheet application, a game application, a telephone application, a video conferencing application, an e-mail application, an instant messaging application, a workout support application, a photo management application, a digital camera application, a digital camcorder application, a web browsing application, a digital music player application, and / or a digital video player application.

[0031] The various applications which can be executed on the terminal can use at least one common physical user-interface device, such as the touch-sensitive surface. One or more functions of the touch-sensitive surface, as well as the display of information related to those functions, on the terminal can be adjusted and / or changed in accordance with the application which is being executed by the terminal. By way of example, the display of information related to a particular function of the touch-sensitive surface which is displayed on the terminal can be adjusted in size and / or position in accordance with the application which is being executed by the terminal. Thus, the user need not provide separate tactile and / or visual feedback of the functions of the terminal from the tactile and / or visual output associated with the applications being executed by the terminal.

[0032] It should be understood that the size of the serial number of each step in the embodiments does not mean the order of execution, the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0033] The function call and the model context protocol tool can be used to build a task execution engine of an agent and an agent architecture to execute a task, especially a complex task. The function call mode has randomness in the generated result, which often leads to inconsistent function interface structure and difficulty in reuse and standardization. The model context protocol tool has an advantage in interface specification, but it is difficult to call in a private deployment scenario without public network environment, which seriously restricts the landing application of the agent in an enterprise-level environment and limits the construction of the task execution engine based on the agent in the private deployment scenario.

[0034] In order to promote the landing application of the agent in the enterprise-level environment and build the task execution engine based on the agent in the private deployment scenario, the application provides a method, system, electronic device and program product for generating a task execution engine.

[0035] In order to illustrate the technical solutions described in the application, specific embodiments are described below.

[0036] Referring to Figure 1 , Figure 1 is a flowchart of a method for generating a task execution engine provided by an embodiment of the application. As Figure 1 indicated, a method for generating a task execution engine includes the following steps:

[0037] Step 101: parsing a user task to obtain at least one subtask, a target function requirement corresponding to each subtask, and an execution order rule between the subtasks.

[0038] The user task refers to a type of task that the user needs the task execution engine to execute, such as translating a Chinese text into an English text, translating a Chinese speech into an English text, etc.

[0039] The subtask refers to an executable unit with clear functional boundaries and input and output requirements formed after the user task (such as translating a Chinese speech into an English text) is decomposed. The core value of the subtask lies in realizing the schedulability and controllability of the task by refining the task granularity and the dependency relationship (such as speech recognition triggering text translation).

[0040] The target function requirement refers to a specific function specification necessary for executing the subtask, which clearly defines the input condition, processing logic and output standard of the subtask, ensuring that the subtask is executable and the result is verifiable.

[0041] The execution order rule refers to a constraint mechanism of the execution order, i.e., the dependency relationship, that the subtask must follow. For example, the user task is to translate a Chinese speech into an English text, wherein the speech recognition subtask is earlier than the Chinese-English translation subtask.

[0042] The user task is parsed into subtasks, the target function requirements of each subtask are standardized, and the execution order rules between the subtasks are established, so that the schedulability and controllable automatic execution of the user task, especially a complex user task, are realized.

[0043] In some embodiments, the parsing of the user task to obtain at least one subtask, the target function requirements corresponding to each subtask, and the execution order rules between the subtasks comprises: decomposing the user task to generate the subtasks; determining the target function requirements that need to be met by each target tool for executing the subtasks; if one subtask is generated, the execution order rule is empty; and if at least two subtasks are generated, the execution order rules between the subtasks are determined based on the task execution dependency relationship of the subtasks, and the execution order rules are serial execution links, parallel execution links, or mixed execution links, the mixed execution links include serial sublinks and parallel sublinks.

[0044] The user task is decomposed, and one or more subtasks are generated based on different task complexities.

[0045] For each subtask, the function requirements that need to be met by the corresponding target tool, i.e., the target function requirements, are determined, which need to accurately describe the input conditions, processing logic, and output standards to ensure that the subtask can be independently executed and the result can be verified.

[0046] The execution order rules are dynamically generated according to the number of subtasks and the dependency relationship. The execution order rules are divided into single-subtask scenarios and multi-subtask scenarios according to the number of subtasks.

[0047] Single-subtask scenario: if only one subtask is generated, the execution order rule does not need to be defined, i.e., the execution order rule is empty. For example, the user task "translate Chinese text into English text" is decomposed to generate only one subtask, i.e., "translate Chinese text into English text", and at this time, the execution order rule is empty.

[0048] Multi-subtask scenario: if at least two subtasks are generated, the execution order rules between the subtasks are determined by analyzing the dependency relationship (such as data transmission, resource preemption, or logical sequence) between the subtasks. The rules are divided into three categories: serial execution links, in which the subtasks are executed in strict sequence, such as subtask A is completed and subtask B is executed; parallel execution links, in which the subtasks with no dependency relationship can be executed synchronously, such as subtask A and subtask B are executed simultaneously; and mixed execution links, which include a combination of serial sublinks and parallel sublinks, such as subtask A is completed, subtask B is executed, and then subtask C and subtask D are executed in parallel.

[0049] Through task decomposition, function standardization, and dependency relationship determination, dynamic scheduling of tasks is realized to ensure the efficiency and reliability of the execution process.

[0050] In some embodiments, a task parsing agent is deployed locally to structure the decomposition of user tasks, generate subtasks, and specify the target functional requirements corresponding to each subtask and the execution order rules between subtasks. This design realizes the atomic decomposition and functional standardization definition of complex tasks through the task parsing agent, provides structured input for subsequent task scheduling and automated execution, and guarantees task controllability.

[0051] In some embodiments, the task parsing agent is an agent constructed based on an open-source large language model or a large language model fine-tuned in combination with parsing business.

[0052] In some embodiments, the task parsing agent corresponds to a parsing prompt word, which can be built-in in the task parsing agent. The parsing prompt word acts as a translator from natural language to executable logic, and is used to specify user task positioning, structure user task decomposition, and dynamically set constraints, accurately guide the agent to understand and decompose user tasks, and realize the closed loop from intent understanding to action landing.

[0053] In step 102, based on the target functional requirements corresponding to each subtask, the tool existence state of each target tool for executing each subtask is determined; the target tool is a model context protocol tool, and the tool existence state is a tool already existing state or a tool to be generated state.

[0054] The target tool is a model context protocol tool for executing the subtask.

[0055] The tool already existing state means that the tool is stored in a locally created model context protocol tool library. The tool to be generated state means that the tool does not exist in the locally created model context protocol tool library and needs to be generated in real time locally.

[0056] The model context protocol tool library is created locally in advance and is used to store model context protocol tools of various functions, such as a model context protocol tool for crawling data, a model context protocol tool for automatic speech recognition (ASR), a model context protocol tool for text-to-speech (TTS), and the like.

[0057] According to the target functional requirements of the subtask, the tool existence state of the target tool for executing the subtask is determined, the tool resources are matched with the subtask requirements, the closed loop adaptation capability is formed, and the efficient execution of the task is guaranteed.

[0058] In some embodiments, the determining of the tool existence state of each target tool for executing each subtask based on the target function requirement corresponding to each subtask comprises: querying whether the target tool satisfying the target function requirement of the subtask exists in the model context protocol tool library; if the target tool exists, marking the tool existence state of the subtask as the tool already exists state; if the target tool does not exist, marking the tool existence state of the subtask as the tool to be generated state.

[0059] In some embodiments, a query unit is provided, which contains the identification information (such as identifier) and function description of all model context protocol tools in the model context protocol tool library. The function description briefly describes the core capability and input / output specification of the tool. For example, the function description is to translate Chinese text into English text.

[0060] In some embodiments, based on the target function requirement of the subtask and the query unit, it is queried whether the target tool with the function description covering the target function requirement exists in the model context protocol tool library. If the tool with the function description completely matching the target function requirement exists in the model context protocol tool library, the tool existence state of the subtask is marked as the tool already exists state. If no matching tool exists, the tool existence state of the subtask is marked as the tool to be generated state.

[0061] In some embodiments, a tool information list of the subtask can be constructed to mark the tool information corresponding to each subtask. For example, Table 1 provided by the embodiments of the present application is a tool information table of a subtask.

[0062] Table 1 Tool information table of a subtask

[0063]

[0064] The tool identifier shown in Table 1 is only an example, and how to identify is determined according to actual conditions.

[0065] Table 1 explicitly shows the target tool, tool existence state, tool identifier and tool acquisition approach corresponding to each subtask. Different tool existence states correspond to different tool acquisition approaches. The target tool in the tool already exists state corresponds to the tool identifier, which is used to acquire the target tool from the model context protocol tool library based on the tool identifier. Correspondingly, the target tool in the tool to be generated state indicates that the target tool does not exist in the model context protocol tool library and needs to be generated in real time. At this time, the tool identifier of the target tool cannot be provided, which is represented as empty.

[0066] By dynamically sensing the status of tool resources (existing / to be generated), a basis for tool acquisition decisions is provided, so that the target tool can be acquired adaptively according to the tool's existence status, achieving a seamless connection in engine generation.

[0067] Step 103: Based on the existence state of the tool, obtain the target tool that meets the target functional requirements from the locally created model context protocol tool library, and / or generate the target tool that meets the target functional requirements using the locally deployed tool generation agent.

[0068] In order to generate an agent-based task execution engine through the Model Context Protocol tool in a private deployment scenario, this application sets up two target tool acquisition methods locally.

[0069] Different tool existence states correspond to different tool acquisition methods. By flexibly scheduling local tool resources, the target tool can be flexibly acquired, thereby improving the engine's generation efficiency.

[0070] In some embodiments, obtaining the target tool that meets the target functional requirements from a locally created Model Context Protocol tool library based on the tool's existence state, and / or generating the target tool that meets the target functional requirements using a locally deployed tool generation agent, includes: obtaining a first target tool that meets the target functional requirements from the Model Context Protocol tool library when the tool's existence state in the subtask is "tool already exists"; and generating a second target tool using the tool generation agent based on the target functional requirements of the subtask when the tool's existence state in the subtask is "tool to be generated".

[0071] When the tool existence status of a subtask is "tool already exists," it indicates that the model context protocol tool library contains a target tool for executing the subtask. In this case, the corresponding target tool, i.e., the first target tool, can be retrieved from the model context protocol tool library first. Accurately matching and calling the target tool from the local model context protocol tool library—that is, reusing existing tools—avoids resource waste caused by repeated generation, reduces redundant resource consumption, lowers development costs and computational overhead, and significantly improves response speed and engine generation efficiency.

[0072] When the tool for a subtask is in the "tool pending generation" state, it indicates that the target tool for executing the subtask does not exist in the model context protocol tool library. In this case, the corresponding target tool, i.e., the second target tool, needs to be generated locally. Generating a second target tool that meets the target's functional requirements on demand automatically fills in functional gaps, ensuring that engine building can continue even when no tools are available. This ensures that engine building and task execution are not interrupted due to tool deficiencies, guaranteeing the executability of the engine and tasks.

[0073] In some embodiments, it is necessary to ensure that the generated second target tool is consistent with the interface format of the model context protocol tool in the model context protocol tool library, so as to improve the compatibility between tools.

[0074] In some embodiments, a tool generation agent is deployed locally, which is used to generate a second target tool that meets the target functional requirements on demand. The tool generation agent is an agent constructed based on an open source large language model or a large language model combined with tool generation business fine-tuning.

[0075] In some embodiments, the tool generation agent corresponds to a generation guidance prompt word, which can be built-in in the tool generation agent. The generation guidance prompt word is used to assist in understanding the tool generation instruction, standardize the tool generation process, ensure the output quality and adapt to the business scenario, and improve the reliability, security and business adaptability of the generated tool.

[0076] In some embodiments, the tool generation agent is a lightweight tool generation agent, and the lightweight design improves the generation speed and reduces resource occupation.

[0077] The tool acquisition operation is completed in a local environment, avoiding network transmission risks, avoiding generation process interruptions caused by public network fluctuations, network attacks or cloud service interruptions, ensuring that sensitive business data is not leaked, providing a safe and reliable local data processing and execution environment for users, and promoting the generation of task execution engines based on agents in enterprise-level private deployment scenarios.

[0078] The sub-tasks are one or more, and the tool existence states of multiple sub-tasks include tool already existing state and / or tool to be generated state. Therefore, for multiple sub-tasks, the acquisition approach of the corresponding target tool is at least one of local tool library acquisition and local real-time generation. That is, in the case where the tool existence states of multiple sub-tasks include tool already existing state and tool to be generated state, a part of the target tools are acquired from the local model context protocol tool library, and a part of the target tools are generated by using the locally deployed tool generation agent; in the case where the tool existence states of multiple sub-tasks are all tool already existing state, all target tools are acquired from the local model context protocol tool library; in the case where the tool existence states of multiple sub-tasks are all tool to be generated state, all target tools are generated by using the locally deployed tool generation agent.

[0079] The multi-way acquisition of target tools improves the efficiency and reliability of agent generation and invocation, realizes the decoupling, standardization and efficient reuse of tool capabilities, provides key support for the wide application of task execution engines based on agents in enterprise-level private deployment environments, and has significant practical value and promotion prospects.

[0080] In some embodiments, the tool generation instruction is generated based on the specific functional requirements of the subtask, and the tool generation instruction is used to instruct the tool generation agent to generate the second target tool that meets the target functional requirements.

[0081] The tool generation instruction is constructed according to the specific functional requirements of the subtask, and the instruction needs to clearly describe the core capabilities and constraint conditions that the target tool should achieve, which is used to guide the tool generation agent to accurately create the adaptive tool.

[0082] The generated tool generation instruction is sent to the tool generation agent, which parses the instruction and dynamically constructs the to-be-verified tool. The to-be-verified tool is a model context protocol tool.

[0083] The to-be-verified tool is functionally verified, focusing on whether it can effectively execute the current subtask. If the verification is passed, the to-be-verified tool is determined as the second target tool for engine construction.

[0084] The tool generation agent dynamically constructs the to-be-verified tool according to the target functional requirements of the subtask, and calls it only after confirming the execution capability of the to-be-verified tool through localized functional verification, ensuring that the generated tool matches the subtask.

[0085] In some embodiments, the tool verification can be completed by a locally deployed tool verification agent, that is, the to-be-verified tool and the target functional requirements are sent to the tool verification agent, the tool verification agent generates test data for verification, and outputs verification pass information or verification fail information. The tool verification agent is an agent constructed based on an open source large language model or a large language model fine-tuned in combination with tool verification business.

[0086] In some embodiments, the tool verification agent corresponds to a verification operation prompt word, which can be built-in in the tool verification agent. The verification operation prompt word is used to standardize the verification process and improve operation accuracy and result reliability.

[0087] In some embodiments, after determining the second target tool as the second target tool to be verified, the method further comprises: verifying an authorization attribute of the second target tool, the authorization attribute being one of allowing the second target tool to be recorded in the model context protocol tool library and disallowing the second target tool to be recorded in the model context protocol tool library; and recording the second target tool in the model context protocol tool library when the authorization attribute is the one of allowing the second target tool to be recorded in the model context protocol tool library.

[0088] The authorization attribute is a unique permission basis for a tool to access the model context protocol tool library.

[0089] After confirming that the tool to be verified has the capability to perform the subtask, the authorization attribute of the tool to be verified needs to be further verified, i.e., whether the tool to be verified is allowed to be recorded in the model context protocol tool library.

[0090] When the authorization attribute is the one of allowing the second target tool to be recorded in the model context protocol tool library, the second target tool is officially recorded in the model context protocol tool library. Through the dynamic recording mechanism, the tool library is continuously expanded, the callable resources of the tool library are expanded, and the compliance access of new tools is ensured, the modularity, controllability and continuous reuse of the capability are realized, and it is ensured that the model context protocol tool library can respond to new task requirements, and the problem of shortage of model context protocol tool resources in a private deployment scenario is effectively alleviated.

[0091] When the authorization attribute is the one of disallowing the second target tool to be recorded in the model context protocol tool library, the recording process is skipped, the model context protocol tool library is prevented from being polluted by unauthorized tools, and the purity and compliance of the tool library are ensured. The second target tool is marked as a temporary tool, which is only used for the current engine construction, and is automatically destroyed after the end, thereby releasing the memory and reducing the resource occupation.

[0092] In some embodiments, the function description, use scenario and destruction time of the temporary tool are recorded synchronously for tracing.

[0093] In some embodiments, the authorization attribute information is set by a manager with a management right or an automatic authorization management unit.

[0094] In some embodiments, when the automatic authorization mechanism is satisfied, the automatic authorization is performed. If the automatic authorization mechanism is not satisfied, a manager with a management right needs to determine whether to perform manual authorization, e.g., the manager authorizes the second target tool to be stored in the model context protocol tool library. The automatic authorization mechanism is set according to actual conditions.

[0095] In step 104, the target tool is arranged according to the execution order rule, and a task execution engine based on an intelligent agent is generated.

[0096] The task execution engine based on the intelligent agent is a task execution engine based on an intelligent agent architecture, and is used to execute a type of user task.

[0097] The execution order rule is an execution rule of a subtask, each subtask corresponds to a target tool, the target tool is used to execute the subtask, and accordingly, the target tool can be arranged according to the execution order rule of the subtask, and then a task execution engine based on an agent is generated.

[0098] The strict ordering depending on the execution order rule avoids interruption of task execution and improves execution reliability.

[0099] In some embodiments, the arrangement of the target tool according to the execution order rule to generate the task execution engine based on the agent includes: converting the target tool into a target agent; the target agent corresponds to the subtask one by one; and assembling the target agent according to the execution order rule between the subtasks to obtain the task execution engine.

[0100] The target tool corresponding to each subtask is converted into an independent target agent through agent encapsulation.

[0101] In some embodiments, the capability interface of the target tool is mapped to the action capability of the target agent, ensuring that the target agent has the ability to execute the subtask. The execution context (such as input data format, performance constraint) matching the subtask is injected into the agent to form a strict correspondence relationship of "one task one agent", guaranteeing resource isolation and single responsibility. Through the lightweight encapsulation of "one task one agent", redundant resource occupation is reduced.

[0102] The subtask corresponds to the target agent one by one, each target agent is used to execute the subtask bound thereto, and the execution order rule between the subtasks is directly mapped to the scheduling logic of the target agent. Thus, the target agent is assembled according to the execution order rule. For example, subtask A is executed first, and then subtask B is executed, target agent a is used to execute subtask A, target agent b is used to execute subtask B, the execution order rule is A→B, and accordingly, the scheduling logic of the target agent is a→b, so the target agent needs to be assembled in order to ensure that the task execution strictly follows the execution order rule. Depending on the strict order, task execution interruption is avoided, an end-to-end traceable task closed loop is realized, and execution continuity is guaranteed.

[0103] In some embodiments, the target agent can be assembled in a serial, parallel, or hybrid (serial + parallel) topology to realize flexible execution of tasks and resource collaboration.

[0104] In some embodiments, the target tool is arranged by a planning agent deployed locally to generate a task execution engine based on an agent. The planning agent is an agent constructed based on an open source large language model or a large language model combined with tool arrangement business fine-tuning.

[0105] In some embodiments, the planning agent corresponds to a planning prompt word, which can be built-in in the planning agent. The planning prompt word is used to guide the planning agent to generate a task execution engine of the agent architecture that conforms to the task execution logic specification.

[0106] The present application takes the execution order rule as the skeleton and the target agent as the atomic unit. Through structured conversion and execution rule driven assembly, the target tool is dynamically converted into an agent instance, and a high-reliability task execution engine is constructed based on the execution order rule, providing an automated base with efficiency and robustness for task execution, and realizing automatic closed-loop execution of tasks.

[0107] In some embodiments, the present application supports horizontal expansion to a level agent cluster to generate a larger scale agent-based task execution engine.

[0108] In some embodiments, the agent-based task execution engine is published as a service. After service publishing, the engine can be called to execute the corresponding type of pending tasks.

[0109] In some embodiments, common programming languages such as java and python can be used to implement service publishing, which is not limited by the present application.

[0110] In order to better understand the above engine generation and publishing process, taking the user task "generate a Chinese to English translation assistant that supports voice input and voice output" as an example, the specific process is as follows:

[0111] The user task "generate a Chinese to English translation assistant that supports voice input and voice output" is received.

[0112] The user task is parsed to obtain a plurality of subtasks, which are voice recognition subtask, text translation subtask and voice generation subtask, and the corresponding target function requirements are to convert the user input Chinese voice into Chinese text, to translate the Chinese text into English text, and to synthesize the English text into English voice and output, and the execution order rule between the subtasks is voice recognition→text translation→voice generation.

[0113] Based on the target function requirement, the tool existence state corresponding to each subtask is determined, and the tool existence states of the voice recognition subtask, the text translation subtask and the voice generation subtask are tool already exists state, tool to be generated state and tool already exists state respectively.

[0114] Based on the tool's existence status, determine the acquisition method of the target tool for executing the sub-task. Obtain the speech recognition MCP tool corresponding to the speech recognition sub-task and the speech generation MCP tool corresponding to the speech generation sub-task from the Model Context Protocol Tool Library. Based on the tool, generate the intelligent agent to generate the callable text translation MCP tool corresponding to the text translation sub-task in real time.

[0115] Following the execution order of speech recognition → text translation → speech generation, speech recognition MCP tools, text translation MCP tools, and speech generation MCP tools are arranged to generate an agent-based task execution engine that performs user tasks. This engine contains three agents.

[0116] The agent-based task execution engine is published as a service via a Representational State Transfer Application Programming Interface (RESTful API). After publication, the engine can be called via the API to perform the task of translating input Chinese speech into English speech and outputting it.

[0117] like Figure 2 As shown, Figure 2 This is a schematic diagram of the architecture of a task execution engine based on intelligent agents provided in an embodiment of this application. The engine includes a speech recognition intelligent agent, a text translation intelligent agent, and a speech generation intelligent agent. When the engine is invoked to execute a user task, it receives Chinese speech input from the user, processes the Chinese speech through its intelligent agent architecture, and outputs English speech.

[0118] Among them, the real-time generation of callable text translation MCP tools corresponding to text translation subtasks based on the tool generation agent includes: generating tool generation instructions corresponding to text translation subtasks, such as developing a Chinese to English text translation (Translator) MCP tool, sending the instructions to the tool generation agent, obtaining the test tool generated by the tool generation agent, and verifying whether the test tool can translate Chinese text into English text through the tool verification agent. If it can translate Chinese text into English text, it is identified as a text translation MCP tool.

[0119] In some embodiments, the authorization attribute of the text translation MCP tool is checked to ensure that it is allowed to be entered into the Model Context Protocol (MCP) tool library. If so, it is stored in the MCP tool library. At this time, if an agent-based task execution engine is rebuilt based on the user task "generate a Chinese-to-English translation assistant that supports voice input and voice output", the tool existence status corresponding to the text translation subtask is "tool already exists".

[0120] In some embodiments, the prompt words of the auxiliary agents such as the task analysis agent, the tool generation agent, the tool verification agent and the planning agent can be dynamically expanded, for example, combined with the user task to achieve expansion and update.

[0121] In the embodiments of the present application, the user task is analyzed to obtain at least one subtask, target function requirements corresponding to each subtask and execution order rules between the subtasks. Based on the target function requirements corresponding to each subtask, the tool existence state of each target tool for executing each subtask is dynamically determined. Based on the tool existence state, the target tool is obtained through at least one of the following two localized acquisition approaches, i.e., obtaining the target tool from a locally pre-created model context protocol tool library and / or generating the target tool in real time by using a locally deployed tool generation agent. The obtained target tools are arranged according to the execution order rules to generate an agent-based task execution engine. The target tools of the engine are locally implemented for acquisition, and do not depend on external platforms, i.e., the purpose of generating an agent-based task execution engine through MCP tools in a private deployment scenario is achieved.

[0122] Referring to Figure 3 , Figure 3 is a structural diagram of a task execution engine generation system provided by the embodiments of the present application. For ease of illustration, only parts related to the embodiments of the present application are shown.

[0123] The task execution engine generation system 300 includes an analysis module 301, a determination module 302, an acquisition module 303 and a generation module 304.

[0124] The analysis module 301 is configured to analyze a user task to obtain at least one subtask, target function requirements corresponding to each subtask and execution order rules between the subtasks.

[0125] The determination module 302 is configured to determine, based on the target function requirements corresponding to each subtask, a tool existence state of each target tool for executing each subtask. The target tool is a model context protocol tool, and the tool existence state is a tool already existing state or a tool to be generated state.

[0126] The acquisition module 303 is configured to acquire, based on the tool existence state, the target tool satisfying the target function requirements from a locally created model context protocol tool library, and / or generate the target tool satisfying the target function requirements by using a locally deployed tool generation agent.

[0127] The generation module 304 is configured to arrange the target tools according to the execution order rules to generate an agent-based task execution engine.

[0128] In some embodiments, the parsing module is specifically configured to:

[0129] decompose the user task to generate the subtasks;

[0130] determine the target function requirements to be met by each target tool performing the subtasks;

[0131] if one subtask is generated, the execution sequence rule is empty;

[0132] if at least two subtasks are generated, determine the execution sequence rule between the subtasks based on the task execution dependency relationship of the subtasks, the execution sequence rule being a serial execution link, a parallel execution link, or a mixed execution link, the mixed execution link including serial sublinks and parallel sublinks.

[0133] In some embodiments, the determining module is specifically configured to:

[0134] query whether the target tool meeting the target function requirements of the subtask exists in the model context protocol tool library;

[0135] if yes, mark the tool existence state of the subtask as the tool already exists state;

[0136] if no, mark the tool existence state of the subtask as the tool to be generated state.

[0137] In some embodiments, the obtaining module is configured to:

[0138] if the tool existence state of the subtask is the tool already exists state, obtain a first target tool meeting the target function requirements from the model context protocol tool library;

[0139] if the tool existence state of the subtask is the tool to be generated state, generate a second target tool by the tool generation agent based on the target function requirements of the subtask.

[0140] In some embodiments, the obtaining module is specifically configured to:

[0141] generate a tool generation instruction based on the target function requirements of the subtask, the tool generation instruction being used to instruct the tool generation agent to generate the second target tool meeting the target function requirements;

[0142] send the tool generation instruction to the tool generation agent to obtain the to-be-inspected tool generated by the tool generation agent;

[0143] verifying whether the tool to be verified can perform the subtask;

[0144] if the tool to be verified can perform the subtask, determining the tool to be verified as the second target tool.

[0145] In some embodiments, the system further comprises an authorization verification module configured to:

[0146] verify an authorization attribute of the second target tool, the authorization attribute being whether to allow the second target tool to be added into the model context protocol tool library or not;

[0147] if the authorization attribute is to allow the second target tool to be added into the model context protocol tool library, add the second target tool into the model context protocol tool library.

[0148] In some embodiments, the generating module is specifically configured to:

[0149] convert the target tool into a target agent, the target agent corresponding to the subtask one by one;

[0150] assemble the target agent according to the execution order rule between the subtasks to obtain the task execution engine.

[0151] The generating system of the task execution engine provided by the embodiments of the present application can implement each process of the embodiments of the above-mentioned method for generating a task execution engine, and achieve the same technical effects. To avoid repetition, the details are not described here.

[0152] Figure 4 is a structural diagram of an electronic device provided by an embodiment of the present application. As shown in the figure, the electronic device 4 of the embodiment includes at least one processor 40 (only one is shown in the figure), a memory 41, and a computer program 42 stored in the memory 41 and executable on the at least one processor 40, wherein the processor 40 implements the steps in any of the above-mentioned method embodiments when executing the computer program 42. Figure 4

[0153] The electronic device 4 can be a desktop computer, a notebook computer, a palm computer, a cloud server, and the like. The electronic device 4 can include, but is not limited to, a processor 40 and a memory 41. Those skilled in the art can understand that the electronic device 4 is only an example of the electronic device 4 and does not constitute a limitation on the electronic device 4, and can include more or fewer components than those shown in the figure, or combine certain components, or different components, for example, the electronic device can also include an input / output device, a network access device, a bus, and the like. Figure 4 The electronic device 4 is only an example of the electronic device 4 and does not constitute a limitation on the electronic device 4, and can include more or fewer components than those shown in the figure, or combine certain components, or different components, for example, the electronic device can also include an input / output device, a network access device, a bus, and the like.

[0154] ​The processor 40 can be a central processing unit (CPU), and can also be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0155] The memory 41 can be an internal storage unit of the electronic device 4, such as a hard disk or a memory of the electronic device 4. The memory 41 can also be an external storage device of the electronic device 4, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 4. Further, the memory 41 can also include both the internal storage unit and the external storage device of the electronic device 4. The memory 41 is used to store the computer program and other programs and data required by the electronic device. The memory 41 can also be used to temporarily store data that has been output or will be output.

[0156] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional units and modules is exemplified, and in actual application, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the system is divided into different functional units or modules to complete all or part of the above described functions. Each functional unit and module in the embodiment can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit, and the integrated unit can be realized in the form of hardware or in the form of software. In addition, the specific names of each functional unit and module are only for easy distinction, and do not limit the protection scope of the present application. The specific working process of the units and modules in the system can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0157] In the above embodiments, the description of each embodiment has its own emphasis, and the parts not described or recorded in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0158] Those skilled in the art can understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0159] In the embodiments provided by the present application, it should be understood that the disclosed system / electronic device and method can be implemented in other ways. For example, the above-described system / electronic device embodiments are merely illustrative. For example, the division of the modules or units is merely a logical function division. There can be another division manner in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed coupling or direct coupling or communication connection between the units can be indirect coupling or communication connection through some interface, system or unit, and can be electrical, mechanical or in other forms.

[0160] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e. they can be located in one place, or distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

[0161] In addition, each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically independently, or two or more units can be integrated into one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0162] The integrated module / unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can also be implemented by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. The computer program can implement the steps of the above-mentioned various method embodiments when executed by a processor. The computer program includes computer program code, which can be in the form of source code, object code, executable files or some intermediate forms. The computer readable medium can include any entity or device, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. that can carry the computer program code. It should be noted that the contents included in the computer readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer readable medium does not include electric carrier signals and telecommunication signals.

[0163] The above-mentioned embodiment methods can also be implemented by a computer program product, which, when running on an electronic device, causes the electronic device to execute the steps of the above-mentioned various method embodiments.

[0164] The above-mentioned embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for generating a task execution engine, the method comprising: The method is applied to a private deployment scene without a public network, and the method comprises the following steps: Analyzing a user task to obtain at least one subtask, a target function requirement corresponding to each subtask, and an execution sequence rule between the subtasks; Based on the target function requirement corresponding to each subtask, a tool existence state of each target tool for executing each subtask is determined; the target tool is a model context protocol tool, and the tool existence state is a tool existing state or a tool to be generated state; Based on the tool existence state, the target tool satisfying the target function requirement is obtained from a model context protocol tool library created locally, and / or an agent is generated by using a locally deployed tool to generate an agent to generate the target tool satisfying the target function requirement, specifically including: in the case where the tool existence state of the subtask is the tool existing state, a first target tool satisfying the target function requirement is obtained from the model context protocol tool library; in the case where the tool existence state of the subtask is the tool to be generated state, a second target tool is generated by using the tool generation agent based on the target function requirement of the subtask; the tool generation agent is a lightweight tool generation agent; wherein the second target tool is generated by using the tool generation agent based on the target function requirement of the subtask, including: generating a tool generation instruction based on the target function requirement of the subtask; the tool generation instruction is used to instruct the tool generation agent to generate the second target tool satisfying the target function requirement; the tool generation instruction is sent to the tool generation agent to obtain a to-be-inspected tool generated by the tool generation agent; it is inspected whether the to-be-inspected tool can execute the subtask; if the to-be-inspected tool can execute the subtask, the to-be-inspected tool is determined as the second target tool; According to the execution sequence rule, the target tool is arranged to generate a task execution engine based on an agent; the task execution engine is used to execute a to-be-executed task of a type corresponding to the user task; Wherein, after the to-be-inspected tool is determined as the second target tool if the to-be-inspected tool can execute the subtask, the following steps are further included: an authorization attribute of the second target tool is inspected, the authorization attribute is an authorization attribute allowing to be recorded into the model context protocol tool library or an authorization attribute not allowing to be recorded into the model context protocol tool library; in the case where the authorization attribute is the authorization attribute allowing to be recorded into the model context protocol tool library, the second target tool is recorded into the model context protocol tool library; in the case where the authorization attribute is the authorization attribute not allowing to be recorded into the model context protocol tool library, the second target tool is marked as a temporary tool, and the second target tool is destroyed after the task execution engine is constructed.

2. The method of claim 1, wherein, The analyzing a user task to obtain at least one subtask, a target function requirement corresponding to each subtask, and an execution sequence rule between the subtasks comprises: Decomposing the user task to generate the subtasks; determining the target function requirement that each target tool performing the subtask needs to meet; if one subtask is generated, the execution sequence rule is empty; if at least two subtasks are generated, the execution sequence rule between the subtasks is determined based on the task execution dependency relationship of the subtasks, and the execution sequence rule is a serial execution link, a parallel execution link or a mixed execution link, and the mixed execution link includes serial sublinks and parallel sublinks.

3. The method of claim 1, wherein, The tool existence state of each target tool performing each subtask is determined based on the target function requirement corresponding to each subtask, including: querying whether the target tool meeting the target function requirement of the subtask exists in the model context protocol tool library; if it exists, marking the tool existence state of the subtask as the tool already exists state; if it does not exist, marking the tool existence state of the subtask as the tool to be generated state.

4. The method of claim 1, wherein, The target tools are arranged according to the execution sequence rule to generate an agent-based task execution engine, including: converting the target tools into target agents; the target agents correspond to the subtasks one by one; assembling the target agents according to the execution sequence rule between the subtasks to obtain the task execution engine.

5. A task execution engine generation system, characterized by, The system is applied to a private deployment scene without public network, and includes: a parsing module configured to parse a user task to obtain at least one subtask, a target function requirement corresponding to each subtask and an execution sequence rule between the subtasks; a determining module configured to determine a tool existence state of each target tool performing each subtask based on the target function requirement corresponding to each subtask; the target tool is a model context protocol tool, and the tool existence state is a tool already exists state or a tool to be generated state; The acquisition module is configured to acquire the target tool satisfying the target function requirement from a locally created model context protocol tool library based on the tool existence state, and / or generate the target tool satisfying the target function requirement by using a locally deployed tool generation agent, and specifically includes: acquiring a first target tool satisfying the target function requirement from the model context protocol tool library in a case where the tool existence state of the subtask is the tool already exists state; and generating a second target tool based on the target function requirement of the subtask by using the tool generation agent in a case where the tool existence state of the subtask is the tool to be generated state, the tool generation agent being a lightweight tool generation agent; wherein the generating the second target tool based on the target function requirement of the subtask by using the tool generation agent includes: generating a tool generation instruction based on the target function requirement of the subtask; the tool generation instruction is used to instruct the tool generation agent to generate the second target tool satisfying the target function requirement; sending the tool generation instruction to the tool generation agent to obtain a to-be-inspected tool generated by the tool generation agent; and inspecting whether the to-be-inspected tool can execute the subtask; and if the to-be-inspected tool can execute the subtask, determining the to-be-inspected tool as the second target tool. The generation module is configured to arrange the target tool according to the execution sequence rule, and generate a task execution engine based on an agent; the task execution engine is used to execute a to-be-executed task of a type corresponding to the user task. The method further includes: inspecting an authorization attribute of the second target tool, the authorization attribute being an authorization attribute of allowing to be recorded in the model context protocol tool library or an authorization attribute of not allowing to be recorded in the model context protocol tool library; recording the second target tool in the model context protocol tool library in a case where the authorization attribute is the authorization attribute of allowing to be recorded in the model context protocol tool library; and marking the second target tool as a temporary tool in a case where the authorization attribute is the authorization attribute of not allowing to be recorded in the model context protocol tool library, and destroying the second target tool after the task execution engine is built.

6. An electronic device, comprising: The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor executes the computer program to enable the electronic device to implement the method of any one of claims 1 to 4.

7. A computer program product, characterised in that, The computer program is executable to enable the method of any one of claims 1 to 4 to be executed.

Images