Dynamic configuration initialization and version synchronization method and system for multi-agent service

Abstract

The invention relates to the technical field of computers, in particular to a dynamic configuration initialization and version synchronization method and system for multi-agent service, and the method comprises the following steps: obtaining a database update lock, constructing a database migration script dependency relationship, determining a current version of a database mode, upgrading and deploying the database mode, and verifying agent versions. The method has the beneficial effects that a rigorous database updating lock control mechanism, perfect migration script dependency chain verification, agent version management, port availability detection, idempotence and transaction safeguard measures are introduced, so that the processes of database structure upgrading and agent version initialization in a distributed deployment environment can be effectively supported; and the data consistency, the operation stability and the service continuity of the system are ensured.

Description

Technical Field

[0001] This invention relates to the field of computer technology, specifically to a method and system for dynamic configuration initialization and version synchronization of multi-agent services. Background Technology

[0002] In modern information systems, with the widespread application of multi-agent collaborative applications, system architecture is gradually evolving towards distributed and modular architectures. Multi-agent applications need to dynamically load models, initialize configurations, and collaboratively execute complex tasks based on different business scenarios. As the number of agents, model versions, and deployment environments continue to increase, the system's configuration management and initialization processes become increasingly complex.

[0003] Currently, most systems still rely on static configuration files or manual operations, lacking unified version control, environment awareness mechanisms, and initialization security guarantees. This easily leads to problems such as inconsistent configurations, initialization conflicts, environment drift, and abnormal system deployments. Furthermore, database schema evolution and agent configuration management are often tightly coupled, lacking standardized migration mechanisms and configuration versioning management. Especially in microservice multi-instance deployment scenarios, the simultaneous startup of multiple instances can easily cause concurrent conflicts in database schema changes and configuration initialization, severely impacting system stability and maintainability. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for dynamic configuration initialization and version synchronization of multi-agent services, so as to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a method for dynamic configuration initialization and version synchronization of multi-agent services, comprising the following steps:

[0006] Acquiring a database update lock: Before performing a database table structure upgrade operation, select the appropriate distributed lock mechanism based on the database type to acquire a database update lock in a distributed environment, set a reasonable timeout and retry mechanism, and continue subsequent operations after successfully acquiring the lock; otherwise, log information is printed and the initialization process is exited if an exception or timeout occurs.

[0007] Build database migration script dependencies: Scan migration script files stored in a specified directory according to a specific naming convention, parse the version number field and the previous version number field in the file, dynamically build a chain of dependencies for the migration scripts, and form an ordered upgrade path;

[0008] Determine the current version of the database schema: Check if a migration version table exists in the database to confirm the current database schema version status. If it does not exist, set it to empty. If it exists, read the record in the table and compare it with the version in the migration script chain. If there is an error, stop the operation and log it. If there is a valid match, use that version as the starting point.

[0009] Database schema upgrade and deployment operations: The execution strategy is determined based on the current version status of the database. If the current version is empty, all migration scripts are executed sequentially from the starting point of the migration chain. If the current version exists, the migration scripts after the current version are executed. Data consistency and transaction atomicity are guaranteed by relying on the characteristics of database transactions. The migration execution status is recorded in real time to ensure the idempotency of the upgrade process.

[0010] Agent version verification: During the initialization or upgrade phase, check the agent version record table in the database to confirm the version status of each agent instance. If there is no version record, set it to empty. If there is a record, check if it is the latest version. If it is not the latest version, mark it as pending upgrade and execute the upgrade process.

[0011] Preferably, in the step of acquiring the database update lock, in a PostgreSQL-based database environment, the Advisory Lock mechanism provided by PostgreSQL is used to acquire a lock with a custom identifier at the session level or transaction level, ensuring that only one session can hold the lock.

[0012] Preferably, the system also includes a process for detecting the availability of the agent management service port: before performing agent initialization and upgrade operations, the system initiates a TCP connection request and polls to check whether the target service port is ready; if the detection fails, the system retryes multiple times according to a preset fixed time interval retry strategy; if the maximum number of retries is reached and a connection still cannot be established, an alarm mechanism is triggered, detailed logs are recorded, and the initialization process is terminated.

[0013] Preferably, the process also includes the following steps: uploading agent descriptions and configuration files and dynamically creating agents, updating agent IDs and migrating historical records, and updating records: Uploading agent descriptions and configuration files and dynamically creating agents: Traversing the agent list, when an agent version is detected as non-existent or lower than the expected version, automatically uploading the agent description file and configuration file to a centralized file storage service to obtain a unique file identifier. Based on this identifier, a new version of the agent is created by calling the agent management service interface via a RESTful API, and the newly generated agent ID is obtained; Updating agent IDs and migrating historical records: After the creation of the new version of the agent is completed, the historical records and running log information associated with the old version of the agent are migrated to the new version of the agent; Updating records: After all migration and upgrade operations are completed, the database records are updated synchronously to ensure that the agent version number field is the latest version, the corresponding agent ID is correctly maintained, and the version change information in the update operation records is updated.

[0014] Preferably, it also includes idempotency and transaction guarantee steps: all update operations are designed to be idempotent; before executing an update operation, the database is connected to query the target version information to confirm the database availability status; port availability is checked to ensure that dependent services are in a listening state; the current version number is verified before each version update operation, and if the version is consistent, the update operation is skipped; all update processes are encapsulated in transactions to ensure that all operations are successfully committed or rolled back in case of exceptions, maintaining the consistency of database and business data.

[0015] A system for a dynamic configuration initialization and version synchronization method for multi-agent services includes:

[0016] Database update lock acquisition module: Before performing database table structure upgrade operations, it attempts to acquire a database update lock in a distributed environment. The appropriate distributed lock mechanism is selected according to the database type used. For example, when based on PostgreSQL, the Advisory Lock mechanism is used to acquire a lock with a custom identifier at the session level or transaction level. Reasonable timeout and retry mechanism are set. If an exception or timeout occurs, log information is printed and the initialization process is exited. After successfully acquiring the lock, subsequent database migration and agent-related initialization operations are continued.

[0017] Migration script dependency building module: Before executing database migration, it scans the migration script files stored in the specified directory according to a specific naming convention, parses the version number field and the previous version number field in the file, dynamically builds the chain dependency relationship of the migration script, forms an ordered upgrade path from the initial version to the latest version, and realizes automatic sorting and dependency verification functions.

[0018] Database schema version determination module: After completing the migration script dependency chain construction, check whether the migration version table exists in the database to confirm the current database schema version status; if it does not exist, set the version status to empty; if it exists, read the record in the table and compare it with the version in the migration script chain. If there is an error, stop the subsequent operation and log it. If there is a valid match, execute the subsequent migration script starting from that version.

[0019] Database schema upgrade and deployment module: The migration execution strategy is determined based on the current version status of the database. If the current version is empty, all migration scripts are executed sequentially from the starting point of the migration chain. If the current version exists, the migration scripts after the current version are executed one by one. Data consistency and transaction atomicity are guaranteed by relying on the characteristics of database transactions, and the migration execution status is recorded in real time to ensure the idempotency of the upgrade process.

[0020] Agent version verification module: During the initialization or upgrade phase, check the agent version record table in the database to confirm the version status of each agent instance. If there is no version record, set it to empty. If there is a version record, check whether it is the latest version. If it is not the latest version, mark it as pending upgrade and execute the upgrade process.

[0021] Preferably, it also includes an agent management service port availability detection module: before performing agent initialization and upgrade operations, it initiates a TCP connection request and polls to check whether the target service port is ready; if the detection fails, it retryes multiple times according to a preset fixed time interval retry strategy; if the connection still cannot be established after reaching the maximum number of retries, it triggers an alarm mechanism, records detailed logs, and terminates the initialization process.

[0022] Preferably, it also includes a module for processing and dynamically creating agent descriptions and configuration files: traversing the agent list, when an agent version is detected to be missing or lower than the expected version, automatically performing the agent description file and configuration file upload operation to a centralized file storage service to obtain a unique file identifier, thereby decoupling the agent configuration file from the business logic; after the file upload is successful, based on the returned unique file identifier, calling the agent management service interface through a RESTful API to initiate a new version agent creation request, obtaining the newly generated agent ID for subsequent version marking and historical migration operations.

[0023] Preferably, it also includes an agent historical data maintenance module: after the creation of the new version agent is completed, the historical records and operation log information associated with the old version agent are migrated to the new version agent to maintain the integrity of historical data and business continuity; after all migration and upgrade operations are completed, the database records are updated synchronously to ensure that the agent version number field in the database table is the latest version, the corresponding agent ID is correctly maintained, and the version change information of the operation record is updated.

[0024] Preferably, it also includes an idempotency and transaction guarantee module: making all update operations idempotent; before executing an update operation, connecting to the database to query the target version information to confirm the database availability status; ensuring that dependent services are in a listening state through port availability detection; verifying the current version number before each version update operation, and skipping the update operation if the version is already consistent; encapsulating all update processes in transactions to ensure that all operations are successfully committed or rolled back in case of exceptions, maintaining the consistency of database and business data.

[0025] Compared with the prior art, the beneficial effects of the present invention are:

[0026] The dynamic configuration initialization and version synchronization method and system for multi-agent services proposed in this invention effectively support the database structure upgrade and agent version initialization process in a distributed deployment environment by introducing a rigorous database update lock control mechanism, a comprehensive migration script dependency chain verification, agent version management, port availability detection, and idempotency and transaction guarantee measures, thus ensuring system data consistency, operational stability, and business continuity. Attached Figure Description

[0027] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the present invention clear and complete, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only some, not all, embodiments of the present invention, and are merely illustrative of the embodiments of the present invention. They are not intended to limit the embodiments of the present invention. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] Example 1, please refer to Figure 1 This invention provides a technical solution: a method for dynamic configuration initialization and version synchronization of multi-agent services, comprising the following steps:

[0030] 4.1. Acquiring the database update lock

[0031] Before performing database table structure upgrade operations, the system must first attempt to acquire a database update lock in a distributed environment to ensure that in a multi-node deployment architecture, only one instance can perform subsequent database migration and configuration synchronization tasks, thus avoiding concurrent initialization conflicts or data consistency issues caused by multiple instances operating at the same time.

[0032] The specific implementation method can be selected according to the type of database used, and the appropriate distributed lock mechanism can be selected. For example, in a PostgreSQL-based database environment, the Advisory Lock mechanism provided by PostgreSQL can be used. This mechanism ensures that only one session can hold the lock by acquiring a lock with a custom identifier at the session level or transaction level. Other sessions must wait or give up the operation if they fail to acquire the lock.

[0033] During lock acquisition, the system employs reasonable timeout and retry mechanisms to prevent deadlocks or prolonged blocking from causing system initialization to stall. In case of exceptions or timeouts, the system will log information and then exit the initialization process. After successfully acquiring the lock, subsequent database migration and agent-related initialization operations will continue.

[0034] 4.2. Establish database migration script dependencies

[0035] To ensure the security, controllability, and rigor of the version evolution process during database migration, the system scans all migration script files in a specified directory before performing the database migration. Migration scripts are typically stored using a specific naming convention, and each script file contains the current version number and information about its dependent previous version numbers.

[0036] After scanning, the system dynamically constructs a chain of dependencies for the migration scripts by parsing the version number and previous version number fields within the files. This forms an ordered upgrade path from the initial version to the latest version, ensuring that the migration scripts are executed strictly in the order of version dependencies. This avoids database table structure anomalies or data corruption caused by incorrect script order. The migration chain features automatic sorting and dependency verification, preventing human error and ensuring the continuity and reliability of database structure changes.

[0037] 4.3. Determine the current version of the database schema

[0038] After completing the migration script dependency chain construction, the system needs to check whether the migration version table exists in the database to confirm the current version status of the database schema.

[0039] If the system detects that the version table does not exist in the database, it means that the current environment is a brand new deployment and no migration scripts have been executed yet. The current version status is set to empty, pending the execution of the complete migration chain. If the version table exists, the current database version recorded in the table needs to be read and compared with the version in the aforementioned migration script chain.

[0040] If a record in the version table cannot be found in the migration chain, it means that the version record in the database may be abnormal or missing, posing an unpredictable risk. In this case, the system will proactively stop subsequent operations, record detailed error logs, and prompt the administrator to manually verify the version information to prevent continued execution from potentially causing database structure corruption or business data inconsistency.

[0041] If a version in the version table has a valid match in the migration chain, then that version is used as the starting point to execute the migration scripts in the subsequent version chains, ensuring that the database schema is gradually upgraded to the latest version and guaranteeing the integrity of the system structure and data.

[0042] 4.4 Database schema upgrade and deployment operations

[0043] Based on the current database version status obtained above, the system will determine the specific database migration execution strategy. If the current version is empty, it means that no migration scripts have been executed. The system needs to start from the starting version of the migration chain and execute all migration scripts in the chain sequentially to complete the database structure and data initialization process.

[0044] If the current version exists, it means that the database has executed some migration scripts. The system needs to skip the executed parts according to the position of the current version in the migration chain, and start executing the migration scripts after the current version one by one until they are completed, thus completing the upgrade operation.

[0045] Whether it's a new deployment environment or a version upgrade environment, the same set of migration scripts will ultimately be executed to ensure that the database structure of all deployment instances is consistent.

[0046] The migration script execution process relies on the database's inherent transaction characteristics to ensure data consistency and transaction atomicity. This ensures that each migration script either executes completely successfully or rolls back to the previous version state in the event of an execution error, preventing inconsistencies caused by partial execution. Simultaneously, the system records the migration execution status in real time during execution to prevent duplicate execution of completed scripts and guarantee the idempotency of the upgrade process.

[0047] 4.5. Agent Version Verification

[0048] During the initialization or upgrade phase, the system checks the agent version record table in the database to confirm the current version status of each agent instance. If no agent version record exists in the database, it indicates a newly deployed environment, and all agent version statuses are set to empty. If version records exist, the system will sequentially verify whether each agent version is the latest version. If all are the latest versions, no upgrade is needed, and no further steps are performed.

[0049] If any agent versions are found to be lower than the target version, the system will mark them as pending upgrades and execute the agent upgrade process until all agent versions meet the expected standard before the initialization process is complete. This ensures that all agent versions run collaboratively and avoids operational anomalies caused by version incompatibility.

[0050] 4.6. Availability Detection of Agent Management Service Port

[0051] Before performing agent initialization and upgrade operations, the system needs to perform availability checks on all agent management service ports to ensure that dependent services are running normally. Specifically, the system initiates TCP connection requests and polls to check whether the target service port is ready.

[0052] If the detection fails, the system will retry multiple times according to a preset retry strategy at fixed time intervals. If the maximum number of retries is reached and a connection still cannot be established, the system will trigger an alarm mechanism, record detailed logs, and then terminate the initialization process.

[0053] This step ensures that all dependent services are fully available before the agent starts, improving the overall stability and fault tolerance of the system.

[0054] 4.7. Uploading Agent Descriptions and Configuration Files and Dynamic Creation of Agents

[0055] The system iterates through the entire agent list. When it detects that an agent's version is missing or lower than the expected version, it automatically uploads the agent's description file and configuration file. All files are stored in a centralized file storage service and assigned a unique file identifier.

[0056] This step decouples the agent configuration file from the business logic, improves the uniformity and security of file management, and avoids version conflicts or missing information caused by scattered file deployment.

[0057] After the file is successfully uploaded, the system uses the returned file's unique identifier to call the agent management service interface via the RESTful API to initiate a new version agent creation request and obtain the newly generated agent ID for subsequent version marking and historical migration operations.

[0058] 4.8. Agent ID Update and Historical Record Migration

[0059] After the creation of the new version of the intelligent agent is completed, the system needs to migrate the historical records, operation logs and other information associated with the old version of the intelligent agent to the new version of the intelligent agent to maintain the integrity of historical data and business continuity.

[0060] 4.9. Record Update

[0061] After all migration and upgrade operations are completed, the system must synchronously update the database records to ensure that the agent version number field in the database table is the latest version and that the corresponding agent ID is correctly maintained, ensuring the correctness of subsequent version verification and upgrade operations. At the same time, update the operation records with version change information to facilitate subsequent version traceability and anomaly troubleshooting, improving system maintainability.

[0062] 4.10. Idempotency and Transaction Guarantees

[0063] To ensure the safety and reliability of system initialization and upgrade operations, all update operations are designed to be idempotent, meaning the same operation can be executed safely multiple times without side effects, avoiding the risk of exceptions caused by repeated execution. Before executing an update operation, the system first connects to the database to query the target version information and confirms that the database is available. Subsequently, port availability checks are performed to ensure that dependent services are in a listening state, guaranteeing the success rate of service interface calls.

[0064] Before each version update operation, the system verifies the current version number. If the version is already consistent, the update operation is skipped to avoid duplicate updates. All update processes are encapsulated in transactions to ensure that operations are either fully committed successfully or rolled back in case of exceptions, maintaining database and business data consistency and preventing data corruption caused by partial execution.

[0065] Example 2, based on Example 1, proposes a system for the dynamic configuration initialization and version synchronization method of multi-agent services according to claim 5, comprising:

[0066] Database update lock acquisition module: Before performing database table structure upgrade operations, it attempts to acquire a database update lock in a distributed environment. The appropriate distributed lock mechanism is selected according to the database type used. For example, when based on PostgreSQL, the Advisory Lock mechanism is used to acquire a lock with a custom identifier at the session level or transaction level. Reasonable timeout and retry mechanism are set. If an exception or timeout occurs, log information is printed and the initialization process is exited. After successfully acquiring the lock, subsequent database migration and agent-related initialization operations are continued.

[0067] Migration script dependency building module: Before executing database migration, it scans the migration script files stored in the specified directory according to a specific naming convention, parses the version number field and the previous version number field in the file, dynamically builds the chain dependency relationship of the migration script, forms an ordered upgrade path from the initial version to the latest version, and realizes automatic sorting and dependency verification functions.

[0068] Database schema version determination module: After completing the migration script dependency chain construction, check whether the migration version table exists in the database to confirm the current database schema version status; if it does not exist, set the version status to empty; if it exists, read the record in the table and compare it with the version in the migration script chain. If there is an error, stop the subsequent operation and log it. If there is a valid match, execute the subsequent migration script starting from that version.

[0069] Database schema upgrade and deployment module: The migration execution strategy is determined based on the current version status of the database. If the current version is empty, all migration scripts are executed sequentially from the starting point of the migration chain. If the current version exists, the migration scripts after the current version are executed one by one. Data consistency and transaction atomicity are guaranteed by relying on the characteristics of database transactions, and the migration execution status is recorded in real time to ensure the idempotency of the upgrade process.

[0070] Agent version verification module: During the initialization or upgrade phase, check the agent version record table in the database to confirm the version status of each agent instance. If there is no version record, set it to empty. If there is a version record, check whether it is the latest version. If it is not the latest version, mark it as pending upgrade and execute the upgrade process.

[0071] It also includes an agent management service port availability detection module: before performing agent initialization and upgrade operations, it initiates a TCP connection request and polls to check whether the target service port is ready; if the detection fails, it retryes multiple times according to a preset fixed time interval retry strategy. If the connection still cannot be established after reaching the maximum number of retries, it triggers an alarm mechanism, records detailed logs, and terminates the initialization process.

[0072] It also includes a module for processing and dynamically creating agent descriptions and configuration files: it iterates through the agent list, and when it detects that an agent version does not exist or is lower than the expected version, it automatically performs the agent description file and configuration file upload operation to a centralized file storage service to obtain a unique file identifier, thereby decoupling the agent configuration file from the business logic; after the file upload is successful, based on the returned unique file identifier, it calls the agent management service interface through a RESTful API to initiate a new version agent creation request, and obtains the newly generated agent ID for subsequent version marking and historical migration operations.

[0073] It also includes a module for maintaining historical data of intelligent agents: after the creation of a new version of intelligent agent, the historical records and operation log information associated with the old version of intelligent agent are migrated to the new version of intelligent agent to maintain the integrity of historical data and business continuity; after all migration and upgrade operations are completed, the database records are updated synchronously to ensure that the intelligent agent version number field in the database table is the latest version, the corresponding intelligent agent ID is correctly maintained, and the version change information of the operation record is updated.

[0074] It also includes an idempotency and transaction guarantee module: making all update operations idempotent; before executing an update operation, connecting to the database to query the target version information to confirm the database availability status; ensuring that dependent services are in a listening state through port availability detection; verifying the current version number before each version update operation, and skipping the update operation if the version is already consistent; encapsulating all update processes in transactions to ensure that all operations are successfully committed or rolled back in case of exceptions, maintaining the consistency of database and business data.

[0075] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for dynamic configuration initialization and version synchronization of multi-agent services, characterized in that: Includes the following steps: Acquiring a database update lock: Before performing a database table structure upgrade operation, select the appropriate distributed lock mechanism based on the database type to acquire a database update lock in a distributed environment, set a reasonable timeout and retry mechanism, and continue subsequent operations after successfully acquiring the lock; otherwise, log information is printed and the initialization process is exited if an exception or timeout occurs. Build database migration script dependencies: Scan migration script files stored in a specified directory according to a specific naming convention, parse the version number field and the previous version number field in the file, dynamically build a chain of dependencies for the migration scripts, and form an ordered upgrade path; Determine the current version of the database schema: Check if a migration version table exists in the database to confirm the current database schema version status. If it does not exist, set it to empty. If it exists, read the record in the table and compare it with the version in the migration script chain. If there is an error, stop the operation and log it. If there is a valid match, use that version as the starting point. Database schema upgrade and deployment operations: The execution strategy is determined based on the current version status of the database. If the current version is empty, all migration scripts are executed sequentially from the starting point of the migration chain. If the current version exists, the migration scripts after the current version are executed. Data consistency and transaction atomicity are guaranteed by relying on the characteristics of database transactions. The migration execution status is recorded in real time to ensure the idempotency of the upgrade process. Agent version verification: During the initialization or upgrade phase, check the agent version record table in the database to confirm the version status of each agent instance. If there is no version record, set it to empty. If there is a record, check if it is the latest version. If it is not the latest version, mark it as pending upgrade and execute the upgrade process.

2. The method for dynamic configuration initialization and version synchronization of a multi-agent service according to claim 1, characterized in that: In the process of acquiring a database update lock, in a PostgreSQL-based database environment, the Advisory Lock mechanism provided by PostgreSQL is used to acquire a lock with a custom identifier at the session or transaction level, ensuring that only one session can hold the lock.

3. The method for dynamic configuration initialization and version synchronization of a multi-agent service according to claim 2, characterized in that: It also includes a process for detecting the availability of the agent management service port: Before performing agent initialization and upgrade operations, the system initiates a TCP connection request and polls to check whether the target service port is ready; if the detection fails, it retryes multiple times according to a preset fixed time interval retry strategy. If the connection still cannot be established after reaching the maximum number of retries, an alarm mechanism is triggered, detailed logs are recorded, and the initialization process is terminated.

4. The method for dynamic configuration initialization and version synchronization of a multi-agent service according to claim 3, characterized in that: This also includes steps for uploading agent descriptions and configuration files and dynamically creating agents, updating agent IDs and migrating historical records, and updating records: Uploading agent descriptions and configuration files and dynamically creating agents: Traversing the agent list, when an agent version is detected as non-existent or lower than the expected version, automatically uploading the agent description file and configuration file to a centralized file storage service to obtain a unique file identifier. Based on this identifier, a new version of the agent is created by calling the agent management service interface via a RESTful API, and the newly generated agent ID is obtained; Updating agent IDs and migrating historical records: After the creation of the new version of the agent is completed, the historical records and running log information associated with the old version of the agent are migrated to the new version of the agent; Updating records: After all migration and upgrade operations are completed, the database records are updated synchronously to ensure that the agent version number field is the latest version, the corresponding agent ID is correctly maintained, and the version change information in the update operation records is updated.

5. The method for dynamic configuration initialization and version synchronization of a multi-agent service according to claim 4, characterized in that: It also includes idempotency and transaction guarantee steps: all update operations are designed to be idempotent, and before executing an update operation, the database is connected to query the target version information to confirm the database availability status, and port availability is checked to ensure that dependent services are in a listening state; Before each version update operation, the current version number is verified. If the version is already consistent, the update operation is skipped. All update processes are encapsulated in transactions to ensure that all operations are successfully committed or rolled back in case of exceptions, thus maintaining the consistency of database and business data.

6. A system for the dynamic configuration initialization and version synchronization method of multi-agent services according to claim 5, characterized in that: include: Database update lock acquisition module: Before performing database table structure upgrade operations, it attempts to acquire a database update lock in a distributed environment. The appropriate distributed lock mechanism is selected according to the database type used. For example, when based on PostgreSQL, the Advisory Lock mechanism is used to acquire a lock with a custom identifier at the session level or transaction level. Reasonable timeout and retry mechanism are set. If an exception or timeout occurs, log information is printed and the initialization process is exited. After successfully acquiring the lock, subsequent database migration and agent-related initialization operations are continued. Migration script dependency building module: Before executing database migration, it scans the migration script files stored in the specified directory according to a specific naming convention, parses the version number field and the previous version number field in the file, dynamically builds the chain dependency relationship of the migration script, forms an ordered upgrade path from the initial version to the latest version, and realizes automatic sorting and dependency verification functions. Database schema version determination module: After completing the migration script dependency chain construction, check whether the migration version table exists in the database to confirm the current database schema version status; if it does not exist, set the version status to empty; if it exists, read the record in the table and compare it with the version in the migration script chain. If there is an error, stop the subsequent operation and log it. If there is a valid match, execute the subsequent migration script starting from that version. Database schema upgrade and deployment module: The migration execution strategy is determined based on the current version status of the database. If the current version is empty, all migration scripts are executed sequentially from the starting point of the migration chain. If the current version exists, the migration scripts after the current version are executed one by one. Data consistency and transaction atomicity are guaranteed by relying on the characteristics of database transactions, and the migration execution status is recorded in real time to ensure the idempotency of the upgrade process. Agent version verification module: During the initialization or upgrade phase, check the agent version record table in the database to confirm the version status of each agent instance. If there is no version record, set it to empty. If there is a version record, check whether it is the latest version. If it is not the latest version, mark it as pending upgrade and execute the upgrade process.

7. The system according to claim 6, characterized in that: It also includes an agent management service port availability detection module: before performing agent initialization and upgrade operations, it initiates a TCP connection request and polls to check whether the target service port is ready; if the detection fails, it retryes multiple times according to a preset fixed time interval retry strategy. If the connection still cannot be established after reaching the maximum number of retries, it triggers an alarm mechanism, records detailed logs, and terminates the initialization process.

8. The system according to claim 7, characterized in that: It also includes a module for processing and dynamically creating agent descriptions and configuration files: it iterates through the agent list, and when it detects that an agent version does not exist or is lower than the expected version, it automatically performs the agent description file and configuration file upload operation to a centralized file storage service to obtain a unique file identifier, thereby decoupling the agent configuration file from the business logic; after the file upload is successful, based on the returned unique file identifier, it calls the agent management service interface through the RESTful API to initiate a new version agent creation request, and obtains the newly generated agent ID for subsequent version marking and historical migration operations.

9. A system according to claim 8, characterized in that: It also includes a module for maintaining historical data of intelligent agents: after the creation of a new version of intelligent agent, the historical records and operation log information associated with the old version of intelligent agent are migrated to the new version of intelligent agent to maintain the integrity of historical data and business continuity; after all migration and upgrade operations are completed, the database records are updated synchronously to ensure that the intelligent agent version number field in the database table is the latest version, the corresponding intelligent agent ID is correctly maintained, and the version change information of the operation record is updated.

10. A system according to claim 9, characterized in that: It also includes an idempotency and transaction guarantee module: making all update operations idempotent, connecting to the database to query the target version information to confirm the database availability status before executing the update operation, and ensuring that dependent services are in a listening state through port availability detection; Before each version update operation, the current version number is verified. If the version is already consistent, the update operation is skipped. All update processes are encapsulated in transactions to ensure that all operations are successfully committed or rolled back in case of exceptions, thus maintaining the consistency of database and business data.

Images