Intelligent agent security execution control method and system

Abstract

The invention discloses an agent security execution control method and system, and relates to the technical field of artificial intelligence, and the method comprises the following steps: receiving a natural language input of a user, analyzing a spoken language demand into a structured design intention expression through an intention analysis agent, and obtaining a structured design intention expression; the design intention representation at least comprises a target entity, an operation constraint and an acceptance condition; on the basis of the design intention representation, relevant context information is retrieved from design data and a rule base through a retrieval enhancement agent until the retrieval coverage degree and the key anchor point positioning confidence degree reach preset threshold values; by introducing multi-agent cooperation and a natural language driven normal form, a DFT design process is upgraded from tedious and error-prone manual script writing to an intention-driven automatic closed loop. The system can automatically analyze the spoken requirements of the user, intelligently retrieve the design context and generate an interpretable and rollback execution plan, so that engineers are liberated from underlying commands and primitive operations, and the design efficiency is remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of artificial intelligence, and more particularly, to an agent security execution control method and system. BACKGROUND

[0002] With the integrated circuit process entering the nanometer scale, the complexity of SoC design grows exponentially, and its design for test (DFT) has become a crucial and extremely tedious link in the chip development process. In modern DFT implementation, engineers need to configure multiple subsystems such as test access network (TAM), streaming scan network (SSN), embedded deterministic compression (EDT), on-chip clock controller (OCC), built-in self-test (MBIST / LBIST), and boundary scan (JTAG / IJTAG) in coordination. These subsystems do not work independently, but are a highly coupled parameter system. For example, the channel width of SSN must cover the total width of the scan chain, the compression ratio of EDT must match the number of chains, and the capture pulse window of OCC must be strictly aligned with the synchronization requirements across clock domains or across chiplets. Any mismatch of parameters can cause difficult-to-debug faults in the automatic test pattern generation (ATPG) or simulation stage, resulting in huge rework costs.

[0003] To address this challenge, existing technical solutions mainly rely on the following two paradigms, but they both have significant limitations: Currently, the industry generally uses a script language-based (such as Tcl, Shell) approach to drive commercial DFT EDA tools (such as Synopsys TestMAX, Siemens Tessent) for design. Although some tools provide a graphical user interface (GUI) to assist with connection and configuration, they still essentially do not deviate from the pattern of "engineers breaking down high-level design intentions into low-level, discrete EDA commands or graph operations." This pattern has the following core problems: Low efficiency and prone to errors: Engineers must accurately remember and write a large number of script commands, or perform tedious graphical dragging and parameter filling. A simple intention (such as "create an SSN path across three chiplets") needs to be broken down into dozens of steps, the process is tedious and prone to human errors.

[0004] Contextual fragmentation and modification difficulty: DFT configuration information is scattered in RTL, netlist, constraint files (SDC), physical design files (LEF / DEF), and multiple scripts. When a modification is needed, engineers need to manually ensure the synchronous update of all related files and scripts, lack a global view, leading to "one change affecting the whole system," and change consistency is difficult to guarantee.

[0005] Post-execution risk: The written scripts are usually directly run in the real EDA tool environment. Due to the lack of effective pre-execution verification means, logical errors, parameter conflicts or insufficient permissions in the script will only be exposed at runtime, which may cause process interruption or even damage the design database, completely postposing the risk on the critical path of the development process.

[0006] Primary automation and intelligent assistant tools: In recent years, with the development of artificial intelligence technology, some technologies have emerged to apply natural language processing (NLP) or large language models (LLM) to code or script generation. However, when these technologies are directly applied to the highly specialized and strongly constrained field of DFT, new problems are exposed: Lack of domain knowledge and context awareness: general code generation models lack deep DFT domain knowledge and cannot understand the complex engineering constraints between SSN, EDT, OCC and other components. The generated scripts may be grammatically correct, but semantically and logically violate DFT design rules, such as generating bit width mismatch, link unreachable or timing violation.

[0007] “Black box” generation and uncontrollability: LLM directly generates scripts as a “black box” process, lacking an interpretable plan and transparent decision-making process. Engineers cannot review, understand and adjust the specific operation steps before script execution, losing control over critical processes, which is unacceptable in high-security chip design.

[0008] Lack of execution security and audit mechanism: such solutions usually only focus on “generation” and ignore “safe execution” and “post-audit”. They do not integrate a sandbox environment for dry run, do not perform sensitivity grading and permission checking on commands, and cannot provide accurate rollback mechanism and complete audit tracking when errors occur, failing to meet the requirements of reliability, security and compliance for industrial applications.

[0009] In summary, existing technologies are either too low-level and tedious, leading to low efficiency and human errors, or too general and “black box”, failing to meet the professional constraints and safe execution requirements of the DFT field. Currently, the industry urgently needs an end-to-end DFT design solution that can improve automation while ensuring safe, controllable and auditable execution process. SUMMARY

[0010] To overcome the above-mentioned defects of the prior art, embodiments of the present application provide an intelligent agent safe execution control method and system, which upgrades the DFT design process from tedious and error-prone manual script writing to intent-driven automation closed loop by introducing multi-agent collaboration and natural language driven paradigm.

[0011] To achieve the above object, the present application provides the following technical solutions: An agent security execution control method, comprising the following steps: receiving a natural language input of a user, parsing the spoken demand into a structured design intent representation by an intent analysis agent, the design intent representation at least containing target entities, operation constraints and acceptance conditions; based on the design intent representation, retrieving relevant context information from a design data and rule base by a retrieval enhancement agent until the retrieval coverage and key anchor point positioning confidence reach a preset threshold; taking the design intent representation and the retrieved context information as input, generating an object plan tree by a plan tree arrangement engine, the object plan tree comprising a plurality of nodes, each node representing an executable operation and being marked with dependency relationship, rollback point, operation sensitivity and required permission; mapping the object plan tree into a graphical editor to be displayed in a tentative change form and synchronously generating an executable script preview; performing command verification and permission verification on each node in the object plan tree and performing Dry-Run pre-execution analysis in a sandbox environment to output impact assessment and risk score; based on user confirmation, executing the object plan tree in the sandbox environment with minimum step length, collecting execution log and performance index in real time and reconciling with the pre-execution analysis result; performing consistency verification according to the reconciliation result, triggering a self-repair mechanism to rollback to the nearest rollback point and re-retrieve or modify the plan tree if the acceptance condition is not passed; when the execution is passed, generating an audit package, the audit package comprising design intent, object plan tree, execution script, log, report and environment fingerprint for full-link traceability and rollback.

[0012] In a preferred embodiment, the retrieval of relevant context information from the design data and rule base by the retrieval enhancement agent specifically comprises: constructing semantic embedding index and hierarchical symbolic graph index for vectorized retrieval of design entities and structured relationships respectively; based on the entities and constraints in the design intent representation, preferentially retrieving the most relevant RTL, Netlist, SDC, LEF / DEF file fragments and historical scripts; calculating the retrieval coverage and key anchor point positioning confidence in real time, if the threshold is not reached, adaptively expanding the retrieval radius along the module level, clock domain or chip grain boundary; stopping the retrieval when the coverage and confidence both reach the threshold, and outputting the plan anchor point set bound with context.

[0013] In a preferred embodiment, the object plan tree is generated by the plan tree orchestration engine, specifically: the design intent representation is decomposed into atomic operation nodes, each node including a unique identifier, an operation type, a parameter list, a list of dependent nodes, a rollback action, and required permissions; a directed acyclic graph structure is constructed according to operation dependency relationships, and a rollback point is injected, which supports minimum granularity rollback; each node is labeled with an operation sensitivity level, including read-only, overwrite, and potentially destructive; the consistency of node parameters and constraints is verified based on a rule base, and an executable object plan tree is output.

[0014] In a preferred embodiment, the object plan tree is mapped into a graphical editor for visual display in a proposed change form, and an executable script preview is generated synchronously, specifically: in the graphical editor canvas, newly added, modified, or deleted primitives and connections are highlighted, and parameter changes are annotated; any manual adjustments on the canvas are written back to the object plan tree and script preview in real time, maintaining consistency among the graph, plan, and script; the script preview view and the graphical view are displayed side by side, supporting line-by-line checking of command syntax and execution order; after parameter adjustment, in-place verification is triggered, and rule conflicts and impact ranges are annotated in real time.

[0015] In a preferred embodiment, each node in the object plan tree is subjected to command verification and permission verification, specifically: using a rule base to perform syntax checking, parameter domain verification, and cross-domain consistency verification on the command template; based on the RBAC model, user permissions are verified, and if the required permissions are missing, a permission application request is automatically generated and execution is suspended; the sensitivity of the command is evaluated, and secondary confirmation or multi-level approval is required for high-sensitivity operations; a verification result list is output, including pass, warning, or block status.

[0016] In a preferred embodiment, the object plan tree is executed in a sandbox environment with minimum steps, specifically: the object plan tree is split into a sequence of minimum executable units based on dependency relationships; each unit is executed in an isolated sandbox with minimum permission accounts, and the operation context and output are recorded; the execution results are compared with Dry-Run predictions in real time, differences are marked and alarms are triggered; if a unit fails to execute, it is automatically rolled back to the nearest rollback point, and a repair suggestion is generated.

[0017] In a preferred embodiment, a self-repair mechanism is triggered to roll back to the nearest rollback point and re-retrieve or correct the plan tree, specifically: the type of execution error is analyzed, including parameter mismatch, link unclosed loop, or insufficient permissions; for automatically repairable errors, a minimum change patch is generated based on the rule base, and the object plan tree is updated; for errors that require human intervention, a diagnostic report and repair guide are output to guide the user to make adjustments; after repair, Dry-Run is re-triggered until consistency verification is passed.

[0018] In a preferred embodiment, the generation of the audit package, in particular: concatenating natural language input, object plan tree, command sequence, execution log, report and environment fingerprint, forming a timestamp sequence; fingerprinting the audit content using a hash chain or Merkle tree to ensure data integrity and tamper resistance; storing the audit package to the version database, supporting query by time point, user or change content; when rolling back, quickly restoring the engineering state based on the rollback point in the audit package and the environment fingerprint.

[0019] The technical effects and advantages of the intelligent agent safe execution control method and system of the present application are as follows: The present application introduces multi-agent collaboration and natural language driven paradigm, upgrades the DFT design process from tedious and error-prone manual script writing to intent-driven automation closed loop. The system can automatically analyze user's colloquial requirements, intelligently retrieve design context, and generate executable and rollbackable execution plan, so as to free engineers from low-level commands and graphic operations, significantly improve design efficiency, and shorten the end-to-end DFT implementation period from man-day to man-week level to hour level. At the same time, the bidirectional real-time linkage of graphical interface and natural language ensures the consistency of design intent and physical implementation, and eliminates parameter errors and consistency conflicts caused by human negligence or information asynchronization from the source.

[0020] The present application constructs a safe execution control system with Dry-Run preview, sandbox execution and full-link audit as the core, fundamentally changes the passive situation of traditional script execution risk postposition. Through comprehensive impact assessment, command verification and permission review before real execution, the system can intercept more than 95% of potential errors in advance. Through execution in isolated sandbox with minimum step and real-time reconciliation, it realizes rapid positioning and accurate rollback of faults, greatly reduces the risk of destructive operations. Finally, the complete audit package and hash chain fingerprint ensure the full traceability and reproducibility of each change, providing strong technical support for team collaboration, compliance review and problem tracing, realizing the unity of efficiency and reliability. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 The intelligent agent safe execution control method flowchart of the intelligent agent safe execution control method of the present application.

[0022] Figure 2 The intelligent agent safe execution control system architecture diagram of the intelligent agent safe execution control system of the present application. DETAILED DESCRIPTION

[0023] With reference to the drawings and embodiments of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by a person of ordinary skill in the art without creative effort are within the scope of the present application.

[0024] Embodiment 1, Figure 1 An intelligent agent security execution control method is given, comprising the following steps: Receiving natural language input of a user, and parsing the spoken demand into a structured design intent representation through an intent analysis intelligent agent, the design intent representation at least containing a target entity, an operation constraint and an acceptance condition; Based on the design intent representation, retrieving relevant context information from a design data and a rule base through a retrieval enhancement intelligent agent until a preset threshold of retrieval coverage and key anchor point positioning confidence is reached; Retrieving relevant context information from a design data and a rule base through a retrieval enhancement intelligent agent, specifically: constructing a semantic embedding index and a hierarchical symbolic graph index, which are respectively used for vectorizing retrieval of design entities and structured relationships; based on the entity and the constraint in the design intent representation, preferentially retrieving the most relevant RTL, Netlist, SDC, LEF / DEF file fragments and historical scripts; calculating the retrieval coverage and the key anchor point positioning confidence in real time, if the threshold is not reached, then adaptively expanding the retrieval radius along the module level, the clock domain or the chip grain boundary; stopping the retrieval when both the coverage and the confidence reach the threshold, and outputting a plan anchor point set bound with the context.

[0025] It should be noted that the core work of the retrieval enhancement intelligent agent is based on the construction of a double-index system, which provides structural support for precise and efficient context retrieval. Among them, the semantic embedding index realizes the vectorization retrieval of unstructured or semi-structured design information by converting design entities (such as chip modules, circuit units, etc.) into high-dimensional vectors, which can break through the limitations of traditional keyword retrieval and accurately match entities related to the semantics of the design intent; the hierarchical symbolic graph index focuses on the association between design elements, and combs logical links such as module affiliation and signal flow direction in a structured way to ensure that key entity interaction information is not missed in the retrieval process. The two indexes do not operate independently, but form a synergy based on a preset design rule base, the former is responsible for positioning core entities, and the latter is responsible for restoring the relationship context, which together provide comprehensive index protection for subsequent retrieval.

[0026] The priority strategy of the retrieval process directly determines the relevance and practicality of the contextual information. Instead of blindly traversing the database, the agent locks the core file fragments and historical data most relevant to the current design task as the retrieval anchor point based on the target entity and operation constraints in the design intent representation. Among them, the RTL (Register Transfer Level) file is the core carrier of circuit logic design, the Netlist (Netlist) reflects the actual circuit connection relationship, the SDC (Timing Constraint File) defines the timing requirements of the design, and the LEF / DEF file associates the library information and layout constraints of physical implementation. These files directly determine whether the design intent can be implemented; the historical script contains practical experience of similar design tasks, which can reduce the cost of repeated trial and error. Prior retrieval of these contents can grasp the core context at the initial stage of retrieval, avoid irrelevant information interference, and improve retrieval efficiency.

[0027] The dynamic optimization mechanism and result output standard of retrieval ensure the integrity and reliability of the contextual information. The agent establishes a quantitative evaluation standard for retrieval quality by calculating the retrieval coverage (the proportion of the retrieved information to the design intent) and the key anchor point location reliability (the matching accuracy probability of the core entity and relationship) in real time. When any indicator does not meet the pre-set threshold, the system will adaptively expand the retrieval radius along the module level (from sub-module to parent module), clock domain (according to signal synchronization range), or core particle boundary (physical and logical division in multi-core particle design). This expansion is not a boundaryless expansion, but based on the inherent structural dimensions of chip design, which ensures the pertinence of the retrieval range and avoids retrieval redundancy. Only when both indicators meet the requirements, the retrieval will stop, and the final output is the plan anchor set that binds the context, which deeply associates the design intent with the retrieved core file and relationship information, providing accurate and complete context support for the generation of object plan trees.

[0028] Taking the design intent representation and the retrieved contextual information as input, the object plan tree is generated by the plan tree arrangement engine. The object plan tree includes multiple nodes, each node representing an executable operation and marking the dependency relationship, rollback point, operation sensitivity, and required permissions. The object plan tree is generated by the plan tree arrangement engine, specifically: the design intent representation is decomposed into atomic operation nodes, each node including a unique identifier, operation type, parameter list, dependent node list, rollback action, and required permissions; a directed acyclic graph structure is constructed according to the operation dependency relationship, and rollback points are injected, which support the smallest granularity rollback; each node is marked with an operation sensitivity level, including read-only, rewrite, and potentially destructive; the consistency of node parameters and constraints is verified based on the rule base, and the executable object plan tree is output.

[0029] It should be noted that the first step of the plan tree arrangement engine to generate the object plan tree is to convert the abstract design intent representation into a deployable atomic operation node. This process realizes the accurate disassembly of design requirements to execution units. Each atomic operation node has standardized core elements: a unique identifier for tracking the execution status and log attribution of the operation throughout the process; an operation type that clearly defines specific actions such as inserting a scanning unit to modify timing constraints, providing a basis for subsequent command generation; a parameter list that refines the specific indicators of the operation, such as the bit width of the scanning unit and the time threshold of the constraint; a dependency node list that defines the preconditions of the operation to avoid logical conflicts; a rollback action that defines the recovery plan after operation failure, which is the basis for subsequent self-repair mechanisms; and required permissions that specify the access qualifications required to execute the operation, which form a link with subsequent permission verification. This detailed node definition ensures the independence and traceability of each operation unit, laying the foundation for reliable execution of the plan tree.

[0030] Building a directed acyclic graph (DAG) structure based on atomic operation nodes and completing multi-dimensional labeling is the core design to achieve ordered execution of operations and controllable risks. The engine automatically sorts the logic relationship of first execution and then execution according to the dependency node list of each node, builds a non-cyclic DAG structure, and fundamentally avoids design errors caused by operation order confusion. The rollback point is not randomly set, but is set in front of key branch nodes or high-risk operations based on operation sensitivity and dependency, supporting the rollback of only the minimum set of fault-associated operations, rather than full rollback, which greatly improves fault repair efficiency. The labeling of operation sensitivity levels establishes a risk grading mechanism: read-only operations have no modification risk, rewrite operations involve design content changes but have controllable impact, and potentially destructive operations (such as deleting core modules) require strict verification and approval, which provides clear evidence for risk management in subsequent execution steps.

[0031] Rule-based parameter and constraint consistency verification is a key closed-loop step to ensure that the object plan tree is executable and conflict-free. The engine calls the pre-set design rule library to perform double verification on the parameters of each node: first, the legality of the parameters, such as whether the numerical value is within the process allowed range and whether the naming conforms to the design specification; second, the consistency of cross-node constraints, such as the clock frequency set by a node, which needs to match the timing constraints of other related nodes to avoid local parameter rationality but global conflict. This verification process is not isolated to a single node, but is combined with the context information provided by the enhanced intelligent agent to ensure that the parameter settings fit the actual scenario of the current design, such as referring to the parameter range of similar chip designs to avoid invalid planning that deviates from engineering reality. The final output object plan tree is not only an ordered set of operations, but also a reliable solution that has passed rule verification and conforms to design specifications, which can be directly converted into execution commands, realizing seamless connection from design intent to execution plan.

[0032] The object plan tree is mapped to the graphical editor to be changed in the form of visual display, and an executable script preview is generated synchronously; The object plan tree is mapped to the graphical editor to be changed in the form of visual display, and an executable script preview is generated synchronously, specifically: the newly added, modified or deleted primitives and connections in the graphical editor canvas are highlighted, and the parameter changes are marked; any manual adjustment on the canvas is written back to the object plan tree and the script preview in real time, keeping the consistency of the three states of graph-plan-script; the script preview view and the graph view are displayed side by side, supporting line-by-line checking of command syntax and execution order; after parameter adjustment, on-the-spot checking is triggered, and real-time marking of rule conflicts and impact range is performed.

[0033] The mapping core of the object plan tree to the graphical editor is to convert abstract operation nodes into intuitive change visualization content, eliminating the cognitive barriers between engineers and execution plans. The graphical editor is not simply a list of primitives, but accurately distinguishes the types of design changes through highlighting markers - newly added primitives and connections are marked with eye-catching colors, modified parts show the parameter differences before and after with contrasting colors, and deleted content is shown with a semi-transparent deletion line style, ensuring that each change is clear and identifiable. This presentation converts structured information such as operation type parameter lists in the plan tree into graphical language familiar to engineers, eliminating the need to interpret complex node logic and quickly locating the core of the change to provide intuitive evidence for manual review.

[0034] The three-state consistent bidirectional linkage mechanism of graph-plan-script is the key innovation to ensure accurate transmission of design intent. When engineers manually adjust primitive positions, modify parameters or add or delete connections on the canvas, the system will write these operations back to the corresponding nodes of the object plan tree in real time - for example, adjusting the timing parameters of a module will update the parameter list of the node in the plan tree simultaneously; deleting a signal connection will mark the change of the corresponding dependency relationship in the plan tree. At the same time, the script preview view will automatically refresh with the update of the plan tree, ensuring that the logic and parameters of the three of graph operation, plan node and execution script are completely matched. This linkage avoids the problem of script missing changes in traditional design, which is out of sync with actual operations, and ensures information synchronization at the tool level.

[0035] The parameter-adjusted in-place verification mechanism realizes early detection and early warning of design errors, and improves the risk interception capability before execution. After the engineer completes the parameter modification on the graphical interface, the system will immediately call the preset design rule library to perform real-time verification on the adjusted parameters. If the modified clock frequency exceeds the upper limit of the chip process, a warning will be marked next to the parameter input box and a reasonable range will be prompted. If the interface of the newly added module does not match the associated unit, the corresponding connection will be highlighted and the conflict reason will be explained. This verification is not independent of the editing process, but is real-time bound with the operation. At the same time, the script preview view will be annotated with syntax errors or execution order problems, so that the engineer can obtain the verification result while completing the editing, without the need to trigger the verification process additionally, which not only improves the efficiency, but also reduces the possibility of errors flowing into the subsequent links.

[0036] Command verification and permission verification are performed on each node in the object plan tree, and Dry-Run pre-execution analysis is performed in a sandbox environment to output impact assessment and risk score; Command verification and permission verification are performed on each node in the object plan tree, and Dry-Run pre-execution analysis is performed in a sandbox environment to output impact assessment and risk score;

[0037] It should be noted that: command verification is supported by rule library as the core, which ensures the legality and feasibility of object plan tree node command through multi-dimensional verification, and intercepts syntax and logic errors from the source. The verification process is not a single format check, but a full-chain verification covering syntax-parameters-cross-domain: syntax checking is based on command templates in the design field to identify basic problems such as command keyword errors and format disorder; parameter domain verification combines the process specifications and module performance upper limit of chip design to determine whether the parameters are within a reasonable range, such as avoiding clock frequency parameters exceeding the carrying capacity of chip process; cross-domain consistency verification is a key extension that associates command parameters of different modules to prevent single-module parameter legal but multi-module coordination conflict problems, such as the signal output parameter of a node needs to match the input parameter of the receiving node. This multi-dimensional verification upgrades the command from formal legality to actual availability.

[0038] The permission check is based on the RBAC (Role-Based Access Control) model to build a hierarchical control system, and at the same time, the risk is differentiated through the sensitivity association to strengthen the execution security. The RBAC model binds the user role with the operation permission, accurately judges whether the current user has the required permission of the node, and if the user role does not cover the operation permission, the system will automatically generate a standardized permission application request, and at the same time, suspend the execution process to avoid unauthorized operation. On this basis, the system combines the operation sensitivity level marked by the node, and starts additional control for rewriting, especially high-sensitivity operations that may be potentially destructive, and requires secondary confirmation or multi-level approval. For example, the operation of deleting the core netlist needs to be approved by the project manager and the technical director. This combination of permission check and sensitivity grading not only guarantees the compliance of the operation, but also focuses on the prevention and control of high-risk behaviors.

[0039] The check result is clearly output in the form of a list, and the subsequent execution process is accurately guided through clear state identifiers, forming a closed loop of check-feedback-processing. The list corresponds to different risk levels and processing strategies through three states of warning, blocking and passing. Passing means that the command and permission fully meet the requirements, and the next execution link can be entered. Warning is for non-fatal problems, such as parameters close to the process upper limit but not exceeding, which need to be confirmed by the engineer before continuing to execute. Blocking corresponds to fatal errors, such as command syntax errors, permission missing and temporary authorization, which directly terminate the execution process. This visual result presentation allows engineers to quickly locate the problem without checking each node, and provides a clear direction for problem solving, improving the practical value of the check link.

[0040] Based on user confirmation, the object plan tree is executed in a sandbox environment with the smallest step, real-time collection of execution logs and performance indicators, and reconciliation with pre-execution analysis results; The object plan tree is executed in a sandbox environment with the smallest step, which is to split the object plan tree into the smallest executable unit sequence according to the dependency relationship; execute each unit in isolation in the sandbox with the smallest permission account, and record the operation context and output; real-time comparison of execution results and Dry-Run prediction, marking differences and triggering alarms; if the unit execution fails, automatically rollback to the nearest rollback point, and generate repair suggestions.

[0041] It should be noted that the pre-key step of sandbox execution is to disassemble the object plan tree into the sequence of the smallest executable unit according to the dependency relationship, and this disassembly logic directly determines the order of execution and the accuracy of fault positioning. The nodes in the object plan tree have explicit dependency relationships (such as B node can start after A node execution is completed), and the engine will traverse the directed acyclic graph structure based on this relationship to combine the inseparable associated operations into the smallest unit - for example, the read timing constraint + the generation of the scan chain is grouped into a unit due to strong dependency, while the unrelated initialization log module is independently grouped into a single unit. This splitting not only ensures the logical coherence of the operations within the unit, but also arranges the order between units to follow the dependency rules, laying the foundation for subsequent step-by-step execution and fault positioning, and avoiding the problem of ambiguous fault points caused by overall execution.

[0042] The dual protection of isolated environment and minimum authority is the core design of the safety and controllability of sandbox execution. The minimum authority account used in the execution process only has the basic authority required for the current unit execution, and cannot access unrelated design data or perform operations beyond the scope, thereby blocking the impact of misoperations on the core design from the permission level; the isolated sandbox builds a virtual space consistent with but completely independent of the real design environment, and all modifications generated by unit execution are limited within the sandbox and will not cause any irreversible impact on the external design database. In terms of execution order, the agent will start in sequence according to the unit sequence, while recording the operation context (such as execution time, called resources, parameter input) and output result (such as generated intermediate file, status feedback code) of each unit in real time, providing complete data support for subsequent reconciliation.

[0043] Real-time comparison and failure rollback mechanism form a risk interception closed loop of sandbox execution. During the execution of each unit, the system will compare the real-time output results with the predicted results of the Dry-Run pre-execution analysis field by field, and if there are differences such as parameter deviation and status code mismatch, it will immediately mark the exception and trigger an alarm, and engineers can intervene to view the difference details in real time. When the unit execution fails explicitly (such as the command cannot be run, the output result is invalid), the system will automatically trigger the rollback process - based on the rollback point information marked in the object plan tree, it will accurately roll back to the nearest stable state before the execution of this unit, avoiding the spread of faults to subsequent units. At the same time, combined with the execution log and rule library of this unit, it intelligently generates repair suggestions, such as parameter format error, and suggests adjusting the timing threshold according to the SDC file, providing direction for quickly solving the problem.

[0044] According to the reconciliation results, perform consistency check, if it does not pass the acceptance conditions, trigger the self-repair mechanism, roll back to the nearest rollback point and re-search or correct the plan tree; Triggering the self-repair mechanism, rolling back to the last rollback point and re-retrieving or correcting the plan tree, specifically: analyzing the execution error type, including parameter mismatch, link unclosed loop or insufficient permissions; for errors that can be automatically repaired, generate a minimum change patch based on the rule library and update the object plan tree; for errors that require human intervention, output a diagnostic report and repair guide to guide the user to adjust; after repair, re-trigger the Dry-Run preview until it passes the consistency check.

[0045] It should be noted that the start of the self-repair mechanism is the accurate classification and root location of the execution error, which is the basis for targeted repair. Instead of simply identifying the result of execution failure, the system combines sandbox execution logs, operation context and pre-execution analysis data to decompose error types into three core scenarios: parameter mismatch (such as actual input parameter format conflict with design rules), link unclosed loop (such as missing signal transmission path between modules leading to execution interruption), insufficient permissions (temporary permissions in sandbox execution do not cover operation requirements). Each error type corresponds to a specific diagnostic dimension - for example, parameter mismatch will associate rule library verification records to locate conflicting fields, and link unclosed loop will trace back to the broken node through hierarchical symbol graph indexing. This accurate classification avoids blind repair and provides a clear direction for subsequent processing.

[0046] Based on the hierarchical repair strategy of error types, the system realizes the organic combination of automated efficient processing and manual intervention precise filling. For errors that can be automatically repaired (such as parameter format error, simple link missing), the system calls the repair template in the rule library to generate a minimum change patch - that is, only modify the error associated parameters or nodes, without touching other normal modules, for example, automatically convert string format timing parameters to numerical format required by the rules, and update the corresponding node information of the object plan tree; for errors beyond the scope of automated repair (such as core module logic conflict, permission application rejected), output a structured diagnostic report, clearly marking the error location, impact range and associated design files, and providing a repair guide (such as suggesting to refer to the Netlist file 3rd paragraph to adjust module interface), guiding engineers to focus on key issues, avoiding repeated troubleshooting, balancing repair efficiency and reliability.

[0047] The verification closed-loop mechanism after repair ensures that the self-repair result meets the design requirements and avoids introducing new errors when repairing old errors. Regardless of automatic repair or manual repair, the system will forcibly trigger the Dry-Run pre-execution analysis again, compare the repaired object plan tree with the design intent representation and retrieve the context information, and focus on verifying the parameter consistency, link integrity and permission adaptability of the repaired part. During the pre-execution process, the execution feasibility and risk score will be recalculated. If it still fails the consistency check, it will return to the error analysis link, supplement the diagnosis dimensions based on the new execution data, and adjust the repair strategy. Only when the pre-execution analysis result completely meets the acceptance conditions and the risk score is lower than the preset threshold, the verification closed loop will end, and the repaired plan tree can re-enter the sandbox execution process, forming a complete closed loop of error analysis-repair-verification.

[0048] When the execution is passed, an audit package is generated, which includes design intent, object plan tree, execution script, log, report and environment fingerprint, for full-link traceability and rollback.

[0049] An audit package is generated, specifically: concatenate natural language input, object plan tree, command sequence, execution log, report and environment fingerprint to form a timestamp sequence; use hash chain or Merkle tree to fingerprint the audit content to ensure data integrity and tamper resistance; store the audit package in the version database to support query by time point, user or change content; when rolling back, quickly restore the engineering state based on the rollback point and environment fingerprint in the audit package.

[0050] It should be noted that: the core construction logic of the audit package is full-link information concatenation. Through the timestamp sequence, the key data of the whole process of agent execution forms a complete traceability chain. The audit package is not a pile of scattered information, but starts with user natural language input, and then includes object plan tree (execution blueprint), command sequence (execution instruction), execution log (process record), report (result output) and environment fingerprint (execution background) in turn, each link is attached with accurate timestamp. This concatenation method makes the link of demand-plan-execution-result clear and traceable. For example, through the timestamp, you can locate the source of the design intent corresponding to a certain execution command, or the log record corresponding to a certain report data, completely solving the traceability problem caused by information breakpoints in traditional execution process.

[0051] The fingerprinting process of the hash chain or the Merkle tree provides the audit package with tamper-proof integrity assurance, which is the key to the legal effectiveness and trust basis of the audit package. The system generates a unique hash value for each type of core information (such as the plan tree and the log) in the audit package, and then concatenates the hash values through the hash chain - the hash value of the previous piece of information is used as the calculation input of the next piece of information, or a hierarchical hash structure is constructed through the Merkle tree. This processing method makes any modification of the content in the audit package cause significant changes in the corresponding hash value, and it is impossible to cover up the traces by tampering with local data. Engineers or auditors can quickly verify whether the audit content has been tampered with by recalculating the hash value and comparing it with the original record, ensuring the authenticity of the data.

[0052] The storage design and rollback application of the audit package realize the practical value of traceability and quick recovery. The system stores the generated audit package in the version database, supports multi-dimensional query and retrieval - according to the time point, the execution of the whole process at a certain time can be located, according to the user, the operation records of a specific engineer can be traced, according to the change content, all audit information related to a certain type of design modification can be screened, which greatly improves the problem positioning efficiency in team collaboration. When rollback is needed, the value of the audit package is particularly prominent: the environmental fingerprint can accurately restore the execution environment configuration (such as software version, hardware parameter) at that time, and the rollback point information clearly indicates the target node of recovery, combined with the plan tree and the log in the audit package, the system can bypass the invalid execution steps and directly restore the engineering state to the target stage, avoiding the efficiency loss caused by full rollback.

[0053] Embodiment 2, Figure 2 The intelligent agent safety execution control system is given, which comprises an intention analysis module, a retrieval enhancement module, a plan arrangement module, a graphical collaboration module, a verification module, a sandbox execution module and an audit module: The intention analysis module is used for receiving natural language input and analyzing it into a structured design intention representation; The retrieval enhancement module is used for retrieving context information from the design data and the rule base until the coverage and confidence reach the threshold; The plan arrangement module is used for generating an object plan tree and marking dependencies, rollback points, sensitivity and permissions; The graphical collaboration module is used for visualizing the proposed changes and script preview, and supports canvas and plan tree bidirectional linkage; The verification module is used for executing command verification, permission verification and consistency verification; The sandbox execution module is used for executing the plan tree in the smallest step and performing real-time reconciliation; The audit module is used for generating an audit package, supporting traceability and rollback.

[0054] The above-described embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, the above-described embodiments can be implemented in whole or in part in the form of a computer program product.

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

[0056] In addition, each functional module in each embodiment of the present application can be integrated in one processing module, or each module can exist physically alone, or two or more modules can be integrated in one module.

[0057] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0058] Finally: the above is only the preferred embodiment of the present application, and is not used to limit the present application. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. An agent security enforcement control method, characterized by, The method comprises the following steps: Receiving natural language input of a user, parsing the spoken requirement into a structured design intent representation by an intent parsing agent, the design intent representation containing at least target entities, operation constraints and acceptance conditions; Based on the design intent representation, retrieving relevant context information from a design data and rule base by a retrieval enhancement agent until the retrieval coverage and key anchor location confidence reach preset thresholds; Taking the design intent representation and the retrieved context information as input, generating an object plan tree by a plan tree orchestration engine, the object plan tree comprising multiple nodes, each node representing an executable operation and being marked with dependency relationship, rollback point, operation sensitivity and required permissions; Mapping the object plan tree into a graphical editor to visually display in the form of proposed changes and synchronously generate an executable script preview; Performing command verification and permission verification on each node in the object plan tree and Dry-Run pre-execution analysis in a sandbox environment to output impact assessment and risk score; Based on user confirmation, executing the object plan tree in the sandbox environment with minimum steps, collecting execution logs and performance indicators in real time and reconciling with the pre-execution analysis results; According to the reconciliation results, performing consistency verification, triggering a self-repair mechanism to rollback to the nearest rollback point and re-retrieve or correct the plan tree if the acceptance conditions are not passed; When the execution is passed, generating an audit package comprising the design intent, the object plan tree, the execution script, the logs, the report and the environment fingerprint for full-link traceability and rollback.

2. The method of claim 1, wherein, The retrieval enhancement agent retrieves relevant context information from the design data and the rule base, specifically: Building semantic embedding index and hierarchical symbolic graph index for vectorized retrieval of design entities and structured relationships respectively; Based on the entities and constraints in the design intent representation, preferentially retrieving the most relevant RTL, Netlist, SDC, LEF / DEF file fragments and historical scripts; Real-time calculation of retrieval coverage and key anchor location confidence, if the thresholds are not reached, adaptively expanding the retrieval radius along the module level, clock domain or chip grain boundary; Stopping retrieval when both the coverage and the confidence reach the thresholds, outputting the plan anchor set bound with context.

3. The method of claim 2, wherein the method further comprises: The plan tree orchestration engine generates the object plan tree, specifically: Decomposing the design intent representation into atomic operation nodes, each node comprising a unique identifier, operation type, parameter list, dependent node list, rollback action and required permissions; Building a directed acyclic graph structure according to operation dependency relationship and injecting rollback points, the rollback points supporting minimum granularity rollback; Marking each node with operation sensitivity level, including read-only, rewrite and potentially destructive; Based on the rule base, verifying the consistency of node parameters and constraints to output an executable object plan tree.

4. The method of claim 3, wherein, Mapping the object plan tree into a graphical editor to visually display in the form of proposed changes and synchronously generate an executable script preview, specifically: Highlighting the newly added, modified or deleted primitives and connections in the graphical editor canvas and marking parameter changes; Any manual adjustment on the canvas is real-time written back to the object plan tree and script preview, keeping the graph-plan-script tri-state consistent; The script preview view is displayed side by side with the graph view, supporting line-by-line checking of command syntax and execution order; Local verification is triggered after parameter adjustment, real-time marking rule conflicts and impact range.

5. The method of claim 4, wherein, Command verification and permission verification are performed on each node in the object plan tree, specifically: Use the rule library to perform syntax checking, parameter domain verification, and cross-domain consistency verification on the command template; Based on the RBAC model, check user permissions. If the required permissions are missing, automatically generate a permission request and suspend execution; Evaluate command sensitivity. For high-sensitivity operations, enforce secondary confirmation or multi-level approval; Output the verification result list, including pass, warning, or block status.

6. The method of claim 5, wherein the method further comprises: The object plan tree is executed in a sandbox environment with the smallest step size, specifically: Split the object plan tree into the smallest executable unit sequence based on dependencies; Execute each unit in a isolated sandbox with the minimum permission account, and record the operation context and output; Real-time compare the execution result with the Dry-Run prediction, mark the differences and trigger the alarm; If a unit fails to execute, automatically roll back to the nearest rollback point and generate a repair suggestion.

7. The method of claim 6, wherein the method further comprises: The self-repair mechanism is triggered, which rolls back to the nearest rollback point and retrieves or corrects the plan tree, specifically: Analyze the type of execution error, including parameter mismatch, link unclosed, or insufficient permissions; For automatically repairable errors, generate the smallest change patch based on the rule library and update the object plan tree; For errors that require human intervention, output a diagnostic report and repair guide to guide the user to adjust; After repair, re-trigger the Dry-Run preview until it passes the consistency check.

8. The method of claim 7, wherein the method further comprises: The audit package is generated, specifically: String together natural language input, object plan tree, command sequence, execution log, report, and environment fingerprint to form a timestamp sequence; Use a hash chain or Merkle tree to fingerprint the audit content to ensure data integrity and tamper resistance; Store the audit package in the version database, supporting queries by time point, user, or change content; When rolling back, quickly restore the engineering state based on the rollback point and environment fingerprint in the audit package.

9. An agent security execution control system applied to the agent security execution control method of any one of claims 1-8, characterized in that, It includes an intent analysis module, a retrieval enhancement module, a plan arrangement module, a graphical collaboration module, a verification module, a sandbox execution module, and an audit module: The intent analysis module is used to receive natural language input and parse it into a structured design intent representation; The retrieval enhancement module is used to retrieve context information from design data and rule libraries until the coverage and confidence reach the threshold; The plan arrangement module is used to generate an object plan tree and mark dependencies, rollback points, sensitivity, and permissions; The graphical collaboration module is used to visualize the proposed changes and script preview, and supports bidirectional linkage between the canvas and the plan tree; The verification module is used to perform command verification, permission verification, and consistency verification; The sandbox execution module is used to execute the plan tree with the smallest step size and real-time reconciliation; The audit module is used to generate an audit package, supporting traceability and rollback.

Images