当 AI 开始“反思”：探讨 Agent 自我修正机制在复杂任务中的可靠性

复杂任务里，Agent 最危险的时刻，往往不是第一次回答出错，而是发现“可能有问题”之后，持续检查、持续修改，却始终没有真正完成任务。Self-Reflection（自我反思）试图解决的正是这个问题：让 Agent 在执行、评估和修正之间形成闭环。但闭环并不天然等于可靠性；如果缺少明确的完成标准和退出机制，反思也可能变成另一种幻觉来源，甚至把任务拖入逻辑死循环。

Self-Reflection 到底改变了什么

普通语言模型通常在一次生成中完成判断和输出，错误一旦进入后续步骤，Agent 可能继续围绕错误前提规划、调用工具，最终形成越来越长的错误链路。反思机制则在中间插入一个评估阶段，让系统重新检查当前状态、已完成的动作、原始目标以及当前结果是否满足要求。

一个典型流程可以概括为：

执行任务 → 检查结果 → 生成反思 → 调整策略 → 再次执行

这里的关键不在于让模型“想得更多”，而在于让下一次尝试真正获得新的信息。有效的反思应该说明哪里失败、失败证据是什么、下一步准备改变什么，而不是泛泛地说“需要更加仔细”。

Reflexion 采用的思路，是把失败经验以自然语言形式保存下来，并带入下一次尝试。它不要求即时修改模型参数，而是通过记忆让 Agent 避免重复相同的错误。Self-Refine 则更接近“生成—批评—改进”：生成器先产生结果，再由反思器检查并提出修改建议，随后生成器根据建议优化输出。

两者都能形成自我修正，但适用条件并不完全相同。Self-Refine 更适合在同一任务内修改文本、方案或推理结果；Reflexion 更强调跨尝试保留失败经验，适合存在多轮行动和工具调用的任务。它们都不能保证反思内容正确，因为负责批评的模型仍可能误判。

三种反思策略的可靠性差异

多轮对齐：让不同阶段互相校验

一种常见设计是把 Agent 拆成执行者、评估者和修正者。执行者负责完成任务，评估者检查输出是否符合目标，修正者根据评估结果重新规划。角色分离可以减少“刚生成答案就立刻自我肯定”的问题，也能让提示词分别围绕行动、评价和修改进行设计。

但多轮对齐并不等于真正独立的审查。如果执行者和评估者使用相同的错误上下文、相同的偏见和相同的判断标准，它们可能只是重复确认同一个错误。反思轮数越多，也不一定越可靠，可能只是让错误解释变得更加完整、更加自信。

因此，多轮反思应当有明确任务边界：每一轮只回答当前是否满足标准、缺失了什么证据，以及下一步要改变哪一个变量。不要让反思器无限扩展新的问题。

外部验证：把“我认为正确”变成可检查结果

外部验证通常比纯语言自评更有约束力。对于代码任务，可以使用实际执行结果或测试结果；对于结构化输出，可以检查字段、格式和必填条件；对于需要事实依据的任务，则可以要求结果与输入资料进行对应核验。外部验证的价值在于，它不只询问 Agent“你觉得完成了吗”，而是提供一个相对客观的完成条件。

这类机制尤其适合高风险步骤。比如，Agent 认为自己已经修复问题，并不代表问题真的消失；只有验证结果满足预先定义的条件，系统才应把任务标记为完成。

外部验证也有局限。如果验证器本身设计错误，或者只检查格式而不检查内容，Agent 仍可能得到“验证通过”的假象。因此，验证标准应尽量贴近任务目标，不能只依赖一个宽泛的评分。

记忆驱动的 Reflexion：让重试有方向

盲目重试的本质是重复相同路径。记忆驱动的反思则要求 Agent 在失败后留下可执行的经验，例如“上一次使用了错误的输入范围”“该工具返回的信息不足以支持结论”“下一次需要先确认某个前置条件”。

这种记忆必须足够短且与当前任务相关。把全部历史操作原样塞回上下文，可能让 Agent 更难识别真正的失败原因，也会增加模型调用开销和任务延迟。相比保存冗长过程，保存失败原因、验证证据和下一步变化通常更有价值。

反思为什么会陷入逻辑死循环

最典型的情况是，Agent 一直查资料、搜索内容或读取文件，却迟迟不进入输出阶段。它把“还可以继续收集信息”误认为“任务还没有完成”，于是每次反思都生成新的查询或工具调用。

另一种情况是评估标准过于严格。反思器不断发现新的瑕疵，但这些瑕疵并不影响任务目标，Agent 仍被要求继续修改。只要系统没有“足够好”的判断，完美主义就会变成无限循环。

还有一种更隐蔽的循环：Agent 每次失败后都生成反思，但下一次没有改变工具、参数、输入或策略。表面上上下文在增长，实际行动轨迹却在重复。此时，反思只是对失败进行重新描述，并没有带来新的信息。

循环还可能来自错误的自我修正。模型把原本正确的内容误判为问题，随后修改出新的错误；接着，它又对新错误进行反思和修正。没有外部证据时，模型可能在多个看似合理的版本之间反复摆动。

把反思机制放进可控的状态机

解决死循环，不能只依靠提示词提醒 Agent“不要重复”。更稳妥的做法，是让系统层的状态机负责判断能不能继续，让模型负责判断下一步怎么做。

首先，要定义可验证的成功标准。完成条件应尽量是明确的状态或结果，而不是“看起来不错”。当条件满足时，反思节点只能输出完成状态；当条件不满足时，必须指出缺失证据或下一步动作。

其次，为循环设置硬性边界，包括最大尝试次数、工具调用上限和资源预算。达到边界后，系统应进入失败、降级或请求人工处理的状态，而不是继续让模型自由生成下一步。对于同一工具和相同参数反复失败的情况，还应记录失败签名，触发提前停止。

再次，需要检测行动是否真正发生变化。如果连续几轮使用相同工具、相同参数，或者产生相同的失败结果，继续反思的收益通常很低。此时可以切换策略、缩小任务范围，或直接返回需要人工确认的状态。

最后，反思输出应尽量结构化。例如，反思节点可以只返回“完成”“继续”或“需要人工处理”中的一种，并附带原因和验证依据。让模型自由决定是否完成，容易出现永远不输出终止信号的问题；有限状态则能把开放式推理约束在可执行的流程内。

可靠性不是反思轮数的简单叠加

Self-Reflection 的作用，更接近一种错误发现和策略调整机制，而不是可靠性的自动证明。多轮对齐可以改善输出审查，Reflexion 可以让失败经验影响后续尝试，外部验证则能为完成判断提供证据。真正稳健的 Agent，通常需要把三者组合起来：模型提出修正方向，外部系统检查结果，状态机决定是否继续。

开发时可以优先观察三个指标：反思后是否改变了行动路径，修正是否带来可验证的改进，以及系统能否在失败时及时停止。若只是增加反思次数，却没有新的证据、不同的策略和明确的退出条件，Agent 可能不会变得更聪明，只会更慢、更贵，并且更擅长解释自己的错误。

对复杂任务而言，最值得保留的不是“会反思”这个标签，而是一个有限、可观测、可验证的修正闭环：失败能够被识别，经验能够被利用，结果能够被外部检查，循环也能够在适当时候结束。