A skill-dependent conflict isolation method and system

Abstract

The application provides a skill-dependent conflict isolation method and system, which comprises the following steps: analyzing the skills of an intelligent agent, and constructing a dependent call graph; performing conflict judgment on the dependent call graph to obtain a conflict graph containing conflict edges; when two nodes of a conflict edge belong to different entry reachable sets respectively, and each interface parameter and return value is serializable, it is determined that the two nodes can be separated at the calling position, and the calling position is taken as a candidate boundary; the dependent node set dominated by each candidate boundary is calculated respectively; a conflict coverage set of the candidate boundary is obtained; candidate boundaries are iteratively selected according to the ratio of coverage benefit to isolation cost until all isolable conflicts are covered; the dependent call graph is split and merged according to the selected candidate boundaries, and a check is performed to obtain a public dependent layer and a conflict isolation layer and update a routing table synchronously; and a delivery package containing an SDK interface-to-isolation layer mapping routing table is generated. According to the scheme, the delivery volume does not increase repeatedly with non-conflict-dependent.

Description

Technical Field

[0001] This invention relates to the field of intelligent agent technology, and in particular to a method and system for isolating skill dependency conflicts. Background Technology

[0002] A smart agent's skill typically includes executable code, Python (a programming language) or Node.js (a runtime environment) dependencies, local commands, and SDK (Software Development Kit) calls. When delivering a skill, the dependencies and runtime need to be migrated to the target device along with the skill. Existing dependency isolation delivery solutions can be categorized into three types based on their isolation granularity. The first type replicates the entire virtual environment or container as a unit for the entire skill, such as venv (a standard Python virtual environment tool), conda (an environment and package management tool), pipx (a Python application isolation installation tool), and Docker (a containerization platform). While dependencies are correctly isolated, each skill repeatedly stores common runtimes and common dependencies, resulting in a linear increase in package size and build time with the number of skills. Secondly, dependencies are shared at the system package repository level, such as Nix (a package management system) package storage and Flatpak (a Linux application distribution and sandbox runtime framework). Dependencies are installed and locked at the package level, without distinguishing between different SDK calling branches within the same Skill that require different versions of the same dependency. Furthermore, permissions and dependency lists usually need to be manually declared by the developer. Thirdly, the runtime adds the dependency directories of each Skill to the host process's PATH (operating system executable file search path environment variable), NODE_PATH (Node.js module search path environment variable), and PYTHONPATH (Python module search path environment variable) in sequence. Even if the dependency files are located in different directories, the loading result still depends on the search path order; a Skill installed or upgraded later will change the dependency resolution results of other Skills.

[0003] The above solutions all use the entire Skill or the entire container as the isolation unit, resulting in a large delivery size. Summary of the Invention

[0004] This invention provides a method and system for isolating skill dependency conflicts to solve the technical problem of large delivery volume of Skills.

[0005] To address the aforementioned technical problems, this invention provides a skill dependency conflict isolation method, comprising the following steps:

[0006] S1. Analyze the skills of the intelligent proxy and use the SDK interface call points as separable boundaries to construct a dependency call graph;

[0007] S2. Perform conflict determination on the dependency call graph to obtain a conflict graph containing conflict edges;

[0008] S3. When two nodes of a conflicting edge belong to reachable sets of different entry points, and the interface parameters and return values ​​are serializable, it is determined that the two nodes can be separated at the call location, and the call location is taken as a candidate boundary.

[0009] S4. Calculate the set of dependent nodes dominated by each candidate boundary. When the two nodes of a conflict edge are located inside and outside the set of dependent nodes respectively after splitting, or are located in two independent execution partitions formed by the candidate boundary, it is considered that the candidate boundary covers the conflict on the conflict edge, and the conflict coverage set of the candidate boundary is obtained.

[0010] S5. Iteratively select candidate boundaries based on the ratio of coverage benefits to isolation costs until all isolable conflicts are covered.

[0011] S6. Based on the selected candidate boundaries, the dependency call graph is segmented and merged for verification to obtain the common dependency layer and conflict isolation layer, and the routing table is updated synchronously.

[0012] S7. Compile the common dependency layer and the conflict isolation layer to generate a delivery package containing a routing table mapping the SDK interface to the isolation layer.

[0013] Preferably, step S1 specifically includes the following steps:

[0014] Read the main process entry point, independent script entry point, and local tool entry point from the skill configuration file, and establish the execution entry point node;

[0015] Analyze function calls, sub-process calls, and SDK calls in the skill code, and establish function or sub-process nodes, SDK interface nodes, and corresponding call edges;

[0016] Read direct and transitive dependencies from Python dependency list files, Node.js package configuration files, dependency lock files, and compilation artifact metadata, and create dependency nodes;

[0017] Calculate the set of dependencies that can be reached by each execution entry point and SDK interface along the call relationship, forming the reachability relationship of "execution entry point - function or sub-process - SDK interface - dependency", and obtain the dependency call graph G=(V,E), where V represents the set of nodes and E represents the set of directed edges.

[0018] Preferably, step S2 specifically includes the following steps: a conflict edge is established when two nodes meet any of the following conditions: the names are the same and the version intervals are empty; the dynamic library names are the same under the same target architecture but the ABI major version or symbol version is incompatible; the command names are the same but the implementation digests are different and cannot be renamed and called; the SDK ABI requirements are incompatible.

[0019] Preferably, step S5 specifically includes the following steps: calculating the isolation cost of the candidate boundary according to the formula Cost(b)=αDb+βSb+γTb, where Cost(b) represents the isolation cost of the candidate boundary b, Db represents the size of the runtime and dependent files repeatedly saved after segmentation divided by the total runtime and dependent files of the skill; Sb is obtained by weighting the startup time of the newly added execution unit divided by the preset reference startup time and the resident memory divided by the preset reference memory; Tb represents the communication volume estimated based on the interface parameter type, average parameter size, number of files and call frequency divided by the preset reference communication volume; Db, Sb and Tb are normalized to 0 to 1 according to the corresponding benchmarks; α, β and γ are non-negative weights set according to the delivery scenario.

[0020] Preferably, step S5 further includes the following step: according to the formula Score(b) = Calculate the ratio of coverage gain to isolation cost, where Score(b) represents the ratio of coverage gain to isolation cost of candidate boundary b, Cb represents the conflict coverage set of candidate boundary b, c represents a conflict in the conflict coverage set Cb, Wc represents the weight of the conflict that must be isolated, and ε represents a preset positive number to prevent the denominator from being zero.

[0021] Preferably, step S5 further includes the following step: in each round, selecting the candidate boundary with the highest ratio of coverage benefit to isolation cost.

[0022] Preferably, step S5 further includes the following steps: when the ratio of coverage benefit to isolation cost is the same, the candidate boundary with the largest number of coverage conflicts, the lowest communication cost, and the closest to the conflict dependency is selected as the isolation boundary in sequence.

[0023] Preferably, step S6 specifically includes the following steps: when the dependency version ranges of the two isolation layers have a common solution, the operating system and CPU architecture are consistent, the language runtime version is consistent, the SDK ABI tags are the same, and merging will not restore the covered conflicts, then the two isolation layers are merged.

[0024] Preferably, step S6 specifically includes the following steps: synchronously updating the routing table from the SDK interface to the isolation layer according to the merged layer identifier, and deleting invalid layer mappings.

[0025] This invention also provides a skill dependency conflict isolation system, comprising the following modules:

[0026] The parsing module is used to parse the skills of the smart agent and use the SDK interface call points as splittable boundaries to build a dependency call graph;

[0027] The conflict determination module is used to determine the conflict in the dependency call graph and obtain a conflict graph containing conflict edges.

[0028] The candidate boundary selection module determines that the two nodes can be separated at the call location when the two nodes of a conflict edge belong to the reachable sets of different entry points and the interface parameters and return values ​​are serializable. The call location is then used as the candidate boundary.

[0029] The conflict coverage set calculation module is used to calculate the set of dependent nodes dominated by each candidate boundary. When the two nodes of a conflict edge are located inside and outside the set of dependent nodes respectively after splitting, or located in two independent execution partitions formed by the candidate boundary, the candidate boundary is considered to cover the conflict on the conflict edge, and the conflict coverage set of the candidate boundary is obtained.

[0030] The isolation cost calculation module is used to iteratively select candidate boundaries based on the ratio of coverage benefits to isolation costs until all isolable conflicts are covered.

[0031] The segmentation and merging verification module is used to segment and merge the dependency call graph according to the selected candidate boundaries, obtain the common dependency layer and conflict isolation layer, and synchronously update the routing table.

[0032] The compilation module is used to compile the common dependency layer and the conflict isolation layer to generate a delivery package containing a routing table mapping the SDK interface to the isolation layer.

[0033] The present invention provides a method and system for isolating skill dependency conflicts, which has the following technical effects:

[0034] (1) Delivery volume and build overhead do not increase with the repeated growth of conflict-free dependencies. Existing solutions replicate virtual environments or containers on a per-Skill basis, regardless of whether dependencies conflict. This invention generates independent search paths only for conflicting dependency nodes dominated by selected candidate boundaries. Runtime and dependencies that do not participate in conflicts are retained in the common dependency layer and reused in read-only mode. The isolation range is determined by the conflict edge rather than the Skill boundary, so the amount of repeatedly saved files mainly increases with the conflict branch, rather than increasing synchronously with the size of conflict-free dependencies.

[0035] (2) The same set of conflicts can be partitioned differently depending on the deployment conditions. The isolation cost is composed of the normalized duplicate dependency amount, execution unit overhead, and cross-environment communication volume weighted. When the weight of duplicate dependency amount is increased for offline small-capacity devices, the algorithm tends to select the boundary with fewer duplicate files; when the weight of execution unit and communication is increased for high-concurrency devices, the algorithm tends to select the boundary with lower call frequency and smaller parameter size. This effect is directly generated by the scenario-based weight of the cost function.

[0036] (3) Conflict determination covers incompatibilities beyond version numbers. Conflict edges are not only established when the intersection of version intervals is empty, but also when the main or symbolic versions of the dynamic library ABI are incompatible under the same target architecture, the command implementation digests are different and cannot be renamed for invocation, or the SDK ABI requirements are incompatible. Therefore, symbol-level and command-level incompatibilities that cannot be discovered by comparing version numbers will also enter the conflict graph and participate in boundary selection.

[0037] (4) The coexistence determination of the same path is feasible in engineering. This determination is based on the reachability of the call subgraph from the execution entry point to the SDK interface, without the need to solve the global precise control flow for dynamic languages. The SDK interface corresponding to the selected boundary is mapped to an independent isolation layer, and the host execution unit does not load the dependency of the conflicting branch. Therefore, the two ends of the conflict will not enter the same process-level module cache or dynamic library loading space. Unresolved dynamic calls are marked as pending confirmation and automatic construction is terminated, keeping the handling of uncertain situations conservative.

[0038] (5) No products that appear installable but have uncertain runtime behavior are generated. When the conflicting ends are on the same call stack, the interface parameters or return values ​​are not serializable, or there are dependencies to be confirmed, the system terminates the automatic build and outputs the conflicting dependency path, call location, and suggested handling location. Compared to overriding or downgrading dependency versions to force installation, this method explicitly exposes dependency conflicts during the build phase.

[0039] (6) Merging and verification after splitting can reduce redundant isolation layers. Two isolation layers are only merged if there is a common solution in the dependency version range, the running platform and language runtime are consistent, the SDK ABI tags are the same, and merging will not restore covered conflicts; the routing table is updated synchronously after merging. This mechanism can merge mergeable partitions formed during the iterative selection process, reducing unnecessary execution units and duplicate dependencies. Attached Figure Description

[0040] Figure 1 This is a flowchart of a skill dependency conflict isolation method provided in an embodiment of the present invention. Detailed Implementation

[0041] To make the objectives, advantages, and features of the present invention clearer, a skill dependency conflict isolation method and system proposed by the present invention will be further described in detail below with reference to the accompanying drawings. It should be noted that the drawings are all in a very simplified form and use non-precise proportions, and are only used to facilitate and clarify the illustration of the embodiments of the present invention.

[0042] In the description of this invention, the terms "first," "second," and other qualifiers are added for convenience of description and reference, and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with qualifiers such as "first" and "second" may explicitly or implicitly include one or more of that feature.

[0043] like Figure 1 As shown, the present invention provides a skill dependency conflict isolation method, comprising the following steps:

[0044] S1. Analyze the skills of the smart agent and use the SDK interface call points as separable boundaries to construct a dependency call graph.

[0045] Preferably, step S1 specifically includes the following steps: reading the main process entry point, independent script entry point, and local tool entry point from the skill configuration file to establish an execution entry point node; parsing function calls, sub-process calls, and SDK calls in the skill code to establish function or sub-process nodes, SDK interface nodes, and corresponding call edges; reading direct dependencies and transitive dependencies from Python dependency list files (such as requirements.txt), Node.js package configuration files (package.json), dependency lock files, and compilation artifact metadata to establish dependency nodes; calculating the set of dependencies reachable by each execution entry point and SDK interface along the call relationship to form a reachability relationship of "execution entry point—function or sub-process—SDK interface—dependency", resulting in a dependency call graph G=(V, E), where V represents the set of nodes and E represents the set of directed edges. This scheme achieves fine-grained dependency call graph construction from multiple aspects, including static configuration parsing, code semantic analysis, dependency file parsing, and reachability calculation.

[0046] Node v records at least the dependency name, version constraints, runtime type, target operating system, CPU (Central Processing Unit) architecture, language ABI (Application Binary Interface), SDK ABI (Software Development Kit Application Binary Interface), artifact size, execution entry point, and corresponding SDK interface. Directed edges E represent package dependencies or reachability relationships from execution entry points to dependencies. For dynamically imported or runtime commands, dependency nodes are supplemented based on explicit dependency mappings in SDK interface declarations and Skill configurations. Dependencies whose source cannot be determined are marked as pending confirmation. The system terminates the current automatic build and outputs the call location and source information of the pending-confirmation dependencies, requiring manual confirmation before rebuilding.

[0047] S2. Perform conflict determination on the dependency call graph to obtain a conflict graph Gc containing conflict edges.

[0048] Preferably, step S2 specifically includes the following steps: a conflict edge is established when two nodes meet any of the following conditions: the names are the same and the version intervals intersect emptyly; the dynamic libraries under the same target architecture have the same name but incompatible ABI major or symbolic versions; the command names are the same but the implementation summaries are different and cannot be renamed for invocation; the SDK ABI requirements are incompatible. When executing step S2, the dependency nodes can be normalized first: Python dependency declarations (requirements), npm (Node.js package management tool) semantic version specifications, and system tool versions are converted into comparable version intervals; the Python pre-compiled distribution package format, Node.js native extension modules, and dynamic libraries record the operating system, CPU architecture, and ABI tags. The CPU architecture is used as a dimension for selecting artifacts during subsequent compilation and installation and is not considered a dependency conflict edge within the same device. The command name and implementation summary can be recorded through the command dependency interface. Conflict edges are established not only when the version intervals intersect emptyly, but also when the dynamic library ABI major or symbolic versions are incompatible under the same target architecture, the command implementation summaries are different and cannot be renamed for invocation, or the SDK ABI requirements are incompatible. Therefore, symbol-level and command-level incompatibilities that cannot be detected by comparing version numbers will also be included in the conflict graph, thus covering incompatibilities beyond version numbers.

[0049] S3. When two nodes of a conflicting edge belong to the reachable sets of different entry points, and the interface parameters and return values ​​are serializable, it is determined that the two nodes can be separated at the call location, and the call location is taken as a candidate boundary. For each conflicting edge in the conflict graph Gc, it is determined whether the dependencies at both ends can be loaded in the same execution path. The determination is based on the reachability of SDK interface call points, without relying on the exact solution of the global control flow of the dynamic language: Suppose that the execution entry set P of Skill includes the main process entry, each SDK interface entry, independent script entry, and local tool entry; for each entry p, its reachable dependency set R(p) is statically obtained along the call subgraph of "entry point - function or subprocess - SDK interface - dependency", and dynamically imported according to the explicit dependency mapping in the SDK interface declaration and Skill configuration. Calls that cannot be resolved are marked as pending confirmation. Conflicting nodes u and v are determined to be likely to be loaded in the same execution path when they meet one of the following conditions: there exists an entry p such that u and v both belong to R(p); or there exists an entry sequence such that u and v meet in the transitive closure of any entry point. If the call parameters or return values ​​of the interfaces containing u and v contain non-serializable objects, then that location is not considered a candidate boundary, and the conflict is marked as requiring manual code modification. Only when u and v belong to reachable sets from different entry points, do not share a common entry point for simultaneous reach, and their interface parameters and return values ​​are serializable, are they determined to be separable at the call location, and that call location becomes a candidate boundary. The SDK interface corresponding to the selected boundary is mapped to an independent isolation layer in the delivery package. When this mapping is executed, the independent execution unit of the isolation layer only loads its own dependencies; the host execution unit does not load the dependencies of the conflicting branch. Therefore, the two ends of the conflict will not enter the same process-level module cache or dynamic library loading space. Only when both dependencies need to be retained, may enter the same loading space, and cannot be resolved through compatibility, are they marked as conflicts that must be isolated.

[0050] S4. Calculate the set of dependent nodes dominated by each candidate boundary. If two nodes of a conflicting edge are located inside and outside the set of dependent nodes respectively after splitting, or are located in two independent execution partitions formed by the candidate boundary, then the candidate boundary is considered to cover the conflict on the conflicting edge, and the conflict coverage set of the candidate boundary is obtained. The candidate boundary set B includes SDK interface call points, Skill sub-process entry points, independent script entry points, and local tool entry points with serializable input and output. For each candidate boundary b, calculate its dominant set of dependent nodes Vb from the call graph, that is, the set of dependent nodes that can be reached from the candidate boundary b along the dependency call graph and are assigned to the isolated execution partition corresponding to the candidate boundary b. If two nodes of a conflicting edge are located inside and outside Vb respectively after splitting, or are located in two independent execution partitions formed by b, then b is considered to cover the conflict. Thus, the conflict coverage set Cb of the candidate boundary b is obtained.

[0051] S5. Iteratively select candidate boundaries based on the ratio of coverage benefits to isolation costs until all isolable conflicts are covered.

[0052] Preferably, step S5 specifically includes the following steps: Calculate the isolation cost of the candidate boundary according to the formula Cost(b)=αDb+βSb+γTb, where Cost(b) represents the isolation cost of candidate boundary b; Db represents the size of the runtime and dependent files repeatedly saved after segmentation divided by the total runtime and dependent files of the skill; Sb is obtained by weighting the startup time of the newly added execution unit (a newly added execution unit refers to an independent running carrier added to the conflict isolation layer relative to the original host execution unit after selecting the isolation boundary) by a preset reference startup time and the resident memory by a preset reference memory; Tb represents the communication volume estimated based on interface parameter type, average parameter size, number of files, and call frequency divided by a preset reference communication volume; Db, Sb, and Tb are normalized to 0 to 1 according to their respective benchmarks; α, β, and γ are non-negative weights set according to the delivery scenario. Ratios greater than 1 are counted as 1, those between [0,1] are taken as the ratio itself, and the corresponding component is taken as 0 when the denominator is 0. The default values ​​are α=β=γ=1. For offline low-capacity devices, α=2, β=1, and γ=0.5 are used, while for high-concurrency devices, α=1, β=2, and γ=1.5. The isolation cost is a weighted average of the normalized duplicate dependency amount (Db), execution unit overhead (Sb), and cross-environment communication volume (Tb). When increasing the weight of duplicate dependencies for offline low-capacity devices, the algorithm tends to select boundaries with fewer duplicate files; when increasing the weights of execution units and communication for high-concurrency devices, the algorithm tends to select boundaries with lower call frequency and smaller parameter size. The same set of conflicts can result in different partitions depending on the deployment conditions.

[0053] Preferably, step S5 further includes the following step: according to the formula Score(b) = The ratio of coverage gain to isolation cost is calculated, where Score(b) represents the ratio of coverage gain to isolation cost for candidate boundary b, Cb represents the conflict coverage set of candidate boundary b, c represents a conflict in the conflict coverage set Cb, Wc represents the weight of the conflict that must be isolated, and ε represents a preset positive number to prevent the denominator from being zero. Wc can be 10 for native ABI conflicts, 5 for command implementation conflicts, and 1 for version range conflicts. The maximum value is taken when multiple conflict types exist for the same conflict edge. ε can be 0.001.

[0054] Preferably, step S5 further includes the following step: selecting the candidate boundary with the highest ratio of coverage benefit to isolation cost in each round, so as to weigh the conflict coverage benefit and isolation cost.

[0055] Preferably, step S5 further includes the following steps: when the ratio of coverage gain to isolation cost, i.e., candidate boundary score Score(b), is the same, the candidate boundary with the most coverage conflicts, the lowest communication cost, and the closest (closest means the fewest number of edges traversed from the conflict node to the candidate boundary) conflict dependency is selected as the isolation boundary in order to balance the conflict coverage gain and the isolation cost.

[0056] S6. Based on the selected candidate boundaries, the dependency call graph is segmented and merged for verification, resulting in the common dependency layer E0 and the conflict isolation layer E1 to En, and the routing table is updated synchronously.

[0057] Preferably, step S6 specifically includes the following steps: when the dependency version ranges of the two isolation layers have a common solution, the operating system and CPU architecture are consistent, the language runtime version is consistent, the SDK ABI tags are the same, and merging will not restore the covered conflicts, then the two isolation layers are merged to reduce redundant isolation layers.

[0058] Preferably, step S6 specifically includes the following steps: synchronously updating the routing table from the SDK interface to the isolation layer according to the merged layer identifier, and deleting invalid layer mappings in order to update the routing table in a timely manner.

[0059] S7. Compile the common dependency layer and the conflict isolation layer to generate a delivery package containing a routing table mapping SDK interfaces to the isolation layer. The isolation layer, containing the native binary, is built separately according to the target CPU architecture, such as amd64 (64-bit x86 instruction set architecture) and arm64 (64-bit ARM instruction set architecture). The CPU architecture is only used to determine the compilation artifacts and installation selection. The delivery package saves the Skill file, the common dependency layer, the conflict isolation layer, a summary of each layer, and a routing table from the "SDK interface or sub-process entry point to the isolation layer". The routing table records the constraint that the interface hitting the isolation boundary must be loaded by the corresponding independent execution unit of the isolation layer.

[0060] The skill dependency conflict isolation method provided by this invention has the following technical effects:

[0061] (1) Delivery volume and build overhead do not increase with the repeated growth of conflict-free dependencies. Existing solutions replicate virtual environments or containers on a per-Skill basis, regardless of whether dependencies conflict. This invention generates independent search paths only for conflicting dependency nodes dominated by selected candidate boundaries. Runtime and dependencies that do not participate in conflicts are retained in the common dependency layer and reused in read-only mode. The isolation range is determined by the conflict edge rather than the Skill boundary, so the amount of repeatedly saved files mainly increases with the conflict branch, rather than increasing synchronously with the size of conflict-free dependencies.

[0062] (2) The same set of conflicts can be partitioned differently depending on the deployment conditions. The isolation cost is composed of the normalized duplicate dependency amount, execution unit overhead, and cross-environment communication volume weighted. When the weight of duplicate dependency amount is increased for offline small-capacity devices, the algorithm tends to select the boundary with fewer duplicate files; when the weight of execution unit and communication is increased for high-concurrency devices, the algorithm tends to select the boundary with lower call frequency and smaller parameter size. This effect is directly generated by the scenario-based weight of the cost function.

[0063] (3) Conflict determination covers incompatibilities beyond version numbers. Conflict edges are not only established when the intersection of version intervals is empty, but also when the main or symbolic versions of the dynamic library ABI are incompatible under the same target architecture, the command implementation digests are different and cannot be renamed for invocation, or the SDK ABI requirements are incompatible. Therefore, symbol-level and command-level incompatibilities that cannot be discovered by comparing version numbers will also enter the conflict graph and participate in boundary selection.

[0064] (4) The coexistence determination of the same path is feasible in engineering. This determination is based on the reachability of the call subgraph from the execution entry point to the SDK interface, without the need to solve the global precise control flow for dynamic languages. The SDK interface corresponding to the selected boundary is mapped to an independent isolation layer, and the host execution unit does not load the dependency of the conflicting branch. Therefore, the two ends of the conflict will not enter the same process-level module cache or dynamic library loading space. Unresolved dynamic calls are marked as pending confirmation and automatic construction is terminated, keeping the handling of uncertain situations conservative.

[0065] (5) No products that appear installable but have uncertain runtime behavior are generated. When the conflicting ends are on the same call stack, the interface parameters or return values ​​are not serializable, or there are dependencies to be confirmed, the system terminates the automatic build and outputs the conflicting dependency path, call location, and suggested handling location. Compared to overriding or downgrading dependency versions to force installation, this method explicitly exposes dependency conflicts during the build phase.

[0066] (6) Merging and verification after splitting can reduce redundant isolation layers. Two isolation layers are only merged if there is a common solution in the dependency version range, the running platform and language runtime are consistent, the SDK ABI tags are the same, and merging will not restore covered conflicts; the routing table is updated synchronously after merging. This mechanism can merge mergeable partitions formed during the iterative selection process, reducing unnecessary execution units and duplicate dependencies.

[0067] The following are several specific examples to further illustrate the skill dependency conflict isolation method provided by this invention:

[0068] Example 1 (Version Range Conflict): A certain skill's public code depends on the Python runtime and requests (Python HTTP request library); document parsing SDK interface A depends on package P1.x, and image recognition SDK interface B depends on package P2.x. The two interfaces do not share a common entry point, and their parameters and return values ​​are both serializable. The version range intersection is empty, forming a conflict edge. Candidate boundaries A and B can both cover this conflict. If branch A has a smaller dependent file and its call parameter is only a file identifier, its cost is lower than splitting at B, so the algorithm chooses A as the isolation boundary. Ultimately, requests and the public runtime enter E0, P1.x enters E1; P2.x does not conflict with the dependencies in E0, so it remains in E0, and the routing table registers interface A to isolation layer E1.

[0069] Example 2 (Command Conflict with Same Name): Two SDK interfaces of a certain skill depend on different implementations of the Zip compression command zip: the call subgraph of interface A depends on version 1 of zip (implementation digest X), and interface B depends on version 3 of zip (implementation digest Y). The two interfaces have no common entry point, and their parameters and return values ​​are serializable. This is determined to be a conflict due to the same command name but different implementation digests. The algorithm generates candidate boundaries at interfaces A and B; if the output of zip v1 is smaller than that of zip v3 and the call frequency of interface A is low, the split is chosen at interface A, while zip v3 is retained in the common layer. The routing table registers interface A → isolation layer E1.

[0070] Example 3 (Native ABI Conflict in the Same Architecture): A certain image processing skill is deployed on an amd64 device. Interface A depends on the 1.x branch of the example dynamic link library libX, whose major ABI version tag is the Linux shared object file libX.so.1; Interface B depends on the 3.x branch of libX, whose major ABI version tag is the Linux shared object file libX.so.3. The symbol versions of the two are incompatible, and their coexistence in the same process load space will cause symbol resolution errors. Therefore, a native ABI conflict edge is established with a weight of 10. Interfaces A and B are located at different entry points and their parameters are serializable. The algorithm generates candidate boundaries at the two interface call points and selects the boundary based on the normalized duplicate dependency amount, execution unit overhead, and communication volume. After splitting, the common layer does not carry conflicting versions; the isolation layer corresponding to interface A carries the Linux shared object file libX.so.1, and the isolation layer corresponding to interface B carries the Linux shared object file libX.so.3. The routing table records the mapping from the two interfaces to their respective isolation layers.

[0071] Example 4 (Termination due to lack of candidate boundaries): Interface A uses both package P1.x and package P2.x in the same call stack. The module objects of the two versions are passed on the function stack, and the parameters or return values ​​are not serializable. There are no candidate boundaries to cover. The system stops automatic construction, outputs the message "Ppackage P1.x and Ppackage P2.x coexist in the call stack of interface A; it is recommended to split the interface or abstract a common subset," along with the dependency paths of the conflicting ends, and waits for manual modification before rebuilding.

[0072] Based on the same technical concept as the aforementioned skill dependency conflict isolation method, this invention also provides a skill dependency conflict isolation system, comprising the following modules:

[0073] The parsing module is used to parse the skills of the smart agent and use the SDK interface call points as splittable boundaries to build a dependency call graph;

[0074] The conflict determination module is used to determine the conflict in the dependency call graph and obtain a conflict graph containing conflict edges.

[0075] The candidate boundary selection module determines that the two nodes can be separated at the call location when the two nodes of a conflict edge belong to the reachable sets of different entry points and the interface parameters and return values ​​are serializable. The call location is then used as the candidate boundary.

[0076] The conflict coverage set calculation module is used to calculate the set of dependent nodes dominated by each candidate boundary. When the two nodes of a conflict edge are located inside and outside the set of dependent nodes respectively after splitting, or located in two independent execution partitions formed by the candidate boundary, the candidate boundary is considered to cover the conflict on the conflict edge, and the conflict coverage set of the candidate boundary is obtained.

[0077] The isolation cost calculation module is used to iteratively select candidate boundaries based on the ratio of coverage benefits to isolation costs until all isolable conflicts are covered.

[0078] The segmentation and merging verification module is used to segment and merge the dependency call graph according to the selected candidate boundaries, obtain the common dependency layer and conflict isolation layer, and synchronously update the routing table.

[0079] The compilation module is used to compile the common dependency layer and the conflict isolation layer to generate a delivery package containing a routing table mapping the SDK interface to the isolation layer.

[0080] In summary, the skill dependency conflict isolation method and system provided by this invention have the following technical effects:

[0081] (1) Delivery volume and build overhead do not increase with the repeated growth of conflict-free dependencies. Existing solutions replicate virtual environments or containers on a per-Skill basis, regardless of whether dependencies conflict. This invention generates independent search paths only for conflicting dependency nodes dominated by selected candidate boundaries. Runtime and dependencies that do not participate in conflicts are retained in the common dependency layer and reused in read-only mode. The isolation range is determined by the conflict edge rather than the Skill boundary, so the amount of repeatedly saved files mainly increases with the conflict branch, rather than increasing synchronously with the size of conflict-free dependencies.

[0082] (2) The same set of conflicts can be partitioned differently depending on the deployment conditions. The isolation cost is composed of the normalized duplicate dependency amount, execution unit overhead, and cross-environment communication volume weighted. When the weight of duplicate dependency amount is increased for offline small-capacity devices, the algorithm tends to select the boundary with fewer duplicate files; when the weight of execution unit and communication is increased for high-concurrency devices, the algorithm tends to select the boundary with lower call frequency and smaller parameter size. This effect is directly generated by the scenario-based weight of the cost function.

[0083] (3) Conflict determination covers incompatibilities beyond version numbers. Conflict edges are not only established when the intersection of version intervals is empty, but also when the main or symbolic versions of the dynamic library ABI are incompatible under the same target architecture, the command implementation digests are different and cannot be renamed for invocation, or the SDK ABI requirements are incompatible. Therefore, symbol-level and command-level incompatibilities that cannot be discovered by comparing version numbers will also enter the conflict graph and participate in boundary selection.

[0084] (4) The coexistence determination of the same path is feasible in engineering. This determination is based on the reachability of the call subgraph from the execution entry point to the SDK interface, without the need to solve the global precise control flow for dynamic languages. The SDK interface corresponding to the selected boundary is mapped to an independent isolation layer, and the host execution unit does not load the dependency of the conflicting branch. Therefore, the two ends of the conflict will not enter the same process-level module cache or dynamic library loading space. Unresolved dynamic calls are marked as pending confirmation and automatic construction is terminated, keeping the handling of uncertain situations conservative.

[0085] (5) No products that appear installable but have uncertain runtime behavior are generated. When the conflicting ends are on the same call stack, the interface parameters or return values ​​are not serializable, or there are dependencies to be confirmed, the system terminates the automatic build and outputs the conflicting dependency path, call location, and suggested handling location. Compared to overriding or downgrading dependency versions to force installation, this method explicitly exposes dependency conflicts during the build phase.

[0086] (6) Merging and verification after splitting can reduce redundant isolation layers. Two isolation layers are only merged if there is a common solution in the dependency version range, the running platform and language runtime are consistent, the SDK ABI tags are the same, and merging will not restore covered conflicts; the routing table is updated synchronously after merging. This mechanism can merge mergeable partitions formed during the iterative selection process, reducing unnecessary execution units and duplicate dependencies.

[0087] The above description is only a description of preferred embodiments of the present invention and is not intended to limit the scope of the present invention in any way. Any changes or modifications made by those skilled in the art based on the above disclosure shall fall within the protection scope of the present invention.

Claims

1. A skill dependency conflict isolation method, characterized in that, Includes the following steps: S1. Analyze the skills of the intelligent proxy and use the SDK interface call points as separable boundaries to construct a dependency call graph; S2. Perform conflict determination on the dependency call graph to obtain a conflict graph containing conflict edges; S3. When two nodes of a conflicting edge belong to reachable sets of different entry points, and the interface parameters and return values ​​are serializable, it is determined that the two nodes can be separated at the call location, and the call location is taken as a candidate boundary. S4. Calculate the set of dependent nodes dominated by each candidate boundary. When the two nodes of a conflict edge are located inside and outside the set of dependent nodes respectively after splitting, or are located in two independent execution partitions formed by the candidate boundary, it is considered that the candidate boundary covers the conflict on the conflict edge, and the conflict coverage set of the candidate boundary is obtained. S5. Iteratively select candidate boundaries based on the ratio of coverage benefits to isolation costs until all isolable conflicts are covered. S6. Based on the selected candidate boundaries, the dependency call graph is segmented and merged for verification to obtain the common dependency layer and conflict isolation layer, and the routing table is updated synchronously. S7. Compile the common dependency layer and the conflict isolation layer to generate a delivery package containing a routing table mapping the SDK interface to the isolation layer.

2. The skill dependency conflict isolation method as described in claim 1, characterized in that, Step S1 specifically includes the following steps: Read the main process entry point, independent script entry point, and local tool entry point from the skill configuration file, and establish the execution entry point node; Analyze function calls, sub-process calls, and SDK calls in the skill code, and establish function or sub-process nodes, SDK interface nodes, and corresponding call edges; Read direct and transitive dependencies from Python dependency list files, Node.js package configuration files, dependency lock files, and compilation artifact metadata, and create dependency nodes; Calculate the set of dependencies that can be reached by each execution entry point and SDK interface along the call relationship, forming the reachability relationship of "execution entry point - function or sub-process - SDK interface - dependency", and obtain the dependency call graph G=(V,E), where V represents the set of nodes and E represents the set of directed edges.

3. The skill dependency conflict isolation method as described in claim 2, characterized in that, Step S2 specifically includes the following steps: A conflict edge is established when two nodes meet any of the following conditions: the names are the same and the version intervals are empty; the dynamic library names are the same under the same target architecture but the ABI major version or symbol version is incompatible; the command names are the same but the implementation digests are different and cannot be renamed and called; the SDK ABI requirements are incompatible.

4. The skill dependency conflict isolation method as described in claim 3, characterized in that, Step S5 specifically includes the following steps: Calculate the isolation cost of the candidate boundary according to the formula Cost(b)=αDb+βSb+γTb, where Cost(b) represents the isolation cost of candidate boundary b, Db represents the size of the runtime and dependent files repeatedly saved after segmentation divided by the total runtime and dependent files of the skill; Sb is obtained by weighting the startup time of the newly added execution unit divided by the preset reference startup time and the resident memory divided by the preset reference memory; Tb represents the communication volume estimated based on the interface parameter type, average parameter size, number of files and call frequency divided by the preset reference communication volume; Db, Sb and Tb are normalized to 0 to 1 according to the corresponding benchmarks; α, β and γ are non-negative weights set according to the delivery scenario.

5. The skill dependency conflict isolation method as described in claim 4, characterized in that, Step S5 also includes the following steps: according to the formula Score(b) = Calculate the ratio of coverage gain to isolation cost, where Score(b) represents the ratio of coverage gain to isolation cost of candidate boundary b, Cb represents the conflict coverage set of candidate boundary b, c represents a conflict in the conflict coverage set Cb, Wc represents the weight of the conflict that must be isolated, and ε represents a preset positive number to prevent the denominator from being zero.

6. The skill dependency conflict isolation method as described in claim 5, characterized in that, Step S5 also includes the following steps: in each round, select the candidate boundary with the highest ratio of coverage benefit to isolation cost.

7. The skill dependency conflict isolation method as described in claim 5, characterized in that, Step S5 also includes the following steps: when the ratio of coverage benefit to isolation cost is the same, the candidate boundary with the largest number of coverage conflicts, the lowest communication cost, and the closest to the conflict dependency is selected as the isolation boundary in sequence.

8. The skill dependency conflict isolation method as described in claim 1, characterized in that, Step S6 specifically includes the following steps: when the dependency version ranges of the two isolation layers have a common solution, the operating system and CPU architecture are consistent, the language runtime version is consistent, the SDK ABI tags are the same, and merging will not restore the covered conflicts, then the two isolation layers are merged.

9. A skill dependency conflict isolation method as described in claim 8, characterized in that, Step S6 specifically includes the following steps: synchronously update the routing table from the SDK interface to the isolation layer according to the merged layer identifier, and delete the invalid layer mappings.

10. A skill dependency conflict isolation system, characterized in that, Includes the following modules: The parsing module is used to parse the skills of the smart agent and use the SDK interface call points as splittable boundaries to build a dependency call graph; The conflict determination module is used to determine the conflict in the dependency call graph and obtain a conflict graph containing conflict edges. The candidate boundary selection module determines that the two nodes can be separated at the call location when the two nodes of a conflict edge belong to the reachable sets of different entry points and the interface parameters and return values ​​are serializable. The call location is then used as the candidate boundary. The conflict coverage set calculation module is used to calculate the set of dependent nodes dominated by each candidate boundary. When the two nodes of a conflict edge are located inside and outside the set of dependent nodes respectively after splitting, or located in two independent execution partitions formed by the candidate boundary, the candidate boundary is considered to cover the conflict on the conflict edge, and the conflict coverage set of the candidate boundary is obtained. The isolation cost calculation module is used to iteratively select candidate boundaries based on the ratio of coverage benefits to isolation costs until all isolable conflicts are covered. The segmentation and merging verification module is used to segment and merge the dependency call graph according to the selected candidate boundaries, obtain the common dependency layer and conflict isolation layer, and synchronously update the routing table. The compilation module is used to compile the common dependency layer and the conflict isolation layer to generate a delivery package containing a routing table mapping the SDK interface to the isolation layer.

Images