Two-dimensional task arrangement method and system for context physical isolation of large language model

Abstract

This invention discloses a two-dimensional task orchestration method and system for large language models with physical isolation of context. The method includes: determining whether a plan node is in an active state based on its dependency list and its parent node in a two-dimensional plan tree; if the plan node is active, constructing an input context corresponding to the plan node based on its dependency list and its parent node in the two-dimensional plan tree; if the plan node fails to execute, identifying the plan node as a failed node and marking the state of its downstream dependent nodes as failed based on the failed node's dependency list; and recursively checking the parent node of the failed node upwards according to the two-dimensional plan tree and adjusting the state of the parent node based on the recursive check results. This orchestration method significantly improves the task orchestration quality for large language model applications by deleting detailed execution history of subtasks and retaining key information through the physical isolation mechanism of attention threads.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a two-dimensional task orchestration method and system with context-physical isolation for large language models. Background Technology

[0002] With the rapid development of artificial intelligence technology, Large Language Models (LLMs) have been applied in numerous scenarios. Text tokens, as the smallest units of text reading and writing in LLMs, play a crucial role in model analysis. For logical reasoning analysis, it is necessary to retain historical output context tokens during task orchestration. However, if all historical outputs are retained in the context, the number of tokens grows linearly, and the LLM's attention is distracted by irrelevant information, ultimately leading to a decline in the quality of the analytical reasoning output. Conversely, if historical output information is compressed or discarded to control the context size, it is highly likely that key information needed for subsequent tasks will be lost, leading to the failure of analytical reasoning tasks or a decrease in the quality of analytical reasoning output.

[0003] In existing one-dimensional task orchestration technologies, all task nodes are at the same level, lacking a hierarchical scope isolation mechanism. As task complexity increases, the one-dimensional task orchestration structure leads to the following technical problems: Problem 1: Context Pollution. The first type of solution is linear sequence orchestration. Frameworks like LangChain use a chain structure to execute multiple steps in sequence. In a one-dimensional structure, all historical execution results are piled up in a single context space, making it impossible for subsequent steps to distinguish which information is relevant and which is irrelevant. As the number of steps increases, the proportion of irrelevant information grows linearly, causing the attention of large language models to be distracted by irrelevant information, reducing decision quality, and ultimately leading to task drift. From a computer system perspective, this accumulation of all historical data results in severe resource waste: the number of tokens that need to be processed in each step grows linearly, reaching tens of thousands of tokens in a 30-step task, causing significant consumption of processor time, memory usage, and network bandwidth. Furthermore, most of the computation is used to process irrelevant information, resulting in low computational efficiency. Problem 2: Insufficient ability to express dependencies. The second type of solution is Directed Acyclic Graph (DAG) orchestration. The LangGraph framework uses a StateGraph to manage task flows, and workflow engines such as Perfect and Airflow also adopt DAG structures. However, DAGs are flat structures, with all nodes at the same level, making it impossible to express dependencies within a local scope. When subtasks A1 and A2 belong to parent task A, and subtasks B1 and B2 belong to parent task B, the one-dimensional structure cannot isolate the internal dependencies between A and B, leading to cross-scope dependency conflicts. This structural defect makes it difficult to accurately express the dependencies of complex tasks, further exacerbating task drift. Problem 3: Lack of hierarchical organization capabilities. The third type of solution is tree-like hierarchical orchestration. Hierarchical Task Networks (HTNs) decompose tasks into subtask trees, supporting hierarchical structures of arbitrary depth. However, HTNs only support parent-child relationships (vertical dependencies) and do not support dependencies between tasks at the same level (horizontal dependencies). When subtask A can only be executed after subtask B is completed, HTN cannot directly express this constraint. It can only handle this by introducing additional intermediate nodes or elevating the dependency to the parent node level, leading to structural complexity and an inability to effectively isolate scope. Problem 4: Unreliable planning. The fourth type of solution involves autonomous planning by the large language model. Frameworks such as ReAct and AutoGPT allow the large language model to decide which task to execute next. The fundamental problem with this solution is that the large language model is a probabilistic system, and its planning decisions are unreliable and unreproducible. The same task may produce completely different decomposition schemes in different executions, and the large language model is prone to forgetting long-term goals, deviating from the original task in multiple execution steps, with a task drift rate of over 50%.

[0004] The lack of a clear context passing mechanism is a key factor exacerbating task drift. In multi-step task execution, subsequent steps need to access the execution results of preceding steps, but existing solutions cannot precisely control the scope of context passing, leading to information overload or information loss: Global state passing: LangGraph's state graph uses this mechanism, where all steps share a global state object. The problem with this mechanism is the unclear context boundaries; any step can access any part of the global state, leading to irrelevant information contamination. In multi-step tasks, subsequent steps can access the outputs of all preceding steps, but only a few of these outputs may be truly relevant, with the rest constituting noise, making it difficult for large language models to focus on key information, thus increasing the task drift rate. Explicit parameter passing: This mechanism requires manual configuration of parameter binding relationships, resulting in high maintenance costs when the task structure is complex. A more serious problem is the inability to automatically handle context inheritance in hierarchical structures—when a subtask needs to access the context of its parent task, all relevant parameters must be explicitly passed, resulting in a lengthy and error-prone parameter passing chain. Incorrect parameter configuration directly leads to subtasks lacking necessary information, triggering task drift. The lack of a failure propagation mechanism makes error handling unreliable. In multi-step task execution, if a step fails, subsequent steps that depend on it should terminate immediately to avoid continuing execution based on an erroneous premise. Existing solutions primarily rely on exception mechanisms or explicit error checking for failure handling. However, the exception propagation path is inconsistent with task dependencies—exceptions propagate upwards along the call stack, while task dependencies may include lateral dependencies. This causes some tasks that should terminate to continue executing, wasting computational resources and potentially producing erroneous results, further exacerbating task drift. The lack of dynamic planning adjustment capabilities limits the adaptability of complex tasks. During task execution, it may be necessary to dynamically add new subtasks based on intermediate results. Existing solutions typically employ static planning, determining the complete task structure before execution and not supporting runtime expansion. Some solutions support conditional branching or loops, but the branch paths of these control structures must be predefined during orchestration, making it impossible to dynamically generate new task nodes at runtime. This rigid structure cannot adapt to the uncertainties in complex task execution; when the actual situation deviates from the preset path, it can only terminate the task or produce unexpected results.

[0005] Based on the above analysis, the fundamental flaw of existing task orchestration schemes lies in the architectural limitations of one-dimensional structures. The lack of hierarchical scope isolation mechanisms in one-dimensional structures leads to the following technical problems: (1) Task drift problem: Context pollution prevents large language models from focusing on key information, severely limiting the ability of intelligent agent systems to handle complex tasks. (2) Insufficient structural expressive power: Linear sequences cannot express parallelism and dependencies, DAGs lack hierarchical organization, tree structures do not support horizontal dependencies, and no scheme simultaneously supports arbitrary depth levels and peer dependencies. (3) Unclear context passing mechanism: Global state leads to information overload, explicit parameter passing has high maintenance costs, and there is a lack of automatic structured context passing mechanism. (4) Lack of failure propagation mechanism: Relying on exception mechanisms or explicit error checks, failure states cannot be automatically propagated along dependencies, resulting in unreliable error handling. (5) Lack of dynamic expansion capability: Static plans cannot adapt to changes in requirements during execution, and the expressive power of conditional branches and loops is limited. The common root cause of the above problems is the lack of hierarchical dimensions in one-dimensional structures. Existing technologies attempt to alleviate the problem by adding mechanisms such as global state management and explicit parameter passing, but these are all repairs on a one-dimensional structure and cannot fundamentally solve the architectural defects.

[0006] Failure Analysis of the Two-Dimensional Structure of Traditional Workflow Engines in LLM Scenarios: Workflow engines such as Airflow's SubDAG, Temporal's Child Workflow, and Perfect's Subflow all support hierarchical task orchestration, exhibiting a two-dimensional structure of "tree hierarchy + DAG dependency." However, these engines are designed for traditional data processing tasks, where structured data (JSON objects, file paths, etc.) is passed between tasks, with a fixed data size and no accumulation. When these engines are applied to LLM agent scenarios, a fundamental adaptation problem arises: LLM tasks pass natural language context (token streams), and the execution of each subtask generates a dialogue history of thousands of tokens. The state management mechanism of traditional engines retains the execution history of all subtasks in a global state object (such as Temporal's Workflow State and LangGraph's StateGraph), meaning that even after a subtask is completed, its detailed history remains in memory. When execution switches to a sibling task, the detailed context of the preceding task cannot be physically deleted, causing the input tokens of subsequent LLM calls to contain detailed outputs of all historical tasks, resulting in a linear increase in the number of tokens. Taking Temporal as an example, after a Child Workflow completes, its execution result is returned to the parent Workflow via the WorkflowExecutionCompleted event. However, the complete execution history of the Child Workflow (including all Activity calls, signal handling, timers, etc.) is retained in Temporal's event store, allowing the parent Workflow to query the complete history of the child Workflow. This design is used for auditing and debugging in traditional scenarios, but it leads to a lack of context isolation in LLM scenarios. Although LangGraph's StateGraph supports subgraphs, all nodes share the same State object, and the execution history of the subgraph is accumulated in the State.messages field. Even with reducer functions for compression, the historical messages remain in the State object and cannot be physically deleted when switching to a sibling node. The root cause of the above problem is that the state management mechanism of traditional workflow engines is "retention-based" (all historical states are persisted to support auditing and recovery), while LLM scenarios require "selective forgetting" (the detailed history of subtasks should be physically deleted after completion, retaining only the output summary). This difference in requirements causes traditional two-dimensional engines to fail in LLM scenarios.

[0007] Analysis of the dimensionality limitations of existing LLM agent task orchestration schemes: Existing schemes all adopt a one-dimensional structure, where all task nodes are at the same level, organized through linear sequences or flat DAGs. The fundamental flaw of the one-dimensional structure lies in the lack of scope boundaries, leading to imprecise control over context propagation: Linear sequence schemes (LangChain's Chain): Tasks A→B→C→D are executed sequentially, and the input context of each task is the accumulation of the outputs of all preceding tasks. When task D is executed, the input context contains all the outputs of A, B, and C, even if D only depends on the result of C. This full accumulation leads to linear growth of the context; in a 30-step task, the input tokens of the last step can reach tens of thousands, most of which are irrelevant information. For LLM, the number of input tokens directly affects inference cost (billed by token) and response quality (attention is scattered by irrelevant information). Therefore, context explosion severely limits the ability of LLM agents to handle complex tasks.

[0008] Flat DAG scheme (LangGraph's StateGraph): Supports dependencies between tasks, but all tasks share a global state object. Any task can access any part of the global state, lacking a scope isolation mechanism. Although access scope can be restricted through manual configuration of parameter bindings, it is costly to maintain and prone to errors. More critically, when task A is decomposed into subtasks A1, A2, and A3, the flat DAG can only flatten them into sibling nodes, failing to express the semantics that "A1, A2, and A3 belong to the scope of A." Therefore, it cannot achieve precise context control such as "A's sibling task B can only access the output summary of A, but cannot access the detailed output of A1, A2, and A3."

[0009] The fundamental problem with one-dimensional structures is the lack of vertical dimensions, which prevents the formation of modular boundaries. In a one-dimensional structure, all task nodes are on the same plane, lacking a hierarchical scope isolation mechanism. When the task scale increases, one-dimensional structures lead to the following technical problems: (1) Context cannot be precisely controlled: Subsequent tasks can access the output of all preceding tasks and cannot distinguish which are relevant and which are irrelevant; (2) Context cannot be automatically switched: When execution switches from one task branch to another, the detailed information of the previous branch cannot be automatically cleared, resulting in the continuous accumulation of context; (3) Insufficient modularity: The detailed output of subtasks cannot be encapsulated inside the parent task, resulting in the leakage of implementation details to the outside.

[0010] Necessity of Two-Dimensional Structure: For task orchestration of LLM agents, a vertical dimension needs to be introduced to form a two-dimensional structure. The vertical dimension provides scope boundaries, and the horizontal dimension provides execution order constraints. The two-dimensional structure enables precise control of context passing: (1) Scope isolation: The detailed output of subtasks is encapsulated within the scope of the parent task, and external tasks cannot access it; (2) Automatic context switching: When execution switches from one branch to another, the context automatically switches from the cumulative output of the previous branch to the cumulative output of the current branch, without carrying the detailed information of the previous branch; (3) Composability: The two-dimensional structure supports arbitrary depth of nesting, and each layer has an independent scope boundary, so complex tasks can be recursively decomposed.

[0011] Therefore, neither of the above two schemes can simultaneously satisfy the two goals of "attention focus" and "information integrity". Existing task orchestration methods for large language models have the problem of poor orchestration quality. Summary of the Invention

[0012] This invention provides a two-dimensional task orchestration method and system with context-physical isolation for large language models, aiming to solve the problem of poor orchestration quality in existing task orchestration methods for large language models.

[0013] In a first aspect, embodiments of the present invention provide a two-dimensional task orchestration method for context-physically isolated large language models, wherein the method is applied in the plan manager of an attention scheduling kernel, the plan manager orchestrates tasks for plan nodes in the large language model, the plan nodes are combined into a two-dimensional plan tree, and the method includes: Based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree, it is determined whether the plan node is in an active state; the state of the plan node is managed by the plan manager and is switched between pending activation, active, completed, and failed. If the plan node is in an active state, construct the input context corresponding to the plan node based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree; If the planned node fails to execute, the planned node is determined to be a failed node, and the status of the downstream dependent nodes of the failed node is marked as failed according to the dependency table of the failed node; The parent node of the failed node is recursively checked upwards according to the two-dimensional plan tree, and the state of the parent node is adjusted according to the recursive check results.

[0014] Secondly, embodiments of the present invention also provide a context-physically isolated two-dimensional task orchestration system for a large language model, wherein the system is configured in the plan manager of the attention scheduling kernel, the plan manager orchestrates tasks for plan nodes in the large language model, the plan nodes are in the form of a two-dimensional plan tree, and the system is used to execute the context-physically isolated two-dimensional task orchestration method for a large language model as described in the first aspect above, and the system is configured with the following units: The judgment unit is used to determine whether the plan node is in an active state based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree; the state of the plan node is managed by the plan manager and is switched between pending activation, active, completed and failed. A construction unit is configured to, if the plan node is in an active state, construct an input context corresponding to the plan node based on the plan node's dependency list and the plan node's parent node in the two-dimensional plan tree; A status marking unit is used to determine that the planning node is a failed node and mark the status of the downstream dependent nodes of the failed node as failed according to the dependency table of the failed node if the planning node fails to execute. The recursive checking unit is used to recursively check the parent node of the failed node upwards according to the two-dimensional plan tree, and adjust the state of the parent node according to the recursive check result.

[0015] Thirdly, embodiments of this application also disclose a context-physically isolated two-dimensional task orchestration system for large language models, comprising a plan manager, an application layer, and a scheduling kernel layer; the plan manager is located between the application layer and the scheduling kernel layer, and the plan manager is communicatively connected to both the application layer and the scheduling kernel layer; the plan manager is used to execute the scheduling method for the large language model computing power cluster as described in the first aspect.

[0016] Fourthly, embodiments of this application also disclose a computer device, wherein the computer device includes a memory and a processor, the memory stores a computer program, and the processor executes the computer program to implement the two-dimensional task orchestration method with contextual physical isolation of a large language model as described in the first aspect.

[0017] Fifthly, embodiments of this application also disclose a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, the computer program including program instructions, and the program instructions, when executed by a processor, can implement the two-dimensional task orchestration method with context-physical isolation of a large language model as described in the first aspect.

[0018] This invention provides a two-dimensional task orchestration method and system with physical isolation of context for large language models. The method includes: determining whether a plan node is in an active state based on its dependency list and its parent node in a two-dimensional plan tree; if the plan node is active, constructing an input context corresponding to the plan node based on its dependency list and its parent node in the two-dimensional plan tree; if the plan node fails to execute, identifying the plan node as a failed node and marking the state of its downstream dependent nodes as failed based on the failed node's dependency list; and recursively checking the parent node of the failed node upwards according to the two-dimensional plan tree and adjusting the state of the parent node based on the recursive check results. This two-dimensional task orchestration method with physical isolation of context removes detailed execution history of subtasks through the physical isolation mechanism of attention threads to avoid attention distraction, while automatically retaining key information through the hierarchical transmission mechanism of the two-dimensional structure, achieving a balance between attention focus and information integrity, and significantly improving the task orchestration quality of large language model applications. Attached Figure Description

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

[0020] Figure 1 A flowchart illustrating the method for a two-dimensional task orchestration method with contextual physical isolation for a large language model provided in this embodiment of the invention; Figure 2 A schematic diagram illustrating the application of the two-dimensional task orchestration method for contextual physical isolation of a large language model provided in an embodiment of the present invention; Figure 3 This is another application diagram of the two-dimensional task orchestration method for contextual physical isolation of a large language model provided in the embodiments of the present invention; Figure 4 This is another application diagram of the two-dimensional task orchestration method with contextual physical isolation of a large language model provided in the embodiments of the present invention; Figure 5 This is a schematic diagram illustrating another application of the two-dimensional task orchestration method with contextual physical isolation for large language models provided in this embodiment of the invention. Figure 6 This is a schematic diagram illustrating a subsequent application of the two-dimensional task orchestration method with contextual physical isolation for a large language model provided in this embodiment of the invention. Figure 7 This is a schematic diagram illustrating another application of the two-dimensional task orchestration method for contextual physical isolation of a large language model provided in this embodiment of the invention. Figure 8 A schematic block diagram of a two-dimensional task orchestration system with context-physical isolation for a large language model provided in an embodiment of the present invention; Figure 9 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

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

[0022] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0023] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0024] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0025] This invention provides a context-physically isolated two-dimensional task orchestration method for a large language model. This method is applied to the plan manager of the attention scheduling kernel. The plan manager executes a stored software program to implement the aforementioned context-physically isolated two-dimensional task orchestration method for a large language model. The plan manager orchestrates tasks for plan nodes in the large language model, and the plan nodes are combined as follows: Figure 2The illustrated two-dimensional plan tree demonstrates how task orchestration methods decompose high-level tasks into the execution order of low-level attention threads, thus addressing the issues of context explosion and task drift in large language models performing multi-step tasks. The attention scheduling kernel provides interfaces for creating, scheduling, switching, and terminating attention threads, while the plan manager uses these interfaces for task orchestration and attention thread execution control. The technical problem addressed by this invention is the dilemma faced by existing solutions when LLM agents perform multi-step tasks: full retention of history leads to context explosion, while compressing and discarding history may result in the loss of critical information. This invention achieves selective forgetting by introducing a vertical hierarchical dimension and a thread-isolation-based physical implementation mechanism: detailed history of subtasks is physically deleted to maintain attention focus, while critical information is automatically retained through hierarchical transmission to ensure information integrity. This method fundamentally solves the context explosion and task drift problems in LLM agents performing complex tasks, enabling agent systems to reliably complete complex tasks exceeding 30 steps while significantly reducing the token cost of LLM inference.

[0026] like Figure 1 As shown, the method includes steps S110 to S140.

[0027] S110. Based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree, determine whether the plan node is in an active state.

[0028] The two-dimensional plan tree is stored in computer memory and consists of multiple plan nodes. Each plan node contains a node identifier, a list of child nodes, a dependency list, a large language model hint template identifier, an execution stage list, and a parameter dictionary. The node identifier is the unique identifier corresponding to each plan node. The child node list records the node identifiers of the child nodes contained in the next level of the plan node. The dependency list records the node identifiers of the nodes that the plan node depends on (i.e., dependent node identifiers). The large language model hint template identifier is the identifier of the hint template corresponding to the current plan node, and the hint template contains the corresponding hint words. The execution stage list records the current execution stage of the plan node, and the parameter dictionary records the parameter information required for the plan node to perform the logical reasoning task. The availability of a plan node can be determined based on its dependency list and its parent node in the two-dimensional plan tree. The status of the plan nodes is managed by the plan manager and transitions between pending activation, active, completed, and failed.

[0029] For example, a planning node contains the following fields: nid (node ​​identifier): a string that uniquely identifies the planning node within its parent node's scope; children (list of child nodes): a list of planning node objects representing all child nodes of this node, used to build a tree hierarchy; depends_on (list of dependencies): a string list containing the identifiers of the sibling nodes that this node depends on, used to build a directed acyclic graph in the horizontal direction; template (large language model prompt template identifier): a string pointing to the prompt template file of the large language model; phases (list of execution phases): a string list defining the multi-phase execution sequence of this node; params (parameter dictionary): a collection of key-value pairs storing the parameters passed to the large language model; priority: an integer used for priority sorting during scheduling.

[0030] A two-dimensional plan tree forms a hierarchical tree of arbitrary depth in the vertical direction through parent-child relationships between nodes, supporting arbitrary nesting. In the horizontal direction, it forms a directed acyclic graph among sibling nodes at the same level through dependencies. The vertical direction provides scope boundaries, while the horizontal direction provides execution order constraints. For example... Figure 2 As shown, solid arrows represent tree-like hierarchical relationships (the hierarchical relationship between parent and child nodes), while dashed arrows represent directed acyclic graphs (dependencies between sibling nodes). For example, A1, A2, and A3 are all child nodes of the "Develop New Feature (Root)" node, meaning A1, A2, and A3 are sibling nodes. Similarly, B1, B2, and B3 are all child nodes of node A3, meaning B1, B2, and B3 are sibling nodes. A2 depends on A1, A3 depends on A2, B2 depends on B1, and B3 depends on both B1 and B2.

[0031] The scope-isolated context passing mechanism automatically constructs the input context when the planned node is activated. The input context consists of two parts: the first part is the cumulative output of the planned node's parent node, achieving vertical context inheritance; the second part is the output of all sibling nodes that the planned node depends on, achieving horizontal context injection. This mechanism ensures the context passing path aligns with the task structure, with parent-child relationships corresponding to inheritance and dependencies corresponding to injection. The dependency resolution mechanism independently resolves dependencies between sibling nodes within the scope of the planned node's parent node; node identifiers in the dependency list are only searched within the child nodes of the same parent node, without crossing the parent node's scope boundary. When all dependent nodes of a node are completed, the node is automatically marked as active. This mechanism avoids global dependency conflicts through scope isolation and eliminates manual scheduling through automatic activation checks; the constructed input context is passed as part of the prompt words to the large language model for inference.

[0032] In a specific embodiment, step S110 includes the following sub-steps: obtaining the scope of the parent node corresponding to the plan node in the two-dimensional plan tree; constructing a first path within the scope of the parent node according to the dependency node identifiers contained in the dependency relationship list of the plan node; checking whether the status of the dependency nodes corresponding to the first path is all completed; if the status of the dependency nodes corresponding to the first path is all completed, then determining that the plan node is in an active state.

[0033] First, an activation check is performed on the plan node to determine if it is in an active state. This is done by first obtaining the scope of the parent node corresponding to the plan node in the two-dimensional plan tree. The parent node scope is the range of all child nodes contained in the plan node's parent node (ensuring dependency resolution only occurs between sibling nodes). Next, based on the dependency node identifiers in the plan node's dependency list, a first path is constructed within the parent node's scope. The dependency node identifiers that the plan node depends on are placed before the plan node's node identifier. It is then determined whether the dependency node identifier also contains dependent nodes within the parent node's scope. If it does, the node identifier of the dependent node is placed before the plan node's dependent node identifier, and so on, ultimately constructing the first path within the parent node's scope.

[0034] Obtain the status of all nodes in the first path and determine if they are all completed. At this stage, the status determination does not involve the planned nodes in the first path, but only the status of the dependent nodes corresponding to the planned nodes in the first path. If the status of all dependent nodes corresponding to the first path is completed, the planned node corresponding to the first path is determined to be in an active state; if the status of any node in the first path is not completed, the planned node corresponding to the first path is determined to be in an inactive state.

[0035] like Figure 3 As shown, Figure 3 This is a flowchart of the dependency resolution mechanism of the present invention, mainly illustrating the dependency satisfaction check process within the scope of the parent node. That is, it determines whether the plan node is in an active state. If the dependency is satisfied, it is determined to be active; otherwise, it is determined not to be active. Dependency resolution is performed only within the scope of the parent node. All dependent nodes in the first path must be in a completed state for the plan node to be determined to be in an active state.

[0036] like Figure 3 As shown, the dependency resolution mechanism performs dependency satisfaction checks before a node is activated; the core of this mechanism lies in scope isolation—dependencies are resolved only within the child nodes of the same parent node.

[0037] The algorithm for dependency satisfaction checking is as follows: Algorithm 1: Dependency Satisfaction Check; Input: scope prefix, plan node; Output: boolean value, indicating whether the dependency is satisfied. The specific steps include: (1) Traverse each dependency node identifier dep in the depends_on list of node; (2) For each dep, construct the complete path of the dependency node: path = prefix + "." + dep; (3) Query the state index to get the current state of the node corresponding to path; (4) If the state is not equal to "COMPLETED", return false; (5) If the state of all dependency nodes is "COMPLETED", return true.

[0038] The parameter prefix is ​​the parent node path (or plan root identifier) ​​of the current node. For the node "plan1.A3.B2", its prefix is ​​"plan1.A3". If the depends_on list of B2 is ["B1"], then check whether the status of "plan1.A3.B1" is completed. The advantages of parent node scope isolation are: (1) avoiding global dependency conflicts, different parent nodes can have child nodes with the same identifier, and their dependencies are independent of each other; (2) simplifying dependency resolution logic, the search scope of dependency nodes is limited to sibling nodes, and there is no need for global search; (3) supporting modular design, the dependency relationship of child plan nodes is encapsulated inside the parent node, which does not affect the external structure.

[0039] Automatic activation checks are triggered at the following times: (1) when the plan is loaded, the dependencies of all root nodes are checked; (2) when a node is completed, the dependencies of all its sibling nodes are checked; (3) when a node is dynamically added, the dependencies of the new node are checked. Automatic activation eliminates the need for manual scheduling, and nodes whose dependencies are satisfied immediately enter the execution queue.

[0040] S120. If the plan node is in an active state, construct an input context corresponding to the plan node based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree.

[0041] If the plan node is in an active state, its state is adjusted to active, and an input context corresponding to the plan node is constructed based on the plan node's dependency list and its parent node. The parent node of the plan node can be obtained from the two-dimensional plan tree.

[0042] In a specific embodiment, step S120 includes the following sub-steps: initializing the context fragment list of the plan node to be empty; determining whether the parent node corresponding to the plan node in the two-dimensional plan tree has accumulated execution results; if the parent node corresponding to the plan node has accumulated execution results, adding the accumulated execution results as a first context fragment to the context fragment list; obtaining the dependency resolution scope corresponding to the plan node in the two-dimensional plan tree; constructing a second path within the dependency resolution scope according to the dependency node identifier contained in the dependency relationship list of the plan node; determining whether the node corresponding to the second path has execution results; if the node corresponding to the second path has execution results, adding the execution results as a second context fragment to the context fragment list; sequentially concatenating the context fragments contained in the context fragment list to obtain a structured context as the input context.

[0043] Each plan node also has a corresponding context fragment list. The context fragment list of the plan node is initialized to empty. It is then checked whether the parent node of the plan node has accumulated execution results, which are the execution results accumulated by the parent node during the inference analysis process. If the parent node of the plan node has accumulated results, the accumulated results are added to the context fragment list as the first context fragment.

[0044] Further, obtain the dependency resolution scope corresponding to the plan node in the two-dimensional plan tree. The dependency resolution scope is the range corresponding to the parent node path (the execution path of the plan node corresponding to the parent node of the current plan node) or the plan root path (if the plan node does not contain a parent node, directly obtain the execution path of the plan node corresponding to the root directory). Construct a second path within the dependency resolution scope based on the dependency node identifiers contained in the dependency relationship list of the plan node. Specifically, if the dependency node identifier of the plan node is contained within the dependency resolution scope, it is retained; if the dependency node identifier of the plan node is not contained within the dependency resolution scope, it is deleted. Arrange and organize the retained dependency node identifiers according to the dependency relationships between plan nodes. For example, if B2 depends on B1, the node identifier corresponding to node B1 is arranged before node B2. After arrangement and organization, a second path containing multiple node identifiers can be constructed.

[0045] Determine whether each node in the second path has an execution result. If an execution result exists, add the execution result of the corresponding node in the second path as a second context fragment to the context fragment list. The added second context fragment is located after the first context fragment.

[0046] Furthermore, the context fragments contained in the context fragment list are sequentially concatenated, following the principle of context fragments of the parent node of the planning node first, and context fragments of the dependent nodes of the planning node last, to obtain a complete structured context as the input context. The structured context is passed to the underlying execution engine as the previous_output parameter when the planning node is executed, thereby realizing the flow of information across nodes.

[0047] Figure 4 This is a schematic diagram of the structured context passing mechanism of the present invention, illustrating parent node result inheritance and dependent node result injection. The input context obtained by passing the context of node B3 includes the accumulated result of vertically inherited A3, and the execution results of horizontally injected (dependency injection) B1 and B2. Vertical inheritance means that the child node automatically obtains the accumulated result of the parent node as a set of context fragments; horizontal injection means obtaining the execution results of all dependent nodes as a set; the context boundary restricts the plan node to only obtain context fragments from the parent node and dependent nodes.

[0048] The structured context passing mechanism automatically constructs the execution context when a node is activated. This mechanism is based on hybrid semantics, mapping parent-child relationships to inheritance and dependencies to injection. The specific algorithm is as follows: Structured context construction; Input: Full path of the node (path), planned node (node); Output: String representing the input context of that node.

[0049] The specific steps include: (1) Initialize the context fragment list parts to an empty list; (2) Query the parent-child relationship index to obtain the parent node path parent_path of path; (3) If parent_path exists and the cumulative output of parent_path exists in the result index, add the output to the parts list (vertical inheritance); (4) Determine the dependency resolution scope: if parent_path exists, it is parent_path, otherwise it is the plan root identifier; (5) Traverse each dependency node identifier dep in the node's depends_on list; (6) For each dep, construct the complete path of the dependency node: dep_path = scope + "." + dep; (7) If the output of dep_path exists in the result index, add the output to the parts list (horizontal injection); (8) Connect all fragments in the parts list with a newline character and return the connected string.

[0050] by Figure 2Taking the structure shown as an example, the context construction process of node B3 "integration test" is as follows: (1) Find the cumulative result of parent node A3 "code implementation", which contains the output summary of all subtasks of A3; (2) Find the results of dependent nodes B1 "implement core logic" and B2 "write unit test"; (3) Connect the three parts in order to form the execution context of B3. The key advantages of this mechanism are: (1) The context passing path is consistent with the task structure, the parent-child relationship is automatically inherited, and the dependency relationship is automatically injected, without manual configuration; (2) The context boundary is clear, and the node can only access the results of the parent node and dependent nodes, and cannot access the results of irrelevant nodes, thus avoiding information leakage; (3) It supports hierarchical accumulation. The result of the parent node already contains the cumulative output of all its child nodes, and the child node automatically obtains complete upstream information when inheriting the result of the parent node.

[0051] Specifically, the plan node includes branch nodes and leaf nodes, and each execution stage of the leaf node corresponds to one call of the underlying execution unit; the method further includes: when the underlying execution unit completes an execution and submits the execution result, the execution result is added to the cumulative execution result of the leaf node; if the index value of the stage index of the leaf node is less than the corresponding total number of stages, the next execution stage is executed.

[0052] Specifically, the plan nodes include two types: branch nodes and leaf nodes. Branch nodes contain a non-empty list of child nodes, do not directly execute tasks, and their state is determined by the aggregation of the states of their child nodes. When a branch node is activated, it triggers an activation check on all its dependent child nodes (activation check corresponds to step S110). Leaf nodes do not contain child nodes and are directly mapped to the underlying execution unit of the underlying execution engine. When a leaf node is activated, an underlying execution unit is created based on the leaf node's large language model prompt template identifier and execution stage list, or a temporary underlying execution unit is created based on the leaf node's content field. The underlying execution engine is also the scheduling kernel of the underlying execution engine. The underlying execution unit is the attention thread. The large language model prompt template corresponds to the identifier information of the prompt template file, and the execution stage list corresponds to the multi-stage execution sequence of the attention thread corresponding to the leaf node.

[0053] Each execution stage of a leaf node corresponds to a call to an underlying execution unit. Typically, a leaf node contains one or more execution stages. When an underlying execution unit completes an execution and submits the result, it adds the result to the cumulative execution result of the leaf node to which the underlying execution unit belongs. After the underlying execution unit of a leaf node completes an execution, the stage index of that leaf node is incremented by one. After updating the stage index, it is further determined whether the stage index of the leaf node is less than the total number of stages. If the index value is not less than the total number of stages, it indicates that all execution stages of the leaf node have been completed; if the index value is less than the total number of stages, it indicates that the execution stage of the leaf node has not been completed, and the next execution stage of the leaf node is then executed.

[0054] The execution of the next execution phase of a leaf node includes: constructing a parameter dictionary for the next execution phase, and merging the structured context of the leaf node with its own accumulated execution results as the prior output parameters of the leaf node; calling the phase switching interface of the underlying execution engine to switch the execution phase of the leaf node to the next phase; if the current execution phase is the final phase, terminating the execution of the underlying execution unit and marking the state of the leaf node as completed, then triggering vertical failure bubbling (recursive check in step S140) and sibling node activation check (taking the sibling nodes of the leaf node as planned nodes and executing S110 accordingly for activation check). The multi-phase execution mechanism of leaf nodes can decompose a single node into multiple consecutive execution phases, and the output of the underlying execution unit of each execution phase is automatically passed to the underlying execution unit of the next execution phase.

[0055] S130. If the planned node fails to execute, the planned node is determined to be a failed node, and the status of the downstream dependent nodes of the failed node is marked as failed according to the dependency table of the failed node.

[0056] The process involves determining whether a planned node executed successfully. If successful, the node's status is changed to "Completed." If unsuccessful, the node's status is changed to "Failed." If a planned node fails, it is designated as a failed node, and its downstream dependent nodes are retrieved from the dependency table and marked as failed. This process corresponds to lateral failure propagation.

[0057] In a specific embodiment, step S130 includes the following sub-steps: obtaining the sibling nodes of the failed node within the scope of the parent node corresponding to the two-dimensional plan tree; determining whether the dependency list of each sibling node contains the node identifier of the failed node; if the dependency list of any sibling node contains the node identifier of the failed node and the current state of the sibling node is pending activation, then determining the sibling node as a downstream dependent node; marking the state of the downstream dependent node as failed and recursively triggering the downstream dependent node to perform lateral failure propagation.

[0058] First, obtain the sibling nodes of the failed node within the scope of its parent node in the two-dimensional plan tree. Extract the dependency list of each sibling node and determine if each dependency list contains the node identifier of the failed node and if the current state of each sibling node is pending activation. If any sibling node's dependency list contains the node identifier of the failed node and its current state is pending activation, then this sibling node is determined to be a downstream dependent node of the failed node, and its state is marked as failed. Further, the downstream dependent nodes marked as failed are treated as failed nodes, and the process returns to recursively triggering the lateral failure propagation of the sibling nodes of the downstream dependent nodes. This process continues until the parent node scope of each failed node no longer contains any sibling nodes, at which point the recursive process terminates.

[0059] Figure 5 This is a schematic diagram of the failure propagation mechanism of the present invention, which includes bidirectional propagation of horizontal failure propagation and vertical bubbling check (vertical failure bubbling). Horizontal failure propagation means that the sibling nodes of the failed node are automatically determined to be in a failed state; vertical failure bubbling means that the parent node fails when all child nodes terminate and at least one child node is failed; recursive propagation means that the hierarchical structure of arbitrary depth is automatically processed.

[0060] The algorithm for lateral failure propagation is: lateral failure propagation; input: the complete path of the failed node; output: (1) none (side effect: update the state of the relevant node). The specific steps include: (1) querying the parent-child relationship index to obtain the parent node path parent_path of path; (2) if parent_path exists, obtain the list of all child nodes of the parent node; otherwise, obtain the list of all child nodes of the plan root; (3) determining the scope prefix: if parent_path exists, it is parent_path, otherwise it is the plan root identifier; (4) extracting the identifier nid of the failed node (the last level of the path) from path; (5) traversing all sibling nodes sib; (6) for each sib, construct its complete path: sib_path = scope prefix + "." + sib.nid; (7) querying the state index to obtain the current state of sib_path; (8) if the state is "PENDING" and the depends_on list of sib contains nid, then: a. update the state of sib_path to "FAILED", b. recursively call the vertical failure bubbling algorithm to process sib_path, c. recursively call the horizontal failure propagation algorithm to process sib_path.

[0061] The vertical failure bubbling algorithm is as follows: Vertical failure bubbling; Input: complete path of the node path; Output: None (side effect: update the parent node state). The specific steps include: (1) query the parent-child relationship index to get the parent node path parent_path of path; (2) if parent_path does not exist, terminate the algorithm (the root node has been reached); (3) query the node index to get the parent node object parent_node corresponding to parent_path; (4) traverse all child nodes of parent_node and get the state of each child node; (5) check whether the state of all child nodes is "COMPLETED" or "FAILED" (i.e. all terminated); (6) if not all terminated, terminate the algorithm; (7) if all terminated, check whether at least one child node is in the state of "FAILED"; (8) if at least one failed, then: a. update the state of parent_path to "FAILED"; b. recursively call the vertical failure bubbling algorithm to process parent_path; c. call the horizontal failure propagation algorithm to process parent_path.

[0062] by Figure 2Taking the structure shown as an example, if node B1 "implements core logic" fails, the failure propagation process is as follows: (1) Horizontal propagation: B2 "writes unit tests" depends on B1 and is marked as failed; B3 "integration tests" depends on B1 and is marked as failed; (2) Vertical bubbling: all child nodes of A3 "encode implementation" have terminated and at least one has failed, so A3 is marked as failed; (3) Continue horizontal propagation: if any of the sibling nodes of A3 depends on A3, it is marked as failed; (4) Continue vertical bubbling: the top-level task "develops new functions" checks the status of all child nodes. If all of them have terminated and at least one has failed, the entire plan is marked as failed.

[0063] The key advantages of this mechanism are: (1) The scope of the failure corresponds precisely to the dependency relationship, and the subsequent tasks that depend on the failed node are automatically prevented from executing, thus avoiding invalid computation; (2) Failure information is automatically propagated upwards, and the parent task is aware of the failure of the child task, supporting the error handling and recovery strategy of the upper layer; (3) The propagation process is a recursive algorithm, which automatically handles hierarchical structures of arbitrary depth and arbitrarily complex dependencies.

[0064] S140. Recursively check the parent node of the failed node upwards according to the two-dimensional plan tree, and adjust the state of the parent node according to the recursive check result.

[0065] Furthermore, the parent nodes of failed nodes can be recursively checked upwards according to the two-dimensional plan tree, and the state of the parent nodes can be adjusted according to the recursive check results. This process corresponds to the vertical bubble check process.

[0066] In a specific embodiment, step S140 includes the following sub-steps: determining whether the two-dimensional plan tree has a parent node corresponding to the failed node; if there is no parent node corresponding to the failed node, terminating the recursive check; if there is a parent node corresponding to the failed node, obtaining all child nodes of the parent node and performing a status check; if all child nodes of the parent node are in a terminated state and at least one of them is in a failed state, marking the parent node as failed and triggering the parent node to perform horizontal failure propagation and vertical bubbling checks; the terminated state includes completed or failed; if all child nodes of the parent node are in a completed state, marking the parent node as completed and triggering the parent node to perform vertical bubbling checks and sibling node activation checks.

[0067] The process involves determining whether a parent node exists in the two-dimensional plan tree corresponding to the failed node. If not, the recursive check terminates. If a parent node exists, all its child nodes are retrieved and their states are checked. If all child nodes of the parent node are in a terminated state and at least one of them is in a failed state, the parent node is marked as failed. The terminated state includes either completed or failed. In this case, the parent node acts as a failed node and can perform the aforementioned lateral failure propagation. Simultaneously, as a failed node, the parent node can also return to the step of determining whether a parent node exists in the two-dimensional plan tree corresponding to the failed node, which is equivalent to implementing a vertical bubbling check.

[0068] If all child nodes of a parent node are in a completed state, then the parent node is marked as completed, and the parent node is triggered to perform a vertical bubbling check (return to the step of determining whether there is a parent node corresponding to the failed node in the two-dimensional plan tree) and a sibling node activation check (corresponding to step S110).

[0069] In a specific embodiment, the method further includes: if a new node addition request is received, verifying the validity of the parent node path in the new node addition request and identifying the path type corresponding to the parent node path; if the parent node path is a plan root path, adding the new node as a root-level node; if the parent node path points to an existing plan node, adding the new node as a child node of the plan node; constructing the complete path of the new node according to the parent node path and the node identifier of the new node; registering the new node in the node index of the plan manager, and configuring the state of the new node as pending activation, the stage index as zero, and the execution result as empty; if the new node contains child nodes, recursively indexing all child nodes of the new node; if the current state of the parent node corresponding to the new node is completed, adjusting the state of the parent node to active and continuing execution; adding the new node as a plan node and returning to the step of determining whether it is in an activatable state.

[0070] The plan manager can also receive new node addition requests. If a new node addition request is received, the validity of the parent node path in the new node addition request is verified, and the path type corresponding to the parent node path is identified.

[0071] If the parent node path is valid and is a plan root path type, the new node is added as a root node, and in this case, the new node does not contain a parent node. If the parent node path is valid and is not a root path type, the parent node path points to an existing plan node, and the new node is added as a child node of the existing plan node.

[0072] Construct a complete path corresponding to the new node based on the parent node path and the new node's node identifier. The format of the complete path is parent node path + "." + new node's node identifier. Register the resulting new node in the plan manager's node index, so the plan manager can manage the new node through the node index.

[0073] Figure 6 This is a flowchart of the dynamic planning extension of the present invention, which can handle the addition of new nodes. It supports the dynamic addition of new nodes during operation, and the state of the parent node is automatically adjusted during the addition of a new node. After the new node is added, dependency resolution is performed (corresponding to the activation check in step S110).

[0074] The dynamic plan expansion mechanism allows adding new child nodes to any parent node during plan execution. This mechanism enables the plan tree to adaptively adjust based on the execution results. The algorithm for dynamically adding new nodes is as follows: Dynamic Plan Expansion Input: parent_path, new node object node; Output: None (Side effect: updates the plan tree structure and index). The steps include: (1) If parent_path equals the plan root identifier, then: a. Construct the full path of the new node: full_path = plan root identifier + "." + node.nid; b. Add node to the node list of the plan root; c. Set the scope prefix to the plan root identifier; (2) Otherwise: a. Query the node index to get the parent node object parent_node corresponding to parent_path; b. If parent_node does not exist, throw the exception "parent node does not exist"; c. Construct the full path of the new node: full_path = parent_path + "." + node.nid; d. Add node to the child node list of parent_node; e. Record in the parent-child relationship index: the parent node of full_path is parent_path; f. Set the scope prefix to parent_path; g. (2) Query the state index. If the state of parent_path is "COMPLETED", then roll back its state to "ACTIVE". (3) Register in the node index: full_path is mapped to node. (4) Initialize in the state index: the state of full_path is "PENDING". (5) Initialize in the stage index: the stage index of full_path is 0. (6) Initialize in the result index: the cumulative output of full_path is an empty string. (7) If node contains child nodes, then recursively index all child nodes. (8) Call the dependency satisfaction check algorithm to check whether the dependency of the new node is satisfied. (9) If the dependency is satisfied, then activate the new node immediately.

[0075] Application scenario example: During the execution of a code review task, three issues are found, requiring the dynamic addition of three fix sub-tasks. The initial plan tree only has a "code review" node, and after execution, three child nodes, "fix issue 1", "fix issue 2", and "fix issue 3", are dynamically added. If issue 2 depends on the fix result of issue 1, then depends_on=["fix issue 1"]. The new node immediately participates in dependency resolution after being added, and is activated immediately if the dependency is satisfied. The key advantages of this mechanism are: (1) It supports runtime adjustment, and the plan tree does not need to be completely determined before execution, and can be dynamically expanded based on intermediate results; (2) The new node enjoys the same semantics as the existing node, and mechanisms such as dependency resolution, context passing, and failure propagation are automatically applied to the new node; (3) The parent node status is automatically adjusted. If the parent node has been completed but a new child node has been added, the parent node status reverts to active, waiting for the new child node to complete.

[0076] The plan manager maintains a global index of the plan tree. The specific maintenance steps include: node index, which maps the complete path of a node to a node object, supporting node lookup with O(1) time complexity; parent-child relationship index, which maps the complete path of a node to the path of its parent node, supporting fast upward traversal; status index, which maps the complete path of a node to the current status of the node, including pending activation, active, completed, and failed; stage index, which maps the complete path of a node to the current stage index, used for progress tracking of multi-stage execution; and result index, which maps the complete path of a node to the cumulative execution result, used for context passing and result querying. The global index is built once when the plan is loaded and updated incrementally during the execution of the plan, so that all operations of the plan manager have constant time or linear time complexity.

[0077] The plan manager maintains the global state of the plan tree and supports real-time queries. The state includes node status, stage index, and execution results. Status query interface: (1) Query all node status: Returns a dictionary where the key is the full path of the node and the value is the current status of the node (PENDING, ACTIVE, COMPLETED, or FAILED). (2) Query specific node results: Input the full path of the node and return the cumulative output string of that node. (3) Query plan completion status: Returns a boolean value indicating whether the plan has been completed (all root-level nodes are in the terminated state). (4) Query global context: Returns a string of cumulative execution results of all nodes concatenated in execution order, used for global decision-making or final result summarization at the application layer.

[0078] Node states include four types: PENDING, ACTIVE, COMPLETED, and FAILED. State transition rules are: (1) PENDING → ACTIVE: Automatic transition when dependencies are satisfied; (2) ACTIVE → COMPLETED: Transition when all stages or all child nodes are completed; (3) ACTIVE → FAILED: Transition when execution fails or a child node fails; (4) PENDING → FAILED: Transition when a dependent node fails. The global context is a concatenation of the cumulative execution results of all nodes, arranged in execution order. This context can be used for global decisions or final result summarization at the application layer.

[0079] Figure 7 The system architecture diagram of this invention involves the interface application between the plan manager and the underlying execution engine. The data flow includes: (1) Application layer → Plan manager: plan tree definition; (2) Plan manager → Underlying execution engine: node mapping; (3) Underlying execution engine → LLM instance: inference request; (4) LLM instance → Underlying execution engine: execution result; (5) Underlying execution engine → Plan manager: result return; (6) Plan manager → Application layer: state update. The plan manager, as layer 1.5, is located between the application layer and the scheduling kernel layer. The application layer defines the high-level plan structure, and the plan manager decomposes the plan into a thread execution sequence of the scheduling kernel layer. Leaf nodes are mapped to attention threads; the execution stage list of nodes is mapped to a multi-stage execution sequence of threads.

[0080] The algorithm for processing node submission results is as follows: multi-stage execution result submission; input: node identifier tid (i.e., the complete path of the node), execution result result; output: none (side effect: updating the node state and stage). The specific steps include: (1) setting path = tid; (2) querying the node index to obtain the node object node corresponding to path; (3) appending result to the cumulative output of path in the result index; (4) querying the stage index to obtain the current stage index idx of path (if it does not exist, it defaults to 0); (5) if the stage list of node is not empty and idx + 1 < the stage list length, then perform stage advancement: a. update the stage index to idx + 1; b. copy the parameter dictionary of node to the new parameter dictionary params; c. call algorithm 2 to construct the structured context ctx of node; d. obtain the cumulative output own of node; e. if ctx is not empty, then concatenate ctx and own as the previous_output parameter; otherwise, use own as the previous_output parameter; f. call the stage switching interface of the underlying execution engine to switch the execution unit to the next stage; (6) otherwise (all stages have been completed): a. call the termination interface of the underlying execution engine to terminate the execution unit; b. c. Update the state of path to "COMPLETED"; d. Call Algorithm 4 to perform vertical failure bubbling; 3. Check and activate the sibling nodes of path whose dependencies have been satisfied.

[0081] Application scenario example: The code generation task is divided into three stages: (1) "Design interface" stage, generating function signatures and documentation; (2) "Implementation logic" stage, generating function bodies based on interface design; (3) "Optimize code" stage, performing performance optimization based on implementation results. The output of each stage is used as the previous_output parameter of the next stage to realize information transfer between stages. The key advantages of multi-stage execution are: (1) Complex tasks of a single node can be decomposed into multiple steps, and the input and output of each step are clear; (2) Information transfer between stages is automated and does not require manual configuration; (3) It supports stage-level state persistence and can be resumed from the current stage after execution is interrupted.

[0082] This application also discloses a context-physically isolated two-dimensional task orchestration system for large language models. The system includes a plan manager, an application layer, and a scheduling kernel layer. The plan manager is located between the application layer and the scheduling kernel layer, and is communicatively connected to both the application layer and the scheduling kernel layer. The plan manager is used to execute the scheduling method for the large language model computing cluster as described in the above embodiments. Figure 7As shown, the scheduler, as layer 1.5, sits between the application layer and the scheduling kernel layer. The application layer defines the high-level schedule structure, and the scheduler decomposes the schedule into a sequence of thread executions at the scheduling kernel layer.

[0083] The interfaces between the plan manager and the underlying execution engine include: **Scheduling Interface:** Retrieves the next thread object to be executed from the underlying execution engine. This interface returns the highest-priority executable thread. **Creation Interface:** Called when a leaf node is activated. Input parameters include thread identifier (tid), template name (template), phase name (phase), parameter dictionary (params), and priority (priority). This interface creates a new execution thread in the underlying execution engine. **Phase Switching Interface:** Called when a node advances to the next phase. Input parameters include thread identifier (tid), new phase name (phase), updated parameter dictionary (params), and priority (priority). This interface updates the current phase and parameters of the execution thread. **Termination Interface:** Called when a node completes or fails. Input parameter is the thread identifier (tid). This interface terminates the corresponding execution thread and releases resources. **Bulk Termination Interface:** Called when a plan is canceled. Input parameter is the path prefix (prefix). This interface terminates all execution threads whose identifiers begin with "prefix" and returns the number of terminated threads.

[0084] The mapping rules from nodes to threads are as follows: (1) Branch nodes do not create threads, but are only used as logical organizational units; (2) Leaf nodes create threads, and the node path is used as the thread identifier; (3) The template and phases of a node are mapped to the template and phase of a thread; (4) The priority of a node is mapped to the priority of a thread.

[0085] Execution flow: (1) The application layer calls the load method of the plan manager to load the plan tree; (2) The plan manager performs integrity verification, builds a global index, and activates the root-level nodes whose dependencies are satisfied; (3) The application layer calls the tick method in a loop, and the plan manager calls the underlying scheduler to get the next thread to be executed; (4) The underlying execution engine executes the thread, and the application layer calls the submit method to submit the execution result; (5) The plan manager updates the node status and triggers phase advancement, failure propagation, or sibling node activation; (6) Repeat steps 3-5 until the plan is completed.

[0086] The interaction protocol and context physical isolation mechanism between the plan manager and the underlying attention scheduling kernel: When a leaf node is activated, the plan manager calls the create interface of the scheduling kernel to create an attention thread, passing parameters including: tid (thread identifier): using the full path of the node as the thread identifier, such as "plan1.A3.B2"; template (template name): the template identifier of the node, pointing to the .thread template file; phase (phase name): the current phase of the node, corresponding to the phase section in the template file; params (parameter dictionary): the parameter dictionary of the node, where the previous_output parameter contains the structured context of the node (parent node output + dependent node output); priority (priority): the priority of the node, used for priority sorting by the scheduler.

[0087] After receiving a create request, the underlying scheduling kernel inserts a new record into the threads table of the SQLite database. This record contains all the thread's state information (tid, content, context_ref, template, phase, params, priority, state, etc.). The thread's context is stored in a separate field of this record, physically isolated from the records of other threads.

[0088] When a node completes, the scheduler calls the scheduler kernel's kill interface to terminate the thread. The scheduler kernel performs the following operations: (1) Executes the SQL statement: DELETE FROM threads WHERE tid = ?; (2) Physically deletes the thread's record in the database; (3) Releases the storage space occupied by the thread.

[0089] Key technical effect: When a thread terminates, its detailed execution history (including prompts, responses, intermediate states, etc.) is physically deleted and not passed on to sibling nodes. Only the node's output (the result field) is retained by the plan manager in the result index (a Python dictionary in memory) for use in the context construction of subsequent nodes.

[0090] The plan tree performs integrity verification during loading. This verification process includes: uniqueness verification, checking if all child node identifiers under the same parent node are unique; if duplicate identifiers exist, loading is rejected; dependency validity verification, checking if the dependent node identifiers in each node's dependency list exist among its sibling nodes; if the dependency does not exist, loading is rejected; circular dependency detection, constructing a dependency graph for sibling nodes within each parent node's scope and using depth-first search to detect circular dependencies; if circular dependencies exist, loading is rejected; and recursive verification, recursively performing the above verifications at each level of the plan tree. The integrity verification is completed before plan execution to ensure the structural validity of the plan tree and prevent unrecoverable errors during runtime.

[0091] The algorithm for detecting circular dependencies is as follows: Circular Dependency Detection; Input: Node list nodes (sibling nodes within the same scope); Output: None (an exception is thrown if a circular dependency is detected); The specific steps include: (1) Constructing a mapping table nid_map from node identifiers to node objects; (2) Initializing the visited set visited to an empty set; (3) Initializing the current path stack stack to an empty set; (4) Defining the depth-first search subprocess DFS(nid): a. If nid is in the stack, throw the exception "Circular dependency detected, involving node nid"; b. If nid is in visited, return (the node has been checked); c. Add nid to the stack; d. Traverse each dependent node identifier dep in the depends_on list of nid_map[nid]; e. For each dep, recursively call DFS(dep); f. Remove nid from the stack; g. Add nid to visited. (5) Traverse each node n in nodes and call DFS(n.nid).

[0092] The algorithm uses depth-first search to detect cycles in a directed graph. If node A depends on B, B depends on C, and C depends on A, then a circular dependency is formed. When a circular dependency is detected, the loading plan is rejected to avoid runtime deadlock. The advantages of integrity verification are: (1) pre-execution error detection, which discovers structural problems before execution and avoids runtime errors; (2) ensuring the satisfiability of dependencies, that all dependent nodes exist and there are no circular dependencies; and (3) ensuring the uniqueness of node identifiers and avoiding ambiguity in dependency resolution.

[0093] The new node is further configured with a status of pending activation, a stage index of zero (the stage index value is zero), and an empty execution result. It is then determined whether the new node contains child nodes. If it does, all child nodes of the new node are recursively indexed to update the child node list. If the current status of the parent node corresponding to the new node is completed, the parent node's status is readjusted to active, and the planned node execution continues. The newly added node is then used as the planned node, and the execution returns to step S110.

[0094] In a specific embodiment, the method further includes: if a cancellation request is received, terminating the execution of the underlying execution unit of the plan node corresponding to the cancellation request; marking the status of non-terminated nodes in the two-dimensional plan tree as failed; and obtaining the number of the underlying execution units that have terminated execution.

[0095] If a cancellation request is received, the execution of all underlying execution units corresponding to the cancelled request's schedule node is terminated. Termination of underlying execution unit execution can be achieved by calling the underlying execution engine's batch termination interface. In addition, the schedule manager interacts with the underlying execution engine through the following interfaces: a scheduling interface, which calls the underlying execution engine's scheduler to obtain the next execution unit to be executed; a creation interface, called when a leaf node is activated, which creates a new execution unit based on the node's template identifier, stage name, and parameter dictionary; a stage switching interface, called when a node advances to the next stage, which updates the current stage and parameters of the execution unit; and a termination interface, called when a node completes or fails, which terminates the corresponding execution unit. This interface design decouples the schedule manager from the underlying execution engine, making it suitable for different underlying execution engines.

[0096] Further traverse all plan nodes in the two-dimensional plan tree, marking non-terminated nodes as failed, obtaining the number of terminated underlying execution units, and providing this as feedback. The plan cancellation operation corresponding to the cancellation request is an atomic operation, ensuring that all underlying execution units of the current plan node terminate simultaneously, preventing resource leaks caused by some underlying execution units continuing to run.

[0097] In a specific embodiment, the method further includes: if a retry request is received, determining whether the plan node corresponding to the retry request exists; if it exists, resetting the state of the plan node to be activated, the stage index to zero, and the execution result to empty; if the plan node is in an activatable state, returning to the step of constructing the input context corresponding to the plan node.

[0098] If a retry request is received, it is determined whether the plan node corresponding to the retry request exists. If it exists, the plan node's status is reset to pending activation, the stage index is zero, and the execution result is empty. It is then determined whether the plan node is in an activatable state (corresponding to step S110). If it is in an activatable state, it is returned to step S120 to retry executing the plan node.

[0099] The inventors conducted multi-stage verification experiments on commercial large language models, using standard programming tasks as test scenarios to compare the execution performance of one-dimensional orchestration schemes with the two-dimensional orchestration schemes of this invention. The experiments used the AttentionOS scheduling kernel as the underlying execution engine, mapping plan nodes to attention threads for execution.

[0100] Evaluation metrics definition: The following quantitative metrics are used to evaluate the performance of the task orchestration scheme in this experiment. (1) Cumulative Completion Rate (CCR): Defined as the average completion quality of all steps, with a value range of 0 to 1. The higher the value, the better the task execution quality. (2) Degradation Coefficient (DC): Defined as the rate at which the completion rate decreases with the number of steps during task execution. A negative value indicates performance degradation, and the smaller the absolute value, the better the stability. (3) Average number of input tokens: Defined as the arithmetic mean of the number of tokens input to the large language model when each step is executed. It reflects the efficiency of the context passing mechanism. This metric directly affects the LLM inference cost.

[0101] Small-scale task validation (10-step task): Using a commercial large language model, testing was conducted on a web backend development task, which includes 10 sequentially executed steps (requirements analysis, interface design, database design, core logic implementation, API endpoint implementation, error handling, unit testing, integration testing, documentation writing, and code review). The one-dimensional solution uses a full history stacking strategy, while the two-dimensional solution of this invention uses a scope-isolated context passing strategy. Experimental results: The CCR of this invention's solution is 0.950, compared to 0.900 for the one-dimensional solution, an improvement of 5.6%; the DC is -0.0027, compared to -0.0094 for the one-dimensional solution, an improvement of 71%; the average number of input tokens is 1888, compared to 3526 for the one-dimensional solution, saving 46%. This experiment verifies the effectiveness of the scope isolation mechanism in small-scale tasks.

[0102] Validation on a medium-sized task (30-step task): Using a commercial large language model, tests were conducted on an extended version of the same web backend development task, which refined the original 10 steps into 30 sub-steps. The increased task size significantly worsened the context stacking problem in the one-dimensional solution, with the number of input tokens reaching approximately 45,000 in step 30. Experimental results: The proposed solution achieved a CCR of 0.917, compared to 0.858 for the one-dimensional solution, representing a 6.9% improvement; the average number of input tokens was 2468, compared to 14712 for the one-dimensional solution, saving 83%. Compared to the 10-step experiment, the token saving ratio increased from 46% to 83%, verifying that the scope isolation mechanism of the two-dimensional structure has a more significant advantage when the task size increases.

[0103] Key Technology Effectiveness Analysis: In a 30-step task, the average number of input tokens for the one-dimensional solution is 14712, while the solution of this invention requires only 2468, saving 83%. This significant token saving directly translates into a reduction in LLM inference cost. Based on the typical pricing of commercial LLM services (approximately 0.01 yuan per thousand tokens), the input token cost for processing a 30-step task is approximately: 14712 × 30 × 0.01 / 1000 = 4.4 yuan for the one-dimensional solution, while it is approximately: 2468 × 30 × 0.01 / 1000 = 0.74 yuan for the solution of this invention, saving 83% of the cost. In large-scale application scenarios, this cost saving has significant commercial value.

[0104] This embodiment compares the differences between two-dimensional and one-dimensional structures in context passing through a specific scenario, illustrating the core advantages of two-dimensional structures. Scenario setting: Software development task, including the following structure. Task A: Requirements Analysis (Output: Requirements Document, 5000 tokens); A1: User Interviews (Output: Interview Records, 3000 tokens); A2: Requirements Compilation (Output: Requirements List, 2000 tokens). Task B: Architecture Design (depends on A, output: architecture document, 4000 tokens); B1: Technology Selection (Output: Technology Stack, 2000 tokens); B2: Module partitioning (output: module graph, 2000 tokens). Task C: Implementation (depending on B); Context Propagation Analysis in a One-Dimensional Structure: In a one-dimensional structure, all task nodes are at the same level and are executed in the order A1→A2→A→B1→B2→B→C. When task C is executed, due to the lack of scope boundaries in a one-dimensional structure, the input context of C contains the outputs of all preceding tasks: Input Context = A1's Interview Records (3000 tokens) + A2's Requirements List (2000 tokens) + A's Requirements Document (5000 tokens) + B1's Technology Stack (2000 tokens) + B2's Module Diagram (2000 tokens) + B's Architecture Document (4000 tokens) = 18000 tokens. Problem Analysis: Task C actually only needs B's architecture document (4000 tokens) to start coding, because the architecture document has already integrated the requirements information and provided the technical solutions. A1's interview records and A2's requirements list are the internal implementation details of A, and B1's technology stack and B2's module diagram are the internal implementation details of B; these are irrelevant information to C. However, the one-dimensional structure cannot isolate this information, resulting in the invalid transmission of 14,000 tokens. For LLM services that are billed per token, this directly translates to wasted costs; for the inference quality of LLM, irrelevant information will distract attention and reduce output quality.

[0105] Context passing analysis of two-dimensional structure: In the two-dimensional structure, A1 and A2 are child nodes of A, and B1 and B2 are child nodes of B, forming two tree levels. Horizontally, B depends on A, and C depends on B. When task C is executed, according to the scope isolation mechanism: (1) C can only access the output of its dependent node B (horizontal injection); (2) C can only access the output of its parent node (vertical inheritance, but C is the root node and has no parent node); (3) C cannot access the output of A1, A2, B1, and B2 because they are encapsulated within the scope of their respective parent nodes. Therefore, the input context of C = B's architecture document (4000 tokens). If C also needs to access the requirements document, C can be set to depend on both A and B. Then: Input context = A's requirements document (5000 tokens) + B's architecture document (4000 tokens) = 9000 tokens.

[0106] Comparison results: One-dimensional structure requires 18,000 tokens; two-dimensional structure (depending only on B) requires only 4,000 tokens, saving 78%; two-dimensional structure (depending on A and B) requires only 9,000 tokens, saving 50%. The core advantages of this scheme are explained as follows: (1) Scope isolation: The detailed outputs of A1 and A2 are isolated within the scope of A, and external tasks cannot access them. This isolation cannot be achieved in one-dimensional structure because one-dimensional structure lacks the modular boundaries provided by the vertical dimension. (2) Automatic context switching: When execution switches from branch A (A→A1→A2) to branch B (B→B1→B2), the context automatically switches from "cumulative output of A" to "cumulative output of B", and the detailed information of A's subtasks will not be passed to B's subtasks. This automatic switching mechanism ensures that each LLM inference call only processes the relevant context. (3) Precise control: By adjusting the dependency relationship (C depends on B, or C depends on A and B), it is possible to precisely control which contexts C can access. One-dimensional structure can only be achieved through full stacking or manual parameter binding. The former leads to information overload, and the latter has high maintenance costs. (4) Scalability: If A is further decomposed into more subtasks (A1, A2, A3...A10), the context of the one-dimensional structure will grow linearly, while the context of the two-dimensional structure remains unchanged, because the detailed output of the subtask is always encapsulated within the scope of A.

[0107] Multi-model validation: The planning management mechanism of this invention is decoupled from the underlying large language model, supporting the combined use of models with different capabilities and costs. The validation experiment adopted a hierarchical model strategy: low-cost models (MiniMax-M2.5) were used for regular task nodes, and high-cost models (GLM-5, Claude Opus 4.6) were used for critical decision nodes. During a continuous 20-day run, the high-cost model consumed approximately 1 billion tokens. Through the scope isolation mechanism of this invention, approximately 70% of token consumption was saved compared to the one-dimensional full-history accumulation strategy (i.e., the one-dimensional solution is estimated to consume approximately 3.3 billion tokens). This validation demonstrates that the dependency resolution mechanism and context passing mechanism of this invention are universally applicable to different models, and the token saving effect is more significant on high-cost models, directly translating into cost savings.

[0108] Real-world task scenario verification: This invention has been verified in various industrial-grade development tasks, and the effectiveness of the two-dimensional orchestration mechanism has been quantitatively evaluated through A / B comparison testing.

[0109] The first task category is C language audio algorithm optimization. This task creates a two-dimensional structure with five plan nodes, responsible for algorithm analysis, performance bottleneck identification, optimization scheme design, code refactoring, and performance testing, respectively. The nodes have dependencies defined by the `depends_on` attribute (bottleneck identification depends on algorithm analysis, optimization scheme design depends on bottleneck identification, code refactoring depends on optimization scheme design, and performance testing depends on code refactoring). Comparative test settings: The one-dimensional solution executes a single plan node sequentially while retaining the complete dialogue history; the two-dimensional solution of this invention uses a multi-node plan tree and enables scope isolation. Test results: The high-cost model token consumption of this invention's solution is reduced by approximately 75% compared to the one-dimensional solution. The generated code passes all unit tests and integration test cases, and the code execution efficiency is comparable to the one-dimensional solution. This experiment verifies the token-saving effect of the scope isolation mechanism in multi-stage tasks.

[0110] The second type of task: Embedded system full-process development. The specific scenario is the development of a UDP to RS232 protocol converter based on the AG32F407 development board. This task creates a two-dimensional hybrid structure with 7 project nodes: the root node "Protocol Converter Development" contains 3 child nodes (requirements analysis, hardware interface design, firmware programming), and the firmware programming node further contains 4 child nodes (UDP module, RS232 module, unit testing, integration testing). Unit testing depends on the UDP and RS232 modules, and integration testing depends on the unit tests passing. This structure simultaneously demonstrates vertical hierarchy (parent-child relationship) and horizontal dependency (depends_on relationship between sibling nodes), making it a typical two-dimensional structure.

[0111] Comparative test settings: The one-dimensional solution executes a flat, 7-step sequential process while preserving the complete dialogue history. The two-dimensional solution of this invention uses a hierarchical plan tree and enables scope isolation and failure propagation mechanisms. Test results: The high-cost model token consumption of this invention is reduced by approximately 80%. The generated firmware code successfully passed all unit tests, integration tests, and system tests, achieving bidirectional data conversion between UDP and RS232. The code quality is not significantly different from the one-dimensional solution (similar number of lines of code, comparable functional completeness). This experiment verifies the effectiveness of the two-dimensional hybrid structure and failure propagation mechanism in complex dependency tasks.

[0112] Key technical effects: In embedded development tasks, the detailed output of the four child nodes (UDP module, RS232 module, unit test, and integration test) of the firmware programming node is encapsulated within the scope of the firmware programming node. When other child nodes of the root node are executed (such as requirements analysis and hardware interface design), they cannot access the detailed output of the firmware programming child nodes, but can only access the cumulative output of the firmware programming node. This scope isolation allows the context to switch automatically between different branches, avoiding the accumulation of irrelevant information. This is the core advantage of a two-dimensional structure over a one-dimensional structure; a one-dimensional structure cannot achieve this automatic switching because it lacks the modular boundaries provided by the vertical dimension.

[0113] The above verifications demonstrate that the scope isolation mechanism of this invention significantly reduces token consumption while maintaining output quality, making it practically valuable in cost-sensitive industrial applications. Addressing the token-based billing characteristic of LLM, this invention achieves precise context control through a two-dimensional structure, ensuring that each inference call processes only relevant information, directly translating into cost savings.

[0114] Long-term stability verification: The planning management system of this invention ran continuously in a production environment for approximately 20 days, handling multiple concurrent planned tasks and accumulating thousands of planned nodes. This verification focused on examining the reliability of the dynamic plan expansion mechanism and failure propagation mechanism in long-cycle tasks. Dynamic expansion scenario: During the execution of the code review task, repair sub-tasks were dynamically added based on the number of issues found. The largest review task dynamically added 15 repair nodes. The dependencies of all new nodes were correctly resolved, the context was correctly passed, and there were no state inconsistencies or deadlocks. Failure propagation scenario: When an integration test fails, the deployment task that depends on the test is automatically marked as failed. The parent task detects the failure of the sub-task and triggers the rollback process. The entire failure propagation path is completely consistent with the expected dependencies. No memory leaks, state corruption, or scheduling deadlocks were observed during long-term operation, verifying the stability of this invention in industrial applications.

[0115] The core technological insight of this invention is that the task orchestration of LLM agents requires a combination of innovative approaches, namely "two-dimensional structure + physical isolation + selective retention," to overcome the dilemma of "attention retention" and "information integrity."

[0116] Key technical principle: The information retention strategy is automatically determined through the semantics of a two-dimensional structure—the detailed execution history of subtasks is physically deleted (to avoid distraction), but key information is automatically aggregated into the cumulative output of the parent task through a hierarchical transfer mechanism (ensuring information integrity). This "selective forgetting" mechanism is not a manually written compression logic, but is automatically implemented by the semantics of the two-dimensional structure: the vertical parent-child relationship defines the information aggregation path, and the horizontal dependency relationship defines the access permissions for information.

[0117] The fundamental difference from existing solutions: Existing technologies employ full-data retention schemes (Temporal, LangGraph): all information is retained equally, making it impossible to distinguish between relevant and irrelevant information; existing technologies employ manual compression schemes (LangGraph reducer): compression logic needs to be manually written, which may result in the loss of critical information. This invention: the semantics of the two-dimensional structure automatically determine the retention strategy, avoiding distraction while ensuring information integrity.

[0118] Traditional workflow engines, while possessing a two-dimensional structure, lack a physical isolation mechanism. This invention maps plan nodes to attention threads and utilizes the physical termination of threads to achieve physical deletion of the context, thereby realizing truly effective selective forgetting in LLM scenarios.

[0119] The key technical effect is that when executing subtasks of different branches, the context automatically switches without carrying the detailed information of irrelevant branches. This precise control of the context cannot be achieved in one-dimensional structures and traditional two-dimensional engines. Specifically: (1) Subtasks A1, A2, and A3 of task A are executed within the scope of A, and their detailed outputs are not visible to A's sibling task B. B can only access A's cumulative output; (2) When execution switches from branch A to branch B, the context automatically switches from "A's cumulative output" to "B's cumulative output". The detailed information of A's subtasks will not be passed to B's subtasks; (3) This automatic switching mechanism ensures that each LLM inference call only processes the relevant context, avoiding the accumulation of irrelevant information.

[0120] The first innovation of this invention lies in the semantic design of a two-dimensional hybrid structure. This hybrid structure combines the hierarchical organization capabilities of a tree structure with the dependency expression capabilities of a directed acyclic graph (DAG), and the two structures are orthogonally combined—the tree hierarchy provides the scope boundaries, and the DAG independently defines dependencies within each scope. This architectural design ensures that the modular boundaries of tasks precisely correspond to dependencies, fundamentally solving the context pollution problem of one-dimensional structures.

[0121] The second innovation of this invention lies in its thread-isolation-based physical implementation mechanism and selective retention strategy. Each planning node is mapped to an independent attention thread, and the thread's context is stored in an independent database record (an independent row in SQLite). When a child thread completes, it calls the termination interface of the underlying scheduling kernel, which performs a deletion operation to remove the thread record and physically release the context storage space. The key selective retention mechanism is that the detailed execution history of the child thread (prompts, responses, intermediate states) is physically deleted, but its output summary (typically hundreds of tokens) is retained in the parent node's cumulative output. The parent node's cumulative output contains the output summaries of all child nodes, forming a complete summary of information for that branch. When a sibling node executes, it accesses the parent node's cumulative output through dependencies to obtain the required historical information, but it does not access the deleted detailed execution history.

[0122] The aforementioned special mechanism achieves a unity of "attention preservation + information integrity": Attention preservation: If node A and node B are sibling nodes, when sibling node B executes, the detailed history (potentially thousands of tokens) of node A's child nodes A1 and A2 has been physically deleted, and B's input context only contains A's cumulative output (hundreds of tokens). LLM's attention focuses on information relevant to the current task; Information integrity: A's cumulative output contains key information (output summary) of A1 and A2. B accesses A's cumulative output through dependencies to obtain the historical information required for execution, preventing task failure due to information loss; Automatic decision-making: What to retain and what to delete is automatically determined by the semantics of the two-dimensional structure—the detailed history of child nodes is automatically deleted, the output summary is automatically summarized to the parent node, and dependencies automatically determine access permissions, eliminating the need for manually written compression logic.

[0123] The fundamental differences between the physical isolation mechanism and traditional workflow engines include: in this invention, the detailed history of child threads is physically deleted (DELETE operation), the output summary is automatically aggregated to the parent node, and the retention strategy is automatically determined by the semantics of the two-dimensional structure.

[0124] The third innovation of this invention lies in its automatic context switching capability. This is a unique advantage of two-dimensional structures over one-dimensional structures. When execution switches from one task branch to another, the context automatically switches from the cumulative output of the previous branch to the cumulative output of the current branch, without carrying the detailed information of the subtasks of the previous branch. This automatic switching mechanism cannot be achieved in one-dimensional structures and traditional two-dimensional engines. The semantic automatic determination and preservation strategy of the two-dimensional structure adopted in this invention avoids distraction while ensuring information integrity.

[0125] The fourth innovation of this invention lies in its dynamic plan expansion mechanism. This mechanism allows adding new child nodes to any parent node during plan execution, with the new node immediately participating in dependency resolution and activation checks. If the new node's dependencies are satisfied, it is activated immediately; otherwise, it waits for the dependencies to be satisfied. This mechanism enables the plan tree to adaptively adjust based on the LLM execution results, supporting the handling of uncertainties in the execution of complex tasks.

[0126] The beneficial effects of this invention include: (1) overcoming the dilemma of "attention retention" and "information integrity": through the selective forgetting mechanism of the two-dimensional structure, the detailed history of the subtask is physically deleted to maintain LLM attention focus, and key information is automatically summarized to the parent task through hierarchical transmission to ensure information integrity. Experiments show that in a complex task with 30 steps, the average number of input tokens per node of the present invention is 2468, while the full retention scheme is 14712, saving 83%; at the same time, the task completion rate is 0.917, which is higher than the 0.858 of the full retention scheme (an improvement of 6.9%), and also higher than the manual compression scheme (the manual compression scheme has a completion rate of about 0.82 due to information loss, resulting in the failure of some tasks). This proves that the present invention avoids both attention distraction and information loss. (2) Automated information retention strategy: what to retain and what to delete is automatically determined by the semantics of the two-dimensional structure, without the need for manual compression logic. The vertical parent-child relationship automatically defines the information aggregation path, and the horizontal dependency relationship automatically defines the information access permissions. This automated mechanism eliminates the development costs and error risks of manual compression schemes—developers do not need to predict which information will be used in the future, and the semantics of the two-dimensional structure automatically ensures that relevant information is accessible and irrelevant information is isolated. (3) Complete execution trajectory auditability: This invention forms a semantic execution trajectory through node paths, supporting repeated checks and audits of any step. The output of each node is independently stored in the result index, and the execution result of any step can be accurately located through the node path (such as "plan1.A3.B2"). The cumulative output of the parent node contains a summary of the output of all child nodes, forming the complete execution history of the branch. This structured information organization makes it possible to: (a) accurately locate any node to check its execution result after the plan is executed; (b) re-check the output quality of any step; (c) analyze the root cause of task failure (by tracing the path of the failed node); (d) re-execute from any node (by the node retry interface).

[0127] The two-dimensional task orchestration method and system for context-physically isolated large language models disclosed in the above embodiments includes: determining whether a plan node is in an active state based on the dependency list of the plan node and its parent node in the two-dimensional plan tree; if the plan node is in an active state, constructing an input context corresponding to the plan node based on its dependency list and its parent node in the two-dimensional plan tree; if the plan node fails to execute, determining the plan node as a failed node and marking the state of its downstream dependent nodes as failed based on the dependency list of the failed node; recursively checking the parent node of the failed node upwards according to the two-dimensional plan tree, and adjusting the state of the parent node based on the recursive check results. This context-physically isolated two-dimensional task orchestration method removes detailed execution history of subtasks through the physical isolation mechanism of attention threads to avoid attention distraction, but key information is automatically retained through the hierarchical transmission mechanism of the two-dimensional structure, achieving a balance between attention focus and information integrity, and significantly improving the task orchestration quality of large language model applications.

[0128] This invention also provides a context-physically isolated two-dimensional task orchestration system for large language models, such as... Figure 8 As shown, the context-physically isolated two-dimensional task orchestration system 100 for the large language model is configured in the plan manager. The context-physically isolated two-dimensional task orchestration system 100 for the large language model is used to execute any embodiment of the aforementioned context-physically isolated two-dimensional task orchestration method for the large language model. Specifically, the aforementioned context-physically isolated two-dimensional task orchestration system 100 for the large language model specifically includes a judgment unit 110, a construction unit 120, a status marking unit 130, and a recursion checking unit 140.

[0129] The judgment unit 110 is used to determine whether the plan node is in an active state based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree; the state of the plan node is managed by the plan manager and is switched between pending activation, active, completed and failed.

[0130] The construction unit 120 is used to construct an input context corresponding to the plan node based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree if the plan node is in an active state.

[0131] The status marking unit 130 is used to determine that the planning node is a failed node and mark the status of the downstream dependent nodes of the failed node as failed according to the dependency table of the failed node if the planning node fails to execute.

[0132] The recursive checking unit 140 is used to recursively check the parent node of the failed node upwards according to the two-dimensional plan tree, and adjust the state of the parent node according to the recursive check result.

[0133] In the context-physically isolated two-dimensional task orchestration system for large language models provided in this embodiment of the invention, the above-mentioned context-physically isolated two-dimensional task orchestration method for large language models is executed. Based on the dependency list of the plan node and its parent node in the two-dimensional plan tree, it is determined whether the plan node is in an active state. If the plan node is active, an input context corresponding to the plan node is constructed based on its dependency list and its parent node in the two-dimensional plan tree. If the plan node fails to execute, it is determined to be a failed node, and the downstream dependent nodes of the failed node are marked as failed according to the dependency list of the failed node. The parent node of the failed node is recursively checked upwards according to the two-dimensional plan tree, and its state is adjusted based on the recursive check results. This context-physically isolated two-dimensional task orchestration method deletes detailed execution history of subtasks through the physical isolation mechanism of attention threads to avoid attention distraction, but key information is automatically retained through the hierarchical transmission mechanism of the two-dimensional structure, achieving a balance between attention focus and information integrity, and significantly improving the task orchestration quality of large language model applications.

[0134] The units configured in the aforementioned context-isolated two-dimensional task orchestration system can be implemented as computer programs, which can be used in, for example... Figure 9 It runs on the computer device shown.

[0135] Please see Figure 9 , Figure 9 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. The computer device can be a plan manager for executing a two-dimensional task orchestration method with context-based physical isolation of a large language model to orchestrate tasks for plan nodes in the large language model.

[0136] See Figure 9 The computer device 500 includes a processor 502, a memory, and a communication interface 505 connected via a communication bus 501. The memory may include a storage medium 503 and internal memory 504.

[0137] The storage medium 503 may store the operating system 5031 and the computer program 5032. When the computer program 5032 is executed, it enables the processor 502 to execute a two-dimensional task orchestration method with physical isolation of the context of a large language model. The storage medium 503 may be a volatile storage medium or a non-volatile storage medium.

[0138] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0139] The internal memory 504 provides an environment for the execution of the computer program 5032 in the storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a two-dimensional task orchestration method with physical isolation of the context of a large language model.

[0140] This communication interface 505 is used for network communication, such as providing data transmission. Those skilled in the art will understand that... Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device 500 to which the present invention is applied. The specific computer device 500 may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0141] The processor 502 is used to run the computer program 5032 stored in the memory to implement the corresponding functions in the above-mentioned two-dimensional task orchestration method with context physical isolation of the large language model.

[0142] Those skilled in the art will understand that Figure 9 The embodiments of the computer device shown do not constitute a limitation on the specific configuration of the computer device. In other embodiments, the computer device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. For example, in some embodiments, the computer device may include only memory and a processor. In such embodiments, the structure and function of the memory and processor are different from those shown. Figure 9 The embodiments shown are consistent and will not be described again here.

[0143] It should be understood that, in this embodiment of the invention, the processor 502 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0144] In another embodiment of the invention, a computer-readable storage medium is provided. This computer-readable storage medium may be volatile or non-volatile. The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps included in the above-described two-dimensional task orchestration method with context-physical isolation of a large language model.

[0145] Those skilled in the art will readily understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0146] In the embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Units with the same function may be grouped into one unit. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, or it may be an electrical, mechanical, or other form of connection.

[0147] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.

[0148] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0149] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned computer-readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks.

[0150] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A two-dimensional task orchestration method with context-physical isolation for a large language model, characterized in that, The method is applied to the plan manager of the attention scheduling kernel. The plan manager orchestrates tasks for plan nodes in the large language model. The plan nodes are combined into a two-dimensional plan tree. The two-dimensional plan tree forms a hierarchical tree of arbitrary depth in the vertical direction through parent-child relationships, and forms a directed acyclic graph among sibling nodes at the same level in the horizontal direction through dependencies. The vertical direction defines the boundary of the scope of the parent node, and the horizontal direction defines the execution order. Each plan node contains a node identifier, a list of child nodes, a list of dependencies, a large language model prompt template identifier, a list of execution stages, and a parameter dictionary. The method includes: Based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree, it is determined whether the plan node is in an active state; the state of the plan node is managed by the plan manager and is switched between pending activation, active, completed, and failed. If the plan node is in an active state, construct the input context corresponding to the plan node based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree; If the planned node fails to execute, the planned node is determined to be a failed node, and the status of the downstream dependent nodes of the failed node is marked as failed according to the dependency table of the failed node; The parent node of the failed node is recursively checked upwards according to the two-dimensional plan tree, and the state of the parent node is adjusted according to the recursive check results.

2. The two-dimensional task orchestration method with contextual physical isolation for large language models according to claim 1, characterized in that, The step of determining whether a plan node is in an active state based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree includes: Obtain the scope of the parent node of the plan node in the two-dimensional plan tree; Construct a first path within the scope of the parent node based on the dependency node identifiers contained in the dependency list of the planned node; Check whether the status of all dependent nodes corresponding to the first path is completed; If the status of all dependent nodes corresponding to the first path is "completed", then the planned node is determined to be in an "activatable" state.

3. The two-dimensional task orchestration method with contextual physical isolation for large language models according to claim 1 or 2, characterized in that, The input context includes only the first context fragment and the second context fragment; the step of constructing the input context corresponding to the plan node based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree includes: The context fragment list of the planned node is initialized to be empty; Determine whether the plan node has accumulated execution results in the parent node corresponding to the two-dimensional plan tree; If the parent node corresponding to the plan node has accumulated execution results, the accumulated execution results are added to the context fragment list as the first context fragment; Obtain the dependency resolution scope corresponding to the plan node in the two-dimensional plan tree; A second path is constructed within the dependency resolution scope based on the dependency node identifiers contained in the dependency relationship list of the planned nodes; Determine whether the node corresponding to the second path has an execution result; If the node corresponding to the second path has an execution result, the execution result is added as a second context fragment to the context fragment list; The context fragments contained in the context fragment list are sequentially concatenated to obtain a structured context, which is used as the input context.

4. The two-dimensional task orchestration method with context-physical isolation for large language models according to claim 3, characterized in that, The step of determining the planned node as a failed node and marking the status of the downstream dependent nodes of the failed node as failed according to the dependency table of the failed node includes: Obtain the sibling nodes of the failed node within the scope of the parent node corresponding to the two-dimensional plan tree; Determine whether the dependency list of each sibling node contains the node identifier of the failed node; If the dependency list of any of the sibling nodes contains the node identifier of the failed node and the current state of the sibling node is pending activation, then the sibling node is determined to be a downstream dependent node. The downstream dependent node is marked as failed, and the downstream dependent node is recursively triggered to perform lateral failure propagation.

5. The two-dimensional task orchestration method with context-physical isolation for large language models according to claim 4, characterized in that, The step of recursively checking the parent nodes of the failed nodes upwards according to the two-dimensional plan tree, and adjusting the state of the parent nodes based on the recursive check results, includes: Determine whether the two-dimensional plan tree has a parent node corresponding to the failed node; If there is no parent node corresponding to the failed node, the recursive check is terminated; If a parent node exists corresponding to the failed node, obtain all child nodes of the parent node and perform a status check; If all child nodes of the parent node are in a terminated state and at least one of the child nodes is in a failed state, then the parent node is marked as failed and the parent node is triggered to perform horizontal failure propagation and vertical bubbling checks; the terminated state includes completed or failed. If all child nodes of the parent node are in a completed state, mark the parent node as completed and trigger the parent node to perform vertical bubbling check and sibling node activation check.

6. The two-dimensional task orchestration method with context-physical isolation for large language models according to claim 3, characterized in that, The method further includes: If a new node addition request is received, verify the validity of the parent node path in the new node addition request and identify the path type corresponding to the parent node path; If the parent node path is the planned root path, add the new node as the root node; If the parent node path points to an existing planned node, then the new node will be added as a child node of the planned node. Construct the complete path of the new node based on the parent node path and the node identifier of the new node; Register the new node in the node index of the plan manager, and configure the status of the new node as pending activation, the stage index as zero, and the execution result as empty; if the new node contains child nodes, recursively index all child nodes of the new node; If the current state of the parent node corresponding to the new node is completed, then the state of the parent node is adjusted to active and execution continues; The new node is designated as the planning node, and the process returns to determine whether it is in an active state.

7. The two-dimensional task orchestration method with context-physical isolation for large language models according to claim 3, characterized in that, The plan node includes branch nodes and leaf nodes, and each execution stage of the leaf node corresponds to a call to the underlying execution unit; The method further includes: When the underlying execution unit completes an execution and submits the execution result, the execution result is added to the cumulative execution result of the leaf node; If the index value of the stage index of the leaf node is less than the total number of corresponding stages, then the next execution stage will be executed.

8. The two-dimensional task orchestration method with context-physical isolation for large language models according to claim 1, characterized in that, The method further includes: If a cancellation request is received, the execution of the underlying execution unit of the plan node corresponding to the cancellation request is terminated; Mark the state of non-terminating nodes in the two-dimensional plan tree as failure; Obtain the number of the underlying execution units that have terminated execution.

9. The two-dimensional task orchestration method with context-physical isolation for large language models according to claim 1, characterized in that, The method further includes: If a retry request is received, determine whether the plan node corresponding to the retry request exists; If it exists, reset the status of the plan node to pending activation, the stage index to zero, and the execution result to empty; If the plan node is in an active state, return to the step of constructing the input context corresponding to the plan node.

10. A two-dimensional task orchestration system with physical isolation of context for a large language model, characterized in that, The system is configured in the plan manager of the attention scheduling kernel. The plan manager orchestrates tasks for plan nodes in the large language model. The plan nodes form a two-dimensional plan tree. The system is used to execute the context-physically isolated two-dimensional task orchestration method for the large language model as described in any one of claims 1-9. The system includes: The judgment unit is used to determine whether the plan node is in an active state based on the dependency list of the plan node and the parent node of the plan node in the two-dimensional plan tree; the state of the plan node is managed by the plan manager and is switched between pending activation, active, completed and failed. A construction unit is configured to, if the plan node is in an active state, construct an input context corresponding to the plan node based on the plan node's dependency list and the plan node's parent node in the two-dimensional plan tree; A status marking unit is used to determine that the planning node is a failed node and mark the status of the downstream dependent nodes of the failed node as failed according to the dependency table of the failed node if the planning node fails to execute. The recursive checking unit is used to recursively check the parent node of the failed node upwards according to the two-dimensional plan tree, and adjust the state of the parent node according to the recursive check result.

11. A two-dimensional task orchestration system with physical isolation of context for a large language model, characterized in that, It includes a plan manager, an application layer, and a scheduling kernel layer; the plan manager is located between the application layer and the scheduling kernel layer, and the plan manager is communicatively connected to both the application layer and the scheduling kernel layer; the plan manager is used to execute the scheduling method of the large language model computing power cluster as described in any one of claims 1-10.

12. A computer device, characterized in that, The computer device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the two-dimensional task orchestration method with contextual physical isolation of a large language model as described in any one of claims 1-9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which includes program instructions that, when executed by a processor, implement the two-dimensional task orchestration method for context-physical isolation of a large language model as described in any one of claims 1-9.

Images