Method for generating a chain of actions across software environments and related product

Abstract

The application discloses a cross-software-environment action chain generation method, an electronic device and a computer readable storage medium. The method comprises the following steps: obtaining description information of a task to be executed, execution constraint information associated with the description information of the task to be executed, and execution resource description information of a current execution environment; constructing a constraint model decoupled from associated execution resources according to the execution constraint information, generating at least one executable action unit according to the constraint model, and determining a dependency relationship between the executable action units; binding one or more execution resource objects to each executable action unit according to the at least one executable action unit and the execution resource description information, and generating an action chain carried by each execution resource object in combination with the dependency relationship between the executable action units. The generated action chain can accurately call and process tasks across software environments and improve the processing efficiency of the action chain.

Description

Technical Field

[0001] This application relates to the field of computer application technology, and in particular to a method for generating action chains across software environments and related products. Background Technology

[0002] Currently, in various scenarios such as government services, enterprise operations, and internal management, there are a large number of business tasks that need to be completed across multiple independent software systems. The mainstream implementation methods for cross-software processes include workflows with manually configured nodes, RPA (Robotic Process Automation) scripts recorded with fixed operation paths, and customized interface orchestration schemes between systems. These schemes are generally customized for specific scenarios, and the execution logic is deeply bound to the specific characteristics of the software environment, such as page identifiers, control identifiers, and interface paths.

[0003] These cross-software environment process solutions that are bound to specific software resource identifiers are prone to complete failure when software is iterated and upgraded, pages are redesigned, interfaces are adjusted, or business rules are changed. They require a high investment of manpower and time to redevelop and reconfigure, and their ability to adapt to heterogeneous software environments that do not have open standard interfaces is insufficient, making it impossible to efficiently support the need for automated process implementation in various cross-software environment scenarios. Summary of the Invention

[0004] This application proposes a method for generating action chains across software environments, an electronic device, and a computer-readable storage medium to solve the technical problems of existing methods generating action chains that lack adaptability to heterogeneous software environments and require redevelopment and reconfiguration after the environment changes.

[0005] The first aspect of this application proposes a method for generating action chains across software environments, including: Obtain the description information of the task to be executed, the execution constraint information associated with the description information of the task to be executed, and the execution resource description information of the current execution environment; Based on the execution constraint information, a constraint model decoupled from the associated execution resources is constructed, and at least one executable action unit is generated based on the constraint model, and the dependency relationship between each executable action unit is determined. Based on the at least one executable action unit and the execution resource description information, one or more execution resource objects are bound to each executable action unit, and an action chain carried by each execution resource object is generated by combining the dependencies between the executable action units; wherein, at least two execution resource objects in the action chain are located in different software environments.

[0006] A second aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor. The electronic device supports processing or communication of at least two different applications, and the processor, when executing the computer program, implements the aforementioned cross-software environment action chain generation method.

[0007] A third aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned cross-software environment action chain generation method.

[0008] The cross-software environment action chain generation method, electronic device, and computer-readable storage medium provided in this application, through multi-source data collection, unstructured task requirements, scattered business rules, and heterogeneous resource information are uniformly converted into machine-recognizable structured data. This eliminates format differences between data from different sources at the source, providing fundamental support for subsequent fully automated action chain generation and eliminating the need for manual data processing and conversion. Furthermore, by constructing a constraint model that is completely decoupled from execution resources, a complete separation of the business rule layer and the execution layer is achieved. Subsequent business rule updates only require iterating the constraint model, and software environment changes only require adjusting execution layer resources, without reconstructing the entire action chain. At the same time, constraint units are accurately converted into action units and dependencies, ensuring that all mandatory business rules are implemented in the execution logic, thus avoiding compliance risks such as missed verification, unauthorized access, and lack of evidence from the generation side. The cross-software environment execution action chains generated by this method are not bound to specific pages, interfaces, controls, or other identifiers. Compared to traditional RPA recording and manual process configuration, system iteration and rule updates do not require full-process reconstruction, and the built-in mandatory constraint verification and multi-source evidence verification significantly improve execution compliance and accuracy. Attached Figure Description

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

[0010] Figure 1 This is a flowchart of an action chain generation method across software environments in an embodiment of this application; Figure 2 yes Figure 1 A flowchart of step S100; Figure 3 yes Figure 1 A flowchart of step S200; Figure 4 yes Figure 1Step S300 is a flowchart for binding an executable action unit to an execution resource object; Figure 5 Is Figure 4 Based on the steps, a flowchart of the action chain is further generated; Figure 6 Is Figure 1 A flowchart showing the process of further filtering action chains and template processing after the initial steps. Detailed Implementation

[0011] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0012] This application provides a method for generating action chains across software environments, applicable to government services, public services, enterprise administration, human resources, finance, legal affairs, project application, procurement, customer service, intellectual property affairs, or other task systems that require continuous execution across different software applications, web pages, file systems, message channels, data interfaces, or hardware interaction components. This method can be applied to mobile phones, computers, or other electronic devices with computer program processing capabilities. The following will use a processing system suitable for government and enterprise matters as an example to describe the specific implementation of this application in detail. It should be noted that the following examples in government and enterprise scenarios are for illustrative purposes only and do not constitute a limitation on the scope of protection.

[0013] like Figure 1 The method for generating action chains across software environments, as shown, includes the following processing steps: S100: Obtain the description information of the task to be executed, the execution constraint information associated with the description information of the task to be executed, and the execution resource description information of the current execution environment.

[0014] In one implementation, such as Figure 2 As shown, obtaining the description information of the task to be executed includes the following steps: S110, Receive task input information associated with the task to be executed obtained from the multi-source input interface; S120. Based on the interface type corresponding to the input interface that provides task input information, and in conjunction with the preset parsing rules that match the interface type, extract the core element information corresponding to the task to be executed from the task input information. S130. Encapsulate the extracted core element information into a standardized task context structure in a unified format.

[0015] A task to be executed can be a specific task item in an interactive application system. For example, submitting application materials and receiving receipts in a government and enterprise management system, the new employee onboarding process in a company management system, or the customer contract signing and payment triggering process in a sales system. The description information of the task to be executed can come from one or more sources of information obtained through multi-source input interfaces, such as text, voice, images, files, form data, interactive operation trajectories, and external events. It can be obtained through voice commands input by the user in natural language, text information input by the user, uploaded material files, operation trajectories recorded by the application system, and event notifications pushed by third-party systems.

[0016] For task input information with different input methods and formats, data processing is used to parse out core fields and standardize and encapsulate them to obtain the descriptive information of the task to be executed. For example, for text or voice input information, the corresponding parsing rules are matched according to the interface type of the corresponding input interface. The text format is first converted or corrected according to the parsing rules, and then core elements related to the task to be executed, such as task objectives, task subject, task operation objects, time conditions, expected output, and input material list, are extracted from the text. For image or file input information, the corresponding parsing rules are matched according to the interface type of the corresponding input interface. Image recognition or file type parsing is performed according to the parsing rules, and then core elements such as field entities, validity period, and subject association information are extracted. For interactive operation trajectory input information, the corresponding parsing rules are matched according to the interface type of the corresponding input interface. Core elements such as page state, operation object, action sequence, and execution result state are identified according to the parsing rules. Finally, all extracted core elements are encapsulated into a standardized task context structure in a unified format to provide a unified task benchmark for subsequent operations. The standardized task context structure can include a globally unique task identifier, a task semantic target, a task subject, a task operation object, a task input set, a time constraint set, and a desired output set.

[0017] Furthermore, in one embodiment, the execution constraint information associated with the description information of the task to be executed is obtained through the following steps: S140. Based on the standardized task context structure, determine the matching candidate constraint packages from the preset rule data source and sort them according to their fit to obtain the set of constraint rules with the highest fit. S150. In the set of constraint rules, the constraint rules are merged and compatible in the order of more specific rules first, mandatory rules first, and latest version first, so as to obtain the execution constraint information.

[0018] The execution constraint information associated with the description information of the task to be executed can, in government and enterprise scenarios, originate from rule data sources such as service guides, application instructions, material lists, form field rules, attachment requirements, processing time limits, status transition rules, and receipt rules. Based on one or more combinations of tags from the generated standardized task context—task type, subject type, applicable region, task semantics, expected output, applicable scope, effective time, permission scope, and rule status—matching candidate constraint packages can be filtered from the rule data source to obtain a set of constraint rules with high adaptability. After filtering out candidate constraint rules that do not meet the requirements, the remaining compliant constraint rules are merged and conflict detected in the order of more specific rules first, mandatory rules first, and latest version first, thus obtaining the final set of effective constraint rules. In one implementation, when performing hierarchical merging and conflict detection on the filtered constraint data, compatible constraint data can be merged according to at least one of the following rules: more specific applicable scope first, mandatory constraints first, current effective version first, or dedicated constraints first over shared default constraints. Conflict detection is performed when there are incompatible requirements for the same field, state, or semantic target. Conflicts involving necessary input, permission boundaries, irreversible operations, or mandatory evidence are not automatically ignored; instead, conflict constraint units are generated or the system enters a pending confirmation state. At least one of the following is generated for the loaded constraint data: rule version identifier, source identifier, loading time, or content summary. When a change in constraint data is detected during execution, the executable action unit corresponding to the changed constraint can be determined based on the mapping relationship between constraint units and executable action units.

[0019] Furthermore, in one implementation, the execution resource description information of the current execution environment can be obtained through the following steps: S160. Obtain the currently available execution resources and their metadata from at least one of the following methods: web page structure, accessibility tree, control tree, interface definition document, file metadata, system call feedback, execution log, visual interface parsing results, and manual registration information; S170. Generate standardized description attributes based on the metadata corresponding to each execution resource, and encapsulate all description attributes into execution resource description information.

[0020] Resource description information can be derived from webpage structure, accessibility tree, control tree, interface definition, file metadata, system call feedback, execution logs, visual interface parsing results, and manual registration information. Appropriate collection methods are selected for different types of execution resources to collect their metadata. For example, for webpage resources, the page DOM, accessibility tree, and page tags can be crawled to generate resource description information. For interface resources, the interface definition document can be retrieved and parsed to obtain input and output parameters, permission requirements, and other information. For desktop software resources, the control tree, operation entry point, and interaction logic can be read to generate description information. Then, standardized description attributes are generated for each execution resource, including resource type, access method, semantic tags, set of executable operations, input / output mode, permission scope, stability, historical success rate, and evidence acquisition capability. The dynamic status of execution resources is updated in real time, such as current accessibility, permission validity, and whether the load exceeds the threshold, to ensure that the description information and real-time status of the execution resources are consistent.

[0021] S200. Construct a constraint model that is decoupled from the associated execution resources based on the execution constraint information, generate at least one executable action unit based on the constraint model, and determine the dependencies between each executable action unit.

[0022] In one implementation, a constraint model is first constructed based on execution constraint information. This model is decoupled from the associated execution resources and includes multiple constraint units and the relationships between them. This constraint model is not bound to specific software, pages, or interfaces. Specifically, as shown... Figure 3 As shown, S210: Data processing is performed on the execution constraint information to decompose all action description information that needs to be processed by the execution resource, thereby obtaining rule semantic information associated with the constraint rules; wherein, the action description information includes at least one of webpage links, control identifiers, interface addresses, operation paths, software names, page positions, and page coordinates. S220: Field information with different sources and different expressions in the rule semantic information is processed into standardized semantic rules. S230: The standardized semantic rules are decomposed into constraint units with relatively independent constraint semantics (e.g., target nodes, input nodes, field nodes, permission nodes, evidence nodes, etc.), and each constraint unit is labeled with relatively independent semantic identification information. Semantic identification information may include semantic identifiers, semantic targets, mandatory attributes, optional attributes, input requirements, output requirements, verification conditions, permission requirements, etc. All attributes only describe the requirements of the constraint rule itself and are not associated with any specific implementation carrier, and each constraint unit is a completely independent rule node that can be mapped to any execution resource that meets the requirements. In one implementation, the constraint unit with relatively independent constraint semantics can be the smallest indivisible constraint unit or a relatively small constraint unit close to this.

[0023] S240. Based on the business processing logic corresponding to the description information of the task to be executed, determine the relationships between all constraint units, such as sequential dependency, data dependency, conditional branching, mutual exclusion, and parallel relationships. Then, define the relationships between constraint units, clearly distinguishing between mandatory constraints that cannot be violated throughout execution, such as required fields, permission boundaries, and mandatory evidence requirements, as well as optimizable constraints that can be dynamically adjusted during execution, such as execution cost and resource preferences. This generates a constraint model in the form of a directed acyclic graph, rule tree, or state machine. The relationships in the constraint model describe the logical dependencies between the constraint rules of each constraint unit. These logical dependencies can include sequential dependencies, data dependencies, and at least one of evidence dependencies, conditional dependencies, mutual exclusion dependencies, parallel dependencies, and quantity constraint dependencies. The resulting constraint model can be reused across heterogeneous environments such as different execution platforms, different operating terminals, and different regions, truly achieving complete decoupling from execution resources.

[0024] The generated constraint model can be further validated using a double check: First, check if any constraint units and relationships contain content bound to specific execution resources; if so, revert to correction. Second, verify the logical validity of the constraint model, checking for constraint conflicts, logical loops, and rule omissions. After both checks pass, an immutable snapshot of the constraint model is generated and bound with a unique version number. This constraint model itself does not need to be modified during subsequent changes to execution resources or task execution; only the mapping relationships at the action layer need to be adjusted to adapt to the new software environment.

[0025] Then, in step S250, at least one executable action unit, including task semantic objectives and resource capability requirements, is generated based on the constraint model, and an action-constraint mapping relationship is established between each executable action unit and its associated constraint unit. Specifically, one or more executable action units are generated corresponding to each constraint unit in the constraint model. These executable action units have built-in attributes such as task semantic objectives, resource capability requirements, verification conditions, pre- and post-rules, retry or timeout strategies, and compensation rules. A bidirectional traceable mapping relationship is established between constraint units and executable action units, thereby forming an action-constraint mapping relationship. For example, the constraint unit identifier, action unit identifier, rule version, and generation basis are recorded for subsequent anomaly localization and rule iteration.

[0026] Finally, based on the constraint model and the action-constraint mapping relationship, the dependencies between each executable action unit are determined. Specifically, S260, based on the association relationships between each constraint unit in the constraint model and the action-constraint mapping relationship, the association relationships between each constraint unit are converted into a dependency mapping set between each executable action unit, which includes at least sequence dependencies, data dependencies, and evidence dependencies. Then, S270, compliance verification is performed on the dependency mapping set to obtain a verified dependency mapping set where each dependency meets preset requirements and is executable; wherein, dependency compliance verification includes checking for anomalies such as circular dependencies, dependency conflicts, no start node, and no end node.

[0027] The above method can transform all mandatory business rules in the constraint model into executable dependency relationships between action units without omission or deviation. This ensures that the execution logic of the action chain fully conforms to the requirements of the original business rules. Furthermore, the pre-compliance verification eliminates logical anomalies such as circular dependencies, logical conflicts, broken execution chains, and no exit points from the generation side. This fundamentally avoids problems such as infinite loops, invalid execution, process interruptions, and uncontrollable results during the execution phase of the action chain. At the same time, the traceable mapping between dependency relationships and constraint units significantly reduces the tracing costs of subsequent rule iterations and anomaly investigations. Overall, this significantly improves the generation reliability, execution stability, and full lifecycle operation and maintenance efficiency of cross-software action chains.

[0028] In other implementations, after generating executable action units and before binding resource objects, data mapping can be established for materials and fields. Specifically, materials, files, historical records, external data sources, or outputs of preceding actions are converted into source data items; target fields may include at least one of the following: field semantics, data type, format, unit, length, enumeration range, validation expression, or required identifier. Field mapping is determined based on at least one of the following: semantic matching degree between source data items and target fields, data type compatibility, format convertibility, time freshness, source credibility, or conflict degree. When the highest candidate credibility is insufficient, or when there are ambiguities among multiple candidate data that cannot be automatically eliminated, field writing is not performed directly; instead, a confirmation action unit or a material replenishment action unit is generated. Field conversion may include at least one of the following: date format conversion, unit conversion, encoding conversion, enumeration mapping, address splitting or merging, name normalization, file format conversion, or file size adjustment.

[0029] S300. Based on at least one executable action unit and execution resource description information, bind one or more execution resource objects to each executable action unit, and generate an action chain carried by each execution resource object by combining the dependencies between the executable action units.

[0030] In one implementation, such as Figure 4 As shown, based on at least one executable action unit and execution resource description information, one or more execution resource objects are bound to each executable action unit, including the following steps: S310. Based on the task semantic goals and resource capability requirements corresponding to each executable action unit, remove execution resources that do not meet the preset conditions from the execution resource library corresponding to the execution resource description information through hard gating.

[0031] S320. Based on the preset matching degree evaluation mechanism or multi-action joint solution mechanism, bind an execution resource object to each executable action unit for the remaining execution resources, or bind a main execution resource object and at least one backup execution resource object to each executable action unit.

[0032] Hard gating refers to mandatory pre-processing validation rules during the resource selection phase. If any rule is not met, the candidate resource for execution is directly eliminated. The rules in hard gating can come from the mandatory constraint rules of the task to be executed, and their priority cannot be dynamically adjusted to ensure that the final bound execution resource does not violate the task's bottom-line requirements.

[0033] The matching evaluation mechanism can be a single-action resource matching algorithm that performs multi-dimensional quantitative scoring on candidate execution resources that pass hard gating for a single executable action unit, and selects the bound execution resource object according to the score.

[0034] The multi-action joint solution mechanism is a resource binding algorithm that can solve the global optimization problem by binding the execution resources of all actions for multiple executable action units with dependencies. It takes into account global constraints such as the matching degree of individual actions, the cost of switching execution resources between actions, and mutual exclusion of execution resources.

[0035] The primary execution resource object is the resource object that is invoked first when an action is executed, while the backup execution resource object is a pre-bound alternative resource object that meets all the requirements of the action. When the primary execution resource object is unavailable, the action can be switched to the backup execution resource object to continue execution without having to go through the entire execution resource selection process again.

[0036] For each executable action unit to be bound, based on its respective task semantic goals, resource capability requirements, and also its respective operation type requirements, permission requirements, evidence acquisition requirements, and version compatibility requirements, an execution resource library consisting of all execution resources is first obtained from the execution resource description information. Available candidate execution resources are then identified from this library, and execution resources that do not meet preset conditions are filtered out using hard gating. These preset conditions include at least two of the following: action capability, access permission, version compatibility, state reachability, and mandatory evidence acquisition requirements.

[0037] For example, each candidate execution resource undergoes five veto checks sequentially; if any one check is not met, the resource is marked as invalid. These five checks may include action capability check, permission validity check, version compatibility check, evidence availability check, and status reachability check. Specifically, the action capability check determines whether the candidate execution resource supports the operation type of the executable action unit. For example, if the action requires uploading a file, does the candidate resource have file upload capabilities? If not, it is eliminated. The permission validity check determines whether the current session has the necessary permissions for the execution resource. For example, is the user logged into the corresponding system? Does the user have the authority to submit a report? If not, the resource is eliminated. The version compatibility check determines whether the current version of the execution resource meets the requirements of the current executable action unit. For example, if the government platform upgrade requires a V2 version interface, a candidate execution resource still using version V1 is eliminated. The evidence availability check determines whether the execution resource can return the mandatory enforcement evidence required by the executable action unit. For example, if the executable action unit requires obtaining an acceptance receipt after submission, the execution resource is eliminated if it cannot return such a receipt. Reachability checks are used to determine whether a resource is currently accessible. For example, there should be no 404 errors on the page, no API downtime, and no crashes in the desktop application. If a resource is unreachable, it should be rejected. In other implementations, only two or three of the above five items can be used, or a veto check can achieve the same purpose.

[0038] For all candidate execution resources that pass these 5 checks, the execution resource objects can be bound using either a single-action matching evaluation or a multi-action joint solution mode, depending on the complexity matching.

[0039] The single-action matching evaluation mode is suitable for scenarios where the correlation between executable action units is low and there is no strong resource dependency. This mode adopts a multi-dimensional quantitative scoring method. For each candidate execution resource that passes the hard gating, a comprehensive score is calculated by multiplying semantic matching degree, capability satisfaction degree, state reachability, permission satisfaction degree, stability, historical success rate, execution risk, and resource switching cost with their respective weights. Data for these dimensions can be obtained from the description information and historical execution logs of the execution resources. Candidate execution resources are sorted from high to low according to their comprehensive scores. The highest-scoring resource is bound to the primary execution resource object, and the second and third-ranked resources are bound to the first and second backup execution resource objects, respectively, and recorded in the attributes of the corresponding executable action units.

[0040] Among them, the multi-action joint solution mode is suitable for scenarios with complex dependencies between executable action units and high costs of cross-software switching. In this mode, the hard gating requirements, resource mutual exclusion rules, and action dependencies corresponding to each executable action unit to be bound are first used as inviolable constraints for solving the problem. Then, with the optimization objectives of minimizing the overall execution cost, overall risk cost, and overall resource switching cost, algorithms such as integer programming and heuristic search are used to solve the execution resource binding scheme of all executable action units, ensuring that the execution resource object bound to each executable action unit meets the hard gating requirements and that the overall cross-software switching overhead and execution risk are minimized. According to the solution results, a main execution resource object is bound to each executable action unit. Furthermore, one or two additional spare execution resource objects that meet the requirements can be matched for each executable action unit and stored in the corresponding executable action unit attributes.

[0041] In this embodiment, by setting hard gating, most invalid candidate execution resources can be quickly eliminated, significantly reducing the computational load of subsequent matching steps and greatly improving the execution resource binding response speed. Furthermore, the execution resource object binding does not rely on fixed page addresses, control identifiers, or interface paths; it is based solely on the semantic capabilities and status features of the execution resource. When the page is redesigned or the interface is upgraded, new, compliant execution resources can be quickly re-matched without requiring manual reconfiguration of the process, resulting in a significant improvement in adaptation efficiency.

[0042] Furthermore, in another embodiment, such as Figure 5 As shown, after binding execution resource objects to each executable action unit, an action chain carried by each execution resource object is generated by combining the dependencies between the executable action units, including the following steps: S330. Perform topological sorting on all executable action units according to the verified dependency mapping set to determine the sequential execution chain, parallel execution group, and conditional branch structure. S340. Combine the execution resource objects bound to each executable action unit to generate a linear action chain or a directed acyclic graph structure of action chains.

[0043] Based on the dependency rules in the verified dependency mapping set, the executable action units are topologically sorted to distinguish sequential execution chains, parallel execution groups, and conditional branch structures. Linear action chains or directed acyclic graph (DAG) action chains are then generated by combining the execution resource objects already bound to each executable action unit. In the generated action chains, at least two execution resource objects reside in different software environments, thus constituting cross-software environment execution.

[0044] Further pre-execution verification can be performed to verify the end-to-end input-output connection, the feasibility of resource switching, and the feasibility of evidence requirements. After the verification is passed, the final action structure that can be directly scheduled is output, and a unique action version number is generated to associate with the corresponding rule and resource version, supporting subsequent traceable rollback.

[0045] The cross-software environment action chain generation method proposed in this application, through multi-source data collection, unstructured task requirements, scattered business rules, and heterogeneous resource information are uniformly converted into machine-recognizable structured data. This eliminates format differences between data from different sources at the source, providing fundamental support for subsequent fully automated action chain generation and eliminating the need for manual data processing and conversion. Furthermore, by constructing a constraint model that is completely decoupled from execution resources, a complete separation of the business rule layer and the execution layer is achieved. Subsequent business rule updates only require iterating the constraint model, and software environment changes only require adjusting execution layer resources, without reconstructing the entire action chain. At the same time, constraint units are accurately converted into action units and dependencies, ensuring that all mandatory business rules are implemented in the execution logic, thus avoiding compliance risks such as missed verification, unauthorized access, and lack of evidence from the generation side. The cross-software environment execution action chains generated by this method are not bound to specific pages, interfaces, or control identifiers. Compared with traditional RPA recording and manual process configuration, system iteration and rule updates do not require full-process reconstruction, and the built-in mandatory constraint verification and multi-source evidence verification significantly improve execution compliance and accuracy.

[0046] Furthermore, in another embodiment, such as Figure 6 As shown, the action chain generation method across software environments proposed in this application further includes the following steps: templated and categorized storage of the action chains: S410. After scheduling each execution resource object to complete the task semantic goal of the corresponding executable action unit, the action chain is templated for admission verification to eliminate action chains that are only temporarily adapted once and have no general reuse value, so as to obtain templated candidate action chains. S420. The candidate action chain is split into layers to remove the variable elements bound to the specific execution environment and abstract them into a standardized parameter set. The task execution logic, action dependency relationship, mandatory constraint rules and exception compensation logic are encapsulated into a stable structure layer. S430: After binding the standardized parameter set and stable structure layer to the parameter verification rules and resource matching rules included in the action chain, generate an action chain template with a unique version identifier, and add the action chain template to the preset template library for categorized storage.

[0047] Template-based admission verification is a pre-screening mechanism before action chains are converted into reusable templates. It can be verified based on three core dimensions: task universality, structural stability, and historical execution success rate. Only action chains with cross-scenario reusability are retained, avoiding invalid content from occupying template library resources.

[0048] Variable elements are exclusive content in the action chain that is strongly bound to the specific execution environment. They may include specific page addresses, control identifiers, interface paths, enterprise localization configuration values, local resource paths, etc., and are the content that needs to be replaced when reusing the action chain in different scenarios.

[0049] The stable structure layer is the core, general, and stable logic component of the action chain, stripped of all execution environment-related content. This stable structure layer can include task execution logic, action dependencies, mandatory constraint rules, exception compensation logic, and evidence verification rules. It serves as the core carrier for cross-scenario reuse, and this stable structure should be prioritized during reuse. When the current task is only partially adapted, only the difference constraint units and their corresponding action units can be adjusted. In one implementation, the stable structure layer can be an immutable stable structure layer, thus unifying the template structure and maintaining consistency throughout the processing.

[0050] Action chain templates are reusable action structures that have been layered, split, and parameterized. They come with a unique version identifier and can be quickly adapted to similar tasks in different environments through parameter instantiation, eliminating the need to generate action chains from scratch.

[0051] Specifically, action chains that have completed the entire process and passed verification are obtained, and the following three admission checks are performed: ① Generality check: Determine whether the task corresponding to the action chain belongs to a high-frequency general task (e.g., high-tech enterprise application, employee onboarding, contract payment collection, etc.), and directly remove action chains corresponding to single customized temporary tasks; ② Structural stability check: Determine whether the proportion of temporary manual intervention nodes during the execution of the action chain is lower than the threshold. If the proportion of manual intervention is too high, it indicates insufficient logical generality and can be directly removed; ③ Execution success rate check: For example, if the historical execution success rate of this type of action chain is lower than 90%, it can be removed. Only action chains that pass all checks can become templateable candidate action chains. If any one of them fails, the current action chain is determined to be an action chain with no reuse value and is directly removed and will not be reused.

[0052] The candidate action chain is then split into two layers: ① Variable element stripping: Traverse the attributes of all executable action units, extract all content associated with the specific execution environment, and organize them into a standardized parameter set with semantic tags and format validation rules; ② Stable structure layer encapsulation: Encapsulate the remaining common core logic (e.g., the order of task execution steps, the three types of dependencies between actions, all mandatory constraint rules, exception compensation logic, and multi-source evidence verification rules) into a stable structure layer to ensure that the core compliance logic remains unchanged during the reuse process.

[0053] Finally, the standardized parameter set and stable structure layer are bound with the corresponding parameter verification rules and resource automatic matching rules. Then, a unique version identifier, scene classification label, and scope of application description are assigned to the generated action chain template, which is stored in the template library and a classification index is established for easy reuse and retrieval in the future.

[0054] In this embodiment, the general compliance logic of action chains across software environments and the variable content of the environment are completely separated. Similar cross-software tasks do not need to generate action chains from scratch; they can be quickly adapted simply by instantiating parameters, greatly improving implementation efficiency. At the same time, the solidified stable structure layer avoids compliance deviations during cross-scenario reuse, significantly reducing the rule configuration cost and compliance risks for similar tasks.

[0055] Furthermore, in another embodiment, the method may further include the following steps: S440. When a new task is detected, first extract the corresponding task intent, constraint rules, and execution environment, and then perform multi-dimensional matching in the template library. S450. If an action chain template generated from the initial action chain is matched, fill in the parameters corresponding to the current task and bind the local execution resource object to generate an executable action chain.

[0056] Multi-dimensional template matching can be a matching mechanism that calculates the similarity between the task to be executed and the templates in the template library by weighting multiple dimensions such as task intent, constraint structure, input pattern, field pattern, target result, and execution environment compatibility, rather than single keyword matching. Such matching results are more in line with actual business requirements.

[0057] The fit threshold is a pre-set minimum similarity requirement for template reuse. The template can only be reused when the similarity between the matching task and the template is higher than this threshold. This ensures the logical fit of the template after reuse from the admission level and avoids execution abnormalities caused by mismatched templates.

[0058] Parameter instantiation is the process of filling the variable parameter set placeholders of the action chain template with the specific business data and localized configuration content of the current task, and completing the legality verification through the parameter validation rules built into the template.

[0059] Specifically, when a new task is initiated, the standardized feature vector of the current task is extracted according to the same feature dimensions as when the template was entered into the database. For example, it includes task intent tags, structured constraint rules (e.g., required fields, permission requirements, evidence requirements, etc.), input material patterns, field validation rules, expected output results, and resource type features of the current execution environment, to ensure that the feature dimensions are fully aligned with the template database index.

[0060] Then, iterate through all templates in the template library under the corresponding scene category, calculate the matching scores for multiple dimensions, and sum them to obtain the total fit score. All templates with a total fit score lower than the preset threshold are directly excluded and do not need to proceed to subsequent verification. After filtering out all templates that meet the fit score standard, select the template with the highest fit score as the reuse template; if there is no template that meets the fit score standard, automatically jump to the regular cross-software environment action chain generation process to build an action chain adapted to the current task from scratch.

[0061] The specific business data and localized configuration content of the current task are populated into the standardized parameter set of the reuse template, triggering the template's built-in parameter validation rules to check whether the parameter format, field rules, and required fields meet the requirements. If the validation fails, parameter completion prompts or processing procedures are automatically triggered.

[0062] Based on the resource matching rules built into the template and combined with the execution resource description information of the current execution environment, each executable action unit in the stable structure layer is bound to a local main execution resource object and a backup execution resource object that meet the requirements, and finally an action chain that is adapted to the current task and can be directly scheduled and executed is generated.

[0063] In this embodiment, the action chain template reuse process improves the efficiency of action chain generation for similar cross-software tasks, eliminates the repetitive development costs of the entire process from constraint modeling to binding execution resource objects, and reuses the core logic of templates that have been verified by historical execution, which greatly reduces the compliance risks and execution failure probability of newly generated action chains.

[0064] This application also proposes an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor. This electronic device supports processing or communication for at least two different applications, and when the processor executes the computer program, it implements the cross-software environment action chain generation method of any of the above embodiments. The definitions of terms, specific examples, and their technical effects can be found in the embodiments of the above methods, and will not be repeated here. The various steps in the above methods can be implemented on the same electronic device or completed by multiple electronic devices working together.

[0065] This application also proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the cross-software environment action chain generation method of any of the above embodiments. The definitions of terms, specific examples, and technical effects involved can be found in the embodiments of the above methods, and will not be repeated here. The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for generating action chains across software environments, characterized in that, include: Obtain the description information of the task to be executed, the execution constraint information associated with the description information of the task to be executed, and the execution resource description information of the current execution environment; Based on the execution constraint information, a constraint model decoupled from the associated execution resources is constructed, and at least one executable action unit is generated based on the constraint model, and the dependency relationship between each executable action unit is determined. Based on the at least one executable action unit and the execution resource description information, one or more execution resource objects are bound to each executable action unit, and an action chain carried by each execution resource object is generated by combining the dependencies between the executable action units; wherein, at least two execution resource objects in the action chain are located in different software environments.

2. The method according to claim 1, characterized in that, The step of constructing a constraint model decoupled from the associated execution resources based on the execution constraint information, generating at least one executable action unit based on the constraint model, and determining the dependencies between the executable action units includes: A constraint model is constructed based on the execution constraint information, which is decoupled from the associated execution resources and includes multiple constraint units and the relationships between the constraint units. Based on the constraint model, at least one executable action unit including task semantic objectives and resource capability requirements is generated, and an action-constraint mapping relationship is established between each executable action unit and the associated constraint unit. Based on the constraint model and the action-constraint mapping relationship, the dependencies between each of the executable action units are determined.

3. The method according to claim 2, characterized in that, The step of binding one or more execution resource objects to each of the at least one executable action unit and the execution resource description information includes: Based on the task semantic objective and resource capability requirements corresponding to each executable action unit, execution resources that do not meet the preset conditions are removed from the execution resource library corresponding to the execution resource description information through hard gating; wherein, the preset conditions include at least two of the following: action capability, access permission, version compatibility, state reachability, and mandatory evidence acquisition requirements; For the remaining execution resources, according to a preset matching degree evaluation mechanism or a multi-action joint solution mechanism, each executable action unit is bound to an execution resource object, or each executable action unit is bound to a main execution resource object and at least one backup execution resource object.

4. The method according to claim 1, characterized in that, The step of obtaining the description information of the task to be executed includes: Receive task input information associated with the task to be executed, obtained from a multi-source input interface; wherein the task input information includes at least one of text, voice, image, file, form data, interactive operation trajectory, or external event; Based on the interface type corresponding to the input interface that provides the task input information, and combined with the preset parsing rules that match the interface type, the core element information corresponding to the task to be executed is extracted from the task input information. The extracted core element information is encapsulated into a standardized task context structure in a unified format; wherein the standardized task context structure includes a globally unique task identifier, a task semantic target, a task subject, a task operation object, a task input set, a time constraint set, and a desired output set.

5. The method according to claim 4, characterized in that, The execution constraint information associated with the description information of the task to be executed is obtained through the following steps: Based on the standardized task context structure, matching candidate constraint packages are determined from the preset rule data source and sorted according to their fit to obtain the constraint rule set with the highest fit. In the set of constraint rules, the constraint rules are merged and compatible in the order of more specific rules first, mandatory rules first, and latest version first, so as to obtain the execution constraint information.

6. The method according to claim 1, characterized in that, The execution resource description information of the current execution environment is obtained through the following steps: Obtain the currently available execution resources and their metadata from at least one of the following methods: web page structure, accessibility tree, control tree, interface definition document, file metadata, system call feedback, execution log, visual interface parsing results, and manual registration information; Standardized descriptive attributes are generated based on the metadata corresponding to each execution resource, and all the descriptive attributes are encapsulated into the execution resource description information; wherein, the descriptive attributes include resource type, access method, semantic tag, set of executable operations, input / output mode, and permission scope.

7. The method according to claim 3, characterized in that, The step of determining the dependencies between each of the executable action units based on the constraint model and the action-constraint mapping relationship includes: Based on the relationships between the constraint units in the constraint model and the mapping relationship between actions and constraints, the relationships between the constraint units are converted into a set of dependency mappings between the executable action units, including at least sequence dependency, data dependency, and evidence dependency. The dependency mapping set is subjected to compliance verification to obtain a verified dependency mapping set in which each dependency meets the preset requirements and is executable; wherein, the dependency compliance verification includes checking for abnormal issues such as circular dependencies, dependency conflicts, no start node, and no end node.

8. The method according to claim 7, characterized in that, The step of generating an action chain carried by each execution resource object by combining the dependencies between the various executable action units includes: Based on the verified dependency mapping set, all executable action units are topologically sorted to determine the sequential execution chain, parallel execution group, and conditional branch structure. By combining the execution resource object bound to each of the executable action units, a linear action chain or a directed acyclic graph structure of action chains is generated.

9. The method according to claim 5, characterized in that, The step of constructing a constraint model decoupled from the associated execution resources based on the execution constraint information includes: The execution constraint information is processed to extract all action description information that needs to be processed by execution resources, thereby obtaining rule semantic information associated with the constraint rules; wherein, the action description information includes at least one of web page links, control identifiers, interface addresses, operation paths, software names, page positions, and page coordinates; The field information with different sources and different expressions in the semantic information of the rules is processed into standardized semantic rules; The standardized semantic rules are decomposed into constraint units with relatively independent constraint semantics, and each constraint unit is labeled with relatively independent semantic identification information. Based on the business processing logic corresponding to the description information of the task to be executed, the association relationship between all the constraint units is determined to generate a constraint model in the form of a directed acyclic graph, rule tree, or state machine between the constraint units; wherein, the association relationship in the constraint model is used to describe the logical dependency relationship between the constraint rules of each constraint unit.

10. The method according to claim 9, characterized in that, The logical dependencies include sequential association, data association, and at least one of evidence association, condition association, mutually exclusive association, parallel association, and quantity constraint association.

11. The method according to claim 1, characterized in that, The method further includes: After scheduling each of the execution resource objects to complete the task semantic target of the corresponding executable action unit, the action chain is subjected to templated admission verification to eliminate action chains that are only temporarily adapted once and have no general reuse value, thereby obtaining templated candidate action chains. The candidate action chain is split into layers to remove the variable elements bound to the specific execution environment and abstract them into a standardized parameter set. The task execution logic, action dependency relationship, mandatory constraint rules and exception compensation logic are encapsulated into a stable structural layer. After binding the standardized parameter set and the stable structure layer with the parameter verification rules and resource matching rules included in the action chain, an action chain template with a unique version identifier is generated, and the action chain template is added to a preset template library for categorized storage.

12. The method according to claim 11, characterized in that, The method further includes: When a new task is detected, the corresponding task intent, constraint rules, and execution environment are extracted and matched against the template library in multiple dimensions. If an action chain template generated from the initial action chain is matched, the parameters corresponding to the current task are populated and the local execution resource object is bound to generate an executable action chain.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The electronic device supports processing or communication for at least two different applications, and the processor, when executing the computer program, implements the cross-software environment action chain generation method according to any one of claims 1 to 12.

14. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the cross-software environment action chain generation method according to any one of claims 1 to 12.

Images