Skill asset processing method, system, device, and storage medium

Abstract

The embodiment of the disclosure provides a skill asset processing method, system, device and storage medium, relating to the technical field of artificial intelligence. The skill asset processing method comprises: acquiring a skill source warehouse used for generating a target skill asset package and at least one root skill identifier, the skill source warehouse comprising a skill configuration file and a skill description file; based on the skill configuration file and the skill description file, recursively generating a target dependency relationship topology with the root skill identifier as a starting point; according to the target dependency relationship topology, acquiring a target running skill set from the skill source warehouse, and generating the target skill asset package based on the target running skill set. The target dependency relationship topology comprises a plurality of target skill identifiers and target dependencies corresponding to each target skill identifier, and the target skill identifier comprises the root skill identifier and a skill identifier recursively dependent on the root skill identifier. In this way, the efficiency and reliability of skill asset packaging and distribution processing are improved.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, and more specifically, to a method, system, device, and storage medium for processing skill assets. Background Technology

[0002] Intelligent agent technology based on chips such as Graphics Processing Units (GPUs) and General-Purpose Computing on Graphics Processing Units (GPGPUs) has been widely applied and deployed in engineering practice. Intelligent agents (such as engineering agents) can be deployed and run based on skill assets, such as skill assets for kernel development, compiler usage, performance profiling, communication library configuration, model framework adaptation, hardware diagnostics, and acceptance gating. During the engineering practice of developing or building skill assets, the completed skill assets can be stored in a skill source repository. Subsequently, according to the needs of the intelligent agent, some or all of the skill assets in the skill source repository can be packaged and distributed to the intelligent agent.

[0003] In related technologies, skill asset distribution can be achieved through two methods: full package distribution and trimmed package distribution. However, full package distribution results in a large package size and low distribution efficiency; trimmed package distribution may miss skills, leading to low reliability. Therefore, how to achieve efficient and reliable skill asset package distribution has become an urgent technical problem to be solved. Summary of the Invention

[0004] One objective of this disclosure is to provide a new technical solution for the processing of skills assets.

[0005] According to a first aspect of the present disclosure, a method for processing skill assets is provided, the method comprising: Obtain a skill source repository for generating the target skill asset package and at least one root skill identifier, wherein the skill source repository includes skill configuration files and skill description files; Based on the skill configuration file and the skill description file, a target dependency topology is recursively generated starting from the root skill identifier. The target dependency topology includes multiple target skill identifiers and their corresponding target dependencies. Each target skill identifier includes the root skill identifier and the skill identifiers recursively dependent on it. If the skill attribute corresponding to the target skill identifier is a routing attribute with routing capabilities, then the target dependency corresponding to the target skill identifier includes structured explicit dependencies extracted from structured metadata in the skill configuration file and the skill description file, and implicit dependencies extracted from natural language description text in the skill description file. If the skill attribute corresponding to the target skill identifier is a non-routing attribute, then the target dependency corresponding to the target skill identifier includes non-empty structured explicit dependencies or implicit dependencies when the structured explicit dependencies are empty. Based on the target dependency topology, the target running skill set is obtained from the skill source repository, and the target skill asset package is generated based on the target running skill set.

[0006] Optionally, the step of recursively generating the target dependency topology based on the skill configuration file and the skill description file, starting from the root skill identifier, includes: The root skill identifier is used as a candidate skill identifier to be recursively traversed; Perform dependency resolution and merging / pruning steps on the candidate skill identifiers to generate the target dependencies corresponding to the candidate skill identifiers; If the target dependency is not empty, the skill identifier in the target dependency is used as a new candidate skill identifier, and the dependency resolution and merging and pruning steps are recursively executed until all candidate skill identifiers have completed the dependency resolution and merging and pruning steps. The dependency resolution and merging / pruning steps include: Based on the skill configuration file and the skill description file, the skill attributes, structured explicit dependencies, and implicit dependencies corresponding to the candidate skill identifier are generated; After processing the structured explicit and implicit dependencies based on the skill attributes, the target dependency corresponding to the candidate skill identifier is obtained.

[0007] Optionally, generating the skill attributes, structured explicit dependencies, and implicit dependencies corresponding to the candidate skill identifier based on the skill configuration file and the skill description file includes: The skill attributes corresponding to the candidate skill identifier are determined based on the skill configuration file. Based on the dependency declarations in the skill configuration file and the dependency declarations in the skill description file based on structured metadata, extract the structured explicit dependencies corresponding to the candidate skill identifier; Based on the natural language description text in the skill description file, extract the implicit dependencies corresponding to the candidate skill identifiers.

[0008] Optionally, extracting the implicit dependencies corresponding to the candidate skill identifiers based on the natural language description text in the skill description file includes: Semantic parsing is performed on the natural language description text in the skill description file to identify the reference dependency information corresponding to the candidate skill identifier; Based on the reference dependency information, the implicit dependencies corresponding to the candidate skill identifiers are obtained by matching the skills in the skill source repository.

[0009] Optionally, determining the skill attribute corresponding to the candidate skill identifier based on the skill configuration file includes: Read the attribute field corresponding to the candidate skill identifier in the skill configuration file; If the attribute field contains a route type flag, then the skill attribute of the candidate skill identifier is determined to be a route attribute; or, if the attribute field does not contain a route type flag, then the skill attribute of the candidate skill identifier is determined to be a non-route attribute.

[0010] Optionally, the step of processing the structured explicit and implicit dependencies according to the skill attributes to obtain the target dependency corresponding to the candidate skill identifier includes: If the skill attribute corresponding to the candidate skill identifier is a routing attribute, the structured explicit dependency and the implicit dependency are merged to obtain the candidate dependency corresponding to the candidate skill identifier; or, If the skill attribute corresponding to the candidate skill identifier is a non-routable attribute, and the structured explicit dependency is not empty, then the structured explicit dependency is used as the candidate dependency corresponding to the candidate skill identifier; if the structured explicit dependency is empty and the implicit dependency is not empty, then the implicit dependency is used as the candidate dependency corresponding to the candidate skill identifier. The target dependency is obtained by pruning the non-runtime dependencies from the candidate dependencies.

[0011] Optionally, the target operational skill set includes skill data corresponding to each target skill identifier in the target dependency topology, wherein the skill data includes text data and non-text data; generating the target skill asset package based on the target operational skill set includes: Based on the skill data, skill integrity verification information is generated for each of the target skill identifiers; The text data is encrypted to obtain encrypted text data; A target skill file is generated based on the encrypted text data and the non-text data; Based on the target skill identifier and the skill integrity verification information, auxiliary information corresponding to the target skill file is generated; wherein, the auxiliary information includes the root skill identifier, skill integrity verification information corresponding to each of the target skill identifiers, and file integrity verification information generated based on the target skill file; The target skill asset package is generated based on the target skill file and the auxiliary information; wherein, the auxiliary information is used to perform integrity verification on the target skill file when the skill asset receiving end receives the target skill asset package.

[0012] According to a second aspect of the present disclosure, a skill asset processing system is provided, the skill asset processing system comprising a skill asset distribution terminal and a skill asset receiving terminal; wherein: The skill asset distribution terminal is configured to execute the method described in the first aspect to generate a target skill asset package and send the target skill asset package to the skill asset receiving terminal. The skill asset receiving end is configured to receive the target skill asset package and deploy skill assets based on the target skill asset package.

[0013] According to a third aspect of the present disclosure, an electronic device is provided, including a memory and a processor, the memory being configured to store computer instructions, and the processor being configured to invoke the computer instructions from the memory to perform the method described in the first aspect.

[0014] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon, the computer program implementing the method described in the first aspect when executed by a processor.

[0015] Based on the skill asset processing method provided in this disclosure, structured explicit dependencies and implicit dependencies are extracted from skill configuration files and skill description files. A dual-source dependency resolution mechanism can be constructed, which can avoid the problem of skill omission caused by relying solely on configuration file declarations, and also avoid the problem of excessive package size and internal capability exposure caused by full distribution, thereby improving the efficiency and reliability of skill asset packaging and distribution processing.

[0016] Other features and advantages of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure.

[0018] Figure 1 This is a schematic diagram of the structure of a skill asset processing system provided in an embodiment of this disclosure.

[0019] Figure 2 This is a flowchart illustrating a skill asset processing method provided in an embodiment of this disclosure.

[0020] Figure 3 This is a schematic diagram of a process for generating a target dependency topology provided in an embodiment of this disclosure.

[0021] Figure 4 This is a schematic diagram of another process for generating target dependency topology provided in an embodiment of this disclosure.

[0022] Figure 5 This is a schematic diagram of a process for generating a target skill asset package provided in an embodiment of this disclosure.

[0023] Figure 6 This is a schematic diagram of another skill asset processing system provided in this embodiment.

[0024] Figure 7 This is an interactive schematic diagram of a skill asset processing method provided in an embodiment of this disclosure.

[0025] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0026] Various exemplary embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0027] The following description of at least one exemplary embodiment is merely illustrative and is not intended to limit this disclosure or its application or use. Techniques, methods, and apparatus known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and apparatus may be considered part of the specification.

[0028] It should be noted that similar labels and letters in the following figures indicate similar items, so once an item is defined in one figure, it need not be discussed further in subsequent figures.

[0029] This disclosure relates to a technical solution for processing skill assets. Figure 1 This is a schematic diagram of the structure of a skill asset processing system provided in an embodiment of this disclosure. Figure 1 As shown, the skill asset processing system may include at least one of a skill asset distribution terminal 100, a skill asset receiving terminal 200, and an operation terminal 300.

[0030] The skill asset distribution terminal 100 can be used to process skill assets, such as executing the skill asset processing method provided in this disclosure embodiment. This skill asset processing method can be triggered by an AI agent and / or a human engineer. The skill asset processing method can be executed based on a target chip, which can be one or more chips of any type, such as a Graphics Processing Unit (GPU), General-Purpose Graphics Processing Unit (GPGPU), Neural-network Processing Unit (NPU), Tensor Processing Unit (TPU), or Central Processing Unit (CPU). In some examples, the skill asset distribution terminal may include a processor, on which the skill asset processing method is executed. The processor may include at least one of a CPU, GPU, GPGPU, NPU, and TPU. Exemplarily, the skill asset distribution terminal may further include a memory, which may include at least one of Static Random Access Memory (SRAM), Read-Only Memory (ROM), or Erasable Programmable Read-Only Memory (EPROM). The memory can be used to store a computer program, which, when executed by a processor, controls the processor to perform the skill asset processing method of this disclosure embodiment. It should be noted that the skill asset distribution terminal may be a server, such as a single server or a server cluster consisting of multiple servers.

[0031] The skill asset receiver 200 can be connected to the skill asset distributor 100, for example, through an interface device or a communication device. The skill asset receiver can receive skill asset packages sent by the skill asset distributor and deploy the corresponding skill assets.

[0032] The operating terminal 300 can be connected to both the skill asset distribution terminal 100 and the skill asset receiving terminal 200, for example, through an interface device or a communication device. Users can control the operation of the skill asset receiving terminal and / or the skill asset distribution terminal through the operating terminal, for example, controlling the skill asset receiving terminal and / or the skill asset distribution terminal to execute the skill asset processing method provided in this embodiment of the disclosure.

[0033] exist Figure 1 In the skill asset processing system shown, the skill asset distribution terminal, skill asset receiving terminal, and operation terminal can each be one or more; the skill asset distribution terminal, skill asset receiving terminal, and operation terminal can be different physical devices, or they can be partially or completely integrated into the same physical device, and this disclosure does not limit this.

[0034] In some examples, the skill asset distribution end can provide a skill source repository, which can store already developed skill assets. For instance, the skill assets stored in the skill source repository may include skill assets for scenarios such as kernel development, compiler usage, performance profiling, communication library configuration, model framework adaptation, hardware diagnostics, and acceptance gating. During the deployment or operation of the agent at the skill asset receiving end, the skill assets required by the agent can be packaged and distributed to the skill asset receiving end; for example, full packaging and distribution or tailored packaging and distribution can be performed.

[0035] The full-package distribution method can directly package all skills, reference materials, and scripts stored in the skill source repository into the installation package, forming a skill asset package, which is then sent to the skill asset receiving end. This method results in a large package size, low distribution efficiency, and because the skill source repository contains compilers, kernels, communication libraries, and hardware diagnostic experience, direct full distribution can easily expose unauthorized capabilities.

[0036] The tailored packaging and distribution method can parse the depends_on field in the package metadata manifest to obtain explicit dependencies. However, the depends_on field in the manifest cannot cover all skill dependencies. Therefore, it may miss the actual skill toolchain capabilities referenced by old skills or routing skills, which may lead to skill failures due to missing dependencies, resulting in low reliability of packaging and distribution.

[0037] Furthermore, the skill asset distribution methods in related technologies also have the following problems: ordinary plugin dependencies are not suitable for agent-related skills. Agent-related skills not only include code, but also prompts, reference documents, scripts, templates and decision-making processes. The operational dependencies of skills may be hidden in the documents; packaged skill assets lack minimum operational proof: the installer (skill asset receiver) cannot prove that the current skill set exactly covers the capabilities required for the root skill to run, nor can it detect orphan skills or missing skills; the packaged skill asset package is difficult to deploy offline. In laboratories or enterprise intranets, there may be inaccessibility to external registry, so a mirrorable and verifiable offline package is required.

[0038] To address the problems in related technologies, this disclosure provides a method for processing skill assets, which partially or completely solves the aforementioned technical problems. For example, based on skill configuration files (e.g., skill.toml) and skill description files (e.g., SKILL.md documents) in a skill source repository, a target dependency topology can be recursively generated starting from the root skill identifier. The target skill asset package generated based on this target dependency topology can be the minimum operable skill closure required by the agent, thereby improving the efficiency and reliability of packaging and distribution.

[0039] Figure 2 This is a flowchart illustrating a skill asset processing method provided in an embodiment of this disclosure. This skill asset processing method can be... Figure 1 The skill asset distribution terminal shown can execute this, or it can be executed by any electronic device. For example... Figure 2 As shown, the skill asset processing method of this embodiment may include the following steps S210 to S230.

[0040] Step S210: Obtain the skill source repository for generating the target skill asset package and at least one root skill identifier. The skill source repository may include skill configuration files and skill description files.

[0041] In some examples, the skill source repository may store the full set of skill assets or skill assets within the scope to be pruned. For instance, the skill source repository may be represented as a skill directory (skills_dir), which can be the root directory of the skill source repository or its scope to be pruned, and may contain actual skill directories, skill.toml, SKILL.md, helper scripts, examples, or resource files, etc. The skill source repository may represent the complete set or a candidate complete set of skill assets that the method of this embodiment can scan and parse.

[0042] Dependencies can exist between skill assets in this skill source repository. For example, if skill asset A needs to call skill asset B or use the output of skill asset B during its operation, then skill asset A and skill asset B can be considered to have a dependency relationship. For instance, skill asset B is included in the target dependency of skill asset A. These dependencies can be both structured explicit dependencies in the package metadata manifest and implicit skill references in historical skill documents.

[0043] Skill configuration files in a skill repository can include structured files, such as skill.toml, used to declare skill metadata and explicit dependencies. These configuration files can also be called structured skill files or machine-readable skill files. Based on these configuration files, structured explicit dependencies between skill assets can be determined.

[0044] Skill description files in the skill source repository can include related files that describe the function and reference relationships of skills in the form of natural language or structured metadata. Examples include SKILL.md, auxiliary scripts, examples, or resource files. Based on the structured metadata in the skill description file, structured explicit dependencies between skill assets can be determined, while implicit dependencies between skill assets can be determined based on the natural language description text in the skill description file.

[0045] The root skill identifier can be the entry skill node identifier for a skill asset processing task, serving as the starting point for dependency resolution. For example, the root skill identifier can be a skill that must be retained, as specified by the user, system policy template, or upper-layer distributed task; for instance, a user can designate any skill in the skill source repository as a root skill. Based on this root skill identifier, the name, relative path, or unique identifier from the skill list of the entry skill can be obtained. There can be one or more root skill identifiers; for example, root skill identifiers can include identifiers for skills such as the AI ​​model master skill (ai-model-master) and the acceptance gate skill (acceptance-gate).

[0046] In some examples, this step may also obtain other information for skill asset processing, such as target runtime environment information (target_profile), which may include chip architecture (such as GPU architecture), driver version, compiler version, security policy, etc. The security policy may include pruning and trusted distribution policies, such as whether to retain optional dependencies, whether to allow implicit dependencies, trusted signature requirements, etc.

[0047] Step S220: Based on the skill configuration file and skill description file, recursively generate the target dependency topology starting from the root skill identifier.

[0048] In some examples, the target dependency topology may include multiple target skill identifiers and their corresponding target dependencies. The target skill identifiers may include a root skill identifier and the skill identifiers that the root skill identifier recursively depends on. For example, this target dependency topology can be represented based on a directed dependency graph structure. In this step, the dependencies of each skill node can be resolved layer by layer by recursively traversing from the root skill identifier, ultimately obtaining the complete set of skill nodes and their dependencies required for the root skill to run.

[0049] In some examples, if the skill attribute corresponding to the target skill identifier is a routing attribute with routing and scheduling capabilities (e.g., it is marked as a router or has routing rules), then the target dependency corresponding to the target skill identifier includes structured explicit dependencies extracted based on structured metadata in the skill configuration file and skill description file, as well as implicit dependencies extracted based on natural language description text in the skill description file.

[0050] In other examples, if the skill attribute corresponding to the target skill identifier is a non-routable attribute, then the target dependency corresponding to the target skill identifier includes a non-empty structured explicit dependency or an implicit dependency when the structured explicit dependency is empty. For example, if the skill attribute corresponding to the target skill identifier is a non-routable attribute and the structured explicit dependency corresponding to the target skill identifier is not empty, then the target dependency corresponding to the target skill identifier is a structured explicit dependency; if the skill attribute corresponding to the target skill identifier is a non-routable attribute, the structured explicit dependency corresponding to the target skill identifier is empty, and the implicit dependency corresponding to the target skill identifier is not empty, then the target dependency corresponding to the target skill identifier is an implicit dependency; if the skill attribute corresponding to the target skill identifier is a non-routable attribute and both the structured explicit dependency and the implicit dependency corresponding to the target skill identifier are empty, then the target dependency corresponding to the target skill identifier is empty.

[0051] It's important to note that skill attributes can also be called skill types. Skill assets in a skill source repository can have different attributes, such as master control skills with master control attributes, routing skills with routing attributes, and ordinary skills with ordinary attributes. Master control skills can be master control / orchestration skills in business semantics, responsible for organizing a specific type of task chain, such as AI model master control or AI operation and maintenance master control. Routing skills can be distribution / routing nodes in technical implementation, responsible for directing requests to one or more downstream skills based on hardware type, task type, operating environment, or capability tags. Ordinary skills can be leaf or intermediate functional skills that do not assume master control or routing responsibilities, such as compiler usage, communication library configuration, hardware diagnostics, and kernel performance profiling. In this example, the master control attribute can be a special case of a routing attribute, while non-routing attributes can be ordinary attributes.

[0052] Optionally, the aforementioned routing attributes can be GPGPU routing attributes. For example, a skill asset with routing attributes can be a GPGPU routing root skill, that is, a skill with routing attributes in the root skill identifier.

[0053] In some examples, the skill attributes corresponding to a target skill identifier can be defined and detected through metadata fields. For example, the frontmatter of skill.toml or SKILL.md can contain role / type fields: role=master, role=router, role=normal, and domain=gpgpu. If a skill's skill.id ∈ roots (the set of root skill identifiers) and skill.domain == gpgpu and skill.role == router, then the skill can be determined to be a GPGPU routing root skill. Optionally, if there is no role field, fields such as routing_rules, routes, dispatch_to, and selector can be used as auxiliary criteria.

[0054] Step S230: Based on the target dependency topology, obtain the target running skill set from the skill source repository, and generate the target skill asset package based on the target running skill set.

[0055] The target runtime skill set may include skill data corresponding to all target skill identifiers in the target dependency topology, such as the minimum runnable skill closure for running the root skill identifier. The target skill asset package may include the target runtime skill set itself, such as a distributable file obtained by generating integrity verification information, encrypting, and packaging the target runtime skill set.

[0056] In some examples, the skill asset distributor can send the generated target skill asset package to the skill asset receiver, which can then deploy skill assets based on the target skill asset package.

[0057] Using the above method, based on skill configuration files and skill description files, structured explicit dependencies and implicit dependencies are extracted, enabling the construction of a dual-source dependency resolution mechanism. This avoids the problem of skill omissions caused by relying solely on configuration file declarations, and also avoids the problems of excessive package size and exposure of internal capabilities caused by full distribution, thereby improving the efficiency and reliability of skill asset packaging and distribution processing.

[0058] Figure 3 This is a schematic diagram illustrating a process for generating a target dependency topology according to an embodiment of this disclosure. For example... Figure 3 As shown, the method of generating the target dependency topology in the aforementioned step S220 may include the following steps S221 to S223.

[0059] Step S221: Use the root skill identifier as a candidate skill identifier to be recursively traversed.

[0060] For example, the candidate skill identifier can be the skill node identifier of the current dependency resolution to be performed, and is the processing object of the dependency resolution and merging / pruning steps.

[0061] In some examples, this step can use a single root skill identifier as the initial candidate skill identifier, initiating a recursive traversal starting from a single node. This simplifies the processing logic, making it suitable for scenarios with a single master skill as the entry point, and reducing the processing complexity of the initialization phase.

[0062] In other examples, this step can also batch-use a set of multiple root skill identifiers as initial candidate skill identifiers, supporting parallel initialization at multiple entry points. This allows for the parallel overriding of dependency closures of multiple independent root skills within the packaging task, improving processing efficiency in batch distribution scenarios.

[0063] Step S222: Perform dependency resolution and merging / pruning steps on the candidate skill identifiers to generate the target dependencies corresponding to the candidate skill identifiers.

[0064] For example, the dependency resolution and merging trimming step may include: generating skill attributes, structured explicit dependencies, and implicit dependencies corresponding to candidate skill identifiers based on skill configuration files and skill description files; and processing the structured explicit dependencies and implicit dependencies according to the skill attributes to obtain the target dependencies corresponding to the candidate skill identifiers.

[0065] In some examples, the skill attributes corresponding to candidate skill identifiers can be determined based on the skill configuration file. These skill attributes can include routing attributes or non-routing attributes. Routing attributes can represent skills with routing capabilities, which, at runtime, can route tasks to different lower-level skills based on input conditions. Their runtime dependencies come not only from explicit declarations in the configuration file but also from the routed skills referenced in natural language within their description files. Non-routing attributes can represent skills without routing capabilities, whose runtime dependencies are typically fully covered by explicit declarations in the configuration file.

[0066] For example, determining skill attributes can include: reading the attribute fields corresponding to the candidate skill identifier in the skill configuration file (e.g., skill.toml); if the attribute field contains a routing type flag (e.g., the type field has a value of router or the skill_type field contains a routing flag), then the skill attribute of the candidate skill identifier is determined to be a routing attribute; or, if the attribute field does not contain a routing type flag, then the skill attribute of the candidate skill identifier is determined to be a non-routing attribute. In this way, skill attribute determination can be quickly completed using machine-readable configuration file fields, without requiring additional parsing of the skill description file content, resulting in high processing efficiency.

[0067] Furthermore, the determination of skill attributes can also be based on a combination of attribute fields in the skill configuration file and metadata annotations in the skill description file. If neither contains a route type marker, it is determined to be a non-route attribute; if either source contains a route type marker, it is determined to be a route attribute. This approach can accommodate historical skill scenarios where route type markers are scattered across different files, thus improving the coverage of skill attribute determination.

[0068] In this way, skill attributes can be accurately determined, providing accurate input for the selection of subsequent dependency merging strategies. This allows the system to adopt corresponding dependency processing logic for routing skills and non-routing skills respectively, thereby ensuring the integrity of routing skill dependencies while avoiding the introduction of unnecessary implicit dependencies by non-routing skills that expand the scope of closures.

[0069] In some examples, the structured explicit dependencies corresponding to candidate skill identifiers can be extracted based on the dependency declarations in the skill configuration file and the dependency declarations in the skill description file based on structured metadata.

[0070] For example, dependency declarations in a skill configuration file (such as skill.toml) can be read as the primary source of structured explicit dependencies. Dependency declarations in a skill configuration file can explicitly declare the current skill's runtime dependencies on other skills using a machine-readable field format (such as a list of depends_on fields), offering high reliability and resolvability. For instance, the skill configuration file can include machine-readable structured files, such as the depends_on, require, and optional_depends fields in a manifest like skill.toml.

[0071] For example, dependency declarations based on structured metadata in the skill description file (SKILL.md) can be read as a second source of structured explicit dependencies. The frontmatter area of ​​the skill description file can contain dependency information declared in a structured format (such as YAML header fields), which, together with the dependency declarations in the skill configuration file, constitute the complete source of structured explicit dependencies. For example, the first and second sources can be merged and deduplicated to obtain structured explicit dependencies.

[0072] For example, the dependency declarations in the skill description file, which are based on structured metadata, may include structured fields such as depends, require, role, domain, and routes, which are recorded in YAML / TOML format in the frontmatter at the top of SKILL.md.

[0073] In this way, the dependency declarations in the skill configuration file and the dependency declarations based on structured metadata in the skill description file can cover the source of the complete machine-readable explicit dependencies, thereby improving the integrity and reliability of structured explicit dependencies.

[0074] In some examples, implicit dependencies corresponding to candidate skill identifiers can be extracted based on the natural language description text in the skill description file.

[0075] For example, the natural language description text in a skill description file can be read as a source of implicit dependencies. This natural language description text may contain path references, name references, or functional descriptions of other skills. The reference information contained in this natural language description text is not explicitly declared in the skill configuration file, but it still constitutes an actual dependency relationship at runtime, which can be called an implicit dependency. The natural language description text in the skill description file can include implicit dependencies in the natural language text of the SKILL.md file, historical skill descriptions, example commands, precondition paragraphs, reference links, etc.

[0076] For example, semantic parsing can be performed on the natural language description text in the skill description file to identify the reference dependency information corresponding to the candidate skill identifier; the reference dependency information can be matched with the skills in the skill source repository to obtain the implicit dependency corresponding to the candidate skill identifier.

[0077] Semantic parsing of natural language descriptive text can be achieved based on a large language model (LLM) or predefined rules, which will be explained below.

[0078] In some examples, implicit dependency extraction can be based on semantic understanding of natural language description text using a large language model. This allows for the identification of functional, path, or name references to other skills within the text, extracting the corresponding reference dependency information. For instance, the large language model can identify skill path strings (such as . / compiler-skill / SKILL.md) or skill names (such as kernel development skills) appearing in skill description files, using them as candidates for reference dependency information. This approach can handle natural language references with diverse expressions, improving the recall rate of implicit dependency identification and making it suitable for scenarios where skill description files are rich in content and have diverse reference formats.

[0079] In other examples, implicit dependency extraction can also be based on predefined rules to extract keywords and match path patterns in natural language description text, identifying strings that conform to skill path formats (such as skill-root / name / SKILL.md or . / skill / SKILL.md, etc.) as reference dependency information. This allows for implicit dependency identification without relying on a large language model, resulting in faster processing speeds and suitability for scenarios where skill description files have relatively standardized reference formats.

[0080] After identifying reference dependency information, it can be matched with known skills in the skill source repository to obtain the implicit dependency set corresponding to candidate skill identifiers. In some examples, the matching method can be exact string matching of skill names or paths, comparing the skill names or paths identified in the reference dependency information with the skill directory names in the skill source repository one by one. If a match is found, the corresponding skill identifier is added to the implicit dependency set. In other examples, the matching method can also be semantic similarity matching, calculating the semantic similarity between the skill descriptions in the reference dependency information and the description text of each skill in the skill source repository, and adding skill identifiers with similarity exceeding a preset threshold to the implicit dependency set to accommodate cases where the reference description and skill name are not completely consistent.

[0081] Through the above methods, the semantic parsing and repository matching mechanism of implicit dependencies can transform skill references in skill description files that are not declared in a machine-readable format into processable dependencies, effectively supplementing the coverage blind spots that may exist in structured explicit dependencies and improving the completeness of overall dependency parsing.

[0082] In some examples, after completing skill attribute determination, structured explicit dependency extraction, and implicit dependency extraction, the dependency resolution and merging / pruning steps can merge and prune the dependency information based on skill attributes to obtain the target dependency corresponding to the candidate skill identifier.

[0083] For example, when the skill attribute corresponding to a candidate skill identifier is a routing attribute, structured explicit dependencies and implicit dependencies can be merged to obtain candidate dependencies. During merging, a deduplication strategy can be used, which involves taking the union of the two dependency sets and removing duplicates to ensure that each skill identifier in the candidate dependency is unique. This way, the explicit dependencies declared by the routing skill in the configuration file and the routed skills referenced by the description file can be fully preserved, avoiding the omission of toolchain skills actually called by the routing skill due to ignoring implicit dependencies.

[0084] For example, if the skill attribute corresponding to a candidate skill identifier is a non-routable attribute, and the structured explicit dependency is not empty, then the structured explicit dependency is used as a candidate dependency, and the implicit dependency is not introduced. This way, for ordinary skills with fully maintained configuration files, their runtime dependencies can be completely covered by explicit declarations. In this case, introducing an implicit dependency might incorrectly include references (not runtime dependencies) in the description file into the closure, causing the closure scope to expand unnecessarily. If the structured explicit dependency is empty and the implicit dependency is not empty, then the implicit dependency is used as a candidate dependency to ensure compatibility with historical skill scenarios where the skill configuration file is not yet fully maintained.

[0085] After identifying candidate dependencies, they can be directly used as target dependencies, or the non-runtime dependencies among the candidate dependencies can be trimmed to obtain the target dependency. Non-runtime dependencies can include dependencies that are not needed at runtime, such as Version Control System (VCS) related directories, cache directories, build artifact directories, and NodeModules directories.

[0086] In some examples, the pruning of non-runtime dependencies can be achieved based on a predefined list of exclusion rules, removing skill identifiers from the dependency set that match the exclusion rules in the candidate dependencies. This allows for flexible management of exclusion rules through configuration, facilitating adjustments to the pruning strategy based on different deployment environments.

[0087] In other examples, the pruning of non-runtime dependencies can also be achieved based on the dependency type field in the skill configuration file, removing skill identifiers marked as non-runtime types (such as dev, build, test, etc.) from the candidate dependencies. This allows pruning to be performed using existing type information in the skill configuration file, reducing the need to maintain an external exclusion rule list.

[0088] In the above manner, the dependency merging and pruning logic based on skill attributes can adopt differentiated dependency processing strategies between routing skills and non-routing skills. While ensuring the integrity of routing skill dependencies, it controls the closure scope of non-routing skills and further simplifies target dependencies through non-runtime dependency pruning, so that the final generated target dependency relationship topology is both complete and accurate.

[0089] In this step, multiple dependency declarations in the skill configuration file and skill description file can be read through dependency resolution and merging / pruning steps. This achieves a dual-source dependency extraction mechanism that covers both machine-readable explicit dependencies and natural language implicit dependencies. It can effectively accommodate historical skill scenarios that are not fully maintained in the skill configuration file and improve the coverage of dependency extraction.

[0090] Step S223: If the target dependency is not empty, use the skill identifier in the target dependency as the new candidate skill identifier, and recursively execute the dependency resolution and merging / pruning steps until all candidate skill identifiers have completed the dependency resolution and merging / pruning steps.

[0091] For example, the determination method for whether all candidate skill identifiers have completed the dependency resolution and merging / pruning steps can include: the target dependency corresponding to the candidate skill identifier is empty, or all skill identifiers in the target dependency have completed dependency resolution. For instance, when the target dependency is empty, the recursion terminates, indicating that the current skill node does not have any lower-level dependencies that need further resolution.

[0092] In some examples, a depth-first search (DFS) strategy can be used, recursively traversing downwards for the target dependencies of each candidate skill identifier until leaf nodes are reached, and then backtracking to process dependencies at the same level. This allows for earlier resolution of leaf skills' dependencies, facilitating the gradual construction of the dependency graph according to topological order, and is suitable for skill tree scenarios with deep dependency chains.

[0093] In other examples, a breadth-first search (BFS) strategy can be used to process the target dependencies of candidate skill identifiers layer by layer, resolving the dependencies of all skill nodes at the same level before moving to the next level. This reduces the recursion depth in skill trees with shallow dependency levels but large widths, lowers the risk of stack overflow, and improves processing stability.

[0094] By using steps S221 to S223 above, and recursively expanding the dependency resolution of candidate skill identifiers layer by layer from the root skill identifier as the starting point, all skill nodes required for the root skill to run can be fully covered, improving the completeness and reliability of dependency relationship topology generation.

[0095] Figure 4This is a schematic diagram illustrating another process for generating target dependency topology provided in this embodiment of the disclosure. For example... Figure 4 As shown, the method for generating target dependency topology may include steps S410 to S420.

[0096] Step S410: Obtain the skill source repository and root skill identifier set.

[0097] For example, a skill source repository and at least one root skill identifier can be obtained for generating the target skill asset package. For a detailed implementation of this step, please refer to [link / reference]. Figure 2 The description of step S210 in the illustrated embodiment will not be repeated here.

[0098] Step S420: Generate the target dependency topology.

[0099] This step may include the process of scanning the skills catalog and outputting the target dependency topology.

[0100] For example, the skill source repository can first be scanned, such as the skill directory containing SKILL.md or SKILL.md.enc, to confirm all accessible skill sets in the repository. By scanning directories containing skill description files, directories in the repository that do not conform to the skill format specifications can be filtered out, ensuring that subsequent dependency resolution objects are all valid skill nodes.

[0101] After scanning is complete, starting with the skills in the root skill identifier set, the root skills are visited sequentially. For each visited skill, dependency information can be obtained in parallel from three sources: dependency declarations in the skill configuration file, dependency declarations based on structured metadata in the skill description file, and natural language description text in the skill description file.

[0102] For example, dependency declarations in the skill configuration file (such as `depends_on` in `skill.toml`) can be read as the primary source of structured explicit dependencies. The skill configuration file (`skill.toml`) can explicitly declare the current skill's runtime dependencies on other skills using machine-readable field formats (such as a list of `depends_on` fields).

[0103] For example, dependency declarations based on structured metadata in the skill description file (such as `frontmatter depends_on`) can be read as a second source of structured explicit dependencies. The `frontmatter` section of the skill description file (SKILL.md) can contain dependency information declared in a structured format (such as YAML header fields), which, together with the dependency declarations in the skill configuration file, constitute the complete source of structured explicit dependencies.

[0104] For example, the natural language description text in the skill description file can be read as a source of implicit dependencies. This natural language description text may contain path references, name references, or functional descriptions of other skills. These references may not be explicitly declared in the skill configuration file, but they still constitute actual dependencies at runtime. The specific implementation of implicit dependency semantic parsing and repository matching can be found in the relevant descriptions in the above embodiments, and will not be repeated here.

[0105] After reading the dependencies from the three sources mentioned above, dependency merging can be performed. This combines dependency declarations from the skill configuration file, dependency declarations from the structured metadata of the skill description file, and implicit dependencies extracted from the natural language description text, forming a complete set of candidate dependency information for the current skill. It should be noted that during dependency merging, deduplication can be performed, or a direct merge can be used.

[0106] Furthermore, after merging dependencies, it can be determined whether the skill attribute is a routing attribute. If the determination result is yes, meaning the current skill has routing capabilities, then the structured explicit dependencies and implicit dependencies are retained and merged as candidate dependencies, ensuring that no routed skills referenced by the routing skill through the description file are missed. If the determination result is no, meaning the current skill does not have routing capabilities, then implicit dependencies are used only when the structured explicit dependencies are empty; if the structured explicit dependencies are not empty, then the structured explicit dependencies are used as candidate dependencies, and implicit dependencies are not introduced, to avoid incorrectly including referential references in the description file into the closure (skill asset). The specific implementation of this skill attribute determination can be found in the relevant descriptions in the foregoing embodiments of this disclosure, and will not be repeated here.

[0107] After determining candidate dependencies based on skill attributes, non-runtime dependencies can be trimmed. Dependencies that are not needed at runtime (such as version control system related directories, cache directories, build artifact directories, node module directories, etc.) can be removed from the candidate dependencies to obtain the target dependencies of the current skill.

[0108] After determining the target dependencies for the current skill, it checks if there are any unvisited dependencies. If the result is yes, meaning there are skill identifiers in the target dependencies that have not yet undergone dependency resolution, these skill identifiers are treated as new skills to be visited, and the complete process of visiting the root skill, reading in three directions, merging dependencies, determining routing attributes, and pruning non-running dependencies is executed iteratively. If the result is no, meaning all dependencies have been visited and resolved, the loop ends, and the target dependency topology is generated. The specific implementation of the loop traversal strategy (such as depth-first traversal or breadth-first traversal) can be found in the relevant descriptions in the above embodiments, and will not be repeated here.

[0109] By adopting the above approach, which involves scanning the skill catalog to identify the set of accessible skills, performing dependency reading and merging for each accessed skill, performing differentiated dependency retention or pruning based on routing attributes, and traversing all unaccessed dependencies through a recursive loop mechanism, it is possible to cover all skill nodes required for operation in the skill source repository. This approach achieves dependency integrity while precisely controlling the scope of closures, providing an accurate and reliable dependency topology foundation for subsequent skill asset packaging.

[0110] In some examples of this disclosure, the aforementioned target running skill set may include skill data corresponding to each target skill identifier in the target dependency topology. This skill data includes text data and / or non-text data. The text data may include skill assets stored in readable text formats such as Markdown files, Python scripts, Shell scripts, YAML configuration files, JSON files, and TOML files; the non-text data may include skill assets in binary formats such as images and model weight files. After obtaining the target running skill set, the method for generating the target skill asset package based on the target running skill set in step S230 may include the following steps S231 to S234.

[0111] Step S231: Generate skill integrity verification information corresponding to each target skill identifier based on the skill data.

[0112] The skill integrity verification information can be a hash digest generated for the content of a single skill catalog, which is used to perform skill-by-skill level verification of the content integrity of the skill at the receiving end.

[0113] Step S232: Generate the target skill file based on the skill data.

[0114] In some examples, the skill data corresponding to each target skill identifier can be merged to obtain a target skill file.

[0115] In other examples, the text data in the skill data can be encrypted to obtain encrypted text data, and the target skill file can be generated based on the encrypted text data and non-text data.

[0116] Encrypting text data in this way prevents unauthorized access to the skill content within the distribution package, thus ensuring content security during the skill asset distribution process.

[0117] In some examples, the target skill file may be stored in a compressed archive format, containing all skill data, such as encrypted text data and non-text data within the skill data.

[0118] Step S233: Generate auxiliary information corresponding to the target skill file based on the target skill identifier and skill integrity verification information.

[0119] The auxiliary information may include the root skill identifier, the skill integrity verification information corresponding to each target skill identifier, and the file integrity verification information generated based on the target skill file.

[0120] Step S234: Generate the target skill asset package based on the target skill file and auxiliary information.

[0121] This auxiliary information can be used to verify the integrity of the target skill files when the target skill asset package is received at the skill asset receiving end.

[0122] The target skill asset package can include two components: target skill documents and auxiliary information. Together, they can form a complete skill asset package that is distributable and verifiable.

[0123] By employing the above method, skill integrity verification information is generated from the skill data in the target skill set, and target skill files and auxiliary information are further generated and ultimately packaged into a target skill asset package. This enables the distribution of skill assets with integrity verifiability, allowing the receiving end to complete trusted verification before deployment and effectively preventing the risk of tampering and loss of skill assets during transmission. Furthermore, encrypting the text data can further enhance the content security of the skill asset package.

[0124] Figure 5 This is a schematic diagram illustrating a process for generating a target skill asset package, provided in an embodiment of this disclosure. Figure 5 As shown, the method for generating a target skill asset package may include steps S501 to S510.

[0125] Step S501: Based on the target dependency topology, obtain the target running skill set (e.g., a list of closures) from the skill source repository.

[0126] For example, the set of target running skills can also be called a closure list, which can be an ordered set of skill data corresponding to all target skill identifiers in the target dependency topology, arranged according to the dependency topology order, so that leaf skills are processed before root skills.

[0127] In some examples, the target skill set can be constructed by traversing all target skill identifiers in the target dependency topology and sequentially reading all files from the corresponding skill directories in the skill source repository according to the topology sorting order. This ensures that the skill data reading order is consistent with the dependency relationship, facilitating subsequent sequential processing and reducing the risk of deployment anomalies caused by disordered order.

[0128] In other examples, skill data corresponding to all target skill identifiers in the target dependency topology can be read in parallel, and then rearranged according to topological order after all data has been read. This can reduce the reading time in scenarios with large-scale skill sets and improve the overall packaging efficiency.

[0129] Step S502: Copy the skill to the temporary staging area.

[0130] This temporary storage area can be a temporary working directory for storing skill data to be packaged. It is isolated from the skill source repository to avoid the packaging operation affecting the content of the source repository.

[0131] In some examples, all files from all skill directories in the target skill set can be copied to a temporary staging area first, and then the non-runtime dependency exclusion operation can be performed uniformly later. This makes the copying logic simple and facilitates a comprehensive review and verification of the staging area content.

[0132] In other examples, files can be selectively copied according to predefined filtering rules during the copying process, writing only files that meet runtime requirements to the temporary staging area. This reduces the disk usage of the temporary staging area and improves processing efficiency in environments with limited storage resources.

[0133] Step S503: Exclude non-runtime dependencies, such as version control systems (VCS), caches, builds, and node modules.

[0134] For example, non-runtime dependencies may include version control system related directories (such as the .git directory), cache directories, build artifact directories, node module directories, and other content that is not needed at runtime. Excluding the above content can ensure that only the skill data required at runtime is retained in the temporary staging area, avoiding the inclusion of irrelevant content in the final asset package.

[0135] For example, excluding non-runtime dependencies can be achieved based on a predefined list of exclusion rules, removing files or directories matching the exclusion rules from the staging area. This allows for flexible management of exclusion rules through configuration, facilitating adjustments to the pruning strategy based on different deployment environments. As another example, excluding non-runtime dependencies can also be achieved based on the dependency type field in the skill configuration file, removing dependencies marked as non-runtime types (such as dev, build, test, etc.) from the staging area. This leverages existing type information in the skill configuration file to complete the exclusion, reducing the need to maintain external exclusion rule lists.

[0136] Step S504: Read version information (e.g., skill.toml version).

[0137] For example, the corresponding version field information can be read from the skill configuration file (skill.toml) under each skill directory. The version information can be used to record the version number of each skill when generating auxiliary information, so that the skill asset receiving end can perform version verification during deployment, and locate specific versions of skills in subsequent audit and rollback scenarios.

[0138] Step S505: Generate skill integrity verification information corresponding to each target skill identifier (e.g., calculate stable tar sha256 for each skill).

[0139] For example, the skill integrity verification information can be a hash digest generated for the content of a single skill directory, used at the receiving end for fine-grained verification of the skill's content integrity. The stable tar method involves packaging the files within the directory in a deterministic order, removing unstable metadata such as timestamps, ensuring that the hash values ​​generated for skill directories with the same content are consistent and reproducible. In some examples, the skill integrity verification information can be obtained by calculating a 256-bit Secure HashAlgorithm (SHA-256) hash value after packaging the skill directory using the stable tar method. This provides the receiving end with a reproducible integrity verification benchmark, avoiding false alarms due to inconsistent hash values ​​caused by non-content factors such as file timestamps, and improving the stability of the verification results. In other examples, the skill integrity verification information can also be calculated using other hash algorithms such as a 512-bit Secure HashAlgorithm (SHA-512). This enhances the collision resistance of the verification information in scenarios with higher security requirements, strengthening the protection against tampering of skill content.

[0140] Step S506: Encrypt text assets.

[0141] For example, text data in the skill data can be encrypted while non-text data remains unencrypted, resulting in encrypted text data. Text data can include skill assets stored in readable text formats such as Markdown files, Python scripts, Shell scripts, YAML configuration files, JSON files, and TOML files; non-text data can include skill assets in binary formats such as images and model weight files. Encryption of the text data can be achieved using symmetric encryption algorithms (such as the Advanced Encryption Standard AES), asymmetric encryption, or a hybrid encryption algorithm.

[0142] All text files in the temporary storage area are encrypted one by one, generating corresponding encrypted files. The original filenames and directory structure are preserved so that the receiving end can decrypt and deploy them normally. This maintains the integrity of the skill directory structure while ensuring encryption strength, facilitating decryption and deployment by the receiving end according to the original directory structure. In other examples, text data encryption can also employ asymmetric or hybrid encryption schemes, using the receiving end's public key to encapsulate the encryption key, supporting key management in multi-receiver scenarios. This allows for secure key distribution without pre-sharing the symmetric key, suitable for scenarios with a large number of receivers or high key management requirements.

[0143] Step S507: Generate the target skill file (e.g., core.tar.gz).

[0144] For example, target skill files can be generated based on encrypted text data and non-text data. Target skill files can be stored in a compressed archive format (for example, core.tar.gz) containing encrypted text data and non-text data of all skills in the staging area, with the directory structure organized according to dependency topology.

[0145] Step S508: Based on the file integrity verification information generated from the target skill file (e.g., calculate the total package SHA256).

[0146] For example, the file integrity verification information may include a hash digest calculated for the entire target skill file, used at the receiving end to verify whether the entire asset package is complete and untampered during transmission. Unlike the skill integrity verification information generated for a single skill in step S505, the file integrity verification information is obtained by hashing the entire target skill file, allowing for a quick determination of the overall package integrity. The skill integrity verification information, on the other hand, is used for fine-grained integrity verification on a skill-by-skill basis, complementing each other in terms of verification granularity. In some examples, the file integrity verification information can be obtained by calculating the SHA-256 hash value of the entire target skill file (e.g., core.tar.gz) (i.e., calculating the total packet SHA256). This allows the receiving end to quickly verify the entire packet before starting unpacking; if the overall packet verification passes, fine-grained verification on a skill-by-skill basis can then be performed, improving verification efficiency and reducing unnecessary unpacking overhead. In other examples, the file integrity verification information can also be calculated using stronger hash algorithms such as SHA-512 to meet scenarios with higher requirements for transmission security. This further enhances the collision resistance of the overall packet integrity verification and reduces the risk of hash collision attacks.

[0147] Step S509: Generate auxiliary information (e.g., core.json manifest).

[0148] For example, this auxiliary information can be stored in a structured manifest file format (e.g., core.json manifest), containing the root skill identifier, version information and skill integrity verification information corresponding to each target skill identifier, and file integrity verification information generated based on the target skill file. This auxiliary information can be used to perform integrity verification on the target skill file when the skill asset receiver receives the target skill asset package, and to provide a reference benchmark for skill versions and hashes in audit and rollback scenarios. In some examples, the auxiliary information can be serialized and stored in JSON format, recording the root skill identifier, version number and hash value of each skill, and the overall package hash value in key-value pairs, facilitating programmatic parsing and verification by the receiver. This reduces the implementation complexity of parsing auxiliary information on the receiver, improves the automation of the verification process, and reduces the need for manual intervention. In other examples, the auxiliary information can also be stored in other structured formats such as TOML or YAML to be compatible with different receiver preferences for configuration file formats. This improves the flexibility of the auxiliary information format, making it easy to read and use directly in deployment environments with different technology stacks, and reducing format adaptation costs.

[0149] Step S510: Generate the target skill asset package.

[0150] For example, the target skill asset package can consist of two parts: target skill files and auxiliary information. Together, they form a complete, distributable, and verifiable skill asset package. In some examples, the target skill asset package can be distributed by packaging the target skill files (such as core.tar.gz) and auxiliary information (such as core.json manifest) into a single archive file, facilitating delivery via network transmission or offline media. This simplifies the distribution process, reduces the risk of missing files at the receiving end, and ensures that the target skill files and auxiliary information always arrive in pairs. In other examples, the target skill asset package can also be distributed in a directory structure, with the target skill files and auxiliary information stored separately in designated directories. The receiving end reads the corresponding files according to the directory structure and then performs verification and deployment. This allows the receiving end to directly access the auxiliary information without unpacking, speeding up the verification process and is suitable for local deployment or high-speed intranet transmission scenarios.

[0151] By adopting the above method, through a series of processes such as acquiring the target running skill set, copying skills to a temporary storage area, excluding non-running dependencies, reading version information, generating skill-by-skill integrity verification information, encrypting text data, packaging target skill files, generating file integrity verification information, generating auxiliary information, and generating target skill asset packages, a target skill asset package with both content security and integrity verifiability can be generated, providing a reliable data foundation for the trusted distribution and offline deployment of skill assets.

[0152] This disclosure also provides a skill asset processing system, which may include a skill asset distribution terminal and a skill asset receiving terminal.

[0153] The skill asset distribution end can be configured to execute the skill asset processing method in the foregoing embodiments of this disclosure to generate a target skill asset package and send the target skill asset package to the skill asset receiving end.

[0154] The skill asset receiver can be configured to receive target skill asset packages and deploy skill assets based on the target skill asset packages.

[0155] In some examples, the skill asset receiver can be configured to perform an integrity check on the target skill file based on the auxiliary information, provided that the target skill asset package includes the target skill file and auxiliary information, and deploy the skill asset based on the target skill file if the integrity check passes.

[0156] In some examples, the skill asset processing system can be as follows: Figure 1 The skill asset processing system shown.

[0157] Figure 6 This is a schematic diagram of another skill asset processing system provided in this embodiment. This embodiment provides a skill asset processing system. Figure 6 As shown, the skill asset processing system may include a skill source repository 610, a dependency resolution module 620, a trimming module 630, a packaging and encryption module 640, and an installation and auditing module 650. The skill asset distribution end may include the skill source repository 610, dependency resolution module 620, trimming module 630, and packaging and encryption module 640; the skill asset receiving end may include the installation and auditing module 650.

[0158] The skill source repository 610 can be used to store all skill assets. For example, the skill assets in the skill source repository can include various skill modules such as AI model master skills (ai-model-master), AI operator master skills (ai-op-master), kernel performance profiling skills (kernel-perf), acceptance gate skills (acceptance-gate), development tool skills (supa-dev), and other GPGPU skills. Each skill asset can contain a corresponding skill configuration file and skill description file.

[0159] The dependency resolution module 620 can be used to read skill configuration files and skill description files from the skill source repository 610 and extract dependency information for each candidate skill identifier. The dependency resolution module 620 may include a first explicit dependency resolver (e.g., skill.toml resolver), a second explicit dependency resolver (e.g., frontmatter resolver), an implicit dependency scanner (e.g., SKILL.md reference scanner), and a dependency merging and deduplication submodule. The first explicit dependency resolver can be used to parse dependency declarations in the skill configuration file (skill.toml) and extract structured explicit dependencies; the second explicit dependency resolver can be used to parse structured metadata dependency declarations in the frontmatter area of ​​the skill description file (SKILL.md) and extract supplementary structured explicit dependencies; the implicit dependency scanner (e.g., the SKILL.md reference scanner) can be used to perform semantic parsing on the natural language description text in the skill description file, identify reference dependency information and match it with skills in the skill source repository to extract implicit dependencies; the dependency merging and deduplication submodule can be used to merge and deduplicate the above multi-source dependency information according to skill attributes to obtain a merged dependency set for each candidate skill identifier.

[0160] The trimming module 630 can be used to construct a skill dependency graph and perform transitive closure calculation based on the merged dependency set output by the dependency resolution module, to obtain the minimum set of skill nodes that covers all runtime dependencies starting from the root skill identifier; then, it performs non-runtime dependency trimming, removing dependencies that are not needed at runtime, such as version control system related directories, cache directories, build artifact directories, and node module directories; finally, it performs topological sorting, determines the processing order of skills according to the directed graph of dependency relationships, and outputs the target dependency relationship topology.

[0161] The packaging and encryption module 640 can be used to copy the skill data corresponding to the target dependency topology output by the trimming module to a temporary staging area, calculate the stable hash of each skill to generate integrity verification information for each skill, encrypt the text data, generate the target skill file (e.g., core.tar.gz) and generate auxiliary information (e.g., core.json manifest), and finally generate a target skill asset package containing the target skill file and auxiliary information.

[0162] The installation and auditing module 650 can be used to perform integrity verification and deployment of the target skill asset package at the skill asset receiving end 200. The integrity verification process can include skill-by-skill hash comparison and overall package hash comparison. After successful verification, a skill lock list (e.g., skills.lock or pin list) can be generated, recording the version and hash information of the installed skills for subsequent auditing and rollback. Furthermore, offline image deployment can be performed, decompressing the skill data in the target skill file and deploying it to the target directory. Optionally, orphan / missing skill detection can also be performed to identify skills that are declared as dependent but are actually missing in the deployment environment and record audit logs.

[0163] The skill asset receiver can be configured to perform integrity verification on the target skill file based on the auxiliary information when the target skill asset package includes target skill files and auxiliary information, and deploy the skill asset based on the target skill file if the integrity verification passes.

[0164] In some examples, the skill asset receiver 200 can employ a two-stage integrity verification strategy: In the first stage, a hash value is calculated for the entire target skill file, and compared with the file integrity verification information recorded in the auxiliary information. If they match, the process proceeds to the second stage. In the second stage, a stable tar hash value is calculated for each skill in the target skill file, and compared one by one with the corresponding skill integrity verification information in the auxiliary information. If all hashes match, the integrity verification is confirmed to have passed. This allows for rapid overall package verification and further pinpointing integrity issues at the specific skill level, improving the granularity of the verification and the efficiency of problem localization.

[0165] In other examples, the skill asset receiver 200 may also perform only fine-grained integrity checks on a skill-by-skill basis. It calculates a hash value for each skill and compares it with the skill integrity check information in the auxiliary information. Once all skills pass the check, the overall integrity is confirmed. This allows integrity checks to be performed without relying on the overall packet hash, making it suitable for scenarios where the target skill asset packet arrives at the receiver via streaming or fragmented transmission.

[0166] After the integrity verification passes, the skill asset receiving end 200 can decompress the skill data in the target skill file and deploy it to the target directory, completing the installation of the skill asset. If the integrity verification fails, the skill asset receiving end can refuse installation and return a verification failure message to the skill asset distribution end and / or operation terminal to prevent incomplete or tampered skill assets from being deployed incorrectly.

[0167] By adopting the above approach, the skill asset processing system can achieve end-to-end trusted assurance of the skill asset distribution link at the system level through dual-source dependency resolution, closure trimming and trusted packaging at the skill asset distribution end, and integrity verification and secure deployment at the skill asset receiving end, effectively preventing the risk of loss and tampering of skill assets during transmission.

[0168] Figure 7 This is an interactive schematic diagram of a skill asset processing method provided in an embodiment of this disclosure. For example... Figure 7 As shown, this method involves interaction between the build end, dependency resolution and trimming module, packaging and encryption module, and installer end. The build end can be... Figure 1 The modules shown in the operation terminal or skill asset distribution terminal, including the dependency parsing and trimming module and the packaging encryption module, can be modules in the skill asset distribution terminal, and the installation terminal can be a module in the skill asset receiving terminal. This method may include the following steps S701 to S709.

[0169] Step S701: Construct the end-to-end dependency resolution and trimming module by inputting the skill source repository and the root skill identifier set.

[0170] This step can initiate the skill asset processing flow. The build side can be responsible for initiating the packaging task and providing the skill source repository path and root skill identifier set as input data. The implementation methods for the skill source repository and root skill identifier set can be found in the descriptions of the foregoing embodiments of this disclosure.

[0171] Step S702: The dependency resolution and pruning module generates the target dependency topology.

[0172] For example, after receiving the skill source repository and the root skill identifier set, the dependency resolution and trimming module performs internal processing to generate the target dependency topology. This internal processing may include scanning the skill directory containing skill description files in the skill source repository, performing dual-source dependency extraction (i.e., structured explicit dependency extraction and implicit dependency extraction) from skill configuration files and skill description files, dependency merging, route attribute judgment, non-runtime dependency trimming, transitive closure calculation, and topology sorting.

[0173] Step S703: The dependency resolution and trimming module returns the generated target dependency topology to the build end.

[0174] For example, the dependency resolution and trimming module can return the generated target dependency topology to the build end after completing its internal processing. For instance, the generated target dependency topology can be returned to the build end as a processing result, and the build end can coordinate the subsequent packaging and encryption process.

[0175] The target dependency topology can contain a directed dependency graph structure of each target skill identifier and its corresponding target dependencies, covering all skill nodes required for the root skill to run.

[0176] Step S704: The build end sends a start packaging command to the packaging encryption module.

[0177] For example, after receiving the target dependency topology, the build end passes the target dependency topology along with the start packaging command to the packaging encryption module, triggering the packaging encryption module to start executing subsequent packaging encryption operations.

[0178] Step S705: The packaging encryption module generates integrity verification information for each skill and encrypts the text assets.

[0179] For example, after receiving the target dependency topology and the start packaging instruction, the packaging encryption module performs internal processing to generate integrity verification information for each skill and encrypt text assets. For instance, it may retrieve the target set of running skills (e.g., a list of closures) from the skill source repository based on the target dependency topology; copy the skill data from the target set of running skills to a temporary staging area, excluding non-runtime dependencies such as version control systems (VCS), caches, builds, and node modules; read the skill.toml version information for each skill; generate integrity verification information for each skill (e.g., calculate the stable tar sha256 for each skill); and encrypt text assets.

[0180] Step S706: The packaging encryption module generates the target skill file and the auxiliary information.

[0181] For example, the packaging encryption module can generate the target skill file and the aforementioned auxiliary information after completing internal processing, and return the generation result to the build end. For instance, it can generate the target skill file (e.g., core.tar.gz) based on encrypted text data and non-text data, and generate auxiliary information (e.g., core.json manifest) based on the root skill identifier, the integrity verification information of each skill, and the file integrity verification information (e.g., calculating the total package SHA256), and return the target skill file and the aforementioned auxiliary information together to the build end.

[0182] Step S707: The build end sends the target skill asset package to the install end, completing the distribution of the target skill asset package.

[0183] For example, the build end can combine the target skill file with auxiliary information into a target skill asset package, and send the target skill asset package to the installer end via network transmission or offline media. The installer end can be the skill asset receiving end.

[0184] Step S708: The installation end performs an integrity verification.

[0185] For example, after receiving the target skill asset package, the installation end can perform internal integrity verification. For instance, it can perform integrity verification on the target skill files based on auxiliary information in the target skill asset package, including overall file hash verification (checking file integrity verification information) and skill-by-skill hash verification (checking the integrity verification information of each skill).

[0186] Step S709: Installation successful or rejected on the installation end.

[0187] For example, after completing the integrity verification, the installer returns a success or rejection result to the builder. If the integrity verification passes, the installer completes the decompression and deployment of the skill assets and returns a success message to the builder; if the integrity verification fails, the installer rejects the installation and returns a rejection message to the builder to prevent incomplete or tampered skill assets from being deployed incorrectly. The builder can decide whether to re-initiate the distribution process or handle the exception based on the returned result.

[0188] By adopting the above method, and through the division of responsibilities—with the build end focusing on unified scheduling, the dependency resolution and trimming module focusing on dependency resolution and closure trimming, the packaging and encryption module focusing on packaging and encryption, and the installation end focusing on integrity verification and deployment—modular collaboration of the skill asset processing chain is achieved, thereby improving the efficiency and reliability of the skill asset processing method.

[0189] This disclosure also provides an electronic device, such as... Figure 8As shown, the electronic device 800 may include a processor 810 and a memory 820. The memory can be used to store computer instructions, and the processor can be used to retrieve computer instructions from the memory to execute all or part of the steps of any of the methods in the foregoing embodiments of this disclosure. The processor may be one or more, and these processors may execute instructions individually or jointly. Similarly, the memory may be one or more, and these memories may store the aforementioned computer instructions individually or jointly. In some examples, the processor may be a CPU, GPU, GPGPU, NPU, or TPU, or it may be a chip in the form of an Application Specific Integrated Circuit (ASIC), System on Chip (SOC), Field Programmable Gate Array (FPGA), Programmable Logic Array (PLA), etc. In some examples, the electronic device may be any type of terminal device, workstation, or server, etc., and this embodiment does not limit this. Optionally, the electronic device may be... Figure 1 The skill asset distribution terminal shown.

[0190] This disclosure also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements all or part of the steps of any of the methods in the foregoing embodiments of this disclosure. Optionally, the computer-readable storage medium may be a non-transitory storage medium, but is not limited thereto, and may also be a temporary storage medium.

[0191] This disclosure also provides a computer program product that may include a computer program that, when executed by a processor, can implement all or part of the steps of any of the methods in the foregoing embodiments of this disclosure.

[0192] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0193] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and apparatuses according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, unit, or part of a circuit. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should be noted that embodiments of the present disclosure may include some or all of the functions marked in the multiple blocks in the drawings, and may also include other functions not shown in the blocks in the drawings. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented in hardware that performs the specified function or action, or in a combination of dedicated hardware and computer instructions. Unless otherwise specified, implementation in hardware, implementation in software, and implementation in a combination of software and hardware may be equivalent.

[0194] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein. The scope of this disclosure is defined by the appended claims.

Claims

1. A method for processing skill assets, characterized in that, The method includes: Obtain a skill source repository for generating the target skill asset package and at least one root skill identifier, wherein the skill source repository includes skill configuration files and skill description files; Based on the skill configuration file and the skill description file, a target dependency topology is recursively generated starting from the root skill identifier. The target dependency topology includes multiple target skill identifiers and their corresponding target dependencies. Each target skill identifier includes the root skill identifier and the skill identifiers recursively dependent on it. If the skill attribute corresponding to the target skill identifier is a routing attribute with routing capabilities, then the target dependency corresponding to the target skill identifier includes structured explicit dependencies extracted from structured metadata in the skill configuration file and the skill description file, and implicit dependencies extracted from natural language description text in the skill description file. If the skill attribute corresponding to the target skill identifier is a non-routing attribute, then the target dependency corresponding to the target skill identifier includes non-empty structured explicit dependencies or implicit dependencies when the structured explicit dependencies are empty. Based on the target dependency topology, the target running skill set is obtained from the skill source repository, and the target skill asset package is generated based on the target running skill set.

2. The method according to claim 1, characterized in that, The step of recursively generating a target dependency topology based on the skill configuration file and the skill description file, starting from the root skill identifier, includes: The root skill identifier is used as a candidate skill identifier to be recursively traversed; Perform dependency resolution and merging / pruning steps on the candidate skill identifiers to generate the target dependencies corresponding to the candidate skill identifiers; If the target dependency is not empty, the skill identifier in the target dependency is used as a new candidate skill identifier, and the dependency resolution and merging and pruning steps are recursively executed until all candidate skill identifiers have completed the dependency resolution and merging and pruning steps. The dependency resolution and merging / pruning steps include: Based on the skill configuration file and the skill description file, the skill attributes, structured explicit dependencies, and implicit dependencies corresponding to the candidate skill identifier are generated; After processing the structured explicit and implicit dependencies based on the skill attributes, the target dependency corresponding to the candidate skill identifier is obtained.

3. The method according to claim 2, characterized in that, The step of generating skill attributes, structured explicit dependencies, and implicit dependencies corresponding to the candidate skill identifier based on the skill configuration file and the skill description file includes: The skill attributes corresponding to the candidate skill identifier are determined based on the skill configuration file. Based on the dependency declarations in the skill configuration file and the dependency declarations in the skill description file based on structured metadata, extract the structured explicit dependencies corresponding to the candidate skill identifier; Based on the natural language description text in the skill description file, extract the implicit dependencies corresponding to the candidate skill identifiers.

4. The method according to claim 3, characterized in that, The step of extracting the implicit dependencies corresponding to the candidate skill identifiers based on the natural language description text in the skill description file includes: Semantic parsing is performed on the natural language description text in the skill description file to identify the reference dependency information corresponding to the candidate skill identifier; Based on the reference dependency information, the implicit dependencies corresponding to the candidate skill identifiers are obtained by matching the skills in the skill source repository.

5. The method according to claim 3, characterized in that, The step of determining the skill attribute corresponding to the candidate skill identifier according to the skill configuration file includes: Read the attribute field corresponding to the candidate skill identifier in the skill configuration file; If the attribute field contains a route type flag, then the skill attribute of the candidate skill identifier is determined to be a route attribute; or, if the attribute field does not contain a route type flag, then the skill attribute of the candidate skill identifier is determined to be a non-route attribute.

6. The method according to claim 2, characterized in that, The step of processing the structured explicit and implicit dependencies according to the skill attributes to obtain the target dependency corresponding to the candidate skill identifier includes: If the skill attribute corresponding to the candidate skill identifier is a routing attribute, the structured explicit dependency and the implicit dependency are merged to obtain the candidate dependency corresponding to the candidate skill identifier; or, If the skill attribute corresponding to the candidate skill identifier is a non-routable attribute, and the structured explicit dependency is not empty, then the structured explicit dependency is used as the candidate dependency corresponding to the candidate skill identifier; if the structured explicit dependency is empty and the implicit dependency is not empty, then the implicit dependency is used as the candidate dependency corresponding to the candidate skill identifier. The target dependency is obtained by pruning the non-runtime dependencies from the candidate dependencies.

7. The method according to any one of claims 1 to 6, characterized in that, The target operational skill set includes skill data corresponding to each target skill identifier in the target dependency topology, and the skill data includes text data and non-text data; The process of generating the target skill asset package based on the target set of operational skills includes: Based on the skill data, skill integrity verification information is generated for each of the target skill identifiers; The text data is encrypted to obtain encrypted text data; A target skill file is generated based on the encrypted text data and the non-text data; Based on the target skill identifier and the skill integrity verification information, auxiliary information corresponding to the target skill file is generated; wherein, the auxiliary information includes the root skill identifier, skill integrity verification information corresponding to each of the target skill identifiers, and file integrity verification information generated based on the target skill file; The target skill asset package is generated based on the target skill file and the auxiliary information; wherein, the auxiliary information is used to perform integrity verification on the target skill file when the skill asset receiving end receives the target skill asset package.

8. A skill asset processing system, characterized in that, The skill asset processing system includes a skill asset distribution terminal and a skill asset receiving terminal; wherein: The skill asset distribution terminal is configured to execute the method of any one of claims 1 to 7 to generate a target skill asset package and send the target skill asset package to the skill asset receiving terminal. The skill asset receiving end is configured to receive the target skill asset package and deploy skill assets based on the target skill asset package.

9. The skill asset processing system according to claim 8, characterized in that, The skill asset receiving end is configured to, when the target skill asset package includes target skill files and auxiliary information, perform integrity verification on the target skill files based on the auxiliary information, and deploy skill assets based on the target skill files if the integrity verification passes.

10. An electronic device, characterized in that, The device includes a memory and a processor, the memory being used to store computer instructions, and the processor being used to retrieve the computer instructions from the memory to perform the method of any one of claims 1 to 7.

11. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images