做了半年多Agent相关的东西我有一个很深的感受现在很多Agent项目不是死在工具调用上而是死在“决策与规划”上。模型明明知道该干什么也知道手头有哪些工具但就是不知道下一步该做什么、什么时候该停下来、中间出错之后怎么自我修正。市面上的方案不少——ReAct、Plan-and-Execute、Reflexion、Tree of Thoughts各有各的适用场景也各有各的坑。这篇文章就把这四种典型范式的原理、实现方式、选型逻辑和实战经验一次说透给正在做Agent开发或者准备入局的同学一个能直接落地的参考。1. 内容整体设计与思路拆解1.1 为什么Agent的决策与规划是核心难题很多刚接触Agent的朋友会把注意力全放在“模型能力”上觉得只要GPT级别够高、工具够多Agent自然就能干活。真实跑过一阵子就会发现问题远没有这么简单。Agent和人一样面对的往往不是一个单步问题而是一个“一连串的小决策”先做什么、再做做什么、中间结果符不符合预期、不符合的话要不要换条路、信息不足时要不要先查资料、查完资料之后原计划还要不要继续。这一连串的决策本质上就是规划和推理问题。说实话大模型本身是有推理能力的你直接问它“从北京去上海怎么安排行程”它能给你答得头头是道。但一旦把它放进一个执行环境里让它自己决定调用哪个工具、怎么解析返回结果、如何编排多步动作它的表现往往就崩了。原因很简单模型缺乏一个“显式决策框架”它不知道什么时候该停下来思考、什么时候该直接行动、什么时候要根据反馈调整策略。这就好比一个刚从驾校毕业的司机科目二倒库倒得挺好真上路面对复杂的路况就手足无措了。所以要解决这个问题不能靠单纯调模型参数而是要给Agent套一个决策与规划的“骨架”。这四种范式就是四种不同形态的骨架。1.2 四种范式的整体定位与选型逻辑先给个总览方便大家建立整体概念。ReAct 的核心是“交替执行推理与行动”是那种边想边干、摸着石头过河的路子适合日常的工具调用类任务、需要与外部环境交互的场景。Plan-and-Execute 走的是“先总规划再分步执行”的路线类似于做项目前先写一份WBS工作分解结构然后照着执行适合长任务、多步骤、需要稳定推进的场景。Reflexion 的核心是“干完之后复盘反思、把教训沉淀下来”适合那种需要反复迭代、靠试错才能收敛的任务。Tree of Thoughts 则更激进它在每一步都尝试多条路径像一个岔路口不断分叉的思维树属于“广撒网再剪枝”的思路适合高难度的复杂推理问题。这里有一个非常关键的点这四种范式不是互相替代的关系而是互补的。我见过不少团队一上来就直接堆复杂的树状结构结果成本高、延迟大、效果也没见得好。正常做法是根据任务性质选一种作为主框架再把另一种作为辅助机制嵌进去。比如长任务用 Plan-and-Execute 做骨架中间每步的执行又套一层 ReAct 式的思考-行动循环来保证灵活性最后配一个 Reflexion 式的复盘模块来吸收失败教训。这个组合思路在后面会细讲。1.3 为什么选型必须考虑成本和延迟做Agent选型的时候很多人只看“效果”一个维度这是很大的误区。实际在线上跑成本和延迟往往是更先卡脖子的东西。拿 Tree of Thoughts 来说它每一步都要探索多个思路分支每个分支都对应一次或者多次模型调用token消耗是指数级增长的。你拿它解数学竞赛题可能效果惊艳但如果拿它去做一个日常的客服Agent用户等不起账单也等不起。ReAct 的好处就在这里体现出来了——它每一步只走一条路成本可控延迟也可控适合绝大多数在线服务场景。Plan-and-Execute 在成本上有另一个优势它把“每步都做完整推理”改成了“先做一次全局规划后面的每一步轻量执行”相当于把推理次数从 N 次压成了 1N 次。在步骤特别多的长任务里这个成本优势非常明显。我在实测中见过一个极端情况一个20步的网页自动化任务用纯 ReAct 做了42次模型调用换成 Plan-and-Execute 之后调用次数降到了24次差不多省了四成。这在生产环境里是可观的成本节省。2. 核心细节解析与实操要点2.1 ReAct边想边干Agent落地最常用的基底ReAct 的全称是 Reasoning Acting最早是Yao等人在论文中使用的方法也是目前生产环境里用得最广的一种范式。它的核心思想非常朴素让模型在每轮操作前先输出一段推理Thought然后决定要调用的工具Action等工具返回结果后再决定下一步Observation如此循环往复直到任务完成。ReAct 的工作流程可以用下面这个模式来描述Thought: 当前状态是什么下一步应该怎么做 Action: 调用某个工具的某项操作附上参数 Observation: 工具返回的结果 Thought: 根据观察结果重新推理……这里面的关键不是循环本身而是“Thought”这一步。模型在每次行动前强制自己先推理一步把当前情况、目标和下一步的打算说清楚这能显著降低模型“急吼吼地瞎执行”的概率也能减少幻觉。我在实际测试里发现加不加这一步思考最终成功率可能差20%以上尤其在涉及先后依赖关系的工具链上差距更明显。写 ReAct 的 Prompt 也是一门学问。一个我用了很多轮、验证过的 Prompt 模板大概是这样的你是一个任务规划Agent。你需要将任务拆解为多个步骤逐步执行。在每一步你必须严格按照以下格式输出 Thought: 你现在需要思考当前步骤是什么应该用什么工具来实现。 Action: 工具名(参数)比如 search(大模型原理) Observation: 执行工具后返回的结果。 当所有步骤都完成后输出 Final Answer: 最终答案。这个模板的精髓在于“格式约束”。通过强制模型输出 Thought → Action → Observation 的三段式结构你就把模型天生的自由散漫输出习惯给约束住了它被迫形成一种调用工具时的“纪律感”。实测下来明确的格式要求比模棱两可的“请逐步思考”要稳得多。2.2 ReAct 的局限与典型适用场景有一说一ReAct 也有明显的短板。首先是“走一步看一步”的近视问题它没有全局视野所以在长任务里容易出现路线偏差。比如你要做一个多步骤的数据分析任务ReAct 每一步都基于当前观察做决策走到第三步时可能因为当时的观察不够全面选了和全局目标相悖的操作然后一路跑偏。其次它对模型本身的推理能力有要求。小一点的模型在推理环节容易犯错一步错步步错而且没有自我纠偏机制。它是目前社区实践里最普适的基底范式尤其适合下面这些场景需要与环境持续交互的动态任务比如网页操作、代码执行、API 调用链任务本身没有长到让上下文爆炸的多步任务需要快速响应的在线服务场景做 Agent 开发ReAct 这套基底基本绕不开它是所有复杂方案的地基。理解了它再去看 Plan-and-Execute、Reflexion、Tree of Thoughts 这些进阶方案就有了坐标系。2.3 Plan-and-Execute先规划再动手长任务的稳定器Plan-and-Execute 的思路与 ReAct 正好相反。它不再“走一步看一步”而是先让模型一次性生成一份完整的执行计划Plan把大任务分解为若干个步骤然后由 executor 逐个步骤执行每执行完一步或者执行过程中发现原来的计划不适用了再进入 replanner 进行计划修订。这里要特别解释一下很多人把 Plan-and-Execute 简单地理解为“分步骤列表”这是不够的。它真正的设计核心有两个一个是“总计划贯穿全局”另一个是“执行步骤之间允许反馈修正”。前一个保证了任务的长线一致性后一个保证了任务不至于因为一刀切计划而死板。整个方案的流程大致长这样Plan: 先生成完整计划列出1, 2, 3, ... N 步 Step 1: Executor 执行第1步 Step 2: Executor 执行第2步 ... 某一步执行失败或结果异常 → 触发 replanner → 调整/重排后续计划 → 继续执行 全部执行完成 → 汇总输出这套思路最典型的使用场景就是那些需要十几个、几十个步骤的长任务。比如爬取一个网站的数据并整理成表格或者自动化处理一批文件。我做过一个电商竞品追踪的Agent需要每天定时抓取多个商品页、提取价格、做环比分析、生成报告。一开始用 ReAct 硬跑跑到第六七个步骤的时候上下文开始飘了工具返回的数据偶尔会污染决策后来改成 Plan-and-Execute 的思路之后稳定度明显提升。2.4 这套方案的成本优势和“重新计划”的正确打开方式成本方面前面提过Plan-and-Execute 最大的优势是省掉了“每步全方位推理”的开销。规划的过程只有那么一两次后面的执行步骤本质上是“拿着模块化的工具装配”不涉及复杂推理。要注意的是这个方案别做成“纯死板执行”否则遇到真实世界里的扰动就会僵住。比如你计划第一步是某个网页搜索结果但搜索返回的内容和预期不一致整个后续计划就要调整。这种时候如果没有 replanner 兜底Agent 就会死板的按原计划继续结果越走越错。我的建议是把 replanner 的触发条件设得宽一点不要等完全失败了才触发。我在项目里通常设定只要 executor 反馈“步骤没达到预期目标”或者“外部数据与规划前提不一致”就立刻请求模型重新评估后续计划。虽然这样会带来一些额外调用但整体效率反而更高因为你避免了一路走下去全部返工的巨大浪费。2.5 Reflexion让Agent学会“吃一堑长一智”Reflexion 的出发点很朴素既然大模型做复杂任务时容易犯错误为什么不让它像人一样“复盘”一下自己的表现然后把教训显式记下来下次遇到类似情况就知道避坑了这个机制在实现上包括三个模块Actor负责实际行动、Evaluator负责评估行动结果的好坏、Self-Reflection负责把失败原因转成自然语言的经验。经历了行动-失败-反思之后反思得到的文本会写回到 memory 里在下一个轮次开始之前注入到上下文中作为参考。可以这样理解Reflexion 不是换了一个新的推理框架而是在 ReAct 或者 Plan-and-Execute 这类执行框架外面包了一层“训练回路”。每一轮执行后系统都会对结果打分如果分数不理想就调用反思模型针对失败点生成改进建议带着建议爆一爆再来一轮。我在一个基于代码生成的场景里试过 Reflexion当时任务是根据自然语言描述生成一个可执行的自动化测试脚本。第一轮写出来的脚本运行报错率高但把报错信息结合 evaluation 结果一起喂给反思模块后第二轮脚本的通过率直接涨了三十多个点第三轮基本稳定。这里面的关键在于“反思文本的质量”。如果反思只是笼统地说“注意语法错误”——那跟没有差不多必须针对具体失败点给出可操作的建议比如“在第17行调用了未定义的函数应该先 import 对应模块”。2.6 Tree of Thoughts给Agent一副“树状探索”的大脑Tree of Thoughts思维树通常简称ToT是一个更重的方法适合高难度、本身就无法一步到位的推理任务。它的核心思路是在每一个推理步骤不只有一个候选下一步而是同时生成多个候选思路每一个候选对应一个节点挂到树上。然后对节点进行评估评估打分或者模型自评用广度优先或者深度优先的策略去探索这棵树最终找到一条从根到叶的最佳路径。听起来有点抽象我举个实际的例子。假设你要推理一个复杂的逻辑谜题传统 ReAct 是一个念头走到黑走错了就完蛋。而 ToT 会在第一步生成“可能A、可能B、可能C”三种解释然后分别对这三种可能向下延伸每条路径走几步之后如果某条分支明显走不通就剪掉它最终你会得到一条经过筛选和验证的推理路径。这个思路其实很像人类面对复杂问题时的“头脑风暴 方案淘汰”是几种范式中最贴合“深度思考”的一种。代价也是明摆着的——每一步多路探索的 token 开销和延迟是普通方案的数倍甚至一个数量级。所以日常应用基本别指望拿它做在线Agent服务它更适合做离线分析、复杂推理研究、推理模型评测这类不计较成本的任务。3. 实操过程与核心环节实现3.1 游戏类任务ReAct的完整实现示例光讲原理不落地等于白讲。我拿一个非常经典的 Agent 实验场景来演示 ReAct 怎么一步步实现让Agent根据当前环境状态猜出隐藏的单词。这种游戏场景的逻辑跟真实工具调用没什么本质区别每一步都需要根据观察结果重新调整决策。先定义工具环境用 Python 写一个简化版# environments.py class GuessEnv: def __init__(self, secret_word): self.secret_word secret_word self.steps 0 self.hint_pool [这个词是5个字母, 第一个字母是A, 最后一个字母是E, 中间有一个字母是L, 这个词和后缀PLE有关] def get_observation(self): return self.hint_pool[min(self.steps, len(self.hint_pool)-1)] def submit_guess(self, guess_word): self.steps 1 if guess_word self.secret_word: return True, 回答正确 else: return False, 回答错误然后写一个 ReAct 的推理循环核心逻辑就是让模型基于当前 observation 输出 Thought 和 Action并根据 Action 调用工具、返回新的 observationimport openai def react_loop(env, max_steps10): messages [ {role: system, content: 你是一个猜词Agent。你必须按以下格式输出\n Thought: 分析当前线索推理可能的单词\n Action: submit_guess(\你的猜测\)} ] obs env.get_observation() messages.append({role: user, content: f当前线索{obs}}) for _ in range(max_steps): response openai.ChatCompletion.create( modelgpt-3.5-turbo, messagesmessages, temperature0.2 ) output response.choices[0].message.content # 解析模型输出中的 Action if Action: in output: action_text output.split(Action:)[-1].strip() # 这里解析动作并调用环境 guess extract_guess(action_text) success, result env.submit_guess(guess) messages.append({role: assistant, content: output}) messages.append({role: user, content: fObservation: {result}}) if success: return guess, env.steps else: break return None, env.steps这套代码看着简单但有几个容易踩坑的地方。第一模型不一定严格按格式输出有时会把 Thought 和 Action 混着来解析 Action 的正则或文本处理逻辑要写得足够鲁棒否则一条格式错误的输出就可能导致整个循环结束。第二temperature 建议设置低一些比如 0.2这个任务需要的是稳定推演而不是发散创造。第三记得控制轮次上限避免模型陷入无意义的死循环。3.2 Plan-and-Execute 的生产落地配置再来看 Plan-and-Execute 的落地。我用 LangChain 提供的现成方案作为例子但你自己写也行核心流程是一致的。from langchain.agents import AgentExecutor, create_plan_and_execute_agent from langchain.agents.plan_and_execute.executors_for_agent import load_agent_executor from langchain.agents.plan_and_execute.planners.chat_planner import load_chat_planner planner load_chat_planner(llm) executor load_agent_executor(llm, tools, verboseTrue) agent create_plan_and_execute_agent(plannerplanner, executorexecutor)实际生产环境里我一般不直接用 LangChain 的默认配置而会自己定制两个细节。第一个是 planner 的输出格式我会强制它输出结构化的 JSON里面包括steps每个步骤的名称、描述、依赖关系和success_criteria每一步完成的判定标准。第二个是在 executor 和执行器之间加一个“结果检查器”它负责对比实际结果和计划的 success_criteria一旦发现偏差就触发 replan。{ plan: [ { step_id: 1, description: 获取商品页面列表, tool: crawler, success_criteria: 拿到了至少10个商品的URL }, { step_id: 2, description: 抽取每个商品页面的价格信息, tool: html_parser, depends_on: [1], success_criteria: 每个URL都成功抽取到价格 } ] }这套定制在实际项目里效果非常明显。默认配置下Executor 常常会“自作聪明”地把两个步骤合并或者跳过尤其是那些隐含依赖关系的步骤一偷懒就出错。加了 success_criteria 并且设置了强校验之后计划内的每个步骤都被强制独立完成整体可靠度提升了非常多。3.3 Reflexion 的 memory 注入实现Reflexion 实现起来并不神秘本质是把过往反思文本缓存起来然后在下一轮对话里注入。这里的关键是 memory 的组织方式。我用过一个有效的方法是“按失败模式分组”也就是把反思文本打上标签比如“超时”、“格式错误”、“逻辑不一致”新一轮遇到类似错误时优先注入对应标签的经验。伪代码大致长这样class ReflexionMemory: def __init__(self): self.experiences [] def add_experience(self, experience_text, tags): self.experiences.append({text: experience_text, tags: tags}) def get_relevant_experiences(self, current_error_tags, max_items3): relevant [e for e in self.experiences if set(e[tags]) set(current_error_tags)] return relevant[-max_items:] # 只取最近的几条经验 # 在每一轮开始前把相关经验拼到 system prompt 里 def build_prompt_with_memory(memory, current_state): experiences memory.get_relevant_experiences(current_state) exp_text \n.join([f经验{i}: {exp} for i, exp in enumerate(experiences)]) return f参考之前失败的经验\n{exp_text}\n现在进行新一轮尝试。之所以只取最近几条是因为反思文本一旦多了全部塞进上下文反而会稀释模型的注意力还白白增加 token 成本。经验文本需要频繁更新老经验对当前问题往往已经失去参考价值它会带来一些噪声。3.4 Tree of Thoughts 的核心步骤与采样策略Tree of Thoughts 的实现要稍微复杂一些但核心模块并不神秘一个生成候选步骤的 generator一个评估候选优劣的 evaluator以及一个搜索控制模块决定用 BFS 还是 DFS。以 BFS 搜索为例每一层保留打分最高的 k 个节点继续往下展开其余直接剪枝def bfs_search(problem, generator, evaluator, max_depth3, beam_size2): # 根节点当前状态 frontier [{state: problem[initial], path: []}] for depth in range(max_depth): candidates [] for node in frontier: # 基于当前状态让模型生成多个候选下一步 next_options generator(node[state], num_options4) for option in next_options: candidates.append({ state: option[next_state], path: node[path] [option[description]] }) # 打分层保留最优的 beam_size 个节点 scored [] for cand in candidates: score evaluator(cand[state]) scored.append((score, cand)) scored.sort(keylambda x: x[0], reverseTrue) frontier [cand for score, cand in scored[:beam_size]] # 最终返回得分最高的路径 best_score, best_cand max( [(evaluator(cand[state]), cand) for cand in frontier], keylambda x: x[0] ) return best_cand[path]这里有两个参数特别敏感。第一个是beam_size取值太大搜索空间爆炸延迟和成本都收不住取值太小又容易把正确的分支提前剪掉。我实测下来多数复杂逻辑推理任务 beam_size 取 2 到 3 之间比较稳妥。第二个是num_options即每一步生成多少候选这个取决于模型的发散能力太少了等于没得选太多了重复度高、白白烧 token。我习惯设置 4 到 5 个。另外evaluator 不要简单地让模型给个 1-10 分数字化打分很容易变成评估模型的自嗨同一个状态下不同时间打分结果差异可能很大。更好的做法是让评估模型先输出“这个状态为什么有潜力/为什么没潜力”再结合推理过程给分。毕竟反思需要有依据评估要能讲清楚理由这样才能指导后面的行动。4. 常见问题与排查技巧实录4.1 ReAct 循环的典型故障格式混乱和死循环ReAct 在实践中最常见的问题有两个。第一个是模型输出格式不听话正则解析不到 Action。这个问题本质上是模型对格式约束的理解不稳定尤其是用一些较小的模型时经常出现 Thought 和 Action 黏在一起、Action 拼错工具名的情况。解决办法是在构造 Few-shot 示例时把“错误格式”和“正确格式”的对比示例都放进去让模型有明确的参照。如果模型还是经常出错可以直接在生成后做一层结构修复用正则把所有 Action 行抽出来抽不出来就让模型重新输出一次。第二个是死循环。模型在某个状态下反复调用同一个工具拿到的 Observation 不变它的下一步决策几乎也不变于是陷入 while 循环里。这种问题的排查思路是在调用历史里检测“重复的 (Thought, Action, Observation)”组合一旦检测到连续三次重复就打断循环并向系统注入一条新指令比如“上一个动作没有产生新信息请放弃当前思路尝试换一种方式”。4.2 Plan-and-Execute 里我踩过的典型坑这个方案让人头大的地方往往是“计划对了执行时跑偏”。我把踩过的坑整理了一下比较常见的有三个计划粒度太粗比如计划里写“分析用户数据”Executor 根本不知道具体要从哪个维度分析结果分析出来的东西不是你要的。解决办法是尽可能把计划拆细每一行都是可执行的指令像一个技术方案里的子任务而不是一个模糊的方向。执行结果没有校验就直接进入下一步经常出现“上一步结果已经是空的了下一步还在依赖它”。我的做法是给 Executor 加一个强制的自校验 Prompt即输出前必须给出一句 completion check说明为什么认为本步骤已经完成了把计划里的 success_criteria 逐条对一遍。replanner 太懒模型本质上是有惰性的如果没发生显式错误它倾向于不修改原计划哪怕现实世界已经变了。我的解决策略不是等模型主动发现而是用规则检测“当前数据与计划前提不一致”这个信号触发 replanner。触发条件写硬规则比让模型自觉要可靠得多。4.3 Reflexion 的反思失效经验注入挤占主任务空间Reflexion 失效的典型表现是加入反思经验之后任务成功率不但没提升反而下降了。这种事的根源往往是“反思文本质量差”或“注入方式不当”。我见过一个团队把大量反思文本直接拼进 system prompt结果模型被一堆“不要做某某事”的负向指令包围主任务推理反而变保守了很多合理操作都不敢执行。我的调整建议是两条。第一反思文本控制数量只保留与当前任务类型相关且最近生成的 2-3 条宁可少而精不要多而杂。第二把“反思”从“禁止性指令”改为“建设性建议”比如“在第2步之前应该先验证数据是否为空”要好过“不要再直接使用数据”。训练模型做反思时明确提出“针对失败原因给出可执行改进建议而不是罗列错误”这是能立刻见效的改动。4.4 Tree of Thoughts 的常见性能瓶颈ToT 如果跑起来效果不好先检查是不是搜索策略本身的问题。第一种常见是分支评估打分失真评估模型给各个分支打的分数区分度太低选不出好分支。解决方法是换一种评估方式例如让模型先输出“该分支成立的三个条件和两个风险”再综合判断。第二种常见是候选生成质量低模型在同一个节点上生成的候选其实高度相似导致搜索空间全是冗余路径。此时可以刻意降低温度、增加生成条数并且要求模型“从三个不同角度生成思路”强行提升多样性。成本控制上也值得注意。每次 BFS 探索的模型调用量等于候选数乘以层数几层下来几十次调用很轻松。我一般会给整个搜索过程设置一个全局 token 预算一旦超了就自动降级为“以当前最优路径继续走到底”不再广撒网。这个降级策略虽然理论性不强但在生产环境里非常好用它让 ToT 既能用在严肃推理场景又不会被账单吓退。4.5 常见问题速查表问题现象可能原因排查与解决建议ReAct 输出格式混乱解析不到 ActionFew-shot 示例不足模型对输出结构理解弱补充“正确格式/错误格式”对比示例增加解析后置校验Agent 反复调用同一工具无进展模型陷入局部最优无法摆脱相同观察检测连续重复三元组强制打断并提示换思路Plan 的执行者跳过隐式依赖步骤Executor 过度“智能”自行合并步骤为每一步设置 success_criteria独立校验和记录计划与实际环境脱节replanner 触发条件过严用硬规则检测“数据与前提不符”信号比模型自觉更可靠反思经验注入后效果反而变差反思文本冗余、负向指令过多限制注入条数把“否定式”反思改成“建议式”改进ToT 各分支分数区分度低数值化打分不敏感要求评估模型先给出理由、理由充分后再打分ToT 候选分支高度雷同模型发散性不足多生成若干条候选并显式要求“从不同角度思考”整条链路 token 成本失控每步都做全量推理缺少策略约束使用 Plan-and-Execute 压缩推理次数全局设置 token 预算并降级5. 四种范式横向对比与实战选型建议5.1 一张表看透四种方案的核心差异把这四种范式放在同一个坐标里对比它们的差异会非常清楚。我按“核心思想”“需要什么能力”“最擅长解决什么”“主要弱点”“成本量级”五个维度做了个表基本覆盖了选型时需要关注的所有关键要素。范式核心思想需要什么基础能力最擅长解决的场景主要弱点成本量级ReAct推理与行动交替执行较强的单步推理能力工具调用、环境交互、动态决策局部视角长任务易跑偏低到中Plan-and-Execute先全局规划再分步执行较强的任务分解能力长流程多步骤、需要全局规划的任务对变更响应不及时需要 replan 兜底中Reflexion执行后反思经验沉淀复用较强的错误分析能力需要反复试错的迭代式任务依赖高质量的反思文本和记忆组织中高需要多轮Tree of Thoughts多路径探索搜索后择优较强的评估和探索控制能力高难度逻辑推理、非结构化复杂问题调用量大、延迟高、成本高高到很高选型建议我个人的习惯是如果一个任务本质是“在现实环境里调用工具干活”优先 ReAct因为它动脑子成本低、反应快如果任务步骤特别多且有明确流程换成 Plan-and-Execute它会让你少操很多心如果任务反复失败但你知道能通过迭代解决则加上 Reflexion 外壳如果任务是真的硬骨头靠线性思路根本解不开那再动用 Tree of Thoughts。5.2 组合使用生产环境中真正能打的方案真正跑生产我发现单一范式很难包打天下。组合使用往往效果更稳而且代码架构并不复杂。我目前比较常用的一个组合套路是这样外层用 Plan-and-Execute 搭主流程保证任务的全局方向不飘每一步的内部执行层用 ReAct 的思考-行动循环保证单步动作灵活应对环境变化整个任务跑完一圈之后无论成败都做一次 Reflexion 复盘把经验写进 persistent memory 里供后续任务参考。至于 Tree of Thoughts它更多是用在“离线医案分析”这类最复杂的核心环节按需接入不参与日常链路。这个组合思路在工程上的优势很直接Plan-and-Execute 给了系统骨架ReAct 给了单步的灵活性Reflexion 让系统具备了“经验积累”能力相当于给 Agent 加上了长期记忆ToT 则是最后的一把杀手锏。四个各司其职互补效应远大于单个范式单打独斗。5.3 线上环境落地时的工程注意点最后聊几个工程上的细节这些是天天跑线上才会注意到的坑。工具调用的超时控制任何 Agent 框架都务必给工具调用设置一个超时时间。哪怕是一个搜索请求网络抖动也可能让它卡上几十秒。超时了之后要有重试逻辑重试两三次还失败就要把失败信息传给模型让它决定是否换工具或调整方案。上下文长度管理ReAct 的循环会不断把新的 Observation 追加到对话历史里任务一长上下文就会膨胀。我的做法是定期把历史摘要化把早期对话压缩成一段摘要文本只保留最近几步的完整日志。这能有效避免“长任务上下文突然爆掉”的经典事故。安全与权限边界这个问题容易被忽视但极其重要。Agent 如果能自由调用系统工具比如执行命令、修改文件、发送请求它一旦决策失误风险可能直接被放大。我强烈建议在工具层做权限分级例如只读工具、写入工具、执行类工具分别走不同的授权策略。目前行业里关于 “agent安全”、“agent harness” 的讨论也越来越热说明这不是小题大做而是每个 Agent 项目都要提前考虑的基础设计。工具本身是好工具但使用工具的决策系统还不够成熟必须用工程手段兜住风险底线。根据我个人反复测试多种组合方案的经验最后想提醒一点别一上来就上最重的方案也别指望某个单一范式能解决所有问题。先拿 ReAct 跑通最小闭环再逐步叠加 Plan-and-Execute 的长任务骨架、Reflexion 的经验沉淀最后才按需引入 Tree of Thoughts 这种重量级武器。在 Agent 项目的实际开发中决策规划模块并不是越多越高级而是越适合越好。只有当你亲手跑过一个任务看着它一步步地从错误和反思中找到正确答案时你才算真正理解为什么这四种范式会在 Agent 架构中占据一席之地。希望这篇整理能帮大家少走几步弯路做 Agent 开发的时候有一个更清晰的判断坐标。