Defect repairing method, defect repairing device, electronic device, and computer storage medium

Abstract

The application discloses a defect repairing method, a defect repairing device, an electronic device and a computer storage medium. The method comprises the following steps: scanning a defect directory to obtain a defect file in the defect directory; searching a historical repair account book according to file information of the defect file to obtain a search result; if the search result indicates that the defect file has not been successfully repaired, performing triage processing on the defect file based on triage rules, generating a defect repairing strategy according to a triage result, and performing defect repairing on a defect of a large model agent platform according to the defect repairing strategy. Through the searching of the historical repair account book, repeated analysis and repairing of successfully repaired defects are avoided, and the repairing period is greatly shortened.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a defect repair method, defect repair device, electronic device, and computer storage medium. Background Technology

[0002] As large-scale agent platforms gradually take on tasks from multiple business areas such as customer relationship management systems and project management systems, the sources of defects have expanded from code errors in traditional monolithic applications to complex issues that cross levels, domains, and sessions.

[0003] During use, users will provide feedback after discovering defects. A single user-reported defect file often involves defects at multiple levels, including message entry points, identity mapping, routing links, system prompts, tool schemas, business skills, and data access layers.

[0004] However, existing defect repair methods are independent in each repair, which may lead to repeated analysis or repair of the same defect during the defect repair process. Summary of the Invention

[0005] In view of this, this application provides a defect repair method, a defect repair apparatus, an electronic device, and a computer storage medium to solve the problems in conventional solutions.

[0006] This application provides a defect repair method, comprising: scanning a defect directory to obtain defect files in the defect directory, wherein the defect files are structured input carriers used to record defects of a large model proxy platform; retrieving a historical repair ledger based on the file information of the defect files to obtain search results, wherein the historical repair ledger stores full lifecycle information of historical defect repair processes; if the search results indicate that the defect file has not been successfully repaired, then performing triage processing on the defect file based on triage rules, and generating a defect repair strategy based on the triage results; and repairing the defects of the large model proxy platform according to the defect repair strategy.

[0007] Optionally, the process of triaging the defective files based on triage rules and generating a defect repair strategy based on the triage results may further include: adding defect type tags to the defective files based on triage rules, generating a set of defects to be repaired based on the tagged defective files, and generating a defect repair strategy corresponding to the set of defects to be repaired.

[0008] Optionally, the process of retrieving the historical repair ledger based on the file information of the defective file to obtain the retrieval results may further include: constructing retrieval conditions based on the defect type and business domain affiliation information included in the file information; retrieving the historical repair ledger based on the retrieval conditions; if defect repair lifecycle information matching the retrieval conditions is found, a retrieval result indicating that the defect of the large model agent platform has been successfully repaired is generated; if defect repair lifecycle information matching the retrieval conditions is not found, a retrieval result indicating that the defect of the large model agent platform has not been successfully repaired is generated.

[0009] Optionally, the triage rules may include: invalid defect identification rules, rules for identifying duplicate submissions by the same user within seconds, rules for identifying duplicate submissions within the same session, rules for identifying regression defects, rules for identifying automated test failure defects, rules for identifying defects requiring supplementary information, and rules for marking new defects; the invalid defect identification rules include: when the defect file is only for feedback and has no valid dialogue record, generating a defect type tag indicating that the defect of the large model proxy platform is an invalid defect; the rules for identifying duplicate submissions by the same user within seconds include: if the same user submits multiple defect files within a preset time window and the first round of user messages is the same, then only the first submitted defect file is retained; the rules for identifying duplicate submissions within the same session include: when different defect files correspond to the same session and the dialogue content is consistent, generating a defect type tag indicating that the defect of the large model proxy platform is a duplicate defect; the regression defect identification rules include: when the historical repair ledger includes the defect file... When matching the full lifecycle information of defect repair, a defect type tag indicating that the defect of the large model proxy platform is a regression defect is generated; the automated test failure defect identification rule includes: when the source of the defect file matches the characteristics of the automated test scenario, a defect type tag indicating that the defect of the large model proxy platform is an automated test failure defect is generated; the supplementary information defect identification rule includes: when the description of the defect file cannot determine the expected behavior, a defect type tag indicating that the defect of the large model proxy platform is an automated test failure defect is generated; the new defect tagging rule includes: when the defect file does not match the invalid defect identification rule, the same user second-level duplicate submission identification rule, the same session duplicate submission identification rule, the regression defect identification rule, the automated test failure defect identification rule, or the supplementary information defect identification rule, a defect type tag indicating that the defect of the large model proxy platform is a new defect is generated.

[0010] Optionally, the process of generating a set of defects to be repaired based on the tagged defect files may further include: classifying the defect files according to the defect type tags and business domain affiliation information of the defects corresponding to the large model agent platform to obtain at least one defect repair group; and prioritizing the at least one defect repair group according to the defect type tags to generate a set of defects to be repaired.

[0011] Optionally, the process of performing defect repair according to the defect repair strategy may further include: if the context resources required to execute the defect repair strategy exceed the resource limit threshold, then the defect repair groups are repaired sequentially according to the priority order, and when each defect repair group is repaired, the defect repair lifecycle information of the defect repair group is updated to the intermediate document, until each defect repair group has completed defect repair.

[0012] Optionally, the defect repair process may further include: if the search results indicate that the defect file has been successfully repaired, then the defects of the large model agent platform are repaired according to the defect repair lifecycle information that matches the search conditions.

[0013] A second aspect of this application provides a defect repair apparatus, comprising: a scanning module for scanning a defect directory to obtain defect files in the defect directory, wherein the defect files are structured input carriers for recording defects of a large model proxy platform; a retrieval module for retrieving a historical repair ledger based on the file information of the defect files to obtain retrieval results, wherein the historical repair ledger stores full lifecycle information of historical defect repair processes; and a generation module for, if the retrieval results indicate that the defect file has not been successfully repaired, performing triage processing on the defect file based on triage rules and generating a defect repair strategy based on the triage results; and performing defect repair on the defects of the large model proxy platform according to the defect repair strategy.

[0014] A third aspect of this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, which causes the processor to perform the operation corresponding to the method described in the first aspect of the embodiment.

[0015] The fourth aspect of this application provides a computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect of the embodiments.

[0016] The fifth aspect of this application provides a computer program product including computer instructions that instruct a computing device to perform an operation corresponding to the method described in the first aspect of the embodiments.

[0017] In this application, the standardized defect file format avoids the problems of non-standard and incomplete defect report information. By retrieving historical repair logs, the repeated analysis and repair of successfully repaired defects is avoided, significantly shortening the repair cycle. Triage of defect files based on triage rules reduces the workload of manual triage and improves the accuracy and timeliness of defect processing. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0019] Figure 1 This is a flowchart of the steps of a defect repair method according to an embodiment of this application; Figure 2 This is a flowchart of the steps of a defect repair method according to another embodiment of this application; Figure 3 This is a flowchart of the steps of a defect repair method according to another embodiment of this application; Figure 4 This is a schematic diagram of a defect repair device according to an embodiment of this application; Figure 5 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in the embodiments of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application should fall within the protection scope of the embodiments of this application.

[0021] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0022] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0023] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application. Where there is no conflict, the following embodiments and their technical features can be combined with each other.

[0024] Figure 1 This is a flowchart illustrating the steps of a defect repair method according to an embodiment of this application. Figure 1 As shown, the defect repair method includes the following steps: Step 101: Scan the defect directory to obtain the defect files in the defect directory.

[0025] A defect directory (e.g., / data / agent_defects / ) is pre-configured on the operation and maintenance server of the large model agent platform. Users can write defect files to this directory. The defect directory can be scanned periodically; for example, scheduled scans (e.g., every 5 minutes) and real-time triggered scans (e.g., automatically triggered when a new defect file is written, or triggered after 5 defect files are written) can be configured. During the scan, the file extensions (e.g., .defect) and header identifiers (e.g., #AGENT_DEFECT_V1.0) of the files in the defect directory are identified, and defect files that meet the format requirements are filtered out.

[0026] Defect files can be structured input carriers in Markdown, JSON, or database record formats, used to record defects in large model proxy platforms. Defect files include, but are not limited to, the following fields: Defect ID, Submission Time, Submitting User ID, Session ID, Business Domain Affiliation, Defect Description, Expected Behavior, Actual Behavior, Error Log, Platform Version, Environment Information, and Reproduction Steps.

[0027] Step 102: Search the historical repair ledger based on the file information of the defective file to obtain the search results.

[0028] A distributed historical remediation ledger can be pre-configured, storing the full lifecycle information of all historical defect remediation processes. This lifecycle information can include: basic defect information, defect type, remediation strategy, remediation executor, remediation start time, remediation completion time, code changes, test results, rollback records, and acceptance conclusions. The file information of the current defect file is extracted as a search feature to initiate a query request to the historical remediation ledger, obtaining the search results. The search results are of boolean type, categorized as either successfully remediated or unsuccessfully remediated.

[0029] Step 103: If the search results indicate that the defective file has not been successfully repaired, the defective file is triaged based on the triage rules, and a defect repair strategy is generated based on the triage results.

[0030] If the search results indicate that the defect file has not been successfully repaired, it proves that the defect in the defect file recording the large model agent platform has not been repaired, or it was repaired but not successfully. In this case, there is no prior reference for repairing this defect. At this time, it is necessary to triage the defect file according to the preset triage rules, and generate a defect repair strategy that can repair the defect of the large model agent platform based on the defect type, business domain, priority and other information indicated by the triage results.

[0031] Step 104: Repair the defects of the large model agent platform according to the defect repair strategy.

[0032] Defects in the large model proxy platform are repaired according to the defect repair strategy.

[0033] The remediation strategy may include: assigning responsibility for remediation, invoking remediation tools, outlining the remediation steps, executing test cases, and implementing rollback contingency plans. Based on the generated remediation strategy, large-scale model code generation tools and automated testing tools are invoked to fix the defects in the large-scale model proxy platform.

[0034] In this embodiment, a standardized defect file format avoids issues such as non-standard and incomplete defect report information. Retrieving historical repair logs avoids redundant analysis and repair of successfully fixed defects, significantly shortening the repair cycle. Triage of defect files based on triage rules reduces the workload of manual triage and improves the accuracy and timeliness of defect processing.

[0035] In one possible implementation, the process of triaging defective files according to preset triage rules and generating defect remediation strategies based on the triage results may further include: Based on the triage rules, defect type tags are added to the defect files, and a set of defects to be repaired is generated based on the tagged defect files. Finally, a defect repair strategy corresponding to the set of defects to be repaired is generated.

[0036] The defect files are analyzed from multiple dimensions, and corresponding defect type tags are added to them. All defect files that have not been successfully fixed and have been marked with defects are aggregated and organized into a set of defects to be fixed. Based on the type, business domain, priority, and other information of each defect in the set of defects to be fixed, a defect fixing strategy capable of fixing defects in the large model proxy platform is generated.

[0037] In this embodiment of the application, by adding corresponding defect type tags to defect files, the unstructured or semi-structured defect descriptions obtained from triage are transformed into standardized structured data, thereby integrating scattered and independent defect files into a unified set of defects to be repaired, and enabling the classification of defects of the same type.

[0038] In one possible implementation, the process of retrieving historical repair ledgers based on file information of defective files to obtain search results may also include: Search criteria are constructed based on the defect type and business domain affiliation information included in the document information. The historical repair ledger is searched based on these criteria. If a defect repair lifecycle information matching the search criteria is found, search results indicating that the defect on the large model agent platform has been successfully repaired are generated. If no defect repair lifecycle information matching the search criteria is found, search results indicating that the defect on the large model agent platform has not been successfully repaired are generated.

[0039] Extract two core fields, defect type and business domain affiliation, from the file information of defect files to construct search conditions for defects that accurately match the large model agent platform.

[0040] It should be noted that the defect type field is optional in the defect file. If the defect type field is not filled in when submitting the defect file, the defect type can be predicted first through a preliminary text classification model, and then search conditions for defects that accurately match the large model proxy platform can be constructed. The business domain affiliation field is a required field and is automatically filled in by the large model proxy platform when generating the defect file. The value range is a predefined enumeration value.

[0041] The constructed search criteria are sent to the historical repair ledger, and the query operation is executed. If the historical repair ledger contains at least one defect repair lifecycle record that completely matches the search criteria, a successfully repaired search result is generated, and the matching defect repair lifecycle information is returned. If no matching record exists in the historical repair ledger, a search result for unrepaired defects is generated.

[0042] In this embodiment, by combining defect type and business domain affiliation as search criteria, interference from irrelevant historical records is avoided, significantly improving search speed and matching accuracy. Simultaneously, the filtering based on business domain affiliation ensures that defect repair lifecycle information from different business scenarios will not be successfully matched, thus guaranteeing the accuracy of defect repair.

[0043] In one possible implementation, the triage rules include: invalid defect identification rules, second-level duplicate submission identification rules for the same user, duplicate submission identification rules for the same session, regression defect identification rules, automated test failure defect identification rules, defect identification rules for information to be supplemented, and new defect marking rules.

[0044] The invalid defect identification rules include: when the defect file only contains feedback intent and has no valid dialogue record, a defect type label indicating that the defect of the large model agent platform is an invalid defect is generated.

[0045] For example, if the defect description only contains vague feedback such as "not working well" or "has a problem," and the dialogue record is empty or only contains greetings without any valid interaction records, it is judged as an invalid defect.

[0046] The rules for identifying duplicate submissions by the same user at the second level include: if the same user submits multiple defect files within a preset time window and the initial user messages are the same, only the defect file submitted in the first round will be retained.

[0047] For example, consider the defect files submitted by the same user within 10 seconds. If multiple defect files have identical initial user message fields, they are considered duplicate submissions. In this case, only the first submitted defect file is retained, and the remaining files are marked as duplicates and automatically archived or deleted.

[0048] The rules for identifying duplicate submissions within the same session include: when different defect files correspond to the same session and the dialogue content is consistent, a defect type marker is generated indicating that the defect of the large model agent platform is a duplicate defect.

[0049] Defect files are grouped based on session address. If multiple defect files exist under the same session address, and their defect descriptions and actual behaviors have a similarity exceeding 95%, then the defect files are considered to correspond to the same session and have identical dialogue content. Content similarity can be calculated using a cosine similarity algorithm. Defect files corresponding to the same session and with identical dialogue content are marked as duplicates and automatically associated with the first submitted defect file, or the marked defect files are directly deleted.

[0050] The regression defect identification rules include: when the historical repair ledger includes full lifecycle information of defect repair that matches the defect file, the defect that indicates the large model agent platform is a regression defect.

[0051] The defect file is compared with closed defect records in the historical repair ledger. If a defect file exists that perfectly matches the defect file and its repair completion time is before the current large model proxy platform's version release time, it is identified as a regression defect. Closed defect records in the historical repair ledger contain the full lifecycle information of defect repairs that were attempted but failed.

[0052] The rules for identifying automated test failure defects include: when the source of a defect file matches the characteristics of an automated test scenario, a defect type marker is generated indicating that the defect of the large model proxy platform is an automated test failure defect.

[0053] The defect identification rules to be supplemented include: when the description of the defect file cannot determine the expected behavior, a defect type label indicating that the defect of the large model agent platform is an automated test failure defect is generated.

[0054] The new defect marking rules include: when a defect file does not match an invalid defect identification rule, a rule for repeated submissions by the same user at the second level, a rule for repeated submissions in the same session, a regression defect identification rule, a rule for identifying defects due to failures in automated testing, or a rule for identifying defects requiring supplementary information, a defect type mark is generated indicating that the defect on the large model proxy platform is a new defect.

[0055] When adding defect type tags to the defect file based on triage rules, the triage rules can be matched sequentially according to their priority. The priority order of the triage rules is as follows: invalid defect identification rule, same user second-level duplicate submission identification rule, same session duplicate submission identification rule, regression defect identification rule, automated test failure defect identification rule, defect identification rule for information to be supplemented, and new defect tagging rule. After a triage rule is matched, the remaining triage rules with lower priority than the matched triage rule will not be matched.

[0056] In this application embodiment, multiple triage rules cover common scenarios such as invalid defects, duplicate defects, regression defects, and automated testing defects, ensuring that all defects can be accurately classified. By identifying different types of defects based on different triage rules, manual processing is avoided, saving significant labor costs.

[0057] Figure 2 This is a flowchart of the defect repair method according to another embodiment of this application, as follows: Figure 2 As shown, step 103 may also include the following steps: Step 1031: Classify the defect files according to the defect type label and business domain affiliation information of the corresponding large model agent platform to obtain at least one defect repair group.

[0058] Defect files are categorized based on defect type tags and business domain attribution information for the corresponding large-scale agent platform. Defect types can include: LLM parameter errors, LLM output format errors, Skill logic defects, missing schema descriptions, broken identity chains, misleading System Prompts, infrastructure failures, historical data issues, display layer defects, missing context, and undetermined types. Business domain attribution information is identified through Agent ID prefix mapping and can include the Customer Relationship Management System domain, Project Management System domain, and other business domains or unknown domains.

[0059] Defect files within the same business domain and with the same defect type tag are grouped into one defect remediation group. Alternatively, defect files can be classified by calculating the similarity of common phenomenon patterns. The similarity of common phenomenon patterns can be calculated using one or more of the following features: keyword overlap in user descriptions, error statement patterns in the first or subsequent rounds of dialogue, consistency or similarity of Agent ID link sequences, consistency of anomaly types in logs located by Trace IDs, and consistency of already classified defect types. Alternatively, a similarity score can be generated based on the above features. When the similarity score reaches a preset threshold, multiple defect files are grouped into the same remediation group; when the similarity score does not reach the threshold, a new remediation group is created.

[0060] Step 1032: Prioritize at least one defect repair group according to the defect type label, generate a set of defects to be repaired, and generate a defect repair strategy corresponding to the set of defects to be repaired.

[0061] Each defect repair group is assigned a priority based on its defect type. For defect repair groups with the same priority, they are further sorted by the submission time of the defect files; earlier submissions have higher priority. The final set of defects to be repaired is a list of defect repair groups sorted by priority.

[0062] In this embodiment, defect files are categorized by defect type tagging and business domain affiliation information. Defects of the same type are processed centrally, facilitating the remediation team to summarize experience, formulate standardized remediation plans, and improve overall remediation efficiency. A priority ranking mechanism ensures that defects with a wide impact and high severity are remediated in a timely manner, reducing the platform's operational risks.

[0063] In one possible implementation, the process of fixing defects in the large model proxy platform according to the defect fixing strategy may also include: If the context resources required to execute the defect repair strategy exceed the resource limit threshold, the defect repair groups will be repaired sequentially according to their priority order. When each defect repair group is completed, the full lifecycle information of the defect repair group will be updated to the intermediate document until each defect repair group has completed its defect repair.

[0064] Before executing a defect remediation strategy, the context resources required can be assessed. If the total resources required exceed the resource limit threshold, it is considered a resource shortage. When resources are insufficient, each defect remediation group is remediated sequentially according to its priority. Specifically, the highest priority defect remediation group can be selected and allocated sufficient context resources. The defect remediation strategy corresponding to that group is executed, completing the remediation of all defects within the group. After the remediation of that group is complete, the entire lifecycle information of the defect remediation (including start time, completion time, remediation content, and test results) is updated to an intermediate document. The intermediate document can be stored in Redis to temporarily store incomplete remediation records. Then, the context resources occupied by that group are released to continue processing the next priority defect remediation group. The above steps are repeated until all defect remediation groups are remediated. Once all defects are remediated, all remediation records in the intermediate document are batch-written to the historical remediation ledger for permanent archiving.

[0065] In this embodiment, when context resources are insufficient, priority is given to repairing high-priority defects to ensure the stability of critical business operations. Repair records are temporarily stored in intermediate documents to prevent data loss due to faults and ensure the traceability of the repair process.

[0066] Figure 3 This is a flowchart of the steps of a defect repair method according to another embodiment of this application, as follows: Figure 3 As shown, the defect repair method includes the following steps: Step 201: Scan the defect directory to obtain the defect files in the defect directory.

[0067] The defect directory can be scanned periodically. For example, it can be set to scan the defect directory on a scheduled basis (e.g., every 5 minutes) or to be triggered in real time (e.g., automatically when a new defect file is written, or after 5 defect files are written). During the scan, the file extensions (e.g., .defect) and header identifiers (e.g., #AGENT_DEFECT_V1.0) of the files in the defect directory will be identified, and defect files that meet the format requirements will be filtered out.

[0068] Step 202: Search the historical repair ledger based on the file information of the defective file to obtain the search results.

[0069] A distributed historical remediation ledger can be pre-configured, storing the full lifecycle information of all historical defect remediation processes. This lifecycle information can include: basic defect information, defect type, remediation strategy, remediation executor, remediation start time, remediation completion time, code changes, test results, rollback records, and acceptance conclusions. The file information of the current defect file is extracted as a search feature to initiate a query request to the historical remediation ledger, obtaining the search results. The search results are of boolean type, categorized as either successfully remediated or unsuccessfully remediated.

[0070] Step 203: Determine whether the defective file has been successfully repaired based on the search results. If yes, proceed to step 204; otherwise, proceed to step 206.

[0071] Step 204: Add defect type tags to defect files based on triage rules, and generate a set of defects to be repaired based on the tagged defect files.

[0072] If the search results indicate that the defective file has not been successfully repaired, it proves that the defect in the file recording the large model agent platform has not been repaired, or it was repaired but not successfully. In this case, there is no prior reference for repairing this defect. Therefore, it is necessary to perform multi-dimensional analysis on the defective file according to the preset triage rules and add corresponding defect type tags to the defective file. All defective files that have not been successfully repaired and have been marked with defects will be summarized and organized into a set of defects to be repaired.

[0073] Step 205: Generate a defect repair strategy corresponding to the set of defects to be repaired, repair the defects of the large model proxy platform according to the defect repair strategy, and end the current process.

[0074] Based on the type, business domain, priority, and other information of each defect in the defect set to be repaired, a defect repair strategy is generated to fix the defects of the large model proxy platform. The defects of the large model proxy platform are then repaired according to the defect repair strategy.

[0075] Step 206: Perform defect repair on the large model agent platform based on the defect repair lifecycle information that matches the search criteria.

[0076] If the search results indicate that the defective file has been successfully repaired, the full lifecycle information of the matched defect repair can be obtained from the historical repair ledger. Based on the matched full lifecycle information of the defect repair, a fast repair strategy is automatically generated, and the defects of the large model agent platform are repaired according to the fast repair strategy.

[0077] In this embodiment of the application, known defects are addressed by directly reusing the entire lifecycle information of defect repair, thus avoiding repeated defect analysis and solution design processes.

[0078] Figure 4 This is a schematic diagram of a defect repair device according to an embodiment of this application, as shown below. Figure 4 As shown, the defect repair device 400 includes: The scanning module 401 is used to scan the defect directory and obtain the defect files in the defect directory. The defect files are structured input carriers used to record the defects of the large model proxy platform.

[0079] The scanning module 401 can periodically scan the defect directory. For example, it can be set to scan the defect directory on a scheduled basis (e.g., every 5 minutes) or to trigger a real-time scan (e.g., automatically when a new defect file is written, or after 5 defect files are written). During the scan, it will identify the file extensions (e.g., .defect) and header identifiers (e.g., #AGENT_DEFECT_V1.0) of the files in the defect directory, and filter out defect files that meet the format requirements.

[0080] The retrieval module 402 is used to retrieve the historical repair ledger based on the file information of the defective file and obtain the retrieval results. The historical repair ledger stores the full lifecycle information of the historical defect repair process.

[0081] The historical remediation ledger stores the entire lifecycle information of all historical defect remediation processes. This lifecycle information can include: basic defect information, defect type, remediation strategy, remediation executor, remediation start time, remediation completion time, remediation code changes, test results, rollback records, and acceptance conclusions. The retrieval module 402 extracts the file information of the current defect file as a retrieval feature, initiates a query request to the historical remediation ledger, and obtains the retrieval results. The retrieval results are of Boolean type, categorized as either successfully remediated or unsuccessfully remediated.

[0082] The generation module 403 is used to perform triage processing on the defective file based on the triage rules if the search results indicate that the defective file has not been successfully repaired, and to generate a defect repair strategy based on the triage results.

[0083] If the search results indicate that the defect file has not been successfully repaired, it proves that the defect in the defect file recording the large model agent platform has not been repaired, or it was repaired but not successfully. In this case, there is no prior reference for repairing the defect. At this time, the generation module 403 needs to perform triage processing on the defect file according to the preset triage rules, and generate a defect repair strategy that can repair the defect of the large model agent platform based on the information such as the type, business domain, and priority of each defect indicated by the triage results.

[0084] Repair module 404 is used to repair defects in the large model proxy platform according to the defect repair strategy.

[0085] Repair module 404 performs defect repair on the large model agent platform according to the defect repair strategy.

[0086] In this embodiment, a standardized defect file format avoids issues such as non-standard and incomplete defect report information. Retrieving historical repair logs avoids redundant analysis and repair of successfully fixed defects, significantly shortening the repair cycle. Triage of defect files based on triage rules reduces the workload of manual triage and improves the accuracy and timeliness of defect processing.

[0087] In this embodiment, an electronic device 500 is provided, such as... Figure 5 As shown, the electronic device 500 may include: a processor 501, a communications interface 502, a memory 503, and a communication bus 504. Wherein: The processor 501, communication interface 502, and memory 503 communicate with each other through the communication bus 504.

[0088] Communication interface 502 is used for communication with other electronic devices or servers.

[0089] The processor 501 is used to execute program 505, which can specifically execute the relevant steps in the aforementioned defect repair method embodiment.

[0090] Specifically, program 505 may include program code that includes computer operation instructions.

[0091] Processor 501 may be a CPU, an Application Specific Integrated Circuit (ASIC), or configured as one or more integrated circuits. A smart device may include one or more processors, which can be of the same type, such as one or more CPUs; or they may be of different types, such as one or more CPUs and one or more ASICs.

[0092] Memory 503 is used to store program 505. Memory 503 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0093] Specifically, program 505 can be used to cause processor 501 to execute the defect repair method in the foregoing embodiments.

[0094] The specific implementation of each step in procedure 505 can be found in the corresponding steps and units described in the aforementioned defect repair method embodiments, and will not be repeated here. Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the devices and modules described above can be referred to the corresponding process descriptions in the aforementioned method embodiments, and will not be repeated here.

[0095] The electronic device 500 in this application avoids the problems of non-standard and incomplete defect report information by using a standardized defect file format. By retrieving historical repair logs, it avoids the repeated analysis and repair of successfully repaired defects, significantly shortening the repair cycle. Triage of defect files based on triage rules reduces the workload of manual triage and improves the accuracy and timeliness of defect processing.

[0096] In this embodiment, a computer-readable storage medium is provided, storing instructions for causing a machine to perform a defect repair method as described herein. Specifically, a system or apparatus equipped with a storage medium storing software program code that implements the functions of any of the embodiments described above, and enabling the computer (or CPU or MPU) of the system or apparatus to read and execute the program code stored in the storage medium.

[0097] In this case, the program code read from the storage medium can itself implement the functions described in the above method embodiments, so the program code and the storage medium storing the program code constitute a part of this application.

[0098] Storage media embodiments for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0099] In this embodiment, a computer program product is provided, including computer instructions that instruct a computing device to perform the operations corresponding to the above-described method embodiments.

[0100] It should be noted that, depending on the implementation needs, the various components / steps described in the embodiments of this application can be broken down into more components / steps, or two or more components / steps or parts of the operation of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of this application.

[0101] The methods described in the embodiments of this application can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as a CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code downloaded over a network that is originally stored in a remote recording medium or a non-transitory machine-readable medium and will be stored in a local recording medium. Thus, the methods described herein can be processed by software stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA). It is understood that computers, processors, microprocessor electronic devices, or programmable hardware include storage components (e.g., RAM, ROM, flash memory, etc.) capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods described herein. Furthermore, when a general-purpose computer accesses code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for performing the methods shown herein. Although this application has been shown and described with respect to one or more implementations, equivalent variations and modifications will occur to those skilled in the art based on a reading and understanding of this specification and the accompanying drawings. This application includes all such modifications and variations and is limited only by the scope of the appended claims. In particular, with respect to the various functions performed by the aforementioned components, the terminology used to describe such components is intended to correspond to any component (unless otherwise indicated) that performs the specified function of said component (e.g., is functionally equivalent to it), even if it is not structurally equivalent to the disclosed structure that performs the functions in the exemplary implementations of this specification shown herein.

[0102] That is, the above description is only an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made using the content of this application’s specification and drawings, such as the combination of technical features between different embodiments, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of this application.

[0103] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0104] The above description is provided to enable any person skilled in the art to implement and use this application. Various details are set forth in the above description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be implemented without using these specific details. In other embodiments, well-known processes will not be described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed herein.

[0105] It should be noted that, without conflict, the various embodiments and / or technical features described in this application can be arbitrarily combined with each other, and the resulting technical solutions should also fall within the protection scope of this application.

[0106] It should be understood that the specific examples in the embodiments of this application are only for the purpose of helping those skilled in the art to better understand the embodiments of this application, and are not intended to limit the scope of the embodiments of this application. Those skilled in the art can make various improvements and modifications based on the above embodiments, and all such improvements or modifications fall within the protection scope of this application. The above descriptions are merely specific implementations of this application, but the protection scope of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A defect repair method characterized by, The method includes: The defect directory is scanned to obtain the defect files in the defect directory, wherein the defect files are structured input carriers used to record the defects of the large model proxy platform; The historical repair ledger is retrieved based on the file information of the defective file to obtain the retrieval results. The historical repair ledger stores the full lifecycle information of the historical defect repair process. If the search results indicate that the defective file has not been successfully repaired, the defective file is triaged based on the triage rules, and a defect repair strategy is generated based on the triage results. The defects of the large model proxy platform are repaired according to the defect repair strategy.

2. The method of claim 1, wherein, The process of triaging the defective files based on triage rules and generating a defect remediation strategy based on the triage results includes: Based on the triage rules, defect type tags are added to the defect files, and a set of defects to be repaired is generated based on the tagged defect files; Generate a defect repair strategy corresponding to the set of defects to be repaired.

3. The method according to claim 1, characterized in that, The step of retrieving the historical repair ledger based on the file information of the defective file to obtain the retrieval results includes: Search criteria are constructed based on the defect types and business domain affiliation information included in the document information; The historical repair ledger is searched according to the search criteria. If defect repair lifecycle information matching the search criteria is found, a search result indicating that the defect of the large model agent platform has been successfully repaired is generated. If defect repair lifecycle information matching the search criteria is not found, a search result indicating that the defect of the large model agent platform has not been successfully repaired is generated.

4. The method according to claim 2, characterized in that, The triage rules include: invalid defect identification rules, second-level duplicate submission identification rules for the same user, duplicate submission identification rules for the same session, regression defect identification rules, automated test failure defect identification rules, defect identification rules for information to be supplemented, and new defect marking rules; The invalid defect identification rule includes: when the defect file is only a feedback intent and has no valid dialogue record, a defect type tag indicating that the defect of the large model agent platform is an invalid defect is generated; The rule for identifying duplicate submissions by the same user at the second level includes: if the same user submits multiple defective files within a preset time window and the first round of user messages is the same, then only the defective file submitted in the first round will be retained; The rule for identifying duplicate submissions within the same session includes: when different defect files correspond to the same session and the dialogue content is consistent, a defect type marker is generated to indicate that the defect of the large model proxy platform is a duplicate defect; The regression defect identification rule includes: when the historical repair ledger includes full lifecycle information of defect repair that matches the defect file, a defect type tag indicating that the defect of the large model proxy platform is a regression defect is generated; The automated test failure defect identification rule includes: when the source of the defect file matches the characteristics of the automated test scenario, a defect type tag is generated indicating that the defect of the large model proxy platform is an automated test failure defect; The defect identification rules for the information to be supplemented include: when the description of the defect file cannot determine the expected behavior, a defect type tag is generated to indicate that the defect of the large model proxy platform is an automated test failure defect; The new defect marking rules include: when the defect file does not match the invalid defect identification rule, the same user's second-level repeated submission identification rule, the same session's repeated submission identification rule, the regression defect identification rule, the automated test failure defect identification rule, or the information to be supplemented defect identification rule, a defect type mark indicating that the defect of the large model proxy platform is a new defect is generated.

5. The method according to claim 2, characterized in that, The step of generating a set of defects to be repaired based on the marked defect files includes: The defect files are classified according to the defect type marker and business domain affiliation information of the corresponding large model agent platform to obtain at least one defect repair group; The at least one defect repair group is prioritized according to the defect type label to generate a set of defects to be repaired.

6. The method according to claim 5, characterized in that, The defect repair according to the defect repair strategy includes: If the context resources required to execute the defect repair strategy exceed the resource limit threshold, the defect repair groups are repaired sequentially according to the priority order. When each defect repair group is repaired, the defect repair lifecycle information of the repaired defect repair group is updated to the intermediate document until each defect repair group has completed defect repair.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: If the search results indicate that the defective file has been successfully repaired, then the defects of the large model agent platform are repaired according to the defect repair lifecycle information that matches the search conditions.

8. A defect repair device, characterized in that, include: The scanning module is used to scan the defect directory and obtain the defect files in the defect directory, wherein the defect files are structured input carriers used to record the defects of the large model proxy platform; The retrieval module is used to retrieve the historical repair ledger based on the file information of the defective file and obtain the retrieval results. The historical repair ledger stores the full lifecycle information of the historical defect repair process. The generation module is used to perform triage processing on the defective file based on triage rules if the search results indicate that the defective file has not been successfully repaired, and to generate a defect repair strategy based on the triage results. The defects of the large model proxy platform are repaired according to the defect repair strategy.

9. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus communicate with each other through the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation corresponding to the method as described in any one of claims 1-7.

10. A computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of claims 1-7.

Images