内容来源：https://blog.n8n.io/agent-to-agent-protocol/

内容总结：

谷歌推出A2A协议：为多智能体协作提供统一通信标准

随着人工智能技术的快速发展，构建一个能处理单一任务的AI智能体相对简单，但真正棘手的问题在于如何让多个智能体在不同系统之间协同工作。开发人员往往需要编写大量定制代码才能实现工具间的协作。

2025年4月，谷歌推出了智能体间协议（Agent-to-Agent Protocol，简称A2A协议），这是一套开放标准，旨在为不同AI系统提供统一的协作语言。该协议采用HTTP作为主要传输方式，通过JSON-RPC实现结构化消息传递，并利用服务器发送事件（SSE）支持长时间运行任务的实时更新。

协议核心架构

A2A协议定义了两种角色：客户端智能体（发起请求方）和远端智能体（执行任务方）。这种设计具有高度的灵活性，任何智能体都可以根据工作流程的需要在客户端和远程服务器角色之间切换。

协议包含四个主要构建模块：

智能体名片（Agent Cards）：相当于数字身份标识，描述智能体的能力、可处理任务类型及所需认证信息。在正式系统中，这些名片帮助实现智能体的自动发现。

任务（Tasks）：定义智能体可执行的具体工作单元，包括数据载荷、预期输出和配额限制。清晰的任務描述是确保可靠异步通信的基础。

消息与数据包（Messages and Parts）：承载工具间交换的实际数据，通常以JSON格式传输。一条消息被拆分为多个部分，包含核心指令和上下文元数据。

传输与流式传输（Transport and Streaming）：数据传输的“通道”，支持从简单HTTP到可选消息代理的不同传输方式，并通过SSE实现实时数据推送。

工作流程与安全性

A2A协议遵循标准客户端-服务器模型，包括三个关键步骤：

1. 发现阶段：客户端智能体通过检查智能体名片，寻找具有所需能力的远程智能体。
2. 认证阶段：采用OAuth、mTLS或JWT等企业级安全标准，确保连接安全并验证授权级别。
3. 通信阶段：完成初始握手后，智能体开始交换结构化数据，支持异步通信，客户端可发送指令后等待触发器或回调。

在安全方面，A2A协议采用mTLS加密连接、OIDC身份认证以及JWT和OAuth授权机制，确保只有经过授权的智能体才能访问相关数据。该协议与企业已有的基于角色的访问控制（RBAC）规则兼容。

A2A与MCP的区别

A2A协议与模型上下文协议（MCP）是互补工具。MCP负责将工具和服务连接至单个智能体，而A2A协议则作为中间件，让这些自主智能体能够跨网络协同工作。

实施挑战

尽管A2A协议带来诸多优势，但也面临一些技术挑战：异步工作模式下错误排查更加困难；智能体委派任务需要谨慎管理授权以防止数据泄露；消息缺失关键细节可能导致上下文丢失；高流量智能体通信可能造成系统延迟。

行业分析人士指出，A2A协议标志着AI多智能体协作迈入新阶段。对于企业技术团队而言，采用该协议无需在每次添加新工具时构建定制连接，能够有效避免供应商锁定，并支持框架间的无缝切换。

中文翻译：

构建一个能处理任务的AI智能体并不复杂。真正的挑战在于，当你需要构建多个智能体必须跨不同系统协调任务的工作流时。开发人员最终往往要编写自定义代码，才能让各种工具协同工作。

智能体间协议——也被称为Agent2Agent或A2A协议——通过为不同的智能体系统提供一种通用的协作语言，解决了这个问题。

但它究竟如何工作？让我们从基础开始了解。

什么是智能体间（A2A）协议？

谷歌于2025年4月推出A2A协议，作为AI系统通信的开放标准。它使用HTTP作为主要传输协议，JSON-RPC用于结构化消息传递，并利用服务器推送事件（SSE）在长时间运行的任务期间进行流式更新。这种设计支持异步工作，因此一个智能体可以将任务发送给另一个智能体，并在任务运行时继续执行自身操作。

对于技术负责人而言，谷歌A2A协议消除了每次在技术栈中添加新工具时都需要构建自定义连接的需求。由于它使用标准化的JSON消息格式，你无需担心供应商锁定。它能够完美融入你企业已有的安全和授权模式，因此你可以在不破坏整个架构的情况下更换框架。

在审视A2A协议提供的内容时，理解它所定义的两个角色会有所帮助：

• 客户端智能体：请求帮助的一方
• 远程智能体：执行工作的一方

这种设置非常灵活。根据工作流的不同，任何智能体都可以在客户端和远程服务器之间切换。这使得不同工具能够轻松协作，共同解决复杂问题。

A2A协议架构：核心组件

A2A协议使用四个主要构建模块来保持系统的互操作性。这些组件定义了一个一致的通信模型，该模型运行在HTTP之上，并且也可以集成到使用消息代理（如RabbitMQ或Apache Kafka）的更广泛架构中。不过，上下文的维持取决于具体的实现细节。

智能体卡片

智能体卡片是一种数字身份标识，描述了智能体的能力、它可以处理的任务以及所需的身份验证。在生产系统中，这些卡片有助于服务发现。如果卡片缺失或格式错误，集成就会失败，因为系统无法确认智能体的能力或权限。

任务

任务是智能体可以执行的具体工作单元。每个任务描述了有效载荷、预期输出以及任何配额或限制。客户智能体通过这种方式精确地告知远程智能体它需要什么。

如果这些没有明确界定，工作流可能会触发需要人工干预的错误，因为执行者将不知道要运行哪个业务流程。使用通用的任务语言能确保可靠的异步通信，即使在不同的软件应用程序之间也是如此。

消息与部件

消息携带工具之间交换的实际数据包，通常格式化为JSON消息。一条消息被分解成多个部件，其中可能包含核心指令以及维护上下文所需的元数据。

当消息格式错误时，服务器无法交换信息，因为这会导致数据一致性问题。这种情况下，智能体虽然在技术上进行着“对话”，但彼此并不理解。对于高风险的企业对企业（B2B）或供应链系统，这可能导致批处理作业中途停止。

传输与流式传输

这一层是数据传输的“道路”。它支持不同的信息移动方式，从简单的HTTP到可选的（additional）消息代理。对于实时更新，它使用SSE来保持连接开放，以便数据持续流动，而无需每次都发起新的请求。

如果传输层设置不当，你的系统将会变慢或断开连接。一个可靠的协议能确保无缝的智能体通信，即使工具正忙于处理长时间运行的任务。这有助于保持微服务的高效性，并随着业务和工作流的增长，便于轻松扩展架构。

A2A协议如何工作

A2A协议遵循一个结构化的序列来让工具协同工作。它的工作方式类似于标准的客户端-服务器模型，其中一个智能体发出请求，另一个智能体执行请求。

服务发现

在两个智能体能够协作之前，它们必须先找到彼此。在发现阶段，客户端智能体会寻找一个具有合适能力来完成工作的远程智能体。它通过检查智能体卡片来完成这项工作，智能体卡片列出了特定工具能够处理的任务。

如果发现失败，工作流就无法进行。一个可靠的发现阶段能确保你的自动化系统无需人工路由就能为任务找到最佳工具。

身份验证

一旦智能体找到彼此，它们需要证明各自的身份。身份验证使用标准化的安全措施，如OAuth、mTLS或JWT，以确保连接安全。协议会检查授权级别，以确定该智能体是否被允许委派任务或访问特定数据。

在生产环境中，这是防止未授权访问的关键环节。如果身份验证缺失或错误，远程智能体将拒绝该请求。使用这些企业级模式能确保你的智能体通信保持安全和合规。

通信

在完成初始握手之后，实际工作便开始了。智能体现在开始交换结构化数据以完成任务。这种异步通信允许客户端发送指令，然后等待触发器或回调，待输出准备就绪后接收。

通过使用A2A协议，工具可以交互并共享上下文，直到它们达成目标。如果出现错误，协议会提供清晰的报告，使系统能够在不停止整个工作流的情况下恢复运行。

A2A与MCP：多智能体架构的协议选择

A2A协议和模型上下文协议（MCP）是互补的工具。MCP是一种将工具和服务连接到单个智能体的协议。另一方面，A2A协议充当中间件，让那些自主智能体能够跨不同网络协同工作。

MCP服务器处理客户端与其资源之间的连接，而A2A则处理智能体本身的互操作性。下表展示了MCP和A2A的不同之处。

A2A安全与身份验证

A2A协议专为需要确保数据安全的大型企业而设计。它使用高级别安全措施，如用于加密连接的mTLS和用于验证登录用户身份的OIDC身份验证。它不依赖简单的API密钥，而是使用JWT和OAuth来确保只有正确的智能体才能访问。

这一点在生产环境中部署时至关重要，因为它遵循了你团队已经使用的相同基于角色的访问控制（RBAC）规则。AI系统随后可以利用这些安全标准来委派任务，而不会为你的业务带来新的安全漏洞。

A2A实施挑战

转向A2A协议使系统更强大，但也带来了新的技术障碍：

• 复杂的故障排查：当智能体异步工作时，查找错误根源远比在简单设置中困难得多。
• 安全风险：赋予智能体委派任务的权力意味着必须谨慎管理授权，以防止数据泄露。
• 上下文丢失：如果消息缺少关键细节，远程智能体可能无法理解目标，从而导致工作流中断。
• 网络延迟：如果消息代理未针对速度进行配置，高流量的智能体通信可能会拖慢系统。

这些挑战需要一套扎实的可观测性和微调方案，以确保生产环境的平稳运行。

用A2A构建AI的未来

转向A2A协议意味着在利用更强安全性（additional）的同时，使你的系统更加独立。团队必须专注于清晰的发现和授权机制，以确保工作流顺畅运行。

n8n提供了编排层，使分布式系统保持可管理。其智能体功能基于LangChain，为你提供一种结构化的方式来将子工作流暴露为可调用的工具，并将任务路由到不同的模型或外部服务。

n8n集成了如MCP和向量数据库等框架，并且可以作为基于不同技术栈构建的智能体的协调中心。对于今天正在尝试A2A的团队，社区已经发布了一个A2A节点，它将协议级别的通信引入了n8n工作流。

英文来源：

Building one AI agent to handle a task is simple. The real headache begins when you need to build workflows where multiple agents must coordinate tasks across different systems. Developers often end up writing custom code just to make tools collaborate.
The agent-to-agent protocol — also called the Agent2Agent or A2A protocol — solves this problem by giving different agentic systems a common language for collaboration.
But how does it work? Let’s start with the basics.
What is agent-to-agent (A2A) protocol?
Google introduced the A2A protocol in April 2025 as an open standard for AI systems to communicate. It uses HTTP as the primary transport, JSON-RPC for structured messaging, and server-sent events (SSE) for streaming updates during long-running tasks. This design supports asynchronous work, so one agent can send a task to another and continue operating while the work runs.
For technical leads, the Google A2A protocol removes the need to build a custom connection every time you add a new tool to your stack. Because it uses a standardized JSON message format, you don’t have to worry about vendor lock-in. It fits right into the security and authorization patterns your enterprise already uses so you can swap frameworks without breaking the whole architecture.
When looking at what the A2A protocol provides, it helps to understand the two roles it defines:

• Client agent: The one asking for help
• Remote agent: The one doing the work
  This setup is flexible. Depending on the workflow, any agent can switch between a client and a remote server. This makes it easy for different tools to collaborate and solve complex problems together.
  A2A protocol architecture: Core components
  The A2A protocol uses four main building blocks to keep systems interoperable. These components define a consistent communication model that operates over HTTP and can also integrate into broader architectures that use message brokers like RabbitMQ or Apache Kafka. However, maintaining context depends on implementation details.
  Agent cards
  An agent card is a digital ID that describes the agent’s capabilities, what tasks it can handle, and the authentication it needs. In a production system, these cards help with discovery. If a card is missing or formatted incorrectly, the integration fails because the system can’t confirm the agent’s capabilities or permissions.
  Tasks
  Tasks are the specific units of work that agents can perform. Each task describes the payload, the expected output, and any quotas or limits. This is how a client agent tells a remote agent exactly what it needs.
  If these aren’t clearly defined, the workflow can trigger an error requiring manual intervention because the executor won’t know which business process to run. Using a common language for tasks ensures reliable asynchronous communication, even across different software applications.
  Messages and parts
  Messages carry the actual data packets exchanged between tools, usually formatted as JSON messages. A single message is broken down into parts, which might include the core instructions and the metadata needed for context.
  The server can’t exchange information when a message is malformed because it leads to data consistency issues. In this case, the agents are technically “talking” but don’t understand each other. For high-stakes B2B or supply chain systems, this could stop a batch processing job in its tracks.
  Transport and streaming
  This layer is the “road” the data travels on. It supports different ways of moving information from simple HTTP to optional message brokers. For real-time updates, it uses SSE to keep the connection open for data to flow without starting a new request each time.
  If the transport layer isn’t set up right, your system will be slow or drop connections. A solid protocol ensures seamless agent communication, even when tools are busy with long running tasks. This keeps microservices fast and facilitates easy architecture scaling as your business and workflows grow.
  How the A2A protocol works
  The A2A protocol follows a structured sequence to make tools collaborate. It works much like a standard client-server model, where one agent makes a request and another fulfills it.
  Discovery
  Before two agents can collaborate, they have to find each other. In discovery, the client agent looks for a remote agent that has the right capabilities for the job. It does this by checking agent cards, which list the tasks a specific tool can handle.
  If discovery fails, the workflow can’t progress. A solid discovery phase ensures your automation finds the best tool for the job without manual routing.
  Authentication
  Once the agents find each other, they need to prove who they are. Authentication uses standardized security like OAuth, mTLS, or JWT to make sure the connection is secure. The protocol checks authorization levels to see if the agent is allowed to delegate tasks or access specific data.
  In a production environment, this is where you prevent unauthorized access. If the authentication is missing or wrong, the remote agent will reject the request. Using these enterprise-grade patterns ensures your agent communications stay secure and compliant.
  Communication
  The actual work begins after finishing this initial handshake. The agents now start to exchange structured data to complete the task. This asynchronous communication lets the client send instructions and then wait for a trigger or a callback once the output is ready.
  By using the A2A protocol, the tools can interact and share context until they complete their goals. If there’s an error, the protocol provides clear reporting so the system can recover without halting the entire workflow.
  A2A vs. MCP: Protocol selection for multi-agent architectures
  The A2A protocol and model context protocol (MCP) are complementary tools. MCP is a protocol that connects tools and services to a single agent. On the other hand, the A2A protocol acts as the middleware that lets those autonomous agents work together across different networks.
  While the MCP server handles the connection between a client and its resources, A2A handles the interoperability between the agents themselves. The table below shows how MCP and A2A differ.
  A2A security and authentication
  The A2A protocol is built for large corporations that need to keep their data safe. It uses high-level security like mTLS to encrypt connections and OIDC authentication to check who’s logging in. Instead of using simple API keys, it relies on JWT and OAuth to make sure only the right agents have access.
  This is important when deployed in production environments because it follows the same role-based access control (RBAC) rules your team already uses. AI systems can then use these security standards to delegate tasks without creating new security gaps for your business.
  A2A implementation challenges
  Moving to the A2A protocol makes systems more powerful, but it also adds new technical hurdles:
• Complex troubleshooting: Finding the source of an error is much harder when agents work asynchronously rather than in a simple setup.
• Security risks: Giving an agent the power to delegate tasks means you must be mindful about authorization to prevent data leaks.
• Context loss: If a message is missing critical details, the remote agent might not understand the goal, which can lead to a broken workflow.
• Network lag: High-traffic agent communication can slow down systems if message brokers aren’t configured for speed.
  These challenges require a solid plan for observability and fine-tuning to keep production environments running smoothly.
  Build the future of AI with A2A
  Moving to the A2A protocol means making your system more independent while using stronger security. Teams must focus on clear discovery and authorization to ensure workflows run smoothly.
  n8n provides the orchestration layer that keeps distributed systems manageable. Its agent features run on LangChain, giving you a structured way to expose sub-workflows as callable tools and to route tasks through different models or external services.
  n8n integrates with frameworks like MCP and vector databases and can serve as the coordination hub for agents built on different stacks. And for teams experimenting with A2A today, the community has published an A2A node that brings protocol-level communication into n8n workflows.