llms.txt vs AGENTS.md vs OKF：三種「給 AI 的 markdown」，其實在解不同問題
最近「給 AI 用的 markdown」冒出一堆：llms.txt、AGENTS.md、CLAUDE.md、OKF……我在自己的網站和 repo 裡剛好三種都用過，結果最常被問的是同一句：「是不是有了其中一個，另外幾個就不用了？」
這問題有點像我上一篇問的「OKF 是不是取代 RAG」。會混淆，是因為把不在同一層的東西擺在一起比；只要先看它們對誰說話，差別就清楚了。
llms.txt 給外部 LLM 讀網站，AGENTS.md／CLAUDE.md 指引在 repo 裡工作的 agent，OKF 則保存 agent 要用的結構化知識。三個是三層，不必三選一。
同一個框架，上一篇：OKF vs RAG vs 向量資料庫先看它們在對誰說話
把它們放回正確的位置，只要問三個問題：對誰說話、內容是什麼、什麼時候被讀。
| llms.txt | AGENTS.md / CLAUDE.md | OKF | |
|---|---|---|---|
| 對誰 | 外部 LLM（讀你公開網站） | 你 repo 裡工作的 coding agent | 需要知識的 agent |
| 是什麼 | 網站的精選地圖／索引 | 行為指令與紀律 | 結構化知識本身 |
| 範圍 | 一個檔、站層級 | 一個檔、repo 層級 | 一個目錄的概念圖 |
| 內含 | 重點頁面連結 + 簡述 | 規矩、指向哪裡 | 概念、關係、決策 |
| 何時被讀 | LLM 讀你網站時（若有讀取） | agent 開始工作時 | agent 需要某項知識時 |
llms.txt：把網站整理給 LLM 看
llms.txt 是放在網站根目錄的一份 markdown 地圖（規格見 llmstxt.org）。它寫給外部 LLM 讀，目的是讓模型快速找到重點內容、正確引用。它目前是提案。到 2026 年 11 月，我查不到 ChatGPT、Perplexity、Claude 這幾家業者公開確認會使用它。它的對象是「外部的、讀你網站的模型」。
規格是 Jeremy Howard 在 2024 年 9 月 3 日提出的。唯一必要的部分是一個 H1，寫專案或網站名稱。後面依序放一段 blockquote 摘要、可選的說明，再用 H2 分區列連結。每個連結項目是 markdown 清單，必須有 [名稱](網址)，冒號後的說明可有可無。名為「Optional」的區塊放次要連結，模型只需要短內容時可以跳過。
它不會對 coding agent 下指令，也不負責保存知識；它是一張對外的網站地圖。我替本站補了一份，內容直接從文章資料產生，所以新增文章時也會一起更新。
AGENTS.md / CLAUDE.md：是指令，不是知識
AGENTS.md（Codex、Cursor、Gemini CLI 等多種工具會讀）和 CLAUDE.md（給 Claude Code）是 coding agent 進到你 repo 時預設會載入的入口檔。它們講的是「怎麼做」：專案慣例、常用指令、規矩、以及該去哪裡找東西。它本身不放知識，它放的是行為與指向。
我就是用它們當入口，把 agent 指向自己的 OKF 知識庫：「動工前先讀 /knowledge 的相關節點」。少了這層，知識庫放在那裡也不會有人主動去讀。
AGENTS.md 的官方站 agents.md 把它定義成「引導 coding agent 的簡單開放格式」。它沒有必填欄位，就是一般的 markdown。monorepo 裡可以放好幾份，離正在改的檔案最近的那份優先，每個子專案都能有自己的規矩。
OKF：知識本身
OKF 則是那份被指向的、結構化、可走訪、可版本控制的知識——一個目錄的 typed markdown，概念之間用連結串成圖。它回答的是「知識該長什麼樣子」，不是「怎麼行為」，也不是「對外怎麼被找到」。
想深入 OKF：Google OKF 會取代 RAG 與向量資料庫嗎？實例：本站這三個檔實際寫了什麼
以下是 2026 年 11 月 4 日本站的狀態。先看對外那份。正式站的 /llms.txt 開頭是 H1「# KeepOnFirst」。接著是兩行 blockquote，中文摘要一行、英文摘要一行。然後是 7 個 H2 區塊：Articles、Guides、Tools、Apps、Signals、About、Knowledge。Articles 底下列了 79 篇文章，每篇一行。
# KeepOnFirst
> （中文一行摘要）
> （英文一行摘要）
## Articles
- [文章標題](https://keeponfirst.com/article/<slug>): 摘要第一段的前幾句
## Guides
## Tools
## Apps
## Signals
## About
## Knowledge這份檔沒有人手寫。build 腳本讀可被搜尋收錄的中文文章，一篇產生一行，標題、網址、摘要都從文章資料來。設成不收錄的頁面不會出現，遊戲頁也不放。
再看對內那兩份。本站的 CLAUDE.md 不到 10 行，主要講三件事。第一，去讀 AGENTS.md。第二，記憶在 /knowledge。第三，部署等於 push 到 main。AGENTS.md 多寫幾條必須先知道的規矩，例如 build 末段有兩道閘門，別繞過。兩份都很短，因為它們只負責指路。
重點：這個 repo 的持久記憶是 /knowledge 的 OKF bundle。
- 動工前先讀 knowledge/index.md 並走訪相關節點，不要憑空重猜架構。
- 改完後更新受影響的節點。被指向的 knowledge/ 才是內容所在。index.md 的 frontmatter 只寫 okf_version。底下列了 24 個節點，分成幾組：架構、參考、資料管線、雷區、操作、寫作等。每個節點自己有 type、title、description。agent 改文章資料前讀〈文章資料模型〉，要上線前讀〈部署〉，不用一次讀完。這個目錄只在 repo 裡，不對外公開。
想自己寫一份：OKF bundle 怎麼寫，一個目錄、三條規則改了什麼，就改哪一層
分層最實際的用處，是知道一件事該寫進哪個檔。下表是本站實際遇過的三種變動。
| 發生什麼事 | 要改的地方 | 原因 |
|---|---|---|
| 新增一篇文章 | 不用手動改；llms.txt 下次 build 自動多一行 | 它從文章資料產生 |
| 部署方式或必守規矩變了 | AGENTS.md／CLAUDE.md 加一句 | agent 每次開工都要先知道 |
| 踩到新雷：文章來源欄只有 label 和 url，沒有 note | knowledge/ 的對應節點 | 只有改到那塊程式時才需要讀 |
第三列如果寫進 AGENTS.md，每個任務都要多讀一段用不到的細節。寫進 llms.txt 更糟，那是給外部讀者的，內部雷區不該出現在那裡。
它們怎麼組起來（不是互相取代）
在我實際的 setup 裡，三者同時存在、各做各的：AGENTS.md／CLAUDE.md 是入口指令，把 agent 指向 OKF bundle；llms.txt 走另一條路，對外，留給可能來讀網站的 LLM。前兩者對內、對開發 agent，llms.txt 對外，沒有誰取代誰。
實測這套怎麼運作：把 repo 做成 OKF bundle 給 agent 當記憶所以你需要哪個？
按需求對號入座：有公開網站，想替 LLM 準備一份地圖 → 補 llms.txt（它還是提案，效果沒有保證）。有 coding agent 在你 repo 裡工作 → 寫 AGENTS.md／CLAUDE.md。有一批 agent 會反覆用到的結構化知識 → 做成 OKF。答案常常是「都要」，但別把其中一個當成另一個用。
所以「給 AI 的 markdown」其實是三層，不是同一種東西。與其糾結要選哪一個，不如逐層檢查：這三層，我各自補齊了沒。