导读你的 Agent 是不是经常一根筋——调了工具就不管对错跑完就结束说实话小编当初也觉得能调工具就够了。但随着任务越来越复杂我才发现——光会动手不够还得会思考、会规划、会反思。本文带你一口气吃透智能体构建的三大经典范式ReAct → Plan-and-Solve → Reflection。万字长文建议收藏慢慢看。一、你的 Agent真的会思考吗小编前面几期已经把智能体搭建的核心技术科普了一遍——从工具调用到 MCP从 Context Engineering 到 Harness。但最近小编在做一个稍微复杂点的 Agent 时遇到了一个很尴尬的问题Agent 有手有脚了但脑子不够用。什么意思来看几个翻车场景翻车场景 1一根筋不会拐弯小编让 Agent 帮我查一个技术问题。它调了搜索工具第一次没搜到有用结果。然后呢它把搜索结果原封不动丢给我说“根据搜索结果未找到相关信息。”完了完了。它不会换个关键词再搜一次不会想是不是我搜索的姿势不对不会反思——它只会一次性执行。翻车场景 2步骤一多就迷路我让 Agent 完成一个复合任务“查一下竞品的最新定价对比我们的产品写成一份分析报告。”三个子任务。结果呢Agent 查完定价之后直接开始写报告了——完全跳过了对比这一步。它没有全局规划的概念走一步算一步步骤一多就丢。翻车场景 3写完就交卷从不检查Agent 帮我写了一段代码。语法对吗对。逻辑对吗……不对。但它不会自己检查。它把初稿直接当终稿交给你。从来不回头看一眼。这三个问题本质上是同一个事Agent 缺乏高质量的思考方式。光有工具不够还得教会它怎么思考。而这正是业界三大经典范式要解决的问题范式核心思想一句话类比ReAct边想边做动态调整像侦探:跟着线索走随时改变方向Plan-and-Solve先想后做按图施工像建筑师先画蓝图再盖房子Reflection做完再想迭代优化像作家写初稿自己审稿改到满意小编用一张图帮你记住核心区别ReAct 想 → 做 → 看 → 想 → 做 → 看 → ... → 完成Plan-and-Solve想想想想 → 做做做做做 → 完成Reflection 做完 → 想哪里不对→ 改 → 想 → 改 → ... → 完成好了下面逐个展开。二、ReAct边想边做的侦探模式2.1 它是什么一句话定义ReAct 让智能体在每一步都先想清楚再动手——形成思考→行动→观察的循环直到解决问题。ReActReasoning and Acting由 Shunyu Yao 于 2022 年提出。它的核心洞察非常朴素人类解决问题时不是纯想也不是纯做而是边想边做。打个比方你是一个侦探接到一桩案件。你不会坐在办公室想完所有可能性再出门那要想到猴年马月也不会不带脑子就出门乱跑。你的做法是——想凶手可能认识死者先去查死者的社交关系做翻看死者的通讯录发现一个可疑号码看这个号码属于死者的前同事张三想张三有动机吗需要查一下他案发时的行踪做调取监控...每一步的想指导下一步做每一步做的结果又更新你的想。这就是 ReAct 的核心循环。2.2 “思考-行动-观察” 循环是怎么跑起来的在 ReAct 出现之前主流方法分两派•纯思考派如思维链 CoT能推理但没有手脚不能上网查、不能调工具——遇到事实性问题就只能靠编•纯行动派直接调工具但不会思考为什么调、调完之后怎么办——像个没脑子的跑腿ReAct 把两者融合了。它通过一种特殊的 Prompt 结构让模型每一步都输出三个东西Thought思考——“我在想什么”这是 Agent 的内心独白。它会分析当前情况、反思上一步结果、规划下一步动作Thought: 用户问的是华为最新手机这个信息我的训练数据里可能过时了。 我需要搜索一下最新的资讯。Action行动——“我要做什么”基于思考Agent 决定调用哪个工具、传什么参数Action: Search[华为 2026 最新款手机]Observation观察——“我看到了什么”工具执行后返回的结果会自动追加到 Agent 的上下文中Observation: 华为于 2026 年 4 月发布了 Pura 90 系列搭载麒麟9030S芯片 主打卫星通话和 AI 摄影...然后 Agent 进入下一轮循环——基于新的 Observation 继续 Thought → Action → Observation直到它认为已经收集到足够信息输出最终答案。用一张图总结完整流程2.3 Prompt 是 ReAct 的操作系统ReAct 的巧妙之处在于——它不需要训练模型只需要一个精心设计的 Prompt 模板。小编直接把模板贴出来# ReAct 提示词模板REACT_PROMPT_TEMPLATE 请注意你是一个有能力调用外部工具的智能助手。可用工具如下:{tools}请严格按照以下格式进行回应:Thought: 你的思考过程用于分析问题、拆解任务和规划下一步行动。Action: 你决定采取的行动必须是以下格式之一:- tool_name[tool_input]:调用一个可用工具。- Finish[最终答案]:当你认为已经获得最终答案时。现在请开始解决以下问题:Question: {question}History: {history}这个模板做了四件关键的事要素作用大白话角色设定告诉模型你能调用工具给模型信心–你有手有脚工具清单列出可用工具的名称和描述告诉它“你的工具箱有什么”格式规约强制输出Thought/Action结构让代码能够精准解析模型意图动态上下文不断累积的交互历史让模型看到“之前发生了什么”注意{history}的重要性——每一轮的 Thought、Action、Observation 都会追加进来。这就像侦探的笔记本越写越厚让后续推理有据可依。2.4 代码实战搭一个能上网搜索的 ReAct Agent小编用 Python 写一个最小化的 ReAct Agent让你看看这个循环在代码里是怎么跑起来的。先说这段代码要做什么定义一个搜索工具模拟网络搜索搭建 ReAct 循环引擎回答一个需要联网才能答的问题import refrom openai import OpenAI# -----------------------------------------------# 【按你的环境修改这里】# -----------------------------------------------client OpenAI( api_keyyour-api-key, # 替换为你的 API Key base_urlyour-base-url # 如果用国内 API 代理改这里)MODEL_NAME gpt-4o # 或其他支持 function calling 的模型# -----------------------------------------------# 步骤1定义工具 defweb_search(query: str) - str: 模拟网络搜索实际项目替换成真实搜索 API # 这里用硬编码模拟你可以接入 Tavily/SerpAPI 等真实搜索 mock_results { 华为 2026 最新款手机: 华为于2026年初发布 Pura 80 系列旗舰手机搭载麒麟9020八核处理器(5nm工艺)运行HarmonyOS 5.1系统支持卫星通话。, 华为 Pura 80 卖点: 主要卖点1.麒麟9020处理器Maleoon 910 GPU性能大幅提升 2.后置50MP48MP40MP三摄(OIS光学防抖) 3.5700mAh电池100W有线快充80W无线快充 4.卫星通话功能 5.6.8英寸OLED LTPO屏(1-120Hz自适应) } # 模糊匹配 for key, value in mock_results.items(): ifany(word in query for word in key.split()): return value returnf未找到与{query}相关的结果# 注册工具告诉 Agent 有什么可用的TOOLS { Search: { func: web_search, description: 搜索互联网获取最新信息。输入搜索关键词 }}# 步骤2构建 ReAct 引擎 REACT_PROMPT 你是一个有能力调用外部工具的智能助手。可用工具:{tools}请严格按以下格式回应每次只输出一组 Thought Action:Thought: 你的思考过程Action: tool_name[输入内容] 或 Finish[最终答案]问题: {question}历史记录:{history}defformat_tools(tools: dict) - str: 把工具字典格式化成文本描述 lines [] for name, info in tools.items(): lines.append(f- {name}: {info[description]}) return\n.join(lines)defparse_action(response: str): 解析模型输出提取 Action 中的工具名和参数 # 匹配 Action: ToolName[input] 或 Finish[answer] match re.search(rAction:\s*(\w)\[(.?)\], response, re.DOTALL) ifmatch: returnmatch.group(1), match.group(2) returnNone, Nonedefreact_agent(question: str, max_steps: int 5) - str: ReAct 主循环 history for step inrange(max_steps): # 组装 Prompt prompt REACT_PROMPT.format( toolsformat_tools(TOOLS), questionquestion, historyhistory if history else暂无 ) # 调用 LLM response client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], temperature0 ) output response.choices[0].message.content print(f\n--- 第 {step 1} 轮 ---) print(output) # 解析 Action tool_name, tool_input parse_action(output) if tool_name Finish: print(f\n✅ 最终答案: {tool_input}) return tool_input elif tool_name and tool_name in TOOLS: # 执行工具 observation TOOLS[tool_name][func](tool_input) print(f[工具返回] {observation}) # 追加到历史 history f\nThought: {output.split(Thought:)[1].split(Action:)[0].strip() if Thought: in output else } history f\nAction: {tool_name}[{tool_input}] history f\nObservation: {observation}\n else: print(⚠️ 无法解析 Action终止) return解析失败 return达到最大步数限制# 步骤3运行 if __name__ __main__: question 华为最新的手机是哪一款它的主要卖点是什么 answer react_agent(question)运行结果--- 第 1 轮 ---Thought: 用户问华为最新手机及卖点。这是实时信息我训练数据可能过时需要搜索。Action: Search[华为 2026 最新款手机][工具返回] 华为于2026年初发布 Pura 80 系列旗舰手机搭载麒麟9020八核处理器(5nm工艺)运行HarmonyOS 5.1系统支持卫星通话。--- 第 2 轮 ---Thought: 我已经知道最新款是 Pura 80 系列但用户还问了主要卖点搜索结果里提到了芯片和卫星通话但不够详细我再搜一下具体卖点。Action: Search[华为 Pura 80 卖点][工具返回] 主要卖点1.麒麟9020处理器Maleoon 910 GPU性能大幅提升 2.后置50MP48MP40MP三摄(OIS光学防抖) 3.5700mAh电池100W有线快充80W无线快充 4.卫星通话功能 5.6.8英寸OLED LTPO屏(1-120Hz自适应)--- 第 3 轮 ---Thought: 现在信息够了。华为最新手机是 Pura 80 系列卖点有五个。可以给出最终答案了。Action: Finish[华为最新手机是 2026年初发布的 Pura 80 系列。搭载麒麟9020处理器(5nm)主要卖点①50MP48MP40MP三摄 ②5700mAh100W快充 ③卫星通话 ④6.8英寸LTPO屏幕 ⑤HarmonyOS 5.1系统。]✅ 最终答案: 华为最新手机是 2026年初发布的 Pura 80 系列...看到了吗Agent 自己决定了搜两次——第一次搜基本信息第二次补充卖点细节。这就是思考的力量它知道什么时候该继续什么时候该收工。2.5 ReAct 的适用场景与局限最适合 ReAct 的场景• 需要外部知识的任务查天气、搜新闻、查股价• 需要精确计算的任务把数学问题交给计算器• 需要多步探索的任务一步搜索不够需要顺藤摸瓜•信息不完整的任务事先不知道需要几步才能解决ReAct 的局限局限具体表现小编踩过的坑短视只看当前一步没有全局规划5步任务经常到第3步就跑偏了循环风险想错了就反复调用同一个工具Agent搜了5遍同一个关键词无自省做完就完了不回头检查代码写完有bug,也直接交卷上下文膨胀历史越来越长Token爆炸跑了8轮之后模型开始“失忆”“ReAct 像个经验丰富的侦探——但它没有地图也不会回头检查笔记有没有写错。”当任务足够复杂——需要先规划再执行——ReAct 就力不从心了。这时候你需要第二种范式。三、Plan-and-Solve先画蓝图再施工的建筑师模式3.1 从边走边看到三思而后行如果说 ReAct 像一个跟着线索走的侦探那么 Plan-and-Solve 更像一位建筑师——动工之前必须先画好完整蓝图。Plan-and-Solve 由 Lei Wang 在 2023 年提出它要解决的核心问题是思维链在处理多步骤复杂问题时容易偏离轨道。小编自己的经历让 Agent 做一个需要 5 步才能完成的任务。用 ReAct 跑它到第 3 步就开始走神——忘了最终目标是什么开始追着一个不相关的细节跑了。为什么会这样因为 ReAct 的思考只看当前一步。它没有一个全局的计划来约束自己。Plan-and-Solve 的解法很直接ReAct 走一步 → 想一步 → 走一步 → 想一步 → ...Plan-and-Solve先想完所有步骤 → 然后逐步执行3.2 两阶段架构规划器 执行器Plan-and-Solve 把整个流程解耦成两个独立阶段小编用一个更通俗的类比帮你理解想象你要做一道复杂的菜——比如佛跳墙。•ReAct 做法打开冰箱看有什么就做什么。做着做着发现少了一味料再出门买。买回来发现火候过了。一边做一边补救。•Plan-and-Solve 做法先拉一张食材清单 步骤表。确认所有食材到位。然后严格按步骤来第一步泡发→第二步焯水→第三步炖煮→……哪种做法更适合复杂任务显然是后者。3.3 规划阶段让 LLM 当项目经理规划阶段的目标很明确把一个大问题拆解成一系列可执行的小步骤。小编设计的规划器 Prompt 是这样的PLANNER_PROMPT 你是一个顶级的AI规划专家。你的任务是将用户提出的复杂问题分解成一个由多个简单步骤组成的行动计划。要求1. 每个步骤必须是一个独立的、可执行的子任务2. 步骤之间严格按逻辑顺序排列3. 每个步骤的描述要具体、明确不要模糊问题: {question}请输出你的计划格式为 Python 列表:python[步骤1: 具体描述, 步骤2: 具体描述, ...]“”**为什么要求输出 Python 列表** 因为 JSON/列表格式比自然语言更容易被代码解析。小编试过让模型用自然语言输出计划——结果格式千变万化解析代码写到崩溃。用列表格式一行 eval() 就搞定当然生产环境别用 eval用 json.loads 或 ast.literal_eval。### 3.4 执行阶段带着任务书逐步推进执行器的工作方式跟 ReAct 不同——它不需要自己想下一步做什么因为计划已经告诉它了。它只需要**专注于当前步骤**。但执行器有一个关键设计**状态传递**。每一步的结果会作为下一步的输入。pythonEXECUTOR_PROMPT 你是一位顶级的AI执行专家。请专注于解决当前步骤。# 原始问题:{question}# 完整计划:{plan}# 已完成的步骤和结果:{history}# 当前步骤:{current_step}请仅输出当前步骤的答案不要多余解释:注意这个 Prompt 的四个组成部分部分作用类比原始问题不让模型忘记最终目标项目的OKR,始终可见完整计划让模型知道当前步骤在全局中的位置甘特图知道自己在哪历史结果前面步骤的结果作为当前步骤的输入上一个同事的工作交接当前步骤明确“现在该做什么”今日代办只有一条3.5 代码实战一个完整的 Plan-and-Solve Agentimport astfrom openai import OpenAI# -----------------------------------------------# 【按你的环境修改这里】# -----------------------------------------------client OpenAI(api_keyyour-api-key, base_urlyour-base-url)MODEL_NAME gpt-4o# -----------------------------------------------# 步骤1规划器 PLANNER_PROMPT 你是一个顶级的AI规划专家。将用户的复杂问题分解成多个简单步骤。要求每步独立可执行按逻辑排列描述具体明确。问题: {question}输出格式严格 Python 列表:python[步骤1: ..., 步骤2: ..., ...]defplan(question: str) - list: 调用 LLM 生成行动计划 response client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: PLANNER_PROMPT.format(questionquestion)}], temperature0 ) output response.choices[0].message.content # 提取 Python 列表 match output.split(python)[1].split()[0] ifpythonin output else output steps ast.literal_eval(match.strip()) # 安全解析列表 return steps# 步骤2执行器 EXECUTOR_PROMPT 你是一位AI执行专家。请专注解决当前步骤仅输出该步答案。# 原始问题: {question}# 完整计划: {plan}# 已完成步骤: {history}# 当前步骤: {current_step}请直接输出当前步骤的答案:defexecute_step(question: str, plan_steps: list, history: str, current_step: str) - str: 执行单个步骤 response client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: EXECUTOR_PROMPT.format( questionquestion, plan\n.join(f{i1}. {s}for i, s inenumerate(plan_steps)), historyhistory if history else暂无, current_stepcurrent_step )}], temperature0 ) return response.choices[0].message.content# 步骤3主流程 defplan_and_solve(question: str) - str: Plan-and-Solve 主流程 # 第一阶段规划 print( 正在生成计划...) steps plan(question) print(f计划生成完毕共 {len(steps)} 步) for i, step inenumerate(steps): print(f {i1}. {step}) # 第二阶段逐步执行 print(\n 开始执行...) history for i, step inenumerate(steps): print(f\n--- 执行第 {i1} 步: {step} ---) result execute_step(question, steps, history, step) print(f结果: {result[:200]}...) # 只打印前200字 history f\n步骤{i1}: {step}\n结果: {result}\n # 最终汇总 print(\n✅ 所有步骤执行完毕汇总最终答案...) final execute_step( question, steps, history, 根据以上所有步骤的结果给出最终的完整答案 ) return final# 运行 if __name__ __main__: question 对比分析 Python 和 Go 在构建高并发 Web 服务时的优劣势并给出选型建议 answer plan_and_solve(question) print(f\n{*50}\n最终答案:\n{answer})运行结果 正在生成计划...计划生成完毕共 4 步 1. 步骤1: 分析 Python 在高并发 Web 服务中的优势和劣势 2. 步骤2: 分析 Go 在高并发 Web 服务中的优势和劣势 3. 步骤3: 从性能、开发效率、生态、部署等维度对比两者 4. 步骤4: 根据不同场景给出选型建议 开始执行...--- 执行第 1 步: 分析 Python 在高并发中的优势和劣势 ---结果: 优势1.开发效率高生态丰富(Django/FastAPI) 2.异步框架成熟(asyncio)... 劣势1.GIL限制真正并行 2.内存占用高 3.冷启动慢...--- 执行第 2 步: 分析 Go 在高并发中的优势和劣势 ---结果: 优势1.原生协程(goroutine)轻量高效 2.编译型语言性能强... 劣势1.泛型支持晚 2.错误处理啰嗦 3.生态不如Python丰富...--- 执行第 3 步: 多维度对比 ---结果: | 维度 | Python | Go | ...--- 执行第 4 步: 场景化选型建议 ---结果: 快速迭代/AI密集型→Python; 高QPS/微服务→Go; 混合架构→...✅ 所有步骤执行完毕看到了吗每一步都不会跑偏因为计划在开头就定好了。执行器只需要专注于当前任务。3.6 Plan-and-Solve 的适用场景与局限最适合的场景•结构化分析任务对比报告、竞品分析、技术选型•多步骤创作任务写长文、做 PPT 大纲、写技术方案•流程性操作数据清洗 Pipeline、自动化部署步骤•需要全局一致性的任务步骤之间有强依赖不能乱序Plan-and-Solve 的局限局限具体表现小编的感受计划不可变一旦规划完成中途遇到意外难以调整第3步发现前面的假设错了但是计划停不下来依赖规划质量规划本身有问题后面全跟着错“垃圾进垃圾出”不适合探索性任务事先不知道需要几步的任务搜索类任务根本没法预规划多一次LLM调用规划本身就要多花Token和时间简单任务反而变慢了“Plan-and-Solve 像个严谨的建筑师——但如果蓝图画错了房子也会歪。它缺少一个’回头审查蓝图’的机制。”这就引出了第三种范式——四、Reflection做完再想的作家模式4.1 为什么做完不是终点前面两种范式——ReAct 做完就完了Plan-and-Solve 执行完计划就结束了。但小编想问你一个问题你写完一篇文章会直接发出去吗当然不会。你会通读一遍检查有没有错别字想想逻辑通不通有没有遗漏改一改措辞删掉废话再读一遍确认没问题了再发这个写完→检查→修改→再检查的过程就是 Reflection 的核心思想。一句话定义Reflection 为智能体引入事后自省能力——执行完任务后让另一个评审员检查结果发现问题后迭代修正直到质量达标。Reflection 的灵感来自 Shinn, Noah 在 2023 年提出的 Reflexion 框架。它的核心洞察是初稿永远不是最好的。加一个自我审查的循环结果会好得多。4.2 三步循环执行 → 反思 → 优化Reflection 的工作流简洁而有力小编把三步拆开说清楚第一步执行Execution—— 先交一份初稿用你熟悉的方法ReAct、Plan-and-Solve、或者直接让 LLM 生成完成任务。这个结果不需要完美——它就是个初稿。第二步反思Reflection—— 让评审员找茬关键来了。这一步调用一个独立的 LLM或者用特殊 Prompt 让同一个 LLM 切换角色扮演严格的评审员。评审员从多个维度检查•事实性有没有与常识或已知事实矛盾的内容•逻辑性推理过程有没有漏洞或矛盾•完整性有没有遗漏关键信息或约束•效率性有没有更好、更简洁的方案然后输出结构化的反馈哪里有问题建议怎么改。第三步优化Refinement—— 根据反馈改稿把初稿和评审反馈一起交给 LLM要求它根据反馈修正生成改进版。这个过程可以多轮迭代——改完再审审完再改直到评审员说OK没问题了。4.3 Reflection 跟前两种范式的本质区别维度ReActPlan-and-SolveReflection纠错时机执行中(靠Observation)几乎不纠错执行后事后审查纠错来源外部工具反馈无内部自我批判能修正什么事实性错误搜错了再搜-逻辑错误、遗漏、质量问题迭代次数每步一次无迭代可多轮类比侦探跟线索建筑师按照蓝图作家改稿关键区别ReAct 靠外部反馈纠错搜索结果不对就再搜Reflection 靠内部自省纠错自己检查自己的逻辑。这就像——• 学生做错题ReAct 是翻书查答案对一下• 学生做错题Reflection 是自己重新推一遍看哪步推错了后者能修正更深层的问题。4.4 代码实战给 Agent 装上自我审查能力小编设计一个场景让 Agent 写一段 Python 函数然后自己审查、自己修正。from openai import OpenAI# -----------------------------------------------# 【按你的环境修改这里】# -----------------------------------------------client OpenAI(api_keyyour-api-key, base_urlyour-base-url)MODEL_NAME gpt-4o# -----------------------------------------------# 步骤1执行器写初稿EXECUTOR_PROMPT 你是一位 Python 开发专家。请根据需求编写代码。需求: {task}请直接输出 Python 代码用 python 包裹:# 步骤2反思器审查REFLECTOR_PROMPT 你是一位严格的代码审查专家。请审查以下代码从这几个维度评估1. **正确性**逻辑是否正确边界条件处理了吗2. **健壮性**异常处理完善吗输入非法会怎样3. **性能**有没有明显的性能问题4. **可读性**命名清晰吗需要加注释吗需求: {task}代码:{code}请输出你的审查结果格式如下评分: X/10问题列表:1. [严重程度] 具体问题描述2. ...改进建议:1. 具体怎么改2. ...是否通过: 是/否# 步骤3优化器改稿REFINER_PROMPT 你是一位 Python 开发专家。请根据审查反馈修改代码。原始需求: {task}当前代码:{code}审查反馈:{feedback}请输出修改后的完整代码用 python 包裹:defcall_llm(prompt: str) - str: 调用 LLM response client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], temperature0.2 ) return response.choices[0].message.contentdefextract_code(text: str) - str: 从 LLM 输出中提取代码块 ifpythonin text: return text.split(python)[1].split()[0].strip() return textdefreflection_agent(task: str, max_iterations: int 3) - str: Reflection 主循环 # 第一步执行写初稿 print(✍️ 正在生成初始代码...) raw_output call_llm(EXECUTOR_PROMPT.format(tasktask)) code extract_code(raw_output) print(f初始代码:\n{code[:300]}...\n) for i inrange(max_iterations): # 第二步反思审查 print(f 第 {i1} 轮审查...) feedback call_llm(REFLECTOR_PROMPT.format(tasktask, codecode)) print(f审查结果:\n{feedback}\n) # 检查是否通过 if是否通过: 是in feedback or是否通过是in feedback: print(f✅ 第 {i1} 轮审查通过) return code # 第三步优化改稿 print(f 根据反馈修改代码...) refined_output call_llm(REFINER_PROMPT.format( tasktask, codecode, feedbackfeedback )) code extract_code(refined_output) print(f修改后代码:\n{code[:300]}...\n) print(⚠️ 达到最大迭代次数) return code# 运行 if __name__ __main__: task 实现一个 LRU 缓存类支持 get 和 put 操作要求 O(1) 时间复杂度 final_code reflection_agent(task) print(f\n{*50}\n最终代码:\n{final_code})运行过程示意✍️ 正在生成初始代码...初始代码:class LRUCache: def __init__(self, capacity): self.capacity capacity self.cache {} ... 第 1 轮审查...审查结果:评分: 6/10问题列表:1. [严重] capacity 未校验传入 0 或负数会出问题2. [中等] get 方法未处理 key 不存在的情况会抛 KeyError3. [轻微] 缺少类型注解和文档字符串改进建议:1. 构造函数加 capacity 0 的校验2. get 方法返回 -1 表示未命中参考 LeetCode 规范3. 加上 type hints是否通过: 否 根据反馈修改代码...修改后代码:class LRUCache: def __init__(self, capacity: int): if capacity 0: raise ValueError(capacity must be positive) ... 第 2 轮审查...审查结果:评分: 9/10问题列表:1. [轻微] 可以考虑加 __repr__ 方便调试是否通过: 是✅ 第 2 轮审查通过看到了吗第一版有 Bug不校验 capacity、不处理 key 不存在经过一轮审查修正后代码质量明显提升。这就是 Reflection 的力量。4.5 Reflection 的成本收益分析说实话Reflection 不是免费的。小编掏心窝子跟你算笔账成本成本项具体影响API调用翻倍每轮迭代至少2次额外调用反思优化3轮就是6次延迟增加串行执行每轮等上一轮完成。简单任务从2s变10sPrompt设计成本要分别设计执行、反思、优化三套PromptToken消耗每轮把代码反馈全传一遍上下文越来越长收益收益项具体效果质量跃迁从“能用”到“好用”–修正边界条件、异常处理、性能问题可靠性增强内部纠错回路不依赖外部反馈就能修正逻辑错误减少人工审查Agent自己审完了你接手时问题已经少了很多结论Reflection 是典型的以成本换质量。什么时候用、什么时候不用小编总结一个决策表场景用Reflection不用Reflection写关键业务代码✅Bug代价高写技术报告/分析✅质量要求高简单问答✅一次就够实时对话✅用户等不了需要快速响应的场景✅延迟敏感“不是所有菜都需要反复试味——煎个鸡蛋就别搞三轮品鉴了。但做满汉全席每道都得反复调。”4.6 Reflection 的适用场景具体来说Reflection 最适合•代码生成与修复写完代码自己跑测试、审查、修正•长文写作写完初稿自己校对逻辑、事实、措辞•复杂推理数学证明、法律分析——初次推理容易有漏洞•决策支持方案制定后自我挑战有什么没考虑到的•多模态输出生成图片/代码后自我评估质量五、全景总结三种范式怎么选看到这里你对三种范式应该已经有了清晰的认知。小编用一张终极对比表帮你做决策维度ReActPlan-and-SolveReflection核心思想边想边做先想后做做完再想类比侦探跟线索建筑师画蓝图作家改稿循环结构想-做-看-想-…想-做做做-完做-审-改-审-…适合的任务探索型、需要工具交互结构化、可预规划质量敏感、需要精细不适合的任务需要全局规划的长流程探索型、未知步骤数实时响应、简单问答纠错能力中靠工具反馈弱执行中不纠错高自我审判Token消耗中低-中高多轮迭代延迟中低高串行迭代实现复杂度低低中三者的关系不是替代是组合说实话实际项目中小编很少只用一种。三者是可以自由组合的组合1Plan-and-Solve ReAct → 先规划步骤每步用 ReAct 执行有工具调用能力 → 适合需要规划 需要工具的复合任务组合2ReAct Reflection → ReAct 完成初步结果Reflection 审查修正 → 适合探索型任务但对结果质量有要求组合3Plan-and-Solve Reflection → 规划→执行→审查→修正 → 适合写长报告、做技术方案终极组合Plan-and-Solve ReAct Reflection → 先规划每步用 ReAct 执行最后整体审查 → 这就是当下最强 Agent 框架的底层设计事实上你现在用的 LangChain、LlamaIndex 等框架底层就是这三种范式的组合。框架帮你封装了细节但理解底层原理你才能在实际开发中灵活组合、针对性优化。“这三种范式不是’选择题’是’工具箱’——好的工程师知道什么时候用什么工具。”小编把三种范式的嵌套关系画清楚最内层 ReAct 负责执行单步中间层 Plan-and-Solve 负责全局规划最外层 Reflection 负责质量兜底。三层加起来就是一个靠谱的生产级 Agent。好了万字看到这里你现在对三种范式应该有了清晰的认知。•你的 Agent 只会调工具不会思考→ 先上 ReAct•任务复杂Agent 老跑偏→ 加 Plan-and-Solve•结果差点意思想让 Agent 自己打磨→ 上 Reflection•三个都想要→ 组合起来这就是当下最先进的 Agent 架构说实话小编自己在做 RAG 系列的 Agent 时就是 Plan-and-Solve ReAct 的组合——规划阶段列出步骤每步用 ReAct 执行因为要调检索工具。最近在考虑加 Reflection 层做结果质量检查。三层全上之后效果确实有质的飞跃。“从’能跑’到’跑得好’中间隔着一种思考方式的进化。”学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
