Agentic Web 卡在信任層，不是標準層：從 robots.txt 到 AgentCard 的信任分類

網站和服務還不敢讓 AI 代理代為行動，問題不在標準太少。現在用得到的機制，從 robots.txt、user-agent 字串到代理協定裡的 AgentCard，幾乎都只是自我宣稱，再加上對方願意遵守。這些標準規定了「怎麼說」，但「說話的是誰、能不能信」一直沒有答案。網站端如果始終沒有可驗證的信任層，再多幾種格式，代理也做不了出錯會有後果的事。

日期: 2026-10-25
資料集: 公開來源（見文末資料來源），無第一手觀測資料
方法: 整理官方文件、規格與公開資料後的分析
限制: 本文為公開資訊的分析與判斷，不含第一手觀測。文中的推論屬個人判斷，可能隨後續資訊改變　本文是根據公開規格、一篇學術論文和利害關係方文章做的推理，沒有量化資料能說明阻礙代理普及的主因是格式還是信任；各協定的部署規模，以及廠商是否讀取 llms.txt，都還沒有一手證據。

普遍的看法：代理用不起來，是因為標準還不夠

談 Agentic Web 的文章，多半把它當成標準化問題。網頁是寫給人看的，代理讀起來吃力，所以要有 llms.txt。爬蟲行為需要規範，所以有 robots.txt。代理之間要溝通，所以有 A2A。照這個思路，只要協定一個個補齊，代理自然就會普及。

另一派把「信任」當成「標準」的對立面，認為重點在身分驗證，格式只是次要問題。兩種說法都對了一半。我認為更好用的問法是：每一層協定背後，靠的是哪一種信任？這樣一拆就會看到，各層技術雖然不同，信任的來源卻幾乎一樣。

把問題分成四層：可讀、意願宣告、身分授權、代理間信任

我把目前跟代理有關的機制分成四層。下表的「信任類型」借用一篇 2025 年 11 月 arXiv 論文的分類。Hu 與 Rong 的比較研究把代理間信任模型分成六類：Brief、Claim、Proof、Stake、Reputation、Constraint。其中 Claim 指自我宣稱的能力與身分，論文舉的例子就是 AgentCard。Proof 指密碼學驗證，包括零知識證明與 TEE attestation。Stake 是抵押與罰沒，Constraint 是沙箱與能力限制。

代理相關機制的分層，以及各層目前實際依賴的信任類型（分層與歸類為作者判斷）
層次	代表機制	回答的問題	目前主要的信任類型
可讀層	llms.txt	代理怎麼有效率地讀懂網站	幾乎不涉及信任，只處理格式
意願宣告層	robots.txt（RFC 9309）	網站希望爬蟲怎麼做	Claim＋自願遵守
身分與授權層	user-agent 辨識；FIDO 指出的缺口	來的是誰、替誰行動、獲得多少授權	Claim（字串可以假冒）
代理間信任層	A2A、AP2、ERC-8004	代理之間能不能互相信任、交易	以 Claim 為主，Proof／Stake 仍在發展

表格最右欄幾乎都是同一個詞。四層的技術成熟度差很多，信任卻多半停在 Claim：對方自稱是誰、自稱會怎麼做，網站只能選擇相信或不相信。

robots.txt 是最好的反例：標準化了，信任問題還在

想證明「標準不等於信任」，robots.txt 是最直接的例子。這套協定由 Martijn Koster 在 1994 年提出，後來由 IETF 以 RFC 9309 正式規格化，現在的狀態是 Internet Standards Track 上的 Proposed Standard，作者是 M. Koster、G. Illyes、H. Zeller、L. Sassman。以網路標準來說，它算很成熟了。

但 RFC 9309 自己就寫明，robots.txt 的規則不是存取授權（access control）機制，只是要求爬蟲遵守。換句話說，IETF 把「網站怎麼表達意願」寫得很清楚，至於對方會不會照做、自稱的身分是不是真的，本來就不在這份標準的範圍。

我認為這一點決定了整個問題該怎麼看。如果連最成熟的 robots.txt 都只做到宣告，那麼期待下一個格式標準解決信任問題，方向就錯了。宣告層和驗證層是兩件事，把前者做得再精細，後者也不會自己出現。很多人以為 robots.txt 能擋住 AI 爬蟲，誤會就出在這裡。它擋得住守規矩的爬蟲，前提是那些爬蟲本來就願意被擋。

user-agent 辨識和 AgentCard，本質上是同一種弱點

網站目前辨識 AI 爬蟲的常見做法，是讀 user-agent 字串，看它自稱是 GPTBot 還是其他爬蟲，再搭配 robots.txt 的規則，期待對方照做。套用論文的分類，這就是典型的 Claim 型信任：字串由來訪者自己填，任何人都能假冒。

代理協定那一端看起來先進得多，但 AgentCard 也是代理對外宣告自己的身分與能力。網站端的 user-agent 和代理端的 AgentCard，一個是老技術，一個是新協定，在信任分類上卻放在同一格。論文還提到一個讓情況更麻煩的因素：prompt injection、sycophancy、幻覺、欺騙、misalignment 這些 LLM 特有的弱點，會讓單靠信譽或單靠宣稱的做法變得脆弱。人類寫的爬蟲至少行為固定，LLM 代理連「自己宣稱的事」都可能被它讀到的內容改掉。

所以我推測，代理端「讀到的內容」本身就是攻擊面。這只是推測，目前沒有量化證據，但方向應該不會錯：讀取格式越普及，內容來源的可信度就越重要，可讀性和信任並不是兩條互不相干的路線。

llms.txt 在這張圖裡的位置

llms.txt 由 Jeremy Howard 提出，最早版本標示的日期是 2024-09-03。內容是在網站放一個 markdown 格式的 /llms.txt，並建議在原頁面網址之下提供乾淨的 markdown 版本。現行的 llms.txt 規格頁已經是 v2，允許把檔案放在網站任何路徑，涵蓋該路徑底下的頁面。規格頁描述代理大量使用網站的情況時寫了一句「Today it is routine.」，並說 2024 年初版寫成時，這件事大致還只是預測。

規格頁也自述：已有數千個網站發布 llms.txt，文件平台會自動產生，Chrome 的 Lighthouse 把它列進 agentic browsing 的檢查項目，OpenAI、Anthropic、Gemini 也都替自家開發者文件發布了 llms.txt。不過這些都是提案方自己的說法，沒有經過獨立統計。根據規格頁的檢索摘要，這份提案目前沒有 W3C 或 IETF 背書。

這裡有個常見的推論跳躍。OpenAI 的 GPTBot 文件頁開頭確實指向自家的 llms.txt 作為文件索引，也可以在網址後面加 .md 取得 markdown 版本。可是「AI 實驗室為自己的文件發布 llms.txt」，和「它們的爬蟲會讀取別人的 llms.txt」是兩回事。第三方的 GreenGeeks 指出，截至 2026 年初，沒有主要模型供應商公開確認自家檢索系統會讀這個檔案。這是那個時間點的狀態，之後可能已經改變，但目前也沒看到一手來源證實。

就算 llms.txt 明天變成普遍標準，它處理的也是可讀性與 token 效率，沒有碰到身分、授權或意圖。它在框架裡屬於最底層，很有用，但動不到信任問題。

取捨與邊界：這個判斷在什麼情況下不成立

「瓶頸在信任，不在標準」這句話本身需要保留。最常這樣說的，正是有利害關係的一方。FIDO Alliance 執行長 Andrew Shikiar 在 2026 年 4 月 28 日的文章主張，網路的信任基礎建立在螢幕前有人在操作這個假設上，而 AI 代理打破了它。這個觀察我同意。但 FIDO 推動代理憑證認證，本來就是在爭取信任層的標準制定權，讀者應該把它看成一方立場，而不是中立結論。更有意思的是，FIDO 自己也主張要用共識標準來解決信任。所以「標準還是信任」從來不是二選一。比較精確的說法是：缺的是信任層的標準，而不是格式層再多一份標準。

這個判斷也有適用範圍。對低後果的讀取，例如代理查一份 API 文件、回答一個產品問題，Claim 型信任其實夠用。讀錯了可以重讀，被假冒的代價也低，這時改善可讀層最划算。只有當代理要下單、付款、改資料、代表使用者簽署，Claim 的弱點才會變成真正的阻礙。如果你的服務多半是前一種情況，把資源投在信任層可能太早了。

還有幾塊資訊目前看不清楚。FIDO 提出的代理憑證計畫有什麼具體規格、時程和採用方，公開資料沒有細節。A2A、AP2、ERC-8004 實際部署到什麼規模，也無從判斷。網站端有沒有一種被廣泛採用、能用密碼學證明「來訪者確實是某家廠商的代理」的機制，我手上沒有一手證據。至於「格式不統一」和「信任不足」哪一個才是阻礙代理普及的主因，目前沒有任何量化資料。所以這篇文章提出的是推理框架，不是實證結論。

對誰有影響，以及接下來該看哪些訊號

網站與內容經營者面對的是很現實的分工。robots.txt 照樣要設，llms.txt 依成本決定要不要做，但不要以為任何現行標記能擋住惡意代理。電商和交易型服務的壓力最大：代理代為下單出錯時，責任歸屬取決於授權能不能被驗證，這正是 Claim 型信任給不了的。做代理和 AI 搜尋產品的團隊則要想清楚，自家代理要怎麼讓對方「驗證」，而不只是「辨識」。

以 AEO/GEO 來說，llms.txt 常被包裝成提升 AI 能見度的手段，但它的效果仍取決於代理方採不採用。我認為更長期的變化是，AI 搜尋從「讀頁面」走向「代理代為行動」以後，能見度問題會慢慢讓位給授權與信任問題。被讀到只是第一步，能不能被放行做事，才是下一輪的門檻。

接下來我會看三個訊號。第一，主要模型廠商有沒有用一手文件說明檢索時會讀 llms.txt。第二，有沒有出現網站端能採用的密碼學驗證機制，讓「我是某家廠商的代理」從宣稱變成可以證明。第三，AP2 這類支付協定裡的 Proof 或 Stake 設計，有沒有真的接上交易型服務。前一個訊號會改變格式層的價值，後兩個才會改變代理能做的事情的範圍。

結論：先問出錯成本，再決定投資哪一層

Agentic Web 不缺標準。可讀層有 llms.txt，意願宣告層有 RFC 9309，代理之間也有 A2A、AP2、ERC-8004。缺的是一套讓網站端能驗證對方身分與授權的共識做法。今天從 user-agent 到 AgentCard，信任類型幾乎都停在自我宣稱。創辦人和網站經營者在排優先順序時，該問的不是「還有哪個格式沒跟上」，而是「代理在我的服務上出錯，成本有多高」。成本低，格式層就夠了；成本高，就會卡在信任層，而這一層的答案目前還沒出現。

延伸閱讀：llms.txt 要不要做的取捨　·　誰在量測 AI 爬蟲是否守規矩　·　用驗收成本與可逆性判斷代理的使用時機　·　代理入口由誰定義

常見問題

robots.txt 能不能擋住 AI 爬蟲？

只能擋住願意遵守的爬蟲。RFC 9309 寫明 robots.txt 的規則不是存取授權機制，只是要求爬蟲遵守。真正的存取控制要靠其他技術手段。

OpenAI、Anthropic 都有 llms.txt，代表它們的 AI 會讀我網站的 llms.txt 嗎？

不能這樣推論。llms.txt 規格頁說的是這些 AI 實驗室替自家開發者文件發布了 llms.txt。第三方 GreenGeeks 指出，截至 2026 年初，沒有主要模型供應商公開確認自家檢索系統會讀這個檔案。

llms.txt 是正式的網路標準嗎？

不是。它是 Jeremy Howard 在 2024 年 9 月提出的提案，目前規格頁是 v2。根據規格頁的檢索摘要，它沒有 W3C 或 IETF 背書。

什麼是 Claim 型信任？為什麼它不夠？

Claim 型信任指對方自我宣稱的身分與能力，例如 user-agent 字串或 AgentCard。它可以被假冒，也沒有密碼學驗證。只做低後果的讀取時通常夠用，一旦代理要代為交易或改資料，就需要 Proof、Stake、Constraint 這類能驗證的機制。