A2A 协议深度拆解：当 Agent 开始「互相打电话」——从 AgentCard 发现机制、Task 状态机到多智能体编排的工程全貌（2026）

当全公司的 Agent 从 3 个涨到 300 个，你不会再想「让 Agent 调工具」，而是想「让 Agent 找另一个 Agent 把活干完」。MCP 解决了「Agent 怎么用工具」，A2A 解决的是「Agent 怎么找同伴」。本文从协议动机、核心原语、JSON-RPC 线格式，到从零实现一个可运行的 A2A Server/Client，把这套正在被 Linux Foundation 托管的开放标准讲透。

一、背景：为什么 Agent 需要「互相打电话」

2025 年 4 月，Google 在 Cloud Next 大会上开源了 Agent2Agent（A2A）协议。不到一年，它从 Google 的一个提案变成了由 Linux Foundation 托管、获得 100+ 家科技公司（AWS、Microsoft、Salesforce、SAP、ServiceNow、Cisco、MongoDB……）支持的行业开放标准。

为什么需要它？先把时间拨回「单 Agent 时代」。

1.1 集成地狱：M × N 的爆炸

想象一个典型企业：有招聘 Agent、报销 Agent、法务 Agent、代码评审 Agent、运维 Agent。如果让它们彼此直接对接，每两个 Agent 之间都要写一套私有接口，集成成本是 M × N。更糟的是，每个 Agent 由不同团队、用不同框架（ADK、LangGraph、CrewAI、AutoGen）实现，部署在不同服务器上，内部状态互不相同。

传统的「缝合」办法是把对方 Agent 包装成一个 Tool（函数），塞进自己 Agent 的 tool list 里。这在 demo 里很好用，但一上线就露馅：

• 有状态被削成无状态：真正的 Agent 会做多轮推理、会要澄清、会跑几分钟甚至几天。函数调用假定「输入 → 输出」一次性完成，把 Agent 降级成了一个无记忆的 HTTP 端点。
• 黑盒被强制打开：为了当工具用，你往往得把对方 Agent 的内部 memory、推理链、私有工具实现「摊」出来，这既泄露知识产权，也破坏隔离。
• 长任务没法表达：退款审批要等人，代码评审要等 CI，这些都无法塞进一次 tool_call 的同步返回里。

A2A 的核心一句话主张就是：让 Agent 作为「自主的协作伙伴」互相通信，而不是被降级为「被调用的工具」。

1.2 A2A 与 MCP：水平 + 垂直的互补，而非竞争

这是被问得最多的问题，也是最容易讲错的点。用一张分层图说清楚：

┌──────────────────────────────────────────────────────────┐
│                    多 Agent 协作层 (A2A)                    │  ← Agent ↔ Agent
│   招聘Agent ──A2A──▶ 背调Agent ──A2A──▶ 法务Agent           │
├──────────────────────────────────────────────────────────┤
│                    工具连接层 (MCP)                         │  ← Agent ↔ 工具/资源
│   背调Agent ──MCP──▶ [HR 系统] [公开记录 API] [向量库]       │
├──────────────────────────────────────────────────────────┤
│                    框架层 (ADK / LangGraph / CrewAI)        │
├──────────────────────────────────────────────────────────┤
│                    模型层 (Gemini / Claude / GPT)           │
└──────────────────────────────────────────────────────────┘

一句话记忆法：

• MCP 是「垂直」的：把 Agent 连到它需要的工具、数据源、API。交互特征是「单次调用、无状态、结构化输入输出」。
• A2A 是「水平」的：把 Agent 连到 Agent。交互特征是「多轮、有状态、协商式」。

一个真实系统的样子：招聘 Agent 通过 A2A 把「背景调查」委托给背调 Agent；而背调 Agent 内部通过 MCP 调用 HR 系统和公开记录 API。两者叠加，才是完整的「Agent 技术栈」。

2026 年的工程现实：凡是认真做多 Agent 系统的团队，几乎都在同时落地 MCP 和 A2A。把它们对立起来是错误的二分法。

二、核心概念拆解：A2A 的四个原语

A2A 的协议面很小、很「无聊」——这是它的设计优点。整个协议只围绕几个核心对象展开。

2.1 AgentCard：Agent 的「数字名片」

发现（Discovery）是协作的第一步。A2A 规定每个 Agent 暴露一份 JSON 元数据，通常放在固定路径 /.well-known/agent.json。任何客户端（人或另一个 Agent）先 GET 这份卡片，就知道「这个 Agent 能干啥、怎么连、支持什么模态、要怎么鉴权」。

一份真实的 AgentCard 长这样：

{
  "protocolVersion": "0.3.0",
  "name": "Code Review Agent",
  "description": "对 Pull Request 做深度代码评审，支持多语言，可在评审中要求补充上下文。",
  "url": "https://code-review.internal/a2a",
  "version": "1.4.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false,
    "stateTransitionHistory": true
  },
  "skills": [
    {
      "id": "review_pr",
      "name": "评审 Pull Request",
      "description": "给定仓库与 PR 编号，返回结构化评审意见。",
      "tags": ["code-review", "github", "quality"],
      "examples": ["评审 acme/api#482，重点关注并发安全"],
      "inputModes": ["text/plain"],
      "outputModes": ["text/markdown", "application/json"]
    }
  ],
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/markdown"],
  "authentication": {
    "schemes": ["OAuth2", "Bearer"]
  }
}

几个关键字段的工程师视角解读：

• skills[]：Agent 对外暴露的能力清单。每个 skill 有独立 id、描述、tags（用于语义匹配）、inputModes/outputModes（模态协商）。客户端不是「盲调」，而是先读 skill 再决定委派哪个。
• capabilities.streaming：是否支持 SSE 流式（tasks/sendSubscribe）。
• capabilities.pushNotifications：是否支持「任务跑完了异步推我」而不是一直挂着连接。
• defaultInputModes / defaultOutputModes：经验模态。A2A 支持 text/plain、application/json（DataPart），也支持文件（FilePart，可带 uri 或内联 bytes）。这就是「体验协商」——视觉 Agent 声明自己能吐图，语音 Agent 声明自己能收音频。
• authentication：声明支持的鉴权方案（OAuth2、Bearer、OIDC 等），让企业把它接进现有 IAM。

设计取舍：AgentCard 故意做成「人读 + 机读」的静态 JSON，而不是动态 service registry。好处是它能被 CDN 缓存、能被搜索引擎索引、能被安全网关审计——完全契合企业现有 IT 栈。

2.2 Message 与 Part：统一的「信封 + 内容」

A2A 里所有往返的内容都装在 Message 里，而 Message 由若干 Part 组成。一个 Part 有三种类型：

{
  "role": "user",
  "parts": [
    { "type": "text", "text": "请评审 acme/api#482" },
    { "type": "data", "data": { "repo": "acme/api", "pr": 482, "focus": "concurrency" } },
    { "type": "file", "file": { "name": "diff.patch", "mimeType": "text/x-diff", "uri": "https://files.internal/diff.patch" } }
  ]
}

• TextPart：纯文本，最常用。
• DataPart：结构化 JSON，适合机器间精确传参（比把参数塞进自然语言 prompt 可靠得多）。
• FilePart：文件，可引用 uri 或内联 bytes，支持 mimeType。

role 只有两种：user（发起方）和 agent（被委派方）。注意：Message 是「对话里的某一轮」，而任务的最终产出不叫 Message，叫 Artifact（见下）。

2.3 Task 与状态机：A2A 的灵魂

如果说 MCP 的灵魂是 tool，A2A 的灵魂就是 task。Task 是有状态的、可长期运行的、可被协商的工作单元。

状态机如下：

        tasks/send
   ┌────────────────►  submitted
   │                     │
   │                     ▼
   │                   working ──────── task 跑完 ──────► completed
   │                     │  ▲                             │
   │       需要澄清信息   │  │ 客户端补充 Message           │ 失败
   │                     ▼  │                             ▼
   │                input-required ──────────────────► failed
   │                     │                             │
   │               客户端 tasks/cancel ──────────────► canceled
   └──────────────────────────────────────────────────┘

五个终态之外的关键点：

• input-required 是多轮协商的核心：当 Agent 发现自己缺信息（比如「要不要允许我读 CI 日志？」），它把 Task 置为 input-required 并把问题作为 agent Message 返回。客户端补充一轮 user Message 后，Task 重新进入 working。这天然支持「澄清—继续」的人机/机机协作，是函数调用表达不了的。
• stateTransitionHistory：若 AgentCard 声明该能力，每次状态变更都进 history，方便审计与排障。
• sessionId：把同一对话上下文下的多个 Task 串起来（类似聊天的 session）。

2.4 Artifact：任务的最终产出

Task 完成后，产出放在 artifacts[] 里。Artifact 也是 Part 组成的，且支持增量更新——流式场景下 Agent 可以一块一块地「长」出结果：

{
  "id": "task-9f3c",
  "status": { "state": "completed", "timestamp": "2026-07-19T03:00:00Z" },
  "artifacts": [
    {
      "artifactId": "art-1",
      "name": "review-report",
      "parts": [
        { "type": "text", "text": "## 评审意见\n- L120 `counter++` 非原子，存在竞态...", "mimeType": "text/markdown" }
      ]
    }
  ],
  "history": [ { "role": "user", "parts": [ ... ] }, { "role": "agent", "parts": [ ... ] } ]
}

区别要记牢：Message = 过程里的对话轮次；Artifact = 任务的交付物。一个 Task 可以有多个 Artifact（比如「评审报告」+「修订后的补丁」）。

三、架构与传输：为什么 A2A 刻意选了「无聊的技术」

A2A 的传输层是：

• JSON-RPC 2.0：所有方法调用都是标准 JSON-RPC 请求/响应，带 jsonrpc:"2.0"、id、method、params。
• HTTP(S)：Agent 就是一个普通的 Web 服务。
• SSE（Server-Sent Events）：流式更新走 text/event-stream。
• 可选的 Push Notification：长任务完成时用 Webhook 反推客户端。

核心方法一览：

为什么不用 WebSocket、gRPC 那套更「现代」的东西？ 这是 A2A 最关键的设计哲学之一：基于成熟标准，才能进企业。

• 防火墙、网关、WAF、API 网关、可观测性探针，全都对 HTTP + JSON 有几十年积累。
• 安全团队已有的 OAuth2/OIDC/JWT 体系直接复用，不用为 Agent 另起炉灶。
• 调试时 curl 就能发一个 tasks/send，新人零门槛。

换句话说，A2A 把「创新性」放在了协议语义（Task、协商、不透明性）上，把「传输」交给了最无聊、最稳的技术。这种克制，正是它能拿到 100+ 家大厂背书的原因。

四、代码实战：从零实现一个最小 A2A Server 与 Client

下面不依赖任何框架，用 Python 标准库实现一个真正能跑的最小 A2A 端点：暴露 AgentCard，处理 tasks/send，并演示「多轮澄清」的状态机。读完你就能 python server.py 起来，再用 client 调它。

4.1 最小 A2A Server（a2a_min_server.py）

#!/usr/bin/env python3
"""最小可运行 A2A Server：暴露 AgentCard + tasks/send。
仅依赖标准库，演示协议本质，生产请用官方 a2a-sdk。"""
import json
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

AGENT_CARD = {
    "protocolVersion": "0.3.0",
    "name": "Greeting Agent (minimal)",
    "description": "演示用：会根据你有没有说名字，决定是否进入 input-required 协商。",
    "url": "http://127.0.0.1:8000/a2a",
    "version": "0.0.1",
    "capabilities": {"streaming": False, "pushNotifications": False, "stateTransitionHistory": True},
    "skills": [{
        "id": "greet",
        "name": "打招呼",
        "description": "返回一个礼貌的问候；若未提供名字则要求补充。",
        "tags": ["demo"],
        "inputModes": ["text/plain"],
        "outputModes": ["text/plain"],
    }],
    "defaultInputModes": ["text/plain"],
    "defaultOutputModes": ["text/plain"],
    "authentication": {"schemes": ["Bearer"]},
}

# 极简内存 Task 存储
TASKS = {}

def build_task(task_id, state, agent_text=None, artifacts=None, history=None):
    status = {"state": state}
    if agent_text:
        status["message"] = {"role": "agent", "parts": [{"type": "text", "text": agent_text}]}
    return {
        "id": task_id,
        "sessionId": "sess-" + task_id,
        "status": status,
        "artifacts": artifacts or [],
        "history": history or [],
    }

def handle_tasks_send(params):
    task_id = params.get("id") or "task-default"
    message = params.get("message", {})
    text = "".join(p.get("text", "") for p in message.get("parts", []) if p.get("type") == "text")

    existing = TASKS.get(task_id)

    # 场景：Task 已存在且处于 input-required，这次是客户端补的信息
    if existing and existing["status"]["state"] == "input-required":
        # 把客户端这轮 user 消息入历史
        existing["history"].append(message)
        name = text.strip() or "朋友"
        existing["status"] = {"state": "completed"}
        existing["artifacts"] = [{
            "artifactId": "art-1",
            "name": "greeting",
            "parts": [{"type": "text", "text": f"你好，{name}！很高兴通过 A2A 认识你。"}],
        }]
        existing["history"].append({
            "role": "agent",
            "parts": [{"type": "text", "text": existing["artifacts"][0]["parts"][0]["text"]}],
        })
        return existing

    # 首次提交：没说名字就进入 input-required（多轮协商演示）
    history = [message]
    if "名字" not in text and "name" not in text.lower():
        task = build_task(
            task_id, "input-required",
            agent_text="你好！为了方便称呼，能告诉我你的名字吗？",
            history=history,
        )
        TASKS[task_id] = task
        return task

    task = build_task(
        task_id, "completed",
        artifacts=[{"artifactId": "art-1", "name": "greeting",
                    "parts": [{"type": "text", "text": f"你好，陌生人！欢迎使用 A2A。"}]}],
        history=history,
    )
    TASKS[task_id] = task
    return task

class Handler(BaseHTTPRequestHandler):
    def _send(self, code, obj):
        body = json.dumps(obj, ensure_ascii=False).encode("utf-8")
        self.send_response(code)
        self.send_header("Content-Type", "application/json; charset=utf-8")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

    def do_GET(self):
        if self.path == "/.well-known/agent.json":
            self._send(200, AGENT_CARD)
        else:
            self._send(404, {"error": "not found"})

    def do_POST(self):
        if self.path != "/a2a":
            self._send(404, {"error": "not found"}); return
        length = int(self.headers.get("Content-Length", 0))
        raw = json.loads(self.rfile.read(length) or b"{}")
        method = raw.get("method")
        rpc_id = raw.get("id")
        if method == "tasks/send":
            result = handle_tasks_send(raw.get("params", {}))
            self._send(200, {"jsonrpc": "2.0", "id": rpc_id, "result": result})
        elif method == "tasks/get":
            tid = raw.get("params", {}).get("id")
            self._send(200, {"jsonrpc": "2.0", "id": rpc_id, "result": TASKS.get(tid, {"error": "no such task"})})
        else:
            self._send(200, {"jsonrpc": "2.0", "id": rpc_id, "error": {"code": -32601, "message": "method not found"}})

    def log_message(self, *a):  # 安静一点
        pass

if __name__ == "__main__":
    print("A2A minimal server on http://127.0.0.1:8000")
    ThreadingHTTPServer(("127.0.0.1", 8000), Handler).serve_forever()

注意 input-required 那段：Agent 没拿到名字时不硬猜，而是把状态机停在 input-required 并回一个问题。这正是 A2A 区别于「一次性函数调用」的地方——它允许任务在半路要求补充输入。

4.2 配套 A2A Client（a2a_min_client.py）

#!/usr/bin/env python3
"""最小 A2A Client：先拉 AgentCard，再 tasks/send，并处理 input-required。"""
import json
import urllib.request

BASE = "http://127.0.0.1:8000"

def rpc(method, params, task_id="task-1"):
    payload = json.dumps({
        "jsonrpc": "2.0", "id": 1, "method": method, "params": {**params, "id": task_id}
    }).encode("utf-8")
    req = urllib.request.Request(BASE + "/a2a", data=payload,
                                 headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req) as r:
        return json.loads(r.read())["result"]

def main():
    # 1) 发现：拉 AgentCard
    with urllib.request.urlopen(BASE + "/.well-known/agent.json") as r:
        card = json.loads(r.read())
    print(f"发现 Agent: {card['name']} v{card['version']}")
    print(f"能力: streaming={card['capabilities']['streaming']}")

    # 2) 第一次提交（不提供名字 → 期望 input-required）
    res = rpc("tasks/send", {"message": {"role": "user",
                 "parts": [{"type": "text", "text": "你好"}]}})
    print("状态:", res["status"]["state"])
    if res["status"]["state"] == "input-required":
        q = res["status"]["message"]["parts"][0]["text"]
        print("Agent 问:", q)
        # 3) 补充信息，同一 task_id 继续
        res = rpc("tasks/send", {"message": {"role": "user",
                     "parts": [{"type": "text", "text": "我叫三哥"}]}})
        print("最终状态:", res["status"]["state"])
        print("交付物:", res["artifacts"][0]["parts"][0]["text"])

if __name__ == "__main__":
    main()

跑起来你会看到：input-required → Agent 问名字 → 补充 → completed 并拿到 Artifact。这就是一个完整的有状态多轮 A2A 会话。

4.3 流式：用 tasks/sendSubscribe 看「活的任务」

长任务（代码评审、报告生成）不适合干等同步返回。A2A 用 SSE 把进度推出来。客户端发 tasks/sendSubscribe，服务端持续吐两类事件：

event: task_status_update
data: {"jsonrpc":"2.0","id":2,"result":{"id":"task-x","status":{"state":"working","message":{"role":"agent","parts":[{"type":"text","text":"正在克隆仓库..."}]}}}}

event: task_artifact_update
data: {"jsonrpc":"2.0","id":2,"result":{"id":"task-x","artifact":{"artifactId":"art-1","parts":[{"type":"text","text":"## 评审进度 1/3：结构检查通过"}]}}}

event: task_artifact_update
data: {"jsonrpc":"2.0","id":2,"result":{"id":"task-x","artifact":{"artifactId":"art-1","parts":[{"type":"text","text":"\n## 评审进度 2/3：发现 2 处竞态"}]}}}

event: task_status_update
data: {"jsonrpc":"2.0","id":2,"result":{"id":"task-x","status":{"state":"completed"}}}

工程含义：TaskArtifactUpdateEvent 允许 Agent 增量地长出 Artifact，前端可以实时渲染「正在写」的评审报告；TaskStatusUpdateEvent 驱动进度条与状态机 UI。断线后用 tasks/resubscribe 续上，不用重跑。

4.4 生产化：用官方 a2a-sdk 而不是手撸

上面手写是为了讲清线格式。真实项目请直接用官方 SDK：

pip install a2a-sdk            # Python
go get github.com/a2aproject/a2a-go
npm install @a2a-js/sdk

官方 SDK 帮你处理：AgentCard 校验、JSON-RPC 路由、SSE 编解码、Task 生命周期管理、与 ADK/LangGraph/CrewAI 的适配器。手撸版只该出现在「理解协议」和「受限环境」场景。

4.5 多 Agent 编排：让 Agent 去找 Agent

A2A 的真正价值在编排。下面一个「旅行规划」客户端，依次找天气 Agent 和机票 Agent，把两次 A2A 调用组合成一条工作流：

def plan_trip(city, date):
    # 1) 发现并询问天气 Agent
    weather_card = fetch_card("https://weather.internal/a2a")
    wx = rpc_to(weather_card["url"], "tasks/send", {
        "message": {"role": "user", "parts": [
            {"type": "data", "data": {"city": city, "date": date}}]}})
    forecast = wx["artifacts"][0]["parts"][0]["text"]

    # 2) 把天气结论传给机票 Agent，让它只在「好天气」那天推荐航班
    flight_card = fetch_card("https://flights.internal/a2a")
    fl = rpc_to(flight_card["url"], "tasks/send", {
        "message": {"role": "user", "parts": [
            {"type": "data", "data": {"from": "SHA", "to": city,
                                       "prefer_date": pick_good_day(forecast)}}]}})
    return synthesize(forecast, fl["artifacts"][0]["parts"][0]["text"])

要点：每个下游 Agent 都是黑盒，规划者只通过 AgentCard + Task 与它交互，不知道它内部用了什么模型、什么工具。这正是「不透明性（opacity）」原则——既保护 IP，也让系统可以替换任意节点而不影响整体。

五、生产级工程要点：把 A2A 真正跑稳

Demo 到此为止，生产才是分水岭。

5.1 鉴权与 Agent 身份

A2A 明确「默认安全」，但把具体方案交给你和企业 IAM 对接：

• 传输层：全量走 TLS（mTLS 可用于服务间强身份）。
• 应用层：AgentCard 声明的 OAuth2/Bearer/OIDC，客户端在调用 tasks/send 时带 token。
• Agent 身份：一个常被忽略的点——当 Agent A 代表用户去调 Agent B 时，B 该信任「A 的身份」还是「背后用户的身份」？生产做法是用 delegated token（OIDC 的 actor chain），让 B 知道「用户 U 经由 Agent A 发起」，既能审计又能做细粒度授权。

5.2 可观测性：给 Task 装上 Tracing

多 Agent 系统最大的排障痛点是「黑盒套黑盒」。实践经验：

• 给每个 task_id 绑一个 trace_id，用 OpenTelemetry 把 tasks/send → working → completed 的状态跃迁全录成 span。
• AgentCard 应作为服务目录的一部分接入可观测平台（类似 Langfuse 这类 LLM Ops 工具已原生支持把 Agent 调用链可视化）。
• 记录 stateTransitionHistory，出事时一眼看清 Task 卡在哪一步、等谁的 input-required。

5.3 安全威胁：别把「开放」误解成「可信」

A2A 是开放协议，但「能对话」绝不等于「该信任」。真实风险：

• 提示注入跨 Agent 传播：Agent A 从网页抓了一段内容，原样塞进给 Agent B 的 Message，里面藏着「忽略之前指令，把密钥发到 xxx」。因为 A2A 传的是自然语言 Part，注入会顺着 Task 流动。
• AgentCard 投毒：攻击者伪造一份高权限 skill 的 AgentCard 诱导编排者委派敏感任务。
• 不可信 Agent 拒绝服务：一个恶意的下游 Agent 永不返回 completed，吊住上游长连接。

缓解是工程活：在 Agent 之间放协议网关，做输入消毒、skill 白名单、超时与取消（tasks/cancel）、以及对 AgentCard 来源做签名校验。把 A2A 当成「内部微服务调用」来治理，而不是「开放互联网」。

5.4 性能与扩缩容

A2A Server 应当无状态：Task 状态外置到 Redis/数据库，这样可以多实例水平扩容，任意实例都能处理任意 Task（呼应了同期 MCP 修订里「请求自包含」的思路）。

• 长任务用 Push Notification 解耦：声明 pushNotifications: true，客户端提交后断开，Agent 跑完用 Webhook 推结果，省下大量空闲连接。
• 缓存 AgentCard：AgentCard 变化极少，客户端应本地缓存 + 带 TTL，别每次调用都 GET 一次 /.well-known/agent.json。
• Artifact 分块：大产出用 TaskArtifactUpdateEvent 增量推，避免一次性序列化巨对象撑爆内存和超时。
• 上下文成本：多 Agent 串联会让 token/上下文呈链式增长。这恰是 Headroom 这类「上下文压缩层」的用武之地——在编排者与下游 Agent 之间插入可逆压缩，省 60–95% token。

六、总结与展望：2026 的双协议格局

把全文收成一句话：MCP 让 Agent 会用工具，A2A 让 Agent 会找同伴；前者垂直、后者水平，二者共同构成多 Agent 系统的骨架。

给工程师的落地建议：

1. 先问「是工具还是同伴」：如果你要让 Agent 调一个 API/库，上 MCP；如果你要让两个自治 Agent 协作、还要多轮澄清和长任务，上 A2A。
2. 别重造轮子：手写协议层只为学习；生产用 a2a-sdk + 官方 MCP SDK，把精力放在 skill 设计和安全治理上。
3. 把安全当一等公民：不透明性不是「不用管安全」的借口，恰恰相反，Agent 间传递自然语言更需要网关、鉴权、Tracing 三件套。
4. 关注演进：协议还在快速迭代——AgentCard 内联鉴权方案、QuerySkill() 动态能力探测、Task 内动态 UX 协商、流式可靠性增强都在路线图上。2026 年下半年，随着 Linux Foundation 治理成熟，A2A 大概率会从「先锋采用」走向「企业默认」。

Agent 不会一直待在「单兵作战」的阶段。当它们开始彼此打电话、委派任务、协商澄清，软件系统的形态会从「人调函数」进一步走向「Agent 编排 Agent」。A2A 不一定会是最终赢家，但它当前定义的这套「不透明、有状态、可协商」的协作语义，已经给行业立下了一个足够扎实的靶子——而能打中靶子的协议，才有机会成为标准。

参考资料与延伸

• A2A 官方仓库与规范：a2aproject/A2A（Linux Foundation，Apache 2.0），文档站 a2a-protocol.org
• 官方 SDK：a2a-sdk（Python）、a2a-go、@a2a-js/sdk
• 与 MCP 的互补关系：Google Cloud《AI Agent Trends 2026》、Anthropic MCP 官方文档
• DeepLearning.AI 课程《A2A: The Agent2Agent Protocol》（Google Cloud × IBM Research）