An agent behavior recording system and method based on specification event types

Abstract

The application discloses an agent behavior event standardization recording system, method, computer readable storage medium and computer program product. A standardized behavior event record is generated at a first agent entity, the record including an event type selected from seven canonical event types (TASK_INVOKED, TASK_COMPLETED, TASK_FAILED, TASK_TIMEOUT, QUALITY_RATED, DISPUTE_FILED, DISPUTE_RESOLVED), an entity identifier, an execution result, and when the event type is a quality assessment period event, a structured quality score object. A cross-platform event adapter maps events from heterogeneous protocols (MCP, A2A, platform internal) to a standardized schema. Event records are stored in an append-only hash chain after cryptographic signing, and the Merkle root is anchored to a public blockchain at regular intervals. The record supports a directed acyclic graph call causal chain with a parent task identifier; a trust anchor entity can provide a proxy signature verification for an agent runtime that does not support direct signing; and a chain storage module supports zero-knowledge proof verification. The application provides a verifiable, tamper-proof and interoperable behavior record for an autonomous agent ecosystem.

Description

Technical Field

[0001] This invention relates to the field of intelligent agent behavior data recording technology, specifically to a standardized, tamper-proof behavior event recording system and method for autonomous software intelligent agents in heterogeneous computing environments. Background Technology Technical Background

[0003] Autonomous software agents—including Large Language Model (LLM) based agents, Robotic Process Automation (RPA) robots, and multi-agent orchestration systems—are increasingly interacting across platforms, protocols, and trust boundaries. An agent on a platform (such as Coze) might invoke tools via Model Context Protocol (MCP), delegate subtasks to another agent via Agent-to-Agent (A2A) protocols, or execute workflows within a proprietary runtime. In all these scenarios, behavioral evidence is generated: who invoked whom, what result was produced, how long the execution took, and the level of satisfaction with the result.

[0004] Currently, there is no standardized mechanism for recording and verifying such behavioral data across these heterogeneous environments. Each platform maintains its own proprietary log format—if it does maintain logs at all—and the calling agent cannot independently verify the behavioral history of the called agent. This lack of verifiable behavioral data undermines trust in interactions between agents and hinders the construction of reliable reputation systems for autonomous agents.

[0005] Description of existing technology

[0006] AgentTrace (arXiv 2602.10133, February 2026) proposes an open structured logging standard for agent systems, defining a pattern-based protocol for recording cognitive, operational, and contextual trajectories. AgentTrace provides fields such as event ID, entity ID, timestamp, and event type, representing the closest existing technology in the field of structured agent event logging. However, AgentTrace is essentially a logging standard rather than a verifiable behavior recording system—it does not provide an event signing mechanism, cross-platform event adaptation, or tamper-proof chained storage, and its field definitions do not include structured quality score objects embedded with rater reputation. The differences between this invention and AgentTrace are: (a) AgentTrace records logs, while this invention records verifiable behavioral evidence; (b) AgentTrace does not define a complete event type classification covering the dispute resolution phase; and (c) AgentTrace's event format does not include quality scores and rater reputation metadata.

[0007] General-purpose structured logging frameworks (such as ELK Stack, Datadog, and Splunk) offer flexible log collection and analysis capabilities, but lack agent-specific semantics. These frameworks cannot distinguish between successfully completed tasks and tasks that time out but return an HTTP 200 status because they operate at the system event level rather than the agent task lifecycle event level. Furthermore, these frameworks do not provide quality scoring, reputation weighting, or tamper-proof storage mechanisms with cryptographic verification.

[0008] Microsoft Sentinel ASIM agent event schema provides a normalized schema for agent telemetry in a security context, including entity ID, event type, timestamp, and result fields. While useful for security information and event management, ASIM does not cover quality scoring, rater reputation, chained storage, or cross-platform event adaptation.

[0009] Appending hash chain storage alone for tamper-proof log recording is well-known in the field, with implementations including pametan / audit-log, Nexuscone, Provara Protocol, Hash-Chain Incident Record (HCIR), and Microsoft Agent Governance Toolkit. Similarly, hybrid off-chain storage combined with on-chain Merkle root anchoring is a widely documented pattern used in blockchain anchoring, Chainpoint, and numerous decentralized record-keeping systems. While effective, these storage mechanisms are general-purpose rather than specifically designed for recording agent behavior.

[0010] Rating group credibility (RGT) methods (Liu et al., Information Systems Frontiers, 2024) and blockchain-based decentralized reputation systems (Wang et al., Future Generation Computer Systems, 2021) conceptually describe weighted reputation scoring and its anti-collusion properties. However, these existing systems do not define a specific data structure that embeds rating group reputation as a first-class field within a quality rating object, representing a standard event pattern.

[0011] Chinese patent application 202511169126 (published in October 2025) discloses a method for evidence storage and trusted auditing of multi-agent collaborative behavior, involving on-chain recording of agent behavior, binding of reputation evaluation data, and arbitration logic. However, this patent application: (a) does not define a standardized event type classification covering the entire task lifecycle (this invention defines seven standardized event types including the task execution period, quality assessment period, and dispute resolution period); (b) does not provide a structured quality scoring object that embeds the ratingr's reputation value as a first-class field into the standardized behavior event record; and (c) does not disclose a cross-platform event adapter for heterogeneous protocols such as MCP and A2A. The essential difference between this invention and the aforementioned prior art is that it not only records behavior but also embeds the ratingr's reputation metadata into the event record itself through standardized event patterns, enabling downstream reputation calculation to achieve anti-collusion weighted scoring without external queries.

[0012] The Model Context Protocol (MCP) and the Agent-to-Agent Protocol (A2A) standardize the communication interfaces between agents and tools, and between agents and agents, respectively. While these protocols define the message formats for interaction, they do not define a unified behavior event logging model or a cross-platform, verifiable, tamper-proof event storage mechanism.

[0013] Therefore, what is needed is a system that combines the following elements: (1) standardized behavioral event patterns with agent-specific semantics; (2) a standardized classification of event types covering the entire agent task lifecycle; (3) a structured quality rating object with embedded rater reputation for weighted scoring; (4) a cross-platform event adapter for heterogeneous protocol environments; and (5) tamper-proof storage with cryptographic verification. None of the above combinations are disclosed in the prior art. Summary of the Invention

[0014] Purpose of the invention

[0015] This invention provides an intelligent agent behavior recording system and method for achieving standardized, verifiable, and tamper-proof recording of autonomous software intelligent agent behavior events.

[0016] Technical solution

[0017] The first aspect of this invention provides a computer-implemented method for standardized recording of intelligent agent behavior events, comprising the following steps:

[0018] (a) Generate a standardized behavior event record conforming to a predefined pattern at the first intelligent agent entity, wherein the standardized behavior event record includes at least:

[0019] (i) Event type, wherein the event type is selected from a standardized event type definition classification covering the entire life cycle of an agent's task, and the standardized event type definition classification includes at least task execution period events, quality assessment period events, and dispute resolution period events;

[0020] (ii) Entity identifier, uniquely identifying the first intelligent agent entity;

[0021] (iii) Execution result, indicating the result of the task performed by the first intelligent agent entity; and

[0022] (iv) When the event type belongs to the quality assessment period event, it also includes a structured quality scoring object, which includes a score value and a rater reputation value, wherein the rater reputation value is used to perform a reputation-weighted scoring on the score value;

[0023] (b) Cryptographically sign the standardized behavioral event record; and

[0024] (c) Append the signed standardized behavior event record to a tamper-proof chained storage structure, wherein the append operation includes including the cryptographic hash of the previous event record in the chained storage structure.

[0025] A second aspect of the present invention provides a standardized recording system for intelligent agent behavior events, comprising:

[0026] (a) An event generation module configured to generate standardized behavioral event records conforming to a predefined pattern, each record including at least: (i) an event type selected from the normative event type definition classification; (ii) an entity identifier; (iii) an execution result; and (iv) when the event type belongs to a quality assessment period event, it also includes a structured quality scoring object, the structured quality scoring object including a score value and a scorer reputation value;

[0027] (b) A cross-platform event adapter configured to receive input events from multiple heterogeneous agent communication protocols and map the input events to a standardized behavior event record of the predefined pattern;

[0028] (c) A chained storage module configured to store the standardized behavioral event records in an append-only hash chain structure with cryptographic signatures; and

[0029] (d) A hash anchoring module configured to periodically compute cryptographic commitments from the hash chain structure and publish the cryptographic commitments to a public blockchain.

[0030] A third aspect of the present invention provides a non-transitory computer-readable storage medium having instructions stored thereon, which, when executed by one or more computer processors, cause the one or more computer processors to perform operations including generating a standardized record of behavioral events conforming to a predefined pattern, wherein:

[0031] (a) The predefined pattern includes an event type field, which can be selected from a definition category consisting of the following seven specification event types: TASK_INVOKED (task has been invoked), TASK_COMPLETED (task has been completed), TASK_FAILED (task has failed), TASK_TIMEOUT (task has timed out), QUALITY_RATED (quality has been rated), DISPUTE_FILED (dispute has been submitted), and DISPUTE_RESOLVED (dispute has been resolved);

[0032] (b) The predefined pattern also includes a structured quality scoring object, which includes a score value field, a rater identifier field, a rater reputation value field, and a confidence value field;

[0033] (c) The standardized behavioral event record is cryptographically signed; and

[0034] (d) The standardized behavioral event record is appended to a tamper-proof chained storage structure that incorporates the cryptographic hash of the previously recorded record.

[0035] A fourth aspect of the present invention provides a computer program product comprising a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspect and dependent aspects of the present invention.

[0036] Beneficial effects

[0037] This invention provides a verifiable, tamper-proof, and interoperable behavior recording mechanism for the autonomous intelligent agent ecosystem by combining standardized event patterns, standardized event type classification, embedded reputation-based structured quality scoring, cross-platform adaptation, and tamper-proof chained storage. The rater's reputation value is embedded as the first type of field in the quality scoring object, enabling downstream reputation engines to achieve anti-collusion weighted scoring without needing to query rater reputations from external sources during scoring, reducing reputation query latency from O(n) external lookup to O(1) embedded read.

[0038] In the event standardization recording method of the present invention, the standardized event type classification definition and the standardized behavior event recording mode are functionally mutually supportive and interactive: the event type classification defines seven standardized event types covering the entire life cycle, and the standardized recording mode predefines corresponding structured fields for each event type (including the ratingr reputation metadata embedded in the quality rating object). Together, they constitute a technical means to solve the technical problem of how to achieve standardized and verifiable recording of behavior events in heterogeneous intelligent agent environments. Attached Figure Description

[0039] Figure 1 This is a system architecture diagram of the intelligent agent behavior event standardization recording system of the present invention, showing the data flow between the event generation module, cross-platform event adapter, chained storage module and hash anchoring module.

[0040] Figure 2 The lifecycle state diagram for the standard event type classification of this invention shows the flow relationship and sequence of the seven standard event types in three stages (task execution period, quality assessment period, and dispute resolution period).

[0041] Figure 3 The flowchart of the method for standardizing the recording of intelligent agent behavior events of the present invention shows the complete processing flow from event generation to cryptographic signature to chained storage appending. Detailed Implementation

[0042] The present invention will be further described in detail below with reference to specific embodiments.

[0043] Standardized event type classification

[0044] According to one embodiment of the present invention, the standardized event type classification includes the following seven event types, covering the complete lifecycle of an agent's task:

[0045] TASK_INVOKED Task or subtask is initiated Record the job initiation, including the caller, the callee, and the task parameters. TASK_COMPLETED The task was completed successfully. Record successful completion, including duration and result payload. TASK_FAILED The task ended due to an error or exception. Log failures, including error type, message, and stack context. TASK_TIMEOUT Task exceeds configuration period Record timeouts, including configuration deadline and actual time elapsed. QUALITY_RATED Raters submit quality assessments Record quality ratings and metadata about the ratingr's identity and reputation. DISPUTE_FILED One party challenges the prior score or result Record the dispute, including the party raising the objection, their reasons, and the evidence cited. DISPUTE_RESOLVED The dispute was adjudicated or resolved. Record the outcome of the resolution, including the final ruling and the identity of the arbitrator.

[0046] Complete lifecycle definition

[0047] According to the present invention, the "complete lifecycle" refers to the complete temporal closed loop of an agent's task from initiation to termination, and then to post-event evaluation and dispute resolution. Specifically, the aforementioned seven normative event types can be divided into three stages according to their functional roles:

[0048] Phase 1 – Task Execution Period (TASK_INVOKED → TASK_COMPLETED / TASK_FAILED / TASK_TIMEOUT): This phase covers the entire process from when the task is invoked to when it produces an execution result. The end of this phase is marked by successful completion, failure to complete, or timeout, which constitute a mutually exclusive set of termination states.

[0049] Phase Two – Quality Assessment Period: After the task execution results are generated, the caller or authorized third party submits an evaluation of the task execution quality to the system. This phase relies on the execution result data generated in Phase One, but is independent of the task execution itself.

[0050] Phase Three – Dispute Resolution Period (DISPUTE_FILED → DISPUTE_RESOLVED): When the task execution result or quality score is questioned, the submission and resolution of disputes provide a post-event corrective mechanism for this lifecycle. This phase relies on the event records generated in Phase One and Phase Two as an evidentiary basis.

[0051] The three stages and seven event types described above together constitute the set of canonical event types for the agent's task behavior in this embodiment. In this embodiment, the seven event types are defined as a set of canonical event types covering the complete lifecycle of the agent's task.

[0052] Standardized Behavioral Event Recording Model

[0053] According to one embodiment, the standardized behavioral event record is defined as follows:

[0054] - event_id (event identifier): UUID (time-ordered, globally unique)

[0055] - entity_id (entity identifier): AIP identifier (AIP is an abbreviation for Agent Identity Protocol as defined in this invention, and is unique to each agent)

[0056] - event_type (event type): Specifies the event type (enumeration)

[0057] - timestamp: ISO 8601 timestamp

[0058] - task_id (task identifier): UUID (optional, linked to the call chain)

[0059] - caller_id (caller identifier): Entity identifier (optional, caller agent)

[0060] - result: Execution result (enumeration: Pending, Success, Failure, Partial, Timeout)

[0061] - quality_score: Quality score object (optional), including:

[0062] - score: a floating-point number (0-1)

[0063] - rater_id (rater identifier): Entity identifier

[0064] - rater_reputation (rater reputation): Floating-point number (optional, the rater's current reputation)

[0065] - confidence: Floating-point number (optional, confidence level based on the number of interactions)

[0066] - duration_ms (duration in milliseconds): Integer (optional, response time in milliseconds)

[0067] - metadata: Mapping (optional, domain-specific extended fields)

[0068] - signature: Cryptographic signature (e.g., Ed25519)

[0069] Example 1: Tool Invocation via MCP Protocol

[0070] In this embodiment, the first intelligent agent Agent_A calls the tool on MCP Server_B through the MCP protocol.

[0071] (a) Agent_A sends a tool call request to MCP Server_B via the MCP protocol. The cross-platform event adapter intercepts the MCP request and generates a TASK_INVOKED event record, including: event_id (UUIDv7), entity_id (Server_B's AIP identifier), event_type (TASK_INVOKED), timestamp (ISO 8601), task_id (association identifier), caller_id (Agent_A's identifier), result (Pending), and a signature for the record.

[0072] (b) Server_B handles the tool call. Upon completion, the adapter generates a TASK_COMPLETED event log, including: event_id, entity_id (Server_B), event_type (TASK_COMPLETED), timestamp, task_id (matching the call), result (Success), duration_ms (234), and a signature. Both events are appended to the Server_B event chain.

[0073] (c) Agent_A evaluates and returns the results and submits a quality score. The adapter generates a QUALITY_RATED event log, including: event_id, entity_id (Server_B), event_type (QUALITY_RATED), timestamp, task_id, quality_score: {score: 0.95, rater_id: Agent_A, rater_reputation: 890, confidence: 0.85}, and a signature.

[0074] (d) The chained storage module appends each event record to the append-only chain of Server_B. Each event record contains the sha256 hash of the previous event record. The module periodically (e.g., every 1000 events) calculates the Merkle root of the cumulative event batch, signs the Merkle root, and publishes the signed root hash to a public blockchain (e.g., Ethereum) as a timestamp-anchored commitment.

[0075] (e) When the querying party requests the reputation of Server_B's actions, it receives the event chain and cryptographic proofs, including Merkle proofs linking each event to an anchor on the chain. The querying party independently verifies the chain integrity and signature validity without trusting Server_B or any centralized authority.

[0076] Example 2: Cross-platform intelligent agent delegation via A2A protocol

[0077] In this embodiment, the agent on the first platform (Agent_C on Coze) delegates the subtask to the agent on the second platform (Agent_D on Dify) via the A2A protocol. The cross-platform compatibility challenge is that Agent_D's platform (Dify) does not natively support the AIP signature protocol.

[0078] (a) Agent_C sends a task request to Agent_D via the A2A protocol. The cross-platform event adapter on the Coze side maps the A2A request to a TASK_INVOKED event record conforming to a standardized pattern. This event is signed by the Trust Anchor associated with the Coze platform.

[0079] (b) Agent_D receives and executes the task on the Dify platform. Upon completion, the trust anchor on the Dify side verifies the execution result, generates a TASK_COMPLETED event record, and signs the record with the trust anchor's key (not Agent_D's key)—because Agent_D's runtime does not support direct cryptographic signatures.

[0080] (c) Both event records are appended to the chain. The signature of the trust anchor serves as cryptographic proof that the event has been verified by the trusted intermediary. The entity_id field in the event record identifies Agent_D as the executing entity, and the signature comes from the trust anchor, enabling verification without requiring each agent to implement the signature protocol at runtime.

[0081] (d) A hybrid storage mechanism is adopted: events are stored off-chain with high throughput and appended only to the chain, with Merkle root commitments periodically published to the public blockchain. The querying party can verify events by: (i) obtaining the event chain from Agent_D's platform; (ii) verifying the signature chain of the trust anchor; (iii) verifying the on-chain Merkle root commitment; and (iv) confirming that the signature key of the trust anchor has been authorized for use on the claimed platform.

[0082] Example 3: Quality Dispute Resolution and Reputation-Weighted Scoring

[0083] In this embodiment, when disputes arise regarding the quality scores submitted by the intelligent agent in the execution of tasks, the dispute resolution process is recorded using a standardized event type classification.

[0084] (a) Agent_E completes a task for Agent_F. Agent_F submits a QUALITY_RATED event with quality_score: {score: 0.30, rater_id: Agent_F, rater_reputation: 120, confidence: 0.60}.

[0085] (b) Agent_E challenges the low score, claiming that the task has been completed according to the specifications. Agent_E submits a DISPUTE_FILED event, including: event_id, entity_id (Agent_E), event_type (DISPUTE_FILED), timestamp, task_id (matching the original task), and metadata containing the reasons for the dispute and references to the original task specifications.

[0086] (c) The arbitrator reviews the dispute (automatically or manually). After the ruling, the system generates a DISPUTE_RESOLVED event, which includes: event_id, entity_id (Agent_E), event_type (DISPUTE_RESOLVED), timestamp, task_id, and metadata containing the resolution result (such as "score remains unchanged" or "score has been adjusted").

[0087] (d) When the reputation engine subsequently calculates Agent_E's reputation score, it retrieves all QUALITY_RATED events associated with Agent_E, excludes events in a disputed frozen state (metadata.frozen=true), and calculates a weighted average of the remaining event quality scores based on the rater's reputation value. This is combined with other reputation factors such as task completion rate and timeliness to calculate Agent_E's overall reputation score. If a dispute is determined to be malicious (e.g., Agent_F's score is adjusted to invalid), the system further reduces Agent_F's rater reputation value, lowering its future rating weight. This closed-loop mechanism ensures that dispute resolution results are fed back into the reputation calculations of both the rater and the rated party.

[0088] Example 4: Multi-level call causal chain tracing

[0089] In this embodiment, in a multi-level call chain (Agent_A → Agent_B → Agent_C → Agent_D) composed of multiple agents, the system tracks and records the complete propagation path of the call causal chain.

[0090] (a) When Agent_A initiates a call to Agent_B, the system generates a TASK_INVOKED event, in which the task_id field records the root identifier of the current call chain, the caller_id field records Agent_A as the caller, and the entity_id field records Agent_B as the callee.

[0091] (b) During task execution, Agent_B further calls Agent_C. The system generates a new TASK_INVOKED event for this recursive call. The task_id field of this event contains the same root identifier as the root call, and a new parent_task_id field is added to reference the event_id of the associated event in Agent_B's call chain, thus establishing a parent-child call relationship. caller_id records Agent_B, and entity_id records Agent_C.

[0092] (c) This process is passed up the call chain level by level until the final agent Agent_D. The TASK_INVOKED event of each intermediate node points to the parent call event through the parent_task_id field, forming a call causal chain with a directed acyclic graph (DAG) structure.

[0093] (d) After each call produces an execution result, the `result` and `duration_ms` fields in the corresponding event record are supplemented with the actual execution result information. In subsequent calculations, the reputation calculation engine can identify key nodes and bottlenecks in the call chain by traversing this DAG structure—for example, if the response time of Agent_B's `TASK_COMPLETED` event is normal, but its child node Agent_C's `TASK_FAILED` event occurs frequently, the root cause of the failure can be automatically located as Agent_C rather than Agent_B.

[0094] (e) When the call chain contains a disputed event (DISPUTE_FILED), the system traces the exact location of the dispute in the call chain through the association between task_id and parent_task_id, and marks all the behavior events of the disputed node and all its subordinate child nodes as frozen until the dispute is resolved.

[0095] Technical Benefits: Multi-level call causal chain tracing enables reputation calculation to move beyond the independent behavioral records of a single agent, allowing for precise attribution of responsibility and contribution in multi-agent collaborative scenarios. During dispute resolution, it can accurately define the scope of affected calls, preventing the reputation of unrelated nodes in the entire call chain from being frozen due to a dispute at a single node.

[0096] The frozen state is achieved by setting the "frozen: true" flag in the metadata field of the event record. The reputation calculation engine skips event records marked as frozen when aggregating reputation factors. After a dispute is resolved, the frozen flag is cleared (weight restored) or the flag is retained and the event weight is adjusted (downward adjustment) depending on the resolution result.

[0097] Other implementation methods

[0098] Zero-knowledge verification implementation. In an alternative implementation, a chained storage module supports zero-knowledge proof verification. The querying party can verify that the agent's event chain satisfies certain predicates (e.g., total number of events ≥ N, success rate ≥ P%, average quality score ≥ Q) without obtaining the complete list of events. This is achieved by constructing a Merkle summation tree of event attributes and generating zero-knowledge range proofs on the cumulative values. This implementation is particularly suitable for privacy-sensitive agent scenarios, such as financial service agents that do not wish to disclose their complete behavioral history.

[0099] Configurable anchoring frequency. In another alternative implementation, the anchoring frequency of the hash anchoring module can be configured according to the application scenario. For high-frequency agent call environments (e.g., 10,000 events per second), anchoring is performed at a reduced frequency (e.g., every 10,000 blocks) to control blockchain transaction costs. For low-frequency, high-value scenarios (e.g., contract settlement mediated by agents), the anchoring frequency is increased (e.g., per block) to maximize tamper-proof guarantees.

[0100] Domain-specific extended fields. In another alternative implementation, metadata fields of standardized event logs are used to carry domain-specific data. For financial transactions, metadata includes transaction amount, counterparty identifier, and compliance check results. For medical agent tasks, metadata includes data type identifier and de-identification status. For code generation agents, metadata includes lines of code, test coverage metrics, and vulnerability scan results.

Claims

1. A computer-implemented method for standardized recording of intelligent agent behavior events, characterized in that, Includes the following steps: (a) Generate a standardized behavior event record conforming to a predefined pattern at the first intelligent agent entity, wherein the standardized behavior event record includes at least: (i) Event type, wherein the event type is selected from a standardized event type definition classification covering the entire life cycle of an agent's task, and the standardized event type definition classification includes at least task execution period events, quality assessment period events, and dispute resolution period events; (ii) Entity identifier, uniquely identifying the first intelligent agent entity; (iii) Execution result, indicating the result of the task performed by the first intelligent agent entity; and (iv) When the event type belongs to the quality assessment period event, it also includes a structured quality scoring object, which includes a score value and a rater reputation value, wherein the rater reputation value is used to perform a reputation-weighted scoring on the score value; (b) Cryptographically sign the standardized behavioral event record; and (c) Append the signed standardized behavior event record to a tamper-proof chained storage structure, wherein the append operation includes including the cryptographic hash of the previous event record in the chained storage structure.

2. A standardized recording system for intelligent agent behavior events, characterized in that, include: The event generation module is configured to generate standardized behavioral event records that conform to a predefined pattern. Each record includes at least an event type selected from the normative event type definition classification, an entity identifier, an execution result, and, when the event type belongs to a quality assessment period event, a structured quality scoring object, which includes a score value and a scorer reputation value. A cross-platform event adapter is configured to receive input events from multiple heterogeneous intelligent agent communication protocols and map the input events to standardized behavior event records of the predefined pattern; A chained storage module is configured to store the standardized behavioral event records in an append-only hash chain structure with cryptographic signatures; as well as The hash anchoring module is configured to periodically compute cryptographic commitments from the hash chain structure and publish the cryptographic commitments to the public blockchain.

3. A non-transitory computer-readable storage medium storing instructions thereon, said instructions, when executed by one or more computer processors, causing said one or more computer processors to perform operations including generating a standardized record of behavioral events conforming to a predefined pattern, characterized in that: (a) The predefined pattern includes an event type field, which can be selected from a definition category consisting of the following seven specification event types: TASK_INVOKED (task has been invoked), TASK_COMPLETED (task has been completed), TASK_FAILED (task has failed), TASK_TIMEOUT (task has timed out), QUALITY_RATED (quality has been rated), DISPUTE_FILED (dispute has been submitted), and DISPUTE_RESOLVED (dispute has been resolved); (b) The predefined pattern also includes a structured quality scoring object, which includes a score value field, a rater identifier field, a rater reputation value field, and a confidence value field; (c) The standardized behavioral event record is cryptographically signed; as well as (d) The standardized behavioral event record is appended to a tamper-proof chained storage structure that incorporates the cryptographic hash of the previously recorded record.

4. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method as described in any one of claims 1, 5, 6, 12, 14, or 15.

5. The method as described in claim 1, characterized in that, The structured quality rating object also includes a rater identifier field and a confidence value field. The rater identifier field identifies the rater entity that provides the rating value, and the confidence value field indicates the confidence level associated with the rating value.

6. The method as described in claim 1, characterized in that, Also includes: Input events are received from a first communication protocol, which is selected from a group consisting of a Model Context Protocol (MCP), an Agent-to-Agent Protocol (A2A), and a platform-internal protocol. And the input events are mapped to the standardized behavior event records via a cross-platform event adapter.

7. The system as described in claim 2, characterized in that, The chain storage module stores the standardized behavioral event records in the off-chain append-only data storage. The hash anchoring module periodically calculates the Merkle root of at least a portion of the standardized behavioral event records and publishes the Merkle root to the public blockchain as a tamper-proof timestamp anchor.

8. The system as described in claim 2, characterized in that, At least one cryptographic signature of a standardized behavioral event record is generated by a trust anchor entity that is different from the intelligent agent entity identified by the entity identifier, and the trust anchor entity verifies the authenticity of the event record before signing.

9. The method as described in claim 1, characterized in that, The semantic definitions of each event type in the defined event type category are as follows: TASK_INVOKED records the initiation of an agent task; TASK_COMPLETED records the successful completion of an agent task; TASK_FAILED records the failure of an agent task due to an error condition; TASK_TIMEOUT records the expiration of the agent task's configuration time limit; QUALITY_RATED records the submission of an agent task quality assessment; DISPUTE_FILED records a challenge to a prior action event; and DISPUTE_RESOLVED records the resolution of a prior submission dispute.

10. The system as described in claim 2, characterized in that, The linked storage module also supports zero-knowledge verification, enabling the querying party to verify that a set of event records satisfies one or more predefined predicates without disclosing the complete set of event records.

11. The system as described in claim 7, characterized in that, The anchoring frequency of the hash anchoring module can be configured according to the application scenario. When the event throughput exceeds a first threshold, a first anchoring frequency is used, and when the event throughput is lower than a second threshold, a second anchoring frequency is used, wherein the first anchoring frequency is lower than the second anchoring frequency.

12. The method as described in claim 1, characterized in that, Also includes: A DISPUTE_FILED event record is generated in response to receiving a dispute submission from a disputed entity; and a DISPUTE_RESOLVED event record is generated in response to receiving a resolution of the dispute, wherein both the DISPUTE_FILED and DISPUTE_RESOLVED event records are appended to the tamper-proof linked storage structure.

13. The system as described in claim 2, characterized in that, The cross-platform event adapter is configured to: verify whether the input event conforms to the specified event type classification, and when the event type belongs to the quality assessment period event, verify that it contains the structured quality scoring object; and map the verified input event to the standardized behavior event record.

14. The method as described in claim 1, characterized in that, The standardized behavior event record also includes a parent task identifier field, which references the event identifier of the preceding behavior event record, thereby establishing a directed acyclic graph structure of the call causal chain in a multi-level call scenario.

15. The method as described in claim 14, characterized in that, In response to receiving a dispute submission for a node in the call causal chain, the behavior events of the disputed node and all its subordinate child nodes are marked as frozen, wherein the frozen state is achieved by setting a freeze flag in the metadata field of the event record; in response to the resolution of the dispute, the freeze flag is cleared or retained according to the resolution result.

Images