a2a-go：A2A 协议 Go 语言实现，让 Agent 之间能够「对话」

想象一下：你在公司里建了一个 AI 客服 Agent，另一个团队建了一个 AI 订单管理 Agent。现在老板说：「让这两个 Agent 直接对话，客服问订单状态，订单系统自动回复。」

听起来很简单？但现实是——每个 Agent 可能来自不同的团队、用不同的语言实现、有不同的接口规范。它们凭什么能「对话」？

a2aproject/a2a-go 就是来解决这个问题的。它是 Agent to Agent（A2A）协议的 Go 语言实现，为所有遵循该协议的 Agent 提供一套标准化的通信「语言」，让不同来源的 Agent 可以无缝互操作，而不需要知道对方的内部实现细节。

图1：A2A 协议在多 Agent 系统中的定位

图片说明：A2A 协议位于 Agent 应用层之下，作为标准通信中间层。无论 Agent 是 Go、Python 还是其他语言实现，只要接入 A2A 协议即可相互通信。

背景：A2A 协议从何而来

A2A 协议由 Google、Salesforce、Atlassian、Notion、MongoDB 等头部科技公司联合推出，目标是定义一套标准的 Agent 发现机制、消息格式、任务生命周期和事件流。在此之前，每个 AI Agent 平台都有自己的私有协议——Anthropic 的 MCP、OpenAI 的插件系统、LangChain 的工具调用——这些协议互不兼容，导致 Agent 生态碎片化。

a2aproject 组织是 A2A 协议的官方维护方，a2a-go 是其 Go 语言版本的参考实现。截至 2026 年 6 月，该项目已获得 410 个 GitHub stars，81 个 forks，在 Go 开源 Agent SDK 领域处于头部位置。

核心架构：三层模块化设计

a2a-go 采用**传输无关（transport-agnostic）**的分层架构，将业务逻辑（AgentExecutor）与传输层完全解耦。整体分为三大层：

第一层：a2a/ —— 核心领域模型

这是整个 SDK 的「地基」，定义了所有 A2A 协议的原生类型：Task（任务）、Message（消息）、Event（事件）以及它们的构造函数。核心文件 a2a/core.go 定义了 A2A v1.0 协议版本常量 a2a.Version。这一层完全独立，不依赖任何传输层实现，可以被 Server 和 Client 两侧共同引用。

第二层：a2asrv/ —— 服务端 SDK

负责构建 A2A 服务器。核心是 a2asrv.Handler（请求处理器）和 a2asrv.AgentExecutor（用户自定义业务逻辑接口）。Handler 接收来自客户端的请求，经过 internal/taskexec/Manager 的并发调度后，调用用户的 AgentExecutor 执行具体业务。

a2asrv/taskstore/ 实现了基于版本号的乐观锁机制，确保多个并发请求（如一个 Agent 在执行任务，另一个 Agent 尝试取消）不会产生数据竞争。具体流程图：

sequenceDiagram
    participant Exec as Execution (Server 1)
    participant Store as TaskStore
    participant Cancel as Cancel (Server 2)
    Exec->>Store: store.Update(submitted→working, prevVersion=V1)
    Cancel->>Store: CreateCanceler → load task
    Store-->>Exec: V2 (乐观锁成功)
    Store-->>Cancel: task V2

第三层：a2aclient/ —— 客户端 SDK

负责构建 A2A 客户端。a2aclient.NewFromCard() 从 AgentCard（Agent 的元数据描述）自动创建客户端实例，隐藏了底层传输细节。Client 支持 gRPC、REST、JSON-RPC 三种传输方式，底层都对接同一个业务逻辑层。

三种传输层：gRPC / REST / JSON-RPC

这是 a2a-go 区别于大多数 Agent 框架的亮点——开发者可以自由选择传输层。

传输方式	适用场景	特点
gRPC	生产环境高性能场景	Protobuf 序列化，支持双向流
REST	通用 HTTP 场景，调试友好	JSON over HTTP，兼容性最好
JSON-RPC 2.0	轻量级集成	简单直观，适合对接现有 JSON-RPC 服务

代码层面，三种传输层都遵循同一套 Handler 抽象：

// 1. 核心 Handler（业务逻辑）
requestHandler := a2asrv.NewHandler(agentExecutor, options...)

// 2. 选择传输层（任选其一）
grpcHandler := a2agrpc.NewHandler(requestHandler)
// 或者 JSON-RPC:
jsonrpcHandler := a2asrv.NewJSONRPCHandler(requestHandler)
// 或者 REST:
restHandler := a2asrv.NewRESTHandler(requestHandler)

// 3. 注册到服务器
server := grpc.NewServer()
grpcHandler.RegisterWith(server)

这种「Handler → Transport」的两段式设计让业务逻辑完全不知道数据是通过什么协议传输的，更换传输方式不需要修改任何业务代码。

并发模型：本地 vs 分布式

a2asrv 支持两种并发管理模式：

本地模式（默认）：使用 localManager，所有任务在单进程内调度，适合轻量级 Agent 服务。

集群模式（Cluster Mode）：通过 a2asrv.WithClusterMode 开启，使用 distributedManager，可跨多个服务实例协调任务分发，适合大规模多 Agent 部署。

可扩展性：Middleware / Auth / 推送通知

a2a-go 提供了丰富的扩展点：

• Middleware：拦截器链，支持日志、限流、监控等横切关注点
• Auth：认证中间件，可接入 JWT、API Key 等认证方案
• Push Notifications：服务端主动推送消息到客户端，无需客户端轮询
• 自定义传输层：可实现 a2asrv.Transport 接口接入私有传输协议
• 自定义 TaskStore：可替换默认的内存存储为 Redis 等持久化方案

CLI 工具：零代码体验 A2A

SDK 自带一个命令行工具 a2a，无需写代码就能体验 Agent 通信：

# 安装
go install github.com/a2aproject/a2a-go/v2/cmd/a2a@latest

# 发现 Agent
a2a discover https://agent.example.com

# 发送消息
a2a send https://agent.example.com "Hello, what can you do?"

# 将本地脚本暴露为 A2A Agent
a2a serve --exec "./my-script.sh" --port 8080

适用场景与局限性

适用场景：

• 企业内部多个 AI Agent 系统需要互联互通
• 多 Agent 协作流程编排（如客服→订单→物流链路）
• 快速将现有脚本/服务封装为可被调用的 Agent
• 需要跨语言/跨平台 Agent 通信（如 Go 后端调用 Python AI 服务）

局限性：

• 协议较新（2025 年中发布 v1.0），生态建设尚在早期，接入方有限
• 纯 SDK 库，没有开箱即用的 Web UI，适合有开发能力的团队
• Go 1.24.4+ 作为硬性依赖，对老项目升级成本较高
• 作为中间件层，A2A 本身不解决 Agent 的「思考能力」问题，这部分仍需依赖底层 LLM

技术规格一览

维度	内容
开发语言	Go 1.24.4+
协议版本	A2A v1.0
核心模块	a2a/（领域）、a2asrv/（服务端）、a2aclient/（客户端）、a2agrpc/（gRPC）
传输协议	gRPC、REST、JSON-RPC 2.0
许可证	Apache 2.0
CI 流程	Nightly 自动测试 + golangci-lint 代码检查
测试覆盖	完整的表驱动单元测试 + e2e 集成测试（TCK 合规测试）

总结

a2a-go 是 A2A 协议的参考级 Go 实现，代表了 AI Agent 互联互通的标准方向。其传输无关的模块化设计、三种传输层支持、以及丰富的扩展机制，使其成为构建企业级多 Agent 系统的理想基础设施。随着 A2A 协议被更多厂商采纳（目前已有 Google、Salesforce、Atlassian 等支持），a2a-go 的战略价值会持续提升。

对于 Go 开发者而言，这是参与 AI Agent 标准化进程的最好入口——只需几行代码，就能让你的服务具备与其他厂商 Agent 对话的能力。