Web 必須始終適應新的標準。它學會了與 Web 瀏覽器對話，接著學會了與搜尋引擎對話。而現在，還需要與 AI 智慧體交流。
今天，我們滿懷欣喜之情，推出了 isitagentready.com — 這是一款新工具，可協助網站擁有者瞭解如何最佳化其網站以支援智慧體，涵蓋從指導智慧體進行身分驗證，到控制智慧體可看到的內容、接收的格式以及付費方式等內容。此外，我們還針對 Cloudflare Radar 推出了一個新的資料集，可追蹤網際網路中各項智慧體標準的整體採用情況。
我們希望以身作則。因此，我們還將分享我們最近如何大幅改版 Cloudflare 的開發人員文件，使其成為讓智慧體便捷易用的文件站點，讓 AI 工具能夠更快速、且以顯著較低的成本回答問題。
簡單來說，不怎麼樣。這在意料之中，但也顯示：一旦相關標準得以採納，智慧體的效能將遠超今日水準。
為了對此進行分析，Cloudflare Radar 選取了網際網路上存取量最高的 20 萬個網域；剔除了那些「智慧體就緒程度」並不重要的類別（例如重新導向、廣告伺服器和通道服務），從而將重點聚焦於那些 AI 智慧體在現實中可能需要與之互動的企業、發布商及平台；隨後，我們利用新開發的工具對這些目標進行了掃描。
分析結果為全新的「AI 智慧體標準採用情況」圖表，現已發布於 Cloudflare Radar AI Insights 頁面，透過該圖表，我們可以跨多個領域類別，衡量各項標準的採用情況。
逐一檢視各項檢查，有幾點特別突出：
robots.txt 幾乎普及無遺 — 78% 的網站有 robots.txt，但絕大多數是專為傳統搜尋引擎網路爬蟲，而非 AI 智慧體編寫。
內容訊號：4% 的網站在 robots.txt 中聲明了其 AI 使用偏好。這是一個發展勢頭正強勁的新標準。
Markdown 內容協商（在接收 Accept: text/markdown 請求頭時提供 text/markdown）在 3.9% 的站點上正常運作。
MCP Server Cards 和 API Catalogs (RFC 9727) 等新興標準，兩者合計在整個資料集中出現的網站不到 15 個。現在還為時過早，您有很多機會能夠脫穎而出，因為現在採用新標準且善用智慧體的網站還是屈指可數。
該圖表將每週更新，並且該資料亦可透過 Data Explorer 或 Radar API 存取。
前往 isitagentready.com，輸入您網站的 URL，即可查看自己網站的智慧體就緒程度分數。
能夠提供可操作意見回饋的分數與稽核，曾有助於推動新標準的採納。例如，Google Lighthouse 根據效能和安全性最佳做法對網站進行評分，並指導網站擁有者採納最新 Web 平台標準。我們認為，應存在某種類似機制，以協助網站所有者針對代理程式採用最佳做法。
當您輸入網站時，Cloudflare 會向其發出請求，以查看其支援哪些標準，並基於四個維度提供分數：
範例網站的智慧體就緒程度檢查結果擷取畫面。
另外，我們還會檢查網站是否支援智慧體商務標準（包括 x402、通用商務通訊協定和智慧體商務通訊協定)，但目前這些標準不入分數中。
針對每一項未通過的檢查，我們提供了提示，您可將該提示傳達給您的編碼智慧體，並讓其代您實作支援。
網站本身的智慧體已就緒，真正做到了言行一致。其會公開一個無狀態 MCP 伺服器 (https://isitagentready.com/.well-known/mcp.json) 透過 Streamable HTTP，任何 MCP 相容智慧體都能使用 scan_site 工具對網站進行程式化掃描，而無須使用 Web 介面。此外，網站還會發布智慧體技能索引，包含每項標準的技能文件，讓智慧體不僅知道該修復什麼內容，還知道修復的方式。
我們來深入探究每個類別中的檢查，及其對智慧體的重要性。
自 1994 年以來，robots.txt 就一直存在，大多數網站都有。對智慧體而言有兩個用途：定義爬取規則（誰可以存取什麼內容），以及指向網站地圖。網站地圖是一個 XML 檔案，列出了網站上的每一個路徑，本質上是一張地圖，讓智慧體能夠輕鬆探索網站的全部內容，而無須逐一爬取每個連結。robots.txt 是智慧體首先查閱的位置。
除了網站地圖外，智慧體還可直接從 HTTP 回應標頭中探索重要資源，具體來說就是使用 Link 回應標頭 (RFC 8288)。與深埋在 HTML 內部的連結不同，Link 標頭本身就是 HTTP 回應的一部分；這表示智慧體無須解析任何標記，即可找到指向資源的連結：
HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"
將智慧體安裝到您的網站是一回事。確保其能實際讀取您的內容是另一回事。
早在 2024 年 9 月，鑑於 AI 領域的發展速度之快，彷彿已是「上輩子的事」了，就曾提議 llms.txt 作為一種提供大型語言模型 (LLM) 友好的網站呈現方式，並能納入模型的上下文視窗。llms.txt 是您站點根目錄下的純文字檔案，為智慧體提供了結構化的文字讀取清單：網站是什麼、網站上的內容和重要內容所在。可以將其想像成為供 LLM 讀取，而非供網路爬蟲索引的網站地圖：
# My Site
> A developer platform for building on the edge.
## Documentation
- [Getting Started](https://example.com/docs/start.md)
- [API Reference](https://example.com/docs/api.md)
## Changelog
- [Release Notes](https://example.com/changelog.md)
Markdown 內容協商更進一步。當智慧體擷取任何頁面並傳送 Accept: text/markdown 標頭時，伺服器會用乾淨的 Markdown 版本回應，而不是 HTML。Markdown 版本所需的權杖數量要少得多，我們在某些案例中測得的權杖減少幅度高達 80%，這使得回應速度更快、成本更低；鑑於大多數智慧體工具預設存在的上下文視窗限制，這也使得回應內容更有可能被完整地取用。
依預設，我們只會檢查網站是否正確處理 Markdown 內容協商，而不會檢查 llms.txt。您可自訂掃描，以選擇性地包含 llms.txt 。
既然智慧體可導覽您的網站並取用內容，那麼下一個問題是：您想讓任何機器人這樣做嗎？
robots.txt 的作用不僅僅是指向網站地圖。您還可在此處定義存取規則。您可明確宣告允許哪些網路爬蟲，及其可存取哪些內容，甚至精確到特定路徑。這個慣例已根深蒂固，至今仍是任何「守規矩」的機器人在開始爬取內容之前首先會去查看之處。
內容訊號讓您的操作更加具體。您可精確宣告 AI 能夠對您的內容執行哪些操作，而不僅限於允許或封鎖。在您的 robots.txt 中使用內容訊號指令，您可獨立進行三項控制：您的內容是否可用於 AI 訓練 (ai-train)，是否可用作 AI 推斷與事實依據構建 (ai-input)，以及是否該出現在搜尋結果中 (search)：
User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes
相反，Web Bot Auth IETF 草案標準允許友好機器人進行身分驗證，並允許接收機器人請求的網站識別這些機器人。機器人會簽署其 HTTP 請求，而接收網站會使用機器人發布的公開金鑰來驗證這些簽名。
這些公開金鑰位於知名端點，/.well-known/http-message-signatures-directory，我們會在掃描過程中檢查此端點。
並非所有網站都必須實作此功能。如果您的網站僅提供內容，且不向其他網站提出請求，則不需要。但隨著網際網路上越來越多的網站執行其自己的智慧體來向其他網站發出請求，我們預計此功能會隨時間推移變得日益重要。
除了被動地取用內容，智慧體還可透過呼叫 API、叫用工具以及自主完成任務，直接與您的網站互動。
如果您的服務擁有一個或多個公用 API，API Catalog (RFC 9727) 可為智慧體提供單一且眾所周知的一位置，便於探索所有 API。此目錄託管於 /.well-known/api-catalog 路徑下，列出了您的各項 API，並提供了指向其規範、文件及狀態端點的連結；藉此，智慧體無須爬取您的開發人員入口網站或通讀相關文件，即可獲取所需資訊。
談論智慧體時，就不得不提到 MCP。模型上下文通訊協定是一項開放標準，允許 AI 模型連線至外部資料來源和工具。您無須針對每個 AI 工具建置一個自訂整合，只需建置一個 MCP 伺服器，任何相容的智慧體都能使用。
您可發布 MCP Server Card（提案目前處於草案狀態），以協助智慧體找到您的 MCP 伺服器。這是一個位於 /.well-known/mcp/server-card.json 的 JSON 檔案，描述了您的伺服器在智慧體連線之前會公開哪些工具、如何存取伺服器，以及如何進行身分驗證。智慧體會讀取此檔案，以及瞭解開始使用您伺服器所需的一切資訊。
{
"$schema": "https://static.modelcontextprotocol.io/schemas/mcp-server-card/v1.json",
"version": "1.0",
"protocolVersion": "2025-06-18",
"serverInfo": {
"name": "search-mcp-server",
"title": "Search MCP Server",
"version": "1.0.0"
},
"description": "Search across all documentation and knowledge base articles",
"transport": {
"type": "streamable-http",
"endpoint": "/mcp"
},
"authentication": {
"required": false
},
"tools": [
{
"name": "search",
"title": "Search",
"description": "Search documentation by keyword or question",
"inputSchema": {
"type": "object",
"properties": {
"query": { "type": "string" }
},
"required": ["query"]
}
}
]
}
當智慧體具備有助於執行特定任務的智慧體技能時，才能處於最佳效能狀態，但智慧體要如何探索網站提供哪些技能呢？我們提議這些網站可透過 .well-known/agent-skills/index.json 提供此資訊，這是一個端點，能夠告知智慧體可用的技能及所在位置。您可能會注意到 .well-known標準 (RFC 8615) 已被眾多其他智慧體和授權標準採用 — 感謝 Cloudflare 的 Mark Nottingham 撰寫的標準，以及其他 IETF 貢獻者！
許多網站需要您先登入才能存取。這使得人類難以讓智慧體代表其存取這些網站；正因如此，有些人採取了一種儘管可能存在安全隱患的變通做法：允許智慧體直接存取使用者的 Web 瀏覽器及其目前已登入的工作階段。
其實有更好的方式，允許使用者明確地授予存取權：支援 OAuth 的網站可告知智慧體授權伺服器的位置 (RFC 9728)，從而讓智慧體能夠引導使用者進入 OAuth 程式，讓使用者自行選擇是否向該智慧體授予存取權。在 2026 年 Agents Week 活動上，我們宣布 Cloudflare Access 現在已全面支援此 OAuth 流程；此外，我們還展示 OpenCode 這類智慧體如何利用這一標準，確保當使用者向其提供受保護的 URL 時能順暢運作。
智慧體亦可代您購物，但 Web 付款是專為人類設計的。加入購物車、輸入信用卡、點按支付。當買家是 AI 智慧體時，這種流程完全無效。
x402 透過重新啟用「HTTP 402 需要付款」狀態碼，在通訊協定層面解決了這一問題；該狀態碼自 1997 年起便已存在於規範之中，但此前從未得到廣泛應用。流程很簡單：智慧體請求使用某項資源，伺服器回應狀態碼 402，以及一個描述付款條款的機器可讀承載，然後智慧體支付並重試。Cloudflare 與 Coinbase 合作推出了 x402 Foundation，其使命是推動將 x402 作為網際網路支付開放標準的採用。
我們還檢查了通用商務通訊協定和智慧體商務通訊協定，這是兩項新興的智慧體商務標準，旨在使智慧體能夠探索並購買人類通常透過電子商務店面及結帳流程所購買的產品。
將智慧體就緒程度整合至 Cloudflare URL 掃描程式中
Cloudflare 的 URL 掃描程式讓您提交任何 URL，並取得相關的詳細報告：HTTP 標頭、TLS 憑證、DNS 記錄、所用的技術、效能資料，以及安全性訊號。對於那些想要深入瞭解 URL 在底層究竟是如何運作的安全研究人員和開發人員而言，這是一項基礎工具。
我們已將 isitagentready.com 中的相同檢查項目新增至 URL 掃描程式中，並使用新的「智慧體就緒程度」索引標籤。您在掃描任何 URL 時，現在會看到其完整的智慧體就緒程度報告，以及現有的分析：哪些檢查項目通過、站點層級為何，以及改善您的分數的可行指引。
還可透過 URL 掃描程式 API，以程式化方式來提供整合功能。若要在掃描中包括智慧體就緒程度結果，請在您的掃描請求中傳遞 agentReadiness 選項：
curl -X POST https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/urlscanner/v2/scan \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
-d '{
"url": "https://www.example.com",
"options": {"agentReadiness": true}
}'
在我們建置用於衡量 Web 就緒程度的工具時，我們深知必須確保內部井然有序。我們的文件必須讓客戶使用的智慧體能夠輕鬆處理。
我們自然而然地採用了上述相關內容站點標準，您可在這裡查看我們的分數。不過，我們並未就此止步。以下是我們如何完善 Cloudflare 的開發人員文件，使其成為 Web 上最便於智慧體使用的資源。
遺憾的是，截至 2026 年 2 月，在 7 個測試的 AI 智慧體中，只有 Claude Code、OpenCode、Cursor 預設會以 Accept: text/markdown 標頭請求內容。至於其餘智慧體，我們需要一個基於 URL 的無縫備援機制。
為此，我們透過 Markdown，在相對於頁面 URL 的 /index.md 路徑下，單獨提供每個頁面。我們結合以下兩項 Cloudflare 規則，以動態方式執行此操作，不複製靜態檔案：
使用這兩項規則，任何頁面都可透過將 /index.md 路徑附加至 URL 來擷取其 Markdown 格式：
我們在 llms.txt 檔案中指向這些 /index.md URL。實際上，針對這些 /index.md 路徑，我們始終會傳回 Markdown，無論用戶端設定了哪些標頭。並且我們執行此操作時，無須執行任何額外的建置步驟，或進行內容複製。
llms.txt 充當智慧體的「主站」，提供頁面目錄，以協助 LLM 尋找內容。然而，單一檔案中包含超過 5,000 頁的文件，會超出模型的上下文視窗。
我們不會生成一個巨大的檔案，而是針對文件中的每個頂層目錄生成一個單獨的 llms.txt 檔案，而根目錄的 llms.txt 則僅指向這些子目錄。
此外，我們還會刪除數百個目錄清單頁面，因為這些頁面對 LLM 而言幾乎不具有語義價值，同時確保每個頁面都具有豐富的描述性上下文（標題、語義名稱和描述）。
例如，我們省略了約 450 頁主要用作當地語系化目錄的頁面，例如 https://developers.cloudflare.com/workers/databases/。
這些頁面會出現在我們的網站地圖上，但對於 LLM 而言，所含資訊量極少。由於所有子頁面在 llms.txt 中已單獨連結，擷取目錄頁面僅會提供冗餘的連結清單，迫使智慧體發出另一項請求來尋找實際內容。
為協助智慧體高效導覽，每個 llms.txt 項目必須有豐富的上下文，但同時需要精簡權杖數量。人類可能會忽略前端資料和篩選標籤，但對於 AI 智慧體而言，這些中繼資料就是方向盤。為此，我們的產品內容體驗 (PCX) 團隊精進了頁面標題、描述和 URL 結構，以確保智慧體能夠確切知道要擷取哪些頁面。
請查看我們的 root llms.txt 部分。
每個鏈結都有語義名稱、相符的 URL 和高價值描述。所有這些完全不需要額外工作，即可完成 llms.txt 的生成。這一切其實早已包含在文件的前置內容中。對於位於頂層目錄下的 llms.txt 檔案中的頁面，情況也是如此。若有這些上下文能讓智慧體更高效地找到相關資訊。
此外，我們還依據 afdocs 對文件進行測試。這是一項智慧體便捷易用的新興文件規範及開放原始碼專案，旨在協助團隊對文件站點進行測試，涵蓋內容探索、導覽等方面。這一規範讓我們能夠建置自己的自訂稽核工具。我們針對自己的使用案例新增了一些專門修補程式，並打造了一個儀表板，讓評估變得輕鬆容易。
我們指派了一個智慧體（透過 OpenCode 執行的 Kimi-k2.5），使其針對其他大型技術文件站點的 llms.txt 檔案進行操作，並賦予該智慧體一項任務：回答高度具體的技術問題。
平均而言，該基於 Cloudflare 文件的智慧體取用的權杖數量減少了 31%，且得出正確答案的速度比未針對智慧體優化的普通網站快了 66%。透過將我們的產品目錄整合至單一上下文視窗，智能體能夠精準定位所需的頁面，並沿著單一的線性路徑將其擷取出來。
LLM 回應的準確度通常是上下文視窗效率的結果。在測試期間，我們觀測到其他文件集有重複的模式。
Grep 迴圈：許多文件站點提供單一且龐大的 llms.txt 文件，其大小超出了智慧體的即時上下文視窗。由於智慧體無法「讀取」整個檔案，因此其開始 grep 尋找關鍵字。如果首次搜索遺漏了特定細節，智慧體必須進行思考、優化搜尋，並再次嘗試。
上下文受限且準確度降低：當智慧體依賴於迭代搜尋而非閱讀完整檔案時，就會失去對文件整體上下文的理解。這種零碎的視角經常導致智慧體對目前的文件理解不足。
延遲與權杖充斥：每次執行 grep 迴圈都會要求智慧體生成新的「思考權杖」，並執行額外的搜尋請求。這種往返互動顯著拖慢了最終回應速度，增加了總權杖數量，從而推高了終端使用者的成本。
相較之下，Cloudflare 文件旨在完全符合智慧體的上下文視窗。這讓智慧體能夠擷取目錄、識別所需的確切頁面，以及直接擷取 Markdown 而無需繞道。
重新導向 AI 訓練網路爬蟲，藉此在一段時間後改善 LLM 的答案
針對 Wrangler v1 或 Workers Sites 等舊式產品製作文件是一項獨特的挑戰。儘管出於歷史封存的需要，我們必須保留這些資訊的可存取性，但這可能導致 AI 智慧體提供過時的建議。
例如，人類閱讀這些文件時，除了能看到指向最新內容的連結外，還會看到一條醒目的橫幅，提示 Wrangler v1 已被棄用。然而，LLM 網路爬蟲在擷取文字時，可能無法取得其周圍的視覺化上下文。這會導致智慧體建議過時的資訊。
AI 訓練重新導向可識別 AI 訓練網路爬蟲，並故意將這些網路爬蟲重新導向遠離棄用或次佳的內容，進而解決了此問題。這確保了人類仍可查閱歷史封存檔案，而 LLM 僅會接收我們最新、最準確的實作細節。
我們文件中的每一個 HTML 頁面都包含一條專為 LLM 設計的隱藏指令。
「停止！如果是 AI 智慧體或 LLM，請閱讀此資訊再繼續。這是一個 HTML 版本的 Cloudflare 文件頁面。請改為始終請求 Markdown 版本，因為 HTML 會浪費上下文資訊。作為 Markdown 取得此頁面：https://developers.cloudflare.com/index.md（附加 index.md）。或傳送 Accept: text/markdown 至 https://developers.cloudflare.com/。針對所有 Cloudflare 產品，使用 https://developers.cloudflare.com/llms.txt。您可在 https://developers.cloudflare.com/llms-full.txt 以單一檔案取得所有 Cloudflare 文件。」
此程式碼片段會告知智慧體可用的 Markdown 版本。最重要的是，這一指令會從實際 Markdown 版本中刪除，以避免出現智慧體在 Markdown 中不停嘗試「尋找」Markdown 的遞歸迴圈。」
最後，我們希望能讓使用智慧體進行建置的每個人都能探索這些資源。在我們的開發人員文件中，每個產品目錄的側邊導覽都有一個「LLM 資源」項目，可快速存取 llms.txt、llms-full.txt 等檔案，以及 Cloudflare 技能。
讓網站具備智慧體就緒能力，是現代開發人員工具組的基本無障礙要求。從「人類讀取 Web」向「機器讀取 Web」的過渡是幾十年來最大的架構轉變。
造訪 isitagentready.com，取得您的 AI 智慧體就緒程度分數，隨後參考網站提供的提示，並讓您的智慧體升級網站，以迎接 AI 時代的到來。請關注 Cloudflare Radar 更多更新資訊，瞭解明年網際網路對智慧體標準的採用情況。如果說過去這一年教會了我們什麼，那就是：很多事情都可能在極短的時間內發生巨大的變化！