還記得那種等快遞的焦慮感嗎？你只能一直守在門口，每當聽到聲音就探頭張望：「是快遞嗎？」結果只是隔壁鄰居回家。

在軟體開發中，這種「一直問有沒有更新」的方式叫做「輪詢 (Polling)」。A2A 協議的推播通知功能，正是要解決這個讓人抓狂的技術問題。

三種互動模式的選擇

A2A 協議支援三種不同的互動模式：

1. Request/Response (輪詢模式)
客戶端定期詢問任務狀態。像每 10 分鐘打電話問一次「快遞到了嗎？」

2. Streaming with SSE
透過開放連線接收即時更新。像安裝門鈴監視器，即時看到快遞員動態。

3. Push Notifications (推播通知)
伺服器主動發送非同步通知。像快遞員到了會主動按門鈴。

推播通知的核心應用

推播通知特別適合「持續數分鐘、數小時甚至數天的超長時間任務」或「無法維持持續連線的客戶端（如行動裝置或無伺服器函式）」。

典型場景： 大型資料分析、影片處理、機器學習訓練、行動裝置應用

運作流程：

1. 伺服器在 Agent Card 設定 capabilities.pushNotifications: true
2. 客戶端提供 PushNotificationConfig（包含 webhook URL、驗證 token）
3. 任務狀態變化時（completed、failed、input-required 等），伺服器主動發送通知
4. 客戶端收到通知後，使用 tasks/get 取得完整任務結果

安全性：推播通知的關鍵挑戰

由於推播通知是伺服器主動發起的對外通訊，安全性至關重要。

伺服器端防護

防範 SSRF 攻擊：不能盲目信任客戶端提供的 webhook URL，惡意客戶端可能指向內部服務進行攻擊。

緩解策略：域名白名單、所有權驗證（發送 validationToken）、網路控制

客戶端防護

身份驗證：webhook 必須驗證通知真的來自合法 A2A 伺服器

• JWT 驗證：檢查簽章和聲明（iss、aud、iat、exp）
• HMAC 簽章：重新計算並比對簽章
• API 金鑰：確保金鑰有效

防重放攻擊：使用時間戳記和唯一識別符防止舊通知重複處理

金鑰輪換：透過 JWKS 機制動態更新加密金鑰

技術革命的意義

從傳統輪詢到推播通知的轉變，代表了根本性的架構思維進化：

輪詢模式：客戶端持續詢問、大量無效請求、延遲與浪費
推播模式：伺服器適時通知、零冗餘通訊、即時回應

掌握推播通知技術，你已經從「被動等待者」進化為「主動管理者」。更重要的是理解了背後的安全考量：SSRF 防護、身份驗證、重放攻擊防範，這些決定了你的 AI 協作系統是玩具還是企業級解決方案。

明天我們將探索 Agent 間的協作，讓不同 Agent 能夠互相了解、信任並開始協作。