昨天我們談到了推播通知如何解決「一直問有沒有更新」的焦慮感。但好像漏提了一個更基本的問題：兩個從未謀面的 AI Agent，究竟是如何從陌生人變成可以託付重要任務的合作夥伴？

Agent Card 的神秘邂逅

還記得第 11 天我們設計的 Agent Card 嗎？

每個 A2A Agent 都有一個固定的「住址」：/.well-known/agent-card.json。這是 A2A 協議的巧妙設計，就像每棟大樓都有門牌號碼一樣標準化。
當一個 Agent 想要認識另一個 Agent 時，首先會禮貌地敲門：

GET https://data-analyst.example.com/.well-known/agent-card.json

然後收到一份詳細的自我介紹：

{
  "protocolVersion": "0.3.0",
  "name": "資深數據分析師",
  "description": "專精商業智慧分析、預測模型建構、客戶行為洞察",
  "url": "https://data-analyst.example.com/a2a",
  "preferredTransport": "JSONRPC",
  "additionalInterfaces": [
    {
      "url": "https://data-analyst.example.com/grpc",
      "transport": "GRPC"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": false
  },
  "skills": [
    {
      "id": "customer_satisfaction_analysis",
      "name": "客戶滿意度分析",
      "description": "分析客戶回饋數據，生成洞察報告",
      "examples": ["分析本季度NPS分數變化", "找出客戶流失的主要原因"]
    }
  ]
}

這張數位名片告訴我們四件關鍵的事：

• 我是誰：名稱和專業領域
• 我會什麼：具體的技能和範例
• 怎麼找我：連接端點和通訊偏好
• 我的特殊能力：支援串流、推播等進階功能

拿到名片後，下個問題是：我們要用什麼方式溝通？

今天，我們就來聊三種握手風格：JSON‑RPC、gRPC、HTTP+JSON（REST 風格），各自什麼時候合適、怎麼從 AgentCard 決定。

為什麼要支持多種傳輸方式？

在理想狀態下，每個 Agent 只用一種最強模式就好。但現實可能沒有想像中美好：

• 有些環境（像瀏覽器、行動端）可能對 gRPC 支援不佳
• 有些系統已有 HTTP / REST 基礎設施，希望與之整合
• 有些場景要求極低延遲或高吞吐，用二進制／streaming 傳輸更有優勢
• 有些 client／agent 平台天生只支援 JSON-RPC

所以 A2A 協議設計上就允許 同一個 Agent 支援多種 transport，並在 AgentCard 裡宣告哪些方式支援。client 則根據這些宣告做選擇及準備 fallback 機制。

協議也強調不同 transport 之間在功能上要「等價」（functional equivalence）。

JSON‑RPC

這是 A2A 協議的基本方式，也是最普遍支援的一種方式。
請求與回應都包在 JSON-RPC 2.0 格式中，走 HTTP(S) POST。協議規範裡也強制這是「核心」方式。

優點

• 可讀性高，工具、語言支援普遍
• 調試簡單，用 JSON 就能看懂
• 在 HTTP 生態中融入門檻低

限制

• JSON 的序列化／反序列化成本比二進制高
• 若要 streaming，就要靠 SSE 或其他技術來「灌流」
• 在高頻率或大資料情境下可能成瓶頸

JSON‑RPC 主要由四個屬性構成，params 主要包含 message 及 configuration

若你在 JSON-RPC 請求中加了一段推播通知的設定，它可能長這樣：

{
  "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"]
        }
      }
    }
  }
}

gRPC (protobuf + HTTP/2)

gRPC 是現代高效的 RPC 協議，用 Protocol Buffers 做序列化，支援雙向流 (streaming)、metadata 等特性。

優點

• 效能高、延遲低
• 原生支援多種 streaming 模式
• 類型安全、介面定義明確

缺點 / 限制

• 客戶端 / 瀏覽器支援需額外轉層（例如 gRPC-web）
• 需要管理 proto 定義與 code generation
• 在某些中間層 (proxy / gateway) 中可能被阻擋或無法直接轉發

HTTP + JSON

這是最熟悉的傳統 API 風格。你可以把某些 RPC 方法封裝成 REST endpoint，例如 POST /v1/message:send、GET /v1/tasks/{id}。若要支援 streaming，也只能靠 SSE。

優點

• 與現有 HTTP 中介件、API Gateway、反向代理 (reverse proxy) 整合度高
• 調試與部署方便
• 對前端、瀏覽器 / 行動端支援友善

缺點

• 若要 streaming，只能靠 SSE 或類似方式，無法像 gRPC 那樣原生
• 在極端效能 / 串流場景下可能效能稍遜

無論是哪種握手方式，重點都不是「選哪一個最好」，而是 根據雙方能力、溝通情境、任務需求，選一個雙方都能接受的語言。