Intelligent agent workflow reverse compilation method and device, equipment and medium

Abstract

The application discloses an agent workflow reverse compilation method and device, equipment and medium, the method comprises the following steps: obtaining the target source code and tool set constraint of the target project; based on the target source code, a cross-file data dependency graph is constructed; and based on the cross-file data dependency graph, a candidate workflow subgraph is extracted; based on the tool set constraint, the tool call in the candidate workflow subgraph is verified to obtain a target workflow subgraph; the target workflow subgraph is parameter analyzed to obtain target parameter information, and a directed acyclic graph workflow configuration is generated according to the data flow topological relationship of the target parameter information and the target workflow subgraph; the directed acyclic graph workflow configuration is converted into an agent callable skill package. Thus, by extracting and verifying the workflow and parameter relationship in the source code, an agent callable skill package is generated, improving the workflow extraction accuracy and code reuse efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device and medium for reverse engineering intelligent agent workflow. Background Technology

[0002] With the rapid development of large language models, intelligent agents based on large language models mainly complete complex tasks by generating code, making it difficult to directly reuse the source code written by existing domain experts.

[0003] Currently, code analysis methods typically focus on function calls or local code structure analysis, making it difficult to fully characterize cross-file data dependencies. This results in workflows extracted from source code containing missing tool call relationships or parameter information. Furthermore, existing methods lack constraint validation for the actual toolset of the target project, easily introducing calls to non-target tools or incorrect tools, making it difficult to directly convert the extracted results into an executable workflow for the agent.

[0004] Therefore, how to accurately extract workflows, parameters, and data dependencies from existing source code and convert them into skills that can be invoked by intelligent agents is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of this, one aspect of this application provides a method for reverse engineering an intelligent agent workflow, the method comprising: Obtain the target source code and toolset constraints of the target project; Based on the target source code, a cross-file data dependency graph is constructed; and based on the cross-file data dependency graph, candidate workflow subgraphs are extracted. Based on the toolset constraints, the tool calls in the candidate workflow subgraphs are verified to obtain the target workflow subgraph; The target workflow subgraph is parsed to obtain target parameter information, and a directed acyclic graph workflow configuration is generated based on the target parameter information and the data flow topology of the target workflow subgraph. The directed acyclic graph workflow configuration is converted into a skill package that can be invoked by the agent.

[0006] Optionally, constructing a cross-file data dependency graph based on the target source code includes: Construct the abstract syntax tree corresponding to the target source code; Based on the abstract syntax tree, determine the variable dependencies and tool call relationships in the target source code; Based on the variable dependencies and tool call relationships, data chains with data flow associations are merged to obtain the cross-file data dependency graph.

[0007] Optionally, the step of extracting candidate workflow subgraphs based on the cross-file data dependency graph includes: Identify target nodes, function bodies, consecutive code unit fragments, and cross-file call chains in the target source code; the target nodes include source data nodes and result output nodes. Based on the data dependencies between the target nodes, extract the data processing links from the cross-file data dependency graph; Based on the code complexity and operation type of the function body, extract the function-level call subgraph; Based on the consecutive code unit fragments and their text context, extract the code unit call subgraph; Based on the cross-file call chain, extract the cross-file call sub-graph; The data processing chain, the function-level call subgraph, the code unit call subgraph, and the cross-file call subgraph are selected as candidate workflow subgraphs.

[0008] Optionally, the step of validating tool calls in the candidate workflow subgraphs based on the toolset constraints to obtain the target workflow subgraph includes: Obtain the tool call names and allowed tools indicated by the toolset constraints in the candidate workflow subgraph; The tool call names are standardized to obtain standard tool names; The standard tool name is precisely matched with the allowed tools; the precise matching is to determine whether the standard tool name is consistent with a preset name portion corresponding to any of the allowed tools. If the exact match fails, a fuzzy match is performed based on name similarity. If the fuzzy matching fails, a fallback matching is performed based on the tool mapping relationship corresponding to the target project, and the legality of the matching result is verified based on a preset tool whitelist. The tool calls that have passed the verification in the candidate workflow subgraph are retained to obtain the target workflow subgraph.

[0009] Optionally, after extracting candidate workflow subgraphs, the following may also be included: Obtain the subgraph features of the candidate workflow subgraph; the subgraph features include at least one of the following: domain tool library coverage information, code complexity, call path length, annotation ratio, and subgraph extraction type; Based on the subgraph features, the candidate workflow subgraphs are classified into quality levels; wherein, the quality level is used to indicate the parameter parsing strategy corresponding to the candidate workflow subgraph.

[0010] Optionally, the step of parsing the target workflow subgraph to obtain target parameter information includes: Based on the results of the quality level classification, the target quality level of the target workflow subgraph is determined; Determine whether the target quality level meets the preset quality conditions; If satisfied, the target parameter information is obtained by parsing the dynamic variables in the target workflow subgraph using the cascaded parameter parsing strategy. If the conditions are not met, the core tool calls and parameter information of the core tool calls are extracted from the target workflow subgraph to obtain the target parameter information.

[0011] Optionally, the cascaded parameter parsing strategy includes a static type reverse inference strategy, a sandbox execution parsing strategy, and a semantic annotation parsing strategy; the step of parsing the dynamic variables in the target workflow subgraph through the cascaded parameter parsing strategy to obtain the target parameter information includes: The static type reverse inference strategy is used to determine the objective function into which the dynamic variables flow and the parameter positions of the dynamic variables in the objective function. The target parameter type of the dynamic variable is determined based on the type constraint corresponding to the parameter position in the function signature of the target function; If the type of the target parameter cannot be uniquely determined, the runtime parameter information of the dynamic variable during the simulation execution process is obtained through the sandbox execution parsing strategy. If complete runtime parameter information is not obtained, the semantic annotation parsing strategy is used to semantically annotate the context code of the dynamic variable to obtain the target parameter information.

[0012] Optionally, obtaining the runtime parameter information of the dynamic variables during the simulated execution process through the sandbox execution parsing strategy includes: Based on the downstream usage nodes of the dynamic variable in the target workflow subgraph, determine the operational semantic constraints corresponding to the dynamic variable; the operational semantic constraints include at least one of spatial relationship constraints, coordinate reference constraints, time index constraints, data validity constraints, data field constraints, and data attribute constraints. Based on the operational semantic constraints, generate simulated test data; In an isolated execution environment, the code snippet corresponding to the target workflow subgraph is executed based on the simulated test data; Obtain the runtime value and runtime type of the dynamic variable to obtain the runtime parameter information.

[0013] Optionally, the step of semantically annotating the context code of the dynamic variable using the semantic annotation parsing strategy to obtain the target parameter information includes: Obtain the context code and auxiliary parsing information of the dynamic variables; the auxiliary parsing information includes upstream dependency information, downstream usage information, toolset constraints, and parsed parameter information; The context code and the auxiliary parsing information are input into a pre-trained semantic annotation model to generate candidate parameter information for the dynamic variable; the candidate parameter information includes parameter name, parameter type, parameter semantic role, and parameter value constraints. The candidate parameter information is subjected to consistency verification, and the candidate parameter information that passes the verification is used as the target parameter information.

[0014] Optionally, based on the target parameter information and the data flow topology of the target workflow subgraph, a directed acyclic graph workflow configuration is generated, including: Based on the data flow topology, determine the data dependencies between tool calls in the target workflow subgraph; When multiple tool calls are executed sequentially based on the same data chain, the multiple tool calls are determined to be in a sequential execution relationship; When multiple tool calls are executed based on independent data chains and converge to a target tool call, the multiple tool calls are determined to be executed in parallel. The directed acyclic graph workflow configuration is generated based on the target parameter information, the data dependencies, and the sequential execution relationships and / or the parallel execution relationships.

[0015] Optionally, converting the directed acyclic graph workflow configuration into a skill set that can be invoked by the agent includes: Generate parameter description information corresponding to the intelligent agent workflow based on the target parameter information; Semantic annotation is performed on the tool call nodes and external input parameter nodes in the directed acyclic graph workflow configuration to generate a framework-independent generic workflow description; Based on the interface protocol of the target intelligent agent framework, the general workflow description is mapped to framework adaptation information that conforms to the interface protocol; The skill pack is generated based on the parameter description information, the framework adaptation information, and the directed acyclic graph workflow configuration.

[0016] Another aspect of this application provides a reverse engineering apparatus for an intelligent agent workflow, the apparatus comprising: The data acquisition module is used to acquire the target source code and toolset constraints of the target project; The workflow extraction module is used to construct a cross-file data dependency graph based on the target source code; and to extract candidate workflow subgraphs based on the cross-file data dependency graph. The tool verification module is used to verify the tool calls in the candidate workflow subgraph based on the toolset constraints to obtain the target workflow subgraph. The configuration generation module is used to parse the target workflow subgraph to obtain target parameter information, and generate a directed acyclic graph workflow configuration based on the target parameter information and the data flow topology relationship of the target workflow subgraph. The skill pack generation module is used to convert the directed acyclic graph workflow configuration into a skill pack that can be invoked by the agent.

[0017] Another aspect of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor executes the computer program to implement the steps of a reverse engineering method for the intelligent agent workflow.

[0018] Another aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the reverse compilation method for the agent workflow.

[0019] The reverse engineering method, apparatus, device, and medium for intelligent agent workflow provided in this application have the following beneficial effects: By constructing a cross-file data dependency graph and extracting candidate workflow subgraphs from the target source code, tool calls and their data dependencies can be identified from the cross-file code. Furthermore, by verifying tool calls in conjunction with the toolset constraints of the target project, the impact of non-target tools or erroneous tool calls on the workflow extraction results can be reduced. Based on this, parameter parsing is performed on the target workflow subgraph, and a directed acyclic graph workflow configuration is generated by combining data flow topology relationships. This configuration is then converted into a skill package that can be called by the intelligent agent, thereby achieving automatic extraction and structured conversion of workflow logic and parameter relationships in existing source code, improving the accuracy and reusability of source code to intelligent agent skills. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating a reverse engineering method for an intelligent agent workflow provided in an embodiment of this application.

[0021] Figure 2 This is a schematic diagram illustrating the principle of constructing a cross-file data dependency graph, as provided in an embodiment of this application.

[0022] Figure 3 This is a schematic diagram illustrating the principle of extracting candidate workflow subgraphs according to an embodiment of this application.

[0023] Figure 4 This is a schematic diagram illustrating the principle of obtaining a target workflow subgraph, as provided in an embodiment of this application.

[0024] Figure 5 This is a schematic diagram illustrating the principle of obtaining target parameter information provided in an embodiment of this application.

[0025] Figure 6 This is a schematic diagram of the structure of a reverse engineering device for an intelligent agent workflow provided in an embodiment of this application.

[0026] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0027] The attached diagram is labeled as follows: 60 is the data acquisition module, 61 is the workflow extraction module, 62 is the tool verification module, 63 is the configuration generation module, 64 is the skill pack generation module, 70 is the memory, 71 is the processor, 72 is the display screen, 73 is the input / output interface, 74 is the communication interface, 75 is the power supply, 76 is the communication bus, 701 is the computer program, 702 is the operating system, and 703 is the data. Detailed Implementation

[0028] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0029] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0030] With the development of large language model technology, intelligent agents based on large language models are gradually being applied to complex tasks such as scientific computing and spatial data analysis. Currently, intelligent agents typically complete tasks by "generating code and executing it," but this approach still has certain limitations in complex toolchain scenarios.

[0031] On the one hand, large language models struggle to fully perceive the actual toolkit and parameter interfaces configured in the target project. This can lead to issues such as calling non-existent tools, mismatched function names, or incorrect parameters, impacting the stability and reliability of code execution. On the other hand, the open-source community has accumulated a wealth of interactive computing notebooks and Python scripts containing mature data processing workflows and tool calling logic. However, current technology lacks a mechanism to automatically convert the data dependencies, tool call chains, and parameter passing relationships in such code into workflows that can be invoked by intelligent agents, hindering the full reuse of existing code resources.

[0032] On the other hand, traditional static analysis methods based on Abstract Syntax Trees (ASTs), call graphs, or program slices struggle to accurately determine the actual call parameters and their types in cases of dynamic string concatenation, runtime variables, and dynamic types, easily leading to incomplete workflow parameter information parsing. Furthermore, different projects allow different sets of tools, and existing methods typically lack mechanisms to validate the extracted tool calls against the project's actual toolset, potentially introducing invalid or erroneous tool calls.

[0033] Furthermore, different code snippets vary in structural completeness, complexity, and reusability. Existing methods typically employ a uniform parsing strategy, making it difficult to balance extraction efficiency and parsing accuracy. For code that requires obtaining dynamic parameters through simulated execution, existing test input data is often generated based on data type or random rules, failing to adequately consider the semantic constraints of subsequent operations. For example, spatial topology operations require input objects to satisfy specific spatial relationships, while aggregation operations may require input data to contain valid numeric fields. If the simulated data does not meet these logical preconditions, it may result in empty execution results or parameter extraction failure.

[0034] Therefore, the technical problem to be solved is how to improve the accuracy of tool calls, dynamic parameter parsing capabilities, project adaptability, and code resource reuse efficiency during the conversion of existing code into intelligent agent workflows.

[0035] To address the aforementioned technical issues, this application provides a reverse compilation method for agent workflows. It should be noted that the reverse compilation (RC) method in this application does not involve the agent regenerating a workflow, but rather extracting a workflow that characterizes the data processing process from the source code of an existing project and converting the extracted workflow into a skill set that the agent can directly invoke.

[0036] Furthermore, it should be noted that the method provided in this application embodiment can be executed by an electronic device with code parsing, data processing and program execution capabilities, and the electronic device can be a server, local development terminal, cloud platform, code analysis platform or processing node integrated into the intelligent agent development system. There is no limitation on the execution subject of the method provided in this application.

[0037] Figure 1 This is a flowchart illustrating a reverse engineering method for an intelligent agent workflow provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes: S10: Obtain the target source code and toolset constraints of the target project; In a specific embodiment, firstly, the target source code and toolset constraints of the target project are obtained. The target project can be a code project containing one or more source code files. The target source code may include Python scripts, interactive computing notebooks, and other code files related to the target functionality within the project; this application does not limit the scope of the source code.

[0038] Toolset constraints are used to limit the tools that are allowed to be used in a target project. They can be determined based on the tool libraries that are actually imported or configured in the target project, such as project dependency files, import statements, external knowledge tables, or pre-configured project tool mapping files.

[0039] S11: Based on the target source code, construct a cross-file data dependency graph; and based on the cross-file data dependency graph, extract candidate workflow subgraphs; After obtaining the target source code, a cross-file data dependency graph is constructed based on the target source code. Specifically, in one optional embodiment, the target source code can be parsed and an Abstract Syntax Tree (AST) can be constructed. The AST is used to trace the data sources of different variables, the assignment relationships between variables, and the associations between variables and function calls. Related data chains located in different source code files are then associated and merged to form a cross-file data dependency graph. The cross-file data dependency graph can represent the variables, tool calls, and their data transfer relationships in the target source code through directed connections between nodes.

[0040] Furthermore, candidate workflow subgraphs are extracted based on the cross-file data dependency graph. In one optional embodiment, specific data dependency structures with workflow characteristics can be determined from the cross-file data dependency graph based on the data processing link between the data source and the data output, the complex operation logic inside functions, the processing flow formed by consecutive code units, and the call link between different source code files. These local data dependency structures are then used as candidate workflow subgraphs. Thus, by extracting candidate workflow subgraphs, code call relationships that reflect the complete task processing process can be filtered from the large number of code structures contained in the project.

[0041] S12: Based on toolset constraints, validate tool calls in candidate workflow subgraphs to obtain target workflow subgraphs; Based on the above embodiments, since the function calls identified in the candidate workflow subgraph are not necessarily all legitimate tools that can be called by the target project, after obtaining the candidate workflow subgraph, the tool calls in the candidate workflow subgraph are verified based on toolset constraints.

[0042] For example, in one optional embodiment, the tool call names identified from the source code can be aliased and normalized, and the normalized tool names can be matched with the allowed tools corresponding to the target project. Tool calls that pass the verification are retained, while tool calls that fail the verification are filtered or re-matched, thereby obtaining the target workflow subgraph. Based on this, in this embodiment, through project-level toolset constraints, tool identification errors caused by function name ambiguity, alias usage, or the mixing of non-target functions can be reduced.

[0043] S13: Perform parameter parsing on the target workflow subgraph to obtain target parameter information, and generate a directed acyclic graph workflow configuration based on the target parameter information and the data flow topology relationship of the target workflow subgraph; After obtaining the target workflow subgraph, parameter parsing is performed on the target workflow subgraph to obtain target parameter information. This target parameter information may include at least one of the following: input parameters corresponding to the tool call, parameter type, parameter value, parameter constraints, and parameter semantics.

[0044] In specific embodiments, for parameters that can be directly determined from the source code, the corresponding parameter information can be obtained based on constants, variable assignment relationships, or function signatures in the code. For dynamic variables that cannot be directly determined from static code, the corresponding parameter information can be further determined by combining function signatures, runtime execution information, or code context semantics. Thus, through parameter parsing, the parameter relationships implicit in variable passing and function call processes in the original code can be converted into structured parameter information suitable for workflow description.

[0045] After obtaining the target parameter information, a directed acyclic graph workflow configuration is generated based on the target parameter information and the data flow topology of the target workflow subgraph. Tool calls in the target workflow subgraph can be mapped to tool nodes in the directed acyclic graph, external input parameters or intermediate variables can be mapped to parameter nodes, and data transfer relationships between different nodes can be mapped to directed edges.

[0046] Furthermore, for multiple tool calls executed sequentially based on the same data chain, corresponding sequential dependencies can be established. For multiple tool calls that process independent data and converge at subsequent nodes, corresponding parallel execution relationships can be established. Thus, the directed acyclic graph workflow configuration can record tool calls, parameter information, and data dependencies between tool calls in a structured form.

[0047] S14: Convert the directed acyclic graph workflow configuration into a skill set that can be invoked by the agent.

[0048] Finally, the directed acyclic graph (DAG) workflow configuration is converted into a skill set that agents can invoke. Specifically, parameter description information corresponding to the agent workflow can be generated based on the target parameter information, and the tool nodes, input parameters, and data dependencies in the DAG can be semantically described to form a general workflow description that is independent of specific agent frameworks.

[0049] Furthermore, based on the interface protocol corresponding to the target intelligent agent framework, the general workflow description is mapped to tool definitions, parameter descriptions, and tool invocation relationships that the target intelligent agent framework can recognize. The generated framework adaptation information, directed acyclic graph workflow configuration, and related parameter description information are then assembled into a skill package. In a specific embodiment, the generated skill package can be loaded by the intelligent agent to invoke the corresponding tools to complete the target task according to the data processing logic extracted from the target source code.

[0050] Therefore, the reverse engineering method for agent workflow provided in this application constructs a cross-file data dependency graph and extracts candidate workflow subgraphs from the target source code, enabling the identification of tool calls and their data dependencies from cross-file code. Furthermore, by verifying tool calls in conjunction with the toolset constraints of the target project, the impact of non-target or erroneous tool calls on the workflow extraction results can be reduced. Based on this, parameter parsing is performed on the target workflow subgraph, and a directed acyclic graph workflow configuration is generated by combining data flow topology relationships. This configuration is then converted into a skill package that can be called by the agent, thereby achieving automatic extraction and structured conversion of workflow logic and parameter relationships in existing source code, improving the accuracy and reusability of source code to agent skills conversion.

[0051] Figure 2This is a schematic diagram illustrating the principle of constructing a cross-file data dependency graph according to an embodiment of this application. In an optional embodiment, the cross-file data dependency graph is constructed based on the target source code, including: constructing an abstract syntax tree corresponding to the target source code; determining variable dependencies and tool call relationships in the target source code based on the abstract syntax tree; and merging data chains with data flow associations based on the variable dependencies and tool call relationships to obtain the cross-file data dependency graph.

[0052] In some embodiments, such as Figure 2 As shown, constructing a cross-file data dependency graph based on the target source code can include processes such as AST construction, variable dependency determination, tool call relationship determination, and data chain merging, thereby organizing the variable passing relationships and tool call relationships scattered in different code files into a unified data flow topology.

[0053] Specifically, the target source code in the target project can be parsed first, and the corresponding Abstract Syntax Tree (AST) can be constructed. The target source code can include target scripts in the target code library and other code files that have call relationships or data associations with the target scripts. For interactive computing notebooks, code units can be pre-extracted and converted into code forms capable of abstract syntax analysis. When constructing the AST, control flow and data processing structures such as conditional statements, loop statements, function call statements, and assignment statements can be preserved, thus obtaining an AST containing control flow information.

[0054] In an alternative embodiment, before constructing the abstract syntax tree, technology stack anchor feature detection and traffic splitting can be performed on the code repository containing the target source code. The anchor library can be a pre-selected core tool library capable of representing the target domain's technology stack, and its call characteristics are used to identify the code's technology stack and value level. The anchor library may include: high-performance and low-level computing anchor libraries, domain data processing anchor libraries, and artificial intelligence and computing engine anchor libraries.

[0055] Among them, high-performance and low-level computing anchor libraries are used to represent columnar storage and in-memory computing engines, multidimensional tensor computing libraries, parallel computing frameworks, or high-performance language binding interfaces, such as DuckDB, Polars, PyArrow, NumPy, TensorFlow, Dask, Ray, PyBind11, or NanoBind. Domain data processing anchor libraries are used to represent geospatial vector processing, raster data reading and writing, spatiotemporal data analysis, spatial geometry operations, or domain data format processing, such as GeoPandas, PySAL, Rasterio, Rioxarray, XArray, Shapely, or PyGEOS. Artificial intelligence and computing engine anchor libraries are used to represent deep learning frameworks, distributed computing execution engines, or automatic differential computing libraries, such as PyTorch, TensorFlow, or JAX.

[0056] Based on the type and number of anchors contained in the code, codebases or code snippets can be divided into different value tiers to determine subsequent processing priorities and resource allocation strategies. For example, high-value tiers may include: code containing at least two domain data processing anchors, code containing at least one domain data processing anchor and one high-performance and low-level computing anchor, or code containing at least one domain data processing anchor and one artificial intelligence and computing engine anchor.

[0057] Furthermore, the medium-value tier can be code that does not meet the high-value tier criteria but contains at least one domain data processing anchor or at least one high-performance and low-level computing anchor. The low-value tier can be code that contains standard data science libraries but does not meet the medium- or high-value criteria. The no-value tier can be code that does not meet the above criteria.

[0058] In an optional embodiment, for the codebase after matching with technology stack anchor features, file roles can also be extracted based on file path and categorized, and recorded in metadata. Files located in the source code directory, core directory, or tool directory can be fully extracted as core implementation files. Files located in the example directory, tutorial directory, script directory, and interactive computing notebooks can be fully extracted as pipeline and example files. Files located in the test directory can be extracted as test and contract files, skipping test files with more than 1000 lines of code. Ordinary Python files located in the documentation directory can be used for documentation configuration noise filtering.

[0059] For interactive computing notebooks, the JSON structure of the notebook file can be parsed to extract code units, IPython line magic commands and unit magic commands can be converted into Python comment annotations, and the execution output meta-information and kernel metadata of the code units can be preserved to form a standard code representation that can continue to perform abstract syntax analysis.

[0060] like Figure 2 As shown, in an optional embodiment, an import alias mapping table corresponding to the target source code can also be obtained. The import alias mapping table records the correspondence between the original library name, the imported object, and the actual call alias in the code file. For example, it records the alias relationships corresponding to import forms such as "import X as Y" and "from X import Y as Z". In a specific embodiment, during subsequent analysis of function calls, the import alias mapping table can be used to restore the call object to the corresponding actual library, module, or function, thereby reducing the differences in call object identification caused by different import aliases used in different code files.

[0061] Building upon the ability to reconstruct the calling object using an import alias mapping table, a domain-related library identification set and a common alias mapping dictionary can be maintained, and the function call source can be determined using a multi-level judgment method. Specifically, this includes: directly checking whether each part of the call name matches the domain library identification set; re-checking after reconstructing the alias according to the common alias mapping dictionary; querying the import alias mapping table corresponding to the target source code; checking whether the call path is prefixed with the domain library name; and performing fuzzy matching when the aforementioned methods fail to determine the call source. Furthermore, a function signature pattern library can be pre-built, for example, a function signature library containing complete signatures of approximately 5000 commonly used functions, for subsequent static type reverse inference.

[0062] Furthermore, the AST can be traversed to identify variable nodes, assignment nodes, and function call nodes related to data processing, and noisy calls that do not participate in the target data processing flow can be filtered out. For example, non-functional calls such as print, display, show, and saveframe, which are mainly used for information display or result presentation, can be filtered out, while tool call nodes related to the target data processing process can be retained to improve the effectiveness of subsequent variable dependency analysis and call relationship analysis.

[0063] When determining variable dependencies, a global variable dependency dictionary can be created. This dictionary records the data sources of each variable in the target project and the dependencies between them, and can be continuously updated across different code files. For a single variable, the dictionary can record the source variables, function calls, expressions, or other data objects that generated it, allowing you to trace the variable's generation and subsequent usage along the data flow.

[0064] See Figure 2In specific embodiments, the determination of variable dependencies can cover multiple assignment patterns. For simple assignment patterns, direct dependencies between variables can be identified. For tuple unpacking patterns, tuple unpacking supports independent records for multi-target assignment. For chained assignment patterns, the data transfer relationship between variables can be determined along the assignment chain, and multiple variables involved in the chained assignment process can be associated with their corresponding data sources.

[0065] In function call assignment patterns, when a variable is generated from the result of a function call, the function call can be used as the data source for the variable, and the variable references in the positional and keyword arguments of the function call can be further traced. When the function call contains nested function calls, the variables involved in the nested calls can be recursively analyzed to establish data dependencies between the outer call, the inner call, and related variables.

[0066] For attribute access assignment patterns, the attribute access chain of a variable can be traced upwards until the corresponding root object is identified, and variable dependencies are established based on the attribute access relationship between the root object and the current variable. For binary operation assignment patterns, the left and right operands in the binary operation expression can be parsed separately, and the source of the variables corresponding to the two operands can be recursively traced to determine the dependency relationship between the operation result variable and each input variable.

[0067] By analyzing the above assignment patterns, the global variable dependency dictionary can be continuously updated, enabling it to represent the data source relationships between variables in the target project. For variables distributed across different code files, cross-file associations can be established by combining function calls, module imports, and variable passing relationships, allowing related variables from different files to be included in the same variable dependency analysis process.

[0068] After obtaining variable dependencies, tool call relationships can be further determined. See also Figure 2 Specifically, a "variable-call" mapping can be established to record which functions or tools call, read, process, or generate each variable. By traversing the function call nodes, the input variables, output variables, and corresponding calling objects involved in the function call can be determined, and a data operation chain can be formed based on the relationship between variables and calls.

[0069] For example, when the same variable is processed by multiple method calls in sequence, the corresponding method chain pattern can be identified, and the consecutive method calls executed on the same object can be organized into an ordered call chain according to the actual data transfer order. For chained calls, intermediate results generated during the chained call process can be identified, and the compound call name can be broken down into the basic variable and the sequence of methods that act on the basic variable in sequence, thereby restoring the data transfer order between the operations in the chained call.

[0070] Based on variable dependencies and tool call relationships, cross-file variable association analysis can be further performed. In a specific embodiment, for variables and call nodes in different code files, the existence of data associations can be determined based on the variable source, function input and output, and import-call relationships, and the variables passed across files can be used as the basis for association between different data chains. For example, when the function output in the first code file is used as input by a function in the second code file, a data dependency connection between the two code files can be established based on this input-output relationship, thereby linking the local data chains that were originally located in different files.

[0071] After completing variable dependency tracking and tool call tracking, data chains with data flow relationships can be merged. Specifically, a reverse dependency mapping can be established based on a global variable dependency dictionary. This mapping records which other variables depend on each variable. For any two data chains, common variable detection and dependency detection can be used to determine whether the two data chains are related. Common variable detection determines whether two data chains contain the same variables or variables with the same data source. Dependency detection determines whether a variable in one data chain is a data source or a subsequent dependency of a variable in another data chain.

[0072] When a common variable or variable dependency is detected between two data chains, a recursive association analysis algorithm can be used to continue searching for other data chains related to the current data chain and merge the data chains that meet the association conditions. It should be noted that recursive association analysis can continue until no new related data chains exist, thereby merging scattered local variable dependencies and tool call relationships into a unified call sequence.

[0073] Therefore, through the above processing, the variable dependencies, tool call relationships, method chain relationships, and cross-file data transfer relationships within different code files of the target project can be uniformly organized to obtain a cross-file data dependency graph. Nodes in the cross-file data dependency graph can be used to represent variables, data objects, or tool calls, while directed connections can be used to represent data dependencies between variables, input-output relationships between variables and tool calls, and data transfer relationships between different tool calls, providing a data foundation for subsequently extracting candidate workflow subgraphs from the cross-file data dependency graph.

[0074] Figure 3This is a schematic diagram illustrating the principle of extracting candidate workflow subgraphs according to an embodiment of this application. In an optional embodiment, based on a cross-file data dependency graph, the extraction of candidate workflow subgraphs includes: identifying target nodes, function bodies, consecutive code unit fragments, and cross-file call chains in the target source code; target nodes include source data nodes and result output nodes; extracting data processing chains from the cross-file data dependency graph based on the data dependencies between target nodes; extracting function-level call subgraphs based on the code complexity and operation type of function bodies; extracting code unit call subgraphs based on consecutive code unit fragments and their textual context; extracting cross-file call subgraphs based on the cross-file call chains; and using the data processing chains, function-level call subgraphs, code unit call subgraphs, and cross-file call subgraphs as candidate workflow subgraphs.

[0075] In specific embodiments, candidate workflow subgraphs can be extracted based on cross-file data dependency graphs, and various workflow subgraph extraction modes can be employed. Specifically, such as... Figure 3 As shown, it can identify target nodes, function bodies, consecutive code unit fragments, and cross-file call chains in the target source code. Target nodes include source data nodes and result output nodes. Source data nodes can be nodes that perform data reading, data loading, or external data access, while result output nodes can be nodes that store execution results, return results, or output data.

[0076] For the data processing chain, a path search can be performed in the cross-file data dependency graph based on the data dependencies between the source data node and the result output node. This can be done using methods such as depth-first search or breadth-first search, tracing along the data dependency direction from the source data node until the result output node is reached. This yields the complete call path connecting the source data node and the result output node, which is then used as the data processing chain. The data processing chain can include multiple tool calls sequentially involved in data reading, process processing, and result output.

[0077] For function-level call subgraphs, code complexity analysis and operation type analysis can be performed on the function bodies in the target source code. Code complexity can be represented using cyclomatic complexity, and operation types can include input / output operations, computational operations, visualization operations, control flow operations, and string processing operations. Function bodies with cyclomatic complexity reaching a preset threshold and the number of operation types reaching a preset threshold can be selected. Based on the data dependencies between variables and utility calls within the function body, the corresponding function-level call subgraph can be extracted. For example, the preset complexity threshold could be 10, and the preset number of operation types could be 3.

[0078] For code unit call subgraphs, consecutive code unit segments within an interactive computing notebook can be identified. For example, a code segment consisting of at least 10 consecutive code units can be extracted, and the Markdown text context associated with this consecutive code unit segment can be obtained. The Markdown text context can include question sentences, key terms, and descriptive text describing the purpose of code processing. Based on the data dependencies between consecutive code units and combined with the expert processing intent represented by the Markdown text context, a code unit call subgraph is extracted.

[0079] For cross-file call subgraphs, cross-file call chains can be identified based on function call relationships and data dependencies between different source code files, and interrelated tool call nodes and variable nodes can be extracted along these chains. For example, cross-file call chains with a call length of at least 3 can be used as the chains to be extracted, thereby forming a cross-file call subgraph.

[0080] Therefore, the method provided in this application embodiment can obtain data processing links, function-level call subgraphs, code unit call subgraphs, and cross-file call subgraphs respectively, and unify the extraction results as candidate workflow subgraphs to extract code call relationships that can reflect the workflow logic of the target source code from different code organization forms and data processing structures.

[0081] Figure 4 This is a schematic diagram illustrating the principle of obtaining a target workflow subgraph according to an embodiment of this application. In an optional embodiment, based on toolset constraints, tool calls in candidate workflow subgraphs are validated to obtain the target workflow subgraph. This includes: obtaining tool call names and allowed tools indicated by toolset constraints in the candidate workflow subgraphs; standardizing the tool call names to obtain standard tool names; performing precise matching between the standard tool names and allowed tools; precise matching involves determining whether the standard tool name matches a preset name portion corresponding to any allowed tool; if precise matching fails, performing fuzzy matching based on name similarity; if fuzzy matching fails, performing a fallback matching based on the tool mapping relationship corresponding to the target project, and validating the matching results based on a preset tool whitelist; retaining the validated tool calls in the candidate workflow subgraphs to obtain the target workflow subgraph.

[0082] In some embodiments, validating tool calls in candidate workflow subgraphs based on toolset constraints can ensure that the extracted tool calls belong to tools actually permitted for use in the target project. See specifically... Figure 4The tool call name to be verified can be obtained from the candidate workflow subgraph, and the allowed tools indicated by the toolset constraints can be obtained. The toolset constraints can be pre-configured at the project level, for example, by reading the legal toolset corresponding to the target project from an external knowledge table and forming a tool constraint dictionary for the target project.

[0083] Furthermore, the tool call names are standardized to obtain standard tool names. Standardization can employ a multi-level mapping approach, including: querying a pre-defined tool mapping dictionary to directly map tool call names; mapping using the complete call name including the module path when the basic function name cannot be matched; identifying the library to which the tool call belongs and standardizing the tool call name based on the corresponding library prefix; and for tool call names that are still undetermined, determining the corresponding standard tool name based on the domain keywords they contain.

[0084] After obtaining the standard tool name, an exact match is performed between the standard tool name and the allowed tools indicated by the toolset constraints. An exact match is determined by comparing the standard tool name with the corresponding preset name portion of each allowed tool. For example, the preset name portion can be a name prefix consisting of the library name, module name, and / or function name used to identify the tool. If a correspondence exists, the exact match is considered successful.

[0085] like Figure 4 As shown, if an exact match fails, a fuzzy match is then performed based on name similarity. Specifically, a sequence similarity matching algorithm can be used to calculate the similarity between the standard tool name and each allowed tool name, and a successful match is determined when the similarity reaches a preset similarity threshold. For example, the preset similarity threshold can be set to 0.8.

[0086] If fuzzy matching still fails, a fallback matching based on the tool mapping relationship corresponding to the target project is performed to further determine candidate allowed tools corresponding to the standard tool name. The fallback matching results are then validated against a pre-defined tool whitelist. This whitelist is formed by calling candidate tool functions one by one in a containerized sandbox environment, recording successfully invoked tool functions. Tool calls not on the whitelist are considered to have failed the validation.

[0087] Finally, the tool calls that pass the above verification are retained in the candidate workflow subgraph, while the tool calls that fail the verification are filtered out to obtain the target workflow subgraph, thereby reducing the impact of tool mismatch and non-target tool calls on subsequent workflow reverse compilation.

[0088] In an optional embodiment, after extracting candidate workflow subgraphs, the method further includes: obtaining subgraph features of the candidate workflow subgraphs; the subgraph features include at least one of domain tool library coverage information, code complexity, call path length, annotation ratio, and subgraph extraction type; classifying the candidate workflow subgraphs into quality levels based on the subgraph features; wherein the quality level is used to indicate the parameter parsing strategy corresponding to the candidate workflow subgraph.

[0089] In a specific embodiment, after extracting candidate workflow subgraphs, the subgraph features of each candidate workflow subgraph can be further obtained, and the candidate workflow subgraphs can be classified into quality levels according to the subgraph features, so that different parameter parsing strategies can be adopted for candidate workflow subgraphs of different quality.

[0090] Specifically, subgraph features may include at least one of the following: domain library coverage information, code complexity, call path length, comment ratio, and subgraph extraction type. Domain library coverage information can be used to characterize the type and number of domain libraries involved in the candidate workflow subgraph. Code complexity can be characterized by the cyclomatic complexity of the function body and the number of operation types it contains. Call path length can be characterized by the number of consecutive call nodes in the candidate workflow subgraph. Comment ratio can be characterized by the proportion of comment content in the function body or code snippet relative to the total code content. Subgraph extraction type can be used to indicate whether the candidate workflow subgraph was extracted from a data processing chain, function-level complex logic, consecutive code unit snippets, or cross-file call chains.

[0091] In one optional embodiment, candidate workflow subgraphs can be divided into multiple quality levels based on subgraph extraction type and domain tool library coverage information. The first quality level can be candidate workflow subgraphs extracted through a complete data processing chain, where the number of domain tool libraries involved in the call path is greater than or equal to a first preset threshold. The second quality level can be candidate workflow subgraphs extracted through a complete data processing chain but involving fewer than the first preset threshold of domain tool libraries, or candidate workflow subgraphs extracted through function-level complex logic extraction or cross-file call chain extraction. The third quality level can be candidate workflow subgraphs extracted based on continuous code unit fragments and their textual context in an interactive computing notebook. Candidate workflow subgraphs that meet preset filtering conditions in terms of code size, call path length, or comment ratio can be classified into a fourth quality level.

[0092] In one optional embodiment, the first preset threshold can be 2, and the cyclomatic complexity threshold used to characterize the function code complexity can be 10. The number of operation types threshold can be 3. The call path length threshold can be 50 nodes, and the comment ratio threshold can be 50%. The above thresholds can be adjusted according to the code size, domain type, and processing resources of the project to be analyzed, and this application does not limit them.

[0093] In another optional embodiment, the fourth preset threshold for filtering at the fourth quality level can be 1000 lines. When the number of lines of code in a candidate workflow subgraph is less than the fourth preset threshold, the call path length exceeds the fifth preset threshold (e.g., 50 nodes), or the percentage of function body comments exceeds the sixth preset threshold (e.g., 50%), it can be classified as belonging to the fourth quality level. For candidate workflow subgraphs obtained through multiple extraction modes, the extraction results can also be converted into a unified format and sorted according to quality level or preset priority.

[0094] The quality level indicates the subsequent parameter parsing strategy. For example, a complete cascaded parameter parsing strategy can be used for high-quality candidate workflow subgraphs that can comprehensively reflect the domain data processing flow. For candidate workflow subgraphs with relatively low quality, a simplified parameter extraction method can be used, thereby avoiding investing too many dynamic execution or semantic parsing resources in low-value code snippets.

[0095] Based on the above embodiments, as an optional embodiment, parameter parsing is performed on the target workflow subgraph to obtain target parameter information, including: determining the target quality level of the target workflow subgraph according to the quality level classification results; determining whether the target quality level meets the preset quality conditions; if it meets the conditions, then the dynamic variables in the target workflow subgraph are parsed through a cascaded parameter parsing strategy to obtain the target parameter information; if it does not meet the conditions, then the core tool calls and the parameter information of the core tool calls in the target workflow subgraph are extracted to obtain the target parameter information.

[0096] In some embodiments, after completing the quality level classification of candidate workflow subgraphs and tool call verification, the target quality level corresponding to the target workflow subgraph can be determined based on the quality level classification results, and the corresponding parameter parsing method can be selected based on the target quality level.

[0097] Specifically, it can be determined whether the target quality level meets preset quality conditions. Preset quality conditions can be set based on whether a full parameter analysis of the target workflow subgraph is required. For example, the first and second quality levels can be set to meet the preset quality conditions to perform a more complete parameter analysis of the dynamic variables within them. For workflow subgraphs such as the third quality level that do not meet the preset quality conditions, a simplified analysis method is used.

[0098] When the target quality level meets the preset quality conditions, the dynamic variables in the target workflow subgraph can be parsed using a cascaded parameter parsing strategy. The cascaded parameter parsing strategy sets up multiple parsing levels in the order of static analysis, dynamic execution, and semantic analysis. It only enters the next level when the parameter information that meets the requirements cannot be obtained at the current level. This avoids directly executing containerized isolated execution environment (hereinafter referred to as sandbox) or semantic model parsing on dynamic variables that can be parsed with low processing cost.

[0099] When the target quality level does not meet the preset quality conditions, a complete three-level cascaded analysis can be skipped. Instead, the core tool calls that characterize the main data processing flow can be identified from the target workflow subgraph, and the corresponding parameter information can be extracted. This extracted parameter information is then used as the target parameter information. For example, for a target workflow subgraph obtained from an interactive computing notebook fragment, the main processing intent can be determined by combining the text context associated with the code unit, and the core tool calls constituting this processing intent can be extracted, thus forming a simplified description of the tool calls and parameters.

[0100] It should be noted that the cascading parameter parsing strategy refers to using multiple parameter parsing methods sequentially in a preset order, and triggering the next parameter parsing method to parse parameters if the previous method fails to obtain parameter information that meets the preset conditions. The static rule parsing strategy refers to extracting tool calls and corresponding parameter information from the target workflow subgraph based on its static code information and according to preset parsing rules, without dynamically executing the target workflow subgraph.

[0101] Therefore, by selecting different parameter parsing methods according to the quality level, code snippets with high workflow reuse value can obtain more complete parameter parsing, while reducing the processing resource consumption caused by dynamic execution and semantic parsing of low-quality or simplified example code.

[0102] Figure 5This is a schematic diagram illustrating the principle of obtaining target parameter information according to an embodiment of this application. In an optional embodiment, the cascaded parameter parsing strategy includes a static type back inference strategy, a sandbox execution parsing strategy, and a semantic annotation parsing strategy. The cascaded parameter parsing strategy parses the dynamic variables in the target workflow subgraph to obtain target parameter information, including: determining the target function into which the dynamic variables flow and the parameter positions of the dynamic variables within the target function using the static type back inference strategy; determining the target parameter type of the dynamic variables based on the type constraints corresponding to the parameter positions in the function signature of the target function; if the target parameter type cannot be uniquely determined, obtaining the runtime parameter information of the dynamic variables during the simulated execution process using the sandbox execution parsing strategy; and if complete runtime parameter information is not obtained, semantic annotation of the context code of the dynamic variables is used to obtain the target parameter information using the semantic annotation parsing strategy.

[0103] In some embodiments, the cascaded parameter parsing strategy includes a static type reverse inference strategy, a sandbox execution parsing strategy, and a semantic annotation parsing strategy. These three strategies are executed sequentially in a preset order, and the next level of parsing is triggered only if the previous level fails to obtain the required parameter information.

[0104] like Figure 5 As shown, the first level is static type reverse inference. For dynamic variables in the target workflow subgraph that cannot be directly parsed as constants, we can first determine the target function into which the dynamic variable will ultimately flow as a parameter, and determine the parameter position of the dynamic variable in the target function. In addition, the system can query the preset function signature pattern library or application interface pattern dictionary to obtain the type constraints corresponding to each parameter position in the target function, and reverse-read the type requirements corresponding to the parameter positions of the dynamic variable, thereby determining the target parameter type of the dynamic variable.

[0105] For example, when a dynamic variable is used as the first input parameter of a utility function, the function signature of the utility function can be queried, and the type declaration corresponding to the first parameter position can be read. If the type declaration can be uniquely identified as a single type, the first-level parsing can be considered successful, and the corresponding type can be used as the target parameter type. If the target function does not exist in the function signature pattern library, or the type requirement for the parameter position is a polysemous union type that cannot be uniquely identified, such as Union[str, Path, BytesIO], the first-level parsing can be considered a failure, and the second-level parsing can proceed. It should be noted that the upstream variable type information already obtained in the first level can be passed to the second level.

[0106] During the first-level static type back-inference process, when a dynamic variable is finally used as a parameter in a known objective function, the upstream complex assignment subtree corresponding to that dynamic variable can be folded as a whole and mapped to a standard external input variable to reduce the impact of the intermediate assignment structure on the parameter description. The success conditions for the second-level sandbox execution can be further limited to: the isolated execution environment ending normally within a preset timeout period, for example, exiting normally within 30 seconds, and the variable values ​​captured by the runtime monitoring probe passing the type consistency check; otherwise, proceeding to the next level of parsing.

[0107] See Figure 5 The second level is sandbox execution resolution. When static type inference cannot uniquely determine the parameter information of a dynamic variable, logically consistent simulated test data can be generated based on the operational semantic constraints of the subsequent use of the dynamic variable. This simulated test data is then used to drive the corresponding code snippet to run in an isolated execution environment. Runtime monitoring is used to obtain the runtime values ​​and runtime types of the dynamic variable. When the code snippet executes normally and obtains complete runtime parameter information, the second level of resolution can be considered successful.

[0108] When the sandbox execution times out, runs abnormally, crashes, or fails to capture complete dynamic variable information because the simulation test data cannot meet the requirements of subsequent operations, it can be determined that the second-level parsing has failed, and the context code containing dynamic variables and the auxiliary parsing information that has been obtained will be passed to the third level.

[0109] See Figure 5 The third level is semantic annotation and parsing. A pre-trained semantic annotation model analyzes the context code and business semantics of dynamic variables to generate candidate parameter information for those variables. This candidate parameter information is then validated for consistency using project toolset constraints, function signatures, and other information. The validated candidate parameter information can then be used as the final target parameter information.

[0110] Therefore, dynamic variables that can be determined statically do not need to be parsed in subsequent analysis; only variables that fail static analysis are executed in the sandbox, and variables that still cannot be parsed in the sandbox are then processed by semantic annotation, thus realizing a sequential relay between multi-level parameter parsing methods.

[0111] Based on the above embodiments, as an optional embodiment, a sandbox execution parsing strategy is used to obtain runtime parameter information of dynamic variables during the simulated execution process. This includes: determining the operational semantic constraints corresponding to the dynamic variables based on the downstream usage nodes of the dynamic variables in the target workflow subgraph; the operational semantic constraints include at least one of spatial relationship constraints, coordinate reference constraints, time index constraints, data validity constraints, data field constraints, and data attribute constraints; generating simulated test data based on the operational semantic constraints; executing the code segment corresponding to the target workflow subgraph based on the simulated test data in an isolated execution environment; and obtaining the runtime values ​​and runtime types of the dynamic variables to obtain runtime parameter information.

[0112] In some embodiments, according to Figure 5 It can be seen that when the static type reverse inference cannot uniquely determine the parameter type of a dynamic variable, a sandbox execution resolution strategy guided by operation semantic constraints can be used to obtain the runtime parameter information of the dynamic variable.

[0113] Specifically, before generating simulated test data, a dependency constraint pre-scan can be performed. Starting from the node corresponding to the dynamic variable to be parsed, the downstream nodes using the dynamic variable are traversed downwards along the target workflow subgraph or AST to construct the subsequent operation sequence corresponding to the dynamic variable. For each operation node in the subsequent operation sequence, the operation type, function name, and parameter position can be extracted and matched with a preset operation type rule table to determine the operational semantic constraints imposed by each downstream operation on the input data. Table 1 is a schematic table of operation type rules provided in an embodiment of this application, and the following will be explained in conjunction with Table 1.

[0114] Table 1 is a schematic diagram of one type of operation rule.

[0115] In a specific embodiment, the operation type rule table can establish the correspondence between operation types and preconditions. Referring to Table 1, spatial topology operations correspond to spatial relationship constraints where there are non-empty intersecting regions between geometries; temporal alignment operations correspond to constraints where time indices have overlapping intervals; and projection transformation operations correspond to constraints where the input data has a valid coordinate reference system. Constraints for other operation types are also shown in Table 1 and will not be elaborated here. Based on Table 1, in an optional embodiment, specific constraints may include spatial relationship constraints, coordinate reference constraints, time index constraints, data validity constraints, data field constraints, or data attribute constraints.

[0116] After determining the operational semantic constraints corresponding to multiple downstream operations, the constraints can be combined as input for generating simulation test data. The corresponding simulation test data generator can then be called in conjunction with the data types derived in the first stage to generate simulation test data that can simultaneously meet the requirements of subsequent operations.

[0117] For example, when the data type of the dynamic variable is GeoDataFrame, and subsequent spatial topological intersection operations are included, a baseline polygon can be generated first, and then another offset polygon can be generated with the centroid of the baseline polygon as the center and according to a preset offset, so that there is a non-empty intersection region between the two polygons. When subsequent aggregation operations are included, non-zero values ​​can be assigned to the numerical fields in the simulated test data. When subsequent spatial join operations are included, both simulated datasets can contain geometric columns and use the same coordinate reference system.

[0118] As a specific implementation method for generating spatial relationship constraint simulation test data, a baseline polygon P1 can be created first. Then, an offset polygon P2 can be created with the centroid of P1 as the center and 50% of the radius of the circumcircle of P1 as the offset, to ensure that there is a non-empty intersecting region between P1 and P2. This ratio is only for example, and the actual offset can be adjusted according to the spatial relationship requirements of the target operation.

[0119] In specific embodiments, for tools containing data reading keywords, a simulated data structure with corresponding column names and row numbers can be generated according to the corresponding data format. For tools containing spatial processing keywords, a geographic data frame with a specified coordinate reference system and number of geometric shapes can be generated.

[0120] After generating simulated test data, the code snippets corresponding to the target workflow subgraph and the simulated test data can be combined into an executable script and executed in an isolated execution environment. For example, an isolated execution environment can be built using a pre-configured containerized base image. Before execution, runtime monitoring probes can be injected through runtime function call tracing interfaces, such as using Python's `sys.settrace` mechanism, to intercept method calls from in-memory computing engines, multidimensional tensor computing libraries, or domain data processing frameworks. During code execution, the runtime monitoring probes capture the runtime values ​​and runtime types of dynamic variables and can backfill the captured information into the AST, thereby forming runtime parameter information.

[0121] In one specific implementation, the isolated execution environment can use a pre-configured containerized base image, such as python:3.10-slim, and set a preset execution timeout, such as 30 seconds. If the container exits normally within the preset time and the value of the target variable captured by the runtime monitoring probe passes the type consistency check, the sandbox execution parsing can be determined to be successful; if an execution timeout, runtime exception, or failure to capture the call record corresponding to the target variable occurs, the sandbox execution parsing can be determined to be unsuccessful and trigger the next level of semantic annotation parsing.

[0122] Based on the above embodiments, as an optional embodiment, a semantic annotation parsing strategy is used to semantically annotate the context code of dynamic variables to obtain target parameter information. This includes: obtaining the context code and auxiliary parsing information of the dynamic variables; the auxiliary parsing information includes upstream dependency information, downstream usage information, toolset constraints, and parsed parameter information; inputting the context code and auxiliary parsing information into a pre-trained semantic annotation model to generate candidate parameter information for the dynamic variables; the candidate parameter information includes parameter name, parameter type, parameter semantic role, and parameter value constraints; performing consistency verification on the candidate parameter information, and using the candidate parameter information that passes the verification as the target parameter information.

[0123] In some embodiments, see Figure 5 When the sandbox execution parsing does not obtain complete runtime parameter information, a semantic annotation parsing strategy can be used to further parse dynamic variables.

[0124] Specifically, the context code and auxiliary parsing information corresponding to dynamic variables can be obtained. The context code can include the definition statements, assignment statements, tool call statements, and code snippets related to the usage of the dynamic variables. The auxiliary parsing information can include the upstream dependencies of the dynamic variables, downstream usage information, toolset constraints corresponding to the target project, and parameter information obtained during the parsing phase of the above embodiments. Furthermore, it may also include information such as the project name, upstream variable types, and the function signature digest of the target function.

[0125] Context code and auxiliary parsing information can be organized into structured input and fed into a pre-trained semantic annotation model. The semantic annotation model analyzes the business semantics of dynamic variables in the code and generates corresponding candidate parameter information. The candidate parameter information can include parameter name, parameter type, parameter semantic role, and parameter value constraints. For example, a parameter semantic role can be used to represent a parameter as a file path, field selection parameter, coordinate reference parameter, or other business input. In a specific embodiment, parameter value constraints can be used to represent the allowed data range, format, or candidate values ​​of the parameter.

[0126] In one alternative embodiment, the output of the semantic annotation model can be constrained by a structured prompt template. The prompt template can include the set of tools allowed by the target project, the parsed function signature, the upstream variable types, and the code snippet to be analyzed, and requires the semantic annotation model to output parameter information according to a preset structured format. For example, it can be required that the output tool names come from the set of tools allowed by the target project, the parameter types must be compatible with the corresponding function signatures, and the output should use a parsable JSON structure.

[0127] As an alternative implementation of structured output, the semantic annotation model may be required to output parameter specifications in JSON format, including at least the fields tool_name, params, param_types, and description, where tool_name is constrained by the set of tools allowed by the target project, and param_types is constrained by the type declaration in the signature of the target function.

[0128] After generating candidate parameter information, consistency checks can be performed on it. Consistency checks may include at least: verifying whether the tool name corresponding to the candidate parameter information exists in the target project's allowed tool set; verifying whether the parameter type is compatible with the type declaration at the corresponding parameter position in the function signature library; and verifying whether the output format of the candidate parameter information meets the preset structured format requirements. When the above checks pass, the candidate parameter information can be used as the target parameter information.

[0129] If candidate parameter information fails the consistency check, semantic annotation parsing can be re-executed. For example, the semantic annotation model can be re-called by adding contextual information such as toolset constraints and function signatures, adjusting the prompt structure to provide clearer output instructions, or adding compliant parameter specification examples. In one example, the maximum number of retries can be set to 3. If the candidate parameter information still fails the consistency check after reaching the preset number of retries, the complete semantic parsing for that code snippet can be stopped, and a simplified parameter extraction method can be used to process the corresponding target workflow subgraph to avoid interrupting the entire reverse engineering process due to the failure of parsing a single dynamic variable.

[0130] It should be noted that in the embodiment using quality level management, if the consistency check still fails after reaching the preset number of retries, the corresponding target workflow subgraph can be downgraded to the third quality level and switched to a simplified parameter extraction method, retaining only the core operation sequence and relaxing parameter dependency constraints.

[0131] In one optional embodiment, a directed acyclic graph workflow configuration is generated based on the target parameter information and the data flow topology of the target workflow subgraph, including: determining the data dependencies between tool calls in the target workflow subgraph based on the data flow topology; determining that multiple tool calls are sequentially executed if they are executed based on the same data chain; determining that multiple tool calls are parallelly executed if they are executed based on independent data chains and converge to the target tool call; and generating the directed acyclic graph workflow configuration based on the target parameter information, data dependencies, and sequential and / or parallel execution relationships.

[0132] In some embodiments, after the parameter parsing of the target workflow subgraph is completed, a directed acyclic graph workflow configuration can be generated based on the target parameter information and the data flow topology of the target workflow subgraph.

[0133] Specifically, data dependencies between tool calls can be determined based on variable transit relationships, tool input-output relationships, and parameter dependencies between tool calls within the target workflow subgraph. Specifically, a data dependency exists between a previous tool call and a subsequent tool call when the output data of the previous tool call is used as an input parameter. In a specific embodiment, target parameter information can be used to characterize the input parameters, parameter types, parameter values, and parameter constraints corresponding to each tool call, and then associated with the corresponding tool call.

[0134] Furthermore, execution patterns in the workflow can be identified based on the data dependencies between tool calls. In an optional embodiment, for a data operation chain from a single variable, when multiple tool calls process the same data chain sequentially, and the later tool call depends on the data generated by the previous tool call, the multiple tool calls can be determined to have a sequential execution relationship.

[0135] In another alternative embodiment, for a data operation chain from multiple independent variables, when multiple tool calls are processed based on different data sources or independent intermediate variables, and the processing results are further converged to the same target tool call, the multiple tool calls can be determined as a parallel execution relationship.

[0136] Within the same target workflow subgraph, sequential and parallel execution relationships can coexist. For example, multiple independent data processing branches can each include multiple sequentially executed tool calls. After each data processing branch completes its processing, it converges to the subsequent target tool call, thus forming a data flow topology that combines sequential and parallel execution.

[0137] After determining data dependencies, sequential execution relationships, and / or parallel execution relationships, a directed acyclic graph workflow configuration can be generated by combining target parameter information. Specifically, tool calls can be organized according to the data flow direction of the target workflow subgraph, and the parameter information corresponding to each tool call and the data dependencies between tool calls can be recorded, so that the output of the previous tool call can be passed to the corresponding subsequent tool call according to the data dependencies. In a specific embodiment, for sequential execution relationships, corresponding directed dependencies can be established according to the order of data operation chains. For parallel execution relationships, directed dependencies can be established from each independent tool call to the target tool call.

[0138] The resulting directed acyclic graph workflow configuration can structurally represent tool calls, target parameter information, data dependencies, and sequential and / or parallel execution relationships in the target workflow, providing a workflow structure foundation for subsequently converting the directed acyclic graph workflow configuration into a skill set that can be invoked by the agent.

[0139] Based on the above embodiments, as an optional embodiment, the directed acyclic graph workflow configuration is converted into a skill package that can be invoked by the agent, including: generating parameter description information corresponding to the agent workflow based on target parameter information; semantically annotating the tool invocation nodes and external input parameter nodes in the directed acyclic graph workflow configuration to generate a framework-independent general workflow description; mapping the general workflow description to framework adaptation information conforming to the interface protocol according to the interface protocol of the target agent framework; and generating a skill package based on the parameter description information, framework adaptation information, and directed acyclic graph workflow configuration.

[0140] In a specific embodiment, parameter description information corresponding to the agent workflow can be generated based on the target parameter information. The external input parameter nodes in the directed acyclic graph workflow configuration can be traversed, and the corresponding parameter schema can be generated based on the parameter type, parameter value, and semantic information obtained during the parameter parsing process described in the above embodiment. It should be noted that the parameter schema may include fields such as parameter name, data type, constraints, default values, and natural language description.

[0141] Parameter names can be obtained from the original variable names in the target source code through standardized mapping, such as removing prefix underscores from variable names, converting camelCase to lowercase underscore-separated form, and unifying name suffixes with the same semantics. Data types can be inferred from static types, obtained through type information, or determined by runtime types acquired during sandbox execution. When multiple assignment paths exist for the same parameter, compatible data types can be determined based on the types corresponding to different assignment paths. Constraints can include numerical range constraints, string pattern constraints, and enumeration value constraints, and can be extracted from conditional branches, constant references, or mapping relationships in the target source code, represented by fields such as minimum, maximum, pattern, or enum in JSON Schema. Default values ​​can be extracted from function default parameters or constant assignments. Natural language descriptions can use semantic descriptions generated during the semantic annotation parsing stage. If no corresponding semantic description exists, it can be extracted from the Markdown text context associated with the code, or a parameter description can be generated based on the parameter name and data type.

[0142] For example, for parameters with enumeration value constraints, one can scan the conditional branches for that parameter, extract the constant values ​​compared with the parameter in each branch, or scan the mapping table and dictionary corresponding to the parameter, extracting the corresponding key values ​​as candidate enumeration values. For path type parameters, the corresponding file format constraints can be determined based on the file extensions used in the target source code.

[0143] It should be noted that during the parameter schema generation process, when the same parameter has multiple assignment paths in the code, the greatest common type of the types corresponding to each assignment path can be used as the final data type. When multiple default assignments exist, the value corresponding to the earliest executed assignment path can be used as the default value. For cases where enumeration values ​​come from external JSON or YAML configuration files, the corresponding configuration file can be parsed and a list of candidate enumeration values ​​can be extracted.

[0144] Furthermore, semantic annotation is performed on tool invocation nodes and external input parameter nodes in the directed acyclic graph workflow configuration to generate a generic workflow description independent of specific agent frameworks. The generic workflow description can include the semantic operation type of the tool, the semantic roles and data type constraints of the input parameters, the semantic roles and data types of the output parameters, and the data flow dependencies between tool invocation nodes.

[0145] Specifically, specific tool calls can be mapped to corresponding semantic operation types through preset operation type rules. For example, calls related to spatial topology can be labeled as geometric topology operations, calls related to spatial buffering can be labeled as geometric buffering operations, calls related to projection transformation can be labeled as coordinate transformation operations, calls related to aggregation operations can be labeled as numerical aggregation operations, and calls related to raster resampling can be labeled as raster resampling operations.

[0146] For input parameters, their corresponding semantic roles can be determined based on their actual use in tool calls. For example, a file path can be marked as a path parameter, a coordinate reference system identifier as a spatial reference parameter, and a parameter used to select data columns can be marked as a field selection parameter.

[0147] For output parameters, the corresponding semantic roles, data types, and data dimensions or shape information can be recorded. For data flow dependencies between tool call nodes, directed edges can be used for representation, and dependency semantics such as data transfer, spatial reference frame transfer, or type conversion can be determined based on the operation types of the preceding and following tool calls.

[0148] In one optional embodiment, the general workflow description can be represented using a JSON structure, including information such as workflow_name, workflow_description, semantic_version, nodes, and edges. Each node can include node_id, node_type (tool node or parameter node), operation_type (semantic operation type), input_roles (input role list), output_roles (output role list), type_constraints (type constraint dictionary), and runtime_hints (runtime hints). By abstracting specific tool interfaces into framework-independent semantic descriptions, a unified intermediate representation can be provided for protocol conversion between different intelligent agent frameworks.

[0149] In another optional embodiment, in addition to the semantic operation types described above, the operation type mapping may further include: mapping spatial join operations to spatial association operations, mapping temporal alignment operations to temporal alignment operations, mapping geometric attribute calculation to geometric attribute query operations, mapping reclassification operations to raster reclassification operations, mapping time series resampling to time series resampling operations, mapping grouping aggregation operations to grouping aggregation operations, and mapping feature normalization operations to feature normalization operations. For data flow dependency edges, the dependency semantics can also be automatically determined based on the operation types of the predecessor and successor nodes. For example, when the successor node is an aggregation operation and the predecessor node output is a set type, the corresponding dependency semantics are marked as aggregation source. When the successor node needs to inherit a spatial reference system, the corresponding dependency semantics are marked as reference system transmission.

[0150] After generating a general workflow description, the interface protocol of the target intelligent agent framework can be obtained, and the general workflow description can be mapped to the corresponding framework adaptation information according to the interface protocol. The interface protocol may include parameter description format, function signature format, data dependency representation method, and skill organization format, etc. For example, different target intelligent agent frameworks can use JSON Schema parameter description, Python type annotation, or Markdown parameter description respectively, and the data dependencies between tools can be represented by parameter binding, toolchain orchestration, or step reference, respectively.

[0151] In one optional embodiment, interface protocol description files or interface adapter templates for various intelligent agent frameworks can be pre-stored. The protocol parser loads the corresponding template based on the target intelligent agent framework type and extracts structured requirements such as parameter description format, function signature format, dependency representation, and skill organization format. For example, for frameworks supporting JSON Schema, field requirements such as type, description, and enum can be extracted. For frameworks using type annotations, Python type annotation format can be extracted. For declarative frameworks, Markdown parameter tables, step numbers, and parameter referencing methods can be extracted. When the target project does not explicitly specify the intelligent agent framework type, compatible skill packages in all supported formats, including function call type, tool description type, and declarative skill file type, can be generated simultaneously.

[0152] In an optional embodiment, when performing semantically preserved protocol mapping, a semantic equivalence mapping table can also be maintained to record the standard names of the same semantic operation in different agent frameworks, and to establish the correspondence between parameter semantic roles and parameter description fields such as description, schema, and annotation of the target framework, so as to reduce the probability of tool semantics or parameter semantics shifting during cross-framework mapping.

[0153] During protocol mapping, consistency in tool operation semantics, parameter semantics, and data flow dependencies can be maintained. Specifically, the semantic operation type of a tool is mapped to the tool name or function name of the target intelligent agent framework, preserving its corresponding processing functionality. The semantic roles of parameters are mapped to parameter description fields supported by the target intelligent agent framework. Data flow dependencies between tool calling nodes are converted to a dependency representation supported by the target intelligent agent framework.

[0154] For example, for function call interfaces, a JSON Schema-based tool call protocol is suitable. Each tool node in the general workflow description is mapped to a function definition object containing a name (mapped by the semantic operation type), a description (automatically generated by the semantic operation type and parameter semantic roles), and parameters (in JSON Schema format, mapped by parameter type constraints and semantic roles). The mapping process includes: querying the semantic operation type-to-function name mapping table to obtain the name field; generating the description text based on the semantic role combination of the input parameters; constructing the JSON Schema structure of parameters based on the type constraint dictionary, where each parameter contains type and description fields, and an enum field if enumeration constraints exist; and establishing parameter binding relationships by mapping the output parameter names of the predecessor tool node to the input parameter names of the successor tool node based on data flow dependencies.

[0155] For tool-descriptive interfaces, the object-oriented tool encapsulation pattern is suitable. Each tool node in the general workflow description is mapped to a tool object definition containing a tool name, tool description, input parameter classes, and execution methods. Data flow dependencies are mapped to toolchain orchestration code (such as pipe operator chaining or sequential call sequences). The mapping process includes: mapping each tool node to a Python class, with the class name generated from the semantic operation type, and the class attribute `args_schema` defined as a Pydantic model, where each field of the model corresponds to an input parameter; if the target framework supports pipe operators (such as `|` in LangChain), chained call code is generated, passing the output of the predecessor tool to the successor tool through a pipe; if the target framework only supports sequential calls, sequential call code with explicit variable assignment is generated.

[0156] For declarative skill interfaces, this applies to skill description patterns based on declarative configuration. A complete workflow described in a generic workflow is mapped to a single skill list file, containing: skill name and description (extracted from semantic annotations in the Markdown text context), execution instructions (converting the topological order of data flow dependencies into a natural language sequence of steps), and tool call sequence (mapping the semantic operation type and parameters of each tool node to tool call entries in the skill file). The mapping process includes: topologically sorting the DAG to generate an ordered list of tool call steps; translating the parameter bindings of each step into a natural language description; and generating a skill list Markdown file containing all step numbers, tool names, and parameter descriptions.

[0157] Furthermore, when generating skill packages, execution environment dependency information can also be generated. Specifically, it can scan the domain library import statements and function calls involved in the directed acyclic graph workflow configuration, and determine the Python packages required for the workflow to run by combining import alias mapping relationships. For Python packages whose specific versions can be obtained, the corresponding versions can be recorded. For Python packages whose exact versions cannot be determined, the compatible version range can be determined based on the known major version or minimum supported version, thereby generating a runtime environment dependency file in the form of requirements.txt or environment.yaml. For system-level dependencies such as GDAL and PROJ, the corresponding system dependencies and version requirements can also be determined based on the dynamic link library dependencies of Python packages, and a system dependency list can be generated.

[0158] In an optional embodiment, version constraints for runtime environment dependencies can be determined as follows: if the exact version can be determined from package metadata or the runtime environment, the exact version is recorded; if the exact version cannot be determined but the major version can be determined, the compatibility range of the corresponding major version is adopted; if the version cannot be determined at all, the lowest supported version of the package is used as the lower bound of the version. For Python packages that depend on system-level dynamic link libraries, the dynamic link library dependency records in the package metadata can also be analyzed to infer the required system libraries and their minimum versions, for example, determining the corresponding GDAL version requirement based on the dependency relationship of Rasterio.

[0159] Finally, a skill package is generated based on parameter description information, framework adaptation information, and directed acyclic graph (DAG) workflow configuration. The skill package may include a parameter schema file, interface adaptation code or configuration files corresponding to the target agent framework, an environment dependency description file, a DAG workflow configuration file, and a skill metadata file. The skill metadata may include information such as skill name, version, source project, quality level, and creation time.

[0160] In an optional embodiment, a skill package directory named after the agent workflow can be created. This directory can contain configuration files for storing parameter schemas and skill metadata, an adaptation directory for storing adaptation files for different agent frameworks, an environment dependency file describing Python package dependencies and system dependencies, and a workflow configuration file for storing the original directed acyclic graph nodes, dependency edges, and metadata. After the skill package is assembled, a corresponding checksum can be generated to verify the integrity of the skill package files. The skill package can be output as a directory or further compressed into a compressed file for transfer and loading between different agent runtime environments.

[0161] As an optional implementation of skill package organization, files such as skill_config.yaml, adapter subdirectory, requirements.txt, system_deps.txt, and dag_config.json can be set in the top-level skill directory. The adapter subdirectory is used to store adaptation code or configuration for different intelligent agent frameworks. After the skill package is assembled, an SHA256 hash checksum file can be generated to verify file integrity. When compressing the output, a ZIP format can be used, and the compression level can be set to, for example, 6, to balance compression ratio and processing speed.

[0162] Therefore, the reverse compilation method for intelligent agent workflow provided in this application can convert the tool call logic, parameter information and data dependency relationships in the directed acyclic graph workflow configuration into a framework-independent semantic representation, and complete the adaptation according to the interface protocol of the target intelligent agent framework, thereby generating a self-contained skill package containing parameter descriptions, framework adaptation information, runtime environment dependencies and workflow configuration, so that the workflow extracted from the target source code can be loaded and called by different intelligent agent frameworks.

[0163] Furthermore, after completing the conversion of the directed acyclic graph (DAG) workflow configuration to the agent skill pack, as an optional implementation, operator compilation mapping can also be performed on the DAG workflow configuration. Specifically, based on intermediate representation technology, high-level tool call nodes in the DAG workflow configuration can be mapped to framework-independent operator nodes. These operator nodes can record operator type identifiers, input / output port lists, data type enumerations, and computational attributes, where data types can include tabular, raster, vector, and tensor types.

[0164] Furthermore, the corresponding underlying execution engine can be selected based on the computational characteristics of each operator node, and zero-copy data transfer can be performed between operators using a columnar memory format. For computationally intensive operators, corresponding operator code can be generated and compiled into native executable modules, and the scheduler can select the execution engine based on hardware characteristics. For example, file reading nodes can be mapped to underlying file reading operators and DuckDB can be selected as the execution backend, and spatial pruning nodes can be mapped to spatial pruning operators and GeoPandas can be selected as the execution backend. Computation optimization for computationally intensive operators can be performed through C++ extension construction.

[0165] In an optional embodiment, Just-In-Time (JIT) compilation technology can also be used to optimize key numerical calculation functions. During the execution of the skill package, the actual performance of each operator is continuously collected, and the execution strategy is dynamically adjusted based on the performance. For repetitive tasks with similar or identical input data shapes and types, optimized execution plans can be cached to reduce the overhead of repeated compilation and scheduling.

[0166] In a specific embodiment, when multiple target projects need to be processed in batches, multiple projects and their corresponding toolset constraints can be read from an external knowledge table. For each project, target source code analysis, workflow subgraph extraction, tool validation, and parameter parsing processes can be performed separately. Each project can generate independent toolchain data, and after merging, a full tool whitelist validation is performed to ensure that tool calls in the batch-generated results all meet the constraints of the corresponding projects.

[0167] It should be noted that the method in this application is not limited to the fields of geospatial or remote sensing data processing. By adjusting the technology stack anchor library and operation type rule table, it can also be used in other scientific computing fields. For example, in the bioinformatics scenario, BioPython, scanpy, anndata, etc. can be set as domain anchor libraries, and the reference sequence format constraints for genome sequence alignment and the non-zero gene expression matrix constraints for cell clustering or dimensionality reduction operations can be added to the operation type rule table to continue using the aforementioned cascade parameter parsing and dependency constraint pre-scanning mechanism.

[0168] To help those skilled in the art better understand the technical solutions provided in this application, the above reverse compilation process will be further explained below in conjunction with several specific embodiments.

[0169] Example 1: For a Python script that batch reads remote sensing images from a specific year and calculates the mean, the script may include `file_path = base_path + str(year) + ".tif"` and call `rasterio.open(file_path)`. In cross-file data dependency analysis, it can be determined that `file_path` depends on `base_path` and `year`. In candidate workflow subgraph extraction, the corresponding code can be identified as a function-level call subgraph and determined to be of the second quality level. Static type inverse inference can determine that `file_path` is a string path type based on the function signature of `rasterio.open`. If sandbox parsing continues, simulated test data containing non-zero numerical fields can be generated based on subsequent mean aggregation operations. The final generated parameter description information can at least include the base path, a list of years, and the output format; the workflow output can be the corresponding feature matrix.

[0170] Example 2: For code snippets containing spatial topological intersection operations, such as sequentially reading gdf1 and gdf2, obtaining the intersection result through gdf1.overlay(gdf2, how='intersection'), and calculating intersection.geometry.area.sum(), a constraint-based pre-scan can identify that overlay belongs to spatial topological intersection operations and area.sum() belongs to aggregation operations. Based on this, simulated test data is generated showing that the two geometries have a non-empty intersection relationship and the intersection result has a non-zero area. After running in an isolated execution environment, runtime monitoring probes can capture the runtime values ​​and types of relevant variables.

[0171] In another embodiment, when the code contains a custom Voronoi mosaicking algorithm not covered by the preset operation type rule table, the dependency constraint pre-scan may return empty constraints. In this case, basic simulation test data can be generated according to the default strategy. If the sandbox execution produces a runtime exception due to the lack of corresponding constraints, the second-level parsing is determined to have failed, and the process proceeds to the third-level semantic annotation parsing. The semantic annotation model can identify the point set distribution constraints required for Voronoi operations based on the code context and output the corresponding parameter specifications accordingly.

[0172] In Example 3, in a multi-project batch processing scenario, multiple target projects and their corresponding toolset constraints can be read from an external knowledge table. For each project, source code preprocessing, cross-file data dependency graph construction, candidate workflow subgraph extraction, tool validation, and parameter parsing are performed. Each project can generate an independent toolchain data file, recording the standard tool name sequence, execution mode, project identifier, and quality level. After each project is processed, a full tool whitelist validation can be performed on the merged result.

[0173] In Example 4, if the tool name in the parameter specification initially output by the semantic annotation model does not belong to the set of tools allowed by the target project, automatic retries can be triggered: the first retry adds emphasis information on toolset constraints, the second retry adjusts the prompt structure and adds a parameter specification example, and the third retry adds contextual information. If the consistency check still fails after multiple retries, the corresponding target workflow subgraph can be downgraded to the third quality level and a simplified parsing method can be used to generate a simplified directed acyclic graph workflow configuration, thereby avoiding the interruption of the entire process due to the failure of a single parameter parsing.

[0174] In Example 5, when using the aforementioned optional operator compilation mapping scheme, the `read_file` node in the directed acyclic graph can be mapped to the underlying file reading operator and DuckDB can be selected as the execution backend; the `clip` node can be mapped to the spatial pruning operator and GeoPandas can be selected as the execution backend; and the `compute_statistics` node can be mapped to the statistical computation operator. For the computationally intensive operators, compilation optimization can be performed using a C++ extension construction method to generate native executable code.

[0175] In Example 6, for an interactive computing notebook containing Markdown text such as "How to query large-scale geographic data using a database," the Markdown text and code units can be extracted simultaneously during the notebook preprocessing stage, and the corresponding continuous code unit fragments can be identified as candidate workflow subgraphs for the third quality level. Subsequently, a question template can be generated based on the expert intent represented by the Markdown text, and a simplified parsing method can be used to extract the core tool call sequence, resulting in a simplified directed acyclic graph workflow configuration containing tool sequences and sequential execution relationships.

[0176] Example 7: The method of this application is not limited to the field of geospatial data processing. When the target project is a single-cell RNA sequencing analysis project based on tool libraries such as BioPython, scanpy, and anndata, the corresponding tool libraries can be configured as domain tool libraries, and the three-level cascaded parsing and dependency constraint pre-scanning can be reused. In this case, the operation type rule table can also be extended to include bioinformatics domain constraints, such as reference sequence format constraints for sequence alignment operations, and data validity constraints such as non-zero gene expression matrices for dimensionality reduction or cell clustering related operations.

[0177] Example 8, in a multi-framework skill package construction example, the directed acyclic graph workflow configuration can include three tool nodes: `rasterio.open`, `numpy.mean`, and the result output, as well as three external input parameters: `base_path`, `year_list`, and `output_format`. For `base_path`, file format constraints can be extracted by concatenating the string path type and the ".tif" suffix. For `year_list`, it can be determined as a `List[int]` type based on list comprehensions and the year range can be extracted based on the loop context. For `output_format`, enumeration values ​​such as GeoTIFF, NetCDF, and Zarr can be extracted from the conditional branches. Subsequently, function call interface definitions, LangChain Tool-type tool objects and orchestration code, and a declarative Markdown skill list can be generated. Python package dependencies and system-level dependency descriptions are generated based on the imported alias mapping table. Finally, the various adapter files, parameter schemas, environment dependencies, and the directed acyclic graph workflow configuration are assembled into a skill package.

[0178] Example 9 illustrates a multi-source remote sensing data fusion workflow that includes multiple tool nodes such as `rasterio.open`, `rioxarray.open_rasterio`, `xarray.merge`, and `numpy.apply_along_axis`. Corresponding adaptation information can be generated for different agent frameworks. In a function call framework, each tool node can describe its parameter types according to a JSON schema. In a tool description framework, the dependencies from `rioxarray` to `xarray.merge` and then to `numpy.apply_along_axis` can be encoded as toolchain orchestration logic. In a declarative skill framework, the same data dependency topology can be converted into a natural language step sequence and the corresponding tools can be called step by step. Thus, the same directed acyclic graph workflow configuration can maintain tool semantics, parameter semantics, and data dependencies across different agent frameworks.

[0179] In one alternative embodiment, 50 open-source Python projects with more than 50 stars tagged with geospatial, remote sensing, or earth science are selected based on their most recent update time, forming a dataset containing 327 Python scripts and 184 Jupyter Notebook files. The dataset covers vector processing, raster processing, multidimensional array computation, spatiotemporal analysis, and machine learning scenarios. Approximately 28% of the code snippets contain dynamically concatenated variables, and approximately 15% contain cross-file dependency calls.

[0180] For each project, a pure static analysis method, a large language model direct generation method, and the method of this application were used to extract workflows and generate skill packs. The parameter extraction completeness rate, simulation test data sandbox execution success rate, percentage of legal tools, and skill generation usability rate were verified within a function call-based intelligent agent framework. The average of 50 projects was used for each indicator. The pure static analysis method uses PyCG 0.1.0 to generate cross-file call graphs and combines AST type annotations and function signatures for inference. The large language model direct generation method inputs the complete code into GPT-4 (gpt-4-0613) at once and requires the output of workflow configuration and parameter schema, without using static analysis or a sandbox environment. Table 2 is a comparison table of different workflow and skill pack generation methods provided in the embodiments of this application, which will be explained below with reference to Table 2.

[0181] Table 2 is a comparison table of different workflows and skill package generation methods.

[0182] As shown in Table 2, the parameter extraction completeness rate of the method in this application is 49 percentage points higher than that of pure static analysis, 23 percentage points higher than that of direct generation of larger language models, and the skill generation usability rate is 44 percentage points higher than that of direct generation of larger language models, while the number of calls to the large language model is approximately 7% of that of the direct generation method. In this experiment, 67% of the dynamic variables were resolved through the first-level static derivation, 25% were resolved through the second-level sandbox execution, and only 8% triggered the third-level semantic annotation. The pre-scanning of dependency constraints increased the success rate of sandbox execution of simulated test data from 31% to 87%.

[0183] In the above embodiments, the reverse compilation method of the agent workflow has been described in detail. This application also provides an embodiment of the reverse compilation device for the agent workflow.

[0184] Figure 6 This is a schematic diagram of the structure of a reverse engineering apparatus for an intelligent agent workflow provided in an embodiment of this application, as shown below. Figure 6 As shown, the device includes: Data acquisition module 60 is used to acquire the target source code and toolset constraints of the target project; Workflow extraction module 61 is used to construct a cross-file data dependency graph based on the target source code; and to extract candidate workflow subgraphs based on the cross-file data dependency graph. The tool verification module 62 is used to verify the tool calls in the candidate workflow subgraph based on toolset constraints to obtain the target workflow subgraph. The configuration generation module 63 is used to parse the target workflow subgraph to obtain the target parameter information, and generate a directed acyclic graph workflow configuration based on the target parameter information and the data flow topology relationship of the target workflow subgraph. The skill pack generation module 64 is used to convert the directed acyclic graph workflow configuration into a skill pack that can be invoked by the agent.

[0185] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 7 As shown, the electronic device includes: a memory 70 for storing computer programs; The processor 71 is used to implement the steps of the reverse compilation method of the intelligent agent workflow as described in the above embodiments when executing a computer program.

[0186] The electronic devices provided in this embodiment may include, but are not limited to, laptops or desktop computers.

[0187] The processor 71 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 71 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 71 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 71 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 71 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0188] The memory 70 may include one or more computer-readable storage media, which may be non-transitory. The memory 70 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 70 is used to store at least the following computer program 701, which, after being loaded and executed by the processor 71, is capable of implementing the relevant steps of the reverse engineering method for the intelligent agent workflow disclosed in any of the above embodiments. In addition, the resources stored in the memory 70 may also include an operating system 702 and data 703, etc., and the storage method may be temporary storage or permanent storage. The operating system 702 may include Windows, Unix, Linux, etc. The data 703 may include, but is not limited to, the relevant data involved in the reverse engineering method for the intelligent agent workflow.

[0189] In some embodiments, the electronic device may further include a display screen 72, an input / output interface 73, a communication interface 74, a power supply 75, and a communication bus 76.

[0190] Those skilled in the art will understand that Figure 7 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0191] The electronic device provided in this application includes a memory and a processor. When the processor executes the program stored in the memory, it can implement the reverse compilation method of the intelligent agent workflow in the above embodiments.

[0192] It should be noted that although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Claims

1. A method for reverse engineering an intelligent agent workflow, characterized in that, The method includes: Obtain the target source code and toolset constraints of the target project; Based on the target source code, a cross-file data dependency graph is constructed; and based on the cross-file data dependency graph, candidate workflow subgraphs are extracted. Based on the toolset constraints, the tool calls in the candidate workflow subgraphs are verified to obtain the target workflow subgraph; The target workflow subgraph is parsed to obtain target parameter information, and a directed acyclic graph workflow configuration is generated based on the target parameter information and the data flow topology of the target workflow subgraph. The directed acyclic graph workflow configuration is converted into a skill package that can be invoked by the agent.

2. The reverse engineering method for the intelligent agent workflow as described in claim 1, characterized in that, The construction of a cross-file data dependency graph based on the target source code includes: Construct the abstract syntax tree corresponding to the target source code; Based on the abstract syntax tree, determine the variable dependencies and tool call relationships in the target source code; Based on the variable dependencies and tool call relationships, data chains with data flow associations are merged to obtain the cross-file data dependency graph.

3. The reverse engineering method for the intelligent agent workflow as described in claim 1, characterized in that, The step of extracting candidate workflow subgraphs based on the cross-file data dependency graph includes: Identify target nodes, function bodies, consecutive code unit fragments, and cross-file call chains in the target source code; the target nodes include source data nodes and result output nodes. Based on the data dependencies between the target nodes, extract the data processing links from the cross-file data dependency graph; Based on the code complexity and operation type of the function body, extract the function-level call subgraph; Based on the consecutive code unit fragments and their text context, extract the code unit call subgraph; Based on the cross-file call chain, extract the cross-file call sub-graph; The data processing chain, the function-level call subgraph, the code unit call subgraph, and the cross-file call subgraph are selected as candidate workflow subgraphs.

4. The reverse engineering method for the intelligent agent workflow as described in claim 1, characterized in that, The step of validating tool calls in the candidate workflow subgraph based on the toolset constraints to obtain the target workflow subgraph includes: Obtain the tool call names and allowed tools indicated by the toolset constraints in the candidate workflow subgraph; The tool call names are standardized to obtain standard tool names; The standard tool name is precisely matched with the allowed tools; the precise matching is to determine whether the standard tool name is consistent with a preset name portion corresponding to any of the allowed tools. If the exact match fails, a fuzzy match is performed based on name similarity. If the fuzzy matching fails, a fallback matching is performed based on the tool mapping relationship corresponding to the target project, and the legality of the matching result is verified based on a preset tool whitelist. The tool calls that have passed the verification in the candidate workflow subgraph are retained to obtain the target workflow subgraph.

5. The reverse engineering method for the intelligent agent workflow as described in claim 1, characterized in that, After extracting candidate workflow subgraphs, the following steps are also included: Obtain the subgraph features of the candidate workflow subgraph; the subgraph features include at least one of the following: domain tool library coverage information, code complexity, call path length, annotation ratio, and subgraph extraction type; Based on the subgraph features, the candidate workflow subgraphs are classified into quality levels; wherein, the quality level is used to indicate the parameter parsing strategy corresponding to the candidate workflow subgraph.

6. The reverse engineering method for the intelligent agent workflow as described in claim 5, characterized in that, The parameter parsing of the target workflow subgraph to obtain target parameter information includes: Based on the results of the quality level classification, the target quality level of the target workflow subgraph is determined; Determine whether the target quality level meets the preset quality conditions; If satisfied, the target parameter information is obtained by parsing the dynamic variables in the target workflow subgraph using the cascaded parameter parsing strategy. If the conditions are not met, the core tool calls and parameter information of the core tool calls are extracted from the target workflow subgraph to obtain the target parameter information.

7. The reverse engineering method for the intelligent agent workflow as described in claim 6, characterized in that, The cascaded parameter parsing strategy includes a static type reverse inference strategy, a sandbox execution parsing strategy, and a semantic annotation parsing strategy. The method of parsing the dynamic variables in the target workflow subgraph using the cascaded parameter parsing strategy to obtain the target parameter information includes: The static type reverse inference strategy is used to determine the objective function into which the dynamic variables flow and the parameter positions of the dynamic variables in the objective function. The target parameter type of the dynamic variable is determined based on the type constraint corresponding to the parameter position in the function signature of the target function; If the type of the target parameter cannot be uniquely determined, the runtime parameter information of the dynamic variable during the simulated execution process is obtained through the sandbox execution parsing strategy. If complete runtime parameter information is not obtained, the semantic annotation parsing strategy is used to semantically annotate the context code of the dynamic variable to obtain the target parameter information.

8. The reverse engineering method for the intelligent agent workflow as described in claim 7, characterized in that, The step of obtaining runtime parameter information of the dynamic variables during the simulated execution process through the sandbox execution parsing strategy includes: Based on the downstream usage nodes of the dynamic variable in the target workflow subgraph, determine the operational semantic constraints corresponding to the dynamic variable; the operational semantic constraints include at least one of spatial relationship constraints, coordinate reference constraints, time index constraints, data validity constraints, data field constraints, and data attribute constraints. Based on the operational semantic constraints, generate simulated test data; In an isolated execution environment, the code snippet corresponding to the target workflow subgraph is executed based on the simulated test data; Obtain the runtime value and runtime type of the dynamic variable to obtain the runtime parameter information.

9. The reverse engineering method for the intelligent agent workflow as described in claim 7, characterized in that, The step of semantically annotating the context code of the dynamic variable using the semantic annotation parsing strategy to obtain the target parameter information includes: Obtain the context code and auxiliary parsing information of the dynamic variables; the auxiliary parsing information includes upstream dependency information, downstream usage information, toolset constraints, and parsed parameter information; The context code and the auxiliary parsing information are input into a pre-trained semantic annotation model to generate candidate parameter information for the dynamic variable; the candidate parameter information includes parameter name, parameter type, parameter semantic role, and parameter value constraints. The candidate parameter information is subjected to consistency verification, and the candidate parameter information that passes the verification is used as the target parameter information.

10. The reverse engineering method for the intelligent agent workflow as described in claim 1, characterized in that, Based on the target parameter information and the data flow topology of the target workflow subgraph, a directed acyclic graph workflow configuration is generated, including: Based on the data flow topology, determine the data dependencies between tool calls in the target workflow subgraph; When multiple tool calls are executed sequentially based on the same data chain, the multiple tool calls are determined to be in a sequential execution relationship; When multiple tool calls are executed based on independent data chains and converge to a target tool call, the multiple tool calls are determined to be executed in parallel. The directed acyclic graph workflow configuration is generated based on the target parameter information, the data dependencies, and the sequential execution relationships and / or the parallel execution relationships.

11. The reverse engineering method for the intelligent agent workflow as described in claim 1, characterized in that, The step of converting the directed acyclic graph workflow configuration into a skill package that can be invoked by the agent includes: Generate parameter description information corresponding to the intelligent agent workflow based on the target parameter information; Semantic annotation is performed on the tool call nodes and external input parameter nodes in the directed acyclic graph workflow configuration to generate a framework-independent generic workflow description; Based on the interface protocol of the target intelligent agent framework, the general workflow description is mapped to framework adaptation information that conforms to the interface protocol; The skill pack is generated based on the parameter description information, the framework adaptation information, and the directed acyclic graph workflow configuration.

12. A reverse engineering apparatus for an intelligent agent workflow, characterized in that, The device includes: The data acquisition module is used to acquire the target source code and toolset constraints of the target project; The workflow extraction module is used to construct a cross-file data dependency graph based on the target source code; and to extract candidate workflow subgraphs based on the cross-file data dependency graph. The tool verification module is used to verify the tool calls in the candidate workflow subgraph based on the toolset constraints to obtain the target workflow subgraph. The configuration generation module is used to parse the target workflow subgraph to obtain target parameter information, and generate a directed acyclic graph workflow configuration based on the target parameter information and the data flow topology relationship of the target workflow subgraph. The skill pack generation module is used to convert the directed acyclic graph workflow configuration into a skill pack that can be invoked by the agent.

13. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the reverse compilation method for the intelligent agent workflow according to any one of claims 1 to 11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the reverse compilation method of the intelligent agent workflow according to any one of claims 1 to 11.

Images