如果你最近在折騰 Autonomous Agent自主智能體一定會被這幾個詞反復(fù)刷屏ReAct、Plan-and-Execute、Reflexion、Tree of Thoughts。它們不是互相替代的關(guān)系而是解決同一個核心問題——Agent 該怎么決策、怎么規(guī)劃——的不同思路。我是在把 Agent 真正放進(jìn)業(yè)務(wù)流程里頭踩過無數(shù)死循環(huán)、幻覺復(fù)讀、工具亂用之后才慢慢把這四種范式吃透的。這篇文章不打算復(fù)述論文而是想用一個從業(yè)者的視角把這四種決策與規(guī)劃范式掰開揉碎講清楚它們各自解決什么問題、適合什么場景、怎么低成本落地以及我在給新項(xiàng)目選型時最看重的幾個點(diǎn)。1. 為什么 Autonomous Agent 的決策與規(guī)劃會成為核心難題1.1 從“能對話”到“能干活”的距離LLM 本身擅長生成文本但“生成文本”和“完成任務(wù)”是兩碼事。你讓模型直接回答“幫我查一下今天上海到北京的航班”它可能編一個航班號。但如果你給它一個查航班工具讓它先查、再答結(jié)果就變成了可信的事實(shí)。這一步跨越就是 Agent 區(qū)別于普通 Chatbot 的關(guān)鍵。決策與規(guī)劃之所以難是因?yàn)?Agent 需要在不確定的環(huán)境里持續(xù)選擇“下一步做什么”。打個比方普通對話像問路對方給你指個方向就夠了Agent 干活像讓一個人自己去陌生城市送快遞他要自己看地圖、查路況、繞開施工路段、確認(rèn)收貨人每一步都可能有意外。ReAct、Plan-and-Execute、Reflexion、Tree of Thoughts 正是四種不同的“帶人干活”的方式。從我實(shí)際觀察來看很多新手一上來就堆工具拖了二三十個 API 給 Agent結(jié)果模型根本不知道什么時候該調(diào)哪個。問題根源不是工具不夠而是缺少一個決策框架——Agent 不知道怎么把任務(wù)拆解、怎么選擇工具、怎么從錯誤中恢復(fù)。這就是為什么這四種范式值得逐個研究。1.2 四個范式背后的統(tǒng)一問題搜索與利用的權(quán)衡如果抽象一點(diǎn)看Agent 決策本質(zhì)上是在一個巨大的“動作空間”里搜索可行路徑。ReAct 是貪心搜索每一步都選當(dāng)下最合理的動作Plan-and-Execute 是先有一個粗粒度計(jì)劃再按計(jì)劃執(zhí)行Reflexion 是用歷史經(jīng)驗(yàn)修正搜索方向Tree of Thoughts 則是顯式地維護(hù)多條候選路徑做系統(tǒng)性搜索。理解了這個底層邏輯你就不會被名詞繞暈。它們各自在“探索新路徑”和“利用已有知識”之間取了不同的平衡點(diǎn)。ReAct 偏向利用執(zhí)行快但容易走一步看一步ToT 偏向探索思考深但成本高Plan-and-Execute 試圖減少重復(fù)決策Reflexion 則試圖從失敗中積累經(jīng)驗(yàn)。生產(chǎn)環(huán)境里沒有銀彈組合使用往往是更務(wù)實(shí)的方案。2. 逐個拆解四種決策范式的原理與邊界2.1 ReAct把思考外化成可被觀察的動作ReAct 的全稱是 Reasoning Acting核心循環(huán)是 Thought推理→ Action行動→ Observation觀察。模型每產(chǎn)生一個思考就去調(diào)用一個工具拿到觀察結(jié)果后再繼續(xù)推理直到生成最終答案。我最早用 LangChain 的 Agent 時默認(rèn)跑的就是這個循環(huán)。它最大的價值是讓模型不再“閉門造車”。比如我問“對比一下 A 方案和 B 方案的運(yùn)行成本”模型如果只憑訓(xùn)練數(shù)據(jù)回答很可能給的是過時價格但在 ReAct 模式下它會主動去查定價文檔、調(diào)用計(jì)算器把數(shù)據(jù)拿到手再下結(jié)論。不過 ReAct 的坑也不少。最典型的是死循環(huán)模型反復(fù)調(diào)用同一個工具拿回同樣的結(jié)果然后繼續(xù)調(diào)用。因?yàn)槟Ｐ蜎]有“我已經(jīng)查過了”的短時記憶機(jī)制它每一次循環(huán)都像失憶一樣重新開始。后來我在工程上加了兩道保險最大迭代次數(shù)比如 10 輪和動作去重檢查同一工具同一參數(shù)重復(fù) 3 次就直接終止并輸出中間結(jié)論。這類防護(hù)不是可選項(xiàng)是必選項(xiàng)。2.2 Plan-and-Execute先畫地圖再按地圖走Plan-and-Execute 的思路很樸素執(zhí)行之前先讓 LLM 把整個任務(wù)拆成一個有序的步驟列表然后由一個執(zhí)行器逐條執(zhí)行。相當(dāng)于你先在地圖上畫出路線再一步步走。這個范式的好處是省 token 且穩(wěn)定。ReAct 每一步都要重新決策思考開銷大Planner 只需要在任務(wù)開始和關(guān)鍵節(jié)點(diǎn)各規(guī)劃一次執(zhí)行階段模型只需要關(guān)注當(dāng)前步驟上下文壓力小很多。我之前做過一個批量處理任務(wù)把 200 個文件分別做格式轉(zhuǎn)寫、摘要、歸檔。如果用 ReAct每個文件都要反復(fù)“該干什么”地繞圈改成 Plan-and-Execute 之后規(guī)劃一次處理流程剩下 200 次執(zhí)行都跟流水線一樣干凈。它的短板也很明顯計(jì)劃趕不上變化。如果任務(wù)中途出現(xiàn)意外情況比如某個文件缺字段、某個 API 返回異常固定計(jì)劃就失效了。因此落地時不能只用一次性 Planner還要加一個 replan 機(jī)制——執(zhí)行器發(fā)現(xiàn)某步失敗且無法重試時把當(dāng)前狀態(tài)送回 Planner 重新制定剩余計(jì)劃。這個“執(zhí)行中重規(guī)劃”才是 Plan-and-Execute 在生產(chǎn)環(huán)境真正好用的形態(tài)。2.3 Reflexion讓 Agent 從錯誤中學(xué)習(xí)Reflexion反射的核心機(jī)制是語言化反饋。傳統(tǒng)強(qiáng)化學(xué)習(xí)要更新權(quán)重Agent 很難做到但 LLM 有個天然優(yōu)勢它能用自然語言描述錯誤經(jīng)驗(yàn)然后在下次決策時把這些經(jīng)驗(yàn)當(dāng)作提示詞注入。簡單說就是把“上次怎么失敗的”寫進(jìn)記憶里下次不再犯。我實(shí)際用 Reflexion 最多的地方是寫代碼類 Agent。比如讓 Agent 寫一個腳本處理 CSV第一次它沒考慮空值導(dǎo)致報錯傳統(tǒng) ReAct 只會拿到錯誤堆棧后試著再修一次但同樣的錯誤可能換個姿勢反復(fù)出現(xiàn)。加上 Reflexion 后失敗后會生成一條反思記錄“這個數(shù)據(jù)集有空值處理前必須 fillna(0) 或 dropna()”下次遇到同類任務(wù)模型直接跳過踩坑過程。要注意的是反思記錄不是越多越好。記憶太多會讓模型注意力分散甚至把無關(guān)的失敗經(jīng)驗(yàn)當(dāng)成“重要線索”。我的經(jīng)驗(yàn)是每條反思記錄要做結(jié)構(gòu)化處理觸發(fā)條件、錯誤類型、解決辦法、適用邊界。然后按相關(guān)性排序只注入當(dāng)前任務(wù)最相關(guān)的前 3 到 5 條。否則 Reflexion 會從“經(jīng)驗(yàn)增益”變成“噪音污染”。2.4 Tree of Thoughts用搜索空間換取決策質(zhì)量Tree of Thoughts思維樹是四種范式里最接近“系統(tǒng)性思考”的。它不再讓模型沿著一條鏈往下走而是每到一個決策點(diǎn)先生成多個候選思路給每個候選打分再擇優(yōu)擴(kuò)展下一層形成一棵樹。最后走完整棵樹選出最優(yōu)路徑。這個范式我在兩個場景下用過一類是邏輯推理題比如“誰是小偷”這種條件約束題單鏈推理容易一條路走到黑另一類是任務(wù)拆解本身讓 LLM 在規(guī)劃階段生成多個備選計(jì)劃從中選一個最靠譜的再執(zhí)行。它明顯能提升決策質(zhì)量但代價也大每個節(jié)點(diǎn)可能要調(diào)用 3-5 次 LLM計(jì)算成本線性上漲延遲也翻倍。如果任務(wù)本身就簡單用它就是殺雞用牛刀。ToT 工程化的難度主要在兩點(diǎn)一是評估函數(shù)的穩(wěn)定性讓另一個 LLM 打分分?jǐn)?shù)時高時低需要做歸一化或多次投票二是搜索策略的取舍。我常用的是 beam search 變體每層保留 top-k 個節(jié)點(diǎn)既控制了樹的寬度又不至于像 DFS 那樣鉆牛角尖。搜索寬度設(shè)為 3 到 5深度控制在 4 到 5 層成本和質(zhì)量比較均衡。3. 怎么選型場景匹配、能力邊界與組合使用3.1 一張表學(xué)會場景匹配很多朋友喜歡問“哪個范式最強(qiáng)”真實(shí)答案永遠(yuǎn)是“看場景”。我整理了一個選型參考表基本覆蓋了常見任務(wù)類型任務(wù)特征推薦范式關(guān)鍵原因客服、問答、簡單信息查詢ReAct實(shí)時交互強(qiáng)能靈活調(diào)用知識庫和計(jì)算工具批量數(shù)據(jù)處理、流水線作業(yè)Plan-and-Execute流程固定減少反復(fù)決策token 更省代碼修復(fù)、數(shù)據(jù)清洗ReAct Reflexion錯誤可復(fù)盤經(jīng)驗(yàn)可復(fù)用提升迭代效率復(fù)雜推理、謎題、策略設(shè)計(jì)Tree of Thoughts多路徑搜索避免單鏈條走死長周期項(xiàng)目、任務(wù)多變計(jì)劃 重規(guī)劃 Reflexion既穩(wěn)又能適應(yīng)變化還能沉淀經(jīng)驗(yàn)這套匹配邏輯背后的原則是任務(wù)的不確定性越高越需要顯式的搜索任務(wù)的重復(fù)性越高越值得做規(guī)劃和記憶沉淀。別在確定性任務(wù)上多花錢也別在不確定性任務(wù)上省思考。3.2 組合玩法ReAct Reflexion 是目前性價比最高的起點(diǎn)如果你只打算給現(xiàn)有項(xiàng)目加一個 Agent 能力我會優(yōu)先推薦 ReAct Reflexion 這個組合。原因很簡單ReAct 足夠靈活能應(yīng)對大多數(shù)工具有調(diào)用場景加上 Reflexion 后系統(tǒng)可以在失敗中積累經(jīng)驗(yàn)逐步變強(qiáng)。這就像帶新人一個人邊干邊復(fù)盤的三四個月后通常比照著標(biāo)準(zhǔn)作業(yè)流程死干的人更能獨(dú)當(dāng)一面。更復(fù)雜一點(diǎn)的場景可以用 Plan-and-Execute 做外層框架ReAct 做執(zhí)行器。外層 Planner 負(fù)責(zé)把任務(wù)拆成階段進(jìn)入某個階段后ReAct 負(fù)責(zé)在該階段內(nèi)靈活決策。中間遇到無法處理的失敗觸發(fā) replan 回到 Planner。這樣既有整體規(guī)劃又有局部靈活性。而 Tree of Thoughts 我建議留在真正需要深度思考的任務(wù)里作為單獨(dú)的服務(wù)調(diào)用不要讓它成為所有流量的默認(rèn)入口。3.3 成本與延遲的量化賬很多 TS 朋友忽略了一個事實(shí)決策范式直接決定了 token 消耗量。我用一個實(shí)際任務(wù)對比過同樣是“總結(jié)一篇技術(shù)文章并提取行動項(xiàng)”ReAct 大約消耗 8000 tokenPlan-and-Execute 大約 5000 token而 Tree of Thoughts 如果展開 3 個分支、每個分支 3 層可能會消耗 25000 token 以上。延遲也是這樣。ReAct 每個動作都要等一次模型返回通常 3-8 秒完成一次小任務(wù)Plan-and-Execute 因?yàn)闇p少了中間決策延遲更低ToT 因?yàn)槎啻未姓{(diào)用可能跑到 20 秒以上。如果你的 Agent 是嵌在用戶交互鏈路里的延遲超過 10 秒就很難接受。這時候你就要判斷是不是可以把復(fù)雜推理挪到后臺異步執(zhí)行。成本不該等到賬單出來才后悔應(yīng)該在選型那一刻就算清楚。4. 實(shí)操用代碼把四種范式落地4.1 先搭好最小工作臺我這里以 Python LangChain 生態(tài)為例但核心思路可以平移到任何框架。第一步是先定義工具并把工具描述寫得足夠清楚。語言模型的工具選擇能力很大程度上依賴描述文本的質(zhì)量。我的習(xí)慣是給每個工具寫清楚“何時使用”“輸入格式”“返回內(nèi)容”。from langchain_core.tools import tool tool def search_web(query: str) - str: 當(dāng)你需要獲取實(shí)時信息、驗(yàn)證事實(shí)或查找最新數(shù)據(jù)時使用。輸入是搜索關(guān)鍵詞返回網(wǎng)頁摘要列表。 # 實(shí)際接入搜索 API這里省略 return 搜索結(jié)果是...工具描述里不要只寫“搜索函數(shù)”而要寫“什么時候用”。差一個關(guān)鍵詞模型就可能在“要不要調(diào)用它”之間猶豫。4.2 自己寫一個最小 ReAct 循環(huán)雖然框架里有現(xiàn)成的 AgentExecutor但我建議新手至少親手寫一次 ReAct 循環(huán)。這樣你能清楚知道每一輪到底發(fā)生了什么排查問題才不會抓瞎。MAX_STEPS 8 for step in range(MAX_STEPS): # 1. 讓模型基于當(dāng)前整個對話歷史決定下一步 response llm.invoke([ model_instructions, # 解釋可用工具、要求逐步思考 *chat_history, ]) # 2. 解析輸出分為 Thought / Action / Action Input action parse_action(response) if action Final Answer: print(最終答案:, response) break # 3. 執(zhí)行工具 result tools_map[action.name].run(action.input) # 4. 把觀察結(jié)果追加到歷史里進(jìn)入下一輪 chat_history.append((observation, result)) else: print(超過最大迭代數(shù)強(qiáng)制結(jié)束)寫完之后你就明白為什么 ReAct 會出現(xiàn)死循環(huán)因?yàn)?history 在積累但模型不一定能判斷“這個觀察和前一輪是否重復(fù)”。所以要自己在代碼里做重復(fù)檢測如果 action 名稱和輸入完全一樣且 observation 也一樣就直接 break。這是我在生產(chǎn)環(huán)境里必加的防線。4.3 Plan-and-Execute 落地兩步走加重規(guī)劃第一步用 Planner 生成計(jì)劃我習(xí)慣讓它輸出 JSON 列表而不是飄渺的自然語言。結(jié)構(gòu)化輸出可以直接映射到代碼邏輯減少解析出錯。plan_prompt 你是一個任務(wù)規(guī)劃器。根據(jù)用戶目標(biāo)生成步驟列表。 要求 - 每一步必須可執(zhí)行、且依賴的工具體現(xiàn)在步驟描述里 - 輸出 JSON 數(shù)組格式為 [{step: 1, task: ...}] 第二步是執(zhí)行器循環(huán)。執(zhí)行器每完成一步就更新狀態(tài)如果某一步連續(xù)重試 2 次仍然失敗就調(diào)用 replan。for step in plan: ok execute_step(step) if not ok: if retry_count 2: plan planner.replan(goal, current_state, plan, step) break retry_count 1這里有個細(xì)節(jié)replan 時不要把舊計(jì)劃全丟棄。我會把“已完成步驟”和“失敗原因”一起傳給 Planner它才能基于真實(shí)進(jìn)度調(diào)整后續(xù)步驟而不是從零開始白干。4.4 Reflexion把反思變成結(jié)構(gòu)化記憶Reflexion 的落地關(guān)鍵是建立一個“經(jīng)驗(yàn)記憶庫”。在每次任務(wù)失敗后調(diào)用反思模型生成反思記錄然后存回記憶庫下次任務(wù)開始前從記憶庫中檢索相關(guān)經(jīng)驗(yàn)放進(jìn) System Prompt。def generate_reflection(task, attempt, error): prompt f 任務(wù){(diào)task} 嘗試過程{attempt} 失敗原因{error} 請生成一條結(jié)構(gòu)化反思記錄格式 【觸發(fā)條件】什么情況下會出現(xiàn)這個錯誤 【解決辦法】下次應(yīng)該怎么做 return llm.invoke(prompt) def build_context(task): memories memory_db.search(task, top_k3) return \n.join(memories)我給你的忠告是反思記錄一定要寫“什么時候用”而不是只寫“發(fā)生了什么”。比如“處理 CSV 時如果列里有空字符串先轉(zhuǎn)換成 NaN 再聚合”比“上次報錯 KeyError”有用得多。前者是可執(zhí)行知識后者只是事故描述。4.5 Tree of Thoughts先理解評估與搜索ToT 的代碼量不大但設(shè)計(jì)難度高。核心是一個節(jié)點(diǎn)類包含狀態(tài)、思路內(nèi)容和評分。class ThoughtNode: def __init__(self, state, parentNone): self.state state self.parent parent self.score 0.0 def generate_candidates(node, k3): # 讓 LLM 基于當(dāng)前節(jié)點(diǎn)生成 k 個不同的下一步思路 return [node.state ; thought for thought in llm.generate_k(k)] def evaluate_node(candidate): # 用規(guī)則或另一個 LLM 給候選打分 return llm.evaluate(candidate) # 0~1 分搜索時我常用 beam search每一層對每個節(jié)點(diǎn)生成 k 個候選保留全局 top-b繼續(xù)下一層。樹的寬度 k 設(shè) 3束寬 b 設(shè) 4深度設(shè) 5。這套參數(shù)在小規(guī)模任務(wù)上效果不錯。如果任務(wù)規(guī)模更大建議退到離線做或者用異步隊(duì)列慢慢算別堵在主流程里。5. 常見問題與排查技巧實(shí)錄5.1 一張速查表解決大部分異常我整理了在項(xiàng)目里反復(fù)出現(xiàn)的幾類問題后面接我的解決思路現(xiàn)象根源處理方式Agent 反復(fù)調(diào)用同一工具缺少重復(fù)檢測機(jī)制加動作去重重復(fù) 3 次直接終止計(jì)劃第一版就執(zhí)行不下去Planner 沒感知上下文邊界重規(guī)劃時把已完成步驟和失敗原因完整傳給 Planner反思記錄注入后回答變差記憶太多、噪聲干擾只注入 top-k 相關(guān)記憶并壓縮每條記錄長度ToT 打分忽高忽低評估模型太弱改用規(guī)則評分或多次采樣取平均穩(wěn)定評估器工具返回結(jié)果太長上下文被擠爆模型丟失重點(diǎn)對工具返回內(nèi)容做摘要或截斷保留關(guān)鍵字段這些問題的共性是模型本身沒出錯是工程上沒有約束和反饋機(jī)制。把 Agent 當(dāng)一個分布式系統(tǒng)來治理設(shè)置超時、重試、重試上限、狀態(tài)觀測點(diǎn)穩(wěn)定性立刻上一個臺階。5.2 我在實(shí)踐中踩過的兩個最深的坑第一個坑是讓 Agent 直接去改生產(chǎn)數(shù)據(jù)庫。當(dāng)時一個 Agent 在執(zhí)行測試時誤調(diào)了寫接口把臨時數(shù)據(jù)寫進(jìn)正式庫。事后我加了兩層保險所有具有副作用寫操作、刪除操作的工具默認(rèn)禁止在測試環(huán)境直接使用必須經(jīng)過人工確認(rèn)開關(guān)同時所有工具調(diào)用記錄都要有 trace 日志出了問題可回放。這個經(jīng)驗(yàn)希望你們用不上但一定要提前配置。第二個坑是 Reflexion 的記憶庫“臟數(shù)據(jù)”問題。有一次反思記錄里混了一條錯誤結(jié)論結(jié)果模型每次遇到相似任務(wù)都被這條錯誤經(jīng)驗(yàn)帶偏。后來我意識到反思記錄本身也需要評估和淘汰機(jī)制不能只增不減。我會設(shè)置一個置信度字段連續(xù)幾次應(yīng)用后任務(wù)都成功置信度上升反之下降低于閾值就淘汰。保持記憶庫干凈比往里面塞更多經(jīng)驗(yàn)更重要。6. 進(jìn)階擴(kuò)展記憶、評估與生產(chǎn)化6.1 記憶設(shè)計(jì)會反過來影響規(guī)劃質(zhì)量四種范式里除了 Plan-and-Execute 對記憶要求不高其他三種都強(qiáng)烈依賴記憶機(jī)制。Agent 的記憶至少分成三檔工作記憶當(dāng)前任務(wù)的上下文緩沖短期記憶當(dāng)前任務(wù)里的工具結(jié)果和歷史動作長期記憶跨任務(wù)的反思和經(jīng)驗(yàn)沉淀。我見過很多團(tuán)隊(duì)在示例里直接把所有歷史一股腦塞進(jìn) prompttoken 爆炸不說模型還抓不住重點(diǎn)。正確的做法是每輪對話只保留最近 3-5 條關(guān)鍵上下文長期記憶靠檢索注入而不是全部加載。6.2 給 Agent 建立評測集而不是靠感覺調(diào)參沒有評測集的 Agent 優(yōu)化基本靠猜。我給每個規(guī)劃范式都建了一套最小評測集20 到 30 條典型任務(wù)每一條都明確標(biāo)注“正確的最終答案”和“關(guān)鍵步驟路徑”。比如對于代碼修復(fù)任務(wù)不僅看最終代碼能否運(yùn)行還要看它是否識別了根因。評測指標(biāo)我會拆成任務(wù)成功率、平均輪次、平均 token 消耗、失敗率分布。只有把這些數(shù)據(jù)量化你才能硬氣地判斷“到底是 ReAct 還是 ToT 更適合我的場景”而不是聽誰的安利。6.3 生產(chǎn)化決策別一上來就全都要如果你正在規(guī)劃一個真實(shí)的 Agent 產(chǎn)品我的建議是別一上來就上四種范式大滿貫。先用 ReAct 簡單記憶跑通最小閉環(huán)再逐步加 Reflexion、重規(guī)劃、ToT。每一步都確認(rèn)收益大于成本再往下一個階段走。比如你的業(yè)務(wù)里 80% 請求是“查信息、寫摘要”那 ReAct 足夠只有那 5% 的復(fù)雜推理需求才值得單獨(dú)起一個 ToT 服務(wù)。這樣既控制了成本也避免了過早優(yōu)化帶來的維護(hù)地獄。我個人在實(shí)際操作中最大的體會是Agent 的決策與規(guī)劃能力不是靠挑選一個“最強(qiáng)范式”獲得的而是靠把基礎(chǔ)循環(huán)做扎實(shí)再根據(jù)任務(wù)類型不斷增加反饋機(jī)制。如果你能把 ReAct 的死循環(huán)防住把 Reflexion 的經(jīng)驗(yàn)庫保持干凈把 Plan-and-Execute 的重規(guī)劃觸發(fā)條件設(shè)準(zhǔn)你的系統(tǒng)就已經(jīng)比大多數(shù) Demo 級 Agent 強(qiáng)了。至于 ToT把它當(dāng)作一把偶爾使用的重武器就好別天天扛著。