A multi-agent factory collaborative management method, a storage medium and an electronic device

Abstract

The present application relates to a kind of multi-agent factory collaborative management method, storage medium and electronic equipment, it relates to computer technology field, the method includes: the natural language expression in task information is mapped to corresponding semantic object instance and determines the position of semantic object instance in global factory knowledge graph;Intelligent agent is executed by the determined business domain, obtains factory business data from the factory business information system connected thereto, and by large language model, under the path constraint of cross-domain association defined in global factory knowledge graph, with factory business data as input, cross-domain reasoning is carried out, wherein, cross-domain reasoning includes affected target business domain is traversed along cross-domain association, and the business data of each target business domain is integrated to generate reasoning result, and according to reasoning result, collaborative operation is executed, so that without manual cross-department coordination, global event can be responded timely and accurately.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a multi-agent factory collaborative management method, storage medium, and electronic device. Background Technology

[0002] In the field of factory management, multiple information systems designed for different business domains are typically deployed in parallel. These include Manufacturing Execution System (MES) for managing production scheduling and execution, Warehouse Management System (WMS) for managing material inventory and procurement, Equipment Management System for managing equipment status and maintenance, and Quality Management System for managing quality inspection and traceability. These information systems are independently built for different business domains such as manufacturing execution, material inventory, equipment operation and maintenance, and quality inspection. Their underlying data models, semantic definitions, and interaction interfaces are heterogeneous, forming isolated data silos.

[0003] Due to the lack of a unified knowledge model and cross-system linkage mechanism, existing methods cannot automatically semantically correlate and collaboratively process abnormal events in a specific business segment with other related business areas when global events such as material shortages, continuous quality defects, or sudden equipment failures occur within the factory. For example, a shortage of a key component in the material inventory domain cannot be automatically mapped to adjustments in the production schedule of the corresponding work order in the manufacturing execution domain, downtime predictions for relevant workstations in the equipment maintenance domain, or linkage changes in overtime hours and manpower allocation in the personnel scheduling domain. Currently, the aforementioned cross-domain collaboration still mainly relies on on-site managers manually discovering anomalies, reporting them layer by layer, coordinating across departments, and manually modifying data in various systems. This approach is not only slow and inefficient but also prone to decision-making biases due to distorted information transmission. Summary of the Invention

[0004] (a) Technical problems to be solved

[0005] In view of the above-mentioned shortcomings and deficiencies of the prior art, the present invention provides a multi-agent factory collaborative management method, storage medium and electronic device, which solves the technical problems existing in the prior art that are unable to automatically semantically associate and collaboratively process global events across domains, can only rely on manual cross-departmental coordination, and are slow to respond and prone to errors.

[0006] (II) Technical Solution

[0007] To achieve the above objectives, the main technical solutions adopted by the present invention include:

[0008] In a first aspect, embodiments of the present invention provide a multi-agent factory collaborative management method, comprising: constructing a global factory knowledge graph; wherein the global factory knowledge graph is used to define semantic objects of multiple business domains within the factory, and also defines cross-domain association relationships between semantic objects of different business domains; deploying a multi-agent system; wherein the multi-agent system includes a task understanding and scheduling agent and multiple business domain execution agents, and each business domain execution agent is connected to a different factory business information system; receiving input task information through the task understanding and scheduling agent, and performing semantic disambiguation on the task information according to the global factory knowledge graph, so as to map the natural language expression in the task information to the corresponding semantic object instance and determine the semantic object instance. For example, the position of the entity in the global factory knowledge graph, and the determination of at least one business domain execution agent for executing task information based on the position; through the determined business domain execution agent, factory business data is obtained from the factory business information system it is connected to, and cross-domain reasoning is performed by the large language model under the path constraints of the cross-domain association relationship defined in the global factory knowledge graph, with the factory business data as input. The cross-domain reasoning includes traversing the affected target business domains hop by hop along the cross-domain association relationship, generating reasoning results by integrating the business data of each target business domain, and performing collaborative operations based on the reasoning results. The collaborative operations include at least one of outputting decision results and issuing cross-system execution instructions to the corresponding factory business information system.

[0009] Optionally, semantic disambiguation is performed on the task information based on the global factory knowledge graph to map the natural language expressions in the task information to corresponding semantic object instances and determine the position of the semantic object instances in the global factory knowledge graph. Specifically, this includes: using a pre-defined factory domain terminology dictionary and thesaurus to perform terminology normalization on the natural language expressions in the task information, and matching the normalized terms with the semantic objects in the global factory knowledge graph to determine candidate semantic objects associated with the task information; and parsing the referential words or time expressions contained in the task information based on the context of the task information or the current system time to determine the semantic object instance that the task information actually points to and its position in the global factory knowledge graph from the candidate semantic objects.

[0010] Optionally, cross-domain associations include at least one of causal associations, temporal associations, and numerical constraint associations;

[0011] Cross-domain relationships are stored in the global factory knowledge graph in the form of triples. A triple consists of two semantic objects belonging to two different business domains and the relationship type connecting the two semantic objects. The relationship type is used to indicate the direction of the path traversal of the large language model along the cross-domain relationship when performing cross-domain reasoning.

[0012] Optionally, the affected target business domains are traversed hop-by-hop along the cross-domain association relationship. Specifically, this includes: starting from the position of the semantic object instance in the global factory knowledge graph as the starting node, and following the path traversal direction indicated by the relation type in the triple, starting from the starting node, sequentially visiting adjacent semantic objects along the cross-domain association relationship corresponding to the relation type; when each adjacent semantic object is visited, it is determined whether the target business domain to which the semantic object belongs is affected by the task information based on the business data of the semantic object and the relation type of the cross-domain association relationship connecting the semantic object; if it is determined to be affected, the business data of the semantic object is included in the step of generating inference results by integrating the business data of each target business domain; the traversal is terminated after all affected semantic objects have been visited.

[0013] Optionally, the multiple business domain execution agents include at least a supply chain domain execution agent, a production domain execution agent, and a finance domain execution agent; the supply chain domain execution agent is connected to the supply chain management system as the factory business information system, the production domain execution agent is connected to the manufacturing execution system as the factory business information system, and the finance domain execution agent is connected to the enterprise resource planning system as the factory business information system.

[0014] Cross-system execution instructions are structured instructions generated for the supply chain management system, manufacturing execution system, and enterprise resource planning system, respectively, so that the corresponding factory business information system can recognize and execute them.

[0015] Optionally, the collaborative operation specifically includes: when the reasoning result involves cross-departmental approval or strategic decision-making, generating the reasoning result into a decision report and pushing it to the management terminal, and receiving the confirmation instruction returned by the management terminal; after receiving the confirmation instruction, converting the reasoning result into a cross-system execution instruction and sending it to the corresponding factory business information system.

[0016] Optionally, cross-domain reasoning also includes an anomaly propagation link generation step, which includes: when there is abnormal data in the factory business data, the large language model traces the upstream impact source and downstream impact range of the abnormal data along the cross-domain association defined in the global factory knowledge graph, and generates an anomaly propagation link graph, which contains the complete propagation path of the abnormal data from the starting node to the ending node; and outputs the anomaly propagation link graph as part of the reasoning result.

[0017] Optionally, the method further includes a feedback learning step, and the feedback learning step includes: recording input task information of each cross-domain reasoning, the determined combination of service domain execution agents, the reasoning path of the large language model for cross-domain reasoning, the execution result of the cooperative operation, and the execution time consumption to form a historical execution record; when new task information is received, the task understanding and scheduling agent calculates the semantic similarity between the new task information and each input task information in the historical execution record, selects the combination of service domain execution agents corresponding to the historical execution record with the highest semantic similarity as an initial scheduling scheme, and dynamically corrects the initial scheduling scheme according to the updated states of semantic objects in the global factory knowledge graph during execution.

[0018] In a second aspect, an embodiment of the present invention provides a storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the multi-agent factory collaborative management method according to any one of the first aspect.

[0019] In a third aspect, an embodiment of the present invention provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the multi-agent factory collaborative management method according to any one of the first aspect.

[0020] (III) Beneficial Effects

[0021] The beneficial effects of the present invention are:

[0022] Embodiments of the present application provide a multi-agent factory collaborative management method, a storage medium, and an electronic device. By constructing a global factory knowledge graph that defines semantic objects of multiple service domains and their cross-domain association relationships, and deploying a multi-agent system including a task understanding and scheduling agent and a plurality of service domain execution agents, after receiving task information, semantic disambiguation can be performed on the task information based on the global factory knowledge graph, natural language expressions are mapped to corresponding semantic object instances and their positions in the global factory knowledge graph are determined, so that corresponding service domain execution agents can be accurately scheduled. In addition, after the scheduled service domain execution agent obtains factory service data from the factory service information system, the large language model performs cross-domain reasoning under the path constraint of the cross-domain association relationships, traverses the affected target service domains hop by hop along the cross-domain association relationships, synthesizes service data of each target service domain to generate a reasoning result, and finally executes cooperative operations according to the reasoning result, which realizes automatic cross-domain collaboration based on unified semantics among multiple service domains in a factory, eliminates semantic barriers brought by data islands, and can make timely and accurate linked responses to global events without manual cross-departmental coordination. Description of Drawings

[0023] Figure 1 A flowchart of a multi-agent factory collaborative management method provided in an embodiment of this application is shown;

[0024] Figure 2 This illustration shows a semantic disambiguation process provided in an embodiment of this application;

[0025] Figure 3 This illustration shows a schematic diagram of a dynamic self-evolution process of a global factory knowledge graph based on multi-agent collaboration, provided in an embodiment of this application. Detailed Implementation

[0026] To better explain and facilitate understanding of the present invention, the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0027] To address the shortcomings of existing technologies, such as the inability to automatically semantically associate and collaboratively process cross-domain global events, reliance on manual cross-departmental coordination, and the resulting slow response and susceptibility to errors, this application provides a multi-agent factory collaborative management method, storage medium, and electronic device. By constructing a global factory knowledge graph that defines semantic objects across multiple business domains and their cross-domain relationships, and deploying a multi-agent system including task understanding and scheduling agents and multiple business domain execution agents, upon receiving task information, semantic disambiguation can be performed on the task information based on the global factory knowledge graph. This maps natural language expressions to corresponding semantic object instances and determines their positions within the global factory knowledge graph, thereby accurately scheduling the corresponding business domain execution agents. Furthermore, after the scheduled business domain execution agent obtains factory business data from the factory business information system, the large language model performs cross-domain reasoning under the path constraints of the cross-domain association relationship. It traverses the affected target business domains hop by hop along the cross-domain association relationship and generates reasoning results by integrating the business data of each target business domain. Finally, it performs collaborative operations based on the reasoning results, realizing automated cross-domain collaboration between multiple business domains within the factory based on unified semantics. This eliminates the semantic barriers caused by data silos and enables timely and accurate linkage responses to global events without the need for manual cross-departmental coordination.

[0028] To better understand the above technical solutions, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present invention can be understood more clearly and thoroughly, and that the scope of the present invention can be fully conveyed to those skilled in the art.

[0029] Please see Figure 1 , Figure 1 A flowchart of a multi-agent factory collaborative management method provided in an embodiment of this application is shown. It should be understood that this method can be executed by an electronic device, and the specific device of the electronic device can be configured according to actual needs; this embodiment is not limited thereto. For example, the electronic device can be a calculator or a server, etc. Specifically, the method may include:

[0030] Step S110: Construct a global factory knowledge graph. The global factory knowledge graph defines semantic objects from multiple business domains within the factory, and also defines cross-domain relationships between semantic objects from different business domains.

[0031] Specifically, a global factory knowledge graph is first constructed. This global factory knowledge graph is not a database for storing specific business instance data, but rather a conceptual model for formally describing cross-domain knowledge within the factory. More specifically, this global factory knowledge graph is used to define semantic objects from multiple business domains within the factory, and also defines the cross-domain relationships between semantic objects from different business domains.

[0032] In this embodiment, business domains refer to different categories divided according to factory operation and management functions, including but not limited to: the manufacturing execution domain (managing production scheduling and execution), the material inventory domain (managing material inventory and procurement), the quality inspection domain (managing quality inspection standards and defect records), and the equipment operation and maintenance domain (managing equipment operating status and maintenance plans). It can be understood that business domains can also include personnel scheduling domains, financial accounting domains, etc. This embodiment does not exhaustively limit the specific number and types of business domains. The reason for dividing according to business domains is that the existing business information systems in the factory (such as the manufacturing execution system, warehouse management system, quality management system, and equipment management system) are independently constructed according to these domains, and the data of each system naturally carries domain attributes. Therefore, organizing semantic objects by business domains in a knowledge graph can directly align with the boundaries of existing information systems, reducing construction and maintenance costs.

[0033] Semantic objects are formal definitions of core business concepts in various business domains. Each semantic object represents a type of entity or concept with a clear business meaning within that business domain. Semantic objects act as nodes in the knowledge graph, unifying the heterogeneous representations of the same type of thing across different business information systems at the semantic level. For example, semantic objects in the manufacturing execution domain may include work orders, production lines, and process parameters; semantic objects in the material inventory domain may include materials, suppliers, and inventory levels; semantic objects in the quality inspection domain may include quality defects, inspection standards, and inspection points; and semantic objects in the equipment operation and maintenance domain may include equipment, fault events, and maintenance work orders. It is understood that the above semantic objects are merely illustrative examples, and in actual implementation, they can be added, deleted, or adjusted according to the specific business needs of the factory. It should be noted that semantic objects define abstract types, not concrete instances. For example, a material is a semantic object type, while "a chip with model number XYZ" is a concrete instance of that semantic object. Instance data is still stored in each business information system; the knowledge graph only maintains its type definition and relationships.

[0034] Furthermore, cross-domain relationships are directed edges connecting semantic objects belonging to two different business domains, used to describe the business logic connections between semantic objects in different business domains. Their function is to enable subsequent cross-domain reasoning to traverse from one business domain to another along these predefined directed edges, thereby achieving semantic-level cross-domain collaboration.

[0035] Typically, cross-domain relationships include, but are not limited to, at least one of causal relationships, temporal relationships, and numerical constraint relationships. A causal relationship indicates that the generation or change of one semantic object directly leads to the generation or change of another semantic object. For example, there is a causal relationship of "causing delay" between the semantic object "material shortage" in the material inventory domain and the semantic object "work order" in the manufacturing execution domain. A temporal relationship indicates that there is a temporal sequence or dependency between two semantic objects belonging to different business domains. The start or completion of one semantic object is a prerequisite for the start or completion of the other semantic object, but there is not necessarily a direct causal mechanism between them. For example, there is a temporal relationship of "prior to execution" between the semantic object "equipment maintenance plan" in the equipment maintenance domain and the semantic object "work order" in the manufacturing execution domain. A numerical constraint relationship indicates that the numerical attribute of one semantic object has a computational or constraint relationship with the numerical attribute of another semantic object. For example, there is a numerical constraint relationship of "consumption" between the semantic object "work order" in the manufacturing execution domain and the semantic object "material" in the material inventory domain. This relationship defines the quantity of materials required to produce one product.

[0036] In one specific implementation, cross-domain relationships are stored in the global factory knowledge graph as triples. Each triple consists of two semantic objects belonging to two different business domains, and the relation type connecting these two semantic objects. For example, a triple can be represented as: (material shortage, causing delay, work order), where material shortage and work order are the two semantic objects belonging to the material inventory domain and the manufacturing execution domain, respectively, and "causing delay" is the relation type. Here, "relation type" is a semantic classification label for cross-domain relationships. Its functions are twofold: first, to identify the nature of the business logic connection between the two semantic objects (such as causality, temporal sequence, or numerical constraints); and second, to indicate the direction of path traversal along the cross-domain relationship when the large language model performs cross-domain reasoning. Specifically, each triple defines a directed edge, with the edge pointing from the starting semantic object to the target semantic object, and the relation type is marked on this directed edge. When the large language model needs to perform cross-domain reasoning, reading the relation type reveals which semantic object to start from, in which direction, and according to what logical properties to traverse to the next semantic object. For example, in the triple "material shortage → delay → work order", the traversal direction is from "material shortage" to "work order", indicating that the impact of the material shortage event is transmitted to the downstream production scheduling process. Conversely, when the reasoning goal is to trace the root cause, the traversal is reversed from "work order" back to "material shortage". Through the above triple structure, business concepts that were originally scattered in various business information systems and had heterogeneous semantics are linked into an organic whole at a unified semantic level, providing a structured path constraint foundation for subsequent cross-domain reasoning in the large language model. It should be noted that it is a necessary condition for the two semantic objects in the triple to belong to two different business domains—if the two semantic objects belong to the same business domain, their relationship is an intra-domain relationship and is not covered by the cross-domain relationship defined in this scheme. This constraint ensures that cross-domain edges in the knowledge graph only connect different domains, making the traversal behavior inherently cross-domain. In the manner described above, the global factory knowledge graph constructed in step S110 provides a unified semantic foundation that can be understood and reasoned by machines for the entire multi-agent system. It clearly defines "what business concepts the factory has" and "how these concepts are related across domains", thereby breaking down data silos between various business information systems at the semantic level.

[0037] Step S120: Deploy the multi-agent system. This system includes a task understanding and scheduling agent and multiple business domain execution agents, with each business domain execution agent connected to a different factory business information system.

[0038] Specifically, after constructing the global factory knowledge graph, this step deploys a multi-agent system. This multi-agent system is a software system running on a computer, composed of multiple agents built based on a large language model. These agents collaborate through a pre-defined communication protocol to jointly complete cross-domain collaborative management tasks within the factory. Specifically, the multi-agent system includes a task understanding and scheduling agent and multiple business domain execution agents, with each business domain execution agent connected to different factory business information systems.

[0039] In this embodiment, the multi-agent system refers to a distributed computing system composed of multiple autonomously operating agent units, each of which possesses the ability to independently perceive the environment, perform reasoning, and execute actions. In this scheme, each agent integrates or invokes a large language model to utilize its semantic understanding and reasoning capabilities to handle complex factory management tasks. Here, the large language model refers to a natural language processing model pre-trained based on a large-scale parametric neural network, possessing capabilities such as semantic understanding, common-sense reasoning, multi-step logical deduction, and text generation. Reasoning services can be provided by a privately deployed model instance locally within the system, or reasoning capabilities can be obtained by calling a cloud-based model service interface. Regarding deployment, the large language model can adopt either a unified deployment or separate deployment architecture: a unified large language model can be deployed within the system as a shared reasoning engine, which each agent uses by calling an interface; alternatively, separate large language model instances can be deployed for the task understanding and scheduling agent and the execution agents for each business domain. Both deployment methods fall within the protection scope of this scheme. Regardless of the deployment architecture, the large language models invoked by each agent are equivalent in reasoning capability; the only difference lies in the number of deployment instances and the interface invocation method. Agents communicate and coordinate through a message passing mechanism. The task understanding and scheduling agent uniformly receives external tasks and assigns subtasks to the corresponding business domain execution agents. After completing the subtasks, the business domain execution agents return the results to the task understanding and scheduling agent or directly execute collaborative operations. The advantage of this architecture is that each business domain execution agent can independently maintain its connection with its respective business information system, resulting in stronger overall system scalability and fault tolerance. For example, when a new business domain is added, only the corresponding execution agent needs to be deployed and registered with the task understanding and scheduling agent; no modification to existing agents is required.

[0040] It is important to note that the large language model mentioned throughout this scheme refers to the same large language model. Specifically, the task understanding and scheduling agent invokes this large language model to perform semantic disambiguation tasks, mapping task information in natural language form to semantic object instances in the global factory knowledge graph. Each business domain execution agent invokes this large language model to perform cross-domain reasoning tasks, traversing the affected target business domains hop-by-hop under the path constraints of cross-domain relationships and generating reasoning results. In the anomaly propagation link generation step, the business domain execution agent invokes the same large language model to trace the upstream impact source and downstream impact range of the abnormal data along the cross-domain relationships. In the new cross-domain relationship discovery and semantic object instantiation and attribute expansion steps of the global factory knowledge graph dynamic self-evolution step, the business domain execution agent also invokes this large language model to perform cross-domain relationship pattern mining, relationship type determination, and semantic type identification. Regardless of the calling entity or specific task, the same large language model provides the reasoning capability; the only difference lies in the task instructions and context data input by each agent.

[0041] Furthermore, the task understanding and scheduling agent is the core coordination unit of the multi-agent system. Functionally, it undertakes two main responsibilities: First, as the interaction entry point between the system and the user, it receives input task information, which is typically a high-level instruction in natural language form, such as analyzing the reasons for the monthly production cost exceeding the standard in the welding workshop or handling the impact of a shortage of a certain type of chip on production scheduling; Second, as the global scheduling center, it performs semantic disambiguation on the task information based on the global factory knowledge graph, mapping the natural language expression in the task information to corresponding semantic object instances and determining the position of the semantic object instances in the global factory knowledge graph. Based on this position, it then determines at least one business domain execution agent to execute the task information. The above semantic disambiguation process utilizes the large language model integrated in the task understanding and scheduling agent, as well as the semantic object definitions in the global factory knowledge graph constructed in step S110. Specifically, the task understanding and scheduling agent first performs word segmentation and named entity recognition on the input natural language instructions to identify the factory terms involved (such as production line names, material codes, workstation numbers, etc.). Then, it normalizes these terms using a pre-defined factory domain terminology dictionary and thesaurus. The normalized terms are then matched with semantic objects in the global factory knowledge graph to determine which semantic object instances in the knowledge graph correspond to the events or objects mentioned in the instructions and their positions within the graph. Since each semantic object instance in the knowledge graph belongs to a specific business domain, once the position of the semantic object instance is determined, the business domain of that position can be identified, thus determining which business domain execution agent should be scheduled to connect to the corresponding business domain information system. The task understanding and scheduling agent packages the decomposed subtasks and their context information into structured task instructions, sends them to the corresponding business domain execution agents, and is responsible for aggregating intermediate results and coordinating the execution order when multiple agents are executing collaboratively.

[0042] Furthermore, the business domain execution agent is an intelligent agent unit responsible for interacting with specific factory business information systems and executing specific domain tasks. Each business domain execution agent connects to different factory business information systems to obtain factory business data from the connected systems. It then uses a large language model, within the path constraints of cross-domain relationships defined in the global factory knowledge graph, to perform cross-domain reasoning on the obtained factory business data. The number of business domain execution agents can be flexibly configured according to the actual business domain divisions of the factory, for example, including at least manufacturing execution agents, material inventory agents, quality inspection agents, and equipment operation and maintenance agents. Each business domain execution agent internally maintains a set of data access adaptation interfaces corresponding to the business information systems it connects to. This is used to map semantic object types in the knowledge graph to data query statements (such as SQL, API calls, etc.) of the specific information systems, and convert the returned structured data into business data of semantic object instances for reasoning. Simultaneously, each business domain execution agent also maintains a local subgraph cache of its responsible business domain in the global factory knowledge graph to improve traversal and matching efficiency.

[0043] Furthermore, a factory business information system refers to a computer information system deployed within a factory to manage the daily operations of various business areas. Typical factory business information systems include, but are not limited to: Manufacturing Execution System (MES) for managing production scheduling and work order execution; Warehouse Management System (WMS) for managing material inventory and purchase orders; Quality Management System (QMS) for managing quality inspection standards and defect records; Equipment Management System (EMS) for managing equipment ledgers and maintenance plans; and Enterprise Resource Planning System (ERP) for managing financial accounting and budgeting. These systems may be physically deployed on different servers or industrial control computers, and have their own independent data models, semantic definitions, and interaction interfaces (such as different database table structures, API protocols, etc.). Each business area execution agent obtains real-time factory business data by calling the application programming interface (API) or database query interface provided by the corresponding factory business information system, and after inference, sends cross-system execution instructions to the corresponding factory business information system through the same interface channel, triggering the system's automatic operations (such as modifying work order priorities, freezing inventory, adjusting production schedules, etc.). It should be noted that the connection between the business domain execution agent and the factory business information system is not necessarily a strict one-to-one mapping. For example, a business domain execution agent can connect to multiple related business information systems (e.g., a manufacturing execution agent may connect to both MES and ERP to obtain work order data and their corresponding cost data). A business information system can also be accessed by multiple execution agents in read-only mode. The specific configuration depends on the actual information system architecture of the factory.

[0044] In one optional implementation, the multiple business domain execution agents include at least a supply chain domain execution agent, a production domain execution agent, and a finance domain execution agent. It should be noted that the supply chain domain, production domain, and finance domain here are specific instances of the multiple business domains defined in step S110, corresponding respectively to the business scopes of managing material procurement and inventory, managing production scheduling and execution, and managing cost accounting and budgeting within the factory.

[0045] Specifically, in the supply chain domain, the executing agent connects to the supply chain management system (SMS) as the factory's business information system. Here, the SMS refers to a computer information system deployed within the factory for managing material procurement, inventory, and supplier information, such as a warehouse management system or a supply chain management module within an enterprise resource planning (ERP) system. The executing agent in the supply chain domain obtains real-time factory business data, such as inventory levels, purchase order status, and logistics node information, by calling the application programming interfaces (APIs) provided by the SMS. In the production domain, the executing agent connects to the manufacturing execution system (MES) as the factory's business information system, obtaining real-time factory business data such as work order status, production line capacity, and process parameters by calling the MES's APIs. In the financial domain, the executing agent connects to the enterprise resource planning (ERP) system as the factory's business information system, obtaining real-time factory business data such as cost data, budget limits, and cash flow by calling the ERP's APIs.

[0046] Under the above architecture, cross-system execution instructions are structured instructions generated for the supply chain management system, manufacturing execution system, and enterprise resource planning system, respectively, for recognition and execution by the corresponding factory business information systems. Here, structured instructions refer to executable commands that conform to the interface specifications of the target business information system, such as production scheduling adjustment instructions conforming to the API protocol of the manufacturing execution system, and budget freeze instructions conforming to the data format of the enterprise resource planning system. Since different factory business information systems may use different data formats, communication protocols, and interface specifications during deployment, instructions in a unified format cannot be correctly parsed by each system. Therefore, the corresponding business domain execution agent needs to convert the inference results into structured instructions recognizable by each system according to the interface specifications of the target system it connects to, before issuing them. For example, in a material shortage scenario, the inference results generated by cross-domain inference indicate that both production scheduling and financial budget need to be adjusted simultaneously. In this case, the production domain execution agent is responsible for converting the scheduling adjustment plan into a structured instruction recognizable by the manufacturing execution system and issuing it, while the financial domain execution agent is responsible for converting the budget adjustment plan into a structured instruction recognizable by the enterprise resource planning system and issuing it. The two instructions are generated independently and executed separately under the interface formats of their respective target systems.

[0047] The multi-agent system deployed in the above manner allows each agent to perform its specific function and collaborate within the unified semantic framework of the global factory knowledge graph. This provides the operational foundation for subsequent steps such as task reception, semantic disambiguation, scheduling and execution, and cross-domain reasoning. The task understanding and scheduling agent is responsible for semantic understanding and task assignment, while the execution agents in each business domain are responsible for connecting to various business information systems, acquiring data, performing reasoning, and issuing instructions. The two agents work together to form a complete semantic-driven collaborative management closed loop for the factory.

[0048] Step S130 involves receiving input task information through a task understanding and scheduling agent, performing semantic disambiguation on the task information based on the global factory knowledge graph, mapping the natural language representation in the task information to corresponding semantic object instances, determining the position of the semantic object instances in the global factory knowledge graph, and determining at least one business domain execution agent based on the position to execute the task information.

[0049] Specifically, the task understanding and scheduling agent performs semantic disambiguation on task information based on the global factory knowledge graph, mapping the natural language expressions in the task information to corresponding semantic object instances and determining the position of the semantic object instances in the global factory knowledge graph, such as... Figure 2 As shown, it specifically includes the following two steps: Step S131, using a preset factory domain terminology dictionary and thesaurus, the natural language expression in the task information is normalized, and the normalized terms are matched with semantic objects in the global factory knowledge graph to determine the candidate semantic objects associated with the task information; Step S132, based on the context of the task information or the current system time, the referential words or time expressions contained in the task information are parsed to determine the semantic object instance that the task information actually points to and its position in the global factory knowledge graph from the candidate semantic objects.

[0050] In step S131, the task understanding and scheduling agent uses a pre-defined factory domain terminology dictionary and thesaurus to perform terminology normalization on the natural language expressions in the task information, and matches the normalized terms with semantic objects in the global factory knowledge graph to determine candidate semantic objects associated with the task information.

[0051] Here, the factory domain terminology dictionary refers to a pre-built vocabulary list that includes standard terms from various business domains within a factory management scenario. Each entry in this dictionary contains a standard term and its associated business domain tag; for example, a work order corresponds to the manufacturing execution domain, inventory level corresponds to the material inventory domain, and quality defects correspond to the quality inspection domain. The factory domain terminology dictionary can be constructed from data dictionaries of various business information systems, standard operating procedure documents within the factory, and industry standard terminology sets. Once completed, it is maintained synchronously with updates to the knowledge graph.

[0052] Furthermore, a thesaurus refers to a pre-built vocabulary that records different expressions of the same concept that may appear in a factory setting and their mapping relationships. Since factory workers may use colloquial expressions, abbreviations, or common phrases to describe the same thing—for example, a welding workshop might be called welding, welding shop, or welding section—and a material shortage might be described as "material shortage," "insufficient material," or "out of stock"—the purpose of the thesaurus is to uniformly map these non-standard expressions to the standard terms in a factory-specific terminology dictionary. Each entry in the thesaurus contains a non-standard expression and its corresponding standard term; the mapping relationship can be one-to-one or many-to-one.

[0053] Furthermore, terminology normalization refers to the process of converting the natural language expressions in the task information into standard terms recognizable by the global factory knowledge graph using the aforementioned factory domain terminology dictionary and thesaurus. Specifically, the task understanding and scheduling agent first performs word segmentation and named entity recognition on the input natural language instructions to identify the factory terms involved (such as production line names, material codes, workstation numbers, etc.). Then, it matches each identified term with the thesaurus: if a synonym is matched, it is replaced with the corresponding standard term; if no synonym is matched but a standard term in the factory domain terminology dictionary is directly matched, the original term is retained; if neither a synonym nor a term in the terminology dictionary is matched, the term is marked as an unrecognized item, and a disambiguation confirmation request is initiated to the user through the interactive interface or a fuzzy match is performed based on the context. After terminology normalization is completed, the task understanding and scheduling agent matches the normalized terms with semantic objects in the global factory knowledge graph. Here, matching refers to using the normalized standard terms as keywords to search for semantic object types with the same names in the global factory knowledge graph. The result of the matching is to identify candidate semantic objects associated with the task information. The term "candidate" is used here because in some cases, term matching alone may yield multiple semantic object types. For example, if the task information only mentions "chip," the term may match a material semantic object in the material inventory domain or a spare parts semantic object in the equipment maintenance domain. In this case, all matching results should be listed as candidate semantic objects and submitted to the context parsing in step S132 for further disambiguation.

[0054] In S132, the task understanding and scheduling agent parses the referential words or time expressions contained in the task information based on the context of the task information or the current system time, in order to determine the semantic object instance that the task information actually points to and its position in the global factory knowledge graph from the candidate semantic objects.

[0055] Here, referential terms refer to words in natural language expressions that refer to specific objects mentioned earlier or implied in the context, such as "this," "the aforementioned," and "its" in the context of "the work order," "the aforementioned production line," and "its corresponding materials." In factory management scenarios, referential terms may also appear in the form of abbreviations, numbers, or codes, such as workstation S-45 or ECO-202410-01. When the task understanding and scheduling agent parses referential terms, it determines the specific instance to which the referential term points based on the context of the task information, that is, the semantic object instances previously identified in the same task information. For example, if the task information is that workstation S-45 has continuous weld defects and its welding parameters need to be adjusted, the task understanding and scheduling agent first identifies workstation S-45 as a specific instance of the semantic object of the production line in the manufacturing execution domain. When it parses the referential term "its," it points to the semantic object instance corresponding to workstation S-45 based on the context.

[0056] Furthermore, a time expression refers to a word or phrase in natural language that represents a point in time or a range of time, such as "this month," "last week," "this afternoon," or "October 2024." In factory management scenarios, time expressions may also appear in the form of production cycles or shift numbers, such as "night shift" or "third shift." When parsing time expressions, the task understanding and scheduling agent combines the current system time (i.e., the real-time clock of the computer system at the time of semantic disambiguation) to convert relative time expressions into absolute time ranges. For example, "this month" is converted to the first day to the last day of the month in the current system time, and "last week" is converted to Monday to Sunday of the previous week. By parsing time expressions, the task understanding and scheduling agent can determine the time range involved in the task information, thereby assisting in locating semantic object instances, such as determining the set of work order instances to which the production plan for this month points.

[0057] After parsing the pronouns and temporal expressions, the task understanding and scheduling agent compares and filters the parsing results with the candidate semantic objects obtained in step S131. The specific comparison and filtering process is as follows:

[0058] First, the task understanding and scheduling agent traverses all candidate semantic objects determined in step S131. For each candidate semantic object, it determines whether it satisfies the pointing constraints in the referencing resolution result. If the referencing resolution result clearly identifies the specific instance that the task information actually points to (e.g., it has been determined to point to the specific instance S-45 workstation), then the candidate semantic objects directly corresponding to that instance identifier are selected from the candidate semantic objects, and other candidates are eliminated. If the referencing resolution result is a general reference to a certain type of semantic object without specifying a specific instance (e.g., it only identifies the production line type), then all candidate semantic objects belonging to that type are retained and not eliminated in this step.

[0059] Then, the task understanding and scheduling agent performs time constraint verification on the candidate semantic objects retained after referential filtering, based on the absolute time range obtained from the time expression parsing. The verification method is as follows: for each candidate semantic object, through the data access adapter interface of the factory business information system it is connected to, it queries the time-related attribute fields (such as the creation time of the work order, the warehousing time of materials, the detection time of quality defects, etc.) in the business data of the corresponding instance of the candidate semantic object, and determines whether the time attribute value falls within the absolute time range obtained from the time expression parsing. If it falls within the range, the candidate semantic object passes the time verification; if it does not, it is removed from the candidate list.

[0060] If, after referential constraints and time range limitations, only one candidate remains in the candidate semantic object list, the task understanding and scheduling agent directly identifies that candidate as the semantic object instance that the task information actually points to. If, after the above filtering, multiple candidate semantic objects still exist that meet the conditions, the task understanding and scheduling agent initiates a disambiguation confirmation request to the user through the interactive interface. This disambiguation confirmation request includes the following: a list of all remaining candidate semantic object instances, and key attribute information for each candidate instance (such as instance name, business domain, key timestamp, associated production line or material code, etc.), allowing the user to select and confirm one as the semantic object instance that the task information actually points to. The interactive interface can take the form of list selection or dialog confirmation. After the user confirms, the system will take the instance selected by the user as the final semantic object instance.

[0061] After identifying a unique semantic object instance, the task understanding and scheduling agent performs a location operation within the global factory knowledge graph. The specific process is as follows: using the instance identifier of the semantic object instance as the query condition, a precise match is performed in the graph node index of the global factory knowledge graph to obtain the node identifier of the graph node corresponding to the instance. This node identifier represents the position of the semantic object instance within the global factory knowledge graph. Subsequently, the task understanding and scheduling agent reads the business domain label to which the node identifier belongs (this label was pre-recorded during the construction of the global factory knowledge graph through the semantic object's domain affiliation attribute), and records both the node identifier and the corresponding business domain label as the basis for subsequently determining the business domain execution agent to be scheduled—the business domain execution agent connected to the factory business information system corresponding to this business domain is the execution agent to be scheduled.

[0062] Step S140: The intelligent agent, acting within the defined business domain, retrieves factory business data from the connected factory business information system. Under the path constraints of cross-domain relationships defined in the global factory knowledge graph, the large language model performs cross-domain reasoning using the factory business data as input. This cross-domain reasoning includes traversing the affected target business domains hop-by-hop along the cross-domain relationships, generating a reasoning result by integrating the business data from each target business domain, and executing collaborative operations based on the reasoning result. The collaborative operations include at least one of outputting a decision result and issuing cross-system execution instructions to the corresponding factory business information system.

[0063] Specifically, after determining the business domain execution agents to be scheduled through semantic disambiguation, the determined business domain execution agents obtain factory business data from the factory business information system they are connected to. This acquisition is achieved by using the data access adaptation interface maintained internally by each business domain execution agent to map the instance identifier of the semantic object instance to the corresponding data query statement of the business information system, initiating a query request to the business information system, and receiving the returned structured data as the factory business data. Factory business data refers to the current operating status data of the semantic object instance stored in the corresponding factory business information system, such as the production start time and execution status of work orders, the inventory quantity and safety threshold of materials, the operating load and overall equipment efficiency of the production line, and the level and detection time of quality defects.

[0064] After acquiring factory business data, the system enters the cross-domain reasoning stage. The core of cross-domain reasoning is to use the acquired factory business data as input for reasoning, under the path constraints of cross-domain relationships defined in the global factory knowledge graph by the large language model. The large language model called here is the same as the one defined in step S120. During the reasoning process, the large language model does not perform generalization reasoning in an open, unconstrained semantic space, but must move in a direction within the path network formed by the predefined cross-domain relationships in the global factory knowledge graph. This path constraint mechanism ensures the traceability of the reasoning results and the rigor of the business logic: each reasoning jump has a clear semantic edge as a basis, and each target business domain determined to be affected is connected to the starting event through one or more cross-domain relationship paths. In this way, business data that was originally stored in isolation in each factory business information system is linked together at a unified semantic level, realizing the ability to automatically discover the global impact from a single event.

[0065] Furthermore, the specific process of cross-domain reasoning includes traversing the affected target business domains hop-by-hop along the cross-domain relationships, and generating reasoning results by integrating the business data of each target business domain. The specific implementation method of hop-by-hop traversal is described in detail below.

[0066] In one optional implementation, traversing the affected target business domains hop-by-hop along cross-domain relationships is achieved as follows: First, starting from the position of the semantic object instance in the global factory knowledge graph, the system visits adjacent semantic objects sequentially along the cross-domain relationships corresponding to the relationship types, following the path traversal direction indicated by the relation types in the triples. The starting node refers to the graph node in the global factory knowledge graph that directly maps the semantic object instance determined after semantic disambiguation. This graph node has a unique node identifier and belongs to a specific business domain. The path traversal direction is predefined by the relation types in the triples; a relation type is essentially a directed edge pointing from the starting semantic object to the target semantic object. At the start of the traversal, the system uses the starting node as the current node and reads all cross-domain relationships and their relation types from the global factory knowledge graph, starting from the current node. It then obtains the target nodes pointed to by these cross-domain relationships, which are the semantic objects adjacent to the current node. The system visits these adjacent semantic objects sequentially according to the weight or preset priority of each cross-domain relationship.

[0067] During the traversal, each time an adjacent semantic object is accessed, the system retrieves the business data of that semantic object from the factory business information system connected to it. Based on the business data of the semantic object and the relationship type of the cross-domain association connecting the semantic object, the system determines whether the target business domain to which the semantic object belongs is affected by the task information. In determining whether it is affected, the system integrates two aspects of information: firstly, it analyzes whether there are any abnormal states or numerical changes in the business data related to the task information; secondly, it applies different judgment logic based on the relationship type of the cross-domain association connecting the semantic object. Specifically, if the relationship type is causal, meaning that an upstream event inevitably causes a downstream impact, then it is directly determined that the target business domain to which the adjacent semantic object belongs is affected; if the relationship type is temporal, then time attributes, such as planned start time and actual start time, are extracted from the business data of the adjacent semantic objects and compared with the time constraints of the upstream event. When the time attribute violates the temporal constraint, it is determined that the target business domain is affected; if the relationship type is numerical constraint, then numerical attributes, such as material consumption and working hours consumption, are extracted from the business data of the adjacent semantic objects and compared with the constraint thresholds or calculation formulas defined in the relationship type. When the value exceeds the constraint range, it is determined that the target business domain is affected.

[0068] If it is determined that an adjacent semantic object is affected, the business data of that semantic object is incorporated into the step of integrating business data from various target business domains to generate the inference result. Integration refers to aggregating the business data of all affected semantic objects into a single dataset for unified use by the large language model when generating the inference result. Simultaneously, the affected adjacent semantic object is marked as a new current node. The system continues to access its adjacent semantic objects along the cross-domain relationships originating from this node, repeating the process of acquiring data, determining impact, and collecting data. This multi-hop diffusion mechanism allows the impact to propagate hop-by-hop along the cross-domain relationship edges of the knowledge graph until all affected branches have been traversed. Traversal terminates when all affected semantic objects have been accessed—that is, when no new affected adjacent semantic objects are found in the current traversal level, or when there are no more unvisited cross-domain relationship edges. At this point, all semantic objects affected by task information triggers and their business data have been collected. The system aggregates this affected business data and provides it to the large language model, which performs integrated inference based on this data and the global factory knowledge graph to generate the inference result. The inference results can include a description of the scope of impact, an assessment of the degree of impact, root cause analysis conclusions, and response recommendations. For example, when material inventory data shows that the inventory of a certain chip is below the safety threshold, the large language model deduces the complete chain of impact step by step along the cross-domain correlation path of material shortage leading to work order delays, work order delays leading to production line shutdowns, and production line shutdowns leading to order delivery delays. It estimates the quantitative impact of each step and finally generates inference results that include the scope of impact, severity, and response recommendations.

[0069] After generating the inference results, the system performs collaborative operations based on those results. These collaborative operations include at least one of the following: outputting decision results and issuing cross-system execution instructions to the corresponding factory business information system.

[0070] In one optional implementation, the specific execution method of collaborative operations varies depending on the nature of the inference result. When the inference result involves cross-departmental approval or strategic decision-making, the system automatically generates a decision report after the large language model generates the inference result. The decision report is a structured, visual document containing an event overview, impact analysis, root cause inference, recommended response plans, and the expected effects and risks of each plan. This decision report is pushed to the management terminal through a pre-set communication channel. The management terminal refers to an electronic device with display and input functions used by the factory management, such as an industrial tablet PC, a control center large screen, or an authorized mobile terminal. The push method can be a system message notification, email, or an application pop-up on the management terminal. After pushing the decision report, the system enters a waiting confirmation state, listening for and receiving confirmation instructions returned by the management terminal. The confirmation instruction is an electronic signal generated by the management terminal after the management user selects or approves the response plan in the decision report, such as an operation instruction generated by clicking the "Agree to Adjust" button. Upon receiving the confirmation instruction, the system converts the corresponding execution plan in the inference result into a cross-system execution instruction and sends it to the corresponding factory business information system. The conversion process is completed by the business domain execution agent responsible for the corresponding business area, which maps the action descriptions in the inference results into structured instructions that conform to the target system's interface specifications. If the inference results do not involve cross-departmental approvals or strategic decisions, and fall within the scope of automatic correction of daily operational deviations, the system can directly generate and issue cross-system execution instructions without requiring confirmation from the management terminal. The criteria for judging daily operational deviations can be preset in the system configuration, such as minor anomalies affecting only a single workstation and requiring no adjustments to the budget or personnel arrangements.

[0071] Furthermore, in an optional implementation, cross-domain reasoning may also include an anomaly propagation path generation function. When anomaly data exists in the factory business data obtained from the factory business information system, the determined business domain execution agent invokes a large language model to trace the upstream impact source and downstream impact range of the anomaly data along the cross-domain associations defined in the global factory knowledge graph. The large language model invoked here is the same large language model used in the aforementioned semantic disambiguation and cross-domain reasoning, and this large language model undertakes the task of anomaly propagation path analysis here. Anomaly data refers to data values ​​or states in the factory business data that exceed the preset normal range or do not conform to business rules, such as the weld strength of multiple consecutive white body-in-white units being lower than the lower limit of the detection standard, or the inventory quantity of a key material being lower than the safety stock threshold, or the actual output of a production line being lower than the predetermined output rate of the production plan for several consecutive hours. The identification of anomaly data can be achieved through preset threshold rules, statistical anomaly detection algorithms, or the judgment of data patterns by the large language model. Tracing the upstream source of influence refers to starting from the semantic object node where the anomalous data is discovered and backtracking hop-by-hop along the cross-domain relationships in the global factory knowledge graph to find the root cause node that caused the anomaly. The direction of backtracking is indicated by the opposite direction of the relationship type: if a causal relationship is A leading to B, then backtracking is done from B back to A; if a temporal relationship is A preceding B, then backtracking is done from B to find the A event that occurred before it, and so on. Tracing the downstream scope of influence refers to starting from the semantic object node where the anomalous data is located and backtracking hop-by-hop along the cross-domain relationships in the global factory knowledge graph to identify all subsequent semantic object nodes that may be affected by the anomaly. During the tracing process, the large language model records the semantic object nodes traversed and the corresponding cross-domain relationship edges for each traversal, forming one or more complete propagation paths starting from the upstream source of influence, passing through the anomalous data node, and extending to the downstream termination node. The collection of these propagation paths constitutes the anomaly propagation link graph. An anomaly propagation graph is a visual directed graph structure where nodes represent affected semantic object instances, edges represent cross-domain relationships in the propagation of influence, and labels on the edges indicate the relationship type. This graph intuitively illustrates how anomaly events propagate and spread across various business areas within the factory. The generated anomaly propagation graph is output as part of the reasoning results, and the output format can include graphical displays and structured data descriptions, enabling management to quickly understand the global impact of the anomaly and providing a basis for subsequent response decisions.

[0072] In an optional implementation, the above method may further include a feedback learning step to optimize the execution efficiency of subsequent tasks using historical execution experience. Specifically, the system records the input task information for each cross-domain reasoning, the combination of determined business domain execution agents, the reasoning path of the large language model for cross-domain reasoning, the execution results of collaborative operations, and the execution time, forming a historical execution record. Input task information refers to the original task information received by the task understanding and scheduling agent, including natural language instruction text and its timestamp. The combination of business domain execution agents refers to the set of all business domain execution agents scheduled to participate in the execution of this task, recorded in the form of a list of agent identifiers. The reasoning path refers to the sequence of nodes and relation edges traversed by the large language model along the global factory knowledge graph during cross-domain reasoning, that is, the semantic object nodes visited hop by hop from the starting node and the relation types between them, forming a complete traversal trajectory. The execution results of collaborative operations refer to the operation status and specific operation effect data returned by each factory business information system after the collaborative operation is completed, such as the actual adjusted production schedule time of the work order and the amount of budget frozen. Execution time refers to the total time from the start of the task understanding and scheduling agent receiving task information to the completion of the collaborative operation, as well as the segmented time of each sub-stage. These records are stored in a structured format in the system's preset historical execution record library, and a new record is automatically written after each cross-domain inference task is completed.

[0073] When new task information is received, the task understanding and scheduling agent calculates the semantic similarity between the new task information and each input task information in the historical execution record. Semantic similarity calculation can utilize a large language model to encode the two task information texts into semantic vectors, and then calculate the cosine similarity or other similarity measures between the vectors. Alternatively, it can employ a similarity calculation method based on keywords and domain terms, combined with a weighted calculation using a factory domain terminology dictionary. The task understanding and scheduling agent selects the combination of business domain execution agents corresponding to the historical execution record with the highest semantic similarity as the initial scheduling scheme. The initial scheduling scheme refers to the set of business domain execution agents that the system defaults to scheduling at the beginning of new task execution, replacing the complete process of semantic disambiguation and graph localization from scratch, thereby accelerating the agent's scheduling decision. During execution, the task understanding and scheduling agent also dynamically modifies the initial scheduling scheme based on the updated state of semantic objects in the global factory knowledge graph. The state of a semantic object refers to the dynamic attributes of the semantic object in the global factory knowledge graph, such as the current inventory level of a material, the current execution status of a work order, and the current load of a production line. These states change with the real-time updates of data in the business information system. If, during the execution of the initial scheduling plan, real-time factory business data reveals a significant change in the state of the semantic object—for example, the previously out-of-stock materials have been replenished, or the previously affected work orders have been manually adjusted—causing certain business domain execution agents in the initial scheduling plan to no longer need to participate, or requiring the addition of other business domain execution agents, then the task understanding and scheduling agent dynamically adjusts the combination of participating business domain execution agents to ensure that the final scheduling plan is consistent with the latest state of the actual semantic object. Through the above feedback learning steps, the system can leverage historical execution experience to accelerate the scheduling and reasoning process of new tasks, improving the response efficiency and scheduling accuracy of the multi-agent system.

[0074] After the collaborative operation is completed, the multi-agent system enters the knowledge self-evolution stage, feeding back the execution experience of this cross-domain reasoning and collaborative operation to the global factory knowledge graph, triggering dynamic updates and structural optimization of the global factory knowledge graph. Specifically, such as Figure 3 As shown, the dynamic self-evolution steps of the global factory knowledge graph based on multi-agent collaboration include the execution result feedback collection step, the new cross-domain relationship discovery step, the semantic object instantiation and attribute expansion step, the confidence assessment and manual confirmation step, and the knowledge graph consistency maintenance step.

[0075] The feedback collection step includes the following: after each cross-domain reasoning and collaborative operation is completed, the task understanding and scheduling agent collects a complete record of the reasoning and execution, forming a feedback data record. The feedback data record includes at least the following: the input task information and the semantic object instances and locations determined after semantic disambiguation; the complete reasoning path traversed by the large language model along the global factory knowledge graph during cross-domain reasoning, i.e., the sequence of semantic object nodes visited hop-by-hop from the starting node and the sequence of cross-domain relationships between nodes; the factory business data obtained by each business domain execution agent from the connected factory business information system and the intermediate judgment results generated during the reasoning process; and the execution results of the collaborative operation, including the actual execution status and operational effect feedback data of the issued cross-system execution instructions in each factory business information system. This feedback data record overlaps somewhat with the historical execution record in the aforementioned feedback learning step, but their uses differ: the historical execution record is used to calculate the semantic similarity between the new task and the historical task to optimize agent scheduling, while the feedback data record is used to discover new cross-domain relationships and new semantic objects to update the global factory knowledge graph itself. In practice, the two can share the same underlying data storage, but serve two different goals: scheduling optimization and knowledge evolution.

[0076] Furthermore, the new cross-domain association discovery step includes: the determined business domain execution agent invokes a large language model to comprehensively analyze the inference paths in the feedback data records and the factory business data, identifying cross-domain association patterns that are not yet defined in the global factory knowledge graph but repeatedly occur in actual business operations. The large language model invoked here is the same large language model used in the aforementioned semantic disambiguation, cross-domain inference, and anomaly propagation link generation. This large language model undertakes the tasks of cross-domain association pattern mining and relationship type determination here. Specifically, the large language model takes the inference path sequence in the feedback data records as input and performs pattern mining on the node jump combinations that frequently occur in multiple cross-domain inferences: when a pair of semantic objects is determined by the large language model to have a business influence relationship in multiple inferences, but there is no cross-domain association directly connecting the pair of semantic objects in the global factory knowledge graph, the large language model marks the pair of semantic objects as a candidate new cross-domain association pair; after the candidate new cross-domain association pair passes the business rule verification (such as verifying whether the two semantic objects belong to different business domains, whether there is business logic rationality, etc.), a new cross-domain association suggestion is generated. The new cross-domain relationship proposal is represented in the form of a triple, which includes a first semantic object, a proposed relationship type, and a second semantic object. The relationship type is automatically determined by the large language model based on the business logic nature (causal, temporal, or numerical constraints) between the two semantic objects.

[0077] Furthermore, the semantic object instantiation and attribute expansion steps include: when, during cross-domain reasoning, it is discovered that the factory business data in the feedback data record contains new business concepts or new attribute dimensions that are not yet defined in the global factory knowledge graph, the agent executing the determined business domain calls the same large language model to perform semantic type identification on the new business concept, determining whether it belongs to a new instance of an existing semantic object or requires the addition of a new semantic object type. If it belongs to a new instance of an existing semantic object, a new semantic object instance node is added for the semantic object type in the global factory knowledge graph, and the identification information of the semantic object instance and its distinguishing attributes from existing instances are recorded in the global factory knowledge graph; if it belongs to a completely new business concept, the large language model determines its business domain based on its business semantics, creates a new semantic object type in the corresponding business domain, creates the first semantic object instance node of the semantic object type, and establishes an initial cross-domain association between the new semantic object type and existing semantic objects.

[0078] Furthermore, the confidence assessment and manual verification steps include: for new cross-domain relationship suggestions generated in the new cross-domain relationship discovery step and semantic object instantiation suggestions generated in the semantic object instantiation and attribute expansion steps, the task understanding and scheduling agent calculates a confidence score for each suggestion. The confidence score is calculated based on: the number of feedback data records on which the suggestion is based (higher frequency indicates higher confidence), the time span of the business data involved in the suggestion (longer time span indicates higher confidence), and the semantic consistency between the suggestion and existing structures in the global factory knowledge graph (higher confidence when there is no conflict with existing cross-domain relationships). The specific calculation formula for the confidence score can use a weighted summation method, with each weight configured by the system administrator according to the actual needs of the factory. When the confidence score exceeds a preset first confidence threshold, the suggestion automatically takes effect and is updated to the global factory knowledge graph. When the confidence score is lower than the preset first confidence threshold but higher than the preset second confidence threshold, the suggestion is marked as pending confirmation. The task understanding and scheduling agent generates a knowledge graph update suggestion report and pushes it to the management terminal, awaiting confirmation from management personnel before taking effect. When the confidence score is lower than the preset second confidence threshold, the suggestion is marked as a low-confidence suggestion and temporarily ineffective, stored in a pending review queue for periodic review. The first confidence threshold is greater than the second confidence threshold; the specific value can be configured by the system administrator based on the factory's tolerance for knowledge graph update risks.

[0079] Furthermore, the consistency maintenance steps for this knowledge graph include: after a new cross-domain relationship or a new semantic object instance takes effect, the task understanding and scheduling agent triggers a consistency verification process. Consistency verification includes: checking whether the newly added cross-domain relationship causes a circular dependency in the global factory knowledge graph (e.g., a closed loop where A leads to B, B leads to C, and C leads to A). If a circular dependency exists, a conflict is marked and the update is rolled back; checking whether the newly added semantic object instance conflicts with an existing semantic object instance of the same semantic object type. If so, an instance merging and deduplication process is triggered; and checking whether the newly added semantic object type conflicts with existing business domain classifications. If so, a domain reclassification process is triggered. Once the update passes the consistency verification, it officially takes effect, and the updated global factory knowledge graph is available for subsequent cross-domain reasoning.

[0080] Therefore, this solution, by collecting execution feedback from each cross-domain inference, enables the large language model to automatically discover undefined cross-domain association patterns in the global factory knowledge graph from practical operational experience, and solidifies frequently occurring association patterns into new cross-domain relationships, achieving a qualitative leap in the global factory knowledge graph from one-time construction to continuous evolution. Furthermore, this solution uses a confidence scoring mechanism to automatically activate high-confidence updates, requiring only manual intervention in the confirmation of low-confidence suggestions, significantly reducing manual maintenance costs, while ensuring the global factory knowledge graph can promptly reflect the latest patterns in business operations. Moreover, this step upgrades the entire method from a one-way task information input to cross-system execution instruction issuance to a closed-loop system with self-learning capabilities. The execution result of each cross-domain inference feeds back into the global factory knowledge graph, making it increasingly rich and accurate with each run, continuously improving the accuracy and coverage of subsequent cross-domain inference, ultimately achieving autonomous evolution of the system's overall intelligence level.

[0081] It should be noted that the multi-agent factory collaborative management method of this application can be deployed as a software system running on factory computer equipment or edge computing devices. This system is not a standalone software requiring manual operation by personnel in each position, but rather acts as an intermediate scheduling and inference layer. Through the application programming interfaces or database query interfaces provided by various factory business information systems, it interacts with existing systems such as manufacturing execution systems, warehouse management systems, quality management systems, and enterprise resource planning systems, thereby achieving cross-domain automated collaboration in the background.

[0082] The system's operation and user experience differ depending on the user's access level. Factory management, such as the plant manager or operations director, can directly input high-level commands in natural language via industrial tablets, control center screens, or authorized mobile terminals. For example, when inputting "Analyze the reasons for the welding workshop's production cost exceeding the standard this month" or "Handle the impact of a certain type of chip shortage on production scheduling," the system automatically performs semantic disambiguation, scheduling execution, and cross-domain reasoning upon receiving the task information, and pushes the generated decision report back to the management terminal for review and confirmation. When the system-pushed decision report involves cross-departmental approval or strategic decisions, management only needs to click the "Agree to Adjust" button on the management terminal, and the system automatically converts the reasoning results into cross-system execution instructions and sends them to the corresponding factory business information systems, eliminating the need for management to manually log into each business system for item-by-item operations. Finance personnel typically do not need to actively interact with the system in their daily work. When cross-domain reasoning involves financial decisions such as budget approval, cost accounting, or fund freezing, the system automatically generates a decision report, which is then pushed to the management terminal of the finance manager. After reviewing the impact analysis and recommended solutions in the report, the finance personnel confirm online, and the system automatically issues the budget adjustment instruction to the enterprise resource planning system for execution. For daily operational deviations that only affect a single workstation and do not require budget or personnel adjustments, the system can directly generate cross-system execution instructions and issue them automatically without the intervention of finance personnel. Finance personnel only conduct post-event supervision when periodically reviewing the automatic execution records pushed by the system. Production line workers and front-line operators generally do not need to interact directly with this system. Workers record production data or report abnormalities in the existing way on the factory business information system corresponding to their respective positions. This system obtains these factory business data from various business information systems in real time through the connected business domain execution agents, automatically identifies abnormal events, and triggers cross-domain reasoning. The entire collaborative process is completed in the background without changing the operating habits of front-line personnel. Department managers, such as heads of production, quality, or supply chain departments, may receive to-do items pushed by the system in their daily work. For example, after the system detects continuous weld defects, it automatically generates an engineering change request. After the system pushes the request to the R&D manager for confirmation of the modified parameters, it automatically flows to the heads of the quality assurance and production departments for approval. After each node passes the approval online, the system directly sends the updated process parameters to the workshop robot controller and resumes production.

[0083] Taking a material shortage event as an example, a complete collaborative management process is as follows. During real-time monitoring, the supply chain domain execution agent detects from the warehouse management system that the inventory quantity of a key chip is lower than a preset safety stock threshold and automatically reports this event information to the task understanding and scheduling agent. The task understanding and scheduling agent invokes the same large language model defined in step S120 to perform semantic disambiguation on the "chip shortage" event, mapping it to a material semantic object instance in the material inventory domain of the global factory knowledge graph. It then determines the chip's position in the global factory knowledge graph and schedules the supply chain domain execution agent connected to the warehouse management system, the production domain execution agent connected to the manufacturing execution system, and the financial domain execution agent connected to the enterprise resource planning system to participate in the collaboration. Each business domain's execution agent retrieves factory business data from the connected factory business information system, including current work order scheduling, production line capacity load, order delivery cycle, material procurement price, and penalty rate. Under the path constraints of cross-domain relationships defined in the global factory knowledge graph, the large language model traverses the affected target business domains hop-by-hop along the path: material shortages leading to work order delays, work order delays leading to production line downtime, production line downtime leading to order delays, and order delays triggering penalty risks. Simultaneously, it calculates the quantitative impact of each step based on numerical constraint relationships. Finally, it integrates the business data from each target business domain to generate a reasoning result including the scope of impact, estimated financial losses, and recommended solutions. Since this reasoning result involves emergency procurement fund applications and cross-departmental production scheduling adjustments, falling under the category of decisions requiring manual confirmation, the system automatically generates a structured decision report from the reasoning result and pushes it to the management terminals of the finance manager and operations director. After two managers review and confirm the data online, the system sends budget adjustment instructions to the Enterprise Resource Planning (ERP) system, expedited purchase order instructions to the Supply Chain Management (SLM) system, and adjusted production scheduling priority instructions to the Manufacturing Execution System (MES) system. These three instructions are generated and executed independently within their respective target system's interface format. Thus, personnel with different permissions only need to confirm or reject decisions based on system-pushed reports or issue instructions in natural language. The system automatically completes cross-domain data acquisition, semantic association, multi-step reasoning, and multi-system instruction issuance, achieving automated collaborative management across various business areas of the factory based on unified semantics.

[0084] In summary, by utilizing the above technical solution, this application has the following advantages:

[0085] First, this application constructs a global factory knowledge graph that defines semantic objects in multiple business domains and their cross-domain relationships, and deploys a multi-agent system that includes task understanding and scheduling agents and execution agents in multiple business domains. This enables the breaking down of data silos between various business information systems within the factory at the semantic level. During runtime, the task understanding and scheduling agent receives task information in natural language form, performs semantic disambiguation based on the global factory knowledge graph, maps the natural language expression in the task information to the corresponding semantic object instance and determines its position in the global factory knowledge graph, thereby accurately scheduling the corresponding business domain execution agent. After the scheduled business domain execution agent obtains factory business data from the connected factory business information system, the large language model traverses the affected target business domains hop by hop along the cross-domain association relationship under the path constraint of the cross-domain association relationship, integrates the business data of each target business domain to generate inference results, and performs a collaborative operation based on the inference results, including at least one of outputting a decision result and issuing cross-system execution instructions to the corresponding factory business information system. This realizes automated cross-domain collaboration between multiple business domains within the factory based on unified semantics, enabling timely and accurate linkage responses to global events without manual cross-departmental coordination, significantly reducing response delays and decision biases.

[0086] Furthermore, this application also generates an anomaly propagation link diagram by means of an anomaly propagation link generation step. When there is anomaly data in the factory business data, the large language model can trace the upstream impact source and downstream impact range of the anomaly data along the cross-domain relationship to generate an anomaly propagation link diagram containing the complete propagation path, which intuitively shows the transmission and diffusion process of the anomaly event between various business areas.

[0087] Furthermore, this application also utilizes the input task information, business domain execution agent combination, inference path and execution time in the historical execution record to calculate the semantic similarity between the new task and the historical task to select the initial scheduling scheme. During the execution process, the initial scheduling scheme is dynamically modified according to the state of semantic objects in the global factory knowledge graph, thereby continuously optimizing the agent scheduling efficiency and improving the system response speed.

[0088] Furthermore, this application also utilizes the dynamic self-evolution step of the global factory knowledge graph to automatically discover undefined cross-domain association patterns from the execution feedback of each cross-domain reasoning. After confidence assessment and consistency verification, these patterns are solidified into new cross-domain associations, realizing a qualitative change in the global factory knowledge graph from one-time construction to continuous evolution. This forms a positive closed loop from reasoning to execution to feedback to evolution to better reasoning, enabling the overall intelligence level of the system to autonomously evolve with the increase in the number of runs.

[0089] It should be understood that the above-described multi-agent factory collaborative management method is merely exemplary, and those skilled in the art can make various modifications based on the above method, and the modified solutions also fall within the protection scope of this application.

[0090] This application also provides a storage medium storing a computer program that, when executed by a processor, implements the steps of the multi-agent factory collaborative management method described above.

[0091] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the multi-agent factory collaborative management method described above.

[0092] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0093] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions.

[0094] It should be noted that any reference numerals placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In claims that enumerate several means, several of these means may be embodied by the same hardware. The use of the terms first, second, third, etc., is merely for convenience of expression and does not indicate any order. These terms can be understood as part of the component names.

[0095] Furthermore, it should be noted that in the description of this specification, the terms "one embodiment," "some embodiments," "embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0096] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the claims should be interpreted to include both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0097] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, then this invention should also include these modifications and variations.

Claims

1. A multi-agent factory collaborative management method, characterized in that, include: Construct a global factory knowledge graph; wherein, the global factory knowledge graph is used to define semantic objects of multiple business domains within the factory, and also defines cross-domain association relationships between semantic objects of different business domains; Deploy a multi-agent system; wherein the multi-agent system includes a task understanding and scheduling agent and multiple business domain execution agents, and each business domain execution agent is connected to a different factory business information system; The task understanding and scheduling agent receives input task information and performs semantic disambiguation on the task information according to the global factory knowledge graph to map the natural language expression in the task information to the corresponding semantic object instance and determine the position of the semantic object instance in the global factory knowledge graph, and determines at least one business domain execution agent to execute the task information according to the position. The intelligent agent, acting within the defined business domain, acquires factory business data from the connected factory business information system. Under the path constraints of the cross-domain relationships defined in the global factory knowledge graph by the large language model, it performs cross-domain reasoning using the factory business data as input. This cross-domain reasoning includes traversing the affected target business domains hop-by-hop along the cross-domain relationships, generating a reasoning result by integrating the business data from each target business domain, and performing collaborative operations based on the reasoning result. The collaborative operations include at least one of outputting a decision result and issuing cross-system execution instructions to the corresponding factory business information system.

2. The method according to claim 1, characterized in that, The step of performing semantic disambiguation on the task information based on the global factory knowledge graph, to map the natural language expressions in the task information to corresponding semantic object instances and determine the position of the semantic object instances in the global factory knowledge graph, specifically includes: Using a pre-defined factory domain terminology dictionary and thesaurus, the natural language expressions in the task information are normalized, and the normalized terms are matched with semantic objects in the global factory knowledge graph to determine candidate semantic objects associated with the task information. Based on the context of the task information or the current system time, the referential words or time expressions contained in the task information are parsed to determine the semantic object instance that the task information actually points to and its position in the global factory knowledge graph from the candidate semantic objects.

3. The method according to claim 1, characterized in that, The cross-domain association relationship includes at least one of causal association relationship, temporal association relationship, and numerical constraint association relationship; The cross-domain association is stored in the global factory knowledge graph in the form of triples. Each triple consists of two semantic objects belonging to two different business domains and a relation type connecting the two semantic objects. The relation type is used to indicate the direction of the path traversal of the large language model along the cross-domain association during cross-domain reasoning.

4. The method according to claim 3, characterized in that, The step-by-step traversal of the affected target business domains along the cross-domain association specifically includes: Starting from the position of the semantic object instance in the global factory knowledge graph, and following the path traversal direction indicated by the relation type in the triple, the adjacent semantic objects are visited sequentially along the cross-domain association relationship corresponding to the relation type, starting from the starting node. When a neighboring semantic object is accessed, the target business domain to which the semantic object belongs is determined to be affected by the task information based on the business data of the semantic object and the relationship type of the cross-domain association connecting the semantic object. If it is determined that the semantic object is affected, then the business data of the semantic object is included in the step of generating inference results by integrating the business data of each target business domain; The traversal ends once all affected semantic objects have been visited.

5. The method according to claim 1, characterized in that, The multiple business domain execution agents include at least a supply chain domain execution agent, a production domain execution agent, and a finance domain execution agent; the supply chain domain execution agent is connected as the supply chain management system of the factory business information system, the production domain execution agent is connected as the manufacturing execution system of the factory business information system, and the finance domain execution agent is connected as the enterprise resource planning system of the factory business information system. The cross-system execution instructions are structured instructions generated for the supply chain management system, the manufacturing execution system, and the enterprise resource planning system, respectively, so that the corresponding factory business information system can identify and execute them.

6. The method according to claim 1, characterized in that, The collaborative operation specifically includes: When the reasoning result involves cross-departmental approval or strategic decision-making, the reasoning result is generated as a decision report and pushed to the management terminal, and a confirmation instruction is received from the management terminal; after receiving the confirmation instruction, the reasoning result is converted into the cross-system execution instruction and sent to the corresponding factory business information system.

7. The method according to claim 1, characterized in that, The cross-domain reasoning also includes an anomaly propagation link generation step, and the anomaly propagation link generation step includes: When abnormal data exists in the factory business data, the large language model traces the upstream source and downstream scope of the abnormal data along the cross-domain association defined in the global factory knowledge graph, and generates an abnormal propagation link graph. The abnormal propagation link graph contains the complete propagation path of the abnormal data from the starting node to the ending node; the abnormal propagation link graph is output as part of the reasoning result.

8. The method according to claim 1, characterized in that, It also includes a feedback learning step, and the feedback learning step includes: Record the input task information for each cross-domain reasoning, the combination of the determined business domain execution agents, the reasoning path of the large language model for cross-domain reasoning, the execution result of the collaborative operation, and the execution time to form a historical execution record; When new task information is received, the task understanding and scheduling agent calculates the semantic similarity between the new task information and each input task information in the historical execution record, selects the combination of the business domain execution agents corresponding to the historical execution record with the highest semantic similarity as the initial scheduling scheme, and dynamically corrects the initial scheduling scheme according to the updated state of the semantic objects in the global factory knowledge graph during the execution process.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-agent factory collaborative management method as described in any one of claims 1 to 8.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the multi-agent factory collaborative management method as described in any one of claims 1 to 8.

Images