邊：不只是一條線

你已經會辨認節點了。現在來看連接節點的東西——邊。

多數人畫工作流的時候，邊就是一條箭頭，意思是「做完 A，接著做 B」。但在 Graph Engineering 裡，邊不只是順序，它帶著合約——規定傳什麼資料、什麼條件才觸發、失敗了怎麼辦。

先說兩種基本的邊。下一課再展開合約的細節。

兩種邊

Data Flow（資料流）

A 做完把結果傳給 B。最常見的邊。

電商例子：「訂單查詢 Tool」查到訂單資料 → 傳給「回覆生成 Agent」。這條邊帶的資料是一個訂單物件（訂單編號、狀態、金額、商品列表）。

Condition（條件邊）

只在特定條件成立時才觸發。Router 節點的輸出通常是條件邊。

電商例子：「意圖分類 Router」判斷客戶要退貨 → 才觸發「退貨處理 Agent」。如果客戶是查單，這條邊不會觸發。

在圖上，Data Flow 通常畫成實線箭頭，Condition 畫成虛線箭頭。

邊帶著什麼

每條邊至少要回答三個問題：

1. 傳什麼？（Schema）

從 A 到 B 的資料長什麼樣子。不定義清楚，B 拿到的東西可能不是它預期的格式。

訂單查詢 → 回覆生成
傳遞：{ order_id, status, amount, items[] }

2. 什麼時候觸發？（Condition）

Data Flow 是「A 做完就觸發」。Condition 邊則需要明確的條件。

意圖分類 → 退貨處理
條件：intent == "return"

3. 傳多少？（Budget）

LLM 有 context window 限制。如果上游產出了一萬字的分析報告，你不一定要全部傳給下游。Budget 決定裁剪策略。

報告生成 → 摘要審查
預算：≤ 2,000 tokens（只傳摘要，不傳全文）

常見的邊設計錯誤

把所有東西都傳下去：A 的完整輸出直接塞給 B，沒有裁剪。結果 B 的 context window 爆了，或者成本暴增。

沒有定義條件邊的 else：Router 說「如果是退貨就走這裡」，但沒定義「不是退貨」的時候走哪裡。結果碰到意外的意圖類型，整張圖卡住。

忘記邊也會失敗：A 到 B 之間的傳輸也可能出問題——格式不對、超時、B 掛了。邊需要自己的錯誤處理策略。

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

當你請 AI 設計工作流時，不只要描述節點做什麼，還要描述節點之間傳什麼。

你的人類優勢：

• 決定哪些資料該傳、哪些不該傳——這涉及隱私和成本的 trade-off
• 定義條件邊的觸發條件——業務邏輯只有你清楚

可以這樣跟 AI 說：

我的工作流有三個步驟：1) 客戶問題分類 2) 查知識庫 3) 生成回覆。幫我定義每條邊傳遞的資料格式（schema），並建議每條邊的 token 預算上限。