深度解析三大AI协议：MCP、ACP与A2A，看懂智能代理的通信法则
AI摘要 本文深入分析了三个关键的AI协议：MCP、ACP和A2A，它们分别针对不同的应用场景，解决AI代理技术中的通信问题。MCP（模型上下文协议）由Anthropic推出，主要解决AI模型与外部信息的交互问题，适用于企业内部系统集成。ACP（代理通信协议）由BeeAI和IBM提出，专为本地设备设计，追求低延迟、少依赖，适用于边缘环境。A2A（代理对代理协议）由Google推出，解决不同平台AI代理的“语言互通”问题，适用于跨平台代理协同工作。这些协议共同推动AI从单打独斗的工具，变成协同工作的团队成员，提高协作效率。未来，开源中间件可能会将这些协议统一接口，降低开发者的使用门槛，促进AI代理技术的更广泛应用。 document.addEventListener('DOMContentLoaded', function() { const urlDisplay = document.getElementById('urlDisplay'); urlDisplay.textContent = "此内容根据文章生成，更内容请访问：" + window.location.href; }); 在 AI 代理技术爆发的今天，协议标准就像隐藏在幕后的交通规则，决定着整个生态的运行效率。如果你还在困惑为什么有的 AI 能无缝调用企业数据，有的能在边缘设备上协同工作，有的却能跨平台完成复杂任务 —— 答案就在这三个关键协议里：MCP、ACP 和 A2A。今天咱们就用大白话拆解这些技术骨架，看看它们各自解决什么问题，又该在什么场景下登场。一、MCP（模型上下文协议）给 AI 装个 "外接大脑"Anthropic 推出的 MCP（Model Context Protocol），本质是给大语言模型打造的标准化 "信息接口"。想象一下，当你让 AI 处理业务时，它需要调取 CRM 数据、查询库存系统、甚至生成报表 —— 这些零散的外部信息如果直接塞进提示词，不仅混乱还浪费 token。1、MCP 的三大核心能力上下文数据注入就像给 AI 开了个 "数据窗口"，文件、数据库记录、API 响应能通过标准化接口直接进入模型工作内存。比如调用客户数据时，不需要把整个数据库结构告诉 AI，只需传入所需字段，既安全又高效。这里的标准化接口就像统一规格的插座，无论是什么类型的外部数据，只要符合规格就能顺利接入，避免了因数据格式不统一而导致的兼容问题。功能路由与调用给 AI 配了个 "工具箱"，你可以注册 searchCustomerData（查询客户数据）、generateReport（生成报表）等能力，模型需要时直接调用。关键是这些工具不用硬编码进模型，升级维护超方便。比如当企业的报表生成逻辑发生变化时，只需要更新 generateReport 这个工具的代码，而不用对整个 AI 模型进行大动干戈的修改，大大降低了维护成本。提示词编排告别 "把所有细节塞进 prompt" 的笨拙做法，MCP 能像搭积木一样动态组装上下文。用户问不同问题时，只加载相关信息 —— 省 token、更精准，输出结果自然更靠谱。例如，当用户询问某一产品的销售情况时，MCP 只会调取该产品的相关销售数据和信息，而不会把所有产品的资料都一股脑地塞进提示词，让 AI 能够更专注地处理当前问题。技术特性与典型场景基于 HTTP (S) 和 JSON，兼容 OAuth2 等企业级安全标准，这意味着它可以很方便地融入企业现有的网络安全体系，保障数据传输的安全性。与模型无关，任何符合标准的 LLM 都能接入，这就为企业提供了很大的灵活性，企业可以根据自身需求选择合适的大语言模型，而不用担心模型与协议不兼容的问题。最适合：企业内部系统集成（如对接 Salesforce、SAP）、智能代理的实时数据支撑、动态定制提示词的场景简单说，MCP 解决的是 "AI 如何高效获取外部信息" 的问题，让模型轻装上阵，专注于逻辑处理而非数据管理。二、ACP（代理通信协议）边缘设备的 "本地对讲机"如果说 MCP 是云端 AI 的信息接口，那 BeeAI 和 IBM 提出的 ACP（Agent Communication Protocol）就是边缘环境的 "内部通信系统"。它专为本地设备设计，追求低延迟、少依赖，堪称 AI 代理的 "对讲机协议"。ACP 的独特架构去中心化设计：每个代理通过本地广播暴露身份和能力，不需要中央服务器协调。这种设计就像一个没有指挥官的团队，每个成员都能自主地向其他成员展示自己的能力，大大提高了系统的灵活性和抗故障能力。即使某个代理出现故障，也不会影响整个系统的运行。事件驱动通信：用本地总线或进程间通信（IPC）传递消息，比网络传输快得多。当有事件发生时，相关代理能迅速收到消息并做出响应，比如在智能家居中，当有人按下门铃时，门铃代理会通过事件驱动通信将这一事件告知门锁代理和摄像头代理，实现门锁自动解锁和摄像头启动录像的联动。轻量运行时：代理作为无状态服务或容器运行，共享通信基础，适合资源有限的设备。这使得 ACP 可以在像传感器、小型控制器等资源受限的边缘设备上运行，扩大了其应用范围。关键特性与应用场景超低延迟，适合无人机、机器人车队等实时响应场景。在无人机编队飞行中，无人机之间需要实时传递位置、速度等信息，以保证编队的整齐和安全，ACP 的超低延迟特性就能满足这种实时通信的需求。无需云依赖，断网也能工作（工厂车间、偏远地区超实用）。在一些网络信号不稳定或没有网络覆盖的工厂车间、偏远矿区等地方，设备之间的通信就可以依靠 ACP，确保生产等工作的正常进行。支持能力自动识别，代理间能自主分工。例如在一个物流仓库里，有的机器人擅长搬运重物，有的机器人擅长分拣小件物品，通过 ACP，它们能自动识别彼此的能力，并根据任务需求进行自主分工，提高工作效率。典型案例：仓库里的多台机器人协作搬运货物时，通过 ACP 实时广播位置和负载状态，无需云端调度就能避开拥堵；智能家居设备间（灯光、温控、安防）的联动响应，延迟能控制在毫秒级。三、A2A（代理对代理协议）跨平台的 "国际通用语"Google 推出的 A2A（Agent-to-Agent）协议，解决的是 不同平台 AI 代理的 "语言互通" 问题。当你的 AI 需要调用别家系统的能力（比如让 LangChain 代理对接 HuggingFace 模型），A2A 就是那套通用翻译标准。核心组件与工作方式代理卡片（Agent Card）每个代理的 "身份证 + 能力说明书"，包含身份信息、可提供的服务、通信端点和安全要求。就像酒店前台的服务清单，其他代理一看就知道能让它做什么。比如一个提供天气查询服务的代理，其代理卡片上会明确标注它能查询全球各地的天气情况、通信的接口以及需要的安全认证方式等信息。双向通信接口每个代理既能当 "客户"（发起任务），也能当 "服务员"（执行任务），支持多轮协作和流式数据传输。比如生成市场报告时，A 代理负责收集数据，B 代理负责分析，C 代理负责可视化，全程无缝衔接。在这个过程中，A 代理向 B 代理发起数据处理请求，B 代理处理完成后将结果返回给 A 代理，A 代理再将结果传递给 C 代理进行可视化处理，整个流程顺畅高效。安全框架基于 OAuth2 和 API 密钥，支持 "能力范围控制"—— 代理只暴露必要功能，内部逻辑完全隐藏，安全感拉满。例如，一个处理用户支付信息的代理，通过 A2A 的安全框架，只会向其他代理暴露查询支付状态的功能，而不会泄露用户的银行卡号、密码等敏感信息，保障了用户数据的安全。技术亮点与适用场景Web 原生设计，基于 HTTP 和 JSON-RPC，跨平台兼容性极强，这使得不同开发平台、不同技术架构的 AI 代理都能通过 A2A 进行通信。支持复杂任务流，适合企业级多系统协作。在大型企业中，可能有来自不同部门、不同供应商的各种 AI 系统，通过 A2A 协议，它们可以协同完成像企业资源规划、客户关系管理等复杂的任务流。最适合：跨厂商代理生态（如不同团队开发的 AI 协同工作）、云原生环境的分布式编排四、三者对比：选协议就像挑工具从这个对比表中可以清晰地看出，MCP 更侧重于模型与外部信息的交互，ACP 主要用于本地代理之间的实时通信，而 A2A 则是跨平台代理协同工作的关键。在实际应用中，企业可以根据自身的业务需求和技术环境，选择合适的协议或组合使用这些协议。五、协议融合未来会走向统一吗？很多人关心这些协议是竞争关系还是互补关系 —— 答案是既互补又各有领地。A2A 负责跨平台 "外交"，MCP 负责内部 "信息管理"，两者结合能打造强大的云端智能生态。比如在一个跨平台的电商智能客服系统中，A2A 让不同平台的客服代理能够相互通信协作，而 MCP 则为这些代理提供商品信息、客户订单等外部信息的支持，共同为客户提供优质的服务。ACP 则在边缘设备领域独树一帜，在工厂、无人机等场景中无可替代。在工业生产的智能工厂里，大量的边缘设备需要实时通信和协作，ACP 的低延迟、本地通信特性就能很好地满足这种需求，而 A2A 和 MCP 在这种场景下则难以发挥优势。未来最可能的趋势是：开源中间件会把这些协议 "翻译" 成统一接口。开发者不用关心底层用了 MCP 还是 ACP，只需调用简单指令，系统会自动匹配最合适的协议 —— 就像现在我们不用懂 TCP/IP 也能上网一样。这种统一接口的出现，将大大降低开发者的使用门槛，促进 AI 代理技术的更广泛应用。最后说句大实话AI 协议的发展，本质是在解决 "协作效率" 的问题。MCP 让 AI 更懂业务，ACP 让设备更协调，A2A 让生态更开放 —— 它们共同推动 AI 从单打独斗的 "工具"，变成协同工作的 "团队成员"。下次再看到某款 AI 产品宣传 "无缝集成"" 低延迟响应 ""跨平台协作" 时，你大概就能猜到它背后站着哪个协议了。技术虽复杂，但看透本质后会发现：所有标准的终极目标，都是让复杂的世界变得更简单。随着 AI 技术的不断发展，这些协议也会不断完善和演进，为 AI 代理的更好协作和应用奠定坚实的基础。
Agent2Agent（A2A）协议规范 版本： 0.2.2 1. 简介 Agent2Agent (A2A) 协议是一项开放标准，旨在促进独立且可能不透明的 AI 代理系统之间的通信和互操作性。在一个代理可能使用不同框架、语言或由不同供应商构建的生态系统中，A2A 提供了一种通用语言和交互模型。 本文档提供了 A2A 协议的详细技术规范。其主要目标是使代理能够： 发现彼此的能力。 协商交互方式（文本、文件、结构化数据）。 管理协作任务。 安全地交换信息以实现用户目标，而无需访问彼此的内部状态、内存或工具。 1.1. A2A 的关键目标 互操作性：弥合不同代理系统之间的沟通差距。 协作：使代理能够委派任务、交换上下文并共同处理复杂的用户请求。 发现：允许代理动态地查找和了解其他代理的功能。 灵活性：支持各种交互模式，包括同步请求/响应、实时更新的流式传输以及长时间运行任务的异步推送通知。 安全性：依靠标准的网络安全实践，促进适合企业环境的安全通信模式。 异步性：原生支持可能涉及人机交互场景的长时间运行的任务和交互。 1.2. 指导原则 简单：重复使用现有的、易于理解的标准（HTTP、JSON-RPC 2.0、服务器发送事件）。 企业就绪：通过与既定的企业实践保持一致，解决身份验证、授权、安全、隐私、跟踪和监控问题。 异步优先：专为（可能非常）长时间运行的任务和人机交互而设计。 与模态无关：支持多种内容类型的交换，包括文本、音频/视频（通过文件引用）、结构化数据/表单以及可能嵌入的 UI 组件（例如，部分引用的 iframe）。 不透明执行：代理根据声明的能力和交换的信息进行协作，而无需分享他们的内部想法、计划或工具实施。 要更广泛地了解 A2A 的目的和好处，请参阅什么是 A2A？。 2.核心概念总结¶ A2A 围绕几个关键概念展开。有关详细解释，请参阅关键概念指南。 A2A 客户端：代表用户或其他系统向 A2A 服务器发起请求的应用程序或代理。 A2A 服务器（远程代理）：公开符合 A2A 的 HTTP 端点、处理任务并提供响应的代理或代理系统。 代理卡： A2A 服务器发布的 JSON 元数据文档，描述其身份、功能、技能、服务端点和身份验证要求。 消息：客户端与远程代理之间的通信回合，具有role（“用户”或“代理”）并包含一个或多个Parts。 任务： A2A 管理的基本工作单元，由唯一 ID 标识。任务是有状态的，并按照定义的生命周期进行。 部分：消息或工件中最小的内容单位（例如TextPart，，，FilePart）DataPart。 工件：代理执行任务后生成的输出（例如，文档、图像、结构化数据），由组成Parts。 流式传输（SSE）：通过服务器发送事件传递的任务（状态变化、工件块）的实时增量更新。 推送通知：通过服务器发起的 HTTP POST 请求向客户端提供的 webhook URL 传递异步任务更新，适用于长时间运行或断开连接的情况。 上下文：一个可选的、服务器生成的标识符，用于对相关任务进行逻辑分组。 扩展：代理提供超出核心 A2A 规范的附加功能或数据的机制。 3. 传输和格式 3.1. 传输协议 A2A 通信必须通过HTTP(S)进行。 The A2A Server exposes its service at a URL defined in its AgentCard. 3.2. Data Format A2A uses JSON-RPC 2.0 as the payload format for all requests and responses (excluding the SSE stream wrapper). Client requests and server responses MUST adhere to the JSON-RPC 2.0 specification. The Content-Type header for HTTP requests and responses containing JSON-RPC payloads MUST be application/json. 3.3. Streaming Transport (Server-Sent Events)¶ When streaming is used for methods like message/stream or tasks/resubscribe: The server responds with an HTTP 200 OK status and a Content-Type header of text/event-stream. The body of this HTTP response contains a stream of Server-Sent Events (SSE) as defined by the W3C. Each SSE data field contains a complete JSON-RPC 2.0 Response object (specifically, a SendStreamingMessageResponse). 4. Authentication and Authorization A2A treats agents as standard enterprise applications, relying on established web security practices. Identity information is not transmitted within A2A JSON-RPC payloads; it is handled at the HTTP transport layer. For a comprehensive guide on enterprise security aspects, see Enterprise-Ready Features. 4.1. Transport Security As stated in section 3.1, production deployments MUST use HTTPS. Implementations SHOULD use modern TLS configurations (TLS 1.2+ recommended) with strong cipher suites. 4.2. Server Identity Verification A2A Clients SHOULD verify the A2A Server's identity by validating its TLS certificate against trusted certificate authorities (CAs) during the TLS handshake. 4.3. Client/User Identity & Authentication Process Discovery of Requirements: The client discovers the server's required authentication schemes via the authentication field in the AgentCard. Scheme names often align with OpenAPI Authentication methods (e.g., "Bearer" for OAuth 2.0 tokens, "Basic" for Basic Auth, "ApiKey" for API keys). Credential Acquisition (Out-of-Band): The client obtains the necessary credentials (e.g., API keys, OAuth tokens, JWTs) through an out-of-band process specific to the required authentication scheme and the identity provider. This process is outside the scope of the A2A protocol itself. Credential Transmission: The client includes these credentials in the appropriate HTTP headers (e.g., Authorization: Bearer <token>, X-API-Key: <value>) of every A2A request sent to the server. 4.4. Server Responsibilities for Authentication¶ The A2A Server: MUST authenticate every incoming request based on the provided HTTP credentials and its declared authentication requirements from its Agent Card. SHOULD use standard HTTP status codes like 401 Unauthorized or 403 Forbidden for authentication challenges or rejections. SHOULD include relevant HTTP headers (e.g., WWW-Authenticate) with 401 Unauthorized responses to indicate the required authentication scheme(s), guiding the client. 4.5. In-Task Authentication (Secondary Credentials) If an agent, during the execution of a task, requires additional credentials for a different system or resource (e.g., to access a specific tool on behalf of the user that requires its own auth): It SHOULD transition the A2A task to the auth-required state (see TaskState). The accompanying TaskStatus.message (often a DataPart) SHOULD provide details about the required secondary authentication, potentially using an PushNotificationAuthenticationInfo-like structure to describe the need. The A2A Client then obtains these new credentials out-of-band and provides them in a subsequent message/send or message/stream request. How these credentials are used (e.g., passed as data within the A2A message if the agent is proxying, or used by the client to interact directly with the secondary system) depends on the specific scenario. 4.6. Authorization Once a client is authenticated, the A2A Server is responsible for authorizing the request based on the authenticated client/user identity and its own policies. Authorization logic is implementation-specific and MAY be enforced based on: The specific skills requested (e.g., as identified by AgentSkill.id from the Agent Card). The actions attempted within the task. Data access policies relevant to the resources the agent manages. OAuth scopes associated with the presented token, if applicable. Servers should implement the principle of least privilege. 5. Agent Discovery: The Agent Card 5.1. Purpose A2A Servers MUST make an Agent Card available. The Agent Card is a JSON document that describes the server's identity, capabilities, skills, service endpoint URL, and how clients should authenticate and interact with it. Clients use this information for discovering suitable agents and for configuring their interactions. For more on discovery strategies, see the Agent Discovery guide. 5.2. Discovery Mechanisms Clients can find Agent Cards through various methods, including but not limited to: Well-Known URI: Accessing a predefined path on the agent's domain (see Section 5.3). Registries/Catalogs: Querying curated catalogs or registries of agents (which might be enterprise-specific, public, or domain-specific). Direct Configuration: Clients may be pre-configured with the Agent Card URL or the card content itself. 5.3. Recommended Location If using the well-known URI strategy, the recommended location for an agent's Agent Card is: https://{server_domain}/.well-known/agent.json This follows the principles of RFC 8615 for well-known URIs. 5.4. Security of Agent Cards Agent Cards themselves might contain information that is considered sensitive. If an Agent Card contains sensitive information, the endpoint serving the card MUST be protected by appropriate access controls (e.g., mTLS, network restrictions, authentication required to fetch the card). It is generally NOT RECOMMENDED to include plaintext secrets (like static API keys) directly in an Agent Card. Prefer authentication schemes where clients obtain dynamic credentials out-of-band. 5.5. AgentCard Object Structure /** * An AgentCard conveys key information: * - Overall details (version, name, description, uses) * - Skills: A set of capabilities the agent can perform * - Default modalities/content types supported by the agent. * - Authentication requirements */ export interface AgentCard { /** * Human readable name of the agent. * @example "Recipe Agent" */ name: string; /** * A human-readable description of the agent. Used to assist users and * other agents in understanding what the agent can do. * @example "Agent that helps users with recipes and cooking." */ description: string; /** A URL to the address the agent is hosted at. */ url: string; /** A URL to an icon for the agent. */ iconUrl?: string; /** The service provider of the agent */ provider?: AgentProvider; /** * The version of the agent - format is up to the provider. * @example "1.0.0" */ version: string; /** A URL to documentation for the agent. */ documentationUrl?: string; /** Optional capabilities supported by the agent. */ capabilities: AgentCapabilities; /** Security scheme details used for authenticating with this agent. */ securitySchemes?: { [scheme: string]: SecurityScheme }; /** Security requirements for contacting the agent. */ security?: { [scheme: string]: string[] }[]; /** * The set of interaction modes that the agent supports across all skills. This can be overridden per-skill. * Supported media types for input. */ defaultInputModes: string[]; /** Supported media types for output. */ defaultOutputModes: string[]; /** Skills are a unit of capability that an agent can perform. */ skills: AgentSkill[]; /** * true if the agent supports providing an extended agent card when the user is authenticated. * Defaults to false if not specified. */ supportsAuthenticatedExtendedCard?: boolean; } Field Name Type Required Description name string Yes Human-readable name of the agent. description string Yes Human-readable description. CommonMark MAY be used. url string Yes Base URL for the agent's A2A service. Must be absolute. HTTPS for production. provider AgentProvider No Information about the agent's provider. iconUrl string No A URL to an icon for the agent. version string Yes Agent or A2A implementation version string. documentationUrl string No URL to human-readable documentation for the agent. capabilities AgentCapabilities Yes Specifies optional A2A protocol features supported (e.g., streaming, push notifications). securitySchemes { [scheme: string]: SecurityScheme } No Security scheme details used for authenticating with this agent. undefined implies no A2A-advertised auth (not recommended for production). security { [scheme: string]: string[]; }[] No Security requirements for contacting the agent. defaultInputModes string[] Yes Input Media Types accepted by the agent. defaultOutputModes string[] Yes Output Media Types produced by the agent. skills AgentSkill[] Yes Array of skills. Must have at least one if the agent performs actions. supportsAuthenticatedExtendedCard boolean No Indicates support for retrieving a more detailed Agent Card via an authenticated endpoint. 5.5.1. AgentProvider Object¶Information about the organization or entity providing the agent./** * Represents the service provider of an agent. */ export interface AgentProvider { /** Agent provider's organization name. */ organization: string; /** Agent provider's URL. */ url: string; } Field Name Type Required Description organization string Yes Name of the organization/entity. url string Yes URL for the provider's website/contact. 5.5.2. AgentCapabilities ObjectSpecifies optional A2A protocol features supported by the agent./** * Defines optional capabilities supported by an agent. */ export interface AgentCapabilities { /** true if the agent supports SSE. */ streaming?: boolean; /** true if the agent can notify updates to client. */ pushNotifications?: boolean; /** true if the agent exposes status change history for tasks. */ stateTransitionHistory?: boolean; /** extensions supported by this agent. */ extensions?: AgentExtension[]; } Field Name Type Required Default Description streaming boolean No false Indicates support for SSE streaming methods (message/stream, tasks/resubscribe). pushNotifications boolean No false Indicates support for push notification methods (tasks/pushNotificationConfig/*). stateTransitionHistory boolean No false Placeholder for future feature: exposing detailed task status change history. extensions AgentExtension[] No [] A list of extensions supported by this agent. 5.5.2.1. AgentExtension ObjectSpecifies an extension to the A2A protocol supported by the agent./** * A declaration of an extension supported by an Agent. */ export interface AgentExtension { /** The URI of the extension. */ uri: string; /** A description of how this agent uses this extension. */ description?: string; /** Whether the client must follow specific requirements of the extension. */ required?: boolean; /** Optional configuration for the extension. */ params?: { [key: string]: any }; } Field Name Type Required Description uri string Yes The URI for the supported extension. required boolean No Whether the agent requires clients to follow some protocol logic specific to the extension. Clients should expect failures when attempting to interact with a server that requires an extension the client does not support. description string No A description of how the extension is used by the agent. params object No Configuration parameters specific to the extension 5.5.3. SecurityScheme ObjectDescribes the authentication requirements for accessing the agent's url endpoint. Refer Sample Agent Card for an example./** * Mirrors the OpenAPI Security Scheme Object * (https://swagger.io/specification/#security-scheme-object) */ export type SecurityScheme = | APIKeySecurityScheme | HTTPAuthSecurityScheme | OAuth2SecurityScheme | OpenIdConnectSecurityScheme; 5.5.4. AgentSkill ObjectDescribes a specific capability, function, or area of expertise the agent can perform or address./** * Represents a unit of capability that an agent can perform. */ export interface AgentSkill { /** Unique identifier for the agent's skill. */ id: string; /** Human readable name of the skill. */ name: string; /** * Description of the skill - will be used by the client or a human * as a hint to understand what the skill does. */ description: string; /** * Set of tagwords describing classes of capabilities for this specific skill. * @example ["cooking", "customer support", "billing"] */ tags: string[]; /** * The set of example scenarios that the skill can perform. * Will be used by the client as a hint to understand how the skill can be used. * @example ["I need a recipe for bread"] */ examples?: string[]; // example prompts for tasks /** * The set of interaction modes that the skill supports * (if different than the default). * Supported media types for input. */ inputModes?: string[]; /** Supported media types for output. */ outputModes?: string[]; } Field Name Type Required Description id string Yes Unique skill identifier within this agent. name string Yes Human-readable skill name. description string Yes Detailed skill description. CommonMark MAY be used. tags string[] Yes Keywords/categories for discoverability. examples string[] No Example prompts or use cases demonstrating skill usage. inputModes string[] No Overrides defaultInputModes for this specific skill. Accepted Media Types. outputModes string[] No Overrides defaultOutputModes for this specific skill. Produced Media Types. 5.6. Sample Agent Card{ "name": "GeoSpatial Route Planner Agent", "description": "Provides advanced route planning, traffic analysis, and custom map generation services. This agent can calculate optimal routes, estimate travel times considering real-time traffic, and create personalized maps with points of interest.", "url": "https://georoute-agent.example.com/a2a/v1", "provider": { "organization": "Example Geo Services Inc.", "url": "https://www.examplegeoservices.com" }, "iconUrl": "https://georoute-agent.example.com/icon.png", "version": "1.2.0", "documentationUrl": "https://docs.examplegeoservices.com/georoute-agent/api", "capabilities": { "streaming": true, "pushNotifications": true, "stateTransitionHistory": false }, "securitySchemes": { "google": { "type": "openIdConnect", "openIdConnectUrl": "https://accounts.google.com/.well-known/openid-configuration" } }, "security": [{ "google": ["openid", "profile", "email"] }], "defaultInputModes": ["application/json", "text/plain"], "defaultOutputModes": ["application/json", "image/png"], "skills": [ { "id": "route-optimizer-traffic", "name": "Traffic-Aware Route Optimizer", "description": "Calculates the optimal driving route between two or more locations, taking into account real-time traffic conditions, road closures, and user preferences (e.g., avoid tolls, prefer highways).", "tags": ["maps", "routing", "navigation", "directions", "traffic"], "examples": [ "Plan a route from '1600 Amphitheatre Parkway, Mountain View, CA' to 'San Francisco International Airport' avoiding tolls.", "{\"origin\": {\"lat\": 37.422, \"lng\": -122.084}, \"destination\": {\"lat\": 37.7749, \"lng\": -122.4194}, \"preferences\": [\"avoid_ferries\"]}" ], "inputModes": ["application/json", "text/plain"], "outputModes": [ "application/json", "application/vnd.geo+json", "text/html" ] }, { "id": "custom-map-generator", "name": "Personalized Map Generator", "description": "Creates custom map images or interactive map views based on user-defined points of interest, routes, and style preferences. Can overlay data layers.", "tags": ["maps", "customization", "visualization", "cartography"], "examples": [ "Generate a map of my upcoming road trip with all planned stops highlighted.", "Show me a map visualizing all coffee shops within a 1-mile radius of my current location." ], "inputModes": ["application/json"], "outputModes": [ "image/png", "image/jpeg", "application/json", "text/html" ] } ], "supportsAuthenticatedExtendedCard": true } 6. Protocol Data ObjectsThese objects define the structure of data exchanged within the JSON-RPC methods of the A2A protocol.6.1. Task ObjectRepresents the stateful unit of work being processed by the A2A Server for an A2A Client. A task encapsulates the entire interaction related to a specific goal or request.export interface Task { /** Unique identifier for the task */ id: string; /** Server-generated id for contextual alignment across interactions */ contextId: string; /** Current status of the task */ status: TaskStatus; history?: Message[]; /** Collection of artifacts created by the agent. */ artifacts?: Artifact[]; /** Extension metadata. */ metadata?: { [key: string]: any; }; /** Event type */ kind: "task"; } Field Name Type Required Description id string Yes Server generated unique task identifier (e.g., UUID) contextId string Yes Server generated ID for contextual alignment across interactions status TaskStatus Yes Current status of the task (state, message, timestamp). artifacts Artifact[] No Array of outputs generated by the agent for this task. history Message[] No Optional array of recent messages exchanged, if requested by historyLength. metadata Record<string, any> No Arbitrary key-value metadata associated with the task. 6.2. TaskStatus ObjectRepresents the current state and associated context (e.g., a message from the agent) of a Task./** TaskState and accompanying message. */ export interface TaskStatus { state: TaskState; /** Additional status updates for client */ message?: Message; /** * ISO 8601 datetime string when the status was recorded. * @example "2023-10-27T10:00:00Z" * */ timestamp?: string; } Field Name Type Required Description state TaskState Yes Current lifecycle state of the task. message Message No Optional message providing context for the current status. timestamp string (ISO 8601) No Timestamp (UTC recommended) when this status was recorded. 6.3. TaskState EnumDefines the possible lifecycle states of a Task./** Represents the possible states of a Task. */ export enum TaskState { Submitted = "submitted", Working = "working", InputRequired = "input-required", Completed = "completed", Canceled = "canceled", Failed = "failed", Rejected = "rejected", AuthRequired = "auth-required", Unknown = "unknown", } Value Description Terminal? submitted Task received by the server and acknowledged, but processing has not yet actively started. No working Task is actively being processed by the agent. Client may expect further updates or a terminal state. No input-required Agent requires additional input from the client/user to proceed. The task is effectively paused. No (Pause) completed Task finished successfully. Results are typically available in Task.artifacts or TaskStatus.message. Yes canceled Task was canceled (e.g., by a tasks/cancel request or server-side policy). Yes failed Task terminated due to an error during processing. TaskStatus.message may contain error details. Yes rejected Task terminated due to rejection by remote agent. TaskStatus.message may contain error details. Yes auth-required Agent requires additional authentication from the client/user to proceed. The task is effectively paused. No (Pause) unknown The state of the task cannot be determined (e.g., task ID is invalid, unknown, or has expired). Yes 6.4. Message ObjectRepresents a single communication turn or a piece of contextual information between a client and an agent. Messages are used for instructions, prompts, replies, and status updates./** Represents a single message exchanged between user and agent. */ export interface Message { /** Message sender's role */ role: "user" | "agent"; /** Message content */ parts: Part[]; /** Extension metadata. */ metadata?: { [key: string]: any; }; /** The URIs of extensions that are present or contributed to this Message. */ extensions?: string[]; /** List of tasks referenced as context by this message.*/ referenceTaskIds?: string[]; /** Identifier created by the message creator*/ messageId: string; /** Identifier of task the message is related to */ taskId?: string; /** The context the message is associated with */ contextId?: string; /** Event type */ kind: "message"; } Field Name Type Required Description role "user" | "agent" Yes Indicates the sender: "user" (from A2A Client) or "agent" (from A2A Server). parts Part[] Yes Array of content parts. Must contain at least one part. metadata Record<string, any> No Arbitrary key-value metadata associated with this message. extensions string[] No A list of extension URIs that contributed to this message. referenceTaskIds string[] No List of tasks referenced as contextual hint by this message. messageId string Yes Message identifier generated by the message sender taskId string No Task identifier the current message is related to contextId string No Context identifier the message is associated with kind "message" Yes Type discriminator, literal value 6.5. Part Union TypeRepresents a distinct piece of content within a Message or Artifact. A Part is a union type representing exportable content as either TextPart, FilePart, or DataPart. All Part types also include an optional metadata field (Record<string, any>) for part-specific metadata./** Represents a part of a message, which can be text, a file, or structured data. */ export type Part = TextPart | FilePart | DataPart; It MUST be one of the following:6.5.1. TextPart ObjectFor conveying plain textual content./** Represents a text segment within parts.*/ export interface TextPart extends PartBase { /** Part type - text for TextParts*/ kind: "text"; /** Text content */ text: string; } Field Name Type Required Description kind "text" (literal) Yes Identifies this part as textual content. text string Yes The textual content of the part. metadata Record<string, any> No Optional metadata specific to this text part. 6.5.2. FilePart ObjectFor conveying file-based content./** Represents a File segment within parts.*/ export interface FilePart extends PartBase { /** Part type - file for FileParts */ kind: "file"; /** File content either as url or bytes */ file: FileWithBytes | FileWithUri; } Field Name Type Required Description kind "file" (literal) Yes Identifies this part as file content. file FileWithBytes | FileWithUri Yes Contains the file details and data/reference. metadata Record<string, any> No Optional metadata specific to this file part. 6.5.3. DataPart ObjectFor conveying structured JSON data. Useful for forms, parameters, or any machine-readable information./** Represents a structured data segment within a message part. */ export interface DataPart extends PartBase { /** Part type - data for DataParts */ kind: "data"; /** Structured data content */ data: { [key: string]: any; }; } Field Name Type Required Description kind "data" (literal) Yes Identifies this part as structured data. data Record<string, any> Yes The structured JSON data payload (an object or an array). metadata Record<string, any> No Optional metadata specific to this data part (e.g., reference to a schema). 6.6.1 FileWithBytes ObjectRepresents the data for a file, used within a FilePart./** Define the variant where 'bytes' is present and 'uri' is absent */ export interface FileWithBytes extends FileBase { /** base64 encoded content of the file*/ bytes: string; uri?: never; } Field Name Type Required Description name string No Original filename (e.g., "report.pdf"). mimeType string No Media Type (e.g., image/png). Strongly recommended. bytes string Yes Base64 encoded file content. 6.6.2 FileWithUri ObjectRepresents the URI for a file, used within a FilePart./** Define the variant where 'uri' is present and 'bytes' is absent */ export interface FileWithUri extends FileBase { /** URL for the File content */ uri: string; bytes?: never; } Field Name Type Required Description name string No Original filename (e.g., "report.pdf"). mimeType string No Media Type (e.g., image/png). Strongly recommended. uri string Yes URI (absolute URL strongly recommended) to file content. Accessibility is context-dependent. 6.7. Artifact ObjectRepresents a tangible output generated by the agent during a task. Artifacts are the results or products of the agent's work./** Represents an artifact generated for a task. */ export interface Artifact { /** Unique identifier for the artifact. */ artifactId: string; /** Optional name for the artifact. */ name?: string; /** Optional description for the artifact. */ description?: string; /** Artifact parts. */ parts: Part[]; /** Extension metadata. */ metadata?: { [key: string]: any; }; /** The URIs of extensions that are present or contributed to this Artifact. */ extensions?: string[]; } Field Name Type Required Description artifactId string Yes Identifier for the artifact generated by the agent. name string No Descriptive name for the artifact. description string No Human-readable description of the artifact. parts Part[] Yes Content of the artifact, as one or more Part objects. Must have at least one. metadata Record<string, any> No Arbitrary key-value metadata associated with the artifact. extensions string[] No A list of extension URIs that contributed to this artifact. 6.8. PushNotificationConfig ObjectConfiguration provided by the client to the server for sending asynchronous push notifications about task updates./**Configuration for setting up push notifications for task updates. */ export interface PushNotificationConfig { /** Push Notification ID - created by server to support multiple callbacks */ id?: string; /** URL for sending the push notifications. */ url: string; /** Token unique to this task/session. */ token?: string; authentication?: PushNotificationAuthenticationInfo; } Field Name Type Required Description url string Yes Absolute HTTPS webhook URL for the A2A Server to POST task updates to. token string No Optional client-generated opaque token for the client's webhook receiver to validate the notification (e.g., server includes it in an X-A2A-Notification-Token header). authentication PushNotificationAuthenticationInfo No Authentication details the A2A Server must use when calling the url. The client's webhook (receiver) defines these requirements. 6.9. PushNotificationAuthenticationInfo ObjectA generic structure for specifying authentication requirements, typically used within PushNotificationConfig to describe how the A2A Server should authenticate to the client's webhook./** Defines authentication details for push notifications. */ export interface PushNotificationAuthenticationInfo { /** Supported authentication schemes - e.g. Basic, Bearer */ schemes: string[]; /** Optional credentials */ credentials?: string; } Field Name Type Required Description schemes string[] Yes Array of auth scheme names the A2A Server must use when calling the client's webhook (e.g., "Bearer", "ApiKey"). credentials string No Optional static credentials or scheme-specific configuration info. Handle with EXTREME CAUTION if secrets are involved. Prefer server-side dynamic credential fetching where possible. 6.10. TaskPushNotificationConfig ObjectUsed as the params object for the tasks/pushNotificationConfig/set method and as the result object for the tasks/pushNotificationConfig/get method./**Parameters for setting or getting push notification configuration for a task */ export interface TaskPushNotificationConfig { /** Task id. */ taskId: string; /** Push notification configuration. */ pushNotificationConfig: PushNotificationConfig; } Field Name Type Required Description taskId string Yes The ID of the task to configure push notifications for, or retrieve configuration from. pushNotificationConfig PushNotificationConfig Yes The push notification configuration. For set, the desired config. For get, the current config (secrets MAY be omitted by server). 6.11. JSON-RPC StructuresA2A adheres to the standard JSON-RPC 2.0 structures for requests and responses.6.11.1. JSONRPCRequest ObjectAll A2A method calls are encapsulated in a JSON-RPC Request object. jsonrpc: A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0". method: A String containing the name of the method to be invoked (e.g., "message/send", "tasks/get"). params: A Structured value that holds the parameter values to be used during the invocation of the method. This member MAY be omitted if the method expects no parameters. A2A methods typically use an object for params. id: An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD NOT be NULL for requests expecting a response, and Numbers SHOULD NOT contain fractional parts. The Server MUST reply with the same value in the Response object if included. This member is used to correlate the context between the two objects. A2A methods typically expect a response or stream, so id will usually be present and non-null. 6.11.2. JSONRPCResponse ObjectResponses from the A2A Server are encapsulated in a JSON-RPC Response object. jsonrpc: A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0". id: This member is REQUIRED. It MUST be the same as the value of the id member in the Request Object. If there was an error in detecting the id in the Request object (e.g. Parse error/Invalid Request), it MUST be null. EITHER result: This member is REQUIRED on success. This member MUST NOT exist if there was an error invoking the method. The value of this member is determined by the method invoked on the Server. OR error: This member is REQUIRED on failure. This member MUST NOT exist if there was no error triggered during invocation. The value of this member MUST be an JSONRPCError object. The members result and error are mutually exclusive: one MUST be present, and the other MUST NOT. 6.12. JSONRPCError ObjectWhen a JSON-RPC call encounters an error, the Response Object will contain an error member with a value of this structure./** * Represents a JSON-RPC 2.0 Error object. * This is typically included in a JSONRPCErrorResponse when an error occurs. */ export interface JSONRPCError { /** * A Number that indicates the error type that occurred. */ code: number; /** * A String providing a short description of the error. */ message: string; /** * A Primitive or Structured value that contains additional information about the error. * This may be omitted. */ data?: any; } Field Name Type Required Description code integer Yes Integer error code. See Section 8 (Error Handling) for standard and A2A-specific codes. message string Yes Short, human-readable summary of the error. data any No Optional additional structured information about the error. 7. Protocol RPC MethodsAll A2A RPC methods are invoked by the A2A Client by sending an HTTP POST request to the A2A Server's url (as specified in its AgentCard). The body of the HTTP POST request MUST be a JSONRPCRequest object, and the Content-Type header MUST be application/json.The A2A Server's HTTP response body MUST be a JSONRPCResponse object (or, for streaming methods, an SSE stream where each event's data is a JSONRPCResponse). The Content-Type for JSON-RPC responses is application/json. For SSE streams, it is text/event-stream.7.1. message/sendSends a message to an agent to initiate a new interaction or to continue an existing one. This method is suitable for synchronous request/response interactions or when client-side polling (using tasks/get) is acceptable for monitoring longer-running tasks. Request params type: MessageSendParams Response result type (on success): Task | Message (A message object or the current or final state of the task after processing the message). Response error type (on failure): JSONRPCError. 7.1.1. MessageSendParams Object/** Sent by the client to the agent as a request. May create, continue or restart a task. */ export interface MessageSendParams { /** The message being sent to the server. */ message: Message; /** Send message configuration. */ configuration?: MessageSendConfiguration; /** Extension metadata. */ metadata?: { [key: string]: any; }; } /**Configuration for the send message request. */ export interface MessageSendConfiguration { /** Accepted output modalities by the client. */ acceptedOutputModes: string[]; /** Number of recent messages to be retrieved. */ historyLength?: number; /** Where the server should send notifications when disconnected. */ pushNotificationConfig?: PushNotificationConfig; /** If the server should treat the client as a blocking request. */ blocking?: boolean; } Field Name Type Required Description message Message Yes The message content to send. Message.role is typically "user". configuration MessageSendConfiguration No Optional: additional message configuration metadata Record<string, any> No Request-specific metadata. 7.2. message/streamSends a message to an agent to initiate/continue a task AND subscribes the client to real-time updates for that task via Server-Sent Events (SSE). This method requires the server to have AgentCard.capabilities.streaming: true. Request params type: MessageSendParams (same as message/send). Response (on successful subscription): HTTP Status: 200 OK. HTTP Content-Type: text/event-stream. HTTP Body: A stream of Server-Sent Events. Each SSE data field contains a SendStreamingMessageResponse JSON object. Response (on initial subscription failure):Standard HTTP error code (e.g., 4xx, 5xx).The HTTP body MAY contain a standard JSONRPCResponse with an error object detailing the failure.7.2.1. SendStreamingMessageResponse ObjectThis is the structure of the JSON object found in the data field of each Server-Sent Event sent by the server for a message/stream request or tasks/resubscribe request./** * JSON-RPC response model for the 'message/stream' method. */ export type SendStreamingMessageResponse = | SendStreamingMessageSuccessResponse | JSONRPCErrorResponse; /** * JSON-RPC success response model for the 'message/stream' method. */ export interface SendStreamingMessageSuccessResponse extends JSONRPCSuccessResponse { result: Message | Task | TaskStatusUpdateEvent | TaskArtifactUpdateEvent; } Field Name Type Required Description jsonrpc "2.0" (literal) Yes JSON-RPC version string. id string | number Yes Matches the id from the originating message/stream or tasks/resubscribe request. result Either Message OR Task OR TaskStatusUpdateEvent OR TaskArtifactUpdateEvent Yes The event payload 7.2.2. TaskStatusUpdateEvent ObjectCarries information about a change in the task's status during streaming. This is one of the possible result types in a SendStreamingMessageSuccessResponse./** Sent by server during sendStream or subscribe requests */ export interface TaskStatusUpdateEvent { /** Task id */ taskId: string; /** The context the task is associated with */ contextId: string; /** Event type */ kind: "status-update"; /** Current status of the task */ status: TaskStatus; /** Indicates the end of the event stream */ final: boolean; /** Extension metadata. */ metadata?: { [key: string]: any; }; } Field Name Type Required Default Description taskId string Yes Task ID being updated contextId string Yes Context ID the task is associated with kind string, literal Yes status-update Type discriminator, literal value status TaskStatus Yes The new TaskStatus object. final boolean No false If true, indicates this is the terminal status update for the current stream cycle. The server typically closes the SSE connection after this. metadata Record<string, any> No undefined Event-specific metadata. 7.2.3. TaskArtifactUpdateEvent ObjectCarries a new or updated artifact (or a chunk of an artifact) generated by the task during streaming. This is one of the possible result types in a SendTaskStreamingResponse./** Sent by server during sendStream or subscribe requests */ export interface TaskArtifactUpdateEvent { /** Task id */ taskId: string; /** The context the task is associated with */ contextId: string; /** Event type */ kind: "artifact-update"; /** Generated artifact */ artifact: Artifact; /** Indicates if this artifact appends to a previous one */ append?: boolean; /** Indicates if this is the last chunk of the artifact */ lastChunk?: boolean; /** Extension metadata. */ metadata?: { [key: string]: any; }; } Field Name Type Required Default Description taskId string Yes Task ID associated with the generated artifact part contextId string Yes Context ID the task is associated with kind string, literal Yes artifact-update Type discriminator, literal value artifact Artifact Yes The Artifact data. Could be a complete artifact or an incremental chunk. append boolean No false true means append parts to artifact; false (default) means replace. lastChunk boolean No false true indicates this is the final update for the artifact. metadata Record<string, any> No undefined Event-specific metadata. 7.3. tasks/getRetrieves the current state (including status, artifacts, and optionally history) of a previously initiated task. This is typically used for polling the status of a task initiated with message/send, or for fetching the final state of a task after being notified via a push notification or after an SSE stream has ended. Request params type: TaskQueryParams Response result type (on success): Task (A snapshot of the task's current state). Response error type (on failure): JSONRPCError (e.g., if the task ID is not found, see TaskNotFoundError). 7.3.1. TaskQueryParams Object¶/** Parameters for querying a task, including optional history length. */ export interface TaskQueryParams extends TaskIdParams { /** Number of recent messages to be retrieved. */ historyLength?: number; } Field Name Type Required Description id string Yes The ID of the task whose current state is to be retrieved. historyLength integer No If positive, requests the server to include up to N recent messages in Task.history. metadata Record<string, any> No Request-specific metadata. 7.4. tasks/cancelRequests the cancellation of an ongoing task. The server will attempt to cancel the task, but success is not guaranteed (e.g., the task might have already completed or failed, or cancellation might not be supported at its current stage). Request params type: TaskIdParams Response result type (on success): Task (The state of the task after the cancellation attempt. Ideally, Task.status.state will be "canceled" if successful). Response error type (on failure): JSONRPCError (e.g., TaskNotFoundError, TaskNotCancelableError). 7.4.1. TaskIdParams Object (for tasks/cancel and tasks/pushNotificationConfig/get)A simple object containing just the task ID and optional metadata./** Parameters containing only a task ID, used for simple task operations. */ export interface TaskIdParams { /** Task id. */ id: string; metadata?: { [key: string]: any; }; } Field Name Type Required Description id string Yes The ID of the task. metadata Record<string, any> No Request-specific metadata. 7.5. tasks/pushNotificationConfig/setSets or updates the push notification configuration for a specified task. This allows the client to tell the server where and how to send asynchronous updates for the task. Requires the server to have AgentCard.capabilities.pushNotifications: true. Request params type: TaskPushNotificationConfig Response result type (on success): TaskPushNotificationConfig (Confirms the configuration that was set. The server MAY omit or mask any sensitive details like secrets from the authentication.credentials field in the response). Response error type (on failure): JSONRPCError (e.g., PushNotificationNotSupportedError, TaskNotFoundError, errors related to invalid PushNotificationConfig). 7.6. tasks/pushNotificationConfig/get¶Retrieves the current push notification configuration for a specified task. Requires the server to have AgentCard.capabilities.pushNotifications: true. Request params type: TaskIdParams Response result type (on success): TaskPushNotificationConfig (The current push notification configuration for the task. Server may return an error if no push notification configuration is associated with the task). Response error type (on failure): JSONRPCError (e.g., PushNotificationNotSupportedError, TaskNotFoundError). 7.7. tasks/resubscribeAllows a client to reconnect to an SSE stream for an ongoing task after a previous connection (from message/stream or an earlier tasks/resubscribe) was interrupted. Requires the server to have AgentCard.capabilities.streaming: true.The purpose is to resume receiving subsequent updates. The server's behavior regarding events missed during the disconnection period (e.g., whether it attempts to backfill some missed events or only sends new ones from the point of resubscription) is implementation-dependent and not strictly defined by this specification. Request params type: TaskIdParams Response (on successful resubscription): HTTP Status: 200 OK. HTTP Content-Type: text/event-stream. HTTP Body: A stream of Server-Sent Events, identical in format to message/stream, carrying subsequent SendStreamingMessageResponse events for the task. Response (on resubscription failure):Standard HTTP error code (e.g., 4xx, 5xx).The HTTP body MAY contain a standard JSONRPCResponse with an error object. Failures can occur if the task is no longer active, doesn't exist, or streaming is not supported/enabled for it.7.8. agent/authenticatedExtendedCardRetrieves a potentially more detailed version of the Agent Card after the client has authenticated. This endpoint is available only if AgentCard.supportsAuthenticatedExtendedCard is true. This is an HTTP GET endpoint, not a JSON-RPC method. Endpoint URL: {AgentCard.url}/../agent/authenticatedExtendedCard (relative to the base URL specified in the public Agent Card). HTTP Method: GET Authentication: The client MUST authenticate the request using one of the schemes declared in the public AgentCard.securitySchemes and AgentCard.security fields. Request params: None (HTTP GET request). Response result type (on success): AgentCard (A complete Agent Card object, which may contain additional details or skills not present in the public card). Response error type (on failure): Standard HTTP error codes. 401 Unauthorized: Authentication failed (missing or invalid credentials). The server SHOULD include a WWW-Authenticate header. 403 Forbidden: Authentication succeeded, but the client/user is not authorized to access the extended card. 404 Not Found: The supportsAuthenticatedExtendedCard capability is declared, but the server has not implemented this endpoint at the specified path. 5xx Server Error: An internal server error occurred. Clients retrieving this authenticated card SHOULD replace their cached public Agent Card with the content received from this endpoint for the duration of their authenticated session or until the card's version changes.7.8.1. AuthenticatedExtendedCardParams Object¶This endpoint does not use JSON-RPC params. Any parameters would be included as HTTP query parameters if needed (though none are defined by the standard).7.8.2. AuthenticatedExtendedCardResponse Object¶The successful response body is a JSON object conforming to the AgentCard interface. 8. Error Handling¶A2A uses standard JSON-RPC 2.0 error codes and structure for reporting errors. Errors are returned in the error member of the JSONRPCErrorResponse object. See JSONRPCError Object definition.8.1. Standard JSON-RPC Errors¶These are standard codes defined by the JSON-RPC 2.0 specification. Code JSON-RPC Spec Meaning Typical A2A message Description -32700 Parse error Invalid JSON payload Server received JSON that was not well-formed. -32600 Invalid Request Invalid JSON-RPC Request The JSON payload was valid JSON, but not a valid JSON-RPC Request object. -32601 Method not found Method not found The requested A2A RPC method (e.g., "tasks/foo") does not exist or is not supported. -32602 Invalid params Invalid method parameters The params provided for the method are invalid (e.g., wrong type, missing required field). -32603 Internal error Internal server error An unexpected error occurred on the server during processing. -32000 to -32099 Server error (Server-defined) Reserved for implementation-defined server-errors. A2A-specific errors use this range. 8.2. A2A-Specific Errors¶These are custom error codes defined within the JSON-RPC server error range (-32000 to -32099) to provide more specific feedback about A2A-related issues. Servers SHOULD use these codes where applicable. Code Error Name (Conceptual) Typical message string Description -32001 TaskNotFoundError Task not found The specified task id does not correspond to an existing or active task. It might be invalid, expired, or already completed and purged. -32002 TaskNotCancelableError Task cannot be canceled An attempt was made to cancel a task that is not in a cancelable state (e.g., it has already reached a terminal state like completed, failed, or canceled). -32003 PushNotificationNotSupportedError Push Notification is not supported Client attempted to use push notification features (e.g., tasks/pushNotificationConfig/set) but the server agent does not support them (i.e., AgentCard.capabilities.pushNotifications is false). -32004 UnsupportedOperationError This operation is not supported The requested operation or a specific aspect of it (perhaps implied by parameters) is not supported by this server agent implementation. Broader than just method not found. -32005 ContentTypeNotSupportedError Incompatible content types A Media Type provided in the request's message.parts (or implied for an artifact) is not supported by the agent or the specific skill being invoked. -32006 InvalidAgentResponseError Invalid agent response type Agent generated an invalid response for the requested method Servers MAY define additional error codes within the -32000 to -32099 range for more specific scenarios not covered above, but they SHOULD document these clearly. The data field of the JSONRPCError object can be used to provide more structured details for any error.9. Common Workflows & Examples¶This section provides illustrative JSON examples of common A2A interactions. Timestamps, context IDs, and request/response IDs are for demonstration purposes. For brevity, some optional fields might be omitted if not central to the example.9.1. Fetching Authenticated Extended Agent Card¶Scenario: A client discovers a public Agent Card indicating support for an authenticated extended card and wants to retrieve the full details. Client fetches the public Agent Card: GET https://example.com/.well-known/agent.json Server responds with the public Agent Card (like the example in Section 5.6), including supportsAuthenticatedExtendedCard: true (at the root level) and securitySchemes. Client identifies required authentication from the public card. Client obtains necessary credentials out-of-band (e.g., performs OAuth 2.0 flow with Google, resulting in an access token). Client fetches the authenticated extended Agent Card: GET https://example.com/a2a/agent/authenticatedExtendedCard Authorization: Bearer <obtained_access_token> Server authenticates and authorizes the request. Server responds with the full Agent Card: 9.2. Basic Execution (Synchronous / Polling Style)¶Scenario: Client asks a simple question, and the agent responds quickly with a task Client sends a message using message/send: { "jsonrpc": "2.0", "id": 1, "method": "message/send", "params": { "message": { "role": "user", "parts": [ { "kind": "text", "text": "tell me a joke" } ], "messageId": "9229e770-767c-417b-a0b0-f0741243c589" }, "metadata": {} } } Server processes the request, creates a task and responds (task completes quickly) { "jsonrpc": "2.0", "id": 1, "result": { "id": "363422be-b0f9-4692-a24d-278670e7c7f1", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4", "status": { "state": "completed" }, "artifacts": [ { "artifactId": "9b6934dd-37e3-4eb1-8766-962efaab63a1", "name": "joke", "parts": [ { "kind": "text", "text": "Why did the chicken cross the road? To get to the other side!" } ] } ], "history": [ { "role": "user", "parts": [ { "kind": "text", "text": "tell me a joke" } ], "messageId": "9229e770-767c-417b-a0b0-f0741243c589", "taskId": "363422be-b0f9-4692-a24d-278670e7c7f1", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4" } ], "kind": "task", "metadata": {} } } Scenario: Client asks a simple question, and the agent responds quickly without a task Client sends a message using message/send: { "jsonrpc": "2.0", "id": 1, "method": "message/send", "params": { "message": { "role": "user", "parts": [ { "kind": "text", "text": "tell me a joke" } ], "messageId": "9229e770-767c-417b-a0b0-f0741243c589" }, "metadata": {} } } Server processes the request, responds quickly without a task { "jsonrpc": "2.0", "id": 1, "result": { "messageId": "363422be-b0f9-4692-a24d-278670e7c7f1", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4", "parts": [ { "kind": "text", "text": "Why did the chicken cross the road? To get to the other side!" } ], "kind": "message", "metadata": {} } } If the task were longer-running, the server might initially respond with status.state: "working". The client would then periodically call tasks/get with params: {"id": "363422be-b0f9-4692-a24d-278670e7c7f1"} until the task reaches a terminal state.9.3. Streaming Task Execution (SSE)¶Scenario: Client asks the agent to write a long paper describing an attached picture. Client sends a message and subscribes using message/stream: { "method": "message/stream", "params": { "message": { "role": "user", "parts": [ { "kind": "text", "text": "write a long paper describing the attached pictures" }, { "kind": "file", "file": { "mimeType": "image/png", "data": "<base64-encoded-content>" } } ], "messageId": "bbb7dee1-cf5c-4683-8a6f-4114529da5eb" }, "metadata": {} } } Server responds with HTTP 200 OK, Content-Type: text/event-stream, and starts sending SSE events: Event 1: Task status update - workingdata: { "jsonrpc": "2.0", "id": 1, "result": { "id": "225d6247-06ba-4cda-a08b-33ae35c8dcfa", "contextId": "05217e44-7e9f-473e-ab4f-2c2dde50a2b1", "status": { "state": "submitted", "timestamp":"2025-04-02T16:59:25.331844" }, "history": [ { "role": "user", "parts": [ { "kind": "text", "text": "write a long paper describing the attached pictures" }, { "kind": "file", "file": { "mimeType": "image/png", "data": "<base64-encoded-content>" } } ], "messageId": "bbb7dee1-cf5c-4683-8a6f-4114529da5eb", "taskId": "225d6247-06ba-4cda-a08b-33ae35c8dcfa", "contextId": "05217e44-7e9f-473e-ab4f-2c2dde50a2b1" } ], "kind": "task", "metadata": {} } } data: { "jsonrpc": "2.0", "id": 1, "result": { "taskId": "225d6247-06ba-4cda-a08b-33ae35c8dcfa", "contextId": "05217e44-7e9f-473e-ab4f-2c2dde50a2b1", "artifact": { "artifactId": "9b6934dd-37e3-4eb1-8766-962efaab63a1", "parts": [ {"type":"text", "text": " "} ] }, "append": false, "lastChunk": false, "kind":"artifact-update" } } data: { "jsonrpc": "2.0", "id": 1, "result": { "taskId": "225d6247-06ba-4cda-a08b-33ae35c8dcfa", "contextId": "05217e44-7e9f-473e-ab4f-2c2dde50a2b1", "artifact": { "artifactId": "9b6934dd-37e3-4eb1-8766-962efaab63a1", "parts": [ {"type":"text", "text": " "} ], }, "append": true, "lastChunk": false, "kind":"artifact-update" } } data: { "jsonrpc": "2.0", "id": 1, "result": { "taskId": "225d6247-06ba-4cda-a08b-33ae35c8dcfa", "contextId": "05217e44-7e9f-473e-ab4f-2c2dde50a2b1", "artifact": { "artifactId": "9b6934dd-37e3-4eb1-8766-962efaab63a1", "parts": [ {"type":"text", "text": " "} ] }, "append": true, "lastChunk": true, "kind":"artifact-update" } } data: { "jsonrpc": "2.0", "id": 1, "result": { "taskId": "225d6247-06ba-4cda-a08b-33ae35c8dcfa", "contextId": "05217e44-7e9f-473e-ab4f-2c2dde50a2b1", "status": { "state": "completed", "timestamp":"2025-04-02T16:59:35.331844" }, "final": true, "kind":"status-update" } } (Server closes the SSE connection after the final:true event).9.4. Multi-Turn Interaction (Input Required)¶Scenario: Client wants to book a flight, and the agent needs more information. Client sends a message using message/send: { "jsonrpc": "2.0", "id": "req-003", "method": "message/send", "params": { "message": { "role": "user", "parts": [{ "kind": "text", "text": "I'd like to book a flight." }] }, "messageId": "c53ba666-3f97-433c-a87b-6084276babe2" } } Server responds, task state is input-required: { "jsonrpc": "2.0", "id": "req-003", "result": { "id": "3f36680c-7f37-4a5f-945e-d78981fafd36", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4", "status": { "state": "input-required", "message": { "role": "agent", "parts": [ { "kind": "text", "text": "Sure, I can help with that! Where would you like to fly to, and from where? Also, what are your preferred travel dates?" } ], "messageId": "c2e1b2dd-f200-4b04-bc22-1b0c65a1aad2", "taskId": "3f36680c-7f37-4a5f-945e-d78981fafd36", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4" }, "timestamp": "2024-03-15T10:10:00Z" }, "history": [ { "role": "user", "parts": [ { "kind": "text", "text": "I'd like to book a flight." } ], "messageId": "c53ba666-3f97-433c-a87b-6084276babe2", "taskId": "3f36680c-7f37-4a5f-945e-d78981fafd36", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4" } ], "kind": "task" } } Client message/send (providing the requested input, using the same task ID): { "jsonrpc": "2.0", "id": "req-004", "method": "message/send", "params": { "message": { "role": "user", "parts": [ { "kind": "text", "text": "I want to fly from New York (JFK) to London (LHR) around October 10th, returning October 17th." } ], "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4", "taskId": "3f36680c-7f37-4a5f-945e-d78981fafd36", "messageId": "0db1d6c4-3976-40ed-b9b8-0043ea7a03d3" }, "configuration": { "blocking": true } } } Server processes the new input and responds (e.g., task completed or more input needed): { "jsonrpc": "2.0", "id": "req-004", "result": { "id": "3f36680c-7f37-4a5f-945e-d78981fafd36", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4", "status": { "state": "completed", "message": { "role": "agent", "parts": [ { "kind": "text", "text": "Okay, I've found a flight for you. Confirmation XYZ123. Details are in the artifact." } ] } }, "artifacts": [ { "artifactId": "9b6934dd-37e3-4eb1-8766-962efaab63a1", "name": "FlightItinerary.json", "parts": [ { "kind": "data", "data": { "confirmationId": "XYZ123", "from": "JFK", "to": "LHR", "departure": "2024-10-10T18:00:00Z", "arrival": "2024-10-11T06:00:00Z", "returnDeparture": "..." } } ] } ], "history": [ { "role": "user", "parts": [ { "kind": "text", "text": "I'd like to book a flight." } ], "messageId": "c53ba666-3f97-433c-a87b-6084276babe2", "taskId": "3f36680c-7f37-4a5f-945e-d78981fafd36", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4" }, { "role": "agent", "parts": [ { "kind": "text", "text": "Sure, I can help with that! Where would you like to fly to, and from where? Also, what are your preferred travel dates?" } ], "messageId": "c2e1b2dd-f200-4b04-bc22-1b0c65a1aad2", "taskId": "3f36680c-7f37-4a5f-945e-d78981fafd36", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4" }, { "role": "user", "parts": [ { "kind": "text", "text": "I want to fly from New York (JFK) to London (LHR) around October 10th, returning October 17th." } ], "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4", "taskId": "3f36680c-7f37-4a5f-945e-d78981fafd36", "messageId": "0db1d6c4-3976-40ed-b9b8-0043ea7a03d3" } ], "kind": "task", "metadata": {} } } 9.5. Push Notification Setup and Usage¶Scenario: Client requests a long-running report generation and wants to be notified via webhook when it's done. Client message/send with pushNotification config: { "jsonrpc": "2.0", "id": "req-005", "method": "message/send", "params": { "message": { "role": "user", "parts": [ { "kind": "text", "text": "Generate the Q1 sales report. This usually takes a while. Notify me when it's ready." } ], "messageId": "6dbc13b5-bd57-4c2b-b503-24e381b6c8d6" }, "configuration": { "pushNotificationConfig": { "url": "https://client.example.com/webhook/a2a-notifications", "token": "secure-client-token-for-task-aaa", "authentication": { "schemes": ["Bearer"] // Assuming server knows how to get a Bearer token for this webhook audience, // or this implies the webhook is public/uses the 'token' for auth. // 'credentials' could provide more specifics if needed by the server. } } } } } Server acknowledges the task (e.g., status submitted or working): { "jsonrpc": "2.0", "id": "req-005", "result": { "id": "43667960-d455-4453-b0cf-1bae4955270d", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4", "status": { "state": "submitted", "timestamp": "2024-03-15T11:00:00Z" } // ... other fields ... } } (Later) A2A Server completes the task and POSTs a notification to https://client.example.com/webhook/a2a-notifications: HTTP Headers might include: Authorization: Bearer <server_jwt_for_webhook_audience> (if server authenticates to webhook) Content-Type: application/json X-A2A-Notification-Token: secure-client-token-for-task-aaa HTTP Body (Task object is sent as JSON payload): { "id": "43667960-d455-4453-b0cf-1bae4955270d", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4", "status": { "state": "completed", "timestamp": "2024-03-15T18:30:00Z" }, "kind": "task" // ... other fields ... } Client's Webhook Service: Receives the POST. Validates the Authorization header (if applicable). Validates the X-A2A-Notification-Token. Internally processes the notification (e.g., updates application state, notifies end user). 9.6. File Exchange (Upload and Download)¶Scenario: Client sends an image for analysis, and the agent returns a modified image. Client message/send with a FilePart (uploading image bytes): { "jsonrpc": "2.0", "id": "req-007", "method": "message/send", "params": { "message": { "role": "user", "parts": [ { "kind": "text", "text": "Analyze this image and highlight any faces." }, { "kind": "file", "file": { "name": "input_image.png", "mimeType": "image/png", "bytes": "iVBORw0KGgoAAAANSUhEUgAAAAUA..." // Base64 encoded image data } } ], "messageId": "6dbc13b5-bd57-4c2b-b503-24e381b6c8d6" } } } Server processes the image and responds with a FilePart in an artifact (e.g., providing a URI to the modified image): { "jsonrpc": "2.0", "id": "req-007", "result": { "id": "43667960-d455-4453-b0cf-1bae4955270d", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4", "status": { "state": "completed", "timestamp": "2024-03-15T12:05:00Z" }, "artifacts": [ { "artifactId": "9b6934dd-37e3-4eb1-8766-962efaab63a1", "name": "processed_image_with_faces.png", "parts": [ { "kind": "file", "file": { "name": "output.png", "mimeType": "image/png", // Server might provide a URI to a temporary storage location "uri": "https://storage.example.com/processed/task-bbb/output.png?token=xyz" // Or, alternatively, it could return bytes directly: // "bytes": "ASEDGhw0KGgoAAAANSUhEUgAA..." } } ] } ], "kind": "task" } } 9.7. Structured Data Exchange (Requesting and Providing JSON)¶Scenario: Client asks for a list of open support tickets in a specific JSON format. Client message/send, Part.metadata hints at desired output schema/Media Type: (Note: A2A doesn't formally standardize schema negotiation in v0.2.0, but metadata can be used for such hints by convention between client/server). { "jsonrpc": "2.0", "id": 9, "method": "message/send", "params": { "message": { "role": "user", "parts": [ { "kind": "text", "text": "Show me a list of my open IT tickets", "metadata": { "mimeType": "application/json", "schema": { "type": "array", "items": { "type": "object", "properties": { "ticketNumber": { "type": "string" }, "description": { "type": "string" } } } } } } ], "messageId": "85b26db5-ffbb-4278-a5da-a7b09dea1b47" }, "metadata": {} } } Server responds with structured JSON data: { "jsonrpc": "2.0", "id": 9, "result": { "id": "d8c6243f-5f7a-4f6f-821d-957ce51e856c", "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4", "status": { "state": "completed", "timestamp": "2025-04-17T17:47:09.680794" }, "artifacts": [ { "artifactId": "c5e0382f-b57f-4da7-87d8-b85171fad17c", "parts": [ { "kind": "text", "text": "[{\"ticketNumber\":\"REQ12312\",\"description\":\"request for VPN access\"},{\"ticketNumber\":\"REQ23422\",\"description\":\"Add to DL - team-gcp-onboarding\"}]" } ] } ], "kind": "task" } } These examples illustrate the flexibility of A2A in handling various interaction patterns and data types. Implementers should refer to the detailed object definitions for all fields and constraints.10. Appendices¶10.1. Relationship to MCP (Model Context Protocol)¶A2A and MCP are complementary protocols designed for different aspects of agentic systems: Model Context Protocol (MCP): Focuses on standardizing how AI models and agents connect to and interact with tools, APIs, data sources, and other external resources. It defines structured ways to describe tool capabilities (like function calling in LLMs), pass inputs, and receive structured outputs. Think of MCP as the "how-to" for an agent to use a specific capability or access a resource. Agent2Agent Protocol (A2A): Focuses on standardizing how independent, often opaque, AI agents communicate and collaborate with each other as peers. A2A provides an application-level protocol for agents to discover each other, negotiate interaction modalities, manage shared tasks, and exchange conversational context or complex results. It's about how agents partner or delegate work. How they work together: An A2A Client agent might request an A2A Server agent to perform a complex task. The Server agent, in turn, might use MCP to interact with several underlying tools, APIs, or data sources to gather information or perform actions necessary to fulfill the A2A task.For a more detailed comparison, see the A2A and MCP guide.10.2. Security Considerations Summary¶Security is a paramount concern in A2A. Key considerations include: Transport Security: Always use HTTPS with strong TLS configurations in production environments. Authentication: Handled via standard HTTP mechanisms (e.g., Authorization header with Bearer tokens, API keys). Requirements are declared in the AgentCard. Credentials MUST be obtained out-of-band by the client. A2A Servers MUST authenticate every request. Authorization:A server-side responsibility based on the authenticated identity.Implement the principle of least privilege.Can be granular, based on skills, actions, or data.Push Notification Security:Webhook URL validation (by the A2A Server sending notifications) is crucial to prevent SSRF.Authentication of the A2A Server to the client's webhook is essential.Authentication of the notification by the client's webhook receiver (verifying it came from the legitimate A2A Server and is relevant) is critical.See the Streaming & Asynchronous Operations guide for detailed push notification security.输入验证：Message服务器必须严格验证所有 RPC 参数以及部分数据的内容/结构，Artifact以防止注入攻击或处理错误。资源管理：实施速率限制、并发控制和资源限制，以保护代理免受滥用或过载。数据隐私：遵守所有适用于数据交换的隐私法规Message。Artifact尽量减少敏感数据的传输。如需全面讨论，请参阅企业就绪功能指南。源文地址：https://google-a2a.github.io/A2A/specification/
AI摘要 Google宣布了一系列A2A技术更新，包括代理开发套件(ADK)的增强功能、代理引擎界面的推出以及Agent2Agent (A2A)协议的全面升级。这些更新旨在帮助开发者构建更复杂、可靠且具有影响力的智能代理解决方案。Python ADK v1.0.0稳定版发布，Java ADK v0.1.0初始版本发布，代理引擎用户界面推出，A2A协议规范0.2版本发布，以及A2A Python SDK推出。新的A2A合作伙伴包括Auth0、Box AI、Microsoft、SAP和Zoom，共同推动A2A生态系统的成长。 document.addEventListener('DOMContentLoaded', function() { const urlDisplay = document.getElementById('urlDisplay'); urlDisplay.textContent = "此内容根据文章生成，更内容请访问：" + window.location.href; }); 在 Google，我们展望这样一个未来：智能代理不仅仅是工具，更是解决复杂挑战、优化工作流、释放全新可能性的协作伙伴。我们认为，要实现这一愿景，关键在于为开发者提供一个具备灵活性、可信度与全面能力的平台。今天，我们很高兴能与您分享我们产品组合中一系列意义重大的更新，这些更新正是围绕这一理念打造，旨在帮助您以前所未有的便捷性与强大能力，构建并管理您的智能代理。这些增强功能聚焦于提供强大的开发工具、直观的管理界面以及无缝的代理间通信，为下一代 AI 驱动的解决方案打造更加坚实的基石。助力构建可靠而灵活的代理：代理开发套件 (ADK)为了让您能够构建具备稳定性和适应性的复杂代理系统，我们在代理开发套件 (ADK) 中引入了多项重要创新。Python ADK v1.0.0：适用于生产就绪型代理的稳定版本我们很高兴地宣布正式发布 Python 代理开发套件 v1.0.0 稳定版。这一里程碑标志着 Python ADK 已达到生产就绪状态，可为开发者提供一个可靠、稳健的平台，使其能够在实际环境中安心构建和部署代理系统。我们已经收到来自现有代理开发套件用户的积极反馈，包括 Renault Group、Box 和 Revionics 等企业。Java ADK v0.1.0：将代理能力拓展至 Java 生态系统为了进一步扩大适用范围，我们同时发布了 Java ADK v0.1.0 的初始版本。此次发布将 ADK 的强大功能与灵活性引入了 Java 开发环境，使 Java 开发者也能利用该套件的能力，满足其代理系统的开发需要。要开始使用 Java ADK，请将以下依赖项添加到您的 Maven 项目中：<groupId>com.google.adk</groupId> <artifactId>google-adk</artifactId> <version>0.1.0</version>XML[vplayer url="https://storage.googleapis.com/gweb-developer-goog-blog-assets/original_videos/AE_console_UI_demo.mp4" pic="https://www.samool.com/usr/uploads/2025/06/2156519748.png" /]直观的控制与管理：代理引擎界面Vertex AI 代理引擎有助于开发者在生产环境中部署、管理和扩展代理系统。我们很高兴现在推出代理引擎用户界面，以更加直观和集中化的方式简化代理生命周期管理。这一便于使用的界面可通过 Google Cloud 控制台访问，并提供全面的仪表板，供您查看和管理已部署的代理、列出会话记录、追踪并调试操作，并监控代理的状态。这种简化的流程显著提升了开发和管理效率，让您对代理的行为和性能拥有更强的控制力和更深入的洞察。代理引擎界面：您可以在这里查看已部署的代理、监控指标（如请求量和 CPU 使用率）、管理会话、查看部署详情，并深入分析跟踪记录。无缝且安全的协作：全面升级 Agent2Agent (A2A) 协议为了让代理真正成为可靠的协作伙伴，它们之间需要能够有效且安全地进行通信。我们正与合作伙伴一道，持续改进 Agent2Agent (A2A) 协议，以在代理之间实现更复杂、更可靠的交互。更轻量、更安全的交互更新的 A2A 协议规范 (v0.2)我们已推出 A2A 协议规范的 0.2 版本，包含以下关键改进：支持无状态交互：此次更新简化了无需会话管理场景下的开发流程，实现了更高效、更轻量的通信方式。标准化的身份验证：我们基于类似 OpenAPI 的身份验证架构，正式定义了统一的身份验证方案，确保代理之间清晰传达身份验证需求，从而提升代理间交互的安全性与可靠性。简化与 A2A Python SDK 的集成为了让开发者更轻松地使用 A2A 协议，我们推出了适用于 A2A 的官方 Python SDK。这一专用软件开发套件提供了与 A2A 交互以及基于其构建应用所需的各种工具，让强大的通信能力能够更便捷地集成到您的 Python 代理中。携手新的 A2A 合作伙伴，推动生态系统加速成长A2A 在行业中的采用速度正在显著加快。我们已经看到多个平台推出了增强功能，用于构建、部署和保护 A2A 代理，这将有助于为未来复杂的多代理系统奠定坚实的基础设施基础。同时，各公司也在为现有代理添加 A2A 支持，使其能够在这个快速增长的生态系统中与其他代理无缝通信。最近的更新包括：Auth0 正在推出开源示例代理，展示如何使用 A2A 和 Auth0 的 Auth for GenAI 服务，对代理进行远程身份验证，以实现安全的多代理通信。Box AI 代理通过提取关键信息（如日期和合同条款），将扫描件、图像等非结构化内容转化为可操作的数据。通过采用 A2A 协议，Box AI 代理能够与外部代理安全协作，在内容存储的位置直接完成复杂的多系统流程。Microsoft 已宣布在 Azure AI Foundry 中支持该协议以用于构建 A2A 代理，并实现了在 Microsoft Copilot Studio 中调用任意 A2A 代理的能力。此外，Microsoft 还展示了通过使用 Microsoft Entra Agent ID 和 Microsoft Graph 调用多个 A2A 代理，以此提升办公效率的应用案例。SAP 正在为其 AI 助手 Joule 添加对 A2A 协议的支持，这将使 Joule 能够在 SAP 生态系统内编排代理，并在 Joule 界面中调用基于 Google ADK 构建的 A2A 代理，让用户无需切换上下文即可访问多个系统中的代理，完成更多任务。Zoom 已宣布支持 A2A 协议及 Agentspace 集成，推动其开放平台上的多代理协作迈向新阶段。携手共建未来我们对这些更新感到无比振奋，并坚信它们有助于您构建更加复杂、可靠且具有影响力的智能代理解决方案。此次在 ADK、代理引擎和 A2A 协议上的重大升级，旨在为您提供一个全面而灵活的平台，将您那些以代理为核心的宏伟计划真正变为现实。我们期待见证您接下来的精彩创作。🚀 即刻行动，开始构建Python ADK (v1.0.0)Java ADK (v0.1.0)A2A Python SDK探索代理引擎🗣️ 参与讨论，获得支持ADK GitHub 讨论区A2A GitHub 讨论区Reddit 上的 ADK💡 深入学习，激发灵感A2A 协议规范 (v0.2)本公告于 2025 年 Google I/O 大会在 io.google 公布。