深度解析 LLM Agent 演进从 ReAct 到 Reflexion 的“自我反思”之路在复杂任务场景下业界早期广泛采用的是ReAct (Reason Act)范式。然而在实际落地中我们常常发现大模型像是一个固执且健忘的员工。当它陷入幻觉或采取错误行动时往往会在一个错误逻辑里无限循环Infinite Loop即使你在系统提示词里让它“仔细想想”它也很难自行跳出泥潭。为了打破这种死循环Agent 架构图中衍生出了一个极其重要的分支——重反思Reflection。而在这个分支中Reflexion无疑是一个里程碑式的架构。但是无论是 Basic Reflection 还是 Reflexion 都还是所有步骤执行完了才会触发反思无法做到中间步骤失败后立即触发反思。下一篇文章介绍的 LATS 就是针对该问题的优化。一、 澄清误区Reflexion 是错别字吗只是加了外部工具吗Reflexion 并不是错别字它出自 2023 年的一篇论文《Reflexion: Language Agents with Verbal Reinforcement Learning》。传闻作者故意将 Reflection 改为 Reflexion是为了致敬并融合 Reinforcement Learning强化学习RL 的概念无凭据大家当一乐看就好了。同时Reflexion 并不仅仅是“Basic Reflection 外部工具”这么简单。Basic Reflection基础反思通常是单次尝试Intra-trial内部的自我检查。比如 Agent 生成了一个答案系统再调一次 LLM 问“你觉得这个答案对吗有漏洞吗”这完全依赖 LLM 自身的内部知识边界如果它本身认知有误它的反思也会是盲目的。Reflexion强化学习反思这是一种跨尝试Inter-trial的记忆与反思机制。它引入了“环境反馈”将 LLM 的反思转化为一种文本化强化学习Verbal Reinforcement Learning。它并不是简单地在节点加上工具而是让 Agent 在尝试完整个任务、收到外部“评估器”的客观打分后将失败的教训总结成长期经验Memory并在下一次重新挑战该任务时带着这些经验。二、 Reflexion 的底层架构与原理文本化强化学习传统的强化学习RL通过标量奖励Scalar Reward来更新模型的神经网络权重Weights。但在推理阶段更新 LLM 权重成本太高且容易灾难性遗忘。Reflexion 提出了一种替代方案用自然语言文本代替标量奖励用短期/长期记忆池代替神经网络权重的更新。其核心包含三个主要组件我们可以用数学表达来严谨定义Actor执行者, 可以是CoT或者ReAct基于当前的上下文x xx短期记忆、历史轨迹h t h_tht​和过去的经验教训长期记忆m mm生成下一步动作或文本a t a_tat​。a t ∼ π θ ( a t ∣ x , m , h t ) a_t \sim \pi_{\theta}(a_t | x, m, h_t)at​∼πθ​(at​∣x,m,ht​)pass: 怕大家不懂 x, m,h t h_tht​的区别下面举个拼接后的prompt例子直观感受下 [ System Message (x 和 m) ] 你是一个高级程序员Agent。 【任务目标 (x)】写一个爬虫脚本爬取某网站的内容。 【过往惨痛教训 (m)】上次你忘记加 User-Agent 导致被封禁了这次一定要加上。 [ Agent Action History ($h_t$) ] 【第 1 步】 Thought: 我需要先发送请求测试一下网站连通性。 Action: requests.get(url) -- (a_1) Observation: 403 Forbidden -- (o_1) 【第 2 步】 Thought: 哦我遇到了403而且我想起了教训我应该加伪装。 Action: requests.get(url, headers{User-Agent: Mozilla...}) -- (a_2) Observation: 200 OK返回了HTML网页内容... -- (o_2) [ Current Step ($a_t$) ] 请基于上述信息给出你的下一步思考和动作Evaluator评估器 定义奖励函数稀疏奖励这是 Reflexion 打破“盲目自信”的关键。它对 Actor 产生的完整轨迹进行客观评估计算出一个标量分数或布尔值r rr。这个评估器可以是外部代码编译器、测试用例、或者另一个被设定为严格裁判的 LLM。r f e v a l ( x , h f i n a l ) r f_{eval}(x, h_{final})rfeval​(x,hfinal​)Self-Reflection自我反思器当评估器返回失败信号时反思器介入。它接收x xx,h f i n a l h_{final}hfinal​,r rr并生成一段自然语言经验总结s r srsr比如“我在步骤 3 错误地假设了变量为负数下次遇到类似情况我应该先检查变量的符号”。s r LLM r e f l e c t ( x , h f i n a l , r ) sr \text{LLM}_{reflect}(x, h_{final}, r)srLLMreflect​(x,hfinal​,r)随后这个s r srsr会被追加到经验记忆池m mm中供 Actor 下次尝试时使用m ← m ∪ { s r } m \leftarrow m \cup \{sr\}m←m∪{sr}。三、 基于LangGraph 实现的核心组件与代码在 LangGraph 中实现 Reflexion核心思想是构建一个带有重试循环的状态机并在每次失败时累积reflections。以下是 LangGraph 伪代码实现fromtypingimportAnnotated,List,TypedDictfromlanggraph.graphimportStateGraph,ENDimportoperator# 1. 定义状态 (State)# 这里的 reflections 就是 Reflexion 论文中提到的长期记忆(Memory)classAgentState(TypedDict):task:strcurrent_trajectory:Annotated[List[str],operator.add]# 当前尝试的执行轨迹 (短期记忆)reflections:List[str]# 跨尝试的经验总结 (长期记忆)is_success:booliterations:int# 2. 节点Actor (执行者)defactor_node(state:AgentState):taskstate[task]reflections\n.join(state[reflections])# 巧妙之处Prompt 中注入过往的惨痛教训promptf 你的任务是:{task}【过去的教训】 如果你之前失败过请务必参考以下教训不要重蹈覆辙{reflections}请给出你的推理和行动步骤。 # 模拟 LLM 调用和工具执行trajectoryllm_invoke_and_act(prompt)return{current_trajectory:[trajectory],iterations:state[iterations]1}# 3. 节点Evaluator (评估器) - 提供客观的外部环境反馈defevaluator_node(state:AgentState):trajectorystate[current_trajectory][-1]# 调用外部环境(如Python编译器、单元测试、或者LLM Judge)判断是否真正解决is_success,feedbackexternal_environment_check(state[task],trajectory)return{is_success:is_success,eval_feedback:feedback}# 4. 节点Reflector (反思器) - Verbal RL 的核心defreflector_node(state:AgentState):taskstate[task]trajectorystate[current_trajectory][-1]promptf 任务:{task}你的执行轨迹:{trajectory}环境评估结果: 失败。 请作为一位严厉的复盘专家分析你在上述轨迹中为何失败。 不要给出借口用一两句话总结根本原因并给出一个明确的、针对下次尝试的【行动建议】。 reflection_textllm.invoke(prompt)return{reflections:state[reflections][reflection_text],current_trajectory:[]}# 清空短期轨迹准备重试# 5. 定义图结构 (Graph)workflowStateGraph(AgentState)workflow.add_node(Actor,actor_node)workflow.add_node(Evaluator,evaluator_node)workflow.add_node(Reflector,reflector_node)# 定义边和条件路由workflow.set_entry_point(Actor)workflow.add_edge(Actor,Evaluator)defcheck_success(state:AgentState):ifstate[is_success]:returnendifstate[iterations]MAX_ITERATIONS:returnendreturnreflect# 根据 Evaluator 的结果决定是结束还是去反思workflow.add_conditional_edges(Evaluator,check_success,{end:END,reflect:Reflector})workflow.add_edge(Reflector,Actor)# 反思完后带着经验重新交给 Actor 尝试appworkflow.compile()四、 常见疑难杂症 QAQ1: 如果充当 Reflector的大模型自身能力不足或者我们让同一个较弱的模型如 7B 的开源小模型同时兼任 Actor 和 Reflector它生成的 Reflection 会不会全是幻觉从而带偏下一次尝试深度解析这是业界常说的“能力倒挂”问题。如果让同一个 LLM 既当运动员又当裁判它很可能会为自己的错误辩护。解决方案解耦评估与反思正如架构图所示Evaluator 最好是确定性的环境反馈如代码报错信息Traceback、正则匹配测试用例。Reflection 节点只负责将确定性的失败信号“翻译”成自然语言指导。异构模型协同Actor 可以用轻量级模型如降低成本而 Reflection / Evaluator 节点使用推理能力最顶尖的模型如 GPT-4 / Claude 3.5 Opus。Q2: 随着重试次数增加Reflections 数组越来越大导致 Token 消耗爆炸且 LLM 发生“注意力涣散Lost in the middle”怎么解决深度解析传统的 Reflexion 只是简单地 Append 记忆这在多步复杂任务中不可持续。解决方案记忆压缩Memory Summarization在 Reflector 节点中不应仅仅追加新的总结而应该让大模型对现有的[Reflection 1, Reflection 2, ...]结合当前的错误进行融合与提炼保持记忆池始终只有少数几条最高密度的“行动守则”。引入向量检索下一篇文章介绍的 LATS 演进方向只将与当前执行步骤语义相似的过往反思通过 RAGRetrieval-Augmented Generation召回而不是全量注入 Prompt。Q3: Reflexion 下一步演进是 LATS (Language Agent Tree Search)。为什么要引入 LATSReflexion 最大的瓶颈是什么Reflexion 的瓶颈它本质上是一个线性重试Linear Trial-and-Error的过程。它抛弃了之前的失败轨迹只是带着经验从头开始。这在步骤极多的任务中效率极低类似于每次做错一道大题都要把试卷擦了从第一步重新写。为何演进为 LATSLATS结合了蒙特卡洛树搜索 MCTS 反思。它保留了整个状态树如果在第 5 步走错了Agent 不需要从第 1 步重头开始它可以退回到第 4 步的节点带着环境的负向反馈Reward -1去探索另外的节点。LATS Reflexion评估与反思 Tree Search状态回溯与全局最优搜索。