A multi-agent tool invocation system and method thereof

Abstract

The application discloses a multi-Agent tool calling system and method thereof, and relates to the technical field of artificial intelligence Agent system.The system comprises a minimization tool interface module, a type declaration and tool document injection module, a type-annotated intermediate script language execution engine, an indirect tool calling module, an access control module, a tool scheduling routing module, a variable storage module, a structured data verification injection module and an operation audit log module.The application aims to solve the problems of large token consumption, wide prompt injection attack surface, lack of type declaration mechanism, repeated injection of intermediate results, disconnection between interface definition and execution environment, low multi-tool calling arrangement efficiency, coarse permission control granularity and scattered audit tracking in the existing multi-tool exposure architecture, and realizes high safety, high efficiency and type declaration assisted multi-Agent tool calling.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence agent system architecture technology, and in particular to a multi-agent tool invocation system and method thereof. Background Technology

[0002] Currently, when large language models interact with external tools, they typically implement agent operations through function calls or executable code to uniformly access multiple tools and automate data processing. These interaction methods form the technical foundation of existing multi-agent tool invocation systems.

[0003] In existing technical solutions, OpenAI's multi-function calls pass up to 128 function definitions in a single API request. Each definition includes information such as name, description, and parameter JSON schema, all injected into the Large Language Model (LLM) context. However, function definitions consume a large number of context tokens, the attack surface increases with the number of functions, access control is coarse-grained, and audit trails are scattered. Anthropic's Model Context Protocol (MCP) allows the LLM to see dozens of tool definitions simultaneously, but token consumption is high, indicating a high risk of injection attacks, and it lacks multi-layered access control. The Executable Code Agent solution (CodeAct) uses Python code to unify the LLM operating space, integrating tool calls and inference planning into code execution, but it requires an external interpreter, cannot be embedded in compiled system language processes, lacks a type declaration mechanism, and lacks type-safe bridging between tool interfaces and the execution environment. Anthropic's programmatic tool calls complete the orchestration of multiple tool calls in a Python container, but it relies on a sandbox container, lacks a type declaration mechanism, tools are still exposed through traditional JSON schema, and it does not support automatic type bridging from compiled system languages ​​to scripting languages.

[0004] To address the aforementioned problems, this invention proposes a multi-Agent tool invocation system and method. Summary of the Invention

[0005] The purpose of this invention is to provide a multi-Agent tool invocation system and method to solve problems such as high token consumption, wide attack surface of hint injection, lack of type declaration mechanism, repeated injection of intermediate results into the context, disconnect between interface definition and execution environment, low efficiency of multi-tool invocation orchestration, coarse granularity of permission control and scattered audit trail in the existing multi-tool exposure architecture.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] The intermediate scripting language with type annotations described in this invention refers to an intermediate expression form that carries static type annotations and is converted into a pure scripting language through type stripping before execution. Type annotations are used to assist the large language model in correctly identifying tool interface parameters and return value structures during the code generation phase; these type annotations are completely stripped before entering the execution engine, and no type checking is performed at runtime.

[0008] A multi-agent tool invocation system, comprising:

[0009] Minimize Tool Interface Modules: This system exposes only three core interfaces to the large language model: code execution interface, text variable writing interface, and structured data variable writing interface. The code execution interface serves as the sole indirect entry point for all MCP tool calls, responsible for receiving and executing intermediate scripting language code with type annotations submitted by the LLM, enabling coordinated calls to multiple tools. The text variable writing interface is used to store ordinary text or string variables, avoiding the need for the LLM to manually handle escaping and concatenation in the code. The structured data variable writing interface is used to store complex structured data, ensuring data integrity and direct usability through two-stage verification.

[0010] Type Declaration and Tool Documentation Injection Module: This module automatically generates intermediate scripting language type declaration files with type annotations using compiled system language structs, recording field types, recursive nesting, and generic constraints. It automatically updates the corresponding declaration files when the tool's return structure changes. When a skill is activated, the system determines the required tool set based on the associated tool information in the current skill configuration. It loads only the corresponding interface declarations, data structure descriptions, and tool documentation formatted as intermediate language API references, injecting them along with prompts from the large language model system. This ensures synchronization between tool interface definitions, tool documentation, and the script execution environment's data structures, guaranteeing that the type-annotated intermediate scripting language code written in LLM remains consistent with the latest interface definitions and tool documentation descriptions.

[0011] The Type-Annotated Intermediate Script Language Execution Engine is used to enforce four processing phases on the received Type-Annotated Intermediate Script Language code, including the syntax parsing phase, the Abstract Syntax Tree (AST) security verification phase, the type stripping phase, and the code generation and execution phase. The introduction of this engine aims to enable the code to be executed lightweightly after stripping type information while obtaining type declaration assistance and security verification, and to maintain the persistent context across calls.

[0012] The syntax parsing phase involves using a script parser to convert the source code into an abstract syntax tree and catch syntax errors.

[0013] The AST security verification phase involves traversing the AST to detect and reject dangerous operation modes, preventing tool calls from causing dangerous operations.

[0014] The type stripping stage involves removing all type annotations to generate a pure scripting language AST, enabling lightweight runtime execution.

[0015] The code generation and execution phase involves converting the scripting language AST back into a source code string and executing it in the embedded script engine, while maintaining a persistent execution context and storing the tool's return value to avoid consuming LLM context tokens.

[0016] The embedded script engine serves as the underlying carrier of the intermediate scripting language execution engine with type annotations. The processed script code is handed over to the embedded script engine for execution. At the same time, the embedded script engine maintains a persistent execution context across calls, so that script variables remain alive across multiple calls.

[0017] Tool Indirect Call Module: LLM writes intermediate scripting language code with type annotations through the code execution interface, and uses ES Module import statements to indirectly call various MCP tools. The system distributes the call requests to the tool scheduling and routing module in the background through a unified callback function. The tool scheduling and routing module performs deterministic routing based on the tool source, including local tools, remote bridging tools, and skill tool calls. This mechanism avoids LLM directly accessing tools and achieves call isolation, call logging, and security management.

[0018] In this invention, the unified entry point is a logical concept, referring to the centralized processing location that all tool calls must pass through; the unified entry function is deployed at this entry point and is responsible for permission verification and audit control; the unified callback function is located in the tool indirect call module and is responsible for translating the script engine's import call into a standard request and forwarding it to the unified entry function. The three are in a serial collaborative relationship: the script call first undergoes format conversion by the unified callback function, then passes through the unified entry function for security checks and is allowed to proceed, and finally enters the scheduling route for execution.

[0019] Access control module: Employs a three-tier access control system to ensure secure calls, specifically including:

[0020] Tool definition filtering: Only expose code execution interface, text variable writing interface and structured data variable writing interface to LLM;

[0021] Permission whitelist check: Based on skill configuration, access permissions are defined by Agent-tool pair, and the caller is verified to have permission to access the target tool before the call is made;

[0022] Centralized execution through a unified entry point: All tool calls must enter the tool scheduling and routing module for processing through a unified entry function. This module works in conjunction with the access control module for centralized control, rate management, retry, and timeout control. The operation audit log module records operation logs at the unified entry point to prevent bypassing access control.

[0023] Tool scheduling and routing module: The tool scheduling and routing module maintains a mapping table from tool name to source. During the initialization phase, it discovers local tools, remote bridging tools, and skill tools. Each time a tool is called, it routes the request to a local direct call, a remote call, or a skill tool based on the tool source. At the same time, it combines permission checks to determine the legality of the call, thereby achieving unified routing scheduling and security assurance.

[0024] The variable storage module receives all tool execution results and stores them in a persistent execution context maintained by the embedded script engine. Variables remain alive across multiple code execution calls. Tool return values ​​are stored in the script engine as variables without entering the LLM context, thus avoiding context token consumption. The LLM can directly read and manipulate the complete recursively nested structured data in subsequent code, enabling the traversal, filtering, and analysis of complex objects.

[0025] Structured data validation injection module: The structured data variable writing interface adopts a two-phase validation mechanism, including:

[0026] Phase 1: Use a JSON parsing library for compiled system languages ​​to validate the JSON format of the input string, and return an error message containing the error type, error location, and a preview of the content when validation fails;

[0027] The second stage involves using the embedded script engine's JSON parsing function to parse the validated JSON string into a native script object and assign it to variables in the script execution environment, allowing subsequent code to directly access nested fields.

[0028] Operation Audit Log Module: This module records complete audit information for all MCP tool calls at a unified entry point. The audit information includes timestamps, tool names, parameter summaries, execution status, result summaries, and error messages. A bounded buffer manages the audit data, with a configurable upper limit. When the upper limit is reached, discarded entries are automatically dumped to persistent storage via a pluggable audit persistence interface. The audit log performs hash calculations on tool call parameters for tamper-proof verification and supports merged querying and exporting from the memory buffer and persistent storage by time range and caller identifier. This enables a traceable and replayable audit chain across agents, providing complete evidence for security control, fault diagnosis, and compliance auditing.

[0029] This invention provides a multi-agent tool invocation method, applied to the aforementioned system, comprising:

[0030] Step S1: Tool interface convergence, exposing only the code execution interface, text variable writing interface, and structured data variable writing interface to the large language model, and using the code execution interface as the only indirect entry point for MCP tool calls;

[0031] Step S2: Type information injection. Determine the set of available tools based on the associated tool information in the current skill configuration, load the interface declaration file, data structure description information and tool document type reference information corresponding to the set of available tools as needed, and inject the large language model prompt information.

[0032] Step S3: Code reception. The system receives intermediate script language code with type annotations generated by the large language model based on the injected type information. The intermediate script language code with type annotations includes tool invocation logic, data processing logic, and task execution flow.

[0033] Step S4: Code parsing and verification. Perform syntax parsing on the intermediate scripting language code with type annotations, construct an abstract syntax tree, and perform security verification on the abstract syntax tree to reject code execution requests with dangerous syntax patterns. The dangerous syntax patterns include: dangerous function calls, dynamic module loading, and illegal object access.

[0034] Step S5: Type processing and script generation. Perform type stripping on the type annotations in the code, remove all type annotations, and generate executable script code.

[0035] Step S6: Script execution and indirect tool invocation. The script code is executed in the embedded script execution environment, and a tool invocation request is initiated through the ES Module import statement.

[0036] Step S7: Permission verification and unified distribution. When the script code initiates a tool call request, the target tool is verified against the Agent-Tool permission whitelist, and the verified tool call request is forwarded to the tool scheduling and routing module through the unified entry point.

[0037] Step S8: Tool routing call. After the verification in step S7 is passed, the tool call request is routed to the local tool, remote bridging tool, or skill tool for execution based on the mapping relationship between the tool name and the tool source.

[0038] Step S9: Variable storage. After step S8 is completed, the tool execution result is saved to the variable storage space of the script execution environment so that subsequent code can directly reference and reuse the tool execution result.

[0039] Step S10: Structured data validation injection. When a structured data variable write request is received, the JSON format validity of the JSON string to be injected is validated. After the validation is passed, the structured data is parsed into a native object in the script execution environment and injected into the runtime context.

[0040] Step S11: Audit Logs. Record the audit logs corresponding to the tool call process at the unified entry point to achieve traceable management of cross-Agent call behavior.

[0041] Compared with the prior art, the beneficial technical effects of the present invention are as follows:

[0042] This invention combines the definitions of the three tools exec, write_to_var, and write_to_var_json with the variable storage mechanism managed by the intermediate scripting language execution engine with type annotations, so that the return value of the MCP tool does not occupy the LLM context token, thereby reducing token consumption, improving context token efficiency, and achieving token saving in multi-agent collaboration scenarios.

[0043] This invention utilizes type-annotated intermediate scripting language syntax parsing, AST security verification, automatic type bridging from compiled system languages ​​to type-annotated intermediate scripting languages, and on-demand type declaration injection. The code generated by LLM undergoes syntax and security verification before entering the execution engine, and the execution risks caused by parameter spelling errors, field access errors, and dangerous syntax are reduced through interface declarations.

[0044] This invention converges the tool exposure surface for large language models from N independent tool definitions to three fixed core interfaces. At the same time, it constructs a multi-layered defense system through AST security verification and code sandbox constraints, achieving a layered combination of attack surface convergence for large language models and security isolation at the execution level.

[0045] This invention achieves access control through a three-layer system: the first layer is tool definition filtering: LLM can only see a limited number of core interfaces; the second layer is permission whitelist checking: fine-grained verification based on Agent-tool pairs; the third layer is centralized execution through a unified entry point: all calls must pass through a unified dispatch function, and the control granularity far exceeds the single-layer tool-level filtering of existing solutions.

[0046] This invention ensures that the tool interface definition and the code execution environment are always synchronized by automatically generating types from a compiled system language to an intermediate scripting language with type annotations. When the MCP tool structure on the compiled system language side changes, the build process is re-executed. At the same time, the type declaration file is automatically updated, and a complete tracking record of type changes can be obtained from the differences in the type declaration files of the version control system.

[0047] This invention removes the limitations of traditional schemes that require truncation, pagination, or digest processing of MCP tool return values ​​due to token consumption concerns through a variable storage module. The MCP tool can return a complete recursive nested data structure, which can be autonomously trimmed and extracted by LLM in intermediate scripting language code with type annotations.

[0048] In this invention, the operation audit log module records all cross-Agent operations at a unified entry point, forming a traceable and replayable operation chain.

[0049] This invention converges the definition of visible tools in LLM into three core interfaces and unifies the actual MCP tool calls to the code execution interface, thereby freeing LLM from the cognitive burden of choosing a large number of tools and releasing its stronger orchestration capabilities. At the same time, the intermediate scripting language with type annotations provides complete programming language expressive capabilities, and the type declaration injection of tools can provide a richer semantic context than JSON Schema. Attached Figure Description

[0050] Figure 1 This is an overall schematic diagram of a multi-Agent tool invocation system provided by the present invention;

[0051] Figure 2 This is a four-level processing flowchart of the execution pipeline of the intermediate scripting language execution engine with type annotations provided by the present invention;

[0052] Figure 3 This invention provides an architectural layered analogy mapping diagram with respect to the microkernel architecture of an operating system.

[0053] Figure 4 This is an architecture diagram of the three-layer access control execution system provided by the present invention;

[0054] Figure 5 This is a data flow diagram of the type bridging system provided by the present invention;

[0055] Figure 6 This is a schematic diagram illustrating the principle of eliminating LLM context token consumption for variable storage in the intermediate scripting language execution engine with type annotations provided by this invention.

[0056] Figure 7 This is a data flow diagram of the deterministic scheduling mechanism of the tool scheduling and routing module provided by the present invention;

[0057] Figure 8 This is a flowchart of the on-demand .d.ts injection mechanism provided by the present invention. Detailed Implementation

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

[0059] This invention uses Rust as a compiled system language, TypeScript as an intermediate scripting language with type annotations, Boa as an embedded scripting engine, and SWC as a syntax transpiler for illustration. However, those skilled in the art will understand that the compiled system language is not limited to Rust, the intermediate scripting language with type annotations is not limited to TypeScript, the embedded scripting engine is not limited to Boa, and the syntax transpiler is not limited to SWC. The "embedded scripting engine" mentioned in this invention refers to a scripting language interpreter that can be embedded within the process of a compiled system language. Boa is merely a specific implementation used in this invention embodiment; those skilled in the art can choose other embedded scripting engines (such as QuickJS) to achieve equivalent functionality according to actual needs.

[0060] Example 1

[0061] like Figure 1 As shown, Figure 1 This is a multi-Agent tool invocation system architecture diagram provided by an embodiment of the present invention, including: a minimal tool interface module in the LLM context space, and a type declaration and tool documentation injection module, an intermediate scripting language execution engine with type annotations, a tool indirect invocation module, an access control module, a tool scheduling and routing module, a variable storage module, a structured data verification and injection module, and an operation audit log module in the kernel space.

[0062] Minimize Tool Interface Module: This module provides three tool definitions to the LLM: `exec`, `write_to_var`, and `write_to_var_json`. The `exec` interface receives and executes TypeScript code, serving as the sole indirect entry point for all MCP tool calls, preventing the LLM from directly calling multiple underlying tools. The `write_to_var` interface for writing text variables and the `write_to_var_json` interface for writing structured data variables are used to write reusable data to the script execution environment. This data is stored in the embedded engine (using the Boa JS engine in this example), avoiding the consumption of LLM context space. `write_to_var` stores multi-line text content as script variables, avoiding the LLM handling escaping and string concatenation in the `exec` code. `write_to_var_json` performs two-stage validation: first, it validates the structure's validity using a JSON parsing library of the compiled system language; then, it injects the validated JSON string into a native script object using the script engine's `JSON.parse()` function.

[0063] The difference between `write_to_var` and `write_to_var_json` is as follows: `write_to_var` stores text or strings without strict data format validation, and is used to save logs or ordinary strings for easy access later; `write_to_var_json` is used to store strictly structured data, i.e., JSON objects. Since JSON objects are usually complex nested structures, if the `write_to_var` method is used for storage, the LLM needs to parse them manually. Therefore, `write_to_var_json` is used to store complex structured data, and this method injects the JSON string as a native script object in the second stage, avoiding extra data parsing operations by the LLM.

[0064] like Figure 3 As shown, this invention maps the operating system microkernel architecture concept to the LLM tool invocation layer: the "system call" in the operating system microkernel corresponds to the "exec unique entry point" in this invention, the "kernel" corresponds to the "intermediate scripting language execution engine with type annotations and tool scheduling and routing module," and the "device driver" corresponds to "various MCP tools," thus realizing the design principle of minimum core and maximum security. It should be noted that the above microkernel analogy is limited to the mapping of the layered architecture concept, that is, to achieve minimal entry point and unified scheduling at the tool invocation layer; the actual process-level isolation is provided by the operating system-level container mechanism, rather than the separation of kernel-mode and user-mode address spaces.

[0065] Type Declaration and Tool Documentation Injection Module: This module enables automatic generation and on-demand injection of type declarations. The system uses the `#[derive(TS)]` macro to automatically generate type declarations from Rust structs (compiled system language) to TypeScript type declarations (intermediate scripting language) with type annotations. A TypeScript type declaration is a description of a data structure, informing the LLM (Local Language Builder) what fields the data has and what the type of each field is, allowing the LLM to correctly access and use this data when writing code, avoiding errors in fields or types. On the compiled system language side, the return value structs of all MCP tools automatically generate TypeScript type declarations using the `#[derive(TS)]` macro. During the cargo test phase, Rust structs automatically export the compiled system language structs as `.d.ts` files, stored in the type declaration file directory. These `.d.ts` files are committed as source code to the Git version control system for long-term storage. When the MCP tool structs on the compiled system language side change, the `.d.ts` files are automatically updated, and a complete tracking record of type changes is provided via Git diff.

[0066] like Figure 5 As shown, this invention achieves automatic type synchronization from compiled system languages ​​(such as Rust) to intermediate scripting languages ​​with type annotations (such as TypeScript) through a type bridging system: Rust structs automatically generate .d.ts declaration files through derived macros, track type changes through Git version management, and finally inject them into the LLM context for code generation, ensuring that the tool interface definition and the data structure of the script execution environment are always consistent.

[0067] The system employs a refined type declaration injection strategy. When a skill is activated, the system determines the required Agent tool set for the current skill based on the related_tools field in the skill's TOML metadata. It then loads the corresponding .d.ts declaration files for each Agent, including Layer 1 type declarations, Layer 1 API declarations, and Layer 2 API declarations. The loaded type declarations are then injected into the LLM system prompt in the standard TypeScript interface declaration format, which includes complete parameter types, return value types, and JSDoc comment information. This provides the required tool interface definitions and data structure descriptions for the current skill while achieving on-demand and precise type injection.

[0068] like Figure 8 As shown, the system determines the set of tools required for the current task based on the related_tools field in the skill configuration, loads the corresponding .d.ts type declaration files and API reference information on demand, and then injects the LLM system prompt words to achieve precise on-demand injection of type declarations and avoid irrelevant type information occupying context tokens.

[0069] In the Exec-Only architecture, the documentation for MCP tools is not directly exposed through the LLM tool definition mechanism. Instead, it is injected into the LLM system prompt as TypeScript API reference information. First, the system reads the skill's related_tools configuration, determines the set of tools that the current skill depends on based on this configuration, and extracts the functional description and parameter schema information of each associated tool from the tool documentation. These are then uniformly formatted into a TypeScript API reference structure, and the corresponding .d.ts type declaration files are loaded. Finally, the above API reference information and type declarations are injected together into the "Available TypeScript APIs" section of the LLM system prompt to achieve a unified provision of tool invocation capabilities and type constraint information.

[0070] Intermediate scripting language execution engines with type annotations: such as Figure 2 As shown, the code received by the `exec` function in this engine is TypeScript code with type annotations. This TypeScript code undergoes four stages of processing in the compiler's native pipeline before execution. Type declarations provide interface and field constraints for the LLM, and runtime risks are reduced through syntax parsing, security verification, type stripping, and code generation. The four stages of the native pipeline are as follows:

[0071] Level 1, Syntax Parsing: The syntax transpiler (using the TypeScript parser as an example in this embodiment) parses the intermediate scripting language source code (TypeScript in this embodiment) with type annotations into an AST, or Abstract Syntax Tree. The AST converts the source code into a tree structure. By checking the completeness of the tree structure, it is possible to check whether there are any syntax errors in the source code. Syntax errors are captured before the code enters the execution engine.

[0072] Level 2, AST security verification: Uses a custom AST traverser to detect and reject dangerous syntax patterns, i.e., prevents users from performing dangerous operations by calling tools: prohibits calls to eval() and Function(), prohibits dynamic imports, prohibits access to __proto__ and constructor, prohibits with statements, and refuses execution and returns an error when a dangerous syntax pattern is found.

[0073] Level 3, Type Stripping: All type annotations in the TypeScript AST are removed, meaning unnecessary runtime documentation is deleted, generating a pure JavaScript AST. TypeScript type declarations provide interface and field hints for the LLM during code generation, but are no longer needed at runtime.

[0074] Level 4, Code Generation and Execution: This involves converting the JavaScript AST back into a source code string, which is then executed within the embedded JavaScript engine. In practice, runtime resource constraints (such as execution time limits, loop iteration limits, recursion depth limits, and memory usage limits) can be further configured to prevent abnormal scripts from exhausting system resources.

[0075] The embedded script engine (taking the Boa JS engine as an example in this embodiment) serves as the underlying carrier of the intermediate scripting language execution engine with type annotations. The intermediate scripting language execution engine with type annotations is executed in the embedded script engine, while maintaining a persistent execution context across calls, so that script variables remain alive across multiple calls.

[0076] Tool Indirect Module Call: This module uses the embedded script engine's module registration mechanism to parse ESModule import statements to pre-registered composition modules, forwarding tool call requests through a unified callback function. LLM writes TypeScript code in the `code` parameter of `exec` to indirectly call all MCP tools using the ES Module import syntax. The specific implementation method is as follows:

[0077] import { file_list, file_read} from 'kalos';

[0078] import { report} from 'hubris';

[0079] const files = await file_list({ path: ".", recursive: true});

[0080] const deps = files.entries.filter(e => e.name.endsWith(".rs"));

[0081] const reports = [];

[0082] for (const f of deps) {

[0083] const content = await file_read({ path: f.path});

[0084] reports.push({

[0085] file: f.name,

[0086] lines: content.content.split("\n").length

[0087] });

[0088] }

[0089] report({ text: "Analysis complete: " + JSON.stringify(reports)});

[0090] TypeScript provides LLM with complete programming language capabilities, allowing LLM to orchestrate coordinated calls of multiple agent tools in a single exec call, performing complex conditional logic and data processing without repeatedly going through the loop of "calling tools - waiting for returns - making decisions again".

[0091] Access Control Module: This module employs a three-tier access control architecture to ensure secure calls, such as... Figure 4 As shown:

[0092] Layer 1: Tool definition filtering. The system only allows the LLM to consistently return `exec`, `write_to_var`, and `write_to_var_json` to all agents. In other words, the LLM can only be aware of the existence of these three tools. When constructing the LLM API request, only the definitions of these three tools are sent to the LLM's entry point.

[0093] Layer 2: Permission checks. At the tool scheduling and routing module level, fine-grained access control based on Agent-tool pairs is implemented through the functions `set_allowed_tools()` to set available tools and `is_tool_allowed()` to determine tool availability. This involves setting a whitelist of permissions in the format "agent.tool_name". Only tools and functions actually needed by the skill are allowed to be invoked. When a skill starts, the system determines the set of tools it can use based on its configuration; when the skill stops or is deactivated, these permissions are automatically revoked. In this way, the system achieves fine-grained access control, ensuring that the LLM can only call allowed tools and preventing unauthorized operations.

[0094] Layer 3: Centralized execution through a unified entry point. All tool calls must pass through the unified entry point, `cosmos_dispatch`, leading to `McpRouter::call()`. This means all tool calls must be scheduled through a single unified entry point, preventing LLM from directly manipulating tools. The unified entry point logs every tool call, facilitating auditing and monitoring. It also works in conjunction with access control modules for centralized control, rate management, retry, and timeout control. This not only ensures security but also facilitates centralized management and control of tool call behavior.

[0095] Tool scheduling and routing module: The tool scheduling and routing module is the core scheduling component after the Agent tool is invoked, such as... Figure 7 As shown, the scheduling path is as follows:

[0096] ES Module import call → cosmos_dispatch() Rust callback → McpRouter::call(tool_name, parameters) → route based on ToolSource enumeration:

[0097] ToolSource::Local → Local MCP tools

[0098] ToolSource::Bridge → HapLotesBridge.call() → JSON-RPC over Unix Socket → Core Engine → Agent Container

[0099] ToolSource::Skill → LLM Subcall

[0100] The tool scheduling and routing module maintains a tool_to_source:HashMap.<String,ToolSource> The mapping table automatically discovers three types of tool sources during the initialization phase: Local tools registered through the McpToolInvoker trait, remote Agent tools obtained through Bridge::list_tools(), and Skill tools discovered through a scan of the skill file system.

[0101] In this invention, a skill tool refers to a tool source encapsulated from a preset skill template or an Agent sub-call. When the tool scheduling and routing module routes a request to a skill tool, the request is converted into a sub-call to the large language model, which is then executed by the sub-Agent or the preset skill logic.

[0102] Variable Storage Module: This module maintains a persistent execution context through an embedded JavaScript engine, ensuring variables remain alive across multiple `exec()` calls. When the LLM calls the MCP tool via ES Module import syntax, the tool's return value is assigned to a JavaScript variable, which can then be reused multiple times. Thus, the tool's return value resides in the JavaScript engine as a variable, avoiding the consumption of context tokens caused by directly entering the LLM context. A context token is a text unit corresponding to a single request processed by the LLM. The LLM can subsequently use `exec()` to call the MCP tool and directly read the tool's return value stored in the script engine through TypeScript code, directly obtaining the complete recursive nested data structure and autonomously traversing, filtering, and analyzing complex nested objects.

[0103] like Figure 6 As shown, the tool's return value is persistently stored as a variable in the execution context of the embedded script engine. Subsequent code execution directly reads the variable value from the script engine without re-injecting the data into the LLM context, thus completely eliminating the consumption of context tokens by intermediate results.

[0104] Structured Data Validation Injection Module: This module implements a two-phase validation injection mechanism using the `write_to_var_json` tool. In multi-agent collaboration scenarios, LLMs need to inject structured data such as task decomposition results, sensor configurations, and analysis reports into the script runtime context for use by subsequent `exec` code. The `write_to_var_json` tool ensures data integrity through a two-phase validation mechanism, detailed as follows:

[0105] Phase 1: Compiled System Language Level Validation. The input string is validated using a JSON parsing library of the compiled system language. If the JSON format is invalid, an error message containing the error type, error location, and a preview of the content is immediately returned to prevent invalid data from entering the script engine.

[0106] Phase 2: Script Engine-Level Injection. The validated JSON string is parsed into a native script object using the script engine's `JSON.parse()` function and assigned to a global variable. This ensures that the injected data is a native object type of the script engine, allowing subsequent `exec` code to directly access nested fields without manual parsing.

[0107] Operation Audit Log Module: The operation audit log module records complete audit information for all MCP tool calls at a unified entry point: timestamp in RFC 3339 format, tool name, parameter summary of the first 120 characters, execution success / failure status, result summary, and error information. A bounded buffer is used to ensure bounded memory usage, with an upper limit of a configurable number. When the number of entries reaches the upper limit, the discarded entries are automatically dumped to persistent storage media through a pluggable audit persistence interface. The audit log performs hash calculations on the tool call parameters for tamper-proof verification and supports merged querying and exporting from the memory buffer and persistent storage by time range and caller identifier.

[0108] This embodiment provides a multi-Agent tool invocation method, applied to the above system, including the following steps:

[0109] Step S1: Tool interface convergence. Only three tool definitions, exec, write_to_var, and write_to_var_json, are exposed to the large language model. All tool capabilities are unified and converged into a limited set of interfaces to reduce the number of exposed tools, reduce the attack surface of injection hints, and establish a unified entry point for subsequent tool calls.

[0110] Step S2: Type information injection. Determine the available tool set based on the associated tool information in the current skill configuration, load the corresponding TypeScript type declaration files as needed, and format the MCP tool document into TypeScript API reference information, and inject it into the large language model system prompt words.

[0111] Step S3: Code reception. The system receives intermediate script language code with type annotations generated by the large language model based on the injected type information. The code describes the tool calling logic, data processing logic, and task execution flow.

[0112] Step S4: Code parsing and verification. The generated intermediate scripting language code with type annotations is parsed to construct an abstract syntax tree. The abstract syntax tree is then subjected to a security check to detect dangerous syntax patterns such as dangerous function calls, dynamic module loading, and illegal object access. After successful verification, the code proceeds to the next processing stage.

[0113] Step S5: Type processing and script generation. Perform type stripping on the type annotations in the code, remove all type annotations and generate executable script code, while maintaining the consistency between the tool interface and the data structure.

[0114] Step S6: Script execution and indirect tool invocation. The processed script code is loaded into the embedded script execution environment for execution. The execution environment maintains the persistent runtime context and is responsible for variable management, code execution, and forwarding tool invocation requests. During script execution, tool requests are initiated through ES Module import statements. The code execution interface serves as the sole access point to indirectly invoke various Agent tools, avoiding direct access to underlying tools by the large language model.

[0115] Step S7: Permission Verification and Unified Distribution. Before a tool is invoked, access to the target tool is verified based on the current skill configuration and permission whitelist to determine whether the invoking entity has the necessary access permissions. Unauthorized requests are intercepted. Tool invoking requests that pass verification are forwarded to the tool scheduling and routing module via a unified entry point.

[0116] Step S8: Tool routing call. For tool call requests that pass the permission verification, the request is routed to the corresponding local tool, remote bridging tool, or skill tool for execution based on the pre-established mapping relationship between tool name and tool source.

[0117] Step S9: Variable storage. Save the results returned by the tool to the variable storage space of the script execution environment so that the execution results can be directly referenced and reused in subsequent code execution without having to return to the large language model context.

[0118] Step S10: Structured data validation injection. For structured data, the data format and structure are validated first. After the validation is passed, the data is parsed into native objects in the script execution environment and injected into the runtime context for direct access by subsequent code.

[0119] Step S11: Audit Log. Record the entire process of tool invocation at the unified tool invocation entry point, including invocation time, tool name, parameter summary, execution result and exception information, to form a complete operation audit log and achieve traceable management of invocation behavior.

[0120] Example 2: Minimal Secure Execution Implementation for Single-Agent Local Tools

[0121] This embodiment provides a minimal deployment model for a multi-Agent tool invocation system, applicable to single-Agent local tool invocation scenarios, such as a local code repository analysis agent, log analysis agent, or personal assistant agent. In this scenario, the system does not need to deploy remote bridging capabilities and multi-tenant access control, but still needs to ensure type safety of tool invocation, interception of dangerous syntax, and low token consumption.

[0122] The specific execution flow of this embodiment is as follows:

[0123] Step S1: Tool interface convergence. The system exposes only three tool definitions to the large language model: exec, write_to_var, and write_to_var_json. Among them, exec serves as the sole indirect entry point for all local tool calls.

[0124] Step S2: Type Information Injection. Based on the associated tool information in the current skill configuration (e.g., "Code Analysis Skill"), the system reads the local tool set, such as file_list, file_read, and grep_files. The system automatically generates corresponding TypeScript type declaration files (.d.ts) using Rust structs and injects these declaration files into the large language model system prompts. Simultaneously, the system injects the MCP tool documentation, formatted as TypeScript API reference information.

[0125] Step S3: Code reception. The user issues a natural language command: "Count the total number of lines in all .rs files in the current directory." The system receives intermediate scripting language code with type annotations generated by the large language model based on the injected type information. The large language model generates the following TypeScript code based on the injected type declarations:

[0126] import { file_list, file_read} from 'kalos';

[0127] import { report} from 'hubris';

[0128] interface FileEntry { name: string; path: string;}

[0129] interface FileContent { content: string;}

[0130] const files = await file_list({ path: ".", recursive: true}) as {entries: FileEntry[]};

[0131] const rsFiles = files.entries.filter((file) => file.name.endsWith(".rs"));

[0132] let totalLines = 0;

[0133] for (const file of rsFiles) {

[0134] try {

[0135] const fileContent = await file_read({ path: file.path}) asFileContent;

[0136] const lineCount = fileContent.content.split("\n").length;

[0137] totalLines += lineCount;

[0138] } catch (error) { console.warn(`Failed to read file: ${file.path}`, error);}

[0139] }

[0140] report({ text: `Total Lines: ${totalLines}`});

[0141] Step S4: Code parsing and verification. The intermediate scripting language execution engine with type annotations receives the TypeScript code, performs syntax parsing to construct an abstract syntax tree (AST), and performs AST security verification on the AST, detecting and rejecting dangerous syntax patterns such as `eval()`, dynamic `import`, `__proto__` access, and `with` statements. After successful verification, proceed to the next stage.

[0142] Step S5: Type processing and script generation. Type stripping is performed on the verified code, removing all TypeScript type annotations to generate a pure JavaScript AST. This AST is then converted back to a JavaScript source code string to obtain executable script code, which is then executed by the embedded script engine. In actual deployment, resource constraint parameters (such as execution time, loop count, recursion depth, and memory usage limit) can be configured for the script execution environment to prevent abnormal code from affecting system stability.

[0143] Step S6: Script execution and indirect tool invocation. The generated JavaScript code is executed in the embedded JavaScript engine (Boa JS engine). The `file_list` and `file_read` functions imported by the `import` statement in the code are parsed to the pre-registered composition module by the module registration mechanism of the embedded script engine. The corresponding exported members in the composition module are bound to the standardized tool invocation callback function, which is then converted into a standardized tool invocation request and forwarded to the tool scheduling and routing module through the unified callback function.

[0144] Step S7: Permission verification and unified distribution. After receiving the call request, the tool scheduling and routing module performs a permission whitelist check to verify whether the current Agent is allowed to call the target tool. In this embodiment, after the permission verification is passed, the request is forwarded to the tool scheduling and routing module for processing via a unified entry point.

[0145] Step S8: Tool routing call. The tool scheduling and routing module queries the tool_to_source mapping table. In this embodiment, all tools are local tools, so the routing is to the ToolSource::Local branch, and the local MCP tool is directly called for execution.

[0146] Step S9: Variable storage. The results returned by the tool call (the array of files.entries and the string content.content) are automatically saved to the persistent context of the embedded script engine and assigned to variables such as files and content. These variables can be directly reused during subsequent code execution without having to return the results to the large language model context.

[0147] Step S10: Structured data validation injection. If the user needs to inject a project configuration file (e.g., .rsproj.json) in advance, the system performs two-stage validation using the write_to_var_json tool: the first stage uses Rust's serde_json library to validate the JSON structure; the second stage uses the script engine's JSON.parse() to inject the validated JSON into a native script object for direct access by subsequent exec code.

[0148] Step S11: Audit Records. The operation audit log module records complete information about this tool call at a unified entry point, including timestamp, tool name, parameter summary, execution status, and error information, forming a traceable audit record.

[0149] The beneficial effects of this embodiment are as follows: First, the large language model only sees three tool definitions, reducing the attack surface from dozens of tools in traditional solutions to three fixed interfaces plus a TypeScript code sandbox; second, all tool return values ​​are stored in the script engine, saving approximately 100 tokens required to return file content to the LLM context in a scenario involving 100 .rs files; third, through TypeScript type declarations, the LLM can obtain field-level auto-completion suggestions when writing code, reducing the probability of parameter spelling errors and field access errors. This embodiment demonstrates that the system can be deployed in a lightweight form in a single-agent local environment while retaining its core security and efficiency advantages.

[0150] Example 3: Implementation of "Multi-tenant Access Control" for High-Security Isolation Scenarios

[0151] This embodiment provides a complete application of a multi-Agent tool invocation system in a multi-tenant, high-security isolation scenario. This scenario is typically applied within an enterprise platform, where multiple departments, such as security auditing, data analysis, and operations, each have independent Agent instances, sharing the same underlying toolset. However, agents from different departments have different access permissions to different tools. The system needs to implement granular access control, comprehensive operation auditing, and prevention of unauthorized invocation.

[0152] The specific execution flow of this embodiment is as follows:

[0153] Step S1: Tool interface convergence. The system uniformly exposes three tool definitions—exec, write_to_var, and write_to_var_json—to the large language model of all agents. Regardless of how many MCP tools are registered at the underlying level, LLM only perceives these three core interfaces, thus reducing the attack surface from "N tool definitions" to three fixed interfaces at the architectural level.

[0154] Step S2: Type Information Injection. The system administrator defines a whitelist of available tools for each Agent using skill configuration files (TOML metadata). For example:

[0155] security_audit_agent: Allows calls to file_read, db_query, audit_log_read, and process_list;

[0156] data_query_agent: Allows calls to db_query and data_export;

[0157] ops_agent: Allows calls to process_list, service_restart, and file_read (log directory only).

[0158] When `security_audit_agent` is activated, the type declaration and tool documentation injection module loads only the TypeScript type declaration files and API reference information corresponding to `file_read`, `db_query`, `audit_log_read`, and `process_list` based on its associated tool set, and injects the system prompt words for that Agent. Other Agents are injected similarly, achieving precise injection on demand and preventing Agents from seeing tool definitions outside their scope of responsibility.

[0159] Step S3: Code Reception. The system receives intermediate scripting language code with type annotations generated by the large language model based on the injected type information. Taking `data_query_agent` as an example, the user command is "query this month's sales." The LLM generates the following TypeScript code based on the injected type declaration:

[0160] / / Define the query result type

[0161] interface QueryResult {

[0162] sum: number;

[0163] record_count?: number;

[0164] }

[0165] / / Execute database query

[0166] / / Note: The following SQL statement is a static query string generated by the large language model based on the injected type information. It is not directly concatenated from user input.

[0167] import { db_query} from 'database';

[0168] import { report} from 'hubris';

[0169] const result = await db_query({ sql: "SELECT SUM(amount) FROM salesWHERE month = '2026-05'"}) as QueryResult;

[0170] report({ text: `This month's sales: ${result.sum}`});

[0171] Step S4: Code parsing and verification. The intermediate scripting language execution engine with type annotations receives the TypeScript code, performs syntax parsing to construct an abstract syntax tree (AST), and performs AST security verification on the AST, detecting and rejecting dangerous syntax patterns such as `eval()`, dynamic `import`, `__proto__` access, and `with` statements. After successful verification, proceed to the next stage.

[0172] Step S5: Type processing and script generation. Type stripping is performed on the verified code, removing all TypeScript type annotations (such as the QueryResult type annotation in the code above), generating a pure JavaScript AST, and then converting it back to a JavaScript source code string to obtain executable script code. In actual deployment, resource constraint parameters (such as execution time, loop count, recursion depth, and memory usage limit) can be configured for the script execution environment to prevent abnormal code from affecting system stability.

[0173] Step S6: Script execution and tool indirect invocation. The generated JavaScript code is executed in the embedded JavaScript engine. The `db_query` function call syntax imported by the `import` statement in the code is intercepted by the tool indirect invocation module and converted into a standardized tool invocation request (tool_name: db_query, parameters: {sql: "..."}), which is then forwarded to the tool scheduling and routing module. The `db_query` function imported by the `import` statement in the code is parsed to the pre-registered synthesis module by the embedded script engine's module registration mechanism. Its corresponding exported members are bound to the standardized tool invocation callback function, converted into a tool invocation request (tool_name: db_query, parameters: {sql: "..."}), and forwarded to the tool scheduling and routing module through the unified callback function.

[0174] Step S7: Permission verification and unified distribution. After the tool scheduling and routing module receives the call request, the access control module performs three-layer access control verification:

[0175] First layer: Tool definition filtering. LLM has never seen tool definitions other than the three core interfaces, and cannot directly call unexposed tools in the code. This layer passes the verification.

[0176] The second layer: permission whitelist check. The access control module checks whether the current Agent (data_query_agent) has the data_query_agent.db_query permission in the whitelist. In this embodiment, according to the permission whitelist configured in step S2, data_query_agent does indeed have the permission to call db_query, and the verification passes.

[0177] The third layer: Centralized execution through a unified entry point. All calls must go through the unified entry point cosmos_dispatch→McpRouter::call() and cannot be bypassed. This layer passes the verification.

[0178] Example of unauthorized call interception: If the LLM of data_query_agent is prompted by an injection attack and generates code that calls file_read to read sensitive configuration files, such as import { file_read} from 'kalos'; ...await file_read({path: " / etc / secrets.conf"}), then during the second-level permission whitelist check, the access control module detects that data_query_agent.file_read is not in the whitelist, immediately rejects the call, returns the error message "Insufficient permissions: data_query_agent does not have permission to call file_read", and triggers step S11 to record the unauthorized call attempt.

[0179] Step S8: Tool routing call. For call requests that pass the permission verification, the tool scheduling and routing module queries the tool_to_source mapping table. In this embodiment, db_query is a local tool (ToolSource::Local), so it is routed to the local MCP tool for execution; if a remote Agent tool is involved (such as calling an Agent from another department), it is routed to the ToolSource::Bridge branch, and JSON-RPC over Unix Socket is sent to the target Agent container through HapLotesBridge.

[0180] Step S9: Variable storage. The result returned by the tool call (such as the sales amount sum) is automatically saved to the persistence context of the embedded script engine and assigned to the result variable. This result can be directly reused during subsequent code execution without returning to the large language model context.

[0181] Step S10: Structured Data Validation Injection: In multi-agent collaboration scenarios, if the main agent needs to pass structured task parameters (such as task decomposition JSON) to the sub-agent, the system performs a two-stage validation using the write_to_var_json tool: the first stage uses Rust's serde_json library to validate the JSON structure; the second stage uses the script engine's JSON.parse() to inject the validated JSON into a native script object, ensuring the integrity of the structured data transmitted across agents.

[0182] Step S11: Audit Recording. The audit log module records complete information for each tool call at a unified entry point, McpRouter::call(), including: RFC 3339 format timestamp, Agent identifier, tool name, parameter summary (first 120 characters), execution status (success / failure / unauthorized rejection), result summary, and error information. It also performs hash calculations on the tool call parameters for tamper-proof verification. The log uses a bounded buffer to ensure bounded memory usage, with a configurable upper limit. When the number of entries reaches the limit, discarded entries are automatically dumped to persistent storage via a pluggable audit persistence interface. It supports merging queries and exporting from the memory buffer and persistent storage to an external audit system based on time range and Agent identifier. When investigating a security incident, the audit system can replay all tool call records based on time range and Agent identifier to form a complete call chain. For example, security_audit_agent calls audit_log_read to read logs at time T1, and ops_agent calls service_restart to restart the service at time T2; there is a compliant time correlation between the two.

[0183] The beneficial effects of this embodiment are as follows: First, existing OpenAI multi-function call schemes only offer function-level access control and lack agent-level isolation; this embodiment achieves fine-grained access control at the multi-tenant level through agent-tools and whitelists. Second, the three-layer access control system (definition filtering + whitelist checking + unified entry point) effectively prevents unauthorized calls caused by hint injection attacks. Third, the complete audit logs of the unified entry point form a traceable and replayable operation chain, meeting enterprise compliance requirements. This embodiment demonstrates the applicability of the system in enterprise-level multi-tenant high-security scenarios.

[0184] Example 4: Collaborative Implementation of "Variable Storage + Structured Injection" for Complex Data Processing Chains

[0185] This embodiment provides an application of a multi-agent tool invocation system in a complex data processing chain scenario, focusing on demonstrating the collaborative working mechanism between the variable storage module and the structured data validation injection module. This scenario is typically applied when an LLM (Local Management Module) needs to repeatedly invoke different tools to perform multiple, multi-step analyses and transformations on a large recursively nested data structure (e.g., a project dependency tree, file directory tree, or knowledge graph subgraph). Traditional solutions require returning the complete data structure or its intermediate results to the LLM context each time, leading to explosive token consumption. This embodiment uses a variable storage module to reside data within the script engine, allowing subsequent operations to directly reference it, completely avoiding context token consumption.

[0186] Application Scenario: Analyze the dependency tree of a large front-end project and generate refactoring suggestions. The project contains 800 dependency nodes, with a dependency tree depth of 5 levels, a recursive nested JSON structure, and an original size of 2.5MB.

[0187] The specific execution flow of this embodiment is as follows:

[0188] Step S1: Tool interface convergence. The system exposes only three tool definitions to the large language model: exec, write_to_var, and write_to_var_json. Among them, write_to_var_json serves as a dedicated injection interface for structured data, ensuring that complex nested data can be injected into the script runtime in the form of native objects.

[0189] Step S2: Type Information Injection. Based on the associated tool information in the current skill configuration (e.g., "Dependency Analysis Skill"), the system loads the TypeScript type declaration files corresponding to the dependency tree data structure as needed. The type declarations define the recursively nested dependency node structure, for example:

[0190] interface DependencyNode {

[0191] name: string;

[0192] version: string;

[0193] dependencies?: DependencyNode[]; / / Recursive nested type

[0194] path?: string;

[0195] }

[0196] The system injects this type declaration into the LLM system hint word, enabling the LLM to correctly access nested fields of the dependency tree when writing analysis code.

[0197] Step S3: Code Reception. The system receives intermediate scripting language code with type annotations generated by the large language model based on the injected type information. This step consists of two stages:

[0198] Phase 3-1 – Data Injection (Non-LLM Generation, Completed by the Upstream System Calling write_to_var_json): The upstream system or main agent calls the write_to_var_json tool to inject the JSON string of the project dependency tree into the script execution environment:

[0199] / / Executed internally by the system, not generated by LLM

[0200] write_to_var_json({

[0201] var_name: "dependencyTree",

[0202] content: '{"name":"root","version":"1.0.0","dependencies":[{"name":"react","version":"18.2.0","dependencies":[{"name":" loose-envify","version":"1.4.0"}]},{"name":"lodash","version":"4.17.21"},{"name":"lodash","version":"2.4.2"}]}'

[0203] });

[0204] Phase 3-2 – LLM Generates Analysis Code: The user issues the command: "Check for circular dependencies in the dependency tree, count the number of direct dependencies, and find all lodash dependencies with version 2.x." Based on the injected type declarations, LLM generates the following TypeScript code and submits it via the exec interface:

[0205] / / Define the dependency node type (matching the injected data structure)

[0206] interface DependencyNode {

[0207] name: string;

[0208] version: string;

[0209] dependencies?: DependencyNode[];

[0210] }

[0211] / / 1. Check for circular dependencies

[0212] function hasCycle(node: DependencyNode, visited: Set <string>= newSet(), path: Set <string>= new Set()): boolean {

[0213] if (path.has(node.name)) return true;

[0214] if (visited.has(node.name)) return false;

[0215] visited.add(node.name);

[0216] path.add(node.name);

[0217] if (node.dependencies) {

[0218] for (let dep of node.dependencies) {

[0219] if (hasCycle(dep, visited, path)) return true;

[0220] }

[0221] }

[0222] path.delete(node.name);

[0223] return false;

[0224] }

[0225] / / 2. Count the number of direct dependencies

[0226] function getDirectDependencyCount(node: DependencyNode): number {

[0227] return node.dependencies? node.dependencies.length : 0;

[0228] }

[0229] / / 3. Find all lodash dependencies of version 2.x

[0230] function findLodashV2(node: DependencyNode, results: Array<{name:string, version: string, path: string}> = [], currentPath: string =node.name): Array<{name: string, version: string, path: string}> {

[0231] if (node.name === "lodash" && node.version &&node.version.startsWith("2.")) {

[0232] results.push({ name: node.name, version: node.version, path:currentPath});

[0233] }

[0234] if (node.dependencies) {

[0235] for (let dep of node.dependencies) {

[0236] findLodashV2(dep, results, `${currentPath} -> ${dep.name}`);

[0237] }

[0238] }

[0239] return results;

[0240] }

[0241] / / Perform three analyses

[0242] let cycleExists = hasCycle(dependencyTree);

[0243] let directCount = getDirectDependencyCount(dependencyTree);

[0244] let lodashV2Instances = findLodashV2(dependencyTree);

[0245] / / Summary Report

[0246] import { report} from 'hubris';

[0247] report({

[0248] Analysis results: Circular dependencies = ${cycleExists}, Direct dependencies = ${directCount}, Lodash 2.x instance count = ${lodashV2Instances.length}, Details = ${JSON.stringify(lodashV2Instances)}`

[0249] });

[0250] Step S4: Code parsing and verification. The intermediate scripting language execution engine with type annotations receives the above TypeScript code, performs syntax parsing to build an abstract syntax tree, and performs AST security verification on the abstract syntax tree. It detects and rejects dangerous syntax patterns such as eval(), dynamic import, __proto__ access, and with statement. After the verification is successful, it proceeds to the next stage.

[0251] Step S5: The compiler's native pipeline module performs type stripping on the verified code, removes all TypeScript type annotations, generates a pure JavaScript AST, and then converts it back to a JavaScript source code string to obtain executable script code. In actual deployment, resource constraint parameters (such as execution time, loop count, recursion depth, and memory usage limit) can be configured for the script execution environment to prevent abnormal code from affecting system stability.

[0252] Step S6: Script execution and indirect tool calls. The generated JavaScript code is executed in the embedded JavaScript engine. The dependencyTree variable in the code is read directly from the script engine's persistence context (this variable was injected in step S3-1 via write_to_var_json). Since this analysis task does not involve additional MCP tool calls, the indirect tool call module does not need to be intercepted or forwarded in this step.

[0253] Step S7: Permission verification and unified distribution. In this embodiment, no tool call is initiated during code execution, so the permission verification step does not need to be performed. If additional tools need to be called during the analysis process (such as reading configuration files for supplementary analysis), permission verification will be triggered when the tool is called.

[0254] Step S8: Tool routing call. In this embodiment, there is no additional tool call, so this step is skipped.

[0255] Step S9: Variable storage. Intermediate variables (cycleExists, directCount, lodashV2Instances) generated during the analysis process, as well as the original dependency tree data (dependencyTree), are stored in the persistence context of the embedded script engine. If further analysis is needed based on these intermediate results, such as "listing the circular paths if circular dependencies exist," LLM can directly reference these variables without recalculating or re-injecting the dependency tree.

[0256] Step S10: Structured data validation injection. The key mechanism in this embodiment lies in the `write_to_var_json` call in step S3-1. This tool performs a two-phase validation injection:

[0257] Phase 1: Compiled system language-level validation. The Rust serde_json library is used to validate the input JSON string for JSON formatting. If the JSON format is invalid, such as mismatched brackets or missing quotes, an error message containing the error type, error location, and a preview of the content is immediately returned to prevent invalid data from entering the script engine.

[0258] The second stage is script engine-level injection. The validated JSON string is parsed into a native JavaScript object using the embedded script engine's JSON.parse() function and assigned to the global variable dependencyTree. After injection, this variable exists as a native object in the script engine's persistence context, and subsequent exec code can directly access its nested fields (such as dependencyTree.dependencies[0].dependencies) without manual parsing.

[0259] Step S11: Audit Log. The operation audit log module records complete information for this exec call and write_to_var_json call at a unified entry point, including timestamp, operation type, parameter summary (first 120 characters of JSON content), execution status, and error information. For large JSON injections of 2.5MB, the audit log only records a preview of the content rather than the complete data to ensure bounded memory usage.

[0260] This embodiment demonstrates the multiple analysis reuse:

[0261] In the single exec code above, LLM completes three analysis tasks (circular dependency detection, direct dependency statistics, and version filtering) in one go. If the user subsequently issues new commands, such as "find all packages whose version numbers contain 'alpha' in their direct dependencies," LLM can generate a second exec code:

[0262] / / The second exec call reuses the stored dependencyTree

[0263] let alphaDeps = dependencyTree.dependencies?.filter(dep =>dep.version.includes("alpha")) || [];

[0264] import { report} from 'hubris';

[0265] report({ text: `alpha version dependency: ${JSON.stringify(alphaDeps)}`});

[0266] In this call, dependencyTree still reads directly from the script engine, without needing to re-inject 2.5MB of dependency tree data, further saving token consumption.

[0267] The beneficial effects of this embodiment are as follows: First, in traditional MCP tool invocation schemes, each tool return value is appended to the dialogue history as a new message, resulting in linear token consumption. This embodiment, through a variable storage module, keeps tool return values ​​and intermediate calculation results residing in the script engine, achieving constant-level token consumption. Second, for a 2.5MB recursive nested dependency tree, the traditional scheme requires approximately 600k tokens per iteration (calculated at an average of approximately 4 characters per token), while this embodiment only requires approximately 500 tokens of analysis code, achieving approximately 1200 times the token savings. Third, the two-stage verification mechanism of the structured data validation injection module ensures the structural integrity of the injected data, avoiding script execution failures due to JSON format errors. Fourth, `write_to_var_json` moves JSON validation errors from the script runtime to the data injection stage, providing more accurate error localization. This embodiment demonstrates the significant token efficiency advantage of this system when handling large-scale recursive nested data chains.

[0268] Example 5: Cross-language / Cross-platform bridging implementation

[0269] This embodiment provides an application of a multi-Agent tool invocation system in a heterogeneous technology stack environment, focusing on demonstrating the remote bridging capability (ToolSource::Bridge) of the tool scheduling and routing module and the unified interception mechanism of the tool indirect invocation module. This scenario is typically applied when the main agent uses the Rust+TypeScript system of this invention and needs to call another agent implemented in Python or an external service (e.g., machine learning inference service, legacy system SOAP service, third-party REST API). Traditional solutions require writing separate adaptation code for each heterogeneous service, while this embodiment achieves transparent tool invocation across languages ​​and platforms through a standardized bridging protocol and unified routing mapping.

[0270] Application scenario: The main Agent (implemented in Rust + TypeScript) needs to call a "sentiment analysis Agent" implemented in Python. This Agent provides the sentiment_analyze tool, which takes a text string as input and outputs a JSON object containing sentiment (positive / negative / neutral) and confidence (0-1).

[0271] The specific execution flow of this embodiment is as follows:

[0272] Step S1: Tool interface convergence. The main agent exposes only three tool definitions—exec, write_to_var, and write_to_var_json—to the large language model. Regardless of whether the underlying tool is implemented locally or by a remote Python agent, the LLM indirectly calls it by writing TypeScript code through the unified exec interface, without needing to know the actual deployment location of the tool.

[0273] Step S2: Type Information Injection. When the remote Python Agent starts, it reports its tool list to the main Agent through the bridge registration interface. During the initialization phase, the main Agent's tool scheduling and routing module calls Bridge::list_tools() to obtain the remote tool list and maintains the tool_to_source mapping table.

[0274] tool_to_source.insert("sentiment_analyze".to_string(), ToolSource::Bridge);

[0275] Meanwhile, the system manually or semi-automatically defines the return type of the remote tool using Rust structs (or automatically generates it via IDL), and generates the corresponding TypeScript type declaration file (.d.ts):

[0276] / / Automatically generated .d.ts type declaration file

[0277] declare module 'sentiment' {

[0278] export function sentiment_analyze(params: { text: string}):Promise<{

[0279] sentiment: "positive" | "negative" | "neutral";

[0280] confidence: number;

[0281] }>;

[0282] }

[0283] When the main agent's current skill requires the use of sentiment analysis capabilities, the `related_tools` field in the skill configuration includes `sentiment_analyze`. The type declaration and tool documentation injection module loads the corresponding TypeScript type declaration file and API reference information for the tool, and injects the system prompt words from the large language model.

[0284] Step S3: Code Reception. The system receives intermediate scripting language (MTL) code with type annotations generated by the large language model based on the injected type information. The user instruction is: "Analyze the sentiment of the user comment 'The product is amazing!'". The LLM generates the following TypeScript code based on the injected type declarations and submits it via the exec interface:

[0285] / / Define the sentiment analysis result type (matching the structure returned by remote tools)

[0286] interface SentimentResult {

[0287] sentiment: "positive" | "negative" | "neutral";

[0288] confidence: number;

[0289] }

[0290] / / Call remote sentiment analysis tool

[0291] import { sentiment_analyze} from 'sentiment';

[0292] import { report} from 'hubris';

[0293] const result = await sentiment_analyze({ text: "The product isamazing!"}) as SentimentResult;

[0294] report({ text: `sentiment: ${result.sentiment}, confidence: ${result.confidence}`}); / / Report analysis results

[0295] Step S4: Code parsing and verification. The main agent's intermediate scripting language execution engine with type annotations receives the TypeScript code, performs syntax parsing to construct an abstract syntax tree (AST), and performs AST security verification on the AST, detecting and rejecting dangerous syntax patterns such as `eval()` and dynamic `import`. After successful verification, proceed to the next stage.

[0296] Step S5: Type processing and script generation. Type stripping is performed on the verified code, removing all TypeScript type annotations (such as the SentimentResult type annotation), generating a pure JavaScript AST, and then converting it back to a JavaScript source code string to obtain executable script code. In actual deployment, resource constraint parameters (such as execution time, loop count, recursion depth, and memory usage limit) can be configured for the script execution environment to prevent abnormal code from affecting system stability.

[0297] Step S6: Script execution and indirect tool invocation. The generated JavaScript code is executed in the embedded JavaScript engine. The `sentiment_analyze` function imported by the `import` statement in the code is parsed to the pre-registered synthesis module by the module registration mechanism of the embedded script engine. Its corresponding exported members are bound to the standardized tool invocation callback function, which is converted into a tool invocation request `{ tool_name: "sentiment_analyze", parameters: { text: "The product is amazing!"}}`, and forwarded to the tool scheduling routing module through the unified callback function.

[0298] Step S7: Permission Verification and Unified Distribution. After receiving the call request, the access control module first performs a permission whitelist check to verify whether the current Agent is allowed to call the sentiment_analyze tool. If the verification passes, the request is forwarded to the tool scheduling and routing module via the unified entry point for routing decisions.

[0299] Step S8: Tool routing call. The tool scheduling routing module queries the tool_to_source mapping table and finds that the source corresponding to sentiment_analyze is ToolSource::Bridge. The system calls HapLotesBridge.call("sentiment_analyze", parameters), and this bridge layer encapsulates the request as a JSON-RPC message.

[0300] {

[0301] "jsonrpc": "2.0",

[0302] "method": "tools / call",

[0303] "params": {

[0304] "name": "sentiment_analyze",

[0305] "arguments": {

[0306] "text": "The product is amazing!"

[0307] }

[0308] },

[0309] "id": 1

[0310] }

[0311] Send to the Python Agent via a pre-established Unix Socket (for high-security, low-latency scenarios; alternatively, a TCP Socket can be used for cross-host or HTTPS public network scenarios).

[0312] The Python Agent receives a JSON-RPC request, calls the local sentiment_analyze function (e.g., using the transformers library to load a sentiment analysis model), obtains the result {"sentiment": "positive", "confidence": 0.99}, and encapsulates it as a JSON-RPC response to return.

[0313] Step S9: Variable storage. The bridging layer of the main agent receives the response, extracts the result, and returns it to the tool scheduling and routing module. The tool then uses the callback mechanism of the indirect call module to pass the result back to the script engine. The script engine assigns the result to the `result` variable and stores it in the persistence context. The LLM does not need to be aware that the underlying process is a remote call; the entire asynchronous call process is transparent to the LLM.

[0314] Step S10: Structured data validation injection. If the structured data returned by the Python Agent needs to be reused by multiple subsequent exec code snippets, the system can choose to inject the result as a persistent variable using the write_to_var_json tool. However, in this embodiment, the result variable is already directly stored in the script engine's persistence context, and subsequent exec code can directly reference it, such as result.sentiment, without the need for additional injection.

[0315] Step S11: Audit Recording. The operation audit log module records complete audit information for this remote tool call at a unified entry point, including: RFC 3339 format timestamp; tool name; parameter summary (first 120 characters), execution status, result summary, communication latency (Unix Socket round-trip latency), and Agent identifier. Even if the remote call fails, such as when the PythonAgent crashes, the error information is still recorded. The log uses a bounded FIFO buffer to manage memory usage, with a maximum of 200 records; when this limit is exceeded, the oldest entry is automatically discarded.

[0316] Extended scenarios in this embodiment:

[0317] The bridging mechanism in this embodiment can be extended to the following scenarios:

[0318] Calling third-party REST APIs: By converting the OpenAPI specification into TypeScript type declarations, LLM can directly write code in the style of `import { repos} from 'github_api'; repos.list()` to call the GitHub API.

[0319] Calling gRPC services: TypeScript type declarations are generated from proto files, and the bridging layer converts gRPC calls into JSON-RPC over HTTP / 2.

[0320] Calling legacy system SOAP services: Type declarations are generated through WSDL, and the bridging layer handles SOAP envelope encapsulation and parsing.

[0321] Cross-host deployment: The transport layer is replaced from Unix Socket to TCP Socket or HTTPS, supporting distributed agent deployment.

[0322] Type Change Tracking: When the sentiment analysis return structure of the Python Agent changes (e.g., by adding an `explanation` field), the corresponding Rust struct definition is updated, and the system re-executes the build to generate a new `.d.ts` file. Git diffs clearly display the type change history, allowing developers to update the type declarations in the LLM prompts accordingly, ensuring that the code generated by the LLM matches the actual return structure of the remote tool.

[0323] The beneficial effects of this embodiment are as follows: First, in existing technologies, calling heterogeneous services typically requires writing separate tool wrapper code for each service. This embodiment, however, achieves "declarative" remote tool integration through a bridging layer and unified routing mapping. Second, the automatic type declaration generation mechanism (Rust→TypeScript) can be extended to cross-language scenarios, maintaining the type safety advantage of the main agent without weakening through IDL (such as Protocol Buffers, Thrift) or other code generators. Third, remote tool calls and local tool calls are completely consistent from the LLM's perspective (both use a unified ES Module import statement), eliminating the need for the LLM to distinguish the underlying implementation and reducing cognitive burden. Fourth, the unified entry point's audit logs can form a complete call chain across local and remote calls, solving the audit fragmentation problem in a distributed agent environment. Fifth, the UnixSocket communication method avoids the connection management and network layer packet overhead of the HTTP protocol stack, but still requires JSON serialization to complete cross-process data transmission, thus reducing overall communication latency compared to HTTP calls. This embodiment demonstrates the high scalability and transparency of the system in heterogeneous technology stack integration scenarios.

[0324] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.< / string> < / string>

Claims

1. A multi-agent tool invocation system, characterized by, include: Minimize tool interface module: Used to provide code execution interface, text variable writing interface and structured data variable writing interface to large language models; The code execution interface serves as the sole indirect entry point for all MCP tool calls, and is used to receive intermediate script language code with type annotations submitted by the large language model; Type Declaration and Tool Documentation Injection Module: When a skill is activated, based on the associated tool information in the current skill configuration, the module injects the corresponding intermediate scripting language type declaration file with type annotations into the large language model system prompt word, and injects the MCP tool documentation formatted as intermediate scripting language API reference information with type annotations. An intermediate scripting language execution engine with type annotations: This engine receives intermediate scripting language code with type annotations from the code execution interface, performs compilation processing on the code to generate executable script code, and the compilation processing adopts a four-level execution pipeline, including a syntax parsing stage, an AST security verification stage, a type stripping stage, and a code generation and execution stage. The embedded script engine serves as the underlying carrier of the intermediate scripting language execution engine with type annotations. The processed script code is handed over to the embedded script engine for execution. At the same time, the embedded script engine maintains a persistent execution context across calls, so that script variables remain alive across multiple calls. Tool indirect call module: During the execution of the script code, the ES Module import statement is parsed to the pre-registered composition module through the module registration mechanism of the embedded script engine. Each exported member in the composition module is bound to a standardized tool call callback function, which is then converted into a standardized tool call request. The standardized tool call request is forwarded to the access control module through a unified callback function. Access control module: used to receive tool call requests via a unified entry function and perform permission verification on the permission whitelist based on Agent-tool; Tool scheduling and routing module: used to receive the tool call request that has passed the permission verification, and route the request to the corresponding execution node according to the preset tool source mapping table; the unified entry function is shared by the access control module and the tool scheduling and routing module, and all tool call requests enter the processing flow through this unified entry function; Variable storage module: Used to receive the return results of all tools and save the results in the persistent context maintained by the embedded script engine for direct access by subsequent code, without consuming the large language model context token; Structured data validation injection module: used to respond to the call of the structured data variable writing interface, perform two-stage validation on the JSON string to be injected, and then inject it as a native script object of the embedded script engine; Operation audit log module: used to record audit information for each tool call at a unified entry point; the unified entry point is a centralized processing location that all tool call requests must pass through, and also serves the access control module's permission verification and the tool scheduling and routing module's routing distribution.

2. The multi-Agent tool invocation system according to claim 1, characterized in that: In the minimized tool interface module, the text variable writing interface is used to save ordinary text or string variables, avoiding the need for large language models to manually handle escaping and concatenation in the code; the structured data variable writing interface is used to write structured data variables to the script execution environment, so that subsequent code can directly access nested fields in the form of native objects.

3. The multi-Agent tool invocation system according to claim 1, characterized in that: The type declaration and tool documentation injection module automatically generates intermediate script language type declaration files with type annotations through the compiled system language structure. When the tool return structure on the compiled system language side changes, the corresponding type declaration file is automatically regenerated through derived macros during the recompilation process. Furthermore, the system determines the set of tools required for the current task based on the associated tool information in the current skill configuration. Only the interface declarations, data structure descriptions, and tool documentation type references corresponding to the tool set are loaded and injected into the large language model prompt information, so that the tool interface definition, tool documentation, and data structure of the script execution environment remain synchronized.

4. The multi-Agent tool invocation system according to claim 1, characterized in that: In the intermediate scripting language execution engine with type annotations, the syntax parsing stage involves using a script parser to convert the source code into an abstract syntax tree and capture syntax errors. The AST security verification phase involves traversing the AST to detect and reject dangerous syntax patterns, preventing users from performing dangerous operations by calling tools, and refusing to execute and returning an error when a dangerous syntax pattern is detected. The type stripping stage involves removing all type annotations to generate a pure scripting language AST, enabling lightweight runtime execution. The code generation and execution phase involves converting the scripting language AST back into a source code string and executing it in the embedded script engine, while maintaining a persistent execution context and storing the tool's return value to avoid consuming LLM context tokens.

5. The multi-Agent tool invocation system according to claim 1, characterized in that: The variable storage module uses an embedded script engine to maintain a persistent execution context. The tool's return results are stored in the execution context as variables, and subsequent code execution can directly access these variables to complete data processing. The tool's return results do not require re-entering the large language model context, and the complete recursive nested data structure can be traversed, filtered, and analyzed in the script execution environment.

6. The multi-Agent tool invocation system according to claim 1, characterized in that: The tool indirect call module parses the ES Module import statement to the pre-registered composition module through the module registration mechanism of the embedded script engine. Each exported member in the composition module is bound to a standardized tool call callback function, which is then converted into a tool call request. The tool call request is forwarded to the access control module for permission verification through the unified callback function in the embedded script engine. After the verification is successful, it is forwarded to the tool scheduling and routing module. The tool scheduling and routing module maintains the mapping relationship between tool names and tool sources. The tool sources include local tools, remote bridging tools, and skill tools, and executes local calls, remote bridging calls, or skill tool calls according to the tool sources.

7. The multi-Agent tool invocation system according to claim 1, characterized in that: The access control module adopts a three-layer access control mechanism, specifically including: Tool definition filtering: Only expose code execution interface, text variable writing interface and structured data variable writing interface to LLM; Permission whitelist check: Based on skill configuration, access permissions are defined by Agent-tool pair, and the caller is verified to have permission to access the target tool before the call is made; Centralized execution through a unified entry point: All tool calls must enter the tool scheduling and routing module for processing through the unified entry function. This module works in conjunction with the access control module for centralized control, rate management, retry, and timeout control. The operation audit log module records operation logs at the unified entry point to prevent bypassing access control.

8. The multi-Agent tool invocation system according to claim 1, characterized in that: The structured data validation injection module performs two-stage validation injection through the structured data variable writing interface. In the first stage, the JSON parsing library of the compiled system language is used to validate the JSON format of the input string, and when the validation fails, it returns error information including the error type, error location and content preview. The second stage uses the script engine's JSON parsing function to parse the validated JSON string into a native script object and assign it to a variable in the script execution environment so that subsequent code can directly access nested fields.

9. The multi-Agent tool invocation system according to claim 1, characterized in that: The operation audit log module records the audit information of all MCP tool calls at a unified entry point. The audit information includes timestamps, tool names, parameter summaries, execution status, result summaries, and error information. A bounded buffer is used to manage the audit data. When the number of entries reaches a preset threshold, the eliminated entries are automatically dumped to persistent storage media through a pluggable audit persistence interface. The audit log performs hash calculations on the tool call parameters for tamper-proof verification and supports merged querying and exporting from the memory buffer and persistent storage by time range and caller identifier to form a traceable and replayable audit chain.

10. A method for invoking a multi-agent tool, applied to the multi-agent tool invoking system according to any one of claims 1-9, characterized in that, Includes the following steps: Step S1: Tool interface convergence, exposing only the code execution interface, text variable writing interface, and structured data variable writing interface to the large language model, and using the code execution interface as the only indirect entry point for MCP tool calls; Step S2: Type information injection. Determine the set of available tools based on the associated tool information in the current skill configuration, load the interface declaration file, data structure description information and tool document type reference information corresponding to the set of available tools as needed, and inject the large language model prompt information. Step S3: Code reception. The system receives intermediate script language code with type annotations generated by the large language model based on the injected type information. The intermediate script language code with type annotations includes tool invocation logic, data processing logic, and task execution flow. Step S4: Code parsing and verification. Perform syntax parsing on the intermediate scripting language code with type annotations, construct the AST, and perform security verification on the AST, rejecting code execution requests with dangerous syntax patterns. The dangerous syntax patterns include: dangerous function calls, dynamic module loading, and illegal object access; Step S5: Type processing and script generation. Perform type stripping on the type annotations in the code, remove all type annotations, and generate executable script code. Step S6: Script execution and indirect tool invocation. The script code is executed in the embedded script execution environment, and a tool invocation request is initiated through the ES Module import statement. Step S7: Permission verification and unified distribution. When the script code initiates a tool call request, the target tool is verified against the Agent-Tool permission whitelist, and the verified tool call request is forwarded to the tool scheduling and routing module through the unified entry point. Step S8: Tool routing call. After the verification in step S7 is passed, the tool call request is routed to the local tool, remote bridging tool, or skill tool for execution based on the mapping relationship between the tool name and the tool source. Step S9: Variable storage. After step S8 is completed, the tool execution result is saved to the variable storage space of the script execution environment so that subsequent code can directly reference and reuse the tool execution result. Step S10: Structured data validation injection. When a structured data variable write request is received, the JSON format validity of the JSON string to be injected is validated. After the validation is passed, the structured data is parsed into a native object in the script execution environment and injected into the runtime context. Step S11: Audit Logs. Record the audit logs corresponding to the tool call process at the unified entry point to achieve traceable management of cross-Agent call behavior.

Images