延伸觀點：Graph Engineering 的定位

Graph Engineering 是 2026 年 7 月在社群裡開始流行的名字。概念不新——分散式系統設計、工作流引擎、DAG 排程器早就存在。新的是把這些工具和思維應用到 LLM / AI Agent 系統上。

這最後一課，把學到的東西放回大脈絡裡。

三層不替代，是疊加

層次	設計什麼	工具舉例	何時學
Prompt Engineering	一個提示	角色設定、CoT、few-shot	入門就學
Loop Engineering	一個迴圈	Hooks、Skill、Review Gate	有自動化需求時
Graph Engineering	多個迴圈的拓撲	Node、Edge Contract、DAG	系統有多個 loop 互動時

你不會因為學了 Graph 就不需要好的 Prompt。每一層解決不同粒度的問題。Graph 管的是「loop 跟 loop 之間怎麼接」，不是取代 loop 內部的設計。

跟 Harness Engineering 的關係

如果你上過這個平台的 Harness Engineering 課程，你會發現 Graph Engineering 跟它有交集：

• Harness Engineering 關注的是「如何駕馭一個 AI Agent」——權限、工具、規則、觀測
• Graph Engineering 關注的是「多個 Agent 之間如何組成系統」——拓撲、邊的合約、routing

一個是單體的治理，一個是系統的編排。兩者互補。

你現在可以做的事

學完這十課，你不一定要立刻建一套自動化系統。但你可以：

1. 把現有工作流畫出來

不用新工具。拿一張紙，把你最常做的工作流畫成圖。標上節點類型、連上邊、找出缺 contract 的地方。光是這一步，就能讓你看到以前沒注意到的問題。

2. 跟 AI 協作時更精準地描述需求

以前：「幫我做一個客服自動化系統。」 現在：「我需要一張 DAG：客戶訊息進來 → Router 根據意圖分流 → 三條路徑各有 Agent → 結果匯到品質審查 Gate → 通過後回覆客戶。生成→審查的邊需要 Edge Contract，schema 包含回覆文字和信心分數，timeout 30 秒。」

用精確的詞彙描述需求，AI 回來的架構就更貼近你要的。

3. 判斷什麼時候不需要 Graph

這跟知道什麼時候需要一樣重要。大多數任務用 Prompt 或 Loop 就夠了。能判斷「這裡不需要 Graph」本身就是一種工程能力。

一句話帶走

Graph Engineering 的核心不是畫節點——是設計邊的合約。

節點可以換。邊的合約是系統的骨架。

先定義邊，再畫節點。

AI 協作：學了這個，跟 AI 怎麼配合？

你現在對 AI 的角色認知從三層升級了：

你的角色	對應層次
Prompt 寫手	Prompt Engineering
循環設計師	Loop Engineering
系統架構師	Graph Engineering

你的人類優勢：

• 看到全局的拓撲——哪裡有隱含的依賴、哪裡有風險集中
• 做出 trade-off 決策——成本 vs 品質 vs 速度，只有了解業務的人能決定

可以這樣跟 AI 說：

我有一個完整的工作流圖（貼上描述），包含 X 個節點和 Y 條邊。幫我做一次全面健康檢查：節點分類是否合理、有沒有多餘的節點、邊的 contract 有沒有漏洞、是否需要升級到框架工具。