前陣子 X（Twitter）上突然冒出一個新詞：Graph Engineering。
事情是這樣的——7 月 18 日，Peter Steinberger 發了一句「Are we still talking loops or did we shift to graphs yet?」（我們還在講迴圈，還是已經轉向拓樸圖像流程了？），幾個小時內 Hamel Husain 就宣布「Loop Engineering Is Dead」（迴圈工程已死），然後 48 小時之內，教學文、反駁文、「我們三年前就在做了」的聲明全部湧出來。
聽起來是不是很熟悉？
Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering → Graph Engineering。每一輪大約兩三個月，每一輪都有「前一個死了」的宣言。有人笑說「接下來會有一萬字的 slop 文章」。果然，幾天後就出現了。
但撇開命名的炒作不談，這個詞背後到底在講什麼技術內容？值不值得花時間理解？我讀了幾篇主要的文章，試著拆解一下。
它到底在說什麼？
簡單來說，Graph Engineering 是一種「流程拓撲」的設計方法論。
過去大多數人在用 AI Agent 做事的時候，不管是用 Claude Code、Cursor 還是其他工具，預設都是一步一步來——做完 A 再做 B，做完 B 再做 C。這不是因為 B 一定需要 A 的結果，而是因為我們打字就是一行一行的，思考習慣跟著輸入介面走。
Graph Engineering 提出的核心問題是：你排成一條線的那些步驟，真的每一步都需要等上一步完成嗎？
如果 B 根本不需要讀 A 的輸出，它們就是獨立的任務，可以同時進行。原文用了一個很直覺的判斷方式——每個「and then」都問一次：下一步真的讀了上一步的輸出嗎？如果答案是 yes，保留順序（這是真正的依賴）。如果答案是 no，拆開來平行跑。
把這個邏輯套用到 multi-agent 的開發流程，就變成：一個人做事天然是序列的，不是因為任務必須序列，而是因為你只有一雙手。現在有了多個 AI Agent 可以同時運作，等於突然有了團隊人力，所以可以回頭重新審視哪些工作其實可以分頭進行。
這就是 Graph Engineering 的「圖」——不是資料結構裡的圖論，而是把工作流程從一條線重新畫成一張有分支、有合流的拓撲圖。
五步方法論拆解
原文（codila / @0xCodila 的五步課程）把這個方法拆成五個步驟：
Step 1 — 識別真實的邊（edge）。 分析你的工作流程，找出哪些步驟之間有真正的資料依賴（真邊），哪些只是習慣性的「and then」（假邊）。假邊代表可以平行的機會。
Step 2 — 扇出（fan out）。 把獨立的任務各自分配給不同的 agent，平行執行。Claude Code 的 Dynamic Workflow 功能會生成一段 JS 編排腳本，協調在腳本裡進行，不佔用你的 context window。
Step 3 — 處理會壞掉的地方。 兩個常見失敗：第一，verifier 不能跟被驗證的 agent 共用同一個 context，不然只是「換個字體同意自己」；第二，多個 agent 不能共用同一個工作區，不然會互相覆寫。
Step 4 — 應用到不同場景。 安全掃描、引用報告、模組移植、對抗式 code review、排程掃描、未知範圍探索——這些都適合同樣的「拆解 → 平行 → 驗證 → 收斂」結構。
Step 5 — 設定錨點（anchor）。 圖裡面要有不可被 LLM 說服的節點——實際跑過的測試（不是「應該會過」，而是真的過了）、基於證據而非感覺的驗證、agent 不被允許修改的凍結規則。
實戰案例：Bun 的 Zig-to-Rust 移植
文章用了一個很硬的案例來展示這套方法的天花板——Bun 團隊用 Dynamic Workflow 把 Bun 從 Zig 移植到 Rust。約 535,000 行 Zig 轉成超過一百萬行 Rust，大約 50 個 workflow、峰值 64 個 agent 平行運作，從第一個 commit 到 merge 花了 11 天。
拆開來看，它的四個階段完美對應了五步方法論：Phase 1 建立 struct field 和 lifetime 的映射表（Step 1：這是真正的依賴），Phase 2 逐檔平行轉換，每個檔配一個轉換 agent 加兩個 reviewer（Step 2 + 3），Phase 3 用 build + test 的 fix loop 反覆修正直到測試全綠（Step 5：測試結果是 anchor），Phase 4 做 overnight cleanup 開 PR。
這個案例之所以跑得起來，是因為它天然具備三個理想條件：檔案之間的轉換大致獨立（高獨立性）、驗證標準非常明確——測試通過就是通過（明確 anchor）、每個任務的定義清晰——一個 .zig 對應一個 .rs（清晰任務邊界）。
它沒說的部分
好，價值講完了。接下來講它沒處理的部分——這也是我認為這篇文章最需要被補充的地方。
第一，它缺少「該不該 fan out」的判斷。 文章直接從「怎麼識別可平行的任務」開始教，但沒有提供一個前置問題的判斷工具：你的任務結構真的有足夠的獨立性可以被利用嗎？Bun 的檔案轉換是天然獨立的，但大多數真實的開發工作不是——功能之間有邏輯耦合，需求本身在變動，一個模組的設計決策會影響另一個模組的實作方式。
我自己在實測 Claude Code 的 Agent Teams（teammate 模式）時的經驗是，大約七八成的真實開發情境裡，任務之間有程序性鎖，能真正平行的窗口很窄。把所有東西都攤開來平行跑，聽起來很美，但多數時候你省下的時間會被協調成本和事後整合的成本吃掉。
第二，verifier 本身也是 LLM。 文章正確地指出 verifier 需要 clean context，不能跟被驗證的 agent 共享對話歷史。但 clean context 只解決了「不受前一個 agent 的措辭影響」，沒有解決 verifier 自身的限制——它也會幻覺，也可能產生「幽靈因果」（Ghost Causality），也會用高信心的語氣輸出不正確的判斷。Bun 的案例靠測試結果（一個不可被說服的硬標準）補救了這個問題，但在非程式碼的任務裡——研究報告、策略分析、內容審核——什麼東西能充當那個 anchor？文章沒有回答。
第三，可靠度是相乘的，不是相加的。 如果單一 agent 的可靠度是 0.9（已經算不錯了），三個串聯就是 0.73，十個就是 0.35。Graph Engineering 教你把圖畫得更寬、讓更多 agent 平行跑，但完全沒有處理「每多一個節點就多一個失敗點」這個基本的可靠度問題。而且 AI agent 的失敗模式跟人類不同——人犯錯通常看得出來（猶豫、停下來問、承認不確定），但 LLM 犯錯的時候臉上的表情跟正確的時候一模一樣。你用更多 agent 省下來的時間，很可能全部被花在審閱和追蹤那些你不確定對不對的產出上。
然後還有一個文章輕描淡寫帶過的數字：Bun 的案例花了大約 $165,000 的 API 使用費。而且文章自己也提到，這個規模的 AI 生成程式碼「drew public criticism over whether that much AI-authored code can be safely reviewed」（引發了公開批評，質疑這麼大量的 AI 生成程式碼是否能被安全地審閱）。Zig 語言的創造者 Andrew Kelley 更直接指出：如果 Bun 現有的測試套件連 Zig 版本的缺陷都抓不到，為什麼同一套測試就能作為百萬行新程式碼的充分證據？規模是真的，成本也是真的，審閱的挑戰也是真的——但這些被埋在段落尾端，而「1000+ agents in one window」被放在標題裡。
放到命名週期裡看
如果把 Graph Engineering 放到 AI Coding 的命名週期裡看，它的角色就更清楚了。
Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering → Graph Engineering——每一層其實都只是往外包了一圈。Prompt 是最內層的輸入設計，Context 是圍繞 prompt 的資訊管理，Harness 是包住 context 的機制控制（權限、工具、持久化），Loop 是讓 harness 重複執行（嘗試 → 檢查 → 修正 → 再來），Graph 是讓多個 loop 協調（平行跑、交叉驗證、收斂結果）。
它們是嵌套關係，不是替代關係。但「嵌套」不好賣，「取代」才有流量。
有一段搜到的討論講得最清楚：真正改變的不是電腦科學，而是 AI 讓啟動另一個 agent 變得如此便宜，以至於結構決策從工程師手中遷移到了從未聽過 DAG 的人手上。術語是換名，但做這個決策的人口確實是新的。
而 LangChain 團隊的反應大概是最到位的——他們用 LangGraph 做圖結構 agent 系統已經三年了，每月超過六千五百萬次下載。Harrison Chase 帶著幾乎忍不住的笑意說：「So i didn’t really know what graph engineering is, and i still don’t really… but it’s basically just langgraph?」（所以我其實不太知道 graph engineering 是什麼，現在還是不太知道…但這基本上就是 LangGraph 吧？）XState 的作者 David Khourshid 更乾脆：「First it was loops. Now it’s graphs. Next month it’ll be something else.」（先是迴圈，現在是圖，下個月又會是別的東西。）
我的觀察
Graph Engineering 作為 Dynamic Workflow 的設計入門指南，對完全沒接觸過 DAG 編排概念的人有教育價值。它的核心洞察——把「and then」跟真正的資料依賴區分開來——確實是一個有效的意識喚醒。Anchor 的概念也指向了一個真實的問題。
但它被包裝成了一個新的工程範式，這個定位是膨脹的。它的技術內容就是 DAG 工作流編排，做了十幾年的東西。真正驅動命名的不是技術突破，而是內容經濟的需求——每一輪 AI Coding 的話題都需要一個新標籤來維持注意力。
而它最大的缺失，是它教人怎麼把圖畫得更寬，但沒有教人判斷什麼時候不該畫圖——而後者才是大多數人真正需要的能力。
一個好的主管在組團隊之前，會先問：這個案子的規模值不值得開團隊？每個成員的能力是否可靠？分工的溝通成本會不會吃掉並行省下的時間？Graph Engineering 跳過了這三個前置判斷，直接從「怎麼分工」開始教。
它給了你一把更大的鋤頭，但沒有教你先看看腳下是不是真的有地要翻。
參考資訊
原始討論源頭：
- Peter Steinberger 原始推文（2026.7.18）： https://x.com/steipete/status/2078277297791189132
- Harrison Chase 回應推文： https://x.com/hwchase17/status/2079219804951683380
本文主要分析的文章：
- codila / @0xCodila，Graph Engineering: build 1000+ agent loops in one window, from one prompt (full 5-step course)：
https://x.com/0xCodila/status/2080344428179259846 - Jarred Sumner，Rewriting Bun in Rust（Bun 官方部落格，2026.7.8）：
https://bun.com/blog/bun-in-rust - Andrew Kelley（Zig 語言創造者）的回應（2026.7.9）：
https://www.theregister.com/devops/2026/07/14/zig-creator-calls-buns-claude-rust-rewrite-unreviewed-slop/5270743 - LangChain 官方回應，3 Years of Graph Engineering with LangGraph（2026.7.22）：
https://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph
