An agent-based task execution method

Abstract

This invention provides a task execution method based on an intelligent agent, relating to the field of artificial intelligence technology. The method includes: generating an execution plan based on a task description of the task to be processed; the execution plan includes multiple sub-steps with an execution order, and each sub-step has a corresponding sub-step description; for each target step, using the target step description corresponding to the target step, determining the tool to be invoked from a preset tool library and retrieving reference memory data from memory data; invoking the tool to be invoked based on the reference memory data, obtaining the tool invocation result; if the tool invocation result is invalid, obtaining the invocation diagnostic data of the tool to be invoked, using the invalidity type therein, updating the execution plan to a new execution plan, and executing the task to be processed according to the new execution plan. The tool invocation result is verified; if invalid, the execution plan can be flexibly adjusted according to the specific invalidity type to ensure the normal execution of the task, thereby improving the success rate of task execution.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and more specifically to a task execution method based on intelligent agents. Background Technology

[0002] With the rapid development of large language model capabilities, leveraging their powerful natural language understanding, reasoning, and generation capabilities to construct intelligent agents capable of autonomously completing complex tasks has become a current research hotspot. These agents can autonomously plan and execute tasks. Currently, most agents can generate task execution plans based on task descriptions and complete tasks according to those plans.

[0003] However, task execution plans are usually pre-generated. In actual execution, the task may fail to continue due to the failure of a certain step. Furthermore, the quality of the content returned by the tool is ignored when using the tool, which leads to a low success rate of task execution. Summary of the Invention

[0004] To address the aforementioned problems, the present invention aims to provide a task execution method based on an intelligent agent, which can flexibly adjust the execution plan according to the tool invocation results during task execution, thereby effectively improving the success rate of task execution.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0006] On one hand, the present invention provides a task execution method based on an intelligent agent, comprising:

[0007] An execution plan is generated based on the task description of the task to be processed. The execution plan includes multiple sub-steps with an execution order, and each sub-step has a corresponding sub-step description.

[0008] For each target step, using the target step description corresponding to the target step, the tool to be called is determined from the preset tool library and reference memory data is retrieved from the agent's memory data. The target step is the currently executed sub-step determined according to the execution order.

[0009] By combining the reference memory data, the tool to be invoked is called to obtain the tool invocation result;

[0010] If the tool call result is invalid, obtain the call diagnostic data of the tool to be called, and the call diagnostic data includes the invalidity type;

[0011] The execution plan is updated using the invalid type to obtain a new execution plan;

[0012] The tasks to be processed will be carried out in accordance with the new execution plan.

[0013] On the other hand, the present invention also provides a task execution device based on an intelligent agent, comprising:

[0014] The plan generation module is used to generate an execution plan based on the task description of the task to be processed. The execution plan includes multiple sub-steps with an execution order, and each sub-step has a corresponding sub-step description.

[0015] The determination module is used to determine the tool to be called from a preset tool library and retrieve reference memory data from the agent's memory data for each target step, using the target step description corresponding to the target step. The target step is the currently executed sub-step determined according to the execution order.

[0016] The call result module is used to call the tool to be called based on the reference memory data and obtain the tool call result;

[0017] The diagnostic acquisition module, if the tool call result is invalid, acquires the call diagnostic data of the tool to be called, and the call diagnostic data includes invalidity type;

[0018] The update module updates the execution plan using the invalid type to obtain a new execution plan;

[0019] The execution module executes the pending tasks according to the new execution plan.

[0020] On the other hand, the present invention also provides an electronic device, including a processor and a memory, the memory storing a plurality of instructions; the processor loads instructions from the memory to execute steps in any of the agent-based task execution methods provided by the present invention.

[0021] On the other hand, the present invention also provides a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute steps in any of the agent-based task execution methods provided by the present invention.

[0022] On the other hand, the present invention also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps in any of the agent-based task execution methods provided by the present invention.

[0023] The beneficial effects of the technical solution provided by this invention include at least the following:

[0024] In this embodiment of the invention, the execution of the task to be processed is broken down into multiple steps. For each target step being executed, the corresponding step description is used to determine the tool to be invoked and reference memory data. The tool to be invoked is then invoked based on the reference memory data to obtain the tool invocation result. When the tool invocation result is invalid, invocation diagnostic data containing the invalid type is obtained. The execution plan is updated according to the invalid type to obtain a new execution plan, and finally, execution continues according to the new execution plan. By validating the tool invocation result and generating invocation diagnostic data containing invalid types, and repairing the execution plan according to the specific invalid type, the execution plan can be flexibly adjusted according to the execution situation, ensuring the successful execution of the task to be processed and thus improving the success rate of task execution. Attached Figure Description

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

[0026] Figure 1 This is a schematic diagram illustrating an application scenario of the agent-based task execution method provided in an embodiment of the present invention;

[0027] Figure 2 This is a flowchart illustrating the task execution method based on an intelligent agent provided in an embodiment of the present invention;

[0028] Figure 3 This is a schematic diagram of node retrieval in a graph provided by an embodiment of the present invention;

[0029] Figure 4 This is a flowchart illustrating an update execution plan provided in an embodiment of the present invention;

[0030] Figure 5 This is another flowchart illustrating the update execution plan provided in an embodiment of the present invention;

[0031] Figure 6 This is a schematic diagram of the structure of the task execution method device based on intelligent agents provided in an embodiment of the present invention;

[0032] Figure 7 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0033] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0034] It is understood that, in specific embodiments of the present invention, data involving user information and related data requires user permission or consent, and the collection, use and processing of such data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0035] See also Figure 1 This diagram illustrates an application scenario for an agent-based task execution method. The application scenario may include a terminal 101 and a server 102, which can exchange data via a network. The terminal 101 may have relevant applications installed. The terminal 101 can be a mobile phone, tablet, smart Bluetooth device, computer, large screen, robot, or other similar device. The server 102 can be a single server or a server cluster consisting of multiple servers.

[0036] The user can send a task description of the task to be processed to the server 102 via terminal 101. The agent system in server 102 can then generate an execution plan based on the task description. This execution plan includes multiple sub-steps with an execution order, each with a corresponding sub-step description. For each target step, using the target step description, a tool to be invoked is determined from a preset tool library, and reference memory data is retrieved from the agent's memory data. The target step is the currently executing sub-step determined according to the execution order. The tool to be invoked is invoked based on the reference memory data to obtain a tool invocation result. If the tool invocation result is invalid, invocation diagnostic data of the tool to be invoked is obtained, including invalidity types. The execution plan is updated using the invalidity types to obtain a new execution plan. The task to be processed is then executed according to the new execution plan.

[0037] After completing the task to be processed, server 102 can send the execution result of the task to terminal 101 so that the execution result can be displayed to the user through terminal 101.

[0038] In this embodiment, a task execution method based on an intelligent agent is provided, such as Figure 2 As shown, the specific process of this agent-based task execution method can be as follows:

[0039] S110. Generate an execution plan based on the task description of the task to be processed.

[0040] The task to be processed is the task that the intelligent agent needs to perform at present. The task description can be used to describe the task objectives of the task to be processed, and the task description can be in the form of text, image, audio, video, etc. In this embodiment of the invention, the task description is described as text.

[0041] Users can send a task description of the task to be processed to the intelligent agent via devices such as terminals. After receiving the task description, the intelligent agent can understand and analyze it to break down the task into an execution plan containing multiple executable sub-steps. These sub-steps all have a corresponding execution order; that is, to complete the task, multiple sub-steps need to be executed sequentially in the order of execution. Furthermore, each sub-step has its corresponding sub-step description, which may include the step objective of the sub-step.

[0042] As one implementation method, the intelligent agent can call the corresponding large language model to analyze and reason about the task description, break down the task to be processed into multiple sub-steps to obtain an execution plan, and guide subsequent actions based on the execution plan.

[0043] S120. For each target step, using the target step description corresponding to the target step, determine the tool to be invoked from the candidate tools and retrieve reference memory data from the agent's memory data.

[0044] After generating an execution plan, the agent can determine the sub-steps that need to be executed in the order of execution and use them as the target steps. The description of the sub-steps corresponding to the target steps is the target step description. For example, arranging the sub-steps in the order of execution yields a sequence of sub-steps as [sub-step 1, sub-step 2, sub-step 3, ...]. If the task to be processed is to be executed now, then sub-step 1 is the target step.

[0045] The preset tool library stores information about multiple tools that can be invoked by an intelligent agent. In this embodiment of the invention, the preset tool library may include multiple preset tools and data such as function descriptions and parameter specifications for each preset tool. This data may be stored in vector form, denoted as a tool description vector. Therefore, the preset tool library contains preset tools and their corresponding tool description vectors.

[0046] Based on the target step description, a search can be conducted in the preset tool library to determine the tool to be invoked. The tool to be invoked is a preset tool related to the target step description and can be used to execute the target step. There can be multiple tools to be invoked, which can be set according to actual needs and is not specifically limited here.

[0047] Furthermore, the target step description can be used to retrieve reference memory data from the agent's memory data. This memory data can include short-term complete execution data and long-term compressed execution data. Short-term complete execution data can be understood as short-term stored complete execution data. As sub-steps are executed, some of the short-term complete execution data can be converted into long-term compressed execution data, which is a graph data structure.

[0048] In short, the execution data related to the most recently executed steps of the agent can be stored in its entirety, while the execution data related to steps that have been executed for some time can be compressed and stored. These two parts form the agent's memory data.

[0049] Among them, memory data refers to the execution data generated by the agent in executing sub-steps within a historical time period, while reference memory data is data related to the description of the target step retrieved from the memory data. It can be used as context when executing the target step to improve the execution accuracy of the target step.

[0050] Optionally, when determining the tool to be invoked and the reference memory data, the tool to be invoked may be determined for each target step based on the similarity between the target step description and each preset tool in the preset tool library; the key entities in the target step description are converted into graph query statements; a reference subgraph is retrieved from the long-term compressed execution data based on the graph query statements; and the reference subgraph and the short-term complete execution data are fused to obtain the reference memory data.

[0051] The process involves several steps: First, a preset tool library stores tool description vectors corresponding to preset tools. A text embedding model can be used to convert the target step description into step description vectors. Second, the cosine similarity between each step description vector and a tool description vector in the preset tool library is calculated. Third, the tool description vectors are sorted in descending order of cosine similarity. Finally, the preset tools corresponding to the top-ranked first few tool description vectors are selected as the tools to be invoked. The first few can be set according to actual needs and are not specifically limited here. At this stage, the selected tools are those that are semantically relevant to the target step, effectively narrowing the scope of subsequent tool selection and reducing data processing volume.

[0052] The agent can process the target step description to extract key entities. For example, if the target step description is "analyze the background of Company A's CEO and his impact on the company," the key entities extracted using a large language model are: Company A, CEO, and background. After extracting the key entities, they can be used to retrieve key data from long-term compressed data.

[0053] Specifically, since long-term compressed data consists of nodes in a graph, to ensure retrieval accuracy, the extracted key entities can be converted into graph query statements, and multi-path retrieval can be performed using these statements. Optionally, when retrieving the reference subgraph, the entity nodes directly associated with the key entities in the long-term compressed execution data can be retrieved as first nodes; the neighboring nodes of the first node in the long-term compressed execution data can be identified as second nodes; the dependent nodes of the first node and the second node can be obtained as third nodes; and the subgraph formed by the first node, the second node, and the third node can be pruned based on the target step description to obtain the reference subgraph.

[0054] For example, see Figure 3 This diagram illustrates how to retrieve nodes in a graph. First, nodes related to key entities can be retrieved as the first node. For example, a node directly mentioning Company A can be used as the first node. Figure 3 Node A in the diagram.

[0055] After finding the first node in the graph, we can find its neighboring nodes based on the relationships between nodes in the graph, and then use these neighboring nodes as the second node. In other words, we use nodes in the graph that have a one-hop relationship with the first node as the second node. For example, Figure 3 Nodes B, C, and F in the example.

[0056] After identifying the first and second nodes, causal backtracking can be performed in the graph based on these nodes to find the positively dependent nodes of the first and second nodes. Positively dependent nodes are those that influence the first and second nodes through causal relationships. For ease of description, the first and second nodes are denoted as the nodes to be backtracked. For each node to be backtracked, its corresponding parent and ancestor nodes can be obtained. These parent and ancestor nodes are the positively dependent nodes of the node to be backtracked, denoted as the third node. For example, Figure 3 The nodes are D, E, and H.

[0057] By merging the first, second, and third nodes, a subgraph is obtained, which is highly relevant to the current target step. To prevent information overload, the agent can prune the subgraph, retaining only a small number of the most important or relevant nodes to obtain a reference subgraph. Finally, based on the reference subgraph and short-term complete execution data, reference memory data is generated.

[0058] As one implementation, when pruning the subgraph and generating reference memory data based on the reference subgraph and short-term complete execution data, the semantic similarity between the task description and reference nodes (nodes in the subgraph) can be calculated; pruning nodes can be determined from the reference nodes based on the execution completion time corresponding to the reference node and the similarity between the node and the target step description; the pruned nodes can be deleted from the subgraph to obtain the reference subgraph; and the reference subgraph and the short-term complete execution data can be combined to obtain the reference memory data.

[0059] Reference nodes are nodes in the subgraph, each representing a piece of long-term compressed execution data. For each reference node, the semantic similarity between the reference node and the target step description can be calculated to find nodes with higher relevance to the target step description. The long-term compressed execution data may also include the execution completion time. Based on the time difference between the execution completion time and the current time, a time parameter is calculated using a similar time decay method as described above. The semantic similarity and time parameter are then fused to calculate the reference score for the reference node. A higher reference score indicates that the reference node is closer to the task description in terms of relevance, or that its time is closer to the current time. Reference nodes can be sorted according to their reference scores, and a certain number of nodes at the bottom of the ranking can be pruned and removed from the subgraph to obtain the reference subgraph.

[0060] Finally, the reference subgraph can be fused with short-term complete execution data to form reference memory data. Alternatively, the reference subgraph can be converted into a short text summary, denoted as the reference summary, and then combined with the short-term complete execution data to form the final reference memory data. Reference memory data retrieved in this way ensures that the agent can utilize both the complete data of recently completed steps and accurately locate relevant key fragments from massive amounts of memory data, effectively solving the memory bottleneck problem for agents processing complex tasks.

[0061] It should be noted that the agent's memory data is dynamically updated as steps are executed. This memory data can be obtained as follows: If the target step is completed, the step execution data and tool call data of the target step are used as short-term complete execution data. This step execution data includes execution completion time, step identifier, execution result summary, and dependency data. If the number of short-term complete execution data is greater than a specified number, data to be compressed is determined from multiple short-term complete execution data based on the execution completion time. Triples are extracted from the data to be compressed, and each triple includes a subject, predicate, and object. All the triples, step identifiers, execution result summaries, and dependency data of the data to be compressed are combined to generate nodes as long-term compressed execution data.

[0062] After an agent completes the target step, it can use the step execution data and tool call data generated during the execution of the target step as short-term complete execution data. Specifically, when executing the target step, the agent can obtain the step identifier, execution result, execution completion time, and dependency data corresponding to the target step. To avoid excessive redundancy, the execution results can be summarized, that is, its output is extracted, and the core insights valuable to the final task are recorded as the execution result summary.

[0063] A step identifier can be used to uniquely identify a specific step in a task to be processed, while dependency data refers to the step identifier of the previous step that triggered or provided the key preconditions for the target step. Of course, step execution data can also include the final state of the target step, i.e., whether the step was executed successfully. Tool invocation data can include information such as the specific tool invoked in executing the task to be processed and the result of the tool invocation. The task execution data and tool invocation data can be directly used as short-term complete execution data. In this embodiment of the invention, the data structure of the short-term complete execution data is as follows:

[0064] "step_id: A unique identifier for a step."

[0065] step_goal: The original description of this step.

[0066] tool_invocation_log: A log list that records detailed information about all tool calls in this step, including tool name, parameters, key result summaries, and verification information for the tool call results.

[0067] key_finding: The core insights that are valuable to the final task objective, derived from refining all the outputs of this step.

[0068] status: The final status of the step, such as COMPLETED_SUCCESS, FAILED_REPLANNED.

[0069] timestamp: The timestamp when the step is completed.

[0070] causal_source_id: Points to the step_id of the previous step that triggered or provided the critical preconditions for this step.

[0071] The short-term complete execution data carries relatively detailed and comprehensive information. The agent has certain limitations on the amount of short-term complete execution data, that is, the amount of short-term complete execution data shall not exceed a specified amount. The specified amount can be set according to actual needs, and no specific limit is set here.

[0072] After each step is completed, corresponding short-term complete execution data is generated. For each short-term complete execution data point generated, the current number of such data points for the agent can be determined. If the number exceeds a specified limit, some of the short-term complete execution data needs to be compressed to convert it into long-term compressed execution data. Specifically, to ensure the timeliness of the short-term complete execution data, the execution completion time within the data can be obtained, and the short-term complete execution data point with the completion time furthest from the current time is selected as the data to be compressed.

[0073] For example, if the specified quantity is 3, the short-term complete execution data includes [SSM_3, SSM_2, SSM_1], where SSM_3 has the shortest execution completion time from the current time, and SSM_1 has the longest execution completion time from the current time. If a new task completes and generates a new short-term complete execution data set SSM_4, then SSM_1 needs to be converted to long-term compressed execution data and deleted from the short-term complete execution data set. The short-term complete execution data will then be [SSM_4, SSM_3, SSM_2].

[0074] One approach to converting data to be compressed into long-term compressed execution data is to directly extract a portion of key data from the data to be compressed as the long-term compressed execution data. Alternatively, the data to be compressed can be digested to obtain corresponding digest data, which can then be used as the long-term compressed execution data.

[0075] As one implementation method, when converting data to be compressed into long-term compressed execution data, the subject, predicate, and object can be extracted from the data to be compressed to form triples. It should be noted that this extraction requires combining all subjects, predicates, and objects involved in the data to be compressed to form multiple triples. All extracted triples, the task identifier corresponding to the task to be processed, and the execution result summary are combined and used as a node in the graph data, and this node is used as the long-term compressed execution data.

[0076] In other words, the essence of long-term compressed execution data of an intelligent agent is graph data. By taking a long-term compressed execution data as a node in the graph data, the relationship between these data can be established through the nodes in the graph data to form memory data with relationships.

[0077] Specifically, when converting data to be compressed into long-term compressed execution data, a large language model can be used for processing. For example, compression prompts can be pre-set, which may include role information, specific compression requirements, etc. The compression prompts are input into the large language model, and the data to be compressed is used as the input of the model. The large language model is then guided to convert the data to be compressed into long-term compressed execution data according to the specific compression requirements in the compression prompts.

[0078] The specific compression prompt could be: "Role: You are a memory graph building engine. Task: Based on the content provided below, extract its core information and output it in a strict JSON format. The JSON must contain three keys: summary_finding, entities_relations, and causal_link. In entities_relations, extract all entities and their relationships as completely as possible in the form of triples of [subject, predicate, object]."

[0079] If the data to be compressed is:

[0080]

[0081] After processing by the large language model, the resulting long-term compressed execution data is as follows:

[0082]

[0083] Among them, node_id is step_id in short-term complete execution data, summary_finding is key_finding in short-term complete execution data, entities_relations are all extracted triples, causal_link is causal_source_id in short-term complete execution data, representing dependency data, which refers to the step identifier of the previous step that triggered or provided the key preconditions of this step.

[0084] Understandably, after converting the data to be compressed into long-term compressed execution data, the data to be compressed is deleted from the short-term complete execution data, thus ensuring that the number of short-term complete execution data never exceeds the specified limit. Short-term complete execution data with a relatively long execution completion time from the current time is automatically converted into a node in the graph data, i.e., long-term compressed execution data.

[0085] In summary, the agent's memory data includes no more than a specified number of short-term complete execution data and long-term compressed execution data that serves as nodes in the graph data. Whenever the agent completes a new task to be processed, it updates the memory data by converting a portion of the short-term complete execution data into long-term compressed execution data based on a specified number and execution completion time.

[0086] S130. Combine the reference memory data to call the tool to be called, and obtain the tool call result.

[0087] After retrieving the reference memory data, it can be used as context. The agent can then invoke the desired tool based on this context to execute the target step. After invoking the corresponding tool, the result of the tool invocation can be obtained.

[0088] S140. If the tool call result is invalid, obtain the call diagnostic data of the tool to be called.

[0089] The tool invocation result can include the following: successful invocation and return of correct content, successful invocation but return of incorrect content, and invocation failure. In this embodiment of the invention, only the case of successful invocation and return of correct content is considered a valid tool invocation result; all other cases are considered invalid tool invocation results.

[0090] If the tool call result is invalid, in order to clarify the specific reason for the invalidity and modify the execution plan accordingly to improve the success rate of task execution, the call diagnostic data of the tool to be called can be obtained. This call diagnostic data may include data such as the reason for invalidity.

[0091] As one implementation method, diagnostic data can be obtained as follows: the target step description, tool call result, the call data of the tool to be called, and the tool output are filled into the diagnostic template to obtain diagnostic prompt words; the diagnostic prompt words are used to guide the large language model to verify the validity of the tool call result to obtain the verification result and the corresponding confidence level; if the confidence level is less than a specified value, the failure type is determined from the preset types and the call diagnostic data of the tool to be called is generated.

[0092] In other words, after obtaining the tool invocation result, the agent can invoke a large language model to verify the validity of the result, determining whether it is effective. This verification result will also be included in the memory data subsequently. Specifically, it can verify whether the tool invocation result matches the target step description; if they match, the result is considered valid; if they do not match, the result is considered invalid. To ensure the consistency and accuracy of the verification, a diagnostic template can be pre-set. This template consists of prompt words used to pre-evaluate the validity of the tool invocation result.

[0093] The diagnostic template may include a description of the target steps, data on the specific tools invoked, and the raw output of the tools, i.e., the tool invocation results. In this embodiment of the invention, the diagnostic template may be:

[0094] Role: You are an AI agent execution quality analyst. Task: Analyze whether the execution of the following tools successfully achieved the "step objectives." Please output your analysis strictly according to the specified JSON format, where `confidence_score` represents your confidence that the tool output successfully met the step objectives, and `suggested_action` is your recommended next step. If your confidence is low, please indicate the most likely root cause of failure in `failure_category` and provide a detailed explanation in `diagnosis_details`.

[0095] Input context:

[0096] Objective: "Obtain the current stock price of Company A."

[0097] Tool call: get_stock_price(ticker='FYTR')

[0098] Raw tool output: {"error":"Invalidticker symbol","code":400}

[0099] Your output (must be in JSON format):

[0100] Fill the corresponding content into the diagnostic template to obtain the corresponding diagnostic prompts. Inputting these prompts into the large language model guides the model to analyze whether the step objectives in the target step description have been achieved, and provides the confidence level for "achieved the step objectives in the target step description." Confidence level refers to the large language model's confidence in the given conclusion; the higher the confidence level, the stronger the confidence.

[0101] A specified value can be preset. After obtaining the confidence level, compare the confidence level with the specified value. If the confidence level is not less than the specified value, it can be considered that the model has strong confidence in the given conclusion, indicating that the tool call result has achieved the step objective in the target step description, and the tool call result is valid.

[0102] If the confidence level is less than the specified value, it can be considered that the model has low confidence in the given conclusion, indicating that the tool invocation result has not achieved the step objective in the target step description, and the tool invocation result is invalid. At this time, the large language model needs to further reason and analyze to find the root cause of the invalid tool invocation result and provide corresponding detailed explanations as invocation diagnostic data.

[0103] Optionally, multiple preset types can be pre-set. These preset types are categorized based on possible reasons for invalid tool calls. The preset types can be set according to actual needs and are not specifically limited here.

[0104] In this embodiment of the invention, the preset types may include precondition mismatch types, tool return error types, assumption error types, and external environment change types. A precondition mismatch type means that the preconditions of the tool to be invoked are not met in the current state. A tool return error type means that the tool to be invoked executes successfully but returns useless or erroneous content, such as a 404 page or an advertisement. An assumption error type means that a fundamental assumption in the execution plan is falsified, such as the execution plan assuming that a website does not require login, but in reality, login is required. An external environment change type means that the external environment changes, such as a change in the website's API interface.

[0105] The large language model can select invalid types from preset types based on the analysis results, and generate call diagnostic data based on the invalid type and the analysis and inference results. The call diagnostic data can include the step identifier corresponding to the target step, the tool to be called, the time, the confidence level, the invalid type, the recommended next step, and a detailed reason for the invalidity.

[0106] For example, in the diagnostic prompt given in the previous example, the step objective is: to obtain the current stock price of Company A. The large language model can analyze that the objective is to obtain the stock price of Company A, but the tool returned an error. The error message is an invalid stock code, indicating that the tool itself is not faulty, but the input parameter "FYTR" may be an incorrect code. This is unrelated to network fluctuations and is due to the assumption that "FYTR" is a valid code, leading to the invalid result. Therefore, the large language model can generate the corresponding call diagnostic data as follows:

[0107]

[0108] S150. Using the invalid type, update the execution plan to obtain a new execution plan.

[0109] After obtaining the invalid type in the diagnostic data, a matching plan update strategy can be selected based on the invalid type to update the execution plan and obtain a new execution plan, so as to ensure that the task to be processed can be executed normally.

[0110] Among them, the preset type can be set with its corresponding preset strategy to obtain the strategy mapping relationship. Based on the invalid type in the diagnostic data, the corresponding preset strategy is found from the strategy mapping relationship. The agent executes the found preset strategy to update the execution plan and obtain a new execution plan.

[0111] As one implementation method, if the invalid type includes a preceding mismatch type, the agent updates the execution plan to obtain a new execution plan. This can be achieved by calling a large language model to analyze and process the call diagnostic data to generate a specified step; inserting the specified step before the target step in the execution plan to obtain a plan to be verified; if a specified tool matching the specified step is found in the preset tool library, the plan to be verified is used as the new execution plan; if no specified tool matching the specified step is found in the preset tool library, the process returns to calling the large language model to analyze and process the call diagnostic data to generate the specified step and subsequent steps, until a specified number of times is reached.

[0112] For example, see Figure 4 This diagram illustrates a flowchart of an updated execution plan. The agent can invoke a large language model to analyze and process the input diagnostic data, understanding the specific reasons for invalidity, such as an expired API key causing the tool call to fail. To avoid invalid call results, the large language model needs to obtain a valid key. Optionally, the large language model can use the analyzed content as prompts, and then generate specific steps based on these prompts to prevent invalid tool call results. For example, the prompt might be: "Background: The previous step failed because the API key expired. Task: Generate a concise, executable new step to obtain a valid API key." Inputting this prompt into the large language model, it can generate specific steps, such as "Obtain a new API key for financial data services."

[0113] The agent can obtain the execution plan, locate the target step in the specified plan, and then insert the specified step before the target step to obtain the plan to be verified. For example, if the execution plan is step 1-step 2-step 3-step 4, and the target step is step 3, then the plan to be verified can be: step 1-step 2-specified step-step 3-step 4.

[0114] To ensure the feasibility of the plan to be verified, it can be verified to ensure that the repair is effective. Specifically, for a specified step, a specified tool matching the specified step can be searched in a preset tool library. The specific search method can be referred to the corresponding part of the foregoing embodiments, and is not specifically limited here.

[0115] If a specified tool matching the specified steps is found in the preset tool library, the plan to be verified is considered executable, and can then be used as a new execution plan. The agent can then continue executing this new execution plan from the specified steps to properly perform the tasks to be processed.

[0116] If no matching tool is found in the preset tool library for the specified step, it indicates that the agent cannot execute the specified step. In this case, the plan to be verified cannot be completed, and it can be considered an invalid repair solution. Since the plan to be verified has already been generated, a rollback operation can be performed to revert the plan to be verified to an execution plan, and then try again.

[0117] In other words, the system can return to the large language model to analyze and process the diagnostic data, generating the specified steps and subsequent steps. Optionally, upon retrying, the system can carry the previous failure information and generate the specified steps based on that information. The specified number of iterations is a pre-set loop count, which can be set according to actual needs. For example, setting it to 1 means that after one iteration (one loop), if no matching tool for the specified step is found in the preset tool library, it indicates that the problem cannot be resolved independently, the loop ends, and a reporting and manual intervention process is triggered.

[0118] As one implementation method, if the invalid type includes the tool returning an error type, when the agent updates the execution plan to obtain a new execution plan, it may be as follows: if the number of retries for the target step is less than a preset number, other tools to be called are invoked for retry processing; if all tools to be called fail to retries or the number of retries exceeds the preset number, the step target in the description of the target step is downgraded based on the tool invocation results of the tools to be called, to obtain a step to be used; the target step is replaced with the step to be used to obtain a new execution plan.

[0119] A tool returning an error type indicates that although the tool was successfully invoked, the returned content was incorrect, which may be due to a problem with the tool itself. Since there are usually multiple tools identified for invocation, the number of retries for the target step can be determined first. If the number of retries is less than the preset number, it indicates that retries can continue. The preset number of retries can be set according to actual needs and is not specifically limited here. Other tools can be selected for retries. If a valid tool invocation result is obtained after retries with other tools, execution can continue according to the original execution plan.

[0120] If all retries to be invoked fail, meaning that trying all the tools still cannot yield a valid tool invocation result, or if the preset number of retries has been reached and further retries are not possible, the step objective in the target step description can be downgraded based on the tool invocation results to obtain the step to be used.

[0121] The target step description typically describes the objective to be achieved by the step. If the agent cannot achieve this objective by calling other tools, the step objective can be downgraded. For example, if the original step objective is "download Company A's 100-page PDF annual report," and the tool calls to the other tools all result in accessing the web version of the annual report, the downgraded step objective could be "extract and summarize the key financial data from Company A's annual report from the web page."

[0122] As one implementation method, degradation processing can be achieved using prompt words and a large language model. The prompt word can provide background and specific tasks, and the large language model can automatically generate the prompt word to use based on the prompt word template after analyzing the aforementioned invocation of the tool to be invoked. The prompt word template can include background and tasks. The background can include the step objectives and an overview of the results returned by the currently invoked tool. The task can be modifying the original objective into a new objective that can be completed based on the results returned by the currently invoked tool.

[0123] For example, the prompt could be: "Background: The original goal of downloading Company A's complete 100-page PDF annual report has failed; all tools can only access the web version. Task: Please modify the original goal to a new goal that can be completed based on the existing web content." Inputting this prompt into the large language model will output the steps to be used. Replacing the target steps in the execution plan with the steps to be used will generate a new execution plan, which can then be executed starting from the steps to be used. For example, if the execution plan is Step 1-Step 2-Step 3-Step 4, and the target step is Step 3, the new execution plan would be: Step 1-Step 2-Step to be used-Step 4.

[0124] As one implementation method, invalidity types can include assumption error types, where steps in the execution plan are made based on a certain assumption that is incorrect, and therefore cannot be executed normally. In this case, it is necessary to find the affected subsequent steps and verify whether these steps still hold true under the incorrect assumption. If the steps are verified to be true, they can be retained in the execution plan; if the steps are verified to be false, they are deleted to obtain a new execution plan.

[0125] The aforementioned long-term compressed execution data includes dependency data and node identifiers. Dependency data refers to the step identifier of the previous step that triggered or provided the key prerequisites for this step. For example, if the target step is step 3, and steps 1 and 2 both provided the prerequisites required for step 3, then the dependency data for step 3 could include the step identifiers of steps 1 and 2.

[0126] When the agent updates the execution plan and obtains a new execution plan, it can construct influence data based on the dependency data and node identifiers. The influence data includes multiple steps in the execution plan and the influence steps corresponding to each step. The target influence step is retrieved from the influence data. For each target influence step, if the target influence step cannot be established under the assumption of error, the target influence step is deleted from the execution plan to obtain a new execution plan.

[0127] See also Figure 5 This illustrates another flowchart for updating the execution plan, where the impact data includes multiple steps in the execution data and the impact steps corresponding to each step. In other words, the impact data represents the inverse relationship between the dependency data. As in the previous example, steps 1 and 2 provide key preconditions for step 3. If a problem occurs in step 1 or step 2, step 3 cannot proceed normally. Therefore, for step 1, the corresponding impact step is step 3, and for step 2, the corresponding impact step is step 3.

[0128] By utilizing the dependency data and node identifiers in the long-term compressed execution data, the impact data can be constructed. Optionally, the impact data can be continuously iterated and updated as the long-term compressed execution data is generated, avoiding the need to create it from scratch when required, thus reducing the execution efficiency of the task.

[0129] Optionally, when constructing impact data based on dependency data and node identifiers, an impact dictionary may be obtained, which includes keywords and their corresponding values. For each piece of long-term compressed execution data obtained, the dependency step identifier in the dependency data is retrieved from the keywords in the impact dictionary. If the dependency step identifier is found, the corresponding keyword in the impact dictionary is used as the target keyword. If the dependency step identifier is not found, the keyword corresponding to the dependency step identifier is added to the impact dictionary, and the keyword is used as the target keyword. The node identifier in the long-term compressed execution data is added to the impact dictionary as the target value corresponding to the target keyword to obtain the impact data.

[0130] The influence dictionary can include keywords and their corresponding values. A dictionary structure can be pre-created as the influence dictionary. After each long-term compressed execution is acquired, the corresponding dependency step identifier in the dependency data can be retrieved from the keywords in the influence dictionary. If the dependency step identifier is found, the retrieved keyword can be directly used as the target keyword. If not found, the keyword corresponding to the dependency step identifier is added to the influence dictionary and used as the target keyword. Then, the node identifiers in the long-term compressed execution data are added to the influence dictionary as the target values ​​corresponding to the target keywords, thus obtaining the influence data. The influence data can be understood as graph data, containing various steps, each step pointing to the steps it influences.

[0131] The target step is the currently executing step. Searching the impact data based on the target step retrieves the target impact steps. The target impact steps refer to the subsequent steps that the target step will affect. When retrieving target impact steps, a first queue and a second queue can be created, and the target step can be placed in the first queue. A step is taken from the head of the first queue as the first step. The impact data is searched for the corresponding impact step of the first step to obtain the second step, and the second step is added to the tail of the first queue. If the second queue does not contain the second step, the second step is added to the second queue. The process of taking a step from the head of the first queue as the first step is repeated until the first queue is empty. Finally, the steps in the second queue are used as the target impact steps.

[0132] Since the execution of the target step resulted in an invalid tool call, other steps in the execution plan affected by the failure of the target step's assumption can be identified based on the impact data. These are denoted as target-affected steps. For each target-affected step, it can be verified whether the target-affected step holds true under the incorrect assumption, i.e., whether the step is valid. If valid, it can be retained without further processing; if invalid, the target-affected step is deleted from the execution plan to obtain a new execution plan.

[0133] Optionally, a large language model can be used to verify whether the target's impact on the steps holds true under the assumption that the error is incorrect. Similarly, a cue word is provided to the large language model so that it outputs a valid or invalid result. This cue word may contain the incorrect assumption and the task the large language model needs to perform. For example, the cue word could be: "Background: The assumption in the previous step that 'xyzw is a valid stock code' is incorrect. Task: Determine whether the following step 'conducting trend analysis based on the historical stock price of xyzw' is valid. Please answer 'valid' or 'invalid'."

[0134] If the large language model outputs "valid," it indicates that the target's impact on the steps is valid, and they can be retained in the execution plan. If the large language model outputs "invalid," it indicates that the target's impact on the steps is invalid, and they can be deleted from the execution plan. Since this modification may delete a large number of steps, a user prompt can be triggered after deletion to display the diagnostic results and remediation plan to the user. For example: "The original plan was aborted due to an incorrect stock code. Subsequent analysis steps will not be deleted. Do you need to provide a new stock code to continue?" User prompts ensure that the remediation aligns with the user's intent.

[0135] As one implementation method, invalid types can also include external environment change types. In this case, the problem lies with the tool itself, not the execution plan. A specified tag can be added to the tool to be invoked in the preset tool library; an alternative tool to the tool to be invoked is searched from other tools in the preset tool library, where the other tools are those without the specified tag; if the alternative tool is found, it is invoked to re-execute the target steps; if the alternative tool is not found, the execution of the task to be processed is paused and a prompt message is generated.

[0136] If the tool to be invoked encounters a problem, to avoid affecting other steps or tasks, a specific tag can be added to the tool in the preset tool library. Then, a corresponding alternative tool can be searched among the other tools in the preset library (tools without the specified tag). If an alternative tool is found, it is invoked to retry the target step. If no alternative tool is found, it indicates the problem cannot be resolved, and the pending task can be paused and a prompt message generated. This prompt message may include diagnostic data, clearly state the reason for the failure, and request manual intervention. This prompt message can be sent to designated users through a specified channel set by the development or operations personnel so that users can be informed of the specific situation.

[0137] S160. Execute the pending tasks according to the new execution plan.

[0138] After receiving the new execution plan, subsequent steps can be directly executed according to the new plan to perform pending tasks. Understandably, when executing pending tasks according to the new execution plan, the process remains the same as described above: for the currently executing target step, the process of determining the tool to be invoked, retrieving reference memory data, and after invoking the tool, judging the validity of the tool invocation result. If invalid, the execution plan can be modified until the task is completed or manual intervention is triggered. Therefore, during task execution, the agent can flexibly adjust the execution plan based on the actual execution situation to ensure the normal execution of the task.

[0139] The agent-based task execution scheme provided in this invention can be applied to various complex task execution scenarios, such as data analysis and decision-making in various scenarios. By using the agent-based task execution method provided in this invention, and through the setting of special memory data, the situation of memory forgetting in complex tasks can be avoided. Moreover, each time the tool is called, the tool result is verified to prevent erroneous results from flowing into subsequent processes. When the tool result is invalid, the execution plan can be flexibly adjusted according to the strategy to improve the success rate of complex task execution.

[0140] The method provided by the embodiments of the present invention can perform a validity review on the tool call result after the tool call, ensuring that the tool call result is correct. When the tool call result is incorrect, the execution plan can be automatically modified through an analysis and error correction mechanism, ensuring that the agent has the ability to repair the plan. Furthermore, the memory data includes short-term complete execution data and long-term compressed execution data, which can ensure that the agent uses all historical data to make decisions, thereby improving the success rate and accuracy of task execution.

[0141] To better implement the above methods, embodiments of the present invention also provide an agent-based task execution device, which can be integrated into an electronic device, such as a terminal or server. The terminal can be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, personal computer, etc.; the server can be a single server or a server cluster composed of multiple servers.

[0142] For example, in this embodiment, the method of the present invention will be described in detail by taking the integration of an agent-based task execution device into a server as an example.

[0143] For example, such as Figure 6 As shown, the agent-based task execution device 200 may include a plan generation module 210, a determination module 220, a call result module 230, a diagnosis acquisition module 240, an update module 250, and an execution module 260.

[0144] The plan generation module 210 is used to generate an execution plan based on the task description of the task to be processed. The execution plan includes multiple sub-steps with an execution order, and each sub-step has a corresponding sub-step description.

[0145] The determination module 220 is used to determine the tool to be called from a preset tool library and retrieve reference memory data from the agent's memory data for each target step, using the target step description corresponding to the target step. The target step is the currently executed sub-step determined according to the execution order.

[0146] The result invocation module 230 is used to invoke the tool to be invoked in conjunction with the reference memory data, and obtain the tool invocation result;

[0147] The diagnostic acquisition module 240, if the tool call result is invalid, acquires the call diagnostic data of the tool to be called, the call diagnostic data including invalidity type;

[0148] The update module 250 updates the execution plan using the invalid type to obtain a new execution plan;

[0149] Execution module 260 executes the pending tasks according to the new execution plan.

[0150] In some embodiments, the memory data includes short-term complete execution data and long-term compressed execution data, and the determining module 220 is specifically used for:

[0151] For each target step, the tool to be invoked is determined based on the similarity between the target step description and each preset tool in the preset tool library;

[0152] Convert the key entities in the target step description into graph query statements;

[0153] Based on the graph query statement, a reference subgraph is retrieved from the long-term compressed execution data;

[0154] The reference subgraph and the short-term complete execution data are combined to obtain reference memory data.

[0155] In some embodiments, the determining module 220 is specifically used for:

[0156] In the long-term compressed execution data, the entity node directly associated with the key entity is retrieved and designated as the first node;

[0157] The neighboring nodes of the first node in the long-term compressed execution data are identified as the second node;

[0158] Obtain the dependent nodes of the first node and the second node, and use them as the third node;

[0159] Based on the target step description, the subgraph consisting of the first node, the second node, and the third node is pruned to obtain a reference subgraph.

[0160] In some embodiments, the agent-based task execution device 200 further includes a memory module, which is specifically used for:

[0161] If the target step is completed, the step execution data and tool call data of the target step are used as short-term complete execution data. The step execution data includes the execution completion time, step identifier, execution result summary and dependency data.

[0162] If the number of short-term complete execution data is greater than the specified number, the data to be compressed is determined from the multiple short-term complete execution data according to the execution completion time;

[0163] Extract triples from the data to be compressed, wherein the triples include a subject, a predicate, and an object;

[0164] Combine all the triples, step identifiers, execution result summaries, and dependency data of the data to be compressed to generate nodes as long-term compressed execution data.

[0165] In some embodiments, the agent-based task execution device 200 further includes a diagnostic module. Before obtaining diagnostic data for the tool to be invoked if the tool invocation result is invalid, the diagnostic module is specifically used for:

[0166] The target step description, tool call result, tool call data, and tool output are filled into the diagnostic template to obtain diagnostic prompt words;

[0167] The diagnostic prompts are used to guide a large language model to verify the effectiveness of the tool's call results, and the verification results and corresponding confidence levels are obtained.

[0168] If the confidence level is less than a specified value, the failure type is determined from the preset types and the call diagnostic data of the tool to be called is generated.

[0169] In some embodiments, the invalid type includes a preceding mismatch type, and the update module 250 is specifically used for:

[0170] The large language model is invoked to analyze and process the diagnostic data to generate the specified steps;

[0171] The specified step is inserted before the target step in the execution plan to obtain the plan to be verified.

[0172] If a specified tool matching the specified step is found in the preset tool library, the plan to be verified is used as a new execution plan;

[0173] If no matching tool is found in the preset tool library for the specified step, the process returns to call the large language model to analyze and process the call diagnostic data to generate the specified step and subsequent steps, until the specified number of times is reached.

[0174] In some embodiments, the invalid type includes the tool-returned error type, and the update module 250 is specifically used for:

[0175] If the number of retries for the target step is less than the preset number, other tools to be called will be invoked for retry processing.

[0176] If all the tools to be invoked fail to retries or the number of retries exceeds the preset number, the step target in the target step description is downgraded based on the tool invocation results of the tools to be invoked, and the step to be used is obtained.

[0177] The target step is replaced with the step to be used to obtain a new execution plan.

[0178] In some embodiments, the memory data includes long-term compressed execution data, which includes dependency data and node identifiers; the invalid type includes the assumption error type; and the update module 250 is specifically used for:

[0179] Impact data is constructed based on the dependency data and node identifiers. The impact data includes multiple steps in the execution plan and the impact steps corresponding to each step.

[0180] The target impact step is retrieved from the impact data according to the target step.

[0181] For each of the target impact steps, if the target impact step cannot be established under the assumption of error, the target impact step is deleted from the execution plan, and a new execution plan is obtained.

[0182] In some embodiments, the update module 250 is specifically used for:

[0183] Obtain the influence dictionary, which includes keywords and their corresponding values;

[0184] For each piece of long-term compressed execution data acquired, the dependency step identifier in the dependency data is retrieved from the keywords of the influence dictionary;

[0185] If the dependent step identifier is found, the corresponding keyword in the influence dictionary will be used as the target keyword.

[0186] If the dependent step identifier is not found, add the keyword corresponding to the dependent step identifier to the influence dictionary and use the keyword as the target keyword.

[0187] The node identifiers in the long-term compressed execution data are added to the impact dictionary as the target values ​​corresponding to the target keywords to obtain the impact data.

[0188] In some embodiments, the update module 250 is specifically used for:

[0189] Create a first queue and a second queue, and place the target step into the first queue;

[0190] Take a step from the head of the first queue as the first step;

[0191] The impact step corresponding to the first step is found in the impact data search, the second step is obtained, and the second step is added to the tail of the first queue;

[0192] If the second step is not present in the second queue, add the second step to the second queue;

[0193] Return to the step that takes a step from the head of the first queue as the first step and the subsequent steps, until the first queue is empty, then take the steps in the second queue as the target affected steps.

[0194] In practice, the above modules can be implemented as independent entities or combined in any way to be implemented as the same or several entities. For the specific implementation of the above modules, please refer to the previous method implementation examples, which will not be repeated here.

[0195] As can be seen from the above, the agent-based task execution device of this embodiment can break down the execution of the task to be processed into multiple steps. For each target step being executed, the corresponding step description is used to determine the tool to be invoked and the reference memory data. The tool to be invoked is then invoked based on the reference memory data to obtain the tool invocation result. When the tool invocation result is invalid, invocation diagnostic data containing the invalidity type is obtained. The execution plan is updated according to the invalidity type to obtain a new execution plan, and finally, execution continues according to the new execution plan. By validating the tool invocation result, generating invocation diagnostic data containing invalidity types, and repairing the execution plan according to the specific invalidity type, the execution plan can be flexibly adjusted according to the execution situation, ensuring the successful execution of the task to be processed and thus improving the success rate of task execution.

[0196] This invention also provides an electronic device, which can be a terminal, a server, or other similar devices. The terminal can be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, personal computer, etc.; the server can be a single server or a server cluster composed of multiple servers, etc.

[0197] In some embodiments, the agent-based task execution device can also be integrated into multiple electronic devices. For example, the agent-based task execution device can be integrated into multiple servers, and the agent-based task execution method of the present invention can be implemented by multiple servers.

[0198] In this embodiment, a server will be used as an example for detailed description. For example, ... Figure 7 As shown, it illustrates a structural schematic diagram of the electronic device involved in an embodiment of the present invention, specifically:

[0199] The electronic device may include components such as a processor 310 with one or more processing cores, a memory 320 with one or more computer-readable storage media, a power supply 330, an input module 340, and a communication module 350. Those skilled in the art will understand that... Figure 7 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0200] The processor 310 is the control center of the electronic device, connecting various parts of the device via various interfaces and lines. It executes various functions and processes data by running or executing software programs and / or modules stored in the memory 320, and by calling data stored in the memory 320. In some embodiments, the processor 310 may include one or more processing cores; in some embodiments, the processor 310 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 310.

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

[0202] The electronic device also includes a power supply 330 that supplies power to the various components. In some embodiments, the power supply 330 can be logically connected to the processor 310 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 330 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0203] The electronic device may also include an input module 340, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0204] The electronic device may also include a communication module 350. In some embodiments, the communication module 350 may include a wireless module, through which the electronic device can perform short-range wireless transmission, thereby providing users with wireless broadband internet access. For example, the communication module 350 can be used to help users send and receive emails, browse web pages, and access streaming media.

[0205] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 310 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 320 according to the following instructions, and the processor 310 runs the applications stored in the memory 320, thereby implementing the steps in the methods of the various embodiments of the present invention.

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

[0207] As can be seen from the above, the electronic device provided in this embodiment of the invention can break down the execution of a task into multiple steps. For each target step being executed, the corresponding step description is used to determine the tool to be invoked and reference memory data. Based on the reference memory data, the tool to be invoked is invoked to obtain the tool invocation result. When the tool invocation result is invalid, invocation diagnostic data containing invalid types is obtained. The execution plan is updated according to the invalid type to obtain a new execution plan, and finally, execution continues according to the new execution plan. By validating the tool invocation result, generating invocation diagnostic data containing invalid types, and repairing the execution plan according to the specific invalid type, the execution plan can be flexibly adjusted according to the execution situation, ensuring the successful execution of the task and thus improving the success rate of task execution.

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

[0209] To this end, embodiments of the present invention provide a computer-readable storage medium storing a plurality of instructions which can be loaded by a processor to execute steps in any of the agent-based task execution methods provided in embodiments of the present invention.

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

[0211] According to one aspect of the present invention, a computer program product or computer program is provided, comprising a computer program / instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer program / instructions from the computer-readable storage medium and executes the computer program / instructions, causing the electronic device to perform the methods provided in various optional implementations of the agent-based task execution aspect of the above embodiments.

[0212] Since the instructions stored in the storage medium can execute the steps in any of the agent-based task execution methods provided in the embodiments of the present invention, the beneficial effects that any of the agent-based task execution methods provided in the embodiments of the present invention can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0213] The above provides a detailed description of a task execution method based on an intelligent agent provided by the embodiments of the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A task execution method based on an intelligent agent, characterized in that, The method includes: An execution plan is generated based on the task description of the task to be processed. The execution plan includes multiple sub-steps with an execution order, and each sub-step has a corresponding sub-step description. For each target step, the target step description corresponding to the target step is used to determine the tool to be called from the preset tool library and retrieve reference memory data from the agent's memory data. The target step is the currently executed sub-step determined according to the execution order. By combining the reference memory data, the tool to be invoked is called to obtain the tool invocation result; If the tool call result is invalid, obtain the call diagnostic data of the tool to be called. The call diagnostic data includes invalidity type, which is selected from preset types. The preset types are types obtained after classifying the reasons for invalidity. The execution plan is updated using the invalid type to obtain a new execution plan; Execute the pending tasks according to the new execution plan; The memory data includes short-term complete execution data and long-term compressed execution data. For each target step, the process of determining the tool to be invoked from a preset tool library and retrieving reference memory data from the agent's memory data, using the target step description corresponding to that target step, includes: For each target step, the tool to be invoked is determined based on the similarity between the target step description and each preset tool in the preset tool library; the key entities in the target step description are converted into graph query statements; a reference subgraph is retrieved from the long-term compressed execution data based on the graph query statements; and the reference subgraph and the short-term complete execution data are fused to obtain reference memory data.

2. The method according to claim 1, characterized in that, The step of retrieving reference subgraphs from the long-term compressed execution data based on the graph query statement includes: In the long-term compressed execution data, the entity node directly associated with the key entity is retrieved and designated as the first node; The neighboring nodes of the first node in the long-term compressed execution data are identified as the second node; Obtain the dependent nodes of the first node and the second node, and use them as the third node; Based on the target step description, the subgraph consisting of the first node, the second node, and the third node is pruned to obtain a reference subgraph.

3. The method according to claim 1, characterized in that, The memory data is obtained in the following way: If the target step is completed, the step execution data and tool call data of the target step are used as short-term complete execution data. The step execution data includes the execution completion time, step identifier, execution result summary and dependency data. If the number of short-term complete execution data is greater than the specified number, the data to be compressed is determined from the multiple short-term complete execution data according to the execution completion time; Extract triples from the data to be compressed, wherein the triples include a subject, a predicate, and an object; Combine all the triples, step identifiers, execution result summaries, and dependency data of the data to be compressed to generate nodes as long-term compressed execution data.

4. The method according to claim 1, characterized in that, If the tool call result is invalid, before obtaining the call diagnostic data of the tool to be called, the method further includes: The target step description, tool call result, tool call data, and tool output are filled into the diagnostic template to obtain diagnostic prompt words; The diagnostic prompts are used to guide a large language model to verify the effectiveness of the tool's call results, and the verification results and corresponding confidence levels are obtained. If the confidence level is less than a specified value, the failure type is determined from the preset types and the call diagnostic data of the tool to be called is generated.

5. The method according to claim 1, characterized in that, The invalid types include preceding mismatch types. The process of updating the execution plan using the invalid types to obtain a new execution plan includes: The large language model is invoked to analyze and process the diagnostic data to generate the specified steps; The specified step is inserted before the target step in the execution plan to obtain the plan to be verified. If a specified tool matching the specified step is found in the preset tool library, the plan to be verified is used as a new execution plan; If no matching tool is found in the preset tool library for the specified step, the process returns to call the large language model to analyze and process the call diagnostic data to generate the steps of the specified step and subsequent steps, until the specified number of times is reached.

6. The method according to claim 1, characterized in that, The invalid types include tool-returned error types. The process of updating the execution plan using these invalid types to obtain a new execution plan includes: If the number of retries for the target step is less than the preset number, other tools to be called will be invoked for retry processing. If all the tools to be invoked fail to retries or the number of retries exceeds the preset number, the step target in the target step description is downgraded based on the tool invocation results of the tools to be invoked, and the step to be used is obtained. The target step is replaced with the step to be used to obtain a new execution plan.

7. The method according to claim 1, characterized in that, The long-term compressed execution data includes dependency data and node identifiers; the invalid types include assumption error types; and the process of updating the execution plan using the invalid types to obtain a new execution plan includes: Impact data is constructed based on the dependency data and node identifiers. The impact data includes multiple steps in the execution plan and the impact steps corresponding to each step. The target impact step is retrieved from the impact data according to the target step. For each of the target impact steps, if the target impact step cannot be established under the assumption of error, the target impact step is deleted from the execution plan, and a new execution plan is obtained.

8. The method according to claim 7, characterized in that, The construction of impact data based on the dependency data and node identifiers includes: Obtain the influence dictionary, which includes keywords and their corresponding values; For each piece of long-term compressed execution data acquired, the dependency step identifier in the dependency data is retrieved from the keywords of the influence dictionary; If the dependent step identifier is found, the corresponding keyword in the influence dictionary will be used as the target keyword. If the dependent step identifier is not found, add the keyword corresponding to the dependent step identifier to the influence dictionary and use the keyword as the target keyword. The node identifiers in the long-term compressed execution data are added to the impact dictionary as the target values ​​corresponding to the target keywords to obtain the impact data.

9. The method according to claim 7, characterized in that, The step of retrieving the target impact step from the impact data using the target step includes: Create a first queue and a second queue, and place the target step into the first queue; Take a step from the head of the first queue as the first step; The impact step corresponding to the first step is found in the impact data search, the second step is obtained, and the second step is added to the tail of the first queue; If the second step is not present in the second queue, add the second step to the second queue; Return to the execution of the step that takes a step from the head of the first queue as the first step and the subsequent steps, until the first queue is empty, and then take the steps in the second queue as the target affected steps.

Images