Reflexion Agent 的设计目标很明确：当模型第一次回答错误时，不让它盲目重试，而是利用环境给出的失败信号生成有针对性的反思，并把反思作为后续推理的上下文。它把传统强化学习中的奖励信号转化为自然语言反馈，从而在冻结模型权重的前提下提升任务成功率。
这种机制非常像人类求解复杂问题：第一次提交代码后编译器报错，开发者不会清空代码从头乱写，而是会读取错误信息，定位是语法问题、类型问题还是逻辑漏洞，然后只修改相关部分。Reflexion Agent 把这个过程拆成了动作、评价、反思、记忆四个步骤。普通 ReAct 风格的 Agent 更像单向执行器，失败时通常只能改变采样随机性；而 Reflexion 增加了一个记忆写入回路，使失败经验能够显式影响后续推理。
一、Reflexion Agent 的核心组成
Reflexion Agent 通常由三个角色组成：Actor、Evaluator 和 Self-Reflection 模型。它们分别承担执行、评价和反思的职责，彼此之间通过自然语言传递信息。
Actor 是执行主体，负责根据任务描述、历史动作以及记忆中的反思内容生成下一步动作。它生成的不是简单文本答案，而是一段带有思考过程的轨迹。例如在代码任务中会输出完整代码，在网页操作任务中会输出点击、输入或搜索动作。轨迹越完整，后续评价和反思就越容易定位问题。
Evaluator 负责与环境交互，判断这轮轨迹是否成功。它可以返回二元奖励，也可以返回更细粒度的反馈，例如编译器报错信息、单元测试结果或子目标完成情况。只要反馈中包含可供分析的信息，就能为反思模型提供判断依据。
最关键的是 Self-Reflection 模型。它拿到任务、失败轨迹和环境反馈后，输出一段自然语言反思。这段反思并不是泛泛而谈的提醒，而是需要指出具体问题、可能原因和改进方向。例如当代码因为索引越界失败时，反思应该写入列表在空状态下直接访问第一个元素导致 IndexError，需要先检查长度。这段文本被存入记忆后，会拼接到下一轮 Actor 的输入中。
记忆模块让反思不只作用于当前轮次，还能跨轮次累积。简单实现可以使用列表存储所有反思，适合单任务连续尝试；更复杂的实现可以按任务类型建立长期记忆库，让不同任务之间共享经验。记忆的存在是 Reflexion 区别于普通重试机制的主要特征。
二、环境反馈如何被转换成可执行经验
Reflexion 对反馈形式没有严格限制，这也是它能快速适配不同任务的原因。在代码生成任务中，反馈通常来自单元测试、编译器和解释器，可能包含失败测试名称、错误类型和堆栈信息。在决策型任务中，反馈可能只是任务是否完成，或者环境中某个状态是否达成。在问答和搜索任务中，反馈可以来自检索结果是否包含答案、是否存在事实冲突。
反思模型需要把这些异构反馈压缩成一段短文本。为了避免反思本身变得冗长，通常会限制反思长度，并要求模型只保留对后续决策有用的信息。一个失败轨迹可能长达几千 token，但反思只需要保留几十到一两百字。压缩过程中，模型倾向于保留导致失败的因果链，而不是记录每一步操作。
环境反馈的质量会直接影响反思质量。如果环境只返回成功或失败，而没有说明原因，反思模型只能根据轨迹猜测错误来源。这时可以通过额外设计中间评价来增强反馈，例如把任务拆成多个子目标，每完成一个子目标就返回一次奖励，使反思更有据可依。也可以让 Evaluator 返回结构化的错误类别，比如语法错误、逻辑错误、超时错误等，降低反思模型的判断难度。
三、实现一个最小 Reflexion 循环
下面给出一个简化版的 Python 实现，重点展示反射循环如何把环境反馈写入记忆。示例中假设模型调用已经被封装为 actor.act、evaluator.evaluate 和 reflector.reflect 三个接口。
class ReflexionAgent:
def __init__(self, actor, evaluator, reflector):
self.actor = actor
self.evaluator = evaluator
self.reflector = reflector
self.memory = []
def run(self, task, max_trials=3):
for trial in range(max_trials):
context = task
if self.memory:
context += "\n\n[Reflections]\n" + "\n".join(self.memory)
trajectory = self.actor.act(context)
score, feedback = self.evaluator.evaluate(trajectory)
if score >= 1.0:
return {"success": True, "trajectory": trajectory}
reflection = self.reflector.reflect(
task=task,
trajectory=trajectory,
feedback=feedback
)
self.memory.append(reflection)
print(f"trial {trial + 1} failed, reflection saved")
return {"success": False, "memory": self.memory}
这段代码的关键在于 context 的构造方式。每次重新尝试时，任务描述后面都会拼接之前所有反思。这样 Actor 看到的并不是一个空白的重试任务，而是一个带有失败经验的任务版本。第一轮失败后，memory 为空，context 只包含原始任务；第二轮开始，上一轮的反思就会进入上下文，成为模型生成新轨迹时的约束条件。
这种实现适合单个任务的连续修正。如果要在多个任务之间共享经验，可以将 memory 从列表改成向量数据库或按任务类型组织的字典。关键设计是反思的粒度：太粗则无法指导行动，太细则会占用大量上下文窗口。实践中通常会在反思提示中加入长度限制和结构化模板，要求模型只输出问题原因和下一步改进。
除了记忆结构，循环终止条件也需要仔细设计。示例中用最大尝试次数防止无限重试，但在实际系统中还可以加入反思有效性检查，例如连续两次生成相同反思时提前停止，或者当评分提升幅度低于阈值时切换策略。这样可以避免 Agent 在错误方向上浪费大量推理资源。
四、反思机制的优势与局限
Reflexion 的最大优势是无需更新模型参数，却能显著提升需要长期规划和试错的任务表现。传统少样本提示在面对新错误时只能重新生成，错误模式可能反复出现。写入记忆后，模型相当于拥有了一个随任务增长的经验库。这种经验还可以被人类阅读和审计，比隐式的参数更新更加透明。
但它也不是万能方案。反思质量高度依赖基础模型能力，如果模型无法准确定位失败原因，错误反思会污染后续推理，甚至把原本正确的方向带偏。上下文长度也是实际瓶颈，连续反思累积后可能超出模型输入限制，因此需要定期压缩或选择性丢弃旧反思。另一个问题是，当任务失败原因本身不可观察，或者环境反馈存在噪声时，反思可能产生误导。
改进方向通常包括：引入更强的评估器来验证反思是否真实有效；把反思与检索增强结合，从历史库中只召回与当前任务相关的经验；以及使用树状搜索保留多条反思路径，避免单一反思把 Agent 锁死在局部错误中。理解这些机制后，再回头看环境反馈，就不只是判断对错的信号，而是构建 Agent 经验记忆的第一手材料。
Reflexion Agent环境反馈推理修正修改时间：2026-08-25 18:11:54