A multi-agent collaboration method and system based on task decomposition and state synchronization, and a storage medium

Abstract

This invention provides a multi-agent collaborative method, system, and storage medium based on task decomposition and state synchronization. The method includes: Step 1: Dynamically decomposing the input high-level complex task into executable sub-task units, responding to re-decomposition requests during runtime, and inputting control block objects into the cooperative scheduler; Step 2: Managing the lifecycle of all task control block objects, binding them to appropriate agent execution units, sending task execution instructions to the agent execution units, and sending re-decomposition requests to the task decomposer; Step 3: Receiving task control block execution instructions from the cooperative scheduler and publishing state events to the state synchronization bus; Step 4: Receiving structured state events sent by agent execution units and pushing the state events to subscribers; Step 5: Receiving all state events from the state synchronization bus and responding to all state query requests. The beneficial effect of this invention is that it provides powerful underlying support for various complex agent applications.

Description

Technical Field

[0001] This invention relates to the field of general multi-agent collaboration, and in particular to a multi-agent collaboration method, system, and storage medium based on task decomposition and state synchronization. Background Technology

[0002] In the field of general multi-agent collaboration, current mainstream collaborative architectures mainly draw on the design ideas of workflow automation platforms. Their core is to use a central controller to statically orchestrate and drive multiple predefined execution units (i.e., agents) to complete complex tasks. Typical examples of such platforms include: SOAR (Security Orchestration, Automation, and Response) platform: widely used in the cybersecurity field. The core of the SOAR platform is the "playbook." Security analysts pre-define repetitive, standardized security response processes (such as blocking IPs and isolating files) into playbooks. These playbooks are fixed, linear, or task flowcharts with simple branches. When a security event (such as a SIEM alert) triggers the playbook, SOAR's central orchestration engine strictly follows the order defined in the playbook, sequentially calling different security tools or agents (such as EDR, firewalls, and email gateways) to execute subtasks (such as isolating hosts, blocking IPs, and notifying users). The entire process is open-loop and forward-driven; once the playbook is started, its structure cannot be dynamically adjusted based on new states during task execution.

[0003] General-purpose workflow engines (such as Apache Airflow) are widely used in data engineering and automated operations. Airflow allows users to define complex directed acyclic graphs (DAGs) using Python code to represent task dependencies. Its scheduler monitors the status of each task in the DAG and distributes subsequent tasks to executors after the preceding tasks have successfully completed. Although Airflow's DAG is more expressive than SOAR playbooks (supporting complex dependencies), its task decomposition remains static. The topology of the DAG is fixed when the workflow instance starts and cannot be reconstructed at runtime based on agent execution results or environmental changes.

[0004] The two types of technologies mentioned above represent the current mainstream paradigm for workflow orchestration and multi-agent collaboration: a central controller coordinates multiple agents based on a predefined, static workflow. This model is very effective when dealing with well-structured and predictable processes. However, current workflows are essentially a centralized, open-loop control model, where task decomposition logic and task execution status are disconnected.

[0005] Despite the success of the aforementioned existing technologies in their respective fields, when applied to general multi-agent cooperative scenarios requiring high dynamism, strong adaptability, and deep state coupling, the following fundamental shortcomings are exposed: Defect 1: The task decomposition mechanism lacks dynamic reconfiguration capabilities. Existing technologies (such as SOAR scripts and Airflow DAG) involve task decomposition before task execution, generating a static and immutable task dependency graph. During execution, this dependency graph is unaware of the dynamic context of task execution. If an agent fails due to insufficient resources, the execution result is not as expected, or there is a sudden change in the external environment (e.g., a critical data source becomes unavailable), the system cannot locally reconstruct or dynamically re-decompose the original task graph. The entire collaborative process is often interrupted. The system cannot autonomously bypass failure points, reallocate tasks, or adjust dependencies between tasks, resulting in low efficiency and insufficient robustness in multi-agent collaboration. This severely restricts the application of multi-agent systems in nondeterministic environments.

[0006] Defect 2: The state synchronization mechanism suffers from semantic gaps and timeliness bottlenecks. In existing architectures, state sharing among agents is often implicit, non-standardized, or entirely reliant on a central controller. For example, Airflow uses the XCom mechanism to transfer small amounts of data between tasks, but this requires developers to explicitly code read / write logic and makes it difficult to guarantee state consistency and timeliness. More commonly, agents only report their own state to the central controller, lacking an efficient, direct, and semantically clear state synchronization channel. This results in each agent's "global state view" being incomplete, outdated, and potentially semantically ambiguous. Making collaborative decisions based on this incomplete or outdated state information (such as conditional triggering or resource contention arbitration) can easily lead to decision errors, task conflicts, or deadlocks, thereby reducing the overall system's collaborative accuracy and reliability.

[0007] Defect 3: The separation of scheduling decisions from state storage creates a decision blind spot. The central controller (scheduler) primarily bases its decisions on static task dependencies and pre-defined scheduling strategies (such as FIFO and priority queues). It cannot efficiently access an authoritative, consistent global state store in real time to obtain dynamic feedback during task execution (such as task progress, agent load, and intermediate output quality), preventing the scheduling logic from achieving true state-aware scheduling. For example, the scheduler might mistakenly preempt a critical, uninterruptible, high-cost task because it is unaware that a low-priority task is about to complete successfully, causing unnecessary context switching overhead and resource waste. The scheduler, state store, and task executors are loosely coupled, ultimately failing to form a tightly integrated "cooperative kernel" like an operating system kernel.

[0008] The information disclosed in this background section is intended only to enhance understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0009] To address the problems in the prior art, this invention provides a multi-agent collaborative method, system, and storage medium based on task decomposition and state synchronization.

[0010] This invention provides a multi-agent cooperative method based on task decomposition and state synchronization, comprising: Step 1, Task Decomposition: The task decomposer dynamically decomposes the input high-level composite task into executable sub-task units, responds to re-decomposition requests at runtime, and then inputs one or more task control block objects into the cooperative scheduler; the high-level composite task includes the high-level task T submitted by the user and the re-decomposition request from the cooperative scheduler. Step 2, Cooperative Scheduling: The cooperative scheduler manages the lifecycle of all task control block objects and binds them to appropriate intelligent agent execution units, sends task execution instructions to intelligent agent execution units, and sends re-decomposition requests to the task decomposer; all task control block objects include task control block objects from the task decomposer and task control block object state change events from the global state cache. Step 3, Agent Execution: The agent execution unit receives the task control block execution instructions from the cooperative scheduler and publishes state events to the state synchronization bus; Step 4, State Synchronization: The state synchronization bus receives the structured state events sent by the intelligent agent execution unit and pushes the state events to the subscribers; Step 5, Global State Cache: The global state cache receives all state events from the state synchronization bus, responds to all state query requests, and ensures that all modules access a consistent global view.

[0011] As a further improvement of the present invention, step 1 further includes: Step 10, Initial decomposition: Decompose the high-level task T into an initial TCB-DAG; Step 11, Dynamic Re-decomposition: Upon receiving the re-decomposition request, locate the failed task control block and its upstream dependencies, and reconstruct only the local subgraph to generate a new subset of task control blocks.

[0012] As a further improvement of the present invention, in step 1, the re-decomposition request includes the failed TCB ID and the reason.

[0013] As a further improvement of the present invention, step 2 further includes: Step 20, Maintain the queue: including: Maintain a ready queue: The ready queue is used to store task control blocks whose dependencies have been satisfied and whose status is ready; Maintain the running queue: The running queue is used to store task control blocks that are in a running state; Maintaining a blocking queue: The blocking queue is used to store task control blocks that are blocked due to unmet dependencies or insufficient resources; Step 21, Scheduling Loop: Periodically select task control blocks from the ready queue according to priority, match them with idle agent execution units according to their capability set, move the task control blocks into the running queue, and notify the agent to start execution. Step 22, Exception Handling: Monitor the task control block in the run queue. If no status update is received within the timeout period or an indication of task execution failure is received, initiate a re-decomposition request to the task decomposer.

[0014] As a further improvement of the present invention, in step 2, when the task state changes, the intelligent agent execution unit publishes an event, the event including at least the identifier of the task and the changed state information.

[0015] As a further improvement of the present invention, in step 3, when the task state changes to meet the triggering conditions set by the synchronization strategy according to the synchronization strategy field of the task control block, a status event is published through the status synchronization bus.

[0016] As a further improvement of the present invention, the intelligent agent execution unit actively queries the global state cache before executing the current task to obtain the context information required to execute the task.

[0017] As a further improvement of the present invention, in step 4, the state synchronization bus adopts a publish-subscribe model, each task control block contains a task identifier, the task identifier is used as the topic of the event publication corresponding to the task, and the state synchronization bus routes the event to all modules that have subscribed to the task identifier.

[0018] As a further improvement of the present invention, step 5 further includes: Maintain a key-value database where the task identifier is the key and the task control block status is the value. Upon receiving an event, the corresponding task control block state is atomically updated using the task identifier carried by the event as the key. A first query interface and a second query interface are provided. The first query interface is used to obtain the status of the task control block corresponding to a specified task identifier, and the second query interface is used to obtain the status of all task control blocks.

[0019] The present invention also discloses a multi-agent cooperative system based on task decomposition and state synchronization, comprising: a memory, a processor, and a computer program stored in the memory, wherein the computer program is configured to implement the steps of the multi-agent cooperative method of the present invention when invoked by the processor.

[0020] The present invention also discloses a computer-readable storage medium storing a computer program configured to implement the steps of the multi-agent cooperative method described in the present invention when invoked by a processor.

[0021] The beneficial effects of this invention are: To address the first deficiency, this invention utilizes the TCB as a unified carrier and a closed-loop feedback mechanism between the task decomposer and scheduler to achieve dynamic task re-decomposition. The system no longer crashes due to partial failures but can adaptively adjust the task flow, significantly improving robustness and task success rate.

[0022] Regarding defect two: This invention ensures the efficiency (transmitting only changes) and accuracy (semantic clarity) of state information transmission through structured TCB definitions and incremental state synchronization buses. The global state cache, as a single source of truth, completely resolves the state inconsistency problem.

[0023] To address the third defect, the cooperative scheduler directly reads the latest and most authoritative state information from the global state cache to make scheduling decisions, truly realizing state-aware scheduling and optimizing resource utilization and task response time.

[0024] In summary, this invention constructs an efficient, robust, and adaptive multi-agent collaborative framework, providing powerful underlying support for various complex agent applications. Attached Figure Description

[0025] Figure 1 This is the system architecture diagram of the present invention. Detailed Implementation

[0026] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings, but it should be understood that the scope of protection of the present invention is not limited to the specific embodiments.

[0027] Unless otherwise expressly stated, throughout the specification and claims, the term "comprising" or its variations such as "including" or "comprises" shall be understood to include the stated elements or components without excluding other elements or other components.

[0028] This invention discloses a multi-agent collaborative method based on task decomposition and state synchronization. Its core lies in abandoning the traditional static workflow model under a central controller and instead constructing a decentralized, state-driven, closed-loop feedback collaborative kernel. This kernel introduces a Task Control Block (TCB) as a unified carrier of tasks and states, and establishes deep linkage between the collaborative scheduler and the global state cache, achieving dynamic task decomposition, efficient state synchronization, and precise state-aware scheduling.

[0029] like Figure 1 As shown, this invention discloses a multi-agent cooperative method based on task decomposition and state synchronization, comprising: Step 1, Task Decomposition: The Task Decomposer is responsible for dynamically decomposing high-level composite tasks into executable subtask units and responding to re-decomposition requests at runtime.

[0030] enter: a) High-level task T submitted by the user; b) Re-decomposition request from the co-scheduler (including the failed TCB ID and reason).

[0031] Processing logic: Step 10, Initial Decomposition: Parse T into an initial TCB-DAG. Each TCB contains structured metadata (see below).

[0032] Step 11, Dynamic Refactoring: Upon receiving a refactoring request, locate the failed TCB and its upstream dependencies, and reconstruct only the local subgraph (e.g., replace the failed agent type, split the oversized task, add an alternative path) to generate a new subset of TCBs.

[0033] Output: One or more Task Control Block (TCB) objects.

[0034] TCB data structure definition: TCB = { "task_id": "Unique string ID", "dependencies": ["List of IDs of the preceding TCBs"], "required_capabilities": {"gpu": true, "os": "linux"}, / / Agent capability requirements "priority": 5, / / Scheduling priority "state": "READY", / / Current state: READY / RUNNING / BLOCKED / COMPLETED / FAILED "output_schema": {"type": "object", "properties": {...}}, / / Expected output JSON Schema "sync_policy": "event_driven" / / Synchronization strategy: event_driven / periodic(5s) } Step 2, Collaborative Scheduling: The Collaborative Scheduler, as the core of the collaborative kernel, manages the lifecycle of all TCBs and binds them to the appropriate agent execution units.

[0035] enter: a) TCB from the task decomposer; b) TCB state change events from the global state cache.

[0036] Processing logic: Maintain a tri-state queue: 1) Ready Queue: Stores TCBs that satisfy all dependencies and whose state is READY.

[0037] 2) Running Queue: Stores TCBs with the current state=RUNNING.

[0038] 3) Blocked Queue: Stores TCBs whose dependencies are not met or whose state is blocked due to insufficient resources.

[0039] 2. Scheduling loop: Periodically select TCBs from the ready queue according to priority, match them with idle agent execution units according to their required_capabilities, move the TCBs into the run queue, and notify the agent to start execution.

[0040] 3. Exception Handling: Monitor the TCBs in the run queue. If no status update is received within a timeout period or a FAILED status is received, initiate a re-decomposition request to the task decomposer.

[0041] Output: Sends task execution instructions to the agent execution unit; sends a re-decomposition request to the task decomposer.

[0042] Step 3, Agent Execution: The Agent Executor specifies the specific task execution entity.

[0043] Input: TCB execution instructions from the coordinating scheduler.

[0044] Processing logic: 1. Execute the task logic specified by TCB.

[0045] 2. Based on the sync_policy in the TCB, publish status events through the status synchronization bus at appropriate times (such as task completion, progress update).

[0046] 3. Before execution, the global state cache can be actively queried to obtain the required context.

[0047] Output: Publish status events to the status synchronization bus.

[0048] Step 4, State Synchronization: The State Sync Bus provides an efficient, reliable, and incremental channel for transmitting state information; Input: Structured state events from the agent's execution unit.

[0049] Processing logic: 1) A publish-subscribe model is adopted. Each TCB's task_id is a topic.

[0050] 2) When the task state changes, the intelligent agent execution unit publishes an event Event = { "topic": task_id,"payload": { "new_state": "...", "output": {...}, "timestamp": 1700000000}}.

[0051] 3) The bus routes events to all modules that have subscribed to the task_id (mainly the coordinator and the global state cache).

[0052] Output: Push state events to subscribers.

[0053] Step 5, Global State Cache: The Global State Cache serves as the system's unique and authoritative state store, ensuring that all modules access a consistent global view.

[0054] Input: All status events from the status synchronization bus.

[0055] Processing logic: 1) Maintain a key-value database KVStore<task_id, TCB_State> .

[0056] 2) Upon receiving an event, atomically update the corresponding TCB_State using task_id as the key.

[0057] 3) Provide query interfaces for GetState(task_id) and GetAllStates().

[0058] Output: Status query requests from modules such as the coordinated scheduler.

[0059] The present invention also discloses a multi-agent cooperative system based on task decomposition and state synchronization, comprising: a memory, a processor, and a computer program stored in the memory, wherein the computer program is configured to implement the steps of the multi-agent cooperative method of the present invention when invoked by the processor.

[0060] The present invention also discloses a computer-readable storage medium storing a computer program configured to implement the steps of the multi-agent cooperative method described in the present invention when invoked by a processor.

[0061] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A multi-agent cooperative method based on task decomposition and state synchronization, characterized in that, include: Step 1, Task Decomposition: The task decomposer dynamically decomposes the input high-level composite task into executable sub-task units, responds to re-decomposition requests at runtime, and then inputs one or more task control block objects into the cooperative scheduler; the high-level composite task includes the high-level task T submitted by the user and the re-decomposition request from the cooperative scheduler. Step 2, Cooperative Scheduling: The cooperative scheduler manages the lifecycle of all task control block objects and binds them to appropriate intelligent agent execution units, sends task execution instructions to intelligent agent execution units, and sends re-decomposition requests to the task decomposer; all task control block objects include task control block objects from the task decomposer and task control block object state change events from the global state cache. Step 3, Agent Execution: The agent execution unit receives the task control block execution instructions from the cooperative scheduler and publishes state events to the state synchronization bus; Step 4, State Synchronization: The state synchronization bus receives the structured state events sent by the intelligent agent execution unit and pushes the state events to the subscribers; Step 5, Global State Cache: The global state cache receives all state events from the state synchronization bus, responds to all state query requests, and ensures that all modules access a consistent global view.

2. The multi-agent cooperative method according to claim 1, characterized in that, Step 1 also includes: Step 10, Initial decomposition: Decompose the high-level task T into an initial TCB-DAG; Step 11, Dynamic Re-decomposition: Upon receiving the re-decomposition request, locate the failed task control block and its upstream dependencies, reconstruct only the local subgraph, and generate a new subset of task control blocks.

3. The multi-agent cooperative method according to claim 1, characterized in that, In step 1, the re-decomposition request includes the failed TCB ID and the reason.

4. The multi-agent cooperative method according to claim 1, characterized in that, Step 2 also includes: Step 20, Maintain the queue: including: Maintain a ready queue: The ready queue is used to store task control blocks whose dependencies have been satisfied and whose status is ready; Maintain the running queue: The running queue is used to store task control blocks that are in a running state; Maintaining a blocking queue: The blocking queue is used to store task control blocks that are blocked due to unmet dependencies or insufficient resources; Step 21, Scheduling Loop: Periodically select task control blocks from the ready queue according to priority, match them with idle agent execution units according to their capability set, move the task control blocks into the running queue, and notify the agent to start execution. Step 22, exception handling: Monitor the task control block in the run queue. If no status update is received within the timeout period or an indication of task execution failure is received, initiate a re-decomposition request to the task decomposer. In step 2, when the task state changes, the intelligent agent execution unit publishes an event, which includes at least the identifier of the task and the changed state information.

5. The multi-agent cooperative method according to claim 1, characterized in that, In step 3, a status event is published through the status synchronization bus when the task status changes in accordance with the synchronization policy field of the task control block and the triggering conditions set by the synchronization policy are met.

6. The multi-agent cooperative method according to claim 1, characterized in that, Before executing the current task, the intelligent agent execution unit will actively query the global state cache to obtain the context information required to execute the task.

7. The multi-agent cooperative method according to claim 1, characterized in that, In step 4, the state synchronization bus adopts a publish-subscribe model. Each task control block contains a task identifier, which is used as the topic for the event publication corresponding to the task. The state synchronization bus routes the event to all modules that have subscribed to the task identifier.

8. The multi-agent cooperative method according to claim 1, characterized in that, Step 5 also includes: Maintain a key-value database where the task identifier is the key and the task control block status is the value. Upon receiving an event, the corresponding task control block state is atomically updated using the task identifier carried by the event as the key. A first query interface and a second query interface are provided. The first query interface is used to obtain the status of the task control block corresponding to a specified task identifier, and the second query interface is used to obtain the status of all task control blocks.

9. A multi-agent cooperative system based on task decomposition and state synchronization, characterized in that, include: A memory, a processor, and a computer program stored on the memory, the computer program being configured to implement the steps of the multi-agent cooperative method of any one of claims 1-8 when invoked by the processor.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program configured to implement the steps of the multi-agent cooperative method according to any one of claims 1-8 when invoked by a processor.

Images