Skill publishing method and device based on configuration data and electronic equipment

Abstract

The application provides a skill publishing method and device based on configuration data and electronic equipment, and relates to the technical field of computer systems, wherein the method comprises: acquiring configuration data corresponding to a first skill and shared assets, the configuration data comprising a space-time side sub-package and a business side sub-package; acquiring reference information of at least one of the space-time side sub-package and the shared assets from the business side sub-package, and constructing a reference graph according to the reference information; performing a first check on the reference graph to obtain a first check result; and performing a publishing operation of the first skill in the case where it is determined according to the first check result that the first skill meets a publishing condition. In the application embodiment, when physical space analysis is performed for multiple scenes, the source code of the two types of executors does not need to be modified, different scenes can be adapted by adding or adjusting the configuration data, physical space analysis can be performed using the first skill based on the existing configuration data in different scenes, and the efficiency of physical space analysis can be improved.

Description

Technical Field

[0001] This application relates to the field of computer system technology, and in particular to a skill publishing method, apparatus and electronic device based on configuration data. Background Technology

[0002] When using large language models for the analysis of complex physical space operations, it is usually necessary to first perform deterministic processing on data from sensors, ticketing, access control, cameras, equipment status, business systems, etc., and then input the processed spatiotemporal context into the large language model or have the large language model call relevant tools for inference.

[0003] Currently, the analysis of physical space operations is usually done only for a single scenario or a single task. For example, analysis logic, indicator codes, rule codes, and prompt word templates are developed separately for each subway station, hub, park, or event scenario.

[0004] The above methods are less efficient when analyzing the physical space of different scenarios. Summary of the Invention

[0005] This application provides a skill publishing method, apparatus, and electronic device based on configuration data to solve the problem of low efficiency when analyzing the physical space of different scenarios.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows:

[0007] In a first aspect, embodiments of this application provide a skill publishing method based on configuration data, the method comprising:

[0008] Acquire configuration data and shared assets corresponding to the first skill. The configuration data includes a spatiotemporal sub-package and a business sub-package. The spatiotemporal sub-package is used to represent the spatiotemporal data of the spatial cognition task corresponding to the first skill. The business sub-package is used to represent the reasoning logic of the spatial cognition task. The spatiotemporal sub-package and the business sub-package are executed by a first executor and a second executor, respectively.

[0009] Obtain reference information of the business-side subpackage to at least one of the spatiotemporal-side subpackage and the shared asset, and construct a reference graph based on the reference information. The reference graph is used to characterize the dependency relationship of the business-side subpackage to at least one of the spatiotemporal-side subpackage and the shared asset.

[0010] The referenced image is subjected to a first verification, and a first verification result is obtained;

[0011] If the first skill meets the release conditions based on the first verification result, the release operation of the first skill is executed.

[0012] Secondly, embodiments of this application provide a skill publishing device based on configuration data, the device comprising:

[0013] The first acquisition module is used to acquire configuration data and shared assets corresponding to the first skill. The configuration data includes a spatiotemporal sub-package and a business sub-package. The spatiotemporal sub-package is used to represent the spatiotemporal data of the spatial cognition task corresponding to the first skill. The business sub-package is used to represent the reasoning logic of the spatial cognition task. The spatiotemporal sub-package and the business sub-package are executed by the first executor and the second executor, respectively.

[0014] The second acquisition module is used to acquire reference information of the business-side sub-package to at least one of the spatiotemporal-side sub-package and the shared asset, and construct a reference graph based on the reference information. The reference graph is used to characterize the dependency relationship of the business-side sub-package to at least one of the spatiotemporal-side sub-package and the shared asset.

[0015] The first verification module is used to perform a first verification on the reference diagram and obtain a first verification result.

[0016] The publishing module is used to execute the publishing operation of the first skill when it is determined from the first verification result that the first skill meets the publishing conditions.

[0017] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of the skill publishing method based on configuration data described in the first aspect.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the skill publishing method based on configuration data described in the first aspect.

[0019] Fifthly, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the skill dissemination method based on configuration data as described in the first aspect.

[0020] In this embodiment, configuration data and shared assets corresponding to a first skill are obtained. The configuration data includes a spatiotemporal sub-package and a business sub-package. The spatiotemporal sub-package represents the spatiotemporal data of the spatial cognition task corresponding to the first skill, and the business sub-package represents the reasoning logic of the spatial cognition task. The spatiotemporal sub-package and the business sub-package are executed by a first executor and a second executor, respectively. Reference information of the business sub-package to at least one of the spatiotemporal sub-package and the shared assets is obtained, and a reference graph is constructed based on the reference information. The reference graph represents the dependency relationship between the business sub-package and at least one of the spatiotemporal sub-package and the shared assets. A first verification is performed on the reference graph to obtain a first verification result. If the first skill meets the release conditions based on the first verification result, the release operation of the first skill is executed. In this embodiment, a reference graph is constructed based on the configuration data and shared assets corresponding to the first skill, and the first skill is released if the reference graph verification passes. When performing physical space analysis for multiple scenarios, there is no need to modify the source code of the two types of executors. Different scenarios can be adapted by adding or adjusting configuration data, and the first skill can be used to perform physical space analysis based on the existing configuration data in different scenarios, which can improve the efficiency of physical space analysis. Attached Figure Description

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

[0022] Figure 1 This is a flowchart of a skill publishing method based on configuration data provided in an embodiment of this application;

[0023] Figure 2 This is a schematic diagram of a system architecture provided in an embodiment of this application;

[0024] Figure 3 This is a diagram of a twin-packet asset model provided in an embodiment of this application;

[0025] Figure 4 This is a schematic diagram of a cross-executor reference provided in an embodiment of this application;

[0026] Figure 5 This is a flowchart of a closure verification and sandbox playback provided in an embodiment of this application;

[0027] Figure 6 This is a flowchart of a dual-channel, two-stage activation process provided in an embodiment of this application;

[0028] Figure 7 This is a runtime consistency fallback flowchart provided in an embodiment of this application;

[0029] Figure 8 This is a schematic diagram of the structure of a skill publishing device based on configuration data provided in an embodiment of this application;

[0030] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0032] When using large language models for the analysis of complex physical space operations, such systems contain at least two types of capabilities: one is deterministic spatiotemporal data preparation capabilities, such as object mapping, field normalization, index calculation, label generation, and spatial constraint verification; the other is uncertain reasoning capabilities, such as attribution explanation, trend judgment, event summarization, and suggestion generation.

[0033] Current engineering implementations include the following:

[0034] One scenario, one code: Develop analysis logic, indicator codes, rule codes, and prompt word templates separately for each subway station, hub, park, or event scenario.

[0035] General Configuration Center: Simple parameters such as thresholds, switches, and addresses are extracted from the code, and the executable program reads the parameters and runs fixed logic.

[0036] Rule engine or workflow engine: Configures parts of the processing flow through rules or task graphs, usually targeting a single executor or a single business process.

[0037] Large language models directly interpret raw data: raw or semi-structured data is given to large language models, which are guided to complete the analysis through prompt words.

[0038] Data pipeline configuration tools: solve some data preparation problems through data task orchestration or SQL templates, but usually do not handle configuration consistency between the data preparation side and the large model inference side.

[0039] The above solution has the following problems:

[0040] Scenario knowledge is coupled with the execution code. Object types, field names, derived metrics, label rules, space constraints, prompts, and inference orchestration are scattered across different code repositories. Introducing a new scenario often requires modifying both the data processing code and the inference code simultaneously.

[0041] Insufficient configuration granularity. Traditional configuration centers primarily handle key-value parameters, making it difficult to express structured differences such as object models, metric dependency graphs, business plugin input parameters, prompt word variables, and spatial validation interface references.

[0042] There is a lack of reference consistency checks between the two execution units. Inference-side prompts or orchestration templates may reference fields, metrics, tags, or spatial objects that have not been generated by the data preparation side, leading to runtime errors, missing fields, or incorrect inference.

[0043] There was a lack of near-production-ready end-to-end verification before release. Single-sided configuration verification could not detect cross-execution issues such as "the spatiotemporal side can run but the business side has incorrect references" or "the business side can render but the spatial verification tool is unavailable".

[0044] Version drift can occur with dual-side configuration deployment. If the spatiotemporal configuration and the business configuration are not activated with the same skill_id and version, it is possible that one side has been upgraded while the other side is still using the old version.

[0045] Insufficient isolation granularity when multiple scenarios coexist. A configuration error in one scenario may affect other scenario tasks in the same cluster, and there is a lack of a unified mechanism for loading, denying service, rolling back, and tracing by skill_id / version.

[0046] Simply externalizing the threshold parameters cannot prevent the data preparation code and large-scale model inference code from being repeatedly modified as the scenario changes. Similarly, simply introducing a rule engine or workflow engine cannot solve the problem of consistency in fields, objects, tools, and versions between the spatiotemporal data preparation side and the large-scale model inference side. In spatiotemporal cognitive task pipelines facing multiple physical space scenarios, a pressing issue is how to first abstract business and spatiotemporal differences into configurable assets, and then explicitly express and perform closure checks on the field, indicator, tag, object, and interface dependencies between the business side and the spatiotemporal side through a cross-execution entity reference graph. This would allow for secure deployment, stable operation, and traceable management of new scenario access, scenario upgrades, and multi-scenario coexistence without modifying the core code of the two types of execution entities.

[0047] This application provides a skill publishing method, apparatus, and electronic device based on configuration data to solve the problem of low efficiency when analyzing the physical space of different scenarios.

[0048] See Figure 1 , Figure 1This is a flowchart of a skill publishing method based on configuration data provided in an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0049] Step 101: Obtain configuration data and shared assets corresponding to the first skill. The configuration data includes a spatiotemporal sub-package and a business sub-package. The spatiotemporal sub-package is used to represent the spatiotemporal data of the spatial cognition task corresponding to the first skill. The business sub-package is used to represent the reasoning logic of the spatial cognition task. The spatiotemporal sub-package and the business sub-package are executed by the first executor and the second executor, respectively.

[0050] Step 102: Obtain the reference information of the business-side sub-package to at least one of the spatiotemporal-side sub-package and the shared asset, and construct a reference graph based on the reference information. The reference graph is used to characterize the dependency relationship of the business-side sub-package to at least one of the spatiotemporal-side sub-package and the shared asset.

[0051] Step 103: Perform a first verification on the referenced image to obtain the first verification result;

[0052] Step 104: If the first skill meets the release conditions based on the first verification result, execute the release operation of the first skill.

[0053] Among them, "skill" can be understood as a spatial cognitive task configuration unit that can be independently published, loaded, rolled back, and traced. It can be understood as "skill" or "task ability". The first skill can be any skill.

[0054] Each spatial cognitive task is identified by a `skill_id` and a `version`, and contains a spatiotemporal subpackage and a business subpackage. The spatiotemporal subpackage describes the spatial base reference, object type, field mapping, derived metrics, cognitive tags, spatial constraint rules, output contracts, etc.; the business subpackage describes business objects, business plugin configurations, inference orchestration templates, prompt word templates, tool call constraints, and output formats, etc. Each skill version includes a top-level manifest, which declares the subpackage path, version number, dependent shared assets, minimum executable version, input / output contracts, and compatibility scope. Shared assets may include the spatial base, business plugins, knowledge bases, glossaries, or industry standards, and are described in separate manifests.

[0055] The first skill can include the following structure in the configuration repository:

[0056] ```text

[0057] skills / {skill_id} / {version} /

[0058] manifest.yaml

[0059] spatial.yaml

[0060] business.yaml

[0061] replay_cases /

[0062] expected_outputs /

[0063] ```

[0064] The manifest.yaml file is the manifest configuration file, used to describe the global metadata of this skill version (i.e., the first skill), including skill_id, version, applicable scenario type, subpackage summary, dependent shared assets, minimum executable version, input / output contract, compatibility scope, release strategy, and rollback strategy. Shared assets are objects that the manifest configuration file declares as dependent on. Shared assets can be stored independently in directories such as space_bases, business_plugins, and knowledge_bases, and their version, summary, compatibility scope, and permissions are declared through the manifest. The top-level skill manifest references shared assets through the dependencies field and declares the minimum version requirements for the two types of executables and interface versions through the compatibility field.

[0065] spatial.yaml is a spatiotemporal subpackage that can include spatiotemporal data for the spatial cognition task corresponding to the first skill, such as: spatial base reference, data source mapping, object type, object hierarchy, original field registry, derived indicator definition, cognitive label rules, spatial constraint rules, data availability rules, external data mount point, output contract, and a list of fields that can be referenced by the business side.

[0066] The business.yaml file is a business-side subpackage that may include inference logic information representing the spatial cognition task, such as: business object registry, business plugin configuration, business indicator definition, inference orchestration template, prompt word template, tool call declaration, scheduling suggestion rules, result format, inference chain traceability strategy, and reference declarations to spatiotemporal fields or interfaces.

[0067] "manifest.yaml" refers to the manifest configuration file, used to declare the basic information, version, sub-package summary, dependent assets, compatibility requirements, release strategy, and rollback strategy of the Skill; "spatial.yaml" refers to the spatiotemporal configuration sub-package, for consumption by the spatiotemporal cognitive data preparation execution unit; "business.yaml" refers to the business configuration sub-package, for consumption by the large language model inference execution unit; where "yaml" is a structured configuration file format. "replay_cases" refers to the set of test samples, historical samples, or synthetic samples used for sandbox replay; "expected_outputs" refers to the expected outputs, benchmark results, or validation benchmarks corresponding to the replay samples, used to determine whether the replay results meet expectations. "dependencies" refers to dependency declarations; "compatibility" refers to compatibility declarations. The dual-sub-package asset model is as follows: Figure 3 As shown.

[0068] In some implementations, such as Figure 2 As shown, the system includes a scenario business configuration layer (including configuration repository, release service, sandbox playback service, etc.), a spatiotemporal cognitive data preparation execution body, and a large language model inference execution body.

[0069] The spatiotemporal cognitive data preparation execution unit, also known as the first execution unit, can be used to consume spatiotemporal side sub-packages. During runtime, it does not determine whether the current location is a subway station, park, or exhibition center; instead, it reads the activated skill_id / version and, based on the configuration, performs data access mapping, spatial object assembly, derived indicator calculation, cognitive tag generation, spatial constraint verification, and spatiotemporal context output. The "skill_id" refers to the unique identifier of a skill, i.e., a "skill identifier" or "task configuration identifier"; "version" refers to the configuration version number. Therefore, "skill_id / version" represents a specific configuration version under a specific skill identifier.

[0070] The large language model inference executor, also known as the second executor, is responsible for consuming business-side sub-packages. At runtime, it does not have built-in specific scenario prompts or business processes. Instead, it reads the activated skill_id / version, assembles business plugins according to the configuration, selects inference orchestration templates, renders prompts, calls the spatiotemporal context query interface or spatial constraint verification interface, and generates structured inference results.

[0071] The source code of neither type of executor contains object names, indicator formulas, thresholds, prompt text, or business orchestration paths specific to the spatial scenario. The two types of executors can interact via standard interfaces. For example, the inference executor can call the context-query interface of the spatiotemporal cognitive data preparation executor to obtain the context, and call the spatial-validate interface to verify whether candidate scheduling schemes meet spatial constraints. The fields, types, and callable scope of the interfaces are jointly defined by the output contract and reference graph of the configured assets. "context-query" refers to the context query interface; "spatial-validate" refers to the spatial constraint verification interface.

[0072] Before submission or release, the configuration layer parses the prompt words, orchestration nodes, plugin input parameters, tool call configurations, and output formats in the business-side subpackage `business.yaml`, extracting references to the spatiotemporal subpackage `spatial.yaml` or shared assets to form a cross-executor reference graph. The source nodes of the reference graph can be prompt words, orchestration nodes, plugin input parameters, or tool call configurations, while the target nodes can be fields, metrics, tags, object types, or API contracts in the spatiotemporal subpackage. The main difference between this reference graph and ordinary configuration centers and ordinary workflow engines is that ordinary configuration centers typically only verify the existence or correct format of a single configuration item, while this application uses a reference graph to describe the input-output dependencies between two different execute entities.

[0073] Reference graphs support at least the following node types:

[0074] 1. Spatiotemporal nodes: spatial objects, original fields, derived indicators, cognitive tags, spatial constraint rules, context output fields, and interface contracts.

[0075] 2. Business-side nodes: prompt word variables, input arrangement, plugin input parameters, tool call input parameters, and result fields.

[0076] 3. Shared asset nodes: spatial base, knowledge base, business plugins, glossary or evaluation criteria.

[0077] In some implementations, data such as template variables, orchestration nodes, plugin input parameters, and tool call input parameters in the business-side sub-package are scanned. The data in the business-side sub-package is standardized and unified with the data in the spatiotemporal sub-package. Then, candidate targets are searched from the spatiotemporal sub-package and the shared asset list to determine the dependency relationship between the business-side sub-package and the referenced object based on the candidate targets, thus forming a reference graph.

[0078] In some implementations, reference information is extracted from the business-side sub-packages, and the referenced objects are determined according to the pre-defined reference and referenced relationships, thereby determining the dependency relationships between different objects and forming a reference graph.

[0079] During verification, manifest.yaml, spatial.yaml, and business.yaml under the same skill_id / version are read, and the reference graph is verified based on the above information.

[0080] For example, verifying the format of the configuration file, the accuracy of the referenced targets, and file compatibility.

[0081] The following example illustrates this concept.

[0082] Example 1: Access to New Scenarios During Morning Rush Hour at Subway Stations

[0083] Taking a subway station's morning rush hour congestion analysis scenario as an example, the configuration personnel create a new skill version v1.0.0 with the skill_id metro_morning_crowd in the configuration console.

[0084] In spatial.yaml, personnel declare spatial objects such as station hall, platform, turnstile, passage, escalator, etc., configure data source mapping such as passenger flow, equipment status, transfer direction, define derived indicators such as passenger flow density per unit area, turnstile throughput, passage congestion index, define cognitive labels such as "mild congestion" and "severe congestion", and declare platform capacity, passage accessibility and evacuation direction constraints.

[0085] In business.yaml, the configuration personnel declare the reasoning and arrangement of the morning peak situation summary, congestion cause explanation, and scheduling suggestion generation, configure the prompt word template variable to reference the above indicators and labels, and declare that the space constraint verification interface needs to be called to verify the candidate diversion scheme.

[0086] The configuration layer constructs a cross-execution reference graph and completes closure verification, then uses historical morning peak samples to perform sandbox replay. After successful replay, the release service loads the spatiotemporal sub-package into the spatiotemporal cognitive data preparation execution body and the business sub-package into the large language model inference execution body, and activates it after both sides report that the skill_id / version is consistent.

[0087] During this process, both types of executors used the original binary and general parsing execution logic, without modifying the code for subway station objects, indicator formulas, label rules, or prompt word templates. New scenario differences were expressed through asset configuration via a dual-package architecture and interpreted and executed by the same set of executors.

[0088] If the verification is successful based on the first verification result, meaning the release conditions are met, then the first skill is released.

[0089] In this embodiment, a reference graph is constructed based on the configuration data and shared assets corresponding to the first skill, and the first skill is released after the reference graph passes verification. When performing physical space analysis for multiple scenarios, there is no need to modify the source code of the two types of executors. Different scenarios can be adapted by adding or adjusting configuration data, and the first skill can be used to perform physical space analysis based on existing configuration data in any scenario, thereby improving the efficiency of physical space analysis.

[0090] Optionally, obtaining reference information of the service-side sub-package to at least one of the spatiotemporal-side sub-package and the shared asset, and constructing a reference graph based on the reference information, includes:

[0091] Parse the business-side sub-package to obtain the reference information of the business-side sub-package to the spatiotemporal-side sub-package and the shared asset. The reference information includes the reference position of the business-side sub-package and the referenced object in the spatiotemporal-side sub-package.

[0092] The information in the business-side sub-package and the spatiotemporal-side sub-package is processed according to the same first rule;

[0093] Based on the shared assets and the reference information, as well as the processed business-side sub-packages and spatiotemporal-side sub-packages, a reference graph is constructed.

[0094] The process parses the business-side subpackages, scanning for template variables, orchestration nodes, plugin input parameters, and tool call input parameters. It then processes the declared field names, metric names, tag names, object identifiers, interface names, or output contract names in the business-side subpackages, along with information from the spatiotemporal subpackages, according to a first rule. This first rule can be a pre-defined rule. By uniformly processing the business-side and spatiotemporal subpackages using the first rule, the information in both subpackages is standardized into a unified reference identifier.

[0095] Subsequently, candidate targets are searched in the spatiotemporal sub-package and the shared asset list. A reference graph is formed based on the candidate targets, and the reference path, configuration file location, and version information are saved.

[0096] The reference graph can be represented as a set of triples: source, target, and constraint. `source` represents the business-side reference location, such as `prompt_templates.crowd_summary.variables.avg_density`; `target` represents the spatiotemporal referenced object, such as `spatial.metrics.avg_density`; and `constraint` represents the type, unit, temporal granularity, spatial granularity, whether it is required, default value, and permission requirements. "Source, target, and constraint" are used to describe the reference initiation location, referenced target, and reference constraint in the cross-executor reference graph.

[0097] The execution reference diagram can be found here. Figure 4 As shown.

[0098] Based on the reference graph, cross-execution dependencies implicit in prompts, plugin configurations, and orchestration templates can be made explicit, enabling machine verification, sandbox replay, and runtime traceability. Without building this reference graph, whether fields referenced in business-side prompts or plugin configurations are actually generated by the spatiotemporal side can only be discovered after a runtime request failure, making it impossible to prevent misconfigurations before release.

[0099] Optionally, performing a first verification on the referenced image to obtain a first verification result includes:

[0100] Perform at least one of the following first checks on the referenced graph to obtain the first check result:

[0101] The format rule items in the configuration data associated with the referenced graph are validated;

[0102] Verify the existence of the referenced targets in the reference graph;

[0103] Based on the reference graph, the compatibility between the business-side sub-package and the reference target is verified;

[0104] Based on the reference diagram, the versions of the first skill and the shared asset are verified;

[0105] Based on the reference graph, the exposure range of the referenced target is verified.

[0106] like Figure 5 As shown, before release, the configuration layer performs existence, type, version, permission, output contract and circular dependency checks on the reference graph. Only skill_id / version that passes all checks can enter the release-ready state.

[0107] The configuration data associated with the reference diagram may include spatiotemporal sub-packages, business sub-packages, and shared assets. The schema can be used to verify whether the syntax, required fields, enumerated values, and version format of each configuration file meet the requirements. "Schema" refers to configuration structure constraints or configuration format specifications.

[0108] Perform an existence check on each reference in the reference graph to confirm that the target field, metric, tag, object, or interface exists in the spatiotemporal subpackage or shared assets.

[0109] Perform type and unit validation to confirm that the data type, unit, time granularity, and spatial granularity required by the referrer (business-side sub-package) are compatible with the referenced target (spatiotemporal-side sub-package, shared assets).

[0110] Perform version and compatibility checks to confirm that the versions of skill, shared assets, and the two types of execution bodies (the first execution body corresponding to the space-time side subpackage and the second execution body corresponding to the business side subpackage) meet the manifest declaration.

[0111] Execution permissions and the scope of exposure of referenced targets are validated. For example, the business-side subpackage can only reference fields and interfaces that are allowed to be exposed by the spatiotemporal subpackage output contract.

[0112] Generate a verification report based on the first verification result, recording the passed items, failed items, reference paths, reasons for failure, and repair suggestions.

[0113] The output of the closure check includes: the set of successful references, the set of failed references, the failure type, the location of the failure configuration, candidate referenced targets, and repair suggestions. Failure types may include target non-existence, target not exposed in the output contract, type incompatibility, unit incompatibility, time granularity incompatibility, space granularity incompatibility, version incompatibility, insufficient permissions, or circular dependencies, etc.

[0114] If any required reference is not closed, the skill_id / version will not be allowed to enter the release phase. For non-required references, the default value can be used according to the configuration declaration, the variable can be ignored, or it can be transferred to manual review, but the result of this processing still needs to be written into the verification report.

[0115] The above verification can improve the accuracy of the referenced diagrams.

[0116] Optionally, after performing a first verification on the referenced graph and obtaining a first verification result, the method further includes:

[0117] Load the configuration data corresponding to the first skill and the shared assets into the sandbox;

[0118] The second verification result is obtained by performing a second verification on the first skill based on the replay sample. The second verification is used to verify at least one of the following: whether the data mapping between the spatiotemporal sub-package and the business sub-package is successful, whether the derived indicators can be calculated, whether the output contract satisfies the business side reference, whether the prompt word variable can be rendered, whether the spatial constraint tool can be called, and whether the inference result satisfies the output format.

[0119] The step of performing the release operation of the first skill when it is determined from the first verification result that the first skill meets the release conditions includes:

[0120] If the first skill meets the release conditions based on the first verification result and the second verification result, the release operation of the first skill is executed.

[0121] like Figure 5 As shown, after the reference graph verification passes, the sandbox replay service loads the twin packages and shared assets with the same skill_id / version (i.e., the first skill), and performs replay using the sandbox interface consistent with the production interface contract. The sandbox interface may include / sandbox / spatial / context-query, / sandbox / spatial / validate, and / sandbox / collab / reason. This step is an auxiliary verification mechanism before release, used to supplement link-related issues that are difficult to cover by checking the reference graph and closure verification.

[0122] By using replay samples to perform data preparation, context output, prompt word rendering, tool calls, and inference result verification for the first skill, cross-executor collaboration defects can be discovered before release.

[0123] The replay samples can be historical running samples, manually labeled samples, synthetic boundary samples, or regression test samples. Sandbox replay must at least cover: whether the spatiotemporal data mapping was successful, whether the derived indicators are calculable, whether the output contract satisfies business-side references, whether all prompt word variables are renderable, whether the spatial constraint tools are callable, and whether the inference results meet the structured output format. The replay results and verification report will serve as the basis for release approval.

[0124] Optionally, the execution of the first skill publishing operation includes:

[0125] The first executor loads the spatiotemporal sub-package, and the second executor loads the service sub-package.

[0126] The first skill is released when both the spatiotemporal sub-package and the business sub-package are successfully loaded and meet the compatibility requirements.

[0127] like Figure 6 As shown, the publishing service can use dual-channel publishing for both the spatiotemporal sub-package and the business sub-package.

[0128] The publishing service distributes corresponding sub-packages to the spatiotemporal cognitive data preparation execution unit (i.e., the first execution unit) and the large language model inference execution unit (i.e., the second execution unit), respectively. It first enters the load_only or staging state. After both sides have successfully loaded and reported the same skill_id / version, it then executes the switch to activate. The publishing record saves the publish_id, idempotent key, target instance, loading status, activation status, and rollback window.

[0129] Specifically, the first phase is the loading phase: the publishing service sends a load_only (indicating loading only, not active) or staging (indicating preparation or grayscale state) request to both the spatiotemporal cognitive data preparation execution entity (i.e., the first execution entity) and the large language model inference execution entity (i.e., the second execution entity). The request carries the publish_id (indicating the publishing transaction identifier), skill_id, version, sub-package summary, and idempotent key. After loading, the execution entity returns the loading result and the local summary.

[0130] The second phase is the switching phase: Once the published service confirms that both sides have loaded successfully and meet compatibility requirements (such as consistent digest and version), a switch request (indicating switching to the production service version) is sent to both sides, making the same skill_id / version a serviceable version simultaneously. If loading fails on either side, neither side switches, and the publication record is marked as failed.

[0131] like Figure 7 As shown, during runtime, the request routing layer or caller carries the skill_id / version. Both types of executors compare the requested version with the locally activated version before processing the request. If a missing, expired, inconsistent digest, or isolated state is found, the request for that skill is rejected according to a preset strategy, a rollback to the previous stable version is initiated, or an automatic rollback is triggered, and the exception is written to the release log and traceability log. This consistency fallback mechanism operates on a skill_id / version basis and does not block requests for other activated skills, thus ensuring runtime security.

[0132] The system generates a trace_id (representing the request tracing identifier) ​​for each spatial cognition task request and records the following information: the request's skill_id / version, summaries of two types of sub-packages, shared asset version, reference graph version, closure verification report number, sandbox replay report number, release record number, spatiotemporal context output fields, prompt word template version, tool call input and output parameters, model response summary, and the final structured result. Traceability information is primarily used for locating misconfigurations and replay analysis, serving as an auxiliary management tool.

[0133] When inference results are abnormal, fields are missing, or tool calls fail, the specific configuration version, reference path, and execution instance can be located using the trace_id. Trace information can also be used to replay historical requests, compare the effects of different skill versions, generate audit reports, and support rollback decisions.

[0134] Optionally, the first executor is used to output a spatiotemporal context based on the spatiotemporal side sub-package;

[0135] The second executor is used to generate structured reasoning results based on the business-side subpackage, the reasoning arrangement template, and the rendering prompts, by calling the query interface corresponding to the spatiotemporal context.

[0136] The scenario independence between the first and second executors can be achieved in the following way.

[0137] Spatiotemporal cognitive data preparation execution body (i.e., the first execution body):

[0138] 1. Generic configuration loader: Loads only the space-time sub-package and dependent assets (i.e., shared assets) based on skill_id / version, without determining the specific scene name in the code branches.

[0139] 2. Generic Object Assembler: Generates an object graph based on space base references, object types, hierarchical relationships, and data source mappings in the configuration.

[0140] 3. General Metrics Calculator: Calculates derived metrics based on field expressions, window granularity, aggregation functions, and dependencies in the configuration, rather than hardcoding formulas in the code.

[0141] 4. Generic Tag Generator: Generates cognitive tags based on the rule expressions, thresholds, priorities, and output contracts configured in the settings.

[0142] 5. General Constraint Verifier: Performs deterministic verification on candidate solutions based on declarative rules such as capacity, connectivity, mutual exclusion, reachability, or business restrictions in the configuration.

[0143] 6. General Context Outputter: Select fields, labels, objects, and time windows according to the output contract to output a structured spatiotemporal context.

[0144] Large language model inference executor (i.e., second executor):

[0145] 1. General Business Configuration Loader: Loads business-side sub-packages and dependent assets only based on skill_id / version.

[0146] 2. General Plugin Assembler: Assembles plugins based on the plugin ID, version, input parameter mapping, and permission scope declared in the business-side subpackage.

[0147] 3. General orchestration executor: Performs steps such as "getting context - rendering prompts - calling the model - calling tools - generating results" based on the inference orchestration template.

[0148] 4. General tooltip renderer: Based on the binding relationship between template variables and reference graph, it retrieves values ​​from the spatiotemporal context or plugin output and renders tooltips.

[0149] 5. General Tool Invoker: Invokes the space-time interface based on the tool name, input contract, output contract, and invocation constraints declared in the configuration.

[0150] 6. General Result Formatter: Generates structured conclusions based on the output format configuration.

[0151] The execution entity retains general capabilities such as parsing, calculation, scheduling, rendering, and verification; objects, fields, formulas, rules, templates, and orchestration for specific scenarios are all provided by the configuration assets. The term "scenario-independent" in this article means that the same general parser, calculator, renderer, or validator can handle spatial identifiers, field mappings, indicator formulas, label rules, prompt word variables, and interface references in different scenarios without modifying the code; when only the configuration assets are changed, the execution entity can still complete parsing, calculation, rendering, and verification according to the same program flow.

[0152] In this way, the spatial cognition task pipeline is abstracted into a collaborative model of "configuration assets - data preparation execution body - inference execution body": the spatiotemporal cognition data preparation execution body (i.e., the first execution body) only interprets the spatiotemporal configuration and produces the standard spatiotemporal context; the large language model inference execution body (i.e., the second execution body) only interprets the business configuration and performs inference orchestration; the two sub-packages are bound through the same skill_id / version, and the business side's dependency on the sub-package fields, indicators, tags, spatial objects and validation interfaces is described through an explicit reference graph.

[0153] The spatiotemporal cognitive data preparation execution unit (i.e., the first execution unit) is responsible for consuming the spatiotemporal side sub-package. Based on the configuration, it performs data access mapping, spatial object assembly, derived index calculation, cognitive tag generation, spatial constraint verification, and spatiotemporal context output.

[0154] The large language model inference executor (i.e., the second executor) is responsible for consuming the business-side sub-packages. It assembles business plugins according to the configuration, selects inference orchestration templates, renders prompts, calls the spatiotemporal context query interface or spatial constraint verification interface, and generates structured inference results.

[0155] As a specific implementation example, the overall system architecture is as follows: Figure 2 As shown. The scenario business configuration layer is responsible for generating, managing, and publishing skill configuration assets, and prioritizes the construction and closure verification of cross-execution reference graphs. It may include a configuration console, configuration repository, schema validator, reference graph builder, dependency resolver, release controller, and version manager; among them, the sandbox orchestrator, dual-channel activator, and tracer can be configured as supporting modules in the same layer. The configuration console provides a metrics studio, rule lab, business object editor, plugin configurator, inference template editor, prompt word editor, sandbox replay panel, and release approval panel. Based on the above architecture, various implementation methods of this application are implemented.

[0156] The following examples illustrate the solution of this application.

[0157] Example 2: Version Upgrade of an Existing Deployed Scenario

[0158] Taking the upgrade of the already deployed convention and exhibition venue congestion analysis skill v1.0.0 to v1.1.0 as an example, the new version adds a derived metric of "entrance queue length prediction" and references this metric in the business-side prompts.

[0159] In the configuration layer, the derived metric and output contract were added to spatial.yaml in v1.1.0, and prompt word variables and orchestration nodes were added to business.yaml. Upon submission, the reference graph builder detects the new reference on the business side, and the closure validator checks whether the metric exists, whether its type is numerical, whether the unit is human or meter, whether the time granularity meets the prediction window, and whether it is exposed in the output contract. After successful validation, the sandbox replay service performs replay using historical exhibition samples.

[0160] During the release phase, v1.1.0 is first loaded into two types of execution bodies in a staging state. Canary release requests are only routed to v1.1.0, while regular requests still use v1.0.0. If the canary release observation is successful, the release service executes a switch statement; if it fails, the activation candidate status of v1.1.0 is revoked, and production remains on v1.0.0.

[0161] Example 3: Emergency Rollback - Version Drift Window is 0

[0162] After activating the analytics skill v2.0.0 in a certain industrial park, the trace logs showed that the input parameters of its business-side plugins caused some results to have abnormal formats. The publishing service queries the previous stable version v1.9.3 based on `publish_records` and sends rollback requests to both types of executables simultaneously. The service version is only switched when both types of executables confirm that v1.9.3 has been loaded and the digests are consistent.

[0163] If an executor fails to confirm the rollback version, the routing layer suspends new requests for that skill to prevent version drift where the spacetime side has rolled back but the business side has not. Requests for other skills are unaffected.

[0164] Example 4: Network jitter during release → Denial of service at skill_id granularity → Automatic recovery

[0165] During the release of Skill v3.2.0 at a transportation hub, the spatiotemporal execution unit loaded successfully, but the business-side execution unit did not receive the switch request due to network jitter. Upon receiving a request carrying the skill_id and version, the runtime routing layer discovered that the active versions on both sides were inconsistent. Therefore, it rejected the new request based on the skill_id / version or continued routing to the previous stable version, and recorded the version drift event.

[0166] The published service retryes the business-side switch request based on the idempotent key. After the business-side execution completes the switch and reports a summary consistent with the spatiotemporal side, the routing layer removes the isolation state of that skill. During this process, requests for other skills can still be processed normally by the same cluster.

[0167] Example 5: Independent Evolution of Scenes in a Multi-Scenario Coexistence Cluster

[0168] A set of spatiotemporal cognitive data preparation execution units and large language model inference execution units can simultaneously load multiple skills such as subway stations, convention and exhibition venues, parks, and scenic spots. Each skill is managed with an independent skill_id / version, bi-package summary, reference graph, sandbox report, and release record.

[0169] When a scenic area skill upgrades its spatial constraint rules, only the scenic area skill's bipartite package and reference graph change. The service deployment only performs loading, canary deployment, and switching on that specific skill; the versions and request routes of skills in subway stations, convention centers, and industrial parks remain unaffected. If the new version for a scenic area fails, only that skill is rolled back, without impacting other scenarios within the same cluster.

[0170] This application has the following beneficial effects:

[0171] 1. Reduce the need to modify the executable code when adding new scenes. Adding new scenes is mainly accomplished by adding skill versions and their twin packages; the executable still uses the general parser, calculator, renderer, and scheduler.

[0172] 2. Improve consistency in cross-execution collaboration. Business-side references to sub-package fields, metrics, tags, spatial objects, and tool interfaces are explicitly modeled and validated before release, reducing runtime field omissions and type mismatches.

[0173] 3. Improve release security. The twin packages undergo static validation and sandbox playback before production release, reducing the probability of misconfigurations directly entering the production environment.

[0174] 4. Reduce version drift risk. Spatiotemporal sub-packages and business sub-packages are loaded and activated with the same skill_id / version, and consistency is continuously verified at runtime.

[0175] 5. Improve multi-scenario coexistence capability. Different skills can be loaded, upgraded, canary-scaled, rolled back, and traced independently within the same execution cluster, and abnormal configurations in one scenario do not need to affect other scenarios.

[0176] See Figure 8 , Figure 8 This is a schematic diagram of the structure of a skill publishing device based on configuration data provided in an embodiment of this application, such as... Figure 8 As shown, the skill publishing device 800 based on configuration data includes:

[0177] The first acquisition module 801 is used to acquire configuration data and shared assets corresponding to the first skill. The configuration data includes a spatiotemporal sub-package and a business sub-package. The spatiotemporal sub-package is used to represent the spatiotemporal data of the spatial cognition task corresponding to the first skill. The business sub-package is used to represent the reasoning logic of the spatial cognition task. The spatiotemporal sub-package and the business sub-package are executed by the first executor and the second executor, respectively.

[0178] The second acquisition module 802 is used to acquire reference information of the business-side sub-package to at least one of the spatiotemporal-side sub-package and the shared asset, and construct a reference graph based on the reference information. The reference graph is used to characterize the dependency relationship of the business-side sub-package to at least one of the spatiotemporal-side sub-package and the shared asset.

[0179] The first verification module 803 is used to perform a first verification on the reference diagram and obtain a first verification result.

[0180] The publishing module 804 is used to perform the publishing operation of the first skill when it is determined from the first verification result that the first skill meets the publishing conditions.

[0181] Optionally, the second acquisition module includes:

[0182] The parsing submodule is used to parse the business-side subpackage and obtain the reference information of the business-side subpackage to the spatiotemporal-side subpackage and the shared asset. The reference information includes the reference position of the business-side subpackage and the referenced object in the spatiotemporal-side subpackage.

[0183] The processing submodule is used to process the information in the service-side sub-package and the spatiotemporal-side sub-package according to the same first rule;

[0184] A submodule is constructed to build a reference graph based on the shared assets and the reference information, as well as the processed business-side subpackage and spatiotemporal-side subpackage.

[0185] Optionally, the first verification module is specifically used for:

[0186] Perform at least one of the following first checks on the referenced graph to obtain the first check result:

[0187] The format rule items in the configuration data associated with the referenced graph are validated;

[0188] Verify the existence of the referenced targets in the reference graph;

[0189] Based on the reference graph, the compatibility between the business-side sub-package and the reference target is verified;

[0190] Based on the reference diagram, the versions of the first skill and the shared asset are verified;

[0191] Based on the reference graph, the exposure range of the referenced target is verified.

[0192] Optionally, the device further includes:

[0193] The first loading module is used to load the configuration data corresponding to the first skill and the shared assets in the sandbox;

[0194] The second verification module is used to perform a second verification on the first skill based on the replay sample to obtain a second verification result. The second verification is used to verify at least one of the following: whether the data mapping between the spatiotemporal sub-package and the business sub-package is successful, whether the derived indicators are calculable, whether the output contract satisfies the business side reference, whether the prompt word variable is renderable, whether the spatial constraint tool is callable, and whether the inference result satisfies the output format.

[0195] The publishing module is specifically used for:

[0196] If the first skill meets the release conditions based on the first verification result and the second verification result, the release operation of the first skill is executed.

[0197] Optionally, the publishing module includes:

[0198] A loading submodule is used to load the spatiotemporal side subpackage using the first executor and to load the service side subpackage using the second executor.

[0199] The publishing submodule is used to publish the first skill when both the spatiotemporal side subpackage and the business side subpackage are successfully loaded and the spatiotemporal side subpackage and the business side subpackage meet the compatibility requirements.

[0200] Optionally, the first executor is used to output a spatiotemporal context based on the spatiotemporal side sub-package;

[0201] The second executor is used to generate structured reasoning results based on the business-side subpackage, the reasoning arrangement template, and the rendering prompts, by calling the query interface corresponding to the spatiotemporal context.

[0202] It should be noted that the skill publishing device based on configuration data provided in this application embodiment is a device capable of executing the above-described skill publishing method based on configuration data. Therefore, all implementation methods in the above-described skill publishing method embodiments based on configuration data are applicable to this device and can achieve the same or similar beneficial effects. To avoid repetition, this embodiment will not elaborate further.

[0203] See Figure 9 As shown in the figure, this application embodiment also provides an electronic device, including a bus 601, a transceiver 602, an antenna 603, a bus interface 604, a processor 605, and a memory 606.

[0204] Processor 605, used for:

[0205] Acquire configuration data and shared assets corresponding to the first skill. The configuration data includes a spatiotemporal sub-package and a business sub-package. The spatiotemporal sub-package is used to represent the spatiotemporal data of the spatial cognition task corresponding to the first skill. The business sub-package is used to represent the reasoning logic of the spatial cognition task. The spatiotemporal sub-package and the business sub-package are executed by a first executor and a second executor, respectively.

[0206] Obtain reference information of the business-side subpackage to at least one of the spatiotemporal-side subpackage and the shared asset, and construct a reference graph based on the reference information. The reference graph is used to characterize the dependency relationship of the business-side subpackage to at least one of the spatiotemporal-side subpackage and the shared asset.

[0207] The referenced image is subjected to a first verification, and a first verification result is obtained;

[0208] If the first skill meets the release conditions based on the first verification result, the release operation of the first skill is executed.

[0209] exist Figure 9 In this document, a bus architecture (represented by bus 601) is used. Bus 601 may include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 605 and memory represented by memory 606. Bus 601 may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 604 provides an interface between bus 601 and transceiver 602. Transceiver 602 may be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 605 is transmitted over a wireless medium via antenna 603, which further receives data and transmits data to processor 605.

[0210] Processor 605 manages bus 601 and general processing, and also provides various functions, including timing, peripheral interface, voltage regulation, power management, and other control functions. Memory 606 can be used to store data used by processor 605 during operation.

[0211] Alternatively, the processor 605 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a complex programmable logic device (CPLD).

[0212] Optionally, the processor 605 performs the step of obtaining reference information of the service-side sub-package to at least one of the spatiotemporal-side sub-package and the shared asset, and constructing a reference graph based on the reference information, including:

[0213] Parse the business-side sub-package to obtain the reference information of the business-side sub-package to the spatiotemporal-side sub-package and the shared asset. The reference information includes the reference position of the business-side sub-package and the referenced object in the spatiotemporal-side sub-package.

[0214] The information in the business-side sub-package and the spatiotemporal-side sub-package is processed according to the same first rule;

[0215] Based on the shared assets and the reference information, as well as the processed business-side sub-packages and spatiotemporal-side sub-packages, a reference graph is constructed.

[0216] Optionally, the processor 605 performs the first verification on the reference graph to obtain a first verification result, including:

[0217] Perform at least one of the following first checks on the referenced graph to obtain the first check result:

[0218] The format rule items in the configuration data associated with the referenced graph are validated;

[0219] Verify the existence of the referenced targets in the reference graph;

[0220] Based on the reference graph, the compatibility between the business-side sub-package and the reference target is verified;

[0221] Based on the reference diagram, the versions of the first skill and the shared asset are verified;

[0222] Based on the reference graph, the exposure range of the referenced target is verified.

[0223] Optionally, the processor 605 is also used to perform:

[0224] Load the configuration data corresponding to the first skill and the shared assets into the sandbox;

[0225] The second verification result is obtained by performing a second verification on the first skill based on the replay sample. The second verification is used to verify at least one of the following: whether the data mapping between the spatiotemporal sub-package and the business sub-package is successful, whether the derived indicators can be calculated, whether the output contract satisfies the business side reference, whether the prompt word variable can be rendered, whether the spatial constraint tool can be called, and whether the inference result satisfies the output format.

[0226] The processor 605 performs the following: If, based on the first verification result, it is determined that the first skill meets the release conditions, the processor performs the release operation for the first skill, including:

[0227] If the first skill meets the release conditions based on the first verification result and the second verification result, the release operation of the first skill is executed.

[0228] Optionally, the processor 605 performs the publishing operation of the first skill, including:

[0229] The first executor loads the spatiotemporal sub-package, and the second executor loads the service sub-package.

[0230] The first skill is released when both the spatiotemporal sub-package and the business sub-package are successfully loaded and meet the compatibility requirements.

[0231] Optionally, the first executor is used to output a spatiotemporal context based on the spatiotemporal side sub-package;

[0232] The second executor is used to generate structured reasoning results based on the business-side subpackage, the reasoning arrangement template, and the rendering prompts, by calling the query interface corresponding to the spatiotemporal context.

[0233] It should be noted that the electronic device provided in this application embodiment is a device capable of executing the above-described skill release method based on configuration data. Therefore, all implementation methods in the above-described skill release method embodiments based on configuration data are applicable to this electronic device and can achieve the same or similar beneficial effects. To avoid repetition, this embodiment will not elaborate further.

[0234] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the above-described method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0235] This application also provides a computer program product, including computer instructions, which, when executed by a processor, implement the above-described... Figure 1 The various processes of the method embodiments shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0236] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0237] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0238] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A skill publishing method based on configuration data, characterized in that, include: Acquire configuration data and shared assets corresponding to the first skill. The configuration data includes a spatiotemporal sub-package and a business sub-package. The spatiotemporal sub-package is used to represent the spatiotemporal data of the spatial cognition task corresponding to the first skill. The business sub-package is used to represent the reasoning logic of the spatial cognition task. The spatiotemporal sub-package and the business sub-package are executed by a first executor and a second executor, respectively. Obtain reference information of the business-side subpackage to at least one of the spatiotemporal-side subpackage and the shared asset, and construct a reference graph based on the reference information. The reference graph is used to characterize the dependency relationship of the business-side subpackage to at least one of the spatiotemporal-side subpackage and the shared asset. The referenced image is subjected to a first verification, and a first verification result is obtained; If the first skill meets the release conditions based on the first verification result, the release operation of the first skill is executed.

2. The method according to claim 1, characterized in that, The step of obtaining reference information of the business-side sub-package to at least one of the spatiotemporal-side sub-package and the shared asset, and constructing a reference graph based on the reference information, includes: Parse the business-side sub-package to obtain the reference information of the business-side sub-package to the spatiotemporal-side sub-package and the shared asset. The reference information includes the reference position of the business-side sub-package and the referenced object in the spatiotemporal-side sub-package. The information in the business-side sub-package and the spatiotemporal-side sub-package is processed according to the same first rule; Based on the shared assets and the reference information, as well as the processed business-side sub-packages and spatiotemporal-side sub-packages, a reference graph is constructed.

3. The method according to claim 1 or 2, characterized in that, The first verification of the referenced image to obtain the first verification result includes: Perform at least one of the following first checks on the referenced graph to obtain the first check result: The format rule items in the configuration data associated with the referenced graph are validated; Verify the existence of the referenced targets in the reference graph; Based on the reference graph, the compatibility between the business-side sub-package and the reference target is verified; Based on the reference diagram, the versions of the first skill and the shared asset are verified; Based on the reference graph, the exposure range of the referenced target is verified.

4. The method according to claim 1 or 2, characterized in that, After performing a first verification on the referenced graph and obtaining a first verification result, the method further includes: Load the configuration data corresponding to the first skill and the shared assets into the sandbox; The second verification result is obtained by performing a second verification on the first skill based on the replay sample. The second verification is used to verify at least one of the following: whether the data mapping between the spatiotemporal sub-package and the business sub-package is successful, whether the derived indicators can be calculated, whether the output contract satisfies the business side reference, whether the prompt word variable can be rendered, whether the spatial constraint tool can be called, and whether the inference result satisfies the output format. The step of performing the release operation of the first skill when it is determined from the first verification result that the first skill meets the release conditions includes: If the first skill meets the release conditions based on the first verification result and the second verification result, the release operation of the first skill is executed.

5. The method according to claim 1 or 2, characterized in that, The execution of the first skill release operation includes: The first executor loads the spatiotemporal sub-package, and the second executor loads the service sub-package. The first skill is released when both the spatiotemporal sub-package and the business sub-package are successfully loaded and meet the compatibility requirements.

6. The method according to claim 5, characterized in that, The first executor is used to output a spatiotemporal context based on the spatiotemporal side sub-package; The second executor is used to generate structured reasoning results based on the business-side subpackage, the reasoning arrangement template, and the rendering prompts, by calling the query interface corresponding to the spatiotemporal context.

7. A skill publishing device based on configuration data, characterized in that, include: The first acquisition module is used to acquire configuration data and shared assets corresponding to the first skill. The configuration data includes a spatiotemporal sub-package and a business sub-package. The spatiotemporal sub-package is used to represent the spatiotemporal data of the spatial cognition task corresponding to the first skill. The business sub-package is used to represent the reasoning logic of the spatial cognition task. The spatiotemporal sub-package and the business sub-package are executed by the first executor and the second executor, respectively. The second acquisition module is used to acquire reference information of the business-side sub-package to at least one of the spatiotemporal-side sub-package and the shared asset, and construct a reference graph based on the reference information. The reference graph is used to characterize the dependency relationship of the business-side sub-package to at least one of the spatiotemporal-side sub-package and the shared asset. The first verification module is used to perform a first verification on the reference diagram and obtain a first verification result. The publishing module is used to execute the publishing operation of the first skill when it is determined from the first verification result that the first skill meets the publishing conditions.

8. An electronic device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the skill publishing method based on configuration data as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the skill publishing method based on configuration data as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of the skill publishing method based on configuration data as described in any one of claims 1 to 6.

Images