Graph Engineering：問題不在 Node，在 Edge Contract

系統裡已經有好幾個 loop——pre-commit、cross-model review、RAG feedback——但它們之間靠 if-else 硬接。兩個 loop 搶同一份 context，沒人管。一個失敗了，下游還在燒 token。

這時候多半有人會說：換更強的模型、寫更嚴的 prompt、上一個 workflow 框架。

我後來覺得，真正缺的不是更亮的節點，而是邊的合約。

社群把這層工作叫做 Graph Engineering：用節點（Agent、Tool、Router、Gate）和邊（資料流、條件、依賴）設計 AI 系統拓撲——接在 Prompt Engineering 與 Loop Engineering 之上。名字是新的；我對它的第一反應不是「原來如此」，而是「等一下，這不就是我過去一年在做的事嗎。」

三層演進：你什麼時候會需要 Graph

上一篇講過 Prompt → Loop。Graph 是同一條線的延伸：

• Prompt Engineering：設計一個提示
• Loop Engineering：設計一個迴圈（做 → 驗證 → 修正）
• Graph Engineering：設計多個迴圈組成的拓撲

你不會在一開始就需要 Graph。

需要它的時刻很具體：單個 loop 已經穩了，痛點變成「loop 與 loop 之間」——觸發順序、context 歸屬、失敗是否該切斷下游。那時候更好的 prompt 幫不上忙，更嚴的單環驗證也不夠。你需要一張可以審視的圖。

我的 Council 就是一張 Graph

過去一年我設計了一套 multi-agent 協作：路由、審查、briefing 規範，最多七個 agent。我一直叫它 Council Protocol。

對上 Graph Engineering 的詞彙之後，才看清楚——我已經在手動做拓撲設計，只是沒把「邊」當成一等公民。

Council Routing ≈ Conditional Branch

四個 preset，條件由簡到重：

• fast-path：單檔 ≤3 行、可逆 → 一人直接做
• solo+review：一般實作 → 實作 + 另一模型 review
• council-lite：跨系統、中風險 → 再加分析視角
• full-council：不可逆、治理級 → 全員

每次先問：scope 多大？跨不跨邊界？可不可逆？能不能本地驗證？任一命中就升一級。

這在拓撲上就是 Conditional Branch：Router 依條件把流程導向不同路徑。我寫在 Markdown 與協議裡，不是寫在 StateGraph 裡。

拓撲與決策邏輯可以同構；執行載體不必相同。 Markdown 路由沒有框架級的狀態持久化、可觀測性與統一 retry 原語——七人規模勉強；再大，runtime 會變成硬需求。承認這點，比假裝「效果完全一樣」有用。

ACE 盲審 ≈ Fan-out + 有條件的匯合

協議裡有「盲審雙階段」：

Phase 1：多個 agent 基於同一份 briefing 獨立分析，禁止看彼此的中間產出。

Phase 2：Chair 發現意見衝突時，才把對方的 claims（連同 evidence 指向）交給雙方做二輪修正。

Phase 1 是 Fan-out。Phase 2 依「有沒有衝突」決定要不要進入對質——是帶條件的狀態轉移，不是無腦全連接。

設計時想的是避免 anchoring bias。回頭看，那是一張有條件邊的有向圖。

Briefing 規範 ≈ Edge Contract（傳輸面）

這是最關鍵的對應。

每份 agent briefing 至少四段：

• TASK → 這條邊要傳遞什麼工作
• CONTEXT → 允許帶過界的上下文（context budget 的上限思維）
• CONSTRAINTS → 下游不能做的事（scope / 權限邊界）
• VERIFY → 產出如何驗收（格式、檢查項、完成定義）

這不是從教科書抄來的。是被誤解搞了幾次，被迫收斂的。

第一次：agent 自己擴大 scope，改了不該改的檔案 → 加 CONSTRAINTS。
第二次：回覆形狀和預期不同，downstream 全壞 → 加 VERIFY。
第三次：對方卡住約 60 秒不回應，整條 pipeline 停擺 → 加 timeout / 停損規則（這條往往寫在 runner 與協議，不只寫在四段標題裡）。

完整的 Edge Contract 至少還要能回答：失敗 retry 幾次、fallback 去哪、逾時怎麼算。 Briefing 四段管的是「允許傳什麼、驗什麼」；retry / timeout / fallback 是 runtime policy，可以和 Markdown 規範分開演進，但不能沒有。

還有一條我後來才釘死的邊界：

Edge Contract 定義的是傳遞語意——允許帶什麼、禁什麼、如何驗收。它不取代證據原件。 下游若只能吃上游摘要、無法指向 raw diff / log / 規格路徑，那條邊仍然很脆。合約管通道；真相仍應可被點名讀取。

每次事故之後，規範就多一條。我是在事故裡手動演化 Edge Contract，不是先畫好框架再填空。

不是 Node，是 Edge

一年 Council 經驗裡，最大的判斷是這個——也是多數 Graph 文章沒講死的：

Graph Engineering 最難的不是設計節點，是設計邊。

節點可以換。今天 Claude，明天 Gemini，後天本地模型。模型升級、API 改版、價錢變了——換節點。

邊不能隨便換。每條邊至少帶著：

• Schema：進出資料的形狀
• Context Budget：傳給下一節點的上下文上限
• Error Contract：失敗時 retry、fallback、是否切斷下游
• Timeout：等多久算死

改 schema，上下游一起動。改 error contract，整條 fallback 路徑要重驗。這和微服務 API contract 是同一類問題——差別是服務變成 LLM，輸出非確定，所以 contract 更重要，不是更不重要。

我花了大半年才學到：先定義邊，再畫節點。

你可能已經在做了

符合任一條，你多半已在做 Graph Engineering，只是圖還散落在習慣裡：

• 有 routing 決定任務走哪個 agent 或哪條流水線
• 有 briefing / template 約束 agent 之間的輸入輸出
• 有多個 review、verification loop 互相依賴
• 有 fallback（A 失敗走 B）

下一步通常不是立刻學某套 Graph 框架，也不是先買 workflow 引擎。

下一步是：把現有的 routing 與交接規則寫成一份可版本化的描述——JSON、YAML、一頁 Markdown、白板拍照都行。目標只有一個：讓隱性拓撲變成可審視、可挑戰、可迭代的顯性圖。

圖一攤開，缺 contract 的邊、沒 fallback 的節點、隱含的環——才會變得難看、也才值得修。

我的手動 Council 在約七個 agent 的規模還跑得動。再放大，就需要真 runtime：LangGraph、Temporal、或自建 DAG。規模變了，工具會變；設計邊的 contract 這件事不會變。

Loop 是 function。
Graph 是 call graph + 拓撲 + runtime policy。

把已經在做的事畫出來。你會先看到哪些邊還只是 if-else 與口頭約定——再決定要不要上 engine，會比先買引擎再找問題便宜。

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。