第 2 篇：Agent 的三种工作模式，选错了事倍功半

系列简介从零搭建一个多 Agent AI 助手覆盖原理、实现、部署全链路。不讲空话每篇都有可运行的代码。项目地址https://github.com/CodeMomentYY/LangGraph-Agent本篇目标理解 Agent 的三种工作模式知道什么场景用哪种。前言大家好我是一名前端工程师。都说前端“已死”那与其担心被 AI 替代不如打入敌人内部于是我开始折腾 Agent 开发。折腾下来发现Agent 的核心不是算法而是“工程能力”怎么设计架构、怎么串联服务、怎么把 LLM 的能力落地成产品。这些恰好是我们擅长的事。这个系列记录我从零搭建多 Agent 系统的完整过程。只聊技术知识和设计思路代码交给 AI 写。如果你也想从应用层切入 AI希望这个系列对你有帮助。读完本篇你将学到Agent 的三种经典工作模式范式每种范式的核心思想和适用场景三种范式的代码实现对比什么时候该用哪种什么时候组合使用背景与动机上一篇我们搞清楚了 Agent 的本质LLM 工具 循环。但“循环”具体怎么循环其实有不同的策略。打个比方你接到一个任务“帮我规划一次北京三日游”。方式 A边想边做。先查天气看到晴天那就安排户外景点再查景点发现故宫周一闭馆那换一个…一步步推进。方式 B先规划再执行。先列出三天的大纲Day1 历史、Day2 自然、Day3 美食然后逐个填充细节。方式 C做完检查一遍。先生成一版计划然后自己审视“有没有遗漏时间安排合理吗”不满意就修改。这三种方式对应 Agent 的三大范式ReAct、Plan-and-Solve、Reflection。核心概念我们对比一下这三种范式的流程用一张表来总结一下ReActPlan-and-SolveReflection核心思想边想边做先规划后执行做完自检循环方式思考→行动→观察→思考…规划→执行步骤1→执行步骤2…生成→反思→修改→再反思…优势灵活能应对意外有条理不遗漏质量高能自我修正劣势可能跑偏规划错了全盘皆输慢多次 LLM 调用适合场景简单查询、工具调用复杂多步任务写作、代码生成类比即兴发挥写提纲再写文章写完改稿动手实现ReAct 范式边想边做ReAct 是最常用的范式上一篇我们其实已经实现了。核心就是Thought → Action → Observation的循环 ReAct 范式边想边做 适合需要调用工具获取信息的场景 REACT_PROMPT你是一个助手请按以下格式思考和行动 Thought: 我需要做什么 Action: 工具名(参数) Observation: 工具返回的结果 ... (重复直到有足够信息) Thought: 我现在可以回答了 Answer: 最终回答 defreact_agent(user_input):messages[{role:system,content:REACT_PROMPT}]messages.append({role:user,content:user_input})for_inrange(5):# 最多 5 轮responsecall_llm(messages)ifAction:inresponse:# 解析并执行工具tool_resultexecute_tool(response)messages.append({role:assistant,content:response})messages.append({role:user,content:fObservation:{tool_result}})elifAnswer:inresponse:returnresponse.split(Answer:)[-1].strip()return处理超时特点每一步都能看到中间过程灵活应对意外情况。但如果任务复杂比如需要 10 个步骤可能会跑偏。Plan-and-Solve 范式先规划后执行先让 LLM 列出计划再逐步执行。适合复杂的多步任务 Plan-and-Solve 范式先规划后执行 适合复杂多步任务旅行规划、研究报告 PLAN_PROMPT请先制定计划再逐步执行。 格式 Plan: 1. 第一步做什么 2. 第二步做什么 3. 第三步做什么 然后逐步执行每一步。 defplan_and_solve_agent(user_input):# 阶段 1生成计划plan_responsecall_llm([{role:system,content:PLAN_PROMPT},{role:user,content:user_input}])stepsparse_plan(plan_response)# 提取步骤列表# 阶段 2逐步执行results[]forstepinsteps:resultcall_llm([{role:system,content:请执行以下任务步骤},{role:user,content:f任务{step}\n已有信息{results}}])results.append(result)# 阶段 3整合结果finalcall_llm([{role:system,content:请整合以下信息生成最终回答},{role:user,content:str(results)}])returnfinal特点有条理适合帮我写一份报告这种需要结构化输出的任务。但如果第一步规划错了后面全跟着错。Reflection 范式做完自检生成回答后让 LLM 自我检查不满意就修改。适合对质量要求高的场景 Reflection 范式生成 自我反思 适合写作、代码生成等需要高质量输出的场景 defreflection_agent(user_input,max_rounds3):# 第一次生成draftcall_llm([{role:system,content:你是一个写作助手},{role:user,content:user_input}])forroundinrange(max_rounds):# 反思检查质量critiquecall_llm([{role:system,content:请严格评审以下内容指出问题。如果质量够好回复PASS},{role:user,content:f原始需求{user_input}\n\n当前内容\n{draft}}])ifPASSincritique:returndraft# 质量够了# 根据反馈修改draftcall_llm([{role:system,content:请根据反馈修改内容},{role:user,content:f当前内容\n{draft}\n\n反馈\n{critique}}])returndraft# 达到最大轮次特点输出质量高但每多一轮反思就多两次 LLM 调用一次评审 一次修改速度慢、成本高。效果对比问同一个问题“帮我写一段产品介绍”三种范式的表现范式LLM 调用次数耗时输出质量ReAct1 次~3 秒一般Plan-and-Solve3-4 次~10 秒较好Reflection5-7 次~20 秒最好组合使用Plan ReAct Reflect实际项目中三种范式经常组合。比如“帮我规划北京三日游并写成攻略”看一下代码实现 三范式组合Plan 拆任务 → ReAct 执行每步 → Reflect 检查质量 defcombined_agent(user_input):# 阶段 1Plan拆解任务plancall_llm([{role:system,content:请将任务拆解为 3-5 个步骤},{role:user,content:user_input}])stepsparse_plan(plan)# 阶段 2ReAct逐步执行每步可调工具results[]forstepinsteps:resultreact_agent(step)# 复用上面的 ReAct 逻辑results.append(result)# 阶段 3Reflect整合并自检draftcall_llm([{role:system,content:请整合以下信息生成完整攻略},{role:user,content:str(results)}])# 自检一轮critiquecall_llm([{role:system,content:检查攻略是否完整有无遗漏},{role:user,content:draft}])ifPASSnotincritique:draftcall_llm([{role:system,content:根据反馈修改},{role:user,content:f{draft}\n\n反馈{critique}}])returndraft这就是我们后面搭建多 Agent 时用的思路——dispatcher 做 Plan判断走哪些 Agent各 Agent 内部用 ReAct调工具写作类任务可以加 Reflect。刨根问底序号问题1️⃣Q实际项目中只用一种范式吗A不是。实际项目经常组合使用。比如天气查询用 ReAct简单调一次工具就够了深度研究用 Plan-and-Solve先规划子任务再逐个执行写文案可以加 Reflection生成后自检修改。2️⃣Q怎么决定用哪种范式A看任务复杂度。一两步就能完成 → ReAct需要多步骤、有明确结构 → Plan-and-Solve对输出质量要求高、允许慢一点 → Reflection。3️⃣QReflection 会不会无限循环A会所以必须加 max_rounds 限制。而且有时候 LLM 的“评审员”和“写作者”是同一个模型可能会陷入“改来改去越改越差”的情况。所以实际使用中 2-3 轮就够了。本篇小结Agent 有三种经典工作模式ReAct边想边做、Plan-and-Solve先规划后执行、Reflection做完自检没有最好的范式只有最适合的——根据任务复杂度和质量要求选择实际项目中经常组合使用多种范式核心差异在于循环的策略不同底层都是 LLM 工具写在最后三种范式看起来是三种“技术方案”但本质是三种“思维方式”。ReAct 像是敏捷开发快速迭代、随时调整、Plan-and-Solve 像是瀑布模型先设计后实现Reflection 像是 Code Review写完回头审视。选范式和选开发流程一样没有万能解只有取舍。下一篇有了范式的认知接下来我们用 LangGraph 框架搭建一个真正的多 Agent 系统——多个 Agent 各司其职dispatcher 动态路由支持串行和并行执行。