Multi-agent indirect collaborative scheduling method and system based on blackboard architecture

Abstract

This invention discloses a multi-agent indirect collaborative scheduling method and system based on a blackboard architecture, belonging to the field of artificial intelligence multi-agent scheduling technology. This invention constructs a project-level shared blackboard containing three types of protocol objects: facts, intentions, and prompts. The scheduler reads the blackboard graph state at fixed intervals and dynamically dispatches three types of tasks: guidance, reasoning, and exploration. Execution units obtain task context through the scheduler and return structured results; there is no direct communication between units. Automatic fault takeover is achieved through a heartbeat lease mechanism, and hierarchical timeout management is adopted for different tasks. A unified driver interface is used to adapt to heterogeneous AI backends. This invention eliminates the need for predefined roles and workflows, decouples the reasoning and execution processes, and exhibits excellent fault tolerance and concurrent scalability, effectively improving the execution efficiency and system stability of complex tasks.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence multi-agent scheduling technology, and in particular to a multi-agent indirect cooperative scheduling method and system based on a blackboard architecture. Background Technology

[0002] With the rapid iteration of Large Language Model (LLM) technology, agents built based on LLMs have acquired the ability to autonomously analyze, plan, and execute tasks. Multi-agent collaborative systems have also become a research hotspot in the field of artificial intelligence. Current mainstream multi-agent frameworks, such as the automatically generated pre-trained Transformer general agent (AutoGPT), the CrewAI framework, and the LangGraph framework, still face several technical bottlenecks when handling open-ended, goal-oriented, and complex tasks. These bottlenecks are as follows:

[0003] First, roles and processes are rigid, resulting in insufficient adaptive scheduling capabilities. Existing multi-agent frameworks typically predefine fixed roles for agents, such as reconnaissance agents, vulnerability analysis agents, and exploit agents, and hard-code the task execution process into the system as a static workflow. When the actual state of the target system does not match the pre-defined process, the system cannot dynamically adjust the task direction and execution strategy, which can easily lead to task failure or generate a large amount of redundant exploration behavior, resulting in poor task adaptability.

[0004] Second, the deep coupling between reasoning and execution makes it difficult to support long-duration tasks. Existing agent frameworks typically mix situational reasoning, step planning, and actual execution within a single agent invocation process. In scenarios with long execution times, such as full-port network scanning and deep vulnerability exploitation, operations often take several minutes to tens of minutes. A single large language model session is prone to timeouts and context window exhaustion, and it cannot support multiple execution units to advance tasks in parallel, resulting in low task execution efficiency and a high failure rate.

[0005] Third, the lack of persistent shared protocol state and task takeover mechanisms results in insufficient recovery capabilities for execution unit failures. Most existing multi-agent systems store task context, execution progress, and exploration direction in a single session or temporary workflow state. When a single agent crashes, a long task times out, or a container exits abnormally, completed exploration results are easily lost. The corresponding task can usually only be restarted or recovered through manual intervention, lacking automatic takeover capabilities based on shared state. The system has poor fault tolerance and cannot meet the requirements for long-term stable operation.

[0006] Fourth, direct communication between agents leads to inefficient concurrent scheduling. In existing frameworks, multiple agents typically coordinate via direct message passing, which incurs significant communication overhead in large-scale concurrent scenarios and makes it difficult to effectively avoid conflicts such as duplicate task exploration and resource contention. System throughput cannot increase linearly with the number of agents, making it difficult to support large-scale parallel exploration by agents.

[0007] In summary, existing multi-agent scheduling schemes cannot simultaneously meet the requirements of adaptive scheduling without predefined processes, decoupling of inference and execution to support long-term tasks, fault takeover based on persistent shared state, and high-concurrency indirect coordination. Therefore, there is an urgent need to propose a new multi-agent collaborative scheduling scheme to solve the above technical problems. Summary of the Invention

[0008] To address the shortcomings of existing technologies, the present invention aims to provide a multi-agent indirect cooperative scheduling method and system based on a blackboard architecture.

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] A multi-agent indirect cooperative scheduling method based on a blackboard architecture includes the following steps:

[0011] S1. Construct a project-level shared blackboard, write the starting and ending facts of the project to be processed as fact nodes into the shared blackboard, and establish three types of protocol objects in the shared blackboard: facts, intentions, and prompts, and initialize the scheduling and running environment;

[0012] S2. The scheduler reads the current graph status of the shared blackboard at fixed time intervals, and dynamically selects and assigns guiding tasks, reasoning tasks and exploration tasks based on whether the project is in the initial state, whether there are new facts or new hints, and whether there are unclaimed exploration intentions.

[0013] S3. After obtaining the task context through the scheduler, the execution unit reads the complete status information of the shared blackboard, executes the corresponding task and returns the structured objective result. The scheduler or the shared blackboard writing interface normalizes the result and writes it to the shared blackboard. The execution units do not communicate directly with each other and do not directly rewrite the protocol status.

[0014] S4. Each claimed task is bound to the identifier of the corresponding execution unit. The scheduler sends a heartbeat signal at a fixed period to maintain the claimed status of the task. When the heartbeat times out, the execution unit identifier of the corresponding task is automatically cleared and the task is reset to the claimable status.

[0015] S5. A two-stage timeout mechanism is adopted for guidance and exploration tasks. If the task is completed within the main execution phase, the execution result is returned directly. If the main execution phase times out, the execution context is retained and the summary phase is entered. The completed execution content is extracted and the corresponding result is output. A single-stage timeout mechanism is adopted for reasoning tasks. Invalid planning results are not written after the timeout.

[0016] Preferably, the fact object is used to record the observed objective state or task result, the intent object is used to record the direction to be explored, the declared state, the identifier of the claimed execution unit and the last heartbeat time, and the prompt object is used to record external expert suggestions, user prompts or supplementary clues injected by the scheduler.

[0017] Preferably, the triggering condition for the guidance task is that there are only starting facts and ending facts in the shared blackboard or the project has not yet completed its initial attempt; the triggering condition for the reasoning task is that new facts, new hints, or the goal achievement status needs to be determined in the shared blackboard, or there is no unclaimed exploration intent in the current project; the triggering condition for the exploration task is that there is an unclaimed exploration intent in the shared blackboard.

[0018] Preferably, the reasoning task corresponds to situation judgment, target achievement determination and exploration intention generation operations, and the exploration task corresponds to specific exploration operations; the same execution unit can be configured to execute one or more task types according to its task type capability, and different execution units can also undertake different tasks according to task type, driving type or concurrency quota.

[0019] Preferably, tasks from different projects are scheduled in parallel, with existing projects taking priority over new projects in dispatching tasks, and the number of running tasks within the same project and the total number of running tasks globally do not exceed the preset maximum concurrency limit for the project and the maximum concurrency limit globally, respectively.

[0020] A multi-agent indirect cooperative scheduling system based on a blackboard architecture includes a shared blackboard service module, a scheduler module, multiple execution unit modules, a declaration lease management module, a heartbeat management module, and a timeout processing module;

[0021] The shared blackboard service module serves as the source of project status truth, and is connected to the scheduler module for data storage. It stores start-up facts, end-up facts, fact objects, intent objects, prompt objects, task running status, and execution history data according to the project.

[0022] The scheduler module is signal-connected to the shared blackboard service module and each execution unit module. It reads the graph state of the shared blackboard service module at fixed intervals, generates guidance tasks, reasoning tasks and exploration tasks according to conditional scheduling rules, and writes the execution results, generation intentions and task states back to the shared blackboard service module as a protocol in the control plane.

[0023] The execution unit module receives task snapshots or prompts dispatched by the scheduler module, calls the corresponding artificial intelligence backend and tool environment to execute the task, and returns the structured execution results to the scheduler module. There is no direct data connection between the execution unit modules.

[0024] The lease management module and heartbeat management module work together with the scheduler module to bind the execution unit identifier, lease status and last heartbeat time to the claimed exploration intention or running task. When the heartbeat times out, the corresponding claimed status is released and reset to the pending claim status.

[0025] Preferably, the timeout handling module is signal-connected to the scheduler module and the execution unit module, and performs two-stage timeout control for the guidance task and the exploration task: tasks completed in the main execution stage directly return the results, and tasks that time out in the main execution stage retain the execution context and enter the summary stage to extract the completed content; single-stage timeout control is performed for the reasoning task, and the corresponding task is terminated after the timeout and no invalid planning results are written.

[0026] Preferably, the conditional scheduling rules of the scheduler module include: prioritizing the dispatch of guidance tasks for initial projects; prioritizing the dispatch of reasoning tasks when there are new facts, new hints, or target states that need to be determined in the shared blackboard; dispatching exploration tasks when there are unclaimed exploration intentions in the shared blackboard and the project concurrency quota allows; and prioritizing the advancement of running projects during cross-project scheduling, subject to global concurrency threshold limitations.

[0027] Preferably, the execution unit module is configured with a task type capability set, driver type, basic priority, maximum concurrency and health status, and the scheduler module selects the execution unit based on task type matching, concurrency limit, health status, cooldown status, basic priority, number of currently running tasks and random disturbances.

[0028] Preferably, all execution unit modules are connected to the system through a unified driver interface, which includes methods for health checks, task execution, session identifier extraction, summary phase triggering, and structured output of results, and supports hybrid deployment of various command-line or interface-based artificial intelligence backends.

[0029] Compared with the prior art, the beneficial effects of the present invention are:

[0030] This invention does not require pre-defining intelligent agent roles and task workflows. It can autonomously and dynamically generate and advance tasks based solely on the start and end points. It can flexibly adjust the exploration direction based on real-time exploration results and is adaptable to various open-ended, goal-oriented tasks.

[0031] This invention, by completely decoupling reasoning and exploration tasks and combining a two-stage timeout and session retention mechanism, effectively avoids session timeout and context loss problems caused by long-term execution, supports the stable operation of long-term exploration tasks, and significantly improves the success rate of tasks.

[0032] This invention achieves execution unit-level fault tolerance through lease acceptance and heartbeat mechanisms. When a single execution unit crashes, the corresponding task is automatically reset to a pending state and taken over by other execution units. The task history is still retained in the shared blackboard, effectively reducing the task interruption rate.

[0033] This invention employs an indirect coordination mechanism based on a shared blackboard, where execution units do not need to communicate directly. The scheduler only performs task declaration, lease maintenance, and result writing based on the shared protocol status. Multiple execution units can explore in parallel under concurrent quota constraints, significantly improving overall exploration efficiency.

[0034] This invention supports unified access to multiple heterogeneous large language model backends through a unified driver interface abstraction. It can flexibly select the optimal intelligent agent backend according to the task type and adapt to the task requirements of different fields without modifying the core scheduling architecture. Attached Figure Description

[0035] Figure 1 This is the overall architecture diagram of the multi-agent indirect cooperative scheduling system based on blackboard architecture described in this invention;

[0036] Figure 2 This is a flowchart illustrating the multi-agent indirect cooperative scheduling method based on blackboard architecture described in this invention. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0038] The shared blackboard described in this invention refers to the unique project-level protocol state carrier in the system. It uses a graph structure composed of facts, intentions, and prompts to store task input information, intermediate exploration results, external prompts, directions to be explored, target states, and execution history. Fact objects represent objective states that have been observed or executed; intention objects represent exploration directions that can be claimed by executable units; and prompt objects represent supplementary clues injected by users, external experts, or the scheduler. All execution units obtain a snapshot of the shared blackboard through the scheduler and return structured results. Protocol state updates are completed by the scheduler or the shared blackboard write interface, eliminating the need for direct communication between execution units. The guidance task described in this invention refers to a one-time overall attempt task triggered in the initial stage of the project; the reasoning task refers to the task responsible for situation assessment, goal achievement determination, and exploration intention generation; and the exploration task refers to the task responsible for executing specific exploration operations and generating objective factual results.

[0039] Example 1: Example of a multi-agent indirect cooperative scheduling method based on blackboard architecture

[0040] like Figure 2 As shown, this embodiment takes a web-based penetration testing challenge in the Capture The Flag (CTF) cybersecurity challenge as an example, and implements the steps from S1 to S5 in sequence. The specific process is as follows:

[0041] S1. Construct a shared blackboard and initialize the scheduling runtime environment:

[0042] This step completes the construction of the globally shared blackboard, the writing of basic project information, and the full initialization of the system's operating environment, providing basic support for subsequent task scheduling.

[0043] First, a project-level shared blackboard is constructed, and the starting and ending facts of the competition problem to be processed are written into the shared blackboard to mark the completion status: the starting fact is the Uniform Resource Locator (URL) of the target website, and the ending fact is the flag string of the target system. In the initial state, there is no other intermediate data in the blackboard.

[0044] In the shared blackboard data model, starting and ending facts are written as project initialization facts; open ports, service versions, directory paths, vulnerability verification results, etc., generated during execution are written as fact objects; directions to be verified generated by inference tasks are written as intent objects; and clues supplemented by users or experts are written as prompt objects. Fact objects, intent objects, and prompt objects form a traceable project state diagram through project identifiers, source identifiers, timestamps, and associated task identifiers.

[0045] Simultaneously complete the full initialization configuration of the system runtime environment:

[0046] Hardware and system environment: A general-purpose cloud server is used, configured with a 4-core CPU, 8GB of RAM, and Ubuntu 22.04 LTS operating system. The AI ​​backend can be accessed using command-line or interface-based intelligent agent tools, such as Claude Code driver, OpenAI Codex driver, simulation driver, or other intelligent agent backends that support command-line calls, without the need to fix specific model implementations in the core scheduling layer.

[0047] Execution Unit Container Environment: All execution units run in independent containers. The container base image is ubuntu:22.04, and it comes pre-installed with common security testing tools such as network mapping tool (nmap), structured query language injection tool (sqlmap), directory brute-force tool (gobuster), and network request tool (curl). The container environments of different projects are completely isolated to avoid resource and data interference.

[0048] Core scheduling parameter configurations: scheduling loop interval, global maximum number of execution units, maximum number of concurrently running projects, maximum number of concurrent execution units per project, health check timeout duration, maximum number of newly created exploration intents per round, and various task timeout parameters are all set in a configurable manner; in one embodiment, the scheduling loop interval is set to 3 seconds, the global maximum number of execution units is 8, the maximum number of concurrently running projects is 3, the maximum number of concurrent execution units per project is 4, the health check timeout duration is 20 seconds, the guidance task and exploration task adopt a two-stage timeout of 300 seconds for the main stage and 90 seconds for the summary stage, and the reasoning task adopts a single-stage timeout of 300 seconds.

[0049] S2. The scheduler reads the blackboard status at fixed intervals and dynamically generates and dispatches three types of tasks:

[0050] In this step, the scheduler operates at fixed time intervals, sequentially performing five operations in each scheduling cycle: harvesting completed tasks, synchronizing project status, canceling inactive tasks, cleaning up container resources, and dispatching new tasks. Based on the real-time status of the shared blackboard, three types of tasks are dynamically generated and dispatched according to priority rules. The scheduling interval also serves as the heartbeat detection period; both reuse the same system clock, requiring no additional parameter settings.

[0051] Task priority and concurrency constraints:

[0052] Task scheduling employs conditional priority rules rather than fixed linear priority. Initial projects prioritize triggering introductory tasks; when new facts, hints, or target states require determination on the shared blackboard, or when there are no unclaimed exploration intentions in the current project, reasoning tasks are prioritized to determine whether the target has been achieved and generate new exploration intentions; exploration tasks are triggered when there are unclaimed exploration intentions on the shared blackboard and the project concurrency quota allows. Across project dimensions, unfinished tasks in running projects are prioritized before scheduling new project tasks; both within the same project and at the global level, concurrency constraints apply.

[0053]

[0054] in, Indicates the first The total number of tasks currently running in each project. This represents the preset maximum number of concurrent tasks for a single project, which is set to 2 in this embodiment. The global concurrency constraint satisfies the following formula:

[0055]

[0056] in, This indicates the total number of projects in the current system. This represents the maximum number of concurrent tasks globally, which is set to 5 in this embodiment.

[0057] Triggering rules for the three types of tasks:

[0058] Protocol object state rules: Once a fact object is written, it serves as the objective input for subsequent reasoning and exploration; intent objects transition between unclaimed, claimed, completed, and released states, carrying the execution unit identifier, claim time, last heartbeat time, and lease status; prompt objects can be injected by users, external experts, or the scheduler to trigger new situational assessments. The scheduler, as the protocol state control plane, performs unified verification of fact writing, intent generation, claim / release, and project completion status.

[0059] The scheduler reads the shared blackboard status in real time and triggers corresponding tasks based on different blackboard statuses, without the need for predefined workflows.

[0060] Guided task: The trigger condition is that there are only starting facts and ending facts in the shared blackboard, and no intermediate exploration results or exploration directions, that is, the project is in the initial state.

[0061] Reasoning task: The trigger condition is that there are no exploration tasks to be executed in the current project, and new situation information appears in the shared blackboard, including newly written fact data, newly injected external expert suggestions, or all ongoing exploration tasks have been completed; at most one reasoning task can run at the same time within a single project, which is guaranteed by the project-level lease mechanism to avoid redundant planning.

[0062] Exploration task: The trigger condition is that there is an exploration direction to be executed in the shared blackboard.

[0063] Execution Unit Selection Algorithm:

[0064] Before each task is dispatched, the scheduler filters candidate execution units according to four criteria: task type matching, current number of running tasks not exceeding the limit, normal health status, and no cooldown penalty. After filtering, the final execution unit is selected based on a three-level ranking system: basic priority, current number of running tasks, and random disturbance. The formula for calculating the comprehensive ranking score of the execution unit is as follows:

[0065]

[0066] in:

[0067] The comprehensive scheduling score of the execution unit is a dimensionless relative score. The higher the score, the higher the priority of the execution unit being selected. This score is only used for the relative ranking among candidate execution units and has no physical dimension meaning.

[0068] The basic priority of an execution unit is a dimensionless relative score pre-configured by the system for each execution unit. When assigning values ​​on the same rating scale, a larger value indicates a higher basic priority.

[0069] This represents the number of tasks currently running in this execution unit.

[0070] A random perturbation value between 0 and 1 is used to break the ranking tie when the scores of each candidate execution unit are similar, thereby achieving load balancing.

[0071] , , These are weighting coefficients used to map the above three items to the same dimensionless scoring scale. In this embodiment, they are taken as 1, 0.5, and 0.1, respectively.

[0072] In the above formula, Basic priority scoring items; As a load penalty item, the more tasks an execution unit is currently running, the more points it will lose in this item, thus prioritizing the selection of execution units with lighter loads; This is a random disturbance term. The three terms are weighted and standardized to dimensionless scores before being summed. There are no dimensional conflicts between the terms. It serves only as a relative basis for the scheduling and ordering of execution units.

[0073] After selecting an execution unit, the system enforces a health check using the health check method in the unified driver interface to verify the reachability of the corresponding large language model interface. The health check employs the following methods depending on the type of backend adapted to the execution unit:

[0074] For the interface-based large language model backend, the scheduler sends a lightweight Hypertext Transfer Protocol (HTP) probe request to the large language model service address configured for the execution unit via the driver interface. For example, it may request the model list interface or send a test completion request containing only a very small number of tokens, and waits for a response within the configured health check timeout period. If a normal HTP response with a status code of 200 is received within the health check timeout period, the large language model interface is determined to be reachable and the execution unit is in good health. If a connection refusal, a HTP 5xx error, or no response is received within the health check timeout period, the interface is determined to be unreachable.

[0075] For the command-line-based large language model backend, the scheduler initiates a lightweight call with a timeout parameter as a child process within the execution unit's container via the driver interface. This could be, for example, executing a version query command for the corresponding driver or a single call command with a fixed short prompt. The scheduler then waits for the child process to exit within the health check timeout period. If the child process exits normally within the health check timeout period with an exit code of 0, the interface is considered reachable. If the child process fails to start, exits with a non-zero exit code, or fails to exit within the timeout period, the interface is considered unreachable.

[0076] Only after the health check is passed will the scheduler officially dispatch a task to the execution unit; if the health check fails, the execution unit is marked as temporarily unselectable in a cooldown state, the current task dispatch is invalidated, and the next scheduling cycle will reselect an execution unit for retry. After the cooldown period ends, the execution unit will rejoin the candidate selection process. In this embodiment, the health check timeout is set to 20 seconds.

[0077] In one task dispatch in this embodiment, after the scheduler selects an execution unit adapted to Claude Code through four-fold filtering, it executes a lightweight call command with a timeout parameter in the execution unit container through the driver interface. The child process exits normally within the 20-second health check timeout period with an exit code of 0. Based on this, the scheduler determines that the large language model interface is reachable and then formally dispatches an exploration task to the execution unit. In another round of scheduling, an execution unit adapted to the OpenAI Codex model fails to receive a response to the health check probe within 20 seconds due to a network failure. The scheduler determines that the interface is unreachable, marks the execution unit as a cooldown state, and cancels this dispatch. In the next round of scheduling, other execution units with normal health status are dispatched. After the network is restored and the cooldown period ends, the execution unit re-participates in the candidate selection.

[0078] The execution unit can be configured with a set of task type capabilities; the same execution unit can support bootstrapping, inference, and exploration tasks simultaneously, or it can support only one or two of these tasks. When dispatching tasks, the scheduler first determines whether the task type capability set matches, and then makes a selection based on a combination of health status, concurrency quota, basic priority, and the number of currently running tasks.

[0079] S3. Each execution unit reads the blackboard status, executes the task, and writes the result back to the blackboard. There is no direct communication between units.

[0080] In this step, after the execution unit receives the corresponding task dispatched by the scheduler, it obtains the task context by reading a complete snapshot of the shared blackboard, performs the corresponding operation, and returns a structured result to the scheduler. The scheduler normalizes, verifies, and deduplicates the structured result, and then writes the objective facts, generation intent, goal achievement status, or execution history into the shared blackboard. The execution units do not communicate directly with each other and do not directly call the shared blackboard protocol interface. Instead, they achieve indirect coordination through the shared blackboard. Each execution unit independently executes an Observe-Orient-Decide-Act (OODA) loop around the shared state.

[0081] In this embodiment, the specific execution and iteration processes of the three types of tasks are as follows:

[0082] Guided task execution: The execution unit reads the start and end information from the shared blackboard, directly attempts to complete the entire problem-solving task in one go, and calls the large language model to combine the target URL information to perform overall detection and vulnerability testing, covering multiple dimensions such as port scanning, directory detection, and basic vulnerability detection.

[0083] First round of inference task execution: After the introductory task ends, the scheduler detects new facts, new hints, or target states that need to be determined on the blackboard, and since the project-level inference lease is not occupied, the inference task is triggered. The execution unit reads the complete state of the shared blackboard, analyzes the discovered open port information, determines that the target has not yet been achieved, and then generates two exploration intentions: one is to perform service fingerprinting on the open ports, and the other is to perform directory traversal scanning on the website. After the scheduler verifies the two intentions, they are written to the shared blackboard.

[0084] The first round of exploration task execution: The scheduler detects two unclaimed exploration intentions in the shared blackboard, and the concurrency limit for a single project has not been reached. It then declares and assigns exploration tasks to both intentions sequentially. The two exploration tasks can be undertaken in parallel by execution units of the same or different types. The first execution unit is responsible for port service fingerprinting, using nmap for deep scanning; the second execution unit is responsible for directory scanning, using gobuster for directory brute-force. After completing their operations, the two execution units return objective results such as service type, version number, and directory path, which are then written to the shared blackboard by the scheduler.

[0085] Multi-round iterative process: After the scheduler detects the completion of the exploration task and the addition of service version and directory path to the shared blackboard, it triggers the inference task again. The execution unit analyzes the newly written information, identifies a known vulnerability in the service version, and generates exploration intents for vulnerability verification and exploitation. The scheduler deduplicates and limits the number of new intents before dispatching the corresponding exploration task. The execution unit calls relevant tools to attempt vulnerability exploitation. After successfully obtaining the flag string of the target system, it returns the result, which is then written to the shared blackboard by the scheduler.

[0086] Task Completion Determination: After the scheduler detects that the exploration task is completed or a new key fact appears on the blackboard, it triggers the reasoning task. The execution unit reads the latest state from the shared blackboard, confirms that the flag string has been obtained, meets the endpoint fact requirements, outputs the conclusion that the goal has been achieved, and the scheduler marks the project as completed based on this.

[0087] S4. The task is bound to the execution unit identifier, and the heartbeat maintains the claimed status. After timeout, it is reset to the pending claim status.

[0088] In this step, each claimed exploration intent or running task is bound to a unique identifier, lease status, and last heartbeat time of the corresponding execution unit. In each scheduling cycle, the scheduler sends a heartbeat signal to the execution unit corresponding to the running task to maintain the task's claimed status; if the heartbeat times out, it releases the corresponding execution unit identifier and lease status, resetting the task or intent to a pending claim state, thus achieving execution unit-level fault takeover.

[0089] The formula for determining heart rate timeout is:

[0090]

[0091] in, The current system time. This is the time when the corresponding task last received a valid heartbeat response. The heartbeat timeout duration threshold is set to 3 times the scheduling interval, i.e., 15 seconds, in this embodiment.

[0092] In this embodiment, the second execution unit responsible for directory scanning crashes due to network fluctuations and stops responding to heartbeats. After a heartbeat timeout, the system automatically releases the execution unit identifier bound to the exploration intent and resets the directory scanning intent to an unclaimed state. Subsequently, the third idle execution unit claims the intent, reads the existing scanning progress and historical data from the shared blackboard, continues to complete the remaining directory scanning work, and finally returns the complete directory path information to the scheduler and writes it to the shared blackboard. All execution history data of the task is permanently retained in the shared blackboard, supporting complete audit trails.

[0093] S5. Long-running tasks employ a two-stage timeout mechanism, consisting of a main execution phase and a summary phase:

[0094] This step employs a two-stage timeout mechanism for two types of long-duration tasks: guidance tasks and exploration tasks. This prevents the loss of all completed work due to task timeouts and ensures the effectiveness of long-duration task execution.

[0095] The two-stage timeout operation logic is as follows: The first stage is the main execution stage, where the execution unit performs the exploration task normally. If it is completed within the timeout period, the complete execution result is returned directly. If the main execution stage times out, the current large language model conversation context is retained, and the second stage, the summary stage, is entered. The execution unit is forced to summarize the completed work and conclusions, and no new exploration is carried out. After extracting the completed execution content, the corresponding results are output and written to the shared blackboard.

[0096] The formula for calculating the total maximum runtime of the bootstrapping task is:

[0097]

[0098] in, To guide the total maximum runtime of the task, To guide the timeout duration of the main execution phase of the task, this embodiment uses a value of 600 seconds; To guide the timeout duration of the task summary phase, this embodiment uses a value of 120 seconds.

[0099] The formula for calculating the total maximum runtime of an exploration mission is:

[0100]

[0101] in, To explore the total maximum runtime of the task, To explore the timeout duration of the main execution phase of the task, this embodiment uses a value of 600 seconds; To explore the timeout duration of the task summary phase, this embodiment uses a value of 120 seconds.

[0102] In this embodiment, if the guidance task is not completed when it reaches the main phase timeout threshold, it automatically enters the summary phase. During the summary phase, the execution unit organizes the discovered target server open port information, returns it to the scheduler, and writes it to the shared blackboard, ensuring that the completed probing work is not lost and providing basic information for subsequent inference and exploration tasks. The inference task adopts a single-phase timeout mechanism; after timeout, the task is directly invalidated, and no content is written to the shared blackboard, avoiding invalid information interfering with subsequent scheduling.

[0103] In this embodiment, the total solution time for a single problem is approximately 12 minutes, requiring no manual intervention throughout. Automatic takeover occurs after a unit failure, without affecting the overall task progress. Actual testing shows that, under the same hardware and large language model conditions, this method significantly improves problem-solving stability and significantly reduces the failure rate of long-duration tasks. Compared to multi-agent systems using predefined static processes, it demonstrates clear advantages in both problem-solving speed and task success rate.

[0104] Example 2: Example of a multi-agent indirect cooperative scheduling system based on blackboard architecture

[0105] like Figure 1 As shown in the figure, this embodiment details the specific architecture, module functions, and operating mechanism of the multi-agent indirect cooperative scheduling system based on blackboard architecture described in this invention.

[0106] System overall architecture:

[0107] This system adopts a layered architecture, consisting of five layers from top to bottom: user interaction layer, service layer, scheduling layer, execution unit layer, and model interface layer. The shared blackboard service module in the service layer is the sole source of project state truth. The scheduler module in the scheduling layer acts as the task control plane and protocol writer. The execution units in the execution unit layer only receive task snapshots dispatched by the scheduler and return structured results. There are no direct communication links between the execution units, implementing an indirect coordination mechanism based on shared state.

[0108] Detailed explanation of the functions of each module:

[0109] Shared blackboard module:

[0110] The shared blackboard service module, deployed at the service layer, is the core of the system's project state storage. It is responsible for storing all data related to the project's start and end points, fact objects, intent objects, prompt objects, task running status, lease claims, heartbeat times, and execution history. The shared blackboard service module ensures data consistency and persistent storage, providing the scheduler module with unified interfaces for status reading, claiming, heartbeat renewal, claim release, fact writing, intent writing, and project completion status updates.

[0111] The shared blackboard service module isolates data by project, with each project corresponding to an independent blackboard space, ensuring data from different projects does not interfere with each other. The module supports atomic writes, intent deduplication, state transition verification, and lease status verification to avoid data conflicts caused by concurrent writes from multiple execution units. All data written to the blackboard includes a timestamp, source identifier, and associated task identifier, supporting complete operation traceability and auditing.

[0112] Scheduler module:

[0113] The scheduler module, deployed at the scheduling layer, is the system's task control plane. It is responsible for reading the graph state of the shared blackboard service module at fixed intervals, dynamically generating tasks according to conditional scheduling rules, and dispatching them to the execution unit layer. The scheduler module operates at fixed time intervals, performing the following operations in each cycle: harvesting completed tasks, synchronizing the latest status of each project, releasing inactive claims that have timed out, cleaning up completed container resources, and dispatching new tasks to be executed.

[0114] The scheduler module incorporates conditional scheduling logic. Initial projects are prioritized for introductory tasks. When new facts, hints, or target states require determination on the shared blackboard, or when the current project has no unclaimed exploration intentions, inference tasks are prioritized. Exploration tasks are assigned when there are unclaimed exploration intentions on the shared blackboard and the project's concurrency quota allows. During cross-project scheduling, tasks from already running projects are processed first, followed by tasks from new projects. Within a single project, concurrency limits are used to prevent excessive system resource consumption by a single project.

[0115] The scheduler module also has a built-in execution unit selection algorithm. Before each task is dispatched, candidate execution units are first screened according to four conditions: task type matching, concurrency limit, health status, and cooldown status. Then, the final execution unit is selected through a weighted sorting algorithm to achieve optimal resource allocation.

[0116] Heartbeat Management Module:

[0117] The heartbeat management module works in conjunction with the scheduler module to maintain the task claiming status and the liveness detection of execution units. After each task is claimed by an execution unit, the heartbeat management module binds it to the corresponding execution unit identifier and records the task claiming time and the last heartbeat response time.

[0118] In each scheduling cycle, the heartbeat management module sends heartbeat detection signals to the execution units corresponding to all running tasks, receives heartbeat responses from the execution units, and updates the last heartbeat time. When a task heartbeat timeout is detected, the heartbeat management module notifies the scheduler to release the execution unit binding identifier of that task or intent, resetting it to a pending state, allowing other execution units to take over again. This mechanism achieves execution unit-level fault tolerance, eliminating the need for mutual monitoring between execution units; a failure of a single execution unit will not affect the overall task progress.

[0119] Timeout handling module:

[0120] The Declaration Lease Management Module is responsible for the claiming, renewal, release, and state transition of intent objects and running tasks. Before the scheduler dispatches an exploration task, it first performs an atomic claiming of unclaimed intents in the Shared Blackboard Service Module, writing the execution unit identifier, claiming time, and lease information. During operation, the lease is periodically renewed through the Heartbeat Management Module. When a task is completed, fails, times out, or the heartbeat fails, the Declaration Lease Management Module marks the intent as completed, failed, or re-released to a pending claim state according to the state transition rules.

[0121] The timeout handling module manages the runtime of all tasks, implementing a two-stage timeout mechanism. For bootstrapping and exploration tasks, the timeout handling module sets two timeout thresholds: a main execution phase and a summary phase. When the task runtime reaches the main phase timeout threshold, the timeout handling module triggers a phase switching instruction, forcing the task to enter the summary phase. It retains the current execution context, requiring the execution unit to only summarize completed work and refrain from new exploration. If the summary phase also times out, the task is forcibly terminated and resources are reclaimed.

[0122] For inference tasks, the timeout handling module adopts a single-stage timeout mechanism. Once the timeout threshold is reached, the task is terminated directly without writing any content to the shared blackboard, thus avoiding invalid planning results from interfering with system scheduling.

[0123] Multiple execution unit modules:

[0124] The execution unit module is deployed at the execution unit layer. Each execution unit runs in an independent container environment, with resource isolation based on the project. The execution unit module is responsible for receiving task snapshots or prompts dispatched by the scheduler, calling the underlying AI backend and tool environment to complete specific inference or execution operations, and returning structured results to the scheduler module. The execution unit module does not directly declare intents, send heartbeats, or directly call the shared blackboard writing interface.

[0125] The system supports the mixed deployment of multiple types of execution units, with different types of execution units adapting to different large language model backends. This embodiment includes three types of execution units: the first type is adapted to Claude Code-driven, supports two-stage session recovery, and is suitable for long-term deep exploration tasks; the second type is adapted to OpenAI Codex-driven, and is suitable for code exploration tasks; the third type is simulation-driven, used for system self-testing and stress testing, and supports probabilistic result simulation.

[0126] All execution units connect to the system through a unified driver interface. The interface definition includes standard methods such as health checks, task execution, session identifier extraction, summary phase triggering, and structured result output. When adding a new AI backend, only the corresponding driver interface needs to be implemented to connect to the system; no modification to the core scheduling logic is required, demonstrating excellent scalability.

[0127] Each execution unit corresponds to an independent set of concurrency quota parameters and task type capabilities, including the maximum number of tasks running simultaneously, basic priority, and executable task types. The system can control the resource allocation ratio of different backends through parameter configuration to achieve hybrid scheduling and load balancing. The same execution unit can support bootstrapping, inference, and exploration tasks simultaneously, or it can support only one or two of these tasks.

[0128] User interaction module:

[0129] The user interaction module is deployed in the user interaction layer, providing two interaction methods: a web user interface (Web UI) and a command-line interface (CLI). It supports user operations such as creating projects, viewing task progress, browsing exploration results, and configuring system parameters. The user interaction module interacts with the shared whiteboard through the service layer interface, synchronizing project running status in real time.

[0130] System operation mechanism:

[0131] During system operation, users create projects and submit start and end point information through the interactive module. This data is written to the shared blackboard as initial facts to complete initialization. The scheduler module scans the shared blackboard graph status at fixed intervals, generates tasks of the corresponding type according to task triggering rules, and assigns them to appropriate execution units through an execution unit selection algorithm.

[0132] After receiving a task, the execution unit reads a complete snapshot of the shared blackboard provided by the scheduler, invokes the large language model and tool environment to complete the inference or execution operations corresponding to the task, and returns a structured result to the scheduler. There is no direct communication between the execution units; all information exchange is completed indirectly through the shared blackboard, i.e., a pheromone-based indirect coordination mechanism is adopted.

[0133] Each execution unit independently executes an Observe-Orient-Decide-Act (OODA) loop around a task snapshot: First, it observes and reads the current state and external information of the shared blackboard; then, it adjusts and analyzes known information to clarify the exploration boundaries; next, in the inference task, it makes decisions to judge the achievement of the goal and generates exploration intentions; finally, in the exploration task, it performs specific operations and returns the results. This mechanism allows multiple execution units to work in parallel under the constraints of a shared protocol state, while the scheduler is responsible for deduplication, claiming, state transitions, and writing back the results.

[0134] When an execution unit malfunctions, the heartbeat management module detects a heartbeat timeout and automatically resets the corresponding task or intent to a pending state, allowing other idle execution units to take over and continue execution, thus achieving execution unit-level fault tolerance. The execution history of all tasks is permanently stored in the shared blackboard, supporting complete auditing and backtracking.

[0135] System scalability description:

[0136] This system has multi-dimensional scalability:

[0137] First, backend scalability. Through a unified driver interface, any AI agent tool that supports command-line calls can be connected, such as the Gemini CLI command-line tool and local open-source large language models, continuously enriching the system's model backend options.

[0138] Second, domain adaptability. By simply adjusting the prompt word templates for the tasks, the system can migrate from the domain of network penetration testing to any goal-oriented problem domain such as mathematical proofs, vulnerability research, and code auditing, without modifying the core scheduling architecture.

[0139] Third, scheduling scalability. The system can be deployed with a single scheduler instance to ensure consistency in protocol write order and state transitions; in the expansion implementation, horizontal scaling of multiple scheduler instances can be supported by introducing distributed locks or lease arbitration mechanisms at the service layer.

[0140] Fourth, policy configuration capabilities. All scheduling parameters, such as task timeout, concurrency limit, task priority, and execution unit weight, can be configured and adjusted, allowing for flexible adjustment of scheduling policies according to different application scenarios.

[0141] System deployment and performance:

[0142] This system can be deployed on a single general-purpose cloud server, and runs stably with standard configuration. It supports processing multiple concurrent projects, and a single project can be configured with multiple execution units running in parallel. The entire system operation requires no manual intervention; any failure of a single execution unit can be automatically taken over, resulting in a low task interruption rate. As the number of execution units increases, within the limits of shared blackboard writing, scheduling loops, and project-level concurrency thresholds, the overall exploration efficiency can be significantly improved.

[0143] The above-described embodiments are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.

Claims

1. A multi-agent indirect cooperative scheduling method based on a blackboard architecture, characterized in that, Includes the following steps: S1. Construct a project-level shared blackboard, write the starting and ending facts of the project to be processed as fact nodes into the shared blackboard, and establish three types of protocol objects in the shared blackboard: facts, intentions, and prompts, and initialize the scheduling and running environment; S2. The scheduler reads the current graph status of the shared blackboard at fixed time intervals, and dynamically selects and assigns guiding tasks, reasoning tasks and exploration tasks based on whether the project is in the initial state, whether there are new facts or new hints, and whether there are unclaimed exploration intentions. S3. After obtaining the task context through the scheduler, the execution unit reads the complete status information of the shared blackboard, executes the corresponding task and returns the structured objective result. The scheduler or the shared blackboard writing interface normalizes the result and writes it to the shared blackboard. The execution units do not communicate directly with each other and do not directly rewrite the protocol status. S4. Each claimed task is bound to the identifier of the corresponding execution unit. The scheduler sends a heartbeat signal at a fixed period to maintain the claimed status of the task. When the heartbeat times out, the execution unit identifier of the corresponding task is automatically cleared and the task is reset to the claimable status. S5. A two-stage timeout mechanism is adopted for the guidance task and the exploration task. If the task is completed in the main execution stage, the execution result is returned directly. If the main execution stage times out, the execution context is retained and the summary stage is entered. The completed execution content is extracted and the corresponding result is output. A single-stage timeout mechanism is adopted for inference tasks, and invalid planning results are not written after the timeout.

2. The multi-agent indirect cooperative scheduling method based on blackboard architecture according to claim 1, characterized in that, The fact object is used to record the observed objective state or task result, the intention object is used to record the direction to be explored, the declared state, the identifier of the claimed execution unit and the last heartbeat time, and the prompt object is used to record external expert suggestions, user prompts or supplementary clues injected by the scheduler.

3. The multi-agent indirect cooperative scheduling method based on blackboard architecture according to claim 1, characterized in that, The triggering condition for the guidance task is that there are only starting facts and ending facts in the shared blackboard or the project has not yet completed its initial attempt; the triggering condition for the reasoning task is that new facts, new hints, goal achievement status need to be determined in the shared blackboard, or there is no unclaimed exploration intent in the current project; the triggering condition for the exploration task is that there is an unclaimed exploration intent in the shared blackboard.

4. The multi-agent indirect cooperative scheduling method based on blackboard architecture according to claim 1, characterized in that, The reasoning task corresponds to situation assessment, target achievement determination and exploration intention generation operations, and the exploration task corresponds to specific exploration operations; the same execution unit can be configured to execute one or more task types according to its task type capability, and different execution units can also undertake different tasks according to task type, driving type or concurrency quota.

5. The multi-agent indirect cooperative scheduling method based on blackboard architecture according to claim 1, characterized in that, Tasks from different projects are scheduled in parallel. Tasks from existing projects are dispatched before new projects. The number of running tasks within the same project and the number of running tasks globally do not exceed the preset maximum concurrency limits for the project and the global concurrency limits, respectively.

6. A multi-agent indirect cooperative scheduling system based on a blackboard architecture, characterized in that, It includes a shared blackboard service module, a scheduler module, multiple execution unit modules, a declaration lease management module, a heartbeat management module, and a timeout handling module; The shared blackboard service module serves as the source of project status truth, and is connected to the scheduler module for data storage. It stores start-up facts, end-up facts, fact objects, intent objects, prompt objects, task running status, and execution history data according to the project. The scheduler module is signal-connected to the shared blackboard service module and each execution unit module. It reads the graph state of the shared blackboard service module at fixed intervals, generates guidance tasks, reasoning tasks and exploration tasks according to conditional scheduling rules, and writes the execution results, generation intentions and task states back to the shared blackboard service module as a protocol in the control plane. The execution unit module receives task snapshots or prompts dispatched by the scheduler module, calls the corresponding artificial intelligence backend and tool environment to execute the task, and returns the structured execution results to the scheduler module. There is no direct data connection between the execution unit modules. The lease management module and heartbeat management module work together with the scheduler module to bind the execution unit identifier, lease status and last heartbeat time to the claimed exploration intention or running task. When the heartbeat times out, the corresponding claimed status is released and reset to the pending claim status.

7. The multi-agent indirect cooperative scheduling system based on blackboard architecture according to claim 6, characterized in that, The timeout handling module is signal-connected to the scheduler module and the execution unit module, and performs dual-stage timeout control for the guidance task and the exploration task: tasks completed in the main execution stage directly return the results, and tasks that time out in the main execution stage retain the execution context and enter the summary stage to extract the completed content. A single-stage timeout is implemented for inference tasks. If the timeout occurs, the corresponding task is terminated and no invalid planning results are written.

8. The multi-agent indirect cooperative scheduling system based on blackboard architecture according to claim 6, characterized in that, The conditional scheduling rules of the scheduler module include: initial projects are given priority in dispatching guidance tasks; reasoning tasks are given priority when there are new facts, new hints, or target states that need to be determined in the shared blackboard; exploration tasks are dispatched when there are unclaimed exploration intentions in the shared blackboard and the project concurrency quota allows; and when scheduling across projects, running projects are given priority and are subject to global concurrency threshold limits.

9. The multi-agent indirect cooperative scheduling system based on blackboard architecture according to claim 6, characterized in that, The execution unit module is configured with a set of task type capabilities, driver type, basic priority, maximum concurrency, and health status. The scheduler module selects the execution unit based on task type matching, concurrency limit, health status, cooldown status, basic priority, number of currently running tasks, and random disturbances.

10. The multi-agent indirect cooperative scheduling system based on blackboard architecture according to claim 6, characterized in that, All execution unit modules are connected to the system through a unified driver interface, which includes methods for health checks, task execution, session identifier extraction, summary phase triggering, and structured output of results. It supports hybrid deployment of various command-line or interface-based AI backends.

Images