Multi-modal agent RAG-ReAct double-engine cooperative training method

Abstract

The invention relates to the technical field of artificial intelligence, in particular to a multi-mode agent RAG-ReAct double-engine cooperative training method. The method comprises the following steps: acquiring multi-modal agent data; identifying a fuzzy distortion image according to the multi-modal agent data; determining optical focusing abnormity based on the fuzzy distortion image, and generating optical focusing abnormity data; the abrasion loss of the spiral guide rail is detected based on optical focusing abnormal data; determining the service life of the lens module according to the spiral guide rail abrasion loss; the focusing compensation amplitude is optimized based on the service life of the lens module; retrieving an agent historical database based on the focusing compensation amplitude, and monitoring computing power overload in a retrieval process to obtain computing power overload data and historical maintenance information; and performing memory leak detection based on the computing power overload data to obtain memory leak data. According to the method, the adaptive execution efficiency and the task completion rate of the multi-modal agent in a complex environment are improved based on an artificial intelligence technology.

Description

Technical Field

[0001] The present invention relates to the field of artificial intelligence technology, and in particular to a multimodal intelligent agent RAG-ReAct dual-engine collaborative training method. Background Art

[0002] In the actual operation of intelligent agents, judgments about the degree of problem resolution often involve ambiguity and uncertainty. Traditional methods, especially when faced with complex query tasks, struggle to accurately assess the completion of the current link and the depth of problem resolution. They often rely on static data processing models and are unable to adjust strategies in real time in dynamically changing environments. Due to the high-dimensional nature of multimodal data, the correlations between different data types cannot be fully utilized when processing them, resulting in inefficient information integration and impacting task performance and accuracy. Model training in traditional methods is often complex and computationally resource-intensive. Especially with limited computing resources, it is difficult to ensure real-time and high efficiency, and computational overload is prone to occur. Traditional dual-engine collaborative training methods often have limitations in memory management and resource scheduling. Especially in complex multimodal tasks, memory leaks and wasted computing resources become serious bottlenecks, impacting system stability and long-term operational capabilities. Detection methods for hardware failures and device anomalies are relatively limited, often limited to monitoring superficial indicators such as focus and vibration, and lack comprehensive monitoring of underlying device performance. This makes it difficult to provide effective early warnings and corrective actions when encountering complex anomalies. Summary of the Invention

[0003] Based on this, it is necessary for the present invention to provide a multimodal intelligent agent RAG-ReAct dual-engine collaborative training method to solve at least one of the above technical problems.

[0004] To achieve the above objectives, a multimodal agent RAG-ReAct dual-engine collaborative training method is proposed, which includes the following steps:

[0005] Step S1: acquiring multimodal agent data; identifying a blurred and distorted image based on the multimodal agent data; determining optical focus abnormality based on the blurred and distorted image, and generating optical focus abnormality data;

[0006] Step S2: Detecting the wear of the spiral guide rail based on the optical focus anomaly data; determining the life of the lens module based on the wear of the spiral guide rail; optimizing the focus compensation amplitude based on the life of the lens module; searching the intelligent agent history database based on the focus compensation amplitude, and monitoring the computing power overload during the retrieval process to obtain computing power overload data and historical maintenance information;

[0007] Step S3: Detect memory leaks based on the computing power overload data to obtain memory leak data; monitor the agent processor thermal anomaly based on the memory leak data to obtain processor thermal anomaly data;

[0008] Step S4: Perform heat dissipation reinforcement learning decision adjustments on the processor thermal anomaly data based on historical maintenance information to obtain heat dissipation reinforcement learning decision data; perform path planning cognitive evolution based on the heat dissipation reinforcement learning decision data to generate path planning cognitive evolution data; transmit the path planning cognitive evolution data and the heat dissipation reinforcement learning decision data to the multimodal intelligent agent to perform the dual-engine collaborative training task.

[0009] By acquiring and analyzing multimodal agent data, the present invention helps the system identify and process blurred and distorted images caused by optical focus anomalies. This optimized anomaly detection not only improves image quality but also reduces system errors caused by optical issues, thereby increasing the accuracy of subsequent task execution. By determining optical focus anomalies based on blurred and distorted images, the wear of the spiral guide rail can be further identified, and this information can be used to estimate the lifespan of the lens module. This process effectively monitors the health of the optical system, enabling early prediction of device lifespan and appropriate measures to prevent equipment failure at critical moments, thereby improving the system's stability and long-term operational capabilities. By optimizing the focus compensation amplitude based on the lens module lifespan, combined with the agent's historical database retrieval process and monitored computing power overload, the entire system can adjust the focus strategy in real time during actual operation and rationally allocate resources in the event of computing power overload, avoiding insufficient computing power or resource waste. This dynamic optimization mechanism not only improves focusing accuracy but also ensures efficient utilization of computing resources, avoiding the real-time performance issues caused by excessive computing resource consumption in traditional methods. Memory leak detection and processor thermal anomaly monitoring further enhance the agent's hardware management capabilities, enabling timely detection of potential hardware failures when the system load is too high, thus avoiding system crashes or performance degradation caused by memory leaks or excessive temperatures. Through heat dissipation reinforcement learning decision adjustments based on historical maintenance information, not only can the heat dissipation solution be optimized, but it can also be intelligently adjusted according to real-time load conditions and hardware status, thereby maximizing the life of the equipment and ensuring efficient operation of the system in complex task environments. The generation and transmission of path planning cognitive evolution data to the multimodal agent further enhances the system's adaptability, enabling the agent to quickly adjust its computing and cooling strategies under different operating environments and task requirements to support the smooth progress of dual-engine collaborative training tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Other features, objects and advantages of the present invention will become more apparent upon reading the detailed description of non-limiting embodiments thereof made with reference to the following drawings:

[0011] Figure 1 A schematic flow chart of the steps of a multimodal agent RAG-ReAct dual-engine collaborative training method of the present invention;

[0012] Figure 2 Detailed step flow diagram of step S1 in the present invention;

[0013] Figure 3 Detailed step flow diagram of step S3 in the present invention;

[0014] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0015] The following is a clear and complete description of the technical method of the present invention in conjunction with the accompanying drawings. Obviously, the embodiments described are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making any creative work are within the scope of protection of the present invention.

[0016] In addition, the accompanying drawings are merely schematic illustrations of the present invention and are not necessarily drawn to scale. Identical reference numerals in the figures denote identical or similar parts, and thus repetitive descriptions thereof will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities that do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor and / or microcontroller approaches.

[0017] It should be understood that although the terms "first," "second," and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used solely to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of the exemplary embodiments. The term "and / or" as used herein includes any and all combinations of one or more of the listed associated items.

[0018] To achieve this, please refer to Figures 1 to 3 The present invention provides a multimodal agent RAG-ReAct dual-engine collaborative training method, the method comprising the following steps:

[0019] Step S1: acquiring multimodal agent data; identifying a blurred and distorted image based on the multimodal agent data; determining optical focus abnormality based on the blurred and distorted image, and generating optical focus abnormality data;

[0020] In this embodiment, multimodal intelligent agent data is collected, including raw data output by multiple types of sensors such as visual sensors, temperature sensors, and acceleration sensors. These data can be collected in real time by various sensor modules connected to the intelligent agent. Specifically, the image data is extracted into RGB three-channel format, the temperature data is output in degrees Celsius, and the acceleration data is output as acceleration values per second along the XYZ axis. After acquiring the data, the original image is denoised using an image processing algorithm to obtain clear image information. Then, based on fuzzy and distorted image recognition technology (such as an image sharpening algorithm), the image edge information is used to analyze the image clarity, and the gradient method is used to calculate the brightness change of each pixel in the image to identify fuzzy and distorted areas. The presence of these distorted areas indicates the presence of optical focus anomalies. The optical focus anomalies in the image are marked, and the optical focus algorithm is used to analyze whether the optical module has focus deviation and generate optical focus anomaly data. The generated data includes the focus error value, focus offset angle, and the coordinates of the deviation area. The data is saved in JSON format and provides basic data support for subsequent processing steps.

[0021] Step S2: Detecting the wear of the spiral guide rail based on the optical focus anomaly data; determining the life of the lens module based on the wear of the spiral guide rail; optimizing the focus compensation amplitude based on the life of the lens module; searching the intelligent agent history database based on the focus compensation amplitude, and monitoring the computing power overload during the retrieval process to obtain computing power overload data and historical maintenance information;

[0022] In this embodiment, based on acquired optical focus anomaly data, a spiral guide rail sensor monitors guide rail wear. The data from the spiral guide rail sensor is converted using a mechanical model to calculate the amount of guide rail wear. Specifically, the wear degree is first calculated based on the readings of the force sensor on the guide rail using a loaded standard wear data table. The wear value is then compared with the pressure change measured by the sensor and a standard wear curve to derive a quantitative value for the wear. Regarding the lifespan calculation of the optical lens module, based on the wear variation pattern and the service life of the lens module, a threshold is set such that when the wear degree reaches 10%, the lens module is considered to enter a warning state. Based on this warning information, the lens module lifespan is determined and dynamically adjusted. The focus compensation amplitude is further optimized. When the image blur exceeds a certain threshold (e.g., a focus error greater than 0.5mm), a compensation value is calculated. The compensation amplitude is optimized based on the current performance and wear degree of the optical module. Then, based on the compensation amplitude, the agent's historical database is queried, and the focus compensation algorithm in the database is invoked to find the focus compensation amplitude under similar historical conditions. By comparing historical data, the real-time compensation amplitude is obtained. At the same time, monitor whether computing power overload occurs during the entire retrieval process. If the system load exceeds 80%, record computing power overload data, including processor usage, memory usage, and other information, and save this information as performance monitoring data.

[0023] Step S3: Detect memory leaks based on the computing power overload data to obtain memory leak data; monitor the agent processor thermal anomaly based on the memory leak data to obtain processor thermal anomaly data;

[0024] In this embodiment, the computing power overload data is analyzed and memory leak problems are detected through the system performance monitoring tool. Specifically, a memory monitoring tool, such as Valgrind, is used to monitor the memory usage of the intelligent agent during operation. The computing power overload data is used as input, and by comparing the dynamic changes in memory, it is analyzed whether a memory leak occurs. The monitoring of memory leaks is achieved by checking the difference between memory allocation and recovery. If it is found that the number of memory allocations is inconsistent with the number of recovery, or there is a significant memory growth, it indicates that there is a memory leak. At this time, the relevant memory leak data, including the leak location, leak amount, etc., is recorded, and a memory leak log is generated. On this basis, the thermal anomaly of the intelligent agent processor is further detected. By monitoring the temperature data of the processor, if the temperature exceeds the set threshold (such as 80°C), it is determined to be a thermal anomaly. The detection of thermal anomalies is carried out by collecting data in real time through the internal temperature sensor. If the temperature exceeds the threshold, the thermal anomaly data is recorded. The data includes information such as timestamp, abnormal temperature value, sensor location, etc.

[0025] Step S4: Perform heat dissipation reinforcement learning decision adjustments on the processor thermal anomaly data based on historical maintenance information to obtain heat dissipation reinforcement learning decision data; perform path planning cognitive evolution based on the heat dissipation reinforcement learning decision data to generate path planning cognitive evolution data; transmit the path planning cognitive evolution data and the heat dissipation reinforcement learning decision data to the multimodal intelligent agent to perform the dual-engine collaborative training task.

[0026] In this embodiment, the device's response to a processor thermal anomaly is analyzed based on historical maintenance information. This historical maintenance information includes similar thermal anomaly events that occurred in the agent's past, as well as the cooling measures taken. This historical data is fed into a reinforcement learning model, which analyzes the effectiveness of different cooling solutions and selects the most appropriate cooling solution for the current situation. Specifically, historical maintenance information forms decision input data by analyzing processor parameters such as temperature changes, cooling efficiency, and energy consumption under different cooling conditions. After inputting this data, the reinforcement learning algorithm generates cooling reinforcement learning decision data, indicating the optimal cooling strategy. This decision data is then used to perform cognitive evolution of path planning. This cognitive evolution of path planning is optimized using a heuristic algorithm, setting appropriate evaluation functions and objectives, and planning the optimal path based on the current device state (such as processor temperature and workload). This path planning data is continuously optimized by the cognitive evolution algorithm to produce a path planning solution that best suits the current environment and task requirements. Finally, the cognitive evolution of path planning data and the cooling reinforcement learning decision data are transmitted to the multimodal agent to execute the dual-engine collaborative training task. The path planning data contains information such as target location, movement strategy, expected state, etc., and the heat dissipation reinforcement learning decision data contains recommended heat dissipation measures (such as increasing the cooling fan speed, changing the chassis heat dissipation layout, etc.).

[0027] Preferably, step S1 is specifically as follows:

[0028] Step S11: Acquire multimodal agent data and extract agent visual sensor images;

[0029] In this embodiment, image data is collected by the visual sensor module of the multimodal intelligent agent system. An RGB camera with a resolution of 1920×1080 pixels is used, and images are collected in 24-bit RGB format, and the acquisition frequency is set to 30 frames per second. In order to ensure the real-time and stability of image data transmission, the visual sensor transmits data with the control unit of the intelligent agent through protocols such as USB 3.0 or GigE Vision. After the image data is transmitted to the control unit, it will be converted and processed by image processing tools (such as OpenCV or PIL library), the original image data format will be converted into a standard format, and the brightness and contrast will be adjusted to ensure that the image meets the requirements of subsequent processing. After reading, each frame of the image will be stored as a two-dimensional array for subsequent analysis.

[0030] Step S12: Calculating the second-order derivative of the pixel based on the agent's visual sensor image;

[0031] In this embodiment, the detailed information of the image is analyzed by calculating the second-order derivative of each pixel. First, common methods such as the Sobel operator or the Laplacian operator are selected to calculate the horizontal and vertical changes of each pixel in the image respectively. The second-order derivative is obtained by differential operation on these changes. The Sobel operator is used to detect the edges and change areas of the image, and then the second-order derivative values are calculated using differential operation. These second-order derivative values reflect the curvature changes of the local area of the image and can help identify subtle changes in the image, especially in blurred or distorted areas. This process is implemented through an image processing library (such as the cv2.Sobel() function in OpenCV) to calculate the second-order derivative of each pixel in the image.

[0032] Step S13: determining the Laplace operator kernel according to the second-order derivative of the pixel point;

[0033] In this embodiment, the image details, especially the edge parts, are enhanced by applying the Laplace operator kernel to the calculated second-order derivative results. The Laplace operator kernel is usually a 3×3 or 5×5 matrix, which is used to perform convolution processing on the image. The kernel highlights the edges and changing areas of the image by performing weighted summation in the area around each pixel in the image. During the specific operation, the image is convolved with the Laplace kernel to calculate the response value of the image at each point. A larger response value indicates that there is a more drastic change in the image. In this way, parts of the image that change more greatly, such as edges or blurred areas, can be effectively identified. The cv2.filter2D() function in the OpenCV library can implement this convolution operation.

[0034] Step S14: identifying fuzzy and distorted regions of the agent's visual sensor image according to the Laplace operator kernel to generate a fuzzy and distorted image;

[0035] In this embodiment, after obtaining the Laplace response of an image, this information is used to identify blurry and distorted areas within the image. Blurry and distortion typically manifest as unclear edges or small grayscale variations. Therefore, a threshold is set to determine which areas within the image have a Laplace response below the threshold, and these areas are then marked as blurry and distorted areas. This threshold can be determined by calculating the mean or standard deviation of the image's Laplace response. For example, it can be set to the mean of the Laplace response minus a certain multiple of the standard deviation. Areas within the image that meet this condition are marked as blurry and distorted areas and extracted from the entire image. These marked blurry and distorted areas serve as input data for subsequent optical focus anomaly analysis.

[0036] Step S15: determining optical focus abnormality based on the blurred and distorted image, and generating optical focus abnormality data.

[0037] In this embodiment, optical focus anomalies are usually manifested as large-scale blurred areas in the image, and these blurred areas do not conform to the normal focus mode. By analyzing the size, distribution and shape of the blurred areas, combined with the optical characteristics of the lens, it is determined whether these areas are related to the lens focus deviation. If the sharpness of certain blurred areas is low and deviates from the standard focus mode, these areas are determined to be optical focus abnormality areas. By setting a certain sharpness threshold (for example, the sharpness index of the blurred area is lower than a certain value), it is determined whether there is an optical focus abnormality. Finally, the relevant data of these optical focus anomalies (such as abnormal position, deviation size, etc.) are recorded to generate optical focus abnormality data.

[0038] Preferably, step S15 is specifically as follows:

[0039] Step S151: When any of the following conditions occurs, it is determined to be a focus blur abnormality and focus blur abnormality data is obtained: the Laplace variance of the blurred and distorted image is less than 0.001, the clarity fluctuation exceeds 20%, and the clarity difference between the edge and center of the blurred and distorted image exceeds 30%;

[0040] In this embodiment, the Laplace variance of the blurred and distorted image is calculated. If the variance value is lower than 0.001, it means that the sharpness of the image is low, indicating that the detail information in the image is missing and there is obvious blur. In order to achieve this operation, it is first necessary to apply the Laplace operator to the blurred and distorted image, calculate the second-order derivative of each area of the image, and find the variance of the entire image. The variance calculation formula is the average of the square difference between the Laplace response of each pixel and the mean. When the variance is lower than the set threshold of 0.001, it is calibrated as a focus blur anomaly. Evaluate the image clarity fluctuation. If the fluctuation exceeds 20%, it is considered to be insufficient clarity, indicating a focus problem. The clarity fluctuation is calculated by comparing the clarity of consecutive image frames (for example, the edge strength calculated by Sobel filtering) to calculate the difference between consecutive frames. When the clarity fluctuation value is greater than 20%, it means that the image quality is unstable and there is a focus problem.

[0041] Step S152: When the following conditions occur simultaneously, it is determined that the focus abnormality is caused by a motor drive failure, and motor drive focus abnormality data is obtained: the VCM motor current fluctuation amplitude exceeds 15%, the motor stroke feedback deviates from the set focal length position by more than 10 μm, and the focus process response time exceeds 300 ms;

[0042] In this embodiment, the current fluctuation amplitude of the VCM (Voice Coil Motor) is monitored. If the current fluctuation amplitude exceeds 15%, it indicates that the motor is overloaded or has a control anomaly. The current fluctuation amplitude is calculated by performing time series analysis on the motor current signal, using methods such as fast Fourier transform (FFT) or peak analysis to calculate the current fluctuation amplitude. It is necessary to monitor whether the motor stroke feedback deviates from the set focal length position by more than 10μm. The motor stroke feedback signal is obtained through a position sensor (such as a Hall effect sensor), and the feedback value is compared with the set focal length. If the deviation exceeds 10μm, it indicates that the motor is not accurately focused, which is caused by a drive failure. At the same time, it is necessary to check whether the response time during the focusing process exceeds 300ms. The focus response time is measured by recording the time required for the motor to receive the control signal and complete the focusing action. If the response time exceeds 300ms, it indicates that the motor is sluggish and there is a fault. When the above conditions are met simultaneously, the system determines that the focus anomaly is caused by a motor drive failure and records the motor drive focus anomaly data for subsequent analysis and adjustment.

[0043] Step S153: When the following conditions occur simultaneously, it is determined that the focus abnormality is caused by the slide rail jamming, and the slide rail jamming focus abnormality data is obtained: the slide rail motion load change rate exceeds 25%, the slide rail displacement curve has an obvious stagnant section, and the local area imaging is blurred and shows discontinuous characteristics with position changes;

[0044] In this embodiment, the rate of change of the slide rail's motion load is calculated. If the load change rate exceeds 25%, it indicates that the slide rail's motion resistance is large, causing the slide rail to become stuck. The load change rate is calculated by collecting the current signal of the slide rail's drive motor and calculating it based on the signal's rate of change. If the load changes dramatically, it is considered that the slide rail is stuck. The slide rail's displacement curve needs to be monitored. If a clear stagnant section appears in the displacement curve, it indicates that the slide rail is obstructed during the focusing process, resulting in inconsistent focusing. The displacement curve is obtained using a slide rail position sensor (such as an encoder) and the curve's smoothness is analyzed. If the curve shows stagnation or abnormal fluctuations, it indicates that the slide rail is stuck. It is necessary to monitor whether the image in the local area is blurred and whether it exhibits discontinuous characteristics as the position changes. By comparing the image clarity at different positions, if the blurred area exhibits discontinuous characteristics as the slide rail moves at different positions, it indicates that the slide rail is stuck and affecting the focusing ability of the optical system. If these conditions are met simultaneously, the system determines that the focus anomaly is caused by slide rail sticking and records the relevant slide rail sticking focus anomaly data.

[0045] Step S154: Integrate the focus blur abnormality data, the motor drive focus abnormality data, and the slide rail stuck focus abnormality data to obtain the optical focus abnormality data.

[0046] In this embodiment, the integration of optical focus abnormality data needs to include focus blur abnormality data, motor drive focus abnormality data, and slide rail stuck focus abnormality data. Each abnormality data will be weighted according to its severity. For example, if the frequency of occurrence of motor drive failure abnormality is high and the impact is large, it will be given a higher weight, and vice versa. The integrated data will be classified according to logical judgment rules to form the final optical focus abnormality data. This data will be used for subsequent adjustments and optimizations, including improvements to the focus algorithm and detection and repair of hardware faults.

[0047] Preferably, the detection of the wear amount of the spiral guide rail in step S2 is specifically as follows:

[0048] Calculating an optical focus offset based on the optical focus abnormality data; calculating an optical focus speed based on the optical focus abnormality data; and reconstructing an optical focus trajectory based on the optical focus offset and the optical focus speed;

[0049] In this embodiment, optical focus anomaly data is obtained, which generally includes indicators such as image clarity, Laplace variance of blurred and distorted images, and focal length deviation of the optical system. The focal length offset is calculated by comparing the focal length of each frame image with the standard set focal length. The specific method is to obtain the real-time focal length through the image data captured by the image sensor, compare the set target focal length through the signal fed back by the sensor and the optical element, and calculate the difference between the two, which is the optical focus offset. The unit of the offset is usually micrometer (μm). If the data fed back by the sensor shows that the actual position of the optical element deviates from the set focal length by more than a predetermined threshold (such as 10μm), the offset will be recorded as the optical focus offset. In this process, the set threshold is crucial for judging the severity of the offset. The commonly used threshold is set to 10μm to capture larger focus deviations and adapt to different hardware conditions. The calculation of the optical focus speed is based on the rate of focal length change per unit time during the focusing process. First, based on the focal length offset and timestamp in the optical focus anomaly data, the focal length change in a continuous time period is obtained. The focal length change is calculated by calculating the focal length difference between two adjacent image frames, while the time difference is obtained from the image timestamp data, typically with millisecond accuracy. The optical focus speed is then calculated by dividing the focal length change by the time difference. The optical focus speed is measured in micrometers per second (μm / s). Normally, the optical focus speed should be between 20 and 50 μm / s. Any deviation outside this range indicates a hardware or control system failure, requiring further analysis. The optical focus offset and speed calculated previously are used to reconstruct the optical focus trajectory. First, the focus position at each moment is inferred from the timestamp data using the optical focus offset (in μm) and the optical focus speed (in μm / s). The relationship between the offset and speed is then used to calculate the focus trajectory between consecutive time points. The specific operation involves inferring the focal length change at each time point based on the time interval. These focal length changes are then linked together to form a complete focus trajectory. This process is accomplished through interpolation methods, such as linear interpolation or spline interpolation, to generate a smooth focus trajectory based on the collected data points. The reconstructed optical focus trajectory is then compared with a preset standard focus trajectory to determine if there is any deviation in the optical system.

[0050] Perform offset guide rail identification according to a preset optical focus standard track and an optical focus track to obtain offset guide rail data;

[0051] In this embodiment, the preset optical focus standard trajectory is a trajectory designed based on the optical focus behavior under normal working conditions. By comparing the reconstructed optical focus trajectory with the standard trajectory, the deviation between the two is detected. First, the distance difference between the reconstructed trajectory and the standard trajectory is calculated. If the difference exceeds the set threshold (for example, 10μm), it is considered that an offset has occurred. The offset is detected by calculating the Euclidean distance between the trajectory points. When the distance exceeds the predetermined threshold, it is considered that an offset guide rail has occurred. The record of the offset guide rail data includes the time, position and offset of the offset. These data will be used in the subsequent spiral guide rail reverse solution step. The offset guide rail data helps to diagnose the root cause of inaccurate focusing of the optical system, such as guide rail wear, mechanical deformation, etc.

[0052] Reversely solve the guide rail shape based on the offset guide rail data to obtain the spiral guide rail data;

[0053] In this embodiment, the geometric shape of the guide rail is inversely calculated using each trajectory point in the offset guide rail data. This operation generally relies on a known guide rail geometric model, such as the mathematical model of a spiral guide rail. By analyzing the relationship between the offset trajectory points and the guide rail design model, the shape change of the guide rail can be inferred. For example, the trajectory points can be fitted using the least squares method or interpolation algorithm to derive the spiral shape of the guide rail. The spiral guide rail data will include parameters such as the starting position and ending position of the spiral, the rotation angle of the spiral, and the pitch of the spiral. This data is of great value for subsequent wear calculations and mechanical repairs.

[0054] Calculate the pitch change based on the spiral guide rail data; calculate the spiral change angle based on the spiral guide rail data;

[0055] In this embodiment, the pitch change reflects the degree of deformation of the spiral guide during use, especially after wear or long-term use, the change in pitch has a direct impact on the optical focus accuracy. Pitch calculation is usually achieved by analyzing the change in distance between two adjacent points in each complete spiral cycle of the spiral guide. If the pitch changes significantly, it means that the guide rail has been worn or deformed. The pitch change can be obtained by calculating the distance difference between two adjacent points in the spiral trajectory. If the difference exceeds a set standard (such as 0.1μm), it is considered that there is a significant pitch change. The spiral change angle refers to the angular offset or distortion that occurs in the spiral guide during use. By analyzing the geometric data of the spiral guide, the angular change of each part of the spiral line is calculated. After long-term use, the spiral guide will cause the spiral angle to change due to wear or mechanical fatigue. The spiral change angle is calculated by measuring the rotation angle change at different positions on the guide rail. This angle can be obtained by discretizing the geometric shape of the guide rail and calculating the angular difference between adjacent segments. If the angle change exceeds a predetermined threshold (for example, 2°), it is calibrated as deformation or damage to the guide rail.

[0056] The wear of the spiral guide rail is determined based on the pitch change and the spiral angle change.

[0057] In this embodiment, the wear amount is calculated by combining the pitch change with the helical angle change to produce a comprehensive wear index. The weighted average of the pitch change and helical angle change is calculated to determine the overall degree of wear. The specific value of the wear amount can be set based on a wear threshold. For example, if the comprehensive wear index exceeds a set threshold (e.g., 0.2 μm), the guide rail is considered to be at a level requiring repair or replacement.

[0058] Preferably, the lens module life is determined in step S2 as follows:

[0059] Identify high-wear guide rail areas based on the amount of helical guide rail wear;

[0060] In this embodiment, the pitch change and spiral angle are calculated based on detailed measurement data of the spiral guide rail. Both the pitch change and spiral angle are output from the measurement results and can reflect the wear condition of the spiral guide rail surface. Based on this data, a threshold is set. When the wear exceeds the preset threshold, the area is judged to be a high-wear guide rail area. The threshold can be set based on equipment usage and wear standards. For example, if the pitch change exceeds 0.02mm or the spiral angle exceeds 2°, the area is judged to be a high-wear area.

[0061] Use vibration sensors to continuously monitor the rail vibration in high-wear rail areas to obtain rail vibration data; extract high-frequency rail vibration data based on the rail vibration data;

[0062] In this embodiment, vibration sensors are installed in the high-wear guide rail area and vibration data is collected in real time. These sensors are used to monitor the vibration of the guide rail during operation, and the collected data can reflect the vibration characteristics of the guide rail under different working conditions. Vibration data includes parameters such as vibration frequency, amplitude and duration. The data acquisition frequency can be set to 100Hz to 1000Hz. The appropriate sampling frequency is selected as needed to ensure the accuracy of the data. High-frequency vibration data is extracted by performing spectral analysis on the collected vibration data. High-frequency vibrations are usually related to small vibrations or local anomalies of the guide rail. Signal processing techniques such as fast Fourier transform (FFT) are used to extract vibration data with a frequency above 200Hz. These high-frequency data are helpful to further analyze the microscopic changes and fault signs of the guide rail.

[0063] Guide rail warpage is identified in high-wear guide rail areas based on high-frequency guide rail vibration data to obtain guide rail warpage data;

[0064] In this embodiment, time-domain and frequency-domain analysis are performed on high-frequency vibration data to extract key characteristics of guide rail vibration. Time-domain analysis analyzes the instantaneous fluctuations of the signal by calculating parameters such as the mean, variance, peak value, and root mean square (RMS) value of the vibration signal, revealing abnormal vibration patterns. Frequency-domain analysis uses methods such as the Fast Fourier Transform (FFT) to convert the vibration signal from the time domain to the frequency domain and analyze the signal's spectral distribution. The characteristics of guide rail warpage are typically manifested as significant changes in vibration amplitude within a specific frequency range. In particular, when localized warping or unevenness occurs on the guide rail surface, the vibration amplitude can experience sudden or discontinuous changes. Frequency-domain analysis can effectively identify these frequency characteristics. Next, warpage characteristics are identified based on predefined criteria (e.g., changes in vibration amplitude exceeding a certain threshold or frequency peak shifts exceeding a predetermined range). These criteria can be derived through experiments and analysis of historical data to ensure the accuracy of the identification process. Machine learning algorithms, such as support vector machines (SVMs) or k-nearest neighbor algorithms (KNNs), are then used to classify and identify the vibration data. First, these algorithms are trained on vibration data from normal and warped guide rails to establish a classification model. New vibration data is then fed into the model to automatically determine whether the guide rail is warping. By analyzing abnormal fluctuations in vibration amplitude and frequency changes, the specific location and extent of warping are identified, and further data on the warping is generated. This data serves as the basis for subsequent analysis and prediction, helping the system understand the health of the guide rail and its risk of failure.

[0065] Perform lens module motion simulation based on the guide rail warping data to generate lens module motion data;

[0066] In this embodiment, the guide rail warping data is input into a pre-established kinematic model. The model needs to fully consider the impact of guide rail irregularities on the motion of the lens module. The guide rail warping data provides specific information about the unevenness of the guide rail surface, such as the direction, magnitude, and distribution of local warping. This information will serve as input parameters for the model. During the simulation process, the design parameters of the lens module, including the module's weight, dimensions, moment of inertia, and coefficient of friction, need to be input into the model. By considering these parameters, the model can simulate the motion trajectory of the lens module under actual operating conditions. Specifically, the model calculation process includes using classical dynamic equations such as the Newton-Euler equation, combined with the influence of guide rail warping, to infer the module's kinematic parameters such as displacement, velocity, and acceleration at each moment. For the moment of inertia, the model considers the lens module's geometry and mass distribution to calculate the module's rotational behavior when moving on the warped guide rail. The setting of the friction coefficient affects the lens module's motion resistance and affects changes in acceleration and velocity. These kinematic calculations reveal the module's actual motion on the guide rail, including trajectory deviations, velocity changes, and acceleration fluctuations. Using these calculations, the model generates lens module motion data describing its specific motion on the warped guide rail, providing essential data support for subsequent mechanical analysis, friction calculations, and resistance assessments.

[0067] Calculating the friction of the lens module according to the motion data of the lens module; Calculating the resistance of the lens module according to the motion data of the lens module;

[0068] In this embodiment, the friction force is calculated by a kinematic formula based on the movement of the lens module on the guide rail. The calculation of the friction force needs to take into account parameters such as the mass of the lens module, the movement speed, and the friction coefficient of the guide rail surface. The friction coefficient can be measured experimentally, and the common friction coefficient value is between 0.1 and 0.5. According to the speed and mass of the lens module, combined with the friction coefficient of the guide rail surface, the friction value at each time point is calculated. The resistance calculation is based on the motion characteristics of the lens module, taking into account air resistance, guide rail friction, and friction of the internal structure of the module. The air resistance can be estimated by parameters such as air flow rate, module surface area, and air density, and the guide rail friction and internal friction are derived through a friction model. All these resistance factors will affect the motion state of the lens module, and detailed physical modeling is required according to the specific situation of the lens module.

[0069] Determine the lens module workload based on the lens module friction and lens module resistance;

[0070] In this embodiment, the friction and resistance at each moment are calculated based on the motion state of the lens module. The calculation of friction is based on the contact conditions and friction coefficient of the lens module when it moves on the guide rail. Specifically, friction is equal to the product of the normal pressure on the contact surface and the friction coefficient. The normal pressure is calculated based on the mass distribution and acceleration of the module (provided by the lens module motion simulation data). Resistance includes additional resistance from air resistance, friction from the module's internal components, and irregularities on the guide rail surface. The calculation of air resistance can be determined based on the module's speed, size, and air flow resistance coefficient. For the friction resistance on the guide rail surface, the effect of guide rail warping on module motion must be considered, as an uneven guide rail surface will increase friction resistance. After the friction and resistance at each moment are calculated, the total resistance at each moment can be calculated using the overall mechanical model in combination with the motion state of the lens module (including the module's speed, acceleration, and motion trajectory). The total resistance is the composite value of all resistance components, including friction, air resistance, guide rail surface friction, and other resistance. Next, the workload calculation will be based on the total resistance combined with the speed and acceleration of the module. The workload reflects the total load on the lens module during the entire movement process, and is determined by considering the energy required to counter the resistance during the movement of the lens module. The workload can be obtained by integrating the resistance at each moment and the motion state of the module. The calculation formula is workload = ∑ (resistance × speed), where the values of resistance and speed are calculated based on the real-time state of the lens module. The calculation process requires parameters such as friction, resistance, speed, acceleration, etc. as input to obtain the total workload borne by the lens module during the entire movement process. This value will help to evaluate whether the lens module is overloaded during the movement process and its impact on the life of the module, providing a basis for further optimization of the design and health monitoring.

[0071] Predict lens module life based on lens module workload.

[0072] In this embodiment, the lens module's workload is obtained through the aforementioned steps. It is the sum of the resistance and friction experienced by the lens module during motion, reflecting the module's load condition. Based on this workload, combined with the fatigue properties of the lens module's materials, the module's remaining life can be estimated. According to fatigue theory, a material's fatigue life is closely related to the magnitude, frequency, and number of historical loading events. Specifically, fatigue life prediction can be performed by calculating the cyclic stress changes during the module's use and, combined with material properties such as Poisson's ratio and yield strength, using empirical formulas to estimate the lifespan. The fatigue life calculation formula is typically based on an SN curve (stress-life curve), where S represents the load stress and N represents the number of cycles the material experiences under that stress. Historical operating data can be used to extract the module's workload changes at various time periods, calculate the stress level corresponding to the workload, and then perform a lifespan prediction based on this stress level and the material's fatigue strength. Lifespan prediction can also be performed based on the thermal stress generated by the lens module during operation. During lens module motion, friction and other resistance forces generate a certain amount of heat, causing the module's internal temperature to rise. This temperature change affects the material's stress state, thereby affecting its fatigue life. Thermal stress can be calculated by combining the heat conduction model with the stress-strain model. Thermal stress will affect the yield strength and fatigue limit of the material, thereby affecting the life of the module.

[0073] Preferably, the reasoning for optimizing the focus compensation amplitude in step S2 is specifically as follows:

[0074] Calculate the historical wear of the lens module based on the life of the lens module;

[0075] In this embodiment, the usage data of the lens module is collected, including parameters such as its working time, working environment temperature, humidity and vibration. These data help determine the load of the lens module under different conditions. By analyzing these data and combining the structure and material properties of the lens module, the wear amount of the lens module throughout its life cycle is calculated. This wear amount is usually proportional to the usage time of the module, and the impact of the working environment of the lens module on wear needs to be considered. For example, in a high humidity or high temperature environment, the wear rate of the lens will usually accelerate. Therefore, based on the working time and environmental conditions of the lens, a historical wear amount is obtained, which reflects the degree of wear of the lens module.

[0076] Convert the historical wear of the lens module into the first loss of focus accuracy;

[0077] In this embodiment, the process of converting the historical wear of the lens module into the first loss of focus accuracy requires first obtaining the lens module's design data and geometry, specifically the dimensions and shapes of its various components. Lens module wear is typically manifested in locations such as the lens surface coating, the optical coating on the lens, and the contact surfaces of the lens' moving parts. By calculating the historical wear, wear data for the lens module during use can be obtained. This data includes the lens module's operating time, usage environment, and actual wear. Based on this data, the geometric dimensions of the lens module are first analyzed to determine how wear affects focus-related components, such as the lens's focus ring and the position of optical elements. Each wear data item reflects the dimensional change of the corresponding component, which directly affects the lens' optical performance and, in turn, the focal length. This change in focal length can lead to a loss in focus accuracy. Next, through experimental data or simulation analysis, a corresponding relationship between wear and focal length change is gradually established. This relationship is typically verified by measuring the blurriness of captured images. Specifically, when lens wear reaches a certain level, the loss of focus accuracy can be quantified by measuring the sharpness or blurriness of the captured image. The combination of experimental data and simulation analysis helps to establish a mathematical relationship between wear and focus loss. Finally, based on this relationship, the historical wear can be converted into the loss of focus accuracy, and on this basis, the degree of degradation of the lens's imaging quality can be evaluated. In this way, the accurate conversion from the historical wear of the lens module to the loss of focus accuracy can be achieved, providing a basis for subsequent focus compensation. Obtain humidity sensing data; screen low-life lens modules based on the life of the lens module, and simulate the optical coating corrosion of the low-life lens module based on the humidity sensing data to obtain optical coating corrosion data;

[0078] In this embodiment, humidity data is collected in real time using humidity sensors installed in the lens module's operating environment. These sensors are typically installed around the lens module and are capable of detecting changes in relative humidity. Humidity sensors operate by sensing the water vapor content in the air and outputting an electrical signal proportional to the humidity. High sensor accuracy is required, typically requiring a high-precision sensor that can respond to humidity changes in real time, with an accuracy of up to 1% relative humidity. The acquired humidity data is recorded in a time series format to provide input for subsequent optical coating corrosion simulations. This data helps understand the impact of humidity changes on the lens module's optical properties, particularly the degree of corrosion of the lens coating. By analyzing the lens module's cumulative operating hours and actual wear, it is determined whether the lens is nearing the end of its service life. Specifically, when the wear of a lens module reaches a preset threshold, or when the module's operating time exceeds a set life expectancy, the lens module is considered to have a low lifespan. For example, a lens module is marked as having a low lifespan if its operating time exceeds 1500 hours or if the wear reaches a certain threshold. By regularly monitoring the operating status of lens modules, those with low lifespans can be promptly identified, allowing for further corrosion simulation and reflectivity assessment. Humidity has a significant impact on the coating of lens modules, particularly in low-lifespan modules, where changes in humidity accelerate corrosion. A corrosion model is used to simulate the corrosion process of lens coatings based on real-time humidity data captured by humidity sensors. The corrosion simulation involves inputting humidity data into a specific corrosion rate model and predicting the degree of coating degradation based on humidity fluctuations. The simulation results will reflect the impact of humidity on the coating, helping to determine changes in coating thickness and the presence of corrosion signs under different humidity conditions. This simulation not only considers humidity but also incorporates environmental factors such as temperature to predict coating corrosion. The impact of humidity fluctuations on coating corrosion forms the basis for calculating lens reflectivity and focal length shift.

[0079] Calculate lens reflectivity based on optical coating corrosion data;

[0080] In this embodiment, based on the data obtained from the optical coating corrosion simulation, the degree of corrosion of the coating layer can be assessed and the reflectivity of the lens can be calculated. As the coating layer corrodes, the reflectivity of the lens gradually decreases. Based on the degree of corrosion, combined with the design parameters of the optical lens, the changes in the optical properties of the coating layer can be evaluated. For example, by analyzing the light transmittance and reflectivity of the coating at different corrosion stages, the reflectivity of the lens in actual use can be calculated. Changes in reflectivity affect the optical performance of the lens, and thus the focal length and image quality. Therefore, this data will directly affect the subsequent focal length shift assessment.

[0081] Evaluate focus shift based on lens reflectivity;

[0082] In this embodiment, the focal length offset of the lens can be assessed based on the measured reflectivity change data. When the reflectivity decreases, the focusing ability of the lens changes, causing the focal length to shift forward or backward. Through experimental data and optical simulation, a relationship between reflectivity and focal length offset is established. When the reflectivity change exceeds a certain critical value, the focal length offset of the lens can be determined. This assessment process, based on the lens' optical design as well as corrosion and wear data, provides a basis for subsequent compensation strategies.

[0083] The focus compensation amplitude is optimized according to the focal length offset and the first loss of focus accuracy.

[0084] In this embodiment, the compensation amplitude is dynamically adjusted based on the magnitude of the focal offset and the loss of focus accuracy. The effects of focal offset are compensated by adjusting the position of the focus lens or the control parameters of the autofocus system. In practice, the most appropriate compensation amplitude should be calculated based on the accuracy requirements of the autofocus system and the adjustment capabilities of the lens module. When the focal offset is large, the compensation amplitude should be increased to ensure that imaging accuracy returns to the standard level.

[0085] Preferably, step S2 of monitoring computing power overload during the retrieval process is specifically as follows:

[0086] Based on the focus compensation amplitude, the agent history database is retrieved to obtain historical maintenance information;

[0087] In this embodiment, the focus offset amplitude is used as a query condition to search the agent's historical database for maintenance information related to this amplitude. Each record in the historical database includes the repair time, repair category, the type of hardware or software failure involved, and the environmental conditions under which the failure occurred. Database design requires structured and standardized data to facilitate fast and efficient retrieval of relevant data. To implement the query, advanced query capabilities in SQL or NoSQL databases are used, combined with keyword searches for focus offset amplitude, to accurately match historical maintenance information.

[0088] The CPU usage during the collection and retrieval of the agent's history database;

[0089] In this embodiment, when collecting CPU usage during the process of searching the agent's historical database, the CPU usage is recorded in real time by a monitoring system. Typically, the real-time CPU load is obtained using an operating system performance monitoring tool (such as the Windows Task Manager or the Linux top command). CPU usage data is typically expressed as a percentage and is recorded each time the database is searched. This data can provide information about resource usage during the search process, thereby reflecting the system's performance bottlenecks and resource consumption during specific query operations.

[0090] Allocate multi-core computing resources according to CPU usage to obtain multi-core computing resource allocation data;

[0091] In this embodiment, the step of allocating multi-core computing resources according to CPU usage relies on real-time monitoring data of CPU usage, and combines the hardware architecture of the multi-core processor to divide the computing tasks into multiple threads. Each thread corresponds to an independent computing task, and these tasks are reasonably allocated according to the number of CPU cores. The principle of computing resource allocation is to distribute tasks to multiple cores as evenly as possible to improve the efficiency of parallel computing. A load balancing algorithm (such as a round-robin algorithm, a minimum load algorithm, etc.) is used to determine the amount of computing tasks executed on each core, while ensuring that some cores are not overloaded while other cores are idle. The allocation process also needs to consider the constraints of resources such as memory bandwidth and cache to avoid excessive resource contention.

[0092] Evaluate parallel computing efficiency based on multi-core computing resource allocation data;

[0093] In this embodiment, the effect of parallel computing is evaluated by comparing the computing execution time and the degree of completion of computing tasks before and after multi-core allocation. The evaluation standard for parallel computing efficiency is the acceleration ratio of the computing task, that is, the ratio of the time required to complete the task in multi-core processing to the time required to complete the task in single-core processing. When the acceleration ratio is close to the number of cores, it means that the allocation of computing resources is relatively ideal. If the acceleration ratio is much lower than the number of cores, it indicates that there is uneven resource allocation or bottlenecks between computing tasks. In this step, performance analysis tools (such as Intel VTune, GProf, etc.) can be used to collect the execution time data of the computing tasks and perform detailed analysis.

[0094] Identify register conflicts based on parallel computing efficiency and obtain register conflict data;

[0095] In this embodiment, when identifying register conflicts based on parallel computing efficiency, the register usage of each core is monitored to detect whether there is a register access conflict. Register conflicts usually occur when multiple threads access the same register at the same time, or when the register data is not refreshed or written back in a timely manner during parallel computing. Hardware performance counters (such as Intel Processor Trace or AMD Performance Counters) can be used to monitor register usage and identify conflict issues through set thresholds (such as the number of register access conflicts or data synchronization delays between threads). The severity and scope of register conflicts need to be quantified through detailed performance testing.

[0096] determining a register overflow degree based on the register conflict data;

[0097] In this embodiment, when determining the degree of register overflow based on register conflict data, the risk of register overflow must be assessed based on the register conflict data and the execution of the computing task. Register overflow generally refers to the situation where the amount of data stored in a register exceeds its storage capacity during the calculation process, resulting in data loss or incorrect calculation. The degree of overflow is assessed based on the number of register overflows and the impact of the overflow data on the calculation results, combined with a comprehensive analysis of the register usage of each core. Data collected using hardware counters will be used to analyze the utilization of each register. If the utilization of a register reaches or approaches its maximum capacity, it indicates an overflow risk.

[0098] Evaluate computing power overload based on the degree of register overflow and obtain computing power overload data.

[0099] In this embodiment, when evaluating computing power overload based on the degree of register overflow, the overall computing power load is calculated by evaluating the register usage and overflow of each core. Computing power overload refers to the execution of computing tasks exceeding the computing power of the system, resulting in slower computing speed or inability to complete the task. When evaluating computing power overload, first determine the maximum processing capacity of the system (that is, the maximum number of tasks that the system can handle or the maximum task complexity), and then determine whether the system has reached the critical point of computing power overload based on the degree of register overflow and resource usage. A threshold can be set in specific operations. For example, when the CPU utilization exceeds 80% at a certain moment, the register overflow exceeds 10 times / second, or the execution time of the computing task exceeds the expected value, it is judged as computing power overload.

[0100] Preferably, step S3 is specifically as follows:

[0101] Step S31: Monitoring memory consumption trends based on computing power overload data;

[0102] In this embodiment, it is necessary to obtain the computing power overload data of the system. This data is usually collected in real time through system monitoring tools (such as Linux's top command, Windows Task Manager, or dedicated performance monitoring tools). Specifically, when obtaining computing power overload data, it is first necessary to determine the moment when the computing load exceeds the system's predetermined load threshold. The system status corresponding to these moments will affect the memory consumption trend, especially in multi-core parallel computing, where memory usage tends to increase with the increase in computing power demand. By collecting memory usage, CPU load, and task progress information at different time points, a trend curve of memory consumption can be drawn. In order to obtain accurate memory consumption trends, it is necessary to set timed monitoring points during system operation, for example, recording memory consumption data every 1 second or every 500ms. The changing trend of memory usage can be further processed by linear regression or smoothing (such as moving average) to ensure that stable and reliable trend data is obtained.

[0103] Step S32: Calculate the memory release amount according to the memory consumption trend;

[0104] In this embodiment, the memory release demand at the next moment or within a certain time period is predicted by analyzing the time series data of memory consumption. There is usually a certain regularity in the increase and decrease of memory consumption. Therefore, in combination with past memory consumption data, the timing of memory release and the amount of memory required to be released can be identified by fitting the trend curve. Specifically, the calculation of the memory release amount is based on the following factors: current memory consumption, last memory consumption and predicted memory growth trend. When the opportunity of memory release occurs, the amount of memory that should be released is calculated and stored for subsequent analysis. In order to accurately calculate the memory release amount, the algorithm used includes a time series analysis method such as an ARIMA model, or a memory prediction method based on a cache management strategy to ensure the accuracy of the memory release amount.

[0105] Step S33: determining a memory release address based on the memory release amount;

[0106] In this embodiment, the usage of the current memory block is monitored by a memory management system (such as the memory allocation module of the operating system). When memory consumption increases and reaches a set threshold, the operating system will mark it as a memory area to be released. These memory areas will be recorded and rely on the memory management mechanism of the operating system, such as stack or heap memory recovery. Based on historical memory allocation data, memory leak detection tools (such as Valgrind, AddressSanitizer, etc.) can be used to determine which memory areas have not been correctly released. These tools will record the allocation and release addresses of each memory block, and determine the memory blocks that are not currently released based on changes in memory consumption. The memory management system will mark the addresses that need to be released based on this information.

[0107] Step S34: performing memory duplicate allocation analysis based on the memory release address to obtain memory duplicate allocation data;

[0108] In the present embodiment, memory duplicate allocation usually occurs when the same block of memory is frequently allocated and released, which can lead to fragmentation or waste of resources. In this step, by analyzing the life cycle of the memory block (allocation time, release time, allocation size, etc.), it is determined whether there is a phenomenon of duplicate allocation. By using tools (such as malloc_info, gperftools and other memory analysis tools), the allocation and release process of each block of memory can be tracked to identify whether there is a situation of memory duplicate allocation. In particular, memory duplicate allocation data can be detected by monitoring the frequency of multiple allocation and release operations of the same memory address. If the number of allocation and release times of a certain memory address exceeds a preset threshold (for example, more than 5 times), it is considered that there is duplicate allocation.

[0109] Step S35: performing memory leak detection based on the memory duplicate allocation data to obtain memory leak data;

[0110] In this embodiment, detailed data of all memory allocations is obtained based on a memory management tool, including the memory allocation address, allocation time, release time, etc. By comparing the records of memory allocation and release, it is determined whether there is a phenomenon in which memory allocation is not released in time. Memory leaks usually occur when a program cannot correctly release the allocated memory, resulting in the memory being occupied and unable to be recovered. Detecting memory leaks requires continuous monitoring of the life cycle of memory blocks, and using memory leak detection tools (such as Valgrind, LeakSanitizer, etc.) to detect memory leak points. Through these tools, detailed information of each unreleased memory block can be obtained, including the size of the memory block, the allocation location, and the leak path. The standard for memory leaks is that if the total amount of unreleased memory exceeds a certain threshold (such as 10MB) within a specified time window (such as within 5 minutes), it is determined to be a memory leak.

[0111] Step S36: Monitor the thermal anomaly of the intelligent agent processor based on the memory leakage data to obtain processor thermal anomaly data.

[0112] In this embodiment, the temperature change of the processor is detected by a temperature sensor and a monitoring system. Processor thermal anomalies usually occur when the CPU usage is high and the memory leak is serious, and the system will have excessive power consumption and heat accumulation. In order to detect this problem, a thermal anomaly detection threshold is set in combination with the degree of memory leakage and the real-time temperature data of the system. For example, when the temperature of the processor exceeds 80°C and the system load reaches more than 90%, the system should trigger a thermal anomaly alarm. The processor temperature is monitored in real time through a temperature monitoring tool (such as a hardware monitoring tool lm-sensors or IntelPower Gadget), and combined with the memory leakage data, it is analyzed whether the processor has a thermal anomaly due to excessive load and memory leakage. In the process of collecting processor thermal anomaly data, it is necessary to continuously monitor the data output by the temperature sensor and synchronize it with the system load data to determine whether there is a risk of thermal anomaly.

[0113] Preferably, step S36 is specifically as follows:

[0114] Step S361: Calculate memory occupancy time based on memory leak data;

[0115] In the present embodiment, the step of calculating memory occupancy time first needs to obtain detailed memory allocation and release records. These records are usually generated by memory management tools (such as Valgrind, gperftools or the built-in memory monitoring mechanism of the operating system) and include the allocation address, allocation time, release time and allocation size of the memory block. For each allocated memory block, by calculating the time difference between allocation and release, the occupancy time of each memory block can be obtained. In order to further analyze memory leaks, it is necessary to compare the release time of each memory block with the changing trend of the total amount of memory in the system. When memory allocation occurs but is not released in time, it is possible to calculate its total occupancy time by continuously tracking these unreleased memory blocks. If within a certain time period (such as 10 seconds, 1 minute), the memory block is still not released, then the block is marked as leaked memory, and its cumulative occupancy time is calculated. For example, if a memory block is not released for more than 10 seconds after allocation, the occupancy time of the memory block is calculated cumulatively.

[0116] Step S362: predicting the probability of triggering garbage collection based on the memory usage time;

[0117] In this embodiment, the probability of triggering garbage collection is predicted based on the memory occupancy time. First, a memory management model needs to be established to evaluate the possibility of garbage collection based on the known garbage collection mechanism and memory occupancy time. Memory recycling systems (such as JVM or custom memory management systems) usually rely on memory occupancy and allocation rate to trigger recycling events. By statistically analyzing the historical data of memory occupancy time, a trigger threshold is set. For example, when the memory occupancy exceeds a set ratio (such as 80%) and the memory occupancy duration exceeds 10 seconds, the system will start the garbage collection mechanism. In order to improve the prediction accuracy, a simple regression model or time series analysis model can be trained based on historical memory consumption data, using parameters such as the total amount of memory allocated, current memory occupancy, memory occupancy duration, etc. as input to predict the probability of triggering garbage collection. If the memory occupancy in a certain period of time is continuously monitored to exceed the preset threshold and the memory is continuously not released, the prediction model will calculate the probability of triggering garbage collection within that period.

[0118] Step S363: Evaluate the processor load pressure based on the garbage collection trigger probability;

[0119] In this embodiment, the processor load pressure is generally determined by the CPU workload and memory usage. The timing of garbage collection triggering has an important impact on the CPU load, especially when the memory usage is high and the garbage collection is triggered frequently. In order to evaluate the processor load pressure, it is first necessary to obtain the current CPU usage, memory usage, and the probability of garbage collection triggering. By monitoring the relationship between CPU usage and memory usage, it is possible to infer how the processor load pressure changes when garbage collection is triggered. An increase in CPU load is usually manifested as the CPU usage continuously exceeding a set threshold (for example, 90%), at which time memory recycling will cause instantaneous high CPU load work. By real-time monitoring and analysis of the triggering of garbage collection, the triggering probability can be associated with the CPU load. If the probability of garbage collection triggering is high (for example, more than 70%), it can be considered that the processor load will be significantly affected and the load pressure will exceed the maximum carrying capacity of the processor.

[0120] Step S364: Counting the processor heat according to the processor load pressure;

[0121] In this embodiment, the heat generated by the processor is closely related to its load pressure. When the processor load increases, especially when performing high-load calculations or frequently triggering garbage collection, the power consumption and heat of the processor will also increase. In order to count the heat of the processor, it is first necessary to obtain the real-time power consumption data of the processor. The processor power consumption data can be obtained through hardware monitoring tools (such as Intel Power Gadget, AMD Ryzen Master) or the power consumption monitoring module of the operating system. These tools can provide processor temperature and power consumption information. When the CPU usage is high, the power consumption and heat will also increase accordingly. When counting the heat of the processor, by combining the CPU usage and power consumption, an approximate heat value can be obtained. For example, if the power consumption of the processor is 50W and the CPU usage is 90%, the heat it generates is approximately 45W. By calculating the heat changes of the processor in real time, data support can be provided for subsequent heat management and anomaly detection.

[0122] Step S365: Obtaining processor heat dissipation efficiency data;

[0123] In this embodiment, the heat dissipation efficiency of the processor is generally determined by its heat dissipation system (such as a fan, heat pipe or liquid cooling system). When obtaining heat dissipation efficiency data, it is first necessary to rely on the hardware monitoring system to record the relationship between the temperature change of the processor and the working conditions of the heat dissipation system. For example, using a heat dissipation management tool (such as lm-sensors, hwmon), you can monitor the real-time data of the processor temperature and infer the heat dissipation efficiency based on the temperature change rate. When the processor load is high, the heat dissipation system needs to improve its efficiency to keep the temperature within a safe range. By monitoring the changes between the temperature and the processor load, the efficiency of the heat dissipation system can be inferred. Assume that when the processor load reaches 100%, the temperature rises by 10°C, which means that the efficiency of the heat dissipation system is relatively high; if the temperature changes slowly, the heat dissipation system needs to be optimized. Specific heat dissipation efficiency data can be obtained through the temperature change rate and the system's heat dissipation parameters (such as fan speed, heat pipe efficiency).

[0124] Step S366: Assess the intelligent agent's processor thermal anomaly based on the processor heat dissipation efficiency data and the processor heat to obtain processor thermal anomaly data.

[0125] In this embodiment, the intelligent agent processor thermal anomaly is evaluated based on the processor heat dissipation efficiency data and the processor heat. First, a processor temperature threshold needs to be set. For example, when the processor temperature exceeds 80°C, it is considered that the temperature is too high and there is a risk of thermal anomaly. Combined with the heat dissipation efficiency of the processor, if the processor temperature rises rapidly under high load conditions and the heat dissipation system cannot effectively reduce the temperature, it can be inferred that there is a thermal anomaly. By comprehensively analyzing the heat dissipation efficiency and the temperature change rate, when the temperature exceeds the safe range and the heat dissipation efficiency is insufficient, the system will mark it as a thermal anomaly and trigger an alarm. In order to further accurately evaluate the occurrence of thermal anomalies, the heat accumulation of the processor is calculated through a mathematical model in combination with the real-time processor power consumption and load data. If the heat accumulation exceeds the safety threshold specified by the system (for example, the accumulated heat exceeds 100J per minute), it can be determined that the processor has a thermal anomaly and the processor thermal anomaly data is recorded.

[0126] Preferably, step S4 is specifically as follows:

[0127] Step S41: extracting load balancing information based on historical maintenance information;

[0128] In this embodiment, the first step in extracting load balancing information is to collect historical maintenance information, which is typically recorded through equipment monitoring systems, fault reports, maintenance logs, and other means. Each maintenance record typically includes the time the equipment fault occurred, the fault type, the maintenance operation, and the impact on the system load during the repair process. Based on this historical data, it is first necessary to calibrate the various computing nodes involved in the repair process (e.g., processors, memory, hard drives, etc.). For these nodes, their load conditions are analyzed, and the load distribution during different fault repairs is analyzed. Load balancing information is extracted by monitoring system data such as load average, CPU utilization, memory utilization, and network load. This information is stored as time series data and statistically analyzed using data analysis tools. Through time series analysis, the load balancing strategy for each node under specific conditions can be extracted, and load fluctuations and overloads can be identified. To further optimize the load balancing strategy, it is necessary to use visual methods such as charts or heat maps to display the load trends of different nodes and derive node load distribution rules based on this. These rules facilitate further analysis of how to achieve load balancing optimization among processors and other resources.

[0129] Step S42: identifying a processor node based on the processor thermal anomaly data; and determining node computing capacity based on the processor node;

[0130] In this embodiment, a temperature monitoring system (e.g., using tools such as temperature sensors and lm-sensors) is required to obtain processor temperature data. This data can reflect the processor load and its thermal anomalies. When the processor temperature exceeds a predetermined threshold (e.g., 90°C), a thermal anomaly is considered to have occurred, affecting computing power. By monitoring the temperature history of each processor node and combining it with system load data, the extent of processor performance degradation can be determined, thereby identifying nodes experiencing thermal anomalies. Based on the workload of the processor node and its thermal anomaly, the computing power of the node needs to be further calculated. This is usually assessed by analyzing comprehensive indicators such as the node's CPU utilization, memory usage, and number of I / O operations. For processor nodes with more severe thermal anomalies, computing power will be reduced. In this case, it is necessary to assess the node's computing power by real-time monitoring of its core frequency (e.g., using the cpufreq tool) and memory access speed. During the computing power assessment process, particular attention should be paid to the processor's performance limitations under high temperature conditions, such as frequency reduction or the activation of thermal protection mechanisms. By comparing this performance data with historical temperature data, the specific level of the node's computing power can be clearly determined.

[0131] Step S43: Adjust the heat dissipation reinforcement learning decision based on the node computing capacity and load balancing information, thereby obtaining heat dissipation reinforcement learning decision data;

[0132] In this embodiment, relevant parameters of the cooling system are set. These parameters include, but are not limited to, the operating efficiency of the cooling device, fan speed, and cooling area. By analyzing load balancing information, the load pressure of each processor node is determined. If the load on a node is too high, a thermal anomaly will be triggered. Therefore, the goal of the cooling reinforcement learning decision-making process is to dynamically adjust the cooling strategy based on real-time load conditions and node computing power to achieve optimal cooling results. A reinforcement learning model is used here to adjust the cooling system's operating strategy through empirical learning based on factors such as load, temperature, and computing power. Specifically, sensors monitor node temperature changes and load fluctuations in real time, and, combined with a reinforcement learning algorithm, design an adaptive cooling adjustment strategy. For example, if a node's load exceeds a preset threshold (e.g., 70%), the node's temperature will rise accordingly, and the cooling system will need to automatically adjust the fan speed or activate other cooling mechanisms. By gradually optimizing the adjustment strategy, an automated cooling management system tailored to load changes is ultimately established. This system continuously adjusts the cooling strategy through the reinforcement learning algorithm to ensure that the processor temperature remains within a reasonable range. The output of this step is cooling reinforcement learning decision data, which records the cooling adjustment strategy for different load conditions.

[0133] It is particularly important that step S43 includes the following steps:

[0134] Step S431: defining a node state space based on node computing capabilities;

[0135] In this embodiment, a node management controller (e.g., a node monitoring module based on the IPMI 2.0 standard) acquires basic hardware parameter information for each node, including the number of CPU cores, single-core clock speed (in GHz), memory capacity (in GB), network bandwidth (in Gbps), and node heat dissipation limit parameters such as the maximum allowable operating temperature (set to 85°C) and maximum cooling capacity (set to 300W). A unified acquisition window with a 5-second period is used, and data is read using the SNMP protocol to ensure real-time parameter consistency. The node's CPU utilization (L) is used as the load indicator, with a range set to 0%-100%. 0%-30% is defined as the low load range, 30%-70% as the medium load range, and 70%-100% as the high load range. Node temperature (T) is measured in degrees Celsius using an onboard temperature sensor (e.g., the ADT7461 sensor chip), with a sampling period synchronized with the load. The node's remaining computing power (R) is calculated by subtracting the node's current load computing power from its maximum theoretical computing power (CPU clock speed × number of cores × maximum number of instructions per core), expressed in GFLOPS. The node's heat dissipation power (Q) is calculated based on the electrical power measured by the real-time current and voltage detection modules, combined with the system's known thermal efficiency settings (assuming 85% electrical energy is converted to heat). Ultimately, the state space S of each node is defined as a four-tuple (L, T, Q, R), discretized and stored in the node state database, which is refreshed every 5 seconds.

[0136] Step S432: performing task scheduling analysis on the node state space based on the load average information to obtain task scheduling data;

[0137] In this embodiment, node state space data is analyzed by a load balancing scheduler (using a combined static and dynamic algorithm, with the dynamic portion based on load change trend discrimination). First, the (L, T, Q, R) quadruple data of all nodes is read at a unified time point and analyzed according to the following scheduling criteria: nodes with a load rate higher than 80% or a temperature higher than 75°C are marked as "heavy nodes," and nodes with a load rate lower than 40% and a temperature lower than 60°C are marked as "idle nodes." Task migration priorities are set, with the principle of "heavy nodes migrate out, idle nodes migrate in" being the basic principle, prioritizing the migration of tasks from highly loaded nodes to idle nodes. During the scheduling analysis process, a weighted scheduling algorithm is used, with the weight set to W = 0.7 × (load rate / 100) + 0.3 × (temperature / 85). The node list is sorted from largest to smallest according to the weight value to determine the migration order. For each overloaded node, the task subset for each migration is calculated based on the number of tasks N and the expected migration task volume (the migration unit is set to 10% of the load volume), and the target node ID and migration volume are recorded. The final output task scheduling data table, including node ID, task quantity change ΔN, expected load change ΔL, and expected temperature change ΔT, is stored in the scheduling system cache with an update cycle of 5 seconds.

[0138] Step S433: identifying multi-task nodes according to task scheduling data;

[0139] In this embodiment, in the task scheduling data table, for each node record, the change in the number of tasks ΔN is detected. If the total number of tasks N is greater than or equal to 3 and the expected load change ΔL is a positive value, and the current temperature of the node T is greater than 65°C, the node is marked as a multi-task node. In the specific implementation, the SQL query statement is used to filter out qualified records from the task scheduling data table, and the filtering conditions are (N≥3)AND(ΔL>0)AND(T≥65). The screening results generate a multi-task node list, which contains information such as node ID, current number of tasks, real-time temperature of the node, load rate, etc. For the convenience of subsequent processing, the load change curve of the node in the last 10 minutes (sampled every 5 seconds, a total of 120 sampling points) is synchronously recorded in the multi-task node list for dynamic adjustment of heat dissipation decisions. The screening operation is performed every 5 seconds to ensure the synchronization of the timeliness of task scheduling actions and heat dissipation adjustment actions.

[0140] Step S434: adjusting the liquid cooling system of the multi-task node to obtain liquid cooling system adjustment data; adjusting the heat sink fan speed of the multi-task node to obtain heat sink fan speed adjustment data;

[0141] In this embodiment, the liquid cooling system's adjustment strategy is determined based on the node's real-time load factor, L, and temperature, T. Liquid cooling flow rate adjustment is performed using a linear increment method. The base flow rate is set at 4 L / min. If the node load factor is between 70% and 90%, the flow rate increases to 5 L / min. If the load factor exceeds 90% or the temperature exceeds 80°C, the flow rate is adjusted to 6 L / min. Flow rate adjustment is accomplished by the liquid cooling system controller sending a PWM signal to the pump control module. The change in the signal's duty cycle corresponds linearly to the target flow rate change, with a proportionality factor set such that a 10% duty cycle corresponds to a 1 L / min flow rate change. Heat sink fan speed adjustment is based on a combination of node temperature and load factor, with a base temperature, Tbase, set at 65°C and a base load, Lbase, set at 50%. The fan speed adjustment, ΔN, is calculated using the formula ΔN = 15 × (T - 65) + 5 × (L - 50), expressed in RPM. The base fan speed is set at 2000 RPM. When the temperature and load exceed the base values, the fan speed increases synchronously. For example, if the node temperature is 75°C and the load is 80%, then ΔN = 15 × (75-65) + 5 × (80-50) = 150 + 150 = 300 RPM, resulting in a final speed adjustment of 2300 RPM. Adjustment commands are sent directly to the fan controller via the I2C bus, enabling dynamic fan speed adjustment. Liquid cooling adjustment data and fan speed adjustment data are stored separately in local adjustment data tables, with each adjustment recorded after completion.

[0142] Step S435: Integrate the liquid cooling system adjustment data and the heat sink fan speed adjustment data to obtain heat dissipation reinforcement learning decision data.

[0143] In this embodiment, the latest liquid cooling adjustment data and fan speed adjustment data are read. The adjustment action of each multi-task node (including the liquid cooling flow change ΔF and the fan speed change ΔN) is combined with the current state of the node S (L, T, Q, R) to form an input sample pair for reinforcement learning. In order to standardize the reinforcement learning decision, the normalization interval of each parameter of the node state is set, such as L normalized to [0,1], T normalized to [0,1] (85℃ corresponds to 1), Q normalized to [0,1] (300W corresponds to 1), and R normalized to [0,1] (maximum remaining computing power corresponds to 1). The adjustment action is also normalized, the liquid cooling flow is normalized to 4-6L / min, and the fan speed is normalized to 2000-4000RPM. The integrated input samples are stored in the reinforcement learning input buffer pool in the (S, A) format. The reinforcement learning component does not use an external model, but instead directly employs a historical sample replay strategy. This strategy scores the effects of historical adjustments (subsequent temperature drops ΔT′ at the node) and selects future action decisions under similar conditions. The sample update cycle is set to 1 minute. The resulting cooling reinforcement learning decision data includes the optimal liquid cooling flow rate and fan speed settings for each node. This decision data is packaged and stored in the decision execution module for subsequent hardware control instruction generation.

[0144] Step S44: performing path planning cognitive evolution according to the heat dissipation reinforcement learning decision data to generate path planning cognitive evolution data;

[0145] In this embodiment, the heat dissipation reinforcement learning decision data is combined with the path planning model, and the scheduling and heat dissipation strategy of computing resources is optimized through the path planning cognitive evolution. Path planning cognitive evolution involves algorithm design and optimization strategy, and the key technologies used include genetic algorithm, ant colony optimization algorithm, etc. In this step, path planning cognitive evolution dynamically selects the optimal path by evaluating the relationship between the heat dissipation adjustment strategy and load demand of different nodes. For example, if the load of a processor node is too high and the heat dissipation is insufficient, the path planning algorithm will automatically select the optimized heat dissipation path to reduce the node load, thereby avoiding further thermal anomalies. Through path planning cognitive evolution, the impact of each heat dissipation strategy adjustment can be evaluated and optimized adjustments can be made based on the feedback results. Ultimately, the data generated by path planning cognitive evolution includes the load scheduling path, heat dissipation strategy path and other computing resource scheduling information between processor nodes, providing data support for subsequent training and optimization.

[0146] It is particularly important that step S44 includes the following steps:

[0147] Step S441: defining a heat dissipation state vector according to heat dissipation reinforcement learning decision data;

[0148] In this embodiment, a heat dissipation state vector is defined based on heat dissipation reinforcement learning decision data. First, heat dissipation reinforcement learning decision data is collected from vehicle or intelligent agent nodes. The data includes the node's actual heat dissipation power value (in W), the liquid cooling system flow rate setpoint (in L / min), the heat sink fan speed setpoint (in rpm), and the node load factor (the percentage of the node's total load to the current load, in %). A high-speed data acquisition card (model NI USB-6341) is used for synchronous sampling at a sampling frequency of 1 Hz. For each node, a heat dissipation state subvector is constructed. Specifically, the collected heat dissipation power is normalized to a value between 0 and 1. The normalization method is to divide the measured value by the node's maximum rated heat dissipation power (measured in a calibration experiment, for example, the node's maximum heat dissipation power is 120 W), compare the flow rate setpoint with the maximum rated flow rate (for example, 5 L / min) and then normalize it. The fan speed is normalized to the set maximum speed (for example, 6000 rpm). The load factor is directly used as the normalized value. Each subvector is concatenated to form an overall heat dissipation state vector. The vector length is equal to the number of nodes multiplied by 4. The thermal state vector is finally stored in the vehicle's internal RAM (Micron DDR4 16GB) for real-time recall in subsequent steps.

[0149] Step S442: constructing a path planning environment model based on the heat dissipation state vector;

[0150] In this embodiment, the heat dissipation state vector is parsed at the node level to extract the heat dissipation power ratio, liquid cooling flow ratio, fan speed ratio and load rate of each node. Through a custom environment construction function, the vehicle driving area is divided into a grid map (the grid side length is fixed at 5 meters × 5 meters), and each grid unit is bound to a local node heat dissipation load attribute. If the heat dissipation power ratio of the node associated with a grid area exceeds 80%, the traffic cost coefficient of the grid unit is set to 2.0, and the traffic cost of the normal area is 1.0. If the node load rate is higher than 90%, an additional cost value of 1.5 times is added. Road traffic data is also added to the environmental model. The traffic density is obtained by real-time scanning of the laser radar (model Velodyne HDL-32E) and superimposed with the heat dissipation status to form the final path planning environment model. All environmental parameters are stored in a two-dimensional matrix. The matrix elements record the terrain cost, heat dissipation cost, and traffic cost of the corresponding grid respectively. The matrix update cycle is set to 2 seconds.

[0151] Step S443: generating a preliminary path according to the environment model;

[0152] In this embodiment, a preliminary path is generated based on the environmental model. Path generation uses the standard A algorithm, with the cost function defined as f(n) = g(n) + h(n), where g(n) is the actual cumulative cost from the starting point to the current node, and h(n) is the heuristically estimated cost from the current node to the end point (calculated using Euclidean distance). During the accumulation process, g(n) is superimposed with the heat dissipation cost, traffic cost, and terrain cost from the environmental model. Specifically, the heat dissipation cost is weighted 0.5, the traffic cost is weighted 0.3, and the terrain cost is weighted 0.2, with the total weight being 1. The open and closed lists in the A algorithm are implemented in C++ (GCC compiler version 9.3.0), and a priority queue data structure (priority_queue) is used to optimize node expansion efficiency. During the path search, if the cumulative cost exceeds three times the direct cost from the starting point to the end point, backtracking and replanning are forced to avoid local extremum traps. The resulting preliminary path is output as a node sequence with a fixed spacing of 5 meters between nodes.

[0153] Step S444: performing path cognitive evolution on the preliminary path based on the heat dissipation reinforcement learning decision data to obtain path planning cognitive evolution data.

[0154] In this embodiment, the cognitive evolution process employs iterative optimization based on a reward mechanism, rather than traditional large-scale neural network training, to avoid wasting computational resources. First, for each node in the preliminary path, the local cost is reassessed based on the current heat dissipation state vector. If the node's associated heat dissipation power exceeds 85%, the local cost is increased by 50%. During the path evolution process, three basic operations are defined: fine-tuning (shifting the current path within ±5°), replanning (searching for alternative nodes in a local area), and jumping (directly skipping over high-heat dissipation areas). The total cost of the path is recalculated after each operation, with decreasing costs serving as positive feedback rewards, while increasing costs result in deductions. The operations are performed in a fixed, looping sequence, prioritizing fine-tuning, followed by replanning, and finally jumping. The number of iterations is set to 50, and the current optimal path is retained after each iteration. After the cognitive evolution of the path is complete, the node sequence and corresponding local heat dissipation cost values of the final path are packaged and stored. The path storage format uses the standard JSON file format, with each node recording four fields: location (X, Y coordinates), local cost, and local heat dissipation state, for subsequent invocation by the agent execution module.

[0155] Step S45: Transmit the path planning cognitive evolution data and the heat dissipation reinforcement learning decision data to the multimodal intelligent agent to perform the dual-engine collaborative training task.

[0156] In this embodiment, after the path planning cognitive evolution data and the heat dissipation reinforcement learning decision data are generated, these two types of data are transmitted to the multimodal intelligent agent through a specific data transmission channel (such as IPC, network transmission, etc.). This step usually transmits the data from the heat dissipation control system to the multimodal intelligent agent for further processing through a dedicated communication protocol (such as MQTT, HTTP, gRPC, etc.). By receiving these data, the multimodal intelligent agent adjusts the internal training task execution strategy based on the received path planning and heat dissipation decision data. The dual-engine collaborative training task refers to the coordinated execution of training tasks on different computing resource nodes, while optimizing the utilization efficiency of computing resources and the heat dissipation effect. By transmitting the path planning cognitive evolution data and the heat dissipation reinforcement learning decision data, the intelligent agent can reasonably allocate computing resources when performing tasks, and at the same time implement an optimized heat dissipation strategy to ensure that the computing tasks are completed in an efficient and stable environment.

[0157] The present invention is therefore intended to be illustrative and non-restrictive in all respects, with the scope of the invention being defined by the appended claims rather than the foregoing description, and all changes that come within the meaning and range of equivalents of the application documents are intended to be embraced therein.

[0158] The foregoing description is intended only to provide specific embodiments of the present invention, which will enable those skilled in the art to understand and implement the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not intended to be limited to the embodiments shown herein, but is to be construed in the widest possible manner consistent with the principles and novel features disclosed herein.

Claims

1. A multimodal agent RAG-ReAct dual-engine collaborative training method, characterized by: The following steps are involved: Step S1: acquiring multimodal agent data; identifying a blurred and distorted image based on the multimodal agent data; determining optical focus abnormality based on the blurred and distorted image, and generating optical focus abnormality data; Step S2: detecting the wear of the spiral guide rail based on the optical focus abnormality data; and determining the life of the lens module according to the wear of the spiral guide rail; Optimize the focus compensation range based on the life of the lens module; search the agent's historical database based on the focus compensation range, and monitor the computing power overload during the search process to obtain computing power overload data and historical maintenance information; Step S3: Perform memory leak detection based on the computing power overload data to obtain memory leak data; Monitor the agent's processor thermal anomaly based on memory leak data and obtain processor thermal anomaly data; Step S4: performing heat dissipation reinforcement learning decision adjustment on the processor thermal anomaly data according to historical maintenance information to obtain heat dissipation reinforcement learning decision data; Path planning cognitive evolution is performed based on the heat dissipation reinforcement learning decision data to generate path planning cognitive evolution data; the path planning cognitive evolution data and the heat dissipation reinforcement learning decision data are transmitted to the multimodal intelligent agent to perform the dual-engine collaborative training task.

2. The multimodal agent RAG-ReAct dual-engine collaborative training method according to claim 1 is characterized in that: Step S1 is specifically as follows: Step S11: Acquire multimodal agent data and extract agent visual sensor images; Step S12: Calculating the second-order derivative of the pixel based on the agent's visual sensor image; Step S13: determining the Laplace operator kernel according to the second-order derivative of the pixel point; Step S14: identifying fuzzy and distorted regions of the agent's visual sensor image according to the Laplace operator kernel to generate a fuzzy and distorted image; Step S15: determining optical focus abnormality based on the blurred and distorted image, and generating optical focus abnormality data.

3. The multimodal agent RAG-ReAct dual-engine collaborative training method according to claim 2, characterized in that: Step S15 is specifically as follows: Step S151: When any of the following conditions occurs, it is determined to be a focus blur abnormality and focus blur abnormality data is obtained: the Laplace variance of the blurred and distorted image is less than 0.001, the clarity fluctuation exceeds 20%, and the clarity difference between the edge and center of the blurred and distorted image exceeds 30%; Step S152: When the following conditions occur simultaneously, it is determined that the focus abnormality is caused by a motor drive failure, and motor drive focus abnormality data is obtained: the VCM motor current fluctuation amplitude exceeds 15%, the motor stroke feedback deviates from the set focal length position by more than 10 μm, and the focus process response time exceeds 300 ms; Step S153: When the following conditions occur simultaneously, it is determined that the focus abnormality is caused by the slide rail jamming, and the slide rail jamming focus abnormality data is obtained: the slide rail motion load change rate exceeds 25%, the slide rail displacement curve has an obvious stagnant section, and the local area imaging is blurred and shows discontinuous characteristics with position changes; Step S154: Integrate the focus blur abnormality data, the motor drive focus abnormality data, and the slide rail stuck focus abnormality data to obtain the optical focus abnormality data.

4. The multimodal agent RAG-ReAct dual-engine collaborative training method according to claim 1, characterized in that: The specific method for detecting the wear of the spiral guide rail in step S2 is as follows: Calculating an optical focus offset based on the optical focus abnormality data; calculating an optical focus speed based on the optical focus abnormality data; and reconstructing an optical focus trajectory based on the optical focus offset and the optical focus speed; Perform offset guide rail identification according to a preset optical focus standard track and an optical focus track to obtain offset guide rail data; Reversely solve the guide rail shape based on the offset guide rail data to obtain the spiral guide rail data; Calculate the pitch change based on the spiral guide rail data; calculate the spiral change angle based on the spiral guide rail data; The wear of the spiral guide rail is determined based on the pitch change and the spiral angle change.

5. The multimodal agent RAG-ReAct dual-engine collaborative training method according to claim 1, characterized in that: The specific method for determining the life of the lens module in step S2 is: Identify high-wear guide rail areas based on the amount of helical guide rail wear; Use vibration sensors to continuously monitor the rail vibration in high-wear rail areas to obtain rail vibration data; extract high-frequency rail vibration data based on the rail vibration data; Guide rail warpage is identified in high-wear guide rail areas based on high-frequency guide rail vibration data to obtain guide rail warpage data; Perform lens module motion simulation based on the guide rail warping data to generate lens module motion data; Calculating the friction force of the lens module according to the motion data of the lens module; Calculating the resistance of the lens module according to the motion data of the lens module; Determine the lens module workload based on the lens module friction and lens module resistance; Predict lens module life based on lens module workload.

6. The multimodal agent RAG-ReAct dual-engine collaborative training method according to claim 1, characterized in that: The reasoning for optimizing the focus compensation amplitude in step S2 is specifically as follows: Calculate the historical wear of the lens module based on the life of the lens module; Convert the historical wear of the lens module into the first loss of focus accuracy; Acquire humidity sensor data; screen low-life lens modules based on their lifespan, and simulate optical coating corrosion on the low-life lens modules based on the humidity sensor data to obtain optical coating corrosion data; Calculate lens reflectivity based on optical coating corrosion data; Evaluate focus shift based on lens reflectivity; The focus compensation amplitude is optimized according to the focal length offset and the first loss of focus accuracy.

7. The multimodal agent RAG-ReAct dual-engine collaborative training method according to claim 1, characterized in that: Step S2 monitors computing power overload during the search process as follows: Based on the focus compensation amplitude, the agent history database is retrieved to obtain historical maintenance information; The CPU usage during the collection and retrieval of the agent's history database; Allocate multi-core computing resources according to CPU usage to obtain multi-core computing resource allocation data; Evaluate parallel computing efficiency based on multi-core computing resource allocation data; Identify register conflicts based on parallel computing efficiency and obtain register conflict data; determining a register overflow degree based on the register conflict data; Evaluate computing power overload based on the degree of register overflow and obtain computing power overload data.

8. The multimodal agent RAG-ReAct dual-engine collaborative training method according to claim 1, characterized in that: Step S3 is specifically as follows: Step S31: Monitoring memory consumption trends based on computing power overload data; Step S32: Calculate the memory release amount according to the memory consumption trend; Step S33: determining a memory release address based on the memory release amount; Step S34: performing memory duplicate allocation analysis based on the memory release address to obtain memory duplicate allocation data; Step S35: performing memory leak detection based on the memory duplicate allocation data to obtain memory leak data; Step S36: Monitor the thermal anomaly of the intelligent agent processor based on the memory leakage data to obtain processor thermal anomaly data.

9. The multimodal agent RAG-ReAct dual-engine collaborative training method according to claim 8, characterized in that: Step S36 is specifically as follows: Step S361: Calculate memory occupancy time based on memory leak data; Step S362: predicting the probability of triggering garbage collection based on the memory usage time; Step S363: Evaluate the processor load pressure based on the garbage collection trigger probability; Step S364: Counting the processor heat according to the processor load pressure; Step S365: Obtaining processor heat dissipation efficiency data; Step S366: Assess the intelligent agent's processor thermal anomaly based on the processor heat dissipation efficiency data and the processor heat to obtain processor thermal anomaly data.

10. The multimodal agent RAG-ReAct dual-engine collaborative training method according to claim 1, characterized in that: Step S4 is specifically as follows: Step S41: extracting load balancing information based on historical maintenance information; Step S42: Identifying a processor node based on the processor thermal anomaly data; Determine node computing capacity based on processor nodes; Step S43: Adjust the heat dissipation reinforcement learning decision based on the node computing capacity and load balancing information, thereby obtaining heat dissipation reinforcement learning decision data; Step S44: performing path planning cognitive evolution according to the heat dissipation reinforcement learning decision data to generate path planning cognitive evolution data; Step S45: Transmit the path planning cognitive evolution data and the heat dissipation reinforcement learning decision data to the multimodal intelligent agent to perform the dual-engine collaborative training task.

Images