Agent execution method, system and equipment based on unified action semantics and medium

Abstract

The invention discloses an agent execution method, system and device based on unified action semantics and a medium. The method comprises the steps that an agent execution plan of the unified action semantics is generated based on a user task instruction; generating a standardized tool calling instruction based on the proxy execution plan, and generating a proxy execution request based on the standardized tool calling instruction; wherein the standardized tool calling instruction comprises standardized calling data and a target adapter; determining a current proxy execution environment based on the standardized tool calling instruction, issuing the proxy execution request to the current proxy execution environment, and executing the proxy execution request through the current proxy execution environment; and receiving an agent execution result returned by the current agent execution environment. According to the technical scheme, fixed configuration limitation is broken, flexible compatibility and rapid expansion of tools and dynamic selection of execution environments are achieved, and therefore the flexibility, stability and reliability of intelligent agent task execution are improved.

Description

Agent execution methods, systems, devices, and media based on unified action semantics Technical Field

[0001] This application belongs to the field of intelligent agent technology, specifically involving agent execution methods, systems, devices and media based on unified action semantics. Background Technology

[0002] Currently, intelligent agent technology driven by large language models can automatically parse complex task instructions, invoke tool resources, and automate task execution to accurately meet user needs. It has become a core support for improving production efficiency and business processing accuracy in fields such as finance, manufacturing, and the internet. However, existing technologies still have significant bottlenecks: the tool invocation logic is highly coupled with the core of the intelligent agent technology, requiring pre-configured internal settings. This makes it inflexible for new types of tools and difficult to adapt to heterogeneous tool systems in various scenarios, resulting in high costs for tool expansion and maintenance. Furthermore, the execution environment is limited to a fixed local environment or a single remote environment, which poses a risk of data leakage when facing high security requirements and performance bottlenecks when facing high computing power requirements. In short, it cannot flexibly meet execution needs, hindering the large-scale application of intelligent agent technology in complex business scenarios. Summary of the Invention

[0003] This application provides a proxy execution method, system, device, and medium based on unified action semantics, aiming to break the limitations of fixed configurations, achieve flexible compatibility and rapid expansion of tools, and dynamically select the execution environment, thereby improving the flexibility, stability, and reliability of intelligent proxy task execution.

[0004] In a first aspect, embodiments of this application provide a proxy execution method based on unified action semantics. The method includes: acquiring a user task instruction and generating a proxy execution plan with unified action semantics based on the user task instruction; wherein the proxy execution plan includes an opcode field and an input parameter field; generating a standardized tool invocation instruction based on the proxy execution plan and generating a proxy execution request based on the standardized tool invocation instruction; wherein the standardized tool invocation instruction includes standardized invocation data and a target adapter; determining the current proxy execution environment based on the standardized tool invocation instruction, sending the proxy execution request to the current proxy execution environment, and executing the proxy execution request through the current proxy execution environment; and receiving the proxy execution result returned by the current proxy execution environment.

[0005] Optionally, generating a proxy execution plan with unified action semantics based on the user task instruction includes: converting the user task instruction into a structured task target, and performing hierarchical decomposition on the structured task target to obtain sub-task targets and the corresponding constraints and resource requirements information of the sub-task targets; determining the execution dependencies between the sub-task targets based on the constraints of the sub-task targets, and determining the execution sequence of the sub-task targets based on the execution dependencies and the resource requirements information; and converting each sub-task target in the execution sequence of the sub-task targets into a proxy execution plan with unified action semantics based on a preset unified action semantics specification.

[0006] Optionally, after converting each subtask objective in the subtask objective execution sequence into a proxy execution plan based on a preset unified action semantic specification, the method further includes: obtaining the pre-execution result and determining a target exception handling strategy based on the pre-execution result; wherein, the exception handling strategy includes a re-execution strategy, a subtask modification strategy, and a subtask skipping strategy; executing the target exception handling strategy on the proxy execution plan to obtain an optimized proxy execution plan with unified action semantics; correspondingly, generating standardized tool invocation instructions based on the proxy execution plan includes: generating standardized tool invocation instructions based on the optimized proxy execution plan.

[0007] Optionally, generating standardized tool invocation instructions based on the agent execution plan includes: determining a target tool in a preset tool directory based on the opcode field; wherein the preset tool directory includes available tools and corresponding capability description information and performance description information; validating the input parameter field based on the target tool, and generating standardized invocation data based on the input parameter field if the input parameter field is valid; determining a target adapter in a preset adapter directory based on the target tool; wherein the preset adapter directory includes available adapters and corresponding capability description information; and combining the standardized invocation data and the target adapter to obtain standardized tool invocation instructions.

[0008] Optionally, determining the target tool in a preset tool directory based on the opcode field includes: determining candidate tools in the preset tool directory based on the opcode field; sorting the candidate tools based on their performance description information, and determining the first candidate tool in the sorting result as the target tool; correspondingly, after validating the input parameter field based on the target tool, the method further includes: if the input parameter field fails the validation, selecting the next candidate tool as the new target tool according to the sorting result, and validating the input parameter field based on the target tool; repeating the above steps until the input parameter field passes the validation.

[0009] Optionally, the proxy execution plan further includes an expected result field and a retry policy field; correspondingly, after receiving the proxy execution result returned by the current proxy execution environment, the method further includes: comparing the proxy execution result with the expected result field to obtain a comparison result; if the comparison result is consistent, determining that the task execution is completed; if the comparison result is inconsistent, re-executing the proxy execution request through the current proxy execution environment based on the retry policy field.

[0010] Optionally, the proxy execution plan further includes a field allowing migration to the target environment; correspondingly, after the proxy execution request is re-executed through the current proxy execution environment based on the retry policy field, the method further includes: when the number of repeated executions reaches a preset threshold, obtaining resource status information, and determining the target proxy execution environment based on the resource status information and the field allowing migration to the target environment; migrating the unfinished execution actions and intermediate states of the current proxy execution environment to the target proxy execution environment through a hot migration mechanism, and continuing to execute the unfinished execution actions through the target proxy execution environment based on the intermediate states.

[0011] Secondly, embodiments of this application provide a proxy execution system based on unified action semantics. The system includes: an execution plan generation module, used to acquire user task instructions and generate a proxy execution plan with unified action semantics based on the user task instructions; wherein the proxy execution plan includes an opcode field and an input parameter field; an execution request generation module, used to generate standardized tool invocation instructions based on the proxy execution plan and generate a proxy execution request based on the standardized tool invocation instructions; wherein the standardized tool invocation instructions include standardized invocation data and a target adapter; an execution request execution module, used to determine the current proxy execution environment based on the standardized tool invocation instructions, send the proxy execution request to the current proxy execution environment, and execute the proxy execution request through the current proxy execution environment; and an execution result receiving module, used to receive the proxy execution result returned by the current proxy execution environment.

[0012] Optionally, the execution plan generation module is specifically used for: converting the user task instruction into a structured task target, and performing hierarchical decomposition on the structured task target to obtain sub-task targets and the corresponding constraints and resource requirements information of the sub-task targets; determining the execution dependencies between the sub-task targets based on the constraints of the sub-task targets, and determining the execution sequence of the sub-task targets based on the execution dependencies and the resource requirements information; and converting each sub-task target in the execution sequence of the sub-task targets into a proxy execution plan with unified action semantics based on a preset unified action semantic specification.

[0013] Optionally, the execution plan generation module is further configured to: obtain the pre-execution result and determine the target exception handling strategy based on the pre-execution result; wherein the exception handling strategy includes a re-execution strategy, a subtask modification strategy, and a subtask skipping strategy; execute the target exception handling strategy on the proxy execution plan to obtain an optimized proxy execution plan with unified action semantics; correspondingly, the execution request generation module is specifically configured to: generate standardized tool invocation instructions based on the optimized proxy execution plan.

[0014] Optionally, the execution request generation module is specifically configured to: determine a target tool in a preset tool directory based on the opcode field; wherein the preset tool directory includes available tools and corresponding capability description information and performance description information; validate the input parameter field based on the target tool, and generate standardized invocation data based on the input parameter field if the input parameter field validation is successful; determine a target adapter in a preset adapter directory based on the target tool; wherein the preset adapter directory includes available adapters and corresponding capability description information; and combine the standardized invocation data and the target adapter to obtain a standardized tool invocation instruction.

[0015] Optionally, the execution request generation module is specifically used to: determine candidate tools in a preset tool directory based on the opcode field; sort the candidate tools based on the performance description information of the candidate tools, and determine the first candidate tool in the sorting result as the target tool; correspondingly, the execution request generation module is also used to: if the input parameter field fails the verification, select the next candidate tool as the new target tool according to the sorting result, and verify the input parameter field based on the target tool; repeat the above steps until the input parameter field passes the verification.

[0016] Optionally, the proxy execution plan further includes an expected result field and a retry policy field; correspondingly, the system is also used to: compare the proxy execution result with the expected result field to obtain a comparison result; if the comparison result is consistent, determine that the task execution is completed; if the comparison result is inconsistent, re-execute the proxy execution request based on the retry policy field through the current proxy execution environment.

[0017] Optionally, the proxy execution plan further includes a field allowing migration to the target environment; correspondingly, the system is also used to: when the number of repeated executions reaches a preset threshold, obtain resource status information, and determine the target proxy execution environment based on the resource status information and the field allowing migration to the target environment; migrate the unfinished execution actions and intermediate states of the current proxy execution environment to the target proxy execution environment through a hot migration mechanism, and continue to execute the unfinished execution actions based on the intermediate states through the target proxy execution environment.

[0018] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the method described in the first aspect.

[0019] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the method described in the first aspect.

[0020] In this embodiment, a user task instruction is obtained, and a proxy execution plan with unified action semantics is generated based on the user task instruction. The proxy execution plan includes an opcode field and an input parameter field. A standardized tool invocation instruction is generated based on the proxy execution plan, and a proxy execution request is generated based on the standardized tool invocation instruction. The standardized tool invocation instruction includes standardized invocation data and a target adapter. The current proxy execution environment is determined based on the standardized tool invocation instruction, and the proxy execution request is sent to the current proxy execution environment and executed through the current proxy execution environment. The proxy execution result returned by the current proxy execution environment is received. This proxy execution method based on unified action semantics breaks the limitations of fixed configurations, achieving flexible compatibility and rapid expansion of tools, as well as dynamic selection of the execution environment, thereby improving the flexibility, stability, and reliability of intelligent proxy task execution. Attached Figure Description

[0021] Figure 1 is a flowchart illustrating the proxy execution method based on unified action semantics provided in Embodiment 1 of this application; Figure 2 is a system architecture diagram illustrating the proxy execution system based on unified action semantics provided in Embodiment 1 of this application; Figure 3 is a flowchart illustrating the proxy execution method based on unified action semantics provided in Embodiment 2 of this application; Figure 4 is a flowchart illustrating the proxy execution method based on unified action semantics provided in Embodiment 3 of this application; Figure 5 is a flowchart illustrating the proxy execution method based on unified action semantics provided in Embodiment 4 of this application; Figure 6 is a structural diagram illustrating the proxy execution system based on unified action semantics provided in Embodiment 5 of this application; Figure 7 is a structural diagram illustrating the electronic device provided in Embodiment 6 of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0023] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0024] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0025] The following description, in conjunction with the accompanying drawings, details the proxy execution method, system, device, and medium based on unified action semantics provided in this application through specific embodiments and application scenarios.

[0026] First, this application applies to scenarios where a proxy execution system is needed to automate specific tasks and replace manual labor; that is, scenarios requiring proxy execution. Based on this application scenario, it is understood that the execution entity in this application can be a proxy execution system. Specifically, the proxy execution system can be an automated intelligent execution carrier capable of receiving user task instructions and autonomously executing the target task.

[0027] Figure 1 is a flowchart illustrating the proxy execution method based on unified action semantics provided in Embodiment 1 of this application. As shown in Figure 1, the method specifically includes the following steps: S101, obtaining user task instructions and generating a proxy execution plan with unified action semantics based on the user task instructions; wherein, the proxy execution plan includes an opcode field and an input parameter field; the user task instructions can be instruction information initiated by the user to the proxy execution system, containing clear task objectives and execution requirements, and can be natural language instructions or interface request instructions. The user task instructions can be obtained through methods such as receiving via a natural language interaction interface, accessing via an API (Application Programming Interface) gateway, and subscribing to a message queue.

[0028] Unified action semantics can be a universal semantic specification that standardizes the definition of all task execution actions, shielding the differences in underlying tool protocols and execution environments. A proxy execution plan can be a structured task scheme that can be parsed and executed. Correspondingly, a proxy execution plan (Action IR) of unified action semantics can be structured action data that conforms to the unified action semantics specification to achieve the user's task goals, and may include an opcode field and an input parameter field. Specifically, the opcode field can be a unique identifier that identifies the action type of the task execution action; the input parameter field can be the set of parameters required to complete the task execution action.

[0029] Figure 2 is a system architecture diagram of the proxy execution system based on unified action semantics provided in Embodiment 1 of this application. As shown in Figure 2, the proxy execution system adopts a five-layer hierarchical architecture design, which consists of a core decision layer 210, a tool compatibility layer 220, a tool access adaptation layer 230, a multi-environment execution proxy layer 240, and an execution environment layer 250 from top to bottom.

[0030] The method of generating a proxy execution plan with unified action semantics based on user task instructions can be achieved by using an LLM (Large Language Model) in the core decision layer to perform intent parsing and plan generation on user task instructions, thereby obtaining a proxy execution plan with unified action semantics.

[0031] S102, Generate standardized tool invocation instructions based on the agent execution plan, and generate agent execution requests based on the standardized tool invocation instructions; wherein, the standardized tool invocation instructions include standardized invocation data and a target adapter; the standardized tool invocation instructions can be unified format invocation instructions transformed by the agent execution plan and recognizable by the tool access adaptation layer, and can include standardized invocation data and a target adapter. Specifically, the standardized invocation data can be compliant data processed by a parameter codec; the adapter can be an intermediate component that enables different tool protocols to interface with the system compatibility layer, and correspondingly, the target adapter can be an adapter that matches the target tool protocol type.

[0032] The method of generating standardized tool invocation instructions based on proxy execution plans can be achieved by using a capability matcher, parameter codec, and adapter selector in the tool compatibility layer to collaboratively process the proxy execution plan and obtain standardized tool invocation instructions.

[0033] A proxy execution request can be a complete request package containing standardized tool invocation instructions. One way to generate a proxy execution request based on standardized tool invocation instructions is to encapsulate the standardized tool invocation instructions through a tool access adaptation layer to obtain the proxy execution request.

[0034] S103, based on the standardized tool invocation instructions, determine the current proxy execution environment, and send the proxy execution request to the current proxy execution environment, and execute the proxy execution request through the current proxy execution environment; the proxy execution environment (i.e., the execution environment layer) can be a set of hardware and software environments used to carry out tool execution, including local execution environments, container sandbox execution environments, and remote execution environments. Accordingly, the current proxy execution environment can be the proxy execution environment most suitable for the current task execution selected according to the standardized tool invocation instructions.

[0035] The method of determining the current agent execution environment based on standardized tool invocation instructions can be achieved by having the environment selector of the multi-environment execution agent layer make strategic decisions based on the standardized tool invocation instructions to obtain the current agent execution environment.

[0036] The method of sending proxy execution requests to the current proxy execution environment can be achieved by having the execution controller of the multi-environment execution proxy layer send the proxy execution requests through the communication interface corresponding to the current proxy execution environment.

[0037] By executing proxy execution requests through the current proxy execution environment, the standardized call data in the proxy execution request can be loaded by the built-in execution engine of the current proxy execution environment, and the target tool can be invoked to complete the task execution.

[0038] S104, Receive the proxy execution result returned by the current proxy execution environment.

[0039] The results of proxy execution can be output data or execution status information after the task is completed. These include two types: result data after successful execution and exception information when execution fails. Exception information can include key information such as error code, error description, and fault location.

[0040] The method to receive the proxy execution results returned by the current proxy execution environment can be to have the audit logger of the multi-environment execution proxy layer monitor the output port of the current proxy execution environment in real time to obtain the proxy execution results.

[0041] Optionally, the audit logger of the multi-environment execution agent layer can also generate a unique audit identifier (trace_id) for the agent execution plan when generating agent execution plans with unified action semantics, and record core information such as agent execution plan, current agent execution environment, target tool, input parameter fields, agent execution results, agent execution time, and environment migration links to form an audit log.

[0042] In this embodiment, a user task instruction is obtained, and a proxy execution plan with unified action semantics is generated based on the user task instruction. The proxy execution plan includes an opcode field and an input parameter field. A standardized tool invocation instruction is generated based on the proxy execution plan, and a proxy execution request is generated based on the standardized tool invocation instruction. The standardized tool invocation instruction includes standardized invocation data and a target adapter. The current proxy execution environment is determined based on the standardized tool invocation instruction, and the proxy execution request is sent to the current proxy execution environment and executed through the current proxy execution environment. The proxy execution result returned by the current proxy execution environment is received. This proxy execution method based on unified action semantics breaks the limitations of fixed configurations, achieving flexible compatibility and rapid expansion of tools, as well as dynamic selection of the execution environment, thereby improving the flexibility, stability, and reliability of intelligent proxy task execution.

[0043] Figure 3 of Embodiment 2 is a flowchart illustrating the proxy execution method based on unified action semantics provided in Embodiment 2 of this application. This solution makes a further improvement on the above embodiments, specifically: the step of generating a proxy execution plan based on the user task instruction includes: converting the user task instruction into a structured task target, and performing hierarchical decomposition on the structured task target to obtain sub-task targets and their corresponding constraints and resource requirements; determining the execution dependencies between the sub-task targets based on their constraints, and determining the sub-task target execution sequence based on the execution dependencies and resource requirements; and converting each sub-task target in the sub-task target execution sequence into a proxy execution plan based on a preset unified action semantics specification.

[0044] As shown in Figure 3, the specific steps include: S301, obtaining user task instructions; S302, converting the user task instructions into structured task objectives, and performing hierarchical decomposition on the structured task objectives to obtain sub-task objectives and the corresponding constraints and resource requirements information; the structured task objectives can be structured task data with clear target boundaries and execution dimensions, converted from user task instructions. The method for converting user task instructions into structured task objectives can be achieved by using the LLM model of the core decision layer based on a preset structured template.

[0045] A subtask objective can be the smallest independently executable task unit formed by breaking down a structured task objective according to execution logic. The constraints corresponding to the subtask objective can be restrictive requirements that ensure the accurate execution of the subtask, and may include time constraints, format constraints, permission constraints, and compliance constraints, etc. The resource requirement information corresponding to the subtask objective can be a description of the hardware, software, and service resources required during the execution of the subtask.

[0046] The structured task objectives can be decomposed hierarchically to obtain sub-task objectives and their corresponding constraints and resource requirements. This can be achieved by matching a preset decomposition template with the task type of the structured task objective, and then using a recursive decomposition method based on the preset decomposition template to break down the structured task objective layer by layer to the smallest execution unit, i.e., the sub-task objective, and obtaining the corresponding constraints and resource requirements of the sub-task objective.

[0047] S303, determine the execution dependency relationship between the sub-task objectives based on the constraints of the sub-task objectives, and determine the execution sequence of the sub-task objectives based on the execution dependency relationship and the resource requirement information; the execution dependency relationship between the sub-task objectives can be the relationship between each sub-task in terms of time sequence, data flow, and result acceptance, and can include three types: pre-dependency, parallel dependency, and mutual exclusion dependency.

[0048] Determining the execution dependencies between sub-task objectives based on their constraints can be achieved by using both the constraints of the sub-task objectives and a pre-built dependency rule base. This dependency rule base can be a set of rules stored in the form of structured rule entries, specifically adapted to the task execution logic of the proxy execution system.

[0049] The execution sequence of subtask objectives can be a list of subtask objectives executed in order of priority, following execution dependencies and resource requirements.

[0050] The method of determining the execution sequence of subtask objectives based on execution dependencies and resource requirements can be as follows: determine the basic execution order by topological sorting based on the pre-dependencies between subtask objectives; then sort the subtask objectives with parallel dependencies in the basic execution order according to resource occupancy priority based on resource requirements; finally, sort the subtask objectives with mutual exclusion dependencies according to the principle of optimal resource utilization to obtain the execution sequence of subtask objectives.

[0051] S304, based on a preset unified action semantic specification, convert each subtask target in the subtask target execution sequence into a proxy execution plan with unified action semantics; wherein, the proxy execution plan includes an opcode field and an input parameter field; the preset unified action semantic specification can be a standardized protocol for the specific field structure, field definition, data format and encoding rules of the unified action semantics.

[0052] Based on the preset unified action semantics specification, the method of converting each subtask target in the subtask target execution sequence into a proxy execution plan with unified action semantics can be achieved by converting each subtask target according to the field mapping rules, field filling standards and semantic verification logic defined in the preset unified action semantics specification, thereby obtaining a proxy execution plan with unified action semantics.

[0053] Optionally, after converting each subtask objective in the subtask objective execution sequence into a proxy execution plan based on a preset unified action semantic specification, the method further includes: obtaining the pre-execution result and determining a target exception handling strategy based on the pre-execution result; wherein, the exception handling strategy includes a re-execution strategy, a subtask modification strategy, and a subtask skipping strategy; executing the target exception handling strategy on the proxy execution plan to obtain an optimized proxy execution plan with unified action semantics; correspondingly, generating standardized tool invocation instructions based on the proxy execution plan includes: generating standardized tool invocation instructions based on the optimized proxy execution plan.

[0054] The pre-execution result can be an abnormal proxy execution result returned by the proxy execution environment during the execution of the current subtask target. The pre-execution result can be obtained by having the audit logger of the multi-environment execution proxy layer monitor the output port of the current proxy execution environment in real time.

[0055] An exception handling strategy can be a pre-defined automated handling scheme to deal with execution exceptions, which may include re-execution strategies, subtask modification strategies, and subtask skipping strategies. Specifically, a re-execution strategy can be a strategy that, when the exception is determined to be a temporary failure (such as network jitter), re-initiates execution by adjusting execution parameters (such as increasing the retry interval); a subtask modification strategy can be a strategy that, when the exception is determined to originate from an improper task objective or parameter setting (such as an incorrect input path), dynamically corrects the input parameters, constraints, or tools invoked for the subtask objective; a subtask skipping strategy can be a strategy that, when the current subtask objective fails but does not affect the achievement of the final main task objective, or when there is an alternative solution, allows skipping the subtask objective, recording the exception status, and continuing the subsequent process. Correspondingly, the target exception handling strategy can be the optimal exception handling strategy matched from a pre-defined strategy library based on the results of previous executions.

[0056] The method of determining the target exception handling strategy based on the results of the preceding execution can be to match the optimal exception handling strategy from a preset strategy library based on the exception type of the preceding execution results. The preset strategy library can be a structured rule library with exception type and exception handling strategy as the association; for example, when the exception type is network timeout, an automatic re-execution strategy can be matched.

[0057] The optimized proxy execution plan with unified action semantics can be the final proxy execution plan obtained by adjusting the original proxy execution plan according to the target exception handling strategy.

[0058] The method to obtain an optimized proxy execution plan with unified action semantics by executing the target exception handling strategy on the proxy execution plan can be achieved by adjusting the proxy execution plan according to the specific operation instructions corresponding to the target exception handling strategy.

[0059] The advantage of this approach is that it introduces dynamic exception handling and execution plan optimization mechanisms, forming a complete autonomous closed-loop execution process, which improves the success rate and overall robustness of complex tasks in real and changing environments.

[0060] S305, Generate standardized tool invocation instructions based on the proxy execution plan, and generate a proxy execution request based on the standardized tool invocation instructions; wherein, the standardized tool invocation instructions include standardized invocation data and a target adapter; S306, Determine the current proxy execution environment based on the standardized tool invocation instructions, send the proxy execution request to the current proxy execution environment, and execute the proxy execution request through the current proxy execution environment; S307, Receive the proxy execution result returned by the current proxy execution environment.

[0061] The advantage of this approach is that by transforming user task instructions into structured task objectives and decomposing them hierarchically, it effectively clarifies task boundaries and execution logic, ensuring the manageability and executability of complex tasks.

[0062] Figure 4 of Embodiment 3 is a flowchart illustrating the proxy execution method based on unified action semantics provided in Embodiment 3 of this application. This solution makes further improvements to the above embodiments, specifically: the step of generating standardized tool invocation instructions based on the proxy execution plan includes: determining a target tool in a preset tool directory based on the opcode field; wherein the preset tool directory includes available tools and corresponding capability description information and performance description information; validating the input parameter field based on the target tool, and generating standardized invocation data based on the input parameter field if the input parameter field is valid; determining a target adapter in a preset adapter directory based on the target tool; wherein the preset adapter directory includes available adapters and corresponding capability description information; and combining the standardized invocation data and the target adapter to obtain standardized tool invocation instructions.

[0063] As shown in Figure 4, the specific steps include: S401, obtaining user task instructions and generating a proxy execution plan with unified action semantics based on the user task instructions; wherein, the proxy execution plan includes an opcode field and an input parameter field; S402, determining the target tool in a preset tool directory based on the opcode field; wherein, the preset tool directory includes available tools and corresponding capability description information and performance description information; the preset tool directory can be a structured tool metadata repository, which may include available tools and corresponding capability description information and performance description information.

[0064] Available tools can be various registered and invoked software functions, algorithm models, or API services. The capability description information of available tools can be metadata used to define the tool's functional boundaries and invocation specifications, which may include supported opcodes, input / output parameter requirements, and supported proxy execution environments, etc.; the performance description information of available tools can be metric data used to evaluate the quality of tool services, which may include latency, throughput, stability, and historical success rate, etc.

[0065] The target tool can be one or more tools selected from a preset tool catalog based on the opcode field in the current agent execution plan, whose capabilities best match the requirements. The method of determining the target tool from the preset tool catalog based on the opcode field can involve using precise or fuzzy matching between the opcode field and the capability descriptions of each available tool to filter candidate tools, and then weighting the performance descriptions of the candidate tools in conjunction with the constraints of the sub-target tasks to select the optimal candidate tool as the target tool.

[0066] S403, the input parameter fields are validated based on the target tool, and standardized call data is generated based on the input parameter fields if the validation of the input parameter fields is qualified; the method of validating the input parameter fields based on the target tool can be to perform compliance checks on the input parameter fields according to the input parameter requirements (io.input_schema) of the target tool.

[0067] The method of generating standardized call data based on input parameter fields can be achieved by encapsulating the input parameter fields into data structures that the target tool can directly parse (such as JSON objects, binary data, or form data) according to the input parameter requirements of the target tool.

[0068] Optionally, determining the target tool in a preset tool directory based on the opcode field includes: determining candidate tools in the preset tool directory based on the opcode field; sorting the candidate tools based on their performance description information, and determining the first candidate tool in the sorting result as the target tool; correspondingly, after validating the input parameter field based on the target tool, the method further includes: if the input parameter field fails the validation, selecting the next candidate tool as the new target tool according to the sorting result, and validating the input parameter field based on the target tool; repeating the above steps until the input parameter field passes the validation.

[0069] Candidate tools can be a set of all available tools whose capabilities match the initial screening from a preset tool catalog based on the opcode field. The method of determining candidate tools from the preset tool catalog based on the opcode field can involve precise or fuzzy matching between the opcode field and the capability descriptions of each available tool.

[0070] The method of ranking candidate tools based on their performance description information can be achieved by assigning weights to various performance indicators (such as latency, throughput, stability, and historical success rate) according to the constraints of the sub-task objectives, calculating the comprehensive score of each candidate tool based on its performance description information and corresponding weights, and then sorting the candidate tools in descending order based on the comprehensive scores to obtain the ranking result.

[0071] Optionally, if the input parameter field fails validation, or if the current proxy execution environment returns an abnormal proxy execution result, the method further includes: determining and executing a target degradation rollback strategy based on the validation result or the abnormal proxy execution result, obtaining a degradation proxy execution plan, and executing the degradation proxy execution plan; wherein, the target degradation rollback strategy includes a service degradation strategy, a function rollback strategy, and a path switching strategy.

[0072] The advantage of this approach is that if the input parameter field fails validation, the next candidate tool is selected as the new target tool according to the sorting results. The input parameter field is then validated based on the target tool. This process is repeated until the input parameter field passes validation. The system can automatically and seamlessly switch to the alternative solution, effectively avoiding process interruptions caused by single-point dependencies. This ensures that fault isolation and recovery can be completed autonomously without manual intervention, thereby improving the success rate and overall robustness of complex tasks.

[0073] S404, determine the target adapter in the preset adapter directory based on the target tool; wherein, the preset adapter directory includes available adapters and capability description information corresponding to the available adapters; the preset adapter directory can be a structured adapter metadata repository, which may include available adapters and capability description information corresponding to the available adapters.

[0074] The preset tool directory and preset adapter directory are maintained and managed for lifecycle by the tool access adaptation layer.

[0075] Available adapters can be registered and invoked adapters. The capability description information corresponding to available adapters can be metadata that describes the adapter's functionality, and may include supported tools, supported agent execution environments, supported communication protocols, and data serialization formats, etc.

[0076] Based on the method of determining the target adapter in the preset adapter directory based on the target tool, the target adapter can be selected by matching the target tool's supported proxy execution environment and required communication protocol in the preset adapter directory, and selecting the adapter that can adapt to the standardized call data and the target tool's running environment as the target adapter.

[0077] S405, combine the standardized call data and the target adapter to obtain a standardized tool call instruction; the method of combining the standardized call data and the target adapter to obtain the standardized tool call instruction can be to encapsulate the standardized call data and the unique identifier of the target adapter into a data structure according to a preset data structure format to obtain the standardized tool call instruction.

[0078] S406, Generate a proxy execution request based on the standardized tool invocation instruction; S407, Determine the current proxy execution environment based on the standardized tool invocation instruction, send the proxy execution request to the current proxy execution environment, and execute the proxy execution request through the current proxy execution environment; S408, Receive the proxy execution result returned by the current proxy execution environment.

[0079] The advantage of this approach is that it can intelligently allocate appropriate tools and adapters to the abstract agent execution plan, ensuring the accuracy of task capability invocation and the compatibility of the execution environment.

[0080] Figure 5 of Embodiment 4 is a flowchart illustrating the proxy execution method based on unified action semantics provided in Embodiment 4 of this application. This solution makes further improvements to the above embodiments, specifically: the proxy execution plan further includes an expected result field and a retry policy field; correspondingly, after receiving the proxy execution result returned by the current proxy execution environment, the method further includes: comparing the proxy execution result with the expected result field to obtain a comparison result; if the comparison result is consistent, determining that the task execution is complete; if the comparison result is inconsistent, re-executing the proxy execution request through the current proxy execution environment based on the retry policy field.

[0081] As shown in Figure 5, the specific steps include: S501, obtaining user task instructions and generating a proxy execution plan with unified action semantics based on the user task instructions; wherein, the proxy execution plan includes an opcode field, an input parameter field, an expected result field, and a retry strategy field; the expected result field can be structured data used to define the success criteria of the task, and may include the expected output data type, key data features, allowable error range, or key information that must be included, etc.

[0082] The retry policy field can be metadata used to define retry rules after a task fails, which may include preset number of retry thresholds, retry trigger conditions, and retry interval policies.

[0083] S502, Generate standardized tool invocation instructions based on the proxy execution plan, and generate proxy execution requests based on the standardized tool invocation instructions; wherein, the standardized tool invocation instructions include standardized invocation data and a target adapter; S503, Determine the current proxy execution environment based on the standardized tool invocation instructions, send the proxy execution request to the current proxy execution environment, and execute the proxy execution request through the current proxy execution environment; S504, Receive the proxy execution result returned by the current proxy execution environment; S505, Compare the proxy execution result with the expected result field to obtain a comparison result; The method of comparing the proxy execution result with the expected result field to obtain a comparison result can be to convert the proxy execution result and the expected result field into vector format, calculate the cosine similarity between the two vectors, and determine that the comparison result is consistent if the cosine similarity exceeds a preset similarity threshold, otherwise determine that the comparison result is inconsistent.

[0084] S506, if the comparison results are consistent, determine that the task execution is complete; determining that the task execution is complete means that the current sub-task objective or the overall structured task objective has been achieved as expected, record the execution success status and output the current proxy execution result as the final result, and the process terminates.

[0085] S507, if the comparison result is inconsistent, the proxy execution request is re-executed through the current proxy execution environment based on the retry policy field.

[0086] Based on the retry policy field, the proxy execution request can be re-executed in the current proxy execution environment. If the number of repeated executions does not exceed the preset threshold and the failure reason meets the retry triggering conditions, the proxy execution request can be re-executed in the current proxy execution environment after waiting for the corresponding time according to the retry interval policy.

[0087] Optionally, the retry strategy field also includes an exception rollback strategy. The exception rollback strategy can be an operational specification used to restore the state to the current task start point before retrying execution, and may include undoing intermediate artifacts, releasing resources, and restoring the context. Correspondingly, the method of re-executing the proxy execution request through the current proxy execution environment based on the retry strategy field can be implemented by waiting for a corresponding time according to the retry interval strategy, and then re-executing the proxy execution request through the current proxy execution environment based on the exception rollback strategy, provided that the number of repeated executions has not exceeded a preset threshold and the failure reason meets the retry triggering conditions.

[0088] Optionally, the proxy execution plan further includes a field allowing migration to the target environment; correspondingly, after the proxy execution request is re-executed through the current proxy execution environment based on the retry policy field, the method further includes: when the number of repeated executions reaches a preset threshold, obtaining resource status information, and determining the target proxy execution environment based on the resource status information and the field allowing migration to the target environment; migrating the unfinished execution actions and intermediate states of the current proxy execution environment to the target proxy execution environment through a hot migration mechanism, and continuing to execute the unfinished execution actions through the target proxy execution environment based on the intermediate states.

[0089] The number of retry attempts can be the cumulative number of times the proxy execution request has failed to execute in the current proxy execution environment. The preset threshold can be a pre-set maximum number of retries related to the criticality of the task and resource costs. Reaching the preset threshold indicates that the current proxy execution environment may have instability issues or resource bottlenecks that are difficult to recover from, making it impossible to successfully execute the proxy execution request.

[0090] Resource status information can be metrics reflecting the real-time load and health of each agent execution environment, including CPU / memory utilization, network latency, and queue depth. Resource status information can be obtained by actively pulling from the resource monitoring service or by receiving periodic reports from each agent execution environment.

[0091] The target proxy execution environment can be determined based on resource status information and the allowed migration target environment field. This can be done by filtering candidate proxy execution environments based on the allowed migration target environment field, comprehensively evaluating the overall execution cost of each candidate proxy execution environment based on the resource status information of the candidate proxy execution environments, and selecting the candidate proxy execution environment with the lowest overall execution cost as the target proxy execution environment.

[0092] Hot migration is a technology that, while ensuring business continuity, migrates running task instances and their complete states from one execution environment to another in real time. The incomplete execution actions in the current agent execution environment can be a queue of subtask targets that have not yet started or are being executed but not yet completed. The intermediate state of the current agent execution environment can be the output results of completed subtask targets, the data context in memory, and the session state, etc.

[0093] The hot migration mechanism can be used to migrate the unfinished execution actions and intermediate states of the current proxy execution environment to the target proxy execution environment. This can be achieved by serializing the intermediate states into a data format that is independent of the proxy execution environment, pausing or recording the breakpoints of the unfinished execution actions, and then transmitting the intermediate state data, the queue of unfinished execution actions, and the recorded breakpoints to the target proxy execution environment and completing the reconstruction.

[0094] By continuing to execute unfinished actions based on intermediate states through the target proxy execution environment, the target proxy execution environment can load the intermediate states into its own context after successfully receiving and deserializing them, and then continue to execute the queue of unfinished actions from the recorded breakpoint.

[0095] The advantage of this approach is that by introducing environmental migration capabilities, the impact of environmental failures on task execution is minimized, effectively preventing complete task interruption due to a single point of environmental failure.

[0096] The advantage of this approach is that by introducing expected result fields and retry strategy fields, an intelligent agent execution system with closed-loop self-verification capabilities and adaptive recovery mechanisms is constructed, effectively addressing temporary failures and environmental fluctuations.

[0097] Figure 6 is a schematic diagram of the structure of the proxy execution system based on unified action semantics provided in Embodiment 5 of this application. As shown in Figure 6, the system includes: an execution plan generation module 610, used to obtain user task instructions and generate a proxy execution plan with unified action semantics based on the user task instructions; wherein, the proxy execution plan includes an opcode field and an input parameter field; an execution request generation module 620, used to generate standardized tool call instructions based on the proxy execution plan and generate proxy execution requests based on the standardized tool call instructions; wherein, the standardized tool call instructions include standardized call data and a target adapter; an execution request execution module 630, used to determine the current proxy execution environment based on the standardized tool call instructions, send the proxy execution request to the current proxy execution environment, and execute the proxy execution request through the current proxy execution environment; and an execution result receiving module 640, used to receive the proxy execution result returned by the current proxy execution environment.

[0098] Optionally, the execution plan generation module 610 is specifically used for: converting the user task instruction into a structured task target, and performing hierarchical decomposition on the structured task target to obtain sub-task targets and the corresponding constraints and resource requirements information of the sub-task targets; determining the execution dependency relationship between the sub-task targets based on the constraints of the sub-task targets, and determining the sub-task target execution sequence based on the execution dependency relationship and the resource requirements information; and converting each sub-task target in the sub-task target execution sequence into a proxy execution plan with unified action semantics based on a preset unified action semantic specification.

[0099] Optionally, the execution plan generation module 610 is further configured to: obtain the pre-execution result and determine the target exception handling strategy based on the pre-execution result; wherein the exception handling strategy includes a re-execution strategy, a subtask modification strategy, and a subtask skipping strategy; execute the target exception handling strategy on the proxy execution plan to obtain an optimized proxy execution plan with unified action semantics; correspondingly, the execution request generation module is specifically configured to: generate standardized tool call instructions based on the optimized proxy execution plan.

[0100] Optionally, the execution request generation module 620 is specifically configured to: determine a target tool in a preset tool directory based on the opcode field; wherein the preset tool directory includes available tools and corresponding capability description information and performance description information; validate the input parameter field based on the target tool, and generate standardized invocation data based on the input parameter field if the input parameter field validation is successful; determine a target adapter in a preset adapter directory based on the target tool; wherein the preset adapter directory includes available adapters and corresponding capability description information; and combine the standardized invocation data and the target adapter to obtain a standardized tool invocation instruction.

[0101] Optionally, the execution request generation module 620 is specifically configured to: determine candidate tools in a preset tool directory based on the opcode field; sort the candidate tools based on the performance description information of the candidate tools, and determine the first candidate tool in the sorting result as the target tool; correspondingly, the execution request generation module 620 is also configured to: if the input parameter field verification fails, select the next candidate tool as the new target tool according to the sorting result, and verify the input parameter field based on the target tool; repeat the above steps until the input parameter field verification passes.

[0102] Optionally, the proxy execution plan further includes an expected result field and a retry policy field; correspondingly, the system is also used to: compare the proxy execution result with the expected result field to obtain a comparison result; if the comparison result is consistent, determine that the task execution is completed; if the comparison result is inconsistent, re-execute the proxy execution request based on the retry policy field through the current proxy execution environment.

[0103] Optionally, the proxy execution plan further includes a field allowing migration to the target environment; correspondingly, the system is also used to: when the number of repeated executions reaches a preset threshold, obtain resource status information, and determine the target proxy execution environment based on the resource status information and the field allowing migration to the target environment; migrate the unfinished execution actions and intermediate states of the current proxy execution environment to the target proxy execution environment through a hot migration mechanism, and continue to execute the unfinished execution actions based on the intermediate states through the target proxy execution environment.

[0104] In this embodiment, an execution plan generation module is used to acquire user task instructions and generate a proxy execution plan with unified action semantics based on the user task instructions; wherein, the proxy execution plan includes an opcode field and an input parameter field; an execution request generation module is used to generate standardized tool invocation instructions based on the proxy execution plan and generate a proxy execution request based on the standardized tool invocation instructions; wherein, the standardized tool invocation instructions include standardized invocation data and a target adapter; an execution request execution module is used to determine the current proxy execution environment based on the standardized tool invocation instructions, send the proxy execution request to the current proxy execution environment, and execute the proxy execution request through the current proxy execution environment; an execution result receiving module is used to receive the proxy execution result returned by the current proxy execution environment. The above-described proxy execution system based on unified action semantics breaks the limitations of fixed configurations, achieves flexible compatibility and rapid expansion of tools, and dynamic selection of execution environments, thereby improving the flexibility, stability, and reliability of intelligent proxy task execution.

[0105] The proxy execution system based on unified action semantics provided in this application can realize the various processes implemented in the above embodiments. To avoid repetition, it will not be described again here.

[0106] Figure 7 is a schematic diagram of the structure of the electronic device provided in Embodiment 6 of this application. As shown in Figure 7, this application embodiment also provides an electronic device 700, including a processor 701, a memory 702, and a program or instructions stored in the memory 702 and executable on the processor 701. When the program or instructions are executed by the processor 701, they implement the various processes of the above-described proxy execution method embodiment based on unified action semantics and achieve the same technical effect. To avoid repetition, further details are omitted here.

[0107] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0108] Example 7 This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described proxy execution method embodiment based on unified action semantics and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0109] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0110] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element. Furthermore, it should be noted that the scope of the methods and systems in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0111] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0112] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0113] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.

Claims

1. A proxy execution method based on unified action semantics, characterized in that, The method includes: acquiring user task instructions and generating a proxy execution plan with unified action semantics based on the user task instructions; wherein the proxy execution plan includes an opcode field and an input parameter field; generating standardized tool invocation instructions based on the proxy execution plan and generating a proxy execution request based on the standardized tool invocation instructions; wherein the standardized tool invocation instructions include standardized invocation data and a target adapter; determining the current proxy execution environment based on the standardized tool invocation instructions, sending the proxy execution request to the current proxy execution environment, and executing the proxy execution request through the current proxy execution environment; and receiving the proxy execution result returned by the current proxy execution environment.

2. The proxy execution method based on unified action semantics according to claim 1, characterized in that, The step of generating a proxy execution plan with unified action semantics based on the user task instruction includes: converting the user task instruction into a structured task target, and performing hierarchical decomposition on the structured task target to obtain sub-task targets and the corresponding constraints and resource requirements information of the sub-task targets; determining the execution dependencies between the sub-task targets based on the constraints of the sub-task targets, and determining the execution sequence of the sub-task targets based on the execution dependencies and the resource requirements information; and converting each sub-task target in the execution sequence of the sub-task targets into a proxy execution plan with unified action semantics based on a preset unified action semantics specification.

3. The proxy execution method based on unified action semantics according to claim 2, characterized in that, After converting each subtask objective in the subtask objective execution sequence into a proxy execution plan based on a preset unified action semantic specification, the method further includes: obtaining the pre-execution result and determining a target exception handling strategy based on the pre-execution result; wherein, the exception handling strategy includes a re-execution strategy, a subtask modification strategy, and a subtask skipping strategy; executing the target exception handling strategy on the proxy execution plan to obtain an optimized proxy execution plan with unified action semantics; correspondingly, generating standardized tool invocation instructions based on the proxy execution plan includes: generating standardized tool invocation instructions based on the optimized proxy execution plan.

4. The proxy execution method based on unified action semantics according to claim 1, characterized in that, The step of generating standardized tool invocation instructions based on the agent execution plan includes: determining a target tool in a preset tool directory based on the opcode field; wherein the preset tool directory includes available tools and corresponding capability description information and performance description information; validating the input parameter field based on the target tool, and generating standardized invocation data based on the input parameter field if the input parameter field is valid; determining a target adapter in a preset adapter directory based on the target tool; wherein the preset adapter directory includes available adapters and corresponding capability description information; and combining the standardized invocation data and the target adapter to obtain standardized tool invocation instructions.

5. The proxy execution method based on unified action semantics according to claim 4, characterized in that, The step of determining the target tool in a preset tool directory based on the opcode field includes: determining candidate tools in the preset tool directory based on the opcode field; sorting the candidate tools based on their performance description information, and determining the first candidate tool in the sorting result as the target tool; correspondingly, after validating the input parameter field based on the target tool, the method further includes: if the input parameter field fails the validation, selecting the next candidate tool as the new target tool according to the sorting result, and validating the input parameter field based on the target tool; repeating the above steps until the input parameter field passes the validation.

6. The proxy execution method based on unified action semantics according to claim 1, characterized in that, The proxy execution plan also includes an expected result field and a retry policy field; correspondingly, after receiving the proxy execution result returned by the current proxy execution environment, the method further includes: comparing the proxy execution result with the expected result field to obtain a comparison result; if the comparison result is consistent, determining that the task execution is completed; if the comparison result is inconsistent, re-executing the proxy execution request through the current proxy execution environment based on the retry policy field.

7. The proxy execution method based on unified action semantics according to claim 6, characterized in that, The proxy execution plan also includes a field allowing migration to the target environment; correspondingly, after the proxy execution request is re-executed through the current proxy execution environment based on the retry policy field, the method further includes: when the number of repeated executions reaches a preset threshold, obtaining resource status information, and determining the target proxy execution environment based on the resource status information and the field allowing migration to the target environment; migrating the unfinished execution actions and intermediate states of the current proxy execution environment to the target proxy execution environment through a hot migration mechanism, and continuing to execute the unfinished execution actions through the target proxy execution environment based on the intermediate states.

8. A proxy execution system based on unified action semantics, characterized in that, The system includes: an execution plan generation module, used to acquire user task instructions and generate a proxy execution plan with unified action semantics based on the user task instructions; wherein the proxy execution plan includes an opcode field and an input parameter field; an execution request generation module, used to generate standardized tool invocation instructions based on the proxy execution plan and generate a proxy execution request based on the standardized tool invocation instructions; wherein the standardized tool invocation instructions include standardized invocation data and a target adapter; an execution request execution module, used to determine the current proxy execution environment based on the standardized tool invocation instructions, send the proxy execution request to the current proxy execution environment, and execute the proxy execution request through the current proxy execution environment; and an execution result receiving module, used to receive the proxy execution result returned by the current proxy execution environment.

9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein when the program or instructions are executed by the processor, they implement the proxy execution method based on unified action semantics as described in any one of claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions, which, when executed by a processor, implement the proxy execution method based on unified action semantics as described in any one of claims 1-7.

Images