Andrej Karpathy、Google 和 Garry Tan 都認為 Markdown 是答案，但他們解決的不是同一個問題
請查看你的收件匣，確認信中可調整你的偏好設定，甚至加入其他群組。
在你常用的社群媒體上追蹤 TNS。
Andrej Karpathy、Google 和 Garry Tan 都認為 Markdown 是答案，但他們解決的不是同一個問題
今年 4 月，Andrej Karpathy 發布了一個名為「LLM Wiki」的 GitHub Gist 檔案；這是一份簡短的文字文件，設計目的在於協助人們使用大型語言模型（LLM）建立個人知識庫。它的前提是：AI 代理人（agent）會把自己知道的內容保存在一批相互連結的 Markdown 檔案中，並且能夠讀取與重寫這些檔案；因為語言模型不會厭煩維護交叉參照，也能在一次處理中碰觸十五個檔案。這份文件只有幾千字，也沒有附帶任何產品。
兩個月後，Google 把這種直覺轉化為一項已發布的標準，稱為 Open Knowledge Format。OKF 將組織知識、指標、表格與 runbook 打包成純 Markdown，讓任何代理人都能在不需要專有帳號的情況下讀取。Google 很謹慎地稱它為 v0.1，也就是一個起點，而不是完成版標準。
Y Combinator 總裁 Garry Tan 則是在另一條路線上更早抵達這個方向。他的 gstack 是一套採 MIT 授權的 Claude Code 設定，在數週內突破 66,000 顆 GitHub 星星；它包含 23 個專門角色，每個角色都是一個 Markdown 檔案。沒有 runtime；沒有程式碼；只有能在十種不同 coding agent 上運作的文字。
Markdown 已成為代理人讀寫的基底
三種做法、三種不同需求，一個共同解法。Karpathy 尋求的是代理人的記憶，Google 瞄準的是 BigQuery agents 裡的企業脈絡，而 Tan 想要的是一種能從終端機召喚工程團隊的方法。三者最後都轉向同一種基本資源：一個用 git 做版本控管的 Markdown 檔案資料夾。
開發者早已建立這種做法。CLAUDE.md 和 AGENTS.md 作為代理一開始載入的檔案，已經存在於數百萬個儲存庫中。OKF 與 gstack 是這個慣例演化後的形式：一個聚焦於代理知道什麼，另一個聚焦於它如何行動。
這就是綁定代理知識的 Git 與 JSON 操作模式。能存活下來的格式，都是你不用改任何東西就能開始使用的格式。你可以單純 cat 檔案、clone 儲存庫，而你已經在用的任何工具都能解析它。MCP 作為代理連接的介面，仍然重要。Markdown 正逐漸成為承載內容的格式。
鎖定效應從模型移到檔案
這裡真正值得觀察的重要因素是競爭優勢，而不是技術細節。過去兩年，人們相信擁有最好的模型，就意味著能控制開發者。
這個觀點現在正在轉變。把 Claude 換成 GLM 或 Codex，gstack 仍然能運作，因為核心智慧已經演化，但文件沒有。
護城河正從模型，轉移到團隊擁有並隨時間累積的 Markdown。
護城河正從模型，轉移到團隊擁有並隨時間累積的 Markdown。一家公司的 OKF 套件，包括它的 runbook、指標定義與架構決策，從設計上就能跨雲端、模型與框架移植。
這種可移植性正是供應商中立格式存在的理由，也正是 Google 的 OKF 值得更仔細觀察的原因。
如果沒有人為它開發消費端，它就只會停留在 Google 某個冷清星期五發布的一個好點子。
我最可能判斷錯誤的地方，是它的持久性。宣告 Markdown 標準很容易，但要讓它們可靠卻很困難。OKF 只是一份 0.1 草案，附帶參考實作，還不是一個完整生態系。如果沒有人為它開發消費端，它就只會停留在 Google 某個冷清星期五發布的一個好點子。
方向仍然由三個獨立賭注所決定，而這三個賭注在同一季內都押向同一種檔案格式。你的下一個代理很可能會從一個 Markdown 資料夾解讀它的脈絡，而建立那個資料夾的人，現在擁有了一種模型供應商不容易複製的優勢。
社群為開發者打造的路線圖、文章、資源與學習旅程，協助你選擇適合自己的方向，並在職涯中持續成長。