開發者使用AI的方式正在從叫一個AI回答問題，轉變為指揮一群AI分頭把一整個專案做完。而怎麼安排這一群AI，正是Graph Engineering（圖結構工程）成為AI領域最新熱門詞的原因之一。透過將AI要做的事，事先安排成一張清楚的流程圖，賦予AI處理一整件複雜工作的能力。
Graph Engineering是什麼？
簡單來說，Graph Engineering就是事先把AI要做的事，安排成一張清楚的流程圖。而這張流程圖只有三個東西：
- 一個個工作步驟，每一步只負責做一件事
- 步驟間的交棒關係，清楚劃分每一步的成果，接下來交給哪一步
- 完整進度紀錄，將進度、成本、產出全數記錄下來
這種先畫好圖的作法，讓AI可以同時進行多項任務，圖上沒有先後關係的步驟能一起跑，不必排隊乾等，要是出錯也可以即時挽回重做，並且任務可以隨時喊停，甚至換個AI模型也能接手執行。
prompt、context、harness、loop這些「工程」是怎麼一路長出來的
而Graph Engineering的誕生，以及這幾年冒出的提示工程（Prompt）、情境工程（Context）、駕馭工程（Harness）、迴圈工程（Loop）都是為了讓AI更有效率，準確無誤地完成任務。自2022年ChatGPT問世以來，開發者圈一直在鑽研如何運用AI，並且隨著AI變得越趨複雜、強大，不斷改良用法。
最初，大家很快發現：同一個問題，換個問法，答案品質天差地遠。於是第一門功夫叫提示工程，研究怎麼把一句話、一段指令寫好，讓模型給出你要的東西。有一陣子「提示工程師」還一度被當成當紅的新職稱。
但光是修飾提示詞，很快就遇到瓶頸。真正的應用不是一句話問得完的，模型還得先看過對的文件、資料和前面的對話，才答得準。因此重點轉為如何讓AI拿到剛剛好的資料。
2025年年中，Shopify執行長路特克（Tobi Lütke）和AI學者卡帕西（Andrej Karpathy）先後在社群平台X上公開改用「情境工程」這個說法，這個詞很快就取代了提示工程的位置。卡帕西給的定義很傳神：在模型一次能看的內容裡，剛好放進下一步需要的資訊，是一門細膩的功夫。
很快地，大家發現光是準確提供資料還不夠，想讓AI真的動手做事，就得幫它準備一整套設備與工具、防止它亂來的安全護欄，還有隨時監看它在做什麼的機制。而這套系統被命名為「駕馭工程」。
就算工具設備一應俱全，還是得人類時時盯著AI做事、一步步下指令。能不能讓AI自主作業、檢查結果進行修改？這樣的探索成為近期流行的迴圈工程。卡帕西前陣子公開的實驗專案autoresearch就是最好的例子，他讓AI自行跑實驗、檢查結果，不僅可以自動化研究、縮短整體時間，還找出人類沒注意到的設定。
但迴圈工程仍有其侷限，AI一次只能做一件事，一出錯就得全部重來，且記憶相當脆弱，一次能記住的內容有限，前面的記憶會慢慢被擠掉。於是有人主張更進一步，畫出完整的工作流程，成為現在受到討論的Graph Engineering。
這些AI工程的名詞，可以歸納如下：
Prompt Engineering：控制單次回答的指令。
Context Engineering：控制模型當下能看到的資訊與記憶（如 Karpathy 與 Tobi Lütke 提倡的概念）。
Harness Engineering：為模型搭建防護欄、工具調用介面與監控環境（Agent = Model + Harness）。
Loop Engineering：讓 AI 自主進行「觀察–執行–檢查–重試」的自動化循環（如 Karpathy 的 autoresearch 專案）。
Graph Engineering：當任務太過複雜時，將多個 Agent 或 Loop 組織成一張有向圖（Directed Graph）/ 狀態機。
不是誰取代誰，而是層層相依
不過，這些工程不是一代把前一代淘汰掉，而是一層包住一層，補強舊方法的侷限，讓AI能處理更複雜的任務。
AI雲端平台Databricks在技術部落格上形容，提示工程和情境工程，其實都住在駕馭工程「裡面」；駕馭工程指的是模型外圍的整套系統，提示和情境只是這套系統裡的零件。同理，迴圈是把「駕馭」那套外圍再自動化地跑起來，而圖則是把「很多個繞圈的AI」再組織、管理起來。
也就是說，過去熱門的提示工程仍然有用，只是從主角變成更大型系統的零件，在每個步驟依然用得上。
但要注意的是，目前這幾層工程誰上誰下、誰包住誰，還沒有業界共識，有人認為迴圈在駕馭之上，但也有人直接排除駕馭工程不談，總之，這幾層到底怎麼排最合理，目前還沒有定論。
畫成圖實際上要怎麼做？三個原則
那實務上到底怎麼把工作畫成圖？綜合開發者社群的實作心得，可以整理成三個簡單好懂的原則：
一、每個步驟只做一件事
把工作切成一個個單純的步驟，每一步最好只做一件事、可以單獨測試、可以整個換掉而不影響別的步驟。如果一個步驟塞了五件事，那它其實就跟過去的作法沒兩樣。
二、把判斷放在「交棒」的地方，並分清楚哪些不用AI
步驟之間怎麼交棒，可以用兩種方法決定，一種是死規則，例如「測試通過就自動上線」；另一種則是交由AI判斷，例如「這張客訴單該轉給帳務還是檢舉部門」。
開發者的任務，是界定好哪些步驟可以用死規則決定，而哪些需要靠AI判斷。需要AI判斷的地方，也正是它以後最容易出錯的地方，要特別盯緊。
三、把進度好好記下來，並設好花費上限
把做到哪、產出什麼資料，都記在一份獨立、格式固定的紀錄裡，每做完一步就存一次檔。這樣一來，出錯時只要重做壞掉那一步就好，不必整批重來。這對長時間的任務格外重要，它可以停在中間等人核可三天，整個任務不會因此停擺。
同樣重要的是花費上限：用了多少運算成本、花了多少時間，都要寫進紀錄、並在過程中強制執行。如果你沒辦法在費用碰到上限時把AI停下來，那它就不算是能自己運作的系統，只是在不停把錢燒掉而已。
Graph Engineering真正的價值，是強行打開AI的黑盒子，將進度、判斷、花費、來源等過去過去藏在AI運作裡、看不到的資訊攤在陽光下、寫成清楚的規則。
當任務規模還小時，Graph Engineering不是當務之急，但當你開始為了「做到一半當掉、又得整批重來」而困擾時，也許就是把整個流程好好畫清楚的時候了。
資料來源：X、Josh C. Simmons 本文初稿為AI編撰，整理．編輯/陳建鈞
