風險與邊界

Graph Engineering 讓你的 AI 系統更有結構。但用錯了，結構本身會變成問題。

風險一：過度設計

三個節點能解決的事，你畫了十五個節點加二十條邊。每加一個節點就多一個可能出錯的點、多一條需要維護的邊。

判斷方法：如果你畫完圖之後，發現有些節點只是「為了好看」而存在——它的輸入和輸出跟前後節點完全一樣——那就該合併。

口訣：先用最少的節點跑通，真的痛了再拆。

風險二：忘記停止條件

Self-loop 沒有 max retry。兩個 Agent 互相 review 形成無限迴圈——A 叫 B 改，B 改完叫 A 看，A 又叫 B 改。

每一次迴圈都在燒 token。如果沒人設停止條件，一個小時後帳單可能已經噴了幾百塊。

解法：任何有環的拓撲，都要有斷路器。最簡單的斷路器是「最多 N 次」。進階一點的是「N 次之後 escalate 到人工 Gate」。

風險三：隱含的循環依賴

你以為畫的是 DAG（無環），但實際上某兩個節點之間有隱含的雙向依賴。

電商例子：「定價 Agent」需要「庫存 Tool」的數據，但「庫存 Tool」的觸發條件依賴「定價 Agent」的輸出。這形成了一個隱含的環。

發現方法：從每個節點出發，追蹤它的所有下游。如果追到最後回到了自己，你有一個環。環不一定是錯的（狀態機本來就有環），但你必須知道它在哪，而且設了停止條件。

風險四：Edge Contract 太鬆

Schema 寫「任意字串」、budget 寫「不限」、error 寫「不處理」。等於沒寫。

真實案例：Agent A 產出了一份 8,000 token 的分析報告，全部塞給 Agent B。B 的 context window 只有 4,096 token。結果：B 收到截斷的輸入，產出了一半正確一半亂講的回覆。沒人發現，因為回覆「看起來」很正常。

解法：Edge Contract 要寫得跟你願意用「這個合約出問題我負責」的承諾一樣嚴格。不確定的欄位用 optional，但必填欄位絕對不能省。

風險五：把什麼都畫進圖

不是所有事情都該放進圖裡。登入驗證、日誌寫入、錯誤監控——這些是基礎設施，不是工作流的節點。把它們畫進圖只會讓圖變得無法閱讀。

判斷方法：這個步驟跟「完成業務目標」有直接關係嗎？有 → 畫進圖。沒有 → 放在圖的外面，作為基礎設施處理。

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

請 AI 幫你做圖的健康檢查。

你的人類優勢：

• 判斷「夠不夠簡單」——AI 傾向建議更多節點，人要能說「這個不需要」
• 判斷哪些環是故意的、哪些是 bug——業務流程有些地方本來就要回頭，不是每個環都要消除

可以這樣跟 AI 說：

我畫了一張工作流的圖（貼上你的圖描述）。幫我檢查五個風險：1) 有沒有可以合併的節點 2) 有沒有沒設停止條件的環 3) 有沒有隱含的循環依賴 4) 有沒有 Edge Contract 太鬆的邊 5) 有沒有不該放進圖的步驟。