“ 智能體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