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。
一个务实建议
很多项目一开始不需要把三者都做全。
更稳妥的顺序通常是：
- 先把任务主流程做通
- 再看是否真的缺外部信息，如果缺就加 RAG
- 再看是否真的经常输出不稳，如果有就加 Reflection
- 任务复杂到一定程度，再增强 Planning
不要一开始就把所有“高级能力”堆进去。
小结
你可以再记一遍这三个关键词的职责：
- Planning：安排动作
- Reflection：检查质量
- RAG：补充信息
这三个概念一旦分清，后面看 Agent 框架和系统设计时就不会总觉得它们像一团黑话。
下一篇建议继续看：