Graph Engineering
Graph Engineering 是把複雜的 agent 任務表示成一張有向圖或狀態機：每個節點負責一個可測試的步驟，邊定義交棒與判斷，外部狀態保存進度、成本、產出與來源。這讓沒有先後依賴的工作可以平行執行，失敗時只重做受影響的節點，任務也能暫停、等待人核准，或由另一個模型接手。
BusinessNext 的術語導讀把它放在 Prompt、Context、Harness、Loop 之後，但也明確指出業界尚未對這些層級的上下關係形成共識。因此本頁把 Graph Engineering 當成可重用的設計模式與來源術語，不把它當成已定型的標準或獨立 benchmark。
與其他工程層的關係
| 層 | 主要控制面 | 最小問題 |
|---|---|---|
| Prompt Engineering | 單次指令 | 這次要模型回答什麼？ |
| context-engineering | 當下可見資訊與記憶 | 下一步需要哪些 context？ |
| harness-engineering-for-ai-coding | 工具、護欄、觀測與驗收 | 模型怎麼安全行動並知道對不對？ |
| loop-engineering | 觀察、執行、檢查、重試 | 怎麼持續推進同一項工作？ |
| Graph Engineering | 多節點、交棒、狀態與預算 | 多個 agent／loop 如何組成可恢復的長任務？ |
這不是取代關係，而是包覆關係的設計假設：Graph 可以管理多個 loop，loop 依賴 harness 的 feedback，harness 又要使用合適的 context 與 prompt。實際系統仍應以任務證據決定是否需要再加一層，不能因為名詞流行就預先建立圖編排框架。
三個最小設計原則
- 節點單一責任：每一步只做一件事，能單獨測試、替換與重做。
- 把判斷放在交棒處：能用 deterministic rule 決定的就不要交給模型；需要語意判斷的交棒點要設成高風險觀測與人工核准位置。
- 外部化狀態與預算：每完成一步就保存固定格式的狀態、產出、來源、耗時與成本，並強制設定時間、次數或 token 上限。
何時值得使用
Graph Engineering 適合有平行分支、長時間執行、可等待人核准、局部失敗重做，或需要跨模型／跨 session 接手的任務。小型一次性任務通常用單一 agent、清楚的 agent-skills 或一般 loop-engineering 更便宜；只有當「中途失敗就得整批重來」成為實際痛點時，才值得把狀態與交棒畫成圖。
AI Ark 的應用
AI Ark 的 watch → queue → ingest → verify 目前仍是小型、可檢查的 loop，不需要為了 Graph Engineering 立即加入 workflow engine。若未來來源掃描、raw capture 與驗證出現可平行且可恢復的長任務，可以先把 queue record、raw path、hash、wikilink 與 index coverage 當成節點 evidence，再決定是否拆成圖；這與 aiark-loop-engineering 的「先留下 artifacts，再抽象化」原則一致。
相關頁面
- dynamic-agent-workflows — 依工具回饋動態調整策略
- harness-engineering-for-ai-coding — 提供工具、護欄、感測器與驗收
- loop-engineering — 把單項工作變成可持續推進的閉環
- context-engineering — 管理每一步真正需要的資訊
- agent-teams-vs-dynamic-workflows — 多 agent 協作模式的差異
- aiark-loop-engineering — AI Ark wiki 的最小 watch／ingest／verify loop