Vehicle control method, device and vehicle control system

Abstract

The embodiment of the application relates to the technical field of vehicle intelligent control, and discloses a vehicle control method, a vehicle control device and a vehicle control system, the method comprising the following steps: in response to an event triggering instruction of a vehicle, target memory matched with the event triggering instruction is acquired based on pre-stored multiple candidate memories, wherein the candidate memories are constructed and stored by a central agent according to sub-candidate memories generated by each sub-agent module; and a vehicle control instruction corresponding to the target memory is executed. The technical scheme of the application can improve the intelligent level of an intelligent cockpit.

Description

Technical Field

[0001] This invention relates to the field of vehicle intelligent control technology, specifically to a vehicle control method, device, and vehicle control system. Background Technology

[0002] Currently, the memory systems in smart cockpits mainly focus on storing configuration parameters and recording simple user preferences. They store user preference information, such as seat, rearview mirror, air conditioning, and media settings, through local configuration files. The triggering mechanism relies on active user operation, and the effect of control adjustments is limited to the current single session. All contextual information related to the session (such as driving habits and scene associations) is completely erased after the vehicle restarts.

[0003] It can be seen that current smart cockpits can only store and reproduce static preference configurations once, meaning they can only passively respond to user commands and cannot meet users' intelligent usage needs. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention provide a vehicle control method to solve the problem that existing intelligent cockpits cannot meet the needs of intelligent use.

[0005] According to one aspect of the present invention, a vehicle control method is provided, applied to a vehicle control system, the vehicle control system including a central agent module and at least two sub-agent modules, the method comprising: In response to an event trigger command from a vehicle, a target memory matching the event trigger command is obtained based on multiple pre-stored candidate memories, wherein the central agent constructs and stores the candidate memories based on the sub-candidate memories generated by each of the sub-Agent modules; Execute the vehicle control command corresponding to the target memory.

[0006] According to another aspect of the present invention, a vehicle control device is provided, comprising: The acquisition module is used to respond to the event triggering command of the vehicle, and acquire the target memory that matches the event triggering command based on a plurality of pre-stored candidate memories, wherein the central agent constructs and stores the candidate memory according to the sub-candidate memory generated by each of the sub-Agent modules; The execution module is used to execute the vehicle control commands corresponding to the target memory.

[0007] According to another aspect of the present invention, a vehicle is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, the executable instruction causing the processor to perform the operation of the vehicle control method as described above.

[0008] This invention, in response to vehicle event-triggered commands, retrieves a target memory matching the command based on a pre-stored pool of candidate memories. These candidate memories are constructed and stored by a central agent based on sub-candidate memories generated by each sub-agent module. Finally, the vehicle control command corresponding to the target memory is executed. This overcomes the limitations of traditional smart cockpits that rely solely on static preference configurations for single-time reproduction. In the field of vehicle intelligent control, this invention leverages a candidate memory system continuously mined by multiple sub-agents in their respective business domains and aggregated by a central agent. Upon event triggering, it automatically matches and invokes the matching target memory to achieve vehicle control. This represents a shift from discrete command responses to scenario-based proactive adaptation, making vehicle control behavior more aligned with users' actual usage habits and potential intentions, thereby enhancing the intelligence level of cockpit interaction.

[0009] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0010] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a first embodiment of the vehicle control method provided by the present invention is shown. Figure 2 This diagram illustrates the data exchange between the central Agent and sub-Agents in the vehicle control method provided by the present invention. Figure 3 A schematic diagram of the structure of a first embodiment of the vehicle control device provided by the present invention is shown. Figure 4 A structural schematic diagram of an embodiment of the vehicle provided by the present invention is shown. Detailed Implementation

[0011] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0012] It's important to note that traditional smart cockpit memory systems primarily focus on configuration and simple user preference recording. For static driver / user configuration memory storage, parameters such as seat position, rearview mirror, air conditioning, media preferences, navigation preferences, and cabin lighting are typically saved in "files" using non-relational databases (such as JSON, XML files, or internal storage), EEPROM (Electrically Erasable Programmable Read-Only Memory), or embedded databases. These files are restored when the user enters or logs in, often through embedded configuration storage combined with local / cloud synchronization. For memory applications, preference memory is typically triggered by rules / templates. For example, a user might explicitly set a music preference ("light music") via menu or voice, and the system triggers the action according to the rules. However, voice assistants only remember the context within a single driving session, and this memory is lost after multiple device restarts. It's evident that current smart cockpit management technology lacks cross-scenario, long-term semantic memory and cannot achieve deep reasoning capabilities. For instance, the system knows that the air conditioning temperature needs to be set to 22°C, but it doesn't know that the user does this because "the user habitually lowers the temperature when picking up their child from school because the child sweats easily."

[0013] Current personalized services in smart cockpits are based solely on preset rule sets and simple behavior counting, lacking deep contextual reasoning and proactive service capabilities. For example, the system might record that a user frequently listens to playlist A, but it cannot infer that if the user is in a bad mood, it should proactively play the "relaxing" playlist B from their favorites. In other words, it lacks proactive intelligence. Furthermore, the smart cockpit's memory representation and retrieval efficiency are low. When a user asks the system, "Did I adjust my seat further back when I went to the beach last time?", the system can only passively navigate to the "seat adjustment" menu.

[0014] Based on this, in order to improve the intelligence level of the intelligent cockpit and realize deep semantic association and unified memory modeling across business domains, this invention uses a central agent (intelligent agent) to coordinate with sub-agents in various domains to transform multi-source heterogeneous interaction logs into a unified memory representation architecture (UMR). This records what the vehicle "did" while mining the triggering conditions and core intentions behind the behavior, thus realizing a leap from discrete data recording to full-domain semantic understanding.

[0015] Therefore, in the first aspect, please refer to Figure 1 , Figure 1 A flowchart of a first embodiment of the vehicle control method of the present invention is shown, which is executed by a vehicle control system. Figure 1 As shown, the method includes the following steps: Step S10: In response to the event triggering command of the vehicle, based on a plurality of pre-stored candidate memories, obtain the target memory that matches the event triggering command.

[0016] In this embodiment, the event triggering command refers to a standardized signal or command generated by various onboard systems during vehicle operation that can trigger the memory matching process, including but not limited to user voice commands, navigation destination settings, vehicle start signals, and environmental sensor data threshold exceeding signals. Candidate memories are a standardized set of memory entries constructed by the central agent based on the sub-candidate memories reported by each sub-agent module, after unified representation conversion, deduplication verification, and confidence assessment. These candidate memories are stored in a database, and each candidate memory typically includes at least one of the following core fields: triggering conditions, behavioral content, applicable scenario, confidence level, and source evidence chain. Target memories are one or more memory entries selected from the candidate memory set after scenario matching degree calculation and confidence ranking, that best match the current event triggering command.

[0017] The central agent module is the core of global scheduling and decision-making in the vehicle control system, possessing capabilities such as memory fusion, conflict arbitration, unified representation conversion, storage orchestration, and command issuance. This central agent does not directly process raw sensor data; instead, it acts as a collaborative hub for various sub-agents, responsible for transforming multi-source, heterogeneous sub-candidate memories into a unified architecture. Specifically, memory mining is performed at the memory mining layer through the central agent module and multiple sub-agent modules. When an event is triggered, the application layer's active service execution module performs the task, such as retrieving the target memory through the voice assistant module. Sub-agent modules are local memory mining units deployed in different business domains. Based on specific vehicle business data types, sub-agent modules include at least a voice interaction memory extraction agent, a navigation record memory mining agent, a multimedia playback record memory mining agent, a vehicle control point memory mining agent, and a vehicle owner setting memory alignment agent. Each sub-agent serves the data stream monitoring and local feature extraction of its respective business domain, generating sub-candidate memories for the corresponding domain and reporting them to the central agent module. Therefore, sub-candidate memories are domain-specific memory entries formed by each sub-agent based on the original interaction data within its respective business domain, and they carry domain identifiers, local confidence levels, and source evidence.

[0018] As an optional implementation, multi-dimensional matching and retrieval of memories can be performed based on a preset rule engine, that is, by comparing event features with memory condition fields. Specifically, when the vehicle generates an event trigger command, such as receiving a user voice command, detecting a change in vehicle status, or detecting environmental parameters exceeding limits, the command is triggered. At this time, the active service decision module of the vehicle control system's retrieval and application layer receives the standardized event and determines whether the event meets the memory retrieval trigger conditions. If it does, the memory retrieval device is invoked to start the target memory retrieval process. Then, after receiving the retrieval request, the memory retrieval device accesses the relational database and performs precise matching of the event's various dimensional features with the structured trigger condition fields of the candidate memories, filtering out all candidate memories that meet the conditions, and then sorting them by confidence and popularity, taking the memory ranked first as the initial target memory. After the initial target memory is returned to the active service decision module, memories with high confidence and no ambiguity are directly confirmed and taken effect. For memories with medium confidence and / or involving user privacy or vehicle control permissions, the voice assistant module can be linked to actively ask the user for confirmation.

[0019] For example, after a user gets into the vehicle and the vehicle starts, and the vehicle completes user identification, the structured rule generated by the proactive service module is: "Started at 16:10 on a weekday, the driver is the owner, the vehicle is started, the current location is near the company, and the calendar or historical travel patterns show that the user may be going to school." At this time, the "children picking up from school" event is triggered. The proactive service module of the vehicle control system application layer reads the corresponding structured rule from the relational database and recalls semantic memories with high confidence related to "picking up children, school, children in the back seat, nursery rhymes, and cooling down".

[0020] As an alternative implementation, target memory matching can also be achieved through vector embedding and similarity calculation. Specifically, when the event trigger command is ambiguous, the application layer's proactive service decision module determines it as a semantic retrieval scenario and sends a semantic retrieval request to the memory retrieval unit. For example, if a user says "I'm not in a good mood today," the proactive service module initiates semantic retrieval for this command, passing the user's emotion tag and the current context to the retrieval unit. Then, the memory retrieval unit converts the event information corresponding to the event trigger command into a semantic vector, and subsequently matches candidate memories that meet the semantic similarity threshold in the vector storage unit as target memories. Specifically, the event text is encoded into a query vector, and an approximate nearest neighbor search is performed in the vector storage unit, returning the Top-K candidate memories with the highest semantic similarity. Then, a relational database is called to supplement structured information, and the memory is reordered based on the current context to select the target memory most suitable for the current scenario. For example, for the query vector "not in a good mood," the relevant memories recalled by vector retrieval are: playing a soothing playlist when feeling down, turning on the ambient lighting warm light mode when stuck in traffic after get off work, and adjusting the seat massage when fatigued during a long drive.

[0021] As an alternative implementation, query matching can also be performed using a knowledge graph. This involves extracting the entity and intent information of the event corresponding to the event triggering command, and then querying the knowledge graph storage unit for candidate memories that match the entity and intent information, which are then used as target memories. Specifically, all named entities are extracted from the event corresponding to the event triggering command. The core intent of the event is identified using an intent classifier, and then the entity set and intent tags are assembled into a graph query statement. Next, a multi-hop traversal is performed in the knowledge graph storage unit starting from the query entity, expanding along relational edges to retrieve associated memory nodes, while simultaneously filtering the node types based on intent tags. The relevance score of each candidate memory is calculated by accumulating path weights, and the candidate memory with the highest score that exceeds a threshold is selected as the target memory.

[0022] Step S20: Execute the vehicle control command corresponding to the target memory.

[0023] In this embodiment, the vehicle control commands are generated after parsing the target memory and are specific control commands for various in-vehicle execution systems. These control commands are typically in-cabin control commands, including corresponding controls for multiple systems such as the vehicle control system, navigation system, multimedia system, and voice system. Each command includes at least one of the following: execution object, parameter value, execution sequence, and priority. For simple control commands with high confidence, the corresponding control can be executed directly, such as song switching or air conditioning temperature adjustment. For control commands involving driving safety, the command is executed in the form of a prompt / notification, such as prompting the user "Do you want to navigate to community A? I will adjust the air conditioning temperature to X for you along the way."

[0024] When executing vehicle control commands, the content of the target memory can be parsed into control commands of the corresponding domain and sent to the corresponding module for execution. That is, the semantic memory description is decomposed into specific control parameters, and these control parameters are marked with execution priority and target execution unit. Then, the corresponding control commands are sent to the target execution unit according to the execution priority.

[0025] Furthermore, when there are multiple target memories, the execution priority of each target memory can be determined based on its confidence level field. Then, based on the execution priority and the corresponding control actions of each target memory, vehicle control commands are generated and finally executed. For example, in a weekday morning rush hour vehicle start-up scenario, after the event is triggered, four target memories are matched simultaneously, including the memory for adjusting the air conditioning to 24°C, the memory for commuting navigation routes, the memory for playing commuting playlists, and the memory for fine-tuning the rearview mirror angle. The central agent first reads the confidence level field of each target memory and sorts them from high to low to determine the execution priority. The high-confidence air conditioning and navigation memories are the first priority and are executed in parallel. The medium-confidence multimedia memories are the second priority and are triggered later. The low-confidence rearview mirror fine-tuning memories are the third priority and require a second verification of the scene matching degree before execution. Then, based on the priority order and the control actions corresponding to each memory, a sequence of vehicle control commands with time stamps is generated and finally issued and executed in batches according to the sequence. This approach anchors execution priority based on confidence level, preventing low-confidence memories from preempting execution resources or interfering with the core user experience, and enabling multiple target memories to work collaboratively rather than running in a chaotic parallel manner.

[0026] It should be noted that executing vehicle control commands corresponding to target memories typically requires a pre-defined trajectory. This means that any vehicle control command corresponding to a memory must not bypass driving safety, child safety, vehicle control boundaries, or regulatory restrictions. Therefore, after parsing the target memory into vehicle control commands, before officially issuing and executing them, they need to undergo mandatory interception verification by a safety verification module and a priority verification module. Specifically, regarding driving safety, when the vehicle is in motion, it will not execute commands that might distract the driver or affect handling stability, such as automatically opening doors or opening windows wide at high speeds due to historical preferences. Regarding child safety, when a child lock is detected or a child seat is occupied, the corresponding door and window control commands are directly intercepted, preventing unlocking or window lowering operations from being triggered by memory. Regarding vehicle control boundaries, all execution parameters are constrained within the physical threshold range calibrated at the vehicle's factory; any parameters exceeding these boundaries in memory will be automatically truncated to the safe upper or lower limit and will not be executed according to their original values. Regarding regulatory restrictions, commands involving lights, horns, and driver assistance, which are subject to road traffic safety regulations, are all subject to the legally permitted usage scenarios; memory commands that do not conform to these scenarios will not be executed. This ensures that memory-based active control always operates within a safe and compliant framework, preventing the introduction of safety risks through memory exploitation.

[0027] For example, if the target memories to be recalled are related to "picking up children, school, children in the back seat, nursery rhymes, and cooling down," the system will prompt on the screen or via voice: "It's usually time to pick up your child from school. Do you want to navigate to XX Elementary School? Upon arrival, do you want to unlock the child locks in the back seats and lower the rear seat temperature?" After the user confirms, the system will execute the corresponding navigation instructions. For safety-related actions such as child locks and window adjustments, confirmation is required upon arrival at the destination, or the actions will be performed while the vehicle is parked.

[0028] This embodiment coordinates a candidate memory database built by at least two sub-agents through a central agent. When an event is triggered, it matches the target memory and executes vehicle control, freeing the vehicle from the limitation of merely storing static preferences and passively waiting for user commands. Based on fused memories continuously accumulated across multiple service domains, it proactively identifies the current scenario and automatically invokes appropriate control strategies, achieving an upgrade in interaction from users issuing commands one by one to the vehicle proactively adapting to user habits. Simultaneously, it enables memories to possess complete semantic units of scenario conditions and behavioral logic, allowing cockpit control behavior to more accurately match the user's actual usage intentions, thus improving the initiative and intelligence level of the smart cockpit.

[0029] Based on the first embodiment described above, in the second embodiment of this application, please refer to... Figure 2 In response to an event triggering command from the vehicle, before retrieving the target memory matching the event triggering command based on multiple pre-stored candidate memories, steps S01 to S04 are further included: Step S01: Obtain historical event data of the vehicle, and based on the event type of the historical event data, route the historical event data to each of the sub-Agent modules.

[0030] In this embodiment, historical event data refers to the complete interaction records generated and accumulated during the vehicle's past operation, including voice interaction logs, navigation trajectories and POI records, multimedia playback and operation logs, vehicle control operation data points, and owner configuration change records. It can be understood that this historical event data is the original source material for the sub-Agent's memory mining, containing metadata such as timestamps, source domains, and associated user identities. Event types are labels used to categorize historical event data according to business domains, including primary categories such as voice interaction, navigation, multimedia playback, vehicle control operation, and owner settings, as well as secondary subcategories within each category. This event type is typically used as the basis for determining the routing and distribution by the central agent.

[0031] In this embodiment, routing and distribution can be performed based on the predefined mapping relationship between event types and sub-Agents. Specifically, historical event data is batch-fetched from the vehicle event log storage module according to time windows. After performing field normalization on each data entry, fields such as event ID, event type, occurrence time, associated seat identity, and original load are uniformly extracted. Missing fields are filled with default values, and the data is anonymized, removing plaintext sensitive information involving user privacy and retaining only semantic tags. Next, the event type field of each standardized event is matched against the mapping table. Once a corresponding entry is matched, the event data is pushed to the target sub-Agent. This ensures that similar events always flow to the corresponding domain sub-Agents, allowing each sub-Agent to receive only data within its domain of expertise, improving data mining efficiency and accuracy.

[0032] Step S02: Obtain the sub-candidate memories output by each sub-Agent module based on historical event data.

[0033] In this embodiment, sub-candidate memories are domain-specific memory entries generated by each sub-Agent within its respective business domain, based on feature extraction and pattern mining of historical event data received via routing. Each sub-Agent module infers from the historical event data based on preset prompts. It is understood that to ensure the sub-Agent module correctly parses the event data and generates structured output that meets business requirements—that is, to obtain sub-candidate memories that meet the needs—an effective prompt strategy must be formulated. In this embodiment, the sub-Agents include a voice interaction memory extraction agent, a navigation record memory mining agent, a multimedia playback record memory mining agent, and a vehicle control point memory mining agent. As an optional implementation, for the voice interaction memory extraction agent, five types of information are defined: 1. Memo, including events / to-dos (including time / location / description). 2. Anniversary, including birthdays / anniversaries (including cycle / date / subject). 3. Address, including home / office / frequently visited locations (with optional latitude and longitude). 4. Preference, including preferences for food / style / communication / notifications, etc. 5. Basic information (profile), including name, gender, birthday, contact information, etc. The corresponding prompts are as follows: #Task: You are an expert in extracting [basic information], [personal preferences], [anniversaries], [schedules], and [frequented addresses], and can accurately extract relevant content from user input.

[0034] #Require Please follow the steps below to perform the extraction task: Step 1: Please determine which category it belongs to.

[0035] Step 2: Then, based on the definition of this category, perform the extraction task to extract the fields that must be extracted for this category.

[0036] #category ##[Basic Information - info] Category ### Required field definitions: -topic: Basic information category, i.e., "base_info" -name: Information type, such as "Education Background", "Work Information", "Personal Information", etc. -value: The specific content of the information, such as "graduate degree", " Limited Liability Company, 28 years old, etc. -content: A textual description of this basic information, such as "employed at..." Limited Liability Company ## [Personal Preference] Category ### Required field definitions: -topic: Category, i.e., "preference" -name: Preference type, such as "music preference", "food preference", "travel preference", "video preference", etc. -value: The specific content of the preference, such as "Cantonese cuisine", "romance movies", "historical sites", etc. -content: A summary of user preferences, such as "likes Cantonese cuisine". ##[Anniversary] Category ### Field definitions must be extracted: -topic: Category, i.e., "anniversary" -name: The name of the anniversary, such as "Wedding Anniversary" -value: The specific date of the anniversary, such as "8 / 12". The text description of the time needs to be converted according to [TIME]. -Notes: Relevant notes, such as "restaurant reservation". -reminder_days: The number of days to remind in advance, such as "1". -content: A summary of the anniversary celebration, requiring specific dates and times, such as "August 12th is our wedding anniversary". ## [Memos or Schedules] Category ### Field definitions must be extracted: -topic: Category, i.e., "schedule" -value: Specific details of the trip, such as "business trip to Beijing". -action_date: The time or period at which the event will be executed, such as "20xx / 9 / 26". The textual description of the time needs to be converted according to [TIME]. -notice_type: The number and type of notifications, with only two options: "only once" or "repeated". -content: A summary of the event and memo content, requiring specific dates and times, such as "Going on a business trip to Beijing next Friday (September 26, 20xx)". ## [Common Addresses] Category ### Field definitions must be extracted: -topic: Category, i.e., "address" -name: The name of the address, such as "Uncle's House" -date: The specific address, such as "No. 25, Jianshe Road, Harmony Community" -content: A summary of address information, such as "My uncle's address is No. 25 Jianshe Road, Hexie Community". The voice interaction memory extraction agent, targeting this prompt, retrieves the voice content from the historical event information as follows: 'I like to listen to singer B's songs while driving.' Output: [{ "topic": "preference" "name": "Music Preference" "value": "Singer B" "content": "I like listening to singer B's songs" }] At this point, each sub-Agent uses the LLM model to parse and construct a sub-candidate memory as follows: { "user_id": " ", "memoryId": " ", "content": "I like listening to singer B's songs", "topic": "preference" "subtopic": "music preference" "value": "Singer B" "createdAt": "20xx-11-07 16:35:30", } Here, user_id is the currently identified user ID, memoryId is a unique memory ID generated using UUID, and createdAt is the creation time. This memory serves as the smallest unit for subsequent memory management and is stored in Time-FIFO.

[0037] It should be noted that the processing method for other sub-Agent modules is the same. They can all generate user-defined memory data based on the specific prompt of the sub-Agent model and the LLM model. The data output by the sub-Agent module is JSON data.

[0038] Step S03: Based on the central Agent module, cross-domain fusion and memory conflict handling are performed on each sub-candidate memory to obtain candidate memories.

[0039] In this embodiment, within the multi-Agent architecture, the memory data extracted by each sub-Agent (voice, navigation, multimedia, vehicle control, settings) exhibits significant heterogeneity in granularity, data structure, and contextual constraints due to their different business domains of focus. Directly storing these isolated memories in the database would lead to memory fragmentation, low retrieval efficiency, and even logical conflicts in cross-domain scenarios. For example, a user might set their voice preferences to prefer quiet, but their multimedia behavior in congested traffic might reveal a preference for heavy metal music. While both memories belong to "preferences," the former lacks contextual limitations, while the latter implicitly includes the condition of "traffic jam," which is not explicitly labeled in the database. When the system retrieves a user's music preferences, it will recall both, resulting in redundant candidate sets, increased sorting computation, and a severe decrease in retrieval efficiency. Furthermore, in cross-domain linkage scenarios, the system cannot determine which preference to prioritize, and might even incorrectly combine "open window + heavy metal" recommendations, contradicting the user's initial "prefer quiet" setting, causing logical conflicts and a poor user experience.

[0040] Therefore, the central agent needs to be considered the cerebral cortex of the all-domain intelligent cockpit. The central agent module performs dimensionality reduction and semantic alignment on the high-dimensional discrete features of each subdomain, constructing a Unified Memory Representation (UMR) architecture. Cross-domain logical reasoning and conflict arbitration are then performed using an LLM (Language Model). Specifically, the central agent module performs dimensionality reduction and alignment on sub-candidate memories based on the unified memory representation architecture, and then performs cross-domain logical reasoning and memory conflict resolution on each sub-candidate memory based on a large language model to obtain the candidate memories.

[0041] Specifically, the execution flow of the central Agent module includes heterogeneous data standardization and global alignment, as well as LLM-based cross-domain collaboration and conflict arbitration. During the alignment process, the central Agent first parses and maps the received outputs from each sub-Agent into a unified UMR structure. For example, navigation's Habit (driving habits / route habits), vehicle control's Dynamic_Pattern (dynamic control mode / driving style mode), and voice's Preference (voice interaction preference / voice control habits) are parsed and mapped into a unified UMR structure. This UMR structure requires all memories to contain four core dimensions: trigger condition (Condition), core intent (Intent), action (Action), and source (Source). Standardized mapping can be performed using lightweight scripts. For example, the voice agent's "Meeting at 9 AM tomorrow" has its Condition mapped to [Time: 20xx / 9 / 19 09:00], and its Action to [Remind me of meeting]. The vehicle control agent's "Temp:<15℃" setting has its Condition mapped to [Temp:<15℃] and its Action to [Turn on driver's seat heating].

[0042] After dimensionality reduction and alignment, the central agent module needs to implement cross-domain collaboration and conflict arbitration based on LLM. A cross-domain logical graph reflection engine is set up within the central agent module. When memories from different sources are simultaneously input into the central agent, the large model not only merges similar items but also identifies synergies or conflicts between cross-domain data based on human psychology and cockpit physics. During the synergy enhancement process, if the navigation agent extracts "going to the gym after work" and the multimedia agent extracts "listening to a workout playlist after work," the central agent will merge the two into a higher-order global memory, namely "workout patterns after get off work," and increase the global confidence of this memory. When handling memory conflicts, the central agent module arbitrates based on preset processing rules, such as dynamic scenarios taking precedence over static settings and multi-source data taking precedence over single-source data. For example, when the explicit setting "I am afraid of the heat" conflicts with the implicit behavior recorded by the vehicle control system as "I must turn on the highest setting of the heater when I get in the car in winter", the central agent uses the rules of "dynamic scenarios taking precedence over static settings" and "multi-source evidence taking precedence over single-source evidence" to arbitrate.

[0043] For example, the prompt for the central agent is as follows: #Role: CenterMemoryFusionNexus, the main memory fusion hub for the full-domain intelligent cockpit ##1. Task Objectives Receive the latest memory slices extracted from multiple sub-agents, including [voice], [navigation], [multimedia], [vehicle control], and [settings]. You need to break down the barriers between business domains, much like the human brain, and process these fragmented memories. Cross-validation, synergistic integration and conflict resolution Ultimately, a high-order global unified memory map is output.

[0044] ##2. Cross-Domain Integration and Arbitration Rules (Core Constraints) - Cross-Domain Synergy Find memories that share the same `Condition` (e.g., both are early morning commutes) or the same `Intent` (e.g., both are for relieving fatigue) across different domains. Package them into a "Macro-ScenarioAction".

[0045] - [Conflict Resolution] : -If explicitly defined static preferences conflict with dynamic patterns extracted from actual behavior, then Dynamic laws with specific environmental constraints As the standard.

[0046] Example: A user sets their system to "not listen to loud music," but the multimedia settings show "listen to heavy metal in traffic jams," and the vehicle control shows "close windows in traffic jams." You must deduce that in this "traffic jam scenario," the user's underlying intention is to "isolate from external noise and vent frustration." This is a special case. cover General settings.

[0047] - High-Level Intent Don't just stop at "the user turned on the air conditioner" or "the user listened to music". You should combine multi-domain actions to infer their ultimate purpose (such as: sleep aid, privacy protection, business preparation).

[0048] ##3. Input Data Format json / / List of UMR format data transmitted by each sub-agent [ {"source":"Voice","type":"STATIC","content":"User settings indicate preference for quiet environments and dislike of noisy environments"}, {"source":"Multimedia","type":"DYNAMIC","condition":"Traffic_Congestion","action":"Play heavy metal music","confidence":0.95}, {"source":"VehicleControl","type":"DYNAMIC","condition":"Speed<15km / h&Traffic_Congestion","action":"Driver's window raised to 100%","confidence":0.90} ] ##4. Output Format Requirements Output the globally merged JSON data: {"fusion_reasoning":"Explains the logical reasoning chain for cross-domain fusion and conflict resolution","global_memories":[{"memory_uid":"Global_M_XXXX","macro_context":"Generalized global triggering scenario (e.g., relieving frustration in congested traffic)","unified_intent":"The final higher-order intent derived from cross-domain inference","cross_domain_actions":{"hvac_and_control":"Actions corresponding to the vehicle control domain","media_and_voice":"Actions in the multimedia and voice domains","nav_and_routing":"Actions in the navigation domain"},"conflict_resolved":"Does a conflict exist? How is it resolved? (Fill null if there is no conflict)","natural_language_desc":"High-quality, semantically rich natural language descriptions used for storage in the vector database (facilitating accurate RAG retrieval later)"}]}.

[0049] In the input sub-candidate memories, the voice agent indicates that the user has a static preference for 'quiet'. Both the multimedia and vehicle control agents captured high-confidence dynamic actions (playing heavy metal, closing windows) in a 'traffic congestion' scenario. At this point, there is a representational conflict between the candidate sub-memories: quiet vs. heavy metal. According to the contextual priority principle, the central agent recognizes dynamic behaviors during congestion as specific strategies to combat external pressure. Closing windows is for physical sound insulation (isolating external noise), while playing heavy metal is for emotional catharsis or white noise masking. Both intentions are unified as 'spatial privacy and emotional regulation in congested environments'. Therefore, these three fragments need to be merged into a cross-domain higher-order memory, i.e., a candidate memory: "global_memories": [ { "memory_uid": "Global_M_CONGESTION_STRESS_01", "macro_context": "Enclosed spaces and emotional release during severe traffic congestion", "unified_intent": "Isolates external noise and alleviates the frustration caused by traffic jams","cross_domain_actions": { "hvac_and_control": "Automatically raises the driver's side and all other vehicle windows to 100%", "media_and_voice": "Cut off soothing music and play heavy metal music with a strong rhythm", "nav_and_routing": null }, "conflict_resolved": "The static preference for 'quiet' is overridden by dynamic, high-pressure scenarios. The system determines that users need extreme physical soundproofing and auditory stimulation to counteract anxiety during congestion." "natural_language_desc": "When a vehicle is in severe traffic congestion, in order to alleviate the user's anxiety and isolate them from outside noise, the user is accustomed to completely closing the windows and abandoning their usual preference for quiet, instead playing high-energy heavy metal music to vent their emotions." } Step S04: Store the candidate memory in the preset storage module according to the memory identifier of the candidate memory, or update the candidate memory that already exists in the preset storage module based on the memory identifier.

[0050] In this embodiment, the memory identifier is a unique identifier for each candidate memory, which can be generated by combining trigger condition semantic hash, behavior content summary, and scene tag. The memory identifier is the core basis for memory deduplication and update determination; memories with the same identifier are considered as the same entry. If the memory identifier does not exist, new storage is performed; if the memory identifier already exists, in-situ update is performed, thereby avoiding memory redundancy caused by duplicate storage.

[0051] Specifically, addition or update operations can be performed through CRUD (Create, Read, Update, Delete) methods. This involves calculating a unique memory identifier for each candidate memory generated through fusion. The identifier is generated by concatenating the semantic hash value of the trigger condition field with the feature summary of the behavioral content. After generation, the system queries the preset storage module to check if the identifier already exists and selects a storage path based on the query result. If the memory identifier does not exist, the central agent writes the complete candidate memory entry into the corresponding level of the preset storage module and simultaneously creates a trigger condition index for subsequent retrieval. If the memory identifier already exists, an incremental update is performed, merging the source evidence chains of the old and new memories, recalculating the weighted confidence level, updating the last occurrence timestamp, and retaining behavioral parameters with higher confidence levels.

[0052] For example, the data flow between the central agent and sub-agents is as follows: Figure 2As shown, the vehicle control system includes a multi-source input data layer, an acquisition and preprocessing layer, a domain sub-Agent layer, a central agent scheduling and fusion center layer, and a retrieval and application layer. In the multi-source input data layer, six types of multi-source input data are acquired, including data for user identification, vehicle owner settings, voice interaction, navigation recording, multimedia playback, and vehicle control data embedding. This multi-source data enters the acquisition and preprocessing layer, where it is aggregated via an event bus and then processed for denoising, time alignment, trajectory slicing, and DSL encoding. Simultaneously, a privacy protection module performs data anonymization, location obfuscation, and local priority processing. The data is then distributed to the corresponding domain sub-Agent layer according to the business domain, including distributing data to the voice memory agent, navigation memory agent, multimedia memory agent, and vehicle control memory agent. Each sub-agent independently extracts local features within its domain, generating an in-domain output with candidate memory items, feature summaries, and confidence indicators, which is then reported to the central agent scheduling and fusion center layer. The central agent first completes task distribution, priority and trigger engine determination, and global context management through task scheduling and fusion center. Then, it fuses and arbitrates conflicts of candidate memories reported by each sub-agent, and finally converts them into standardized memory entries represented by UMR. Next, the unified UMR memory data is written into the Time-FIFO short-term memory area to support real-time context calls. At the same time, it is synchronously written to a relational database (used to store structure fields, rules, indexes, weights, and audit logs) responsible for accurate querying, low-latency reading, and transaction consistency, and a vector database (capable of storing natural language descriptions, embeddings, and semantic tags) responsible for semantic recall, similar memory retrieval, and LLM context enhancement through a dual-track memory manager. The dual-track memory jointly support the upper-layer memory retrieval unit, proactive service decision-making, and downstream applications such as HMI, voice assistant, and recommendation control linkage, thus forming a complete closed-loop data flow path of multi-source collection, sub-agent domain extraction, central agent unified fusion, dual-track storage, and scenario-based applications.

[0053] Furthermore, to aid in understanding the implementation process of this embodiment combined with the first embodiment, let's take the memory mining and proactive service process in a commuting congestion scenario as an example. In the vehicle's historical event data, users typically travel from home to work between 8:00 and 9:00 AM on weekdays, with a stable route. The system recorded eight severe congestion scenarios in the past 30 days, with congestion conditions including an average vehicle speed below 15 km / h and an ETA extension exceeding 15 minutes. In these scenarios, users repeatedly skipped their usual news or popular music, switching to soothing music, podcasts, or audiobooks; simultaneously, they lowered the air conditioning fan speed, turned off loud alerts, or activated seat massage.

[0054] Sub-agents perform local memory mining: the navigation agent identifies the "home-to-work" commute route and congested sections; the multimedia agent, based on a global statistical baseline, detects significant deviations in user-played content during severe traffic congestion; the vehicle control agent extracts contextual memories of "reducing cabin stimulation and alleviating anxiety" from behaviors such as air conditioning fan speed, seat massage, and alert tone settings; and the voice agent supplements the user's expression, "Traffic jams are so annoying, play something relaxing." During the central agent's fusion process, the central agent merges navigation congestion, media deviation, and vehicle control comfort operations into a dynamic pattern under the same triggering condition: If the morning rush hour commute is severely congested, then provide soothing multimedia content, reduce notification interruptions, and suggest comfort settings.

[0055] { "memory_id": "M_COMMUTE_CONGESTION_001", "type": "DYNAMIC_PATTERN", "condition": { "route_type": "Home_to_Work_Commute", "time_window": "Weekday morning rush hour", "traffic_state": "Average speed <15km / h or ETA extension >15 minutes", "passenger_state": "Driver-only priority" }, "action": [ "Prioritize soothing music / podcasts / audiobooks". "It is recommended to enable the low-distraction commuting mode and reduce unnecessary notification sounds." "If the user has a history of frequently using the seat massage, they will be prompted whether to turn on the gentle massage." "Also provide alternative routes or estimated delay information." ], "reasoning": "During heavily congested commutes, users frequently alleviate anxiety and reduce irritation by switching media and adjusting cabin comfort settings." "confidence_score": 0.87, "requires_user_confirm": true } In the proactive service phase, when a vehicle enters its commute route from home to work at 8:20 AM on a weekday, and the navigation indicates severe congestion ahead, the central agent first reads congestion rules from the relational database to determine if the time, route, speed, and ETA conditions are met. Then, it recalls semantic memories such as "congestion relief," "relaxing music," "podcasts," and "massage" from the vector library as context for dialogue generation. It then prompts: "Congestion ahead is expected to cause a 18-minute delay. You often listen to relaxing podcasts during similar congestion and lower the alert volume. Would you like to switch to a low-distraction commuting mode?" This is executed after user confirmation. Furthermore, if a front passenger or rear passenger is present, and their preferences conflict with the driver's congestion preferences, the central agent will partition the system based on seating area and current playback area, prioritizing against automatically switching all in-vehicle media. If the user rejects this proactive suggestion three times consecutively, the system will reduce the service trigger weight of that memory.

[0056] This embodiment uses a central agent to route historical event data by type to various sub-agents. Each sub-agent performs domain-specific mining, and then cross-domain fusion and conflict arbitration form a unified candidate memory, which is then stored hierarchically. This overcomes the fragmentation limitations of single-domain memory mining, ensuring that each candidate memory in the memory bank possesses cross-domain scenario semantics and multi-system linkage capabilities, rather than being an isolated single preference record. Simultaneously, central fusion guarantees semantic consistency and internal conflict-free nature across all domain memories, providing an accurate data foundation for precise target memory matching when subsequent events are triggered.

[0057] Based on the second embodiment described above, please continue to refer to the third embodiment of this application. Figure 2 After the unified memory representation (UMR) is generated on the central agent side, the data can be stored bidirectionally through a dual-track storage manager. The relational database prioritizes the retrieval of deterministic structured memories, while the vector library prioritizes semantically related memories and cross-domain associations. In terms of reading priority, while the relational database provides precise matching, semantic supplementation is performed based on the vector library, and the data is then uniformly sorted and distributed by the central agent. Therefore, the preset storage module is a dual-track storage module, which includes a vector storage unit and a knowledge graph storage unit. Step S04 includes: storing candidate memories in the vector storage unit using vector embedding, and storing candidate memories in the knowledge graph storage unit in the form of a knowledge graph.

[0058] In this embodiment, dual-track storage refers to the simultaneous formation of structured records and semantic vector records from the same fused memory. The relational database handles deterministic, auditable, low-latency, and transactionally manageable memory storage; the vector database handles semantic similarity retrieval, natural language recall, and cross-domain association. The two are linked through a unified memory_id, and a central agent is responsible for writing, updating, deleting, and maintaining consistency. The division of labor between the two is shown in the table below.

[0059] Therefore, in relational storage, macro_context, cross_domain_actions, and configuration parameters are extracted as structured rule engine trigger conditions. This ensures that in deterministic scenarios, the underlying system can directly trigger vehicle control actions with extremely low latency (milliseconds), without waiting for large model generation, such as sudden speed drops or windshield wiper activation. The vector database can be a Vector DB / RAG recall library, which extracts natural_language_desc and unified_intent, and uses an embedding model to transform them into high-dimensional vector storage, thereby giving the cockpit system the ability to perform fuzzy semantic matching.

[0060] Furthermore, after the central agent receives and processes the candidate memories from the sub-agents, it can decide whether to write them into the dual-track storage according to the following rules:

[0061] In the dual-track priority triggering condition and read priority, memory calls are scheduled according to the principle of "deterministic execution priority to structured processing, semantic understanding priority to vector recall", that is, the scheduling process is shown in the table below:

[0062] During the scheduling process, when multiple memories are under the same conditions and both databases can be matched, the Agent will make a decision according to the following priority:

[0063] This embodiment utilizes relational data to achieve millisecond-level low-latency vehicle control triggering, while using vectorized data to support large models for dual-modal invocation of fuzzy semantic retrieval and anthropomorphic proactive services.

[0064] Based on any of the above embodiments, in Embodiment 4 of this application, the vehicle control system further includes a vehicle setting alignment module, wherein the owner settings in the smart cockpit are characterized by explicitness, strong intent, and high priority. This type of data is discretely distributed across various functional components and UI interfaces of the cockpit system; for example, "driver's seat memory position," "default system volume," "default ambient light color," and "preferred air conditioning temperature" are assigned to the central control screen menu, mobile app, etc. Unlike the aforementioned sub-agents that rely on large model inference, analysis, and mining of dynamic implicit habits, the owner settings are static preferences directly and explicitly expressed by the user.

[0065] Therefore, for vehicle settings for car owners, there is no need to introduce complex agent analysis or large model inference. It is only necessary to convert the scattered and unstructured configuration parameter dictionary in the underlying vehicle control system, such as AC_Temp=22, Ambient_Color=Blue, into memory fragments with natural language descriptions and uniform format, so that the subsequent central agent can seamlessly integrate and resolve conflicts with the implicit memories mined by various sub-agents.

[0066] Therefore, before step S03, the following steps are also included: Step S05: When the vehicle setting alignment module detects a state change event in the vehicle's cockpit configuration center, it maps the vehicle setting fields to memory fragments of a unified theme and type. Step S06: Input the memory fragment as a sub-candidate memory to the central Agent module.

[0067] In this embodiment, the system triggers the alignment module by listening to the unified State ChangeEvent from the cockpit configuration center. When a user setting change is received, the corresponding vehicle preference setting information is obtained, i.e., discrete events from the underlying configuration system are acquired. Then, three steps are executed: confidence setting, multi-source field mapping, and text description generation. Since the owner's settings represent the user's highest subjective intention, the confidence score for this type of memory can be directly fixed at 1.0, providing a baseline priority for subsequent conflict resolution. In multi-source field mapping, the dictionary fields of different functional domains at the underlying level, i.e., vehicle setting fields, are uniformly mapped to the topic and type in the global memory system. Finally, through text description generation, using a preset rule-based template, the parameters are automatically translated into natural language memory fragments, so that these fragments can directly participate in the vectorization and retrieval of the central agent.

[0068] For example, the input fragment is { "event_type": "USER_SETTING_UPDATE", "user_id": "UID_987654321", "module": "HVAC", "parameter": "default_temp", "value": 23.5, "timestamp": "2023-11-08T10:00:00Z" } The aligned output segment is: [ { "memory_id": "M_SETTING_HVAC_001", "user_id": "UID_987654321", "type": "STATIC_PREFERENCE", "topic": "preference", "subtopic": "Default air conditioning temperature", "condition": null, "value": "23.5℃", "confidence_score": 1.0, "content": "The user has set the default cabin air conditioning temperature to 23.5℃", "createdAt": "20xx-11-08 10:00:00" }, { "memory_id": "M_SETTING_LIGHT_002", "user_id": "UID_987654321", "type": "STATIC_PREFERENCE", "topic": "preference", "subtopic": "Default ambient light color", "condition": null, "value": "Aurora Purple", "confidence_score": 1.0, "content": "The user has set the default ambient lighting color in the cockpit to Aurora Purple", "createdAt": "20xx-11-08 10:05:12" }, { "memory_id": "M_SETTING_SEAT_003", "user_id": "UID_987654321", "type": "STATIC_PREFERENCE", "topic": "preference", "subtopic": "Seat position settings", "condition": null, "value": "position 1", "confidence_score": 1.0, "content": "The user has saved the driver's seat position as setting 1", "createdAt": "20xx-11-08 10:10:30" } ] In this embodiment, the vehicle configuration alignment module transforms scattered hardware configuration parameters into semantically and contextually meaningful memory bases. This data, along with the memories extracted by other sub-agents, is then stored in a vector library and a structured database.

[0069] Based on any of the above embodiments, in Embodiment 5 of this application, the memory bank can be updated based on the latest vehicle data after the vehicle is woken up or a control command corresponding to a target memory is completed, or the memory can be updated based on a preset period. Therefore, before step S01, when the vehicle's memory update process is triggered, the vehicle control system's identification module can be woken up, then the identification module reads and loads the memory configuration information corresponding to the current user, and finally the central Agent module and each sub-Agent module are woken up, and the processing action of step S01 is executed.

[0070] In this embodiment, the memory update process can be triggered after the vehicle starts, or it can be triggered after the vehicle completes a task, such as completing an intelligent navigation recommendation. Taking vehicle startup as an example, vehicle startup requires waking up the user identification module and identifying user information based on the user identification module. Then, basic memory loading, sub-Agent monitoring process startup, and available memory cache preparation are performed, so that the cabin enters a personalized service state before the user perceives a significant wait.

[0071] Specifically, the cold start sequence is triggered by any of the following events: vehicle power-on, unlocking, driver's side door opening, or vehicle transitioning from OFF / ACC to ON or READY state. During the cold start interaction, when the vehicle powers on or the driver's side door opens at time T0 and the cockpit domain controller generates a Power_ON event, the central agent enters a pre-start state. If the power supply is unstable at this time, only low-power listening is activated, and deep memory extraction is not triggered. Then, within T0+0.5s, the user recognition module is activated, performing facial feature extraction based on the DMS camera and voiceprint feature extraction based on the microphone array. The similarity of the parallel outputs of the two is used for judgment. If the face and voiceprint match and Score≥T_id, the user's user_id is confirmed; if there is a conflict or low confidence, a temporary visitor mode is entered and a second confirmation is prompted. Then, within T0+1s, the owner setting memory alignment module is activated, reading settings such as seat, rearview mirror, air conditioning, ambient lighting, and account configuration. If the user_id is not confirmed, only the vehicle's default configuration is loaded; if reading fails, the previous local snapshot can be used. Next, static preference candidate memories are output and provided to the central Agent as a high-priority memory baseline.

[0072] Then, within T0+2 seconds, the central agent scheduler is started, reading the scheduling policy table based on the central agent. If the network is unavailable at this time, only the edge rules and local models are enabled. Next, within T0+3 seconds, the listening process of each sub-agent is started, with sub-agents such as voice, navigation, multimedia, vehicle control, and settings subscribing to their respective event topics. If a sub-agent fails to start, and it does not affect other agents, the central agent marks that domain as degraded. Subsequently, each sub-agent enters the listening state, waiting for event triggering or periodic triggering. Next, within T0+5 seconds, the local cache loading of historical memory is completed. The central agent reads high-priority deterministic memory from the relational database and prefetches Top-K relevant semantic memory summaries from the vector library. If cache loading takes more than 5 seconds, deterministic configurations such as seat / air conditioning are completed first, and semantic memory is loaded asynchronously. A SessionMemoryCache is formed for proactive services and dialogue calls. Finally, within T0+8 seconds, an initial personalized service plan is formed. The central agent generates low-risk service suggestions based on the current time, weather, occupants, destination prediction, and historical memory. Actions involving vehicle control, route changes, and child locks require secondary confirmation, while display / recommendation actions can be prompted directly. Finally, a list of proactive service candidates is output, such as "Navigate to company / school?" or "Restore air conditioning preference?"

[0073] It's important to note that to better serve all vehicle users, data segmentation by user is necessary. After identifying the user in each seat using facial and voiceprint recognition, a data index can be built using a unique user_id. Therefore, during user registration, upon first use, users must input their facial and voiceprint data to create a nickname and a unique user account. The facial and voiceprint feature vectors are uniquely bound to each other to generate a User_ID. Simultaneously, an initial profile is constructed, recording the initial seat position, air conditioning temperature, navigation preferences, and other default settings, triggering a memory write request. The initial user profile, including seat position, air conditioning temperature, navigation preferences, and media preferences, is collected as initial memory and written during first use. During the recognition phase, the DMS camera extracts facial features, and the microphone array extracts voiceprints; both output similarity scores in parallel. This calculates the similarity score between the facial features and the features of each user in the database. Calculate the similarity score between voiceprint features and user features in the database. Finally, the result is expressed using a weighted summation or logistic regression method:

[0074] When the score exceeds the threshold T, the user_id is confirmed; when a conflict occurs, such as face=A, voiceprint=B, or low confidence, a secondary confirmation is triggered, such as voice prompt / phone confirmation / manual selection.

[0075] Based on any of the above embodiments, in Embodiment Six of this application, when storing data, the vehicle control system prioritizes storing original events, identity templates, sensitive locations, and short-term contexts locally on the vehicle. The cloud only synchronizes long-term memory summaries that have been de-identified, compressed, and authorized by the user. Specifically, the relational database can maintain a low-latency master database on the vehicle, while the cloud maintains user-authorized backups or cross-vehicle synchronized copies; the vector database can be divided into a local lightweight vector index and a cloud-enhanced vector index. Specifically, to protect user privacy, the local and cloud storage logic is shown in the table below:

[0076] Furthermore, the vehicle control system also includes a memory management mechanism for viewing, editing, and deleting. Users can view the system's saved memories via the vehicle's screen or voice commands. For example, a user might say, "What commuting habits of mine have you remembered?", "Delete memories related to my child's school," or "Don't recommend music based on my preferences anymore." The central agent then parses the natural language deletion or modification request into structured operations, simultaneously applying them to the relational database, vector database, local cache, and cloud-synchronized copy. The deletion mechanism employs a cascading deletion strategy. When a user deletes a memory corresponding to a memory_id, the central agent first writes a tombstone deletion record in the relational database, immediately making the memory unsearchable and inaccessible. Subsequently, it deletes or invalidates the embedding in the vector database, the cached copy in the Session Memory Cache, and the cloud-synchronized copy. For deleted memories, the vector retrieval phase must pass relational database status verification to prevent the problem of "the vector database still recalling deleted content."

[0077] Furthermore, to ensure data security, each memory entry during access control includes fields such as owner_user_id, seat_scope, vehicle_scope, privacy_level, and allowed_agents. Sub-agents and downstream services can only read the corresponding memory within their authorized scope. Meanwhile, preferences generated by the front passenger or rear passenger are by default bound to their seat_id or guest_id and are not automatically written to the owner's long-term memory; memories related to children require owner authorization. All memory creation, updates, deletions, cloud synchronization, and proactive calls are written to the audit log, with fields including operator, timestamp, operation, memory_id, reason, and device_id. Encrypted transmission is used between the vehicle, cloud, and services; local databases and vector indexes can use file-level or field-level encryption; keys are stored in secure hardware or the system key management module. When the privacy_level is higher than the current authorization level, the central agent must not send the memory to the cloud-based large model, nor use it for proactive services; it can only perform low-risk processing locally or request user authorization.

[0078] Secondly, Figure 3 A schematic diagram of an embodiment of the vehicle control device of the present invention is shown. Figure 3 As shown, the device 300 includes: an acquisition module 310 and an execution module 320.

[0079] The acquisition module 310 is used to respond to the event triggering command of the vehicle and acquire the target memory that matches the event triggering command based on a plurality of pre-stored candidate memories. The central agent constructs and stores the candidate memory based on the sub-candidate memory generated by each sub-Agent module. The execution module 320 is used to execute the vehicle control commands corresponding to the target memory.

[0080] In an alternative embodiment, the device 300 further includes a memory mining module 330, which is used to acquire historical event data of the vehicle and route the historical event data to each of the sub-Agent modules based on the event type of the historical event data. Obtain the sub-candidate memories output by each of the sub-Agent modules based on the historical event data; Based on the central Agent module, cross-domain fusion and memory conflict processing are performed on each of the sub-candidate memories to obtain the candidate memories; Based on the memory identifier of the candidate memory, the candidate memory is stored in a preset storage module, or the candidate memory already existing in the preset storage module is updated based on the memory identifier; In an alternative approach, the memory mining module 330 is also configured to control the central agent module to perform dimensionality reduction and alignment processing on the sub-candidate memories based on a unified memory representation architecture; Based on the large language model, cross-domain logical reasoning and memory conflict handling are performed on each of the sub-candidate memories to obtain the candidate memories.

[0081] In an alternative embodiment, the mining module 330 is further configured to store the candidate memories in the vector storage unit using a vector embedding method; and The candidate memories are stored in the knowledge graph storage unit in the form of a knowledge graph.

[0082] In an alternative approach, the mining module 330 is further configured to map the vehicle setting fields to memory fragments of a uniform theme and type when the vehicle setting alignment module detects a state change event of the vehicle's cockpit configuration center. The memory fragment is input into the central Agent module as the sub-candidate memory.

[0083] In an alternative approach, the mining module 330 is also used to wake up the identification module of the vehicle control system when the vehicle's memory update process is triggered; The recognition module reads and loads the memory configuration information corresponding to the current user. The central Agent module and each of the sub-Agent modules are awakened, and the steps of obtaining the historical event data of the vehicle and routing the historical event data to each of the sub-Agent modules based on the event type of the historical event data are executed.

[0084] In an optional manner, the acquisition module 310 is further configured to convert the event information corresponding to the event triggering instruction into a semantic vector, and match the candidate memory that meets the semantic similarity threshold in the vector storage unit as the target memory; and / or, Extract the entity and intent information of the event corresponding to the event triggering instruction, and query the knowledge graph storage unit for the candidate memory that matches the entity and intent information, and use it as the target memory.

[0085] In an alternative embodiment, the execution module is further configured to determine the execution priority of each target memory based on the confidence field in each target memory; The vehicle control command is generated based on the execution priority and the control action corresponding to each target memory. Execute the vehicle control command.

[0086] Thirdly, Figure 4 The diagram shows a structural schematic of an embodiment of the vehicle of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the vehicle.

[0087] like Figure 4 As shown, the vehicle may include: a processor processor 402. Communication Interface CommunicationsInterface 404, Memory memory 406, and communication bus 408.

[0088] The processor 402, communication interface 404, and memory 406 communicate with each other via communication bus 408. Communication interface 404 is used to communicate with other network elements such as clients or other servers. The processor 402 executes program 410, specifically performing the relevant steps described above in the vehicle control method embodiment.

[0089] Specifically, program 410 may include program code, which includes computer-executable instructions.

[0090] Processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The vehicle may include one or more processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0091] Memory 406 is used to store program 410. Memory 406 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0092] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing at least one executable instruction that, when executed on a vehicle / vehicle control device, causes the vehicle / vehicle control device to perform the vehicle control method in any of the above method embodiments.

[0093] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Furthermore, the embodiments of this invention are not directed to any particular programming language.

[0094] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. Similarly, for the sake of brevity and to aid in understanding one or more aspects of the invention, in the description of exemplary embodiments of the invention above, various features of the embodiments are sometimes grouped together in a single embodiment, figure, or description thereof. The claims, which follow the detailed description, are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0095] Those skilled in the art will understand that the modules in the device of the embodiment can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiment can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components, except that at least some of such features and / or processes or units are mutually exclusive.

[0096] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A vehicle control method, characterized in that, Applied to a vehicle control system, the vehicle control system including a central agent module and at least two sub-agent modules, the method includes: In response to an event trigger command from a vehicle, a target memory matching the event trigger command is obtained based on multiple pre-stored candidate memories, wherein the central agent constructs and stores the candidate memories based on the sub-candidate memories generated by each of the sub-Agent modules; Execute the vehicle control command corresponding to the target memory.

2. The method as described in claim 1, characterized in that, Before retrieving the target memory matching the event trigger command based on multiple pre-stored candidate memories in response to the vehicle's event trigger command, the method further includes: Obtain the historical event data of the vehicle, and based on the event type of the historical event data, route the historical event data to each of the sub-Agent modules; Obtain the sub-candidate memories output by each of the sub-Agent modules based on the historical event data; Based on the central Agent module, cross-domain fusion and memory conflict processing are performed on each of the sub-candidate memories to obtain the candidate memories; Based on the memory identifier of the candidate memory, the candidate memory is stored in a preset storage module, or the candidate memory already existing in the preset storage module is updated based on the memory identifier.

3. The method as described in claim 2, characterized in that, The process of performing cross-domain fusion and memory conflict processing on each of the sub-candidate memories based on the central Agent module to obtain the candidate memories includes: The central agent module controls the dimensionality reduction and alignment of the sub-candidate memories based on a unified memory representation architecture. Based on the large language model, cross-domain logical reasoning and memory conflict handling are performed on each of the sub-candidate memories to obtain the candidate memories.

4. The method as described in claim 2, characterized in that, The preset storage module is a dual-track storage module, which includes a vector storage unit and a knowledge graph storage unit. The step of storing the candidate memory into the preset storage module according to the memory identifier of the candidate memory includes: The candidate memories are stored in the vector storage unit using vector embedding; and The candidate memories are stored in the knowledge graph storage unit in the form of a knowledge graph.

5. The method as described in claim 2, characterized in that, The vehicle control system further includes a vehicle setting alignment module. Before the process of performing cross-domain fusion and memory conflict processing on each of the sub-candidate memories based on the central Agent module to obtain the candidate memories, the system further includes: When the vehicle setting alignment module detects a state change event in the vehicle's cockpit configuration center, it maps the vehicle setting fields to memory fragments of a unified theme and type. The memory fragment is input into the central Agent module as the sub-candidate memory.

6. The method as described in claim 2, characterized in that, Before acquiring the historical event data of the vehicle and routing the historical event data to each of the sub-Agent modules based on the event type of the historical event data, the method further includes: When the vehicle's memory update process is triggered, the vehicle control system's identification module is activated; The recognition module reads and loads the memory configuration information corresponding to the current user. The central Agent module and each of the sub-Agent modules are awakened, and the steps of obtaining the historical event data of the vehicle and routing the historical event data to each of the sub-Agent modules based on the event type of the historical event data are executed.

7. The method as described in claim 1, characterized in that, The response to a vehicle event trigger command, based on multiple pre-stored candidate memories, involves retrieving a target memory that matches the event trigger command, including: The event information corresponding to the event triggering instruction is converted into a semantic vector, and candidate memories that meet the semantic similarity threshold are matched in the vector storage unit as the target memory; and / or, Extract the entity and intent information of the event corresponding to the event triggering instruction, and query the knowledge graph storage unit for the candidate memory that matches the entity and intent information, and use it as the target memory.

8. The method according to any one of claims 1 to 7, characterized in that, When there are multiple target memories, the step of executing the vehicle control command corresponding to the target memory includes: The execution priority of each target memory is determined based on the confidence field in each target memory. The vehicle control command is generated based on the execution priority and the control action corresponding to each target memory. Execute the vehicle control command.

9. A vehicle control device, characterized in that, The device includes: The acquisition module is used to respond to the event triggering command of the vehicle, and acquire the target memory that matches the event triggering command based on a plurality of pre-stored candidate memories, wherein the central agent constructs and stores the candidate memory according to the sub-candidate memory generated by each of the sub-Agent modules; The execution module is used to execute the vehicle control commands corresponding to the target memory.

10. A vehicle control system, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of the vehicle control method as described in any one of claims 1-8.

Images