Vehicle end intelligent agent system, vehicle, control method, device and readable storage medium

Abstract

A vehicle end intelligent agent system, vehicle, control method, device and readable storage medium, the system includes a host domain and an intelligent agent virtual running space, the host domain includes an intelligent agent interface module, and the intelligent agent virtual running space includes a safe intelligent agent routing module and an intelligent agent runtime module;The intelligent agent interface module receives multi-source input information, generates an intelligent agent context object including a user identity and an intelligent agent identity based on the multi-source input information;The safe intelligent agent routing module routes the intelligent agent context object to the target container corresponding to the user identity and the intelligent agent identity in the intelligent agent virtual running space, and the target container has target objects such as memory data, working space and intelligent agent characteristics corresponding thereto;The intelligent agent runtime module executes a target task in the target container based on the target object and the intelligent agent context object to solve the problems of input crosstalk, memory serial number, working space pollution and poor security in a multi-identity scenario.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle control technology, specifically to a vehicle-side intelligent agent system, a vehicle, a control method, an equipment, and a readable storage medium. Background Technology

[0002] With the development of vehicle intelligence and large-scale model capabilities, vehicles are no longer just physical carriers equipped with fixed voice assistants, but are gradually becoming intelligent agent nodes that combine "information + physical carrier". Among them, vehicle agents need to perceive in-vehicle users, vehicle status, cabin environment and external cloud services, and be able to call local vehicle capabilities, application capabilities and external agent capabilities.

[0003] In related technologies, traditional vehicle-side voice assistants or single-agent solutions typically focus on fixed functions, single session memory, or a single account, mainly handling tasks such as voice commands, navigation, music, and vehicle control. These solutions are suitable for simple human-vehicle interactions. In addition, PC (Personal Computer) agents, mobile agents, and cloud agents operate in a 1:1 personal device or 1:N cloud multi-tenant manner, relying on accounts, passwords, facial recognition, fingerprints, or application programming interface keys for identity and session isolation. However, the vehicle side is a typical N:1 shared space, where the same vehicle may be used by multiple users at different times or concurrently, and the agent may also proactively initiate tasks based on vehicle events or cabin status. Furthermore, ordinary application sandboxes or ordinary container sandboxes can provide a certain degree of application isolation or file isolation, but their operating environment is usually still located on top of the host operating system or a shared kernel.

[0004] It is evident that traditional solutions have weak input identity boundaries, which can easily lead to inaccurate identity recognition, request crosstalk, and session mismatch. Furthermore, the fact that all users share the same memory, agent characteristics, or long-term preferences can result in memory cross-identity, privacy memory leakage, and personality / preference contamination between different identities such as driver, passenger, child, and visitor. In addition, files, contexts, tool call results, and temporary states generated during agent execution are not isolated by identity or agent, and may be read or reused by other agents, causing task result contamination and privacy leakage. Moreover, traditional solutions lack sufficient host-side isolation, so agent memories, rules, tool call results, and local knowledge bases may be tampered with, read, or indirectly accessed by other agents. Summary of the Invention

[0005] This application provides a vehicle-side intelligent agent system, vehicle, control method, device, and readable storage medium, which can solve the technical problems of input crosstalk, memory serial number, workspace pollution, and poor security in multi-identity scenarios in the prior art.

[0006] In a first aspect, embodiments of this application provide a vehicle-side intelligent agent system, the vehicle-side intelligent agent system comprising: a host domain and an intelligent agent virtual runtime space, the host domain including an intelligent agent interface module, and the intelligent agent virtual runtime space including a secure intelligent agent routing module and an intelligent agent runtime module; The agent interface module is used to receive multi-source input information and generate an agent context object based on the multi-source input information. The agent context object includes a user identity identifier and an agent identifier. The secure agent routing module is used to route the agent context object to the target container in the agent virtual runtime space that corresponds to the user identity and agent identity. The target container has a corresponding target object, which includes memory data, workspace and agent characteristics. The agent runtime module is used to execute target tasks within the target container based on the target object and the agent context object.

[0007] In conjunction with the first aspect, in one implementation, the secure intelligent agent routing module is specifically used for: Query the mapping relationship between currently created containers in the agent's virtual runtime space and the user identity identifier and agent identifier; If a matching target container exists, the agent context object is routed to the target container; If no matching target container exists, a new container is created within the agent's virtual runtime space. The user identity identifier and agent identifier are bound to the new container. The memory data and workspace corresponding to the user identity identifier and the agent characteristics corresponding to the agent identifier are bound to the new container to form a target container. The agent context object is then routed to the target container.

[0008] In conjunction with the first aspect, in one implementation, the agent context object further includes vehicle status, risk level, and permission policy; the agent virtual operating space further includes an action permission verification module, which is used for: Before calling the vehicle service interface and / or external intelligent agents, perform action authorization verification based on user identity, intelligent agent identity, vehicle status, risk level and permission policy; If the action authorization verification passes, the action of calling the vehicle service interface and / or an external intelligent agent will be executed; If the action authorization verification fails, actions that call the vehicle service interface and / or external intelligent agents are prohibited.

[0009] In conjunction with the first aspect, in one implementation, the permission policy includes a restriction policy corresponding to a restricted object, the restricted object including strangers, children, designated drivers, car rental personnel, and maintenance personnel, the restriction policy including creating a restricted agent or restricted container, and using a temporary workspace, restricted agent characteristics, and a restricted memory policy to clean up or archive temporary data after the interaction ends.

[0010] In conjunction with the first aspect, in one embodiment, the agent virtual operating space further includes an agent gateway, which is used to map external agent requests to local agent context objects and establish constraint relationships between external agent requests and containers, memory data, workspaces, agent characteristics, and permission policies.

[0011] In conjunction with the first aspect, in one implementation, the host domain and the agent's virtual operating space interact with each other via an isolated communication channel, which is implemented based on a virtual socket protocol or restricted virtual input / output.

[0012] Secondly, embodiments of this application provide a vehicle including the aforementioned vehicle-side intelligent agent system.

[0013] Thirdly, embodiments of this application provide a vehicle-side intelligent agent control method, applied to the aforementioned vehicle-side intelligent agent system, the vehicle-side intelligent agent control method comprising: Receive multi-source input information and generate an agent context object based on the multi-source input information. The agent context object includes a user identity identifier and an agent identifier. The agent context object is routed to the target container in the agent's virtual runtime space that corresponds to the user identity and agent identity. The target container has a corresponding target object, which includes memory data, workspace, and agent characteristics. The target task is executed within the target container based on the target object and the agent context object.

[0014] Fourthly, embodiments of this application provide a vehicle-side intelligent agent control device, which includes a processor, a memory, and a vehicle-side intelligent agent control program stored in the memory and executable by the processor. When the vehicle-side intelligent agent control program is executed by the processor, it implements the steps of the aforementioned vehicle-side intelligent agent control method.

[0015] Fifthly, embodiments of this application provide a computer-readable storage medium storing a vehicle-side intelligent agent control program, wherein when the vehicle-side intelligent agent control program is executed by a processor, it implements the steps of the aforementioned vehicle-side intelligent agent control method.

[0016] The beneficial effects of the technical solutions provided in this application include: By constructing a host domain and an agent virtual runtime space in the vehicle-side agent system, the agent's operating environment resides in the agent virtual runtime space, enhancing isolation and preventing data from being tampered with, read, or indirectly accessed by other agents. The agent interface module in the host domain receives multi-source input information and generates an agent context object, including a user identity identifier and an agent identifier, based on this information. This provides a unified context for subsequent routing and container selection. The secure agent routing module routes the agent context object to the target container in the agent virtual runtime space corresponding to the user identity identifier and agent identifier. The target container has a corresponding target object, which includes memory... Data, workspace, and agent characteristics—that is, each container is bound to a corresponding user identity, agent identity, memory data, workspace, and agent characteristics—to avoid problems such as input crosstalk, memory serial number crosstalk, execution crosstalk, privacy memory leakage, and workspace pollution caused by multiple users and multiple agents using the same or shared time in an N:1 scenario on the vehicle side. The agent runtime module executes the target task based on the target object and agent context object within the target container. That is, the host is isolated by the agent virtual runtime space, and different agents are isolated by the container. This allows container anomalies to be prioritized and restricted within the agent virtual runtime space, thereby achieving two-way protection between the host and agent execution environment, and between different agents, thus effectively improving security. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the overall architecture of an embodiment of the vehicle-side intelligent agent system of this application; Figure 2 This is a schematic diagram illustrating the usage scenarios and permissions of the vehicle Agent involved in the embodiments of this application; Figure 3 This is a flowchart illustrating an embodiment of the vehicle-side intelligent agent control method of this application; Figure 4 This is a schematic diagram of the hardware structure of the vehicle-side intelligent agent control device involved in the embodiments of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0019] First, some of the technical terms used in this application will be explained to help those skilled in the art understand this application.

[0020] Agent: Intelligent agent. It should be noted that the specific architecture and working principle of the intelligent agent in this embodiment are common knowledge in the field, and will not be described in detail here for the sake of simplicity.

[0021] Agent Group: Intelligent Agent Group.

[0022] Memory: Persistent data such as user memory, vehicle context, session summary, long-term preferences, trip preferences, and local knowledge base.

[0023] Soul: Agent characteristics, including the agent's long-term preferences (such as thinking, drawing, speaking), permissions, and memory strategies.

[0024] Agent Runtime: The agent runtime module is the core of the vehicle-side agent execution, responsible for model inference, task planning, standardized skill module scheduling, Memory / Soul strategy and container selection.

[0025] Workspace: The space containing files, context, tool call results, and temporary state during agent tasks.

[0026] Agent Interface: The intelligent agent interface module.

[0027] Lightweight Container: A lightweight, isolated execution environment launched by agent or identity. In subsequent embodiments, the container may preferably be this lightweight container.

[0028] SE-Agent Router: Secure Intelligent Agent Routing Module.

[0029] A2A: Agent-to-Agent protocol, used for collaboration between vehicle-side agents and external cloud agents, mobile agents, and PC agents.

[0030] A2A Gateway: Intelligent Agent Gateway.

[0031] Cloud Agent: A smart agent used in cloud computing.

[0032] Agent VM Sandbox: A virtual runtime space for intelligent agents, used to run the vehicle-side Agent Runtime and a virtual machine isolation environment with multiple containers to achieve isolation between the Host Domain and the Agent execution environment.

[0033] Action Permission Verify: Action permission verification module.

[0034] KMS / HSM: Key management service and hardware security module for protecting encryption keys for memory, workspace, soul, or sensitive data.

[0035] Memory / Workspace Manager.

[0036] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0037] In a first aspect, embodiments of this application provide a vehicle-side intelligent agent system.

[0038] In one embodiment, reference is made to Figure 1 , Figure 1 This is a schematic diagram of the overall architecture of an embodiment of the vehicle-side intelligent agent system of this application. Figure 1 As shown, the vehicle-side intelligent agent system includes: a host domain and an intelligent agent virtual runtime space. The host domain includes an intelligent agent interface module, and the intelligent agent virtual runtime space includes a secure intelligent agent routing module and an intelligent agent runtime module. The agent interface module is used to receive multi-source input information and generate an agent context object based on the multi-source input information. The agent context object includes a user identity identifier and an agent identifier. The secure agent routing module is used to route the agent context object to the target container in the agent virtual runtime space that corresponds to the user identity and agent identity. The target container has a corresponding target object, which includes memory data, workspace and agent characteristics. The agent runtime module is used to execute target tasks within the target container based on the target object and the agent context object.

[0039] Exemplary, see Figure 1As shown, this embodiment will construct a multi-Agent isolated execution architecture on the vehicle-side SoC (System on Chip) or in-vehicle computing platform, consisting of a Host Domain, an Agent Virtual Runtime Space (i.e., Agent VM Sandbox), an External Agent Cloud, a Trusted Execution Environment / Secure World (TEE / Secure World), and underlying Hypervisor / OS, memory (i.e., host memory, guest shared memory, and guest private memory), and hardware collaboration. Among them, the Host Domain includes an Agent Interface module, which uniformly accepts multi-source input information such as voiceprint recognition, seat information, account, vehicle events, application (App) requests, external Agent collaboration requests (i.e., external A2A requests), and special Agent fields (such as agent_id), and forms different Agent Context objects.

[0040] It should be noted that AgentContext includes, but is not limited to, user_id (user identifier), agent_id (agent identifier), mode (e.g., intelligent driving mode, sleep mode, and sentry mode), preset risk level (which can be preset in advance according to actual application scenarios and user types, such as low risk for entertainment scenarios and high risk for scenarios affecting driving safety), permission profile (e.g., full access for the driver and restricted access for children), workspace_id (workspace identifier), input source, and vehicle state (e.g., acceleration and parking status). AgentContext can be represented in the form of structured data objects, the specific form of which is determined according to actual needs and is not limited here. For example, a predefined data structure can be used, with each field encapsulated according to a unified data type and naming convention for easy transmission between Agent Interface, Agent Runtime, and Container. Simple states in AgentContext can be represented using strings, numbers, or enumeration values, while information containing multiple attributes, such as vehicle state, can be represented using nested objects. Fields can also be extended based on task timestamps, session identifiers, device identifiers, and policy versions.

[0041] Furthermore, this embodiment will deploy Agent Runtime, SE-AgentRouter, multiple Containers (such as multiple Lightweight Containers), Action Permission Verify, Memory / Workspace Manager, and A2A Gateway / Cloud Agent within the Agent VM Sandbox. The SE-Agent Router makes container selection and resource policy decisions based on the AgentContext. Each Container is bound to a specific Agent identity or Agent Group and corresponds to independent Memory, Workspace, Soul, and permission policies. In other words, this embodiment isolates different Agents through Containers, specifically within the Agent VM Sandbox by user identity, Agent identity, and Agent... Group or working mode launches multiple containers, allowing different agents to run in independent containers to solve problems such as memory serial numbers and execution crosstalk caused by multiple users and agents using the same or time-sharing mode simultaneously in the N:1 scenario on the vehicle. On this basis, namespaces can be used to isolate processes, networks and mount spaces, cgroups can be used to limit resources such as central processing unit and memory, seccomp can be used to limit executable system calls, and an independent root file system rootfs can be used to isolate the file system, thereby preventing data, processes and resources from affecting each other between different users, agents or working modes.

[0042] Understandably, under the aforementioned Memory / Workspace / Soul binding mechanism, each Container in this embodiment is bound to one or more Soul, Memory, and Workspace. Therefore, read and write operations of Soul, Memory, and Workspace can be uniformly managed by the Memory / Workspace Manager. Once cross-identity, cross-Agent, or cross-Container access and sharing occur, authorization is required to prevent Soul serial number, Memory leakage, and Workspace contamination.

[0043] Based on this, the secure intelligent agent routing module can filter out the corresponding target container from the containers deployed on the Agent VM Sandbox using the user_id and agent_id in the AgentContext, and route the AgentContext to the target container. This allows the Agent Runtime to execute the target task within the target container based on the AgentContext and the Memory / Workspace / Soul bound to the target container. The target task includes, but is not limited to, AI computation, task planning, and Skill scheduling. After the task is completed, only the authorization result is returned. If the authorization result needs to be persisted, the result, summary, or status can be written back to the corresponding Memory / Workspace, but not to the Memory / Workspace of other identities or Agents. The Host / Agent Interface feeds back the result to the original input source through voice, screen, App, or vehicle status, maintaining consistency between the input source and the output result.

[0044] It is worth noting that this embodiment can also implement a client-side privacy data encryption protection mechanism through a key management server (KMSServer in TEE) in the Trusted Execution Environment. This protects Memory, Workspace, Soul, local knowledge base, and cross-device synchronized data by encrypting and protecting them with DEK (Data Encryption Key) / KEK (Key Encryption Key) managed by TEE-KMS / HSM (i.e., Certificate Management / Key Manager), preventing direct reading by the host, other agents, or unauthorized external agents. In addition, this embodiment can persist Memory, Workspace, Soul, and cross-device synchronized data in encrypted form, and the release of control keys is constrained by identity, container, policy, and security state.

[0045] Furthermore, in one embodiment, the secure intelligent agent routing module is specifically used for: Query the mapping relationship between currently created containers in the agent's virtual runtime space and the user identity identifier and agent identifier; If a matching target container exists, the agent context object is routed to the target container; If no matching target container exists, a new container is created within the agent's virtual runtime space. The user identity identifier and agent identifier are bound to the new container. The memory data and workspace corresponding to the user identity identifier and the agent characteristics corresponding to the agent identifier are bound to the new container to form a target container. The agent context object is then routed to the target container.

[0046] As an example, in this embodiment, the SE-Agent Router can preferably be controlled to dynamically select, create, reuse, or destroy Containers based on comprehensive information such as user_id, agent_id, workspace_id, vehicle state, mode, risk, and permission_profile. Specifically, a container mapping table can be pre-built to establish a one-to-one correspondence between user_id, agent_id, and the Containers already deployed in the Agent VM Sandbox, with each Container bound to corresponding Memory, Workspace, Soul, permission policies, and resource permissions. Based on this, when the SE-Agent Router receives the AgentContext, it can generate routing conditions based on the comprehensive information such as user_id, agent_id, workspace_id, vehicle state, mode, risk, and permission_profile in the AgentContext, and query the existing container mapping table according to the routing conditions to perform container selection and routing actions.

[0047] Suppose that when a user initiates an entertainment request, the vehicle triggers an abnormal vibration alarm in Sentry mode. In this case, with Sentry mode set to high risk, the routing condition will show that entertainment agent interaction is prohibited. The container mapping table will not be queried; instead, a warning message indicating that access to the entertainment agent is prohibited or a risk warning will be returned. Conversely, if the vehicle is in sleep mode when the user initiates an entertainment request, with sleep mode set to low risk, the routing condition will show that entertainment agent interaction is allowed. The SE-Agent Router will then iterate through the container mapping table based on the user_id and agent_id to check if a deployed container matching the user_id and agent_id exists in the Agent VM Sandbox. If it does, the deployed container will be used as the target container, and the AgentContext will be routed to that target container. If it does not exist, the routing will proceed within the Agent VM. A new Container is created within the Sandbox, and the user_id and agent_id are bound to the new Container. At the same time, the memory data and workspace corresponding to the user_id and the Soul corresponding to the agent_id are bound to the new Container to form the target Container. Then, the AgentContext is routed to the target Container.

[0048] Furthermore, in one embodiment, the agent context object further includes vehicle status, risk level, and permission policy; the agent virtual operating space further includes an action permission verification module, which is used for: Before calling the vehicle service interface and / or external intelligent agents, perform action authorization verification based on user identity, intelligent agent identity, vehicle status, risk level and permission policy; If the action authorization verification passes, the action of calling the vehicle service interface and / or an external intelligent agent will be executed; If the action authorization verification fails, actions that call the vehicle service interface and / or external intelligent agents are prohibited.

[0049] As an example, it is understandable that when an agent directly calls vehicle service interfaces or external agent capabilities such as Service-Oriented Architecture (SOA), Model Context Protocol (MCP), vehicle skills, or app capabilities, without relevant verification, it may allow children, guests, valet drivers, or maintenance personnel to unauthorizedly control the vehicle's physical world. To prevent unauthorized vehicle capability calls, this embodiment implements an action permission verification mechanism for vehicle-side agents: before calling vehicle service interfaces (such as vehicle skills, SOA, MCP, app capabilities, etc.) and external agent capabilities, Action Permission Verify can verify and confirm the operation permissions corresponding to the call action based on user_id, agent_id, seat, vehicle state, risk, and permission_profile, including identity, scenario, vehicle status, and risk. If the action authorization verification passes, the call is allowed; if the action authorization verification fails, the call is rejected, ensuring that different identities have different operable capabilities in different scenarios. It should be noted that for high-risk call actions, secondary confirmation can be required to ensure driving safety and data access security.

[0050] Furthermore, in one embodiment, the permission policy includes a restriction policy corresponding to a restricted object, which includes strangers, children, designated drivers, car rental personnel, and maintenance personnel. The restriction policy includes creating a restricted agent or a restricted container and using a temporary workspace, restricted agent characteristics, and a restricted memory policy to clean up or archive temporary data after the interaction ends.

[0051] Exemplary and understandable, the core difference of vehicle-side agents lies in the fact that the vehicle is an N:1 shared space, with different users having different identities, permissions, memories, and interaction modes with the same vehicle-side agent system. Therefore, this embodiment maps different input objects such as the driver, passenger, child, stranger, and active perception system to different Souls or restricted Souls, and further binds them to corresponding Memory and Workspace to achieve multi-identity isolation for the driver, passenger, child, guest, chauffeur, maintenance personnel, and system agent. It should be noted that the specific permissions and scope corresponding to each type of user can be determined according to actual needs and are not limited here. For details, see [link to documentation]. Figure 2As shown, the driver's seat corresponds to Soul_A and has full access; the passenger seat corresponds to Soul_C and has a personal workspace; children correspond to Soul_D and have restricted access; strangers or guests have no memory / no permission or a temporary workspace. The proactive sensing system corresponds to the RestrictedAccess policy. Therefore, the Memory / Workspace Manager can manage the loading, reading, writing, sharing, cleanup, and persistence of Memory, Workspace, and Soul based on the AgentContext and permission policies, and prohibit unauthorized cross-container access.

[0052] Based on this, this embodiment will implement a temporary mode governance mechanism for restricted objects such as Guest / Child / chauffeur / repair personnel; specifically, for strangers, children, visitors, chauffeur, car rental or repair personnel, a Guest AgentContainer or restricted Agent Container can be created, and temporary Workspace, restricted Soul and No Memory / Restricted Memory strategies can be used, and temporary data can be cleaned up or archived after the temporary mode ends to prevent temporary users from accessing the owner's private memory.

[0053] Furthermore, in one embodiment, the agent virtual operating space further includes an agent gateway, which is used to map external agent requests to local agent context objects and establish constraint relationships between external agent requests and containers, memory data, workspaces, agent characteristics, and permission policies.

[0054] As an example, it should be understood that current vehicle-side agents often need to simultaneously invoke local vehicle capabilities and external cloud agents. However, existing solutions lack A2A Gateway, session isolation, and authorization paths, making it difficult to guarantee the security boundaries of cross-end agent collaboration. Based on this, this embodiment will implement an A2A Gateway-cloud agent collaboration mechanism. That is, the vehicle-side agent, as a mobile node in a unified agent network, can access external agent networks such as mobile agents, PC agents, and cloud agents through the A2A Gateway to collaborate with mobile agents, PC agents, and cloud agents. In addition, requests from external agents must be mapped to the local AgentContext, and a constraint relationship must be established between external agent requests and Container, Memory / Workspace, Soul, and permission policies. This ensures that external agent requests are constrained by the target Container, Memory / Workspace, Soul, and vehicle capability permission policies, thereby preventing external agents from directly accessing local privacy memory or making unauthorized calls to vehicle capabilities.

[0055] Furthermore, in one embodiment, the host domain and the agent's virtual operating space interact with each other via an isolated communication channel, which is implemented based on a virtual socket protocol or restricted virtual input / output.

[0056] As an example, in this embodiment, the Host is controlled to send input and receive results only through a controlled channel (i.e., an isolated communication channel) to prevent the Host App from directly reading or tampering with data such as Agent Memory, Workspace, and Soul. The isolated communication channel is implemented based on the virtual socket protocol vsock or restricted virtual input / output virtio, meaning that the Host only interacts with objects within the Agent VM Sandbox through vsock / restricted virtio. It should be noted that the specific implementation methods and working principles of vsock and restricted virtio are common knowledge in the field, and will not be elaborated here for the sake of brevity.

[0057] Based on this, this embodiment implements a two-layer isolation mechanism of virtual machine (VM) + container: controlling the Agent Runtime and multiple containers, Memory / Workspace Manager and A2A Gateway to run within the Agent VM Sandbox, so as to isolate the Host through the VM and isolate different Agents through the Container, so that container anomalies are first restricted to the VM, while controlling the Host to interact with the VM only through vsock / restricted virtio, thereby achieving bidirectional protection between the Host and Agent execution environment and between different Agents.

[0058] It should be noted that the above mechanism can be applied in vehicle-side multi-user agents, in-vehicle voice assistant upgrades, proactive perception services, cockpit personalization, vehicle SOA / MCP capability governance, cross-terminal A2A agent networks, and privacy protection in car rental / chauffeur / repair models.

[0059] In summary, this embodiment constructs a closed loop of VM + multiple containers + Memory / Workspace / Soul binding + Runtime dynamic routing, which can solve problems such as Agent input crosstalk, memory serial numbers, Workspace pollution, and unauthorized access in N:1 multi-identity scenarios on the vehicle side. It isolates the Host through VM, different Agents through Container, and memory and workspace through Memory / WorkspaceManager, forming a two-layer execution isolation and data isolation. Simultaneously, the SE-Agent Router can dynamically select or create containers based on the intelligent agent context object constructed from voiceprint, account, special Agent fields, input source, vehicle status, etc., supporting on-demand startup, reuse, destruction, and resource control. Furthermore, Action Permission Verification is required before vehicle Skill, SOA, MCP, and App capabilities, as well as external Agent calls, to reduce the risk of unauthorized vehicle control in scenarios involving children, guests, chauffeured drivers, and maintenance personnel. Further, this embodiment uses an A2A Gateway to make the vehicle-side Agent accessible to the cloud, mobile phones, and PCs. Controlled mobile nodes in the Agent network support cross-device distributed task collaboration while maintaining local privacy and vehicle capability boundaries. In addition, temporary modes such as Guest, Child, chauffeur, car rental, and maintenance can use restricted Soul, temporary Workspace, and memory cleanup policies to protect the owner's privacy memories, trips, contacts, cabin behavior preferences, and local knowledge base. Based on this, this embodiment can be extended to multi-user agents on the vehicle side, proactive perception services, in-vehicle personalized cockpits, SOA / MCP capability governance, and cross-device agent ecosystems.

[0060] Secondly, embodiments of this application provide a vehicle including the vehicle-side intelligent agent system as described above.

[0061] Thirdly, embodiments of this application also provide a vehicle-side intelligent agent control method.

[0062] In one embodiment, reference is made to Figure 3 , Figure 3 This is a flowchart illustrating an embodiment of the vehicle-side intelligent agent control method of this application. Figure 3 As shown, the vehicle-side intelligent agent control method includes: Step S10: Receive multi-source input information and generate an agent context object based on the multi-source input information. The agent context object includes a user identity identifier and an agent identifier. Step S20: Route the agent context object to the target container in the agent virtual runtime space that corresponds to the user identity and agent identity. The target container has a corresponding target object, which includes memory data, workspace and agent characteristics. Step S30: Execute the target task within the target container based on the target object and the agent context object.

[0063] In this exemplary embodiment, the Agent Interface receives multi-source input information, including voiceprint, account, seat, App request, vehicle event, agent_id, or external A2A request, and generates an AgentContext based on this. This AgentContext includes, but is not limited to, user_id, agent_id, mode, risk, permission_profile, workspace_id, input source, and vehicle status. The SE-Agent Router makes routing decisions based on the AgentContext and looks up the Container mapping table to select or create a target Container. This target Container provides a runtime environment for the Driver Agent, Passenger Agent, Guest Agent, Child Agent, System Agent, or other Agent Groups. The target Container loads its dedicated Memory, Workspace, and Soul, and the Agent Runtime performs AI calculations, task planning, and Skill scheduling within the target Container. Before invoking vehicle Skills, MCP, SOA, App capabilities, or external Agents, Action Permission... Verify confirms the call action based on user identity, vehicle status, risk level, and permission policy. After the task is completed, it only returns the authorization result. If persistence is required, the result, summary, or status is written back to the corresponding memory / workspace. Finally, the Agent Interface feeds back the result to the original input source through voice, screen, App, or vehicle status, and keeps the input source and output result consistent.

[0064] As can be seen, this embodiment forms a complete closed loop for vehicle-side agent security governance, consisting of "input identity recognition—AgentContext generation—Runtime routing—Container selection / creation—Memory / Workspace / Soul binding—Vehicle capability authorization—A2A external connection—result write-back".

[0065] The implementation of each step in the above-mentioned vehicle-side intelligent agent control method corresponds to each part in the above-mentioned vehicle-side intelligent agent system embodiment, and its functions and implementation process will not be described in detail here.

[0066] Fourthly, embodiments of this application provide a vehicle-side intelligent agent control device, which can be a PC, laptop, server, or other device with data processing capabilities.

[0067] Reference Figure 4 , Figure 4 This is a schematic diagram of the hardware structure of the vehicle-side intelligent agent control device involved in the embodiments of this application. In the embodiments of this application, the vehicle-side intelligent agent control device may include a processor, a memory, a communication interface, and a communication bus.

[0068] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0069] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used to interconnect devices within the vehicle-mounted intelligent agent control device, as well as interfaces used to interconnect the vehicle-mounted intelligent agent control device with other devices (such as other computing devices or user devices). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user devices can be displays, keyboards, etc.

[0070] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0071] The processor can be a general-purpose processor, which can call the vehicle-side intelligent agent control program stored in the memory and execute the vehicle-side intelligent agent control method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the vehicle-side intelligent agent control program is called can be referred to in the various embodiments of the vehicle-side intelligent agent control method of this application, and will not be repeated here.

[0072] Those skilled in the art will understand that Figure 4 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0073] Fifthly, embodiments of this application also provide a computer-readable storage medium.

[0074] The present application has a readable storage medium storing a vehicle-side intelligent agent control program, wherein when the vehicle-side intelligent agent control program is executed by a processor, it implements the steps of the vehicle-side intelligent agent control method as described above.

[0075] The method implemented when the vehicle-side intelligent agent control program is executed can be referred to in various embodiments of the vehicle-side intelligent agent control method of this application, and will not be repeated here.

[0076] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0077] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0078] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0079] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0080] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish the different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

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

[0082] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A vehicle-side intelligent agent system, characterized in that, The vehicle-side intelligent agent system includes: a host domain and an intelligent agent virtual runtime space. The host domain includes an intelligent agent interface module, and the intelligent agent virtual runtime space includes a secure intelligent agent routing module and an intelligent agent runtime module. The agent interface module is used to receive multi-source input information and generate an agent context object based on the multi-source input information. The agent context object includes a user identity identifier and an agent identifier. The secure agent routing module is used to route the agent context object to the target container in the agent virtual runtime space that corresponds to the user identity and agent identity. The target container has a corresponding target object, which includes memory data, workspace and agent characteristics. The agent runtime module is used to execute target tasks within the target container based on the target object and the agent context object.

2. The vehicle-side intelligent agent system as described in claim 1, characterized in that, The secure intelligent agent routing module is specifically used for: Query the mapping relationship between currently created containers in the agent's virtual runtime space and the user identity identifier and agent identifier; If a matching target container exists, the agent context object is routed to the target container; If no matching target container exists, a new container is created within the agent's virtual runtime space. The user identity identifier and agent identifier are bound to the new container. The memory data and workspace corresponding to the user identity identifier and the agent characteristics corresponding to the agent identifier are bound to the new container to form a target container. The agent context object is then routed to the target container.

3. The vehicle-side intelligent agent system as described in claim 1, characterized in that, The agent context object also includes vehicle status, risk level, and permission policy; the agent virtual operating space also includes an action permission verification module, which is used for: Before calling the vehicle service interface and / or external intelligent agents, perform action authorization verification based on user identity, intelligent agent identity, vehicle status, risk level and permission policy; If the action authorization verification passes, the action of calling the vehicle service interface and / or an external intelligent agent will be executed; If the action authorization verification fails, actions that call the vehicle service interface and / or external intelligent agents are prohibited.

4. The vehicle-side intelligent agent system as described in claim 3, characterized in that, The permission policy includes a restriction policy corresponding to the restricted object, which includes strangers, children, designated drivers, car rental personnel, and maintenance personnel. The restriction policy includes creating a restricted agent or restricted container and using a temporary workspace, restricted agent characteristics, and a restricted memory policy to clean up or archive temporary data after the interaction ends.

5. The vehicle-side intelligent agent system as described in claim 1, characterized in that, The virtual runtime space for intelligent agents also includes an intelligent agent gateway, which is used to map external intelligent agent requests to local intelligent agent context objects and establish constraint relationships between external intelligent agent requests and containers, memory data, workspaces, intelligent agent characteristics, and permission policies.

6. The vehicle-side intelligent agent system as described in claim 1, characterized in that, The host domain and the agent's virtual operating space interact with each other via an isolated communication channel, which is implemented based on a virtual socket protocol or restricted virtual input / output.

7. A vehicle, characterized in that, Including the vehicle-mounted intelligent agent system as described in any one of claims 1 to 6.

8. A vehicle-side intelligent agent control method, applied to a vehicle-side intelligent agent system as described in any one of claims 1 to 6, characterized in that, The vehicle-side intelligent agent control method includes: Receive multi-source input information and generate an agent context object based on the multi-source input information. The agent context object includes a user identity identifier and an agent identifier. The agent context object is routed to the target container in the agent's virtual runtime space that corresponds to the user identity and agent identity. The target container has a corresponding target object, which includes memory data, workspace, and agent characteristics. The target task is executed within the target container based on the target object and the agent context object.

9. A vehicle-side intelligent agent control device, characterized in that, The vehicle-mounted intelligent agent control device includes a processor, a memory, and a vehicle-mounted intelligent agent control program stored in the memory and executable by the processor, wherein when the vehicle-mounted intelligent agent control program is executed by the processor, it implements the steps of the vehicle-mounted intelligent agent control method as described in claim 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a vehicle-side intelligent agent control program, wherein when the vehicle-side intelligent agent control program is executed by a processor, it implements the steps of the vehicle-side intelligent agent control method as described in claim 8.

Images