An adaptive construction method, device and equipment of a multi-agent team

Abstract

The application provides a multi-agent team adaptive construction method, device and equipment, relates to the technical field of artificial intelligence, and comprises the following steps: receiving a task request, and extracting a task feature vector corresponding to the task request; determining a target team topology template from a preset team strategy library according to the task feature vector; performing role instantiation on the target team topology template to obtain a role cooperation structure; selecting a role agent of each role in the role cooperation structure from a preset agent resource pool to obtain a target agent team; controlling each role agent in the target agent team to execute a task corresponding to the task request according to the role cooperation structure, and monitoring a dynamic adjustment trigger condition in the execution process; when it is monitored that the dynamic adjustment trigger condition is met, performing adjustment on the target team topology template, and continuing to execute the task based on the adjusted team topology template until the task execution is completed. The application can improve the intelligent level of multi-agent task execution.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and more specifically, to an adaptive construction method, apparatus, and device for multi-agent teams. Background Technology

[0002] With the rapid development of large language models, agent frameworks, and distributed collaboration technologies, multi-agent collaboration to complete complex tasks has become an important implementation method for intelligent systems. In existing technologies, multi-agent collaboration mainly adopts fixed collaboration modes such as supervised collaboration, handover collaboration, workflow collaboration, and review and arbitration.

[0003] However, existing solutions still have the following shortcomings: First, the collaboration mode is rigid, and the system cannot adaptively select a matching team organization method based on factors such as task complexity, evidence dependence, risk level, and resource budget; Second, there is a lack of a unified strategy analysis layer, and the system directly performs decomposition and scheduling after the task arrives, lacking a process for generating, comparing, and selecting the best candidate team strategy; Third, there is a lack of organizational structure restructuring capabilities during execution, making it difficult to dynamically adjust the team topology when faced with evidence conflicts, role anomalies, or insufficient resources; Fourth, there is insufficient reuse of historical experience, making it impossible to form a closed loop of strategy memory between "task characteristics - team topology - execution effect," and making it difficult to continuously optimize the collaborative orchestration of subsequent tasks.

[0004] Therefore, there is an urgent need for a multi-agent collaboration method that can adaptively construct team topologies and support dynamic adjustments. Summary of the Invention

[0005] This application provides an adaptive construction method, apparatus, and device for multi-agent teams, which can improve the intelligence level of multi-agent task execution.

[0006] In a first aspect, embodiments of this application provide an adaptive construction method for a multi-agent team, the method comprising: Receive a task request and extract the task feature vector corresponding to the task request; Based on the task feature vector, determine the target team topology template from the preset team strategy library; The target team topology template is instantiated with roles to obtain the role collaboration structure; Select the role-based intelligent agents of each role in the role collaboration structure from the preset intelligent agent resource pool to obtain the target intelligent agent team; Based on the role collaboration structure, control each role agent in the target agent team to execute the task corresponding to the task request, and monitor and dynamically adjust the triggering conditions during the execution process; When the dynamic adjustment triggering condition is detected, the target team topology template is adjusted, and the task continues to be executed based on the adjusted team topology template until the task is completed.

[0007] Optionally, determining the target team topology template from a preset team strategy library based on the task feature vector includes: Based on the task feature vector, multiple candidate team topology templates are determined from the preset team strategy library; Obtain the fit between the task feature vector and the topology templates of multiple candidate teams; Based on the fit, the target team topology template is selected from the multiple candidate team topology templates.

[0008] Optionally, the step of instantiating roles in the target team topology template to obtain a role collaboration structure includes: Generate a set of roles based on the role slots in the target team topology template; Based on the set of roles, establish the handover relationships, message routing relationships, and evidence citation relationships among the roles; The role collaboration structure is constructed based on the handover relationship, the message routing relationship, and the evidence citation relationship.

[0009] Optionally, the role collaboration structure includes: a role graph, which includes: a set of roles; selecting role agents of each role in the role collaboration structure from a preset agent resource pool to obtain a target agent team, including: The job responsibilities of each role are obtained based on the set of roles. Based on the responsibilities of each role and the attributes of each agent in the preset agent resource pool, an agent is selected as the role agent for each role. The role agents of all the roles in the role graph are taken as the target agent team.

[0010] Optionally, the role graph further includes: role permissions and message rules; the role collaboration structure further includes: evidence graph and decision graph, and controlling each role agent in the target agent team to execute the task corresponding to the task request according to the role collaboration structure includes: Based on the role permissions, the message rules, the evidence rules in the evidence graph, and the decision rules in the decision graph, control each role agent in the target agent team to execute the task corresponding to the task request.

[0011] Optionally, the step of monitoring and dynamically adjusting the triggering conditions during execution includes: During execution, multiple operational metrics of the target intelligent agent team are continuously monitored; Each of the monitored operational indicators is compared with its corresponding preset threshold. When any of the aforementioned operating indicators reaches or exceeds the preset threshold, it is determined that the dynamic adjustment trigger condition is met.

[0012] Optionally, adjustments are made to the target team topology template, including: Switch the current team topology template to another type of team topology template; or... Reconfigure roles in the target team topology template; or, A verification node is injected into the target team topology template. The verification node is used to perform independent verification on intermediate or final results.

[0013] Optionally, the method further includes: During the execution of the task, at the plan formation node, a quality gating check is performed on the plan integrity of the role collaboration structure; or, At key evidence submission points, perform quality gating checks on the sufficiency and consistency of the submitted evidence; or, At the intermediate result integration node, quality gating checks are performed on the completeness of the intermediate results and their matching degree with the evidence; or, At the output node, quality gating checks are performed on the compliance and risk acceptability of the final result.

[0014] Secondly, embodiments of this application also provide an adaptive building apparatus for multi-agent teams, the apparatus comprising: The receiving module is used to receive task requests and extract the task feature vector corresponding to the task request; The selection module is used to determine the target team topology template from a preset team strategy library based on the task feature vector. The module is used to instantiate roles in the target team topology template to obtain the role collaboration structure; The selection module is also used to select the role intelligent agents of each role in the role collaboration structure from the preset intelligent agent resource pool to obtain the target intelligent agent team; The execution module is used to control each role agent in the target agent team to execute the task corresponding to the task request according to the role collaboration structure, and to monitor and dynamically adjust the triggering conditions during the execution process. The refactoring module is used to adjust the target team topology template when the dynamic adjustment triggering condition is detected, and to continue to execute the task based on the adjusted team topology template until the task is completed.

[0015] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus, wherein the memory stores program instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and the processor executes the program instructions to perform the steps of the adaptive construction method of the multi-agent team as described in any of the first aspects. This application provides an adaptive construction method, apparatus, and device for multi-agent teams. First, it receives a task request and extracts the corresponding task feature vector. Then, using this task feature vector as a matching basis, it selects a suitable target team topology template from a preset team strategy library. Next, it instantiates roles within the target topology template, constructs a role collaboration structure, and assigns corresponding role agents to each role from a preset agent resource pool, forming a target agent team. Then, it controls each role agent to collaboratively execute the task according to the role collaboration structure, continuously monitoring and dynamically adjusting trigger conditions during execution. When the trigger conditions are met, it adjusts the target team topology template and continues execution based on the adjusted template until the task is completed. By using this method, the optimal team topology template can be adaptively selected from the preset team strategy library based on the task feature vector, and roles can be instantiated. This enables the construction of multi-agent teams to dynamically match task requirements. This not only significantly improves the collaborative processing efficiency of complex tasks, but also allows for the dynamic invocation of various collaboration modes through the preset team strategy library. This enables the constructed agent teams to maintain stable collaboration quality and execution efficiency in different task scenarios, significantly improving the task adaptability and robustness of multi-agent teams, reducing the workload of manually arranging team structures, realizing the adaptive construction and dynamic adjustment of team topology, and improving the intelligence level and execution stability of multi-agent collaborative processing of complex tasks. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating an adaptive construction method for a multi-agent team provided in an embodiment of this application; Figure 2 A flowchart illustrating the process of obtaining the target team topology template in an adaptive construction method for a multi-agent team provided in this application embodiment; Figure 3A flowchart illustrating the process of obtaining the role collaboration structure in an adaptive construction method for a multi-agent team provided in this application embodiment; Figure 4 A flowchart illustrating the process of obtaining a target agent team in an adaptive construction method for a multi-agent team provided in this application embodiment; Figure 5 A flowchart illustrating the monitoring and dynamic adjustment of triggering conditions in an adaptive construction method for a multi-agent team provided in this application embodiment; Figure 6 A schematic diagram of an adaptive building device for a multi-agent team provided in an embodiment of this application; Figure 7 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0019] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0021] Before providing a detailed explanation of this application, let's first introduce its application scenarios.

[0022] In complex task multi-agent collaborative processing scenarios, existing technologies typically employ a single, fixed collaborative mode to organize agents to execute tasks. This makes it difficult to simultaneously adapt to the differentiated needs of different tasks in terms of complexity, parallelism, evidence dependence, and risk level. Furthermore, it is impossible to flexibly adjust the team collaboration structure during execution, which severely restricts the processing efficiency and result reliability of multi-agent agents in complex task scenarios.

[0023] Based on this, this application provides an adaptive construction method, apparatus, and device for multi-agent teams. First, a task request is received and the corresponding task feature vector is extracted. Then, using this task feature vector as a matching basis, a suitable target team topology template is selected from a preset team strategy library. Next, roles are instantiated on the target topology template to construct a role collaboration structure, and corresponding role agents are assigned to each role from a preset agent resource pool, forming a target agent team. Then, each role agent is controlled to collaboratively execute the task according to the role collaboration structure, and the triggering conditions are continuously monitored and dynamically adjusted during execution. When the triggering conditions are detected, the target team topology template is adjusted, and execution continues based on the adjusted template until the task is completed. This significantly improves the task adaptability and robustness of multi-agent teams, reduces the workload of manually arranging team structures, realizes adaptive construction and dynamic adjustment of team topology, and improves the intelligence level and execution stability of multi-agent collaborative processing of complex tasks.

[0024] The following description, in conjunction with the accompanying drawings, illustrates several embodiments. The adaptive construction method for multi-agent teams provided in this application can be implemented by a computer device pre-installed with a preset adaptive construction algorithm or software for multi-agent teams, through the execution of the algorithm or software. The computer device can be, for example, a server or a terminal, and the terminal can be a user computer.

[0025] Figure 1 A flowchart illustrating an adaptive construction method for a multi-agent team provided in this application embodiment is shown below. Figure 1 As shown, the adaptive construction method of this multi-agent team includes: S101 receives the task request and extracts the task feature vector corresponding to the task request.

[0026] First, acquire the task requests to be processed. Task requests can be complex tasks that require the collaboration of multiple intelligent agents, such as drafting tender response documents, handling supply chain anomalies, and generating medical literature reviews.

[0027] Specifically, the received task requests are parsed in a structured manner. The parsing process includes at least the following: semantic segmentation of the task request, breaking down long texts or complex instructions into independently processable semantic units; target identification, extracting task objectives from the task request; constraint extraction, identifying explicit or implicit restrictions in the task, including time constraints, resource constraints, and compliance requirements; output format identification, analyzing the specific requirements of the task on the structure, field completeness, and template format of the output results; and risk analysis, assessing the potential consequences of errors during task execution, the scope of business impact, and the sensitivity to decision-making.

[0028] After completing the above analysis, a task feature vector is generated to quantify and describe the task attributes. In one implementation, the task feature vector can be represented as: F = {complexity, parallelism, evidence_dependency, risk_level,timeliness, tool_dependency, interaction_freq, budget, compliance_level,output_format_constraint} Each dimension can be a discrete rank value, a continuous numerical value, or a Boolean value.

[0029] Specifically, complexity characterizes the number of subtasks, dependency depth, and goal ambiguity after task decomposition, and can be represented by a scale of 1 to 5, with higher values ​​indicating more complex tasks; parallelism characterizes the proportion of subtasks that can be executed in parallel, and can be represented by a scale of 1 to 5 or a scale of 0 to 1, with higher values ​​indicating greater parallelism; evidence dependency characterizes the degree to which the task depends on external evidence, search results, or structured data, and can be represented by a scale of low, medium, high, or 1 to 5, with higher values ​​indicating stronger evidence dependency; risk level characterizes the consequences of errors in the task, the scope of business impact, or the sensitivity of decision-making, and can be represented by a scale of 1 to 5, with higher values ​​indicating higher risk levels; timeliness characterizes the urgency of the task's deadline, and can be converted into a scale based on the ratio of remaining time to estimated execution time, with higher values ​​indicating more urgent time requirements; tool dependency characterizes the task's dependence on external tools, databases, or third-party tools. The dependency strength of third-party interfaces can be represented by a level value from 1 to 5, with higher values ​​indicating stronger tool dependency; `interaction_freq` is used to characterize the frequency of human-computer interaction, approval confirmation, or multiple rounds of clarification required during task execution, and can also be represented by a level value from 1 to 5, with higher values ​​indicating higher interaction frequency; `budget` is used to characterize the acceptable time cost, computing power cost, token cost, or manual review cost, and can be represented by a numerical budget or a level range, with its value further parsed as a budget ceiling for subsequent resource constraint filtering; `compliance_level` is used to characterize the task's requirements for audit trails, manual review, data isolation, or tool whitelists, and can be represented by a Boolean value, level value, or preset label, with its value used for subsequent compliance hard constraint filtering; `output_format_constraint` is used to characterize the task's constraints on output structure, field integrity, template format, or external delivery protocols, and can be represented by structured labels, Boolean values, or rule sets, with its value used for subsequent output format constraint filtering.

[0030] In addition, it is necessary to identify the task's dependencies on essential tools, including external tools, databases, or third-party interfaces that must be called during task execution. This essential tool dependency information will be recorded and used for subsequent tool availability verification and hard constraint filtering.

[0031] The aforementioned dimensions can be obtained through rule extraction, classification model prediction, historical statistics, external configuration, or a combination thereof. After obtaining the raw values ​​of each dimension, they are normalized to convert the dimension values ​​of different dimensions to the same numerical range. The normalized dimension values ​​are then written into the task feature vector for subsequent team strategy matching and scoring.

[0032] S102, Based on the task feature vector, determine the target team topology template from the preset team strategy library.

[0033] After obtaining the task feature vector, the team collaboration strategy is first analyzed and selected.

[0034] Specifically, the preset team strategy library includes at least one or more of the following basic topology types: supervised topology, handover topology, sequential workflow topology, parallel collaboration topology, cyclic feedback topology, debate and arbitration topology, and evaluation and optimization topology.

[0035] Among them, the supervised topology adopts a centralized control mode, in which the team leader uniformly assigns tasks, coordinates progress, and collects results; the handover topology adopts a control transfer mode, in which each role executes in a predetermined order, and the task status and intermediate results are transferred to the next role after the previous role completes the task; the sequential workflow topology organizes the roles to execute in a fixed serial order; the parallel collaboration topology allows multiple roles to process independent subtasks at the same time, without a central control role or only setting a lightweight integration role; the cyclic feedback topology introduces feedback loops between roles to support iterative optimization; the debate and arbitration topology configures multiple analysis roles to independently generate candidate conclusions, and then the arbitration role compares and adjudicates them; the evaluation and optimization topology forms an iterative loop between the generating role and the evaluation role until the result quality meets the preset standards.

[0036] Furthermore, the team strategy library also supports combining two or more of the aforementioned basic topology types to form composite hybrid topologies as candidates. For example, a supervised topology can be used as the main topology to control the global process, while a parallel collaborative topology can be used as a sub-topology to process a set of parallelizable subtasks; another example is using a parallel collaborative topology as the main topology to handle multi-path parallel acquisition, while an evaluation and optimization topology can be used as a sub-topology to iteratively optimize the generated results. Composite hybrid topologies participate in the subsequent selection process along with the basic topology types.

[0037] The extracted task feature vectors are matched against team topology templates in the team strategy library. The matching process can employ methods such as weighted similarity calculation, rule matching, or machine learning model inference to evaluate the applicability of each team topology template to the current task. Based on this, according to a preset selection strategy (e.g., selecting the template with the highest applicability, or selecting the template with the best overall score under basic constraints), the team topology template that best matches the current task is determined from multiple candidate templates and selected as the target team topology template.

[0038] S103, instantiate roles in the target team topology template to obtain the role collaboration structure.

[0039] After determining the target team topology template, it is necessary to transform the template into an executable and specific collaboration structure.

[0040] Specifically, the target team topology template defines the role slots involved, such as planning role slots, data collection role slots, verification role slots, and generation role slots, as well as the control relationships, message flow rules, and dependency constraints between these slots.

[0041] Based on the actual needs of the current task, the aforementioned role slots are instantiated. The instantiation process includes: defining the specific responsibilities and boundaries of each role slot, setting interaction protocols between roles, defining the transmission paths for evidence and decisions, and configuring trigger nodes for quality gating. After instantiation, a structured role collaboration structure is generated. This structure describes at least the following: which roles are required to participate, what operations each role is allowed to perform, the order or conditions in which roles collaborate, and the approval and review mechanisms for key decision points.

[0042] S104: Select the role agents of each role in the role collaboration structure from the preset agent resource pool to obtain the target agent team.

[0043] After the role collaboration structure is built, each role needs to be assigned a specific executable intelligent agent.

[0044] The preset agent resource pool has registered multiple available agents. Each agent instance has its own capability tags, tool permissions, historical execution performance, and current load status.

[0045] Specifically, each role in the role collaboration structure is traversed, and based on the role's responsibilities and capability constraints, a matching and filtering process is performed in the agent resource pool. This filtering process can comprehensively consider factors such as the agent's capability matching degree, current availability, historical success rate, and response latency to select the most suitable agent instance for that role. Once all roles have completed agent mapping, these selected agent instances together constitute the target agent team for the current task.

[0046] S105, based on the role collaboration structure, controls each role agent in the target agent team to execute the task corresponding to the task request, and monitors and dynamically adjusts the triggering conditions during the execution process.

[0047] Specifically, based on the generated role collaboration structure, each role agent is scheduled and controlled through a unified collaboration bus. The control process includes: triggering each agent to start execution according to the order or conditions defined in the role collaboration structure, routing messages and transmitting intermediate results between agents, collecting evidence and conclusions produced by each agent, and triggering quality gating verification at key nodes.

[0048] While the task is being executed, its operational status is continuously monitored to determine if the dynamic adjustment trigger conditions are met. These conditions measure whether the current team topology remains suitable for the current task status. Monitored metrics may include, but are not limited to: evidence conflict rate, output confidence, plan completeness, key role health status, resource utilization, tool availability, compliance verification results, and real-time risk level. These metrics are compared to preset thresholds to determine whether an adjustment mechanism needs to be activated.

[0049] S106 When the dynamic adjustment trigger condition is detected, the target team topology template is adjusted, and the task continues to be executed based on the adjusted team topology template until the task is completed.

[0050] When one or more monitored indicators reach or exceed a preset threshold, it is determined that the current team topology is no longer suitable for continuing to execute the task and needs to be adjusted.

[0051] Specifically, based on the type and severity of the triggering conditions and the current task context, adaptive adjustments are performed on the current target team topology template. These adjustments aim to change the current team's organizational structure, role configuration, or collaboration methods to address anomalies that may occur during execution, allowing the team topology to readjust to the current task state.

[0052] After the adjustment is completed, an adjusted team topology template is obtained. Based on this adjusted team topology template, the roles are re-instantiated and the agents are re-mapped, and the execution of the tasks is resumed on this basis.

[0053] If, during the resumption of execution, the dynamic adjustment triggering conditions are met again, the above steps of adjustment and resumption of execution are repeated. That is, the adjustment operation is performed again based on the new team topology, and the task continues to advance based on the adjusted team topology template.

[0054] The above adjustment and execution process is repeated until all objectives corresponding to the entire task request are achieved, and the task is finally successfully completed.

[0055] In addition, to leverage the experience gained during this task to optimize the scheduling of subsequent tasks, the strategy memory needs to be written to and updated after the task is completed. The strategy memory is a pre-defined historical experience repository used to record the complete execution profile of each task from start to finish.

[0056] Specifically, the strategy memory can be organized using any of the following methods: key-value indexing, vector indexing, relational storage, or graph structure storage. It collects and records key information from the task execution process, including at least one or more of the following: task feature vector, target team topology, role composition, key gating results, topology switching records, task latency, task cost, final quality score, user feedback, and failure reasons or anomaly types (if any anomalies occurred during task execution). After this information is written into the strategy memory, the configuration parameters for subsequent tasks can be updated using this historical data, including updating topology scoring parameters, role selection parameters, and gating threshold parameters. Through this closed-loop mechanism, the experience gained from each task execution can be distilled into reusable strategy memory, enabling continuous optimization of team topology selection, role mapping, and gating decisions in subsequent similar tasks, thereby continuously improving the efficiency and quality of multi-agent collaboration.

[0057] In this embodiment, the optimal team topology template can be adaptively selected from the preset team strategy library based on the task feature vector, and the role instantiation can be performed. This enables the construction of multi-agent teams to dynamically match task requirements. This not only significantly improves the collaborative processing efficiency of complex tasks, but also allows for the dynamic invocation of various collaboration modes through the preset team strategy library. This enables the constructed agent teams to maintain stable collaboration quality and execution efficiency in different task scenarios, significantly improving the task adaptability and robustness of multi-agents, reducing the workload of manually arranging team structures, realizing the adaptive construction and dynamic adjustment of team topology, and improving the intelligence level and execution stability of multi-agent collaborative processing of complex tasks.

[0058] In the above Figure 1 Based on the corresponding embodiments, in order to more clearly demonstrate the process of obtaining the target team topology template, this application also provides a possible implementation of obtaining the target team topology template in the adaptive construction method of a multi-agent team. Figure 2 This is a flowchart illustrating the process of obtaining the target team topology template in an adaptive construction method for a multi-agent team provided in an embodiment of this application. Figure 2 As shown, in S102 above, based on the task feature vector, the target team topology template is determined from the preset team strategy library, including: S210: Based on the task feature vector, determine multiple candidate team topology templates from the preset team strategy library.

[0059] After obtaining the task feature vector, a selection process for candidate team topology templates is carried out.

[0060] Specifically, in the preset team strategy library, each team topology template includes not only role templates, role permission templates, message routing templates, quality gating templates, topology switching preconditions, and termination conditions, but also template metadata. The template metadata includes at least: applicable task characteristic range, risk tolerance range, budget range, tool dependency requirements, compliance support level, default number of roles, recommended parallelism, evidence dependency threshold, and historical execution statistics. This metadata is used for subsequent matching and scoring.

[0061] Candidate team topology templates are selected from the team strategy library in a two-stage manner.

[0062] The first stage is hard constraint filtering. Based on the compliance level, budget ceiling, timeliness requirements, output format constraints, and necessary tool dependencies in the task feature vector, all team topology templates in the team strategy library are filtered, and templates that do not meet the minimum conditions are removed. For example, if the task requires a high level of compliance support, templates that do not support high compliance requirements are removed; if the task budget is lower than the estimated cost lower limit of a template's budget range, that template is removed.

[0063] The second stage is feature matching. For the team topology templates that have passed the hard constraint filtering in the first stage, the fit is calculated based on the similarity between the task feature vector and the template metadata profile, and the top N templates are selected as candidate team topology templates according to the fit. Here, N is a preset positive integer that can be configured according to the actual application scenario.

[0064] Furthermore, after selecting the basic topology templates, two or more of the selected templates will be combined to generate composite hybrid topology candidates. During combination, one basic topology is designated as the primary topology, and one or more basic topologies are designated as sub-topologies, with the role boundary delineation rules between the primary and sub-topologies defined. The composite hybrid topology candidates, together with the basic topology candidates, constitute the candidate team topology template set.

[0065] A set of candidate team topologies is formed by matching team topology templates.

[0066] S220, obtain the fit between the task feature vector and the topology template of multiple candidate teams.

[0067] After determining the set of candidate team topology templates, the fit between each candidate template and the feature vector of the current task is calculated one by one.

[0068] Specifically, the fit is calculated using a weighted matching method, and the formula is as follows: Adapt(T) = (Σ wi × sim(fi, pi)) / (Σ wi) Where fi represents the i-th dimension value in the task feature vector, pi represents the applicable profile of the team topology template in the corresponding dimension, sim(fi, pi) represents the dimension matching function, and wi represents the dimension weight.

[0069] For different types of dimensions, the matching function is calculated as follows: For numerical dimensions, sim(fi, pi) = 1 - min(|fi - pi| / ri, 1), where ri is the maximum allowable deviation for that dimension. For enumerated dimensions, the value is 1 for perfect match, 0.5 for adjacent levels, and 0 for inconsistency. For Boolean dimensions, the value is 1 for match and 0 otherwise.

[0070] The weights wi for each dimension can be configured according to the task type or application scenario, or dynamically adjusted based on historical strategy memory. Through the above calculations, a quantified fit score is generated for each candidate team topology template, which reflects the degree of matching between the template and the current task features.

[0071] S230, select the target team topology template from multiple candidate team topology templates based on the fit.

[0072] After obtaining the fit of all candidate team topology templates, the selection is not based solely on fit, but rather on a comprehensive evaluation that incorporates multiple scoring factors.

[0073] Specifically, a comprehensive score is calculated for each candidate team topology. The scoring inputs include: fit, historical success rate, average latency (corresponding to timeliness matching value), average cost, risk penalty coefficient, quality estimate, current resource availability, and compliance matching degree. To address the issue of inconsistent dimensions for different indicators, each scoring input is first normalized to form intermediate scoring parameters.

[0074] In one implementation, a hard compliance constraint filter is first applied, directly eliminating candidate team topologies that do not meet the minimum compliance level, manual review requirements, or tool whitelist requirements. For the candidate team topologies that pass the filter, an interpretable scoring model is then applied. Score(T) = α × Fit + β × Estimated Quality + γ × Success Rate + δ × Time-Based Matching Value + η × Compliance Matching Value ε× Risk Penalty ζ×Resource Penalty The parameters in the aforementioned scoring model (such as α, β, γ, δ, η, ε, ζ, and the weighting coefficients within each sub-item) are the topology scoring parameters. These parameters can be dynamically updated and optimized using historical task execution data recorded in the strategy memory. For example, when the strategy memory shows that the success rate of a certain type of task is significantly improved under a specific topology, γ (success rate weight) or the success rate calculation method for that topology can be adjusted accordingly.

[0075] Each parameter is obtained in at least the following manner: The fit is determined by the weighted matching result between the task feature vector and the team topology template, specifically calculated using the Adapt(T) formula mentioned above.

[0076] The quality prediction value is calculated using the following aggregation method: Q(T) = λ1×Qhist + λ2×Gpass + λ3×Qpred. Where Qhist represents the average quality score of similar tasks in the team topology within the policy memory, Gpass represents the gating pass rate of the corresponding role combination in historical tasks, and Qpred represents the output value of the quality prediction model; when historical samples are insufficient, Qpred degenerates into a rule-based estimate. The input features of the quality prediction model include at least the task feature vector, role composition, evidence dependence, historical gating results, and user feedback.

[0077] The success rate is determined by the number of successful completions of the same or similar tasks in the corresponding team topology and the total number of executions in the strategy memory, and can be smoothed using Laplace: S(T) = (Ns + 1) / (Nt + 2), where Ns is the number of successful completions and Nt is the total number of executions.

[0078] The timeliness matching value is calculated based on the relationship between the task time limit and the estimated completion time of the corresponding team topology: U(T) = max(0, 1 - Et / Dt), where Et represents the estimated completion time and Dt represents the allowed task time. When Et is less than Dt, the closer the value is to 1, the higher the timeliness matching degree.

[0079] The compliance matching value is calculated based on the proportion of candidate team topologies that meet the compliance requirements: C(T) = Mc / Rc, where Rc represents the number of compliance items required to be met by the task and Mc represents the number of compliance items actually met by the team topology; candidate team topologies that do not reach the minimum threshold are directly eliminated before scoring.

[0080] Risk penalty is calculated using a weighted summation method: R(T) = ρ1×Rtask + ρ2×Rconflict + ρ3×Rrole, where Rtask represents the normalized value of the task risk level, Rconflict represents the evidence conflict rate or conflict escalation rate of the team topology in historical tasks, and Rrole represents the historical failure rate of key roles.

[0081] Resource penalties are calculated using P(T) = v1×Costnorm + v2×Utilnorm + v3×Queuenorm, where Costnorm represents the normalized average call cost, Utilnorm represents the normalized current resource utilization rate, and Queuenorm represents the normalized execution queue congestion level.

[0082] The data such as Qhist, Ns, Nt, Rconflict, and historical gating pass rate are derived from policy memory; Et, Costnorm, Utilnorm, and Queuenorm are derived from real-time resource status and runtime monitoring modules; and Mc and Rc are derived from the comparison results of task constraint parsing and team topology template metadata.

[0083] In another implementation, when the historical sample size of similar tasks and candidate team topologies in the policy memory reaches a preset threshold, a machine learning model can be used to automatically output a team topology recommendation score based on task feature vectors, template metadata, historical success rate, average latency, average cost, resource status, and gating results. The input features of the machine learning model include at least: values ​​of each dimension of the task feature vector, team topology template metadata, role quantity configuration, historical success rate, historical average quality score, historical average latency, historical average cost, current resource utilization, tool availability, recent gating pass rates, and average user feedback. To ensure interpretability, the machine learning model can be used to generate an initial ranking, which is then used for final selection by constraint filtering and an interpretable scoring model; or it can be pre-configured to explicitly specify the use of only a linear scoring model, only a machine learning model, or a combination of both. Both the weight parameters in the linear scoring model and the network parameters within the machine learning model can be updated periodically or incrementally based on historical data accumulated in the policy memory.

[0084] Based on the comprehensive scoring results, the candidate team topology templates are ranked, and the candidate team topology template with the highest comprehensive score is selected as the target team topology template. The target team topology template can be a single basic topology type, or a composite hybrid topology composed of two or more basic topology types.

[0085] In this embodiment, the ability to adaptively select the optimal team topology template from a preset team strategy library is realized, avoiding the shortcomings of traditional methods that use a single collaboration mode, and significantly improving the accuracy of multi-agent team topology selection and task adaptability.

[0086] In the above Figure 1 Based on the corresponding embodiments, in order to more clearly demonstrate the process of obtaining the role collaboration structure, this application also provides a possible implementation of obtaining the role collaboration structure in the adaptive construction method of a multi-agent team. Figure 3 This is a flowchart illustrating the process of obtaining the role collaboration structure in an adaptive construction method for a multi-agent team provided in an embodiment of this application. Figure 3 As shown, in S103 above, the target team topology template is instantiated into roles, resulting in a role collaboration structure that includes: S310: Generate a set of roles based on the role slots in the target team topology template.

[0087] After determining the target team topology template, the role slots defined in the template need to be instantiated into specific role sets.

[0088] Specifically, the target team topology template defines a series of role slots. Different types of team topology templates have different default role configurations. The following are examples of role configurations for some topology types: Supervised topology: This topology is centrally managed by a team leader role, and includes one team leader role, several data collection roles, one generation role, and one verification role. The team leader role is responsible for task assignment, progress tracking, and result aggregation, while each execution role reports to the team leader role.

[0089] Parallel collaborative topology: This topology features no central control role or only one lightweight integration role. The configuration includes N similar or dissimilar execution roles and one integration role. Each execution role processes independent subtasks in parallel, sharing evidence and intermediate results via a collaborative bus. The integration role is responsible for aggregating the outputs of all execution roles and forming a unified result.

[0090] Evaluation and optimization topology: This includes an iterative loop between the generation and evaluation roles, configured with one generation role, one evaluation role, and an optional optimization role. The generation role produces initial results, the evaluation role scores the results for quality, and if the score does not reach a preset threshold, the evaluation feedback is returned to the generation role for modification. This process iterates until the score reaches the threshold or the maximum number of iterations is reached. The optimization role can revise the structure and expression of the results before the final output.

[0091] Arbitration Topology: The configuration includes two or more analyst roles and one arbitrator role. Each analyst role independently generates candidate conclusions based on the same or different chains of evidence. The arbitrator role compares the candidate conclusions, makes a ruling, and outputs the final conclusion.

[0092] Handover topology: The configuration includes several execution roles that hand over control in a predefined order. After the previous role completes its task, it transfers the task status and intermediate results to the next role, without the need for a central control role.

[0093] It should be noted that the above role configurations are examples for various topology types. The actual number and types of roles can be adjusted during the instantiation phase based on the task scale and characteristics. Based on the required and optional role slots in the target team topology template, and considering task scale, parallelism, evidence dependency, and timeliness requirements, the number of instances for each type of role is determined, ultimately generating an initial role set. The role set can include at least one or more of the following role types: Team Leader, Planning, Data Acquisition, Verification, Generation, Review, Arbitration, and Integration.

[0094] S320: Based on the set of roles, establish the handover relationships, message routing relationships, and evidence citation relationships between the roles.

[0095] After generating the set of roles, it is necessary to establish the collaborative relationships between the roles to define how the roles interact, how they pass information, and how they share evidence.

[0096] Specifically, based on the predefined relationship templates in the target team topology template, establish multiple relationship types between roles, including at least: Handover Relationship: Defines the control transfer path between roles, that is, which one or more subsequent roles the task status and intermediate results will be handed over to after the previous role completes its task. For example, in a handover topology, each executing role will hand over control in a predefined order.

[0097] Message routing relationships: Define the message sending scope, message priority, and message acknowledgment methods between roles, including which roles can send messages to which roles, and support for direct messages and broadcast messages.

[0098] Evidence Citation Relationships: Defines the relationships between the generation, citation, review, and transfer of evidence objects. In one implementation, the citation method of evidence objects can be indexed using a Uniform Evidence Identifier (UID). An evidence object can be associated with at least one or more of the following fields: evidence identifier, source identifier, acquisition time, version number, confidence level, location of the cited fragment, review status, and expiration time. Generation, verification, and arbitration roles can cite, review, and adjudicate evidence objects based on these fields to improve the traceability of results.

[0099] In addition, role permissions and decision-making rules need to be established. Role permissions define the tools that each role can access, the data objects that can be read and written, the handover actions that can be initiated, and the quality gates that can be triggered; decision-making rules define which role initiates decisions at key nodes, which role reviews them, and the arbitration method for conflict decisions.

[0100] S330 constructs a role-based collaboration structure based on handover relationships, message routing relationships, and evidence citation relationships.

[0101] After establishing the aforementioned relationships, they are integrated into a unified role-based collaboration structure.

[0102] Specifically, the role-based collaboration structure utilizes role diagrams, evidence diagrams, and decision-making mechanisms. Figure 3 Each view is described as follows: Role Graph: This graph corresponds to a set of roles, role permissions, and message rules, and is used to express the control, collaboration, and handover relationships between roles. Roles are treated as nodes, and handover and message routing relationships are used as edges, forming a collaborative network topology among roles.

[0103] Evidence Graph: Corresponding to evidence rules, it is used to express the relationships between the generation, citation, verification, and transmission of evidence objects. The evidence graph uses evidence objects as nodes and evidence citation relationships as edges, forming a complete link of evidence from collection and transmission to consumption.

[0104] Decision graph: Corresponding to decision-making rules, it is used to express the decision initiation, review, and arbitration relationships of key nodes. The decision graph uses decision nodes as nodes and decision triggering relationships and review and arbitration relationships as edges to form the approval and adjudication paths of key decision points.

[0105] The three views mentioned above are interconnected and jointly constrained, together forming a complete description of the role collaboration structure. The role collaboration structure includes at least the following: role set, role permissions, message rules, evidence rules, and decision rules. This structure clarifies which roles are required to participate, what operations each role is allowed to perform, the order or conditions in which roles collaborate, how evidence is transferred and verified, and the approval and review mechanisms for key decision points.

[0106] In this embodiment, a set of roles is generated based on the role slots in the target team topology template, and handover relationships, message routing relationships, and evidence citation relationships are established between roles. Ultimately, a role graph, evidence graph, and decision graph are constructed. Figure 3 The collaborative structure of roles jointly described by multiple views enables the organization of multi-agent teams to have richer semantic expressiveness and stronger interpretability, providing a structured collaborative foundation for subsequent task execution, quality gating and dynamic adjustment, and significantly improving the consistency, reliability and traceability of results in the process of handling complex tasks.

[0107] In the above Figure 1 Based on the corresponding embodiments, in order to more clearly demonstrate the process of obtaining the target intelligent agent team, this application also provides a possible implementation of obtaining the target intelligent agent team in the adaptive construction method of multi-agent teams. Figure 4 This is a flowchart illustrating the process of obtaining the target agent team in an adaptive construction method for a multi-agent team provided in an embodiment of this application. Figure 4 As shown, in S104 above, the role-based intelligent agents of each role in the role collaboration structure are selected from the preset intelligent agent resource pool to obtain the target intelligent agent team, which includes: The role collaboration structure includes a role graph, which in turn includes a set of roles.

[0108] S410, obtain the job requirements of each role based on the role set.

[0109] After the role collaboration structure is built, a specific executable agent needs to be assigned to each role in the role set.

[0110] Specifically, the role collaboration structure includes a role diagram, which contains a set of roles. Each role in the role set is traversed, and its responsibilities are extracted from the role collaboration structure. These responsibilities include at least one or more of the following: the specific task type the role needs to perform, the tools or data resources the role needs to access, the role's input / output specifications in the collaboration relationship, the permission constraints the role needs to meet, and the quality standards the role needs to achieve.

[0111] For example, the responsibilities of a data collection role may include: being able to call specified data retrieval tools, being able to collect evidence according to constraints, and being able to perform preliminary structuring processing on the collected results; the responsibilities of a verification role may include: being able to perform consistency verification on evidence, being able to compare the differences in conclusions from different sources, and being able to output verification reports; the responsibilities of an arbitration role may include: being able to comprehensively analyze multiple candidate conclusions, being able to make a ruling based on evidence and rules, and being able to output a final decision with supporting evidence.

[0112] S420: Based on the responsibilities of each role and the attributes of each agent in the preset agent resource pool, select an agent for each role as the role's agent.

[0113] After clarifying the responsibilities and requirements of each role, the most suitable agent needs to be matched for each role from the preset agent resource pool.

[0114] Specifically, a pre-defined resource pool contains registered multiple available agents, each with its own attribute description. These attributes include at least one or more of the following: capability tags, representing the types of tasks and functionalities the agent can perform; tool permissions, representing the external tools, databases, or interfaces the agent can invoke; historical performance, including historical success rate, average response latency, and average quality score; and current load status, including the number of tasks currently being processed, resource utilization, and queue congestion level.

[0115] For each role in the role set, a matching process is performed in the agent resource pool based on the extracted responsibility requirements. The matching process can employ a multi-dimensional comprehensive evaluation method, considering the following factors: the degree of match between the agent's capability tags and the role's responsibility requirements; whether the agent's tool permissions meet the role's tool access needs; the agent's historical performance on similar roles, including success rate and quality score; and whether the agent's current workload is suitable for undertaking new tasks. A comprehensive score is then calculated based on these factors, and the agent with the highest comprehensive score and meeting the minimum availability requirements is selected as the role's agent.

[0116] In one implementation, when a role requires multiple agents to perform in parallel (e.g., multiple execution roles in a parallel collaborative topology), multiple qualified agent instances can be selected to jointly perform the role. In another implementation, when a role cannot find a qualified agent from the current resource pool, an exception handling mechanism can be triggered, such as waiting for resource release, activating a backup agent, triggering role merging, or reselecting a team topology template.

[0117] S430, which takes the role agents of all roles in the role graph as the target agent team.

[0118] Once all roles in the role set have completed agent mapping, these selected role agents are brought together to form a target agent team oriented towards the current task.

[0119] Specifically, the target agent team is a cluster composed of multiple role-based agents. Each role-based agent assumes corresponding responsibilities within the team and collaborates according to the handover relationships, message routing relationships, and evidence referencing relationships defined in the role collaboration structure. The target agent team not only contains information about each role-based agent but also includes the collaboration constraints and interaction protocols between these agents. These constraints and protocols will be implemented through a collaboration bus during subsequent task execution.

[0120] In this embodiment, the responsibilities of each role are obtained based on the role set, and the role agents are matched and selected according to the responsibilities and agent attributes. Finally, the role agents of all roles in the role graph are gathered into the target agent team. This ensures that the selected agents not only meet the responsibilities and capabilities of the roles, but also take into account the availability and load balancing of current resources. This significantly improves the quality of agent team formation, execution efficiency and robustness, laying the foundation for the collaborative execution of complex tasks.

[0121] In the above Figure 4 Based on the corresponding embodiments, to more clearly demonstrate the process of a role-based intelligent agent performing a task, this application also provides a possible implementation of a role-based intelligent agent performing a task in an adaptive construction method for a multi-agent team. Optionally, in S105 above, according to the role collaboration structure, controlling each role-based intelligent agent in the target intelligent agent team to perform the task corresponding to the task request includes: The role graph also includes role permissions and message rules; the role collaboration structure also includes evidence graph and decision graph.

[0122] S510 controls each role agent in the target agent team to execute the task corresponding to the task request, based on the role permissions, message rules, evidence rules in the evidence graph, and decision rules in the decision graph.

[0123] After the target agent team is formed, it is necessary to uniformly schedule and control each agent in the team according to the rules defined in the role collaboration structure to ensure that the task can be carried out in an orderly manner according to the expected collaboration mode.

[0124] Specifically, the role diagram also includes role permissions and messaging rules. Role permissions define the tools each role can access, the data objects it can read and write, the handover actions it can initiate, and the quality gates it can trigger. For example, a data collection role might be granted permission to call external retrieval tools but not to modify archived evidence objects; an arbitration role might be granted permission to make the final decision, but its decision must be verified by a quality gate. Messaging rules define the scope of messages sent between roles, message priorities, and message acknowledgment methods, including which roles can send messages to which roles, and whether direct messages or broadcast messages are supported.

[0125] The role collaboration structure also includes evidence graphs and decision graphs. Evidence graphs correspond to evidence rules, used to express the generation, citation, verification, and transmission relationships of evidence objects. Evidence rules define the citation method, verification conditions, version control method, and expiration conditions of evidence objects. During task execution, the operational behavior of each role's intelligent agent on evidence objects is controlled according to the evidence rules. For example, after generating evidence, the collection role must index it according to a unified evidence identifier; the verification role must verify its confidence level and verification status when citing evidence; and the generation role must follow version control rules to ensure that the cited version is the latest valid version. Decision graphs correspond to decision rules, used to express the decision initiation, verification, and arbitration relationships of key nodes. Decision rules define which role initiates the decision at key nodes, which role verifies it, and the arbitration method for conflict decisions.

[0126] Role permissions serve as the operational boundary constraints for each intelligent agent, ensuring that each agent performs operations within its authorized scope; message rules serve as the communication standard between roles, ensuring that messages can be reliably transmitted according to predefined routing rules and priorities; evidence rules serve as the basis for the full lifecycle management of evidence objects, ensuring that the entire process of evidence from collection and transmission to consumption is traceable and verifiable; and decision rules serve as the triggering and arbitration mechanism for key decision points, ensuring that when important judgments need to be made, the correct role can initiate decisions at the appropriate time, and that an arbitration role can intervene to adjudicate when disagreements arise.

[0127] Through the joint constraints of the above multi-dimensional rules, the intelligent agents in each role of the target intelligent agent team are finely controlled, so that they execute tasks in an orderly manner according to the collaborative mode defined in the role collaboration structure, until the task is completed or the dynamic adjustment conditions are triggered.

[0128] In this embodiment, by uniformly controlling each role agent in the target intelligent agent team based on role permissions, message rules, evidence rules, and decision rules, a complete control closed loop is formed in four dimensions: operation permissions, communication routing, evidence tracing, and decision arbitration. This significantly improves the standardization, controllability, and auditability of the task execution process, and provides a guarantee for the reliable execution of complex tasks in multi-agent teams.

[0129] In the above Figure 1 Based on the corresponding embodiments, in order to more clearly demonstrate the process of monitoring and dynamically adjusting triggering conditions, this application also provides a possible implementation of monitoring and dynamically adjusting triggering conditions in an adaptive construction method for multi-agent teams. Figure 5 This is a flowchart illustrating the monitoring and dynamic adjustment of triggering conditions in an adaptive construction method for a multi-agent team provided in an embodiment of this application. Figure 5 As shown, in S105 above, the dynamic adjustment of triggering conditions during execution includes: S610 continuously monitors multiple operational metrics of the target intelligent agent team during execution.

[0130] During task execution, it is necessary to monitor the operational status of the target intelligent agent team in real time in order to promptly detect any abnormal situations that may lead to task failure or quality degradation.

[0131] Specifically, the operational metrics of the target intelligent agent team across multiple dimensions are continuously monitored. In one implementation, at least the following metrics may be monitored: Conflict rate: The ratio of the number of contradictory valid evidence entries to the total number of valid evidence entries. It can be calculated as rc = Nc / Ne, where Nc represents the number of evidence pairs that the verified parties determined to be in conflict with the conclusion, and Ne represents the total number of currently valid evidence pairs.

[0132] Output confidence score: This represents the credibility of the aggregated result of the role's self-assessment, the verifying role's score, and the evidence coverage. It can be calculated as qc = ω1×qself + ω2×qverify + ω3×qcover, where qself represents the confidence score of the generated role's self-assessment, qverify represents the verifying role's review score, and qcover represents the evidence coverage.

[0133] Plan completeness: This indicates the proportion of necessary subtasks, roles, and tools that are covered in the current plan. It can be calculated as pc = (Np + Nr + Nt) / (Rp + Rr + Rt), where Np, Nr, and Nt represent the number of necessary subtasks, roles, and tools that are covered in the current plan, respectively, and Rp, Rr, and Rt represent the corresponding total number that should be covered.

[0134] Critical Role Status: Indicates whether a critical role is in an available, degraded, timed-out, or failed state. This can be determined based on whether the critical role is in a successful response, continuous timeout, execution failure, or degraded operation state.

[0135] Resource utilization rate: This represents the proportion of agent resources, tool quotas, or execution queues currently used by the task. It can be calculated as ru = Uused / Ucap, where Uused represents the amount of resources currently used, and Ucap represents the total amount of available resources.

[0136] Tool Availability: Indicates the health check results, success rate, or remaining quota status of the tools required for the task. This can be determined based on the tool's recent success rate, health check results, and remaining quota.

[0137] Risk Level: Indicates the business risk, scope of error impact, or decision sensitivity level corresponding to the current intermediate result. It can be obtained by aggregating the task risk baseline, current evidence conflict status, number of outstanding key issues, and potential scope of error impact.

[0138] Compliance results: This indicates whether the current execution process meets the requirements for record keeping, approval, data boundaries, and manual review. It can be determined based on the completeness of audit records, the fulfillment of approval procedures, the absence of sensitive data exceeding boundaries, and whether the tools are on the whitelist.

[0139] The monitoring frequency of the above-mentioned operational indicators can be configured according to the indicator type and task scenario. For critical indicators (such as the status of key roles and tool availability), a high-frequency monitoring strategy can be adopted to detect anomalies in a timely manner; for relatively stable indicators (such as resource utilization), a moderate monitoring frequency can be adopted to reduce overhead.

[0140] S620 compares each monitored operating indicator with its corresponding preset threshold.

[0141] After obtaining the real-time monitoring values ​​of each operating indicator, these indicator values ​​need to be compared with the pre-configured thresholds to determine whether the current operating status is within the normal range.

[0142] Specifically, each operational metric corresponds to a preset threshold, which can be flexibly configured according to different task scenarios, risk levels, and business requirements. In one implementation, the threshold configuration and judgment logic for each metric are as follows: Conflict of evidence rate: Configure a first threshold θc1 and a second threshold θc2 (where θc2>θc1). When rc>θc1, it indicates a certain degree of conflict of evidence, which needs attention; when rc>θc2, it indicates a serious conflict of evidence, which requires immediate intervention.

[0143] Output confidence level: Configure the lower limit threshold θq. When qc < θq, it indicates that the confidence level of the current output result is insufficient, and a rollback or supplementary verification mechanism needs to be triggered.

[0144] Plan integrity: Configure the threshold θp. When pc < θp, it indicates that the current plan coverage is incomplete, and the plan needs to be regenerated from the planning role.

[0145] Key Role Status: Configure the consecutive timeout threshold n and the maximum number of failures. When a key role experiences n consecutive timeouts or the maximum number of failures, it indicates that the role is no longer able to perform its duties and requires role reconfiguration.

[0146] Resource utilization: Configure the upper limit threshold θr. When ru > θr, it indicates that the resource utilization is too high, and it is necessary to reduce the parallelism, limit tool calls, or switch to a low-resource topology.

[0147] Tool Availability: Configure success rate threshold and health check criteria. When a critical tool is unavailable or its success rate falls below the preset threshold, it indicates a tool-level failure, requiring adjustment of constraint rules or execution path rollback.

[0148] Risk Level: Configure the upper limit of the acceptable risk level θl. When the risk level is higher than θl, it indicates that the current execution process is too risky and the review level needs to be increased or switched to a stronger review topology.

[0149] Compliance Result: Configure compliance pass criteria. When the compliance result fails, it indicates that the execution process violated compliance requirements, and rollback, manual review, or termination of output should be prioritized.

[0150] S630 determines that the dynamic adjustment trigger condition is met when any operating indicator reaches or exceeds a preset threshold.

[0151] After comparing each operational indicator with the preset threshold, a comprehensive judgment is made based on the comparison results to determine whether the dynamic adjustment triggering conditions are met.

[0152] Specifically, the judgment results of each indicator are aggregated. When any operational indicator reaches or exceeds its corresponding preset threshold, it is determined that the current dynamic adjustment trigger condition is met. For example, dynamic adjustment will be triggered when the evidence conflict rate exceeds θc1, the output confidence level is lower than θq, the resource utilization rate exceeds θr, or the compliance result fails.

[0153] In one implementation, when multiple operational metrics simultaneously reach or exceed their respective thresholds, they can be processed according to a preset priority order. For example, corresponding adjustment operations can be performed in the priority order of compliance risk first, result correctness first, and resource protection first. Priority is given to handling compliance failures, as compliance issues may lead to legal or business risks; priority is also given to handling output confidence levels that are too low, as result correctness is core to task success; and timely handling is also necessary when resource utilization is too high to avoid system crashes.

[0154] Once the dynamic adjustment trigger conditions are met, the specific team topology adjustment operation is executed. If all operational metrics are within the normal range, the task continues, and the next round of monitoring and comparison is carried out.

[0155] In this embodiment, by continuously monitoring multiple operational metrics such as evidence conflict rate, output confidence, plan integrity, key role status, resource utilization, tool availability, risk level, and compliance results during task execution, timely and accurate triggering basis is provided for subsequent dynamic adjustments, significantly improving the ability to perceive and adapt to complex dynamic environments.

[0156] In the above Figure 1 Based on the corresponding embodiments, to more clearly demonstrate the process of adjusting the target team topology template, this application also provides a possible implementation of adjusting the target team topology template in the adaptive construction method of a multi-agent team. Optionally, in the above S106, adjusting the target team topology template includes: S710, switch the current team topology template to another type of team topology template.

[0157] When monitored operational metrics indicate that the current team organization method is no longer suitable for the task status, a team topology switch operation can be performed.

[0158] Specifically, team topology switching refers to a comprehensive change in the control relationships, message routing relationships, and decision-making methods between roles. For example, when the evidence conflict rate is consistently higher than the second threshold θc2, the current topology can be switched from a parallel collaboration topology to a debate and arbitration topology, introducing multiple analysis roles to independently generate candidate conclusions, which are then decided by the arbitration role. As another example, when the resource utilization rate is consistently higher than θr, the current topology can be switched from a high-parallel topology to a sequential workflow topology, reducing concurrency to decrease resource consumption.

[0159] In one implementation, the team topology switch is executed as follows: First, retain the valid outputs and evidence indexes of the currently completed roles to avoid losing the progress made due to the switch; then, regenerate the topology-level role relationships and update the message routing template, decision rules, and gating template; finally, map the reusable role instances to the corresponding roles in the new topology to maximize the reuse of existing resources and reduce the switch cost.

[0160] S720 performs role reconfiguration on the target team topology template.

[0161] When monitored operational metrics indicate that there is a problem with the current role configuration, a role reconfiguration operation can be performed.

[0162] Specifically, role reconfiguration refers to replacing, adding, removing, merging, splitting, or adjusting permissions of role instances without changing the main topology type. For example, when a data collection role times out n times consecutively, it can be replaced with a backup data collection role, and the concurrency can be reduced.

[0163] In one implementation, role reconfiguration can be performed in the following ways: role replacement, role addition, role demotion, role merging, or permission boundary re-division. After a role is replaced, unfinished tasks of the original role can be recycled to the shared task pool and continued by the new role, ensuring that tasks are not interrupted due to role changes.

[0164] S730 injects a verification node into the target team topology template. The verification node is used to perform independent verification on intermediate or final results.

[0165] When the monitored operation metrics indicate uncertainties in the current result quality, a verification node injection operation can be executed.

[0166] Specifically, verification node injection refers to temporarily inserting a role mechanism with special verification capabilities into the original execution chain for one or more independent verifications of specified conclusions, evidence chains, or key intermediate results. For example, when the evidence conflict rate rc satisfies θc1 < rc ≤ θc2, an evidence verification role can be injected without immediately switching the topology to perform source cross-comparison, timestamp verification, and confidence review on the conflicting evidence.

[0167] In one implementation, the specific execution method of verification node injection is as follows: A verification role link can be inserted before the evidence submission node, intermediate result integration node, or final output node. The verification role link can at least include one or more combinations of "evidence verification role → review role → arbitration role", and the verification result can be used as a subsequent gating input to provide a basis for quality judgment.

[0168] In one possible implementation, adjusting the target team topology template further includes: adjusting the constraint rules of the target team topology template.

[0169] When the monitored operation metrics indicate that the current execution boundary conditions need to be tightened or relaxed, a constraint rule adjustment operation can be executed.

[0170] Specifically, constraint rule adjustment refers to dynamically adjusting various constraint boundaries during task execution without changing the team topology structure and role configuration to adapt to changes in the operating state. Constraint rule adjustment can include one or more of the following methods: increasing the evidence threshold, requiring evidence to have higher confidence or more sufficient sources to be adopted; narrowing the available tool range, restricting the external tools or interfaces that roles can call, and reducing security risks; increasing the review level, increasing the manual review ratio or introducing more strict automatic verification logic; tightening the output format requirements, adding required fields to the output template or strengthening field integrity verification.

[0171] For example, when the compliance result is close to the threshold, the manual review ratio can be increased and external tool calls can be restricted to ensure that the execution process meets compliance requirements; when the output confidence is continuously low, the evidence sufficiency threshold can be increased, requiring more valid evidence to support the conclusion before output.

[0172] In one implementation, the specific execution method for adjusting the constraint rules is as follows: The threshold for sufficiency of evidence can be dynamically increased, the proportion of manual review can be increased, the scope of external tool calls can be restricted, the scope of writable objects for a role can be narrowed, or mandatory fields can be added to the output template. The adjusted constraint rules take effect immediately, and subsequent execution processes will be verified and controlled according to the new constraint boundaries.

[0173] In another possible implementation, adjusting the target team topology template also includes performing an execution path rollback on the target team topology template.

[0174] When the monitored operational metrics indicate that the current execution path can no longer produce results that meet quality requirements, an execution path rollback operation can be performed.

[0175] Specifically, execution path rollback refers to restoring the current execution state to the most recent stable version that passed quality gating, and re-executing subsequent steps from that stable version after completing the recertification, role change, or topology switch.

[0176] For example, when the output confidence level is lower than θq, it can fall back to the evidence integration node and regenerate the conclusion after the supplementary evidence is completed; when a key role fails and cannot be recovered quickly, it can fall back to the task assignment node and re-execute the role's task after the role replacement is completed.

[0177] In one implementation, the specific execution method for path rollback is as follows: The execution environment is restored based on the most recently gated plan version, evidence version, and intermediate result version, ensuring that the execution starting point after rollback is in a quality-verified state. Simultaneously, the abnormal reasons causing the rollback are written into the policy memory for reference when adjusting thresholds and topology selection for subsequent similar tasks, forming a closed loop of experience accumulation and continuous optimization.

[0178] It should be noted that the team topology switching, role reconfiguration and verification node injection, constraint rule adjustment, and execution path rollback described above are all different types of dynamic adjustment operations. In actual execution, one or more of the five adjustment methods described above can be selected and combined based on the type and severity of the triggering conditions and the current task's context. When multiple triggering conditions are met simultaneously, the dynamic adjustment action can be selected in the following order: compliance risk priority, result correctness priority, and resource protection priority. After the dynamic adjustment is completed, the current team topology score is recalculated to determine whether to restore the main process.

[0179] In one implementation scenario, if the current task is a high-risk supply chain anomaly handling task, an initial supervised topology is adopted. The role configuration includes one team leader, two data collection roles, one generation role, and one verification role. When the two data collection roles obtain conflicting delivery dates from the warehousing system and the logistics system, respectively, and calculate rc = 0.31, which is higher than θc1 = 0.25 but lower than θc2 = 0.45, the topology is not switched immediately. Instead, an evidence verification role is injected into the current link to perform source cross-comparison, timestamp verification, and confidence level review of the conflicting evidence. If rc still rises to 0.52 after review, a team topology switch is triggered, changing the original supervised topology to a debate and arbitration topology, and adding two analysis roles and one arbitration role. Among them, the two analysis roles generate handling plans based on the warehousing evidence chain and the logistics evidence chain, respectively, while the arbitration role outputs the final decision based on the latest evidence, timeliness requirements, and risk constraints. If the original verification role times out a preset number of times (n) consecutively during the switchover process, a role reconfiguration can be performed simultaneously, replacing it with a backup verification role, and any unfinished verification tasks of the original role will be returned to the shared task pool. Finally, the arbitration-confirmed result is written back to the collaboration bus, and the role graph, evidence graph, and decision graph are updated, restoring the system to a new stable execution state.

[0180] In this embodiment, by using three parallel adjustment mechanisms—team topology switching, role reconfiguration, and verification node injection—differentiated adaptive adjustments can be performed based on different anomaly types detected during runtime, significantly improving the robustness and completion rate of complex tasks when facing evidence conflicts, role anomalies, resource shortages, or risk changes.

[0181] In the above Figure 1 Based on the corresponding embodiments, to more clearly demonstrate the process of quality gating verification, this application also provides a possible implementation of quality gating verification in an adaptive construction method for multi-agent teams. Optionally, based on the above S101-S106, the method further includes: S810 performs quality gating checks on the integrity of the role collaboration structure during task execution, at the plan formation node.

[0182] In the task execution process, quality gating can be set at multiple key nodes to ensure that the output at each stage meets the preset quality standards. Each quality gating node is a verification point set in parallel, independent of each other, and triggered at different execution stages.

[0183] Specifically, the plan formation node refers to the point where the target team topology is completed, the role collaboration structure is generated, but the specific tasks have not yet started to be executed. The plan formation node is located before the task execution starts. At the plan formation node, quality gating checks are performed on the completeness of the role collaboration structure plan to check whether the task breakdown, role assignment, tool preparation, and output goals are complete before execution.

[0184] The integrity of a plan can be verified by at least one or more of the following: required subtask coverage, which is the ratio of the number of subtasks currently covered to the total number of subtasks that should be covered; role coverage, which is the ratio of the number of roles assigned to the total number of required roles; and tool readiness, which is the ratio of the number of tools ready to the total number of tools required for the task.

[0185] If the plan integrity check passes, continue task execution. If the plan integrity check fails, return to the planning role and regenerate the plan until it meets the integrity requirements.

[0186] S820 performs quality gating checks on the sufficiency and consistency of submitted evidence at key evidence submission nodes.

[0187] The key evidence submission node refers to the point where the evidence collection role completes the evidence gathering and submits it to the evidence sharing space, but before it is used by the generation or analysis role to generate conclusions. The key evidence submission node is located before the evidence consumption stage. At the key evidence submission node, quality gating checks are performed on the sufficiency and consistency of the submitted evidence. This is used to check whether the key evidence is sufficient, whether there are obvious conflicts, and whether the evidence meets the timeliness requirements before generation or decision-making.

[0188] The sufficiency and consistency of evidence can be determined by at least one or more of the following: sufficiency of evidence can be determined by the ratio of the number of key evidence items collected to the preset minimum number of evidence items; consistency of evidence can be determined by the evidence conflict rate (the ratio of the number of mutually contradictory valid evidence items to the total number of valid evidence items), the degree of difference in conclusions between evidence sources, or whether the review results are consistent; and timeliness of evidence can be determined by comparing the timestamp of the evidence with the timeliness requirements of the task.

[0189] When the sufficiency and consistency of evidence pass the verification, subsequent generation or decision-making steps are allowed to continue. When the verification fails, actions such as supplementary evidence (requiring the collection role to supplement missing evidence), review (the verification role to perform a second verification of the questionable evidence), or verification node injection (inserting an evidence verification role to perform a special verification) may be triggered.

[0190] S830 performs quality gating checks on the completeness of intermediate results and their matching with evidence at the intermediate result integration node.

[0191] An intermediate result integration node refers to the point where, after multiple parallel or sequential execution roles have produced their intermediate conclusions, and before these conclusions are converged or integrated into a higher-level conclusion, the intermediate result integration node is located before the result convergence. At the intermediate result integration node, quality gating checks are performed on the completeness of the intermediate results and their consistency with the evidence. This is used to check whether the intermediate conclusions are consistent, whether the cited evidence is complete, and whether dependencies are satisfied before the results from multiple roles are converged.

[0192] The completeness and matching degree of intermediate results can be verified by at least one or more of the following: consistency of conclusions, which can be determined by the degree of difference between intermediate conclusions produced by different roles; completeness of evidence citation, which can be determined by whether each key conclusion is bound with sufficient evidence citation; satisfaction of dependencies, which can be determined by whether all the preconditions on which the current intermediate result depends have been met; matching degree between conclusions and evidence, which can be determined by the proportion of key conclusions that have been bound with evidence citations or the result of conclusion-evidence mapping verification.

[0193] If the integrity and matching accuracy of the intermediate results pass the verification, subsequent integration steps can proceed. If the verification fails, the process can be rolled back to the relevant roles for further correction, requiring them to supplement or modify the problematic intermediate results.

[0194] S840 performs quality gating checks on the compliance and risk acceptability of the final result at the output node.

[0195] The output node refers to the point where all task execution steps have been completed and the final result is about to be delivered to the requester. The output node is the final checkpoint before task delivery. At the output node, quality gating checks are performed on the compliance and risk acceptability of the final result. This is used to check the consistency between the conclusion and evidence, compliance, completeness of the output format, and residual risks before the result is delivered.

[0196] Compliance and risk acceptability can be verified by at least one or more of the following: compliance, which can be verified by whether the approval process is complete, whether the processing of sensitive data meets the requirements, and whether the tools used are on the whitelist; completeness of output format, which can be verified by whether the required chapters, fields, and structured tags in the target template are complete; whether the risk is within an acceptable range, which can be verified by comparing the residual risk score with the preset risk threshold; and the degree of matching between conclusions and evidence, which can be verified by the consistency between key conclusions and the cited evidence.

[0197] When the final result passes compliance and risk acceptability checks, the final result is allowed to be output, and the task enters the completed state. When the checks fail, one or more of the following actions can be taken depending on the reason for the failure: rejection and redo (requiring the generation role to regenerate the result), supplementary evidence (requiring the collection role to supplement the missing key evidence), upgrading the review level (introducing a more stringent verification mechanism), injecting a verification node (inserting an arbitration role to independently adjudicate the conclusion), execution path rollback (rolling back to the previous stable state that passed the gating), switching team topology (switching to a topology type that is more suitable for the current quality requirements), or terminating output (abolishing the task if the quality requirements cannot be met).

[0198] In this embodiment, by setting quality gating in parallel at the planning node, key evidence submission node, intermediate result integration node, and output node, multi-stage quality control of the entire task execution process is achieved, effectively reducing the risk of error propagation in team collaboration and ensuring high-quality task output.

[0199] To more clearly illustrate the specific implementation process of the multi-agent team adaptive construction method provided in this application embodiment in a real-world application scenario, the following is a description through specific embodiments.

[0200] Example 1: Collaborative Preparation of Bidding Response Documents A company needs to complete a large project bidding response document within a limited time. The task involves extracting key points of the bidding document, verifying qualification clauses, collecting historical project cases, drafting technical solutions, reviewing risk clauses, and final layout and integration.

[0201] After receiving a task request, the task feature vector corresponding to the task request is extracted. In this embodiment, the extracted task feature vector is as follows: high complexity, high parallelizability, medium-high evidence dependence, medium-high risk level, high timeliness level, medium tool dependence, and medium resource budget.

[0202] Based on the task feature vector, a target team topology template is determined from a pre-defined team strategy library. Specifically, multiple candidate team topology templates are first generated. After hard constraint filtering and comprehensive scoring, a composite hybrid topology combining supervised topology and parallel collaborative topology is selected as the target team topology template. This target team topology template uses supervised topology as the main topology and parallel collaborative topology as the sub-topology. Roles are instantiated for this target team topology template to obtain a role collaboration structure. The role configuration includes: one team leader role, responsible for overall task control and result aggregation; three acquisition roles, which, as parallel collaborative sub-topologies, complete the retrieval of qualification clauses, case materials, and format requirements; one generation role, responsible for generating a draft technical solution; one verification role, responsible for verifying the coverage of bidding requirements; and one integration role, responsible for outputting the final version. Matching role agents are selected for the above roles from a pre-defined agent resource pool to obtain the target agent team.

[0203] During task execution, the system controls the execution of tasks by each intelligent agent according to the role-based collaboration structure and continuously monitors various operational metrics. If a conflict is detected between the draft technical solution and the equipment parameters in the qualification terms, and the evidence consistency is below a preset threshold, it is determined that the dynamic adjustment trigger condition is met. Based on the type and severity of the trigger condition, a verification node injection operation is selected to introduce an additional evidence verification role into the current execution chain to perform source cross-comparison and confidence level verification of the conflicting parameters. After verification, the conflict is resolved, execution resumes, and subsequent tasks continue until completion.

[0204] Example 2: Supply Chain Anomaly Handling and Customer Communication Arrangement A manufacturing company experienced supply chain anomalies during production, including raw material delays, inventory discrepancies, and customer order requests. The company needed to quickly develop a response plan, verify communication with customers, and simultaneously generate an internal execution checklist.

[0205] After receiving a task request, the task feature vector corresponding to the task request is extracted. In this embodiment, the extracted task feature vector is as follows: medium-high complexity, medium parallelizability, high evidence dependence, high risk level, high timeliness level, high interaction frequency, and medium resource budget.

[0206] Based on the task feature vector, a target team topology template is determined from a pre-defined team strategy library. Specifically, multiple candidate team topology templates are first generated. A supervised topology is then selected as the target team topology template. Roles are instantiated for this target team topology template to obtain a role collaboration structure. The initial role configuration includes: one team leader role, two data collection roles, one generation role, one verification role, and one communication role. Matching role agents are selected from a pre-defined agent resource pool for each of the above roles to obtain the target agent team. During task execution, the team leader role schedules the data collection roles to collect supply, inventory, order, and logistics evidence, while the generation role formulates customer communication plans and internal handling suggestions based on the current evidence.

[0207] During execution, various operational metrics are continuously monitored. Two data collection roles are responsible for collecting supply-side and logistics-side evidence, respectively. The generation role formulates customer communication plans and internal handling suggestions based on the current evidence, while the verification role is responsible for comparing the consistency between delivery dates, inventory quantities, and mitigation measures. When the verification role calculates an evidence conflict rate rc = 0.28, it is determined to be higher than the verification node injection threshold θc1 = 0.25. Therefore, an evidence verification role is inserted without interrupting the main topology. The evidence verification role performs a specific review of the warehouse system's exported records, logistics return records, and order change timestamps, and outputs a conflict review report. If the review report indicates that the conflict has not been eliminated and rc has increased to 0.49, it is determined to exceed the topology switching threshold θc2 = 0.45. Therefore, the dynamic adjustment trigger condition is met, and the following operations are performed: First, freeze the current version of customer communication plans, internal handling suggestions, and cited evidence to ensure that no progress is lost during the adjustment process. Second, switch the team topology from a supervisory topology to a debate and arbitration topology. Third, add two new analysis roles to independently generate candidate handling plans based on the warehousing evidence chain and the logistics evidence chain, respectively. Fourth, add one arbitration role to output a final ruling based on the two candidate plans, risk constraints, and the latest evidence. Fifth, retain the original verification role as a gating input role to perform final consistency verification on the arbitration output.

[0208] If the original verification role times out a preset number of times during the above process, the role will be reconfigured, replacing the backup verification role with a new gating execution role, and restricting the original role's access to the write interface to prevent abnormal roles from interfering with subsequent execution.

[0209] Ultimately, after the results output by the arbitration role are verified by two gated nodes, the intermediate result integration node and the output node, the communication role generates customer notification text, and the execution role generates internal work orders for expedited procurement, production scheduling adjustments, and logistics coordination.

[0210] Example 3: Generation of Medical Literature Review and Clinical Evidence Summary A research team needs to complete a comprehensive literature review, evidence level assessment, and structured abstract generation for treatment options for a specific disease within a short period to support internal research meetings. This task requires traceability of results and the ability to explain conflicts between conclusions from different studies.

[0211] After receiving a task request, the task feature vector corresponding to the task request is extracted. In this embodiment, the extracted task feature vector is as follows: high complexity, medium-high parallelizability, high evidence dependence, high risk level, medium timeliness level, high tool dependence, and high compliance requirements.

[0212] Based on the task feature vector, a target team topology template is determined from a pre-defined team strategy library. Specifically, multiple candidate team topology templates are first generated. Subsequently, a composite hybrid topology combining parallel collaboration topology and evaluation optimization topology is selected as the target team topology template. This target team topology template uses parallel collaboration topology as the main topology and evaluation optimization topology as the sub-topology. Roles are instantiated for this target team topology template to obtain a role collaboration structure. The role configuration includes: 3 data collection roles, which search different databases and guideline sources in parallel; 1 evidence verification role, which uniformly judges the quality of literature and the level of evidence; 1 generation role, which is responsible for generating the initial review draft; 1 review role, which is responsible for verifying whether the conclusions match the evidence; and 1 optimization role, which is responsible for iteratively revising the review structure and abstract expression. Among them, the review role and the optimization role constitute an iterative loop of the evaluation optimization sub-topology. When the review role determines that the matching degree between the conclusion and the evidence does not meet the standard, the review opinion is returned to the generation role or the optimization role for modification. Matching role agents are selected for the above roles from a pre-defined agent resource pool to obtain the target agent team.

[0213] During task execution, the system controls the execution of tasks by each agent according to the role collaboration structure and continuously monitors various operational indicators. At the intermediate results integration node, the review role discovers a conflict between two studies on key efficacy indicators, and the initial drafts fail to adequately explain sample differences and study design differences. The evidence conflict rate exceeds a preset threshold, thus meeting the dynamic adjustment trigger condition. Based on the type and severity of the trigger condition, two adjustment operations are selected: adjusting the constraint rules and injecting validation nodes. On the one hand, the evidence sufficiency threshold is raised, requiring conclusions to be supported by more substantial evidence; on the other hand, an arbitration role is inserted to provide a specific explanation of the conflicting conclusions, forming an independent conflict analysis paragraph. After the adjustment is completed, execution resumes, and subsequent tasks continue.

[0214] Finally, a structured review result with an index of evidence sources and conflict interpretation paragraphs is output. All conclusions are bound to corresponding evidence citations, and conflict sections are accompanied by independent arbitration interpretations, meeting the traceability standard of high compliance requirements.

[0215] The following describes an adaptive construction apparatus and electronic device for a multi-agent team provided in this application, which are used to implement the application. The specific implementation process and technical effects are described above and will not be repeated below.

[0216] Figure 6 A schematic diagram of an adaptive building device for a multi-agent team provided in an embodiment of this application is shown below. Figure 6 As shown, the adaptive building apparatus of this multi-agent team includes: The receiving module 1000 is used to receive task requests and extract the task feature vector corresponding to the task request.

[0217] Select module 2000, which is used to determine the target team topology template from the preset team strategy library based on the task feature vector.

[0218] Module 3000 is used to instantiate roles from the target team topology template to obtain the role collaboration structure.

[0219] The selection module 2000 is also used to select role agents of each role in the role collaboration structure from the preset agent resource pool to obtain the target agent team.

[0220] The execution module 4000 is used to control each role-based intelligent agent in the target intelligent agent team to execute the task corresponding to the task request according to the role collaboration structure, and to monitor and dynamically adjust the triggering conditions during the execution process.

[0221] The Refactoring Module 5000 is used to adjust the target team topology template when the dynamic adjustment trigger conditions are detected, and to continue executing the task based on the adjusted team topology template until the task is completed.

[0222] Optionally, module 2000 is selected, specifically for determining multiple candidate team topology templates from a preset team strategy library based on the task feature vector; obtaining the fit between the task feature vector and the multiple candidate team topology templates; and selecting the target team topology template from the multiple candidate team topology templates based on the fit.

[0223] Optionally, module 3000 is constructed, specifically used to generate a set of roles based on the role slots in the target team topology template; establish handover relationships, message routing relationships, and evidence citation relationships between roles based on the set of roles; and construct a role collaboration structure based on the handover relationships, message routing relationships, and evidence citation relationships.

[0224] Optionally, module 2000 is selected, specifically for the role collaboration structure including: a role graph, which includes: a set of roles; obtaining the responsibilities of each role based on the set of roles; selecting an agent as the role agent for each role based on the responsibilities of each role and the attributes of each agent in the preset agent resource pool; and taking the role agents of all roles in the role graph as the target agent team.

[0225] Optionally, the execution module 4000, specifically used for the role graph, also includes: role permissions and message rules; the role collaboration structure also includes: evidence graph and decision graph; based on the role permissions, message rules, evidence rules in the evidence graph, and decision rules in the decision graph, it controls each role agent in the target intelligent agent team to execute the task corresponding to the task request.

[0226] Optionally, the adaptive construction device of the multi-agent team also includes a monitoring module 6000, which is used to continuously monitor multiple operational indicators of the target agent team during execution; compare each monitored operational indicator with a corresponding preset threshold; and determine that the dynamic adjustment trigger condition is met when any operational indicator reaches or exceeds the preset threshold.

[0227] Optionally, the refactoring module 5000 is specifically used to switch the current team topology template to another type of team topology template; or to reconfigure the roles of the target team topology template; or to inject verification nodes into the target team topology template, which are used to perform independent verification on intermediate or final results.

[0228] Optionally, the monitoring module 6000 is also used to perform quality gating checks on the integrity of the plan of the role collaboration structure at the plan formation node during the execution of the task; or, at the key evidence submission node, to perform quality gating checks on the sufficiency and consistency of the submitted evidence; or, at the intermediate result integration node, to perform quality gating checks on the integrity of the intermediate results and their matching degree with the evidence; or, at the output node, to perform quality gating checks on the compliance and risk acceptability of the final result.

[0229] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more digital signal processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0230] Figure 7 This is a schematic diagram of an electronic device provided in an embodiment of this application. The device may be a computing device or a server with computing processing capabilities.

[0231] The electronic device 10 includes a processor 11, a storage medium 12, and a bus 13. The storage medium 12 stores program instructions executable by the processor 11. When the electronic device 10 is executed, the processor 11 communicates with the storage medium 12 via the bus 13, and the processor 11 executes the program instructions to perform the above-described method embodiment. The specific implementation and technical effects are similar and will not be described in detail here.

[0232] Optionally, this application also provides a program product, such as a computer-readable storage medium, including a program that, when executed by a processor, performs the above-described method embodiments.

[0233] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0235] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0236] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0237] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An adaptive construction method for multi-agent teams, characterized in that, The method includes: Receive a task request and extract the task feature vector corresponding to the task request; Based on the task feature vector, determine the target team topology template from the preset team strategy library; The target team topology template is instantiated with roles to obtain the role collaboration structure; Select the role-based intelligent agents of each role in the role collaboration structure from the preset intelligent agent resource pool to obtain the target intelligent agent team; Based on the role collaboration structure, control each role agent in the target agent team to execute the task corresponding to the task request, and monitor and dynamically adjust the triggering conditions during the execution process; When the dynamic adjustment triggering condition is detected, the target team topology template is adjusted, and the task continues to be executed based on the adjusted team topology template until the task is completed.

2. The method according to claim 1, characterized in that, The step of determining the target team topology template from a preset team strategy library based on the task feature vector includes: Based on the task feature vector, multiple candidate team topology templates are determined from the preset team strategy library; Obtain the fit between the task feature vector and the topology templates of multiple candidate teams; Based on the fit, the target team topology template is selected from the multiple candidate team topology templates.

3. The method according to claim 1, characterized in that, The instantiation of roles in the target team topology template to obtain the role collaboration structure includes: Generate a set of roles based on the role slots in the target team topology template; Based on the set of roles, establish the handover relationships, message routing relationships, and evidence citation relationships among the roles; The role collaboration structure is constructed based on the handover relationship, the message routing relationship, and the evidence citation relationship.

4. The method according to claim 1, characterized in that, The role collaboration structure includes: a role graph, which includes: a set of roles; selecting role agents from a preset agent resource pool to obtain a target agent team, including: The job responsibilities of each role are obtained based on the set of roles. Based on the responsibilities of each role and the attributes of each agent in the preset agent resource pool, an agent is selected as the role agent for each role. The role agents of all the roles in the role graph are taken as the target agent team.

5. The method according to claim 4, characterized in that, The role graph also includes: role permissions and message rules; the role collaboration structure also includes: evidence graph and decision graph, and controlling each role agent in the target agent team to execute the task corresponding to the task request according to the role collaboration structure includes: Based on the role permissions, the message rules, the evidence rules in the evidence graph, and the decision rules in the decision graph, control each role agent in the target agent team to execute the task corresponding to the task request.

6. The method according to claim 1, characterized in that, The monitoring and dynamic adjustment of triggering conditions during execution includes: During execution, multiple operational metrics of the target intelligent agent team are continuously monitored; Each of the monitored operational indicators is compared with its corresponding preset threshold. When any of the aforementioned operating indicators reaches or exceeds the preset threshold, it is determined that the dynamic adjustment trigger condition is met.

7. The method according to claim 1, characterized in that, Adjustments were made to the target team topology template, including: Switch the current team topology template to another type of team topology template; or... Reconfigure roles in the target team topology template; or, A verification node is injected into the target team topology template. The verification node is used to perform independent verification on intermediate or final results.

8. The method according to claim 1, characterized in that, The method further includes: During the execution of the task, at the plan formation node, a quality gating check is performed on the plan integrity of the role collaboration structure; or, At key evidence submission points, perform quality gating checks on the sufficiency and consistency of the submitted evidence; or, At the intermediate result integration node, quality gating checks are performed on the completeness of the intermediate results and their matching degree with the evidence; or, At the output node, quality gating checks are performed on the compliance and risk acceptability of the final result.

9. An adaptive building device for multi-agent teams, characterized in that, The device includes: The receiving module is used to receive task requests and extract the task feature vector corresponding to the task request; The selection module is used to determine the target team topology template from a preset team strategy library based on the task feature vector. The module is used to instantiate roles in the target team topology template to obtain the role collaboration structure; The selection module is also used to select the role intelligent agents of each role in the role collaboration structure from the preset intelligent agent resource pool to obtain the target intelligent agent team; The execution module is used to control each role agent in the target agent team to execute the task corresponding to the task request according to the role collaboration structure, and to monitor and dynamically adjust the triggering conditions during the execution process. The refactoring module is used to adjust the target team topology template when the dynamic adjustment triggering condition is detected, and to continue to execute the task based on the adjusted team topology template until the task is completed.

10. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores program instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus, and the processor executes the program instructions to perform the steps of the adaptive construction method for a multi-agent team as described in any one of claims 1 to 8.

Images