---
layout: default
title: Planning、Reflection、RAG 分别解决什么问题
description: 分清三个高频概念在 Agent 系统中的职责
eyebrow: Agent Basic / 07
---

# Planning、Reflection、RAG 分别解决什么问题

这是 Agent 学习中另一个高频混淆点。

很多教程会同时提到：

- Planning
- Reflection
- RAG

然后把它们一起包装成“高级 Agent 能力”。

但如果不拆清楚，你很容易出现下面这种情况：

- 该用检索的时候去做规划
- 该做自检的时候去补知识库
- 系统真正缺的是信息，结果你一直让模型“多思考一下”

## 先给一句最短定义

你可以先这样记：

- `Planning`：解决“下一步该做什么”
- `Reflection`：解决“刚才做得对不对”
- `RAG`：解决“我现在缺什么信息”

这三者都很常见，但职责完全不同。

## 1. Planning：组织执行路径

Planning 关注的是任务推进方式。

例如：

- 先查价格还是先查新闻
- 哪些子任务要先做
- 当前信息不足时下一步该用哪个工具
- 整个任务要分几步推进

Planning 的本质是：

> 把目标拆成后续动作。

它更关心行动顺序，而不是知识内容本身。

### 什么时候需要 Planning

当任务满足下面特征时，Planning 会很有用：

- 多步任务
- 路径不固定
- 工具很多
- 中间结果会影响下一步

如果任务很短、步骤固定，那你可能根本不需要显式 Planning。

## 2. Reflection：检查结果是否靠谱

Reflection 更像是一种回看和自检。

例如：

- 当前结论是否有证据支持
- 刚才那次工具调用有没有真正解决问题
- 输出是否满足目标
- 有没有逻辑跳步或遗漏

Reflection 的本质是：

> 不是继续往前冲，而是停下来检查刚才做得对不对。

### 什么时候需要 Reflection

当任务结果质量很重要，而且模型经常会：

- 过度自信
- 逻辑跳步
- 工具用得不充分
- 输出形式对了但内容不扎实

这时 Reflection 会有价值。

但要注意，Reflection 不是免费午餐。  
它会增加：

- token 成本
- 执行时间
- 系统复杂度

所以不是所有任务都要加一轮“反思”。

## 3. RAG：补充外部信息

RAG 解决的是一个完全不同的问题：

> 模型当前不知道，或者上下文里没有，但系统可以从外部知识中取回来。

例如：

- 公司内部文档
- 历史研究报告
- 产品说明
- 外部知识库
- 市场资料

RAG 的重点不是“想更久”，而是“拿更多相关信息”。

### 什么时候需要 RAG

如果任务高度依赖外部知识，而且这些知识：

- 不在模型训练数据里
- 不足够新
- 不足够准
- 不适合全部塞进提示词

那 RAG 往往就很必要。

## 一个容易混淆的例子

假设任务是：

> 分析某个币种今天的风险。

系统遇到“信息不足”时，可能有三种不同处理方式：

### Planning 的动作

决定下一步去查什么：

- 先查价格异常
- 再查新闻
- 再查链上数据

### Reflection 的动作

检查当前结论是否站得住：

- 只有价格波动就下高风险结论，证据够吗
- 当前解释是否太武断

### RAG 的动作

补回系统缺失的信息：

- 取回历史风控规则
- 召回某类异常模式说明
- 读取已有研究资料

你会发现三者根本不是一回事。

## 不要把“缺信息”误判成“要多思考”

这是实际系统里很常见的错误。

如果模型当前缺的是外部知识，你让它 Planning 也没用。  
如果系统当前缺的是结果校验，你补 RAG 也没用。  
如果真正缺的是任务拆解，你一直 Reflection 也没用。

所以在设计系统时，应该先判断当前缺的是哪一类能力：

- 缺路径组织
- 缺结果校验
- 缺外部信息

对应地选择 Planning、Reflection 或 RAG。

## 一个务实建议

很多项目一开始不需要把三者都做全。

更稳妥的顺序通常是：

1. 先把任务主流程做通
2. 再看是否真的缺外部信息，如果缺就加 RAG
3. 再看是否真的经常输出不稳，如果有就加 Reflection
4. 任务复杂到一定程度，再增强 Planning

不要一开始就把所有“高级能力”堆进去。

## 小结

你可以再记一遍这三个关键词的职责：

- Planning：安排动作
- Reflection：检查质量
- RAG：补充信息

这三个概念一旦分清，后面看 Agent 框架和系统设计时就不会总觉得它们像一团黑话。

下一篇建议继续看：

- [单 Agent 和多 Agent 的边界](../08-single-vs-multi-agent/index.html)