A Multi-Agent-Based Intelligent Decision-Making Method for Bridge Maintenance

Abstract

This invention discloses a multi-agent-based intelligent decision-making method for bridge maintenance, comprising: constructing a multimodal data access layer to form a unified data access foundation; constructing a knowledge graph for the bridge maintenance domain, using directed multigraphs to perform structured modeling of knowledge; constructing a skill base for the bridge maintenance domain, encoding expert experience into skill templates; receiving user queries, using planning agents in conjunction with the skill base to perform intent recognition, scenario classification, and task decomposition, obtaining a sub-task list and updating the state space; resolving dependencies and routing them to specialized execution agents through a scheduler; each agent using the ReAct pattern to invoke tools, generating results, evidence, and trajectories, and writing them back; performing entity, relation, and attribute verification on the results based on the knowledge graph, generating an illusion detection report; and finally, the planning agent retrieving the results, evidence, report, and trajectory to generate a traceable intelligent decision response. This invention solves the problems of automatic decomposition of complex tasks and collaborative analysis of multi-source data.

Description

Technical Field

[0001] This invention relates to the field of intelligent transportation infrastructure operation and maintenance management, and in particular to an intelligent decision-making method for bridge maintenance based on multi-agent systems. Background Technology

[0002] As a crucial node in transportation networks, the operational safety and durability of bridges directly impact public safety and socio-economic efficiency. With the continuous growth in the number of bridges in my country and a large number entering their mid-to-late service stages, bridge maintenance management faces challenges such as the expansion of data volume, the complexity of structural conditions, and the high demands for timely decision-making. Currently, various bridge management systems, health monitoring platforms, and maintenance information platforms have been gradually established, capable of collecting structured data (such as assessment records and monitoring data), unstructured text (such as inspection reports and specification documents), and multi-source heterogeneous data such as images and videos.

[0003] However, existing technologies remain primarily at the "information management" or "single-point intelligent analysis" stage, exhibiting the following key shortcomings: First, multi-source heterogeneous data is scattered across different systems or modules, lacking a unified semantic modeling and association mechanism, making it difficult to achieve cross-data source linkage analysis and comprehensive reasoning. Managers need to repeatedly retrieve information across multiple systems, relying on human experience for comprehensive judgment, resulting in low efficiency and difficulty in standardizing decision-making logic. Second, existing systems lack the ability to automatically decompose and collaboratively execute complex decision-making tasks. When multi-step reasoning, cross-data source analysis, or the need to call external computing tools (such as finite element analysis) are involved, the system cannot form a complete reasoning chain, and lacks a mechanism for automatically decomposing, collaboratively processing, and integrating results based on task complexity. Third, existing technologies lack the recording and traceability of the decision-making process; intermediate steps, data sources, and applicable standards for analysis conclusions are difficult to trace, resulting in low decision transparency. Furthermore, the bridge maintenance field is highly specialized, and existing systems are prone to domain knowledge illusions, omissions of key steps, or incorrect task allocation when applying artificial intelligence technologies, affecting the reliability and professionalism of decision-making.

[0004] Therefore, how to achieve unified semantic fusion of multi-source heterogeneous data, automatic decomposition and collaborative execution of complex tasks, and build a traceable and highly reliable intelligent decision-making system are the core technical problems that urgently need to be solved in the field of bridge maintenance. Summary of the Invention

[0005] To address the aforementioned shortcomings of existing technologies, this invention provides a multi-agent-based intelligent decision-making method for bridge maintenance. By constructing a multimodal data access layer, a domain knowledge graph, a skill base, and a multi-agent collaborative architecture, it solves the technical problems of the inability to automatically decompose complex tasks and the difficulty in collaborative analysis of multi-source heterogeneous data in the field of bridge maintenance.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0007] A multi-agent-based intelligent decision-making method for bridge maintenance includes the following steps:

[0008] S1. Connect to multimodal data in the field of bridge maintenance, encapsulate and standardize the multimodal data through interfaces, and construct a multimodal data access layer in the field of bridge maintenance.

[0009] S2. Construct a knowledge graph for the field of bridge maintenance, using a directed multigraph structure and a triplet-based structured model of knowledge in the field of bridge maintenance.

[0010] S3. Encode the experience and knowledge of bridge maintenance experts into skill templates to build a skill library in the field of bridge maintenance;

[0011] S4. Based on the constructed bridge maintenance domain skill library, initialize the planning agent and construct a global shared state space for recording task status and context data; receive the user's natural language query, use the planning agent in conjunction with the bridge maintenance domain skill library to perform intent recognition, scene classification and task decomposition, obtain a list of sub-tasks with dependencies, and update it to the global shared state space.

[0012] S5. Based on the subtask list in the global shared state space, the scheduler resolves the dependencies, selects executable subtasks in sequence, and assigns them to the corresponding professional execution agents through a conditional routing mechanism.

[0013] S6. Each of the specialized execution agents receives the assigned sub-tasks, uses the ReAct mode to call predefined domain tools, generates sub-task execution results, evidence sources and reasoning trajectories, and writes the sub-task execution results, evidence sources and reasoning trajectories back to the global shared state space.

[0014] S7. Based on the knowledge graph of the bridge maintenance domain, perform entity existence, relationship legality and attribute constraint verification on the execution results of the sub-tasks in order to detect and correct illusions, generate an illusion detection report and update it to the global shared state space.

[0015] S8. When all subtasks in the global shared state space are completed or the maximum number of iterations is reached, the planning agent retrieves the execution results, evidence sources, hallucination detection reports, and reasoning trajectories of each subtask from the global shared state space to generate a structured and traceable final answer for intelligent bridge maintenance decision-making.

[0016] As a preferred embodiment, in step S1, the multimodal data includes structured data, unstructured specification documents, computer vision model services, and finite element analysis software;

[0017] The interface encapsulation and standardization processing of the multimodal data specifically includes:

[0018] S11. Connect the structured data to a database engine and access a bridge maintenance relational database. The database contains a bridge basic information table, a technical condition assessment table, a defect record table, and a sensor monitoring information table. Configure a security control mechanism to allow only SELECT query statements to be executed.

[0019] S12. Perform text segmentation and metadata parsing on unstructured standard documents, use a semantic embedding model to convert the text into high-dimensional vectors, and store them in a vector database to build a vectorized standard document library that supports semantic retrieval.

[0020] S13. Through a standardized visual model client interface, encapsulate functions for bridge appearance defect detection, bridge deck vehicle detection, cable appearance detection, pier appearance detection, and multimodal large language model image analysis, and support access to computer vision model services.

[0021] S14. Define the finite element analysis client interface, encapsulate the functions of model file generation, analysis execution and result parsing, and support access to the finite element analysis software.

[0022] As a preferred embodiment, in step S2, the knowledge graph for bridge maintenance includes the following domain knowledge:

[0023] Bridge structural hierarchy knowledge is used to describe the hierarchical inclusion relationship between bridges and their components;

[0024] Component-Disease Correspondence Knowledge is used to describe the association mapping between bridge components and disease types;

[0025] Disease-maintenance mapping knowledge is used to describe the correspondence between disease types and maintenance methods;

[0026] Technical condition assessment standards are used to describe the correspondence between technical condition levels, scoring ranges, and maintenance measures;

[0027] Monitoring indicators and threshold knowledge, used to describe the units, applicable components, early warning thresholds, and alarm thresholds of monitoring indicators;

[0028] Material property knowledge is used to describe the relationship between components and materials, as well as the mechanical property parameters of materials;

[0029] Standardized reference relationship knowledge is used to describe the traceability relationship between knowledge entries and source standards.

[0030] As a preferred embodiment, in step S3, the skill template includes the following attributes: unique skill identifier, skill name, function description, applicable scenario type, trigger keyword list, execution step list, and matching priority weight; wherein, each step in the execution step list specifies the assigned agent type, task category, parameter template, and dependency relationship.

[0031] As a preferred embodiment, in step S4, the intent recognition and scenario classification includes: classifying the user's natural language query into a single bridge scenario, a regional scenario, or a general scenario, and identifying the corresponding task category; the task category includes single bridge monitoring, single bridge detection, single bridge technical status, single bridge maintenance, regional disease trends, regional maintenance strategies, regional budget allocation, regional data overview, standard query, and general questions.

[0032] As a preferred option, step S4 includes the following specific processing steps based on task decomposition:

[0033] S41. Calculate the matching score between the user's natural language query and the trigger keywords of each skill template, and filter out a preset number of skill templates before the matching score.

[0034] S42. Convert the matched skill template into structured reference text and inject it into the prompt words of the planning agent;

[0035] S43. The planning agent generates a list of subtasks with dependencies based on the prompt words and the user's natural language query; wherein each subtask in the list includes a task identifier, a task description, an assigned agent type, a dependency list, and a parameter dictionary.

[0036] As a preferred embodiment, step S5, which involves resolving dependencies through the scheduler and sequentially selecting executable subtasks, includes the following specific processing steps:

[0037] S51. The scheduler traverses the subtasks in the subtask list whose status is "to be executed";

[0038] S52. Determine that all preceding subtasks in the dependency relationship of each subtask to be executed have been completed;

[0039] S53. Select the first subtask whose dependencies are all satisfied as the currently executable subtask;

[0040] S54. Extract the execution results from the completed previous subtasks and inject them into the parameter dictionary of the current subtask;

[0041] S55. Update the current subtask identifier and iteration counter in the global shared state space.

[0042] As a preferred embodiment, in step S5, the conditional routing mechanism assigns the subtask to the corresponding professional execution agent based on the agent type field of the subtask's assignment; the professional execution agents include: SQL agent, retrieval agent, analysis agent, code agent, vision agent, and finite element agent.

[0043] As a preferred embodiment, in step S6, the specific processing procedure of the ReAct mode includes:

[0044] S61. Input the subtask description, parameter dictionary, and execution results extracted from the preceding subtask into a large language model equipped with domain system prompt words;

[0045] S62. The large language model performs reasoning and thinking to determine the domain tools to be called and the calling parameters;

[0046] S63. Execute domain tool calls and obtain tool return results, then feed the tool return results back to the large language model for further reasoning;

[0047] S64. Repeat steps S62 to S63 until the preset information threshold is reached. Output the subtask execution results and evidence sources, and record the execution process as the reasoning trajectory.

[0048] As a preferred embodiment, in step S7, the specific methods for verifying entity existence, relationship validity, and attribute constraints are as follows:

[0049] Entity existence verification is used to verify whether the entities in the subtask execution results exist in the knowledge graph of the bridge maintenance domain. If they do not exist, similarity matching is performed and similar entity suggestions are returned.

[0050] Relationship validity verification is used to verify whether the relationship between entity pairs in the subtask execution result is consistent with the relationship recorded in the bridge maintenance domain knowledge graph. If they are inconsistent, the actual relationship of the entity pair in the knowledge graph is returned.

[0051] Attribute constraint validation is used to verify whether the numerical or attribute values ​​in the subtask execution result are within a preset range, which includes numerical range constraints and enumerated value constraints.

[0052] Compared with the prior art, the present invention has the following technical effects:

[0053] 1. This invention constructs a multimodal data access layer in the field of bridge maintenance, and standardizes and integrates structured databases, vectorized specification document libraries, computer vision model services, and finite element analysis software interfaces to form a unified data access foundation. On the one hand, it solves the problems of scattered storage, inconsistent formats, and difficulty in collaborative calling of multi-source heterogeneous data in the field of bridge maintenance. On the other hand, it provides a standardized data access interface for upper-level professional intelligent agents, reducing the complexity of system integration and development costs.

[0054] 2. This invention constructs a domain knowledge graph with a directed multigraph structure and triples as the basic knowledge units. It structurally models and accurately stores professional knowledge such as bridge structure hierarchy, component-disease correspondence, disease-maintenance measure mapping, technical condition assessment standards, and monitoring index thresholds. Compared with the method of embedding knowledge in the parameters of a large language model, the knowledge graph accurately stores this domain knowledge in the form of structured triples, providing a reliable factual basis for subsequent intelligent decision-making. It effectively supports fact-based illusion detection and overcomes the defect of general large language models that are prone to producing professional knowledge illusions in vertical domains.

[0055] 3. This invention encodes the experience and knowledge of bridge maintenance experts into reusable skill templates, constructing a domain skill library. The skill templates predefine the standard workflows of common maintenance tasks as structured execution steps, providing a professional reference "scaffold" for the task decomposition of planning agents. This ensures that the decomposition of complex maintenance tasks follows domain best practices, effectively avoiding problems such as missing steps, incorrect sequence, or improper agent allocation, thus improving the accuracy and completeness of task decomposition.

[0056] 4. This invention achieves the automatic conversion of complex natural language queries into structured executable task chains through the cooperation of planning agents and a globally shared state space. The planning agent combines a skill base to perform intent recognition, scene classification, and task decomposition, accurately breaking down user queries into sub-task graphs with dependencies; the globally shared state space provides a unified data exchange platform for collaborative communication among multiple agents, avoiding the problems of information loss and high communication complexity caused by traditional message passing mechanisms.

[0057] 5. This invention achieves intelligent orchestration and dynamic distribution of subtasks through a dependency-aware task scheduling algorithm and a conditional routing mechanism. The scheduler automatically identifies tasks that can be executed in parallel or sequentially based on the dependencies between subtasks, maximizing execution efficiency while ensuring the correctness of data dependencies. The conditional routing mechanism accurately assigns subtasks to the corresponding specialized intelligent agents according to their types and automatically injects the execution results of preceding tasks into the parameters of subsequent tasks, thus automating the data flow between tasks and ensuring the continuity of the inference chain.

[0058] 6. This invention equips each specialized intelligent agent with deterministic domain tools and employs the ReAct mode to execute subtasks. The ReAct mode enables the intelligent agent to dynamically adjust its strategy based on the execution situation, exhibiting good adaptability. The deterministic domain tools (such as SQL queries, BCI calculations, wind load calculations, etc.) ensure the accuracy of numerical calculations, compensating for the shortcomings of large language models in terms of precise calculations. At the same time, the intelligent agent outputs evidence sources and reasoning trajectories during execution, making each conclusion verifiable and providing key support for the interpretability and traceability of decisions.

[0059] 7. After each subtask is completed, the present invention performs three-layer fact verification based on the knowledge graph: entity existence, relationship validity, and attribute constraints. This achieves automated quality control and illusion suppression of the output results of the large language model. This task-by-task, real-time verification mechanism can detect and mark problems in time before erroneous information is referenced and propagated by subsequent subtasks, realizing early detection and scope control of errors, and effectively improving the reliability and professionalism of the final decision results.

[0060] 8. This invention uses a planning agent to comprehensively summarize and semantically integrate the execution results of each subtask, evidence sources, hallucination detection reports, and reasoning trajectories to generate a structured and traceable final decision response. The final response clearly indicates the data source and supporting standards for each conclusion, and provides explicit annotations and suggestions for manual review for content that failed the hallucination detection. This makes the entire decision-making process transparent and reviewable, significantly improving the interpretability and user trust in bridge maintenance decisions. Attached Figure Description

[0061] To make the objectives, technical solutions, and advantages of the invention clearer, the invention will now be described in further detail with reference to the accompanying drawings, wherein:

[0062] Figure 1 This is a flowchart of a bridge maintenance intelligent decision-making method based on multi-agent technology disclosed in this invention;

[0063] Figure 2 This is an architecture diagram of the method in an embodiment of the present invention. Detailed Implementation

[0064] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0065] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to represent selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0066] It should be noted that similar reference numerals and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the figures, or the orientation or positional relationship commonly used when the product is in use. They are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance. In addition, the terms "horizontal," "vertical," etc., do not indicate that the component is required to be absolutely horizontal or suspended, but can be slightly tilted. For example, "horizontal" simply means that its direction is more horizontal than "vertical," and does not mean that the structure must be completely horizontal, but can be slightly tilted. In the description of this invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0067] Example:

[0068] Currently, while various bridge management systems collect and store multi-source heterogeneous data such as inspection records, damage reports, monitoring data, and detection images, they remain primarily at the stage of "information management" or "single-point intelligent analysis." Data from different sources and in different formats is scattered across independent systems, lacking a unified semantic association mechanism, making effective collaboration difficult. In actual maintenance decision-making, managers still need to repeatedly search for information across multiple systems, relying on personal experience for manual comprehensive judgment, which is not only inefficient but also makes it difficult to standardize decision-making logic and traceability of the analysis process. When problems involve multiple data types and require step-by-step reasoning, dynamic verification, or external tool validation, existing systems cannot form a complete reasoning chain and lack a mechanism for automatically decomposing tasks, collaboratively processing, and integrating results. Therefore, how to establish a method that can perform unified semantic understanding and cross-modal fusion analysis of multi-source heterogeneous data in the field of bridge maintenance, and achieve intelligent collaborative decision-making by constructing interpretable reasoning paths, has become a core problem that current technology urgently needs to solve.

[0069] Based on this, the present invention proposes a multi-agent-based intelligent decision-making method for bridge maintenance. The core idea of ​​this method is to build a multi-agent collaborative system with a planning agent as the central scheduler, multiple specialized agents cooperating in execution, a knowledge graph providing domain constraints and illusion detection, and a skill library assisting in task decomposition. This system is designed for multi-source heterogeneous data (structured database data, unstructured standard text, bridge image and video data, finite element model data, etc.) in the field of bridge maintenance. It enables end-to-end intelligent decision support, starting from user natural language queries, through automatic task decomposition, parallel / serial execution of multiple agents, cross-modal data fusion analysis, fact verification based on knowledge graphs, and result aggregation with traceable inference links.

[0070] Specifically, such as Figure 1 As shown, the intelligent decision-making method for bridge maintenance based on multi-agent systems proposed in this invention includes the following steps:

[0071] S1. Connect to multimodal data in the field of bridge maintenance, encapsulate and standardize the multimodal data through interfaces, and construct a multimodal data access layer in the field of bridge maintenance.

[0072] S2. Construct a knowledge graph for the field of bridge maintenance, using a directed multigraph structure and a triplet-based structured model of knowledge in the field of bridge maintenance.

[0073] S3. Encode the experience and knowledge of bridge maintenance experts into skill templates to build a skill library in the field of bridge maintenance;

[0074] S4. Based on the constructed bridge maintenance domain skill library, initialize the planning agent and construct a global shared state space for recording task status and context data; receive the user's natural language query, use the planning agent in conjunction with the bridge maintenance domain skill library to perform intent recognition, scene classification and task decomposition, obtain a list of sub-tasks with dependencies, and update it to the global shared state space.

[0075] S5. Based on the subtask list in the global shared state space, the scheduler resolves the dependencies, selects executable subtasks in sequence, and assigns them to the corresponding professional execution agents through a conditional routing mechanism.

[0076] S6. Each of the specialized execution agents receives the assigned sub-tasks, uses the ReAct mode to call predefined domain tools, generates sub-task execution results, evidence sources and reasoning trajectories, and writes the sub-task execution results, evidence sources and reasoning trajectories back to the global shared state space.

[0077] S7. Based on the knowledge graph of the bridge maintenance domain, perform entity existence, relationship legality and attribute constraint verification on the execution results of the sub-tasks in order to detect and correct illusions, generate an illusion detection report and update it to the global shared state space.

[0078] S8. When all subtasks in the global shared state space are completed or the maximum number of iterations is reached, the planning agent retrieves the execution results, evidence sources, hallucination detection reports, and reasoning trajectories of each subtask from the global shared state space to generate a structured and traceable final answer for intelligent bridge maintenance decision-making.

[0079] As can be seen, the present invention aims to improve the intelligence level and decision-making efficiency of bridge maintenance management by constructing a multi-agent collaborative reasoning and multi-modal data fusion analysis system, thereby realizing the automatic decomposition of complex maintenance tasks, collaborative analysis across data sources, and traceable intelligent decision output.

[0080] The following is combined Figure 2 The present invention provides a further explanation of the intelligent decision-making method for bridge maintenance based on multi-agent systems.

[0081] I. Overall Architecture

[0082] 1.1 Multi-agent collaborative architecture design

[0083] In this embodiment, a star-shaped collaborative architecture of "central scheduling - professional execution" is adopted, with a planning agent (PlanAgent) as the central scheduler and six professional agents (SQLAgent, RetrievalAgent, AnalysisAgent, CodeAgent, VisionAgent, FEAAgent) as task executors. Communication and cooperation between agents are realized through a globally shared state space (AgentState).

[0084] Compared to peer-to-peer collaborative architectures, in bridge maintenance decision-making scenarios, a complex problem often requires sequential or parallel invocation of multiple different types of data sources and analysis methods. If a peer-to-peer multi-agent negotiation mechanism is adopted, each agent needs to negotiate the division of tasks in pairs, resulting in a quadratic increase in communication complexity and a high risk of task duplication or omission. The star architecture adopted in this embodiment uses PlanAgent as the sole task decomposer and result aggregator. Each specialized agent only needs to focus on the execution of tasks in its own domain and does not need to communicate directly with other agents. The advantages of this approach are: (1) reduced system communication complexity; (2) natural support for task dependency management and execution order control; (3) the addition or removal of any specialized agent does not affect other agents or the overall architecture, and the system has good scalability; (4) PlanAgent centrally grasps global information and can make better scheduling decisions.

[0085] 1.2 Global Shared State Space

[0086] All agents communicate by reading and writing a unified, globally shared state object, which contains the key fields shown in Table 1:

[0087] Table 1 Key fields of global shared state

[0088] Fields type illustrate query String User's original natural language query scenario_type String Scene Classification (Single Bridge / Regional / General) subtasks Subtask list The set of subtasks decomposed by PlanAgent current_subtask_id String Currently executing subtask identifier agent_outputs Output list Set of execution results of each agent hallucination_results Validation list Hallucination test result set final_answer String Final summary answers references String list List of cited sources reasoning_trace String list Complete Reasoning Process Record iteration_count Integer Current iteration number is_complete Boolean value Task completion status indicator

[0089] Traditional multi-agent systems often use message passing for communication. However, in bridge maintenance decision-making scenarios, the execution of tasks by subsequent agents often requires reference to the complete output results of preceding agents. For example, the analysis agent needs to use all the data queried by the SQL agent for calculation, and the code agent needs to draw graphs based on the queried data. If only message passing is used, a large amount of context data needs to be carried in the message, which can easily lead to information loss. The advantages of using a globally shared state space in this embodiment are: (1) all historical information is naturally visible, and any agent can obtain the complete context; (2) the dependent results of subtasks can be automatically passed through the state injection mechanism without explicit message routing; (3) the reasoning_trace field in the state realizes a complete record of the reasoning process, making the decision-making link traceable.

[0090] Subtasks are the basic units of communication between agents, and each subtask contains the following attributes:

[0091] • id: A unique identifier for the subtask;

[0092] •Description: The task content described in natural language;

[0093] •assigned_agent: The type of specialized intelligent agent assigned to perform this task;

[0094] • Category: Task category, corresponding to the specific scenario of bridge maintenance (such as single bridge monitoring, regional maintenance strategy, standard query, etc.).

[0095] •dependencies: A list of preceding subtask identifiers that depend on the task, forming a directed acyclic task graph;

[0096] •parameters: A dictionary of parameters passed to the executing agent;

[0097] •status: Execution status (pending execution / in execution / completed / failed);

[0098] • result: The text containing the execution result;

[0099] •evidence: A list of sources and citations;

[0100] •error: Error message.

[0101] The merging of subtask states adopts an ID-based update-append strategy: when a new subtask state has the same ID as an existing subtask, an overwrite update is performed; otherwise, an append is performed. This ensures the consistency of subtask states in concurrent execution scenarios.

[0102] II. Detailed Plan for Each Step

[0103] 2.1 Step S1: Construction of a multimodal data access layer in the field of bridge maintenance

[0104] This step establishes a unified data access foundation by connecting to structured databases, vectorized specification document libraries, computer vision model services, and finite element analysis software interfaces;

[0105] 2.1.1 Access to Structured Databases

[0106] This embodiment connects the structured data to a bridge maintenance relational database via a database engine. The database contains a bridge basic information table, a technical condition assessment table, a defect record table, and a sensor monitoring information table. A security control mechanism is configured to allow only SELECT query statements to be executed.

[0107] Specifically, a structured database contains the following core data tables:

[0108] • Bridge Basic Information Table (cbms_bridge): Stores basic attribute information such as bridge code, name, road to which it belongs, bridge type, superstructure category, bearing type, and bridge deck category;

[0109] • Bridge Overall Technical Condition Assessment Table (bridge_overall_grade): Stores the overall technical condition level and score of each bridge at different inspection times;

[0110] • Bridge Part Technical Condition Assessment Form (bridge_part_grade): Stores the assessment grades and scores for different parts of the bridge, such as the bridge deck system, superstructure, and substructure;

[0111] • Bridge Component Technical Condition Assessment Form (bridge_structural_grade): Stores the assessment level and score of specific components such as main beams, bearings, and piers;

[0112] • Periodic inspection disease record form (interval_check_disease): Stores information such as the type, extent, size, and scale of component diseases found during periodic inspections;

[0113] • Regularly check the disease record sheet (regular_check_disease): Store the types and extent of component defects found during daily inspections;

[0114] • Maintenance and repair history table (check_maintenance_history): Stores information such as the content, plan, workload, and cost of each maintenance operation;

[0115] • Sensor location information table (sensor_location): Stores information such as the sensor number, type, installation location, and monitoring subject of each bridge.

[0116] • Sensor monitoring data table (sensor_data): Stores the data collected by each sensor, including external temperature and humidity sensing, internal vibration, deflection and other information.

[0117] Furthermore, the system implements strict security control mechanisms at the database access layer: only SELECT query statements are allowed, any data modification operations (INSERT, UPDATE, DELETE, DROP, etc.) are prohibited, and keyword filtering checks are performed on SQL statements to prevent accidental data corruption. Query results are limited to a maximum of 100 rows to prevent performance issues caused by large-scale data transfers.

[0118] Thus, since SQL queries are automatically generated by a large language model based on natural language understanding, there is a risk of generating inappropriate SQL. The bridge maintenance database stores a large amount of valuable historical data on inspection, monitoring, and maintenance; accidental modification or deletion would cause irreversible losses. Therefore, implementing a dual protection mechanism of read-only and keyword filtering at the data access layer ensures data security without affecting query and analysis functions, making it a necessary design for a production environment.

[0119] 2.1.2 Access to the Vectorized Specification Document Library

[0120] This embodiment first performs text segmentation and metadata parsing on unstructured specification documents related to bridge maintenance to extract structured information such as specification names and chapter numbers; then, it uses a semantic embedding model to convert the text into high-dimensional vectors and stores them in a vector database to build a vectorized specification document library that supports semantic retrieval.

[0121] Thus, due to the highly specialized nature and diverse expressions in bridge maintenance regulations, for example, when a user asks "how to deal with cracks," relevant regulations may use different terms such as "crack treatment," "crack repair," and "crack closure." Traditional keyword matching cannot capture these semantically equivalent expressions. Vectorized semantic retrieval, by mapping text to a continuous semantic space, can perform retrieval based on semantic similarity rather than literal matching, significantly improving the recall and precision of regulatory clause retrieval.

[0122] 2.1.3 Access to Computer Vision Model Services

[0123] This embodiment encapsulates bridge appearance defect detection, bridge deck vehicle detection, cable appearance detection, pier appearance detection, and multimodal large language model image analysis functions through a standardized visual model client interface, and supports access to computer vision model services.

[0124] In this embodiment, the visual model client uses an abstract interface design, defining a unified input (image path / URL, detection type) and output (detection result dictionary) format. This allows for different projects to use different detection models (such as YOLOv8, DETR, U-Net, DeepLab, etc.) due to the rapid development of model technology in the field of bridge visual inspection. The abstract interface design decouples the model calling logic from the system's business logic, ensuring that changing the underlying detection model does not require modifying the upper-layer agent's code; only the corresponding client interface needs to be implemented. This design guarantees the system's technological evolution capabilities and engineering maintainability.

[0125] 2.1.4 Integration with Finite Element Analysis Software

[0126] This embodiment, by accessing the finite element analysis client interface, encapsulates the functions of model file generation, analysis execution, and result parsing, supporting access to the finite element analysis software. This finite element analysis software supports the following specific functions:

[0127] • Finite element model file generation: Automatically generates finite element model input files (such as MIDAS's .mgt format files) based on bridge type and structural parameters, supporting various bridge types such as simply supported beam bridges, continuous beam bridges, cable-stayed bridges, and arch bridges;

[0128] • Finite element analysis execution: Call the installed finite element software to perform static analysis, modal analysis, buckling analysis, seismic response analysis, wind load analysis, construction stage analysis, etc.

[0129] • Analysis Result Parsing: Read and parse the finite element calculation result file to extract structural response data.

[0130] The system automatically detects the installed finite element software upon startup and configures the software path via environment variables.

[0131] Thus, in bridge maintenance decision-making, certain complex issues require structural mechanics analysis to provide a scientific judgment, such as assessing the safety status of bridges under high wind conditions and evaluating whether the bridge's load-bearing capacity meets requirements. Traditional bridge maintenance systems typically lack structural analysis capabilities, relying solely on human experience for decision-making. By encapsulating finite element analysis capabilities into a tool that can be invoked by intelligent agents, the system can automatically generate models and perform analyses when needed, thereby realizing a complete decision-making chain from data query to structural verification.

[0132] 2.2 Step S2: Construction of a Knowledge Graph for Bridge Maintenance

[0133] This step constructs a knowledge graph for the field of bridge maintenance, using a directed multigraph structure based on NetworkX, with triples (subject-predicate-object) as the basic knowledge unit to perform structured modeling of domain knowledge.

[0134] 2.2.1 Entity Types and Relationship Types in the Knowledge Graph of Bridge Maintenance

[0135] Entity types include: bridges, components, types of defects, materials, maintenance measures, standards and specifications, monitoring indicators, and technical condition levels;

[0136] The relationship types include: component relationships, relationships with defects, relationships requiring maintenance, relationships measured by sensors, relationships rated at a certain level, relationships specified by standards, relationships made of materials, and relationships that trigger alarms when monitoring values ​​exceed thresholds.

[0137] 2.2.2 Domain Knowledge in the Knowledge Graph of Bridge Maintenance:

[0138] Bridge structural hierarchy knowledge is used to describe the hierarchical inclusion relationship between bridges and their components; for example: bridge → bridge deck system → {bridge deck pavement, expansion joints, sidewalks, railings, drainage system, lighting facilities}; bridge → superstructure → {main beams, crossbeams, wet joints, prestressed system, bearings}; bridge → substructure → {piers, abutments, cap beams, columns, pile caps, pile foundations}, etc.

[0139] The component-disease correspondence knowledge is used to describe the association mapping between bridge components and disease types; for example: main beam → {cracks, abnormal deflection, concrete spalling, steel corrosion, prestress loss}; bearing → {void, shear deformation, aging, abnormal displacement, cracking}; pier → {cracks, concrete spalling, exposed steel, tilting, scour}, etc.

[0140] Disease-Maintenance Mapping Knowledge describes the correspondence between disease types and maintenance methods; for example: cracks → {sealing treatment, grouting repair, carbon fiber bonding, chiseling and redoing}; support voids → {support shim adjustment, support replacement}; scour → {rockfill protection, revetment construction, reinforcement treatment}, etc.

[0141] Technical condition assessment standards are used to describe the correspondence between technical condition levels, scoring ranges, and maintenance measures; including a complete grading system from Class 1 (BCI∈[90,100], good condition, routine maintenance) to Class 5 (BCI∈[0,40], hazardous condition, renovation / demolition).

[0142] The monitoring indicators and threshold knowledge are used to describe the units, applicable components, early warning thresholds, and alarm thresholds of the monitoring indicators; for example: the early warning threshold for deflection is L / 600, and the alarm threshold is L / 300; the early warning threshold for crack width is 0.15mm, and the alarm threshold is 0.20mm; the early warning threshold for cable force change is 5% of the design value, etc.

[0143] Material property knowledge is used to describe the relationship between components and materials and the mechanical performance parameters of materials; for example: main beam → C50 concrete (compressive strength 50MPa); bridge pier → C30 concrete; steel structure → Q345 steel (yield strength 345MPa), etc.

[0144] Standardized reference relationship knowledge is used to describe the traceability relationship between knowledge entries and source standards.

[0145] 2.2.3 Querying the knowledge graph in the field of bridge maintenance

[0146] Knowledge graphs support the following query operations:

[0147] • Entity Query: Given an entity name, return the entity's type, all outgoing edges, and incoming edges;

[0148] • Relational query: Given a subject and a predicate (object optional), return a set of triples that satisfy the condition;

[0149] • Type retrieval: Given an entity type, return the collection of all entities of that type;

[0150] • Path query: Given a source entity and a target entity, find all paths between them (with a maximum depth limit) for inference link discovery;

[0151] • Subgraph extraction: Given a central entity and an extended depth, extract a local knowledge subgraph centered on that entity.

[0152] Although large language models learn a lot of general knowledge during training, they may have inaccurate or missing information about the professional knowledge of the vertical field of bridge maintenance (such as the legal combination of specific components and defects, the specific numerical boundaries of evaluation standards, and the precise thresholds of monitoring indicators), resulting in "illusions" in the generated content. Knowledge graphs store this domain knowledge accurately in the form of structured triples, which has the following advantages: (1) the knowledge storage is accurate and reliable, and will not become fuzzy like model parameters; (2) it supports efficient logical query and relational reasoning, and can answer structured questions such as "what defects may occur in a certain component"; (3) it provides a factual basis (Ground Truth) for subsequent illusion detection, so that the system outputs reliable conclusions verified by entities.

[0153] 2.3 Step S3: Construction of a Skills Library for Bridge Maintenance

[0154] This step constructs a skill library for bridge maintenance scenarios, providing domain-specific reference templates for task decomposition of planning agents. Each skill template includes the following attributes: unique skill identifier, skill name, functional description, applicable scenario type, list of triggering keywords, list of execution steps, and matching priority weight. Each step in the execution step list specifies the assigned agent type, task category, parameter template, and dependencies.

[0155] This embodiment of the system includes eleven skill templates covering the main scenarios of bridge maintenance:

[0156] (1) Single Bridge Technical Condition Assessment Skill: Applicable to scenarios where the overall technical condition of a single bridge is queried and assessed. The steps include: SQL agent querying overall assessment data → SQL agent querying scores for each component → retrieval agent retrieving assessment criteria → analysis agent calculating BCI and assigning a grade → code agent drawing a score comparison chart. Triggering keywords include "technical condition", "assessment", "BCI", "grade", etc.

[0157] (2) Disease Query and Maintenance Suggestion Skills: Applicable to scenarios where bridge diseases are queried and maintenance suggestions are generated. The steps include: SQL agent querying scheduled inspection disease records → SQL agent querying patrol inspection disease records → Retrieval agent retrieving standard maintenance requirements → Analysis agent analyzing disease evolution trends → Code agent generating disease distribution maps and trend maps.

[0158] (3) Monitoring data analysis skills: Applicable to scenarios involving structural health monitoring data analysis. The steps include: SQL agent querying sensor deployment information → SQL agent querying monitoring data → Retrieving warning thresholds by the agent → Analysis agent performing time series analysis and anomaly detection → Code agent drawing monitoring data trend charts.

[0159] (4) Regional bridge maintenance priority ranking skills: Applicable to scenarios involving multi-bridge comparative analysis and maintenance priority determination.

[0160] (5) Wind load safety assessment skills: Applicable to bridge safety assessment scenarios under strong wind conditions, combining the wind load calculation of analytical agents and the structural analysis capabilities of finite element agents.

[0161] (6) Bridge image defect recognition skills: Applicable to image-based defect detection scenarios, combining image detection by visual agents and standardized query by retrieval agents.

[0162] (7) Bridge deck traffic condition analysis skills, (8) rapid load-bearing capacity verification skills, (9) standard and specification query skills, (10) maintenance budget allocation skills, (11) finite element structural analysis skills, etc.

[0163] Thus, this embodiment introduces a skill library to assist in task decomposition rather than relying entirely on the large language model for self-planning. While general-purpose large language models possess some task planning capabilities, they lack specialized knowledge of specific bridge maintenance processes (such as the standard workflow of "first look up data, then retrieve specifications, then calculate and verify"), which can easily lead to omissions (such as omitting the specification query step) or allocation errors (such as assigning calculation tasks to the retrieval agent). The role of the skill library is to encode the experience and knowledge of domain experts into reusable templates, providing "scaffolding" for the large language model's planning process. This leverages the flexible reasoning capabilities of the large language model to adapt to the differences in specific problems while ensuring the completeness and correctness of key steps through expert knowledge. Furthermore, the skill library supports custom extensions and loading from JSON files, enabling the system to continuously accumulate and enrich task decomposition experience based on actual engineering needs.

[0164] 2.4 Step S4: Intent recognition, scene classification and task decomposition

[0165] This step is executed by the planning agent, which receives user natural language queries and performs intent recognition, scene classification, and task decomposition.

[0166] The intent recognition and scenario classification includes classifying user natural language queries into single-bridge scenarios, regional scenarios, or general scenarios, and identifying the corresponding task categories; the task categories include single-bridge monitoring, single-bridge detection, single-bridge technical status, single-bridge maintenance, regional disease trends, regional maintenance strategies, regional budget allocation, regional data overview, standard queries, and general questions.

[0167] The specific processing steps for task decomposition include:

[0168] S41. Calculate the matching score between the user's natural language query and the trigger keywords of each skill template, and filter out a preset number of skill templates before the matching score.

[0169] S42. Convert the matched skill template into structured reference text and inject it into the prompt words of the planning agent;

[0170] S43. The planning agent generates a list of subtasks with dependencies based on the prompt words and the user's natural language query; wherein each subtask in the list includes a task identifier, a task description, an assigned agent type, a dependency list, and a parameter dictionary.

[0171] The task decomposition follows these principles:

[0172] • Data-first principle: First, obtain data through the SQL agent, then consult the specifications through the retrieval agent, and finally perform calculations through the analysis agent;

[0173] • Explicit Dependency Principle: Subtasks with data dependencies must specify the preceding task ID in the dependency field;

[0174] • Atomicity principle: Each subtask should be an atomic operation that can be completed independently by a single agent;

[0175] • Parameter completeness principle: The parameters should include the key information required for the execution of the subtask (such as table name, query conditions, analysis method, etc.).

[0176] When parsing the JSON output of the large language model fails, the system automatically degrades to the default planning strategy (using a retrieval agent for canonical querying) to ensure the system's fault tolerance.

[0177] Thus, if skill matching were not performed and the large language model were to plan entirely on its own, the model would need to search for suitable task decomposition schemes from a vast space of possibilities. This embodiment, by first matching relevant domain experience templates from the skill base, effectively provides the large language model with effective prior constraints and reference examples for its planning space, enabling the model to generate task decomposition schemes suitable for bridge maintenance scenarios more quickly and accurately. This "retrieval-augmented planning" method combines the reliability of expert experience with the flexibility of a large language model.

[0178] 2.5 Step S5: Subtask scheduling based on dependency topology

[0179] This step is executed by the scheduler, which determines the execution order based on the dependencies between subtasks and assigns tasks to the corresponding specialized intelligent agents through a conditional routing mechanism.

[0180] 2.5.1 Dependency-Aware Task Scheduling Algorithm

[0181] This embodiment uses a scheduler to resolve dependencies and sequentially selects executable subtasks. The specific processing steps include:

[0182] S51. The scheduler traverses the subtasks in the subtask list whose status is "to be executed";

[0183] S52. Determine that all preceding subtasks in the dependency relationship of each subtask to be executed have been completed;

[0184] S53. Select the first subtask whose dependencies are all satisfied as the currently executable subtask;

[0185] S54. Extract the execution results from the completed previous subtasks and inject them into the parameter dictionary of the current subtask;

[0186] S55. Update the current subtask identifier and iteration counter in the global shared state space.

[0187] 2.5.2 Conditional Routing Mechanism

[0188] The conditional routing mechanism assigns subtasks to corresponding specialized execution agents based on the agent type field of the subtask assignment; the specialized execution agents include: SQL agents, retrieval agents, analysis agents, code agents, vision agents, and finite element agents.

[0189] 1) SQL Agent

[0190] The SQL agent is responsible for querying the structured database for bridge maintenance and is equipped with the following tools:

[0191] • get_database_schema: Retrieves complete schema information of the database, including all table names, column names, column types, primary keys, and foreign key relationships, helping the agent understand the database structure;

[0192] •execute_sql_query: Executes an SQL SELECT query and returns formatted results (including security checks, allowing only SELECT operations);

[0193] •get_table_sample: Retrieves sample data from a specified table to help the agent understand the actual content and format of the data.

[0194] The SQL agent is injected with a complete database schema overview (including all field names, types, and meanings of the eight core data tables) into its system prompts, enabling the large language model to understand the database structure and generate correct SQL query statements. After execution, the agent labels the data source in the subtask results ("Source: BM3A MySQL database query").

[0195] 2) Retrieval Agent

[0196] The retrieval agent is responsible for semantic retrieval of bridge maintenance specifications and technical documents, and is equipped with the following tools:

[0197] •search_specifications: Performs semantic retrieval in a vectorized canonical document library, returning the most relevant canonical document fragments to the query, along with their similarity scores and source information;

[0198] •search_by_component_damage: Combines the search based on component name and damage type. First, it obtains the structured component-damage relationship and recommended maintenance measures from the knowledge graph, and then supplements the specification clauses through vector retrieval, realizing the integration of knowledge graph structured query and semantic retrieval.

[0199] •search_condition_rating_standard: Specifically retrieves technical condition rating standards, obtaining rating definitions, BCI score ranges, and corresponding maintenance measures from the knowledge graph;

[0200] •search_monitoring_threshold: Retrieves the early warning and alarm thresholds for monitoring indicators, and obtains the indicator unit, applicable components and threshold information from the knowledge graph.

[0201] Why design multiple specialized retrieval tools instead of just providing general semantic retrieval? Information retrieval in the field of bridge maintenance has distinctly structured characteristics. For example, when querying "maintenance methods for main beam cracks," the most effective approach is to first precisely locate the relationship path of "main beam" → "crack" → "maintenance measures" in the knowledge graph, obtain a structured list of recommended measures, and then supplement the detailed description of the relevant specifications through semantic retrieval. This dual-channel strategy of "precise knowledge graph query + semantic supplementation via vector retrieval" ensures both the structured accuracy of core information and provides rich contextual supplementation, which is superior to simple keyword or semantic retrieval methods.

[0202] 3) Analysis Agent

[0203] The analytical agent is responsible for data-driven computation and analytical reasoning, and is equipped with two types of tools:

[0204] Bridge maintenance analysis tools:

[0205] •calculate_bci: Calculates the BCI value according to the weighted formula of JTG / T H21 standard based on the scores of the superstructure, substructure and bridge deck system, and automatically determines the technical condition level and recommends maintenance measures;

[0206] • analyze_time_series: Performs statistical analysis (mean, standard deviation, coefficient of variation, etc.), linear trend analysis (slope, goodness of fit R²), and anomaly detection based on the 3σ principle on monitored time series data;

[0207] •analyze_damage_evolution: Analyzes the evolution trend of damage records, groups them by component-damage type, assesses the changing trends of severity and quantity, and makes predictions of the next development based on linear regression;

[0208] •calculate_maintenance_priority: Calculates the maintenance priority of bridges in the region, taking into account four factors: BCI value (weight 40%), traffic volume (weight 25%), bridge age (weight 20%), and time since last maintenance (weight 15%).

[0209] Numerical calculation tools for bridge engineering:

[0210] • calculate_section_properties: Calculates the geometric properties of common bridge sections (rectangular, circular, hollow circular, T-shaped, box-shaped, I-shaped), including area, moment of inertia, section modulus, radius of gyration, etc.

[0211] •calculate_beam_internal_forces: Calculates the support reactions, maximum bending moment, and maximum shear force of simply supported beams and cantilever beams under uniformly distributed loads, concentrated loads, or combined loads.

[0212] • calculate_wind_load: Calculate the wind load on the bridge according to JTG D60-2015, taking into account ground roughness, wind pressure height variation, gust coefficient and shape coefficient, and provide safety assessment recommendations;

[0213] •calculate_bearing_capacity_check: Performs a simplified check on the flexural capacity and shear capacity of the concrete beam to determine whether it meets the code requirements;

[0214] •calculate_fatigue_life: Estimates the fatigue life of steel structures based on the SN curve method;

[0215] •calculate_cable_force: Estimates the cable force based on the vibration frequency method;

[0216] •math_expression_eval: Securely calculates mathematical expressions (including whitelist control and security sandbox).

[0217] Why equip analytical agents with such a diverse range of specialized computational tools? Large language models excel at reasoning but not at precise computation. In bridge maintenance decision-making, calculations such as BCI (Bridge Ingress Computation) calculation, bearing capacity verification, and wind load calculation all require accurate numerical results. Relying entirely on large language models for these calculations can easily lead to numerical errors. By encapsulating these calculations into deterministic tool functions, the large language model only needs to understand when to call which tool and provide the correct input parameters; the tool functions ensure the correctness of the actual numerical calculations. This division of labor—where the large language model handles reasoning and decision-making, and deterministic tools handle precise computation—utilizes the model's understanding and planning capabilities while avoiding the model's unreliability in numerical computation.

[0218] 4) CodeAgent

[0219] The code-based intelligent agent is responsible for dynamically generating and executing Python code, primarily for data visualization and custom analysis calculations, and is equipped with the following tools:

[0220] • `execute_python_code`: Executes Python code in a secure sandbox, supporting data analysis libraries such as numpy, pandas, and matplotlib. The sandbox mechanism includes: module import whitelist control (allowing only data analysis-related libraries), dangerous keyword filtering (prohibiting system operations, file operations, and network operations), automatic fixing of common problems (such as replacing `plt.show()` with `plt.savefig()`), standard output and error output capture, and newly generated file detection.

[0221] •generate_visualization_code: Generates visualization code templates based on data description and chart type, supporting nine chart types including line chart, bar chart, scatter plot, heatmap, pie chart, box plot, histogram, multi-line chart, and stacked bar chart;

[0222] • list_generated_files: View a list of generated files and their size information.

[0223] Why introduce code execution capabilities instead of relying solely on pre-defined analysis tools? Pre-defined analysis tools can only cover standardized computational scenarios, but bridge maintenance decisions may involve various personalized data analysis and visualization needs (such as statistical charts of the number of defects on a specific bridge over many years, radar charts comparing the scores of multiple bridges, etc.). The code-based intelligent agent dynamically generates Python code to adapt to these personalized needs, offering extremely high flexibility. Simultaneously, a security sandbox mechanism ensures the security of code execution, while whitelist control and dangerous keyword filtering jointly prevent the risk of malicious code execution.

[0224] 5) Vision Agent

[0225] The visual agent is responsible for the intelligent analysis of bridge images and is equipped with five visual analysis tools (detect_bridge_damage, detect_bridge_vehicles, detect_cable_condition, detect_pier_condition, analyze_image_with_multimodal_llm), which call external computer vision models through standardized interfaces.

[0226] After acquiring the detection results, the visual intelligent agent will interpret the results by combining professional knowledge of bridge engineering, give an assessment of the severity of the detected defects, provide treatment suggestions based on standards and specifications, and mark the confidence level (low confidence results are recommended for manual review).

[0227] 6) Finite Element Agent (FEAAgent)

[0228] The finite element intelligent agent is responsible for the finite element analysis of bridge structures. It is equipped with four tools (generate_midas_model, run_fea_analysis, generate_wind_fea_scenario, parse_fea_results) to support a complete finite element analysis process, including model file generation, analysis execution, working condition scheme generation, and result parsing.

[0229] 2.6 Step S6: ReAct execution mode of professional intelligent agents

[0230] This step describes the execution mechanism of each specialized intelligent agent. All specialized intelligent agents adopt the ReAct (Reasoning and Acting) model, dynamically invoking predefined domain tools to complete sub-tasks under the guidance of reasoning from the large language model.

[0231] The specific processing steps of this ReAct mode include:

[0232] S61. Input the subtask description, parameter dictionary, and execution results extracted from the preceding subtask into a large language model equipped with domain system prompt words;

[0233] S62. The large language model performs reasoning and thinking to determine the domain tools to be called and the calling parameters;

[0234] S63. Execute domain tool calls and obtain tool return results, then feed the tool return results back to the large language model for further reasoning;

[0235] S64. Repeat steps S62 to S63 until the preset information threshold is reached. Output the subtask execution results and evidence sources, and record the execution process as the reasoning trajectory.

[0236] This embodiment equips each specialized agent with deterministic domain tools and employs the ReAct mode to execute subtasks. The ReAct mode enables the agent to dynamically adjust its strategy based on the execution status, demonstrating good adaptability. The deterministic domain tools (such as SQL queries, BCI calculations, and wind load calculations) ensure the accuracy of numerical calculations, compensating for the shortcomings of large language models in terms of precise calculations. Simultaneously, the agent outputs evidence sources and reasoning trajectories during execution, making each conclusion verifiable and providing crucial support for the interpretability and traceability of decisions.

[0237] 2.7 Step S7: Hallucination Detection Based on Knowledge Graph

[0238] This step is performed after each subtask is completed, using the knowledge graph to perform fact verification on the agent's output.

[0239] 2.7.1 Hallucination Detection Mechanism

[0240] The specific methods for verifying entity existence, relationship validity, and attribute constraints are as follows:

[0241] Entity existence verification is used to verify whether the entities in the subtask execution results exist in the knowledge graph of the bridge maintenance domain. If they do not exist, similarity matching is performed and similar entity suggestions are returned.

[0242] Relationship validity verification is used to verify whether the relationship between entity pairs in the subtask execution result is consistent with the relationship recorded in the bridge maintenance domain knowledge graph. If they are inconsistent, the actual relationship of the entity pair in the knowledge graph is returned.

[0243] Attribute constraint validation is used to verify whether the numerical or attribute values ​​in the subtask execution result are within a preset range, which includes numerical range constraints and enumerated value constraints.

[0244] 2.7.2 The Execution Process of Hallucination Detection

[0245] (a) Obtain the execution result text of the current subtask from the global state;

[0246] (b) Scan the known component names and disease type entities in the knowledge graph within the resulting text;

[0247] (c) Perform entity existence verification on the detected entities;

[0248] (d) Verify the legality of the relationship between component-disease combinations that appear simultaneously in the result text;

[0249] (e) Store all validation results (including validation statements, pass / fail status, confidence level, knowledge graph evidence, and correction suggestions) in the global state hallucination detection result list;

[0250] (f) Count the number of valid items that passed and failed, and record them in the log.

[0251] This embodiment performs illusion detection after each subtask, rather than only during the final summary. If illusion detection were only placed in the final summary stage, erroneous intermediate results might be referenced and propagated by subsequent subtasks, amplifying the error. For example, if the SQL agent incorrectly queries a component as a non-existent disease type, the analysis agent might perform trend analysis based on this erroneous data, and the code agent might then use this error analysis to generate graphs, potentially leading to a final decision completely deviating from reality. Performing illusion detection after each subtask allows for timely detection of problems and the appending of verification results to the context of subsequent tasks. This enables the planning agent to annotate and correct any content that fails verification during the summary, achieving early error detection and range control.

[0252] 2.8 Step S8: Summarize the results of the judgment and traceability.

[0253] This step determines the completion status of all subtasks, and the planning agent summarizes these to generate the final decision answer.

[0254] 2.8.1 Complete the decision logic

[0255] After each hallucination detection is completed, the system performs a completion check:

[0256] (a) If the global state completion flag (is_complete) has been set to true, proceed directly to the summary;

[0257] (b) If the current iteration count has reached the preset maximum iteration limit (default 10 times), then force the system to enter the summary to prevent the system from getting stuck in an infinite loop;

[0258] (c) If there are still tasks in the subtask list with a status of "pending execution", return to the scheduler to continue executing the next subtask;

[0259] (d) If all subtasks are no longer in the "pending execution" state (all completed or failed), proceed to the summary.

[0260] In the multi-agent system of this embodiment, certain boundary conditions may occur that prevent the task state from transitioning normally (such as circular dependencies or continuous failures of tool calls). The maximum number of iterations limit serves as a safety mechanism to ensure that the system can provide a response within a limited time even in abnormal situations, rather than waiting indefinitely, thereby guaranteeing the robustness and availability of the system in the production environment.

[0261] 2.8.2 Summary of Traceable Results

[0262] The aggregation process is performed by the planning agent:

[0263] (a) Collect the execution results, evidence sources and reasoning trajectories of each subtask, and organize them in sequence into a structured execution report;

[0264] (b) Collect items that fail the hallucination test and generate hallucination alarm information;

[0265] (c) Submit the execution report, hallucination alarm information, and the user's original question to the large language model for aggregation and generation;

[0266] (d) The large language model generates the final answer based on the answer principles (reliability, interpretability, structure, and professionalism) defined in the system prompts;

[0267] (e) The final answer includes: core conclusions, detailed analysis points, data source annotations, reference specifications, annotations and suggestions for uncertain content, and explanations of the reasons for failed subtasks.

[0268] In this embodiment, the large language model reorganizes the answer during the summarization phase instead of directly piecing together the results of each subtask. This is because while the outputs of each specialized agent solve their respective sub-problems, these results are fragmented and stylistically diverse. For example, the SQL agent outputs structured data tables, the retrieval agent outputs fragments of regulatory clauses, and the analysis agent outputs calculation results and numerical judgments. Directly piecing together these results makes it difficult for users to form a holistic understanding of the problem. The planning agent utilizes the text generation capabilities of the large language model to integrate the fragmented results into a logically coherent, clearly structured, and professionally expressed complete answer. Simultaneously, it clearly labels the data source and regulatory basis for each conclusion, ensuring that the final output is not only informationally complete but also highly readable and traceable.

[0269] III. Workflow Diagram Arrangement and Execution Engine

[0270] The execution flow of the entire multi-agent system is orchestrated using a directed acyclic workflow graph, with the nodes and edges defined as follows:

[0271] 3.1 Workflow Node Definition

[0272] The system includes the ten workflow nodes shown in Table 2:

[0273] Table 2 Workflow Nodes

[0274] Node Name Implementing entity Function Description plan Planning Intelligent Agent Task decomposition and subtask generation dispatch Scheduler Select the next executable subtask sql_agent SQL Intelligent Agent Structured database query retrieval_agent Retrieval agent Standardized document semantic retrieval analysis_agent Analytical agents Data Analysis and Engineering Calculation code_agent Code-based intelligent agents Code generation and visualization vision_agent Visual intelligent agents Bridge image analysis fea_agent Finite element intelligent agent Finite element model analysis hallucination_check Hallucination detector Fact verification based on knowledge graphs aggregate Planning Intelligent Agent Results Summary and Final Response Generation

[0275] 3.2 Workflow Edge Definition

[0276] Fixed edge:

[0277] •START → plan: After system startup, the system first enters the planning node.

[0278] •plan → dispatch: After planning is completed, the process moves to the dispatch node.

[0279] • Each specialized agent node → hallucination_check: After each agent completes its execution, it enters the hallucination detection phase.

[0280] •aggregate → END: The system ends after aggregation is complete.

[0281] Conditional routing edge:

[0282] • dispatch → {sql_agent, retrieval_agent, analysis_agent, code_agent, vision_agent, fea_agent}: The scheduler performs six-way conditional routing based on the current subtask allocation information.

[0283] •hallucination_check → {dispatch, aggregate}: After hallucination detection, based on the completion determination result, either return to the scheduler to continue executing the next subtask, or enter the aggregate node.

[0284] This embodiment employs a directed acyclic graph (DAG) instead of a nonlinear pipeline or free orchestration because linear pipelines cannot represent conditional branching and cyclical execution between tasks, and cannot meet the iterative requirements of bridge maintenance decision-making where "after data retrieval, it may be necessary to return to the scheduler to assign the next analysis task." While free orchestration is flexible, it lacks structural constraints, which may lead to chaotic execution paths. The DAG combined with conditional routing supports the cyclical processing mode of "scheduling → execution → detection → rescheduling," and ensures the orderliness of execution through the structural constraints of the graph. Simultaneously, it makes the workflow's execution path naturally visible and traceable.

[0285] IV. Multi-turn dialogue and context preservation

[0286] The system supports multi-turn dialogue scenarios by maintaining message history (in the `messages` field) in a globally shared state. User questions and system responses from previous dialogues are preserved in the message history. When a user asks a subsequent question, the planning agent can refer to the historical context for more accurate intent understanding and task decomposition. For example, if a user first asks, "What is the technical condition of the Xiaohe Bridge?", and after the system answers, the user follows up with, "When will it need major repairs?", the planning agent can understand from the historical context that "it" refers to "Xiaohe Bridge" and perform further analysis based on the previous query results.

[0287] V. Overview

[0288] In summary, the key technology of this embodiment lies in constructing a multi-agent collaborative reasoning and multi-modal data fusion analysis method for bridge maintenance decision-making scenarios. Its core is to realize the automatic decomposition of complex bridge maintenance tasks, cross-data source collaborative analysis, and interpretable decision generation through a unified multi-agent architecture.

[0289] First, by setting up a planning agent as the system hub, the system performs intent recognition and scenario classification on the natural language queries submitted by users. Combined with the domain skill library, the system automatically decomposes complex problems into multiple sub-tasks with dependencies, forming a directed acyclic task graph, thereby realizing the automatic planning and structured processing of complex bridge maintenance tasks.

[0290] Secondly, by constructing a professional intelligent agent system consisting of SQL intelligent agents, retrieval intelligent agents, analysis intelligent agents, code intelligent agents, visual intelligent agents, and finite element intelligent agents, the system can connect to various data sources such as structured databases, standardized text knowledge bases, bridge image data, and structural analysis models. Under a unified scheduling mechanism, it can complete the collaborative processing and comprehensive analysis of cross-modal data, and achieve unified semantic fusion of multi-source heterogeneous data in the field of bridge maintenance.

[0291] Furthermore, by introducing a knowledge graph from the field of bridge maintenance into the system, the professional knowledge such as bridge structural hierarchy, component-disease relationship, maintenance measure mapping, and technical condition assessment standards is structured and modeled. After each sub-task is completed, entity existence verification, relationship legality verification, and attribute constraint verification based on the knowledge graph are carried out, thereby effectively suppressing the illusion problem of large language models in professional fields and ensuring the reliability of decision results.

[0292] Finally, the execution results of subtasks, sources of evidence, and complete reasoning trajectories are recorded in a globally shared state space. After the task is completed, the planning agent summarizes and semantically integrates the results of each subtask to generate a structured decision conclusion that includes data sources and standard references. This forms a bridge maintenance intelligent decision-making process with a complete reasoning chain and traceability.

[0293] Overall, this embodiment constructs a domain knowledge foundation through a "multimodal data access layer + domain knowledge graph + skill base," achieves automatic decomposition and state management of complex tasks through "planning agents + globally shared state space," realizes collaborative execution based on dependency perception through "scheduler + specialized agents," and achieves illusion suppression and decision traceability through "knowledge graph verification + reasoning trajectory recording." Compared with existing technologies, this embodiment achieves unified semantic fusion of multi-source heterogeneous data, automatic decomposition and collaborative execution of complex maintenance tasks, illusion suppression based on knowledge graphs, and interpretable and traceable decision output, significantly improving the intelligence level, reliability, and work efficiency of bridge maintenance decision-making.

[0294] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit the technical solutions. Those skilled in the art should understand that any modifications or equivalent substitutions to the technical solutions of the present invention without departing from the spirit and scope of the present invention should be covered within the scope of the claims of the present invention.

Claims

1. A method for bridge maintenance and management intelligent decision-making based on multi-agent, characterized in that, Includes the following steps: S1. Connect to multimodal data in the field of bridge maintenance, encapsulate and standardize the multimodal data through interfaces, and construct a multimodal data access layer in the field of bridge maintenance. S2. Construct a knowledge graph for the field of bridge maintenance, using a directed multigraph structure and a triplet-based structured model of knowledge in the field of bridge maintenance. S3. Encode the experience and knowledge of bridge maintenance experts into skill templates to build a skill library in the field of bridge maintenance; S4. Based on the constructed bridge maintenance domain skill library, initialize the planning agent and construct a globally shared state space for recording task status and context data. The system receives natural language queries from users, uses the planning agent in conjunction with the bridge maintenance skill library to perform intent recognition, scene classification and task decomposition, obtains a list of sub-tasks with dependencies, and updates it to the global shared state space. S5. Based on the subtask list in the global shared state space, the scheduler resolves the dependencies, selects executable subtasks in sequence, and assigns them to the corresponding professional execution agents through a conditional routing mechanism. S6. Each of the specialized execution agents receives the assigned sub-tasks, uses the ReAct mode to call predefined domain tools, generates sub-task execution results, evidence sources and reasoning trajectories, and writes the sub-task execution results, evidence sources and reasoning trajectories back to the global shared state space. S7. Based on the knowledge graph of the bridge maintenance domain, perform entity existence, relationship legality and attribute constraint verification on the execution results of the sub-tasks in order to detect and correct illusions, generate an illusion detection report and update it to the global shared state space. S8. When all subtasks in the global shared state space are completed or the maximum number of iterations is reached, the planning agent retrieves the execution results, evidence sources, hallucination detection reports, and reasoning trajectories of each subtask from the global shared state space to generate a structured and traceable final answer for intelligent bridge maintenance decision-making.

2. The intelligent decision-making method for bridge maintenance based on multi-agent technology according to claim 1, characterized in that, In step S1, the multimodal data includes structured data, unstructured specification documents, computer vision model services, and finite element analysis software; The interface encapsulation and standardization processing of the multimodal data specifically includes: S11. Connect the structured data to a database engine and access a bridge maintenance relational database. The database contains a bridge basic information table, a technical condition assessment table, a defect record table, and a sensor monitoring information table. Configure a security control mechanism to allow only SELECT query statements to be executed. S12. Perform text segmentation and metadata parsing on unstructured standard documents, use a semantic embedding model to convert the text into high-dimensional vectors, and store them in a vector database to build a vectorized standard document library that supports semantic retrieval. S13. Through a standardized visual model client interface, encapsulate functions for bridge appearance defect detection, bridge deck vehicle detection, cable appearance detection, pier appearance detection, and multimodal large language model image analysis, and support access to computer vision model services. S14. Define the finite element analysis client interface, encapsulate the functions of model file generation, analysis execution and result parsing, and support access to the finite element analysis software.

3. The intelligent decision-making method for bridge maintenance based on multi-agent technology according to claim 1, characterized in that, In step S2, the knowledge graph for bridge maintenance includes the following domain knowledge: Bridge structural hierarchy knowledge is used to describe the hierarchical inclusion relationship between bridges and their components; Component-Disease Correspondence Knowledge is used to describe the association mapping between bridge components and disease types; Disease-maintenance mapping knowledge is used to describe the correspondence between disease types and maintenance methods; Technical condition assessment standards are used to describe the correspondence between technical condition levels, scoring ranges, and maintenance measures; Monitoring indicators and threshold knowledge, used to describe the units, applicable components, early warning thresholds, and alarm thresholds of monitoring indicators; Material property knowledge is used to describe the relationship between components and materials, as well as the mechanical property parameters of materials; Standardized reference relationship knowledge is used to describe the traceability relationship between knowledge entries and source standards.

4. The intelligent decision-making method for bridge maintenance based on multi-agent technology according to claim 1, characterized in that, In step S3, the skill template includes the following attributes: unique skill identifier, skill name, function description, applicable scenario type, trigger keyword list, execution step list, and matching priority weight; wherein, each step in the execution step list specifies the assigned agent type, task category, parameter template, and dependency relationship.

5. The intelligent decision-making method for bridge maintenance based on multi-agent technology according to claim 4, characterized in that, In step S4, the intent recognition and scenario classification includes: classifying the user's natural language query into a single bridge scenario, a regional scenario, or a general scenario, and identifying the corresponding task category; the task category includes single bridge monitoring, single bridge detection, single bridge technical status, single bridge maintenance, regional disease trends, regional maintenance strategies, regional budget allocation, regional data overview, standard query, and general questions.

6. The intelligent decision-making method for bridge maintenance based on multi-agent technology according to claim 5, characterized in that, In step S4, the specific processing steps for task decomposition include: S41. Calculate the matching score between the user's natural language query and the trigger keywords of each skill template, and filter out a preset number of skill templates before the matching score. S42. Convert the matched skill template into structured reference text and inject it into the prompt words of the planning agent; S43. The planning agent generates a list of subtasks with dependencies based on the prompt words and the user's natural language query; wherein each subtask in the list includes a task identifier, a task description, an assigned agent type, a dependency list, and a parameter dictionary.

7. The intelligent decision-making method for bridge maintenance based on multi-agent technology according to claim 6, characterized in that, In step S5, the specific process of resolving dependencies through the scheduler and sequentially selecting executable subtasks includes: S51. The scheduler traverses the subtasks in the subtask list whose status is "to be executed"; S52. Determine that all preceding subtasks in the dependency relationship of each subtask to be executed have been completed; S53. Select the first subtask whose dependencies are all satisfied as the currently executable subtask; S54. Extract the execution results from the completed previous subtasks and inject them into the parameter dictionary of the current subtask; S55. Update the current subtask identifier and iteration counter in the global shared state space.

8. The intelligent decision-making method for bridge maintenance based on multi-agent technology according to claim 7, characterized in that, In step S5, the conditional routing mechanism assigns the subtask to the corresponding professional execution agent based on the agent type field of the subtask's assignment. The specialized execution agents include: SQL agent, retrieval agent, analysis agent, code agent, vision agent, and finite element agent.

9. The intelligent decision-making method for bridge maintenance based on multi-agent technology according to claim 8, characterized in that, In step S6, the specific processing procedure of the ReAct mode includes: S61. Input the subtask description, parameter dictionary, and execution results extracted from the preceding subtask into a large language model equipped with domain system prompt words; S62. The large language model performs reasoning and thinking to determine the domain tools to be called and the calling parameters; S63. Execute domain tool calls and obtain tool return results, then feed the tool return results back to the large language model for further reasoning; S64. Repeat steps S62 to S63 until the preset information threshold is reached. Output the subtask execution results and evidence sources, and record the execution process as the reasoning trajectory.

10. The intelligent decision-making method for bridge maintenance based on multi-agent technology according to claim 1, characterized in that, In step S7, the specific methods for verifying entity existence, relation validity, and attribute constraints are as follows: Entity existence verification is used to verify whether the entities in the subtask execution results exist in the knowledge graph of the bridge maintenance domain. If they do not exist, similarity matching is performed and similar entity suggestions are returned. Relationship validity verification is used to verify whether the relationship between entity pairs in the subtask execution result is consistent with the relationship recorded in the bridge maintenance domain knowledge graph. If they are inconsistent, the actual relationship of the entity pair in the knowledge graph is returned. Attribute constraint validation is used to verify whether the numerical or attribute values ​​in the subtask execution result are within a preset range, which includes numerical range constraints and enumerated value constraints.

Images