最近看到 Cloudflare 推了一個「Markdown for Agents」的功能，我第一個反應不是「哇好酷」，而是：這其實是在替整個 Web 補一個新時代的缺口。

我們做網站做了二十年，預設訪客是人：眼睛看、滑鼠點、用瀏覽器跑 JS。於是所有優化都圍繞著 UI/UX、SEO、轉換率。

但接下來幾年，網站的主要讀者之一會變成 AI agent：它不需要動畫、不需要版面，不會因為你用 fancy 的 CSS 就多停留三秒。它要的是「乾淨、可解析、可引用」的內容。

Agent 讀網頁時，HTML 的成本很高

站在 agent 的角度，HTML 的問題不是它不好，而是它太吵。

• 導覽列、頁尾、廣告、追蹤碼，對「理解內容」幾乎沒幫助
• DOM 結構常常是為了排版而設計，不是為了語意
• Token 會被大量耗在樣板與雜訊上

你如果把 LLM 當成「會讀網頁的同事」，就會很快遇到一個現實：同樣一篇文章，乾淨的 Markdown 往往比原始 HTML 更便宜、更穩、更好抽取。

Cloudflare 的切入點很漂亮：在 edge 做內容協商

這功能有意思的地方在於它不要求你改 origin。

概念很像傳統的 content negotiation：只要請求帶上特定 header（例如 Accept: text/markdown），Cloudflare 就在邊緣節點把 HTML 轉成 Markdown 回傳。

對網站方來說，這解了兩個麻煩：

1. 不用維護第二份「給機器看的版本」：不用多一個 /md、也不用額外寫轉換 pipeline
2. 把成本放到網路層：你不需要在 app server 上多做一次解析與清理

更重要的是，它在傳遞一個訊號：未來的網站可能會同時服務兩種訪客——人類與機器，而且機器訪客不再只是爬蟲或 SEO bot，而是會「理解內容、引用內容、甚至用內容去完成任務」的工作者。

這不是萬靈丹：SPA 仍然是痛點

原討論串也有人問「支援 SPA 嗎？」答案是否定的，原因很合理：edge 轉換本質上處理的是靜態 HTML，不會幫你跑 JS。

如果你的內容主要靠前端渲染（CSR/SPA），那 agent 看到的多半是空殼或骨架。

這時候可行的方向通常是：

• 用 Cloudflare 的 Browser Rendering 類型服務去「真正渲染」後再取內容
• 或者回到架構面：重要內容改成 SSR/SSG，讓內容在初始 HTML 就存在

這其實也會逼產品做取捨：你想讓內容被 agent 讀到，就得讓內容在某個階段變成可見、可抽取、可快取。

我會怎麼用：把它當成 agentic workflow 的基礎建設

如果你正在做內部 AI 助理、知識庫 agent、或任何「需要讀外部網頁」的流程，這類功能的價值很直接：

• 你的擷取層變得更乾淨 → 後面 RAG、摘要、引用都更穩
• 成本可預期 → token 不會被網頁樣板吃光
• 解析一致性更高 → 不用每個站都寫一套 rule-based 清理

我更在意的其實不是「省了多少 token」（各站差異很大），而是它讓「機器可讀」變成一個可以被標準化的介面。

當 Web 開始把 agent 當成一級公民，接下來就會出現更多配套：

• 針對引用/授權的政策（能不能被摘要、能不能被引用）
• 針對結構化內容的標準（不只 Markdown，可能還有更嚴格的 schema）
• 針對機器訪客的觀測指標（你要怎麼量 agent 讀了什麼、帶來了什麼價值）

到那個時候，「給人看的網站」會慢慢長出一條分岔：一條是視覺與互動，一條是語意與可用性。Cloudflare 這步像是在把第二條路先鋪好。

原 Threads 連結：sliven0722 原文

AgenticWorkflow #AI落地實務 #人機協作 #DevTools #Cloudflare