Mcp calling method and device based on hierarchical memory, vehicle and storage medium

Abstract

Embodiments of the present application provide a layered memory-based MCP calling method and device, a vehicle and a storage medium. The method comprises: obtaining an interaction request event of a user; generating an MCP calling chain according to the interaction request event and a layered memory architecture; and calling a corresponding target tool to execute the interaction request event based on the MCP calling chain. The embodiments of the present application can significantly improve the accuracy and reliability of MCP calling in the high real-time and high security scenarios of the automotive industry.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to an MCP recall method, device, vehicle, and storage medium based on hierarchical memory. Background Technology

[0002] With the widespread application of Large Language Models (LLMs) in scenarios such as intelligent assistants and in-vehicle interactions, the Model Context Protocol (MCP), as a standardized interface connecting LLMs with external tools and data sources, has become a key infrastructure of the AI ​​application ecosystem. MCP typically adopts a client-host-server three-element architecture, based on JSON-RPC 2.0 message semantics and multi-transport layer support, aiming to provide LLMs with consistent, secure, and scalable resource access capabilities. However, in actual deployments, the accuracy of MCP calls is a prominent issue, severely impacting the reliability of AI systems and user experience.

[0003] In related technologies, improving the accuracy of MCP invocation is mainly achieved by enhancing contextual information. For example, Retrieval-Augmented Generation-Model Context Protocol (RAG-MCP) utilizes retrieval-augmented generation to obtain relevant information from external knowledge bases to supplement the context required for tool invocation; context enhancement techniques employ methods such as hybrid retrieval and cross-encoder reordering to optimize input quality. Furthermore, memory operating systems attempt to introduce centralized memory management mechanisms to support the long-term memory capabilities of LLMs. These methods alleviate the problems of tool selection or parameter filling errors to some extent.

[0004] However, while the above solutions improve the accuracy of MCP calls to varying degrees, they are difficult to balance the comprehensive needs of accuracy, real-time performance, and personalization in scenarios with high real-time and high security requirements, such as automobiles. Summary of the Invention

[0005] This application provides a hierarchical memory-based MCP invocation method, device, vehicle, and storage medium, which can significantly improve the accuracy and reliability of MCP invocation in high real-time and high-security scenarios in the automotive industry.

[0006] In a first aspect, embodiments of this application provide an MCP invocation method based on hierarchical memory. The method includes: acquiring user interaction request events; generating an MCP invocation chain based on the interaction request events and the hierarchical memory architecture; and invoking the corresponding target tool to execute the interaction request events based on the MCP invocation chain.

[0007] In one possible implementation, the hierarchical memory architecture includes a short-term working memory layer, a user preference memory layer, a contextual memory layer, and a semantic knowledge layer. The steps of constructing the hierarchical memory architecture include: storing the context state of the current session in the short-term working memory layer; storing the user's long-term preferences, habits, and behavioral patterns in the user preference memory layer; storing the user's key interaction events and decision history in the contextual memory layer; and storing the user's knowledge graph and concept system in the semantic knowledge layer.

[0008] In one possible implementation, an MCP call chain is generated based on the interaction request event and a pre-built hierarchical memory architecture, including: determining the target tool corresponding to the interaction request event and determining the tool parameters of the target tool; and generating the MCP call chain based on the target tool and the tool parameters.

[0009] In one possible implementation, before generating the MCP call chain based on the target tool and tool parameters, the method further includes: determining the functional safety level corresponding to the interactive request event; verifying the tool parameters according to the functional safety level to obtain a verification result; and generating the MCP call chain based on the target tool and tool parameters, including: generating the MCP call chain based on the target tool and tool parameters when the verification result is a successful verification.

[0010] In one possible implementation, after calling the corresponding target tool to execute the interaction request event based on the MCP call chain, the method further includes: updating the hierarchical memory architecture based on the interaction request event, the functional safety level, and the MCP call chain.

[0011] In one possible implementation, updating the hierarchical memory architecture includes: determining the memory type corresponding to the interaction request event based on the functional safety level; determining the storage policy and synchronization policy based on the memory type; and updating the interaction request event and MCP call chain to the hierarchical memory architecture based on the storage policy and synchronization policy.

[0012] In one possible implementation, the storage strategy includes storage location; the synchronization strategy includes synchronization frequency.

[0013] Secondly, embodiments of this application provide an MCP invocation device based on hierarchical memory, comprising: an acquisition module for acquiring user interaction request events; a generation module for generating an MCP invocation chain based on the interaction request events and the hierarchical memory architecture; and an invocation module for invoking the corresponding target tool to execute the interaction request events based on the MCP invocation chain.

[0014] Thirdly, embodiments of this application provide a vehicle, including: a memory and a processor;

[0015] The memory stores the instructions that the computer executes;

[0016] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0018] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0019] In this embodiment, by acquiring the user's interaction request event; generating an MCP call chain based on the interaction request event and the hierarchical memory architecture; and calling the corresponding target tool to execute the interaction request event based on the MCP call chain, the tool selection and calling decision can be more in line with the user's current needs and historical interaction characteristics, reducing problems such as tool misselection, parameter mapping deviation and inaccurate context understanding, thereby improving the accuracy, personalization adaptation capability and response reliability of tool calling in the vehicle scenario. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] Figure 1 This is a schematic diagram illustrating an application scenario of an MCP invocation method based on hierarchical memory, according to an embodiment of this application.

[0022] Figure 2 A flowchart illustrating an MCP invocation method based on hierarchical memory provided in this application embodiment;

[0023] Figure 3 A flowchart illustrating an MCP invocation method based on hierarchical memory provided in this application embodiment;

[0024] Figure 4 A schematic diagram of the updated hierarchical memory architecture provided in an embodiment of this application;

[0025] Figure 5 A schematic diagram of the structure of an MCP recall device based on hierarchical memory provided in this application embodiment;

[0026] Figure 6 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0027] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described below do not represent all embodiments consistent with this application. They are merely examples of systems and methods consistent with some aspects of this application as detailed in the claims.

[0028] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0029] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0030] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0031] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0032] With the widespread application of Large Language Models (LLMs) in scenarios such as intelligent assistants and in-vehicle interactions, the Model Context Protocol (MCP), as a standardized interface connecting LLMs with external tools and data sources, has become a key infrastructure of the AI ​​application ecosystem. MCP typically adopts a client-host-server three-element architecture, based on JSON-RPC 2.0 message semantics and multi-transport layer support, aiming to provide LLMs with consistent, secure, and scalable resource access capabilities. However, in actual deployments, the accuracy of MCP calls is a prominent issue, severely impacting the reliability of AI systems and user experience.

[0033] In related technologies, improving the accuracy of MCP invocation is mainly achieved by enhancing contextual information. For example, Retrieval-Augmented Generation-Model Context Protocol (RAG-MCP) utilizes retrieval-augmented generation to obtain relevant information from external knowledge bases to supplement the context required for tool invocation; context enhancement techniques employ methods such as hybrid retrieval and cross-encoder reordering to optimize input quality. Furthermore, memory operating systems attempt to introduce centralized memory management mechanisms to support the long-term memory capabilities of LLMs. These methods alleviate the problems of tool selection or parameter filling errors to some extent.

[0034] However, while the above solutions improve the accuracy of MCP calls to varying degrees, they are difficult to balance the comprehensive needs of accuracy, real-time performance, and personalization in scenarios with high real-time and high security requirements, such as automobiles.

[0035] In view of this, this application provides an MCP invocation method based on hierarchical memory. By constructing a hierarchical user long-range memory architecture, user memory is divided into short-term working memory, preference memory, contextual memory, and semantic knowledge layers to achieve multi-dimensional behavioral modeling. Combined with edge-first storage and an Automotive Safety Integrity Level (ASIL)-aware memory governance mechanism, personalized optimization of the MCP invocation chain is achieved. This method establishes processing logic integrated with the hierarchical memory architecture between request acquisition, invocation chain generation, and execution of the target tool. This enables the in-vehicle system to more effectively complete tool invocations when faced with continuous instructions, complex intents, and personalized needs, thereby improving the accuracy, adaptability, and execution reliability of invocations in in-vehicle scenarios, and laying the foundation for the development of subsequent specific technical solutions.

[0036] Before introducing the MCP invocation method based on hierarchical memory provided in the embodiments of this application, the application scenarios of the MCP invocation method based on hierarchical memory will be explained first.

[0037] Figure 1This diagram illustrates an application scenario of the MCP invocation method based on hierarchical memory, as described in this application. The technical solution of this application is primarily applied to cockpit systems, autonomous driving decision-making systems, and vehicle-to-everything (V2X) interaction scenarios in intelligent vehicles. In the in-vehicle environment, users interact with the AI ​​system via voice, gestures, or touch, and the system needs to invoke tools such as navigation, vehicle control, entertainment, and safety monitoring. This scenario places extremely high demands on the accuracy, real-time performance (millisecond-level response), and security (compliant with ISO 26262 standards) of MCP invocation, and it also needs to dynamically adapt to users' personalized preferences (such as frequently used routes, music genres, and interaction habits). The MCP invocation system, from top to bottom, consists of an application layer, an MCP invocation layer, a memory enhancement layer, a memory storage layer, and an infrastructure layer.

[0038] The application layer, located at the top of the system architecture, directly interacts with the driver, passengers, and external objects, and is responsible for converting users' natural interactions within the in-vehicle environment into application-level request events that the system can recognize and process. For example... Figure 1 As shown, the application layer includes at least intelligent driving applications, in-vehicle human-machine interface (HMI) applications, V2X (Vehicle-to-Everything) communication applications, and other automotive applications.

[0039] Among them, intelligent driving applications cover autonomous driving decision-making interaction, assisted driving status query, and driving safety-related requests; in-vehicle HMI applications are responsible for receiving and processing interactive content input through voice, touch, steering wheel buttons, gestures, or facial gaze signals; V2X communication applications are used to handle collaborative interaction requests between vehicles, between vehicles and roadside facilities, and between vehicles and cloud service platforms; other automotive applications include extended applications such as cockpit environment control, infotainment services, remote diagnostics, and third-party ecosystem services. After receiving user input, the application layer performs noise removal, format normalization, and context completion on the raw interactive data to form structured interactive request events, and then passes them down to the MCP calling layer.

[0040] The MCP call layer is the core decision-making and orchestration layer of the system. Its function is to transform interactive request events passed from the application layer into executable MCP call chains. For example... Figure 1 As shown, the MCP call layer includes at least a tool selection engine, a parameter prediction module, a sequence planner, and an error recovery mechanism.

[0041] The tool selection engine is responsible for selecting the target tool that best matches the interactive request event from the candidate tool set based on the current request semantics and multi-source context information obtained from the memory enhancement layer. It calculates the matching score by comprehensively considering semantic matching degree, historical successful call frequency, scenario adaptability, parameter completeness, and security constraint compliance. The parameter prediction module, after determining the target tool, generates the required tool parameters by combining explicit request content, hierarchical memory retrieval results, and semantic knowledge constraints, and eliminates parameter conflicts through context consistency verification. The sequence planner, when the interactive request involves multiple capability interfaces or composite intents, arranges the call order of the target tool and its parameters according to the dependencies, parallel feasibility, and execution priority between tools, forming an MCP call chain that includes link identifiers, node lists, parameter dictionaries, execution order, parallel relationships, dependencies, and failure fallback strategies. The error recovery mechanism, when a tool call fails, parameter verification fails, or network anomalies occur, executes alternative solution switching, local cache degradation, or user clarification requests according to the preset fallback strategies in the MCP call chain to ensure the continuity and stability of the call process.

[0042] The memory enhancement layer is an intermediate processing layer connecting the MCP invocation layer and the memory storage layer. Its function is to retrieve, fuse, update, and manage the raw memory data in the memory storage layer, enabling it to effectively support MCP invocation decisions. Figure 1 As shown, the memory enhancement layer includes at least a memory retrieval engine, a memory fusion processor, a memory update controller, and a memory governance module.

[0043] The memory retrieval engine uses user identifiers, session identifiers, location status, timestamps, vehicle status, and semantic fragments from interactive request events as retrieval keys. It performs matching searches in each memory layer of the memory storage layer to obtain short-term context, long-term preferences, historical scenarios, and semantic knowledge related to the current request. The memory fusion processor is responsible for weighted fusion and conflict resolution of multi-source retrieval results from different memory layers, generating a unified contextual representation for use by the tool selection engine and parameter prediction module. The memory update controller is responsible for determining storage and synchronization strategies based on functional safety levels and memory types after the target tool has completed execution, and writing back the interactive request event, MCP call chain, and execution results to the memory storage layer. The memory governance module is responsible for implementing ASIL-aware memory access control, memory importance assessment, natural memory decay, and obsolete information eviction, ensuring the security, timeliness, and relevance of the memory database content, and preventing privacy leaks, security vulnerabilities, and memory contamination.

[0044] In practical applications, the fusion logic of the memory fusion processor can dynamically adjust the weight of each memory layer according to the functional safety level. For example, in high-safety-level scenarios, the constraint rules of the semantic knowledge layer are given priority, and in personalized service scenarios, the habit parameters of the user preference memory layer are given priority.

[0045] The memory storage layer is the system's data accumulation and context support layer, employing a hierarchical organizational structure to store user memories at different time scales and semantic granularities. For example... Figure 1 As shown, the memory storage layer includes at least short-term working memory, user preference memory, episodic memory layer, and semantic knowledge layer.

[0046] The system comprises four layers: Short-term working memory (STM) and Semantic knowledge layer. STM stores recent interactions, completed tool calls, and the current task context, supporting rapid retrieval of pronouns, omitted expressions, and continuous dialogue cues. User preference memory stores stable selection tendencies formed over a longer period, such as frequently used navigation routes, default air conditioning temperatures, music genres, contacts, and service providers, supporting parameter default value prediction and dynamic tool priority adjustment. Contextual memory stores key interaction events and decision history related to contextual variables such as time, location, vehicle status, and travel purpose, supporting repetitive scenario recognition and reuse of historical behavior patterns. The Semantic knowledge layer stores tool capability descriptions, parameter semantic constraints, entity relationship mappings, and in-vehicle domain concept systems, supporting fuzzy expression resolution, parameter validity verification, and cross-tool semantic association. These four layers of memory work collaboratively to achieve joint modeling of short-term behavior and long-term preferences, providing comprehensive memory support for MCP calls, covering immediate context, stable habits, historical scenarios, and domain knowledge.

[0047] The infrastructure layer, located at the bottom of the system architecture, provides fundamental support for hardware resources, data security, and cross-domain collaboration to the upper layers. For example... Figure 1 As shown, the infrastructure layer may include edge storage devices, cloud synchronization services, security encryption modules, and audit and monitoring systems.

[0048] Edge storage devices are deployed in vehicles to persistently store critical user memories and frequently accessed data locally, ensuring millisecond-level memory retrieval even under network fluctuations or weak network conditions. Cloud synchronization services perform cross-vehicle and cross-device memory synchronization between edge storage and the cloud data center, supporting memory migration and consistency maintenance across multiple vehicles or terminals; its synchronization frequency can be configured differently based on functional safety levels and memory types. A security encryption module encrypts memory data and the MCP call chain during transmission, storage, and access, meeting privacy protection and data compliance requirements in in-vehicle scenarios. An auditing and monitoring system performs end-to-end auditing and traceability monitoring of memory access behavior, tool call processes, and parameter change records, supporting anomaly detection, security event backtracking, and call effect evaluation.

[0049] Furthermore, this application embodiment also incorporates a real-time memory update and incremental learning mechanism. Specifically, it can capture and store important interaction information in real time, dynamically assess the importance of memories based on information gain and user feedback, and simulate human memory mechanisms to achieve natural memory decay and long-term consolidation of important information. In this way, user behavior is captured and updated in the memory bank in real time, and outdated information is eliminated through the importance assessment mechanism, thereby ensuring the timeliness and relevance of the memory bank and avoiding memory contamination and interference from outdated information.

[0050] The following section, in conjunction with the accompanying drawings and application scenarios, provides a detailed description of the MCP invocation method based on hierarchical memory provided in the embodiments of this application.

[0051] Figure 2 This is a flowchart illustrating an MCP invocation method based on hierarchical memory, provided as an embodiment of this application. Figure 2 As shown, the method provided in this embodiment can be applied to, for example... Figure 1 In the application scenario shown, specifically, the MCP invocation method based on hierarchical memory may include the following steps:

[0052] S201, Get the user's interaction request event.

[0053] The interaction request event is an input object issued by the user to trigger subsequent Model Context Protocol (MCP) calls. Its core function is to transform the user's natural interactive behavior in the in-vehicle environment into event data that the system can recognize, compute, and program, so as to provide basic input for the generation of subsequent MCP call chains. This interaction request event can originate from at least one of the following: voice, touch, steering wheel buttons, gesture recognition, facial gaze signals, or remote commands from a mobile terminal.

[0054] S202 generates the MCP call chain based on the interactive request event and the hierarchical memory architecture.

[0055] The hierarchical memory architecture is a memory organization structure used to support MCP invocation decisions. Its role is to provide multi-granularity and multi-timescale contextual support for the current interaction request, enabling the system to complete tool selection and parameter estimation based on long-term user habits, recent interaction trajectories, historical contextual events, and semantic knowledge relationships, beyond the current request. The MCP invocation chain refers to the complete process of MCP invocation, describing the complete link from request understanding, tool selection, parameter construction, invocation dependency orchestration to execution order determination.

[0056] In its implementation, the hierarchical memory architecture comprises a short-term working memory layer, a user preference memory layer, a contextual memory layer, and a semantic knowledge layer. The short-term working memory layer stores the most recent rounds of interactions in the current session, the results of completed tool calls, and the current task context. The user preference memory layer stores long-term stable user preferences, such as frequently used navigation routes, default air conditioning temperatures, commonly listened-to music genres, frequently contacted individuals, and frequently selected service providers. The contextual memory layer stores historical events related to time, location, vehicle status, and travel purpose, such as frequently going to work during weekday morning rush hour, frequently checking nearby charging stations when the battery is low, and preferring to lower the volume while driving at night. The semantic knowledge layer stores tool capability descriptions, parameter semantic constraints, entity relationship mappings, and in-vehicle domain knowledge to support fuzzy expression resolution and parameter completion.

[0057] Specifically, when generating the MCP call chain, the interactive request event can first be semantically parsed to obtain intent candidates, object candidates, constraint candidates, and action candidates. Subsequently, using the user identifier, session identifier, location status, timestamp, vehicle status, and semantic fragments in the interactive request event as retrieval keys, matching and retrieval are performed in the hierarchical memory architecture.

[0058] For the short-term working memory layer, the system can look up objects mentioned in recent conversations and tasks being performed; for the user preference memory layer, the system can extract stable preference parameters as candidates for default values; for the contextual memory layer, the system can retrieve historical high-similarity events based on the current location, time period, and vehicle status to determine whether the current request belongs to a recurring scenario; for the semantic knowledge layer, the system can determine which tools can meet the current intent based on the tool capability definition and parameter dependencies, as well as the required, optional, and constraint parameters for each tool.

[0059] Subsequently, an MCP call chain is generated based on the determined target tool and tool parameters. In one possible embodiment, the MCP call chain can adopt a structured link description format, which, for example, may include link identifier, node list, node type, tool name, parameter dictionary, execution order, parallel relationships, dependencies, failure fallback strategy, and result write-back rules.

[0060] Furthermore, after determining the tool parameters of the target tool, it is also necessary to determine the functional safety level corresponding to the interactive request event; based on the functional safety level, the tool parameters are validated to obtain the validation result. If the validation result is successful, an MCP call chain is generated based on the target tool and its parameters.

[0061] For example, when a user requests "navigate to the nearest gas station", the system calls the navigation tool, predicts the location parameters of the "gas station", and checks whether it matches the user's preferences (such as avoiding highways).

[0062] S203, based on the MCP call chain, calls the corresponding target tool to execute the interactive request event.

[0063] A target tool is a functional entity that corresponds to an interactive request event and is used to actually complete the user's requested task. It can be a navigation tool, a vehicle control tool, a media tool, a vehicle status query tool, a remote service tool, a third-party life service tool, or a safety assistance tool.

[0064] Specifically, upon receiving the MCP call chain, each tool node in the chain can be parsed and converted into a call instruction supported by the corresponding interface protocol. If the target tool is a local vehicle capability, such as air conditioning control, window control, seat adjustment, media playback, and local map navigation, the call can be initiated directly through the vehicle service bus, local application service interface, or vehicle communication interface. If the target tool is a cloud or third-party capability, such as online music, real-time charging station status, weather, or remote customer service, the request is initiated to the external service through the interface gateway when the network conditions are met, and local caching results or degradation strategies are enabled when necessary.

[0065] In one possible implementation, after invoking the target tool to execute the interactive request event, the process may also include result write-back and memory update. If the tool invocation is successful, information such as the invocation result, final parameters, execution time, user confirmation, whether the user subsequently made manual modifications, and environment status can be written back to the hierarchical memory architecture.

[0066] Among them, the short-term working memory layer updates the execution result of the current session, the user preference memory layer can update the default preference after multiple confirmations, the context memory layer records the time, location and execution mode of this request, and the semantic knowledge layer can synchronously update the capability description when the tool description changes.

[0067] If the tool call fails, an alternative solution can be executed according to the failure fallback strategy in the MCP call chain. For example, when the online music service is unavailable, switch to the local media library; when the cloud charging station data is unreachable, switch to the local cache site; and generate a clarification query when parameter conflicts cannot be resolved automatically.

[0068] After execution, the system outputs the execution result to the user through voice broadcast, interface prompts, instrument panel display, or haptic feedback, so that the user can clearly know whether the task has been completed and its completion status. For example, when the interaction request is "navigate to the nearest charging station and set the air conditioner to 22 degrees", the system can first call the vehicle status query tool to obtain the remaining range, then call the navigation tool to filter the nearest accessible charging station, and simultaneously call the air conditioner control tool to set the temperature, and finally announce to the user "You have been navigated to the nearest accessible charging station, and the air conditioner has been set to 22 degrees".

[0069] The technical solution of this embodiment acquires user interaction request events; generates an MCP call chain based on the interaction request events and a hierarchical memory architecture; and invokes the corresponding target tool to execute the interaction request events based on the MCP call chain. Thus, by unifying and abstracting user multimodal interactions into structured event inputs, and combining a hierarchical memory architecture composed of short-term working memory, user preference memory, contextual memory, and semantic knowledge to complete the call chain planning, and driving the target tool execution and result write-back based on the generated call chain, the in-vehicle system can simultaneously improve tool matching accuracy, parameter determination completeness, and execution process stability when processing continuous instructions, fuzzy expressions, complex tasks, and personalized requests. Furthermore, reducing reliance on simple cloud retrieval and static tool documentation helps shorten response latency and reduce the impact of network fluctuations on call results, significantly improving the accuracy and reliability of MCP calls in the high-real-time and high-security scenarios of the automotive industry.

[0070] Based on the above embodiments, the steps of constructing a hierarchical memory architecture may further include: storing the context state of the current session in the short-term working memory layer; storing the user's long-term preferences, habits, and behavioral patterns in the user preference memory layer; storing the user's key interaction events and decision history in the context memory layer; and storing the user's knowledge graph and concept system in the semantic knowledge layer.

[0071] When constructing a hierarchical user long-range memory architecture, the system first maintains the context state of the current session through a short-term working memory layer to ensure immediate response in tool selection and parameter prediction. Then, a user preference memory layer stores long-term user preferences, dynamically adjusting tool call priorities. Next, a contextual memory layer records key interaction events and retrieves historical behavior patterns to avoid contextual understanding biases. Finally, a semantic knowledge layer stores the user's knowledge graph to verify the legality of parameter types and enumerated values. Through this hierarchical storage, the system provides comprehensive personalized context support for the MCP call chain.

[0072] For example, when a user requests navigation, the short-term working memory layer captures the immediate intent of "the user is currently requesting navigation"; the user preference memory layer adjusts the route planning tool's invocation strategy based on "the user prefers to avoid highways when navigating at night"; the contextual memory layer proactively recommends assistance functions related to driving in rainy weather based on historical events such as "the user activates automatic wipers in rainy weather"; and the semantic knowledge layer uses a knowledge graph of "the user's familiarity with 'fuel level' terminology" to employ familiar professional expressions when querying fuel level, ensuring the accuracy of parameter transmission.

[0073] The technical solution in this embodiment, by storing user short-term behavior and long-term preferences in a layered manner, can achieve comprehensive optimization of tool selection, parameter prediction, and context verification. For example, the short-term working memory layer ensures immediate response to the current session state, the user preference memory layer dynamically adjusts the tool call priority, the context memory layer retrieves historical behavior patterns to eliminate context bias, and the semantic knowledge layer verifies parameter validity. Through the above-mentioned layered collaboration, the system significantly improves the accuracy of tool selection, the reliability of parameter prediction, and the depth of context understanding, thereby achieving personalized optimization of the MCP call chain in high-safety-level scenarios in the automotive industry.

[0074] In this embodiment, to ensure the effectiveness and personalized adaptability of the hierarchical memory architecture, based on the technology of the above embodiments, after S203, the method provided in this embodiment can also update the hierarchical memory architecture based on interactive request events, functional safety levels, and MCP call chains.

[0075] Specifically, such as Figure 3 and Figure 4 As shown, in this embodiment, the steps for updating the hierarchical memory architecture include the following S301 to S303:

[0076] S301, determine the memory type corresponding to the interactive request event based on the functional safety level.

[0077] S302, determine the storage strategy and synchronization strategy based on the memory type.

[0078] S303 updates interactive request events and MCP call chains to the hierarchical memory architecture based on storage and synchronization strategies.

[0079] Among them, the functional safety level is used to characterize the safety sensitivity and execution constraint strength of the interaction request event in the vehicle scenario. The memory type is used to characterize the type of memory layer in the hierarchical memory architecture that carries the interaction request event. The storage strategy is used to limit the write granularity, retention period, and overwrite method of the interaction request event and the MCP call chain; the synchronization strategy is used to limit the update timing, synchronization scope, and consistency requirements between memory layers.

[0080] When updating the hierarchical memory architecture, the memory type to which the interactive request event should be written can be determined first based on the functional safety level. Then, the corresponding storage and synchronization strategies can be selected according to the memory type. Subsequently, the interactive request event and its corresponding MCP call chain can be written to the target memory layer according to the strategy, and synchronized to the associated memory layer when necessary to form a reusable historical context.

[0081] In one feasible implementation, the storage strategy may include storage location, and the synchronization strategy may include synchronization frequency.

[0082] The storage location is used to indicate the writing area of ​​the interaction request event and MCP call chain in the hierarchical memory architecture. The writing area can correspond to any of the short-term working memory layer, user preference memory layer, context memory layer or semantic knowledge layer. It can also be further subdivided into different storage units within the same memory layer to respectively carry the current session context, long-term preference records, key interaction history and conceptual knowledge entries.

[0083] Synchronization frequency represents the time interval or triggering cycle for data consistency updates between different storage locations. The system can configure different synchronization frequencies for different storage locations based on functional safety level, memory type, and the importance of interactive request events, so that high-security information is synchronized at a higher frequency, while low-frequency usage information is synchronized at a lower frequency, thereby reducing the overhead of repeated writes and maintaining the effective consistency of memory content.

[0084] For example, the correspondence between functional safety levels, memory types, synchronization strategies, and storage strategies can be shown in Table 1:

[0085]

[0086] In other words, for interactive request events with a functional safety level of ASIL-D, the corresponding memory type is safety-critical memory, the synchronization frequency is real-time synchronization, the storage location is the edge and the cloud, and the access latency is less than 1ms.

[0087] For interactive request events with a functional safety level of ASIL-B / C, the corresponding memory type is critical functional memory, the synchronization frequency is once every 5 minutes, the storage location is edge-priority, and it can also be stored in the cloud when necessary, with an access latency of less than 10ms.

[0088] For interactive request events with a functional safety level of ASIL-A, the corresponding memory type is general functional memory, the synchronization frequency is once every 30 minutes, the storage location is mainly in the cloud, and the access latency is less than 100ms. For interactive request events with a functional safety level of insecure, the corresponding memory type is user preference memory, the synchronization frequency is on-demand synchronization, that is, synchronization is performed when necessary, the storage location is in the cloud, and the access latency is less than 500ms.

[0089] The technical solution of this embodiment enables high-security requests and ordinary requests to be treated differently in memory maintenance. This not only ensures the controllable preservation of security-sensitive information, but also improves the efficiency of utilizing historical information when generating subsequent MCP call chains, thereby enhancing call accuracy, context continuity, and in-vehicle interaction stability.

[0090] This application also provides an MCP recall device based on hierarchical memory. For example... Figure 5 As shown, the MCP invocation device 500 based on hierarchical memory includes: an acquisition module 501 for acquiring user interaction request events; a generation module 502 for generating an MCP invocation chain based on the interaction request events and the hierarchical memory architecture; and an invocation module 503 for invoking the corresponding target tool to execute the interaction request events based on the MCP invocation chain.

[0091] In some embodiments, the hierarchical memory architecture includes a short-term working memory layer, a user preference memory layer, a contextual memory layer, and a semantic knowledge layer; the MCP invocation device 500 based on hierarchical memory also includes a construction module for storing the context state of the current session in the short-term working memory layer; storing the user's long-term preferences, habits, and behavioral patterns in the user preference memory layer; storing the user's key interaction events and decision history in the contextual memory layer; and storing the user's knowledge graph and concept system in the semantic knowledge layer.

[0092] In some embodiments, the generation module 502 is specifically used to determine the target tool corresponding to the interaction request event, and to determine the tool parameters of the target tool; and to generate an MCP call chain based on the target tool and the tool parameters.

[0093] In some embodiments, the MCP invocation device 500 based on hierarchical memory further includes a determination module for determining the functional safety level corresponding to the interactive request event; and a verification module for verifying the tool parameters according to the functional safety level to obtain a verification result. Correspondingly, the generation module 502 is specifically used to generate an MCP invocation chain based on the target tool and tool parameters when the verification result is a pass.

[0094] In some embodiments, the MCP invocation device 500 based on hierarchical memory further includes an update module for updating the hierarchical memory architecture based on interactive request events, functional safety levels, and MCP invocation chains.

[0095] In some embodiments, the update module is specifically configured to: determine the memory type corresponding to the interaction request event based on the functional safety level; determine the storage policy and synchronization policy based on the memory type; and update the interaction request event and MCP call chain to the hierarchical memory architecture based on the storage policy and synchronization policy. The storage policy includes the storage location; the synchronization policy includes the synchronization frequency.

[0096] The MCP calling device based on hierarchical memory provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0097] Figure 6 This is a structural diagram of the vehicle provided in this application. Figure 6 As shown, the vehicle 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the vehicle 60 also includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0098] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0099] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0100] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0101] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0102] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0103] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0104] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0105] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0106] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0107] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0108] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0109] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0110] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, 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 personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0111] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0112] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for calling MCP based on hierarchical memory, characterized in that, The method includes: Get user interaction request events; Based on the interactive request events and the hierarchical memory architecture, an MCP call chain is generated; Based on the MCP call chain, the corresponding target tool is invoked to execute the interactive request event.

2. The method according to claim 1, characterized in that, The hierarchical memory architecture includes a short-term working memory layer, a user preference memory layer, a contextual memory layer, and a semantic knowledge layer; the steps for constructing the hierarchical memory architecture include: The context state of the current session is stored in the short-term working memory layer; The user preference memory layer stores users' long-term preferences, habits, and behavioral patterns. The contextual memory layer stores key user interaction events and decision history. The semantic knowledge layer stores the user's knowledge graph and concept system.

3. The method according to claim 2, characterized in that, The step of generating the MCP call chain based on the interactive request event and the pre-built hierarchical memory architecture includes: Identify the target tool corresponding to the interaction request event, and determine the tool parameters of the target tool; The MCP call chain is generated based on the target tool and the tool parameters.

4. The method according to claim 3, characterized in that, Before generating the MCP call chain based on the target tool and the tool parameters, the method further includes: Determine the functional security level corresponding to the interaction request event; The tool parameters are verified according to the functional safety level to obtain the verification result; The process of generating the MCP call chain based on the target tool and the tool parameters includes: When the verification result is successful, the MCP call chain is generated based on the target tool and the tool parameters.

5. The method according to claim 4, characterized in that, After invoking the corresponding target tool to execute the interactive request event based on the MCP call chain, the method further includes: The hierarchical memory architecture is updated based on the interactive request event, the functional safety level, and the MCP call chain.

6. The method according to claim 5, characterized in that, The update of the hierarchical memory architecture includes: Based on the functional safety level, determine the memory type corresponding to the interaction request event; Based on the memory type, determine the storage strategy and synchronization strategy; Based on the storage strategy and the synchronization strategy, the interactive request event and the MCP call chain are updated to the hierarchical memory architecture.

7. The method according to claim 6, characterized in that, The storage strategy includes storage location; the synchronization strategy includes synchronization frequency.

8. An MCP recall device based on hierarchical memory, characterized in that, include: The acquisition module is used to acquire user interaction request events; The generation module is used to generate the MCP call chain based on the interactive request event and the hierarchical memory architecture; The calling module is used to invoke the corresponding target tool to execute the interactive request event based on the MCP call chain.

9. A vehicle, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images