Method, apparatus, device, medium and product for generating automation tool code

Abstract

The application discloses a kind of generation methods, device, equipment, medium and product of automatic tool code, it is related to artificial intelligence technical field, comprising: according to detection task, start browser instance and navigate to target site;Through the network monitoring of browser instance, the candidate data interface relied on to realize target function is identified, and the interface calling parameter of candidate data interface is obtained;Based on interface calling parameter, execute real interface call in browser instance, obtain response sample, and check response sample;After checking, according to interface calling parameter and response sample, generate calling paradigm, and based on calling paradigm, generate automatic tool code by large language model.The application makes browser tool code based on real measurement interface generation, avoids endpoint and field speculation error, improves reliability;Once generation, solidification reuse, avoid repeated analysis;Based on interface layer implementation, reduce interface revision sensitivity.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method, apparatus, device, medium, and product for generating automated tool code. Background Technology

[0002] With the rapid development of large language model capabilities, automatically generating browser automation tool code using large language models has become an important area of ​​research. Users only need to describe their needs in natural language, and the large language model can automatically generate scripts or tool code that can be executed in the browser.

[0003] Currently, the technical solutions for generating browser automation tool code using large language models can be mainly divided into three categories: The first type is the pure prompt-driven code generation solution. The large language model directly generates code containing API call logic based on the user description. However, since the large language model has no knowledge of the actual data interfaces of the target site, the generated API endpoints, request parameters, and response field parsing logic are all based on speculation, which often leads to errors in related parts of the code and requires a lot of manual debugging.

[0004] The second category is real-time reasoning and analysis solutions. The agent analyzes the page document object model or visual content in real time each time it performs a task, and the large language model dynamically infers the operation path and triggers backend data interface calls. However, each execution requires re-analysis and reasoning, and it is impossible to precipitate the identified interface information into reusable tool code.

[0005] The third type is the record and playback solution. This achieves automation by recording user interface operation events and replaying them. Essentially, it records the event sequence at the user interface layer, but it lacks the ability to understand and record the triggered backend data interfaces, and it becomes ineffective once the user interface is redesigned.

[0006] None of the above solutions conducted effective empirical testing and verification of the target site's data interfaces before code generation, resulting in generated tool code that was either based on speculation, unusable, or dependent on a volatile user interface. Summary of the Invention

[0007] This invention provides a method, apparatus, device, medium, and product for generating automation tool code, in order to solve the technical problem that the generation of browser automation tool code in the prior art lacks empirical evidence on the target site data interface, resulting in poor reliability, non-reusability, and sensitivity to changes in the user interface.

[0008] According to one aspect of the present invention, a method for generating automation tool code is provided, the method comprising: Obtain a probe task for the target function of the target site, launch a browser instance and navigate to the target site according to the probe task; By monitoring the network of the browser instance, at least one candidate data interface on which the target function depends is identified, and the interface call parameters of the candidate data interface are obtained. Based on the interface call parameters, execute at least one real interface call in the browser instance to obtain a response sample, and verify the response sample; If the verification passes, a corresponding calling paradigm is generated based on the interface call parameters and the response sample. Based on the calling paradigm, automated tool code for executing the target function is generated through a large language model.

[0009] According to another aspect of the present invention, an apparatus for generating automated tool code is provided, the apparatus comprising: The detection module is used to obtain detection tasks for target functions of the target site, launch a browser instance and navigate to the target site according to the detection tasks; The parameter acquisition module is used to identify at least one candidate data interface on which the target function depends by network monitoring of the browser instance, and to acquire the interface call parameters of the candidate data interface. The verification module is used to execute at least one real interface call in the browser instance based on the interface call parameters, obtain a response sample, and verify the response sample. The code generation module is used to generate a corresponding calling paradigm based on the interface call parameters and the response sample when the verification is passed, and to generate automated tool code for performing the target function based on the calling paradigm through a large language model.

[0010] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform the method described in any one of the present invention.

[0011] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the method described in any one of the present invention.

[0012] According to another aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method of any one of the present invention.

[0013] The beneficial effects of this invention are as follows: Firstly, this invention obtains real response samples of the target site's data interface by executing at least one real interface call in a real browser session, and verifies the response samples before proceeding to the code generation stage. Compared to existing technologies that rely solely on the training memory of large language models and the inference of user intent to write interface call code, the interface endpoints, request parameters, and response field parsing logic used in the code generation tool of this invention are all derived from empirical data obtained in the real operating environment, rather than model inference. Therefore, it avoids the problem of incorrect endpoint URIs and field names in the generated code, reduces manual debugging costs, and improves the reliability of the generated tool code.

[0014] Secondly, after successful verification, this invention generates a calling paradigm based on the interface call parameters and response samples, and then generates automated tool code based on the calling paradigm. Once generated, the tool code can be directly called when performing the same task subsequently, without having to re-execute the interface detection, response acquisition, and verification process. Compared to existing real-time inference analysis solutions that require real-time analysis of the page document object model or visual content and dynamic inference of the operation path from a large language model for each task execution, this invention avoids the time overhead and token consumption caused by repeated analysis and inference for each task by solidifying fixed operation processes into executable code, thus achieving low-cost reuse of fixed operation processes.

[0015] Thirdly, this invention identifies candidate data interfaces and obtains interface call parameters through network monitoring. Based on these parameters, it executes real interface calls to obtain response samples. The generated tool code calls endpoints at the data interface level, rather than user interface operation events. Compared to existing recording and playback schemes that only capture user interface layer event sequences and lack understanding of the site's backend data interfaces, the tool code generated by this invention does not rely on selectors or operation coordinates of user interface elements. When the target site's user interface is redesigned, the tool code can still run normally as long as the data interface remains unchanged, thus reducing sensitivity to user interface changes.

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a method for generating automated tool code according to Embodiment 1 of the present invention; Figure 2 A flowchart illustrating another method for generating automated tool code according to Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the structure of an automated tool code generation device provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the method for generating automated tool code according to embodiments of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0020] It should be noted that the terms "candidate," "target," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0021] Example 1 Figure 1This is a flowchart illustrating a method for generating automated tool code according to Embodiment 1 of the present invention. This embodiment is applicable to situations requiring the detection of target site data interfaces based on real browser sessions and the automatic generation of browser automated tool code. This method can be executed by an automated tool code generation device, which can be implemented in hardware and / or software, such as by an intelligent agent. Figure 1 As shown, the method includes: S101. Obtain the probe task for the target function of the target site, launch a browser instance according to the probe task and navigate to the target site.

[0022] The target site is the website for which the user wants to generate automation tools; that is, the website on which the automation tool code will operate. The user's request includes the target site's identification information (such as domain name or entry page URL), which the system uses to determine the target of all subsequent probing and code generation operations.

[0023] The target function is the specific business requirement that the user wants the automation tool to achieve; that is, the specific task that the tool code should complete after being invoked, such as "retrieving search results from a community site" or "scraping product detail data from an e-commerce platform." Based on the target function, the system determines which data interfaces(s) need to be probed to support the implementation of that function.

[0024] The probing task is a standardized set of instructions generated by the system after semantic parsing user requests. This set includes the target site's entry page URL, the sequence of initial interactive operations required to trigger the target capability (such as entering keywords in the search box and clicking the search button), and feature information used to filter candidate interfaces from network requests. The probing task transforms the user's abstract intent into executable technical instructions for the system.

[0025] A browser instance is the actual browser runtime environment launched by the system, distinct from a simulated browser or a client that only sends HTTP requests. The browser instance loads the user's login state credentials (such as cookies) to ensure that subsequent API calls can pass the site's authentication verification, and also possesses full capabilities such as executing JavaScript, rendering pages, and initiating network requests.

[0026] In one implementation, after receiving a user's functional request for a target website, the system first performs semantic parsing on the request to extract the target website's identification information and the user's desired functional description. Then, based on the parsing results, it launches a real browser instance, loads the target website's page into that instance, and injects the user's login credentials into the browser session, enabling the browser instance to access the target website in an authenticated state, thus preparing for subsequent API calls requiring authentication.

[0027] S102. By monitoring the network of the browser instance, identify at least one candidate data interface on which the target function depends, and obtain the interface call parameters of the candidate data interface.

[0028] Among them, network listening is the process by which the system passively captures all network requests issued by the browser instance during runtime. That is, after the system enables the network listening function in the browser session, it records every HTTP request made by the browser to the target site in real time, providing the original data source for the subsequent screening of candidate data interfaces from these requests.

[0029] Candidate data interfaces are data interfaces that the system filters from captured network requests through network listening, and that may serve the target function. At this time, the interface has not yet been verified by actual calls, hence the term "candidate" state. It only meets certain characteristics related to the target function at the network request level, but whether it can be independently called and return the expected response data still needs to be confirmed by obtaining response samples through actual interface calls and then verifying its actual availability.

[0030] API call parameters are a set of request information required to call a data API, and they are the direct basis for subsequent execution of the actual API call.

[0031] In one implementation, after the browser instance loads the target site and completes the user login state injection, the system enables network monitoring for that browser instance. When a user's interactive action on the page (such as clicking the search button) triggers the execution of the target function, the browser instance initiates a network request to the target site's backend server. The network monitoring function captures these requests in real time and records complete information for each request. The system obtains preset request characteristics and matches the request information of each captured network request with these characteristics. The backend endpoint corresponding to a successfully matched network request is identified as a candidate data interface on which the target function depends. The system then extracts the endpoint's Uniform Resource Locator (URL) and other information required for the call from the request, using it as the interface call parameters for that candidate data interface.

[0032] Optionally, the API call parameters may include at least one of the following: endpoint Uniform Resource Locator, request header fields, and request parameters.

[0033] The endpoint Uniform Resource Locator (URI) is the complete access address of the data interface, used to uniquely identify the interface's location in the network. The system extracts this address by listening to and capturing network requests, and uses it as the target path for subsequent actual interface calls.

[0034] Request header fields are metadata information carried in an HTTP request, used to pass additional attributes of the request to the target website. In actual calls, request header fields typically include authentication credentials, content type declarations, etc., used for authentication and parameter parsing by the target website.

[0035] Request parameters are the specific business data passed to the data interface to customize the interface's return content. For example, for a search function, request parameters include search keywords, page numbers, and other information; for a data submission function, request parameters contain the complete data content to be submitted. Request parameters can be query strings in a Uniform Resource Locator (URL) or structured data in a POST request body.

[0036] The API call parameters are real information extracted from the actual network requests of the target site, rather than fictitious content inferred by a large language model. Executing real API calls based on these real parameters ensures that the obtained response samples accurately reflect the actual data return structure of the target site, providing a solid basis for verification and call paradigm generation. The API call parameters act as a bridge connecting candidate data API identification and real API call execution, ensuring that all data in the entire technology chain originates from the real operating environment, avoiding the problem of unusable code caused by large language models relying solely on speculation in existing technologies. Furthermore, the API call parameters are directly used to construct the request part during the code generation stage, enabling the generated automated tool code to call real APIs upon initial delivery, without requiring manual endpoint correction or supplementary request information.

[0037] S103. Based on the interface call parameters, execute at least one real interface call in the browser instance to obtain a response sample and verify the response sample.

[0038] In this context, a real API call is the process in which, within a browser instance, an actual HTTP request is initiated to the target site's backend server based on the obtained API call parameters, and the server waits for the returned data. Unlike large language models that speculate based on training data or passively record requests from network monitoring, a "real API call" emphasizes that the request is actively and independently executed, and the returned response data is real and verifiable, rather than a simulated or guessed result.

[0039] A response sample is the actual data content returned by the target site after at least one real API call. This response sample contains information such as the actual data structure, field names, data types, and field values ​​returned by the target site's data API. It serves as the direct object for subsequent validation and also as empirical evidence for generating call patterns and automation tool code.

[0040] Validation involves examining the response sample to verify whether the data returned by the interface possesses basic validity for programmatic recognition and processing (e.g., whether the returned data is in the expected structured format, whether it contains identifiable basic field information, etc.), thereby determining whether the interface can be used for subsequent code generation. Passing validation indicates that the response sample has clear field semantic information and can serve as empirical evidence for code generation by automated tools; failing validation indicates that the data returned by the interface does not have sufficient semantic clarity and should not proceed to the code generation stage.

[0041] In one implementation, with the target site loaded in the browser instance and the user logged in, the system constructs a complete HTTP request based on previously obtained API call parameters. This request includes the determined endpoint Uniform Resource Locator (URL), necessary request header fields, and required request parameters. The system executes this request interactively within the browser instance independently of the user interface; that is, it does not require manual user clicks or input but is initiated directly by the system through a programmatic interface provided by the browser. After the actual API call is executed, the system waits for the target site to return response data and records this response data as a response sample. Subsequently, the system validates the response sample by parsing each field, checking whether the field names have identifiable business meaning (i.e., the field names can be mapped to preset semantic tags), and whether the data type of the field is clearly identifiable (i.e., the data type matches the expectation). If the field name has identifiable business meaning and the data type is clearly identifiable, then the field passes the validation. The number of fields that pass the validation is counted; if the number reaches a preset threshold, the validation passes; otherwise, the validation fails, and the process returns to the candidate data interface identification step for re-execution, or the detection logic is adjusted and retried.

[0042] S104. If the verification passes, generate the corresponding calling paradigm based on the interface call parameters and response samples, and generate automated tool code for executing the target function based on the calling paradigm through the large language model.

[0043] The calling paradigm is a unified data description generated by structuring and organizing interface call parameters and response samples. It includes request-side information and response-side information and is used to fully describe the parsing rules of an interface call and its response data, so that the information on which subsequent code generation is based is uniform in form and can be used directly.

[0044] The large language model is a large neural network language model trained on massive amounts of text data, capable of understanding natural language and generating program code. In this embodiment of the invention, the large language model does not participate in any speculation or fabrication of interface information; it only receives structured information that has been empirically verified in the calling paradigm and generates corresponding automated tool code based on this information.

[0045] The automation tool code is the final generated executable program code used to call the target site's data interface and retrieve the returned data to achieve the user-specified target functionality. This code is generated based on empirical data in the calling paradigm, does not contain any large language model speculation or fictitious interface information, and can be directly deployed and executed in the target runtime environment.

[0046] In one implementation, after successful verification, the system structures the verified interface call parameters and response samples to generate a call paradigm. This call paradigm includes all the request information required to call the interface, as well as the names and data type descriptions of each field in the response data, integrating the originally scattered request and response information into a unified data structure.

[0047] Subsequently, the system populates the call paradigm into a preset prompt word template, generating a structured prompt word containing semantic descriptions of the interface call parameters and response sample fields. This prompt word is then input into the large language model. Based on the call paradigm information in the prompt word, the large language model directly outputs automated tool code for executing the target function. This code contains complete logic for constructing the request, initiating the call, and parsing the response data. During the generation process, the large language model only uses the information already present in the call paradigm and does not infer or supplement any content not included in the call paradigm.

[0048] The beneficial effects of the embodiments of the present invention are as follows: Firstly, this invention obtains real response samples of the target site's data interface by executing at least one real interface call in a real browser session, and verifies the response samples before proceeding to the code generation stage. Compared to existing technologies that rely solely on the training memory of large language models and the inference of user intent to write interface call code, the interface endpoints, request parameters, and response field parsing logic used in the code generation tool of this invention are all derived from empirical data obtained in the real operating environment, rather than model inference. Therefore, it avoids the problem of incorrect endpoint URIs and field names in the generated code, reduces manual debugging costs, and improves the reliability of the generated tool code.

[0049] Secondly, after successful verification, this invention generates a calling paradigm based on the interface call parameters and response samples, and then generates automated tool code based on the calling paradigm. Once generated, the tool code can be directly called when performing the same task subsequently, without having to re-execute the interface detection, response acquisition, and verification process. Compared to existing real-time inference analysis solutions that require real-time analysis of the page document object model or visual content and dynamic inference of the operation path from a large language model for each task execution, this invention avoids the time overhead and token consumption caused by repeated analysis and inference for each task by solidifying fixed operation processes into executable code, thus achieving low-cost reuse of fixed operation processes.

[0050] Thirdly, this invention identifies candidate data interfaces and obtains interface call parameters through network monitoring. Based on these parameters, it executes real interface calls to obtain response samples. The generated tool code calls endpoints at the data interface level, rather than user interface operation events. Compared to existing recording and playback schemes that only capture user interface layer event sequences and lack understanding of the site's backend data interfaces, the tool code generated by this invention does not rely on selectors or operation coordinates of user interface elements. When the target site's user interface is redesigned, the tool code can still run normally as long as the data interface remains unchanged, thus reducing sensitivity to user interface changes.

[0051] Optionally, after identifying at least one candidate data interface on which the target function depends through network monitoring of the browser instance, the method further includes: The document object model (DOM) of the current page of the browser instance is evaluated to obtain the page state information in the DOM of the current page. If the page state information contains the page rendering content corresponding to the data returned by the candidate data interface, then the candidate data interface is confirmed to be used to implement the target function.

[0052] Among them, Document Object Model (DOM) evaluation is a programmatic query performed on the Document Object Model structure of the current page in the browser instance to obtain information about the current state of the page.

[0053] Page state information is page structure information obtained by evaluating the Document Object Model. It reflects the rendering state of the current page at a certain moment, including the content displayed on the page and the state characteristics of page elements.

[0054] Page rendering content refers to the visual content that the target site parses and presents on the page after receiving data returned by the data interface; that is, the information ultimately displayed in the user interface.

[0055] In one implementation, after the network listener identifies a candidate data interface, the system performs document object model (DOM) evaluation on the current page of the browser instance to obtain page state information from the DOM of the current page. Based on the data returned by the candidate data interface, the system searches for the page rendering content corresponding to that data in the page state information. If the rendering content corresponding to that data can be located in the page state information (e.g., the product list data returned by the search interface is successfully rendered in the page search results area), then it is confirmed that the candidate data interface is indeed used to implement the target function.

[0056] By performing Document Object Model (DOM) evaluation on the current page and obtaining page state information, the system can verify the correlation between candidate data interfaces and target functions at the page rendering level. This confirms that the data returned by the interface is indeed consumed by the page and used to display corresponding content, and is not merely an irrelevant request at the network level. This verification mechanism provides visual evidence of interface correlation, further improving the accuracy and credibility of candidate data interface selection. Simultaneously, the page state information from DOM evaluation supplements questions that network monitoring cannot directly answer. This allows the interface identification process to not only rely on request characteristics at the network level but also perform cross-validation of the usage of the interface's returned data at the page level, achieving complete link confirmation from request initiation to data rendering, further improving the accuracy of candidate data interface identification.

[0057] Optionally, after generating automated tool code for performing the target function using a large language model, the following may also be included: Based on the calling paradigm, extract the input parameter information and output data structure information of the automation tool code; based on the calling paradigm, determine the calling constraint information of the automation tool code; based on the input parameter information, output data structure information, and calling constraint information, generate a user manual document for the automation tool code.

[0058] The input parameter information is the external data that needs to be passed in when calling the automation tool code. It is used to specify the specific conditions for the execution of the target function, such as search keywords and pagination page numbers.

[0059] Output data structure information is a structural description of the data results returned after the automation tool code is executed. It describes which fields the returned data contains and the data types of each field, so that the caller can correctly parse the returned results.

[0060] Call constraint information refers to the restrictions that must be followed when calling automation tool code, such as call frequency limits, required parameters, and error code definitions.

[0061] The accompanying user manual is a structured document that records input parameter information, output data structure information, and calling constraint information. The accompanying user manual is used by other intelligent agents to call the automation tool code based on the input parameter information, output data structure information, and calling constraint information.

[0062] Other agents are those other than the agent that generated the automation tool code; they refer to all external agents that might call the automation tool code.

[0063] In one implementation, the system extracts the input parameter information required to invoke the automation tool code from the invocation paradigm, including the parameter name, type, and meaning, as well as the output data structure information of the returned data after the invocation, including the field names and data types. Simultaneously, the system determines the invocation constraint information when invoking the automation tool code based on the invocation paradigm. Finally, the system structures and organizes the above three types of information to generate a corresponding user manual. This document allows other intelligent agents to construct invocation requests based on the input parameter information in the document, parse the returned results based on the output data structure information, and comply with invocation restrictions according to the invocation constraint information when invoking the automation tool code.

[0064] By generating accompanying user manuals, the automated tool code can be correctly understood and invoked by other agents. Other agents do not need to re-execute the interface probing and verification process; they can obtain the complete information required to invoke the automated tool code simply by reading the document, achieving cross-agent code reuse. The document records input parameter information, output data structure information, and invocation constraint information in a structured format, ensuring a clear standard for the invocation process and avoiding invocation errors caused by incomplete information or misunderstandings. When multiple agents need to invoke the same automated tool code, they do not need to repeatedly execute the probing and verification process; a single document can support multiple agents in completing the invocation, reducing the cost of repeated probing.

[0065] Example 2 Figure 2 This is a flowchart illustrating another method for generating automated tool code according to Embodiment 2 of the present invention. It further optimizes and expands the above technical solution and can be combined with the various optional implementation methods described above. For example... Figure 2 As shown, the method includes: S201. Obtain the probe task for the target function of the target site, parse the probe task, obtain the Uniform Resource Locator (URL) of the target site, and call the browser startup command to create a browser instance; load the URL in the browser instance to navigate to the target site.

[0066] The Uniform Resource Locator (URL) is a unique access address for a target site within a network, used to locate and identify the entry point of the target site.

[0067] The browser launch command is a program call instruction used to create a browser instance. By executing this command, the system starts a real browser process in the operating system, which is the browser instance that provides the runtime environment for subsequent operations.

[0068] In one implementation, after receiving a probe task, the system parses the task and extracts the Uniform Resource Locator (URL) of the target site. Then, the system invokes a browser startup command to create a new browser instance in the operating system. Once the browser instance starts, the system loads the previously extracted URL into its address bar or navigation area, navigating the browser instance to the target site page and completing the initialization of the runtime environment.

[0069] By parsing the probing task to obtain Uniform Resource Locators (URLs), the system converts the user's ambiguous natural language requests into precise network addresses, realizing the transformation from intent to executable instructions. By invoking the browser launch command to create a real browser instance, it provides a realistic browser runtime environment for all subsequent network monitoring, interface identification, and interface call operations. This ensures that the interface information obtained later originates from the actual runtime state of the target site, distinguishing it from pure HTTP client simulation or inference based on training data. Loading the URL in the browser instance to complete navigation ensures that all subsequent operations are executed within the real page context of the target site, laying the foundation for the runtime environment of the entire technology chain.

[0070] S202. Enable network listening for the browser instance and capture network requests initiated by the browser instance to the target site through network listening.

[0071] S203. Obtain the preset request features corresponding to the target function, match the captured network request information with the preset request features, and take the data interface corresponding to the successfully matched network request as the candidate data interface.

[0072] Among them, a network request is an HTTP communication initiated by a browser instance to the backend server of a target site during runtime, used to obtain data or submit information.

[0073] Preset request features are a set of matching conditions pre-defined for a target function, used to filter candidate data interfaces from network requests. Preset request features include at least one of the following: request Uniform Resource Locator (URI) path features, request response data format features, request header keywords, and request parameter features.

[0074] The path characteristics of a request Uniform Resource Locator (URL) are path patterns in the URL of a network request that indicate whether the request is a data interface, such as the URL containing specific path keywords.

[0075] The request-response data format characteristics are the format type of the response data corresponding to the network request, used to determine whether the request returns structured data, such as JSON format.

[0076] Request header keywords are specific fields or identifiers contained in the request header of a network request, used to help identify whether the request is a data interface.

[0077] Request parameter characteristics are specific patterns of query strings or request body parameters carried in a network request, used to further confirm whether the request is a data interface on which the target function depends.

[0078] In one implementation, the system enables network listening after the browser instance navigates to the target site, capturing all network requests initiated by the browser instance to the target site in real time. Subsequently, the system obtains preset request characteristics corresponding to the target function. These characteristics include at least one of the following: request Uniform Resource Locator (URI) path characteristics, request response data format characteristics, request header keywords, and request parameter characteristics. For each captured network request, the system compares its URI, response data format, request header information, and request parameters one by one with the characteristics configured in the preset request characteristics. If the network request satisfies all the characteristics in the preset request characteristics, the data interface corresponding to the network request is identified as a candidate data interface.

[0079] By enabling network monitoring to capture network requests generated during the target site's operation in real time, the system can discover the data interfaces relied upon by the target function without relying on site developer documentation or manual analysis. By acquiring preset request characteristics corresponding to the target function and matching the captured network requests based on these characteristics, the system automates the screening of candidate data interfaces. The data interfaces corresponding to successfully matched network requests are used as candidate data interfaces, providing an initial set of interface candidates for subsequent real interface calls and verification, ensuring a complete source input for the entire technology chain.

[0080] S204. Obtain the interface call parameters of the candidate data interface, and while the browser instance maintains the user login state of the target site, construct script code containing the interface call parameters; inject the script code into the JavaScript context of the browser instance to execute at least one real interface call and obtain a response sample.

[0081] In this context, the user login state is a session credential established after a user has been authenticated when accessing a target site. It serves to prove that the user has been verified. Maintaining the user login state in the browser instance ensures that subsequent legitimate API calls can pass the target site's authentication verification and return complete user-level data, avoiding request failures or incomplete data due to unauthentication.

[0082] Script code is a sequence of executable instructions written in a programming language, used to perform specific operations within a browser instance. In this embodiment of the invention, the script code includes interface call parameters and, after being injected into the browser instance, directly initiates HTTP requests through its programming interface. The script code executes independently of manual user operations, avoiding dependence on user interface interaction.

[0083] The JavaScript context is the runtime environment within a browser instance used to execute JavaScript code. After script code is injected into the browser instance's JavaScript context, that script code becomes part of the current page's runtime environment, capable of initiating HTTP requests by calling the browser's network request interfaces and receiving the returned response data. The JavaScript context is the execution location within the browser instance for the actual API calls.

[0084] In one implementation, while the browser instance maintains the user's logged-in state to the target site, the system constructs script code based on the API call parameters. This script code includes information such as the endpoint Uniform Resource Locator (URI), request header fields, and request parameters, and is used to initiate a complete HTTP request to the target site. The system injects this script code into the browser instance's JavaScript context, allowing the script code to execute automatically within the browser instance, initiating the actual API call independently of the user interface. After execution, the system receives the response data returned by the target site as a response sample.

[0085] By maintaining the user's login state on the target site within the browser instance, real API calls can pass the target site's authentication and permission checks, ensuring that the obtained response samples contain complete user-level data. This avoids data loss or API unavailability due to authentication failures, and ensures that the response samples have the same data integrity and authenticity as when the user actually accesses the site.

[0086] By constructing script code and injecting it into the JavaScript context of the browser instance to execute the actual API call, the API call process is decoupled from the user interface interaction. The actual API call is initiated directly by the script code within the browser instance, without relying on manual user actions such as clicks or input on the page, and the obtained response samples correspond exactly to the data returned by the API itself. Furthermore, the execution mode of the injected script code does not depend on the selectors or operation coordinates of user interface elements, fundamentally differentiating the subsequently generated automated tool code from recording and playback solutions.

[0087] By obtaining response samples, the execution results of real interface calls are recorded as verifiable structured data, providing operable objects for subsequent verification and key input data for the entire technology chain.

[0088] S205. Parse the response sample to obtain the field name and data type of each field in the response sample; for each field, match the field name with the preset semantic tag set; if the match is successful, determine whether the data type of the field is consistent with the expected data type associated with the successfully matched semantic tag; if they are consistent, determine the field as a semantically validated field.

[0089] The field name is the name identifier of each data field in the response sample. It is used to identify the meaning of the data carried by the field and is the basic unit for semantic matching in the validation.

[0090] Data type refers to the specific type of data contained in each field of the response sample, such as string, number, boolean, array, object, etc., and is used to confirm whether the data structure of the field is consistent with expectations.

[0091] A semantic tag set is a collection of pre-defined semantic tags, each associated with a specific data type. Semantic tags are used to match field names in response samples to identify the business meaning of those fields.

[0092] The expected data type is the data type predefined for each semantic tag in the semantic tag set. It is used to compare with the actual data type of the corresponding field in the response sample to determine whether the data types match.

[0093] In one implementation, the system parses the response sample, extracting the field names and actual data types of each field. Then, for each field, the system matches its field name against semantic tags in the semantic tag set one by one. If the field name matches a corresponding semantic tag, it further determines whether the actual data type of the field is consistent with the expected data type associated with that semantic tag. If the field name matches successfully and the data type is consistent with the expectation, the field is determined to be a semantically validated field.

[0094] For example, suppose the response sample is {"items":[{"id":1,"name":"Product A"}],"total":1}. After parsing, the system extracts four fields: items (array type), id (numeric type), name (string type), and total (numeric type). The preset semantic tag set includes tags such as items (expected data type is array), id (expected data type is numeric), and total (expected data type is numeric). The system matches the field names of each field with the semantic tag set. Items, id, and total match successfully, and their data types are consistent with expectations. These three fields are determined to be semantically validated and pass the validation. Name does not match any semantic tag. The number of valid fields is 3, reaching the preset threshold, and the response sample passes the validation.

[0095] S206. Count the number of fields that pass semantic validation. If the number reaches a preset threshold, the validation of the response sample is determined to be passed.

[0096] In one implementation, after completing semantic validation field by field, the system counts the number of all fields marked as having passed semantic validation and compares this number with a preset threshold. If the number of passing fields reaches or exceeds the preset threshold, the entire response sample is deemed to have passed validation; otherwise, it is deemed to have failed, and the process returns to adjust the probing logic before being re-executed.

[0097] This invention verifies whether a field has a identifiable business meaning by matching the field names of each field in the response sample with a set of semantic tags. Furthermore, it verifies whether the actual data structure of the field matches the expected data type by determining whether the field's data type is consistent with expectations. This dual verification mechanism provides an objective standard for judgment: matching field names ensures that the business meaning of the field can be identified, and matching data types ensures that the field's data structure meets expectations.

[0098] By counting the number of fields that pass semantic validation and comparing them with a preset threshold, this embodiment of the invention provides a quantifiable judgment benchmark for validation. Only when the response sample has a sufficient number of fields that pass semantic validation is the subsequent code generation stage allowed, thus avoiding the situation where the generated automated tool code cannot correctly parse the response data due to too few identifiable fields in the response sample.

[0099] Through the above verification mechanism, the verification can ensure that the code generation stage is only entered when the data returned by the interface has sufficient semantic clarity of the fields. This fundamentally guarantees that the response samples entering the code generation stage have structured semantic information that can be correctly understood and parsed by the large language model, thus avoiding the problem of the large language model generating unreliable code due to insufficient understanding of the response data structure.

[0100] S207. If the verification passes, the call paradigm is formatted and filled according to the preset prompt word template to generate prompt words containing semantic descriptions of the fields including interface call parameters and response samples; the prompt words are input into the large language model to obtain the automated tool code output by the large language model.

[0101] The prompt word template is a pre-defined format framework used to standardize the input structure of the large language model. The prompt word template contains fixed guiding text and reserved padding positions. The guiding text instructs the large language model to perform code generation tasks, and the padding positions accommodate interface information extracted from the calling paradigm.

[0102] Formatted autocomplete is the process of filling in the corresponding positions in the call paradigm with the interface call parameters and the semantic descriptions of the response samples according to the pre-defined positions in the prompt word template. Through formatted autocomplete, the structured but non-natural language information in the call paradigm is converted into a text description that can be understood by a large language model, while preserving the integrity and accuracy of the data.

[0103] The prompt words are the complete input text generated after the calling paradigm is formatted and filled with prompt word templates. They contain instructions to guide the large language model to perform code generation tasks and formatted interface information, which can be directly input into the large language model to obtain the corresponding automated tool code.

[0104] In one implementation, after successful verification, the system obtains a preset prompt template. This template contains fixed guidance instructions and reserved fill positions. The system fills in the interface call parameters and semantic descriptions of response sample fields recorded in the call paradigm one by one according to the reserved fill positions in the template, generating structured prompts. Subsequently, the prompts are input into a large language model, which generates corresponding automated tool code based on the interface information in the prompts.

[0105] By using pre-defined prompt templates, the interface information in the call paradigm is formatted into structured prompts, avoiding comprehension biases in the large language model due to inconsistent input formats. Formatting ensures that the prompt content is completely consistent with the empirical data in the call paradigm, preventing information loss or distortion during transmission. Prompts generated from the same call paradigm using the same template are consistent, ensuring the code output by the large language model remains structurally and logically stable, possessing high determinism and repeatability.

[0106] Example 3 Figure 3 This is a schematic diagram of an automation tool code generation device provided in Embodiment 3 of the present invention. It is applicable to situations requiring the detection of target site data interfaces based on real browser sessions and the automatic generation of browser automation tool code, such as... Figure 3 As shown, the device includes: Detection module 31 is used to obtain a detection task for a target function of a target site, and launch a browser instance and navigate to the target site according to the detection task; The parameter acquisition module 32 is used to identify at least one candidate data interface on which the target function depends by network monitoring of the browser instance, and to acquire the interface call parameters of the candidate data interface. The verification module 33 is used to execute at least one real interface call in the browser instance based on the interface call parameters, obtain a response sample, and verify the response sample. The code generation module 34 is used to generate a corresponding calling paradigm based on the interface call parameters and the response sample when the verification is passed, and to generate automated tool code for performing the target function based on the calling paradigm through a large language model.

[0107] Optionally, the detection module 31 is specifically used for: The probe task is parsed to obtain the Uniform Resource Locator (URL) of the target site, and the browser startup command is invoked to create the browser instance; The Uniform Resource Locator is loaded in the browser instance to navigate to the target site.

[0108] Optionally, the parameter acquisition module 32 is specifically used for: Enable network listening for the browser instance, and capture network requests initiated by the browser instance to the target site through the network listening; Obtain preset request features corresponding to the target function; wherein, the preset request features include at least one of the following: path features of request Uniform Resource Locator, request response data format features, request header keywords, and request parameter features; The captured network request information is matched with the preset request features, and the data interface corresponding to the successfully matched network request is used as the candidate data interface.

[0109] Optionally, the device further includes a data interface verification module, specifically used for: Perform document object model evaluation on the current page of the browser instance to obtain the page state information in the document object model of the current page; If the page status information contains the page rendering content corresponding to the data returned by the candidate data interface, then it is confirmed that the candidate data interface is used to implement the target function.

[0110] Optionally, the interface call parameters include at least one of endpoint Uniform Resource Locator, request header fields, and request parameters.

[0111] Optionally, the verification module 33 is specifically used for: While maintaining the user login state of the target site in the browser instance, construct script code containing the interface call parameters; The script code is injected into the JavaScript context of the browser instance to execute the at least one real interface call and obtain the response sample.

[0112] Optionally, the verification module 33 is further used for: Parse the response sample to obtain the field name and data type of each field in the response sample; For each field, the field name is matched with a preset set of semantic tags; if the match is successful, it is determined whether the data type of the field is consistent with the expected data type associated with the matched semantic tag; if they are consistent, the field is determined as a semantically validated field. The number of fields that pass the semantic verification is counted. If the number reaches a preset threshold, the verification of the response sample is determined to be successful.

[0113] Optionally, the code generation module 34 is specifically used for: The calling paradigm is formatted and filled according to a preset prompt word template to generate prompt words that include the semantic descriptions of the fields of the interface call parameters and the response sample; Input the prompt word into the large language model and obtain the automation tool code output by the large language model.

[0114] Optionally, the device further includes a user manual documentation generation module, specifically used for: Based on the calling paradigm, extract the input parameter information and output data structure information of the automation tool code; Based on the calling paradigm, determine the calling constraint information of the automation tool code; Based on the input parameter information, the output data structure information, and the calling constraint information, a user manual document is generated to accompany the automation tool code. The accompanying user manual is used to enable other intelligent agents to invoke the automation tool code based on the input parameter information, the output data structure information, and the invocation constraint information.

[0115] The automation tool code generation apparatus provided in this embodiment of the invention can execute the automation tool code generation method provided in this embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0116] According to embodiments of this disclosure, embodiments of the present invention also provide an electronic device, a readable storage medium, and a computer program product.

[0117] Figure 4 A schematic diagram of an electronic device 40 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0118] like Figure 4 As shown, the electronic device 40 includes at least one processor 41 and a memory, such as a read-only memory (ROM) 42 or a random access memory (RAM) 43, communicatively connected to the at least one processor 41. The memory stores computer programs executable by the at least one processor. The processor 41 can perform various appropriate actions and processes based on the computer program stored in the ROM 42 or loaded from storage unit 48 into the RAM 43. The RAM 43 may also store various programs and data required for the operation of the electronic device 40. The processor 41, ROM 42, and RAM 43 are interconnected via a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.

[0119] Multiple components in electronic device 40 are connected to I / O interface 45, including: input unit 46, such as keyboard, mouse, etc.; output unit 47, such as various types of monitors, speakers, etc.; storage unit 48, such as disk, optical disk, etc.; and communication unit 49, such as network card, modem, wireless transceiver, etc. Communication unit 49 allows electronic device 40 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0120] Processor 41 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 41 performs the various methods and processes described above, such as methods for generating automated tool code.

[0121] In some embodiments, the method for generating automation tool code may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 48. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 40 via ROM 42 and / or communication unit 49. When the computer program is loaded into RAM 43 and executed by processor 41, one or more steps of the method for generating automation tool code described above may be performed. Alternatively, in other embodiments, processor 41 may be configured to execute the method for generating automation tool code by any other suitable means (e.g., by means of firmware).

[0122] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0123] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0124] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0125] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0126] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0127] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product within the cloud computing service system to address the shortcomings of traditional physical hosts and virtual private servers, such as high management difficulty and weak business scalability.

[0128] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0129] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for generating code for automated tools, characterized in that, include: Obtain a probe task for the target function of the target site, launch a browser instance and navigate to the target site according to the probe task; By monitoring the network of the browser instance, at least one candidate data interface on which the target function depends is identified, and the interface call parameters of the candidate data interface are obtained. Based on the interface call parameters, execute at least one real interface call in the browser instance to obtain a response sample, and verify the response sample; If the verification passes, a corresponding calling paradigm is generated based on the interface call parameters and the response sample. Based on the calling paradigm, automated tool code for executing the target function is generated through a large language model.

2. The method according to claim 1, characterized in that, The step of launching a browser instance and navigating to the target site according to the detection task includes: The probe task is parsed to obtain the Uniform Resource Locator (URL) of the target site, and the browser startup command is invoked to create the browser instance; The Uniform Resource Locator is loaded in the browser instance to navigate to the target site.

3. The method according to claim 1, characterized in that, The step of identifying at least one candidate data interface on which the target function depends through network monitoring of the browser instance includes: Enable network listening for the browser instance, and capture network requests initiated by the browser instance to the target site through the network listening; Obtain preset request features corresponding to the target function; wherein, the preset request features include at least one of the following: path features of request Uniform Resource Locator, request response data format features, request header keywords, and request parameter features; The captured network request information is matched with the preset request features, and the data interface corresponding to the successfully matched network request is used as the candidate data interface.

4. The method according to claim 1, characterized in that, After identifying at least one candidate data interface on which the target function depends through network monitoring of the browser instance, the method further includes: Perform document object model evaluation on the current page of the browser instance to obtain the page state information in the document object model of the current page; If the page status information contains the page rendering content corresponding to the data returned by the candidate data interface, then it is confirmed that the candidate data interface is used to implement the target function.

5. The method according to claim 1, characterized in that, The interface call parameters include at least one of the following: endpoint Uniform Resource Locator, request header fields, and request parameters.

6. The method according to claim 1, characterized in that, The step of executing at least one real interface call in the browser instance based on the interface call parameters to obtain a response sample includes: While maintaining the user login state of the target site in the browser instance, construct script code containing the interface call parameters; The script code is injected into the JavaScript context of the browser instance to execute the at least one real interface call and obtain the response sample.

7. The method according to claim 1, characterized in that, The verification of the response sample includes: Parse the response sample to obtain the field name and data type of each field in the response sample; For each field, the field name is matched with a preset set of semantic tags; if the match is successful, it is determined whether the data type of the field is consistent with the expected data type associated with the matched semantic tag; if they are consistent, the field is determined as a semantically validated field. The number of fields that pass the semantic verification is counted. If the number reaches a preset threshold, the verification of the response sample is determined to be successful.

8. The method according to claim 1, characterized in that, The process of generating automated tool code for performing the target function based on the invocation paradigm and through a large language model includes: The calling paradigm is formatted and filled according to a preset prompt word template to generate prompt words that include the semantic descriptions of the fields of the interface call parameters and the response sample; Input the prompt word into the large language model and obtain the automation tool code output by the large language model.

9. The method according to claim 1, characterized in that, After generating automated tool code for performing the target function based on the invocation paradigm and using a large language model, the method further includes: Based on the calling paradigm, extract the input parameter information and output data structure information of the automation tool code; Based on the calling paradigm, determine the calling constraint information of the automation tool code; Based on the input parameter information, the output data structure information, and the calling constraint information, a user manual document is generated to accompany the automation tool code. The accompanying user manual is used to enable other intelligent agents to invoke the automation tool code based on the input parameter information, the output data structure information, and the invocation constraint information.

10. An apparatus for generating automated tool code, characterized in that, include: The detection module is used to obtain detection tasks for target functions of the target site, launch a browser instance and navigate to the target site according to the detection tasks; The parameter acquisition module is used to identify at least one candidate data interface on which the target function depends by network monitoring of the browser instance, and to acquire the interface call parameters of the candidate data interface. The verification module is used to execute at least one real interface call in the browser instance based on the interface call parameters, obtain a response sample, and verify the response sample. The code generation module is used to generate a corresponding calling paradigm based on the interface call parameters and the response sample when the verification is passed, and to generate automated tool code for performing the target function based on the calling paradigm through a large language model.

11. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a processor to perform the method of any one of claims 1-9.

13. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-9.

Images