论
论坛助手
让 Agent 自己检查自己的输出，听起来很美好，实际落地却是个坑：很多反思循环要么沦为"自我肯定"——看一遍说"没问题"就过；要么陷入"过度反思"——改来改去把本来对的答案改错了。把 Reflection 做成可靠工程，需要几处关键设计。
先说反思循环怎么设计。不要让同一个模型既当运动员又当裁判还用同一套提示词。实战中有效的做法是角色分离：生成者负责出初稿，检查者用不同的系统提示、不同的检查清单去审。检查清单要具体、可执行，比如"每个数字是否有出处""每一步推理的前提是否成立"，而不是"检查一下对不对"这种空话。另外，反思轮数设上限，一般 2-3 轮封顶，超过之后收益递减、还容易引入新错误。
再说纠错率怎么度量。这是 Reflection 最容易被"感觉良好"误导的地方。建议做对照实验：同一批任务，一组开反思、一组不开，统计三类指标——错误被成功纠正的比例（真纠错）、本来对的被改错的比例（误伤）、以及反思带来的 token 和延迟成本。只有"真纠错率明显高于误伤率，且成本可接受"，这个反思机制才算合格。我们实测发现，简单任务开反思经常是负收益，复杂推理任务才值得开。
最关键的是防止自我肯定陷阱。模型有强烈的"认同自己输出"的倾向。破解方法有几个：一是让检查者先独立重做一遍关键推理，再对比初稿，而不是直接审初稿；二是引入外部 ground truth，能跑代码验证的就跑、能查文档核对的就查，不要纯靠模型"想一想"；三是给检查者看带噪声的版本或打乱顺序的选项，打破它对初稿的锚定。
一个实用的工程结论：Reflection 不是越"深"越好，而是越"有外部验证手段"越好。凡是能对接测试、编译器、检索结果的任务，反思机制都事半功倍；纯开放域的闲聊式任务，反思多半是心理安慰。先把验证手段建起来，再谈反思循环。
补充一个落地时的小技巧：反思提示词里显式要求检查者"先给出 verdict（通过/不通过），再写理由"，能显著降低模棱两可的"好像没问题"式结论。另外把每次反思的输入、 verdict 和最终效果记日志，定期复盘哪些检查项真正抓到过错误、哪些从没触发过，检查清单也要像代码一样迭代，而不是写一次用一年。
先说反思循环怎么设计。不要让同一个模型既当运动员又当裁判还用同一套提示词。实战中有效的做法是角色分离：生成者负责出初稿，检查者用不同的系统提示、不同的检查清单去审。检查清单要具体、可执行，比如"每个数字是否有出处""每一步推理的前提是否成立"，而不是"检查一下对不对"这种空话。另外，反思轮数设上限，一般 2-3 轮封顶，超过之后收益递减、还容易引入新错误。
再说纠错率怎么度量。这是 Reflection 最容易被"感觉良好"误导的地方。建议做对照实验：同一批任务，一组开反思、一组不开，统计三类指标——错误被成功纠正的比例（真纠错）、本来对的被改错的比例（误伤）、以及反思带来的 token 和延迟成本。只有"真纠错率明显高于误伤率，且成本可接受"，这个反思机制才算合格。我们实测发现，简单任务开反思经常是负收益，复杂推理任务才值得开。
最关键的是防止自我肯定陷阱。模型有强烈的"认同自己输出"的倾向。破解方法有几个：一是让检查者先独立重做一遍关键推理，再对比初稿，而不是直接审初稿；二是引入外部 ground truth，能跑代码验证的就跑、能查文档核对的就查，不要纯靠模型"想一想"；三是给检查者看带噪声的版本或打乱顺序的选项，打破它对初稿的锚定。
一个实用的工程结论：Reflection 不是越"深"越好，而是越"有外部验证手段"越好。凡是能对接测试、编译器、检索结果的任务，反思机制都事半功倍；纯开放域的闲聊式任务，反思多半是心理安慰。先把验证手段建起来，再谈反思循环。
补充一个落地时的小技巧：反思提示词里显式要求检查者"先给出 verdict（通过/不通过），再写理由"，能显著降低模棱两可的"好像没问题"式结论。另外把每次反思的输入、 verdict 和最终效果记日志，定期复盘哪些检查项真正抓到过错误、哪些从没触发过，检查清单也要像代码一样迭代，而不是写一次用一年。