Methods, systems, devices, and storage media for building multi-agent microservice models

Abstract

This invention provides a method, system, device, and storage medium for constructing a multi-agent microservice model. The method includes: receiving a target microservice codebase; launching a multi-agent collaborative system based on a large language model; this system extracts field source mapping relationships and business processing logic by calling a code parsing tool and combining it with thought chain reasoning, generating structured lineage data and system model data; sending the generated data to a message middleware; asynchronously consuming the data; persisting the text containing field processing logic to a relational database; and persisting the edge relationships between service nodes and field flows to a graph database. This invention overcomes the context overload and illusion problems when a single model processes a large codebase by splitting multi-agent tasks and synchronizing lightweight local library states, giving the system breakpoint resume capability and achieving transparency and real-time synchronization of technical assets and business logic.

Description

Technical Field

[0001] This invention relates to the field of service architecture development, and more specifically, to a method, system, device, and storage medium for constructing a multi-agent microservice model. Background Technology

[0002] With the widespread adoption of cloud computing and distributed system architectures, microservice architecture has become the mainstream choice for building large-scale enterprise applications. It breaks down a massive monolithic application into multiple small, independently deployed services, each built around a specific business capability and developed, deployed, and scaled by an independent team. This architectural pattern offers numerous advantages, including flexible technology selection, fault isolation, and ease of continuous delivery. However, the complexity of microservice architecture also introduces significant governance challenges, most notably the intricate dependencies between services, forming a difficult-to-understand and maintain "spider web." When a system contains dozens or even hundreds of microservices, understanding the complete call chain of a business request, how data flows between services, and what business transformations a particular field undergoes becomes extremely difficult.

[0003] To address this challenge, the industry has developed service lineage analysis and system modeling technologies. Their core objective is to automatically or semi-automatically extract the call relationships between services, data flow, and the internal processing logic of each service from the microservice codebase, configuration files, and runtime data, and present this information in the form of visual graphs or models. This helps architects, developers, and operations personnel understand the current state of the system, assess the impact of changes, locate the root cause of failures, and discover performance bottlenecks. Existing technical solutions mainly rely on the following three approaches: First, there's static code scanning based on abstract syntax trees (ASTs). This closest existing technique primarily extracts data flow at the table and field levels of the database by parsing Structured Query Language (SCL) statements. Its working principle is to parse the code into an AST and then traverse the AST nodes to identify read and write operations in the SCL statements. A significant drawback of this approach is its limited analytical dimension; it can only extract low-level data flow relationships and cannot trace data across microservice components. For example, when one service calls another via a remote procedure call, AST-based scanning cannot correlate the before-and-after states of the same business field in both services. More seriously, it cannot understand business code logic containing conditional statements, loops, and complex data transformations; the extracted graph is merely a cold, impersonal connection of syntax nodes, lacking any business semantics. This makes the resulting system model almost unreadable to business users, unusable for business alignment and domain understanding, and creates a huge gap between technical assets and business knowledge. Furthermore, AST-based methods struggle to handle dynamic features such as reflection and dynamic proxies, resulting in extracted graphs lacking business semantics and failing to generate system models readable by business users.

[0004] Second, there's the issue of code summarization based on a single large language model. With the rapid development of artificial intelligence, especially the astonishing capabilities of large language models in code understanding, some cutting-edge solutions attempt to directly input the entire microservice codebase or key code snippets into a single large language model, requiring it to generate summaries of service call relationships or data flow annotations. While this approach can understand the semantics of the code to some extent, its flaws are equally fatal. First, a massive microservice codebase contains thousands of source files, easily exceeding the context window limit of a single language model—meaning the model can only process a limited number of tokens at a time. When the code length exceeds the window size, the model must truncate the input, leading to the loss of crucial information. Second, even when the code length is within the window, language models exhibit severe forgetting when processing long sequences; they tend to focus on the beginning and end of the input sequence while ignoring the middle, causing a sharp drop in accuracy when tracing long call chains. Furthermore, the inherent illusion problem of language models is further amplified in long context scenarios, potentially leading to the model fabricating non-existent call relationships or data transformation logic. Finally, full analysis of microservice code is typically a computationally intensive and time-consuming process, potentially lasting tens of minutes or even hours. If a service timeout, container restart, or network interruption occurs during the analysis process, the single model cannot save any intermediate inference state, and the entire task must start from scratch. It lacks the most basic fault tolerance capability of resuming interrupted downloads, which is unacceptable in an industrial production environment.

[0005] Third, dynamic and static data are isolated. While existing distributed tracing probes can record the actual dynamic call chains, they lack summaries of business logic at the code level. Currently, there is a lack of an effective mechanism to feed back the truth values ​​from dynamic runtime to the static inference process for closed-loop self-correction, leading to a potential disconnect between the results of large model analysis and actual online operation. Static analysis is based on code text for reasoning, but actual runtime may produce execution paths different from static code due to factors such as dynamic deployment from the configuration center, feature switching, and A / B testing. Without feedback and correction from dynamic links, the results of static analysis will fail to reflect the system's true behavior, thus reducing the practical value of the analysis results.

[0006] To address the aforementioned pain points, traditional AST-based static scanning techniques cannot provide business semantics, while parsing schemes based on a single LLM are limited by context windows, illusion problems, and state volatility, failing to meet the real-time, accuracy, and reliability requirements of large-scale microservice architecture governance. Therefore, how to provide a highly available, highly accurate, and business semantic-understanding-capable automated construction solution for service lineage and system models has become a pressing technical problem for those skilled in the art.

[0007] In view of this, the present invention provides a method, system, device and storage medium for constructing a multi-agent microservice model. Summary of the Invention

[0008] To address the problems in existing technologies, the present invention aims to provide a method, system, device, and storage medium for constructing a multi-agent microservice model. This overcomes the difficulties of existing technologies, specifically the context overload and illusion problems encountered when a single model handles a large codebase, achieving transparency and real-time synchronization between technical assets and business logic.

[0009] Embodiments of the present invention provide a method for constructing a multi-agent microservice model, comprising the following steps: S110. Abstract the target microservice system into a topology that includes input interfaces, business processing entities, storage entities, and output interfaces; S120. Start a multi-agent collaborative system based on a large language model to parse the code library of the target microservice. The multi-agent collaborative system extracts the source mapping relationship of each field and the corresponding business processing logic by calling the code parsing tool and combining the thinking chain reasoning, and generates structured lineage data and system model data. The multi-agent collaborative system includes at least a master control agent, an interface and metadata scanning agent, and a lineage tracing and logic extraction agent. S130. Send the bloodline data and system model data to the message middleware; S140. The asynchronous collection service consumes the data in the message middleware, persists the text containing field processing logic to a relational database, and persists the edge relationship between the service node and the field flow to a graph database.

[0010] Preferably, step S120 further includes: The multi-agent collaborative system performs deep link tracing. Multiple agents persist intermediate inference states and synchronize progress by mounting a lightweight local relational database to enable breakpoint resumption of parsing tasks. The lightweight local relational database is SQLite, and the intermediate inference states include variable data type conversion records and code link tracing nodes.

[0011] Preferably, in step S120, the business processing logic is extracted as follows: based on the semantic understanding capability of the large language model, the code snippets containing conditional branches and data transformation operations are summarized into highly generalized natural language logic descriptions; and the natural language logic descriptions are attached as attributes to the edge relationships of field flow stored in the graph database.

[0012] Preferably, in step S120, the master control agent is configured to issue parsing rules and tasks and load project-level development specifications; the interface and metadata scanning agent is configured to call a static code scanning tool to identify and extract the external interfaces of the controller layer and the entity class mapping of the data access object layer, so as to determine the boundaries of the input interface, storage entity and output interface, and write the generated system model skeleton data into a lightweight local relational database.

[0013] Preferably, in step S120, the lineage tracing and logic extraction agent is configured to monitor the status of the lightweight local relational database, receive the identified interface entities, and reverse trace the code flow using the thought chain strategy of a large language model; during deep tracing across microservice components, classes, and methods, the generated intermediate inference results are frequently written to the mounted lightweight local relational database so that execution can continue from the last inference node when parsing is interrupted.

[0014] Preferably, step S120 further includes: a dynamic-static cross-validation and self-correction step: constructing a verification agent, acquiring distributed call chain log data during the target microservice runtime, performing graph comparison between the link tracing log data and preliminary static lineage data, identifying dynamic call chains that were missed or misjudged in the static analysis, and constructing inconsistent call contexts as error correction prompts to be fed back to the multi-agent collaborative system, and performing secondary deduction and self-correction of the thought chain to generate cross-validated structured lineage data and system model data. Preferably, in step S140, in the step of persisting the edge relationship between service nodes and field flows to the graph database, directed edges from interface nodes to database nodes are established in the graph database to store topological paths. At the same time, detailed natural language logical text is recorded in the relational database, and the two are mapped through globally unique attribute identifiers.

[0015] Preferably, step S140 further includes: an incremental file difference triggering mechanism based on continuous integration pipeline or code repository Webhook monitoring, whereby when the code changes, the multi-agent collaboration system only extracts the difference context for incremental parsing, thereby achieving local hot updates of the relational database and the graph database.

[0016] Embodiments of the present invention also provide a multi-agent microservice model construction system for implementing the above-described multi-agent microservice model construction method, the multi-agent microservice model construction system comprising: The microservice parsing module abstracts the target microservice system into a topology that includes input interfaces, business processing entities, storage entities, and output interfaces. The system generation module starts a multi-agent collaborative system built on a large language model to parse the code library of the target microservice. The multi-agent collaborative system extracts the source mapping relationship of each field and the corresponding business processing logic by calling the code parsing tool and combining the thinking chain reasoning, and generates structured lineage data and system model data. The multi-agent collaborative system includes at least a master control agent, an interface and metadata scanning agent, and a lineage tracing and logic extraction agent. The message passing module sends the bloodline data and system model data to the message middleware; The database update module asynchronously collects data from the message middleware consumed by the service, persists the text containing field processing logic to a relational database, and persists the edge relationships between service nodes and field flows to a graph database.

[0017] Embodiments of the present invention also provide a multi-agent microservice model construction device, comprising: processor; A memory in which executable instructions of the processor are stored; The processor is configured to execute the steps of the multi-agent microservice model construction method described above by executing the executable instructions.

[0018] Embodiments of the present invention also provide a computer-readable storage medium for storing a program, which, when executed, implements the steps of the above-described multi-agent microservice model construction method.

[0019] The purpose of this invention is to provide a method, system, device, and storage medium for constructing a multi-agent microservice model. It can overcome the context overload and illusion problems when a single model processes a large codebase by splitting multi-agent tasks and synchronizing the state of a lightweight local library. It gives the system the ability to resume interrupted downloads and converts complex code logic into natural language business semantics, thereby achieving transparency and real-time synchronization of technical assets and business logic. Attached Figure Description

[0020] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0021] Figure 1 This is a flowchart of the multi-agent microservice model construction method of the present invention.

[0022] Figure 2 This is a schematic diagram of the process steps for implementing the multi-agent microservice model construction method of the present invention.

[0023] Figure 3 This is a system architecture diagram of the multi-agent microservice model construction system of the present invention.

[0024] Figure 4 This is a schematic diagram of the structure of the multi-agent microservice model construction device of the present invention.

[0025] Figure 5 This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of the present invention. Detailed Implementation

[0026] The following specific examples illustrate the implementation methods of this application. Those skilled in the art can easily understand the other advantages and effects of this application from the content disclosed herein. This application can also be implemented or applied through other different specific embodiments, and various details in this application can be modified or changed according to different viewpoints and application systems without departing from the spirit of this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0027] The embodiments of this application will now be described in detail with reference to the accompanying drawings, so that those skilled in the art can easily implement the application. This application may be embodied in many different forms and is not limited to the embodiments described herein.

[0028] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics represented in connection with that embodiment or example, which are included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics represented may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate different embodiments or examples represented in this application, as well as features of different embodiments or examples.

[0029] Furthermore, the terms "first" and "second" are used for illustrative purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the representation of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0030] For the purpose of clearly describing this application, devices that are not relevant to the description are omitted, and the same or similar components throughout the specification are given the same reference numerals.

[0031] Throughout this specification, when it is said that a device is "connected" to another device, this includes not only "direct connection" but also "indirect connection" by placing other components in between. Furthermore, when it is said that a device "comprises" a certain constituent element, unless otherwise stated otherwise, this does not exclude other constituent elements, but rather implies that other constituent elements may be included.

[0032] When we say that a device is "above" another device, this can mean that it is directly above the other device, or it can mean that other devices are present in between. Conversely, when we say that a device is "directly" "above" another device, there are no other devices present in between.

[0033] Although the terms first, second, etc., are used in some instances herein to refer to various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, first interface and second interface, etc., are used. Furthermore, as used herein, the singular forms “a,” “an,” and “the” are intended to also include the plural forms unless the context indicates otherwise. It should be further understood that the terms “comprising,” “including,” indicate the presence of features, steps, operations, elements, components, items, kinds, and / or groups, but do not exclude the presence, occurrence, or addition of one or more other features, steps, operations, elements, components, items, kinds, and / or groups. The terms “or” and “and / or” as used herein are interpreted as inclusive, or mean any one or any combination thereof. Thus, “A, B, or C” or “A, B, and / or C” means “any one of: A; B; C; A and B; A and C; B and C; A, B, and C.” Exceptions to this definition will only occur if the combination of elements, functions, steps, or operations is inherently mutually exclusive in some way.

[0034] The technical terms used herein are for reference only to specific embodiments and are not intended to limit the scope of this application. The singular form used herein includes the plural form unless the statement explicitly indicates otherwise. The word "comprising" as used in the specification means to specify a particular characteristic, region, integer, step, operation, element, and / or component, and does not exclude the presence or addition of other characteristics, regions, integers, steps, operations, elements, and / or components.

[0035] Although not explicitly defined, all terms, including technical and scientific terms used herein, shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. Terms defined in commonly used dictionaries shall be further interpreted as having a meaning consistent with the relevant technical literature and the content of this present application, and shall not be over-interpreted as having an ideal or overly formulaic meaning unless otherwise defined.

[0036] Figure 1This is a flowchart of the multi-agent microservice model construction method of the present invention. For example... Figure 1 As shown, the multi-agent microservice model construction method of the present invention includes the following steps: S110. Abstract the target microservice system into a topology that includes input interfaces, business processing entities, storage entities, and output interfaces; S120. Start a multi-agent collaborative system based on a large language model to parse the code library of the target microservice. The multi-agent collaborative system extracts the source mapping relationship of each field and the corresponding business processing logic by calling the code parsing tool and combining the thinking chain reasoning, and generates structured lineage data and system model data. The multi-agent collaborative system includes at least a master intelligent agent, an interface and metadata scanning intelligent agent, and a lineage tracing and logic extraction intelligent agent. S130. Send the lineage data and system model data to the message middleware; S140. Asynchronously collect data from the service consumption message middleware, persist the text containing field processing logic to a relational database, and persist the edge relationship between service nodes and field flow to a graph database.

[0037] The system of this invention first receives code change events through a code repository webhook or CI / CD pipeline. When an event is triggered, the master agent loads a predefined project configuration file (e.g., .yaml or .json format), which contains metadata such as service layering rules, RPC client definitions, and database table mappings. The master agent breaks down the overall parsing task into three stages: boundary scanning, lineage tracing, and logic extraction. Boundary scanning is performed by the interface and metadata scanning agent, which calls a language-specific AST parser (e.g., JavaParser or Python's ast module) to extract the API definitions of the Controller layer and the entity mappings of the DAO layer. The lineage tracing and logic extraction agent uses these boundaries as anchors and employs thought chain reasoning to progressively traverse the method call stack in reverse. Each time the LLM is called, the system only passes in the code snippet of the current method body and the already traced context summary to avoid exceeding the context window. All generated nodes (e.g., APIs, service methods, database tables) and edges (e.g., call relationships, data flow) are encapsulated in JSON format and sent to a Kafka message queue. The backend kinship collection service consumes these messages, uses NebulaGraph's nGQL statements to create nodes and edges, and uses MySQL's INSERT statements to store long text logic. The two are linked through the edge_uuid field.

[0038] This invention achieves fully automated construction of the entire process from the original codebase to a queryable and visualized service lineage and system model. Through task splitting and asynchronous decoupling, the system can complete the initial full parsing of a large codebase containing hundreds of microservices within minutes, while traditional manual analysis typically takes weeks. The introduction of message queues completely decouples the parsing layer from the persistence layer. Even if the database is temporarily unavailable, the parsing task will not be interrupted, and messages can be temporarily stored in the queue for processing after recovery, significantly improving the system's robustness. The hybrid storage strategy (graph database + relational database) enables topology query response time to be controlled in milliseconds, while supporting complex retrieval of long text logic (such as searching business rules by keywords), providing an efficient and reliable technical foundation for microservice governance.

[0039] In a preferred embodiment, step S120 further includes: the multi-agent collaborative system performs deep link tracing, and multiple agents persist intermediate inference states and synchronize progress by mounting a lightweight local relational database to enable breakpoint resumption of the parsing task; the lightweight local relational database is SQLite, and the intermediate inference state includes variable data type conversion records and code link tracing nodes. In this preferred embodiment, each agent mounts an SQLite database file locally upon startup, and this file is stored in a persistent volume (such as a PVC of a container cloud platform or a specified directory on the host machine). When executing a task, the agent writes the intermediate state of each key step into the agent_state table of the SQLite. The structure of this table includes: task_id (global task identifier), agent_id (agent identifier), step_name (step name, such as "parse OrderController"), step_input (hash of the input parameters of this step), step_output (summary of the output result of this step), checkpoint_data (detailed state data in JSON format, such as the traced variable type mapping stack), created_at, and updated_at timestamps. Once an agent completes the analysis of a method, it immediately updates the `step_output` and `checkpoint_data` fields of the corresponding record. If the agent process terminates due to timeout, memory overflow, or container restart, the system's master agent will detect that the task status is "incomplete". When restarting a new agent instance, the master agent will pass the same `task_id` to the new instance. The new instance first queries the last valid record corresponding to the `task_id` in SQLite, reads the status in `checkpoint_data`, and resumes execution from the point of interruption without starting from scratch. This preferred embodiment provides the system with industrial-grade fault tolerance. In a real production environment, performing a full analysis of a large microservice codebase containing tens of thousands of source files can take several hours. Without a breakpoint resume mechanism, any unexpected service restart will result in the loss of all work, and the task success rate is typically below 50%. By introducing lightweight state persistence based on SQLite, this invention improves the task success rate to over 99%. Compared to using external storage such as Redis, SQLite, as an embedded database, requires no additional network overhead or operational costs. Furthermore, its ACID properties guarantee the atomicity of state writes, avoiding inconsistencies. This mechanism also supports proactive task pause and resumption, allowing the system to execute parsing tasks during off-peak hours, significantly improving resource utilization efficiency.

[0040] In a preferred embodiment, in step S120, the business processing logic is extracted as follows: based on the semantic understanding capability of the large language model, code snippets containing conditional branches and data transformation operations are summarized into highly generalized natural language logic descriptions; and the natural language logic descriptions are then attached as attributes to the edge relationships of field flow stored in the graph database. In this preferred embodiment, when the lineage tracing and logic extraction agent traces a method containing complex business logic, it does not directly send the entire method body code to the LLM. Instead, the agent first uses a code parsing tool to break down the method body into multiple basic blocks, such as variable declaration blocks, conditional judgment blocks (if / else), loop blocks, assignment blocks, and return blocks. Then, the agent submits the code snippets of each basic block along with a carefully designed Few-Shot prompt template to the LLM in the order of the control flow graph. This prompt template contains multiple examples to guide the LLM to interpret "if (amount > 500) { total = amount The statement "0.9;}" is transformed into "If the order amount is greater than 500 yuan, then a 10% discount will be applied." The LLM returns an independent natural language description for each basic block. Finally, the agent concatenates these descriptions in the order of control flow and uses another LLM call to merge them into a coherent, highly generalized logical statement, such as: "The system first checks the order amount: if the amount exceeds 500 yuan, then a 10% discount will be automatically applied; otherwise, the original price will be applied." The logic description is then stored in the `logic_description` field of the relational database and associated with lineage relationships in the graph database via edge IDs. This preferred embodiment achieves a crucial leap from "code syntax" to "business semantics." Traditional static analysis tools can only output low-level information such as "OrderServiceImpl.java:45 calls inventoryClient.getPrice()", which is of no value to business users. However, the natural language description generated by this invention, such as "querying the price of goods in the inventory service," allows non-technical personnel (such as product managers, business analysts, and compliance auditors) to directly understand the system's business logic. This "semantic dimensionality reduction" capability extends microservice governance from the technical field to the business domain, enabling business users to participate in architecture reviews, impact analyses, and compliance verification, significantly reducing cross-role communication costs. Simultaneously, attaching the natural language description to the edges of the graph gives the visualization interface the interactive capability of "clicking to connect lines to see the logic," significantly improving the user experience.

[0041] In a preferred embodiment, in step S120, the master control agent is configured to issue parsing rules and tasks, and load project-level development specifications; the interface and metadata scanning agent is configured to call a static code scanning tool to identify and extract the external interfaces of the controller layer and the entity class mappings of the data access object layer, in order to determine the boundaries of input interfaces, storage entities, and output interfaces, and write the generated system model skeleton data into a lightweight local relational database. In this preferred embodiment, the master control agent pulls project-level development specifications from a configuration center (such as Nacos or Consul) during the task initialization phase. This specification is a structured document that defines rules such as "all Controller classes must be located in..." Rules such as "under the .controller package", "Service layer methods must be prefixed with 'execute' or 'process'", and "DAO layer entity classes must be annotated with '@Table'" are implemented. The master agent embeds these rules into the instructions distributed to other agents. When calling the AST parser, the interface and metadata scanning agent prioritizes scanning classes and methods that conform to these rules, ignoring test code and automatically generated code, thus narrowing the scan scope. After extracting the Controller layer interfaces and DAO layer entities, the scanning agent generates a system model skeleton, which describes the expected call path from interface to business logic to data storage in the form of a directed acyclic graph (DAG). This skeleton is written to the `model_skeleton` table in SQLite, containing a list of nodes and a list of expected edges. The lineage tracing and logic extraction agent reads this at startup. The skeleton serves as a "roadmap" for tracing, prioritizing the verification of expected call relationships and supplementing the actual field flow details. This preferred embodiment significantly improves the efficiency and accuracy of parsing. By loading project-level development specifications, the system can automatically filter out approximately 30% to 50% of non-core code (such as unit tests, configuration files, and automatically generated code), reducing unnecessary LLM calls and shortening parsing time by approximately 40%. Simultaneously, the system model skeleton generated based on the specifications provides prior knowledge for subsequent lineage tracing. For example, if the specifications stipulate that all data access must go through the DAO layer, then the agent does not need to analyze the SQL statements directly written in the Service layer during tracing, thereby reducing the complexity of reasoning and the possibility of LLM illusions. This "specification-driven" parsing approach allows the system of this invention to adapt to different enterprise architecture styles, exhibiting good versatility and configurability.

[0042] In a preferred embodiment, in step S120, the lineage tracing and logic extraction agent is configured to monitor the state of a lightweight local relational database, receive identified interface entities, and reverse-trace the code flow using a large language model's thought chain strategy. During deep tracing across microservice components, classes, and methods, the generated intermediate inference results are frequently written to the mounted lightweight local relational database so that execution can continue from the last inference node if parsing is interrupted. In this preferred embodiment, the lineage tracing and logic extraction agent internally maintains a state machine. When starting to trace a field, the state machine enters the "initialization" state and reads the starting node (e.g., the return value field of an API) from the SQLite's model_skeleton table. Then it enters the "method call analysis" state, where the agent reads the bytecode or AST of the current method and identifies all method call statements. If the call is a local method (another class within the same service), the agent recursively enters the method and writes the current stack frame information (method name, line number, local variable table) to the SQLite's call_stack table. If the call is to a remote method (via an RPC client), the agent records a cross-service boundary and sets the tracing task's status to "waiting for remote service resolution." A dedicated `remote_waiting_list` table in SQLite records the source service, target service, fields to be traced, and currently traced intermediate results. When the target service's resolution task is completed, the corresponding lineage tracing and logic extraction agent updates this table, waking up the waiting task. During the tracing process, after analyzing each method, the agent serializes its intermediate inference results (e.g., "variable X is assigned a value in method A, whose value is the return value of method B") into JSON and writes it to the `inference_result` table in SQLite. This preferred embodiment implements complex link tracing across microservice boundaries. In a typical microservice architecture, a business request often involves 3 to 5 or even more service calls. Existing technologies cannot automatically perform field-level tracing across service boundaries, while this invention achieves distributed tracing task coordination through the `remote_waiting_list` table in SQLite and a state machine mechanism. When one service depends on the resolution result of another service, the task can be gracefully suspended and automatically resumed after the dependency is satisfied. This design avoids circular waits and deadlocks, enabling the system to fully reconstruct the entire lineage of a field from the source database to the final API response. Simultaneously, writing intermediate inference results to the local database at high frequency ensures that in long-chain tracing (e.g., spanning more than 10 method calls), even if an intermediate LLM call fails, only the current step needs to be retried, without needing to reanalyze the entire chain, significantly improving the success rate and efficiency of tracing.

[0043] In a preferred embodiment, step S120 further includes: a dynamic-static cross-validation and self-correction step: constructing a verification agent, acquiring distributed call chain log data of the target microservice runtime, performing graph comparison between the link tracing log data and preliminary static lineage data, identifying dynamic call chains that were missed or misjudged in static analysis, constructing inconsistent call contexts as error correction prompts and feeding them back to the multi-agent collaborative system, and performing secondary deduction and self-correction of the thought chain to generate cross-validated structured lineage data and system model data. In this preferred embodiment, the verification agent pulls the distributed call chain log of the target microservice by integrating an APM probe (such as SkyWalking), extracting the RPC call order, method signature, and branch hit status during actual runtime. It compares the nodes and edges of the dynamic links with the preliminary lineage graph generated by static analysis, and uses a graph similarity algorithm to identify call relationships that were missed or misjudged in static analysis, such as implicit calls injected by Spring AOP proxies or branches caused by conditional routing. For identified inconsistencies, the call context (including actual input parameter types, return values, and exception stack traces) is extracted to construct structured error correction prompts, which are then fed back to the master control agent. The master control agent triggers the lineage tracing and logic extraction agents to perform a second deduction of the thought chain, forcing a re-analysis of relevant code snippets and correcting previously misjudged or omitted logic, generating cross-validated structured data. This solution solves the problem that static analysis cannot perceive runtime characteristics such as dynamic proxies and reflection calls, improving the accuracy of lineage resolution from approximately 75% to over 95%, achieving production-grade usability. Simultaneously, continuous integration of dynamic logs allows the verification loop to automatically evolve with online traffic, becoming increasingly accurate over time, significantly suppressing the illusion of a large model, and providing a highly reliable data foundation for the architectural governance of critical business systems.

[0044] In a preferred embodiment, in step S140, the step of persisting the edge relationship between the service node and the field flow to the graph database, only directed edges from the interface node to the database node are established in the graph database to store the topology path. Simultaneously, detailed natural language logical text is recorded in the relational database, and the two are mapped through globally unique attribute identifiers. In this preferred embodiment, the data persistence layer includes an intelligent routing module. After receiving a message from Kafka, this module first parses the edge_type field in the message. If edge_type is a topology relationship such as "RPC_CALL" or "DB_WRITE", the graph database driver is invoked, and parameterized nGQL statements (e.g., INSERT EDGEdepends_on (type, edge_id) VALUES "src_uuid"->"dst_uuid":("RPC_CALL", "edge_12345")) are written to NebulaGraph. If `edge_type` is "LOGIC_DESC", the JDBC driver is invoked to execute `INSERTINTO edge_details (edge_id, logic_description, source_snippet) VALUES (?, ?, ?)` to write the natural language logical description to MySQL. To ensure consistency between the two writes, this intelligent routing module adopts a "write to graph database first, then write to relational database" strategy and records operation logs. If the relational database write fails, the system writes the failure message to a dead letter queue, and a separate compensation task retryes periodically. Simultaneously, the system maintains a global ID generator (such as the snowflake algorithm) to ensure that each newly created edge and node has a unique UUID, which serves as both the attribute value of the edge in the graph database and a foreign key in the relational database. This preferred embodiment solves the technical challenge of a single database type not being able to simultaneously achieve graph query performance and text storage capabilities through a hybrid storage strategy. Pure graph database solutions experience a 5-10x increase in query latency when storing thousands of long texts (100-500 characters each), because graph database storage engines are not optimized for variable-length text. Pure relational database solutions, when querying service dependencies at three or more levels, require complex recursive SQL or multiple JOIN operations, potentially resulting in response times exceeding 10 seconds at a scale of millions of nodes. This invention stores the topology in NebulaGraph, enabling the complete downstream dependency chain of the query service to be returned within 50 milliseconds; simultaneously, it stores long texts in MySQL, supporting efficient fuzzy search and full-text retrieval.The two are linked by edge_id, which allows the neighbor nodes to be quickly retrieved from the graph database and the logical description to be quickly retrieved from the relational database when clicking on the connection in the visualization interface, achieving a perfect balance between performance and functionality.

[0045] In a preferred embodiment, step S140 further includes: an incremental file difference triggering mechanism based on continuous integration pipeline or code repository Webhook monitoring. When code changes, the multi-agent collaborative system only extracts the difference context for incremental parsing, achieving partial hot updates of relational databases and graph databases. In this preferred embodiment, the system registers a Webhook in the code repository (such as GitLab or GitHub) to monitor push and merge events. When a new code commit occurs, the Webhook sends a payload to the system of this invention, which includes the commit hash, a list of changed files, and the code differences (diff) before and after the change. After receiving the payload, the triggering layer calls a difference analysis service. This service parses the diff content and distinguishes between newly added, modified, and deleted files. For modified files, it further extracts the specific methods or classes that have changed. Then, the master agent creates an incremental parsing task, which only contains the path of the changed files and the location information of the changed methods. The agent system then only re-parses these changed code units. For example, if only the `calculateDiscount` method in `OrderServiceImpl.java` is modified, only the lineage edges and logical descriptions related to that method will be recalculated. After parsing, the system generates an update event and sends it to Kafka. The data persistence layer consumes this event, first deleting old records related to the covered edge ID in the graph database and relational database, and then inserting the newly generated record, thus achieving atomic local hot updates. This preferred embodiment completely solves the industry problem of traditional architecture documents becoming "expired as soon as they are written." In existing technologies, every code change requires triggering a complete full analysis, which is unacceptable in microservice architectures because a single full analysis can consume hours of computing resources and hundreds of dollars in LLM API call fees. Through an incremental parsing mechanism based on file differences, this invention reduces the model update time triggered by a single code commit to 10 seconds to 2 minutes, and reduces the LLM call cost to less than 1% of that of a full analysis. This ensures that the system model can maintain near real-time synchronization with the code, like a CI / CD pipeline. Architects can view the lineage graph reflecting the latest online code status at any time, and change impact analysis can be completed based on the latest model before code merging, thus truly integrating microservice governance into the development process and achieving the ideal state of "what you write is what you get, and what you get is what you see".

[0046] The key technical features of the present invention will be described in detail below through several specific embodiments.

[0047] Example 1: Implementation of Multi-Agent Cooperation and State Synchronization

[0048] refer to Figure 2 In the multi-agent parsing layer based on a large language model, the system adopts a distributed architecture deployment. When the code access and triggering layer detects a code change event, the master control scheduling agent receives the parsing task, loads the project-level development specification configuration file, and breaks the task down into multiple sub-tasks.

[0049] During the task initialization phase, the master agent retrieves the project-level development specifications from the configuration center. This specification is a structured document that defines rules such as all controller classes must be located in a specified package, service layer methods must begin with a specific prefix, and data access object layer entity classes must be annotated with specific annotations. The master agent embeds these rules into the instructions distributed to other agents, ensuring that the parsing process follows the project-specific architectural conventions, thus improving the accuracy and efficiency of parsing.

[0050] The interface and metadata scanning agent first autonomously invokes static code scanning tools, such as JavaParser for Java or the ast module for Python, to accurately extract the external interfaces of the controller layer and the entity class mappings of the data access object layer. When invoking the abstract syntax tree parser, the scanning agent prioritizes scanning classes and methods that conform to project development specifications, ignoring test code and automatically generated code, thus narrowing the scan scope. After extracting the controller layer interfaces and data access object layer entities, the scanning agent generates a system model skeleton, which describes the expected call path from interface to business logic to data storage in the form of a directed acyclic graph. This skeleton is written to the model skeleton table in the lightweight local relational database SQLite, containing a list of nodes and a list of expected edges, and marked as scan complete.

[0051] Subsequently, the lineage tracing and logic extraction agent monitors the task status table in a lightweight local relational database. Upon detecting that the target service's model skeleton data is ready, it immediately begins its work. The lineage tracing and logic extraction agent receives the identified interface entities and uses a large language model's thought chain strategy to reverse-trace the code flow. Each agent mounts an SQLite database file locally upon startup, which is stored in a persistent volume. During task execution, the agent writes the intermediate state of each key step to the agent status table in SQLite. This table's structure includes: a global task identifier, agent identifier, step name, step input parameter hash, step output result summary, detailed state data in JSON format, and creation and update timestamps.

[0052] The key difference from existing technologies lies in the high-frequency writing of numerous intermediate inference results generated during deep tracing across microservice components, classes, and methods to a mounted lightweight local relational database. These intermediate inference results include variable data type conversion records and code tracing nodes. Once the agent completes the analysis of a method, it immediately updates the corresponding record's step output and checkpoint data fields. If an application programming interface call times out or the parsing container restarts, the agent can directly read the last inference node from the lightweight local relational database to continue execution, thus enabling breakpoint resumption for complex tasks. When the master agent detects that a task is incomplete, it passes the same global task identifier to the new instance upon restarting. The new instance first queries the last valid record corresponding to this global task identifier in SQLite, reads the status from the checkpoint data, and resumes execution from the point of interruption without starting from scratch.

[0053] This design endows the system with industrial-grade fault tolerance. In a real-world production environment, performing a full analysis of a large microservice codebase containing tens of thousands of source files can take several hours. Without a mechanism for resuming interrupted downloads, any unexpected service restart will result in the loss of all work, with a task success rate typically below 50%. By introducing lightweight state persistence based on SQLite, this invention improves the task success rate to over 99%. Compared to using external storage such as Redis, SQLite, as an embedded database, requires no additional network overhead or operational costs, and its ACID properties guarantee the atomicity of state writes, avoiding state inconsistency issues. Furthermore, this mechanism supports proactive task pause and resumption, allowing the system to execute parsing tasks during off-peak hours, significantly improving resource utilization efficiency.

[0054] Example 2: Business Semantic Dimensionality Reduction and Dual-Database Persistence

[0055] When the lineage tracing and logic extraction agent traces a method containing complex business logic, it does not directly send the entire method body code to the large language model. Instead, the agent first uses a code parsing tool to break down the method body into multiple basic blocks, such as variable declaration blocks, conditional statement blocks, loop blocks, assignment blocks, and return blocks.

[0056] Then, following the order of the control flow graph, the agent submits code snippets for each basic block along with a carefully designed few-sample cue word template to the large language model. This cue word template contains multiple examples to guide the large language model in converting conditional statements and arithmetic operation code snippets into natural language descriptions. For example, the cue word template might contain code snippets like "if (amount > 500) { total = amount The expression "0.9;}" is transformed into the example "If the order amount is greater than 500 yuan, then a 10% discount will be applied". The large language model returns a single natural language description for each basic block.

[0057] Finally, the agent concatenates these descriptions according to the control flow order and merges them into a coherent, highly generalized logical statement using another call to the large language model. For example, for the code related to order amount calculation, the large language model generates the following description: "The system first checks the order amount: if the amount exceeds 500 yuan, a 10% discount is automatically applied; otherwise, the original price is applied."

[0058] The parsed results are assembled into a JSON object and sent to the message middleware in the asynchronous message dispatch layer. The lineage collection service in the data collection and persistence layer consumes this message. Considering that existing graph databases are not adept at storing large amounts of long text, this embodiment employs a hybrid storage strategy.

[0059] In a graph database, only directed edges from interface nodes to database nodes are created to store topological paths. For example, an order service application programming interface node and a database table node are created in the graph database, and then a directed edge is created from the application programming interface node to the database table node. This edge contains basic topological information such as the edge type and a globally unique edge identifier, but does not store long text content.

[0060] Simultaneously, detailed natural language logical text is recorded in the relational database. An edge details table is created in the relational database, with a structure including edge identifier, logical description field, source code fragment field, and creation time field. For each edge created in the graph database, a record is inserted into the edge details table in the relational database, storing the natural language description in the logical description field and optionally storing the relevant code fragment in the source code fragment field for auditing purposes.

[0061] The two are mapped through a globally unique attribute identifier. The system maintains a global identifier generator to ensure that each newly created edge and node has a unique, universally unique identifier. This universally unique identifier serves as both the attribute value of the edge in the graph database and the foreign key in the relational database. Thus, during visualization queries, topological neighbor node information can be retrieved from the graph database using the edge identifier, while a detailed business logic description can be obtained from the relational database.

[0062] Finally, at the presentation layer, when business users click on the connection between nodes in the graph on the visualization frontend, the frontend system captures the click event, obtains the edge identifier corresponding to the connection, and initiates a query request to the backend application programming interface (API). The backend API queries the edge details table in the relational database and returns the content of the logical description field. The frontend displays this natural language description in a sidebar or pop-up. Thus, the business logic, originally hidden in complex code and cross-service calls, is clearly presented in plain language that business users can fully understand.

[0063] This embodiment achieves a crucial leap from code syntax to business semantics. Traditional static analysis tools can only output low-level information such as "implementation class .java: line X calls client .method()", which is of no value to business users. However, the natural language description generated by this invention, such as "querying product prices in the inventory service," allows non-technical personnel to directly understand the system's business logic. This semantic dimensionality reduction capability extends microservice governance from the technical domain to the business domain, enabling business personnel to participate in architecture reviews, impact analyses, and compliance verification, significantly reducing cross-role communication costs.

[0064] Example 3: Dynamic-Static Cross-Validation Closed Loop

[0065] Continue to refer to Figure 2 After static inference is completed, the initial lineage data generated may be biased due to the dynamic characteristics of microservices. For example, based on the dynamic proxy and dependency injection mechanism of the Spring framework, many actual call relationships do not exist explicitly in the static code, but are dynamically determined by the framework at runtime. Static scanning and large language model static analysis cannot accurately identify these implicit calls.

[0066] To address this issue, this invention constructs a verification agent. The verification agent pulls real dynamic link tracing logs of the target service over a past period from an external application performance monitoring probe system for comparison. Application performance monitoring probe systems, such as SkyWalking, Pinpoint, or Jaeger, automatically collect the complete call chain for each request by deploying probes in microservice instances, including information such as the method signature, execution time, and status of each cross-service call.

[0067] The validating agent performs a graph comparison between the acquired dynamic link tracing log data and the preliminary static lineage data generated by the multi-agent collaborative system. Specifically, the validating agent converts the call relationships in the dynamic link tracing log into a temporary graph structure and matches nodes and edges with the lineage graph generated by static analysis. The comparison algorithm identifies two types of differences: the first type is call links missed by static analysis, i.e., edges that exist in the dynamic log but not in the static graph; the second type is call links that are misjudged by static analysis, i.e., edges that exist in the static graph but not in the dynamic log.

[0068] For the identified discrepancies, the verification agent focuses on handling dynamic call chains that were missed or misjudged by static analysis. For example, the comparison revealed frequent calls to the dynamic proxy class for the discount activity in the actual chain, while the static large language model analysis failed to identify this implicit call due to dependency injection configuration. The verification agent extracts the method signature and context of the dynamic call and constructs a prompt word containing error correction instructions to feed back to the multi-agent collaborative system.

[0069] The error correction message includes the following: First, it indicates that the current static analysis has omissions and requires supplementary analysis; second, it provides detailed information about the actual call chain observed in the dynamic logs, including the caller method, the callee method, the call parameter types, and the return value type; third, it suggests possible dynamic mechanisms, such as Spring AOP proxies, dependency injection, or conditional annotations. This error correction message is fed back to the master agent, which then assigns the error correction task to the lineage tracing agent.

[0070] Guided by error-correction prompts, the lineage-tracing agent performs a second, deeper logical deduction. The agent re-analyzes relevant code, focusing on configuration files and annotations related to dynamic proxies, accurately reconstructing the business paths hidden by the dynamic proxies. The agent integrates the newly discovered call relationships into the final parsing result, generating cross-validated structured lineage data and system model data.

[0071] Compared to purely statically parsed data, cross-validated data shows a significant improvement in accuracy. For a typical microservice system using the Spring framework, the accuracy of purely static parsing is approximately 70% to 80%, with the main omissions being implicit calls related to dynamic proxies and dependency injection. After closed-loop correction through cross-validation of static and dynamic data, the accuracy can be improved to over 95%, reaching a production-ready level.

[0072] This embodiment establishes a closed-loop self-correction mechanism between static large-model inference and dynamic runtime links. This mechanism can not only detect omissions in static analysis, but also verify the correctness of the large language model inference results through dynamic truth verification, effectively suppressing the illusion problem of large language models. Simultaneously, as the system runtime increases, the dynamic log data accumulated by the verification agent grows, covering more business scenarios and call paths, resulting in a continuous improvement in the accuracy of the parsing results over time.

[0073] Figure 3 This is a system architecture diagram of the browser connector service in the multi-agent microservice model construction system of this invention. (See diagram below.) Figure 3 As shown, the multi-agent microservice model construction system 5 of the present invention includes: The microservice parsing module 51 abstracts the target microservice system into a topology that includes input interfaces, business processing entities, storage entities, and output interfaces.

[0074] System generation module 52 starts a multi-agent collaborative system based on a large language model to parse the code library of the target microservice. The multi-agent collaborative system extracts the source mapping relationship of each field and the corresponding business processing logic by calling the code parsing tool and combining the thinking chain reasoning, and generates structured lineage data and system model data. The multi-agent collaborative system includes at least a master intelligent agent, an interface and metadata scanning intelligent agent, and a lineage tracing and logic extraction intelligent agent.

[0075] The message passing module 53 sends the lineage data and system model data to the message middleware.

[0076] The database update module 54 asynchronously collects data from the service consumption message middleware, persists the text containing field processing logic to the relational database, and persists the edge relationship between service nodes and field flow to the graph database.

[0077] In summary, the multi-agent microservice model construction system of the present invention can overcome the context overload and illusion problems when a single model processes a large codebase by splitting multi-agent tasks and synchronizing lightweight local library states, giving the system the ability to resume interrupted downloads, and converting complex code logic into natural language business semantics, thus realizing the transparency and real-time synchronization of technical assets and business logic.

[0078] This invention also provides a multi-agent microservice model building device, including a processor and a memory storing executable instructions for the processor. The processor is configured to execute steps of a multi-agent microservice model building method by executing the executable instructions.

[0079] As shown above, the multi-agent microservice model building device of this invention can overcome the context overload and illusion problems when a single model processes a large codebase by splitting multi-agent tasks and synchronizing the state of a lightweight local library. It gives the system the ability to resume interrupted downloads and converts complex code logic into natural language business semantics, realizing the transparency and real-time synchronization of technical assets and business logic.

[0080] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "platform."

[0081] Figure 4 This is a schematic diagram of the structure of the multi-agent microservice model construction device of the present invention. See below for reference. Figure 4 To describe an electronic device 600 according to this embodiment of the present invention. Figure 4 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0082] like Figure 4 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different platform components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0083] The storage unit stores program code, which can be executed by the processing unit 610 to perform the steps described in the method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 610 can perform actions such as... Figure 1 The steps are shown in the figure.

[0084] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include read-only memory (ROM) 6203.

[0085] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0086] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0087] Electronic device 600 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms.

[0088] This invention also provides a computer-readable storage medium for storing a program, which, when executed, implements the steps of a method for constructing a multi-agent microservice model. In some possible implementations, various aspects of this invention can also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the above-described method section of this specification according to various exemplary embodiments of the invention.

[0089] As shown above, the multi-agent microservice model construction system of this invention in this embodiment can overcome the context overload and illusion problems when a single model processes a large codebase by splitting multi-agent tasks and synchronizing the state of a lightweight local library. It gives the system the ability to resume interrupted downloads and converts complex code logic into natural language business semantics, realizing the transparency and real-time synchronization of technical assets and business logic.

[0090] Figure 5 This is a schematic diagram of the structure of the computer-readable storage medium of the present invention. (Reference) Figure 5As shown, a program product 800 for implementing the above-described method according to an embodiment of the present invention is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0091] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0092] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0093] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0094] In summary, the purpose of this invention is to provide a method, system, device, and storage medium for constructing a multi-agent microservice model. By splitting multi-agent tasks and synchronizing lightweight local library states, it overcomes the context overload and illusion problems when a single model processes a large codebase, endows the system with the ability to resume interrupted downloads, and converts complex code logic into natural language business semantics, thereby achieving transparency and real-time synchronization of technical assets and business logic.

[0095] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for constructing a multi-agent microservice model, characterized in that, Includes the following steps: S110. Abstract the target microservice system into a topology that includes input interfaces, business processing entities, storage entities, and output interfaces; S120. Start a multi-agent collaborative system based on a large language model to parse the code library of the target microservice. The multi-agent collaborative system extracts the source mapping relationship of each field and the corresponding business processing logic by calling the code parsing tool and combining the thinking chain reasoning, and generates structured lineage data and system model data. The multi-agent collaborative system includes at least a master control agent, an interface and metadata scanning agent, and a lineage tracing and logic extraction agent. S130. Send the bloodline data and system model data to the message middleware; as well as S140. The asynchronous collection service consumes the data in the message middleware, persists the text containing field processing logic to a relational database, and persists the edge relationship between the service node and the field flow to a graph database.

2. The method for constructing a multi-agent microservice model as described in claim 1, characterized in that, Step S120 further includes: The multi-agent collaborative system performs deep link tracing. Multiple agents persist intermediate inference states and synchronize progress by mounting a lightweight local relational database to enable breakpoint resumption of parsing tasks. The lightweight local relational database is SQLite, and the intermediate inference states include variable data type conversion records and code link tracing nodes.

3. The method for constructing a multi-agent microservice model as described in claim 1, characterized in that, In step S120, the business processing logic is extracted as follows: based on the semantic understanding capability of the large language model, code snippets containing conditional branches and data transformation operations are summarized into highly generalized natural language logic descriptions; and the natural language logic descriptions are attached as attributes to the edge relationships of field flow stored in the graph database.

4. The method for constructing a multi-agent microservice model as described in claim 1, characterized in that, In step S120, the main control agent is configured to issue parsing rules and tasks and load project-level development specifications; the interface and metadata scanning agent is configured to call a static code scanning tool to identify and extract the external interfaces of the controller layer and the entity class mapping of the data access object layer to determine the boundaries of the input interface, storage entity and output interface, and write the generated system model skeleton data into a lightweight local relational database. The lineage tracing and logic extraction agent is configured to monitor the status of the lightweight local relational database, receive the identified interface entities, and use the thinking chain strategy of the large language model to reverse trace the code flow. During deep tracing across microservice components, classes, and methods, the resulting intermediate inference results are frequently written to the mounted lightweight local relational database to resume execution from the last inference node in the event of a parsing interruption.

5. The method for constructing a multi-agent microservice model as described in claim 2, characterized in that, Step S120 further includes: dynamic and static cross-validation and self-correction steps: constructing a verification agent, obtaining distributed call chain log data during the runtime of the target microservice, performing graph comparison between the link tracing log data and the preliminary static lineage data, identifying dynamic call chains that were missed or misjudged in the static analysis, constructing inconsistent call contexts as error correction prompts and feeding them back to the multi-agent collaborative system, and performing secondary deduction and self-correction of the thought chain to generate cross-validated structured lineage data and system model data.

6. The method for constructing a multi-agent microservice model as described in claim 1, characterized in that, In step S140, the step of persisting the edge relationship between the service node and the field flow to the graph database involves establishing directed edges from the interface node to the database node in the graph database to store the topological path. At the same time, detailed natural language logical text is recorded in the relational database, and the two are mapped through globally unique attribute identifiers.

7. The method for constructing a multi-agent microservice model as described in claim 1, characterized in that, Step S140 further includes: Based on the incremental file difference triggering mechanism of continuous integration pipeline or code repository webhook monitoring, when the code changes, the multi-agent collaboration system only extracts the difference context for incremental parsing, realizing local hot updates of the relational database and the graph database.

8. A multi-agent microservice model construction system, used to implement the method according to any one of claims 1 to 7, characterized in that, include: The microservice parsing module abstracts the target microservice system into a topology that includes input interfaces, business processing entities, storage entities, and output interfaces. The system generation module starts a multi-agent collaborative system built on a large language model to parse the code library of the target microservice. The multi-agent collaborative system extracts the source mapping relationship of each field and the corresponding business processing logic by calling the code parsing tool and combining the thinking chain reasoning, and generates structured lineage data and system model data. The multi-agent collaborative system includes at least a master control agent, an interface and metadata scanning agent, and a lineage tracing and logic extraction agent. The message passing module sends the lineage data and system model data to the message middleware; and The database update module asynchronously collects data from the message middleware consumed by the service, persists the text containing field processing logic to a relational database, and persists the edge relationships between service nodes and field flows to a graph database.

9. A device for constructing a multi-agent microservice model, characterized in that, include: processor; A memory in which executable instructions of the processor are stored; The processor is configured to perform the steps of the multi-agent microservice model construction method according to any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium for storing a program, characterized in that, When the program is executed by the processor, it implements the steps of the multi-agent microservice model construction method according to any one of claims 1 to 7.

Images