An agent workflow orchestration method, an agent, and related devices

Abstract

This application discloses an intelligent agent workflow orchestration method, an intelligent agent, and related devices. The method involves: first, receiving user instructions; second, generating a sub-target graph based on the user instructions, where the sub-target graph includes multiple sub-target nodes and the dependencies between these nodes; and finally, performing the following operations for each sub-target: generating a task graph corresponding to the sub-target based on its description and context information; executing each task in the task graph; and storing tool information of the corresponding task-bound tool and a list of upstream subtasks for each task node. Applying this method can reduce the inference complexity of large language models called during intelligent agent workflow orchestration, improve orchestration efficiency, further reduce the power consumption and response latency of robot edge computing devices, and avoid memory overflow and device resource conflicts in scenarios with unlimited concurrency.

Description

Technical Field

[0001] This application relates to the field of intelligent agent technology, and in particular to an intelligent agent workflow orchestration method, an intelligent agent, and related equipment. Background Technology

[0002] Intelligent agent workflow orchestration is a scheduling framework based on the topology of a directed acyclic graph (DAG). It defines the task timing, data transfer, branching loops, and exception strategies of multiple artificial intelligence (AI) agents, tools, and external systems to achieve automated collaborative execution of complex business objectives.

[0003] In related technologies, the planning and execution of intelligent agents are coupled at the same level. For complex tasks, this may lead to problems such as high inference complexity of large language model calls, high power consumption and slow response of execution devices (such as robot edge computing devices), as well as memory overflow and device resource conflict problems caused by infinite concurrency scenarios. Summary of the Invention

[0004] This application provides an intelligent agent workflow orchestration method, an intelligent agent, and related devices to reduce the inference complexity of large language models called during the intelligent agent workflow orchestration process, improve orchestration efficiency, further reduce the power consumption and response latency of robot edge computing devices, and avoid memory overflow and device resource conflict problems caused by unlimited concurrency scenarios.

[0005] In a first aspect, one embodiment of this application provides an intelligent agent workflow orchestration method, including: Receive user instructions and generate a sub-target graph based on the user instructions; wherein, the sub-target graph includes multiple sub-target nodes and the dependencies between multiple sub-target nodes; each sub-target node stores the description information of the corresponding sub-target and a list of upstream sub-target nodes of the sub-target node; For each of the multiple sub-objectives, perform the following operation: Based on the description and context information of the sub-target, generate the task graph corresponding to the sub-target; execute each of the multiple tasks in the task graph; The task graph includes multiple task nodes and the dependencies between them; each task node stores tool information of the corresponding task-bound tool and a list of upstream subtasks of the task node; the context information is determined based on the execution results of the upstream subtasks of the completed subtasks.

[0006] In this embodiment, upon receiving a user instruction, a sub-target graph is generated based on the user's execution. This sub-target graph includes multiple sub-target nodes and their dependencies. For each sub-target, a corresponding task graph is generated, including multiple task nodes and their dependencies. Then, each task in the task graph is executed. In this design, nodes in the sub-target graph are sub-targets, not bound to specific tools; in the task graph, sub-nodes are tasks, and nodes are specific tool calls. This decouples the planning and execution of the two-level directed acyclic graph (DAG) of the sub-target graph and task graph. On one hand, the layered architecture splits the agent workflow orchestration into two levels of logic, effectively reducing the inference complexity of the large language model during the orchestration stage and improving overall orchestration efficiency. On the other hand, the two-level planning mechanism reduces the frequency of LLM calls, further reducing the power consumption and response latency of the robot's edge computing device, while avoiding memory overflow and device resource conflicts in scenarios with unlimited concurrency.

[0007] In one optional implementation, generating a sub-target map according to user instructions includes: Determine the first prompt word that matches the user command; wherein, the first prompt word includes capability domain information of the first language model; Based on the first prompt word, the first language model is invoked to generate a sub-target map according to the user's instructions; Perform a topological sorting check on the sub-target graph to determine that the sub-target graph is an acyclic graph and has no isolated vertices.

[0008] In the above embodiment, the process of generating the sub-target graph is implemented by the first language model. The first prompt word used in this process includes the capability domain information of the first language model and also matches the user command, thus generating a more accurate sub-target graph. In addition, ensuring that the sub-target graph is an acyclic graph without isolated vertices guarantees that the execution order of the sub-targets will not be disordered.

[0009] In one optional implementation, a task graph corresponding to the sub-target is generated based on the sub-target's description information and context information, including: Based on the second prompt word, the second language model is invoked to generate the task graph corresponding to the sub-target; wherein, the second prompt word includes the description information of the sub-target and the context information of the sub-target node; Perform a topological sort check on the task graph to determine that the task graph is an acyclic graph and has no isolated vertices.

[0010] In the above embodiment, the process of generating the task graph is implemented by a second language model. The second prompt words used in this process include descriptive information about the sub-goals and contextual information determined based on the execution results of the upstream sub-goals of the completed sub-goals. That is, the execution results of the upstream sub-goals are considered, resulting in a more accurate task graph. Furthermore, ensuring that the task graph is an acyclic graph without isolated vertices guarantees that the execution order of tasks will not be disordered.

[0011] In one alternative implementation, the method further includes: After all tasks in the task graph corresponding to the sub-goal have been completed, evaluation information is generated based on the description information of the sub-goal, the execution results of each task, and the context information. The evaluation information includes some or all of the completeness evaluation information, achievement information, missing dimension list, and supplementary suggestion information. Update the first and / or second prompt words based on the evaluation information.

[0012] In the above embodiment, a verification process is added after execution. The evaluation information obtained from the verification is used to update the first prompt word and / or the second prompt word. In this way, when the updated first prompt word or second prompt word is used to execute the workflow orchestration of the intelligent agent in the future, the accuracy is higher and the efficiency is higher.

[0013] In one alternative implementation, the method further includes: If the completeness score indicates a completeness level less than the set completeness threshold, supplementary tasks are generated based on supplementary suggestions and the execution results of each task. These supplementary tasks are then added to the task graph to update it.

[0014] In the above embodiments, the supplementary task is only added to the current task graph, without needing to modify other task graphs of the current sub-target, and will not trigger a global replanning, thus avoiding unnecessary calling processes.

[0015] In one alternative implementation, the method includes: For each task, if a suspected task failure is detected, the task is re-executed based on an exponential backoff retry strategy. If the set number of retries is reached, the task is determined to have failed and the sub-target to which the task belongs has also failed. If a failed sub-target is detected, the downstream sub-targets that depend on the failed sub-target are identified and marked as canceled.

[0016] In the above embodiments, in the case of task execution failure, the task is re-executed through an exponential backoff retry strategy. The retry count is set as a condition, and the retry will not be infinite, which is suitable for resource-constrained scenarios. In the case of sub-target execution failure, the downstream sub-target is marked as canceled in a timely manner to avoid permanent blocking.

[0017] In one alternative implementation, the method further includes: Traverse the subtarget graph to find downstream subtargets that directly or indirectly depend on the failed subtargets; Generate at least one alternative sub-goal; wherein the nodes of the alternative sub-goal inherit the dependencies of the nodes of the sub-goal that failed to execute; The dependencies of downstream sub-target nodes on failed sub-target nodes are replaced with dependencies on alternative sub-target nodes, resulting in an updated sub-target graph. Re-execute the topology sorting check on the updated sub-target graph to confirm that the updated sub-target graph is an acyclic graph and has no isolated vertices.

[0018] In the above embodiment, by generating alternative sub-goals and replacing the dependencies of downstream sub-goals' nodes on failed sub-goals with dependencies on the alternative sub-goals' nodes, an updated sub-goal graph is obtained, and the updated task graph is reprocessed. This design does not affect other sub-goals, ensuring the overall workflow orchestration efficiency and accuracy of the agent.

[0019] In one alternative implementation, the method further includes, before receiving user instructions: Determine capability domain information, tool information, and executor instances; where capability domain information includes multiple sets of capability names and capability descriptions, and tool information includes tool name, tool parameters, and tool descriptions. Determine the correspondence between tool information and capability domain information.

[0020] The above embodiments obtain and determine capability domain information, tool information, and executor instances through a unified registration process, providing data preparation for subsequent execution orchestration. Furthermore, determining the correspondence between tool information and capability domain information allows for timely identification of the capability domain to which a tool belongs, providing a foundation for accurately binding tool information to task nodes.

[0021] Secondly, one embodiment of this application provides an intelligent agent based on a two-level directed acyclic graph, including a central scheduling unit, a strategic planner, a tactical planner, and a workflow execution engine; The central dispatch unit is used to: receive user instructions; The strategic planner is used to: generate a sub-target graph based on user instructions; wherein the sub-target graph includes multiple sub-target nodes and the dependencies between the multiple sub-target nodes; each sub-target node stores the description information of the corresponding sub-target and a list of upstream sub-target nodes of the sub-target node; The tactical planner is used to perform the following operations for each of multiple sub-targets: generate a task graph corresponding to the sub-target based on the sub-target's description information and context information; The workflow execution engine is used to perform the following operation for each of multiple sub-goals: execute each of the multiple tasks in the task graph; The task graph includes multiple task nodes and the dependencies between them; each task node stores tool information of the corresponding task-bound tool and a list of upstream subtasks of the task node; the context information is determined based on the execution results of the upstream subtasks of the completed subtasks.

[0022] In this embodiment, the intelligent agent includes different components to perform different functions. For example, a central scheduling unit receives user instructions; a strategic planner generates a sub-goal graph; a tactical planning phase generates a task graph for each sub-goal's tasks; and a workflow execution engine executes each task. In the sub-goal graph, nodes are sub-goals and are not bound to specific tools; in the task graph, sub-nodes are tasks, and nodes are specific tool calls. This achieves decoupling of planning and execution in the two-level directed acyclic graph of sub-goal graphs and task graphs. On the one hand, the layered architecture splits the intelligent agent's workflow orchestration into two levels of logic, effectively reducing the inference complexity of the large language model in the orchestration stage and improving overall orchestration efficiency. On the other hand, the two-level planning mechanism reduces the frequency of LLM calls, further reducing the power consumption and response latency of the robot's edge computing devices, while avoiding memory overflow and device resource conflicts caused by unlimited concurrency scenarios.

[0023] Thirdly, one embodiment of this application provides an intelligent agent workflow orchestration apparatus, comprising: The data transmission module is used to: receive user commands; The data processing module is used to: generate a sub-target graph according to user instructions; wherein the sub-target graph includes multiple sub-target nodes and the dependencies between the multiple sub-target nodes; each sub-target node stores the description information of the corresponding sub-target and a list of upstream sub-target nodes of the sub-target node; The data processing module is also used to: generate a task graph corresponding to the sub-target based on the description information and context information of the sub-target; and execute each task in the multiple tasks in the task graph. The task graph includes multiple task nodes and the dependencies between them; each task node stores tool information of the corresponding task-bound tool and a list of upstream subtasks of the task node; the context information is determined based on the execution results of the upstream subtasks of the completed subtasks.

[0024] Fourthly, one embodiment of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above methods.

[0025] Fifthly, one embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0026] Sixthly, one embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above methods. Attached Figure Description

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

[0028] Figure 1 A system architecture diagram for intelligent agent workflow orchestration is provided in one embodiment of this application; Figure 2 This is a schematic diagram of the structure of an intelligent agent provided in one embodiment of this application; Figure 3 A flowchart illustrating an intelligent agent workflow orchestration method provided in an embodiment of this application; Figure 4 A schematic diagram of the structure of an intelligent agent workflow orchestration device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0030] For ease of understanding, the terms used in the embodiments of this application are explained below: (1) Capability information, which is used by the Strategic Planner’s Large Language Model (LLM) (represented by the first language model in this embodiment) to refer to when decomposing sub-objectives, and is in the format of “capability name-capability description”.

[0031] (2) Tool information (ToolDef), which is used by the LLM of the tactical planner (represented by a second language model in this embodiment) to refer to when generating tasks, including tool name, tool parameters and tool description.

[0032] (3) Executor instance, which is called by the workflow engine.

[0033] The number of any elements in the accompanying drawings is for illustrative purposes only and not as a limitation, and any naming is for distinction only and has no limiting meaning.

[0034] First, the application background, industry status, and related technologies of this application will be explained.

[0035] Related technology 1: Reasoning-Acting-ReAct Agent Loop.

[0036] Represented by LangChain AgentExecutor and AutoGPT, AgentExecutor is LangChain's agent loop execution engine. Regardless of whether the ReAct hint strategy or the OpenAI Function Calling tool selection mechanism is used, it runs a serial loop of "LLM inference, tool call, LLM observation results, and continued inference." The LLM is located on the critical path of execution, and each step requires LLM decision-making. This approach has the following disadvantages: 1) LLM calls are frequent and costly.

[0037] Each inference step requires a Large Language Model Application Programming Interface (API) call. Even though modern LLMs support returning multiple parallel function calls in a single response, this only reduces the serial waiting time for tools within a single step, not the total number of inference steps. For example, for a task containing 10 tools, even if some steps can call tools in parallel, at least 5-10 LLM calls are still required, resulting in high token consumption.

[0038] 2) It is inherently serial and cannot be concurrent.

[0039] The inference-action alternation pattern of the Agent Loop dictates that each LLM inference must wait for the results of all tools from the previous round to return before it can begin, and all inference paths pass through the same LLM decision point. While modern LLMs support returning multiple parallel tool calls in a single response, allowing the application layer to execute these calls concurrently, this is limited to tool-level parallelism within the same inference step. For independent sub-goals without data dependencies (such as "competitive research" and "architecture design"), the Agent Loop cannot allow them to proceed simultaneously; they must be processed sequentially through the LLM, making decisions one by one.

[0040] 3) Context-dependent message history stacking.

[0041] The execution results of upstream tools are passed to subsequent inference processes by appending them to the dialogue history. When the tools return large JSON or documents, the context window is quickly exhausted, and there is a lack of structured data transmission mechanism.

[0042] 4) The certainty of execution is not high.

[0043] LLM can produce illusions or deviate from the original intent at every step, lacks independent verification links, and once a link fails, the entire process needs to be restarted.

[0044] Related technology 2: Static workflow engine.

[0045] Represented by Apache Airflow, this approach supports parallel scheduling, automatic retries, and state tracking by predefined DAG orchestration of task dependencies. While Perfect (using a dynamic DAG-free workflow) and Temporal (an event-based imperative workflow) do not rely on predefined dependencies, all three suffer from the limitation that the workflow structure must be manually defined by the developer before execution, and cannot be dynamically generated by an LLM based on natural language instructions. Specifically, this approach has the following drawbacks: 1) Dynamic programming capability without LLM-driven operation.

[0046] Workflow logic must be written manually by developers (Airflow's DAG definition, Perfect's @flow / @task decorators, Temporal's Workflow / Activity code), and it is impossible to dynamically generate task graphs and tool selections based on users' natural language commands.

[0047] 2) Lack of a result quality verification (Verify) phase.

[0048] Workflow engines can determine whether a task was executed successfully (return value / exception) and even perform data quality checks (null value rate, range validation, etc.), but they cannot perform semantic-level validation, i.e., determine whether the execution result is complete and whether it fully answers the original question. For example, if a search for a tourist attraction returns 3 results (when there should actually be 10), the engine determines it as successful, but the result is incomplete.

[0049] 3) Lack of a unified capability domain registration mechanism.

[0050] In traditional engines, task declarations (telling the orchestrator what capabilities are available) and execution implementations (telling the engine how to execute) are scattered across different modules or configurations. This makes them prone to inconsistencies when modified, and it is impossible to uniformly manage the "capability domain" attribution of tasks. LLM also cannot automatically select appropriate tools based on capability domains.

[0051] Related technology 3: Single-layer LLM planning, that is, planning before execution (Plan-then-Execute).

[0052] Examples of LLM models include HuggingGPT and Plan-and-Solve. LLMs generate a complete list of steps at once and then execute them according to dependencies. The HuggingGPT process is as follows: the LLM parses the user request into a list of tasks with dependencies (using the `dep` field to annotate data dependencies between tasks), selects the HuggingFace model for each task, executes them according to dependencies (tasks without dependencies can be executed in parallel), and then the LLM summarizes the results. Plan-and-Solve, on the other hand, uses a hinting strategy to allow the LLM to generate a plan first and then execute it step by step. Compared to Agent Loop, this reduces the number of inference-action alternation calls in the LLM. However, this approach has the following disadvantages: 1) The steps are granular and the planning and execution are coupled at the same level.

[0053] It can only formulate a single-level plan. For complex tasks (such as "a robot dog patrolling the entire building, taking pictures and notifying the owner when it finds something unusual"), it cannot distinguish between the two decision levels of "high-level goal decomposition" and "low-level tool selection". Although HuggingGPT separates task planning and model selection into two stages, they are at the same decision level. That is, the task type (such as image-to-text) determines both "what to do" and "what type of model to use", and it cannot separate the semantic decomposition of the target from the binding of tool parameters to different decision levels.

[0054] 2) Static planning cannot be dynamically adjusted.

[0055] LLM generates a complete plan in one go during the planning phase, and strictly follows the preset plan during the execution phase, without the ability to dynamically adjust subsequent steps based on intermediate execution results. For example, if an anomaly is found in the execution result of "inspecting the corridor," the system cannot dynamically insert a new subtask of "taking a picture and notifying" at runtime; it can only continue execution according to the original plan. Although HuggingGPT supports task-level DAG dependencies and parallel execution, its DAG is generated once during the planning phase and cannot be modified during execution.

[0056] 3) Lack of failure isolation and automatic cancellation mechanisms.

[0057] When a step fails, downstream steps that depend on it will be blocked indefinitely and will not be automatically recognized and canceled by the system.

[0058] Related Technology 4: Verification-Driven LLM Orchestration

[0059] VMAO (Verified Multi-Agent Orchestration) implements a closed-loop plan-execute-verify-replan on LangGraph. It decomposes user commands into DAG sub-problems using the QueryPlanner, which is then executed in parallel by the DAGExecutor according to dependencies (supporting the context_from_deps mechanism for selectively passing upstream results). The results are then evaluated for completeness by the LLM Verifier (using the Claude Opus 4.5 model), triggering the AdaptiveReplanner for targeted completion. A.DOT (Agentic DAG-Orchestrated Transformer) compiles natural language queries into DAG execution plans, passing the minimum necessary data between subqueries through variable binding and slimming variables, and supports parallel execution, DataOps error correction, and cache reuse. This approach has the following drawbacks: 1) The planning level is too simple, making it impossible to distinguish between strategic breakdown and tactical selection.

[0060] Both VMAO and A.DOT employ a single-layer DAG decomposition: each sub-question node in VMAO contains both a question (what to do) and an agent type (what tool to use); each node in A.DOT contains a question, a tool (SQL tool or vector retrieval tool), and a label. For complex tasks involving multiple independent subdomains (such as "query weather + search for attractions + generate itinerary"), LLM needs to handle target semantic decomposition and tool parameter binding simultaneously at the same level, increasing the inference burden and error probability of LLM.

[0061] 2) Context passing granularity is limited.

[0062] VMAO's context_from_deps mechanism only allows you to choose whether to pass upstream results, and it cannot filter by sub-goal dimension. When multiple tasks under the same sub-goal generate a large number of intermediate results, downstream nodes still need to receive all upstream outputs. Although A.DOT's lightweight variables only pass necessary key-value pairs, their variable binding occurs at the DAG node level, and context aggregation and pruning cannot be performed at the sub-goal level, which may result in redundant information being passed across sub-goals.

[0063] 3) Lack of Subgoal-level failure isolation.

[0064] When a single task node fails, VMAO relies on LangGraph's built-in retry or global exception handling and will not automatically identify and undo all downstream nodes that depend on the failed node, potentially causing some downstream nodes to be permanently blocked or idle. While A.DOT's DataOps System provides diagnostic and repair mechanisms, these primarily target planned error correction and retries and do not involve automatically undoing downstream dependent nodes.

[0065] Related Technology 5: Subgraph Nesting and Decentralized DAG.

[0066] LangGraph v1.0.7 introduces the Subgraph mechanism, allowing a graph node to be expanded into nested subgraphs. It implements hierarchical parallel scheduling based on the Pregel model and supports cyclic edges. D3X proposes a decentralized DAG execution architecture where each node only receives the output of its direct upstream dependencies as context (rather than the global context), achieving a 4x speedup and 37%-83% token savings. Google ADK 2.0 Alpha provides graph workflow combinations such as SequentialAgent, ParallelAgent, and LoopAgent. FIM One supports dynamic DAG generation via LLM and ReAct / DAG dual-mode runtime switching, based on asyncio concurrent execution. This approach has the following drawbacks: 1) Subgraph is an execution layer abstraction and does not have an independent planning-validation closed loop.

[0067] LangGraph's Subgraph simply breaks down complex nodes into smaller execution steps; it does not include a separate Tactical Planner or LLMVerifier. The steps within a Subgraph are still statically defined by the developer in the code and cannot be dynamically generated based on upstream results.

[0068] 2) D3X's dependency local context is only applicable to scenarios where the data flow is explicit.

[0069] D3X assumes that each node only needs to directly access the upstream output, but sub-goal-level planning (such as "generating an itinerary based on weather and attraction information") requires integrating the semantic results of multiple upstream sub-goals. D3X's local contextualization strategy cannot support this cross-domain semantic fusion requirement.

[0070] 3) Capability registration and executor registration are separated for each framework.

[0071] In LangGraph, the definition of a Tool (via the @tool decorator or ToolNode) and the description of an Agent's capabilities (written manually in the system prompt) are two separate configurations; similarly, the Agent capability declaration in the ADK is separated from the underlying tool definition. Modifying a tool requires simultaneous updates in multiple places, which can easily lead to inconsistencies.

[0072] 4) FIM One’s dual-mode switching increases runtime decision complexity.

[0073] The decision to switch between ReAct and DAG modes requires additional LLM calls or heuristic rule judgments, failing to fundamentally decouple planning from execution.

[0074] To address this, this application provides an agent workflow orchestration method that fundamentally decouples planning and execution, achieving separation of two-level DAG planning and execution. This reduces the inference complexity of the large language model invoked during agent workflow orchestration and improves orchestration efficiency. Furthermore, it implements a closed loop of planning-execution-verification-replanning.

[0075] After introducing the design concept of the embodiments of this application, the following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application can be applied. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.

[0076] refer to Figure 1 This diagram illustrates a system architecture for intelligent agent workflow orchestration, as provided in an embodiment of this application. A robot device 11 receives natural language commands from a user and sends these commands to an electronic device 12 on which intelligent agents are deployed. The electronic device 12 can be a computer or a server. The intelligent agents execute the workflow orchestration process, and the robot device executes the orchestration results. In practical applications, intelligent agents can also be deployed in the cloud; this is merely an example and does not constitute a specific limitation.

[0077] refer to Figure 2 This is a schematic diagram of the structure of an intelligent agent provided in an embodiment of this application. The intelligent agent includes combining the planning capabilities of LLM with a deterministic DAG execution engine to achieve a closed loop of Plan, Execute, Verify, and Replan.

[0078] Optionally, the intelligent agent includes a central scheduling unit 21 (AgentBrain), a strategic planner 22 (StrategicPlanner), a tactical planner 23 (TacticalPlanner), and a workflow execution engine 24 (WorkflowEngine), and may also include a registration unit (ToolRegistry). Figure 2 Not shown in the image. The following sections will introduce each component in detail: The registration unit, also known as the unified registration center, serves as the system's sole entry point for capabilities. A single registration generates tool definitions (ToolDef), executors (Executor), and capability domain information (Capability description).

[0079] Central Scheduling Unit: Orchestrates the global planning-execution-verify-replan closed loop, managing the concurrent execution, result verification, failure isolation, and full-process snapshot of SubGoals.

[0080] Strategic Planner: Receives user natural language commands and a list of system capability domains, and generates a SubGoalGraph (or simply SubGoal Graph) using LLM. Subgoal nodes only describe "what to achieve" (e.g., "check the weather"), and are not bound to specific tools.

[0081] The tactical planner receives a natural language description of a single sub-target and a structured execution result context from an upstream sub-target. It then uses an LLM (Limited Linear Model) to generate a directed acyclic graph (TaskGraph) within that sub-target. Task nodes are bound to specific tool types and parameters.

[0082] Workflow execution engine: A DAG scheduler based on asyncio event-driven architecture. It receives a task graph, automatically identifies ready tasks and starts concurrent execution, and supports exponential backoff retries and deadlock detection.

[0083] Of course, the methods provided in the embodiments of this application are not limited to... Figure 1 The application scenarios shown can also be used in other possible scenarios, and this application does not impose any limitations. Figure 1 The functions that each device in the application scenario shown can achieve will be described in subsequent method embodiments, and will not be elaborated on here.

[0084] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, the method may include more or fewer operation steps based on conventional or non-inventive methods. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application.

[0085] The following is combined Figure 1 and Figure 2 The application scenarios shown illustrate the technical solutions provided in the embodiments of this application.

[0086] refer to Figure 3 This application provides an intelligent agent workflow orchestration method, applied to an intelligent agent, which includes a central scheduling unit, a strategic planner, a tactical planner, and a workflow execution engine. The workflow orchestration method includes at least the following steps: S301: The central dispatch unit receives user instructions.

[0087] S302: The strategic planner generates a sub-target map based on user instructions.

[0088] S303: For each of the multiple sub-objectives, perform the following operation: S303-1: Generate the task graph corresponding to the sub-target based on the description information and context information of the sub-target.

[0089] S303-2: The workflow execution engine executes each of the multiple tasks in the task graph.

[0090] In this embodiment, upon receiving a user instruction, a sub-target graph is generated based on the user's execution. This sub-target graph includes multiple sub-target nodes and their dependencies. For each sub-target, a corresponding task graph is generated, including multiple task nodes and their dependencies. Then, each task in the task graph is executed. In this design, nodes in the sub-target graph are sub-targets, not bound to specific tools; in the task graph, sub-nodes are tasks, and nodes are specific tool calls. This decouples the planning and execution of the two-level directed acyclic graph (DAG) of the sub-target graph and task graph. On one hand, the layered architecture splits the agent workflow orchestration into two levels of logic, effectively reducing the inference complexity of the large language model during the orchestration stage and improving overall orchestration efficiency. On the other hand, the two-level planning mechanism reduces the frequency of LLM calls, further reducing the power consumption and response latency of the robot's edge computing device, while avoiding memory overflow and device resource conflicts in scenarios with unlimited concurrency.

[0091] Before executing the intelligent agent workflow orchestration method, a unified registration is performed first. Specifically, at system startup, developers register all available tools, Model Context Protocol (MCP) servers, and external Agent Servers through the ToolRegistry. Each registration simultaneously generates three pieces of data: capability domain information (including multiple sets of capability names and capability descriptions), tool information (tool name, tool parameters, and tool descriptions), and executor instances.

[0092] In addition, developers determine the correspondence between tool information and capability domain information during registration; that is, they specify the capability group to which the tool belongs. If not specified, the tool itself is an independent capability domain. All registration information is automatically output through the `registry.capabilities` and `registry.tool_defs` properties, eliminating the risk of inconsistencies from manually maintaining two sets of configurations.

[0093] Compared to related technologies where capability descriptions (for strategic-level LLMs) and tool definitions (for tactical-level LLMs) are maintained as two separate configurations, the unified registry center in this application makes capability and tool definitions originate from the same source. When modifying tool registration, the capability domain is automatically synchronized, eliminating the risk of inconsistencies in manual configuration.

[0094] Considering that existing frameworks all suffer from varying degrees of capability-tool separation issues—for example, LangGraph maintains separate tool definitions (@tool decorators) and capability descriptions in the Agent system prompt; Agent capability declarations are separated from underlying tool definitions; VMAO inherits the same separation problem based on LangGraph—this application's embodiment automatically outputs the capabilities and tool_defs attributes of a unified registry center, automatically synchronizing capability domains when modifying tool registration, thus eliminating the risk of inconsistency from a mechanism perspective. Specifically, ToolRegistry serves as the system's sole capability entry point, maintaining three dimensions simultaneously during a single registration: ToolDef (tool name, tool parameters, tool description information, and dependency hints, for use by the tactical layer LLM (second language model)), Executor (executor instance, for engine invocation), and Capability (capability domain name and description information, for use by the strategic layer LLM (first language model)).

[0095] Regarding S301, the central dispatch unit receives user commands, which are in natural language, such as "Please get me a bottle of water." After receiving the user command, the central dispatch unit generates a unique trace identifier (trace_id), which can be in UUID v7 format and includes a millisecond timestamp prefix. This trace identifier can be used for location tracking.

[0096] Regarding S302, the strategic planner obtains user instructions from the central scheduling unit and generates a sub-target map based on these instructions. This process can be achieved through steps A1-A3: A1: Determine the first prompt word that matches the user command.

[0097] The large model of the strategic planner is called the first language model. The capability domain information of the first language model indicates what the first language model can do. Combined with user instructions, the strategic planner injects capability domain information (such as a list of capability domains) into the system prompt words to obtain the first prompt word that matches the user instructions.

[0098] In a specific example, the first prompt could be "navigate to the location of the refrigerator, open the refrigerator door, and finally take out the water and close the refrigerator door."

[0099] A2: Based on the first prompt word, call the first language model to generate a sub-target graph according to the user's instructions.

[0100] Optionally, the sub-target graph includes multiple sub-target nodes and the dependencies between them. Each sub-target node stores the description information of its corresponding sub-target and a list of its upstream sub-target nodes. In a specific example, the description information includes an English identifier (id), a brief Chinese description (title), and a detailed natural language description (description); the list of upstream sub-target nodes includes a list of predecessor sub-target IDs (dependencies).

[0101] Taking "Please get me a bottle of water" as an example, the sub-goals can include navigating to the location of the refrigerator, opening the refrigerator door, taking out the water, and closing the refrigerator door.

[0102] A3: Perform a topological sorting check on the sub-target graph to determine that the sub-target graph is an acyclic graph and has no isolated vertices.

[0103] The generated sub-target graph is subjected to Kahn topology sorting verification by the strategic planner to detect cyclic dependencies and isolated nodes, and to determine that the sub-target graph is acyclic and has no isolated nodes.

[0104] In S303-1, the central scheduling unit enters the main loop, calling SubGoalGraph.get_ready() in each round to obtain ready sub-goals whose dependencies all meet the conditions, and dispatching them concurrently via asyncio.gather(). Sub-goals without dependencies (such as simultaneously "checking the weather" and "searching for attractions") are executed in parallel within the same round. For each sub-goal, a Plan-Execute-Verify-Replan loop is executed. For each sub-goal, the following steps B1-B2 are performed: B1: Based on the second prompt word, call the second language model to generate the task graph corresponding to the sub-target.

[0105] Optionally, the large model of the tactical planner is called the second language model, and the second prompt also incorporates the execution results of the upstream sub-targets. For example, the second prompt includes descriptive information of the sub-target and contextual information of the sub-target node (the contextual information is determined based on the execution results of the completed upstream sub-targets).

[0106] Specifically, the tactical planner receives the description information of the sub-targets as instructions, receives the execution results of all completed upstream sub-targets as structured context information (injected in JSON format via system prompt, rather than concatenated into the instructions), and generates a task graph through LLM.

[0107] The task graph includes multiple task nodes and the dependencies between them. Each task node stores tool information about the tool it is bound to and a list of its upstream subtasks. In other words, each task is bound to a specific tool type (task.type), parameters (task.params), and dependencies within the graph (task.dependencies).

[0108] Taking the sub-objective "navigating to the location of the refrigerator" as an example, the tasks corresponding to this sub-objective include sensing and scanning the indoor scene, identifying the refrigerator, calculating the spatial coordinates of the refrigerator, global path planning, real-time obstacle avoidance, movement control, distance verification, and stopping positioning.

[0109] Compared to Agent Loop's approach of appending the complete return result of each tool call to the message history, this application passes a structured context (dict format, containing only the result field of successful sub-targets) between sub-targets. The tactical planner's LLM references upstream results as needed, avoiding context window bloat and token waste caused by large tool return values ​​repeatedly entering the message history. Structured context passing avoids context window bloat.

[0110] In addition, to prevent the second language model from generating invalid or dangerous operations during the task graph generation process, a three-level protection verification process of the TaskBuilder is performed on the generated task graph. Optionally, this three-level protection verification process is as follows: First, for the Prompt layer, the system prompts should explicitly list the names of available tools, parameter definitions, and output format rules to constrain the output space of the LLM.

[0111] Secondly, for the parsing layer, defensive JSON extraction is performed on the text returned by LLM, supporting three modes: pure JSON, Markdown code block wrapping, and mixed text and JSON, ensuring correct parsing under various LLM output styles.

[0112] Furthermore, regarding the validation layer, a whitelist filtering mechanism only allows the use of registered tool names (the `tool` field must be in the `ToolDef` name set) and declared parameter names (the `key` in `args` must be in the corresponding tool's `ParamDef` whitelist). Parameters not in the whitelist are silently filtered. Simultaneously, the uniqueness of the task ID, the dictionary type of `args`, and the list type of `deps` are validated.

[0113] In this embodiment, a progressive relationship is formed through three levels of protection: the Prompt layer reduces the probability of LLM errors, the parsing layer catches up with format anomalies, and the verification layer serves as the final security barrier to ensure that no LLM output will generate calls to unregistered tools or inject illegal parameters.

[0114] B2: After obtaining the task graph, perform a topological sorting check on the task graph to determine that the task graph is an acyclic graph and has no isolated vertices.

[0115] Optionally, the generated task graph can be checked using the tactical planner with Kahn topology sorting to detect cyclic dependencies and isolated nodes, and to determine that the task graph is acyclic and has no isolated nodes.

[0116] This relates to each of the multiple tasks in the workflow execution engine's task graph in S303-2. The execution process of each task will be explained below.

[0117] The workflow execution engine receives the task graph, iterates through the Kahn algorithm to obtain ready tasks, and concurrently dispatches each ready task using `asyncio.create_task()`. The ExecutorRouter searches for registered executors by `task.type`. In a specific example, four executor types are supported: local functions (ToolExecutor), external agent services (AgentServiceExecutor), MCP protocol clients (automatically discovered via tools / list), and remote devices (RemoteExecutor).

[0118] The executor router is processed through a middleware pipeline before and after the call. The middleware uses a chained call pattern: multiple middlewares are nested and wrapped in the order of registration, with the outermost middleware processing the request first and the response last, and the innermost middleware closest to the actual executor call. Middleware can be used for cross-cutting concerns such as logging, time statistics, authentication, and metric collection, without modifying the executor itself. The engine supports a pluggable scheduler to control concurrency and resource allocation. The scheduler inserts a control layer between the "find executable tasks" and "create execution coroutines" steps in the main loop, providing two built-in implementations: Built-in implementation method 1: ConcurrencyScheduler, which schedules based on concurrency limits and priorities. It sorts tasks in ascending order by task.priority (the smaller the value, the higher the priority), and retrieves a maximum of (max_concurrent - running_count) tasks starting from the highest priority to prevent system overload.

[0119] Built-in implementation method 2: ResourceAwareScheduler, which adds resource capacity awareness on top of the concurrency limit. Tasks declare their required resources (such as Central Processing Unit (CPU), Graphics Processing Unit (GPU), and memory) via task.meta["resources"]. The scheduler maintains a resource capacity pool; resources are occupied by dispatched tasks and released via reconcile() after task completion. A local resource counter is maintained within the same scheduling round to ensure the correct calculation of the decreasing remaining amount, avoiding over-allocation.

[0120] Compared to the single-layer DAG of VMAO and A.DOT (where nodes simultaneously carry "target semantics" and "tool binding"), this application's two-layer DAG separates these two decision-making levels into different LLM calls. The strategic-layer LLM only needs to understand the capability domain (such as "weather query"), without needing to care about specific tool names and parameter formats; the tactical-layer LLM only needs to generate call chains based on specific tool definitions, without needing to understand the global target. This separation of concerns reduces the reasoning complexity of each LLM call.

[0121] Compared to LangGraph Subgraph, the nested graph of Subgraph is statically defined in the code and lacks the dynamic generation capability driven by LLM. The tactical layer DAG in this application is dynamically generated by the tactical planner based on the upstream execution results, and can generate different tool call graphs and dependencies for different inputs. (The task graph depends on the execution results of upstream sub-target nodes.)

[0122] Thus, this embodiment of the application achieves a two-level separation of DAG planning and execution. The strategic layer DAG (sub-goal graph) describes "what to do," with nodes representing sub-goals, not bound to specific tools, and is generated by the strategic planner using LLM based on the system's capability domain. The tactical layer DAG (task graph) describes "how to do it," with nodes representing specific tool calls, and is generated by the tactical planner using LLM based on tool definitions. Both layers of DAGs share the same Kahn topology sorting base class, but differ in decision-making level and dependency granularity. The dependency between strategic layer nodes expresses "goal A must be completed before goal B," while the dependency between tactical layer nodes expresses "the output of tool A is the input of tool B."

[0123] Based on the above technical solution, after the task is completed, a verification process and a completion process are also included. Optionally, the verification process can be implemented through steps C1-C2: C1: After all tasks in the task graph corresponding to the sub-target have been completed, the verifier generates evaluation information based on the description information of the sub-target, the execution results of each task, and the context information.

[0124] The evaluation information includes some or all of the completeness evaluation information, compliance information, missing dimension list, and supplementary suggestion information.

[0125] In a specific example, after all tasks within a sub-goal have been completed, an independent LLM validator (LLMVerifier) ​​receives the sub-goal's description information, the execution results of each task, and context information, and outputs an integrity score (0.0~1.0), whether it meets the standard (is_sufficient), a list of missing dimensions (gaps), and supplementary suggestions (suggestion).

[0126] C2: Update the first or second prompt word based on the evaluation information.

[0127] This includes verifying the first and second prompt words to avoid bias.

[0128] In addition, the completion process can be implemented as follows: if the completeness represented by the completeness score is less than the set completeness threshold, the LLM validator will send the supplementary suggestion information and the execution results of each task to the tactical planner, and the tactical planner will generate supplementary tasks and add them to the task graph to update the task graph.

[0129] Specifically, if the completeness is less than the set completeness threshold, the central scheduling unit will send a supplementary suggestion and the existing results (the execution results of each task) to the tactical planner to generate a supplementary task. This supplementary task is then added to the task graph and executed again. Completion is performed at most `max_verify_rounds` rounds (including the initial execution, meaning a maximum of `max_verify_rounds` verification checks) to avoid infinite loops. Results from multiple rounds are merged using a merging strategy: lists of the same type are merged to remove duplicates, nested dictionaries are recursively merged, and in case of value type conflicts, the later round overwrites the previous one.

[0130] This application's embodiment implements a closed loop of planning-execution-verification-replanning. Specifically, an independent verification phase is introduced after execution, using independent LLM calls to evaluate the completeness and quality of the execution results. Verification and execution failure handling constitute two non-overlapping paths: verification completion handles "execution successful but quality insufficient" (retaining the atomic goal and adding supplementary tasks), and StrategicPlanner.replan handles "execution failure beyond redemption" (redefining sub-goals).

[0131] In related technologies, VMAO's verification and replanning operate on the same DAG layer. When verification fails, the original DAG node is directly modified or a new node is added. In this application, the verification loop is located at the tactical layer (within the sub-target), while replanning is located at the strategic layer (across sub-targets). These two paths operate on data structures at different levels and do not interfere with each other. This layered closed-loop design ensures that "a single sub-target needs supplementary data" does not trigger a global replanning, avoiding unnecessary LLM calls and the loss of results from successfully completed sub-targets.

[0132] In addition, the embodiments of this application can also implement a three-level error classification system, mainly including the following three categories: UnrecoverableError: Errors such as incorrect LLM API key or non-existent model. For this type of error, do not retry and terminate the workflow directly.

[0133] RecoverableError: This error indicates a network timeout or temporary service unavailability. It can be recovered by backing down and retrying.

[0134] ResourceExhaustedError: All retries fail, the device is offline, or the set number of retries has been exceeded. It is unrecoverable but can trigger a replanning process.

[0135] In practical applications, for situations where task execution fails and sub-target execution fails, the method of this application embodiment achieves two-level failure isolation and layered error recovery. The specific implementation process is as follows: For each task, if a suspected task failure is detected, the task is re-executed based on an exponential backoff retry strategy. If the set number of retries is reached, the task is determined to have failed and the sub-target to which the task belongs has also failed.

[0136] During this process, the workflow execution engine automatically executes an exponential backoff retry strategy (controlled by `RetryPolicy`, where `delay = base_delay × 2^(retry_count - 1)`). Once the set number of retries is exhausted, the current task is marked as failed. This also helps determine if the sub-target containing the failed task has failed. Here, `delay` represents the interval between two retries, `base_delay` is the initial interval between two retries, and `retry_count` represents the set number of retries.

[0137] If a failed sub-target is detected, the downstream sub-targets that depend on the failed sub-target are identified and marked as canceled.

[0138] During this process, the central scheduling unit calls _cancel_blocked() in the main loop to automatically identify downstream sub-targets that depend on the failed sub-targets and mark them as canceled to avoid permanent blocking.

[0139] Since this application can be used in resource-constrained scenarios such as robotics and edge computing, it addresses the potential for memory overflow or device conflicts caused by unlimited concurrency. The ResourceAwareScheduler in this application manages resource capacity pools (limiting the number of retries) to ensure that resource consumption at any given time does not exceed the system limit, while maximizing resource utilization. Resource-aware scheduling prevents system overload.

[0140] Additionally, for cases where recoverable sub-targets fail, optimization can be performed through steps D1-D4: D1: Traverse the subtarget graph and find downstream subtarget nodes that directly or indirectly depend on the failed subtarget.

[0141] This involves recursively traversing the subtarget graph to find all downstream nodes that directly or indirectly depend on the failed subtarget (_find_downstream).

[0142] D2: Generate at least one alternative sub-target.

[0143] The second language model is invoked to generate one or more alternative sub-targets for the failed sub-targets. The second language model can choose to modify the original description of the failed sub-nodes to avoid the cause of failure, and can also split the atomic target into multiple sub-targets with finer granularity or adopt a degradation scheme.

[0144] In addition, the node that replaces the sub-target inherits the dependencies of the node of the sub-target that failed to execute, and maintains the relationship with the upstream sub-target node unchanged.

[0145] D3: Replace the dependencies of downstream sub-target nodes on failed sub-target nodes with dependencies on nodes that replace the failed sub-target nodes, resulting in an updated sub-target graph.

[0146] For example, downstream sub-target nodes are represented by M1, M2, and M3, respectively. The dependency relationship between downstream sub-target nodes and failed sub-target nodes means that M1, M2, and M3 are child nodes of the failed sub-target. After replacing the dependency relationship, M1, M2, and M3 become child nodes of the node that replaces the sub-target.

[0147] D4: Re-execute the topology sorting check on the updated sub-target graph to determine that the updated sub-target graph is an acyclic graph and has no isolated vertices.

[0148] Optionally, the Kahn topology sort check can be re-executed on the updated subtarget graph to ensure acyclic dependencies and orphan nodes.

[0149] To further improve the technical solution of this application, the following sections will explain the processes of end-to-end tracing, state persistence and breakpoint recovery, and workflow lifecycle management: End-to-end tracing: Each workflow generates a unique tracing identifier, which is injected into the Task.meta dictionary and all event data in the event bus. The event bus publishes three levels of events (workflow). / subgoal. / task. This covers the complete state transitions of the workflow lifecycle, including workflow.started / completed / failed, subgoal.started / planning / executing / verified / replanned / completed / failed, task.running / success / failed / cancelled / retrying / exhausted, etc.

[0150] State Persistence and Breakpoint Recovery: The system supports workflow state persistence through a state manager abstraction. The workflow execution engine automatically triggers a snapshot save whenever a task's state changes (task execution failure or success), serializing the task graph into a snapshot containing the state, results, and metadata of all task nodes. If the workflow is unexpectedly interrupted, the task graph can be restored from the most recent snapshot using `load_snapshot()`, skipping completed tasks and re-executing only tasks in the waiting or failed states. A default implementation based on a local JSON file (JSON state manager) is provided, which can be extended to a database or object storage backend.

[0151] Agent Brain provides workflow-level lifecycle management interfaces, the functions of which are as follows: `pause(workflow_id)` pauses the specified workflow, stopping the main loop after the current round's SubGoal is completed, while retaining all states. `resume(workflow_id)` resumes the paused workflow, continuing execution from the pause point. `cancel(workflow_id)` cancels the specified workflow, marking all unfinished subgoals as `CANCELLED`. `inspect(workflow_id)` displays the real-time status of the workflow, returning the total number of subgoals, as well as the number of completed, failed, pending, running, and paused subgoals.

[0152] In addition, the agent also supports global workflow timeout configuration, which generates a timeout message and terminates the workflow after a timeout to prevent it from running indefinitely.

[0153] The following specific examples illustrate the beneficial effects of this application: In summary, compared to the ReAct Agent Loop, which requires an LLM call for each step, this application only requires one strategic planning and N tactical planning (N being the number of sub-objectives, which can be concurrent). The execution and verification phases do not call the LLM (verification uses an independent LLM call, triggered only when the result may be incomplete). Taking "checking the weather + searching for attractions + generating an itinerary" as an example, the Agent Loop requires approximately 3-4 LLM calls, while this application also requires approximately 3. However, when the transaction complexity increases to 5-10 tool calls per sub-objective, the Agent Loop's call count multiplies, while this application maintains only 3 calls. This significantly reduces the cost of LLM calls.

[0154] Furthermore, related technologies often lack concurrency capabilities (serial agent loops) or only offer single-layer concurrency (DAG engines are task-level only). This application implements two levels of concurrency: sub-target level and task level. Dependent sub-targets execute in parallel, and independent tasks within each sub-target also execute in parallel. When there are two independent sub-targets, and each sub-target has three independent tasks, theoretically all six tasks can execute simultaneously. Therefore, this two-level concurrency improves execution efficiency.

[0155] like Figure 4 As shown, based on the same inventive concept as the above-described intelligent agent workflow orchestration method, this application embodiment also provides an intelligent agent workflow orchestration device, which includes a data transmission module 41 and a data processing module 42.

[0156] Data transmission module 41 is used for: receiving user instructions; Data processing module 42 is used to: generate a sub-target graph according to user instructions; wherein the sub-target graph includes multiple sub-target nodes and the dependencies between the multiple sub-target nodes; each sub-target node stores the description information of the corresponding sub-target and a list of upstream sub-target nodes of the sub-target node; The data processing module 42 is also used to: generate a task graph corresponding to the sub-target based on the description information and context information of the sub-target; and execute each of the multiple tasks in the task graph. The task graph includes multiple task nodes and the dependencies between them; each task node stores tool information of the corresponding task-bound tool and a list of upstream subtasks of the task node; the context information is determined based on the execution results of the upstream subtasks of the completed subtasks.

[0157] In one alternative implementation, the data processing module 42 is specifically used for: Determine the first prompt word that matches the user command; wherein, the first prompt word includes capability domain information of the first language model; Based on the first prompt word, the first language model is invoked to generate a sub-target map according to the user's instructions; Perform a topological sorting check on the sub-target graph to determine that the sub-target graph is an acyclic graph and has no isolated vertices.

[0158] In one alternative implementation, the data processing module 42 is specifically used for: Based on the second prompt word, the second language model is invoked to generate the task graph corresponding to the sub-target; wherein, the second prompt word includes the description information of the sub-target and the context information of the sub-target node; Perform a topological sort check on the task graph to determine that the task graph is an acyclic graph and has no isolated vertices.

[0159] In an optional implementation, the data processing module 42 is further configured to: After all tasks in the task graph corresponding to the sub-goal have been completed, evaluation information is generated based on the description information of the sub-goal, the execution results of each task, and the context information. The evaluation information includes some or all of the completeness evaluation information, achievement information, missing dimension list, and supplementary suggestion information. Update the first and / or second prompt words based on the evaluation information.

[0160] In an optional implementation, the data processing module 42 is further configured to: If the completeness score indicates a completeness level less than the set completeness threshold, supplementary tasks are generated based on supplementary suggestions and the execution results of each task. These supplementary tasks are then added to the task graph to update it.

[0161] In an optional implementation, the data processing module 42 is further configured to: For each task, if a suspected task failure is detected, the task is re-executed based on an exponential backoff retry strategy. If the set number of retries is reached, the task is determined to have failed and the sub-target to which the task belongs has also failed. If a failed sub-target is detected, the downstream sub-targets that depend on the failed sub-target are identified and marked as canceled.

[0162] In an optional implementation, the data processing module 42 is further configured to: Traverse the subtarget graph to find downstream subtargets that directly or indirectly depend on the failed subtargets; Generate at least one alternative sub-goal; wherein the nodes of the alternative sub-goal inherit the dependencies of the nodes of the sub-goal that failed to execute; The dependencies of downstream sub-target nodes on failed sub-target nodes are replaced with dependencies on alternative sub-target nodes, resulting in an updated sub-target graph. Re-execute the topology sorting check on the updated sub-target graph to confirm that the updated sub-target graph is an acyclic graph and has no isolated vertices.

[0163] In an optional implementation, the data processing module 42 is further configured to: determine capability domain information, tool information, and executor instance before receiving user instructions; wherein the capability domain information includes multiple sets of capability names and capability description information, and the tool information includes tool name, tool parameters, and tool description information; Determine the correspondence between tool information and capability domain information.

[0164] The intelligent agent workflow orchestration device proposed in this application adopts the same inventive concept as the above-described intelligent agent workflow orchestration method and can achieve the same beneficial effects, which will not be repeated here.

[0165] Based on the same inventive concept as the aforementioned intelligent agent workflow orchestration method, this application also provides an electronic device on which an intelligent agent can be deployed. Specifically, this electronic device can be a desktop computer, portable computer, smartphone, tablet computer, personal digital assistant (PDA), server, etc. Figure 5 As shown, the electronic device may include a processor 501 and a memory 502.

[0166] Processor 501 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0167] Memory 502, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. Memory 502 in this embodiment may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0168] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned computer storage medium can be any available medium or data storage device that a computer can access, including but not limited to: mobile storage devices, random access memory (RAM), magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)) and other media capable of storing program code.

[0169] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a 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 methods of the various embodiments of this application. The aforementioned storage medium includes: mobile storage devices, random access memory (RAM), magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs), etc.) and other media capable of storing program code.

[0170] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the intelligent agent workflow orchestration methods discussed above. Since the principle by which the above-described computer program product solves the problem is similar to that of the intelligent agent workflow orchestration method, the implementation of the above-described computer program product can refer to the implementation of the method, and repeated details will not be described again.

[0171] The above embodiments are only used to provide a detailed description of the technical solutions of this application. However, the description of the above embodiments is only for the purpose of helping to understand the methods of the embodiments of this application and should not be construed as a limitation on the embodiments of this application. Any changes or substitutions that can be easily conceived by those skilled in the art should be covered within the protection scope of the embodiments of this application.

Claims

1. A method for orchestrating intelligent agent workflows, characterized in that, include: Receive user instructions and generate a sub-target graph according to the user instructions; wherein, the sub-target graph includes multiple sub-target nodes and the dependencies between the multiple sub-target nodes; each sub-target node stores the description information of the corresponding sub-target and a list of upstream sub-target nodes of the sub-target node; For each of the multiple sub-objectives, perform the following operation: Based on the description information and context information of the sub-target, a task graph corresponding to the sub-target is generated; each task in the multiple tasks in the task graph is executed. The task graph includes multiple task nodes and dependencies between them; each task node stores tool information of the corresponding task-bound tool and a list of upstream subtasks of the task node; the context information is determined based on the execution results of the upstream subtasks of the completed subtasks.

2. The method according to claim 1, characterized in that, The step of generating a sub-target map according to the user instruction includes: Determine a first prompt word that matches the user instruction; wherein the first prompt word includes capability domain information of a first language model; Based on the first prompt word, the first language model is invoked to generate a sub-target map according to the user instruction; Perform a topological sorting check on the sub-target graph to determine that the sub-target graph is an acyclic graph and has no isolated vertices.

3. The method according to claim 1, characterized in that, The step of generating a task graph corresponding to the sub-target based on the description information and context information of the sub-target includes: Based on the second prompt word, the second language model is invoked to generate the task graph corresponding to the sub-target; wherein, the second prompt word includes the description information of the sub-target and the context information of the sub-target node; A topological sorting check is performed on the task graph to determine that the task graph is an acyclic graph and has no isolated vertices.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: After all tasks in the task graph corresponding to the sub-target have been completed, evaluation information is generated based on the description information of the sub-target, the execution results of each task, and the context information; wherein, the evaluation information includes some or all of the completeness evaluation information, achievement information, missing dimension list, and supplementary suggestion information. Update the first prompt word and / or the second prompt word based on the evaluation information.

5. The method according to claim 4, characterized in that, The method further includes: If the completeness score represents a completeness level less than a set completeness threshold, then a supplementary task is generated based on the supplementary suggestion information and the execution results of each task, and the supplementary task is added to the task graph to update the task graph.

6. The method according to claim 1, characterized in that, The method includes: For each task, if the task is suspected of failing, the task is re-executed based on an exponential backoff retry strategy. If the set number of retries is reached, the task and the sub-target to which the task belongs are determined to have failed. If a failed sub-target is detected, downstream sub-targets that depend on the failed sub-target are identified and marked as canceled.

7. The method according to claim 6, characterized in that, The method further includes: Traverse the subtarget graph to find downstream subtargets that directly or indirectly depend on the subtarget that failed to execute; Generate at least one alternative sub-target; wherein the nodes of the alternative sub-target inherit the dependencies of the nodes of the failed sub-target; The dependencies of the downstream sub-target nodes on the failed sub-target nodes are replaced with dependencies on the alternative sub-target nodes to obtain the updated sub-target graph. The updated sub-target graph is re-executed with topology sorting to determine that the updated sub-target graph is an acyclic graph and has no isolated vertices.

8. The method according to claim 1, characterized in that, Prior to receiving the user instruction, the method further includes: Determine capability domain information, tool information, and executor instances; wherein, the capability domain information includes multiple sets of capability names and capability descriptions, and the tool information includes tool name, tool parameters, and tool descriptions; Determine the correspondence between tool information and capability domain information.

9. An intelligent agent based on a two-level directed acyclic graph, characterized in that, This includes a central scheduling unit, a strategic planner, a tactical planner, and a workflow execution engine; The central dispatch unit is used to: receive user instructions; The strategic planner is configured to: generate a sub-target graph according to the user instructions; wherein the sub-target graph includes multiple sub-target nodes and dependencies between the multiple sub-target nodes; each sub-target node stores description information of the corresponding sub-target and a list of upstream sub-target nodes of the sub-target node; The tactical planner is configured to: for each of a plurality of sub-targets, perform the following operation: generate a task graph corresponding to the sub-target based on the description information and context information of the sub-target; The workflow execution engine is configured to perform the following operation for each of the multiple sub-goals: execute each of the multiple tasks in the task graph; The task graph includes multiple task nodes and dependencies between them; each task node stores tool information of the corresponding task-bound tool and a list of upstream subtasks; the context information is determined based on the execution results of the upstream subtasks of the completed subtasks.

10. A smart agent workflow orchestration device, characterized in that, include: The data transmission module is used to: receive user commands; The data processing module is configured to: generate a sub-target graph according to the user instruction; wherein the sub-target graph includes multiple sub-target nodes and the dependencies between the multiple sub-target nodes; each sub-target node stores the description information of the corresponding sub-target and a list of upstream sub-target nodes of the sub-target node; The data processing module is further configured to: generate a task graph corresponding to the sub-target based on the description information and context information of the sub-target; and execute each of the multiple tasks in the task graph. The task graph includes multiple task nodes and dependencies between them; each task node stores tool information of the corresponding task-bound tool and a list of upstream subtasks of the task node; the context information is determined based on the execution results of the upstream subtasks of the completed subtasks.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

12. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When executed by a processor, the computer program instructions implement the steps of the method according to any one of claims 1 to 8.

Images