面试官问：“Agent 的反思机制怎么实现？”很多人第一反应是：让模型不满意就重新生成一次。

这个回答只说对了一点点。真正的 Reflection 不是随机重试，而是一个有标准、有反馈、有修改、有停止条件的闭环。它像人写完文章后自己检查，也像代码写完后做 Review：先找问题，再带着问题改，而不是盲目重写。

一、反思不是“再生成一次”

随机重试只是再赌一次运气。反思机制则会先生成一版结果，再用明确标准评估它，然后把评估意见传给下一轮改进。两者最大的差别是：下一轮有没有“带着问题去修”。

第一次输出常见的问题有四类：逻辑跳跃、遗漏要求、事实错误、表达含糊。模型并不是完全不能发现这些问题，而是第一次生成时通常一口气往前写，没有停下来做质量检查。反思机制就是给它加上“回头检查”的环节。

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

最基础的反思模式可以拆成三步：Generator 先产出初稿，Evaluator 按规则检查质量，Refiner 根据批注定向修改。循环一直持续到评估结果为 PASS，或者达到最大轮次。

Self-Refine 论文把这种方式总结为 FEEDBACK 和 REFINE 的迭代过程：先让模型对自己的输出生成反馈，再把反馈用于改进输出。它不需要额外训练，也不需要微调，本质是在推理阶段用更多计算换更高质量。

三、两个 Prompt：评估和改进要分工

反思能不能有效，关键看 Prompt 怎么设计。最常见的错误是只写一句“请检查有没有问题”。这种指令太宽泛，模型很容易给出一句“整体看起来不错”，然后什么也没改。

评估 Prompt 必须给出明确检查维度，比如事实准确性、逻辑完整性、任务覆盖度、表达清晰度；同时必须提供 PASS 机制，让模型在输出已经足够好时可以停止。

EVALUATE_PROMPT = """
任务：{task}
当前输出：{answer}

请按以下维度评估：
1. 是否存在事实错误？
2. 逻辑是否完整，有没有跳步？
3. 是否遗漏用户要求？
4. 表达是否清晰、准确、可执行？

如果已经足够好，只输出：PASS
否则输出：问题清单 + 修改建议。
"""

REFINE_PROMPT = """
原始任务：{task}
当前输出：{answer}
评估意见：{feedback}

请只根据评估意见定向改进，不要偏离原始任务。
"""

改进 Prompt 一定要同时传入三样东西：原始任务、当前输出、评估意见。只有任务没有原文，模型不知道从哪里改；只有原文没有批注，模型不知道改哪里；只有批注没有任务，模型容易修着修着偏题。

四、PASS 和最大轮次：反思必须有刹车

反思最怕两种情况：第一，模型一直觉得自己有问题，陷入“为了改而改”；第二，模型每轮都做轻微改动，但质量没有明显提升。生产环境不能把停止权完全交给模型，必须有硬性轮次上限。

def reflect(task, generator, evaluator, refiner, max_rounds=2):
answer = generator(task)

for round_id in range(max_rounds):
feedback = evaluator(task, answer)

if feedback.strip().upper() == "PASS":
return answer

answer = refiner(task, answer, feedback)

return answer

经验上，普通内容生成最多 1 轮，重要报告或代码生成最多 2 轮，极少数高价值任务才开 3 轮。超过 3 轮通常说明评估标准不清楚，或者任务本身需要拆解，而不是继续反思。

五、反思粒度：步骤级还是任务级？

反思可以放在每一步后面，也可以放在最终输出之后。步骤级反思能早发现错误，但每一步都多一次调用；任务级反思成本低，但如果中间某一步已经错了，最后才发现会浪费前面的执行。

如果任务是多步检索、SQL 生成、代码执行、自动化操作，前一步错误会影响后一步，就更适合步骤级反思。如果任务是文章、报告、总结、方案输出，整体一致性更重要，就更适合任务级反思。

六、单 Agent 自查，不如 Critic Agent 互评

单 Agent 自我反思有一个天然问题：生成者和评估者是同一个模型，它可能沿用自己刚才的逻辑，对自己的错误不敏感。这有点像自己写代码自己 Review，很容易“脑补”正确。

更稳的做法是设置独立的 Critic Agent。Executor 负责生成，Critic 只负责找问题，Refiner 再根据 Critic 的意见修改。它更适合代码生成、事实核查、金融分析、法律文本、合同审查这类错误代价高的任务。

class ReflectionState(TypedDict):
task: str
draft: str
feedback: str
round: int


def should_continue(state: ReflectionState) -> str:
if state["feedback"].strip().upper() == "PASS":
return "finish"
if state["round"] >= 2:
return "finish"
return "revise"

七、Reflexion：把失败经验存下来

Self-Refine 主要解决“这一次输出怎么改好”。Reflexion 更进一步：它会把失败经验总结成文字记忆，下次遇到类似任务时放进上下文，避免重复犯错。

比如代码 Agent 第一次写出 bug，测试失败后反思出原因：“没有处理空数组和越界输入”。这条经验会进入 memory buffer。下次生成类似函数时，Agent 会先看到这条经验，从而主动补上边界测试。

这里要注意：Reflexion 不是更新模型参数，而是用文字经验影响后续推理。它更像“错题本”，不是重新训练大脑。

八、LATS：反思 + 树搜索

如果任务非常复杂，只沿着一条路径反思还不够。LATS 把反思和树搜索结合起来，同时探索多条路径，每条路径执行后都做价值评估和反思，失败路径的经验会反馈给后续搜索。

LATS 适合研究型或高价值任务，例如复杂代码修复、长链路决策、网页导航、数学推理。它的效果可能更强，但成本也更高：既要多路径探索，又要多轮评估和反思，不适合普通线上请求默认启用。

九、工程权衡：质量提升，不是免费的

反思每增加一轮，通常至少多两次调用：一次评估，一次改进。如果原始生成是 1 次调用，那么 2 轮反思就是 1 + 2 × 2 = 5 次调用。延迟、费用、上下文长度都会上升。

所以反思不能全局默认打开，而应该按场景启用：简单格式转换不需要，关键报告可以任务级反思，代码生成可以配合测试 Agent，复杂工具链可以在关键步骤做步骤级反思。

十、生产落地：把反思做成质量链路

真正的线上系统不会只写两个 Prompt 就上线。生产级 Reflection 至少要包含调度器、执行器、评审器、修改器、日志追踪、记忆存储和护栏规则。

Orchestrator 负责轮次控制和状态流转；Executor 负责生成；Critic 负责评估；Refiner 负责定向修改；Trace 记录每轮输入输出，方便排查问题；Memory 保存可复用经验；Guardrails 处理敏感内容、权限边界和事实核验。

十一、面试回答可以这样说

Agent 的反思机制是让模型在完成一步或整个任务后，对结果进行结构化评估，如果不达标，就根据评估意见定向修改。它的核心不是随机重试，而是“生成、评估、改进”的闭环。

实现上通常需要两个 Prompt：评估 Prompt 给出检查维度和 PASS 机制；改进 Prompt 同时传入原始任务、当前输出和评估意见。工程上必须设置最大轮次，通常 2-3 轮，防止模型无限挑毛病。

反思可以分为步骤级和任务级。步骤级适合强依赖任务，错误能早发现；任务级适合报告和文章这类整体质量更重要的任务。质量要求更高时，可以引入独立 Critic Agent 做互评；需要跨任务复用经验时，可以用 Reflexion 把失败经验写入记忆。

反思能提升质量，但会显著增加 token、延迟和系统复杂度，所以不要每一步都做，而要用在高价值、高风险、复杂任务的关键节点。