A blockchain-based multi-agent collaborative work method

Abstract

This invention proposes a blockchain-based multi-agent collaborative working method, comprising: recording the capability attribute information of each agent on the configuration chain of a blockchain network, wherein the capability attribute information includes the spatial identifier to which the agent belongs and the spatial identifier that can be accessed; in response to task submission, the main agent decomposes the task into multiple sub-tasks and sends the sub-task information and the identifiers of other allowed spaces to participate to the blockchain network corresponding to the target space through blockchain transactions; nodes within the same space conduct a consensus vote based on the sub-task information to determine the agent that undertakes each sub-task, and record the voting results and undertaking relationships on the blockchain; the agent that undertakes the sub-task executes the sub-task and records the execution process and execution results in a block of the blockchain for subsequent traceability and reuse. This invention can improve the credibility and traceability of multi-agent collaboration, and realize decentralized dynamic task allocation and cross-space permission control.

Description

Technical Field

[0001] This invention relates to the field of blockchain and multi-agent collaboration technology, and in particular to a blockchain-based multi-agent collaborative working method. Background Technology

[0002] With the rapid development of large-scale modeling and agent technologies, multi-agent collaborative architecture has become an important paradigm for handling complex tasks, widely applied in fields such as automated decision-making, distributed computing, and cross-organizational collaboration. In related technologies, a master agent decomposes complex tasks into multiple sub-tasks, which are then distributed to different sub-agents for parallel execution, constructing a collaborative system based on a centralized server or a fully trusted internal network. Specifically, this system covers the entire process from task decomposition and sub-task distribution to result aggregation, including key aspects such as agent capability declaration, task scheduling, and execution feedback, aiming to improve task processing efficiency and system scalability.

[0003] However, existing multi-agent collaboration methods directly adopt centralized or fully trusted network assumptions, failing to consider the reality in production-level, alliance-based application scenarios where agent instances belong to different organizations and are deployed in untrusted distributed network environments. This may lead to untraceable agent execution results, invisible execution processes, or, after task splitting, overall task execution being affected by single-point agent anomalies or network isolation, thus limiting cross-space and cross-organization agent collaboration capabilities and system robustness. Summary of the Invention

[0004] The present invention aims to at least partially solve one of the technical problems in the related art.

[0005] Therefore, the first objective of this invention is to propose a blockchain-based multi-agent collaborative working method.

[0006] The second objective of this invention is to provide an electronic device.

[0007] To achieve the above objectives, a first aspect of the present invention proposes a blockchain-based multi-agent collaborative working method, comprising: S1, recording the capability attribute information of each agent on the configuration chain of the blockchain network, wherein the capability attribute information includes the space identifier to which the agent belongs and the space identifier that can be accessed; S2, in response to task submission, the main agent decomposes the task into multiple sub-tasks and sends the sub-task information and the identifiers of other spaces that are allowed to participate to the blockchain network corresponding to the target space through a blockchain transaction; S3, nodes within the same space conduct a consensus vote based on the sub-task information to determine the agent that undertakes each sub-task, and record the voting results and the undertaking relationship on the blockchain; S4, the agent that undertakes the sub-task executes the sub-task and records the execution process and execution results in the blockchain block for subsequent traceability and reuse.

[0008] In one embodiment of the present invention, the step of recording the capability attribute information of each intelligent agent on the configuration chain of the blockchain network includes: nodes deployed by alliance members declaring the capability attribute information of the intelligent agents they possess, the capability attribute information including the intelligent agent name, intelligent agent description, and accessible public key, and generating a blockchain transaction based on the capability attribute information and sending it to the configuration chain of the blockchain network, the configuration chain being used to record the intelligent agent attributes declared by all nodes as an intelligent agent capability output list.

[0009] In one embodiment of the present invention, the capability attribute information further includes spatial attributes, which include spatial name, spatial identifier, spatial description, spatial certificate and member public key, and the spatial attributes are also recorded on the configuration chain.

[0010] In one embodiment of the present invention, the step of decomposing the task into multiple sub-tasks by the main intelligent agent in response to task submission includes: the user submits the task to a blockchain node, the node converts the task into a blockchain transaction, the transaction carries a spatial name, the node hands the transaction over to an entry intelligent agent for processing, and the entry intelligent agent, as the main intelligent agent, is responsible for task decomposition.

[0011] In one embodiment of the present invention, the method of setting the space name carried by the transaction includes: the user manually specifying the space name to which the transaction is sent, or the node calling the large model to collect space descriptions with permissions on the configuration chain, automatically determining which space to send the transaction to and selecting the entry agent.

[0012] In one embodiment of the present invention, the step of sending the subtask information and other allowed space identifiers to the blockchain network corresponding to the target space via a blockchain transaction includes: the main intelligent agent converting the dismantling plan into a blockchain transaction, defining a transaction identifier and a minimum number of intelligent agents to undertake each subtask, and sending the transaction to the blockchain network corresponding to the space where the main intelligent agent is located. If the configuration chain allows other space intelligent agents to participate, the other space identifier field is specified in the transaction.

[0013] In one embodiment of the present invention, the consensus voting among nodes in the same space based on subtask information includes: the large model to which each node is located automatically determines whether the current node has the ability to execute the subtask; if so, it sends a vote; the vote content includes the mapping relationship between transaction identifier, subtask identifier and agent name; and the vote is broadcast on the network to which the current space is located.

[0014] In one embodiment of the present invention, recording the voting results and acceptance relationships on the blockchain includes: after the master node receives votes exceeding a specified threshold, the smart contract automatically triggers the execution of this smart agent, and at the same time records the transactions, acceptance results of each node, and voting information through the blockchain ledger.

[0015] In one embodiment of the present invention, the intelligent agent that undertakes the sub-task executes the sub-task and records the execution process and execution result in the blockchain block includes: each node subscribes to the blockchain block production event, and when it finds that the block has confirmed that the intelligent agent has agreed to execute the sub-task, the intelligent agent that undertakes the task executes the sub-task, and records the execution process and execution result in the blockchain block after processing.

[0016] In one embodiment of the present invention, the execution process includes: recording the tool name, parameters and results when the execution tool is called; recording the questions and answers when the large model is called; recording the prompt content and skill content when constructing system prompts; and uploading this data to object storage to obtain the access address and hash value.

[0017] In one embodiment of the present invention, the execution result includes the final result data returned by the large model. The data recorded on the blockchain includes transaction identifier, agent name, access address, hash value and result data, linked by a separator.

[0018] In one embodiment of the present invention, the method further includes: configuring a timeout threshold for the main agent; if the execution results of all subtasks are collected before the timeout, the method proceeds to the result merging step; if the timeout occurs, the collected execution results of the subtasks are brought into the result merging step.

[0019] In one embodiment of the present invention, the result merging step includes: the main agent sends the execution results of each agent of each subtask to the large model for merging and summarizing to form the final result of each subtask; the main agent performs subsequent processing again based on the results of each subtask, and repeats the task distribution process.

[0020] In one embodiment of the present invention, during the merging process, the master agent marks agents with good performance evaluations and generates a score list. The score list contains the transaction identifiers of the agent's execution results. Other nodes in the same space find the transactions through blockchain tracing based on the score list and obtain the agent's execution process and results.

[0021] In one embodiment of the present invention, if the timeout occurs, the main agent triggers a manual intervention tool to prompt the user to input whether they agree to data aggregation based on incomplete agent execution results. If they agree, the process proceeds to the result merging step.

[0022] In one embodiment of the present invention, if there is no intelligent agent in the current space that meets the requirements, a request is sent to intelligent agents in other spaces according to the accessible space identifier. The intelligent agents in other spaces access the configuration chain to query their own accessible public key list. If the requester's public key is in the authorized list, the intelligent agent is invoked to vote and perform actions.

[0023] To achieve the above objectives, a second aspect of this application provides an electronic device, including a processor and a memory; wherein the processor runs a program corresponding to the executable program code by reading executable program code stored in the memory, for implementing the method described in the first aspect embodiment.

[0024] The embodiments of the present invention have the following beneficial effects: 1. Enhance the credibility and traceability of multi-agent collaboration: By recording the entire process of agent declaration, task breakdown, voting consensus, execution, and results on the blockchain, the immutability and traceability of blockchain ensure that every step is verifiable. Subsequently, on-chain records (such as transaction IDs and block heights) can be used to accurately trace the agent undertaking any subtask, the execution process (tool calls, LLM requests, Prompt construction), and the final result, facilitating auditing and problem localization.

[0025] 2. Achieve dynamic, decentralized agent capability discovery and task allocation: Each agent autonomously declares its capabilities, its associated namespace, accessible namespaces, and public key via the Config chain, eliminating the need for a centralized registration center. The main task agent distributes subtasks based on the attributes declared on the chain (namespace, auth namespace, etc.), and combines LLM automatic judgment and voting consensus mechanisms to achieve dynamic matching of agent capabilities and distributed task allocation, improving the system's flexibility and scalability.

[0026] 3. Support for cross-space collaboration and access control: When tasks are decomposed and uploaded to the blockchain (tx2), the main Agent can explicitly specify other space identifiers (auth namespace) that are allowed to participate. Combined with the fields "which spaces can access" and "which public keys can access" in the Agent declaration, fine-grained cross-space task collaboration and access verification are realized, which not only ensures data security, but also supports a wider range of Agent resource sharing.

[0027] 4. Achieve structured storage and lightweight on-chain recording of execution processes and results: Upload large amounts of process data, such as large model calls, tool calls, and system prompts, to OSS object storage, and only record the access URL, data hash, and core result (result1) on the blockchain. This preserves the complete execution process for reproduction and auditing while significantly reducing the storage burden on the blockchain and improving transaction processing efficiency.

[0028] 5. Support for Agent Performance Evaluation and Optimal Reuse: When merging subtask results, the main agent can mark high-performing agents based on their performance, generating a score list that records the transaction ID of the agent's execution result. Other nodes in the same space can use blockchain traceability to find the corresponding transaction based on the score list, obtaining the agent's execution process and results for subsequent agent selection or model optimization, forming a positive feedback mechanism.

[0029] 6. Supports multi-round progressive task processing and complex process orchestration: After the main agent completes the merging of the first round of sub-task results, it can redistribute, decompose, and reach consensus again based on the summarized results, repeating the above process. This mechanism supports multi-layered, progressive complex task processing and is suitable for application scenarios that require multi-stage reasoning and iterative optimization (such as complex problem solving and long-process automation).

[0030] 7. Enhanced automation and intelligence in task execution: The entire process, from task submission, breakdown, voting, execution to result merging, is driven by smart contracts, blockchain consensus, and LLM automatic judgment, requiring no manual intervention. LLM automatically determines whether a node is capable of executing sub-tasks and triggers agent execution based on blockchain transactions and consensus results, achieving a highly automated and intelligent multi-agent collaborative workflow.

[0031] 8. Enhanced Fault Tolerance in Complex Network Environments: Utilizing the underlying P2P networking mechanism of the blockchain, when the Agent cluster is deployed in complex networks (such as cross-regional, weakly stable connections, or edge computing environments with intermittent network outage risks), the system maintains high robustness even if the node containing the main Agent is temporarily offline due to network fluctuations or other nodes. Since task decomposition, voting consensus, sub-task succession relationships, and the storage addresses (URLs) and data hashes of execution results are all fixed in consecutive blocks of the blockchain, the main Agent or any participating node can automatically retrieve complete historical task states, intermediate results, and final data by synchronizing block data after reconnecting to the network. This effectively avoids the problem of task failure or data loss due to single-point network interruptions in traditional centralized orchestration models, achieving resilient collaboration capabilities of "no loss of activity during network outages, and immediate recovery upon reconnection." Attached Figure Description

[0032] The above-described and additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, in which: Figure 1 A flowchart of a blockchain-based multi-agent collaborative working method provided in an embodiment of the present invention. Detailed Implementation

[0033] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

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

[0035] The following description, with reference to the accompanying drawings, describes a blockchain-based multi-agent collaborative working method and apparatus according to an embodiment of the present invention.

[0036] Example 1 This embodiment provides a blockchain-based method for multi-agent collaborative work. For example... Figure 1 As shown, the method includes the following steps: S1, record the capability attribute information of each intelligent agent on the configuration chain of the blockchain network. The capability attribute information includes the spatial identifier to which the intelligent agent belongs and the spatial identifier that can be accessed.

[0037] In a blockchain-based multi-agent collaborative working method, the first step is to build a decentralized agent capability registration and discovery mechanism that can be accessed by all participating nodes.

[0038] Specifically, each intelligent agent records its own capability attribute information in the form of transactions on a dedicated chain within the blockchain network. This dedicated chain is configured to store and manage the capability declarations of intelligent agents, i.e., the configuration chain. The capability attribute information includes at least the spatial identifier to which the intelligent agent belongs and the spatial identifier to which the intelligent agent can be accessed. The spatial identifier defines the logical or physical network domain to which the intelligent agent belongs. By default, intelligent agents in different spaces are logically isolated from each other, and their data is not visible. The spatial identifier to which other spaces the intelligent agent allows to be invoked or collaborated with across spaces. By writing the above capability attribute information into the configuration chain, all alliance member nodes can query the data on this chain to obtain the capabilities, domains, and access permissions of all registered intelligent agents in the network, forming a globally visible and tamper-proof list of intelligent agent capabilities.

[0039] As one implementation method, after deploying an agent, each node can assemble the agent's name, description, spatial identifier, accessible spatial identifier, and list of accessible public keys into a blockchain transaction, and send the transaction to the configuration chain. The consensus mechanism of the blockchain network will then verify and record the transaction, thereby completing the on-chain registration of the agent's capability attributes.

[0040] This step achieves decentralized registration and global visibility of agent capabilities by storing the agent's capability attribute information on the configuration chain. It avoids single points of failure and trust issues that may exist in traditional centralized registration centers, and provides reliable basic data support for subsequent dynamic and flexible task distribution and cross-space collaboration.

[0041] S2, in response to task submission, the main agent breaks down the task into multiple sub-tasks and sends the sub-task information and the identifiers of other spaces that are allowed to participate to the blockchain network corresponding to the target space through blockchain transactions.

[0042] In response to task submission, the system first decomposes the task by the main agent into multiple logically related or parallel-executable subtasks. Based on its understanding of the task and the capability attributes declared by each agent on the configuration chain, the main agent determines the technical capabilities and execution conditions required for each subtask. Subsequently, the main agent encapsulates the decomposed subtask information, including the subtask's identifier, content description, and minimum number of agents required for execution, along with identifiers of other spaces authorized to participate in the task, to generate a blockchain transaction. This transaction is sent to the blockchain network corresponding to the target space, which can be the default space belonging to the main agent or another space dynamically determined based on task requirements or spatial attribute information recorded on the configuration chain. By writing the subtask information and cross-space authorization identifiers into the blockchain transaction, the task decomposition results are reliably broadcast and persistently recorded in the distributed network, providing a reliable data foundation for subsequent agent matching and consensus among nodes within the same space based on this transaction information.

[0043] As one implementation method, when the main agent breaks down a task, it can call a large language model to analyze the task and automatically determine the target space and entry agent by combining the capability descriptions of each space on the configuration chain. At the same time, the sub-task information can include the minimum number of agents required for each sub-task, which is used for threshold determination in the subsequent consensus stage, while the identifiers of other allowed spaces are used to authorize cross-space agent collaboration.

[0044] This step achieves decentralization and trustworthiness in the task distribution process by broadcasting and recording the task breakdown results and cross-space authorization information in the form of blockchain transactions. It avoids the problems of single point of failure and information opacity in the traditional centralized scheduling mode, while providing a clear permission control mechanism for cross-space collaboration and improving the flexibility and scalability of multi-agent collaborative systems.

[0045] S3: Nodes within the same space reach a consensus through voting based on subtask information, determine the intelligent agent that will undertake each subtask, and record the voting results and the undertaking relationship on the blockchain.

[0046] Upon receiving a blockchain transaction containing subtask information, nodes within the same space initiate a voting consensus process based on this subtask information. This process aims to determine the agent responsible for each subtask from all available agents within the space through distributed negotiation. Specifically, each node, based on its own capabilities and the specific requirements of the subtask, autonomously determines whether it possesses the conditions to execute the subtask and generates voting information accordingly. This voting information at least includes a mapping relationship between the subtask identifier and the candidate agent identifier. All voting information is broadcast in the blockchain network corresponding to this space and collected and counted by the main agent or nodes designated by the consensus mechanism. When the number of votes for a subtask reaches a preset threshold, the assignment of that subtask is considered determined. Subsequently, the voting result and the assignment relationship between the subtask and the agent are recorded in a blockchain block, forming an immutable consensus record.

[0047] As one implementation method, each node can automatically determine whether it is capable of executing subtasks by calling the large language model, and send a vote accordingly. When the number of votes exceeds the preset minimum number of smart agents to accept the task, the smart contract automatically triggers the subsequent execution process and records the transaction containing subtask information, the acceptance results of each node and the voting information through the blockchain ledger.

[0048] This step introduces a blockchain-based voting consensus mechanism, enabling decentralized determination of the subtask-accepting agent in an untrusted distributed network environment. This avoids the trust risks associated with single-point decision-making, while ensuring the transparency and traceability of the task allocation process, providing a reliable on-chain basis for the auditing and reuse of subsequent execution results.

[0049] S4, the intelligent agent that takes over the subtask executes the subtask and records the execution process and results in the blockchain block for subsequent traceability and reuse.

[0050] After confirming the assignment relationship, the agent that receives the sub-task executes the assigned sub-task and records the key data generated during the execution process and the final execution result in the blockchain block. This process aims to digitize, structure, and solidify the agent's behavior data on the chain, thereby providing an immutable original basis for subsequent task traceability, effect evaluation, and reuse of agent capabilities.

[0051] Specifically, when an intelligent agent executes a subtask, it invokes various tools or models, such as calling a large language model for reasoning, calling external application programming interfaces to obtain data or perform specific operations, and constructing system prompts. These invocations, along with their corresponding input parameters and output results, constitute the execution process data. To reduce the storage pressure on the blockchain while ensuring data integrity, these large-volume process data can be stored in an off-chain distributed object storage system, generating corresponding access addresses and data hash values. Subsequently, the core information, including the subtask identifier, the intelligent agent identifier executing the task, the access address, the data hash value, and the final execution result, is concatenated using a preset delimiter to form a structured record. This record is then submitted to the blockchain network as transaction content and written into a block after consensus.

[0052] As one implementation method, when the agent executes a tool call, it records the tool name, parameters and results; when it calls the large language model, it records the request content and response; when it constructs system prompt words, it records the prompt word content and skill description. It then uploads this data to object storage to obtain a Uniform Resource Locator (URL) and hash value. Finally, it concatenates the subtask identifier, agent identifier, URL, hash value and the final result returned by the large model with a delimiter and stores them on the blockchain.

[0053] This step achieves complete recording and lightweight evidence storage of agent behavior by separating and storing the execution process and results on the blockchain. It retains detailed process data for reproduction and auditing while significantly reducing the storage overhead of the blockchain. At the same time, it provides a reliable data foundation for subsequent agent capability evaluation, optimal reuse, and behavior tracing based on on-chain records.

[0054] Example 2 Based on the above embodiments, this embodiment provides a detailed description of the specific implementation of step S1 in the blockchain-based multi-agent collaborative working method, which involves "recording the capability attribute information of each agent on the configuration chain of the blockchain network, wherein the capability attribute information includes the spatial identifier to which the agent belongs and the spatial identifier that can be accessed."

[0055] In this embodiment, the step S1 of recording the capability attribute information of each intelligent agent on the configuration chain of the blockchain network is specifically implemented in the following way: First, alliance members deploy their respective blockchain nodes and join the blockchain network. Each node needs to declare its own intelligent agents and their capabilities. This capability attribute information includes the intelligent agent's name, description, spatial identifier, accessible spatial identifiers, and accessible public keys. Specifically, the node generates a blockchain transaction using the aforementioned fields, such as the intelligent agent name, intelligent agent description, the intelligent agent's spatial identifier, which spaces can access it, and which public keys can access it, and sends this transaction to the blockchain network's configuration chain. This configuration chain records the intelligent agent attributes declared by all nodes, essentially acting as a list of intelligent agent capabilities; all nodes on the alliance blockchain can access this configuration chain. Furthermore, spatial attributes are also recorded on the configuration chain, including the spatial name, spatial identifier, spatial description, spatial certificate, and member public keys. By recording the intelligent agent's capability attributes along with its spatial attributes on the configuration chain, decentralized registration and discovery of intelligent agent capabilities are achieved, providing a foundation for subsequent task distribution and cross-spatial collaboration.

[0056] This specific implementation records the agent's capability attribute information and spatial attributes on the configuration chain, thereby achieving decentralized registration and discovery of agent capabilities. This avoids the single point of failure risk of centralized registration, supports cross-spatial collaboration permission verification, and improves the system's scalability and security.

[0057] Example 3 Based on the above embodiments, this embodiment provides a detailed description of the specific implementation of step S2 in the blockchain-based multi-agent collaborative working method: "In response to task submission, the main agent decomposes the task into multiple sub-tasks and sends the sub-task information and other allowed space identifiers to the blockchain network corresponding to the target space through blockchain transactions."

[0058] In this embodiment, the process described in step S2, where the main intelligent agent decomposes the task into multiple sub-tasks in response to task submission, is as follows: First, the user submits the complex task to be processed to a node in the blockchain network, which serves as the task entry point. After receiving the task, the node converts it into a blockchain transaction. This transaction must carry the name of the target space to specify which space the task should be routed to for processing. There are two specific implementation paths for setting the space name. The first path is that the user manually specifies it, that is, when submitting the task, the user directly writes the name of the target space in the transaction, and the node sends the transaction to that space accordingly. The second path is that the node automatically determines it. When the user does not manually specify the space name, the node calls its built-in large language model, which actively collects and analyzes the description information of all spaces with access permissions on the configuration chain. Based on the matching degree between the task content and the space capabilities, it automatically decides the most suitable space name and simultaneously determines the entry intelligent agent responsible for processing the task in that space. This entry intelligent agent is the main intelligent agent that subsequently executes the task decomposition. After a node submits a blockchain transaction carrying the space name to the blockchain network, the transaction is routed to the corresponding space and received by the entry agent within that space. The entry agent, acting as the master agent, begins to break down the original task into multiple logically independent subtasks. It defines a corresponding transaction identifier for each subtask and sets parameters such as the minimum number of agents required to handle each subtask, preparing for subsequent voting consensus and task distribution. This process creates a complete closed loop from user task submission to master agent task decomposition, ensuring that tasks are accurately routed to the correct space and processed by the appropriate agent.

[0059] This specific implementation significantly improves the flexibility and intelligence of task routing by introducing two space name setting methods: manual user specification and automatic node judgment. It not only meets the user's need for precise control over the task execution space, but also enables the system to automatically make the optimal decision when the user does not specify it, thereby enhancing the adaptability and ease of use of the multi-agent collaborative system.

[0060] In this embodiment, the step S2 of sending the subtask information and other allowed space identifiers to the blockchain network corresponding to the target space via a blockchain transaction is specifically implemented as follows: After the main intelligent agent completes the decomposition of the user-submitted task, it converts the generated decomposition plan into a blockchain transaction, denoted as tx2. In this transaction tx2, the main intelligent agent defines a unique transaction identifier for each decomposed subtask. For example, identifiers sub1 and sub2 are defined for subtasks sub1 and sub2, respectively. Simultaneously, transaction tx2 also defines a minimum number of intelligent agents to undertake each subtask. For example, a minimum number of agents is defined for subtask sub1 (sub1_min_agree) and subtask sub2 (sub2_min_agree). This parameter is used in the subsequent voting consensus phase to determine the minimum number of intelligent agents to undertake the subtask. Subsequently, the main intelligent agent sends transaction tx2 to the blockchain network corresponding to its own space, i.e., by default, the network corresponding to the space identifier to which the main intelligent agent belongs is used. In one possible implementation, if the attribute information of the space to which the main agent belongs, or the capability attribute information of related agents, recorded on the configuration chain, allows agents from other spaces to participate in this task, then when constructing transaction tx2, the main agent also needs to specify the allowed other space identifier field in the transaction, denoted as auth_namespace. The value of this field is the identifier of the other spaces authorized to participate in the execution of this subtask. Through the above processing, transaction tx2 contains the subtask breakdown information, the unique identifier of each subtask, the minimum number of agents required to undertake each subtask, and optional cross-space authorization information, thus providing complete data input for subsequent voting consensus among nodes in the same space based on this transaction.

[0061] This specific implementation achieves precise control over the granularity of subtask distribution and cross-space collaboration permissions by defining a transaction identifier and a minimum number of accepting agents for each subtask, and by combining it with a cross-space authorization field, thereby improving the flexibility of task allocation and the scalability of the system.

[0062] Example 4 Based on the above embodiments, this embodiment provides a detailed description of the specific implementation of step S3 in the blockchain-based multi-agent collaborative working method: "Nodes in the same space vote to reach a consensus based on sub-task information, determine the agent that undertakes each sub-task, and record the voting results and undertaking relationship on the blockchain."

[0063] In this embodiment, the process of consensus voting based on subtask information among nodes in the same space in step S3 is as follows: First, the master agent sends a blockchain transaction containing subtask information to the blockchain network corresponding to the target space, and each node in that space receives the transaction. Each node inputs the received subtask information into the large language model deployed locally on that node. The large language model automatically determines whether the current node has the ability to execute the subtask, for example, whether the agent owned by the current node meets the requirements of the subtask for tool calls, model parameters, or professional skills. If the large language model determines that the current node has the ability to execute the subtask, the node generates a voting transaction. The voting transaction contains a mapping relationship between the transaction identifier, the subtask identifier, and the agent name, for example, in the format "tx2-sub1-SAgent1", where "tx2" is the identifier of the task decomposition transaction, "sub1" is the subtask identifier, and "SAgent1" is the name of the agent in the current node that undertakes the subtask. The voting transaction is broadcast in the blockchain network where the current space is located. Subsequently, the master node is responsible for collecting votes for the same subtask. When the master node receives more than a preset threshold for the number of votes for a subtask (e.g., sub1_min_agree as defined in the subtask information), the smart contract automatically triggers, initiating the execution process of the current agent. Simultaneously, the smart contract records the transactions containing subtask information, the results of each node accepting the subtask, and all relevant voting information on the blockchain ledger, and packages them into a new block, such as block1. The generation of this block ensures the immutability and traceability of the voting consensus results and the acceptance relationships. Through this mechanism, decentralized task allocation based on a combination of large-scale model intelligent judgment and blockchain consensus is achieved, ensuring that subtasks can be reliably accepted by capable agents. The beneficial technical effects of this specific implementation are that by introducing a large-scale model to automatically judge node capabilities and combining it with a blockchain voting consensus mechanism, dynamic and decentralized discovery of agent capabilities and task allocation are achieved, eliminating the need for a centralized scheduler and improving the system's flexibility and robustness. Furthermore, storing the voting results and acceptance relationships on the blockchain provides immutable evidence for the traceability and auditing of subsequent task execution results.

[0064] Example 5 Based on the above embodiments, this embodiment provides a detailed description of the specific implementation of step S4 in the blockchain-based multi-agent collaborative working method: "The agent that undertakes the sub-task executes the sub-task and records the execution process and execution results in the blockchain block for subsequent traceability and reuse."

[0065] In this embodiment, the process by which the intelligent agent that undertakes the sub-task executes the sub-task and records the execution process and results in the blockchain block is as follows: First, each node subscribes to the block production event of the blockchain network. When a node hears that a block containing the intelligent agent's consent information has been generated and confirmed on the blockchain, the intelligent agent that undertakes the task begins to execute the sub-task it has claimed.

[0066] Specifically, each node monitors the generation of new blocks in real time through the blockchain network's subscription mechanism. When a new block contains the voting results and succession relationships recorded in step S3, and this succession relationship explicitly indicates that the agent on the current node needs to execute a certain subtask, the agent is triggered to execute. During execution, the agent needs to record detailed execution process data. When the agent executes a tool call, the recorded content includes the tool name, call parameters, and the result returned by the tool; when the agent calls the large model, the recorded content includes the input question and the large model's returned answer; when the agent constructs system prompts, the recorded content includes the prompt text and skill content. This execution process data is uploaded to the object storage service and obtains the corresponding access address and data hash value. The execution result includes the final result data returned by the large model.

[0067] Subsequently, the agent combines the execution result with the access address, hash value, and related transaction identifiers, agent name, and other information of the execution process data. Specifically, the data recorded on the blockchain includes the transaction identifier, agent name, access address, hash value, and result data. These data items are linked using predefined delimiters to form a complete record, which is then sent to the blockchain network as a new transaction and ultimately written into a blockchain block. In this way, lightweight core data is stored on the blockchain, while complete process data is associated through the access address and hash value of the object storage, ensuring the traceability of the execution process while avoiding excessive consumption of blockchain storage space.

[0068] This specific implementation uploads the execution process data to object storage and only puts the access address and hash value on the blockchain, thus achieving structured storage and lightweight on-chain storage of the execution process and results. While retaining the complete execution process for reproduction and auditing, it significantly reduces the storage burden on the blockchain and improves transaction processing efficiency.

[0069] In this embodiment, after distributing subtasks, the main agent configures a timeout threshold to control the maximum waiting time for the execution results of each subtask. Specifically, after sending the subtask information and the identifiers of other allowed spaces to the blockchain network corresponding to the target space via a blockchain transaction, the main agent starts a timer. This timer uses the blockchain network's timestamp or the main agent's local system time as a reference and sets a preset time length as the timeout threshold. During the timer's operation, the main agent continuously monitors block events on the blockchain network to collect the execution results submitted by each agent undertaking the subtasks. When the main agent collects all the execution results of all subtasks within the timeout threshold, that is, when all the agents corresponding to the subtasks have recorded the execution process and results in the blockchain blocks, the main agent obtains these execution results as input and enters the result merging step. If the timer reaches the timeout threshold before the main agent has collected all the execution results of all subtasks, the main agent uses the currently collected subtask execution results as input and directly pushes them into the result merging step, thereby avoiding the entire task process from stalling due to delays or failures in the execution of individual agents.

[0070] In the result merging step, the main agent sends the execution results of each agent in each subtask to the large model for merging and aggregation. Specifically, for each subtask, the main agent retrieves the execution results of all agents corresponding to that subtask from the blockchain, including execution process data (such as tool calls, LLM requests, system prompts, etc.) and the final return results. This data is then fed into the large model, which uses its natural language processing capabilities to integrate, deduplicate, logically reason, and summarize these results to form the final result of that subtask. Based on the final results of each subtask, the main agent performs further processing, such as determining whether further task decomposition is needed based on the aggregated results. If so, the task distribution process is repeated, i.e., the new subtask information is sent to the target space again through blockchain transactions, triggering a new round of voting consensus and execution. During the merging process, the main agent marks agents with good execution performance and generates a score list. Specifically, during the merging process, the master agent marks high-performing agents based on metrics such as accuracy, completeness, and efficiency of their execution results. The scoring list includes the transaction identifier (e.g., transaction ID) of the agent's execution result. Other nodes in the same space then use the blockchain's traceability capabilities to locate the corresponding transaction based on the scoring list, thereby obtaining the agent's execution process and results for subsequent agent selection or model optimization.

[0071] If the main agent triggers the result merging step after a timeout, and the collected subtask execution results are incomplete, the main agent triggers a manual intervention tool. Specifically, the main agent calls a manual intervention interface to generate a prompt message containing an overview of the currently collected subtask execution results and information on the uncollected subtasks. This message is sent to the user via a user interface or message channel, asking the user whether they agree to data aggregation based on incomplete agent execution results. The user responds by inputting a command. If the user agrees, the main agent uses the collected subtask execution results as input and proceeds to the result merging step; if the user disagrees, the main agent terminates the current task flow or waits for further instructions from the user.

[0072] This specific implementation effectively improves the robustness and flexibility of the multi-agent collaborative workflow by introducing timeout thresholds and manual intervention mechanisms. It avoids the entire task being blocked due to abnormal execution of individual agents, while retaining the channel for manual decision-making in the case of incomplete data. This enhances the system's fault tolerance and the reliability of task completion in complex network environments.

[0073] In this embodiment, after the nodes in the same space reach a consensus through voting based on subtask information, if there is no intelligent agent in the current space that meets the requirements, the main intelligent agent sends a request to intelligent agents in other spaces based on the accessible space identifier.

[0074] Specifically, in the blockchain transaction tx2 generated by the main agent during the task decomposition phase, the auth_namespace field indicates the other space identifiers that are allowed to participate. When a node in the current space automatically determines through LLM that it does not have the ability to execute a certain subtask, the node will construct a new blockchain transaction tx3 based on the other space identifiers indicated by the auth_namespace field. This tx3 transaction includes the subtask identifier, the subtask text content, and the requester's public key signature, such as a combination of tx2-sub1-SAgent1 and the subtask text, and is signed using the requester's own private key pk1. This tx3 transaction is broadcast to the target space through the blockchain network. After receiving the tx3 request, the agents in other spaces (such as Agent4) first access the configuration chain (Config chain) and query the list of accessible public keys (auth_publicKey field) in their own declared capability attribute information. Agent4 compares the requester's public key pk1 carried in tx3 with the public keys in its own auth_publicKey list. If pk1 exists in the authorized list, it confirms that the requester has access rights. Subsequently, Agent4 invokes its own intelligent agent to vote and execute actions, that is, sending voting information to the current space. The voting content includes the mapping relationship between transaction identifiers, subtask identifiers, and Agent names, such as tx2-sub1-Agent4. This voting information is broadcast on the network where the current space resides, participating in the subsequent voting consensus process. When the master node receives more than a specified threshold of votes, the smart contract automatically triggers the Agent to execute the subtask and records the acceptance result, voting information, and subsequent execution process and results in the blockchain block. Through the above mechanism, dynamic discovery and permission verification of intelligent agents across spaces are achieved, ensuring secure collaboration between intelligent agents in different spaces in an untrusted network environment.

[0075] This specific implementation introduces a cross-space authorized access mechanism, enabling the system to automatically initiate requests to other spaces and perform fine-grained permission verification based on the public key list on the configuration chain when there is a lack of suitable agents in the current space. This expands the pool of available agents, improves the flexibility of task allocation and the overall fault tolerance of the system, and ensures the security of cross-space collaboration.

[0076] Example 6 In this embodiment, the complete implementation of the blockchain-based multi-agent collaborative working method will be described in detail, including the specific implementation details of the entire process such as system initialization, task submission and decomposition, voting consensus, cross-space collaboration, execution and result on-chaining, result aggregation and evaluation.

[0077] First, during the system initialization phase, consortium members deploy their respective blockchain nodes and join the blockchain network. Each node declares its own intelligent agent and its capability attributes, including the agent name, agent description, namespace identifier, which spaces it can access (authnamespace), and which public keys it can access (authpublicKey). The node generates a blockchain transaction based on these attributes and sends it to the blockchain network's configuration chain (Config chain). The main function of the configuration chain is to record the intelligent agent attributes declared by all nodes, essentially acting as a list of intelligent agent capabilities. All nodes on the consortium blockchain can access this configuration chain. Furthermore, space attributes are also recorded on the configuration chain, including space name, space ID, space description, space certificate, and member public key (memberpublicKey). Intelligent agents within the same space can network, enabling data visibility and sharing. Multiple blockchain nodes network according to spaces, with logical network isolation between spaces requiring authorized access.

[0078] During the task submission phase, a user submits a task to a blockchain node. The node transforms the task into a blockchain transaction, which must include a space name. There are two ways to set the space name: one is for the user to manually specify the space to which the transaction will be sent; the other is that if the user does not specify a space name, the node first calls the Large Model (LLM), which collects space descriptions with permissions on the configuration chain, automatically determines which space to send the transaction to, and selects an entry agent. The node then hands the transaction over to the entry agent for processing. This entry agent acts as the master agent, responsible for task decomposition.

[0079] During the task decomposition and on-chain phase, the main agent breaks down the task, transforming the decomposition plan into blockchain transactions and defining a transaction identifier for each subtask. For example, a transaction might include subtasks sub1 and sub2, and the minimum number of agents required to perform each subtask: sub1_min_agree and sub2_min_agree. The main agent sends this transaction to the corresponding space in the blockchain network, using the default space name of the main agent. If the configuration chain allows agents from other spaces to participate, the auth_namespace field must be specified in the transaction. sub1_min_agree represents the minimum number of agents required to execute task sub1, used for vote counting.

[0080] During the voting and consensus phase, after receiving a transaction, each node in the same space automatically determines whether it has a suitable agent (e.g., agent SAgent1) within its larger model. Other nodes similarly determine SAgent2, SAgent3, etc. The larger model automatically determines whether the current node is capable of executing the subtask; if so, it sends a vote. The vote contains a mapping between the transaction identifier, subtask identifier, and agent name, such as tx2-sub1-SAgent1 and tx2-sub2-SAgent2. The vote is broadcast across the network containing the current space. When the master node receives a vote exceeding a specified threshold (e.g., sub1 requires two agents to complete, and sub2 requires three), the smart contract automatically begins the execution of the current agent, recording the transaction, the completion results of each node, and the voting information on the blockchain ledger (let's say block1). If the current space does not have a suitable agent, a request is sent to agents in other spaces based on the authnamespace. Specifically, a subtask text is added to tx2-sub1-SAgent1, and the transaction tx3 is generated by signing the private key pk1 of the requester. After receiving the request tx3, the agent Agent4 in other spaces accesses the configuration chain, queries its own auth publicKey list, and checks whether pk1 is in the authorization list. If it exists, it calls the agent to vote and execute actions.

[0081] During the execution and result on-chain phase, each node subscribes to blockchain block events. When it finds that block1 has confirmed agreement on the agent's execution, the agent undertaking the task executes the sub-task and records the execution process and results on the blockchain block. The execution process includes: when an execution tool is called, recording the tool name (tools1), parameters (args), and result (result); when the large model is called, recording the request and answer (result); when constructing a system prompt, recording the prompt content, skill content (SKILL), etc. This data is uploaded to object storage (OSS), obtaining the access address (url) and generating a hash value (hash) for the data. The execution result includes the final result data returned by the large model (result1). The data finally recorded on the blockchain includes: transaction identifier (e.g., tx2-sub1), agent name (e.g., agent1), access address (url), hash value (hash), and result data (result1), separated by the hyphen "-".

[0082] During the results aggregation phase, the master agent configures a timeout threshold. If the execution results of all subtasks (such as sub1 and sub2) have been collected before the timeout, the next step, result merging, proceeds. If a timeout occurs, the execution results of all collected subtasks are incorporated into the result merging step. In the result merging step, the master agent sends the execution results of each agent in each subtask to the large model for merging and aggregation, ultimately forming the final result for each subtask. Based on the results of each subtask, the master agent performs further processing, potentially repeating the above process and redistributing tasks. During merging, the master agent marks agents with good performance evaluations, generating a score list containing the transaction identifier of the agent's execution result. Other nodes in the same space can trace the transaction identifier through the blockchain using the score list, find the complete record of the execution result (including transaction identifier, agent name, access address, hash value, and result data), and then find the execution process through the access address for agent selection or model optimization in subsequent tasks. If the timeout occurs, the main agent triggers the human being tool, prompting the user to enter whether they agree to data aggregation based on incomplete agent execution results. If the user agrees, the process proceeds to the result merging step.

[0083] Through the above process, this embodiment realizes trusted collaborative work among multiple agents in an untrusted network environment. By leveraging the immutability and traceability of blockchain, it ensures full-process traceability of agent declaration, task decomposition, voting consensus, execution process and results. At the same time, it realizes dynamic discovery of agent capabilities and cross-space authorized collaboration through configuration chain, balances data integrity and storage efficiency through object storage and lightweight on-chain mechanism, enhances system robustness through timeout mechanism and manual intervention, and supports evaluation and optimal reuse of agent execution effect through scoring list and traceability mechanism.

[0084] Example 7 To implement the methods of the above embodiments, the present invention also provides an electronic device, which includes a memory and a processor; wherein the processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement the various steps of the methods described above.

[0085] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0086] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0087] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

Claims

1. A blockchain-based multi-agent collaborative working method, characterized in that, Includes the following steps: S1, record the capability attribute information of each intelligent agent on the configuration chain of the blockchain network. The capability attribute information includes the spatial identifier to which the intelligent agent belongs and the spatial identifier that can be accessed. S2, in response to task submission, the main intelligent agent breaks down the task into multiple sub-tasks and sends the sub-task information and other space identifiers that are allowed to participate to the blockchain network corresponding to the target space through blockchain transactions; S3: Nodes within the same space reach a consensus through voting based on subtask information, determine the intelligent agent that will undertake each subtask, and record the voting results and the undertaking relationship on the blockchain. S4, the intelligent agent that takes over the subtask executes the subtask and records the execution process and results in the blockchain block for subsequent traceability and reuse.

2. The method as described in claim 1, characterized in that, The process of recording the capability attribute information of each intelligent agent on the configuration chain of the blockchain network includes: The nodes deployed by the alliance members declare the capability attribute information of the intelligent agents they possess, and generate a blockchain transaction based on the capability attribute information and send it to the configuration chain of the blockchain network. The configuration chain is used to record the intelligent agent attributes declared by all nodes as a list of intelligent agent capability outputs. The capability attribute information also includes agent name, agent description, and accessible public key; the capability attribute information also includes spatial attributes, which include spatial name, spatial identifier, spatial description, spatial certificate, and member public key, and the spatial attributes are also recorded on the configuration chain.

3. The method as described in claim 1, characterized in that, In response to task submission, the main agent breaks down the task into multiple sub-tasks, including: Users submit tasks to blockchain nodes, which transform tasks into blockchain transactions. These blockchain transactions carry spatial names, and the nodes hand over the transactions to an entry intelligent agent for processing. The entry intelligent agent acts as the main intelligent agent and is responsible for task decomposition. The method for setting the space name carried by the blockchain transaction includes: the user manually specifying the space name to which the transaction is sent, or the node calling the large model to collect and configure the space descriptions with permissions on the chain, automatically determining which space to send the transaction to and selecting the entry agent.

4. The method as described in claim 1, characterized in that, The step of sending sub-task information and other allowed spatial identifiers to the blockchain network corresponding to the target space via blockchain transactions includes: The main agent transforms the dismantling plan into a blockchain transaction, defines a transaction identifier and a minimum number of agents to undertake each subtask, and sends the transaction to the blockchain network corresponding to the space where the main agent is located. If the configuration chain allows agents from other spaces to participate, the other space identifier field is specified in the transaction.

5. The method as described in claim 1, characterized in that, The nodes within the same space reach a consensus through voting based on sub-task information to determine the intelligent agent that will undertake each sub-task, and record the voting results and undertaking relationships on the blockchain, including: The large model where each node is located automatically determines whether the current node is capable of executing the subtask. If it is, it sends a vote. The vote contains the mapping relationship between the transaction identifier, the subtask identifier, and the agent name. The vote is broadcast on the network where the current space is located. Once the master node receives more than a specified threshold of votes, the smart contract automatically triggers the execution of this smart agent, and records the transactions, the results of each node's acceptance, and the voting information through the blockchain ledger.

6. The method as described in claim 1, characterized in that, The intelligent agent that undertakes the sub-task executes the sub-task and records the execution process and results in a block of the blockchain, including: Each node subscribes to blockchain block events. When it finds that the block has confirmed the agreement to execute the task, the intelligent agent that accepted the task executes the sub-task and records the execution process and results on the blockchain block. The execution process includes: recording the tool name, parameters and results when the execution tool is called; recording the questions and answers when the large model is called; recording the prompt content and skill content when constructing system prompts; and uploading this data to object storage to obtain the access address and hash value. The execution result includes the final result data returned by the large model. The data recorded on the blockchain includes transaction identifier, agent name, access address, hash value and result data, which are linked together using separators.

7. The method as described in claim 1, characterized in that, Also includes: The main agent is configured with a timeout threshold. If the execution results of all subtasks are collected before the timeout, the result merging step is initiated. If a timeout occurs, the collected subtask execution results will be incorporated into the result merging step. The result merging step includes: the main agent sends the execution results of each agent in each subtask to the large model for merging and summarizing to form the final result of each subtask; the main agent performs subsequent processing based on the results of each subtask, repeating the task distribution process. During the merging process, the master agent marks agents with good performance evaluations and generates a score list. The score list contains the transaction identifiers of the agent's execution results. Other nodes in the same space can find the transactions through blockchain tracing based on the score list and obtain the agent's execution process and results.

8. The method as described in claim 7, characterized in that, Also includes: If the timeout occurs, the main agent triggers a manual intervention tool, prompting the user to enter whether they agree to data aggregation based on incomplete agent execution results. If they agree, the process proceeds to the result merging step.

9. The method as described in claim 1, characterized in that, Also includes: If there is no agent in the current space that meets the requirements, a request is sent to agents in other spaces based on the accessible space identifier. Agents in other spaces access the configuration chain to query their own list of accessible public keys. If the requester's public key is in the authorized list, the agent is invoked to vote and perform actions.

10. An electronic device, characterized in that, Including processor and memory; The processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement the method as described in any one of claims 1-9.

Images