跳到主要内容

Reflexion

Reflexion（Language Agents with Verbal Reinforcement Learning）研究的是：Agent 失败之后，能否把失败经验写成语言记忆，并在下一次尝试中利用这些经验改进行为。

它不是传统强化学习。

传统强化学习通常通过奖励信号更新策略参数。

Reflexion 的关键是把反馈写进上下文或记忆，而不是更新模型权重。

对工程系统来说，它的价值在于把失败复盘产品化：

  • 失败要有评估器判断。
  • 失败原因要结构化。
  • 反思要绑定具体 trace。
  • 反思要影响下一次执行。
  • 错误经验要能过期、撤销和审计。

1. 背景问题​

很多 Agent 在第一次尝试时会失败。

失败原因可能包括：

  • 计划不完整。
  • 工具选错。
  • 参数错误。
  • 检索证据不足。
  • 代码没有通过测试。
  • 对环境反馈理解错误。
  • 达到预算前没有完成任务。

如果每次失败都从零开始，系统会重复犯同样的错。

如果只把所有历史对话塞进上下文，系统又会受到噪声、成本和错误记忆污染。

Reflexion 提出一个中间方案：

  • 执行任务。
  • 用评估器判断成功或失败。
  • 失败时生成自然语言反思。
  • 把反思放入记忆。
  • 下一轮尝试读取这些反思。

2. 一句话结论​

Reflexion 适合把可评估任务中的失败经验转化为短期或情景记忆，但它依赖可靠评估器；如果评估器错误，反思会把错误经验固化。

3. 方法结构​

论文中的角色可以映射为工程组件。

论文角色工程组件输入输出
Actor执行 Agent任务、上下文、记忆动作、答案、轨迹
Evaluator评估器输出、环境反馈、测试结果成功/失败、分数、错误类型
Self-Reflection复盘器失败轨迹、评估信号语言经验、修正建议
Memory经验存储反思、来源、适用范围下一轮可检索上下文

4. 实验设置与证据边界​

Reflexion 论文在多类任务上评估。

代表任务包括：

  • ALFWorld：交互式环境任务。
  • HotPotQA：多跳问答。
  • HumanEval：代码生成任务。

这些任务有一个共同特点：

它们能够提供某种评估信号。

例如：

  • 环境是否完成目标。
  • 问答是否匹配标准答案。
  • 代码是否通过测试。

论文证据支持的是：

  • 在可多轮尝试的任务中，语言反思可以帮助下一轮改进。
  • 把失败经验写入记忆比完全从零开始更有效。
  • 反思不一定需要更新模型参数。

证据不支持的是：

  • 所有任务都适合自动反思。
  • 模型自评足够可靠。
  • 反思越多越好。
  • 失败后可以无限自动重试。

5. 核心贡献​

Reflexion 的贡献主要有四点。

第一，它把失败反馈从数值奖励转成语言经验。

这让人类更容易阅读、编辑和审计失败原因。

第二，它把执行、评估和反思拆成三个角色。

这比单个模型一边做事一边自我评价更容易工程化。

第三，它提出了轻量学习路径。

在不能或不想微调模型时，可以通过记忆和上下文改变后续行为。

第四，它推动了 trace-driven improvement。

Agent 的改进不只来自 prompt 调整，也来自真实失败轨迹的系统化复盘。

6. 局限表​

局限具体表现工程后果缓解方式
依赖评估器Evaluator 错误会导致错误反思系统下次更坚定地走错方向优先使用测试、规则、人工标注等强信号
反思可能虚构模型会生成合理但不真实的失败解释复盘污染经验库反思必须引用 trace、错误码或测试结果
成本增加多轮尝试和反思需要更多调用延迟和费用升高设置最大重试次数和收益阈值
记忆污染错误经验长期存在后续任务被过期经验误导加有效期、适用范围、置信度和撤销机制
自动重试有风险失败后继续执行可能扩大副作用重复发信、重复扣费、重复修改高风险工具失败后停止并请求人工
泛化有限一个任务的反思未必适用于另一个任务跨任务迁移导致错误建议记忆检索要按任务类型、工具、环境过滤

7. 今天工程系统如何借鉴​

Reflexion 最适合借鉴到失败处理和持续改进流程。

推荐把反思设计成结构化对象，而不是随意文本。

{
  "reflection_id": "ref_20260509_001",
  "source_trace_id": "trace_8842",
  "task_type": "code_fix",
  "failure_type": "test_failure",
  "evidence": {
    "test": "tests/test_parser.py::test_empty_input",
    "error": "Expected [] but got None"
  },
  "lesson": "处理空输入时应返回空列表，不要返回 None。",
  "next_attempt_hint": "修改 parse_items 的 early return 分支，并重新运行相关测试。",
  "scope": {
    "repo": "example-service",
    "files": ["parser.py"]
  },
  "expires_at": "2026-06-09"
}

这种结构比单纯一句“下次要更小心”有用得多。

可借鉴工程动作：

  • 对失败 trace 做自动分类。
  • 把测试失败、工具错误、权限错误分开处理。
  • 为反思设置来源证据。
  • 为反思设置适用范围和有效期。
  • 将高价值失败样本加入评测集。
  • 把反思结果用于下一轮 prompt 或任务规划。

8. 不能直接照搬的地方​

不要把“模型自我反思”当作可靠评估。

如果任务有客观验证方式，应优先使用：

  • 单元测试。
  • 集成测试。
  • 规则校验。
  • schema 校验。
  • 人工验收。
  • 环境成功信号。

不要让系统无限重试。

多轮反思应该受这些条件约束：

  • 最大轮数。
  • 最大成本。
  • 最大时间。
  • 风险等级。
  • 是否出现同类重复错误。

不要把所有反思写入长期记忆。

反思可能只适合某次任务、某个版本、某个工具状态。

长期保存前需要去重、验证和人工抽检。

9. 评测方法​

评测 Reflexion 类系统要看反思是否真的改善下一轮。

指标说明评测方式
First Attempt Success第一次尝试成功率不使用反思的基线
Retry Success Lift使用反思后的成功率提升A/B 或固定样本回放
Reflection Grounding反思是否基于真实失败证据检查 trace 引用
Failure Classification Accuracy错误分类是否正确人工标注对比
Cost per Recovered Task每个被挽救任务的额外成本成本日志
Harmful Retry Rate重试造成副作用的比例高风险动作审计
Memory Pollution Rate被判定为错误或过期反思的比例抽样复核

一个可操作的评测流程：

1. 准备一批失败任务和对应 trace。
2. 固定 Actor 和工具版本。
3. 分别运行无反思、通用提示反思、结构化反思三组。
4. 对比重试成功率、平均成本和失败类型变化。
5. 抽样检查反思是否引用真实证据。
6. 将有帮助的失败样本沉淀为回归评测。

10. 安全与治理​

Reflexion 的安全风险来自两个方向。

第一是失败后的自动重试。

如果任务涉及真实副作用，失败重试可能带来重复操作。

例如：

  • 重复发送邮件。
  • 重复创建订单。
  • 重复修改配置。
  • 重复调用付费接口。

第二是错误反思进入记忆。

一条错误反思可能影响未来很多任务。

治理要求：

  • 高风险动作失败后默认停止。
  • 重试前检查幂等键。
  • 反思必须绑定 trace。
  • 反思记忆支持删除和修正。
  • 长期反思进入共享库前要通过审核。
  • 评估器版本变化后要重新验证旧反思。

11. 适用与不适用场景​

适用场景：

  • 代码生成和修复。
  • 可自动测试的工作流。
  • 有明确成功信号的环境任务。
  • 可回放的工具调用任务。
  • 需要从失败样本持续改进的内部 Agent。

不适用场景：

  • 没有可靠评估器的开放式判断任务。
  • 高风险不可逆动作。
  • 成本或延迟极其敏感的请求。
  • 失败原因无法从 trace 中验证的任务。

12. 与其他方法的关系​

ReAct 关注执行中的推理和行动交替。

Reflexion 关注执行失败后的复盘和下一轮改进。

Tree of Thoughts 可以在单次尝试中搜索多个候选。

Reflexion 可以在尝试之间积累经验。

Voyager 使用环境反馈和代码技能库持续积累能力，与 Reflexion 的失败经验记忆有相通之处。

13. 权威资料​