LangGraph智能體設計模式與多智能體開發

• @before_agent：智能體啓動前觸發（每次調用執行一次），適合進行初始化操作（如參數校驗、資源申請、上下文初始化）。例如，調用智能體前校驗用戶輸入的城市名稱是否爲中文全稱，避免無效流程啓動。 • @before_model：每次調用模型前觸發，適合動態補充上下文、修改提示詞、過濾敏感信息。例如，在調用模型前，根據用戶歷史查詢記錄補充地區默認值，讓模型獲取更完整的輸入。 • @after_model：每次接收模型響應後觸發，適合處理模型輸出（如格式校驗、內容過濾、日誌記錄）。例如，模型返回響應後，檢查是否包含符合要求的JSON結構，若不符合，則標記異常。 • @after_agent：智能體執行完成後觸發（每次調用最多執行一次），適合進行結果匯總、資源清理、數據持久化。例如，智能體返回最終結果後，將查詢記錄（城市、時間、結果）存入日誌文件。

內容有些過時，不太推薦。我讀它的初衷很務實——想弄明白 LangGraph 的設計理念，好在工作中真正用起來。讀完之後，印象最深的有幾點： **1. 便籤 vs 工作交接單** 書裏把普通 LLM 的輸出比作"一張便籤"，只寫最終答案；而 LangGraph 的輸出是"一份帶流程的工作交接單"，除了結果，還得告訴下一個環節"該誰接手、做什麼"。這個類比一下子擊中了我。之前我一直把大模型當成"回答問題的人"，但從沒想過在 Agent 裏它其實是一個"流水線上的工人"——光答對題不算完，還得知道自己往哪兒交、交什麼。放回我的日常工作，這不就像寫交接文檔嗎？只說"做完了"遠遠不夠，得說清楚下一步。 **2. State 是那個"公共記事本"** Node、Edge、State 這三個概念裏，我最有共鳴的是 State。它像一張擺在桌上的公共記事本，每個小站幹完活都要往上面記一筆，下個環節讀了才知道從哪兒繼續。聯想到我們工程裏的多模塊協作，最難的從來不是每個模塊本身，而是模塊之間的"當前狀態"怎麼傳遞、怎麼不丟。LangGraph 用 Annotated 給字段加註解、用 reduce 定義消息的合併邏輯，把"大家怎麼往記事本上寫字"的規則也收編進了框架，而不是靠各節點自覺——這個思路很聰明。 **3. 先定好輸出格式，再問大模型** "在訪問大模型前就定義好輸出的格式"這句話讓我反思了很久。以前我調模型總是先聊再掰，拿到結果再想怎麼解析，經常爲解析髒數據頭疼。書裏的做法是倒過來：請求之前就約好格式，格式裏既要有當前結果，也要有下一步建議。這跟我工作中先定接口、再寫實現的路數是同構的——約定先行，後面一切順暢。 **4. 條件分支不只是 if-else，是"指路牌"** Edge 不只是連接節點的路，還是指路牌——負責做選擇。書裏提到的多場景條件分支本質上是 Conditional Edge，主要用在意圖識別上。這讓我意識到，Agent 編排裏最考驗設計的地方往往不是單個節點多強，而是"什麼時候該走哪條路"這個路由邏輯。也順帶解答了我一直的疑惑：爲什麼選 PG 而不是 MySQL 做底層——大概就是爲了支撐這類複雜查詢和路由判斷。

廢話太多，像是AI寫的，書中的代碼多處有錯誤

瑕不掩瑜。前半段確實是langgraph，後面就變成了langgraph和langchain的大雜燴，從此可見langchain的倉庫冗餘問題確實挺嚴重的。另外就是代碼質量極低，可讀性較差，經常出現爲了“演示方便理解”而寫出各種匪夷所思的模擬代碼，反而顯得代碼多次複用現象反而不值一提了。尤其是倒了本書後面，幾乎就是代碼+代碼總結的AI文，味道太重。 雖然上面說了這麼多問題，但是本書前半段還是可以的，能大體系統地瞭解langgraph的機制和能力，作爲頭次閱讀還行，不適合深入研究。

這本書寫得...能直接看官方文檔，我爲什麼看你ai寫的書。