Agent 的 Reflection 反思机制是什么？为什么自查也可能越改越错？

知识点详解：怎样让反思有依据，而不是多说一遍？

先区分“觉得不对”和“有证据证明不对”

假设咱们让 Agent 实现一个分页接口。需求明确要求：请求页码超过最后一页时，返回空列表，不自动跳回第一页。

Agent 第一次写的代码没有处理这个条件。运行测试以后，测试报告指出：请求第 20 页，预期为空，实际返回了第 1 页的数据。

这份报告给了模型三个具体东西：输入是什么、预期是什么、实际哪里不一样。模型就可以检查页码处理逻辑，而不是把整个文件重写一遍。

如果只发送“你再看看有没有问题”，模型并没有得到新事实。它可能注意到遗漏，也可能为了满足“应该有问题”的暗示，挑出一个根本不需要改的地方。

一项关于无外部反馈自我纠错的研究就观察到了这类局限。它研究的是特定模型和任务，不能据此断言所有自查都无效，但足以提醒我们：不能默认多检查一轮必然更准确。

一轮反思应该包含哪些东西？

接着上面的分页任务，我们可以把一次修正安排为：

• 保存当前代码和失败用例，不覆盖唯一版本。
• 把失败输入、预期结果与实际结果交给模型。
• 要求它定位相关逻辑，提出有限范围的修改。
• 在原来的测试规则下重新执行，比较前后结果。

这里最重要的是第三步和第四步不能混在一起。模型负责提出修正，测试负责检查修正。不能让模型一边改答案，一边把判定规则改成“现在这样也算对”。

如果修改后新增了失败用例，就应该退回旧版本或继续分析，不能只看刚才那一条通过了。

Reflection 和 Reflexion，不完全是一个意思

Reflection 常被当作一个宽泛名称，表示检查、批评和修正已有结果。不同系统的实现差别很大。

Reflexion 论文提出了一套更具体的方法：利用任务反馈生成文字反思，把经验保存在 episodic memory 中，再让后续尝试参考这些经验。它不通过这一步直接更新模型权重。

仍然用分页接口举例，一次失败之后可以留下这样的经验：“超过最后一页要返回空列表，不能沿用首页兜底。”下一次尝试再看到这条经验，可能就更容易注意到这个条件。

但是，经验要注明适用范围。如果把它扩大成“所有越界参数都返回空列表”，拿去处理支付金额就不合适了。记录的是某个任务得到的判断，不是自动生成了一条普遍规律。

为什么反思会越改越错？

一种原因是反馈本身错了。需求说越界返回空列表，评审提示却说“应该返回首页”，模型越服从评审，离需求就越远。

另一种原因是修改范围太大。原本只需要改一个条件判断，模型却顺手重构了查询、排序和响应结构，增加了新的错误。

还有一种是只奖励“看起来改进了”。反思文字很长、态度很认真，并不能说明代码行为已经变好。真正要比较的，仍然是原需求下的结果。

因此，建议把“失败事实”“模型解释”“拟修改内容”分开保存。解释可以被质疑，失败事实不能因为模型换了说法就消失。

上线之前怎样验证是否值得加这一轮？

用同一批任务分别运行不反思、纯自查、带外部反馈修正三种流程。

不仅统计最终通过率，还要单独看“原来正确，修改后错误”的比例，以及每次修正增加的耗时和费用。这样的对照才能告诉我们：新增一轮到底帮到了哪里，又损坏了什么。

对于高风险操作，反思不能直接批准执行。模型认为修改正确以后，仍然需要满足原有权限与审批条件。

面试官继续追问

换一个模型做评审，会不会就独立了？

换模型可以增加差异，但不保证评审正确。两个模型可能共享相同的知识缺口，也可能一起误读需求。评审意见最好能指向原文、测试或具体结果，而不是只返回一个分数。

反思多少次合适？

没有固定答案。可以给修正设置次数上限；如果没有新反馈、连续结果没有改善，就停止。已经达到明确验收条件时，也没有必要为了流程完整再修改一遍。

所有失败都值得保存成经验吗？

不值得。网络临时失败不能自动总结成工具永远不可用。经验要带任务范围与来源，过时或未经验证的判断不能长期指导后面的任务。

面试速记卡

• Reflection：根据结果和反馈检查、修正一次尝试。
• 反馈质量：测试报错和真实结果，比“再认真想想”更具体。
• Reflexion：保存文字经验供后续尝试参考，不等于更新权重。
• 验证边界：提出修改的人，不能顺手改掉验收规则。
• 采用依据：检查修正收益，也检查正确答案被改坏的情况。