Intention graph-based ai behavior chain tracing method, device, equipment and medium

Abstract

This application relates to a method, apparatus, device, and medium for tracing AI behavior chains based on intent graphs. The method includes: monitoring execution events generated when an AI system performs intent graph-driven tasks; generating a behavior record for each captured execution event, the behavior record containing an intent graph node identifier, event type, event payload, timestamp, and a cryptographic hash value calculated based on the hash value of the preceding record; appending the behavior records to a behavior chain in chronological order to form a one-way verifiable cryptographic hash chain; constructing a Merkle tree from the hash values ​​of all records in the behavior chain upon completion of intent or contract execution, and writing the Merkle root hash to immutable storage; responding to an audit query request, returning the corresponding complete behavior chain and Merkle verification path using the intent graph node identifier as the primary key. This method enables cryptographically-level trusted tracing and auditing of AI behavior, meeting regulatory compliance requirements.

Description

Technical Field

[0001] This application relates to the field of AI large model technology, and in particular to an AI behavior chain tracing method, apparatus, device and medium based on intent graph. Background Technology

[0002] As artificial intelligence systems evolve from simple dialogue tools into complex systems capable of calling external tools, delegating to sub-AI agents, and driving drones and robots to perform physical tasks, the traceability of AI behavior has evolved from an academic issue into a rigid requirement for engineering implementation and legal compliance. Currently, mainstream AI execution systems typically use traditional logging systems, blockchain-based evidence storage solutions, or audit logs specific to each AI platform to record system operation status. Traditional logging systems track system behavior by recording system calls and API requests; blockchain-based evidence storage solutions utilize the immutability of distributed ledgers to preserve evidence of critical transactions; and existing AI platforms (such as various large-scale model service platforms) provide audit logs in proprietary formats to record basic information about individual API calls.

[0003] However, each of the aforementioned existing technical solutions has fundamental flaws. Traditional log systems have coarse-grained recording, lack semantic information, and cannot be structurally correlated with the user's original intent; log files themselves can be modified, lacking cryptographic immutability and thus difficult to serve as credible audit evidence. Blockchain-based evidence storage solutions suffer from high on-chain confirmation latency, with writing costs increasing linearly with data size, making them unsuitable for real-time recording of high-frequency AI behaviors; furthermore, they only store transaction hashes on-chain, lacking structured intent graph information, and cannot achieve precise behavior tracing at the intent level. Existing AI platform audit logs use platform-specific formats, recording only information at the single API call level, failing to trace cross-platform, cross-AI agent delegation execution chains, lacking correlation with user intent structures, and unable to automatically reconcile resource budget declarations with actual consumption before task execution. Summary of the Invention

[0004] Therefore, it is necessary to provide an AI behavior chain tracing method, device, equipment, and medium based on intent graphs to address the aforementioned technical problems. This aims to solve the technical issues in existing technologies, such as untraceable AI behavior, decoupling of intent and behavior, broken multiple AI delegation chains, inability to automatically reconcile accounts, and failure to meet regulatory requirements.

[0005] An AI behavior chain tracing method based on intent graphs, the method comprising: Monitor execution events generated when the AI ​​system performs intent-driven tasks; the execution events include at least one of intent submission, task compilation, tool invocation, resource consumption, task completion, and task failure.

[0006] For each captured execution event, a behavior record is generated; the behavior record includes the intent graph node identifier corresponding to the execution event, the execution event type, the structured data payload of the execution event, the event timestamp, and the cryptographic hash value of this record calculated based on the hash value of the preceding behavior record.

[0007] The generated behavior records are appended to the behavior chain of the corresponding intent or contract in chronological order. The preceding hash field of each record references the hash value of the preceding record, so that any subsequent modification of any record in the behavior chain can be detected.

[0008] When an intent or contract is executed, a Merkle tree is constructed from the hashes of all records in the behavior chain, and the Merkle root hash is written to immutable storage.

[0009] In response to an audit query request, return the corresponding complete behavior chain and Merkle verification path with the intent graph node identifier as the primary key.

[0010] In one embodiment, the behavior record further includes an input modality source field that triggers the execution event; the input modality source field identifies the user input modality type that triggers the intent node, including at least one of voice input, graphic drawing, scene form, block assembly, and trajectory drawing; the method further includes: filtering and statistically analyzing the behavior record according to the input modality source during audit queries.

[0011] In one embodiment, the method further includes: when the AI ​​system delegates a subtask to another AI execution entity in a nested contract manner, recording the identifier of the parent contract in the behavior record of the subcontract; responding to an audit query request with the root contract identifier as the entry point, recursively traversing and returning the behavior chain data of all levels in the complete delegation tree, and restoring the complete execution path of multi-level AI collaboration in a single view.

[0012] In one embodiment, the method further includes: summarizing the actual consumption of resource consumption type event records from the behavior chain and comparing them item by item with the resource budget declared before the task started; when the actual consumption of any resource item exceeds the declared budget, generating a breach of contract behavior record and adding it to the behavior chain; the breach of contract behavior record includes the breached resource type, the amount of excess, and the specific behavior record identifier that triggered the breach.

[0013] In one embodiment, the cryptographic hash value of the behavior record is expressed by the formula:

[0014] Where Hash is a cryptographic hash function, record_id is a globally unique identifier for the behavior record, intent_node_id is the intent graph node ID that triggered this behavior, event_type is the event type, payload is the event payload data, timestamp is the event timestamp, and prev_hash is the cryptographic hash value of the preceding behavior record; any tampering with any record in the behavior chain will cause a change in record_hash and cause the verification of prev_hash of subsequent records to fail.

[0015] In one embodiment, when constructing the Merkle tree, the cryptographic hash values ​​of all action records of the current execution are used as leaf nodes, and the generated Merkle root hash is the unique verifiable digest of the intent execution; during auditing, the verifier obtains the Merkle root hash and the corresponding Merkle path, and verifies the authenticity of any single action record in logarithmic time complexity.

[0016] In one embodiment, the steps of responding to a single record independent verification request based on a Merkle path include: receiving a target behavior record identifier and a Merkle path provided by the querying party, recalculating the Merkle root hash and comparing it with the anchor value in immutable storage, and outputting a verification result as to whether the record has been tampered with.

[0017] An AI behavior chain tracing device based on intent graphs, the device comprising: The behavior recording module is configured to generate behavior records for each atomic execution event generated during the execution of an intent graph-driven task by the AI ​​system. The behavior record includes at least: the intent graph node identifier that triggered the execution event, the execution subject identifier, the event type, the event payload data, the timestamp, the cryptographic hash value of the preceding behavior record, and the cryptographic hash value of this record calculated based on the above fields.

[0018] The behavior chain building module is configured to arrange behavior records corresponding to the same intent or contract in chronological order, with the preceding hash field of each record containing the hash value of the preceding record, forming a one-way verifiable cryptographic hash chain.

[0019] The integrity anchoring module is configured to construct a Merkle tree from the hash values ​​of all behavior records of the execution when the intent or contract is completed, generate a Merkle root hash as a unique integrity summary of the execution, and write it to immutable storage.

[0020] The audit query interface is configured to accept audit requests with intent graph node identifiers or contract identifiers as the query primary key, and return the corresponding complete behavior chain data and Merkle verification path, enabling the querying party to independently verify the authenticity of any behavior record locally.

[0021] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program performing the following steps: Monitor execution events generated when the AI ​​system performs intent-driven tasks; the execution events include at least one of intent submission, task compilation, tool invocation, resource consumption, task completion, and task failure.

[0022] For each captured execution event, a behavior record is generated; the behavior record includes the intent graph node identifier corresponding to the execution event, the execution event type, the structured data payload of the execution event, the event timestamp, and the cryptographic hash value of this record calculated based on the hash value of the preceding behavior record.

[0023] The generated behavior records are appended to the behavior chain of the corresponding intent or contract in chronological order. The preceding hash field of each record references the hash value of the preceding record, so that any subsequent modification of any record in the behavior chain can be detected.

[0024] When an intent or contract is executed, a Merkle tree is constructed from the hashes of all records in the behavior chain, and the Merkle root hash is written to immutable storage.

[0025] In response to an audit query request, return the corresponding complete behavior chain and Merkle verification path with the intent graph node identifier as the primary key.

[0026] A computer-readable storage medium having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Monitor execution events generated when the AI ​​system performs intent-driven tasks; the execution events include at least one of intent submission, task compilation, tool invocation, resource consumption, task completion, and task failure.

[0027] For each captured execution event, a behavior record is generated; the behavior record includes the intent graph node identifier corresponding to the execution event, the execution event type, the structured data payload of the execution event, the event timestamp, and the cryptographic hash value of this record calculated based on the hash value of the preceding behavior record.

[0028] The generated behavior records are appended to the behavior chain of the corresponding intent or contract in chronological order. The preceding hash field of each record references the hash value of the preceding record, so that any subsequent modification of any record in the behavior chain can be detected.

[0029] When an intent or contract is executed, a Merkle tree is constructed from the hashes of all records in the behavior chain, and the Merkle root hash is written to immutable storage.

[0030] In response to an audit query request, return the corresponding complete behavior chain and Merkle verification path with the intent graph node identifier as the primary key.

[0031] The aforementioned AI behavior chain tracing method, device, equipment, and medium based on intent graphs precisely associate each execution event of the AI ​​system with the specific intent node that generated the execution, using the intent graph node ID as the primary key, thus achieving a structured binding of intent and behavior. A cryptographic hash chain structure is used to record the entire chain of behavior sequences from intent graph generation to execution completion, ensuring that any tampering of records can be detected. It supports the hierarchical association of behavior records across multiple AI delegation chains, restoring the complete delegation execution tree in a single behavior chain view. It enables automatic reconciliation between the budget declaration of contractual intents and actual resource consumption, generating structured default reports. A standardized audit query interface is provided, allowing regulators, delegators, and third parties to verify the execution behavior of any historical intent. This solves the technical problems of existing technologies, such as untraceable AI behavior, decoupling of intent and behavior, broken multiple AI delegation chains, inability to automatically reconcile accounts, and failure to meet regulatory requirements. Attached Figure Description

[0032] Figure 1 This is an application scenario diagram of an AI behavior chain tracing method based on intent graphs in one embodiment; Figure 2 This is a flowchart illustrating an AI behavior chain tracing method based on intent graphs in one embodiment. Figure 3 This is a structural block diagram of an AI behavior chain tracing device based on intent graphs in one embodiment. Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0034] The AI ​​behavior chain tracing method based on intent graphs provided in this application can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. Users submit intent tasks (such as drone spraying tasks, AI-assisted search and rescue tasks, etc.) through terminal 102. After receiving the intent task, server 104 executes the intent-driven task processing by the AI ​​system. During task execution, server 104 continuously monitors execution events, generates behavior records for each atomic execution event, maintains a cryptographic hash chain, and constructs a Merkle tree for integrity anchoring upon task completion. When a regulator, client, or third party needs to initiate an audit query request through terminal 102, server 104 responds by returning the corresponding complete behavior chain and Merkle verification path. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices, while server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0035] In one embodiment, such as Figure 2 As shown, an AI behavior chain tracing method based on intent graphs is provided, which can be applied to... Figure 1 Taking the server in the example, the following steps are included: Step 202: Listen for execution events generated when the AI ​​system performs intent-driven tasks.

[0036] As an AI system unfolds a task according to an intent map, it generates a series of discrete but causally related event nodes. The server listens to these nodes through an event bus or callback registration mechanism, capturing execution events that cover the entire lifecycle from user intent submission to task completion: intent submission signifies the user's intent entering the system; task compilation transforms the intent map into an executable sequence of instructions; tool calls record the interaction between the AI ​​and external tools or APIs; resource consumption tracks the use of resources such as tokens and computing power; and task completion and failure are marked with their respective execution results. This listening layer constitutes the raw input for all subsequent behavioral chain data.

[0037] Step 204: Generate a behavior record for each captured execution event.

[0038] The server converts each detected atomic event into a structured behavior record. The core fields of each record include: an intent graph node identifier, precisely linking the behavior to the intent node that triggered it; an event type, identifying the nature of the event; a structured data payload, carrying execution details such as tool parameters, return values, and resource consumption; a millisecond-level timestamp; and a cryptographic hash value calculated based on the hash value of the preceding record. This conversion step effectively establishes a one-to-one mapping between the physical facts of machine execution and auditable digital evidence.

[0039] Step 206: Append the generated behavior records to the behavior chain of the corresponding intent or contract in chronological order.

[0040] The system maintains independent behavior chains based on IntentContract or single intent submission. Behavior records are appended sequentially in chronological order, with each record's prev_hash pointing to the hash value of the preceding record, forming R1→R2→R3→…→R n The hash chain. If an attacker attempts to tamper with a middle record R... i Not only does it require recalculating R, i Its own hash must also be recalculated from R i Until the hashes of all records at the tail of the chain, otherwise R i+1 The prev_hash verification will fail. This makes the cost of tampering proportional to the chain length, providing an engineering-acceptable deterrent for integrity protection.

[0041] Step 208: When the intent or contract execution is completed, construct a Merkle tree from the hash values ​​of all records in the behavior chain and write the Merkle root hash into immutable storage.

[0042] When constructing the Merkle tree, the hash values ​​of all actions recorded in this execution are used as leaf nodes. The hashes of parent nodes are calculated layer by layer from the bottom up until a unique root node is obtained. This root hash is a compact summary of all actions recorded in this execution. Its core value lies in the fact that any addition, deletion, or modification of a single record will cause a change in the root hash; therefore, the existence of the root hash provides an anchor point for integrity verification. The root hash is written to immutable storage, which can be a local append-only log or an external timestamp service, and simultaneously written to the contract completion record as proof of action integrity during settlement.

[0043] Step 210: Respond to the audit query request and return the corresponding complete behavior chain and Merkle verification path with the intent graph node identifier as the primary key.

[0044] The audit query interface accepts intent graph node identifiers or contract identifiers as query entry points and returns complete behavior chain data along with the corresponding Merkle verification path. Verifiers only need the Merkle root hash and the corresponding Merkle path to complete the verification of any single record in O(logn) time, without needing to obtain the complete behavior chain. This design strikes a balance between audit efficiency and privacy protection, allowing regulators to complete trusted verification without accessing the entire behavior log of the AI ​​system.

[0045] From an overall design perspective, the above steps constitute a well-structured audit evidence production pipeline. The monitoring layer captures physical events, the recording layer transforms events into structured digital evidence, the chain structure layer provides tamper-proof protection, the Merkle anchoring layer locks the protection into a publicly verifiable digest, and the query layer provides standardized access to the outside world. These five layers each perform independent functions while working closely together to achieve a complete transformation from machine execution to trusted auditing.

[0046] The aforementioned AI behavior chain tracing method based on intent graphs precisely associates each execution event of the AI ​​system with the specific intent node that generated the execution by using the intent graph node ID as the primary key, thus achieving a structured binding between intent and behavior. It employs a cryptographic hash chain structure to record the entire behavior sequence, ensuring that any tampering with any record can be detected. Through Merkle tree aggregation and root hash anchoring, it provides verifiable integrity proofs. Furthermore, it offers a standardized audit query interface, supporting verifiable backtracking queries. This method effectively solves the technical problems of untraceable AI behavior, decoupling of intent and behavior, inability to automatically reconcile accounts, and failure to meet regulatory requirements in existing technologies.

[0047] In one embodiment, the behavior log also includes an input modality source field (source_modality) that triggered the execution event. This input modality source field identifies the type of user input modality that triggered the intent node, including at least one of voice input, graphic drawing, scene form, block assembly, and trajectory drawing. Specifically, the source_modality field is used to trace the input source of the intent node.

[0048] For example, when a user submits an intent via voice input, the source_modality field is set to voice input; when a user submits an intent via graphical drawing (such as drawing a flight path on an electronic map), the source_modality field is set to graphical drawing; when a user submits an intent by filling out a scenario form (such as a drone spraying task form), the source_modality field is set to scenario form; when a user constructs an intent via block assembly (such as dragging and dropping graphical programming blocks), the source_modality field is set to block assembly; and when a user submits an intent via trajectory drawing (such as hand-drawing a motion trajectory), the source_modality field is set to trajectory drawing.

[0049] This also includes filtering and statistically analyzing behavior records based on the input modality source during audit queries. For example, regulators or clients can query all behavior records corresponding to intent nodes triggered by voice input, or statistically analyze task completion rates and resource consumption under different input modalities. This filtering and statistical analysis capability based on modality source enables the system to trace and analyze AI behavior in a more granular way, helping to identify the impact of different input modalities on AI execution behavior and providing data support for system optimization and regulatory compliance.

[0050] This embodiment introduces an input modality source field, realizing a complete traceability chain from AI execution behavior to the user's original input modality. This fills the gap in the existing technology for the ability to trace the modality source and provides a technical foundation for user experience optimization, modality adaptability analysis, and regulatory compliance.

[0051] In one embodiment, a mechanism for linking behavior records across multiple AI delegation chains (A2A nested contracts) is implemented. When an AI system delegates a subtask to another AI execution entity via a nested contract, the system records the identifier (parent_contract_id) of the parent contract in the behavior record of the subcontract.

[0052] Specifically, when AI-A delegates to AI-B, and AI-B delegates to AI-C to execute subtasks, the system maintains an independent BehaviorChain for each delegation level and establishes cross-chain associations through the parent_contract_id field: When the root contract (user → AI-A) records the DISPATCHED event in its behavior chain, the payload contains a list of subcontract contract_ids.

[0053] The parent_contract_id of the first record in the behavior chain of each subcontract points to the parent contract, forming a delegate tree structure that can be traced upwards.

[0054] When a subcontract fails to execute, the failure event (event_type=FAILED) propagates upwards along the parent_contract_id chain, and the root contract behavior chain automatically adds the CHILD_FAILED event, thus realizing the technical implementation of behavior record level for the hierarchical propagation of failure responsibility.

[0055] This also includes: responding to audit query requests with the root contract identifier as the entry point, recursively traversing and returning behavioral chain data for all levels in the complete delegation tree, and reconstructing the complete execution path of multi-layered AI collaboration in a single view. For example, in an AI collaborative search and rescue mission scenario, the user submits the search and rescue mission intent, the system creates a root contract C-ROOT, and AI-A is the executor. AI-A delegates a reconnaissance AI-B to perform a reconnaissance sub-task, creating a sub-contract CB (parent_contract_id=C-ROOT). After AI-B discovers the target, it delegates a rescue AI-C to approach the target, creating a sub-contract CC (parent_contract_id=CB). During post-audit, calling the query interface with C-ROOT as the root contract identifier returns a complete view of the three-layer behavioral chain, clearly showing the decision-making path: User → AI-A → AI-B → AI-C, and the specific behavioral records of each step.

[0056] The beneficial effects of this embodiment are as follows: by recursively associating the parent_contract_id field, it solves the fundamental problem of difficulty in tracing the attribution of responsibility in multi-AI collaboration scenarios, restores the complete delegation execution tree in a single query view, and fills the gap in the existing technology for cross-AI delegation chain tracing capabilities.

[0057] In one embodiment, a contract budget reconciliation function is involved, which automatically reconciles the budget with the IntentContract resource budget declaration. Specifically, the method includes the following steps: First, the actual consumption of resource consumption type event records is summarized from the behavior chain. During execution, each BehaviorRecord with event_type=RESOURCE_CONSUMED records the actual type and quantity of resources consumed, including but not limited to the number of tokens, computing power duration, power consumption, and data transmission volume.

[0058] Secondly, the resource budget is compared item by item with the resource budget declared before the task began. After the contract is executed, the system summarizes the resource consumption records of all behaviors in the contract chain, generates a ResourceConsumptionSummary, and compares it item by item with the budget declaration in IntentContract.resource_budget.

[0059] Finally, when the actual consumption of any resource item exceeds the declared budget, a default record is generated and appended to the behavior chain. The BudgetViolationRecord contains the default type (exceeding the Token budget / exceeding the time budget / exceeding the physical resource budget), the amount of excess, and the specific behavior record ID that triggered the default, event_type=VIOLATED. It is written to the behavior chain and the contract state is marked as VIOLATED.

[0060] For example, in a drone-based precision agriculture spraying task, the system creates an IntentContract with a budget declaration: flight distance ≤ 8km, power consumption ≤ 80%, and flight time ≤ 45 minutes. During flight, the system writes a resource consumption record every 30 seconds, recording the current cumulative flight distance and power consumption. After the task is completed, the system summarizes the actual consumption: flight distance 6.8km, power consumption 72%, and flight time 38 minutes. All three indicators are within the budget, and the contract status is marked as FULFILLED. If the actual flight distance exceeds 8km, the system generates a default record and marks the contract status as VIOLATED.

[0061] The beneficial effects of this embodiment are as follows: the resource reconciliation module extends the pre-contractual constraints of the contractual intent to a verifiable execution result after the fact, and the breach of contract record provides objective technical evidence for contract performance disputes, thus realizing a complete automated process for contract execution reconciliation.

[0062] In one embodiment, the method for calculating the cryptographic hash value of the behavior record is defined. The cryptographic hash value of the behavior record is calculated using the following formula: The meanings of each parameter are as follows: Hash: A cryptographic hash function, which can use standard cryptographic hash algorithms such as SHA-256 and SM3. Cryptographic hash functions are one-way and collision-resistant, ensuring that the original data cannot be derived from the record_hash, and the probability of different inputs producing the same hash value is negligible.

[0063] record_id: A globally unique identifier for behavior records, usually in UUID (Universally Unique Identifier) ​​format, to ensure that each behavior record has a unique identifier globally.

[0064] intent_node_id: The ID of the intent graph node that triggered this action, used to precisely associate the intent graph node defined in the action record.

[0065] event_type: Event type, enumerated values ​​include INTENT_SUBMITTED, COMPLETED, DISPATCHED, TOOL_CALLED, RESOURCE_CONSUMED, COMPLETED, FAILED, VIOLATED, etc.

[0066] Payload: Event payload data, structured data stored in JSON format, containing detailed information about the execution event such as tool name, parameters, return value, and resource consumption.

[0067] timestamp: The timestamp of the event, in ISO8601 format, with millisecond precision.

[0068] prev_hash: The cryptographic hash value of the preceding action record. For the first record in the action chain, prev_hash is an all-zero hash (e.g., 000…000).

[0069] Any alteration to a record in the action chain will result in a change to the record_hash, causing the verification of the prev_hash of subsequent records to fail. Specifically, since the calculation of each record's record_hash depends on the prev_hash of the preceding record, and the prev_hash is itself the record_hash of the preceding record, the entire action chain forms a cryptographic dependency where a change in one part affects the whole. If an attacker attempts to tamper with a historical record R... i The content must be recalculated from R at the same time. i The chain hashes are processed from the beginning to the end of the chain using the `record_hash` of all records; otherwise, the `prev_hash` verification of subsequent records will fail. This chain hash structure provides a cryptographic level of tamper-proof guarantee.

[0070] The beneficial effects of this embodiment are as follows: through a clear hash calculation formula, a standardized integrity protection mechanism is provided for behavior records, which provides a stronger integrity guarantee compared with traditional variable log systems, and can achieve high-frequency real-time recording without relying on blockchain.

[0071] In one embodiment, the construction method and verification mechanism of the Merkle tree are specifically defined.

[0072] When constructing the Merkle tree, the cryptographic hash values ​​(record_hash) of all action records in the current execution are used as leaf nodes. Specifically, for an execution process containing N action records, the system uses N record_hash values ​​as leaf nodes of the Merkle tree, and then calculates the parent node hash layer by layer upwards: every two adjacent leaf node hash values ​​are concatenated and then hashed to obtain the parent node hash of the next level; if the number of nodes in a certain level is odd, the last node is copied and concatenated with itself to calculate the parent node hash. This process is repeated until a unique root node hash, namely the Merkle root hash, is finally obtained.

[0073] The generated Merkle root hash is the unique verifiable digest of the intent execution. MerkleRoot has the following characteristics: (1) Uniqueness: Different action record sequences will inevitably produce different MerkleRoots; (2) Compactness: No matter how many records the action chain contains, MerkleRoot is always a hash value of fixed length; (3) Verifiability: The verifier can verify the authenticity of any single record without obtaining the complete action chain, based only on MerkleRoot and the corresponding Merkle path.

[0074] During auditing, the verifier obtains the Merkle root hash and the corresponding Merkle path, verifying the authenticity of any single action record in logarithmic time complexity (O(log n)). The specific verification process is as follows: The verifier provides the target action record and its record_hash, as well as the Merkle path from the leaf node to the root node (i.e., the hash values ​​of each sibling node on the path). The verifier uses the target record_hash and the hash values ​​of the sibling nodes on the Merkle path to recalculate the parent node hash layer by layer upwards, ultimately obtaining a new root hash value. This recalculated root hash is compared with the MerkleRoot anchored in immutable storage: if they match, it proves that the action record has not been tampered with and belongs to the Merkle tree; if they do not match, it proves that the record has been tampered with or does not belong to the execution process.

[0075] The beneficial effects of this embodiment are: the Merkle tree structure makes the integrity verification of large-scale behavior chains efficient and feasible. The verifier does not need to obtain and transmit the complete behavior chain, but only needs to obtain the MerkleRoot and the Merkle path of O(log n) length to complete the verification, which greatly reduces the communication and computation overhead of audit verification.

[0076] In one embodiment, the specific steps for responding to a single record independent verification request based on a Merkle path are further defined.

[0077] The steps for responding to a single record independent verification request based on a Merkle path include: S1 receives the target behavior record identifier and Merkle path provided by the querying party.

[0078] Specifically, the system audit query interface receives a single record verification request initiated by the querying party. This request includes two necessary parameters: the target behavior record identifier (record_id) and the corresponding Merkle path (merkle_proof). The querying party can either have previously obtained the behavior chain information through the getChainByIntent or getChainByContract interface and then extracted the Merkle path of the specific record; or it can be an external verifier (such as a regulatory agency or third-party auditing firm) that has obtained the Merkle path through other means.

[0079] S2 outputs the verification result of whether the record has been tampered with by recalculating the Merkle root hash and comparing it with the anchor value in the immutable storage.

[0080] Specifically, the system retrieves the complete data of the target behavior record, including its record_hash, from storage based on the identifier of the target behavior record provided by the querying party. Then, using this record_hash and the Merkle path provided by the querying party, the system recalculates the hash of the parent node layer by layer upwards, ultimately obtaining a new root hash value. The system compares this recalculated root hash with the pre-anchored MerkleRoot in immutable storage.

[0081] If both are consistent, the system returns True (or verification passes), proving that the behavior record has not been tampered with since anchoring and does indeed belong to the execution process corresponding to the Merkle tree.

[0082] If the two are inconsistent, the system returns False (or verification fails), proving that the behavior record has been tampered with, or that the record does not belong to the execution process (i.e., the querying party provided an incorrect record or an incorrect Merkle path).

[0083] It is worth emphasizing that the core advantage of this verification process lies in the fact that the verifier does not need to obtain the complete behavioral chain; verification can be completed with only the target record itself and the Merkle path. This means that regulatory agencies can independently verify the authenticity of a specific behavioral record without accessing the complete behavioral logs of the AI ​​system, thus protecting the commercial privacy of the AI ​​system (without disclosing all behavioral logs) while meeting the verification requirements of compliance audits.

[0084] The beneficial effects of this embodiment are as follows: the independent verification mechanism for a single record provides an efficient and privacy-protected verification method for regulatory auditing, fills the gap in the lack of real-time verification capabilities in the prior art, and enables the verifier to complete trusted verification without obtaining the complete behavioral chain.

[0085] In one embodiment, the process of monitoring execution events also includes real-time anomaly detection during execution. When an inconsistency is detected between the hash chain of the current behavior record and the anchored intermediate hash value, the system immediately issues a behavior chain integrity alarm to the task delegator and inserts an alarm record of type INTEGRITY_ALERT into the behavior chain, recording the time point at which the inconsistency was detected and the inconsistent hash value, supporting execution interruption and post-event auditing.

[0086] Specifically, the system can periodically or at critical nodes during execution to verify the hash continuity of the behavior chain. For example, the system maintains a recently anchored intermediate state hash value. When a new behavior record is appended, it verifies whether the prev_hash of the new record is consistent with the record_hash at the current tail of the chain. If the verification fails, it indicates that the behavior chain may have been subjected to a tampering attack or that the system has encountered an anomaly, and the system immediately triggers an alarm mechanism.

[0087] The beneficial effect of this embodiment is that the real-time anomaly detection mechanism enables the system to detect and respond to attacks in a timely manner, rather than only discovering problems during post-event audits, thereby improving the security and reliability of the system.

[0088] The steps in the above embodiments are not necessarily executed sequentially according to the order of the arrows indicated in the flowchart. Unless otherwise expressly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the above embodiments may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0089] In one embodiment, such as Figure 3 As shown, an AI behavior chain tracing device based on intent graphs is provided, including: a behavior recording module, a behavior chain construction module, an integrity anchoring module, and an audit query interface. Among them: The behavior recording module is configured to generate behavior records for each atomic execution event generated during the execution of intent-driven tasks by the AI ​​system. The behavior record includes at least: the intent node identifier (intent_node_id) that triggered the execution event, the actor identifier (actor_id, identifying user ID / AI Agent ID / device ID), the event type (event_type), the event payload data, the timestamp, the cryptographic hash value of the preceding behavior record (prev_hash), and the cryptographic hash value of this record calculated based on the above fields (record_hash).

[0090] The BehaviorChain building module is configured to arrange behavior records corresponding to the same intent or contract in chronological order. The preceding hash field of each record contains the hash value of the preceding record, forming a one-way verifiable cryptographic hash chain (BehaviorChain).

[0091] The integrity anchoring module is configured to construct a Merkle tree from the hash values ​​of all behavior records of the execution when the intent or contract is completed, generate a Merkle root hash as a unique integrity summary of the execution, and write it to immutable storage.

[0092] The audit query interface is configured to accept audit requests with intent graph node identifiers or contract identifiers as the query primary key, and return the corresponding complete behavior chain data and Merkle verification path, enabling the querying party to independently verify the authenticity of any behavior record locally.

[0093] In one embodiment, the audit query interface also supports the following standardized query functions: getChainByIntent(intent_id): Returns the complete chain of behaviors corresponding to the intent based on the intent ID, including all BehaviorRecords.

[0094] getChainByContract(contract_id): Returns the behavior chain and MerkleRoot of the contract based on the contract ID.

[0095] getFullDelegationTree(root_contract_id): Returns a recursively expanded view of the complete delegation tree behavior chain based on the root contract ID.

[0096] verifyRecord(record_id, merkle_proof): Verifies whether a record has not been tampered with based on the record ID and the Merkle path.

[0097] getResourceSummary(contract_id): Returns a summary of resource consumption and budget reconciliation results based on the contract ID.

[0098] getViolationReport(contract_id): Returns details of the violation record based on the contract ID.

[0099] queryByTimeRange(start, end, actor_id): Returns all behavior records of the specified subject within the specified time range.

[0100] All query interfaces return data in standard JSON format, along with MerkleRoot and verification path, allowing the querying party to independently verify data integrity locally without needing to trust the query service itself.

[0101] Specific limitations regarding the intent graph-based AI behavior chain tracing device can be found in the limitations of the intent graph-based AI behavior chain tracing method described above, and will not be repeated here. Each module in the aforementioned intent graph-based AI behavior chain tracing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0102] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data such as behavior records, behavior chains, Merkle trees, and Merkle root hashes. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements an intent-graph-based AI behavior chain tracing method.

[0103] Those skilled in the art will understand that Figure 4The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0104] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps in the above-described method embodiments.

[0105] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0106] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0107] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0108] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for tracing AI behavior chains based on intent graphs, characterized in that, The method includes: Monitor execution events generated when the AI ​​system performs intent-driven tasks; the execution events include at least one of intent submission, task compilation, tool invocation, resource consumption, task completion, and task failure; For each captured execution event, a behavior record is generated; the behavior record includes the intent graph node identifier corresponding to the execution event, the execution event type, the structured data payload of the execution event, the event timestamp, and the cryptographic hash value of this record calculated based on the hash value of the preceding behavior record; The generated behavior records are appended to the behavior chain of the corresponding intent or contract in chronological order. The preceding hash field of each record references the hash value of the preceding record, so that any subsequent modification of any record in the behavior chain can be detected. When an intent or contract is executed, a Merkle tree is constructed from the hash values ​​of all records in the behavior chain, and the Merkle root hash is written to immutable storage. In response to an audit query request, return the corresponding complete behavior chain and Merkle verification path with the intent graph node identifier as the primary key.

2. The method according to claim 1, characterized in that, The behavior record also includes an input modality source field that triggered the execution event; The input modality source field identifies the type of user input modality that triggered the intent node, including at least one of voice input, graphic drawing, scene form, block assembly, and trajectory drawing. The method also includes filtering and statistically analyzing behavior records based on the source of the input modality during audit queries.

3. The method according to claim 1, characterized in that, Also includes: When an AI system delegates a subtask to another AI execution entity in a nested contract manner, the identifier of the parent contract is recorded in the behavior record of the subcontract; Responding to audit query requests that use the root contract identifier as the entry point, it recursively traverses and returns the behavior chain data of all levels in the complete delegation tree, reconstructing the complete execution path of multi-level AI collaboration in a single view.

4. The method according to claim 1, characterized in that, Also includes: The actual consumption of resource consumption type event records is summarized from the behavior chain and compared item by item with the resource budget declared before the task started. When the actual consumption of any resource item exceeds the declared budget, a default behavior record is generated and added to the behavior chain; the default behavior record includes the default resource type, the amount of excess, and the specific behavior record identifier that triggered the default.

5. The method according to claim 1, characterized in that, The cryptographic hash value of the behavior record is expressed by the formula: Where Hash is a cryptographic hash function, record_id is a globally unique identifier for the behavior record, intent_node_id is the intent graph node ID that triggered this behavior, event_type is the event type, payload is the event payload data, timestamp is the event timestamp, and prev_hash is the cryptographic hash value of the preceding behavior record; any tampering with any record in the behavior chain will cause a change in record_hash and cause the verification of prev_hash of subsequent records to fail.

6. The method according to claim 1, characterized in that, When constructing the Merkle tree, the cryptographic hash values ​​of all action records of this execution are used as leaf nodes, and the generated Merkle root hash is the unique verifiable digest of this intention execution; During the audit, the verifier obtains the Merkle root hash and the corresponding Merkle path, and verifies the authenticity of any single behavior record in logarithmic time complexity.

7. The method according to claim 1, characterized in that, The steps for responding to a single record independent verification request based on a Merkle path include: The system receives the target behavior record identifier and Merkle path provided by the querying party, recalculates the Merkle root hash and compares it with the anchor value in immutable storage, and outputs the verification result of whether the record has been tampered with.

8. An AI behavior chain tracing device based on intent graphs, characterized in that, The system includes: The behavior recording module is configured to generate behavior records for each atomic execution event generated during the execution of an intent graph-driven task by the AI ​​system; the behavior record includes at least: the intent graph node identifier that triggered the execution event, the execution subject identifier, the event type, the event payload data, the timestamp, the cryptographic hash value of the previous behavior record, and the cryptographic hash value of this record calculated based on the above fields; The behavior chain building module is configured to arrange behavior records corresponding to the same intent or contract in chronological order, with the preceding hash field of each record containing the hash value of the preceding record, forming a one-way verifiable cryptographic hash chain; The integrity anchoring module is configured to construct a Merkle tree from the hash values ​​of all behavior records of the execution when the intent or contract is completed, generate a Merkle root hash as a unique integrity summary of the execution, and write it to immutable storage. The audit query interface is configured to accept audit requests with intent graph node identifiers or contract identifiers as the query primary key, and return the corresponding complete behavior chain data and Merkle verification path, enabling the querying party to independently verify the authenticity of any behavior record locally.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images