AI Agent 協議戰爭：MCP、A2A 與決定代理式 AI 未來的標準之爭

2026 年 2 月 17 日，美國國家標準暨技術研究院（NIST）宣布成立 AI Agent 標準計畫（AI Agent Standards Initiative），聚焦產業主導標準、開源協議開發與代理安全研究三大支柱。^[1]六天前的 2 月 13 日，Google Chrome 146 Canary 版本內建了 WebMCP——這意味著全球數十億的網頁將可直接作為 AI Agent 的結構化工具。^[2]更早之前的 2025 年 12 月，Anthropic 將其 Model Context Protocol（MCP）捐贈給 Linux 基金會新成立的 Agentic AI Foundation（AAIF），共同創辦者包括 OpenAI、Block 等巨頭，白金會員涵蓋 AWS、Google、Microsoft、Bloomberg 與 Cloudflare。^[3]MCP 的 Python 與 TypeScript SDK 月下載量已突破 9,700 萬次；Google 的 Agent-to-Agent Protocol（A2A）獲得超過 100 家企業支持。^[4]這些事件不是獨立發生的——它們共同標誌著 AI Agent 生態系正在經歷一場與 1980 年代 TCP/IP vs OSI「協議戰爭」結構性相似的歷史轉折。在那場戰爭中，草根驅動的 TCP/IP 擊敗了國際標準組織精心設計的七層 OSI 模型，奠定了今日網際網路的基礎架構。四十年後，誰制定 AI Agent 的通訊標準，誰就將掌握代理式 AI 時代的基礎設施控制權。這不僅是一個技術問題——它是一場地緣政治、產業戰略與治理哲學的多維博弈。

一、協議的 Bretton Woods 時刻：NIST 的歷史性宣告

NIST 的 AI Agent 標準計畫不是一般的技術公告——它是美國聯邦政府首次以國家級力量介入 AI Agent 的互通性標準制定。計畫書開宗明義地宣示，CAISI（NIST 的 AI 標準協調機構）的目標是「鞏固美國在代理式 AI 技術前沿的主導地位」。^[1]計畫設定了三大支柱：第一，推動產業主導的開源協議標準；第二，建立 AI Agent 安全與身份認證的研究議程；第三，協調跨部門的監管框架。具體而言，NIST 發出了兩項緊急徵求意見書（RFI）：Agent Security 的截止日為 2026 年 3 月 9 日，Agent Identity 的概念文件將於 4 月 2 日發布。

將這個宣告放在歷史脈絡中，它的意義更加清晰。1944 年的布雷頓森林會議為戰後國際金融秩序奠定了基礎——美元成為全球儲備貨幣，國際貨幣基金組織與世界銀行應運而生。NIST 的宣告在某種意義上扮演了類似的角色——它試圖為 AI Agent 的互通性建立一個以美國為中心的秩序框架。這不是偶然的：當 Gartner 預測 2026 年底將有 40% 的企業應用程式內建 AI Agent（相較 2025 年不到 5%），AI Agent 的「基礎管道」就如同 1990 年代的 HTTP/TCP/IP 一樣，成為了戰略性的基礎設施。^[5]

然而，與布雷頓森林不同的是，AI Agent 的標準制定不是在一個由政府主導的封閉會議室中進行——它是在開源社群、科技巨頭、創投資本與監管機構之間的多方博弈中展開的。Linux 基金會的 Agentic AI Foundation 已經搶先一步：其創始白金會員名單讀起來像是矽谷的「誰是誰」——Anthropic、OpenAI、AWS、Google、Microsoft、Cloudflare、Block、Bloomberg、Intuit、Replit、Samsung、PayPal、Salesforce、SAP。^[3]首批專案包括 MCP（Anthropic 捐贈）、A2A（Google 捐贈）、AGENTS.md（OpenClaw 的 Steinberger 主導）與 goose（Block 貢獻）。這個陣容表明：AI Agent 的標準之爭不是一場零和遊戲，而是一場「競合」（co-opetition）——競爭者在標準層面合作，在應用層面競爭。

二、TCP/IP vs OSI 的歷史啟示：草根標準如何擊敗委員會設計

要理解當前 AI Agent 協議戰爭的走向，最具啟發性的歷史先例是 1980 年代到 1990 年代的 TCP/IP vs OSI 之爭。^[7]

1978 年，國際標準組織（ISO）開始設計 OSI（Open Systems Interconnection）參考模型——一個精緻的七層網路架構，旨在成為全球通訊的統一標準。OSI 由政府支持、電信巨頭推動、國際委員會設計，擁有當時最權威的制度背書。與此同時，TCP/IP 則是由 DARPA（美國國防高等研究計畫署）資助、大學研究者開發的一個「夠用就好」的四層協議。它沒有 OSI 的優雅分層，沒有委員會的精心設計，也沒有國際組織的官方認證。但它有一個 OSI 缺乏的關鍵優勢：一個可以執行的實作（running code）。

TCP/IP 的勝出歸因於三個結構性特質。第一，簡潔性：TCP/IP 的四層架構比 OSI 的七層模型更容易理解、實作與除錯。複雜性是標準採用的天敵——每多一層抽象，就多一層實作障礙。第二，可執行性：TCP/IP 遵循的是「先有實作，再有規範」的 IETF 哲學——RFC（Request for Comments）文件不是從理論出發的規範設計，而是對已經運行的實作的文件化描述。相反，OSI 花了數年設計規範，然後再嘗試實作——結果發現許多設計在實務中不可行。第三，開放性：任何人都可以提交 RFC、實作協議、參與討論。OSI 的標準制定過程則限於官方委員會成員，速度緩慢且政治化。

這個歷史對 AI Agent 協議戰爭的啟示是深刻的。MCP 和 A2A 正在重演 TCP/IP 的模式——它們是開源的、社群驅動的、迭代演化的協議，由實際的使用案例推動，而非由委員會設計。MCP 的月下載量 9,700 萬次不是政策命令的結果，而是開發者社群「用腳投票」的結果。^[3]相較之下，歐盟 AI 法案（EU AI Act）中關於 AI Agent 互通性的條款——雖然出發點正確——面臨著成為「AI 時代的 OSI」的風險：由上而下、設計精密、但可能與實務脫節。TechPolicy.Press 的分析直言：歐盟 AI 法案第 73 條的草案指引「暴露了令人擔憂的準備不足」——它缺乏處理多 Agent 事故、跨系統責任歸屬與代理信任鏈的工具。^[8]

在我過去研究數位主權與國際技術治理的經驗中，我反覆觀察到一個規律：在技術標準的演化中，「最早形成網路效應的標準」往往勝出，而非「設計最完善的標準」。VHS 擊敗 Betamax、Windows 擊敗 OS/2、TCP/IP 擊敗 OSI——每一次，市場採用速度都勝過了技術優越性。MCP 已經在這場競賽中搶佔了先機，但歷史也警告我們：先發優勢不是永久優勢——AOL 曾經是網際網路的代名詞，MySpace 曾經是社群媒體的霸主。關鍵在於協議能否持續演化以回應新的需求，而不是凍結在初始設計中。

三、三層協議架構：MCP、A2A 與 WebMCP 的互補生態

截至 2026 年 2 月，AI Agent 的協議架構正在結晶為三個互補的層次，每一層解決不同的通訊需求。

第一層：MCP（Model Context Protocol）——Agent 對工具的標準介面。Anthropic 在 2024 年 11 月首次發布 MCP，將其定位為「AI 的 USB-C」——一個讓 AI Agent 能夠連接到任何外部工具、資料來源或服務的標準化介面。^[3]就像 USB-C 讓你的筆電能夠連接到顯示器、硬碟或充電器而不需要不同的接頭，MCP 讓 AI Agent 能夠呼叫資料庫查詢、API 呼叫、檔案操作或網頁瀏覽而不需要為每個工具撰寫客製化的整合程式碼。MCP 的 Python 與 TypeScript SDK 月下載量突破 9,700 萬次，這個數字的意義在於：它表明 MCP 已經從「一家公司的協議」演化為「整個生態系的基礎設施」。Anthropic 將 MCP 捐贈給 Linux 基金會，正是為了加速這個從私有到公共的轉變——就像 Google 將 Kubernetes 捐贈給 CNCF（Cloud Native Computing Foundation）一樣，捐贈不是放棄控制，而是通過放棄獨佔來獲取更大的生態系影響力。

第二層：A2A（Agent-to-Agent Protocol）——Agent 對 Agent 的通訊標準。Google 在 2025 年 4 月發布 A2A，解決的是 MCP 沒有涵蓋的問題：當多個 AI Agent 需要互相協作——例如一個負責客服的 Agent 需要將技術問題轉交給一個負責工程支援的 Agent——它們之間如何溝通？^[4]A2A 定義了 Agent 之間的能力發現（capability discovery）、任務委派（task delegation）、狀態同步（state synchronization）與安全認證（authentication）的標準化流程。發布時即有超過 50 家企業支持，包括 Salesforce、SAP、PayPal 與 ServiceNow；截至 2026 年 2 月，支持企業已超過 100 家。IBM 原本獨立開發的 ACP（Agent Communication Protocol）在 2025 年底宣布合併入 A2A，進一步鞏固了 A2A 在 Agent 間通訊層的主導地位。

第三層：WebMCP——Agent 對網頁的結構化存取。這是最新的一層，也是最具革命性的一層。2026 年 2 月 13 日，Google Chrome 146 Canary 版本內建了 WebMCP 的早期預覽版（Early Preview Program）。^[2]WebMCP 在瀏覽器中暴露了一個 navigator.modelContext API，讓 AI Agent 能夠以結構化的方式存取網頁內容——而不是像過去那樣依賴截圖（screenshot）或 HTML 解析。Google 的數據顯示，WebMCP 相較於截圖方法，Token 效率提升了 89%。這個數字的意涵是深遠的：它意味著 AI Agent 與網頁互動的成本將大幅下降，使得大規模的網頁自動化操作在經濟上變得可行。WebMCP 由 Google 與 Microsoft 聯合開發——兩大瀏覽器引擎（Chromium 與 Edge）的合作，幾乎確保了這個標準將獲得主流瀏覽器的普遍支持。

這三層協議的互補關係，可以用一個企業場景來說明。想像一個 AI Agent 被指派為一位高管處理一個跨部門的採購決策：Agent 使用 MCP 連接到 ERP 系統查詢庫存數據、連接到 CRM 查詢供應商歷史記錄、連接到財務系統檢查預算餘額。當 Agent 發現需要法務部門的合規審查時，它使用 A2A 將審查任務委派給法務部門的 AI Agent，並即時同步任務狀態。當 Agent 需要檢查供應商的最新報價（只發布在供應商的網站上），它使用 WebMCP 以結構化的方式存取網頁內容，而不是模擬人類的瀏覽器操作。三層協議各司其職，共同構成了一個完整的代理式 AI 通訊基礎設施。

Deloitte 在其 2026 年企業 AI 報告中指出了這個三層架構的治理挑戰：目前 23% 的組織已經在中度使用代理式 AI，預計兩年內將攀升至 74%。^[9]但「Agent 蔓延」（agent sprawl）——不同部門使用不同協議、不同框架、不同 AI 模型的 Agent——已成為 CTO 們的首要擔憂。在沒有統一的協議標準下，企業面臨的不是「太少 AI Agent」的問題，而是「太多不兼容的 AI Agent」的問題——這正是標準化的經濟理由。

四、OpenClaw 的架構啟示：為什麼互通性決定了 AI Agent 的成敗

OpenClaw 的爆發式成長——GitHub Stars 超過 14.5 萬、Forks 超過 2 萬——不僅是一個開源專案的成功故事，更是一個關於互通性為何至關重要的活生生案例研究。^[10]

OpenClaw 的架構設計是一個多層協議整合的典範。最底層是 MCP 工具層——OpenClaw 從一開始就原生支援 MCP，使得 Agent 可以連接到任何符合 MCP 標準的外部工具。中間層是 Channel Adapters——OpenClaw 支援 LINE、Slack、Discord、Telegram 等多種通訊平台，每個平台都有一個標準化的適配器。最上層是 Gateway——一個統一的入口點，負責路由、認證與任務分配。這個架構的成功之處在於：OpenClaw 不需要為每個工具或平台撰寫客製化的整合——它依賴標準化的協議層來處理異質性。

OpenClaw 創辦人 Peter Steinberger 主導的 AGENTS.md 規範，成為了 Agentic AI Foundation 的首批專案之一。^[3]AGENTS.md 定義了一種標準化的方式，讓 AI Agent 能夠在一個程式碼庫中宣告自己的能力、限制與互動規則——就像 robots.txt 告訴搜尋引擎的爬蟲如何索引一個網站，AGENTS.md 告訴 AI Agent 如何與一個專案互動。這個看似微小的標準化努力，實際上解決了一個核心問題：在一個多 Agent 的世界中，Agent 如何「了解」彼此的能力？

2026 年 2 月 15 日，Steinberger 宣布加入 OpenAI，同時將 OpenClaw 移交給一個獨立基金會。^[10]這個動作的戰略意義在於：它表明開源 AI Agent 生態系與商業 AI 平台正在通過共享標準匯流。Steinberger 不是「被收購」——他是帶著開源社群的經驗，進入了全球最大的 AI 公司之一，而 OpenClaw 繼續作為獨立的開源專案存在。這個模式與 Brendan Eich（JavaScript 的創造者）從 Netscape 到 Mozilla 的軌跡有結構性的相似：個人創造者離開原始專案，專案移交給社群治理的基金會，創造者在新的機構中推動技術的更大規模採用。

然而，互通性的缺失正在成為 AI Agent 專案的首要失敗原因。Gartner 預測，超過 40% 的 Agentic AI 專案將在 2027 年底前被取消——原因包括成本失控、商業價值不明確與風險管控不足。^[6]在這三個原因中，互通性缺失是一個共同的底層因素：當不同的 Agent 使用不同的協議、不同的身份認證機制、不同的任務描述格式時，整合成本呈指數級增長，商業價值難以實現，而安全風險在每個協議邊界都會被放大。Deloitte 的報告直接指出，「Agent 蔓延」——企業內部不同部門各自部署不相容的 AI Agent——是導致專案失敗的首要組織因素。^[9]

在我帶領超智諮詢協助企業部署 AI 系統的實務經驗中，互通性問題的嚴重性遠超大多數技術報告所描述的。一個典型的中大型企業在 2026 年可能同時使用 Salesforce 的 Agentforce（A2A 原生支持）、Microsoft 的 Copilot Studio（MCP + 自有協議）、Google 的 Vertex AI Agent（A2A 原生支持）與內部開發的自定義 Agent（可能使用 LangChain 或其他框架）。讓這些 Agent 互相溝通、共享狀態、協調任務，是一個工程挑戰——但也是一個治理挑戰。正如我在分析台灣 AI 治理框架時所強調的，技術標準的缺失不僅增加了技術成本，更製造了治理真空——當沒有人知道 Agent A 是否有權要求 Agent B 存取某個數據庫時，安全審計就變成了一場猜謎遊戲。

五、協議安全的致命盲區：東西向流量與新型攻擊面

AI Agent 協議的快速採用，正在創造一個傳統網路安全架構無法有效防護的新型攻擊面。Security Boulevard 在 2026 年 2 月的深度分析將其命名為「東西向流量問題」（East-West Traffic Problem）。^[11]

傳統的企業網路安全主要關注「南北向」流量——即外部（互聯網）與內部（企業網路）之間的通訊。防火牆、WAF（Web Application Firewall）、IDS/IPS 等安全工具都是為了監控和過濾這個方向的流量而設計的。但 AI Agent 之間的通訊（透過 A2A 協議）產生的是「東西向」流量——Agent A 在雲端服務 X 中呼叫 Agent B 在雲端服務 Y 中的功能，這個通訊路徑完全繞過了傳統的安全邊界。它發生在企業的網路安全工具的「盲區」中——既不是外部攻擊，也不是典型的內部存取，而是一種全新的、橫跨多個系統的自主通訊。

更令人擔憂的是，即使是協議設計者自身的實作也存在嚴重的安全漏洞。Solo.io 的安全研究團隊在 Anthropic 自家的 Git MCP 伺服器中發現了三個遠端程式碼執行（RCE）漏洞——CVE-2025-68143、CVE-2025-68144、CVE-2025-68145——攻擊向量是通過 prompt injection 在 MCP 工具呼叫中嵌入惡意指令。^[12]這個發現的諷刺之處在於：MCP 的設計者 Anthropic 自己的 MCP 伺服器實作就存在其協議試圖防範的安全問題。這不是對 Anthropic 的批評——它揭示的是一個結構性的挑戰：在 AI Agent 的世界中，安全的邊界不再是「輸入驗證」（input validation），而是「意圖驗證」（intent validation）。傳統的安全工具可以檢查一個 HTTP 請求是否包含 SQL 注入語法，但很難判斷一個看似正常的 MCP 工具呼叫中是否隱含了惡意的 prompt injection——因為 prompt injection 利用的是自然語言的語義模糊性，而非程式語法的結構性漏洞。

arXiv 上的一篇系統性安全威脅模型研究進一步揭示了問題的深度。^[13]研究者比較了四個主要的 AI Agent 協議——MCP、A2A、Agora 和 ANP——的安全威脅模型，識別出幾個跨協議的系統性弱點：Agent 身份欺騙（identity spoofing）、能力聲明偽造（capability declaration forgery）、任務鏈汙染（task chain poisoning）與信任圖攻擊（trust graph attacks）。其中「信任圖攻擊」尤為危險：在一個多 Agent 環境中，如果 Agent A 信任 Agent B，而 Agent B 信任 Agent C，那麼一個被入侵的 Agent C 可以透過信任鏈間接操控 Agent A——而 Agent A 在整個過程中完全不知道 Agent C 的存在。這種「級聯信任失敗」（cascading trust failure）在分散式系統中是一個已知的挑戰，但在 AI Agent 的脈絡中它被放大了，因為 Agent 的決策不是確定性的（deterministic），而是基於概率推理的——這使得惡意行為的偵測變得異常困難。

NIST 在其 AI Agent 標準計畫中將 Agent Security 列為首要研究議程，並將 RFI 的截止日設定為 2026 年 3 月 9 日——距今不到兩週——這個緊迫的時間線本身就說明了問題的急迫性。^[1]與此同時，歐盟 AI 法案在 2026 年 8 月全面執法後，其第 73 條草案指引在多 Agent 事故的責任歸屬問題上「暴露了令人擔憂的準備不足」。^[8]當 Agent A（部署在美國的 AWS 上）呼叫 Agent B（部署在歐盟的 Azure 上）來處理一項涉及亞洲客戶數據的任務，而這個任務鏈中某處出了差錯導致數據洩露——哪個管轄區的法律適用？誰承擔責任？目前，沒有任何一個協議標準或法律框架能夠完整回答這個問題。

在我過去研究數據跨境流動立法的經驗中，跨境治理的挑戰在於：技術的演化速度遠超法律的制定速度。AI Agent 協議的安全問題重現了這個結構性矛盾——協議已經被數千萬開發者採用、數百家企業部署，但安全標準仍在 RFI 階段。這不是監管失職——它反映的是代理式 AI 技術發展的指數性速度與制度建設的線性速度之間的根本性時差。W3C 已經成立了 AI Agent Protocol Community Group，試圖在網頁標準的層面建立安全規範，但正式的 Web 標準預計要到 2026-2027 年才能完成。^[15]在此之前，AI Agent 的安全在很大程度上取決於個別開發者和企業的自律——而正如 OpenClaw 的 73 個安全漏洞所展示的，自律的效果是有限的。

在這個脈絡下，AI Agent 協議戰爭的真正賭注不僅是「哪個協議會贏」，而是「協議標準能否在安全災難發生之前成熟到足以防範系統性風險」。TCP/IP 的歷史提供了一個警醒：TCP/IP 在被大規模採用後的數十年間，不斷出現當初設計時未曾預見的安全問題——從 DDoS 攻擊到 BGP 劫持——每一次都需要事後補丁式的修補。AI Agent 協議如果重演這個歷史，後果可能更加嚴重：因為 AI Agent 不僅傳輸數據，更執行決策；不僅連接系統，更管理業務流程。協議層面的安全漏洞，在 TCP/IP 時代可能導致數據洩露，在 AI Agent 時代可能導致自主決策失控——而當這些決策涉及金融交易、醫療診斷或基礎設施管理時，其後果將遠超數據洩露的範疇。正如 Gartner 預測 40% 的 Agentic AI 專案將被取消，如果協議安全問題不能在採用的早期階段得到系統性的解決，這個取消率可能還會上升——而已經部署的系統可能在被取消之前就已經造成了無法逆轉的損害。^[6]