Three-element linkage execution method and system for vehicle-mounted intelligent agent tool call

Abstract

The application relates to the field of vehicle-mounted software and discloses a three-element linkage execution method for tool calling of a vehicle-mounted intelligent agent and a gateway system, which comprises the following steps: receiving a calling request and obtaining a calling subject identifier and target tool parameters; analyzing the original semantics of the calling request to generate a target state change vector composed of multiple vehicle domain state change dimensions; assembling vehicle state data, environment state data, personnel state data, resource state data and a historical operation sequence to form a current context data set; and taking the calling subject identifier, the target tool parameters, the target state change vector and the current context data set as joint input variables to perform dynamic permission judgment. The application can realize active identification and dynamic control of risks at the semantic entrance of tool calling of a vehicle-mounted large model, avoids the decline of function availability caused by simple rejection, and realizes safe degradation execution in a high-risk scene through a rewriting mechanism of an alternative execution path.

Description

Technical Field

[0001] This invention relates to the field of vehicle software, and in particular to a three-element linkage execution method and gateway system for invoking vehicle intelligent agent tools. Background Technology

[0002] With the deployment of large-scale cockpit models, in-vehicle agents, domain controller orchestration, and tool invocation frameworks in intelligent vehicles, more and more vehicle functions are no longer triggered through fixed menus, but through natural language, multimodal requests, or multi-agent collaborative plans. Unlike traditional HMI control, agent invocation chains have the following characteristics: user input is often first semantically parsed and then transformed into tool invocations, parameter combinations, and cross-domain action plans; a single invocation may span multiple domains, including the cockpit, body, chassis, access system, payment, cloud services, and driver assistance; risks no longer only come from unauthorized access, but also from misunderstanding of intent, excessive parameters, chained linkages, improper execution timing, missing context, and multi-agent conflicts.

[0003] Existing technologies can be broadly categorized into four types.

[0004] The first type is access control based on identity, role, and vehicle status. For example, CN116994577A, for voice commands, determines whether vehicle operations are allowed based on user legitimacy, location, health status, priority, age, and other role information. This solution can achieve fine-grained role-based access control, but its determination result is essentially still whether or not execution is authorized. It lacks a design that considers the acceptability of the execution consequences as an independent access control condition during runtime, and it has not yet disclosed a mechanism for generating alternative execution paths after the risk exceeds the threshold.

[0005] The second category is permission verification for large language model tool calls. For example, CN118568776A discloses a chain of question intent recognition, tool matching, permission verification, and feedback generation to protect privacy data and control function tool calls. This solution has a semantic entry point similar to this invention, but its application scenarios are concentrated on general information query and privacy protection. It is not geared towards the in-vehicle physical world, nor does it incorporate the vehicle environment, driver status, passenger status, execution chain influence domain, and forward inference of execution consequences into the same closed loop. Furthermore, it does not disclose high-risk but alternative rewritten execution paths.

[0006] The third category is dialogue and task orchestration for in-vehicle multi-agent or multi-domain interactions. For example, CN118514708A discloses a method that automatically triggers in-vehicle agents to output chat information based on environmental information, selects relevant agents, verifies the output content, and executes control actions after user feedback. This type of solution focuses on dialogue triggering and controlling the speaking order of multiple agents, and does not involve modeling the consequences of actions after obtaining functional permissions or the issue of security rewriting.

[0007] The fourth category involves predicting physical risks and refusing to execute driving control inputs. For example, CN121246839A discloses a method that assesses accident risks based on environmental information and driver control inputs. If a risk is identified, the control command is refused to be executed, and the issue can be reported to a safety monitoring platform. This solution focuses on physical safety denial during manual or intelligent driving takeover processes, but further improvements are needed in areas such as large-scale model intent parsing, semantic binding of tool calls, dynamic permission determination, alternative execution synthesis, and cross-domain coordination among multiple agents.

[0008] In addition, CN109102593B mainly involves static or cloud-based configuration mapping of user-role-permission; TuSimple's US10768626B2 and Pedersen's US20240362500A1 involve multi-agent control task assignment and distributed task scheduling, respectively, but neither of them discloses the semantic intent-permission-consequence-rewrite closed loop for in-vehicle large model tool calls.

[0009] Therefore, although existing technologies cover individual aspects such as role permissions, tool call authorization, multi-agent scheduling, and physical risk denial, they have not yet formed the following technology chain: intent structured parsing, target state change vector construction, dynamic determination of context permissions, pre-execution consequence simulation, risk threshold classification, automatic rewriting of alternative execution paths, multi-agent conflict coordination, and evidence chain recording of operational behavior. Summary of the Invention

[0010] This invention addresses the insufficient security control in existing technologies for in-vehicle intelligent agent tool invocation by proposing a three-element linkage execution method and gateway system for such invocation. The "three-element linkage" refers to the linkage between "intent, permission, and consequence." This technical solution effectively solves the technical problems mentioned in the background art, such as misunderstanding of intent, excessive parameters, chained linkage, improper execution timing, missing context, and multi-agent conflicts, through core technologies such as multi-dimensional state perception, dynamic permission determination, consequence simulation and deduction, and alternative path rewriting.

[0011] The three-element linkage execution method of the present invention includes the following core steps:

[0012] First, the system receives the invocation request and obtains the invoking entity identifier and target tool parameters. The invoking entity identifier is used to uniquely identify the agent instance, mobile terminal user, or cloud service request initiating this tool invocation. The target tool parameters include the interface function identifier of the function to be executed, the action code sequence, and the configuration data frame.

[0013] Secondly, the original semantics of the call request are parsed to generate a target state change vector composed of multiple vehicle domain state change dimensions.

[0014] The original semantics of the call request are parsed, and natural language processing techniques are used to extract intent slot information. The parsing results are then mapped into a multi-dimensional target state change vector. This target state change vector is composed of physical state dimension, permission state dimension, temporal dimension, influence domain dimension, and chain effect dimension. The physical state dimension represents the physical parameters of the expected action direction and action amplitude. The permission state dimension represents the level code of the call request accessing high-sensitivity system interfaces, cross-physical domain control interfaces, or control takeover interfaces. The temporal dimension represents the clock information and condition trigger logic identifier of the action message. The influence domain dimension represents the potential impact of the called action on the driving safety domain, comfort domain, entry domain, vehicle body domain, payment domain, cloud service domain, or other domains. The chain effect dimension indicates whether the action may trigger further automatic actions, responses from other intelligent agents, or device cascading linkages.

[0015] Then, the acquired vehicle status data, environmental status data, personnel status data, resource status data, and historical operation sequences are assembled to form the current context dataset.

[0016] The vehicle status data includes parameters such as vehicle speed, gear, steering angle, braking pressure, and battery SOC; the environmental status data includes parameters such as temperature, light intensity, precipitation, and road surface adhesion coefficient; the personnel status data includes parameters such as driver attention index, voice emotion analysis, and biometric signals; the resource status data includes parameters such as memory occupancy, bus bandwidth, and computing load; and the historical operation sequence contains the time sequence record of the most recent N tool calls.

[0017] Next, the calling entity identifier, target tool parameters, target state change vector, and current context dataset are used as joint input variables to perform dynamic permission determination and output the determination result.

[0018] In specific implementation, the system first determines whether the calling entity has the right to invoke the tool; then it determines whether the state change meets the conditions for acceptance in the current context; wherein, the context includes: current vehicle operating state; driver state; occupant state; environment state; equipment and resource state; one or more of the historical operation sequence, wherein the occupant state includes one or more of the following: type of passenger, occupant distribution, and occupant entry intention; the historical operation sequence includes one or more of the following: continuous request frequency, previous action execution result, continuous failure cases, and abnormal interaction patterns.

[0019] This consequence simulation model is built upon a time series prediction network structure and can output risk assessment results within the projected time window. The risk assessment results include classifying requests into multiple risk levels based on simulation results and policy library thresholds: low risk, medium risk, high risk, and execution prohibition risk. Furthermore, the access control decision-making prioritizes the following principles: low-risk requests can be executed directly; medium-risk requests can be executed after adding explanation prompts or secondary confirmation; high-risk requests are given priority to enter the process of rewriting alternative execution paths; execution prohibition risk requests are rejected when there are no feasible alternative execution paths, and the reason for rejection is output.

[0020] Subsequently, the risk score is compared with the preset first risk threshold and the prohibition threshold, and different processing branches are executed according to the comparison results.

[0021] When the risk score is less than the first risk threshold, a direct execution path is generated according to the original semantics; when the risk score is greater than or equal to the first risk threshold and less than the prohibition execution threshold, the target tool parameters are extracted and rewritten to generate an alternative execution path carrying new triggering conditions and modified action parameters; when the judgment result is a direct rejection state, or the risk score is greater than or equal to the prohibition execution threshold, a rejection instruction set is generated and the execution link of the call request is blocked.

[0022] in,

[0023] The alternative execution path includes at least one or more of the following: parameter reduction, used to generate reduced control parameters; tool replacement, used to replace high-privilege action objects with alternative execution bodies with preset security attributes; step-by-step execution, used to process the original control request into a time-series execution sequence containing intermediate verification nodes; timing delay, used to suspend the current control request until the vehicle's dynamic physical indicators meet preset safety release conditions; mode switching, used to reduce the operating state to a preset high constraint level; and condition binding, used to forcibly connect at least one verification node in the action execution path to construct closed-loop access logic before execution.

[0024] The system further detects concurrent call requests within a predetermined time period. When multiple concurrent call requests are detected, a topology conflict graph is generated based on the target state change vector corresponding to each concurrent call request. The graph structure is pruned according to the node and edge attributes in the topology conflict graph. The request node parameters that have not been pruned are assembled with the direct execution path or alternative execution path to form the final execution plan.

[0025] This topology conflict graph sets the underlying action opcodes corresponding to each concurrent call request as nodes, and extracts the hardware resource occupancy mutex representation bit, the pre- and post-sequence dependency identifiers, and the process priority value as edge weight attribute parameters. Based on the weight attribute parameters, the topology conflict graph is traversed and calculated, and request nodes with low process priority values ​​that trigger the hardware resource occupancy mutex representation bit are removed. The retained request nodes are then assembled with the direct execution path or alternative execution path to form the final execution plan.

[0026] If no multiple concurrent call requests are detected, the generated direct execution path or alternative execution path will be used as the final execution plan.

[0027] Finally, optionally, the underlying action message containing the final execution plan is sent to the vehicle's underlying execution node, and the semantic decision structure that records the processing flow and the physical consequences recorded by the underlying execution node are encapsulated and spliced ​​into a running behavior evidence chain data block, which is then written into a locally isolated read-only audit ledger block.

[0028] The semantic decision structure includes a memory address segment allocated to the calling entity identifier, an array object of the original text character sequence, the target state change vector, and a verification hash code mapped to the local dynamic permission rule logic tree; the physical consequence record may optionally include a vehicle sensor state snapshot matrix at the time the control message is sent, a system bus hexadecimal control frame generated by the gateway protocol converter, a response level signal status word fed back by the underlying execution node, and hardware recovery condition parameters triggered when the blocking control action is executed.

[0029] In some possible implementations, the target state change vector comprises a sequence of numerical parameters along the following dimensions:

[0030] The physical state dimension is used to characterize the physical quantities of the expected action direction and the action amplitude.

[0031] The permission status dimension is used to characterize the level code of the call request accessing a high-sensitivity system interface, a cross-physical domain control interface, or a control takeover interface;

[0032] The timing dimension is used to represent the clock information for action message delivery and the condition triggering logic identifier;

[0033] The impact domain dimension is used to characterize the potential impact of this action on the driving safety domain, comfort domain, access domain, vehicle body domain, payment domain, and cloud service domain.

[0034] The chain reaction dimension is used to characterize whether the action is likely to trigger further automatic actions, responses from other intelligent agents, or cascading device linkages.

[0035] In some possible implementations, the dynamic permission determination using the calling entity identifier, the target tool parameters, the target state change vector, and the current context dataset as joint input variables, and the output determination result, includes: determining whether the calling entity has the right to call the tool; determining whether the state change meets the conditions for acceptance in the current context; wherein, the context includes: current vehicle operating state; driver state; occupant state; environmental state; equipment and resource state; one or more of the historical operation sequence, wherein the occupant state includes one or more of the following: passenger type, occupant distribution, and occupant entry intention; the historical operation sequence includes one or more of the following: continuous request frequency, previous action execution result, continuous failure cases, and abnormal interaction patterns.

[0036] In some possible implementations, the step of inputting the target state change vector and the current context dataset into a preset consequence simulation model, and outputting the risk assessment results within the extrapolation time window, includes:

[0037] Based on simulation results and policy library thresholds, requests are categorized into multiple risk levels, including low risk, medium risk, high risk, and execution prohibited risk; furthermore, access control decisions are optimized according to the following principles:

[0038] Low-risk requests can be executed directly;

[0039] For medium-risk requests, additional explanations or confirmations can be added before execution.

[0040] High-risk requests are given priority in the process of rewriting alternative execution paths;

[0041] Prohibit execution of risky requests. If there is no feasible alternative execution path, the request will be rejected, and the reason for rejection will be output.

[0042] In some possible implementations, the alternative execution path includes at least one or more of the following: parameter reduction, used to generate reduced control parameters; tool replacement, used to replace high-privilege action objects with alternative executors with preset security attributes; step-by-step execution, used to process the original control request into a time-series execution sequence containing intermediate verification nodes; timing delay, used to suspend the current control request until the vehicle's dynamic physical indicators meet preset safety release conditions; mode switching, used to reduce the operating state to a preset high constraint level; and condition binding, used to forcibly connect at least one verification node in the action execution path to construct closed-loop access logic before execution.

[0043] In some possible implementations, the step of pruning the graph structure based on the node and edge attributes in the topological conflict graph, and assembling the request node parameters that were not pruned with the direct execution path or the alternative execution path into a final execution plan, includes:

[0044] Set the underlying action opcode corresponding to each concurrent call request as the node set of the topology conflict graph;

[0045] Extract the hardware resource usage mutual exclusion bit, the pre- and post-timing time dependency identifiers, and the process priority value between each concurrent call request, and assign the connection between each node as a weight attribute parameter.

[0046] Based on the weight attribute parameters, a graph traversal calculation is performed on the topology conflict graph. Request nodes whose process priority values ​​are low and trigger the hardware resource occupation mutual exclusion representation bit are stripped and moved into the degradation cache pool or rejection cache pool. The remaining request nodes are moved into the executable action cache pool.

[0047] The action opcodes in the executable action cache pool are superimposed and merged with the instruction execution timing in the direct execution path or the alternative execution path along the system clock axis.

[0048] This invention also provides a three-element linkage gateway system for invoicing in-vehicle intelligent agent tools. The system includes: a request access and subject identification module for receiving invoice requests and obtaining the invoicing subject identifier and target tool parameters; an intent parsing and target state change vector generation module for parsing the original semantics of the invoice request and generating a target state change vector composed of multiple vehicle domain state change dimensions; a context aggregation module for assembling the acquired vehicle state data, environmental state data, personnel state data, resource state data, and historical operation sequences into a current context dataset; a permission determination module for dynamically determining permissions using the invoicing subject identifier, target tool parameters, target state change vector, and current context dataset as joint input variables and outputting the determination result; and a risk assessment and grading module for... When the result is a permissible state or a conditionally permissible state, the target state change vector and the current context dataset are input into a preset consequence simulation model, and the risk assessment result within the simulation time window is output. The risk assessment result includes a risk score. The strategy rewriting and alternative execution module is used to compare the risk score with a preset first risk threshold and a prohibited execution threshold: if the risk score is less than the first risk threshold, a direct execution path is generated according to the original semantics; if the risk score is greater than or equal to the first risk threshold and less than the prohibited execution threshold, the target tool parameters are extracted and a rewriting operation is performed to generate an alternative execution path carrying new triggering conditions and modified action parameters. The strategy rewriting and alternative execution module is used to generate a rejection instruction set and block the execution link of the call request when the judgment result is a direct rejection state, or when the risk score is greater than or equal to the prohibited execution threshold.

[0049] This invention also provides an intent-permission-consequence linkage gateway system, including a memory and a processor. The memory stores pre-compiled computer program instruction code and includes independent non-volatile storage partitions divided into read-only attributes for persistent storage of audit ledger blocks. The processor establishes a hardware bus connection with the memory and, when reading and executing the computer program instruction code, drives the system hardware circuitry to implement the instruction timing control flow of the aforementioned three-element linkage execution method for in-vehicle intelligent agent tool calls.

[0050] The present invention also provides a computer-readable storage medium on which a computer-executable instruction sequence is physically inscribed. When the computer-executable instruction sequence is read by the computer processor during the instruction fetch cycle and sent to the instruction register for execution, it implements all the operational logic steps of the three-element linkage execution method for calling vehicle-mounted intelligent agent tools as described above.

[0051] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0052] This invention effectively overcomes the fragmentation problem between single-point technologies such as role permission control, tool call authorization, multi-agent scheduling, and physical risk denial in existing technologies by constructing a complete technical closed loop, including intent structured parsing, target state change vector construction, context permission dynamic determination, pre-execution consequence simulation, risk threshold classification, automatic rewriting of alternative execution paths, multi-agent conflict coordination, and evidence chain recording of operational behavior.

[0053] The present invention can proactively identify and dynamically manage risks at the semantic entry point of the in-vehicle large model tool call. It avoids the functional availability degradation caused by simple rejection, achieves safe degraded execution in high-risk scenarios through the rewriting mechanism of alternative execution paths, and provides reliable data support for subsequent security audits and accountability through the traceability mechanism of the evidence chain of running behavior. Attached Figure Description

[0054] Figure 1 The three-element linkage execution method flow for invoking in-vehicle intelligent agent tools provided in this embodiment of the invention. Figure 1 ;

[0055] Figure 2 This is an exemplary system module architecture diagram of the in-vehicle intelligent agent tool call provided in the embodiments of the present invention; it is also an overall architecture diagram of the intent-permission-consequence linkage gateway.

[0056] Figure 3 This is a logic diagram of intent-permission-consequence linkage control provided in the embodiments of the present invention;

[0057] Figure 4The flowchart of a three-element linkage execution method for invoking in-vehicle intelligent agent tools provided in this embodiment of the invention. Figure 2 ;

[0058] Figure 5 A flow diagram of the evidence chain between data and operational behavior. Detailed Implementation

[0059] The intent-permission-consequence linkage gateway system provided by the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0060] In the solution of the present invention, such as Figure 1 A three-element linkage execution method for invoking in-vehicle intelligent agent tools includes the following steps:

[0061] Receive the call request and obtain the caller identifier and target tool parameters of the call request;

[0062] Parse the original semantics of the call request and generate a target state change vector composed of multiple vehicle domain state change dimensions;

[0063] The acquired vehicle status data, environmental status data, personnel status data, resource status data, and historical operation sequences are assembled to form the current context dataset;

[0064] The system uses the calling entity identifier, target tool parameters, target state change vector, and current context dataset as joint input variables to perform dynamic permission determination and output the determination result.

[0065] When the judgment result is an allowable state or a conditional allowable state, the target state change vector and the current context dataset are input into the preset consequence simulation model, and the risk assessment result within the simulation time window is output. The risk assessment result includes a risk score.

[0066] The risk score is compared numerically with the preset first risk threshold and the prohibition threshold:

[0067] If the risk score is less than the first risk threshold, a direct execution path is generated based on the original semantics.

[0068] If the risk score is greater than or equal to the first risk threshold and less than the prohibition threshold, extract the target tool parameters and perform a rewrite operation to generate an alternative execution path carrying the new triggering conditions and modified action parameters.

[0069] As one implementation method, when the determination result is a direct rejection state, or when the risk score is greater than or equal to the prohibition execution threshold, a rejection instruction set is generated and the execution link of the call request is blocked.

[0070] The method provided by this invention breaks through the rigid blocking restrictions of traditional static permissions. By transforming the call semantics into a state change vector and combining it with multi-dimensional context for consequence deduction, the system can accurately assess the vehicle's safety boundaries before execution. In particular, when a risk exceeding the limit is detected, the system no longer simply rejects the request, but automatically rewrites and generates a low-risk alternative execution path. This solution not only ensures that the vehicle's physical state is always within an acceptable safety threshold, but also maximizes the continuity of the agent's objectives in extreme scenarios, achieving a perfect balance between security and user experience.

[0071] Building upon the methods described above, and further considering the potential for multiple intelligent agents to simultaneously issue control commands in a real-world vehicle environment, leading to contention for underlying hardware resources or logical conflicts, this embodiment introduces a concurrency coordination mechanism after generating a direct execution path or an alternative execution path. Specifically, the system will implement real-time monitoring within a predetermined time period to detect concurrent call requests within that period.

[0072] If multiple concurrent call requests are detected during this period, a topology conflict graph is generated based on the target state change vector corresponding to each concurrent call request. The graph structure is pruned according to the node and edge attributes in the topology conflict graph. The parameters of the request nodes that have not been pruned are assembled with the direct execution path or alternative execution path to form the final execution plan. If no multiple concurrent call requests are detected, the generated direct execution path or alternative execution path is used as the final execution plan.

[0073] When facing concurrent calls from multiple agents, this solution incorporates cross-domain action mutual exclusion, inter-domain dependencies, and potential chain amplification risks into a unified graph-structured computation framework based on the target state change vector. By removing conflicting nodes through graph pruning algorithms, the system not only effectively resolves contention for underlying hardware resources and the risk of logical deadlock, but also ensures that even in complex concurrent serial linkage scenarios, the system can still robustly output a safe and executable final plan, achieving a safe leap from single-point response to global multi-dimensional collaboration.

[0074] After determining the final execution plan, in order to complete the control loop and achieve automotive-grade underlying security audit, the solution of this invention further performs message delivery and evidence collection processing.

[0075] During the message distribution and evidence collection process, the underlying action message containing the final execution plan is sent to the vehicle's underlying execution node. The semantic decision structure that records the processing flow and the physical consequences recorded by the underlying execution node are encapsulated and spliced ​​into a running behavior evidence chain data block, which is then written to the local isolated read-only audit ledger block.

[0076] By constructing a hardware-level isolated and tamper-proof chain of evidence, this solution not only achieves precise closed-loop verification from abstract intent to underlying physical execution, but also provides highly reliable underlying data support for subsequent compliance reviews, accurate attribution of responsibility for traffic accidents, and iterative upgrades of model strategies. It also greatly improves the engineering transparency and automotive-grade safety protection level of the in-vehicle intelligent agent system.

[0077] In order to comprehensively and accurately quantify the impact of the aforementioned call request on the various physical and logical domains of the vehicle, this embodiment specifically defines the data structure of the target state change vector generated in the above steps. The target state change vector specifically includes the following numerical parameter sequences: physical state dimension; permission state dimension; temporal dimension; influence domain dimension; and chain effect dimension.

[0078] Multidimensional parameter sequences transform ambiguous intentions into machine-readable structured matrices, completely eliminating semantic drift during instruction issuance and providing a high-dimensional computational foundation for subsequent accurate dynamic authentication and consequence deduction.

[0079] Regarding the security screening stage in the aforementioned process, specifically the process of dynamically determining permissions using the calling entity identifier, target tool parameters, target state change vector, and current context dataset as joint input variables, and outputting the determination result, its specific cross-validation and state assignment mechanism includes: determining whether the calling entity has the right to call the tool; determining whether the state change meets the conditions for acceptance in the current context; wherein, the context includes: current vehicle operating status; driver status; occupant status; environmental status; equipment and resource status; one or more of the historical operation sequence, wherein, occupant status includes one or more of the following: passenger type, occupant distribution, and occupant entry intention; the historical operation sequence includes one or more of the following: continuous request frequency, previous action execution result, continuous failure cases, and abnormal interaction patterns.

[0080] After the dynamic permission determination described above, to ensure the security of the physical environment, the process of inputting the target state change vector and the current context dataset into a preset consequence simulation model and outputting the risk assessment results within the extrapolation time window is achieved through the following operations:

[0081] Based on simulation results and policy library thresholds, requests are categorized into multiple risk levels, including low risk, medium risk, high risk, and execution prohibition risk. Furthermore, access control decisions prioritize the following principles: low-risk requests can be executed directly; medium-risk requests can be executed after adding explanation prompts or secondary confirmation; high-risk requests are given priority to enter the process of rewriting alternative execution paths; execution prohibition risk requests are rejected when there are no feasible alternative execution paths, and the reason for rejection is output.

[0082] When the risk score obtained from the above deduction falls into the range requiring downgrade processing, the steps of extracting target tool parameters, performing rewriting operations, and generating alternative execution paths can be implemented through the application of intervention strategies. Specifically, this includes executing one or more of the following rewriting instruction generation operations: parameter reduction, used to generate reduced control parameters; tool replacement, used to replace high-privilege action objects with alternative executors with preset security attributes; step-by-step execution, used to process the original control request into a time-series execution sequence containing intermediate verification nodes; timing delay, used to suspend the current control request until the vehicle's dynamic physical indicators meet the preset safety release conditions; mode switching, used to reduce the operating state to a preset high constraint level; and condition binding, used to forcibly connect at least one verification node in the action execution path to construct a closed-loop access logic before execution.

[0083] This underlying mechanism translates abstract replacement strategies into physical degradation instructions. This approach breaks the rigid rejection pattern, ensuring automotive-grade safety standards while maximizing the preservation of user intent and experience continuity.

[0084] Furthermore, for the aforementioned scenario of handling concurrent requests from multiple agents, the steps of pruning the graph structure based on the node and edge attributes in the topological conflict graph to assemble the final execution plan are implemented as follows:

[0085] Based on the node and edge attributes in the topology conflict graph, graph pruning is performed. The parameters of the request nodes that were not pruned are then combined with the direct execution path or alternative execution path to form the final execution plan, including:

[0086] Set the underlying action opcodes corresponding to each concurrent call request as a set of nodes in the topology conflict graph;

[0087] Extract the hardware resource usage mutual exclusion bit, the pre- and post-timing time dependency identifiers, and the process priority value between each concurrent call request, and assign the connection between each node as a weight attribute parameter.

[0088] Based on the weight attribute parameters, the graph traversal calculation is performed on the topology conflict graph. Request nodes with low process priority values ​​and triggering hardware resource occupation mutual exclusion representation bits are removed and moved into the degradation cache pool or rejection cache pool. The remaining request nodes are moved into the executable action cache pool.

[0089] The action opcodes in the executable action buffer pool are superimposed and merged with the instruction execution timing in the direct execution path or alternative execution path along the system clock axis.

[0090] The system performs graph traversal calculations on the topology conflict graph, accurately identifying low-priority conflicting nodes and resolving underlying resource contention and logical deadlocks at the physical level. Instruction overlay based on the system clock axis ensures the secure and timely delivery of multi-domain control messages in concurrent scenarios.

[0091] This solution utilizes a sliding time window to statistically analyze risks, extending the security defense from single-call scenarios to continuous behavioral patterns, accurately identifying hidden and persistent risks. Furthermore, the system physically disconnects the bus link of highly sensitive nodes using hardware register bits, achieving a security leap from software rejection to hardware isolation. This not only avoids the security risks of bypassing software logic but also ensures the authority of secure takeover through an external unlocking protocol.

[0092] The following combination Figure 2 and Figure 3 This invention provides an intent-permission-consequence linkage gateway system for in-vehicle intelligent agent tool invocation.

[0093] like Figure 2 The diagram shown is an exemplary system module architecture diagram of a three-element linkage gateway system for invoking in-vehicle intelligent agent tools, provided by the present invention. This system includes at least:

[0094] The access request and subject identification module 1 is used to receive user natural language requests, system event requests, or other intelligent agent delegation requests, and obtain the corresponding subject identifier.

[0095] The intent parsing and target state change vector generation module 2 is used to convert the request sent by the request access and subject identification module into a structured intent representation and generate a target state change vector.

[0096] Context aggregation module 3 is used to aggregate context information such as vehicle status, driving task, environmental information, driver status, occupant status, resource status, fault mode, historical operation sequence and policy version.

[0097] Permission determination module 4 is used to perform dynamic permission determination based on the calling subject, target tool, target state change vector and context constraints.

[0098] The consequences simulation module 5 is used to predict the state changes, risk propagation and conflict results that the call may cause within a predetermined time window after authorization or conditional approval.

[0099] The Risk Assessment and Classification Module 6 is used to output risk scores, risk categories, confidence levels, impact domains, and evidence summaries.

[0100] The strategy rewriting and alternative execution module 7 is used to generate low-risk alternative execution paths when the risk exceeds a predetermined threshold.

[0101] The multi-agent conflict coordination module 8 is used to establish mutual exclusion relationships, priorities, and degradation strategies for concurrent action requests from multiple agents.

[0102] The execution orchestration and control output module 9 is used to output the final execution plan, conditional execution plan, secondary confirmation plan, or rejection plan.

[0103] The Audit and Evidence Ledger Module 10 is used to record request semantics, context snapshots, risk assessment results, decision results, execution results, and recovery conditions in the chain of evidence for operational behavior.

[0104] Furthermore, in Figure 2 Based on the architecture diagram shown, combined with Figure 3 The diagram shown is a logic diagram of the intent-permission-consequence linkage gateway system for in-vehicle intelligent agent tool invocation provided by the present invention, which illustrates the embodiments of this application.

[0105] The invocation process begins with two parallel data inputs. One path parses the request for access and the subject's identification information to generate a target state change vector; the other path aggregates the vehicle / environment / occupant / resource context. These two data streams converge in the dynamic permission determination module for initial screening. If the determination is "directly rejected," the process proceeds directly to the rejection and explanation output, and the orchestration and control output module rejects the plan's implementation. If the determination is "allowed / conditionally allowed," the process is allowed to proceed to the consequence simulation module for pre-consequence simulation, followed by risk assessment and grading. During the risk assessment phase, the system uses a three-way routing based on the risk level: "Absolute Prohibition" directly leads to the "Rejection and Explanation Output" result, where the execution orchestration and control output module will reject the plan's implementation; "Low Risk" generates a direct execution plan and sends it to the execution orchestration and control output module for execution; "High Risk / Rewriteable" requires sequential processing through the policy rewriting and alternative execution modules, followed by a "Multi-Agent Conflict Coordination" phase, before finally being implemented by the execution orchestration and control output module. The execution orchestration and control output phase simultaneously generates semantic decision records and physical consequence records, both of which are ultimately aggregated in the underlying audit and evidence ledger, forming a complete data loop.

[0106] The core of this invention lies not in individual intent recognition, individual permission verification, or individual physical risk prediction, but in organizing these three into a verifiable, interconnected control chain, further incorporating policy rewriting, cross-agent conflict coordination, and operational behavior evidence chain recording when necessary. This system architecture, through deep decoupling and collaboration of intent parsing, consequence simulation, and dynamic authentication modules, completely breaks down in-vehicle information silos. This not only significantly improves the efficiency of concurrent processing and fault-tolerant flow of cross-domain commands, but also enhances the high availability and traceability of the underlying electromechanical execution.

[0107] To enable those skilled in the art to more clearly understand the control mechanism and logic of the present invention, the following will provide an exemplary description of each key execution stage of the core technical solution of the present invention in conjunction with the internal data flow process of the system.

[0108] The following section explains the intent parsing and the construction of the target state change vector.

[0109] Intent parsing and target state change vector construction serve as the data abstraction foundation for the entire alternative execution mechanism. The core technical objective of this stage is to transform multi-source, heterogeneous, and non-standardized agent requests into structured parameters that can be recognized and computed by the underlying control gateway.

[0110] Specifically, when the above request enters the system, the intent parsing and target state change vector generation module does not directly use surface actions such as "opening the car window", "turning down the air conditioning", and "switching driving modes" as the only judgment object, but maps the request to structured target changes in multiple vehicle state domains.

[0111] To comprehensively define the potential physical and logical boundaries of the request, the target state change vector can be represented as a multidimensional structure, including at least one or more of the following dimensions:

[0112] 1. Physical state dimension, used to represent the expected direction and magnitude of change of door locks, windows, sunroofs, seats, air conditioning, lights, chassis, steering, braking, power, or other actuators.

[0113] 2. Permission Status dimension, used to indicate whether the request triggers sensitive permissions such as high-sensitivity tools, cross-domain tools, external payments, reading private data, and switching vehicle control.

[0114] 3. Timing dimension, used to indicate whether the action is executed immediately, delayed, in stages, or triggered by a condition.

[0115] 4. Impact Domain Dimension: This dimension indicates that the action may affect the driving safety domain, comfort domain, access domain, vehicle body domain, payment domain, cloud service domain, or other domains.

[0116] 5. Chain reaction dimension, used to indicate whether the action may trigger further automatic actions, responses from other intelligent agents, or cascading device linkages.

[0117] Through the above vectorization representation, the present invention can transform semantic intent into state change hypothesis, providing a unified object for subsequent permission determination, consequence simulation and record of evidence chain of operational behavior.

[0118] The next step is to explain the stage of dynamic determination of context permissions.

[0119] After constructing a unified vectorized representation, the system does not directly issue control commands, but instead uses them as verification objects, combining real-time aggregated vehicle context data for pre-emptive dynamic authentication. In this stage, the permission determination module not only determines whether the calling entity has the right to call the tool (i.e., static authentication), but also determines whether the state change meets the conditions for acceptance in the current context (i.e., dynamic authentication).

[0120] To achieve this fine-grained dynamic constraint, the context in this embodiment may include at least:

[0121] 1. Current vehicle operating status, such as parked, low-speed driving, high-speed driving, automatic driving, manual takeover, or fault-degraded mode.

[0122] 2. Driver's condition, such as fatigue, distraction, abnormal emotions, whether seat belt is worn, and whether both hands are off the steering wheel.

[0123] 3. Passenger status, such as information on the types of passengers (children, pets, etc.), the resting status of passengers in the back, passenger distribution, and entry intention.

[0124] 4. Environmental conditions, such as road type, surrounding obstacles, weather, lighting, temperature, and traffic events.

[0125] 5. Device and resource status, such as the load of relevant domain controllers, sensor availability, network latency, policy library version, and security module health.

[0126] 6. Historical operation sequence, such as the frequency of consecutive requests, the result of the previous action, consecutive failures, and abnormal interaction patterns.

[0127] The preferred outcome of permission determination is not a simple binary result of allow / deny, but includes at least multiple results such as: allow, conditional allowance, require confirmation, determine after entering simulation, and direct denial.

[0128] This solution integrates multi-dimensional vehicle scenarios for pre-emptive dynamic authentication, overcoming the limitations of static binary permission determination. Fine-grained polymorphic determination not only allows for more accurate calibration of the security boundaries of the current context but also provides a basis for decision-making in subsequent risk projection and policy rewriting.

[0129] The next step is to explain the pre-execution consequence simulation phase.

[0130] Although the request may have passed the aforementioned dynamic determination of context permissions, in order to prevent seemingly compliant single-point instructions from causing unforeseen harm in extreme or complex vehicle physical situations, embodiments of the present invention introduce a forward-looking sand table simulation defense line before the underlying action is issued.

[0131] Specifically, when the permission determination result is allowed or the conditions are allowed, the consequence simulation module performs a fast forward inference on the state change vector corresponding to the request before the action is actually issued to the toolchain.

[0132] The consequence simulation preferably employs a lightweight online model rather than a heavyweight offline simulation platform. This module can perform one or more predictions based on the following inputs: current vehicle snapshot, target state change vector, relevant actuator capability boundaries, contextual risk characteristics, historical similar call results, and current execution plans of multiple agents.

[0133] Based on the aforementioned multi-dimensional real-time feature inputs and the rapid calculations of the online model, the system can comprehensively depict the future state characteristics after instruction execution. Based on this, the consequence simulation output includes, for example,: risk score, risk category, confidence level, list of impact domains, key triggering conditions, set of feasible alternative actions, and recommended execution strategy. Among these, risk categories include security risks, unauthorized access risks, resource risks, experience risks, chain-reaction risks, and regulatory risks.

[0134] For example, when the request is to open all the windows and switch to theater mode, and the vehicle is currently in a rainy night with low temperatures and the driver is fatigued, the consequence simulation module can identify that the action will reduce visibility, interfere with driving attention, and cause a conflict between the comfort domain and the safety domain, thus outputting a high-risk conclusion.

[0135] The next step is to introduce the risk classification and access control decision-making stages. After obtaining the above deduction results and multi-dimensional output indicators, the system must translate them into specific control flow directions.

[0136] In this phase, the risk assessment and classification module classifies requests into multiple risk levels based on simulation results and policy library thresholds, such as low risk, medium risk, high risk, and execution prohibition risk.

[0137] Access control decision-making follows these principles:

[0138] 1. Low-risk requests can be executed directly.

[0139] 2. For medium-risk requests, explanation prompts or secondary confirmation can be added before execution.

[0140] 3. High-risk requests will be prioritized for alternative execution rewriting processes.

[0141] 4. Prohibit the execution of risk requests from being rejected when there are no feasible alternatives, and output the reason for rejection.

[0142] Compared with existing technologies, this invention separates "high risk" from "must be rejected", so that a large number of requests that could only be rejected can still obtain a secure landing path through rewriting.

[0143] The following section describes the strategy rewriting and alternative execution phases. For the high-risk requests located at the security boundary, this embodiment does not employ a rigid binary blocking strategy, but rather uses intelligent rewriting to balance the agent's business intent with physical security.

[0144] like Figure 3 As shown, when the risk is higher than the first predetermined threshold but lower than the absolute prohibition threshold, and there is a security variant that can preserve the user's objective, the policy rewriting and alternative execution module generates an alternative execution path.

[0145] The alternative execution path may include at least one or more of the following:

[0146] 1. Parameter reduction, used to generate controlled parameters after limitation; for example, reducing the opening range of a car window from fully open to partially open.

[0147] 2. Tool replacement, used to replace high-privilege action objects with alternative executors with preset security attributes; for example, rewriting the direct switch to chassis mode to first enter the confirmation mode or only execute the comfort domain action.

[0148] 3. Step-by-step execution is used to process the original control request into a time-sequenced execution sequence that includes intermediate verification nodes; for example, first unlocking, then prompting the occupants for confirmation, and then turning on the relevant equipment.

[0149] 4. Timing delay: This is used to suspend the current control request until the vehicle's dynamic physical indicators meet the preset safety release conditions; for example, when the vehicle is stationary, the vehicle speed is below a threshold, or the road conditions are safe.

[0150] 5. Mode switching, used to reduce the operating state to a preset high constraint level; for example, switching to conservative mode, child protection mode, privacy protection mode or low power mode.

[0151] 6. Conditional binding is used to force at least one verification node to be chained in the action execution path to build closed-loop access logic before execution; for example, requiring the driver to straighten their eyes, the car door to close, children to leave the danger zone, or the autonomous driving to disengage before execution.

[0152] By implementing this rewrite mechanism, which uses parameter reduction, step-by-step processing, and delays, the traditional hard blocking is transformed into a flexible degradation. When faced with boundary risks, an alternative path is automatically generated, which not only upholds the physical safety baseline of the vehicle but also maximizes the preservation of user objectives, perfectly balancing security and business continuity.

[0153] To ensure that the generated alternative execution paths can be effectively parsed and automatically executed by the underlying vehicle gateway and electromechanical actuators, rather than merely remaining as a superficial user interface pop-up reminder, the policy rewriting according to embodiments of this application outputs a structured alternative plan to replace the simple prompt that is not executable. The output alternative options include at least: alternative actions, triggering conditions, execution order, expected risk reduction value, and explanatory text.

[0154] After completing the parsing, deduction, and path generation of user requests, this embodiment further introduces a global conflict detection and coordination mechanism, considering that multiple intelligent agents (such as the cockpit domain, body domain, and intelligent driving domain) may issue control commands simultaneously in a real vehicle environment, leading to contention for underlying hardware resources or logical conflicts.

[0155] In one implementation, multiple agents can simultaneously initiate tool invocation requests. For example, the cockpit agent requests to activate entertainment mode, the vehicle body agent requests to activate a welcoming gesture, and the driver assistance agent requests to enter emergency defense mode. In this case, the multi-agent conflict coordination module constructs a conflict graph based on the target state change vector.

[0156] To address the complex conflict scenarios arising from high concurrency and cross-domain calls, and in order to achieve accurate system-level diagnosis and resource arbitration, this embodiment imposes multi-dimensional data structure limitations on the constructed conflict graph. Specifically, the conflict graph can reflect at least various conflict relationships between multiple agents, such as mutual exclusion, dependency, priority, resource contention, and security domain coverage.

[0157] After constructing the conflict graph and assigning multi-dimensional attribute weights, the system will dynamically adjudicate each concurrent request based on a preset graph structure pruning and traversal algorithm (such as priority-based graph node stripping). Based on the conflict graph, the system can output: the final set of executable actions, the set of downgraded actions, the set of delayed actions, the set of rejected actions, conflict explanations, and recovery conditions.

[0158] By combining conflict graphs with multi-dimensional data structure constraints, this solution achieves accurate conflict diagnosis and resource arbitration in high-concurrency cross-domain calls.

[0159] After completing the above conflict coordination and outputting the final executable action set, in order to form a complete control closed loop and meet the automotive-grade system's requirement for absolute traceability of the instruction execution process, this embodiment also includes a global audit mechanism at the end of the execution path.

[0160] like Figure 3 As shown, in the audit phase of the operational behavior evidence chain, the present invention preferably generates an operational behavior evidence chain for each decision.

[0161] The chain of evidence for operational behavior preferably includes at least one of the following recorded objects:

[0162] 1. Original request, subject identifier, and session identifier;

[0163] 2. Intent recognition results, target state change vector, and candidate tool set;

[0164] 3. Permission determination criteria, policy hit records, and secondary confirmation events;

[0165] 4. Environmental snapshots, vehicle status snapshots, and simulation input summaries;

[0166] 5. Risk assessment results, conflict diagram summary, and comparison of plans before and after rewriting;

[0167] 6. Final execution results, abnormal rollback records, and recovery conditions.

[0168] To further enhance the granularity of automotive-grade safety audits and clearly define the responsibility boundaries between "software instruction logic" and "underlying electromechanical execution," in one embodiment, the records in the operational behavior evidence chain can be further distinguished into semantic decision records and physical consequence records to facilitate audit playback and responsibility attribution. However, in this invention, both are used as components of the operational behavior evidence chain to uniformly support the interface for interpreting access control decisions, replaying execution results, and subsequent consistency verification during the operational phase.

[0169] The aforementioned chain of operational evidence can serve not only post-event replay but also engineering activities such as strategy reinjection and threshold iteration, liability attribution and compliance review, vehicle model migration and toolchain adaptation, and verifiable outputs for insurance, regulatory, or enterprise risk control platforms. This mechanism achieves fine-grained mapping across the entire chain from the original intent to the underlying electromechanical execution, providing structured and verifiable underlying data support for accident liability attribution, strategy iteration, and compliance review, ensuring the absolute traceability of the system.

[0170] In order to organically integrate the aforementioned in-depth discussions, such as intent parsing, dynamic authentication, consequence simulation, flexible rewriting, concurrency coordination, and bottom-line recording, into a complete and continuous control logic executed by the underlying computing resources, and to clearly demonstrate the temporal flow relationship of system data throughout its entire lifecycle, the following explanation will be combined with the global methodology.

[0171] Figure 4 This is a flowchart of a three-element linkage execution method for invoking in-vehicle intelligent agent tools, provided by an embodiment of the present invention. For example... Figure 4 As shown, the method of the present invention exemplarily includes the following steps:

[0172] S1: Receive user natural language requests, system event requests, or inter-agent delegation requests from the access port, and parse them to obtain the calling entity identifier and target tool parameters of the request.

[0173] S2: Parse the original semantics of the call request, convert it into a machine-readable structured representation, and then generate a target state change vector composed of multiple vehicle domain state change dimensions.

[0174] S3: Acquire and aggregate vehicle physical state, external environment state, driver and occupant state, system resource state, and historical operation sequences to construct a current context dataset containing multi-dimensional features. It should be noted that in step S3, the acquisition action is not strictly limited to synchronous polling at a specific time sequence. As some specific implementation examples, the system can acquire the above vehicle context data in the following ways: synchronous acquisition triggered in real time based on the current call request; or, asynchronously received underlying push data via subscribing to the vehicle communication bus (such as CAN, vehicle Ethernet); or, reading state snapshot data pre-collected and continuously updated in the local shared memory / cache pool by the background daemon process. The data acquisition mechanism of this invention covers all the above-mentioned time-series forms, as long as valid data is extracted when assembling the context dataset.

[0175] S4: Using the above-mentioned calling entity identifier, target tool parameters, target state change vector, and current context dataset as joint input variables, perform dynamic permission determination based on rules and context boundaries.

[0176] S5: If the permission determination result is a direct denial, a denial instruction set is generated to block the execution chain of the call request, the denial basis is output synchronously, and the interception event is written to the audit log.

[0177] S6: If the permission determination result is an allowed state or a conditional allowed state, then the target state change vector and the context dataset are input into the preset consequence simulation model to perform a forward-looking physical and logical risk deduction before the underlying action is actually issued.

[0178] S7: Based on the multi-dimensional indicators such as risk score, risk category and confidence level within the inference time window output by the model, risk classification is performed in combination with the preset strategy library.

[0179] S8: If the risk score is lower than the preset first risk threshold (i.e., it is determined to be a safe domain) after numerical comparison, a direct execution path is generated directly according to the original semantics.

[0180] S9: If the risk score is higher than or equal to the first risk threshold but lower than the absolute prohibition threshold, and there is a security variant in the system that can retain the user's target, extract the target tool parameters and perform a policy rewrite operation to generate an alternative execution path after flexible degradation.

[0181] S10: After generating the single-agent execution path, the system implements concurrent monitoring. If multiple agents make concurrent requests, a topological conflict graph is constructed based on the target state change vectors corresponding to each request, and structural pruning is performed according to the graph node and edge attributes to coordinate resources and calculate the final plan.

[0182] S11: After the above-mentioned traffic splitting and concurrent arbitration, the final execution plan, conditional execution plan, alternative execution plan or final rejection plan is output to the downstream underlying vehicle execution gateway.

[0183] S12: Extract the semantic decision structure and underlying physical consequence record of the processing flow, encapsulate it as a chain of evidence of running behavior and write it into the local isolated audit ledger block, and when the frequency of high risk is counted and meets the preset overflow condition, generate a communication message and report it to the external security monitoring platform.

[0184] To further reveal the technical advantages of this invention in preventing 'semantic drift' within the system and achieving automotive-grade safety traceability, based on Figure 5 As shown, based on the method processing flow introduced in the previous text examples, the data and evidence flow architecture is further explained from the perspective of underlying data interaction.

[0185] like Figure 5 As shown, the data and evidence flow of the present invention preferably includes the following objects: original request object, subject identity and session object, target state change vector object, context snapshot object, risk assessment object, alternative execution plan object, decision result object, and operational behavior evidence chain ledger object.

[0186] The original request object, subject, and session object serve as the starting point of the data flow, carrying external non-standardized trigger sources and identity credentials. The intent result transformed from the original request forms a target state change vector object, serving as a structured feature matrix connecting upstream and downstream processes. The context snapshot object is generated by fusing real-time vehicle state snapshots with environment / occupant / resource snapshots, providing static and dynamic boundary constraints. The consequence simulation record object and risk assessment object are dynamically calculated based on the aforementioned vectors and snapshots, carrying physical security inference indicators. The permission determination record object is used to synthesize intermediate authorization state credentials generated from preceding objects. The alternative execution plan object generates machine-readable execution messages based on a flexible rewrite strategy when a risk is triggered. The semantic decision record object and physical consequence record object respectively carry the final state data of control plane logic and data plane electromechanical feedback. The operational behavior evidence chain ledger object serves as the physical endpoint of the system data flow.

[0187] refer to Figure 5 As can be seen from the topological flow, the target state change vector object, as the core intermediate object throughout the entire process, is input in parallel to the permission determination and consequence simulation stages. This ensures that intent parsing, permission adjudication, risk simulation, and execution orchestration are all strictly coordinated around the same structured object. This innovative data architecture fundamentally avoids the decision drift and control failures caused by each functional module using its own semantic tags or inconsistent data standards in existing technologies.

[0188] Furthermore, by constructing a ledger object for the chain of evidence of operational behavior, embodiments of the present invention achieve unified and persistent storage of the aforementioned request semantics, context snapshots, risk assessments, policy rewriting, execution results, and recovery conditions. This not only provides native data support for policy upgrades and responsibility attribution within the system, but also forms a standardized and connectable interface with the consistency verification system of the upper-layer delivery declaration evidence chain, effectively solving the burden of proof problem in the control process of autonomous driving intelligent agents.

[0189] To enable those skilled in the art to more intuitively understand the collaborative working principle and technical effects of the above-mentioned system architecture, method flow and core data objects (especially the target state change vector and the evidence chain of running behavior) in real complex automotive-grade scenarios, four typical application embodiments are listed below.

[0190] These embodiments demonstrate how the control gateway of the present invention transforms abstract semantic intents into secure underlying physical actions from four dimensions: flexible rewriting of a single request, secure decomposition of cross-domain linkage, arbitration of concurrent conflicts among multiple agents, and global circuit breaking of continuous abnormal behavior.

[0191] Example 1: Comfort Domain Request Rewriting in Fatigue Driving Scenarios

[0192] When a driver is driving at high speed at night and their fatigue score increases, they can request via voice to open all the windows and adjust the seat to massage mode.

[0193] The intent parsing module generates a target state change vector and identifies that the request involves window, seat, and comfort domain enhancement actions; the context convergence module simultaneously obtains nighttime, rainfall, vehicle speed, lane keeping status, and driver fatigue features; the permission determination module determines that the subject has general control permissions over the relevant tools, but the consequence simulation module predicts that the combined actions will reduce driver attention stability and cabin safety.

[0194] Based on this, the system assessed the request as high-risk but rewriteable. The request was rewritten as follows: windows will only be opened 10% for ventilation, the massage function will be delayed until the vehicle comes to a complete stop or exits the highway, and a prompt will be given asking whether to switch to wakefulness assist mode. Finally, the system outputs an alternative execution plan and incorporates the before-and-after comparison, risk explanation, and execution results into the operational behavior evidence chain.

[0195] The above embodiment 1 demonstrates how the present invention can achieve flexible degradation of a single agent's request when faced with abnormal physiological state of the driver through the consequence simulation and policy rewriting module.

[0196] Example 2: Chain-linked access control system connecting entry system, body system, and chassis movement

[0197] When the vehicle is parked on a slope, the user requests that the tailgate be opened, the rear seats be folded down, the parking brake be released, and the vehicle be moved forward half a meter.

[0198] The intent parsing module identifies that the request will trigger the linkage of the entry domain, vehicle body domain, and chassis domain; the target state change vector indicates that there is a cross-domain state synchronous change; the consequence simulation module finds that if the combined action is performed under the conditions of a ramp and a tailgate open, it may cause objects to fall, passengers to become unstable, or the vehicle to skid.

[0199] The system breaks down the original combined actions into a step-by-step execution plan: first, keep the vehicle parked and only open the tailgate; after the rear area is checked to be safe, the tailgate is closed, and the occupants confirm, then proceed to the next stage of action; if the conditions are not met, the chassis action is blocked.

[0200] This approach avoids the problem of single-action authorization being approved but combined consequences being unacceptable, and writes the results of each decomposition step into the chain of evidence for operational behavior. Therefore, Example 2 effectively verifies the system's ability to decompose and orchestrate the execution of cross-domain composite requests from a single agent.

[0201] Example 3: Conflict Coordination under Concurrent Requests from Multiple Agents

[0202] The cockpit AI agent requests to switch to cinema mode, the welcoming AI agent requests to open the car door and adjust the ambient lighting, and the driver assistance AI agent requests to enter defensive driving alert mode due to risks ahead.

[0203] The multi-agent conflict coordination module constructs a conflict graph based on the target state change vector. It identifies that the cinema mode reduces the priority of driver assistance prompts and affects driver attention, while the welcoming gesture is incompatible with the current vehicle speed. Therefore, the system retains the driver assistance agent's request, rejects the welcoming request, and rewrites the cinema mode to only retain low-interference volume prompts and reduced visual display, thereby outputting a final plan that meets safety priorities and recording the conflict explanation and recovery conditions.

[0204] Example 3 effectively verifies the global arbitration capability of the present invention in resolving cross-domain concurrency and priority conflicts when multiple intelligent agents compete for control of the underlying layer at the same time.

[0205] Example 4: High-frequency abnormal requests trigger external security monitoring linkage

[0206] Within a predetermined time window, if the same entity repeatedly initiates multiple high-risk requests, such as frequently requesting to disable driver assistance systems, unlock hazardous functions, or trigger high-risk execution chains, the system will enter a safety intervention state multiple times. Afterward, it will report the current state summary, risk count, and evidence summary to an external monitoring platform and restrict access to certain high-risk tools until recovery conditions are met.

[0207] This fourth embodiment extends the invention from single-execution control to safe operation linkage under continuous abnormal behavior, with the abnormal event sequence and its handling results serving as an important part of the operational behavior evidence chain.

[0208] In summary, the three-element linkage execution method and system for invoking vehicle-mounted intelligent agents provided by this invention, through the progressive explanation of the above four typical embodiments, fully presents a comprehensive security defense architecture, from 'flexible degradation of instructions', 'chain decomposition of cross-domain composite actions', 'priority arbitration of multi-agent spatial concurrency' to 'global circuit breaking of high-risk time-series features'.

[0209] The architecture of the embodiments according to this application not only effectively breaks through the rigid blocking bottleneck of traditional vehicle security gateways, enabling a large number of intelligent agent requests that would otherwise be rejected to obtain a secure landing path; more importantly, this invention relies on the target state change vector object and the operational behavior evidence chain ledger object throughout the entire lifecycle to eliminate the semantic drift risk of natural language intent at the underlying physical execution layer. While preserving the continuity of AI intelligent agent business experience, it solidifies the absolute safety and accountability bottom line at the automotive grade.

[0210] This embodiment also provides a three-element linkage gateway system for invoking in-vehicle intelligent agent tools. It is mainly used to support all the operational logic steps of the three-element linkage execution method for invoking in-vehicle intelligent agent tools as described in any of the foregoing embodiments of the present invention from the underlying hardware architecture level. This includes, but is not limited to, dynamic permission determination, sandbox consequence simulation, alternative path generation, and underlying evidence chain solidification.

[0211] The three-element linkage gateway system for invoicing vehicle-mounted intelligent agent tools provided by the present invention includes: a request access and subject identification module, used to receive invoice requests and obtain the invoicing subject identifier and target tool parameters of the invoice request; an intent parsing and target state change vector generation module, used to parse the original semantics of the invoice request and generate a target state change vector composed of multiple vehicle domain state change dimensions; a context aggregation module, used to assemble the acquired vehicle state data, environmental state data, personnel state data, resource state data, and historical operation sequences into a current context dataset; an authorization determination module, used to dynamically determine authorization using the invoicing subject identifier, target tool parameters, target state change vector, and current context dataset as joint input variables, and output the determination result; and a risk assessment and classification module, used for determining... When the result is an allowed state or a conditional allowed state, the target state change vector and the current context dataset are input into a preset consequence simulation model, and the risk assessment result within the simulation time window is output. The risk assessment result includes a risk score. The strategy rewriting and alternative execution module is used to compare the risk score with a preset first risk threshold and a prohibited execution threshold: if the risk score is less than the first risk threshold, a direct execution path is generated according to the original semantics; if the risk score is greater than or equal to the first risk threshold and less than the prohibited execution threshold, the target tool parameters are extracted and a rewriting operation is performed to generate an alternative execution path carrying new triggering conditions and modified action parameters. The strategy rewriting and alternative execution module is used to generate a rejection instruction set and block the execution link of the call request when the judgment result is a direct rejection state, or when the risk score is greater than or equal to the prohibited execution threshold.

[0212] Physically, this system can be integrated into the vehicle's Central Computing Platform, Autonomous Driving Domain Controller (ADCU), or a standalone Security Gateway module. The system includes a processor and memory interconnected via hardware bus connections (e.g., PCIe, automotive Ethernet, or CAN-FD bus). The processor can be a general-purpose central processing unit (CPU), microprocessor (MCU), digital signal processor (DSP), application-specific integrated circuit (ASIC), or system-on-a-chip (SoC). In this embodiment, when the processor reads and executes the computer program instruction code, it drives the system hardware circuitry to implement the instruction timing control flow of the aforementioned intent-permission-consequence linkage gateway and three-element linkage execution method for in-vehicle intelligent agent tool invocation. Specifically, to meet automotive-grade security audit and anti-tampering requirements, the memory (e.g., eMMC, UFS flash memory, or EEPROM) includes pre-divided independent non-volatile memory partitions with read-only attributes at the physical or logical level. This partition is built on a Trusted Execution Environment (TEE) or hardware isolation technology (such as TrustZone) and is specifically used to permanently store the chain of evidence data blocks and audit ledger blocks generated by the aforementioned methods.

[0213] This embodiment also provides a three-element linkage gateway system for invoking vehicle-mounted intelligent agents, comprising: a memory for storing pre-compiled computer program instruction code, the memory including an independent non-volatile storage partition with read-only attributes for permanently storing the audit ledger block; and a processor connected to the memory via a hardware bus, wherein when the processor reads and executes the computer program instruction code, it drives the system hardware circuit to fully implement all the operational logic steps of the three-element linkage execution method for invoking vehicle-mounted intelligent agents as described in any of the foregoing embodiments of the present invention, including but not limited to dynamic permission determination, sandbox consequence simulation, alternative path generation, and underlying evidence chain solidification.

[0214] This embodiment also provides a computer-readable storage medium on which a sequence of computer-executable instructions is physically inscribed. The storage medium can be a tangible, non-volatile medium, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk, or it can be a flash memory chip embedded within a vehicle's microcontroller unit.

[0215] When the computer-executable instruction sequence is loaded into the operating environment of the vehicle's main control device, and is read and sent to the instruction register for decoding and execution during the fetch cycle of the computer processor microarchitecture, it can drive the underlying hardware circuit of the main control device to fully implement all the operational logic steps of the three-element linkage execution method for in-vehicle intelligent agent tool invocation described in any of the foregoing embodiments of the present invention, including but not limited to dynamic permission determination, sandbox consequence simulation, alternative path generation, and underlying evidence chain solidification.

[0216] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A three-element linkage execution method for invoking in-vehicle intelligent agent tools, characterized in that, Includes the following steps: Receive a call request and obtain the call subject identifier and target tool parameters of the call request; Parse the original semantics of the call request to generate a target state change vector composed of multiple vehicle domain state change dimensions; The acquired vehicle status data, environmental status data, personnel status data, resource status data, and historical operation sequences are assembled to form the current context dataset; The caller identifier, the target tool parameters, the target state change vector, and the current context dataset are used as joint input variables for dynamic permission determination, and the determination result is output. When the determination result is an allowed state or a conditional allowed state, the target state change vector and the current context dataset are input into a preset consequence simulation model, and the risk assessment result within the simulation time window is output, the risk assessment result includes a risk score; The risk score is compared numerically with a preset first risk threshold and a prohibited execution threshold: If the risk score is less than the first risk threshold, a direct execution path is generated according to the original semantics; If the risk score is greater than or equal to the first risk threshold and less than the prohibited execution threshold, the target tool parameters are extracted and a rewrite operation is performed to generate an alternative execution path carrying new triggering conditions and modified action parameters; When the determination result is a direct rejection, or when the risk score is greater than or equal to the prohibition threshold, a rejection instruction set is generated and the execution chain of the call request is blocked.

2. The method according to claim 1, characterized in that, The method further includes: Detect concurrent call requests within a predetermined time period. If multiple concurrent call requests are detected, a topology conflict graph is generated based on the target state change vector corresponding to each concurrent call request. The graph structure is pruned according to the node and edge attributes in the topology conflict graph. The request node parameters that have not been pruned are assembled with the direct execution path or the alternative execution path to form the final execution plan. If no multiple concurrent call requests are detected, the generated direct execution path or the alternative execution path will be used as the final execution plan.

3. The method according to claim 2, characterized in that, The method further includes: The underlying action message containing the final execution plan is sent to the vehicle's underlying execution node, and the semantic decision structure that records the processing flow and the physical consequences recorded by the underlying execution node are encapsulated and spliced ​​into a running behavior evidence chain data block, which is then written into a locally isolated read-only audit ledger block.

4. The method according to claim 1, characterized in that, The target state change vector contains a sequence of numerical parameters in the following dimensions: The physical state dimension is used to characterize the physical quantities of the expected action direction and the action amplitude. The permission status dimension is used to characterize the level code of the call request accessing a high-sensitivity system interface, a cross-physical domain control interface, or a control takeover interface; The timing dimension is used to represent the clock information for action message delivery and the condition triggering logic identifier; The impact domain dimension is used to characterize the potential impact of this action on the driving safety domain, comfort domain, access domain, vehicle body domain, payment domain, and cloud service domain. The chain reaction dimension is used to characterize whether the action is likely to trigger further automatic actions, responses from other intelligent agents, or cascading device linkages.

5. The method according to claim 1, characterized in that, The dynamic permission determination, which uses the calling entity identifier, the target tool parameters, the target state change vector, and the current context dataset as joint input variables, and outputs the determination result, includes: Determine whether the calling entity has the right to invoke the tool; Determine whether the state change meets the acceptable conditions in the current context; wherein the context includes: current vehicle operating state; driver state; occupant state; environmental state; equipment and resource state; and one or more of the historical operation sequences, wherein... Passenger status includes one or more of the following: type of passenger, passenger distribution, and passenger entry intention; The historical operation sequence includes one or more of the following: continuous request frequency, result of the previous action, continuous failure cases, and abnormal interaction patterns.

6. The method according to claim 1, characterized in that, The step of inputting the target state change vector and the current context dataset into a preset consequence simulation model and outputting the risk assessment results within the extrapolation time window includes: Based on simulation results and policy library thresholds, requests are categorized into multiple risk levels, including low risk, medium risk, high risk, and execution prohibited risk; furthermore, access control decisions are optimized according to the following principles: Low-risk requests can be executed directly; For medium-risk requests, additional explanations or confirmations can be added before execution. High-risk requests are given priority in the process of rewriting alternative execution paths; Prohibit execution of risky requests. If there is no feasible alternative execution path, the request will be rejected, and the reason for rejection will be output.

7. The method according to claim 1, characterized in that, The alternative execution paths include at least one or more of the following: Parameter reduction is used to generate the reduced control parameters; Tool replacement is used to replace high-privilege action objects with alternative executors that have preset security attributes; Step-by-step execution is used to process the original control request into a time-sequenced execution sequence that includes intermediate verification nodes; Timing delay is used to suspend the current control request until the vehicle's dynamic physical parameters meet the preset safety release conditions. Mode switching is used to reduce the running state to a preset high constraint level; Conditional binding is used to force at least one verification node to be chained together in the action execution path, thus constructing closed-loop admission logic before execution.

8. The method according to claim 2, characterized in that, The step of pruning the graph structure based on the node and edge attributes in the topological conflict graph, and assembling the parameters of the request nodes that were not pruned with the direct execution path or the alternative execution path into a final execution plan, includes: Set the underlying action opcode corresponding to each concurrent call request as the node set of the topology conflict graph; Extract the hardware resource usage mutual exclusion bit, the pre- and post-timing time dependency identifiers, and the process priority value between each concurrent call request, and assign the connection between each node as a weight attribute parameter. Based on the weight attribute parameters, a graph traversal calculation is performed on the topology conflict graph. Request nodes whose process priority values ​​are low and trigger the hardware resource occupation mutual exclusion representation bit are stripped and moved into the degradation cache pool or rejection cache pool. The remaining request nodes are moved into the executable action cache pool. The action opcodes in the executable action cache pool are superimposed and merged with the instruction execution timing in the direct execution path or the alternative execution path along the system clock axis.

9. A gateway system for the three-element linkage of in-vehicle intelligent agent tool invocation, characterized in that, The system includes: The access request and subject identification module is used to receive the call request and obtain the call subject identifier and target tool parameters of the call request; The intent parsing and target state change vector generation module is used to parse the original semantics of the call request and generate a target state change vector composed of multiple vehicle domain state change dimensions. The context aggregation module is used to assemble the acquired vehicle status data, environmental status data, personnel status data, resource status data, and historical operation sequences into the current context dataset. The permission determination module is used to dynamically determine permissions by taking the calling entity identifier, the target tool parameters, the target state change vector, and the current context dataset as joint input variables, and output the determination result. The risk assessment and classification module is used to input the target state change vector and the current context dataset into a preset consequence simulation model when the judgment result is an allowable state or a conditional allowable state, and output the risk assessment result within the simulation time window, wherein the risk assessment result includes a risk score. The strategy rewriting and alternative execution module is used to compare the risk score with a preset first risk threshold and a prohibited execution threshold. If the risk score is less than the first risk threshold, a direct execution path is generated according to the original semantics; If the risk score is greater than or equal to the first risk threshold and less than the prohibited execution threshold, the target tool parameters are extracted and a rewrite operation is performed to generate an alternative execution path carrying new triggering conditions and modified action parameters; The strategy rewriting and alternative execution module is used to generate a set of rejection instructions and block the execution chain of the call request when the determination result is a direct rejection state, or when the risk score is greater than or equal to the prohibition execution threshold.

10. A three-element linkage gateway system for invoicing in-vehicle intelligent agent tools, characterized in that, include: A memory for storing pre-compiled computer program instruction code, the memory comprising independent non-volatile storage partitions divided into read-only attributes for permanently storing the audit ledger blocks; The processor establishes a hardware bus connection with the memory. When the processor reads and executes the computer program instruction code, it drives the system hardware circuit to implement the instruction timing control flow of the three-element linkage execution method for invocation of vehicle-mounted intelligent agent tools as described in any one of claims 1 to 9.

11. A computer-readable storage medium having a sequence of computer-executable instructions physically inscribed thereon, characterized in that, When the computer-executable instruction sequence is read by the computer processor during its instruction fetch cycle and sent to the instruction register, it implements all the operational logic steps of the three-element linkage execution method for calling vehicle-mounted intelligent agent tools as described in any one of claims 1 to 10.

Images