反思循环怎么运作
Reflexion（Shinn et al., NeurIPS 2023）在任务失败后让模型总结失败原因，写成可复用的经验文本，下一轮带着这些经验重试——不更新模型参数，改进完全靠文本记忆。前提是必须有外部评估器（单元测试、格式校验、规则检查），否则「反思」会退化成自我安慰：模型可能把失败原因写错，然后在错误的方向上改。它和 Self-Refine 的差别在于经验跨尝试保留并累积。
基本信息
| 循环结构 | 尝试 → 评估 → 反思 → 带经验重试 |
|---|---|
| 必要条件 | 可自动判定的评估器（测试、校验器、规则） |
| 经验载体 | 文本（写在提示里），不涉及参数更新 |
| 与 Self-Refine 差别 | Reflexion 的经验跨尝试保留并可累积 |
典型使用场景
- 代码生成修复：跑单元测试，失败则读报错写反思再改，直到通过
- 结构化输出修复：解析失败时记录失败位置与原因，下一轮带上修正要点
- SQL 生成：用执行报错与结果校验驱动多轮改写
- 规则校验类任务：字段约束不满足时定位到具体约束并重试
- Agent 流程：动作失败后把教训写入经验区，避免重复同样的错误调用
循环结构
循环结构
尝试 1：执行任务 → 评估（通过 / 失败）
反思：失败原因是什么？下次要避免什么？→ 写成 3 条要点
尝试 2：本次提示 = 原任务 + 反思要点，重新执行
……直到通过或达到轮数上限
# 评估必须由程序给出，不要用模型的自我评价当唯一判据
# 反思要点限制在 3 条以内，避免上下文随轮次膨胀
# 设置最大轮数（常见 3-5 轮）并记录每轮失败原因，便于统计哪类问题反复出现循环要素与检查点
| 要素 | 内容 | 检查点 |
|---|---|---|
| 任务 | 原始任务描述与输入 | 每轮是否携带同一份原始输入 |
| 评估器 | 测试、校验器或规则脚本 | 输出是否结构化、可自动判定 |
| 反思 | 失败原因与规避要点 | 是否指向具体错误，而非泛泛而谈 |
| 经验注入 | 反思要点并入下一轮提示 | 条数是否受控、是否与旧经验重复 |
没有外部评估器时，「反思」容易变成自我安慰，失败原因可能全写错；先有判定手段，再谈反思循环。
反思要点随轮次累积注入，需限制条数并去重，否则上下文迅速膨胀，反而降低后续尝试的质量。