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