Method for constructing an intelligent agent management platform supporting knowledge retrieval, generation and optimization

Abstract

The present invention relates to the field of artificial intelligence technology, and in particular to a method for constructing an intelligent agent management platform that supports knowledge retrieval, generation, and optimization. The method comprises the following steps: acquiring multimodal data, and performing semantic fusion based on the multimodal data to obtain semantic fusion data; performing knowledge retrieval based on the semantic fusion data to obtain knowledge retrieval data; establishing a three-level reflection system based on the knowledge retrieval data, including constructing a result reflection layer, a process reflection layer, and a strategy reflection layer, thereby obtaining result reflection layer data, process reflection layer data, and strategy reflection layer data, and performing hierarchical system fusion to obtain three-level reflection system data; performing prompt word optimization based on the three-level reflection system data to obtain prompt word optimization data. The present invention improves the knowledge retrieval accuracy and system operation efficiency of the intelligent agent management platform based on artificial intelligence technology.

Description

Technical Field

[0001] The present invention relates to the field of artificial intelligence technology, and in particular to a method for constructing an intelligent agent management platform that supports knowledge retrieval, generation, and optimization. Background Art

[0002] Traditional intelligent agent management platforms have limited semantic fusion capabilities across multimodal data, typically remaining at the shallow feature concatenation or rule mapping stage. They are unable to achieve deep cross-modal semantic understanding, leading to information bias in the knowledge retrieval process or poor contextual relevance of retrieval results. They lack effective reflection mechanisms, preventing systematic evaluation and feedback optimization of knowledge generation results. Especially when faced with complex tasks, they lack the ability to backtrack the generation process and decision paths, which can easily lead to problems such as logical jumps, semantic duplication, or redundant generation. The prompt word optimization process relies on manual rules or static templates and cannot dynamically adjust semantic control strategies based on task context, resulting in insufficient prompt word generalization and affecting the accuracy of the system's response to complex instructions. Task chain construction often uses linear processes or static configuration methods, making it difficult to optimize in real time based on node resource load status. This results in wasted resources on some nodes and overloaded loads on others, resulting in low scheduling efficiency and weak system throughput. When faced with heterogeneous hardware resource environments, the lack of precise quantification of task resource types and thread binding mechanisms prevents efficient hardware collaborative scheduling, resulting in large fluctuations in the platform's overall execution efficiency and high response latency, which restricts the performance improvement of intelligent agent management systems in complex scenarios. Summary of the Invention

[0003] Based on this, it is necessary for the present invention to provide a method for constructing an intelligent agent management platform that supports knowledge retrieval, generation and optimization, so as to solve at least one of the above technical problems.

[0004] To achieve the above objectives, a method for constructing an agent management platform that supports knowledge retrieval, generation, and optimization includes the following steps:

[0005] Step S1: Acquire multimodal data, and perform semantic fusion based on the multimodal data to obtain semantic fusion data; perform knowledge retrieval based on the semantic fusion data to obtain knowledge retrieval data;

[0006] Step S2: Establish a three-level reflection system based on the knowledge retrieval data, including constructing a result reflection layer, a process reflection layer, and a strategy reflection layer, thereby obtaining result reflection layer data, process reflection layer data, and strategy reflection layer data, and performing hierarchical system integration to obtain three-level reflection system data;

[0007] Step S3: Optimize prompt words based on the three-level reflection system data to obtain prompt word optimization data; perform node load balancing based on the three-level reflection system data to obtain node load balancing data; reconstruct the task chain based on the node load balancing data to obtain task chain data; detect resource consumption based on the task chain to obtain resource consumption data;

[0008] Step S4: Perform heterogeneous hardware collaborative scheduling based on resource consumption data to obtain heterogeneous hardware collaborative scheduling data; build an intelligent agent management platform based on the heterogeneous hardware collaborative scheduling data and prompt word optimization data, and adaptively adjust the knowledge retrieval strategy of the intelligent agent management platform to obtain adaptive strategy data.

[0009] The present invention improves the ability to understand cross-modal information through deep semantic fusion of multimodal data, effectively solves the semantic deviation problem caused by shallow feature splicing of traditional platforms, and ensures the contextual relevance and accuracy of knowledge retrieval. The established three-level reflection system realizes the comprehensive evaluation and adjustment of knowledge generation results, construction process and strategy, avoids logical jumps and redundant generation, and improves the logic of content. The prompt word optimization based on the reflection system realizes the dynamic adjustment of prompt words, enhances its generalization ability and semantic control effect, and improves the accuracy of complex instruction response. Node load balancing and task chain reconstruction are introduced to solve the problem of uneven resource allocation, achieve node load balancing, optimize task execution process, and improve scheduling efficiency and system throughput. Heterogeneous hardware collaborative scheduling is carried out through resource consumption data, task resource requirements are accurately quantified and combined with thread binding mechanism to achieve efficient hardware collaboration, reduce delay fluctuations, improve execution efficiency and response speed in complex hardware environments, enhance system performance stability and expansion capabilities, and comprehensively improve the comprehensive capabilities of the intelligent body management platform. 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 method for constructing an intelligent agent management platform that supports knowledge retrieval, generation, and optimization according to the present invention;

[0012] 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

[0013] 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.

[0014] 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.

[0015] 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.

[0016] To achieve this, please refer to Figure 1 The present invention provides a method for constructing an intelligent agent management platform that supports knowledge retrieval, generation, and optimization, the method comprising the following steps:

[0017] Step S1: Acquire multimodal data, and perform semantic fusion based on the multimodal data to obtain semantic fusion data; perform knowledge retrieval based on the semantic fusion data to obtain knowledge retrieval data;

[0018] In this embodiment, multimodal data includes text data, image data, audio data, and structured data. Each type of data is first standardized using the corresponding preprocessing modules. Text data is segmented using a word segmentation tool, and a custom industry terminology dictionary is selected as the dictionary library to ensure a segmentation accuracy of over 95%. Image data is pixel normalized to a uniform resolution of 224×224 pixels. Image features are extracted using a convolutional feature extraction algorithm, with the extraction layer set to the fourth convolutional layer and the output dimension fixed to a 512-dimensional vector. The audio data sampling rate is fixed at 16kHz, and time-frequency features are extracted using a short-time Fourier transform (STFT) with a window length of 25ms and a step size of 10ms, resulting in 128-dimensional spectral features. Structured data is input in JSON format, with predefined fields strictly adhering to data standards. A hash map indexing method is used to quickly locate key fields. Multimodal alignment technology was then employed. Specifically, cross-modal feature alignment was performed using the Maximum Mutual Information (RMI) criterion. The mutual information between features from each modality was calculated, with a threshold of 0.8 to ensure alignment accuracy. After alignment, the features from each modality were fused using a weighted fusion method, with weights calculated by normalizing the mutual information values. The fusion result was converted into a 512-dimensional semantic vector via linear projection. This fused vector was used as input to retrieve relevant knowledge fragments from a pre-built knowledge base using a multi-source knowledge base matching algorithm based on cosine similarity calculation. The similarity threshold for retrieval was set to 0.75. The retrieval results were sorted in descending order of similarity, and the top 20 results were selected as the knowledge retrieval data.

[0019] Step S2: Establish a three-level reflection system based on the knowledge retrieval data, including constructing a result reflection layer, a process reflection layer, and a strategy reflection layer, thereby obtaining result reflection layer data, process reflection layer data, and strategy reflection layer data, and performing hierarchical system integration to obtain three-level reflection system data;

[0020] In this embodiment, at the result reflection layer, core keywords are extracted through text analysis technology, using the TF-IDF algorithm, and the number of keywords is limited to the top 10. A target semantic graph is constructed based on the core keywords. The semantic graph nodes represent keywords, and edge weights are calculated based on the keyword co-occurrence frequency. The threshold is set to 0.6, and edges below the threshold are removed. The automatic question and answer generation process is executed based on the target semantic graph, using a template-driven answer generation mechanism, and all generated text is recorded as actual output data. When calculating keyword coverage, the number of matching keywords in the actual output is divided by the total number of core keywords. A coverage below 0.7 is considered insufficient. The cosine similarity method is used to calculate the semantic match, and a match below 0.75 is considered a mismatch. The output error is calculated based on the keyword coverage and semantic match, with an error threshold of 0.3. The output error is used to extract language control parameters, including the answer length limit (maximum 500 characters), the proportion of professional terminology used (minimum 15% of the total number of words), and the semantic coherence control index. Language control parameters are converted into a structured output control template. This template is defined in the form of a finite state machine, with nodes corresponding to language generation rules and edges representing transition conditions. This ultimately generates data for the result reflection layer. The process reflection layer is implemented by analyzing task execution paths. Log analysis techniques are used to parse task node call sequences and extract task execution path data. A path decision tree is constructed based on this path data, with nodes representing task nodes. The tree height is limited to 10 layers to control complexity. To identify inefficient nodes, the average response time of each node is calculated, and nodes exceeding 100ms are classified as inefficient. Node call frequency is counted, and inefficient nodes exceeding a call threshold of 500 are marked as high-frequency inefficient nodes. A result cache storage policy is configured for high-frequency inefficient nodes, with a cache capacity of 1GB and a cache expiration time of 30 minutes. Task processes are restructured based on the cache policy, adjusting the execution priority of inefficient nodes to generate data for the process reflection layer. The policy reflection layer is implemented by extracting business rules, using a unified JSON Schema format. These rules cover 20 business rules, such as knowledge update and permission control. Historical decision output records for the past three months are obtained and stored in log files. By comparing historical decisions with business rules, a Bayesian network model was used to calculate the probability of cognitive bias, with a bias threshold of 0.2. Based on cognitive bias, knowledge structure update requirements were generated and converted into graph reconstruction requirements, specifically including adding and deleting nodes and adjusting relationships, with adjustments not exceeding 10%. The knowledge graph structure was adjusted to form the strategic reflection layer data. Finally, the three layers of reflection data were hierarchically fused using a weighted fusion method, with weights of 40% for the outcome reflection layer, 35% for the process reflection layer, and 25% for the strategic reflection layer, resulting in a complete three-level reflection system data.

[0021] Step S3: Optimize prompt words based on the three-level reflection system data to obtain prompt word optimization data; perform node load balancing based on the three-level reflection system data to obtain node load balancing data; reconstruct the task chain based on the node load balancing data to obtain task chain data; detect resource consumption based on the task chain to obtain resource consumption data;

[0022] In this embodiment, the task execution result data in the result reflection layer is analyzed, and a result reflection operation is performed to extract key anomaly indicators from the task results. Anomaly detection algorithms are used to identify outliers. A statistical threshold setting method is used during anomaly identification. The anomaly threshold is set to data points outside the range of the result data plus or minus three times the standard deviation. The standard deviation and mean are dynamically calculated based on the numerical indicators in each task output result to ensure identification accuracy. Based on the extracted outlier information, combined with the mapping path between the prompt words recorded in the result reflection path and the actual task feedback, the policy deviation that caused the anomaly is analyzed. During the deviation type identification process, the K-means clustering algorithm is used to cluster the abnormal task data. The clustering dimensions include prompt word length, number of nesting levels, task response semantic deviation value, and information density index. The prompt word length unit is the number of words, the number of nesting levels is analyzed from the context structure, the semantic deviation value is calculated by comparing the word embedding cosine distance with historical task results, and the information density index is calculated by dividing the number of high-frequency key entities appearing in the prompt word per unit length by the total number of words. The three clusters output by the clustering algorithm are categorized as prompt word structure defects, semantic deviation, and information redundancy. Based on the identified policy deviation types, the prompt words are restructured using a context-free grammar to construct a prompt word structure template consisting of non-terminal and terminal symbols. The maximum parsing depth of the template is limited to five levels. Terminal symbols include fields such as keywords, operation objectives, and task requirements, while non-terminal symbols include context-dependent semantics, situational modifiers, and constraints. A control weight mechanism is introduced when generating the multi-level prompt word control structure. The control weight is calculated based on three characteristic parameters: part of speech (nouns, verbs, and adjectives are assigned values ​​of 0.2, 0.5, and 0.3, respectively), semantic strength (normalized to a range of 0-1 based on word frequency ranking), and contextual relevance (calculated by the similarity between the word vectors of the prompt word and the context paragraph, ranging from 0-1). The weighted average of these three factors is used as the final control weight, with a constraint range of 0 to 1. After generating the prompt word optimization data, the execution status of all agent nodes in the current task system is calculated based on historical execution data provided by the process reflection layer and the strategy reflection layer of the three-level reflection system. Four node states are enumerated: idle, running, waiting, and failed. Each state is automatically identified based on the task lifecycle labels recorded in real-time in the node log. Node resource load is calculated as a weighted average of CPU utilization and memory utilization. CPU utilization is sampled once per second and expressed as a percentage. Memory utilization is measured in GB and converted to a percentage before use in the calculation. Node scheduling priority is calculated using the following weighted formula: Priority = 0.7 × (1 - CPU load) + 0.3 × (1 - memory load). The result is normalized to a value between 0 and 1, with larger values ​​indicating higher node scheduling priority.According to the scheduling priority data, a priority-based polling scheduling algorithm is used to assign tasks to be executed to nodes with appropriate resources to ensure that the scheduling delay time does not exceed 50 milliseconds. Node load analysis calculates the mean and standard deviation of the CPU and memory usage of all running nodes. If the variance value of the node load rate does not exceed 0.05, it is determined to be in a load-balanced state. Otherwise, the scheduling order is readjusted to approach load balance. After the node allocation is completed, the dependency relationship between tasks is identified based on the historical dependency information of task execution. The dependency relationship is expressed in the form of a directed acyclic graph (DAG). The nodes in the graph are task identifiers, and the edges represent dependency relationships. The maximum depth of the graph does not exceed 8 layers. In the task chain reconstruction stage, a topological sorting method is used to sort all task nodes in the task graph. The sorting results are combined with the node load priority to dynamically adjust the execution order of specific tasks, so that high-priority nodes give priority to tasks with high dependencies, completing the reconstructed task chain structure. After the reconstruction, resource consumption is monitored throughout the entire task chain execution process. Resource items include CPU usage time, memory peak, and network bandwidth. The sampling period is 1 second. The maximum CPU usage of a single node cannot exceed 80%, the maximum memory usage is 4GB, and the network bandwidth is capped at 100Mbps. The system continuously records the resource usage of each task chain node, generates resource consumption data, and synchronously writes it to the log and database, providing data support for subsequent heterogeneous hardware scheduling and dynamic configuration of intelligent agent tasks.

[0023] Step S4: Perform heterogeneous hardware collaborative scheduling based on resource consumption data to obtain heterogeneous hardware collaborative scheduling data; build an intelligent agent management platform based on the heterogeneous hardware collaborative scheduling data and prompt word optimization data, and adaptively adjust the knowledge retrieval strategy of the intelligent agent management platform to obtain adaptive strategy data.

[0024] In this embodiment, based on the resource consumption data obtained in step S3, the task's required resource type is first identified, distinguishing between compute-intensive, storage-intensive, and network-intensive tasks. Classification is based on CPU utilization, memory usage, and network bandwidth utilization exceeding 60%. Computing power requirements are quantified based on task resource type using the formula: computing power requirement = CPU utilization × task priority, with a priority range of 0–1. The computing power requirement is expressed in GFLOPS, and the computational threshold is set to 10 GFLOPS. Heterogeneous hardware resources are matched based on computing power requirements. Hardware resources include CPU clusters, GPU clusters, and FPGA arrays, corresponding to computing power ranges of 100 GFLOPS, 1000 GFLOPS, and 500 GFLOPS, respectively. A preliminary match is performed based on available resource capacity and task computing power requirements, selecting the hardware node that meets the requirements and has the lowest load. Task execution simulation is performed based on the preliminary matching data using a discrete event simulation method with a simulation period of 10 seconds. During the simulation, thread blocking points are monitored. A thread is considered blocked if its wait time exceeds 100ms. Blockage locations and counts are then collected. Based on thread blocking data, thread binding adjustments are made to the hardware matching results, binding highly blocked threads to resource-free nodes. Thread binding is performed at the thread level, and the binding rule is to prevent more than 64 threads on the same node. After thread binding is completed, heterogeneous hardware collaborative scheduling is performed. The scheduling algorithm uses a priority queue-based scheduler with a 50ms scheduling time slice, supporting task migration and dynamic load adjustment. Based on the heterogeneous hardware scheduling data and the prompt word optimization data in step S3, the logical architecture of the intelligent agent management platform is constructed. The platform architecture adopts a modular design, with modules communicating via RESTful interfaces and data transmission formatted as JSON. Finally, based on the platform construction results, adaptive adjustments to the knowledge retrieval strategy are performed.

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

[0026] Step S11: Acquire multimodal data;

[0027] In this embodiment, the platform specifies the multimodal input types supported, including text, image, audio, and structured sensor data. Text data is extracted from task logs and divided into rows. Each log entry contains fields such as timestamp, task ID, execution content, and system response. Image data consists of monitoring screenshots uploaded by nodes, in JPEG format with a resolution limited to 1920×1080. Audio data is extracted from system command broadcasts in WAV format with a sampling rate of 16kHz and mono. Structured data consists of status monitoring indicators generated by each node, including CPU utilization (in %), memory usage (in GB), and network throughput (in Mbps), stored in CSV format with a 1-second sampling period. All modal data must be annotated with a unified timestamp format of "YYYY-MM-DD HH:MM:SS" for subsequent alignment operations. The data preprocessing tools are Python's pandas and scipy. Image data is normalized to the range of 0-1. A mean filter (with a window size of 5) is used for audio signal denoising. Regular expressions are used to remove special symbols from text, retaining only letters, numbers, and common punctuation marks.

[0028] Step S12: extracting intra-modal features based on the multimodal data to obtain modal feature data;

[0029] In this embodiment, a separate feature extraction channel is constructed for each type of modality. The text modality processing process is as follows: n-gram statistical feature extraction is used, with n ranging from 1 to 3, to generate a term frequency matrix (Term Frequency), then calculate the TF-IDF value (weight capped at 1.0), and generate a sparse matrix of dimension (number of samples × 1000) as text features. The image modality uses the local binary pattern (LBP) algorithm to extract texture features, with the LBP radius set to 3 and the number of neighbors set to 8. The final image is divided into 9×9 grid regions, and a histogram is output for each region. After combination, an image feature vector of dimension (81×59) is generated. The audio modality extracts Mel-frequency cepstral coefficients (MFCCs) as features, with a window size of 25ms and a sliding step size of 10ms. 13-dimensional coefficients are generated and first-order and second-order differences are appended to obtain a feature vector sequence with a total dimension of 39. Structured modality data is normalized (Z-score normalization), and statistical features such as mean, standard deviation, maximum, and minimum are calculated using a sliding window (window size of 10 seconds and step size of 5 seconds) for each second of data, resulting in a feature vector of dimension 4. All modal features are managed with modal labels through a predefined dictionary structure and uniformly converted into NumPy array format, maintaining the time alignment structure unchanged.

[0030] Step S13: performing inter-modal alignment processing according to the modal feature data to obtain modal alignment data;

[0031] In this embodiment, inter-modal temporal alignment and semantic structure alignment are performed on the intra-modal features obtained in the previous step. The temporal alignment process uses interpolation and synchronization techniques to process all modalities. The minimum sampling interval is used as the baseline timeline (1 second for text and structured data, 5 seconds for images, and 10 seconds for audio). Linear interpolation is used to fill missing time points in sparsely sampled modalities. Missing time points in the image modality are copied from the previous frame, and missing time points in the audio modality are filled with silence features (all values ​​set to 0). Semantic structure alignment uses cosine similarity to assess the semantic relevance between vectors in different modalities. For text and image modalities, the image-text consistency score is calculated by matching co-occurring keywords. A matching threshold of 0.7 is set. If the match is below this threshold, the current sample is considered inconsistent at the image-text level and excluded from subsequent fusion operations. Audio modality alignment uses VAD (Voice Activity Detection) to remove silent segments and retain the speech segments before alignment. During alignment, structured data is matched to the text log according to the task ID; if there is no match, the record is deleted. After alignment, all modalities are stored as a fixed-length multimodal joint vector. Each sample is organized in a dictionary format, with fields including "timestamp", "modality identifier", and "feature vector content".

[0032] Step S14: performing semantic association based on the modality alignment data to obtain semantic association data;

[0033] In this embodiment, semantic association processing is performed based on modality-aligned data. The process includes three steps: cross-modal association graph construction, edge weight calculation, and subgraph screening. First, a multimodal semantic graph is constructed based on the aligned samples. The nodes in the graph represent the features of each modality, and the edges in the graph represent the semantic connections between the modalities. Each edge records the cosine similarity value between the two modalities. Edge weights are set between 0 and 1, and edges below 0.3 are directly removed as unrelated. To ensure the closure of semantic links, each node must have valid edge weights (edge ​​weight ≥ 0.5) with at least two other modalities; otherwise, the node is removed from the semantic graph. In the subgraph screening step, the K-core algorithm is used with a coreness of 3 to select the most central semantic core subgraph for subsequent semantic fusion operations. The graph data is constructed and visualized using the NetworkX tool to verify the rationality of the semantic graph structure. Finally, the semantic subgraph data structure corresponding to each sample is output, formatted as a combination of an adjacency matrix and a node feature set.

[0034] Step S15: performing semantic fusion according to the semantic association data to obtain semantic fusion data;

[0035] In this embodiment, semantic fusion is performed based on the semantic subgraph data structure using a maximum relevance path aggregation method based on graph traversal. Specifically, a depth-first traversal is performed on each semantic subgraph, starting from each text modal node to find the path with the maximum semantic weight leading to other modal nodes. The path score is the weighted average of all edge weights on the path (the edge weight coefficient is set to 1.0), and the top three paths with the highest scores are retained. The feature vectors on the path nodes are combined using a weighted fusion method, where the weighting factor is the edge weight value between each node in the path and the starting node. The fused semantic vector is a fixed-length vector structure (uniformly 512 dimensions), and all modalities are fused into a unified space. This operation is implemented using NumPy, and after fusion, the vectors of all samples are normalized (mean is 0, standard deviation is 1). The fused semantic vector structure is organized as a database structure indexed by the task ID. Each record stores the semantic vector content and a timestamp index in JSON format.

[0036] Step S16: Perform knowledge retrieval based on the semantic fusion data to obtain knowledge retrieval data.

[0037] In this embodiment, a knowledge retrieval operation is performed based on semantic fusion data. First, a knowledge index library is constructed. The data sources are task operation descriptions extracted from the knowledge graph, platform management rules, prompt word template libraries, and professional document texts collected from external knowledge bases. All knowledge content undergoes text normalization processing, removes punctuation and stop words, constructs an inverted index structure, and generates TF-IDF vectors (dimension is 2048) for all text paragraphs. This is implemented using scikit-learn's TfidfVectorizer with parameters set to max_features=2048 and ngram_range=(1,2). During the retrieval operation, the semantic fusion vector is used as the query vector, and the cosine similarity with each TF-IDF vector in the index library is calculated. The retrieval threshold is set to 0.75, and knowledge entries with a similarity greater than this value are selected as retrieval results. If no result meets the threshold, the top three closest knowledge records are returned. The retrieval return structure contains the fields "knowledge paragraph ID", "similarity score", "knowledge base type", and "original content text" for subsequent generation or reasoning task calls. All search results are stored in the Redis database cache, and the expiration time is set to 10 minutes to prevent outdated knowledge from interfering with scheduling tasks.

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

[0039] Step S161: constructing a semantic vector based on the semantic fusion data to obtain semantic vector data;

[0040] In this embodiment, text entities and their corresponding contextual semantic segments are extracted from the semantically fused data obtained in step S15. For each semantic segment, word segmentation is performed using a word segmentation tool (such as the Jieba word segmentation tool). Part-of-speech tagging and term mapping are performed in conjunction with a domain dictionary (such as a manually constructed "Industrial Control Domain Terminology Library" containing 5,000 terms) to ensure that the extracted words are valid and semantically representative. These terms are then standardized and encoded, and a pre-built "semantic label mapping table" is used to map each term to a unified semantic label, such as "equipment_fault_type" and "process_control_parameter," totaling 200 labels. To construct a semantic vector, a sparse vector space with a fixed dimension of 1024 is used to calculate the TF-IDF value of each term in the entire semantically fused corpus. TF is calculated as the ratio of the frequency of each term in the semantic segment to the total number of words in the segment. The IDF value is the logarithm of the total number of documents in the corpus containing the term divided by the number of documents in which the term appears. For example, if the term "fault current" appears three times in a semantic segment with a total of 100 words, its TF is 0.03. If it appears in 4,000 semantic segments in the entire corpus with a total of 200,000 semantic segments, its IDF is log(200,000 / 4,000) = 1.7, and the final TF-IDF is 0.03 × 1.7 ≈ 0.051. During the construction process, the sparse matrix structure (scipy.sparse.csr_matrix) in NumPy is used to store and subsequently calculate the semantic vectors.

[0041] Step S162: performing similarity matching on multiple source knowledge bases based on semantic vector data to obtain candidate knowledge fragment data;

[0042] In this example, the multi-source knowledge base includes 1,600 manufacturing and maintenance manuals (PDF converted to plain text), an industrial production knowledge graph (stored in triples, with a total of 350,000 nodes), and equipment sensor data logs (structured text, totaling 2TB). For each knowledge segment, a 1024-dimensional semantic vector is constructed using the same method to ensure consistency in the vector space. Similarity matching is performed using the cosine similarity method, calculated as follows: Similarity = (A·B) / (||A|| × ||B||), where A is the current semantic vector and B is the semantic vector of the segment in the knowledge base. To improve matching efficiency, the vector index acceleration tool Faiss (Facebook AI Similarity Search) is used to construct an inverted vector index with a top-k value of 100. The index returns the top 100 knowledge segments with the highest similarity to the input semantic vector. The matching threshold is set to 0.75; if a segment's similarity to the input semantic vector falls below 0.75, it is automatically discarded from the candidate list.

[0043] Step S163: sorting the candidate knowledge fragment data based on semantic relevance to obtain sorted knowledge fragment data;

[0044] In this embodiment, the ranking criteria mainly consists of three parts: (1) semantic similarity score S1, which is directly provided by cosine similarity; (2) context keyword overlap rate S2, which is calculated as the ratio of the number of intersection terms and the number of union terms of the semantic fusion data and candidate fragments at the keyword level; (3) knowledge timeliness score S3, which is defined as the interval (in days) between the current time and the time when the knowledge fragment was created or last updated, and is mapped to a standard score (for example, if the time difference is 10 days, then S3 = 1.0; if it is 300 days, then S3 = 0.1). The total ranking score Score is calculated by the following formula: Score = 0.5 × S1 + 0.3 × S2 + 0.2 × S3.

[0045] For example, if a candidate segment has a semantic similarity of 0.88, a keyword overlap rate of 0.5, and a knowledge timeliness score of 0.9, the final ranking score for the segment is 0.5 × 0.88 + 0.3 × 0.5 + 0.2 × 0.9 = 0.44 + 0.15 + 0.18 = 0.77. Using Pandas, all 100 candidate segments are scored and sorted in descending order by the Score field. The top 20 segments are retained as the final ranked knowledge segment data and stored in a structured JSON format. The fields include "segment ID," "semantic content," "source knowledge base ID," and "semantic score."

[0046] Step S164: extract knowledge based on the sorted knowledge fragment data to obtain knowledge retrieval data.

[0047] In this example, each sentence in each knowledge segment is first parsed using a dependency parser (such as Stanford NLP Parser) to extract subject-verb-object relationships and prepositional phrases. The syntactic tree is then matched using a custom extraction rule library (containing 600 rules, covering common structures such as "device-function-operation," "parameter-limits-impact," and "fault-cause-solution." For example, in the sentence "When the motor temperature exceeds 85°C, the load should be reduced," syntactic analysis identifies "motor temperature" as the subject noun phrase, "exceed" as the predicate verb, "85°C" as a numerical modifier, and "should reduce the load" as the result-oriented action. Based on the "entity-condition-action" rule, triples are extracted (motor temperature, exceeds 85°C, reduce the load). All extracted knowledge content is organized as "entity-attribute-value" or "entity-relationship-entity" triples. Following the knowledge graph construction specifications, the extracted results are written to a Neo4j graph database. Each entity node in the graph database is labeled with a type (e.g., "device," "parameter," or "action"). Relationship edges are labeled with the relationship type and accompanied by a confidence field (the confidence level is set by the rule matching level: 1.0 for first-level rule matching, 0.8 for second-level rule matching, and a default minimum of 0.5). All structured triples are ultimately extracted and used as knowledge retrieval data for the platform.

[0048] Preferably, the result reflection layer constructed in step S2 is specifically as follows:

[0049] Extract core keywords based on knowledge retrieval data to obtain core keyword data;

[0050] In this embodiment, a specified natural language processing toolkit (such as Jieba or NLTK) is used to perform word segmentation operations in the acquired knowledge retrieval data, and a customized dictionary is used in combination with part-of-speech tagging to select entries with the parts of speech of nouns (n), gerunds (vn), professional terms (nz) and adjectives (a) as candidate keywords. Subsequently, the text weight of each entry is calculated based on the TF-IDF scoring standard. In the weight calculation, the word frequency threshold is set to 1, and the inverse text frequency threshold is set to 0.1. Entries below the threshold are eliminated to reduce the influence of irrelevant words. Then, the context window co-occurrence frequency calculation method is used, and the window size is set to 5 words. Word pairs with a co-occurrence frequency higher than 3 times are screened out, and a word network is constructed based on the co-occurrence frequency. High-frequency keywords that appear simultaneously in multiple knowledge retrieval data are selected from them, and a core keyword set of no more than 50 is finally output as input for subsequent analysis.

[0051] Draw the target semantic graph based on the core keyword data;

[0052] In this embodiment, a target semantic graph is drawn based on core keyword data. A node connection matrix must be constructed, with nodes representing each term in the keyword set and edges representing co-occurrence relationships. Edge weights are calculated based on co-occurrence frequencies. The NetworkX library is used to construct an undirected graph structure. The edge weight threshold is set to 3; edges below 3 are not constructed, thereby controlling the complexity of the semantic graph. Node visualization uses the force-directed layout algorithm (Fruchterman-Reingold algorithm), with the number of layout iterations set to 50, the attraction coefficient set to 0.1, and the repulsion coefficient set to 0.8. In the semantic graph, different semantic clusters are distinguished by color. The Louvain algorithm is used as the clustering method, with the minimum community resolution parameter set to 0.5. Modularity-maximizing partitions are generated based on the edge weights between nodes, forming several semantic subgraphs representing different thematic areas. Finally, the graph structure data of the semantic graph and its visualization image are output as a reference structure for subsequent generation.

[0053] Execute the answer generation process based on the target semantic graph and record it as output text to obtain the actual output data;

[0054] In this embodiment, the question text entered by the user is segmented, tagged with parts of speech, and scored with TF-IDF in the same way, and the keywords that overlap with the nodes in the semantic graph are extracted, and the matching weight is calculated. For nodes with a matching weight greater than the set threshold of 0.2, the semantic graph edge structure is expanded to the high-weight nodes within 2 hops, and the node entries in all extended paths are collected. These entries and their edge weights are input into the answer generation process as semantic constraint structures. The answer generation process does not use a general model, but calls a preset template set to fill in the structured template with the matched keywords and the entry fragments in their semantic subgraphs. For example, when the keywords are "intelligent agent management", "knowledge retrieval", and "semantic graph", the structural template "ZZZ structure organization in accordance with the management needs of XXX through YYY method" is selected, and the above three types of keywords and their extended fragments are filled in respectively to form a complete structural answer text. The output text needs to record the semantic path and the entries used for each paragraph source for subsequent indicator calculation.

[0055] Calculate keyword coverage based on the target semantic graph and actual output data; calculate semantic matching based on the target semantic graph and actual output data;

[0056] In this embodiment, the output text is segmented and stop words are removed to obtain an output word set. The node term set in the semantic graph is then compared to calculate the ratio of the number of covered terms to the total number of node terms. The coverage is expressed as a percentage. Specifically, the total number of nodes N, the number of covered nodes M, and the keyword coverage are (M / N)×100%, where N is counted by the aforementioned semantic graph node set, M is the number of node terms that can be matched in the output text, and the matching requirement is a complete word match, without fuzzy matching. The coverage data is recorded in the system log table and used to evaluate the output error together with the semantic matching degree. The path structure between the nodes in the semantic graph is compared with the order of keyword appearance in the output text. First, a word pair sequence is constructed according to the order of keyword appearance in the output text. Whether adjacent terms have an edge connection in the semantic graph is extracted. If so, it is recorded as a path match. If not, but there is an indirect connection with a co-occurrence relationship edge distance of less than 2, it is recorded as a weak match. The total number of all path matches and weak matches S is counted, and the matching degree value is calculated with the output word pair sequence length T, i.e. (S / T)×100%. If T is 0, the match is 0%. The match threshold is set to 50%. If the threshold is lower than this, the output structure is considered to deviate from the main path of the semantic graph. The match result is recorded as a floating point number and passed to the subsequent module.

[0057] Determine the output error based on keyword coverage and semantic matching to obtain output error data;

[0058] In this embodiment, the error is defined as the weighted deviation value of coverage and matching degree, and the weight is set to 0.4 for coverage and 0.6 for matching degree. The formula calculation is not reproduced here, only the actual operation steps are described: the coverage and matching degree are input into the operation module respectively, and a single floating-point output error value is generated according to the weight configuration. The error classification standard is: an error value less than 20% is a low error, between 20%-50% is a medium error, and above 50% is a high error. According to the error level, the system extracts the corresponding language control parameters from the preset rule table. For example, a high error level corresponds to the activation of the "structural word adjustment", "term reinsertion", and "syntax repair" parameter sets. Each parameter set consists of multiple operation instructions.

[0059] extracting language control parameters based on output error data;

[0060] In this embodiment, the parameter table in the configuration file is called according to the error level. The parameter table is a JSON structure, and each item corresponds to a type of language control operation, including the parameter name, applicable error range, activation threshold and scope. For example, the "Syntactic Structure Adjustment" parameter is set to be enabled when the error is higher than 30%, and the scope of action is the replacement and order adjustment of keywords in all subject-predicate structures; the "Term Supplement" parameter is set to start when the coverage rate is lower than 40%, and the supplementary items are selected from the uncovered nodes in the semantic graph according to the weight. Each parameter call operation must indicate the start order, and the control instructions are sorted and executed in the call order array. After the parameters are extracted, they are not directly used for generation, but are passed into the structure output template construction process.

[0061] A structure output control template is constructed according to the language control parameters, and a result reflection layer is constructed to obtain result reflection layer data.

[0062] In this embodiment, the control template is a multi-level rule structure, and each template includes a title sentence template, a main paragraph template, a supplementary term template and a conjunction template, etc. In the construction process, the template type is selected according to the language control parameters. For example, when the parameters include "term supplement", the main template structure with redundant term paragraphs is called. If it includes "syntactic structure adjustment", the subject-predicate structure transformation rules are added to the template, such as subject advancement, verb-object reordering, etc. The conjunction template inserts segmented vocabulary such as "in addition" and "compared to" according to the semantic clustering boundary. The constructed template outputs a new text after being filled with variables. The result reflection layer is a structured data set, which records the template type, usage parameters, semantic graph path, number of covered nodes, number of syntactic adjustments and final output text length each time it is generated, forming an execution trajectory log for subsequent training optimization, and the output is a structured JSON array containing all the generated component call details.

[0063] Preferably, the construction process reflection layer in step S2 is specifically as follows:

[0064] Identify the task execution path based on the knowledge retrieval data and obtain the task execution path data;

[0065] In this embodiment, behavioral record data for each knowledge request process is extracted from stored knowledge retrieval data. This data includes, but is not limited to, fields such as user input content, matching keywords, matching path, calling component name, response generation timestamp, return content length, and execution component number. The operational process uses the Logstash module in the ELK log processing engine to extract structured behavioral data. The call sequence in each request is sorted by timestamp to form an ordered task execution list. For example, in a knowledge retrieval task, the keyword "agent deployment" is input. The system calls the keyword extraction module (component number A1), the semantic clustering module (component number B3), and the template filling module (component number C2). The execution order of these three steps is recorded as [A1, B3, C2] and associated with the input and return content. The above operation builds an index structure based on Elasticsearch, using the user request ID as the primary key field. Each task execution list is stored as a document node, ultimately forming a complete set of task execution path data, containing no less than 500 task samples as the initial data foundation.

[0066] Building a path decision tree based on the task execution path data to obtain path decision tree data;

[0067] In this embodiment, the representation format of the task path is unified, and each task path is serialized into a fixed format string according to the component number. For example, the path "A1-B3-C2" represents a complete path. The path data is then structurally modeled using the sklearn.tree.DecisionTreeClassifier tool in Python. The input data is the path sequence and its execution performance label, such as processing time (milliseconds) and whether it returns successfully (Boolean value). During the construction process, "information gain" is used as the division criterion, the maximum depth of the tree is set to 10, and the minimum number of leaf node samples is set to 5 to ensure that the path node division is statistically significant. All path branches use the component number as the splitting node, and each layer of splitting represents whether a component in the task process is called, thereby forming a complete decision structure. The path decision tree data is exported in JSON format, which contains the component number, conditional judgment, sub-path branch number and corresponding task execution label of each decision node. This data is used for subsequent inefficient node identification operations to ensure that each sub-path structure has clear path statistical support.

[0068] Identify inefficient nodes based on path decision tree data and obtain inefficient node data;

[0069] In this embodiment, the operation of identifying inefficient nodes based on path decision tree data includes two sub-steps: the first is to calculate the average execution time and failure rate of the corresponding nodes in each decision path. The execution time is directly calculated through the start and end timestamp fields returned by the component, and the failure rate is achieved by counting the proportion of empty or abnormal status codes returned; the second is to set a threshold standard to identify inefficient nodes. Nodes with an average execution time greater than 500ms and a failure rate greater than 0.3 are set as inefficient nodes, and the node numbers are recorded in a list. For example, if the average execution time of component B3 in all occurrence paths is 634ms and the failure rate is 0.37, it is identified as an inefficient node. The implementation logic uses Pandas to perform path data aggregation and grouping statistical operations, and combines Boolean filtering functions to extract a list of node numbers that meet the above two criteria. Finally, the inefficient node data is output and saved in list form, excluding duplicates and non-task process nodes, to ensure that only component numbers that truly affect task execution efficiency are extracted.

[0070] Calculate the node call frequency based on the inefficient node data to obtain high-frequency inefficient node data;

[0071] In this embodiment, the operation of calculating the node call frequency based on the inefficient node data needs to re-trace all task execution path data and count the total number of times each inefficient node appears in the path. This operation is implemented by traversing all path sequences, matching the component numbers in the path string, and using Python's collections.Counter to perform frequency statistics. The frequency threshold is set to a number of occurrences exceeding 30% of the total number of all task paths. For example, if the total number of task paths is 1000, then an inefficient node with a call frequency of more than 300 times is a high-frequency inefficient node. During the statistical process, the context component number pairs that appear in different comparison paths for each high-frequency inefficient node are recorded at the same time to form node context data. Finally, the high-frequency inefficient node data is output in the form of a key-value pair, where the key is the node number and the value is the number of occurrences and the corresponding path context list, which is used to determine the cache replacement granularity and coverage when configuring the cache strategy.

[0072] Configure the result cache storage strategy based on high-frequency and inefficient node data to obtain result cache data;

[0073] In this embodiment, a cache space is established for each high-frequency, low-efficiency node. The cache structure is implemented using a Redis database. The cache key is composed of the node component number and the hash value of its input parameters. The input parameters are hashed using the SHA-256 algorithm, and the cache value is the text of the component's historical return results under specific input conditions. The cache time is set to 300 seconds, and the cache hit strategy uses a LRU eviction mechanism. The cache capacity is limited to no more than 1,000 results per node. During configuration, all input condition caches with a hit frequency exceeding 10 are set to be forced preloaded. The cache preload uses an initialization script to load the cache database during the task engine startup phase. All cache configuration parameters are written to the Redis configuration file in the path / etc / redis / cache_config.json. This includes the cache key template, maximum cache entry count, expiration time, and LRU weight value for each component number. This ultimately creates structured result cache data, including the cache key value strategy, hit frequency records, and component binding rules. This ensures that high-frequency, low-efficiency nodes are not recalculated in subsequent processes. All cached results record the calculation source path and result timestamp.

[0074] Reconstruct the task process based on the result cache data, build a process reflection layer, and obtain the process reflection layer data.

[0075] In this embodiment, the task flow execution engine logic is first modified. The entry point function for each call to a high-frequency, inefficient node component is replaced with a cache query entry. Redis's GET interface is used to retrieve cache hits before execution. If a hit is found, the cached result is directly returned, skipping the actual component call. The modified task flow execution sequence is recorded as a new version of the flowchart. A visual flowchart is automatically generated using Mermaid flowchart syntax and stored in the task recording system. Simultaneously, a process reflection layer is constructed to record all cache hit data, actual component call data, and the task execution path and its changes for each task execution. The reflection layer data structure is stored in a MongoDB document database. Each reflection document contains fields such as task ID, original path, new path, list of cache node numbers hit, hit time, hit parameter values, and the identifier of the skipped component call function. All reflection layer data is aggregated and statistically analyzed daily, outputting analysis results such as cache coverage, component call reduction, and overall process compression rate. These are used by the system scheduler for optimizing the next process schedule. The process reflection layer data is ultimately output in JSON format, with data accuracy preserved down to millisecond timestamps and a document structure with no more than three nested levels to ensure efficient database indexing.

[0076] Preferably, the strategy reflection layer is constructed in step S2 as follows:

[0077] Extract business rules based on knowledge retrieval data to obtain business rule data;

[0078] In this embodiment, the structured business operation mode is extracted based on the archived knowledge retrieval request content. First, the retrieval request statement is segmented and grammatical phrases are extracted using regular expression rules. For example, the keywords "query", "first quarter of 2023", "production data report", "workshop classification and sorting" and other operation intention phrases are identified from the retrieval statement "query the production data report for the first quarter of 2023 and sort it by workshop classification". Then, classification is performed by setting the operation intention template. The template structure includes four fields: "operation type + object + restriction + display format". The operation type field is centered on verb phrases, such as "query", "generate", and "compare"; the object field is unified as entity keywords, such as "report" and "fault record"; the restriction field is composed of words such as time, place, and status; the display format field extracts keywords such as "chart", "list", and "ranking". After extraction, each structured template is assigned a unique identification number, such as the rule ID BR-20230613-001. All extracted business rules are stored in JSON format. Each record contains the template structure fields, source search content, call frequency, trigger component path, business response parameter type, and associated context entities. Business rule data is stored in a MongoDB collection named "BusinessRules," and a keyword inverted index is constructed to support fast search.

[0079] Obtain historical decision output records;

[0080] In this embodiment, the operation of obtaining historical decision output records uses the decision execution log of the agent platform as the data source, extracting the output result records of all task decision modules from the platform database, including fields such as the input parameters, selection path, decision node, output response, timestamp, trigger context, and feedback score value for each decision task. The operation uses an SQL script to query a table named "DecisionLog" in the PostgreSQL database. The query statement limits the records to records where the decision output field is not null, the feedback score field is not NULL, and the execution status field is "success" or "fail". After extraction, all fields are uniformly formatted into a JSON object structure, where "input_context" is the task context text, "decision_result" is the recommended option given by the system, "response_time" is a millisecond timestamp, "feedback_score" is a floating point number between 0 and 1, and "path_id" is the system path ID. This data is sorted by time series and deduplicated to ensure that there are no duplicate records, ultimately obtaining a set of no less than 100,000 historical decision output records. All data undergoes a field mapping check before being imported into the analysis environment to ensure consistent key names and standardized units (time in milliseconds, fractions in decimals, and paths in standard numbers). It is then stored in a MongoDB collection named "DecisionHistory" and an index is created with the path number as the primary key.

[0081] Conduct cognitive bias analysis based on historical decision output records and business rule data to obtain cognitive bias data;

[0082] In this embodiment, the process of analyzing cognitive bias based on historical decision output records and business rule data consists of two steps. The first step is to identify multiple historical decision outputs corresponding to the same business rule and calculate their output consistency across different contexts. Specifically, this involves traversing the rule ID of each rule in the business rule data, filtering all records corresponding to that rule ID in the historical decision records, and calculating the distribution frequency of the corresponding decision result field (decision_result). For example, if a rule ID outputs "Option A" 25 times, "Option B" 15 times, and "Option C" 10 times in 50 records, the output bias calculation formula is: Bias = 1 - (maximum frequency / total frequency) = 1 - 0.5 = 0.5. A bias threshold of 0.3 is set; any deviation above this threshold is considered to indicate cognitive bias. The second step is to perform semantic distance analysis on the biased output records, using the Jaccard text similarity algorithm to compare the similarity between different input contexts. If the similarity is greater than 0.8 but the corresponding decision output is different, the item is marked as a potential cognitive bias. The deviation record data structure includes the business rule ID, deviation value, context example pair, output difference type (suggestion conflict, execution path split, etc.) and number of occurrences. All deviation items are recorded in the "CognitiveBias" collection. Each record contains a unique number, the corresponding business rule ID, a statistical timestamp, a context difference description field and an output conflict example field.

[0083] Generate knowledge structure update demand based on cognitive bias data to obtain knowledge structure update demand data;

[0084] In this embodiment, the steps for generating knowledge structure update requests based on cognitive bias data require parsing each record in the cognitive bias data into units requiring knowledge update. First, the output difference field in each cognitive bias record is parsed, and conflicting items are extracted as explicit knowledge nodes. For example, "Solution A" and "Solution B" are used as decision output nodes. A semantic conflict relationship is established between the two, forming a knowledge update request pair. Next, keywords are extracted from the context field to identify whether there are associated entity nodes in the current knowledge graph. If not, this is treated as a new concept node request. If there are but the connecting edge attributes conflict, this is treated as an edge attribute modification request. The knowledge structure update request data format is encoded using an RDF triple structure. The triple consists of a "subject-predicate-object" structure, where the subject is the context entity node, the predicate is a relationship such as "recommended output," "dependency rule," or "conflict generated," and the object is the target decision outcome or recommended item. All update requests are labeled with the update type (add, delete, replace), impact path, context source, and deviation number. The update request data is uniformly written into the pending area of ​​the Neo4j graph database named "KnowledgeUpdateRequest", and the update mark is set to "Not Executed".

[0085] Convert the knowledge structure update demand data into graph reconstruction demand data;

[0086] In this embodiment, dependency path analysis is performed on each knowledge update request record to identify the node range and edge connectivity structure affected within the graph structure. A depth-first search algorithm is used to traverse the graph nodes and calculate the path coverage of the target node in the knowledge update request within the existing graph. The maximum path depth is set to three levels, and out-of-range nodes are automatically excluded to ensure that the reconstruction requirements are controlled within the local subgraph. Next, edges with attribute conflicts are annotated, recording the starting node, edge type, old attribute value, and new proposed value of the conflicting edge. Finally, all graph node IDs, edge IDs, and operation types that require modification are encapsulated into a reconstruction task unit. The data structure includes: task ID, subgraph node set, edge set to be deleted, edge set to be added, edge attribute set to be modified, expected update timestamp, and version control identifier. Graph reconstruction request data is exported in YAML format, containing explicit reconstruction instructions, graph module number, namespace, and relationship type to ensure parsing within the graph engine. All graph reconstruction tasks are written to a task scheduler named "GraphRebuildTasks" and initialized to a "waiting for execution" state. Each task must be assigned a version rollback flag to support failure recovery.

[0087] The knowledge graph structure is adjusted based on the graph reconstruction demand data, and a strategy reflection layer is constructed to obtain the strategy reflection layer data.

[0088] In this embodiment, the reconstruction execution engine is called in the graph management module, and the subgraph reconstruction operations are executed one by one according to the reconstruction instructions recorded in the task scheduling table. Before each subgraph reconstruction is executed, a graph snapshot backup is performed first. The backup is completed using the export module provided by the Neo4j graph database, and the file is named "graph_snapshot_taskID.graph". Subsequently, transactions are submitted to the graph database one by one according to the operations of adding edges, deleting edges, and modifying attributes listed in the reconstruction task. The transaction execution adopts the ACID mode to ensure structural consistency. After the reconstruction of the graph structure is completed, the strategy reflection layer data is immediately constructed. The reflection layer records the deviation number, reconstruction task ID, number of modified nodes, number of relationships, backup snapshot path, trigger rule ID, expected change range and actual execution impact path list involved in this reconstruction. All reflection layer data is uniformly written to the "StrategyReflectionLayer" collection in the MongoDB database, and each record is bound to a unique strategy number and graph update version number. The reflection layer data aggregation script is run once every 24 hours to count evaluation dimensions such as the source frequency of various update requests, the coverage of trigger rules, and the number of path changes after the update. This is used for subsequent strategy fine-tuning and version control to ensure that the reconstruction and reflection process is structurally closed-loop managed.

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

[0090] Step S31: performing result reflection analysis based on the three-level reflection system data to obtain result reflection data; restoring the result reflection path based on the result reflection data to obtain result reflection path data;

[0091] In this embodiment, the three-level reflection system data output from the policy reflection layer serves as the input data source. This data includes the first-level policy reflection records (used to describe the original policy output behavior), the second-level intermediate state monitoring records (used to characterize the state changes of key nodes during policy execution), and the third-level external feedback comparison data (used to record the differences between the external environment or standard output and the policy output). This three-level data set undergoes structured mapping processing, using a structured vector encoding method to map it into a state vector S1, a behavior path vector S2, and a feedback error vector S3. These are aligned in chronological order. A bidirectional time window sliding analysis is performed, with the window size set to 10 consecutive records and a 60% overlap. Within each window unit, a behavior-feedback matching ratio analysis is performed, calculating the vector Euclidean distance between the policy output and the feedback error and recording it as the error magnitude. Behavioral paths with an error magnitude exceeding 0.7 (this threshold is determined by the 95th percentile obtained from statistics of 100,000 historical data sets) are extracted as result reflection points. A path tracing mechanism (using the node number in the behavior path as the primary key and a breadth-first search method) is then used to construct a set of paths from the current reflection point to the original decision starting point, which is named the result reflection path data. The path set contains the behavior label, state feature vector, upstream and downstream connection node ID and timestamp of each node, and is stored as a directed graph structure to form a complete result reflection path dataset.

[0092] Step S32: identifying strategy deviations based on the result reflection path data to obtain strategy deviation data; reorganizing the prompt word structure based on the strategy deviation data to obtain prompt word structure data; fusing multi-level control semantics based on the prompt word structure data to obtain prompt word optimization data;

[0093] In this embodiment, the resulting reflection path data output from step S31 is used as input. Deviations are first identified for all policy branch nodes in the path. This identification is performed by setting a policy deviation index, P_dev, defined as the cosine similarity difference between the state vector of the actual behavior output and the expected target state vector. The specific calculation method is: P_dev = 1-cos(θ). A node is identified as a policy deviation when P_dev is greater than 0.25 (determined by the intersection of the historical deviation classification error curve). Deviation nodes and their corresponding behavior semantic labels in all paths are counted to form a policy deviation data set. A prompt word restructure operation is performed on this policy deviation data. The semantic labels of the deviation nodes are mapped to their upstream semantic control units (e.g., "plan," "scheduling," and "retrieval") using the structure rewriting rules defined in the syntactic rule library. For example, if the deviation point is "resource allocation failure," the original prompt word structure "perform task allocation" is rewritten to "perform task allocation after recalibrating the resource pool." All structure rewriting operations are performed based on a predefined dependency syntactic graph mapping rule library. Models are not used, and structural adjustments are performed directly after matching semantic templates. Finally, the reconstructed prompt word structure data is integrated with multi-level control semantics (including three semantic dimensions: operation, constraint, and target) through a semantic fusion rule table to generate optimized prompt word data. The control semantic fusion process requires that each prompt word simultaneously contain an "action-condition-target" triple expression. Otherwise, it is marked as "semantically incomplete" and not output.

[0094] Step S33: performing node load balancing according to the three-level reflection system data to obtain node load balancing data;

[0095] In this embodiment, all system nodes involved in the policy execution process are classified into four categories according to their roles: decision processing nodes, information retrieval nodes, prompt generation nodes, and knowledge fusion nodes. Three types of load indicators are extracted for each node: call frequency, processing time, and input and output data volume. These indicators are recorded as F (frequency), T (duration), and D (data volume), with units of times / hour, seconds, and MB, respectively. After normalization, a node load vector Vn=[F', T', D'] is constructed, where F'=F / Max(F_all), and the rest are deduced in the same way. The load vectors of all nodes are sent to the outlier detection module based on the standard deviation distribution. The load fluctuation coefficient threshold is set to 0.15 (that is, if the standard deviation difference between a node and other nodes is greater than 0.15, it is marked as high load). Node classification is performed, and a set of low-load nodes and a set of high-load nodes are output. Perform load transfer operations on high-load nodes. The transfer rule is: if the functional roles of two nodes are consistent and logically replaceable (the judgment method is based on the node function label matching degree greater than 0.8), then replace the original binding node identifier in the task flow with the target node identifier with a lower load, forming an adjusted task pointing graph structure and outputting the node load balancing data.

[0096] Step S34: identifying the task node based on the node load balancing data to obtain task node data; identifying the task dependency relationship based on the task node data to obtain task dependency relationship data;

[0097] In this embodiment, the task graph structure, adjusted after load balancing in step S33, is used to identify logical start and end nodes, and the task graph is traversed hierarchically. A depth-first search algorithm is used, starting from the start node, to record visited nodes layer by layer, labeling them with task operation labels and task IDs. Each time a complete path record is completed, a task node data unit is generated. Each task node data structure includes fields such as the task ID, task operation type (such as "retrieval trigger," "rule analysis," or "semantic fusion"), the node ID to which it belongs, the set of predecessor task IDs, the set of successor task IDs, the processing time threshold (calculated by adding the historical average and standard deviation), and the resource requirement level. Based on this, dependency analysis is performed on all task nodes. Using a graph topology sorting method, the forward and backward constraints between tasks are determined. If an output field in task A depends on the processing result of task B, then A is recorded as dependent on B, forming a task dependency edge set. Dependency determination criteria include field name matching (edit distance less than 3) and field type consistency, as well as the intersection of field value usage ranges as a prerequisite for determining the establishment of a dependency relationship. Ultimately, the task node data and the task dependency data set are output.

[0098] Step S35: reconstructing the task chain according to the task dependency data to obtain task chain data;

[0099] In this embodiment, based on the task dependency graph structure, all subgraphs with redundant branches and loop paths are identified. The redundant branch identification rule is: if two task nodes A and B meet the output field consistency and processing logic similarity greater than 0.85 (determined by the operation label matching table), and ultimately point to the same target task C, they are merged into one branch. The loop path identification rule is: if there is a closed loop structure in the graph where task A depends on B, B depends on C, and C depends on A, then the node with the minimum processing time is set as the loop breakpoint, breaking its one-way dependency. After completing the redundancy and loop cleaning, all task nodes are reordered, and the total processing time of each path is calculated using the topological sorting + critical path algorithm. The path with the longest processing time is selected as the main task chain, and the relative path structure of all branch task chains is recorded, the dependency hierarchy and trigger conditions are annotated, and finally the task chain dataset is output. The task chain structure is stored in JSON format, containing field information such as chain ID, task sequence, time per step, required nodes, and execution resource level.

[0100] It is particularly important that step S35 includes the following steps:

[0101] Step S351: parse the task nodes according to the task dependency data to obtain task chain node data;

[0102] In this embodiment, it is necessary to obtain structured data containing all tasks and their dependencies. This data is usually stored in the form of a directed graph, where nodes represent specific tasks and edges represent dependencies between tasks. During the parsing process, graph traversal techniques (such as depth-first traversal or breadth-first traversal) are used to traverse the task dependency graph to identify all independent task nodes and their predecessor and successor nodes. Each task node contains a unique task identifier, task type, execution time estimate, input and output parameters, and a list of dependent tasks. Task node information is extracted through the traversal operation and stored as a structured task chain node data table. The table fields include task ID, dependent task ID list, estimated execution time (unit: milliseconds), task type code, etc. During the parsing process, data integrity is strictly verified to ensure that there are no isolated nodes and all dependencies are clear and there are no loops. After the parsing is completed, the obtained task chain node data can be directly used for subsequent sorting and path analysis.

[0103] Step S352: Prioritize the task chain node data to obtain sorted task node data;

[0104] In this embodiment, the priority value is first calculated for each task node. The priority calculation adopts a weighted algorithm based on the task dependency depth and task urgency. The specific method is: calculate the dependency hierarchy depth of each node. The greater the hierarchy depth, the higher the priority. The urgency is calculated by the difference between the preset task deadline and the expected task execution time. The smaller the difference, the higher the urgency. The priority value is the linear weighted sum of the hierarchy depth and the urgency, and the weights are set to 0.7 and 0.3 respectively. The priority values ​​of all task nodes are sorted, and the sorting method adopts the heap sort algorithm to ensure that the time complexity is O(nlogn), where n is the number of task nodes. After the sorting is completed, a sorted task node data structure is generated, which contains the task ID and the corresponding priority value for subsequent path analysis. Priority sorting ensures that tasks with high dependency levels and close to the deadline are given priority.

[0105] Step S353: performing path analysis based on the sorted task node data to obtain task chain path data;

[0106] In this embodiment, the task dependency graph is combined with the priority sorting results, starting from the starting node, and a topological sorting combined with a dynamic programming method is used to determine the task execution path. Topological sorting is used to ensure that the execution order satisfies the dependency constraints, and dynamic programming is used to calculate the cumulative execution time and resource consumption of each path to ensure that path selection takes into account both efficiency and resource utilization. During the analysis process, the list of sorted task nodes is traversed, the earliest start time and the latest completion time of each node are updated in sequence, and the predecessor task path of each task node is recorded. These time parameters are used to identify the key tasks and bottleneck tasks in the path. The path analysis results form task chain path data, which contains fields such as task execution order, path time consumption, and critical path identifier. This data structure is stored in the form of a directed acyclic graph to facilitate subsequent reconstruction of the execution order.

[0107] Step S354: reconstructing the execution order according to the task chain path data to obtain reconstructed task chain data;

[0108] In this embodiment, the path data is subjected to dependency verification and sequence optimization. In the verification step, the execution order of all tasks is checked to see if it satisfies the task dependency constraints, and the path is validated using a topological sorting algorithm. Sequence optimization uses a task scheduling method based on a heuristic algorithm to adjust the order of tasks on the timeline, reducing idle waiting time and resource conflicts. The heuristic algorithm parameters include the task switching delay time (set to 5 milliseconds), the task execution priority weight (calculated based on step S352), and the task resource occupancy rate (obtained through resource demand data, with the threshold set to 80% resource occupancy, which is considered high load). By repeatedly iteratively adjusting the task execution sequence, it is ensured that the execution time window of each task in the task chain maximizes the utilization of system resources, ultimately forming optimized reconstructed task chain data. This data records the optimized task execution order and corresponding timestamps in detail.

[0109] Step S355: Perform structural optimization based on the reconstructed task chain data to obtain task chain data.

[0110] In this embodiment, when performing structural optimization based on reconstructed task chain data, the focus is on adjusting the node connectivity and overall structure within the task chain, employing graph theory techniques such as minimum spanning trees and task merging. Structural optimization first identifies redundant dependencies and task fragmentation within the task chain. By analyzing task execution time and resource usage, task nodes are merged. Merging criteria include task execution time differences of less than 10 milliseconds and identical dependencies. Secondly, a minimum spanning tree algorithm is used to reconnect task nodes, reducing duplicate dependency edges in the execution path and optimizing the task chain topology. Parameters used in the structural optimization process include the maximum allowable task delay (set to 15 milliseconds), the node merging threshold, and the dependency redundancy determination criterion (dependency edges with weights below 0.1 are considered redundant). After optimization is complete, task chain data is generated. This data describes the optimized task chain nodes, dependencies, task execution order, and related performance indicators, supporting efficient scheduling and execution of the intelligent agent management platform.

[0111] Step S36: Detect resource consumption according to the task chain to obtain resource consumption data.

[0112] In this embodiment, four resource types are preset, including CPU utilization, memory usage, disk I / O read / write volume, and network bandwidth consumption. A basic unit consumption table is set for each resource type. For example, the average CPU consumption for a single "knowledge retrieval operation" is 0.5 cores, memory usage is 120MB, disk I / O read / write volume is 10MB / s, and network bandwidth usage is 0.1MB / s. This data is obtained by statistically averaging hardware resource monitoring indicators from nearly 10,000 operation log records. Each task node operation type in the task chain is mapped to obtain its standard resource consumption indicator, which is then corrected based on actual historical data (the correction factor depends on the specifications of the server to which the node belongs; for high-performance nodes, the resource consumption correction factor is set to 0.85). The usage of the four resource types is accumulated for the entire task chain, node by node, and the results are stored in a resource consumption data table. Each record includes fields such as the task chain ID, total CPU core hours, total memory MB, total I / O read / write volume MB / s, and network bandwidth MB / s. The resource detection results are used as input for resource pool allocation parameters in the subsequent scheduling optimization module.

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

[0114] Step S331: Counting the node execution status according to the three-level reflection system data to obtain the node execution status data;

[0115] In this embodiment, the system uses the operation log collection module deployed in each node of the intelligent body management platform to comprehensively count the data from the three-level reflection system. The collected data includes fields such as task ID, task start time, completion time, execution status code, number of CPU cores occupied, memory usage, and IO load. The log data is written to the centralized management database in JSON format. By aggregating and analyzing the data of different node numbers according to time intervals, the built-in data processing tools in Python are used to perform statistical operations on the number of tasks, number of completions, number of failures, average task duration, and average task resource consumption of each node. The statistical results are stored in a separate form called "Node Execution Status Data Table", where each node contains at least five statistical indicators, including the total number of tasks, the number of successful tasks, the number of failed tasks, the average execution time, and the average resource usage. This status data table will be used for load rate analysis in the next step.

[0116] Step S332: Calculating the node resource load rate based on the node execution status data;

[0117] In this embodiment, the system calls the resource monitoring module deployed on each node to obtain the resource usage status of the node, including the current CPU usage, memory usage and the number of currently active threads. The data is collected by polling every second, and the collection time lasts for five minutes. The formed data structure uses the node number as the primary key and is accompanied by time series resource occupancy data; the platform uses the time window sliding average method to process the collected data, and extracts the five-minute average usage of the CPU and memory respectively; at the same time, combined with the average task execution time and the number of completed tasks obtained in step S331, the resource processing capacity and resource usage of each node within the time interval are compared. The system marks this comparison value as the resource load rate of the node. After the load rate calculation of all nodes is completed, it is uniformly stored in the node load rate data set and prepared for subsequent priority calculation.

[0118] Step S333: Calculate the scheduling priority according to the node resource load rate, thereby obtaining node scheduling priority data;

[0119] In this embodiment, the system uses the node resource load rate data obtained in step S332 to divide the scheduling priorities of the nodes according to the preset load rate stratification intervals. The nodes with lower load rates are assigned higher scheduling priorities. The system sets four level intervals and defines them in the platform configuration file. All nodes are automatically assigned scheduling priority levels according to the stratification standards. At the same time, the system will mark the current status label of each node in the process of assigning scheduling priority, including "idle", "lightly occupied", "heavily occupied", and "resource critical", and record the priority level and status label together in the node scheduling priority data set. The data set is used as a key reference table in the task allocation strategy and is set to be refreshed only when resources change significantly.

[0120] Step S334: performing agent task allocation according to the node scheduling priority data to obtain agent task allocation data;

[0121] In this embodiment, the system performs task allocation operations based on node scheduling priority data and a list of tasks to be executed. The task list consists of three categories: knowledge retrieval, content generation, and solution optimization. Each task is marked with the computing resource requirement level and task completion time limit requirements during the task submission stage. The system enables the matching rule table in the task allocation module and prioritizes matching nodes that are currently idle or low-loaded and have a higher priority level based on the resource requirement level and completion time requirements of the task. If the priority node can carry multiple tasks, a polling strategy is used for parallel distribution. If the match fails, an attempt is made to recursively distribute it to the node with the next lower scheduling level. After the task allocation is completed, the mapping relationship between all tasks and nodes is written into the task scheduling mapping table and synchronized to the task distribution module for the task scheduling engine to call.

[0122] Step S335: Perform node load analysis based on the agent task allocation data to obtain node load balancing data.

[0123] In this embodiment, after the task allocation is completed, the system monitors the actual task processing status of each node in real time, re-collects the node resource status data before and after the task is issued, and performs difference analysis operations. The fields analyzed include changes in CPU utilization, memory utilization, thread growth, and changes in the average task execution time. The resource fluctuation data of all nodes are processed through the analysis script to form a node load deviation data set. The system calculates the current load distribution deviation level of each node by comparing the number of tasks of each node with the resource usage deviation value, and finally forms a node load balancing data table. This data table is used to detect whether there is a problem of uneven node load. If there is a deviation node that exceeds the preset threshold, the node number and current task ID set will be recorded for reference by subsequent load migration mechanism or task fallback mechanism.

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

[0125] Step S41: Identify the task resource type based on the resource consumption data to obtain task resource type data;

[0126] In this embodiment, the system first retrieves resource consumption data stored in the resource monitoring module. This data includes detailed metrics such as task ID, CPU usage time (in milliseconds), GPU usage time (in milliseconds), memory usage (in MB), and network bandwidth usage (in Mbps). By parsing each task's metrics in the resource consumption data, the task's resource type is identified using resource type determination rules set by the rule engine. Specific rules include: tasks with a CPU usage time exceeding 500 milliseconds and a GPU usage time less than 100 milliseconds are considered CPU-intensive; tasks with a GPU usage time exceeding 500 milliseconds and a memory usage less than 512 MB are considered GPU-intensive; tasks with a memory usage exceeding 1024 MB are considered memory-intensive; and tasks with a network bandwidth usage exceeding 100 Mbps are considered network-intensive. Based on these rules, the system automatically generates task resource type data, recording the mapping between task IDs and resource types. The data format is JSON, and each record contains the task ID, a resource type identification field, and a corresponding threshold metric for use in the next step of quantifying computing power requirements.

[0127] Step S42: quantify the computing power requirement according to the task resource type data to obtain the task computing power requirement data;

[0128] In this embodiment, the system quantifies computing power requirements using an empirical parameter method based on the task resource type data obtained in step S41, combined with task execution duration and peak resource consumption data. For CPU-intensive tasks, computing power requirements are quantified by calculating the product of CPU occupancy time (milliseconds) and node CPU frequency (GHz). The thresholds are set as 1000 GHz·ms for low demand, 3000 GHz·ms for medium demand, and 5000 GHz·ms and above for high demand. The computing power requirements of GPU-intensive tasks are calculated by multiplying the GPU occupancy time by the GPU core frequency. Memory-intensive tasks are categorized by peak memory usage: less than 2048 MB for low demand, 2048 MB to 8192 MB for medium demand, and greater than 8192 MB for high demand. The computing power requirements of network-intensive tasks are calculated based on bandwidth usage and the amount of data transmitted by the task: less than 200 Mbps·MB for low demand, 400 Mbps·MB for medium demand, and 800 Mbps·MB and above for high demand. The system stores the quantified results of the computing power requirements of all tasks in the task computing power requirement data table. The data fields include task ID, computing power requirement value, and requirement level. It is stored in CSV format for quick query and scheduling.

[0129] Step S43: Match heterogeneous hardware resources according to the task computing power requirement data to obtain preliminary hardware matching data;

[0130] In this embodiment, the system uses the task computing power requirement data generated in step S42 to match the heterogeneous hardware resource library supported by the agent management platform. This resource library details each node's CPU model, frequency, number of cores, GPU model, frequency, number of CUDA cores, memory capacity and bandwidth, and network interface bandwidth. Matching rules filter the resource library based on the task computing power requirement level, first selecting nodes with hardware configurations that meet the requirement level. For CPU-intensive tasks, nodes with a CPU frequency of at least 3.0 GHz and at least 8 cores are selected; for GPU-intensive tasks, nodes with a CUDA compute capability of at least 7.0 and at least 8 GB of video memory are selected; for memory-intensive tasks, nodes with a memory capacity greater than 16 GB; and for network-intensive tasks, nodes with a network bandwidth greater than 1 Gbps are selected. The system automatically extracts a set of nodes that meet the requirements from the resource library through query statements, generating preliminary hardware matching data. The data is stored in a table with fields including the task ID, matching node ID, and a snapshot of matching hardware parameters (CPU frequency, number of cores, GPU model, memory size, etc.) for subsequent simulation analysis.

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

[0132] Step S431: Perform hardware resource capability analysis based on the task computing power requirement data to obtain hardware resource capability data;

[0133] In this embodiment, key performance indicators (KPIs) are extracted from the task computing power requirement data, including but not limited to the number of CPU cores, GPU computing power (measured in floating-point operations per second (GFLOPS), memory bandwidth (in GB / s), storage I / O speed (in MB / s), and network transmission rate (in Gbps). The actual performance parameters of all currently available heterogeneous hardware resources are collected using system resource monitoring interfaces, such as the / proc file system in Linux or hardware management interfaces (e.g., IPMI). These parameters are compared against the required threshold standards for the task, such as a minimum of 8 CPU cores, a minimum of 5 TFLOPS GPU computing power, a minimum memory bandwidth of 100 GB / s, a storage I / O speed greater than 500 MB / s, and a minimum network transmission rate of 10 Gbps. Hardware resources that meet the task computing power requirements are screened to form a hardware resource capability data table. This data table details the model, performance indicator value, current utilization rate, and free resource capacity of each hardware resource for subsequent screening.

[0134] Step S432: Filter available heterogeneous hardware resources according to the hardware resource capability data to obtain a candidate hardware resource list;

[0135] In this embodiment, screening rules are set based on the degree of match between the performance indicators recorded in the hardware resource capability data and the task computing power requirements, including performance threshold satisfaction, resource idle rate greater than 30%, load rate less than 70%, etc. as screening criteria. The traversal algorithm is used to evaluate the hardware resource capability data one by one, and the hardware resources that meet all the screening rules are added to the candidate hardware resource list. In order to ensure load balancing, the physical location and network topology of the resources are also considered during screening, and nodes with low latency and high bandwidth are given priority. The screening results are stored in the form of a list, including the hardware resource identifier, specific performance indicators, current resource status, percentage of match with task requirements, and physical topology location, for subsequent matching.

[0136] Step S433: performing resource performance matching according to the candidate hardware resource list to obtain resource matching data;

[0137] In this embodiment, the performance indicators of each resource in the candidate hardware resource list are compared with the task computing power requirement data one by one, and the matching degree is calculated using a weighted scoring algorithm. The weight allocation is based on the importance of the task to different performance indicators, such as CPU performance weight 0.3, GPU performance weight 0.4, memory bandwidth weight 0.2, and storage IO weight 0.1. During the matching degree calculation process, the actual hardware performance value is standardized to the range of 0-1, compared with the standardized value of the task requirement, and the matching score of each indicator is obtained, which is then multiplied by the weight for weighted summation. Finally, the resource matching score is obtained, ranging from 0 to 1. After completing the calculation for all candidate hardware resources, the results are summarized to form a resource matching data table, recording the hardware resource identifier, the matching score of each performance indicator, and the comprehensive matching score.

[0138] Step S434: sorting the hardware resource priorities according to the resource matching data to obtain sorted hardware resource data;

[0139] In this embodiment, a descending sorting algorithm based on resource matching scores is used to sort the hardware resources in the resource matching data table from highest to lowest comprehensive matching score. This sorting algorithm uses a quick sort with a time complexity of O(nlogn), ensuring efficient processing of large numbers of hardware resources. The sorting results in a sorted hardware resource data structure containing information such as the hardware resource's unique identifier, corresponding matching score, detailed performance indicators, and the resource's current load, facilitating subsequent resource allocation.

[0140] Step S435: Perform resource allocation planning based on the sorted hardware resource data to obtain preliminary hardware matching data.

[0141] In this embodiment, hardware resources are allocated sequentially based on the sorting results, with resources with high comprehensive matching scores preferentially allocated to task submodules with higher computing power requirements. The allocation process adheres to the resource capacity limit and load balancing principles to ensure that the load rate of a single hardware node does not exceed 85%. A greedy allocation algorithm is used to gradually reduce the capacity of allocated resources based on the numerical value of the task computing power requirements until the computing power requirements of all task modules are met. After the allocation is completed, preliminary hardware matching data is generated, which records in detail the hardware resource identifiers, allocated computing power shares, and remaining resource capacity corresponding to each task module, ensuring that the matching solution can be directly called during the next task execution simulation.

[0142] Step S44: performing task execution simulation based on the preliminary hardware matching data to obtain task execution data; performing thread blocking point analysis based on the task execution data to obtain thread blocking data;

[0143] In this embodiment, the system performs task execution simulation based on the preliminary hardware matching data from step S43. During the simulation, a node simulator is invoked to simulate the task execution process based on real hardware parameters, including details such as task start time, execution time slice allocation, and thread scheduling. The simulation utilizes discrete event simulation technology. Input parameters include the task's computational load (computing power requirement), number of threads, and node hardware configuration. Output metrics include task execution time, CPU / GPU time occupied by each thread, and wait time. Based on the simulation results, the system analyzes thread blocking points, collecting the blocking time, blocking reasons (such as resource contention, waiting for I / O), and occurrence frequency of each thread during the simulated execution. Blocking point analysis scans thread execution logs, extracts blocking event timestamps and context, and combines this with CPU core usage and memory access conflict information to generate thread blocking data. The data structure includes thread ID, blocking type, blocking duration, frequency, and the node where the blocking occurred. The data is stored in XML format for easy subsequent parsing.

[0144] Step S45: performing thread binding adjustment on the preliminary hardware matching data according to the thread blocking data to obtain thread binding data; performing heterogeneous hardware collaborative scheduling according to the thread binding data to obtain heterogeneous hardware collaborative scheduling data;

[0145] In this embodiment, the system performs thread binding adjustment on the preliminary hardware matching data based on the thread blocking data obtained in step S44. During the adjustment process, the system analyzes the mapping relationship between the blocking point and the hardware resources, and rebinds the threads with higher blocking rates to the computing cores or independent hardware units with low blocking rates to reduce resource competition. The binding rule depends on the blocking duration threshold. Threads blocked for more than 50 milliseconds must be rebound. The binding operation includes thread migration and priority adjustment. After completing the thread binding adjustment, the system performs heterogeneous hardware collaborative scheduling on the adjusted thread allocation status. The scheduling module comprehensively considers the hardware performance indicators and thread priorities based on the thread binding data to achieve task execution coordination across nodes and multiple hardware resources. The collaborative scheduling process records the scheduling path, resource allocation ratio and load balancing indicators to form a heterogeneous hardware collaborative scheduling data table, which includes task ID, thread ID, bound hardware unit and scheduling time slice distribution, and is stored in JSON format for easy management.

[0146] Step S46: construct an intelligent agent management platform based on the heterogeneous hardware collaborative scheduling data and the prompt word optimization data, and perform adaptive adjustment on the knowledge retrieval strategy of the intelligent agent management platform to obtain adaptive strategy data.

[0147] In this embodiment, the platform maps hardware resource utilization and thread scheduling efficiency metrics in the scheduling data with semantic hierarchical information in the prompt word structure, defines a mapping rule table, and uses the node response time and load balancing in the scheduling data as trigger conditions to dynamically adjust the search scope and depth of the knowledge retrieval module. The adaptive adjustment process includes parsing the scheduling data, extracting key performance indicators, combining the multi-level semantic fusion results in the prompt word optimization data, and reconfiguring the search index weights and filtering thresholds. The adjustment results generate an adaptive strategy data file, which includes the strategy version number, adjustment parameter values, corresponding task category, and timestamp. The file format is YAML and is used for real-time scheduling of subsequent tasks and updating retrieval strategies in the intelligent agent management platform.

[0148] Preferably, step S46 is specifically as follows:

[0149] Step S461: performing node distribution analysis based on the heterogeneous hardware collaborative scheduling data to obtain node distribution data; performing scheduling unit division based on the node distribution data to obtain scheduling unit data; performing module resource mapping based on the scheduling unit data to obtain module mapping data;

[0150] In this embodiment, the system first performs node distribution analysis based on heterogeneous hardware co-scheduling data. The data used includes node identification, task allocation, hardware resource utilization, and time-series load change information. Node distribution analysis calculates the node load balancing index by counting the number of tasks each node undertakes, resource utilization, and task execution time. The load balancing index is calculated as the weighted average of the node's CPU utilization, GPU utilization, and memory utilization, with weights set to 0.5, 0.3, and 0.2, respectively. Nodes with a load balancing index exceeding 0.8 are marked as high-load nodes, and those below 0.3 are marked as low-load nodes. Based on node load and geographic network topology, a clustering algorithm (such as K-means, with the number of clusters set to the integer square root of the total number of nodes) is used to group nodes to generate node distribution data. This data structure is indexed by the node group ID and contains records containing a list of nodes, the load balancing index of nodes within the group, and the average network latency. The system then divides scheduling units based on the node distribution data. The scheduling unit division rule is based on load balancing within a node group and network latency thresholds. Nodes with network latency no greater than 5 milliseconds and a load index difference no greater than 0.15 are assigned to the same scheduling unit. Scheduling unit data records information such as the unit ID, the node set to which it belongs, and the total resources within the unit (number of CPU cores, number of GPU cores, and total memory). This data is formatted in JSON for easy subsequent processing. Finally, the system performs module resource mapping based on the scheduling unit data. This mapping process involves matching the resource specifications required by the functional module with the resource capabilities of the scheduling unit. Resource specifications include the number of CPU cores, number of GPU cores, memory capacity, and network bandwidth. The specific values ​​are determined in the functional module design documents. For example, the search module requires a 4-core CPU, 1 GPU unit, and 8GB of memory, while the generation module requires a 6-core CPU, 2 GPU units, and 16GB of memory. The system traverses all scheduling units and matches those that meet these resource specifications as module mapping targets. The system then outputs module mapping data, which includes the module ID, the mapped scheduling unit ID, and detailed resource matching metrics. The data is structured in a table format, enabling quick querying.

[0151] Step S462: performing semantic detection based on the prompt word optimization data to obtain semantic data;

[0152] In this embodiment, the system performs semantic detection based on the prompt word optimization data. The prompt word optimization data includes a hierarchical vocabulary list, part-of-speech tagging, a semantic relationship graph, and optimized historical versions. The semantic detection process uses a method that combines lexical semantic matching with dependency syntax analysis. First, the prompt word text is segmented. The word segmentation tool uses a dictionary-based and rule-based word segmenter with a stop word list length of 5000 to ensure the removal of invalid words. The word segmentation results are then tagged with parts of speech. The part-of-speech probability distribution is calculated using a statistical language model, and the part-of-speech with the highest probability is selected as the final part-of-speech. Subsequently, the system constructs a dependency syntax tree, analyzes the grammatical relationships between words, and generates a dependency graph. Based on the dependency graph and lexical semantic similarity calculations, the system detects semantic clusters, using a cosine similarity threshold of 0.75 as the judgment criterion to aggregate semantically similar phrases. Ultimately, the detection results are converted into semantic data, including lexical entities, semantic categories, dependency relationships, and semantic cluster identifiers. The storage format uses XML to facilitate subsequent parsing and intent extraction.

[0153] Step S463: Analyze the behavior intention according to the semantic data to obtain behavior intention data; select the function module according to the behavior intention data to obtain function module data;

[0154] In this embodiment, behavioral intent analysis utilizes a method based on semantic rule matching and comparison with a behavioral pattern library. The behavioral pattern library contains predefined behavioral templates that clearly describe the intent keyword set, trigger conditions, and corresponding behavior codes. For example, a semantic cluster containing terms such as "query," "retrieval," and "optimization" is mapped to the "information retrieval" behavioral intent. The system scans the lexical entities and dependencies within the semantic data and determines the intent match based on a keyword coverage threshold (set at 70%) and semantic cluster completeness. If the match exceeds the threshold, the corresponding behavioral intent is confirmed. After analysis, behavioral intent data is generated, with fields including the behavioral intent code, intent description, and a list of matching keywords. Functional modules are then selected based on the behavioral intent data. The module selection rules are based on a behavioral intent code mapping table, mapping different intent codes to corresponding functional module IDs. For example, "information retrieval" corresponds to the search engine module, and "knowledge generation" corresponds to the text generation module. The module selection data contains the functional module ID, module name, and module description in JSON format, facilitating subsequent platform calls.

[0155] Step S464: constructing a platform logic architecture based on the module mapping data and the functional module data, thereby obtaining platform architecture data;

[0156] In this embodiment, the system combines the module mapping data obtained in step S461 with the functional module data in step S463 to build the platform's logical architecture. During the construction process, the deployment location of each functional module is first determined based on the module mapping data, that is, mapped to the corresponding scheduling unit. Based on the call dependencies and data flow paths between functional modules, a logical connection structure is designed to ensure that inter-module communication meets low latency and high throughput requirements. The communication protocol uses a message queue mechanism, supporting asynchronous communication and load balancing. Message queue configuration parameters include a queue length limit (default 1000 messages), a message timeout threshold (set to 5 seconds), and a number of retries (3 times). The logical architecture design also takes into account redundant backup mechanisms. Key modules are deployed with dual instances, and a heartbeat detection mechanism is used between instances. The heartbeat interval is 1 second, and the heartbeat timeout threshold is set to 3 seconds to trigger failover. Ultimately, the platform architecture data is generated, including module deployment nodes, inter-module communication topology, backup strategy, and fault detection parameters. The data is stored in YAML format to facilitate version control and dynamic adjustment.

[0157] Step S465: Construct an intelligent agent management platform according to the platform architecture data, and adaptively adjust the knowledge retrieval strategy of the intelligent agent management platform to obtain adaptive strategy data.

[0158] In this embodiment, the agent management platform constructed in step S464 is deployed and initialized. During the construction process, the operating environment of each module is first configured on a physical or virtual server based on the platform architecture data, computing resources are allocated, and network access permissions are set. Deployment utilizes automated scripts, whose parameters include the module deployment path, dependency library version numbers, and startup parameters (e.g., setting the number of threads to 8 and the memory limit to 16GB). Subsequently, the platform launches the module and loads the initial knowledge base and prompt word optimization data. Adaptive adjustment of the knowledge retrieval strategy is performed based on the aforementioned heterogeneous hardware collaborative scheduling data and prompt word optimization data, combining scheduling load, response latency, and prompt word level weights to adjust the retrieval index structure and weight distribution. The adjustment process includes reallocating index nodes, setting the index shard size (default 10MB), adjusting the retrieval filter threshold (set to 0.85 cosine similarity), and updating the retrieval cache policy (cache validity period 300 seconds). The adjustment results are output as adaptive policy data, including the policy version number, parameter adjustment details, and the effective timestamp, stored in JSON format. This policy data is continuously used to dynamically optimize retrieval performance and resource utilization during platform operation.

Claims

1. A method for constructing an intelligent agent management platform that supports knowledge retrieval, generation, and optimization, characterized in that: The following steps are involved: Step S1: Acquire multimodal data, and perform semantic fusion based on the multimodal data to obtain semantic fusion data; perform knowledge retrieval based on the semantic fusion data to obtain knowledge retrieval data; Step S2: Establish a three-level reflection system based on knowledge retrieval data, including building a result reflection layer, specifically: Extract core keywords based on knowledge retrieval data to obtain core keyword data; Draw the target semantic graph based on the core keyword data; Execute the answer generation process based on the target semantic graph and record it as output text to obtain the actual output data; Calculate keyword coverage based on the target semantic graph and actual output data; Calculate the semantic matching degree based on the target semantic graph and the actual output data; Determine the output error based on keyword coverage and semantic matching to obtain output error data; extracting language control parameters based on output error data; Construct a structure output control template based on the language control parameters, and construct a result reflection layer to obtain the result reflection layer data; construct a process reflection layer, specifically: Identify the task execution path based on the knowledge retrieval data and obtain the task execution path data; Building a path decision tree based on the task execution path data to obtain path decision tree data; Identify inefficient nodes based on path decision tree data and obtain inefficient node data; Calculate the node call frequency based on the inefficient node data to obtain high-frequency inefficient node data; Configure the result cache storage strategy based on high-frequency and inefficient node data to obtain result cache data; Reconstruct the task process based on the result cache data, build a process reflection layer, and obtain the process reflection layer data; And build a strategic reflection layer, specifically: Extract business rules based on knowledge retrieval data to obtain business rule data; Obtain historical decision output records; Conduct cognitive bias analysis based on historical decision output records and business rule data to obtain cognitive bias data; Generate knowledge structure update demand based on cognitive bias data to obtain knowledge structure update demand data; Convert the knowledge structure update demand data into graph reconstruction demand data; According to the graph reconstruction demand data, the knowledge graph structure is adjusted, and the strategy reflection layer is constructed to obtain the strategy reflection layer data, thereby obtaining the result reflection layer data, process reflection layer data and strategy reflection layer data, and performing hierarchical system integration to obtain the three-level reflection system data; Step S3: Optimizing prompt words based on the three-level reflection system data to obtain optimized prompt word data; Perform node load balancing based on the three-level reflection system data to obtain node load balancing data; Reconstruct the task chain based on the node load balancing data to obtain the task chain data; Detect resource consumption according to the task chain and obtain resource consumption data; Step S4: performing heterogeneous hardware collaborative scheduling based on the resource consumption data to obtain heterogeneous hardware collaborative scheduling data; An intelligent agent management platform is constructed based on heterogeneous hardware collaborative scheduling data and prompt word optimization data, and the knowledge retrieval strategy of the intelligent agent management platform is adaptively adjusted to obtain adaptive strategy data.

2. The method for constructing an intelligent agent management platform supporting knowledge retrieval, generation and optimization according to claim 1, characterized in that: Step S1 is specifically as follows: Step S11: Acquire multimodal data; Step S12: extracting intra-modal features based on the multimodal data to obtain modal feature data; Step S13: performing inter-modal alignment processing according to the modal feature data to obtain modal alignment data; Step S14: performing semantic association based on the modality alignment data to obtain semantic association data; Step S15: performing semantic fusion according to the semantic association data to obtain semantic fusion data; Step S16: Perform knowledge retrieval based on the semantic fusion data to obtain knowledge retrieval data.

3. The method for constructing an intelligent agent management platform supporting knowledge retrieval, generation and optimization according to claim 2, characterized in that: Step S16 is specifically as follows: Step S161: constructing a semantic vector based on the semantic fusion data to obtain semantic vector data; Step S162: performing similarity matching on multiple source knowledge bases based on semantic vector data to obtain candidate knowledge fragment data; Step S163: sorting the candidate knowledge fragment data based on semantic relevance to obtain sorted knowledge fragment data; Step S164: extract knowledge based on the sorted knowledge fragment data to obtain knowledge retrieval data.

4. The method for constructing an intelligent agent management platform supporting knowledge retrieval, generation and optimization according to claim 1, characterized in that: Step S3 is specifically as follows: Step S31: performing result reflection analysis based on the three-level reflection system data to obtain result reflection data; restoring the result reflection path based on the result reflection data to obtain result reflection path data; Step S32: identifying strategy deviation based on the result reflection path data to obtain strategy deviation data; Perform prompt word structure reorganization based on the strategy deviation data to obtain prompt word structure data; fuse multi-level control semantics based on the prompt word structure data to obtain prompt word optimization data; Step S33: performing node load balancing according to the three-level reflection system data to obtain node load balancing data; Step S34: identifying the task node based on the node load balancing data and obtaining the task node data; Identify task dependencies based on task node data and obtain task dependency data; Step S35: reconstructing the task chain according to the task dependency data to obtain task chain data; Step S36: Detect resource consumption according to the task chain to obtain resource consumption data.

5. The method for constructing an intelligent agent management platform supporting knowledge retrieval, generation and optimization according to claim 4, characterized in that: Step S33 is specifically as follows: Step S331: Counting the node execution status according to the three-level reflection system data to obtain the node execution status data; Step S332: Calculating the node resource load rate based on the node execution status data; Step S333: Calculate the scheduling priority according to the node resource load rate, thereby obtaining node scheduling priority data; Step S334: performing agent task allocation according to the node scheduling priority data to obtain agent task allocation data; Step S335: Perform node load analysis based on the agent task allocation data to obtain node load balancing data.

6. The method for constructing an intelligent agent management platform supporting knowledge retrieval, generation and optimization according to claim 1, characterized in that: Step S4 is specifically as follows: Step S41: Identify the task resource type based on the resource consumption data to obtain task resource type data; Step S42: quantify the computing power requirement according to the task resource type data to obtain the task computing power requirement data; Step S43: Match heterogeneous hardware resources according to the task computing power requirement data to obtain preliminary hardware matching data; Step S44: performing task execution simulation based on the preliminary hardware matching data to obtain task execution data; performing thread blocking point analysis based on the task execution data to obtain thread blocking data; Step S45: performing thread binding adjustment on the preliminary hardware matching data according to the thread blocking data to obtain thread binding data; Perform heterogeneous hardware co-scheduling according to thread binding data to obtain heterogeneous hardware co-scheduling data; Step S46: construct an intelligent agent management platform based on the heterogeneous hardware collaborative scheduling data and the prompt word optimization data, and perform adaptive adjustment on the knowledge retrieval strategy of the intelligent agent management platform to obtain adaptive strategy data.

7. The method for constructing an intelligent agent management platform supporting knowledge retrieval, generation and optimization according to claim 6, characterized in that: Step S46 is specifically as follows: Step S461: performing node distribution analysis based on heterogeneous hardware collaborative scheduling data to obtain node distribution data; performing scheduling unit division based on the node distribution data to obtain scheduling unit data; Perform module resource mapping according to the scheduling unit data to obtain module mapping data; Step S462: performing semantic detection based on the prompt word optimization data to obtain semantic data; Step S463: Analyze the behavior intention according to the semantic data to obtain behavior intention data; Select functional modules based on behavioral intention data to obtain functional module data; Step S464: constructing a platform logic architecture based on the module mapping data and the functional module data, thereby obtaining platform architecture data; Step S465: Construct an intelligent agent management platform according to the platform architecture data, and adaptively adjust the knowledge retrieval strategy of the intelligent agent management platform to obtain adaptive strategy data.

Images