反思模式（Reflection）
通过引入反馈循环，让智能体从「一次性执行」进化为「迭代改进」，是构建高质量输出的关键机制。
🎯 什么是反思模式？
反思（Reflection）是指智能体评估自己的工作、输出和内部状态，并利用评估结果来改进性能和优化响应。这是一种自我纠正或自我改进的形式。
四种模式的演进
| 章节 | 模式 | 核心能力 | 解决问题 |
|---|---|---|---|
| 第一章 | 提示链 | 顺序执行 | 怎么走？ |
| 第二章 | 路由 | 动态决策 | 走哪条路？ |
| 第三章 | 并行化 | 同时执行 | 走多快？ |
| 第四章 | 反思 | 自我改进 | 走得好不好？ |
与其他模式的本质区别
| 模式 | 特点 |
|---|---|
| 提示链 | 输出直接传给下一步 |
| 路由 | 在不同路径中做选择 |
| 反思 | 引入反馈循环，审视并改进自己的输出 |
🔄 反思的四个步骤
┌────────────────────────────────────────────────────────────────┐
│ 反思循环 │
├────────────────────────────────────────────────────────────────┤
│ │
│ ① 执行（Execution） │
│ 智能体执行任务，生成初始版本的输出 │
│ │ │
│ ▼ │
│ ② 评估/剖析（Evaluation/Critique） │
│ 分析结果：准确性、连贯性、完整度等 │
│ │ │
│ ▼ │
│ ③ 反思/优化（Reflection/Refinement） │
│ 根据评估结果确定改进方向并修改 │
│ │ │
│ ▼ │
│ ④ 迭代（Iteration） │
│ 重复上述过程，直到满意或达到停止条件 │
│ │
└────────────────────────────────────────────────────────────────┘评估的维度
| 维度 | 说明 |
|---|---|
| 事实准确性 | 信息是否正确？ |
| 内容连贯性 | 逻辑是否通顺？ |
| 风格一致性 | 语气是否符合要求？ |
| 完整度 | 是否遗漏重要内容？ |
| 指令遵从 | 是否按要求执行？ |
👥 生产者-评论者模型
为什么需要两个角色？
单个智能体进行自我反思有一个问题：认知偏见。
就像作者很难发现自己文章中的问题一样，智能体审查自己的输出时也容易"灯下黑"。
两个角色的分工
| 角色 | 职责 | 特点 |
|---|---|---|
| 生产者（Producer） | 执行任务，生成内容 | 专注于创作 |
| 评论者（Critic） | 评估输出，提供反馈 | 专注于挑错 |
评论者的角色设定
评论者通常被赋予一个专业角色：
- "你是一位高级软件工程师"
- "你是一位严谨的事实核查员"
- "你是一位资深编辑"
工作流程
┌─────────────────────────────────────────────────────────────────┐
│ 生产者-评论者模型 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [初始任务] │
│ │ │
│ ▼ │
│ ┌──────────────────┐ │
│ │ 🔨 生产者 │ │
│ │ 生成初始输出 │ │
│ └────────┬─────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────┐ │
│ │ 🔍 评论者 │ ← "你是高级软件工程师，请审查代码" │
│ │ 评估并提反馈 │ │
│ └────────┬─────────┘ │
│ │ │
│ ▼ │
│ ┌────────────┐ │
│ │ 达标了吗？│ │
│ └─────┬──────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ 是 │ 否 │
│ ▼ ▼ │
│ 输出结果 反馈给生产者 → 修改 → 返回评论者 │
│ │
└─────────────────────────────────────────────────────────────────┘职责分离的价值
| 优势 | 说明 |
|---|---|
| 分离检查职责 | 单独分配审查任务，减少生成与检查争用同一提示 |
| 专业化评估 | 评论者可以是特定领域专家 |
| 结构化反馈 | 反馈更有针对性、更系统 |
| 可审计反馈 | 评论者必须给出证据；不同角色仍可能共享偏差 |
代码实现
下面是控制循环的接口示意。generate(task, previous, feedback)、review(task, candidate) 和 verify(candidate) 是需要实现的适配函数，分别负责生成、结构化评审和独立验证；不是可直接调用的 SDK。review 至少返回 issues 列表，verify 返回布尔值。模型评审只能提出问题，不能取代测试或证据校验。
python
def refine(task, generate, review, verify, max_revisions=2):
candidate = generate(task, None, None)
for attempt in range(max_revisions + 1):
feedback = review(task, candidate)
passed = verify(candidate)
if passed and not feedback["issues"]:
return {"status": "passed", "output": candidate}
if attempt == max_revisions:
return {"status": "needs_review", "output": candidate,
"feedback": feedback, "verification_passed": passed}
candidate = generate(task, candidate, feedback)生成器每次修订都应收到原始任务、原稿和具体反馈，防止只追随最新评论而丢失原始要求。评审结果要先做 schema 校验；字符串中出现 LGTM 不能作为通过条件，例如“并非 LGTM”也包含这个片段。
Self-Refine研究了同一模型生成反馈并修订的方式；另有研究发现，缺乏外部反馈的自我纠错可能不能修复推理错误，甚至把正确答案改错。这些结论依赖研究中的模型和任务，不能泛化成“反思总有效”或“总无效”。自我纠错研究
实现要点：保留修订历史；硬性验证失败时不得标记完成；达到轮数或费用上限后明确返回未达标状态。验收时同时统计“错变对”和“对变错”的比例，并与不反思的基线比较。代码任务使用测试、静态检查和需求断言；事实写作用原文逐条支持关键主张。
📋 六大应用场景
1. 创意写作和内容生成
| 用例 | 反思过程 | 价值 |
|---|---|---|
| 撰写博客文章 | 写草稿 → 检查流畅性、语气 → 重写 | 更精致的内容 |
2. 代码生成和调试
| 用例 | 反思过程 | 价值 |
|---|---|---|
| 编写Python函数 | 写代码 → 运行测试 → 识别错误 → 修复 | 更健壮的代码 |
3. 复杂问题解决
| 用例 | 反思过程 | 价值 |
|---|---|---|
| 逻辑推理谜题 | 提出步骤 → 评估是否推进 → 回退或调整 | 更强的问题导航 |
4. 摘要和信息综合
| 用例 | 反思过程 | 价值 |
|---|---|---|
| 总结长文档 | 生成摘要 → 对照原文 → 补充遗漏 | 更准确的摘要 |
5. 规划和策略
| 用例 | 反思过程 | 价值 |
|---|---|---|
| 制定行动计划 | 生成计划 → 评估可行性 → 调整 | 更务实的计划 |
6. 对话智能体
| 用例 | 反思过程 | 价值 |
|---|---|---|
| 客服机器人 | 生成回复 → 回顾对话历史 → 确保连贯 | 更自然的沟通 |
🔬 实战案例：代码审查智能体
场景描述
以下代码审查对话为教学构造，评分与反馈不是实际运行记录。
用户请求："帮我写一个计算阶乘的Python函数"
反思流程
┌─────────────────────────────────────────────────────────────────┐
│ 代码审查反思循环 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [任务: 编写阶乘函数] │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ 🔨 生产者（代码生成器） │ │
│ │ │ │
│ │ 生成初始代码: │ │
│ │ def factorial(n): │ │
│ │ if n == 0: │ │
│ │ return 1 │ │
│ │ return n * factorial(n-1) │ │
│ └──────────────────┬───────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ 🔍 评论者（高级软件工程师） │ │
│ │ │ │
│ │ 审查反馈: │ │
│ │ 1. 缺少输入验证（负数怎么办？） │ │
│ │ 2. 缺少类型提示 │ │
│ │ 3. 大数可能栈溢出，建议用迭代 │ │
│ │ 4. 缺少文档字符串 │ │
│ └──────────────────┬───────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ 🔨 生产者（根据反馈修改） │ │
│ │ │ │
│ │ 改进后代码: │ │
│ │ def factorial(n: int) -> int: │ │
│ │ """计算n的阶乘""" │ │
│ │ if not isinstance(n, int) or n < 0: │ │
│ │ raise ValueError("需要非负整数") │ │
│ │ result = 1 │ │
│ │ for i in range(2, n + 1): │ │
│ │ result *= i │ │
│ │ return result │ │
│ └──────────────────┬───────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ 🔍 评论者（再次审查） │ │
│ │ │ │
│ │ 审查结果: ✅ 代码质量良好，无需修改 │ │
│ └──────────────────┬───────────────────────┘ │
│ │ │
│ ▼ │
│ [输出最终代码] │
│ │
└─────────────────────────────────────────────────────────────────┘关键设计要点
| 要点 | 说明 |
|---|---|
| 专业角色 | 评论者是"高级软件工程师" |
| 结构化反馈 | 具体指出问题和改进方向 |
| 迭代改进 | 循环直到评论者满意 |
| 停止条件 | 无问题或达到最大迭代次数 |
⚡ 反思的增强因素
与目标和监控的关系
┌──────────────┐
│ 🎯 目标 │ → 提供评估的最终基准
└──────┬───────┘
│
▼
┌──────────────┐
│ 📊 监控 │ → 跟踪进度，发现偏离
└──────┬───────┘
│
▼
┌──────────────┐
│ 🔄 反思 │ → 分析偏离原因，调整策略
└──────────────┘
协同作用：使智能体从「被动执行者」变成「有目的的自适应系统」与记忆的关系
| 有无记忆 | 反思特点 |
|---|---|
| 无记忆 | 每次反思都是独立事件 |
| 有记忆 | 反思成为累积性循环，避免重复犯错 |
⚠️ 反思模式的代价
成本与收益
| 收益 | 代价 |
|---|---|
| 更高质量的输出 | 更长的延迟 |
| 更准确的结果 | 更高的计算成本 |
| 更好地遵循复杂指令 | 可能超出上下文窗口 |
| 自我纠错能力 | 可能被API限流 |
何时值得使用？
✅ 值得使用：
- 质量、准确性比速度更重要
- 生成长篇内容
- 编写和调试代码
- 创建详细计划
- 需要专业评估
❌ 不值得使用：
- 对速度要求很高
- 任务简单，初始输出已足够
- 成本敏感的场景
📊 两种反思架构
自我反思
┌──────────────────┐
│ 智能体 A │
│ │
│ 生成 → 自评 → 改进 → 循环...
└──────────────────┘
优点：简单
缺点：可能有认知偏见生产者-评论者架构
┌──────────────────┐ ┌──────────────────┐
│ 🔨 生产者 │ ←→ │ 🔍 评论者 │
│ 专注于创作 │ │ 专注于挑错 │
└──────────────────┘ └──────────────────┘
优点：更客观、更专业
缺点：更复杂、更多LLM调用📊 四种模式对比
| 维度 | 提示链 | 路由 | 并行化 | 反思 |
|---|---|---|---|---|
| 核心问题 | 怎么走？ | 走哪条路？ | 走多快？ | 走得好不好？ |
| 执行方式 | 顺序 | 条件分支 | 并发 | 迭代循环 |
| 比喻 | 流水线 | 调度中心 | 多车道 | 质检站 |
| 优化目标 | 可靠性 | 灵活性 | 效率 | 质量 |
组合公式
高质量智能体 = 提示链（可靠性） + 路由（灵活性） + 并行化（效率） + 反思（质量）
📝 核心要点
| 要点 | 说明 |
|---|---|
| 自我纠错 | 反思使智能体能够迭代改进输出 |
| 反馈循环 | 执行 → 评估 → 优化 → 迭代 |
| 生产者-评论者 | 职责分离提高客观性和专业性 |
| 元认知 | 为智能体增加自我意识和适应能力 |
| 质量优先 | 适用于质量比速度更重要的场景 |
🔧 工具支持
| 框架 | 反思实现方式 |
|---|---|
| LangChain LCEL | 单步反思循环 |
| LangGraph | 完整迭代反思（状态管理） |
| Google ADK | 多智能体串联工作流 |
| Crew.AI | 支持反思链 |
🔗 相关阅读
参考资源：