第4章：反思（Reflection）

来源：《智能体设计模式：智能系统构建实战指南》
学习日期：2026-04-01

---

一、核心概念：什么是反思？

一句话：让 AI 在输出结果后，自己当自己的质检员——审视、挑错、改进，循环往复直到满意为止。

打个比方：

• 没有反思的 AI：就像学生写完试卷直接交，对错全靠运气
• 有反思的 AI：就像写完论文自己审三遍，查漏洞、调逻辑、润色语言，交稿前确保质量

实际例子——写代码：

没有反思（一次通过）：

用户需求 → AI 写代码 → 直接交付
问题：可能有 bug、边界没处理、代码不规范

有反思（迭代改进）：

用户需求 → AI 写代码 → AI 自审（发现 3 个问题）→ 修改 → 再审 → 交付
结果：bug 更少、更健壮

---

二、为什么需要反思？

传统 AI 的问题

问题	表现	后果
幻觉	编造不存在的事实	用户被误导
逻辑跳跃	推理链条有断裂	结论不可靠
遗漏	漏掉需求或边界条件	输出不完整
过度自信	对不确定的事也说得斩钉截铁	信任崩塌

反思能解决什么

1. 质量提升：自己挑错自己改，减少低级错误
2. 减少幻觉：输出后自检事实，不确定就去验证
3. 逻辑加强：审视推理链条，发现断裂点
4. 自适应：初始方案不行就换思路，不会一条路走到黑
5. 信心校准：知道哪里确定、哪里不确定，不再盲目自信

---

三、反思的核心机制：自我批评与修订

基本流程

┌──────────────┐
│  1. 生成输出   │ ← 第一次尝试
└──────┬───────┘
       ▼
┌──────────────┐
│  2. 自我批评   │ ← 找问题：逻辑？事实？完整性？
└──────┬───────┘
       ▼
┌──────────────┐
│  3. 修订改进   │ ← 针对问题逐一修正
└──────┬───────┘
       ▼
┌──────────────┐
│  4. 收敛判断   │ ← 够好了吗？不够就回到步骤 2
└──────────────┘

实战演示：自我批评与修订

场景：让 AI 写一个排序算法

第一轮——生成：

"用快速排序实现，选择第一个元素作为 pivot，递归排序左右子数组。"

第二轮——自我批评：

"分析这个方案：
 - 快速排序思路正确 ✅
 - 但没有处理重复元素的情况 ⚠️
 - 没有考虑数组已经有序时的退化问题（O(n²)）⚠️
 - 没有处理空数组和单元素数组 ⚠️
 - 结论：需要补充边界处理"

第三轮——修订：

"改进方案：
 - 快速排序 + 三数取中法选 pivot（避免退化）
 - 双指针分区，处理重复元素
 - 基线条件：数组长度 ≤ 1 时直接返回
 - 数组较小时切换为插入排序（优化常数因子）"

这就是反思的力量：从"能用"到"好用"。

---

四、四种反思范式

范式 1：自我批评与修订（Self-Critique & Revision）

最基础也最常用的模式。

生成 → 批评 → 修订 → 再批评 → 再修订 → ... → 收敛

优点：

• 直接有效，改进路径清晰
• 每一轮都有明确的改进方向

缺点：

• 多轮生成消耗 token 和时间
• 可能陷入"自我辩护"，不愿否定自己的初始方案（确认偏误）

适用场景：代码生成、文案写作、方案设计

---

范式 2：多视角评估（Multi-Perspective Evaluation）

从不同角度审视同一个输出：

技术视角 → "代码逻辑正确，但性能可以优化"
安全视角 → "第 42 行有 SQL 注入风险"
用户体验视角 → "错误提示太技术化，用户看不懂"
综合评估 → "需要修复安全问题 + 改进错误提示后再发布"

优点：

• 多维度覆盖，不容易漏掉问题
• 模拟不同角色的关注点

缺点：

• 不同视角可能有冲突（性能 vs 安全），需要权衡
• 需要预先定义好评估维度

适用场景：技术方案评审、产品设计、安全审计

---

范式 3：置信度评分与验证（Confidence Scoring）

给输出中的每条信息打信心分，只验证不确定的部分：

原始输出：
  "巴黎是法国首都"          [置信度: 0.95] → 高，不用查
  "人口约 210 万"           [置信度: 0.70] → 中，值得确认
  "建于公元前 250 年"       [置信度: 0.40] → 低，必须验证

反思决策：
  → 查阅资料验证低置信度内容
  → 修正为："巴黎是法国首都。市区人口约 210 万，大巴黎地区超过 1200 万。
            建城于公元前三世纪左右，当时叫卢泰西亚（Lutetia）。"

优点：

• 精准投放验证资源，不浪费 token
• 有效减少幻觉

缺点：

• AI 对自身置信度的判断本身可能不准（过度自信或过度谦虚）

适用场景：知识问答、事实核查、报告生成

---

范式 4：结果模拟与预测（Outcome Simulation）

在执行前先预演后果：

拟执行操作：删除旧日志文件释放磁盘空间

模拟结果：
  ✅ 好处：释放约 15GB 空间
  ⚠️ 风险1：可能删除审计合规需要的日志
  ⚠️ 风险2：可能删除正在排查的线上问题日志

反思决策：
  → 先检查合规保留要求
  → 确认无活跃排查中的问题
  → 确认备份状态
  → 只删除超过保留期限的日志

优点：

• 防止有害操作
• 促使更审慎的决策

缺点：

• 无法完美预测所有后果
• 可能过度谨慎，导致决策瘫痪

适用场景：自动化运维、系统管理、安全操作

---

五、反思的五种策略

策略	时机	说明	示例场景
即时反思	输出前	生成后立即审查，用户看不到中间过程	医疗诊断、法律建议
增量反思	每步之后	多步骤任务中，每完成一步就检查	数学证明、代码生成
回顾反思	任务结束后	分析已完成任务，积累经验	项目复盘、性能分析
比较反思	多方案之间	生成多个方案，横向对比选最优	创意写作、策略规划
协作反思	多 Agent 之间	多个 Agent 互相评审	同行评审、多 Agent 辩论

---

六、反思的六个评估维度

反思时从这六个维度审视输出：

维度	核心问题	检查要点
正确性	事实和逻辑对不对？	数据准确、逻辑严密、计算无误
完整性	有没有遗漏？	需求全覆盖、边界条件处理、上下文充分
清晰性	看得懂吗？	表达清晰、术语恰当、结构合理
一致性	前后矛盾吗？	内部自洽、与已知事实一致、结论连贯
安全性	有风险吗？	是否有害、安全隐患、隐私伦理问题
效率	有更优解吗？	方案最简、资源最优、能否简化

---

七、与其他模式的关系

模式	与反思的关系
提示链	提示链的每一步都可以加入反思，实现"边做边检查"
路由	反思可以作为路由的判断依据——不够好就换条路
并行化	可以并行生成多个方案，然后用反思选择最优
工具调用	反思发现不确定时，调用工具验证

反思是"质量保障层"，可以叠加在任何模式之上。

---

八、反思的陷阱

⚠️ 陷阱 1：确认偏误

AI 倾向于为自己的初始方案辩护，而不是真正挑错。

对策：在 prompt 中明确要求"找出至少 3 个问题"，而不是"你觉得有什么问题"。

⚠️ 陷阱 2：过度反思

反复修改导致"改坏"，或者消耗太多 token 和时间。

对策：设定最大反思轮数（通常 2-3 轮就够），或设置收敛条件。

⚠️ 陷阱 3：反思能力本身有限

AI 可能意识不到自己的错误——不知道自己不知道。

对策：结合工具调用（搜索引擎、代码执行器），用外部手段辅助验证。

⚠️ 陷阱 4：成本问题

每一轮反思都是一次完整的 LLM 调用，成本线性增长。

对策：反思轮用更便宜的模型（如 flash），最终修订用强模型。

---

九、最佳实践

1. 结构化反思 prompt

不要问"你觉得怎么样"，而是给明确的检查清单：

请从以下维度审查你的输出：
1. 正确性：事实是否准确？逻辑是否严密？
2. 完整性：是否覆盖了所有需求？
3. 清晰性：表达是否清楚？
对每个维度给出评分（1-10）和具体改进建议。

2. 分级反思

不是所有任务都需要深度反思：

任务类型	反思策略	轮数
简单问答	即时反思	1 轮
代码生成	增量反思	2-3 轮
技术方案	多视角评估	2 轮
安全关键操作	结果模拟 + 多轮	3+ 轮

3. 收敛条件

避免无限循环，设定明确的"什么时候算够了"：

• 所有维度评分 ≥ 8/10
• 连续两轮没有新问题被发现
• 达到最大反思轮数

4. 反思日志

记录每轮反思发现的问题和改进，形成经验库：

反思轮次1：发现边界条件未处理 → 已修复
反思轮次2：发现变量命名不清晰 → 已优化
结论：2 轮后收敛，输出质量达标

---

十、总结

要点	说明
本质	AI 自己当自己的质检员
核心循环	生成 → 批评 → 修订 → 收敛判断
四种范式	自我批评、多视角评估、置信度验证、结果模拟
五个策略	即时、增量、回顾、比较、协作
六个维度	正确性、完整性、清晰性、一致性、安全性、效率
最大陷阱	确认偏误、过度反思、成本问题
最佳实践	结构化 prompt、分级反思、收敛条件、反思日志

一句话总结：反思让 AI 从"一次性输出"进化为"自我迭代优化"，是从"能用"到"好用"的关键跃迁。