Agent gateway implementation method and system based on a2a protocol

Abstract

The application discloses an agent gateway implementation method and system based on an A2A protocol and belongs to the technical field of agent communication and governance. The system comprises a registration center, an A2A gateway and a management platform which are independently deployed and functionally decoupled. The method comprises the following steps: the registration center receives agent registration information and stores the credentials in an encrypted manner; the A2A gateway synchronizes the registration information from the registration center, maintains a local cache, uniformly authenticates calling parties carrying access tokens, converts the protocol versions according to the declared protocol versions of target agents, finds a URL based on the local cache and forwards a request, and returns a response to the calling party; and the management platform is responsible for credential management and operation and maintenance monitoring. The application realizes unified authentication, unified governance and unified observability of agents, solves the incompatibility problem of high and low versions of the A2A protocol, and is suitable for enterprise-level agent large-scale application scenarios.

Description

Technical Field

[0001] This application relates to the fields of intelligent agent communication and intelligent agent governance technology, specifically to an intelligent agent gateway implementation method and system based on the A2A protocol. Background Technology

[0002] With the maturity of large-scale modeling technology, the application of AI agents in enterprises is becoming increasingly widespread. To better support business operations and serve customers, enterprises are continuously developing agents tailored to different business scenarios (such as intelligent investment advisors, intelligent risk control, intelligent marketing, and intelligent customer service). Complex business processes often require the coordination and collaboration of multiple specialized agents. However, these agents are typically scattered across different teams and business systems. Each agent is built based on its own business scenario and different technical frameworks, resulting in diverse business functions, heterogeneous technologies, and a lack of unified interaction standards. How to enable them to interact and collaborate, how to uniformly expose and reuse them externally, and how to establish a shared interactive infrastructure for agents are the core challenges enterprises face when implementing large-scale AI agent applications.

[0003] The Agent2Agent (A2A) protocol is an open intelligent agent interaction standard that supports three protocols: JSON-RPC, gRPC, and HTTP+JSON / REST. It defines standard interaction specifications for task assignment, status query, message streaming return, and push notification.

[0004] When introducing large-scale models and intelligent agent technologies, securities firms face stringent regulatory constraints and compliance requirements: 1) Technological independence and controllability: The core systems of securities companies must meet the requirements of financial information technology innovation and independent controllability. Key technical infrastructure cannot rely on a single external vendor or closed-source black box, and must have the ability to develop, manage, and audit. 2) System security and permission classification: Securities business involves sensitive data such as customer identity, transactions, holdings, and funds. Intelligent agent calls must follow the principles of least privilege, permission classification, and auditing. Unauthorized intelligent agent capability information, endpoint information, and skill lists must not be exposed to the outside world. 3) Sensitive and controllable data: Customer data, investment research data, risk control model data, etc. are highly sensitive data. The flow of data across intelligent agents must have clear data boundaries and auditable links to avoid unauthorized data flow. 4) Unified management and monitoring: Securities companies have many systems and departments. During the independent construction of intelligent agents by each business line, there are situations where duplicate construction and inability to share are occurred. Unified registration, control and monitoring are needed to avoid duplicate construction and waste of resources, and to meet the requirements of company-level intelligent agent governance and regulatory reporting.

[0005] The A2A protocol addresses the standard issue of "how agents communicate," but it doesn't specify implementation mechanisms for "unified registration, discovery, authentication, and governance" in enterprise-level scenarios. These are precisely the aspects that enterprises must address when deploying intelligent agents at scale.

[0006] Currently, there are two main ways to implement interaction between intelligent agents.

[0007] Method 1: For example Figure 1 As shown, this is a point-to-point direct connection based on API / MCP interfaces. The remote agent directly exposes a RESTful API or MCP (Model Context Protocol) interface, and the client agent requests data from the remote agent according to the corresponding protocol. The client agent maintains the access information of the remote agent (including the target URL and authentication method) through hard-coding or configuration files, and initiates a direct connection request to the remote agent at an appropriate time after the program starts.

[0008] Method 2: For example Figure 2 As shown, this is a point-to-point direct connection based on the A2A protocol. The interaction between agents uses the A2A protocol, but in a point-to-point direct connection manner. The remote agent exposes its AgentCard according to the A2A protocol, and the client agent configures the remote agent's AgentCard access address. The client agent retrieves the remote agent's AgentCard to obtain information such as the remote agent's URL, protocol version, and authentication method, and caches it locally. At an appropriate time, the client agent initiates a task request to the remote agent. After the remote agent returns the task object information, the interaction between the agents is realized.

[0009] The existing implementation methods described above have the following problems: For Method 1, the API / MCP approach addresses the "tool invocation" problem, which involves passing structured input to an agent and receiving structured output. It is suitable for stateless functional calls but has the following drawbacks: 1) The API / MCP approach is simply a tool invocation and cannot provide the capabilities required for agent collaboration, such as task lifecycle management, multi-round context maintenance, and push notifications. It essentially downgrades the agent to a stateless tool, failing to leverage the agent's autonomous collaboration capabilities; 2) Different agents expose API interfaces with varying styles, and the MCP tool descriptions are inconsistent. Client agents need to be adapted individually for each agent, increasing development costs.

[0010] For method two, such as Figure 2 As shown, the A2A protocol can solve the problem of missing agent collaboration semantics in Method 1 (the A2A protocol natively supports task assignment, status query, message streaming return, push notification, etc.), but this point-to-point direct connection has the following problems: 1) Lack of unified authentication: The official A2A protocol specification takes a relatively simple approach to authentication, with remote agents only exposing themselves directly through the `securitySchemes` field of the `AgentCard`. The acquisition and issuance of authentication credentials are outside the A2A protocol specification, while enterprise applications must consider authentication and authorization, including the issuance, rotation, revocation, and auditing of authentication credentials. Furthermore, in point-to-point direct connections, each caller must maintain the authentication information for all remote agents, resulting in scattered credentials that are difficult to manage centrally.

[0011] 2) Lack of an intelligent agent governance system: The point-to-point direct connection method is too decentralized and lacks unified management. For example, an enterprise may have multiple business intelligent agents such as intelligent investment advisory agents, risk control agents, and marketing agents, which are built and deployed independently by different teams and departments. They are unaware of each other's existence, and there is no unified place to know which intelligent agents in the company can be reused, which easily leads to redundant construction. At the same time, there is no unified access point exposed to the outside world. When external systems or client intelligent agents in the company want to use a certain intelligent agent, they need to find the corresponding team to understand the address, protocol, authentication method and other information before they can connect. The operation and maintenance costs are high and cannot meet the requirements of unified governance of intelligent agents at the enterprise level.

[0012] 3) Lack of unified observability leads to difficulties in fault location: Both client-side and remote agents record their own logs, lacking unified monitoring and maintenance methods. It is impossible to statistically analyze the usage, success rate, and response time of each agent, making it difficult to perform capacity planning and fault location.

[0013] 4) Significant version incompatibility in the A2A protocol: The A2A protocol exists in two versions, v0.3 and v1.0, which are incompatible in terms of method names, message structures, task states, and other formats. When both old and new versions of intelligent agents coexist within an enterprise, each new intelligent agent added to the caller's system may require additional version adaptation, resulting in high maintenance costs. Furthermore, after an intelligent agent is upgraded, older versions may become inaccessible to callers, necessitating modifications to the caller's code. Summary of the Invention

[0014] To address the shortcomings of existing technologies, this application provides a method and system for implementing an intelligent agent gateway based on the A2A protocol. By coordinating three independently deployed components—a registration center, an A2A gateway, and a management platform—it aims to solve the problems of lack of unified authentication, lack of intelligent agent governance system, lack of unified observability, and incompatibility between high and low versions of the A2A protocol under the existing point-to-point direct connection method, thereby overcoming or at least partially overcoming the shortcomings of existing technologies.

[0015] The embodiments of this application adopt the following technical solutions: In a first aspect, this application provides a method for implementing an intelligent agent gateway based on the A2A protocol, applicable to a system including a registration center, an A2A gateway, and a management platform. The registration center, A2A gateway, and management platform are deployed independently and functionally decoupled. The method includes: The backend agent submits registration information, including agent name, URL, protocol version and authentication configuration, to the registration center. The registration center performs uniqueness verification and authentication configuration verification on the registration information and then encrypts and stores the credentials. The A2A gateway synchronizes the registration information from the registration center and maintains a local cache, which includes the URL, protocol version, and credentials of each backend agent. The caller sends an A2A request carrying an access token to the unified entry point of the A2A gateway. The A2A gateway authenticates the caller and, after successful authentication, retrieves the target agent's credentials from the local cache. The A2A gateway performs protocol version conversion on the A2A request based on the protocol version declared by the target intelligent agent during registration, and constructs an outbound request that conforms to the protocol version of the target intelligent agent; The A2A gateway looks up the URL of the target agent based on the local cache, forwards the outbound request to the target agent, and returns the response returned by the target agent to the caller.

[0016] Secondly, this application provides an intelligent agent gateway implementation system based on the A2A protocol, including a registration center, an A2A gateway, and a management platform, which are deployed independently and functionally decoupled. The registration center is used to receive registration information submitted by backend intelligent agents, perform uniqueness verification and authentication configuration verification on the registration information, encrypt and store the credentials, and serve as the sole storage and distribution center for registration information. The A2A gateway is communicatively connected to the registration center and the management platform, and includes a configuration synchronization module, an access module, an access control module, a protocol conversion module, and a forwarding and routing module. The configuration synchronization module is used to synchronize registration information from the registration center and maintain a local cache. The access module is used as a unified entry point to receive A2A requests carrying access tokens sent by the caller and to pass the requests to subsequent modules in sequence. The permission control module is used to authenticate the caller and obtain the target agent's credentials from the local cache; The protocol conversion module is used to convert the request protocol version according to the protocol version declared when the target agent registers, and the forwarding and routing module is used to find the URL of the target agent based on the local cache and forward the request and return the response; The management platform is communicatively connected to the registration center and the A2A gateway, respectively, for credential management, registration information management and operation and maintenance monitoring, and pushes control measures and credentials to the A2A gateway.

[0017] Thirdly, this application also 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 computer program to implement the steps of the above-described intelligent agent gateway implementation method based on the A2A protocol.

[0018] Fourthly, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described intelligent agent gateway implementation method based on the A2A protocol.

[0019] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: (1) Achieve unified authentication and improve credential security: The caller only needs to present the access token to the A2A gateway, and the gateway will complete the authentication in a unified manner and obtain the credential of the target intelligent agent from the local cache. The caller does not need to directly hold the authentication credentials of each backend intelligent agent. The credentials are encrypted and stored by the registration center, which avoids the security risks of credentials being scattered among multiple callers and intelligent agents in the point-to-point direct connection mode.

[0020] (2) Shielding the differences in A2A protocol versions and reducing the adaptation cost for the caller: The A2A gateway automatically converts the protocol version of the request and constructs an outbound request that conforms to the target version based on the protocol version declared when the target agent is registered. The caller does not need to be aware of the differences in the protocol versions of the backend agents, and does not need to maintain adaptation logic for different versions of agents. This solves the problem of high adaptation cost for the caller when new and old versions of A2A agents coexist in the enterprise.

[0021] (3) Separation of control plane and data plane to improve system availability and fault tolerance: The registration center, A2A gateway and management platform are deployed independently and their functions are decoupled to achieve fault domain isolation. Faults on the management side do not affect the call forwarding link. The A2A gateway synchronizes registration information from the registration center and maintains local cache. Subsequent routing forwarding is completed based on the local cache. When the registration center fails, the gateway can still continue to forward requests based on the local cache to achieve degraded operation.

[0022] (4) Unified registration and unified access to realize centralized management of intelligent agents: the backend intelligent agents submit registration information to the registration center in a unified manner, and the caller initiates a request through the unified entry point of the A2A gateway. This changes the situation where intelligent agents are deployed in a decentralized manner and access information is maintained by each party under the point-to-point direct connection method, realizes centralized registration and unified access of intelligent agents, and reduces the management and maintenance costs of intelligent agents within the enterprise. Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A schematic diagram of the existing point-to-point direct connection method based on API / MCP interface is shown; Figure 2 This diagram illustrates the structure of a point-to-point direct connection based on the A2A protocol in the prior art. Figure 3 A schematic diagram of the overall technical architecture of an A2A gateway according to an embodiment of this application is shown; Figure 4 A schematic diagram of an agent registration process according to an embodiment of this application is shown; Figure 5 A schematic diagram of an agent discovery process according to an embodiment of this application is shown; Figure 6 A timing diagram of a client invoking an A2A gateway according to an embodiment of this application is shown; Figure 7 A schematic diagram of a task proxy query and bypass record process according to an embodiment of this application is shown. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0026] In the description of this application, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc., indicating the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0027] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0028] In this application, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection, an electrical connection, or a communication connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0029] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0030] To address the shortcomings of existing technologies, this application proposes a unified access and governance architecture for intelligent agents centered on an A2A gateway. This architecture consists of three independently deployed components: a registration center, an A2A gateway, and a management platform. The registration center is responsible for storing and managing intelligent agent registration information, serving as the sole storage and distribution hub for this information. The A2A gateway handles traffic processing functions such as call forwarding and protocol adaptation. It retrieves registration information from the registration center and caches it locally. Callers only need to interact with the gateway, which handles protocol standardization, authentication, routing, and call record reporting. The management platform is responsible for governance functions such as credential management, registration information management, and operation and maintenance monitoring. It pushes control measures and credentials to the A2A gateway and retrieves registration information from the registration center. These three components achieve functional decoupling and fault domain isolation, ensuring that management-side failures do not affect call forwarding.

[0031] Example 1: I. System Architecture like Figure 3 As shown, the overall architecture of the A2A gateway in this application is divided into three main layers from top to bottom: the client layer, the A2A gateway layer, and the backend intelligent agent layer. The registration center and management platform on the left serve as supporting control. The A2A gateway layer is internally divided into four main link sublayers from top to bottom according to the request flow order: the access sublayer, the access control sublayer, the protocol conversion sublayer, and the forwarding routing sublayer. In addition, it also includes a configuration synchronization module, an AgentCard controlled discovery module, a task agent query and bypass recording module, a push notification module, and an indicator collection module.

[0032] (1) Access Sublayer: As the sole entry point for external communication of the A2A gateway, it provides a unified HTTP entry point to accept requests. The request body can be a standard JSON-RPC structure or a RESTful style. After receiving the request, the access sublayer hands it over to the permission control sublayer for processing. The access sublayer and the permission control sublayer exchange information such as the caller's identity, access token, target agent name, and request body through an internal request object.

[0033] (2) Access Control Sublayer: Responsible for unified authentication, verifying the caller's permissions to access the AgentCard, access the target agent, and request tasks. The access control sublayer adopts a role-based access control (RBAC) model to authenticate the caller. After successful authentication, the target agent's credentials are decrypted for subsequent requests to the target agent. The access control sublayer connects to the configuration synchronization module and obtains authorization data such as permission policies, tokens, and target agent credentials from the local cache maintained by the configuration synchronization module.

[0034] (3) Protocol Conversion Sublayer: Responsible for shielding the differences between different A2A protocol versions and undertaking version conversion and request / response format conversion. The protocol conversion sublayer performs version normalization (field mapping, message structure conversion, method name translation) and request / response format conversion (constructing an outbound request body of the corresponding format according to the binding type declared by the target intelligent agent and encapsulating the response according to the caller's binding format) on the request based on the version and parameters of the target intelligent agent. The protocol conversion sublayer receives the authenticated request and credentials transmitted by the access control sublayer and outputs the converted outbound request to the forwarding routing sublayer.

[0035] (4) Forwarding and Routing Sublayer: Based on the local cache, the forwarding and routing sublayer finds the URL of the target agent, sends the request to the target agent, and returns a response. The forwarding and routing sublayer includes a discovery and routing module, a call orchestration module, and a streaming response module. The discovery and routing module finds the URL of the target agent based on the local cache maintained by the configuration synchronization module; the call orchestration module constructs and sends the request according to the A2A protocol specification; the streaming response module is used to pass through the SSE stream data returned by the target agent to the caller, and supports the caller to replay the cached events in sequence after disconnection and reconnection. The forwarding and routing sublayer receives the outbound request output by the protocol conversion sublayer, initiates a call to the target agent, and returns the response to the caller.

[0036] (5) Configuration Synchronization Module: Responsible for synchronizing registration information from the registry center and maintaining the local cache. The gateway detects changes in registration information from the registry center through polling and event listening mechanisms and updates the local cache accordingly. Subsequent calls are all completed based on the local cache, without directly accessing the registry center, ensuring efficient call paths. When the local cache misses, the gateway can trigger a registry center synchronization. The content of the local cache includes registration information such as agent name, URL, protocol version, capability declaration, and credentials, as well as authorization data such as permission policies and tokens synchronized from the management platform. The configuration synchronization module provides local cache data support for the permission control sublayer, protocol conversion sublayer, and forwarding routing sublayer.

[0037] (6) Task Proxy Query and Bypass Recording Module: This module undertakes two responsibilities: first, it proxies and forwards the caller's task query and cancellation requests to the target agent to obtain the task status; second, it records the task object in the call forwarding chain for auditing, statistics, and observability, recording the entire lifecycle processing of the task. When the target agent is unavailable, this module can fall back to the locally cached task status table to return the most recently known status, and mark "may expire" in the response for the caller's reference. This module is connected to the forwarding routing sublayer and obtains task object information in the call forwarding chain by bypass.

[0038] (7) Metrics Acquisition Module: Records metrics such as the number of calls, response time, success or failure on the call forwarding link according to the agent dimension, providing data support for capacity planning and fault location. The metrics acquisition module is connected to the forwarding routing sublayer and collects metrics data in bypass mode during request forwarding and response return.

[0039] (8) Push Notification Module: After the A2A gateway obtains a task status change, it actively notifies the caller. The push notification module is connected to the task agent query and bypass record module. When the task status changes, the push notification module pushes a status change notification to the caller.

[0040] The system's modules are functionally decoupled and have clearly defined connections: the access module serves as a unified entry point, receiving requests and sequentially passing them to the access control module, protocol conversion module, and forwarding / routing module, forming a clear request flow chain; the access control module provides unified authentication and retrieves credentials from the local cache; the protocol conversion module masks differences between different A2A protocol versions; and the forwarding / routing module completes routing based on the local cache and returns a response; the configuration synchronization module provides local cache data support for each link module; and the registration center and management platform, as management and control accessories, communicate with the A2A gateway, achieving separation of traffic processing and governance management, and supporting independent scaling, independent upgrades, and fault isolation.

[0041] Example 2: Methodology like Figure 4 As shown, this embodiment provides a method for implementing an intelligent agent gateway based on the A2A protocol, applied to a system including a registration center, an A2A gateway, and a management platform. The registration center, A2A gateway, and management platform are deployed independently and functionally decoupled. The method includes the following steps: S1. The backend agent submits registration information, including agent name, URL, protocol version and authentication configuration, to the registration center. After the registration center performs uniqueness verification and authentication configuration verification on the registration information, it encrypts and stores the credentials in the authentication configuration. S2. The A2A gateway synchronizes the registration information from the registration center and maintains a local cache, which includes the URL, protocol version and credentials of each backend agent. S3. The caller sends an A2A request carrying an access token to the unified entry point of the A2A gateway. The A2A gateway authenticates the caller and, after successful authentication, retrieves the target agent's credentials from the local cache. S4. The A2A gateway performs protocol version conversion on the A2A request according to the protocol version declared by the target intelligent agent during registration, and constructs an outbound request that conforms to the protocol version of the target intelligent agent; S5. The A2A gateway finds the URL of the target agent based on the local cache, forwards the outbound request to the target agent, and returns the response returned by the target agent to the caller.

[0042] II. Agent Registration Process The agent registration process includes the following steps in chronological order, describing the registration process of the backend agent.

[0043] Step R1: Registration Initiation. The input is the registration request submitted by the initiator. The initiator sends the registration request to the registration center via SDK or configuration. The request body includes registration information such as agent name, URL, protocol version, capability declaration, and authentication configuration. The registration center is the sole entry point for writing registration information. The output is the pending registration requests received by the registration center. This step is a prerequisite for subsequent verification and storage. The agent name in the registration request is used for uniqueness verification, and the authentication configuration is used for subsequent encrypted storage.

[0044] Step R2: Uniqueness Verification. The input is the registration request received in step S1. The registration center performs a uniqueness verification on the agent name. If an agent with the same name already exists, a conflict error is returned, and the registration process terminates; if no agent with the same name exists, proceed to step S3. The output is the uniqueness verification result. This step ensures that each agent has a unique identifier in the registration center, avoiding routing ambiguity caused by name conflicts.

[0045] Step R3: Authentication Configuration Verification and Encrypted Storage. The input is a registration request that passes uniqueness verification. The registration center verifies the authentication configuration and encrypts sensitive fields such as credentials. If the authentication configuration verification fails, a configuration error is returned, and the registration process terminates; if the verification passes, the credentials are encrypted before proceeding to step S4. The output is the registration information that has passed verification and whose credentials have been encrypted. This step ensures that sensitive credentials in the registration information are not stored in plaintext, meeting data security requirements.

[0046] Step R4: Persistent Storage. The input is the registration information processed in Step S3. The registration center persists the registration information to its own storage, assigns a unique identifier, and records audit information such as creation time and registration source. The output is the persisted registration record. This step solidifies the registration information in the registration center, serving as the data foundation for subsequent A2A gateway synchronization and route invocation.

[0047] Step R5: Return registration result. The input is the persistent result from step S4. The registration center returns the registration result to the registration initiator, including the assigned unique identifier and registration status. The output is a response indicating successful or failed registration. At this point, the backend agent has completed registration, and its registration information can be obtained by the A2A gateway through the configuration synchronization module.

[0048] III. Agent Detection Mechanism like Figure 5 As shown, the A2A gateway discovers backend agents and their registration information (agent metadata, credentials, etc.) from the registry center by configuring the synchronization module, and maintains a local cache as the data basis for calls.

[0049] The configuration synchronization module works as follows: When the A2A gateway starts, the configuration synchronization module pulls all the registration information of registered agents from the registration center and loads it into the local cache; during operation, the configuration synchronization module periodically queries the registration center for registration information changes through a polling mechanism, and at the same time receives change events pushed by the registration center through an event listening mechanism, so as to detect the addition, modification and deletion of registration information and update the local cache; when the local cache does not find the target agent, the configuration synchronization module triggers a registration center synchronization, pulls the latest registration information of the agent and updates the local cache.

[0050] The locally cached content includes: agent name, URL, protocol version, capability declaration, credentials, and other registration information, as well as authorization data such as permission policies and tokens synchronized from the management platform. Subsequent calls are all completed based on the local cache, without directly accessing the registry center, ensuring efficient call paths.

[0051] To quantify the optimization effect of local caching on call latency, let the cache hit rate be H (0≤H≤1) and the local cache lookup latency be L. cache The remote query latency of the registry center is L. remote And L remote Much larger than L cache The average call routing latency is: L avg =H×L cache +(1-H)×L remote ; Where H is the cache hit rate, representing the probability that the target agent's information is found in the local cache when the route is invoked; L cache Local cache query latency, i.e., the time required to read the target agent URL and credentials from the A2A gateway's local memory; L remote The remote query latency to the registry center is the time required for the A2A gateway to request target agent information from the registry center over the network. When the cache hit rate H approaches 1, the average latency L... avg Approaching L cache The latency L is significantly lower than that of directly accessing the registry center. remote Meanwhile, when the registration center fails, the gateway can continue forwarding based on the local cache, thus achieving degradation.

[0052] IV. Client Invocation Flow like Figure 6 As shown, the client's call flow to the A2A gateway includes the following steps in chronological order.

[0053] Step T0: Client discovers the agent. The input is an AgentCard request initiated by the caller. Before making the call, the caller can request the target agent's AgentCard from the gateway to obtain information such as its protocol version, capability declaration, and skill list. The gateway performs permission verification before returning the card. It only returns the card if the caller has access rights to the agent. The card content is directly taken from the local registration information synchronized from the registry center and does not need to be forwarded to the agent. If the caller already knows the target agent's name and protocol version, it can skip this step and directly initiate the call. The output is either an AgentCard that has passed permission verification or a permission denied response. This step is optional and provides the caller with agent capability discovery capabilities while preventing the leakage of unauthorized agent capability information through permission verification.

[0054] Step T1: The A2A gateway receives the request. The input is an A2A request carrying an access token sent by the caller. The caller initiates the request to the gateway's unified HTTP entry point. The request body can be in standard JSON-RPC or RESTful style. After the access sublayer receives the request, it is handed over to the access control sublayer for processing. The output is an internal request object containing the caller's identity, access token, target agent name, and request body. This step is the entry point of the call chain; the unified HTTP entry point shields the heterogeneous access methods of the backend agents.

[0055] Step T2: Authentication and Credential Preparation. The input is the internal request object from Step T1. The access control sublayer performs RBAC authentication on the caller. Upon successful authentication, the target agent's credentials are decrypted for subsequent requests to the target agent. The A2A gateway's configuration synchronization module is responsible for synchronizing this credential information from the registry center and loading it into the local cache for authentication and subsequent route queries. If authentication fails, a permission denial response is returned, and the call process terminates. The output is the authenticated request object with the decrypted credentials of the target agent. This step ensures that only authorized callers can access the target agent, and the gateway centrally manages credentials, so the caller does not need to directly hold the target agent's credentials.

[0056] Step T3: Version Conversion and Request / Response Format Conversion. The input is the authenticated request object from Step T2. The protocol conversion sublayer performs version normalization (field mapping, message structure conversion, method name translation) and request / response format conversion (constructing an outbound request body in the corresponding format according to the binding type declared by the target agent, and encapsulating the response according to the caller's binding format) based on the protocol version and parameter format declared during target agent registration. This constructs a request that conforms to the target agent's version and parameters. The output is an outbound request that conforms to the target agent's protocol version and parameter format. This step masks the differences between different versions of the A2A protocol, so the caller does not need to be concerned with the target agent's protocol version.

[0057] Step T4: Routing and Forwarding. The input is the outbound request from Step T3. The forwarding routing sublayer looks up the target agent's URL based on the local cache and sends the request to the target agent. The output is the A2A protocol request sent to the target agent. This step completes routing based on the local cache, eliminating the need for real-time access to the registry center and ensuring routing efficiency.

[0058] Step T5: Return Response. The input is the result returned by the target agent after processing. The forwarding routing sublayer returns the result to the caller. For SendStreamingMessage streaming requests, the streaming response module of the forwarding routing sublayer passes the SSE stream data returned by the agent to the caller, and supports the caller to replay cached events in sequence after disconnection and reconnection. The output is the response result returned to the caller. This step completes the closed loop of the call chain, and the streaming response module supports the message streaming return specification of the A2A protocol.

[0059] Step T6 (Bypass): Record task status. This step is executed in bypass mode by the task agent query and bypass recording module. The input is the task object contained in the response of step T5. If the response contains a task object, a copy of the task status is recorded locally. Subsequent task query or cancellation requests are forwarded by the gateway agent to the target agent to obtain the accurate status, while simultaneously updating the local copy. The output is the locally stored copy of the task status. This step records the task status in bypass mode without affecting the main call chain, for auditing, statistics, and observability purposes.

[0060] Step T7 (Bypass): Metric Collection. This step is executed in bypass mode by the A2A gateway's metric collection module. Inputs are request and response information from the call forwarding chain, and metrics such as call count, response time, and success or failure are recorded at the agent level. Outputs are the collected call metric data, providing data support for capacity planning and fault location. This step is executed in bypass mode and does not increase latency in the main call chain.

[0061] V. Design of splitting vouchers at both ends This application employs a credential splitting design: on the caller side, the gateway centrally issues, rotates, and revokes access tokens, and the caller no longer directly holds the backend agent's credentials; on the Agent side, only the gateway's credentials are needed to verify the agent's identity, eliminating the need to manage a large number of caller credentials. Credentials from the gateway to each Agent are encrypted and stored in the registry center. The A2A gateway retrieves credential information for all backend agents from the registry center and adapts accordingly based on the authentication type. In other words, the caller does not directly hold the target agent's credentials, but only the access token distributed by the gateway.

[0062] The working principle of the credential splitting mechanism is as follows: On the caller side, the management platform uniformly issues access tokens to the caller. The caller holds this token and initiates a request to the A2A gateway. The A2A gateway's access control sublayer verifies the token's validity and checks the caller's access permissions to the target agent. The rotation and revocation of access tokens are managed uniformly by the management platform; the caller does not need to maintain the target agent's authentication information. On the agent side, the backend agent only needs to be configured to trust the A2A gateway's credentials; there is no need to configure authentication information separately for each caller. Credentials from the A2A gateway to each backend agent are encrypted and stored by the registry center. The A2A gateway retrieves credential information from the registry center to its local cache through a configuration synchronization module. After successful authentication, it decrypts the target agent's credentials from the local cache and injects them into the outbound request.

[0063] To quantify the effect of splitting credentials at both ends on reducing credential management complexity, assume there are N calling agents and M backend agents within the enterprise. In the traditional point-to-point direct connection method, each calling agent needs to maintain authentication information for M backend agents, and each backend agent needs to manage credentials for N calling agents. The total credential management complexity is: C traditional =N×M; After adopting the credential splitting design, the caller only needs to hold the access token distributed by the gateway (N callers correspond to N tokens, which are managed uniformly by the management platform), and the backend agent only needs to trust the gateway credential identity (M backend agents correspond to M gateway credentials, which are encrypted and stored by the registration center). The total complexity of credential management is reduced to: C proposed =N+M; The reduction in credential management complexity is: (N×M-(N+M)) / (N×M)=1-(N+M) / (N×M). When both N and M are large, this ratio approaches 1, meaning that credential management complexity is significantly reduced. The authentication burden of the backend agent is reduced from "N callers × M types of credentials" to "unified authentication by the gateway," and the complexity of credential management converges to the gateway and the registration center.

[0064] As can be seen, the complexity of credential management is significantly reduced: by adopting a credential split design at both ends, the access tokens on the caller side are uniformly issued, rotated, and revoked by the management platform, and the caller does not directly hold the credentials of the target intelligent agent; the intelligent agent side only needs to trust the credential identity of the A2A gateway, and there is no need to configure authentication information separately for each caller; the complexity of credential management is reduced from N callers × M types of credentials in the traditional point-to-point direct connection mode to unified authentication by the gateway, and the complexity of credential management converges to the gateway and the registration center.

[0065] Enhanced credential security and auditability: Credentials from the A2A gateway to each target agent are encrypted and stored in the registration center. The gateway pulls the credentials to the local cache through the configuration synchronization module. After authentication, the credentials are decrypted and injected into the outbound request. Authentication information is no longer scattered among multiple callers and agents, realizing centralized storage, unified management and auditing of credentials. This significantly reduces the security burden on the agent side and meets the credential management needs of scenarios with high security and compliance requirements, such as finance.

[0066] VI. Controlled Discovery of AgentCard The A2A gateway implements permission verification for AgentCard access, ensuring that the caller can only obtain the capability declarations and skill lists of agents within the authorized scope. Specifically, when the caller requests the target agent's AgentCard from the A2A gateway, the gateway's permission control sublayer first verifies the caller's permissions to check if the caller has the necessary authorization to access the agent's AgentCard. Only when the caller has access to the agent will the A2A gateway return the AgentCard. The content of the AgentCard is retrieved from the registration information cached locally by the A2A gateway, eliminating the need to forward requests to the target agent and avoiding additional call pressure on the backend agent. If the caller already knows the target agent's name and protocol version, it can skip the AgentCard discovery step and directly initiate the task call.

[0067] As can be seen, the A2A gateway implements permission verification for access to the AgentCard. The caller can only obtain the capability declaration and skill list of the agent within the authorized scope. This avoids the problem of leakage of unauthorized agent capability information and endpoint information caused by the direct exposure of the AgentCard to the outside world in the point-to-point direct connection mode. It meets the security requirements of minimum permission and permission level and can prevent the leakage of unauthorized agent capability information.

[0068] The AgentCard content is retrieved from the registration information cached locally by the A2A gateway, eliminating the need to forward requests to the target agent and avoiding additional call pressure on the backend agent. When the caller knows the target agent name and protocol version, it can skip the AgentCard discovery step and directly initiate the task call, improving call efficiency and reducing the call pressure on the backend agent while improving discovery efficiency.

[0069] VII. Task Status Proxy Query and Bypass Record The A2A protocol defines task states including submitted, working, input_required, completed, failed, canceled, rejected, and auth_required. These states describe the target agent's handling of the task. Regarding task states, the A2A gateway in this application primarily undertakes two responsibilities: first, it proxies and forwards the caller's task query and cancellation requests to the target agent to obtain the task status; second, it bypasses the call forwarding chain to record task objects for auditing, statistics, and observability, recording the entire lifecycle processing of the task.

[0070] like Figure 7 As shown, the task proxy query and bypass recording process is as follows: (1) Gateway proxy query: When the A2A gateway receives a task query or cancellation request, it forwards it to the target agent to obtain the real task status and ensures that the returned status is consistent with the agent side; the task cancellation request is also forwarded to the target agent through the gateway to perform the cancellation operation. (2) Bypass recording: The gateway records the task object in the call forwarding link locally for auditing, statistics and observability, and does not use it as the data source of accurate task status. (3) Degradation query: When the target agent is unavailable, the gateway can fall back to the locally cached task status table to return the most recently known status and mark "may expire" in the response for the caller to refer to.

[0071] The A2A gateway agent forwards the caller's task query and cancellation requests to the target agent, obtains the actual task status on the target agent's side, and returns it to the caller. This ensures that the returned task status is consistent with that on the agent's side, avoiding the problem of inconsistency between the gateway's local cached status and the agent's actual status, and guaranteeing accurate and consistent task status.

[0072] The call chain is auditable and does not affect the performance of the main chain: The A2A gateway records the task object locally in the call forwarding chain for auditing, statistics and observability, and explicitly states that the task status recorded in the bypass is not used as the data source of accurate task status. This achieves traceability of the entire task lifecycle while avoiding the risk of inconsistent status; the bypass record does not increase the latency of the main call chain.

[0073] When the target agent is unavailable, the A2A gateway falls back to the locally cached task status table to return the most recently known status and marks "may expire" in the response for the caller's reference. This avoids the problem of direct failure of the call when the target agent is unavailable in the point-to-point direct connection mode, improves the system's fault tolerance and call continuity, provides degradation query capability, and improves the system's fault tolerance.

[0074] VIII. Version Conversion and Extension Mechanism The A2A protocol currently has two main versions, v0.3 and v1.0, which are incompatible in terms of method names, message structures, task states, and other formats. Enterprises typically have multiple teams and agents built at different times, resulting in the coexistence of old and new versions. This application's A2A gateway supports both v1.0 and v0.3. If the caller already knows the capabilities of the target agent and does not need to obtain the AgentCard, the caller can specify the A2A version when making a request to the gateway. This eliminates the need to maintain multiple sets of client logic for compatibility across different agent versions, and the caller does not need to modify its client when the agent version is upgraded.

[0075] The A2A gateway employs a scalable version adapter design, with an independent version adapter for each A2A protocol version, registered to the gateway via a version registry. The version adapter works as follows: Upon receiving an authenticated request, the protocol conversion sublayer searches the version registry for the corresponding version adapter based on the protocol version declared by the target agent during registration. The version adapter performs field mapping, message structure conversion, and method name translation on the request, transforming the caller's request into an outbound request conforming to the target agent's protocol version. After the target agent returns a response, the version adapter encapsulates the response according to the caller's protocol version and returns it to the caller. Adding a new A2A protocol version only requires implementing the new version adapter and registering it in the version registry; no modification to the gateway's core code or the caller's code is required. When the gateway does not yet support the version declared by the target agent, it returns an explicit version unsupported error.

[0076] To quantify the cost reduction effect of the scalable version adapter design on version expansion, assume there are K calling agents within the enterprise. In the traditional approach, adding a new A2A protocol version requires each calling agent to add version adaptation logic, resulting in a total code change of: E traditional =K; With the scalable version adapter design, adding a new version only requires implementing one new version adapter and registering it in the version registry. The gateway core code and the caller code do not need to be modified, resulting in a total code change of: E proposed =1; The reduction in code modification amount is (K-1) / K. When K is large, this ratio approaches 1, meaning that the code modification amount for the new protocol version is significantly reduced, while avoiding compatibility risks introduced by the caller's modifications.

[0077] It can be seen that (1) the differences between high and low versions of the A2A protocol are shielded, reducing the adaptation cost for the caller: The A2A gateway adopts an extensible version adapter design, with each A2A protocol version corresponding to an independent version adapter and registered through the version registry; the caller initiates a request to the gateway with any supported version, and the gateway automatically performs field mapping, message structure conversion and method name translation when leaving the site according to the protocol version declared by the target agent, shielding the incompatibility differences between v0.3 and v1.0 in terms of method name, message structure, task status and other formats; the caller does not need to maintain multiple sets of client logic for compatibility of multiple agent versions, and the caller does not need to modify when the agent upgrades its version.

[0078] (2) Significantly reduced version extension cost: When adding a new A2A protocol version, only the new version adapter needs to be implemented and registered in the version registry, without modifying the core code of the A2A gateway and the caller code; the version extension cost is reduced from the code modification of K callers in the traditional way to the implementation of 1 new adapter, while avoiding the compatibility risk introduced by the modification of the caller; when the gateway does not support the protocol version declared by the target agent, the gateway returns an explicit version not supported error, improving the maintainability of the system.

[0079] IX. Local Cache Synchronization and Metric Collection The A2A gateway uses polling and event listening mechanisms to detect changes in registration information from the registry center and updates its local cache accordingly. Subsequent calls are all completed based on the local cache, without directly accessing the registry center, ensuring efficient call paths. When the local cache misses, the A2A gateway triggers a registry center synchronization. The A2A gateway collects call counts, response times, and success / failure metrics at the agent level along the call forwarding chain for unified monitoring, auditing, and fault localization.

[0080] The A2A gateway uses a dual mechanism of polling and event listening to detect changes in registration information in the registry center and update the local cache. Subsequent calls are all completed based on the local cache and do not directly access the registry center, ensuring an efficient call path. When the local cache misses, the gateway triggers a registry center synchronization, pulls the latest registration information of the target agent and updates the cache, balancing cache consistency and call efficiency, ensuring both efficient call path and cache consistency.

[0081] The A2A gateway collects call counts, response times, and success or failure metrics at the agent level along the call forwarding link, providing unified monitoring, auditing, and fault location capabilities. This solves the problems in point-to-point direct connection scenarios where client agents and remote agents record logs separately, lack unified monitoring methods, cannot statistically analyze usage and success rates, and are difficult to perform capacity planning and fault location. It achieves unified observability and supports capacity planning and fault location.

[0082] 10. Streaming Response and Push Notifications For SendStreamingMessage streaming requests, the streaming response module of the forwarding routing sublayer forwards the SSE stream data returned by the agent to the caller, and supports the caller to replay cached events in sequence after disconnection and reconnection. After the A2A gateway obtains a task status change, the push notification module actively notifies the caller.

[0083] Complete and continuous streaming messages with support for disconnection recovery: The streaming response submodule of the forwarding routing module passes the SSE stream data returned by the target agent to the caller and supports the caller to replay the cached events in order after disconnection and reconnection, ensuring the integrity and continuity of the A2A protocol message streaming return and avoiding message loss or out-of-order problems caused by disconnection.

[0084] The push notification module proactively notifies the calling end after the A2A gateway receives a change in the task status, enabling real-time push notifications of the task status. The calling end does not need to continuously poll for the task status, reducing the calling end's resource consumption and network overhead, and ensuring real-time push notifications of the task status.

[0085] The main differences between this application and the prior art are as follows: (1) Architecture difference: Existing technologies are point-to-point direct connections between client intelligent agents and remote intelligent agents, without a unified governance node; this application constructs a star governance architecture with the A2A gateway as the center, and the registration center, A2A gateway and management platform are deployed independently to achieve separation of the control plane and data plane, and the failure of the management side does not affect the call forwarding.

[0086] (2) Authentication difference: In the prior art, the caller maintains all remote agent authentication information by itself, and the credentials are scattered and difficult to manage centrally. The remote agents only expose the authentication method through the securitySchemes field of AgentCard. This application adopts a credential split design at both ends. The caller side is uniformly issued, rotated and revoked by the management platform. The agent side only needs to trust the identity of the A2A gateway credentials. The credentials from the gateway to each agent are encrypted and stored in the registration center. The credential management complexity is reduced from N×M to unified authentication by the gateway.

[0087] (3) Protocol compatibility differences: In the prior art, the A2A protocol v0.3 and v1.0 formats are incompatible under the point-to-point direct connection method. The caller may need to add a new version adaptation for each new intelligent agent connected. In this application, an extensible version adapter is set in the protocol conversion sub-layer. Each protocol version corresponds to an independent adapter and is registered through the version registry. The caller initiates a request with any supported version. The gateway automatically converts when leaving the site according to the version declared by the target intelligent agent. When adding a new version, only the new adapter needs to be implemented and registered. There is no need to modify the core code of the gateway and the code of the caller.

[0088] (4) Governance differences: In the existing technology, point-to-point direct connection lacks unified registration, unified discovery, unified control and unified observability. Each intelligent agent is unaware of the existence of the other, which is easy to duplicate construction and difficult to locate faults. This application provides a unified registration entry through the registration center and serves as the only storage and distribution hub for registration information. The A2A gateway provides a unified discovery and unified call entry and completes routing based on local cache. The management platform provides a unified management plane and pushes control measures and credentials to the gateway. The gateway collects call indicators uniformly on the call link and records the task status in a bypass.

[0089] (5) Fault tolerance difference: In the prior art, when the remote intelligent agent is unavailable in the point-to-point direct connection mode, the call will fail directly without a degradation mechanism; the A2A gateway of this application maintains the local cache through the configuration synchronization module, and can continue to forward based on the cache to achieve degradation when the registration center fails; when the target intelligent agent is unavailable, the task agent query and bypass record module rolls back the local task status table to return the most recently known status and marks it as "may expire"; the streaming response module supports the caller to replay the cached events in sequence after disconnection and reconnection.

[0090] This application can achieve at least the following beneficial effects: (1) Achieve unified authentication and improve credential security: The caller only needs to present the access token to the A2A gateway, and the gateway will complete the authentication in a unified manner and obtain the credential of the target intelligent agent from the local cache. The caller does not need to directly hold the authentication credentials of each backend intelligent agent. The credentials are encrypted and stored by the registration center, which avoids the security risks of credentials being scattered among multiple callers and intelligent agents in the point-to-point direct connection mode.

[0091] (2) Shielding the differences in A2A protocol versions and reducing the adaptation cost for the caller: The A2A gateway automatically converts the protocol version of the request and constructs an outbound request that conforms to the target version based on the protocol version declared when the target agent is registered. The caller does not need to be aware of the differences in the protocol versions of the backend agents, and does not need to maintain adaptation logic for different versions of agents. This solves the problem of high adaptation cost for the caller when new and old versions of A2A agents coexist in the enterprise.

[0092] (3) Separation of control plane and data plane to improve system availability and fault tolerance: The registration center, A2A gateway and management platform are deployed independently and their functions are decoupled to achieve fault domain isolation. Faults on the management side do not affect the call forwarding link. The A2A gateway synchronizes registration information from the registration center and maintains local cache. Subsequent routing forwarding is completed based on the local cache. When the registration center fails, the gateway can still continue to forward requests based on the local cache to achieve degraded operation.

[0093] (4) Unified registration and unified access to realize centralized management of intelligent agents: the backend intelligent agents submit registration information to the registration center in a unified manner, and the caller initiates a request through the unified entry point of the A2A gateway. This changes the situation where intelligent agents are deployed in a decentralized manner and access information is maintained by each party under the point-to-point direct connection method, realizes centralized registration and unified access of intelligent agents, and reduces the management and maintenance costs of intelligent agents within the enterprise.

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

[0095] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

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

Claims

1. A method for implementing an intelligent agent gateway based on the A2A protocol, characterized in that, Applied to a system including a registry center, an A2A gateway, and a management platform, wherein the registry center, A2A gateway, and management platform are independently deployed and functionally decoupled, the method includes the following steps: Step S1: The backend agent submits registration information, including agent name, URL, protocol version and authentication configuration, to the registration center. After the registration center verifies the uniqueness of the registration information and the authentication configuration, it encrypts and stores the credentials in the authentication configuration. Step S2: The A2A gateway synchronizes the registration information from the registration center and maintains a local cache, which includes the URL, protocol version, and credentials of each backend agent. Step S3: The calling party sends an A2A request carrying an access token to the unified entry point of the A2A gateway. The A2A gateway authenticates the calling party and obtains the target agent's credentials from the local cache after successful authentication. Step S4: The A2A gateway performs protocol version conversion on the A2A request according to the protocol version declared by the target intelligent agent during registration, and constructs an outbound request that conforms to the protocol version of the target intelligent agent; Step S5: The A2A gateway looks up the URL of the target agent based on the local cache, forwards the outbound request to the target agent, and returns the response returned by the target agent to the caller.

2. The method for implementing an intelligent agent gateway based on the A2A protocol according to claim 1, characterized in that, In step S3, the A2A gateway authenticates the caller, including: The management platform uniformly issues, rotates, and revokes access tokens to the caller. The caller uses the access tokens distributed by the management platform to access the target intelligent agent and does not directly hold the credentials of the target intelligent agent. The target intelligent agent only trusts the credentials of the A2A gateway, and the credentials from the A2A gateway to each target intelligent agent are encrypted and stored in the registration center; The A2A gateway synchronizes credential information from the registry center to the local cache through the configuration synchronization module. After authentication, it decrypts the credential of the target agent from the local cache and injects it into the outbound request.

3. The method for implementing an intelligent agent gateway based on the A2A protocol according to claim 1, characterized in that, The process of agent discovery is preceding step S3: The calling party requests the AgentCard of the target intelligent entity from the A2A gateway. The A2A gateway first performs permission verification on the calling party, and only returns the AgentCard if the calling party has access rights to the target intelligent entity. The content of the AgentCard is taken from the registration information cached locally by the A2A gateway, without the need to forward the request to the target intelligent agent; If the caller already knows the name and protocol version of the target agent, it skips the agent discovery step and directly executes step S3.

4. The method for implementing an intelligent agent gateway based on the A2A protocol according to claim 1, characterized in that, In step S4, the A2A gateway performs protocol version conversion on the A2A request, including: The A2A gateway adopts an extensible version adapter design, with each A2A protocol version corresponding to an independent version adapter, and each version adapter is registered to the A2A gateway through a version registry. The A2A gateway selects the corresponding version adapter according to the protocol version declared by the target agent, performs field mapping, message structure conversion and method name translation on the A2A request, constructs an outbound request that conforms to the protocol version of the target agent, and encapsulates the response returned by the target agent according to the protocol version of the caller and returns it. When adding a new A2A protocol version, only the new version adapter needs to be implemented and registered in the version registry; there is no need to modify the core code of the A2A gateway or the caller code. When the A2A gateway does not yet support the protocol version declared by the target agent, the A2A gateway returns a version unsupported error.

5. The method for implementing an intelligent agent gateway based on the A2A protocol according to claim 1, characterized in that, It also includes task status management steps: When the A2A gateway receives a task query or cancellation request from the caller, it forwards the task query or cancellation request to the target intelligent agent, obtains the actual task status on the target intelligent agent side, and returns it to the caller. The A2A gateway records the task object locally in the call forwarding link for auditing, statistics and observability. The task status recorded in the bypass is not used as the data source for accurate task status. When the target agent is unavailable, the A2A gateway falls back to the locally cached task status table to return the most recently known status and marks it as possibly expired in the response.

6. The method for implementing an intelligent agent gateway based on the A2A protocol according to claim 1, characterized in that: In step S2, the A2A gateway detects changes in the registration information of the registration center through polling and event listening mechanisms and updates the local cache. Subsequent call operations are all completed based on the local cache and do not directly access the registration center. When the local cache is not hit, the A2A gateway triggers a synchronization of the registration center. After step S5, the A2A gateway collects the number of calls, response time, and success or failure indicators at the agent level on the call forwarding link for unified monitoring, auditing, and fault location.

7. A smart agent gateway implementation system based on the A2A protocol, characterized in that, The system includes a registration center, an A2A gateway, and a management platform, all of which are deployed independently and have decoupled functions. The registration center is used to receive registration information submitted by the backend intelligent agent, perform uniqueness verification and authentication configuration verification on the registration information, encrypt and store the credentials, and serve as the sole storage and distribution center for registration information. The A2A gateway is communicatively connected to the registration center and the management platform, and includes a configuration synchronization module, an access module, an access control module, a protocol conversion module, and a forwarding and routing module. The configuration synchronization module is used to synchronize registration information from the registration center and maintain a local cache. The access module is used as a unified entry point to receive A2A requests carrying access tokens sent by the caller, and to pass the A2A requests sequentially to the permission control module, the protocol conversion module and the forwarding routing module; The permission control module is used to authenticate the caller, and after successful authentication, retrieves the target agent's credentials from the local cache. The protocol conversion module is used to convert the A2A request according to the protocol version declared by the target intelligent agent during registration; The forwarding and routing module is used to find the URL of the target agent based on the local cache and forward the request, and return the response returned by the target agent to the caller; The management platform is communicatively connected to the registration center and the A2A gateway, respectively, for credential management, registration information management and operation and maintenance monitoring, and pushes control measures and credentials to the A2A gateway.

8. The intelligent agent gateway implementation system based on the A2A protocol according to claim 7, characterized in that: The management platform is also used to uniformly issue, rotate, and revoke access tokens to the caller. The caller holds the access tokens distributed by the management platform to access the target intelligent agent and does not directly hold the credentials of the target intelligent agent. The target intelligent agent only trusts the credentials of the A2A gateway, and the credentials from the A2A gateway to each target intelligent agent are encrypted and stored in the registration center; The access control module is also used to decrypt the target agent's credentials from the local cache and inject the decrypted credentials into the forwarding request.

9. The intelligent agent gateway implementation system based on the A2A protocol according to claim 7, characterized in that: The protocol conversion module includes a version registry and multiple version adapters. Each A2A protocol version corresponds to an independent version adapter, and each version adapter is registered to the protocol conversion module through the version registry. The protocol conversion module selects the corresponding version adapter based on the protocol version declared by the target agent and performs protocol version conversion. The A2A gateway also includes a task proxy query and bypass recording module, which is used to forward the caller's task query or cancellation request to the target agent to obtain the real task status, bypass and record the task object locally in the call forwarding link for auditing and observability, and fall back to the locally cached task status table when the target agent is unavailable to return the most recently known status and mark it as possibly expired.

10. The intelligent agent gateway implementation system based on the A2A protocol according to claim 7, characterized in that: The forwarding and routing module also includes a streaming response submodule, which is used to pass through the SSE stream data returned by the target agent to the caller, and supports the caller to replay the cached events in sequence after disconnection and reconnection. The A2A gateway also includes a push notification module, which is used to proactively notify the caller after receiving a change in the task status; The A2A gateway also includes an indicator collection module, which is used to collect the number of calls, response time, and success or failure indicators at the agent level along the call forwarding link.

Images