别再盲目追新词！ 从工程视角看透Loop与Graph之争

講者首先指出當下 AI 工程界的焦點問題：用 Agent 寫代碼越來越累，模型改了十分鐘不但沒修好還把正常代碼改崩。表面上看是模型不聰明，但根本原因往往是控制流、狀態管理和驗證出了問題。正因為這樣，整個技術圈最近為「Loop vs Graph」炒翻了天。

這場討論的引爆點發生在 2026 年 7 月，開發者 Peter Steinberger 在推特上拋出靈魂拷問：「我們還在談 Loop 還是已經轉向 Graph？」隨後，另一位大佬 Hamel Hussain 用一篇標題煽動的文章《Loop Engineering is Dead, Enter Graph Engineering》回應，點進去才發現文章只有一個句號和一段搞笑影片——這其實是在嘲諷技術圈的名詞通膨現象。每隔幾個月就會發明新詞彙：prompt engineering、context engineering、loop engineering，現在又來 graph engineering。

但講者強調，我們不能因為討厭新名詞就無視背後的真實工程挑戰。對於簡陋的 Loop 實現，最大的問題是架構設計缺陷。最常見的做法是把所有東西——歷史記錄、工具調用結果、事實、錯誤——全都塞進越來越長的對話上下文。這樣做的後果是模型分不清什麼是事實、什麼是它自己猜的，而且串行執行太慢，一步失敗整個任務可能得從頭來過。

Graph Engineering 其實不是突然出現的新算法，工作流、狀態機、DAG 早已存在。它的本質是：當系統從單 Agent 複雜化，涉及多個 Agent、確定性代碼、驗證器，甚至人工審批時，你需要把他們組織成一個可控制、可審計的執行網絡。Loop 和 Graph 不是誰替代誰的關係，而是不同層級的問題。Anthropic 在《Building Effective Agents》中提到的路由、並行、編排器、工作者模式，其實已經具備了圖的結構。

針對如何做好執行編排，講者列舉了三個比較有共識的工程做法。首先，把狀態外置。別再把聊天記錄當資料庫了，任務的計畫、驗證過的事實、執行的檢查點這些都要變成結構化的資料存起來，狀態字段應該有明確的所有者，模型不能隨便覆蓋事實。其次，明確節點和邊的契約。不一定非得是模型決定下一步，涉及權限、預算和不可逆操作時必須交給確定性的代碼、規則或人工審批。最後，小心使用並行和循環。並行能加快速度但帶來結果冲突，而對於循環，如果驗證失敗不要簡單讓 Agent 再試一次，回復必須携帶具體失敗原因、證據和建議的修改範圍。

然而，Graph 並非萬能藥。它無法修復錯誤的目標、評價標準和外部事實依據。如果系統目標本身就是偏的，或驗證器依賴同一個有偏見的模型，那麼 Graph 只會讓你的系統更快更系統地做錯事。此外，動態圖（讓模型自己生成工作流和節點結構）聽起來很酷，但若缺少足夠的約束，可能生成無限分支、瘋狂消耗成本，甚至繞過安全審批。

講者強調的務實原則是：不要盲目追逐新概念。如果你的任務很短、探索性強、失敗了重來成本不高，那就老老實實用 Loop。但如果任務有可並行的分支、需要不同 Agent 的隔離上下文、需要檢查點恢復或需要準確審計執行路徑，這時候更好的執行編排帶來的收益才大於它增加的複雜度。一個務實的做法是：先給單個 Agent 設置明確的驗收標準、截止期限和停止條件，看看它能否收斂；如果不能，再把狀態外置、加上獨立驗證和失敗回復；最後才考慮複雜編排。不要為了畫圖而畫圖，工程的本質是解決問題，而不是堆砌複雜度。

最後，講者展望工業級系統的方向：絕對不會是模型在裡面隨意狂奔，而是模型提議、運行時約束、外層可編程執行引擎來約束節點類型、全線預算和副作用。Anthropic 的 Dynamic Workflows 已經展示了這個方向——執行 JavaScript 的工作流、協調 Agent 的支持、恢復和並行能力。我們需要的是可控的智能，而不是失控的黑盒。