Function call method, device, vehicle and storage medium

Abstract

The application discloses a function calling method and device, a vehicle and a storage medium, and relates to the technical field of vehicle-mounted system software. The scheme is applied to a target system, the target system comprises a master process and at least one local function process, and the master process is the only process in the system that interacts with a large language model through a model context protocol server. The method comprises the following steps: receiving a target calling instruction based on a model context protocol sent by the large language model based on the master process; analyzing the instruction to obtain a target function identifier and a calling parameter; forwarding the parsed instruction to the corresponding local function process according to the target function identifier, so that the process executes a function according to the calling parameter. Through centralized and standardized calling management, the scheme improves the response efficiency and scalability of function calling, and reduces the function extension and maintenance cost.

Description

Technical Field

[0001] This application relates to the field of vehicle system software technology, specifically to a function invocation method, device, vehicle, and storage medium. Background Technology

[0002] With the maturation of large language model technology, its application in the field of in-vehicle intelligent systems is gradually deepening, aiming to achieve convenient control of local in-vehicle functions such as air conditioning, windows, and seats through natural language interaction. In in-vehicle systems, especially Android-based in-vehicle infotainment systems, achieving efficient and reliable calls to underlying functions by large language models has become a clear technical requirement.

[0003] In related technologies, to achieve this goal, the common practice is to deploy independent large language model tool call protocol server modules within each local functional process of the in-vehicle Android system (such as the air conditioning control process and the window control process). These distributed server modules are directly responsible for communicating with the large language model locally or in the cloud to register their own functions and respond to call commands. This multi-point deployment mode results in a large number of protocol communication modules with duplicate functions in the system architecture, which not only increases the complexity of individual processes but also leads to the overall bloat of the system. The coexistence of multiple server modules makes the communication links intertwined and chaotic, making unified scheduling and collaborative management difficult to achieve; at the same time, the protocol implementations between different processes may differ, affecting the adaptability and success rate of function calls.

[0004] Therefore, the existing technical approach of deploying protocol servers independently in multiple processes leads to problems such as architectural redundancy, poor protocol compatibility, and management difficulties when vehicle systems face dynamic functional expansion and maintenance. Ultimately, this results in low system operating efficiency, high resource consumption, and limited expansion flexibility, making it difficult to meet the stringent requirements of lightweight and high reliability in the vehicle environment. Summary of the Invention

[0005] In view of this, this application aims to provide a function invocation method, device, vehicle, and storage medium that can improve the response efficiency and scalability of function invocation through centralized and standardized invocation management, and reduce the cost of function expansion and maintenance.

[0006] According to a first aspect of this application, a function invocation method is provided, applied to a target system, the target system including a main control process and at least one local function process, the main control process being the only process in the target system interacting with a large language model through a model context protocol server, the method comprising: receiving a target invocation instruction based on a model context protocol sent by the large language model based on the main control process; the target invocation instruction being generated by the large language model in response to a user instruction and including a target function identifier and invocation parameters of the target local function process; parsing the target invocation instruction to obtain a parsed target invocation instruction; the parsed target invocation instruction including the target function identifier and invocation parameters of the target local function process; and forwarding the parsed target invocation instruction to the target local function process according to the target function identifier, so that the target local function process executes a corresponding function according to the invocation parameters.

[0007] In this embodiment, by setting the master process as the only process in the target system that interacts with the large language model through the model context protocol server, local functional processes do not need to deploy a separate model context protocol server; they only interact with the master process through inter-process communication. The master process uniformly receives target invocation instructions issued by the large language model, parses them, and forwards them to the corresponding target local functional process based on the target function identifier. This process then executes the specific function according to the invocation parameters. This approach centralizes the model context protocol communication function, which was originally scattered across multiple local functional processes, into the master process, avoiding the need for each functional process to establish its own communication link with the large language model. This reduces redundant modules and duplicate code in the system and lowers resource consumption. Local functional processes do not need to handle protocol parsing and communication management; they only need to focus on the function execution logic, simplifying the implementation of functional processes and reducing development and maintenance complexity. Furthermore, as a unified interaction entry point, when new functions are needed, only a new local functional process needs to be developed and connected to the master process through inter-process communication. There is no need to modify the interaction logic between the master process and the large language model, nor is it necessary to deploy a separate model context protocol server for the new function, thus enhancing the system's scalability.

[0008] According to a second aspect of this application, a function invocation apparatus is provided, applied to a target system, the target system including a main control process and at least one local function process, wherein the main control process is the only process in the target system that interacts with a large language model through a model context protocol server, and the apparatus includes: The main control module is used to receive a target invocation instruction based on the model context protocol sent by the large language model based on the main control process; the target invocation instruction is generated by the large language model in response to the user instruction and includes the target function identifier and invocation parameters of the target local function process; The parsing module is used to parse the target invocation instruction to obtain the parsed target invocation instruction; the parsed target invocation instruction includes the target function identifier and invocation parameters of the target local function process; The sending module is used to forward the parsed target call instruction to the target local function process according to the target function identifier, so that the target local function process can execute the corresponding function according to the call parameters.

[0009] According to a third aspect of this application, a computer-readable storage medium is provided, the storage medium storing a computer program for performing the methods described in any of the above embodiments.

[0010] According to a fourth aspect of this application, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; the processor being configured to perform the method described in any of the above embodiments.

[0011] According to a fifth aspect of this application, a vehicle is provided, including the aforementioned electronic equipment.

[0012] This application provides a function invocation method, device, vehicle, and storage medium. The solution is applied to a target system, which includes a main control process and at least one local function process. The main control process is the only process in the system that interacts with a large language model through a Model Context Protocol (MTP) server. The method includes: receiving a target invocation instruction based on the MTP sent by the large language model through the main control process; parsing the instruction to obtain a target function identifier and invocation parameters; and forwarding the parsed instruction to the corresponding local function process according to the target function identifier, so that the process executes the function according to the invocation parameters. This solution improves the response efficiency and scalability of function invocation through centralized and standardized invocation management, and reduces the cost of function expansion and maintenance. Attached Figure Description

[0013] Figure 1 The diagram shown is a schematic representation of an implementation environment provided in an embodiment of this application.

[0014] Figure 2 The diagram shown is a flowchart of a function invocation method provided in one embodiment of this application.

[0015] Figure 3 The diagram shown is a block diagram of a function calling device provided in one embodiment of this application.

[0016] Figure 4 The diagram shown is a structural block diagram of an electronic device provided in one embodiment of this application. Detailed Implementation

[0017] 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.

[0018] In the field of integrating large language models into in-vehicle systems to control local functions, to enable users to invoke in-vehicle functions such as air conditioning and windows via natural language commands, the common approach is for each local process executing a specific in-vehicle function to deploy and maintain a model context protocol server. Specifically, this solution achieves direct communication with the large language model by embedding a complete protocol server module in each local function process. Its basic working principle is that each function process independently registers its capabilities with the large language model and directly receives and parses protocol call commands from the large language model. This approach is adopted by some solutions primarily because it allows for a direct, point-to-point interaction link between the function module and the large language model.

[0019] However, this solution performs poorly when applied to resource-constrained automotive environments with extremely high requirements for system stability and maintainability, especially in automotive Android systems based on a multi-process architecture. To maintain the independence of each functional module in protocol interaction, the inherent design of this solution inevitably compromises the overall architectural efficiency and manageability of the system, and may even lead to resource waste and logical inconsistencies. Specifically, in scenarios where automotive systems need to integrate dozens or even more local functions, each functional process runs a protocol server instance, resulting in a significant increase in memory and CPU usage. Simultaneously, the mesh communication topology formed between multiple servers and a large language model complicates function call paths, makes protocol implementation difficult to unify, and increases the complexity of system debugging and functional expansion.

[0020] Through in-depth analysis, the inventors discovered that the root causes of the aforementioned contradictions are multifaceted: From a system architecture perspective, the tight coupling and distributed deployment of functional logic and protocol communication logic lead to redundant construction of module functions and resource redundancy. From an interaction topology perspective, the large language model needs to manage connections and sessions with multiple protocol servers simultaneously, and the dispersed interaction logic increases the difficulty of maintaining state synchronization and data consistency. Furthermore, from an engineering maintenance perspective, any update to the protocol specification or adjustment of security policies requires modification and testing in all functional processes where servers are deployed, resulting in high change costs and a high risk of errors. These factors collectively limit the feasibility of large-scale deployment and long-term evolution of the relevant technical solutions in the automotive environment.

[0021] To overcome the aforementioned contradictions, this invention proposes a different technical approach. Its core concept lies in establishing a unique, centralized protocol service process within the vehicle-side system to converge and uniformly manage the protocol communication and instruction routing aspects of in-vehicle function calls. This effectively eliminates architectural redundancy and resource overhead caused by multiple servers while maintaining the independence of the execution logic of each local functional module, and achieves unified registration and security control of functional capabilities. In other words, it provides a centralized protocol scheduling mechanism to solve the problems of high system resource consumption, dispersed interaction logic, and high maintenance costs caused by multi-process deployment of protocol servers, achieving a lightweight, highly manageable, and easily scalable in-vehicle function call technology.

[0022] After introducing the basic principles of this application, various non-limiting embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0023] To concretize the inventive concept, first combine Figure 1 Describe a typical implementation environment. Figure 1 The diagram illustrates an implementation environment provided in this application embodiment. The system runs on a vehicle-mounted computing platform, typically an in-vehicle Android operating system. The system includes a main control process 121 and at least one local function process 122. A large language model module 110 is configured to understand user natural language commands and generate structured function call instructions. The main control process 121 is the only process in the system that communicates with the large language model module 110. Local function processes 122, such as air conditioning control processes and window control processes, are configured to execute specific in-vehicle functions. The main control process 121 and each local function process 122 interact with each other through an inter-process communication mechanism provided by the operating system.

[0024] Figure 2 This is a flowchart illustrating a function call method provided in one embodiment of this application. Figure 2 The method described is executed by a target system, which can be a vehicle-mounted system or an operating system for electronic devices such as mobile phones and tablets. Here, "vehicle-mounted system" broadly refers to any computing system installed in a vehicle. The vehicle-mounted system can be an in-vehicle terminal, in-vehicle controller, in-vehicle smart cockpit system, or an integrated system composed of multiple in-vehicle electronic control units, or a software module deployed on an in-vehicle computing platform. This application embodiment does not limit the specific implementation of this method.

[0025] The target system includes a main control process and at least one local functional process. The main control process is the only process in the target system that interacts with the large language model through the model context protocol server. Figure 2 As shown, the method includes the following: Step S210: Based on the main control process, receive the target invocation instruction sent by the large language model based on the model context protocol; the target invocation instruction is generated by the large language model in response to the user instruction, and includes the target function identifier and invocation parameters of the target local function process.

[0026] In this application, the term "master process" refers to any process that is the only one in the system that interacts with the large language model through the Model Context Protocol server. For example, it may include, but is not limited to: a process running as the master process in an in-vehicle Android system, or any process that centrally manages functional capability description information and forwards invocation instructions, or a combination thereof.

[0027] In this application, "large language model" refers to any artificial intelligence model capable of understanding and generating natural language. For example, it may include, but is not limited to: pre-trained language models based on the Transformer architecture, large language model services deployed in the cloud, or locally deployed large language model instances.

[0028] In this application embodiment, the Model Context Protocol (MCP) refers to any communication protocol used for large language models to interact with external tools or services. For example, it may include, but is not limited to, protocols conforming to the Model Context Protocol (MCP) specification, or any protocol that defines the tool invocation format and capabilities. Regarding the protocol format, it may refer to a data structure that strictly follows the JSON schema definition, containing specific fields such as tool name, parameter description, etc.

[0029] In this embodiment, the Model Context Protocol (MGP) server is a service module used to implement MGP communication functions. It can be deployed within the main control process or independently of it, but it must be ensured that only one MGP server exists in the target system. This server is responsible for receiving call instructions conforming to the MGP format sent by the large language model, and encapsulating the data to be returned according to the protocol format before sending it to the large language model. Since there is only one MGP server, all MGP interactions between the target system and the large language model are handled uniformly by this server.

[0030] In this embodiment, the target invocation instruction is a command generated by the large language model based on user instructions and a synchronized list of functional capabilities, conforming to the model context protocol format, and is used to request the invocation of a specific function. This instruction at least includes the target function identifier and invocation parameters of the target local function process. For example, if a user says, "Turn on the driver's seat heater, set it to level 2," the invocation instruction generated by the large language model will include the identifier and level parameter of the corresponding seat heating function.

[0031] In this embodiment, the local functional process is a process in the target system responsible for providing specific capabilities. Each local functional process may correspond to one or more capability types, including providing resource access to the large language model, exposing callable functional functions, or providing predefined task templates. The local functional process does not deploy a model context protocol server and does not directly interact with the large language model based on the model context protocol. Instead, it completes capability registration and instruction execution through inter-process communication with the main control process.

[0032] When the target system is a vehicle-side system, the corresponding local function process is called a vehicle-side local function process. This refers to a process running on the vehicle's computing platform that performs specific in-vehicle functions, including but not limited to control functions and data acquisition functions. Control functions can include physical control of vehicle hardware, such as adjusting the air conditioning, opening and closing windows, and adjusting seats, or software operations, such as setting navigation, playing music, and making phone calls. Data acquisition functions can be used to query vehicle status or user information, such as checking vehicle speed, remaining battery power, navigation route, and tire pressure.

[0033] In this embodiment, the target local function process refers to the local function process that needs to execute the current call instruction, as determined by the target function identifier. After the main control process parses the target call instruction and obtains the target function identifier, it matches the corresponding process among the registered local function processes based on the identifier and forwards the instruction to that process for execution. For example, if the target function identifier corresponds to the air conditioning control function, then the target local function process is the air conditioning control process.

[0034] In this embodiment, the target function identifier is an identification information used to uniquely distinguish different functions. Each local function process carries its own function identifier when reporting function registration information to the main control process. The main control process generates a list of function capabilities based on this identifier. The large language model also needs to specify the target function identifier when generating calling instructions so that the main control process can accurately identify the function to be called. For example, the identifier for the air conditioning function could be "air_condition," and the identifier for the window function could be "window."

[0035] In this embodiment, the calling parameters are data generated by the large language model based on user instructions and the calling parameter rule information corresponding to the function in the function capability list, used for specific function execution. The calling parameters must conform to the calling parameter rule information reported during function registration, including the data type and value range of the parameters. For example, for the air conditioning temperature adjustment function, the calling parameters can be integers with a value range of 18 to 30, representing the target temperature value.

[0036] Step S220: Parse the target invocation instruction to obtain the parsed target invocation instruction; the parsed target invocation instruction includes the target function identifier and invocation parameters of the target local function process.

[0037] In this embodiment, the parsed target invocation instruction refers to the data obtained by the main control process after parsing the received target invocation instruction. The original target invocation instruction is text or structured data conforming to the model context protocol format. After parsing, the main control process converts it into an internally recognizable instruction form, which explicitly includes the target function identifier and invocation parameters of the target local function process, so that it can be forwarded according to the function identifier and the specific function can be executed according to the invocation parameters.

[0038] Step S230: Based on the target function identifier, forward the parsed target call instruction to the target local function process, so that the target local function process executes the corresponding function according to the call parameters.

[0039] In this embodiment, the main control process and the local function process interact with each other via inter-process communication (IPC). Once the main control process determines the target local function process based on the target function identifier, it sends the parsed target call instruction to that process via IPC. The inter-process communication can use the native Binder mechanism of the Android system, or other IPC methods such as Socket or shared memory can be selected according to actual needs.

[0040] In this embodiment, after receiving the forwarded call instruction, the target local function process executes the corresponding function according to the call parameters contained in the instruction. The function can be a control function, such as adjusting the air conditioning temperature, opening / closing windows, or adjusting the seat position; or it can be a data acquisition function, such as querying the current vehicle speed, obtaining the remaining battery power, or reading user preference settings. After the local function process completes execution, it typically generates an execution result and returns it to the main control process via IPC. The main control process then sends the result back to the large language model via the model context protocol, and finally provides feedback to the user in natural language.

[0041] In this embodiment, by setting the master process as the only process in the target system that interacts with the large language model through the model context protocol server, local functional processes do not need to deploy a separate model context protocol server; they only interact with the master process through inter-process communication. The master process uniformly receives target invocation instructions issued by the large language model, parses them, and forwards them to the corresponding target local functional process based on the target function identifier. This process then executes the specific function according to the invocation parameters. This approach centralizes the model context protocol communication function, which was originally scattered across multiple local functional processes, into the master process, avoiding the need for each functional process to establish its own communication link with the large language model. This reduces redundant modules and duplicate code in the system and lowers resource consumption. Local functional processes do not need to handle protocol parsing and communication management; they only need to focus on the function execution logic, simplifying the implementation of functional processes and reducing development and maintenance complexity. Furthermore, as a unified interaction entry point, when new functions are needed, only a new local functional process needs to be developed and connected to the master process through inter-process communication. There is no need to modify the interaction logic between the master process and the large language model, nor is it necessary to deploy a separate model context protocol server for the new function, thus enhancing the system's scalability.

[0042] based on Figure 2 In addition to the method described in the embodiments of this specification, some specific implementation schemes of the method are also provided below.

[0043] Optionally, forwarding the parsed target invocation instruction to the target local function process includes: Based on the main control process, the legality of the parsed target call instruction is verified; If the validity check passes, the parsed target invocation instruction is forwarded to the target local function process; If the validity check fails, a verification failure message will be sent to the large language model.

[0044] In this embodiment, the legality verification of the parsed target call instruction refers to the main control process determining whether the call request meets preset legality conditions before forwarding the instruction to the target local function process. The main control process pre-stores legality condition information reported by each local function process, which indicates various constraints required to execute the corresponding function. The main control process obtains the real-time status information of the current system and compares this status information with the legality condition information corresponding to the target local function process. If the current system status meets the legality requirements, the verification is deemed successful, and the instruction is allowed to be forwarded; otherwise, the verification is deemed unsuccessful, and forwarding is rejected. Legality conditions can include various types, such as vehicle status conditions, such as requiring the vehicle to be parked before executing window control functions; user permission conditions, such as requiring the currently logged-in user to have administrator privileges before executing certain settings functions; function exclusivity conditions, such as prohibiting other specific functions from calling certain functions simultaneously during execution; and system resource conditions, such as requiring sufficient system resources to execute high-load functions. The main control process makes a comprehensive judgment based on pre-stored validity conditions and the current system state to determine whether to allow the call. For example, the execution permission information reported by the high beam off function requires the vehicle to be in a parked state before execution. If the vehicle is currently moving, the main control process will determine that the high beam off command is not valid during the validity check.

[0045] In this embodiment, the verification failure message refers to the feedback information returned by the main control process to the large language model when the legality verification fails. This verification failure message informs the large language model that the current call request cannot be executed due to security or conditional limitations, so that the large language model can translate it into natural language feedback that the user can understand. The verification failure message at least includes the reason for the call failure, such as "High beams must not be turned off while the vehicle is in motion; please park and try again." The main control process encapsulates the verification failure message according to the model context protocol format and sends it to the large language model.

[0046] In this embodiment, the execution permission information refers to one of the fields included when the local function process reports function registration information to the main control process. This field indicates the vehicle state conditions required to execute the function. The execution permission information clarifies under which vehicle states the corresponding function is allowed to be invoked, such as "executable only when parked" or "executable while driving." The main control process stores this information and performs a validity check based on the current vehicle state when it receives an invocation command. Different functions can be configured with different execution permissions. For example, window control functions typically require execution while parked, while air conditioning temperature adjustment functions can be executed in both driving and parked states.

[0047] In this embodiment, the vehicle status information refers to the real-time operating status data of the vehicle where the target system is located, used to compare with the execution permission information during legality verification. The vehicle status information includes at least whether the vehicle is currently in a driving or parked state, and may further include information such as vehicle speed and gear position. The main control process can obtain this information through the target system's bus interface or system services, for example, by reading the vehicle speed signal from the vehicle control unit to determine whether the vehicle is in a driving state.

[0048] In this embodiment, the main control process performs a validity check on the parsed target call instruction before forwarding it to the target local function process. Based on the pre-stored execution permission information corresponding to the target local function process, the main control process obtains the current vehicle status information and determines whether the current vehicle status meets the conditions required to execute the function. If it does, the check passes, and the main control process forwards the instruction to the target local function process for execution; if it does not, the check fails, and the main control process directly sends a check failure message to the large language model, without further forwarding. This approach centralizes security control logic to the main control process, which performs pre-verification of call instructions, avoiding the distribution of insecure call instructions to local function processes and reducing the possibility of security risks caused by unauthorized operations. Local function processes do not need to concern themselves with permission verification logic; they only need to focus on executing the received instructions, reducing the implementation complexity of function processes and avoiding inconsistencies or omissions that may arise from different function processes implementing their own verification logic. Meanwhile, since the verification failure message is directly returned to the large language model by the main control process, the large language model can promptly translate the failure reason into natural language feedback that users can understand. This allows users to clearly understand why the call was rejected, improving the user experience. Furthermore, when it's necessary to adjust the execution permissions of a function, the local function process only needs to re-report the updated execution permission information, and the main control process only needs to update the storage for the changes to take effect. No modification to the verification logic of other function processes or the main control process is required, improving system maintainability.

[0049] Optionally, the method is applied to the vehicle-side system; the step of validating the parsed target invocation instruction includes: Obtain the execution permission information corresponding to the target local function process; the execution permission information is used to indicate the vehicle state conditions that need to be met to execute the function; Obtain the current status information of the vehicle where the vehicle-end system is located; Based on the current status information and the vehicle status conditions, the legality of the parsed target invocation instruction is verified.

[0050] In this embodiment, the execution permission information refers to one of the fields included when the local function process reports function registration information to the main control process. This field indicates the vehicle state conditions required to execute the function. The execution permission information clarifies under which vehicle states the corresponding function is allowed to be invoked, such as "executable only when parked" or "executable while driving." The main control process stores this information and performs a validity check based on the current vehicle state when it receives an invocation command. Different functions can be configured with different execution permissions. For example, window control functions typically require execution while parked, while air conditioning temperature adjustment functions can be executed in both driving and parked states.

[0051] In this embodiment, the vehicle state condition refers to the specific requirements for the vehicle's state when executing a certain function, and is the core content of the execution permission information. The vehicle state condition defines under what vehicle operating scenarios the function can be safely or reasonably invoked. Vehicle state conditions can include various types, such as requiring the vehicle to be parked, requiring the vehicle to be in motion, requiring the vehicle speed to be below a certain threshold, or requiring the vehicle to be stationary. During legality verification, the main control process compares the current vehicle state with the vehicle state condition; if the current state meets the condition, execution is allowed; otherwise, execution is rejected.

[0052] In this embodiment, the current status information refers to the real-time vehicle operating status data obtained by the main control process during legality verification, used to compare with the vehicle status conditions in the execution permission information. The current status information includes at least whether the vehicle is currently in a driving or parked state, and may further include information such as vehicle speed, gear position, and door status. The main control process can obtain this information through the target system's bus interface or system services, for example, by reading the vehicle speed signal from the vehicle control unit to determine whether the vehicle is in a driving state, or by obtaining gear information from the body control module to determine whether the vehicle is in a parked state.

[0053] For example, in the function registration information reported by the window control process to the main control process, the vehicle status condition included in the execution permission information is "parked". When the user issues a command to open the window through the large language model, the main control process receives the corresponding target call command, parses it, obtains the current status information, and finds that the vehicle is in motion. The current status information does not meet the vehicle status condition of "parked", so the validity check fails. The main control process refuses to forward the command to the window control process and returns a verification failure message.

[0054] In this embodiment, before forwarding the parsed target call instruction to the target local functional process, the main control process obtains the execution permission information corresponding to the target local functional process. This information indicates the vehicle state conditions required to execute the function. Simultaneously, it obtains the current state information of the vehicle where the target system resides and verifies the legality of the call instruction based on the matching of the current state information and the vehicle state conditions. This approach integrates security control logic into the main control process, allowing it to uniformly determine whether each call request meets the vehicle state requirements, thus avoiding the distribution of potentially security-risk instructions to the local functional process. The local functional process does not need to be aware of the vehicle state or implement permission judgments independently; it only needs to focus on executing the received instructions, reducing the implementation complexity of the functional processes and avoiding inconsistencies or omissions that might arise from different functional processes implementing their own verification logic. Since the verification logic is centralized in the main control process, when the execution permission of a function needs to be adjusted, the local functional process only needs to re-report the updated execution permission information, and the main control process updates its storage to take effect, without needing to modify the verification logic of other functional processes or the main control process itself. Meanwhile, when the verification fails, the main control process directly returns a prompt message. The large language model can promptly convert the reason for the failure into natural language feedback that the user can understand, so that the user clearly knows why the call was rejected, thus improving the interactive experience.

[0055] Optionally, forwarding the parsed target invocation instruction to the target local function process includes: The parsed target invocation instruction is forwarded to the target local function process via inter-process communication.

[0056] In this embodiment, inter-process communication (IPC) refers to the mechanism for data interaction between the main control process and the local function process. Inter-process communication (IPC) is a way for different processes in an operating system to exchange data, enabling cross-process data transmission and instruction delivery. In this solution, the main control process sends the parsed target call instruction to the target local function process via IPC, and the local function process also reports function registration information, execution result data, etc., to the main control process via IPC. The specific implementation of IPC can be selected according to the operating system environment of the target system. For example, in the Android system, the Binder communication mechanism can be used. Binder is a widely used IPC method in the Android system, characterized by high efficiency and security. In other operating system environments, IPC methods such as Socket, shared memory, and pipes can also be used.

[0057] For example, in the Android system environment, the main control process and the air conditioning control process communicate via the Binder mechanism. The main control process constructs a Parcel object, writes the target function identifier and call parameters from the parsed target call instruction into this object, and then calls the service method exposed by the air conditioning control process through the Binder interface, passing the instruction data to it. After receiving the instruction, the air conditioning control process executes the corresponding temperature adjustment operation according to the call parameters, and returns the result to the main control process through the Binder interface after execution.

[0058] In this embodiment, the main control process forwards the parsed target call instruction to the target local function process via inter-process communication (IPC). IPC utilizes the cross-process data transmission mechanism provided by the operating system, enabling efficient and reliable instruction transfer between the main control process and the local function process. The local function process does not need to concern itself with the source of the instruction or the communication protocol; it only needs to receive and execute the instruction. Since the local function process does not deploy a model context protocol server and does not directly interact with the large language model, its IPC communication with the main control process becomes the only way for the local function process to obtain call instructions. This design completely concentrates the burden of protocol parsing and communication management on the main control process, allowing each local function process to maintain a lightweight implementation. Simultaneously, IPC communication, as a native inter-process interaction method of the operating system, has low overhead and high stability, suitable for the target system's requirements for resource consumption and real-time performance. When a new local function process needs to be added, it only needs to implement the IPC service interface according to the agreement to be discovered and called by the main control process, without introducing additional modifications to the main control process or existing function processes, thus improving the system's scalability.

[0059] Optionally, before the main control process receives the target invocation instruction based on the model context protocol sent by the large language model, it further includes: Based on the main control process, receive function registration information in model context protocol format sent by at least one local function process; A list of functional capabilities is generated based on the received functional registration information; the list of functional capabilities is used by the large language model to generate invocation instructions for calling the functions corresponding to the local functional processes. Synchronize the list of functional capabilities to the large language model.

[0060] In this embodiment, the function registration information refers to the data structure reported by local function processes to the main control process, describing the functional capabilities they provide. The function registration information is constructed using a model context protocol format, enabling the main control process to parse and summarize the capabilities of each local function process according to a unified standard. The function registration information includes at least a function identifier and call parameter rule information. The function identifier uniquely distinguishes different functions; for example, the function identifier for air conditioning control could be "air_condition". The call parameter rule information specifies the parameter requirements that the large language model needs to provide when calling the function, including the data type and value range of the parameters; for example, the temperature parameter is an integer with a value range of 18 to 30. Furthermore, the function registration information may also include other fields such as function description information and execution permission information as needed to further enrich the description of the functional capabilities.

[0061] In this embodiment, the functional capability list refers to a list generated by the master control process based on the functional registration information reported by each local functional process, describing all currently available functional capabilities of the target system. The functional capability list includes key information such as the function identifier, function description, call parameter rules, and execution permissions for each function, organized according to the model context protocol format. After generating the functional capability list, the master control process synchronizes it to the large language model. Based on this, the large language model establishes a tool call list, clarifying which functions the target system currently supports, what parameters each function requires, and what the execution conditions are. For example, the functional capability list may contain information on multiple entries such as air conditioning control, window control, and seat adjustment, with each entry recording a complete capability description of the function in a unified format.

[0062] In this embodiment, synchronization refers to the process by which the master control process sends the list of functional capabilities to the large language model via the model context protocol. The synchronization operation enables the large language model to promptly obtain all currently supported functions and their detailed capability information from the target system. Synchronization can occur during system initialization or be triggered after each local functional process reports new function registration information. The master control process encapsulates the list of functional capabilities according to the format specified by the model context protocol and sends it to the large language model. Upon receiving the list, the large language model updates its internal list of functional tools. For example, when a vehicle adds a seat massage function, after the corresponding local functional process reports the function registration information, the master control process updates the list of functional capabilities and synchronizes the updated list to the large language model. Afterward, the user can control the seat massage function using natural language.

[0063] In this embodiment, before receiving the target invocation instruction from the large language model, the main control process first receives function registration information based on the model context protocol format sent by each local function process. Based on this information, it generates a list of functional capabilities and synchronizes this list to the large language model. This approach eliminates the need for local function processes to deploy a model context protocol server; they only need to report function registration information in a unified format to complete capability registration. The main control process, as the sole node interacting with the large language model, aggregates the capabilities of all local function processes and synchronizes them uniformly to the large language model. The large language model then obtains all currently supported functions and their invocation rules for the target system. Because the function registration information uses a unified protocol format, the main control process can consistently parse and process capability descriptions from different local function processes, avoiding adaptation problems caused by format differences. When a new function needs to be added, only the corresponding local function process needs to be developed and have it report the function registration information. The main control process automatically updates the capability list and synchronizes it to the large language model, without requiring modification to the core logic of the main control process. Meanwhile, the reporting mechanism for function registration information allows the capabilities of the target system to change dynamically. Local function processes can report different function registration information based on the actual situation, and the main control process updates the capability list accordingly. The capabilities perceived by the large language model also change accordingly, enhancing the flexibility and scalability of the system.

[0064] Optionally, the function registration information includes: function identifier, function description information, call parameter rule information, and execution permission information.

[0065] In this embodiment, the function identifier refers to identification information used to uniquely distinguish different functions. Each local function process carries its own function identifier when reporting function registration information to the main control process. The main control process generates a list of function capabilities based on this identifier. The large language model also needs to specify the target function identifier when generating call instructions so that the main control process can accurately identify the function to be called. The function identifier can be in string form; for example, the identifier for the air conditioning function could be "air_condition," and the identifier for the window function could be "window."

[0066] In this embodiment, the functional description information refers to textual information that briefly describes a function, used to help the large language model understand the function's purpose and usage scenario. The functional description information is typically presented in natural language, such as "controlling air conditioning temperature, airflow, and mode" or "opening or closing car windows, with specified opening degree." After receiving the list of functional capabilities, the large language model can more accurately parse user instructions based on the functional description information, matching the user's intent to the correct function.

[0067] In this embodiment, the calling parameter rule information refers to the parameter requirements that the large language model needs to provide when calling the function, including the data type and value range of the parameters. The calling parameter rule information is used to constrain the parameter format when the large language model generates the calling instruction, ensuring that the generated parameters can be correctly parsed and executed by the local function process. For example, for the air conditioning temperature adjustment function, the calling parameter rule information can specify that the parameter type is an integer with a value range of 18 to 30; for the window opening adjustment function, the parameter type can be specified as an integer with a value range of 0 to 100, representing the opening percentage.

[0068] In this embodiment, the execution permission information refers to information indicating the vehicle state conditions required to execute the function, used by the main control process to perform legality verification before forwarding the call instruction. The execution permission information clarifies under which vehicle states the corresponding function is allowed to be called, such as "executable only when parked" or "executable while driving." The main control process stores this information and performs legality verification based on the current vehicle state when receiving the call instruction. Different functions can be configured with different execution permissions; for example, window control functions typically require execution in a parked state, while air conditioning temperature adjustment functions can be executed in both driving and parked states.

[0069] In this embodiment, the function registration information reported by the local function processes to the main control process includes function identifiers, function descriptions, call parameter rules, and execution permission information. The function identifier uniquely distinguishes each function, ensuring that the main control process and the large language model can accurately locate the target function. The function description explains the function's purpose in natural language, helping the large language model more accurately match user intent to the corresponding function. The call parameter rules specify the data type and value range of the parameters, constraining the large language model to generate compliant call parameters and preventing call failures due to incorrect parameter formats. The execution permission information indicates the vehicle state conditions required to execute the function, providing a basis for subsequent legality verification by the main control process. Through this structured function registration information, the main control process can obtain complete capability descriptions of each local function process in a unified manner, generate a function capability list, and synchronize it to the large language model. This mechanism allows for the addition of new features by requiring only the local feature process to report the feature registration information in a compliant format, without needing to modify the configuration of the main control process or the large language model, thus improving the system's scalability. At the same time, the explicit reporting of call parameter rules and execution permission information provides a reliable foundation for the large language model to generate compliant call instructions and for the main control process to perform security verification, which helps to improve the success rate and security of feature calls.

[0070] Optionally, generating a list of functional capabilities based on the received functional registration information includes: The validity of one of the function identifier, call parameter rule information, and execution permission information included in the function registration information shall be verified. If the validity verification passes, a list of functional capabilities is generated based on the functional registration information.

[0071] In this embodiment, the validity check refers to the standardization check performed by the main control process on the function registration information reported by the local function process, used to determine whether the registration information meets the requirements and can be included in the function capability list. The validity check differs from the aforementioned legality check. The legality check targets the calling instruction, determining whether the calling request meets the execution conditions; while the validity check targets the function registration information, determining whether the registration information itself is standardized, complete, and parsable.

[0072] In this embodiment, when validating the function identifier, the main control process checks whether the function identifier is a valid string format, whether it is empty, and whether it is duplicated with an existing function identifier. For example, if the function identifier reported by the window control process is "window", and the "window" identifier already exists in the main control process, the verification is deemed to have failed, and duplicate registration is rejected to prevent ambiguity in the function capability list.

[0073] In this embodiment of the application, when validating the calling parameter rule information, the main control process checks whether the parameter rule conforms to the format specified by the model context protocol, whether the data type is clear, and whether the value range is reasonable. For example, if the calling parameter rule information reported by the air conditioning control process specifies that the temperature parameter type is an integer but the value range is "18-30 degrees", which includes unit characters, the main control process can determine that the format is not standard and require resubmission.

[0074] In this embodiment of the application, when validating the execution permission information, the main control process checks whether the execution permission information is one of the preset legal state conditions, such as whether it belongs to an identifiable state enumeration value such as "parking state" or "driving state".

[0075] For example, the window control process reports function registration information to the main control process. The function identifier is "window," the call parameter rules are integers representing the opening parameter type with a value range of 0 to 100, and the execution permission information is "parking status." Upon receiving this information, the main control process verifies the validity of the function identifier, finding that the "window" identifier is unique and passes the verification. It also verifies the call parameter rules, finding the format to be correct and passing the verification. Finally, it verifies the execution permission information, finding that "parking status" is a preset valid status and passing the verification. Once all three verifications are successful, the main control process adds the window control function to the function capability list.

[0076] In this embodiment, before generating the functional capability list based on the functional registration information, the master control process first performs validity verification on at least one of the functional identifier, call parameter rule information, and execution permission information in the functional registration information. Only after the verification passes will the corresponding function be included in the capability list. This approach allows the master control process to filter out registration information with incorrect format, incomplete information, or non-standard specifications during the capability list generation stage, avoiding the synchronization of invalid or erroneous functional capabilities to the large language model. Since the large language model generates call instructions entirely based on the information in the capability list, if the list contains incorrect functional identifiers or non-standard call parameter rules, the subsequently generated call instructions will not be correctly parsed or executed. By adding validity verification on the master control process side, the accuracy and standardization of the capability list can be guaranteed at the source, reducing the risk of call failure caused by incorrect registration information and improving the stability and reliability of the system.

[0077] Based on the same technical concept, this application also provides another function invocation method. In this embodiment, the target system runs on an in-vehicle Android operating system and includes a main control process and at least one local function process. The main control process deploys a model context protocol server, which is the only process in the target system that interacts with the large language model based on the model context protocol. The local function process does not deploy a model context protocol server, and it interacts with the main control process through inter-process communication.

[0078] The first step is the function registration phase. Each local function process constructs function registration information conforming to the model context protocol format based on its own capabilities. This information includes at least a function identifier and invocation parameter rules. The function identifier uniquely identifies the function, and the invocation parameter rules indicate the data type and value range of the parameters required to invoke the function. Additionally, the function registration information may also include function description information and execution permission information. Each local function process reports its function registration information to the master process via inter-process communication.

[0079] After receiving the function registration information reported by each local function process, the master control process performs validity checks on the function registration information. Validity checks include verifying whether function identifiers are duplicated, whether the call parameter rule information format is standardized, and whether the execution permission information meets the preset legal status conditions. If the checks pass, the master control process generates a function capability list based on the received function registration information. This list summarizes the capability descriptions of all currently available functions in the target system. Subsequently, the master control process synchronizes this function capability list to the large language model via the model context protocol. Upon receiving this list, the large language model establishes a tool call list, specifying each function supported by the target system and its call rules.

[0080] After function registration is complete, the function invocation phase begins. The user issues a natural language command through the in-vehicle intelligent assistant, such as "turn on the driver's seat heater and set it to level 2." The in-vehicle intelligent assistant forwards the user's command to the large language model. The large language model parses the user's intent, matches it with the corresponding function in its own tool invocation list, and generates a target invocation command conforming to the model context protocol format based on the function's invocation parameter rules. The target invocation command contains the target function identifier and invocation parameters of the target local function process; for example, the target function identifier is "seat_heater," and the invocation parameter is "2."

[0081] The large language model sends the target invocation instruction to the target system. After receiving the target invocation instruction, the master process parses it to obtain the parsed target invocation instruction, which explicitly contains the target function identifier and invocation parameters of the target local function process.

[0082] Subsequently, the main control process performs a validity check on the parsed target call instruction. The main control process pre-stores execution permission information reported by each local function process, indicating the vehicle state conditions required to execute the corresponding function. The main control process obtains the real-time status information of the current vehicle, such as the current speed and gear position via the vehicle bus, to determine whether the vehicle is in a driving or parked state. The main control process compares the current status information with the execution permission information corresponding to the target local function process; for example, the window control function requires the vehicle to be parked before execution. If the current vehicle state meets the execution permission requirements, the validity check passes; otherwise, the check fails.

[0083] If the validity check passes, the main control process determines the corresponding target local function process based on the target function identifier and forwards the parsed target call instruction to that process via inter-process communication. If the validity check fails, the main control process directly generates a verification failure message, such as "Do not open the car window while the vehicle is in motion. Please park and try again." This message is then returned to the large language model via the model context protocol, where it is converted into natural language and fed back to the user.

[0084] After receiving the call instruction forwarded by the master process, the target local function process parses the call parameters in the instruction and executes the corresponding function according to its own functional logic. After execution, the local function process generates execution result data, including execution status and execution details, and reports the execution result to the master process through inter-process communication.

[0085] After receiving the execution result, the main control process forwards it to the large language model via the model context protocol. The large language model converts the execution result into natural language feedback information and sends it to the in-vehicle intelligent assistant, which then provides feedback to the user via voice or text, completing the entire function call process.

[0086] In the above embodiments, when the functionality of a local function process is updated, such as by adding new calling parameters or adjusting execution permissions, the process can reconstruct the function registration information and proactively report it to the main control process. The main control process verifies the validity of the updated function registration information. If the verification passes, it updates the function capability list and synchronizes the updated list to the large language model, thereby ensuring that the large language model always holds the latest function capability information.

[0087] Using the above method, only the master control process in the target system deploys the model context protocol server, while local functional processes do not need to deploy this server, thus avoiding the architectural bloat and communication link chaos caused by multi-process deployment. The master control process is uniformly responsible for protocol parsing, command routing, permission verification, and capability management, achieving the technical effects of lightweight, centralized control, and high scalability.

[0088] The apparatus embodiments of this application can be used to execute the method embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the method embodiments of this application.

[0089] Figure 3 The diagram shown is a block diagram of a function calling device provided in one embodiment of this application. Figure 3 As shown, the device 300 is applied to a target system, which includes a main control process and at least one local functional process. The main control process is the only process in the target system that interacts with the large language model through the model context protocol server. The device includes: The main control module 310 is used to receive a target invocation instruction based on the model context protocol sent by the large language model based on the main control process; the target invocation instruction is generated by the large language model in response to the user instruction and includes the target function identifier and invocation parameters of the target local function process; Parsing module 320 is used to parse the target invocation instruction to obtain the parsed target invocation instruction; the parsed target invocation instruction includes the target function identifier and invocation parameters of the target local function process; The sending module 330 is used to forward the parsed target call instruction to the target local function process according to the target function identifier, so that the target local function process can execute the corresponding function according to the call parameters.

[0090] Optionally, the sending module 330 includes: The verification unit is used to perform legality verification on the parsed target call instruction based on the main control process; The sending unit is used to forward the parsed target invocation instruction to the target local function process if the legality verification passes. The feedback unit is used to send a verification failure message to the large language model if the validity check fails.

[0091] Optionally, the target system is a vehicle-mounted system; the verification unit is used for: Obtain the execution permission information corresponding to the target local function process; the execution permission information is used to indicate the vehicle state conditions that need to be met to execute the function; Obtain the current status information of the vehicle where the target system is located; Based on the current status information and the vehicle status conditions, the legality of the parsed target invocation instruction is verified.

[0092] Optionally, the verification unit is used to forward the parsed target invocation instruction to the target local function process via inter-process communication.

[0093] Optionally, the device 300 further includes: The registration module is used to receive function registration information based on the model context protocol format sent by at least one local function process based on the main control process; generate a list of function capabilities based on the received function registration information; the list of function capabilities is used by the large language model to generate calling instructions for calling the functions corresponding to the local function processes; and synchronize the list of function capabilities to the large language model.

[0094] Optionally, the function registration information includes: function identifier, function description information, call parameter rule information, and execution permission information.

[0095] Optionally, the registration module is used for: The validity of one of the function identifier, call parameter rule information, and execution permission information included in the function registration information shall be verified. If the validity verification passes, a list of functional capabilities is generated based on the functional registration information.

[0096] Below, for reference Figure 4 This describes an electronic device according to embodiments of the present application. Figure 4 A block diagram of an electronic device according to an embodiment of this application is illustrated.

[0097] like Figure 4 As shown, the electronic device 400 includes one or more processors 410 and memory 420.

[0098] The processor 410 may be another form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 400 to perform desired functions.

[0099] Specifically, processor 410 can be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present invention. It can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 410 may also include a main processor, and may also include a baseband chip, a modem, etc.

[0100] The memory 420 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 410 may execute the program instructions to implement the function call methods of the various embodiments of this application described above and / or other desired functions. Various contents, such as category correspondences, may also be stored in the computer-readable storage medium.

[0101] In one example, the electronic device 400 may also include an input device 430 and an output device 440, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0102] In addition, the input device 430 can also be a device that receives user input data and information, such as a keyboard, mouse, camera, scanner, light pen, voice input device, touch screen, pedometer, or gravity sensor. The output device 440 can output various information to the outside. The output device 440 may include, for example, a display, speaker, printer, and communication networks and their connected remote output devices.

[0103] Of course, for the sake of simplicity, Figure 4 Only some of the components of the electronic device 400 relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device 400 may include any other suitable components depending on the specific application.

[0104] In addition to the methods and devices described above, embodiments of this application may also include a vehicle, comprising a vehicle body and the electronic equipment.

[0105] In addition to the methods and devices described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps of the function call methods according to various embodiments of this application as described in the "Exemplary Methods" section of this specification.

[0106] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0107] Furthermore, embodiments of this application may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps of the function call methods according to various embodiments of this application described in the "Exemplary Methods" section above.

[0108] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0109] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the application to the necessity of employing the aforementioned specific details for implementation.

[0110] For the foregoing method embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application. The steps in the methods of each embodiment of this application can be adjusted, combined, and deleted according to actual needs, and the technical features recorded in each embodiment can be replaced or combined.

[0111] It should be noted that each embodiment in this specification focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other.

[0112] The block diagrams of devices, apparatuses, devices, and systems involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0113] The modules or submodules described as separate components may or may not be physically separate. The components that constitute a module or submodule may or may not be physical modules or submodules; that is, they may be located in one place or distributed across multiple network modules or submodules. Some or all of the modules or submodules can be selected to achieve the purpose of this embodiment's solution, depending on actual needs.

[0114] Furthermore, the functional modules or sub-modules in the various embodiments of this application can be integrated into one processing module, or each module or sub-module can exist physically separately, or two or more modules or sub-modules can be integrated into one module. The integrated modules or sub-modules described above can be implemented in hardware or in the form of software functional modules or sub-modules.

[0115] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0116] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software unit executed by a processor, or a combination of both. The software unit can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0117] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

Claims

1. A function invocation method, characterized in that, Applied to a target system, the target system includes a main control process and at least one local functional process, wherein the main control process is the only process in the target system that interacts with the large language model through the model context protocol server, the method includes: Based on the main control process, the system receives a target invocation instruction based on the model context protocol sent by the large language model; the target invocation instruction is generated by the large language model in response to the user instruction and includes the target function identifier and invocation parameters of the target local function process. The target invocation instruction is parsed to obtain the parsed target invocation instruction; the parsed target invocation instruction includes the target function identifier and invocation parameters of the target local function process. Based on the target function identifier, the parsed target call instruction is forwarded to the target local function process, so that the target local function process executes the corresponding function according to the call parameters.

2. The method according to claim 1, characterized in that, The step of forwarding the parsed target invocation instruction to the target local function process includes: Based on the main control process, the legality of the parsed target call instruction is verified. If the validity check passes, the parsed target invocation instruction is forwarded to the target local function process; If the validity check fails, a verification failure message will be sent to the large language model.

3. The method according to claim 2, characterized in that, The target system is a vehicle-mounted system; the validity verification of the parsed target invocation command includes: Obtain the execution permission information corresponding to the target local function process; the execution permission information is used to indicate the vehicle state conditions that need to be met to execute the function; Obtain the current status information of the vehicle where the vehicle-end system is located; Based on the current status information and the vehicle status conditions, the legality of the parsed target invocation instruction is verified.

4. The method according to claim 1, characterized in that, The step of forwarding the parsed target invocation instruction to the target local function process includes: The parsed target invocation instruction is forwarded to the target local function process via inter-process communication.

5. The method according to claim 1, characterized in that, Before the main control process receives the target invocation instruction based on the model context protocol sent by the large language model, it also includes: Based on the main control process, receive function registration information in model context protocol format sent by at least one local function process; A list of functional capabilities is generated based on the received functional registration information; the list of functional capabilities is used by the large language model to generate invocation instructions for calling the functions corresponding to the local functional processes. Synchronize the list of functional capabilities to the large language model.

6. The method according to claim 5, characterized in that, The function registration information includes: function identifier, function description information, call parameter rule information, and execution permission information.

7. The method according to claim 6, characterized in that, The step of generating a list of functional capabilities based on the received functional registration information includes: The validity of one of the function identifier, call parameter rule information, and execution permission information included in the function registration information shall be verified. If the validity verification passes, a list of functional capabilities is generated based on the functional registration information.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is used to perform the method according to any one of claims 1 to 7.

10. A vehicle, characterized in that, Including the electronic device as described in claim 9.

Images