第 11 章：Reflection 模式——让 Agent 学会“照镜子”

芋圆ai
0 阅读6分钟

第11章：Reflection 模式：让 Agent 学会“照镜子”

Reflection（反思）不是为了让 Agent 变得完美，而是为了提高“及格线”。它把“听天由命”的单次生成，变成了“自我纠错”的闭环系统。

0001页.png

想象一下，你让 Agent 写一段 Python 代码。 第一次运行，它报错了。 Agent 对此一无所知，直接把这段报错的代码扔给了用户。 用户一跑，炸了。

这就是没有 Reflection 的后果。

LLM（大模型）在本质上是一个概率模型。它就像一个醉酒的作家，有时候下笔如有神，有时候胡言乱语。如果你每次都直接采纳它的第一稿，那你就是在赌博。 0002页.png

Reflection 模式的核心思想很简单： 在把结果交给用户之前，先让 Agent 自己看一眼（照镜子），问自己一句：“我写的对吗？”如果不对，自己改好再发出去。

本章我们来聊聊这个能让 Agent “智商暴涨”的模式。

01. 系统 1 与系统 2：快思考与慢思考

在认知心理学神作《思考，快与慢》中，丹尼尔·卡尼曼提出了两个系统：

  • 系统 1（快思考） ：直觉、本能、反应快但容易出错。
  • 系统 2（慢思考） ：逻辑、推理、反应慢但准确。

普通的 LLM 生成（Direct Generation）就是 系统 1。它根据概率快速吐字，不假思索。 Reflection 模式则是强制 LLM 进入 系统 2。它强迫模型停下来，审视自己的输出，进行逻辑校验。

比喻： 没有 Reflection 的 Agent 就像 口无遮拦的醉汉，想到什么说什么。 有 Reflection 的 Agent 就像 谨慎的发言人，打好草稿，反复推敲，确认无误后再发布。

02. Reflection 的核心三部曲

Reflection 不是玄学，它在工程上通常由三个明确的步骤组成，我们可以用 “作家与编辑” 的关系来比喻：

第一步：初稿生成（Writer）

Agent 像往常一样，根据用户的 Prompt 生成一个 初稿（Draft） 。

  • 状态：可能包含错误、幻觉或逻辑漏洞。

第二步：质量评估（Editor）

这是一个专门的“评估者角色”（可以是同一个 LLM，也可以是更强的 LLM）。它不负责写，只负责挑刺。 它会拿着放大镜检查初稿：

  • 代码能运行吗？（调用解释器验证）
  • 格式是 JSON 吗？（正则验证）
  • 有没有回答用户的核心问题？（语义评分）

如果发现问题，它会写下一段 反馈意见（Feedback） ：“第 3 行代码引用了不存在的库；JSON 缺少 user_id 字段。”

第三步：带反馈重写（Reviser）

Agent 拿到初稿和编辑的反馈意见，重新生成 终稿（Final Version） 。 这一次，它有了明确的修改方向，质量通常会大幅提升。

03. 架构设计：闭环与护栏

在 Shannon 框架中，Reflection 是一个标准的 While 循环。

# 伪代码：Reflection 主循环
def generate_with_reflection(query):
    # 1. 写初稿
    draft = llm.generate(query)
    retry_count = 0
    
    while retry_count < MAX_RETRIES:
        # 2. 评估（照镜子）
        score, feedback = evaluator.assess(draft)
        
        # 3. 达标判断
        if score > PASS_THRESHOLD:
            return draft  # 质量过关，直接返回
            
        # 4. 根据反馈重写
        prompt = f"""
        你的上一次回答有问题。
        问题：{query}
        你的回答：{draft}
        反馈意见：{feedback}
        请根据反馈修正回答。
        """
        draft = llm.generate(prompt)
        retry_count += 1
        
    # 5. 兜底：如果重试多次还不行，返回最后一次的结果（或报错）
    return draft

关键组件

  1. Evaluator（评估器） ：这是最核心的组件。

    • 基于规则：比如代码必须通过单元测试，JSON 必须能 Parse。这是最硬的指标。
    • 基于模型：让 LLM 自己打分（0-10 分）。提示词：“作为一个严厉的教授，请给这篇论文打分，并指出逻辑谬误。”

  2. Controller（控制器） ：防止死循环。

    • 必须设置 MAX_RETRIES（通常是 1-3 次）。否则遇到修不好的 Bug，Agent 会把你的 Token 烧光。

0004页.png

04. 经济学账本：质量与成本的博弈

Reflection 听起来很美，为什么不给所有 Agent 都装上？ 因为 贵。

引入 Reflection 后，原本 1 次的 API 调用，变成了 1（初稿）+ N（评估）+ N（重写） 次。

  • Token 消耗：可能翻倍甚至三倍。
  • 延迟（Latency） ：用户等待时间显著增加。

什么时候该用 Reflection？

场景建议原因
代码生成必须用代码错一个标点就跑不通，必须自我纠错。
复杂逻辑推理推荐用数学题、侦探推理，容易一步错步步错。
创意写作慎用创意没有标准答案，“纠错”可能会扼杀灵感。
简单闲聊禁用“你好”不需要反思，秒回最重要。

升维思考： 这本质上是 质量成本（Cost of Quality） 的权衡。对于高价值输出（如生产环境代码、医疗建议），多花几倍的 Token 换取准确性是值得的；对于低价值输出（如闲聊），则是浪费。

05. 常见的坑（Pitfalls）

坑 1：盲目自信的评估器

如果你让 GPT-3.5 去评估 GPT-4 的回答，它往往看不出问题，甚至会觉得“写得真好”。 原则：评估者的能力必须 大于等于 生成者。或者使用确定性工具（编译器、数据库）作为评估标准。

坑 2：模糊的反馈

评估器给出的反馈如果是：“这写得不好，重写。” —— 这种反馈毫无价值。 原则：反馈必须 具体（Actionable） 。比如：“第 2 段逻辑与第 1 段矛盾”、“缺少具体的案例支撑”。

坑 3：死循环陷阱

有时候 Agent 会陷入怪圈：A 改成了 B，评估说 B 不对；B 改回了 A，评估说 A 不对。 原则：在 Prompt 中加入 Temperature（随机性） 的微调，或者在重试时强制切换思路。

06. Reflection vs 其他优化手段

Reflection 经常被拿来和 Self-Consistency（自洽性） 做比较。

  • Reflection（反思） ：串行。写完 -> 改 -> 再改。适合 修正错误。
  • Self-Consistency（自洽） ：并行。同时写 5 个版本 -> 投票选最好的。适合 开放性探索。

Human Review（人工审核） 则是 Reflection 的终极形态——由人来充当 Evaluator。这是最贵但最准的。!

0011页.png

总结

Reflection 模式是 Agent 从“鹦鹉学舌”迈向“独立思考”的关键一步。

它教会了 Agent 审视自我。 虽然它会增加成本和延迟，但在追求高可靠性的场景下，它是不可或缺的质量守门员。

记住：我们不要求 Agent 一次就对，但我们要求它在交卷前，至少自己检查一遍。

下一章预告

Agent 学会了反思，质量有了保障。但面对那些需要几十步推理的超级难题，光靠反思还不够。它需要学会把思维过程“显性化”。 下一章，我们来聊 Chain-of-Thought (CoT，思维链) ：如何让 Agent 像数学家一样，把推理过程一步步写在纸上，从而解开最难的谜题。 0014页.png

avatar
文章
阅读
粉丝