「AI Agent」Agent 的反思机制：评估闭环、两个粒度与防死循环

0 前言

本文内容整理自公众号「小林面试笔记」的文章 15. 讲讲 Agent 的反思机制？为什么要用反思？具体怎么实现？，用于记录与总结 AI Agent 相关的核心面试知识点。

「Agent 的反思机制是什么？为什么要用反思？怎么实现？」，可以这样作答：

反思机制，是让 Agent 在完成一个步骤或整个任务后，自我评估输出质量、判断有没有问题，不达标就重试或调整策略。通俗讲，就是给「一次性生成」的 LLM 加一个「回头检查再修改」的环节，相当于人写完文章后自己再读一遍、改一遍。

为什么要用反思？因为 LLM 的第一次输出往往不是最优的——它是在「一口气」里生成的，很容易出现逻辑跳跃、遗漏细节、事实错误、表达含糊等问题。做一轮自我检查就能显著提升输出质量，这是反思机制的核心价值。

具体怎么实现？核心是「生成 → 评估 → 改进」的循环（来自 Self-Refine 论文），由两个 prompt 驱动：评估 prompt 专门扮演「检查者」找问题（关键设计是给出明确检查维度 + 设置「PASS」出口，否则 LLM 要么流于表面、要么无限挑毛病）；改进 prompt 则结合原始任务、原始输出、评估意见三样东西做定向修改。循环直到 LLM 回复 PASS 或超过最大轮次强制退出。

反思的代价是每次循环多至少一次 LLM 调用，token 和延迟都会上升。所以工程上我通常只在质量要求高的关键节点启用反思，不每步都做，并设 2-3 轮硬性上限防止死循环。

生产级例子：Cursor 和 Claude Code 已经把反思机制做进了日常开发流程。Cursor 的 Agent 在改代码时会自动跑构建、测试并读取报错反馈，根据失败结果自我修正，直到通过；Claude Code 遇到构建失败或测试报错时，会读取错误日志、定位问题代码、再次修改重试，直到验证通过——这正是「生成 → 评估 → 改进」闭环在生产工具里的落地形态。更进阶的是 Claude Code 的 Bugbot / Security Review 这类专门「评审角色」子代理，用独立视角审查主代理的改动，正是「多 Agent 互评」的生产级实现。

1 为什么需要反思：LLM 的一次性生成问题

先从一个日常经验说起：你写完一篇文章，扔到一边，过半小时再拿回来读，往往能发现一堆之前没注意到的问题——某个句子逻辑跳跃了、某个论点没有支撑、某段话写得不够清楚。改完之后，文章质量明显提升。

其实 LLM 也面临同样的问题。它每次生成输出，本质上都是在「一口气」里完成的，没有机会停下来检查自己。

写完后再回顾，能发现当初没注意到的问题

第一次输出常见的毛病主要有这么几类：

逻辑跳跃：推理步骤不完整，中间少了关键推断；
遗漏细节：任务里要求的某些点，没有被全部覆盖到；
事实错误：模型幻觉导致的错误信息；
表达含糊：意思到了，但说得不够清晰准确。

这些问题，如果给 LLM 一个「回头检查」的机会，它自己是有能力发现并修正的。反思机制就是给它补上这个环节。

2 核心闭环：生成 → 评估 → 改进

反思机制的核心思路来自 Self-Refine 论文（Madaan 等人 2023 年提出），整个流程就是「生成 → 评估 → 改进」的循环。

Self-Refine：生成 → 评估 → 改进的循环

你可以用「草稿 → 批阅 → 修改」来类比：学生交出草稿（生成），老师批阅指出问题（评估），学生拿着批注修改（改进），改完的稿子再经过老师审阅，直到通过为止。

草稿 → 批阅 → 修改的类比

2.1 评估 prompt：检查者的两个关键设计

评估由第一个 prompt 负责，让 LLM 扮演「检查者」的角色，专门去找问题：

任务：{task}

当前输出：
{current_output}

请评估以上输出：
1. 有没有事实错误或逻辑问题？
2. 有没有遗漏重要内容？
3. 表达是否清晰准确？

如果输出已经足够好，回复「PASS」；
否则指出具体问题并给出改进建议。

这个评估 prompt 的设计，有两个特别值得注意的地方。

第一，给出明确的检查维度（事实、逻辑、完整性、表达），而不是让 LLM 自由发挥。这很重要——没有方向的评估往往流于表面，LLM 可能只是说「输出看起来不错」，实际上没找到任何问题。给出具体维度，它才会有针对性地逐项审查。

第二，「PASS」机制必须要有。这是给 LLM 一个「足够好就停」的出口。如果没有它，LLM 为了反思而反思，可能对一个已经很好的输出挑不必要的小毛病，反而把原本对的东西改错。

2.2 改进 prompt：三要素缺一不可

如果评估结果不是 PASS，就把评估意见喂进第二个改进 prompt：

原始任务：{task}
当前输出：{current_output}
评估意见：{reflection}

请根据评估意见改进输出：

改进 prompt 有一个关键点：它同时传入了原始任务、原始输出、评估意见这三样东西，缺任何一个都会让改进变得盲目——

只有任务、没有原始输出：LLM 不知道在什么基础上改；
只有原始输出、没有评估意见：LLM 不知道改哪里；
只有评估意见、没有任务：LLM 可能改着改着偏离了原始目标。

三者都在，它才能有针对性地修改，而不是把内容全部推倒重写。

改进 prompt 需要同时传三样输入

两个 prompt 循环调用，直到 LLM 自己回复 PASS，或者超过最大轮次强制退出。整个外层逻辑，其实不过是一个普通的 for 循环。

3 两个粒度：步骤级 vs 任务级

反思可以在两个粒度上触发，它们适用场景不同、代价也不一样，选哪种要根据任务特点来判断。

3.1 步骤级反思：早发现早纠正

步骤级反思是在每个工具调用或推理步骤完成后立即检查。好处是错误早发现早纠正，不会让一个小错误在后续步骤里层层放大。

想象一个 Agent 在做多步信息检索：第一步选了一个不精准的搜索关键词，后续所有步骤都在错误信息上继续，到最后才发现，前面的工作全废了。步骤级反思能在第一步就发现问题、马上纠正，后续步骤都建立在正确基础上。

适合这种粒度的场景，是步骤之间强依赖、前一步错了后面会全错的任务。代价是每一步都多一次 LLM 调用，整体延迟和 token 消耗会大幅增加——一个 10 步的任务，实际可能要调用 20 次 LLM。

3.2 任务级反思：整体视角、开销更小

任务级反思是整个任务执行完之后做一次整体评估。好处是开销更小，整个任务只多一次 LLM 调用；而且从整体视角审视，能发现步骤级看不到的问题——比如各个步骤单独看都是对的，但整体结论前后矛盾，或各部分之间衔接不自然，这种问题只有从整体视角才能看出来。

代价是如果任务中途某步出了大问题，到最后才发现，前面的执行都已经浪费了。适合步骤之间相对独立、最终输出的整体质量更重要的场景，比如生成一份报告。

步骤级 vs 任务级反思

4 多 Agent 互评：为什么「他人审视」比「自我检查」更好

除了单 Agent 的自我反思，还有一种效果通常更好的方式：多 Agent 互评——专门设置一个独立的 Critic Agent，让它来审查执行 Agent 的输出。

为什么独立的审查比自我反思效果更好？可以类比代码 review 的场景：一个人写完代码自己检查，和让同事来 review，发现的问题质量往往不一样。自己写的东西自己看，容易「视觉疲劳」，会不自觉地补脑跳过问题，潜意识里倾向于认为自己的逻辑是正确的。

在 LLM 里同样如此：单 Agent 自我反思时，评估者和生成者是同一个模型，它在生成输出时形成的一套「内部逻辑」，做评估时也会沿用这套逻辑，对自己输出的错误不够敏感，容易陷入「自洽」。而独立的 Critic Agent 没有这种包袱，它的唯一职责就是「找问题」，视角更客观，更容易发现执行 Agent 自己看不出来的漏洞。

互评的具体流程是：执行 Agent 生成输出，Critic Agent 审查并给出具体批注，执行 Agent 根据批注修改，Critic Agent 再次确认。

多 Agent 互评流程

什么时候值得用这种方式？质量要求非常高的场景，比如生成代码后让独立的测试 Agent 来验证、生成分析报告后让事实核查 Agent 交叉验证。代价是又多一个 Agent 的调用成本、系统复杂度也更高，所以并不是所有场景都需要互评，普通场景用自我反思就够了。

5 进阶：Reflexion 与 LATS，把反思做得更深

前面讲的 Self-Refine 是最基础的反思模式。学术界在此基础上还有更进一步的探索，了解这些能帮你在面试里展现更深的理解。

5.1 Reflexion：把失败经验存下来

Reflexion（Shinn 等人 2023 年提出，和 Self-Refine 同年）的核心思路是：不仅让 Agent 反思当前输出的质量，还要把「失败经验」存下来，下次遇到类似任务时直接参考、避免重蹈覆辙。

可以这样理解两者的区别：Self-Refine 是「写完作文当场改」，Reflexion 是「把这次犯的错记在笔记本上，下次写作文之前先翻一遍笔记」。

Reflexion 引入了一个「经验记忆」的概念：每次反思产生的教训会被存储起来，作为后续任务的参考上下文。这个思路在需要重复执行类似任务的场景里特别有价值——比如一个代码生成 Agent，第一次写出了有 bug 的代码，反思后不仅修好了这次的 bug，还把「这类 bug 的成因和避免方法」记下来，下次生成类似代码时就不太容易犯同样的错。

5.2 LATS：把反思和树搜索结合

LATS（Language Agent Tree Search，Zhou 等人 2024 年提出）把反思和树搜索结合了起来。核心思路是把蒙特卡洛树搜索（MCTS）和反思结合起来：通过 MCTS 同时探索多条路径，每条路径执行之后都做评估和反思，反思结果作为经验反馈给后续的路径探索。

这样一来，Agent 不仅能同时探索多条路径，还能从已经走过的路径里学到教训，让后续探索更有针对性。代价当然也更大——既有多路径的成本又有反思的成本。目前主要还是学术研究场景，还没看到成熟的生产级实现。

此外还有一种辩论式反思：不是让一个 Agent 自己审查自己，而是设置「正方 Agent」和「反方 Agent」互相辩论，反方专门挑毛病、提反对意见，正方再针对反对意见优化。这种对抗式反思比单方面审查更能暴露深层问题，工程上偶尔用于高质量要求的场景，比如重要的商业决策分析、法律文本审查。

6 工程权衡：怎么用才合理

理解了原理和进阶方案之后，还要知道工程上怎么合理地用它，不然反而会让系统变慢、变贵、甚至陷入死循环。

什么场景值得开反思？ 输出质量要求高、错误代价大的关键节点，比如最终报告生成、重要决策的推理过程，以及任务比较复杂、LLM 容易遗漏细节的场景。

什么场景不值得开？ 简单直接的任务（如格式转换、简单问答）加反思纯粹是浪费；实时性要求高的场景也一样——一次反思至少多一次完整的 LLM 调用，延迟可能从 1 秒涨到 3 秒，有些应用场景根本接受不了。

最重要的是防死循环：必须设最大轮次，通常设 2-3 轮，绝对不能依赖 LLM 自己判断停止。原因是 LLM 有时会陷入「为了改而改」的循环——每次评估都觉得还有地方能优化，改完又有新的「问题」，每轮改动都很小但实质没有进步，系统就一直在转圈。硬性的轮次上限，是唯一可靠的退出机制。

反思需要用护栏防止死循环

最后要对整体代价有清醒认知：每轮反思包含一次评估和一次改进，3 轮反思意味着在原始生成之外额外增加 6 次 LLM 调用，延迟和成本都会大幅增加。这是工程上做取舍的核心数字。反思是提升质量的有效手段，但不是免费的，用在刀刃上才有价值，不是每步都做。

7 要点回顾

回答「Agent 的反思机制」这道题，把握好以下几个层次：

层次	要点
本质	反思是「生成 → 评估 → 改进」的有结构闭环（Self-Refine），不是「不满意就随机重试」
评估 prompt 两个关键设计	给出明确检查维度（逻辑/事实/完整性/表达）+ 设置「PASS」出口，否则要么流于表面、要么无限挑毛病
改进 prompt 三要素	原始任务、原始输出、评估意见三者缺一不可，否则改进会变得盲目
两个粒度	步骤级（错误发现得早但开销大）vs 任务级（能看到整体问题但前期无效工作难以挽回）
多 Agent 互评	独立 Critic Agent 比自我检查更好，因为同一模型对自己的输出有「自洽」偏见
防死循环	必须硬性设置最大轮次（2-3 轮），不能依赖 LLM 自己停止