Reflection 深度技术解析：从 Self-Critique 到 Agentic Reflection 的完整架构
Reflection 深度技术解析：从 Self-Critique 到 Agentic Reflection 的完整架构
Reflection（反思）是 AI Agent 从“执行任务”走向“自我检查、自我修正、自我改进”的关键机制。
如果说：
- ReAct 解决的是：Agent 如何“思考 → 行动 → 观察”
- Memory 解决的是：Agent 如何“记住过去”
- RAG 解决的是：Agent 如何“获取外部知识”
- Tool / MCP 解决的是：Agent 如何“与外部世界交互”
- Reflection 解决的则是：
“我刚才做得对吗？哪里有问题？应该如何改进？”
Reflection 的真正价值并不是让 LLM “再想一遍”，而是建立一个 Evaluation → Critique → Revision → Verification 的闭环。
1. 什么是 Reflection？
最简单的 Reflection：
Task
↓
Generate
↓
Critique
↓
Revise
↓
Final Answer
例如用户要求：
写一个 Java 的线程安全缓存。
Agent 第一次生成：
class Cache {
private Map<String, Object> cache = new HashMap<>();
public void put(String key, Object value) {
cache.put(key, value);
}
}
Reflection 发现：
问题：
HashMap 不是线程安全的。
然后：
Revision
修改为：
private final ConcurrentHashMap<String, Object> cache
= new ConcurrentHashMap<>();
这就是最基本的：
Generate
↓
Critique
↓
Revision
但是生产级 Reflection 要复杂得多。
2. Reflection 与普通 LLM 调用的区别
普通 LLM：
User
↓
LLM
↓
Answer
Reflection：
User
↓
LLM
↓
Draft
↓
Evaluator
↓
Critique
↓
LLM
↓
Revision
↓
Verification
↓
Answer
所以：
Reflection 的本质是给 Agent 增加一个 Feedback Loop。
从软件工程角度看，它非常类似：
Compile
↓
Test
↓
Failure
↓
Fix
↓
Retest
这也是为什么 Reflection 非常适合软件开发 Agent。
3. Reflection 最核心的思想：Feedback Loop
可以把 Reflection 抽象成：
┌─────────────┐
│ Task │
└──────┬──────┘
↓
┌─────────────┐
│ Generate │
└──────┬──────┘
↓
┌─────────────┐
│ Evaluate │
└──────┬──────┘
↓
┌─────────────┐
│ Critique │
└──────┬──────┘
↓
┌─────────────┐
│ Revise │
└──────┬──────┘
↓
┌─────────────┐
│ Verify │
└──────┬──────┘
│
┌──────┴──────┐
│ │
Pass Fail
│ │
↓ │
Final ←─────────┘
注意：
Reflection 并不是无限循环。
真正的工程系统必须有：
maxIterations
timeout
qualityThreshold
budget
terminationCondition
否则可能出现：
Reflect
↓
Revise
↓
Reflect
↓
Revise
↓
...
最终：
Token Explosion
4. Reflection 为什么重要？
LLM 有一个非常明显的问题：
生成能力很强，但天然不保证生成结果正确。
例如：
数学计算
代码
SQL
系统设计
事实判断
复杂推理
第一次生成可能存在错误。
传统程序：
Input
↓
Deterministic Algorithm
↓
Output
LLM：
Input
↓
Probabilistic Generation
↓
Output
因此需要：
Generation
+
Evaluation
Reflection 就是连接二者的重要机制。
5. Reflection 与 Self-Consistency 的区别
这两个概念容易混淆。
Self-Consistency
多个答案：
LLM
├── Answer A
├── Answer B
├── Answer C
└── Answer D
然后：
Voting
得到：
Most Consistent Answer
重点：
多个独立推理路径。
Reflection
则是：
Answer
↓
Critique
↓
Improve
重点：
基于反馈修改当前答案。
因此：
Self-Consistency
=
Generate Multiple Candidates
Reflection
=
Generate → Evaluate → Improve
二者可以组合。
6. Reflection 与 ReAct 的区别
ReAct：
Reason
↓
Act
↓
Observe
↓
Reason
↓
Act
核心是：
如何完成任务。
Reflection：
Generate
↓
Evaluate
↓
Critique
↓
Improve
核心是：
如何提高任务质量。
因此两者可以组合：
User
↓
ReAct Agent
↓
Reason → Act
↓
Observe
↓
Draft Answer
↓
Reflection
↓
┌────────┴────────┐
↓ ↓
Pass Fail
↓ ↓
Final Revise
↓
ReAct
这就是：
Reflective ReAct Agent。
7. Reflection 的四个核心阶段
一个完整 Reflection Loop 可以定义为：
1. Generation
2. Evaluation
3. Critique
4. Revision
即：
G → E → C → R
生产系统通常进一步增加：
Verification
形成：
G → E → C → R → V
8. Generation：第一次生成
首先完成任务：
Task
↓
LLM
↓
Draft
例如：
Task:
设计秒杀系统。
Draft:
Redis 扣库存
↓
MQ
↓
DB
此时不要急着认为答案正确。
9. Evaluation：评价
Evaluator 判断：
Draft 是否满足要求？
可以采用：
LLM Judge
也可以：
Rule Engine
甚至：
Unit Test
Integration Test
Static Analysis
例如代码 Agent：
Draft
↓
Compile
↓
Unit Test
↓
Result
这通常比单纯让 LLM 判断更可靠。
10. Critique：批判
Critique 不应该简单问：
“这个答案怎么样？”
更好的方式是：
请从以下维度检查：
1. Correctness
2. Completeness
3. Consistency
4. Security
5. Performance
6. Maintainability
然后：
{
"score": 7.5,
"issues": [
{
"severity": "HIGH",
"category": "CONCURRENCY",
"description": "库存扣减存在并发超卖风险"
},
{
"severity": "MEDIUM",
"category": "CONSISTENCY",
"description": "没有说明 Redis 与数据库之间的一致性策略"
}
]
}
这样 Reflection 才能真正进入工程化阶段。
11. Revision：修改
Revision 不应该：
重新生成一遍。
而应该：
Original Draft
+
Critique
+
Constraints
↓
Revised Draft
例如：
Original:
Redis 扣库存。
Critique:
没有说明原子性。
Revision:
使用 Lua Script 保证库存判断与扣减操作的原子性。
这样可以：
局部修复
而不是：
全部推倒重来。
12. Verification：验证
这是生产级 Reflection 和 Demo 最大的区别。
不能：
LLM：
我检查了一遍，应该没问题。
就认为完成。
应该：
Revision
↓
Independent Verification
例如代码：
Compile
↓
Unit Test
↓
Integration Test
SQL：
EXPLAIN
↓
Execution
↓
Result Validation
API：
HTTP Request
↓
Response
↓
Schema Validation
因此：
Reflection 负责“思考如何改进”，Verification 负责“证明改进是否有效”。
13. Reflection 的真正价值：Externalized Evaluation
LLM 最大的问题之一：
Generator
=
Evaluator
如果让同一个 LLM：
写答案
↓
自己检查
它可能存在：
Self-Bias
因此更好的架构是：
Generator
↓
Independent Evaluator
↓
Feedback
↓
Generator
甚至：
Generator Model
↓
Evaluator Model
使用不同模型。
14. Generator / Critic Architecture
经典架构：
Task
│
▼
┌──────────────┐
│ Generator │
└──────┬───────┘
│
▼
Draft
│
▼
┌──────────────┐
│ Critic │
└──────┬───────┘
│
▼
Feedback
│
▼
┌──────────────┐
│ Generator │
└──────────────┘
这其实就是：
Generator-Critic Loop
15. Critic 不一定是 LLM
这是一个非常重要的工程思想。
很多 Agent 系统：
LLM
↓
LLM
↓
LLM
↓
LLM
成本非常高。
实际上 Critic 可以是：
LLM
Rule Engine
Compiler
Unit Test
Static Analyzer
SQL Engine
Schema Validator
Policy Engine
例如：
代码生成 Agent
可以：
LLM Generator
↓
Compiler
↓
JUnit
↓
SonarQube
↓
LLM Critic
这样可靠性远高于：
LLM → LLM
16. Reflection 的三种实现模式
可以把 Reflection 分成三个等级。
Level 1：Self-Reflection
LLM
↓
Answer
↓
LLM
↓
Critique
↓
LLM
↓
Revision
简单。
成本低。
但容易存在：
Self-Bias
Level 2：Generator-Critic
Generator
↓
Critic
↓
Generator
职责分离。
效果更好。
Level 3：Tool-Augmented Reflection
Generator
↓
Critic
↓
Tools
├── Compiler
├── Test
├── Search
├── SQL
└── API
↓
Verification
↓
Revision
这是最适合生产环境的方式。
17. Reflection + Tools
例如：
帮我修复这个 Java Bug。
Agent：
Read Code
↓
Reason
↓
Generate Patch
↓
Compile
↓
Test
如果：
Test Failed
则：
Reflection
↓
Analyze Failure
↓
Modify Patch
↓
Compile
↓
Test
直到：
Tests Passed
这个过程实际上非常接近：
Autonomous Software Engineer
18. Reflection + ReAct
把 ReAct 和 Reflection 合起来：
┌──────────────────────────────────────┐
│ Agent │
│ │
│ ┌───────────┐ │
│ │ ReAct │ │
│ └─────┬─────┘ │
│ │ │
│ ▼ │
│ Reason │
│ │ │
│ ▼ │
│ Tool │
│ │ │
│ ▼ │
│ Observation │
│ │ │
│ ▼ │
│ Draft │
│ │ │
│ ▼ │
│ ┌───────────┐ │
│ │ Reflection│ │
│ └─────┬─────┘ │
│ │ │
│ ▼ │
│ Critique │
│ │ │
│ ▼ │
│ Revision │
│ │ │
│ └────────→ ReAct │
└──────────────────────────────────────┘
ReAct 负责：
Task Execution
Reflection 负责：
Task Quality
19. Reflection + Memory
Reflection 还可以把反馈保存下来。
例如：
Task
↓
Generate
↓
Critique
↓
Failure
系统发现：
以前经常因为没有考虑数据库事务导致失败。
可以写入：
Memory
例如：
When designing distributed transactions,
always explicitly consider transaction boundaries,
failure recovery and idempotency.
以后 Agent 再遇到类似问题：
Retrieve Memory
↓
Reason
于是：
Reflection
不仅修复当前任务：
还可以改善未来任务。
20. Reflection 的 Learning Loop
因此可以形成：
Task
↓
Execute
↓
Reflect
↓
Failure Analysis
↓
Memory
↓
Future Task
↓
Better Execution
这就是：
Reflection + Memory = Experience Learning
注意：
这并不意味着模型参数真的发生了变化。
更多情况下是：
External Memory
发生了变化。
21. Reflection 与 Fine-Tuning 的区别
Reflection：
Runtime Learning
Fine-tuning：
Model Parameter Learning
Reflection：
Task A
↓
Feedback
↓
Improve Task A
Fine-tuning：
Many Examples
↓
Training
↓
Model Update
↓
Future Tasks
所以：
Reflection
=
Inference-time Improvement
Fine-tuning
=
Training-time Improvement
22. Reflection 的一个关键问题：谁来评价？
这是 Reflection 最深层的问题。
假设：
Generator = GPT-like LLM
Critic = Same LLM
那么：
如果 Generator 犯了一个模型本身不知道的错误
Critic 可能：
无法发现。
所以 Reflection 的质量取决于：
Evaluator Capability
这意味着：
Reflection 本身不是可靠性的保证。
必须引入：
Ground Truth
External Tools
Deterministic Validators
Human Feedback
23. Reflection 的 Evaluation Hierarchy
可以按照可靠性排序：
Human Feedback
↑
External Ground Truth
↑
Deterministic Test
↑
Specialized Evaluator
↑
LLM Judge
↑
Self-Critique
例如代码：
Self-Critique
不如：
Compile + Unit Test
数学：
LLM Judge
不如：
Symbolic Calculator
API：
LLM 判断 JSON 是否正确
不如：
JSON Schema Validator
所以：
能用确定性验证器，就不要只使用 LLM Reflection。
24. Reflection 的停止条件
必须设计：
class ReflectionPolicy {
int maxIterations;
double minScore;
Duration timeout;
int maxTokens;
boolean requireVerification;
}
例如：
maxIterations = 3
minScore = 0.9
timeout = 30 seconds
循环：
Iteration 1
↓
Score = 0.62
Iteration 2
↓
Score = 0.81
Iteration 3
↓
Score = 0.93
STOP
25. Reflection 的边际收益
Reflection 并不是：
Iterations ↑
Quality ↑
无限增长。
通常：
Quality
│
│ ________
│ /
│ /
│ /
│ /
│____/
└──────────────────── Iterations
第一轮 Reflection：
提升很大
第二轮：
仍有提升
第三轮：
提升变小
继续：
成本增加
收益很低
因此：
Reflection 应该有预算，而不是无限追求完美。
26. Reflection 的成本模型
一次普通调用：
Cost = C_generation
Reflection：
Cost
=
C_generation
+
C_evaluation
+
C_revision
+
C_verification
如果：
3 iterations
可能变成：
3~6 次 LLM Calls
所以必须考虑：
Latency
Token Cost
Model Cost
Tool Cost
27. Adaptive Reflection
不是所有任务都需要 Reflection。
例如：
“你好”
不需要。
“把 Java List 转成 Set”
通常不需要。
但：
“设计一个金融交易系统”
值得 Reflection。
因此可以：
Task Complexity
↓
Reflection Policy
例如：
Low Complexity
→ No Reflection
Medium
→ One Critique
High
→ Full Reflection Loop
这叫：
Adaptive Reflection。
28. Risk-Based Reflection
甚至可以根据风险：
Risk
├── Low
├── Medium
└── High
例如：
代码格式化
→ Low
生产数据库 SQL
→ High
金融交易
→ Very High
策略：
Low
→ LLM Self Check
Medium
→ Critic
High
→ Critic + Tool Verification
Very High
→ Human-in-the-loop
这是非常实用的企业 Agent 架构。
29. Reflection Prompt Engineering
一个差的 Prompt：
检查一下你的答案。
一个好的 Reflection Prompt：
You are a strict technical reviewer.
Review the proposed solution against:
1. Functional correctness
2. Concurrency safety
3. Error handling
4. Security
5. Performance
6. Maintainability
For each issue:
- identify the problem
- explain why it matters
- assign severity
- provide a concrete correction
Do not rewrite the solution yet.
然后 Revision：
You are the implementation agent.
Given:
- Original solution
- Review feedback
- Original requirements
Revise the solution.
Preserve correct parts.
Fix only identified issues.
Do not introduce unrelated changes.
这样比：
“请重新回答”
可靠得多。
30. Structured Reflection
生产系统最好不要让 Critic 输出自然语言。
推荐：
{
"status": "NEEDS_REVISION",
"score": 0.78,
"issues": [
{
"severity": "HIGH",
"category": "CORRECTNESS",
"description": "...",
"recommendation": "..."
}
]
}
这样程序可以直接判断：
if (evaluation.score() < threshold) {
revise();
}
而不是：
if (text.contains("not good")) {
...
}
31. Reflection State Machine
可以把 Agent 实现成状态机：
GENERATE
↓
EVALUATE
↓
┌──────────────┐
│ Score >= 0.9 │
└──────┬───────┘
│
YES
↓
VERIFY
│
▼
SUCCESS
NO
↓
CRITIQUE
↓
REVISE
↓
GENERATE
对应 Java：
enum AgentState {
GENERATE,
EVALUATE,
CRITIQUE,
REVISE,
VERIFY,
SUCCESS,
FAILED
}
这比把所有逻辑写在一个：
while(true)
里更加可维护。
32. Reflection Agent 的 Java 设计
可以定义：
public interface Generator {
Draft generate(Task task, Context context);
}
Evaluator：
public interface Evaluator {
Evaluation evaluate(
Task task,
Draft draft
);
}
Critic：
public interface Critic {
Feedback critique(
Task task,
Draft draft,
Evaluation evaluation
);
}
Revision：
public interface Reviser {
Draft revise(
Draft draft,
Feedback feedback
);
}
Verification：
public interface Verifier {
VerificationResult verify(
Draft draft
);
}
最终：
class ReflectionAgent {
private Generator generator;
private Evaluator evaluator;
private Critic critic;
private Reviser reviser;
private Verifier verifier;
}
33. Reflection Loop 示例
伪代码：
Draft draft = generator.generate(task, context);
for (int i = 0; i < maxIterations; i++) {
Evaluation evaluation =
evaluator.evaluate(task, draft);
if (evaluation.isGoodEnough()) {
VerificationResult result =
verifier.verify(draft);
if (result.isValid()) {
return draft;
}
}
Feedback feedback =
critic.critique(
task,
draft,
evaluation
);
draft =
reviser.revise(
draft,
feedback
);
}
throw new ReflectionFailedException();
这就是最基本的：
Generate
→ Evaluate
→ Critique
→ Revise
→ Verify
34. Reflection + Spring Boot
在 Spring Boot 中可以进一步拆成：
reflection-agent
│
├── controller
│
├── application
│ └── ReflectionOrchestrator
│
├── domain
│ ├── Task
│ ├── Draft
│ ├── Evaluation
│ └── Feedback
│
├── llm
│ ├── GeneratorClient
│ ├── CriticClient
│ └── ReviserClient
│
├── verification
│ ├── CodeVerifier
│ ├── SchemaVerifier
│ └── RuleVerifier
│
└── memory
这与传统 Java：
Controller
Service
Repository
的架构思想完全可以结合。
35. Reflection + OpenTelemetry
如果做生产级 Agent，Reflection 的每一步都应该可观测。
例如 Trace：
Agent Request
│
├── Memory Retrieval
│
├── LLM Generate
│
├── LLM Critique
│
├── Tool Verification
│
├── LLM Revision
│
└── Final Response
Span：
agent.generate
agent.evaluate
agent.critique
agent.revise
agent.verify
Metrics：
reflection_iterations
reflection_success_rate
reflection_failure_rate
reflection_latency
reflection_token_usage
reflection_cost
这对于 Debug 非常重要。
36. Reflection Failure Analysis
假设 Agent 最终回答错误。
传统系统：
Request
↓
LLM
↓
Wrong Answer
很难 Debug。
Reflection Agent：
Request
↓
Generate
↓
Critique
↓
Revision
↓
Verification
↓
Wrong Answer
可以定位：
Generator Error
Critic Error
Revision Error
Verification Error
因此 Reflection 同时提升：
Reliability
+
Observability
37. 一个代码 Agent 的完整案例
用户：
实现一个线程安全的 LRU Cache。
Agent：
Step 1
Generate Java Code
得到：
class LRUCache {
private final Map<Integer, Integer> cache =
new LinkedHashMap<>();
}
Reflection：
Critic:
存在并发访问问题。
Revision：
synchronized
然后：
Compile
↓
Unit Test
↓
Concurrency Test
发现：
Race Condition
再次 Reflection：
Review
↓
Replace implementation
↓
ConcurrentHashMap + custom eviction
再次测试：
PASS
最终：
Answer
这已经不是简单的：
LLM Code Generation
而是：
Autonomous Coding Loop。
38. Reflection 在软件工程中的巨大潜力
未来 Coding Agent 很可能采用：
Requirement
↓
Plan
↓
Generate Code
↓
Compile
↓
Test
↓
Reflect
↓
Fix
↓
Test
↓
Security Scan
↓
Performance Test
↓
Review
↓
Pull Request
这里 Reflection 是整个：
Software Engineering Loop
的核心。
39. Reflection + Multi-Agent
更进一步，可以使用多个 Agent：
Task
│
┌───────┴────────┐
▼ ▼
Developer Architect
│ │
└───────┬────────┘
▼
Critic
│
┌───────┴────────┐
▼ ▼
Security Tester
│ │
└───────┬────────┘
▼
Judge
│
▼
Final
不同 Agent 负责：
Developer
Architecture
Security
Performance
Testing
这种架构本质上是：
Multi-Agent Reflection。
40. Debate 与 Reflection
再进一步：
Agent A
↓
Proposal
Agent B
↓
Counter Argument
Agent A
↓
Revision
Judge
↓
Final
这已经从：
Reflection
进入：
Debate
两者区别：
Reflection
=
自己/另一个 Agent 批评自己
Debate
=
多个 Agent 互相挑战
41. Reflection + Memory + ReAct + RAG
如果把前面几个主题全部组合：
User
│
▼
┌─────────────┐
│ Agent │
└──────┬──────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Memory RAG Context
│ │ │
└──────────────────┼──────────────────┘
│
▼
ReAct
│
Reason → Act
│
▼
Observe
│
▼
Draft
│
▼
Reflection
│
┌────────────┴────────────┐
▼ ▼
Critique Verification
│ │
└────────────┬────────────┘
▼
Revise
│
▼
Final
│
▼
Memory
这就是一个比较完整的：
Reflective Agent Architecture
42. Reflection 的核心设计原则
原则 1：Reflection 不是重新生成
错误：
Answer
↓
Generate Again
正确：
Answer
↓
Feedback
↓
Targeted Revision
原则 2：Evaluation 必须独立
尽量避免：
Generator = Evaluator
最好：
Generator
≠
Evaluator
原则 3：能使用工具验证，就不要只靠 LLM
例如：
代码 → Compiler/Test
数学 → Calculator
SQL → Database
API → Real Request
JSON → Schema Validator
原则 4：Reflection 必须有预算
Max Iterations
Max Tokens
Timeout
Cost Budget
原则 5：Reflection 应该是风险驱动的
Low Risk
→ No Reflection
High Risk
→ Deep Reflection
43. Reflection 的最终抽象
如果把 Reflection 用一个数学形式表达：
D₀ = Generate(Task)
第一次生成：
D₀
评价：
E₀ = Evaluate(D₀)
产生反馈：
F₀ = Critique(D₀, E₀)
修改：
D₁ = Revise(D₀, F₀)
然后：
D₂ = Revise(D₁, F₁)
最终：
D* = argmax Quality(D)
因此 Reflection 可以理解为：
在推理阶段进行迭代式质量优化。
44. Reflection 真正解决的问题
LLM 原始能力：
Generate
Reflection：
Generate
+
Evaluate
+
Correct
ReAct：
Reason
+
Act
+
Observe
Memory：
Remember
+
Retrieve
RAG：
Retrieve
+
Ground
Tool Calling：
Act
+
Observe
最终：
Agent
│
┌──────────────┼──────────────┐
│ │ │
Reason Memory Tools
│ │ │
ReAct RAG MCP
│ │ │
└──────────────┼──────────────┘
│
▼
Reflection
│
Evaluate → Improve
│
▼
Reliable Agent
45. 最值得记住的一句话
如果面试官问：
Reflection 到底是什么？
可以回答：
Reflection 是 Agent 在完成一个阶段性任务后，通过 Evaluator 或 Critic 对当前结果进行系统性评价，识别错误、缺陷和改进方向，然后根据反馈进行 Revision，并通过 Verification 验证修改结果，从而形成 Generate → Evaluate → Critique → Revise → Verify 的闭环。它本质上是一种 inference-time feedback optimization mechanism，而不是简单地让 LLM 再生成一次答案。
如果再进一步：
高质量的 Reflection 不应该完全依赖 LLM 自我评价，而应该结合确定性验证器、工具调用、外部 Ground Truth、Memory 和 Human-in-the-loop，最终形成可观测、可控、有预算的 Agent Quality Loop。
这才是 Reflection 真正的工程价值。
46. 最终形成 AI Agent 四大核心能力
到这里，可以把我们前面讨论的几个主题串起来：
┌──────────────────────┐
│ AI Agent │
└──────────┬───────────┘
│
┌───────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Reason Remember Act
│ │ │
ReAct Memory Tools
│ │ │
└───────────────┼────────────────┘
│
▼
Reflection
│
Evaluate / Improve
│
▼
Better Agent
可以把它浓缩成：
ReAct
→ 我怎么做？
Memory
→ 我记得什么？
RAG
→ 外部世界知道什么？
Tools / MCP
→ 我能做什么？
Reflection
→ 我做得对不对？
而真正高级的 Agent：
Remember
↓
Reason
↓
Act
↓
Observe
↓
Reflect
↓
Improve
↓
Remember
形成完整的：
Agent Cognitive Loop
这也是从普通 LLM Application Developer 进一步走向 AI Agent Engineer / AI Platform Engineer 时，非常值得掌握的一条核心技术主线。
