Chapter 04 · Agent Patterns
ReAct、Planning、Reflection，不是三个孤立概念，而是 Agent 控制策略的三块积木
这一份的目标不是记论文名字，而是建立一个可以直接用于项目设计的控制框架：遇到动态环境用 ReAct，遇到长任务先 Plan，遇到结果不可靠就引入 Reflection 与外部验证。
ReAct边做边看
适应动态环境
适应动态环境
Plan先拆任务
保留全局结构
保留全局结构
Reflect检查修正
提升可靠性
提升可靠性
组合Plan → Act → Reflect
真实 Agent 常这样做
真实 Agent 常这样做
1. ReAct：边行动，边根据结果调整
ReAct 的核心不是“Thought”这个单词，而是：模型的下一步决策依赖真实环境返回的 Observation。
Decision → Action → Observation → Decision → …
典型场景
🌐
Web Agent
搜索结果决定下一次搜索什么。
💻
Code Agent
编译错误、测试结果决定下一次修改。
🔎
Research Agent
已有证据决定还缺什么信息。
最重要的判断：如果任务过程中会不断出现新信息，而且下一步必须依据这些新信息决定，ReAct 就很适合。
2. ReAct 的最小代码骨架
def run_agent(task, tools):
state = []
for step in range(MAX_STEPS):
decision = llm.decide(
task=task,
state=state,
tools=tools
)
if decision.type == "finish":
return decision.answer
result = execute_tool(
decision.tool,
decision.arguments
)
state.append({
"action": decision,
"observation": result
})
不要把 ReAct 等同于字符串 “Thought / Action / Observation”。那只是早期常见的文本协议。现代工程更倾向 Structured Output / Tool Calling，因为字符串正则解析太脆弱。
| 旧式做法 | 更稳妥的做法 |
|---|---|
Action: search("...") 再用正则解析 | 让模型输出结构化 Tool Call |
| 容易被格式变化打断 | Schema 更明确、更容易校验 |
| 调试困难 | 参数与工具调用可单独评估 |
3. Plan-and-Solve：先看全局，再执行局部
ReAct 很灵活，但如果任务很长，Agent 容易“只顾眼前”。Plan-and-Solve 的目的就是先构造任务地图。
Goal → Plan → Step 1 → Step 2 → Step 3 → Finish
优点
保留全局目标；长任务不容易乱；更适合做进度管理和步骤检查。
缺点
初始计划可能错误；环境变化后旧计划可能失效，需要 Replan。
工程化建议：Planner 最好输出结构化任务列表，而不是一大段自由文本。这样步骤更容易被 Runtime 执行、跟踪、重试与评估。
4. Reflection：做完以后，不要直接相信自己
Reflection 的本质是：生成一个结果后，再引入“评估 → 批评 → 修正”的闭环。
Generate → Evaluate → Critique → Improve
Self-Reflection 的问题
🪞
只让模型“自己检查”
生成器和评估器可能犯相似错误，模型可能对错误结果仍然自信。
✅
引入可验证反馈
pytest、编译器、benchmark、数据库结果、规则校验等能提供独立证据。
Reflection + Verifiable Feedback ≫ Pure Self-Reflection
特别适合代码 Agent：因为编译器和测试天然就是外部反馈源。比单纯问“你觉得自己的代码对吗？”可靠得多。
5. 三者怎么组合？
真实长任务通常不是 ReAct、Plan、Reflection 三选一，而是组合。
Plan → ReAct → Evaluate → Reflect → Replan / Finish
这就是更接近真实 Agent 的控制逻辑。Plan 提供全局方向，ReAct 处理动态局部环境，Evaluator 提供客观反馈，Reflection 决定如何修正。
6. 用“科研复现 Agent”理解一次
这是最适合把三种范式串起来的案例。
Plan：解析论文 → 找代码 → 确认数据集 → 搭环境 → 跑 baseline → 对比论文指标。
ReAct：安装依赖时出现 CUDA mismatch，于是读取 requirements、检查版本、调整环境、重新运行。
Evaluate：论文 Accuracy = 92.4%，当前复现 = 86.1%，差距明显。
Reflection：检查 preprocessing、checkpoint、随机种子、超参数是否一致。
Replan：重新安排下一步——优先核对数据预处理和 checkpoint。
7. 三种范式怎么选？
| 范式 | 核心问题 | 最适合 | 主要风险 |
|---|---|---|---|
| ReAct | 下一步依赖环境反馈 | 搜索、代码、网页、工具操作 | 容易局部最优、步骤发散 |
| Plan-and-Solve | 任务太长，需要全局结构 | 研究、复杂项目、长流程 | 计划可能过时 |
| Reflection | 结果可能错误，需要修正 | 代码、数学、可验证任务 | 纯自评可能重复犯错 |
| 组合 | 复杂真实任务 | 长时 Agent、科研复现、Coding Agent | 成本与复杂度更高 |
不要把架构设计成“所有任务都 Plan + Reflect + Multi-Agent”。控制策略越多，成本、延迟、失败点越多。先从任务真正需要的能力开始。
8. 快速验收
Q1：修复代码时，每次根据 pytest 错误决定下一步，最核心的范式是什么？
ReAct。因为下一步依赖环境 Observation。
Q2：一个 20 步科研任务为什么不应该只靠 ReAct？
因为容易陷入局部操作并丢失全局目标，应先引入 Planning。
Q3：Reflection 为什么最好接外部验证？
因为同一个模型的生成错误和自评错误可能相关。pytest、编译器、指标等能提供更独立的证据。
Q4：最完整的一条控制链是什么？
Plan → ReAct → Evaluate → Reflect → Replan / Finish。
9. 一页总结
ReAct = Act ↔ Observe
Plan-and-Solve = Plan → Execute
Reflection = Generate → Evaluate → Improve
真实长任务 = Plan → ReAct → Evaluate → Reflect → Replan
动态环境
优先想到 ReAct
复杂长任务
优先想到 Plan
结果可验证
优先加入 Reflection + External Feedback
下一份：第 6～7 章——LangGraph / AutoGen / AgentScope，以及 Agent Framework 内部的 LLM、Message、Tool、State、Runtime 到底怎么组织。