--- title: "圖工程：建構 AI 代理工作流程的設計原則" locale: zh-hant category: ai_data category_name: "AI 資料" translation_status: reviewed license: cc_by author: "injoys" source_url: https://injoys.com/en/articles/graph-engineering-ai-agent-workflow-guide published_at: 2026-08-21T02:29:06+09:00 --- # 圖工程：建構 AI 代理工作流程的設計原則 > 圖工程是一種將複雜的 AI 任務拆分為節點與轉移規則，並明確設計狀態、驗證、故障復原及使用者核准的做法。關鍵不在於將所有步驟都交給 AI，而是區分程式碼、模型與人員的角色。 ## Key Points - 圖工程設計的並非模型的一次回答，而是整項任務的路徑、狀態、分支、反覆執行及終止條件。 - 節點執行任務，邊定義移動路徑，狀態在各步驟之間傳遞資料，而條件則選擇下一條路徑。 - 路由、平行執行、生成者與評估者的反覆迭代，以及使用者核准，都是具代表性的代理圖模式。 - 將格式驗證與數值比較等確定性任務交由程式碼處理、模糊的解讀交給 AI、高風險決策交由人員負責，通常較為有利。 - 可投入營運的圖需要狀態結構描述、重試上限、防止重複執行、可觀測性、權限邊界與成本預算。 圖工程（Graph Engineering）並非只提升單一 AI 模型的回答品質，而是一種設計多項工作與工具應按何種順序及條件執行的方法。將複雜業務表示為節點及其連接關係後，便能分開管理各階段的輸入與輸出、失敗原因、重試路徑，以及需要人工核准的節點。 不過，這個說法目前尚不是整個業界一致認可的單一標準術語。更準確的理解是，它是一個涵蓋代理工作流程設計、圖形化編排及多代理控制的實務概念。 ## 圖形出現在 AI 工程中的背景 AI 應用程式的設計關注點已按以下方式逐步擴展。這並非所有組織都會以相同方式經歷的正式發展階段，而是彼此互補的設計層次。 | 層次 | 核心問題 | 主要設計對象 | |---|---|---| | 提示工程 | 該如何向模型下達指示？ | 指示、範例、輸出格式 | | 上下文工程 | 該用哪些資訊構成判斷所需的內容？ | 搜尋結果、記憶、工具結果、系統規則 | | 迴圈工程 | 該如何重複進行規劃、執行、驗證與修正？ | 重複條件、評估標準、終止條件 | | 圖工程 | 該透過哪些路徑連接多項工作與判斷主體？ | 節點、轉移、狀態、分支、平行化、核准 | 提示與上下文在圖形中仍然不可或缺。迴圈也可以表示為圖形中的循環邊。因此，圖工程並不是淘汰先前技術的方法，而更接近一種將這些技術配置於執行結構中的高階設計觀點。 ## 圖工程的組成要素 ### 節點 節點（Node）是具有單一明確責任的工作單位。除了呼叫 LLM，資料庫查詢、呼叫搜尋 API、格式驗證、計算、等待使用者核准等一般程式碼也可以成為節點。 良好的節點具有明確的輸入與輸出，且能獨立測試。與其使用「市場調查」這類範圍寬泛的名稱，不如將責任縮小為「收集指定產業的近期資料」、「移除重複來源」、「逐項檢查主張的依據」，這會更有利於除錯。 ### 邊 邊（Edge）是從一個節點移動至下一個節點的轉移。邊可分為每次都移動至相同下一階段的固定邊、檢查狀態後選擇路徑的條件邊，以及同時啟動多項工作的分支邊。 ### 狀態 狀態（State）是圖形執行期間共享的資料。它可能包括使用者請求、中間產出、搜尋來源、錯誤代碼、核准結果及重複次數等。 狀態不同於單純的對話紀錄。哪些欄位為必填、誰可以修改、如何合併平行執行的結果，以及何時刪除敏感資訊，都必須透過結構描述與規則加以定義。 ### 條件 條件（Condition）是選擇下一條路徑的規則。像「來源是否至少有三個」這類確定性條件，可以透過程式碼判定。相較之下，像「依據是否足以支持結論」這類需要語意判斷的條件，可能需要模型評估或人工審查。 ## 比單一代理更容易控制的原因 若將調查、分析、撰寫及驗證全部交給單一代理，結果出錯時便難以區分原因。這是因為規劃錯誤、搜尋遺漏、工具呼叫失敗或無依據生成等問題，都混雜在同一份執行紀錄中。 將工作分解為圖形後，即可逐階段管理以下項目。 - 限制每個節點可使用的工具及資料存取權限。 - 儲存中間產出並進行獨立評估。 - 僅重新執行失敗的節點，以降低成本與時間。 - 在執行重要的外部動作前取得人工核准。 - 追蹤執行路徑、延遲時間、權杖使用量與錯誤。 然而，增加節點數量並不會自動提升可靠性。若狀態傳遞不準確或評估標準模糊，錯誤可能會跨越多個階段而不斷放大。 ## 典型的圖形運用模式 ### 路由器模式 路由器會根據請求類型或風險程度選擇不同路徑。例如，退款諮詢可以傳送至政策搜尋節點，技術故障則可傳送至診斷節點。 若路由標準只是簡單的關鍵字或帳戶狀態，適合使用程式碼。若需要解讀上下文，則可使用模型分類；但信賴度偏低時，需要設置將其傳送至預設路徑或人工審查的安全機制。 ### 平行執行模式 同時執行彼此不相依的工作，再由彙整節點加以合併。平行執行市場、客戶及競爭對手調查，便是典型方式。 平行化可以縮短延遲時間，但會增加呼叫次數與即時成本。如果多個結果會同時修改相同的狀態欄位，也必須制定衝突解決規則與合併順序。 ### 生成者與評估者模式 生成者建立草稿，評估者則依據標準決定通過、修改或重新撰寫。由於評估結果會返回生成者，因此會在圖形中形成迴圈。 若評估者同樣是 LLM，也可能做出錯誤判定。可行的項目應以結構描述檢查、執行測試、確認引用 URL 等確定性驗證加以補強，並且必須設定最大重複次數，以避免無限循環。 ### 使用者核准模式 在變更外部系統、傳送訊息、付款、部署等難以復原或責任重大的動作之前，先停止執行並等待人工判斷。核准畫面與其只顯示最終結果，不如一併呈現即將執行的動作、使用的資料、預期影響及復原方法，會更加安全。 ### 管理者與專家模式 管理者節點會分解工作，將其分配給搜尋、分析、撰寫等專門節點，再彙整結果。角色分工固然實用，但增加代理數量本身不應成為目標。對於固定程序，明確的工作流程可能更具可預測性。 ## 劃分 AI、程式碼與人工角色的原則 | 工作性質 | 優先手段 | 範例 | |---|---|---| | 結果必須一致的明確規則 | 一般程式碼 | 數量計算、日期比較、JSON 結構描述檢查 | | 處理自然語言語意與模糊性的判斷 | AI 模型 | 意圖分類、摘要、草稿撰寫、定性評估 | | 需要責任、倫理或高風險判斷的決策 | 人工 | 對外傳送核准、允許例外、高風險措施核准 | 即使規則明確仍使用 LLM，會不必要地增加成本、延遲及非確定性。反之，若將所有判斷都固定為程式碼規則，便難以處理表達方式多樣的實際輸入。良好的圖形會結合三種手段的優點，並在各個邊界驗證輸入與輸出。 ## 知識圖譜與圖工程的差異 這兩個概念可能有所關聯，但並不相同。 - **知識圖譜**是將人物、組織、文件、概念等實體及其關係結構化的資料表示方式。 - **代理執行圖形**表示工作會按照何種順序與條件執行。 - **圖工程**可指設計執行圖形的結構、狀態、控制、驗證及營運方式的實務。 雖然可以將知識圖譜搜尋連接為一個節點，但圖工程不一定需要知識圖譜。反之，建立知識圖譜也不會自動產生具備重試與核准路徑的代理工作流程。 ## 決定營運品質的隱藏設計要素 僅憑圖形示意圖無法完成正式環境系統。真正左右可靠性的要素，是執行語意及營運契約。 ### 狀態契約與版本管理 必須定義各節點的輸入與輸出結構描述、必填欄位、資料來源及更新權限。為了在變更圖形後仍能繼續執行先前已中斷的工作，也必須管理狀態結構描述與工作流程版本的相容性。 ### 失敗復原與冪等性 若在網路錯誤後重新執行節點，可能會重複傳送電子郵件或重複付款。對於會產生外部副作用的工作，需要使用冪等性金鑰、執行前確認、補償工作或防止重複的儲存機制。 失敗也並非全都相同。必須依錯誤類型區分路徑，例如對暫時性的 API 錯誤進行重試、將錯誤輸入退回給使用者，並在違反政策時立即終止。 ### 終止條件與成本預算 生成者與評估者迴圈必須設定最大重複次數、時間限制，以及權杖或成本上限。若品質提升有限，也需要設定終止或轉交人工處理的條件。 圖形的總成本不能只計算個別模型的呼叫成本，還必須包含重試、平行呼叫、狀態儲存、外部工具及可觀測性系統。 ### 可觀測性與評估 營運紀錄中必須保留執行了哪些節點與模型、選擇了哪些路徑，以及輸入、輸出與錯誤的內容。不過，為避免個人資料、驗證資訊及敏感業務資料原封不動地儲存在日誌中，必須套用遮罩處理及保存期限。 評估不能只看最終回答分數。還必須一併衡量路由準確度、工具成功率、依據滿足率、核准前風險偵測率、平均重試次數等節點與路徑指標，才能找出瓶頸。 ### 安全性與權限邊界 必須考量搜尋文件或使用者輸入中所含指示改變系統規則的提示注入。模型生成的工具引數應在執行前加以驗證，且每個節點只應被授予執行業務所需的最低權限。將讀取、寫入、刪除及對外傳送權限分開，可以降低單一節點的錯誤擴大為整體系統事故的風險。 ## 適合使用圖工程的情況 以下條件重疊得越多，圖形結構的效益就越大。 - 需要依輸入採用不同的專業處理路徑。 - 可以平行執行獨立工作。 - 特定階段失敗時，必須返回指定節點。 - 需要驗證或稽核中間產出。 - 變更外部系統前需要取得核准。 - 執行時間較長，必須能在中斷後繼續執行或保存狀態。 - 必須區分各工具的權限與資料存取範圍。 對於簡單摘要、單次分類或簡短問答，單一模型呼叫或短小的循序管線會更合適。如果導入圖形所產生的狀態管理、測試、觀測與部署負擔，大於所獲得的效益，就是過度工程化。 ## 設計審查檢查清單 1. 以可衡量的形式定義最終結果與成功標準。 2. 將每個節點限制為單一責任及可測試的輸入與輸出。 3. 以程式碼實作明確規則，並將 LLM 的判斷範圍降至最低。 4. 定義狀態結構描述及平行結果的合併規則。 5. 區分可重試的錯誤與應立即終止的錯誤。 6. 設定重複次數、執行時間及成本的上限。 7. 為具有外部副作用的節點設置防止重複執行的機制。 8. 在高風險動作之前安排人工核准並提供充分說明。 9. 制定各節點與路徑的日誌、評估指標及個人資料保護規則。 10. 再次確認是否無法以更簡單的結構達到相同的可靠性。 ## 核心整理 如果說單一代理就像一次將多項工作交給一名能幹的員工，那麼圖工程則更接近設計組織角色、工作傳遞路徑、審查程序與核准層級。 核心並非代理的數量，而是可控制的結構。必須明確界定 AI 在哪些階段進行判斷、程式碼在哪些環節進行驗證，以及何時由人工做出負責任的決策。此外，還必須具備狀態契約、失敗復原、可觀測性、權限控制及成本上限，圖形才能超越單純的示意圖，成為可實際營運的 AI 系統。 ## FAQ ### 什麼是圖工程？ 這是一種將複雜的 AI 工作拆分為節點，並明確設計工作之間的移動路徑、共享狀態、分支條件、重複與核准程序的方法。與其說是整個業界一致認可的單一標準術語，不如說是用來描述基於圖的代理協調之實務性表達。 ### 圖工程與提示工程有何不同？ 提示工程處理的是要為個別模型呼叫提供哪些指示與範例。圖工程處理的是要以何種順序和條件連接多次模型呼叫、程式碼、工具與人的判斷。提示仍會持續用於構成圖的各個節點內。 ### 圖工程與知識圖譜是相同的概念嗎？ 不是。知識圖譜是將實體與關係結構化的資料，而代理執行圖則呈現工作順序與控制流程。雖然可以將知識圖譜搜尋用作執行圖的一個節點，但任一方都不是另一方的必要條件。 ### 所有節點都必須做成 AI 代理嗎？ 沒有必要。像是數量計算、日期比較、格式檢查等結果明確的工作，使用一般程式碼會更快、更便宜且更可預測。適合將自然語言解讀與定性判斷交給 AI，將責任重大或難以復原的決策交給人。 ### 生成者與評估者迴圈如何防止無限重複？ 必須預先設定最大重複次數、時間與成本上限，以及通過標準。還需要設定終止條件，當重複執行仍無法改善品質，或評估的信心程度偏低時，傳回先前的最佳結果，或送往人工審查路徑。 ### 多代理系統總是比單一代理更好嗎？ 不是。角色增加時，呼叫成本、狀態傳遞錯誤、延遲與偵錯負擔也會增加。只有當專業角色之間的分工確實有助於提升品質或進行權限控管時，才應選擇多代理架構；固定程序則可能更適合以一般程式碼工作流程處理。 ### 圖的狀態中應儲存哪些內容？ 原則上只儲存下一階段所需的資料，例如使用者請求、經驗證的中間結果、來源、錯誤類型、重複次數與核准狀態。應定義各欄位的格式與修改權限，且不應儲存驗證資訊或不必要的個人資料，或應將其遮蔽。 ### 重試失敗的節點時應注意什麼？ 應先區分錯誤是暫時性的、輸入本身有誤，還是依政策必須中止。對於傳送電子郵件、付款、變更資料等會產生外部副作用的工作，應使用冪等鍵與重複執行檢查。 ### 哪些工作不需要圖工程？ 對於簡單摘要、簡短問答、單次分類等只需一次呼叫即可完成的工作，通常不需要圖工程。如果加入圖所產生的狀態管理與營運成本，大於品質、控制或復原能力的改善，維持簡單的架構會更好。 ## Sources - [Building effective agents](https://www.anthropic.com/research/building-effective-agents) - [LangGraph](https://github.com/langchain-ai/langgraph) - [Temporal Documentation](https://docs.temporal.io/) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [Graphiti](https://github.com/getzep/graphiti) - [OWASP Top 10 for Large Language Model Applications](https://genai.owasp.org/llm-top-10/) ## Images ![女子在伺服器機房操作觸控螢幕上的工作流程圖](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTA0NzMsInB1ciI6ImJsb2JfaWQifX0=--ef1105ce6a385a669f3ac38d2daca7268be12737/ai-8a9b7d63.webp) ![以箭頭連結 AI 代理、資料儀表板、驗證、安全與人工審核的工作流程圖](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTA0NzksInB1ciI6ImJsb2JfaWQifX0=--dcdc470a0909904f41c12684bf7ee53b4ab8a805/ai-03b3a3b1.webp)