用LangGraph進行圖工程：三年經驗總結

圖工程這個術語最近在X的AI內容工廠中興起，與提示工程、上下文工程、編排工程和循環工程等術語並列。儘管這些可能被視為流行語，但它們確實描述了構建者面臨的實際挑戰和設計決策。

在LangChain，我們三年來一直在幫助人們使用圖形構建代理系統。我們的框架LangGraph目前每月下載量超過6500萬次，被初創企業和大型企業廣泛使用。其成功的關鍵在於它在確定性路徑和自主步驟之間取得了平衡。

將代理建模為圖形

圖形提供了一種具體的方式來定義代理遵循的工作流。在LangGraph中，節點執行工作——可以是確定性代碼、單個LLM調用、工具調用或具有內部循環的完整代理。邊定義了下一步做什麼，有些是確定性的，有些則基於節點結果、當前狀態或外部信號是條件性的。這本質上是一個狀態機。

何時使用圖形

現實世界中的代理工作流通常具有可預測的結構：支持代理在回答或升級之前先對問題進行分類，編碼代理在提出更改之前先檢查倉庫，合規工作流在採取外部行動之前需要審批。圖形允許您直接編碼這些結構：模型的決策點以及系統應強制確定性行為的地方。

例如，一個知識庫代理使用三個子代理進行搜索：一個GitHub代理處理代碼、問題和拉取請求，一個Notion代理處理內部文檔和Wiki，一個Slack代理處理相關線程。工作流有三個固定階段：分類、搜索、綜合。結果是代碼和模型推理協同工作，模型在增加價值的地方推理，代碼處理其餘部分，從而使代理更便宜、更快、更可預測。

何時避免使用圖形

有些任務本質上更具自主性，強行使用確定性路徑是錯誤的。例如通用的深度研究：研究代理需要規劃、委派、搜索、閲讀和綜合，這些很難預先確定。早期的深度研究使用預定義的LangGraph工作流，但後來轉向了更自主的核心循環。GPT Researcher也做了類似的轉變。

構建LangGraph的教訓

首先，代理圖形通常不是DAG。生產代理需要循環：重試失敗的工具調用、向用户詢問缺失信息、驗證後修改答案、重複調用工具直到獲得足夠上下文、在恢復前暫停等待人工輸入。循環是代理系統的核心部分。

其次，循環是簡單的圖形。循環工程不是圖形的替代品，而是它們的簡化版本。

第三，動態轉換很重要。您並不總是希望提前定義每條邊。有時節點在運行時決定要創建多少工作。Map-reduce是經典案例：將輸入拆分為片段，每個片段發送給工作器，然後組合結果。工作器的數量取決於輸入，無法提前知道。LangGraph通過Send功能處理這種情況，允許節點動態地將工作路由到一個或多個下游節點。

什麼實際上發生了變化

將代理系統表示為圖形並非新鮮事——我們已經這樣做了三年。現在的新情況是節點中可以包含的內容。早期節點是確定性代碼或單個LLM調用。現在代理本身足夠可靠，節點可以是一個完整的代理運行——您正在編排代理，而不僅僅是LLM調用。編碼代理是很好的例子，它們嵌入在更大的圖形中作為節點，這是一種新的實用模式。

例如，一個文檔代理將Slack請求轉換為可供審查的拉取請求。圖中的每個節點都位於確定性到自主性的不同點上：固定步驟由代碼和API調用驅動；模型步驟使用單個LLM調用且沒有工具；代理步驟則完成更開放的工作。這種確定性/自主性的混合使得文檔代理可預測、強大且高效。

更大的思路

圖工程不是一個新想法，它是構建可靠代理的成熟方法的最新名稱。它與循環工程和編排工程背後的理念相同：在正確的位置、正確的上下文中放置模型推理。如果您想嘗試圖工程，不妨試試LangGraph。