Tool invocation method and apparatus, tool invocation management system

Abstract

This specification provides a tool invocation method and apparatus, and a tool invocation management system. The method includes: responding to a tool invocation command sent by an intelligent processing unit, obtaining a tool identifier from the tool invocation command and obtaining a dialogue context; obtaining a tool profile of a target tool from a tool registry based on the tool identifier, determining the target execution permission and target risk level of the target tool based on the tool profile and the dialogue context, wherein the tool profile is a structured data set describing the tool's capabilities and has been pre-configured in the tool registry; if the target execution permission is not granted, determining the target isolation level based on the target risk level and constructing a target execution environment corresponding to the target isolation level; invoking the target tool in the target execution environment, executing the target task corresponding to the tool invocation command, obtaining the execution result, and returning the execution result to the intelligent processing unit; thereby increasing the probability of a successful tool invocation.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to a method for invoking tools. Background Technology

[0002] Current intelligent agent systems based on large language models can invoke external tools (such as compilers, database clients, and code analysis tools) to perform complex tasks. However, the current architecture lacks an effective intermediate management mechanism between the intelligent agent based on large language models and the execution of these tools.

[0003] In terms of tool permission management, a binary strategy of static whitelist / blacklist is usually adopted, which cannot dynamically determine permissions based on task context. This leads to either excessive permission granting, which brings security risks, or excessive blocking, which hinders legitimate operations. Furthermore, the execution environment of the tools adopts a globally shared approach. When dependencies between different tools conflict, it is impossible to match differentiated isolation granularity according to the risk characteristics of the tools, resulting in execution failures and resource waste caused by environment dependency conflicts.

[0004] In other words, the tool cannot dynamically determine permissions and configure differentiated environments during execution, which leads to risks of data security and execution failure, making it impossible to achieve safe and efficient tool execution. Summary of the Invention

[0005] In view of this, embodiments of this specification provide a tool invocation method. One or more embodiments of this specification also relate to a tool invocation apparatus, a tool invocation management system, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0006] According to a first aspect of the embodiments of this specification, a tool invocation method is provided, comprising: In response to a tool invocation command sent by the intelligent processing unit, the tool identifier in the tool invocation command is obtained, and the dialogue context is obtained; The tool profile of the target tool is obtained from the tool registry based on the tool identifier. The target execution permission and target risk level of the target tool are determined based on the tool profile and the dialogue context. The tool profile is a structured data set describing the capabilities of the tool and has been pre-configured in the tool registry. If the target execution permission is granted, the target isolation level is determined based on the target risk level, and a target execution environment corresponding to the target isolation level is constructed. The target tool is invoked in the target execution environment to execute the target task corresponding to the tool invocation instruction, obtain the execution result, and return the execution result to the intelligent processing unit.

[0007] According to a second aspect of the embodiments of this specification, a tool invocation apparatus is provided, comprising: The response module is configured to respond to a tool invocation command sent by the intelligent processing unit, obtain the tool identifier in the tool invocation command, and obtain the dialogue context; The determination module is configured to obtain the tool profile of the target tool from the tool registry based on the tool identifier, and determine the target execution permission and target risk level of the target tool based on the tool profile and the dialogue context. The tool profile is a structured data set describing the capabilities of the tool, and the tool profile has been pre-configured in the tool registry. The construction module is configured to determine the target isolation level based on the target risk level and construct the target execution environment corresponding to the target isolation level, provided that the target execution permission is granted. The acquisition module is configured to invoke the target tool in the target execution environment, execute the target task corresponding to the tool invocation instruction, obtain the execution result, and return the execution result to the intelligent processing unit.

[0008] According to a third aspect of the embodiments of this specification, a tool invoking a management system is provided, comprising: The command interception module includes a first interception submodule and a second interception submodule. The first interception submodule is used to respond to the tool call instruction sent by the intelligent processing unit, obtain the tool identifier in the tool call instruction, and obtain the dialogue context. The second interception submodule is used to perform pre-execution verification on the system command corresponding to the tool call instruction before calling the target tool corresponding to the tool identifier and executing the target task corresponding to the tool call instruction in the target execution environment. The tool registry module is used to store the tool profiles of each tool. The permission decision module is used to determine the target execution permission and target risk level of the target tool based on the tool profile and the dialogue context. The tool profile is a structured data set describing the capabilities of the tool, and the tool profile has been pre-configured in the tool registry center. The execution environment management module is used to determine the target isolation level based on the target risk level and construct the target execution environment corresponding to the target isolation level; The feedback update module is used to send the execution result corresponding to the tool invocation command back to the tool registration center; The file system abstraction module is used to convert access instructions in a file operation request into primitive instructions corresponding to the target file system when the target tool is invoked to access the target file system.

[0009] According to a fourth aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the tool invocation method described above.

[0010] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the above-described tool invocation method.

[0011] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described tool invocation method.

[0012] This specification provides a tool invocation method in one embodiment. Responding to a tool invocation command sent by an intelligent processing unit, it obtains the tool identifier from the command and simultaneously acquires the dialogue context. This introduces the specific semantic environment of the current task into the decision-making stage before tool execution, providing a basis for subsequent dynamic permission determination and avoiding overly broad or strict permissions due to static configuration. Based on the tool identifier, it obtains a tool profile of the target tool from the tool registry center, and determines the target execution permission and target risk level of the target tool based on the tool profile and the dialogue context. The tool profile is a structured data set describing the tool's capabilities, combining the inherent attributes of the target tool (which include tool attribute information) with user intent, task stage, etc., in the current dialogue context. This achieves dynamic permission determination based on the task context, preventing excessive interception of legitimate operations and eliminating excessive unauthorized or malicious invocations. By granting permission, the contradiction between security and availability caused by the static binary strategy is resolved. When the target execution permission is granted, the target isolation level is determined based on the target risk level, and a target execution environment corresponding to the target isolation level is constructed. This allows the isolation granularity to be differentiated rather than globally uniform, avoiding the high performance overhead and excessive dependency configuration complexity caused by uniform high isolation, and avoiding inter-tool dependency conflicts caused by uniform low isolation. This significantly reduces the execution failure rate and resource waste. The target tool is invoked within the target execution environment to execute the target task corresponding to the tool invocation instruction, obtain the execution result, and return the execution result to the intelligent processing unit. This achieves a closed-loop process from permission determination to environment isolation to secure execution, ensuring that the intelligent processing unit efficiently completes tool invocations in complex tasks under secure and controllable conditions, significantly increasing the probability of a successful tool invocation. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a tool invocation method provided in one embodiment of this specification; Figure 2 This is a system architecture diagram corresponding to a tool invocation method provided in one embodiment of this specification; Figure 3 This is a schematic diagram illustrating the processing of a tool invocation method provided in one embodiment of this specification; Figure 4 This is a schematic diagram of the structure of a tool calling device provided in one embodiment of this specification; Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0014] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0015] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0016] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0017] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0018] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0019] Intelligent Processing Unit: An automated processing system with a Large Language Model (LLM) as the core reasoning engine, combined with memory mechanisms, planning capabilities, and tool usage capabilities.

[0020] Tool call: External function interface call instructions, structured instructions generated by the model requesting external tools to execute.

[0021] Hook: An interception mechanism, a hook function that is triggered before the actual execution of a system command.

[0022] Tool profile: A structured collection of data describing the capabilities of a tool, including information such as functionality, environment, permissions, and status.

[0023] Cold start: The process of handling the first call of an unregistered tool. In this embodiment, the "allow first, then collect" processing strategy is adopted for unknown tools during the cold start phase.

[0024] Environment Factory: A generation module that automatically builds matching execution environments based on tool profile declarations, used to generate ready-to-use isolated execution environments.

[0025] Preheating pooling: A mechanism that pre-creates and caches execution environment instances to reduce startup latency, and pre-builds environment caches for high-frequency tools.

[0026] Current intelligent agent systems based on large language models frequently need to invoke external command-line tools (such as compilers, package managers, database clients, code analysis tools, etc.) to complete complex tasks. However, the lack of an effective intermediate management mechanism between the intelligent agent and the tool execution layer in existing architectures leads to the following systemic problems: When generating tool invocation commands, large language models are completely unaware of the actual state of the tools in the target environment (whether they are installed, whether the versions match, and whether the paths are reachable). The model "assumes" the existence of the tools based on training knowledge, but frequently encounters errors such as command not found and version incompatibility during actual execution. After each failure, the model needs to consume additional inference resources to parse error messages, infer the cause, and generate repair commands, forming an inefficient "invocation-failure-analysis-retry" loop. Experimental results show that in complex development environments, invalid token consumption due to toolchain issues can account for 20%-40% of the total consumption, meaning that blindly invoking tools leads to a large amount of invalid inference consumption.

[0027] Existing solutions typically manage tool execution permissions using static whitelists / blacklists. This binary strategy leads to two extremes: excessive permission granting introduces security risks; excessive blocking hinders legitimate operations, forcing users to frequently grant manual authorizations and interrupting the task flow. It lacks the ability to dynamically determine permissions based on task context, failing to distinguish between the fundamentally different semantics of "deleting temporary files in the test directory" and "performing deletion in the root directory."

[0028] Different tools have varying requirements for their runtime environment (such as Python version, system library version, environment variable configuration, etc.). The current solution relies on a global environment; when dependencies between multiple tools conflict, the model cannot resolve this autonomously, requiring numerous interaction rounds for environment debugging. This indicates a lack of environment consistency and dependency conflicts between tools. Furthermore, the handling process and final solution for each failed tool call remain within the context of the current session, making them unreusable across sessions. The same toolchain issues repeatedly occur in different sessions, resulting in redundant resource waste.

[0029] Therefore, this specification provides a tool invocation method with a complete closed-loop lifecycle management of "interception-query-preprocessing-authorization-execution-feedback" to address scenarios where large language model agents encounter numerous invalid retries and token waste when invoking external tools due to issues such as tool non-existence, version mismatch, insufficient permissions, environment incompatibility, and differences in cross-operating system file systems. Through interception collaboration mechanisms, multi-mechanism permission fusion decision-making based on dialogue context (including semantic inference and dynamic trust levels), and a unified file system abstraction layer for agents (including semantic-level file operation primitives, path normalization, pluggable adapters, and permission linkage), the success rate of tool invocation can be significantly improved, invalid token consumption can be reduced, and seamless file operations across operating systems and file systems can be achieved.

[0030] This specification provides a tool invocation method, and also relates to a tool invocation device, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0031] See Figure 1 , Figure 1 A flowchart of a tool invocation method provided in one embodiment of this specification is shown, which specifically includes the following steps.

[0032] Step 102: In response to the tool call instruction sent by the intelligent processing unit, obtain the tool identifier in the tool call instruction and obtain the dialogue context.

[0033] The intelligent processing unit can be understood as an automated processing system with a Large Language Model (LLM) as its core inference engine, combined with memory mechanisms, planning capabilities, and tool usage capabilities. In this embodiment, the intelligent processing unit is an autonomous task execution system used to generate tool invocation instructions, i.e., an LLM agent. The tool invocation instruction can be understood as a structured instruction that requests an external tool to perform an operation, such as a command to run a code formatting tool or perform file read / write operations. The tool identifier can be understood as an identifier used to uniquely identify the target tool's identity information. The dialogue context can be understood as a set of semantic information related to the task in the current session, including the task objective, historical operation records, and natural language descriptions input by the user.

[0034] Specifically, in response to the tool invocation command sent by the intelligent processing unit, the tool identifier is first extracted from the command by analyzing the tool invocation command to determine the specific tool to be invoked; at the same time, the current dialogue context is obtained to understand the task background and operation intent of this invocation.

[0035] The tool identifier is used to query the tool profile in the tool registry center to determine the tool's availability, version compatibility, environment dependencies, and permission requirements; the dialogue context serves as the input for the subsequent permission decision engine to perform semantic inference, helping to determine the risk level and legality of this call.

[0036] For example, when an LLM agent performs a code quality analysis task, it generates a tool call command: "Run the static analysis tool to scan the current project directory." Upon receiving this tool call command, it extracts the tool identifier as "static-analyzer" and obtains the dialogue context. The dialogue context may include the task goal as "code review", the historical operation record as "switched to the project root directory", the current working directory as " / project / 1", and the user's original input as "help me check code style issues".

[0037] By proactively acquiring the tool identifier and dialogue context before tool invocation, a data foundation is laid for subsequent tool profile queries, availability verification, and dynamic permission decisions. This avoids the agent blindly executing invocations when the tool does not exist or the context does not match, thereby reducing invalid failure retries and token consumption.

[0038] Step 104: Obtain the tool profile of the target tool from the tool registry based on the tool identifier, and determine the target execution permission and target risk level of the target tool based on the tool profile and the dialogue context. The tool profile is a structured data set describing the capabilities of the tool, and the tool profile has been pre-configured in the tool registry.

[0039] In this context, "tool" can be understood as a functional unit that can be invoked, such as a weather query API, a data analysis function, or a device control command, etc., without any specific limitations.

[0040] A tool profile can be understood as a structured metadata set that includes basic dimensional information and LLM adaptability dimensional information.

[0041] Basic dimension information includes, but is not limited to, the tool's functional description (the tool's functional scope, supported input and output formats, and applicable task types), version information (currently installed version, compatible version range, and differences between versions), environment dependencies (runtime dependencies and environment variable requirements), permission requirements (the minimum set of permissions required and whether irreversible operations are involved), and health status (recent execution success rate, average response time, and last failure information).

[0042] LLM adaptability dimensions include, but are not limited to, Token consumption estimation (the estimated number of tokens required for model processing, calculated based on the typical output of the tool. This helps agents prioritize tools with higher output efficiency when multiple tools are available, avoiding a single tool call output that fills the model's context window), output resolvability score (assessing the structured nature of the tool's output, affecting the token consumption and accuracy of the model in resolving the tool's output. Low-resolvability tool outputs require structured transformation by middleware before being fed back to the model), illusion risk level (marking common error patterns in how large language models use the tool. When the interceptor detects that the model-generated call command matches a known illusion pattern, it actively intercepts and corrects it), context window friendliness (assessing whether the typical output of the tool exceeds the model's context window capacity and whether a truncation strategy is needed. For tools marked as "unfriendly," the system will automatically perform summary compression on the output after execution before feeding it back to the model), and operation reversibility labeling (classifying the operations performed by the tool into three levels—read-only operations (e.g., viewing files), reversible write operations (e.g., creating files, which can be deleted and rolled back), and irreversible write operations (e.g., deleting files, overwriting data)).

[0043] Execution permission can be understood as the authorization result of allowing or prohibiting a target tool from performing a specific operation, including allowing, blocking, or triggering an additional confirmation process; risk level can be understood as the degree of security risk obtained from the assessment, which is used to guide permission decisions and isolation level selection.

[0044] Specifically, based on the tool identifier extracted from the tool invocation command, the tool registry (a centralized management system for available tools (such as APIs, functions, services, and algorithm components) corresponding to intelligent processing units, providing registration, discovery, verification, and monitoring capabilities) queries and retrieves the tool profile of the target tool. This tool profile provides the target tool's capabilities, runtime dependencies, permission requirements, and compatibility information related to interaction with the LLM agent. Using the dialogue context as input, and combining dimensions such as operation reversibility annotations and permission requirements in the tool profile, the execution permissions that should be granted to the target tool in the current invocation scenario, as well as the corresponding risk level, are determined.

[0045] It's important to note that when a tool is registered with a tool registry, the registry not only records the tool's access point (such as API address and function name), but also synchronously receives or automatically generates a tool profile corresponding to that tool. This tool profile is pre-configured in the registry during the registration phase. When the tool is subsequently discovered or invoked, the tool profile exists stably in the registry as metadata description information, available for querying and parsing.

[0046] For example, the LLM agent invokes the "static-analyzer" tool to scan the project directory for code. Based on the tool identifier "static-analyzer," it queries the tool registry to obtain the tool's profile, which includes information such as: operation reversibility marked as "read-only," estimated token consumption as medium, and historical success rate of 98%. Combining this with the dialogue context—the task goal being "code review"—and the historical operation record showing the user is checking code style, it determines the target tool's execution permissions (e.g., "allow") and target risk level (e.g., "low risk") for this tool invocation.

[0047] The tool invocation method provided in the embodiments of this specification completes the accurate assessment of permissions and risks before the tool is executed by jointly determining the tool profile and the dialogue context. This upgrades the traditional static binary permission control to a semantically aware dynamic authorization, avoiding security risks caused by excessive permission or task interruption caused by excessive interception. At the same time, it provides a decision basis for the subsequent selection of the execution environment isolation level.

[0048] In one or more embodiments of this specification, before determining the target execution permissions and target risk level of the target tool, the state of the target tool is adjusted to a ready state; that is, based on the ready state of the target tool, the corresponding execution permissions and risk level are determined. Specific implementation methods are described below: Before determining the target execution permissions and target risk level of the target tool based on the tool profile and the dialogue context, the process also includes: If the target tool is determined to be in a non-ready state based on the tool profile, a preprocessing operation is performed on the target tool to adjust its state to a ready state.

[0049] The "not ready" state can be understood as the state in which the target tool does not have the conditions for normal invocation in the current execution environment, which may be caused by the tool not being installed, version mismatch, unreachable path, missing dependencies, etc. The preprocessing operation can be understood as the proactive repair actions performed before the tool is invoked and executed, including performing version alignment (installing or switching to a compatible version) when the version is mismatched, performing path rewriting when the path is unreachable, and triggering dependency installation when dependencies are missing. The "ready" state can be understood as the state in which the target tool, after preprocessing, meets the prerequisites for normal execution and can be correctly invoked.

[0050] Specifically, before determining the execution permissions and risk level of the target tool based on the tool profile and dialogue context, the system first determines whether the target tool is in a ready state based on dimensions such as version information, environment dependencies, and health status in the tool profile. If it detects that the tool is not installed, the installed version does not match the compatible version range marked in the tool profile, the path is unreachable, or runtime dependencies are missing, the target tool is determined to be in a not-ready state.

[0051] At this point, the preprocessing process is triggered, and based on the environment dependency declarations and version requirements recorded in the tool profile, the corresponding repair operations are performed to adjust the target tool from an unready state to a ready state.

[0052] For example, an LLM agent invokes the "static-analyzer" tool. The tool profile shows that the currently installed version is v2.1, while the compatible version range indicated in the tool profile is v3.0+. Therefore, an automatic version upgrade operation is triggered, upgrading the tool from v2.1 to v3.2 (a stable version within the compatibility range). This may also require the installation of two new runtime dependency libraries. After the upgrade and dependency installation are completed (i.e., preprocessing), the tool's state is adjusted to the ready state, and permission decisions are then executed for tools in the ready state.

[0053] The tool invocation method provided in the embodiments of this specification transforms the traditional "retry after the fact" mode, which relies on repeated trial and error and self-repair by LLM agents, into a "prevention before the fact" mode by proactively detecting and repairing the tool's readiness state before making permission decisions. This avoids invalid invocations and token waste caused by tools not being ready, and enables subsequent permission decisions and execution processes to be based on available tools, thereby improving the success rate of tool invocation.

[0054] In one or more embodiments of this specification, when determining the target execution permission of a target tool, it is necessary to determine the reversibility label of the operation corresponding to the tool's invocation instruction. If the label indicates that the operation is irreversible, the initial execution permission is directly determined to be "not approved"; otherwise, the final target execution permission is determined based on at least one permission decision result. Specific implementation methods are described below: Based on the tool profile and the dialogue context, the target execution permissions and target risk level of the target tool are determined, including: Based on the tool profile and the dialogue context, determine the operation reversibility label corresponding to the tool invocation command; Determine whether the reversibility flag of the operation is irreversible. If so, determine that the initial execution permission is denied and the target risk level is high, send a permission notification to the client, and if the client returns an authorization response corresponding to the permission notification, determine that the target execution permission is granted. If not, the target execution permission and the target risk level are determined based on at least one permission decision result.

[0055] Among them, the operation reversibility label can be understood as a pre-classification of the recoverability of the operations performed by the tool in the tool profile, including read-only operations (such as viewing files), reversible write operations (such as creating files, which can be deleted and rolled back), and irreversible write operations (such as deleting files, overwriting data, and modifying system configurations); irreversible operations can be understood as operation types that cannot be restored to their original state by conventional means after execution, usually involving permanent data deletion, changes to critical system configurations, etc.

[0056] The permission decision result can be understood as the permission judgment result output by each independent mechanism (static pre-authorization, semantic inference, trust level assessment) in the multi-mechanism permission fusion decision; the initial execution permission can be understood as the permission judgment result determined by the permission decision engine for the first time after completing the risk assessment; the authorization response can be understood as the operation instruction of confirmation and permission returned by the client.

[0057] Specifically, when determining the execution permission and risk level of a target tool based on the tool profile and dialogue context, the permission decision engine first reads the operation reversibility label corresponding to the tool from the tool profile and determines whether the operation reversibility label is an irreversible operation. If it is determined to be a non-irreversible operation (i.e., a read-only operation or a reversible operation), the engine performs a weighted fusion of multiple permission decision results, such as static pre-authorization, semantic inference, and trust level assessment, and determines the final target execution permission (pass or fail) and target risk level based on the fused comprehensive score. If it is determined to be an irreversible operation, the engine directly determines that the operation should not be allowed, that is, the initial execution permission is set to fail and the target risk level is set to high. Then, a permission notification is sent to the client to request manual confirmation. Only after receiving the authorization response (confirmation of approval) returned by the client is the target execution permission updated to pass. That is, an additional confirmation process is forcibly triggered for operations identified as irreversible.

[0058] For example, if an LLM agent calls the "rm" tool to delete a file, the permission decision engine first reads the operation's reversibility label from the tool profile. The tool is labeled as an "irreversible write operation." After determining it to be irreversible, the permission decision engine sets the initial execution permission to "disallow" and marks it as high risk, sending a permission notification to the client for confirmation. Once the user confirms, the operation is allowed. However, if the LLM agent calls the "a" tool to read a configuration file, the operation's reversibility label is "read-only," and it is determined to be non-irreversible. In this case, considering the decision results from static pre-authorization, semantic inference, and trust level assessment, the final execution permission is determined to be "allowed," and the target risk level is set to "low risk."

[0059] The tool invocation method provided in the embodiments of this specification introduces operation reversibility labeling as a pre-gating condition for permission decision-making. It forces additional manual confirmation for irreversible operations and determines the final target execution permission by combining multiple permission decision results for reversible operations. This achieves differentiated control over high-risk operations and avoids the crude authorization mode of "either all allowed or all blocked" in traditional solutions. It ensures system security while taking into account the execution efficiency of legitimate operations.

[0060] In one or more embodiments of this specification, corresponding permission decision results are obtained through decision-making methods such as static pre-authorization, semantic inference, and trust level assessment. The target execution permission and target risk level are then obtained by weighted fusion of these multiple permission decision results. Specific implementation methods are described below: Determining the target execution permission and the target risk level based on at least one permission decision result includes: The reversibility of the operation is matched with a predefined rule base to determine the first permission decision result; Analyze the dialogue context to determine the invocation intent, and determine the second permission decision result based on the invocation intent; The third permission decision result is determined based on the historical call records of the target tool and the accumulated trust score of the dialogue context; The first permission decision result, the second permission decision result, and the third permission decision result are weighted and fused to obtain the target execution permission and the target risk level.

[0061] Among them, the predefined rule base can be understood as a set of pre-configured static authorization rules, which are used to quickly match and determine tool calls of specific types or specific identifiers; the first permission decision result can be understood as the permission determination result obtained based on the rule base matching; the call intent can be understood as the user's real operation purpose inferred from the dialogue context through semantic analysis, such as distinguishing between the two essentially different intents of "deleting temporary files" and "deleting system files".

[0062] The second permission decision result can be understood as the permission judgment result derived from the semantic analysis of the calling intent; the historical call record can be understood as the target tool's success rate, failure rate, and whether any exceptions were triggered during past executions; the cumulative trust score can be understood as a credit score dynamically calculated based on the tool's historical execution performance and current session interaction behavior. The trust level of the tool is lower when it is called for the first time, and the trust level gradually increases after multiple successful executions.

[0063] The third-level permission decision result can be understood as the permission judgment result based on the trust level assessment; weighted fusion can be understood as the comprehensive calculation of the permission judgment results of multiple independent decision-making mechanisms according to their respective weights, and the fusion weight can be dynamically adjusted.

[0064] Specifically, when determining the target execution permissions and target risk level, if the operation reversibility is marked as non-irreversible, the permission decision engine will use three independent decision mechanisms to determine the weights and perform a weighted fusion of the outputs of each decision mechanism.

[0065] The first decision-making mechanism is static pre-authorization. In practice, the reversibility of operations in the tool profile is matched with a predefined rule base, such as "read-only operations are allowed by default" and "irreversible operations are blocked by default", to obtain the first permission decision result.

[0066] The second decision-making mechanism is semantic inference. In practice, semantic analysis is performed on the dialogue context to extract the true intent behind the tool call. For example, it identifies whether the user is performing routine maintenance or a high-risk system change, and determines the second permission decision based on the risk level of the intent. In practical applications, task objective descriptions, historical operation sequences, and current working directory information from the dialogue context can be used as input features. Semantic analysis determines the operation intent category and risk level of the tool call instruction. The operation intent categories include at least read-only analysis, file modification, and system change categories; different operation intent categories correspond to different permission constraint strategies.

[0067] The third decision-making mechanism is trust level assessment. In practice, it queries the target tool's historical call records (success rate, whether any exceptions have been triggered), combines this with the accumulated trust score in the current session, and comprehensively assesses execution permissions to obtain the third permission decision result. For example, tools with high success rates receive higher trust levels and relatively more lenient permission restrictions, while tools that are experiencing exceptions for the first time or have historically triggered exceptions have lower trust levels and stricter execution restrictions. In practical applications, each tool maintains a corresponding trust score value. This trust score value is determined based on the tool's historical execution success rate, exception trigger frequency, and cumulative call count. When the trust score value exceeds a preset upgrade threshold, the tool's permission level can be automatically upgraded; when the trust score value is below a preset downgrade threshold, the tool's permission level is automatically downgraded or a manual review process is triggered.

[0068] The three permission decision results are weighted and fused together. The fusion weight can be dynamically adjusted according to the accuracy of each mechanism over a period of time. Finally, a unified target execution permission (pass or fail) and target risk level (low risk, medium risk, high risk) are output.

[0069] It should be noted that when a tool call command is identified as an irreversible operation, regardless of the fusion result of the above three permission decision mechanisms, an additional confirmation process will be forcibly triggered. Irreversible operations include file deletion operations, database write operations, and system configuration modification operations, etc., which are not limited here.

[0070] In practical applications, the permission decision results output by each decision-making mechanism are normalized scores. Therefore, by weighted fusion of the three scores, the final target score can be obtained. For example, if the target score is less than 0.6, the target execution permission is determined to be "not approved" and the target risk level is high risk. If the target score is greater than 0.6 and less than 0.8, the target execution permission is determined to be "approved" and the target risk level is medium risk. If the target score is greater than 0.8, the target execution permission is determined to be "approved" and the target risk level is low risk.

[0071] The tool invocation method provided in the embodiments of this specification overcomes the limitations of traditional single-dimensional permission determination by weightedly integrating three independent decision-making mechanisms: static rule matching, semantic intent inference, and dynamic trust assessment. Through the collaborative decision-making of multiple mechanisms, the same tool can obtain differentiated permission decisions in different invocation scenarios.

[0072] Step 106: If the target execution permission is granted, determine the target isolation level based on the target risk level, and construct the target execution environment corresponding to the target isolation level.

[0073] Among them, the target execution permission can be understood as the authorization result finally determined by the permission decision engine, with a value of "pass" or "fail"; the target risk level can be understood as the security risk level classification output by the permission decision engine, including low risk, medium risk, and high risk levels.

[0074] The target isolation level can be understood as the granularity of execution environment isolation dynamically selected based on the level of operational risk. This includes lightweight process isolation (suitable for low-risk read-only operations), virtual environment isolation (suitable for medium-risk reversible write operations), and complete container-level isolation (suitable for high-risk irreversible operations). The build process can be understood as the automated creation of a matching execution environment instance based on the environment dependency declarations in the tool profile through an environment factory. The target execution environment can be understood as a ready runtime environment specifically prepared for this tool call, including the correct dependency versions, environment variable configurations, and resource limitations that meet the isolation level requirements.

[0075] Specifically, when the permission decision engine determines that the target's execution permission is "granted," it selects a matching target isolation level from multiple isolation granularities supported by the environment factory based on the target's risk level. In practice, the lower the risk level, the lighter the isolation method is selected to reduce startup overhead; the higher the risk level, the stricter the isolation method is selected to enhance security.

[0076] For example, in this embodiment, low-risk read-only tools use lightweight process isolation (millisecond-level startup), medium-risk reversible write tools use virtual environment isolation, and high-risk irreversible tools use full container-level isolation. The same tool may obtain different isolation levels in different calling contexts.

[0077] Once the target isolation level is determined, the environment factory can automatically build the target execution environment corresponding to that target isolation level based on the environment dependency declarations (including runtime dependencies, library versions, system components, environment variable requirements, etc.) in the tool profile.

[0078] In the embodiments of this specification, the environment dependency declaration in the tool profile is used as input, and a large language model is used to assist in deriving the complete environment configuration specification (including compatible dependency version combinations, necessary system libraries, environment variable settings, etc.), without the need for manual configuration file writing.

[0079] In practical applications, frequently used tools can have their execution environment instances pre-built and persistently cached. When a tool call request arrives, a ready execution environment instance is retrieved directly from the cache pool, eliminating the cold start delay of environment building. The number of execution environment instances in the cache pool (also known as the warm-up pool) can be automatically adjusted according to the historical call frequency of the tool. For example, high-frequency tools maintain multiple warm-up execution environment instances, while low-frequency tools build execution environment instances as needed.

[0080] For example, when an LLM agent calls the "static-analyzer" read-only analysis tool, the permission decision engine outputs that the target execution permission is "passed" and the target risk level is "low risk". In this case, "lightweight process isolation" is selected as the target isolation level based on the low risk level.

[0081] The environment factory queries the tool's profile to obtain the environment dependency declaration (requires Python 3.8+ and py dependency libraries), retrieves the cached Python 3.9 runtime environment instance from the preheating pool, injects environment variables and dependency paths into a lightweight subprocess, and completes the construction of the target execution environment.

[0082] The tool invocation method provided in the embodiments of this specification achieves differentiated isolation protection for the same tool in different invocation scenarios by dynamically associating risk level with isolation level. Based on the tool profile, the target execution environment can be automatically deduced and constructed using a large language model, eliminating the burden of manually writing environment configuration files. Furthermore, the preheating pooling reuse mechanism further reduces the environment preparation delay for high-frequency tool invocation.

[0083] In one or more embodiments of this specification, a preheating pooling reuse mechanism is used to achieve rapid construction of the target execution environment. The specific implementation method is as follows: Constructing the target execution environment corresponding to the target isolation level includes: The execution environment instance corresponding to the target tool and the target isolation level is searched in the target cache, wherein the execution environment instance in the target cache is updated according to the tool profile of the corresponding tool; If found, the execution environment instance corresponding to the target tool and the target isolation level is determined as the target execution environment; If no information is found, the environment dependency information in the tool profile is input into the data processing model to obtain the environment configuration specifications corresponding to the environment dependency information. Based on the environment configuration specifications, construct the target execution environment for the target isolation level.

[0084] The target cache can be understood as a high-speed cache storage area used to pre-create and store execution environment instances, which is used to eliminate the cold start delay of environment building; the execution environment instance can be understood as a runtime environment unit that has been built and is in a ready state and can be directly used for tool invocation, containing the correct dependency versions, environment variable configurations and isolation resource limits.

[0085] Environment dependency information can be understood as the set of runtime dependencies declared in the tool profile, including dependency library versions, system components, environment variable requirements, etc.; the data processing model can be understood as a large language model used to automatically deduce the complete environment configuration specification from the dependency information, and to use its knowledge capabilities to generate compatible dependency version combinations, necessary system library lists, and environment variable settings; the environment configuration specification can be understood as a complete parameter description required to build the execution environment, including dependency version combinations, system library lists, environment variable key-value pairs, and isolated resource configurations, etc.

[0086] Specifically, when constructing the target execution environment corresponding to the target isolation level, the system first checks the target cache to see if a corresponding execution environment instance exists based on the tool identifier of the target tool and the target isolation level. If a matching execution environment instance is successfully found in the target cache, the instance is directly identified as the target execution environment without needing to be reconstructed.

[0087] If not found, environment dependency information (i.e., the environment dependency declaration in the above embodiment) is extracted from the tool profile. This environment dependency information is then input into the data processing model (i.e., the large language model), which automatically derives a complete environment configuration specification, including compatible dependency version combinations, necessary system libraries, environment variable settings, etc. Subsequently, the environment factory constructs a new execution environment instance as the target execution environment based on this environment configuration specification and according to the target isolation level (lightweight process isolation, virtual environment isolation, or container-level isolation). After construction, this execution environment instance can be optionally stored in the target cache for reuse in subsequent identical requests.

[0088] It should be noted that the execution environment instances stored in the target cache are incrementally updated according to changes in the tool profile of the corresponding tool. That is, when the version information or environment dependencies in the tool profile change, the corresponding execution environment instances in the target cache are kept in sync through differential updates.

[0089] The tool invocation method provided in the embodiments of this specification effectively reduces the environment preparation delay for high-frequency tool invocation by prioritizing the reuse of already built execution environment instances through target caching, avoids the overhead of repeated construction, and automatically derives the complete configuration specification from environment dependency information using a large language model, replacing the traditional method of manually writing configuration files. This achieves automated environment construction with zero human intervention and can effectively improve data processing efficiency.

[0090] Step 108: Invoke the target tool in the target execution environment, execute the target task corresponding to the tool invoking instruction, obtain the execution result, and return the execution result to the intelligent processing unit.

[0091] The target task can be understood as the specific operation described in the tool invocation instruction that needs to be completed by the target tool, such as code formatting, file reading, compilation and building, etc., without being limited here. The execution result can be understood as the information output by the target tool after it has run in the target execution environment, including success status, returned data, time consumed, resource consumption, and possible error messages.

[0092] Specifically, once the target execution environment is built and the permission decision is approved, the target tool is invoked within that environment, and the target task corresponding to the tool's invocation instructions is executed. By running the target tool in an isolated target execution environment, all its operations (including file reading and writing, network access, subprocess invocation, etc.) are constrained by the target isolation level.

[0093] After the target tool completes execution, the output information generated during the execution process is collected. In fact, the collected raw output is converted into a structured execution result format (such as a structured object containing success flags, data payloads, and metadata), and the structured execution result is returned to the intelligent processing unit that initiated the call for subsequent reasoning and processing.

[0094] For example, the LLM agent calls the "static-analyzer" tool to perform code quality analysis on the project directory. In a lightweight process isolation execution environment, the static-analyzer tool is called to execute the command "abcd" to obtain the raw output. This raw output is then converted into a structured execution result. When the structured execution result is returned to the LLM agent, the LLM agent can directly use the structured execution result to generate subsequent code repair suggestions without parsing the raw command line output, thereby reducing the token consumption required for the model to parse the raw output.

[0095] The tool invocation method provided in the embodiments of this specification ensures the security and environmental consistency of the tool execution process by invoking the target tool in an isolated execution environment, avoids inter-tool dependency conflicts and impacts on the host system, and returns structured execution results to the intelligent processing unit, reducing the token consumption required for the intelligent processing unit to parse the original tool output, thereby improving the overall task execution efficiency.

[0096] In one or more embodiments of this specification, if the tool needs to access the file system (reading input files, writing output results, and manipulating temporary files) during execution, the file operation request is handled using the file system abstraction layer, instead of directly calling the underlying operating system's file interface. Specific implementation methods are described below: In the target execution environment, the target tool is invoked to execute the target task corresponding to the tool invocation instruction, and the execution result is obtained, including: When the target tool is invoked to access the target file system, the file operation request is sent to the file system abstraction layer, wherein the file system abstraction layer uses semantic-level file operation primitives to convert the access instructions in the file operation request into primitive instructions corresponding to the target file system. The target file system capability description registry is queried, and operation instructions corresponding to the target file system are generated based on the primitive instructions and the capability description registry. The operation on the target file system is completed according to the operation instructions, and the execution result is obtained.

[0097] The target file system can be understood as the specific storage backend pointed to by the file operation in the tool call command, including local file system, cloud object storage, distributed file system or browser sandbox file system, etc.; the file system abstraction layer can be understood as an independent intermediate layer located between the intelligent agent and the underlying heterogeneous file system, responsible for shielding the interface differences of different file systems and providing a unified file operation entry point.

[0098] Semantic file operation primitives can be understood as a set of standardized file operation interfaces that are independent of the operating system and file system type, including but not limited to path resolution, file reading, file writing, directory traversal, file search, permission query, metadata retrieval, file moving / copying / deleting, etc.

[0099] The capability description registry can be understood as a structured set of metadata maintained for each type of file system that has been connected. It records information such as the set of operations supported by the file system (e.g., object storage does not support directory traversal, some sandbox file systems do not support symbolic links), performance characteristics (millisecond latency for local file systems, hundreds of milliseconds latency for cloud storage), capacity limits (maximum single file size, maximum path length), permission model type, atomicity guarantees (whether atomic renaming and transactional writes are supported), and versioning capabilities (whether file version history is supported). When selecting a file operation strategy, the capability description registry is queried to avoid generating operation instructions that the target file system does not support. Operation instructions can be understood as specific commands that, after being converted by the adapter, can be directly executed on the target file system.

[0100] Specifically, when the target tool is invoked to execute the target task in the target execution environment, if the target tool needs to access the file system (reading input files, writing output results, operating on temporary files, etc.), all file operation requests are first sent to the file system abstraction layer for processing.

[0101] After receiving a file operation request, the file system abstraction layer uses semantic-level file operation primitives to convert the access instructions in the file operation request (such as "read project configuration file") into standardized primitive instructions. Then, the lower-level adapter further converts them into operation instructions corresponding to the target file system. Cross-platform portability is achieved through a two-level translation mechanism.

[0102] By querying the target file system's capability description registry, we obtain characteristic information such as the types of operations supported by the target file system, permission models, and path length limits. Based on the converted primitive instructions and the capability descriptions found in the capability description registry, we determine whether the operation corresponding to the primitive instruction is supported by the target file system. If supported, we generate specific operation instructions that match the target file system, and then perform the actual operation on the target file system according to the generated operation instructions to obtain the execution result.

[0103] In practical applications, the file system abstraction layer also includes a path semantic normalization engine. This engine is responsible for uniformly converting path representations from different operating systems and file systems into the system's internal standardized path format. Specific processing includes: path separator normalization (converting path separators from different operating systems into the system's internal standardized format), case sensitivity adaptation (handling path matching according to the target file system's case sensitivity policy), path encoding standardization (handling filenames with different character sets), path length compliance checking (verifying and truncating path lengths according to the target file system's path length limits), symbolic link resolution policy adaptation, and mapping cloud storage path bucket / key formats to a unified path format. The normalization results are cached to avoid redundant conversion overhead.

[0104] The tool invocation method provided in the embodiments of this specification, through a two-level translation mechanism and pluggable adapter architecture of the file system abstraction layer, enables the target tool's file operations to automatically complete cross-platform adaptation at runtime without being aware of the path format differences of the underlying operating system and the capability boundaries of the file system. The capability description registry provides decision references for the generation of operation instructions, avoiding execution failures caused by generating operation instructions that are not supported by the target file system. By doing so, the file system difference problem that traditional solutions require multiple rounds of interaction is brought forward to the abstraction layer for transparent processing, reducing the reasoning burden and token consumption of the agent.

[0105] In one or more embodiments of this specification, when the file system abstraction layer receives a file operation request, it converts the access instructions in the request into standardized primitive instructions. If it determines that the instruction permissions corresponding to the primitive instructions are valid, it uses an adapter to convert the primitive instructions into operation instructions corresponding to the target file system. Specific implementation methods are described below: The generation of operation instructions corresponding to the target file system includes: If it is determined that the instruction permission corresponding to the primitive instruction is passed, the target adapter of the target file system is invoked to convert the primitive instruction into the operation instruction corresponding to the target file system.

[0106] Here, primitive instructions can be understood as standardized intermediate representations generated after mapping natural language access instructions or high-level operation descriptions in file operation requests to semantic-level file operation primitives; instruction permissions can be understood as the authorization determination result performed before executing primitive instructions, with values ​​of "pass" or "fail".

[0107] The target adapter can be understood as a pluggable conversion module implemented in the file system abstraction layer for a specific file system type (such as local file system, cloud object storage, distributed file system, etc.), responsible for converting standard primitive instructions into specific operation instructions that the file system can recognize; operation instructions can be understood as call commands or requests that the underlying target file system can directly execute.

[0108] Specifically, after receiving a file operation request, the file system abstraction layer first performs semantic parsing on the access instructions in the request, mapping them to the corresponding primitives in the semantic-level file operation primitive set, and generating standardized primitive instructions. After generating the primitive instructions, the file system abstraction layer sends the primitive instructions to the permission decision engine for linkage authorization determination, judging whether the file operation corresponding to the primitive instructions is allowed to be executed under the current dialogue context and path semantics.

[0109] Once the permissions corresponding to the primitive instruction are determined to be valid, the file system abstraction layer routes and invokes the corresponding target adapter from the set of pluggable adapters, based on the type of the target file system (local file system, cloud object storage, distributed file system, etc.). After receiving the standardized primitive instruction, the target adapter converts the primitive instruction into specific operation instructions that the target file system can directly execute, according to the target file system's interface specification, path format, permission model, and capability boundaries.

[0110] In this embodiment, the adapter pattern is adopted to convert unified primitive instructions into operation instructions for a specific file system. Each adapter is responsible for the operation translation of a type of file system backend. The access of a new file system type only requires implementing the standard adapter interface without modifying the upper-layer logic, thus reserving an expansion channel for new file systems that will emerge in the future.

[0111] It should be noted that when the instruction permission of the primitive instruction is not approved, a structured rejection reason is generated and fed back to the intelligent processing unit.

[0112] The tool invocation method provided in the embodiments of this specification introduces permission linkage judgment before primitive instruction conversion, deeply integrates the operation conversion of the file system abstraction layer with the permission decision engine, so that every file operation is authorized and verified based on dialogue context and path semantics before execution, and through the design of the file system adapter, it can achieve scalable adaptation of cross-platform file operations.

[0113] In one or more embodiments of this specification, upon obtaining the execution result, the tool profile of the target tool can be updated based on the execution result. Specific implementation methods are described below: After obtaining the execution result, it also includes: The tool profile of the target tool is updated using the execution results.

[0114] The execution result can be understood as the structured information output by the target tool after it has run in the target execution environment, including success status, returned data, execution time, resource consumption, and possible error information. The update can be understood as the process of writing the new data generated by this execution into the corresponding dimension of the tool profile, including appending historical call records, refreshing health status indicators, and adjusting trust level related parameters, etc., which are not limited here.

[0115] Specifically, after the target tool completes execution and obtains the execution result, the feedback update module uses the execution result as input to update the tool profile of the target tool. For example, in the health status dimension, it updates the tool's success rate statistics (such as recent execution success rate, average response time) based on the success or failure status of the execution result, and records the last failure information if a failure exists; in the version information dimension, if a version change or compatibility issue is detected during execution, the version record is updated; in the trust level related dimension, it dynamically adjusts the tool's historical trust score based on whether the execution was successful, whether an exception was triggered, or whether high-risk operations were involved but were handled correctly (successful execution increases the trust value, while failure or an exception decreases the trust value).

[0116] In terms of LLM adaptability, based on the actual output and structural characteristics of this execution, the statistical data such as the estimated token consumption and output resolvability score are updated, and the updated tool profile is persistently stored in the tool registry center for subsequent cross-session tool call queries and decision-making, so as to realize the cross-session accumulation and reuse of toolchain knowledge.

[0117] The tool invocation method provided in this embodiment realizes the dynamic accumulation and cross-session reuse of tool operation characteristics by writing back the execution result of each tool invocation to the tool profile. That is, through the continuous updating of the tool profile in this embodiment, queryable prior knowledge can be accumulated. Thus, when the same tool is invoked in a subsequent instance, information such as its health status, trust level, and compatibility characteristics can be directly obtained from the tool profile, thereby making more accurate preprocessing and permission decisions and avoiding the waste of resources caused by repeated problem handling.

[0118] See Figure 2 , Figure 2 The system architecture diagram corresponding to a tool invocation method provided in one embodiment of this specification is shown.

[0119] Specifically, the Large Language Model Agent (LLM Agent, as described in the above embodiments) is an autonomous task execution system capable of planning and invoking external tools to complete tasks. The tool invocation instructions it generates first enter the first-layer interceptor (the agent framework interceptor). This interceptor, located in the agent framework layer, is used to initiate a profile query to the tool registry center, carrying the dialogue context.

[0120] The tool registry maintains a structured tool profile database. Each tool profile includes basic dimensions (version information, environment dependencies, permission requirements, and health status) as well as LLM adaptability dimensions unique to this embodiment (token consumption estimation, output resolvability score, illusion risk level, context window friendliness, and operation reversibility annotation). In other words, in this embodiment, by querying the tool profile in the tool registry, the complete status of the tool can be obtained before it is actually invoked.

[0121] When the queried tool profile indicates that the tool is not in a ready state, the preprocessing process is automatically triggered. For example, if the version does not match, version alignment is performed (install or switch to a compatible version), if the path is unreachable, path rewriting is performed, and if the dependency is missing, dependency installation is triggered.

[0122] If the first-layer interceptor determines that the tool poses no security risk and the environment is ready, the command is allowed to proceed to the command execution layer, entering the second-layer interception (command execution layer pre-hook). This second-layer interception performs a final verification of the actual command to be executed, including verification of the actual binary path, runtime parameter security checks, and execution environment variable verification. These two layers of interception form a collaborative protection mechanism that combines semantic-level and system-level measures. This dual-layer collaborative mechanism overcomes the limitations of traditional command-line verification, which can only detect the existence of the tool and cannot verify version compatibility or runtime dependencies.

[0123] The permission decision engine simultaneously activates four independent decision mechanisms. The outputs of different decision mechanisms can be weighted and fused to determine the final target execution permission and target risk level. Specifically, the four decision mechanisms include static pre-authorization (fast matching based on a predefined rule base. For example, "read-only file viewing tools" are allowed by default), dialogue context semantic inference (using the current dialogue context as input and using semantic analysis capabilities to infer the true intent and potential risks of this call. For example, if "the user is conducting code review" is identified from the dialogue, the code analysis tool is allowed, but if a deletion operation is identified from "cleaning up disk space", the risk level is increased), trust level assessment (based on the tool's historical call records (success rate, whether any exceptions have been triggered) and the cumulative trust score of the current session. The trust level of the tool is lower and the execution restrictions are stricter on the first call; the trust level increases after multiple successful executions, and the restrictions are gradually relaxed), and irreversible operation risk gating (for operations identified as irreversible (such as file deletion, database writing, system configuration modification), an additional confirmation process is forcibly triggered regardless of the scores of the other three mechanisms).

[0124] After determining permissions and risk levels, the corresponding isolation level environment is constructed. Specifically, the environment factory module automatically constructs a matching execution environment based on the environment dependency declarations in the tool profile, aided by a large language model.

[0125] In practical applications, the dependency list in the tool profile is used as input, and the knowledge capabilities of the large language model are used to automatically derive the complete environment configuration specifications (including compatible dependency version combinations, necessary system libraries, environment variable settings, etc.), without the need for manual configuration file writing.

[0126] Based on the target risk level output by the permission decision engine, an appropriate isolation granularity is dynamically selected, allowing the same tool to potentially obtain different isolation levels in different invocation contexts. To reduce latency, in this embodiment, frequently used tools pre-build and persistently cache their execution environment instances. When a tool invocation request arrives, a ready environment instance is directly retrieved from the cache pool, eliminating the cold start latency of environment building. The cache pool automatically adjusts the number of pre-warmed instances based on the tool's historical invocation frequency; for example, multiple pre-warmed instances are maintained for high-frequency tools, while low-frequency tools are built on demand.

[0127] When a tool profile changes due to feedback updates (such as version upgrades or added dependencies), the environment factory does not rebuild the entire environment. Instead, it incrementally updates the cached environment instance based on the differential changes, further reducing environment preparation overhead. After the execution environment executes the target task corresponding to the tool invocation command and the execution is complete, the feedback update module writes the execution result (success / failure, time consumption, resource consumption, and error messages) back to the tool registry, updating the corresponding tool's profile data. Simultaneously, the structured execution result (rather than the raw command-line output) is fed back to the large language model, reducing the token consumption required for the model to parse the raw output.

[0128] For example, when the LLM agent performs a code quality analysis task, it generates an instruction to call a static analysis tool. The first-layer interceptor parses the tool identifier as "static-analyzer" and extracts the target code directory path as the parameter. It queries the registry and finds that the tool is registered, but the currently installed version is v2.1, while the profile indicates a compatible version range of v3.0+ (due to the target code using new syntax features). An automatic version upgrade process is triggered, upgrading the tool from v2.1 to v3.2 (the latest stable version within the compatibility range), and simultaneously installing its two newly added runtime dependencies. The permission decision engine's fusion result is to allow the process (e.g., static pre-authorization rule matching is "read-only analysis tool, default allow"; semantic inference identifies the current context as "code review task," low risk; trust level is "high" (this tool has a historical success rate of 98%); no irreversible operations). The environment factory retrieves the tool's cached environment instance from the preheating pool, injects the updated dependencies, and executes the analysis in an isolated environment. Upon successful execution, a structured execution result is obtained and fed back to the LLM agent, while simultaneously updating the health and version information in the profile.

[0129] Therefore, compared to existing methods that go through a cycle of "call - version incompatibility error - error analysis - attempt to upgrade - missing dependency - re-analysis - install dependency - retry", the method provided in this specification's embodiments can be expected to consume 4-6 additional rounds of interaction and thousands of tokens.

[0130] In practical applications, tools may need to access the file system during execution. However, large language models generate file operation commands based on knowledge of mainstream operating systems from their training corpus. In reality, deployment environments may run on different operating systems (Windows, Mac, Linux) and different file system types (local file systems, cloud storage, sandbox file systems, etc.). Large language models cannot perceive the differences in file system characteristics of the target environment. This leads to agents frequently generating incompatible file operation commands in cross-platform scenarios, causing numerous path resolution errors and permission denial anomalies. Each failure requires additional tokens for error analysis and command rewriting. More seriously, for new storage backends such as cloud storage, distributed file systems, and browser sandbox file systems, the model's training knowledge is almost entirely lacking, resulting in incorrect resolution of file dependencies called by the tool.

[0131] Therefore, in this embodiment, the tool execution module integrates a file system abstraction layer to provide a unified file system read / write interface. The file system abstraction layer in this embodiment can parse specific file paths and operation types from natural language descriptions such as "read project configuration files," achieving semantic-level file system access.

[0132] In other words, when a tool needs to access the file system during execution (reading input files, writing output results, operating on temporary files, etc.), all file operation requests are handled through the Unified File System Abstraction Layer (Agent FS), rather than directly calling the underlying operating system's file interface.

[0133] Agent FS, acting as an independent intermediary layer between the agent and the underlying heterogeneous file system, implements a two-level translation mechanism of "semantic instruction - standard primitive - specific call" through a semantic-level file operation primitive set. This makes the agent's file operation instructions inherently cross-platform portable. Through a path semantic normalization engine, it unifies the path representations of different operating systems and file systems into the system's internal standardized path format. By describing the registry through file system capabilities, it avoids generating operation instructions that the target file system does not support. Through a pluggable file system adapter architecture, it converts the unified file operation primitives into specific file system implementations. Through deep integration with the permission decision engine, it ensures that each file operation is authorized and determined by the permission decision engine before execution.

[0134] The linkage mechanism includes: using file operation path information and operation type (read-only / reversible write / irreversible deletion) as input features for permission decisions, and participating in multi-mechanism fusion decision-making together with the semantic context of the dialogue; directly inputting the reversibility label of file operations into the risk gate for irreversible operations (e.g., permanent file deletion is an irreversible operation, triggering mandatory confirmation); distinguishing risk levels based on the semantic analysis of file paths, such as deleting cache files in the project's temporary directory as low risk, and modifying configuration files in the system's critical directories as high risk; and converting permission models of different file systems such as cloud storage and distributed file systems into a unified permission description format through the adapter layer, and incorporating them into the evaluation scope of the permission decision engine.

[0135] For example, an LLM agent in a Windows environment performs a code build task originally developed for Linux. This task involves reading the / src / config / app.yaml configuration file and writing the compilation output to the / dist / output / directory, while also backing up the build artifacts to cloud object storage.

[0136] Specifically, the first-layer interceptor identifies the file operations "read configuration file" and "write compilation output" contained in the tool call command, and simultaneously parses the backup target as a cloud storage path. Agent FS's path normalization engine detects that it is currently running on a Windows operating system and automatically converts the POSIX path format in the command to the Windows path format ( / src / config / app.yaml -> C:\project\src\config\app.yaml), handling case-insensitive path matching. For the cloud storage path, it is mapped to a unified internal format of "bucket name / key path".

[0137] Query the file system capability description registry to confirm that the local NTFS supports all required operations (read, write, directory creation); confirm that the target cloud storage adapter supports write operations but does not support atomic renaming (use the equivalent strategy of "write temporary key + copy + delete" instead).

[0138] File operation permissions were determined through a multi-mechanism fusion decision: semantic inference identified it as "normal file read and write in code build tasks," indicating low risk; path analysis confirmed that the operation scope was limited to the project directory and the specified cloud storage bucket, with no access to critical system directories; and reversibility was marked as "reversible write operation." The fusion permission decision result was determined to allow the operation.

[0139] Local file read / write operations are performed through the NTFS adapter; cloud storage backups are performed through the object storage adapter. The two adapters work in parallel, each handling the differences in the underlying file system details. Upon successful execution, the structured results returned to the LLM include the execution status of each file operation, and the path normalization cache is updated to accelerate subsequent similar operations.

[0140] Without Agent FS, executing the Linux path generated by the model directly on Windows will result in a path not found error. The model needs multiple rounds of interaction to understand the differences in path format and correct them one by one. Cloud storage backup operations require the model to infer a completely different API call method, which is expected to consume 3-5 additional rounds of interaction.

[0141] The system architecture corresponding to this tool invocation method significantly improves the success rate of tool invocation and reduces invalid token consumption by 20%-40%. Compared with the traditional command-line verification combined with retry mechanism, this embodiment no longer relies on blind retries, but performs precise repair based on the information of the tool profile; compared with static whitelist / blacklist permission control, this embodiment can dynamically adjust permission boundaries according to the invocation context.

[0142] See Figure 3 , Figure 3 This diagram illustrates the processing flow of a tool invocation method provided in one embodiment of this specification.

[0143] The LLM agent generation tool invokes commands, entering the first layer of interception (agent framework layer). This layer performs operations such as parsing the tool name and parameters, querying the tool registry center, and determining whether the tool is registered. For registered tools, the system obtains a tool profile (including basic dimensions and LLM compatibility dimensions) and performs a readiness check. If the tool is in an inready state (e.g., version mismatch, missing dependencies), the system automatically triggers preprocessing operations. In fact, traditional command-line verification can only detect the existence of the tool, but cannot verify version compatibility, and can only rely on the model to blindly retry after failure; while this embodiment, through profile query and preprocessing mechanism, proactively solves problems such as version alignment and dependency installation before invocation, transforming "retry after the fact" into "prevention before the fact".

[0144] After passing the readiness check, the system enters the multi-mechanism permission fusion decision-making stage, which simultaneously activates four independent decision-making mechanisms: static pre-authorization (fast matching based on the rule base), semantic inference (parsing the calling intent and risk level from the dialogue context), historical trust level assessment (dynamic scoring based on the tool's historical execution performance), and irreversible operation risk gating.

[0145] It should be noted that when an operation is marked as irreversible (such as file deletion or database writing), an additional confirmation process will be forcibly triggered regardless of the scores of the other three mechanisms.

[0146] The target execution permission is determined by the fused decision results. In fact, existing methods make static judgments based on predefined structured attributes and lack the ability to understand the semantic context of natural language dialogue. However, the semantic inference in this embodiment introduces context awareness, which enables the same tool to obtain different permission decisions in different contexts, realizes the dynamics of the "principle of least privilege", and overcomes the rigidity of static lists.

[0147] After the permission decision is approved, the system enters the second layer of interception, where the actual system command to be executed is finally verified, including: verification of the actual binary path, security checks of runtime parameters, and verification of execution environment variables, etc., which are not limited here.

[0148] Specifically, the environment is validated, which is the environment factory stage. Based on the environment dependency declarations in the tool profile, the environment factory automatically constructs a matching execution environment with the assistance of LLM, and dynamically selects the target isolation level according to the risk level, so as to execute the target task corresponding to the tool invocation instruction in the target execution environment of the target isolation level.

[0149] It should be noted that when the target tool is not registered, a cold start is enabled, meaning it is allowed to proceed directly. The target task corresponding to the tool's invocation instruction is executed within the target execution environment at the target isolation level, and a tool profile is collected based on the execution results. Specifically, during execution, information such as the target tool's runtime environment, dependencies, and execution characteristics is collected. Based on this collected information, initial profile data for the target tool is automatically generated and written to the tool registry. This implements a "allow first, collect later" strategy for unregistered tools, ensuring the system's openness to new tools. Simultaneously, by automatically generating a profile based on the initial execution results, management capabilities are gradually accumulated.

[0150] When file operations are involved during tool execution, all requests pass through the Unified File System Abstraction Layer (AgentFS). Specifically, a series of operations are performed (supporting local file systems, cloud object storage, distributed file systems, sandboxed file systems, versioned file systems, etc.) to obtain the execution result. These operations include path semantic normalization (unifying path formats across operating systems), querying the file system capability description registry, file operation permission decision-making (linking with the permission engine), adapter routing (selecting the matching file system driver), and adapter execution. In fact, the file system adapter has a pluggable architecture, so the access of new file system types only requires implementing the standard adapter interface and registering the capability description in the file system capability description registry, without modifying the upper-layer abstract logic.

[0151] Among them, the path semantic normalization engine automatically completes cross-platform path conversion at runtime, the file system capability description registry provides decision reference information for the agent to avoid generating incompatible operations, and the pluggable adapter architecture supports zero-modification access to new file system types.

[0152] In the embodiments described in this specification, a unified file system abstraction layer is used to eliminate the burden on the agent to inform about the differences between the underlying operating system and file system. It eliminates the need to handle low-level adaptation details such as path format conversion and permission model mapping during inference, thereby reducing token consumption. Furthermore, the pluggable adapter architecture allows the system to access new file systems without modifying any upper-layer logic. The file system abstraction layer includes a file system capability description registry, which serves as an intermediary between the agent and the underlying storage, enabling the agent to make correct file operation decisions without understanding the implementation details of the underlying file system.

[0153] After execution, the feedback update module feeds back the structured execution results (rather than the raw command line output) to the LLM agent, while updating the health status and trust level in the tool profile. The structured feedback reduces the token consumption required for the model to parse the raw output, while the cross-session update of the tool profile allows toolchain knowledge to be accumulated and reused. That is, the same problem will no longer consume resources repeatedly in different sessions, thus overcoming the shortcoming of existing technologies that "problem-solving experience cannot be accumulated".

[0154] The tool invocation method provided in the embodiments of this specification achieves a significant improvement in the success rate of tool invocation, a 20%-40% reduction in token consumption, fine-grained adaptive permission management, and seamless file operations across operating systems and file systems. Furthermore, from the first-layer interception profile query to the readiness status check, to the multi-mechanism permission fusion decision-making, to the specification derivation of the environment factory, and then to the feedback closed-loop profile update, each execution process achieves information sharing and collaborative decision-making through profiles, resulting in the collaborative effect of "significantly improving the success rate of tool invocation".

[0155] Corresponding to the above method embodiments, this specification also provides a tool invocation management system, including: The command interception module includes a first interception submodule and a second interception submodule. The first interception submodule is used to respond to the tool call instruction sent by the intelligent processing unit, obtain the tool identifier in the tool call instruction, and obtain the dialogue context. The second interception submodule is used to perform pre-execution verification on the system command corresponding to the tool call instruction before calling the target tool corresponding to the tool identifier and executing the target task corresponding to the tool call instruction in the target execution environment. The tool registry module is used to store the tool profiles of each tool. The permission decision module is used to determine the target execution permission and target risk level of the target tool based on the tool profile and the dialogue context. The tool profile is a structured data set describing the capabilities of the tool, and the tool profile has been pre-configured in the tool registry center. The execution environment management module is used to determine the target isolation level based on the target risk level and construct the target execution environment corresponding to the target isolation level; The feedback update module is used to send the execution result corresponding to the tool invocation command back to the tool registration center; The file system abstraction module is used to convert access instructions in a file operation request into primitive instructions corresponding to the target file system when the target tool is invoked to access the target file system.

[0156] Specifically, the first interception submodule is located at the agent framework layer and is used to parse tool call instructions and extract dialogue context information; the second interception submodule is located at the command execution layer and is used to perform pre-execution verification on the system commands corresponding to the tool call instructions. The tool registration center module actually maintains a tool profile database, which stores basic dimensional data (version information, environment dependency information, permission requirement information, and running status information) and large language model adaptability dimensional data (estimated model inference resource consumption, tool output parsability score, and operation reversibility annotation).

[0157] It should be noted that when determining the target execution permissions and target risk level of the target tool, the permission decision module will determine them based on the fusion result of at least two permission decision mechanisms. These at least two permission decision mechanisms include, but are not limited to, a semantic inference mechanism based on dialogue context information and a trust level assessment mechanism based on historical call records.

[0158] The feedback update module not only updates the execution results to the tool registry center, but also outputs structured execution results to the large language model agent.

[0159] The unified file system abstraction module, located between the execution environment management module and the underlying file system, specifically includes: a file operation primitive translation submodule, used to translate file operation requests into standard file operation primitives (i.e., primitive instructions) independent of the operating system and file system type; a path semantic normalization submodule, used to uniformly convert path representations of different operating systems and file systems into the system's internal standardized path format; a file system capability description registry, used to store capability characteristic metadata of each file system type; and a pluggable file system adapter group, used to convert the standard file operation primitives into specific calls of the target file system; furthermore, the unified file system abstraction module is linked with the permission decision module, and file operations are authorized and determined by the permission decision module before execution.

[0160] Corresponding to the above method embodiments, this specification also provides embodiments of a tool invocation device. Figure 4 A schematic diagram of a tool calling device according to one embodiment of this specification is shown. Figure 4 As shown, the device includes: The response module 402 is configured to respond to a tool invocation command sent by the intelligent processing unit, obtain the tool identifier in the tool invocation command, and obtain the dialogue context; The determination module 404 is configured to obtain the tool profile of the target tool from the tool registry based on the tool identifier, and determine the target execution permission and target risk level of the target tool based on the tool profile and the dialogue context. The tool profile is a structured data set describing the capabilities of the tool, and the tool profile has been pre-configured in the tool registry. The construction module 406 is configured to determine the target isolation level based on the target risk level and construct the target execution environment corresponding to the target isolation level when the target execution permission is granted. The acquisition module 408 is configured to invoke the target tool in the target execution environment, execute the target task corresponding to the tool invocation instruction, obtain the execution result, and return the execution result to the intelligent processing unit.

[0161] The device further includes: The preprocessing module is configured to perform a preprocessing operation on the target tool to adjust its state to a ready state when the target tool is determined to be in an unready state based on the tool profile.

[0162] Optionally, the determining module 404 is further configured to: Based on the tool profile and the dialogue context, determine the operation reversibility label corresponding to the tool invocation command; Determine whether the reversibility flag of the operation is irreversible. If so, determine that the initial execution permission is denied and the target risk level is high, send a permission notification to the client, and if the client returns an authorization response corresponding to the permission notification, determine that the target execution permission is granted. If not, the target execution permission and the target risk level are determined based on at least one permission decision result.

[0163] Optionally, the determining module 404 is further configured to: The reversibility of the operation is matched with a predefined rule base to determine the first permission decision result; Analyze the dialogue context to determine the invocation intent, and determine the second permission decision result based on the invocation intent; The third permission decision result is determined based on the historical call records of the target tool and the accumulated trust score of the dialogue context; The first permission decision result, the second permission decision result, and the third permission decision result are weighted and fused to obtain the target execution permission and the target risk level.

[0164] Optionally, the building module 406 is further configured to: The execution environment instance corresponding to the target tool and the target isolation level is searched in the target cache, wherein the execution environment instance in the target cache is updated according to the tool profile of the corresponding tool; If found, the execution environment instance corresponding to the target tool and the target isolation level is determined as the target execution environment; If no information is found, the environment dependency information in the tool profile is input into the data processing model to obtain the environment configuration specifications corresponding to the environment dependency information. Based on the environment configuration specifications, construct the target execution environment for the target isolation level.

[0165] Optionally, the obtaining module 408 is further configured to: When the target tool is invoked to access the target file system, the file operation request is sent to the file system abstraction layer, wherein the file system abstraction layer uses semantic-level file operation primitives to convert the access instructions in the file operation request into primitive instructions corresponding to the target file system. The target file system capability description registry is queried, and operation instructions corresponding to the target file system are generated based on the primitive instructions and the capability description registry. The operation on the target file system is completed according to the operation instructions, and the execution result is obtained.

[0166] Optionally, the obtaining module 408 is further configured to: If it is determined that the instruction permission corresponding to the primitive instruction is passed, the target adapter of the target file system is invoked to convert the primitive instruction into the operation instruction corresponding to the target file system.

[0167] The device further includes: The update module is configured to update the tool profile of the target tool using the execution results.

[0168] The above is an illustrative scheme of a tool calling device according to this embodiment. It should be noted that the technical solution of this tool calling device and the technical solution of the tool calling method described above belong to the same concept. For details not described in detail in the technical solution of the tool calling device, please refer to the description of the technical solution of the tool calling method described above.

[0169] Figure 5 A structural block diagram of a computing device 500 according to one embodiment of this specification is shown. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 550 is used to store data.

[0170] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0171] In one embodiment of this specification, the above-described components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0172] The computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 500 can also be a mobile or stationary server.

[0173] The processor 520 is used to execute the following computer program / instruction, which, when executed by the processor, implements the steps of the above-described tool invocation method.

[0174] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the computing device embodiments are basically similar to the tool invocation method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the tool invocation method embodiments.

[0175] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the above-described tool invocation method.

[0176] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the computer-readable storage medium embodiments are relatively simple in description because they are fundamentally similar to the tool invocation method embodiments; relevant parts can be referred to in the description of the tool invocation method embodiments.

[0177] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described tool invocation method.

[0178] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the tool invocation method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the tool invocation method described above.

[0179] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0180] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0181] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0182] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0183] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A tool invocation method, comprising: In response to a tool invocation command sent by the intelligent processing unit, the tool identifier in the tool invocation command is obtained, and the dialogue context is obtained; The tool profile of the target tool is obtained from the tool registry based on the tool identifier. The target execution permission and target risk level of the target tool are determined based on the tool profile and the dialogue context. The tool profile is a structured data set describing the capabilities of the tool and has been pre-configured in the tool registry. If the target execution permission is granted, the target isolation level is determined based on the target risk level, and a target execution environment corresponding to the target isolation level is constructed. The target tool is invoked in the target execution environment to execute the target task corresponding to the tool invocation instruction, obtain the execution result, and return the execution result to the intelligent processing unit.

2. The method of claim 1, before determining the target execution permission and target risk level of the target tool based on the tool profile and the dialogue context, further comprising: If the target tool is determined to be in a non-ready state based on the tool profile, a preprocessing operation is performed on the target tool to adjust its state to a ready state.

3. The method as described in claim 1, wherein determining the target execution permission and target risk level of the target tool based on the tool profile and the dialogue context includes: Based on the tool profile and the dialogue context, determine the operation reversibility label corresponding to the tool invocation command; Determine whether the reversibility flag of the operation is irreversible. If so, determine that the initial execution permission is denied and the target risk level is high, send a permission notification to the client, and if the client returns an authorization response corresponding to the permission notification, determine that the target execution permission is granted. If not, the target execution permission and the target risk level are determined based on at least one permission decision result.

4. The method of claim 3, wherein determining the target execution permission and the target risk level based on at least one permission decision result, includes: The reversibility of the operation is matched with a predefined rule base to determine the first permission decision result; Analyze the dialogue context to determine the invocation intent, and determine the second permission decision result based on the invocation intent; The third permission decision result is determined based on the historical call records of the target tool and the accumulated trust score of the dialogue context; The first permission decision result, the second permission decision result, and the third permission decision result are weighted and fused to obtain the target execution permission and the target risk level.

5. The method as described in claim 1, comprising constructing a target execution environment corresponding to the target isolation level, including: The execution environment instance corresponding to the target tool and the target isolation level is searched in the target cache, wherein the execution environment instance in the target cache is updated according to the tool profile of the corresponding tool; If found, the execution environment instance corresponding to the target tool and the target isolation level is determined as the target execution environment; If no information is found, the environment dependency information in the tool profile is input into the data processing model to obtain the environment configuration specifications corresponding to the environment dependency information. Based on the environment configuration specifications, construct the target execution environment for the target isolation level.

6. The method as described in claim 1, wherein the target tool is invoked in the target execution environment to execute the target task corresponding to the tool invocation instruction, and an execution result is obtained, comprising: When the target tool is invoked to access the target file system, the file operation request is sent to the file system abstraction layer, wherein the file system abstraction layer uses semantic-level file operation primitives to convert the access instructions in the file operation request into primitive instructions corresponding to the target file system. The target file system capability description registry is queried, and operation instructions corresponding to the target file system are generated based on the primitive instructions and the capability description registry. The operation on the target file system is completed according to the operation instructions, and the execution result is obtained.

7. The method of claim 6, wherein generating operation instructions corresponding to the target file system comprises: If it is determined that the instruction permission corresponding to the primitive instruction is passed, the target adapter of the target file system is invoked to convert the primitive instruction into the operation instruction corresponding to the target file system.

8. The method according to any one of claims 1-7, further comprising, after obtaining the execution result: The tool profile of the target tool is updated using the execution results.

9. A tool calling device, comprising: The response module is configured to respond to a tool invocation command sent by the intelligent processing unit, obtain the tool identifier in the tool invocation command, and obtain the dialogue context; The determination module is configured to obtain the tool profile of the target tool from the tool registry based on the tool identifier, and determine the target execution permission and target risk level of the target tool based on the tool profile and the dialogue context. The tool profile is a structured data set describing the capabilities of the tool, and the tool profile has been pre-configured in the tool registry. The construction module is configured to determine the target isolation level based on the target risk level and construct the target execution environment corresponding to the target isolation level, provided that the target execution permission is granted. The acquisition module is configured to invoke the target tool in the target execution environment, execute the target task corresponding to the tool invocation instruction, obtain the execution result, and return the execution result to the intelligent processing unit.

10. A tool call management system, comprising: The command interception module includes a first interception submodule and a second interception submodule. The first interception submodule is used to respond to the tool call instruction sent by the intelligent processing unit, obtain the tool identifier in the tool call instruction, and obtain the dialogue context. The second interception submodule is used to perform pre-execution verification on the system command corresponding to the tool call instruction before calling the target tool corresponding to the tool identifier and executing the target task corresponding to the tool call instruction in the target execution environment. The tool registry module is used to store the tool profiles of each tool. The permission decision module is used to determine the target execution permission and target risk level of the target tool based on the tool profile and the dialogue context. The tool profile is a structured data set describing the capabilities of the tool, and the tool profile has been pre-configured in the tool registry center. The execution environment management module is used to determine the target isolation level based on the target risk level and construct the target execution environment corresponding to the target isolation level; The feedback update module is used to send the execution result corresponding to the tool invocation command back to the tool registration center; The file system abstraction module is used to convert access instructions in a file operation request into primitive instructions corresponding to the target file system when the target tool is invoked to access the target file system.

11. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the tool invocation method according to any one of claims 1 to 8.

12. A computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the tool invocation method according to any one of claims 1 to 8.

13. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the tool invocation method according to any one of claims 1 to 8.

Images