透過內容協商向 AI 代理提供 Markdown

透過內容協商優化網頁內容以供 AI 代理使用

透過 HTTP 內容協商提供網頁的 Markdown 版本，可讓 AI 代理跳過導航選單、腳本和版面配置標記，直接存取核心內容。透過回應 Accept: text/markdown 標頭，伺服器可提供高訊號、低雜訊的頁面版本，從而優化基於 LLM 的代理的記憶體消耗並降低延遲。

Markdown 傳送的技術優勢

為 AI 客戶端提供專用的 Markdown 回應，相較於提供標準 HTML，具有三大主要技術優勢：

• 記憶體效率：Markdown 移除了 DOM 包裝、CSS 樣式和 JavaScript，確保 LLM 的上下文視窗專注於實際的散文內容，而非結構標記。
• 改善檢索（RAG）：透過移除廣告、相關內容欄位和模態覆蓋層，訊號與雜訊比提升，避免無關資料干擾檢索增強生成（RAG）流程中的嵌入過程。
• 降低延遲：較小的資料量導致更快的取得與解析，使模型在開始生成前處理的資料更少，從而加快「第一個記憶體」的回應時間。

適合 AI 的 URL 實作要求

要正確透過內容協商實作 Markdown 提供，URL 應遵循以下技術標準：

1. 標頭支援：當請求包含 Accept: text/markdown 時，專門提供 Markdown 內容。
2. 快取控制：設定 Vary: Accept 標頭，通知快取（如 CDN）回應會根據請求的 Accept 標頭而變化。
3. 錯誤處理：對於不支援的請求類型，回傳 406 Not Acceptable 狀態碼。
4. 權重：尊重 Accept 標頭中定義的 q-值（品質值），以處理偏好權重。

社群爭議與技術反駁

儘管此提案旨在簡化 AI 消費，但已在開發者社群中引發關於網路標準以及客戶端與伺服器責任的廣泛討論。

客戶端轉換論點

多位批評者認為，內容轉換的負擔應由 AI 代理的「外殼」承擔，而非網站所有者。主流觀點認為，由於 HTML 已是結構化標記語言，AI 代理應使用現有的 HTML-to-Markdown 庫來清除雜訊，類似於螢幕閱讀器或文字瀏覽器的運作方式。

快取與基礎設施挑戰

針對內容分發網路（CDN）的影響，技術上的疑慮也已提出。特別是，有使用者指出，某些 CDN（如 Cloudflare）可能難以針對同一 URL 快取不同內容類型（JSON 與 HTML），除非特別設定，可能導致 JSON 被錯誤地提供給 HTML 客戶端。

可存取性與語意 HTML

部分開發者主張，優先考慮語意 HTML 和可存取性（ARIA 標籤、螢幕閱讀器相容性）是更永續的做法。他們認為，結構良好的可存取 HTML 頁面已針對機器與搜尋引擎優化，因此額外的 Markdown 層是多餘的。

採用與激勵機制

關於網站所有者是否有動機實作此標準，存在持續的疑問。批評者指出，若未獲得相應回饋，向 AI 公司提供「乾淨」資料可能不會推動廣泛採用，除非主要 AI 代理（如 OpenAI、Google、Anthropic）明確開始請求 text/markdown 標頭。

各方觀點總結

觀點	論點
支持者	減少記憶體成本、降低延遲、提升 RAG 准確度。
架構師	警告主動協商的複雜性與 CDN 快取問題。
務實派	建議 AI 代理應在本地處理從 HTML 到 Markdown 的轉換。
可存取性倡議者	主張語意 HTML 已滿足機器可讀性的需求。