A resource allocation method and system based on multi-dimensional feature and state cooperation

Abstract

The application relates to the technical field of computer-aided resource management and intelligent scheduling, and provides a resource allocation method and system based on multi-dimensional feature and state cooperation, which comprises the following steps: acquiring demand features of a target task and static attribute labels, real-time loads and current available states of resource nodes in a candidate resource pool; obtaining a comprehensive matching degree index based on preset weight weighted fusion of matching degrees, load factors and availability factors; generating a state snapshot and executing state change mutual exclusion control within an allocation period; selecting a target resource node from the candidate resource pool based on the comprehensive matching degree index and the state snapshot and executing an allocation operation, triggering a re-allocation operation according to an allocation feedback result, and obtaining a final allocation scheme. Through multi-dimensional feature fusion and state cooperative control, the application realizes automation, high precision and full-process traceability of resource allocation, significantly improves allocation efficiency and reduces artificial maintenance cost.

Description

Technical Field

[0001] This application relates to the field of computer-aided resource management and intelligent scheduling technology, specifically to a resource allocation method and system based on multi-dimensional features and state coordination. Background Technology

[0002] In large organizations' project review, task assignment, and crowdsourcing scheduling scenarios, the allocation of resource nodes (such as review experts, processing personnel, and service equipment) generally relies on manual operation or simple static rule matching. Existing technical solutions have the following limitations when facing high concurrency and large-scale tasks: First, the matching criteria are singular, typically relying solely on simple text matching based on task requirements and static attribute tags of resource nodes, ignoring the real-time load and dynamic availability status of resource nodes. This leads to insufficient matching accuracy and the possibility of misallocation where assigned nodes are actually unresponsive or overloaded. Second, during the allocation process, if the state of a resource node changes, the lack of an effective concurrency control mechanism means the system may make allocation decisions based on outdated state information, causing state conflicts and data inconsistencies. Third, the exception handling mechanism is weak; when allocation fails or a resource node rejects the task, there is a lack of mature automatic reassignment and fallback strategies, easily leading to allocation process interruptions or task backlogs. These shortcomings not only reduce the efficiency of resource scheduling but also affect the fairness and traceability of task allocation. Therefore, there is an urgent need for a resource allocation scheme that can integrate multi-dimensional features, ensure consistency of state data, and have closed-loop scheduling capabilities. Summary of the Invention

[0003] To address the problems of existing technologies, such as single matching criteria, inconsistent state data, and insufficient robustness of allocation processes, this application proposes a resource allocation method and system based on multi-dimensional features and state coordination. This method performs multi-dimensional quantitative fusion calculation of the static attributes, real-time load, and availability status of resource nodes. It also introduces a state snapshot and change mutual exclusion mechanism during the allocation execution cycle, combined with automatic state transition and reallocation operations, to achieve accurate, highly reliable, and traceable resource allocation.

[0004] To achieve the above objectives, this application adopts the following technical solution: A resource allocation method based on multidimensional features and state coordination includes: Obtain the requirements of the target task, as well as the static attribute labels, real-time load data and current availability status of each resource node in the candidate resource pool; Based on a preset weighting strategy, the matching degree of the static attribute tags, the load factor corresponding to the real-time load data, and the availability factor corresponding to the current availability status are determined. The matching degree, the load factor, and the availability factor are then fused and calculated to obtain a comprehensive matching degree index for each resource node. Within a preset allocation execution cycle, a state snapshot of the candidate resource pool is generated, and state change mutual exclusion control is executed. Based on the comprehensive matching index and the state snapshot, target resource nodes are selected from the candidate resource pool to perform allocation operations, allocation feedback results are obtained, and a reallocation operation is triggered based on the allocation feedback results to obtain the final allocation scheme.

[0005] The above solution constructs a multi-dimensional comprehensive matching index by weightedly integrating quantitative indicators from three dimensions: static attribute tag matching, real-time load assessment, and availability status awareness. This enables allocation decisions to simultaneously consider the professional matching degree of resource nodes, task carrying capacity, and real-time availability. At the same time, it introduces a status snapshot and mutual exclusion control mechanism to ensure the consistency of status data within the allocation cycle, and forms a closed-loop processing flow through allocation feedback-driven reallocation operations, thereby significantly improving the accuracy and robustness of allocation.

[0006] As one implementation method, the fusion calculation of the matching degree, the load factor, and the availability factor includes: The matching degree is determined based on the comparison results between the demand characteristics and the static attribute tags; The load factor is determined based on the ratio between the real-time load data and the preset load threshold. The availability factor is determined based on the state category to which the current available state belongs; The matching degree, the load factor, and the availability factor are weighted and summed according to the preset weighting strategy to obtain the comprehensive matching degree index.

[0007] As one implementation method, determining the matching degree based on the comparison results between the demand features and the static attribute tags includes: The first set of labels contained in the demand features is compared with the second set of labels contained in the static attribute labels by performing a Cartesian product comparison to generate a feature vector containing multiple matching elements; wherein, the value of the matching element is assigned a three-level quantization based on complete matching, partial matching or no matching; Based on the type of the target task, the optimal pooling strategy is adaptively selected from a preset strategy library; wherein, the strategy library includes a max pooling strategy and an average pooling strategy. The feature vector is compressed based on the optimal pooling strategy to obtain the matching degree in scalar form.

[0008] The above scheme, through three-level quantization assignment and adaptive pooling strategy selection, can flexibly adjust the aggregation method of matching degree according to the task type (such as single-discipline task or interdisciplinary task), thereby improving the adaptability and accuracy of matching degree calculation.

[0009] As one implementation method, generating a state snapshot of the candidate resource pool within a preset allocation execution cycle and performing state change mutual exclusion control includes: When the allocation operation is initiated, a snapshot of the current state is created, and the validity period of the snapshot is set. When a state change instruction for the target resource node is received during the allocation execution cycle, the state change mutual exclusion control is executed, and the state change instruction is applied to the next round of allocation operation.

[0010] As one implementation, executing the state change mutual exclusion control and applying the state change instruction to the next round of allocation operation includes: In the current allocation round, the issued allocation instructions are not withdrawn, and the corresponding response tracking continues to be executed; When the allocation feedback result triggers the reallocation operation, the state snapshot or the latest state data is reread; If the current available state of the target resource node has been updated based on the state change instruction, then the target resource node is processed according to the updated latest state data in the reallocation operation.

[0011] The above scheme achieves a balance between data consistency and process continuity by maintaining the allocation instruction in the current round and applying the state update in the next round through a mutual exclusion strategy. This is achieved by ensuring that the current allocation process is not interrupted by external state changes and that the latest state takes effect immediately in subsequent allocation decisions.

[0012] As one implementation method, it also includes: An automatic transition operation is performed on the current availability status of the resource node based on a preset time-triggered condition; wherein the automatic transition operation includes: In response to receiving a status setting command, the system records the status change timestamp and starts a timer. When the timer reaches a preset duration, the system automatically restores the currently available status to the idle status. Upon receiving and approving a status suspension request, the system records the suspension end time. When the suspension end time is reached, the system automatically restores the current available status to the idle status.

[0013] The above solution achieves automated lifecycle management of resource node status through two mechanisms: automatic time-based cancellation and automatic recovery upon expiration. This avoids situations where resource nodes are unavailable for extended periods due to manual recovery of their status, and reduces the manual maintenance workload for administrators.

[0014] As one implementation method, triggering the reallocation operation based on the allocation feedback result includes: When the allocation feedback result is rejection or no response after timeout, the first-level automatic reallocation operation is triggered, the corresponding resource node is excluded from the candidate resource pool, and a substitute resource node is selected from the remaining resource nodes. When the number of times the first-level automatic reallocation operation is executed reaches the preset limit, or when the number of available resource nodes in the candidate resource pool does not meet the requirements of the target task, the second-level manual fallback operation is triggered, the target task is transferred to the allocation failure list, and a manual allocation operation interface is provided to receive manual intervention instructions.

[0015] The above solution constructs a three-tiered processing architecture of automatic allocation, automatic reallocation, and manual fallback, ensuring that the task allocation process can be completed without interruption in various abnormal situations such as resource node rejection, timeout failure, and insufficient candidate pool.

[0016] As one implementation method, it also includes: When the first-level automatic reallocation operation is triggered, the reallocation attempt counter is incremented, and it is determined whether the incremented value has reached the preset upper limit. Throughout the entire execution chain of the allocation operation, audit log data is recorded in a structured manner; wherein, the audit log data includes rule version information, the calculation basis of the comprehensive matching degree index, the candidate resource node list and sorting results, the final allocation scheme, and operator information; Based on the task identifier of the target task, one-click traceability query of the audit log data is supported.

[0017] The above solution achieves complete traceability of allocation decisions through structured recording and one-click traceability of end-to-end audit logs, meeting the needs of enterprise internal audit and compliance inspection.

[0018] As one implementation method, the step of selecting a target resource node from the candidate resource pool and performing an allocation operation based on the comprehensive matching index and the state snapshot includes: An initial recommendation list is generated based on the comprehensive matching index; Check whether the initial recommendation list meets the preset hard constraints; If the conditions are not met, then from the resource nodes in the candidate resource pool that were not selected into the initial recommendation list, select the resource node that meets the hard constraints and has the highest comprehensive matching index, and replace the resource node with the lowest comprehensive matching index in the initial recommendation list. Repeat the replacement operation until all the hard constraints are met, and obtain the final recommendation list to perform the allocation operation.

[0019] The above solution, through the checking and iterative correction of hard constraints, can ensure that the recommended list still maintains the optimization goal of maximizing the overall matching degree index while meeting the preset mandatory rules (such as the requirement to include specific types of resource nodes).

[0020] Furthermore, this application also provides a resource allocation system based on multidimensional features and state coordination, used to implement the resource allocation method based on multidimensional features and state coordination as described in any of the above schemes, including: The data acquisition module is used to acquire the requirements of the target task, as well as the static attribute labels, real-time load data and current availability status of each resource node in the candidate resource pool; The comprehensive matching degree calculation module is used to determine the matching degree of the static attribute tag, the load factor corresponding to the real-time load data, and the availability factor corresponding to the current availability status based on a preset weight strategy, and to perform a fusion calculation on the matching degree, the load factor, and the availability factor to obtain the comprehensive matching degree index of each resource node. The state coordination control module is used to generate a state snapshot of the candidate resource pool within a preset allocation execution cycle and to perform state change mutual exclusion control. The allocation execution and reallocation module is used to select target resource nodes from the candidate resource pool based on the comprehensive matching degree index and the status snapshot, perform allocation operations, obtain allocation feedback results, and trigger reallocation operations based on the allocation feedback results to obtain the final allocation scheme.

[0021] The above system integrates multi-dimensional feature quantification evaluation, state collaborative control and hierarchical allocation processing through the coordinated cooperation of various modules, providing a corresponding system carrier for the methodology.

[0022] Beneficial effects: This application constructs a resource allocation scheme based on multi-dimensional feature fusion and state coordination. By weighted fusion calculation of the static attribute matching degree of resource nodes, real-time load factor, and availability factor, the assessment of resource suitability is elevated from single-label comparison to multi-dimensional quantitative decision-making, significantly improving the accuracy of allocation compared to traditional static matching methods. By generating state snapshots and implementing mutual exclusion control for state changes during the allocation execution cycle, the interference of external state mutations on the current allocation decision is isolated. Simultaneously, the latest state is applied in real-time during the reallocation phase, solving the bottleneck problem of balancing data consistency and process continuity in high-concurrency resource scheduling scenarios. Through a time-triggered condition-driven automatic state transition mechanism, the state maintenance of resource nodes is freed from dependence on manual operation, ensuring the timeliness of the resource pool. Through reallocation operations and full-link audit logs, a complete anomaly handling path from automatic closed-loop processing to manual intervention is constructed, endowing the allocation process with complete decision reconstruction capabilities, comprehensively improving the robustness and traceability of the resource allocation process. Attached Figure Description

[0023] Figure 1 A flowchart illustrating a resource allocation method based on multidimensional features and state coordination, provided for an embodiment of this application; Figure 2 A flowchart illustrating the method for obtaining the comprehensive matching index provided in this application embodiment; Figure 3 This is a system architecture diagram of a resource allocation system based on multidimensional features and state coordination, provided for an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0025] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0026] Example 1 like Figure 1As shown, this embodiment provides a resource allocation method based on multi-dimensional features and state coordination. This method can be executed by a computer system, server, or electronic device with data processing capabilities, and is used to automatically select the optimal combination of resource nodes for a specific task from multiple candidate objects. Specifically, the method includes the following steps: Step S110: Obtain the demand characteristics of the target task, as well as the static attribute labels, real-time load data, and current availability status of each resource node in the candidate resource pool.

[0027] Specifically, a target task refers to any operational unit that requires resource allocation, such as a job creation project awaiting review, a production order to be assigned, a customer service work order to be processed, or a computing task requiring scheduled computing power. Demand characteristics are structured descriptions of the target task's own attributes, containing at least one or more tags to characterize the professional direction, skill requirements, or business domain involved in the task. The candidate resource pool refers to the set of resource nodes available for allocation in the current system. Resource nodes are the basic units capable of undertaking and processing target tasks, and can correspond to different entities in different application scenarios, such as review experts, production equipment, customer service seats, or server nodes. Each resource node in the system is associated with three types of data: static attribute tags, which are pre-configured and relatively stable attribute information, such as expert's professional direction tags, equipment processing capacity parameters, and agent service skill groups; real-time load data, which is a dynamic indicator reflecting the number of tasks that the resource node is currently processing or has been assigned but not yet completed, such as the total number of projects currently under review by experts, the length of the equipment's task queue, and the number of concurrent online sessions for agents; and current availability status, which is an instantaneous status indicator representing whether the resource node is ready to accept new tasks at any given moment, such as idle, busy, suspended, or blacklisted. By acquiring the above three dimensions of data at once through step S110, subsequent allocation decisions no longer rely on a single dimension of static information but are based on a more comprehensive data foundation. This solves the problems of low allocation efficiency and insufficient accuracy caused by incomplete information acquisition in traditional methods.

[0028] Step S120: Based on the preset weight strategy, determine the matching degree of static attribute tags, the load factor corresponding to real-time load data, and the availability factor corresponding to the current availability status. Then, perform a fusion calculation on the matching degree, load factor, and availability factor to obtain the comprehensive matching degree index of each resource node.

[0029] The preset weighting strategy is a set of pre-set or configurable weight parameters used to define the proportion of the above three dimensions in the final decision. Matching degree is a quantitative value obtained by comparing the requirements of the target task with the static attribute labels of each resource node, used to measure the degree of fit between the resource node and the target task at the professional or attribute level. Load factor is an indicator calculated based on real-time load data, used to reflect the current task load pressure of the resource node. For example, when the real-time load data of a resource node is close to or exceeds its preset processing capacity limit, its load factor value is low, indicating that the node is currently unsuitable for undertaking new tasks. Availability factor is a coefficient determined based on the current availability status, used to reflect whether the resource node is currently in an allocable state. For example, the availability factor value is high when the status is idle, and low or zero when the status is busy or suspended. Fusion calculation refers to the mathematical synthesis of matching degree, load factor, and availability factor according to the preset weighting strategy to obtain a scalar-form comprehensive matching degree index for each resource node. This comprehensive matching index integrates information from three objective technical dimensions: static attribute matching, real-time load pressure, and immediate availability. This allows the system to perform horizontal comparison and ranking of all resource nodes in the candidate resource pool in a unified and quantitative manner. Compared to traditional manual allocation methods, where operators rely solely on subjective experience and partial knowledge of an expert database for screening, this step is automated by the computer to perform multi-dimensional data fusion calculations. This avoids human oversight and cognitive bias, ensuring the objectivity and repeatability of allocation decisions from a fundamental mechanism perspective.

[0030] Step S130: Generate a state snapshot of the candidate resource pool within a preset allocation execution cycle, and perform state change mutual exclusion control.

[0031] The allocation execution cycle refers to the entire time period from the start of an allocation operation to the receipt of the allocation feedback result. At the start of this cycle, the system creates a momentary copy of the status data of all resource nodes in the candidate resource pool at the current instant, i.e., a state snapshot. The purpose of this state snapshot is to provide a consistent state benchmark for all calculations and judgments within this allocation cycle, avoiding data inconsistencies in the allocation logic due to concurrent changes in external states. State change mutual exclusion control is a concurrent access control strategy. Its core logic is: within an allocation execution cycle, if the system receives state change instructions for certain target resource nodes (e.g., an expert is set to busy by the administrator, or a device's status changes to maintenance), the system will not immediately withdraw the issued allocation instructions or recalculate in the current allocation round. Instead, it will continue to complete the allocation operation and response tracking for this round based on the previously generated state snapshot. Simultaneously, the system will record these state change information and apply the latest changed state to the next round of allocation operations. Through step S130, this embodiment ensures both the continuity and determinism of a single allocation process in a real environment where the resource node status changes dynamically, and also ensures that the status update takes effect in a timely manner in subsequent allocations, thereby achieving a balance between data consistency and process continuity.

[0032] Step S140: Based on the comprehensive matching degree index and the status snapshot, select the target resource node from the candidate resource pool to perform the allocation operation, obtain the allocation feedback result, and trigger the reallocation operation based on the allocation feedback result to obtain the final allocation scheme.

[0033] After obtaining the comprehensive matching index calculated in step S120 and the status snapshot generated in step S130, the system selects one or more resource nodes with the highest comprehensive matching index from the candidate resource pool as target resource nodes and sends allocation instructions or task invitations to these target resource nodes. The specific form of the allocation operation is related to the application scenario; for example, it could be sending a review invitation notification to a selected expert, dispatching a production work order to a designated device, or routing a customer session to a selected agent. After executing the allocation operation, the system continuously tracks the response status of the target resource nodes and obtains the allocation feedback result. The allocation feedback result can include various types, such as the resource node accepting the allocation, the resource node rejecting the allocation, or no response being received within a preset waiting time (i.e., no response after timeout). When the allocation feedback result is rejection or no response after timeout, the system triggers a reallocation operation. The reallocation operation refers to excluding resource nodes that have rejected or failed to respond within the candidate resource pool, and then, based on the existing state snapshot and comprehensive matching index, reselecting replacement nodes from the remaining resource nodes and performing the allocation. This process is repeated until the target task's requirement for the number of resource nodes is met, ultimately forming a complete and effective final allocation scheme. The "allocation → feedback → reallocation" closed-loop mechanism constructed through step S140 enables this embodiment to automatically self-correct when encountering abnormal situations such as resource node rejection or timeouts, without requiring manual intervention for re-screening and communication, thus improving the robustness and execution efficiency of the allocation process overall.

[0034] Example 2 This embodiment, based on step S120 of embodiment 1, further elaborates on the specific sub-processes of fusion calculation and matching degree determination. It should be noted that the calculation steps described below can be executed by the comprehensive matching degree calculation module, and its input data comes from the multi-dimensional data obtained in step S110 of embodiment 1.

[0035] In step S120, the matching degree, load factor, and availability factor are fused and calculated based on a preset weighting strategy, as follows: Figure 2 As shown, it can be broken down into the following sub-steps.

[0036] Step S121: Based on the comparison results between the requirement features and the static attribute tags, determine the matching degree. Specifically, when determining the matching degree, the system organizes all tags contained in the requirement features of the target task into a first tag set, and organizes all tags contained in the static attribute tags of each resource node into a second tag set. Then, the two sets are compared by performing a Cartesian product comparison to generate a feature vector containing multiple matching elements. The value of each matching element is quantized and assigned at three levels based on whether it is a complete match, a partial match, or a non-match. Specifically, for any tag pair consisting of any tag in the first tag set and any tag in the second tag set, when the two tags semantically point to the exact same concept (e.g., both are "relay protection"), the matching element is assigned a value of 1; when the two tags semantically have an inclusion relationship, a hierarchical relationship, or an intersection relationship (e.g., the task requirement tag is "power system automation," and the resource node tag is "relay protection" or "substation automation," the latter belonging to a subdomain or related branch of the former), the matching element is assigned a value of 0.5; when the two tags semantically have no relation (e.g., the task requirement tag is "relay protection," and the resource node tag is "communication technology"), the matching element is assigned a value of 0. Thus, the system obtains a feature vector with a dimension equal to the size of the first tag set multiplied by the size of the second tag set, where each element's value falls within the set {0, 0.5, 1}. Compared to traditional binary matching (match or no match), this three-level quantification method can more precisely characterize the correlation between task requirements and resource node attributes. Especially when dealing with hierarchical professional labeling systems, the introduction of partial matching allows resource nodes that are related but not in the same sub-field to still obtain reasonable matching scores and will not be rudely excluded, thereby expanding the range of effective candidate resource nodes and improving the feasibility of the allocation scheme under limited resources.

[0037] After generating the feature vector, the system adaptively selects the optimal pooling strategy from a pre-defined strategy library based on the type of the target task. The strategy library includes at least two strategies: max pooling and average pooling. Max pooling takes the maximum value of all matching elements in the feature vector as the final matching score. It is suitable for single-discipline or single-domain tasks, where the target task only requires resource nodes to be capable in a specific sub-field. In this case, a high matching score should be given as long as the resource node achieves a high match on at least one label pair. For example, a vocational innovation project purely focused on "relay protection" only needs to evaluate which expert has the highest matching score in relay protection. Average pooling, on the other hand, takes the arithmetic mean of all matching elements in the feature vector as the final matching score. It is suitable for interdisciplinary or comprehensive tasks, where the target task involves multiple technical directions and requires resource nodes to cover multiple fields. In this case, the matching of all label pairs should be comprehensively considered. For example, an interdisciplinary project involving both "new energy grid connection" and "electricity market" needs to evaluate the expert's comprehensive matching level in these two fields. The adaptive selection decision logic can be that the system automatically determines the optimal pooling strategy based on the number of tags contained in the target task's requirement features and the semantic distribution among the tags: when the requirement feature contains only a single tag or multiple tags that are semantically closely related to the same subject branch, the max pooling strategy is selected; when the requirement feature contains multiple tags that are semantically related to different subjects or have high independence, the average pooling strategy is selected. In some implementations, administrators can also explicitly specify the pooling strategy for specific task types in the rule configuration. By selecting an adaptive pooling strategy, this embodiment avoids the matching bias that a single aggregation method may produce under different task types. For example, if max pooling is used for all tasks, interdisciplinary tasks are likely to be matched with resource nodes that are only good at one direction and completely irrelevant to other directions; if average pooling is used for all tasks, single-discipline tasks may have their scores diluted due to the resource node tag set containing a large number of irrelevant tags, resulting in unreasonable ranking.

[0038] Step S122: Determine the load factor based on the ratio between the real-time load data and the preset load threshold. Specifically, the real-time load data is an objective value reflecting the current task capacity of a resource node, monitored and recorded by the system in real time. Examples include the number of projects currently under review by an expert, the number of processing orders currently queued by a device, and the number of concurrent sessions currently being handled by an agent. The preset load threshold is a pre-set upper limit of processing capacity based on resource configuration or management strategies. Examples include the maximum number of projects each expert can simultaneously handle, and the maximum task queue length for each device. The load factor can be calculated by dividing the real-time load data by the preset load threshold to obtain a load ratio, and then subtracting this load ratio from a constant value. For example, when an expert currently has 2 projects under review and the preset upper limit is 5, their load ratio is 0.4, and the load factor can be calculated as 1 minus 0.4 equals 0.6. When the real-time load data reaches or exceeds the preset load threshold, the load factor is directly set to 0, indicating that the resource node currently has no spare capacity to handle new tasks and will automatically be at a disadvantage in subsequent sorting. By introducing a real-time load factor, the system can prioritize resource nodes with less current task load during allocation, thereby achieving load balancing of the resource pool and preventing some resource nodes from becoming overloaded due to task clustering, affecting overall processing quality and response time, while other resource nodes remain idle and wasted.

[0039] Step S123: Determine the availability factor based on the status category to which the current available status belongs. Specifically, the current available status of a resource node is an instantaneous status identifier maintained in real time by the system through the status management module. It typically includes at least status categories such as idle, busy, suspended, and blacklisted, with different availability factor values ​​corresponding to different status categories. For example, the idle status corresponds to an availability factor of 1, indicating that the resource node is fully capable of undertaking new tasks; the busy status corresponds to an availability factor between 0 and 1, such as 0.3, indicating that although the resource node is temporarily busy, it still has a certain probability of participating in allocation; the suspended and blacklisted statuses correspond to an availability factor of 0, indicating that the node is not currently capable of undertaking new tasks and should be automatically filtered out during allocation. In some implementations, the mapping relationship between status categories and availability factors can be adjusted by administrators according to actual business rules. For example, the availability factor for the busy status can be set to 0 to completely exclude busy experts, or the suspended status can be set to a small positive value so that it can still be considered when the candidate pool is severely insufficient.

[0040] After obtaining the factors of the above three dimensions, step S124 involves weighting and summing the matching degree, the load factor, and the availability factor according to the preset weighting strategy to obtain the comprehensive matching degree index. The formula for weighted summation can be expressed as: ; In this system, Score represents the overall matching degree index of each resource node, Match represents the matching degree, Load represents the load factor, and Avail represents the availability factor. w1, w2, and w3 are the matching degree weight coefficient, load weight coefficient, and availability weight coefficient, respectively. All three weight coefficients are positive numbers, and their sum equals 1. For example, they can be set to 0.5, 0.3, and 0.2, or 0.6, 0.2, and 0.2, respectively. The specific values ​​of the weight coefficients can be configured by administrators according to business strategies. When the business requires high precision in professional matching, the value of w1 can be increased; when the resource pool load balancing pressure is high, the value of w2 can be appropriately increased; when the resource node status fluctuates frequently, the value of w3 can be appropriately increased to increase the influence of the status dimension in decision-making.

[0041] To facilitate understanding of the above calculation process, a specific numerical example is given below. Assume the target task's requirements include a label set T = {relay protection, power system}, and three review experts need to be assigned. There is one expert A in the current candidate resource pool, whose static attribute label set is E = {relay protection, automation}, the number of projects currently under review is 2, the preset load limit is 5, and the current available status is idle. The preset weight coefficients are w1 = 0.5, w2 = 0.3, and w3 = 0.2. First, the matching degree is calculated: a Cartesian product comparison is performed on T and E to obtain the matching status of four label pairs. "Relay protection - relay protection" is a complete match with a value of 1, "relay protection - automation" is a partial match with a value of 0.5, "power system - relay protection" is a partial match with a value of 0.5, and "power system - automation" is a partial match with a value of 0.5, forming the feature vector [1, 0.5, 0.5, 0.5]. Since this task involves two closely related areas in the power industry—"relay protection" and "power system"—the system can adaptively select a max-pooling strategy, with the match value set to the maximum value of the feature vector (1). Alternatively, if the task is labeled as an interdisciplinary project, the system will use an average pooling strategy, with the match value set to the average of the four elements, i.e., (1+0.5+0.5+0.5) divided by 4 equals 0.625. Next, the load factor is calculated: the current number of projects under review (2) divided by the preset upper limit (5) yields a load ratio of 0.4, and the load factor Load = 1 - 0.4 = 0.6. Finally, the availability factor is determined: expert A is in an idle state, and the availability factor Avail is set to 1. Finally, a weighted sum is calculated: if the max pooling strategy is used, the score = 0.5×1 + 0.3×0.6 + 0.2×1 = 0.5 + 0.18 + 0.2 = 0.88; if the average pooling strategy is used, the score = 0.5×0.625 + 0.3×0.6 + 0.2×1 = 0.3125 + 0.18 + 0.2 = 0.6925. The system calculates the score for all experts in the candidate resource pool in the same way, and finally sorts them from highest to lowest score. The top N experts (the top 3 in this case) with the highest scores are included in the recommendation list.

[0042] This embodiment, through the above-described decomposition steps, concretizes the overarching description of "fusion calculation based on a preset weight strategy" in step S120 of embodiment 1 into a complete and executable calculation process. It clarifies the three-level quantization generation mechanism of the matching degree, the adaptive selection logic of the pooling strategy, the ratio calculation method of the load factor, and the state category mapping relationship of the availability factor. This ensures that the calculation process of the comprehensive matching degree index forms a closed loop from data input to result output, fully disclosing the implementation details of the core algorithm. Furthermore, the calculation of each factor relies on objective data collected or maintained in real time by the computer system (static labels from database configuration, real-time load from system monitoring, and availability status from the state management module). The entire calculation process is automatically executed by the computer, not based on abstract mathematical rules or human mental activity, thus technically supporting the object eligibility of the solution.

[0043] Example 3 This embodiment, based on the "generating a state snapshot of the candidate resource pool and executing state change mutual exclusion control" already described in step S130 of embodiment 1, further elaborates on the internal process details of state snapshot creation, validity period management, and state change mutual exclusion control. It should be noted that the process of triggering a reallocation operation based on allocation feedback results involved in step S140 of embodiment 1 is closely related to the mutual exclusion control strategy described in this embodiment. How the system makes decisions based on the state snapshot or the latest state data when reallocation is triggered is precisely the specific manifestation of the mutual exclusion control strategy in the reallocation scenario.

[0044] In step S130 of Example 1, a state snapshot of the candidate resource pool is generated within a preset allocation execution cycle, and state change mutual exclusion control is executed. This can be specifically implemented as follows: When the allocation operation is started, the system creates a state snapshot at the current moment and sets the validity period of the state snapshot. Specifically, when the computer system detects that an allocation process has been triggered, such as a request for allocation of review experts for a vocational innovation project entering the execution queue, before officially starting to calculate the comprehensive matching index, the system first calls the state reading interface to batch obtain the current available state data of all resource nodes in the candidate resource pool, and writes this data into a temporary data copy in a structured form, i.e., the state snapshot. The content recorded in the state snapshot includes at least the unique identifier of each resource node and its current available state value at the time of snapshot creation. Auxiliary information such as real-time load data can also be recorded as needed, but the core purpose is to solidify the availability state benchmark of each resource node at the time of allocation start. Once the state snapshot is created, all calculation, comparison, and selection operations within this allocation execution cycle will be based on the state data recorded in the snapshot, and the latest state of the resource nodes will no longer be queried in real time. The significance of this approach is that the allocation cycle may undergo multiple iterations (such as reallocation after the initial allocation is rejected). If the real-time status is read every time, inconsistencies may occur between different iterations. For example, a resource node may be idle in the first round of allocation, selected after scoring, but its status may be changed to busy while waiting for a response. If the latest status is read directly during reallocation, the node may be incorrectly retained or excluded during reallocation. The snapshot mechanism, on the other hand, ensures the consistency of the decision-making benchmark within the same allocation cycle.

[0045] The validity period of a status snapshot is a configurable time parameter, such as a preset 72 hours. The purpose of the validity period is to define the lifecycle of the snapshot: reallocation operations triggered within the validity period continue to use that snapshot; if the entire allocation process continues beyond the validity period for various reasons without final allocation, the snapshot is automatically marked as invalid by the system, and a new snapshot must be created and the allocation process restarted when allocation is triggered again. The specific duration of the validity period can be adjusted by administrators according to business scenarios. For expert review scenarios, 72 hours typically covers the entire time window from sending an invitation to waiting for expert responses and, if necessary, multiple rounds of reallocation; for scenarios requiring faster response times (such as real-time customer service allocation), the validity period can be shortened to several hours or even minutes; and for scenarios requiring longer coordination times (such as large equipment scheduling), the validity period can be extended to several days or even weeks. This embodiment does not limit the specific value of the validity period, but only emphasizes its technical significance in preventing outdated snapshots from being used indefinitely, thus making decision-making decisions obsolete.

[0046] During the allocation execution cycle, if the system receives a state change instruction for a target resource node, it executes state change mutual exclusion control and applies the instruction to the next allocation round. Here, a state change instruction refers to any operation request that may change the current available state of a resource node, such as a resource node automatically setting its state to busy, an administrator adding a resource node to a pending list, or removing a resource node from a blacklist. State change mutual exclusion control means that these change instructions do not immediately take effect in the current allocation round; instead, they are temporarily stored by the system and applied to subsequent decisions after the current allocation round ends.

[0047] Furthermore, the process of implementing mutual exclusion control for state changes and applying state change instructions to the next round of allocation operations can be refined into the following processing logic. In the current allocation round, the system maintains the issued allocation instructions without revocation and continues to execute the corresponding response tracking. That is, when an ongoing allocation round has already issued an allocation instruction to the selected target resource node (e.g., sending a review invitation to an expert), even if the node's status changes after the invitation is issued—for example, the expert is suddenly set to busy by the administrator—the system will not automatically revoke the issued invitation upon detecting this status change, nor will it interrupt the response status tracking for that invitation. The system continues to monitor whether the expert accepts, rejects, or fails to respond within a preset waiting period (e.g., 48 hours). The advantage of this design is that it ensures the continuity of the allocation process: In actual business operations, state changes may be triggered by various reasons, some of which are temporary or revocable. If all issued invitations are revoked the moment a state change occurs, it will lead to frequent interruptions in the allocation process and increase unnecessary redistribution overhead. By not withdrawing the issued allocation instructions, the system gives the resource nodes that have received the invitation sufficient time to respond, while also avoiding erroneous withdrawals caused by the instantaneous nature of state changes.

[0048] When the allocation feedback result triggers a reallocation operation, the system rereads the state snapshot or the latest state data. Here, "allocation feedback result triggers a reallocation operation" corresponds to the reallocation operation triggered in step S140 of Embodiment 1 when the allocation feedback result is a rejection or a timeout without response. At the point of triggering reallocation, the system faces two data source reading options: one is to read the created state snapshot, and the other is to skip the snapshot and directly query the latest state data in the database. These two options can be combined according to a preset strategy: generally, if the state snapshot is still valid, the system prioritizes reallocation calculation based on the snapshot to maintain the continuity of the decision benchmark within the same allocation cycle; however, in some implementations, the system can also actively query the latest state data in the database when reallocation is triggered, or use the intersection of the snapshot and the latest state data as the judgment criterion, that is, only if the snapshot records that the node is available and the latest state indicates that the node is still available, will it continue to be included in the candidate pool for reallocation.

[0049] If the current available status of the target resource node has been updated based on the status change instruction, the target resource node will be processed according to the updated latest status data during the reallocation operation. For ease of understanding, a specific operational example is given below using the reallocation process in step S140 of Embodiment 1. Assume that at the start of an allocation execution cycle, the system creates a status snapshot, which records expert A's status as idle. After comprehensive matching index calculation and sorting, expert A is selected as one of the target resource nodes, and the system sends a review invitation to it. While waiting for a response, expert A, due to a temporary business trip, sets its status to busy through the system interface, triggering a status change instruction. According to the mutual exclusion control strategy, the system will not withdraw the invitation already sent to expert A in the current round. Assume that expert A subsequently refuses to accept within the response time limit (or fails to respond within the timeout period), and the allocation feedback result triggers a reallocation operation. During the preparation phase of the reallocation operation, the system rereads the status snapshot or the latest status data, and at this time finds that expert A's latest status has changed to busy. According to the preset availability factor mapping rules, the availability factor of a busy state may be 0.3 or even 0, meaning that expert A is considered unqualified to serve as a substitute in the current redistribution round. Therefore, during the redistribution operation, the system will exclude expert A from the candidate resource pool for this redistribution and select the node with the highest comprehensive matching index from the remaining available resource nodes as the substitute node, sending a new allocation instruction to it. This processing mechanism is the specific implementation of the mutual exclusion strategy of "no change in this round, effective in the next round". "No change" means that the instructions issued in the current round are not withdrawn and the response tracking is not interrupted; "effective in the next round" means that when entering the redistribution (i.e., the next round), the system will re-evaluate the availability of each resource node according to the latest updated status and perform screening and selection accordingly.

[0050] Through the entire process described above, this embodiment achieves a balance between data consistency and process continuity in complex environments where resource node states may change concurrently. On one hand, state snapshots ensure the uniformity of decision-making benchmarks within the same allocation execution cycle, making allocation decisions deterministic and interpretable. Managers or auditors can clearly understand the state data at which moment each allocation was based when querying the data afterward. On the other hand, mutual exclusion control for state changes ensures that external state changes do not disrupt the ongoing allocation process, while also ensuring that these state changes are promptly considered during reallocation, preventing resource nodes with changed states from being incorrectly selected as targets again. This dual protection mechanism is of great significance for ensuring allocation quality and process stability in scenarios with a large number of resource nodes and frequent state fluctuations (e.g., large enterprises with hundreds of experts whose states change frequently).

[0051] Example 4 This embodiment, building upon the basic method provided in Embodiment 1, further offers an automatic resource node state transition mechanism. Unlike the approach described in Embodiment 3, which ensures consistency in a single allocation by generating state snapshots and implementing mutual exclusion control for state changes within the allocation execution cycle, this embodiment focuses on lifecycle management where resource node states automatically change over time. The triggering condition is based on preset time conditions and does not depend on the initiation or feedback of the allocation operation itself. This design enables the system to automatically maintain the availability of resource nodes without human intervention, thereby preventing resource nodes from being mistakenly judged as unavailable for extended periods due to administrators or the resource nodes themselves forgetting to manually restore their states.

[0052] As one implementation method, this method further includes: performing an automatic transfer operation on the current availability status of resource nodes based on preset time-triggered conditions. The automatic transfer operation includes at least two parallel processing paths, which can coexist, or only one can be enabled depending on different business scenarios.

[0053] The first path addresses temporary unavailability states, such as a busy state. When the system receives a status setting instruction, this instruction can be triggered automatically by the resource node through the client, or by an operator with management privileges through the management interface. The system records the timestamp of this status change and starts a timer. The timer's duration is a configurable preset duration, such as a default of 7 days (168 hours), which can be adjusted by administrators to shorter or longer periods, such as 3 days or 14 days. When the preset duration is reached, the system automatically restores the resource node's current available state to an idle state without any manual intervention. From a technical implementation perspective, this timer can be implemented using an operating system-level scheduled task, a delayed message mechanism based on a message queue, or a background daemon process periodically scanning for expired records; this application does not specify any particular method. Taking the scenario of assigning review experts as an example, if an expert is temporarily away on business and sets their status to busy through their personal control panel, the system automatically records the setting time and automatically switches the expert's status back to idle 7 days later. Even if the expert forgets to manually remove the busy status after returning from a business trip, the system, acting as an automatic lifecycle manager, has already completed the recovery process on their behalf. The expert can then immediately re-enter the candidate resource pool and participate in the automatic allocation of subsequent tasks. Compared to the existing method of relying on manual verification and modification of status one by one, this mechanism significantly reduces the workload of administrators and avoids resource nodes becoming permanently unavailable due to forgetfulness. If the system did not provide this automatic removal capability, experts might remain in a busy status for an extended period after their business trip, leading administrators to mistakenly believe they are unable to handle tasks and repeatedly filter other nodes, further exacerbating the manpower consumption for task allocation.

[0054] The second path addresses long-term or planned unavailability states, such as a suspended state. When the system receives a suspension request from a resource node, the request does not take effect immediately but enters an approval process. The request typically includes information such as the reason for suspension, the expected start time, and the expected end time. The request is pushed to the terminal of an administrator with approval authority. After the administrator approves it, the system officially changes the current available state of the resource node to a suspended state and records the suspension end time. During the suspension period, the resource node is automatically excluded from the status filtering logic in the allocation process and does not participate in the allocation of any new tasks. When the system time reaches the recorded suspension end time, the system automatically restores the current available state to an idle state, and the resource node becomes eligible for allocation again. For example, an expert needs to leave their post for an extended period due to maternity leave. They submit a suspension request through the system, specifying the expected start and end dates of nine months. After the administrator approves it, the system marks the expert's status as suspended. Nine months later, the system automatically restores the expert's status to idle on the scheduled end date. The expert can immediately receive review tasks upon returning to their post without needing to contact the administrator for manual restoration. Similarly, if an expert returns early, they can proactively submit a request to cancel the suspension, and the idle status will be restored early after approval. It should be noted that the approval process for suspension requests is not the only way to achieve automatic workflow. In some implementation scenarios, the suspension operations of certain trusted roles can be set to take effect directly without approval, as long as the system can record the suspension end time and automatically restore it upon expiration.

[0055] Through the two automatic workflow paths described above, this embodiment upgrades resource node status management from a manual maintenance mode to a time-driven automatic lifecycle management mode. The micro-mechanism of this mechanism lies in its decoupling of state change actions from state recovery actions in time. It utilizes the precise timing capabilities of the computer system to replace human memory, thereby fundamentally solving the problem of "state residue" caused by human negligence. For example, in traditional purely manual management, if an expert marks themselves as busy and then forgets to restore their status, they may not receive any task invitations for weeks or even months, essentially "disappearing" from the available resource pool. However, with the automatic time-removal mechanism introduced in this embodiment, the busy state is given a defined lifecycle, inevitably restoring upon expiration, ensuring that the dynamic state of the resource node always aligns with the actual situation. Similarly, the automatic restoration of suspended states upon expiration allows the system to accurately execute the end times of long-term leave, secondment, and other plans, without requiring administrators to set reminders in the calendar and perform manual operations. Therefore, this embodiment effectively improves the real-time availability and data accuracy of the entire resource pool without increasing any human resource investment, and further enhances the robustness of the entire resource allocation method.

[0056] Example 5 This embodiment, based on the "triggering a reallocation operation based on the allocation feedback result to obtain the final allocation scheme" described in step S140 of embodiment 1, further elaborates on the internal logic of hierarchical reallocation and the data recording mechanism of end-to-end auditing. This embodiment works in conjunction with the state snapshot and mutual exclusion control described in embodiment 3. When the allocation feedback result is rejection or timeout failure triggers reallocation, the system combines the state snapshot or the latest state data to reselect. During this process, the hierarchical decision-making and log recording described in this embodiment are executed simultaneously.

[0057] In step S140, a reallocation operation is triggered based on the allocation feedback result, which can be broken down into the following two-level progressive processing path. When the allocation feedback result is rejection or no response after timeout, the system triggers the first-level automatic reallocation operation, excluding the corresponding resource node from the candidate resource pool and reselecting a substitute resource node from the remaining resource nodes. Here, an allocation feedback result of rejection means that the target resource node actively responds by not accepting the allocation after receiving the allocation instruction, such as a review expert clicking the "reject" button after logging into the system and receiving a review invitation. An allocation feedback result of no response after timeout means that the target resource node neither accepts nor rejects within the preset response waiting time. The system determines that the node has made a silent response to this allocation instruction, causing the process to be unable to continue, such as an expert not logging into the system to process the invitation notification within 48 hours. Whether it is rejection or no response after timeout, the system uniformly identifies it as an event of "this allocation failed for this node" and triggers the first-level automatic reallocation. In the initial phase of this level of reallocation, the system first excludes the target resource node that caused the aforementioned failure event from the candidate resource pool of the current allocation execution cycle. This means that it will not be considered for re-issuing allocation instructions in the subsequent processing of this allocation task. Subsequently, based on the candidate resource pool after excluding the node, the system re-executes the comprehensive matching index calculation in step S120 (or directly reuses the index results of nodes that were previously calculated but not selected as targets in the initial selection; the specific implementation can be configured according to real-time requirements). From the remaining candidate resource nodes, a new substitute resource node is selected in descending order of the comprehensive matching index, and an allocation instruction is sent to the substitute node. Through this automatic exclusion and reselection mechanism, the system can replace a single failed node without manual intervention, thus ensuring the self-healing capability of the allocation process in the face of occasional rejections or timeouts.

[0058] When the first-level automatic reallocation operation is triggered, the system synchronously increments the reallocation attempt counter and checks whether the incremented value has reached the preset upper limit. The reallocation attempt counter is an accumulator variable used to track the number of reallocations performed on the same target task within the current allocation execution cycle. This counter is initialized to zero at the start of each allocation execution cycle, and its value increments by 1 each time the first-level automatic reallocation is triggered. The preset upper limit is a threshold parameter that can be configured by administrators. Its purpose is to set a reasonable boundary for the number of attempts for automatic reallocation, for example, the default configuration is 3 attempts. When the incremented counter value has not yet reached the preset upper limit, the system continues to execute the first-level automatic reallocation process described above, reselecting a substitute resource node and sending an allocation command. When the incremented counter value has reached the preset upper limit, the system determines that continuing to perform automatic reallocation without restriction can no longer guarantee efficiency, possibly indicating that the remaining available resource nodes in the current candidate pool are generally no longer suitable, or that the qualified resource nodes have indeed been exhausted. At this point, the system no longer triggers a new first-level automatic reallocation, but instead triggers the second-level manual fallback operation. In addition to the trigger condition of the counter reaching its limit, the system also directly triggers a second-level manual fallback operation when the number of available resource nodes in the candidate resource pool is insufficient to meet the needs of the target task. This is because if the total number of remaining available resource nodes is less than the number of nodes still needing to be allocated, continuing to perform automatic reallocation is mathematically impossible to succeed, and switching to manual processing is the only reasonable path.

[0059] When the second-level manual fallback operation is triggered, the system transfers the target task to the unsuccessful allocation list and provides a manual allocation interface to receive manual intervention instructions. The unsuccessful allocation list is a dedicated page maintained by the system that displays a collection of tasks that failed to complete their target tasks through automatic allocation. It is typically presented on the administrator's terminal in the form of a paginated table or list view. Each record in the list corresponds to a target task that failed to be automatically allocated, and the information displayed may include, but is not limited to: task name or unique identifier, number of required resource nodes, number of currently successfully allocated nodes, reason for failure (e.g., "Automatic reallocation attempts have reached the maximum of 3," "Insufficient number of available experts in the candidate resource pool," etc.), and the time it entered the unsuccessful list. When browsing this list, administrators can clearly see which tasks require manual intervention and the brief reasons for automatic allocation failure, thus allowing them to rationally prioritize processing. The manual allocation interface is an interactive operating environment provided by the system, allowing administrators to access the manual allocation process for specific target tasks. In this interface, the system displays a complete list of resource nodes (not limited to the candidate resource pool filtered by status in automatic allocation, but also including resource nodes in a busy or suspended state, allowing administrators to make flexible decisions based on actual conditions), and supports searching, filtering, and sorting by various attributes of resource nodes. After administrators select target resource nodes and confirm, the system sends allocation instructions to the selected resource nodes and marks this allocation operation as "manual fallback allocation". The presentation form of the manual allocation operation interface is not limited to a graphical visual interface; in some implementations, the interface can also be a command-line interactive terminal, a voice command interface, or a structured manual intervention message received through an application programming interface (API), as long as it allows administrators to manually specify and confirm the allocation results. This embodiment constructs a complete allocation closed loop through a two-level progressive processing architecture of first-level automatic reallocation and second-level manual fallback: in common abnormal situations (individual resource nodes rejecting or timeout), the system automatically completes the repair without consuming human resources; only in extreme abnormal situations (candidate pool exhaustion or reallocation reaching the limit) is it transferred to manual processing, ensuring that the task is never shelved due to the blockage of the automated process. This design, which smoothly transitions from automation to manual operation, substantially improves the robustness of the entire resource allocation system compared to solutions that rely solely on automation or solely on manual operation.

[0060] Throughout the entire allocation process, the system records audit log data in a structured manner. This audit log data includes rule version information, the calculation basis for the comprehensive matching index, a list of candidate resource nodes and their sorting results, the final allocation scheme, and operator information. Based on the task identifier of the target task, one-click traceability and querying of the audit log data is supported. The following describes in detail the structured recording method and content of the audit log data at each stage, following the actual execution timeline of the allocation operation. When the allocation process starts and the currently effective rule set is loaded, the system reads the version identifiers and all parameter values ​​of each rule used in this allocation from the rule configuration module. This includes, but is not limited to: the specific values ​​of the matching weight coefficient, load factor weight coefficient, and availability factor weight coefficient in the preset weight strategy; the calculation method of the load factor or the preset load threshold; the preset upper limit number of automatic reallocations; and the response waiting time. This information, along with the rule version number, is written as "rule version information" to the corresponding field of an audit log record. This ensures that subsequent traceability can clearly identify under which set of rule parameters the decision was made, avoiding the inability to reconstruct the decision basis at a specific point in time due to online rule iteration. After the comprehensive matching index calculation is completed in step S120, the system writes the key intermediate data and final results of the calculation process into the audit log. Specifically, the calculation basis of the comprehensive matching index includes: the unique identifier of each candidate resource node, the comparison details of its static attribute labels with the target task requirement features (e.g., the values ​​of each element in the feature vector obtained by three-level quantization assignment, the name of the optimal pooling strategy used, such as "max pooling" or "average pooling", and the final matching scalar value), the original value of its real-time load data and the load factor calculated accordingly, its current availability status and corresponding availability factor, and the comprehensive matching index score obtained by weighted summation of the three factors. At the same time, the system also records the candidate resource node list and sorting results, that is, a complete list after sorting all candidate resource nodes according to their comprehensive matching index from high to low, including the factor scores and total score of each node. The purpose of this part of the log is to completely preserve the evidence chain of allocation and sorting, making the quantitative basis for why one resource node was selected and why another resource node was not selected clearly visible. When the allocation operation is performed in step S140 and the final allocation scheme is obtained, the system records all the constituent information of the final allocation scheme, namely, the list of resource nodes that were finally selected as targets and successfully allocated (accepted), the allocation time of each node, the channel through which the allocation instruction was sent, and the sending status. If the first-level automatic reallocation was triggered during the allocation process, the log also needs to record the triggering reason (rejection or timeout) for each reallocation, the reallocation attempt counter value at the time of triggering, the identifier of the excluded node, and the identifier of the newly selected substitute node.For target tasks that fail to complete automatically and are transferred to the second-level manual fallback, the system, in addition to recording the complete logs of the automatic phase, must also supplement the recording of operator information after the manual fallback is completed. This includes the administrator account that performed the manual allocation, the operation time, and the final resource node list selected in the manual allocation interface, thus bringing the manual intervention part into a unified audit track. In the final stage of the allocation process, the system aggregates and persistently stores all scattered log data according to the task identifier of the target task. The task identifier is a unique code or ID that identifies the target task within the system, which can be a project number, application number, or a UUID automatically generated by the system. Using this task identifier, when managers or auditors need to retrospectively review a certain allocation decision, they can enter the identifier in the query interface provided by the system, and the system will retrieve and present all audit log data related to the task with one click, reconstructing the complete decision-making chain from rule loading, matching degree calculation, sorting and selection, allocation and sending, reallocation triggering, to the final solution determination along the timeline. The structured storage format for audit log data can be a normalized table structure in a relational database, a JSON document in a document-oriented database, or both formats to accommodate different query needs. The log retention period can be flexibly set according to compliance requirements; for example, in the power industry, a minimum retention period of 6 years is typically required.

[0061] Through the audit log recording and one-click traceability mechanism described in this embodiment, each resource allocation operation forms a complete and quantifiable chain of evidence from input parameters to output results. This fundamentally compensates for the shortcomings of traditional manual allocation methods, where the basis for allocation decisions is difficult to find and cannot be verified. This makes the technical solution of this application show significant advantages in meeting the traceability needs of internal management audits, external regulatory compliance, and review impartiality challenges. At the same time, since the log recording and the update of the reallocation counter occur synchronously in the process, the two logical links are naturally coupled. The records of the number of reallocations and the triggering reasons in the audit log provide auditable proof of the counter's behavior, while the threshold determination of the counter directly drives the records of hierarchical processing paths in the log. This close collaboration enables the entire allocation feedback processing process to have both automatic closed-loop execution capability and complete self-proof capability.

[0062] Example 6 This embodiment, based on the step S140 of embodiment 1, which describes "selecting target resource nodes from the candidate resource pool and performing allocation operations based on comprehensive matching degree indicators and status snapshots", further elaborates on how to introduce and enforce preset hard constraints during the selection process, so that the final recommended list can maintain the overall matching degree level to the maximum extent while meeting the mandatory requirements.

[0063] In step S140, the step of selecting target resource nodes from the candidate resource pool based on the comprehensive matching degree index and the status snapshot for allocation operation can be specifically implemented as a selection logic that includes hard constraint checks and corrections. First, the system generates an initial recommendation list based on the comprehensive matching degree index. The initial recommendation list can be generated as follows: calculate the comprehensive matching degree index score of each resource node in the candidate resource pool as described in Example 2, then sort them in descending order of score, and take the top N resource nodes to form the initial recommendation list, where N is the number of resource nodes required by the target task. At this time, the initial recommendation list reflects the top N node combinations that the system considers to have the best comprehensive conditions under a pure weighted fusion scoring system. However, in actual business scenarios, relying solely on the value of the comprehensive matching degree index for selection sometimes cannot meet some mandatory or policy requirements. Therefore, it is also necessary to introduce hard constraints to verify the compliance of the initial recommendation list.

[0064] Next, the system checks whether the initial recommendation list meets the preset hard constraints. Hard constraints are mandatory screening rules, distinct from numerical scoring and ranking rules. Their judgment is binary: either satisfied or not satisfied, with no intermediate state. They typically originate from business regulations, management rules, or review standards, such as "each review group must include at least one expert from an external unit," "must include at least one member with a senior professional title," or "must include a representative of a specific professional field." The specific content of hard constraints can be pre-set by administrators through the rule configuration module, or different sets of constraint rules can be configured for different types of tasks. During the check, the system iterates through all currently configured and effective hard constraints, verifying the attribute information of each resource node in the initial recommendation list. For example, for the constraint "must include at least one expert from an external unit," the system checks the affiliated unit attribute of all nodes in the initial recommendation list to determine if there is at least one node whose unit type is "external unit." If so, the constraint is marked as satisfied; if not, it is marked as unsatisfied. When all hard constraints are marked as satisfied, the initial recommendation list passes the check and can be directly used as the final recommendation list in the subsequent allocation instruction sending stage.

[0065] If the check finds any unmet hard constraints, the system initiates an iterative correction process: from the resource nodes in the candidate resource pool that were not selected into the initial recommendation list, the system selects the resource node that meets the hard constraints and has the highest comprehensive matching score, replacing the resource node with the lowest comprehensive matching score in the initial recommendation list. This replacement operation is repeated until all hard constraints are met, resulting in a final recommendation list for allocation. The specific logic of this iterative correction process can be described as follows: The system defines two subsets in the candidate resource pool: set A (the N nodes in the initial recommendation list) and set B (all other remaining nodes in the candidate resource pool). For a hard constraint that is not yet met, the system iterates through set B, selecting all nodes that meet the constraint and sorting them from highest to lowest based on their comprehensive matching score. Simultaneously, the system identifies the node with the lowest comprehensive matching score in set A; this node is called the "replacement candidate" for this round of replacement. Then, the system replaces the lowest-scoring node in set A with the highest-scoring node from set B that satisfies the constraints, completing one round of replacement. After the replacement, the composition of the recommendation list corresponding to set A changes, and the system re-executes a complete check of the hard constraints to determine whether all constraints have been satisfied. If there are still unsatisfied constraints, the replacement process is repeated until all hard constraints are satisfied. This cyclical mechanism of "finding unsatisfied constraints → finding the highest-scoring unselected node that satisfies the constraints → replacing the lowest-scoring node in the current list → re-checking" ensures that the correction process satisfies the hard constraints at the cost of minimal matching degree loss, without falling into an infinite loop. This is because each replacement introduces a new node from set B that satisfies the constraints, and the replaced node can no longer satisfy the missing constraint. The overall iterative direction gradually approaches the constraint-satisfied state. In extreme cases, if there are no nodes in set B that can satisfy a certain unmet hard constraint, it means that the constraint cannot be achieved within the current candidate resource pool. The system can record this situation in the audit log and send a prompt to the administrator, who can then decide whether to relax the constraint, expand the candidate resource pool, or directly switch to the manual fallback process.

[0066] To illustrate the iterative correction process more intuitively, a case study with specific matching scores is provided below. Assume a target task requires selecting 3 resource nodes from a candidate resource pool, with a pre-defined hard constraint that "at least one resource node of type A must be included." The candidate resource pool contains 6 available resource nodes. After calculating the comprehensive matching score, the scores and type attributes of each node are as follows (for ease of description, they are listed below in the form of node identifier plus score plus type): Node 1 score 0.92, type B; Node 2 score 0.88, type B; Node 3 score 0.85, type B; Node 4 score 0.80, type A; Node 5 score 0.76, type A; Node 6 score 0.71, type B.

[0067] The system first generates an initial recommendation list by selecting the top 3 nodes based on their scores, from highest to lowest: [Node 1 (0.92, B), Node 2 (0.88, B), Node 3 (0.85, B)]. Checking the hard constraint "must contain at least one resource node of type A," it finds that all three nodes in the list are of type B, none meeting the requirement of type A, thus the constraint is not satisfied. The system initiates iterative correction. In the set of B nodes not selected for the initial recommendation list, namely [Node 4 (0.80, A), Node 5 (0.76, A), Node 6 (0.71, B)], nodes of type A are selected: Node 4 and Node 5, with the higher score being Node 4 (0.80). In the current set of A nodes, i.e., the initial recommendation list, the node with the lowest score is Node 3 (0.85). The system replaces Node 3 with Node 4, and the resulting recommendation list becomes [Node 1 (0.92, B), Node 2 (0.88, B), Node 4 (0.80, A)]. At this point, the hard constraints are re-examined, and it is found that the list already contains a node of type A (node ​​4). The constraints are satisfied, the iteration correction ends, and the list becomes the final recommended list. Based on this, the system sends allocation instructions to node 1, node 2, and node 4.

[0068] Suppose that in the above example, there is more than one hard constraint, such as simultaneously requiring "at least one resource node of type A" and "at least one resource node of type C". After each round of replacement, the system will re-examine all constraints. If any constraints remain unmet, the system will continue to replace them in the next round. For example, if the list still does not contain a node of type C after the initial replacement, the system will search for the node of type C with the highest score in set B to replace the lowest-scoring non-C type node in the current list, repeating this process until all constraints are satisfied.

[0069] This embodiment addresses the issue of recommended lists failing to meet mandatory business rules when relying solely on weighted scoring, by introducing a check and iterative correction mechanism with hard constraints based on the overall matching index ranking. The beneficial effect of this mechanism is that it achieves a controllable balance between maximizing the overall matching index and meeting the compliance requirement of hard constraints. The iterative replacement strategy replaces only the lowest-scoring node in the current list each time, preserving the positions of existing high-scoring nodes to the greatest extent possible, thus ensuring that the corrected recommended list still maintains the highest possible overall matching level. Furthermore, because the correction process is deterministic and based on clearly defined rules, each decision can be recorded in the audit log, facilitating post-event tracing of the complete decision-making logic regarding "why a node was replaced" and "why a node was retained," ensuring full transparency and explainability of the entire allocation process during compliance reviews.

[0070] Example 7 like Figure 3 As shown, this embodiment provides a resource allocation system 200 based on multi-dimensional features and state coordination. The system is used to implement the resource allocation method based on multi-dimensional features and state coordination described in any of the foregoing embodiments, and includes: a data acquisition module 210, a comprehensive matching degree calculation module 220, a state coordination control module 230, and an allocation execution and reallocation module 240.

[0071] The data acquisition module 210 is used to acquire the requirements characteristics of the target task, as well as the static attribute labels, real-time load data, and current availability status of each resource node in the candidate resource pool. This module serves as the interface layer between the system and external data sources. In actual deployment, the data acquisition module can retrieve static attribute labels and real-time load data of resource nodes in batches from the enterprise's internal expert information management system, equipment operation monitoring system, customer service scheduling system, or other business databases through standardized application programming interfaces or database queries. Simultaneously, it reads the current availability status of each resource node from the status management service. The data acquisition module performs format validation and normalization preprocessing on the three types of data acquired to ensure that the data received by the subsequent calculation module has a consistent structure and integrity. For example, it maps status strings from different sources to the system's internal status code, fills missing load data fields with default values, and then passes the preprocessed data to the comprehensive matching degree calculation module and the status collaborative control module, respectively.

[0072] The comprehensive matching degree calculation module 220 is used to determine the matching degree of static attribute tags, the load factor corresponding to real-time load data, and the availability factor corresponding to the current available state based on a preset weight strategy. It then performs a fusion calculation on the matching degree, load factor, and availability factor to obtain the comprehensive matching degree index for each resource node. This module is the core algorithm component of the system. It receives the multi-dimensional raw data output by the data acquisition module and executes the calculation process described in detail in Example 2, including generating feature vectors through three-level quantization assignment, adaptively selecting max pooling or average pooling strategies for feature compression, calculating the load factor based on the ratio of real-time load data to a preset load threshold, determining the availability factor based on state category mapping, and performing weighted summation according to preset weight coefficients. The output of the comprehensive matching degree calculation module is a scalar list of comprehensive matching degree indices. Each resource node in the list corresponds to a comprehensive matching degree index score. This list is sorted in descending order of score and then passed to the allocation execution and reallocation module.

[0073] The state coordination control module 230 is used to generate a state snapshot of the candidate resource pool within a preset allocation execution cycle and to execute state change mutual exclusion control. This module is connected to the data acquisition module. After obtaining the current available state of each resource node from the data acquisition module, it creates a copy of the instantaneous state data as a state snapshot when the allocation operation starts, and sets an expiration date for this snapshot. Within the allocation execution cycle, the state coordination control module is also responsible for listening to external state change commands and executing mutual exclusion control according to the "no change in this round, effective in the next round" strategy described in Example 3. That is, it maintains the allocation command issued in the current round without retraction and continues to track and respond, while retaining the state change information until the next allocation round. The state coordination control module transmits the generated state snapshot and the output of the mutual exclusion control logic (e.g., providing the latest updated state data when a reallocation is triggered) in parallel to the allocation execution and reallocation modules, enabling these modules to have a consistent decision-making basis when selecting target resource nodes and to obtain updated state information in reallocation scenarios.

[0074] The allocation execution and reallocation module 240 is used to select target resource nodes from the candidate resource pool based on the comprehensive matching degree index and state snapshot, perform allocation operations, obtain allocation feedback results, and trigger reallocation operations based on the allocation feedback results to obtain the final allocation scheme. This module is the system's decision execution and closed-loop control component. Its input end simultaneously receives a comprehensive matching degree index list from the comprehensive matching degree calculation module and state snapshot information from the state coordination control module. After both are input in parallel, the selection logic inside the module determines the target resource node list based on the comprehensive matching degree index from high to low and combines it with the availability benchmark recorded in the state snapshot, and performs allocation operations (e.g., sending task allocation instructions or invitation notifications to the selected resource nodes). After the allocation operation is executed, the module continuously tracks the response status of the target resource nodes and collects allocation feedback results. When the feedback results trigger the reallocation condition, the module excludes failed nodes from the candidate resource pool, interacts with the state coordination control module to obtain the latest state data or state snapshot required for reallocation, drives the comprehensive matching degree calculation module to generate new recommended nodes, and performs allocation again. This cycle continues until the final allocation scheme is formed. This module also undertakes the hierarchical processing logic described in Example 5. When the number of attempts for automatic reallocation at the first level reaches the preset limit or there are not enough available nodes in the candidate resource pool, the target task will be transferred to the manual fallback operation interface.

[0075] In the collaborative relationship of the above four modules, the data flow path can be summarized as follows: the data acquisition module acts as the data entry point, sending multi-dimensional raw data to the comprehensive matching degree calculation module and the state coordination control module respectively; the comprehensive matching degree calculation module sends the calculated comprehensive matching degree index to the allocation execution and reallocation module; the state coordination control module sends the state snapshot and mutual exclusion control results to the allocation execution and reallocation module; the allocation execution and reallocation module acts as the output endpoint of the system, sending allocation instructions and receiving feedback, and simultaneously driving the comprehensive matching degree calculation module to recalculate when reallocation is required. These four functional modules can be physically deployed on the same server or distributed across different computing nodes. For example, the comprehensive matching degree calculation module can be deployed on a server with high-performance computing resources to meet the real-time computing needs of a large-scale candidate pool; the data acquisition module and the state coordination control module can be deployed on edge nodes close to the data source to reduce data transmission latency; and the allocation execution and reallocation module can be deployed on a user-facing business application server to directly receive manual fallback operation instructions from the administrator. The modules communicate and exchange data through an internal network or message middleware. This embodiment does not limit the specific deployment topology.

[0076] This embodiment constructs an engineered system architecture by mapping the four core steps of the method to functionally independent modules. The data acquisition module, comprehensive matching degree calculation module, state coordination control module, and allocation execution and reallocation module each assume clearly defined responsibilities and collaborate decoupled through standardized data interfaces. This ensures the system has good scalability and maintainability. For example, when introducing a new dimension for matching degree calculation, only the internal algorithm of the comprehensive matching degree calculation module needs to be upgraded without modifying the interface logic of other modules. When adapting to the state management rules of different types of resource nodes, only the configuration parameters of the state coordination control module need to be adjusted. Simultaneously, the design of parallel input of the comprehensive matching degree index and state snapshots into the allocation execution and reallocation module ensures that the allocation decision has both a quantified matching degree ranking basis and consistent state baseline data at the same time. The synergistic effect of these two ensures that the allocation result simultaneously considers both optimality and availability, avoiding decision biases caused by lagging state data or sequential execution of matching calculation and state filtering in traditional systems.

[0077] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any equivalent substitutions or partial improvements made by those skilled in the art to the resource allocation process, multi-dimensional feature fusion calculation method, state collaborative control strategy, hierarchical redistribution mechanism, or system module division based on the inventive concept of this application within the technical scope disclosed in this application, such as adjusting the assignment method of weight coefficients, changing the storage format of state snapshots, replacing the manual fallback operation interface with a voice command interface, or reordering the method steps, as long as they do not depart from the spirit and principle of the technical solution of this application, should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of protection of the claims.

Claims

1. A resource allocation method based on multidimensional features and state coordination, characterized in that, include: Obtain the requirements of the target task, as well as the static attribute labels, real-time load data and current availability status of each resource node in the candidate resource pool; Based on a preset weighting strategy, the matching degree of the static attribute tags, the load factor corresponding to the real-time load data, and the availability factor corresponding to the current availability status are determined. The matching degree, the load factor, and the availability factor are then fused and calculated to obtain a comprehensive matching degree index for each resource node. Within a preset allocation execution cycle, a state snapshot of the candidate resource pool is generated, and state change mutual exclusion control is executed. Based on the comprehensive matching index and the state snapshot, target resource nodes are selected from the candidate resource pool to perform allocation operations, allocation feedback results are obtained, and a reallocation operation is triggered based on the allocation feedback results to obtain the final allocation scheme.

2. The resource allocation method based on multi-dimensional features and state coordination according to claim 1, characterized in that, The fusion calculation of the matching degree, the load factor, and the availability factor includes: The matching degree is determined based on the comparison results between the demand characteristics and the static attribute tags; The load factor is determined based on the ratio between the real-time load data and the preset load threshold. The availability factor is determined based on the state category to which the current available state belongs; The matching degree, the load factor, and the availability factor are weighted and summed according to the preset weighting strategy to obtain the comprehensive matching degree index.

3. The resource allocation method based on multi-dimensional features and state coordination according to claim 2, characterized in that, Determining the matching degree based on the comparison results between the demand features and the static attribute tags includes: The first set of labels contained in the demand features is compared with the second set of labels contained in the static attribute labels by performing a Cartesian product comparison to generate a feature vector containing multiple matching elements; wherein, the value of the matching element is assigned a three-level quantization based on complete matching, partial matching or no matching; Based on the type of the target task, the optimal pooling strategy is adaptively selected from a preset strategy library; wherein, the strategy library includes a max pooling strategy and an average pooling strategy. The feature vector is compressed based on the optimal pooling strategy to obtain the matching degree in scalar form.

4. The resource allocation method based on multi-dimensional features and state coordination according to claim 1, characterized in that, The step of generating a state snapshot of the candidate resource pool within a preset allocation execution cycle and executing state change mutual exclusion control includes: When the allocation operation is initiated, a snapshot of the current state is created, and the validity period of the snapshot is set. When a state change instruction for the target resource node is received during the allocation execution cycle, the state change mutual exclusion control is executed, and the state change instruction is applied to the next round of allocation operation.

5. The resource allocation method based on multidimensional features and state coordination according to claim 4, characterized in that, The execution of the state change mutual exclusion control and the application of the state change instruction to the next round of allocation operations include: In the current allocation round, the issued allocation instructions are not withdrawn, and the corresponding response tracking continues to be executed; When the allocation feedback result triggers the reallocation operation, the state snapshot or the latest state data is reread; If the current available state of the target resource node has been updated based on the state change instruction, then the target resource node is processed according to the updated latest state data in the reallocation operation.

6. The resource allocation method based on multi-dimensional features and state coordination according to claim 1, characterized in that, Also includes: An automatic transition operation is performed on the current availability status of the resource node based on a preset time-triggered condition; wherein the automatic transition operation includes: In response to receiving a status setting command, the system records the status change timestamp and starts a timer. When the timer reaches a preset duration, the system automatically restores the currently available status to the idle status. Upon receiving and approving a status suspension request, the system records the suspension end time. When the suspension end time is reached, the system automatically restores the current available status to the idle status.

7. The resource allocation method based on multidimensional features and state coordination according to claim 1, characterized in that, The triggering of the reallocation operation based on the allocation feedback result includes: When the allocation feedback result is rejection or no response after timeout, the first-level automatic reallocation operation is triggered, the corresponding resource node is excluded from the candidate resource pool, and a substitute resource node is selected from the remaining resource nodes. When the number of times the first-level automatic reallocation operation is executed reaches the preset limit, or when the number of available resource nodes in the candidate resource pool does not meet the requirements of the target task, the second-level manual fallback operation is triggered, the target task is transferred to the allocation failure list, and a manual allocation operation interface is provided to receive manual intervention instructions.

8. The resource allocation method based on multidimensional features and state coordination according to claim 7, characterized in that, Also includes: When the first-level automatic reallocation operation is triggered, the reallocation attempt counter is incremented, and it is determined whether the incremented value has reached the preset upper limit. Throughout the entire execution chain of the allocation operation, audit log data is recorded in a structured manner; wherein, the audit log data includes rule version information, the calculation basis of the comprehensive matching degree index, the candidate resource node list and sorting results, the final allocation scheme, and operator information; Based on the task identifier of the target task, one-click traceability query of the audit log data is supported.

9. The resource allocation method based on multidimensional features and state coordination according to claim 1, characterized in that, The step of selecting a target resource node from the candidate resource pool and performing an allocation operation based on the comprehensive matching index and the status snapshot includes: An initial recommendation list is generated based on the comprehensive matching index; Check whether the initial recommendation list meets the preset hard constraints; If the conditions are not met, then from the resource nodes in the candidate resource pool that were not selected into the initial recommendation list, select the resource node that meets the hard constraints and has the highest comprehensive matching index, and replace the resource node with the lowest comprehensive matching index in the initial recommendation list. Repeat the replacement operation until all the hard constraints are met, and obtain the final recommendation list to perform the allocation operation.

10. A resource allocation system based on multidimensional features and state coordination, used to implement the resource allocation method based on multidimensional features and state coordination as described in any one of claims 1 to 9, characterized in that, include: The data acquisition module is used to acquire the requirements of the target task, as well as the static attribute labels, real-time load data and current availability status of each resource node in the candidate resource pool; The comprehensive matching degree calculation module is used to determine the matching degree of the static attribute tag, the load factor corresponding to the real-time load data, and the availability factor corresponding to the current availability status based on a preset weight strategy, and to perform a fusion calculation on the matching degree, the load factor, and the availability factor to obtain the comprehensive matching degree index of each resource node. The state coordination control module is used to generate a state snapshot of the candidate resource pool within a preset allocation execution cycle and to perform state change mutual exclusion control. The allocation execution and reallocation module is used to select target resource nodes from the candidate resource pool based on the comprehensive matching degree index and the status snapshot, perform allocation operations, obtain allocation feedback results, and trigger reallocation operations based on the allocation feedback results to obtain the final allocation scheme.

Images