不吃辣的Chris · AI 实践指南

Appearance

61. 反射模式（Reflection Pattern） ​

难度 P1 高频 · 岗位 应用 · 频率 ★★★★☆ · 预计阅读 8 min 公司 OpenAI · Anthropic · Google 相关题 Q62 工具使用模式 · Q63 ReAct 模式 · Q64 规划模式

本题阅读地图 ​

  1. 面试场景还原 — 1 min
  2. TL;DR 速记 — 30 sec
  3. 图解 — 30 sec
  4. 详细解析 — 5 min
  5. 常见踩坑与反例 — 1 min
  6. 面试官可能继续追问 — 1 min

面试场景还原 ​

�面试官：Agent 输出质量不稳定，有时候好有时候差，你有什么优化思路？

🙋‍♂️我：可以优化 Prompt，让模型更仔细地思考。

👔面试官：Prompt 优化有上限。如果一次生成的结果本身就有问题，再怎么优化 Prompt 也难保证质量。有没有办法让 Agent 自己检查自己的错误？

🙋‍♂️我：呃……可以让它再检查一遍？

👔面试官：对，这叫「反射模式」。但具体怎么实现？怎么防止它无限循环检查？怎么确保自检是客观的，不是「自我欺骗」？

🙋‍♂️我：这个……

👔面试官：反射模式 是 Agent 设计的核心模式之一。关键点在于：1）构建生成-自检-修正的闭环；2）用外部验证器代替模型自检会更客观；3）必须设置终止条件防止死循环。

TL;DR 速记 ​

  • 是什么：Agent 完成输出后回头自检、发现问题再迭代的增强回路
  • 核心价值：突破单次推理上限，通过「写 → 检 → 改」循环提升输出质量
  • 关键机制：生成-自检-修正循环，可用模型自检或外部验证器
  • 边界控制：必须设置最大迭代次数和终止条件
  • 典型应用：代码生成自修复、文案合规检查、数学问题验证

图解 ​

图 1：反射模式工作流程 ​

图 2：反射模式 vs 单次生成 ​

详细解析 ​

为什么需要反射模式？单次推理的局限 ​

大模型单次生成的输出存在三个固有局限：

局限 1：幻觉问题。模型有时会自信地输出错误信息，如果用户不指出，模型自己不会意识到。就像一个人写文章时没意识到自己写错了，需要回头再看才能发现。

局限 2：复杂任务容易遗漏。一次生成的过程中，模型可能遗漏某些约束条件或边界情况。特别是当任务有多个要求时，一次性输出很难保证每个要求都被满足。

局限 3：没有自我修正机会。人类写作时会反复修改润色，但传统 LLM 调用是「一问一答」模式，没有「写完后检查再改」的机会。

反射模式本质上就是给模型一个「回头看」的机会，让它能像人类一样迭代优化自己的工作。

反射模式的核心机制：生成-自检-修正循环 ​

反射模式的运作遵循一个标准的三步循环：

第一步：生成（Generate） Agent 根据输入任务产生初始输出。这一步和普通 LLM 调用没有区别，输出质量受限于单次推理能力。

第二步：自检（Reflect） Agent 回头审查刚才的输出，检查是否存在问题。自检可以是：

  • 模型自己检查（「请检查刚才的回答是否有错误」）
  • 外部验证器检查（单元测试、语法检查器、规则引擎）

第三步：修正（Revise） 如果自检发现问题，Agent 根据反馈进行修正，产生新的版本。然后回到第二步再次自检，形成循环。

输入 → 生成初稿 → 自检发现问题 → 修正 → 再次自检通过 → 输出
         ↑___________________________|

这个循环持续进行，直到自检通过（没有发现问题）或达到最大迭代次数。

自检的三种实现方式 ​

根据自检主体的不同，有三种实现方案：

方案 1：模型自检（Self-Reflection） 让同一个模型扮演「审查者」角色，检查刚才的输出。

优点：

  • 实现简单，无需额外系统
  • 能发现逻辑错误、遗漏约束

缺点：

  • 可能「自我欺骗」，对错误视而不见
  • 自检和生成用同一模型，存在盲区

Prompt 示例：

你刚才生成了以下回答：[插入输出]

请检查这个回答是否存在以下问题：
1. 事实性错误
2. 遗漏了用户要求的约束条件
3. 逻辑不一致

如果发现问题，请指出并说明如何修正。

方案 2：外部验证器（External Validator） 用专门的工具或规则来验证输出，而不是依赖模型自检。

典型验证器：

  • 单元测试：代码生成场景，运行测试验证代码正确性
  • 语法检查器：验证 JSON/XML 格式是否正确
  • 规则引擎：验证输出是否符合业务规则
  • 事实检索：验证输出中的事实是否准确

优点：

  • 客观、无偏见的验证
  • 可以验证模型难以自检的问题

缺点：

  • 需要额外开发验证器
  • 不适用于所有类型任务

方案 3：多模型交叉验证（Cross-Reflection） 用另一个独立的模型实例来审查第一个模型的输出，避免「自我欺骗」。

优点：

  • 旁观者清，更容易发现问题
  • 减少单一模型的偏见

缺点：

  • 成本翻倍（两次模型调用）
  • 延迟增加

典型应用场景与案例 ​

场景 1：代码生成自修复 这是反射模式最成功的应用之一。GitHub Copilot、Cursor 等工具都内置了类似机制。

流程：

  1. 用户要求：「写一个 Python 函数，计算列表的平均值」
  2. Agent 生成初版代码
  3. 自动运行单元测试验证代码
  4. 测试失败（如没有处理空列表）→ 分析错误原因 → 修正代码
  5. 再次运行测试 → 通过 → 输出最终代码

场景 2：文案合规检查 法律文书、医疗建议等对准确性要求高的场景。

流程：

  1. 生成初稿文案
  2. 用规则引擎检查是否包含禁用词汇
  3. 用模型自检检查逻辑是否严谨
  4. 发现问题 → 修正 → 再次检查
  5. 合规后输出

场景 3：数学问题求解 数学问题的多步推导容易出错，反射模式可以逐步验证。

流程：

  1. 生成解题步骤
  2. 每一步用计算工具验证结果
  3. 发现计算错误 → 定位出错步骤 → 重新计算
  4. 所有步骤验证通过 → 输出最终答案

实现中的关键参数与边界控制 ​

反射模式必须设置以下边界条件，否则会陷入无限循环：

最大迭代次数（Max Iterations）

  • 设置上限，如最多迭代 3-5 次
  • 超过上限后，即使未通过自检也要输出（可附带警告）

终止条件（Stop Condition）

  • 自检通过（没有发现问题）
  • 达到最大迭代次数
  • 输出质量不再提升（连续两次迭代结果相同）

自检 Prompt 设计原则

  • 与生成 Prompt 分开，避免角色混淆
  • 明确列出检查清单（Checklist）
  • 要求结构化输出（问题列表 + 修正建议）

代码示例（伪代码）：

python
max_iterations = 3
output = generate(initial_prompt)

for i in range(max_iterations):
    # 自检
    reflection = reflect(output, reflection_prompt)

    if reflection.has_issues:
        # 修正
        output = revise(output, reflection.feedback)
    else:
        # 通过检查，提前终止
        break

return output

常见踩坑与反例 ​

踩坑 1：自检和生成用同一个 Prompt ​

错误做法：

请生成代码，并检查是否正确。

问题：生成和自检混在一起，模型容易「自我欺骗」，明明有错也说没错。

正确做法： 分开两个独立步骤，先用生成 Prompt，再用专门的自检 Prompt 审查。

踩坑 2：没有设置最大迭代次数 ​

错误做法： 循环条件只有「自检通过才停止」，没有最大次数限制。

问题：某些情况下模型会陷入循环，不断发现问题→修正→又发现新问题，永不终止。

正确做法： 必须设置 max_iterations，超过后强制终止并输出。

踩坑 3：过度依赖模型自检 ​

错误做法： 完全依赖模型自己来检查错误，没有外部验证。

问题：模型对自己生成的内容有确认偏见（Confirmation Bias），容易漏检。

正确做法： 能用外部验证器的场景尽量用外部验证器（如代码用单元测试、事实用检索验证）。

踩坑 4：反馈信息不足导致修正无效 ​

错误做法： 自检只告诉模型「有错」，但不说明具体错在哪里。

问题：模型不知道具体问题，修正方向可能错误。

正确做法： 自检输出要包含：1）具体问题描述；2）错误位置；3）修正建议。

面试官可能继续追问 ​

  • 追问 1：反射模式和 ReAct 模式有什么关系？ 答题要点：反射模式是 ReAct 的一个子集。ReAct 包含「思考-行动-观察」循环，反射模式可以看作是其中的「自我观察」环节。ReAct 更宏观（与外部工具交互），反射模式更聚焦（内部质量优化）。

  • 追问 2：反射模式的成本怎么控制？ 答题要点：1）设置合理的最大迭代次数；2）用轻量级模型做自检，强模型做生成；3）对简单任务跳过反射；4）缓存常见错误的修正模式。

  • 追问 3：怎么判断一个任务是否需要反射模式？ 答题要点：需要反射的场景：1）输出质量要求高（法律、医疗）；2）有可验证的正确性标准（代码、数学）；3）复杂多约束任务。不需要的场景：1）创意生成；2）开放式对话；3）成本敏感的简单任务。

  • 追问 4：反射模式和多智能体协作有什么区别？ 答题要点：反射模式通常是一个 Agent 内部循环；多智能体是多个 Agent 之间协作。反射模式是自检，多智能体是「他检」（其他 Agent 来审查）。两者可以结合：生成 Agent → 审查 Agent（反射）→ 修正 Agent。

面试总结 ​

反射模式是提升 Agent 输出质量的核心设计模式。面试时强调三点：

  1. 核心机制：生成-自检-修正的闭环，突破单次推理上限
  2. 实现要点：自检方式选择（模型自检/外部验证器）、最大迭代次数限制
  3. 应用场景：代码自修复、合规检查、数学验证等需要高质量输出的场景

记住：反射不是无限循环，必须有明确的终止条件和客观的验证标准。能用外部验证器的场景，不要完全依赖模型自检。

章节首页 · ← Q60 · Q62 →

最后更新2026-05-05
难度P1
频率high
阅读8 min
主题agent / reflection / self-correction
觉得有帮助？把这个链接转给正在求职的朋友 · 用 Ctrl + K 全站搜索其它题