“ 智能體開發過程中存在很多細節性問題，而這些問題決定著智能體的質量?！?/strong>

最近要把RAG系統優化成智能體實現，因此又深入研究了一下智能體的實現方式，開發框架使用的是Langgraph；然后在工具執行的時候出了一點問題。

智能體工具節點

智能體簡單來說就是會使用工具的大模型，主要由大模型(Model)+工具(Tool)+提示詞(Prompt)構成；其原理就是通過讓大模型理解用戶問題，然后自己根據工具說明，生成調用參數執行工具，最終獲取執行結果，本質上就是讓大模型調API，只不過傳統的方式是由開發人員寫調用代碼，而智能體自己生成請求參數。

既然智能體能夠執行工具，因此我們就可以把很多功能封裝成API提供給智能體使用，這樣智能體就可以根據用戶問題做自主決策來完成任務。

在Langgraph中，調用工具是通過工具節點——ToolNode來執行的；而且在Langgraph中的執行流程是一個節點一個節點的執行。因此，需要大模型調用工具之后，需要在ToolNode節點中執行完之后，把執行結果放到State狀態圖中，然后再在模型節點中從State獲取工具調用結果。

在智能體中所謂的工具本質上就是一個個函數，其和我們平常寫的功能函數沒什么區別；只不過把調用方換成了大模型。因此，這里就有一個問題，那就是在平常人工編碼開發過程中，函數的返回值基本上都是結構化的數據。

但在智能體中，模型直接獲取工具節點的執行結果，然后解決用戶問題；這時對工具的執行結果就有講究了。

我們只能實現多功能智能體有兩種方式，一種是給一個智能體配置多個工具，另一種是根據單一職責原則，一個智能體只配置有限的幾個工具，然后通過組合的方式來實現復雜功能。

因此，針對多個功能不同的工具，比如說有些工具處理的是中間過程，而有些工具處理的是最終結果；這些中間過程的工具執行結果可能還需要用來調用另一個工具，而最終的處理結果需要丟給大模型進行處理。

以召回功能為例，我們最終丟給大模型的是一個格式化之后的參考文檔，而不僅僅是一個檢索回來的文檔列表；因此，工具的最終執行結果也要進行處理格式化處理；比如說把召回文檔列表的主要內容給提取出來，而不是把存在很多無用參數的查詢結果丟給模型，比如說文檔的ID，時間，介紹等。

其中還一個主要問題是，在工具中如果也要使用大模型功能，在Langgraph的模型節點進行流式返回的時候，會把工具中模型的執行結果也進行流式輸出；從理論上來說這應該是有問題的。

因為，對模型節點來說需要的是工具的執行結果，而不是工具的執行過程；這樣不但會影響到模型的最終輸出效果，同時還會暴露背后的工具，這是一種潛在的風險；因此在處理過程中需要對工具節點的數據進行過濾。

本文轉載自??????AI探索時代?????? 作者：DFires