為代理人優化內容

就像 LLMs.txt 一樣沒用。

這一切都是愚蠢的抽象，AI 並不需要，因為 AI 和人類一樣聰明，所以它們可以直接使用現有的東西，也就是 API。

LLMs.txt 的確沒用，但這也是這句話裡唯一正確的地方。我又一次被激怒，必須來處理社群媒體上更多腦殘的觀點。這次是關於內容優化。

簡短扼要地說：你應該像優化給人類的內容一樣，為代理人優化內容。如何做到這一點是一個不斷演變的主題，但我們看到一些常見的做法：

邊緣模型（Frontier models）以及建立在它們之上的代理人，行為都非常相似，有著類似的限制和優化。例如，為了避免上下文膨脹，它們已知會只讀取檔案的一部分。可能是前 N 行、前 N 位元組或前 N 個字元。它們在被告知某處存在資訊，與必須自行發現資訊時，行為也會有很大的不同。這兩點考量實際上是 LLMs.txt 成為一個有價值的想法的原因，但當時的實施方式是錯誤的。

今天的實施方式很簡單：內容協商。當請求帶有 `Accept: text/markdown` 時，你可以確信你面對的是一個代理人。這就是你的切入點，接下來就看你如何優化它了。我將簡潔明瞭地提供一些我們在 Sentry 的做法範例。

我們花了很多時間優化我們的文件以適應代理人，這是有明顯原因的。主要的優化大多很簡單：

在我們的案例中，我們實際上使用 MDX 來渲染這些，所以這涉及到一些解析的變更和覆寫，以允許某些關鍵頁面以不同的方式渲染。結果是：代理人獲取的頁面更具操作性。

如果一個無頭機器人（headless bot）正在抓取網站，你能做的最沒用的事情就是向它提供一個需要驗證的頁面。在我們的案例中，我們利用這個機會告知代理人，有幾種程式化的方式可以存取應用程式資訊（MCP、CLI、API 等）：

對於像 Warden 這樣的專案，我們實際上設置了讓代理人能夠命中整個內容來引導自身：

如果你根據 `Accept` 標頭來變更回應，你需要告知快取（caches）這一點。否則你的 CDN 會儲存它首先看到的版本，並將該版本提供給所有人——瀏覽器看到 Markdown，代理人看到 HTML，一片混亂。

在你的回應標頭中加入 `Vary: Accept`，這樣快取就會根據請求的 `Accept` 值進行鍵值對應。沒有它，內容協商就只是你的快取層的競爭條件（race condition）。

這很簡單而且有效。你應該這麼做。你也應該關注代理人的模式變化，並隨著行為的改變而更新你的優化。