四月時，Andrej Karpathy 發布了一份名為「LLM Wiki」的 GitHub gist 檔案，這是一份簡短的文字文件，旨在協助使用者利用 LLM 建立個人知識庫。其概念是讓 AI 代理將所知資訊儲存為可讀寫的連結式 Markdown 檔案，因為語言模型不會厭倦維護交叉參照，且能一次處理十五個檔案。這份文件僅有數千字，且未附帶任何產品。

兩個月後，Google 將此概念轉化為已發布的標準，稱為 Open Knowledge Format。OKF 將組織知識、指標、表格與操作手冊封裝為純 Markdown，讓任何代理都能讀取，無需專有帳戶。Google 特別標註為 v0.1——這是起點而非完整標準。

Garry Tan（Y Combinator 總裁）則以不同方式率先採用。他的 gstack 是一套 MIT 授權的 Claude Code 設定，在數週內便突破 66,000 顆 GitHub 星標，包含 23 個專業角色，每個角色皆為 Markdown 檔案。沒有執行環境，也沒有程式碼，只有可跨十種不同程式碼代理運作的純文字。

Markdown 已成為代理讀寫的基礎

三種方法、三種不同需求，卻有共同的解決方案。Karpathy 追求代理記憶，Google 瞄準 BigQuery 代理的企業脈絡，而 Tan 則希望能從終端機召喚工程團隊。三者皆轉向同一種基本資源：以 git 版本控制的 Markdown 檔案資料夾。

開發者早已建立此慣例。CLAUDE.md 與 AGENTS.md 已出現在數百萬個儲存庫中，作為代理載入的初始檔案。OKF 與 gstack 是此慣例的進化形式——前者專注於代理所知，後者專注於代理行為。

這是將 Git 與 JSON 玩法綁定到代理知識的做法。能存活下來的格式，是那些無需任何更改即可開始使用的格式。你只需 cat 檔案、clone 儲存庫，你已使用的任何工具都能解析它。MCP 仍是代理連接的重要介面，而 Markdown 正成為承載內容的格式。

鎖定從模型轉移到檔案

這裡值得觀察的關鍵因素是競爭優勢，而非技術細節。兩年來，人們相信擁有最佳模型就等於控制開發者。

此觀點現已轉變。將 Claude 替換為 GLM 或 Codex 後，gstack 仍能運作，因為核心智慧演進了，但文件內容並未改變。

護城河正從模型轉移到團隊擁有並長期累積的 Markdown。

護城河正從模型轉移到團隊擁有並長期累積的 Markdown。一家公司的 OKF 套件（包含操作手冊、指標定義與架構決策）在設計上即可跨雲端、模型與框架移植。

這種可移植性正是中立廠商格式存在的原因，也正是 Google 的 OKF 值得深入探討之處。

如果沒有人為它開發消費者，它就只會是 Google 在一個平靜的週五發布的一個好點子。

我最可能出錯的地方在於耐用性。宣告 Markdown 標準很容易，但讓它們可靠運作卻很困難。OKF 僅是一個 0.1 草案，附帶參考實作，而非完整生態系統。如果沒有人為它開發消費者，它就只會是 Google 在一個平靜的週五發布的一個好點子。

方向仍由三個獨立且針對同一檔案格式的賭注所決定，且皆發生在同一季度。你的下一個代理很可能會從 Markdown 資料夾解讀其脈絡，而該資料夾的建立者現在擁有模型廠商難以輕易複製的優勢。

YOUTUBE.COM/THENEWSTACK

科技發展迅速，別錯過任何一集。訂閱我們的 YouTube 頻道，即可觀看所有播客、訪談、示範等內容。

Group Created with Sketch.