記錄一次Langgraph流式返回的問題處理過程——以及智能體debug的心得體會 原創
“ 智能體debug最好的方式就是一個功能點一個功能點的測試;原因在于智能體不可控因素太多,會導致排查問題異常困難。”
最近在做智能體的過程中遇到了一個問題,就是流式返回的問題;剛開始為了方便,使用的是langgraph提供的create_react_agent接口;但使用過這個接口的人應該都知道,它提供的流式接口是一個偽流式或者說根本不是流式輸出,因它的(a)stream流式方法中調用的是(a)invoke接口。
因此,后來還是選擇使用自定義智能體的方式,使用StateGraph創建智能體。
def create_graph(self):
"""自定義智能體"""
graph_builder = StateGraph(MessagesState)
graph_builder.add_node("chatbot", self.chat_model)
graph_builder.add_node("tools", self.tool_node)
graph_builder.add_edge(START, "chatbot")
graph_builder.add_conditional_edges("chatbot",tools_condition)
graph_builder.add_edge("tools", "chatbot")
return graph_builder.compile()智能體流式返回問題
從用戶體驗的角度出發,大家都知道大模型有流式返回的功能;但基于大模型的流式返回相對比較簡單,當把大模型與工具相結合做成Agent智能體時,其復雜度就直線上升,出問題的概率也比較大。
智能體是大模型和工具的集合體,由于工具的存在就導致大模型的流式返回處理起來比較復雜;比如說調用工具時,必須要等到工具響應之后才能進行下一步,否則大模型無法獲取工具的執行結果,那么調用工具就沒了意義。
再有Langgraph為了解決節點調用過程中的數據通訊問題,使用了狀態圖(State)的方式進行數據傳輸;這樣下層節點只能等上層節點執行完畢之后,才能從狀態圖中獲取上層節點的執行結果;備注: 工具節點也是節點。

所以,這時影響智能體進行流式輸出的因素就比較多了;可能是模型節點問題,工具節點問題,代碼bug問題,工具包的版本問題,甚至是模型本身問題和模型的部署問題等等。
而作者這次遇到流式返回的問題,就是在模型的部署問題上;在智能體的測試過程中,一直都是一次性返回;剛開始一直以為是代碼寫的有bug導致無法流式返回,然后把代碼改了又改,最后找到那些能正常流式返回的智能體代碼,拿過來跑還是無法進行流式返回。
等發現這個問題又開始懷疑是不是環境問題,然后把兩個環境的工具版本對照了一下,然后版本確實不太一樣;但等把版本更新成統一版本時,還是無法流式返回。
智能體的流式返回有多種模式,不同的模式適合不同的業務場景。

這時才開始懷疑是不是模型的原因,但在測試智能體的過程中,也試過直接調用模型,但可以進行正常的流式返回;所以剛開始并沒有懷疑模型的問題。
而最后經過替換第三方模型,發現確實是模型的問題;而這時又需要考慮是模型本身還是部署的原因;因為我們模型部署使用了nginx做了反向代理,并且使用的是ollama部署的。
然后經過一通測試,發現是ollama的版本問題導致無法正常流式輸出。
經過這次問題,也發現了一個debug的方法;在智能體開發中,由于智能體本身的復雜性,其涉及的環節比較多,再加上大模型本身的不穩定性;就導致其問題排查過程非常困難。

因此,在智能體開發中比較好的debug方式就是,一個問題一個問題,一個節點一個節點的排查;比如說懷疑工具調用有問題就只測試工具調用的功能;把其它無關代碼全部注釋掉,如果確認這個環節沒問題之后,再測試其它功能模塊。
在智能體這種長距離調用以及復雜環境下,最忌諱的就是全流程的debug方法;原因就在于其不穩定因素太多,不可控變量也太多;這樣就會導致你無法判斷到底是哪個環節出了問題。
本文轉載自???AI探索時代?? 作者:DFires

















