LLM Agent真正走向落地關鍵不在于給模型疊加更多概念而在于把任務規劃、工具調用、環境反饋與自我反思組織成可驗證的工程閉環。本文從工具與Agent的基本定義出發梳理總體架構和核心交互機制進一步解讀ReAct、Plan-and-Solve等經典工作并延伸到訓練數據構建與實踐方法幫助開發者建立從論文理解到系統實現的完整視角?；靖拍?. 什么是工具只要能夠讓語言模型從外部獲得知識、或者執行操作的接口都可以視為工具。這些“工具”可以是一個檢索引擎、一個代碼執行器、一個地圖 API、一個天氣 API、一個與數據庫交互的接口等等。2. 為什么要使用工具當前大模型已經具備了很多能力也具備了很強的理解和解決問題能力比如內容創作、語言理解、代碼生成等但是依舊無法完成很多復雜的任務。這是因為首先純LLM的知識固化于訓練語料中一旦涉及世界最新資訊或時效性較強的數據如天氣、新聞、股票LLM 往往會產生“幻覺”。因此相比其他確定性的工具LLM是“最容易失控的”。這時候通過整合搜索引擎、在線數據庫、知識庫等工具模型能獲得真實世界的知識和反饋在回答用戶實時問題時具有更高的準確度與時效性。舉例來說檢索增強式生成Retrieval-Augmented GenerationRAG就是最常見的工具之一檢索引擎可看作是一個“文本搜索”工具我們在用戶與LLM交互的時候讓LLM能夠從外掛知識庫中實時檢索引入豐富且正確的外部知識避免“幻覺”式回答。其次大模型雖在通用場景下表現出色但當問題需要專業技能如復雜邏輯推理、多語言編程、多模態生成時僅靠自身生成的能力難以解決。如果能“外呼”專業工具如真實執行代碼、調用多模態模型等則能大幅提升表現。tool的類型多種多樣它們能夠幫助LLM完成自己本身做不到的事情3. Agent基本介紹AGENT LLM × 規劃記憶工具在這篇文章中我們會對Agent的每個環節做較為詳細的介紹。先把架構圖放在這里以便有一個整體的認知。在這篇文章中我們會詳細介紹規劃Planning如何將大型任務分解為較小的、可管理的子目標以便高效的處理復雜任務;反思與自我修正Reflection Self-critics如何對過去的行為進行自我批評和反省并指導接下來的行動記憶Memory工具使用Tool use如何調用外部 API以獲取模型權重中缺少的額外信息。4. Agent的不同階段在這里也是先放一個整體的圖以便有整體的認知。之后我們會通過經典論文和實操來了解更具體的細節。Stage 1Task-Planning任務規劃是指當模型接收到用戶的復雜query后需要先進行意圖理解與任務分解。先把整個問題分解成若干容易執行的小任務或步驟并確定這些步驟的依賴關系和執行順序形成一個有向無環圖DAG。Stage 2 Tool Selection在完成任務分解、明確了子問題后模型需要在多個可用的工具或API中檢索并選擇最合適的工具。不同工具往往功能、輸入輸出方式都不同因此正確選擇不同工具組合對于成功解決子任務至關重要。工具選擇的方法也分成兩類基于檢索器的工具選擇Retriever-based Tool Selection。 當工具數目龐大時先用一個外部的檢索器來篩選Top-K可能相關的工具再把它們的描述與用戶問題一并輸入LLM最終由LLM做最后的選擇。這是因為模型能接受的上下文長度是有限的如果把所有的工具都堆給它直接就超出了上下文長度這樣肯定是不行的。常見的檢索方法包括多種傳統IR技術TF-IDF/BM25或者語義向量檢索?；贚LM的直接選擇LLM-based Tool Selection。 當備選的工具數量不是很多時可以直接把工具描述全部拼接進模型輸入讓LLM選出最優工具。Stage3Tool-Calling在選定要用的工具后LLMs 需要以正確的格式向工具發送調用請求并準確填充調用參數。需要遵循工具說明中要求的格式如參數名稱、變量類型、取值范圍等否則調用會失敗。按照種類來分工具調用分為單工具調用Single Function Call: 如“今天天氣怎么樣”- 調用get_weather依賴性工具調用Dependent Function Call如“張三的地址處天氣怎么樣”- 先調用get_address然后調用get_weather平行工具調用Parallel Function Call如“張三的手機號和地址是多少”- 同時調用get_address、get_phone_numberStage4Response Generation工具調用完成后LLM會收到工具調用結果這個結果稱為Observation。接下來需要基于這個Observation與自身知識生成最終回答給用戶。直接插入式Direct Insertion Methods 這是最簡單的辦法如讓模型回答時先寫一句“這里是工具返回結果ToolResult()”然后在呈現給用戶前將“ToolResult()”替換成實際工具輸出文本。這種方式往往不夠靈活也可能影響可讀性所以目前使用較少。信息整合式Information Integration Methods 先將Observation作為上下文繼續輸入LLM讓它基于這個信息寫出完整、自然的答案。若工具輸出過長超出LLM的上下文窗口會先對工具結果進行壓縮或抽取。經典論文1. React2022奠定Agent“思考”與“行動”相結合的范式論文標題REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS論文鏈接https://arxiv.org/pdf/2210.03629這篇系統性地提出了將 Reasoning 與 Acting 結合的范式也就是我們現在熟知的ReAct模式。在 ReAct 模式提出之前LLM的推理主要分為如下兩個模式推理Reasoning 例如 Chain-of-Thought (CoT)模型利用內部知識直接輸出答案。但是這個的缺點就是模型容易產生幻覺且無法獲取外部世界的實時信息。例如問LLM“現在的美國總統是誰”它不能實時聯網搜索用的知識都停留在訓練時候的老舊數據。行動Acting 模型根據tool-call的執行結果Observation直接輸出下一個動作Action。比如下圖的(1c)中每次都根據上一輪的Observation來生成下一個動作。(1a) 直接輸出答案(1b) 先思考再輸出答案 (1c) 只調用工具 (1d) ReAct在調用工具之前先思考在Agent框架下Agent 會不斷地與環境交互。 具體地在時間步 tAgent 接收到來自環境的觀察 o_t /in /mathcal{O}并根據當前的上下文 c_t (o_1, a_1, /dots, o_{t-1}, a_{t-1}, o_t) 采取行動。Observation觀察Agent執行一個動作之后的運行結果比如執行一次數據庫查詢Observation就是查詢的結果。Action動作Agent調用的工具比如search、click等傳統策略Act-only通常是學習一個映射 , 其中 是外部動作空間如search[query],click[button]。ReAct 的核心創新在于擴充了動作空間其中 是語言空間。用大白話說就是現在LLM不再是直接輸出一個Action了而是先進行一些推理生成Thought然后再輸出Action。如上圖的(1d)所示每次在生成答案的時候都先生成Thought, 然后再生成Action。Thought 。這是一個內部動作幫助 Agent 整理思路、分解目標或提取關鍵信息。它不會影響外部環境因此沒有對應的觀察反饋。Reason-only: 直接輸出不調用工具Act-only: 只輸出調用工具的ActionReAct: 在輸出調用工具的Action之前先進行思考Agent的運行軌跡就是交替Thought - Action - Observation - Thought ...這個做法在現在看來已經是司空見慣尤其是在以o1、deepseek-R1為首的復雜推理模型出來之后都是先做思考thinking、然后再輸出答案。我們現在都知道thinking的過程以及thinking長度對于推理結果的正確性而言是非常重要的。不過在當時React還是非常有開創性的。它奠定了Agent“思考”與“行動”相結合的范式也是目前大多數自主Agent框架如LangChain的底層邏輯。2. Plan-and-Solve規劃與任務拆解解決長程復雜任務論文標題 Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models論文鏈接 https://arxiv.org/pdf/2305.04091Plan-and-Solve的核心貢獻是提出了“先計劃再執行”的策略解決了Agent在面臨復雜目標時“走一步看一步”導致的迷失問題。為什么需要用Planner這是因為對于一些復雜的、長鏈路的任務如“寫一個游戲”普通的Agent調用方式如ReAct往往會“走著走著就忘了要去哪”。這時候我們需要就Plan-and-Solve (PS) 模式了先制定完整的計劃再逐一執行。在這個模式里面有兩個角色Planner和Executor。(a) Planner: 把一個需求變成可執行步驟的“項目經理”。Planner 把一個復雜的任務拆解成 3-5 個清晰的動作有論文驗證 plan 的步驟不能過多并且給出不同動作的依賴關系告訴 Agent 哪些步驟可以并行哪些必須串行。這個本質上是創建了一個有向無環圖DAG的執行計劃后續可以將這些計劃分配給對應的 Agent 執行。示例 [1. 搜索2023年財報, 2. 提取凈利潤數據, 3. 計算同比增長率, 4. 生成圖表]在Executor執行的過程中Planner還需要執行監控記錄每個任務pending、in progress、completed的狀態每完成一步就更新狀態。PS 最重要的地方在于動態重規劃計劃并不是一成不變的而是會根據Executor的執行情況做動態調整。假如某個步驟執行失敗了Planner需要根據失敗給出原因 改進建議之后進行重新規劃。1. **Planner 生成初始計劃 [A, B, C, D]。** 2. **Executor 執行 A成功。** 3. **Executor 執行 B失敗例如工具報錯“數據不存在”。** 4. **Executor 將失敗信息反饋給 Planner。** 5. **Planner 被喚醒“任務 B 失敗了看來原來的計劃行不通。基于現在的觀察我需要修改后續計劃。”** 6. **Planner 生成新計劃 [B, C, D]。** 7. **Executor 繼續執行 B。**可選還可以加上human in loop也就是當用戶不滿意這個plan時可以人為去修改plan。bExecutor拿著 Planner 給的清單一項一項地去調工具執行。二者的交互如下圖所示Planner與executor的交互。planner會根據實時的執行結果動態調整planPlan-and-Solve論文中給出的示例如下(a) 普通COT方法 (b) Plan-and-Solve, 先制定計劃再一個個執行 ? 把執行結果輸給LLM生成答案更準確PS在實際應用中的例子Claude-CodeClaude Code 作為Code Agent 也有任務規劃模塊。下方是Claude Code 的運行截圖prompt是幫我生成一個打地鼠游戲它首先做了一個任務規劃同時每執行一步都會記錄并更新任務的狀態“Update Todos”正在進行的任務用彩色表示已經完成任務用綠色表示并用刪除線劃掉待辦的任務用白色表示圖片來源https://zhuanlan.zhihu.com/p/19379340937624252143. Reflection自我反思與閉環控制論文標題 Reflexion: Language Agents with Verbal Reinforcement Learning論文鏈接 https://arxiv.org/pdf/2303.11366核心貢獻引入了動態記憶和自我反思機制Agent會根據環境反饋評估自己的表現并將失敗經驗存入記憶指導下一次嘗試。這篇論文是實現自我糾錯和Plan-Execute-Observe循環的核心論文。Reflexion的思想很簡單就是讓Agent從之前的失敗中學習。Reflexion會把環境的0/1反饋比如代碼執行是否正確或量化的反饋轉換成文字描述作為下次迭代中的額外信息讓Agent知道怎樣改正錯誤這樣就能更好地完成任務了。從上圖看出Reflexion框架利用三個不同的模型執行者Actor、評估者Evaluator和自我反思模型Self-Reflection)。Actor基于狀態和Observation生成文本和ActionEvaluator對Actor產生的輸出計算獎勵分數Self-Reflection模型生成自我反思的文本分析以協助Actor自我改進。該過程使用短期和長期記憶其中軌跡歷史作為短期記憶而自我反思模型的輸出存儲在長期記憶中。看下面這個示例圖的中間Programming部分可以對上面的流程圖有一個直觀的了解以代碼生成為例在模型拿到一個Task之后它首先生成了一個代碼段。之后這個代碼段被送給EvaluatorEvaluator會自己生成一些測試用例self-generated unit tests用于測試。假如這個測試失敗了assertion fail那么Self-Reflection模型就會分析這次失敗的原因形成一個原因分析文本再輸入給模型。模型根據上一次失敗的教訓會重新生成。Self-Reflection在實際應用中的例子swe-agent現在主流的Agent框架都不再采用上述的Actor、Evaluator、Self-Reflection三個模型了而是用一個模型解決所有的問題。具體而言swe-agent是一個讓code-agent在其中解決真實repo中issue 報錯的框架這個code-agent可以查看文件并運行任意的代碼。那么在運行代碼的過程中不可避免地會遇到一些報錯。這個報錯就是模型與環境交互的錯誤信息了模型在下一步輸出的時候就會根據報錯的信息進行分析并修復自己的錯誤。比如在模型認為自己已經修復了issue之后它運行下寫的面的代碼想看一下自己寫的代碼是否有效但是很不幸它的代碼出現了報錯所以之后的輪次模型就在不停地view各種文件并進行修改嘗試在經歷了若干輪的toolcall-observation-toolcall-observation…之后模型終于解決了問題Agent實踐1. Agent訓練數據構建用于預訓練/SFTstep1. 工具構建工具分為兩種真實工具調用外部真實存在的API或服務如天氣接口、數據庫返回結果是完全真實的如實時股價。但是缺點是開發較為復雜需處理API認證等另外調用成本高頻繁使用需支付API費用。虛擬工具工具功能及結果完全由LLM生成無真實后端支持因此不需要API認證等復雜的開發流程也無需API費用。缺點就是結果不可信容易編造不存在的事實、可能違反常識。如果我們方便使用真實工具最好還是使用真實工具的調用結果。例如對于Code-Agent一般都是直接在容器中執行代碼并且獲得代碼的執行結果。只有那種不好調用API的才使用模擬的方式。step2. 任務構建可以使用大模型針對工具List合成問題另外加入persona和場景設計借助指令進化方法使得Agent數據的任務變得更加接近真實使用場景逐漸增加問題難度和多樣性。最后可以合并已有的簡單任務逐步構建復雜任務。step3. 答案構建搭建帶可執行/模擬API調用的環境 → 智能體在環境中交互 → 記錄真實調用軌跡trajectory作為訓練數據step4. 答案校驗為了驗證構建軌跡的正確性我們需要進行答案校驗。對于那種可以驗證正確性的問題我們可以用rule-based的方式來驗證正確性。例如對于code-agent任務我們可以通過校驗最終的代碼是否通過測試用例來驗證整個軌跡是否正確。對于那種不好驗證正確性的問題我們只能用LLM judge的方式來判斷API使用是否合理、工具選擇路徑是否最優、參數是否合理等。另外還有一個需要注意的一點就是整個軌跡是正確的不代表其中每一步都是正確的因此我們可以對其中不正確的步驟選擇mask掉它的loss。例如有的時候LLM生成的工具調用格式可能是錯誤的如json無法解析、參數格式錯誤那么這一步是無法調用工具的所以這一步在SFT里面我們不去學習。另外比如code-agent在中間的執行結果可能經常會發生報錯那么我們可以選擇不去學習導致報錯的輪次。2. Agent訓練/推理的chat-templateLLMs在聊天應用場景中會由多個消息組成對話在這些消息中每一條都包含一個角色比如system、“user”、“assistant”、“tool”不同的模型會采用截然不同的格式進行訓練。一旦模型接受了某種格式的訓練需要確保未來的輸入使用相同的格式否則就可能會出現損害性能的分布漂移。因此為了使用上的方便防止由于格式不對齊導致chat模型效果有損現在的所有模型均采用在tokenizer中預置chat template的方式固定拼接方式。例如下面就是一個原始對話的例子tools [ { type: function, function: { name: get_current_temperature, description: Get current temperature at a location., parameters: { type: object, properties: { location: { type: string, description: The location to get the temperature for, in the format City, State, Country., }, }, required: [location], }, }, } ] messages [ {role: system, content: You are a helpful agent. n}, {role: user, content: 現在北京的天氣怎么樣} ]從上面的這段代碼我們可以看到它首先有一個system字段描述了 LLM的身份另外有一個第一輪問題user字段 “現在北京的天氣怎么樣”。另外還有一個tools的定義這個就是工具列表里面有LLM可以調用的所有工具的描述就類似說明書一樣描述了每個工具的名稱、功能描述、調用參數等。例如上面這個工具叫get_current_temperature,它的作用是實時獲得某個地點的溫度。它只接受一個傳參叫做location是一個string類型的地點信息如Beijing。之后調用apply_chat_template將上面的對話信息變成大模型接受的string類型輸入text tokenizer.apply_chat_template( messagesmessages, toolstools, # 所有可調用的工具描述 add_generation_promptTrue, tokenizeFalse )結果如下_systemYou are a helpful agent. # 可用工具 你可以調用tools/tools標簽中包含的一個或多個工具來輔助你回答問題,以下是可用工具詳情 tools {type: function, function: {name: get_current_temperature, description: Get current temperature at a location., parameters: {type: object, properties: {location: {type: string, description: The location to get the temperature for, in the format City, State, Country.}, unit: {type: string, enum: [celsius, fahrenheit], description: The unit to return the temperature in. Defaults to celsius.}}, required: [location]}}} /tools # 調用方法 你需要遵循工具的要求使用json格式返回工具名稱及參數并用tool_calltool_call包含。下方是一個調用模板 tool_call {name: function-name, arguments: args-json-object} /tool_call _user現在北京的天氣怎么樣_bot將上面的這個文本輸入給大模型得到返回結果為了獲取當前天氣我需要調用get_current_temperature這個工具。 tool_call {name: get_current_temperature, arguments: {location: 北京}} /tool_call之后對這個結果進行解析將tool_call(.*)/tool_call中的部分提取出來嘗試使用json進行解析確?？梢蕴崛〕鏊{用工具的名字(name)與參數(arguments)如果在tool_call前模型有額外輸出作為content字段一并返回給用戶如果解析失敗模型輸出格式不規范則需要返回提示信息給用戶并將模型輸出直接放進content字段上面結果解析之后如下{ role: assistant, content: 為了獲取當前天氣我需要調用get_current_temperature這個工具, tool_calls: [ { type: function, function: { name: get_current_temperature, arguments: {location: 北京} } } ] }注意解析的過程一般都是放在vllm里面的所以返回給用戶的結果就已經是解析之后的了。用戶獲取大模型調用工具的具體信息后需要返回給模型調用工具的結果。例如上面調用get_current_temperature API得到北京的溫度是10℃。這時候下一步模型的輸入就包含了工具調用的結果messages [ { role: system, content: You are a helpful agent. }, { role: user, content: 現在北京的天氣怎么樣 }, { role: assistant, content: 為了獲取當前天氣我需要調用get_current_temperature這個工具, tool_calls: [ { type: function, function: { name: get_current_temperature, arguments: {location: 北京} } } ] }, { role: tool, name: get_current_temperature, content: {temperature: 10°C, location: 北京} } ]apply_chat_template之后變成了string格式_systemYou are a helpful agent. ... _user現在北京的天氣怎么樣 _bot為了獲取當前天氣我需要調用get_current_temperature這個工具 tool_call {name: get_current_temperature, arguments: {location: 北京}} /tool_call_end _usertool_response{temperature: 10°C, location: 北京}/tool_response_bot用戶最終得到的信息是{role:bot, content: 當前北京的天氣為10°C。}解決了用戶的問題。這里給大家精心整理了一份全面的AI大模型學習資源包括AI大模型全套學習路線圖從入門到實戰、精品AI大模型學習書籍手冊、視頻教程、實戰學習、面試題等資料免費分享掃碼免費領取全部內容1. 成長路線圖學習規劃要學習一門新的技術作為新手一定要先學習成長路線圖方向不對努力白費。這里我們為新手和想要進一步提升的專業人士準備了一份詳細的學習成長路線圖和規劃?？梢哉f是最科學最系統的學習成長路線。2. 大模型經典PDF書籍書籍和學習文檔資料是學習大模型過程中必不可少的我們精選了一系列深入探討大模型技術的書籍和學習文檔它們由領域內的頂尖專家撰寫內容全面、深入、詳盡為你學習大模型提供堅實的理論基礎。書籍含電子版PDF3. 大模型視頻教程對于很多自學或者沒有基礎的同學來說書籍這些純文字類的學習教材會覺得比較晦澀難以理解因此我們提供了豐富的大模型視頻教程以動態、形象的方式展示技術概念幫助你更快、更輕松地掌握核心知識。4. 2026行業報告行業分析主要包括對不同行業的現狀、趨勢、問題、機會等進行系統地調研和評估以了解哪些行業更適合引入大模型的技術和應用以及在哪些方面可以發揮大模型的優勢。5. 大模型項目實戰學以致用當你的理論知識積累到一定程度就需要通過項目實戰在實際操作中檢驗和鞏固你所學到的知識同時為你找工作和職業發展打下堅實的基礎。6. 大模型面試題面試不僅是技術的較量更需要充分的準備。在你已經掌握了大模型技術之后就需要開始準備面試我們將提供精心整理的大模型面試題庫涵蓋當前面試中可能遇到的各種技術問題讓你在面試中游刃有余。7. 資料領取全套內容免費抱走學 AI 不用再找第二份不管你是 0 基礎想入門 AI 大模型還是有基礎想沖刺大廠、了解行業趨勢這份資料都能滿足你現在只需按照提示操作就能免費領取掃碼免費領取全部內容 萬字長文解讀 LLM Agent：總體框架、經典論文與實踐
LLM Agent真正走向落地關鍵不在于給模型疊加更多概念而在于把任務規劃、工具調用、環境反饋與自我反思組織成可驗證的工程閉環。本文從工具與Agent的基本定義出發梳理總體架構和核心交互機制進一步解讀ReAct、Plan-and-Solve等經典工作并延伸到訓練數據構建與實踐方法幫助開發者建立從論文理解到系統實現的完整視角?；靖拍?. 什么是工具只要能夠讓語言模型從外部獲得知識、或者執行操作的接口都可以視為工具。這些“工具”可以是一個檢索引擎、一個代碼執行器、一個地圖 API、一個天氣 API、一個與數據庫交互的接口等等。2. 為什么要使用工具當前大模型已經具備了很多能力也具備了很強的理解和解決問題能力比如內容創作、語言理解、代碼生成等但是依舊無法完成很多復雜的任務。這是因為首先純LLM的知識固化于訓練語料中一旦涉及世界最新資訊或時效性較強的數據如天氣、新聞、股票LLM 往往會產生“幻覺”。因此相比其他確定性的工具LLM是“最容易失控的”。這時候通過整合搜索引擎、在線數據庫、知識庫等工具模型能獲得真實世界的知識和反饋在回答用戶實時問題時具有更高的準確度與時效性。舉例來說檢索增強式生成Retrieval-Augmented GenerationRAG就是最常見的工具之一檢索引擎可看作是一個“文本搜索”工具我們在用戶與LLM交互的時候讓LLM能夠從外掛知識庫中實時檢索引入豐富且正確的外部知識避免“幻覺”式回答。其次大模型雖在通用場景下表現出色但當問題需要專業技能如復雜邏輯推理、多語言編程、多模態生成時僅靠自身生成的能力難以解決。如果能“外呼”專業工具如真實執行代碼、調用多模態模型等則能大幅提升表現。tool的類型多種多樣它們能夠幫助LLM完成自己本身做不到的事情3. Agent基本介紹AGENT LLM × 規劃記憶工具在這篇文章中我們會對Agent的每個環節做較為詳細的介紹。先把架構圖放在這里以便有一個整體的認知。在這篇文章中我們會詳細介紹規劃Planning如何將大型任務分解為較小的、可管理的子目標以便高效的處理復雜任務;反思與自我修正Reflection Self-critics如何對過去的行為進行自我批評和反省并指導接下來的行動記憶Memory工具使用Tool use如何調用外部 API以獲取模型權重中缺少的額外信息。4. Agent的不同階段在這里也是先放一個整體的圖以便有整體的認知。之后我們會通過經典論文和實操來了解更具體的細節。Stage 1Task-Planning任務規劃是指當模型接收到用戶的復雜query后需要先進行意圖理解與任務分解。先把整個問題分解成若干容易執行的小任務或步驟并確定這些步驟的依賴關系和執行順序形成一個有向無環圖DAG。Stage 2 Tool Selection在完成任務分解、明確了子問題后模型需要在多個可用的工具或API中檢索并選擇最合適的工具。不同工具往往功能、輸入輸出方式都不同因此正確選擇不同工具組合對于成功解決子任務至關重要。工具選擇的方法也分成兩類基于檢索器的工具選擇Retriever-based Tool Selection。 當工具數目龐大時先用一個外部的檢索器來篩選Top-K可能相關的工具再把它們的描述與用戶問題一并輸入LLM最終由LLM做最后的選擇。這是因為模型能接受的上下文長度是有限的如果把所有的工具都堆給它直接就超出了上下文長度這樣肯定是不行的。常見的檢索方法包括多種傳統IR技術TF-IDF/BM25或者語義向量檢索?；贚LM的直接選擇LLM-based Tool Selection。 當備選的工具數量不是很多時可以直接把工具描述全部拼接進模型輸入讓LLM選出最優工具。Stage3Tool-Calling在選定要用的工具后LLMs 需要以正確的格式向工具發送調用請求并準確填充調用參數。需要遵循工具說明中要求的格式如參數名稱、變量類型、取值范圍等否則調用會失敗。按照種類來分工具調用分為單工具調用Single Function Call: 如“今天天氣怎么樣”- 調用get_weather依賴性工具調用Dependent Function Call如“張三的地址處天氣怎么樣”- 先調用get_address然后調用get_weather平行工具調用Parallel Function Call如“張三的手機號和地址是多少”- 同時調用get_address、get_phone_numberStage4Response Generation工具調用完成后LLM會收到工具調用結果這個結果稱為Observation。接下來需要基于這個Observation與自身知識生成最終回答給用戶。直接插入式Direct Insertion Methods 這是最簡單的辦法如讓模型回答時先寫一句“這里是工具返回結果ToolResult()”然后在呈現給用戶前將“ToolResult()”替換成實際工具輸出文本。這種方式往往不夠靈活也可能影響可讀性所以目前使用較少。信息整合式Information Integration Methods 先將Observation作為上下文繼續輸入LLM讓它基于這個信息寫出完整、自然的答案。若工具輸出過長超出LLM的上下文窗口會先對工具結果進行壓縮或抽取。經典論文1. React2022奠定Agent“思考”與“行動”相結合的范式論文標題REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS論文鏈接https://arxiv.org/pdf/2210.03629這篇系統性地提出了將 Reasoning 與 Acting 結合的范式也就是我們現在熟知的ReAct模式。在 ReAct 模式提出之前LLM的推理主要分為如下兩個模式推理Reasoning 例如 Chain-of-Thought (CoT)模型利用內部知識直接輸出答案。但是這個的缺點就是模型容易產生幻覺且無法獲取外部世界的實時信息。例如問LLM“現在的美國總統是誰”它不能實時聯網搜索用的知識都停留在訓練時候的老舊數據。行動Acting 模型根據tool-call的執行結果Observation直接輸出下一個動作Action。比如下圖的(1c)中每次都根據上一輪的Observation來生成下一個動作。(1a) 直接輸出答案(1b) 先思考再輸出答案 (1c) 只調用工具 (1d) ReAct在調用工具之前先思考在Agent框架下Agent 會不斷地與環境交互。 具體地在時間步 tAgent 接收到來自環境的觀察 o_t /in /mathcal{O}并根據當前的上下文 c_t (o_1, a_1, /dots, o_{t-1}, a_{t-1}, o_t) 采取行動。Observation觀察Agent執行一個動作之后的運行結果比如執行一次數據庫查詢Observation就是查詢的結果。Action動作Agent調用的工具比如search、click等傳統策略Act-only通常是學習一個映射 , 其中 是外部動作空間如search[query],click[button]。ReAct 的核心創新在于擴充了動作空間其中 是語言空間。用大白話說就是現在LLM不再是直接輸出一個Action了而是先進行一些推理生成Thought然后再輸出Action。如上圖的(1d)所示每次在生成答案的時候都先生成Thought, 然后再生成Action。Thought 。這是一個內部動作幫助 Agent 整理思路、分解目標或提取關鍵信息。它不會影響外部環境因此沒有對應的觀察反饋。Reason-only: 直接輸出不調用工具Act-only: 只輸出調用工具的ActionReAct: 在輸出調用工具的Action之前先進行思考Agent的運行軌跡就是交替Thought - Action - Observation - Thought ...這個做法在現在看來已經是司空見慣尤其是在以o1、deepseek-R1為首的復雜推理模型出來之后都是先做思考thinking、然后再輸出答案。我們現在都知道thinking的過程以及thinking長度對于推理結果的正確性而言是非常重要的。不過在當時React還是非常有開創性的。它奠定了Agent“思考”與“行動”相結合的范式也是目前大多數自主Agent框架如LangChain的底層邏輯。2. Plan-and-Solve規劃與任務拆解解決長程復雜任務論文標題 Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models論文鏈接 https://arxiv.org/pdf/2305.04091Plan-and-Solve的核心貢獻是提出了“先計劃再執行”的策略解決了Agent在面臨復雜目標時“走一步看一步”導致的迷失問題。為什么需要用Planner這是因為對于一些復雜的、長鏈路的任務如“寫一個游戲”普通的Agent調用方式如ReAct往往會“走著走著就忘了要去哪”。這時候我們需要就Plan-and-Solve (PS) 模式了先制定完整的計劃再逐一執行。在這個模式里面有兩個角色Planner和Executor。(a) Planner: 把一個需求變成可執行步驟的“項目經理”。Planner 把一個復雜的任務拆解成 3-5 個清晰的動作有論文驗證 plan 的步驟不能過多并且給出不同動作的依賴關系告訴 Agent 哪些步驟可以并行哪些必須串行。這個本質上是創建了一個有向無環圖DAG的執行計劃后續可以將這些計劃分配給對應的 Agent 執行。示例 [1. 搜索2023年財報, 2. 提取凈利潤數據, 3. 計算同比增長率, 4. 生成圖表]在Executor執行的過程中Planner還需要執行監控記錄每個任務pending、in progress、completed的狀態每完成一步就更新狀態。PS 最重要的地方在于動態重規劃計劃并不是一成不變的而是會根據Executor的執行情況做動態調整。假如某個步驟執行失敗了Planner需要根據失敗給出原因 改進建議之后進行重新規劃。1. **Planner 生成初始計劃 [A, B, C, D]。** 2. **Executor 執行 A成功。** 3. **Executor 執行 B失敗例如工具報錯“數據不存在”。** 4. **Executor 將失敗信息反饋給 Planner。** 5. **Planner 被喚醒“任務 B 失敗了看來原來的計劃行不通。基于現在的觀察我需要修改后續計劃。”** 6. **Planner 生成新計劃 [B, C, D]。** 7. **Executor 繼續執行 B。**可選還可以加上human in loop也就是當用戶不滿意這個plan時可以人為去修改plan。bExecutor拿著 Planner 給的清單一項一項地去調工具執行。二者的交互如下圖所示Planner與executor的交互。planner會根據實時的執行結果動態調整planPlan-and-Solve論文中給出的示例如下(a) 普通COT方法 (b) Plan-and-Solve, 先制定計劃再一個個執行 ? 把執行結果輸給LLM生成答案更準確PS在實際應用中的例子Claude-CodeClaude Code 作為Code Agent 也有任務規劃模塊。下方是Claude Code 的運行截圖prompt是幫我生成一個打地鼠游戲它首先做了一個任務規劃同時每執行一步都會記錄并更新任務的狀態“Update Todos”正在進行的任務用彩色表示已經完成任務用綠色表示并用刪除線劃掉待辦的任務用白色表示圖片來源https://zhuanlan.zhihu.com/p/19379340937624252143. Reflection自我反思與閉環控制論文標題 Reflexion: Language Agents with Verbal Reinforcement Learning論文鏈接 https://arxiv.org/pdf/2303.11366核心貢獻引入了動態記憶和自我反思機制Agent會根據環境反饋評估自己的表現并將失敗經驗存入記憶指導下一次嘗試。這篇論文是實現自我糾錯和Plan-Execute-Observe循環的核心論文。Reflexion的思想很簡單就是讓Agent從之前的失敗中學習。Reflexion會把環境的0/1反饋比如代碼執行是否正確或量化的反饋轉換成文字描述作為下次迭代中的額外信息讓Agent知道怎樣改正錯誤這樣就能更好地完成任務了。從上圖看出Reflexion框架利用三個不同的模型執行者Actor、評估者Evaluator和自我反思模型Self-Reflection)。Actor基于狀態和Observation生成文本和ActionEvaluator對Actor產生的輸出計算獎勵分數Self-Reflection模型生成自我反思的文本分析以協助Actor自我改進。該過程使用短期和長期記憶其中軌跡歷史作為短期記憶而自我反思模型的輸出存儲在長期記憶中。看下面這個示例圖的中間Programming部分可以對上面的流程圖有一個直觀的了解以代碼生成為例在模型拿到一個Task之后它首先生成了一個代碼段。之后這個代碼段被送給EvaluatorEvaluator會自己生成一些測試用例self-generated unit tests用于測試。假如這個測試失敗了assertion fail那么Self-Reflection模型就會分析這次失敗的原因形成一個原因分析文本再輸入給模型。模型根據上一次失敗的教訓會重新生成。Self-Reflection在實際應用中的例子swe-agent現在主流的Agent框架都不再采用上述的Actor、Evaluator、Self-Reflection三個模型了而是用一個模型解決所有的問題。具體而言swe-agent是一個讓code-agent在其中解決真實repo中issue 報錯的框架這個code-agent可以查看文件并運行任意的代碼。那么在運行代碼的過程中不可避免地會遇到一些報錯。這個報錯就是模型與環境交互的錯誤信息了模型在下一步輸出的時候就會根據報錯的信息進行分析并修復自己的錯誤。比如在模型認為自己已經修復了issue之后它運行下寫的面的代碼想看一下自己寫的代碼是否有效但是很不幸它的代碼出現了報錯所以之后的輪次模型就在不停地view各種文件并進行修改嘗試在經歷了若干輪的toolcall-observation-toolcall-observation…之后模型終于解決了問題Agent實踐1. Agent訓練數據構建用于預訓練/SFTstep1. 工具構建工具分為兩種真實工具調用外部真實存在的API或服務如天氣接口、數據庫返回結果是完全真實的如實時股價。但是缺點是開發較為復雜需處理API認證等另外調用成本高頻繁使用需支付API費用。虛擬工具工具功能及結果完全由LLM生成無真實后端支持因此不需要API認證等復雜的開發流程也無需API費用。缺點就是結果不可信容易編造不存在的事實、可能違反常識。如果我們方便使用真實工具最好還是使用真實工具的調用結果。例如對于Code-Agent一般都是直接在容器中執行代碼并且獲得代碼的執行結果。只有那種不好調用API的才使用模擬的方式。step2. 任務構建可以使用大模型針對工具List合成問題另外加入persona和場景設計借助指令進化方法使得Agent數據的任務變得更加接近真實使用場景逐漸增加問題難度和多樣性。最后可以合并已有的簡單任務逐步構建復雜任務。step3. 答案構建搭建帶可執行/模擬API調用的環境 → 智能體在環境中交互 → 記錄真實調用軌跡trajectory作為訓練數據step4. 答案校驗為了驗證構建軌跡的正確性我們需要進行答案校驗。對于那種可以驗證正確性的問題我們可以用rule-based的方式來驗證正確性。例如對于code-agent任務我們可以通過校驗最終的代碼是否通過測試用例來驗證整個軌跡是否正確。對于那種不好驗證正確性的問題我們只能用LLM judge的方式來判斷API使用是否合理、工具選擇路徑是否最優、參數是否合理等。另外還有一個需要注意的一點就是整個軌跡是正確的不代表其中每一步都是正確的因此我們可以對其中不正確的步驟選擇mask掉它的loss。例如有的時候LLM生成的工具調用格式可能是錯誤的如json無法解析、參數格式錯誤那么這一步是無法調用工具的所以這一步在SFT里面我們不去學習。另外比如code-agent在中間的執行結果可能經常會發生報錯那么我們可以選擇不去學習導致報錯的輪次。2. Agent訓練/推理的chat-templateLLMs在聊天應用場景中會由多個消息組成對話在這些消息中每一條都包含一個角色比如system、“user”、“assistant”、“tool”不同的模型會采用截然不同的格式進行訓練。一旦模型接受了某種格式的訓練需要確保未來的輸入使用相同的格式否則就可能會出現損害性能的分布漂移。因此為了使用上的方便防止由于格式不對齊導致chat模型效果有損現在的所有模型均采用在tokenizer中預置chat template的方式固定拼接方式。例如下面就是一個原始對話的例子tools [ { type: function, function: { name: get_current_temperature, description: Get current temperature at a location., parameters: { type: object, properties: { location: { type: string, description: The location to get the temperature for, in the format City, State, Country., }, }, required: [location], }, }, } ] messages [ {role: system, content: You are a helpful agent. n}, {role: user, content: 現在北京的天氣怎么樣} ]從上面的這段代碼我們可以看到它首先有一個system字段描述了 LLM的身份另外有一個第一輪問題user字段 “現在北京的天氣怎么樣”。另外還有一個tools的定義這個就是工具列表里面有LLM可以調用的所有工具的描述就類似說明書一樣描述了每個工具的名稱、功能描述、調用參數等。例如上面這個工具叫get_current_temperature,它的作用是實時獲得某個地點的溫度。它只接受一個傳參叫做location是一個string類型的地點信息如Beijing。之后調用apply_chat_template將上面的對話信息變成大模型接受的string類型輸入text tokenizer.apply_chat_template( messagesmessages, toolstools, # 所有可調用的工具描述 add_generation_promptTrue, tokenizeFalse )結果如下_systemYou are a helpful agent. # 可用工具 你可以調用tools/tools標簽中包含的一個或多個工具來輔助你回答問題,以下是可用工具詳情 tools {type: function, function: {name: get_current_temperature, description: Get current temperature at a location., parameters: {type: object, properties: {location: {type: string, description: The location to get the temperature for, in the format City, State, Country.}, unit: {type: string, enum: [celsius, fahrenheit], description: The unit to return the temperature in. Defaults to celsius.}}, required: [location]}}} /tools # 調用方法 你需要遵循工具的要求使用json格式返回工具名稱及參數并用tool_calltool_call包含。下方是一個調用模板 tool_call {name: function-name, arguments: args-json-object} /tool_call _user現在北京的天氣怎么樣_bot將上面的這個文本輸入給大模型得到返回結果為了獲取當前天氣我需要調用get_current_temperature這個工具。 tool_call {name: get_current_temperature, arguments: {location: 北京}} /tool_call之后對這個結果進行解析將tool_call(.*)/tool_call中的部分提取出來嘗試使用json進行解析確?？梢蕴崛〕鏊{用工具的名字(name)與參數(arguments)如果在tool_call前模型有額外輸出作為content字段一并返回給用戶如果解析失敗模型輸出格式不規范則需要返回提示信息給用戶并將模型輸出直接放進content字段上面結果解析之后如下{ role: assistant, content: 為了獲取當前天氣我需要調用get_current_temperature這個工具, tool_calls: [ { type: function, function: { name: get_current_temperature, arguments: {location: 北京} } } ] }注意解析的過程一般都是放在vllm里面的所以返回給用戶的結果就已經是解析之后的了。用戶獲取大模型調用工具的具體信息后需要返回給模型調用工具的結果。例如上面調用get_current_temperature API得到北京的溫度是10℃。這時候下一步模型的輸入就包含了工具調用的結果messages [ { role: system, content: You are a helpful agent. }, { role: user, content: 現在北京的天氣怎么樣 }, { role: assistant, content: 為了獲取當前天氣我需要調用get_current_temperature這個工具, tool_calls: [ { type: function, function: { name: get_current_temperature, arguments: {location: 北京} } } ] }, { role: tool, name: get_current_temperature, content: {temperature: 10°C, location: 北京} } ]apply_chat_template之后變成了string格式_systemYou are a helpful agent. ... _user現在北京的天氣怎么樣 _bot為了獲取當前天氣我需要調用get_current_temperature這個工具 tool_call {name: get_current_temperature, arguments: {location: 北京}} /tool_call_end _usertool_response{temperature: 10°C, location: 北京}/tool_response_bot用戶最終得到的信息是{role:bot, content: 當前北京的天氣為10°C。}解決了用戶的問題。這里給大家精心整理了一份全面的AI大模型學習資源包括AI大模型全套學習路線圖從入門到實戰、精品AI大模型學習書籍手冊、視頻教程、實戰學習、面試題等資料免費分享掃碼免費領取全部內容1. 成長路線圖學習規劃要學習一門新的技術作為新手一定要先學習成長路線圖方向不對努力白費。這里我們為新手和想要進一步提升的專業人士準備了一份詳細的學習成長路線圖和規劃?？梢哉f是最科學最系統的學習成長路線。2. 大模型經典PDF書籍書籍和學習文檔資料是學習大模型過程中必不可少的我們精選了一系列深入探討大模型技術的書籍和學習文檔它們由領域內的頂尖專家撰寫內容全面、深入、詳盡為你學習大模型提供堅實的理論基礎。書籍含電子版PDF3. 大模型視頻教程對于很多自學或者沒有基礎的同學來說書籍這些純文字類的學習教材會覺得比較晦澀難以理解因此我們提供了豐富的大模型視頻教程以動態、形象的方式展示技術概念幫助你更快、更輕松地掌握核心知識。4. 2026行業報告行業分析主要包括對不同行業的現狀、趨勢、問題、機會等進行系統地調研和評估以了解哪些行業更適合引入大模型的技術和應用以及在哪些方面可以發揮大模型的優勢。5. 大模型項目實戰學以致用當你的理論知識積累到一定程度就需要通過項目實戰在實際操作中檢驗和鞏固你所學到的知識同時為你找工作和職業發展打下堅實的基礎。6. 大模型面試題面試不僅是技術的較量更需要充分的準備。在你已經掌握了大模型技術之后就需要開始準備面試我們將提供精心整理的大模型面試題庫涵蓋當前面試中可能遇到的各種技術問題讓你在面試中游刃有余。7. 資料領取全套內容免費抱走學 AI 不用再找第二份不管你是 0 基礎想入門 AI 大模型還是有基礎想沖刺大廠、了解行業趨勢這份資料都能滿足你現在只需按照提示操作就能免費領取掃碼免費領取全部內容