Intelligent agent skill package evolution closed loop and version immutable governance method and device

Abstract

The embodiment provides an intelligent agent skill package evolution closed loop and version immutable governance method and device, collects multi-source operation feedback of the skill package, extracts failure modes from failure operation logs, extracts improvement requirements from user feedback, extracts capability gaps from missed problems, converges and generates evolution suggestions according to preset evolution suggestion merging rules, and writes the evolution suggestions into an evolution review draft pool; the evolution suggestions in the draft pool are edited by skill creators and reviewed by auditors to form a candidate skill package version, the candidate skill package version is verified for behavior correctness according to preset triple verification rules, new and old version permission differences are compared and risk level differences are compared to generate triple verification results and determine access; the candidate skill package version that passes the access is released as an immutable version, is automatically pushed to a subscribed workspace according to workspace installation association, and forms an evolution closed loop according to the operation feedback after the pushing and backflow to the failure operation logs.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and intelligent agent operation technology, specifically to a method and apparatus for managing the evolutionary closed loop and version immutability of intelligent agent skill packages. Background Technology

[0002] Existing parking lot management intelligent agents primarily provide business capabilities through fixed skill packages. Once deployed, these skill packages maintain their existing configurations for extended periods, lacking a closed-loop evolution mechanism based on operational feedback. Failure logs, user feedback, and missed issues generated during skill package operation are scattered across different storage systems, failing to be systematically collected and refined into actionable improvement items. Improvement relies on periodic manual review, with skill package iteration cycles measured in weeks. Failure modes exposed during operation are difficult to promptly translate into capability enhancements for the skill packages.

[0003] Existing general-purpose intelligent agent frameworks mostly offer retrieval enhancement and process automation capabilities, enabling the injection of external knowledge into the agent and the orchestration of actions. However, their improvement still remains at the level of manually adjusting prompts and processes, failing to establish a complete closed-loop path from operational feedback collection, suggestion merging, review, verification to release. Skill package version management often adopts an in-place update approach, with new versions directly overwriting old versions. The content of released versions can be modified, but if a problem occurs in the new version, it is difficult to revert to a stable version, and version rollback carries risks.

[0004] Existing skill packs lack comparisons of permission and risk levels between old and new versions during version switching. During upgrades, the permission scope of skill packs may expand undetected, leading to the risk of unauthorized access to the parking lot business system. Synchronization of released versions to various workspaces relies heavily on manual distribution, resulting in version inconsistencies and untimely synchronization among multiple workspaces subscribing to the same skill pack. Current solutions do not integrate multi-source feedback collection, draft pool review, triple validation, immutable release, and automatic push, lacking a complete method for skill pack evolution closure and version immutability governance. Therefore, a method for skill pack evolution closure and version immutability governance that integrates multi-source evolution suggestion collection, draft pool review and triple validation, immutable release, and automatic push is needed. Summary of the Invention

[0005] To address the issues of existing parking lot management agents' skill packages lacking closed-loop evolution based on operational feedback, easily overwritten versions during in-situ updates, lack of permission and risk level checks during version switching, and reliance on manual distribution for workspace synchronization, this application provides a method and apparatus for closed-loop evolution and immutable version governance of agent skill packages. This method collects evolutionary suggestions from multiple sources, including failed operation logs, user feedback, and missed issues, and merges them into a draft pool. After editorial review and triple verification of behavioral correctness, permission differences, and risk level differences, it generates admissible candidate skill package versions. These admissible candidate versions are then published as immutable versions and automatically pushed to subscribed workspaces. Operational feedback is fed back to form an evolutionary closed loop, improving the timeliness of skill package iteration, version rollback capability, controllable permission risks, and consistency of synchronization across multiple workspaces.

[0006] To solve at least one of the above problems, this application provides the following technical solution: Firstly, this application provides a method for closed-loop evolution and version immutability governance of intelligent agent skill packs, comprising: collecting multi-source operational feedback of the skill pack; extracting failure modes from failure logs; extracting improvement requirements from user feedback; extracting capability gaps from missed issues; aligning the failure modes, improvement requirements, and capability gaps according to their respective target skill capability items based on preset evolution suggestion merging rules, and then aggregating them to generate evolution suggestions and writing them into an evolution review draft pool, wherein the evolution review draft pool is used to store the evolution suggestions; and then reviewing the evolution suggestions in the evolution review draft pool with skill creators and reviewers. Candidate skill package versions are selected and evaluated in an isolated sandbox according to preset triple verification rules. The test runs verify the correctness of the behavior, compare the differences in permissions between the old and new versions, and compare the differences in risk levels between the old and new versions. The triple verification results are generated and admission is determined. For the candidate skill package versions that pass the admission, a hash fingerprint is calculated and appended to the version chain and published as an immutable version. The immutable version is set with a read-only constraint to prevent modification of the published content. The immutable version is automatically pushed to the subscribed workspaces according to the workspace installation association. The running feedback after the push is fed back to the failure running log to form an evolutionary closed loop.

[0007] Furthermore, it also includes: at the end of each run of the skill package, collecting run feedback according to a preset run feedback field template; importing run feedback with abnormal results into the failure run log; importing user evaluation text of the run results into user feedback; and importing requests that failed to hit into missed issues; binning the failure run log by error code and comparing the similarity of call stack summaries within the bins to extract failure patterns; classifying the user feedback according to a preset intent dictionary to extract improvement needs; and comparing the difference between the request intent and the skill coverage of the missed issues to extract capability gaps.

[0008] Furthermore, it also includes: aligning the failure modes, improvement requirements, and capability gaps according to their respective target skill capabilities based on preset evolutionary suggestion merging rules; merging multiple evolutionary clues pointing to the same skill capability and resolving contradictory improvement directions; assigning weights based on source credibility and frequency of occurrence; encapsulating the merged evolutionary clues with suggestion identifiers, target skill capability items, suggestion content, and weight fields to generate evolutionary suggestions; writing the evolutionary suggestions into the evolutionary review draft pool and adding them to the review queue; and eliminating evolutionary suggestions with weights below the preset threshold when the draft capacity exceeds the preset threshold.

[0009] Furthermore, it also includes: skill creators retrieving evolution suggestions from the waiting queue of the evolution review draft pool, modifying the skill package's prompt word template and process arrangement according to the evolution suggestions to generate a change draft, registering a draft exception flag for change drafts that fail the basic checks on syntax and process connectivity and returning them to the editor; having reviewers verify the scope of changes and compliance constraints of the change drafts, encapsulating the verified change drafts along with version metadata to form a candidate skill package version, and returning the verified and rejected change drafts with rejection comments to the editor and registering a rejection flag in the draft status.

[0010] Furthermore, it also includes: loading the candidate skill package version into an isolation sandbox and running an evaluation test based on a preset evaluation test set; dividing the test set into regular test cases, boundary test cases, and historical failed test cases; comparing the actual output with the expected output to calculate the pass rate; and determining that the behavior verification fails for candidate skill package versions with a pass rate lower than a preset threshold condition; comparing the permission list differences between the candidate skill package version and its predecessor to identify newly added permission items; comparing the risk level differences between the candidate skill package version and its predecessor to identify changes in risk level; marking candidate skill package versions with newly added high-risk permission items and those with increased risk levels as pending manual confirmation; and summarizing the triple verification results to determine admission.

[0011] Furthermore, it also includes: calculating a hash fingerprint for the serialized content of the candidate skill package version that has passed the admission and assigning a monotonically increasing version number; appending the version content along with the hash fingerprint and the version number to an append-only version chain to generate an immutable version; each node in the version chain records a parent version reference; setting a read-only constraint on the immutable version to prohibit modification of the published content; writing a publication exception flag for hash verification failures and retrying; if the number of retries exceeds a preset number, manual intervention is initiated; and when an upgrade request is received, a new candidate draft is created based on the version chain to re-enter the review loop.

[0012] Furthermore, it also includes: maintaining an installation association table between workspaces and skill packs, determining target workspaces that have subscribed to the skill packs based on the installation association table, automatically pushing the immutable version to the target workspaces and updating the installed version number according to a batching strategy of first gray-scale batches and then full batches, registering a push error flag for workspaces that fail to push and retrying according to a backoff strategy; collecting the running feedback of the target workspaces on the immutable version, feeding back records of abnormal running results in the running feedback to the failed running log and evolution suggestion collection, and triggering the generation of the next round of evolution suggestions based on the fed-back running feedback to form an evolutionary closed loop.

[0013] Secondly, this application provides a closed-loop evolution and version immutability governance device for intelligent agent skill packages, comprising: an evolution suggestion collection module, used to collect multi-source operational feedback of the skill package and extract failure patterns from failure logs by clustering error codes and call stack summaries, extract improvement needs from user feedback by categorizing them according to a preset intent dictionary, extract capability gaps by comparing missed issues with skill coverage, and aggregate and generate evolution suggestions according to preset evolution suggestion merging rules; a draft pool review module, used to write the evolution suggestions into an evolution review draft pool and add them to a queue for review, wherein the evolution review draft pool is used to store the evolution suggestions, and the skill creator modifies the prompt word template and process arrangement of the skill package to generate a change draft, and the reviewer verifies the scope of changes and compliance constraints before encapsulating the change draft to form a candidate skill package version; and a triple verification module, used to verify the candidate skill package in an isolated sandbox. The evaluation test verifies the correctness of the behavior of the version, compares the permission differences and risk level differences between the candidate skill package version and its predecessor, summarizes and generates a triple verification result, and determines the admission of the candidate skill package version; the immutable release module is used to calculate the hash fingerprint of the candidate skill package version that has passed the admission and assign a monotonically increasing version number, append the version content and the hash fingerprint to the append-only version chain and publish it as an immutable version, set read-only constraints on the immutable version, and create a new candidate draft based on the version chain when an upgrade request is received to re-enter the review closed loop; the automatic push feedback module is used to determine the subscribed target workspace based on the workspace and skill package installation association table and automatically push the immutable version to the target workspace, collect the running feedback after the push, and record the abnormal running results back to the failure running log to form an evolution closed loop.

[0014] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the intelligent agent skill package evolution closed loop and version immutability governance method.

[0015] Fourthly, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the described intelligent agent skill package evolution loop and version immutability governance method.

[0016] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the described intelligent agent skill package evolution loop and version immutability governance method.

[0017] As can be seen from the above technical solution, this application provides a method and device for the closed-loop evolution of intelligent agent skill packages and the governance of immutable versions. It collects data from multiple sources, including failure logs, user feedback, and missed issues, and aggregates them according to merging rules to generate evolutionary suggestions, which are then written into a draft pool. The skill package versions are then reviewed by skill creators and reviewers to form candidate skill package versions, and are subject to triple verification based on behavioral correctness, permission differences, and risk level differences to determine admission. The candidate skill package versions that pass the admission are calculated with hash fingerprints and appended to the version chain for publication as immutable versions. The installation is associated with automatic push to subscribed workspaces, and the collected runtime feedback is fed back to the failure logs and evolutionary suggestion collection to form an evolutionary closed loop. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0019] Figure 1 This is a flowchart illustrating the intelligent agent skill package evolution closed loop and version immutability governance method in the embodiments of this application; Figure 2 This is a schematic diagram of the intelligent agent skill pack evolution closed loop and version immutability management device in the embodiments of this application; Figure 3 This is a schematic diagram illustrating the process of collecting multi-source operational feedback and merging evolutionary suggestions into the draft pool in an embodiment of this application; Figure 4 This is a flowchart illustrating the process of editing and reviewing the draft pool for evolutionary review and triple verification of candidate skill pack versions in this application embodiment; Figure 5 This is a schematic diagram illustrating the process of immutable release and append-only version chain governance of candidate skill pack versions in this application embodiment; Figure 6 This is a schematic diagram illustrating the process of automatically pushing the immutable version to the subscription workspace and the closed loop of runtime feedback in the embodiments of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of this application, but not all embodiments.

[0021] Considering the existing problems of lacking closed-loop evolution based on operational feedback after the deployment of skill packages for parking lot management agents, easy overwriting of released versions during on-site updates, lack of permission and risk level verification during version switching, and reliance on manual distribution for synchronization to the workspace, this application provides a closed-loop evolution and version immutability governance method for agent skill packages. Through multi-source evolution suggestion collection, draft pool review and triple verification, immutable release and automatic push, the evolution and version of skill packages are governed in a closed loop.

[0022] This application provides an embodiment of a closed-loop evolution and version immutability governance method for intelligent agent skill packs, see [link to relevant documentation]. Figure 1 The method specifically includes the following: Step S101: Collect multi-source operation feedback of the skill pack, extract failure modes from failure operation logs, extract improvement requirements from user feedback, extract capability gaps from missed issues, and align the failure modes, improvement requirements and capability gaps with the skill capability items they point to according to the preset evolution suggestion merging rules to generate evolution suggestions and write them into the evolution review draft pool.

[0023] In this embodiment, the method runs on the skill package evolution platform of the parking lot management intelligent agent, such as... Figure 1 As shown, the platform adopts a layered architecture consisting of an operation monitoring layer, an evolution suggestion collection layer, a draft pool review layer, a triple verification layer, and an immutable release layer. Skill packages are organized using six fields: skill package identifier, version number, prompt word template, workflow orchestration, permission list, and risk level. The skill package identifier is a globally unique code.

[0024] In one feasible implementation, the operation monitoring layer collects operation feedback at the end of each skill package run. The operation feedback is organized by operation identifier, skill package identifier, error code, call stack summary, operation context, and timestamp, with the operation identifier as the primary key. Operation feedback for abnormal results is written to the failure operation log, user evaluation text of the operation results is written to user feedback, and requests that fail to hit are written to the missed issues log.

[0025] Based on this, the failure mode is extracted from the failed execution log. For example... Figure 3As shown, the evolutionary suggestion collection layer bins the failed operation logs by error code, and clusters them by comparing the similarity of the call stack summary within each bin. The same cluster is summarized into a failure pattern. The failure pattern records the typical error code, the frequency of occurrence, and the representative call stack. The similarity threshold condition is calibrated based on the historical annotation set. When the annotation set is insufficient, it falls back to the preset initial value and registers the calibration fallback flag.

[0026] Optionally, the evolutionary suggestion collection layer categorizes user feedback according to a preset intent dictionary and semantic similarity to extract improvement needs. User feedback with a confidence level below a preset threshold is registered with a verification pending flag and transferred to a manual verification queue. For issues that are not matched, the difference between the request intent and the skill coverage is compared to extract capability gaps. Capability gaps record the missing request intent and the suggested supplementary skill capabilities.

[0027] In one specific implementation, the failure modes, improvement requirements, and capability gaps are aligned according to their respective corresponding skill capabilities. Multiple evolutionary threads pointing to the same skill capability are merged and contradictory improvement directions are resolved based on a preset evolutionary suggestion merging rule. Evolutionary suggestions are then generated by assigning weights based on source credibility and frequency of occurrence. These evolutionary suggestions are then written into an evolutionary review draft pool. This pool is a storage container for temporarily storing evolutionary suggestions generated from multi-source operational feedback (failure modes, improvement requirements, and capability gaps). These suggestions are sorted by weight and added to a review queue for skill creators to edit and reviewers to form candidate skill package versions. In short, it serves as a centralized buffer and review entry point for evolutionary suggestions.

[0028] Evolutionary suggestions are organized using five fields: suggestion identifier, target skill / ability item, suggestion content, source category, and weight. Evolutionary suggestions are written to the evolutionary review draft pool with the suggestion identifier as the primary key and added to the waiting review queue. Step S102 reads the suggestions at the review entry point according to weight and submission time. When the draft capacity exceeds the preset threshold, evolutionary suggestions with weights lower than the threshold are eliminated and the elimination identifier is registered.

[0029] Step S102: The evolution suggestions in the evolution review draft pool are edited by skill creators and reviewed by reviewers to form candidate skill package versions. According to the preset triple verification rules, the candidate skill package versions are evaluated and tested in an isolated sandbox to verify the correctness of the behavior, compare the differences in permissions between the old and new versions, compare the differences in risk levels between the old and new versions, generate triple verification results, and determine admission.

[0030] Step S101: The evolutionary suggestions written into the evolutionary review draft pool are read into the draft pool review stage, such as... Figure 4 As shown. The draft pool review layer maintains a queue of drafts awaiting review. The queue is sorted by the weight of the evolutionary suggestion and the submission time. The draft status has four values: pending editing, editing, pending review, and packaged. The status transition records the operator and timestamp.

[0031] In one feasible implementation, skill creators retrieve evolutionary suggestions for editing from the review queue, and modify the skill pack's prompt template and workflow arrangement based on these suggestions to generate a draft change. The draft change records prompt differences, additions or deletions of workflow nodes, and parameter adjustments, and is organized with a draft identifier, a source suggestion identifier, and a difference content field.

[0032] Based on this, a basic verification is performed on the draft amendment. The basic verification checks the syntax of the prompt word template and the connectivity of the nodes in the workflow arrangement. Draft amendments that fail the basic verification are marked with an exception and returned to editing. The exception mark records the verification items that failed. After editing and correction, the draft amendment is re-entered for basic verification.

[0033] In one specific implementation, reviewers verify the scope and compliance constraints of draft changes that have passed basic checks, confirming whether the changes exceed the skill and capability items suggested and whether they comply with the compliance constraints of parking lot operations. Draft changes that pass verification are encapsulated along with version metadata to form a candidate skill package version. Draft changes that are rejected are returned to the editor with rejection comments and a rejection flag is registered in draft status.

[0034] Once the candidate skill pack version is ready, it undergoes a triple verification process. For example... Figure 4 As shown, the triple verification layer loads the candidate skill package version in the isolation sandbox and performs evaluation tests according to the preset evaluation test set. The evaluation test set is divided into regular test cases, boundary test cases and historical failure test cases. The pass rate is calculated by comparing the actual output with the expected output. Candidate skill package versions with a pass rate lower than the preset threshold condition are judged to have failed the behavior verification. Test cases that time out are judged to be downgraded after retrying.

[0035] Based on this, permission differences and risk level differences are compared between candidate skill package versions. The permission difference comparison identifies newly added permission items by comparing the permission lists of the candidate skill package version with those of its predecessors. The risk difference comparison identifies changes in risk levels by comparing the risk levels of the two versions, marking candidate skill package versions with newly added high-risk permission items or increased risk levels as requiring manual confirmation. The triple verification results are organized using the candidate identifier as the primary key, and are read and approved at the access point in step S103.

[0036] Step S103: Calculate the hash fingerprint of the candidate skill package version that has passed the admission and append it to the version chain to publish it as an immutable version. Set a read-only constraint on the immutable version to prevent modification of the published content. Automatically push the immutable version to the subscribed workspaces according to the workspace installation association. Flow back to the failure operation log according to the operation feedback after the push to form an evolutionary closed loop.

[0037] Step S102 determines the candidate skill pack version for admission and reads it into the immutable release process, such as... Figure 5As shown, the immutable release layer calculates a hash fingerprint for the serialized content of the admitted candidate skill pack versions. The hash fingerprint is generated using a cryptographic hash function, and a monotonically increasing version number is assigned to each candidate skill pack version.

[0038] In one feasible implementation, the version content, the hash fingerprint, the version number, the release time, and the admission criteria are appended to an append-only version chain to generate an immutable version. Each node in the append-only version chain records a parent version reference and a hash fingerprint. The version chain only allows appending and does not allow modification of existing nodes. After writing, a read-only constraint is set on the immutable version to prohibit modification of the published content.

[0039] Based on this, a hash verification is performed on the write result. The hash verification recalculates the hash fingerprint of the written node and compares it with the registered fingerprint. If the hash verification fails, the write registration and publication are marked as abnormal and retried. If the number of retries exceeds the preset number, manual intervention is initiated. After the manual intervention result is written back, the publication process is restarted.

[0040] In one specific implementation, upon receiving an upgrade request, a new candidate draft is created based on the version chain, and the review loop of step S102 is re-entered, while the already released immutable version remains unchanged. Upon receiving a rollback request, an existing stable version is located on the version chain by version number and marked as the current version. The rollback operation records the version numbers before and after the rollback, along with the operation timestamp.

[0041] Once the immutable version is ready, it will enter the automatic push phase, such as... Figure 6 As shown. The automatic push layer maintains an installation association table between workspaces and skill packs. The installation association table uses the workspace identifier and skill pack identifier as a joint primary key, records the installed version number and subscription status, determines the target workspace that has subscribed to the skill pack based on the installation association table, and automatically pushes the immutable version and updates the installed version number according to a batching strategy of first gray-scale batch and then full batch.

[0042] Workspaces that experience push failures are registered with an error flag and retried according to a backoff strategy, with the backoff interval increasing with the number of retries. Based on this, operational feedback is collected from the target workspace on the immutable version. This feedback includes call success rate, failure records, and user feedback. Records of abnormal operational results from the feedback are fed back to the failed operation log and evolutionary suggestion collection. The fed-back records use the operational flag as the primary key, triggering the next round of evolutionary suggestion generation in step S101 to form an evolutionary closed loop.

[0043] As can be seen from the above description, the intelligent agent skill package evolution closed loop and version immutability governance method provided in this application embodiment can collect evolution suggestions from multiple sources such as failed operation logs, user feedback and missed issues and merge them into the draft pool. After being reviewed by skill creators, editors and reviewers and subjected to triple verification of behavior correctness, permission differences and risk level differences, the candidate skill package version that has passed the admission is published as an immutable version and automatically pushed to the subscribed workspaces. The evolution closed loop is formed by feedback from operation.

[0044] In one embodiment of the agent skill pack evolution closed loop and version immutability governance method of this application, see [link to relevant documentation]. Figure 3 It can also specifically include the following: Step S201: At the end of each run of the skill pack, collect the run feedback according to the preset run feedback field template, import the run feedback with abnormal results into the failure run log, import the user's evaluation text of the run results into the user feedback, and import the requests that failed to hit into the missed issues. Step S202: The failed operation logs are bucketed by error code and the failure patterns are extracted by clustering the call stack summary similarity within the bucket. The user feedback is classified according to the preset intent dictionary to extract improvement requirements. The missing issues are compared with the difference between the request intent and the skill coverage to extract capability gaps.

[0045] Step S101 describes the operation monitoring layer collecting operation feedback at the end of each skill package run, such as... Figure 3 As shown. The runtime feedback is organized by runtime identifier, skill package identifier, error code, call stack summary, and runtime context. The runtime identifier is a globally unique code. The error code takes five values: normal, parameter abnormality, permission denied, external dependency failure, and timeout. The call stack summary records the call path of the node that erred.

[0046] Abnormal execution results are reported in the failure log; user evaluations of the execution results are reported in the user feedback log; and requests that failed to be executed are reported in the non-attack log. Figure 3 As shown, the failure log is appended chronologically with the run identifier as the primary key, user feedback records the evaluation text and rating, and missed issues record the request intent and the reason for the missed request.

[0047] The failed execution logs are bucketed by error code, and clustering is performed within each bucket by comparing the similarity of the call stack digests to extract failure patterns. The similarity of the call stack digests is measured by a combination of edit distance and common subsequence length. Execution feedback with similarity exceeding a preset threshold is grouped into the same cluster, and the same cluster is summarized into a failure pattern. The failure pattern records typical error codes, frequency of occurrence, and representative call stacks.

[0048] The user feedback is categorized and improvement requests are extracted based on a preset intent dictionary and semantic similarity. The intent dictionary maintains the mapping between business intents and keywords. Semantic similarity calculates the vector distance between the evaluation text that does not hit the dictionary and each intent. User feedback with a confidence level lower than a preset threshold is registered with a verification flag and transferred to a manual verification queue. After the verification results are written back, the feedback is recategorized.

[0049] The missing issues are compared with the difference between the request intent and the skill coverage to extract capability gaps. The skill coverage records the set of request intents currently supported by the skill pack, and the difference is the part of the request intent that is not covered. The capability gap records the missing request intent, its frequency of occurrence, and the suggested skill capabilities to be added. Based on this, gap clues are provided for evolutionary suggestions.

[0050] The failure mode similarity threshold is determined based on the receiver operating characteristic curve of the historical annotation set. When the annotation set is insufficient, it falls back to the preset initial value and the calibration fallback flag is registered. The failure mode, the improvement requirement, and the capability gap are written into the evolutionary cue cache with the evolutionary cue identifier as the primary key, so that step S301 can read them at the evolutionary suggestion merging entry point according to the target skill capability item.

[0051] In one embodiment of the agent skill pack evolution closed loop and version immutability governance method of this application, see [link to relevant documentation]. Figure 3 It can also specifically include the following: Step S301: According to the preset evolution suggestion merging rules, align the failure mode, the improvement requirement and the ability gap according to the skill ability item they point to, merge multiple evolution clues pointing to the same skill ability item and resolve contradictory improvement directions, and label the weights according to the source credibility and occurrence frequency. Step S302: The merged evolutionary clues are encapsulated into evolutionary suggestions according to the suggestion identifier, target skill ability item, suggestion content and weight field. The evolutionary suggestions are written into the evolution review draft pool and added to the queue to be reviewed. When the draft capacity exceeds the preset threshold condition, evolutionary suggestions with weights lower than the threshold condition are eliminated.

[0052] After the failure modes, improvement needs, and capability gaps extracted in step S101 are ready, the evolutionary suggestions are merged, such as... Figure 3 As shown. The merging layer aligns the failure modes, improvement requirements, and capability gaps according to preset evolutionary suggestion merging rules, based on their respective pointing skill capability items. The skill capability items are encoded using the action node identifiers within the skill pack, and the alignment is based on the target skill capability items recorded according to the evolutionary cues.

[0053] The evolutionary cues are grouped and merged according to the target skill ability items, such as... Figure 3As shown, multiple evolutionary clues pointing to the same skill or ability are merged into one. The source category and frequency of occurrence of each clue are retained during the merging process. For evolutionary clues pointing to the same skill or ability but with contradictory improvement directions, conflict resolution is performed. Conflict resolution is performed, and the suppressed clues are selected and registered based on the credibility of their source and the frequency of occurrence.

[0054] Based on this, the merged evolutionary clues are weighted according to source credibility and frequency of occurrence. Source credibility is preset with initial values ​​based on the source categories of failed operation logs, user feedback, and missed issues. Frequency of occurrence is measured by the cumulative number of times the evolutionary clue appears in the statistics window. The weight is obtained by weighting source credibility and normalized frequency of occurrence, and the weighting coefficients used to determine the weights are based on historical adoption rates.

[0055] The merged evolutionary cues are encapsulated according to the suggestion identifier, target skill ability item, suggestion content, and weight field to generate evolutionary suggestions, such as... Figure 3 As shown. The suggestion identifier is a globally unique code, and the suggestion content records the suggested improvement actions and source clues. Evolutionary suggestions use the suggestion identifier as the primary key.

[0056] The evolutionary suggestions are written into the evolutionary review draft pool and added to the queue awaiting review, such as Figure 4 As shown. The evolution review draft pool is stored with the suggestion identifier as the primary key. The queue to be reviewed is sorted in descending order of weight and ascending order of submission time. The draft status is initially set to pending editing, so that step S401 can read it at the review entry point.

[0057] When the draft pool size exceeds a preset threshold, evolutionary suggestions with a weight below the threshold are eliminated and marked as eliminated. The elimination threshold is determined based on the draft pool size and historical adoption distribution. Eliminated evolutionary suggestions are moved to the archive area for retention. When similar evolutionary clues reappear and their cumulative weight recovers, they are re-added to the review queue, thereby maintaining a controllable draft pool size.

[0058] In one embodiment of the agent skill pack evolution closed loop and version immutability governance method of this application, see [link to relevant documentation]. Figure 4 It can also specifically include the following: Step S401: The skill creator retrieves evolution suggestions from the queue of drafts to be reviewed in the evolution review pool, modifies the prompt word template and flow arrangement of the skill pack according to the evolution suggestions to generate a change draft, and registers a draft exception mark for change drafts that fail the basic verification of syntax and flow connectivity and returns them to the editor. Step S402: The reviewer verifies the scope of the changes and compliance constraints of the draft changes. The draft changes that pass the verification are packaged together with the version metadata to form a candidate skill package version. The draft changes that are rejected are returned to the editor with the rejection comments and the rejection mark is registered in the draft status.

[0059] After the evolutionary suggestions in step S301 are written into the evolutionary review draft pool, editing and review are performed, such as... Figure 4 As shown, the draft pool review layer maintains a queue of drafts awaiting review. The queue is sorted by the weight of the evolutionary suggestion and the submission time. The draft status can be selected as pending editing, editing, pending review, or encapsulated. The status transition records the operator's identifier and timestamp, which supports the parallel progress of editing and review.

[0060] Skill creators retrieve evolutionary suggestions for editing from the waiting queue of the evolutionary review draft pool, such as... Figure 4 As shown. When retrieving the draft, the draft is set to "editing" and locked to prevent concurrent editing. The retrieved evolution suggestions include the target skill / ability items and suggested content, providing a basis for modifying the prompt template and flow arrangement.

[0061] Based on the aforementioned evolutionary recommendations, the prompt templates and workflow of the skill pack are modified to generate a draft change. The draft change records the differences in prompts, the addition or deletion of workflow nodes, and parameter adjustments. The draft change is organized using a draft identifier, a source recommendation identifier, and a difference content field, with the draft identifier as the primary key linked to the source evolutionary recommendation.

[0062] Perform basic syntax and flow connectivity checks on the draft amendments, such as... Figure 4 As shown. The basic verification checks the grammatical validity of the prompt word template and the connectivity of the nodes in the workflow arrangement. Draft changes that fail the basic verification are marked with a draft exception and returned to editing. The draft exception mark records the failed verification items. After editing and correction, the draft re-enters the basic verification process.

[0063] The reviewers verify the scope of changes and compliance constraints of the draft changes that have passed the basic verification. The scope of changes is verified to ensure that the modifications do not exceed the skill and capability items suggested in the recommendations. The compliance constraints are verified to ensure that the modifications comply with the data access and operation compliance requirements for parking lot operations. Verification is performed based on the compliance rule set, and the verification conclusion records the reviewer's identification and review comments.

[0064] The approved draft changes, along with version metadata, are encapsulated to form a candidate skill pack version, such as... Figure 4 As shown. The version metadata records the source suggestion identifier, editor, reviewer and packaging time. The candidate skill package version is written to the candidate version library with the candidate identifier as the primary key. The rejected change draft is returned to the editor with the rejection comments and the rejection identifier is registered in the draft status, so that step S501 can read the candidate skill package version at the triple verification entry.

[0065] In one embodiment of the agent skill pack evolution closed loop and version immutability governance method of this application, see [link to relevant documentation]. Figure 4 It can also specifically include the following: Step S501: Load the candidate skill package version into the isolation sandbox and run the evaluation test according to the preset evaluation test set. Divide the test set into regular test cases, boundary test cases and historical failure test cases, and compare the actual output with the expected output to calculate the pass rate. Candidate skill package versions with a pass rate lower than the preset threshold condition are judged to have failed the behavior verification. Step S502: Compare the permission list of the candidate skill package version with its earlier version to identify newly added permission items, compare the risk level of the candidate skill package version with its earlier version to identify changes in risk level, mark the newly added high-risk permission items and the candidate skill package versions with increased risk level as pending manual confirmation, summarize and generate triple verification results and determine access.

[0066] After the candidate skill package version encapsulated in step S401 is ready, perform triple verification, such as... Figure 4 As shown. The triple verification layer loads the candidate skill package version within an isolation sandbox. The isolation sandbox is isolated from the production environment and limits the scope of resources it can access. Candidate skill package versions that fail to load are registered with a loading error flag and returned to the packaging stage.

[0067] The candidate skill package version is evaluated and tested according to a preset evaluation test set to verify the correctness of its behavior. Figure 4 As shown, the evaluation test set is divided into regular test cases, boundary test cases, and historical failure test cases. Historical failure test cases are taken from the representative call stack of the failure execution log. The pass rate is calculated by comparing the actual output with the expected output. Timeout test cases are downgraded after retry.

[0068] Candidate skill pack versions with a pass rate below a preset threshold are deemed to have failed behavior verification. The pass rate threshold is set based on the historical pass rate of previous versions. Candidate skill pack versions that fail behavior verification are returned to the editor with a list of failed test cases. Based on this, a permission difference comparison is performed on candidate skill pack versions that pass behavior verification.

[0069] The candidate skill pack version is compared with its earlier version to identify newly added permission items by comparing the permission list, such as... Figure 4 As shown. The permission list records the parking lot business system interfaces and data ranges that the skill package can access. The differences are compared item by item between the old and new permission lists. Candidate skill package versions with newly added high-risk permission items are marked as pending manual confirmation. High-risk permission items are determined according to the preset permission risk classification table.

[0070] The risk level of each candidate skill package version is compared with its earlier version to identify changes in risk level. The risk level is assessed based on the operational impact and reversibility of the skill package. The risk levels of the new and old versions are compared. Candidate skill package versions with an increased risk level are marked as requiring manual confirmation with a risk change explanation. Candidate skill package versions requiring manual confirmation are reviewed by the human reviewer and a confirmation conclusion is then written back.

[0071] The results of the behavior correctness verification, the permission difference comparison, and the risk level difference comparison are combined to generate a triple verification result and determine access. Figure 4 As shown. The triple verification result uses the candidate identifier as the primary key, records the conclusion of each verification item and the mark of pending manual confirmation. The candidate skill package version that passes all three verifications and has no mark of pending manual confirmation is determined to be admitted, and is read by step S601 at the release entry.

[0072] In one embodiment of the agent skill pack evolution closed loop and version immutability governance method of this application, see [link to relevant documentation]. Figure 5 It can also specifically include the following: Step S601: Calculate the hash fingerprint of the serialized content of the candidate skill package version that has passed the admission and assign a monotonically increasing version number. Add the version content, the hash fingerprint and the version number together to the append-only version chain to generate an immutable version. Each node of the version chain records the parent version reference. Step S602: Set a read-only constraint on the immutable version to prohibit modification of the published content. Write the published exception flag when the hash verification fails and retry. If the number of retries exceeds the preset number, manual intervention is required. When an upgrade request is received, create a new candidate draft based on the version chain and re-enter the review loop.

[0073] After step S501 determines that the candidate skill pack version for admission is ready, an immutable release is performed, such as... Figure 5 As shown. The immutable release layer calculates a hash fingerprint for the serialized content of the candidate skill package version that has passed the admission. The serialization encodes the prompt word template, process arrangement, and permission list in an ordered manner according to a preset specification format. The hash fingerprint is generated using a cryptographic hash function and uniquely identifies the version content.

[0074] Assign monotonically increasing version numbers to the candidate skill pack versions, such as... Figure 5 As shown. The version number monotonically increases within the same skill pack. The version number allocator records the current maximum version number and atomically increments it to avoid duplicate numbers caused by concurrent releases. If allocation fails, a release exception flag is registered and the process is retried.

[0075] The version content, the hash fingerprint, the version number, the release time, and the admission criteria are all appended to the append-only version chain to generate an immutable version, such as... Figure 5 As shown, each node in the append-only version chain records a parent version reference and a hash fingerprint. The parent version reference points to the earlier version of the skill pack. The version chain only allows nodes to be appended to the end and does not allow modifications to existing nodes.

[0076] Set a read-only constraint on the immutable version to prevent modification of the published content, such as Figure 5As shown. Read-only constraints disable write permissions for published nodes in the storage layer, reject all modification requests for published content and register violation flags, thereby ensuring that published versions are not overwritten.

[0077] After writing, a hash verification is performed. The hash fingerprint of the written node is recalculated and compared with the registered fingerprint. If the hash verification fails, an exception is marked for writing and publishing and a retry is performed. If the number of retries exceeds the preset number, manual intervention is initiated. The upper limit of the number of retries is determined based on the storage reliability. After the manual intervention result is written back, the publishing process is restarted.

[0078] Upon receiving an upgrade request, a new candidate draft is created based on the version chain, and the review loop in step S102 is re-entered. Published immutable versions remain unchanged. Figure 5 As shown. When a rollback request is received, the existing stable version is located on the version chain by version number and marked as the current version. The rollback record records the version number before and after the rollback and the operation timestamp. For immutable versions, the version number is used as the primary key for step S701 to read at the push entry point.

[0079] In one embodiment of the agent skill pack evolution closed loop and version immutability governance method of this application, see [link to relevant documentation]. Figure 6 It can also specifically include the following: Step S701: Maintain the installation association table between workspaces and skill packs, determine the target workspaces that have subscribed to the skill packs based on the installation association table, automatically push the immutable version to the target workspaces according to the batching strategy of first gray-scale batch and then full batch, and update the installed version number. For workspaces that fail to push, register the push error flag and retry according to the backoff strategy. Step S702: Collect the running feedback of the target workspace on the immutable version, and return the records of abnormal running results in the running feedback to the failure running log and evolution suggestion collection. Based on the returned running feedback, trigger the generation of the next round of evolution suggestions to form an evolutionary closed loop.

[0080] After the immutable version released in step S601 is ready, execute the automatic push, such as... Figure 6 As shown. The automatic push layer maintains an installation association table for workspaces and skill packs. The installation association table uses the workspace identifier and skill pack identifier as a composite primary key, and records the installed version number and subscription status. The subscription status takes the values ​​of "subscribed" and "unsubscribed".

[0081] Based on the installation association table, determine the target workspace that has subscribed to the skill pack, such as... Figure 6 As shown. The target workspace set is obtained by filtering records with a subscription status of "subscribed," which provides the target range for batch push notifications. The target workspace set is updated synchronously when the installation association table changes.

[0082] The immutable version is automatically pushed to the target workspace and the installed version number is updated according to a batching strategy of first gray-scale batching and then full batching. Figure 6 As shown. The gray-scale batch first selects a portion of the target workspaces for push and observes their operational feedback. After the gray-scale batch meets the criteria, it is pushed to the remaining target workspaces in full. The gray-scale compliance condition is determined based on the call success rate threshold.

[0083] Workspaces that fail to push notifications are registered with a push exception flag and retried according to a backoff strategy. The backoff interval increases with the number of retries. Workspaces that exceed the preset number of retries are transferred to a manual investigation queue. Based on this, the push results of the target workspace are tracked in a closed loop.

[0084] Collect runtime feedback from the target workspace on the immutable version, such as Figure 6 As shown. The operational feedback includes call success rate, failure records, and user feedback. The operational feedback is aggregated using the workspace identifier and version number as a joint primary key, providing a source of feedback data for the evolutionary closed loop.

[0085] Records of abnormal execution results in the execution feedback will be fed back to the failure execution log and evolution suggestion collection, such as... Figure 6 As shown. The reflow record is appended to the failed operation log with the operation identifier as the primary key. Based on the operation feedback of the reflow, the next round of evolution suggestions in step S101 is triggered to generate, forming an evolutionary closed loop of collection, merging, review, verification, release and push.

[0086] To implement all or part of the method, this application provides an embodiment of an apparatus for implementing the intelligent agent skill package evolution closed loop and version immutability governance method, see [link to embodiment]. Figure 2 The device specifically includes the following components: The evolution suggestion collection module is used to collect multi-source operation feedback of skill packs and extract failure patterns from failure operation logs by clustering error codes and call stack summaries, extract improvement needs from user feedback by classifying them according to a preset intent dictionary, extract capability gaps by comparing the skill coverage of missed issues, and aggregate and generate evolution suggestions according to preset evolution suggestion merging rules. The draft pool review module is used to write evolution suggestions into the evolution review draft pool and add them to the queue for review. Skill creators modify the prompt word template and process arrangement of the skill package to generate a change draft. After the reviewers verify the scope of changes and compliance constraints, the change draft is packaged to form a candidate skill package version. The triple verification module is used to evaluate and test the candidate skill package version within an isolated sandbox to verify the correctness of its behavior, compare the permission differences and risk level differences between the candidate skill package version and its previous version, summarize and generate triple verification results, and determine the admission of the candidate skill package version. The immutable release module is used to calculate the hash fingerprint of the candidate skill package version that has passed the admission and assign a monotonically increasing version number, append the version content and the hash fingerprint to the append-only version chain and release it as an immutable version, set read-only constraints on the immutable version, and create a new candidate draft based on the version chain when an upgrade request is received to re-enter the review closed loop. The automatic push feedback module is used to determine the subscribed target workspace based on the workspace and skill pack installation association table and automatically push the immutable version to the target workspace. It collects the running feedback after the push and returns the records of abnormal running results to the failure running log to form an evolutionary closed loop.

[0087] The evolution suggestion collection module gathers multi-source runtime feedback for the skill package. At the end of each skill package run, it aggregates runtime feedback based on runtime identifier, skill package identifier, error code, call stack summary, and runtime context. Runtime feedback with abnormal results is added to the failure runtime log, user evaluation text is added to user feedback, and requests that failed to hit are added to missed issues. The failure runtime log is bucketed by error code, and call stack summary similarity is compared within each bucket to extract failure patterns. User feedback is categorized according to a preset intent dictionary to extract improvement needs. Missed issues are compared to the difference set of skill coverage to extract capability gaps. Based on preset evolution suggestion merging rules, the three types of evolution clues are aligned and merged according to target skill capability items, and weighted to generate evolution suggestions. The draft pool review module writes the evolution suggestions into the evolution review draft pool and adds them to the review queue. Skill creators modify the skill package's prompt word template and process arrangement to generate a change draft. Reviewers verify the scope of changes and compliance constraints, then encapsulate the change draft along with version metadata to form a candidate skill package version.

[0088] The triple verification module loads the candidate skill package version within an isolated sandbox and performs evaluation tests based on a preset evaluation test set to verify the correctness of the behavior. It compares the actual output with the expected output to calculate the pass rate. It compares the permission list differences between the candidate skill package version and its predecessor to identify newly added permission items, and compares the risk level differences to identify changes in risk level. Candidate skill package versions with newly added high-risk permission items and increased risk levels are marked as requiring manual confirmation. The triple verification results are then summarized and admission is determined. The immutable release module calculates a hash fingerprint for the serialized content of the admitted candidate skill package versions and assigns a monotonically increasing version number. The version content, hash fingerprint, version number, release time, and admission criteria are appended to an append-only version chain to generate an immutable version. A read-only constraint is set on the immutable version to prevent modification of the published content. Upon receiving an upgrade request, a new candidate draft is created based on the version chain, and the review loop is re-entered.

[0089] The automatic push feedback module maintains the installation association table between workspaces and skill packages and determines the target workspaces that have subscribed to the skill packages based on the installation association table. It automatically pushes the immutable version to the target workspaces and updates the installed version number according to a batch strategy of first gray-scale batch and then full batch. Workspaces that fail to push are registered with a push exception flag and retried according to the backoff strategy. The module collects the running feedback of the target workspaces on the immutable version and feeds back records of abnormal running results in the running feedback to the failure running log and evolution suggestion collection module. Based on the fed-back running feedback, the module triggers the generation of the next round of evolution suggestions. It works in conjunction with the evolution suggestion collection module, draft pool review module, triple verification module and immutable release module to form an evolutionary closed loop of collection, review, verification, release and push.

[0090] As can be seen from the above description, the intelligent agent skill package evolution closed-loop and version immutability management device provided in this application embodiment can perform closed-loop evolution and version immutability management of the skill package of the parking lot operation intelligent agent through the collaboration of five modules: evolution suggestion collection, draft pool review, triple verification, immutable release and automatic push backflow.

[0091] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described method.

[0092] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0093] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method.

[0094] In this embodiment, evolutionary suggestions are generated and written into a draft pool by collecting data from multiple sources, including failed operation logs, user feedback, and missed issues, and aggregating them according to merging rules. These suggestions are then reviewed by skill creators and reviewers to form candidate skill package versions, which undergo a triple check for behavioral correctness, permission differences, and risk level differences to determine admission. Hash fingerprints are calculated on the approved candidate skill package versions and appended to the version chain for publication as immutable versions. The installation process automatically pushes these versions to subscribed workspaces and collects operational feedback, which is then fed back to the failed operation logs and evolutionary suggestion collection, forming an evolutionary closed loop of collection, review, verification, publication, and push.

[0095] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for managing the evolutionary closed loop and version immutability of an agent's skill pack, characterized in that, The method includes: Collect multi-source operational feedback of skill packs, extract failure modes from failure operation logs, extract improvement requirements from user feedback, extract capability gaps from missed issues, and align the failure modes, improvement requirements and capability gaps with their respective target skill capability items according to preset evolution suggestion merging rules to generate evolution suggestions and write them into the evolution review draft pool, wherein the evolution review draft pool is used to store the evolution suggestions. The evolution suggestions in the evolution review draft pool are edited by skill creators and reviewed by reviewers to form candidate skill package versions. According to the preset triple verification rules, the candidate skill package versions are evaluated, tested and run in an isolated sandbox to verify the correctness of the behavior, compare the differences in permissions between the old and new versions, compare the differences in risk levels between the old and new versions, generate triple verification results, and determine admission. Calculate the hash fingerprint of the candidate skill pack version that has passed the admission and append it to the version chain to publish it as an immutable version. Set read-only constraints on the immutable version to prevent modification of the published content. Automatically push the immutable version to the subscribed workspaces according to the workspace installation association. The running feedback after the push is fed back to the failure running log to form an evolutionary closed loop.

2. The method for managing the evolutionary closed loop and version immutability of agent skill packages according to claim 1, characterized in that, The multi-source operational feedback of the skill collection package extracts failure patterns from failed operation logs, improvement requirements from user feedback, and capability gaps from missed issues, including: At the end of each run of the skill pack, the run feedback is collected according to the preset run feedback field template. The run feedback with abnormal results is imported into the failure run log, the user's evaluation text of the run results is imported into the user feedback, and the requests that fail to hit are imported into the missed issues. The failed operation logs are bucketed by error code, and the failure patterns are extracted by clustering the call stack summary similarity within the bucket. The user feedback is categorized according to a preset intent dictionary to extract improvement requirements. The missing issues are compared with the difference between the request intent and the skill coverage to extract capability gaps.

3. The method for closed-loop evolution and version immutability governance of intelligent agent skill packages according to claim 1, characterized in that, The process of aligning the failure modes, improvement needs, and capability gaps according to their respective corresponding skill / capability items, based on preset evolution suggestion merging rules, and then aggregating them to generate evolution suggestions, which are then written into the evolution review draft pool, includes: According to the preset evolutionary suggestion merging rules, the failure mode, the improvement requirements and the capability gap are aligned with the skill and capability items they point to. Multiple evolutionary clues pointing to the same skill and capability item are merged and contradictory improvement directions are resolved. Weights are marked according to the credibility of the source and the frequency of occurrence. The merged evolutionary clues are encapsulated into evolutionary suggestions by suggestion identifier, target skill ability item, suggestion content and weight field. The evolutionary suggestions are written into the evolution review draft pool and added to the queue to be reviewed. When the draft capacity exceeds the preset threshold condition, evolutionary suggestions with weights lower than the threshold condition are eliminated.

4. The method for closed-loop evolution and version immutability governance of intelligent agent skill packages according to claim 1, characterized in that, The process of generating candidate skill pack versions by editing evolution suggestions from the evolution review draft pool and reviewing them by skill creators and reviewers includes: The skill creator retrieves evolution suggestions from the queue of drafts to be reviewed in the evolution review pool, modifies the prompt word template and process arrangement of the skill pack according to the evolution suggestions, generates a change draft, and registers a draft exception mark for change drafts that fail the basic checks of syntax and process connectivity and returns them to the editor. The reviewers verify the scope of the changes and compliance constraints of the draft changes. The approved draft changes, along with the version metadata, are packaged into a candidate skill package version. The rejected draft changes are returned to the editor with the rejection comments and a rejection mark is registered in the draft status.

5. The method for managing the evolutionary closed loop and version immutability of agent skill packages according to claim 1, characterized in that, The process of evaluating and testing the candidate skill pack version within an isolated sandbox according to preset triple verification rules, verifying the correctness of the behavior, comparing the permission differences between the old and new versions, comparing the risk level differences between the old and new versions, generating triple verification results, and determining admission includes: The candidate skill package version is loaded into the isolation sandbox and evaluated according to the preset evaluation test set. The test set is divided into regular test cases, boundary test cases and historical failure test cases. The actual output is compared with the expected output to calculate the pass rate. The candidate skill package version with a pass rate lower than the preset threshold condition is judged to have failed the behavior verification. The candidate skill package version is compared with its earlier version to identify newly added permission items by comparing the permission list differences. The candidate skill package version is also compared with its earlier version to identify changes in risk level by comparing the risk level differences. Newly added high-risk permission items and candidate skill package versions with increased risk levels are marked as pending manual confirmation. The results of the triple verification are then summarized and admission is determined.

6. The method for managing the evolutionary closed loop and version immutability of agent skill packages according to claim 1, characterized in that, The process of calculating the hash fingerprint of the candidate skill package version that has passed the admission process and appending it to the version chain for publication as an immutable version, and setting a read-only constraint on the immutable version to prevent modification of the published content, includes: Calculate a hash fingerprint for the serialized content of the candidate skill pack version that has passed the admission and assign a monotonically increasing version number. Then, append the version content, the hash fingerprint, and the version number to the append-only version chain to generate an immutable version. Each node in the version chain records a parent version reference. The immutable version is set to read-only to prevent modification of the published content. If the hash verification fails, an exception is recorded and the version is retried. If the number of retries exceeds the preset number, manual intervention is required. When an upgrade request is received, a new candidate draft is created based on the version chain and the review loop is restarted.

7. The method for managing the evolutionary closed loop and version immutability of agent skill packages according to claim 1, characterized in that, The process of automatically pushing the immutable version to subscribed workspaces based on workspace installation associations, and then feeding back the evolutionary closed loop to the failure log based on the operational feedback after the push, includes: Maintain the installation association table between workspaces and skill packs, and determine the target workspaces that have subscribed to the skill packs based on the installation association table. Automatically push the immutable version to the target workspaces and update the installed version number according to the batch strategy of first gray batch and then full batch. For workspaces that fail to push, register the push error mark and retry according to the backoff strategy. The target workspace is collected for runtime feedback on the immutable version. Records of abnormal runtime results in the runtime feedback are fed back to the failure runtime log and evolution suggestion collection. The next round of evolution suggestion generation is triggered based on the fed-back runtime feedback to form an evolutionary closed loop.

8. A closed-loop evolution and version immutability management device for intelligent agent skill packages, characterized in that, The device includes: The evolution suggestion collection module is used to collect multi-source operation feedback of skill packs and extract failure patterns from failure operation logs by clustering error codes and call stack summaries, extract improvement needs from user feedback by classifying them according to a preset intent dictionary, extract capability gaps by comparing the skill coverage of missed issues, and aggregate and generate evolution suggestions according to preset evolution suggestion merging rules. The draft pool review module is used to write evolution suggestions into the evolution review draft pool and add them to the queue for review. The evolution review draft pool is used to store the evolution suggestions. Skill creators modify the prompt word template and process arrangement of the skill package to generate a change draft. After the reviewers verify the scope of changes and compliance constraints, the change draft is packaged to form a candidate skill package version. The triple verification module is used to evaluate and test the candidate skill package version within an isolated sandbox to verify the correctness of its behavior, compare the permission differences and risk level differences between the candidate skill package version and its previous version, summarize and generate triple verification results, and determine the admission of the candidate skill package version. The immutable release module is used to calculate the hash fingerprint of the candidate skill package version that has passed the admission and assign a monotonically increasing version number, append the version content and the hash fingerprint to the append-only version chain and release it as an immutable version, set read-only constraints on the immutable version, and create a new candidate draft based on the version chain when an upgrade request is received to re-enter the review closed loop. The automatic push feedback module is used to determine the subscribed target workspace based on the workspace and skill pack installation association table and automatically push the immutable version to the target workspace. It collects the running feedback after the push and returns the records of abnormal running results to the failure running log to form an evolutionary closed loop.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the intelligent agent skill package evolution closed loop and version immutability governance method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the intelligent agent skill package evolutionary closed-loop and version immutable governance method as described in any one of claims 1 to 7.

Images