A2a local task protocol and result encapsulation normalization output method and apparatus

Abstract

The embodiment provides an A2A local task protocol and result package normalization output method and device, a full-duplex real-time communication channel is established between a cloud agent runtime and a local device agent, and a heartbeat mechanism is used for maintaining channel activity and state machine migration; when it is determined that a local tool needs to be called according to a capability list, a local tool request message carrying a multi-dimensional security check element is issued through the communication channel; the local device agent performs seven-dimensional security check chain on the request identification idempotent, device and workspace binding, tool authorization, component integrity, digital signature, and running environment and local area network reach, and performs dimension-by-dimension check; after the check is passed, a tool component is loaded to generate an original execution result, the original execution result is mapped into a result package containing a structured result, a subsequent to-do list, a memory update suggestion, an operator visible abstract, and an attachment abstract, and is returned through the communication channel, a task running state is updated, and output security review is triggered to return to a decision-making closed loop.

Description

Technical Field

[0001] The present application relates to the technical field of artificial intelligence agent cooperative communication, and specifically relates to an A2A local task protocol and result encapsulation normalized output method and apparatus. Background Art

[0002] Existing Agent-to-Agent (A2A, Agent2Agent protocol) cooperative technologies mostly adopt a mode in which a main model distributes tasks to sub-agents, instructions are transmitted between the main model and the sub-agents in a request-response mode, and execution results are returned in the form of free text. These technologies mainly focus on task decomposition and load balancing, and do not involve structured encapsulation and security verification of execution results. Another type of scenario orchestration and device cooperation solution is oriented to scenarios such as smart home to realize multi-device linkage through scenario template matching. The format of scenario orchestration results is defined by each device manufacturer independently, lacking a unified normalized output standard. The platform layer needs to write a dedicated adapter for each device for format conversion, and communication mostly adopts a polling or publish-subscribe mode, without a dedicated security verification chain designed.

[0003] In the existing model context protocol client invocation solution, the client calls a statically configured tool set in sequence, the format of tool invocation results is defined by the tool provider, the platform only performs transparent transmission without structured encapsulation, and security verification mainly relies on the tool permissions declared by the client, lacking server-side mandatory multi-dimensional verification. The existing lightweight tool matching solution matches tools based on task splitting, the return format of tool execution results is determined by each tool itself, and the platform does not provide a unified normalized encapsulation layer. In the above solutions, the format of the return results after the agent executes the local tool is inconsistent, making it difficult for the cloud agent to perform unified parsing and processing, resulting in parsing failure and information loss due to format differences during cross-device cooperation, which limits the automation level of business decision-making.

[0004] A more fundamental problem is that existing local tool invocations usually only rely on simple identity authentication or session token verification, lacking systematic multi-dimensional verification for request idempotency, device binding, workspace binding, tool authorization, component integrity, message signature and operating environment, making it difficult to intercept threats such as request forgery, parameter tampering, replay attacks and cross-device unauthorized access; communication between the cloud and local devices mostly adopts polling or simple message transmission, lacking state machine management based on a full-duplex channel. When the local device is offline, the cloud cannot accurately perceive the online state and task execution state, and may repeatedly issue requests to the offline device. Therefore, it is necessary to develop an Agent-to-Agent local task protocol and result encapsulation normalized output method that combines full-duplex channel state management, multi-dimensional security verification and result normalized encapsulation. Summary of the Invention

[0005] To address the issues of existing intelligent agent collaboration technologies, such as the lack of structured result encapsulation, systematic multi-dimensional security verification, and full-duplex channel state management leading to inconsistent execution formats across devices, security vulnerabilities in local tool execution, and unreliable communication states, this application provides an A2A local task protocol and result encapsulation normalized output method and apparatus. This method establishes a full-duplex real-time communication channel between cloud-based intelligent agents and local device intelligent agents, maintains the channel state machine using a heartbeat mechanism, verifies local tool requests dimension-by-dimensionally through a seven-dimensional security verification chain to intercept forgery, tampering, replay, and unauthorized access, and unifies the execution results of various tools through a five-field normalized encapsulation structure, thereby improving the security, reliability, and consistency of results in cross-device collaboration.

[0006] To solve at least one of the above problems, this application provides the following technical solution: Firstly, this application provides an A2A local task protocol and result encapsulation normalization output method, comprising: establishing a full-duplex real-time communication channel between a cloud-based intelligent agent and a local device intelligent agent during runtime and maintaining channel activity and state machine transition according to a preset heartbeat mechanism; when the cloud-based intelligent agent determines that a local tool needs to be invoked based on the capability list, it sends a local tool request message carrying multi-dimensional security verification elements to the local device intelligent agent through the communication channel; after receiving the local tool request message, the local device intelligent agent binds the request identifier to idempotency and device and workspace identifiers, tool authorization and tool component integrity, digital signature and runtime according to a seven-dimensional security verification chain. The environment and local area network reach are verified one by one. When the seven-dimensional verification is passed, the corresponding tool component is loaded and executed to generate the original execution result. If any dimension fails, execution is rejected and a security event is reported through the communication channel. The original execution result is mapped into a result encapsulation containing five standard fields: structured result, subsequent pending tasks, memory update suggestions, operator-visible summary, and attachment summary, according to a preset normalized encapsulation structure. The result encapsulation is sent back to the cloud intelligent agent through the communication channel to update the task running status and trigger output security review. After updating the state machine and authorization snapshot of the communication channel according to the return sequence and security event, it is fed back to the decision-making process that determines that local tools need to be called.

[0007] Furthermore, it also includes: the local device agent reads the locally configured cloud server address, workspace identifier, device identifier, and credential information, obtains a short-term valid access token from the cloud authentication service using the credential information, and initiates a connection request to the real-time communication endpoint carrying the device identifier, workspace identifier, and operating environment information; the cloud agent verifies the validity of the access token and confirms the binding relationship between the device identifier and the workspace identifier, accepts the connection, and sends back an initialization message; after the communication channel is established, both parties send heartbeat requests and heartbeat responses to each other at a preset heartbeat interval to maintain channel activity; if no heartbeat is received from the other end for a preset number of consecutive cycles, the channel is determined to be interrupted and migrates to the reconnection state according to the exponential backoff strategy.

[0008] Furthermore, it also includes: the cloud-based intelligent agent organizing a local tool request message on the communication channel during runtime; the local tool request message containing a request identifier, device identifier, workspace identifier, skill identifier and tool name, input parameters, pre-authorization token, tool component hash value and digital signature; calculating a message authentication code for all fields of the local tool request message except the digital signature using a workspace-level shared key as the digital signature; and sending the local tool request message to the local device intelligent agent via the communication channel; the pre-authorization token containing a method name, workspace identifier, skill identifier, parameter structure template, expiration time and range of random numbers as pre-authorization elements.

[0009] Furthermore, it also includes: the local device agent maintaining a memory cache and persistent storage of processed request identifiers; comparing the request identifier of the local tool request message with it to identify duplicate requests and returning an idempotent response to duplicate requests; strictly comparing the device identifier of the local tool request message with the local device identifier and the workspace identifier with the locally bound workspace identifier to complete the device and workspace binding verification; parsing the pre-authorization token verification validity period and the consistency of the method name, workspace identifier, skill identifier, and parameter structure template of the local tool request message to complete the tool authorization verification; calculating the hash value of the tool component and comparing it with the hash value of the tool component carried in the request using the constant time comparison method to complete the integrity verification; calculating the message authentication code of the request field with the workspace-level shared key and comparing it with the digital signature to complete the signature verification; and verifying the matching of the local operating environment and the tool's declared compatible platform and the local area network reach status to complete the seven-dimensional security verification chain.

[0010] Furthermore, it also includes: when the seven-dimensional verification passes, the local device agent loads the corresponding tool component according to the tool name in the local tool request message and executes it with the input parameters, recording the task execution steps including the tool loading time, execution start time, execution parameters, and intermediate states, and using the hash value of the previous task execution step as the input of the next task execution step to form a traceable record chain; when any dimension verification fails, the local device agent stops subsequent verifications according to the fast failure strategy and generates a security event including the event type, failure dimension number, failure reason, and authorized snapshot identifier, and reports the security event to the cloud agent in real time through the communication channel and writes it into the local audit log, and triggers a local security lock to suspend the receipt of new local tool requests for verification failures in the tool component integrity dimension and digital signature dimension.

[0011] Furthermore, it also includes: selecting the corresponding structured result template based on the tool type of the original execution result to map the original execution result to standard key names; normalizing the mapped numerical fields, timestamp fields, and enumeration value fields according to preset precision, unified time format, and standard code value to generate structured results; generating subsequent to-dos and memory update suggestions for the structured results based on preset rule families and lightweight models; generating an operator-visible summary based on the structured results using a natural language generation template and generating an attachment summary for the attachments generated in this execution; assembling the five types of standard fields into a result encapsulation; and gracefully degrading the original execution result for format anomalies, missing fields, and timeouts in to-do generation according to a fallback template, default annotation, and empty list return, respectively.

[0012] Furthermore, it also includes: after receiving and encapsulating the results, the cloud-based intelligent agent updates the lifecycle status of the task execution and triggers an output security review containing multiple types of information interception; it records each task execution step in sequence and generates an audit event with associated authorization snapshot identifier, which is then written into the audit event storage to form a traceable audit closed loop; it applies differentiated constraints to the invocation of local tools according to the execution mode bound to the task execution, executing in a predefined order and defaulting to rejecting system commands in workflow mode; adding user confirmation to write access-level and critical risk-level operations in personal intelligent agent mode; converting external standardized requests into local tool invocations and fully recording audits in gateway intelligent agent mode; and in local event radar mode, having the local device intelligent agent initiate a local tool request in reverse when the trigger conditions are met.

[0013] Secondly, this application provides an A2A local task protocol and result encapsulation normalization output device, comprising: a channel management module, used to establish a full-duplex real-time communication channel between the cloud-based intelligent agent and the local device intelligent agent during runtime and verify the binding relationship between the access token and the device and workspace identifier, maintain channel activity and state machine transition according to a preset heartbeat mechanism, and trigger reconnection according to an exponential backoff strategy when the channel is interrupted; a request delivery module, used to organize classified messages containing runtime initialization messages, local tool request and response messages, heartbeat messages, and security event messages on the communication channel, and when the cloud-based intelligent agent determines that a local tool needs to be called according to the capability list, organizes a local tool request message containing a request identifier, device and workspace identifier, pre-authorization token, tool component hash value, and digital signature, and delivers it through the communication channel; and a security verification module, used to verify the received local tool request message according to a seven-dimensional security check. The verification chain performs a dimensional check on the request identifier's idempotency and binding to the device and workspace identifiers, tool authorization and tool component integrity, digital signature and runtime environment and LAN accessibility. If any dimension check fails, subsequent checks are stopped according to a fast-failure strategy and handled according to the failure dimension. The tool execution module is used to load the corresponding tool component according to the tool name and execute it with input parameters to generate the original execution result when the seven-dimensional check passes. It records the task execution steps including the tool loading time, execution start time and intermediate state, and generates a security event report and triggers local security locking when the check fails. The result encapsulation module is used to map the original execution result into a result encapsulation containing structured results, subsequent tasks, memory update suggestions, operator-visible summary and attachment summary according to a preset normalized encapsulation structure. The result encapsulation is then sent back to the cloud intelligent agent through the communication channel to trigger task execution status update and output security review.

[0014] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the A2A local task protocol and result encapsulation normalization output method.

[0015] Fourthly, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the A2A local task protocol and result encapsulation normalization output method.

[0016] Fifthly, this application provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the steps of the A2A local task protocol and result encapsulation normalization output method.

[0017] As can be seen from the above technical solution, this application provides an A2A local task protocol and result encapsulation normalization output method and apparatus. It maintains reliable communication between the cloud and local devices and accurately senses online and execution status through a full-duplex real-time communication channel and heartbeat state machine. It intercepts unauthorized execution through a seven-dimensional verification chain of request identifier idempotency, device and workspace binding, tool authorization, component integrity, digital signature, and access to the operating environment and local area network. It normalizes and encapsulates the execution results of various tools through five fields: structured results, subsequent tasks, memory update suggestions, operator-visible summary, and attachment summary. After updating the channel state machine and authorization snapshot according to the return sequence and security events, it flows back to the issuing decision to form a closed loop. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0019] Figure 1 This is a flowchart illustrating the A2A local task protocol and result encapsulation normalization output method in the embodiments of this application; Figure 2 This is a schematic diagram of the structure and cloud and local layered architecture of the A2A local task protocol and result encapsulation normalization output device in the embodiments of this application. Figure 3 This is a schematic diagram illustrating the process of establishing a full-duplex real-time communication channel, transitioning the heartbeat state machine, and sending local tool request messages in the embodiments of this application. Figure 4 This is a schematic diagram of the seven-dimensional security verification chain dimension-by-dimensional verification, tool execution, and security incident handling process in the embodiments of this application. Figure 5 This is a schematic diagram of the five-field normalized encapsulation structure of the original execution result and the graceful degradation process in the embodiments of this application; Figure 6 This is a schematic diagram illustrating the four execution modes of result feedback audit closed loop, workflow, personal intelligent agent, gateway, and local event radar in the embodiments of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of this application, but not all embodiments.

[0021] Considering the existing problems of lack of structured result encapsulation, systematic multi-dimensional security verification, and full-duplex channel state management for intelligent agents, this application provides an A2A local task protocol and result encapsulation normalization output method. Through the establishment of a full-duplex real-time communication channel, a seven-dimensional security verification chain, result encapsulation normalization, and multi-mode execution state management, the process of cloud-based intelligent agents calling local device tools is subjected to security verification and result normalization feedback.

[0022] This application provides an embodiment of an A2A local task protocol and a result encapsulation and normalization output method, see [link to relevant documentation]. Figure 1 The method specifically includes the following: Step S101: When the cloud-based intelligent agent is running, a full-duplex real-time communication channel is established between the cloud-based intelligent agent and the local device intelligent agent, and the channel activity and state machine transition are maintained according to the preset heartbeat mechanism. When the cloud-based intelligent agent determines that a local tool needs to be called according to the capability list, it sends a local tool request message carrying multi-dimensional security verification elements to the local device intelligent agent through the communication channel.

[0023] In this embodiment, the method operates on an intelligent agent collaborative platform for digital parking lot management, such as... Figure 1 As shown, the platform is logically divided into two layers: a cloud-based intelligent agent runtime and a local device intelligent agent runtime. These two layers communicate via a full-duplex real-time communication channel. This communication channel establishes a persistent connection to the real-time communication endpoint, carrying five types of messages: runtime initialization messages, local tool request messages, local tool response messages, heartbeat messages, and security event messages. Each type of message is organized into a message header and a message body.

[0024] In one feasible implementation, such as Figure 3 As shown, the message header is organized with fields for message type, message identifier, sender identifier, receiver identifier, timestamp, and protocol version number. The message identifier is a globally unique string, generated by combining the timestamp, a random number, and a workspace identifier, serving as the primary key for message deduplication and association; the timestamp uses millisecond-level values. The heartbeat message body is organized with fields for heartbeat type, local device status summary, and network quality metrics. The local device status summary includes online status, data reach level, most recent active time, and number of pending tasks. The network quality metrics include latency, packet loss rate, and most recent reconnection count, used by the cloud to assess the peer's status.

[0025] Optionally, after the local device agent starts, it reads the cloud server address, workspace identifier, device identifier, and credential information from its local configuration. Using the credential information, it initiates identity verification with the cloud authentication service to obtain a short-term valid access token, the validity period of which is a preset duration. Based on this, the local device agent, carrying the device identifier, workspace identifier, operating system type, operating system version, and processor architecture information, initiates a connection request to the real-time communication endpoint. The cloud runtime verifies the validity of the access token and confirms the binding relationship between the device identifier and the workspace identifier before accepting the connection and sending back a runtime initialization message containing the session identifier, heartbeat interval configuration, and maximum message size.

[0026] In one specific implementation, the communication channel manages the connection lifecycle using a state machine, such as... Figure 3 As shown, the state machine contains six states: Initial, Connecting, Connected, Heartbeat Timeout, Reconnecting, and Disconnected. The Initial state transitions to the Connecting state after the local device agent starts up. The Connecting state transitions to the Connected state after receiving the run initialization message, and transitions to the Disconnected state when the connection request is rejected. The Connected state transitions to the Heartbeat Timeout state when no heartbeat is received from the peer for a preset number of consecutive cycles, and then transitions to the Reconnecting state. After successful reconnection, it returns to the Connected state. If the reconnection fails for a preset number of consecutive times, it transitions to the Disconnected state.

[0027] After the connection is established, both parties exchange heartbeat requests and responses at the heartbeat intervals agreed upon in the initialization message. If either party fails to receive a message from the other party within a preset number of consecutive cycles, the channel is considered interrupted and a reconnection is triggered. Error handling during the connection phase employs a tiered strategy: when authentication fails, the credential is checked for expiration and refreshed before retrying if expired; if the credential is valid but rejected, the connection is moved to a disconnected state and a security event is registered; when the network is unreachable, the connection enters a reconnection state and reconnects using an exponential backoff strategy, with the backoff interval doubling each time until a preset upper limit is reached; when the protocol version is mismatched, a version error flag is registered, an upgrade is prompted, and the connection is closed; when message parsing fails, a security event message explaining the parsing error details is sent back without interrupting the current connection.

[0028] In the parallel processing path, after the input security review of the cloud agent is passed, the parsing module derives the capability list of this session from the server. When it is determined that an operation requires calling a local device tool based on the capability list, the cloud agent sends a local tool request message to the local device agent through the communication channel. The local tool request message is organized with request identifier, device identifier, workspace identifier, skill identifier, tool name, input parameters, pre-authorization token, tool component hash value and digital signature fields. The request identifier is a combination of workspace identifier, timestamp and random number, which is read by primary key for the request identifier idempotency verification in step S102. If the sending fails, an exception identifier is registered and the message is resent according to the backoff strategy.

[0029] Step S102: After receiving the local tool request message, the local device intelligent agent performs a dimension-by-dimensional verification of the request identifier idempotency and binding with the device and workspace identifier, tool authorization and tool component integrity, digital signature and operating environment and local area network access according to the seven-dimensional security verification chain. When the seven-dimensional verification passes, the corresponding tool component is loaded and executed to generate the original execution result. If any dimension fails, execution is rejected and a security event is reported through the communication channel.

[0030] After the local tool request message issued in step S101 reaches the local device intelligent agent, it is read into the seven-dimensional security verification process, such as... Figure 4 As shown. The local device intelligent agent verifies the local tool request message dimension by dimension according to a seven-dimensional security verification chain. The seven-dimensional verification chain adopts a fast failure strategy; if any dimension fails verification, subsequent verifications are immediately stopped and a security event is generated. Only after all dimensions pass verification does the tool execution phase begin. The input of the seven-dimensional verification chain is the local tool request message body, and the output is a verification result object. The verification result object is organized with fields for verification pass flag, failure dimension number, failure reason description, verification time, and audit event identifier.

[0031] In one specific implementation, the first dimension performs idempotent verification of the request identifier. The local device agent maintains a memory cache and persistent storage for processed request identifiers. The memory cache retains the most recent preset number of request identifiers, while the persistent storage retains request identifiers within a preset time period. Upon receiving a request, the request identifier is compared with the cache and persistent storage. If a match is found, it is determined to be a duplicate request, and the cached result corresponding to that request identifier is returned directly without re-executing the tool. If a match is found, the request identifier is added to the cache, and the process continues to the next dimension. The second dimension performs device identifier matching verification, comparing the device identifier of the request message with the local device identifier using a case-sensitive strict string comparison. If a mismatch is found, a security event is registered, and a device identifier mismatch error is returned.

[0032] Based on this, the third dimension, workspace identifier binding verification, is performed. The local device agent reads the workspace identifier bound to the device during registration from its local configuration and strictly compares it with the workspace identifier in the request message. This verification ensures that a device can only execute instructions belonging to its own workspace, preventing unauthorized access across workspaces. The fourth dimension, tool authorization verification, is performed. The pre-authorization token is parsed and verified sequentially: whether it is within its validity period, whether the method name matches the requested tool name, whether the workspace identifier and skill identifier match the request, and whether the parameter structure template matches the requested input parameter structure. Parameter structure matching requires that the set of requested parameter key names is a subset of the set of key names defined in the template. If any sub-condition is not met, the tool authorization verification fails.

[0033] Optionally, the fifth dimension performs tool component integrity verification. The local device agent locates the corresponding tool component file based on the tool name and calculates its hash value. This hash value is compared with the tool component hash value carried in the request message using a constant-time comparison method. The constant-time comparison method ensures that the comparison time is independent of the location of content differences to prevent timing side-channel analysis. If there is an inconsistency, a security event is registered and an integrity verification failure is returned. This verification ensures that the locally executed tool component is consistent with the expected version in the cloud. The sixth dimension performs digital signature verification. Using the workspace-level shared key distributed through a secure channel during device registration and stored in the local key storage, a message authentication code is calculated for all fields of the request message except the digital signature. This code is compared with the digital signature carried in the request to confirm that the message has not been tampered with during transmission.

[0034] The seventh dimension performs runtime environment compatibility and LAN reach verification. The local device agent verifies whether the local operating system type and processor architecture are on the compatibility platform list declared by the tool component, and verifies whether the local device is in a LAN environment reachable from the cloud runtime. If both are satisfied, the entire seven-dimensional security verification chain passes. Figure 4 As shown, the verification pass flag is set to true and the verification time is recorded. Accordingly, the local device agent loads the corresponding tool component according to the tool name in the request message and executes it with the input parameters. During the execution process, the local runtime records the task execution steps, including the tool loading time, execution start time, execution parameters, and intermediate states. The hash value of the previous task execution step is used as the input of the next task execution step to form a traceable execution record.

[0035] When any dimension verification fails, the local device agent generates a security event. This security event is organized using fields such as event type, failure dimension number, failure reason, request identifier, device identifier, workspace identifier, timestamp, and authorized snapshot identifier. The security event message is reported to the cloud in real time via the communication channel and written to the local audit log. Security rejections are handled according to failure dimensions. Failures in the first to third dimensions are considered general security risks and only logged. Failures in the fifth and sixth dimensions are considered serious security risks and trigger local security locking, suspending the reception of new local tool requests pending manual review. The security rejection response message body includes the rejection reason, failure dimension number, and suggested handling measures. The generated original execution result or security event is read by step S103 to enter the encapsulation or reporting process.

[0036] Step S103: Map the original execution result into a result encapsulation containing five standard fields: structured result, subsequent tasks, memory update suggestions, operator-visible summary, and attachment summary, according to the preset normalized encapsulation structure. The result encapsulation is then sent back to the cloud intelligent agent via the communication channel to update the task running status and trigger output security review. After updating the state machine and authorization snapshot of the communication channel according to the return sequence and security events, the result is sent back to the decision-making process that determines whether to call local tools.

[0037] The raw execution result generated in step S102 is read into the result encapsulation stage, such as... Figure 5 As shown, the local device intelligent agent invokes a result encapsulation generator, which maps the original execution result into a result encapsulation containing five standard fields: structured result, subsequent tasks, memory update suggestions, operator-visible summary, and attachment summary, according to a preset normalized encapsulation structure. Both cloud intelligent agents and all local device intelligent agents follow this structure for encapsulation, thereby eliminating parsing failures and information loss caused by differences in tool formats.

[0038] In one specific implementation, the structured result is a structured object, carrying the core data of the tool's execution. The result encapsulation generator selects the corresponding structured result template based on the tool type and maps the original execution result to standard key names. For example, a barrier gate control tool maps the barrier gate identifier, execution action, pre-execution state, post-execution state, and execution time; a toll query tool maps the query time range, total amount due, total amount received, discount amount, number of transactions, and payment method distribution; and a parking space detection tool maps the total number of parking spaces, the number of occupied parking spaces, the number of available parking spaces, the distribution of parking spaces in each area, and the most recent update time. During mapping, numerical fields are normalized to a preset precision, timestamp fields are formatted to a uniform time format, and enumerated value fields are standardized to standard code values.

[0039] Based on this result, the generator encapsulates subsequent tasks and memory update suggestions. Subsequent tasks are string arrays, generated by the rule engine according to preset rule families based on the content of the structured results. For example, when the actual amount received is lower than a preset percentage of the amount due, a task to check abnormal transaction records is generated; when the number of available parking spaces is lower than a preset percentage of the total number of parking spaces, a task to enable traffic limiting guidance is generated. Memory update suggestions are structured objects, organized with update type, memory key name, memory value, validity period, and priority fields, suggesting that the cloud-based intelligent agent update the relevant entries in the memory storage.

[0040] Optionally, the result encapsulation generator uses a natural language template to generate a business-visible summary based on the key indicators of the structured results. This business-visible summary describes the core results of the execution in concise language, with a length controlled within a preset range, allowing business operators to quickly understand the execution results without reading the original technical data. The result encapsulation generator then checks whether the execution generated attachments and generates attachment summaries for the execution logs, screenshots, and exported data files. These attachment summaries are arrays of objects, each organized with fields for attachment identifier, attachment type, attachment name, file size, and download address. The download address is a secure link that is valid only once and has a preset validity period.

[0041] In one feasible implementation, the result encapsulation process employs a graceful degradation strategy to ensure uninterrupted data return, such as... Figure 5 As shown. When the original execution result format is abnormal, a fallback template is used to fill in some fields and the abnormal data format is explained in the summary visible to the operator. When the structured result mapping is missing a required field, the missing field is marked as unavailable and a text dump of the original execution result is attached to the appendix summary for manual analysis. When the generation of subsequent tasks times out, an empty list of subsequent tasks is returned without blocking the return. When the generation of the summary visible to the operator fails, a structured list of key indicators is returned as a substitute. All exceptions in the encapsulation process are captured and registered as security events without affecting the return of the encapsulated result.

[0042] The assembled result is packaged and transmitted back to the cloud-based intelligent agent via the communication channel, such as... Figure 6 As shown, the cloud-based intelligent agent receives and encapsulates the results, updates the lifecycle state of the task execution, and triggers an output security audit containing multiple types of information interception. After the audit passes, the final result is presented to the user. Each task execution step is recorded sequentially, and an audit event with an associated authorized snapshot identifier is generated and written to the audit event storage. Based on this, the cloud-based intelligent agent updates the state machine and authorized snapshot of the communication channel according to the feedback sequence and security events, and feeds back to the decision-making process that requires calling local tools. This ensures that subsequent distributions are based on the latest channel state and authorized scope, forming a closed loop of connection establishment and distribution, verification and execution, and encapsulation and feedback.

[0043] As can be seen from the above description, the A2A local task protocol and result encapsulation normalization output method provided in this application embodiment can ensure reliable communication through a full-duplex real-time communication channel and a heartbeat state machine, intercept forgery, tampering, replay and unauthorized access through a seven-dimensional security verification chain, unify the execution results of various tools through a five-field normalization encapsulation structure, and form a closed loop by updating the channel state machine and authorized snapshot according to the return timing and security events.

[0044] In one embodiment of the A2A local task protocol and result encapsulation normalization output method of this application, see [link to relevant documentation]. Figure 3 It can also specifically include the following: Step S201: The local device agent reads the cloud server address, workspace identifier, device identifier and credential information configured locally, obtains a short-term valid access token from the cloud authentication service with the credential information, and initiates a connection request to the real-time communication endpoint with the device identifier, workspace identifier and operating environment information. Step S202: When the cloud-based intelligent agent runs, it verifies the validity of the access token and confirms the binding relationship between the device identifier and the workspace identifier. After that, it accepts the connection and sends back the running initialization message. After the communication channel is established, both parties send heartbeat requests and heartbeat responses to each other at a preset heartbeat interval to maintain the channel activity. If no heartbeat is received from the other end for a preset number of consecutive cycles, the channel is determined to be interrupted and the channel is migrated to the reconnection state according to the exponential backoff strategy.

[0045] The establishment of the communication channel in step S101 is initiated by the local device intelligent agent, such as... Figure 3 As shown. After the local device agent starts, it reads the cloud server address, workspace identifier, device identifier, and credential information from the local configuration. The credential information is stored in the local credential storage in read-only mode. If the read fails, a configuration missing identifier is registered and the process is transferred to manual investigation without initiating a connection. Based on this, the local device agent initiates identity verification with the cloud authentication service using the credential information to obtain a short-term valid access token. The access token has a preset validity period and is actively refreshed by the local device agent before expiration to avoid token expiration and interruption during the connection process.

[0046] In one specific implementation, the local device agent initiates a connection request to the real-time communication endpoint, carrying device identifier, workspace identifier, operating system type, operating system version, and processor architecture information. The connection request carries the above information in the request header, and the runtime environment information is used for subsequent runtime environment compatibility verification in the seven-dimensional verification. After receiving the connection request, the cloud runtime verifies the validity of the access token and confirms the binding relationship between the device identifier and the workspace identifier. The binding relationship is established during device registration and recorded in the cloud device registry. After successful verification, the connection is accepted and a runtime initialization message is sent back.

[0047] The runtime initialization message is organized using a session identifier, heartbeat interval configuration, and maximum message size field, such as... Figure 3 As shown. The session identifier is a globally unique identifier for this connection, used for subsequent message association; the heartbeat interval configuration specifies the period at which both parties send heartbeats to each other; the maximum message size specifies the upper limit for a single message to prevent excessively large messages from blocking the channel. After receiving the run initialization message, the local device agent migrates to the connected state; if the connection fails or the token is invalid, it migrates to the disconnected state and registers the connection error identifier.

[0048] Optionally, after the connection is established, both parties exchange heartbeat requests and responses according to the configured heartbeat interval. The heartbeat message carries a local device status summary and network quality indicators, which the cloud uses to monitor the online status and link quality of the peer. If the local device agent does not receive a heartbeat response from the peer within a preset number of consecutive cycles, it determines that the channel is interrupted and migrates to the heartbeat timeout state, and then to the reconnection state, avoiding sending requests to the disconnected peer.

[0049] In one feasible implementation, reconnection employs an exponential backoff strategy, such as... Figure 3 As shown, the initial reconnection interval is a preset value, which is then doubled to a preset upper limit for each subsequent reconnection. The backoff strategy avoids overwhelming the cloud with frequent reconnections during link jitter and rebuilds the connection as quickly as possible when the link recovers. After a successful reconnection and receiving the run initialization message, the system migrates back to the connected state and restores the context of any unfinished tasks. If a preset number of consecutive reconnection failures occur, the system migrates to the disconnected state and registers a reconnection failure security event.

[0050] The state machine of the communication channel is organized and written into the connection state storage using fields such as state identifier, entry time, and recent migration reason, for both the cloud and local parties to query the current connection lifecycle. Authentication failure, network unreachability, protocol version mismatch, and message parsing failure are handled according to a tiered strategy. Among them, message parsing failure only sends back a security event message without interrupting the connection. The connection state storage uses the session identifier as the primary key for step S101 to read the channel status at the distribution entry point. When the channel is in a non-connected state, distribution is temporarily suspended and reconnection is triggered.

[0051] In one embodiment of the A2A local task protocol and result encapsulation normalization output method of this application, see [link to relevant documentation]. Figure 3 It can also specifically include the following: Step S301: When the cloud-based intelligent agent is running, it organizes a local tool request message on the communication channel. The local tool request message includes a request identifier, device identifier, workspace identifier, skill identifier and tool name, input parameters, pre-authorization token, tool component hash value and digital signature. Step S302: Calculate the message authentication code for all fields of the local tool request message except for the digital signature using the workspace-level shared key, and send the local tool request message to the local device agent through the communication channel. The pre-authorization token includes the method name, workspace identifier, skill identifier, parameter structure template, expiration time, and range of random numbers as pre-authorization elements.

[0052] The local tool request message described in step S101 is organized during the runtime of the cloud-based intelligent agent, such as... Figure 3As shown. After the cloud-based intelligent agent performs multi-dimensional risk scoring on user requests and determines the risk level, the parsing module derives the capability list for this session from the server. The capability list is derived based on the user's workspace permissions, roles, and current data access status. Accordingly, the cloud-based intelligent agent organizes local tool request messages on the communication channel. The local tool request messages are organized with request identifier, device identifier, workspace identifier, skill identifier, tool name, input parameters, pre-authorization token, tool component hash value, and digital signature fields.

[0053] In one specific implementation, the request identifier is generated as a globally unique string by combining the workspace identifier, timestamp, and random number, serving as the comparison key for the first-dimensional request identifier idempotency check; the device identifier points to the target local device, used for the second-dimensional device identifier matching check; the workspace identifier is used for the third-dimensional workspace identifier binding check; the skill identifier points to the skill package to which it belongs; the tool name points to the tool component to be loaded; the input parameters are the key-value structure required for tool execution; and the tool component hash value is the hash value of the tool component, used for the fifth-dimensional integrity check comparison.

[0054] The pre-authorization token is a scope pre-authorization credential issued during cloud runtime, organized with six scope pre-authorization elements: method name, workspace identifier, skill identifier, parameter structure template, expiration time, and random number. Figure 3 As shown. The method name limits the tools that can be called in this authorization, the parameter structure template limits the set of key names for the input parameters, the expiration time limits the validity period of the authorization, the random number is used to prevent replay, and the pre-authorization token is used for item-by-item verification by the fourth-dimensional tool authorization verification. The scope pre-authorization element makes the authorization granularity converge to the specific method and parameter structure rather than the overall device.

[0055] Optionally, during cloud runtime, a message authentication code is calculated using a workspace-level shared key for all fields of the local tool request message, excluding the digital signature, as the digital signature. The workspace-level shared key is distributed via a secure channel during device registration and stored separately in cloud key storage and local key storage; the key is not transmitted with the message. Based on this digital signature, it is sent along with the request message for comparison by the sixth-dimensional digital signature verification using the same key. Any tampering with any field during transmission will result in the recalculated message authentication code being inconsistent with the digital signature and thus intercepted.

[0056] In one feasible implementation, the assembled local tool request message is sent to the local device intelligent agent via the communication channel, such as... Figure 3 As shown. Before sending, the cloud runtime reads the channel status storage to confirm that the channel is connected. If the channel is in a heartbeat timeout or reconnection state, the sending is temporarily suspended and the request message is placed in the waiting queue. After the channel is restored, the message is sent in order. Messages that fail to send are registered with a sending exception flag and resent according to the backoff strategy.

[0057] The local tool request message is written to the cloud-based in-transit request table using the request identifier as the primary key. The in-transit request table records the request's dispatch time, target device, and current status, allowing the cloud to track the request's lifecycle and determine timeouts. In local event radar mode, the local device agent organizes and initiates a local tool request message in reverse direction when the triggering conditions are met. The direction is opposite to the regular dispatch, but its message structure and field organization are consistent with the regular dispatch. The in-transit request table uses the request identifier as the primary key for step S102 to associate and read the request context at the verification entry point.

[0058] In one embodiment of the A2A local task protocol and result encapsulation normalization output method of this application, see [link to relevant documentation]. Figure 4 It can also specifically include the following: Step S401: The local device agent maintains the memory cache and persistent storage of the processed request identifier, compares the request identifier of the local tool request message with it to identify duplicate requests and returns an idempotent response to duplicate requests, and performs strict comparisons between the device identifier of the local tool request message and the local device identifier, and between the workspace identifier and the locally bound workspace identifier to complete the device and workspace binding verification. Step S402: Parse the pre-authorization token verification validity period and the consistency of the method name, workspace identifier, skill identifier and parameter structure template of the local tool request message to complete the tool authorization verification; calculate the hash value of the tool component and compare it with the hash value of the tool component carried in the request using the constant time comparison method to complete the integrity verification; calculate the message authentication code of the request field with the workspace-level shared key and compare it with the digital signature to complete the signature verification; and verify the matching of the local operating environment and the tool's declared compatible platform and the local area network reach status to complete the seven-dimensional security verification chain.

[0059] Step S102 performs a seven-dimensional security check chain on the local tool request message, such as... Figure 4 As shown. After receiving a request, the local device agent first performs an idempotent check on the first-dimensional request identifier. It maintains a memory cache and persistent storage for processed request identifiers. The memory cache retains the most recent preset number of request identifiers to support high-frequency deduplication, while the persistent storage retains request identifiers within a preset time period to support deduplication after a restart. If a request identifier matches the cache or persistent storage, it is determined to be a duplicate request, and the cached result corresponding to that request identifier is returned directly without re-executing the tool. If it does not match, the request identifier is added to the cache and subsequent checks continue.

[0060] In one specific implementation, the second-dimensional device identifier matching verification performs a strict, case-sensitive string comparison between the device identifier in the request message and the local device identifier. If they match, the comparison passes; otherwise, a security event is registered and a device identifier mismatch error is returned. The third-dimensional workspace identifier binding verification reads the workspace identifier bound to the device during registration in the local configuration and strictly compares it with the workspace identifier in the request message. This verification ensures that a device can only execute instructions from its own workspace, preventing devices of the same model from being misled to execute instructions from other workspaces, thus preventing cross-departmental unauthorized access.

[0061] Based on this, a fourth-dimensional tool authorization verification is performed. The pre-authorization token is parsed, and the following checks are sequentially performed: whether it is within its validity period; whether the method name matches the requested tool name; whether the workspace identifier and skill identifier match the request; and whether the parameter structure template matches the requested input parameter structure. Parameter structure matching is based on a subset of the key name set defined in the template as the request parameter key name set. If any sub-condition is not met, the tool authorization verification fails. The verification result object is organized with fields for verification pass flag, failure dimension number, failure reason description, verification time, and audit event identifier, recording the verification process dimension by dimension.

[0062] The fifth-dimensional tool component integrity verification locates the corresponding tool component file based on the tool name and calculates its hash value. This hash value is then compared with the tool component hash value carried in the request message using a constant-time comparison method. Figure 4 As shown. The constant-time comparison method makes the comparison time independent of the first difference position to resist timing side-channel analysis. If the comparison is consistent, it passes; if inconsistent, a security event is registered and an integrity verification failure is returned. This verification ensures that the locally executed tool component is consistent with the version expected in the cloud, preventing the tool component from being maliciously replaced and executed.

[0063] Optionally, the sixth-dimensional digital signature verification uses the workspace-level shared key stored locally to recalculate the message authentication code for all fields of the request message except the digital signature. This code is then compared with the digital signature carried in the request. If the recalculated value matches the digital signature, the verification passes; otherwise, a security event is registered and a digital signature verification failure is returned. This verification confirms that the request message has not been tampered with during transmission. Both the fifth and sixth-dimensional keys and hashes are compared locally, without transmitting the keys or the original text back, reducing the risk of sensitive information exposure.

[0064] The seventh dimension, runtime environment compatibility and LAN reach verification, checks whether the local operating system type and processor architecture are on the compatibility platform list declared by the tool component, and whether the local device is in a LAN environment reachable from the cloud runtime. If both are satisfied, the entire seven-dimensional security verification chain passes and the verification time is recorded. Figure 4As shown. The verification result object is associated with the security event and subsequent execution by the audit event identifier. When the verification pass flag is true, the execution stage of step S102 reads it to load the tool component, and when the verification pass flag is false, it reads the failure dimension number to enter the hierarchical handling.

[0065] In one embodiment of the A2A local task protocol and result encapsulation normalization output method of this application, see [link to relevant documentation]. Figure 4 It can also specifically include the following: Step S501: When the seven-dimensional verification is passed, the local device intelligent agent loads the corresponding tool component according to the tool name in the local tool request message and executes it with the input parameters. It records the task running steps including the tool loading time, execution start time, execution parameters and intermediate states. The hash value of the previous task running step is used as the input of the next task running step to form a traceable record chain. Step S502: When any dimension verification fails, the local device agent stops subsequent verifications according to the fast failure strategy and generates a security event containing event type, failure dimension number, failure reason and authorized snapshot identifier. The security event is reported to the cloud agent in real time through the communication channel and written to the local audit log. For verification failures in the tool component integrity dimension and digital signature dimension, a local security lock is triggered to suspend the receipt of new local tool requests.

[0066] After step S102, the seven-dimensional verification passes, proceed with the tool execution, as follows: Figure 4 As shown, the local device agent loads the corresponding tool component from the local tool component library based on the tool name in the local tool request message. It then executes the tool operation using the input parameters of the request message. The tool component library is organized using the tool name and version as the primary key. Tools that fail to load are registered with a loading exception flag and a failure response is returned before execution without proceeding. During execution, the local runtime records the task execution steps, organized using fields for tool loading time, execution start time, execution parameters, and intermediate states.

[0067] In one specific implementation, the local runtime uses the hash value of the previous task execution step as the input for the next task execution step, allowing each step to be sequentially chained into a traceable execution record. Any change in the content of any step will cause a change in the hash value of subsequent steps, thus being detected and providing a verifiable execution trajectory for post-event auditing. The task execution steps are written to the local task execution storage using the task execution identifier as the primary key. The task execution identifier is associated with the request identifier and the authorization snapshot identifier. The original execution result generated after execution is read by step S103 to enter the encapsulation process.

[0068] Accordingly, the execution of equipment control tasks employs pre- and post-execution state recording. For example, before restarting a gate controller, the network connection status, module status, and mechanical status are recorded. After execution, the status is re-collected after a preset time to determine the execution effect. If the execution effect does not meet expectations, a failure flag is registered and sent back to the cloud for decision-making on subsequent handling. Multi-step tasks are executed in a predefined order, with the output of the previous step serving as the input of the next step, forming a complete execution chain.

[0069] In one feasible implementation, if any dimension verification fails, the local device agent stops subsequent verifications according to a fail-fast strategy and generates a security event, such as... Figure 4 As shown. The security events are organized using the fields of event type, failure dimension number, failure reason, request identifier, device identifier, workspace identifier, timestamp, and authorization snapshot identifier. The event type is marked as security verification failure, the failure dimension number points to the specific dimension that failed, and the authorization snapshot identifier is associated with the authorization scope on which this request is based, for tracing the source of authorization afterward.

[0070] The security events are reported to the cloud in real time via the communication channel and written to the local audit log. Upon receiving the report, the cloud updates the status of the request in the in-transit request table and triggers the corresponding alarm. Security denials are handled according to the failure dimension. Failures in the first to third dimensions are considered general security risks, which are only logged and a rejection response is returned. Failures in the fifth and sixth dimensions are considered serious security risks, which trigger a local security lock, suspending the reception of new local tool requests until manual review and unlocking.

[0071] Optionally, the security rejection response message body is organized with fields for rejection reason, failure dimension number, and suggested handling measures. The cloud uses this information to prompt the user with the rejection reason and handling suggestions, such as... Figure 4 As shown. During the local security lock period, local tool requests arriving are registered with a lock period rejection flag and a lock-in response is sent back to avoid requests being silently dropped during the lock period. The generated original execution result or security rejection response is written to the local response cache with the request flag as the primary key, so that step S103 can read it by the primary key at the encapsulation or return entry point. When a duplicate request hits the cache, it can be directly reused to support the first-dimensional idempotent response.

[0072] In one embodiment of the A2A local task protocol and result encapsulation normalization output method of this application, see [link to relevant documentation]. Figure 5 It can also specifically include the following: Step S601: Select the corresponding structured result template according to the tool type of the original execution result, map the original execution result to the standard key name, and normalize the mapped numeric field, timestamp field and enumeration value field according to the preset precision, unified time format and standard code value to generate structured results; Step S602: Generate subsequent to-do items and memory update suggestions for the structured results based on the preset rule family and lightweight model. Generate an operator-visible summary based on the structured results using a natural language generation template and generate an attachment summary for the attachments generated in this execution. Assemble the five types of standard fields into a result package. Perform graceful degradation for abnormal original execution result format, missing fields, and timeout of to-do item generation by returning a fallback template, default annotation, and empty list, respectively.

[0073] After the raw execution result generated in step S102 is ready, the execution result is encapsulated, such as... Figure 5 As shown, the local device intelligent agent invokes the result encapsulation generator. Based on the tool type of the original execution result, it selects the corresponding template from the structured result template library. The structured result template library is organized by tool type as the primary key, and each template defines the set of standard key names output by that type of tool. Accordingly, the result encapsulation generator maps the original fields of the original execution result to the standard key names. When a corresponding template is missing, a template missing flag is registered, and a general key-value pass-through template is used as a fallback to generate the structured result.

[0074] In one specific implementation, the mapping process normalizes different types of fields. Numerical fields are normalized to a preset precision; for example, monetary fields are uniformly retained to two decimal places, and percentage fields are uniformly retained to one decimal place. Timestamp fields are uniformly converted to a standard time format. Enumerated value fields are uniformly mapped to predefined standard code values; for example, the execution action is uniformly represented by three standard code values: rise, fall, and hold. Normalization ensures that similar data returned by devices from different manufacturers have consistent key names, units, and value ranges. The cloud-based intelligent agent can then parse the data in a unified manner without maintaining dedicated parsing logic for each type of device.

[0075] Based on this result, the encapsulation generator generates subsequent pending tasks. These pending tasks are string arrays, generated by the rule engine according to the content of the structured result and matched against preset rule families. Each rule family contains several predefined rules; for example, when the actual amount received is lower than a preset percentage of the amount due, a pending task for verifying abnormal transaction records is generated; when the number of available parking spaces is lower than a preset percentage of the total number of parking spaces, a pending task for enabling traffic limiting guidance is generated. A lightweight model is used to assist in rule matching to cover cases where the rules are not exhaustive. When rule matching times out, an empty list of subsequent pending tasks is returned without blocking the encapsulation.

[0076] Optionally, the result encapsulation generator generates memory update suggestions, which are structured objects organized by update type, memory key name, memory value, validity period, and priority fields, such as... Figure 5As shown. The update type includes add, modify, and delete. The memory key name points to the entry in the cloud memory storage. The validity period limits the validity of the memory, and the priority is used by the cloud to choose when memory capacity is limited. The result encapsulation generator then generates a summary visible to the operator based on the key indicators of the structured results using a natural language template. The length of the summary visible to the operator is controlled within a preset range so that the operator can quickly understand it.

[0077] In one feasible implementation, the result encapsulation generator checks whether the execution generates attachments and generates attachment summaries for the execution log, screenshots, and exported data files. The attachment summary is an array of objects, with each attachment object organized by fields for attachment identifier, attachment type, attachment name, file size, and download address. The download address is a secure link that is valid only once and has a preset validity period to prevent attachments from being exposed for a long time. The result encapsulation generator assembles five standard fields—structured results, follow-up tasks, memory update suggestions, operator-visible summary, and attachment summary—into a result encapsulation and serializes it.

[0078] The assembly of the encapsulated results employs a graceful degradation strategy to ensure uninterrupted data return, such as... Figure 5 As shown. When the original execution result format is abnormal, it is filled with a catch-all template and the data format in the operator-visible summary description is abnormal. When the structured result lacks a required field, the missing field is marked as unavailable and a text dump of the original execution result is attached to the appendix summary. When the operator-visible summary generation fails, a structured key indicator list is used instead. All exceptions during the encapsulation process are captured and registered as security events without affecting the return of the encapsulated result. The assembled result encapsulation uses the request identifier as the primary key for step S103 to read at the return entry point.

[0079] In one embodiment of the A2A local task protocol and result encapsulation normalization output method of this application, see [link to relevant documentation]. Figure 6 It can also specifically include the following: Step S701: After receiving the encapsulated result, the cloud-based intelligent agent updates the lifecycle status of the task execution and triggers an output security audit containing multiple types of information interception. It records each task execution step in sequence and generates an audit event with associated authorized snapshot identifier, which is then written into the audit event storage to form a traceable audit closed loop. Step S702: Apply differentiated constraints to the invocation of local tools according to the execution mode bound to the task. In workflow mode, execute in a predefined order and reject system commands by default. In personal agent mode, add user confirmation to write access level and critical risk level operations. In gateway agent mode, convert external standardized requests into local tool invocations and record audits in full. In local event radar mode, the local device agent initiates a local tool request in reverse when the trigger condition is met.

[0080] The result described in step S103 is encapsulated and sent back for processing by the cloud-based intelligent agent, such as... Figure 6 As shown, the cloud-based intelligent agent receives and encapsulates the results, updates the task's lifecycle status (which can be in progress, completed, or failed), and triggers an output security review that includes multiple types of information interception. This review checks the content intended for presentation to the user within the encapsulated results against preset information interception rules. If sensitive information is detected, it is either de-identified or blocked before presentation. Once the review is passed, the cloud-based intelligent agent presents the user with a summary visible to the operator and the structured results.

[0081] In one specific implementation, the cloud-based intelligent agent records each task execution step sequentially and generates audit events. These audit events are organized using fields such as event identifier, task execution identifier, request identifier, authorization snapshot identifier, time, and event content. The authorization snapshot identifier is associated with the user identity, role, workspace permissions, and pre-authorization status frozen for this task, ensuring that each execution can be traced back to its authorization source. Audit events are written to the audit event storage, and each task execution step uses the hash value of the previous step as input for the next step, forming a traceable audit loop that supports post-event verification and accountability.

[0082] Accordingly, the cloud-based intelligent agent updates the state machine and authorization snapshot of the communication channel based on the feedback sequence and security events, such as... Figure 6 As shown. When the return is timely and there are no security events, the connected state and the current authorized snapshot are maintained. When the return times out, the heartbeat status is used to determine whether the channel is abnormal and a state transition is triggered if an abnormality is detected. When a security event is received, the scope of the authorized snapshot is narrowed down according to the severity of the event. The updated channel state and authorized snapshot are fed back to the decision-making process that requires calling local tools, so that subsequent distribution is based on the latest channel state and authorized scope.

[0083] In one feasible implementation, the cloud-based intelligent agent imposes differentiated constraints on the invocation of local tools based on the execution mode bound to the task, such as... Figure 6 As shown, the workflow model is designed for automated business processes. Task execution steps are strictly executed in a predefined order, and system command execution is rejected by default. Operations at the reach level and critical risk level must be pre-authorized and confirmed. The task definition clearly specifies the list of allowed skill packs and the maximum risk level limit, and these constraints are strictly enforced during runtime.

[0084] The Personal Intelligent Agent mode targets the personal assistant scenario for business operators. The intelligent agent interacts with users in a conversational format and supports natural language input. Execution results are displayed in the conversation in a packaged form. Read-level and analysis / suggestion-level operations are executed directly, while write-level and critical risk-level operations require user confirmation. The Gateway Intelligent Agent mode targets inter-system integration scenarios. The intelligent agent acts as a protocol gateway, receiving external standardized requests and converting them into local tool calls. After execution, the results are packaged and returned in the format expected by the external system. All calls are fully logged and audited.

[0085] Local event radar mode is designed for real-time monitoring and alarm scenarios, such as... Figure 6 As shown, the local device agent continuously monitors the specified local data source and initiates a local tool request in reverse direction when the trigger condition is met, opposite to the normal distribution direction. This mode requires the local device agent to have a local rule engine to independently complete simple judgments and actions in offline mode. The four execution modes share the same seven-dimensional security verification chain and result encapsulation normalization structure, differing only in the trigger direction, executable risk level, and confirmation strategy. The execution mode identifier is written to the task execution storage with the task execution identifier as the primary key, for step S101 to read at the distribution decision entry point to apply corresponding constraints, forming a closed loop of chain establishment, verification, encapsulation, and backflow.

[0086] To implement all or part of the method, this application provides an embodiment of an apparatus for implementing the A2A local task protocol and result encapsulation normalization output method, see [link to embodiment]. Figure 2 The device specifically includes the following components: The channel management module is used to establish a full-duplex real-time communication channel between the cloud-based intelligent agent and the local device intelligent agent during operation, verify the binding relationship between the access token and the device and workspace identifier, maintain channel activity and state machine transition according to a preset heartbeat mechanism, and trigger reconnection according to an exponential backoff strategy when the channel is interrupted. The request delivery module is used to organize classified messages, including runtime initialization messages, local tool request and response messages, heartbeat messages, and security event messages, on the communication channel. When the cloud agent determines that a local tool needs to be called based on the capability list, it organizes a local tool request message containing a request identifier, device and workspace identifier, pre-authorization token, tool component hash value, and digital signature, and delivers it through the communication channel. The security verification module is used to verify the received local tool request message according to the seven-dimensional security verification chain. It performs dimension-by-dimensional verification of the request identifier idempotency and binding with the device and workspace identifier, tool authorization and tool component integrity, digital signature and runtime environment and local area network access. If any dimension verification fails, it stops the subsequent verification according to the fast failure strategy and handles the failure according to the failure dimension. The tool execution module is used to load the corresponding tool component according to the tool name and execute it with the input parameters when the seven-dimensional verification passes, generate the original execution result, record the task operation steps including the tool loading time, execution start time and intermediate state, and generate a security event report and trigger local security lock when the verification fails. The result encapsulation module is used to map the original execution result into a result encapsulation containing structured results, subsequent tasks, memory update suggestions, operator-visible summary, and attachment summary according to a preset normalized encapsulation structure, and transmit the result encapsulation back to the cloud intelligent agent through the communication channel to trigger task running status update and output security review.

[0087] The channel management module establishes a full-duplex real-time communication channel between the cloud-based intelligent agent and the local device intelligent agent during runtime, such as... Figure 2 As shown, after verifying the validity of the access token and confirming the binding relationship between the device identifier and the workspace identifier, the connection is accepted and a runtime initialization message is sent back. Heartbeat requests and responses are exchanged according to a preset heartbeat mechanism to maintain channel activity. A state machine manages six connection states: initial, connecting, connected, heartbeat timeout, reconnecting, and disconnected. Reconnection is triggered according to an exponential backoff strategy when the channel is interrupted. The request delivery module organizes categorized messages on the communication channel, including runtime initialization messages, local tool request and response messages, heartbeat messages, and security event messages. When the cloud agent determines that a local tool needs to be called based on the capability list, it organizes a local tool request message containing the request identifier, device and workspace identifiers, skill identifier, tool name, input parameters, pre-authorization token, tool component hash value, and digital signature. The message authentication code is calculated using the workspace-level shared key for all fields except the digital signature, and then sent through the communication channel as a digital signature.

[0088] The security verification module verifies the received local tool request message dimension by dimension according to the seven-dimensional security verification chain, such as... Figure 2 As shown, the following checks are performed sequentially: request identifier idempotency verification, device identifier matching verification, workspace identifier binding verification, tool authorization verification, tool component integrity verification, digital signature verification, runtime environment compatibility verification, and LAN reach verification. If any dimension verification fails, subsequent verifications are stopped according to a fast-failure strategy, and the failure is handled in a tiered manner according to the dimension. Failure in the tool component integrity dimension and digital signature dimension verification triggers a local security lock. When the seven-dimensional verification passes, the tool execution module loads the corresponding tool component according to the tool name and executes it with the input parameters to generate the original execution result. It records the task execution steps, including the tool loading time, execution start time, execution parameters, and intermediate states, and uses the hash value of the previous step as the input for the next step to form a traceable execution record. When verification fails, a security event is generated, reported to the cloud, and written to the local audit log.

[0089] The result encapsulation module maps the original execution result into a result encapsulation containing structured results, subsequent tasks, memory update suggestions, an operator-visible summary, and an attachment summary, according to a preset normalized encapsulation structure. Figure 2 As shown, a structured result template is selected based on the tool type to map the original fields to standard key names and normalize the numerical, timestamp, and enumeration value fields. Subsequent to-do and memory update suggestions are generated based on the preset rule family and lightweight model. A summary visible to the operator is generated using a natural language generation template, and an attachment summary is generated for the attachments generated during execution. For format anomalies, missing fields, and generation timeouts, graceful degradation is performed using a fallback template, default annotation, and empty list return. The results are then encapsulated and transmitted back to the cloud intelligent agent through the communication channel. After receiving the results, the cloud intelligent agent updates the task running status, triggers an output security review containing multiple types of information interception, and updates the channel state machine and authorized snapshot based on the transmission sequence and security events before transmitting them back to the issuing decision. The five modules work together to achieve a closed loop of full-duplex channel management, seven-dimensional security verification, and result normalization transmission.

[0090] As can be seen from the above description, the A2A local task protocol and result encapsulation normalization output device provided in this application embodiment can perform full-duplex channel management, seven-dimensional security verification and result normalization return on the process of cloud intelligent agents calling local device tools through the collaboration of five modules: channel management, request issuance, security verification, tool execution and result encapsulation.

[0091] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described method.

[0092] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0093] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method.

[0094] In this embodiment, a full-duplex real-time communication channel is established between the cloud-based intelligent agent and the local device intelligent agent during runtime, and the channel activity and state machine transition are maintained by a heartbeat mechanism. A seven-dimensional security verification chain is used to verify the idempotency of the request identifier, the binding of the device and workspace identifiers, tool authorization, tool component integrity, digital signature, and accessibility of the operating environment and local area network. The execution results of various tools are unified by normalizing and encapsulating five fields: structured results, subsequent tasks, memory update suggestions, operator-visible summary, and attachment summary. The state machine and authorization snapshot of the communication channel are updated according to the feedback sequence and security events, and then fed back to the decision-making process for determining whether to call the local tool to form a closed loop.

[0095] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for A2A local task protocol and result encapsulation normalization output, characterized in that, The method includes: A full-duplex real-time communication channel is established between the cloud-based intelligent agent and the local device intelligent agent during operation, and the channel activity and state machine transition are maintained according to a preset heartbeat mechanism. When the cloud-based intelligent agent determines that it needs to call a local tool based on the capability list, it sends a local tool request message carrying multi-dimensional security verification elements to the local device intelligent agent through the communication channel. After receiving the local tool request message, the local device intelligent agent performs a seven-dimensional security verification chain to check the idempotency of the request identifier and the binding of the device and workspace identifiers, the tool authorization and the integrity of the tool components, and the digital signature and the accessibility of the operating environment and local area network. When the seven-dimensional verification passes, the corresponding tool component is loaded and executed to generate the original execution result. If any dimension fails, execution is rejected and a security event is reported through the communication channel. The original execution result is mapped into a result encapsulation containing five standard fields: structured result, subsequent tasks, memory update suggestions, operator-visible summary, and attachment summary, according to a preset normalized encapsulation structure. The encapsulated result is then transmitted back to the cloud intelligent agent via the communication channel to update the task running status and trigger output security review. Based on the transmission sequence and security events, the state machine and authorization snapshot of the communication channel are updated and then fed back to the decision-making process that determines whether to call local tools.

2. The A2A local task protocol and result encapsulation normalization output method according to claim 1, characterized in that, The establishment of a full-duplex real-time communication channel between the cloud-based intelligent agent and the local device intelligent agent during operation, and the maintenance of channel activity and state machine transition according to a preset heartbeat mechanism, includes: The local device intelligent agent reads the cloud server address, workspace identifier, device identifier and credential information configured locally, obtains a short-term valid access token from the cloud authentication service with the credential information, and initiates a connection request to the real-time communication endpoint with the device identifier, workspace identifier and operating environment information. When the cloud-based intelligent agent runs, it verifies the validity of the access token and confirms the binding relationship between the device identifier and the workspace identifier. After accepting the connection, it sends back a running initialization message. After the communication channel is established, both parties send heartbeat requests and heartbeat responses to each other at a preset heartbeat interval to maintain channel activity. If no heartbeat is received from the other end for a preset number of consecutive cycles, the channel is determined to be interrupted and migrates to the reconnection state according to the exponential backoff strategy.

3. The A2A local task protocol and result encapsulation normalization output method according to claim 1, characterized in that, When the cloud-based intelligent agent determines that a local tool needs to be invoked based on the capability list, it sends a local tool request message carrying multi-dimensional security verification elements to the local device intelligent agent through the communication channel, including: When the cloud-based intelligent agent is running, it organizes local tool request messages on the communication channel. The local tool request message includes a request identifier, device identifier, workspace identifier, skill identifier and tool name, input parameters, pre-authorization token, tool component hash value and digital signature. The message authentication code is calculated using the workspace-level shared key on all fields of the local tool request message except for the digital signature, and is used as the digital signature. The local tool request message is then sent to the local device agent via the communication channel. The pre-authorization token includes pre-authorization elements such as method name, workspace identifier, skill identifier, parameter structure template, expiration time, and range of random numbers.

4. The A2A local task protocol and result encapsulation normalization output method according to claim 1, characterized in that, After receiving the local tool request message, the local device agent performs a step-by-step verification according to the seven-dimensional security verification chain, including binding the request identifier to the device and workspace identifier, tool authorization and tool component integrity, digital signature and runtime environment and local area network access. The local device agent maintains a memory cache and persistent storage for processed request identifiers, compares the request identifier of the local tool request message with it to identify duplicate requests and returns an idempotent response to duplicate requests, and performs strict comparisons between the device identifier of the local tool request message and the local device identifier, and between the workspace identifier and the locally bound workspace identifier to complete the device and workspace binding verification. The tool authorization verification is completed by parsing the pre-authorization token validity period and verifying the consistency of the method name, workspace identifier, skill identifier, and parameter structure template in the local tool request message. The hash value of the tool component is calculated and compared with the hash value of the tool component carried in the request using the constant time comparison method to complete the integrity verification. The message authentication code is calculated on the request field using the workspace-level shared key and compared with the digital signature to complete the signature verification. Finally, the matching of the local operating environment and the tool's declared compatible platform and the local area network reach status are verified to complete the seven-dimensional security verification chain.

5. The A2A local task protocol and result encapsulation normalization output method according to claim 1, characterized in that, When the seven-dimensional verification passes, the corresponding tool component is loaded and executed to generate the original execution result. If any dimension fails, execution is rejected and a security event is reported via the communication channel, including: When the seven-dimensional verification is passed, the local device intelligent agent loads the corresponding tool component according to the tool name in the local tool request message and executes it with the input parameters. It records the task execution steps including the tool loading time, execution start time, execution parameters and intermediate states. The hash value of the previous task execution step is used as the input of the next task execution step to form a traceable record chain. If any dimension verification fails, the local device agent stops subsequent verifications according to the fast failure strategy and generates a security event containing the event type, failure dimension number, failure reason and authorized snapshot identifier. The security event is reported to the cloud agent in real time through the communication channel and written to the local audit log. For verification failures in the tool component integrity dimension and digital signature dimension, a local security lock is triggered to suspend the receipt of new local tool requests.

6. The A2A local task protocol and result encapsulation normalization output method according to claim 1, characterized in that, The process of mapping the original execution result into a result encapsulation containing five standard fields—structured result, subsequent pending tasks, memory update suggestions, operator-visible summary, and attachment summary—according to a preset normalized encapsulation structure includes: Based on the tool type of the original execution result, select the corresponding structured result template to map the original execution result to the standard key name, and normalize the mapped numeric field, timestamp field and enumeration value field according to the preset precision, unified time format and standard code value to generate structured results; Based on the preset rule family and lightweight model, subsequent to-do items and memory update suggestions are generated for the structured results. A business-visible summary is generated based on the structured results using a natural language generation template, and an attachment summary is generated for the attachments generated in this execution. The five types of standard fields are assembled into a result package. For abnormal original execution result format, missing fields, and timeout of to-do item generation, graceful degradation is performed by returning a fallback template, default annotation, and empty list, respectively.

7. The A2A local task protocol and result encapsulation normalization output method according to claim 1, characterized in that, The process involves encapsulating the results via the communication channel and transmitting them back to the cloud-based intelligent agent to update the task's running status and trigger an output security review. Based on the transmission sequence and security events, the state machine and authorization snapshot of the communication channel are updated and then fed back to the decision-making body that determines whether to call local tools. This includes: After receiving and encapsulating the results, the cloud-based intelligent agent updates the lifecycle status of the task execution and triggers an output security audit containing multiple types of information interception. It records each task execution step in sequence and generates an audit event with associated authorized snapshot identifier, which is then written into the audit event storage to form a traceable audit closed loop. Differentiated constraints are imposed on the invocation of local tools according to the execution mode bound to the task. In workflow mode, the invocation is executed in a predefined order and system commands are rejected by default. In personal agent mode, user confirmation is added to write access level and critical risk level operations. In gateway agent mode, external standardized requests are converted into local tool invocations and fully recorded for auditing. In local event radar mode, the local device agent initiates local tool requests in reverse when the trigger conditions are met.

8. An A2A local task protocol and result encapsulation normalization output device, characterized in that, The device includes: The channel management module is used to establish a full-duplex real-time communication channel between the cloud-based intelligent agent and the local device intelligent agent during operation, verify the binding relationship between the access token and the device and workspace identifier, maintain channel activity and state machine transition according to a preset heartbeat mechanism, and trigger reconnection according to an exponential backoff strategy when the channel is interrupted. The request delivery module is used to organize classified messages, including runtime initialization messages, local tool request and response messages, heartbeat messages, and security event messages, on the communication channel. When the cloud agent determines that a local tool needs to be called based on the capability list, it organizes a local tool request message containing a request identifier, device and workspace identifier, pre-authorization token, tool component hash value, and digital signature, and delivers it through the communication channel. The security verification module is used to verify the received local tool request message according to the seven-dimensional security verification chain. It performs dimension-by-dimensional verification of the request identifier idempotency and binding with the device and workspace identifier, tool authorization and tool component integrity, digital signature and runtime environment and local area network access. If any dimension verification fails, it stops the subsequent verification according to the fast failure strategy and handles the failure according to the failure dimension. The tool execution module is used to load the corresponding tool component according to the tool name and execute it with the input parameters when the seven-dimensional verification passes, generate the original execution result, record the task operation steps including the tool loading time, execution start time and intermediate state, and generate a security event report and trigger local security lock when the verification fails. The result encapsulation module is used to map the original execution result into a result encapsulation containing structured results, subsequent tasks, memory update suggestions, operator-visible summary, and attachment summary according to a preset normalized encapsulation structure, and transmit the result encapsulation back to the cloud intelligent agent through the communication channel to trigger task running status update and output security review.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the A2A local task protocol and result encapsulation normalization output method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the A2A local task protocol and result encapsulation normalization output method as described in any one of claims 1 to 7.

Images