Local function invocation systems, methods, devices, media, and program products

Abstract

The embodiment discloses a local function calling system, method, device, medium and program product, wherein the local function calling system is applied to an Electron client, and the local function calling system comprises a main process layer and a rendering process layer; the rendering process layer comprises an MCP adapter; the MCP adapter is used for interacting with an AI application layer; wherein the rendering process layer is used for receiving a first request sent by the AI application layer through the MCP adapter, and sending the first request to the main process layer; the first request is a function list acquisition request or a function calling request; the function list acquisition request is used for acquiring a function list in the main process layer, and the function calling request is used for calling a function in the main process layer; and the main process layer is used for generating first response information based on the first request, and sending the first response information to the rendering process layer.

Description

Technical Field

[0001] This application belongs to the field of software engineering technology, and in particular relates to a local function call system, method, device, medium and program product. Background Technology

[0002] As Large Language Models (LLMs) acquire tool-calling capabilities, the need has grown to include providing local functionalities (such as file systems, clipboard, notifications, window management, network requests, and enterprise internal control functions) to Artificial Intelligence (AI) applications in a secure and controllable manner using a unified protocol. The desktop application development framework Electron, by integrating the rendering capabilities of the cross-platform open-source web browser Chromium with the native system capabilities of Node.js, can build a cross-platform desktop application development environment that can both render web pages and directly call operating system native functions. This allows developers to directly and efficiently call operating system native functions and system-level application programming interfaces (APIs). However, the current Electron client lacks standardized tool exposure methods and result feedback mechanisms for AI applications, hindering standardized integration between the Electron client and AI applications. Summary of the Invention

[0003] This application provides a local function call system, method, device, medium, and program product, and presents a standardized tool exposure method and result feedback mechanism for AI applications based on an Electron client, realizing standardized interface between the Electron client and AI applications.

[0004] This application provides a local function call system applied to an Electron client. The Electron client includes a main process layer and a rendering process layer. The rendering process layer includes a Model Context Protocol (MCP) adapter. The MCP adapter is used to interact with the AI ​​application layer. The rendering process layer is used to receive a first request sent by the AI ​​application layer through the MCP adapter, and send the first request to the main process layer; the first request is a function list retrieval request or a function call request; the function list retrieval request is used to retrieve the function list in the main process layer, and the function call request is used to call the function in the main process layer; The main process layer is used to generate first response information based on the first request and send the first response information to the rendering process layer.

[0005] This application embodiment also provides a local function invocation method, applied to a local function invocation system in an Electron client, wherein the Electron client includes: a main process layer and a rendering process layer; the rendering process layer includes an MCP adapter; the MCP adapter is used to interact with the AI ​​application layer; the method includes: The MCP adapter receives a first request sent by the AI ​​application layer; the first request is a function list retrieval request or a function call request; the function list retrieval request is used to retrieve the function list in the main process layer, and the function call request is used to call the function in the main process layer. Generate a first response based on the first request.

[0006] This application provides an electronic device, which includes a processor and a memory for storing computer programs capable of running on the processor; wherein, The processor is used to run the computer program to execute the aforementioned local function call method.

[0007] This application provides a computer storage medium storing a computer program that, when executed by a processor, implements the aforementioned local function call method.

[0008] This application provides a computer program product, including a computer program that, when executed by a processor, implements the aforementioned local function invocation method.

[0009] This application provides a local function invocation system, method, device, medium, and program product. By adding an MCP adapter to the rendering process layer of the Electron client, the Electron client can interact with AI applications through the MCP adapter. The first request sent by the AI ​​application layer is sent to the main process layer, and the main process layer returns the first response information to the first request of the AI ​​application layer, that is, it returns the list of functions requested by the AI ​​application layer or the local functions requested to be invoked. This realizes a standardized tool exposure method and result feedback mechanism for the Electron client to AI applications, enabling the AI ​​application layer to invoke local functions based on the local function invocation system proposed in this application, and realizing standardized docking between the Electron client and AI applications. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of a local function call system structure provided in an embodiment of this application; Figure 2 This is a flowchart of a function invocation method based on an Electron client provided in an embodiment of this application; Figure 3 This is a schematic diagram of a call timing provided in an embodiment of this application; Figure 4 This is a flowchart of a local function invocation method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] As large language models acquire tool-calling capabilities, the need is growing for how to provide local functions, such as local desktop application capabilities (e.g., file system, clipboard, notifications, window management, network requests, enterprise internal control functions, etc.), to AI applications in a unified, secure, and controllable manner. Examples of such applications include the Claude model and the Chat Generative Pre-trained Transformer (ChatGPT).

[0013] Electron, as a cross-platform desktop runtime, can integrate Chromium's rendering capabilities with Node.js's native system capabilities to build a cross-platform desktop application development environment that can both render web pages and directly call operating system functions, enabling developers to directly and efficiently call the operating system's native functions and system-level APIs.

[0014] However, the current Electron framework lacks standardized tools for AI applications, as well as mechanisms for permission management, parameter validation, and result feedback. Therefore, there is an urgent need for a method and system to convert local client functionality into MCP tools within the Electron framework, enabling standardized integration with AI applications, fine-grained permission control, sandboxed secure execution, and stable streaming returns.

[0015] To address the aforementioned issues, this application provides a local function invocation system capable of standardized integration between Electron clients and AI applications. The embodiments of this application are further described in detail below with reference to the accompanying drawings and examples. It should be understood that the embodiments provided herein are merely illustrative and not intended to limit the scope of this application. Furthermore, the embodiments provided below are only some embodiments for implementing this application, and not all embodiments. Unless otherwise specified, the technical solutions described in this application can be implemented in any combination.

[0016] It should be noted that, in the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a method or apparatus that includes a series of elements includes not only the elements expressly described, but also other elements not expressly listed, or elements inherent to implementing the method or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of other related elements in the method or apparatus that includes that element (e.g., steps or devices in the method, units or modules in the system; for example, a device, unit, or module in the system may be a portion of circuitry, a portion of a processor, a portion of a program or software, etc.).

[0017] The local function invocation system provided in this application includes a series of modules. However, the system provided in this application is not limited to the modules explicitly described, but may also include modules needed to obtain relevant information or process information. Similarly, the local function invocation method provided in this application includes a series of steps, but the local function invocation method provided in this application is not limited to the steps described.

[0018] Figure 1 A schematic diagram of a local function call system architecture is shown. Figure 1 The local function call system 10 shown is applied to the Electron client. The local function call system 10 includes a rendering process layer 101 and a main process layer 102. The rendering process layer 101 includes an MCP adapter 1011. The MCP adapter 1011 is used to interact with the AI ​​application layer (not shown in the figure). Figure 1 In the local function call system 10 shown: The rendering process layer 101 is used to receive the first request sent by the AI ​​application layer through the MCP adapter 1011 and send the first request to the main process layer 102.

[0019] The first request is either a function list retrieval request or a function call request; the function list retrieval request is used to retrieve the function list in the main process layer 102, and the function call request is used to call the functions in the main process layer 102.

[0020] MCP is an open standard designed to unify standardized, secure, and efficient bidirectional communication between large models and external data sources, as well as between various functions (tools). MCP's main purpose is to address the current challenge of AI models being unable to fully realize their potential due to data silos. The application of MCP enables AI applications to securely access and manipulate local and remote data, providing an interface for AI applications to connect to everything. LLM is an artificial intelligence model designed to understand and generate human language. Trained on massive amounts of text data, it can perform a wide range of tasks, including text summarization, translation, sentiment analysis, and more. LLMs are characterized by their massive parameter scale, typically containing billions of parameters, which help them learn complex patterns in language data. These models are often based on deep learning architectures, such as transformers, helping them achieve impressive performance on various Natural Language Processing (NLP) tasks.

[0021] In this embodiment, the AI ​​application layer can include different types of AI applications, such as different large models. The AI ​​application layer receives user input data or input commands through AI applications, determines the user's needs through the intent recognition module, and determines whether one or more of the following is required: local function call, remote function call, etc. The local function can refer to the function called from the main process layer, i.e., the function obtained from the main process layer.

[0022] When the intent recognition module of the AI ​​application determines that a local function call is required, the AI ​​application sends a first request to the rendering process layer 101. This first request is a function list retrieval request, which may include "tools / list". The AI ​​application uses this request to obtain the local function list. Once the AI ​​application obtains the local function list, it can determine the target function based on it and generate a call request for that function, i.e., a function call request. This function call request may include "tools / call", and the AI ​​application sends this request to the rendering process layer 101 to obtain the target function.

[0023] Specifically, the local function call system 10 described in this application embodiment is applied to an Electron client. In practical applications, the main process layer and rendering process layer of the local function call system can specifically be the main process layer and rendering process layer of the Electron client. Based on the local function call system 10, an MCP adapter 1011 can be set in the rendering process layer of the Electron client, enabling the Electron client to receive the first request sent by the AI ​​application layer. The rendering process layer 101 (or MCP adapter 1011) is the unified interaction entry point between the local function call system 10 and the AI ​​application layer. It receives the first request from the AI ​​application layer through the MCP adapter 1011 and sends the first request to the main process layer 102 for processing.

[0024] In this embodiment, the MCP adapter 1011 based on the local function call system can specifically support two transmission modes: stdio (local) and WebSocket (remote / multi-process), including heartbeat and back pressure control; it can return unified error codes and stream results; as a unified access point for AI applications, the MCP adapter 1011 provides a standardized MCP protocol interface.

[0025] The main process layer 102 is used to generate first response information based on the first request and send the first response information to the rendering process layer 101.

[0026] The main process layer 102 receives a first request forwarded from the rendering process layer 101 and generates a first response message based on the type of the first request. For example, when the first request is a function list retrieval request, the main process layer 102 determines the list of all tools supported by the system resources based on the function list retrieval request, obtains the function list, and sends the function list as the first response message to the rendering process layer 101; when the first request is a function call request, the main process layer 102 can determine the specific target function to be called based on the function call request, call the target function in the system resources to obtain the first response message, and send the first response message to the rendering process layer 101.

[0027] After receiving the first response information, the rendering process layer 101 can send the first response information to the AI ​​application layer through the MCP adapter 1011.

[0028] Specifically, the main process layer 102 may include an inter-process communication (IPC) bridging module. The IPC bridging module is used to securely pass call context and results between the main process layer 102, the rendering process layer 101, and various child processes, avoiding the transmission of non-serialized objects; the IPC bridging module supports bidirectional communication between the unified interaction layer of the rendering process and the core services of the main process layer, and can provide a high-performance IPC channel, supporting streaming data transmission and real-time state synchronization.

[0029] In practical applications, the main process layer 102 can interact with the rendering process layer 101 through the IPC bridging module. For example, the rendering process layer 101 sends the first request to the IPC bridging module, and the IPC bridging module sends the first response information to the rendering process layer 101.

[0030] This application provides a local function call system 10 applied to an Electron client. Based on the local function call system 10, an MCP adapter 1011 can be added to the rendering process layer of the Electron client, enabling the rendering process layer of the Electron client to interact with AI models. This allows the AI ​​models to call local functions through the MCP adapter 1011, achieving standardized integration between the Electron client and AI applications, and expanding the application scenarios for local function calls, especially for large AI models. In practical applications, the rendering process layer 101 and the main process layer 102 can be implemented based on a processor and communication device.

[0031] As can be seen from the above embodiments, the local function call system 10 is mainly used to support the AI ​​application layer to call local functions. Therefore, in order to ensure that the first request received is a local function call request, in some embodiments, the rendering process layer also includes a verification module. When the first request is a function call request, the MCP adapter 1011 is used to send the first request to the verification module after receiving the first request. The verification module is used to verify the first request. When the first request is verified to be to obtain a function in the main process layer, the first request is sent to the main process layer.

[0032] The rendering process layer 101 includes a verification module, which can serve as a front-end entry point for the rendering process layer 101. This module only receives the first request sent by the MCP adapter 1011 and verifies the first request. Specifically, when an AI application needs to call a local function, the first request generated by the AI ​​application may include "toolType='local'", indicating that the first request is for calling a local function.

[0033] When the first request is a function call request, such as "tools / call", the verification module can analyze and identify the fields in the first request. If it determines that the first request includes "toolType='local'", it considers the first request to be for a local function and forwards the first request to the main process layer 102 (specifically, the IPC bridge module of the main process layer 102). When the first request is not for a local function call, for example, if the first request does not include "toolType='local'", or if the first request includes a remote call "toolType='remote'", the verification module fails, and the AI ​​application layer will directly call the external service to invoke the remote function.

[0034] Specifically, the verification module can perform local routing and rate limiting on the first request based on one or more of the following: schema definition, policy hints, and historical auditing. For example, it can dynamically adjust the routing path or rate limiting threshold based on one or more of these criteria to verify the first request. When the verification module performs verification based on schema, it can uniformly define the data structure, field types, and legal range of the first request as the basic rules for routing and rate limiting, verifying whether the first request is used to obtain functions in the main process layer 102. When the verification module performs verification based on policy hints, it can dynamically adjust routing and rate limiting rules, supporting flexible context-based control (such as user permissions and service status), to verify whether the first request is used to obtain functions in the main process layer 102. When the verification module performs verification based on historical auditing, it can dynamically optimize the verification rules based on relevant data from historical first requests (such as response time, error rate, and traffic patterns) to verify whether the first request is used to obtain functions in the main process layer 102. This embodiment does not specifically limit the verification method of the verification module.

[0035] It can be seen that by setting a verification module in the rendering process layer 101 and using the verification module as the front entry point of the rendering process layer 101, it can be ensured that the local function call system 10 only processes local function call requests, which helps to improve the efficiency and success rate of local function calls.

[0036] Furthermore, in some embodiments, the rendering process layer further includes a processing module and an extension module. The verification module is specifically used to verify the first request. If the first request is to obtain a function in the main process layer, the first request is sent to the processing module. The processing module is used to call the extension module based on the first request after receiving the first request and send the first request to the main process layer. The extension module is used to extend the front-end function based on the first request.

[0037] In this embodiment, the rendering process layer 101 further includes a processing module and an extension module. When the verification module verifies that the first request is to obtain a function in the main process layer 102, the verification module can send the first request to the processing module, which then sends the first request to the main process layer 102, specifically to the IPC bridge module of the main process layer 102, and simultaneously sends the first request to the extension module. The processing module of the rendering process layer 101 is mainly used to integrate the extension module and provide custom business logic for local functions in conjunction with the extension module. Simultaneously, the processing module can also process the first request sent by the AI ​​application layer, determine the target function, such as file system, system notification, clipboard access, etc., and coordinate with the main process layer to execute secure calls to local functions.

[0038] Extension modules are used to extend front-end functionality in response to the first request. Specifically, an extension module can determine the configuration required for local functionality extension (such as component list, routing rules, permission information, etc.) in the first response information based on the first request. According to these configurations, it can load components, modify routes, or adjust business logic to extend front-end functionality. Specifically, extension modules can be front-end extension layers (FE extensions).

[0039] In order to determine the access rights of AI applications to local functions, in some embodiments, the main process layer includes an authentication module. When the first request is a function call request, the authentication module is used to verify the permissions of the first request based on a preset permission list before generating the first response information.

[0040] The main process layer 102 also includes an authentication module, which includes a preset permission list. The preset permission list may include one or more of the following: a whitelist, a blacklist, and an authorization scope. Through the preset permission list, the authentication module can determine the function call permissions of the AI ​​application corresponding to the current first request. The authentication module authenticates the first request based on the preset permission list to determine whether the first request or the AI ​​application corresponding to the first request has the permission to call the target function.

[0041] The authentication module authenticates the first request, specifically by performing parameter-level authentication. This includes analyzing the context of the first request and related data sent by the AI ​​application, and checking whether specific field values ​​in the first request parameters conform to preset permission rules. For example, authentication can be performed on one or more of the following: the path prefix of the first request, the whitelist of the domain name corresponding to the first request, the maximum number of bytes in the first request, and the time window of the first request.

[0042] The authentication module can also generate authorization credentials to update the preset permission list, and can cache the generated authorization credentials to improve authentication performance. In addition, the authentication module can also include a revocation function to revoke authorization or update the blacklist in case of user active cancellation, AI application permission change, or abnormal AI application behavior, and update the preset permission list in real time. The authentication module can also record and audit authorization events, and use a database table to store audit logs to provide authentication traceability.

[0043] After obtaining the authentication result, the authentication module can return the context corresponding to the authentication result to the IPC bridging module, so that the IPC bridging module can determine whether to execute the first request and obtain the corresponding target function based on the context corresponding to the authentication result.

[0044] The authentication module can also perform collaborative authentication with the rendering process layer 101 to achieve unified permission management. In some embodiments, the main process layer includes an authentication module, and the rendering process layer also includes an interaction module. When the first request is a function call request, the authentication module is used to send an authorization request to the interaction module before generating the first response information; the interaction module is used to receive the user's authorization instruction based on the authorization request; and send the authorization instruction to the authentication module; the authentication module is also used to verify the permission of the first request based on the authorization instruction.

[0045] Specifically, after receiving the first request, the authentication module can send an authorization request to the interaction module of the rendering process layer 101. This authorization request may include information to be authorized, such as the AI ​​application identifier that initiated the first request and the target function. Upon receiving the authorization request, the interaction module can process it and display it to the user through the display interface. The user can then send an authorization command based on the displayed authorization request, indicating whether to authorize or deny the first request. The interaction module then sends the received authorization command to the authentication module, which determines the permission verification result for the first request based on the authorization command.

[0046] In practical applications, the authentication module can directly determine the permission verification result of the first request based on the authorization instruction; or, based on the above embodiments, the authentication module can combine a preset permission list and the authorization instruction to determine the permission verification result of the first request. After the authentication of the first request is completed, the main process layer 102 can call the target function corresponding to the first request based on the first request.

[0047] In this embodiment, the interaction module may include a user authorization interface. The user authorization interface can be a unified permission confirmation interface, supporting fine-grained permission requests and user authorizations. It can also provide users with interactive authorization components for various aspects such as file selection, directory browsing, and network permissions, supporting visualization of permission scope, time-limit settings, and batch authorization management. By integrating the user authorization interface into the front end of the rendering process layer 101, the Electron client can support customized authorization processes and interface styles. The authorization method provided in this embodiment, combined with user authorization, can improve the accuracy and flexibility of authorization.

[0048] Based on the above embodiments, in order to improve the security of local target function calls, in some embodiments, the main process layer further includes a sandbox module, which is used to execute the target function corresponding to the first request and generate the first response information.

[0049] In this embodiment, after the permission verification is passed, the authentication module can return the context corresponding to the authentication result to the IPC bridging module, so that the IPC bridging module can determine that the permission verification is passed based on the context corresponding to the authentication result, and send the first request to the sandbox module, so that the sandbox module can obtain and process the target function.

[0050] The first request is sent to the sandbox module, which then retrieves the target function from system resources, executes it, and generates the first response information. Specifically, the sandbox module can include sub-modules such as the child process module (child_process), the worker thread module (worker_threads), and the Virtual Machine (VM) module. The target function can be executed within each sub-module to obtain the first response information. Furthermore, the sandbox module can support custom execution logic and processing results defined by the aforementioned extension modules. For example, it allows developers to dynamically define code execution rules (such as restricting access permissions or modifying system behavior) and customize the processing of execution results (such as intercepting, transforming, or verifying output).

[0051] In some embodiments, the rendering process layer further includes an extension module and an integration module. The extension module is used to extend the front-end function based on the first request to generate first extension information and send the first extension information to the integration module. The integration module is used to receive the first extension information and the first response information sent by the main process layer, and send the first response information and the first extension information to the MCP adapter 1011. The MCP adapter 1011 is also used to receive the first response information and the first extension information and send the first response information and the first extension information to the AI ​​application layer.

[0052] After receiving the first response information, the main process layer 102 can send the first response message to the integration module. For example, the sandbox module of the main process layer 102 processes the target function corresponding to the first request to obtain the first response information, and sends the first response information to the IPC bridging module, which then sends the first response information to the integration module.

[0053] Based on the extension module described in the above embodiments, after receiving the first request, the extension module can generate first extension information based on the first request. The first extension information is used to extend the front-end functionality. Then, the extension module sends the first extension information to the integration module.

[0054] After receiving the first response information and the first extended information, the integration module integrates the first response information and the first extended information, and sends the first response information and the first extended information to the MCP adapter 1011. The MCP adapter 1011 then sends the first response information and the first extended information to the AI ​​application as the final response information of the first request.

[0055] In practical applications, the integration module can aggregate the output data of the local function call system 10, user interface (UI) callback data, intermediate results, and data generated by the extension module, transmitting each data segment or summarizing them into a result package for transmission. Simultaneously, the integration module also performs data anonymization and truncation, uniformly outputting the processing results of "onChunk" and "final" to the MCP adapter 1011 for streaming consumption by AI applications.

[0056] In summary, the extension module of this application embodiment is used to provide a pluggable front-end business logic extension framework, supporting custom UI components and interaction logic; supporting business-specific tool registration, parameter verification, result processing and user interface customization, providing rich extension APIs, including custom authorization processes, data visualization, real-time feedback, etc., while supporting hot-swapping and dynamic loading, realizing flexible configuration and updates of business logic.

[0057] Based on the local invocation system described in the above embodiments, Figure 2 A flowchart illustrating a function call method based on an Electron client is shown. Figure 2 As shown, the method includes: Step 201: The intent recognition module of the AI ​​application layer 201 sends a function list retrieval request to the MCP adapter 1011.

[0058] The intent recognition module of the AI ​​application layer 201 determines the user's needs. If the user needs to call local functions, it sends a function list retrieval request to the MCP adapter 1011. Specifically, the function list retrieval request can be "MCP:tool / list".

[0059] Step 202: MCP adapter 1011 sends a registration list query request to the IPC bridging module in the main process layer 102.

[0060] Based on the function list retrieval request, the MCP adapter 1011 sends a registration list query request to the IPC bridging module in the main process layer 102. The registration list query request can specifically be a function list retrieval request.

[0061] Step 203: The IPC bridging module requests the function registration module to generate a function description.

[0062] The function registration module registers client-side functionalities, such as functions and class methods, in Electron client applications as MCP tools through decorators, annotations, or explicit registration. It can automatically generate JSON Schema-compliant description files by analyzing type definitions and annotations in the function code, precisely defining the function's data type, required fields, optional value range, data format, and numerical range. The module supports versioning, capability tags, and dependency declarations, allowing for management methods such as those requiring UI interaction, network connectivity, or file access. Furthermore, the module can collaborate with the front-end business extension layer, supporting business-specific tool descriptions and metadata.

[0063] Step 204: The function registration module returns the function list to the IPC bridging module.

[0064] The feature registration module returns a list of features, such as ToolDescriptor[], where ToolDescriptor[] can be a JSON data structure schema.

[0065] Step 205: The IPC bridging module returns a function list to the MCP adapter 1011.

[0066] Step 206: MCP adapter 1011 returns a function list to the intent recognition module.

[0067] The MCP adapter 1011 can generate first response information based on the function list. The first response information can be "MCP: Tools / list Response".

[0068] Step 207: The intent recognition module sends a function call request to the MCP adapter 1011.

[0069] After determining the target function based on the function list, the intent recognition module sends a function call request to the MCP adapter 1011. The function call request is used to call the target function, and the function call request can be "MCP: Tools / call{name, arguments}".

[0070] Step 208: MCP adapter 1011 sends a function call request to the tool gateway / router.

[0071] The tool gateway / router can be the verification module in the above embodiments, and the MCP adapter 1011 can also encapsulate the function call request and send the encapsulated function call request to the tool gateway / router.

[0072] The tool gateway / router verifies the function call request, such as verifying "toolType=local", and performs route distribution. After successful verification, proceed to step 209.

[0073] Step 209: The tool gateway / router sends the function call request to the local tool processing module.

[0074] The local tool processing module can be the processing module in the above embodiments.

[0075] Step 210: The local tool processing module sends the function call request to the front-end business extension layer.

[0076] The local tool processing module specifically processes the business logic of function call requests and sends the processing results to the front-end business extension layer. The front-end business extension layer extends the front-end application based on the business logic processing results, such as enhancing extended metadata and generating first extended information. The front-end business extension layer can be the extension module described in the above embodiments.

[0077] Subsequently, the front-end business extension layer sends the first extension information to the result integrator, which may be the integration module in the above embodiment.

[0078] Step 211: The local tool processing module sends the function call request to the IPC bridge module in the main process layer 102.

[0079] Step 212: The IPC bridging module requests permissions and performs permission verification with the policy engine.

[0080] The IPC bridging module performs context processing on the function call request and requests the permission and policy engine to verify permissions based on the processing result; alternatively, the IPC bridging module can directly send the function call request to the permission and policy engine for authentication. The permission and policy engine can be the authentication module described in the above embodiments.

[0081] Step 213: The permissions and policy engine determines the authentication result based on the user authorization interface.

[0082] This step is optional in the authentication process and can be skipped according to actual needs. Specifically, step 213 may include: Step 213a: The permissions and policy engine sends an authorization request to the user authorization interface. Step 213b: The user authorization interface returns the authorization result based on the user's authorization command.

[0083] Step 214: The permissions and policy engine returns the authentication result to the IPC bridging module and returns the authorization context.

[0084] Step 215: The IPC bridging module notifies the execution of function call processing with the sandbox runner.

[0085] After successful authentication, the IPC bridging module notifies the execution and sandbox runner to perform function call processing. The execution and sandbox runner can be the sandbox module described in the above embodiments.

[0086] Step 216: Execute the function of obtaining target resources from system resources by the sandbox runner.

[0087] The target function corresponding to the function call request can be a file, network data, system API, etc. in system resources.

[0088] Step 217: System resources return the target function to the execution and sandbox runner.

[0089] Afterwards, the execution and sandbox runner process the target function and obtain the first response information.

[0090] Step 218: The sandbox runner returns the first response information to the IPC bridging module.

[0091] After generating the first response information based on the target function, the execution and sandbox runner sends the first response information to the IPC bridge module. Specifically, the execution and sandbox runner can send the first response information to the IPC bridge module in the form of execution chunks.

[0092] Step 219: The IPC bridging module sends the first response information to the result integrator.

[0093] Step 220: The result integrator integrates the information and sends the integrated information to the MCP adapter 1011.

[0094] The integrator then integrates the first response information and the first extended information, and sends the integrated information to the MCP adapter 1011.

[0095] Step 221: MCP adapter 1011 sends the integrated information to the intent recognition module.

[0096] In step 201 above, when the intent recognition module of the AI ​​application layer 201 determines that a remote function needs to be invoked, the intent recognition module sends a remote invocation request to the remote tool processing module. The remote tool processing module performs remote protocol processing based on the remote invocation request and invokes the remote function in the external service. The external service responds remotely and sends the remote function to the remote tool processing module, which then integrates the invoked remote function and sends it to the intent recognition module.

[0097] Based on the local function call system given in the above embodiments, Figure 3 A call timing diagram is shown, including: Step 301: The AI ​​application sends a function list retrieval request to the MCP adapter.

[0098] Step 302: The MCP adapter sends a registration list query request to the IPC bridging module.

[0099] Step 303: The IPC bridging module requests the function registration module to generate a function description.

[0100] Step 304: The function registration module returns the function list to the IPC bridging module.

[0101] Step 305: The IPC bridging module returns a function list to the MCP adapter.

[0102] Step 306: The MCP adapter returns a list of features to the AI ​​application.

[0103] Steps 301 to 306 belong to the tool (function) discovery stage, and steps 307 to 319 belong to the local tool (function) invocation stage.

[0104] The implementation of steps 301 to 306 can refer to steps 201 to 206 above.

[0105] Step 307: The AI ​​application sends a function call request to the MCP adapter.

[0106] Step 308: The MCP adapter sends a function call request to the tool gateway / router.

[0107] The implementation of steps 307 to 308 can refer to steps 207 to 208 above.

[0108] Step 309: The tool gateway / router sends the function call request to the IPC bridging module.

[0109] This step can also be implemented by referring to steps 209 to 211 above.

[0110] Step 310: The IPC bridging module requests permissions and performs permission verification with the policy engine.

[0111] Step 311: The permissions and policy engine requests the authentication result through the user authorization interface.

[0112] This step can be referenced from steps 213a and 213b above. The permissions and policy engine requests user authorization from the user authorization interface, which receives the user authorization instruction by displaying an authorization pop-up window. Afterwards, the user authorization interface generates authorization credentials based on the user's input information and sends them to the permissions and policy engine.

[0113] Step 312: The permissions and policy engine returns authentication success information to the IPC bridging module and returns the authorization context.

[0114] Step 313: The IPC bridging module notifies the execution of function call processing with the sandbox runner.

[0115] Steps 312 and 313 can be referred to in detail to steps 214 to 215 above.

[0116] Step 314: Execute the sandbox runner to obtain raw functions from system resources.

[0117] Step 315: System resources return the raw results to the execution and sandbox runner.

[0118] Steps 314 and 315 can be referred to steps 216 to 217 above. Afterwards, the execution and sandbox runner can send the first response information to the IPC bridging module via execution chunking based on the following steps.

[0119] Step 316: Execute the sandbox runner to return progress block information to the IPC bridging module.

[0120] For example, the execution and sandbox runner returns progress block information to the IPC bridging module: executionchunk{type: "progress", data}.

[0121] Step 317: The IPC bridging module returns the chunked data to the result integrator.

[0122] Step 318: The results integrator updates the data to the MCP adapter and returns the progress.

[0123] Step 319: The result integrator updates the data to the MCP adapter and returns that the current data chunk transfer is complete.

[0124] Step 320: The MCP adapter returns the current data block to the AI ​​application.

[0125] Step 321: Execute the sandbox runner to update data to the IPC bridging module and return the last data block.

[0126] For example, the execution and sandbox runner returns progress block information to the IPC bridging module: executionchunk{type: "final", data}.

[0127] Step 322: The IPC bridging module returns the final data to the result integrator.

[0128] The result integrator can combine the first extended information output by the extended module in the above embodiments to integrate the business enhancement data.

[0129] Step 323: The results integrator updates the data to the MCP adapter and returns the final data.

[0130] Step 324: The MCP adapter returns the final data to the AI ​​application.

[0131] The MCP adapter ultimately returns a "Tools / call" response to the AI ​​application.

[0132] This application provides a local function invocation system that uses a unified protocol (such as the MCP protocol for large models and locally adapted custom protocols) to "tool" any Electron client function, reducing the access cost of AI models. Unified access to AI models is achieved through the rendering process layer, simplifying the integration of AI applications. The local function invocation system in this application reduces the risk of unauthorized access through parameter-level policies, user authorization, sandboxing, and resource whitelisting, achieving secure invocation of local functions. Additional business security controls are provided through extension modules, offering more precise permission control strategies for AI model intent recognition. In the local function invocation system provided in this application, any front-end business can be customized into an MCP tool, providing rich customization capabilities, including UI components, business logic, authorization processes, and result processing, meeting the personalized needs of different business scenarios and offering greater flexibility. Unified interaction through the rendering process layer simplifies the access process for AI applications, and the front-end business extension framework reduces business logic development costs and improves development efficiency. By encapsulating business functions into MCP plugins, users only need to describe their needs in natural language to obtain accurate services through AI applications, further enhancing the user experience.

[0133] Based on the local function invocation system provided in this application, the "callable boundary" of AI applications is moved forward to the Electron client, forming a dual-track interaction for AI applications: "direct connection to cloud services from the cloud (remote tools) + direct connection to the client's MCP from the client side (local tools)." This achieves both open local functions and maintains clear security boundaries and user-perceptible authorization. By embedding the MCP in the client and sinking the MCP service endpoint to the Electron client (exposing tools / list and tools / call in the rendering process), AI applications can directly connect to the local MCP to obtain and invoke local functions. AI applications can first classify local and remote functions based on a requirement list. Local functions can be invoked through the MCP; remote tools are directly connected to the cloud by the AI ​​application without executing the call path through the client, realizing a dual-track processing method of local / remote. Through local calls, the client completes the "static policy + pop-up authorization (Grant) + sandbox (whitelist / time limit / memory limit / frequency limit / path virtualization) + streaming return" strategy, realizing a closed-loop security system on the client side. The AI ​​application retrieves a list of functions and a JSON schema (including toolType) by calling the client's tools / list. Remote functions can be categorized using only metadata. The AI ​​application can determine whether to call a local function on its own side, and only initiates the first request tools / call to the Electron client if it determines that a local function call is needed. The Electron client can compare the first request with the registered toolType; if the comparison result is inconsistent, it can reject the function call, ensuring that the remote call does not end up being executed on the client side. The Electron client can also trigger a UI pop-up to obtain parameter-level authorization (scope / duration / revocability), issue a grant, and access local functions in the sandbox according to the whitelist, streaming progress, data fragmentation, and final results via MCP.

[0134] Based on the local function call system given in the above embodiments, Figure 4 A flowchart of a local function call method is shown, applied to a local function call system in an Electron client. The system includes: a main process layer and a rendering process layer; the rendering process layer includes an MCP adapter; the MCP adapter is used to interact with the AI ​​application layer; the method includes: Step 401: Receive the first request sent by the AI ​​application layer through the MCP adapter.

[0135] The first request is either a function list retrieval request or a function call request; the function list retrieval request is used to obtain the function list in the main process layer, and the function call request is used to call the function in the main process layer.

[0136] Step 402: Generate the first response information based on the first request.

[0137] In practical applications, steps 401 to 402 can be implemented based on a processor, which can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor.

[0138] In some embodiments, generating first response information based on a first request includes: verifying the first request, and generating first response information based on the first request if the first request is verified to be for obtaining a function in the main process layer.

[0139] Specifically, the first request can be sent to the verification module of the above embodiment through the MCP adapter; the verification module verifies the first request, and if the first request is to obtain the function in the main process layer, the verification module sends the first request to the main process layer.

[0140] In some embodiments, the method further includes: verifying the first request, and if the first request is to obtain functions in the main process layer, extending the front-end functions based on the first request.

[0141] Specifically, the first request can be verified by the verification module of the above embodiment. If the first request is to obtain the function in the main process layer, the verification module sends the first request to the processing module of the above embodiment. The processing module sends the first request to the main process layer and calls the extension module of the above embodiment. The extension module extends the front-end function based on the first request.

[0142] In some embodiments, before generating the first response information, the method further includes: performing permission verification on the first request based on a preset permission list.

[0143] Specifically, the authentication module in the above embodiment can perform permission verification on the first request based on a preset permission list.

[0144] In some embodiments, before generating the first response information, the method further includes: sending an authorization request; and, upon receiving an authorization instruction from the user, verifying the permissions of the first request.

[0145] Specifically, before generating the first response information, the authentication module can send an authorization request to the interaction module of the above embodiment; the interaction module can receive the user's authorization instruction based on the authorization request; the authorization instruction can be sent to the authentication module; and the authentication module can verify the permission of the first request based on the authorization instruction.

[0146] In some embodiments, generating first response information includes: if the permission verification of the first request is successful, executing the target function corresponding to the first request in the sandbox module to generate first response information.

[0147] In some embodiments, the method further includes: extending the front-end function based on the first request to generate first extended information; after generating the first response information, the method further includes: sending the first response information and the first extended information to the MCP adapter; and sending the first response information and the first extended information to the AI ​​application layer through the MCP adapter.

[0148] Specifically, the extension module can extend the front-end function based on the first request to generate first extended information, and send the first extended information to the integration module; the integration module receives the first extended information and the first response information sent by the main process layer, and sends the first response information and the first extended information to the MCP adapter; the MCP adapter sends the first response information and the first extended information to the AI ​​application layer.

[0149] It should be noted that the descriptions of the above method embodiments are similar to those of the above system embodiments, and have similar beneficial effects. For technical details not disclosed in the method embodiments of this application, please refer to the descriptions of the system embodiments of this application for understanding.

[0150] Those skilled in the art will understand that the order in which the steps are written in the above-described method of the specific implementation does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic. The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

[0151] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a terminal, server, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0152] This application also provides an electronic device. Figure 5 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application, as shown below. Figure 5 As shown, the electronic device 50 may include: Memory 501 is used to store executable instructions.

[0153] The processor 502 is used to implement any of the above-described local function call methods when executing executable instructions stored in the memory 501.

[0154] The processor 502 mentioned above can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor.

[0155] The aforementioned computer-readable storage medium or memory 501 may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; it may also be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0156] This application embodiment further provides a computer storage medium storing computer-executable instructions, which are used to implement any of the local function invocation methods provided in the above embodiments.

[0157] Correspondingly, this application embodiment further provides a computer program product, the computer program product including computer executable instructions, which are used to implement any of the local function invocation methods provided in the above embodiments.

[0158] In some embodiments, the functions or modules of the apparatus provided in this application can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0159] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0160] The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined to obtain new method embodiments without conflict.

[0161] The features disclosed in the various product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0162] The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

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

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

Claims

1. A local function call system, characterized in that, This system, used in the Electron client desktop application development framework, includes a main process layer and a rendering process layer. The rendering process layer includes a Model Context Protocol (MCP) adapter. The MCP adapter is used to interact with the artificial intelligence (AI) application layer. The rendering process layer is used to receive a first request sent by the AI ​​application layer through the MCP adapter, and send the first request to the main process layer; the first request is a function list retrieval request or a function call request; the function list retrieval request is used to retrieve the function list in the main process layer, and the function call request is used to call the function in the main process layer; The main process layer is used to generate first response information based on the first request and send the first response information to the rendering process layer.

2. The system according to claim 1, characterized in that, The rendering process layer also includes a verification module, in the case that the first request is a function call request. The MCP adapter is used to send the first request to the verification module after receiving the first request; The verification module is used to verify the first request, and if the first request is verified to be for obtaining a function in the main process layer, the first request is sent to the main process layer.

3. The system according to claim 2, characterized in that, The rendering process layer also includes a processing module and an extension module. The verification module is specifically used to verify the first request. If the first request is to obtain a function in the main process layer, the first request is sent to the processing module. The processing module is configured to, upon receiving the first request, invoke the extension module based on the first request and send the first request to the main process layer; The extension module is used to extend the front-end functionality based on the first request.

4. The system according to claim 1, characterized in that, The main process layer includes an authentication module, which is used when the first request is a function call request. The authentication module is used to verify the permissions of the first request based on a preset permission list before generating the first response information.

5. The system according to claim 1, characterized in that, The main process layer includes an authentication module, and the rendering process layer also includes an interaction module, in the case that the first request is a function call request. The authentication module is used to send an authorization request to the interaction module before generating the first response information; The interaction module is used to receive the user's authorization instruction based on the authorization request; and send the authorization instruction to the authentication module. The authentication module is also used to verify the permissions of the first request based on the authorization instruction.

6. The system according to claim 4 or 5, characterized in that, The main process layer also includes a sandbox module. The sandbox module is used to execute the target function corresponding to the first request and generate the first response information if the permission verification of the first request is successful.

7. The system according to claim 1, characterized in that, The rendering process layer also includes an extension module and an integration module. The extension module is used to extend the front-end function based on the first request to generate first extension information, and send the first extension information to the integration module; The integration module is used to receive the first extended information and the first response information sent by the main process layer, and send the first response information and the first extended information to the MCP adapter. The MCP adapter is further configured to receive the first response information and the first extended information, and send the first response information and the first extended information to the AI ​​application layer.

8. A method for invoking local functions, characterized in that, A local function call system applied in the Electron client, a desktop application development framework, includes: a main process layer and a rendering process layer; the rendering process layer includes a Model Context Protocol (MCP) adapter; the MCP adapter is used to interact with an artificial intelligence (AI) application layer; the method includes: The MCP adapter receives a first request sent by the AI ​​application layer; the first request is a function list retrieval request or a function call request; the function list retrieval request is used to retrieve the function list in the main process layer, and the function call request is used to call the function in the main process layer. Generate a first response based on the first request.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory for storing computer programs capable of running on the processor; wherein, The processor is used to run the computer program to perform the method of claim 8.

10. A computer storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method of claim 8.

11. A computer program product, comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the method of claim 8.

Images