大模型应用开发实战（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 给出了一个非常实用的区分WorkflowLLM 和工具按预定义代码路径被编排AgentLLM 会动态决定自己的过程和工具使用方式拥有更强的自主性而且他们特别强调构建应用时应先从最简单可行的方案出发很多场景优化单次 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 论文则更进一步把它表述为不通过更新模型权重而是通过语言反馈来强化 agentagent 会针对任务反馈进行 verbal reflection并把反思文本保存在 episodic memory 中用于后续试次的决策。1. Reflection 的三阶段Execution先生成一个初稿或初始行动轨迹Reflection像评审一样指出事实错误、逻辑漏洞、遗漏、效率问题Refinement根据反馈修订出更好的版本可以简单写成2. 它为什么重要因为很多任务不是“先有外部信息缺失”而是“第一版质量不够高”。例如代码生成报告写作法律条文整理研究方案设计决策建议生成在这类任务中Reflection 的价值不是外部探索而是质量提升。Reflection 不强调“多查资料”而强调“多做一轮高质量复盘”。对于高价值、高准确性要求的场景它往往比单次生成更可靠。3. Reflection 的优势和短板优势能显著提升最终质量有利于减少逻辑漏洞特别适合代码、报告、方案类任务容易结合人工审查短板成本与延迟更高容易出现“反思过度”如果反馈质量不高修订可能无效对实时性要求高的场景不够友好当应用场景需要快速响应或者“大致正确”就够时ReAct 或 Plan-and-Solve 可能更有性价比。六、ToT 是经典范式外的重要补充但从更广的研究视角看Tree of ThoughtsToT也是一个非常重要的补充。ToT 的核心不是“单条链式思考”而是把中间推理步骤当成一个个 thought 节点允许模型探索多条不同路径并通过自评与回溯来选择下一步。论文摘要直接写到ToT 允许模型通过考虑多种不同推理路径、自我评估选择、必要时前瞻和回溯来进行更审慎的决策。ToT 适合什么需要搜索的任务需要 lookahead 的任务初始决策非常关键的任务单条 CoT 容易走死胡同的任务所以如果你把智能体范式理解为一个更大的光谱ToT 可以看成是在 ReAct 之上更强调搜索与分支在 Plan-and-Solve 之上更强调路径评估与回退四种范式怎么选一张表看懂范式核心思想优势短板最适合的任务ReActThought-Action-Observation 交替循环灵活、适合工具调用、适应环境变化成本高、长任务易漂移搜索、查询、实时信息、外部交互Plan-and-Solve先规划后执行稳定、结构清晰、可解释性好静态计划不够灵活数学推理、报告生成、明确步骤任务Reflection / Reflexion执行后反思再优化质量高、可靠性强更慢、更贵代码、方案、报告、关键决策ToT多路径搜索与评估擅长搜索和全局决策实现复杂、开销更高博弈、复杂推理、需要回溯的任务真正落地时往往不是“选一种”而是“组合”这是做项目最关键的一点。在真实应用里你很少只用一种范式走到底。更常见的是ReAct Reflection先边想边查最后再复盘润色Plan-and-Solve ReAct先给高层计划再让执行阶段动态用工具Plan-and-Solve Reflection先保证结构再提升质量ReAct ToT对关键节点做分支探索再决定下一步行动真正工程化的 agent 往往不是单一范式而是组合式架构计划解决方向问题ReAct 解决动态交互问题Reflection 解决质量问题。当一个大模型不再只是回答一句话而是要持续完成任务时我们该如何组织它的思考、行动、反馈与修正