【A2A 系列 #3】Task 狀態機與安全架構：讓多 Agent 協作真正可信賴

本文為 A2A 系列第三篇。建議依序閱讀： → 【A2A 系列 #1】從對話到協作：為何 A2A 是 AI 演進的終局之戰？ → 【A2A 系列 #2】深入剖析 A2A：如何讓 AI Agent 彼此溝通與分工？

---

上一篇我們把 A2A 協議的五個核心元件拆解完畢 —— Agent Card、Task、Message、Part、Artifact —— 並且走過了一次完整的任務協作流程。你現在知道 A2A「是什麼」了。

但「能跑起來」和「能在生產環境被信任」之間，還有一段不小的距離。

這一篇，我們要繼續深挖兩個關鍵主題：

1. Task 狀態機（FSM）：是什麼讓任務「可追蹤、可恢復、可被有限狀態機管理」？
2. A2A 安全架構：四個安全層如何在 Agent 之間建立可驗證的信任鏈？

最後，我們也會回答 A2A 系列中最常見的一個問題：A2A 和 MCP 是什麼關係？它們衝突嗎？

---

Task 狀態機：將「不可預測的 AI 行為」放進可預測的框架

AI Agent 天生有個難題：它的輸出並不像一般程式那樣可以預測。同樣一個任務，不同時間、不同模型跑可能得到不同結果，執行多久也難以估計 —— 可能 0.5 秒，可能 5 分鐘，也可能因為需要澄清而中途等待。

但分散式系統工程師對這種情況很熟悉，解法也不陌生：用有限狀態機（FSM）把它管起來。

A2A 的 Task 就是一個精心設計的狀態機，它定義了 7 種狀態與合法的狀態轉移路徑：

狀態	說明
submitted	任務已送達，等待 Agent 開始處理
working	Agent 正在執行，可能持續更新進度
input-required	Agent 需要客戶端提供額外資訊才能繼續
completed	任務成功結束，Artifact 已就緒
canceled	任務被主動取消
failed	任務執行過程中發生錯誤
unknown	任務狀態無法確認（通常發生在連線中斷後）

狀態轉移：拿爬蟲任務走一遍

讓我們用一個具體例子，把這個狀態機走完一圈。場景：使用者透過協調 Agent 委派給一個「網頁爬蟲 Agent」，要求它「寫一個 Python 爬蟲抓取網頁標題」。

Stage 1｜submitted：任務剛送進去

任務建立的瞬間，狀態是 submitted。此時 messages 只有使用者傳來的初始需求，artifacts 是空的。

{
  "taskId": "scraper-task-101",
  "status": "submitted",
  "messages": [
    {
      "role": "user",
      "parts": [{ "type": "text", "text": "請幫我寫一個 Python 爬蟲抓取網頁標題。" }]
    }
  ],
  "artifacts": []
}

Stage 2｜input-required：Agent 需要更多資訊

Agent 發現使用者沒有指定目標 URL，無法精確地撰寫程式碼。它不猜測、不衝動假設 —— 而是進入 input-required 狀態，主動請求澄清。

{
  "taskId": "scraper-task-101",
  "status": "input-required",
  "messages": [
    {
      "role": "user",
      "parts": [{ "type": "text", "text": "請幫我寫一個 Python 爬蟲抓取網頁標題。" }]
    },
    {
      "role": "agent",
      "parts": [{ "type": "text", "text": "好的，請提供您想爬取的目標網址（URL）？" }]
    }
  ],
  "artifacts": []
}

協調 Agent（或使用者）收到這個狀態後，補上 URL，任務重新進入 working。

Stage 3｜working：正在生成，持續串流

使用者補上了 URL，Agent 開始生成程式碼。此時 append: true 表示 artifact 的內容正在持續增量更新，lastChunk: false 代表還沒傳完。

{
  "taskId": "scraper-task-101",
  "status": "working",
  "messages": [
    {
      "role": "user",
      "parts": [{ "type": "text", "text": "請幫我寫一個 Python 爬蟲抓取網頁標題。" }]
    },
    {
      "role": "user",
      "parts": [{ "type": "text", "text": "https://example.com" }]
    }
  ],
  "artifacts": [
    {
      "index": 0,
      "name": "scraper.py",
      "append": true,
      "lastChunk": false,
      "parts": [
        {
          "type": "text",
          "text": "import requests\nfrom bs4 import BeautifulSoup\n\n# 正在生成邏輯..."
        }
      ]
    }
  ]
}

Stage 4｜working（lastChunk: true）：程式碼生成完畢

當 lastChunk 轉為 true，表示 index 0 這個 artifact 已經完整封裝。

{
  "artifacts": [
    {
      "index": 0,
      "name": "scraper.py",
      "append": true,
      "lastChunk": true,
      "parts": [
        {
          "type": "text",
          "text": "import requests\nfrom bs4 import BeautifulSoup\n\ndef get_title(url):\n    res = requests.get(url)\n    return BeautifulSoup(res.text, 'html.parser').title.text\n\nprint(get_title('https://example.com'))"
        }
      ]
    }
  ]
}

Stage 5｜completed：任務結束，Artifact 就緒

{
  "taskId": "scraper-task-101",
  "status": "completed",
  "messages": [
    {
      "role": "agent",
      "parts": [
        {
          "type": "text",
          "text": "程式碼已產出。這是一個使用 BeautifulSoup 的版本，祝您使用愉快！"
        }
      ]
    }
  ],
  "artifacts": [
    {
      "index": 0,
      "name": "scraper.py",
      "append": true,
      "lastChunk": true,
      "parts": [{ "type": "text", "text": "import requests\n..." }]
    }
  ]
}

Stage 6（延伸）｜completed（Revision）：版本演進，歷史留存

使用者進一步需求「加上 CSV 存檔功能」。Agent 不是修改原來的 index 0，而是新增一個 index 1 的 artifact，並透過 metadata.is_revision_of 聲明它是 index 0 的修訂版。artifacts 陣列同時保留兩個版本 —— 這讓整個演進過程可稽核、可回溯。

{
  "artifacts": [
    {
      "index": 0,
      "name": "scraper.py",
      "description": "基本爬蟲版",
      "parts": [{ "type": "text", "text": "..." }]
    },
    {
      "index": 1,
      "name": "scraper_with_csv.py",
      "description": "支援 CSV 匯出版本",
      "parts": [
        {
          "type": "text",
          "text": "import requests\nimport csv\nfrom bs4 import BeautifulSoup\n\n# 新增了 csv 寫入邏輯...\nwith open('output.csv', 'w') as f:\n    writer = csv.writer(f)\n    writer.writerow(['Title'])\n    # ... 其餘邏輯"
        }
      ],
      "metadata": {
        "is_revision_of": 0,
        "features": ["requests", "csv", "beautifulsoup4"]
      }
    }
  ]
}

狀態機的設計哲學

這個 FSM 設計解決了一個在非同步 AI 任務中非常現實的問題：任務中斷後怎麼接著跑下去。

當網路連線中斷、某個 Agent 重啟，任何一方只要拿到 taskId，就能重新查詢當前狀態，從最後一個已知節點繼續，而不是從頭來過。unknown 狀態就是為這個場景設計的，連線恢復後，客戶端重新確認狀態，系統不會因為一次中斷就讓整個長任務作廢。

這是一個把多年分散式系統設計智慧，移植到 AI Agent 場景的典型案例。

---

A2A 安全架構：建立 Agent 間的信任鏈

如果說前面的技術設計回答了「A2A 怎麼運作」，那安全架構回答的是：我們為什麼敢讓 Agent 自主執行？

多 Agent 自主協作帶來了全新的安全挑戰 —— 傳統的 API 安全是人類呼叫系統，現在是機器呼叫機器，跨越組織邊界，且往往沒有人工干預的機會。一個被入侵或惡意偽裝的 Agent，可能在毫秒內發出數千個危險指令。

A2A 的安全架構分為四個層次，每一層保護不同的威脅面：

Layer 1｜發現層（Discovery）— 你是誰？

保護對象：Agent Card 核心機制：選擇性揭露（SD-JWT）、Registry 權限控管

Agent Card 是 Agent 的「履歷」，但公開在 .well-known/agent-card.json 的資訊，並不是所有欄位都該對所有人可見。

A2A 支援一種叫做 SD-JWT（Selective Disclosure JWT，選擇性揭露憑證） 的機制 —— Agent 可以根據對方的身分，決定要開放多少資訊。例如：

• 對外部未知 Agent：只揭露名稱和公開端點
• 對同組織的 Agent：揭露完整 Skills 和內部 API 路徑
• 對特權 Orchestrator：揭露安全配置和管理端點

SD-JWT 在 2025 年已正式成為 IETF RFC 9901，是一個已完成標準化的規範 ——選擇性揭露這個概念也同步被 W3C Verifiable Credentials Data Model v2.0 採納為官方的憑證保護機制，並且是目前歐盟 eIDAS 2.0 / EUDI Wallet（歐洲數位身份錢包） 的核心技術之一。換句話說，A2A 在身份驗證層選用的技術方向，與全球數位身份標準的演進是一致的。

Registry 權限控管則讓企業可以建立一個「Agent 白名單」服務，只有在 Registry 中登記並通過審查的 Agent 才能被其他 Agent 發現和呼叫，防止惡意 Agent 假冒合法服務。

---

Layer 2｜傳輸層（Transport）— 資料有沒有被竄改？

保護對象：Messages 與 Artifacts 核心機制：mTLS、網路隔離（VPN/VPC）

所有 Agent 間的通訊必須加密。A2A 採用 mTLS（Mutual TLS，雙向 TLS） —— 不只是 Server 向 Client 提供憑證，Client 也必須向 Server 提供憑證，雙方互相驗證身分。

這防的是一個很現實的威脅：中間人攻擊 —— 有人偷偷站在兩個 Agent 中間，假裝是對方。在 mTLS 下，即使攻擊者攔截了傳輸中的內容，也無法解密；即使偽裝成合法 Agent，也過不了憑證驗證這關。

在企業內部部署場景，A2A 更建議搭配 VPN / VPC 網路隔離 —— 讓 Agent 間的通訊根本不暴露在公網上，從網路層就杜絕大多數攻擊向量。

---

Layer 3｜應用層（App/Auth）— 你有權限做這件事嗎？

保護對象：執行權限 核心機制：OAuth 2.0、動態憑證（短效期 JWT）

身分驗證解決了「你是誰」， 授權（Authorization） 解決的是「你能做什麼」。

A2A 採用 OAuth 2.0 作為授權框架，讓每個 Agent 在呼叫另一個 Agent 時，必須攜帶有效的 Access Token。這個 Token 的範圍（Scope）精確定義了被呼叫方允許執行哪些操作。

為了降低 Token 洩漏的風險，A2A 強調使用短效期 JWT（Short-lived JWT） —— 即使被竊取，攻擊者能利用的時間窗口也極短。配合 Token 輪換機制，可以進一步降低長期風險。

---

Layer 4｜操作層（Operation）— 這個操作需要人類確認嗎？

保護對象：敏感動作執行 核心機制：input-required 狀態（要求人類二次確認）

這是四個安全層中最「有人味」的一層，也是最重要的一層。

自動化的邊界在哪裡？當 Agent 即將執行某個不可逆或高風險的操作 —— 如刪除生產資料庫的記錄、向外部系統發送付款指令、更改核心基礎設施配置 —— 它不應該自行決定。

A2A 的 input-required 狀態提供了一個原生的人機協作（Human-in-the-Loop） 機制：Agent 執行到關鍵節點時，可以主動暫停、進入 input-required，等待人類（或上層 Orchestrator）確認後才繼續。

這個機制讓 AI 自動化的範圍可以被明確定義和控制 —— 不是「AI 能做所有事」，而是「AI 在授權範圍內自主執行，超出邊界時自動請示」。這才是企業敢把核心業務流程交給 Agent 的真正前提。

延伸閱讀：kagent 的 ask_user tool 提供了這個機制在 Kubernetes 雲原生環境的具體實作 —— 見 【AIOps】kagent 完整解析：ask_user Tool。

---

四層安全架構的整體圖景

安全層	防護對象	核心機制
發現層（Discovery）	Agent Card	選擇性揭露（SD-JWT）、Registry 權限控管
傳輸層（Transport）	Messages	mTLS、網路隔離（VPN/VPC）
應用層（App/Auth）	執行權限	OAuth 2.0、動態憑證（短效期 JWT）
操作層（Operation）	敏感動作執行	input-required（要求人類二次確認）

這四層的設計邏輯叫做縱深防禦 —— 打穿其中一層，不代表整個系統就崩了，後面還有下一道關卡。這是現代資安架構的基本原則，A2A 把它完整套用到了 Agent 間的信任體系上。

---

A2A vs MCP：垂直擴展 vs 水平協作

讀到這裡，你可能有一個問題：A2A 和 MCP 是什麼關係？它們在競爭嗎？

這是 A2A 領域最常見的誤解，讓我們直接說清楚：它們解決的是完全不同的問題，而且相輔相成。

各自解決的問題

MCP（Model Context Protocol） 解決的是「Agent 與工具 / 外部資源」之間的問題 A2A（Agent-to-Agent） 解決的是「Agent 與 Agent」之間的問題

比較表

維度	MCP	A2A
技術定位	垂直整合（Vertical）	水平協作（Horizontal）
解決問題	Agent 如何存取外部工具與數據	Agent 如何與其他 Agent 溝通委派任務
架構模式	Client-Server（Host ↔ Server）	Peer-to-Peer（Agent ↔ Agent）
能力譬喻	賦予 Agent 一套「萬用工具箱」	建立 Agent 之間的「專業社交網絡」
應用場景	讀取日誌、查詢資料庫、執行 Code	跨領域任務分工、異質框架 Agent 溝通

在同一個系統裡，它們如何共存？

一個典型的多 Agent 系統，往往同時用到 MCP 和 A2A：

圖片來源：a2a-protocol.org

這張圖清楚呈現了兩個協議的分工邊界 —— 注意圖中間那條垂直線：「Organizational or technological boundaries」。

左右兩側各自是一個完整的 Agent 生態系，技術棧可以完全不同 —— 左側用 Google 的 Vertex AI（Gemini API）與 Agent Development Kit（ADK），右側可以是任意 LLM 搭配任意 Agent Framework。兩者之間沒有任何依賴關係。

A2A 協議負責穿越這條邊界：讓兩個原本互不相識的 Agent 系統能夠互相溝通、委派任務，無論底層技術棧為何。

MCP 則在各自邊界內部運作：每個 Agent 系統用 MCP 連接自己的 APIs 與企業應用（如資料庫、Slack、GitHub），這部分完全是各自的內部實作，對方無需知曉。

這個設計的精妙之處在於：你不需要要求合作夥伴換掉他們的技術棧，只需要雙方都支援 A2A，就能跨越組織邊界協作。 這才是 A2A 作為「通用語言」的真正價值 —— 它解耦了協作雙方，讓每一側都可以自由演進自己的內部架構。

---

從服務導向到意圖導向：A2A 構建的 Agent Mesh 新紀元

有了 Task 狀態機、三種通訊模式、四層安全架構，以及 MCP 的垂直補強，我們現在有了一幅完整的圖景。

但技術細節之外，A2A 代表的是一種更深層的思維轉變。

服務導向架構（SOA）的時代

過去二十年，企業 IT 的核心範式是「服務導向架構（Service-Oriented Architecture, SOA）」，後來演進為微服務。這個架構的邏輯是：

以「服務」為基本單元 —— 你告訴系統「做什麼」，系統執行。

開發者呼叫一個 API，系統執行一個預定義好的操作，回傳結果。整個系統靠明確的指令驅動。

意圖導向架構（IDA）的時代

A2A 代表的是另一種邏輯：

以「意圖」為基本單元 —— 你告訴系統「你想要什麼結果」，系統自主決定怎麼做。

當你的 Orchestrator Agent 說「幫我分析最近一個月的客戶流失原因，並給出三個改善建議」，它不需要知道：

• 要呼叫哪個資料庫 Agent、哪個分析 Agent、哪個報告生成 Agent
• 每個 Agent 的 API 格式長什麼樣
• 中間的錯誤處理和重試邏輯

這些「怎麼做」的細節，由多 Agent 系統自主協商、分工、執行。人類只需要說清楚「想要什麼結果」，不需要規劃每一步怎麼走。

這和 Kubernetes 的宣告式（Declarative）思維如出一轍，你只需要說「我要三個副本、80% 記憶體時自動擴容」，Kubernetes Control Plane 自己決定怎麼達到並維持這個狀態。

Agent Mesh：意圖導向架構的基礎設施

A2A 正在構建的，是一個 Agent Mesh —— 類比於服務網格（Service Mesh）在微服務世界的角色。

微服務世界	Agent 世界
Service Mesh（如 Istio）	Agent Mesh（A2A 協議）
服務發現（Service Discovery）	Agent 自動發現（Agent Card + Registry）
負載均衡（Load Balancing）	任務路由（Task Routing by Skills）
熔斷 / 重試（Circuit Breaking）	Task 狀態機 + 錯誤狀態管理
mTLS 加密	A2A 四層安全架構
可觀測性（Observability）	Task 稽核日誌 + Artifact 版本追蹤

Agent Mesh 有三個核心特性：

1. 自動化服務發現

Agent 透過 A2A 協議自動宣告自己能做什麼。一個新的 Agent 加入後，協調 Agent（Orchestrator） 可以自動讀取它的 Agent Card、評估它的 Skills，並在合適的任務出現時把它派上場。

2. 跨域協作的標準化

A2A 打破了組織邊界 —— 你的 Agent 可以委派任務給合作夥伴公司的 Agent，只要雙方都遵守 A2A 協議，即使底層框架完全不同，也能順暢溝通。更重要的是，底層跑的是哪個語言模型完全無關緊要：你的 協調 Agent（Orchestrator） 可以是 Gemini 驅動的，子 Agent 可以是 Claude，另一個子 Agent 可以是 OpenAI，甚至是本地部署的開源模型 —— A2A 定義的是 Agent 之間的溝通介面，而不是 Agent 內部的推理引擎。這讓每個 Agent 都能獨立選用最適合自己任務的模型，而不需要整個生態統一在同一家廠商的技術棧上。

3. 分散式治理防護欄

Agent Mesh 內建了意圖審查（input-required 確認機制）與權限委派（OAuth 2.0 Scope 控制），讓「AI 自主決策」和「人類治理」之間的邊界可以被明確定義和動態調整 —— 而不是非此即彼的二元選擇。

---

小結：從「協議」到「基礎設施」

回顧前三篇文章，我們從頭走了一遍 A2A 的全景：

• 第一篇：為什麼多 Agent 協作是必然方向，以及 A2A 解決了什麼根本問題
• 第二篇：A2A 的五個核心元件 —— Agent Card、Task、Message、Part、Artifact
• 本篇：Task 狀態機、四層安全架構，以及 A2A 與 MCP 的定位關係

A2A 協議的誕生，讓我想到 1440 年古騰堡（Johannes Gutenberg）發明的活字印刷術。

印刷術出現之前，書籍由僧侶手抄，知識的複製極其昂貴、緩慢，只有少數人能接觸。古騰堡的突破不是讓書寫得更好 —— 他發明的是一套讓任何內容都能被標準化複製與傳播的機制。此後半個世紀，歐洲的書籍數量從幾萬冊爆增至超過一千萬冊，文藝復興、宗教改革、科學革命接連而至。

A2A 協議的邏輯與此如出一轍。

個別 AI Agent 的能力再強，若無法與其他 Agent 溝通，就像一本手抄孤本 —— 珍貴，但無法規模化。A2A 定義的標準化溝通介面，讓每個 Agent 的能力得以被任意組合、串接、放大：一個專精法律合規的 Agent、一個擅長資料分析的 Agent、一個負責客戶溝通的 Agent —— 透過 A2A，它們能在不同組織、不同技術棧、不同語言模型之間自由協作，就像印刷術讓不同語言、不同地域的思想得以跨越邊界流動。

更關鍵的是，印刷術帶來的不只是「更快的傳播」，而是網絡效應的爆發 —— 每一本新書的出版，讓整個知識網絡對所有人都更有價值。Agent Mesh 成熟之後的邏輯相同：每一個新加入的專業 Agent，都讓整個協作網絡的能力對所有參與者同步提升。

當這個 Agent Mesh 成熟，我們最終獲得的，是一個全新的生產力範式：

不是一個更強的 AI，而是一個每個專業領域都有最強 AI Agent，且所有 Agent 都能無縫協作的世界。

這，才是 A2A 真正想要構建的終局。

如果這篇文章對你有幫助，歡迎分享給對 AI Agent 感興趣的朋友。

下一篇：【A2A 系列 #4】動手做：用 Google ADK 打造你的第一個 A2A 多 Agent 協作 Demo

---

延伸閱讀

看完 A2A 理論，來看它在雲原生環境的實作：

• 【AIOps】Kubernetes 原生的 AI Agent 框架：kagent 完整解析 — 已支援 A2A Protocol 的 CNCF Sandbox 專案，帶你看 A2A 如何在真實 K8s 環境中落地
• 【Agentic SRE】HolmesGPT：雲原生運維的「夏洛克」深度開箱 — 另一個 CNCF Sandbox AI Agent，專為 K8s 故障排查打造

A2A 系列完整回顧：

• 【A2A 系列 #1】從對話到協作：為何 A2A 是 AI 演進的終局之戰？
• 【A2A 系列 #2】深入剖析 A2A：如何讓 AI Agent 彼此溝通與分工？
• 【A2A 系列 #4】動手做：用 Google ADK 打造你的第一個 A2A 多 Agent 協作 Demo