Method, apparatus, device, and product for processing tasks

Abstract

The present application relates to a method, device, equipment and product for processing a task. The method comprises determining an association relationship of a task node, the association relationship indicating association information of the task node and other task nodes, the association relationship comprising at least one of a first relationship or a second relationship, the first relationship indicating first information in the association relationship, the second relationship indicating second information in the association relationship, the first information and the second information being independent of each other. The method further comprises processing a task of the task node based on at least one of the first relationship or the second relationship, the task being executed on the task node. By the method, the overall efficiency of the task node in processing the task is improved.

Description

Technical Field

[0001] This article generally relates to the field of information processing, and more specifically to methods, apparatus, devices and computer program products for processing tasks. Background Technology

[0002] In the development of multi-task nodes (e.g., multi-task nodes in machine learning), requirements, design, implementation, verification, and fixes form linear, branching, and converging structures, often using a single identifier, workflow stage sequence, or file links to express multiple relationships simultaneously. Summary of the Invention

[0003] In the examples presented herein, a method, apparatus, electronic device, and computer program product for processing tasks are provided.

[0004] In a first aspect of this document, a method for processing tasks is provided. The method may include determining associations of task nodes, including at least one of a first relationship or a second relationship, wherein the association indicates association information between the task node and other task nodes, the first relationship indicates first information in the association, the second relationship indicates second information in the association, and the first and second information are independent of each other. The method may further include processing a task of the task node based on at least one of the first or second relationships, wherein the task is executed on the task node.

[0005] In a second aspect of this document, an electronic device for processing tasks is provided. The device includes a determining module configured to determine an association relationship of a task node, including at least one of a first relationship or a second relationship, wherein the association relationship indicates association information between the task node and other task nodes, the first relationship indicates first information in the association relationship, the second relationship indicates second information in the association relationship, and the first and second information are independent of each other. The device also includes a processing module configured to process a task of the task node based on at least one of the first or second relationships, wherein the task is performed on the task node.

[0006] In a third aspect of this document, an electronic device is provided. The electronic device includes a processor. The electronic device also includes a memory coupled to the processor, the memory having instructions stored therein, which, when executed by the processor, cause the electronic device to perform the method according to the first aspect of this document.

[0007] In a fourth aspect of this document, a computer program product is provided, comprising computer-executable instructions, wherein the computer-executable instructions are executed by a processor to implement the method according to the first aspect of this document.

[0008] In a fifth aspect of this document, a computer-readable storage medium is provided. The computer-readable storage medium stores computer-executable instructions, which are executed by a processor to implement the method according to the first aspect.

[0009] The summary section is intended to present the chosen concepts in a simplified form, which will be further described in the detailed description below. The summary section is not intended to identify key or principal features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the examples herein will become more apparent when taken in conjunction with the accompanying drawings and the following detailed description. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0011] Figure 1 A schematic diagram is shown illustrating an example environment in which one or more examples in this article can be implemented;

[0012] Figure 2 Flowcharts illustrating some of the methods used in this paper to process tasks are shown;

[0013] Figure 3 A flowchart is shown illustrating a preliminary preparation method for processing a task, based on one or more examples in this document;

[0014] Figure 4 This illustrates a flowchart of a method for determining an input list for processing a task, based on one or more examples in this paper;

[0015] Figure 5 This shows a flowchart of a method for a post-processing task based on one or more examples in this paper;

[0016] Figure 6 A block diagram of an electronic device for processing tasks, according to some examples in this paper, is shown;

[0017] Figure 7 A block diagram of a device capable of implementing several of the examples in this paper is shown;

[0018] In all the accompanying figures, the same or similar reference numerals denote the same or similar elements. Detailed Implementation

[0019] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0020] It is understandable that before using the technical solutions disclosed in the examples in this article, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this article in an appropriate manner in accordance with relevant laws and regulations, and their authorization should be obtained.

[0021] For example, upon receiving a user's proactive request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations described herein, based on the prompt message.

[0022] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0023] It is understood that the above notification and user authorization process is merely illustrative and does not limit the implementation method described in this article. Other methods that comply with relevant laws and regulations may also be applied to the implementation method described in this article.

[0024] The examples herein will now be described in more detail with reference to the accompanying drawings. While some examples of this document are shown in the drawings, it should be understood that this document can be implemented in various forms and should not be construed as limited to the examples set forth herein; rather, these examples are provided to provide a more thorough and complete understanding of this document. It should be understood that the accompanying drawings and examples are for illustrative purposes only and are not intended to limit the scope of this document.

[0025] In the description of the examples in this document, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The terms "an example" or "the example" should be understood as "at least one example". The terms "first", "second", etc., may refer to different or the same objects unless explicitly stated otherwise. Other explicit and implicit definitions may also be included below.

[0026] As mentioned above, multiple relationships are typically expressed using a single identifier, workflow stage sequence, or file links. Furthermore, during task execution, the data from upstream task nodes is usually temporarily appended to the prompt context by the caller, consisting of comments, summaries, or working directory files. If the task is retried, the platform may reread the current upstream file. If the upstream task node has been rerun, updated, or deleted, the same downstream task will see different inputs in two dispatches. For large amounts of content, some systems directly truncate the text before calculating the summary or hash.

[0027] Therefore, to address at least one of the above problems, one or more examples in this paper provide a mechanism capable of representing different relationships between task nodes and processing tasks based on these relationships. Specifically, one or more examples in this paper can determine that the relationships between task nodes include at least one of a first relationship or a second relationship, wherein the relationship indicates the association information between the task node and other task nodes, the first relationship indicates first information in the relationship, the second relationship indicates second information in the relationship, and the first and second information are independent of each other. Furthermore, one or more examples in this paper can also process the tasks of task nodes based on at least one of the first or second relationships, wherein tasks are executed on the task nodes. In this way, one or more examples in this paper provide a mechanism for processing tasks, and based on this mechanism, improve the overall efficiency of task nodes in processing tasks.

[0028] Figure 1 A schematic diagram of an example environment 100 in which one or more examples of this article can be implemented is shown. For example... Figure 1As shown, environment 100 includes processing device 102. Processing device 102 can be any device with processing capabilities. For example, processing device 102 can include smartphones, tablets, laptops, desktop computers, workstations, servers, cloud computing, quantum computers, or smart wearable devices, etc. In environment 100, processing device 102 can run task management application 104, which can be used to manage various functions of tasks (such as task execution, rerunning, updating, or deletion). User 116 can interact with task management application 104 through processing device 102. In some examples, task management application 104 can obtain various types of information from intelligent systems. In some examples, intelligent systems can include intelligent systems 110, 112, or 114, etc. In task management application 104, users can use relevant information from intelligent systems 110, 112, or 114, etc., to create tasks or complete related tasks, etc. Intelligent systems 110, 112, or 114, etc., can be at least one of existing or future intelligent systems. Task management application 104 may include a task processing module 106 according to one or more examples herein. Task processing module 106 may be configured to be a fully automatic, 24 / 7 task processing module. Task processing module 106 may also efficiently complete various tasks by obtaining information from various intelligent systems 110, 112, or 114, etc., based on the association relationship 108 of task nodes, through interaction with user 116.

[0029] Specifically, the task processing module 106 can determine that the association relationship of the task node includes at least one of a first relationship or a second relationship, wherein the association relationship indicates the association information between the task node and other task nodes, the first relationship indicates first information in the association relationship, the second relationship indicates second information in the association relationship, and the first and second information are independent of each other. Furthermore, the task processing module 106 can also process the task of the task node based on at least one of the first or second relationships, wherein the task is executed on the task node. In this way, the task processing module 106 provides a mechanism for processing tasks, and based on this mechanism, improves the overall efficiency of task node task processing.

[0030] It should be understood that, for the sake of brevity, Figure 1This document only shows a specific number of processing devices 102, task management applications 104, task processing modules 106, and intelligent systems 110, 112, or 114, etc., but it is not intended to limit the number of processing devices 102, task management applications 104, task processing modules 106, and intelligent systems 110, 112, or 114, etc. In other implementations, any number of processing devices 102, task management applications 104, task processing modules 106, and intelligent systems 110, 112, or 114, etc., applicable to this document, may be used. For example, processing device 102 may also be a cloud computing platform, etc.

[0031] In this way, the environment 100 containing the task processing module 106 of one or more example implementations of this paper provides a mechanism for processing tasks and improves the overall efficiency of task nodes in processing tasks based on this mechanism.

[0032] The following will combine Figures 2 to 7 The process described in detail is based on the examples in this document. For ease of understanding, the specific data mentioned in the following description are exemplary and are not intended to limit the scope of protection of this document. It should be understood that the examples described below may also include additional actions not shown and / or the actions shown may be omitted, and the scope of this document is not limited in this respect.

[0033] Figure 2 A flowchart illustrating a method 200 for processing a task, as shown in this paper, is provided. Method 200 can be executed by a processing device. For example, method 200 can be performed by… Figure 1 The processing device 102 performs the operation. The processing device may include, for example, a smartphone, tablet computer, laptop computer, desktop computer, workstation, quantum computer, cloud computing platform, or smart wearable device.

[0034] In step 202, determining the association relationships of task nodes includes at least one of a first relationship or a second relationship, wherein the association relationship indicates the association information between a task node and other task nodes, the first relationship indicates first information in the association relationship, the second relationship indicates second information in the association relationship, and the first and second information are independent of each other. In some examples, method 200 may also include determining that the association relationships of task nodes include a first relationship, a second relationship, and a third relationship, wherein the first relationship, the second relationship, and the third relationship respectively indicate independent information in the association relationships of task nodes, and the third relationship indicates the attribution information between task nodes in a process or historical relationship.

[0035] In some examples, the first relationship may include task execution dependencies, the second relationship may include data dependencies for executing tasks, and the third relationship may include node organization relationships, etc. These three can be combined, but no relationship can be implicitly replaced by another, and they are independent of each other. In some examples, product (or result) passing or explicit referencing can answer questions such as which upstream products are read during execution and under what names. In some examples, product passing on execution dependencies controls the scope of products passed along with dependencies, etc. In some examples, explicit product referencing can provide non-blocking or custom-named data input, etc. In some examples, node organization relationships can answer questions such as which process, stage, or historical branch a task node belongs to. In some examples, node organization relationships can be used for attribution, template validity constraints, and audit presentation, and must not be automatically equivalent to execution predecessors.

[0036] In some examples, these three relationships can exist independently. For instance, when there is only an explicit artifact reference without an execution dependency, the data reference itself does not constitute an execution prerequisite. When there is only an execution dependency and the artifact propagation scope is empty, the upstream still blocks execution but does not propagate the file. Additionally, when two task nodes belong to the same process container but have no execution dependencies, they can execute in parallel.

[0037] By employing these three relationships, it is possible to avoid mistaking data references for execution prerequisites or mistaking related processes for sequential dependencies, and to support branching, merging, and non-blocking references. Furthermore, by establishing prerequisite relationships based on the relevant technical characteristics of the scope of output propagation carried by execution dependencies, upstream data can be deterministically obtained, and the propagation scope can be closed or narrowed as needed.

[0038] Back Figure 2 In step 204, based on at least one of a first relation or a second relation, the task of the task node is processed, wherein the task is executed on the task node. In some examples, method 200 may include preventing the task node from processing its task in response to the task node having a first relation with an upstream task node, wherein the first relation indicates that the task node needs to wait for all upstream task nodes to complete their tasks. In some examples, method 200 may also include, in response to the upstream task nodes completing all their tasks, obtaining at least a partial result of the upstream task nodes completing their tasks based on a transitive attribute in the first relation, wherein the transitive attribute indicates the task node's dependency on the results of the upstream task nodes, and processing the task node's task based on the at least partial result of the upstream task nodes completing their tasks. The transitive attribute in the first relation ensures that the current task node obtains the information it needs to process its task by waiting for the upstream nodes' tasks to complete.

[0039] In some examples, method 200 may further include processing the task of the task node in response to the association between the task node and the upstream task node being a second relationship, wherein the second relationship indicates that the task node does not need to wait for the upstream task node to complete all of its tasks. In some examples, method 200 may further include obtaining the result of the upstream task node at least partially completing its tasks based on the task node's input requirements, wherein the input requirements indicate the identifier of the upstream task node and the processing result information required to process the task node's tasks, and processing the task node's tasks based on the result of the upstream task node at least partially completing its tasks. Because the second relationship specifies that only partial data is needed, the task node does not need to wait for the upstream node to complete all its tasks, but can inquire midway whether the required information is ready, thus saving waiting time and improving the processing efficiency of tasks belonging to the second relationship within the task node.

[0040] In some examples, method 200 may further include determining the input of the task node, determining compressed information of the task node's input based on the task node's input, and using the compressed information as a list of task node inputs. In some examples, determining the task node's input may include deduplicating the results of upstream task nodes, and determining the task node's input based on the deduplicated results of upstream task nodes and the task node's own input. This explicit artifact reference priority and deduplication technique, along with support for custom mount names, avoids duplicate injection of same-source artifacts and wasted context windows. In some examples, the compressed information may include the hash value of the task content.

[0041] In some examples, method 200 may further include determining that the input list exceeds a first threshold, retaining the input list in response to the input list exceeding the first threshold, and prohibiting the determination of new compressed information based on the truncated content of the task node's input. In some examples, method 200 may further include storing the task node's input list in a read-only area, sending the task node's tasks and inputs to the intelligent system, receiving the intelligent system's processing results for the task node's tasks, and storing the intelligent system's processing results for the task node's tasks in an output area. This solves the problem of upstream task node inputs and current-round outputs sharing a directory; for example, input files can easily be mistaken for current-round outputs, causing access control errors or overwriting. Therefore, by physically separating the input area from the output area, this problem is avoided.

[0042] In some examples, method 200 may further include determining the processing result of the intelligent system on the task node as a processing result containing at least one of the following: result identifier, task node identifier, result type, path, result content, result version, and input source; and deleting the processing result of the intelligent system on the task node. In some examples, the deletion of the processing result of the intelligent system on the task node is a soft deletion, thus not affecting the execution of historical task nodes. In some examples, method 200 may further include determining that the execution instance of the intelligent system has a corresponding input list, and reusing the input list in response to the existence of a corresponding input list for the execution instance of the intelligent system. In these examples, by freezing the input list when the execution instance is first dispatched, and reusing the input list for subsequent re-dispatch of the same execution instance, it is possible to ensure that subsequent changes upstream do not change the input of historical execution instances, and to reproduce retries and accurately answer "based on what" the task was executed at that time, thereby ensuring the traceability and trackability of the processing tasks of the task node.

[0043] In summary, one or more examples of Method 200 address several technical problems in this way. For instance, one or more examples of Method 200 resolve the issue of parent node relationships or stage order bearing all relationships, such as data references unexpectedly blocking execution, organizational affiliation being misinterpreted as a precondition, and complex branches not being accurately expressed. One or more examples of Method 200 decompose execution dependencies, task processing result (or artifact) transitive relationships, and node organizational relationships into mutually independent (or orthogonal) associations.

[0044] Furthermore, one or more examples of Method 200 address the issue of dependencies only expressing the order of completion. For instance, downstream task nodes may require additional configuration of data, leading to the risk of forgetting to pass or duplicate mounting. One or more examples of Method 200 explicitly configure the scope of artifact delivery for each dependency that must be executed, and provide reasonable default values.

[0045] Furthermore, one or more examples of Method 200 address the issue of needing to reread upstream task nodes for each task dispatch. For instance, if the retry input for the same intelligent system execution instance changes with the upstream task node, it cannot answer the question "which version of the data was it based on?". One or more examples of Method 200 freeze the input list when the intelligent system execution instance is first dispatched, and this input list is always reused in subsequent redispatches of the same execution instance.

[0046] On the other hand, one or more examples of Method 200 also address the issue of inputs from upstream task nodes sharing the same directory as current-round outputs. For example, input files can easily be mistaken for current-round outputs, leading to incorrect access control or overwriting. One or more examples of Method 200 physically separate the read-only control / inputs area from the control / artifacts area, thereby avoiding this problem.

[0047] Furthermore, one or more examples of Method 200 address the issue of silent truncation of overloaded content, such as inconsistent hashes with the actual complete content, leading to unverifiable audit results. Meanwhile, one or more examples of Method 200 preserve the complete content hash and source metadata, and explicitly omit inline content using a sentinel without blocking dispatch.

[0048] By addressing the aforementioned issues, the orthogonal correlation features of the three relationships in one or more examples of Method 200 avoid mistaking data references for execution prerequisites or related processes for sequential dependencies, and support branching, merging, and non-blocking references. Furthermore, after establishing prerequisite relationships using the execution dependency-carrying artifact propagation scope features in one or more examples of Method 200, upstream data can be deterministically obtained, and the propagation scope can be closed or narrowed as needed.

[0049] Additionally, the explicit artifact reference priority and deduplication techniques in one or more examples of Method 200 support custom mount names and avoid duplicate injection of same-source artifacts and wasted context windows. The first-freeze task input list technique in one or more examples of Method 200 ensures that subsequent upstream changes do not alter the input of historical execution instances, and also enables retrying and accurately answers the question of "what was the task based on at the time".

[0050] Furthermore, the full content hashing and over-limit sentinel-related techniques in one or more examples of Method 200 control storage volume while preserving content integrity proofs and preventing false audits due to truncated hashes. Additionally, the techniques related to separating the read-only input area from the product output area in one or more examples of Method 200 prevent upstream inputs from impersonating current-round products or being overwritten by intelligent system executors, thereby improving access control accuracy. Furthermore, the execution entry re-checking and lock replacement techniques in one or more examples of Method 200 avoid dependency changes and dispatch race conditions that could lead to the use of incorrect predecessors or incorrect inputs.

[0051] Therefore, one or more examples of Method 200 extend the task lineage from a single tree relationship to an auditable graph composed of "control edges, data edges, attribution edges, and actual consumption snapshots," while simultaneously grounding the abstract relationship into real input evidence for each specific execution through an immutable task input list. Thus, one or more examples of Method 200 construct a multi-dimensional task lineage and immutable context backflow mechanism, ensuring that execution gates, data transfer, and organizational attribution are non-substitutable. Any downstream task can deterministically obtain the required upstream output, and even after upstream changes, the actual content used during its initial execution can still be audited, achieving significant technical effects.

[0052] To help those skilled in the art better understand the implementation of the overall method presented in this paper, Figure 3-5 An overall flowchart for processing tasks is shown, based on one or more examples in this document. Figure 3 A flowchart is shown of a preliminary preparation method 300 for processing a task, based on one or more examples in this document. Figure 4 This illustrates a flowchart of a method 400 for determining an input list for processing a task, based on one or more examples in this document. Figure 5 This illustrates a flowchart of a method 500 for a post-processing task based on one or more examples in this paper.

[0053] It is important to note that the detailed methodologies described below are merely examples and not intended to limit the scope of this document. Any methodologies and their variations suitable for this document should be within its scope. Furthermore, the specific steps involved are also merely examples and not intended to limit the scope of this document. Any specific steps or combinations of specific steps suitable for this document should be within its scope.

[0054] Before detailing methods 300-500, let's introduce some examples of related terminology. In some examples, a task node can include a work unit that carries an independent task objective, execution status, and output. In some examples, the `task_node_id` (task_node_identifier) ​​field in the implementation of a task node can represent the identifier of that task node. In some examples, a research and development task node can include a work unit that carries an independent research and development objective, execution status, and output. The `task_node_id` field in the implementation of this research and development task node only represents the identifier of that research and development task node. It is worth noting that the research and development task node is merely one example of a task node and can include any task node suitable for this article, such as task nodes for product development, task nodes for updating existing products, etc.

[0055] In some examples, explicit execution dependencies include predecessor constraints that determine when a task node can be executed, and explicit execution dependencies include control relationships. In some examples, artifacts (or results) may include versionable outputs generated after the execution of a task node, including at least one of code changes, design documents, test reports, or structured data. In some examples, R&D artifacts (or R&D results) may include versionable outputs generated after the execution of R&D task nodes, including at least one of code changes, design documents, test reports, or structured data.

[0056] In some examples, artifact delivery scope may include configurations declaring which sources the current node is allowed to receive artifacts from. In some examples, the implementation field of artifact delivery scope may be named artifact_scope. In some examples, explicit artifact references may include directed references to specific source nodes, artifact types, or versions. Different systems may use different reference record names.

[0057] In some examples, the task input manifest may include a set of inputs generated and frozen when one or more intelligent system execution instances are first dispatched. This input set may record at least one of the following for each input: source, version, or injection method. In some examples, this manifest is reused for continuation, retries, and redispatch of the same execution instance, and a new version of the manifest can be created when a new execution instance is created. In some examples, the implementation field of the task input manifest may be named task_input_manifest (task_input_manifest) or input_manifest (input_manifest), etc.

[0058] In some examples, node organization includes information describing the affiliation of task nodes within a process, parent-child, or historical hierarchy. Node organization does not directly determine whether an action is executable or which data is transmitted. In some examples, intelligent system execution instances may include one or more stateful execution processes of task nodes executed by the intelligent system. Different intelligent systems may use different execution record names.

[0059] One or more examples in this article distinguish the relationships between task nodes, such as execution dependencies, data dependencies, and node organization relationships. These three can be combined, but no relationship can be implicitly replaced by another, and they are independent of each other. In some examples, execution dependencies can answer the question of when the current development task node is allowed to execute. Execution dependencies can use `task_node_id` (task_node_identifier) ​​and `predecessor_task_node_id` (predecessor_task_node_identifier) ​​to record normalized control edges, where all necessary predecessors must be satisfied before execution can pass the gate.

[0060] In some examples, product passing or explicit referencing can answer questions such as which upstream products are read at execution time and under what names. In some examples, product passing on execution dependencies controls the scope of products passed in with dependencies. In some examples, explicit product referencing can provide non-blocking or custom-named data input. In some examples, node organization can answer questions such as which process, stage, or historical branch a task node belongs to. In some examples, node organization can be used for attribution, template validity constraints, and audit presentation, and must not be automatically equivalent to execution predecessors.

[0061] In some examples, all three relationships can exist independently. For instance, when there is only an explicit artifact reference without an execution dependency, the artifact reference itself does not constitute an execution prerequisite. When there is only an execution dependency and the artifact propagation scope is none (empty), the upstream still blocks execution but does not propagate the file. Additionally, when two task nodes belong to the same process container but have no execution dependencies, they can execute in parallel.

[0062] Back Figure 3 In a 302 response, upstream artifacts can be frozen in response to an upstream task node completing its task. In some examples, upstream completion results can be persisted as entities or informational items with attributes such as artifact_id, task_node_id, kind (type), path, content, version, or source_task_id. In some examples, deleting an item can be done using soft deletion.

[0063] In some examples, control dependencies can be established in 304 or 306 errors. In some examples, such as in 304 errors, dependencies can be explicitly declared and executed on downstream task nodes. In some examples, the scope of propagation can be configured, for example, each dependency can be written with three scope values: all, required, or none. In some examples, the default is all if not specified. In some examples, all can indicate that all frozen artifacts from upstream that have not been soft-deleted can be mounted as the default value for new dependencies. In some examples, required can indicate that only required artifacts declared by upstream can be mounted. In some examples, none can indicate that only execution gates are retained, and upstream artifacts are not propagated.

[0064] In some examples, explicit artifact references are frozen when a development task node is created. Mounted names are unique within the same development task node and meet security character and quantity restrictions to prevent path traversal. In other examples, during the planning phase before any intelligent system execution instances have been created, execution dependencies can be atomically replaced entirely. Once an active or final execution instance exists, execution dependencies are locked to prevent rewriting historical preconditions after execution.

[0065] In some examples, explicit artifact references are used in situations where execution prerequisites are not established or where custom mount directories are required. When a task node from the same source provides data through both execution dependencies and explicit artifact references, explicit references take precedence. The system deduplicates artifacts passed with dependencies to avoid duplicate injection of the same artifact set.

[0066] In some examples, an entry point recheck can be performed at step 308. For instance, all necessary predecessors can be checked before the initial execution, rerun, retrieval, resumption after manual intervention, recovery, and scheduling of a task node. In some examples, it can be determined whether all necessary predecessor task nodes for the current task node have been completed. In some examples, at step 312, in response to "No," the initial execution, rerun, retrieval, resumption after manual intervention, recovery, and scheduling of a task node can be prevented. In some examples, at step 314, in response to "Yes," the upstream product of the upstream task node can be selected for subsequent processing according to the product delivery range, and the process can proceed to the corresponding subsequent step A, etc.

[0067] In some examples, such as 306, explicit artifact references can be declared on downstream task nodes. In some examples, zero or more required predecessors can be written to downstream (R&D) task nodes, validating them to be in the same workspace, of valid types, non-self-referencing, and not forming circular references. In some examples, establishing explicit references can include optionally writing the source task node identifier and mount name, using non-blocking data input or a custom directory, and not creating execution dependency edges. In some examples, such as 310, artifact references can be selected by custom mount names, and then the process jumps to the corresponding subsequent step A.

[0068] Go to Figure 4 Method 400 is shown to prepare the input list for the task node. In 402, the input can be parsed. For example, information such as the task node's own input, execution dependencies, explicit references, and compatible parent node sources can be collected, and deduplication can be performed according to explicit reference priority rules. In some examples, the deduplicated explicit reference information is merged with the task node's own input information to form the task node's input list information.

[0069] Optionally, at 404, it is determined whether the current intelligent system execution instance already has an input list. At 408, in response to no, the input list of the task node can be frozen for the first time. For example, when the intelligent system execution instance first constructs and dispatches the task payload, the actual path, content, source, and hash calculated based on the complete content are written into a versioned task input list, which corresponds one-to-one with the execution instance. And at 410, it is determined whether the input list exceeds a security threshold. The security threshold can be determined based on the experience of those skilled in the art or actual needs. This document does not impose any limitations on it. Any security threshold suitable for this document should be within the scope of protection of this document.

[0070] In some examples, such as at 414, in response to the input list not exceeding the security threshold, the complete content is retained in the input list, and the process proceeds to step B, etc. In some examples, such as at 412, in response to the input list exceeding the security threshold, the path, complete compressed content (e.g., content hash value, etc.), and source are retained, while inline content is set to null and the reason for exceeding the threshold is recorded. Furthermore, the hash of the truncated content must not be calculated to ensure the uniqueness of the compressed content. The process then proceeds to step B, etc.

[0071] Returning to 404, if it is determined at 404 that the current intelligent system execution instance already has an input list, then at 406, an immutable input list for reusing the intelligent system execution instance can be determined. Based on the immutable input list of the reusable intelligent system execution instance, as with other steps in this stage, we can proceed to step B, etc.

[0072] Go to Figure 5 Method 500 is shown to complete the task on the task node. In 502, the task node can dispatch a payload to the intelligent system, carrying the complete actual input. In some examples, execution-side materialization can be performed. For example, in 504, the complete task payload is written to the read-only input area. Additionally, in 506, the current round's output is only allowed to be written to a separate product output area. In 508, new products of the task node can be frozen, while new products can continue to be referenced by downstream task nodes, etc. In some examples, when the same intelligent system execution instance is dispatched, resumed, or retried, the existing task input list is used, and rereading the current upstream product is prohibited.

[0073] In some examples, it is also possible to query the organizational relationships of task nodes. For instance, the query interface returns the source of control dependency edges, organizational affiliation edges, and task input lists, allowing users to trace from a node to a specific upstream R&D task node, R&D deliverable, and source execution instance.

[0074] In some examples, a merge node can declare multiple required predecessors, and execution can only proceed if all are satisfied by default. Inputs are merged according to the output propagation range of each predecessor. Rework is not achieved by rolling back the state of old nodes, but by creating a new round of development task nodes and making its execution dependencies point to the subsequent node that triggered the rework or the currently valid upstream node. The currently valid branch is determined based on the actual explicit dependency anchor point, not by guessing based on the same iteration number or the reachability of the parent node.

[0075] In some examples, for nodes progressing normally, the node can depend on the current design node and receive all or all necessary artifacts from the design node. In other examples, for nodes requiring rework, the new design node can depend on the failed verification node; the old design remains unchanged, and the new branch becomes the current fact by explicitly depending on the anchor point.

[0076] In some examples, the input list can remain immutable. For instance, the task input list is an audited copy at the execution instance level of the intelligent system, decoupled from the actual task payload. Subsequent soft deletion of upstream (R&D) artifacts, rerunning of upstream R&D task nodes, summary updates, or migration of the execution instance to another execution environment do not change the input list of the existing execution instance. In some examples, the list can be reused for continuation, retries, and reassignments of the same execution instance. In some examples, a new version of the list can be generated based on the current situation when creating a new execution instance. In some examples, if a historical execution instance never captured its input list, the query results should be explicitly marked as uncaptured, and historical inputs should not be recreated using the current upstream content. In some examples, if the input list has been captured but there are no upstream items, a captured marker and an empty inherited input set can be returned.

[0077] Considering path, security, and compatibility, in some examples, all `mount_name` and `relative_path` values ​​may undergo character set, length, reserved name, and path traversal validation. In some examples, input files are written to a read-only region, which the intelligent system executor must not overwrite. In some examples, the output region and input region use different root directories.

[0078] Additionally, in some examples, if the legacy execution process does not recognize optional input feedback fields, these fields can be ignored and execution can proceed normally without causing the intelligent system execution instance to fail. In some examples, the task input list for the same intelligent system execution instance is only allowed to be written once; concurrent dispatch uses execution instance row locks, unique constraints, or compare-and-swap mechanisms to prevent the generation of two versions. In some examples, execution during the planning phase relies on global replacement operations sharing development task node row locks with task dispatch; for example, whoever submits first must have the latter re-check within the lock.

[0079] In some examples, upstream artifacts can be text, structured JSON, code patches, test reports, screenshot indexes, or object storage references. In some examples, task input lists can be inline content or store content addresses and hashes, as long as the version used in the initial dispatch can be deterministically reconstructed. In some examples, the conditions for fulfilling execution dependencies can be expanded from the completion facts of predecessors to verification conclusions, specified gates, or specified development artifact versions, but these must be explicitly written into the dependency text and cannot be implied from the development process container or parent node.

[0080] In some examples, this paper does not require a manual, suggestion, or auto_dispatch strategy for the development process container; tasks can be triggered by manual buttons, external APIs, or any task scheduler. It also does not require knowledge to be bound to a specific task type execution profile. Implementation is possible as long as explicit execution dependencies, independent artifact delivery configurations, and an immutable list of execution instance-level inputs exist.

[0081] In summary, one or more examples of methods 300, 400, or 500 address multiple technical problems in this way. For instance, one or more examples of methods 300, 400, or 500 resolve issues where parent node relationships or stage order assume all relationships, such as data references unexpectedly blocking execution, organizational affiliation being misinterpreted as a precondition, and complex branches not being accurately expressed. One or more examples of methods 300, 400, or 500 decompose execution dependencies, task processing result (or artifact) transitivity, and node organizational relationships into mutually independent (or orthogonal) associations.

[0082] Furthermore, one or more examples of methods 300, 400, or 500 address the issue of dependencies only expressing the order of completion. For example, downstream task nodes may require additional configuration data, leading to the risk of forgetting to pass or duplicate mounting. One or more examples of methods 300, 400, or 500 explicitly configure the scope of artifact delivery for each dependency that must be executed, and provide reasonable default values.

[0083] Additionally, one or more examples of methods 300, 400, or 500 address the issue of needing to reread upstream task nodes for each task dispatch. For instance, if the retry input for the same intelligent system execution instance changes with the upstream task node, it cannot answer the question "which version of the data was it based on?". One or more examples of methods 300, 400, or 500 freeze the input list when the intelligent system execution instance is first dispatched, and this input list is always reused in subsequent redispatches of the same execution instance.

[0084] On the other hand, one or more examples of methods 300, 400, or 500 also address the issue of inputs from upstream task nodes sharing the same directory as the current round's output. For example, input files can easily be mistaken for current round outputs, leading to incorrect access control or overwriting. One or more examples of methods 300, 400, or 500 physically separate the read-only control / inputs area from the control / artifacts area, thus avoiding this problem.

[0085] Furthermore, one or more examples of methods 300, 400, or 500 address the issue of silent truncation of overloaded content, such as inconsistent hashes with the actual complete content, leading to unverifiable audit results. Meanwhile, one or more examples of methods 300, 400, or 500 preserve the complete content hash and source metadata, and explicitly omit inline content with a sentinel without blocking dispatch.

[0086] By addressing the aforementioned issues, the orthogonal correlation features of the three relationships in one or more examples of methods 300, 400, or 500 avoid mistaking data references for execution prerequisites or related processes for sequential dependencies, and support branching, merging, and non-blocking references. Furthermore, the execution dependency features carrying the product propagation scope in one or more examples of methods 300, 400, or 500, once the prerequisite relationship is established, upstream data can be deterministically obtained, and the propagation scope can be closed or narrowed as needed.

[0087] Additionally, the explicit artifact reference priority and deduplication techniques in one or more examples of methods 300, 400, or 500 support custom mount names and avoid duplicate injection of homologous artifacts and wasted context windows. The first-freeze task input list technique in one or more examples of methods 300, 400, or 500 ensures that subsequent upstream changes do not alter the inputs of historical execution instances, and also enables retrying and accurately answers the question of "what was the task based on at the time?"

[0088] Furthermore, the full-content hashing and over-limit sentinel-related techniques in one or more examples of methods 300, 400, or 500 retain content integrity proofs while controlling storage volume, preventing false audits caused by truncated hashes. Additionally, the techniques related to separating the read-only input area from the product output area in one or more examples of methods 300, 400, or 500 prevent upstream inputs from impersonating current-round products or being overwritten by intelligent system executors, thereby improving access control accuracy. Furthermore, the execution entry re-checking and lock replacement-related techniques in one or more examples of methods 300, 400, or 500 avoid the use of incorrect predecessors or incorrect inputs due to dependency changes and dispatch race conditions.

[0089] As can be seen, one or more examples of methods 300, 400, or 500 expand the task lineage from a single tree relationship to an auditable graph composed of "control edges, data edges, attribution edges, and actual consumption snapshots," while simultaneously grounding the abstract relationships into real input evidence for each specific execution through an immutable task input list. Therefore, one or more examples of methods 300, 400, or 500 construct a multi-dimensional task lineage and immutable context backflow mechanism, ensuring that execution access control, data transfer, and organizational attribution are non-substitutable. Any downstream task can deterministically obtain the required upstream output, and even after changes to the upstream, the actual content used during its initial execution can still be audited, achieving significant technical effects.

[0090] Figure 6 A block diagram of an electronic device 600 for processing tasks, according to some examples herein, is shown. Figure 6 As shown, device 600 includes a determining module 610 configured to determine the association relationships of task nodes, including at least one of a first relationship or a second relationship. The association relationship indicates association information between the task node and other task nodes; the first relationship indicates first information within the association relationship; the second relationship indicates second information within the association relationship; and the first and second information are independent of each other. Device 600 also includes a processing module 620 configured to process tasks of the task nodes based on at least one of the first or second relationships, wherein tasks are executed on the task nodes. It can be understood that, in this way, one or more embodiments of device 600 can achieve at least one of the aforementioned advantages.

[0091] In summary, one or more examples in this paper provide a technical mechanism capable of expressing control dependencies, data dependencies, and node organizational relationships separately, and recording the actual content consumed by tasks. Furthermore, one or more examples in this paper model when execution is allowed, which upstream artifacts are read during execution, and which process or historical branch a node belongs to as orthogonal or independent relationships. The artifacts actually consumed when a downstream task is first dispatched are frozen as an immutable input list with source and content compression (e.g., content hash values). This ensures that the lineage of R&D task nodes and their intelligent system execution instances simultaneously expresses execution constraints, data transfer, and historical facts without mutual misinterpretation.

[0092] One or more examples in this paper also construct a multidimensional task lineage and immutable context backflow mechanism, which makes execution access, data transfer, and organizational affiliation non-substitutable, and ensures that any downstream task can deterministically obtain the required upstream output, and can still audit the content actually used when it was first executed after upstream changes.

[0093] Furthermore, one or more examples in this paper provide mechanisms for three orthogonal relationships: execution dependencies, artifact input references, and organization / audit attribution. Additionally, one or more examples in this paper provide schemes for required execution dependencies to carry three artifact propagation scopes: all, required, or none, with the default propagation not altering the execution gate. One or more examples in this paper also provide mechanisms for explicit artifact references to provide non-blocking input when there are no execution dependencies, and to mount them with custom names.

[0094] Furthermore, one or more examples in this paper provide a mechanism to freeze the input list with source and full content hashes when an intelligent system executes an instance for the first time, without recalculating it when the same instance is reassigned. Additionally, one or more examples in this paper provide a solution for exceeding content limits by using an over-limit sentinel with null content, while retaining the full hash, without truncating or blocking the actual input distribution. Moreover, one or more examples in this paper also provide a method to separate the read-only input area from the current round's output area, preventing input from participating in the current round's product gatekeeping. On another front, one or more examples in this paper extend the task organization relationship from a single tree structure to an auditable graph composed of control edges, data edges, ownership edges, and actual consumption snapshots, while using an immutable task input list to ground the abstract relationship into real input evidence for each specific execution.

[0095] As can be seen, through the various methods described above, one or more examples in this paper solve multiple technical problems. For example, one or more examples in this paper address the issue of parent node relationships or stage order bearing all relationships. For instance, data references may unexpectedly block execution, organizational affiliation may be misinterpreted as a precondition, and complex branches may not be accurately expressed. One or more examples in this paper decompose execution dependencies, task processing result (or artifact) transit relationships, and node organizational relationships into mutually independent (or orthogonal) association relationships.

[0096] Furthermore, one or more examples in this paper address the issue of dependencies only expressing the order of completion. For instance, downstream task nodes may require additional configuration data, leading to the risk of forgetting to pass artifacts or duplicate mounting. One or more examples in this paper explicitly configure the artifact propagation scope for each required dependency and provide reasonable default values.

[0097] Furthermore, one or more examples in this paper address the issue of needing to reread upstream task nodes for each task dispatch. For instance, if the retry input for the same intelligent system execution instance changes with the upstream task node, it cannot answer the question "which version of the data was it based on?". One or more examples in this paper freeze the input list when the intelligent system execution instance is first dispatched, and this input list is always reused for subsequent redispatches of the same execution instance.

[0098] On the other hand, one or more examples in this paper also address the issue of inputs from upstream task nodes sharing the same directory as the current round's output. For example, input files can easily be mistaken for current round outputs, leading to incorrect access control or overwriting. One or more examples in this paper physically separate the read-only control inputs area from the control artifacts area, thereby avoiding this problem.

[0099] Furthermore, one or more examples in this paper address the issue of silent truncation of overloaded content, such as inconsistent hashes with the actual complete content, leading to unverifiable audit results. One or more examples in this paper, however, preserve the complete content hash and source metadata, and use explicit sentinels to omit inline content without blocking dispatch.

[0100] By addressing the aforementioned issues, the orthogonal correlation features of the three relationships in one or more examples in this paper avoid mistaking data references for execution prerequisites or related processes for sequential dependencies, and support branching, merging, and non-blocking references. Furthermore, the execution dependency features carrying the product propagation scope in one or more examples in this paper, once the prerequisite relationship is established, upstream data can be deterministically obtained, and the propagation scope can be closed or narrowed as needed.

[0101] Furthermore, the explicit artifact reference priority and deduplication techniques in one or more examples in this paper support custom mount names and avoid duplicate injection of artifacts from the same source, thus preventing wasted context windows. The initial freeze on task input list techniques in one or more examples in this paper ensure that subsequent changes upstream do not alter the input of historical execution instances, and also enable retrying and accurately answer the question of "what was the task based on at the time" for the execution.

[0102] Furthermore, the full content hashing and over-limit sentinel-related techniques in one or more examples of this paper control storage volume while retaining content integrity proofs, preventing false audits caused by truncated hashes. Additionally, the techniques related to separating the read-only input area and product output area in one or more examples of this paper prevent upstream inputs from impersonating current-round products or being overwritten by intelligent system executors, thereby improving access control accuracy. Furthermore, the execution entry re-checking and lock replacement techniques in one or more examples of this paper avoid dependency changes and dispatch race conditions that lead to the use of incorrect predecessors or incorrect inputs.

[0103] Therefore, one or more examples in this paper extend the task lineage from a single tree-like relationship to an auditable graph composed of control edges, data edges, attribution edges, and actual consumption snapshots. Simultaneously, an immutable task input list translates the abstract relationships into concrete input evidence for each specific execution. Thus, one or more examples in this paper construct a multi-dimensional task lineage and immutable context backflow mechanism, ensuring that execution access control, data transfer, and organizational attribution are non-substitutable. Any downstream task can deterministically obtain the required upstream output, and even after upstream changes, the actual content used during its initial execution can still be audited, achieving significant technical results.

[0104] Figure 7 A block diagram of a device 700 capable of implementing several examples of this paper is shown. For example... Figure 7 As shown, device 700 includes a central processing unit (CPU) and / or a graphics processing unit (GPU) 701, which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) 702 or loaded from storage unit 708 into random access memory (RAM) 703. Various programs and data required for the operation of device 700 can also be stored in RAM 703. The CPU / GPU 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704. Although not shown in... Figure 7 As shown, device 700 may also include a coprocessor.

[0105] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0106] The various methods or processes described above can be executed by CPU / GPU 701. For example, in some examples, the methods can be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 708. In some examples, part or all of the computer program can be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by CPU / GPU 701, one or more steps or actions in the methods or processes described above can be performed.

[0107] In some examples, the methods and processes described above can be implemented as a computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing the various aspects of this document.

[0108] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0109] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network, to an external computer or external storage device. The network may include copper cables, fiber optic cables, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0110] The computer program instructions used to perform the operations described herein can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​and conventional procedural programming languages. The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider). In some examples, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can be customized by utilizing state information from the computer-readable program instructions to execute the computer-readable program instructions, thereby implementing various aspects of this document.

[0111] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0112] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

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

[0114] The examples described above are exemplary and not exhaustive, nor are they limited to the disclosed examples. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described examples. The terminology used herein is chosen to best explain the principles, practical applications, or technical improvements to technology in the market, or to enable others skilled in the art to understand the examples disclosed herein.

Claims

1. A method for processing a task, comprising: Determining the association relationship of a task node includes at least one of a first relationship or a second relationship, wherein the association relationship indicates the association information between the task node and other task nodes, the first relationship indicates a first piece of information in the association relationship, the second relationship indicates a second piece of information in the association relationship, and the first and second pieces of information are independent of each other; as well as The task of the task node is processed based on at least one of the first relationship or the second relationship, wherein the task is executed on the task node.

2. The method of claim 1, wherein processing the task of the task node based on at least one of the first relationship or the second relationship includes: In response to the first relationship between the task node and the upstream task node, the task node is prevented from processing its own task, wherein the first relationship indicates that the task node needs to wait for the upstream task node to complete all its tasks.

3. The method of claim 1, wherein processing the task of the task node based on at least one of the first relationship or the second relationship further comprises: In response to the upstream task nodes having completed all their tasks, at least a portion of the results of the upstream task nodes having completed all their tasks are obtained based on the transitive attribute in the first relationship, wherein the transitive attribute indicates the task node's dependency information on the at least a portion of the results, and the first relationship indicates that the task node needs to wait for the upstream task nodes to complete all their tasks. Based on at least a portion of the results of the upstream task nodes completing all their tasks, the tasks of the task nodes are processed.

4. The method of claim 1, wherein processing the task of the task node based on at least one of the first relationship or the second relationship includes: In response to the association relationship between the task node and the upstream task node being the second relationship, the task node's task is processed, wherein the second relationship indicates that the task node does not need to wait for the upstream task node to complete all its tasks.

5. The method of claim 4, wherein in response to the association relationship between the task node and the upstream task node being the second relationship, processing the task of the task node includes: Based on the input requirements of the task node, the result of the upstream task node at least partially completing the task is obtained, wherein the input requirements indicate the identification and processing result information required to process the task of the task node, wherein the identification and processing result information is the identification and processing result information of the upstream task node; The task of the task node is processed based on the result of the upstream task node at least partially completing the task of the upstream task node.

6. The method of claim 1, wherein processing the task of the task node includes: Determine the input of the task node; Based on the input of the task node, determine the compression information of the input of the task node; as well as The compressed information is used as the input list for the task node.

7. The method of claim 6, wherein determining the input to the task node comprises: Deduplicate the results of upstream task nodes; The input of the task node is determined based on the deduplicated results of the upstream task node and the task node's own input.

8. The method of claim 6, wherein the task of processing the task node further comprises: It is determined that the input list exceeds a first threshold; In response to the input list exceeding a first threshold, the input list is retained, and the determination of new compressed information based on the truncated content of the input from the task node is prohibited.

9. The method of claim 6, wherein the task of processing the task node further comprises: Store the input list of the task node in a read-only area; Send the task and input of the task node to the intelligent system; Receive the processing results of the task node from the intelligent system; as well as The intelligent system stores the processing results of the task node's task in the output area.

10. The method of claim 9, wherein the task of processing the task node further comprises: Obtain the processing result of the intelligent system on the task, wherein the processing result includes at least one of the following: result identifier, task node identifier, result type, path, result content, result version, and input source; as well as Delete the processing result of the intelligent system for the task.

11. The method of claim 9, wherein the task of processing the task node further comprises: It is determined that the execution instance of the intelligent system has a corresponding input list; In response to the existence of a corresponding input list for the execution instance of the intelligent system, the input list is reused.

12. The method according to claim 1, wherein determining the association relationship of task nodes includes a first relationship and a second relationship, comprising: Determining the association relationships of task nodes includes the first relationship, the second relationship, and the third relationship, wherein the first relationship, the second relationship, and the third relationship respectively indicate the non-dependent information in the association relationships of the task nodes, and the third relationship indicates the attribution information between the task nodes in the process or history relationship.

13. An electronic device comprising: A determination module is configured to determine the association relationship of a task node, including at least one of a first relationship or a second relationship, wherein the first relationship and the second relationship respectively indicate mutually independent information in the association relationship of the task node; A processing module, configured to process the task of the task node based on at least one of the first relationship or the second relationship.

14. An electronic device, comprising: processor; as well as A memory coupled to the processor, the memory having instructions stored therein, which, when executed by the processor, cause the electronic device to perform the method according to any one of claims 1 to 12.

15. A computer program product comprising computer-executable instructions, wherein the computer-executable instructions are executed by a processor to implement the method according to any one of claims 1 to 12.

Images