A2A（Agent2Agent）是讓不同公司、不同框架的 AI 代理互相發現能力、委派任務並交換結果的開放協定，截至 2026-10-31 現行版本為 v1.0.1（2026-05-26）。它把連線格式標準化，但身分、授權與出事責任仍交給各家實作，目前也查不到具名、跨公司且有量測成效的生產案例。
A2A 由 Google 於 2025 年 4 月發表，2025-06-23 移交 Linux Foundation，2026 年 8 月再加入與 MCP 同一個基金會的 Agentic AI Foundation（AAIF）。v1.0 起以 a2a.proto 為唯一規範來源，同時支援 JSON-RPC 2.0、gRPC 與 HTTP+JSON/REST 三種綁定。規格的開放議題已經從格式轉向信任：v1.1 的八個主題、留言最多的代理身分議題（約 658 則），以及 2026 年 8–10 月第一批官方 SDK CVE，都集中在身分、委派、授權與推播通知。實際在跑的多半是同一雲平台內的互通（AWS、Microsoft、Google）。對一般企業與跨境電商、物流業者，現階段較穩妥的做法是先把網頁結構化資料與確定性、唯讀的 MCP 工具做好，寫入、下單、付款類操作在責任框架出現前不要開放給外部代理。
好運器 AI 研究小組整理，引用一手規格、GitHub 紀錄、學術論文與政府文件；每個事實附來源，來源互相矛盾處並列說明，推論與廠商宣稱另行標明。 本文區分三種說法：有一手規格、論文或官方文件支持的寫成事實並附來源；新聞稿與廠商部落格中無法獨立驗證的標明「廠商宣稱」；作者依證據推出的判斷標明「推論」。
重點結論
- A2A（Agent2Agent）現行版本是 v1.0.1（2026-05-26），v1.0 起以 a2a.proto 為唯一規範來源，支援 JSON-RPC 2.0、gRPC、HTTP+JSON/REST 三種綁定。
- A2A 與 MCP 的分界是推理迴圈歸誰：MCP 由呼叫端 LLM 掌控工具，A2A 的對方是自己推理的不透明代理；MCP 的 GitHub repo 數約為 A2A 的 65 倍（40,675 對 622）。
- A2A 規格把授權交給實作、卡片簽章為選配；2026 年 8–10 月已出現第一批官方 SDK CVE，a2a-java 曾預設不做讀取授權（CVSS 7.5）。
- 截至 2026-10-31 找不到具名、跨公司且有量測成效的 A2A 生產案例；實際在跑的是同一雲平台內的互通。
- AI 代理付款分結帳、授權證據、機器微付三層，AP2 不分配爭議責任，x402 筆數多為刷量。
- 台灣《人工智慧基本法》已施行但未提代理；數位發展部風險框架把「AI 自主代理之授權外行為」列為風險 B6。
- 跨境電商與物流業者現在該先做網頁結構化資料與確定性 MCP 工具，下單與付款類操作暫不開放給外部代理。
A2A 協定是什麼？誰在維護？
A2A（Agent2Agent）協定是 Google 於 2025 年 4 月發表、2025-06-23 起由 Linux Foundation 託管的代理對代理開放協定，截至 2026-10-31 現行版本為 v1.0.1（2026-05-26），用途是讓分屬不同組織的 AI 代理互相發現能力、委派任務與交換結果。
A2A 官方對自己與 MCP 的分工說法是：「MCP 是垂直的，加深單一代理；A2A 是水平的，跨邊界連接代理。」在 A2A 裡，被呼叫的一方是一個「不透明」的代理：它自己推理、自己保存狀態，呼叫方看不到它內部用了哪些模型或工具，雙方只透過任務（Task）的生命週期多輪往來。台灣官方文件也已經寫到 A2A：數位發展部《公部門人工智慧應用參考手冊》V1.0（文件記載提供日期 115-01-28）第 14 頁設有「A2A：AI代理間的溝通協議」小節，說明它專注在「Client-遠端」的溝通。
A2A 的治理分三個階段。2025-06-23 Linux Foundation 宣布接手，創始成員為 AWS、Cisco、Google、Microsoft、Salesforce、SAP、ServiceNow；2025-08-29 IBM 主導的 ACP 併入 A2A 並停止開發。實際決策權在一個 9 席的技術指導委員會（TSC），一家公司一席：Google、Microsoft、Cisco、AWS、Salesforce、ServiceNow、SAP、IBM、Bloomberg。議案在標有 TSC Review 的 GitHub issue 上用 gitvote 表決，例如 #1942 把 41 個議題整併為 v1.1 的八個主題，2026-06-25 以 5 票贊成、0 票反對通過（門檻 51%）。
2026 年 8 月，A2A 以 Growth Stage 專案身分加入 Agentic AI Foundation（AAIF），和 MCP 同屬一個基金會。加入日期各來源並不一致：AAIF 部落格與 Axios 寫 2026-08-17，A2A 官方部落格與規格頁寫 2026-08-27，Forbes 的報導日期是 08-19。一種可能是 08-17 為基金會對外宣布、08-27 為專案方發文，但沒有來源證實這個解釋，本文兩個日期並列、不替讀者挑一個。Diginomica 把 A2A 算作 AAIF 第 5 個託管專案，前四個是 MCP、goose、AGENTS.md、agentgateway；也有二手來源強調這次只是組織層面的調整，兩份規格並沒有合併。
A2A 治理文件寫明「成立 18 個月後決定穩定期組成」。從 2025 年 6 月起算，大約在 2026 年 12 月到期，而 AAIF 的公告沒有說明 TSC 是否改組——這是推論，代表 TSC 的組成可能在近期改變，值得追蹤。
| 名詞 | 是什麼 | v1.0 要注意的地方 |
|---|---|---|
| Agent Card | 代理的公開「名片」，宣告技能、介面、認證方式，慣例放在 /.well-known/agent-card.json | 改以 supportedInterfaces[] 為核心；卡片簽章是選配 |
| Task | 一次協作的工作單位，有自己的狀態機 | taskId 一律由伺服器產生；已進入終態的任務不能重啟 |
| Message | 雙方往來的一則訊息 | 代理可以只回 Message、不建立 Task，客戶端兩種都要能處理 |
| Part | 訊息或產出物裡的內容片段 | 壓平成 text、raw、url、data 四選一，移除 kind 判別欄位 |
| Artifact | 任務的產出物 | 可隨任務進度以串流送出 |
| Extension | 在核心之外加功能（例如支付） | 以 URI 識別，不能修改核心資料結構或新增 enum 值 |
依據來源 A2A Specification| A2A and MCP（A2A 官方說明）| Linux Foundation：A2A 專案成立新聞稿（2025-06-23）| LF AI & Data：ACP 併入 A2A| A2A GOVERNANCE.md| A2A Issue #1942（v1.1 主題表決）| AAIF：A2A joins AAIF| Axios（2026-08-17）| A2A 官方公告（2026-08-27 加入 AAIF）| Forbes（2026-08-19）| Diginomica| 數位發展部《公部門人工智慧應用參考手冊》V1.0
A2A v1.0 改了什麼？任務、串流與推播怎麼運作？
A2A v1.0.0（CHANGELOG 記載 2026-03-12 發布）改以 a2a.proto 為唯一規範來源，從同一份 proto 推導出 JSON-RPC 2.0、gRPC、HTTP+JSON/REST 三種綁定，並把方法全面改名、把 Part 資料結構壓平；2026-05-26 的 v1.0.1 則是與 1.0.0 線路相容的修補版。
A2A v1.0 的方法全部改名：message/send 改為 SendMessage、message/stream 改為 SendStreamingMessage、tasks/resubscribe 改為 SubscribeToTask，另外新增 ListTasks。REST 路徑改用 AIP 風格，例如 POST /tasks/{id}:cancel，並拿掉 /v1 前綴。HTTP 錯誤格式從 RFC 9457 的 application/problem+json 換成 google.rpc.Status，reason 用大寫底線寫法（例如 TASK_NOT_FOUND），domain 固定為 "a2a-protocol.org"。研究筆記認為這次改版等於把 A2A 改造成 Google API 設計指南的風格，這是推論。
資料模型最大的破壞性變更是 Part 被壓平。原本的 TextPart、FilePart、DataPart 與 kind 判別欄位都移除了，改成同一個 Part 裡只放 text、raw（bytes）、url、data 其中一個，判斷方式從讀 kind 改成看哪個欄位存在；mimeType 改名 mediaType，file.fileWithUri 改為 url。社群回報指出，很多解析器到現在還在讀 part.kind，這是 0.3 與 1.0 互通失敗最常見的原因。Agent Card 則改以 supportedInterfaces[] 為核心，每個介面各自帶 url、protocolBinding、protocolVersion 與可選的 tenant；客戶端依陣列順序挑選，並 SHOULD 實作 fallback。
版本協商有一條很少人注意的預設：A2A-Version 標頭留空，就當成 0.3。客戶端只送 Major.Minor，伺服器不支援時回 −32009 VersionNotSupportedError；同一個代理可以在 supportedInterfaces 列出不同 protocolVersion 的介面，讓 0.3 與 1.0 並存。官方遷移分三階段：先能解析兩種格式，再輸出 1.0、讀 0.3，最後只留 1.0。Atlassian Forge 與 MuleSoft 都已發布 0.3→1.0 遷移指南，可見破壞性變更真的有人在付成本。
任務語意有幾個要讀完規格才會發現的細節。taskId 一律由伺服器產生；contextId 若由客戶端帶入，代理只能接受或拒絕，不能另生一個；taskId 與 contextId 不一致時代理 MUST 拒絕。對 COMPLETED、FAILED、CANCELED、REJECTED 這四種終態任務再送訊息，會得到 UnsupportedOperationError，要接著做就在同一 context 開新任務，再用 referenceTaskIds 串回原任務。狀態機有兩個「中斷」狀態：TASK_STATE_INPUT_REQUIRED 與 TASK_STATE_AUTH_REQUIRED，阻塞式 SendMessage 遇到中斷狀態也會返回。
串流與推播的保證比多數人以為的弱。TaskStatusUpdateEvent 的 final 旗標在 1.0 被移除，改用「連線關閉」代表串流結束，所以任務做到一半斷線和任務完成在客戶端看起來一樣，必須再呼叫 GetTask 或 SubscribeToTask 才分得出來；規格也沒有事件 ID 續傳機制，已列為 v1.1 主題 #1986。推播通知是把 StreamResponse 以 HTTP POST 送到客戶端 webhook，Content-Type 為 application/a2a+json；規格只要求代理至少嘗試送一次、逾時 SHOULD 約 10–30 秒，接收方 SHOULD 冪等處理並 MUST 核對 taskId。換句話說，推播是「至少一次、不保證順序、payload 沒有簽章」，這是依規格推論的結果。冪等性也只做了一半：SendMessage「可以」用 messageId 去重，但不是必須。
日期與數量有兩處來源矛盾。v1.0 發布日：CHANGELOG 寫 2026-03-12，一篇綜述論文（arXiv:2507.10644 v4）寫 2026 年 1 月，Linux Foundation 一週年新聞稿只說 v1.0 是第一個穩定版、沒給日期，本文採 CHANGELOG 這個一手來源。SDK 數量：Linux Foundation 2026-04 說有 5 種「production-ready」語言，A2A 官方公告列出 Python、Go、Java、JS、.NET、Rust 共 6 種，但被詳細測試過的 Rust SDK 是社群版。
| 日期 | 版本或事件 | 重點 | 證據等級 |
|---|---|---|---|
| 2025-04 | Google 發表 A2A | 50 多家合作夥伴 | 二手來源 |
| 2025-05-27 | 0.2.1 | 新增 referenceTaskIds、extended card 布林值 | 一手（CHANGELOG） |
| 2025-06-09 | 0.2.2 | 破壞性的 JSON-RPC 對齊；gRPC／REST 定義；extensions | 一手（CHANGELOG） |
| 2025-06-23 | Linux Foundation 接手 | 7 家創始成員 | 一手（LF 新聞稿） |
| 2025-06-30 | 0.2.5 | Agent Card 必填 protocolVersion；每個任務可有多個推播設定 | 一手（CHANGELOG） |
| 2025-07-30 | 0.3.0 | agent.json 改名 agent-card.json（破壞性）；卡片簽章；mTLS；技能層級安全 | 一手（CHANGELOG） |
| 2025-08-29 | IBM ACP 併入 A2A | ACP 停止開發 | 一手（LF AI & Data） |
| 2026-03-12 | 1.0.0 | proto 為規範、Part 壓平、方法改名、版本協商、多租戶、ListTasks | 一手（CHANGELOG）；另有論文寫 2026 年 1 月 |
| 2026-05-26 | 1.0.1 | 與 1.0.0 線路相容的修補；建議媒體類型 application/a2a+json | 一手（CHANGELOG） |
| 2026-08-17 或 08-27 | 加入 AAIF | 與 MCP 同一基金會 | 來源日期矛盾 |
| 2026-10-01 | 官方 a2a CLI 推出 | 命令列工具 | 一手（A2A 公告） |
依據來源 A2A Specification| What's new in A2A v1| A2A CHANGELOG| A2A 官方公告| DEV Community：A2A tech update（2026-03-20）| Atlassian Forge：A2A 0.3→1.0 遷移| MuleSoft：A2A Connector 升級遷移| Petrova et al., Web of Agents（arXiv:2507.10644 v4）| Linux Foundation：A2A 一週年新聞稿| philippdubach：MCP vs A2A in 2026（2025-04 發表背景）
A2A 和 MCP 差在哪？該用哪一個？
A2A 與 MCP 的真正分界是推理迴圈歸誰：MCP 由呼叫端的 LLM 掌控，對方只交出 schema 透明的工具；A2A 的對方是自己推理、自己保存狀態的不透明代理。兩者的採用規模差了一到兩個數量級，帶 mcp-server topic 的 GitHub repo 有 40,675 個，帶 a2a-protocol 的有 622 個。
過去一年常聽到「MCP 加了 Tasks，A2A 就沒必要了」，但 MCP 2026-07-28 版的實際走向正好相反。MCP 2025-11-25 版確實加入實驗性的 Tasks（SEP-1686），用途是追蹤長時間請求、輪詢與延後取回結果，其狀態（working、input_required、completed、failed、cancelled）與 A2A 幾乎一一對應。可是 2026-07-28 版移除了 session 與 initialize 握手、讓 MCP 變成無狀態（SEP-2567、SEP-2575），把 Tasks 移出核心改成官方擴充 io.modelcontextprotocol/tasks（SEP-2663），用 MRTR（InputRequiredResult 搭配重送時附上的 inputResponses）取代伺服器主動發起的請求（SEP-2322），並把 Sampling、Roots、Logging 列為 deprecated（SEP-2577）。
這些變更的意思是，MCP 維護者刻意放棄了「伺服器反過來借用呼叫端 LLM 推理」這條代理化路線，這是推論。MCP 伺服器如果要自己推理就得自帶模型，那時它其實已經是一個不透明代理，只是外表還是工具。MCP 的 Task 處理的是「一次長時間工具呼叫的延後取回」，A2A 的 Task 處理的是「雙方都可能提問的多輪協作」，另外還有 Agent Card 發現、技能宣告與 artifact 串流。反方向也有失效情境：查價、查稅率這類確定性查詢若硬套 Task、Message、Artifact 生命週期，延遲與實作成本都會增加，呼叫端 LLM 也拿不到精細的工具 schema，這同樣是推論。研究筆記沒有找到「用 MCP 做代理對代理而失敗」或「用 A2A 包工具而失敗」的實際事故紀錄。
採用面，除了 GitHub topic 數量，一則非系統性的 PyPI 比較顯示 A2A SDK 約 1,090 萬次下載、MCP SDK 約 2.57 億次。二手來源指出 Shopify 的 UCP 端點以 MCP 為傳輸層，也就是主流商務代理接上來時走的是 MCP。各雲平台方面：AWS AgentCore Runtime 可以部署 A2A 伺服器（JSON-RPC、POST /、port 9000、OAuth 2.0 或 SigV4）；Microsoft Foundry 的 A2A 支援在 2026 年 6 月進入 public preview；Google Agent Registry 會讀取 well-known 卡片，但自動發現只限同一個專案。在研究筆記查到的主要模型廠商中，Anthropic 目前沒有原生 A2A 支援，Claude Code 相關的 issue #104852 在 2026 年 10 月下旬才開立。
實務上的選擇方式很單純：要讓 AI 助理呼叫你的確定性功能（報價、查稅率、查貨況），用 MCP；要讓兩個各自會推理、分屬不同組織的代理多輪協作，才需要 A2A。好運器的公開 MCP 就屬於前者，接法可參考站內的集運 MCP 教學。
| 比較項目 | MCP | A2A |
|---|---|---|
| 連接對象 | 代理與工具、資源 | 代理與代理 |
| 誰掌控推理迴圈 | 呼叫端的 LLM | 遠端代理自己 |
| 對方透明度 | 工具 schema 透明 | 不透明，只看 Agent Card 宣告 |
| 狀態 | 2026-07-28 版改為無狀態，Tasks 移為官方擴充 | 有狀態的 Task 生命週期，支援多輪 |
| 發現機制 | MCP Registry（2025-09 起預覽至今） | /.well-known/agent-card.json；官方不提供註冊中心 |
| 適合場景 | 查價、查稅率等確定性查詢 | 跨組織、多輪、需要對方判斷的協作 |
| GitHub repo 數 | 40,675（mcp-server topic） | 622（a2a-protocol topic） |
| 基金會 | AAIF | 2025-06 起 Linux Foundation；2026-08 加入 AAIF |
集運 MCP 教學：在 Claude 目錄連接好運器 ・ 好運器開發者平台：公開 MCP 與會員 MCP 說明
依據來源 A2A and MCP（A2A 官方說明）| MCP 2025-11-25 changelog| MCP 2026-07-28 changelog| WorkOS：MCP 2025-11-25 spec update| gravity.fast：MCP adoption statistics| Hacker News 相關討論（PyPI 下載比較）| Presta：UCP 與 AI 購物代理指南| AWS：AgentCore Runtime A2A protocol contract| Microsoft 365 Message Center AZ563716| Google Cloud：Agent Registry automatic registration| anthropics/claude-code Issue #104852
A2A 安全嗎？已知漏洞與 CVE 有哪些？
A2A 規格只規範憑證「怎麼宣告、怎麼傳」，授權交給各家實作、Agent Card 簽章也是選配；2026 年 8–10 月已出現第一批官方 SDK CVE，其中 a2a-java 的 CVE-2026-111764 因預設不做讀取授權而被評為 High（CVSS 7.5）。
A2A 的 Agent Card 以 securitySchemes 宣告五種認證方案之一：API Key、HTTP Auth、OAuth2、OIDC、mTLS。v1.0 移除了 OAuth 的 implicit 與 password flow，新增 Device Code，並建議所有客戶端使用 PKCE。規格要求伺服器「MUST authenticate every incoming request」，但授權屬於 implementation-specific，憑證取得要走頻外（out-of-band）管道；任務進入 AUTH_REQUIRED 狀態時，規格特別寫明「Agents MUST NOT treat the state transition alone as authorization」。第 13 節「安全考量」完全沒有提到 prompt injection、委派或 token exchange、OpenTelemetry，也沒有專門的租戶隔離要求。Semgrep 在 v0.3 時期的評論指出，A2A「supports but does not enforce Agent Card signing」，token 壽命與 scope 不受協定約束，而且同一任務可以有多條並行串流，被偷走的 session token 可以靜默監聽受害者的串流。
即使簽了 Agent Card，目前也不保證能跨 SDK 驗證。規格的做法是先依 RFC 8785（JCS）正規化卡片（排除 signatures 欄位）再做 JWS，protected header MUST 包含 alg 與 kid。Issue #2122（2026-08-10 開立，截至 2026-10-31 未關閉）記錄了實測差異：a2a-python 1.1.2 與 @a2a-js/sdk 1.0.1 正規化出來的位元組不同，Python 把非 ASCII 字元跳脫成 \uXXXX、以 code point 而非 UTF-16 單位排序、把數字輸出成 1e-06，ECMAScript 則輸出 0.000001；規格要求 REQUIRED 欄位即使是預設值也要出現，但 proto3 沒有 presence 概念，description: "" 與 skills: [] 會被丟掉；typ 也有歧義。PR #2319 修正了規格範例，但 a2a-go 的輸出仍然不同。另一個限制是，簽章驗過只證明卡片沒被竄改，不證明發卡者的身分，社群也指出規範沒有任何機制把卡片綁到實際發出呼叫的執行環境。
有些攻擊完全符合規格也能成立。A2ABreak（arXiv:2609.10871，v3 2026-10-24）用 LLM 從自然語言規格萃取出 37 個狀態、76 個轉移、929 條形式化陳述，找到 11 個新漏洞，全部「不需要任何實作缺陷，規範合規的對手就能利用」，例如 context identifier 沒有保護造成跨客戶端 context 注入、委派鏈多跳後身分遺失、代理宣稱未經證實的能力。名稱碰撞研究（arXiv:2609.27624）指出規範把 name 定位為「human-readable metadata, not as a stable identity」且沒有定義碰撞規則，作者追蹤的 7 個開源實作中有 6 個客戶端型整合會把請求送到攻擊者控制的端點，作者將其定性為反覆出現的實作漏洞類別，而非通用的協定漏洞。Palo Alto Networks 旗下 Unit 42 以 Google ADK 做的 session smuggling 概念驗證，示範惡意代理用「澄清問題」套出系統指令，並誘導客戶端呼叫 buy_stock 未經授權買進 10 股；Unit 42 明確表示這不是協定漏洞，任何有狀態的多輪協定都可能受影響，也沒有看到野外利用。社群另回報，惡意伺服器可以把指令藏在 Agent Card 的 description 或 skills 欄位，被宿主 LLM 當成指令執行。
學術界對跨代理攻擊的實證也支持「代理之間的信任不能預設」。Triedman 等人（COLM 2025）發現惡意網頁內容可以劫持多代理系統的控制流程，以 GPT-4o 為例，任意程式碼執行在 58%–90% 的試驗中成功；Ferrag 等人在 ICT Express（2026）的同行評審綜述，把 prompt injection 一路整理到協定層攻擊，涵蓋 MCP 與 A2A。
下表的 CVE 編號完全照研究筆記抄錄。研究筆記本身註明這些編號的數字不尋常，部分條目只見於單一資料庫（例如 CVE-2026-90790 在 a2a-python repo 沒有對應的 GHSA，只見於 OpenCVE）。a2a-js、a2a-go、a2a-dotnet 的 repo advisories 查詢結果是空的，但這可能是權限不足，不代表一定沒有漏洞。這張表可以歸納出三個教訓，以下屬推論：第一，Agent Card 是攻擊者可以控制的輸入，連 header 名稱都可能由對方決定；第二，規範只寫「SHOULD 驗證 webhook URL」，兩種語言的 SDK 都因此出了 SSRF；第三，規範說「授權由實作決定」，最熱門的 Java SDK 預設就沒做授權，修補還被 Android 平台差異繞過。
| 編號 | 元件 | 問題 | 嚴重度 |
|---|---|---|---|
| GHSA-qw47-mcm5-934w／CVE-2026-111764 | a2a-java server-common < 1.3.0.Final | InMemoryTaskStore 無參建構子把 authorizationProvider 設成 null，預設不做讀取授權（fail-open） | High，CVSS 7.5 |
| GHSA-9rhm-2h4x-jwmx／CVE-2026-111763 | a2a-java < 1.3.0.Final | 惡意 AgentCard 以 APIKeySecurityScheme 指定自訂 header 名再回 redirect，API key 被轉送給第三方 | Medium |
| GHSA-4fpj-g9jf-9rgg／CVE-2026-111765 | a2a-java（Android） | Android 同步 POST 繞過上一筆的 redirect 修補 | High |
| GHSA-q78c-5jjq-57g8／CVE-2026-111761 | a2a-java | 推播通知 SSRF | Medium |
| GHSA-x32g-jvvm-4725／CVE-2026-111762 | a2a-java | protobuf 解析失敗時把推播憑證明文寫進 log | Medium |
| CVE-2026-90790 | a2a-python ≤ 1.1.3 | _dispatch_notification 經 push_info.url 的 SSRF，1.1.4 修補；repo 無對應 GHSA，只見於 OpenCVE | CVSS 6.3 |
| CVE-2026-115419／GHSA-4v6f-7vjh-6x4m | Strands Agents A2A 伺服器 | 不同 context_id 的呼叫者共享對話歷史；無完整 workaround，建議一個租戶一個實例 | High，CVSS 8.1 |
| CVE-2025-6167 | 非官方 python-a2a ≤ 0.5.5 | 路徑穿越（與官方 a2a-sdk 是不同套件） | 未標示 |
依據來源 A2A Specification（§4.5、§7、§8.4、§13）| Semgrep：A security engineer's guide to the A2A protocol| A2A Issue #2122（簽章正規化差異）| A2A Discussion #1677| levelup：Signed Agent Cards prove integrity, not identity| Lotfi et al., A2ABreak（arXiv:2609.10871）| Arun Kumar, Agent Name Collision Attacks（arXiv:2609.27624）| Unit 42：Agent session smuggling| langgraph-a2a-client Issue #8（卡片欄位注入回報）| Triedman et al., Multi-Agent Systems Execute Arbitrary Malicious Code（COLM 2025）| Ferrag et al., ICT Express 12（2026）| GitHub Advisory GHSA-qw47-mcm5-934w| GitHub Advisory GHSA-9rhm-2h4x-jwmx| a2a-java advisory GHSA-4fpj-g9jf-9rgg| a2a-java advisory GHSA-q78c-5jjq-57g8| a2a-java advisory GHSA-x32g-jvvm-4725| OpenCVE：a2a-python| GitLab Advisory：CVE-2026-115419| Vulners：python-a2a
AI 代理的身分與授權怎麼驗證？
截至 2026-10-31，AI 代理的身分與委派仍沒有定稿的共同標準：工作負載身分由 IETF WIMSE 工作組推進，委派多半套用 RFC 8693 token exchange，對外可驗證身分則有 Cloudflare Web Bot Auth 與 ANS v2 草案等方案並存，A2A 本身只觸及選配的 Agent Card 簽章。
代理身分問題正在 A2A 之外分成三層。第一層是工作負載身分，回答「這是哪個程式」：draft-klrc-aiagent-auth 的作者來自 Amazon、Zscaler、Ping Identity、OpenAI 等公司，已被 IETF WIMSE 工作組採納並由 draft-ietf-wimse-aims 取代，路線是套用既有的 WIMSE 與 OAuth 2.0 家族，「不發明新協定」。第二層是授權與委派，回答「代表誰、能做什麼」：Ping Identity 的範例以 RFC 8693 token exchange 的 act claim 記錄整條委派路徑、用 may_act 限定下一跳；但 RFC 8693 原本是為「同意已經發生之後」的伺服器間交換設計，不原生涵蓋使用者對某個特定代理的同意。
第三層是對外可驗證身分，回答「陌生方怎麼信它」。Cloudflare Web Bot Auth 用 Ed25519 加 RFC 9421 簽署 HTTP 請求，但 Cloudflare 目前不驗 nonce，防重放主要靠約 1 分鐘的短效期；ANS v2 草案用 ACME 驗證網域，分 Bronze、Silver（加 DANE）、Gold（加 SCITT 透明度日誌）三級。A2A 只觸及這一層的卡片簽章，而且簽章是選配。商用產品已先上線：Okta Agent SSO 在 2026-08-24 正式推出並使用 ID-JAG；Microsoft Entra Agent ID 不原生支援 ID-JAG，正式推出日期各來源說法不一（2026-04 或 2026-05）。所以跨公司做 A2A 時，雙方多半得在各自邊界做 token 轉換，這是推論。
政府層級也在補這塊空白。美國 NIST 的 CAISI 在 2026-02-17 宣布 AI Agent Standards Initiative，三大支柱是產業主導的標準、社群主導的開源協議、代理安全與身分研究，但倡議頁只寫「interoperable agent protocols」等泛稱，沒有點名 A2A 或 MCP。NIST NCCoE「Software and AI Agent Identity and Authorization」專案在 2026-09-29 公布概念文件意見摘要，回應者超過 600 個單位或個人。NIST 2026-10-27 的部落格〈Design Tenets for Agent Identity Management Systems〉提出 10 條設計原則，包括代理要有獨立身分、與發起者連結且委派時權限逐層縮小、最小權限、授權短期且可撤銷、依風險觸發人類介入、用簽署的 mandate 界定行動範圍、留下不可竄改的紀錄；它的定位是部落格，不是正式標準。
學術研究的方向與此一致。South 等人提出在 OAuth 2.0／OIDC 上擴充代理專用憑證、建立可稽核的委派鏈，同一研究的立場版本收錄於 ICML 2025 Position Paper Track；Chan 等人在 FAccT 2024 主張以代理識別碼、即時監控、活動日誌三類措施提升代理的可見度。
| 層級 | 回答的問題 | 主要方案 | 現況 |
|---|---|---|---|
| 工作負載身分 | 這是哪個程式 | IETF WIMSE（draft-ietf-wimse-aims） | 工作組草案，尚未成為 RFC |
| 授權與委派 | 代表誰、能做什麼 | RFC 8693 token exchange（act、may_act） | 已是 RFC，但不涵蓋使用者對特定代理的同意 |
| 對外可驗證身分 | 陌生方怎麼信它 | Cloudflare Web Bot Auth、ANS v2 草案、A2A Agent Card 簽章 | 各自部署，沒有共同標準；A2A 簽章為選配 |
| 商用產品 | 企業現在能買什麼 | Okta Agent SSO（2026-08-24 推出，ID-JAG）、Microsoft Entra Agent ID | 彼此互通有限 |
依據來源 IETF Datatracker：draft-klrc-aiagent-auth| Ping Identity：以 Ping 授權 Gemini Agent2Agent| Identra：OAuth on-behalf-of| Cloudflare Docs：Web Bot Auth| IETF：draft-narajala-courtney-ansv2-01| Forkast：六家廠商推出代理身分產品| tech-insider：AI 代理身分供應商比較| NIST：AI Agent Standards Initiative（2026-02-17）| NIST：Software and agentic AI identity 概念文件意見摘要（2026-09-29）| NIST：Design Tenets for Agent Identity Management Systems（2026-10-27）| South et al., Authenticated Delegation and Authorized AI Agents（arXiv:2501.09674）| Chan et al., Visibility into AI Agents（FAccT 2024）
AI 代理怎麼付款？AP2、x402 和 A2A 是什麼關係？
AI 代理付款目前分成結帳、授權證據、機器微付三層協定，A2A 只是可以掛載支付擴充的通訊層；其中 AP2 v0.2.0（2026-04-28）改用 Checkout Mandate 與 Payment Mandate，2026-04-29 由 Google 捐給 FIDO Alliance 託管，但規格明文把爭議處理列為範圍外，不分配責任。
AP2 已經不是 2025 年大家記得的版本。v0.2.0 把機制改成 Checkout Mandate 與 Payment Mandate，各自分為 open 與 closed 兩階段，以 SD-JWT 實作，open mandate 用 cnf claim 存放代理的公鑰。新增的重點是 Human-Not-Present 流程：使用者先在可信介面上用自己的金鑰簽 open mandate、寫下限制條件，代理之後再用代理金鑰簽 closed mandate，兩段以 sd_hash 綁在一起；商家或憑證提供者可以回傳 unresolved_constraint，把流程拉回「人在場」。規格也建議商家簽 Checkout JWT 時用非決定性簽章（ECDSA）、不要用 Ed25519，以防彩虹表攻擊。最關鍵的是，AP2 規格把爭議處理、保存與調閱列為 out of scope，只承諾提供不可否認的密碼學稽核軌跡。研究筆記另注意到，AP2 規格推薦的擴充方式是 UCP 的 extension points，A2A 在規格正文中反而沒被討論，AP2 的定位正從「A2A 擴充」移向「商務協定裡的安全層」，這是推論。
支付擴充掛在 A2A 上的方式，就是 A2A 的 extension 機制本身：在 AgentCapabilities 裡以 AgentExtension（uri、description、required、params）宣告，客戶端用 A2A-Extensions 標頭要求啟用；擴充不能修改核心資料結構、不能新增 enum 值，只能透過 metadata 運作，破壞性變更必須換新的 URI，碰到不支援的版本「MUST NOT fall back」。a2a-x402（spec v0.1）就是這種擴充：商家送 payment-required，客戶端簽名後回 payment-submitted，商家上鏈結算後回 payment-completed。
x402 的交易筆數主要來自刷量。Chainalysis 統計 Base 鏈上的 x402 交易到 2026 年第一季累計超過 1 億筆，但 2025 年第四季的暴增「大多由 meme coin farming 驅動」，每週留存從 87% 跌到 5%。Coinbase 在 2026 年 4 月底宣稱約 1.65 億筆、累計約 5,000 萬美元，這是廠商宣稱；Artemis 則認為超過 95% 是協定訊號或測試；另有追蹤站估計真實商務金額每天約 2.8 萬美元。
卡組織與平台的實際做法是「多協定都收、人在場的強認證當安全閥」。OpenAI 在 2026 年 3 月把 ChatGPT 內的 Instant Checkout 退回商家 Apps 模式，發言人的說法是「Instant Checkout is moving to Apps」。Visa 在 2026-07-02 宣布歐洲已有代理實際完成購買，合作發卡機構超過 30 家，交易全部用 Payment Passkeys 來符合強客戶認證（SCA）。責任框架仍是空白：Chargebacks911 警告爭議與責任基礎設施「largely unaddressed」；Taylor Wessing 分析，在歐盟框架下，代理超出客戶設定條件的購買原則上會被認定為未授權交易；Ant International、Visa、Mastercard 在 2026-09-10 才開始探索 Know-Your-Agent 互通框架。歐盟 PSD3／PSR 目前只到理事會 2026-10-29 通過第一讀立場，尚未刊登 Official Journal，理事會的 PSR 理由書以關鍵字搜尋查無 AI 或自主代理條款；美國 CFPB 也沒有代理支付指引。
學術研究點出另一個盲點。Debi 等人（IEEE IMNS 2026）用 AP2 購物代理做紅隊測試，間接與直接 prompt injection 可以操縱商品排序並取出使用者敏感資料，說明簽章 mandate 保護不到簽章之前的推理過程；Jiang 等人（arXiv:2609.00060）則用 Tamarin 形式化分析 x402、MPP、ACP、AP2，指出意圖、委派權限與結算分散在多方所產生的安全依賴。物流業的代理化目前走的是 MCP：Flexport 的 MCP 伺服器讓客戶的 AI 助理用議定費率訂艙並取得 booking ID。研究筆記沒有找到任何以 AP2 或 x402 結算運費的實例。
| 層級 | 協定 | 主導方 | 現況 |
|---|---|---|---|
| 結帳層 | ACP | OpenAI＋Stripe | 2026-03 ChatGPT Instant Checkout 改走商家 Apps，ACP 持續存在 |
| 結帳層 | UCP | Google＋Shopify | 二手來源指 Shopify 的 UCP 端點以 MCP 為傳輸層 |
| 授權證據層 | AP2 v0.2.0 | Google 發起，2026-04-29 捐給 FIDO Alliance | 爭議處理不在規格範圍內 |
| 授權證據層 | Verifiable Intent | Mastercard | 二手來源指 2026-03 開源 |
| 機器微付層 | x402 | Coinbase 發起 | 鏈上筆數多為刷量；真實商務量估計每天約 2.8 萬美元 |
| 機器微付層 | MPP | Stripe＋Tempo | 二手來源指 2026-03 隨 Tempo 主網推出 |
依據來源 AP2 v0.2 Specification| AP2 Flows| ap2-protocol.org| FIDO Alliance：Google 捐贈 AP2| A2A Extensions| google-agentic-commerce/a2a-x402| Chainalysis：x402 agentic payments adoption| Forkast：x402 實際交易量| presenc.ai：x402 採用追蹤| Digital Commerce 360（2026-03-06）| Visa UK 新聞稿（2026-07-02）| The Paypers：Chargebacks911 警告| Taylor Wessing：Agentic AI in payments| TechNode（2026-09-10）| The Paypers：MPP 推出| Mastercard Developers：Agentic 交易指南| 歐盟理事會 PSR 第一讀立場投票文件 ST 15154/26| Debi et al., Whispers of Wealth（IEEE IMNS 2026）| Jiang et al., A Formal Analysis of Agent Payment Protocols（arXiv:2609.00060）| SupplyChain247：Flexport AI 助理訂艙
A2A 現在有人在用嗎？有生產案例嗎？
截至 2026-10-31，研究筆記找不到任何具名、跨公司且有量測結果的 A2A 生產案例；Linux Foundation 2026-04-09 宣稱有 150 多個支持組織與生產部署，但沒有點名使用者，而一位作者 2026-10-27 對 18 個組織發出 36 個請求，取得的有效 Agent Card 是 0 張。
Linux Foundation 2026-04-09 的一週年新聞稿說 A2A 有 150 多個支持組織，並在供應鏈、金融、保險、IT 營運有生產部署，這屬於廠商宣稱：新聞稿沒有點名任何使用者，也沒有提供流程或成效指標。最常被拿來當例子的 Microsoft Agent Framework .NET 文章與 Google 採購 concierge codelab，都是程式範例而不是部署報告。Tyson Foods 常被宣傳為 A2A 供應鏈案例，但 apis.io 給它的 A2A Agent Card 分數是 0/8，它對交易夥伴提供的仍是 EDI 與 API。
最直接的反證是實測。一位作者 2026 年 4 月從公開註冊中心抽了 50 個宣稱支援 A2A 的代理，只有約 0–2 個在 well-known 路徑提供有效卡片，正確回應 task 的是 0 個；同一位作者 2026-09-09 對 12 個組織發了 24 個請求、2026-10-27 對 18 個組織發了 36 個請求，拿到的卡片都是 0 張。樣本由作者自選，不是普查，但方向一致。實際有在跑的是同一雲平台內的互通：AWS AgentCore、Microsoft Foundry、Google Agent Registry。
多代理架構本身的實證也對跨組織 A2A 不利。MAST（NeurIPS 2025 Datasets & Benchmarks Track）分析 1,642 筆執行軌跡，歸納出 14 種失敗模式，分成系統設計、代理間錯位、任務驗證三大類；文中 7 個最先進開源多代理系統的失敗率在 41%–86.7% 之間（作者提醒不同 benchmark 不能直接比較）。Google Research 與 MIT 等作者的「Towards a Science of Scaling Agent Systems」在 v1／v2 與 Google 部落格版本中測了 180 種配置：獨立式多代理的錯誤放大 17.2 倍、中央協調式 4.4 倍，序列推理任務上所有多代理變體退步 39%–70%；2026-04-08 的 v3 擴充為 260 種配置、6 個 benchmark，仍保留 17.2 倍與 4.4 倍的結論。Anthropic 工程部落格（非同行評審論文）說明其多代理研究系統比單代理 Claude Opus 4 強 90.2%，但 token 用量約為一般對話的 15 倍，並點名「需要所有代理共享同一上下文、或代理之間依賴很多」的領域不適合。跨組織 A2A 剛好集齊這些不利條件：雙方不共享上下文、沒有共同的驗證者、商務流程（查價→下單→付款→出貨）又是序列型，這是推論。
工程面的空白比規格面更多。A2A 委派給下一個代理時 trace 會斷：Python SDK 只在本地建 span，沒有標準方式在代理之間傳遞 W3C Trace Context（Issue #2103）。社群 Rust SDK 回報 7 個 TCK 失敗，對照後判定是測試套件本身的缺陷；同一份回報說 JS、Go、Java SDK 在兩種綁定上都是 21/21 通過。消費端的代理流量也還小：HUMAN Security 統計 2025 年代理流量年增 7,851%，但只有 2.3% 發生在結帳頁；二手來源引用 Cloudflare Radar 2026 年 8 月資料，AI 機器人約占 HTML 請求 7%，其中「代使用者即時行動」只占 5.8%，兩者相乘約 0.4%，這個乘算是推論、尚未用原始資料確認。Akamai 則警告電商網站對 90% 以上的 AI 機器人只做監控，同時詐欺型代理活動在增加。研究筆記沒有找到 ChatGPT、Gemini、Claude 等個人代理用 A2A 呼叫一般企業代理的證據，但這只是缺乏反證，不是官方確認。
政府與國際組織的訪談則顯示需求是真的。OECD Artificial Intelligence Papers No. 65 第 16 頁記錄，受訪的實務工作者偏好開放協議，並指出 A2A 等代理對代理通訊協議是多代理協調的重要推手，同時擔心被單一供應商的生態綁住。
| 說法或案例 | 實際查到的證據 | 判讀 |
|---|---|---|
| Linux Foundation：150 多個組織、多產業生產部署 | 新聞稿未點名使用者、無成效指標 | 廠商宣稱 |
| Tyson Foods 供應鏈案例 | apis.io A2A Agent Card 分數 0/8；對夥伴仍用 EDI 與 API | 證據不支持 |
| Microsoft Agent Framework、Google codelab | 程式範例，不是部署報告 | 非生產案例 |
| 公開註冊中心 50 個宣稱支援的代理（2026-04） | 約 0–2 個有效卡片，0 個正確回應 task | 第三方實測 |
| 18 個組織、36 個請求（2026-10-27） | 0 張卡片（樣本自選） | 第三方實測 |
| 同一雲平台內互通 | AWS AgentCore、Microsoft Foundry、Google Agent Registry 已提供 | 目前實際在跑的形態 |
依據來源 Linux Foundation：A2A 一週年新聞稿（2026-04-09）| Microsoft DevBlogs：A2A v1 in Agent Framework for .NET| Google Codelabs：A2A purchasing concierge| apis.io：Tyson Foods| heym.run：A2A vs MCP 實測| Cemri et al., Why Do Multi-Agent LLM Systems Fail?（NeurIPS 2025 D&B）| Kim et al., Towards a Science of Scaling Agent Systems（arXiv:2512.08296）| Google Research 部落格（2026-01-28）| Anthropic Engineering：How we built our multi-agent research system| A2A Issue #2103（trace 斷鏈）| a2a-rust PR #180（TCK 結果）| HUMAN Security：2026 State of AI Traffic| PaidHosting：AI agent traffic（引用 Cloudflare Radar）| Akamai 新聞稿| OECD Artificial Intelligence Papers No. 65
各國政府怎麼規範 AI 代理？有提到 A2A 嗎？
截至 2026-10-31，台灣數位發展部、新加坡 IMDA、OECD 的官方文件已直接點名 A2A 或多代理風險，但沒有任何國家針對 A2A 立法；台灣《人工智慧基本法》於 115-01-14（2026-01-14）公布施行、主管機關為國科會，代理出錯時的責任分配要等第 17 條授權的配套規範。
台灣：《人工智慧基本法》共 20 條，第 3 條把人工智慧定義為「具自主運行能力之系統」，可以涵蓋 AI 代理，但法條沒有出現「代理」兩字；第 4 條列出七大原則，包括人類自主與監督、透明與可解釋、問責；第 16 條由數位發展部推動與國際介接的風險分類框架；第 17 條要求政府明定高風險 AI 的責任歸屬及歸責條件，並建立救濟、補償或保險機制；第 18 條要求各機關在施行後二年內完成相關法規調整。數位發展部依第 16 條於 115-07-07 公告《人工智慧風險分類框架》v1.0（數位策略字第 1150015933 號，自即日生效），其中風險類型 B6「AI 自主代理之授權外行為」寫明：「多代理系統更可能因代理人間相互觸發，產生開發者與使用者均未預期的連鎖反應，使人類難以及時介入糾正。」衛福部 115-05-29 函頒的醫療機構生成式 AI 指引，則明確把 AI 代理系統「尚不列入本指引之適用對象」。
台灣既有法律也適用代理情境。《個人資料保護法》第 4 條規定受委託蒐集、處理或利用個資者，在本法適用範圍內視同委託機關，因此把個資交給代理處理不會因為「是 AI 在做」而免責；第 21 條規範國際傳輸限制。要注意 114-11-11 修正的多個條文（含第 21 條新版與增訂第 20-1 條）已公布、尚未施行，施行日期由行政院定之。《電子簽章法》沒有提到 AI 或代理，代理代為簽署能否推定為本人簽署，法無明文、本文無法證實。
中國：國家市場監督管理總局與國家標準化管理委員會以 2026 年第 22 號國家標準公告，於 2026-05-22 批准發布 GB/Z 185.1～185.7-2026《人工智能 智能體互聯》系列共 7 份指導性技術文件（總體架構、身分碼、身分管理、智能體描述、智能體發現、智能體交互、智能體工具調用），全國標準信息公共服務平台標示狀態為「現行」，全文於 2026-06-18 公開，市場監管總局另於 2026-06-26 召開專題新聞發布會。官方文件使用的協議名稱是 AIP（智能體互聯協議），查到的官方頁面都沒有提到 A2A 或 MCP，兩者是否相容未經證實。2026-05-08 國家網信辦、國家發展改革委、工業和信息化部聯合印發的《智能體規範應用與創新發展實施意見》，則把 AIP 推廣、智能體註冊平台、智能體數字身分綁成一套，並要求「智能體執行操作不得超出用戶授權範圍」。這條路線與 A2A 社群「官方不提供註冊中心」不同。
歐盟：AI Act（Regulation (EU) 2024/1689）2024-08-01 生效，通用目的 AI 模型義務自 2025-08-02 適用，一般適用與透明義務自 2026-08-02 起；高風險義務已由 Regulation (EU) 2026/1744（2026-07-24 刊登 Official Journal）延後，附件 III 延至 2027-12-02、附件 I 延至 2028-08-02。PSD3 與 PSR 則是理事會 2026-10-29 通過第一讀立場，尚待歐洲議會二讀，未刊登 Official Journal。
美國、新加坡、英國：CISA 與 NSA 等五眼機關在 2026-04-30／05-01 發布〈Careful Adoption of Agentic AI Services〉，建議限制存取權限、從低風險且非敏感的用例開始；美國 CFPB 沒有針對代理支付的指引，2025 年的相關解釋性規則提案已於 2025-05-15 撤回。新加坡 IMDA《Model AI Governance Framework for Agentic AI》v1.5（2026-05-20 發布、06-05 更新）第 1.1.1 節直接點名 A2A 用於代理之間的溝通、MCP 用於代理與工具的溝通，並指出遞迴委派與跨組織身分是目前的缺口。英國 CMA 2026-03-09 發布（10-30 更新）的指引寫明「if an AI agent you use does something illegal, you are responsible」，也就是業者要為自己使用的代理違法行為負責；英國 ICO 對代理式 AI 的公開徵詢到 2026-11-20 截止。
| 地區 | 文件 | 日期 | 與 A2A 或代理的關係 |
|---|---|---|---|
| 台灣 | 《人工智慧基本法》 | 115-01-14 公布施行 | 第 17 條要求明定高風險 AI 責任歸屬；未提「代理」 |
| 台灣 | 數位發展部《人工智慧風險分類框架》v1.0 | 115-07-07 | 風險 B6「AI 自主代理之授權外行為」 |
| 台灣 | 數位發展部《公部門人工智慧應用參考手冊》V1.0 | 115-01-28（文件記載） | 第 14 頁 A2A 小節 |
| 中國 | GB/Z 185.1～185.7-2026《人工智能 智能體互聯》 | 2026-05-22 批准發布 | 官方協議名 AIP；與 A2A 相容性未證實 |
| 歐盟 | Regulation (EU) 2026/1744 | 2026-07-24 刊登 | AI Act 高風險義務延後至 2027-12-02／2028-08-02 |
| 歐盟 | PSD3／PSR 理事會第一讀立場 | 2026-10-29 | 未刊登 Official Journal；PSR 理由書查無代理條款 |
| 美國 | NIST〈Design Tenets for Agent Identity Management Systems〉 | 2026-10-27 | 代理身分 10 條設計原則（部落格） |
| 新加坡 | IMDA 代理式 AI 治理框架 v1.5 | 2026-05-20 | §1.1.1 點名 A2A 與 MCP |
| 英國 | CMA 消費者法與 AI 代理指引 | 2026-03-09 | 業者為所用代理的違法行為負責 |
| 國際 | OECD AI Papers No. 65 | 2026-09 | 第 16 頁：實務者視 A2A 為多代理協調推手 |
依據來源 全國法規資料庫：人工智慧基本法| 數位發展部公告：人工智慧風險分類框架| 數位發展部：人工智慧風險分類框架 v1.0（PDF）| 數位發展部：公部門人工智慧應用參考手冊（PDF）| 衛生福利部：醫療機構應用生成式人工智慧指引| 全國法規資料庫：個人資料保護法| 全國法規資料庫：電子簽章法| 國家標準化管理委員會：2026 年第 22 號國家標準公告| 全國標準信息公共服務平台：GB/Z 185.1-2026| 全國標準信息公共服務平台：全文公開通知| 國際科技創新中心：智能體互聯標準化發布會| 國家市場監督管理總局：轉載報導| 中國網信網：智能體規範應用與創新發展實施意見| European Commission：AI Act regulatory framework| European Parliament：Digital Omnibus on AI| 歐盟理事會 PSD3 投票文件 ST 15152/26| 歐盟理事會 PSR 投票文件 ST 15154/26| CISA：Secure adoption of agentic AI| Federal Register 2025-08646（CFPB 撤回）| IMDA：Model AI Governance Framework for Agentic AI v1.5| GOV.UK：CMA complying with consumer law when using AI agents| ICO：Agentic AI call for evidence| OECD Artificial Intelligence Papers No. 65
A2A v1.1 會補上什麼？還有哪些問題沒有答案？
A2A v1.1 的八個主題已由 TSC 在 2026-06-25 以 5 比 0 表決通過，涵蓋串流續傳、冪等性、推播設定、技能選擇、認證發現、任務歷史、多輪互動與雙向串流，截至 2026-10-31 尚無發布日期；代理身分、委派與計費等討論最熱的議題仍未定案。
Issue #1942 把 41 個議題整併為 v1.1 的八個主題，跨任務的代理記憶（#893）不在追蹤範圍內。比主題清單更能說明方向的是留言最多的議題：#1672 Agent Card 的代理身分驗證（約 658 則留言）、#1829 以 Ed25519 加 RFC 9421 做訊息簽章、#2028 actor-chain 委派、#2121 成本與預算傳遞、#1815 用 HTTP 402 表示「需要付款」。這些都是信任與商務問題；加上新設的 extension 治理流程，研究筆記判斷它們比較可能以擴充而非修改核心規格的方式出現，這是推論。
「個人代理怎麼找到公司代理」目前沒有已部署的開放答案。A2A 官方文件明確說策展型註冊中心不在 A2A 範圍內；Discussion #741 的 Agent Registry 提案拖了很久，審閱者質疑「由提供者自己管理登記項目」的前提。從網域找到代理的做法，IETF 有四份互相競爭的個人草案：DNS-AID（以 SVCB 記錄指向 /.well-known/agent-card.json）、AID（查 _agent TXT 記錄）、ADP、DAN，都還沒被工作組採納；2026 年 7 月的 landscape 草案也指出命名空間需要協調。MCP 這邊的 MCP Registry 從 2025 年 9 月到現在仍是預覽版。
跨組織稽核與責任同樣沒有框架。A2A 規格只有 SHOULD 層級的認證失敗記錄與限流要求，OpenTelemetry GenAI 語意慣例的穩定狀態各來源說法互相矛盾。在現有工具下，可以留存的最小稽核單位大概是：自己這側的 taskId 與 contextId、對方 Agent Card 簽章的指紋、對方出示 token 的 act 委派鏈，雙方各自保存、日後對帳，這是推論。研究筆記也沒有找到任何以「耗盡對方 LLM 預算」為目標的 denial-of-wallet 實證研究。
- #1986 串流續傳：斷線後能從中斷處接續
- #1987 冪等性：重送請求不重複執行
- #1988 推播設定：webhook 的設定與管理
- #1989 技能選擇：呼叫方如何指定要用的技能
- #1990 認證發現：事先知道要用哪種認證
- #1991 任務歷史：查詢過去任務的紀錄
- #1992 多輪互動：雙方往返提問的語意
- #1995 雙向串流：雙方同時串流資料
依據來源 A2A Issue #1942（v1.1 主題）| A2A issues（依留言數排序）| A2A：Agent discovery| A2A Discussion #741| IETF：DNS-AID 草案| IETF：DAWN discovery landscape 草案| MCP Registry preview（2025-09-08）| A2A Specification §13.4| GreptimeDB：OpenTelemetry GenAI semantic conventions
企業現在該不該導入 A2A？
依 2026-10-31 的證據，企業導入 A2A 宜採「先唯讀、先同平台、暫緩跨公司寫入」：同一雲平台內的代理互通可以試，跨公司的下單、付款類 A2A 在身分、委派與責任框架定案前不建議開放，因為序列型任務上所有多代理變體都退步 39%–70%（arXiv:2512.08296 v1／v2 數據）。
A2A 現在的狀態很像早年的 HTTP：格式已經標準化，信任層還得各自補上；差別是這次被呼叫的一方會自己推理，還可能被對方說服。因此瓶頸不在工程，而在「誰為代理的行為負責」，而這件事目前分散在 IETF（身分）、FIDO Alliance（支付意圖）、卡組織（爭議）與各國監管機關手上，A2A 的 TSC 管不到。由此推論，未來幾年跨公司代理互通最可能的形態是「A2A 的外殼，包著確定性的工具呼叫」：被呼叫的一方表面上是代理，內部其實是 API，真正的推理只在自家信任邊界內發生。
政府指引的方向與此一致。CISA 與 NSA 等五眼機關建議從低風險且非敏感的用例開始並限制存取權限；新加坡 IMDA 框架把「讓人負起實質責任」與技術控制列為核心面向；台灣數位發展部把多代理相互觸發的連鎖反應列為風險 B6；英國 CMA 則明講業者要為自己使用的代理違法行為負責。
下表把一般企業的導入選項依證據強度分級。表中「做」代表在現有證據下風險低、報酬明確；「可做」代表成本低但沒有量測案例；「暫緩」與「不要做」都附上理由，等觸發條件出現再重新評估。
| 建議 | 行動 | 理由 |
|---|---|---|
| 做 | 授權自己實作並預設拒絕，不依賴 SDK 預設值 | 規範說授權由實作決定；a2a-java 曾預設不做讀取授權（CVE-2026-111764） |
| 做 | 把 Agent Card 欄位與推播 URL 一律當成不可信輸入，推播 URL 拒絕私有 IP | 卡片可指定 header 名稱；a2a-java 與 a2a-python 都出過推播 SSRF |
| 做 | 記錄 taskId、contextId、呼叫方身分與 traceparent | 跨代理 trace 會斷（Issue #2103），事後只能靠雙方各自的紀錄對帳 |
| 做 | 固定 SDK 版本並訂閱安全公告 | 2026 年 8–10 月已有多個官方 SDK CVE，修補曾被平台差異繞過 |
| 可做 | 同一雲平台內的代理互通（AWS AgentCore、Microsoft Foundry、Google Agent Registry） | 目前實際在跑的形態，雙方信任邊界相同 |
| 暫緩 | 依賴跨 SDK 的 Agent Card 簽章驗證 | Issue #2122 正規化不一致；簽章只證明完整性、不證明身分 |
| 不要做 | 讓外部代理代客下單、改資料或付款 | AP2 不分配責任、卡組織沒有代理專屬爭議規則、PSR 查無代理條款 |
| 不要做 | 為了 A2A 自建跨組織多代理後端 | 獨立式多代理錯誤放大 17.2 倍；序列任務退步 39%–70% |
依據來源 Kim et al., Towards a Science of Scaling Agent Systems（arXiv:2512.08296）| CISA：Secure adoption of agentic AI| IMDA：Model AI Governance Framework for Agentic AI v1.5| 數位發展部：人工智慧風險分類框架 v1.0（PDF）| GOV.UK：CMA complying with consumer law when using AI agents| GitHub Advisory GHSA-qw47-mcm5-934w| A2A Issue #2103| A2A Issue #2122| AP2 v0.2 Specification
跨境電商與物流業者現在該怎麼準備 A2A？
跨境電商與物流業者在 2026 年最值得投資的不是 A2A 端點，而是網頁結構化資料與確定性、唯讀的 MCP 工具：二手來源引用 Cloudflare Radar 2026 年 8 月資料，AI 機器人約占 HTML 請求 7%，其中代使用者即時行動只占 5.8%，而 Flexport 讓客戶 AI 助理訂艙走的也是 MCP。
跨境電商與物流的核心查詢——運費多少、稅費多少、這個商品的稅則號別與輸入規定是什麼——本來就是確定性計算，正是外部代理最需要、也最不容易出錯的一類服務。Anthropic 工程部落格的經驗是，改寫工具描述就讓後續代理的任務完成時間減少 40%；OpenAI 把 Instant Checkout 改回商家 Apps 的經驗則說明，交易最後仍會回到商家自己的流程。所以業者的準備順序應該是：先讓網頁與結構化資料讀得到、再把確定性工具做成 MCP、在工具回應中附上接續網址把交易導回自家流程，最後才考慮 A2A 占位。
A2A 占位卡的意思是：在 /.well-known/agent-card.json 發布一張卡片，skills 對應既有的報價、稅費、流程等確定性工具，背後直接呼叫程式而不跑 LLM。這個做法成本低、屬於「選擇權價值」，但目前沒有任何中小企業因此獲得流量或營收的量測案例，屬推論。真要開放 A2A 端點，至少要做到：只開唯讀技能、不信任對方卡片的任何欄位、推播 URL 拒絕私有 IP、紀錄 taskId、contextId、呼叫方身分與 traceparent。
好運器目前的做法（以下皆可在好運器開發者頁面查證）：好運器提供免金鑰、免 OAuth 的公開 MCP（https://0523.tw/mcp/public），內含 8 支唯讀、冪等的工具，涵蓋好運器品牌與服務介紹、中國→台灣集運運費試算（海快／空運）、台灣進口稅費試算、商品名稱查 CCC 稅則候選、CCC 稅則稅率與輸入規定、台灣段配送超材費、集運流程與簡易申報規定，每個 IP 每分鐘 120 次，並已登錄官方 MCP Registry（名稱 tw.0523/lucky-public）；運費試算的回應附有接續網址（continue_url），讓使用者回到官網繼續。會員 MCP（https://0523.tw/mcp）則以 OAuth 2.1 授權，提供 6 支唯讀工具，只能讀取授權會員本人的帳單、包裹、預報、稅單與進口報單，預設每分鐘 60 次、每日 5,000 次。好運器開發者頁面目前列出的入口是會員資料 API、會員 MCP 與公開 MCP，沒有 A2A 端點；本文不代表好運器已支援 A2A。
如果你是想讓 AI 助理幫你估算中國寄台灣的成本，可以直接用網頁版的集運運費試算、進口關稅計算機與稅則查詢；工具與公開 MCP 使用同一套計算邏輯，試算僅供參考，運費以入倉丈量後帳單為準、稅費以海關核定為準。
| 優先序 | 行動 | 建議 | 理由 |
|---|---|---|---|
| 1 | 持續強化網頁內容與 schema.org 結構化資料 | 做 | 代理接觸網站的主要方式仍是瀏覽與抓取；代使用者即時行動的流量占比很小 |
| 2 | 把報價、稅費、稅則等功能做成確定性、唯讀的 MCP 工具，打磨工具描述 | 做 | 改寫工具描述讓代理完成時間減少 40%；物流業代理訂艙走 MCP |
| 3 | 工具回應附接續網址，把交易導回自家流程 | 做 | Instant Checkout 已改回商家 Apps，交易回到商家自己的頁面 |
| 4 | 會員資料介面維持 OAuth，加上每個用戶端的限流與稽核日誌 | 做 | 規範把授權交給實作；Akamai 警告詐欺型代理增加 |
| 5 | 發布 /.well-known/agent-card.json 占位卡，背後只接確定性程式、不跑 LLM | 可做（低優先） | 成本低、屬選擇權價值；尚無量測案例（推論） |
| 6 | 開放 A2A 端點 | 有條件做 | 只開唯讀；不信任卡片欄位；推播 URL 拒絕私有 IP；完整記錄（對應已公開的 SSRF 與 fail-open CVE） |
| 7 | 簽署 Agent Card | 暫緩或只用單一 SDK | Issue #2122 跨 SDK 正規化不一致 |
| 8 | 開放外部代理下單、改地址、付款 | 不要做 | 責任框架未定；序列型任務多代理退步 39%–70% |
| 9 | 為了 A2A 自建多代理後端，或接 AP2／x402 收取運費 | 不要做 | x402 真實商務量很小；查無運費結算實例 |
好運器開發者平台：公開 MCP 與會員 MCP ・ 集運 MCP 教學：讓 Claude、ChatGPT 查運費與稅金 ・ 集運運費試算：中國寄台灣海快、空運費用 ・ 進口關稅計算機：關稅、營業稅、貨物稅試算 ・ 稅則查詢：打中文品名查 CCC 碼與稅率
依據來源 PaidHosting：AI agent traffic（引用 Cloudflare Radar）| HUMAN Security：2026 State of AI Traffic| SupplyChain247：Flexport AI 助理訂艙| Anthropic Engineering：How we built our multi-agent research system| Digital Commerce 360（2026-03-06）| Akamai 新聞稿| A2A Specification| 好運器開發者平台（公開 MCP、會員 MCP 說明）
跨境電商與物流業者準備 AI 代理互通的 5 個步驟
1先讓網頁讀得到
把價格、時效、規則等關鍵事實寫在伺服器直出的 HTML，補上 schema.org 結構化資料；代理接觸網站的主要方式仍是瀏覽與抓取。
2把確定性功能做成 MCP 工具
報價、稅費、稅則等查詢做成唯讀、冪等的 MCP 工具，工具描述寫清楚輸入單位與限制，回應附接續網址把使用者導回自家流程。
3會員資料走 OAuth 並限流
涉及個人資料的介面只用 OAuth 授權、只回本人資料，並加上每個用戶端的限流與稽核日誌。
4評估 A2A 占位卡
若要試水溫，在 /.well-known/agent-card.json 發布只對應確定性工具、背後不跑 LLM 的卡片，上線前檢查推播 URL 與卡片欄位的輸入驗證。
5每季重測、等觸發條件
每季對 10–20 個同業或平台發送 well-known 請求；在具名夥伴書面要求、v1.1 定案或責任框架出現前，不開放下單與付款。
名詞解釋
- A2A（Agent2Agent）
- 讓分屬不同組織、不同框架的 AI 代理互相發現能力、委派任務與交換結果的開放協定，2025-06 起由 Linux Foundation 託管。
- MCP（Model Context Protocol）
- 讓 AI 助理呼叫外部工具與資源的開放協定，由呼叫端的 LLM 掌控推理，工具 schema 對呼叫方透明。
- Agent Card
- A2A 代理的公開描述檔，宣告技能、介面與認證方式，慣例放在 /.well-known/agent-card.json；簽章為選配。
- Task（任務）
- A2A 中一次協作的工作單位，taskId 由伺服器產生，有提交、處理、需要輸入、需要授權、完成、失敗等狀態。
- Extension（擴充）
- 在 A2A 核心之外加功能的機制，以 URI 識別，客戶端用 A2A-Extensions 標頭啟用，不能修改核心資料結構。
- AP2（Agent Payments Protocol）
- 以 SD-JWT mandate 記錄使用者對代理付款授權的協定，v0.2.0 於 2026-04-28 發布，2026-04-29 移交 FIDO Alliance。
- x402
- 以 HTTP 402「需要付款」狀態碼為基礎的機器對機器微付協定，主要在 Base 鏈上結算。
- RFC 8693 token exchange
- OAuth 2.0 的權杖交換標準，可用 act claim 記錄委派路徑、用 may_act 限定下一跳。
- SSRF（伺服器端請求偽造）
- 誘使伺服器向攻擊者指定位址發出請求的漏洞；A2A 的推播 webhook URL 是常見入口。
- TSC（技術指導委員會）
- A2A 的決策機構，9 席、一家公司一席，議案在 GitHub issue 上以 gitvote 表決。
- AIP（智能體互聯協議）
- 中國 GB/Z 185-2026 系列國家標準文件使用的代理互聯協議名稱，與 A2A 是否相容未經證實。
常見問題
A2A 協定是誰開發的？
A2A 由 Google 於 2025 年 4 月發表，2025-06-23 移交 Linux Foundation 託管，創始成員包含 AWS、Cisco、Microsoft 等 7 家公司；目前由 9 席技術指導委員會決策，2026 年 8 月再加入與 MCP 同一個基金會的 AAIF。
A2A 最新版本是幾版？
截至 2026-10-31，A2A 現行版本為 v1.0.1，於 2026-05-26 發布，與 2026-03-12 的 v1.0.0 線路相容；v1.1 已通過八個主題但尚無發布日期。
A2A 和 MCP 可以一起用嗎？
可以。A2A 官方的範例是代理之間用 A2A 協作、每個代理再用 MCP 操作自己的工具；兩者分別處理代理對代理與代理對工具，並不互斥。
A2A 有哪些已知安全漏洞？
2026 年 8–10 月出現第一批官方 SDK CVE，包括 a2a-java 預設不做讀取授權（CVE-2026-111764，CVSS 7.5）、a2a-python 推播 SSRF（CVE-2026-90790），另有學術研究找到 11 個規範合規也能利用的協定層漏洞。
AI 代理可以自己刷卡付款嗎？
技術上可以，Visa 2026-07-02 宣布歐洲已有代理完成購買，但交易仍用 Payment Passkeys 讓持卡人做強認證；AP2 規格不分配爭議責任，歐盟 PSR 也還沒刊登 Official Journal。
台灣有規範 AI 代理的法律嗎？
台灣《人工智慧基本法》2026-01-14 公布施行但未提「代理」；數位發展部風險分類框架 v1.0 將「AI 自主代理之授權外行為」列為風險 B6，責任歸屬待第 17 條配套規範。
好運器支援 A2A 嗎？
好運器開發者頁面目前列出的是會員資料 API、會員 MCP 與免金鑰的公開 MCP，沒有 A2A 端點；公開 MCP 提供運費、進口稅費、CCC 稅則等唯讀試算工具。
中國的智能體互聯國家標準和 A2A 一樣嗎？
不能確定。GB/Z 185.1～185.7-2026 共 7 份於 2026-05-22 批准發布，官方協議名稱為 AIP，查到的官方頁面沒有提到 A2A 或 MCP，兩者是否相容未經證實。
關鍵數據
A2A 大事記
- Google 發表 A2A，50 多家合作夥伴（二手來源）
- A2A 0.2.2：破壞性 JSON-RPC 對齊，新增 extensions
- Linux Foundation 宣布接手 A2A 專案
- A2A 0.3.0：agent.json 改名 agent-card.json，加入卡片簽章與 mTLS
- IBM ACP 併入 A2A，ACP 停止開發
- 台灣《人工智慧基本法》公布施行
- A2A v1.0.0 發布（另有論文寫 2026 年 1 月）
- AP2 v0.2.0 發布；次日 Google 將 AP2 捐給 FIDO Alliance
- 中國 GB/Z 185.1～185.7-2026 智能體互聯系列 7 份批准發布
- A2A v1.0.1 發布
- TSC 以 5 比 0 通過 v1.1 八個主題
- 數位發展部公告《人工智慧風險分類框架》v1.0，列風險 B6
- MCP 2026-07-28 版改為無狀態，Tasks 移為官方擴充
- AAIF 與 Axios 記載 A2A 加入 AAIF 的日期
- A2A 官方部落格記載加入 AAIF 的日期（與 08-17 並列）
- 官方 a2a CLI 推出
- NIST 發布代理身分管理系統 10 條設計原則部落格
- 歐盟理事會通過 PSD3／PSR 第一讀立場（尚未刊登 Official Journal）
我們持續追蹤的訊號
- 有具名的 B2B 夥伴（電商平台、承運商、倉儲或報關業者）以書面要求 A2A 對接；截至 2026-10-31 跨組織 A2A 還沒有任何具名案例，這是最強的訊號。
- ChatGPT、Gemini 或 Claude 官方宣布以 A2A 呼叫第三方商家代理；目前三家都沒有這樣做，Anthropic 也還沒有原生 A2A 支援。
- A2A v1.1 正式發布且包含認證發現（#1990）與冪等性（#1987），或代理身分、委派相關擴充正式定稿。
- Issue #2122 關閉，且 TCK 簽章測試向量在 Python、JS、Go 三個 SDK 都通過。
- 卡組織發布代理專用的 chargeback 理由碼，或歐盟 PSD3／PSR 完成歐洲議會二讀並刊登 Official Journal 且出現代理條款（截至 2026-10-31 理事會僅通過第一讀立場，PSR 理由書查無代理條款）。
- Google Agent Registry、Microsoft Agent 365 或 MCP Registry 開放跨組織公開登記，或 DNS-AID 等草案被 IETF 工作組採納。
- 中國 GB/Z 185 系列（AIP）與 A2A 的相容性或實作公開，或智能體註冊平台上線並有兩岸跨境合作方開始採用。
- 台灣依《人工智慧基本法》第 17 條訂出高風險 AI 責任歸屬規範，或《個人資料保護法》114-11-11 修正條文由行政院定施行日期。
- A2A TSC 依治理文件於成立 18 個月（約 2026 年 12 月）後調整組成。
- 每季以 well-known 請求重測 10–20 個同業或平台；只要取得的有效 Agent Card 仍是 0 張，就沒有理由追加投資。
本文提及的組織與標準
- 好運器 Q140309005
- A2A（Agent2Agent） Q133867455
- MCP（模型脈絡協定） Q133436854
- Google Q95
- Google Research Q28943742
- Linux Foundation Q858851
- Agentic AI Foundation（AAIF）
- AWS Q456157
- Amazon Q3884
- Cisco Q173395
- Microsoft Q2283
- Salesforce Q941127
- SAP Q552581
- ServiceNow Q7455653
- IBM Q37156
- Bloomberg Q13977
- Atlassian Q757307
- MuleSoft Q6933868
- Anthropic Q116758847
- OpenAI Q21708200
- Zscaler Q8074786
- Ping Identity Q85793376
- Cloudflare Q4778915
- Okta Q55627388
- Semgrep Q124512828
- Palo Alto Networks Q7128508
- FIDO Alliance Q15731702
- Chainalysis Q111939618
- Coinbase Q16972754
- Stripe Q7624104
- Shopify Q7501150
- Visa Q328840
- Mastercard Q489921
- Taylor Wessing Q1030253
- Ant International Q135234509
- Flexport Q23016856
- Tyson Foods Q1325987
- HUMAN Security Q140700188
- Akamai Q415598
- MIT（麻省理工學院） Q49108
- NeurIPS Q1961016
- IETF（網際網路工程任務組） Q217082
- W3C Q37033
- 歐盟 Q458
- 國家標準化管理委員會（中國） Q63961
- Axios Q28230873
- Forbes Q25161472
- GitHub Q364
- Claude Q118876059
- Claude Code Q138457287
- ChatGPT Q115564437
- Gemini Q116698014
- Microsoft Foundry Q141613812
- Microsoft Entra Q24833870
- AGENTS.md Q136229882
- Tempo Q140472934
- MPP（Machine Payments Protocol） Q140387814
- x402 Q139414309
- UCP（Universal Commerce Protocol） Q139500408
- AP2（Agent Payments Protocol）
- ACP（Agentic Commerce Protocol）
- Android Q94
- Java Q251
- Python Q28865
- Go Q37227
- .NET Q21622213
- Rust Q575650
- JSON-RPC Q1164443
- gRPC Q26356541
- REST Q749568
- OAuth 2.0 Q97371579
- OIDC（OpenID Connect） Q18385539
- PKCE Q47470960
- JWS（JSON Web Signature） Q22906027
- JWT（JSON Web Token） Q22284678
- RFC 8785（JCS） Q97455550
- RFC 8693 token exchange Q83682184
- RFC 9457 Q123502710
- RFC 9421 Q125295021
- Ed25519 Q56099578
- ECDSA Q915079
- OpenTelemetry Q121746046
- ACME Q20311482
- DANE Q4036847
- SVCB 記錄 Q139159304
- TXT 記錄 Q2386111
- HTTP 402 Q64728484
- EDI（電子資料交換） Q690189
- 強客戶認證（SCA） Q65089871
- schema.org Q3475322
- CVE Q94950995
- CVSS Q1024582
- webhook Q2553302
- SSRF（伺服器端請求偽造） Q56064107
- prompt injection（提示注入） Q116737628
- 路徑穿越 Q442856
- 彩虹表 Q1139146
- UTF-16 Q740701
- Passkey（通行金鑰） Q118213879
- chargeback（拒付爭議） Q3307525
- 多代理系統 Q529909
- 大型語言模型（LLM） Q115305900
- AI 代理 Q132451509
- 迷因幣 Q109536316
- Protocol Buffers（proto） Q1645574
- HTTP Q8777
- JSON Q2063
- 歐盟官方公報（Official Journal） Q480448
- NIST（美國國家標準與技術研究院）
- CISA（美國網路安全暨基礎設施安全局）
- NSA（美國國家安全局）
- CFPB（美國消費者金融保護局）
- 新加坡資訊通信媒體發展局（IMDA）
- 英國競爭及市場管理局（CMA）
- 英國資訊專員辦公室（ICO）
- OECD（經濟合作暨發展組織）
- 數位發展部
- 國家科學及技術委員會（國科會）
- 衛生福利部
- 國家市場監督管理總局（中國）
- 國家網信辦（中國）
- 歐盟理事會
- 歐盟執委會
- Unit 42
- 人工智慧基本法
- 個人資料保護法
- 電子簽章法
- 歐盟人工智慧法（AI Act）
- PSD3／PSR（歐盟支付服務指令與規則）
- GB/Z 185-2026《人工智能 智能體互聯》
- 代理式 AI 模型治理框架（IMDA）
- Chargebacks911
- Artemis
- Diginomica
- Digital Commerce 360
- TechNode
- The Paypers
- Strands Agents
- Google ADK
- Microsoft Agent 365
- Microsoft Agent Framework
- Google Agent Registry
- MCP Registry
- Okta Agent SSO
- Cloudflare Radar
- Web Bot Auth
- WIMSE
- SD-JWT
- goose
- agentgateway
- Verifiable Intent
- W3C Trace Context
- Base
參考資料
政府與官方文件
- 人工智慧基本法 總統府公布；主管機關國家科學及技術委員會 · 2026-01-14（115-01-14） 台灣 AI 框架法；第 17 條責任歸屬、第 18 條二年內調整法規
- 人工智慧風險分類框架 v1.0（數位策略字第 1150015933 號） 數位發展部 · 2026-07-07（115-07-07） 風險 B6「AI 自主代理之授權外行為」
- 人工智慧風險分類框架公告 數位發展部 · 2026-07-07 公告與生效日
- 公部門人工智慧應用參考手冊 V1.0 數位發展部 · 2026-01-28（文件記載 115-01-28） 第 14 頁 A2A 小節
- 醫療機構應用生成式人工智慧指引 衛生福利部 · 2026-05-29（115-05-29） AI 代理系統尚不列入適用對象
- 個人資料保護法 全國法規資料庫 · 現行；114-11-11 修正條文已公布、尚未施行 第 4 條受託者視同委託機關；第 21 條國際傳輸
- 電子簽章法 全國法規資料庫 · 2024-05-15（113-05-15 修正） 未規範 AI 或代理簽署
- 中華人民共和國國家標準公告 2026 年第 22 號 國家市場監督管理總局、國家標準化管理委員會 · 2026-05-22 批准 GB/Z 185.1～185.7-2026 智能體互聯系列
- GB/Z 185.1-2026 標準詳情 全國標準信息公共服務平台 · 2026-05-22 發布，現行 狀態與分類
- 關於公開 2026 年第 22 號國家標準公告中國家標準全文的通知 全國標準信息公共服務平台 · 2026-06-18 全文公開日
- 智能體互聯標準化專題新聞發布會報導 國際科技創新中心網 · 2026-06-29 2026-06-26 發布會
- 轉載《法治日報》智能體互聯標準報導 國家市場監督管理總局 · 2026-07-03 7 項標準、身分碼與 AIP
- 智能體規範應用與創新發展實施意見 國家網信辦、國家發展改革委、工業和信息化部 · 2026-05-08 AIP 推廣、註冊平台、不得超出用戶授權範圍
- AI Act regulatory framework European Commission · 持續更新 AI Act 適用時程
- Digital Omnibus on AI（Regulation (EU) 2026/1744） European Parliament Legislative Train · 2026-07-24 刊登 Official Journal 高風險義務延後至 2027-12-02／2028-08-02
- PSD3 first reading position, ST 15152/26 Council of the European Union · 2026-10-29 通過 尚未刊登 Official Journal
- PSR first reading position, ST 15154/26 Council of the European Union · 2026-10-29 通過（文件日期 2026-10-30） PSR 理由書查無代理條款
- Announcing the AI Agent Standards Initiative NIST CAISI · 2026-02-17 未點名 A2A 或 MCP
- Comments on Software and Agentic AI Identity Concept Paper NIST NCCoE · 2026-09-29 逾 600 份回應
- Design Tenets for Agent Identity Management Systems NIST（Booth、Fisher、Galluzzo、Clancy） · 2026-10-27 代理身分 10 條設計原則（部落格）
- Careful Adoption of Agentic AI Services CISA、NSA 與國際夥伴 · 2026-05-01 從低風險用例開始、限制權限
- CFPB 撤回 EFTA／Reg E 解釋性規則提案（Federal Register 2025-08646） Consumer Financial Protection Bureau · 2025-05-15 美國無代理支付官方解釋
- Model AI Governance Framework for Agentic AI v1.5 新加坡 IMDA · 2026-05-20（06-05 更新） §1.1.1 點名 A2A 與 MCP
- Complying with consumer law when using AI agents 英國 CMA · 2026-03-09（10-30 更新） 業者為所用代理的違法行為負責
- Agentic AI call for evidence 英國 ICO · 2026-10-08 至 2026-11-20 代理式 AI 公開徵詢
- Agentic AI in organisations: Early insights from practitioner interviews（AI Papers No. 65） OECD · 2026-09 第 16 頁提到 A2A
學術論文
- Why Do Multi-Agent LLM Systems Fail? Cemri, M., Pan, M. Z., Yang, S., et al.（13 位作者） · NeurIPS 2025 Datasets and Benchmarks Track（spotlight） · 2025（arXiv v3 2025-10-26） · arXiv:2503.13657
- A2ABreak: Systematic Security Analysis of the A2A Protocol Lotfi, A., Rahman, M. M., Karim, I., & Bertino, E. · arXiv 預印本 · 2026-10-24（v3） · arXiv:2609.10871
- Agent Name Collision Attacks in Multi-Agent Systems Arun Kumar, A. · arXiv 預印本 · 2026-09-23 · arXiv:2609.27624
- Towards a Science of Scaling Agent Systems Kim, Y., Gu, K., Park, C., et al.（20 位作者） · arXiv 預印本 · 2025-12-09（v1）；2026-04-08（v3，260 種配置） · arXiv:2512.08296
- From Multi-Agent Systems and the Semantic Web to Agentic AI: A Unified Narrative of the Web of Agents Petrova, T., Bliznioukov, B., Puzikov, A., & State, R. · arXiv 預印本 · 2026-05-24（v4） · arXiv:2507.10644v4
- From prompt injections to protocol exploits: Threats in LLM-powered AI agents workflows Ferrag, M. A., Tihanyi, N., Hamouda, D., Maglaras, L., Lakas, A., & Debbah, M. · ICT Express, 12, 353–383 · 2026 · DOI 10.1016/j.icte.2025.12.001
- Multi-Agent Systems Execute Arbitrary Malicious Code Triedman, H., Jha, R., & Shmatikov, V. · COLM 2025 · 2025 · arXiv:2503.12188
- Authenticated Delegation and Authorized AI Agents South, T., Marro, S., Hardjono, T., et al. · arXiv；立場版本收錄於 ICML 2025 Position Paper Track · 2025-01-16 · arXiv:2501.09674
- Visibility into AI Agents Chan, A., Ezell, C., Kaufmann, M., et al. · FAccT '24, 958–973 · 2024-06-03 · DOI 10.1145/3630106.3658948
- A Formal Analysis of Agent Payment Protocols Jiang, K., Yu, M., Chang, Y., et al. · arXiv 預印本 · 2026-08-30 · arXiv:2609.00060
- Whispers of Wealth: A Systematic Red-Teaming Study of the Agent Payments Protocol (AP2) Debi, T., Zhu, W., & Gupta, P. S. · IEEE IMNS 2026, 1–6 · 2026-08 · DOI 10.1109/IMNS67862.2026.11655291
規格與產業來源
- A2A Specification A2A Project（Linux Foundation） · v1.0.1，2026-05-26
- What's new in A2A v1 A2A Project · 2026
- A2A CHANGELOG a2aproject/A2A（GitHub） · 2025-05 至 2026-05
- A2A GOVERNANCE.md a2aproject/A2A（GitHub） · 截至 2026-10-31
- A2A and MCP A2A Project · 截至 2026-10-31
- A2A Extensions A2A Project · 截至 2026-10-31
- A2A Announcements A2A Project · 2026-08-27、2026-10-01 等
- Issue #1942：v1.1 主題整併 a2aproject/A2A（GitHub） · 2026-06-25 表決
- Issue #2122：簽章正規化差異 a2aproject/A2A（GitHub） · 2026-08-10 開立
- Linux Foundation Launches the Agent2Agent Protocol Project Linux Foundation · 2025-06-23
- A2A Protocol Surpasses 150 Organizations Linux Foundation · 2026-04-09
- A2A joins AAIF Agentic AI Foundation · 2026-08-17
- MCP 2026-07-28 changelog Model Context Protocol · 2026-07-28
- MCP 2025-11-25 changelog Model Context Protocol · 2025-11-25
- AP2 Specification v0.2 AP2 Project · 2026-04-28
- Google donates Agent Payments Protocol to FIDO Alliance FIDO Alliance · 2026-04-29
- AgentCore Runtime A2A protocol contract Amazon Web Services · 截至 2026-10-31
- How we built our multi-agent research system Anthropic Engineering（工程部落格） · 2025-06-13
- Towards a science of scaling agent systems Google Research 部落格 · 2026-01-28
- A security engineer's guide to the A2A protocol Semgrep · 2025
- Agent session smuggling in Agent2Agent systems Unit 42（Palo Alto Networks） · 2025
- x402 agentic payments adoption Chainalysis · 2026
- Visa 歐洲代理購買新聞稿 Visa · 2026-07-02
- OpenAI shifts checkout plans Digital Commerce 360 · 2026-03-06
- A2A vs MCP（Agent Card 實測） heym.run · 2026-10-27 更新
- Web Bot Auth Cloudflare Docs · 截至 2026-10-31
- draft-klrc-aiagent-auth IETF Datatracker · 截至 2026-10-31
- Flexport AI assistants freight booking SupplyChain247 · 2026
最後更新 首次發布
本文為技術研究整理，不構成法律、資安或投資建議；規格與法規以各機關與專案最新公告為準。