A federated capability management and unified scheduling system for multi-agent collaboration

Abstract

This invention relates to the fields of artificial intelligence, multi-agent collaborative scheduling, and federated security management. Specifically, it is a federated capability management and unified scheduling system for multi-agent collaboration, comprising: a central scheduler receiving collaborative task requests across multiple local agent nodes and obtaining capability declaration information containing only the capability tags of the local agent nodes; constructing prompt word templates and generating an initial fine-grained task decomposition scheme; extracting cross-domain call links, statistically analyzing the frequency of cross-domain calls and data interaction dimensions, predicting the communication interruption probability of local agent nodes and comparing it with a security risk threshold; if the probability is lower than the threshold, a fine-grained scheme is adopted; if the probability is higher than or equal to the threshold, a minimum-privilege interaction coarse-grained scheduling scheme is generated and distributed; and local agent nodes executing sub-tasks and reporting their status to maintain core business continuity without exposing underlying private data.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence, multi-agent collaborative scheduling, and federated security management, specifically a federated capability management and unified scheduling system for multi-agent collaboration. Background Technology

[0002] A federated capability management and unified scheduling system for multi-agent collaboration is applied to collaborative processing scenarios across regions and authority boundaries. Its scheduling stability directly depends on the accuracy of the visibility of capabilities of each local agent node and the rationality of cross-domain task orchestration. Therefore, achieving efficient collaborative scheduling without exposing underlying private data is the key to ensuring the continuous operation of the federated network.

[0003] Existing multi-agent collaborative scheduling methods have many problems. For example, they often use a central side to directly split tasks and allocate nodes based on static capability registration or preset rules. Although this can achieve basic collaboration, it is difficult to simultaneously take into account the impact of cross-domain call frequency, data interaction complexity, and permission conflicts caused by differences in security boundaries of different nodes. Especially in scenarios with high concurrency, strict data interaction security restrictions, or abnormal fluctuations in network requests, it is easy for tasks to be executable at the business layer, but fail to pass access control verification stably at the local security gateway. This leads to node communication interruption, delayed scheduling rollback, or a decline in the continuity of core business, and cannot effectively meet the stable collaboration requirements in federated networks. Summary of the Invention

[0004] The purpose of this invention is to provide a federated capability management and unified scheduling system for multi-agent collaboration, addressing the following technical problems: Existing multi-agent collaborative scheduling technologies have significant shortcomings in perceiving permission conflicts during cross-domain task orchestration and in preventing communication interruptions based on node security boundary differences in high-concurrency scenarios. There is an urgent need to propose a federated capability management and unified scheduling system for multi-agent collaboration that can more accurately quantify cross-domain permission conflicts and predict communication interruption probabilities, and dynamically and adaptively switch scheduling strategies to ensure the continuity of core services. The purpose of this invention can be achieved through the following technical solutions: A federated capability management and unified scheduling system for multi-agent collaboration includes: The central scheduler is configured to: receive collaborative task requests involving multiple local agent nodes with built-in security isolation mechanisms; obtain capability declaration information reported by each local agent node; construct prompt word templates from the collaborative task requests and capability declaration information, input them into a pre-set generative artificial intelligence language model for parsing, and generate an initial fine-grained task decomposition scheme containing multiple sub-tasks; extract cross-domain call links between sub-tasks in the initial fine-grained task decomposition scheme, and count the cross-domain call frequency and cross-domain data interaction dimension of the cross-domain call links; and calculate the cross-domain permission conflict index by combining the trust weights pre-configured for each local agent node, the cross-domain call frequency, and the cross-domain data interaction dimension. Based on the cross-domain permission conflict index, the probability of communication interruption triggered by each local intelligent agent node to the built-in security isolation mechanism is predicted through a preset risk assessment mechanism. If the communication interruption probability is less than a preset security risk threshold, the initial fine-grained task decomposition scheme will be used as the target scheduling strategy. If the communication interruption probability is greater than or equal to the security risk threshold, the initial fine-grained task decomposition scheme is abandoned, and a minimum-privilege interaction coarse-grained scheduling scheme is generated by merging cross-domain interaction subtasks as the target scheduling strategy; the target scheduling strategy is then distributed to the corresponding local agent node. The local intelligent agent node has the built-in security isolation mechanism and is configured to: execute the corresponding sub-task according to the target scheduling strategy and feed back the task execution status to the central scheduler.

[0005] Optionally, the central scheduler includes: The task parsing module is configured to receive collaborative task requests and generate an initial fine-grained task decomposition scheme using a generative artificial intelligence language model; the conflict perception module is configured to acquire capability declaration information, calculate the cross-domain permission conflict index, and predict the probability of communication interruption; the dynamic scheduling module is configured to determine the target scheduling strategy based on the comparison result between the probability of communication interruption and the security risk threshold, and distribute the target scheduling strategy to the corresponding local intelligent agent node.

[0006] Optionally, the local agent node includes: The capability registration module is configured to generate capability declaration information and upload it to the central scheduler; the local security gateway module has a preset maximum concurrent request connection threshold and is configured to monitor cross-domain call requests in the cross-domain call chain generated when executing the target scheduling strategy, and perform access control based on local permission rules; the task execution module is configured to execute sub-tasks after the local security gateway module verifies them and generate task execution status.

[0007] Optionally, the conflict sensing module is configured to: predict the probability of communication interruption. Obtain historical permission alarm records of local intelligent agent nodes; count the number of alarms in the historical permission alarm records, construct a feature vector by combining the number of alarms with the cross-domain permission conflict index, and input it into a pre-trained risk prediction model; calculate the classification probability value corresponding to the feature vector through the risk prediction model, which serves as the communication interruption probability of the local intelligent agent node triggering the built-in security isolation mechanism.

[0008] Optionally, the central scheduler has a preset scheduling objective function, which includes global resource allocation weight parameters and permission isolation weight parameters. When generating a least-permission interaction coarse-grained scheduling scheme, it is configured as follows: For a pre-configured unit task cycle, retrieve cross-domain interaction subtasks in the initial fine-grained task decomposition scheme whose cross-domain call frequency is greater than a pre-set frequency threshold to form a set of high-frequency cross-domain interaction subtasks; merge the set of high-frequency cross-domain interaction subtasks into a single domain execution task; Based on the proportion of the high-frequency cross-domain interaction subtask set to the total concurrent calls within a unit task cycle, the corresponding target adjustment step size is dynamically calculated and obtained. Based on the target adjustment step size, the global resource allocation weight parameter and the permission isolation weight parameter are dynamically adjusted in reverse, and the updated scheduling objective function is used to reallocate tasks for tasks executed within a single domain, generating a least-permission interaction coarse-grained scheduling scheme.

[0009] Optionally, the central scheduler is also configured as follows: When a cross-domain call request not registered in the capability declaration information is detected in a subtask parsed by the generative artificial intelligence language model, the cross-domain call request is marked as an unknown cross-domain signal. If the unknown cross-domain signal does not match the legal access policy pre-configured by the central scheduler, the collaborative task request is determined as unstructured abnormal request data, and the cross-domain permission conflict index is updated in real time. In response to the increase in the value of the cross-domain permission conflict index, the security risk threshold is dynamically lowered according to a preset attenuation coefficient to forcibly trigger the least privilege interaction coarse-grained scheduling scheme.

[0010] Optionally, the built-in security isolation mechanism is configured as follows: When the number of cross-domain call requests received by the local agent node exceeds the maximum concurrent request connection threshold preset by the local security gateway module, it is determined to be an abnormal privilege escalation attack; a communication interruption control signal is generated to instruct the local agent node to disconnect from the central scheduler and update the local task receiving status to stop receiving new task scheduling instructions.

[0011] Optionally, when a cross-domain call request is detected to exceed the maximum concurrent request connection threshold or to carry a cross-domain call request not registered in the capability declaration information, the built-in security isolation mechanism is configured to block communication; the capability declaration information only contains node capability tags and does not contain underlying private data of the node.

[0012] Compared with the prior art, the present invention has the following beneficial effects: 1. This system quantifies the cross-domain permission conflict index through a central scheduler. Combining the frequency of cross-domain calls, the dimension of cross-domain data interaction, and the trust weights configured in the local agent nodes, it can accurately predict the probability of communication interruption triggered by the local agent nodes' built-in security isolation mechanism. When faced with high permission conflicts or concurrency pressure, the system proactively abandons the initial fine-grained task decomposition scheme and instead generates and distributes a coarse-grained scheduling scheme with the least privilege interaction. This mechanism effectively solves the problem that task decomposition is easily intercepted by the local security gateway module in existing technologies. At the same time, the capability declaration information reported by the nodes only retains the node capability tags while shielding the underlying private data. Under the premise of fully meeting the data isolation requirements of the multi-agent federated network, it achieves stable and unified scheduling that meets preset performance indicators. 2. The conflict perception module of this system constructs a feature vector by combining the number of alarms in the historical permission alarm records of local intelligent agent nodes with the current cross-domain permission conflict index, and inputs it into the risk prediction model to calculate the classification probability value. This takes into account the recent boundary load overload status of the node, avoiding the lag defect of a single static evaluation. In addition, when the system detects unstructured abnormal request data containing unknown cross-domain signals, it can update the cross-domain permission conflict index in real time and dynamically lower the security risk threshold according to the preset attenuation coefficient. This design enables the system to reduce the risk tolerance threshold in advance before formal communication is interrupted, forcibly triggering the least privilege interaction coarse-grained scheduling scheme, and realizing the pre-protection of the trust boundary of the federated network. 3. This system pre-defines a scheduling objective function on the central scheduling side, which includes global resource allocation weight parameters and permission isolation weight parameters. When the risk of communication interruption increases, the system reduces the global resource allocation weight parameter and increases the permission isolation weight, merging the set of high-frequency cross-domain interaction subtasks into single-domain execution tasks. This proactively reduces cross-domain call links to maintain continuous business operation under high-pressure conditions in the federated network. At the same time, the system equips local intelligent agent nodes with an independent concurrency protection mechanism. When cross-domain call requests exceed the preset maximum concurrent request connection threshold, it is directly judged as an abnormal unauthorized attack and a communication interruption control signal is generated, stopping the reception of new task scheduling instructions. This effectively prevents the problem of cascading failure of the entire federated network due to severe overload of a single node. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 This is a structural diagram of a federated capability management and unified scheduling system for multi-agent collaboration according to the present invention. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments.

[0015] like Figure 1 As shown, a federated capability management and unified scheduling system for multi-agent collaboration includes: The central scheduler is configured to: receive collaborative task requests involving multiple local agent nodes with built-in security isolation mechanisms, and obtain capability declaration information reported by each of the local agent nodes in the federation; construct the collaborative task requests and the capability declaration information into prompt word templates, input them into a pre-set generative artificial intelligence language model for parsing, and generate an initial fine-grained task decomposition scheme containing multiple sub-tasks. Extract the cross-domain call chain between each subtask in the initial fine-grained task decomposition scheme; based on the cross-domain call chain, count the cross-domain call frequency and cross-domain data interaction dimension of the cross-domain call chain; combine the trust weight pre-configured for each local intelligent agent node, the cross-domain call frequency and the cross-domain data interaction dimension, and quantify and calculate the cross-domain permission conflict index. Based on the cross-domain permission conflict index, predict the probability of communication interruption triggered by the built-in security isolation mechanism for each local agent node; determine whether the communication interruption probability is greater than or equal to the preset security risk threshold; if the communication interruption probability is less than the security risk threshold, use the initial fine-grained task decomposition scheme as the target scheduling strategy; if the communication interruption probability is greater than or equal to the security risk threshold, abandon the initial fine-grained task decomposition scheme, and use the minimum permission interaction coarse-grained scheduling scheme generated by merging cross-domain interaction subtasks as the target scheduling strategy; and distribute the target scheduling strategy to the corresponding local agent node. The local intelligent agent node has a built-in security isolation mechanism and is configured to execute the corresponding sub-tasks according to the target scheduling strategy and feed back the task execution status to the central scheduler.

[0016] This embodiment provides a federated capability management and unified scheduling mechanism for multi-agent collaboration. Specifically, the main scenario is set as follows: During periods of drastic fluctuations in external input data, a cross-domain distributed system cluster needs to complete collaborative computing actions such as cross-domain abnormal node identification, data interaction link protection, distributed state synchronization, and operation log persistence within a preset time window. The federated network includes at least a first core security node, a second high-frequency concurrent node, a third state synchronization node, and a fourth global audit node. Each node only registers its own available capability tags with the central scheduler, such as global state anomaly assessment, concurrent request load balancing, cross-domain data consistency verification, and operation log persistence, without uploading end-user details, underlying business data, or permission verification message fields, thereby meeting the data isolation requirements of different jurisdictions. Specifically, the central scheduler receives collaborative task requests; these requests can be for the collaborative scheduling and resource reconfiguration of distributed business nodes affected by abnormal fluctuations, and typically include task objectives, time constraints, priorities, and the business areas to be covered. The central scheduler collects the capability declaration information periodically reported by each local agent node; the capability declaration adopts a directory structure, which can be understood as a combination of tags, such as local agent nodes. It features tag set node state fluctuation assessment, concurrent load threshold calculation, local domain access rule review, and local intelligent agent node... It features high-frequency instruction issuance for tag sets, distributed state machine collaborative synchronization, and integration of node execution results; The central scheduler constructs a prompt word template from the collaborative task request and the capability tags of each local agent node, and inputs it into a pre-set generative AI language model for parsing. The prompt word template contains preset structured constraint tags, which force the generative AI language model to output a JSON format result containing subtask identifiers, prerequisite dependencies, and candidate local agent node numbers. This enables task decomposition based solely on task intent and available capabilities without accessing underlying private data. Specifically, this process involves vectorized matching or semantic alignment of the intent text in the collaborative task request with the reported set of capability tags, defining task splitting logic and cross-domain boundary constraints in the prompt word template, thereby generating a standardized sequence of subtasks. The pre-built generative AI language model is supervised and fine-tuned based on a federated multi-agent historical scheduling architecture and a cross-domain compliant corpus. The prompt word template is embedded with preset JSON format constraint tags and permission boundary identifiers to force the model to output a set of subtasks with structured cross-domain call relationships and local agent node assignment logic according to predetermined logical rules, ensuring the technical determinism of the parsing results.

[0017] In a simplified example, the result of task decomposition can be represented as subtasks. to ,in To identify abnormal call nodes, In order to form candidate processing solutions, To perform cross-domain data synchronization, To verify data consistency constraints, To solidify the audit trail; if the call chain output by the generative artificial intelligence language model is Completed by the first core security node. Invoke the abnormal state compensation capability provided by the second high-frequency concurrent node. If the state consistency verification capability of the third state synchronization node is invoked again, at least two cross-domain call links will be formed in this scheme; The central scheduler further calculates the cross-domain call frequency and data interaction dimension for each link. The cross-domain call frequency is configured as the number of round trips for cross-node request communication within a preset unit task cycle. The data interaction dimension corresponds to the complexity of the field categories that need to be exchanged in a call. For example, exchanging only the security assessment score is a low-dimensional interaction, while the interaction involving node call direction, concurrency threshold status, legality flag, timing constraints, etc., is an interaction with a data interaction dimension greater than the preset dimension threshold. Furthermore, the central scheduler detects permission conflicts in the aforementioned links. Essentially, it doesn't directly assess the underlying business data itself, but rather calculates the load on local security boundaries caused by the task splitting method. The higher the trust weight configured on a node's local agent node, the higher the node's evaluation value with the federation center in terms of interface specifications, historical collaboration stability, and compliance verification mechanisms reaches the preset evaluation threshold. The conflict quantification value generated by cross-domain calls of the same scale is less than the first preset conflict parameter pre-defined using historical stable period data. Conversely, if a node's regulatory restrictions meet the second preset restriction condition representing a high level of confidentiality, and its historical interface rejection rate is greater than the preset rejection rate threshold, its trust weight is less than the preset trust parameter, making the same call chain more likely to trigger interception by the security gateway. Based on the fusion of three-dimensional features—cross-domain call frequency, cross-domain data interaction dimension, and trust weight of local agent node configuration—the central scheduler quantitatively calculates the cross-domain permission conflict index of the initial fine-grained task decomposition scheme. Its core logic is to weight and accumulate the cross-domain interaction frequency pressure and the data complexity dimension, and then normalize and correct it using the node trust weight, thereby obtaining a dimensionless conflict value that can characterize the pressure level of the local domain security gateway. Based on the cross-domain permission conflict index, the probability of communication interruption triggered by each local agent node to the built-in security isolation mechanism is predicted through a preset risk assessment mechanism. In the example simulation, it is assumed that the initial solution contains three main cross-domain links: → , → , → If among them Although the node has strong business processing capabilities, the region where it is located has strict preset interception rules for cross-border calls. Furthermore, the solution requires it to repeatedly exchange risk summaries, execution confirmations, and compliance flags with multiple nodes. Therefore, even if a single call is feasible in terms of business, the probability of communication interruption may increase due to the cumulative conflicts being greater than or equal to the preset conflict threshold. The system acquires the trust weights of local agent node configurations based on historical interface collaboration stability, compliance verification pass rate, and local security gateway standardization assessment. It also extracts the security risk thresholds pre-configured by the federated scheduling network during system initialization. These thresholds characterize the maximum tolerable limit of cross-domain concurrent impacts on the local agent node's security gateway. The central scheduler then compares the communication interruption probability with the security risk thresholds. If the communication interruption probability is lower than the security risk thresholds, the initial fine-grained task decomposition scheme is retained, thereby improving the technical execution efficiency of cross-node collaboration. If the probability of communication interruption reaches or exceeds the security risk threshold, the original fine-grained decomposition method is abandoned, and a least-privilege interaction coarse-grained scheduling scheme is generated instead. For example, the initial scheme for risk identification and abnormal state compensation that originally required multiple round-trip confirmations is generated and merged into the same domain for processing first, and then only the locally trimmed result summary is output to the outside, thereby reducing the number of cross-domain links and interaction complexity. The least-privilege interaction coarse-grained scheduling scheme is a strategy generated by the central scheduler to merge cross-domain subtasks with interaction frequency exceeding a preset threshold in the initial fine-grained task decomposition scheme into tasks to be executed in a single domain, in order to reduce the number of cross-domain call links. After receiving the target scheduling policy, the local intelligent agent node executes the corresponding sub-task according to the local domain permission rules and feeds back the task execution status to the central scheduler. The task status can include received, in execution, waiting for gateway permission, completed, local rejection, and timeout rollback. The central scheduler updates the subsequent task queue based on these statuses to reduce the system's invalid communication rate in the task execution chain. As an exception handling mechanism, if some local agent nodes have not yet reported the latest capability declaration at the current time, the central scheduler can first use the most recent capability catalog within the validity period to perform initial matching, but will reduce its scheduling priority; if a node fails to update the capability catalog for more than a preset time, it will not be included in the cross-domain main link and will only be retained as a backup local agent node; if the decomposition scheme output by the generative model has subtasks that cannot be covered by capability labels, the central scheduler will roll back the subtask to manual review or standard template task to avoid forming an unassigned call link without a subject to take over; if the communication interruption probability of multiple candidate schemes is higher than the security risk threshold, the backup disaster recovery strategy that can complete the core defense action in a single area will be retained first, even if the scheme cannot achieve global resource optimization, to ensure that the core business is not interrupted. Before a period of high-frequency interaction in a distributed system cluster, the system detected abnormal data flow deviations and enhanced cross-domain node linkage in multiple sub-networks simultaneously. The center issued a global core business collaborative protection task. The first core security node reported capability tags of fluctuation screening and credit risk warning. The second high-frequency concurrency node reported capability tags of abnormal state compensation and high-priority instruction truncation execution. The third state synchronization node reported capability tags of global state consistency verification and cross-domain data total amount constraint control. The fourth global audit node reported capability tags of preset security rule verification and operation log archiving. The central scheduler first generates a fine-grained solution, breaking down risk assessment, cross-domain data synchronization and status confirmation requests, instruction issuance, data consistency verification and audit solidification into multi-level sub-tasks; after link extraction, it was found that the second high-frequency concurrent node needs to frequently interact bidirectionally with the first core security node and the third status synchronization node, and there are many types of interaction fields; Based on this, the system determined that the scheme placed a significant burden on the security gateway of the second high-frequency concurrent node, and the probability of communication interruption was approaching the security risk threshold. This triggered the system to automatically switch the scheduling strategy to the least privilege interaction coarse-grained scheduling scheme: first, the first core security node completes risk aggregation and outputs a simplified risk summary within its domain; then, the second high-frequency concurrent node generates and executes a comprehensive state compensation operation within its domain; finally, only the necessary information for state consistency verification is sent to the third state synchronization node. Although this reduces some of the precision of the detailed coordination, the federated connection remains stable. To further clarify, to avoid inconsistent standards in cross-domain permission conflict indices during engineering, the central scheduler can separately calculate the pressure of each cross-domain link related to a node, and then calculate the local agent node's pressure using the following quantification formula. Cross-domain permission conflict index : in, Indicates the relationship with local agent nodes The total number of related cross-domain call chains; Represents a node In the The system can pre-configure grading rules to map the cross-domain call frequency on each call chain into dimensionless structured values. Represents a node In the The cross-domain data interaction dimension on each call chain represents the complexity of the exchanged field categories, and it is a dimensionless discrete rating value. and These represent the preset frequency weight and the preset dimension weight, respectively; to ensure consistency of the formulas, and All are used as dimensional normalization coefficients to map heterogeneous data in terms of frequency and dimension into a unified risk assessment measurement space; This indicates that the node is pre-defined as a local agent node. The configured trust weight is a dimensionless positive constant greater than zero, which is derived from a comprehensive evaluation based on historical interface collaboration stability, compliance verification pass rate, etc. It serves as a penalty coefficient in the denominator, meaning that the higher the trust level of a node, the more significantly its cross-domain permission conflict index is suppressed. Specifically, the quantitative evaluation process of the trust weight configured for local intelligent agent nodes is as follows: corresponding basic evaluation scores and percentage weights are pre-configured for historical interface collaboration stability, compliance verification pass rate, and local security gateway standardization. A comprehensive score is obtained by weighted summation. The comprehensive score is mapped to a preset positive value range using an S-shaped function or a maximum-minimum normalization function, which is used as the final trust weight configured for local intelligent agent nodes.

[0018] Through the above formula, the system can structurally and systematically transform multi-dimensional cross-domain interaction behaviors into a unified cross-domain permission conflict index value, providing a rigorous physical dimension input basis for subsequent communication interruption probability prediction. The preset risk assessment mechanism refers to a set of algorithmic logics used to quantify cross-domain behavioral risks and map them to communication state probabilities. In this embodiment, the mechanism specifically includes preset mapping rules based on fixed numerical ranges or risk prediction models based on machine learning architectures. The central scheduler dynamically calls the above rules or models to perform predictions based on the system's current computing power resources and the completeness of historical data.

[0019] As a basic implementation of the preset risk assessment mechanism, when historical alarm enhancement prediction is not enabled, the central scheduler can directly calculate the results based on the preset monotonic mapping table or segmentation rules. Converted to the probability of communication interruption.

[0020] Specifically, the preset monotonic mapping table or segmentation rules include: by setting a first conflict threshold and a second conflict threshold, when the cross-domain permission conflict index is less than the first conflict threshold, the communication interruption probability is mapped to a value lower than the preset security risk threshold; when it is between the first and second conflict thresholds, a linear interpolation function is used to calculate the specific communication interruption probability value; when it is greater than or equal to the second conflict threshold, it is directly mapped to the communication interruption probability of the highest security risk level. When the enhanced mode of the embodiment is enabled, the conflict calculation result is used as one of the input features of the risk prediction model. With this setting, the prediction process in the embodiment is executable even without an additional model, while maintaining a hierarchical relationship with the subsequent subordinate schemes. To further clarify, in this paper, cross-domain call chains and cross-node call chains refer to the same type of object, both representing the call relationship between subtasks and different local agent nodes. Cross-node emphasizes that the call occurs between different nodes, while cross-domain emphasizes that the call crosses different local permission boundaries. In this embodiment, they are not measured as two different chains separately. Correspondingly, the aforementioned cross-domain call frequency is the statistical result of the number of round trips for this type of cross-domain call chain, and the cross-domain data interaction dimension is the statistical result of the complexity of the exchanged field categories on this type of chain. Both are used together to characterize the boundary pressure of the same chain. To further explain, the aforementioned communication interruption probability is preferably predicted separately for each node, and then the central scheduler takes the maximum risk value among the target local agent nodes participating in the current scheduling scheme, or takes the set of high-risk nodes that exceeds the preset node number threshold, as the basis for determining whether to abandon the initial fine-grained task decomposition scheme. The built-in security isolation mechanism of this invention is a general term for the self-protection mechanism used within the local intelligent agent node. The local security gateway module is one of the entry verification components of the built-in security isolation mechanism. Therefore, when the probability of communication interruption triggered by the built-in security isolation mechanism is described in the text, it means protection results such as the local security gateway refusing to allow access, rate limiting upgrade, stopping the reception of new scheduling instructions, or actively disconnecting the communication connection, and is not limited to a single action. The purpose of this step is to first estimate the cross-domain permission conflicts that may be caused by the task decomposition itself without exposing the underlying private data, and then decide whether to adopt high-efficiency fine-grained scheduling or low-conflict coarse-grained scheduling, so as to put the avoidance of communication interruption of federated nodes and the maintenance of core business continuity at the forefront of central scheduling. In this embodiment, the central scheduler includes: The task parsing module is configured to receive collaborative task requests and generate an initial fine-grained task decomposition scheme using a generative artificial intelligence language model; the conflict perception module is configured to acquire capability declaration information, calculate the cross-domain permission conflict index, and predict the probability of communication interruption; the dynamic scheduling module is configured to determine the target scheduling strategy based on the comparison result between the probability of communication interruption and the security risk threshold, and distribute the target scheduling strategy to the corresponding local intelligent agent node.

[0021] This embodiment provides a modular collaborative mechanism for a central scheduler. Specifically, in the aforementioned global node data collaborative protection scenario, the overall process alone is insufficient to support rapid response under high concurrency. This is because if task generation, conflict assessment, and scheduling decisions are all mixed in one processing unit, queuing and blocking can easily occur when there are a large number of external concurrent requests. To this end, the central scheduler is further divided into a task parsing module, a conflict perception module, and a dynamic scheduling module, so that different processing stages can run in a streamlined manner. Specifically, the task parsing module is responsible for converting the upper-level business language into executable subtasks; the collaborative task requests it receives may come from a human command center or from an automatic early warning system; this module encapsulates the received collaborative task requests, time constraints, and capability tag directories into a prompt word template according to a predetermined format, calls the generative artificial intelligence language model, and outputs results including a set of subtasks, task temporal dependencies, and candidate local intelligent agent nodes. In this simplified example, the task parsing module can output a task table: Risk assessment is required and can be conducted by or Accept; The required state-compensated combinatorial construction can be achieved by... Accept; State consistency verification is required, which can be done by Accept; Auditing and sealing are required, which can be done by Accept; The results obtained solely from task parsing still tend to focus on business executability and are insufficient to reflect the tension of permission boundaries. The aforementioned mechanism has the following technical defects: if the scheduling system only obtains the capability declaration of the node without performing cross-domain boundary permission conflict verification on the task allocation strategy, then in scenarios where the concurrent call volume exceeds the preset security threshold, it may result in a situation where the task decomposition is correct but the federated connection is unstable. Therefore, this embodiment introduces a conflict awareness module. This module extracts cross-domain call links based on capability declaration information and task parsing results, calculates the cross-domain permission conflict index, and further predicts the probability of communication interruption for each node. Its function is to pre-evaluate whether the federal boundary can support the call method before the task is officially issued. Especially when different jurisdictions and different business lines adopt different permission policies, this step can identify high-risk links that are business-executable but difficult to pass local boundary verification in advance. The dynamic scheduling module makes a final strategy selection after obtaining the probability of communication interruption. If the risk is within a controllable range, it retains the fine-grained scheme to leverage the parallel capabilities of multiple nodes. If the risk exceeds the safety risk threshold, the module reduces the scheduling weight for system execution efficiency, reorganizes the task into fewer cross-domain links, and distributes it to the corresponding nodes according to the new target strategy. The module can also include a scheduling version number, effective time window, and acknowledgment requirements to ensure that local agent nodes execute according to the same round of strategy, avoiding state chaos caused by the overlap of old and new strategies. As an exception handling mechanism, if the task parsing module generates multiple candidate solutions, the conflict awareness module can evaluate them separately and output the ranking results. The dynamic scheduling module will prioritize the solution with a lower probability of communication interruption and that can meet the time limit. If the parsing module is temporarily unavailable, the central scheduler can revert to the predefined template library and generate a basic sub-task chain according to common task templates. If the capability catalog required by the conflict awareness module is incomplete, the dynamic scheduling module will adopt a conservative strategy and remove highly sensitive nodes from the main scheduling link until the capability information is restored to completeness. When an anomaly occurs in the cross-domain distributed node data flow linkage in the market, the task parsing module first outputs an initial fine-grained solution for cross-domain anomaly data flow review, state compensation reconstruction, liquidation constraint verification, and audit evidence storage. The conflict perception module finds that the solution requires the second high-frequency concurrent node to request the first core security node to update the risk summary multiple times in a short period of time, and also needs to repeatedly confirm the data interaction boundary with the third state synchronization node, thus judging that its boundary pressure is relatively large. The dynamic scheduling module then directly issues the reconstructed coarse-grained strategy: the first core security node outputs only a single summary after completing risk compression in its domain; the second high-frequency concurrent node performs comprehensive state compensation in its domain; and the third state synchronization node only performs end-point verification. Each node returns the status based on a unified version number, and the central scheduler continuously observes subsequent risks accordingly. To further clarify, the aforementioned task list... , , , These represent identifiers for different subtasks; , , , , These represent the identifiers of different local agent nodes participating in the federal scheduling, where and All of them can serve as candidate nodes for undertaking the risk assessment sub-task. Construct candidate nodes for state compensation combinations. Candidate nodes for state consistency verification. To audit and seal candidate nodes; with this setting, the subtask identifiers in the task parsing module output will correspond one-to-one with the candidate node identifiers, avoiding unclear references to node codes in example simulations; The purpose of this step is to address three types of issues through module division of labor: whether a task can be split, whether splitting it is prone to causing permission conflicts, and what scheduling strategy should be adopted in the end. This will enable stable scheduling and rapid degradation under high load conditions. In this embodiment, the local agent node includes: The capability registration module is configured to generate capability declaration information and upload it to the central scheduler; the local security gateway module is configured to monitor cross-domain call requests in the cross-domain call chain generated when executing the target scheduling policy, and perform access control based on local permission rules; the task execution module is configured to execute sub-tasks after the local security gateway module verifies them and generate task execution status.

[0022] This embodiment provides a hierarchical execution mechanism for local intelligent agent nodes. Specifically, in the aforementioned global federation collaboration scenario, relying solely on the central-side policy optimization is still insufficient, because what truly determines whether a cross-domain request can be executed is the boundary control capability of each local intelligent agent node. If the local intelligent agent node does not have a clear capability registration-gateway verification-task execution three-layer structure, even if the central scheduler provides a target solution generated based on the optimal weight of global resources, it may still cause erroneous approval or rejection due to the disorder of the local execution chain. Specifically, the capability registration module is responsible for abstracting the publicly available capabilities of local intelligent agent nodes into capability declaration information that does not contain underlying data. Taking the first core security node as an example, it may internally know the data load status of specific terminal nodes, underlying access authorization policies, and regulatory sensitive fields, but externally it only registers labels such as credit risk assessment, margin stress test, and regional compliance filtering. The technical essence of this step is to map local underlying data resources into standardized capability identifier configurations that can be called by the center, so as to achieve physical isolation of underlying private data. In the example scenario, a node's capability declaration can be represented as a statement containing the node number. The tag set is a directory record for risk assessment, margin calculation, support period of all day, and maximum concurrency level of medium; the central scheduler only needs to obtain the external availability characteristics and time constraints of the node, without parsing its underlying implementation logic; Registration alone cannot guarantee secure execution. The above implementation method is prone to defects in extreme cases: the central side may think that a certain subtask can be sent to a certain node, but the region where the node is located has temporarily tightened a certain type of cross-border access rule. If there is a lack of independent access control and verification by the local intelligent agent node, it may lead to a disconnect between the central scheduling strategy and the local compliance boundary. Therefore, this embodiment sets up a local security gateway module; this module is located before the task execution module, and monitors cross-domain call requests generated during the execution target scheduling strategy in real time, and decides to allow, deny, rate limit or postpone processing according to local permission rules; the permission rules here can cover multiple aspects such as call source, business category, request time window, exchangeable field category, and whether audit obligations are complete; The task execution module only starts executing subtasks and generates task execution status after the gateway allows access. In addition to completion and failure, the execution status can also include more detailed results such as pending authentication, affected by local rate limiting, and transferred to the local domain to replace the process. Therefore, the central scheduler is configured to distinguish between the non-execution status and the non-execution status of tasks, so as to make more accurate subsequent scheduling. As an exception handling mechanism, if the capability registration module detects a local system upgrade, rule change, or service suspension, it should immediately refresh the capability declaration and, if necessary, temporarily revoke certain tags to prevent the center from continuing to assign unsuitable tasks to it. If the security gateway receives a request field that exceeds the registered allowed range, it will first refuse to allow the task and send back the reason for the restriction, even if the task originates from the central scheduler. If the task execution module cannot continue execution due to insufficient local resources after allowing the task, it should output the execution stop status and may attach a suggested alternative capability label for the central to rematch other nodes. When the global collaborative defense mission enters the execution phase, the capability registration module of the second high-frequency concurrent node declares to the center that it supports the comprehensive task splitting and execution receipt summary of complex state compensation execution, but does not disclose any restricted privacy basic data; the center issues a compensation execution sub-task, requesting it to call the risk summary output by the first core security node; this request first enters the local security gateway of the second high-frequency concurrent node; If the gateway determines that the summary only contains the risk level identifier and status compensation direction for cross-border flow, and does not contain restricted personal data, it will allow the flow; if it finds that the request includes unauthorized low-level fine-grained feature fields, it will directly block the flow; the task execution module will only perform status operations after the flow is allowed, and return the executed and pending settlement confirmation status to the center. To further clarify, the terms "local security gateway module," "local security gateway," and "security gateway" appearing in the contextual descriptions all refer to the same module in the embodiments and do not constitute different components; "local permission rules," "local domain permission rules," and "regional compliance boundaries" are all used to describe the same set of rules that the module relies on when performing access control, only emphasizing their execution location or compliance attributes in different narrative contexts. Accordingly, the built-in security isolation mechanism in the embodiment is a higher-level concept that covers the local security gateway module and subsequent protection actions. The local security gateway module is responsible for verifying the entry of cross-domain call requests and triggering isolation actions such as rejection, rate limiting, delay or communication interruption. The task execution module only continues to execute requests that have passed the verification of the module, thereby ensuring that the terminology is consistent. The purpose of this step is to distinguish between those that can be scheduled and those that can be safely executed through hierarchical control of local intelligent agent nodes, thereby achieving a stable connection between the federal center and the boundary rules of each jurisdiction. In this embodiment, the conflict sensing module is configured as follows when predicting the probability of communication interruption: Obtain historical permission alarm records of local intelligent agent nodes; count the number of alarms in the historical permission alarm records, construct a feature vector by combining the number of alarms with the cross-domain permission conflict index, and input it into a pre-trained risk prediction model; calculate the classification probability value corresponding to the feature vector through the risk prediction model, which serves as the probability of communication interruption triggered by the local intelligent agent node's built-in security isolation mechanism.

[0023] This embodiment provides a communication interruption probability prediction mechanism based on historical alarm memory. Specifically, in the aforementioned scheme, if the risk is judged solely based on the cross-domain permission conflict index corresponding to the current task decomposition, the following shortcomings still exist: Although the number of subtasks and interaction dimensions of the current task of some nodes do not exceed the preset security threshold, the node has recently experienced multiple permission alarms, interface denials, or rate limiting events, and its security gateway is in a highly sensitive state. At this time, looking only at the current conflict level may underestimate the actual communication interruption risk. Therefore, this embodiment further introduces historical permission alarm records into the conflict perception module. The historical alarm records are not business detail data, but rather boundary state traces output by the local security gateway in previous periods, such as field out-of-range alarms, cross-domain frequency abnormal alarms, source authentication retry alarms, and concurrency approaching the limit alarms. The central side can obtain the count or hierarchical summary of these alarms without needing to know the specific customer or order content corresponding to the alarm. The conflict perception module constructs a feature vector by combining the cross-domain permission conflict index corresponding to the current solution with the number of historical alarms, inputs it into the pre-trained risk prediction model, and outputs the classification probability value as the communication interruption probability. In the simplified example, assume the node The current cross-domain permission conflict index is Furthermore, the number of permission-related alerts issued within the past hour was [number missing]. Another node Current cross-domain permission conflict index and The numbers are close, but the number of alerts in the past hour has significantly decreased; in this situation, the risk prediction model will not treat them as equally safe, but rather... Nodes identified as having a higher recent accumulation of boundary alarms are given a higher probability of communication interruption. This reflects the engineering principle of continuity judgment: the boundary withstand capability of a node is not only determined by the current request, but also by its recent accumulated impact. By introducing historical alarm information, the central scheduler gets closer to the actual response trend of the local gateway. The scheme that only uses the current conflict value is prone to judgment lag when facing continuous disturbances, which is the shortcoming of the above implementation method. Especially in high-load network environments, permission alarms have a cumulative effect. After being triggered multiple times in a row, the local gateway will often tighten the access conditions. To this end, this embodiment introduces a risk prediction model and uses historical trajectories to correct the current estimate, so that the judgment of communication interruption no longer depends on static single-point observation. As an anomaly handling mechanism, if a node lacks historical alarm records due to its first connection to the federation, the initial default configuration parameters can be used to set its historical alarm characteristics to a neutral level and temporarily increase the security margin. If there are obvious missing historical alarm records or abnormal timestamps, only the current cross-domain permission conflict index will be used for judgment, and a risk mark for incomplete historical information will be given to prompt the dynamic scheduling module to adopt a more conservative approach. If the risk prediction model is temporarily unavailable, the system can revert to a coarse judgment mode based on rule thresholds to avoid the scheduling process from stopping due to model service anomalies. During a cross-market anomaly that continued to spread, the second high-frequency concurrent node had repeatedly triggered source authentication retries and cross-domain frequency increase alarms within the past twenty minutes. At this point, the central scheduler generated a fine-grained scheme for the new round of collaborative defense with a lower number of call chains than the usual preset value. If only the current number of links is considered, the system may think that the scheduling can still be further subdivided. However, after the conflict perception module inputs the node's current conflict level and its recent high-frequency alarms into the risk prediction model, it obtains a high probability of communication interruption. Therefore, the system abandons the scheme in advance and adopts a scheduling method with fewer cross-domain interactions. To further clarify, in order to ensure the stability of the input criteria for the risk prediction model, historical access alarm records are preferably summarized according to a unified observation window, such as the total number of alarms in the last five minutes, fifteen minutes, or one hour, and time alignment is completed before entering the model. If different types of alarms have different impacts on the risk of communication interruption, they can be converted into a unified alarm count or alarm level summary at the local gateway before being sent to the center, thereby ensuring that the source of the alarm count as an input feature in the embodiment is consistent. The pre-trained risk prediction model can employ logistic regression, lightweight tree models, or other supervised learning models that output classification probability values. Its training samples must at least include historical cross-domain permission conflict indices, historical alarm counts, and labeling results indicating whether security isolation was triggered during the corresponding time period. In this way, the classification probability values ​​output by the model have a clear supervisory objective, namely, representing the probability that a node will trigger the built-in security isolation mechanism under the current observation conditions, rather than a generalized abstract risk score. This avoids the technical defect of unclear prediction objectives due to the lack of a judgment object in the model. Specifically, the training process of the pre-trained risk prediction model is as follows: obtain the cross-domain permission conflict index and historical alarm count of each local agent node within a historical preset time period as sample feature data, and extract the actual status of whether the local security gateway is triggered to limit the flow, refuse or disconnect the connection within the corresponding time period as the classification label; divide the sample feature data and the classification label into training set and test set, and use the cross-entropy loss function to iteratively train the supervised learning model until the loss value converges or the maximum number of iterations is reached, thus obtaining the trained risk prediction model.

[0024] The purpose of this step is to incorporate the recent boundary tension of nodes into the prediction, so that the central scheduler can detect risks in advance before the local security gateway officially disconnects, thereby achieving earlier policy convergence and fewer sudden communication interruptions. In this embodiment, the central scheduler has a preset scheduling objective function, which includes global resource allocation weight parameters and permission isolation weight parameters. When generating a least-permission interaction coarse-grained scheduling scheme, it is configured as follows: For a pre-configured unit task cycle, retrieve cross-domain interaction subtasks in the initial fine-grained task decomposition scheme whose cross-domain call frequency is greater than a pre-set frequency threshold, forming a set of high-frequency cross-domain interaction subtasks; merge the set of high-frequency cross-domain interaction subtasks into a single domain execution task; Based on the proportion of the high-frequency cross-domain interaction subtask set to the total concurrent calls within a unit task cycle, the corresponding target adjustment step size is dynamically calculated and obtained; in this process, the specific rule for dynamic calculation is: the proportion to the total concurrent calls is denoted as... ,when When the value is less than a preset proportional threshold, a first fixed step size is used; when... When the ratio is greater than or equal to a preset threshold, a function is used. Calculate target adjustment step size ,in, The preset gain coefficient, Adjust the base number based on the fundamentals; Based on the target adjustment step size, the global resource allocation weight parameter and the permission isolation weight parameter are dynamically adjusted in reverse, and the updated scheduling objective function is used to reallocate tasks for tasks executed within a single domain, generating a least-privilege interaction coarse-grained scheduling scheme.

[0025] This embodiment provides a coarse-grained reconfiguration scheduling mechanism for high-risk scenarios. Specifically, in the aforementioned system, when the probability of communication interruption approaches the security risk threshold, if the initial fine-grained splitting method is still used, even if the central side knows the risk has increased, it can only output the risk assessment result, lacking a reconfiguration execution mechanism to transform the task into a low-conflict scheduling scheme. Therefore, this embodiment presets a scheduling objective function and actively changes the emphasis of different objectives when the risk increases. The scheduling objective function is specifically defined as follows: In the formula, Score the overall scheduling fitness. The global resource allocation efficiency evaluation value for the corresponding node; This is the predicted cross-domain permission conflict index; Assign weight parameters to global resources; To isolate the weight parameter for permissions; when generating a coarse-grained scheduling scheme for least-permission interaction, the weight is adjusted by lowering... And raise This allows the forced priority selection to minimize [the impact of task reallocation]. The single-domain closed-loop execution strategy ensures the stability of the communication link while sacrificing some resource processing efficiency.

[0026] Specifically, the scheduling objective function considers both global resource optimization and permission isolation. The former emphasizes allocating tasks to nodes with processing efficiency greater than a preset efficiency threshold and idle time that meets preset resource conditions, in order to shorten the total latency. The latter emphasizes minimizing cross-domain boundary crossings and reducing interface verification pressure. Under normal stable conditions, the weight of global resource optimization can be relatively higher to maximize the parallel processing efficiency of the system. However, during periods of increased risk, the system actively reduces this weight and increases the weight of permission isolation, shifting the scheduling objective from minimizing processing latency to prioritizing meeting the preset permission isolation security threshold. In its implementation, the central scheduler first retrieves cross-domain interaction subtasks whose interaction frequency exceeds a preset frequency threshold from the initial fine-grained scheme, forming a set of high-frequency cross-domain interaction subtasks. In the example scenario, it is assumed that the subtask chain sequentially includes... Risk screening, Risk confirmation, Cross-domain data synchronization and status confirmation requests Execution of business instructions Data synchronization verification and Audited and sealed, among which , , Multiple rounds of cross-domain confirmation are required. If these processes frequently call different regional nodes, it will continuously increase permission conflicts; therefore, the central scheduler merges this high-frequency set into tasks executed within a single domain, for example, by... Anomaly assessment and confirmation Cross-domain data synchronization and status confirmation requests are incorporated into the intra-domain status compensation preparation task within the first data processing domain, or... Global data pre-core and After the audited and sealed tasks are reorganized into the underlying compliance integration tasks in the second data processing domain, the updated scheduling objective function is used to redistribute tasks and generate a minimum-privilege interaction coarse-grained scheduling scheme. While the above implementation methods can determine the level of risk, when actually performing the downgrade, the lack of clear task merging rules can easily lead to the technical defect of the downgrade scheduling strategy lacking a clear task merging and reordering mechanism. This is precisely why this embodiment introduces a set of high-frequency interactive subtasks and a weight switching mechanism. By first identifying the high-frequency links that consume the most boundary trust and then compressing them back into a single domain, unnecessary cross-domain confirmation processes can be effectively reduced. As an exception handling mechanism, if a high-frequency cross-domain subtask requires dual-domain review due to regulatory requirements and cannot be completely merged into a single domain, the central scheduler can merge only the portion that is allowed to be executed independently within its own domain and reduce the cross-domain interface to a single result submission. If multiple domains have the capacity to handle merged tasks, the domain with the most complete data, the fewest historical alarms, and the lowest gateway load will be prioritized. If merging leads to a significant increase in resource pressure on a single node, redundant nodes within that domain can be configured for tasks within that domain, while still minimizing cross-domain exits. During a period of drastic fluctuations in external environmental parameters and system call frequency, the initial fine-grained solution required the first core security node and the second high-frequency concurrent node to continuously perform multiple rounds of risk updates and business instruction data revisions around the same batch of assets, while the third state synchronization node continuously participated in each round of constraint verification. The system identified risk confirmation—cross-domain data synchronization and status confirmation request—data synchronization verification as a set of high-frequency cross-domain interaction subtasks. Therefore, it reduced the global resource optimization weight and increased the permission isolation weight, reconstructing the above link into two intra-domain tasks with cross-domain interaction frequencies below a preset frequency threshold: the first core security node outputs only one compressed risk instruction, the second high-frequency concurrent node completes the state policy construction and execution within its own domain, and the third state synchronization node completes a one-time settlement verification at the end; as a result, the number of cross-domain round trips decreased to below the preset frequency threshold. To further clarify, merging tasks into a single domain does not require the original high-frequency subtasks to be semantically identical. Rather, it requires that these subtasks have close dependencies, iterative confirmation relationships, or share intermediate states, making them suitable for closed-loop completion within the same domain. When selecting the domain for merging, the central scheduler can filter tasks based on the following characteristics: holding the minimum necessary inputs required to complete the closed loop, outputting less than a preset output data threshold, and having a local gateway pass rate greater than a preset pass rate threshold. After merging, tasks within the domain only expose necessary result summaries, execution conclusions, or verification conclusions, and no longer expose the round-trip information of the original multiple intermediate steps. Thus, the engineering meaning of merging the set of high-frequency cross-domain interaction subtasks into a single domain execution task in the embodiment is further clarified. That is, its core is to compress the cross-domain round-trip process rather than simply splicing task names, so as to avoid the deviation of formal merging but still high-frequency cross-domain calls in practice. The purpose of this step is to achieve continuous operation of the federation under high load by actively sacrificing some of the globally optimal allocation effect in exchange for less cross-domain permission traversal when the system is already on the verge of high conflict. In this embodiment, the central scheduler is further configured as follows: When a cross-domain call request not registered in the capability declaration information is detected in a subtask parsed by the generative artificial intelligence language model, the cross-domain call request is marked as an unknown cross-domain signal. If the unknown cross-domain signal does not match the legal access policy pre-configured by the central scheduler, the collaborative task request is determined as unstructured abnormal request data, and the cross-domain permission conflict index is updated in real time. In response to the increase in the value of the cross-domain permission conflict index, the security risk threshold is dynamically lowered according to the preset attenuation coefficient to forcibly trigger the least privilege interaction coarse-grained scheduling scheme.

[0027] This embodiment provides a dynamic threshold tightening mechanism for unstructured abnormal request data. Specifically, in the aforementioned scenario, if the system only calculates permission conflicts for the already identified formal task chains, but lacks the ability to handle unstructured cross-domain requests from outside that exceed the preset concurrency limit, the central scheduler may experience a delay of more than a preset duration in judging the true tension level of the federation boundary. Especially when a large number of ambiguous abnormal signals appear in the market, the center will be forced to repeatedly try to call different nodes for verification. Although these requests may not all form formal business tasks, they themselves have already put pressure on the local security gateway. Therefore, this embodiment introduces a detection mechanism for unknown cross-domain signals. In this invention, unstructured cross-domain request data refers to signals that fail to match the preset permission rules on the central side, whose source intent is not entirely clear, but which trigger cross-domain capability exploration or tentative collaborative requests. Its engineering meaning is that although these requests have not yet entered the explicit task list, they have already begun to occupy cross-domain verification resources between federations. Once the central scheduler detects such unstructured abnormal request data, it updates the cross-domain permission conflict index in real time, rather than waiting for the formal task to fail before taking remedial action. Furthermore, while the security risk threshold in the above embodiments can be statically set, static thresholds have their shortcomings in real high-pressure environments: when abnormal request data continues to rise, continuing to use the original threshold may make the system's response to risks too slow. Therefore, this embodiment dynamically lowers the security risk threshold according to a preset attenuation coefficient. Its essence is not to expand alarms, but to tighten the tolerance range in advance, so that the system enters a defensive scheduling state earlier. In other words, during stable periods, the system allows for more granular cross-domain splitting; while during periods of dense abnormal request data, the system actively lowers the acceptable risk boundary, thereby forcibly triggering the least privilege interaction coarse-grained scheduling scheme earlier. In the simplified example, assume the center receives three types of abnormal cross-domain requests in succession. , , The request It can match existing permission templates, while the request and Only partial matching is possible, and the request structure contains unknown field combinations. The center does not need to parse the business meaning of these unknown fields, but only needs to identify that they do not conform to the existing permission mode and regard them as the source of boundary uncertainty. As such requests accumulate, the system gradually lowers the security risk threshold, so that the fine-grained solution that was originally on the edge of the acceptable range is judged into the high-risk zone in advance and quickly switched to a coarse-grained strategy. As an anomaly handling mechanism, if certain unknown cross-domain signals are subsequently confirmed to be legitimate new business scenarios, they can be added to the permission rule template library to avoid long-term misjudgment as abnormal request data; if the number of abnormal requests surges briefly but then drops rapidly, the security risk threshold can gradually rise within a preset recovery period, rather than remaining at the lowest level for a long time, to avoid the system being overly conservative; if the central side cannot determine whether an unknown signal is an offensive abnormal request data or a new pattern caused by a business upgrade, it can be temporarily marked as a high-sensitivity event and restricted to only entering the sandbox verification process, without directly triggering formal cross-domain linkage; As cross-domain nodes continuously faced unstructured, high-frequency concurrent requests, the central scheduler simultaneously received a large number of abnormal requests from across markets and categories with incomplete fields. These requests continuously attempted to access risk control, business processing, and clearing capabilities, but their combination methods were inconsistent with existing compliance templates. After identifying these unstructured abnormal request data, the system immediately increased the permission conflict perception results and lowered the security risk threshold according to a preset attenuation coefficient. The originally planned fine-grained global collaborative scheduling was thus promptly canceled, and a defensive solution of first closing the loop within the region and only transmitting the summary across domains was adopted to avoid multiple local intelligent agent nodes triggering isolation due to continuous probing calls. Furthermore, in this embodiment, the unknown cross-domain signal and unstructured abnormal request data are different descriptions of the same detection object. The former emphasizes that the request has failed to establish a definite matching relationship with the existing permission mode on the central side, while the latter emphasizes that the request has not yet formed a structured task that can enter the formal scheduling process at the current moment. The processing result of such objects does not directly replace the communication interruption probability calculation in the embodiment, but is incorporated into the update process of the same cross-domain permission conflict index as an additional source of boundary pressure. Therefore, the security risk threshold in the embodiment is still the same threshold in this embodiment. However, this threshold can be tightened from the initial threshold to a dynamic threshold when the abnormal request data rises, and then reverted according to the recovery cycle after the abnormal request data falls back, so as to maintain consistency with the basic scheme. To further clarify, the aforementioned coarse-grained scheduling scheme for forcibly triggering least privilege interaction refers to the process where, under the effect of a dynamically lowered security risk threshold, the probability of communication interruption that was not yet exceeded by the static threshold is moved into a high-risk range. The dynamic scheduling module then selects a coarse-grained scheduling scheme according to the implementation mechanism, rather than bypassing the existing scheduling process to establish an independent strategy. With this setting, the implementation is a pre-emptive tightening measure on the existing judgment link, and the technical process remains consistent throughout. The purpose of this step is to enable the system not only to make risk assessments on completed tasks, but also to tighten the scheduling boundaries in advance for uncertain and abnormal request data from the outside world, thereby achieving pre-emptive protection of the cross-domain trust foundation. In this embodiment, the built-in security isolation mechanism is configured as follows: When the number of cross-domain call requests received by the local agent node exceeds the maximum concurrent request connection threshold preset by the local security gateway module, it is determined to be an abnormal privilege escalation attack; a communication interruption control signal is generated to instruct the local agent node to disconnect from the central scheduler and update the local task receiving status to stop receiving new task scheduling instructions.

[0028] This embodiment provides a concurrent communication interruption protection mechanism for local intelligent agent nodes. Specifically, in the aforementioned system, even if the central scheduler has conflict perception and dynamic degradation capabilities, it cannot rule out the possibility that a large number of cross-domain requests will simultaneously flood into a local intelligent agent node in extreme cases. If the local intelligent agent node still passively receives all requests in this situation, the security gateway may experience verification delays, rule execution backlogs, or even state chaos due to excessively high connection numbers, ultimately damaging the stability of the local boundary. Therefore, this embodiment sets a maximum concurrent request connection threshold in the local built-in security isolation mechanism. When the number of cross-domain call requests received by a node exceeds this threshold, the local security gateway determines it as an abnormal privilege escalation attack and generates a communication interruption control signal. This judgment does not depend on whether the request content has been fully parsed, but rather on the connection concurrency pressure for rapid protection. The engineering consideration is that under high-frequency attacks or unstructured abnormal request data, the local system is first subjected to the impact at the connection level. If the content-level review is waited for to be fully completed, the execution time often exceeds the preset security isolation time window. While the above implementation can minimize high-conflict scheduling at the central side, if abnormal traffic has already crossed the central control, the local intelligent agent node still needs to perform end-point mandatory security isolation control. This embodiment addresses this gap by adding communication interruption control logic. After communication is interrupted, the local task receiving status is updated to stop receiving new task scheduling instructions to prevent the central side from continuing to send new cross-domain tasks and further increasing the load. At the same time, the node can retain the processing capacity of existing tasks that have entered the execution stage in its local domain, avoiding unnecessary interruptions to work that can still be completed locally in a closed loop. In the example scenario, the maximum concurrent request connection threshold for a certain business node is set to... When the number of valid connections initiated by the center and other nodes to this business node within a short period of time exceeds the maximum concurrent request connection threshold. When this happens, the gateway immediately enters protection mode and generates a communication interruption control signal. Simultaneously, the local status flag S is updated to stop receiving new scheduling status; after the central side receives this status, it will no longer deliver new cross-domain tasks to it, but will re-plan alternative nodes or switch to an intra-domain closed-loop scheme. As an exception handling mechanism, if the number of concurrent connections is close to the threshold but has not yet exceeded it, the gateway can first implement rate limiting, queuing, or only retain high-priority tasks; if the reason for exceeding the threshold is confirmed to be repeated retries of the same task, deduplication can be performed first before judgment to avoid erroneously triggering communication interruption; if a node has experienced a communication interruption but the subsequent connection pressure returns to normal, it can re-declare its task-receiving status to the center through the capability registration module after the local cooldown period ends; if the communication interruption occurs during a critical business window, the local intelligent agent node can retain only the minimum necessary regulatory or settlement task entry points, and keep other types closed. During the execution of the global node data collaborative protection task, the second high-frequency concurrent node once simultaneously received multiple requests from the central scheduler, the first core security node, and the third state synchronization node, including formal execution requests and a large number of retry connections. Its local security gateway detected that the number of concurrent connections continued to exceed the preset limit, determined that the current state was close to an abnormal privilege escalation attack, and immediately generated a communication interruption control signal to block the communication link for new tasks with the central scheduler and update the status to stop receiving new scheduling instructions. After receiving this status, the central side will no longer deliver new cross-domain tasks to it, but will re-plan alternative nodes or use an intra-domain degradation alternative strategy. The purpose of this step is to provide local agent nodes with a defense line independent of the central scheduling, thereby enabling rapid self-protection when the pressure on the connection layer exceeds the limit, and preventing a single local agent node from affecting the entire federated link due to overload. It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A federated capability management and unified scheduling system for multi-agent collaboration, characterized in that, include: The central scheduler is configured to: receive collaborative task requests involving multiple local agent nodes with built-in security isolation mechanisms, and obtain capability declaration information reported by each of the local agent nodes; The collaborative task request and the capability declaration information are constructed into a prompt word template, which is then input into a pre-set generative artificial intelligence language model for parsing to generate an initial fine-grained task decomposition scheme containing multiple sub-tasks. Extract the cross-domain call links between each subtask in the initial fine-grained task decomposition scheme, and count the cross-domain call frequency and cross-domain data interaction dimensions of the cross-domain call links; The cross-domain permission conflict index is calculated by combining the trust weight pre-configured for each local intelligent agent node, the cross-domain call frequency, and the cross-domain data interaction dimension. Based on the cross-domain permission conflict index, the probability of communication interruption triggered by each local intelligent agent node to the built-in security isolation mechanism is predicted through a preset risk assessment mechanism. If the communication interruption probability is less than a preset security risk threshold, the initial fine-grained task decomposition scheme is used as the target scheduling strategy; if the communication interruption probability is greater than or equal to the security risk threshold, the initial fine-grained task decomposition scheme is abandoned, and the minimum permission interaction coarse-grained scheduling scheme is generated by merging cross-domain interaction subtasks as the target scheduling strategy. The target scheduling strategy is distributed to the corresponding local agent node; The local intelligent agent node has the built-in security isolation mechanism and is configured to: execute the corresponding sub-task according to the target scheduling strategy and feed back the task execution status to the central scheduler.

2. The federated capability management and unified scheduling system for multi-agent collaboration according to claim 1, wherein, The central scheduler includes: The task parsing module is configured to receive collaborative task requests and generate an initial fine-grained task decomposition scheme using a generative artificial intelligence language model. The conflict awareness module is configured to acquire capability declaration information, calculate the cross-domain permission conflict index, and predict the probability of communication interruption. The dynamic scheduling module is configured to determine the target scheduling strategy based on the comparison between the communication interruption probability and the security risk threshold, and then distribute the target scheduling strategy to the corresponding local agent node.

3. The federated capability management and unified scheduling system for multi-agent collaboration of claim 2, wherein, Local agent nodes include: The capability registration module is configured to generate capability declaration information and upload it to the central scheduler; the local security gateway module has a preset maximum concurrent request connection threshold and is configured to monitor cross-domain call requests in the cross-domain call chain generated when executing the target scheduling strategy, and perform access control based on local permission rules; the task execution module is configured to execute sub-tasks after the local security gateway module verifies them and generate task execution status.

4. The federated capability management and unified scheduling system for multi-agent collaboration of claim 2, wherein, The conflict detection module is configured as follows when predicting the probability of communication interruption: Obtain historical permission alarm records of local intelligent agent nodes; count the number of alarms in the historical permission alarm records, construct a feature vector by combining the number of alarms with the cross-domain permission conflict index, and input it into a pre-trained risk prediction model; calculate the classification probability value corresponding to the feature vector through the risk prediction model, which serves as the communication interruption probability of the local intelligent agent node triggering the built-in security isolation mechanism.

5. A federated capability management and unified scheduling system for multi-agent collaboration as described in claim 1, characterized in that, The central scheduler has a pre-defined scheduling objective function, which includes global resource allocation weight parameters and permission isolation weight parameters. When generating a least-privilege interaction coarse-grained scheduling scheme, it is configured as follows: For a pre-configured unit task cycle, retrieve cross-domain interaction subtasks in the initial fine-grained task decomposition scheme whose cross-domain call frequency is greater than a pre-set frequency threshold, and form a set of high-frequency cross-domain interaction subtasks. Merge a set of high-frequency cross-domain interaction subtasks into a single domain-intra-domain execution task; Based on the proportion of the high-frequency cross-domain interaction subtask set to the total concurrent calls within a unit task cycle, the corresponding target adjustment step size is dynamically calculated and obtained. Based on the target adjustment step size, the global resource allocation weight parameter and the permission isolation weight parameter are dynamically adjusted in reverse, and the updated scheduling objective function is used to reallocate tasks for tasks executed within a single domain, generating a least-permission interaction coarse-grained scheduling scheme.

6. A federated capability management and unified scheduling system for multi-agent collaboration as described in claim 1, characterized in that, The central scheduler is also configured as follows: When a cross-domain call request that is not registered in the capability declaration information is detected in the subtask parsed by the generative artificial intelligence language model, the cross-domain call request is marked as an unknown cross-domain signal; if the unknown cross-domain signal does not match the legal access policy pre-configured by the central scheduler, the collaborative task request is determined as unstructured abnormal request data, and the cross-domain permission conflict index is updated in real time. In response to the increase in the cross-domain permission conflict index, the security risk threshold is dynamically lowered according to a preset attenuation coefficient to forcibly trigger the least privilege interaction coarse-grained scheduling scheme.

7. A federated capability management and unified scheduling system for multi-agent collaboration as described in claim 3, characterized in that, The built-in security isolation mechanism is configured as follows: When the number of cross-domain call requests received by the local intelligent agent node exceeds the maximum concurrent request connection threshold preset by the local security gateway module, it is determined to be an abnormal privilege escalation attack. A communication interruption control signal is generated to instruct the local agent node to disconnect from the central scheduler and update the local task reception status to stop receiving new task scheduling instructions.

8. A federated capability management and unified scheduling system for multi-agent collaboration as described in claim 3, characterized in that, When a cross-domain call request is detected to exceed the maximum concurrent request connection threshold or to carry a cross-domain call request not registered in the capability declaration information, the built-in security isolation mechanism is configured to block communication; the capability declaration information only contains node capability tags and does not contain local agent node underlying private data.

Images