Agent Card 是什麼？讓 AI 代理看懂的網站規格

Agent Card 是 A2A 協定裡的一份 JSON 規格文件，放在網域根下的 well-known 路徑，用來向其他 AI 代理自我介紹：這個代理叫什麼名字、端點在哪個位址、擅長處理哪些任務、支援哪幾種傳輸方式、連線前要做哪種身分驗證，全部寫在同一份檔案裡。在 A2A 的設計中，這份卡片是伺服器端的必備文件，其他代理靠它完成「找到、評估、連線」三個動作，過程不需要人類逐案仲介。

官方文件給它的一句話定位很傳神：Agent Card 是一份 JSON 文件，扮演 A2A 伺服器的數位名片。名片的比喻抓住了兩個重點：它是主動公開的自我描述，而且篇幅有限，重點是讓對方快速判斷「要不要跟你往來」。差別在於讀它的是程式，所以欄位、型別與放置位置都由規格定死，不能像紙本名片一樣自由發揮。

定義與出場背景：A2A 協定的必備文件

Agent Card 不能脫離 A2A 協定單獨理解。A2A 規格第 8 章開宗明義寫著：A2A 伺服器「必須」提供一張 Agent Card，卡片描述伺服器的身分、能力、技能與互動要求，用戶端靠這些資訊發現合適的代理並設定互動方式。換句話說，在 A2A 的世界裡，沒有卡片的代理等於沒有對外身分，協定層次的互通從第一步就走不下去。

從資料模型的角度看，規格把 Agent Card 定義為代理的自我描述清單，內容涵蓋身分、能力、技能、支援的通訊方式與安全要求。這五個詞就是整份卡片的骨架，後面的欄位拆解會沿著它們展開。

「規格文件」與「寫給人看的頁面」差別比想像中大。給人的頁面靠視覺層次與語境補洞，標題漏了還有導覽，敘述模糊還有圖片。機器讀的規格沒有這些緩衝：欄位拼錯就是讀不到，型別不對就是解析失敗，該填的沒填就直接被排除在候選之外。做內容的人可以用一個熟悉的角度理解它：這是一份完全為機器讀者最佳化的文案，每一個字都要能在配對與連線的決策裡發揮作用，修辭與留白的空間是零。

這套協定的出身值得認識。2025 年 4 月 Google 開發者部落格的發起公告宣布推出開放的 Agent2Agent 協定，當時已有超過 50 家技術夥伴支持與貢獻，名單裡有 Atlassian、PayPal、Salesforce、SAP、ServiceNow 這類企業軟體公司。Google 在同一篇公告裡把定位講得很清楚：A2A 互補於 Anthropic 的 MCP，後者負責把工具與上下文供應給代理，前者負責讓代理之間彼此對話。公告也說明協定建立在 HTTP、SSE、JSON-RPC 這些既有標準上，比較容易與企業日常使用的 IT 系統整合。想先補齊 AI 代理的基礎概念與兩大協定的分工，可以回頭讀站上的AI Agent 實戰指南。

治理結構在兩個多月後轉手。2025 年 6 月北美開源峰會上，Google 把 A2A 捐給 Linux Foundation，依捐贈公告的說法，與 AWS、Cisco、Microsoft、Salesforce、SAP、ServiceNow 共同成立 Agent2Agent 專案，當時已有超過 100 家公司支持，AWS 與 Cisco 是最新的驗證者。到了 2026 年 4 月滿一週年，Linux Foundation 的新聞稿宣布支持組織超過 150 家，核心儲存庫在 GitHub 上累積超過 22,000 顆星，SDK 從單一 Python 實作擴增到 JavaScript、Java、Go、.NET 共五種語言。一個規格檔案能長出這樣的生態，是它值得內容工作者認真理解的原因。

它解決的問題：代理互相發現的成本

A2A 官方說明頁用一個情境說明問題：請 AI 助理規劃一趟出國旅行，背後要協調的代理可能包括機票訂購代理、飯店預訂代理、在地行程推薦代理與匯率換算代理。這四個代理可能來自不同開發者、不同框架、不同公司，誰也不認識誰。

在沒有共通協定的時候，這種組合要靠工程一對一搭建。官方文件對痛點的描述是：每一次互動都需要客製化、點對點的解決方案，製造可觀的工程負擔。每一條需要互動的代理連線，都可能要用客製、點對點的方式處理，互動關係一多，工程與維護負擔也會跟著增加。

Agent Card 是這個問題的第一塊拼圖。Google 的發起公告在說明協定運作時，把能力發現列為第一項關鍵能力：代理可以用 JSON 格式的 Agent Card 宣告自己的能力，讓用戶端代理找出最適合處理某項任務的對象，再用 A2A 與遠端代理溝通。先有標準化的自我描述，配對才有可能自動化。

拿到卡片之後，用戶端做的事可以拆成三個動作，官方指南的整理是：判斷代理的合適程度、組織請求內容、確保通訊安全。三個動作對應卡片的三個區塊。讀 skills 與 description 判斷「這個任務該不該交給它」，讀 supportedInterfaces 與輸出入模式決定「請求要長什麼樣子、送到哪裡」，讀 securitySchemes 與 securityRequirements 弄清楚「連線前要準備哪種憑證」。一張卡的品質，就看你能不能讓對方把三個動作一次做完不卡關。

配對完成之後的故事也值得知道，因為它解釋了卡片欄位為什麼長這樣。A2A 的溝通以任務為中心，發起公告的說明是，用戶端與遠端代理的溝通以任務完成為導向，任務物件由協定定義、有自己的生命週期，任務的產出稱為 artifact。代理之間以訊息交換上下文、回覆、產出與使用者指示。公告還特別點出長任務的設計：從快速任務到需要人類介入、可能耗時數小時甚至數天的深度研究，都在協定的支援範圍內。理解這個背景，就明白卡片為什麼要宣告串流與推播能力，因為長任務的狀態回報，靠的就是這兩條通道。

這裡有個容易混淆的邊界要畫清楚。MCP 與 A2A 不在同一層：MCP 讓代理呼叫工具與取得上下文，A2A 讓代理以代理的身分往來。官方說明頁強調 A2A 以代理原本的樣貌揭露代理，不做包裝，因為把代理降級成工具，會限制代理天生擅長的協商與多輪互動。Agent Card 描述的對象是「代理這個服務本體」，不是它手上的工具清單，這是它與工具型協定文件最根本的差異。

把視角從工程換到生意，發現機制的意義更直白。搜尋時代的流量入口是搜尋結果頁，網站爭的是排名與點擊。代理時代的入口正在長出來：當使用者的助理需要一項能力，它去哪裡找、憑什麼挑，就是新的分配機制。Agent Card 是服務進入這個分配機制的最低門檻，沒有卡的服務連被考慮的資格都沒有。這不代表要現在焦慮部署，而是代表這個機制值得放進雷達圖，在看見自己的客戶或合作夥伴開始用代理串接服務時，知道下一步該做什麼。

卡片內容拆解：欄位、技能與介面

進入規格細節前先給全景。v1.0 的 Agent Card 主要欄位可以分成六組：基本身分、提供者資訊、支援介面、能力設定、安全宣告與技能清單。下表整理各欄位的必填性與用途，欄位名稱保留規格的英文原名，方便對照官方文件與產生的 JSON。

欄位	必填	內容與用途
name	必填	人類可讀的代理名稱
description	必填	代理用途的說明文字，幫助使用者與其他代理理解目的
supportedInterfaces	必填	支援介面清單，依偏好排序，第一項為優先
provider	選填	服務提供者的組織名稱與網址
version	必填	代理自身的版本號
documentationUrl	選填	額外文件的網址
capabilities	必填	能力設定：串流、推播通知、擴充卡支援等
securitySchemes	選填	身分驗證方案宣告，對齊 OpenAPI 的安全方案
securityRequirements	選填	實際套用的安全要求
defaultInputModes	必填	預設接受的輸入媒體型別
defaultOutputModes	必填	預設輸出的媒體型別
skills	必填	技能清單，描述代理擅長的任務範圍
signatures	選填	卡片的數位簽章陣列
iconUrl	選填	代理圖示網址

基本身分的兩個必填欄位是 name 與 description。這兩個欄位的讀者不是人類訪客，是來探詢的代理程式：description 寫得越具體，用戶端越容易判斷這個代理適不適合手上的任務，效果類似搜尋結果裡的描述文字，只是評分的是機器。version 是必填欄位，記代理自身的版本，規格範例使用 1.0.0。

supportedInterfaces 是 v1.0 結構重組後的重頭戲。每個介面項目宣告一組位址、傳輸繫結與協定版本，規格官方支援的繫結有 JSONRPC、GRPC 與 HTTP+JSON 三種，清單依偏好排序，第一項代表優先介面。這樣的設計讓同一個代理可以同時在多個端點、多種傳輸上提供服務，呼叫端從清單裡挑一個自己支援的組合即可。介面項目裡還有一個 tenant 欄位，用於多個代理共用單一端點時的路由，這是 v1.0 因應企業多租戶場景新增的設計，每個介面各自宣告協定版本，也讓新舊版本可以並存過渡。

capabilities 是布林旗標的集合：streaming 表示支援串流回應，pushNotifications 表示支援任務更新推播，extendedAgentCard 表示通過身分驗證後可以提供內容更完整的擴充卡。這些宣告讓用戶端知道代理支援哪些互動管道，規格指出任務更新可由輪詢、串流或推播取得。

defaultInputModes 與 defaultOutputModes 以媒體型別表示代理在所有技能上的預設互動模式，個別技能可以覆寫，規格範例卡使用的輸入值是 application/json 與 text/plain，輸出值是 application/json 與 image/png。媒體型別看似工程細節，對內容型服務卻是重要的表達工具：你的代理吃純文字的描述需求、回 JSON 的結構化結果，還是能產圖，都由這組欄位宣告。

skills 是多數人最需要花心思的區塊。規格把一項技能定義為代理可以執行的特定能力或功能，每項技能有自己的識別碼、名稱、詳細描述、關鍵字標籤，以及可選的範例提示詞。關鍵字用來描述技能的能力範圍，範例則是這個技能能處理的提示或情境。換句話說，技能不是機器可呼叫的函式簽名，是一段給用戶端讀的自然語言定位：你希望別人的代理在聽到什麼樣的需求時想到你，就把那個情境寫進技能描述。

技能的寫法有幾個實用原則。標籤從使用者與對方代理的詞彙出發，描述技能的能力範圍，內部系統的模組名稱對外部讀者沒有意義。範例提示寫成可以直接投進對話的完整句子，例如規格範例卡裡的路線規劃技能，附的範例就是一個從某地址到某機場、避開收費路段的完整請求。描述裡明確寫出邊界與條件，例如只服務特定地區或只接受特定格式，讓用戶端盡早判斷代理是否合適。這些原則與寫產品頁文案的思路一致，只是受眾從人換成了代理。

安全宣告走的是 OpenAPI 的成熟路線。發起公告在設計原則裡承諾企業級的身分驗證與授權，並與 OpenAPI 的驗證方案看齊。卡片上以 securitySchemes 宣告可用的驗證方案，再以 securityRequirements 指定實際要求，技術上可以表達 API 金鑰、HTTP 驗證、OAuth 2.0、OpenID Connect 與雙向 TLS 等方案。v1.0 還現代化了 OAuth 流程，移除已被淘汰的隱式與密碼流程，加入裝置授權流程與 PKCE 支援。不只在代理層級，個別技能也可以宣告自己需要的安全方案。

規格第 8.5 節提供了一張完整的範例卡，主角是一個路線規劃代理。從範例可以讀到實務上的寫法：supportedInterfaces 依序列出 JSONRPC、GRPC、HTTP+JSON 三個介面，capabilities 同時打開串流與推播，securitySchemes 用 Google 的 OpenID Connect 端點，skills 裡的技能附上 maps、routing、navigation、traffic 這類標籤，連同具體的範例提示一起寫進卡裡。以下是保留主要欄位後的骨架。

{
  "name": "GeoSpatial Route Planner Agent",
  "description": "Provides advanced route planning, traffic analysis, ...",
  "supportedInterfaces": [
    {"url": "https://georoute-agent.example.com/a2a/v1",
     "protocolBinding": "JSONRPC", "protocolVersion": "1.0"}
  ],
  "provider": {"organization": "Example Geo Services Inc."},
  "version": "1.2.0",
  "capabilities": {"streaming": true, "pushNotifications": true},
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json", "image/png"],
  "skills": [
    {
      "id": "route-optimizer-traffic",
      "name": "Traffic-Aware Route Optimizer",
      "description": "Calculates the optimal driving route ...",
      "tags": ["maps", "routing", "navigation", "directions", "traffic"]
    }
  ]
}

放置位置與三種發現方式

卡片放哪裡是規格明定的。標準路徑是網域下的 well-known 位置：https://後面接代理伺服器的網域，再加上 /.well-known/agent-card.json，遵循 RFC 8615 對 well-known URI 的原則。RFC 8615 是網路基礎設施的老規矩，robots.txt 之後許多站點級設定檔都靠這套慣例落位，Agent Card 沿用它，等於把「到固定地址找設定」的肌肉記憶延伸到代理世界。

檔名本身有一段演化史，實作時最容易踩到新舊並存的坑。2025 年 7 月底發布的 v0.3.0 把 well-known 檔名從 agent.json 改為 agent-card.json，專案變更紀錄寫得一清二楚。v0.3.0 以前的文件可能使用舊檔名，對照資料時應先確認規格版本。同一次改版也引入了卡片簽章能力，為後面 v1.0 的正式簽章驗證鋪路。

拿到位址之後，用戶端怎麼找到卡？規格承認三種發現機制：well-known URI、註冊庫查詢，以及直接設定。well-known 適合公開代理或想在特定網域內被廣泛發現的服務，實作最單純，也最貼近自動化發現的想像。官方的代理發現指南對三種策略的取捨有完整討論，部署環境與安全需求是選擇的主要依據。

well-known 路徑的實際流程只有三步：用戶端以某種方式得知或推導出目標代理所在的網域，對該網域的 /.well-known/agent-card.json 發出 HTTP GET 請求，伺服器若存在這張卡且可存取，就以 JSON 回應。三步裡沒有註冊、沒有帳號、沒有事先申請，這是它被推薦給公開代理的原因。對服務提供方，整個「被發現」的基礎建設就是一個靜態檔案，放到對的位置就生效。

註冊庫（registry）走集中管理的路線：一個中介服務維護一批 Agent Card，用戶端依技能、標籤、提供者等條件查詢，拿到符合需求的卡片或參照。這在企業內部與公開市集都很常見，因為它支援治理與權限框架。規格也誠實標註了邊界：目前的 A2A 規格並沒有為註冊庫制定標準 API，各家的查詢介面各自設計。現實世界的實例是 Google Cloud 的 Agent Registry，官方文件說明它支援 A2A 規格的 0.3 與 1.0 兩個版本，註冊後代理成為可發現的元件，組織內其他開發者與協調代理就能找到並重用它發布的技能。官方指南也預告，A2A 社群持續探索註冊庫互動的標準化與更進階的發現協定。

還有一種部署形態值得認識：多個代理可以共用單一 A2A 端點，AgentInterface 的 tenant 欄位用來表達這類配置，用戶端依所選介面在請求中帶上這個值。卡片仍應如實描述其代理身分與介面。

直接設定則把卡片位址或內容寫死在用戶端：設定檔、環境變數或私有 API 都屬於這一類。官方指南的描述是，用戶端應用程式利用寫死的細節、設定檔、環境變數或私有 API 進行發現。直接設定可預先配置 Agent Card 的 URL 或內容：若把卡片內容寫進用戶端，異動時需要同步更新配置，若配置的是 URL，則由該位址提供卡片。

三種方式可以並存：well-known URI 從固定路徑取得卡片，註冊庫維護 Agent Card 集合供用戶端查詢，但 A2A 尚未規定統一的註冊庫 API，直接設定則預先提供卡片 URL 或內容。官方指南在取捨上也有標註：註冊庫需要部署並維護一項註冊服務，直接設定對動態發現的場景彈性較低。實作者可依部署環境與安全需求選擇一種或多種方式。

發現機制還有一層容易忽略的工程細節：快取。卡片的內容不常變動，通常是新增技能或更新驗證要求時才動，官方指南建議伺服器端在回應裡加上標準的 HTTP 快取標頭，以 Cache-Control 的 max-age 讓用戶端與中繼節點快取卡片，並以 ETag 搭配條件請求避免重複下載沒變的內容。用戶端也有對應的紀律：快取到期時改用條件請求，帶上儲存的 ETag 或 If-Modified-Since，而不是把整張卡重新抓一次，伺服器沒有提供快取標頭時，可以套用合理的預設快取期間，擴充卡則另有以工作階段為範圍的快取指引。對外提供卡片的伺服器把這兩個標頭設好，等於免費替整個發現生態省流量，規格第 8.6 節對快取另有正式的規範要求。

資安設計：簽章、擴充卡與憑證管理

一個放在公開路徑、人人可讀的自我描述檔案，安全模型要想清楚再上線。卡片的攻擊面主要有兩類：內容本身可能洩漏內部資訊，卡片也可能在中途被竄改或假冒。規格對兩類風險都給了對策，但要求層級不同：Agent Card 可以選擇使用數位簽章，含敏感資料的卡片必須受身分驗證與授權機制保護，採用簽章時內容必須先依 JSON 正規化方案處理。

先處理「什麼可以放」。官方指南點名兩種不該出現在公開卡的內容：內部或受限代理的網址，以及敏感技能的描述。正面表列則是身分定位、公開技能、傳輸介面與驗證方案這類本來就要給外人看的資訊。判斷方法很樸素：假設這張卡明天被競爭對手與資安研究員各讀一遍，前者讀到的是你的服務定位，後者讀到的是你的驗證要求，兩者都屬於你本來就打算公開的營業資訊，這張卡就過關。任何一把鑰匙、一組內部位址、一條還沒發布的路線圖，都屬於會讓你後悔的內容。

防竄改的答案是數位簽章。規格第 8.4 節允許以 JSON Web Signature 簽署 Agent Card，確保真實性與完整性，讓用戶端確認卡片未經竄改、確實來自宣稱的提供者。簽署前要以 RFC 8785 的 JSON 正規化方案處理內容，保證不同 JSON 實作產生一致的正規形式，簽章才能跨環境驗證。驗證端的要求寫得更白：用戶端在信任一張卡片之前，應該驗證至少一個簽章。v1.0 的發布說明把這件事列為企業級功能的一環，以密碼學方式驗證身分。

簽章的工程細節規格也照顧到了。受保護標頭以 alg 表示簽署演算法、以 kid 識別金鑰，typ 建議設為 JOSE，也可以用 jku 指向包含公鑰的 JWKS，讓驗證方知道去哪裡拿公鑰。卡片允許同時存在多個簽章，用途是支援金鑰輪替，服務方換鑰匙時不必中斷驗證，新舊簽章並存過渡。這套設計直接沿用 JSON Web 生態的既有工具鏈，對已經在別處管理過 API 簽章的團隊，學習曲線接近零。

資訊分層的答案是擴充卡。capabilities 裡的 extendedAgentCard 旗標宣告通過身分驗證後可取得內容更完整的卡片，官方指南建議敏感資訊或更詳細的版本改放在這種經驗證的擴充卡裡。公開卡放行銷定位與基本能力，細部規格只對通過驗證的呼叫端揭露，這是名片比喻在安全層次的延伸：公開電話一面，客戶名單另一面。

憑證管理有一條明確的紅線：任何包含敏感內容的卡片都必須以身分驗證與授權機制保護，而且 A2A 規格強烈建議使用帶外發放的動態憑證，而非把靜態秘密嵌進卡片。指南列出的端點防護手段包括雙向 TLS、以 IP 範圍為界的網路限制，以及 OAuth 2.0 這類 HTTP 驗證。註冊庫還有一招選擇性揭露：依查詢端的身分與權限，回傳不同深度的卡片。原則一句話講完：卡片是廣告看板，不是保險箱，任何不想上招牌的東西都不該出現在公開版本裡。

把這些機制組起來，一個對外商業服務的典型配置會是：公開卡走 well-known 路徑，只放身分、公開技能與 OpenID Connect 驗證方案，卡片加上簽章並設定金鑰輪替，細部規格與內部技能放進驗證後的擴充卡，端點再視需要疊上雙向 TLS 或網路範圍限制。每一層都有獨立的失效邊界，公開卡被抄走不影響服務安全。公開卡只放預定公開的資訊，若卡片的簽章無法驗證，用戶端不應據此信任卡片，服務端點仍須依宣告的身分驗證與授權機制保護。週年新聞稿把這套資安設計整理為貼近 Web 的架構，沿用熟悉的安全與負載平衡模式，支撐大規模場景的可靠度。資安設計在這份規格裡不是附加題，是欄位結構的一部分，這也是它與早期許多機器可讀檔案最大的不同。

誰在用它：從市集上架到生產環境

Agent Card 不只是紙上規格，已經嵌入實際的商業流程。Google Cloud Marketplace 的合作夥伴文件對想在市集上架 AI 代理的團隊有明確要求：每一個透過市集供應的 AI 代理，都必須建立一張對齊 A2A Agent Card 規格的卡片，卡片以 JSON 檔案形式存放在 Cloud Storage，並在 Producer Portal 提交給 Google 驗證，驗證通過是代理上架發布的必要條件。對代理開發者來說，寫好一張卡從加分題變成入場券。

開發工具鏈也把卡片納為一等公民。2025 年 7 月的 Google Cloud 部落格在發布 0.3 版工具鏈時宣布，Agent Development Kit 原生支援 A2A，開發者可以用 Agent Card 把別人家的代理納為自己的子代理，也可以反過來把既有的 ADK 代理暴露成可被發現的 A2A 代理。同一篇文章形容當時的生態圈已有超過 150 家組織支持，涵蓋每一個大型雲端業者、主要技術供應商與跨國企業用戶。

生產端的採用也跨過了實驗階段。2026 年 4 月的週年新聞稿列出生產部署橫跨供應鏈、金融服務、保險與 IT 維運等產業。更早的 2025 年 7 月 Google Cloud 部落格就點名 Tyson Foods 與 Gordon Food Service 兩家食品業者，以 A2A 系統協作衝刺業績、降低供應鏈摩擦，讓雙方的代理即時交換產品資料與業務線索。

平台整合把門檻再往下拉。Microsoft 把 A2A 整合進 Azure AI Foundry 與 Copilot Studio，AWS 則透過 Amazon Bedrock AgentCore Runtime 提供支援，三大雲端到了 2026 年都把協定收進自家代理基礎設施。支付場景也在跟上：以 A2A 為基礎發展的 Agent Payments Protocol 已有超過 60 家支付與金融服務組織支持，讓代理之間的交易有專屬協定可走。對內容與服務網站的經營者，這些訊號合起來指向一個方向：代理互相呼叫的流量版圖正在成形，而 Agent Card 是這個版圖的地址系統。

跟 llms.txt、robots.txt、結構化資料差在哪

講到「放在網站根目錄給機器讀的檔案」，難免與幾個熟悉的名字擺在一起比較。四者的讀者、目的與格式各不相同，混用術語是討論 AI 可見性時最常見的混亂來源。下表把四個機制放在同一張桌子上對照。

機制	主要讀者	格式	位置	解決的問題
Agent Card	AI 代理（A2A 用戶端）	JSON（規格定義欄位）	/.well-known/agent-card.json	讓代理發現並連線另一個代理服務
llms.txt	大型語言模型與其擷取工具	Markdown 清單	/llms.txt	給模型一份網站內容的精簡導覽
robots.txt	遵守慣例的爬蟲	純文字指令	/robots.txt	管理爬蟲可存取的路徑範圍
結構化資料	搜尋引擎與其他解析器	頁內 JSON-LD 等標記	各頁面的 HTML 內	以機器可讀格式描述頁面內容的類型與屬性

先把一個常見的期待拆掉：Agent Card 不是 SEO 工具。A2A 規格與 Google 的公告裡，從頭到尾沒有搜尋排名相關的承諾，卡片服務的對象是代理程式的發現與連線，不是搜尋引擎的排序器。把它當成新的排名魔法部署，期待會落空。它影響的是另一個賽道：當採購助理、行程規劃代理這類用戶端代理在找服務時，有卡的服務在名單上，沒卡的服務根本不在候選池裡。

兩個賽道的關係是互補而非替代。llms.txt 處理「模型怎麼理解你的內容」，站上先前對llms.txt 的完整討論整理過它的格式、爭議與務實做法。Agent Card 處理「代理怎麼呼叫你的服務」，前提是你有服務端點可以呼叫。這條分界線就是決策的第一問：網站提供的是內容，還是可程式呼叫的服務？純內容網站的 AI 可見性工程，主戰場仍在內容結構、結構化資料與檔案層的 AI 可讀性。

換一個角度看四者的維護責任，差異更清楚。robots.txt 與 llms.txt 是網站自行維護的檔案，改了就生效，沒有外部審核。結構化資料嵌在頁面裡，跟著內容版更走。Agent Card 的宣告應與服務實際行為一致，若要在 Google Cloud Marketplace 發布代理，卡片還須通過 Google 驗證。這也是為什麼 Agent Card 不適合「先放一張占位卡」的做法，宣告了做不到的能力，在這個生態裡會直接變成信任問題。

用兩種典型網站把配置樣貌具體化。內容型網站合理的機器可讀配置是：robots.txt 管爬蟲、頁內結構化資料標內容類型、llms.txt 視情況提供導覽，well-known 目錄裡沒有卡，因為沒有代理可呼叫的服務。服務型網站則是四件全上：內容行銷的頁面照樣做結構化資料，同時在 well-known 目錄放 Agent Card 描述 API 代理服務，兩套讀者各自取用。同一個網域裡這些檔案互不干擾，各自的讀者讀各自的檔，搞混的是人，不是機器。

把鏡頭拉遠，網站與 AI 的介面版圖也正在變動。當 AI 瀏覽器開始代替使用者逛網站、代理式搜尋改寫流量來源，這個介面會從單一的搜尋引擎爬蟲，長成多種代理各自讀不同規格檔的局勢。想理解這兩股趨勢的細節，可以參考站上對agentic browsing 的介紹與代理式搜尋的因應策略。Agent Card 在這張地圖上的位置，是代理之間的那一層。

實際上路：發布一張 Agent Card 的五個步驟

如果你的服務確實有代理可呼叫的端點，發布流程可以拆成五步：盤點技能、撰寫卡片、部署到 well-known 路徑、驗證與註冊、上線後維運。順序比技巧重要，每一步的產出是下一步的輸入。

第一步：盤點要曝光的技能

先別急著寫 JSON，回到服務本身列出你要對外開放的能力。每項能力想清楚三件事：使用者會用什麼話描述這個需求、這個技能的邊界在哪裡、哪些情境你不想被配對到。這份清單會直接變成卡片的 skills 陣列，標籤描述技能範圍，範例呈現可處理的提示或情境，內容應具體且與實作一致，供用戶端判斷代理是否合適。技能寧可少而準，也不要多而模糊，切分清楚的少數技能，比一大包塞進同一張卡的能力更容易被讀懂。

盤點的素材不要只從開發端來。客服與業務的對話紀錄是最現成的技能候選清單：客人反覆問哪些問題、哪些查詢每天都要人工回一次、哪個流程合作夥伴一直希望你開放介面，這些就是外部代理最可能代替人類來敲門的需求。把這些需求整理成一句一句的任務描述，再對照自家服務的能力邊界，能開放的寫成技能，還不能開放的明確排除。這一步做扎實，卡片的骨架就有了，後面全部是格式工程。

第二步：按規格撰寫卡片

以規格的必填欄位為骨架填內容：name、description、supportedInterfaces、capabilities、version、defaultInputModes、defaultOutputModes、skills 一個都不能少，選填的 provider、documentationUrl、iconUrl 視需要補上。description 與技能描述寫具體的任務語言，避免行話與空泛形容。安全宣告如實填寫：需要驗證就宣告 securitySchemes，不要為了降低摩擦把該驗證的服務裸奔。寫完以 JSON 格式存檔，欄位名稱用規格的 camelCase 拼法。

撰寫階段的常見錯誤集中在三類。必填欄位漏填，特別是 defaultInputModes 這種容易被當成裝飾的欄位，缺了就是無效卡。列舉值拼錯，傳輸繫結與安全方案的型別名稱都要對照規格原文，大小寫與格式差一個字就解析失敗。宣告與實作脫節，卡片上寫支援串流，端點卻沒實作對應行為，這類不一致在驗證階段被退回是好事，漏進生態裡就是配對事故。寫完卡先自己走一次讀卡流程，把卡當成一個第一次認識你的用戶端，逐欄位問「我讀到這個會怎麼做」，比任何檢查表都有效。

第三步：部署到 well-known 路徑

把檔案放到 https://你的網域/.well-known/agent-card.json，確認以 HTTP GET 直接請求會回傳 JSON 內容，狀態碼是 200。部署時順手把快取標頭設好：Cache-Control 帶上合理的 max-age，並提供 ETag，讓用戶端能用條件請求省流量。若服務本身掛在多個網域或子網域下，把卡片部署在用戶端將用來尋找該 A2A 伺服器的網域。

第四步：驗證與註冊

自查欄位完整性與 JSON 可解析性之後，走向外的驗證管道。用 Google Cloud 基礎設施的團隊可以參考 Agent Registry 的註冊流程，文件明言它支援 A2A 規格的 0.3 與 1.0 版，並提供 Agent Card 的結構描述可供檢查。計畫上市集的代理，直接以 Marketplace 的 Producer Portal 流程為準，卡片通過 Google 驗證是上架的前置條件。驗證不通過時，先檢查必填欄位缺失與列舉值拼寫，這兩類最容易被忽略。

第五步：上線後的維運

卡片是活文件，不是上線就結束的一次性工程。新增技能、調整驗證方式、介面改版時同步更新卡片，並讓 version 欄位反映變化，方便依賴 ETag 的用戶端收斂到新版本。敏感度高的服務，把公開卡收斂到安全的基本面，細節搬進驗證後的擴充卡，並檢查簽章設定是否跟上金鑰輪替。每次改版的自我檢查問題只有一個：新的呼叫端讀到這張卡，能不能正確預期服務的現狀。

你需要 Agent Card 嗎：三個判斷問題

回到大多數讀者的處境。判斷需不需要 Agent Card，依序問自己三個問題。第一，我的網站或服務有沒有可以讓程式呼叫的端點，還是只有給人讀的內容？第二，我有沒有跨團隊、跨組織的代理協作需求，例如讓別家的助理呼叫我的報價或查詢功能？第三，我有沒有把代理服務上架市集或註冊庫的計畫？三題都是肯定，Agent Card 是必做的基礎建設。只有第一題肯定，值得排進路線圖。三題都是否定，現階段與它關係不大。

組織裡不同角色要抓的重點也不同。行銷與業務把 Agent Card 當新的通路思考：技能描述就是這個通路裡的產品文案，寫得具體、與實作一致，用戶端才容易判斷代理是否合適。開發與維運把它當介面合約思考：宣告的能力、模式與驗證方式都要有實作支撐，改版要走版本欄位與快取紀律。採購與資安把它當供應商評估的輸入：對方有沒有卡、卡有沒有簽章、宣告的安全方案到不到得了自家政策要求的等級，都是可檢查的訊號。一份 JSON 能同時服務三種視角，這是規格化帶來的紅利。

對以內容為主的網站，優先順序更實際的做法是把基本功排前面：讓內容在代理式搜尋與 AI 回答裡可被引用，靠的仍是清晰的內容結構、結構化資料與合宜的檔案層設定，llms.txt 的評估可以在這個脈絡下一起考慮。等服務端點真的上線，再回來補卡。規格會演化，從 agent.json 改名到 v1.0 的結構重組都發生在一年內，跟得太早反而維護負擔重。

收在 Agent Card 的本質上。它是一份讓代理看懂的自我規格：用機器可解析的格式，講清楚我是誰、我會什麼、怎麼連我、連我要帶什麼證件。人類世界靠名片與簡介建立第一印象，代理世界靠這份 JSON。若目前只有內容網站，可先維持既有的機器可讀基本功，服務端點上線後，再依 A2A 規格建立 Agent Card，讓用戶端取得代理的身分、能力、技能、介面與安全要求。