---

title: Graphify：把 Karpathy 的 LLM Wiki 概念做成可直接上手的知識圖譜工具，主打 71.5 倍 token 節省 date: 2026-04-08 source: https://www.threads.com/@anxko.86/post/DWz27WokmU8 category: articles tags:

• Graphify
• LLM Wiki
• Andrej Karpathy
• 知識圖譜
• Claude Code
• OpenClaw
• 知識庫
• Token Optimization created: 2026-04-08 updated: 2026-04-08

---

Graphify：把 Karpathy 的 LLM Wiki 概念做成可直接上手的知識圖譜工具，主打 71.5 倍 token 節省

概要

這篇 Threads 補上了一條很關鍵的線：Karpathy 提出的 LLM Wiki 概念，已經開始有人做成可直接使用的開源工具。

作者提到的工具叫 Graphify，定位是讓 AI coding assistant（Claude Code、Codex、OpenCode、OpenClaw）可以直接把任意資料夾轉成可查詢的知識圖譜。它不是只做筆記整理，而是把整包資料編譯成更適合 agent 閱讀與導航的中介層。

這篇 Threads 的重點

1. Graphify 是 LLM Wiki 的實作化版本

前一篇在談的是 Karpathy 的概念：

• 人類只管丟 raw 素材
• LLM 持續維護 wiki
• 知識不是每次查詢時臨時拼，而是預先整理、持續演化

這篇進一步指出：

已經有人把這套思路包成工具，而且可以直接對資料夾執行。

2. 使用方式非常工程化

貼文裡給的流程很直接：

之後讓 agent 指向某個資料夾，執行：

就能產出三個重要檔案：

• ：互動式圖譜
• ：架構報告
• ：長期可查詢的結構化知識表示，可作為原始文件的代理層

3. 作者最在意的是 token 成本

這篇最有實戰感的一句，是作者說：

Graphify 直接節省了 71.5 倍的 token。

這點很重要，因為它說明 Graphify 的價值不只是「看起來很漂亮」，而是它在 AI agent 工作流裡扮演了非常實際的角色：

• 不讓模型每次都直接重讀整包原始文件
• 先把資料夾編譯成結構化知識層
• 讓 agent 透過圖譜、報告、JSON 代理去理解整體脈絡

Graphify 在知識架構裡屬於哪一類？

如果放進我們剛剛整理的知識架構分類中，Graphify 很明顯屬於：

編譯型知識庫架構

而且偏向：

• 知識圖譜導向
• agent consumption oriented
• token optimization first

也就是說，它不是單純的：

• RAG 搜尋工具
• 筆記軟體
• 一般向量資料庫

它更像是：

把原始資料夾編譯成 AI 可導航、可查詢、可長期保留的中間知識層。

它和 LLM Wiki、MemPalace、OpenClaw 的差別

1. 和 LLM Wiki 的差別

• LLM Wiki 是概念 / workflow 哲學
• Graphify 是把這套哲學變成工具化輸出

LLM Wiki 強調的是：

• raw → wiki 的持續編譯

Graphify 則更偏：

• raw folder → graph / report / json 的知識中介層

2. 和 MemPalace 的差別

• MemPalace 比較像長期記憶作業系統
• Graphify 比較像知識編譯器 / 圖譜生成器

MemPalace 強調：

• wings / rooms / halls / tunnels
• 記憶層級
• agent diary
• temporal knowledge graph

Graphify 這條線則更像：

• 先把目錄資料轉成結構化圖譜
• 先節省 token
• 先讓 agent 看懂整體資料夾脈絡

3. 和 OpenClaw 的差別

• OpenClaw 現在的強項是檔案型持久記憶 + agent workflow
• Graphify 補的是資料夾級別的「結構化理解層」

如果借鏡到 Allen / OpenClaw 工作流，Graphify 比較像可以插在這裡：

我的判斷

它真正值得注意的地方

不是「又一個圖譜工具」，而是它抓到了一個很對的方向：

先把資料夾編譯成知識表示，再讓 agent 使用。

這比每次讓模型重新讀整包原始文件，通常更省 token，也更穩。

它最適合的場景

• repo 分析
• 文件夾知識導航
• 研究資料整理
• 長期專案資料結構理解
• 給 Claude Code / OpenClaw / Codex 當中介知識層

可能的限制

但也要保留幾個觀察點：

1. 圖譜抽得準不準，決定實用性上限
2. 結構化過程可能會丟掉一些細節語氣
3. 如果資料更新很頻繁，重編譯成本要看實作
4. token 省很多，不代表所有 query 都能保留完整上下文

資源

• GitHub：https://github.com/safishamsi/graphify
• Threads 原始分享：https://www.threads.com/@anxko.86/post/DWz27WokmU8

一句話總結

Graphify 的價值，在於它把 Karpathy 的 LLM Wiki 概念往前推了一步：不是只談「讓 AI 維護知識庫」，而是直接把資料夾編譯成可查詢的知識圖譜與報告層，讓 agent 更省 token 地看懂整體脈絡。