反思（Reflection）

这章讲的是 反思（Reflection）。它是在前面三种模式之后继续升级：

1
2
3
4
提示链 Prompt Chaining：一步一步做
路由 Routing：判断该走哪条路
并行化 Parallelization：多个独立任务同时做
反思 Reflection：做完以后检查、批判、修改

这一章的核心问题是：

Agent 第一次生成的结果不一定好，所以需要一个“检查—反馈—修改”的机制，让结果越来越好。

1. 反思到底是什么？

反思（Reflection） 指的是：智能体生成一个结果之后，不是直接交付，而是再评估这个结果有没有问题，然后根据评估结果进行修改。

典型流程是：

1
2
3
4
5
6
7
执行 Execute
 ↓
评估 / 批判 Evaluate / Critique
 ↓
优化 Improve
 ↓
必要时继续迭代 Iterate

比如让模型写代码：

1
2
3
4
第 1 步：生成初版代码
第 2 步：检查代码有没有 bug、边界情况、风格问题
第 3 步：根据检查意见修改代码
第 4 步：再次检查，直到满足要求

所以反思模式的本质是：

给 Agent 增加一个自我纠错机制。

它不是单纯“多问一次模型”，而是有明确角色分工：第一次负责生成，第二次负责审查，第三次负责修改。

2. 为什么需要反思？

因为 LLM 的第一次输出经常有问题。

比如你让它写一个函数：

1
2
3
4
5
写一个 calculate_factorial(n)，计算 n 的阶乘。
要求：
1. 有 docstring
2. 处理 0 的阶乘
3. 负数抛出 ValueError

模型第一次可能会写出：

1
2
3
4
5
def calculate_factorial(n):
    result = 1
    for i in range(1, n + 1):
        result *= i
    return result

这个代码能处理普通正整数，但可能漏掉：

1
2
3
没有 docstring
没有检查负数
没有检查输入类型

如果直接交付，质量不稳定。

反思模式会多加一个审查步骤：

1
请作为资深 Python 工程师，检查这段代码是否满足原始要求。

审查者可能指出：

1
2
3
- 缺少 docstring
- 没有处理负数输入
- 没有明确处理非整数输入

然后生成者再根据这些意见修改代码。

3. 生产者—批评者模型

PDF 里重点讲了一个结构：

1
2
生产者 Producer
批评者 Critic

也可以叫：

1
2
生成者 Generator
审阅者 Reviewer

它们的分工是：

中文	English	作用
生产者	Producer	负责生成初始结果
批评者	Critic	负责检查结果、指出问题
审阅者	Reviewer	和 Critic 类似，偏向审查与反馈
生成者	Generator	和 Producer 类似，偏向内容生成

流程是：

1
2
3
4
5
6
7
8
9
用户任务
 ↓
Producer 生成初稿
 ↓
Critic 审查初稿
 ↓
Producer 根据批评意见修改
 ↓
输出更好的版本

这个结构比“让同一个模型自己看看自己写得好不好”更可靠一些。因为批评者可以用不同的系统提示，专门站在审查角度看问题。PDF 也提到，独立批评者可以减少自我评审时的偏差，让反馈更结构化。

4. 反思适合哪些场景？

反思不是所有任务都要用。它适合那些 质量比速度更重要 的任务。

场景一：写作与内容生成

比如写博客、文案、报告：

1
2
3
4
5
生成初稿
 ↓
检查逻辑、语气、清晰度、完整性
 ↓
重写优化

适合要求高质量输出的场景。

场景二：代码生成与调试

这是反思模式非常典型的应用。

1
2
3
4
5
6
7
写代码
 ↓
运行测试 / 静态检查 / LLM 审查
 ↓
发现 bug
 ↓
修改代码

Coding Agent 里经常会用这种模式。

比如：

1
2
3
4
5
6
7
8
9
Generate code
 ↓
Run tests
 ↓
Read error message
 ↓
Fix code
 ↓
Run tests again

这就是反思思想。

场景三：复杂问题求解

比如逻辑题、数学推理、规划问题。

模型可以先提出一个方案，然后检查：

1
2
3
这个方案有没有矛盾？
有没有违反条件？
有没有漏掉约束？

如果发现问题，就回退或修改。

场景四：摘要与信息整合

比如总结长文档：

1
2
3
4
5
6
7
生成初版摘要
 ↓
检查是否遗漏关键点
 ↓
检查是否加入原文没有的信息
 ↓
修改摘要

这对 RAG 也很重要。因为 RAG 的最终回答可能存在：

1
2
3
4
漏掉检索内容
错误引用内容
回答没有覆盖用户问题
生成了资料里没有的东西

所以可以增加一个反思步骤来检查答案是否忠于材料。

场景五：规划与策略制定

比如让 Agent 制定学习计划、项目计划、执行方案：

1
2
3
4
5
6
7
8
9
生成计划
 ↓
检查是否现实
 ↓
检查是否有时间冲突
 ↓
检查是否缺少关键步骤
 ↓
修订计划

这类任务往往不是一次生成就能很稳，所以适合反思。

5. LangChain 代码在讲什么？

PDF 里的 LangChain 示例是让模型写一个 Python 阶乘函数，然后反复审查和修改。

任务要求是：

1
2
3
4
5
6
创建 calculate_factorial 函数
接受整数参数 n
计算 n!
包含 docstring
处理 0! = 1
负数抛出 ValueError

代码整体流程是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
第 1 次迭代：
    LLM 生成初始代码
    Critic 审查代码
    如果完美，停止
    如果不完美，把批评意见加入历史

第 2 次迭代：
    LLM 根据批评意见优化代码
    Critic 再次审查
    如果完美，停止
    如果不完美，继续

最多迭代 3 次

关键变量有几个：

1
2
3
max_iterations = 3
current_code = ""
message_history = [HumanMessage(content=task_prompt)]

它们分别表示：

1
2
3
max_iterations：最多反思几轮
current_code：当前版本代码
message_history：保存任务、代码、批评意见的上下文历史

最关键的是这个批评者提示：

1
2
3
4
你是一名资深软件工程师，精通 Python。
请根据原始任务要求，严格评估代码。
如果代码完美，只回复 CODE_IS_PERFECT。
否则，用项目符号给出批判意见。

这里有一个很重要的工程点：

批评者必须有明确的判断标准和停止信号。

比如：

1
CODE_IS_PERFECT

这个停止信号让程序知道什么时候可以退出循环。

否则模型可能一直修改下去，成本和时间都会变高。

6. ADK 代码在讲什么？

PDF 里的 Google ADK（Agent Development Kit，智能体开发工具包） 示例更简单。

它定义了两个 Agent：

1
2
DraftWriter：生成初稿
FactChecker：检查事实准确性

流程是：

1
2
3
4
5
6
7
generator 生成文本
 ↓
输出保存到 draft_text
 ↓
reviewer 读取 draft_text
 ↓
输出 review_output

其中 review_output 是结构化结果：

1
2
status：ACCURATE 或 INACCURATE
reasoning：解释判断原因

这体现了一个关键点：

反思最好输出结构化反馈。

比如不要让审查者随便说：

1
这段还可以，但有点问题。

而是要求它输出：

1
2
3
4
{
  "status": "INACCURATE",
  "reasoning": "第二句话中的事实缺少依据，且与输入材料不一致。"
}

这样后续系统才能判断：

1
2
如果 status = ACCURATE，就结束
如果 status = INACCURATE，就进入修改流程

7. 第 8 页图怎么理解？

第 8 页的图展示的是 自我反思流程（Self-reflection Flow）。

它的结构大概是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
User
 ↓
Prompt
 ↓
Agent
 ↓
Output
 ↘
  Reflection
 ↺ 回到 Agent

意思是：

Agent 生成输出后，会进入 Reflection 环节；反思结果再反馈给 Agent，让它修改输出。

这是一种闭环结构，不是单向流程。

前几章的模式大多是：

1
输入 → 处理 → 输出

而反思变成：

1
输入 → 处理 → 输出 → 检查 → 修改 → 输出

所以第 8 页图的重点是那个回路。

8. 第 9 页图怎么理解？

第 9 页图展示的是 生产者—批评者 Agent 模式。

大概结构是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Prompt
 ↓
Agent: Producer
 ↓
Output
 ↓
Agent: Critique
 ↓
Reflection
 ↺ 返回 Producer

也就是说，生成和审查不是同一个角色完成的，而是分成两个 Agent：

1
2
Producer：负责写
Critique：负责审

这个结构在代码生成、事实核查、长文写作里很常见。

比如：

1
2
3
写作 Agent：写一篇文章
审稿 Agent：检查结构、事实、逻辑
写作 Agent：根据审稿意见重写

这比让一个 Agent 从头到尾自己说自己好不好，更像真实工程里的“生成—评审—修改”流程。

9. 反思模式的代价

反思不是免费的。PDF 明确提到它会带来几个成本：

第一，延迟增加

每反思一次，就多一次或多次 LLM 调用。

比如：

1
2
直接生成：1 次 LLM 调用
生成 + 批判 + 修改：至少 3 次 LLM 调用

所以响应会更慢。

第二，成本增加

LLM 调用次数越多，token 消耗越多，费用越高。

如果是复杂代码或长文档，每轮反思都会带上上下文，成本会进一步增加。

第三，上下文窗口压力增加

反思循环里会保存：

1
2
3
4
5
6
7
原始任务
第一版输出
批判意见
第二版输出
第二次批判意见
第三版输出
...

内容越来越多，可能接近模型的 上下文窗口（Context Window） 限制。

第四，可能陷入无意义修改

有时模型会为了修改而修改，结果不是更好，而是变得更啰嗦、更偏离目标。

所以实际工程里通常要设置：

1
2
3
最大迭代次数 max_iterations
停止条件 stopping condition
评价标准 evaluation criteria

10. 反思和前几章怎么组合？

真实 Agent 工作流通常会把这些模式混在一起。

比如一个研究报告 Agent：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
用户输入主题
 ↓
路由 Routing：判断是行业研究、论文综述还是竞品分析
 ↓
并行 Parallelization：同时检索多个来源
 ↓
提示链 Prompt Chaining：提取信息 → 整理结构 → 生成报告
 ↓
反思 Reflection：检查报告是否遗漏、是否有幻觉、是否符合格式
 ↓
最终输出

也就是说：

1
2
3
4
路由决定走哪条流程
并行提升信息收集速度
提示链负责有序处理
反思负责质量控制

反思在这里像是最后的质量检查环节，也可以插在中间步骤中。

11. 师生对话版理解

学生：老师，反思是不是就是让模型“再检查一遍”？

是，但不是随便检查一遍。它需要明确标准，比如事实准确性、代码是否通过测试、格式是否符合要求、有没有遗漏约束。

没有标准的反思很容易变成空泛评价。

学生：那是不是每次都应该用反思？

不是。

简单问题没必要，比如：

1
什么是 ROC 曲线？

直接解释就行。

反思适合：

1
2
3
4
5
6
代码
长文
报告
计划
复杂推理
高准确性问答

也就是最终质量比速度更重要的任务。

学生：反思是不是一定能让结果变好？

不一定。如果批评标准不清楚，或者批评者本身判断错了，可能会把结果改坏。

所以反思最好结合：

1
2
3
4
5
6
明确评分标准
结构化反馈
测试工具
检索证据
人工反馈
最大迭代次数

比如代码任务里，最可靠的 Critic 往往不是另一个 LLM，而是：

1
2
3
单元测试 Unit Tests
静态检查 Static Analysis
运行报错 Runtime Error

LLM 可以解释错误并修复，但测试结果更客观。

学生：反思和记忆有什么关系？，有记忆时反思效果会更好。

没有记忆时，每次反思都是独立的：

1
这次错了 → 这次改

有记忆时，Agent 可以记住过去犯过的问题：

1
2
上次经常漏掉边界条件
这次生成代码时提前检查边界条件

所以反思 + 记忆，可以让 Agent 不只是当前一轮改得更好，而是长期表现更稳定。

12. 关键词整理

中文	English	含义
反思	Reflection	对自身输出进行评估并改进
自我纠错	Self-correction	发现并修正自己的错误
自我改进	Self-improvement	根据反馈提升结果质量
反馈循环	Feedback Loop	生成、评估、修改的循环结构
生产者	Producer	负责生成初始结果的角色
批评者	Critic	负责审查结果、提出问题的角色
生成者	Generator	负责生成内容或方案
审阅者	Reviewer	负责检查和评价输出
停止条件	Stopping Condition	判断是否结束迭代的条件
最大迭代次数	Max Iterations	防止无限循环的轮数上限
结构化反馈	Structured Feedback	用固定格式输出批判结果
上下文窗口	Context Window	模型一次能处理的上下文长度

13. 直观总结

这一章你可以这样记：

反思（Reflection）就是让 Agent 在输出后进行检查、批判和修改，从而提高结果质量。

和前三章合起来：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
提示链 Prompt Chaining：
解决“复杂任务怎么拆步骤”。

路由 Routing：
解决“下一步该走哪条路径”。

并行化 Parallelization：
解决“哪些任务可以同时做以提高速度”。

反思 Reflection：
解决“结果不够好时怎么检查和改进”。

最重要的工程判断是：

1
2
3
如果任务追求速度，用简单流程。
如果任务追求质量，用反思。
如果任务非常复杂，用反思 + 路由 + 提示链 + 并行化。

所以这章的本质不是让 Agent 更快，而是让 Agent 更稳、更准、更会改。

章节插图