Seat resource scheduling method and device, equipment and storage medium

Abstract

The application discloses a method and device for scheduling a seat resource, an equipment and a storage medium, relates to the technical field of resource scheduling, and comprises the following steps: hot spot identification is performed on multi-dimensional operation data to obtain hot spot data of the multi-dimensional operation data; a dynamic programming algorithm is used to split a seat resource scheduling decision task into a plurality of subtask packages which are executed in parallel, and a scheduling decision path is determined; scheduling is performed based on the hot spot data and the scheduling decision path to obtain real evaluation data; and the real evaluation data and expected evaluation data are compared and analyzed to obtain comparison and analysis results. Through hot spot identification and dynamic programming parallel decomposition, the application obtains the processing of subtasks, improves the speed of data query and resource scheduling, and improves the efficiency of seat resource scheduling.

Description

Technical Field

[0001] This application relates to the field of resource scheduling technology, and in particular to seat resource scheduling methods, apparatus, equipment and storage media. Background Technology

[0002] As remote banking services continue to expand, the efficiency of agent resource allocation directly impacts operating costs and customer service quality. Currently, the industry commonly employs a manual scheduling model for agent resource management. Operations personnel must monitor and comprehensively assess multi-dimensional data, including call volume, queue status, agent shifts, professional skills, online and training status, and manually adjust agent allocation across skill queues based on personal experience and pre-defined rules. However, this experience-dependent scheduling method suffers from significant decision-making lag. Due to the multi-dimensional and rapidly changing data, operations personnel typically require several minutes or even longer from identifying problems and analyzing data to making adjustment decisions, with a response delay of approximately 10 minutes. In the face of sudden call surges, this lag prevents agents from being allocated to high-load queues in a timely manner, resulting in longer customer wait times, lower connection rates, and difficulty meeting the real-time requirements of dynamic business changes.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, device, and storage medium for scheduling seat resources, aiming to solve the technical problem of low efficiency in scheduling seat resources.

[0005] To achieve the above objectives, this application proposes a seat resource scheduling method, the method comprising: Hotspot identification is performed on the multidimensional operational data to obtain the hotspot data of the multidimensional operational data; The task of scheduling agent resources is divided into several parallel sub-task packages based on the dynamic programming algorithm to determine the scheduling decision path. Scheduling is performed based on the hotspot data and the scheduling decision path to obtain accurate evaluation data; The actual evaluation data and the expected evaluation data are compared and analyzed to obtain the comparison and analysis results.

[0006] In one embodiment, the step of identifying hotspots in the multidimensional operational data to obtain hotspot data of the multidimensional operational data includes: Build a Zookeeper service and listen for data change commands through the Zookeeper service. The data change commands include service start commands and hotspot refresh commands. When the Zookeeper service listens for the service startup command, it identifies hot data from the multi-dimensional operational data based on preset hotspot rules; When the Zookeeper service detects the hotspot refresh command, it refreshes the hotspot data to obtain the refreshed hotspot data.

[0007] In one embodiment, the step of dividing the seat resource scheduling decision task into several parallel-executed sub-task packages based on the dynamic programming algorithm and determining the scheduling decision path includes: The seat resource scheduling decision task is divided into several sub-tasks according to a preset rule group, and each sub-task is encapsulated into a sub-task package; The sub-task packages are executed in parallel using the target framework to obtain the execution results of the sub-task packages; The execution results are recursively combined based on the logical relationships between the preset rule groups to generate the scheduling decision path.

[0008] In one embodiment, the step of dividing the seat resource scheduling decision task into several parallel-executed sub-task packages based on the dynamic programming algorithm and determining the scheduling decision path further includes: When the scheduling decision path indicates that skill adjustments are needed for the target agent, the adjustment status of the target agent is queried through a Bloom filter; If the query result of the Bloom filter indicates that the target agent is in a cooling state, then the current skill adjustment for the target agent is abandoned. If the query result of the Bloom filter indicates that the target agent is not in a cooling state, then it is determined to perform a current skill adjustment for the target agent, and the identifier of the target agent is written into the Bloom filter to start the cooling timer.

[0009] In one embodiment, the step of scheduling based on the hotspot data and the scheduling decision path to obtain the actual evaluation data includes: The target agent and target skill to be scheduled are determined based on the aforementioned scheduling decision path; Read the real-time status information of the target agent from the hotspot data to verify whether the target agent meets the scheduling execution conditions; If the target agent meets the scheduling execution conditions, the target agent will be assigned to the queue corresponding to the target skill for scheduling execution, thereby obtaining the actual evaluation data.

[0010] In one embodiment, before the step of comparing and analyzing the actual evaluation data and the expected evaluation data to obtain the comparison analysis results, the method further includes: Construct an autoregressive integral moving average time series prediction model; The autoregressive integral moving average time series prediction model is used to fit and predict historical operating data and multidimensional operating data to generate expected evaluation data within future time windows.

[0011] In one embodiment, the step of comparing and analyzing the actual evaluation data and the expected evaluation data to obtain the comparison analysis results includes: The target deviation value is calculated by comparing the actual evaluation data within the preset time window after the scheduling is executed with the corresponding target value in the expected evaluation data. The target deviation value is compared with a preset deviation threshold to generate the comparison analysis result.

[0012] Furthermore, to achieve the above objectives, this application also proposes a seat resource scheduling device, which includes: The hotspot identification module is used to identify hotspots in multidimensional operational data to obtain hotspot data from the multidimensional operational data. The scheduling determination module is used to break down the seat resource scheduling decision task into several parallel sub-task packages based on the dynamic programming algorithm, and determine the scheduling decision path. The scheduling execution module is used to perform scheduling based on the hotspot data and the scheduling decision path to obtain real evaluation data; The comparison and analysis module is used to compare and analyze the actual evaluation data and the expected evaluation data to obtain the comparison and analysis results.

[0013] In addition, to achieve the above objectives, this application also proposes a seat resource scheduling device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the seat resource scheduling method as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the seat resource scheduling method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the seat resource scheduling method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application proposes a method, apparatus, device, and storage medium for agent resource scheduling. It identifies hotspots in multi-dimensional operational data to obtain hotspot data; it decomposes the agent resource scheduling decision task into several parallel sub-task packages based on a dynamic programming algorithm to determine the scheduling decision path; it performs scheduling based on the hotspot data and the scheduling decision path to obtain actual evaluation data; and it compares and analyzes the actual evaluation data with the expected evaluation data to obtain comparison analysis results. This application improves the speed of data querying and resource scheduling, and enhances the efficiency of agent resource scheduling by using hotspot identification and parallel decomposition of sub-tasks through dynamic programming. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating an embodiment of the seat resource scheduling method of this application. Figure 2 A flowchart illustrating the hot data refresh process of the Zookeeper service provided in the embodiment of the seat resource scheduling method of this application; Figure 3 A schematic flowchart illustrating the execution of the seat resource scheduling method provided in this application, which uses a dynamic programming algorithm to determine the scheduling decision path. Figure 4 A flowchart illustrating the verification of the Bloom filter provided for the seat resource scheduling method of this application; Figure 5 This is a schematic diagram of the module structure of the seat resource scheduling device according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the seat resource scheduling method in the embodiments of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution of this application embodiment is: to identify hotspots in multi-dimensional operational data to obtain hotspot data; to divide the seat resource scheduling decision task into several parallel sub-task packages based on a dynamic programming algorithm to determine the scheduling decision path; to perform scheduling based on the hotspot data and the scheduling decision path to obtain real evaluation data; and to compare and analyze the real evaluation data and the expected evaluation data to obtain the comparison and analysis results.

[0024] In this embodiment, for ease of description, the following description will focus on the seat resource scheduling device as the execution subject.

[0025] As remote banking services continue to expand, the efficiency of agent resource allocation directly impacts operating costs and customer service quality. Currently, the industry commonly employs a manual scheduling model for agent resource management. Operations personnel must monitor and comprehensively assess multi-dimensional data, including call volume, queue status, agent shifts, professional skills, online and training status, and manually adjust agent allocation across skill queues based on personal experience and pre-defined rules. However, this experience-dependent scheduling method suffers from significant decision-making lag. Due to the multi-dimensional and rapidly changing data, operations personnel typically require several minutes or even longer from identifying problems and analyzing data to making adjustment decisions, with a response delay of approximately 10 minutes. In the face of sudden call surges, this lag prevents agents from being allocated to high-load queues in a timely manner, resulting in longer customer wait times, lower connection rates, and difficulty meeting the real-time requirements of dynamic business changes.

[0026] This application provides a solution that improves the speed of data query and resource scheduling, and enhances the efficiency of agent resource scheduling by obtaining sub-tasks through hotspot identification and parallel decomposition using dynamic programming.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or a seat resource scheduling system capable of performing the above functions. The following description uses a seat resource scheduling system as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, embodiments of this application provide a seat resource scheduling method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the seat resource scheduling method of this application.

[0029] In this embodiment, the seat resource scheduling method includes steps S11 to S14: Step S11: Hotspot identification is performed on the multidimensional operational data to obtain the hotspot data of the multidimensional operational data.

[0030] It should be noted that multidimensional operational data refers to heterogeneous data from various remote banking business systems, including call detail records (CDRs), voice data, text data, agent skill data, agent real-time status data (online, on call, training, short break, etc.), queue information data, and conversation information data. Hotspot identification is a technical method for filtering out key data subsets with high-frequency queries and high real-time requirements from massive amounts of operational data. This step employs an identification algorithm based on a combination of access frequency statistics and business priority weighting. It automatically marks hotspot data using preset hotspot rules (such as data fields queried more than M times in the last N minutes). Its purpose is to pre-separate the core data required for subsequent scheduling decisions from the full dataset, providing a data foundation for cache loading and fast access.

[0031] Understandably, the purpose of this step is to address the technical problem of low query efficiency caused by massive data volumes in traditional scheduling models. The principle is to divide the entire dataset into hot and non-hot data using identification technology, and only include frequently used hot data in the fast access channel. First, the original multi-dimensional operational data is scanned, and data that is frequently queried is identified according to preset rules. Then, this data is marked and extracted as hot data. After hot data identification, subsequent scheduling decisions do not need to traverse the entire dataset, significantly reducing the data query scope and laying the foundation for improving overall scheduling efficiency.

[0032] Specifically, the system connects to multiple data sources to collect various operational data in real time. It pre-sets hotspot identification rules, such as setting real-time agent status data, current waiting time data for each skill queue, and the current online agent list as default hotspot data. The system calculates the query frequency of each data field according to a time window (e.g., the last 5 minutes) and automatically marks data with a query frequency exceeding a threshold as hotspot data. Furthermore, the system supports manual configuration of hotspot rules, allowing operations personnel to specify specific data as hotspot data based on business characteristics. Multiple implementation methods can be combined; for example, the system can load default hotspot data at startup, dynamically adjust the hotspot data set based on actual query frequency during operation, and accept manual intervention for correction, thereby achieving adaptive optimization.

[0033] For example, in a bank's customer service center, the system collects operational data across 100 dimensions in real time. Through hotspot identification, the system discovered that the three dimensions—the number of currently online agents, skill distribution, queue size, and agent status (idle / on a call)—were queried in every dispatch decision, with a query frequency far exceeding other dimensions. Based on this, the system marked the data in these three dimensions as hotspot data, extracted them, and stored them separately for rapid subsequent retrieval.

[0034] Step S12: Based on the dynamic programming algorithm, the seat resource scheduling decision task is divided into several parallel sub-task packages to determine the scheduling decision path.

[0035] It should be noted that dynamic programming is a mathematical optimization method that decomposes a complex problem into interrelated subproblems and obtains the optimal solution to the original problem by solving the optimal solutions to the subproblems. The agent resource scheduling decision task refers to the complete decision-making process of determining which agent should be assigned which skill and to which queue. A subtask package is an independent computational unit after the original scheduling decision task is decomposed according to the granularity of rule groups; each subtask package corresponds to the index calculation of a rule group. The scheduling decision path refers to a series of decision nodes and selection sequences from the initial state to the final scheduling scheme; it describes which agents were assigned which skills at what time. This step uses dynamic programming combined with the Fork / Join parallel computing framework to recursively decompose the complex scheduling task into parallel executable subtask packages, and recursively combines the computation results of the subtask packages to generate the globally optimal scheduling decision path.

[0036] Understandably, the purpose of this step is to address the technical problem of long computation time and slow response caused by the comprehensive calculation of multi-dimensional data involved in scheduling decisions. The principle is to decompose a large-scale, highly complex scheduling decision task into multiple independent or weakly dependent subtasks according to the natural boundaries of business rules, enabling these subtasks to be executed in parallel, thereby significantly reducing the overall computation time. First, the various rule groups contained in the scheduling decision task are identified, and the index calculation of each rule group is encapsulated into a subtask package. Then, a parallel computing framework is used to execute all subtask packages simultaneously. Finally, the calculation results of each subtask package are recursively combined according to the logical relationships between rule groups (such as AND and OR) to form a complete decision path. Through task decomposition and parallel computing, complex calculations that originally required sequential execution are transformed into parallel execution, significantly improving the decision response speed.

[0037] Specifically, the system first parses all rule groups contained in the scheduling decision task. Each rule group defines specific scheduling conditions and corresponding scheduling actions. The system breaks down the task according to the granularity of the rule groups, encapsulating the condition judgments and index calculations of each rule group into an independent subtask package. The system uses a Fork / Join framework to manage these subtask packages: in the Fork phase, the subtask packages are distributed to multiple computing threads for parallel execution; in the Join phase, all subtask packages are waited for completion, and their execution results are collected (such as whether the conditions are met or not, and the corresponding confidence level). Based on the preset logical relationships between rule groups (e.g., an AND relationship indicates that scheduling is triggered only when all subtask packages are satisfied, or an AND relationship indicates that scheduling is triggered when any subtask package is satisfied), the results are recursively combined to generate the final scheduling decision path. When there are nested relationships between rule groups, the system recursively combines them from the inside out to ensure logical correctness.

[0038] For example, a scheduling decision task includes three rule groups: rule group A determines whether the number of people waiting in the credit card queue exceeds a threshold; rule group B determines whether the number of available seats in the loan queue is insufficient; and rule group C determines whether the current time is during peak business hours. The system encapsulates these three rule groups into three sub-task packages and distributes them to three computing threads for parallel execution. After execution, thread A returns that the number of people waiting exceeds the threshold, thread B returns that there are insufficient available seats, and thread C returns that the period is during peak hours. The system combines the rule groups according to their logical relationships (e.g., scheduling is triggered when A and B are satisfied and C is also satisfied). Since all three conditions are met, the system generates a decision path that schedules agents with both credit card and loan skills from other queues to the credit card queue.

[0039] Step S13: Based on the hotspot data and the scheduling decision path, perform scheduling to obtain the actual evaluation data.

[0040] It should be noted that scheduling refers to the specific execution operation of adjusting agent resources from the current queue or skill configuration to the target skill queue. Real evaluation data refers to the actual operational indicator data reflecting the scheduling effect collected by the system in real time after the scheduling execution is completed. This includes scheduling execution status (success / failure), scheduling execution timestamp, agent status after scheduling, and core indicators such as connection rate and waiting time of related queues before and after scheduling. The core of this step is to use the extracted hotspot data as the input information source for decision execution, use the determined scheduling decision path as the execution instruction, actually execute the agent skill adjustment operation, and collect execution result data in real time during and after execution.

[0041] Understandably, the purpose of this step is to implement the scheduling plan generated in the previous decision-making steps and obtain real execution effect data, providing a data foundation for subsequent comparative analysis. The system identifies the agents and target skills requiring adjustment based on the scheduling decision path, quickly reads the current status of the agent from hotspot data to verify whether the execution conditions are met, and executes the scheduling operation after confirmation. Simultaneously, it records various status data during the scheduling execution process as real evaluation data. Through rapid verification and scheduling execution based on hotspot data, the accurate implementation of scheduling instructions is ensured, and real data usable for effect evaluation is produced, forming a complete closed loop from decision-making to execution.

[0042] Specifically, the scheduling decision path is first analyzed to extract the list of target agent identifiers to be scheduled, the target skills corresponding to each agent, and the queue information to which the target skills belong. Real-time status information for each target agent is read from hotspot data (e.g., whether currently on a call, on a short break, and current continuous working time), and each agent is verified to meet the preconditions for scheduling execution (e.g., the agent must be idle, not in a cooldown period). For agents that meet the conditions, the system calls the agent skill management interface to assign the agent to the queue corresponding to the target skill; for agents that do not meet the conditions, the system skips the scheduling and records the reason for skipping. During scheduling execution, the scheduling execution status (success / failure), scheduling execution timestamp, and changes in agent status after scheduling are recorded in real time, forming a realistic evaluation dataset.

[0043] For example, the scheduling decision path indicates: schedule agent Zhang San from the loan skills queue to the credit card skills queue. Reading Zhang San's real-time status from the hotspot data, it is found that Zhang San is currently idle and has not been scheduled in the last 5 minutes, meeting the execution conditions. The system calls the skills adjustment interface to enable Zhang San's credit card skills and adds him to the credit card skills queue. After successful execution, the system records: scheduling execution status = successful, execution timestamp = 2024-01-15 10:35:22, and Zhang San's status after scheduling = credit card queue waiting. Simultaneously, the system reads the number of people waiting in the credit card queue before and after scheduling from the hotspot data, decreasing from 5 to 4, and records this as actual evaluation data.

[0044] Step S14: Compare and analyze the actual evaluation data and the expected evaluation data to obtain the comparison and analysis results.

[0045] It should be noted that the expected assessment data refers to the target operational indicator values ​​set by the system based on historical data and predictive models before scheduling execution, such as target connection rate, target average waiting time, and target queue length. Comparative analysis compares the actual assessment data collected after scheduling execution with the pre-set expected assessment data, calculates the deviation, and determines whether the deviation is within an acceptable range. The comparative analysis results refer to the output generated by the comparative analysis, including the deviation values ​​of each indicator, whether they exceed the threshold, and the subsequent actions triggered as a result (such as whether to send an alert). This step uses a threshold-based deviation detection method, generating a structured comparative analysis report by comparing the actual values ​​with the expected values ​​item by item.

[0046] Understandably, the purpose of this step is to quantitatively evaluate the actual effectiveness of scheduling decisions and verify whether the scheduling has achieved its expected goals. The collected actual evaluation data is compared item by item with the preset expected evaluation data, and the deviation of each indicator is calculated. The deviation value is then compared with a preset threshold to determine whether the scheduling effect meets the standard. Through comparative analysis, the system can objectively evaluate the effectiveness of each scheduling operation, providing a quantitative basis for subsequent scheduling optimization, early warning triggering, and closed-loop feedback.

[0047] Specifically, key operational metrics (such as connection rate, average waiting time, average queue length, and skill adjustment execution success rate) are extracted from real assessment data, and corresponding target values ​​are read from expected assessment data. A deviation value is calculated for each metric, with the calculation method determined based on the metric type: for ratio-based metrics (such as connection rate), deviation = actual value - target value; for duration-based metrics (such as average waiting time), deviation = actual value - target value, with negative values ​​indicating better performance than the target; for count-based metrics (such as queue length), deviation = actual value - target value. The deviation value for each metric is compared with a preset deviation threshold to determine if it exceeds the threshold. All comparison results are summarized to generate a comparative analysis result including the deviation status (normal / exceeding threshold) of each metric.

[0048] For example, before scheduling execution, the expected evaluation data includes: a target connection rate of ≥85% for the credit card queue and a target average waiting time of ≤30 seconds. After scheduling execution, the collected actual evaluation data shows: connection rate = 88%, average waiting time = 25 seconds. The system compares each item: connection rate deviation = +3%, not exceeding the preset threshold (e.g., -5%); average waiting time deviation = -5 seconds, not exceeding the preset threshold (e.g., +10 seconds). The comparison analysis result is generated: both indicators meet the standards, and the scheduling effect is good. If in another scenario the actual connection rate = 78%, and the deviation = -7%, exceeding the -5% threshold, the comparison analysis result indicates that the connection rate exceeds the standard, requiring a warning.

[0049] This embodiment, through the above-described scheme, simplifies massive, multi-dimensional data into high-frequency, key data through hotspot identification, transforms complex decision-making tasks into efficient, parallel subtask packages through dynamic programming and parallel decomposition, executes scheduling based on hotspot data and decision paths while collecting real data, and finally achieves effect evaluation through comparative analysis. This series of steps forms a complete closed loop from data preprocessing, rapid decision-making, scheduling execution to effect evaluation, effectively solving the technical problems of low data query efficiency, delayed decision response, and lack of quantitative evaluation of scheduling effects in the traditional manual scheduling mode. It improves the efficiency of agent resource scheduling and achieves automated, intelligent, and measurable technical effects in agent resource scheduling.

[0050] Based on the above implementation scheme, in one feasible implementation, the step of identifying hotspots in the multidimensional operational data to obtain hotspot data of the multidimensional operational data includes S21~S23: Step S21: Build a Zookeeper service and listen for data change commands through the Zookeeper service. The data change commands include service start commands and hotspot refresh commands.

[0051] It's important to note that ZooKeeper is an open-source distributed coordination framework used for configuration management and data change notification. Service startup commands are initialization commands triggered when the system first starts or restarts. Data change commands are signals that trigger hot data update operations, including but not limited to service startup commands and hotspot refresh commands. ZooKeeper acts as a listener, continuously monitoring the state changes of specific nodes. Once a command change is detected, it immediately triggers the corresponding callback function.

[0052] Understandably, the purpose of this step is to establish a passive, event-driven data update triggering mechanism to replace the active polling method, thereby reducing the ineffective consumption of system resources. A listener is registered on ZooKeeper to listen for preset command nodes; when the data on that node changes, ZooKeeper actively notifies the system. Through ZooKeeper's event listening mechanism, there is no need to frequently query for update commands; instead, notifications are passively received only when commands are available, significantly reducing system overhead while ensuring real-time command response.

[0053] Specifically, upon system startup, a pre-defined command node is created or connected to on ZooKeeper. A listener is registered on this node to continuously monitor data changes. When node data changes, the ZooKeeper server proactively pushes a change notification to the system, parsing the updated command content within a callback function. The system supports listening to multiple command nodes simultaneously, each corresponding to different types of commands. For example, the system can separately listen to service startup nodes and hotspot refresh nodes to differentiate and process different commands.

[0054] For example, the agent resource scheduling system registers a listener on the ` / dispatch / commands` node in ZooKeeper. When ZooKeeper detects a change in node data, it immediately pushes a change notification to all system instances that have registered listeners. Upon receiving the notification, the system parses the command type as a "hotspot refresh command" and prepares to execute the hotspot data refresh operation.

[0055] Step S22: When the Zookeeper service hears the service start command, it identifies hot data from the multi-dimensional operational data based on preset hotspot rules.

[0056] It should be noted that the service startup command is an initialization command triggered when the system starts or restarts for the first time. The preset hotspot rules are a predefined set of conditions or algorithms used to determine which data qualifies as hotspot data. Examples include rules based on access frequency (more than M queries in the last N minutes), rules based on business priority (certain core metrics are marked as hotspots by default), and rules based on time windows (active data within the current time period). This step performs the initial identification and loading of hotspot data during the service startup phase, ensuring that hotspot data is ready when the system begins processing scheduling requests.

[0057] Understandably, the purpose of this step is to initialize hot data during system startup, providing a data foundation for subsequent scheduling decisions. When Zookeeper detects the service startup command, the system triggers the initialization process, scanning and filtering multi-dimensional operational data according to preset hot data rules. Data matching the rules is identified as hot data and loaded into the cache. Through proactive identification during service startup, the system pre-loads hot data before formal operation, avoiding delays caused by unprepared data during the initial scheduling request.

[0058] Specifically, when Zookeeper receives the service startup command, it initiates the hotspot data initialization process. It reads a pre-defined hotspot rule configuration file, which can contain various rule types: frequency rules (e.g., setting a time window length of 5 minutes and a frequency threshold of 10 times, indicating that data fields queried more than 10 times within 5 minutes are marked as hotspots), type rules (e.g., core fields such as agent status and queue waiting time are marked as hotspots by default), and time period rules (e.g., certain data are automatically marked as hotspots during peak business periods). The identification is performed sequentially according to rule priority: first, the core hotspot data marked by type rules is loaded; then, frequency rule identification is performed based on the most recent historical query logs; finally, time period rule identification is performed based on the current time period. The identified hotspot data is loaded into the local cache, and the identification time and data version number are recorded.

[0059] For example, when a system service starts, the preset hotspot rules include: (1) marking the agent status table and queue waiting table as hotspots by default; and (2) marking data fields that have been queried more than 10 times in the last 5 minutes as hotspots. When the system starts, it first loads the agent status table and queue waiting table; then it queries the historical logs and finds that the skill mapping table has been queried 15 times in the last 5 minutes, and marks it as a hotspot as well. Finally, the system identifies the three data tables as hotspot data and loads them into the cache.

[0060] Step S23: When the Zookeeper service hears the hotspot refresh instruction, it refreshes the hotspot data to obtain the refreshed hotspot data.

[0061] It's important to note that the hotspot refresh command is an instruction that requests the system to update the hotspot data set. This can be triggered automatically by a scheduled task (e.g., automatically refreshing at regular intervals) or manually by operations personnel (e.g., by clicking the refresh button through the management backend). Refreshing refers to re-executing the hotspot identification process, replacing the old hotspot data in the current cache with the newly identified hotspot data. This step ensures that the hotspot data can be dynamically updated as business changes occur, maintaining the timeliness and accuracy of the hotspot data.

[0062] Understandably, the purpose of this step is to address the issue of hot data becoming invalid over time. When Zookeeper detects a hot data refresh command, the system re-executes the hot data identification process, retrieves the latest set of hot data, and then replaces the old data in the cache with the new data. Through this dynamic refresh mechanism, hot data can promptly reflect changes in business access patterns, avoiding the problem of decreased cache hit rate caused by expired hot data.

[0063] Specifically, upon receiving a hotspot refresh command, the refresh process is initiated. The system first creates a new hotspot data container, then re-executes the identification process according to preset hotspot rules to generate the latest hotspot data set. The system employs a dual-caching or version-switching strategy for refreshing: during the refresh process, the system continues to provide services using the old hotspot data to avoid service interruptions. Once the new hotspot data is fully loaded, the system switches the cache pointer from the old data to the new data and then releases the memory resources occupied by the old data. The system records the timestamp and updated content for each refresh for easy problem traceability. When an anomaly occurs during the refresh process (such as data source unavailability), the system retains the original hotspot data and records an error log; alternatively, an alarm notification can be sent to operations personnel.

[0064] Furthermore, to address various Zookeeper anomalies, the system implements heartbeat and data compensation mechanisms. The heartbeat mechanism is a keep-alive mechanism where the system and Zookeeper periodically send heartbeat messages to check the connection status. The data compensation mechanism is a remedial measure where, when a Zookeeper connection anomaly or data synchronization failure is detected, the system proactively retrieves data from the data source to restore consistency. During Zookeeper connection initialization, a heartbeat thread is started simultaneously. This thread sends Ping requests to Zookeeper at fixed intervals (e.g., 30 seconds) and waits for a response. If a response is received within the timeout period (e.g., 10 seconds), the connection is considered normal; if no response is received multiple times consecutively (e.g., 3 times), the system determines that the Zookeeper connection is abnormal. After determining an anomaly, the system immediately enters data compensation mode: the system does not rely on Zookeeper event notifications but proactively reads the latest hotspot rule configurations and hotspot data lists directly from the configuration center or database, and re-executes the loading and cache update of hotspot data. After compensation is completed, the system continues to attempt to reconnect to Zookeeper and resume heartbeat listening. The compensation mechanism supports multiple trigger conditions: heartbeat timeout, Zookeeper session expiration, and data refresh command execution failure. The system logs each compensation operation, including the trigger reason, compensation time, and compensation result (success / failure), facilitating troubleshooting by operations personnel. When the compensation mechanism also fails, the system retains the last successfully synchronized hot data to continue providing services and issues a high-level alarm to notify operations personnel for manual intervention.

[0065] For example, the system automatically triggers a hotspot refresh every 10 minutes. During a refresh, the system re-executes the identification process and finds that the query frequency of a certain promotional activity skill queue has increased sharply in the past 10 minutes, making it a new hotspot data, while the query frequency of a certain nighttime skill queue has decreased and it is no longer a hotspot. The system loads the new hotspot data (including the promotional activity skill queue) into a new cache, and then switches the cache pointer to the new cache. From then on, subsequent scheduling decisions will read the hotspot data from the new cache, realizing the dynamic updating of hotspot data.

[0066] Please refer to [link / reference] for a better understanding. Figure 2 , Figure 2 This is a flowchart illustrating hotspot data refresh for the ZooKeeper service. The system first executes a scheduled task with a configurable execution frequency, defaulting to 30 seconds. After the scheduled task is triggered, the service application initiates the registration and listening process, sending a connection request to the ZooKeeper service and registering a listener. The service application creates an ephemeral node on ZooKeeper and sends a health text message as a heartbeat to that node, while simultaneously logging the heartbeat sending. The system then determines whether the heartbeat was successfully sent: if successful, the ZooKeeper service updates the heartbeat timestamp corresponding to that node, recording a normal heartbeat; if the heartbeat fails, the system increments the count of failed heartbeats and logs the failure. The system then checks if the cumulative number of failed heartbeats has reached a preset threshold (default is 3 consecutive failures). If the threshold has not been reached, the process returns to continue executing the scheduled task, waiting for the next heartbeat cycle; if the threshold has been reached (i.e., 3 consecutive heartbeat failures), the system determines that the ZooKeeper connection is abnormal, and further checks if the current time has reached the forced refresh time. The forced refresh time is determined by the condition of "execution at 30 minutes past the hour," meaning the system will force a refresh of hot data at the 30th minute of every hour, regardless of heartbeat status. If the current time has not yet reached the forced refresh time, the process returns and continues to wait; if the current time has reached the forced refresh time (e.g., 10:30, 11:30, etc.), the system will trigger the forced refresh of hot data, directly reading the latest configuration from the data source and updating the hot data in the local cache. After the forced refresh is completed, the system resets the number of failed heartbeats to 0, records the refresh log, and then the process ends. Furthermore, Figure 2 Another triggering branch is also demonstrated: when the number of successful heartbeats is greater than or equal to 3, the system determines that the Zookeeper connection has been restored, resets the number of unsuccessful heartbeats to 0, logs it, and then the process ends. Figure 2The process design shown allows the system to operate efficiently using an event-driven refresh mechanism when Zookeeper is functioning normally, and to ensure continuous updates of hot data through a timed forced refresh mechanism when Zookeeper is abnormal. At the same time, it uses a heartbeat counting and threshold judgment mechanism to automatically monitor and recover connection status, thereby ensuring the high availability and data consistency of the hot data caching system.

[0067] This embodiment establishes an event-driven data update awareness channel through the Zookeeper listening mechanism, as described above, enabling the initial loading of hot data during service startup and the updating of hot data during dynamic refresh. This technical solution addresses the problems of high resource consumption and high response latency associated with traditional polling methods. By combining passive listening with active refreshing, it ensures both efficient utilization of system resources and real-time updates of hot data as business changes occur, providing timely and accurate data support for subsequent scheduling decisions.

[0068] Based on the above implementation scheme, in one feasible implementation, the step of dividing the seat resource scheduling decision task into several parallel-executed sub-task packages based on the dynamic programming algorithm and determining the scheduling decision path includes S31~S33: Step S31: Divide the seat resource scheduling decision task into several sub-tasks according to the preset rule group, and encapsulate each sub-task into a sub-task package.

[0069] It should be noted that a preset rule group refers to a predefined set of scheduling conditions and corresponding actions. Each rule group encapsulates an independent business judgment logic. For example, when the number of people waiting in the credit card queue exceeds a threshold, agents with credit card skills will be scheduled to this queue. A subtask is an independent computational unit obtained by breaking down the original scheduling decision task according to the granularity of the rule groups. Each subtask corresponds to the index calculation of a rule group. A subtask package is the encapsulation form of a subtask, containing the input data, computation logic, and output format definition required by the subtask. The core task of this step is to decompose a complex scheduling decision task containing multiple rule groups into multiple independent subtask packages according to the boundaries of the rule groups, preparing for subsequent parallel execution.

[0070] Understandably, the purpose of this step is to break down complex tasks into independent units that can be executed in parallel, thereby leveraging the advantages of parallel computing to shorten the overall processing time. The system analyzes all rule groups contained in the scheduling decision task, creating a corresponding subtask package for each rule group, encapsulating the judgment conditions and index calculation logic of the rule group within it. Through task decomposition at the rule group granularity, the originally serial rule judgments can be transformed into parallel execution, creating conditions for improving decision-making efficiency.

[0071] Specifically, the system first loads the rule configuration for the scheduling decision task, obtaining the definitions of all rule groups. Each rule group contains three parts: triggering conditions (e.g., the number of people waiting in the queue > a threshold), calculation metrics (e.g., the queue length to be queried, the number of agents, etc.), and output format (e.g., returning True and confidence level when the conditions are met, and False when not met). The system creates a subtask package object for each rule group, which contains an independent execution method that implements the metric calculation logic for that rule group. The system places all subtask packages into a task queue, ready to enter the parallel execution phase. Optionally, the system can set task priorities, marking subtask packages of key rule groups as high priority for priority execution during resource contention.

[0072] For example, the scheduling decision task includes three rule groups: rule group A (credit card queue monitoring), rule group B (loan queue monitoring), and rule group C (time window monitoring). Three sub-task packages are created: Task_A encapsulates the judgment logic of rule group A (querying the number of people waiting in the credit card queue and comparing it with a threshold), Task_B encapsulates the judgment logic of rule group B (querying the number of available seats in the loan queue and comparing it with a threshold), and Task_C encapsulates the judgment logic of rule group C (determining whether the current time is within a preset peak period). These three sub-task packages are placed into a parallel task queue.

[0073] Step S32: Execute the sub-task package in parallel through the target framework to obtain the execution result of the sub-task package.

[0074] It should be noted that the target framework refers to the framework used to achieve parallel execution of tasks. In one embodiment of this application, the Fork / Join parallel computing framework is adopted. Parallel execution means that multiple subtask packages are simultaneously assigned to multiple computing threads or processor cores for execution, rather than being executed sequentially one after another. The execution result of a subtask package is the output data returned by each subtask package after completing its computation, which typically includes the judgment result of whether the rule group meets the conditions and related auxiliary information (such as confidence level, computation time, etc.). Through the divide-and-conquer characteristic of the Fork / Join framework, subtask packages are allocated to different computing resources for simultaneous execution, and the return results of each subtask package are collected uniformly.

[0075] Understandably, the purpose of this step is to significantly reduce the total computation time of rule groups through parallel computing. The created subtask packages are submitted to the Fork / Join framework, which automatically assigns them to available computing threads for parallel execution. Each subtask package runs independently without interference. After all subtask packages have completed execution, their results are collected collectively. Compared to serial execution, parallel execution reduces the total time from the sum of the times of all rule groups to the time of the longest-running rule group, significantly improving decision-making efficiency.

[0076] Specifically, the thread pool of the Fork / Join framework is initialized, and its size is typically set to 1 to 2 times the number of CPU cores to fully utilize hardware resources. The system submits all generated subtask packages to the Fork / Join framework, which then distributes them to different worker threads for execution. The Fork / Join framework employs a work-stealing algorithm: when a worker thread completes its own task package, it steals tasks from the tail of other busy threads' task queues to execute, thus maintaining load balancing across all threads. After each subtask package completes execution, the execution result (such as rule fulfillment / disqualification, calculated values, etc.) is returned to the result collector to obtain a complete list of execution results.

[0077] For example, three sub-task packages, Task_A, Task_B, and Task_C, are submitted to the Fork / Join framework. The system has four CPU cores. The framework assigns the three task packages to three worker threads for simultaneous execution. Task_A queries the queue database, taking 150ms; Task_B queries the agent status cache, taking 50ms; and Task_C performs time checks, taking 10ms. After Task_B and Task_C complete, their worker threads immediately steal the remaining tasks from Task_A's queue to assist in execution. Ultimately, all tasks are completed within 160ms (instead of the 210ms required for sequential execution). The system collects three execution results: Task_A returns True (waiting number exceeds threshold), Task_B returns True (insufficient available agents), and Task_C returns True (peak period).

[0078] Step S33: Based on the logical relationship between the preset rule groups, the execution results are recursively combined to generate the scheduling decision path.

[0079] It should be noted that logical relationships refer to the relational structure formed between rule groups through the combination of AND and OR logical operators. Recursive combination is a processing method that builds higher-level results step by step from lower-level sub-results by repeatedly applying the same combination rules. The scheduling decision path is the final output after the recursive combination is completed. It integrates the judgment results of all rule groups and indicates what scheduling operation should be performed in the current business state. This step merges the independent execution results of each subtask package layer by layer from the leaf nodes upwards according to the preset logical relationship tree between rule groups, and finally generates a global scheduling decision.

[0080] Understandably, the purpose of this step is to integrate the judgment results of multiple independent rule groups into a unified scheduling decision with business implications. The system parses the logical relationship tree between rule groups, starting from the leaf nodes (the results of each subtask package), merging the results of child nodes according to the logical operators (AND / OR) of the parent node, recursively ascending layer by layer, and finally obtaining the result of the root node, i.e., the scheduling decision path. Through recursive combination, the system can handle the logical relationships of rule groups of arbitrary complexity, generate scheduling decisions that conform to business rules, and ensure the integrity and correctness of the decision logic.

[0081] Specifically, the system first loads the logical relationship configuration between rule groups, typically stored as a tree structure or expression. The logical relationship tree is processed in post-order traversal: leaf nodes (i.e., the results of each subtask package) are processed first, and then the results of child nodes are merged according to the logical operator specified by the parent node. For AND relationships, the parent node's result is True only if all child node results are True; for OR relationships, the parent node's result is True as long as any child node result is True. During the merging process, the system can also pass auxiliary information, such as confidence levels (minimum for AND relationships, maximum for OR relationships). The system recursively executes the above merging process until it reaches the root node, whose result is the final scheduling decision path. The scheduling decision path includes not only a Boolean result of whether to execute the scheduling but also information about the specific rule group that triggered the scheduling (e.g., which condition triggered the scheduling), so that subsequent steps can determine specific scheduling parameters (e.g., which agents to schedule and what skills to assign).

[0082] For example, the logical relationship is configured as (A AND B) OR C, where A, B, and C correspond to the judgment results of three subtask packages. All three subtask packages result in True. The system first processes A AND B: both A and B are True, and the combined result is True. Then it processes (True) OR C: True OR True, and the combined result is True. The final scheduling decision path is to execute the schedule, and the system records the trigger condition as the rule groups A, B, and C all being satisfied. If both A and B are True but C is False, then (True AND True) OR False = True, and the schedule is still executed; if A is True, B is False, and C is False, then (True AND False) OR False = False, and the schedule is not executed.

[0083] Please refer to [link / reference] for a better understanding. Figure 3 , Figure 3 This is a schematic flowchart illustrating the execution of a scheduling decision path based on a dynamic programming algorithm. Figure 3As shown, the process mainly consists of three core parts: the main process, dynamic assembly of task packages, and tag time calculation.

[0084] In the main workflow, the system first identifies all rule groups within the scheduling decision task, such as rule group 1 to rule group n. For each rule group, the system performs a task package assembly operation, encapsulating the indicator calculation logic of each rule group into an independent sub-task package. After all rule groups' task packages are assembled, the system submits these sub-task packages to the parallel execution framework, enabling parallel execution of tasks across rule groups. After parallel execution, the system aggregates the execution results returned by each sub-task package to form a unified aggregate result, and finally outputs a decision result (such as executing the scheduling or not executing the scheduling) based on the aggregate result. The main workflow embodies the core idea of ​​"decomposition-parallel execution-aggregation," transforming complex multi-rule group decision tasks into an efficient parallel processing flow.

[0085] In the dynamic task package assembly section, the system performs refined processing on each rule group. Specifically, the system first obtains the set of tag filtering execution units corresponding to each rule group, which contains all tag judgment units that need to be executed under that rule group. The system traverses this set, obtaining tag execution units one by one. For each obtained tag execution unit, the system calculates the time consumption weight of that tag. The calculation of the time consumption weight is based on the "tag time consumption calculation" module (detailed below), used to evaluate the execution cost of the tag execution unit. The system determines whether the time consumption weight of the tag is greater than or equal to 1, or whether the number of elements in the current task queue is greater than or equal to 2. If either of the above conditions is met (time consumption weight ≥ 1 or queue elements ≥ 2), the system assembles the tag execution unit into a task package; if the conditions are not met, the system continues to obtain the next tag execution unit for judgment, or merges the unit into an existing task package. The system repeats the above process until all tag execution units are assigned to their corresponding task packages. This dynamic assembly strategy ensures that labels with high computational costs can obtain independent computing resources, while labels with low computational costs can be merged and processed, thus achieving an optimal match between task granularity and computing resources.

[0086] In the tag execution time calculation section, the system establishes a complete tag execution efficiency evaluation mechanism. For each tag execution unit, the system defaults to setting its execution time weight to 1 as the initial baseline value. The system maintains an execution unit queue for each group of tags to record the historical execution status of each tag within that group. At the asynchronous execution level, the system calculates the average execution time of tags using multiple techniques: on the one hand, it uses Kafka and Flink jobs to collect and compute real-time data streams to obtain real-time execution time data for tags; on the other hand, it stores the execution time data in ClickHouse for efficient analysis and querying; in addition, the system also uses Spark for T+1 (next day) offline batch computation to statistically analyze the average execution time of each tag from the previous day. All calculated average execution time data for tags is ultimately stored in a MySQL database for real-time querying and updating of execution time weights during the dynamic task package assembly stage. Through this mechanism, the system can dynamically perceive changes in the execution efficiency of each tag and adaptively adjust the task package assembly strategy accordingly, achieving intelligent scheduling of computing resources.

[0087] This embodiment, through the above-described scheme, constructs a complete dynamic programming parallel decision-making mechanism by decomposing tasks at the rule group granularity, using the Fork / Join framework for parallel execution, and employing recursive combination based on logical relationships. It solves the technical problem of the linear increase in decision time as the number of rule groups increases in the traditional serial rule judgment mode. It transforms the decision-making time from the accumulation of rule groups to the execution time of the longest rule group, achieving an order-of-magnitude improvement in decision-making efficiency. Simultaneously, the recursive combination ensures the accurate expression of complex logical relationships, providing a reliable decision-making basis for subsequent scheduling and execution.

[0088] Based on the above implementation scheme, in one feasible implementation, the step of dividing the seat resource scheduling decision task into several parallel-executed sub-task packages based on the dynamic programming algorithm and determining the scheduling decision path further includes S41~S43: Step S41: When the scheduling decision path indicates that the target agent needs to have their skills adjusted, query the adjustment status of the target agent through a Bloom filter.

[0089] It should be noted that a Bloom filter is a highly space-efficient probabilistic data structure used to determine whether an element belongs to a set. In this scheme, the Bloom filter is used to record the agent identifier and corresponding skill identifier currently in a cooldown state. A cooldown state refers to a temporary state where an agent's skill has recently been adjusted, a state temporarily prohibited from adjustment to avoid frequent changes. The target agent is the specific agent in the scheduling decision path that requires skill adjustment. Before formally executing the skill adjustment, this step first uses the Bloom filter to quickly query the adjustment status of the target agent to determine whether the agent is currently in a cooldown period.

[0090] Understandably, the purpose of this step is to establish an efficient deduplication and rate limiting mechanism to prevent the same agent's same skill from being repeatedly scheduled within a short period. When the scheduling decision path determines that a skill adjustment for a certain agent is needed, the agent's identifier and skill identifier are combined as the query key and input into a Bloom filter for existence lookup. The Bloom filter returns results that may or may not exist. Through the efficient query of the Bloom filter (time complexity O(k), where k is the number of hash functions, much smaller than traversal lookup), the system can complete the cooldown status check in a very short time, and the Bloom filter occupies very little memory (compared to storing the entire set), making it suitable for handling the cooldown status records of a large number of agents.

[0091] Specifically, the agent resource scheduling system initializes a Bloom filter instance, which uses multiple (e.g., 3-5) independent hash functions. The system defines a scheduling combination identifier for agents and skills, typically in the format "Agent ID_Skill ID". When querying the adjustment status of a target agent, the system inputs the agent's current scheduling combination identifier into the Bloom filter. The Bloom filter applies each hash function sequentially to this identifier, calculating the bit array index positions corresponding to multiple hash values, and checks whether the bit values ​​at these positions are all 1. If any bit value is 0, the Bloom filter returns "definitely does not exist" (i.e., the agent is definitely not in a cooling-off state); if all bit values ​​are 1, the Bloom filter returns "possibly exists" (i.e., the agent may be in a cooling-off state).

[0092] For example, the system needs to query whether agent Zhang San's credit card skill is in a cooldown state. The system inputs Zhang San's credit card skill representation ZHANGSAN_CCARD as the query key into a Bloom filter. The Bloom filter uses three hash functions to calculate bit array index positions 100, 2050, and 3100. Upon checking, it finds that the bit values ​​at these three positions are all 1, so the Bloom filter returns "possibly exists." The system determines that Zhang San's credit card skill may be in a cooldown state and enters the abort branch.

[0093] Step S42: If the query result of the Bloom filter indicates that the target agent is in a cooling state, then the current skill adjustment for the target agent is abandoned.

[0094] It should be noted that the cooling-off state is a temporary restriction state, during which the agent's skill cannot be adjusted again. Abandoning execution means the system will not perform the current skill adjustment operation and will record this decision. Possible implementation methods include recording the reason for abandonment and sending a notification message. This step handles cases where the Bloom filter query result is positive (i.e., the agent may be in a cooling-off state). A conservative strategy is adopted, abandoning this scheduling to avoid the negative impact of frequent adjustments on agent operations.

[0095] Understandably, the purpose of this step is to prevent the same agent from being repeatedly assigned the same skill within a short period, avoiding decreased agent efficiency and wasted system resources due to frequent switching. When the Bloom filter query results indicate that the scheduling combination for the target agent may exist in the cooldown log, the system chooses not to perform the skill adjustment and records the reason for abandoning the scheduling. Through the cooldown protection mechanism, the system ensures the minimum time interval for agent skill adjustments, avoiding oscillations caused by an overly sensitive decision-making system, and improving the stability of the scheduling system and the agent's work experience.

[0096] Specifically, upon receiving a possible return result from the Bloom filter, the system executes a process to abandon the scheduling attempt. The system first logs the scheduling attempt, including a timestamp, target agent ID, target skill ID, and reason for abandonment (the agent is in a cooldown state). Optionally, the system can send the abandonment information to a monitoring platform or operations terminal so that operations personnel can understand the operational status of the scheduling system. Alternatively, the system can feed this abandonment information back to the decision-making module as a reference factor for subsequent decisions (e.g., reducing the scheduling priority of that agent and skill). Then, it continues processing other pending scheduling items in the scheduling decision path (if any), or terminates the current scheduling process.

[0097] For example, the scheduling decision path indicates that Agent Zhang San's credit card skill needs to be enabled. After querying the Bloom filter, the system finds that Zhang San's credit card skill may be in a cooldown state, so it abandons the adjustment. The system log records: 2024-01-15 10:35:22, Agent Zhang San, Credit Card Skill, Reason for Abandonment: Cooldown State. Operations personnel can see this record in the monitoring backend, understanding that Zhang San's credit card skill was not rescheduled due to cooldown protection. During this period, Zhang San continued to process the original loan skill queue, avoiding efficiency losses caused by frequent skill switching.

[0098] Step S43: If the query result of the Bloom filter indicates that the target seat is not in a cooling state, then determine to perform the current skill adjustment of the target seat, and write the identifier of the target seat into the Bloom filter to start the cooling timer.

[0099] It should be noted that "confirm execution" means the system confirms that the skill adjustment operation can be performed, i.e., the agent is not in a cooldown state. "Identifier writing" refers to adding the agent-skill scheduling combination identifier to the Bloom filter, enabling subsequent queries to detect the existence of this combination. "Cooldown timer" refers to a preset time window (e.g., 5 minutes, 10 minutes) starting from the writing time. During this time window, the agent's skill is considered to be in a cooldown state. This step handles the case where the Bloom filter query result is "not found" (i.e., the agent is definitely not in a cooldown state), executes the skill adjustment, and writes the scheduling record to the Bloom filter to start the cooldown timer.

[0100] Understandably, the purpose of this step is to record the skill adjustment while performing it, providing a basis for subsequent cooldown determination. When the Bloom filter confirms that the target agent's scheduling combination definitely does not exist in the cooldown record, the system performs the skill adjustment operation and then writes the scheduling combination identifier into the Bloom filter, so that it will return a possible existence when queried in the future. Through the writing operation, the system establishes a memory mechanism for the cooldown state, ensuring that the agent that has just been adjusted will not be rescheduled during the cooldown period, thus achieving effective control of the scheduling frequency.

[0101] Specifically, upon receiving a "definitely does not exist" return result from the Bloom filter, the scheduling process begins. The skill adjustment interface is invoked to perform a skill adjustment operation on the target agent. After successful adjustment, the scheduling combination identifier of the agent and the target skill is written to the Bloom filter: various hash functions are applied sequentially to this identifier to calculate the bit array index position corresponding to each hash value, and the bit values ​​at these positions are all set to 1. After writing, a timer of the same length as the cooldown window is started. Upon expiration of this timer, the system can choose to remove the scheduling combination identifier from the Bloom filter (if the Bloom filter supports deletion) or leave it as is (probabilistic data structures typically do not support deletion; cooldown maintenance can be achieved through the natural expiration of the time window—i.e., no active deletion, but over time, the false positive rate will gradually accumulate, which the system can address by periodically rebuilding the Bloom filter). Furthermore, the Bloom filter, in conjunction with the time window mechanism, records the writing timestamp after each scheduling combination is written. During subsequent queries, the timestamp is used to determine whether the cooldown window has expired; if it has, the cooldown is considered invalid.

[0102] For example, the scheduling decision path indicates that agent Li Si's loan skill needs to be enabled. The system queries the Bloom filter and returns "definitely not found," confirming that Li Si's loan skill is not in a cooldown state. The system performs a skill adjustment, enabling Li Si's loan skill. After successful execution, the system writes LISI_LOAN to the Bloom filter, sets the corresponding hash bit value to 1, and records the write timestamp as 10:35:22, setting the cooldown time window to 5 minutes. Before 10:40:22, any scheduling request for Li Si's loan skill will be intercepted by querying the Bloom filter and returning "possibly found." After 10:40:22, based on the timestamp, it is determined that the cooldown has expired, and subsequent queries can re-execute the scheduling.

[0103] For better understanding, please refer to Figure 4 , Figure 4 This is a flowchart illustrating the calibration process of a Bloom filter. Figure 4 As shown, the entire process starts from the initial node, first initiating a skill adjustment request. This request is triggered by the scheduling decision path, indicating that a specific skill of a target agent needs adjustment. The skill adjustment request then enters a multi-layer Bloom filter for cooling-off status verification. The multi-layer Bloom filter employs a two-layer query structure: the first layer queries using the agent's identifier to quickly determine whether the agent as a whole might be in a cooling-off state; the second layer queries using both the agent's identifier and skill identifier to precisely determine whether a specific skill of that agent is in a cooling-off state. Through this two-layer query design, the system can achieve progressive filtering from coarse-grained to fine-grained, ensuring both query efficiency and refined control.

[0104] After querying with a multi-layered Bloom filter, it is determined whether the target agent's current skill is within the cooldown range. If the Bloom filter query result indicates that the agent's skill is in a cooldown state (i.e., the query returns "may exist"), the skill adjustment is abandoned, the process ends directly, and no scheduling operation is performed. If the Bloom filter query result indicates that the agent's skill is not in a cooldown state (i.e., the query returns "definitely does not exist"), the skill adjustment execution branch is entered. In the skill adjustment execution branch, the skill adjustment operation is executed first, assigning the target agent to the queue corresponding to the target skill. After the skill adjustment is completed, the adjustment record is entered into the database, and the adjustment information (including agent identifier, skill identifier, adjustment timestamp, etc.) is persistently stored in the MySQL database for subsequent data traceability and cooldown range maintenance. After the adjustment record is entered into the database, the system sends a notification to all service applications to inform them of the updated cooldown range, ensuring that the cooldown status of each service instance in the distributed deployment environment remains consistent. The process ends here.

[0105] also, Figure 4The system also demonstrates a protection thread mechanism independent of the main process. A separate daemon thread is started, which executes periodically every minute. The daemon thread's main functions are: updating the cooldown range every minute, reading cooldown records from the database, and retaining only data from the last X minutes (X is a configurable parameter, such as 10 minutes, 15 minutes, etc.). Cooldown records exceeding the time window are automatically cleaned up and no longer included in the cooldown range judgment. The protection thread periodically reads adjustment records from the MySQL database, combines them with the current timestamp to determine which records have exceeded the cooldown time window, removes these expired records from the cooldown range, and optionally updates the Bloom filter (e.g., by periodically rebuilding the Bloom filter). Through the daemon thread's periodic maintenance, the timeliness and accuracy of the cooldown range are ensured, avoiding memory bloat and increased false positive rates caused by the unlimited growth of cooldown records.

[0106] This embodiment, through the aforementioned solution, introduces a cooling model based on Bloom filters, adding a cooling status verification step after the scheduling decision path is generated and before actual scheduling execution. This technical solution solves the technical problem of frequent and ineffective adjustments to agent skills in traditional scheduling modes. Leveraging the efficient query capabilities and extremely low memory usage of Bloom filters, it achieves rapid cooling status checks in large-scale agent scenarios, effectively avoiding repeated scheduling of the same agent and the same skill within a short period. This protects agent work stability, reduces ineffective consumption of system resources, and achieves a balance between scheduling accuracy and operational stability.

[0107] Based on the above implementation scheme, in one feasible implementation, the step of scheduling based on the hotspot data and the scheduling decision path to obtain the real evaluation data includes S51~S53: Step S51: Determine the target agent and target skill to be scheduled based on the scheduling decision path.

[0108] It should be noted that the target agent is the specific agent whose skill adjustment needs to be performed, determined according to the rule group configuration in the scheduling decision path. The target skill refers to the specific skill type (such as credit card skills, loan skills, etc.) that the target agent needs to be scheduled to. This step parses the core parameters required for scheduling from the scheduling decision path, providing clear instruction information for subsequent scheduling execution.

[0109] Understandably, the purpose of this step is to transform abstract scheduling decisions into concrete, executable scheduling instructions. The system parses the rule group trigger information in the scheduling decision path and maps the agent identifiers that need to be scheduled and the skill identifiers that need to be activated based on the rule group configuration. Through parsing and mapping, the system transforms the logical-level decision results into specific operational-level instructions, clarifying who to schedule and what to schedule.

[0110] Specifically, upon receiving a scheduling decision path, the system first determines whether the decision result is to execute the scheduling. If so, it further parses the rule group information that triggered the scheduling. Each rule group is associated with a scheduling parameter template during configuration, including: agent selection conditions (such as the agent with the longest idle time, the agent with the highest skill matching degree, etc.), target skill identifiers (such as credit card skills, loan skills), and scheduling quantity (such as scheduling 3 agents). Based on the agent selection conditions, a specific list of target agents is selected from the pool of agents that meet the conditions, and based on the target skill identifiers, the skill that each agent needs to be scheduled for is determined. The parsed results are assembled into a scheduling instruction list, with each instruction containing a target agent identifier and a target skill identifier.

[0111] For example, the scheduling decision path indicates the trigger rule group A, which is configured as follows: when the number of people waiting in the credit card queue exceeds a threshold, select agents with credit card skills from the idle agent pool and schedule 5 agents to the credit card queue. Based on this configuration, the system obtains a list of currently idle agents with credit card skills from the hotspot data, sorts them by idle duration, and selects the top 5: Zhang San, Li Si, Wang Wu, Zhao Liu, and Qian Qi. The system generates 5 scheduling instructions: (Zhang San, credit card skill), (Li Si, credit card skill), (Wang Wu, credit card skill), (Zhao Liu, credit card skill), and (Qian Qi, credit card skill).

[0112] Step S52: Read the real-time status information of the target agent from the hotspot data and verify whether the target agent meets the scheduling execution conditions.

[0113] It should be noted that real-time status information refers to the dynamic status data of the agent at the current moment, including the agent's online status (online / offline), working status (idle / on a call / taking a break / training / post-event processing), current continuous working time, and current skill queue. Scheduling execution conditions refer to the set of preconditions that must be met for an agent to be adjusted by the executing skill, typically including: the agent must be online, the agent must be idle or switchable, the agent is not currently in a cooling-off state (as addressed in claim 4), and the agent is not currently in an emergency state (such as performing critical business processing). This step utilizes the real-time status information of the agents stored in the hotspot data to perform a final verification of the target agent before scheduling, ensuring the security of the scheduling operation.

[0114] Understandably, the purpose of this step is to prevent scheduling failures or anomalies caused by changes in agent status at the actual scheduling moment. Based on the determined scheduling instructions, the real-time status information of each target agent is read from the hotspot data. The read status is then compared one by one with the scheduling execution conditions to confirm whether the agent can truly be scheduled. This real-time status verification before scheduling ensures that the scheduling instructions are still valid at the moment of execution, avoiding invalid or erroneous scheduling due to expired status and improving the success rate of scheduling execution.

[0115] Specifically, the generated list of scheduling instructions is traversed, and a verification process is executed for the target agent in each instruction. The latest status information of the agent is read from the hot data cache (hot data is maintained through a refresh mechanism to ensure timeliness). The system verifies the following conditions: first, whether the agent is online; second, whether the agent's work status is idle or post-processing (indicating that they can receive new tasks); third, whether the agent's current queue allows switching (some queues may be temporarily locked due to business reasons); and fourth, whether the agent meets the qualification requirements of the target skill (e.g., whether they have completed the relevant training). Only when all conditions are met is the agent marked as meeting the scheduling execution conditions. For agents that do not meet the conditions, the system removes them from the current scheduling list and records the reason for removal. Optionally, the system can trigger a replacement selection mechanism to reselect a qualified agent from the agent pool to fill the removed position.

[0116] For example, the system verifies the status of the five agents in the dispatch instruction. It reads from hotspot data: Zhang San's status = idle, Li Si's status = on call, Wang Wu's status = idle, Zhao Liu's status = short break, and Qian Qi's status = idle. Verification results: Zhang San meets the criteria, Li Si does not (on call), Wang Wu meets the criteria, Zhao Liu does not (on short break), and Qian Qi meets the criteria. The system retains Zhang San, Wang Wu, and Qian Qi who meet the criteria, and removes Li Si and Zhao Liu from the current dispatch list, recording: Li Si's removal reason: on call; Zhao Liu's removal reason: short break. The system triggers a replacement selection, adding Sun Ba and Zhou Jiu from the idle agent pool, and the final dispatch list is adjusted to: Zhang San, Wang Wu, Qian Qi, Sun Ba, and Zhou Jiu.

[0117] Step S53: If the target agent meets the scheduling execution conditions, the target agent is assigned to the queue corresponding to the target skill for scheduling execution to obtain the actual evaluation data.

[0118] It should be noted that allocation refers to binding an agent to a target skill, adding the agent to the service queue corresponding to the target skill, and enabling it to begin receiving customer requests of that skill type. Scheduling execution refers to actually calling the agent skill management system's interface to complete the change operation of the agent skill configuration. Real evaluation data refers to the data collected after scheduling execution, including the scheduling execution status (success / failure), execution timestamp, changes in agent status after scheduling, and changes in relevant business indicators before and after scheduling.

[0119] Understandably, the purpose of this step is to implement the verified scheduling instructions and collect execution effect data. For each verified target agent, the system calls the skill adjustment interface to assign them to the queue corresponding to the target skill; during execution, it records information such as success / failure status and execution time; after execution, it updates the status information of relevant agents in the hot data and collects operational metrics before and after scheduling. Through a standardized scheduling execution process and data collection mechanism, the system achieves reliable implementation of scheduling instructions and produces real evaluation data that can be used for subsequent effect assessment.

[0120] Specifically, for each verified target agent, a scheduling operation is executed one by one. For each agent, the API interface of the agent skill management system is called, passing parameters including: agent identifier, target skill identifier, and operation type (enable / switch). The API is then waited for the execution result: if a success code is returned, the scheduling execution status is recorded as successful, and the agent's skill list and status information in the hotspot data are updated; if a failure code is returned, the scheduling execution status is recorded as failed, along with the reason for failure (e.g., interface timeout, insufficient permissions). The execution timestamp of each scheduling instruction is recorded. After all scheduling instructions have been executed, operational metrics before and after scheduling execution are collected from the hotspot data: before scheduling, the number of waiting users in each queue, connection rate, average waiting time, etc.; and after scheduling, the corresponding metrics within the same time window.

[0121] For example, a scheduling operation is performed on five agents in the scheduling list: Zhang San, Wang Wu, Qian Qi, Sun Ba, and Zhou Jiu. The skill management API is called to enable the credit card skills for these five agents. The API returns: all five instructions were successful. The system records: scheduling execution status = successful, execution timestamp = 10:35:22. The system updates the skill list of these five agents in the hotspot data, adding the credit card skills. Operational metrics for the credit card queue before scheduling (10:30:00-10:35:00) are collected from the hotspot data: number of waiting users = 15, connection rate = 72%, average waiting time = 45 seconds. Five minutes after scheduling (10:35:00-10:40:00), the data is collected again: number of waiting users = 8, connection rate = 84%, average waiting time = 28 seconds. The system encapsulates this data into real evaluation data.

[0122] This embodiment, through the above-described scheme, constructs a complete scheduling implementation mechanism by analyzing the target agent and target skills from the scheduling decision path, verifying the real-time status from hot data, and actually executing and allocating data. This technical solution solves the technical problems of lacking status verification for instruction execution and lacking recording and feedback of execution results in traditional scheduling models. Real-time status verification before scheduling ensures the executability of scheduling instructions, and data collection after execution provides a quantitative basis for effect evaluation, realizing a complete closed loop from decision-making to execution to data feedback.

[0123] Based on the above implementation scheme, in one feasible implementation, before the step of comparing and analyzing the actual evaluation data and the expected evaluation data to obtain the comparison analysis results, the method further includes steps S61 to S62: Step S61: Construct an autoregressive integral moving average time series prediction model.

[0124] It should be noted that the Autoregressive Integrated Moving Average (ARIMA) time series forecasting model is a classic statistical model used for analyzing and forecasting time series data. The autoregressive (AR) part represents the linear relationship between the current value and the previous p historical values; the integral (I) part transforms a non-stationary series into a stationary series through differencing; and the moving average (MA) part represents the linear relationship between the current value and the past q prediction errors. Construction refers to the process of determining the optimal parameters (p, d, q) of the model based on the characteristics of historical data (such as trend, seasonality, and periodicity) and initializing the model instance. The purpose of this step is to establish a forecasting model that can accurately characterize the time series patterns of operational data.

[0125] Understandably, the purpose of this step is to establish a reliable mathematical model foundation for subsequent predictive functions. The system collects a sufficiently long series of historical operational data and uses methods such as autocorrelation analysis (ACF) and partial autocorrelation analysis (PACF) to identify the stationarity and autocorrelation characteristics of the data. Based on this, the three core parameters (p, d, q) of the ARIMA model are determined, completing the model construction and initialization. Through parameter optimization and data fitting, the constructed ARIMA model can capture the time-series patterns of operational data, providing model support for generating accurate expected assessment data.

[0126] Specifically, historical data on operational metrics such as call volume, connection rate, and waiting time over a past period (e.g., 30 days) are extracted from the database to form a time series. First, a stationarity test is performed, such as the ADF (Augmented Dickey-Fuller) test. If the series is not stationary, it is transformed into a stationary series through differencing (d-parameters). Then, by plotting autocorrelation and partial autocorrelation function (AIC) graphs, the order p (cutoff point of the partial autocorrelation graph) of the autoregressive component and the order q (cutoff point of the moving average) of the moving average component are identified. The system can use a grid search method to traverse candidate parameter combinations and select the parameter combination with the smallest AIC (Akaike Information Criterion) or BIC (Bayesian Information Criterion) value as the optimal model parameters. The system instantiates an ARIMA model object based on the selected parameters (p, d, q) and trains the model using historical data (i.e., estimates the coefficients in the model). After the model is trained, the system can test the goodness of fit of the model (such as residual white noise test) to ensure the effectiveness of the model.

[0127] For example, the system analyzes hourly call volume data over the past 30 days and finds that the sequence exhibits a clear daily periodicity but is not stationary. The ADF test p-value is 0.6 > 0.05, accepting the non-stationary hypothesis. After the system performs first-order differencing (d=1), the sequence becomes stationary. Analysis of the autocorrelation plot and partial autocorrelation plot reveals that the partial autocorrelation plot is truncated after lag 1, and the autocorrelation plot is also truncated after lag 1, determining p=1 and q=1. The system constructs an ARIMA(1,1,1) model, trains the model coefficients using data from the first 28 days, and validates them using data from the last 2 days. The prediction error is within an acceptable range, and the model construction is complete.

[0128] Step S62: The historical operating data and the multidimensional operating data are fitted and predicted using the autoregressive integral moving average time series prediction model to generate expected evaluation data within the future time window.

[0129] It should be noted that historical operational data refers to actual operational indicator data generated over a past period, used to train the predictive model. Multidimensional operational data refers to the multi-source data collected in real-time as described in claim 1, including real-time data at the current moment. Fitting prediction refers to inputting historical and real-time data into the constructed ARIMA model, which calculates predicted values ​​within future time windows based on learned time series patterns. A future time window refers to a time interval extending into the future from the current moment (such as the next 15 minutes, the next hour, the next half-day, etc.). Expected evaluation data refers to the predicted target values ​​for future operational indicators, such as predicted future call completion rate, predicted future call volume, and predicted future waiting time.

[0130] Understandably, the purpose of this step is to provide forward-looking target references for scheduling decisions, enabling scheduling to move beyond mere post-event remediation and instead focus on pre-event prediction. Historical operational data and current real-time operational data are input into the constructed ARIMA model. The model uses autoregression and moving average mechanisms to calculate predicted values ​​for various operational indicators within future time windows, outputting these predicted values ​​as expected performance data. Through time series forecasting, the system can anticipate resource demands before peak business periods arrive, setting reasonable scheduling targets in advance, thereby achieving a shift from reactive response to proactive scheduling.

[0131] Specifically, the prediction process is executed at the beginning of each scheduling cycle (or at fixed time intervals). Sufficiently long historical operational data time series (such as call volume, call completion rate, and waiting time at 5-minute granularity for the last 7 days) are extracted from the database, and current real-time operational data is obtained from hotspot data. The system merges this data and inputs it into the constructed ARIMA model. Based on historical patterns and the current state, the model predicts various indicators within a future time window (such as the next 15 minutes) and outputs a sequence of predicted values. The system converts the predicted values ​​into expected evaluation data format, including predicted call completion rate, predicted call volume, and predicted average waiting time at each time point. The system can adjust the predicted values ​​according to business needs (such as multiplying by a safety factor) to adapt to aggressive or conservative strategies in different scenarios. The generated expected evaluation data is stored or transmitted to the scheduling decision module as a reference benchmark for setting scheduling targets.

[0132] For example, if the current time is 10:00, the system needs to predict the call volume of the credit card queue for the next 15 minutes (10:00-10:15). The system extracts call volume data from 10:00-10:15 every day for the past 7 days as a historical sequence, combines it with the real-time call volume data at the current time of 10:00, and inputs it into the ARIMA(1,1,1) model. The model outputs: the predicted call volume for the next 15 minutes is 120 calls, the target predicted connection rate is 85%, and the target predicted average waiting time is 30 seconds. The system uses these predicted values ​​as expectation evaluation data. The scheduling decision module determines based on these expectations: if the current resources are insufficient to support 120 calls, then agent resources need to be scheduled to the credit card queue in advance.

[0133] This embodiment, through the above-described scheme, generates expected assessment data for future time windows by fitting and predicting historical and real-time operational data. This technical solution addresses the problems of traditional scheduling models, such as reliance on manual experience in target setting, lack of data support, and a tendency to lead to over-schedule or under-schedule. By using time series prediction, it upgrades scheduling target setting from post-event compensation to pre-event prediction, enabling scheduling decisions to respond proactively to changing business trends and improving the foresight and accuracy of scheduling.

[0134] Based on the above implementation scheme, in one feasible implementation, the step of comparing and analyzing the actual evaluation data and the expected evaluation data to obtain the comparison analysis results includes S71~S72: Step S71: Compare the actual evaluation data within the preset time window after scheduling execution with the corresponding target value in the expected evaluation data to calculate the target deviation value.

[0135] It should be noted that the preset time window refers to a pre-defined time interval (such as 5 minutes, 10 minutes, or 15 minutes after scheduling execution) used to collect operational indicator data after scheduling execution. Actual evaluation data refers to the actual operational indicator values ​​collected after scheduling execution. Expected evaluation data refers to the target values ​​of future operational indicators predicted by the ARIMA model. Target values ​​are the specific numerical values ​​of each indicator included in the expected evaluation data, such as a target connection rate of 85% or a target average waiting time of 30 seconds. The target deviation value refers to the difference between the actual value in the actual evaluation data and the target value in the expected evaluation data; the calculation method is determined according to the indicator type (such as difference, ratio, etc.).

[0136] Understandably, the purpose of this step is to quantitatively evaluate the gap between the actual effect of the scheduling execution and the expected goals. The system extracts the actual values ​​of various operational indicators within a preset time window from the real evaluation data, extracts the corresponding target values ​​from the expected evaluation data, and calculates the deviation value item by item according to the preset calculation formula. Through deviation calculation, the system transforms the abstract quality of the effect into specific numerical deviations, providing quantitative input for subsequent threshold judgment.

[0137] Specifically, after the scheduling execution is completed, a preset time window (e.g., 5 minutes) is waited for to end. After the time window ends, the actual values ​​of various operational indicators within that time window are extracted from the generated real evaluation data. Simultaneously, the target values ​​for the corresponding time period and indicator are extracted from the generated expected evaluation data. For each indicator, a target deviation value is calculated. The calculation method for the deviation value is determined based on the characteristics of the indicator: For ratio-type indicators (e.g., connection rate), connection rate deviation value = actual connection rate value - connection rate target value (positive deviation indicates better than the target, negative deviation indicates worse than the target); for duration-type indicators (e.g., average waiting time), average waiting time deviation value = actual average waiting time value - average waiting time target value (negative deviation indicates better than the target, positive deviation indicates worse than the target); for count-type indicators (e.g., call volume, queue length), call volume deviation value = actual call volume value - call volume target value, the positive or negative meaning of which is determined based on business expectations. All calculated deviation values ​​are summarized to form a deviation value set.

[0138] For example, within a 5-minute time window after scheduling execution, the actual evaluation data collected by the system is: connection rate = 82%, average waiting time = 35 seconds, and queue length = 12 people. The system reads the corresponding target values ​​from the expected evaluation data: target connection rate = 85%, target average waiting time = 30 seconds, and target queue length = 8 people. The system calculates the deviation values: connection rate deviation = 82% - 85% = -3% (3 percentage points worse than the target), average waiting time deviation = 35 - 30 = +5 seconds (5 seconds worse than the target), and queue length deviation = 12 - 8 = +4 people (4 people worse than the target).

[0139] Step S72: Compare the target deviation value with the preset deviation threshold respectively to generate the comparison analysis result.

[0140] It should be noted that the preset deviation threshold refers to the maximum acceptable deviation range between the actual value and the target value, which is pre-set. Different thresholds can be set for different indicators (e.g., the allowable deviation for call connection rate is ±5%, and the allowable deviation for average waiting time is +10 seconds, etc.). The comparative analysis results are conclusive outputs generated after comparing the deviation value with the threshold, which typically include: the deviation status of each indicator (normal / exceeding the threshold / severely exceeding the threshold), the overall assessment conclusion (meeting the standard / not meeting the standard), and suggested follow-up actions (no action / warning / rescheduling, etc.). The calculated deviation value is compared with the preset threshold, and a structured analysis report is generated based on the comparison results.

[0141] Understandably, the purpose of this step is to determine whether the scheduling effect is within an acceptable range based on the magnitude of the deviation value, and to trigger subsequent warnings or adjustments accordingly. The target deviation value of each indicator is compared with the corresponding preset deviation threshold to determine whether the deviation value exceeds the threshold. All comparison results are summarized to generate a comparative analysis result that includes the status of each indicator and a comprehensive conclusion. Through threshold comparison, the system achieves automated evaluation and hierarchical judgment of scheduling effect, providing clear effect feedback to operators and a decision-making basis for possible automatic rescheduling.

[0142] Specifically, preset deviation thresholds are established for each indicator. For example: connection rate threshold = ±5% (meaning the actual value is considered normal if it is within ±5 percentage points of the target value), average waiting time threshold = +10 seconds (meaning the actual waiting time is considered normal if it exceeds the target value by less than 10 seconds), and queue length threshold = +5 people (meaning the actual queue length is considered normal if it exceeds the target value by less than 5 people). The system iterates through the calculated deviation values ​​of each indicator and performs comparison logic for each indicator: if the absolute value of the deviation (or a directional judgment based on a one-way threshold) is less than or equal to the preset threshold, the indicator is marked as normal; if it exceeds the threshold but within a certain range (e.g., within 2 times the threshold), it is marked as "attention"; if it significantly exceeds the threshold (e.g., more than 2 times), it is marked as "alarm". The system summarizes the status of all indicators and generates a comparative analysis result, which may include: overall compliance status (marked as compliant when all indicators are normal, otherwise marked as non-compliant), a list of indicators exceeding the threshold and their specific deviation values, and suggested actions (e.g., no action required, sending an early warning notification, triggering rescheduling, etc.). The generated comparative analysis result can be stored and displayed on the operations monitoring panel.

[0143] For example, preset thresholds are: connection rate threshold = ±5%, average waiting time threshold = +10 seconds, and queue length threshold = +5 people. The deviation values ​​calculated in step S701 are: connection rate deviation = -3%, average waiting time deviation = +5 seconds, and queue length deviation = +4 people. Comparison results: if the absolute value of the connection rate deviation -3% is 3% < 5%, the status is normal; if the average waiting time deviation is +5 seconds < +10 seconds, the status is normal; if the queue length deviation is +4 people < +5 people, the status is normal. The overall compliance status is compliant, and the suggested action is no action required. If in another scenario, the average waiting time deviation is +15 seconds, exceeding the +10-second threshold, then the status of this indicator is alarm, the overall compliance status is non-compliant, and the suggested action is to send a warning notification.

[0144] This embodiment constructs a quantitative scheduling effect evaluation mechanism through the above scheme, using deviation value calculation and threshold comparison. This technical solution solves the technical problems of lacking objective quantitative evaluation of scheduling effects and difficulty in judging whether targets are met in traditional scheduling models. By accurately comparing actual evaluation data with expected evaluation data, the scheduling effect is transformed into quantifiable deviation indicators and executable status judgments, providing clear effect feedback for operators and a decision-making basis for closed-loop system optimization (such as automatic rescheduling), thus realizing automated and standardized evaluation of scheduling effects.

[0145] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the seat resource scheduling method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0146] This application also provides a seat resource scheduling device, please refer to... Figure 5 The seat resource scheduling device includes: Hotspot identification module 501 is used to identify hotspots in multidimensional operational data to obtain hotspot data of the multidimensional operational data. The scheduling determination module 502 is used to divide the seat resource scheduling decision task into several parallel execution sub-task packages based on the dynamic programming algorithm and determine the scheduling decision path. The scheduling execution module 503 is used to perform scheduling based on the hotspot data and the scheduling decision path to obtain real evaluation data; The comparison analysis module 504 is used to compare and analyze the actual evaluation data and the expected evaluation data to obtain the comparison analysis results.

[0147] The seat resource scheduling device provided in this application, employing the seat resource scheduling method in the above embodiments, can solve the technical problem of low seat resource scheduling efficiency. Compared with the prior art, the beneficial effects of the seat resource scheduling device provided in this application are the same as those of the seat resource scheduling method provided in the above embodiments, and other technical features in the seat resource scheduling device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0148] This application provides a seat resource scheduling device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the seat resource scheduling method in the above embodiment 1.

[0149] The following is for reference. Figure 6 The diagram illustrates a structural schematic of a seat resource scheduling device suitable for implementing embodiments of this application. The seat resource scheduling device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The seat resource scheduling device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0150] like Figure 6As shown, the seat resource scheduling device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the seat resource scheduling device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the agent resource scheduling device to communicate wirelessly or wiredly with other devices to exchange data. Although agent resource scheduling devices with various systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0151] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0152] The seat resource scheduling device provided in this application, employing the seat resource scheduling method in the above embodiments, can solve the technical problem of low seat resource scheduling efficiency. Compared with the prior art, the beneficial effects of the seat resource scheduling device provided in this application are the same as those of the seat resource scheduling method provided in the above embodiments, and other technical features in this seat resource scheduling device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0153] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0155] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the seat resource scheduling method in the above embodiments.

[0156] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0157] The aforementioned computer-readable storage medium may be included in the seat resource scheduling device; or it may exist independently and not be assembled into the seat resource scheduling device.

[0158] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the agent resource scheduling device, the agent resource scheduling device performs the following actions: hotspot identification on the multi-dimensional operational data to obtain hotspot data; it then divides the agent resource scheduling decision task into several parallel sub-task packages based on a dynamic programming algorithm to determine the scheduling decision path; it performs scheduling based on the hotspot data and the scheduling decision path to obtain actual evaluation data; and it compares and analyzes the actual evaluation data with the expected evaluation data to obtain the comparison analysis results.

[0159] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0160] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0161] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0162] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described seat resource scheduling method, thereby solving the technical problem of low seat resource scheduling efficiency. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the seat resource scheduling method provided in the above embodiments, and will not be repeated here.

[0163] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the seat resource scheduling method described above.

[0164] The computer program product provided in this application can solve the technical problem of low efficiency in seat resource scheduling. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the seat resource scheduling method provided in the above embodiments, and will not be repeated here.

[0165] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for scheduling agent resources, characterized in that, The seat resource scheduling method includes: Hotspot identification is performed on the multidimensional operational data to obtain the hotspot data of the multidimensional operational data; The task of scheduling agent resources is divided into several parallel sub-task packages based on the dynamic programming algorithm to determine the scheduling decision path. Scheduling is performed based on the hotspot data and the scheduling decision path to obtain accurate evaluation data; The actual evaluation data and the expected evaluation data are compared and analyzed to obtain the comparison and analysis results.

2. The seat resource scheduling method as described in claim 1, characterized in that, The step of identifying hotspots in multidimensional operational data to obtain hotspot data of the multidimensional operational data includes: Build a Zookeeper service and listen for data change commands through the Zookeeper service. The data change commands include service start commands and hotspot refresh commands. When the Zookeeper service listens for the service startup command, it identifies hot data from the multi-dimensional operational data based on preset hotspot rules; When the Zookeeper service detects the hotspot refresh command, it refreshes the hotspot data to obtain the refreshed hotspot data.

3. The seat resource scheduling method as described in claim 1, characterized in that, The steps for dividing the seat resource scheduling decision task into several parallel sub-task packages based on the dynamic programming algorithm and determining the scheduling decision path include: The seat resource scheduling decision task is divided into several sub-tasks according to a preset rule group, and each sub-task is encapsulated into a sub-task package; The sub-task packages are executed in parallel using the target framework to obtain the execution results of the sub-task packages; The execution results are recursively combined based on the logical relationships between the preset rule groups to generate the scheduling decision path.

4. The seat resource scheduling method as described in claim 1, characterized in that, The step of dividing the seat resource scheduling decision task into several parallel-executed sub-task packages based on the dynamic programming algorithm and determining the scheduling decision path further includes: When the scheduling decision path indicates that skill adjustments are needed for the target agent, the adjustment status of the target agent is queried through a Bloom filter; If the query result of the Bloom filter indicates that the target agent is in a cooling state, then the current skill adjustment for the target agent is abandoned. If the query result of the Bloom filter indicates that the target agent is not in a cooling state, then it is determined to perform a current skill adjustment for the target agent, and the identifier of the target agent is written into the Bloom filter to start the cooling timer.

5. The seat resource scheduling method as described in claim 1, characterized in that, The step of scheduling based on the hotspot data and the scheduling decision path to obtain the actual evaluation data includes: The target agent and target skill to be scheduled are determined based on the aforementioned scheduling decision path; Read the real-time status information of the target agent from the hotspot data to verify whether the target agent meets the scheduling execution conditions; If the target agent meets the scheduling execution conditions, the target agent will be assigned to the queue corresponding to the target skill for scheduling execution, thereby obtaining the actual evaluation data.

6. The seat resource scheduling method as described in claim 1, characterized in that, Before the step of comparing and analyzing the actual evaluation data and the expected evaluation data to obtain the comparison and analysis results, the method further includes: Construct an autoregressive integral moving average time series prediction model; The autoregressive integral moving average time series prediction model is used to fit and predict historical operating data and multidimensional operating data to generate expected evaluation data within future time windows.

7. The seat resource scheduling method as described in claim 1, characterized in that, The step of comparing and analyzing the actual evaluation data and the expected evaluation data to obtain the comparison analysis results includes: The target deviation value is calculated by comparing the actual evaluation data within the preset time window after the scheduling is executed with the corresponding target value in the expected evaluation data. The target deviation value is compared with a preset deviation threshold to generate the comparison analysis result.

8. A seat resource scheduling device, characterized in that, The seat resource scheduling device includes: The hotspot identification module is used to identify hotspots in multidimensional operational data to obtain hotspot data from the multidimensional operational data. The scheduling determination module is used to break down the seat resource scheduling decision task into several parallel sub-task packages based on the dynamic programming algorithm, and determine the scheduling decision path. The scheduling execution module is used to perform scheduling based on the hotspot data and the scheduling decision path to obtain real evaluation data; The comparison and analysis module is used to compare and analyze the actual evaluation data and the expected evaluation data to obtain the comparison and analysis results.

9. A seat resource scheduling device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the seat resource scheduling method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the seat resource scheduling method as described in any one of claims 1 to 7.

Images