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

最近要把RAG系統(tǒng)優(yōu)化成智能體實現(xiàn)，因此又深入研究了一下智能體的實現(xiàn)方式，開發(fā)框架使用的是Langgraph；然后在工具執(zhí)行的時候出了一點問題。

智能體工具節(jié)點

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

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

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

在智能體中所謂的工具本質(zhì)上就是一個個函數(shù)，其和我們平常寫的功能函數(shù)沒什么區(qū)別；只不過把調(diào)用方換成了大模型。因此，這里就有一個問題，那就是在平常人工編碼開發(fā)過程中，函數(shù)的返回值基本上都是結(jié)構(gòu)化的數(shù)據(jù)。

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

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

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

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

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

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

本文轉(zhuǎn)載自??????AI探索時代?????? 作者：DFires