Multi-agent communication and collaborative optimization method based on FIPA-ACL protocol

Abstract

The invention relates to the technical field of artificial intelligence, and discloses a multi-agent communication and collaborative optimization method based on an FIPA-ACL protocol, and the method comprises the following steps: S1, receiving an FIPA-ACL format communication message from a sender agent, analyzing the communication message, and constructing a semantic transaction object; s2, based on a pre-constructed semantic ontology mapping rule base, analyzing intention and content in the semantic transaction object, matching a corresponding target platform behavior under a current context condition, and generating a structured behavior description object; and S3, packaging the target platform behavior into a general behavior packaging protocol format, constructing a behavior task structural body, and constructing a behavior execution graph according to the behavior dependency relationship. According to the method, the most adaptive target platform behavior can be automatically selected in the agent communication process by introducing a context-driven semantic reasoning mechanism, so that the flexibility and accuracy of behavior decision making are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of artificial intelligence, and in particular to a multi-agent communication and collaborative optimization method based on FIPA-ACL protocol. BACKGROUND

[0002] In the traditional multi-agent communication system, the behavior decision of the agent is usually configured by using a static mapping rule table. Specifically, the mapping relationship between the communication intention and the platform behavior is predefined during the system development stage, and the agent directly selects the corresponding action according to the received communication intention by table lookup at runtime. This static rule mechanism simplifies the initial design and implementation, but has obvious limitations in actual application.

[0003] Firstly, the static rule table cannot fully perceive the environmental changes. The behavior selection in the existing system is mostly based on the field information of the communication message itself, lacking the perception and analysis of the runtime context environment, such as platform load state, resource availability, task priority, dependency condition and other dynamic parameters. This leads to the fact that the agent still follows the pre-hardcoded decision logic in complex situations such as system load fluctuation, resource dynamic change or task scheduling conflict, lacking real-time adjustment capability, and the behavior selection is easy to mismatch, even causing execution failure or resource conflict problems.

[0004] Secondly, the maintenance cost of the static rule is high and prone to errors. With the expansion of the system scale and the increase of the number of agents, the mapping relationship between the communication intention and the platform behavior becomes more and more complex. In order to adapt to new scenarios, the rule table needs to be continuously expanded and adjusted manually, and the modification process is tedious and prone to logical vulnerabilities. At the same time, when a new environment or a new platform is connected, a large-scale reconstruction of the rule library is often required, lacking the flexibility of expansion mechanism, which restricts the adaptability and evolution efficiency of the system. SUMMARY

[0005] In order to make up for the above shortcomings, the present application provides a multi-agent communication and collaborative optimization method based on FIPA-ACL protocol, aiming at improving the problems of behavior decision relying on static rules, rigid response and difficulty in adapting to environmental dynamic changes in the existing multi-agent system.

[0006] In the first aspect, the present application provides a technical scheme as follows: a multi-agent communication and collaborative optimization method based on FIPA-ACL protocol, comprising the following steps: S1, receiving a FIPA-ACL format communication message from a sender agent, and parsing and constructing a semantic transaction object for the communication message; S2, based on a pre-constructed semantic ontology mapping rule library, parsing the intention and content in the semantic transaction object, and matching the corresponding target platform behavior under the current context condition to generate a structured behavior description object; S3, encapsulate the target platform behavior as a general behavior package protocol format, build a behavior task structure, and build a behavior execution graph according to the behavior dependency relationship; S4, send the encapsulated behavior task to the corresponding platform for execution; S5, extract platform behavior event information through the behavior listener deployed on each platform; S6, based on the captured behavior event information, build structured communication feedback content, and push it to the sender agent in the form of a feedback message format consistent with the FIPA-ACL semantic specification, complete the communication closed loop and transaction scheduling state update.

[0007] Preferably, the sub-step of analyzing and building a semantic transaction object in S1 is: S11, analyze the field data of the FIPA-ACL communication message, including the communication intent field, semantic content field, communication ontology field, semantic language field, sender identification field and receiver identification field; S12, take the communication intent field and semantic content field as input data, and structure the data through a semantic analysis function to generate a data structure object containing communication intent, task semantic content, semantic ontology, platform behavior mapping indication, context environment parameter, survival time window and scheduling priority, and form a semantic transaction object; S13, write the semantic transaction object as structured output data into a semantic transaction cache pool for subsequent behavior mapping and scheduling calls.

[0008] Preferably, the semantic ontology mapping rule library is built in an ontology structure diagram modeling manner, each semantic mapping rule includes an input semantic expression, a context condition and a platform behavior output expression, and an optimal behavior mapping path is dynamically selected through a context reasoning mechanism.

[0009] Preferably, the context reasoning mechanism is based on the semantic transaction object and the current system context environment to derive the optimal behavior mapping path, including: S21, extract a set of candidate platform behaviors matching the semantic intent; S22, extract platform state data, resource occupation information, behavior dependency state, transaction priority and time limit parameters from the system context environment to build a context vector; S23, input the context vector into a multi-dimensional scoring model to calculate the fitness score of each candidate platform behavior; S24, sort the candidate behavior set based on the fitness score, and select the highest scorer as the target behavior output.

[0010] Preferably, the behavior task structure in S3 comprises a behavior unique identifier, a behavior type, an execution target, an execution parameter, an expected start time, a timeout time, dependent behavior information, and a rollback strategy, and describes the sequential or concurrent dependency relationship between multiple behaviors through a behavior execution graph structure.

[0011] Preferably, the behavior listener is used to listen to a platform event bus or service call feedback, and the behavior event information extracted by the listener comprises a behavior identifier, an execution state, a timestamp, a return value, and a behavior triggering context.

[0012] Preferably, the S6 structured communication feedback content generation process comprises: S61, based on each behavior event object, a pre-defined message template library is called to construct a corresponding single feedback message; S62, when multiple behavior event objects corresponding to a semantic transaction are captured within a same time window, event aggregation processing is performed to generate a combined feedback message comprising multiple behavior states and execution results, and the combined feedback message is returned to a communication link in a batch manner.

[0013] In a second aspect, the present application provides the following technical solution: a multi-agent communication and collaborative optimization system based on a FIPA-ACL protocol, the system comprising: a communication semantic analysis module, configured to receive and analyze a FIPA-ACL format communication message, and to construct a semantic transaction object; a semantic mapping engine module, configured to convert the semantic transaction object into a target platform behavior based on an ontology mapping rule; a behavior packaging module, configured to package the target platform behavior into a structured behavior task; a platform adapter module, configured to schedule and send the behavior task to a target platform for execution; a behavior monitoring agent module, configured to capture feedback events in a platform behavior execution process and to generate standardized event objects; an ACL message generation module, configured to construct a FIPA-ACL format feedback message based on the behavior event objects and to send the feedback message to a communication link of a sender agent.

[0014] In a third aspect, the present application provides the following technical solution: a computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to implement the above-mentioned multi-agent communication and collaborative optimization method based on a FIPA-ACL protocol.

[0015] In a fourth aspect, the present application provides a readable storage medium, wherein the readable storage medium stores a computer program, and the computer program is executed by a processor to implement the multi-agent communication and collaborative optimization method based on the FIPA-ACL protocol.

[0016] The present application has the following beneficial effects: 1. In the present application, by introducing a context-driven semantic reasoning mechanism, the most suitable target platform behavior can be automatically selected in the process of agent communication. Without relying on static rule tables, it can dynamically adapt to environmental changes. Compared with the fixed mapping rule method used in traditional multi-agent, the flexibility and accuracy of behavior decision-making are improved, and the pain points of "rigid response" and "inability to adjust in real time" of the original system are solved.

[0017] 2. In the present application, by using the encapsulation and dependency scheduling strategy of behavior execution graph, multiple platform behaviors can be triggered in sequence, concurrently or dependently on demand. The logical relationship between behaviors is explicitly managed, and the scheduling is clear. Unlike the "single behavior serial call" in the prior art, the present application can automatically organize complex behavior flow, avoiding the problems of artificial nesting and bloated control logic. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 The method flowchart of the multi-agent communication and collaborative optimization method based on the FIPA-ACL protocol proposed by the present application; Figure 2 The S1 flowchart of the multi-agent communication and collaborative optimization method based on the FIPA-ACL protocol proposed by the present application; Figure 3 The behavior execution graph of the multi-agent communication and collaborative optimization method based on the FIPA-ACL protocol proposed by the present application; Figure 4 The S2 flowchart of the multi-agent communication and collaborative optimization method based on the FIPA-ACL protocol proposed by the present application; Figure 5 The S3 flowchart of the multi-agent communication and collaborative optimization method based on the FIPA-ACL protocol proposed by the present application; Figure 6 The S6 flowchart of the multi-agent communication and collaborative optimization method based on the FIPA-ACL protocol proposed by the present application; Figure 7 The system architecture diagram of the multi-agent communication and collaborative optimization system based on the FIPA-ACL protocol proposed by the present application; Figure 8 The data flow diagram of the multi-agent communication and collaborative optimization system based on the FIPA-ACL protocol proposed by the present application; Figure 9 A template library schematic diagram of the multi-agent communication and collaborative optimization system based on the FIPA-ACL protocol provided by the present application; Figure 10 A computer framework schematic diagram of the multi-agent communication and collaborative optimization system based on the FIPA-ACL protocol provided by the present application. DETAILED DESCRIPTION

[0019] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0020] Embodiment one Reference Figures 1-6 In the first embodiment of the present application, the present application provides a multi-agent communication and collaborative optimization method based on the FIPA-ACL protocol, including the following steps: S1, receiving a FIPA-ACL format communication message from a sender agent, and parsing and constructing a semantic transaction object for the communication message; the sub-step of parsing and constructing a semantic transaction object for the communication message is: S11, parsing the field data of the FIPA-ACL communication message, the field data including a communication intention field, a semantic content field, a communication ontology field, a semantic language field, a sender identification field and a receiver identification field; S12, taking the communication intention field and the semantic content field as input data, and performing structured parsing via a semantic parsing function to generate a data structure object containing a communication intention, a task semantic content, a belonging semantic ontology, a platform behavior mapping indication, a context environment parameter, a survival time window and a scheduling priority, thereby constituting a semantic transaction object; S13, writing the semantic transaction object as structured output data into a semantic transaction cache pool, for subsequent behavior mapping and scheduling calling.

[0021] Specifically, after receiving a communication message in FIPA-ACL format, the system parses its fields through the built-in communication unpacking module. The communication message usually contains multiple key fields, such as performative (communication intent), content (semantic content), ontology (communication ontology), language (semantic language), and the identification fields of the communication parties, sender and receiver. In the specific implementation, the field data structure is represented by JSON or XML packaging format, and the system uses a unified field parser to extract it. The field parser aligns the ACL messages in different semantic languages based on regular matching and structural pattern recognition techniques.

[0022] { "performative": "request", "sender": "agent_01", "receiver": "agent_02", "ontology": "task_scheduling", "language": "RDF", "content": "(assign-task :taskID T123 :deadline 2025-05-15)" } The system extracts the performative as "request intent" and the content part is semantically parsed using a custom syntax rule. The syntax rule is implemented through a "semantic parsing function" using the ANTLR syntax tree constructor combined with a self-developed rule engine to disassemble (assign-task :taskID T123 :deadline 2025-05-15) into structured fields and label task intent, parameter key-value, time constraints, etc.

[0023] The next core process is to generate a semantic transaction object. The system inputs the communication intent and semantic content fields into the semantic parsing function, which annotates the keywords and parameter structures at the ontology level according to the registered communication ontology. The semantic transaction object not only contains the literal task information, but also embeds mapping instructions related to platform execution behavior. For example, if the communication ontology points to "task_scheduling" and the target platform is a manufacturing execution system (MES), the generated transaction object will contain implicit semantic labels such as "behavior target type: task dispatching", "platform interface type: REST-POST", "dependent behavior: resource verification", etc.

[0024] The internal structure of a semantic transaction object usually contains the following fields: { "intent": "assign-task", "taskID": "T123", "deadline": "2025-05-15", "ontology": "task_scheduling", "platform_behavior_map": "MES.taskDispatch", "context_env": { "agent_role": "scheduler", "load_factor": 0.85 }, "ttl": 300, "priority": "high" } The above transaction object is not only used for behavior execution, but also provides decision basis for scheduling scoring module. In particular, the context environment field (context_env) contains parameters such as sender role, current platform state, system load, etc., which are used as inference input in the subsequent behavior mapping stage.

[0025] The constructed semantic transaction object is written into the system's "semantic transaction cache pool", which is usually a high-performance transaction queue based on Redis or in-memory KV database, supporting concurrent read and write and priority scheduling mechanism. Each transaction object is attached with a timestamp and a transaction ID, and the subsequent behavior mapping module polls the cache pool to take out the tasks to be processed according to priority.

[0026] S2, based on the pre-constructed semantic ontology mapping rule library, the intent and content in the semantic transaction object are parsed, and the corresponding target platform behavior is matched under the current context condition, and a structured behavior description object is generated; the semantic ontology mapping rule library is constructed by ontology structure diagram modeling, each semantic mapping rule includes input semantic expression, context condition and platform behavior output expression, and the optimal behavior mapping path is dynamically selected through context reasoning mechanism.

[0027] The process of context reasoning mechanism based on semantic transaction object and current system context environment to derive the optimal behavior mapping path includes: S21, extract a set of candidate platform behaviors matching the semantic intent; S22. Extract platform status data, resource usage information, behavior dependency status, transaction priority and time limit parameters from the system context environment, and construct a context vector; S23. Input the context vector into the multidimensional scoring model and calculate the fitness score for each candidate platform behavior. S24. Sort the candidate behavior set based on fitness scores and select the one with the highest score as the target behavior output.

[0028] Specifically, after constructing the semantic transaction object, the system initiates a semantic mapping phase to translate abstract task intents into concrete, executable target platform behaviors. This mapping is not a static matching process, but rather a dynamic inference based on the context to ensure that behavior execution optimally matches the current system state.

[0029] This system pre-builds a semantic ontology mapping rule base to support the conversion logic from semantic transactions to platform behaviors. This rule base is not simply a list of rules, but is built based on an "ontology structure graph." We organize these mapping rules using a graph database (such as Neo4j), where each node represents a semantic intent, context label, or platform behavior, and edges represent mapping logic and conditional constraints. This graph structure facilitates fast querying, dynamic updates, and context path retrieval.

[0030] Each semantic mapping rule generally consists of three components: Enter an expression, such as "assign-task" or "query-status"; Contextual conditions, such as "agent_role=scheduler" and "load<0.8"; Platform behavior expressions, such as "MES.taskDispatch" and "WMS.orderReserve".

[0031] After the system reads a semantic transaction object, it first extracts the core intent from it. For example, if the transaction intent is "assign-task", it enters the branch in the ontology graph where the intent node is "assign-task". The system then uses intent expansion logic to retrieve all related candidate platform behavior paths. For example, for manufacturing industry applications, the following set of candidate behaviors might appear: [ "MES.taskDispatch", "SCADA.writeTag", "ERP.pushJobEntry" ] After the candidate behaviors are extracted, the system starts the context reasoning. A context vector is constructed, containing the current system environment information, such as platform status, resource occupation, behavior dependency status, task priority, etc. The platform status is read directly through the interface (such as through REST or MQTT), the resource information comes from the resource scheduling module, and the behavior dependency is calculated from the behavior execution graph.

[0032] For example, the constructed context vector is: { "platform_load": 0.72, "resource_available": true, "dependent_behavior_done": true, "priority": "high", "deadline": "2025-05-15T18:00:00Z" } Subsequently, the system inputs the context vector into a scoring model. The scoring model is a self-defined lightweight multi-factor scoring mechanism. Each candidate behavior is calculated for fitness according to different dimensions. The dimensions can include: expected response time, current load adaptation degree, whether the execution condition is met, resource readiness, behavior history success rate, etc. The scoring model can be based on linear weighting of weights, or can be trained based on a simple neural network or logistic regressor.

[0033] The scoring results are as follows: { "MES.taskDispatch": 0.87, "SCADA.writeTag": 0.65, "ERP.pushJobEntry": 0.52 } The system sorts all candidate behaviors in descending order of score, and selects the highest scoring one as the final target behavior. At this time, the semantic transaction object will be supplemented with the behavior mapping label, for example: "mapped_behavior": "MES.taskDispatch" The biggest advantage of this mechanism is its dynamic nature. Even if different platform behaviors have the same semantic intent, the system can determine which behavior is currently more "appropriate" based on the environment, rather than making a rigid call. For example, for the same task intent, the system may choose WMS preprocessing when the system is under high load, and may choose MES to issue directly when the system is under low load, thereby achieving more robust scheduling logic.

[0034] S3, encapsulate the target platform behavior into a unified behavior wrapper protocol format, construct a behavior task structure, and construct a behavior execution graph according to the behavior dependency relationship; The behavior task structure in S3 includes a behavior unique identifier, a behavior type, an execution target, an execution parameter, an expected start time, a timeout time, dependency behavior information, and a rollback policy, and describes the sequential or concurrent dependency relationship between multiple behaviors through a behavior execution graph structure.

[0035] Specifically, after the semantic transaction is mapped to a specific platform behavior, the system needs to further encapsulate the behavior into a unified executable task structure to support subsequent control operations such as scheduling, dependency management, and error recovery. The present application introduces a general behavior wrapper protocol format (Unified Behavior Wrapper Protocol, UBWP) for standardizing and structuring target platform behaviors.

[0036] The wrapping process starts with a behavior parameter template. Platform behaviors usually have interface differences and parameter naming differences, for example, MES systems use jobId, while ERP systems may use orderCode. To solve this compatibility problem, the system designs a layer of behavior abstraction template, and all platform behaviors are mapped to a unified parameter structure through the template, and are uniformly encapsulated into a task structure.

[0037] The internal fields of the behavior task structure include: { "behavior_id": "bhv_873d1c0f", "behavior_type": "taskDispatch", "target_system": "MES", "parameters": { "jobId": "T123", "deadline": "2025-05-15T18:00:00Z" }, "expected_start_time": "2025-05-15T16:00:00Z", "timeout": 120, "dependencies": ["bhv_659d11a4"], "rollback_policy": { "on_failure": "notify_and_reassign", "timeout_action": "cancel_and_log" } } Among them, behavior_id is an automatically generated globally unique identifier, ensuring that the behavior can be uniquely located throughout its lifecycle; the parameters field stores the specific execution parameters required for the behavior interface call, which is adapted to the platform's standard interface; expected_start_time and timeout provide the basis for time control during behavior scheduling; dependencies is a list of behavior dependency identifiers used to establish the prerequisite relationships between behaviors; and rollback_policy defines the remedial actions when the behavior fails or is abnormal, such as rollback, log marking, and rescheduling.

[0038] To support collaborative execution of multiple behaviors, this invention designs a BehaviorExecution Graph (BEG) structure to model the dependencies, execution order, and concurrency strategies among multiple behavioral tasks. This execution graph is a directed graph structure, where nodes represent behavioral tasks and edges point to dependencies. The system automatically generates this graph based on the logical task decomposition rules in semantic transactions.

[0039] Taking a typical "multi-process collaborative scheduling" task as an example, please refer to the attached behavior execution diagram. Figure 3 : In the appendix Figure 3 In the structure, behavior B depends on behavior A, while behaviors C and D concurrently depend on B. The behavior graph structure implements various control logics such as serial, concurrent, and condition-triggered operations through topology sorting and state-aware driving scheduling modules. After each behavior is executed, the system records its execution status (success, failure, timeout, rollback, etc.) and triggers status checks on dependent behaviors.

[0040] The behavior execution graph is not only the foundation of scheduling and execution, but also a key data source for monitoring and visualization. The graph structure is serialized using JSON Schema and stored in the scheduling center. The task flow structure, execution path, and abnormal nodes are displayed through a visualization interface, supporting real-time tracking and backtracking analysis during task execution.

[0041] Furthermore, the system supports a rollback strategy and a dependency update linkage mechanism. Once a certain behavior triggers a rollback strategy, all its downstream dependent behaviors will enter a frozen state, awaiting manual handling or triggering of the rollback chain. For example, if task dispatch fails, the notify_and_reassign strategy can be automatically invoked to regenerate scheduling suggestions and rebuild the behavior graph, achieving task self-recovery.

[0042] S4, send the encapsulated behavior task to the corresponding platform for execution; S5, extract platform behavior event information through the behavior listener deployed on each platform; the behavior listener is used for listening to platform event bus or service call feedback, and the behavior event information extracted by the listener includes behavior identification, execution state, timestamp, return value and behavior triggering context.

[0043] Specifically, after completing the structured encapsulation of the behavior task and the construction of the execution graph, the system will start the actual behavior task scheduling according to the topological order of the behavior execution graph. The scheduling module first obtains the target platform type of the current behavior node, such as MES, WMS, SCADA or ERP, and finds the bound communication protocol and scheduling channel according to the target platform configuration file.

[0044] In the embodiment, platform execution supports multiple modes, including HTTP / REST interface call and message bus (such as MQ, Kafka) mode for sending behavior task requests. The system will dynamically select the adaptive communication mode based on the target_system field in the behavior task structure. The encapsulated task is packaged in a unified JSON format and carries the behavior ID and scheduling parameters, and then sent to the corresponding platform through the scheduling adapter.

[0045] For example, the MES platform usually provides a REST interface, and the system scheduling module constructs the following POST request: POST / api / mes / dispatchTask HTTP / 1.1 Content-Type: application / json { "behavior_id": "bhv_873d1c0f", "jobId": "T123", "deadline": "2024-07-15T18:00:00Z" } The behavior_id field in the request ensures that the platform side response and the task of the main system can correspond one by one. After the interface call is successful, the system records the sending time and enters the behavior state "has been issued", and waits for the platform execution feedback.

[0046] To ensure the behavior execution closed loop tracking, the present application deploys a lightweight behavior listener (Behavior Listener Agent) on each target platform. The listener is used to access the platform event channel, continuously listen to the event stream related to behavior execution, extract and synchronize behavior execution state information. The listener supports the following signal sources: Interface callback (HTTP webhook) of MES / ERP system; Event bus of SCADA system (such as OPC UA, MQTT); Local log or middleware message of custom behavior service.

[0047] The behavior listener extracts each event message into a standard behavior event structure, for example: { "behavior_id": "bhv_873d1c0f", "status": "success", "timestamp": "2025-05-15T16:32:01Z", "return_value": { "machine_id": "MC08", "response_code": 200 }, "context_snapshot": { "platform_load": 0.73, "operator": "auto" } } The listener associates with the main calling system behavior graph through the behavior_id, updates the current behavior node state to "execution success", and triggers the subsequent behavior tasks according to the execution graph logic. If the behavior execution fails, the listener can also capture the abnormal state and error code in real time, providing the basis for triggering rollback strategies or rescheduling for the system.

[0048] S6, based on the captured behavior event information, construct structured communication feedback content, and push it to the sender agent in the format of feedback message conforming to the FIPA-ACL semantic specification, complete the communication closed loop and transaction scheduling state update. The S6 structured communication feedback content generation process includes: S61, based on each behavior event object, call the pre-defined message template library to construct the corresponding single feedback message; S62, when multiple behavior event objects corresponding to a semantic transaction are captured within the same time window, perform event aggregation processing, generate a combined feedback message containing multiple behavior states and execution results, and return it to the communication link in batch mode.

[0049] Specifically, after the platform behavior execution is completed and the relevant event information is captured by the listener, the system will enter the communication closed loop phase, and actively send feedback messages to the agent of the task initiator. The feedback is not only used to inform the task completion, but also an important basis for internal scheduling state update and intention re-planning of the agent. Therefore, the format, content and delivery time of the communication feedback must meet the requirements of semantic consistency, state traceability and communication protocol compliance.

[0050] To this end, the application designs a structured communication feedback generation mechanism to ensure that the feedback information is interpretable, semantically consistent, and fully complies with the message semantic structure defined by FIPA-ACL protocol.

[0051] The specific process is as follows: The system first constructs a feedback message according to each behavior event object reported by the listener, calling a predefined message template library. The template library is organized with intention + state as index dimension, such as Appendix Figure 9 : The template content is encapsulated based on FIPA-ACL message specification, including: performative: inform, failure, confirm, etc. sender: current platform agent receiver: initial transaction initiator agent ontology: keep the original semantic transaction ontology consistent language: default RDF or JSON-LD content: structured execution result data

[0052] For example, if the platform returns behavior execution success, the following ACL feedback message is generated: { "performative": "inform", "sender": "platform_agent_MES", "receiver": "agent_01", "ontology": "task_scheduling", "language": "JSON", "content": { "behavior_id": "bhv_873d1c0f", "status": "success", "return_value": { "machine_id": "MC08", "job_ticket": "TK_2025051501" }, "timestamp": "2025-05-15T16:32:01Z" } } This process is described in S61 for a single feedback message generation mechanism. After triggering each behavior event, a corresponding feedback is generated and immediately pushed to the initiator through the agent communication channel of the system.

[0053] However, considering that a semantic transaction may be associated with multiple platform behaviors (such as "scheduling tasks" that need to perform task dispatching, label printing, resource registration, etc.), if multiple behavior events are completed within a short time window, frequent communication will cause link congestion and increase agent processing overhead. Therefore, the invention further introduces an event aggregation and batch feedback mechanism (corresponding to S62).

[0054] In the present system, the semantic transaction cache pool has event aggregation scheduling capability. When the system detects that multiple behavior tasks under the same transaction ID are completed within a set time window (such as within 10 seconds), it will temporarily suspend the single feedback delivery and instead construct a combined feedback message. The aggregated message contains the following structure: { "performative": "inform", "sender": "platform_agent_gateway", "receiver": "agent_01", "ontology": "task_scheduling", "language": "JSON", "content": { "transaction_id": "txn_20250515_T123", "behavior_results": [ { "behavior_id": "bhv_873d1c0f", "status": "success", "timestamp": "2025-05-15T16:32:01Z"}, { "behavior_id": "bhv_92a35ba7", "status": "timeout", "timestamp": "2025-05-15T16:33:22Z" } ], "summary": { "completed": 1, "failed": 1, "pending": 0 } } } The combination feedback not only reduces the communication frequency, but also facilitates the sender agent to make unified assessment and update of the entire transaction state. The system automatically updates the local transaction state to "closed" or "partially failed" after the feedback is pushed, and triggers the behavior learning, failure rescheduling or rollback action on the agent side.

[0055] Embodiment Two: Referring to Figures 7-9 In the second embodiment of the present application, the present application provides a multi-agent communication and collaborative optimization system based on FIPA-ACL protocol, which comprises: A communication semantic analysis module for receiving and analyzing FIPA-ACL format communication messages and constructing semantic transaction objects; A semantic mapping engine module for converting semantic transaction objects into target platform behaviors based on ontology mapping rules; A behavior packaging module for packaging target platform behaviors into structured behavior tasks; A platform adapter module for scheduling and sending behavior tasks to the target platform for execution; A behavior monitoring agent module for capturing feedback events in the platform behavior execution process and generating standardized event objects; An ACL message generation module for constructing FIPA-ACL format feedback messages based on behavior event objects and sending them to the communication link of the sender agent.

[0056] Specifically, when the system is running, first, the communication semantic analysis module receives the FIPA-ACL format communication message from the external agent, analyzes the semantic intention, operation ontology and content field in the message, constructs a standardized semantic transaction object, and delivers it to the semantic mapping engine module. The mapping engine translates the semantic transaction into a set of behaviors recognizable by the specific target platform according to the built-in ontology mapping rules of the system, and clearly defines the target platform type, execution mode and required parameters corresponding to each behavior. Subsequently, the mapping result is sent to the behavior packaging module, which is responsible for packaging the behavior set into a structured behavior task structure, completing the behavior ID, behavior type, execution target, expected start time, timeout time, parameter field, dependency relationship and rollback strategy, etc. information, while constructing the directed execution graph between behaviors to determine the execution order and concurrency relationship.

[0057] After the behavior task is packaged, it is handed over to the platform adapter module for processing. The adapter completes the parameter mapping and communication packaging of the behavior task according to the target platform interface protocol (such as REST, MQ, WebSocket, etc.), and schedules the task to the specific platform system for execution. During the platform execution behavior, the behavior monitoring agent module deployed on each business system side listens to the platform event bus, API callback or message middleware in real time, captures the execution feedback events related to the behavior task, and extracts the key fields to form a structured behavior event object, which is then reported to the system master module. The behavior event object as a state feedback basis will be delivered to the ACL message generation module, which will construct a communication message conforming to the FIPA-ACL semantic specification according to the event type and behavior intention, support single feedback and batch aggregation feedback two modes, and push the generated feedback message to the original transaction initiator agent, thereby completing the communication closed loop and semantic transaction state update.

[0058] Embodiment three The third embodiment of the present application is based on the same inventive concept. The present application provides a computer readable storage medium storing a computer program, which is executed by a processor to implement the steps of the multi-agent communication and collaborative optimization method based on the FIPA-ACL protocol of the above-mentioned embodiments.

[0059] Embodiment four Reference Figure 10 The fourth embodiment of the present application is based on the same inventive concept. The present application provides a computer, which includes a processor, a memory, and a communication between the processor and the memory. The memory is used to store instructions, and the processor is used to execute the instructions in the memory to implement the multi-agent communication and collaborative optimization method based on the FIPA-ACL protocol of the above-mentioned embodiments.

[0060] It should be understood that portions of the present application can be implemented with hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented with software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, implementation can be with any or a combination of the following technologies, which are all well-known in the art: a discrete logic circuit having logic gates for implementing logic functions upon an application of data signals, an application specific integrated circuit having appropriate combinational logic gates, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0061] Finally, it should be noted that the above-mentioned only is the preferred embodiment of the present application, and is not used to limit the present application, although the present application is described in detail with reference to the foregoing embodiments, for those skilled in the art, the technical solution recorded in the foregoing embodiments can still be modified, or some technical features can be replaced, any modification, equivalent replacement, improvement, etc. within the spirit and principles of the present application, should be included in the protection scope of the present application.

Claims

1. A multi-agent communication and cooperative optimization method based on the FIPA-ACL protocol, characterized in that, Includes the following steps: S1. Receive FIPA-ACL format communication messages from the sending agent, parse the communication messages, and construct semantic transaction objects; S2. Based on the pre-built semantic ontology mapping rule library, parse the intent and content in the semantic transaction object, and match the corresponding target platform behavior under the current context to generate a structured behavior description object; S3. Encapsulate the target platform behavior into a general behavior packaging protocol format, construct a behavior task structure, and construct a behavior execution graph based on behavior dependencies; S4. Send the encapsulated action task to the corresponding platform for execution; S5. Extract behavioral event information from each platform by using behavior listeners deployed on each platform; S6. Based on the captured behavioral event information, construct structured communication feedback content and push it to the sending agent in a feedback message format that conforms to the FIPA-ACL semantic specification, thus completing the communication loop and transaction scheduling status update.

2. The multi-agent communication and cooperative optimization method based on the FIPA-ACL protocol according to claim 1, characterized in that, The sub-step in S1 of parsing the communication message and constructing the semantic transaction object is as follows: S11. Parse the field data of the FIPA-ACL communication message. The field data includes the communication intent field, semantic content field, communication ontology field, semantic language field, sender identifier field, and receiver identifier field. S12. The communication intent field and semantic content field are used as input data and structured parsing is performed through the semantic parsing function to generate a data structure object containing communication intent, task semantic content, belonging semantic ontology, platform behavior mapping indication, context environment parameters, life time window and scheduling priority, which constitutes a semantic transaction object. S13. Write the semantic transaction object as structured output data into the semantic transaction cache pool for subsequent behavior mapping and scheduling calls.

3. The multi-agent communication and cooperative optimization method based on the FIPA-ACL protocol according to claim 1, characterized in that, The semantic ontology mapping rule base is constructed using an ontology structure graph modeling approach. Each semantic mapping rule includes an input semantic expression, context conditions, and platform behavior output expression, and dynamically selects the optimal behavior mapping path through a context reasoning mechanism.

4. The multi-agent communication and cooperative optimization method based on the FIPA-ACL protocol according to claim 3, characterized in that, The context reasoning mechanism, based on semantic transaction objects and the current system context, derives the optimal behavior mapping path through the following process: S21. Extract a set of candidate platform behaviors that match the semantic intent; S22. Extract platform status data, resource usage information, behavior dependency status, transaction priority and time limit parameters from the system context environment, and construct a context vector; S23. Input the context vector into the multidimensional scoring model and calculate the fitness score for each candidate platform behavior; S24. Sort the candidate behavior set based on fitness scores and select the one with the highest score as the target behavior output.

5. The multi-agent communication and cooperative optimization method based on the FIPA-ACL protocol according to claim 1, characterized in that, The behavior task structure in S3 includes a unique behavior identifier, behavior type, execution target, execution parameters, expected start time, timeout, dependent behavior information, and rollback strategy. It also describes the sequential or concurrent dependencies between multiple behaviors through a behavior execution graph structure.

6. The multi-agent communication and cooperative optimization method based on the FIPA-ACL protocol according to claim 1, characterized in that, The behavior listener is used to monitor the platform event bus or service call feedback. The behavior event information extracted by the listener includes behavior identifier, execution status, timestamp, return value and behavior triggering context.

7. The multi-agent communication and cooperative optimization method based on the FIPA-ACL protocol according to claim 1, characterized in that, The S6 structured communication feedback content generation process includes: S61. Based on each behavior event object, call the predefined message template library to construct the corresponding single feedback message; S62. When multiple behavioral event objects corresponding to a semantic transaction are captured within the same time window, event aggregation processing is performed to generate a combined feedback message containing multiple behavioral states and execution results, and the message is returned to the communication link in batches.

8. A multi-agent communication and cooperative optimization system based on the FIPA-ACL protocol, characterized in that, The system used in the multi-agent communication and cooperative optimization method based on the FIPA-ACL protocol according to any one of claims 1-7 includes: The communication semantic parsing module is used to receive and parse communication messages in FIPA-ACL format and construct semantic transaction objects; The semantic mapping engine module is used to convert semantic transaction objects into target platform behaviors based on ontology mapping rules; The behavior packaging module is used to encapsulate the target platform behavior into structured behavior tasks; The platform adapter module is used to schedule the behavioral task and send it to the target platform for execution; The behavior monitoring proxy module is used to capture feedback events during the execution of platform behaviors and generate standardized event objects; The ACL message generation module is used to construct a FIPA-ACL format feedback message based on the behavior event object and send it to the communication link of the sending agent.

9. A computer 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 multi-agent communication and cooperative optimization method based on the FIPA-ACL protocol as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, The readable storage medium stores a computer program, which, when executed by a processor, implements the multi-agent communication and cooperative optimization method based on the FIPA-ACL protocol as described in any one of claims 1 to 7.

Images