圖工程：從迴圈到 Markdown 知識圖譜

2026 年 7 月 18 日，Peter Steinberger 在 X 上丟出一個半開玩笑的問題：從迴圈走向圖。Hamel Husain 接了下去，發表一篇標題為 Loop Engineering Is Dead. Enter Graph Engineering. 的文章。一週之內，這個詞到處都是。

那大半是在嘲笑這個領域鑄造新學科的速度——我們在大約十八個月裡，從提示工程走到脈絡工程，再到 harness 工程、迴圈工程，然後是圖工程，而且定義彼此重疊得很嚴重。

但這個玩笑之所以打得中，是因為它指向了某個真實的東西。以下是值得留下的部分。

人們口中的「圖工程」有三種

這個詞一來就帶著至少三種不同的想法。網路上的多數混亂，是人們在這三者之間跳來跳去地爭論。

1. 編排圖。 把多代理人系統設計成一張明確的圖，而不是一個 while 迴圈：有型別的節點、有型別的轉移、可續跑的檢查點。這是 LangGraph 與 Temporal 的地盤。這是真正的工程，主要對打造代理人基礎設施的人有意義。

2. 迴圈之圖。 一張彼此觀察的自我改進循環網路。概念上有趣，而依多數人的判斷，是目前最難落地的一種。

3. 圖結構的知識與記憶。 代理人的知識以有型別的節點與邊儲存，讓它真的能走過去，而不是一堆每次都要重讀、重猜關係的文件。

如果你不是在打造編排基礎設施——大多數人都不是，包括正在看著代理人搬進工作空間的那些人——改變你每一天的是第三種。它也是三者中最老、根基最厚的：知識圖譜比這個詞早了數十年。

為什麼邊贏過搜尋

這個例子會讓你一下子懂。

問代理人：「我們當初為什麼把工作佇列的 Redis 換掉？」

全文搜尋會回傳每一份含有「Redis」的文件——工作一段時間之後，那是幾十個檔案，而且沒有一個是答案。向量搜尋會回傳聽起來像這個問題的文件，這通常更糟：語意上接近，因果上無關。

圖用三跳回答：

工作佇列 --decided_by--> ADR-007（Postgres 佇列）
ADR-007  --supersedes--> ADR-003（Redis 佇列）
ADR-003  --caused------> 事故 2026-03-11

答案不在任何單一文件裡。它在文件之間的路徑上。搜尋取不回路徑：它取回節點，然後指望你自己把線連起來。

還要注意那個決定性的細節：邊是具名的。supersedes 不是 caused，也不是 decided_by。把標籤拿掉，你就回到「這些檔案好像有點關係」，代理人只好全部打開、重新推論關係——正是你想省下的那份工。

有型別的邊就是全部訣竅。其餘都是水管工程。

你的 Markdown 保管庫已經有八成

這是整場討論裡最被低估的觀察：一個維護得宜的 Markdown 保管庫，已經是 GraphRAG 索引的大半。

想想一疊帶 wikilink 的筆記免費給了你什麼：

• 節點——一個想法、一份來源或一個決定，各一個檔案
• 邊——每一個 [[wikilink]] 都是某人刻意建立的連結
• 實體解析在結構上就解決了——[[ADR-007]] 不論出現在哪裡都是同一個節點。沒有模糊比對、沒有嵌入向量碰撞、也不必問「這兩處提到的是同一件事嗎」

最後這點不是小事。實體解析正是多數自動化知識圖譜流水線悄悄崩掉的地方。保管庫繞過了它，因為人類只替實體命名過一次，而連結本身就是同一性。

一個素樸的保管庫缺的是標籤。[[ADR-007]] 告訴你兩則筆記有連結，但沒告訴你怎麼連。那就是剩下的兩成。

實務上長什麼樣

Minibase Vault 正是繞著這一塊打造的，所以與其抽象地談可能性，不如具體講它怎麼運作。

節點來自閱讀。 你在任何值得留下的東西上按一下 Minibase 擴充功能——文件頁、一份 RFC、X 上的討論串、一場演講——它就以乾淨的 Markdown 落進本機的知識庫。不必複製貼上、沒有匯出步驟，也沒有那種瀏覽器一當就消失的「待會再讀」分頁。

邊會連同理由一起被記錄。 保管庫在根目錄放一份 _graph.json：

{
  "edges": [
    {
      "from": "AI Research/attention-paper-20260405-1200.md",
      "to": "AI Research/transformer-tutorial-20260408-0900.md",
      "reason": "Both explain the attention mechanism in transformers"
    }
  ]
}

Claude 會透過保管庫的 MCP 伺服器自己寫下這些邊——當它橫向讀過你的筆記、注意到某個連結時。它們接著會以 Related: 的形式浮現在每個知識庫的 _index.md 裡，讓這張網不只模型看得見，你也看得見。

路徑會凝聚成頁。 當一叢相關筆記夠密了，Claude 可以把它們綜合成一頁 _topic-*.md，並引用來源。下次你再存入這一叢裡的東西，那頁綜合早就在那裡等著被更新。這就是複利的那一步：保管庫變聰明，而不只是變大。

孤兒筆記會被標出來。 一輪 lint 會回報重複、孤兒筆記、過期內容，以及已經熟成、適合綜合的叢集。圖譜會腐朽；總得有東西察覺。

一切都在本機執行。搜尋索引是採 BM25 排序的 SQLite FTS5，圖譜是一個 JSON 檔，你筆記裡的任何內容都不會離開這台機器。

我會替熱度降溫的地方

兩點誠實的保留，因為這是一個一週就爆紅的詞，而熱度總是跑在內容前面。

Minibase 的邊帶的是理由，不是形式化的型別。 "reason": "Both explain the attention mechanism" 是一個句子，不是 supersedes。它遠勝過沒有標籤的 wikilink，也遠不及一套本體論。如果你需要嚴格具型別的關係來做具規模的多跳推理，你要的是一個真正的圖資料庫——而且該對它的維護成本誠實一點。

大多數人根本不需要這些。 如果你的知識只有五十則筆記，搜尋就夠了。圖譜開始划算，是在材料多到你已經開始忘記自己有什麼的時候，也是在你的問題從詞彙型（「我在哪讀到的」）變成因果型（「我們當初為什麼這樣做」）的時候。

「圖工程」這個詞大概撐不過今年。它底下的想法——筆記之間的結構比筆記的數量更值錢——在它有名字之前很久就成立，在名字消失之後也會繼續成立。

從最無聊的版本開始

1. 把讀到的東西存成 Markdown，而不是加進書籤。書籤是指向會腐爛之物的指標；檔案是你真的擁有的東西。
2. 留在本機、單一資料夾，一份來源一個檔案。
3. 讓你的 AI 讀整個資料夾——透過 MCP，不是複製貼上——然後問它需要兩份文件才答得出來的問題。
4. 記下它找到的連結。下個月再問一次。

這就是給不出貨編排框架的人的圖工程。它就是把連結寫下來的脈絡工程。

---

Minibase 一鍵把任何網頁變成乾淨的 Markdown，直接存進 AI 能搜尋、能建立關聯的本機保管庫。擴充功能免費且儲存次數不限；Minibase Plus（每月 5.99 美元或每年 34.99 美元）另有 AI 範本、歷史紀錄與影片轉錄。minibase.md。