什么是 Reflexion？它和 ReAct 有什么区别？如何提升 Agent 的自我纠错能力？
参考答案
Reflexion 是 2023 年提出的一种 Agent 推理范式，核心思路是让 Agent 在每次任务执行结束后做一轮”自我反思”，分析哪里做得好、哪里做得烂，然后把反思结论当作经验存下来，下一次再尝试的时候带着这些经验去避免重蹈覆辙。
它和 ReAct 最大的区别就是有没有”回头看”的能力。ReAct 是一步步往前走，做完一步看结果决定下一步干啥，但它不会回过头来审视整个执行过程。Reflexion 每次尝试结束后，不管成不成功，都会做一个反思总结，带着总结从头再来。
ReAct 就像在迷宫里一步步摸索，走到死胡同就换个方向继续走。Reflexion 是走完一遍迷宫，停下来想”刚才第三个路口右转是错的，下次应该左转”，然后带着经验重新走一遍。
Reflexion 的典型流程：执行任务 → 评估结果 → 生成反思 → 存储反思到记忆 → 重新尝试。论文实验显示，在 HumanEval 代码生成任务上，Reflexion 把 pass@1 从 80% 提到了 91%，反思 2-3 轮基本就能收敛。
扩展知识
Reflexion 的三个关键组件
Reflexion 的架构拆开来看就三块：
Actor 负责执行任务，本质上就是一个跑 ReAct 或其他推理策略的 Agent。
Evaluator 负责判断任务完成得怎么样，可以是自动化测试用例、单元测试通过率，也可以让另一个 LLM 来打分。
Self-Reflection 是核心中的核心，它拿到执行过程和评估结果后，生成一段自然语言的反思总结，明确指出”错在哪、为什么错、下次怎么改”。
这三个组件里，Evaluator 的质量直接决定了整个 Reflexion 管不管用。如果评估本身不靠谱，反思就是在瞎总结，越反思越跑偏。
ReAct 和 Reflexion 的核心差异
| 维度 | ReAct | Reflexion |
|---|---|---|
| 执行模式 | 单次执行，一步步往前 | 多次尝试，每次带上之前的经验 |
| 有没有记忆 | 只有当前轮次的短期记忆 | 有跨轮次的经验记忆 |
| 纠错方式 | 靠当前观察即时调整 | 事后反思，下次整体改进 |
| token 消耗 | 相对省 | 多次尝试 + 反思，消耗是 ReAct 的 3-5 倍 |
| 适用场景 | 简单到中等复杂度任务 | 中高复杂度、允许多次尝试的任务 |
在 2026 年 Agent 系统中的实际应用
Reflexion 的思想在现在的 Agent 系统里已经很普遍了，只不过不一定严格按论文那套来：
1）失败重试时的经验注入。Agent 第一次尝试失败，不是无脑重试，先让模型分析失败原因，把结论塞进上下文再重试。Cursor 的 Agent 模式、Claude Code 都在用这个思路，代码报错后会带着错误信息和之前的上下文做修正，比盲重试效果好得多。
2）代码修复场景。Agent 写的代码跑不过测试，把错误堆栈和源码一起发给模型，让它反思哪里写错了再修正。Devin、OpenHands 这类 Coding Agent 基本都内置了这个机制，一般允许 3-5 轮修复循环。
3）多轮优化场景。写文案、做数据分析这类任务，先出初版，Agent 自己评估质量、反思改进点，再生成改进版。
提升 Agent 自我纠错能力的实用技巧
除了 Reflexion 框架本身，工程上还有几个提升纠错能力的手段：
结构化反思模板。不要让模型自由发挥反思，给一个固定模板：
1）这次尝试的目标是什么？
2）实际结果和预期差在哪？
3）根本原因是什么？
4）下次应该怎么做？结构化的反思比自由文本质量稳定得多。
外部验证器。用代码测试、API 调用结果、格式校验这类确定性手段来验证 Agent 的输出，比让 LLM 自评靠谱。LLM 自评最大的问题是”自信但错”，自己打高分但实际结果一塌糊涂。
渐进式难度。先让 Agent 处理简单的子任务，攒够经验再处理复杂任务。不要上来就扔一个大任务让它反思，容易每次都失败，反思也总结不出有价值的经验。
Reflexion 的局限和使用建议
Reflexion 最大的问题就是贵。每次反思要额外调一次 LLM，多次尝试下来 token 消耗是单次执行的 3-5 倍。
实际工程中的建议：不要对所有任务都开 Reflexion，默认用 ReAct 跑，只在第一次尝试失败或结果不达标的时候才启动反思流程。设一个最大反思次数，一般 3 轮足够，超过 3 轮还搞不定大概率是任务本身有问题或者模型能力不够，再反思也没用。
面试官追问
提问：Reflexion 的经验记忆能跨任务复用吗？比如任务 A 的反思结论能帮到任务 B 吗？
回答：原始论文里的经验记忆是任务级别的，每个任务独立反思，不跨任务。但工程上完全可以做跨任务复用，关键是要对反思结论做抽象提炼。比如”调用搜索 API 时要先检查参数格式”这种经验就有通用价值，可以提炼成一条规则放进系统提示词。不过过于具体的经验直接搬到别的任务反而会干扰推理，所以需要一个筛选机制，只保留泛化程度高的经验。
提问：如果评估器本身就是 LLM，怎么避免”自己评自己”导致的偏差？
回答：最稳的做法是拆开来用两个不同的模型，执行用一个、评估用另一个，降低同源偏差。或者设计评估 prompt 的时候强制要求给出扣分理由，不能只打分。再就是把 LLM 评估跟确定性检查结合，比如代码任务先跑测试用例，通过率是硬指标，LLM 只负责评估代码风格和可读性这类主观维度。
提问：在生产环境里，你会怎么控制 Reflexion 的成本？
回答：第一，分级触发，简单任务不反思，只有失败或评分低于阈值的才启动。第二，限制反思轮次，最多 3 轮，再多就直接降级返回当前最好的结果。第三，用便宜的小模型做反思，比如执行用 Claude Opus 4.6，反思和评估用 Claude Sonnet 4，反思不需要太强的推理能力，能总结出”错在哪”就够了，成本能砍掉 60-70%。