Operational evidence package driven scripted acceptance method, system, device, and storage medium

Abstract

The application provides an operation evidence package driven script acceptance method, system, device and storage medium, and the method comprises the following steps: recording state acquires user real operation to generate a structured operation evidence package; compiling state compiles a script according to the evidence package written by an external coded intelligent agent, and the script is iteratively modified in the compiling period by a platform provided standardized acceptance operator; running state determines the steps to be executed in sequence by a step host, and a browser related step does not call a large language model. Through the three-state separation architecture of the recording state, the compiling state and the running state, the application realizes an integrated scheme of human recording evidence, external intelligent agent writing maintainable script and platform acceptance operator closed loop verification, and significantly improves the script compiling and acceptance efficiency and reliability in the mixed business arrangement scene.

Description

Technical Field

[0001] This invention relates to the field of script acceptance technology, and more specifically, to a script acceptance method, system, device, and storage medium driven by operational evidence packages. Background Technology

[0002] With the increasing complexity of enterprise application systems and the diversification of business scenarios, the fields of software automation testing and business process automation are facing increasingly severe technical challenges. Traditional automation script writing methods mainly rely on manual coding, requiring testers or developers to manually write large amounts of code to simulate user operations. This approach is not only inefficient but also results in poor script maintainability; when the application interface changes, the script often needs to be completely rewritten. In recent years, a series of technical solutions have emerged in the industry aimed at simplifying automation script generation, mainly including recording-as-code solutions, runtime AI manipulation solutions, and automated workflow generation solutions with built-in compiler intelligence agents.

[0003] In the prior art, the closest technical solutions to this invention include: recording-as-code solutions such as Playwright codegen, which directly generate executable test code by recording user operations in the browser; runtime AI manipulation solutions such as BrowserUse and Codex Record and Replay, which call large language models to perform real-time understanding and operation decisions on the page during script execution; solutions such as Imprint, which automatically generate workflow configuration files using built-in compiler agents, where the system's built-in agents automatically convert the recorded content into a structured workflow after recording is completed; and solutions such as Workflow Use and Browserlet, which automatically convert recorded content into a workflow.

[0004] However, the aforementioned existing technical solutions have many problems and shortcomings in practical applications, which seriously restrict the further development of automated script compilation and acceptance technology.

[0005] First, existing technologies generally lack a three-state separation architecture that separates the evidence package, the external intelligent agent writing, and the platform-standardized acceptance operator. Most solutions adopt a recording-as-code-generate (codegen) model, generating an executable script immediately after recording, lacking an independent evidence package as an intermediate product. This results in a lack of traceable mapping between the original recorded operation information and the final generated script. Other solutions employ a runtime large language model interpretation model, where a large language model is invoked in real-time during script execution to understand the current page and make operational decisions. While this model offers some flexibility, it suffers from high execution costs, poor stability, and difficulty in guaranteeing the repeatability of execution results. Existing technologies fail to effectively separate and independently optimize the evidence collection in the recording state, the intelligent writing and acceptance in the compilation state, and the deterministic execution in the runtime state.

[0006] Second, existing technologies lack a progressive, single-step real-world execution acceptance mechanism that shares the same host process as production operations. Most automated testing solutions use simulated execution or lightweight verification during the compilation and acceptance phase, rather than performing step-by-step verification in a real environment. This acceptance method is prone to situations where tests pass but fail during full-scale runtime, the so-called "test passes but production fails" problem. This is because the execution environment and logic of compilation and acceptance differ from the production environment, making it impossible to discover certain problems that would only be exposed in a real-world execution environment during the acceptance phase.

[0007] Third, in application programming interface (API) traffic recording scenarios, existing technologies lack timeline alignment, Hypertext Transfer Protocol (HTTP) replay verification, and user confirmation access control mechanisms before script writing. When recording network request traffic rather than graphical user interface operations, the agent often infers business intent solely based on the interface path and request parameters, lacking verification of request timing, data dependencies, and response results, leading to deviations between the generated script and the actual business scenario. Furthermore, the lack of user confirmation allows the agent to blindly generate scripts without fully understanding the business semantics.

[0008] Fourth, existing technologies struggle to orchestrate diverse capabilities within a single maintainable script, such as browser operations, Hypertext Transfer Protocol requests, collaboration platform calls, Large Language Model (LLM) calls, and video processing. Furthermore, they cannot guarantee that browser-related steps do not consume LLM tokens during runtime. In real-world business scenarios, a complete business process often spans multiple technology platforms and capability domains, while existing solutions typically focus on orchestrating single types of operations, lacking effective support for the mixed orchestration of heterogeneous capabilities.

[0009] Therefore, there is an urgent need in this field for a novel script acceptance technology solution driven by operational evidence packages, which can clearly separate the recording state, compilation state, and runtime state. This solution uses a technical architecture that allows for the writing of maintainable scripts by external intelligent agents, iterative modifications driven by platform-standardized acceptance operators, and deterministic execution in the runtime state, thereby fundamentally solving many of the shortcomings of the existing technologies.

[0010] In view of this, the present invention provides a script acceptance method, system, device and storage medium driven by operational evidence package. Summary of the Invention

[0011] To address the problems in existing technologies, the present invention aims to provide a script acceptance method, system, device, and storage medium driven by operational evidence packages. It overcomes the difficulties of existing technologies and can achieve an integrated solution of human-recorded evidence, externally written maintainable scripts by artificial intelligence, and closed-loop verification by platform acceptance operators through a three-state separation architecture of recording, compilation, and runtime. This significantly improves the efficiency and reliability of script compilation and acceptance in mixed business orchestration scenarios.

[0012] An embodiment of the present invention provides a script-based acceptance method driven by an operational evidence package, characterized by comprising the following steps: S110, Recording State Step: Collect the user's actual operations on the target application, store them in chronological order as a timeline event sequence, and generate a structured operation evidence package after stopping recording. The evidence package includes at least the operation type, operation object, operation timestamp, and context information. S120, Compiled script generation step: The external coding agent reads the structured operation evidence package and writes a step arrangement script based on the timeline event sequence in the evidence package. The step arrangement script includes multiple execution steps arranged in sequence and dependency declarations for each step. S130, First Acceptance Step in Compilation State: The platform performs abstract syntax tree parsing on the step orchestration script, executes static consistency checks, compares and verifies the timeline event sequence with the written step orchestration script, and outputs structured acceptance results; S140, Second acceptance step in compiled state: The platform maintains the index of the current execution step, performs progressive single-step real execution of each step in the step orchestration script, shares the step host orchestration logic with the running state during execution, and injects browser resources into the page context according to a preset mode; S150, Compilation-state iterative modification step: If the acceptance result of the first acceptance step or the second acceptance step is not passed, the external coding agent modifies the step arrangement script according to the acceptance result, and repeats the first acceptance step and the second acceptance step until the acceptance is passed; S160. Runtime execution steps: The step host executes each step sequentially according to the order of the script arranged in the steps. For steps that declare browser dependencies, the browser automation engine is used for deterministic execution, and the large language model is not called throughout the runtime. For steps that do not declare browser dependencies, the corresponding application programming interface is called to complete the execution.

[0013] Preferably, step S110 includes: S111. Start the recording process and listen to the user's graphical user interface operations and / or network requests on the target application. The graphical user interface operations include at least clicking, inputting, navigating, and scrolling, and the network requests include at least Hypertext Transfer Protocol requests and responses. S112. Write each collected operation event into the timeline event sequence in chronological order of occurrence. For each event, record at least the event type, event occurrence time, event target identifier, and event load data. S113. In application programming interface mode, additionally collect network requests and write them into the timeline event sequence, and support the export of intent identification records and authentication credentials. S114. After recording stops, the timeline event sequence is serialized into a structured operation evidence package and persistently stored. The platform does not provide a code generation function to generate an executable script immediately upon stopping recording.

[0014] Preferably, step S120 includes: S121. The external coded intelligent agent reads the structured operation evidence package through the application programming interface or file system, and parses the operation type, operation object and operation sequence of each event in the timeline event sequence; S122. The external coding agent generates a step orchestration script containing multiple execution steps based on the parsed event sequence. Each execution step includes a step identifier, step type, step parameters, and a declaration of dependencies between steps. S123. The step arrangement script is written in a structured format to support the mixed arrangement of browser operation steps, Hypertext Transfer Protocol request steps, collaboration platform call steps, large language model call steps and video processing steps. S124. The external coding agent is a coding proxy embedded in the integrated development environment. It interacts with the platform through the command-line interface and outputs structured acceptance results for the agent to parse.

[0015] Preferably, step S130 includes: S131. After receiving the step arrangement script, the platform calls the abstract syntax tree parser to parse the script, extract the step type, step parameters and dependency declarations of each step in the script, and construct a step dependency graph. S132. Perform a static consistency check, which includes at least: checking whether the operation objects or dependent data referenced in each step exist in the evidence package, checking whether there is a circular dependency between steps, and checking whether the format and value range of the step parameters are valid. S133. Compare and verify the timeline event sequence with the written step arrangement script to generate a comparison view containing the original events of the evidence package and the script steps, and identify the covered events and the uncovered events. S134. Output structured acceptance results, which shall include at least whether the static consistency check has passed, a list of differences in the comparison and verification, and suggested modifications.

[0016] Preferably, step S140 includes: S141. The platform maintains the index pointer of the currently pending steps, and proceeds step by step in sequence from the starting step of the step arrangement script. S142. For the current step, determine whether the step declares a browser dependency. If a browser dependency is declared, obtain the browser page context through the step host and inject it into the execution environment. If no browser dependency is declared, execute directly in the current execution environment. S143. The host executes the current step and records the execution log and execution results. The execution results include at least the success or failure status, return data and error information. S144. After execution is complete, update the index pointer to point to the next step, and output the execution result of the current step for external coded intelligent agents to view; S145. The host of the step is an execution engine shared by the production and compilation / acceptance environments, ensuring that the execution logic of single-step execution in the compilation state and full execution in the runtime state is consistent.

[0017] Preferably, step S150 includes: S151. The external coding agent receives the structured acceptance results output by the first acceptance step and the second acceptance step, and parses the static consistency check failure items and / or single-step execution failure items contained therein. S152. The external coding agent locates the corresponding steps and step parameters in the step arrangement script based on the failed items obtained from the parsing, and modifies them according to the following priority: First, based on the difference list in the acceptance results, the missing steps corresponding to the uncovered events are supplemented and inserted first; then, the steps that report errors in the static consistency check are corrected; and finally, the parameters of the steps that fail to execute in a single step are adjusted or the context is completed. S153. The external coding agent performs local static verification on the modified step arrangement script to confirm that the modified script has correct syntax and no acyclic dependencies. S154. The external coding agent resubmits the modified step orchestration script to the platform, and the platform executes the first acceptance step and the second acceptance step again. After each modification, only the first acceptance step and the second acceptance step are re-executed for the modified steps and their dependent steps. The other steps that have passed the acceptance reuse the previous acceptance results. S155. The external coding agent records the iteration number and corresponding acceptance result of each iteration. If the iteration number reaches the preset maximum threshold and the acceptance is still not passed, the iteration is terminated and an alarm message is output. S156. The external coding agent is a coding agent driven by a large language model. It concatenates the structured acceptance result with the step arrangement script to form prompt words and calls the large language model to generate a modified step arrangement script. S157. The external coding agent maintains multiple historical versions of the current step's orchestration script. If the acceptance result after this modification is not improved or worsened compared to the previous round, it rolls back to the previous script version and regenerates the modified script using an alternative modification strategy. S158. The first acceptance step and the second acceptance step share the same execution context during the iterative modification process. The execution context includes at least the browser session state, authentication credentials and environment variables, and the context continuity is maintained during the iteration process. S159. If the static consistency check of the first acceptance step fails, the external coding agent shall first correct the script structure and resource reference issues and then resubmit for acceptance. After the static consistency check passes, the single-step execution acceptance result of the second acceptance step shall be processed.

[0018] Preferably, in step S160, during runtime execution: S161. The host loads the accepted step arrangement script and executes it sequentially from the starting step. S162. For steps that declare browser dependencies, the step host calls the browser automation engine to start the browser instance, navigates to the target page, and performs deterministic operations according to the step parameters. The deterministic operations include at least clicking, inputting, waiting, and asserting. During the execution process, the large language model is not called for page understanding and operation decision-making. S163. For steps that do not declare browser dependencies, the step host calls the corresponding application programming interface to execute the steps according to the step type. The application programming interface includes at least the Hypertext Transfer Protocol Request Interface, the Collaboration Platform Application Programming Interface, the Large Language Model Application Programming Interface, and the Video Processing Interface. S164. After all steps are completed, the step host generates a complete execution report containing the execution status, execution time, and return data of each step.

[0019] Embodiments of the present invention also provide a script acceptance system driven by an operation evidence package, used to implement the above-described script acceptance method driven by an operation evidence package, the script acceptance system driven by the operation evidence package includes: The operation recording module is used to collect the user's actual operations on the target application, store them in chronological order as a timeline event sequence, and generate a structured operation evidence package after recording stops. The evidence package includes at least the operation type, operation object, operation timestamp, and context information. The compilation script module is used to allow an external coded intelligent agent to read the structured operation evidence package and write a step arrangement script based on the timeline event sequence in the evidence package. The step arrangement script includes multiple execution steps arranged in sequence and dependency declarations for each step. The first acceptance module is used to perform abstract syntax tree parsing on the step arrangement script, perform static consistency checks, compare and verify the timeline event sequence with the written step arrangement script, and output structured acceptance results. The second acceptance module is used to maintain the index of the current execution steps, perform progressive single-step real execution of each step in the step orchestration script, share the step host orchestration logic with the running state during execution, and inject browser resources into the page context according to a preset mode. An iterative modification module is used to modify the step arrangement script according to the acceptance result if the acceptance result of the first acceptance step or the second acceptance step is not passed, and to repeatedly execute the first acceptance step and the second acceptance step until the acceptance is passed. The execution module is used by the step host to execute each step sequentially according to the order of the scripts arranged by the steps. For steps that declare browser dependencies, deterministic execution is performed using the browser automation engine, and the large language model is not called throughout the runtime. For steps that do not declare browser dependencies, the corresponding application programming interface is called to complete the execution.

[0020] Embodiments of the present invention also provide a script acceptance device driven by an operational evidence package, comprising: processor; A memory in which executable instructions of the processor are stored; The processor is configured to execute the steps of the above-described operation evidence package-driven script acceptance method by executing the executable instructions.

[0021] Embodiments of the present invention also provide a computer-readable storage medium for storing a program, which, when executed, implements the steps of the above-described operation evidence package-driven script acceptance method.

[0022] The purpose of this invention is to provide a script acceptance method, system, device, and storage medium driven by operational evidence packages. It can realize an integrated solution of human-recorded evidence, external artificial intelligence-written maintainable scripts, and platform acceptance operator closed-loop verification through a three-state separation architecture of recording state, compilation state, and runtime state, which can significantly improve the efficiency and reliability of script compilation and acceptance in mixed business orchestration scenarios. Attached Figure Description

[0023] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0024] Figure 1 This is a flowchart of the script acceptance method driven by the operation evidence package of the present invention.

[0025] Figure 2 This is a three-state architecture diagram of the script acceptance method driven by the operational evidence package that implements the present invention.

[0026] Figure 3 This is a flowchart of the compiled-state acceptance closed-loop process of the script acceptance method driven by the operation evidence package of the present invention.

[0027] Figure 4 This is an API verification access control timing diagram for implementing the script acceptance method driven by the operation evidence package of this invention.

[0028] Figure 5 This is a schematic diagram of the host and requirements assembly steps for implementing the script acceptance method driven by the operation evidence package of the present invention.

[0029] Figure 6 This is a combined schematic diagram of the timeline and step arrangement script of the script acceptance method driven by the operational evidence package of the present invention.

[0030] Figure 7 This is a system architecture diagram of the script acceptance system driven by the operation evidence package of the present invention.

[0031] Figure 8 This is a schematic diagram of the structure of the script acceptance device driven by the operation evidence package of the present invention.

[0032] Figure 9 This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of the present invention. Detailed Implementation

[0033] The following specific examples illustrate the implementation methods of this application. Those skilled in the art can easily understand the other advantages and effects of this application from the content disclosed herein. This application can also be implemented or applied through other different specific embodiments, and various details in this application can be modified or changed according to different viewpoints and application systems without departing from the spirit of this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0034] The embodiments of this application will now be described in detail with reference to the accompanying drawings, so that those skilled in the art can easily implement the application. This application may be embodied in many different forms and is not limited to the embodiments described herein.

[0035] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics represented in connection with that embodiment or example, which are included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics represented may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate different embodiments or examples represented in this application, as well as features of different embodiments or examples.

[0036] Figure 1 This is a flowchart of the script acceptance method driven by the operation evidence package of the present invention. For example... Figure 1As shown, this invention provides a script acceptance method driven by an operation evidence package, including a recording state step S110, a compiled state script generation step S120, a compiled state first acceptance step S130, a compiled state second acceptance step S140, a compiled state iterative modification step S150, and a runtime execution step S160. In the recording state step S110, the system collects the user's actual operations on the target application, stores them in chronological order as a timeline event sequence, and generates a structured operation evidence package after recording stops. In the compiled state script generation step S120, an external coding agent reads the structured operation evidence package and writes a step arrangement script based on the timeline event sequence. In the compiled state first acceptance step S130, the platform performs abstract syntax tree parsing on the step arrangement script, performs static consistency checks, compares the timeline event sequence with the written step arrangement script, and outputs a structured acceptance result. In the second acceptance step S140 of the compile state, the platform maintains the index of the current execution step and performs progressive, single-step execution of each step in the step orchestration script. During execution, it shares the step host orchestration logic with the runtime state, and browser resources are injected into the page context according to a preset mode. In the iterative modification step S150 of the compile state, if the acceptance result of the first or second acceptance step is unsuccessful, the external coding agent modifies the step orchestration script according to the acceptance result and repeats the first and second acceptance steps until the acceptance is successful. In the execution step S160 of the runtime state, the step host executes each step sequentially according to the order of the step orchestration script. For steps that declare browser dependencies, the browser automation engine is used for deterministic execution without calling the large language model. For steps that do not declare browser dependencies, the corresponding application programming interface is called to complete the execution. The technical advantages of this embodiment are as follows: By separating the recording, compilation, and runtime states into a three-state architecture, clear decoupling of evidence collection, script writing, and platform acceptance is achieved; the static consistency check in the first acceptance step and the progressive single-step real execution in the second acceptance step form a dual acceptance gate, ensuring script quality; the iterative modification mechanism in the compilation state achieves closed-loop feedback between the external intelligent agent and the platform; and the deterministic execution of the runtime browser step achieves zero large language model token consumption, balancing the dual requirements of intelligent script generation and deterministic execution.

[0037] In a preferred embodiment, step S110 is further defined, including sub-steps S111 to S114. In sub-step S111, a recording process is initiated, monitoring user actions on the target application's graphical user interface and / or network requests. Graphical user interface actions include at least clicking, inputting, navigating, and scrolling; network requests include at least Hypertext Transfer Protocol (HTTP) requests and responses. In sub-step S112, each collected operation event is written into a timeline event sequence in chronological order of occurrence. Each event records at least the event type, event occurrence time, event target identifier, and event payload data. In sub-step S113, in application programming interface (API) mode, additional network requests are collected and written into the timeline event sequence, supporting intent identifier recording and authentication credential export. In sub-step S114, after recording stops, the timeline event sequence is serialized into a structured operation evidence package and persistently stored. The platform does not provide a code generation function to generate an executable script upon stopping recording. The technical advantages of this embodiment are as follows: by simultaneously monitoring graphical user interface operations and network requests, it achieves comprehensive collection of user operations, capturing both visible user interactions and underlying network communications; through the standardized storage format of timeline event sequences, it provides a structured data foundation for subsequent script generation and acceptance; by additionally collecting network requests in API mode and supporting the export of intent identifiers and authentication credentials, it provides complete contextual information for script generation in API scenarios; the platform does not provide the function of generating executable scripts upon stopping recording, forcing the recorded output to remain in the form of an evidence package, avoiding the drawbacks of skipping acceptance and directly generating scripts in existing technologies.

[0038] In a preferred embodiment, step S120 is further defined, including sub-steps S121 to S124. In sub-step S121, the external coding agent reads the structured operation evidence package through an application programming interface or file system, and parses the operation type, operation object, and operation sequence of each event in the timeline event sequence. In sub-step S122, the external coding agent generates a step orchestration script containing multiple execution steps based on the parsed event sequence. Each execution step includes a step identifier, step type, step parameters, and a declaration of dependencies between steps. In sub-step S123, the step orchestration script is written in a structured format to support the mixed orchestration of browser operation steps, Hypertext Transfer Protocol request steps, collaboration platform call steps, large language model call steps, and video processing steps. In sub-step S124, the external coding agent is a coding agent embedded in the integrated development environment, interacting with the platform through a command-line interface and outputting structured acceptance results for the agent to parse. The technical advantages of this embodiment are as follows: By using an external coding agent instead of a platform-built-in compiled agent to write scripts, the script writing logic is decoupled from the platform, and users can choose and replace different agents to implement the scripts; through the structured format and dependency declaration mechanism of the step-by-step script orchestration, unified orchestration of various heterogeneous capabilities such as browsers, HTTP, collaboration platforms, large language models, and video is achieved; and through the integrated development environment's embedded coding agent and command-line interface interaction, developers are provided with a familiar development experience and flexible integration methods.

[0039] In a preferred embodiment, step S130 is further defined, including sub-steps S131 to S134. In sub-step S131, after receiving the step orchestration script, the platform calls an abstract syntax tree parser to parse the script, extracting the step type, step parameters, and dependency declarations for each step, and constructing a step dependency graph. In sub-step S132, a static consistency check is performed, including checking whether the operation objects or dependent data referenced by each step exist in the evidence package, checking for circular dependencies between steps, and checking whether the format and value range of the step parameters are valid. In sub-step S133, the timeline event sequence is compared and verified with the written step orchestration script, generating a comparison view containing the original events in the evidence package and the script steps, identifying covered and uncovered events. In sub-step S134, a structured acceptance result is output, including whether the static consistency check passed, a list of differences in the comparison verification, and suggested modifications. The technical advantages of this embodiment are as follows: It achieves a deep understanding of the script structure through abstract syntax tree parsing and step dependency graph construction; it detects structural problems in the script in advance without actual execution through multi-dimensional static consistency checks (reference existence, dependency acyclicity, parameter validity); it clearly shows the agent which recorded events have been covered and which have not by comparing the timeline with the script steps and the difference list, providing precise guidance for iterative modifications; and the structured acceptance results facilitate programmatic parsing and automatic correction by the agent.

[0040] In a preferred embodiment, step S140 is further defined, including sub-steps S141 to S145. In sub-step S141, the platform maintains an index pointer for the currently executed step, proceeding sequentially from the starting step of the step orchestration script. In sub-step S142, for the current step, it is determined whether the step declares a browser dependency. If a browser dependency is declared, the browser page context is obtained through the step host and injected into the execution environment; otherwise, it is executed directly in the current execution environment. In sub-step S143, the step host executes the current step, recording the execution log and execution result. The execution result includes at least a success or failure status, returned data, and error information. In sub-step S144, after execution is complete, the index pointer is updated to point to the next step, and the execution result of the current step is output for external coding agents to review. In sub-step S145, the step host is an execution engine shared by the production runtime environment and the compilation and acceptance environment, ensuring consistency between the execution logic of single-step execution in the compilation state and full execution in the runtime state. The technical advantages of this embodiment are as follows: by maintaining index pointers and proceeding step by step in sequence, fine-grained progressive execution and acceptance are achieved; by judging browser dependencies and injecting page context as needed, the correct runtime environment is ensured when browser steps are executed; by sharing the step host in the production environment and the compilation and acceptance environment, the problem of inconsistent execution semantics between the compilation state and the runtime state is fundamentally eliminated, avoiding the dilemma of "tests pass but full run fails"; by recording and outputting the execution results of each step, rich debugging information is provided for the iterative modification of the agent.

[0041] In a preferred embodiment, step S150 is further defined, including sub-steps S151 to S159. In sub-step S151, the external coding agent receives the structured acceptance results output by the first and second acceptance steps, and parses the static consistency check failure items and / or single-step execution failure items contained therein. In sub-step S152, the external coding agent locates the corresponding steps and step parameters in the step arrangement script based on the parsed failure items, and modifies them according to priority: first, it prioritizes supplementing missing steps based on the difference list in the acceptance results; then, it corrects the steps that reported static consistency check errors; and finally, it adjusts the single-step execution failure steps. In sub-step S153, a local static check is performed on the modified script to confirm that the syntax is correct and the dependencies are acyclic. In sub-step S154, the modified script is resubmitted to the platform, and after each modification, only the steps involved in the modification and their dependent steps are re-accepted; the remaining steps that have passed acceptance reuse the previous acceptance results. In sub-step S155, the iteration number and corresponding acceptance result of each round of modification are recorded. If the preset maximum threshold is reached and the test still fails, the iteration is terminated and an alarm is output. In sub-step S156, the external coding agent, a coding proxy driven by a large language model, concatenates the structured acceptance result with the step orchestration script to form a prompt word, which is then used to call the large language model to generate the modified script. In sub-step S157, multiple historical versions of the current script are maintained. If the acceptance result does not improve or worsens after this modification, the system rolls back to the previous version and adopts an alternative strategy. In sub-step S158, the first and second acceptance steps share the same execution context during iterative modification, maintaining the continuity of browser session state, authentication credentials, and environment variables. In sub-step S159, if the static consistency check fails, the script structure and resource reference issues are corrected first. The single-step execution acceptance result is then processed after the static consistency check passes. The technical advantages of this embodiment are as follows: Through structured acceptance result analysis and a tiered modification strategy, the intelligent agent achieves accurate localization and orderly correction of script problems; the incremental acceptance mechanism (only re-verifying the steps involved in the modification) significantly improves iteration efficiency; the round recording and maximum threshold protection mechanism prevent infinite loops; intelligent script correction is achieved through modification generation driven by a large language model; historical version management and rollback mechanisms ensure the stability of modifications; shared execution context ensures the continuity of context information such as browser session state and authentication credentials during iteration, avoiding false alarms caused by context loss; and the acceptance order prioritizing static checks over dynamic execution ensures that the script is structurally correct before behavioral verification, reducing invalid dynamic execution attempts.

[0042] In a preferred embodiment, step S160 is further defined, including sub-steps S161 to S164. In sub-step S161, the step host loads the accepted step orchestration script and executes it sequentially from the initial step. In sub-step S162, for steps that declare browser dependencies, the step host calls the browser automation engine to launch a browser instance, navigates to the target page, and performs deterministic operations according to the step parameters, including clicking, inputting, waiting, and asserting. During execution, the large language model is not invoked for page understanding and operation decisions. In sub-step S163, for steps that do not declare browser dependencies, the step host calls the corresponding application programming interface (API) based on the step type, including the Hypertext Transfer Protocol (HTTP) request interface, the collaboration platform API, the large language model API, and the video processing interface. In sub-step S164, after all steps are executed, the step host generates a complete execution report containing the execution status, execution time, and returned data for each step. The technical advantages of this embodiment are as follows: by executing the accepted scripts sequentially by the host steps, a smooth transition from compilation and acceptance to production operation is achieved; the deterministic operations (click, input, wait, assertion) and zero large language model calls of the browser steps ensure the stability, reproducibility, and low cost of browser operations; the unified call of multiple types of application programming interfaces enables the hybrid orchestration of various heterogeneous capabilities such as HTTP, collaboration platforms, large language models, and video in a single script; and the generation of complete execution reports provides data support for the observability of the runtime state and troubleshooting.

[0043] Figure 2 This is a three-state architecture diagram of the script acceptance method driven by the operational evidence package that implements the present invention. Figure 3 This is a flowchart of the compiled-state acceptance closed-loop process of the script acceptance method driven by the operation evidence package of the present invention. Figure 4 This is an API verification access control timing diagram for implementing the script acceptance method driven by the operation evidence package of this invention. Figure 5 This is a schematic diagram of the StepHost and Requirements assembly for implementing the script acceptance method driven by the operation evidence package of the present invention. Figure 6 This is a combined timeline and Step-by-Step Script (STEPS) diagram illustrating the implementation of the operational evidence package-driven script acceptance method of this invention. (Reference) Figures 1 to 6 As shown below, taking a typical enterprise-level hybrid business automation scenario as an example, the implementation process of a complete embodiment of the present invention will be described in detail.

[0044] I. System Initialization and Recording Implementation (corresponding to step S110) Figure 1 , Figure 2 )

[0045] like Figure 1 As shown, the method of the present invention begins with step S110. First, the operation and maintenance personnel deploy the script acceptance system of the present invention on an automated execution server. The system includes an operation recording module, a script compilation module, a first acceptance module, a second acceptance module, an iterative modification module, and a runtime execution module.

[0046] refer to Figure 2 The three-state architecture diagram shown clearly divides the overall architecture of this invention into three independent yet organically collaborative stages: recording, compilation, and execution. The recording stage, located on the left side of the architecture, is responsible for collecting real user actions and generating evidence packages. The compilation stage, located in the middle of the architecture, involves the external coding agent and platform acceptance operators jointly writing and accepting the script. The execution stage, located on the right side of the architecture, is responsible for the deterministic execution of the script by the StepHost.

[0047] During the recording phase, the user executes a recording start command via the command-line interface (CLI), for example: `thebottrace start --mode ui`. Upon receiving this command, the recording module starts the recording process and begins monitoring the user's graphical user interface (GUI) operations on the target application (corresponding to sub-step S111). The target application can be a web application, a desktop application, or a mobile application. In this embodiment, the target application is an enterprise-level customer relationship management (CRM) web system.

[0048] The recording process continuously monitors various user operation events in the background. When a user clicks a button in the browser, the recording process captures the click event, recording the event type as "click," the event occurrence time as the current system timestamp, the event target identifier as the DOM selector or accessibility identifier of the clicked button, and the event payload data including the button's text content and the Uniform Resource Locator (URL) of the page. When a user enters text into an input box, the recording process captures the input event, recording the event type as "input," the event target identifier as the input box's selector, and the event payload data including the entered text content. When a user navigates the page, the recording process captures the navigation event, recording the event type as "navigation" and the event target identifier as the target URL. When a user scrolls the page, the recording process captures the scroll event and records the scroll position information (corresponding to the graphical user interface operation in sub-step S111).

[0049] Meanwhile, the recording process also listens for all Hypertext Transfer Protocol (HTTP) requests and responses (corresponding to network requests in sub-step S111) via the Chrome DevTools Protocol (CDP) or a network proxy. Whenever the browser initiates an HTTP request, the recording process records the request method (GET / POST / PUT / DELETE, etc.), URL, request headers, and request body; when the server returns a response, the recording process records the response status code, response headers, and response body. These network request events are also written into the timeline event sequence in chronological order of occurrence.

[0050] All collected operation events (including GUI operation events and network request events) are written into the timeline event sequence one by one in chronological order of occurrence (corresponding to sub-step S112). Each event contains at least the following fields: event type (event_type), event occurrence time (timestamp), event target identifier (target), and event payload data (payload). The timeline event sequence is essentially a list of events sorted by time, completely recording the user's entire operation trajectory from the start of recording to the stop of recording.

[0051] After the user completes all required recording operations, they execute a stop command via the command-line interface, for example: `thebottrace stop`. The recording process stops, and the complete timeline event sequence is serialized into a structured operation evidence package (corresponding to sub-step S114). This evidence package is stored in JavaScript Object Notation (JSON) format, named `actions.json`, and located in the `artifacts` directory. The evidence package contains the operation type, operation object, operation timestamp, and complete context information. Notably, the platform does not provide a code generation function to generate an executable script upon stopping recording—meaning the output after recording is complete is merely the evidence package itself, not a directly runnable automated script. This design forces the recording output to remain in "evidence" form, preserving an independent acceptance benchmark for subsequent compiled-state acceptance (corresponding to sub-step S114).

[0052] If the user wishes to record in API mode (corresponding to sub-step S113), execute the command: `thebot trace start --mode api`. In API mode, the recording process focuses on collecting network requests and writing these requests into the timeline event sequence. The user can also set the business intent identifier (intent) for this recording using the `--intent` parameter, such as `--intent "query customer list"`. This intent identifier will be recorded in the metadata of the evidence package, allowing subsequent compiled external coding agents to understand the business purpose of the recording. Furthermore, the API mode recording process also supports extracting authentication credentials (such as cookies and tokens) from the response and exporting them, so that subsequently generated scripts can reuse these credentials for authentication.

[0053] II. Implementation of Compiled Script Generation (corresponding to step S120) Figure 2 , Figure 6 )

[0054] After recording is complete, the process enters the compilation phase. For example... Figure 2 As shown in the middle section, the compilation state is jointly completed by the external coding agent and the platform acceptance operator. The external coding agent is a coding agent running in an integrated development environment (IDE) or a standalone command-line environment. In this embodiment, it is a large language model (LLM) driven coding agent (corresponding to sub-step S124).

[0055] The external encoding agent first reads the newly generated artifacts / actions.json structured operation evidence package (corresponding to sub-step S121) through the file system. The agent parses the timeline event sequence in the evidence package, extracting the operation type, operation object, and operation sequence relationship for each event. For example, the agent identifies the event sequence as: navigating to the login page → entering username → entering password → clicking the login button → waiting for successful login → navigating to the customer list page → clicking the query button → receiving the query results.

[0056] Based on the parsed event sequence, the external coded agent generates a Step Orchestration Script (STEPS) (corresponding to sub-step S122). This Step Orchestration Script is written in a structured YAML format and contains multiple execution steps arranged in sequence. Each step includes a step identifier (step_id), a step type (step_type), step parameters (params), and a declaration of dependencies between steps (requires).

[0057] The above example demonstrates the core capability of this invention to support hybrid orchestration: steps step_001 to step_005 are browser operation steps (involving navigation, form filling, clicking, and waiting), step_006 is an HTTP request step, step_007 is a Large Language Model (LLM) invocation step, and step_008 is a Lark collaboration platform sending step. The steps are linked by a requirements field, forming a directed acyclic graph (DAG) structure (corresponding to sub-step S123).

[0058] It's worth noting that the dependency declarations (requires) in the step orchestration script have two meanings: for browser steps, requires indicates that the step depends on the browser context (i.e., it needs to be executed in the browser page environment); for regular steps, requires indicates that the step depends on the output data of the preceding step. In the example, step_002's requires is ["step_001"], indicating that the form filling operation depends on the page state after the navigation operation is completed; while step_007's requires is ["step_006"], indicating that the large language model call depends on the response data of the HTTP request.

[0059] After the external coding agent is written, the steps orchestration script is saved as a steps.yaml file, ready to be submitted to the platform for acceptance (corresponding to sub-step S124). The agent interacts with the platform through the command-line interface (CLI), for example, by executing the command "thebot explain steps.yaml" to trigger the first acceptance.

[0060] III. First Acceptance Test in Compilation Mode (corresponding to step S130) Figure 3 , Figure 6 )

[0061] like Figure 3 The flowchart shown in the compiled state acceptance closed-loop diagram shows that the first acceptance step (explain operator) is the entry point for the acceptance closed loop. After receiving the step arrangement script submitted by the external coding agent, the platform executes the explain acceptance (corresponding to sub-step S131).

[0062] First, the platform calls the Abstract Syntax Tree (AST) parser to parse steps.yaml. The parser reads the YAML structure, extracts the step type (step_type), step parameters (params), and dependency declarations (requires) for each step, and constructs a Directed Acyclic Graph (DAG) based on the dependency relationships, namely the step dependency graph (corresponding to sub-step S131).

[0063] Secondly, the platform performs a static consistency check (requires_check) (corresponding to sub-step S132). This check includes multiple dimensions: First, check whether the operation objects or dependent data referenced in each step exist in the evidence package. For example, if a step's params reference a variable named "{{step_999.response.body}}", but the step_999 does not exist in the evidence package, the check will fail.

[0064] Second, check for circular dependencies between steps. For example, if step_002 depends on step_003, and step_003 depends on step_002, then a circular dependency is formed, and the check fails.

[0065] Third, check whether the format and value range of the step parameters are valid. For example, the url parameter of the browser_navigate step must be a valid URL format; the method parameter of the http_request step must be one of the allowed values ​​such as GET, POST, PUT, DELETE, etc.

[0066] After the static consistency check passes, the platform performs a comparison verification (corresponding to sub-step S133). The platform compares the timeline event sequence in the evidence package with the pre-written Step Orchestration Script (STEPS). Figure 6 The diagram showing the timeline and Steps-by-Step Programming Script (STEPS) is a side-by-side comparison view generated by the platform: the left side displays the original event sequence (with timestamps) recorded in the evidence package, and the right side shows the corresponding steps written in the script. The platform identifies which original events have been covered by the script steps (marked in green), which original events have not been covered (marked in red), and which script steps cannot find corresponding events in the evidence package (marked in yellow).

[0067] Finally, the platform outputs a structured acceptance result (corresponding to sub-step S134). This acceptance result is output in JSON format and includes the following fields: whether the static consistency check passed (passed), a list of differences in the comparison check (diff_list, containing a list of uncovered events and redundant steps), and suggested modifications (suggestions). The external coding agent receives and parses this structured acceptance result via the command-line interface.

[0068] IV. Second Acceptance Test in Compilation Mode (corresponding to step S140) Figure 3 , Figure 5 )

[0069] After the first acceptance test is passed, the second acceptance test (step operator) begins. For example... Figure 3 As shown, the second acceptance step is a progressive, single-step real-execution acceptance. The platform maintains an index pointer (next_index) for the current step to be executed, and proceeds step by step in sequence from the starting step of the step orchestration script (corresponding to sub-step S141).

[0070] For the current step, the platform first determines whether the step declares browser dependencies (i.e., whether the `requires` directive contains browser context-related identifiers) (corresponding to sub-step S142). For example... Figure 5 The diagram illustrates the assembly of the StepHost and requires. If the current step declares browser dependencies, the platform obtains the browser page context (ctx.page) through the StepHost and injects it into the execution environment. The StepHost is the execution engine shared by the production runtime environment and the compilation and acceptance environment (corresponding to sub-step S145), ensuring that the execution logic of single-step execution in the compilation state is completely consistent with that of full execution in the runtime state.

[0071] If the current step does not declare browser dependencies, it will be executed directly in the current execution environment (e.g., by directly initiating an HTTP request or calling the large language model interface).

[0072] The host executes the current step, recording detailed execution logs and results (corresponding to sub-step S143). Execution results must include at least a success or failure status, returned data, and error information. For example, for the `browser_click` step, the execution result includes information such as whether the click was successful and whether the page changed after the click; for the `http_request` step, the execution result includes information such as the HTTP status code, response headers, and response body.

[0073] After execution, the platform updates the index pointer to point to the next step and outputs the execution result of the current step (corresponding to sub-step S144). The external coding agent can view the execution results of each step to understand the actual running status of the script.

[0074] If all steps are executed successfully, the second acceptance test is passed, and the script can enter the running state. If any step fails, the second acceptance test is not passed, and the platform records the index of the failed step and the error message, which is then output to the external coding agent for iterative modification.

[0075] V. Implementation of iterative modifications in compile state (corresponding to step S150) Figure 3 )

[0076] like Figure 3As shown, if the acceptance result of the first or second acceptance step is unsuccessful, the iterative modification closed loop is entered. The external coding agent receives the structured acceptance result and parses the static consistency check failure items and / or single-step execution failure items contained therein (corresponding to sub-step S151).

[0077] Based on the failed items obtained from parsing, the agent locates the corresponding steps and step parameters in the step orchestration script and modifies them according to the preset priority (corresponding to sub-step S152): First, based on the difference list in the acceptance results, it prioritizes supplementing and inserting the missing steps corresponding to the uncovered events; then, it corrects the steps that report errors in the static consistency check (e.g., correcting parameter formats, fixing circular dependencies); finally, it adjusts the parameters or completes the context for steps that fail to execute in a single step (e.g., correcting selectors, adding waiting conditions, adjusting data references).

[0078] The agent performs local static verification on the modified step orchestration script to confirm that the modified script has correct syntax and acyclic dependencies (corresponding to sub-step S153).

[0079] The agent resubmits the modified step orchestration script to the platform (corresponding to sub-step S154). To improve iteration efficiency, the platform supports incremental acceptance: after each modification, only the steps involved in the modification and their dependent steps are re-executed in the first and second acceptance steps; the remaining steps that have already passed acceptance reuse the results of the previous acceptance. This significantly shortens the iteration cycle.

[0080] The agent records the iteration number and corresponding acceptance result for each round of modification (corresponding to sub-step S155). The system presets a maximum iteration threshold of 10 rounds. If the acceptance is not passed after 10 iterations, the iteration is terminated and an alarm message is output to prompt the user for manual intervention.

[0081] In the specific implementation, the external coding agent is a coding proxy driven by a large language model (corresponding to sub-step S156). The agent concatenates the structured acceptance result with the current step orchestration script to form a prompt, and calls the large language model (such as GPT-4, Claude, etc.) to generate a modified step orchestration script. For example, the prompt could be: "The following is the step orchestration script and its acceptance result. Please revise the script according to the acceptance failure information:\n\n[script content]\n\n[acceptance result]".

[0082] The agent also maintains multiple historical versions of the orchestration script for the current step (corresponding to sub-step S157). Before each modification, the agent saves a copy of the current version. After the modification is completed, the acceptance result of this modification is compared with the acceptance result of the previous round: if the acceptance result after this modification is better than the previous round (e.g., fewer failed steps), the modification is retained; if it is not better or worse (e.g., more failed steps or the introduction of new static errors), the agent rolls back to the previous script version and regenerates the modified script using an alternative modification strategy.

[0083] Specifically, the first and second acceptance steps share the same execution context (corresponding to sub-step S158) during iterative modifications. This execution context includes browser session state (such as logged-in session cookies), authentication credentials (such as tokens), and environment variables. During iteration, the execution context remains continuous—that is, within the execution context, the browser will not close due to single-step execution failure, and authentication credentials will not become invalid due to script modifications. This ensures the consistency of the context state during iterative modifications and avoids false alarms caused by context loss.

[0084] Furthermore, the agent processes acceptance issues in a "static over dynamic" order (corresponding to sub-step S159): if the static consistency check of the first acceptance step fails, the agent prioritizes correcting script structure and resource reference issues. Only after the static consistency check passes does it process the single-step execution acceptance results of the second acceptance step. This avoids invalid dynamic execution attempts when the script structure is incorrect.

[0085] VI. Execution in runtime (corresponding to step S160) Figure 2 )

[0086] After acceptance testing, the script enters the runtime phase. For example... Figure 2 As shown on the right, the running state is executed by the StepHost.

[0087] The host loads the accepted step orchestration script (steps.yaml) and executes it sequentially from the starting step (corresponding to sub-step S161).

[0088] For steps that declare browser dependencies (corresponding to sub-step S162), the step host calls the browser automation engine (Playwright in this embodiment) to launch a real browser instance, navigates to the target page, and executes deterministic operations according to the step parameters. Deterministic operations include clicking, filling, waiting, and asserting. Crucially, the large language model is not invoked for page understanding and operation decisions during execution—all operation targets (such as selectors), operation types (such as click or fill), and operation parameters (such as what text to input) are already fixed in the step orchestration script in the compile state; the runtime state only needs to mechanically execute these predefined operations. This ensures the complete determinism, reproducibility, and zero large language model token (LLM) consumption of the browser steps.

[0089] For steps that do not declare browser dependencies (corresponding to sub-step S163), the step host calls the corresponding application programming interface (API) to execute the step, depending on the step type. For example, an HTTP request step calls a Hypertext Transfer Protocol request interface (such as the axios or requests library); a collaboration platform call step calls the Lark API or DingTalk API; a large language model call step calls the OpenAI API or Anthropic API; and a video processing step calls the video processing service API.

[0090] After all steps are completed (corresponding to sub-step S164), the step host generates a complete execution report. This report includes the execution status (success / failure), execution time (millisecond precision), and returned data for each step. The execution report is output in JSON or HTML format for easy viewing and troubleshooting by operations and maintenance personnel.

[0091] VII. API Dimensionality Reduction Implementation

[0092] In API recording mode, this invention also supports API dimensionality reduction. In recording mode, the user records in --mode api mode, generating an evidence package containing network requests. In compilation mode, before the external coding agent writes the script, the platform first executes the third acceptance operator—trace replay (a replay verification gate before writing code in API mode).

[0093] like Figure 4The API verification access control sequence diagram shown illustrates the following operations performed by the trace replay operator: First, timeline alignment is performed, arranging the HTTP requests recorded in the evidence package in chronological order. Then, each HTTP request is replayed, meaning an actual request is sent to the same URL using the same request method and parameters. The replay results are then categorized, with the following outcomes: ok (request successful and returned data as expected), empty_data_despite_success (request successful but returned empty data), business_error (business error, i.e., HTTP status code 200 indicating business failure), http_error (HTTP error, i.e., HTTP status code 4xx or 5xx), non_json (returned non-JSON format data), and unknown (unknown error). The script writing stage can only begin after the user confirms the scope and validity of the replay results.

[0094] The subordinate effect of API dimensionality reduction is that after successful replay, external coding agents can write pure HTTP step orchestration scripts, completely replacing browser operations. In runtime, these pure HTTP steps can be executed without launching a browser, achieving headless scheduled batch execution and significantly reducing resource consumption and execution time.

[0095] VIII. Verification through Multiple Implementation Examples

[0096] Example 1 (Web UI Mode): The user executes `thebot trace start --mode ui` to start recording. After completing CRUD operations on customer information in the CRM system, the user executes `thebot trace stop` to stop recording. The external coding agent reads `artifacts / actions.json` and writes `steps.yaml`. `thebot explain steps.yaml` is executed for the first acceptance test, correcting the `requires_check` issue. `thebot step` is executed for the second acceptance test, executing each step realistically until finished. Finally, `thebot run` is executed for finalization and configured for scheduled execution.

[0097] Example 2 (Pure API Mode): The user executes `thebot trace start --mode api --intent "Batch Export Order Data"` to start API recording, and stops recording after completing the relevant API calls. The user then executes `thebot tracereplay` to verify the replay, obtaining an "ok" output. After the user confirms the replay result range, an external coding agent writes a pure HTTP step orchestration script (including site signature). After `explain` and `step` verification, the user executes `thebot run` to achieve browserless, scheduled batch processing.

[0098] Example 3 (Hybrid Orchestration Mode): In the step orchestration script, browser steps declare browser dependencies using `requires` to fetch page data; steps without `requires` call `run_llm_vision` for image recognition and `run_lark` to send notifications. After `explain` and `step` verification, the `run` state executes uniformly, achieving end-to-end hybrid business automation.

[0099] Through the above complete implementation scheme, the present invention achieves the following significant technical effects: First, the evidence package, acceptance operators, and business scripts are decoupled into three states, allowing for version management and auditing of the scripts. The recorded output is an evidence package, not directly executable code. The compiled scripts are independent of the recorded output, and the acceptance operators are independent of the script writing logic. The three are clearly separated, and each can be independently managed for version control and audit traceability.

[0100] Second, the step and run modes share the same step host, and the incremental execution reduces the risk of inconsistencies between acceptance testing and production. Since the single-step execution in compile mode and the full execution in runtime mode use the exact same execution engine, the problem of "compile acceptance passing but production execution failing" is fundamentally eliminated.

[0101] Third, the API pattern intent and replay outcome translate the recorded intent into a replayable chain of evidence. Through intent identification and replay result classification, the agent can accurately understand the business semantics of the API call, and the generated script can achieve a high success rate on the first run.

[0102] Fourth, after finalization, the browser steps use a zero LLM token, allowing for headless, timed batch execution of APIs after dimensionality reduction. Browser operations are already fixed as deterministic instructions in the compile state, eliminating the need to call the large language model in the runtime state, thus avoiding continuous token consumption and inference latency.

[0103] Fifth, Step-by-Step Orchestration Script (STEPS) serves as the sole orchestration entry point. A single script can orchestrate various business capabilities such as browsers, HTTP, Lark, large language models, and video, meeting the complex needs of enterprise-level hybrid business automation.

[0104] In summary, this invention realizes an integrated solution for the compilation and acceptance of operation evidence package-driven scripts that separates recording, compilation, and execution into three states, significantly improving the efficiency, stability, and maintainability of automated script development in mixed business orchestration scenarios.

[0105] Figure 7 This is a system architecture diagram of the script acceptance system driven by the operational evidence package of the present invention. Figure 7 As shown, the script acceptance system 5 driven by the operation evidence package of the present invention includes: The operation recording module 51 is used to collect the user's actual operations on the target application, store them in chronological order as a timeline event sequence, and generate a structured operation evidence package after recording stops. The evidence package includes at least the operation type, operation object, operation timestamp, and context information.

[0106] The compilation script module 52 is used to allow external coded intelligent agents to read the structured operation evidence package and write a step arrangement script based on the timeline event sequence in the evidence package. The step arrangement script contains multiple execution steps arranged in sequence and the dependency declarations of each step.

[0107] The first acceptance module 53 is used to perform abstract syntax tree parsing on the step orchestration script, perform static consistency checks, compare and verify the timeline event sequence with the written step orchestration script, and output structured acceptance results.

[0108] The second acceptance module 54 is used to maintain the index of the current execution steps, perform progressive single-step real execution of each step in the step orchestration script, share the step host orchestration logic with the running state during execution, and inject browser resources into the page context according to a preset mode.

[0109] The iterative modification module 55 is used to modify the step arrangement script according to the acceptance result if the acceptance result of the first acceptance step or the second acceptance step is not passed, and to repeatedly execute the first acceptance step and the second acceptance step until the acceptance is passed.

[0110] The execution module 56 is used by the step host to execute each step sequentially according to the order of the script. For steps that declare browser dependencies, the browser automation engine is used for deterministic execution, and the large language model is not called throughout the runtime. For steps that do not declare browser dependencies, the corresponding application programming interface is called to complete the execution.

[0111] In summary, the script acceptance system driven by the operational evidence package of the present invention can realize an integrated solution of human-recorded evidence, external artificial intelligence writing maintainable scripts, and platform acceptance operator closed-loop verification through a three-state separation architecture of recording state, compilation state, and runtime state, which significantly improves the efficiency and reliability of script compilation and acceptance in mixed business orchestration scenarios.

[0112] This invention also provides an operational evidence packet-driven script acceptance device, including a processor and a memory storing executable instructions for the processor. The processor is configured to execute steps of an operational evidence packet-driven script acceptance method via the executable instructions.

[0113] As shown above, the script acceptance device driven by the operation evidence package of this invention in this embodiment can realize an integrated solution of human-recorded evidence, external artificial intelligence writing maintainable scripts, and platform acceptance operator closed-loop verification through a three-state separation architecture of recording state, compilation state, and running state, which significantly improves the efficiency and reliability of script compilation and acceptance in mixed business orchestration scenarios.

[0114] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "platform."

[0115] Figure 8 This is a schematic diagram of the structure of the script acceptance device driven by the operation evidence package of the present invention. See below for reference. Figure 8 To describe an electronic device 600 according to this embodiment of the present invention. Figure 8 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0116] like Figure 8 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different platform components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0117] The storage unit stores program code, which can be executed by the processing unit 610 to perform the steps described in the method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 610 can perform actions such as... Figure 1 The steps are shown in the figure.

[0118] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 6201 and / or cache 6202, and may further include read-only memory (ROM) 6203.

[0119] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0120] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0121] Electronic device 600 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms.

[0122] This invention also provides a computer-readable storage medium for storing a program, which, when executed, implements the steps of a script acceptance method driven by an operation evidence package. In some possible implementations, various aspects of this invention can also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the above-described method section of this specification according to various exemplary embodiments of the invention.

[0123] As shown above, the script acceptance system driven by the operation evidence package of this invention in this embodiment can realize an integrated solution of human-recorded evidence, external artificial intelligence writing maintainable scripts, and platform acceptance operator closed-loop verification through a three-state separation architecture of recording state, compilation state, and running state, which significantly improves the efficiency and reliability of script compilation and acceptance in mixed business orchestration scenarios.

[0124] Figure 9 This is a schematic diagram of the structure of the computer-readable storage medium of the present invention. (Reference) Figure 9 As shown, a program product 800 for implementing the above-described method according to an embodiment of the present invention is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0125] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0126] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0127] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0128] In summary, the purpose of this invention is to provide a script acceptance method, system, device, and storage medium driven by operational evidence packages. It can achieve an integrated solution of human-recorded evidence, externally written maintainable scripts by artificial intelligence, and closed-loop verification by platform acceptance operators through a three-state separation architecture of recording, compilation, and runtime, which significantly improves the efficiency and reliability of script compilation and acceptance in mixed business orchestration scenarios.

[0129] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A script-based acceptance method driven by operational evidence packages, characterized in that, Includes the following steps: S110, Recording State Step: Collect the user's actual operations on the target application, store them in chronological order as a timeline event sequence, and generate a structured operation evidence package after stopping recording. The evidence package includes at least the operation type, operation object, operation timestamp, and context information. S120, Compiled script generation step: The external coding agent reads the structured operation evidence package and writes a step arrangement script based on the timeline event sequence in the evidence package. The step arrangement script includes multiple execution steps arranged in sequence and dependency declarations for each step. S130, First Acceptance Step in Compilation State: The platform performs abstract syntax tree parsing on the step orchestration script, executes static consistency checks, compares and verifies the timeline event sequence with the written step orchestration script, and outputs structured acceptance results; S140, Second acceptance step in compiled state: The platform maintains the index of the current execution step, performs progressive single-step real execution of each step in the step orchestration script, shares the step host orchestration logic with the running state during execution, and injects browser resources into the page context according to a preset mode; S150, Compilation-state iterative modification step: If the acceptance result of the first acceptance step or the second acceptance step is not passed, the external coding agent modifies the step arrangement script according to the acceptance result, and repeats the first acceptance step and the second acceptance step until the acceptance is passed; S160. Runtime execution steps: The step host executes each step sequentially according to the order of the script arranged in the steps. For steps that declare browser dependencies, the browser automation engine is used for deterministic execution, and the large language model is not called throughout the runtime. For steps that do not declare browser dependencies, the corresponding application programming interface is called to complete the execution.

2. The script acceptance method driven by the operation evidence package as described in claim 1, characterized in that, Step S110 includes: S111. Start the recording process and listen to the user's graphical user interface operations and / or network requests on the target application. The graphical user interface operations include at least clicking, inputting, navigating, and scrolling, and the network requests include at least Hypertext Transfer Protocol requests and responses. S112. Write each collected operation event into the timeline event sequence in chronological order of occurrence. For each event, record at least the event type, event occurrence time, event target identifier, and event load data. S113. In application programming interface mode, additionally collect network requests and write them into the timeline event sequence, and support the export of intent identification records and authentication credentials. S114. After recording stops, the timeline event sequence is serialized into a structured operation evidence package and persistently stored. The platform does not provide a code generation function to generate an executable script immediately upon stopping recording.

3. The script acceptance method driven by the operation evidence package as described in claim 1, characterized in that, Step S120 includes: S121. The external coded intelligent agent reads the structured operation evidence package through the application programming interface or file system, and parses the operation type, operation object and operation sequence of each event in the timeline event sequence; S122. The external coding agent generates a step orchestration script containing multiple execution steps based on the parsed event sequence. Each execution step includes a step identifier, step type, step parameters, and a declaration of dependencies between steps. S123. The step arrangement script is written in a structured format to support the mixed arrangement of browser operation steps, Hypertext Transfer Protocol request steps, collaboration platform call steps, large language model call steps and video processing steps. S124. The external coding agent is a coding proxy embedded in the integrated development environment. It interacts with the platform through the command-line interface and outputs structured acceptance results for the agent to parse.

4. The script acceptance method driven by the operation evidence package as described in claim 1, characterized in that, Step S130 includes: S131. After receiving the step arrangement script, the platform calls the abstract syntax tree parser to parse the script, extract the step type, step parameters and dependency declarations of each step in the script, and construct a step dependency graph. S132. Perform a static consistency check, which includes at least: checking whether the operation objects or dependent data referenced in each step exist in the evidence package, checking whether there is a circular dependency between steps, and checking whether the format and value range of the step parameters are valid. S133. Compare and verify the timeline event sequence with the written step arrangement script to generate a comparison view containing the original events of the evidence package and the script steps, and identify the covered events and the uncovered events. S134. Output structured acceptance results, which shall include at least whether the static consistency check has passed, a list of differences in the comparison and verification, and suggested modifications.

5. The script acceptance method driven by the operation evidence package as described in claim 1, characterized in that, Step S140 includes: S141. The platform maintains the index pointer of the currently pending steps, and proceeds step by step in sequence from the starting step of the step arrangement script. S142. For the current step, determine whether the step declares a browser dependency. If a browser dependency is declared, obtain the browser page context through the step host and inject it into the execution environment. If no browser dependency is declared, execute directly in the current execution environment. S143. The host executes the current step and records the execution log and execution results. The execution results include at least the success or failure status, return data and error information. S144. After execution is complete, update the index pointer to point to the next step, and output the execution result of the current step for external coded intelligent agents to view; S145. The host of the step is an execution engine shared by the production and compilation / acceptance environments, ensuring that the execution logic of single-step execution in the compilation state and full execution in the runtime state is consistent.

6. The script acceptance method driven by the operation evidence package as described in claim 1, characterized in that, Step S150 includes: S151. The external coding agent receives the structured acceptance results output by the first acceptance step and the second acceptance step, and parses the static consistency check failure items and / or single-step execution failure items contained therein. S152. The external coding agent locates the corresponding steps and step parameters in the step arrangement script based on the failed items obtained from the parsing, and modifies them according to the following priority: First, based on the difference list in the acceptance results, the missing steps corresponding to the uncovered events are supplemented and inserted first; then, the steps that report errors in the static consistency check are corrected; and finally, the parameters of the steps that fail to execute in a single step are adjusted or the context is completed. S153. The external coding agent performs local static verification on the modified step arrangement script to confirm that the modified script has correct syntax and no acyclic dependencies. S154. The external coding agent resubmits the modified step orchestration script to the platform, and the platform executes the first acceptance step and the second acceptance step again. After each modification, only the first acceptance step and the second acceptance step are re-executed for the modified steps and their dependent steps. The other steps that have passed the acceptance reuse the previous acceptance results. S155. The external coding agent records the iteration number and corresponding acceptance result of each iteration. If the iteration number reaches the preset maximum threshold and the acceptance is still not passed, the iteration is terminated and an alarm message is output. S156. The external coding agent is a coding agent driven by a large language model. It concatenates the structured acceptance result with the step arrangement script to form prompt words and calls the large language model to generate a modified step arrangement script. S157. The external coding agent maintains multiple historical versions of the current step's orchestration script. If the acceptance result after this modification is not improved or worsened compared to the previous round, it rolls back to the previous script version and regenerates the modified script using an alternative modification strategy. S158. The first acceptance step and the second acceptance step share the same execution context during the iterative modification process. The execution context includes at least the browser session state, authentication credentials and environment variables, and the context continuity is maintained during the iteration process. S159. If the static consistency check of the first acceptance step fails, the external coding agent shall first correct the script structure and resource reference issues and then resubmit for acceptance. After the static consistency check passes, the single-step execution acceptance result of the second acceptance step shall be processed.

7. The script acceptance method driven by the operation evidence package as described in claim 1, characterized in that, In step S160, during runtime execution: S161. The host loads the accepted step arrangement script and executes it sequentially from the starting step. S162. For steps that declare browser dependencies, the step host calls the browser automation engine to start the browser instance, navigates to the target page, and performs deterministic operations according to the step parameters. The deterministic operations include at least clicking, inputting, waiting, and asserting. During the execution process, the large language model is not called for page understanding and operation decision-making. S163. For steps that do not declare browser dependencies, the step host calls the corresponding application programming interface to execute the steps according to the step type. The application programming interface includes at least the Hypertext Transfer Protocol Request Interface, the Collaboration Platform Application Programming Interface, the Large Language Model Application Programming Interface, and the Video Processing Interface. S164. After all steps are completed, the step host generates a complete execution report containing the execution status, execution time, and return data of each step.

8. A script-based acceptance system driven by operational evidence packages, used to implement the method of any one of claims 1 to 7, characterized in that, include: The operation recording module is used to collect the user's actual operations on the target application, store them in chronological order as a timeline event sequence, and generate a structured operation evidence package after recording stops. The evidence package includes at least the operation type, operation object, operation timestamp, and context information. The compilation script module is used to allow an external coded intelligent agent to read the structured operation evidence package and write a step arrangement script based on the timeline event sequence in the evidence package. The step arrangement script includes multiple execution steps arranged in sequence and dependency declarations for each step. The first acceptance module is used to perform abstract syntax tree parsing on the step arrangement script, perform static consistency checks, compare and verify the timeline event sequence with the written step arrangement script, and output structured acceptance results. The second acceptance module is used to maintain the index of the current execution steps, perform progressive single-step real execution of each step in the step orchestration script, share the step host orchestration logic with the running state during execution, and inject browser resources into the page context according to a preset mode. An iterative modification module is used to modify the step arrangement script according to the acceptance result if the acceptance result of the first acceptance step or the second acceptance step is not passed, and to repeatedly execute the first acceptance step and the second acceptance step until the acceptance is passed. The execution module is used by the step host to execute each step sequentially according to the order of the scripts arranged by the steps. For steps that declare browser dependencies, deterministic execution is performed using the browser automation engine, and the large language model is not called throughout the runtime. For steps that do not declare browser dependencies, the corresponding application programming interface is called to complete the execution.

9. A script-based acceptance device driven by operational evidence packages, characterized in that, include: processor; A memory in which executable instructions of the processor are stored; The processor is configured to execute the steps of the script acceptance method driven by the operational evidence package according to any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium for storing a program, characterized in that, When the program is executed by the processor, it implements the steps of the script acceptance method driven by the operational evidence package as described in any one of claims 1 to 7.

Images