Task execution method for an agent, agent, device, medium and product

Abstract

The application provides a task execution method for an agent, an agent, a device, a medium and a product, wherein the task execution method for the agent comprises: in response to receiving an evidence task package, generating an original plan based on the evidence task package and a corresponding formal constraint specification, and compiling the original plan into a structured execution plan; performing static verification on the structured execution plan based on the formal constraint specification; after the static verification is passed, scheduling the execution of the structured execution plan; recording evidence information during the execution of the structured execution plan, and outputting a task execution result comprising the evidence information. The above scheme defines a decision boundary through the formal constraint specification, cooperates with the compiled structured execution plan and the pre-execution verification mechanism, converts the agent from an open free reasoning mode to a constrained verifiable execution mode, improves the flexibility of task execution, and ensures that the execution process conforms to the predetermined safety policy.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing technology, and more specifically, to a task execution method, intelligent agent, device, medium, and product for an intelligent agent. Background Technology

[0002] With the rapid development of large language model technology, intelligent agent systems based on large language models have become important tools for handling complex tasks. Existing intelligent agent systems generally adopt an open architecture of large language models, tool invocation, and result return. The large language model autonomously infers based on the evidence task package and dynamically generates tool invocation sequences, then schedules external tools or databases to complete sub-tasks. Such systems emphasize flexibility and versatility; their execution plans are typically in the form of natural language descriptions or semi-structured data, and are dynamically adjusted during execution based on the model's own contextual understanding capabilities.

[0003] However, existing agent systems lack formal constraints and verifiable mechanisms in the decision-making and execution phases. Because the model autonomously decides tool invocation, parameter selection, and data access based on natural language context, the lack of mandatory formal constraints on tool whitelists, parameter value ranges, data access permissions, and execution dependencies prevents the agent from effectively verifying the compliance of the plan before execution. This ambiguity in decision boundaries exposes the agent to risks of unauthorized tool invocation, use of parameters exceeding security boundaries, and access to restricted data. Furthermore, the lack of explicit, structured execution representation makes static verification before execution impossible and step-by-step auditing and traceability difficult, resulting in an unauditable execution process and untraceable, unacceptable results. Summary of the Invention

[0004] The purpose of this application is to provide a task execution method, intelligent agent, device, medium, and product for an intelligent agent, so as to solve the above-mentioned problems.

[0005] In a first aspect, embodiments of this application provide a task execution method for an intelligent agent, the method comprising: in response to receiving an evidence task package, generating an original plan based on the evidence task package and its corresponding formal constraint specification, and compiling the original plan into a structured execution plan; wherein the structured execution plan includes explicit execution nodes and dependencies between nodes; performing static verification on the structured execution plan based on the formal constraint specification; scheduling the execution of the structured execution plan after the static verification passes; wherein the structured execution plan is driven by evidence information encapsulated in the evidence task package; recording evidence information during the execution of the structured execution plan, and outputting a task execution result including the evidence information.

[0006] In the implementation of the above scheme, formal constraint specifications are used to limit the decision boundary. Combined with a compiled structured execution plan and a pre-execution verification mechanism, the agent is transformed from an open, free reasoning mode into a constrained, verifiable execution mode. This improves the flexibility of task execution while ensuring that the execution process conforms to predetermined security policies. On the other hand, formal constraint specifications are used to perform static pre-execution verification of the structured execution plan. Before the actual task execution, the legality of tool calls, the compliance of parameter ranges, and data access permissions are forcibly checked. Only after verification is the execution phase allowed, thus blocking unauthorized calls and illegal parameter configurations at the source. Furthermore, by compiling the original plan into a structured execution plan containing explicit execution nodes and dependencies between nodes, the execution logic is transformed from an implicit reasoning process into an explicit data flow and control flow structure. Combined with the recording of evidence information during execution, this forms an engineered execution object that is inspectable, replayable, and auditable. Finally, by incorporating the evidence information recorded during execution into the task execution results, the output results are upgraded from isolated conclusion texts to traceable objects with execution paths and evidence chains, facilitating subsequent review, acceptance, and accountability of the conclusions.

[0007] In one implementation of the first aspect, the method further includes: obtaining the formal constraint specification corresponding to the evidence task package; wherein the formal constraint specification includes at least one of a tool whitelist, inter-tool dependency topology, parameter value range, data access permission, and output contract requirements; the output contract requirements include constraint definitions on the structure, fields, and data types of the task execution results, as well as matching constraints on the input and output data formats between execution nodes; the output contract requirements are used to limit the form of results that the structured execution plan needs to generate after execution.

[0008] In the implementation of the above scheme, a multi-dimensional formal constraint specification is constructed, including a tool whitelist, dependency topology, parameter value range, data access permission, and output contract requirements. This specification provides a three-dimensional boundary limit for the agent's tool selection, execution timing, parameter configuration, data access, and result format, compressing the possibility space of unauthorized operations from the input source. On the other hand, the tool whitelist limits the set of callable tools to prevent unauthorized calls, the dependency topology specification constrains the execution timing to avoid logical errors, the parameter value range limits the legality of input to block illegal configurations, the data access permission controls resource boundaries to prevent data overreach, and the output contract requirements ensure the integrity of result fields to ensure downstream compatibility. This ensures that the entire task execution process is within a predictable constraint framework.

[0009] In one implementation of the first aspect, the static verification of the structured execution plan based on the formal constraint specification includes: performing at least one of the following static verifications on the structured execution plan based on the formal constraint specification: tool validity verification, dependency topology verification, data permission verification, parameter validity verification, output contract satisfiability verification, and evidence generation capability verification; when the static verification fails, the structured execution plan is rejected for execution, and the structured execution plan is modified based on the verification failure result to ensure that the structured execution plan satisfies the formal constraint specification; wherein, the modification includes at least one of adjusting execution node parameters, reselecting tools, and adjusting inter-node dependencies; and the modified structured execution plan is statically verified again.

[0010] In implementing the above scheme, a multi-dimensional static verification is constructed, encompassing tool legitimacy, dependency topology, data permissions, parameter legitimacy, output contract satisfiability, and evidence generation capabilities. This is coupled with an automatic correction and re-verification mechanism after failure. This establishes a closed-loop pre-execution access control system covering all elements after plan compilation, ensuring that the structured execution plan entering the scheduling and execution phase strictly conforms to the behavioral boundaries defined by formal constraint specifications. Furthermore, through tool legitimacy and data permission verification, unauthorized tool calls and unauthorized data access requests are identified and blocked before execution, restricting agent operations to a preset whitelist and permission range, preventing untraceable analysis conclusions due to unauthorized calls or data contamination. Finally, by automatically triggering execution node parameter adjustments, tool reselection, or dependency reconstruction when static verification fails, and re-executing static verification on the corrected plan, automated repair and iterative optimization of plan defects are achieved, reducing manual intervention and task interruptions caused by plan violations.

[0011] In one implementation of the first aspect, compiling the original plan into a structured execution plan includes: parsing the original plan and extracting atomic operations and corresponding parameter information; wherein the original plan is an unstructured or semi-structured plan; constructing the explicit execution nodes based on the atomic operations, and determining the input data, output data, and parameter information of each explicit execution node; establishing the inter-node dependencies based on the data dependencies and control flow relationships between the explicit execution nodes, generating a directed acyclic graph representation with the explicit execution nodes as vertices and the inter-node dependencies as edges, and converting the original plan into a graph-structured structured execution plan.

[0012] In the implementation of the above scheme, atomic operations and corresponding parameter information are extracted by parsing the original plan. Explicit execution nodes containing input data, output data, and parameter information are constructed based on the atomic operations. Then, inter-node dependencies are established based on the data dependencies and control flow relationships between nodes, transforming the unstructured original plan into a structured execution plan with explicit nodes and connections. This transforms implicit reasoning intentions into explicit engineering execution structures. On the other hand, the explicit execution nodes encapsulate the atomic operation logic and data flow, and, in conjunction with the inter-node dependencies, characterize the execution sequence and control branches, forming a parsable, traversable, and verifiable graph structure representation. This provides a formal check object for static verification before execution and provides fine-grained anchor points for step tracing and evidence binding during execution. Furthermore, by transforming natural language or semi-structured descriptions into structured representations containing data flow and control flow, execution uncertainties caused by ambiguity or misunderstanding in the original plan are eliminated, improving the consistency of the execution plan's reconstruction in different operating environments and its reproducibility across versions.

[0013] In one implementation of the first aspect, recording evidence information during the execution of the structured execution plan includes: generating a corresponding evidence object for the explicit execution node and establishing a binding relationship between the explicit execution node and the evidence object; wherein the evidence object includes at least one of operation identifier, input / output summary, parameter summary, tool version, timestamp, and data source reference.

[0014] In the implementation of the above scheme, corresponding evidence objects are generated for explicit execution nodes, and a binding relationship is established between explicit execution nodes and evidence objects. This accurately maps the operation traces during the execution process to the specific execution steps in the structured execution plan, forming a step-level execution genealogy record. On the other hand, evidence objects are used to capture multi-dimensional execution metadata such as operation identifiers, input / output summaries, parameter summaries, tool versions, timestamps, and data source references, so that each execution step has an independently verifiable operation context and data traceability capability. Furthermore, a node-level evidence binding mechanism replaces the traditional coarse-grained log recording, realizing a two-layer mapping between the execution structure and the evidence structure, providing fine-grained technical basis for audit traceability, problem localization, and result acceptance of the execution process.

[0015] In one implementation of the first aspect, the evidence task package includes a defect review evidence task package for a defect review task in the semiconductor manufacturing process; The method further includes: generating a defect reassessment evidence task package; wherein the defect reassessment evidence task package includes an image of the region of interest of the defect to be reassessed, a partial fragment of the wafer image, a layout window summary, a process log time window and a fragment of process recipe parameters, as well as candidate labels and confidence information.

[0016] In the implementation of the above scheme, a dedicated evidence task package for semiconductor defect review scenarios is constructed. This package encapsulates the region of interest image of the defect to be reviewed, local fragments of the wafer map, layout window summary, process log time window, and process recipe parameter fragments in a structured manner, forming a unified multi-source data context. This ensures that the review task has a complete evidentiary basis and is executable. On the other hand, the defect review evidence task package integrates defect visual features, process environment parameters, and spatial location information. Combined with the candidate labels and confidence information output by the model, it provides a panoramic judgment basis for manual review, reducing the review bias caused by information fragmentation.

[0017] In one implementation of the first aspect, the method further includes: before generating the original plan, actively sampling multiple candidate defect tasks to be reviewed based on a multi-objective utility function to determine the defect review task; wherein the multi-objective utility function includes: an uncertainty term for quantifying the degree of prediction uncertainty, a sample diversity term for quantifying the difference in feature space distribution between candidate samples and selected samples, a new class sensitivity term for quantifying the degree of deviation between candidate samples and known defect category distribution, and a review cost term for quantifying the time required for evidence acquisition and manual review; generating the defect review evidence task package based on the defect review task, and using the defect review evidence task package as the evidence task package to trigger the generation of the original plan and the compilation of the structured execution plan.

[0018] In the implementation of the above scheme, a multi-objective utility function is constructed that integrates uncertainty terms, sample diversity terms, novelty sensitivity terms, and re-judgment cost terms. Before generating the original plan, candidate defect tasks are actively sampled, and the sample selection strategy is optimized under the constraint of limited annotation budget, balancing the resource allocation between mining difficult examples of known categories and exploring potential new categories. On the other hand, the uncertainty term is used to prioritize screening the model to predict candidate defects with low confidence. The sample diversity term is combined to expand the coverage of process conditions and defect types. The novelty sensitivity term is used to identify abnormal samples that deviate from the distribution of known categories. The re-judgment cost term is used to constrain the cost of evidence acquisition and the time for manual review, thereby improving the model gain per unit of annotation resources. Furthermore, through multi-objective utility evaluation, re-judgment resources are transferred from a large number of high-confidence known defects to marginal samples and suspected new categories with high information gain, alleviating the human resource bottleneck in defect distribution drift scenarios and enhancing the model's ability to discover unknown defect patterns.

[0019] In one implementation of the first aspect, the method further includes: dynamically adjusting the weight of the new type of sensitivity item based on the recent new type of defect discovery rate, abnormal sample hit rate, or budget constraint status; wherein, when the weight update condition is met, the weight of the new type of sensitivity item is increased; the weight update condition includes the new type of defect discovery rate being lower than a preset threshold, or the abnormal sample hit rate being higher than a threshold, or at least one of the following changes occurring: process batch, machine, formula version, and layer; when the abnormal sample hit rate is lower than the threshold and the budget is tight, the weight of the new type of sensitivity item is decreased, and a step-by-step update method is adopted to limit the weight fluctuation range.

[0020] In the implementation of the above scheme, the weight of the new class sensitivity item is dynamically adjusted based on the recent new class defect discovery rate, abnormal sample hit rate, and budget constraint status. This allows the active sampling strategy to adaptively optimize based on the actual new class discovery efficiency and resource pressure, balancing the exploration intensity of unknown defect patterns with labeling cost control. On the other hand, by utilizing the mechanism of increasing the weight when the new class defect discovery rate is lower than a preset threshold or the abnormal sample hit rate is higher than the threshold, the focus on out-of-distribution samples is enhanced during periods of scarcity of potential new classes or when anomaly judgment is effective. This is combined with the weight increase under process batch, machine, formula version, and layer switching scenarios to quickly respond to defect distribution drift caused by changes in production line conditions. Furthermore, by reducing the weight when the abnormal sample hit rate is lower than the threshold and the budget becomes tight, and by using a step-by-step update method to limit the range of weight fluctuations, the limited re-judgment resources are avoided from being continuously consumed on low-yield abnormal samples, while preventing sampling strategy oscillations caused by drastic weight adjustments.

[0021] In one implementation of the first aspect, when executing the structured execution plan, the method further includes: modeling the manual review operation as an explicit execution node and incorporating it into the node dependency relationship of the structured execution plan for unified scheduling; wherein, the explicit execution node includes an automatic processing node and a manual review node; the manual review node is triggered, allocated, and verifies the results based on the formal constraint specification, and selects between a single-person review mode, a dual-person independent review mode, and an expert arbitration mode according to a preset collaborative strategy; the manual review node generates a corresponding evidence object during execution and establishes a binding relationship with the nodes in the structured execution plan.

[0022] In the implementation of the above scheme, by modeling manual review operations as explicit execution nodes and incorporating them into the node dependencies of the structured execution plan, a unified graph structured execution framework covering automatic processing and manual review is constructed. This allows manual intervention to be controlled and scheduled under the same formal constraints, achieving full-link programmability and auditability for human-machine collaborative tasks. On the other hand, during execution, the manual review nodes generate corresponding evidence objects and establish binding relationships with nodes in the structured execution plan, ensuring that the timestamps of manual operations, decision-making basis, and conclusion changes are solidified into traceable evidence units and incorporated into the overall evidence chain for integrity verification. Furthermore, the manual review nodes are triggered, allocated, and result verified based on formal constraints, and select between single-person review mode, dual-person independent review mode, and expert arbitration mode according to preset collaborative strategies. This ensures that the resource allocation and quality control strategies for manual review are constrained by task specifications, avoiding unfounded reasoning and unauthorized decision-making.

[0023] In one implementation of the first aspect, the method further includes: incrementally updating at least one of the training sample set, the difficult example sample pool, and the unknown class candidate set according to the review conclusion of the defect review task, and updating the model parameters, classification threshold, and rule base accordingly, and adjusting the parameter value range in the formal constraint specification based on the updated classification threshold.

[0024] In the implementation of the above scheme, a complete feedback loop is constructed from the review conclusion to data assets, model parameters, and constraint specifications. This transforms the wisdom of manual review into iterative engineering assets, forming a continuous evolution mechanism driven by both data and rules. On the other hand, by incrementally updating the training sample set, the difficult example sample pool, and the unknown class candidate set, the manually verified review conclusions are solidified into structured data assets, strengthening the model's ability to recognize difficult patterns and potential new classes. Furthermore, by adjusting the parameter value range in the formal constraint specifications based on the updated classification threshold, the front-end execution constraints and the back-end model capabilities are dynamically adapted, ensuring that the constraint boundaries always reflect the current optimal judgment criteria.

[0025] Secondly, embodiments of this application provide an intelligent agent, including: The plan generation and compilation module is used to generate an original plan based on the evidence task package and its corresponding formal constraint specification in response to receiving the evidence task package, and compile the original plan into a structured execution plan; wherein, the structured execution plan includes explicit execution nodes and dependencies between nodes; The static verification module is used to perform static verification on the structured execution plan based on the formal constraint specification. An execution scheduling module is used to schedule the execution of the structured execution plan after the static verification is passed; wherein, the structured execution plan is driven by the evidence information encapsulated in the evidence task package; The evidence recording and result output module is used to record evidence information when executing the structured execution plan and output the task execution result including the evidence information.

[0026] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a communication bus, wherein the processor and the memory communicate with each other through the communication bus; the memory stores computer program instructions that can be executed by the processor, and the computer program instructions are read and executed by the processor to perform the method provided in the first aspect or any possible implementation of the first aspect.

[0027] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when read and executed by a processor, perform the method provided in the first aspect or any possible implementation thereof.

[0028] Fifthly, embodiments of this application provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the method provided by the first aspect or any possible implementation of the first aspect.

[0029] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims and drawings. Attached Figure Description

[0030] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1 A flowchart illustrating a task execution method for an intelligent agent provided in an embodiment of this application; Figure 2 This is a schematic diagram of the architecture of the intelligent agent provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0032] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0033] An intelligent agent is an autonomous task execution entity based on a large language model. By integrating natural language understanding, logical reasoning, and tool invocation orchestration capabilities, it can receive user task input and autonomously decompose it into a sequence of executable sub-tasks. Based on task context, historical session states, and preset prompts, the intelligent agent autonomously decides the necessity, execution order, and parameter configuration of external tool invocations. It interacts with external tools, knowledge bases, and data sources through function calls, application programming interface requests, or database queries, and integrates intermediate results from each step to generate the final task output. During execution, the intelligent agent possesses multiple functions, including task understanding, scheduling decisions, and result integration. Its generated execution plan is typically represented in natural language description or semi-structured data form and can be dynamically adjusted based on intermediate execution feedback, forming a closed-loop processing flow from task input to result delivery.

[0034] Currently, general-purpose intelligent agent tool invocation schemes based on large language models typically employ an open execution architecture. The large language model autonomously infers based on user input, contextual prompts, and historical conversations, dynamically generating tool invocation sequences and adjusting execution strategies in real time. In these schemes, the model undertakes both task understanding and scheduling decisions and result integration. The tool invocation order, parameter configuration, and data access scope are all determined by the model during execution, expressing the execution intent in natural language or semi-structured JSON. However, because these schemes lack mandatory formal constraints on tool sets, dependency topologies, parameter value ranges, and data permissions, the intelligent agent may invoke unauthorized tools, use parameter combinations exceeding security boundaries, or access restricted data sources without necessary verification. This results in unauthorized invocations and illegal parameter configurations failing to be identified and blocked before execution. Furthermore, the execution plan exists in implicit natural language or temporary function call chains, lacking an explicit structured execution representation. This makes it difficult for formal verification tools to parse and validate the execution logic, and also prevents the establishment of fine-grained step-level audit traceability relationships.

[0035] Fixed-process solutions based on workflow engines or rule engines typically predefine task processing templates, decomposing tasks into a sequence of modules to be executed in a fixed order through process orchestration, or triggering specific processing branches based on rule matching. While such solutions offer a degree of process controllability, their rigidity makes them ill-suited for complex task scenarios requiring dynamic reasoning and conditional branch adjustments. Furthermore, the plans in these solutions are not autonomously generated by the agent based on the task context, but rather rely on manually preset fixed paths. This lacks a unified formal description mechanism for complex conditional branches, parameter value ranges, data permission boundaries, and output contracts, resulting in a tradeoff between flexibility and verifiability within the same technical framework. It fails to fully leverage the autonomous reasoning advantages of large language models while also lacking rigorous pre-execution verification capabilities.

[0036] Furthermore, existing logging and auditing solutions typically capture and store runtime logs after task execution, recording tool call timestamps, input / output data summaries, error messages, and version identifiers. Some solutions extend this to include call chain tracing and runtime environment logging. While these solutions can improve post-event traceability to some extent, they are essentially post-event supplementary logging models. They do not formally constrain the agent's decision space before execution, nor do they compile the execution process into a verifiable, structured execution representation. Therefore, when the agent executes unauthorized calls, uses illegal parameters, or outputs conclusions without necessary evidence, these solutions can only discover the problem through log backtracking after the violation occurs. They cannot prevent non-compliant operations at the source during the decision-making or pre-execution stages, resulting in a time lag in risk control. The cost of erroneous execution has already entered the runtime process and cannot be reversed.

[0037] In view of this, embodiments of this application provide a task execution method for an intelligent agent. This method limits the decision boundary through formal constraint specifications, and, in conjunction with a compiled structured execution plan and a pre-execution verification mechanism, transforms the intelligent agent from an open free reasoning mode to a constrained verifiable execution mode. This improves the flexibility of task execution while ensuring that the execution process complies with predetermined security policies. On the other hand, formal constraint specifications are used to perform static verification of the structured execution plan before execution. Before the actual execution of the task, mandatory checks are performed on the legality of tool calls, the compliance of parameter ranges, and data access permissions. Execution is only allowed after the verification passes. This process involves several steps: firstly, blocking unauthorized calls and illegal parameter configurations at the source; secondly, compiling the original plan into a structured execution plan containing explicit execution nodes and dependencies between nodes, transforming the execution logic from an implicit reasoning process into an explicit data flow and control flow structure, and combining this with the recording of evidence information during execution to form an engineered execution object that is inspectable, replayable, and auditable; and thirdly, incorporating evidence information recorded during execution into the task execution results, upgrading the output results from isolated conclusion texts to traceable objects with execution paths and evidence chains, facilitating subsequent review, acceptance, and accountability of the conclusion basis.

[0038] The application scenarios of the task execution method for intelligent agents provided in this application include, but are not limited to: (1) Application in defect review scenarios in the semiconductor manufacturing field; In this application scenario, the intelligent agent receives defect review tasks from the production line, generates and compiles a structured execution plan based on formal constraint specifications, and ensures through static verification that the review process only calls authorized defect detection tools and accesses process data of specific layers and machines. After verification, it performs defect classification and layout alignment operations. The evidence information recorded during the execution process, together with the review conclusion, constitutes the defect review evidence task package, forming a complete evidence chain from defect signal acquisition to manual review, meeting the technical requirements of the semiconductor manufacturing industry for auditable defect judgment processes, traceable results, and traceable responsibility.

[0039] (2) Execution scenarios of general complex task intelligent agents; In such scenarios, the agent, based on the evidence task package and predefined formal constraints, compiles the original plan described in natural language into a structured execution plan containing explicit execution nodes and dependencies. Pre-execution static verification checks the legality of tool calls, the compliance of parameter ranges, and data access permissions to prevent unauthorized calls or illegal parameter configurations during open-domain inference. The node-level evidence binding relationships established during execution ensure that each tool call step has an independent operational context record. The final task execution result includes complete evidence citations and execution path information, facilitating auditability of the execution process and acceptance of results in general task processing scenarios.

[0040] (3) Applied to high-risk decision-making scenarios such as financial risk control analysis, medical diagnosis assistance, and industrial quality inspection; In these scenarios, formal constraint specifications can limit the agent to calling only specific risk assessment models or medical knowledge base interfaces, static verification mechanisms ensure that the analysis parameters meet the value ranges specified by regulatory requirements or clinical guidelines, and the evidence recording function captures the input data version, parameter configuration and intermediate output of each model inference, forming a complete technical file that can be reviewed by regulatory agencies or quality management departments. This enables the controllability and verifiability of the agent's execution process in industries that require strict compliance control and audit traceability.

[0041] Please see Figure 1 The illustrated flowchart shows a task execution method for an intelligent agent provided in an embodiment of this application. The task execution method for an intelligent agent provided in this application can be applied to electronic devices, which may include physical devices such as servers, PCs, tablets, or smartphones, or virtual devices such as virtual machines or containers. The electronic device can be a single device, a combination of multiple devices, or a cluster of a large number of devices. The aforementioned task execution method for an intelligent agent may include: Step S110: In response to receiving the evidence task package, generate an original plan based on the evidence task package and its corresponding formal constraint specifications, and compile the original plan into a structured execution plan; wherein, the structured execution plan includes explicit execution nodes and dependencies between nodes.

[0042] The aforementioned evidence task package can be the evidence task package corresponding to a user task. User tasks typically take the form of natural language text or structured data packets, and their content includes a description of the task objective, input data identifiers, and expected output requirements. In general task processing scenarios, user tasks are presented as descriptive instructions, submitted to the agent by the user through application programming interfaces (APIs) or interactive interfaces. In specific industrial scenarios such as semiconductor manufacturing, user tasks can be further instantiated into defect review requests, whose data structures can encapsulate a unique identifier for the defect to be processed, pointers to acquired image data, associated process parameters, and priority markers.

[0043] The aforementioned formal constraint specification is a predefined, machine-parseable set of structured constraints. It uses strict logical semantics to define the decision boundaries and permissible behavioral ranges of an agent during task execution. Through formal data structures, it explicitly encodes execution elements such as tool call permissions, execution timing dependencies, parameter value ranges, data access scope, and output format requirements, enabling them to be directly read, parsed, and verified by the compiler and verifier. As a pre-defined set of rules independent of specific task inputs, the formal constraint specification serves as a contextual reference during the initial plan generation phase, a basis for structural transformation during the compilation phase, and a mandatory criterion for determining the compliance of the execution plan during the static verification phase. This constrains the agent's open, autonomous decision-making within a verifiable, auditable, and safe operating space.

[0044] Optionally, the above-mentioned task execution method for intelligent agents further includes: obtaining formal constraint specifications corresponding to the evidence task package; wherein, the formal constraint specifications include at least one of tool whitelist, tool dependency topology, parameter value range, data access permission and output contract requirements; the output contract requirements include constraint definitions on the structure, fields and data types of the task execution results and matching constraints on the input and output data formats between execution nodes; the output contract requirements are used to limit the form of results that the structured execution plan needs to generate after execution.

[0045] The aforementioned tool whitelist is a predefined set in the formal constraint specification used to limit the scope of tools that an agent can call. It explicitly enumerates the tools, models, algorithm modules, and database interface identifiers authorized for use in specific task scenarios. By defining the boundaries of legal operations through a positive authorization list, it prevents agents from calling unauthorized or potentially dangerous external functional units. During task execution, the tool whitelist can be obtained along with the constraint specification corresponding to the user task. It can be retrieved from a pre-built configuration library or rule database by parsing the task type identifier, or extracted from the top-level structure of the formal constraint specification and loaded into the verification context by the task receiving module based on task attributes. The tool whitelist can be persistently stored in various machine-parseable structured formats, including but not limited to JSON Schema files describing tool identifiers and permission states in key-value pairs, YAML configuration files defining tool classification and inheritance relationships in a hierarchical structure, tool permission matrices maintained by relational database tables or key-value storage systems, constraint rule text described in domain-specific languages, and tool authorization semantic networks built based on ontology or knowledge graphs. This ensures that the constraint specification can be uniformly read and parsed by the compiler and verifier in different runtime environments.

[0046] The aforementioned inter-tool dependency topology is a structured description in formal constraint specifications used to define the execution timing and logical dependencies between explicit execution nodes. It defines the sequential execution constraints, parallel permissions, and conditional branch paths between tool modules through directed graphs or adjacency lists. It clearly identifies the data flow direction where the output of a preceding tool becomes the input of a subsequent tool, and includes control logic such as mandatory sequential execution, mutually exclusive execution, or synchronous aggregation, thereby preventing logical errors such as skipping steps, reversing order, or illegal parallelism during execution. The inter-tool dependency topology can be obtained by: loading the corresponding dependency definition from a pre-set constraint template library or workflow orchestration database by parsing the task type identifier; or by the task receiving module dynamically retrieving and instantiating it based on process recipes, business rules, or historical execution patterns. At the storage implementation level, the inter-tool dependency topology can be persisted in various structured forms, including directed acyclic graph structures described by node-edge relationships, JSON / YAML configuration files encoded by adjacency lists or association matrices, relational database table structures maintained by primary key-foreign key relationships, state machine definition files described by state transition rules, and process definition documents formalized based on Petri nets or workflow description languages. This allows the compiler to parse execution order constraints into inter-node dependencies in a structured execution plan and provides a traversable topology verification basis for the static verification module.

[0047] The aforementioned parameter value range is a technical constraint definition in the formal constraint specification used to limit the legal value space of parameters used by each execution node. It explicitly defines the numerical range, enumeration set, data type, regular expression pattern, and safety boundary for the input parameters of each tool, specifying the minimum and maximum values ​​of thresholds, discrete optional values, string format patterns, or mandatory and optional fields for structured data fields. This prevents out-of-bounds parameters, illegal types, and dangerous configurations from entering the runtime phase before execution. The parameter value range can be obtained by parsing specific tool identifiers or task category codes to retrieve corresponding legal value templates from parameter configuration libraries, rule engine storage, or policy databases. Alternatively, it can be obtained by dynamically loading adapted parameter boundary definitions based on the process recipe version or runtime environment. At the persistence implementation level, parameter value ranges can be stored in various machine-resolvable structured formats, including JSON or YAML configuration files that describe parameter names and range upper and lower bounds as key-value pairs, DSL domain-specific language scripts that define numerical range expressions or set enumerations, relational database entries stored as constraint tables or rule records, parameter type and format validation specifications described in XML Schema or JSON Schema, and data attribute restriction declarations based on ontology definitions, ensuring that the compiler and static validator can accurately parse the legal domains of each parameter and perform strict range checks during the validation phase.

[0048] The aforementioned data access permissions are technical constraints defined in formal constraint specifications to limit the range of data sources, data fields, and data anonymization rules that an agent can access during execution. They explicitly identify permitted database identifiers, data table sets, field whitelists, query condition restrictions, and sensitive information anonymization strategies, preventing agents from unauthorized access to restricted data sources, extraction of unauthorized fields, or leakage of sensitive privacy information. Data access permissions can be obtained by parsing task attributes or user identity identifiers to retrieve the corresponding authorization scope from the data governance platform's permission configuration center, data security policy library, or access control list storage. Alternatively, they can be dynamically loaded with adapted access policies based on a data hierarchical classification system. At the persistence implementation level, data access permissions can be stored in various structured formats, including JSON or YAML permission policy files described by role-resource-operation triples, relational database permission tables maintained in the form of access control lists or capability tables, declarative permission rules described in resource policy languages, and dynamic policy definitions based on attribute access control models. This ensures that the validator can perform rigorous compliance checks on data access operations during the static verification phase.

[0049] The aforementioned output contract requirements are formal constraint specifications used to define the form of results that a structured execution plan must generate after execution. They explicitly define the structure, fields, and data types of the task execution results, as well as the matching constraints on input and output data formats between execution nodes, ensuring that the agent's output conforms to the acceptance standards of downstream processing flows or manual review. Output contract requirements can be obtained by parsing the task type identifier or output target identifier and retrieving the corresponding format specification from a pre-built output template library, interface contract definition library, or data exchange standard library. Alternatively, they can be dynamically loaded based on business scenarios or recipient requirements. At the persistence implementation level, output contract requirements can be stored in various structured forms, including JSONSchema or YAML configuration files described by field name-type-constraint triples, interface contract files described by message format definition languages, relational database records maintained in the form of field mapping tables or structure templates, serialization format specifications defined by XML Schema or Protocol Buffers, and data attribute constraint declarations based on ontology definitions. This ensures that the compiler can verify whether the structured execution plan meets the output field generation requirements and that the verifier can check whether the execution path necessarily produces a result structure that conforms to the contract.

[0050] In a certain application scenario, the formal constraint specification is represented by a JSON data structure as follows: TaskSpec={tool_whitelist:[tool_A,tool_B,tool_C],dependency_graph:{tool_A:[],tool_B:[tool_A],tool_C:[tool_B]},data_permissions:{allowed_sources:[db_1,repo_2],masking_rule:pii_redaction},parameter_domains:{threshold:[0.6,0.95],tile_size:[256,512,1024]},output_contract:{required_fields:[result,confidence,evidence_refs]}}. In the formal constraint specification above, the `tool_whitelist` field is defined, whose value is a string array `[tool_A,tool_B,tool_C]`. This array explicitly limits the set of tool identifiers that the current task is allowed to call in an enumerated manner, containing only three types of tools: `tool_A`, `tool_B`, and `tool_C`. Any tool call outside this list is considered an unauthorized operation. This field compresses the agent's tool selection space through a positive whitelist mechanism, preventing unauthorized calls to unverified external functional modules. The `dependency_graph` field defines the execution dependency topology between tools in the form of nested objects, where the key represents the tool identifier and the value represents the list of tools that the tool depends on. Specifically, `tool_A` corresponds to an empty array `[]`, indicating that it has no dependencies and can be executed directly; `tool_B` corresponds to the array `[tool_A]`, indicating that it can only be started after `tool_A` has been executed; `tool_C` corresponds to the array `[tool_B]`, indicating that it depends on the execution result of `tool_B`. This structure explicitly defines the execution timing constraints through directed dependency edges, preventing logical errors caused by skipping steps, reversing order, or illegal parallelism. The `data_permissions` field encapsulates data access permission configurations as an object. The `allowed_sources` subfield is a string array `[db_1, repo_2]`, which enumerates the identifiers of the data sources that are allowed to access. The `masking_rule` subfield takes the value `pii_redaction`, indicating that a de-identification rule must be applied to data fields involving personally identifiable information. This combination of fields limits data access boundaries through a data source whitelist and a de-identification strategy, preventing unauthorized data extraction and leakage of sensitive information.The `parameter_domains` field defines the parameter value space in object form. The `threshold` key corresponds to the numerical range array [0.6, 0.95], indicating that the classification threshold parameter must be within the closed interval of 0.6 to 0.95. The `tile_size` key corresponds to the discrete enumeration array [256, 512, 1024], indicating that the image processing tile size parameter can only take one of three discrete values: 256, 512, or 1024. This field ensures the legality of parameter configuration through interval limitation and enumeration constraints, preventing out-of-bounds parameters from entering the execution stage. The `output_contract` field specifies the output contract requirements in object form. The `required_fields` subfield is a string array [result, confidence, evidence_refs], explicitly requiring that the final output result must include three fields: `result` (result content), `confidence` (confidence level), and `evidence_refs` (evidence citation list). This field ensures the completeness of the output structure through required field enumeration, meeting the downstream processing flow's acceptance standards for the result format.

[0051] Upon receiving the evidence task package and its corresponding formal constraint specifications, the agent inputs both as the reasoning context into the large language model or the agent's inference engine. This engine performs semantic parsing and logical decomposition based on the task objective description, and combines this with the tool whitelist, dependencies, and parameter domain information defined in the formal constraint specifications to generate an initial plan containing a sequence of candidate tool calls, conditional branch suggestions, a draft parameter configuration, and a description of the execution intent. The initial plan is presented in natural language or semi-structured data format, reflecting the initial reasoning path and operational intent from task input to the expected output.

[0052] The aforementioned structured execution plan is a verifiable intermediate representation that transforms task execution logic from implicit reasoning descriptions into explicit engineering structures. It extracts the atomic operation intentions from the original plan through the compilation process, constructs execution nodes with clearly defined input / output interfaces, and establishes topological connections between nodes based on data dependencies and control flow relationships, forming a standardized execution graph structure containing data flow, control flow, and parameter instances. This structured representation transforms the vague "what to do first, what to do later" intentions originally described in natural language or semi-structured JSON into explicit execution paths that can be parsed by a formal verifier, traversed by a scheduler, and tracked by an auditor, making the execution logic an engineering object with deterministic boundaries and inspectable properties. By explicitly defining execution nodes and dependencies, the compiled structured execution plan can undergo rigorous static verification based on formal constraint specifications, thereby ensuring the compliance of the execution plan from the source. At the same time, the explicit structure at the node level provides precise anchor points for evidence recording during the execution process, enabling each operation step to be bound to an independent evidence object. Ultimately, this forms a complete, reproducible, and auditable execution spectrum from task input to result output, improving the controllability of complex task execution processes and the acceptability of results.

[0053] The above step S110 can compile the original plan into a structured execution plan using at least one of the following compilation methods: The first compilation method: a compilation method based on template matching and slot filling; This compilation method uses a predefined plan template library as the compilation target architecture. By semantically matching the task intent in the original plan with the standard execution framework in the template, it achieves the transformation from unstructured description to structured execution plan. Its implementation is as follows: First, a set of plan templates covering typical task patterns is established. Each template defines a standard sequence of execution nodes, data flow between nodes, and parameter slots. During compilation, the semantic matching engine parses the operation intent, target object, and constraints in the original plan, maps them to the most suitable standard template, and injects the original parameters and tool selection into the execution nodes corresponding to the template through entity recognition and slot filling. Finally, a structured execution plan containing explicit nodes and dependencies is instantiated and generated.

[0054] The second compilation method: a compilation method based on abstract syntax tree parsing and transformation; This compilation method treats the original plan as a semi-structured text representation in a domain-specific language. It constructs an intermediate representation of an abstract syntax tree through lexical analysis and syntax parsing, and then generates the target structured execution plan through tree traversal and node transformation. The implementation is as follows: First, a context-free grammar of the original plan is defined. A lexical analyzer breaks down the original plan into lexical units such as utility call symbols, parameter key-value pairs, and control flow keywords. A syntax parser organizes these units into a hierarchical abstract syntax tree based on predefined grammar rules, where internal nodes represent control structures and leaf nodes represent atomic operations. The compiler performs a depth-first traversal of this syntax tree, converting each syntax node into a corresponding execution node, extracting data dependencies and control dependencies, and finally assembling it into a structured execution plan containing explicit execution nodes and inter-node dependencies.

[0055] The third compilation method: a compilation method based on graph reconstruction and topology analysis; This compilation method employs entity relation extraction and graph construction techniques to identify operational entities in the original plan as graph nodes and data and control flow as graph edges. Through graph optimization and topology sorting, an executable structured execution plan is generated. The implementation process is as follows: First, a named entity recognition and relation extraction model is used to locate atomic operation descriptions, parameter configurations, and execution order clues from the original plan, and the identified operational entities are instantiated as explicit execution nodes. Directed edges between nodes are established based on data flow analysis and control flow parsing, including data dependency edges (the output of the previous node serves as the input of the next node) and control dependency edges (conditional branches or parallel synchronization relationships). Isolated nodes are eliminated through graph connectivity checks, and a topology sorting algorithm is used to determine linear or parallel execution sequences that meet dependency constraints, ultimately outputting a standardized structured execution plan.

[0056] The fourth compilation method: a compilation method based on atomic operation extraction and dependency relationship construction; Optionally, step S110 above compiles the original plan into a structured execution plan, including: parsing the original plan and extracting atomic operations and corresponding parameter information; wherein the original plan is an unstructured or semi-structured plan; constructing explicit execution nodes based on atomic operations and determining the input data, output data, and parameter information of each explicit execution node; establishing inter-node dependencies based on the data dependencies and control flow relationships between explicit execution nodes, generating a directed acyclic graph representation with explicit execution nodes as vertices and inter-node dependencies as edges, and converting the original plan into a graph-structured structured execution plan.

[0057] The atomic operations described above are the smallest functional execution units in a structured execution plan, representing an indivisible tool call, model inference, or data processing action. They encapsulate specific computational logic or external function calls into independent execution nodes. During compilation, atomic operations are determined through semantic parsing and entity extraction of the tool call intent in the original plan. Each atomic operation corresponds to an explicit execution node, carrying a clear operation type identifier and functional semantics. The parameter information corresponding to an atomic operation includes the set of configuration parameters required for operation execution and the definition of the input data interface for the atomic operation. The configuration parameters mainly include: parameter identifier, parameter value or range, parameter data type, and parameter semantic description; the input data interface definition specifies the source, format, and data dependencies of the required input data; and the output data interface definition specifies the type, structure, and downstream consumption method of the output data, forming a complete data flow and control flow connection foundation.

[0058] In this embodiment, parsing the original plan to obtain atomic operations and corresponding parameter information can be achieved through various technical means, including but not limited to: (1) semantic parsing methods, structured data parsing methods, and pattern matching and rule extraction methods based on natural language processing. Specifically, when the original plan is presented in the form of natural language text, named entity recognition and intent classification techniques can be used. By training a sequence labeling model or utilizing the contextual understanding capabilities of a large language model, tool call entities, operation type identifiers, and parameter key-value pairs can be located from the descriptive text. When the original plan is presented in the form of semi-structured data (such as JSON or YAML), atomic operation identifiers and parameter configurations in predefined fields can be directly extracted by recursively traversing the data structure, parsing key-value mapping relationships, and nested object levels. (2) Based on predefined lexical rules, regular expression patterns, or context-free grammars, a lexical analyzer and a syntax parser are constructed. Through template matching, slot filling, or abstract syntax tree traversal, the operation intents and parameter instances in the original plan are mapped to a standardized set of atomic operation descriptions and parameter information.

[0059] The aforementioned explicit execution node is the basic scheduling unit in the structured execution plan that carries the logic of atomic operations. By encapsulating operation identifiers, input / output interface definitions, and parameter configuration information, it transforms the operational intent in the original plan into an engineered object with clear data boundaries and configuration attributes. When constructing this node, the functional semantics and operation identifier of the node can be determined based on the atomic operation types extracted from the original plan. Then, specific input data interfaces are configured for each node to specify the data source and format requirements, output data interfaces to specify the data products and downstream consumption methods, and extracted parameter information is injected to form a complete execution context. Finally, it is instantiated into an explicit execution entity that can be independently scheduled in the execution scheduler, individually checked in the verifier, and precisely traced in the evidence record.

[0060] In a specific application scenario, a plan can be compiled into a structured execution plan PlanIR as follows: PlanIR={Nodes:{Node1:fetch_image(defect_id),Node2:align_layout(image_output,gds_window),Node3:classify_defect(aligned_data,threshold=0.82),Node4:generate_result(class,confidence,evidence_refs)},Edges:[Node1→Node2,Node2→Node3,Node3→Node4]}. In the above structured execution plan PlanIR, the Node1 field is encoded as fetch_image(defect_id), representing a data acquisition atomic operation node. The operation identifier fetch_image indicates that this node is responsible for retrieving defect image data from the storage system. The input parameter defect_id is a unique identifier of the defect to be re-evaluated. This node, as the starting node of the execution graph, undertakes the function of pulling raw data, and its output is the raw defect image data stream. The Node2 field is encoded as `align_layout(image_output, gds_window)`, representing a data processing atomic operation node. The operation identifier `align_layout` indicates that this node performs layout alignment and spatial registration operations. `image_output` is a reference to the output data of Node1, representing the defect image acquired by the previous node, and `gds_window` is the layout design data window parameter. This node generates a registered composite data structure by spatially aligning the visual image with the circuit layout, providing spatial context for subsequent defect classification. The Node3 field is encoded as `classify_defect(aligned_data, threshold=0.82)`, representing an inference decision-making atomic operation node. The operation identifier `classify_defect` indicates that this node calls the defect classification model for pattern recognition and type determination. The input parameter `aligned_data` references the aligned data output by Node2, and `threshold=0.82` sets the classification confidence threshold to 0.82. This node performs the core machine learning inference operation, outputting the defect category identifier and confidence score.The Node4 field is encoded as generate_result(class, confidence, evidence_refs), representing a result synthesis atomic operation node. The operation identifier generate_result indicates that this node is responsible for aggregating the execution products of the preceding nodes and generating structured output. The input parameters class and confidence reference the classification result and confidence value output by Node3. evidence_refs is a set of evidence references. This node encapsulates the scattered intermediate results into task execution results that meet the output contract requirements. The Edges field defines the execution dependencies between nodes in the form of a directed edge list. Node1→Node2 means that the execution of Node2 depends on the completion of Node1 and its output data; Node2→Node3 means that Node3 needs to wait for the alignment operation of Node2 to finish; Node3→Node4 means that Node4 depends on the classification conclusion of Node3. The set of dependent edges forms a directed acyclic graph structure, clearly representing the data flow and execution timing constraints, ensuring that each atomic operation is executed in the correct topological order, and preventing data races and logical errors.

[0061] Step S120: Perform static verification of the structured execution plan based on formal constraint specifications.

[0062] It is understandable that although the agent uses formal constraint specifications as contextual references to guide the generation of a draft plan that conforms to the constraints during the initial plan generation stage, the generated initial plan may still have implicit violation risks such as tool call out-of-bounds, parameter configuration out-of-limits, or dependency mismatches due to the probabilistic nature of large language model generation and potential biases in semantic understanding. Therefore, after compiling the initial plan into a structured execution plan, independent static verification can be performed. Through programmatic formal rule checks, mandatory logical judgments can be made on tool whitelists, parameter value ranges, dependency topologies, and data permissions. This can build a second deterministic defense before execution, ensuring that only execution schemes that absolutely satisfy all constraints can enter the running phase. This blocks any possible violation paths at the source, forming a progressive risk control system from flexible guidance to rigid verification.

[0063] Optionally, step S120 includes: performing at least one static verification on the structured execution plan based on formal constraint specifications, including tool validity verification, dependency topology verification, data permission verification, parameter validity verification, output contract satisfiability verification, and evidence generation capability verification; when the static verification fails, the structured execution plan is rejected, and the structured execution plan is modified based on the verification failure result to ensure that the structured execution plan meets the formal constraint specifications; wherein, the modification includes at least one of adjusting the execution node parameters, reselecting the tool, and adjusting the dependencies between nodes; and the modified structured execution plan is statically verified again.

[0064] The aforementioned tool legitimacy verification aims to ensure that each explicit execution node in the structured execution plan can only call tools explicitly authorized in the formal constraint specification, preventing agents from exceeding their authority to call external functional modules not included in the whitelist or operation units with security risks. It works by traversing each execution node in the structured execution plan, extracting the operation identifier configured in the node, and determining the membership relationship with the tool whitelist set defined in the formal constraint specification. When any execution node is detected to reference a tool identifier that is not in the whitelist, the verification is deemed to have failed, thereby blocking the calling path of unauthorized tools before execution.

[0065] The aforementioned dependency topology verification aims to ensure that the execution order of each explicit execution node in the structured execution plan strictly follows the dependency topology relationship defined in the formal constraint specification, preventing illegal parallel operations such as skipping execution, reverse calls, or violating data dependencies. It checks for the existence of loops by parsing the dependency graph between nodes in the structured execution plan, verifying whether the preceding dependency nodes of each execution node have been satisfied or arranged in advance, and confirming that there are no data dependency conflicts or timing races between parallel execution nodes, thereby ensuring the logical correctness and data consistency of the execution process.

[0066] The aforementioned data permission verification aims to ensure that data access operations in the structured execution plan are strictly limited to the data source scope and field set authorized by the formal constraint specification, preventing agents from accessing restricted databases without authorization, extracting unauthorized data fields, or leaking sensitive information. It verifies whether data requests comply with preset permission boundaries and data security policies by extracting the data source identifier, query target field, and access operation type configured for each execution node and comparing them item by item with the list of allowed data sources, field whitelist, and desensitization strategies defined in the formal constraint specification, thereby blocking potential unauthorized data access paths before execution.

[0067] Parameter validity verification aims to ensure that the parameter values, types, and formats used by each explicit execution node in the structured execution plan are strictly within the legal value space defined by the formal constraint specification. This prevents calculation errors, model failures, or security vulnerabilities caused by out-of-bounds thresholds, illegal types, or dangerous configurations. It extracts parameter identifiers, numerical values, and data types by traversing the parameter configuration set of each execution node and performs range inclusion checks and type matching verifications against the parameter domains (including numerical ranges, enumeration sets, regular patterns, or type constraints) defined for this tool in the formal constraint specification. When any parameter value is detected to exceed the preset boundary or the type does not match, the verification is deemed to have failed, thereby intercepting illegal parameter configurations from entering the execution phase before execution.

[0068] The aforementioned output contract satisfiability check aims to ensure that the structured execution plan can generate an output result structure that conforms to the formal constraint specification definition along the logical execution path. This prevents downstream processing failures or acceptance failures due to missing execution nodes, omitted output fields, or format mismatches. By analyzing the data transformation logic of the execution path termination node and each intermediate node of the structured execution plan, tracing the generation source and transmission path of the output fields, it verifies whether the final output node necessarily produces a task execution result that contains all required fields and conforms to the format requirements. This confirms the completeness and compliance of the result structure before execution.

[0069] The aforementioned evidence generation capability verification aims to ensure that the prerequisite evidence, input data versions, and configuration dependencies required before the execution of the structured execution plan are complete and valid. This prevents the agent from entering the execution phase without key evidence or with mismatched data versions, which could lead to unreliable or untraceable conclusions. By traversing the input dependency declarations of each execution node, it extracts the required evidence identifiers, data source references, version hashes, or configuration signatures, and performs existence checks, version consistency comparisons, and integrity verifications against the currently available evidence library, data snapshots, and configuration status. When any execution node is found to have missing evidence objects, mismatched versions, or broken configuration dependencies, the verification is deemed to have failed, thereby blocking the execution path with missing evidence and triggering the supplementary evidence process before execution.

[0070] In the above scheme, when static verification identifies a deviation between the structured execution plan and the formal constraint specification, a plan correction process is automatically initiated based on the verification failure result. This process eliminates violations and restores compliance with the formal constraint specification by specifically adjusting the internal attributes of the execution plan, avoiding manual intervention and task interruption caused by direct rejection of execution, and improving the automation rate and robustness of task execution. The correction operation includes three dimensions: execution node parameter adjustment, tool reselection, and inter-node dependency reconstruction. Specifically, execution node parameter adjustment addresses scenarios where parameter validity verification fails, correcting parameter values ​​outside the valid domain to the range defined by the formal constraint specification without changing the tool selection and topology. Tool reselection addresses scenarios where tool validity verification or dependency topology verification fails, selecting alternative tools that meet the dependency requirements from the tool whitelist of the formal constraint specification and simultaneously updating the tool identifier and interface contract of the corresponding node. Inter-node dependency reconstruction addresses scenarios where dependency topology verification fails, adjusting the data flow connection or control flow order between nodes in the directed acyclic graph to eliminate circular dependencies, missing prerequisites, or timing conflicts. The revised structured execution plan needs to be re-validated. This validation process involves incremental validation of the relevant dimensions involved in the revision, or full validation in complex revision scenarios, to confirm that the revision has completely eliminated the original violations and has not introduced any new compliance risks. Only after passing the re-validation can the structured execution plan enter the scheduling and execution phase, thus forming a closed-loop control mechanism of validation, revision, and re-validation, ensuring that the plan entering the execution phase always meets all the requirements of the formal constraint specifications.The aforementioned static verification can be implemented through several methods: First, based on field tracing and data flow analysis, an end-to-end mapping relationship is established from the input fields of the evidence task package to the output fields of each execution node during the compilation phase. The transmission path and transformation operations of fields between nodes are traced, verifying the matching between the output field types of upstream nodes and the input field requirements of downstream nodes, as well as whether the data flow completely covers all the required return fields required by the output contract. Second, by traversing the explicit execution nodes in the structured execution plan, the output field set of each node is extracted, and set matching and inclusion relationship verification are performed with the field structure, data type, and required constraints defined in the formal constraint specification's output contract. This verifies whether the execution link can generate a result that meets the contract requirements. The result format; third, based on the topology traversal algorithm of the directed acyclic graph, starting from the initial input node, recursively checks whether the tool identifier of each node falls into the tool whitelist, whether the dependency edges between nodes satisfy the pre- and post-constraints defined by the topology of the call dependency, and whether there are circular dependencies or isolated nodes; fourth, for parameter validity verification, by traversing the parameter configuration table of each node, the parameter values ​​are compared with the value range, enumeration set or regular constraint defined in the formal constraint specification; fifth, in the evidence satisfiability verification, the encapsulation field list of the evidence task package is parsed and the intersection operation is performed with the evidence requirement list declared by each node in the structured execution plan to verify the availability of the required evidence object and the matching status of the version identifier.

[0071] Step S130: After the static verification is passed, the structured execution plan is scheduled to be executed; wherein, the structured execution plan is driven by the evidence information encapsulated in the evidence task package.

[0072] After static verification is passed, the agent starts the task execution process according to the node topology order, data dependencies and control flow logic defined in the structured execution plan. It traverses each explicit execution node in the order determined by the directed acyclic graph. For nodes without prerequisite dependencies or whose prerequisite dependencies have been completed, execution is started immediately. For nodes with data dependencies, execution is triggered after the output data of its predecessor node is ready. The agent supports parallel execution strategy for nodes without dependency conflicts to improve processing efficiency, provided that dependency constraints are met, or serial execution strategy to ensure data consistency when there is resource contention or timing requirements, until all termination nodes have completed execution.

[0073] The structured execution plan uses the evidence information encapsulated in the evidence task package as the initial data payload and control trigger source for execution. This evidence information is parsed at the starting input node of the plan and injected into the data flow of the directed acyclic graph. According to the node topology order and data dependency relationship, the input data, trigger conditions and context state are passed to the downstream explicit execution nodes, so that each node performs the corresponding atomic operation based on the received evidence information, and the processed intermediate results continue to be passed to subsequent nodes along the inter-node dependency relationship until the terminating node completes the output. This realizes data-driven execution from the initial evidence input to the full-link node scheduling.

[0074] Step S140: Record evidence information when executing the structured execution plan, and output the task execution results including the evidence information.

[0075] The aforementioned evidence consists of verifiable traces generated during the execution of execution nodes. These traces capture the contextual state, computational basis, and environmental information of atomic operations, establishing a causal relationship between the execution action and the operational context, forming a complete technical spectrum from input data to output conclusions. Embedding evidentiary information into task execution results transforms task conclusions from isolated text outputs into proof objects accompanied by a complete execution spectrum. This supports independent review of the basis for conclusion generation, formal verification of the compliance of the execution process, and accountability and scenario reconstruction in the event of disputes or anomalies. Consequently, it meets the stringent requirements of high-risk decision-making scenarios for the credibility, acceptability, and audit traceability of results.

[0076] Optionally, step S140 above records evidence information when executing the structured execution plan, including: generating corresponding evidence objects for explicit execution nodes and establishing a binding relationship between explicit execution nodes and evidence objects; wherein, the evidence object includes at least one of operation identifier, input / output summary, parameter summary, tool version, timestamp, and data source reference.

[0077] The aforementioned operation identifier is a symbolic label used to uniquely identify the type of atomic operation performed by a specific explicit execution node. It represents the specific tool category or functional operation semantics invoked by that node. The operation identifier can be obtained by parsing the operation type field of the corresponding execution node or the metadata name of the tool invocation interface in the structured execution plan. It is extracted and bound to the evidence object during the node instantiation or tool invocation initialization phase, and is used to quickly locate the operation category and responsible party in subsequent audits.

[0078] The aforementioned input / output digests are compressed representations describing the content characteristics and structure of the input data consumed and the output data generated by the execution node. They are typically recorded using hash fingerprints, data checksums, or format signatures, rather than complete data copies. Input digests can be obtained before node execution by reading the input data stream and calculating its content fingerprint. Output digests can be obtained after node execution by performing the same fingerprint calculation and format capture on the generated output data stream. Together, they form the basis for data lineage tracing, ensuring data integrity and reproducibility during execution.

[0079] The parameter summary described above is a structured description of the instantiated values ​​of specific configuration parameters used during the execution of the node, including key runtime configurations such as classification thresholds, processing window sizes, and model hyperparameters. The parameter summary can be generated by extracting the parameter mapping table configured for this node in the structured execution plan, or by capturing the actual input parameter key-value pairs during the tool's API initialization phase. It is used for subsequent verification of whether the execution parameters conform to the value range defined by the formal constraint specification and supports parameter-level backtracking analysis of abnormal results.

[0080] The tool version mentioned above is a metadata tag that identifies the version number of the specific tool, algorithm model, or software component on which the atomic operation is performed. The tool version can be obtained by querying the version registry in the tool manifest, reading the version attribute field of the model file, or capturing the image version identifier in the containerized execution environment. It is used to ensure the reproducibility of the execution results and to provide accurate traceability of the software environment in case of version compatibility disputes or model drift issues.

[0081] The timestamps mentioned above are precise time markers that record critical state changes during the lifecycle of an execution node, including node scheduling start time, execution completion time, or critical input / output operation times. Timestamps can be captured and written to evidence objects at critical event points of node state transitions by calling the system's high-resolution clock or network time protocol service. These timestamps are used for post-event auditing of execution timing analysis, performance bottleneck location, and cross-node concurrency control.

[0082] The aforementioned data source reference is a set of identifiers describing the original source, storage location, or database access path of the input data, including database connection identifiers, bucket paths, or table names. Data source references can be generated by parsing the data source fields defined in the input data interface of the structured execution plan, or by capturing the metadata of the actual established data connection during data acquisition operations. They are used to verify whether data access conforms to the data permission scope authorized by the formal constraint specification and support the tracing of data lineage.

[0083] The aforementioned binding relationships establish a traceable association between explicit execution nodes and corresponding evidence objects. These associations can be implemented through direct mapping based on unique identifier references, fingerprint binding based on hash digests, indirect association based on index structures, and group association based on shared storage. Specifically, one-to-one binding is achieved by assigning an independent evidence object identifier to each execution node and establishing a bidirectional reference; one-to-many binding is achieved by associating a single execution node with a collection identifier or list structure of multiple evidence objects; and many-to-many or group-shared binding is achieved by mapping multiple related execution nodes to the same evidence package identifier or shared evidence container. Furthermore, binding relationships can also be established using derived identifiers such as content hash values, chained timestamp fingerprints, or log sequence indexes, making the association between evidence objects and execution nodes tamper-resistant and verifiable, supporting precise identifier-based retrieval and content-based integrity verification.

[0084] It is understandable that, in addition to evidentiary information, the task execution results also include task output content that characterizes the processing conclusion, result confidence or certainty score that measures the reliability of the conclusion, execution path information that records the sequence of explicit execution nodes and control flow branches, formal constraint specification version marker that identifies the set of constraint rules on which it is based, plan hash fingerprint or content summary that verifies the integrity of the structured execution plan, and description of failure reasons or missing evidence information provided in the event of execution anomalies or verification failures.

[0085] It is understandable that existing defect review solutions at the fab level mainly adopt a passive response model based on manual item-by-item review, or a semi-automated screening mechanism combined with a simple active learning strategy. These solutions extract samples from the production line defect stream through preset uncertainty thresholds or uniform sampling rules for manual review, and only record the final classification label as model feedback after review. However, when faced with the long-term drift in defect distribution caused by frequent changes in product layers and machine formulations, such solutions lack a systematic consideration of the sensitivity to suspected new types of defects. This makes it difficult to effectively identify potential new defect patterns that deviate from the known category distribution, leading to the discovery of high-value unknown defects. The samples are overwhelmed by known defects with high confidence, and the review process typically only outputs isolated conclusion labels. There is a lack of a mechanism to structurally encapsulate heterogeneous evidence such as defect region-of-interest images, wafer map spatial context, and fragments of process formulation parameters. This prevents the formation of a complete evidence chain from defect signal acquisition to manual judgment, making it difficult to audit and trace the review conclusions. Furthermore, the weights in the active sampling strategy are usually preset as static parameters, unable to adaptively adjust based on recent new class discovery rates, anomaly sample hit rates, or budget constraints. This results in ineffective consumption of annotation resources on low-return samples or a gradual degradation of new class exploration capabilities. Therefore, this application provides the following solution: Optionally, the aforementioned evidence task package includes a defect review evidence task package for defect review tasks in the semiconductor manufacturing process. The aforementioned task execution method for the intelligent agent further includes: generating a defect review evidence task package; wherein the defect review evidence task package includes an image of the region of interest of the defect to be reviewed, a partial fragment of the wafer image, a layout window summary, a process log time window and a fragment of process recipe parameters, as well as candidate labels and confidence information.

[0086] The aforementioned defect review task is a technical step in the semiconductor manufacturing process where the defect detection results output by automated optical inspection or automated defect classification systems are manually or intelligently assisted in verification. It combines visual defect features, wafer spatial distribution context, process formulation parameters, and layout design information to ultimately confirm or correct the defect category. Defect review tasks are typically triggered in scenarios such as: the confidence level of the automated classification model output is below the acceptance threshold; the defect feature distribution deviates significantly from known category inventories and is suspected to belong to a new defect pattern; product layer switching or machine formulation changes on the production line cause process distribution drift; or samples with high information gain potential are identified based on active learning strategies. The aim is to improve defect classification accuracy, discover unknown defect types, and correct model biases through human-machine collaborative review, thereby ensuring the effectiveness of semiconductor manufacturing process control and the reliability of yield management.

[0087] The aforementioned defect review evidence task package is a structured data encapsulation unit designed for defect review scenarios in semiconductor manufacturing. It aggregates multidimensional heterogeneous information scattered across different data sources using a unified data organization format, providing a panoramic judgment context and traceable evidence foundation for manual or automated review. The defect review evidence task package includes at least one of the following information dimensions: visual feature data of the defect to be reviewed (region of interest image), spatial distribution context (partial wafer map fragment), design structure reference (layout window summary), process records (process log time windows and process recipe parameter fragments), and preliminary automated inference results (candidate labels and confidence information). Specifically, the region of interest image of the defect to be reviewed can be acquired through the image acquisition subsystem of the defect detection equipment. Based on the defect coordinates and bounding box size output by the defect detection algorithm, a high-resolution local image patch is extracted from the original wafer scan image. This image patch expands outwards from the defect center by a specific pixel range, ensuring coverage of the complete defect shape and its adjacent background area, serving as the primary basis for visual judgment. Local segments of the wafer map can be obtained from the defect database of the manufacturing execution system or the wafer inspection data management platform. Based on the physical coordinates of the target defect on the wafer, a spatial distribution sub-map containing the defect and all other defects within a preset radius is extracted. Alternatively, the defect density statistical signature and clustering pattern features of the region can be extracted to characterize the spatial context and distribution anomalies of the defect at the wafer level. Layout window summaries can be obtained by mapping the physical coordinates of the defect to GDS layout design data. Based on optical proximity correction or design rule checks of the hierarchical structure information in the database, the design layer identifier, adjacent geometric topology relationships, linewidth spacing parameters, and aligned layout window views at the defect location are extracted to correlate the spatial correspondence between defects and circuit design features. Process log time windows can be obtained from the manufacturing execution system or machine equipment data acquisition system. Based on the timestamp of the defect occurrence, a preset time period is extended forward and backward to extract the operation event logs, alarm records, and status transition information of all associated process equipment within that time interval, used to trace the process environment context at the time of defect occurrence. Process recipe parameter fragments can be obtained through the Recipe management system or process equipment control interface. The process recipe identifier and key process parameter instance values ​​at the time the defect occurred can be extracted, including setpoints and actual feedback values ​​for temperature, pressure, flow rate, and power, to establish a causal relationship between defect characteristics and process conditions. Candidate labels and confidence information can be obtained through a previously deployed automatic defect classification model or rule-based defect recognition engine. This information includes the model's probability distribution prediction of the defect's category, the maximum confidence score, the second-best category candidates, and the matching rule identifier and deterministic score triggered by the rule engine. This indicates the uncertainty and classification difficulty of the current sample, supporting the priority determination of active sampling and manual review.

[0088] The aforementioned defect review evidence task package can be persisted using various structured storage formats. For example, it can encode metadata descriptions and data reference pointers for each information dimension using a hierarchical data encapsulation format (such as JSON or Protocol Buffers). Large-scale binary content such as high-dimensional image data, layout files, and log streams can be stored in independent buckets of object storage services or distributed file systems and referenced using content hashing or Uniform Resource Identifiers. Structured fields such as process parameters and candidate tags can be embedded in the main document as key-value pairs or stored in specific table structures of relational databases. It also supports the use of content-addressed storage mechanisms (such as hash-based immutable storage) to ensure the integrity and tamper-proof nature of each evidence component, and achieves precise binding and traceability retrieval with specific review task instances through version control identifiers or timestamp sequences.

[0089] Optionally, the above-mentioned task execution method for intelligent agents further includes: before generating the original plan, actively sampling multiple candidate defect tasks to be reviewed based on a multi-objective utility function to determine the defect review task; wherein, the multi-objective utility function includes: an uncertainty term for quantifying the degree of prediction uncertainty, a sample diversity term for quantifying the difference in feature space distribution between candidate samples and selected samples, a new class sensitivity term for quantifying the degree of deviation between candidate samples and known defect category distribution, and a review cost term for quantifying the time required for evidence acquisition and manual review; generating a defect review evidence task package based on the defect review task, and using the defect review evidence task package as an evidence task package to trigger the generation of the original plan and the compilation of the structured execution plan.

[0090] The aforementioned multi-objective utility function is an active sampling evaluation function for semiconductor defect re-judgment scenarios. It integrates quantitative indicators from four complementary dimensions—prediction uncertainty, sample feature diversity, sensitivity to novel defect types, and re-judgment cost—to identify priority re-judgment targets that offer both information gain and cost-effectiveness from a candidate defect task set. The multi-objective utility function integrates the evaluation results of each component in an additive manner, balancing the allocation of resources for exploring unknown defect patterns and utilizing known knowledge through configurable weight coefficients. This ensures that the limited manual re-judgment budget is focused on samples most valuable for improving model performance.

[0091] The uncertainty term quantifies the degree of uncertainty of the classification model regarding the prediction results of candidate defective samples. It is calculated based on the posterior probability distribution of the model output. Let p(y|x) be the predicted probability distribution of each category output by the model for a candidate sample x. Then the uncertainty term U(x) is defined as U(x) = 1. max(p(y|x)) is the difference between the maximum predicted probability and the value 1. Here, p(y|x) represents the model's probability estimate that sample x belongs to class y; it is a dimensionless value ranging from [0,1]. max(p(y|x)) represents the maximum predicted probability of this sample across all classes. U(x) is also a dimensionless value ranging from [0,1]. A larger value indicates greater uncertainty in the model's classification of the sample, and such values ​​should be prioritized in the review process to eliminate blind spots in the model's understanding.

[0092] The sample diversity term measures the difference in distribution between candidate samples and the selected sample set in the feature space, preventing active sampling from over-concentrating on redundant samples with similar features. Let the selected sample set be S, the feature embedding vector of candidate sample x be embed(x), and the embedding vector of selected sample s be embed(s). Then the diversity term D(x) is defined as D(x) = mins∈Sdistance(embed(x), embed(s)), which is the feature distance between the candidate sample and the nearest neighbor sample in the selected sample set. Here, embed() represents the embedding function that maps defective samples to the feature space by the feature extraction network or dimensionality reduction algorithm, and the output is a real-valued vector; distance() represents the distance metric in the feature space (such as Euclidean distance or cosine distance), with the dimension being length units or dimensionless (depending on the specific distance definition); the dimension of D(x) is consistent with the selected distance metric. The larger the value, the greater the difference between the candidate sample and the selected samples, and the better it can supplement the sample diversity coverage.

[0093] The novel class sensitivity term is used to evaluate the degree of deviation of candidate samples from the known defect category distribution, identifying outlier samples that may belong to unseen defect patterns. Let the feature embedding of candidate sample x be embed(x), then the novel class sensitivity term N(x) is defined as N(x) = outlier_score(embed(x)), which is the anomaly score calculated based on the embedding vector. Where outlier_score( ) represents the anomaly degree quantification value output by an anomaly detection algorithm (such as isolated forest, local anomaly factor, or density estimation-based outlier detection). It is a dimensionless numerical value (usually normalized to [0,1] or in standard score form). The larger the value, the more the sample deviates from the known category distribution, and the more likely it is to be a new defect pattern or an out-of-distribution sample. It should be re-judged first to expand the cognitive boundary of the model.

[0094] The re-evaluation cost item is used to quantify the comprehensive resource expenditure required to complete the re-evaluation of candidate defects, balancing information gain and annotation cost. Let the evidence acquisition cost be evidence_fetch_cost(x) and the manual review time be human_review_time(x), then the cost item C(x) is defined as C(x) = evidence_fetch_cost(x) + human_review_time(x). Where evidence_fetch_cost(x) represents the computational resources, storage access, or network transmission cost required to fetch multi-source evidence such as defect images, layout data, and process logs, and the unit can be time (seconds) or currency; human_review_time(x) represents the average manual time required for engineers to review the defect, and the unit is time (minutes or hours); the unit of C(x) should be consistent with its components (e.g., uniformly converted to time or cost units). The larger the value, the higher the resource consumption for re-evaluating the sample, and its priority should be reduced under budget constraints.

[0095] A multi-objective utility function can integrate the above four indicators based on a linear weighted combination to calculate the comprehensive priority score of candidate samples. Let w1, w2, w3, and w4 be the weight coefficients of the uncertainty, diversity, novelty sensitivity, and cost items, respectively. Then, the comprehensive utility score Score(x) is defined as Score(x) = w1 U(x)+w2 D(x)+w3 N(x) w4 C(x). The weighting coefficients w1, w2, w3, and w4 are dimensionless positive real numbers used to adjust the relative importance of each dimension in the sampling decision. Since the cost item C(x) is a negative indicator (the larger the value, the lower the priority), it is negative in the combination formula. The system sorts all candidate samples in descending order of Score(x), and selects the top-K samples within the preset daily manual review hours or budget limit as the determined defect review tasks to enter the subsequent process.

[0096] After actively selecting and identifying defect review tasks, the multi-source heterogeneous data of the defects to be reviewed corresponding to the selected defect review tasks, including defect region of interest images, wafer image fragments and statistical signatures, aligned layout window summaries, associated equipment log time windows and process recipe parameter fragments, as well as candidate labels and confidence information, are standardized, encapsulated, and annotated with metadata to form a defect review evidence task package. This defect review evidence task package serves as the initial data payload and execution context for triggering subsequent agent task execution processes. Using this defect review evidence task package and its corresponding formal constraint specifications as input, the original plan generation process is initiated. The agent generates an original plan based on the evidence information encapsulated in the task package, which is then compiled into a structured execution plan containing explicit execution nodes and dependencies between nodes. This allows the actively selected review tasks to seamlessly integrate into the graph structured execution and static verification process, achieving a complete technical closed loop from task selection to plan generation and compilation.

[0097] The above scheme optimizes the decision boundary by prioritizing difficult samples with ambiguous model cognition through uncertain terms, expands the coverage by avoiding sampling redundancy through diversity terms, actively explores out-of-distribution samples through novelty sensitivity terms to discover unknown defect patterns, and constrains resource consumption through cost terms to achieve sustainable labeling budget management. These four synergistic effects shift limited manual review resources from a massive number of known high-confidence defects to high-value information gain samples, thereby maintaining the model's adaptability and discovery capability in an environment where production line defect distribution continuously drifts. Optionally, the weight coefficient w3 (newty sensitivity term weight) can be dynamically adjusted based on the recent newty discovery rate, anomaly sample hit rate, or budget constraint status: when the new defect type discovery rate is lower than a preset threshold for several consecutive periods, or when the proportion of high-anomaly score samples confirmed by manual review to belong to a new category increases, w3 is increased to enhance the exploration of potential new categories; when high-anomaly score samples mostly belong to known categories after review and the budget becomes tight, w3 is decreased to reduce the resource consumption of low-yield anomaly samples, and a step-by-step small-update method is used to limit the weight fluctuation range to maintain strategy stability.

[0098] Optionally, the above-mentioned task execution method for intelligent agents further includes: dynamically adjusting the weight of the new type of sensitivity item based on the recent new type of defect discovery rate, abnormal sample hit rate, or budget constraint status; wherein, when the weight update condition is met, the weight of the new type of sensitivity item is increased; the weight update condition includes the new type of defect discovery rate being lower than a preset threshold, or the abnormal sample hit rate being higher than a threshold, or at least one of the following changes occurring: process batch, machine, recipe version, and layer; when the abnormal sample hit rate is lower than the threshold and the budget is tight, the weight of the new type of sensitivity item is decreased, and a step-by-step update method is adopted to limit the weight fluctuation range.

[0099] The aforementioned new defect discovery rate is the proportion of samples that, within a preset time sliding window or statistical period, are actively selected, enter the review process, and are confirmed by manual review to belong to previously unrecorded defect categories or new defect patterns, out of the total number of reviewed samples in that period. It quantifies the actual output efficiency of the current active learning strategy in exploring unknown defect patterns as a percentage. The anomaly sample hit rate is the proportion of candidate samples whose new category sensitivity score exceeds a specific anomaly threshold, which, after manual review, are confirmed to belong to new defect types, unknown patterns, or category boundary samples. It reflects the accuracy of the new category sensitivity assessment index in identifying samples outside the true distribution. The budget constraint status is quantified by the ratio of the consumed manual review time or evidence acquisition cost in the current statistical period to the preset budget ceiling, or by the percentage of remaining available budget to planned budget, representing the degree of resource strain.

[0100] When the detection rate of new defect types remains below the preset detection rate threshold, it indicates that the current sampling strategy is overly focused on high-confidence samples of known categories or that the model has stabilized and potential exploration is insufficient. In this case, increasing the weight of the new category sensitivity term can enhance attention to samples deviating from the known distribution, prompting the sampling strategy to tilt towards potential unknown defect patterns. When the hit rate of abnormal samples is higher than the preset hit rate threshold, it indicates that samples with high abnormal scores do indeed belong to new categories or boundary cases. In this case, increasing the weight can amplify the utilization efficiency of effective signals and accelerate the accumulation of new category knowledge. When process batch switching, new machine launch, formula version change, or product tier adjustment occurs, the defect distribution may drift. In this case, increasing the weight can quickly respond to changes in process conditions and proactively explore unknown defect patterns that may appear under new process conditions. When the hit rate of outliers is lower than the preset hit rate threshold and the budget constraint becomes tight, it indicates that most of the current high outlier score samples still belong to known categories. Continuing to invest a lot of resources in the screening and re-judgment of outliers will lead to a decrease in unit labeling revenue and a deterioration in budget efficiency. At this time, reducing the weight can reduce the oversampling of low-return outlier samples and reallocate limited resources to samples with high uncertainty or clear diversity gains.

[0101] Weight adjustments can be implemented using a step-by-step update mechanism, which means setting reasonable upper and lower limits for weight values ​​and limiting the change to a preset step size in each adjustment rather than jumping to the target value all at once. Exponential moving averages or sliding window smoothing techniques can be used to suppress the interference of short-term statistical fluctuations on the stability of the strategy, ensuring the continuity and predictability of the sampling strategy.

[0102] The above scheme establishes a feedback-based adaptive closed loop, enabling the active sampling strategy to adjust the balance between exploration and utilization in real time according to the actual efficiency of new class discovery, the accuracy of anomaly detection, and the resource consumption status. During the stable period of production line conditions, it automatically converges to the state of efficient resource utilization, and during the period of process drift or new class scarcity, it automatically enhances the exploration intensity. At the same time, it prevents strategy oscillation by constraining the rate of change of weights, and maintains the continuous optimization and long-term stable operation of the defect review process.

[0103] Optionally, when executing a structured execution plan, the above-mentioned task execution method for intelligent agents further includes: modeling manual review operations as explicit execution nodes and incorporating them into the node dependency relationships of the structured execution plan for unified scheduling; wherein, the explicit execution nodes include automatic processing nodes and manual review nodes; the manual review nodes are triggered, allocated, and result verified based on formal constraint specifications, and select between single-person review mode, dual-person independent review mode, and expert arbitration mode according to preset collaborative strategies; the manual review nodes generate corresponding evidence objects during execution and establish binding relationships with nodes in the structured execution plan.

[0104] The manual review process is transformed from a traditional, independent external process into an explicit execution node within the structured execution plan, allowing it to share the same graph-based structured scheduling mechanism as automated processing nodes. By incorporating node dependencies, manual review is no longer an independent step outside the execution framework, but rather a vertex in a directed acyclic graph constrained by topological ordering. Its execution order, data input sources, and downstream triggering conditions are all explicitly defined by the dependencies between nodes, thereby enabling the orchestration and scheduling of human-machine collaborative tasks within a unified execution framework. Explicit execution nodes can be understood as being divided into two categories in the graph structure: automated processing nodes and manual review nodes. Automated processing nodes handle atomic operations such as algorithm reasoning, data transformation, and rule application performed by computing devices; manual review nodes handle judgment, correction, and confirmation operations performed by personnel with process knowledge. Both types of nodes have a unified interface contract and state management mechanism within the structured execution plan, participating in global scheduling through input data readiness detection, execution status monitoring, and output data publishing mechanisms, ensuring seamless integration of human-machine tasks at the data flow and control flow levels.

[0105] The single-person review mode is suitable for routine defect tasks where the automatic classification model outputs high confidence and historical review records indicate a clear type. A single qualified engineer independently reviews and judges the defect review evidence package based on visual features, spatial context, and process parameters. This mode reduces manpower consumption by simplifying the review process and is suitable for the rapid processing of large-scale standardized defects. The dual-person independent review mode is suitable for defect tasks with moderate model confidence or categorical ambiguity. Two engineers independently review the same defect review evidence package without knowing each other's identities and submit their respective judgments. Cross-validation is achieved by comparing the consistency of the two engineers' conclusions. When both conclusions are consistent, the conclusion is directly adopted; when there is disagreement, an escalation mechanism is triggered to enter expert arbitration mode. This mode utilizes independent dual judgment to reduce the risk of misjudgment caused by individual cognitive bias. The expert arbitration model is suitable for high-risk defect tasks where independent review by two individuals results in conflicting conclusions, defect characteristics exhibit rare patterns, or involve critical process layers. It involves the intervention of expert engineers with extensive process experience or defect analysis expertise, who make a final ruling based on the comprehensive information and historical knowledge base of the defect review evidence package. This model resolves controversial cases by introducing high-level professional judgment, ensuring that complex or boundary defects are classified and characterized authoritatively and accurately.

[0106] During execution, the manual review nodes generate evidence objects in real time that record the review actions, including the reviewer's identifier, operation timestamp, original algorithm conclusion, manual modification conclusion, and the basis for the modification. These evidence objects are bound to the corresponding manual review nodes in the structured execution plan through unique identifiers, forming a two-way reference link from node instances to evidence entities. This binding relationship incorporates traces of human intervention into the overall evidence chain, supporting the accurate reconstruction of the human decision-making context during subsequent deterministic replay and providing an auditable trace of human operations for consistency verification.

[0107] Optionally, the above-mentioned task execution method for intelligent agents further includes: incrementally updating at least one of the training sample set, the difficult example sample pool, and the unknown class candidate set according to the review conclusion of the defect review task, and updating the model parameters, classification threshold, and rule base accordingly, and adjusting the parameter value range in the formal constraint specification based on the updated classification threshold.

[0108] The aforementioned training sample set serves as the baseline data set for supervised learning by the agent. It consists of defect samples whose classification has been confirmed as correct by human review, along with their corresponding labels, providing a reliable foundation for the agent's category cognition. The difficult example sample pool is a cache area storing boundary samples where the agent's prediction confidence is below the expected threshold or where the prediction result is inconsistent with the human review conclusion. By accumulating cognitively challenging instances, it specifically strengthens the agent's ability to discriminate between ambiguous features and boundary situations. The unknown class candidate set is a temporary storage area containing anomalous samples that may belong to new defect patterns or significantly deviate from the known category distribution. It identifies potential new classes through cluster analysis or manual screening, providing candidate seeds for expanding the agent's category cognition space.

[0109] The incremental update mechanism transforms the re-judgment conclusions into training assets for the agent through a non-full reconstruction method. It dynamically maintains the above three types of data sets by adding newly confirmed samples, adjusting the weights of existing samples, or implementing a selective forgetting strategy. For example, in a re-judgment task of defects that has been manually confirmed as correctly classified, the defect feature data and final label are added to the training sample set in an append mode; for samples that are identified as difficult for the agent to predict or misclassified, their features and confusion information are entered into the difficult sample pool, and when the pool capacity reaches the upper limit, they are eliminated according to the sample age or importance weight; for samples that are judged as suspected new classes or out-of-distribution patterns, their feature embeddings and abnormal scores are archived into the unknown class candidate set, and after accumulating to a preset number threshold, manual clustering review and category definition are triggered.

[0110] Based on the updated training sample set and hard example sample pool, the agent updates its internal inference parameters through incremental learning or fine-tuning mechanisms. Gradient-based optimization algorithms are used to absorb new sample features while retaining existing knowledge, or knowledge distillation is employed to prevent catastrophic forgetting. The agent's classification threshold is calibrated based on the false positive and false negative rates in the review feedback, optimizing the balance between precision and recall by adjusting the decision boundaries of each category. The agent's rule base is revised based on correction patterns and attribution analysis in expert review conclusions. By adding new decision rules, adjusting the weights of existing rules, or removing outdated rules, its symbolic reasoning ability and neural network reasoning ability evolve synchronously. The updated classification threshold is synchronized to the parameter value range definition in the formal constraint specification. By modifying the safety boundaries or default values ​​of the corresponding tool parameters in the constraint configuration file, the front-end execution constraints and the back-end agent capabilities remain dynamically adapted. In specific implementation, confidence intervals are calculated based on the new threshold statistical distribution, and the upper and lower bound values ​​or discrete enumeration sets in the parameter domain fields are updated to ensure that the subsequently generated structured execution plans inherit the calibrated decision criteria during the modeling stage, forming a closed loop from data feedback to constraint reinforcement.

[0111] like Figure 2As shown, based on the same inventive concept, this application also provides an intelligent agent 200, comprising: The plan generation and compilation module 210 is used to generate an original plan based on the evidence task package and its corresponding formal constraint specifications in response to receiving the evidence task package, and compile the original plan into a structured execution plan; wherein, the structured execution plan includes explicit execution nodes and dependencies between nodes; Static verification module 220 is used to perform static verification of structured execution plans based on formal constraint specifications; The execution scheduling module 230 is used to schedule the execution of the structured execution plan after the static verification is passed; wherein, the structured execution plan is driven by the evidence information encapsulated in the evidence task package; The evidence recording and result output module 240 is used to record evidence information when executing a structured execution plan and output the task execution results including the evidence information.

[0112] The intelligent agent 200 provided in this application embodiment can be used to execute the task execution method for intelligent agents provided in this application embodiment. Its implementation principle and the resulting technical effects have been described in the foregoing method embodiments. For the sake of brevity, any part not mentioned when introducing the intelligent agent 200 can be referred to the corresponding content in any of the foregoing method embodiments.

[0113] Figure 3 This is a schematic diagram of an electronic device provided in an embodiment of this application. (Refer to...) Figure 3 The electronic device 300 includes a processor 310, a memory 320, and a communication interface 330. These components are interconnected and communicate with each other via a communication bus 340 and / or other forms of connection mechanism (not shown).

[0114] The memory 320 includes one or more (only one is shown in the figure), which may be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The processor 310 and other possible components may access the memory 320 to read and / or write data therein.

[0115] Processor 310 includes one or more (only one is shown in the figure), which can be an integrated circuit chip with signal processing capabilities. The processor 310 described above can be a general-purpose processor, including a central processing unit (CPU), a microcontroller unit (MCU), a network processor (NP), or other conventional processors; it can also be a special-purpose processor, including a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0116] The communication interface 330 includes one or more (only one is shown in the figure) and can be used to communicate directly or indirectly with other devices to exchange data. For example, the communication interface 330 can be an Ethernet interface; it can be a mobile communication network interface, such as an interface for 3G, 4G, or 5G networks; or it can be other types of interfaces with data transmission and reception functions.

[0117] One or more computer program instructions may be stored in the memory 320, and the processor 310 may read and run these computer program instructions to implement the task execution method for intelligent agents and other desired functions provided in the embodiments of this application.

[0118] Understandable. Figure 3 The structure shown is for illustrative purposes only; the electronic device 300 may also include components that are more advanced than those shown. Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown. Figure 3 The components shown can be implemented using hardware, software, or a combination thereof. For example, electronic device 300 can be a single server (or other device with computing power), a combination of multiple servers, a cluster of a large number of servers, etc., and can be either a physical device or a virtual device.

[0119] This application also provides a computer-readable storage medium storing computer program instructions. These computer program instructions are read and executed by a processor to perform the task execution method for an intelligent agent provided in this application. For example, the computer-readable storage medium can be implemented as follows: Figure 3The memory 320 in the electronic device 300, or a separate storage product (such as a USB flash drive, portable hard drive, etc.).

[0120] This application also provides a computer program product, which includes computer program instructions. These computer program instructions are read and executed by a processor to perform the task execution method for an intelligent agent provided in this application. For example, these computer program instructions can be stored in... Figure 3 The memory 320 in the electronic device 300 is located inside the memory, or it is stored in a separate storage product (such as a USB flash drive, portable hard drive, etc.).

[0121] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A task execution method for an intelligent agent, characterized in that, The method includes: In response to receiving an evidence task package, an original plan is generated based on the evidence task package and its corresponding formal constraint specifications, and the original plan is compiled into a structured execution plan; wherein, the structured execution plan includes explicit execution nodes and dependencies between nodes; the compilation method includes at least one of the following: a compilation method based on template matching and slot filling, a compilation method based on abstract syntax tree parsing and transformation, a compilation method based on graph reconstruction and topology analysis, and a compilation method based on atomic operation extraction and dependency construction; The structured execution plan is statically verified based on the formal constraint specifications. After the static verification is passed, the structured execution plan is scheduled to be executed; wherein, the structured execution plan is driven by the evidence information encapsulated in the evidence task package; Evidence information is recorded during the execution of the structured execution plan, and the task execution result including the evidence information is output. The static verification of the structured execution plan based on the formal constraint specifications includes: performing at least one of the following checks on the structured execution plan based on the formal constraint specifications: tool validity verification, dependency topology verification, data permission verification, parameter validity verification, output contract satisfiability verification, and evidence generation capability verification. When the static verification fails, the structured execution plan is rejected, and the structured execution plan is modified based on the verification failure result to ensure that the structured execution plan meets the formal constraint specifications. Specifically, for parameter validity verification failures, parameter values ​​exceeding the valid domain are corrected to the value range defined by the formal constraint specifications; for tool validity verification failures, alternative tools that meet the dependency requirements are reselected based on the formal constraint specifications, and the tool identifier and interface contract of the corresponding node are updated; for dependency topology verification failures, the data flow connections or control flow order between nodes are adjusted to eliminate circular dependencies, missing prerequisites, or timing conflicts. The method further includes: re-performing static verification on the modified structured execution plan; wherein the re-performing static verification includes full static verification or incremental static verification on the relevant dimensions involved in the modification.

2. The task execution method for an intelligent agent according to claim 1, characterized in that, The method further includes: Obtain the formal constraint specification corresponding to the evidence task package; wherein, the formal constraint specification includes at least one of the following: tool whitelist, inter-tool dependency topology, parameter value range, data access permission, and output contract requirements; the output contract requirements include constraint definitions on the structure, fields, and data types of the task execution results, as well as matching constraints on the input and output data formats between execution nodes; the output contract requirements are used to limit the form of results that the structured execution plan needs to generate after execution.

3. The task execution method for an intelligent agent according to claim 1, characterized in that, The step of compiling the original plan into a structured execution plan includes: The original plan is parsed to extract atomic operations and their corresponding parameter information; wherein, the original plan is an unstructured or semi-structured plan; The explicit execution nodes are constructed based on the atomic operations, and the input data, output data, and parameter information of each explicit execution node are determined. Based on the data dependencies and control flow relationships between the explicit execution nodes, the dependencies between the nodes are established, and a directed acyclic graph representation with the explicit execution nodes as vertices and the dependencies between the nodes as edges is generated, thus transforming the original plan into a graph-structured structured execution plan.

4. The task execution method for an intelligent agent according to claim 1, characterized in that, The recording of evidence information during the execution of the structured execution plan includes: A corresponding evidence object is generated for the explicit execution node, and a binding relationship is established between the explicit execution node and the evidence object; wherein, the evidence object includes at least one of the following: operation identifier, input / output summary, parameter summary, tool version, timestamp, and data source reference.

5. The task execution method for an intelligent agent according to any one of claims 1 to 4, characterized in that, The evidence task package includes the defect review evidence task package for the defect review task in the semiconductor manufacturing process; The method further includes: Generate the defect reassessment evidence task package; wherein, the defect reassessment evidence task package includes an image of the region of interest of the defect to be reassessed, a partial fragment of the wafer image, a layout window summary, a process log time window and a fragment of process recipe parameters, as well as candidate labels and confidence information.

6. The task execution method for an intelligent agent according to claim 5, characterized in that, The method further includes: Before generating the original plan, multiple candidate defect tasks to be reviewed are actively sampled based on a multi-objective utility function to determine the defect review task; wherein, the multi-objective utility function includes: an uncertainty term for quantifying the degree of prediction uncertainty, a sample diversity term for quantifying the difference in feature space distribution between candidate samples and selected samples, a new class sensitivity term for quantifying the degree of deviation between candidate samples and known defect category distribution, and a review cost term for quantifying the time required for evidence acquisition and manual review; Based on the defect review task, the defect review evidence task package is generated, and the defect review evidence task package is used as the evidence task package to trigger the generation of the original plan and the compilation of the structured execution plan.

7. The task execution method for an intelligent agent according to claim 6, characterized in that, The method further includes: The weight of the new type sensitivity item is dynamically adjusted based on the recent new type defect discovery rate, abnormal sample hit rate, or budget constraint status. Specifically, when the weight update conditions are met, the weight of the new type of sensitivity item is increased; the weight update conditions include the new type of defect detection rate being lower than a preset threshold, or the abnormal sample hit rate being higher than a threshold, or at least one of the following changes occurring: process batch, machine, formula version, and layer. When the hit rate of the abnormal samples is lower than the threshold and the budget becomes tight, the weight of the new class sensitivity item is reduced, and a step-by-step update method is adopted to limit the range of weight fluctuation.

8. The task execution method for an intelligent agent according to claim 5, characterized in that, When executing the structured execution plan, the method further includes: The manual review operation is modeled as an explicit execution node and incorporated into the node dependency relationship of the structured execution plan for unified scheduling. The explicit execution node includes automatic processing nodes and manual review nodes. The manual review node is triggered, assigned, and verifies results based on the formal constraint specifications, and selects between single-person review mode, dual-person independent review mode, and expert arbitration mode according to a preset collaborative strategy. During execution, the manual review node generates corresponding evidence objects and establishes a binding relationship with the nodes in the structured execution plan.

9. The task execution method for an intelligent agent according to claim 5, characterized in that, The method further includes: Based on the review conclusion of the defect review task, at least one of the training sample set, the difficult example sample pool, and the unknown class candidate set is incrementally updated, and the model parameters, classification threshold, and rule base are updated accordingly. The parameter value range in the formal constraint specification is adjusted based on the updated classification threshold.

10. An intelligent agent, characterized in that, include: The plan generation and compilation module is used to, in response to receiving an evidence task package, generate an original plan based on the evidence task package and its corresponding formal constraint specifications, and compile the original plan into a structured execution plan; wherein, the structured execution plan includes explicit execution nodes and dependencies between nodes; the compilation method includes at least one of the following: a compilation method based on template matching and slot filling, a compilation method based on abstract syntax tree parsing and transformation, a compilation method based on graph reconstruction and topology analysis, and a compilation method based on atomic operation extraction and dependency construction; The static verification module is used to perform static verification on the structured execution plan based on the formal constraint specification. An execution scheduling module is used to schedule the execution of the structured execution plan after the static verification is passed; wherein, the structured execution plan is driven by the evidence information encapsulated in the evidence task package; The evidence recording and result output module is used to record evidence information when executing the structured execution plan and output the task execution result including the evidence information; The static verification module is specifically used to: perform at least one of the following checks on the structured execution plan based on the formal constraint specifications: tool validity verification, dependency topology verification, data permission verification, parameter validity verification, output contract satisfiability verification, and evidence generation capability verification; when the static verification fails, the structured execution plan is rejected from execution, and the structured execution plan is modified based on the verification failure result to ensure that the structured execution plan meets the formal constraint specifications; wherein, for parameter validity verification failure, parameter values ​​exceeding the valid domain are corrected to the value range defined by the formal constraint specifications; for tool validity verification failure, a replacement tool that meets the dependency requirements is reselected based on the formal constraint specifications, and the tool identifier and interface contract of the corresponding node are updated; for dependency topology verification failure, the data flow connection or control flow order between nodes is adjusted to eliminate circular dependencies, missing prerequisites, or timing conflicts; The static verification module is further configured to: re-perform static verification on the modified structured execution plan; wherein the re-performed static verification includes full static verification or incremental static verification on the relevant dimensions involved in the modification.

11. An electronic device, characterized in that, include: A processor, a memory, and a communication bus, wherein the processor and the memory communicate with each other via the communication bus; The memory stores program instructions that can be executed by the processor, and the processor can execute the method as described in any one of claims 1 to 9 by calling the program instructions.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a computer, cause the computer to perform the method as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 9.

Images