大模型应用开发实战（4）——智能体经典范式
🤵♂️ 个人主页：小李同学_LSH的主页
✍🏻 作者简介：LLM学习者
🐋 希望大家多多支持，我们一起进步！😄
如果文章对你有帮助的话，
欢迎评论 💬点赞👍🏻 收藏 📂加关注+
目录
一、先把概念捋顺：Workflow 不等于 Agent
二、智能体经典范式的总体地图
三、ReAct：边想边做，是最像“原型 Agent”的范式
1. ReAct 的工作流
2. 为什么 ReAct 强？
3. ReAct 的优势和短板
四、Plan-and-Solve：先谋后动，适合长链路结构化任务
1. Plan-and-Solve 的形式化表达
2. 为什么它有用？
3. Plan-and-Solve 的优势和短板
五、Reflection / Reflexion：给智能体加“复盘”能力
1. Reflection 的三阶段
2. 它为什么重要？
3. Reflection 的优势和短板
六、ToT 是经典范式外的重要补充
ToT 适合什么？
四种范式怎么选？一张表看懂
真正落地时，往往不是“选一种”，而是“组合”
这两年，“Agent”几乎成了大模型应用开发里最热的词之一。
但只要你真正开始做项目，很快就会发现一个现实问题：
智能体不是只有一种写法。
有的系统喜欢边想边做，有的系统先规划再执行，有的系统先给出答案再自我反思，还有的系统会探索多条推理路径再回溯选择。
如果不把这些经典范式分清楚，后面你做项目时就很容易陷入一种状态：
- 工具接了一堆
- 调用链路越来越长
- 但系统并没有变聪明，反而越来越难调
单智能体的经典范式三条主线：ReAct、Plan-and-Solve、Reflection
与此同时，更广义的研究和工业实践又常常把智能体范式总结为工具使用、规划、反馈学习三类，并进一步区分workflow和agent这两种系统形态。ReAct 论文强调“推理和行动交错进行”，Plan-and-Solve 强调“先规划再求解”，Reflexion 则强调“通过语言反馈自我纠错”；而 Anthropic 在工程实践里则建议，大多数应用应先从更简单、可组合的 workflow 开始，只有在确实需要灵活决策时再走向更自治的 agent。
所以这篇文章我想做的，不只是“介绍几个名词”，而是帮你回答一个更实际的问题：
面对真实业务任务，ReAct、Plan-and-Solve、Reflection 到底分别解决什么问题？什么时候该用哪一种？能不能组合？
一、先把概念捋顺：Workflow 不等于 Agent
在聊具体范式之前，先把一个特别容易混淆的问题讲清楚：
很多人把所有“调用大模型 + 调工具”的系统都叫 Agent，但从工程角度，这其实不够精确。
Anthropic 给出了一个非常实用的区分：
- Workflow：LLM 和工具按预定义代码路径被编排
- Agent：LLM 会动态决定自己的过程和工具使用方式，拥有更强的自主性
而且他们特别强调，构建应用时应先从最简单可行的方案出发，很多场景优化单次 LLM 调用、加上检索和 in-context 示例就已经足够；agentic systems 往往是“用更高的延迟与成本，换更好的任务表现”。
这个视角特别重要，因为它决定了你后面怎么选范式。很多时候，你不是在选“最酷的 agent”，而是在选：
- 是要一个可控的固定流程
- 还是一个会临场决策的动态系统
不是所有“带工具的大模型系统”都必须做成 Agent。工程上经常先从 Workflow 起步，再在必要时升级成更自治的 Agent。这个区分与 Anthropic 的工程建议是一致的。
二、智能体经典范式的总体地图
经典智能体范式大致可以对应三条主线：
- 工具使用型：代表是 ReAct
- 规划型：代表是 Plan-and-Solve
- 反馈学习 / 自我修正型：代表是 Reflection / Reflexion
更广义地说，还有一类偏“搜索型”的思路，例如 Tree of Thoughts，它强调不是沿一条推理链一直走下去，而是尝试多条路径、评估、回溯、再选择。综述论文也把当前 LLM-based agents 的 prominent paradigms 总结为 tool use、planning 和 feedback learning 三大类。
三、ReAct：边想边做，是最像“原型 Agent”的范式
ReAct 的名字来自Reason + Act。
它的核心思想不是先把计划一次性想完，而是：
让模型在推理和行动之间交替进行。
ReAct 论文把这一点说得非常明确：它让 LLM 以一种交错（interleaved）的方式生成 reasoning traces 和 task-specific actions；推理有助于更新和维护行动计划，行动又能帮助模型从外部知识库或环境中拿到更多信息。
1. ReAct 的工作流
最经典的 ReAct 循环可以写成：
这其实就是一个“边思考、边试探、边修正”的循环。
2. 为什么 ReAct 强？
因为很多真实任务不是静态题目，而是需要外部信息。
例如：
- 查实时天气
- 搜最新新闻
- 查订单状态
- 调地图接口
- 查询数据库
如果没有行动能力，模型只能“靠记忆猜”；一旦它能先想、再调用工具、再根据返回结果继续想，它就开始具备真正的“交互式问题求解”能力。ReAct 论文也指出，在问答和事实验证里，它通过与 Wikipedia API 的交互缓解了幻觉和错误传播；在 ALFWorld 与 WebShop 这类交互决策任务上也优于多种基线。
ReAct 不是“先想完再做”，而是“想一点、做一点、看结果、再继续想”。这正是它最适合探索型和工具密集型任务的原因。
3. ReAct 的优势和短板
优势：
- 动态适应环境变化
- 天然适合工具调用
- 推理链清晰，便于调试和追踪
- 对开放任务更灵活
短板：
- 调用轮数多，成本更高
- 容易在长任务中走偏
- 工具多时，工具选择本身会成为新问题
- 依赖输出格式约束，否则解析脆弱
这也是为什么很多 ReAct 系统一开始很惊艳，但一上线就暴露出“工具选错、参数填错、调用链太长”的工程问题。
四、Plan-and-Solve：先谋后动，适合长链路结构化任务
如果说 ReAct 是“边走边看”，那 Plan-and-Solve 就是“先画路线图再出发”。
Plan-and-Solve Prompting 最初是为了解决 Zero-shot-CoT 中的missing-step errors提出的。论文摘要里直接说，它包含两个核心组成部分：先制定计划，把整个任务拆成更小的子任务；再按照计划逐一执行这些子任务。Hello-Agents 也把这种两阶段流程形式化成了“规划阶段”和“执行阶段”。
1. Plan-and-Solve 的形式化表达
2. 为什么它有用？
因为很多任务并不需要“边走边探测环境”，而是更需要：
- 清晰分解步骤
- 稳定按顺序执行
- 避免漏步骤
- 避免中途跑偏
比如：
- 数学应用题
- 长文结构化写作
- 报告生成
- 固定流程的数据清洗
- 明确阶段性的业务流程
论文中指出，Plan-and-Solve 是为了改善 Zero-shot-CoT 的 missing-step、calculation 和 semantic misunderstanding 等问题，并在多个推理数据集上优于 Zero-shot-CoT。
Plan-and-Solve 的核心不是“更会调用工具”，而是“更会先把事情拆开”。在结构清晰、步骤明确的长任务里，它往往比 ReAct 更稳。
3. Plan-and-Solve 的优势和短板
优势：
- 目标一致性更强
- 适合长链条、强结构任务
- 可解释性更好
- 更容易做中间步骤审查
短板：
- 计划往往是静态的
- 一旦中途条件变化，容易失效
- 不如 ReAct 灵活
- 在需要大量外部交互的场景中，可能不如边想边做高效
它特别适合逻辑路径确定、内部推理密集的任务，而 ReAct 更适合探索性和需要外部工具输入的任务。
五、Reflection / Reflexion：给智能体加“复盘”能力
在真实项目里，一个非常常见的痛点是：
模型第一版答案往往不是最好的。
这时候，如果你只是“让它再答一遍”，效果往往很有限。
更强的做法是：让它先产出初稿，再让另一个过程专门审查、批评、指出问题，然后再根据反馈修订。
这就是 Reflection 的核心思路。Hello-Agents 把它概括成一个post-hoc 自我校正循环：执行 → 反思 → 优化。Reflexion 论文则更进一步，把它表述为：不通过更新模型权重，而是通过语言反馈来强化 agent；agent 会针对任务反馈进行 verbal reflection，并把反思文本保存在 episodic memory 中，用于后续试次的决策。
1. Reflection 的三阶段
- Execution：先生成一个初稿或初始行动轨迹
- Reflection：像评审一样指出事实错误、逻辑漏洞、遗漏、效率问题
- Refinement：根据反馈修订出更好的版本
可以简单写成：
2. 它为什么重要？
因为很多任务不是“先有外部信息缺失”，而是“第一版质量不够高”。
例如：
- 代码生成
- 报告写作
- 法律条文整理
- 研究方案设计
- 决策建议生成
在这类任务中，Reflection 的价值不是外部探索，而是质量提升。
Reflection 不强调“多查资料”，而强调“多做一轮高质量复盘”。对于高价值、高准确性要求的场景，它往往比单次生成更可靠。
3. Reflection 的优势和短板
优势：
- 能显著提升最终质量
- 有利于减少逻辑漏洞
- 特别适合代码、报告、方案类任务
- 容易结合人工审查
短板：
- 成本与延迟更高
- 容易出现“反思过度”
- 如果反馈质量不高，修订可能无效
- 对实时性要求高的场景不够友好
当应用场景需要快速响应，或者“大致正确”就够时，ReAct 或 Plan-and-Solve 可能更有性价比。
六、ToT 是经典范式外的重要补充
但从更广的研究视角看，Tree of Thoughts（ToT）也是一个非常重要的补充。
ToT 的核心不是“单条链式思考”，而是：
把中间推理步骤当成一个个 thought 节点，允许模型探索多条不同路径，并通过自评与回溯来选择下一步。
论文摘要直接写到：ToT 允许模型通过考虑多种不同推理路径、自我评估选择、必要时前瞻和回溯来进行更审慎的决策。
ToT 适合什么？
- 需要搜索的任务
- 需要 lookahead 的任务
- 初始决策非常关键的任务
- 单条 CoT 容易走死胡同的任务
所以如果你把智能体范式理解为一个更大的光谱，ToT 可以看成是：
- 在 ReAct 之上，更强调搜索与分支
- 在 Plan-and-Solve 之上，更强调路径评估与回退
四种范式怎么选？一张表看懂
| 范式 | 核心思想 | 优势 | 短板 | 最适合的任务 |
|---|---|---|---|---|
| ReAct | Thought-Action-Observation 交替循环 | 灵活、适合工具调用、适应环境变化 | 成本高、长任务易漂移 | 搜索、查询、实时信息、外部交互 |
| Plan-and-Solve | 先规划后执行 | 稳定、结构清晰、可解释性好 | 静态计划不够灵活 | 数学推理、报告生成、明确步骤任务 |
| Reflection / Reflexion | 执行后反思再优化 | 质量高、可靠性强 | 更慢、更贵 | 代码、方案、报告、关键决策 |
| ToT | 多路径搜索与评估 | 擅长搜索和全局决策 | 实现复杂、开销更高 | 博弈、复杂推理、需要回溯的任务 |
真正落地时，往往不是“选一种”，而是“组合”
这是做项目最关键的一点。
在真实应用里，你很少只用一种范式走到底。更常见的是：
- ReAct + Reflection：先边想边查，最后再复盘润色
- Plan-and-Solve + ReAct：先给高层计划，再让执行阶段动态用工具
- Plan-and-Solve + Reflection：先保证结构，再提升质量
- ReAct + ToT：对关键节点做分支探索，再决定下一步行动
真正工程化的 agent 往往不是单一范式，而是组合式架构：计划解决方向问题，ReAct 解决动态交互问题，Reflection 解决质量问题。
当一个大模型不再只是回答一句话，而是要持续完成任务时，我们该如何组织它的思考、行动、反馈与修正？