Cross-node synchronization method for skill version management of nested double-layer git repository intelligent agent

Abstract

This invention provides a cross-node synchronization method for skill version management based on a nested two-layer Git repository intelligent agent. This method constructs an outer main repository and multiple inner skill sub-repositories. The outer layer excludes inner sub-repositories through ignore rules, decoupling application versions from skill versions. Each inner sub-repository is an independent Git repository, storing the corresponding level of skill files. In response to skill modifications, an edit copy is created from the inner sub-repository. After submission to a feature branch, approval, and merging, a timestamp tag is generated on the default branch. Each stateless node periodically pulls the remote tag from the inner sub-repository and compares it with the local tag. If they are inconsistent, a new tag is detected and added to a temporary working area. After successful verification, the skill directory is atomically switched and the cache is invalidated, achieving hot reloading without restarting the process. This invention achieves decoupling of skills and applications, multi-level isolated version management, change auditing and rollback, and consistent synchronization across nodes.

Description

Technical Field

[0001] This invention relates to the field of intelligent agent platform technology, and in particular to a cross-node synchronization method for intelligent agent skill version management based on nested two-layer Git repositories. Background Technology

[0002] Existing intelligent agent platforms typically place skill files and application code in the same repository or release process. Skill files include skill description files (SKILL.md), executable scripts, dependency declarations, etc. When skill descriptions, invocation scripts, dependency declarations, or security policies need to be adjusted, it is often necessary to rebuild, release, or restart the service along with the application, resulting in long skill iteration cycles. Furthermore, even a small change to a skill can affect the release schedule of the entire platform. In multi-team, multi-tenant, or multi-level skill systems, system-level skills, organization-level extended skills, third-party extended skills, and user-private skills are often managed in a mixed manner. Relying solely on manual file copying, single-level repository branches, or runtime directory overwriting makes it difficult to simultaneously meet the requirements for isolation, auditing, rollback, approval, and difference comparison, easily leading to problems such as unclear skill sources, untraceable versions, accidental overwriting, and unauthorized modifications.

[0003] As agent platforms evolve towards large-scale and engineering-oriented development, the industry is beginning to explore incorporating version control concepts into the agent development process. However, for stateless agent clusters deployed using Kubernetes or similar methods, each node typically caches the skill list and skill file content locally. If a node updates a skill but other nodes fail to synchronize in time, the same user request may hit different versions of the skill on different nodes, resulting in inconsistent behavior. Existing Git submodules or CI / CD solutions primarily focus on application building and deployment, without directly addressing the hierarchical isolation, cache invalidation, and runtime synchronization issues of agent skills throughout the entire chain from editing, difference comparison, approval and merging, tag publishing to node hot reloading. Summary of the Invention

[0004] To address the aforementioned technical problems in related technologies, this invention proposes a cross-node synchronization method for skill version management based on nested two-layer Git repository agents, which can overcome the above-mentioned shortcomings of existing technologies.

[0005] To achieve the above-mentioned technical objectives, the technical solution of the present invention is implemented as follows: A cross-node synchronization method for skill version management based on nested two-layer Git repository agents; This method for cross-node synchronization of skill version management based on nested two-layer Git repository agents includes: A nested two-layer Git repository structure is constructed, which includes an outer main repository and multiple inner skill sub-repositories. The outer main repository stores the agent application code, skill loader, and cache manager. The outer main repository excludes each of the inner skill sub-repositories through an ignore rule, so that the application version release of the outer main repository is decoupled from the skill version release of the inner skill sub-repositories. Each inner-layer skill sub-repository is an independent Git repository, storing skill files of the corresponding level. The skill files include at least a skill description file and an executable script. In response to a modification request for a target skill, an isolated edit copy is created from its inner-layer skill sub-repository, and the skill modification is completed in the edit copy; The modified skill is submitted to the feature branch of the inner skill sub-repository, and after approval, it is merged into the default branch. A timestamp tag or semantic version tag is generated on the current commit of the default branch. Each stateless service node retrieves remote tags from the inner skill sub-repository at a preset period and compares the latest remote tags with the locally loaded tags. If the latest remote tag is inconsistent with the locally loaded tag, the node will check out the skill content corresponding to the latest remote tag to the temporary work area. After the verification is passed, the node will atomically switch the current skill visibility directory to the temporary work area and invalidate the corresponding skill cache to achieve hot loading of skills. The node continues to run after the hot reload is completed without restarting the application process.

[0006] Furthermore, the outer main repository excludes each of the inner skill sub-repositories through ignore rules, including: setting a skill mounting directory in the root directory of the outer main repository, configuring ignore rules in the ignore file to exclude each inner skill sub-repository under the skill mounting directory, and retaining the directory description file of the skill mounting directory; or, the inner skill sub-repository is registered in the outer main repository as a Git submodule, and the outer main repository records the submodule references without committing the skill content.

[0007] Furthermore, the skill file also includes at least one of dependency declaration files, test cases, metadata manifests, and hook scripts; each of the inner skill sub-repositories corresponds to one of the following levels: system-level shared skills, organization-level extended skills, third-party extended skills, and user-private skills; the skill loader generates a unique skill version identifier based on the repository path, skill name, level, default branch, current tag, and skill file hash value of the inner skill sub-repository.

[0008] Furthermore, after the skill modification is completed in the edit copy and before it is submitted to the feature branch, at least one of the following verification operations is included: performing format verification, directory structure verification, cross-level import prohibition verification, script executability verification, and regression testing.

[0009] Furthermore, before submitting the modified skill to the feature branch, the process includes: using the baseline tag or default branch submission of the inner skill sub-repository as a benchmark, and the edited copy or the feature branch as a comparison object, generating structured difference information. The difference information includes at least one or more of the following: adding skill files, deleting skill files, modifying skill files, changing the content of skill description files, script changes, dependency changes, permission changes, and test results. The difference information is then used as the basis for approval.

[0010] Furthermore, the timestamp tag or semantic version tag annotation records at least one of the following: approval number, changed skill list, submitter information, approver information, and test results; after the tag is generated, a version index file is generated in the inner skill sub-repository. The version index file records at least one of the following: repository name, tag name, submission hash value, skill list, hash value of each skill file, and dependency summary. The version index is used for version comparison and hot reloading judgment during node synchronization.

[0011] Furthermore, the preset period is between 10 and 60 seconds, with a default value of 30 seconds; the nodes determine the latest stable labels by sorting them according to the timestamps in the names of the labels.

[0012] Furthermore, the skill cache corresponding to the failure includes at least one of the following: a cache of failed skill lists, a cache of skill description file content, a cache of prompt words, a cache of script paths, and a cache of executor dependencies, based on the dimensions of the inner skill sub-repository identifier, tag, skill name, and file hash value; the node checks out the skill content corresponding to the latest tag from the remote end to the temporary work area through the Git worktree method, and performs the atomic switch through symbolic link atomic switch or directory atomic switch.

[0013] Furthermore, when a node fails during the fetching, verification, detection, or hot reloading process, it continues to provide services for the skill content corresponding to the previous available tag and records the synchronization failure event. When a skill version needs to be rolled back, a rollback tag pointing to the previous stable commit is created in the default branch or version index of the inner skill sub-repository, and each node automatically converges to the rollback version by tracking the rollback tag.

[0014] Furthermore, the node tracks the remote tag by periodically pulling data, or by combining periodic pulling with any one or more of the following methods: Webhook notifications, message queue notifications, and Redis publish / subscribe notifications.

[0015] The beneficial effects of this invention are as follows: By excluding inner independent Git skill sub-repositories through an outer main repository using ignore rules, skill version evolution is decoupled from application version, avoiding minor skill changes from triggering overall build deployment; by assigning skills at each level to different inner sub-repositories and having their own independent branches and approval processes, multi-level isolated version management is achieved; through a complete chain of feature branches, approval records, default branch merging commits, and timestamp tags, each skill release is ensured to be auditable, traceable, and rollbackable; by periodically tracking the latest tags of inner sub-repositories and comparing them with local versions through stateless cluster nodes, cache invalidation and hot reloading are triggered upon detecting changes, allowing each node to converge to a consistent skill version in a short time without restarting the application process. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the overall process of the cross-node synchronization method for skill version management based on nested two-layer Git repository agents described in this invention. Detailed Implementation

[0018] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," and "counterclockwise," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0020] 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 indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified. Furthermore, the terms "installed," "connected," and "linked" should be interpreted broadly; for example, they may refer to a fixed connection, a detachable connection, or an integral connection; they may refer to a mechanical connection or an electrical connection; they may refer to a direct connection or an indirect connection through an intermediate medium; and they may refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0021] like Figure 1 As shown in the embodiment of the present invention, the cross-node synchronization method for skill version management based on nested two-layer Git repository agents includes: A nested two-layer Git repository structure is constructed, which includes an outer main repository and multiple inner skill sub-repositories. The outer main repository stores the agent application code, skill loader, and cache manager. The outer main repository excludes each of the inner skill sub-repositories through an ignore rule, so that the application version release of the outer main repository is decoupled from the skill version release of the inner skill sub-repositories. Each inner-layer skill sub-repository is an independent Git repository, storing skill files of the corresponding level. The skill files include at least a skill description file and an executable script. In response to a modification request for a target skill, an isolated edit copy is created from its inner-layer skill sub-repository, and the skill modification is completed in the edit copy; The modified skill is submitted to the feature branch of the inner skill sub-repository, and after approval, it is merged into the default branch. A timestamp tag or semantic version tag is generated on the current commit of the default branch. Each stateless service node retrieves remote tags from the inner skill sub-repository at a preset period and compares the latest remote tags with the locally loaded tags. If the latest remote tag is inconsistent with the locally loaded tag, the node will check out the skill content corresponding to the latest remote tag to the temporary work area. After the verification is passed, the node will atomically switch the current skill visibility directory to the temporary work area and invalidate the corresponding skill cache to achieve hot loading of skills. The node continues to run after the hot reload is completed without restarting the application process.

[0022] According to an embodiment of the present invention, the cross-node synchronization method for skill version management based on nested two-layer Git repositories, in a specific implementation, involves the outer main repository excluding each of the inner skill sub-repositories by means of an ignore rule. This includes: setting a skill mounting directory in the root directory of the outer main repository, configuring an ignore file to exclude each inner skill sub-repository under the skill mounting directory by means of an ignore rule, and retaining the directory description file of the skill mounting directory; or, the inner skill sub-repository is registered in the outer main repository as a Git submodule, and the outer main repository records the submodule reference without committing the skill content.

[0023] According to an embodiment of the present invention, the cross-node synchronization method for skill version management based on nested two-layer Git repository intelligence, in a specific implementation, the skill file further includes at least one of dependency declaration files, test cases, metadata manifests, and hook scripts; each inner skill sub-repository corresponds to one of the following levels: system-level shared skills, organization-level extended skills, third-party extended skills, and user-private skills; the skill loader generates a unique skill version identifier based on the repository path, skill name, level, default branch, current tag, and skill file hash value of the inner skill sub-repository.

[0024] According to an embodiment of the present invention, the cross-node synchronization method for skill version management based on nested two-layer Git repository agents, in a specific implementation, after the skill modification is completed in the edit copy and before it is committed to the feature branch, further includes: performing at least one of the following verification operations: format verification, directory structure verification, cross-layer import prohibition verification, script executability verification, and regression testing.

[0025] According to an embodiment of the present invention, the cross-node synchronization method for skill version management based on nested two-layer Git repository agents, in a specific implementation, before submitting the modified skill to the feature branch, further includes: using the baseline tag or default branch submission of the inner skill sub-repository as a baseline, and the edited copy or the feature branch as a comparison object, generating structured difference information, wherein the difference information includes at least one or more of the following: adding skill files, deleting skill files, modifying skill files, changing the content of skill description files, script changes, dependency changes, permission changes, and test results, and using the difference information as the basis for approval.

[0026] According to an embodiment of the present invention, the cross-node synchronization method for skill version management based on nested two-layer Git repository agents, in a specific implementation, records at least one of the following in the annotation of the timestamp tag or semantic version tag: approval number, changed skill list, submitter information, approver information, and test results; after the tag is generated, a version index file is generated in the inner skill sub-repository. The version index file records at least one of the following: repository name, tag name, submission hash value, skill list, hash value of each skill file, and dependency summary. The version index is used for version comparison and hot reloading judgment during node synchronization.

[0027] According to an embodiment of the present invention, the cross-node synchronization method for skill version management based on nested two-layer Git repository agents is described in a specific implementation where the preset period is 10 to 60 seconds, with a default value of 30 seconds; the nodes determine the latest stable tags according to the timestamps in the tag names.

[0028] According to an embodiment of the present invention, the cross-node synchronization method for skill version management based on nested two-layer Git repository intelligent agents, in a specific implementation, includes at least one of the following: a cache of failed skills, a cache of skill description file content, a cache of prompt words, a cache of script paths, and a cache of executor dependencies, based on the inner skill sub-repository identifier, tag, skill name, and file hash value. The node retrieves the skill content corresponding to the latest tag from the remote end to the temporary work area via Git worktree, and performs the atomic switch via symbolic link atomic switch or directory atomic switch.

[0029] According to an embodiment of the present invention, the cross-node synchronization method for skill version management based on nested two-layer Git repository agents, in a specific implementation, when a node fails during the pulling, verification, detection, or hot reloading process, it maintains the skill content corresponding to the previous available tag to continue providing services and records the synchronization failure event; when a skill version needs to be rolled back, a rollback tag pointing to the previous stable commit is created in the default branch or version index of the inner skill sub-repository, and each node automatically converges to the rollback version by tracking the rollback tag.

[0030] According to an embodiment of the present invention, the cross-node synchronization method for skill version management based on nested two-layer Git repository intelligence, in a specific implementation, involves the node tracking the remote tag by periodic pull, or by a combination of any one or more of Webhook notifications, message queue notifications, and Redis publish-subscribe notifications with periodic pull.

[0031] To facilitate understanding of the above technical solutions of the present invention, the following detailed description of the above technical solutions of the present invention is provided through specific embodiments and working principles.

[0032] Example 1: Initialization of a nested two-level Git repository This embodiment uses an intelligent agent platform as an example to illustrate the construction process of a nested two-layer Git repository structure.

[0033] The platform's outer main repository contains application code directories such as xagent / , web / , deploy / , tests / , and config / , as well as skill mount directories, such as common_extends / for storing system-level shared skills, extends / for storing organization-level extended skills, and contexts / users / {user_id} / skills / for storing user-private skills.

[0034] Configure an ignore file (.gitignore) in the root directory of the outer main repository, which contains ignore rules to exclude inner skill sub-repositories under the aforementioned skill mount directories, such as "common_extends / ", "extends / ", "contexts / users / / skills / ", etc. Simultaneously, preserve the directory description files using methods like "!common_extends / README.md" and "!extends / README.md", making the directory structure visible in the repository while preventing the actual skill content from being committed.

[0035] Subsequently, an independent Git repository is initialized in the common_extends / sthg_agent_common_extends / directory as an inner sub-repository for system-level shared skills. This inner sub-repository has its own default branch, such as main or master, its own commit history, and its own tag system.

[0036] Operating principle: The outer main repository excludes inner skill sub-repositories by ignoring rules, ensuring that each build of the outer main repository does not include any content from the inner skill repositories. When skills change, there is no need to rebuild or redeploy the outer main repository, thus decoupling application versions from skill versions. The inner sub-repositories are independent of each other; system-level, organization-level, third-party, and user-private skills can be stored in different sub-repositories, each with independent permission management and approval processes, effectively avoiding cross-layer contamination and accidental overwriting risks.

[0037] Example 2: Inner Sub-Repository Structure and Version Identifier for Skills This embodiment illustrates the organizational structure of the inner skill sub-repository and the method for generating skill version identifiers.

[0038] Each inner sub-repository is an independent Git repository, hosting skill sets at different levels. Taking common_extends / sthg_agent_common_extends as an example, this repository is organized into directories by skill name. Each skill directory contains at least a skill description file (SKILL.md) and an executable script, and may also contain dependency declaration files such as requirements.txt and package.json, test cases, metadata manifests such as skill.yaml, and optional hook scripts.

[0039] When loading a skill, the skill loader generates a unique skill version identifier based on the repository path of the inner sub-repository, the skill name, the hierarchy, the default branch name, the current tag name, and the hash value of the skill file. This identifier is used at runtime to distinguish different versions of the same skill.

[0040] How it works: Each skill exists as an independent directory within an inner sub-repository, and the directory structure, along with the skill content, is version-managed. When skill files change, Git can precisely track the modification history of each file. The skill loader generates a version identifier by combining multiple dimensions such as repository identifier, skill name, and file hash, ensuring that even minor changes to skill content are reflected at the version identifier level, providing accurate evidence for subsequent version comparisons and cache invalidation.

[0041] Example 3: Skill Forking, Editing, and Difference Comparison This embodiment illustrates the complete process of skill modification, including creating an edit copy, performing verification, and generating a difference summary.

[0042] When a developer needs to modify a skill related to "cross-node skill synchronization," the system first creates an isolated edit copy from the current tag of the default branch in the source inner sub-repository. This edit copy can be a local branch, a Gitworktree, or a separate working directory copy.

[0043] Developers modify skill files in the edit copy, such as changing the skill descriptions or prompt templates in skills / skill-sync / SKILL.md, and modifying the synchronization script logic in scripts / sync.py.

[0044] After editing, the system automatically performs several verification operations: format verification to check whether SKILL.md conforms to the established format specifications, directory structure verification to check whether the skill directory contains the required files, cross-level import verification to prevent unexpected dependency references between skills, script executability verification to ensure that the script has the correct execution permissions, and minimal regression testing to verify that the modifications have not broken the basic functionality of the skills.

[0045] After successful verification, the system uses the current commit of the baseline tag or default branch as the benchmark, and the edited copy or feature branch as the comparison object to generate structured difference information. This difference information includes at least: a list of newly added, deleted, and modified skill files, details of changes to SKILL.md content, details of script changes, details of dependency changes, changes to permissions or external system calls, test results, and the scope of impact.

[0046] The difference comparison results serve as approval input, allowing skill owners or platform administrators to determine whether to allow the merging.

[0047] Operating principle: An isolated edit copy is created from the stable tag, ensuring that modifications do not affect the currently serving skill version. Multi-layered verification mechanisms during the editing process intercept non-compliant changes at the source, preventing erroneous skills from entering the stable branch. Difference comparison presents the modified content in a structured format, allowing approvers to clearly understand the specific content and potential impact of each change, providing an objective basis for approval decisions. The entire process ensures the controllability and auditability of skill changes.

[0048] Example 4: Feature Branch Submission, Approval Merging, and Tag Issuance This example illustrates the process of merging and releasing skill changes after approval.

[0049] Once approved, the system will submit the changes to the feature branch of the inner sub-repository, named for example "feature / skill-sync-hotload", and create a merge request or pull request.

[0050] After the approver completes the approval process through the merge request interface of the code hosting platform, the feature branch will be merged into the default branch of the inner sub-repository. After the merge is complete, the system automatically generates a timestamp tag on the current commit of the default branch. The tag annotation records the approval number, commit summary, change skill list, committer information, approver information, and test results.

[0051] After tags are generated, the system synchronously generates or updates version index files (such as VERSION_INDEX.json or INDEX.yaml) in the inner sub-repository. This file records the repository name, tag name, commit hash, skill list, hash value of each skill file, dependency summary, and release time. The version index is used to quickly determine whether hot reloading is needed during node synchronization and is also used for troubleshooting and audit tracing.

[0052] Operating principle explanation: Timestamp tags provide a unique and ordered version identifier for each skill release, naturally supporting time-based sorting and comparison of versions. Tag annotations record information such as approval number, change list, and approver, ensuring the complete context of each release is preserved and meeting audit trail requirements. The version index file centrally records the complete skill list and file hashes corresponding to the tags, allowing nodes to quickly determine if a version has changed without having to check each skill file individually, thus improving synchronization efficiency.

[0053] Example 5: Periodic Synchronization and Hot Reloading of Stateless Cluster Nodes This example illustrates how a stateless service node can detect skill version changes and perform hot reloading.

[0054] Assume that there are nodes A, B, and C in the cluster. All three are stateless service instances and have mounted or cloned the inner sub-repository of common_extends / sthg_agent_common_extends.

[0055] Each node initiates a lightweight synchronization task to fetch remote references and tags from the inner skill sub-repository at a preset period T. The period T can be configured from 10 seconds to 60 seconds; in this embodiment, it is set to 30 seconds by default.

[0056] The specific execution flow of the synchronization task is as follows: traverse the registered inner skill repositories; execute "git fetch --tags" to obtain the latest tags from the remote repository; parse the latest stable tags according to the timestamp in the tag name; and compare the parsed latest tags with the tags already loaded locally on the node.

[0057] If the two match, no loading operation is triggered, and this round of synchronization ends. If the tag, submission hash, or skill file hash changes, the hot loading process begins.

[0058] The hot reloading process includes: the node checks out the skill content corresponding to the target tag to a temporary workspace or an independent worktree; the checked content is validated, including directory structure validation, version index validation, and skill specification validation; after the validation is passed, the currently visible directory of the skill is atomically switched to point to the new tag content, which can be achieved through symbolic link atomic switching or directory atomic switching; then, the expired skill list, SKILL.md content, prompt word assembly cache, script path cache, and executor dependency cache are cached according to the dimensions of repository, tag, skill name, and file hash; the "skill_version_changed" event is published, which includes the repository identifier, old tag name, new tag name, changed skill list, and commit hash value.

[0059] When a new user request is made or the next Agent loop construction context is encountered, the skill loader reads the skill definitions under the new tag and updates the set of skills available at runtime. Throughout this process, the HTTP service, the Agent loop main process, and the container instance are not restarted.

[0060] Operating principle explanation: Stateless nodes proactively fetch remote tags at fixed intervals, avoiding the risk of message loss that may arise from relying on external notifications. Atomic switching ensures that the skill catalog remains consistent at the moment of switching, preventing intermediate states where some files are new versions and others are old versions. Cache invalidation is executed precisely across multiple dimensions, clearing only the cache of affected skills without impacting the operation of other skills. Skill version changes are notified to all runtime components via an event mechanism, enabling the entire system to respond collaboratively to version changes. Since the application process does not require a restart, online sessions can continue to run, and service is uninterrupted.

[0061] Example 6: Synchronization Failure Protection and Version Rollback This embodiment illustrates the protection mechanism in case of node synchronization failure and the implementation method of skill version rollback.

[0062] If a node fails to retrieve a tag due to network issues, or if it encounters verification failures such as an incomplete directory structure or an incorrect version index format during content verification, the node will not perform a directory switch. Instead, it will continue to provide services using the skill content corresponding to the previous stable tag and will write the error information to the synchronization event log to record the synchronization failure event.

[0063] When a released skill version is found to have a logical flaw and needs to be rolled back, the administrator does not modify the history tag. Instead, they create a new rollback tag pointing to the previous stable commit in the default branch or version index of the inner sub-repository. The comment on this rollback tag records the reason for the rollback and the original issue tag information.

[0064] In the next synchronization cycle, each node recognizes the rollback tag as the latest stable tag because its timestamp is later than the issue tag. It then performs the same verification, atomic switching, cache invalidation, and hot reloading process as a normal release, thereby automatically converging to the previous stable skill version.

[0065] Operating principle: The failure protection mechanism ensures that a synchronization failure on a single node does not affect the normal service of that node. Nodes always run on the last known available skill version, avoiding service unavailability due to synchronization failure. Rollback uses a "forward release of rollback tags" approach instead of "deleting historical tags," preserving a complete version evolution history—both the issue version and the rollback version have corresponding tag records, facilitating post-event auditing and issue tracing. All nodes automatically converge to the rollback version according to the same tag tracking rules, eliminating the need for manual operation on each node individually.

[0066] Example 7: Skill Caching Key Mechanism This embodiment illustrates the generation and deactivation principle of skill cache keys.

[0067] The skill loader generates a cache key for each loaded skill. The expression for the cache key is: CacheKey=hash(repo_id,layer,skill_name,tag,commit_hash,file_hash) Among them, repo_id represents the unique identifier of the inner sub-repository, layer represents the level to which the skill belongs, such as: system level, organization level, third party or user private, skill_name represents the skill name, tag represents the name of the currently loaded tag, commit_hash represents the commit hash value corresponding to the tag, and file_hash represents the aggregate hash value of all files in the skill directory.

[0068] When any of the above fields changes, the cache key naturally changes, and the corresponding cache entry automatically becomes invalid. When all fields remain unchanged, the node directly reuses the local cache, avoiding unnecessary duplicate loading.

[0069] Operating principle: This cache key mechanism precisely limits skill version changes to the corresponding repository and skill scope. Changes to system-level skills do not affect the caching of organization-level skills, and changes to one skill do not affect the caching of other skills, reducing the impact across skills, tenants, and nodes. Furthermore, because the cache key includes a file hash dimension, even if a corrective commit (such as fixing a spelling error) is made to a skill file under the same tag, the cache key will change, ensuring that nodes can detect any substantial changes to skill content.

[0070] In summary, by utilizing the technical solutions described above, the outer main repository excludes independent Git skill sub-repositories within the inner layer using ignore rules, decoupling skill version evolution from application version and preventing minor skill changes from triggering overall build deployment. Multi-level isolated version management is achieved by assigning skills at each level to different inner sub-repositories, each with its own independent branch and approval process. A complete chain of feature branches, approval records, default branch merging commits, and timestamp tags ensures that each skill release is auditable, traceable, and rollbackable. Stateless cluster nodes periodically track the latest tags of the inner sub-repositories and compare them with the local version, triggering cache invalidation and hot reloading upon detecting changes, allowing nodes to converge to a consistent skill version in a short time without restarting the application process.

[0071] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cross-node synchronization method for skill version management based on nested two-layer Git repository intelligent agents, characterized in that: include: A nested two-layer Git repository structure is constructed, which includes an outer main repository and multiple inner skill sub-repositories. The outer main repository stores the agent application code, skill loader, and cache manager. The outer main repository excludes each of the inner skill sub-repositories through an ignore rule, so that the application version release of the outer main repository is decoupled from the skill version release of the inner skill sub-repositories. Each inner-layer skill sub-repository is an independent Git repository, storing skill files of the corresponding level. The skill files include at least a skill description file and an executable script. In response to a modification request for a target skill, an isolated edit copy is created from its inner-layer skill sub-repository, and the skill modification is completed in the edit copy; The modified skill is submitted to the feature branch of the inner skill sub-repository, and after approval, it is merged into the default branch. A timestamp tag or semantic version tag is generated on the current commit of the default branch. Each stateless service node retrieves remote tags from the inner skill sub-repository at a preset period and compares the latest remote tags with the locally loaded tags. If the latest remote tag is inconsistent with the locally loaded tag, the node will check out the skill content corresponding to the latest remote tag to the temporary work area. After the verification is passed, the node will atomically switch the current skill visibility directory to the temporary work area and invalidate the corresponding skill cache to achieve hot loading of skills. The node continues to run after the hot reload is completed without restarting the application process.

2. The cross-node synchronization method for skill version management based on nested two-layer Git repository intelligent agents according to claim 1, characterized in that, The outer main repository excludes each of the inner skill sub-repositories through ignore rules, including: setting a skill mounting directory in the root directory of the outer main repository, configuring ignore rules in the ignore file to exclude each inner skill sub-repository under the skill mounting directory, and retaining the directory description file of the skill mounting directory; or, the inner skill sub-repository is registered in the outer main repository as a Git submodule, and the outer main repository records the submodule references but does not commit the skill content.

3. The cross-node synchronization method for skill version management based on nested two-layer Git repository intelligent agents according to claim 1, characterized in that, The skill file also includes at least one of dependency declaration files, test cases, metadata manifests, and hook scripts; each of the inner skill sub-repositories corresponds to one of the following levels: system-level shared skills, organization-level extended skills, third-party extended skills, and user-private skills. The skill loader generates a unique skill version identifier based on the repository path, skill name, level, default branch, current tag, and skill file hash value of the inner skill sub-repository.

4. The cross-node synchronization method for skill version management based on nested two-layer Git repository intelligent agents according to claim 1, characterized in that, After the skill modification is completed in the edit copy, and before it is submitted to the feature branch, the process also includes at least one of the following verification operations: performing format verification, directory structure verification, prohibiting cross-level import verification, script executability verification, and regression testing.

5. The cross-node synchronization method for skill version management based on nested two-layer Git repository intelligent agents according to claim 1, characterized in that, Before submitting the modified skill to the feature branch, the process further includes: using the baseline tag or default branch submission of the inner skill sub-repository as a baseline and the edit copy or the feature branch as a comparison object to generate structured difference information. The difference information includes at least one or more of the following: adding skill files, deleting skill files, modifying skill files, changing the content of skill description files, script changes, dependency changes, permission changes, and test results. The difference information is then used as the basis for approval.

6. The cross-node synchronization method for skill version management based on nested two-layer Git repository intelligent agents according to claim 1, characterized in that, The timestamp tag or semantic version tag annotation records at least one of the following: approval number, changed skill list, submitter information, approver information, and test results; after the tag is generated, a version index file is generated in the inner skill sub-repository. The version index file records at least one of the following: repository name, tag name, submission hash value, skill list, hash value of each skill file, and dependency summary. The version index is used for version comparison and hot reloading judgment during node synchronization.

7. The cross-node synchronization method for skill version management based on nested two-layer Git repository intelligent agents according to claim 1, characterized in that, The preset period is 10 to 60 seconds, with a default value of 30 seconds; the nodes are sorted according to the timestamps in the names of the tags to determine the latest stable tags.

8. The cross-node synchronization method for skill version management based on nested two-layer Git repository intelligent agents according to claim 1, characterized in that, The skill cache corresponding to the failure includes at least one of the following: a cache of failed skills list, a cache of skill description file content, a cache of prompt words, a cache of script paths, and a cache of executor dependencies, based on the inner skill sub-repository identifier, tag, skill name, and file hash value. The node checks out the skill content corresponding to the latest tag from the remote end to the temporary work area through the Git worktree method, and performs the atomic switch through symbolic link atomic switch or directory atomic switch.

9. The cross-node synchronization method for skill version management based on nested two-layer Git repository intelligent agents according to claim 1, characterized in that, When a node fails during the retrieval, verification, detection, or hot-loading process, it maintains the skill content corresponding to the previously available tag to continue providing services and records the synchronization failure event. When a skill version needs to be rolled back, a rollback tag pointing to the previous stable commit is created in the default branch or version index of the inner skill sub-repository. Each node automatically converges to the rollback version by tracking the rollback tag.

10. The cross-node synchronization method for skill version management based on nested two-layer Git repository intelligent agents according to claim 1, characterized in that, The node tracks the remote tag by periodically pulling data, or by combining periodic pulling with any one or more of the following methods: Webhook notifications, message queue notifications, and Redis publish / subscribe notifications.

Images