Version control knowledge base-based internal and external network isolation large model collaborative operation system and method

Abstract

The application discloses an internal and external network isolation large model cooperative operation and maintenance system and method based on a version control knowledge base, which comprises an external network service domain, a knowledge base communication layer and an internal network research and development domain; the external network service domain receives a fault problem submitted by a user, and performs first-level routing query by using an external large model and a local knowledge base; the knowledge base communication layer takes a GitLab knowledge base warehouse as a unique data communication hub across domains, and realizes internal and external network isolation and asynchronous flow through warehouse-level access control; the internal network research and development domain triggers a second-level penetration path when the first-level query is not hit, independently locates and analyzes internal network source code by a code analysis intelligent agent, and automatically verifies a repair scheme in a modification verification environment through a containerized sandbox, and after verification, automatically deposits into a desensitization knowledge document and synchronously updates to the external network. While ensuring the safety of the core source code of an enterprise, the application realizes real-time self-evolution of operation and maintenance knowledge and optimization of operation and maintenance cost.

Description

Technical Field

[0001] This invention relates to the field of software operation and maintenance and fault diagnosis technology, and in particular to a collaborative operation and maintenance system and method for a large-scale model of internal and external network isolation based on version control knowledge base. Background Technology

[0002] With the rapid increase in the complexity of enterprise software systems, software fault diagnosis and troubleshooting have become core challenges in the fields of technical support and operations and maintenance. In recent years, the rapid development of Large Language Model (LLM) technology has provided a new technical path for intelligent fault diagnosis, and various intelligent operations and maintenance solutions based on large models have emerged. However, in the operations and maintenance scenarios of software products for B-end (Business) enterprise customers, existing technical solutions generally suffer from a fundamental contradiction between source code security and intelligent analysis capabilities. In-depth code analysis requires access to the enterprise's core source code, while uploading the source code to the cloud or an environment accessible by the internet will bring serious data leakage and intellectual property risks.

[0003] Specifically, the existing technical solutions have the following technical defects: (1) Source code security risks: Existing solutions usually require uploading the source code to a cloud-based large model for analysis, or directly loading the source code in an environment with internet access, which exposes the enterprise's core source code to the external network environment, posing serious risks of data leakage and intellectual property infringement, making it difficult to meet the requirements of B-end enterprise customers for source code confidentiality and compliance.

[0004] (2) Waste of computing power and cost: The existing solution initiates a complete code-level in-depth analysis process for each customer problem, calling high-cost large model APIs or high-computing-power inference resources. Actual operation and maintenance data shows that more than 80% of customer problems are repeated inquiries about known problems or similar problems. Performing a complete code analysis for each inquiry results in a large amount of unnecessary API call overhead and consumption of computing resources.

[0005] (3) High maintenance cost of knowledge base: In the existing technical solutions, the content update of the technical support knowledge base relies on manual writing and input. As the software version is iterated and customer problems accumulate, the coverage of the knowledge base gradually decreases, resulting in a continuous decrease in the hit rate of knowledge base query, and more problems are forced to enter the high-cost in-depth analysis process.

[0006] (4) Lack of repair verification loop: In the existing schemes, the repair schemes generated by the large model are usually directly output to manual review, lacking automated compilation, testing and regression verification links, and cannot confirm the correctness and feasibility of the scheme before output.

[0007] (5) Rigid internal and external network collaboration mechanism: In the scenario of internal and external network isolation, the existing solutions usually rely on manual information transmission or use heavy-duty physical isolation gateway devices, which have high deployment costs and low communication efficiency. They lack a lightweight, version traceable, and asynchronous collaboration cross-domain communication mechanism, making it difficult to ensure security while taking into account the efficiency of operation and maintenance response.

[0008] In existing related patent technologies: The patent with publication number CN118365311A proposes an intelligent operation and maintenance management system, server and method based on a large language model. It uses the KNN algorithm for fault identification and isolated forest for fault prediction. However, this solution uses a single model to be deployed in a single network environment. It has neither an internal nor external network isolation architecture nor source code-level code analysis capabilities. Moreover, the knowledge base is statically constructed and lacks an automatic evolution mechanism.

[0009] The patent with publication number CN117610667B proposes a fault handling expert system, method and computer equipment based on an open source large model. It identifies alarms and generates handling actions through two-stage reasoning. However, this solution only handles alarm-level operation and maintenance events and cannot go deep into the code level to perform root cause analysis and generate repair solutions. Moreover, knowledge improvement relies on manual interaction to correct training data and lacks automated knowledge accumulation capabilities.

[0010] The patent with publication number CN119065917A proposes a method, device and equipment for operation and maintenance alarm analysis based on a large language model. It uses a model finely tuned by RLHF to classify alarms and combines a vector database to match historical events. However, its knowledge base is updated in a monthly batch manner rather than in real-time self-evolution, and it does not involve code-level fault analysis and automatic verification of repair solutions.

[0011] The patent with publication number CN120492319B proposes a code error repair method and system based on a large model. It deploys multiple large programming models and verifies the correctness of the repair through playback in a test environment. It is the closest solution to the present invention in the prior art. However, this solution does not consider the risk of source code leakage caused by the internal and external network isolation architecture, and lacks knowledge base accumulation and self-evolution mechanism. Each repair is an independent event, and it is impossible to transform historical repair experience into reusable knowledge assets.

[0012] The patent with publication number CN118193714B proposes a dynamic adaptive question-answering system and method based on hierarchical structure and retrieval enhancement, which has the ability to automatically update the knowledge graph and the knowledge evolution driven by feedback. However, this solution is a general question-answering system, which does not have the domain-specific ability to diagnose software faults, cannot perform source code analysis and generate repair solutions, and does not involve network security isolation architecture.

[0013] In summary, existing technologies lack a lightweight collaborative operation and maintenance method and system for software faults that can simultaneously ensure source code security protection, differentiated model collaboration, API call cost optimization, automatic verification of repair solutions, and automatic evolution of the knowledge base under an internal and external network isolation architecture. Summary of the Invention

[0014] To address the shortcomings of existing technologies, the present invention aims to provide a collaborative operation and maintenance method and system for a large-scale model of internal and external network isolation based on a version control knowledge base.

[0015] To achieve the objectives of this invention, the technical solution adopted is as follows: A collaborative operation and maintenance system for a large-scale model of internal and external network isolation based on a version control knowledge base includes: The external service domain, deployed in a managed cloud or isolated zone, is used to receive software fault issues submitted by users and to perform first-level hierarchical routing queries based on a de-identified Markdown knowledge base by calling external large language models and local knowledge base index services. The knowledge base communication layer is deployed on the enterprise GitLab server. It uses the GitLab knowledge base repository as the only data communication hub between the internal and external networks. It isolates access between the internal and external networks through a repository-level access control list and realizes asynchronous information flow across domains through issue tickets and version control submission mechanisms. The internal R&D domain is deployed within the enterprise's internal network. It is used to trigger a secondary penetration path when the primary query fails. The code analysis intelligence agent autonomously locates and analyzes the internal source code and automatically verifies the repair solution in the modification verification environment.

[0016] Furthermore, the external network service domain includes: External application server: hosts customer service front-end applications, index routing engine, and API gateway services; Customer Service Large Language Model API Interface: The external application server calls the external large language model through the API interface to complete intent recognition, keyword extraction, and natural language response generation based on the technical solution text, and the interface does not access any source code data; Knowledge Base Index Service: Running on an external application server, when the GitLab knowledge base repository is updated, it automatically scans Markdown knowledge documents through push or timed pull, parses metadata, and builds an inverted index based on tags and keywords and a full-text search index based on titles and abstracts; Anonymized Markdown Knowledge Base: Stored in GitLab Knowledge Base Repository in plain text format. Its documents use a unified template that includes a YAML header and a three-part body, and the content does not contain any source code snippets or sensitive path information. Index routing engine: running on the external application server, responsible for hierarchical routing determination based on the retrieval results of the knowledge base index service.

[0017] Furthermore, the knowledge base communication layer: Configure the external application server as a restricted access role for the GitLab knowledge base repository, granting it only permissions to pull knowledge documents and submit issue tickets, and prohibiting it from accessing other code repositories within the enterprise; configure the workstations in the internal R&D domain as full read-write roles, granting them permissions to push knowledge documents, update documents, and process issue tickets; the GitLab knowledge base repository automatically records a complete audit log containing the operator's identity, operation time, and changes.

[0018] Furthermore, the intranet R&D domain includes: Intranet code analysis workstation: Equipped with a GPU accelerator card, it is used to run code analysis agents, access code repository servers and modification verification environments through the intranet, and has full read and write permissions to the GitLab knowledge base repository; Code Analysis Agent: An interactive AI programming agent running on an intranet code analysis workstation, capable of multi-round autonomous reasoning, code reading and understanding, tool invocation, and iterative correction. The internal code repository server stores the company's full source code and version history. The code analysis agent accesses the code repository server by forcing read-only mounting at the operating system level through the read-only mount option of the Linux file system. Code indexing engine: A preprocessing module running on the code repository server, responsible for parsing the source code abstract syntax tree, constructing the symbol table, generating the function call graph, and constructing the code search index; The verification environment is modified to build an isolated compilation and testing sandbox based on containerization technology. It integrates automatic compilation and build tools, unit testing framework and regression testing suite to automatically verify the repair solutions generated by the code analysis agent, and feeds back the error information to the code analysis agent when the verification fails.

[0019] Furthermore, the system employs a differentiated dual-model strategy: On the external network side, a low-cost, pay-as-you-go external large language model API service is used to perform single-round reasoning, keyword extraction, and natural language response generation based on context. The internal network adopts an AI programming agent framework with long context windows and multi-round autonomous reasoning capabilities. It locates the root cause of the fault by autonomously planning and analyzing paths, performing multi-step reasoning, and repeatedly calling code search and file reading tools.

[0020] A collaborative operation and maintenance method for a large-scale internal and external network isolation model based on version control knowledge base includes the following steps: Step S1: The external application server receives the description of the software fault submitted by the user; Step S2: The external application server calls the external low-cost large language model API service to extract fault type tags, software module names, error codes and key technical terms from the problem description and combine them into structured query conditions. Step S3: The knowledge base indexing service performs a retrieval in the pre-built multi-level index based on the structured query conditions, and returns the candidate Markdown knowledge document with the highest score and its relevance score; Step S4: The index routing engine performs hierarchical routing determination. When the relevance score of the best matching document exceeds the preset threshold, it is determined as a first-level hit. Step S5: Read the complete content of the matched Markdown document and submit it to an external low-cost large model API. Combine the original question to generate the final response text and return it to the user.

[0021] Furthermore, in step S4, when the search result is empty or the relevance score of the best matching document is lower than a preset threshold, it is determined as a miss, triggering a secondary penetration path, including the following steps: Step S6: The index routing engine automatically removes sensitive fields from user questions and de-identifies them, then encapsulates them into a question ticket with category tags and priority markers, and submits it to the GitLab knowledge base repository; Step S7: The intranet code analysis workstation automatically detects and retrieves new issue tickets from the knowledge base repository through GitLab push notifications or a timed polling mechanism.

[0022] Furthermore, it also includes the autonomous analysis steps of the intranet intelligent agent: Step S8: The intranet code analysis workstation starts the code analysis agent and inputs the problem description in the work order into the agent. The agent autonomously plans the analysis path and determines the code area to be checked based on the problem description. Step S9: The code analysis agent calls the code indexing engine and narrows the candidate code range from the entire code repository to the relevant function or module level through abstract syntax tree query, symbol table matching and function call graph traversal; Step S10: The code analysis agent performs deep semantic analysis on the narrowed candidate code range, accurately locates the function or code segment where the root cause of the fault is located by executing multiple rounds of tool calls, and generates the corresponding code repair solution.

[0023] Furthermore, it also includes a sandbox iterative verification step: Step S11: Modify the code repair plan for the verification environment, and perform automatic compilation, unit testing and regression testing in the containerized isolated sandbox; if the verification fails, the failure result containing compilation error details or test assertion failure information is fed back to the code analysis agent, triggering it to re-analyze and generate an improvement plan, and return to step S10 to continue iterating until the verification passes or the preset maximum number of iterations is reached.

[0024] Furthermore, it also includes the steps of knowledge accumulation and self-evolution: Step S12: After verification, the code analysis agent encapsulates the analysis results into a standard Markdown knowledge document and performs desensitization verification during generation to ensure that it does not contain source code snippets, internal variable names or source file paths; Step S13: The intranet workstation submits the generated Markdown knowledge document to the GitLab knowledge repository via push, and at the same time replies with the anonymized solution summary in the corresponding issue ticket and changes the issue status to resolved. After the external application server detects the change in issue status, it replies with the solution to the user. Step S14: After receiving the repository push event notification, the knowledge base index service automatically pulls the latest submissions and re-parses the newly added or modified Markdown knowledge documents, incrementally updating the inverted index and full-text search index.

[0025] The beneficial effects of this invention are that, compared with the prior art, this invention divides the system into an external network service domain and an internal network development domain through GitLab repository-level permission management. The source code repository is completely invisible to the external network, and the external network can only access a dedicated knowledge base repository. The source code is always stored in the internal network code repository server and is only accessed by internal network agents in read-only mode, never leaving the internal network boundary. This invention blocks the path of source code leakage at the repository access control level.

[0026] This invention employs a differentiated dual-model strategy and a two-level routing hierarchical query mechanism. The external network uses a low-cost large model to handle repetitive / similar problems, while the internal network only activates a high-performance agent for a small number of requests that are not hit at the first level. This invention reduces the number of calls to the high-cost model and lowers the overall cost of calling the large model in the system.

[0027] This invention sets up a modification and verification environment based on containerization technology on the intranet. The repair scheme generated by the intelligent agent must undergo automatic compilation, unit testing and regression verification before output. If the verification fails, iterative correction is automatically triggered. The generation-verification-iteration closed loop of this invention ensures the correctness and feasibility of the repair scheme.

[0028] In this invention, after the code analysis agent completes fault analysis and passes verification, it automatically encapsulates the solution into a standard Markdown knowledge document and submits it to the GitLab knowledge base repository via `git push`. The knowledge base indexing service automatically and incrementally updates the index via Webhook notifications. This invention achieves real-time knowledge self-evolution driven by Git commits. New knowledge generated by each secondary query is automatically accumulated as primary query resources. The more the system is used, the higher the knowledge base coverage becomes, and each knowledge update has a complete Git version history that can be traced.

[0029] This invention employs a multi-round autonomous reasoning agent in the intranet, supporting autonomous planning of analysis paths, multiple tool calls, and iterative corrections. The agent mode can handle complex fault scenarios across files and modules.

[0030] The code indexing engine of this invention pre-constructs an AST index, symbol table, and function call graph for the source code. The agent can reduce the scope of a single code analysis to one-hundredth to one-thousandth of the entire codebase through index retrieval and AST analysis, thereby reducing the agent's context consumption and the number of API call tokens.

[0031] This invention uses a GitLab knowledge repository as the communication hub between internal and external networks. It achieves asynchronous issue flow through Issue tickets and synchronous knowledge updates through `git push / pull`. All cross-domain operations are automatically logged by GitLab with complete audit logs. This invention leverages the native mechanisms of version control systems to achieve lightweight, traceable, and asynchronous cross-domain collaboration, with low deployment costs and native support for change rollback. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the collaborative operation and maintenance system for a large-scale model of internal and external network isolation based on version control knowledge base as described in this invention; Figure 2 This is a flowchart of the collaborative operation and maintenance method for a large-scale model of internal and external network isolation based on version control knowledge base, as described in this invention. Detailed Implementation

[0033] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and should not be used to limit the scope of protection of this application.

[0034] The present invention describes a collaborative operation and maintenance system for large-scale models with internal and external network isolation based on a version control knowledge base. This system adopts a dual-domain architecture with internal and external network isolation, using a knowledge base repository hosted by the version control system (Git) as a cross-domain communication hub. It combines a differentiated collaborative mechanism between low-cost large-scale model API services on the external network and code analysis agents on the internal network, a knowledge retrieval engine based on lightweight text markup (Markdown) indexing, a modification verification sandbox, and an asynchronous collaboration process based on issue work orders. Under the premise of ensuring that the source code never leaves the internal network, it achieves efficient, intelligent, and verifiable fault diagnosis and continuous knowledge accumulation.

[0035] like Figure 1 As shown, the system of this invention is divided into three areas: the external network service domain, the knowledge base communication layer, and the internal network R&D domain.

[0036] The external service domain is deployed in a managed cloud or DMZ and includes the following components: (1) External application server: An application server deployed in a managed cloud or DMZ, which carries services such as customer service front-end applications, index routing engines and API gateways. This server does not run large model inference tasks, but calls external large language model services through API interfaces, and has low local computing resource requirements.

[0037] (2) Customer Service Large Language Model API Interface: The external application server calls external large language model services (such as DeepSeek series models) through a standard RESTful API interface to complete tasks such as user intent recognition, keyword extraction, and natural language response generation. This API interface adopts a pay-as-you-go (token) billing model, and the cost of a single call is only a fraction of that of high-end models. This interface does not access any source code data and only performs inference based on the anonymized technical solution text, thus eliminating the possibility of source code leakage from the input data level.

[0038] (3) Knowledge Base Indexing Service: This module, running on an external application server, automatically scans all Markdown knowledge documents in the knowledge base repository when an update occurs (receiving a Git push notification (Webhook) or detecting a new commit during a scheduled fetch). It parses the YAML metadata (including fields such as title, tags, keywords, and associated modules) and the main text content, constructing a multi-level index structure: the first level is an inverted index based on tags and keywords, and the second level is a full-text search index based on document titles and summaries. After index construction, the index is cached in memory, supporting millisecond-level multi-condition combined queries.

[0039] (4) Anonymized Markdown Knowledge Base: A collection of structured knowledge documents stored in the knowledge base repository in Markdown plain text format. Each knowledge document uses a unified template format, including a YAML header (recording metadata such as title, tags, keywords, creation time, and associated Issue number) and Markdown body (organized in a three-part structure of problem description - technical root cause - solution). All knowledge documents have been anonymized and do not contain sensitive information such as source code snippets, internal API interface addresses, and source file paths. The advantages of the Markdown plain text format are: it naturally supports Git version control, with complete diff records and commit history for each modification; it can be directly read and understood by large language models without format conversion; and it has a small file size and high efficiency in index building and full-text search.

[0040] (5) Index Routing Engine: A software module running on the external application server, responsible for hierarchical routing determination based on the retrieval results of the knowledge base index service. When a user submits a question, the index routing engine first calls the customer service big language model API interface to extract keywords and tags from the question, and then executes a multi-condition combined query in the knowledge base index service. If the candidate document set returned by the retrieval is not empty and the comprehensive relevance score of the best matching document exceeds the preset threshold (this threshold is determined by historical query log statistics optimization), it is determined to be a first-level hit, and the content of the matched Markdown document is handed over to the big language model to generate a response; if the retrieval result is empty or the relevance score is lower than the threshold, it is determined to be a miss, and the second-level query process is triggered.

[0041] The knowledge base communication layer (based on version control system access control) includes: (6) GitLab Knowledge Base Repository: A dedicated Git repository deployed on the enterprise's GitLab server, serving as the sole data communication hub between the internal and external networks. This repository stores all documents of the anonymized Markdown knowledge base and achieves access isolation between the internal and external networks through GitLab's fine-grained permission management mechanism: external application servers are configured with a restricted access role for this repository, having only the permission to pull knowledge documents and submit issue tickets, and cannot access other code repositories of the enterprise; workstations in the internal R&D domain have full read and write permissions for this repository, and can push new knowledge documents, update existing documents, and process issue tickets. Through GitLab's repository-level access control list (ACL) and project visibility configuration, this repository is set as the only repository accessible from the external network, strictly isolated from the enterprise's source code repository. All operations on this repository are automatically recorded by GitLab in complete audit logs (including operator identity, operation time, and Gitdiff of operation content), achieving full traceability. This repository also serves as a cross-domain communication function: the external network asynchronously transmits unresolved issues to the internal network by submitting Issues, and the internal network feeds back solutions to the external network by submitting knowledge documents and closing Issues, thus achieving secure, traceable, and asynchronous two-way information flow through the native mechanism of the version control system.

[0042] The internal R&D domain is deployed within the enterprise's internal network. Both the source code repository and production environment reside within this domain, which is not directly accessible from the external network. It includes the following components: (7) Intranet Code Analysis Workstation: A high-performance computing device deployed in the intranet R&D domain, equipped with a GPU accelerator card, used to run code analysis agents. This workstation accesses the code repository server and modification verification environment through the intranet, and also has full read and write permissions to the GitLab knowledge base repository.

[0043] (8) Code Analysis Agent: An interactive AI programming agent running on an intranet code analysis workstation, possessing multi-round autonomous reasoning, code reading and understanding, tool invocation, and iterative correction capabilities. Employing an interactive programming agent framework based on a large language model (such as Claude Code), this type of agent can autonomously plan analysis steps, invoke code search and file reading tools, progressively delve into the root causes of problems through multi-round dialogues, and automatically iteratively correct its analysis conclusions and repair solutions based on verification feedback. Compared to traditional single-round large model API calls, the agent mode supports a long context window of up to 1M tokens, enabling it to handle complex fault analysis tasks across files and modules. The code analysis agent accesses the code repository server in read-only mode, ensuring that no unauthorized modifications are made to the source code.

[0044] (9) Internal Code Repository Server: A server running the Git version control system, storing the company's full source code and version history. The code analysis agent accesses the code repository through a read-only mount, having only read permissions. This read-only constraint is enforced at the operating system level through the Linux file system's read-only mount (mount-ro) option. This server is a different repository instance from the GitLab knowledge base repository, and the source code repository is completely invisible to the external network.

[0045] (10) Code Indexing Engine: A preprocessing module running on the code repository server, responsible for abstract syntax tree (AST) parsing, symbol table construction, function call graph generation, and code search index construction of the source code. AST parsing uses a multi-language parser (tree-sitter) that supports mainstream programming languages ​​such as C / C++, Python, Java, and Rust. The pre-built index structure of the code indexing engine allows the agent to quickly narrow down the candidate range to the relevant function or module level without traversing the entire codebase when analyzing specific problems.

[0046] (11) Modify the verification environment: Deploy an independent sandbox or CI / CD pipeline environment in the intranet R&D domain to automatically verify the fixes generated by the code analysis agent. This environment is built on containerization technology (Docker / Podman) to create an isolated compilation and testing environment, including automatic compilation and build tools (such as CMake, Bazel), unit testing frameworks (such as Google Test, pytest), and regression test suites. When verification fails, the verification results (compilation error information, test failure details, code coverage report) will be fed back to the code analysis agent, triggering the next round of analysis-fix-verification iteration loop until verification passes or the maximum number of iterations is reached.

[0047] like Figure 2 As shown, the collaborative operation and maintenance method for a large-scale model of internal and external network isolation based on version control knowledge base described in this invention includes the following steps: Step S1: Users submit a description of software malfunction to the external application server through the client terminal (Web interface, instant messaging customer service group or API interface). The description of the problem supports multiple input formats such as natural language text, error log fragments and screenshots. Step S2: The external application server calls an external low-cost large-scale model service through the customer service large language model API interface to perform intent recognition and keyword extraction on the user's question. Specifically, the model extracts fault type tags, names of relevant software modules, error codes, and key technical terms from the question text, and combines the extracted results into structured query conditions; Step S3: After receiving the structured query conditions, the knowledge base index service performs a search in the pre-built multi-level index: First, it quickly filters the candidate document set by tags and keywords through the inverted index, then performs a full-text search on the candidate set and calculates the comprehensive relevance score, and returns the top-K Markdown knowledge documents with the highest scores and their relevance scores; Step S4: The index routing engine performs hierarchical routing determination on the search results: if the candidate set is not empty and the relevance score of the best matching document exceeds the preset threshold, it is determined as a first-level hit, and step S5 is executed; if the candidate set is empty or the score is lower than the threshold, it is determined as a miss, and step S6 is executed. Step S5 (Level 1 Hit Path): The index routing engine reads the complete content of the hit Markdown knowledge document from the GitLab knowledge base repository, submits the document content as context to the customer service big language model API interface, and the big model combines the user's original question and the knowledge document content to generate a response text for the user and return it. Step S6 (Secondary Penetration Path): The index routing engine triggers the secondary query process, automatically encapsulating the user's issue into an Issue ticket and submitting it to the GitLab knowledge base repository's Issue system. The Issue ticket includes a de-identified problem description (removing sensitive fields such as customer name, project number, and internal environment IP address), problem category tags, and priority markers; Step S7: The intranet code analysis workstation detects newly added Issue tickets in the knowledge base repository through GitLab Webhook notifications or timed polling mechanisms, and automatically retrieves the Issue content; Step S8: The intranet code analysis workstation starts the code analysis agent, taking the problem description in the Issue as input. The agent then enters a multi-round autonomous analysis mode. Based on the problem description, the agent autonomously plans the analysis path and determines the tools to be used and the code areas to be inspected. Step S9: The code analysis agent first calls the code indexing engine. Based on the keywords, error stack information or exception patterns in the problem, it narrows down the candidate code range from the entire code repository to a few related functions or modules through syntax tree query, symbol table matching and function call graph traversal. This narrows down the candidate range to the level of one percent to one thousandth of the original code repository. Step S10: The code analysis agent performs deep semantic analysis on the narrowed candidate code range, accurately locating the function or code segment containing the root cause of the fault by combining code context understanding, and generating a corresponding repair solution. In this step, the agent may execute multiple rounds of tool calls (code search, file reading, symbol jump, etc.) to gradually narrow the analysis scope and locate the root cause. Step S11: Modify the repair plan generated by the code analysis agent in the verification environment, and execute automatic compilation, unit testing, and regression testing in a containerized isolated sandbox. If the verification fails, the failure information (compilation error details, test assertion failure information, code coverage differences, etc.) is fed back to the code analysis agent, triggering it to re-analyze and generate an improvement plan, and return to step S10 to continue iterating until the verification passes or the maximum number of iterations is reached; Step S12: After successful verification, the code analysis agent encapsulates the analysis results into a standard Markdown knowledge document, including a YAML metadata header (title, tags, keywords, associated Issue number, etc.) and body content organized in a three-part structure: problem description - technical root cause - solution. The agent performs de-identification verification during document generation to ensure that the output content does not contain any source code snippets, internal variable names, or source file paths. Step S13: Knowledge Synchronization and Issue Closure; The intranet workstation pushes the Markdown knowledge document generated in step S12 to the GitLab knowledge repository via git, and simultaneously replies with a de-identified solution summary in the corresponding Issue ticket, setting the Issue status to resolved. Upon detecting the Issue status change, the external application server replies with the solution to the waiting user. Step S14: Knowledge Self-Evolution; After receiving repository push event notifications via GitLab Webhook, the knowledge base index service automatically pulls the latest commits, re-parses the metadata and text content of newly added or modified Markdown knowledge documents, and incrementally updates the inverted index and full-text search index. After the index update is completed, subsequent identical or similar questions can be directly hit in the first-level search of step S3. As the system continues to run, the number and coverage of documents in the anonymized Markdown knowledge base continue to grow, the first-level hit rate increases accordingly, and the proportion of second-level queries that need to penetrate to the internal network continues to decrease, realizing system-level knowledge self-evolution and self-optimization of call costs.

[0048] This invention employs two different large language model access methods with varying capabilities and costs in the external network service domain and the internal network R&D domain: The external customer service side utilizes low-cost external large language model API services (such as the DeepSeek series models) billed on a token basis. These models already possess sufficient performance in intent recognition, keyword extraction, and natural language generation tasks, while the cost per API call is extremely low (token-based billing, with a single request cost approximately one-tenth of that of high-end models). The external side needs to withstand the concurrent pressure of all customer requests; the low-cost API model can support high-throughput service demands within a limited budget. Adopting the API call model eliminates the need for GPU resources on the external application server, further reducing hardware investment. The core capability of the external large model lies in receiving Markdown knowledge documents as context and combining them with user questions to generate accurate and natural response text, enabling a high-quality customer service experience supported by a plain text knowledge base.

[0049] The internal network code analysis side employs an AI programming agent framework (such as Claude Code) with multi-round autonomous reasoning and tool invocation capabilities. Code-level deep semantic understanding, cross-file call chain analysis, and precise root cause localization require models with long contextual understanding capabilities (1M token level) and multi-step reasoning depth. Traditional single-round API call models are ill-suited for such complex analysis tasks. The agent model allows the model to autonomously plan analysis paths, repeatedly invoke code search and file reading tools, adjust analysis directions based on intermediate results, and iteratively correct based on feedback from the verification environment. Since only 10% to 20% of queries reach the internal network after primary routing interception, the invocation cost of the high-performance agent is kept within a reasonable range.

[0050] This differentiated strategy enables the system to achieve the best performance-cost ratio in terms of overall operating costs: more than 80% of requests are handled by low-cost external APIs (low cost per request), and only a small number of requests that truly require in-depth code analysis are routed to high-performance internal agents (higher cost per request but controlled call volume). The overall API call cost of the large model of the system is significantly reduced compared to using high-end models across the board.

[0051] The applicant of this invention has provided a detailed description of the embodiments of the invention in conjunction with the accompanying drawings. However, those skilled in the art should understand that the above embodiments are merely preferred embodiments of the invention. The detailed description is only intended to help readers better understand the spirit of the invention and is not intended to limit the scope of protection of the invention. On the contrary, any improvements or modifications made based on the inventive spirit of the invention should fall within the scope of protection of the invention.

Claims

1. A collaborative operation and maintenance system for a large-scale model with internal and external network isolation based on a version control knowledge base, characterized in that, include: The external service domain, deployed in a managed cloud or isolated zone, is used to receive software fault issues submitted by users and to perform first-level hierarchical routing queries based on a de-identified Markdown knowledge base by calling external large language models and local knowledge base index services. The knowledge base communication layer is deployed on the enterprise GitLab server. It uses the GitLab knowledge base repository as the only data communication hub between the internal and external networks. It isolates access between the internal and external networks through a repository-level access control list and realizes asynchronous information flow across domains through issue tickets and version control submission mechanisms. The knowledge base communication layer configures the external application server as a restricted access role to the GitLab knowledge base repository, granting it only the permission to pull knowledge documents and submit issue tickets, and prohibiting it from accessing other code repositories of the enterprise. Configure workstations in the intranet R&D domain as full read / write roles, granting them permissions to push knowledge documents, update documents, and process issue tickets; the GitLab knowledge base repository automatically records a complete audit log containing the operator's identity, operation time, and changes. The intranet R&D domain is deployed within the enterprise's internal network. It is used to trigger a secondary penetration path when the primary query fails. The code analysis intelligence agent autonomously locates and analyzes the intranet source code and automatically verifies the repair solution in the modification and verification environment. The internal network R&D domain includes: Intranet code analysis workstation: Equipped with a GPU accelerator card, it is used to run code analysis agents, access code repository servers and modification verification environments through the intranet, and has full read and write permissions to the GitLab knowledge base repository; Code Analysis Agent: An interactive AI programming agent running on an intranet code analysis workstation, capable of multi-round autonomous reasoning, code reading and understanding, tool invocation, and iterative correction. The internal code repository server stores the company's full source code and version history. The code analysis agent accesses the code repository server by forcing read-only mounting at the operating system level through the read-only mount option of the Linux file system. Code indexing engine: A preprocessing module running on the code repository server, responsible for parsing the source code abstract syntax tree, constructing the symbol table, generating the function call graph, and constructing the code search index; The verification environment is modified to build an isolated compilation and testing sandbox based on containerization technology. It integrates automatic compilation and build tools, unit testing framework and regression testing suite to automatically verify the repair solutions generated by the code analysis agent, and feeds back the error information to the code analysis agent when the verification fails.

2. The collaborative operation and maintenance system for a large-scale model with internal and external network isolation based on a version control knowledge base as described in claim 1, characterized in that, The external network service domain includes: External application server: hosts customer service front-end applications, index routing engine, and API gateway services; Customer Service Large Language Model API Interface: The external application server calls the external large language model through the API interface to complete intent recognition, keyword extraction, and natural language response generation based on the technical solution text, and the interface does not access any source code data; Knowledge Base Index Service: Running on an external application server, when the GitLab knowledge base repository is updated, it automatically scans Markdown knowledge documents through push or timed pull, parses metadata, and builds an inverted index based on tags and keywords and a full-text search index based on titles and abstracts; Anonymized Markdown Knowledge Base: Stored in GitLab Knowledge Base Repository in plain text format. Its documents use a unified template that includes a YAML header and a three-part body, and the content does not contain any source code snippets or sensitive path information. Index routing engine: running on the external application server, responsible for hierarchical routing determination based on the retrieval results of the knowledge base index service.

3. The collaborative operation and maintenance system for a large-scale model with internal and external network isolation based on a version control knowledge base as described in claim 1, characterized in that, The system employs a differentiated dual-model strategy: On the external network side, a low-cost, pay-as-you-go external large language model API service is used to perform single-round reasoning, keyword extraction, and natural language response generation based on context. The internal network adopts an AI programming agent framework with long context windows and multi-round autonomous reasoning capabilities. It locates the root cause of the fault by autonomously planning and analyzing paths, performing multi-step reasoning, and repeatedly calling code search and file reading tools.

4. A collaborative operation and maintenance method for a large-scale model of internal and external network isolation based on a version control knowledge base, based on the system described in any one of claims 1-3, characterized in that, Includes the following steps: Step S1: The external application server receives the description of the software fault submitted by the user; Step S2: The external application server calls the external low-cost large language model API service to extract fault type tags, software module names, error codes and key technical terms from the problem description and combine them into structured query conditions. Step S3: The knowledge base indexing service performs a retrieval in the pre-built multi-level index based on the structured query conditions, and returns the candidate Markdown knowledge document with the highest score and its relevance score; Step S4: The index routing engine performs hierarchical routing determination. When the relevance score of the best matching document exceeds the preset threshold, it is determined as a first-level hit; when the search result is empty or the relevance score of the best matching document is lower than the preset threshold, it is determined as a miss, triggering a second-level penetration path and implementing step S6. Step S5: Read the complete content of the matched Markdown document and submit it to the external low-cost large model API. Combine the original question to generate the final response text and return it to the user. Step S6: The index routing engine automatically removes sensitive fields from user questions and de-identifies them, then encapsulates them into a question ticket with category tags and priority markers, and submits it to the GitLab knowledge base repository; Step S7: The intranet code analysis workstation automatically detects and retrieves new issue ticket content from the knowledge base repository through GitLab push notifications or a timed polling mechanism; Step S8: The intranet code analysis workstation starts the code analysis agent and inputs the problem description in the work order into the agent. The agent autonomously plans the analysis path and determines the code area to be checked based on the problem description. Step S9: The code analysis agent calls the code indexing engine and narrows the candidate code range from the entire code repository to the relevant function or module level through abstract syntax tree query, symbol table matching and function call graph traversal; Step S10: The code analysis agent performs deep semantic analysis on the narrowed candidate code range, accurately locates the function or code segment where the root cause of the fault is located by executing multiple rounds of tool calls, and generates the corresponding code repair solution.

5. The collaborative operation and maintenance method for a large-scale model of internal and external network isolation based on version control knowledge base as described in claim 4, characterized in that, It also includes sandbox iterative verification steps: Step S11: Modify the code repair plan for the verification environment, and perform automatic compilation, unit testing, and regression testing in a containerized isolated sandbox; If the verification fails, the failure result, including details of the compilation error or the test assertion failure information, is fed back to the code analysis agent, triggering it to re-analyze and generate an improvement plan, and then returning to step S10 to continue iterating until the verification passes or the preset maximum number of iterations is reached.

6. The collaborative operation and maintenance method for a large-scale model of internal and external network isolation based on version control knowledge base as described in claim 4, characterized in that, It also includes knowledge accumulation and self-evolution steps: Step S12: After verification, the code analysis agent encapsulates the analysis results into a standard Markdown knowledge document and performs desensitization verification during generation to ensure that it does not contain source code snippets, internal variable names or source file paths; Step S13: The intranet workstation submits the generated Markdown knowledge document to the GitLab knowledge repository via push, and at the same time replies with the anonymized solution summary in the corresponding issue ticket and changes the issue status to resolved. After the external application server detects the change in issue status, it replies with the solution to the user. Step S14: After receiving the repository push event notification, the knowledge base index service automatically pulls the latest submissions and re-parses the newly added or modified Markdown knowledge documents, incrementally updating the inverted index and full-text search index.

Images