Script generation and execution method, device and storage medium

Abstract

The application discloses a script generation and execution method, device and storage medium, and relates to the technical field of large language models. The method comprises the following steps: obtaining a candidate script through employee operation and large language model assistance; deriving multiple groups of test cases from the candidate script and combining the test cases with different large language models to form a differential test combination; performing differential testing to obtain a differential index; if the differential indexes of all differential test combinations are within a preset differential threshold, marking the candidate script as a script to be audited; after auditing and signing the script to be audited, entering a gray state to obtain a target script; performing gray online of the target script on real traffic and continuously comparing the target script with a historical execution mode; when the performance indexes of the target script and the historical execution mode meet preset conditions, promoting the target script to a next gray stage; otherwise, rolling back to a previous stage; and repeating the above steps until the target script is marked as activated, and an activated script is obtained. The application can improve the credibility of a large model generated script.

Description

Technical Field

[0001] This application relates to the field of large language model technology, and in particular to a script generation and execution method, device and storage medium. Background Technology

[0002] Currently, with the maturity of browser automation agents driven by large language models, the description threshold for automation tasks has been significantly reduced. Related technologies typically involve directly generating and executing scripts online using large models. However, due to sampling uncertainties, model version drift, and the risk of illusion, the generated scripts are untested and their correctness cannot be guaranteed, easily leading to the erroneous execution of high-risk operations. Summary of the Invention

[0003] The main purpose of this application is to provide a script generation and execution method, device, and storage medium, aiming to solve the technical problem of unreliable scripts generated from large models.

[0004] To achieve the above objectives, this application provides a script generation and execution method, which includes: Candidate scripts are obtained through the first and second channels. The first channel captures each step of the employee's business process and aligns it with the stable control identifier and navigation edge to obtain candidate scripts. The second channel obtains candidate scripts by reverse lookup after the large language model performs the task for the first time under the constraints of the website's structured knowledge graph. Multiple test cases derived from candidate scripts are combined with multiple different large language models to form differential test combinations, and differential tests are performed on the differential test combinations to obtain differential metrics. If the differential indicators of all differential test combinations are within the preset differential threshold, the candidate script will be marked as a script to be reviewed. In response to the audit labels, risk point confirmations, and electronic signatures of the script to be audited on the audit workbench, the script to be audited enters a grayscale state and is marked as the target script that has passed the audit. The target script is deployed to real traffic in a gray-scale manner according to a preset ratio. During the gray-scale deployment, the performance indicators of the target script are compared with the performance indicators of the historical execution method. If the comparison results of the performance indicators meet the preset judgment conditions, it is promoted to the next gray-scale stage. If the preset judgment conditions are not met, it is rolled back to the previous stage until the full activation state is reached. The target script is then marked as activated and the activated script is obtained.

[0005] In one embodiment, obtaining candidate scripts through a second channel includes: Based on task intent, retrieve the minimum relevant subgraph and the corresponding jump adjacency list from the website's structured knowledge graph, which has a four-layer structure of site, page, block and control as its skeleton. The minimum related subgraph and the jump adjacency list are compactly exported and injected with prompt words in three forms: hierarchical path expansion, jump adjacency list compression, and whitelist subgraph query. After attaching hard constraints to the end of the prompt, the script is generated, and the system-level access control component rejects script products that violate the hard constraints, thus obtaining candidate scripts.

[0006] In one embodiment, after obtaining the activation script, the method further includes: Once the task arrives, the task-level script is retrieved based on the task parameters, and it is determined whether the task-level script is an active script. The script status of the task-level script is obtained, and the path is selected and executed based on the script status and site knowledge completeness to obtain the execution result.

[0007] In one embodiment, after a task arrives, a task-level script is retrieved based on task parameters. Then, a path is selected and executed based on the script status and site knowledge completeness of the task-level script, yielding the execution result, including: The task-level script is retrieved based on the task parameters, and it is determined whether the task-level script is active. The script status of the task-level script is obtained. If the query finds a task-level script and the script status is active, it is executed according to the direct execution path of the task-level script to obtain the execution result. If the query matches a task-level script and the script status is downgraded, execute the task-level script as the main body with additional natural language fallback prompts to obtain the execution result. If no task-level script is found in the query, but the site has structured knowledge, the injection prompt words are retrieved from the site's structured knowledge graph and extracted in a compact manner before execution. The successful execution result is used as a new candidate script to obtain the execution result. If the query does not find a task-level script and the site does not have structured knowledge, it will be executed in natural language mode, and the site will be added to the re-annotation queue to obtain the execution result.

[0008] In one embodiment, execution is performed according to the task-level script direct execution path, and the execution result includes: The business process engine performs business-level decomposition, branch parallelism, timeout retries, compensation rollback, and manual countersigning on business events, resulting in multiple sub-tasks. Subtasks are distributed to the corresponding task-level scripts via standardized interfaces. The task-level scripts decompose the subtasks into single-step atomic actions. The intelligent agent executes the single-step atomic actions to obtain execution status information and returns the execution status information to the business process engine through standardized interfaces. Based on the execution status information, the business process engine will select one of the following to handle the failure: path switching, compensation rollback, manual intervention, or adding the task to the re-labeling queue according to the preset strategy. If a business node involves compliance level or cross-site redirection, the business process engine will force a route to a manual approval node, and continue execution after approval.

[0009] In one embodiment, in response to the audit label, risk point confirmation, and electronic signature of the script to be audited on the audit workbench, the script to be audited enters a grayscale state, resulting in a target script marked as approved, including: The review workbench identifies and marks the risk points in the scripts to be reviewed, fills in rollback plans and exception handling suggestions for the risk points, and generates review tags. If the review label indicates that the review has been passed, an electronic signature is attached to the script to be reviewed. The script to be reviewed then enters a grayscale state, and the target script marked as having passed the review is obtained. If the review label indicates that the review has failed, the script is returned for review and marked as a candidate script to obtain the candidate script.

[0010] In one embodiment, multiple sets of test cases derived from candidate scripts are combined with multiple different large language models to form a differential test combination, and differential testing is performed on the differential test combination to obtain differential metrics, including: Using parameter samples as seeds, multiple test cases are generated from candidate scripts according to preset value rules; Multiple test cases, execution environment matrices, and localization strategies are combined to form differential test combinations. Differential tests are performed on the differential test combinations to obtain differential metrics. The execution environment matrix contains at least two different large language models and script executables without large language models. The localization strategy includes a preferred file and a secondary file.

[0011] In one embodiment, the script generation and execution method further includes: In response to changes in the page structure signature in the website's structured knowledge graph, scan all scripts that reference stable control identifiers within the changed areas and generate a list of affected scripts; For each script in the list of affected scripts, determine the granularity of change, perform differential update corresponding to the granularity of change, and generate a new version of the script. The granularity of change includes attribute-level changes, field order changes, or structural changes. The new version of the script is re-executed with differential testing, auditing on the audit workbench, and gray-scale deployment. Once approved, the new version of the script is marked as the active version, and the original active version is downgraded for backup, thus obtaining the active script.

[0012] In addition, to achieve the above objectives, this application also provides a script generation and execution device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the above-described script generation and execution method.

[0013] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, storing a program that implements the script generation and execution method. The program that implements the script generation and execution method is executed by a processor to implement the steps of the above-mentioned script generation and execution method.

[0014] This application provides a script generation and execution method. Candidate scripts are obtained through a first channel and a second channel. The first channel captures each step of an employee's business process and aligns it to stable control identifiers and navigation edges to obtain candidate scripts. The second channel obtains candidate scripts by reverse lookup after the large language model performs its first task under the constraints of the website's structured knowledge graph. Multiple test cases derived from the candidate scripts are combined with multiple different large language models to form differential test combinations, and differential tests are performed on these combinations to obtain differential metrics. If the differential metrics of all differential test combinations are within a preset differential threshold, the candidate scripts are... This script is marked as pending review. In response to the script's review label, risk point confirmation, and electronic signature on the review workbench, the script enters a gray-scale state, resulting in a target script marked as approved. The target script is then deployed to real traffic in a gray-scale manner according to a preset ratio. During the gray-scale deployment, the target script's performance metrics are compared with those of historical execution methods. If the performance metrics meet preset judgment conditions, it advances to the next gray-scale stage; otherwise, it reverts to the previous stage until full activation is achieved, at which point the target script is marked as activated, resulting in an activated script. By eliminating illusions through knowledge graph constraint generation, exposing inconsistencies through multi-model differential testing, and ensuring quality control through manual review and gray-scale verification, the behavior of generating scripts from large models is transformed into a constrained and verified engineering process, improving the credibility of scripts generated from large models. Attached Figure Description

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

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the script generation and execution method of this application in Embodiment 1. Figure 2 A schematic diagram of the dual-channel script source provided for Embodiment 1 of the script generation and execution method of this application; Figure 3 A schematic diagram of the gray-scale deployment and automatic rollback process provided in Embodiment 1 of the script generation and execution method of this application; Figure 4 A schematic diagram of the e-commerce order creation script process for the script generation and execution method provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the script generation and execution device in the embodiments of this application.

[0018] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0021] Currently, with the maturity of browser automation agents driven by large language models, the description threshold for automation tasks has been significantly reduced. Related technologies typically involve directly generating and executing scripts online using large models. However, due to sampling uncertainties, model version drift, and the risk of illusion, the generated scripts are untested and their correctness cannot be guaranteed, easily leading to the erroneous execution of high-risk operations.

[0022] The main solution of this application is as follows: Candidate scripts are obtained through a first channel and a second channel. The first channel captures each step of an employee's business process and aligns it with stable control identifiers and navigation edges to obtain candidate scripts. The second channel obtains candidate scripts by reverse lookup after the large language model performs the task for the first time under the constraints of the website's structured knowledge graph. Multiple test cases derived from the candidate scripts are combined with multiple different large language models to form differential test combinations, and differential tests are performed on these combinations to obtain differential metrics. If the differential metrics of all differential test combinations are within a preset differential threshold, the candidate script is marked. The script is initially set to be reviewed. In response to the script's review label, risk point confirmation, and electronic signature on the review workbench, it enters a gray-scale state, resulting in a target script marked as approved. The target script is then deployed to real traffic at a preset ratio. During the gray-scale deployment, its performance metrics are compared with those of historical execution methods. If the performance metrics meet preset judgment conditions, it advances to the next gray-scale stage; otherwise, it reverts to the previous stage until full activation is achieved, at which point the target script is marked as activated, resulting in an activated script. By eliminating illusions through knowledge graph constraint generation, exposing inconsistencies through multi-model differential testing, and ensuring quality control through manual review and gray-scale verification, the behavior of generating scripts from large models is transformed into a constrained and verified engineered process, improving the credibility of scripts generated from large models.

[0023] It should be noted that the execution subject in this embodiment can be a script generation and execution device, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a script generation and execution device capable of performing the above functions. This embodiment does not specifically limit it in this way. The following uses a script generation and execution device as the execution subject as an example to describe this embodiment and the following embodiments.

[0024] Based on this, Embodiment 1 of this application proposes a script generation and execution method, please refer to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the script generation and execution method of this application. The script generation and execution method includes steps S10 to S50: Step S10: Obtain candidate scripts through the first channel and the second channel. The first channel captures each step of the employee's business process and aligns it with the stable control identifier and navigation edge to obtain candidate scripts. The second channel obtains candidate scripts by reverse lookup after the large language model performs the task for the first time under the constraints of the website's structured knowledge graph.

[0025] In this embodiment, the first channel refers to the employee operation recording and learning channel, which captures each step of the employee's business process through a browser extension and aligns it to stable control identifiers and navigation edges to obtain candidate scripts. The second channel refers to the large language model-assisted generation channel, which obtains candidate scripts by reverse lookup after the large language model performs the task for the first time under the constraints of the website's structured knowledge graph. Candidate scripts refer to the original scripts generated through the first or second channel that have not yet been tested or reviewed. Stable control identifiers refer to the unique IDs of controls registered in the webpage structure knowledge base. Navigation edges refer to the legitimate relationships recorded in the website's structured knowledge graph that trigger a jump from one page to another by a specific control, used to constrain the jump behavior when the large language model generates scripts. The website structured knowledge graph refers to the four-layer hierarchy of site, page, block, and control, and the octet of control-triggered jumps, serving as the unique context constraint skeleton for the large language model to generate scripts.

[0026] As an alternative implementation, the first channel obtains candidate scripts through a browser extension, and the second channel obtains candidate scripts through a website's structured knowledge graph with added constraints.

[0027] Specifically, please refer to Figure 2 , Figure 2This diagram illustrates a dual-channel script source process for Embodiment 1 of the script generation and execution method of this application. The first channel involves operations performed by business personnel, while the second channel generates scripts based on natural language task objectives and examples. In the first channel, the business personnel use a browser extension to enable recording and learning mode, completing the business process once or multiple times. The browser extension automatically captures each operation, such as clicking, inputting, selecting, scrolling, and jumping, and maps each operation to stable control identifiers and navigation edges in the webpage structure knowledge base. Simultaneously, the browser extension captures a snapshot of the page and the accessibility tree at that time for subsequent multi-model playback testing. After multiple recordings, the script's parameter slots can be aligned and summarized, identifying which steps' inputs differ due to task parameters. A structured candidate script is then output and its source is marked as a recording. In the second channel, the business personnel provide natural language task objectives and parameter examples. The system retrieves the least relevant subgraph from the website's structured knowledge graph, adds prompts and hard constraints, and then the browser's automated agent executes the task for the first time under these constraints. The execution trajectory is then processed through trajectory parsing, control reverse lookup, and parameter slot summarization to output a structured candidate script, with the source marked as model generation. Trajectory parsing transforms each step of the browser's automated agent's execution into a structured operation log; control reverse lookup matches each step in the log to stable control identifiers and navigation edges in the webpage's structured knowledge base, verifying their validity and supplementing positioning strategy information; parameter slot summarization identifies steps in the script that vary due to task parameters by comparing multiple executions or analyzing the relationship between input parameters and operation values, abstracting them into parameter slots, and finally outputting a complete structured candidate script. By acquiring candidate scripts through both browser extension recording and website structured knowledge graph constraint generation, the system ensures a consistent data structure for all candidate scripts without requiring manual dragging and dropping by the business side, providing standardized input for subsequent multi-model testing.

[0028] Step S20: Combine multiple test cases derived from candidate scripts with multiple different large language models to form differential test combinations, and perform differential tests on the differential test combinations to obtain differential metrics.

[0029] In this embodiment, a test case refers to a regression execution instance that is automatically generated from a parameter sample according to a preset value rule, containing a complete set of input parameters and their expected key fields, and is used to verify the correctness and consistency of the script.

[0030] As one implementation method, multiple sets of test cases are derived from the candidate scripts, and differential testing is performed on each test case under all combinations of multiple models and multiple positioning strategies to obtain differential indicators.

[0031] Specifically, the test orchestrator first uses the parameter samples of the candidate scripts as seeds and automatically generates multiple sets of test cases according to preset value rules, such as boundary values, typical values, and outliers. Each set of test cases contains complete input parameters and their expected key fields. Each test case is run separately in an execution environment matrix, which contains at least two different large language models, such as a high-quality model and a high-performance model, as well as a pure script execution level without a large language model. Simultaneously, execution is performed between multiple level positioning strategies, such as the preferred level and the secondary level. This means differential testing is conducted on multiple sets of test cases under all combinations of model and positioning strategy dimensions. By performing differential testing under all combinations of multiple models, multiple positioning strategies, and multiple sets of test cases, potential inconsistencies and reliability risks of the scripts can be fully exposed, ensuring that candidate scripts perform consistently under the expected execution environment.

[0032] Step S30: If the differential indicators of all differential test combinations are within the preset differential threshold, the candidate script is marked as a script to be reviewed.

[0033] As one implementation method, when all differential metrics of a candidate script are within a preset threshold under all models, all positioning strategy levels, and all combinations of all test cases, the candidate script is marked as a script to be reviewed.

[0034] Specifically, after executing all differential test combinations, the test orchestrator compares the metric results of each test case under each model and positioning strategy level combination to confirm that the difference values ​​of all combinations are within the preset differential thresholds, such as a key field consistency rate ≥ 99% and a time consumption deviation ≤ 20%. The key field consistency rate refers to the percentage of core business fields extracted after execution of different combinations under the same test case that are completely consistent, used to measure the certainty of the script output; the time consumption deviation refers to the maximum percentage deviation of the execution time of the same test case under different combinations from the baseline time, used to measure the performance stability of the script under different environments. If all standards are met, a test report is generated containing the test scope, a summary of the results for each combination, and the differential judgment conclusion. The evidentiary signature of this report is written into the script's audit chain, and the script status is marked as pending review. If any combination's metric does not meet the preset differential threshold requirements, a difference positioning report is generated. By setting a threshold for the differential metrics of all combinations as the passing standard, it ensures that only scripts that have passed the consistency check can enter the manual review stage, preventing scripts with potential inconsistency risks from entering the subsequent process.

[0035] In step S40, in response to the audit label, risk point confirmation, and electronic signature of the script to be audited on the audit workbench, the script to be audited enters a grayscale state and is marked as the target script that has passed the audit.

[0036] In this embodiment, the review workbench refers to an interactive interface that displays script content in a business-readable, structured view. The grayscale state refers to a transitional state before the script goes live, used to verify the script's actual performance in a controlled, low-risk manner in the production environment. The review label refers to the review conclusion given after reviewing the script, such as "passed" or "failed."

[0037] As one implementation method, in response to the audit label on the audit workbench of the script to be audited, the audit workbench automatically marks the risk points of the script to be audited and forces business experts to confirm the high-risk steps. After the business experts complete the electronic signature, the script to be audited enters the grayscale state and is marked as the target script that has passed the audit.

[0038] Specifically, in response to the review tags on the scripts awaiting review in the review workbench, the workbench displays the script content block by block and step by step in a business-readable structured view. It automatically marks risk points involving amounts, personal information, and external interfaces, mandating that business experts confirm each item and fill in rollback plans and exception handling suggestions. After review by business experts, the review conclusion is confirmed with an electronic signature. The electronic signature supports multi-party signing strategies; for example, at the highest compliance level, it requires the signatures of the process manager, business manager, and security manager in sequence. After the signatures are archived, the script status is marked as grayscale, resulting in the target script marked as approved. Through risk point confirmation and electronic signature operations in the review workbench, it is ensured that only scripts approved by business experts can be fully deployed.

[0039] Step S50: The target script is deployed to real traffic in a gray-scale manner according to a preset ratio. During the gray-scale deployment, the performance indicators of the target script are compared with the performance indicators of the historical execution method. If the comparison results of the performance indicators meet the preset judgment conditions, it is promoted to the next gray-scale stage. If the preset judgment conditions are not met, it is rolled back to the previous stage until the full activation state is reached. The target script is then marked as activated, and the activated script is obtained.

[0040] In this embodiment, "real traffic" refers to task requests carrying real business data initiated by actual users or business systems in the production environment. "Full activation state" refers to the ready state reached when the target script has undergone complete gray-scale verification and meets preset judgment conditions.

[0041] As one implementation method, the target script is gradually rolled out to real traffic in a gray-scale manner according to a preset gray-scale ratio. During the gray-scale rollout, the performance indicators are continuously compared with the historical execution methods. When the comparison results of the performance indicators meet the preset judgment conditions, it is promoted to the next gray-scale stage; otherwise, it is rolled back to the previous gray-scale stage. The condition judgment is executed in a loop until the full activation state is reached, and the target script is marked as activated to obtain the activated script.

[0042] Specifically, please refer to Figure 3 , Figure 3 The diagram illustrates the gray-scale deployment and automatic rollback process provided in Embodiment 1 of the script generation and execution method of this application. First, the current gray-scale ratio is determined. The gray-scale scheduler gradually releases the approved target scripts according to preset gray-scale ratio steps, such as 1%, 5%, 10%, 50%, and 100%, with an initial gray-scale ratio of 1%. Each ratio is maintained for a preset duration, such as 1 hour, or a preset task volume, such as 1000 tasks. During each gray-scale phase, the execution results of the new script are compared in real-time with the existing method. Differences or ratios are calculated for key indicators. For example, success rate difference = target script success rate - existing method success rate; key field consistency rate difference = target script consistency rate - existing method consistency rate; time consumption deviation = |target script average time consumption - existing method average time consumption| / existing method average time consumption × 100%. When all indicators meet preset judgment conditions within the preset duration, such as key field consistency rate ≥ 99%, the traffic ratio is promoted to the next level, i.e., promoted to the next gray-scale phase. For example, preset judgment conditions include a success rate difference ≥ 0.5%, a key field consistency difference ≥ 1%, and a time consumption deviation ≤ 20%. When any metric fails to meet the preset judgment conditions, a rollback mechanism is automatically triggered, reverting the traffic ratio to the previous level (i.e., reverting to the previous gray-scale phase) and simultaneously notifying operations and maintenance and business stakeholders. This process is continuously iterated, for example, starting with 1% traffic and progressing through 5%, 10%, 50%, and finally 100% full traffic. When the target script runs stably for the entire preset observation period at 100% traffic and meets the preset judgment conditions, it is considered fully activated, and the script's status is marked as activated. This automatic promotion mechanism, which iterates until full activation, transforms gray-scale verification from a phased task into a continuous closed-loop process. This ensures that the script becomes a formal production resource only after consistently meeting the standards at each traffic level, making the entire deployment process automatically traceable.

[0043] Furthermore, the canary deployment scheduler can determine the initial canary deployment ratio and the minimum observation period based on the risk level of the scripts marked by business experts during review. For example, low-risk scripts start at 5%, while high-risk scripts start at 1% with a minimum observation period of 48 hours. By setting the canary deployment start point and minimum observation period differently based on the risk level marked by business experts, it is possible to avoid excessive delays in the deployment of low-risk scripts while ensuring business security, thus balancing risk control and delivery efficiency.

[0044] Furthermore, throughout the candidate script's lifecycle, whenever a critical event is completed, the system automatically generates a structured evidence signature for that event. These critical events include recording events, generation events, testing events, review events, gray-scale events, activation events, and modification events. Each signature contains the event type, timestamp, system identifier, and a summary of the core results. All evidence signature records are appended chronologically to the end of the script's immutable audit chain, forming a complete and traceable chain. This immutable audit chain uses hash chain or blockchain technology for storage, meaning any tampering with historical records will destroy the chain's integrity, preventing the alteration of critical event records. During compliance audits, operations personnel only need to provide the script identifier to export the complete audit chain from generation to activation, containing evidence signatures and original vouchers for all events. By attaching the event and result evidence signatures for each stage to the immutable audit chain, every step of the entire lifecycle is traceable, verifiable, and tamper-proof, meeting the audit requirements of high-compliance fields such as finance and healthcare while providing reliable and complete evidence for the script's reliability.

[0045] Furthermore, the script goes through eight states throughout its lifecycle: candidate, pending testing, pending review, gray-scale deployment, activation, downgrade, repair, and obsolete. The transitions between these states are triggered by specific events and accompanied by corresponding evidence signatures. Specifically, a script enters the candidate state after recording or model generation; a candidate script moves to the pending testing state after passing multi-model differential testing; a script pending testing enters the pending review state after passing electronic signature review by business experts; a script pending review is promoted to the gray-scale state after being deployed proportionally and meeting the standards; after passing full gray-scale verification, it officially enters the activation state and becomes the scheduling target for direct script execution; when the recent failure rate of an activated script exceeds a preset threshold or the page structure signature changes significantly, it is automatically downgraded to the downgraded state, where the script, in conjunction with a large model, provides backup; downgraded scripts enter the repair state awaiting automatic or manual repair; if repair is successful, they can re-enter the testing and review process to return to the activation state; if repair fails, they enter the obsolete state; scripts that have not been used for a long time or have been replaced by newer versions also enter the obsolete state and can be cleaned up or archived. Each state transition must be accompanied by a corresponding stage's evidence signature, such as a test report, audit signature, or gray-scale report. Transitions lacking evidence signatures will be rejected by system-level access control. By implementing refined management of the entire script lifecycle, each stage has clear entry and exit thresholds and evidence signature constraints, ensuring that the script is in a known and controllable state at any point from generation to disposal. This eliminates the risk of scripts being deployed beyond their designated level or serving production operations without sufficient verification.

[0046] This embodiment provides a script generation and execution method. First, candidate scripts are obtained through a first channel and a second channel. The first channel captures each step of an employee's business process and aligns it to stable control identifiers and navigation edges to obtain candidate scripts. The second channel obtains candidate scripts by reverse lookup after the large language model performs its first task under the constraints of the website's structured knowledge graph. Multiple test cases derived from the candidate scripts are combined with multiple different large language models to form differential test combinations, and differential tests are performed on these combinations to obtain differential metrics. If the differential metrics of all differential test combinations are within a preset differential threshold, then... Candidate scripts are marked as pending review scripts. In response to the pending review script's review label, risk point confirmation, and electronic signature on the review workbench, the pending review script enters a gray-scale state, resulting in a target script marked as approved. The target script is then gray-scale deployed to real traffic at a preset ratio. During the gray-scale deployment, the target script's performance metrics are compared with those of historical execution methods. If the performance metrics meet preset judgment conditions, it advances to the next gray-scale stage; otherwise, it reverts to the previous stage until full activation is achieved, at which point the target script is marked as activated, resulting in an activated script. By eliminating illusions through knowledge graph constraint generation, exposing inconsistencies through multi-model differential testing, and ensuring quality control through manual review and gray-scale verification, the behavior of generating scripts from large models is transformed into a constrained and verified engineering process, improving the credibility of scripts generated from large models.

[0047] Based on Embodiment 1, in Embodiment 2 of this application, the content that is the same as or similar to that in Embodiment 1 can be referred to the above description, and will not be repeated hereafter. On this basis, candidate scripts are obtained through a second channel, including: Step S11: Based on the task intent, retrieve the minimum relevant subgraph and the corresponding jump adjacency list of the minimum relevant subgraph from the website's structured knowledge graph, which has a four-layer structure of site, page, block and control as its skeleton.

[0048] In this embodiment, task intent refers to the business objective that the user expects to achieve, expressed through natural language or parameter examples. Site refers to a specific website involved in the business process. Page refers to a specific URL or functional page within a site. Block refers to a DOM (Document Object Model) container within a page that has an independent functional area. Control refers to an interactive HTML (HyperText Markup Language) element within a block, such as a button. Minimal related subgraph refers to a subgraph structure containing only the minimum number of sites, pages, blocks, controls, and their relationships required to complete the current task. Jump adjacency list refers to a table recording the relationships between pages triggered by specific controls, containing information such as the starting page, triggering control, target page, and preconditions.

[0049] As one implementation, the intent parsing layer of the knowledge gateway processes the natural language task objectives and parameter samples submitted by the user, obtaining a quadruple of intent normalization key, site hint, page hint, and parameter slot shape summary. Using this quadruple as the query condition, a layer-by-layer recall is performed in the four-layer graph of sites, pages, blocks, and controls. First, the target site node is located; then, a list of candidate pages related to the task is filtered from that site; next, blocks related to the function are recalled for each candidate page; finally, all labeled stable control identifiers and corresponding multi-level positioning strategies are recalled for each candidate block. After the recall is completed, a minimum relevance subgraph is obtained. Simultaneously, control trigger jump octuplets related to the candidate pages are recalled from the website's structured knowledge graph. These control trigger jump octuplets include the starting page, triggering control, target page, preconditions, postconditions, alternative results, target page, and target site, forming a jump adjacency list. By accurately retrieving the minimum relevant subgraph and jump adjacency list from the four-layer graph, the scope of large model script generation is narrowed down to only the controls and paths already marked in the graph, eliminating the possibility of large models creating controls out of thin air and randomly jumping pages from the source.

[0050] Step S12: The minimum related subgraph and the jump adjacency list are compactly exported and injected with prompt words in three forms: hierarchical path expansion, jump adjacency list compression, and whitelist subgraph query.

[0051] As one implementation, the compact exporter compresses and injects prompt words simultaneously in three forms: hierarchical path expansion, jump adjacency list compression, and whitelist subgraph query. The hierarchical path expansion uses "site / page / block / control" as a separator to concatenate each candidate control in the minimum relevant subgraph to form a complete hierarchical path as a reference slot, enabling the large model to accurately reference each control without guessing its location. The jump adjacency list compression groups the recalled control trigger jump octets into groups in the format of "starting page-triggering control-target page [preconditions / post-flags / alternative results]" to list all navigation edges related to this task. For example, the starting page is order-create-page, the triggering control is btn-submit-order, the target page is order-confirm-page, the precondition is logged in, the post-flag is confirmation page loading completed, and the alternative result is verification failure remaining on the current page, so that the large model can only jump to the page along these predefined paths. The whitelist subgraph query summarizes all candidate blocks and controls in the minimum relevant subgraph into a whitelist list and attaches the recommended positioning strategy level for each control, clearly telling the large model which controls can be referenced. The compact exporter concatenates the compression results from the above three forms into a compact prompt word, which can significantly compress the original map information, enabling long-running tasks to be accommodated in a single context window.

[0052] Step S13: After attaching hard constraints to the end of the prompt words, the script is generated, and the system-level access control component rejects the script products that violate the hard constraints, thus obtaining candidate scripts.

[0053] As one implementation, a hard constraint template is fixed at the end of the generated compact prompt. This hard constraint template includes the following: only stable control identifiers in the whitelist above can be referenced; any control identifier not in the whitelist will be rejected; any jump step must hit an edge in the jump adjacency list; page jumps not listed in the adjacency list will be rejected; each step must provide control references in a hierarchical path expansion format, and selectors or XPath (XML Path Language) cannot be constructed manually; when the whitelist and jump adjacency list are insufficient to complete the task, immediately return to the "more context needed" flag instead of guessing; it is recommended that the positioning strategy level be materialized by the system, and hardcoding specific positioning expressions in the script is prohibited.

[0054] Furthermore, prompts carrying hard constraints are submitted to the browser's automated agent. The agent executes the task step by step according to the hierarchical path references and jump adjacency lists in the prompts. The actual location results and jump results at each step are completely returned through the execution trajectory. The actual location results include the identifiers of the hit stable controls, the location strategy file used, and whether a backtrack was performed. The jump results include the actual target page and whether alternative results were triggered. The trajectory ingestion and script accumulation submodule of the knowledge gateway performs control reverse lookup, jump edge verification, and parameter slot summarization on the trajectory, outputting structured candidate scripts. During this process, the system-level access control component performs real-time verification of the script outputs. Any script outputs that violate hard constraints are directly rejected by the access control component and an error flag is returned to the caller. Only script outputs that fully comply with hard constraints are accepted as candidate scripts and enter the candidate state. By attaching hard constraints to the end of the prompts and coordinating with the system-level access control component to enforce them, it is ensured that the generated scripts strictly follow the knowledge graph constraints.

[0055] Furthermore, a three-way comparative verification was initiated for the obtained candidate scripts. Path A1 was the first execution of a bare agent with its native cache disabled and no graph knowledge injected. Path A2 was the second execution with the same task identifier hitting the agent's native cache. Path B was the execution after injecting graph knowledge and hard constraints according to this scheme. The total number of steps, completed steps, fallback attempts, agent rollback attempts, cache hits, number of extracted results, target page number hits, and key field overlap were recorded for all three paths. The quality standard was determined by the following criteria: the total number of steps in path B should not exceed that of path A1, and the difference between the key field consistency rate of path B and the key field consistency rate of path A1 should be greater than a preset threshold. An accuracy improvement report was generated. Through quantitative comparison of the three-way metrics—pure agent first execution, agent cache execution, and graph injection execution—it was demonstrated that graph-based generation outperforms free-prompt generation in both accuracy and execution efficiency, providing reproducible and auditable empirical evidence for generating scripts for large models.

[0056] In this embodiment, by injecting prompt words into the four-layer structure and jump relationship in the website's structured knowledge graph in a compact form and attaching hard constraints, the large language model is forced to generate scripts within a strictly defined whitelist of controls and jump paths, thereby producing reliable candidate scripts that are executable, auditable, and can directly enter the access control process.

[0057] Based on any of the above embodiments of this application, Embodiment 3 of this application proposes a script generation and execution method, which can be referred to the above description and will not be repeated hereafter. Based on this, after obtaining the activation script, it further includes: Step S51: After the task arrives, the task-level script is retrieved based on the task parameters, and it is determined whether the task-level script is an active script. The script status of the task-level script is obtained. Based on the script status of the task-level script and the completeness of site knowledge, the path is selected and executed to obtain the execution result.

[0058] In this embodiment, a task-level script refers to a structured execution plan with a complete business process as its boundary, and a composite hash index consisting of a site identifier, a task intent normalization key, and a parameter shape digest. Once a candidate script is marked as active, it becomes an active task-level script in the script library. Site knowledge completeness refers to whether the website to which the current task belongs has completed the annotation and construction of a four-layer graph (site, page, block, and control) in the webpage structure knowledge base.

[0059] As one implementation method, upon task arrival, the system first queries the task-level script library based on the input hash of the task parameters and determines whether the task-level script is an active script. If it is an active script, the script status of the task-level script is active. The input hash is a composite hash value composed of a site identifier, a task intent normalization key, and a parameter shape digest. The site identifier is used to identify the target website; the task intent normalization key standardizes the natural language task description into a business intent identifier; and the parameter shape digest performs a hash abstraction of the structure of the task input parameters to distinguish tasks of the same type with different parameter patterns. Simultaneously, the system verifies the site's knowledge completeness. Based on the site identifier in the task parameters, it queries the web page structure knowledge base to see if there is a graph record associated with the site containing a four-layer hierarchy of complete site, page, block, and control relationships, as well as a navigation jump adjacency list. If such a record exists and the version is valid, it is determined to be registered, meaning the site possesses structured knowledge; otherwise, the site does not possess structured knowledge. Then, based on the obtained task-level script's script status and the site's knowledge completeness, the system selects and executes the corresponding path according to preset path judgment rules to obtain the execution result. By combining the script status and site knowledge completeness, the optimal execution path is automatically selected according to preset rules, which can simultaneously ensure reliability and efficiency.

[0060] In this embodiment, by accurately matching input hashes, verifying the completeness of site knowledge, and making adaptive path decisions, the reuse of existing script assets and structured knowledge is maximized while ensuring execution reliability. This minimizes the cost of calling large models and ensures that unlabeled sites can be included in the relabeling process in a timely manner, forming a virtuous cycle of continuous evolution.

[0061] Based on any of the above embodiments of this application, Embodiment 4 of this application proposes a script generation and execution method, which can be referred to the above description and will not be repeated hereafter. On this basis, after a task arrives, a task-level script is obtained by querying the task parameters. The path is selected and executed based on the script status and site knowledge completeness of the task-level script, resulting in the execution result, including: Step S511: Query the task-level script based on the task parameters and determine whether the task-level script is an active script. Obtain the script status of the task-level script. If the query finds a task-level script and the script status is active, execute it according to the direct execution path of the task-level script and obtain the execution result.

[0062] As one implementation method, upon task arrival, the task-level script in the script library is queried using task parameters, such as input hashes, as the key. It is then determined whether the task-level script is the active script. If the task-level script query matches and the script is active, path one is triggered, i.e., the script is executed directly. The knowledge gateway first reads the structured execution plan of the active script from the script library, which includes a block-organized sequence of steps, stable control identifiers referenced by each step, and the corresponding multi-level positioning strategy primary key. Subsequently, the control materialization submodule of the knowledge gateway parses all stable control identifiers in the script in batches, sorts them according to the confidence of each control's multi-level positioning strategy stored in the website's structured knowledge graph, selects the current optimal positioning strategy for each control, such as a preferred CSS (Cascading Style Sheets) selector or XPath, and replaces the stable control identifiers in the script with specific positioning expressions, decoupling the script from the underlying positioning strategy.

[0063] Furthermore, the knowledge gateway submits the complete executable script to the browser's automated agent. The agent executes the steps sequentially according to the script, directly locating page controls and performing corresponding atomic actions such as clicking, inputting, and selecting at each step. This entire process involves almost no invocation of the large language model, relying solely on the script's structured instructions. During execution, the agent continuously feeds back the actual location results, success status, key field extraction results, and final page state to the knowledge gateway's feedback processor via callbacks or polling channels. Upon completion, the feedback processor updates the script's usage log and statistical fields, triggering a rolling update of script-level confidence metrics. If execution is successful, the system returns the key field extraction results to the caller; if execution fails, the system records failure information, such as location failure, timeout, or page anomaly, and triggers subsequent degradation or alarm processes. By executing the task-level script directly, zero large model inference calls are achieved, fundamentally eliminating the uncertainty of large language models and ensuring efficient and stable execution of high-frequency repetitive tasks.

[0064] Step S512: If the query finds a task-level script and the script status is downgraded, execute the task-level script as the main body with additional natural language fallback prompts to obtain the execution result.

[0065] As one implementation method, if the query is successful and the script status is downgraded, path two is triggered, where the script works in conjunction with the large model as a fallback. The knowledge gateway first reads the structured execution plan of the downgraded script, i.e., the sequence of main steps, which includes steps organized by blocks, stable control identifiers referenced by each step, and their multi-level positioning strategies. Then, it parses the stable control identifiers in the script in batches into the current optimal positioning strategy, making the script executable. The knowledge gateway submits the script to the browser's automated agent, which attempts to execute it according to the script's steps. In each step, the agent prioritizes using the positioning strategies and atomic action instructions in the script; if the current step executes successfully, it continues to the next step. If the current step fails, such as a control not found, positioning timeout, abnormal page structure, or operation results not meeting expectations, the agent immediately switches to fallback mode, assembling the current task context, the trajectory of executed steps, the description of failed steps, the accessibility tree or DOM snapshot of the target page, and the original task objective into natural language prompts, and calling the large language model to generate a remedial solution. After the large language model returns a remedial step, the agent executes that step and records the fallback operation in the execution trajectory. Upon completion, the agent sends the complete trajectory back to the feedback processor of the knowledge gateway. The feedback processor updates the script's usage log and statistical fields, such as the number of fallback attempts, the fallback success rate, and the distribution of failed steps. Based on metrics like the fallback success rate, it determines whether to restore the script's state from degraded to active or remain in a degraded state. Finally, the system returns the execution result to the caller and feeds back any new positioning strategies or alternative steps discovered during the fallback process to the knowledge graph for subsequent script self-healing updates. By using a script backbone as the primary approach and a large model as a fallback, the system can still complete the task even when the script partially fails, balancing efficiency and accuracy.

[0066] Step S513: If the query does not find a task-level script, but the site has structured knowledge, recall and compactly export the injection prompt words from the website's structured knowledge graph and execute them. The successful execution result is used as a new candidate script to obtain the execution result.

[0067] As one implementation, if no task-level script is matched, but the site to which the task belongs has been labeled in the website's structured knowledge graph (i.e., possessing structured page knowledge), path three, i.e., structured knowledge enrichment execution, is triggered. The knowledge gateway first performs intent parsing on the task objective, obtaining a quadruple of intent normalization key, site hint, page hint, and parameter slot shape summary. Then, using this quadruple as the query condition, it retrieves the minimum relevant subgraph with a four-layer structure of site, page, block, and control as its skeleton, along with its corresponding control trigger adjacency list, from the website's structured knowledge graph. The compact exporter simultaneously compresses the minimum relevant subgraph and the adjacency list using three methods: hierarchical path expansion, adjacency list compression, and whitelist subgraph query, and injects them into the hint words, attaching hard constraints to the end of the hint words. Hint words carrying hard constraints are submitted to the browser's automated agent. The agent executes the task step-by-step according to the hierarchical path references and adjacency lists in the hint words, with the actual location and jump results of each step being completely returned through the execution trajectory. The knowledge gateway's trajectory acquisition and script accumulation submodule performs control reverse lookup, jump edge validation, and parameter slot summarization on the trajectory, outputting a structured candidate script. This candidate script includes the knowledge base version number and page structure signature at the time of generation. Upon successful execution, the candidate script enters the candidate state and sequentially enters multi-model differential testing, business expert review, and gray-scale deployment access control. Only after passing these steps can it be officially activated and become a new candidate script. Subsequent similar tasks can directly target path one. If execution fails, the failure information is recorded, and the task can be added to the re-annotation queue for retry after the knowledge graph is improved. By utilizing existing structured knowledge to generate scripts according to the graph and completing the access control process, cold tasks are transformed into reusable activation scripts.

[0068] Step S514: If the query does not find a task-level script and the site does not have structured knowledge, execute in natural language mode and add the site to the re-annotation queue to obtain the execution result.

[0069] As one implementation method, if no task-level script is matched and the site to which the task belongs is not annotated in the website's structured knowledge graph (i.e., lacking structured page knowledge), path four, i.e., pure natural language execution, is triggered. The knowledge gateway first performs intent parsing on the task objective, extracting the task description and parameter examples. However, due to the lack of structured site knowledge, it cannot retrieve the minimum relevant subgraph, jump adjacency list, or control whitelist from the knowledge graph. Instead, it directly assembles the original task objective and parameter examples into natural language prompts, without attaching any graph constraints or control whitelists, and submits them to the browser's automated agent. The agent executes the task in free exploration mode, relying on the large language model's own page understanding and reasoning capabilities to autonomously identify page controls, plan operation steps, and execute them step by step. During execution, the agent transmits the complete execution trajectory back to the knowledge gateway in real time. After execution, the system returns the execution result to the caller. Simultaneously, the knowledge gateway packages information such as the site domain name, task description, execution trajectory, and page snapshot of the task, adding it to the re-annotation queue, awaiting subsequent construction and annotation of the structured knowledge graph. Once the site is labeled, subsequent similar tasks can generate candidate scripts via path three and complete the access control process, ultimately upgrading to path one for efficient execution with zero large models. By exploring and executing unknown sites using pure natural language and adding them to the re-labeling queue, an entry point is provided for subsequent knowledge graph construction and script accumulation, ensuring that the system can continuously expand to cover new sites.

[0070] In this embodiment, the optimal execution method is dynamically selected based on the script status and site knowledge completeness through four-path adaptive decision-making. This maximizes execution efficiency and minimizes large model dependencies while ensuring reliability, forming a complete closed loop from cold start to hot execution.

[0071] Based on Embodiment 4 of this application, Embodiment 5 of this application proposes a script generation and execution method, which can be referred to the above description and will not be repeated hereafter. Based on this, execution is performed according to the task-level script direct execution path to obtain the execution result, including: In step S515, the business process engine performs business-level decomposition, branch parallelism, timeout retries, compensation rollback, and manual countersigning on business events to obtain multiple sub-tasks.

[0072] One implementation approach involves registering activated scripts as business nodes within the business process engine, isomorphically orchestrated with manual approval nodes, business system interface nodes, and decision branch nodes. The business process engine first decomposes business events at the business level, breaking down large tasks into multiple independently executable subtasks. Then, it performs parallel scheduling according to the business node graph, distributing each subtask to its corresponding RPA (Robotic Process Automation) node, approval node, or interface node for parallel execution. During the execution of each node, the engine is responsible for timeout retries and compensation rollbacks; that is, if a subsequent node fails, it triggers the reverse operation of the preceding node, such as canceling an already created order or requiring manual countersigning. By integrating activated scripts as business nodes into the business process engine, scripts are upgraded from isolated execution to orchestratable and controllable business process components, achieving business-level decomposition, parallel scheduling, and fault tolerance.

[0073] Step S516: The subtask is sent to the corresponding task-level script through a standardized interface. The task-level script decomposes the subtask into single-step atomic actions. The agent executes the single-step atomic actions to obtain execution status information and returns the execution status information to the business process engine through the standardized interface.

[0074] As one implementation method, the business process engine decomposes business events into subtasks and distributes them to the corresponding task-level scripts through a standardized interface. Once invoked, the task-level script parses and materializes its predefined, block-organized step sequence into a specific positioning strategy, breaking down the subtask into a series of single-step atomic actions, such as clicking, inputting, selecting, and redirecting. The browser automation agent executes each single-step atomic action sequentially according to the step sequence, recording the positioning results, page state changes, and key field extraction results in real time during execution. After execution, the agent returns execution status information to the business process engine through the same standardized interface, including success or failure indicators and key field extraction results. This standardized interface enables collaboration between the business process engine and the task-level scripts, making the entire business process observable and retryable.

[0075] In step S517, the business process engine, based on the execution status information, selects one of the following for processing when execution fails: path switching, compensation rollback, manual intervention, or adding the task to the re-labeling queue, according to the preset strategy: path switching, compensation rollback, manual intervention, or adding the task to the re-labeling queue.

[0076] As one implementation method, when the business process engine detects an RPA script node execution failure, it automatically selects one of the following options based on a preset strategy: path switching, compensation rollback, manual intervention, or adding the task to the relabeling queue. Specifically, in path switching, if the current script node is in a degraded state or the failure reason is recoverable (e.g., network jitter), the subtask is rerouted to path two or three for re-execution, attempting to bypass the failed script step. In compensation rollback, if the failure occurs in the middle or later stages of the business process, the engine triggers reverse compensation operations on the preceding nodes, such as clearing the shopping cart or releasing inventory locks, restoring the system state to its pre-execution safe state. In manual intervention, if the failure reason is risk control interception, data verification inconsistency, or exceeds the scope of automatic processing, the subtask is suspended and pushed to the manual processing queue for manual intervention by business personnel in the management backend. In adding to the relabeling queue, if the root cause of the failure is a change in site structure or a missing knowledge graph, the relevant information of the task is packaged and added to the relabeling queue, awaiting a subsequent update of the knowledge graph before retrying. By automatically making decisions based on preset strategies, it ensures that each failure scenario has a corresponding processing path, avoiding task deadlock or data inconsistency.

[0077] Step S518: If a business node involves compliance level or cross-site redirection, the business process engine will force routing to a manual approval node, and continue execution after approval.

[0078] As one implementation method, during the business process engine orchestration process, the system performs real-time checks on the compliance level and redirection type of each business node. If the current node involves a high-compliance-level operation, such as an amount exceeding a preset threshold, involving the export of sensitive personal information, or a cross-site redirection (e.g., from an internal enterprise system to a third-party payment platform), the node is forcibly marked as requiring manual approval and routed to a manual approval node. This generates an approval task and pushes it to the review workbench. After review, business experts can choose to approve, reject and modify parameters, or terminate the entire business process. The approval conclusion is archived with an electronic signature and timestamp, serving as evidence for compliance auditing. By ensuring that high-risk operations are executed under human supervision, the compliance requirements for critical business processes in the financial, healthcare, and government sectors can be met.

[0079] In this embodiment, by embedding the activation script as a business node into the business process engine, a business closed loop is achieved, which includes engine orchestration of macro-processes, script execution of atomic actions, automatic recovery of exception classification, and mandatory manual approval for high-risk cases. This upgrades the large-model-driven automation from a single tool call to a complete business process that is enterprise-level, observable, retryable, compensable, and auditable.

[0080] Based on any of the above embodiments of this application, Embodiment Six of this application proposes a script generation and execution method, which can be referred to the above description and will not be repeated hereafter. In response to the audit label, risk point confirmation, and electronic signature of the script to be audited on the audit workbench, the script to be audited enters a grayscale state, resulting in a target script marked as approved, including: Step S41: The audit workbench identifies and marks the risk points in the script to be audited, fills in the rollback plan and anomaly handling suggestions for the risk points, and generates audit tags.

[0081] As one implementation method, the scripts to be reviewed are reviewed on a review workbench. The review workbench displays the script's blocks, steps, controls, parameters, expected results, and risk points in a structured view, presented alongside a recorded video, allowing business experts to intuitively understand the business implications of each step. The review workbench's built-in risk identification engine automatically scans the script according to preset rules, marking steps that meet risk criteria, such as those involving amounts or personal information, as risk points. Business experts review the script block by block and step by step on the review workbench. For each automatically marked risk point, the system mandates that the business expert check and confirm each one, and fill in a rollback plan for that step, such as automatically canceling the order and releasing inventory if the order submission fails, along with exception handling suggestions. For steps not automatically marked but deemed risky by the business expert, the expert can manually add risk labels and supplement corresponding rollback plans and exception handling suggestions. Each script to be reviewed is given a review label indicating approval or failure, and all confirmation and entry operations are recorded and archived in real time. By automatically identifying and labeling risky steps, mandating the completion of rollback plans and anomaly handling suggestions, and obtaining structured audit records based on the experience of business experts, we ensure that high-risk operations have clear anomaly response plans.

[0082] Step S42: If the review label is "approved", an electronic signature is added to the script to be reviewed. The script to be reviewed enters a grayscale state, and the target script marked as "approved" is obtained.

[0083] As one implementation method, after business experts complete the confirmation of all high-risk steps, the completion of rollback plans, and the suggestions for handling exceptions on the review workbench, they click the "Approval" button. The system immediately pops up an electronic signature confirmation dialog box, requiring the business expert to verify their identity using their digital certificate or account password. After successful verification, the system generates an review conclusion containing the reviewer's identity information, electronic signature, and current timestamp, and archives this review conclusion as structured evidence in the script's immutable audit chain. After archiving, the system-level access control component detects that the script has a valid electronic signature and automatically transfers the script's status from pending review to grayscale, thus obtaining the approved script. By granting the script compliance authorization, it ensures that only scripts confirmed by business experts can enter the grayscale production environment, achieving a trusted transition from manual review to grayscale deployment.

[0084] Step S43: If the review label is "Review Failed", return the script to be reviewed and mark it as a candidate script to obtain the candidate script.

[0085] As one implementation method, after reviewing the script on the review workbench, if a business expert deems the script to have unacceptable issues, such as logical errors in steps or incomplete parameter slot definitions, they can click the "Reject" button to return the script to the pending review stage. This marks the script as a candidate, creating a candidate script. Simultaneously, a dialog box pops up asking the business expert to select or fill in the rejection reason and attach specific modification suggestions. After the rejection reason is filled in, the system archives the rejection conclusion as structured evidence in the script's audit chain. The system-level access control component then reverts the script's status from pending review to candidate, and notifies the script submitter to adjust and resubmit the candidate script based on the feedback. By returning the script to the candidate status with a rejection reason, a closed loop of review failure, feedback modification, and resubmission is formed, preventing unqualified scripts from being shelved or bypassed for direct deployment, ensuring continuous iteration and improvement of script quality.

[0086] In this embodiment, an unavoidable compliance access control system is formed through structured review by business experts, mandatory confirmation of risk steps, completion of rollback contingency plans, electronic signature archiving, and rejection loops. This ensures that only scripts that have been confirmed by business experts and are traceable can enter the production environment, meeting the audit and security requirements of high-compliance fields.

[0087] Based on any of the above embodiments of this application, Embodiment Seven of this application proposes a script generation and execution method, which can be referred to the above description and will not be repeated hereafter. On this basis, multiple sets of test cases derived from candidate scripts are combined with multiple different large language models to form differential test combinations, and differential tests are performed on the differential test combinations to obtain differential indicators, including: Step S21: Using the parameter sample as a seed, generate multiple sets of test cases for the candidate script according to the preset value rules.

[0088] As one implementation method, parameter slot definitions are extracted from candidate scripts, defining which steps in the script have inputs that vary depending on task parameters, such as customer name and product quantity. Using user-provided parameter examples as seeds, multiple sets of test parameters are automatically generated according to preset value rules. These preset rules include boundary values, typical values, and outliers. After generating multiple values ​​for each parameter slot, the values ​​of all parameter slots are combined using a Cartesian product or orthogonal combination to obtain a complete set of test case parameters. For each parameter combination, the test orchestrator constructs a complete regression test case, including input parameters, expected key fields, expected page state signature, and expected time range, outputting multiple sets of test cases covering normal, boundary, and outlier scenarios. By automatically generating multiple sets of test cases according to preset rules, the script is ensured to be fully validated under different input parameters.

[0089] Step S22: Combine multiple test cases, execution environment matrix, and localization strategy into a differential test combination, perform differential testing on the differential test combination, and obtain differential metrics. The execution environment matrix contains at least two different large language models and script executables without large language models. The localization strategy includes a preferred file and a secondary file.

[0090] In this embodiment, the execution environment matrix is ​​a set of model execution environments composed of multiple model dimensions. It is used to combine with the localization strategy to form a full permutation test matrix, which covers the execution performance of the script under different models and localization strategies.

[0091] As one implementation method, the test orchestrator distributes multiple sets of derived test cases to an execution environment matrix. This matrix contains at least two different large language models and a pure script executable file without large language models. For example, the matrix contains a high-quality large model A, a high-performance model B, a local small model C, and a pure script executable file without large language models. Simultaneously, it configures a preferred and secondary set of multiple positioning strategies for each execution environment. That is, each set of test cases is executed sequentially under each model and each combination of positioning strategy levels until all models and all level combinations have been executed. During each execution, the browser automation agent operates the page according to the script steps. After execution, it collects the final page state signature, key field extraction results, key business identifiers, and time consumption metrics. The final page state signature is a unique fingerprint obtained by standardizing the hash calculation of the page DOM structure at the end of execution. The key field extraction results are the actual values ​​of key business fields, such as order numbers and transfer numbers. The time consumption metrics are the total time elapsed from the start of execution to the return of the result. All execution results are recorded in structured data format. Through comprehensive testing across multiple large language models, pure script executables, and combinations of multi-level positioning strategies, the consistency of script behavior under various execution environments is verified, providing a multi-dimensional and comparable data foundation for differential judgment.

[0092] In this embodiment, by automatically generating test cases and performing differential testing in combination with multiple models and multiple positioning strategies, and by using the full combination threshold judgment to form an unbypassable quality gate, the implicit inconsistency risks caused by the uncertainty of large language models and changes in positioning strategies are eliminated from the source, ensuring the consistency and reliability of candidate scripts in different execution environments.

[0093] Based on any of the above embodiments of this application, Embodiment Eight of this application proposes a script generation and execution method, which can be referred to the above description and will not be repeated hereafter. In addition, the script generation and execution method further includes: Step S100: In response to changes in the page structure signature in the website's structured knowledge graph, scan all scripts that reference stable control identifiers within the changed area and generate a list of affected scripts.

[0094] As one implementation method, under periodic inspections or event triggers, if the DOM structure hash value or stable control identifier set signature of a certain page is found to be inconsistent with the baseline signature stored in the knowledge graph, it is determined that a significant change has occurred in the page structure signature. The DOM structure hash refers to calculating the hash value of the page's standardized DOM tree; when the page's element hierarchy, tag type, or attribute set changes, the hash value changes accordingly. The stable control identifier set signature refers to sorting all the labeled stable control identifiers within the page, concatenating them, and then calculating the hash value; when a control is added, removed, or its attributes change, the signature changes. Upon receiving this change notification, the differential update module of the knowledge gateway locates the changed area, i.e., which specific site, page, block, or control has had its stable identifier added, removed, or its attributes changed. The differential update module scans all scripts in the script library that are in the candidate, testing, review, gray-scale, activation, downgrade, or repair stages, checking each script to see if the stable control identifiers referenced by each script fall within the changed area, and recording each script's ID, current version number, list of referenced changed controls, and the specific step position of the control in the script. After the scan is complete, all affected scripts are compiled into a structured list. Each record in the list includes the script identifier, changed control identifier, change type, reference step location, and current script status. By identifying all scripts affected by the website redesign, omissions and delays from manual inspections are avoided, ensuring that the impact is fully known and controllable.

[0095] Step S200: Determine the change granularity for each script in the list of affected scripts, and perform differential updates corresponding to the change granularity. The change granularity includes attribute-level changes, field order changes, or structure-level changes.

[0096] As one implementation method, the differential update module traverses the generated list of affected scripts, analyzes the granularity of changes to each stable control identifier within the changed area for each script in the list, and determines whether it is an attribute-level change, a field order change, or a structural-level change. Attribute-level changes include changes to attributes such as the ID of a control, but the control's function and position remain unchanged; field order changes include adjustments to the order of input fields in a form, but the fields themselves and their attributes remain unchanged; structural-level changes include the complete replacement of a block, page layout reconstruction, and the deletion or addition of controls. Based on the granularity of the change, the corresponding differential update is executed. For attribute-level changes, the old reference is directly replaced with the new stable control identifier in the script without modifying the step logic; for field order changes, the execution order of the corresponding steps in the script is adjusted or the correspondence between parameter slots and fields is remapped; for structural-level changes, alternative step sequences are retrieved from the website's structured knowledge graph, such as replacing invalid control operations with new control combinations, generating suggested replacement steps, and submitting them for review and confirmation by business experts or operations personnel. After all differential updates are completed, a new version of each affected script is generated and automatically enters a pending test state, ready to re-execute multi-model differential testing, business expert review, and canary deployment access control. By performing minimal differential updates based on the granularity of changes, the cost of fixing issues and the probability of errors after a redesign are significantly reduced.

[0097] Step S300: Re-execute differential testing, audit workbench review, and gray-scale deployment on the new version script. After passing the audit, mark the new version script as the active version and downgrade the original active version for backup, thus obtaining the active script.

[0098] As one implementation method, the newly generated script version automatically enters the test-ready state. The test orchestrator re-executes multi-model differential testing on it. That is, in an execution environment matrix containing at least two different large language models and pure script executables, the derivative test cases are fully executed in combination with the preferred and secondary positions of the multi-position positioning strategy to determine whether the differential indicators are all within the preset thresholds. After the test passes, the new version script enters the review-ready state and is pushed to the review workbench. Business experts review it step by step, confirm the risk points, and fill in the rollback plan. After the review is approved, an electronic signature is attached and the script is archived. After the review is approved, the new version script enters the gray-scale state. The gray-scale scheduler gradually increases the volume according to the preset ratio. Each stage continues to have a preset duration or task volume. During this period, the performance indicators of the new script and the historical execution methods are continuously compared. When all indicators reach the preset threshold, it is promoted to the next stage. If any indicator falls below the threshold, it automatically reverts to the previous stage. Once the gray-scale rollout reaches 100% and all metrics consistently meet targets, the new version script is officially switched to active status, resulting in an activated script. The original activated version remains in a downgraded, standby state during this period until the new version is fully activated and then relegated to an obsolete state as a historical version retained in the audit chain. By forcing the new version script to undergo testing, review, and a full-departmental gray-scale rollout before activation, while retaining the original downgraded standby version, the updated script ensures equal reliability and allows for rapid rollback in case of anomalies, guaranteeing business continuity.

[0099] In this embodiment, by automatically sensing changes in website structure, accurately identifying affected scripts, minimizing repairs based on the granularity of changes, and forcing the repaired new version to re-encode all access restrictions, the system achieves automated management and reliability assurance of script assets in website redesign scenarios, ensuring that the impact of the redesign is controllable and the online deployment is secure.

[0100] For example, to help understand the technical concept or principle of the script generation and execution method after combining this embodiment with the above-described Embodiments 1 and 2, please refer to Figure 4 , Figure 4 A schematic diagram of the e-commerce order creation script process for the script generation and execution method provided in this application embodiment is shown below: First, business employees record and create a standard order. A browser extension then submits a candidate script containing parameter slots to the knowledge gateway. The knowledge gateway triggers multi-model differential testing. If all tests pass, a differential report is archived and pushed to the review workbench. High-risk steps require submitting an order for business experts to complete a rollback plan and provide an electronic signature. After approval, the process enters the canary scheduler for a 1% canary release. As targets are met, it gradually increases to 100%, and finally, the production workflow takes over the direct execution of thousands of subsequent orders, achieving automated scaling. By transforming a single-recorded candidate script into a production-level workflow through automated verification, manual review, and canary scaling, the automated batch execution of thousands of orders can be achieved while ensuring business continuity, reducing deployment risks and improving release efficiency.

[0101] This application provides a script generation and execution device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the script generation and execution method in the first embodiment described above.

[0102] The following is for reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing the script generation and execution device of the embodiments of this application. The script generation and execution device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablets, and in-vehicle terminals, as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The script generation and execution device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0103] like Figure 5As shown, the script generation and execution device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the script generation and execution device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the script generation and execution device to communicate wirelessly or wiredly with other devices to exchange data. Although script generation and execution devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0104] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0105] The script generation and execution device provided in this application, employing the script generation and execution method described in the above embodiments, can solve the technical problem of unreliable scripts generated from large models. Compared with the prior art, the beneficial effects of the script generation and execution device provided in this application are the same as those of the script generation and execution device provided in the above embodiments, and other technical features in this script generation and execution device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0106] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0107] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0108] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, which are used to execute the script generation and execution methods in the above embodiments.

[0109] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), or any suitable combination thereof.

[0110] The aforementioned computer-readable storage medium may be included in the script generation and execution device; or it may exist independently and not assembled into the script generation and execution device.

[0111] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a script generation and execution device, the script generation and execution device: acquires candidate scripts through a first channel and a second channel. The first channel captures each step of an employee's business process and aligns it to stable control identifiers and navigation edges to acquire candidate scripts. The second channel retrieves candidate scripts by reverse lookup after the large language model performs its first task under the constraints of the website's structured knowledge graph. Multiple test cases derived from the candidate scripts are combined with multiple different large language models to form differential test combinations, and differential tests are performed on these combinations to obtain differential metrics. If all differential test combinations... When all differential indicators are within the preset differential threshold, the candidate script is marked as a script to be reviewed. In response to the script to be reviewed being labeled, risk point confirmed, and electronically signed on the review workbench, the script to be reviewed enters a gray-scale state, and the target script is marked as approved. The target script is then gray-scale deployed to real traffic at a preset ratio. During the gray-scale deployment, the performance indicators of the target script are compared with the performance indicators of the historical execution method. If the comparison results of the performance indicators meet the preset judgment conditions, the script is promoted to the next gray-scale stage. If the preset judgment conditions are not met, the script is reverted to the previous stage until the script reaches a fully activated state, at which point the target script is marked as activated, and the activated script is obtained. The historical execution method is compared with the performance indicators in parallel. Based on the performance indicators of the two, when the preset judgment conditions are met, it is promoted to the next gray-scale stage, and when the preset judgment conditions are not met, it is rolled back to the previous stage. The preset judgment conditions are checked repeatedly until the full activation state is reached, and the target script is marked as activated. The events and results generated by the candidate script in each stage from generation, testing, review, gray-scale to activation are attached with evidence signatures and mounted on the candidate script's immutable audit chain.

[0112] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0113] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0114] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0115] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described script generation and execution methods, thereby solving the technical problem of unreliable scripts generated from large models. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the script generation and execution methods provided in the above embodiments, and will not be repeated here.

[0116] This application provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the script generation and execution method described above.

[0117] The computer program product provided in this application can solve the technical problem of unreliable scripts generated from large models. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the script generation and execution methods provided in the above embodiments, and will not be repeated here.

[0118] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A script generation and execution method, characterized in that, The script generation and execution method includes: Candidate scripts are obtained through a first channel and a second channel. The first channel captures each step of the employee's business process and aligns it with the stable control identifier and navigation edge to obtain the candidate script. The second channel obtains the candidate script by reverse lookup after the large language model performs the task for the first time under the constraints of the website's structured knowledge graph. The candidate scripts are used to derive multiple test cases and multiple different large language models to form differential test combinations, and differential tests are performed on the differential test combinations to obtain differential metrics. If all the differential indicators of the differential test combinations are within the preset differential threshold, the candidate script will be marked as a script to be reviewed. In response to the audit label, risk point confirmation, and electronic signature of the script to be audited on the audit workbench, the script to be audited is controlled to enter the grayscale state, and the target script marked as approved is obtained; The target script is deployed to real traffic in a gray-scale manner according to a preset ratio. During the gray-scale deployment, the performance indicators of the target script are compared with the performance indicators of the historical execution methods. If the comparison results of the performance indicators meet the preset judgment conditions, it is promoted to the next gray-scale stage. If the preset judgment conditions are not met, it is rolled back to the previous stage until the full activation state is reached. The target script is then marked as activated, and the activated script is obtained.

2. The script generation and execution method as described in claim 1, characterized in that, Obtaining the candidate script through the second channel includes: Based on the task intent, retrieve the minimum relevant subgraph with a four-layer structure of site, page, block and control as the skeleton and the jump adjacency list corresponding to the minimum relevant subgraph from the website structured knowledge graph; The minimum relevant subgraph and the jump adjacency list are compactly exported and injected with prompt words in three forms: hierarchical path expansion, jump adjacency list compression, and whitelist subgraph query. After attaching a hard constraint to the end of the prompt word, a script is generated, and the system-level access control component rejects script products that violate the hard constraint, thus obtaining the candidate script.

3. The script generation and execution method as described in claim 1, characterized in that, After obtaining the activation script, the process also includes: Upon arrival of the task, the task-level script is retrieved based on the task parameters, and it is determined whether the task-level script is the activation script. The script status of the task-level script is obtained, and the path is selected and executed based on the script status and site knowledge completeness to obtain the execution result.

4. The script generation and execution method as described in claim 3, characterized in that, Upon arrival of the task, a task-level script is retrieved based on the task parameters. Then, based on the script status and site knowledge completeness of the task-level script, a path is selected and the script is executed, yielding the execution result, including: The task-level script is obtained by querying the task parameters and it is determined whether the task-level script is the active script. The script status of the task-level script is obtained. If the query matches the task-level script and the script status is active, the script is executed according to the direct execution path of the task-level script to obtain the execution result. If the query matches the task-level script and the script is in a downgraded state, the task-level script is executed with additional natural language hints to obtain the execution result. If the query does not find the task-level script, but the site has structured knowledge, the injection prompt words are retrieved from the site's structured knowledge graph and extracted in a compact manner before execution. The successful execution result is used as a new candidate script to obtain the execution result. If the query does not find the task-level script and the site does not have structured knowledge, the execution is performed in natural language mode, and the site is added to the re-annotation queue to obtain the execution result.

5. The script generation and execution method as described in claim 4, characterized in that, The execution is carried out according to the direct execution path of the task-level script, and the execution result is obtained, including: The business process engine performs business-level decomposition, branch parallelism, timeout retries, compensation rollback, and manual countersigning on business events, resulting in multiple sub-tasks. The subtask is distributed to the corresponding task-level script through a standardized interface. The task-level script decomposes the subtask into single-step atomic actions. The agent executes the single-step atomic actions to obtain execution status information and returns the execution status information to the business process engine through the standardized interface. The business process engine, based on the execution status information, selects one of the following for processing when execution fails: path switching, compensation rollback, manual intervention, or adding the task to the re-labeling queue, according to a preset strategy. If a business node involves compliance levels or cross-site redirection, the business process engine will force a route to a manual approval node, and execution will continue after approval is granted.

6. The script generation and execution method as described in claim 1, characterized in that, The step of responding to the audit label, risk point confirmation, and electronic signature of the script to be audited on the audit workbench, controlling the script to be audited to enter a grayscale state, and obtaining the target script marked as approved, includes: The review workbench identifies and marks the risk points in the script to be reviewed, fills in rollback plans and anomaly handling suggestions for the risk points, and generates the review tags. If the review label indicates that the review has been passed, the electronic signature is attached to the script to be reviewed, and the script to be reviewed is controlled to enter the grayscale state, thus obtaining the target script marked as having passed the review. If the review label indicates that the review has failed, the script to be reviewed is returned and marked as a candidate script to obtain the candidate script.

7. The script generation and execution method as described in claim 1, characterized in that, The process involves combining multiple test cases derived from the candidate scripts with multiple different large language models to form differential test combinations, and performing differential tests on these combinations to obtain differential metrics, including: Using parameter examples as seeds, multiple test cases are derived from the candidate scripts according to preset value rules; Multiple sets of test cases, execution environment matrices, and localization strategies are combined to form differential test combinations. Differential tests are performed on the differential test combinations to obtain differential metrics. The execution environment matrix contains at least two different large language models and script executables that do not contain the large language models. The localization strategy includes a preferred file and a secondary file.

8. The script generation and execution method as described in claim 1, characterized in that, The script generation and execution method also includes: In response to changes in the page structure signature in the website's structured knowledge graph, the system scans all scripts that reference stable control identifiers within the changed regions and generates a list of affected scripts. For each script in the list of affected scripts, determine the granularity of change, perform differential update corresponding to the granularity of change, and generate a new version of the script. The granularity of change includes attribute-level changes, field order changes, or structural changes. The new version of the script is re-executed with differential testing, auditing on the audit workbench, and gray-scale deployment. Once it passes the audit, the new version of the script is marked as the active version, and the original active version is downgraded for backup, thus obtaining the active script.

9. A script generation and execution device, characterized in that, The script generation and execution device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the script generation and execution method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the script generation and execution method as described in any one of claims 1 to 8.

Images