1. 先搞清楚 Reflexion 这篇论文到底解决了什么问题如果你正在研究 AI Agent或者想找一个能让大语言模型LLM在执行任务时“吃一堑长一智”的方法那么 Reflexion 这篇论文绝对值得你花时间精读。它不是教你搭建一个功能花哨的 Agent而是直击一个核心痛点如何让一个只会“纸上谈兵”的 LLM通过反思过去的失败在后续尝试中变得更聪明、更可靠。很多人一提到 Agent就想到工具调用、多步规划、记忆这些模块。但 Reflexion 的切入点更底层——它关注的是决策后的评估与迭代。简单来说一个 Agent 执行任务失败了传统的做法可能是直接报错或者换个参数重试。而 Reflexion 的核心思想是让 Agent 自己“复盘”这次失败生成一段文字形式的“反思”Reflection然后把这段反思和原始任务、历史记录一起作为新的输入驱动下一次尝试。这听起来简单但效果显著。论文通过编程代码调试、决策AlfWorld 环境和问答HotpotQA三个领域的实验证明引入反思机制后Agent 的成功率有显著提升。它解决的正是 LLM 在复杂、动态环境中“一条道走到黑”或“随机试错”的局限性。所以这篇论文不适合只想快速跑通一个 Agent Demo 的新手。它更适合那些已经了解基础 Agent 框架比如 ReAct并且开始思考“如何让 Agent 在真实、开放环境中持续学习和优化”的开发者或研究者。它的价值不在于提供一个开箱即用的工具而在于提供一种可复用的方法论和架构思路。2. 理解 Reflexion 的核心机制不只是“想一想”Reflexion 的框架并不复杂但理解其设计细节才能知道怎么用。它主要包含三个核心角色和两个关键循环。2.1 三个核心角色Actor执行者这就是你的基础 Agent比如一个采用 ReAct推理行动模式的 LLM。它负责接收任务与环境交互如运行代码、操作模拟器并产生行动轨迹。Evaluator评估者这是一个独立的判断模块。它的任务不是执行而是客观评价 Actor 这次尝试的结果。在编程任务中评估者就是编译器或单元测试——代码跑不通就是失败跑通了并且通过测试就是成功。在问答任务中可能就是对比标准答案。Self-Reflection自我反思模块这是 Reflexion 的灵魂。它也是一个 LLM但它的输入是本次失败的任务描述、Actor 的行动轨迹、以及环境反馈的错误信息。它的输出是一段结构化的自然语言文本即“反思”。这段反思需要分析失败原因并提出具体的改进建议。2.2 两个关键循环整个框架的运行依赖于两个循环内层行动循环Actor 在一个任务回合内进行多步思考和行动ReAct直到任务完成或达到步数限制。外层反思循环当一个任务回合失败后触发反思模块。反思模块生成的文本会被添加到下一个任务回合的提示词Prompt中作为“历史经验”指导新的尝试。这个过程可以重复多次直到成功或达到最大反思次数。关键在于反思是文本化的、可积累的。它不像只是调整几个内部参数而是把失败教训变成了可以喂给 LLM 的“经验故事”。下一次 Actor 看到“上次我因为没导入某个库而失败”它就会更注意检查依赖。2.3 与常见方案的差异很多人会混淆 Reflexion 和简单的“重试”或“思维链”CoT。vs 简单重试简单重试是用同样的提示词再试一次期望模型随机采样到更好的输出。Reflexion 是加入了新的、有针对性的信息反思引导模型走向不同的、更可能成功的推理路径。vs 思维链CoTCoT 是让模型在单次推理中展示思考步骤。Reflexion 是在多次尝试的回合之间进行总结和规划属于元认知层面的优化。你可以把 Reflexion 看作是为 CoT 或 ReAct 加装了一个“事后复盘”系统。在实际应用中这意味着你需要设计好评估标准和反思提示词。评估必须自动化、客观如测试用例。反思提示词要引导模型从轨迹中提取具体错误而不是泛泛而谈“我做得不好”。3. 如何在自己的环境中复现或借鉴 Reflexion 思想论文本身没有提供一键运行的代码库但它的思想完全可以被工程化。下面我以一个简化的“代码调试 Agent”为例拆解实现步骤。这个 Agent 的目标是给定一个自然语言描述的需求和有 bug 的代码让 Agent 修复它。3.1 环境与依赖准备你不需要强大的 GPU因为核心是 LLM 的 API 调用。你需要准备Python 环境3.8 即可。LLM APIOpenAI GPT-4/GPT-3.5-Turbo或开源的 Llama 3、Qwen 等需本地部署或使用对应 API。Reflexion 对模型的分析和总结能力要求较高建议使用能力较强的模型作为反思模块。关键库openai(或litellm,transformers),python-dotenv(管理 API Key)。一个安全的代码执行环境非常重要绝对不能直接exec不可信的代码。推荐使用docker容器隔离或者使用像piston这样的开源代码执行 API。这里为演示我们使用一个极度简化的、仅做字符串匹配的“安全执行”来模拟。# 示例创建环境并安装基础库 pip install openai python-dotenv3.2 搭建核心框架我们创建几个核心类来对应 Reflexion 的模块。import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) class CodeActor: 执行者负责生成代码修复方案 def __init__(self, modelgpt-3.5-turbo): self.model model def act(self, task_description, buggy_code, reflection_history): prompt f 你是一个资深程序员。你的任务是修复一段有bug的Python代码。 任务描述{task_description} 历史反思供参考{reflection_history} 有bug的代码 python {buggy_code} 请直接输出修复后的完整代码不要任何解释。 response client.chat.completions.create( modelself.model, messages[{role: user, content: prompt}], temperature0.2 # 低温度保持确定性 ) fixed_code response.choices[0].message.content.strip() # 清理可能出现的代码块标记 fixed_code fixed_code.replace(python, ).replace(, ).strip() return fixed_code class CodeEvaluator: 评估者负责验证代码是否正确这里用模拟 def evaluate(self, code, task_description): # 真实场景应运行单元测试。这里用简单规则模拟。 # 规则1代码必须包含 def solve() # 规则2代码不能有语法错误这里简单用 exec 检查生产环境应用容器 try: # 警告仅为演示实际环境必须隔离 exec(code, {}) if def solve() in code: return True, 代码通过检查。 else: return False, 错误代码中未找到要求的 def solve() 函数。 except SyntaxError as e: return False, f语法错误{e} except Exception as e: return False, f运行时错误{e} class ReflectionModule: 反思模块分析失败原因生成反思文本 def __init__(self, modelgpt-4): # 反思可以用更强的模型 self.model model def reflect(self, task, buggy_code, fixed_code_attempt, error_feedback): prompt f 你是一个代码评审专家。刚才的一次代码修复尝试失败了。 原始任务{task} 原始有bug的代码{buggy_code} 本次尝试修复的代码{fixed_code_attempt} 环境/测试给出的错误反馈{error_feedback} 请你分析本次失败的根本原因并为下一次修复尝试提供具体、可操作的建议。 反思和建议 response client.chat.completions.create( modelself.model, messages[{role: user, content: prompt}], temperature0.5 ) return response.choices[0].message.content.strip() class ReflexionAgent: Reflexion 智能体总控制器 def __init__(self, max_reflections3): self.actor CodeActor() self.evaluator CodeEvaluator() self.reflector ReflectionModule() self.max_reflections max_reflections self.reflection_history # 积累的反思文本 def run_task(self, task_description, buggy_code): print(f开始任务: {task_description[:50]}...) for attempt in range(self.max_reflections 1): # 1 给初始尝试 print(f\n--- 第 {attempt1} 次尝试 ---) # 1. Actor 行动生成修复代码 fixed_code self.actor.act(task_description, buggy_code, self.reflection_history) print(f生成的代码:\n{fixed_code[:200]}...) # 2. Evaluator 评估 success, feedback self.evaluator.evaluate(fixed_code, task_description) print(f评估结果: {success}, 反馈: {feedback}) if success: print(任务成功) return fixed_code else: # 3. 失败则进行反思 print(任务失败启动反思...) reflection self.reflector.reflect(task_description, buggy_code, fixed_code, feedback) print(f生成反思: {reflection[:150]}...) # 将本次反思追加到历史中指导下一次尝试 self.reflection_history f\n[第{attempt1}次反思]: {reflection}\n print(f达到最大反思次数({self.max_reflections})任务失败。) return None3.3 运行一个最小实例现在我们可以模拟一个任务。if __name__ __main__: agent ReflexionAgent(max_reflections2) task 编写一个函数 solve()计算并返回列表中所有正整数的和。 buggy_code def solve(lst): sum 0 for i in lst: if i 0: # 这里逻辑正确 sum i return sum # 缺少函数调用和测试 # 第一次运行代码没有语法错误但缺少 def solve()实际上我们的buggy_code里是有的。 # 我们故意给一个会失败的代码 buggy_code_fail def solve(lst): total 0 for num in lst: if num 0: total total num # 这行没问题 # 故意少一个 return 语句 result agent.run_task(task, buggy_code_fail) if result: print(\n最终修复的代码) print(result)在这个模拟中第一次尝试的代码缺少return语句评估器会返回失败和反馈。反思模块会分析这个错误生成如“失败原因函数没有返回语句。建议确保函数在所有逻辑分支后都有明确的 return 语句。”这样的文本。第二次尝试时Actor 会看到这段历史反思从而更有可能生成正确的代码。4. 将 Reflexion 思想应用到更广泛的 Agent 场景理解了代码调试的例子你可以把 Reflexion 模式迁移到任何需要试错和学习的 Agent 任务中。关键在于设计好三个部分4.1 设计评估者Evaluator评估必须是自动化、明确、可编程的。这是 Reflexion 能运行的前提。编程单元测试框架如 pytest、编译器错误码。决策如网页操作检查目标页面是否出现特定元素、URL 或文本。问答与标准答案进行字符串匹配或嵌入相似度计算。创意写作这可能比较主观但可以设定一些客观指标如是否包含关键词、是否符合格式、长度是否达标。不要依赖另一个 LLM 来做核心评估这会导致循环不稳定和成本激增。LLM 可以作为辅助但成功/失败的最终裁决应由确定性的规则或代码完成。4.2 设计反思提示词Prompt for Reflection反思提示词的质量决定了学习效率。好的反思提示词应引导模型定位具体错误点是语法错误、逻辑错误、工具使用顺序错误还是对目标的理解错误关联轨迹与反馈将行动历史中的某一步与环境反馈的错误信息联系起来。提出具体改进建议应该是可操作的如“下次应该先调用 API X 获取令牌”“在循环开始前检查列表是否为空”而不是“再仔细一点”。保持简洁与结构化便于后续拼接进提示词。示例提示词框架“你刚完成了一次失败的尝试。以下是任务描述、你的行动历史和环境反馈。请首先用一句话总结失败的直接原因。然后列出 1-3 条针对性的、具体的改进建议用于指导下一次尝试。建议应以‘下次应...’开头。”4.3 管理反思历史与上下文长度随着反思次数增加历史记录会变长可能超出 LLM 的上下文窗口。策略一只保留最近 N 次反思。对于短期任务最近的教训最相关。策略二总结与压缩。在反思次数较多时可以用另一个 LLM 调用对之前的反思进行摘要保留核心教训。策略三向量化检索。将每次的反思存入向量数据库当新任务开始时检索最相关的几条历史反思而不是全部加载。这适合长期运行的、任务多变的 Agent。5. 实践中的关键考量与避坑指南在实际项目中应用 Reflexion 模式有几个点需要特别注意。5.1 成本与延迟问题Reflexion 意味着多次 LLM 调用Actor Reflector成本是单次尝试的 2-N 倍。优化策略设置合理的最大反思次数比如 3-5 次避免陷入无限循环。分层使用模型让能力较弱的模型如 GPT-3.5-Turbo做 Actor能力强的模型如 GPT-4做 Reflector。反思的质量比生成的速度更重要。并行反思与行动在某些场景下可以基于一次失败并行生成多个不同的反思角度和新的尝试方案然后选择最优解但这会进一步增加成本。5.2 评估器的可靠性是生命线如果评估器本身不准整个 Reflexion 系统就会“学歪”。比如假阳性评估器误判成功Agent 就会把一个错误的解决方案当成经验积累下来。假阴性评估器误判失败会导致 Agent 在已经正确的道路上无效反思甚至引入错误。务必对评估器进行充分测试。在复杂任务中可以考虑“多票制”或“黄金标准测试集”来验证评估器的准确性。5.3 反思可能导致“过度拟合”或“局部最优”Agent 可能学会通过一些“投机取巧”的方式通过当前评估但这些方式并不通用。例如在代码生成中它可能学会了针对特定测试用例的硬编码而不是理解通用算法。对策使用更多样、更全面的测试集进行评估而不仅仅是单个用例。引入随机性在 Actor 的提示词中保留一定的temperature或偶尔忽略部分历史反思鼓励探索。5.4 不是所有任务都适合 ReflexionReflexion 在以下场景效果最好任务有明确、自动化的成功标准。失败原因可分析、可描述。任务具有可重复性且尝试成本可接受。对于以下场景Reflexion 可能不适用或需调整单次机会任务如发送一封不可撤回的邮件。成功标准极其模糊或主观如“写一首感人的诗”。环境反馈极其稀疏或延迟如训练一个下围棋的 Agent需要一整盘棋结束后才知道输赢反思的粒度太粗。5.5 与其它 Agent 组件的结合Reflexion 不是一个完整的 Agent 框架而是一个增强模块。它可以与以下组件无缝结合规划模块在高层规划失败后进行反思重新制定计划。工具使用模块在工具调用序列出错后反思是工具选择错误、参数错误还是顺序错误。记忆模块将反思文本作为长期记忆存储供未来类似任务检索使用。我个人在实践中的建议是不要一上来就在复杂系统中集成 Reflexion。先在一个定义清晰、评估明确的小任务上比如一个固定的代码调试题跑通整个循环观察反思文本的质量和效果。确认这个模式在你的任务和模型上 work 之后再逐步将其嵌入到更大的工作流中。最需要监控的指标不是最终成功率而是反思文本是否真的在指向正确的改进方向。如果反思总是空泛或错误那么整个机制就是在浪费资源。