A task execution method, electronic device, and computer program product

Abstract

The application discloses a task execution method, an electronic device and a computer program product, and belongs to the technical field of communication. The method comprises the following steps: in response to receiving a target task, determining an initial task evolution framework corresponding to the target task; the initial task evolution framework is generated based on a preset visual structure, wherein the initial task evolution framework comprises a plurality of nodes, and the plurality of nodes correspond to each link of task evolution in the process of the target task from task input to task execution end; based on task execution data of each link of task evolution, updating metadata of the corresponding node in the initial task evolution framework to obtain a complete task evolution framework of task execution of each link after the target task is executed, wherein the metadata of each node in the initial task evolution framework is used to carry task execution data of the corresponding link of task evolution.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a task execution method, electronic device, and computer program product. Background Technology

[0002] With the continuous development of artificial intelligence technology, multi-agent application scenarios based on large models are becoming increasingly widespread and have become a key path for intelligent transformation in various industries.

[0003] In fields such as intelligent operation and maintenance of communication networks and complex task planning, current intelligent agent systems based on large models often rely on "black box" decision outputs, lacking visualization and traceability of key information during task planning and execution. For example, when anomalies occur during task execution or verification and review are required, operation and maintenance personnel find it difficult to trace the details of the execution process and verify the rationality and compliance of the intelligent agent's decisions. This lack of interpretability not only reduces operational trust but also affects the compliance and reliability of task planning and execution. Summary of the Invention

[0004] This application provides a task execution method, electronic device, and computer program product that can solve the problem that related technologies cannot meet the requirements of full-process traceability and interpretability of task planning and task execution.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows: Firstly, a task execution method is provided, including: In response to receiving a target task, an initial task evolution framework corresponding to the target task is determined; the initial task evolution framework is generated based on a preset visualization structure, wherein the initial task evolution framework includes multiple nodes, and the multiple nodes correspond to each stage of the task evolution process from task input to task execution completion; Based on the task execution data of each stage of the task evolution, the metadata of the corresponding nodes in the initial task evolution framework is updated to obtain a complete task evolution framework for the task execution of each stage after the target task is completed. The metadata of each node in the initial task evolution framework is used to carry the task execution data of the corresponding stage of the task evolution.

[0006] In a second aspect, an electronic device is provided, the electronic device comprising a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement the steps of the task execution method described above.

[0007] Thirdly, a readable storage medium is provided, wherein at least one computer program is stored in the readable storage medium, the computer program being loaded and executed by a processor to implement the steps of the task execution method described above.

[0008] Fourthly, a computer program product is provided, the computer program product comprising at least one computer program, the computer program being loaded and executed by a processor to implement the steps of the task execution method provided in the various optional implementations described above.

[0009] The task execution method, electronic device, and computer program product provided in this application can determine an initial task evolution framework based on the target task. During the task evolution process, the execution data (data source, execution result, etc.) of each stage of the task evolution are structurally deposited into the framework node metadata. Through the initial task evolution framework, the complete information of the task execution basis, task execution process, and task execution result of each stage can be clearly presented, realizing the traceability and visualization of the entire task lifecycle. This facilitates the rapid location of task advancement logic and potential problem stages, thereby improving the trust level of operation and maintenance, and ensuring the compliance and reliability of task planning and task execution processes.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0012] Figure 1 A flowchart of a task execution method provided in an embodiment of this application is shown; Figure 2 This illustration shows a structural diagram of an initial task evolution framework provided in an embodiment of this application; Figure 3 This illustration shows a schematic diagram of the structure of an initial task evolution framework provided in another embodiment of this application; Figure 4 This application illustrates a flowchart of a task execution data update process for corresponding nodes in the initial task evolution framework, based on task evolution at each stage, according to an embodiment of this application. Figure 5 A flowchart of a human-machine collaborative target determination execution scheme provided in an embodiment of this application is shown; Figure 6 A schematic diagram of a human-computer collaborative interaction interface provided in an embodiment of this application is shown; Figure 7This application provides a flowchart illustrating a complete task evolution framework for obtaining each stage of task execution after the target task has been completed, according to an embodiment of the present application. Figure 8 A flowchart illustrating the processing of a situation where the execution result does not meet the preset requirements, according to an embodiment of this application, is shown. Figure 9 This paper presents a schematic diagram of the structure of a multi-agent distributed system provided in an application example of this application; Figure 10 This application provides an example of a solution based on... Figure 9 The flowchart shown is a method for task execution in a multi-agent distributed system. Figure 11 A flowchart of a task execution method provided in an application example of this application is shown; Figure 12 A structural block diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0013] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and systems consistent with some aspects of this application as detailed in the appended claims.

[0014] As business scale expands and scenario complexity increases, the need for end-to-end traceability, explainability, and dynamic adaptation in task planning and execution becomes increasingly urgent. However, in existing fields such as intelligent operation and maintenance of communication networks and complex task planning, intelligent agent systems based on large models often rely on "black box" decision outputs, which cannot meet the end-to-end traceability and explainability of task planning and execution. This not only reduces the trust level of operation and maintenance but also affects the compliance and reliability of the task planning and execution process.

[0015] To address the aforementioned technical problems in related technologies, embodiments of this application provide a task execution method.

[0016] The following will combine Figures 1 to 11 The task execution methods provided in the embodiments of this application are explained and described in detail. These embodiments are only used to explain this application and do not constitute a limitation thereof.

[0017] Figure 1 A flowchart illustrating a task execution method as shown in an exemplary embodiment of this application is provided. Figure 1 As shown, the task execution method mainly includes the following steps (S101-S102): S101. In response to receiving the target task, determine the initial task evolution framework corresponding to the target task; In this embodiment, the target task is, for example, a task required by actual business needs in the field of communication networks, such as network optimization, fault diagnosis, resource scheduling, and compliance auditing. In some embodiments, the target task includes at least data associated with the target task and preset requirements for execution results. For example, the data associated with the target task is the basis for determining the initial task evolution framework, and the data related to the target task includes at least one of the following: task description information (such as the task's objective, context information, timestamp, etc.), task type (such as fault diagnosis, network optimization, resource scheduling, etc.), service domain (such as bearer network, core network), service requirement parameters (such as resource quota limits, service level agreement latency requirements), service priority, task constraints (such as compliance restrictions), etc. For example, the preset requirements for execution results are the expected results that the target task needs to achieve after execution. For example, whether the fault in the fault repair task is completely repaired, or whether the degree of repair reaches a preset threshold; or whether the resource configuration result after the resource configuration task is completed meets the preset configuration requirements.

[0018] In some embodiments, the initial task evolution framework is generated based on a preset visual structure, with the aim of structuring the complete lifecycle of the target task from task input to final task execution into an interpretable structured form. The initial task evolution framework includes multiple nodes, each corresponding to a different stage in the task evolution process from task input to task execution.

[0019] In this embodiment, each stage of task evolution represents a core step in the entire task lifecycle process, covering the complete link from task input to final task execution. The division of each stage can be flexibly adapted to the business scenario; multiple consecutive steps can be integrated into one stage, or a single key step can be treated as an independent stage. For example, the core steps in the entire task lifecycle process may include task input, data acquisition, rule matching, solution verification, decision generation, task decomposition, task execution, and result feedback. These steps can be combined into different stages according to actual needs. For instance, rule matching, solution verification, and decision generation can be integrated into one stage, or data acquisition can be treated as an independent information preprocessing stage. This embodiment does not limit the division of stages.

[0020] For example, based on the above-described segmentation method, in some embodiments, the core steps can be divided into task evolution stages, each stage of which includes at least one of the following: a solution generation stage, a solution orchestration stage, and a solution execution stage. In some embodiments, the solution generation stage includes generating a target execution plan for the target task based on data associated with the target task. In some embodiments, the solution orchestration stage includes splitting and orchestrating the target execution plan to obtain multiple sub-task execution plans; for example, the solution orchestration stage further includes: the execution order, dependencies, and resource requirements among the multiple sub-task execution plans, so that the solution execution stage can execute the sub-task execution plans. In some embodiments, the solution execution stage includes executing the sub-task execution plans. In this stage, each agent executes according to the sub-task execution plan, and during execution, execution data is collected in real time and the execution status is fed back to ensure the expected progress of the target task plan.

[0021] Each stage of the task evolution process can be supplemented with task input stages, task termination stages, etc., according to the actual business scenario, forming a complete task flow chain. Each stage constructs the basic skeleton of the initial task evolution framework through node mapping. For example, Figure 2 A schematic diagram illustrating the structure of the initial task evolution framework shown in an exemplary embodiment of this application is illustrated. Figure 2 As shown, corresponding to each stage of the task evolution, the core nodes of the initial task evolution framework include: a task input node, a solution generation node, a solution orchestration node, a solution execution node, and a task termination node. These core nodes are sequentially connected via directed edges, forming the basic path for task flow. Specifically, the task input node receives the target task and associated input data (such as multimodal task descriptions and network alarm information), performs preliminary parsing of the input data, and outputs it to the solution generation node. The solution generation node executes the core logic of the solution generation stage, completing verification and decision-making processes based on the input data and outputting the target execution solution. The solution orchestration node breaks down the target execution solution into sub-task execution solutions, clarifies the dependencies between sub-tasks, and distributes them to the solution execution node. The solution execution node executes the sub-tasks, collects execution data in real time, and provides feedback on the execution status. The task termination node summarizes the overall execution results, determines whether the execution results of the task execution stage meet preset requirements, and forms a closed-loop task.

[0022] In this embodiment, the various stages of task evolution are structured as a graph. The nodes in the initial task evolution framework visually represent each stage, and the metadata of each node carries the task execution data for that stage. For example, the task execution data includes at least one of the following: data source information and execution result information. The data source information indicates the basis for task execution at each stage, and the execution result information indicates the task execution status at each stage. This clearly presents the complete information of the task execution basis, execution process, and result for each stage, enabling traceability and visual explanation of the entire task lifecycle, facilitating rapid identification of task progression logic and potential problem stages.

[0023] In some embodiments, the initial task evolution framework is generated based on a preset visualization structure. The form of the visualization structure can be flexibly selected, such as through a list, flowchart, line chart, tree diagram, directed graph, etc. As long as the visualization structure can clearly present the time sequence of task evolution, the link relationship and the annotation of task execution data, the embodiments of this application do not limit it.

[0024] As an optional implementation method in this application, the preset visualization structure can be a directed graph structure. The directed graph includes nodes, directed edges, and node attributes.

[0025] For example, the nodes of the directed graph are used to indicate the various nodes of the initial task evolution framework, including the core nodes corresponding to the task evolution stage (such as the task input node and solution generation node in Figure 2) and the subsequent expandable child nodes (such as the rule node and case node in Figure 3 below). The core nodes correspond one-to-one with each stage of the task evolution, and the child nodes of the core nodes are used to carry the execution data and related collaboration information of the subdivided dimensions.

[0026] For example, nodes in a directed graph have node attributes. These attributes record the metadata of the corresponding node in the initial task evolution framework. Node attributes can include multiple dimensions to form a multi-layered, tagged metadata storage structure. For example, the attribute fields of node attributes include at least one of the following: evidence dimension, rule dimension, graph dimension, history dimension, simulation dimension, uncertainty dimension, and task execution information dimension. Of course, there can also be attribute fields with other dimensions, which are not limited in this application. For example, the evidence dimension records basic information such as data source, collection path, and evidence fingerprint, including fault alarms, device performance, and network status, corresponding to the evidence attributes of the data source information. This supports subsequent verification and tracing, as well as the verification of the reliability of the execution basis. The rule dimension stores security and compliance constraints such as expert rules, business constraints, and compliance clauses, corresponding to the rule attributes of the data source information, providing a verification basis for the feasibility verification of subsequent tasks. The graph dimension associates entity and relationship data in the knowledge graph, such as network topology and device dependencies, corresponding to the graph attributes of the data source information. The history dimension references similar historical cases and experience data, corresponding to the history attributes of the data source information. The simulation dimension records data such as the simulated execution effect of the solution, such as simulated routing switching and load balancing effects. The uncertainty dimension includes confidence assessment results, risk quantification values, accuracy calculation results, and conflict detection results, corresponding to the execution effect quantification results of the execution result information. The task execution information dimension includes one of the following: process information of the execution stage, execution result of the execution stage, and matching result of related evidence. The process information of the execution stage indicates at least one of the intermediate process data of task execution and the result of human-machine collaborative processing; the execution result of the execution stage indicates at least one of the following: the execution of the task stage is completed, the execution of the task stage fails, or the alternative plan for the execution of the task stage; the matching result of related evidence indicates the correlation between the execution result of the execution stage and the information from the data source.

[0027] For example, nodes in a directed graph (including core nodes and child nodes, and core nodes and core nodes) are connected by directed edges. Directed edges are used to label the relationships between connected nodes in the directed graph. Directed edges can include various types to represent different relationships between connected nodes. For example, the types of directed edges include at least one of the following: basic support edge, causal inference edge, result verification edge, collaborative interaction edge, orchestration and scheduling edge, execution instruction edge, data storage edge, status feedback edge, and process loop edge. Of course, other types of directed edges can also exist based on different relationships, and this application does not impose any restrictions on this. For example, basic support edges are used to annotate the associations between support nodes that provide basic data support for core nodes. For instance, task input nodes are associated with rule nodes, knowledge graph nodes, etc., through this edge, providing compliance constraints and domain knowledge support for task execution; causal inference edges are used to reflect the logical inference or process progression relationships between nodes; result verification edges serve to provide quantitative verification basis for core nodes, such as accuracy calculation, risk assessment, confidence assessment, etc., generating verification results, which are then transmitted to the solution decision node to verify the feasibility and security of the solution; collaborative interaction edges are used to annotate human-machine collaboration or intelligent agent collaboration relationships, triggering collaborative decision-making in different human-machine collaboration modes; orchestration and scheduling edges... The decision-making node transmits the target execution plan to the orchestration node, initiating the subtask splitting process. The execution instruction edge is used by the orchestration node to issue the split subtask execution plans to the execution nodes, driving the subtasks to be executed. The data storage edge enables the execution node to synchronize execution logs, status data, and other key information to the process data storage node, facilitating subsequent traceability. The status feedback edge supports the execution node in providing feedback on execution results and anomalies to upstream decision-making or orchestration nodes, providing a basis for dynamic plan adjustments. The process loop edge is used to close the task flow from the execution stage to the completion stage; the execution node uses this edge to transmit the final execution result to the task completion node, completing the entire task process loop. Therefore, the interconnected relationships between nodes ensure clear and traceable logic between each stage of the task evolution.

[0028] For example, to more clearly illustrate the directed graph structure details of the initial task evolution framework, in an application example, Figure 3 A schematic diagram of the initial task evolution framework shown in another embodiment of this application is illustrated. Those skilled in the art will understand that the embodiments of this application use… Figure 3 The example of the directed graph structure of the initial task evolution framework is used to introduce the directed graph structure of the initial task evolution framework. This is only an illustrative example and does not constitute a limitation on this application.

[0029] like Figure 3As shown, this directed graph uses the task input node as the root node and connects each core node with its child nodes through directed edges of different types, forming a hierarchical and multi-dimensional initial task evolution framework. Figure 3 As shown: The task input node serves as the root node of the entire directed graph. It points to the solution evidence node through causal inference edges (infer), providing the solution evidence node with data related to the target task.

[0030] The solution evidence node is connected to rule nodes, knowledge graph nodes, historical experience nodes, case nodes, and data collection nodes through basic support edges (basis_of). These extended sub-nodes constitute the basic support nodes of the solution evidence node, providing data source information such as rule constraints, knowledge graph, historical experience, and similar cases. After the solution evidence node summarizes the multi-dimensional data of the basic support nodes, it is then connected to the solution verification node through causal inference edges (verify). The solution verification node is connected to the accuracy calculation node, conflict detection node, confidence assessment node, risk assessment node, and simulation node through the result verification edge (verify). These extended sub-nodes serve as verification sub-nodes of the solution verification node, providing verification dimension data and jointly supporting the execution of the solution verification process. The solution verification node then points to the solution decision node through the causal inference edge (infer), and the solution verification node transmits the verification results of each verification sub-node to the solution decision node.

[0031] The solution decision node is connected to the human-machine collaboration node through a collaborative interaction edge (collab) and points to the solution big model node through a causal inference edge (infer). The solution decision node selects the corresponding human-machine collaboration mode based on the verification results of the solution verification node, triggering the human-machine collaboration node to determine the final target execution plan based on the selected human-machine collaboration mode. The solution big model node generates the final target execution plan with the help of the big model based on the multi-dimensional data summarized by the solution evidence node and the selected human-machine collaboration mode. The decision node points to the orchestration node via an orchestration edge (orchestra), and outputs the target execution plan to the orchestration node; The scheme orchestration node is associated with the scheme execution node through the decision edge, and outputs the execution schemes of each subtask obtained by scheme decomposition and orchestration based on the target execution scheme to the scheme execution node; The execution node connects to the process data storage node via a data storage edge (save), synchronizing key information such as execution logs and status data to the process data storage node for easy traceability. Furthermore, the execution node supports feedback of execution results and anomaly information to upstream nodes via a status feedback edge (feedback), providing a basis for dynamic adjustment of the plan. Finally, if the execution result of a subtask meets the preset requirements of the target task, the final execution result is transmitted to the task end node via a process loop edge (end), triggering the task end node to generate the final complete task evolution framework, thus completing the entire task process loop.

[0032] In this application example, the directed graph structure of the initial task evolution framework not only reflects the flow logic of the core nodes, but also realizes the decomposition of subdivided functions through the expansion of child nodes. The type identifiers of each directed edge clearly mark the relationship between nodes. Together with the metadata in the node attributes, it fully presents the evolution process of the entire task lifecycle: "task input - data support - verification decision - solution generation - task orchestration - task execution - task completion", providing structured support for subsequent metadata updates and task visualization.

[0033] In some embodiments, upon receiving a target task, a corresponding initial task evolution framework is determined based on the target task. For example, the initial task evolution framework can be generated by combining historical experience reuse with a knowledge rule graph to ensure the adaptability and compliance of the initial task evolution framework.

[0034] In some embodiments, determining the initial task evolution framework corresponding to the target task includes: parsing the target task to obtain data related to the target task; and obtaining the initial task evolution framework based on the data related to the target task.

[0035] For example, after receiving the target task, the target task is parsed to obtain data related to the target task. The data related to the target task includes at least one of the following: task description information, task type, business domain, business requirement parameters, business priority, and task constraints.

[0036] For example, obtaining an evolution graph template based on data related to the target task includes: (1) If an evolution graph template matching the target task is found in the knowledge base based on the data related to the target task, the evolution graph template is used as the initial task evolution framework. The evolution graph template is formed by solidifying the complete task evolution framework of a previously completed task similar to the target task. The evolution graph template includes nodes, directed edges and node attribute configurations corresponding to each stage of the task evolution of the target task.

[0037] (2) If no matching task graph template is found in the knowledge base based on the data related to the target task, the large model is called to generate the initial task evolution framework corresponding to the target task. The large model is based on the data related to the target task, and on the domain knowledge graph, historical case experience data and business rules (such as expert rules, business constraints, and compliance clauses) to construct an initial task evolution framework with task input as the root node, which includes nodes corresponding to core links such as solution generation, solution orchestration, and solution execution, and initializes the attribute fields of each node.

[0038] In one application example, taking cross-domain link fault diagnosis of the bearer network as an example, if there is an evolution diagram template for similar fault diagnosis in the knowledge base, the template can be directly reused as the initial task evolution framework for the target task. For example, the evolution diagram template includes node configurations for: fault alarm input node, evidence collection node, solution generation node, diagnosis execution node, and result feedback node, corresponding to each stage of the fault alarm task planning and execution process. If the target task is a new fault scenario and there is no similar evolution diagram template for fault diagnosis in the knowledge base, the large model is called to generate an adapted initial task evolution framework based on the general process of fault diagnosis and the business characteristics of the bearer network.

[0039] In this embodiment, the directed graph structure of the initial task evolution framework fully presents the evolution process of the complete link of the entire task lifecycle, providing structured support for subsequent metadata updates and task visualization.

[0040] S102. Based on the task execution data of each stage of the task evolution, update the metadata of the corresponding nodes in the initial task evolution framework so as to obtain the complete task evolution framework of each stage of task execution after the target task is completed.

[0041] In this embodiment, the metadata of each node in the initial task evolution framework is used to carry the task execution data of the corresponding stage in the task evolution. During the task evolution process, the metadata of the corresponding node is continuously updated through the task execution data of each stage to ensure the real-time nature and traceability of the metadata. Task execution data is the core foundation supporting metadata updates, and its main purpose is to reflect the execution basis and execution results of each stage. In some embodiments, task execution data includes at least one of the following: data source information and execution result information, wherein the data source information indicates the task execution basis of each stage, and the execution result information indicates the task execution status of each stage. Of course, other types of task execution data may also be included, and this application does not limit them.

[0042] The attributes of data source information can include multiple dimensions to comprehensively record various bases for the execution of each stage, ensuring the traceability and compliance of the execution process. In some embodiments, the attributes of data source information include at least one of the following: evidence attributes, rule attributes, graph attributes, and historical attributes. Of course, other dimensions of data source information attributes may also be included, and this application does not limit this. Evidence attributes indicate the input data and data source of each stage; rule attributes indicate the constraint rules for security and compliance; graph attributes indicate the knowledge graph; and historical attributes indicate historical case experience data. In this embodiment, data source information is the basic basis for the execution of each stage. For example, data source information with evidence attributes may include basic information such as data source, collection path, and evidence fingerprint, such as fault alarms, device performance, and network status, providing an evidentiary basis for subsequent verification and traceability of evidence and verification of the reliability of the execution basis; for example, data source information with rule attributes may include content such as security and compliance constraint rules, providing a verification basis for the feasibility verification of subsequent tasks; for example, data source information with graph attributes may include the alignment of tasks with entities and relationships in the knowledge graph, such as network topology and device dependencies; and data source information with historical attributes may include historical cases and experience data. For example, the data source information in the scheme evidence stage includes multi-dimensional evidence data obtained from rule nodes and knowledge graph nodes, as well as corresponding credibility labels.

[0043] In this embodiment, the attributes of the execution result information can cover multiple dimensions to comprehensively record various outputs after the execution of each stage, reflecting the execution effect and status. In some embodiments, the execution result information includes at least one of the following: stage execution process information, stage execution result, associated evidence matching result, and execution effect quantification result. Of course, other information (such as execution time information, execution subject information, etc.) may also be included, and this application does not limit this. In this embodiment, the execution result information is the output content after the execution of each stage. The stage execution process information indicates at least one of the intermediate process data of task execution and human-machine collaborative processing result; the stage execution result indicates at least one of the stage task execution completion, stage task execution failure, or stage task execution replacement scheme; the associated evidence matching result indicates the correlation between the stage execution result and the data source information, and the verification stage verifies the matching degree between the target execution scheme and the evidence; the execution effect quantification result indicates at least one of the stage simulation result, confidence assessment result, accuracy calculation result, risk assessment result, and conflict detection result. For example, the execution result information of the verification stage includes quantitative indicators such as the accuracy calculation value, confidence assessment value, and risk quantification value of the target execution scheme.

[0044] The core of this step is to continuously update the metadata of the nodes corresponding to each stage in the initial task evolution framework during the execution of each stage of the task evolution process. This enables the structured accumulation of task execution data into the framework nodes. Finally, after the target task is completed, a complete task evolution framework for each stage of task execution can be obtained, which can clearly present the complete information of the task execution basis, task execution process, and task execution result for each stage. This enables the traceability and visualization of the entire life cycle of the target task, facilitating the rapid identification of task advancement logic and potential problem stages.

[0045] In this embodiment, task execution data updates the metadata of nodes. The update method can be flexibly selected according to the node's carrying capacity requirements. It can be done by directly updating the metadata of the target node, or by expanding child nodes to achieve hierarchical storage of subdivided data, forming a metadata system where the target node coordinates and child nodes supplement and assist, thus improving the efficiency of data retrieval and traceability. In some embodiments, such as... Figure 4 As shown, step S102 above updates the metadata of the corresponding nodes in the initial task evolution framework based on the task execution data of each stage of task evolution, including the following steps (S201-S202): S201. For each stage of the task evolution, based on the task execution data of the stage, the target node corresponding to the stage in the initial task evolution framework is expanded with child nodes to obtain the child nodes of the target node. The child nodes have a collaborative relationship with the target node, and the sub-stages corresponding to the child nodes are used to assist the target node in executing the task of this stage. In this embodiment, for each stage of the task evolution, based on the task execution data of that stage, the corresponding target node in the initial task evolution framework is expanded with child nodes. The child nodes, as subdivided functional modules of the target node, specifically carry task execution data at a subdivided dimension, assisting the target node in executing the task of that stage. For example, the child node can determine the collaborative relationship with the target node based on the subdivided task execution data, and clarify the functional support relationship between the two through directed edges of corresponding types, such as result verification edges, basic support edges, causal inference edges, etc. For example, as... Figure 3As shown, the solution evidence node (i.e., the target node) needs to collect multi-dimensional data source information (i.e., data source information for task execution data) related to the target solution, such as rules, knowledge graphs, historical experience, and cases. Based on this task execution data, child nodes are expanded through supporting edges (basis_of), associating rule nodes, knowledge graph nodes, historical experience nodes, and case nodes. These expanded child nodes constitute the basic supporting nodes of the solution evidence node. Similarly, the solution verification node (i.e., the target node) expands its child nodes, such as confidence assessment nodes, risk assessment nodes, and conflict detection nodes, based on task execution data such as confidence assessment and risk assessment. Each child node is associated with the target node through result verification edges, carrying verification data of its corresponding dimension.

[0046] S202. Update the metadata of the target node and the metadata of the target node's child nodes based on the task execution data of the stage.

[0047] In this embodiment, after the sub-nodes are expanded, the metadata of the target node and the sub-nodes is updated synchronously based on the task execution data of this stage, forming a metadata system in which the target node coordinates and the sub-nodes provide supplementary assistance.

[0048] For example, updating the metadata of a target node based on task execution data of a stage includes updating the target node's metadata with data source information (such as the evidence fingerprint on which the execution is based, and the data source) and execution result information (such as the overall execution status of the stage and the results during the execution process) from the task execution data of that stage, ensuring that the target node can fully reflect the overall execution status of the corresponding stage. For example, the metadata of the solution generation node (target node) will be updated to include the core content of the target execution solution, evidence matching logic, confidence level and risk level, and human-machine collaborative decision-making records.

[0049] For example, updating the metadata of child nodes of a target node based on task execution data of a process includes: updating the detailed attributes corresponding to the metadata of the child nodes, carrying detailed execution data not covered by the target node, and realizing refined and multi-level storage of metadata. For example, the confidence assessment node (child node) associated with the solution generation node will update detailed information such as the confidence calculation value, calculation basis (evidence coverage, multi-model consistency data), and sampling variance; the risk assessment node (child node) will update detailed information such as the risk quantification value, business impact scope, and error probability.

[0050] In this embodiment, refined and multi-level storage of task execution data is achieved through the expansion of child nodes and the collaborative updating of metadata between the target node and child nodes. Child nodes, as sub-modules of the target node, carry execution data at subdivided dimensions. The target node coordinates the overall execution information, ensuring the integrity of metadata while improving the accuracy of data retrieval and traceability. This achieves hierarchical expansion of nodes and multi-level tagging of metadata, while providing a structured data foundation for subsequent metadata verification and anomaly tracing.

[0051] In this embodiment, intelligent agents can collect task execution data for each stage and update the metadata of corresponding nodes in the initial task evolution framework. Each stage can be executed by a central intelligent agent, which includes multiple sub-intelligent agents. These sub-intelligent agents collaborate to complete the task execution for each stage. To achieve cross-domain and efficient task execution, various distributed collaborative architectures can be adopted in this embodiment, with hierarchical collaboration between the global control-side entity and the execution entities at each autonomous region level. The specific forms of the control-side entity and the execution entities at each autonomous region level can be flexibly adjusted. For example, the control-side entity can be a distributed control node cluster, a cloud-native scheduling center, etc., while the execution entities at each autonomous region level can be edge agents, intra-domain autonomous units, functional microservice nodes, etc. This hierarchical collaboration avoids the single-point bottleneck of centralized architectures and the collaborative chaos of purely distributed architectures. This embodiment adopts a multi-agent distributed architecture, where each stage of task evolution is collaboratively executed by the control-side intelligent agent and multiple autonomous region execution intelligent agents. The control-side agent is deployed at the global control layer. It executes the scheme generation and orchestration phases and allocates subtask execution schemes to the corresponding autonomous domain execution agents. For example, the control-side agent also determines the initial task evolution framework based on the target task. Multiple autonomous domain execution agents are deployed within their respective business autonomous domains. Each autonomous domain execution agent executes the scheme execution phase within its domain and updates the metadata of the corresponding nodes in the initial task evolution framework based on the task execution data from the scheme execution phases within its domain. Those skilled in the art will understand that the embodiments described in this application using this multi-agent distributed architecture as an example are merely illustrative and do not constitute a limitation on the embodiments of this application.

[0052] In this embodiment, the control-side intelligent agent is deployed at the global control layer, responsible for process planning and task allocation from a global perspective. Multiple autonomous domain (AGN) execution agents are deployed in their respective business AGNs (such as bearer network domains and core network domains), responsible for localized execution and data collection within their respective domains. The control-side intelligent agent allocates the split sub-task execution schemes to the corresponding AGN execution agents. During execution, the AGN execution agents collect task execution data and update the metadata of corresponding nodes in the initial task evolution framework. During metadata updates, each AGN execution agent is responsible for the initial update of the metadata of target nodes and child nodes within its domain. After synchronizing this data to the control-side intelligent agent, the control-side intelligent agent performs consistency verification to avoid cross-domain metadata conflicts. After each AGN execution agent synchronizes its update results to the control-side intelligent agent, the control-side intelligent agent receives the synchronized task execution data and metadata update information from each AGN execution agent, integrates them to form end-to-end metadata, and ensures the consistency and global visibility of the initial task evolution framework node metadata.

[0053] by Figure 3 Taking the nodes of the initial task evolution framework as an example, different nodes have different update focuses during the task evolution process. For example, the task input node and the solution evidence node focus on context and data; the solution verification node and the solution decision node focus on evidence indicators, such as accuracy and risk assessment values; the solution execution node focuses on execution logs and feedback; and the human-machine collaboration node focuses on recording the human-machine collaboration process. Table 1 below lists these as examples. Figure 3 The state update content of each node in the initial task evolution framework is shown in Table 1.

[0054] Table 1.

[0055] In this embodiment, each stage of the task evolution includes at least a solution generation stage. The solution generation stage is the core decision-making stage of task execution, and its core function is to generate an adapted target execution plan based on the task input data. This stage can be further subdivided into multiple sub-stages according to the decision complexity or scenario requirements. For example, it may include multiple sub-stages such as data preprocessing, rule matching, solution deduction, quantitative verification, and human-machine collaborative decision-making to ensure the reliability, compliance, and adaptability of the solution. In some embodiments, the solution generation stage includes at least a verification stage and a decision-making stage.

[0056] In some embodiments, the verification step is used to verify the feature data of the target task based on the target verification dimension to obtain the verification result. The target verification dimension includes at least one of confidence level and risk level. Of course, there may be other verification dimensions (such as compliance, resource suitability, etc.), which are not limited in this application. The task execution data of the verification step includes at least the verification basis data and verification results related to the target verification dimension. Of course, there may be other task execution data (such as verification time data, verification subject data, etc.), which are not limited in this application.

[0057] For example, the central control agent calls the knowledge agent to obtain multi-dimensional data source information, such as rule constraints, graph knowledge, historical experience and similar cases, and calls the large model to learn the target learning features related to high confidence / low risk from the multi-dimensional data source information in advance. The target learning features include at least one of the following: evidence chain integrity, rule matching degree, historical case similarity, and execution result feedback.

[0058] In the verification phase, the feature data of the target task are verified based on the target verification dimension. This includes: the large model extracts task features of the target task based on the verification basis data related to the input target verification dimension, matches the task features of the target task with the target learned features, and outputs the verification results. For example, the verification basis data related to the target verification dimension includes data related to the target task, evidence chain coverage, business impact scope, potential conflicts, and operational irreversibility. The verification results include confidence scores and risk scores.

[0059] In this embodiment, the target verification dimension includes at least one of confidence level and risk level.

[0060] Confidence score primarily measures the reliability of candidate solutions generated by a large model. For example, confidence score verification mainly includes evidence chain coverage, rule / knowledge consistency, and historical case similarity. Evidence chain coverage checks whether the generated candidate solution is supported by complete evidence (such as data, logs, and monitoring metrics); the higher the evidence chain coverage, the higher the confidence score. Rule / knowledge consistency checks whether the generated candidate solution is consistent with the rule base and knowledge graph. For example, does the candidate solution fully conform to the preset rule base (such as communication protocol specifications and operation and maintenance procedures)? If the candidate solution's match rate with the rule base is 100%, then the candidate solution is verified to be consistent with the preset rules. Another example is aligning the entities and relationships in the candidate solution with the knowledge graph, calculating coverage and consistency; if the matching result is unique and conflict-free, the candidate solution is consistent with the knowledge graph; the higher the consistency, the higher the confidence score. Historical case similarity checks the similarity between the generated candidate solution and historical successful cases; the higher the similarity, the higher the confidence score.

[0061] Risk level primarily measures the scope and probability of adverse effects that the execution of a candidate solution may bring. For example, risk level verification mainly includes business impact scope, potential conflict detection, compliance and security verification, and uncertainty quantification. Specifically, business impact scope indicates high risk if it involves core links / critical business processes, and low risk if it involves edge nodes / local optimizations. Potential conflict detection checks whether the execution of the candidate solution competes for resources or conflicts with other tasks; more conflicts indicate high risk. Compliance and security verification checks whether the candidate solution violates security policies and compliance requirements (such as cross-border data, unauthorized access), indicating high risk. Uncertainty quantification is measured through the confidence interval and probability distribution output by the large model; high confidence (e.g., >90%) and small fluctuations indicate low risk. The uncertainty amplification effect needs to be considered; even with high confidence, if an error causes widespread impact (e.g., backbone network switching), the risk remains high. Quantification can be achieved by multiplying the impact scope by the error probability.

[0062] For example, the confidence level C can be calculated using the following formula:

[0063] Where A represents evidence coverage, obtained from the accuracy score A; M represents model consistency, which is the consistency of multi-model / multi-round inference, normalized to 0~1; V represents sampling variance, which reflects uncertainty, and is the variance of multiple outputs of large model inference or simulation from the same data source, normalized to 0~1. The larger the value, the higher the uncertainty. The weights of A and M are respectively. .

[0064] For example, when the evidence coverage A reaches 90%, the outputs M of multiple models are consistent, and the variance V is less than 0.1, the confidence level can be higher than 90%. The calculation process, calculation parameters, and final results are all written into the metadata of the confidence assessment node (child node) as the basis for subsequent verification and decision-making.

[0065] For example, the accuracy score A can be calculated using the following formula:

[0066] Where R represents Rule Consistency, which measures the matching degree between the candidate solution and the rule base, with a value ranging from 0 to 1, and 1 for a perfect match; K represents Knowledge Graph Consistency, which measures the consistency between the entity / relationship of the candidate solution and the coverage of the knowledge graph, with a value ranging from 0 to 1, and 0 for uniqueness and no conflict; H represents History Case Similarity, which measures the similarity between the candidate solution and historical successful cases, with a value ranging from 0 to 1; and E represents Evidence Completeness, which measures whether the candidate solution has a complete evidence fingerprint, with a value ranging from 0 to 1. The weights for R, K, H, and E are respectively. The weights can be adjusted according to different applications.

[0067] For example, the risk level R can be calculated using the following formula:

[0068] Where I represents the scope of business impact, indicating the importance of the candidate solution's execution to the business chain. Core chains have higher values ​​(e.g., 0.8-1.0), while edge chains have lower values ​​(e.g., 0.2-0.5), normalized to 0-1. U represents irreversibility, indicating whether the operation can be recovered once an error occurs. Complete irreversibility has a value close to 1, while rapid rollback has a value close to 0. For example, the irreversibility of physical operations like fiber optic patching is 0.9, and the configuration rollback operation is 0.1. P represents the probability of error, determined by a combination of factors including confidence level, uncertainty, conflict detection, and compliance. ,in, The value is determined by the variance / confidence interval width of the large model output; a larger value indicates a higher risk. F represents conflict detection; if the candidate solution has resource or policy conflicts, the value is close to 1; otherwise, it is 0. L represents compliance violations; if the candidate solution has compliance / security violations, the value is close to 1; otherwise, it is 0. In the above formula, 1-C indicates that the higher the confidence level C, the lower the error probability P. The weights for C, U, F, and L are respectively. =1.

[0069] In this embodiment, the control-side agent obtains the confidence level and risk level based on the above implementation method to form a verification result, which is used as the input of the decision-making process. At the same time, the verification result is written into the metadata of the solution generation node (target node) to complete the initial metadata update of the solution generation process.

[0070] In this embodiment, the core function of the decision-making process is to generate an appropriate target execution plan based on the task input data and verification results. The decision-making process can generate the target execution plan based on the task input data, verification results, and preset plan generation rules. Alternatively, it can utilize a large model, directly generating the target execution plan by inputting the task input data and verification results into the large model. Or, it can obtain the target execution plan through human-computer interaction and collaboration. This application does not limit the method by which the decision-making process generates the target execution plan.

[0071] In some embodiments, the decision-making process may select a human-machine collaboration mode based on the verification results, so as to obtain the target execution plan through the selected human-machine collaboration mode. In this process of obtaining the target execution plan, the interaction between the intelligent agent and the target object is different in different human-machine collaboration modes. The task execution data of the decision-making process includes at least the human-machine collaboration mode and the target execution plan.

[0072] In this embodiment, after receiving the verification result from the verification stage, the decision-making stage determines whether the preset conditions are met based on the verification result, and then selects different human-machine collaboration modes. For example, the preset conditions can be a confidence score higher than a preset high confidence score and a risk score lower than a preset low risk score. For instance, the preset conditions can be set to a confidence score ≥ 85% and a risk score ≤ 0.3. It is understood that the setting of preset conditions in this embodiment is merely an illustrative example and does not constitute a limitation on this application.

[0073] In this embodiment, the purpose of adopting the human-machine collaboration mode is to achieve complementary advantages between machine intelligence and human experience. The division of the human-machine collaboration mode can be flexibly set according to the interaction depth and decision-making authority allocation. For example, it can be divided into machine-led and human-reviewed, or human-machine equal collaboration, or human-led and machine-assisted, etc. The division of the human-machine collaboration mode in this embodiment is not limited. In some embodiments, the human-machine collaboration mode includes a first human-machine collaboration mode and a second human-machine collaboration mode. The first human-machine collaboration mode is also called the deliberation mode, in which the large model generates candidate solutions, and human experts determine the target execution plan after reviewing and adjusting the candidate solutions. If the verification result meets the preset conditions, it means that the current candidate solution has clear rule matching, high similarity to historical cases, and low execution risk, and the first human-machine collaboration mode can be selected. The second human-machine collaboration mode is also called the co-creation mode, in which the large model and human experts need to jointly determine the target execution plan through multiple dialogues and interactions. If the verification result does not meet the preset conditions, it means that the current candidate solution may have new task scenarios, incomplete knowledge graph matching, high execution risk, or complex rule constraints, and the second human-machine collaboration mode is more appropriate. Thus, a deep integration of machine efficiency and expert experience is achieved.

[0074] In the decision-making stage, if the verification result meets the preset conditions, the human-machine collaboration mode selects the first human-machine collaboration mode. The process of obtaining the target execution plan in the first human-machine collaboration mode includes: the agent generating candidate plans for the target task, and the target object reviewing and adjusting the candidate plans to determine the target execution plan. In the decision-making stage, if the verification result does not meet the preset conditions, the human-machine collaboration mode selects the second human-machine collaboration mode. The process of obtaining the target execution plan in the second human-machine collaboration mode includes: the agent iteratively generating the target execution plan based on the dialogue-based interaction content between the agent and the target object.

[0075] The following application example will introduce and explain the selection of the first human-machine collaboration mode (deliberation mode) or the second human-machine collaboration mode (co-creation mode) in the embodiments of this application. Figure 5 A flowchart illustrating a human-machine collaborative target determination execution scheme according to an embodiment of this application is shown. This human-machine collaborative target determination execution scheme is completed collaboratively by a control-side intelligent agent and a large model. For example... Figure 5 As shown, the human-machine collaborative target determination execution plan mainly includes the following steps (S301-S306): S301. Receive the target task and obtain the data associated with the target task; The control-side intelligent agent receives the target task issued by the upper-layer system. In this example, the target task is the core network resource expansion task. It obtains the data associated with the target task, such as task description information (task objective, context information, timestamp, etc.), task requirements (expansion bandwidth, expansion scope), service constraints (SLA latency ≤10ms, load balancing threshold ≤80%), and existing resource status.

[0076] S302. Collect multi-dimensional data source information to support the execution of the verification process; For example, the control-side intelligent agent collects multi-dimensional data source information related to the resource expansion task by invoking the knowledge intelligent agent. This includes: graph attribute data such as core network resource topology and device interface attributes in the knowledge graph; rule attribute data such as resource expansion compliance constraints and operating specifications in the rule base; historical attribute data such as execution data and experience parameters of similar historical resource expansion cases; and evidence attribute data such as real-time device load and bandwidth utilization collected on-site. For example, the above multi-dimensional data source information is aggregated as verification basis data related to the target verification dimension in the verification process.

[0077] S303. Perform the verification process and output the verification results, including confidence level and risk level. Based on the aforementioned multi-dimensional data source information, the verification process is executed. In this application example, the large model extracts the task features of the target task based on the verification criteria data related to the input target verification dimension. It then matches these task features with the target learning features. For instance, the large model generates three candidate resource expansion schemes, calls a simulation agent to perform digital twin pre-playing of each candidate scheme, and outputs the simulation results. It also calls a referee agent to calculate the confidence and risk of each candidate scheme. Finally, it outputs complete verification results, providing a basis for the subsequent selection of human-machine collaborative modes.

[0078] S304. Based on the verification results, select the corresponding human-machine collaboration mode. If the verification results meet the preset conditions, select the first human-machine collaboration mode and execute step S305. If the verification results do not meet the preset conditions, select the second human-machine collaboration mode and execute step S306. For example, if the candidate solution is of high confidence and low risk, the first human-machine collaboration mode is selected; if the candidate solution is of low confidence and high risk, the second human-machine collaboration mode is selected.

[0079] For example, among the above three candidate resource expansion schemes, the confidence level of the optimal candidate scheme is 88%, the risk level of the optimal candidate scheme is 0.25, and the verification result includes the optimal candidate scheme, its confidence level of 88%, and its risk level of 0.25. It also meets the preset condition of "confidence level ≥ 85% and risk level ≤ 0.3". The first human-machine collaboration mode can be selected to determine the target execution scheme.

[0080] S305. The first human-machine collaborative mode is adopted. The intelligent agent generates candidate solutions for the target task. The target object reviews and adjusts the candidate solutions to determine the target execution plan. In this embodiment, the control-side intelligent agent synchronously pushes the three candidate resource expansion schemes generated by the large model, the confidence / risk data of each scheme, the multi-dimensional data source information collected in step S302, and the resource usage details and simulation results corresponding to each candidate scheme to the human-machine collaboration interface. The target object (such as a human expert in the core network) reviews and partially adjusts the logic chain, resource matching, and risk points of each candidate scheme according to the information displayed on the human-machine collaboration interface, and determines the candidate scheme that meets business constraints, has controllable risks, and has high confidence as the target execution scheme.

[0081] S306. The second human-machine collaboration mode is adopted, and the target object and the large model determine the target execution plan based on the interactive content of the dialogue.

[0082] For example, step S306 specifically includes the following steps: RM1. Enable human-computer dialogue mode. Automatically or manually, experts can open a new conversation on the front-end interface and pull the large model in the relevant field and human experts (i.e., the target object) into the group chat. Human experts can adjust the task objectives, constraints, etc., and the large model will parse the relevant inputs into a structured task model.

[0083] RM2, large-scale models in related fields, and human experts communicate through dialogue. In response to information collection needs, it calls on information collection intelligent agents to obtain relevant information and integrates large-scale models in multiple fields and dialogues with human experts to generate candidate solutions. In this embodiment, a collaborative team composed of large models in the relevant field and multiple human experts iteratively optimizes candidate solutions through a dialog-based interactive window of the human-computer collaborative interface.

[0084] During the solution generation process, the large-scale model in the relevant field calls upon the information acquisition agent in real time to supplement real-time data of the target task (such as network topology changes, device load status, and the latest compliance rules). Combined with existing data source information and verification results, candidate solutions are generated in the interactive window. Human experts clarify business objectives, priorities, and constraints (such as compliance, security, and latency requirements), provide tacit knowledge and industry experience to fill the knowledge gaps of the large-scale model, confirm, correct, or supplement the candidate solutions generated by the large-scale model, and assess the feasibility and risks of the candidate solutions, proposing preferences or restrictions.

[0085] During task execution, the large model visualizes the causal links, evidence fingerprints, and confidence levels at each node based on the directed graph of the initial task evolution framework. When the environment changes or execution fails, it quickly generates alternative solutions and prompts human experts. Based on the interpretable links and confidence levels provided by the large model, human experts directly intervene at critical nodes or high-risk stages to modify parameters, adjust priorities, or select alternative paths. They also review the execution results proposed by the large model to confirm whether they comply with business logic and compliance requirements.

[0086] RM3. Human experts, based on their professional experience, propose modifications to the candidate solutions, including parameter optimization, structural adjustments, and the addition of new conditions.

[0087] For example, the target user (human expert), through a human-machine collaborative interface and drawing on their domain experience, discovers that the optimal candidate solution suffers from a "core equipment load approaching the threshold" problem. Therefore, they provide a modification suggestion: "Adjust the resource allocation ratio for capacity expansion to control the core equipment load below 75%." This modification suggestion is simultaneously entered into the human-machine collaborative interface to ensure traceability. The large model receives the target user's modification suggestion, combines it with real-time resource status data, adjusts the optimal candidate solution, and optimizes the resource allocation ratio. After adjustment, the large model recalculates the solution's confidence level (adjusted confidence level 90%) and risk level (adjusted risk level 0.22), simultaneously updates resource usage details, integrates the optimized candidate solution, adjustment records, and recalculated verification data, and pushes it back to the human-machine collaborative interface for expert confirmation.

[0088] RM4. Human experts confirm the final target implementation plan.

[0089] During the iteration process, the information acquisition agent continuously supplements relevant data, and the domain-wide model synchronously updates the confidence and risk levels of the solution until experts confirm the optimal solution, forming the target execution plan. For example, the entire process is recorded in dialogue and interaction logs (such as expert modification traces, data supplementation records, solution iteration versions, and detailed changes in confidence / risk levels), serving as metadata for the solution generation nodes and corresponding sub-nodes during the execution process, supporting subsequent auditing, traceability, and experience reuse.

[0090] This application example fully demonstrates the selection logic and execution process of the human-machine collaboration mode through a specific core network resource expansion task. It enables direct collaboration between domain big data model experts and human experts on the same interface, and generates the final target execution plan by fusing opinions through the big data model. For example, the human-machine interaction in this embodiment supports multimodal input from human experts, such as text, voice, images, and files. The human-machine interaction process and results are clearly visible. Through human-machine interaction, expert experience and domain knowledge can be quickly absorbed, reducing trial-and-error costs and improving the relevance and feasibility of the target execution plan, making it suitable for complex and ever-changing communication scenarios.

[0091] For example, a human-computer interaction interface can be designed according to requirements. Figure 6 A schematic diagram of a human-computer collaborative interaction interface according to an embodiment of this application is shown. The following section addresses... Figure 6 The innovative features of the interactive interface shown will be briefly introduced and explained. For example... Figure 6 As shown, the multimodal input area supports seamless switching between voice, text, and image channels, and integrates and parses them within the same conversation. The mode switching prompt area displays the current mode in real time, such as... Figure 6As shown, the current mode is automatic mode. For example, modes can include: automatic mode (i.e., a mode where the target execution plan is generated solely by the large model without human expert involvement), deliberation mode (i.e., the first human-machine collaborative mode), and co-creation mode (i.e., the second human-machine collaborative mode), dynamically switching based on accuracy scores and providing users with decision-making context. The parameter setting / negotiation area can be embedded in the interaction between experts and the large model, dynamically adjusting key parameters (SLA priority, risk threshold, rollback strategy, etc.). The dialogue and results area can embed interpretable messages; each inference message from the large model can highlight the current evidence chain node and causal relationship, allowing human experts to verify it instantly. The task evolution and evidence chain visualization area visually presents the nodes corresponding to each stage of the target task's evolution from alarm to recovery, with each node carrying task execution data, including data source information and execution result information, such as evidence source and credibility (i.e., confidence level). The comprehensive output area provides a complete task evolution framework for each stage of task execution after the target task is completed, combining dialogue conclusions and the evidence chain, and can be directly archived or used for automatic execution.

[0092] In this embodiment, before each stage is executed and before updating the corresponding node metadata, the autonomous domain execution agent or control-side agent needs to perform feasibility verification on the reliability of the execution basis and the controllability of the execution risk for each stage. In particular, as the risk control layer for the output and inference results of the large model, it intercepts unreasonable assumptions, unreliable verifications, and unsafe decisions to avoid the large model from producing illusory outputs, execution deviations, or illegal operations, and intercepts risks in advance. In some embodiments, based on the task execution data of each stage of task evolution, the metadata of the corresponding nodes in the initial task evolution framework is updated. This includes: for each stage of task evolution, performing feasibility verification on the execution of this stage based on the task execution data of the stage, and updating the metadata of the node corresponding to the stage in the initial task evolution framework based on the task execution data of the stage after the verification is passed. In this embodiment, the verification dimension can be flexibly selected according to the characteristics of the stage. Feasibility verification includes at least one of the reliability of the execution basis and the controllability of the execution risk. Of course, it may also include, but is not limited to, the authenticity, compliance, and logical rationality of the execution basis. This embodiment does not limit this. Verification methods can employ various means such as rule validation, data comparison, simulation pre-run, and conflict detection; this application embodiment does not impose any limitations on these methods. In this embodiment, the purpose of feasibility verification is to ensure that the execution process is safe, compliant, and effective, and to avoid execution without basis or high-risk execution.

[0093] The feasibility verification for each step provided in the embodiments of this application is described below: (1) Verification of the reliability of the execution basis: A1. Verification of Implementation: For example, in the solution generation stage, it is confirmed that both the candidate solutions and the target execution solution generated in this stage are bound to valid evidence fingerprints (i.e., data source information in the task execution data). Data without supporting evidence, with ambiguous evidence, or with evidence irrelevant to the task is marked as low confidence and triggers manual review to intercept unfounded illusionary outputs from the large model. For example, the target execution solution determined in the solution generation stage must be associated with the device interface attributes of the knowledge graph and the operation specifications of the rule base; otherwise, it will fail the verification and the metadata update of the corresponding node in this stage cannot be executed.

[0094] A2. Rule-based Verification: For example, during the solution execution phase, verify whether the execution basis of the task execution plan violates security compliance rules or business operation specifications (such as cross-border data transmission restrictions, device operation permissions, and load balancing thresholds). If a violation occurs, the execution of the phase is directly blocked, the reason for the violation and correction suggestions are returned, and the violation record is written to the knowledge base for reference in subsequent similar tasks. For example, the core network resource scheduling plan must comply with the rule "load balancing threshold ≤ 80%"; otherwise, a rule alarm is triggered, and the plan execution is blocked.

[0095] (2) Verification of the controllability of execution risks: B1. Graph Alignment Verification: For example, in the solution execution phase, it is confirmed that the execution basis of the sub-tasks in this phase must achieve sufficient matching with the domain topology / knowledge graph. Otherwise, it is marked as high-risk, and the information acquisition agent needs to supplement the graph correction data and adjust the execution basis to avoid execution errors caused by large model graph matching deviations. For example, the order of sub-tasks in the solution execution phase must be consistent with the device dependencies in the network topology graph; otherwise, it is judged as high-risk, and the sub-task logic needs to be readjusted.

[0096] B2. Conflict Detection: For example, in the verification stage, if there is insufficient multi-source consistency or cross-source conflict (logical implication / mutual exclusion) among multiple candidate solutions, it is judged as high risk and cannot pass the verification.

[0097] B3. Simulation Pre-verification: In the verification phase, a simulation agent is invoked to perform a simulation pre-run. If the simulation results do not meet the SLA service level requirements or security compliance requirements, they are judged as high-risk and cannot pass the verification. The process can be returned to the solution generation phase to adjust the target execution plan, but it must not enter the actual execution phase to avoid losses such as business interruption and data loss.

[0098] B4. Uncertainty Verification: For example, in the verification stage, if the accuracy of the candidate solution is not up to standard or is a risky solution, it is judged as high risk and cannot pass the verification.

[0099] In this embodiment, the execution of this stage and the metadata update work can only proceed after the feasibility verification is passed. For example, if the verification fails, the reasons for failure, verification logs, and correction suggestions can be saved as historical case experience data to the knowledge base. At the same time, manual intervention is triggered for correction. After correction, the feasibility verification is re-executed until it passes, ensuring that the execution of each stage has a reliable basis and controllable risks.

[0100] In this embodiment, during the task execution phase, after the task in this phase is completed, the execution result of the task execution phase needs to be judged to ensure that the execution result meets the preset requirements before the final complete task evolution framework is formed. In some embodiments, Figure 7 This document illustrates a flowchart of a complete task evolution framework, showing the process of obtaining each stage of task execution after the completion of the target task, according to an embodiment of this application. (See attached flowchart.) Figure 7 As shown, the complete task evolution framework for obtaining the task execution of each stage after the target task is completed mainly includes the following steps (S401-S402): S401. Determine whether the execution result of the target task in the task execution stage meets the preset requirements. The task execution stage is one of the stages in the task evolution. For example, the preset requirements are the execution result preset requirements carried in the target task received by the control-side intelligent agent in step S101. For instance, the preset requirements for a fault diagnosis task are a fault root cause localization accuracy of ≥95% and a fault recovery rate of ≥90%, with an execution latency of ≤30 minutes; the preset requirements for a resource scheduling task are a subtask execution latency of ≤5 minutes and a resource utilization rate of ≥80%, with no record of violations; and the preset requirements for a compliance audit task are a decision-making process compliance rate of 100% and a complete and traceable chain of evidence. It is understood that the above preset requirements are merely illustrative examples, and these examples are only used to explain this application and do not constitute a limitation on this application.

[0101] For example, each autonomous domain execution agent synchronizes the execution results (including completion status, quantitative indicators, and anomaly logs) of all sub-tasks in the execution phase of the solution within its domain to the control-side agent in real time; the control-side agent integrates the execution result data of all autonomous domain execution agents to generate a global execution result, which includes a comparison between the execution results of each sub-task and the preset requirements.

[0102] S402. In response to the execution result meeting the preset requirements, determine that the target task execution has ended, and determine the current task evolution framework as the complete task evolution framework.

[0103] For example, if the execution results of all subtasks in the global execution result meet the preset requirements, there are no unresolved anomalies, and the evidence chain is complete, the control-side intelligent agent will determine the current task evolution framework (including all core nodes, sub-nodes, metadata of each node, and directed edge relationships between nodes) as the complete task evolution framework.

[0104] In addition, when the execution result does not meet the preset requirements, an exception handling mechanism needs to be triggered. The rollback method can be flexibly selected according to the root cause of the exception. It can roll back to the most recent critical step or roll back across steps to the root cause of the problem. Through targeted adjustments and re-execution, it can be ensured that the task execution result ultimately meets the preset requirements. Figure 8 A flowchart illustrating the processing of a situation where the execution result does not meet preset requirements, as shown in an embodiment of this application, is also provided. Figure 8 As shown, after step S401, the processing flow when the execution result does not meet the preset requirements mainly includes the following steps (S501-S502): S501. In response to the execution result not meeting the preset requirements, the task evolution framework obtained from the task input to the task execution stage is rolled back to the rollback target stage that caused the preset requirements not to be met. In this embodiment, based on the metadata of each node in the task evolution framework and the directed edge relationships between nodes, the execution basis, execution process data, and execution result data of each stage in the task evolution can be clearly displayed. The scheme execution node supports the feedback of execution results and anomaly information to upstream nodes through state feedback edges. The control-side agent, based on the synchronous feedback of execution results and anomaly information (such as subtask execution failure logs, risk assessment exceeding records, and metadata verification failures) from each autonomous domain execution agent, traces back along the state feedback edges and causal inference edges. Combined with the metadata of each node, it can accurately locate the root cause of the anomaly, i.e., the target stage that fails to meet preset requirements, thereby significantly improving anomaly handling efficiency and reducing business impact. For example, if the scheme execution stage fails due to an error in the factor task dependency relationship, tracing back reveals that the error originates from the subtask splitting logic in the scheme orchestration stage, thus determining the scheme orchestration stage as the target stage for rollback; if the scheme is unreasonable due to a deviation in the confidence calculation in the verification stage, then the rollback proceeds to the verification stage in the scheme generation stage.

[0105] S502, Adjust the execution parameters of the rollback target stage, re-execute each stage of the task evolution from the rollback target stage to the end of the task execution, switch to executing the task execution data based on each stage of the task evolution, and update the metadata of the corresponding nodes in the initial task evolution framework.

[0106] In this embodiment, after locating the target rollback stage, the control-side agent, for example, combines the task execution data of that stage (such as execution basis, verification logs, and human-computer interaction records) to deeply analyze the causes of the anomaly, such as incomplete evidence matching, missing rule verification, inadequate human-computer collaboration adjustment, or unreasonable sub-node expansion. It can also retrieve historical handling experience of similar anomalies from the knowledge base to adjust the execution parameters of the target rollback stage. For example, if the cause of the anomaly is missing evidence, the target rollback stage is the scheme verification node, and the control-side agent triggers the information acquisition agent to supplement the corresponding data source; if the cause of the anomaly is rule violation, the target rollback stage is the scheme generation node, and the control-side agent corrects the violation parameters in the scheme while simultaneously triggering the human-computer collaboration node to generate a new target execution scheme; if the cause of the anomaly is human-computer collaboration adjustment deviation, the target rollback stage is the human-computer collaboration node, and the control-side agent triggers the human-computer collaboration node.

[0107] After adjusting the execution parameters of the rollback target stage, the process of re-executing each stage of the task evolution from the rollback target stage to the end of task execution proceeds. This involves executing task execution data based on each stage of the task evolution and updating the metadata of the corresponding nodes in the initial task evolution framework. For example, if the rollback target stage is a scheme orchestration node, after adjusting the execution parameters of the scheme orchestration node, the execution schemes for each sub-task obtained from scheme decomposition and orchestration are re-done. The control-side agent issues a re-execution command to the corresponding autonomous region execution agent to execute the corresponding sub-task execution scheme, synchronizing the task execution data during the re-execution process, updating the metadata of the corresponding nodes, and synchronizing it to the control-side agent in real time. If the execution result after re-execution meets the preset requirements, the subsequent process continues until a complete task evolution framework is formed. If the re-execution still does not meet the preset requirements, the process of locating the rollback target stage, adjusting the execution parameters, and re-executing is repeated until the execution result after re-execution meets the preset requirements. Meanwhile, the complete process of this abnormal rollback (cause of the abnormality, rollback steps, adjustment plan, re-execution results, and verification records) will be stored in the knowledge base as historical experience data, associated with the target task, to provide support for the handling of abnormalities in subsequent similar tasks and achieve iterative optimization of task execution capabilities.

[0108] In this embodiment, after obtaining the complete task evolution framework, its reuse method can be flexibly selected. It can directly replace the original initial task evolution framework, or it can be stored separately as a dedicated template corresponding to the target task, or it can be integrated with the complete frameworks of multiple similar tasks to form a general template for reuse by subsequent tasks of the same type, thereby reducing the framework construction cost of subsequent similar tasks and improving task execution efficiency. In some embodiments, after obtaining the complete task evolution framework, the method provided in this application embodiment further includes: updating the initial task evolution framework corresponding to the target task to the complete task evolution framework.

[0109] For example, the control-side agent updates the complete task evolution framework determined in step S402 to the initial task evolution framework corresponding to the target task, and updates it to the evolution graph template corresponding to the target task. For example, an association index between the target task and the evolution graph template can be established and stored in the global knowledge base for reuse in subsequent tasks of the same type. For example, the control-side agent can also generate a task interpretability report, including the complete task evolution framework, key decision paths, execution details of each stage, and metadata summary, which is stored in the global knowledge base as historical experience data.

[0110] Below, in an application example, the distributed architecture and corresponding task execution method of this application will be explained and described in detail with reference to the accompanying drawings and preferred embodiments. These embodiments are only used to explain the present invention and do not constitute a limitation thereof.

[0111] Figure 9 A schematic diagram of the structure of a multi-agent distributed system is shown in an application example of this application. For example... Figure 9 As shown, the multi-agent distributed system provided in this application embodiment includes: a central control layer, a human-machine collaboration layer, a domain autonomy layer, and a security layer.

[0112] The following explains the composition and function of each layer in a multi-agent distributed system: (1) Central control layer: This includes a control-side intelligent agent responsible for global decision-making, process scheduling, and data synchronization, ensuring consistency in task execution across the entire chain. It is responsible for generating the initial task evolution framework, globally synchronizing and updating metadata, coordinating the scheduling of agents at each layer, and ultimately determining the complete task evolution framework. For example, the control-side intelligent agent includes a policy control agent and an execution control agent.

[0113] For example, the functions of the policy control agent include: (1) intent understanding, parsing the business intent of the input target task and generating an initial task evolution framework; (2) risk assessment, assessing potential security risks, compliance and business impact; (3) decision generation, integrating global information and using the agent to determine the target execution plan; and adjusting the strategy and plan based on the sub-task execution results during the task execution process, which is suitable for dynamic network environments; (4) task decomposition, splitting the target execution plan into executable sub-tasks.

[0114] For example, the functions of the execution control agent include: (1) process orchestration, planning the execution order of subtasks according to dependencies and priorities; (2) resource allocation, allocating network, device, computing and other resources among different domains; (3) atomic execution scheduling: sending tasks to specific interfaces and operation instructions to the domain autonomous layer.

[0115] (2) Human-machine collaboration layer: As the interface between the system and external users, it supports two core modes: Human-machine collaborative review mode: After the user submits the requirements, the large model generates an initial solution. In high-confidence or critical task scenarios, experts or users review and confirm the solution to generate the final target execution plan, ensuring the solution is robust.

[0116] Human-machine collaborative creation mode: When there is low confidence or creative exploration is needed, users interact with the large model intelligent agent in real time, put forward modification suggestions, and the large model immediately integrates and optimizes to generate the target execution plan.

[0117] (3) Domain autonomy level: It comprises multiple domains, which can be divided by technical domains (such as transmission domain, access domain, and core domain) or business domains. Each domain corresponds to an autonomous domain execution agent, responsible for executing sub-tasks within its domain, collecting task execution data, verifying local feasibility, expanding sub-nodes and updating metadata, and feeding relevant data back to the control-side agent. For example, the autonomous domain agent includes: an information acquisition agent, an adaptation decision agent, and an execution control agent. In this embodiment, the information acquisition agent collects real-time business data within its domain (such as device operating status, alarm information, and operation records) to provide local data support for metadata updates and task execution. The adaptation decision agent is responsible for feasibility verification before execution within its domain, focusing on verifying the local compliance of the execution basis and its matching degree with the domain's knowledge graph, thus proactively intercepting local execution risks. The execution control agent executes according to the sub-task execution plan and provides status feedback.

[0118] (4) Security layer: Composed of multiple intelligent agents, exemplarily including: a simulation agent, a referee agent, an audit agent, and a knowledge agent, all invoked uniformly by the control-side agent, providing global-level technical support for verification, decision-making, and anomaly handling at each stage. For example, the simulation agent executes the solution verification node, performing simulation pre-runs and effect predictions of candidate solutions to prevent negative impacts. The referee agent supports the execution of the solution verification stage, verifying reliability during the verification process. The audit agent records and archives operation logs in real time, including the execution process and decision-making basis, forming traceable logs that meet compliance auditing and interpretability requirements. The knowledge agent manages the case library, rule library, and knowledge graph for decision-making reference and continuous optimization.

[0119] The multi-agent distributed system provided in this embodiment can be applied to pure software form or software and hardware combination form. (1) Pure software implementation: The multi-agent distributed system is deployed on a cloud computing platform, data center or virtualization environment, and various intelligent agent components are run in the form of microservices. Internal and cross-system communication is realized through software bus, API interface and message queue. (2) Software and hardware combination implementation: Hardware processing units (such as edge computing gateway, SDN controller, smart probe) are deployed in network infrastructure or edge nodes, distributed intelligent agents are configured, and information acquisition agents and execution control agents are pushed down to the edge side to realize low latency autonomy; edge nodes combine with the central cloud platform to complete cross-domain collaboration.

[0120] The multi-agent distributed system provided in this embodiment solves the problems of insufficient flexibility in traditional centralized architectures and difficulty in ensuring consistency in distributed architectures. The system is divided into a central control layer, a human-machine collaboration layer, a domain autonomy layer, and a security layer, forming a global and local collaborative closed loop. Key capabilities (interpretability, conflict arbitration, and human-machine collaboration) flow horizontally through each layer, ensuring that key control points are effective online throughout the entire task lifecycle rather than being remedied afterward. The central control layer possesses a global perspective and resource scheduling capabilities, while the domain autonomy layer possesses local decision-making, adaptive adjustment, and rapid response capabilities. It can execute sub-tasks in parallel under the guidance of the control-side agents, and all agents are implemented by independent agents, facilitating on-demand expansion and replacement.

[0121] Figure 10 An application example of this application is shown. Figure 9 The flowchart illustrates a task execution method for a multi-agent distributed system. (Example:) Figure 10 As shown, the task execution method mainly includes the following steps (S601-608).

[0122] S601. Receive the target task, and the policy control agent generates the initial task evolution framework; The control-side agent receives the target task, which can be triggered by user interaction, system events (alarms / monitoring), policy timers, external system calls, etc. Data related to the target task includes: multimodal front-end (text / voice / image / file), northbound API, alarms / telemetry, timing policies, etc.

[0123] Based on the target task, the control-side agent obtains the evolution graph template corresponding to the target task and generates an initial task evolution framework. It identifies the core nodes corresponding to each stage in the task evolution process, defines the directed edge association types between nodes, and initializes the metadata of each node.

[0124] S602. The strategy control agent collects multi-dimensional data source information, performs the verification process, outputs the verification results of confidence and risk, and selects the corresponding human-machine collaboration mode based on the verification results. S603. The human-machine collaboration agent determines the target execution plan based on the selected human-machine collaboration mode. In the deliberation model, a preliminary plan is provided using a large model, and the implementation plan is determined after expert review. In the co-creation model, experts and the large model iterate in a dialogical manner, with large models from different fields and human experts negotiating, and the large model synthesizing the results to determine the implementation plan.

[0125] In addition, the human-machine collaborative agent runs through the entire lifecycle of the target task and can be triggered in situations of high risk, conflict points, and multiple decision-making scenarios.

[0126] S604, Execution of the overall control agent's execution plan arrangement stage; The execution control agent breaks down the target execution plan into sub-task execution plans, clarifies the sub-task dependencies, allocates computing, storage, bandwidth and other resources according to the execution objects, requests sub-task execution domains, breaks down the target execution plan into monitorable and rollbackable atomic operations, and distributes them to the execution agents in each autonomous domain for localized execution. S605, The scheme for executing locally allocated sub-tasks in parallel by autonomous domain execution agents; In this embodiment, each autonomous domain is an autonomous entity that can independently perceive, make decisions, and execute tasks according to domain policies, and supports collaboration with other autonomous domain execution agents.

[0127] The Information Acquisition Agent collects real-time business data within the domain (such as device operating status, alarm information, and operation records) to provide localized data support for metadata updates and task execution. The Adaptation Decision Agent is responsible for feasibility verification before execution of each step within the domain, focusing on verifying the local compliance of the execution basis and its matching degree with the domain's knowledge graph, thus proactively intercepting local execution risks. The Execution Control Agent executes atomic operations according to the sub-task execution plan and feeds back the execution status and metadata update information to the control-side intelligent agent in real time.

[0128] S606. Execution result verification: Determine whether the execution result meets the preset requirements. If it meets the preset requirements, proceed to step S608; otherwise, trigger the exception rollback mechanism and proceed to step S607. After all subtasks are completed, each autonomous region's execution agent synchronizes the execution results of the subtasks (such as fault repair status, execution latency, and repair effect) to the control-side agent. The control-side agent then aggregates these results to generate a global execution result. The control-side agent then verifies the global execution result against preset requirements (such as a fault repair rate of 100%, recovery time ≤ 30 minutes, and no secondary faults). If the global execution result meets the preset requirements, the task execution ends, and a complete task evolution framework is generated. If it does not meet the requirements, an exception rollback mechanism is triggered to accurately locate the target rollback stage, adjust the plan, and re-execute until the global execution result meets the preset requirements.

[0129] S607. Accurately locate the target step of rollback, adjust the plan and re-execute the rollback target step until the target plan is completed, until the global execution result meets the preset requirements, and execute step S608. S608, Generate a complete task evolution framework.

[0130] After the control-side agent confirms that the global execution result meets the preset requirements, it determines the current task evolution framework (including all nodes, child nodes, directed edge relationships, and updated full metadata) as the complete task evolution framework. Simultaneously, it updates the complete framework to the evolution graph template corresponding to the target task, stores it in the global knowledge base, and establishes an association index between the target task and the evolution graph template for reuse in subsequent similar tasks. At the same time, the control-side agent archives the complete record of the target task execution (human-machine collaboration record, verification record, execution record, and metadata update record), completing the closed loop of the entire task process.

[0131] Figure 11 A detailed flowchart illustrating the task execution method shown in the application example of this application is provided. Figure 11 As shown, the task execution method mainly includes the following steps (S701-S712): S701: Receive the target task and trigger multimodal data input and acquisition; The system receives target tasks from external or internal sources, and multimodal data, including monitoring alarms, scheduled tasks, and manual instructions, serves as the conditions for starting the process. In this step, the control agent obtains the evolution graph template corresponding to the target task and generates an initial task evolution framework. It identifies the core nodes corresponding to each stage of the task evolution process, defines the directed edge association types between nodes, and initializes the metadata of each node.

[0132] S702. Analyzing the requirements of the target task and retrieving knowledge yields multi-dimensional data source information; In this step, the large model is used to analyze and process the requirements of the target task, and to perform matching and retrieval in the knowledge base, prioritizing matching the knowledge graph and then matching the RAG knowledge base.

[0133] S703, Selecting human-machine mode based on multi-dimensional data source information; Based on the multi-dimensional data source information obtained from the demand analysis and knowledge retrieval in step S702, candidate solutions are generated using a large model, and the confidence and risk of the candidate solutions are calculated. For example, if the candidate solution has high confidence and low risk, the human-machine review mode is selected and step S704 is executed; if the candidate solution has low confidence and high risk, the human-machine co-creation mode is selected and step S705 is executed. S704. Based on the human-machine review model, determine the target implementation plan; Candidate solutions generated based on the large model are reviewed and adjusted by experts to determine the final target implementation plan.

[0134] S705. Based on the human-machine co-creation model, determine the target execution plan; The human-computer dialogue window is activated, allowing large models from different fields and multiple human experts to engage in direct dialogue. Through the negotiation process of human-computer interaction, the results are fused using large models to obtain the target execution plan.

[0135] S706. Based on the target execution plan, perform global planning and orchestration to generate a scheme orchestration plan; The target execution plan is broken down into sub-task execution plans, the execution order of the sub-tasks is optimized, the degree of parallel execution and resource allocation are calculated, and an overall plan orchestration is generated.

[0136] S707. Conduct risk assessment and simulation of the scheme arrangement plan to obtain risk assessment results and simulation results; Based on models or digital maps, the scheme orchestration plan (including the execution order, parallelism, and resource allocation of each sub-task) is simulated and executed, and risk assessment and simulation are performed to obtain risk assessment results and simulation results. S708. Determine whether the risk assessment result P and the simulation result Q meet the risk threshold P' and the simulation result requirement Q'. If they meet, proceed to step S709; otherwise, proceed to step S705. S709. Assign the subtask execution plan to the corresponding autonomous domain execution agent. Each autonomous domain execution agent executes the locally assigned subtask execution plan in parallel and synchronizes the subtask execution results to the control side agent. For example, the target task is decomposed into subtasks and assigned to different autonomous domains for execution. The assigned subtask execution plan includes not only the specific subtask plan, but also the execution steps, rollback strategies, etc.

[0137] For example, the task scheduling process is a full-link mechanism of "task parsing -> decomposition -> allocation -> execution plan generation -> execution deployment -> conflict arbitration -> rollback guarantee -> result closure". It not only ensures the efficiency of automated execution, but also ensures security and compliance through rollback and arbitration mechanisms, while continuously accumulating knowledge and improving the system's evolutionary capabilities.

[0138] The control-side intelligent agent, based on the task requirements of the target task, invokes a large model to understand and structure the task, extracting objectives, constraints, priorities, and latency requirements, and decomposes the task based on rules, knowledge graphs, and historical cases. Task decomposition includes first-level subtask decomposition, which breaks down the target execution plan into several subtask execution plans based on business logic or network domain division, and further refinement of the first-level subtasks into executable second-level subtasks. The deployment of subtask execution plans is completed by mapping the corresponding subtask execution plans to executable APIs or device interfaces within the corresponding autonomous system and adjusting parameters.

[0139] During the execution of sub-task execution plans, the system needs to select, replan, or roll back the sub-task execution plan based on three types of real-time signals: "adaptation," "execution," and "conflict detection." The goal is to maximize business utility, minimize risk and latency under given constraints, and maintain causal consistency and interpretability with the initial task evolution framework. For example, after receiving the sub-task execution plan assigned by the upper layer, the autonomous region execution agent establishes an initial execution plan and performs an adaptation check, verifying whether the assigned sub-task execution plan matches the current environmental conditions. If they do not match, an alternative plan for the sub-task execution plan is generated. The system then performs execution prediction, risk assessment, and conflict detection on the sub-task execution plan. For example, it calls a simulation agent or historical case library to predict the execution results and benefits, calculate confidence and risk levels, and determine whether thresholds are met. It also checks whether there are resource, policy, or timing conflicts in the sub-task execution plan; if such conflicts exist, arbitration or adjustment of the execution order is performed. If the confidence level of the subtask execution plan is high and the risk is low, it will be executed automatically. If the confidence level of the subtask execution plan is insufficient or the risk is high, it will switch to a human-machine co-creation mode, where experts will intervene to regenerate the target execution plan. After the subtask enters execution, the autonomous region execution agent monitors the execution status of the subtask in real time. If an execution anomaly occurs, the operation will be rolled back or an alternative plan will be switched. Finally, after each autonomous region execution agent completes the locally assigned subtask execution plan, it will synchronize the subtask execution results (such as fault repair status, execution latency, and repair effect) to the control-side agent.

[0140] S710, Aggregate the execution results of all subtasks; The control-side agent aggregates the execution results of all subtasks and generates a global execution result. S711. Determine whether the global execution result meets the preset requirements. If it meets the preset requirements, execute step S712; otherwise, trigger the exception rollback mechanism. For details on triggering the exception rollback mechanism, please refer to the description in step S608, which will not be repeated here.

[0141] S712. Confirm the completion of the task execution and generate a complete task evolution framework.

[0142] If the global execution result meets the preset requirements, the task execution is confirmed to be complete, a complete task evolution framework is generated, and the evolution diagram template corresponding to the target task is updated using the complete task evolution framework. Based on the entire task evolution process, an interpretable report is generated, and the complete record of the target task execution (human-machine collaboration record, verification record, execution record, metadata update record) is archived and stored in the global knowledge base, completing the closed loop of the entire task process.

[0143] The task execution method provided in this application determines an initial task evolution framework based on the target task. During the task evolution process, the execution data (data source, execution results, etc.) of each stage of the task evolution are structurally accumulated into the framework node metadata. This can clearly present the complete information of the task execution basis, task execution process, and task execution results of each stage, realize the traceability and visualization of the entire task lifecycle, facilitate the rapid location of task advancement logic and potential problem stages, thereby improving the trust level of operation and maintenance, and ensuring the compliance and reliability of task planning and task execution processes.

[0144] Figure 12 A structural block diagram of an electronic device 1000 illustrating an exemplary embodiment of this application is shown. The electronic device 1000 can be implemented as the task execution method described above.

[0145] Typically, electronic device 1000 includes a processor 1001 and a memory 1002.

[0146] Processor 1001 may include one or more processing cores, such as a quad-core processor, a deca-core processor, etc. Processor 1001 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1001 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1001 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1001 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0147] The memory 1002 may include one or more computer-readable storage media, which may be non-transitory. The memory 1002 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1002 are used to store at least one instruction, which is executed by the processor 1001 to implement all or part of the steps in the task execution method shown in the method embodiments of this application.

[0148] Those skilled in the art will understand that Figure 12 The structure shown does not constitute a limitation on the electronic device 1000, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0149] In one exemplary embodiment, a readable storage medium is also provided, which stores a program or instructions that, when executed by a processor, implement all or part of the steps in the task execution method shown in the above method embodiments. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0150] In one exemplary embodiment, a computer program product is also provided, the computer program product including a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform all or part of the steps of the task execution method shown in the above method embodiments.

[0151] It should be understood that the training and prediction processes of the AI ​​models involved in the various embodiments of this specification all adhere to multiple legal and compliant principles, including legal data sources, compliant data content, compliant data governance, compliant training objectives and schemes, compliant training processes, compliant training environments and tools, and compliant ethical verification of training results, and comply with the requirements of Article 5 of the Patent Law. Among them: Data source legitimacy: All datasets used for AI model training were obtained through legal means, covering three categories: publicly authorized data, data authorized by partners, and self-collected compliant data. Publicly authorized data comes from compliant data sources following open-source licenses such as Apache 2.0, with complete copyright attribution and authorization scope clearly marked, and no unauthorized open-source code or data reuse. Data authorized by partners has been subject to formal data usage agreements, clearly defining the scope, duration, and confidentiality obligations, and possessing a complete authorization chain. For self-collected data involving personal information, strict informed consent procedures have been followed, and anonymization processes (including but not limited to field masking, feature anonymization, and differential privacy technology applications) have been implemented to remove personally identifiable information, fully complying with the requirements of relevant laws and regulations such as the "Interim Measures for the Administration of Generative Artificial Intelligence Services" and the "Personal Information Protection Law."

[0152] Data content compliance: The AI ​​model's dataset undergoes multiple screenings and cleaning processes to remove all content that may violate social morality or harm public interests. It contains no obscene, pornographic, violent, discriminatory, or information that endangers national or public safety, nor does it involve the illegal acquisition or use of genetic resources. For data in sensitive fields (such as healthcare and finance), an additional privacy-preserving computation module (including federated learning and secure multi-party computation technologies) ensures that the data is "usable but not visible," avoiding compliance risks during the original data transmission process and ensuring that the data application scenarios and uses comply with public order and good morals and industry regulatory requirements.

[0153] Data governance norms: A complete data traceability system is established during the AI ​​model training process to automatically record the source, collection time, annotation process, cleaning rules, and permission allocation of training data, generating traceable compliance reports to ensure that the data is verifiable throughout its entire lifecycle. The dataset annotation process for AI models is completed by a professional human R&D team, clearly defining the proportion of human creative contributions and avoiding reliance on AI-generated data that has not undergone substantial human modification, thus meeting the examination requirements for "human main contributions" in AI patent applications.

[0154] Training objectives and plans are compliant: The training objective of the AI ​​model focuses on multimodal information interaction. The training scheme and the final output results do not violate any mandatory provisions of laws and administrative regulations, do not harm the public interest or the legitimate rights and interests of others, and do not pose any potential risks of being used for illegal activities, infringing on privacy, or undermining public safety. The model strictly adheres to the ethical principle of "intelligent for good".

[0155] Training process compliance: A closed-loop training framework is adopted to ensure compliance and controllability of the training process. The specific process is as follows: First, training samples are obtained through compliant data sources. After the aforementioned data cleaning and desensitization, they are input into the neural network model to generate preliminary training results. Second, an expert system is introduced to verify the preliminary results. Based on preset rules and human expert experience, the feasibility of the results is evaluated, and outputs that may pose ethical risks or compliance hazards are corrected (such as removing decision-making logic that violates public order and good morals, and adjusting model parameters that do not comply with safety regulations). Finally, the loss function weights are dynamically optimized based on expert system feedback to strengthen the model's learning of compliant results, avoid overfitting errors or non-compliant labels, and form a closed-loop control of "data input - model training - expert verification - parameter optimization - result feedback" to ensure that the entire training process complies with A5 ethical review requirements.

[0156] Training environment and tool compliance: AI model training is implemented using nationally licensed chips and a compliant training platform. All open-source frameworks and components used in the training process have obtained their corresponding licenses, and copyright statements and patent citation information are fully retained, with no instances of infringement or reuse. The training environment is built using virtual devices (containers / virtual machines) with fixed random seeds and initial parameter configurations to ensure the reproducibility of the training process. Furthermore, through access control and operation log recording, risks such as data leakage and parameter tampering during training are prevented, ensuring the security and compliance of the training process.

[0157] Training results ethical verification compliance: After the model is trained, it undergoes additional third-party ethical compliance assessment and algorithm filing review to verify that the model output does not violate social morality or harm public interests. For potentially sensitive scenarios (such as public services and intelligent decision-making), a special result verification mechanism is established to ensure that the model always complies with Article 5 of the Patent Law and relevant laws and regulations in practical applications.

[0158] In summary, the data and training process used in the AI ​​model of this specification strictly comply with the relevant provisions of Article 5 of the Patent Law and the Patent Examination Guidelines (2023 Edition), and there are no violations of laws, social ethics, public interests, or illegal use of genetic resources. It fully meets the compliance requirements for patent authorization.

[0159] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0160] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A task execution method, characterized in that, include: In response to receiving a target task, an initial task evolution framework corresponding to the target task is determined; the initial task evolution framework is generated based on a preset visualization structure, wherein the initial task evolution framework includes multiple nodes, and the multiple nodes correspond to each stage of the task evolution process from task input to task execution completion; Based on the task execution data of each stage of the task evolution, the metadata of the corresponding nodes in the initial task evolution framework is updated to obtain a complete task evolution framework for the task execution of each stage after the target task is completed. The metadata of each node in the initial task evolution framework is used to carry the task execution data of the corresponding stage of the task evolution.

2. The method according to claim 1, characterized in that, The updating of metadata for corresponding nodes in the initial task evolution framework based on task execution data from each stage of the task evolution includes: For each stage of the task evolution, based on the task execution data of the stage, the target node in the initial task evolution framework corresponding to the stage is expanded with child nodes to obtain the child nodes of the target node. The child nodes have an associated and cooperative relationship with the target node, and the sub-stages corresponding to the child nodes are used to assist the corresponding stage of the target node in executing the task of this stage. The metadata of the target node and the metadata of the target node's child nodes are updated based on the task execution data of the aforementioned stage.

3. The method according to claim 1, characterized in that, The task execution data includes at least one of the following: data source information and execution result information, wherein the data source information indicates the basis for task execution at each stage, and the execution result information indicates the task execution status at each stage.

4. The method according to claim 3, characterized in that, The attributes of the data source information include at least one of the following: evidence attribute, rule attribute, graph attribute, and historical attribute; the evidence attribute indicates the input data and data source of each stage, the rule attribute indicates the constraint rules for security and compliance, the graph attribute indicates the knowledge graph, and the historical attribute indicates historical case experience data. The execution result information includes at least one of the following: stage execution process information, stage execution result, related evidence matching result, and execution effect quantification result, wherein the stage execution process information indicates at least one of the intermediate process data of task execution and human-machine collaborative processing result; the stage execution result indicates at least one of the stage task execution completion, stage task execution failure, or stage task execution replacement scheme; the related evidence matching result indicates the correlation between the stage execution result and the data source information; the execution effect quantification result indicates at least one of the stage simulation result, confidence assessment result, accuracy calculation result, risk assessment result, and conflict detection result.

5. The method according to claim 1, characterized in that, Each stage of the task evolution includes at least a solution generation stage, which in turn includes at least a verification stage and a decision-making stage; wherein; The verification step is used to verify the feature data of the target task based on the target verification dimension to obtain the verification result. The target verification dimension includes at least one of confidence level and risk level. The task execution data of the verification step includes at least the verification basis data related to the target verification dimension and the verification result. The decision-making process is used to select a human-machine collaboration mode based on the verification results, so as to obtain a target execution plan through the selected human-machine collaboration mode. In this process of obtaining the target execution plan, the interaction between the intelligent agent and the target object is different in different human-machine collaboration modes. The task execution data of the decision-making process includes at least the human-machine collaboration mode and the target execution plan.

6. The method according to claim 5, characterized in that, In the decision-making process, if the verification result meets the preset conditions, the human-machine collaboration mode selects the first human-machine collaboration mode; wherein, the process of obtaining the target execution plan in the first human-machine collaboration mode includes: the intelligent agent generating candidate plans for the target task, and the target object reviewing and adjusting the candidate plans to determine the target execution plan; In the decision-making process, if the verification result does not meet the preset conditions, the human-machine collaboration mode selects a second human-machine collaboration mode. In the second human-machine collaboration mode, the process of obtaining the target execution plan includes: the agent iteratively generating the target execution plan based on the dialogue-based interaction content between the agent and the target object.

7. The method according to claim 1, characterized in that, The updating of metadata for corresponding nodes in the initial task evolution framework based on task execution data from each stage of the task evolution includes: For each stage of the task evolution process, the feasibility of execution of this stage is verified based on the task execution data of the stage. After the verification is passed, the metadata of the node corresponding to the stage in the initial task evolution framework is updated based on the task execution data of the stage. The feasibility verification includes at least one of the reliability of the execution basis and the controllability of execution risk.

8. The method according to claim 1, characterized in that, The complete task evolution framework for obtaining the task execution of each stage after the completion of the target task includes: Determine whether the execution result of the target task in the task execution stage meets the preset requirements, wherein the task execution stage is one of the stages in the task evolution; In response to the execution result satisfying the preset requirements, the execution of the target task is determined to be completed, and the current task evolution framework is determined as the complete task evolution framework.

9. The method according to claim 8, characterized in that, After determining whether the execution result of the target task in the task execution phase meets the preset requirements, the process includes: In response to the execution result not meeting the preset requirements, the task evolution framework obtained from the process of the target task from task input to the task execution stage is rolled back to the rollback target stage that caused the failure to meet the preset requirements. The steps include adjusting the execution parameters of the rollback target stage, re-executing each stage of the task evolution from the rollback target stage to the end of the task execution, switching to executing the task execution data based on each stage of the task evolution, and updating the metadata of the corresponding nodes in the initial task evolution framework.

10. The method according to claim 1, characterized in that, After obtaining the complete task evolution framework, the method further includes: updating the initial task evolution framework corresponding to the target task to the complete task evolution framework.

11. The method according to claim 1, characterized in that, Each stage of the task evolution includes at least one of the following stages: scheme generation, scheme orchestration, and scheme execution. The scheme generation stage includes generating a target execution scheme for the target task based on input data associated with the target task. The scheme orchestration stage includes splitting and orchestrating the target execution scheme to obtain multiple sub-task execution schemes. The scheme execution stage includes executing the sub-task execution schemes.

12. The method according to claim 11, characterized in that, Each stage of the task evolution is executed collaboratively by the control-side agent and multiple autonomous domain execution agents, wherein: The control-side agent is deployed in the global control layer. The control-side agent is used to execute the scheme generation stage and the scheme orchestration stage, and to allocate the sub-task execution scheme to the corresponding autonomous domain execution agent. The multiple autonomous domain execution agents are deployed in their respective business autonomous domains. The autonomous domain execution agents are used to execute the solution execution steps within their respective domains and update the metadata of the corresponding nodes in the initial task evolution framework based on the task execution data of the solution execution steps within their respective domains.

13. The method according to claim 1, characterized in that, The preset visualization structure is a directed graph structure. The nodes of the directed graph are used to indicate each node of the initial task evolution framework. The nodes of the directed graph have node attributes, which are used to record the metadata of the corresponding node in the initial task evolution framework. The nodes of the directed graph are connected by directed edges, which are used to mark the association relationship between connected nodes in the directed graph.

14. An electronic device comprising a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement the steps of the task execution method as claimed in any one of claims 1 to 13.

15. A computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform the steps of the task execution method as described in any one of claims 1 to 13.

Images