1 你以为 Agent 就是会调 API 的聊天机器人如果你最近在技术圈子里混大概率听过这样的对话“你搞 Agent 了吗”“搞了啊就是让大模型调工具嘛加个搜索、加个计算器完事了。”“哇好厉害”这段对话的问题在于——它把 Agent 理解成了会按按钮的大模型。但真正的 Agent核心价值不在于能调几个 API而在于它怎么思考、怎么行动、怎么规划、怎么反思。换句话说Agent 真正的灵魂不是工具而是它的工作方法。这篇文章就讲清楚三种经典范式ReAct边想边干、Plan-and-Solve谋定后动、Reflection交稿前自己审三遍。读完之后再看各种 Agent 框架你就能真正看懂智能体到底是怎么工作的。2 先搞清楚一个问题Agent 和普通大模型到底差在哪2.1 普通大模型一个超级学霸但只能一问一答你可以把普通大模型想象成一个学识渊博但非常被动的人。你问他地球到月球有多远他脱口而出384,400 公里。你再问“那如果我要造火箭去月球需要多少燃料”他可能会给你一个基于训练数据的估算但这个数字准不准他自己也不知道。因为他不能去查 NASA 的最新数据不能打开计算器精确运算更不能说等等我觉得这个问题的前提条件需要再确认一下。他只能基于记忆中见过什么来回答。这就是普通大模型的局限知识有截止日期无法与真实世界交互不能主动拆解复杂任务。2.2 Agent学霸 工具箱 工作方法Agent 在学霸的基础上多了两样东西第一工具箱。它能调用搜索引擎查最新信息用计算器做精确运算访问数据库读取业务数据甚至操作浏览器、发邮件、写文件。第二也是更重要的——工作方法。它不是拿到问题就直接回答而是会判断当前信息够不够要不要先搜索一下这个任务要不要拆成几步生成的结果靠不靠谱要不要再检查一遍这种判断—行动—观察—调整的能力才是 Agent 和普通大模型的本质区别。而不同的工作方法就构成了我们今天要讲的三种范式。3 ReAct边想边干见招拆招3.1 一句话理解 ReActReAct Reasoning推理 Acting行动。翻译成人话就是想一步做一步看结果再调整。如果你是一个喜欢边走边看的人那你天生就是一个 ReAct 选手。3.2 从一次旅行说起假设你打算周末去一个从没去过的城市玩一天。你会在周一就把每个小时干什么都安排得死死的吗大概率不会。因为你不知道那天天气如何、景点是否开放、网红餐厅要不要排队、地铁线路有没有临时调整。你更可能的做法是先想这个城市有哪些值得去的地方去查周末天气怎么样看到结果周六有雨周日晴天。调整计划户外景点挪到周日周六安排室内活动。再查博物馆需不需要预约发现预约满了。继续调整换一个备选景点。整个过程你没有提前规划好一切而是根据每一步获取到的新信息不断调整下一步行动。这就是 ReAct 的精髓。3.3 ReAct 的技术流程在 Agent 的技术语境下ReAct 的工作流程是一个不断循环的三步Thought思考 → Action行动 → Observation观察 → 回到 Thought ...具体来说Thought思考Agent 分析当前掌握的信息判断下一步应该做什么。这一步是纯粹的推理不涉及任何工具调用。Agent 会想“用户问的是最新产品价格我的训练数据可能已经过时了需要搜索一下。”Action行动Agent 根据思考结果选择并调用合适的工具。可能是搜索引擎、计算器、数据库查询、API 调用甚至代码执行。Observation观察工具返回结果后Agent 把这些结果当作新的事实依据重新进入思考阶段。这个循环会一直持续直到 Agent 判断信息已经足够可以给出最终答案为止。3.4 一个更贴近开发的例子用户问 Agent“帮我整理一下最近适合学生党的轻薄本推荐预算 4000-6000 元。”这个问题模型记忆中的信息大概率是过时的。电脑价格会波动新品会发布老款会降价。一个 ReAct Agent 的处理过程可能是这样的第一轮Thought需要最新的笔记本推荐信息先搜索一下近期热门轻薄本。Action调用搜索引擎搜索2026 年学生轻薄本推荐 4000-6000 元。Observation得到了若干品牌和型号的推荐列表。第二轮Thought列表里有七八款但不知道哪些真正适合学生。学生的核心需求是轻便、续航长、性能够用、性价比高。我来筛选一下。Action针对其中几款搜索详细评测和用户反馈。Observation获取到了各款的重量、续航、性能跑分、用户口碑。第三轮Thought信息差不多了但有两款价格近期波动比较大再确认一下实时价格。Action查询电商平台实时价格。Observation发现其中一款正在做活动性价比突然变高了。第四轮Thought现在信息充分了可以生成推荐了。Action输出最终推荐结果。你看Agent 不是一次性把答案想出来的而是通过多次与外部世界交互逐步拼出了完整答案。3.5 ReAct 的三大优势第一环境适应性强。外部信息变了Agent 可以通过工具获取最新数据。它不会被训练数据截止日期限制住。第二动态纠错能力强。第一次搜索关键词不好没关系换一个再搜。工具返回不完整可以继续追问。这种见招拆招的能力让 Agent 在面对不确定性时非常灵活。第三可解释性好。通过 Thought 链你可以看到 Agent 每一步在想什么、为什么选择调用这个工具、看到结果后又做了什么判断。这种透明度对于调试和信任建立非常重要。3.6 ReAct 的两个坑当然ReAct 不是万能的。第一个坑成本高。每一轮思考—行动—观察都需要调用一次大模型如果任务复杂可能需要循环五六次甚至更多。这意味着更多的 API 调用、更长的响应时间、更高的 Token 消耗。第二个坑缺少全局视野。ReAct 的本质是走一步看一步这在探索性任务中是优势但在步骤明确、结构复杂的任务中就成了劣势。它可能会在某些环节反复尝试甚至偏离最优路径——就像一个没有导航的司机虽然最终也能到目的地但可能绕了不少弯路。3.7 ReAct 小结一句话总结ReAct 是一个边走边查边判断的执行者最适合探索性强、需要实时信息、依赖外部工具的任务。如果用游戏角色类比ReAct 就像是一个探险家——没有详细地图但有指南针和望远镜每走一步都在观察地形、调整方向。4 Plan-and-Solve谋定而后动步步为营4.1 一句话理解 Plan-and-Solve如果说 ReAct 是边走边看那 Plan-and-Solve 就是先画好路线图再按图索骥。它的核心逻辑是两个阶段Planning规划先把任务拆解成清晰的步骤。Solving执行按照步骤逐步完成。4.2 从一次 PPT 汇报说起假设你要做一个课程项目的汇报 PPT。如果你一上来就打开 PowerPoint 开始做大概率会出现这种情况第一页写了项目背景。第二页突然想到一个技术亮点赶紧写上。第三页又觉得应该先讲需求分析。做到一半发现顺序乱了开始大调整。最后匆匆收尾总结页只有两行字。但如果你先花十分钟列一个大纲呢项目背景与问题定义需求分析与用户画像系统架构设计核心功能展示技术亮点与创新点总结与未来展望有了这个框架再逐页填充内容效率和质量都会高得多。这就是 Plan-and-Solve 的核心价值面对复杂任务先结构化拆解再逐步执行远比想到哪做到哪更靠谱。4.3 Plan-and-Solve 的技术流程在 Agent 的技术实现中Plan-and-Solve 分为两个明确阶段阶段一Planning规划Agent 拿到任务后不是立刻动手而是先生成一个执行计划。这个计划会回答以下问题这个任务可以拆成哪几个子任务每个子任务的先后顺序是什么哪些子任务之间有依赖关系最终输出应该如何组织阶段二Solving执行按照计划中的步骤逐一完成。每完成一步Agent 都会对照计划确认进度和方向。4.4例如用户说“帮我设计一个校园二手交易平台的后端方案。”这是一个典型的复杂任务。如果 Agent 直接开写很容易变成一锅粥一会说数据库设计一会跳到接口定义突然又插了一段安全方案。Plan-and-Solve 会先让 Agent 生成这样的计划执行计划明确核心业务模块用户模块、商品模块、订单模块、消息模块、支付模块。设计数据库表结构每个模块的实体、字段、关联关系。设计核心 API 接口RESTful 风格列出关键接口及其入参出参。考虑非功能性需求权限控制、数据安全、异常处理、日志记录。分析高并发场景秒杀、热门商品、订单峰值的处理方案。总结方案亮点与可优化点。有了这个计划后Agent 再逐步展开每一部分的内容。最终输出的方案结构清晰、逻辑完整、覆盖全面——就像一份真正经过深思熟虑的技术文档而不是即兴发挥的随笔。4.5 Plan-and-Solve 的深层价值Plan-and-Solve 的价值不仅仅是有条理它还解决了大模型的一个核心痛点长文本生成时的逻辑漂移问题。你可能注意到如果让大模型一次性生成一篇很长的文章或方案前半部分和后半部分的逻辑连贯性往往会下降。这是因为模型在生成过程中注意力会逐渐偏移。Plan-and-Solve 通过先拆解再执行的方式相当于给模型一个导航仪。每一步都只需要专注于当前子任务而不需要在脑子里同时装着整个任务的全貌。这大大降低了逻辑漂移的风险。4.6 Plan-and-Solve 的三大优势第一结构性强。输出结果天然有清晰的层次和逻辑特别适合需要方案感的任务。第二稳定性高。因为执行路径是预先规划好的不会像 ReAct 那样出现绕弯路或跑偏的情况。第三可复用性好。同一个任务的计划模板可以被复用。比如设计后端方案的计划对不同项目都可以套用类似的结构。4.7 Plan-and-Solve 的两个风险第一个风险计划本身的错误会被放大。如果规划阶段就出了问题后面执行得再认真也是在错误方向上越走越远。比如设计后端方案时计划中遗漏了权限控制这个模块那后面所有内容都不会涉及安全设计。而在 ReAct 范式中这种遗漏可能会在后续搜索或工具调用时被意外发现并弥补。第二个风险灵活性不足。Plan-and-Solve 假设任务的执行路径是可以提前规划的但现实中很多任务充满了不确定性。如果执行过程中发现计划需要大改Agent 可能缺乏动态调整的能力。4.8 Plan-and-Solve 小结一句话总结Plan-and-Solve 是一个先画蓝图再施工的规划者最适合结构清晰、步骤明确、逻辑密集的任务。如果继续用游戏角色类比Plan-and-Solve 就像是一个建筑师——在动第一块砖之前已经有了完整的施工图纸。每一步施工都严格按照图纸执行确保最终建筑的结构稳固、功能完整。5 Reflection交稿之前自己先审三遍5.1 一句话理解 ReflectionReAct 解决怎么边做边调Plan-and-Solve 解决怎么先拆再做而 Reflection 解决的是一个完全不同的问题结果出来了但不够好怎么办Reflection 就是给 Agent 装上一个内置审稿人生成结果后不是直接交付而是自己检查一遍、发现问题、修改优化然后再检查、再优化——直到质量达标。5.2 其实你每天都在用 ReflectionReflection 听起来很高级但其实你在日常工作中一直在用它写作文第一版叫初稿改完之后叫终稿有些人的终稿和初稿几乎不是同一篇文章。写代码第一版写完能跑然后做 Code Review发现命名不规范、边界条件没覆盖、性能可以优化于是重写一版。做题算完答案之后验算一遍发现中间某一步算错了赶紧改过来。写方案交付前检查一遍发现有个重要场景遗漏了赶紧补上。发邮件写完之后读一遍觉得措辞不太合适改了几个词再发出去。这些行为的本质都是一样的第一版不求完美但求有然后通过反复审查和修改让结果从能用变成好用。Reflection 就是把这种人类习以为常的自我迭代能力赋予了 Agent。5.3 Reflection 的技术流程Reflection 的工作流程分为三个核心阶段Execution执行 → Reflection反思 → Refinement优化 → 回到 Reflection ...Execution执行Agent 先生成一个初始结果。这个结果可以是代码、文章、方案、分析报告——任何类型的输出。Reflection反思Agent 切换到审查者角色对初始结果进行严格审查。它会问自己一系列问题结果是否正确有没有事实性错误逻辑是否连贯有没有前后矛盾是否覆盖了所有重要方面有没有遗漏有没有更优的实现方式是否符合目标受众的需求Refinement优化根据反思阶段发现的问题Agent 对结果进行针对性修改。这个反思—优化的循环可以执行多轮直到结果质量达到预期标准。5.4 代码场景写一个限流工具类用户让 Agent 写一段代码“用 Java 实现一个接口限流工具类支持滑动窗口算法。”第一版ExecutionAgent 生成了一段代码。能编译、能运行、基本逻辑也对了。审查阶段ReflectionAgent 切换成高级工程师视角对代码进行审查并发安全多个线程同时调用时计数器的原子性有保证吗用了AtomicInteger还是普通的int异常处理如果传入的参数是 null 或者负数会抛异常吗有友好的错误提示吗边界条件窗口大小为 0 或者 1 的时候算法还正确吗扩展性限流策略是硬编码的还是可以通过策略模式替换的可测试性核心逻辑是否容易写单元测试代码规范变量命名是否清晰关键逻辑有没有注释第二版RefinementAgent 根据上述反馈重写代码引入ConcurrentHashMap保证线程安全、增加参数校验、抽取策略接口提升扩展性、补充关键注释。再来一轮可选Agent 甚至可以再审查一次第二版代码看看还有没有遗漏——比如是否考虑了分布式场景、是否需要引入 Redis 做跨实例限流。这个过程的价值远不只是修了几个 Bug。它让最终输出从能用变成了可靠从Demo 级别变成了生产级别。5.5 写作场景写一篇公众号文章再来看一个非代码场景。用户让 Agent 写一篇关于程序员如何保护颈椎的公众号文章。第一版文章写完了信息完整有病因分析、有动作建议、有就医提醒。但读起来像一篇医学百科——正确但无趣。审查阶段Agent 从读者体验角度重新审视开头第一句话是颈椎病是一种常见的退行性疾病——读者到这就划走了。能不能换成一个更有代入感的开头比如你有没有过这种体验加完班站起来脖子像被灌了水泥段落长度有好几段超过 200 字在手机屏幕上就是一整面文字墙。能不能拆短重点突出关键建议混在大段文字里不够醒目。能不能加粗、加小标题例子和比喻全程都是专业术语能不能用更生活化的比喻比如你的颈椎就像一个 24 小时值班的保安你越不理它它越会闹脾气。结尾平平淡淡的希望对你有帮助——能不能给读者一个立刻能做的行动比如现在就放下手机做三个颈部环绕动作。第二版根据反馈重写文章风格大变开头有共鸣感中间有节奏感结尾有行动感。这就是 Reflection 的威力——它不只是纠错更是从能用到好用的质变过程。5.6 Reflection 的三大核心价值第一内置纠错回路。Reflection 不依赖外部工具来发现问题而是让 Agent 自己成为自己的质检员。这种自我审查能力在很多没有外部反馈渠道的场景中尤其重要。第二提升最终质量。对于代码、方案、报告、文章这类质量没有上限的任务Reflection 提供了持续优化的机制。每一次反思循环都在把结果推向更高的质量标准。第三形成迭代记忆。Agent 不仅知道最终答案还保留了初稿—反馈—修改的完整过程。这种过程信息对于理解为什么最终方案是这样的非常有价值也为后续的多轮优化提供了基础。5.7 Reflection 的成本与适用边界Reflection 不是免费的午餐。每一次反思 优化循环至少需要额外调用两次大模型一次审查一次修改。如果反复迭代三四轮成本和耗时都会显著增加。所以Reflection 本质上是一种用时间和成本换质量的策略。适合使用 Reflection 的场景生产级代码生成正式技术报告或方案复杂逻辑分析与推理高质量内容创作关键业务决策辅助不太适合的场景快速问答“今天星期几”简单的格式转换对质量要求不高的临时任务简单来说如果你只需要一个60 分答案直接生成就够了但如果你需要90 分答案Reflection 几乎是必经之路。5.8 Reflection 小结一句话总结Reflection 是一个自带审稿人和质检员的智能体最适合对准确性、可靠性和最终质量要求极高的场景。如果用游戏角色类比Reflection 就像是一个铸剑师——第一版是粗锻第二版是精磨第三版是淬火。每一轮都不是推倒重来而是在上一版基础上让作品变得更锋利、更坚韧、更完美。6 三种范式的深度对比什么时候该用谁6.1 核心差异一句话版讲到这里我们可以用最简洁的方式区分三种范式ReAct解决的是信息不够的时候怎么办答案是——去行动、去获取、去交互。Plan-and-Solve解决的是任务太复杂的时候怎么办答案是——先拆解、再规划、后执行。Reflection解决的是结果不够好的时候怎么办答案是——自己审、找问题、再优化。6.2 全方位对比表维度ReActPlan-and-SolveReflection核心思想边想边做动态调整先规划后执行先完成再优化形象比喻探险家建筑师铸剑师核心能力环境感知与动态适应结构化拆解与有序执行自我审查与持续优化工作模式循环式想→做→看→想线性式规划→执行迭代式生成→审查→优化适合任务类型探索性、实时性、工具密集型结构性、多步骤、逻辑密集型质量敏感、高精度要求典型场景搜索问答、数据分析、信息检索报告撰写、方案设计、代码架构代码审查、文章润色、方案优化优势灵活、适应性强、可解释结构清晰、稳定、可复用质量高、可迭代、自纠错劣势成本高、缺乏全局规划计划错误会被放大、灵活性差成本最高、迭代次数难控制Token 消耗中到高低到中高到很高6.3 如何选择合适的范式选择范式的决策逻辑其实很直觉问自己三个问题这个任务需要和外部世界交互吗如果需要搜索、查数据库、调 API 获取实时信息——优先选ReAct。这个任务步骤多、结构复杂吗如果任务需要生成一份完整方案、一篇长文、一个系统设计——优先选Plan-and-Solve。这个任务对质量要求特别高吗如果输出需要达到可交付标准比如生产级代码、正式报告——加上Reflection。当然很多时候答案是都需要这时候就需要组合使用——这也是我们下一节要讲的内容。7 组合拳才是王道三种范式的协同作战7.1 真实场景中的 Agent 不会只用一种范式在实际项目中一个成熟的 Agent 系统很少只用单一范式。就像现实中的优秀工作者往往是身兼数职的接到任务时先规划Plan-and-Solve。执行过程中根据需要搜索和交互ReAct。完成后自己检查一遍Reflection。7.2 一个完整的例子生成行业分析报告假设你的 Agent 要完成这个任务“帮我生成一份 2026 年中国新能源汽车行业分析报告面向投资人。”这个任务同时具备以下特征结构复杂报告需要包含市场规模、竞争格局、技术趋势、政策分析、投资建议等多个维度。需要实时信息市场数据、政策动向、企业财报都是最新的。质量要求高面向投资人不能有事实性错误逻辑必须严谨。一个优秀的 Agent 会这样工作第一步Plan-and-Solve——规划报告结构1. 行业概览与市场规模 2. 竞争格局与主要玩家 3. 技术发展趋势 4. 政策环境与监管动态 5. 产业链分析 6. 投资机会与风险提示 7. 结论与建议第二步ReAct——搜索填充每个章节对于市场规模章节Thought需要最新的市场规模数据。Action搜索 2026 年新能源汽车销量数据。Observation获取到 2026 年 1-5 月的销量统计。Thought还需要同比数据和增长率。Action搜索同比数据。Observation获取到完整数据。对于政策环境章节Thought需要了解最新的补贴政策和其他相关政策。Action搜索 2026 年新能源汽车相关政策。Observation获取到政策清单。…依次类推。第三步Reflection——审查与优化数据是否准确有没有前后矛盾的数字逻辑是否连贯从行业概览到投资建议推理链条是否完整有没有遗漏重要信息比如某个重要的新入局者没提到表达是否专业面向投资人的报告措辞不能太口语化。结论是否有充分的数据支撑不能拍脑袋给建议。根据审查结果修改并优化报告。7.3 组合使用的流程图接到任务 ↓ Plan-and-Solve规划任务结构与执行路径 ↓ ReAct按计划逐步执行通过工具获取外部信息 ↓ 生成初始结果 ↓ Reflection审查结果发现问题 ↓ 优化结果 ↓ 可选再次 Reflection ↓ 输出最终结果这个流程体现了一个完整的 Agent 工作流先规划 → 再行动 → 看反馈 → 再优化这才是 Agent 真正有价值的地方——它不是简单地调用一次大模型生成一段文字而是在执行一个有策略、有章法、有质控的完整工作流程。7.4 不是所有任务都需要三种范式当然组合使用不等于每次都全部用上。根据任务特点选择合适的组合才是关键任务类型推荐范式组合快速搜索问答ReAct简单代码生成直接生成 Reflection技术方案设计Plan-and-Solve ReAct长篇报告撰写Plan-and-Solve ReAct Reflection代码重构优化Reflection实时数据分析ReAct Plan-and-Solve关键决策支持Plan-and-Solve Reflection选择的标准不是越多越好而是够用就好。毕竟每多一种范式都意味着更多的 Token 消耗和更长的响应时间。8 超越三种范式Agent 的未来方向讲完三种经典范式有必要简单展望一下 Agent 领域正在发生的变化。8.1 多 Agent 协作三种经典范式聚焦的是单个 Agent 如何工作。但在更复杂的场景中可以让多个 Agent 分工协作一个 Agent 负责搜索信息ReAct 专家。一个 Agent 负责结构化规划Plan-and-Solve 专家。一个 Agent 负责质量审查Reflection 专家。一个管理者 Agent 负责协调它们。这种多 Agent 架构在 LangGraph、AutoGen 等框架中已经开始普及。8.2 记忆与学习经典范式中的 Agent 是无状态的——每次任务都从零开始。但更先进的 Agent 系统会引入长期记忆记住用户偏好这个用户喜欢简洁风格还是详细风格记住任务经验上次类似的报告哪些章节被要求修改了记住工具使用经验这个搜索 API用什么关键词效果更好这种越用越聪明的能力是 Agent 从工具进化为助手的关键。8.3 主动性与自主性当前的 Agent 还是被动接受任务的模式。未来的 Agent 可能会更加主动发现你的代码有潜在问题主动提醒你。注意到你关注的行业新闻有新动态主动推送给你。在执行任务过程中发现更好的方案主动建议调整。从你让它做什么它就做什么到它能主动帮你想到你没想到的——这是 Agent 发展的长远方向。9理解范式才能真正理解 Agent回到文章开头那个问题Agent 到底是什么如果你只看表面Agent 就是大模型 工具调用。但如果你理解了今天讲的三种范式你会发现 Agent 的真正价值不在于能调几个 API而在于它能像一个有方法论的工作者一样完成任务信息不够的时候它会像探险家一样主动出击通过行动获取反馈在不确定中找到方向。任务复杂的时候它会像建筑师一样先画蓝图按部就班地拆解和执行确保结构完整。结果不够好的时候它会像铸剑师一样反复打磨审查问题、持续优化直到质量达标。这三种能力——动态适应、结构化规划、自我优化——构成了 Agent 的工作灵魂。而更让人兴奋的是这三种能力不是互斥的而是可以组合使用的。一个真正成熟的 Agent就像一个经验丰富的专业人士接到任务后先规划执行过程中灵活应变完成后认真复盘。所以下次当有人告诉你Agent 就是让大模型调工具的时候你可以笑着回他一句“调工具只是手脚会思考才是灵魂。”附录一张图看懂三种 Agent 范式┌─────────────────────────────────────────────────────────────────┐ │ Agent 三大经典范式 │ ├──────────────────┬──────────────────┬───────────────────────────┤ │ ReAct │ Plan-and-Solve │ Reflection │ │ 边想边干 │ 谋定后动 │ 精益求精 │ ├──────────────────┼──────────────────┼───────────────────────────┤ │ 想→做→看→想 │ 规划→执行 │ 生成→审查→优化 │ │ 循环式 │ ➡️ 线性式 │ 迭代式 │ ├──────────────────┼──────────────────┼───────────────────────────┤ │ 探险家 │ 建筑师 │ 铸剑师 │ ├──────────────────┼──────────────────┼───────────────────────────┤ │ 探索性任务 │ 结构性任务 │ 质量敏感任务 │ │ 实时信息获取 │ 多步骤推理 │ 代码审查/文章润色 │ │ 工具调用密集 │ 方案设计 │ 关键决策支持 │ └──────────────────┴──────────────────┴───────────────────────────┘选择范式的核心原则不是越多越好而是够用就好。根据任务特点灵活选择单一范式或组合使用在质量和成本之间找到最佳平衡点。
别再只会调工具了！三种 Agent 范式，教你看懂智能体到底怎么“自己干活“
发布时间：2026/6/14 10:31:06
1 你以为 Agent 就是会调 API 的聊天机器人如果你最近在技术圈子里混大概率听过这样的对话“你搞 Agent 了吗”“搞了啊就是让大模型调工具嘛加个搜索、加个计算器完事了。”“哇好厉害”这段对话的问题在于——它把 Agent 理解成了会按按钮的大模型。但真正的 Agent核心价值不在于能调几个 API而在于它怎么思考、怎么行动、怎么规划、怎么反思。换句话说Agent 真正的灵魂不是工具而是它的工作方法。这篇文章就讲清楚三种经典范式ReAct边想边干、Plan-and-Solve谋定后动、Reflection交稿前自己审三遍。读完之后再看各种 Agent 框架你就能真正看懂智能体到底是怎么工作的。2 先搞清楚一个问题Agent 和普通大模型到底差在哪2.1 普通大模型一个超级学霸但只能一问一答你可以把普通大模型想象成一个学识渊博但非常被动的人。你问他地球到月球有多远他脱口而出384,400 公里。你再问“那如果我要造火箭去月球需要多少燃料”他可能会给你一个基于训练数据的估算但这个数字准不准他自己也不知道。因为他不能去查 NASA 的最新数据不能打开计算器精确运算更不能说等等我觉得这个问题的前提条件需要再确认一下。他只能基于记忆中见过什么来回答。这就是普通大模型的局限知识有截止日期无法与真实世界交互不能主动拆解复杂任务。2.2 Agent学霸 工具箱 工作方法Agent 在学霸的基础上多了两样东西第一工具箱。它能调用搜索引擎查最新信息用计算器做精确运算访问数据库读取业务数据甚至操作浏览器、发邮件、写文件。第二也是更重要的——工作方法。它不是拿到问题就直接回答而是会判断当前信息够不够要不要先搜索一下这个任务要不要拆成几步生成的结果靠不靠谱要不要再检查一遍这种判断—行动—观察—调整的能力才是 Agent 和普通大模型的本质区别。而不同的工作方法就构成了我们今天要讲的三种范式。3 ReAct边想边干见招拆招3.1 一句话理解 ReActReAct Reasoning推理 Acting行动。翻译成人话就是想一步做一步看结果再调整。如果你是一个喜欢边走边看的人那你天生就是一个 ReAct 选手。3.2 从一次旅行说起假设你打算周末去一个从没去过的城市玩一天。你会在周一就把每个小时干什么都安排得死死的吗大概率不会。因为你不知道那天天气如何、景点是否开放、网红餐厅要不要排队、地铁线路有没有临时调整。你更可能的做法是先想这个城市有哪些值得去的地方去查周末天气怎么样看到结果周六有雨周日晴天。调整计划户外景点挪到周日周六安排室内活动。再查博物馆需不需要预约发现预约满了。继续调整换一个备选景点。整个过程你没有提前规划好一切而是根据每一步获取到的新信息不断调整下一步行动。这就是 ReAct 的精髓。3.3 ReAct 的技术流程在 Agent 的技术语境下ReAct 的工作流程是一个不断循环的三步Thought思考 → Action行动 → Observation观察 → 回到 Thought ...具体来说Thought思考Agent 分析当前掌握的信息判断下一步应该做什么。这一步是纯粹的推理不涉及任何工具调用。Agent 会想“用户问的是最新产品价格我的训练数据可能已经过时了需要搜索一下。”Action行动Agent 根据思考结果选择并调用合适的工具。可能是搜索引擎、计算器、数据库查询、API 调用甚至代码执行。Observation观察工具返回结果后Agent 把这些结果当作新的事实依据重新进入思考阶段。这个循环会一直持续直到 Agent 判断信息已经足够可以给出最终答案为止。3.4 一个更贴近开发的例子用户问 Agent“帮我整理一下最近适合学生党的轻薄本推荐预算 4000-6000 元。”这个问题模型记忆中的信息大概率是过时的。电脑价格会波动新品会发布老款会降价。一个 ReAct Agent 的处理过程可能是这样的第一轮Thought需要最新的笔记本推荐信息先搜索一下近期热门轻薄本。Action调用搜索引擎搜索2026 年学生轻薄本推荐 4000-6000 元。Observation得到了若干品牌和型号的推荐列表。第二轮Thought列表里有七八款但不知道哪些真正适合学生。学生的核心需求是轻便、续航长、性能够用、性价比高。我来筛选一下。Action针对其中几款搜索详细评测和用户反馈。Observation获取到了各款的重量、续航、性能跑分、用户口碑。第三轮Thought信息差不多了但有两款价格近期波动比较大再确认一下实时价格。Action查询电商平台实时价格。Observation发现其中一款正在做活动性价比突然变高了。第四轮Thought现在信息充分了可以生成推荐了。Action输出最终推荐结果。你看Agent 不是一次性把答案想出来的而是通过多次与外部世界交互逐步拼出了完整答案。3.5 ReAct 的三大优势第一环境适应性强。外部信息变了Agent 可以通过工具获取最新数据。它不会被训练数据截止日期限制住。第二动态纠错能力强。第一次搜索关键词不好没关系换一个再搜。工具返回不完整可以继续追问。这种见招拆招的能力让 Agent 在面对不确定性时非常灵活。第三可解释性好。通过 Thought 链你可以看到 Agent 每一步在想什么、为什么选择调用这个工具、看到结果后又做了什么判断。这种透明度对于调试和信任建立非常重要。3.6 ReAct 的两个坑当然ReAct 不是万能的。第一个坑成本高。每一轮思考—行动—观察都需要调用一次大模型如果任务复杂可能需要循环五六次甚至更多。这意味着更多的 API 调用、更长的响应时间、更高的 Token 消耗。第二个坑缺少全局视野。ReAct 的本质是走一步看一步这在探索性任务中是优势但在步骤明确、结构复杂的任务中就成了劣势。它可能会在某些环节反复尝试甚至偏离最优路径——就像一个没有导航的司机虽然最终也能到目的地但可能绕了不少弯路。3.7 ReAct 小结一句话总结ReAct 是一个边走边查边判断的执行者最适合探索性强、需要实时信息、依赖外部工具的任务。如果用游戏角色类比ReAct 就像是一个探险家——没有详细地图但有指南针和望远镜每走一步都在观察地形、调整方向。4 Plan-and-Solve谋定而后动步步为营4.1 一句话理解 Plan-and-Solve如果说 ReAct 是边走边看那 Plan-and-Solve 就是先画好路线图再按图索骥。它的核心逻辑是两个阶段Planning规划先把任务拆解成清晰的步骤。Solving执行按照步骤逐步完成。4.2 从一次 PPT 汇报说起假设你要做一个课程项目的汇报 PPT。如果你一上来就打开 PowerPoint 开始做大概率会出现这种情况第一页写了项目背景。第二页突然想到一个技术亮点赶紧写上。第三页又觉得应该先讲需求分析。做到一半发现顺序乱了开始大调整。最后匆匆收尾总结页只有两行字。但如果你先花十分钟列一个大纲呢项目背景与问题定义需求分析与用户画像系统架构设计核心功能展示技术亮点与创新点总结与未来展望有了这个框架再逐页填充内容效率和质量都会高得多。这就是 Plan-and-Solve 的核心价值面对复杂任务先结构化拆解再逐步执行远比想到哪做到哪更靠谱。4.3 Plan-and-Solve 的技术流程在 Agent 的技术实现中Plan-and-Solve 分为两个明确阶段阶段一Planning规划Agent 拿到任务后不是立刻动手而是先生成一个执行计划。这个计划会回答以下问题这个任务可以拆成哪几个子任务每个子任务的先后顺序是什么哪些子任务之间有依赖关系最终输出应该如何组织阶段二Solving执行按照计划中的步骤逐一完成。每完成一步Agent 都会对照计划确认进度和方向。4.4例如用户说“帮我设计一个校园二手交易平台的后端方案。”这是一个典型的复杂任务。如果 Agent 直接开写很容易变成一锅粥一会说数据库设计一会跳到接口定义突然又插了一段安全方案。Plan-and-Solve 会先让 Agent 生成这样的计划执行计划明确核心业务模块用户模块、商品模块、订单模块、消息模块、支付模块。设计数据库表结构每个模块的实体、字段、关联关系。设计核心 API 接口RESTful 风格列出关键接口及其入参出参。考虑非功能性需求权限控制、数据安全、异常处理、日志记录。分析高并发场景秒杀、热门商品、订单峰值的处理方案。总结方案亮点与可优化点。有了这个计划后Agent 再逐步展开每一部分的内容。最终输出的方案结构清晰、逻辑完整、覆盖全面——就像一份真正经过深思熟虑的技术文档而不是即兴发挥的随笔。4.5 Plan-and-Solve 的深层价值Plan-and-Solve 的价值不仅仅是有条理它还解决了大模型的一个核心痛点长文本生成时的逻辑漂移问题。你可能注意到如果让大模型一次性生成一篇很长的文章或方案前半部分和后半部分的逻辑连贯性往往会下降。这是因为模型在生成过程中注意力会逐渐偏移。Plan-and-Solve 通过先拆解再执行的方式相当于给模型一个导航仪。每一步都只需要专注于当前子任务而不需要在脑子里同时装着整个任务的全貌。这大大降低了逻辑漂移的风险。4.6 Plan-and-Solve 的三大优势第一结构性强。输出结果天然有清晰的层次和逻辑特别适合需要方案感的任务。第二稳定性高。因为执行路径是预先规划好的不会像 ReAct 那样出现绕弯路或跑偏的情况。第三可复用性好。同一个任务的计划模板可以被复用。比如设计后端方案的计划对不同项目都可以套用类似的结构。4.7 Plan-and-Solve 的两个风险第一个风险计划本身的错误会被放大。如果规划阶段就出了问题后面执行得再认真也是在错误方向上越走越远。比如设计后端方案时计划中遗漏了权限控制这个模块那后面所有内容都不会涉及安全设计。而在 ReAct 范式中这种遗漏可能会在后续搜索或工具调用时被意外发现并弥补。第二个风险灵活性不足。Plan-and-Solve 假设任务的执行路径是可以提前规划的但现实中很多任务充满了不确定性。如果执行过程中发现计划需要大改Agent 可能缺乏动态调整的能力。4.8 Plan-and-Solve 小结一句话总结Plan-and-Solve 是一个先画蓝图再施工的规划者最适合结构清晰、步骤明确、逻辑密集的任务。如果继续用游戏角色类比Plan-and-Solve 就像是一个建筑师——在动第一块砖之前已经有了完整的施工图纸。每一步施工都严格按照图纸执行确保最终建筑的结构稳固、功能完整。5 Reflection交稿之前自己先审三遍5.1 一句话理解 ReflectionReAct 解决怎么边做边调Plan-and-Solve 解决怎么先拆再做而 Reflection 解决的是一个完全不同的问题结果出来了但不够好怎么办Reflection 就是给 Agent 装上一个内置审稿人生成结果后不是直接交付而是自己检查一遍、发现问题、修改优化然后再检查、再优化——直到质量达标。5.2 其实你每天都在用 ReflectionReflection 听起来很高级但其实你在日常工作中一直在用它写作文第一版叫初稿改完之后叫终稿有些人的终稿和初稿几乎不是同一篇文章。写代码第一版写完能跑然后做 Code Review发现命名不规范、边界条件没覆盖、性能可以优化于是重写一版。做题算完答案之后验算一遍发现中间某一步算错了赶紧改过来。写方案交付前检查一遍发现有个重要场景遗漏了赶紧补上。发邮件写完之后读一遍觉得措辞不太合适改了几个词再发出去。这些行为的本质都是一样的第一版不求完美但求有然后通过反复审查和修改让结果从能用变成好用。Reflection 就是把这种人类习以为常的自我迭代能力赋予了 Agent。5.3 Reflection 的技术流程Reflection 的工作流程分为三个核心阶段Execution执行 → Reflection反思 → Refinement优化 → 回到 Reflection ...Execution执行Agent 先生成一个初始结果。这个结果可以是代码、文章、方案、分析报告——任何类型的输出。Reflection反思Agent 切换到审查者角色对初始结果进行严格审查。它会问自己一系列问题结果是否正确有没有事实性错误逻辑是否连贯有没有前后矛盾是否覆盖了所有重要方面有没有遗漏有没有更优的实现方式是否符合目标受众的需求Refinement优化根据反思阶段发现的问题Agent 对结果进行针对性修改。这个反思—优化的循环可以执行多轮直到结果质量达到预期标准。5.4 代码场景写一个限流工具类用户让 Agent 写一段代码“用 Java 实现一个接口限流工具类支持滑动窗口算法。”第一版ExecutionAgent 生成了一段代码。能编译、能运行、基本逻辑也对了。审查阶段ReflectionAgent 切换成高级工程师视角对代码进行审查并发安全多个线程同时调用时计数器的原子性有保证吗用了AtomicInteger还是普通的int异常处理如果传入的参数是 null 或者负数会抛异常吗有友好的错误提示吗边界条件窗口大小为 0 或者 1 的时候算法还正确吗扩展性限流策略是硬编码的还是可以通过策略模式替换的可测试性核心逻辑是否容易写单元测试代码规范变量命名是否清晰关键逻辑有没有注释第二版RefinementAgent 根据上述反馈重写代码引入ConcurrentHashMap保证线程安全、增加参数校验、抽取策略接口提升扩展性、补充关键注释。再来一轮可选Agent 甚至可以再审查一次第二版代码看看还有没有遗漏——比如是否考虑了分布式场景、是否需要引入 Redis 做跨实例限流。这个过程的价值远不只是修了几个 Bug。它让最终输出从能用变成了可靠从Demo 级别变成了生产级别。5.5 写作场景写一篇公众号文章再来看一个非代码场景。用户让 Agent 写一篇关于程序员如何保护颈椎的公众号文章。第一版文章写完了信息完整有病因分析、有动作建议、有就医提醒。但读起来像一篇医学百科——正确但无趣。审查阶段Agent 从读者体验角度重新审视开头第一句话是颈椎病是一种常见的退行性疾病——读者到这就划走了。能不能换成一个更有代入感的开头比如你有没有过这种体验加完班站起来脖子像被灌了水泥段落长度有好几段超过 200 字在手机屏幕上就是一整面文字墙。能不能拆短重点突出关键建议混在大段文字里不够醒目。能不能加粗、加小标题例子和比喻全程都是专业术语能不能用更生活化的比喻比如你的颈椎就像一个 24 小时值班的保安你越不理它它越会闹脾气。结尾平平淡淡的希望对你有帮助——能不能给读者一个立刻能做的行动比如现在就放下手机做三个颈部环绕动作。第二版根据反馈重写文章风格大变开头有共鸣感中间有节奏感结尾有行动感。这就是 Reflection 的威力——它不只是纠错更是从能用到好用的质变过程。5.6 Reflection 的三大核心价值第一内置纠错回路。Reflection 不依赖外部工具来发现问题而是让 Agent 自己成为自己的质检员。这种自我审查能力在很多没有外部反馈渠道的场景中尤其重要。第二提升最终质量。对于代码、方案、报告、文章这类质量没有上限的任务Reflection 提供了持续优化的机制。每一次反思循环都在把结果推向更高的质量标准。第三形成迭代记忆。Agent 不仅知道最终答案还保留了初稿—反馈—修改的完整过程。这种过程信息对于理解为什么最终方案是这样的非常有价值也为后续的多轮优化提供了基础。5.7 Reflection 的成本与适用边界Reflection 不是免费的午餐。每一次反思 优化循环至少需要额外调用两次大模型一次审查一次修改。如果反复迭代三四轮成本和耗时都会显著增加。所以Reflection 本质上是一种用时间和成本换质量的策略。适合使用 Reflection 的场景生产级代码生成正式技术报告或方案复杂逻辑分析与推理高质量内容创作关键业务决策辅助不太适合的场景快速问答“今天星期几”简单的格式转换对质量要求不高的临时任务简单来说如果你只需要一个60 分答案直接生成就够了但如果你需要90 分答案Reflection 几乎是必经之路。5.8 Reflection 小结一句话总结Reflection 是一个自带审稿人和质检员的智能体最适合对准确性、可靠性和最终质量要求极高的场景。如果用游戏角色类比Reflection 就像是一个铸剑师——第一版是粗锻第二版是精磨第三版是淬火。每一轮都不是推倒重来而是在上一版基础上让作品变得更锋利、更坚韧、更完美。6 三种范式的深度对比什么时候该用谁6.1 核心差异一句话版讲到这里我们可以用最简洁的方式区分三种范式ReAct解决的是信息不够的时候怎么办答案是——去行动、去获取、去交互。Plan-and-Solve解决的是任务太复杂的时候怎么办答案是——先拆解、再规划、后执行。Reflection解决的是结果不够好的时候怎么办答案是——自己审、找问题、再优化。6.2 全方位对比表维度ReActPlan-and-SolveReflection核心思想边想边做动态调整先规划后执行先完成再优化形象比喻探险家建筑师铸剑师核心能力环境感知与动态适应结构化拆解与有序执行自我审查与持续优化工作模式循环式想→做→看→想线性式规划→执行迭代式生成→审查→优化适合任务类型探索性、实时性、工具密集型结构性、多步骤、逻辑密集型质量敏感、高精度要求典型场景搜索问答、数据分析、信息检索报告撰写、方案设计、代码架构代码审查、文章润色、方案优化优势灵活、适应性强、可解释结构清晰、稳定、可复用质量高、可迭代、自纠错劣势成本高、缺乏全局规划计划错误会被放大、灵活性差成本最高、迭代次数难控制Token 消耗中到高低到中高到很高6.3 如何选择合适的范式选择范式的决策逻辑其实很直觉问自己三个问题这个任务需要和外部世界交互吗如果需要搜索、查数据库、调 API 获取实时信息——优先选ReAct。这个任务步骤多、结构复杂吗如果任务需要生成一份完整方案、一篇长文、一个系统设计——优先选Plan-and-Solve。这个任务对质量要求特别高吗如果输出需要达到可交付标准比如生产级代码、正式报告——加上Reflection。当然很多时候答案是都需要这时候就需要组合使用——这也是我们下一节要讲的内容。7 组合拳才是王道三种范式的协同作战7.1 真实场景中的 Agent 不会只用一种范式在实际项目中一个成熟的 Agent 系统很少只用单一范式。就像现实中的优秀工作者往往是身兼数职的接到任务时先规划Plan-and-Solve。执行过程中根据需要搜索和交互ReAct。完成后自己检查一遍Reflection。7.2 一个完整的例子生成行业分析报告假设你的 Agent 要完成这个任务“帮我生成一份 2026 年中国新能源汽车行业分析报告面向投资人。”这个任务同时具备以下特征结构复杂报告需要包含市场规模、竞争格局、技术趋势、政策分析、投资建议等多个维度。需要实时信息市场数据、政策动向、企业财报都是最新的。质量要求高面向投资人不能有事实性错误逻辑必须严谨。一个优秀的 Agent 会这样工作第一步Plan-and-Solve——规划报告结构1. 行业概览与市场规模 2. 竞争格局与主要玩家 3. 技术发展趋势 4. 政策环境与监管动态 5. 产业链分析 6. 投资机会与风险提示 7. 结论与建议第二步ReAct——搜索填充每个章节对于市场规模章节Thought需要最新的市场规模数据。Action搜索 2026 年新能源汽车销量数据。Observation获取到 2026 年 1-5 月的销量统计。Thought还需要同比数据和增长率。Action搜索同比数据。Observation获取到完整数据。对于政策环境章节Thought需要了解最新的补贴政策和其他相关政策。Action搜索 2026 年新能源汽车相关政策。Observation获取到政策清单。…依次类推。第三步Reflection——审查与优化数据是否准确有没有前后矛盾的数字逻辑是否连贯从行业概览到投资建议推理链条是否完整有没有遗漏重要信息比如某个重要的新入局者没提到表达是否专业面向投资人的报告措辞不能太口语化。结论是否有充分的数据支撑不能拍脑袋给建议。根据审查结果修改并优化报告。7.3 组合使用的流程图接到任务 ↓ Plan-and-Solve规划任务结构与执行路径 ↓ ReAct按计划逐步执行通过工具获取外部信息 ↓ 生成初始结果 ↓ Reflection审查结果发现问题 ↓ 优化结果 ↓ 可选再次 Reflection ↓ 输出最终结果这个流程体现了一个完整的 Agent 工作流先规划 → 再行动 → 看反馈 → 再优化这才是 Agent 真正有价值的地方——它不是简单地调用一次大模型生成一段文字而是在执行一个有策略、有章法、有质控的完整工作流程。7.4 不是所有任务都需要三种范式当然组合使用不等于每次都全部用上。根据任务特点选择合适的组合才是关键任务类型推荐范式组合快速搜索问答ReAct简单代码生成直接生成 Reflection技术方案设计Plan-and-Solve ReAct长篇报告撰写Plan-and-Solve ReAct Reflection代码重构优化Reflection实时数据分析ReAct Plan-and-Solve关键决策支持Plan-and-Solve Reflection选择的标准不是越多越好而是够用就好。毕竟每多一种范式都意味着更多的 Token 消耗和更长的响应时间。8 超越三种范式Agent 的未来方向讲完三种经典范式有必要简单展望一下 Agent 领域正在发生的变化。8.1 多 Agent 协作三种经典范式聚焦的是单个 Agent 如何工作。但在更复杂的场景中可以让多个 Agent 分工协作一个 Agent 负责搜索信息ReAct 专家。一个 Agent 负责结构化规划Plan-and-Solve 专家。一个 Agent 负责质量审查Reflection 专家。一个管理者 Agent 负责协调它们。这种多 Agent 架构在 LangGraph、AutoGen 等框架中已经开始普及。8.2 记忆与学习经典范式中的 Agent 是无状态的——每次任务都从零开始。但更先进的 Agent 系统会引入长期记忆记住用户偏好这个用户喜欢简洁风格还是详细风格记住任务经验上次类似的报告哪些章节被要求修改了记住工具使用经验这个搜索 API用什么关键词效果更好这种越用越聪明的能力是 Agent 从工具进化为助手的关键。8.3 主动性与自主性当前的 Agent 还是被动接受任务的模式。未来的 Agent 可能会更加主动发现你的代码有潜在问题主动提醒你。注意到你关注的行业新闻有新动态主动推送给你。在执行任务过程中发现更好的方案主动建议调整。从你让它做什么它就做什么到它能主动帮你想到你没想到的——这是 Agent 发展的长远方向。9理解范式才能真正理解 Agent回到文章开头那个问题Agent 到底是什么如果你只看表面Agent 就是大模型 工具调用。但如果你理解了今天讲的三种范式你会发现 Agent 的真正价值不在于能调几个 API而在于它能像一个有方法论的工作者一样完成任务信息不够的时候它会像探险家一样主动出击通过行动获取反馈在不确定中找到方向。任务复杂的时候它会像建筑师一样先画蓝图按部就班地拆解和执行确保结构完整。结果不够好的时候它会像铸剑师一样反复打磨审查问题、持续优化直到质量达标。这三种能力——动态适应、结构化规划、自我优化——构成了 Agent 的工作灵魂。而更让人兴奋的是这三种能力不是互斥的而是可以组合使用的。一个真正成熟的 Agent就像一个经验丰富的专业人士接到任务后先规划执行过程中灵活应变完成后认真复盘。所以下次当有人告诉你Agent 就是让大模型调工具的时候你可以笑着回他一句“调工具只是手脚会思考才是灵魂。”附录一张图看懂三种 Agent 范式┌─────────────────────────────────────────────────────────────────┐ │ Agent 三大经典范式 │ ├──────────────────┬──────────────────┬───────────────────────────┤ │ ReAct │ Plan-and-Solve │ Reflection │ │ 边想边干 │ 谋定后动 │ 精益求精 │ ├──────────────────┼──────────────────┼───────────────────────────┤ │ 想→做→看→想 │ 规划→执行 │ 生成→审查→优化 │ │ 循环式 │ ➡️ 线性式 │ 迭代式 │ ├──────────────────┼──────────────────┼───────────────────────────┤ │ 探险家 │ 建筑师 │ 铸剑师 │ ├──────────────────┼──────────────────┼───────────────────────────┤ │ 探索性任务 │ 结构性任务 │ 质量敏感任务 │ │ 实时信息获取 │ 多步骤推理 │ 代码审查/文章润色 │ │ 工具调用密集 │ 方案设计 │ 关键决策支持 │ └──────────────────┴──────────────────┴───────────────────────────┘选择范式的核心原则不是越多越好而是够用就好。根据任务特点灵活选择单一范式或组合使用在质量和成本之间找到最佳平衡点。
（支持资料、图片参考_相关定制）_文章底部可以扫码)
（支持资料、图片参考_相关定制）_文章底部可以扫码)
