Agent 架构学习-1单智能体框架单智能体Agent框架1、ReAct定义优点缺点2、Plan-and-Execute定义优点缺点3、Reflexion定义优点缺点4、ReWOO定义优点缺点5、LLMCompiler定义优点缺点总结最近在学习Agent搭建在看了不少项目后打算先仔细研究下现有的主流Agent架构设计以更好地了解如何搭建不同期望目标的Agent系统。我将分单智能体场景和多智能体场景分别介绍Agent框架展示框架的核心思想、具体例子、优缺点。单智能体Agent框架1、ReAct定义可以说所有复杂 Agent 的起点都是“推理-行动”的基本循环。其中最经典的范式是ReActReasoning ActingReAct框架的核心思想是将推理与工具交替使用在一步步完整的推理中获得最终的答案。用一个简单while循环展示即是初始化消息列表 [用户问题]; while 未得出最终答案: 将消息发给 LLM; if LLM 返回最终答案 return; else LLM 返回工具调用 执行工具得到结果; 消息列表调用结果;作为最基础的框架ReAct的优缺点如下优点1推理过程透明可解释性极强由于每一步推理都会输出“思考 → 行动 → 观察”的完整链条调试时能清楚看到模型在哪一步调用了某个工具、从结果中提取了什么信息。2动态适应由于ReAct 会根据每一步的观察实时调整消息假如搜索到额外信息它可以立刻改变策略非常适合信息不确定、需要多步探索的任务。3工具使用灵活由于推理和工具的交替工具调用的时机、顺序完全由模型基于当前上下文决定而不是被固定流程图限制。扩展新工具也非常简单只要加入可使用工具列表模型就能自适应地组合使用。4实现门槛极低基于 Function Calling 的 ReAct Agent只需几十行代码就能跑通概念直观不需要依赖复杂的图编排或状态机等规划因素。5支持错误修正当工具返回不理想的结果或模型得出之前推理有偏差的结论在下一轮思考即可主动纠正重新搜索或换工具。缺点1串行执行延迟高、效率低几乎每次行动都是完整的推理与调用必须先完成思考再等工具返回然后才能继续下一次思考。即使是互不依赖的多个工具调用传统 ReAct 也会串行处理导致大量等待时间。2上下文窗口消耗极快每一步推理的结论都堆积在消息列表中如果是多步任务则会让上下文迅速膨胀不仅token成本增高还可能超出模型窗口限制导致信息丢失或拒绝继续推理。3全局规划能力弱易陷入局部最优ReAct没有对整体任务结构的规划面对复杂的大型任务它无法像 Plan-and-Execute 架构先制定最优路径可能选择绕远路、重复劳动甚至走入死胡同。4死循环与重复行动风险由于没有全局记忆与强制停止机制模型可能重复调用相同工具、反复陷入失败后重试的循环。5对模型推理能力高度依赖如果模型本身的推理、格式遵循能力不强尤其是一些小模型容易产生错误的工具调用参数、幻觉式的推断或无法正确从观察中提取有效信息结果的质量高度依赖模型。6错误步步传播假设在推理过程中某个工具返回了不准确或有误导性的结果模型并没有识别出错误ReAct 会直接基于它继续推理缺乏对信息源的质疑和验证机制结果可能“失之毫厘谬以千里”。2、Plan-and-Execute定义这个框架的核心思想是对任务与执行进行解耦。很多复杂的任务出于全局最优考虑会先将任务整理成完整的计划再逐步执行这个框架就是Plan-and-Execute架构分为两部分规划器Planner和执行器Executor规划器 输入用户的目标、任务 输出一个完整的结构化的计划通常是一个步骤列表每个步骤描述需要做什么包含要调用的工具和参数。 实现方式调用一次 LLM通过精心设计的提示词生成计划并规范为结构化输出。 执行器 负责读取计划按顺序执行工具调用并将前一步的输出作为后一步的输入优点1显著降低 LLM 调用次数与 Token 成本规划仅需一次调用后续执行可以是纯工具调用。2支持并行化由于清晰的步骤让批量并发执行成为可能大幅降低整体延迟3全局优化规划器能看到任务全貌可能发现更优的分解路径例如合并同类查询。4清晰可控计划对人类可读易于审查和干预可以在执行前由用户修改计划。缺点1对环境变化不敏感计划一旦固定如果中间步骤获取的信息发生变动与计划不符原规划可能反而是错误的。2计划本身的准确性依赖模型若模型对任务理解偏差可能生成不合理计划导致整个任务失败。3增加设计复杂度需要增加设计 Planner 与 Executor 间的接口、上下文传递机制和重规划逻辑。4对于高度交互式、需求不明确的任务容易出错比如用户说“帮我找点好吃的”无法预知搜索路径ReAct 更灵活。3、Reflexion定义这个框架的核心思想就是反思与自改进。如果说 ReAct 让 Agent 学会了“边想边做”Plan-and-Execute 让它学会了“谋定而后动”那么 Reflexion 则赋予了它一套内省机制——任务失败后不白费而是把失败经验转化为文字化的“反思”存入长期记忆中以便下次遇到相似情境时能主动避开陷阱。这个架构包含四个部分Actor执行者、Evaluator评估者和Self-Reflection自我反思、长期记忆库。Actor执行者 Actor负责在环境中执行动作、使用工具、产生最终回答但与普通 ReAct 有两个重要区别 1、它的上下文不仅包含当前任务的交互历史还包含从长期记忆中检索出的相关反思。 2、当 Evaluator 判定它失败后它会产出一段完整的执行轨迹trace供反思模块分析。Evaluator评估者 Evaluator 负责判断 Actor 的一次尝试是成功还是失败。它可以是 1、基于规则的例如检测答案是否包含特定关键词或是否符合期望格式。 2、基于 LLM 的将 Actor 的最终输出与标准答案或评分标准一起交给 LLM 进行评判。 3、对于多步任务也可以结合中间步骤的正确性。 如果判定为失败Evaluator 会将失败信号连同执行轨迹一起传递给反思模块。Self-Reflection反思生成器 Self-Reflection通常由一个单独的 LLM 调用完成 输入 1、完整的执行轨迹Thought → Action → Observation 序列 2、失败信号或最终的低分评价 3、可能会对比正确的解决方案如果可用 输出一段自然语言文本指出失败的原因并提供改进建议。长期记忆库 Self-Reflection生成的反思一旦生成就会存储到长期记忆中通常是一个向量数据库记忆的索引信息可能包括 1、任务类型或目标描述 2、失败的原因 当 Actor 执行新任务时它会从记忆中检索与当前情境最相关的反思并嵌入到提示词中作为“过去经验”来引导行为。优点1持续自我改进随着经历增多长期记忆的积累Agent 的成功率会逐渐提高并减少错误的工具调用。2跨任务泛化反思是自然语言具有强泛化性一个领域的教训可能被迁移到相似领域。3不依赖参数更新通过提示词内的记忆影响行为无需微调模型易于集成到现有 LLM或跨Agent继承。缺点1反思生成的质量至关重要如果反思本身不准确或过于宽泛反而会误导 Actor。2记忆检索的相关性如何确保检索到的反思真正适用于当前任务需要良好的检索策略如语义搜索。3额外的延迟与成本每次失败都要额外调用 LLM 生成反思且重试会增加总步骤数。4可能收敛到次优策略反思有时会固化局部有效但非全局最优的行为模式。4、ReWOO定义当任务需要调用大量工具时ReAct 的串行等待就成了瓶颈。以上几个框架都是串行执行的如果一个步骤需要调用大量工具串行的等待会大大增加任务的完成时间。为了实现并行处理ReWOO 应运而生ReWOO 的全称是ReasoningWithOutObservation即在推理时不等待观察结果。它将整个任务处理分成三个完全解耦的阶段Planner计划器 一次性生成一个包含工具调用占位符的“蓝图” 输入用户问题 “比较北京、上海、广州今天天气并推荐最适合户外运动的城市” 输出“推理步骤工具调用占位符”交织的计划 eg 1. 获取北京天气 #E1 search(北京天气) 2. 获取上海天气 #E2 search(上海天气) 3. 获取广州天气 #E3 search(广州天气) 4. 根据 #E1, #E2, #E3 的结果比较并推荐最适合户外运动的城市。 这里的#E1、#E2等就是工具调用的占位符Worker 尽可能并行执行依赖已满足的工具调用获取真实结果。 上例中#E1、#E2、#E3都是无依赖关系的可以全部并行执行得到真实结果并与对应的占位符绑定Solver 将执行结果回填到蓝图生成最终答案。 将 Worker 绑定的所有变量值回填到 Planner 生成的原始计划模板中再交给 LLM 做最后一次推理生成最终的自然语言答案。 即只需要调用一次LLM完成Planner中的第4步优点1LLM 调用次数极低仅 Planner 和 Solver 各一次调用中间 Worker 阶段是纯工具执行不涉及 LLM。2并行执行工具Worker 可以根据依赖图并发执行多个工具极大压缩了时间。3上下文窗口友好Planner 生成计划时上下文很轻只含用户问题Solver 也只是将计划模板和结果拼接不会像 ReAct 那样堆积长长的历史记录。缺点1依赖关系必须在规划时完全确定如果某个工具的结果格式与预期不符或者需要根据动态结果调整后续步骤ReWOO 会非常僵硬。例如搜索结果返回了意外格式导致后续占位符替换失败。2不支持条件分支和循环计划是静态的无法表达“如果 A 结果为空则走 B 路线”。3对 Planner 的能力要求高必须一次性生成包含正确依赖关系和变量引用的计划模型较小时容易出错。5、LLMCompiler定义如果说 ReWOO 是借用占位符静态描述依赖那么LLMCompiler则更进一步它直接在 LLM 内部生成了一个带依赖关系的有向无环图DAG然后由专门的调度器像一个编译器一样高效执行LLMCompiler 的核心思想是许多工具调用构成了一个计算图节点是任务工具调用边是数据依赖。它可以把这个图的执行并行化同时仍然尊重依赖顺序。它主要由三个组件构成Planner生成一个任务列表DAG每个任务包含工具名、参数、以及依赖的任务ID。 Task Fetching Unit一个专门的调度器负责从 DAG 中动态抓取已就绪的任务并分派执行。 Executor执行具体的工具函数并将结果返回给调度器从而解锁更多任务。这里不再举单框架完整的例子而是通过对比的方式来直观感受LLMCompiler框架对比ReWOO框架的优越性。Planner阶段 ReWOO框架生成工具调用占位符 LLMCompiler框架生成一个JSON格式的任务列表显式地标出依赖和工具调用Worker阶段/Task Fetching Unit阶段 ReWOO框架解析依赖在看见任何数据之前就形成固定的执行计划 LLMCompiler框架调度器维护两个集合就绪任务队列和等待依赖的任务池能动态扩展任务图举两个相反的执行过程例子假设B任务依赖A任务ReWOO框架设置了2个占位符#E1LLMCompiler框架则是标明了依赖关系。1如果A的结果输出为3个ReWOO框架则只能舍弃1个结果进入B任务LLMCompiler框架则可以动态扩展带着3个结果进入B任务2如果A的结果输出为0个则ReWOO框架只能尴尬地浪费调用LLMCompiler框架则可以动态调整跳过B任务。能动态扩展缩减任务图和不能这就是两个框架最大的区别。优点1极致并行效率流式调度实时解锁后继任务并立即并行执行时间趋近关键路径长度延迟压至理论下限。2动态任务注入元任务可根据中间结果动态生成新子任务并挂载到 DAG轻松处理条件分支适应性远超静态方案。3显式依赖图结构化 DAG使依赖解析可靠、便于可视化调试还可进行合并、剪枝等编译优化提升可预测性。4调度与执行解耦Task Fetching Unit独立于 LLM 和工具可灵活替换组件、实现优先级与并发控制架构更健壮。5容错与重规划基础任务失败时能精准定位受影响的子图支持增量重规划和动态替换修复效率高且不中断整体流程缺点1实现复杂度高需构建 DAG 调度器、动态注入协议、状态管理和并发控制工程量大调试负担重。2强依赖 LLM 规划正确性要求 LLM准确拆解任务、标注依赖一旦出现循环或遗漏调度器可能死锁或乱序执行。3调试困难错误可能来自 DAG 结构、工具执行或调度器逻辑动态注入后因果链复杂难以快速定位。4短小任务无收益并行优势需足够多独立工具调用支撑步骤少的任务反而因规划调度开销导致延迟增加。5动态注入的双刃剑可能生成大量不必要子任务导致执行爆炸或产生错误依赖需严格控制。6上下文与成本压力生成完整 DAG 和整合大量工具结果时提示词仍可能过长影响最终输出质量并增加成本。总结从工程学角度考虑对以上框架可以直观地对比架构实现复杂度推理延迟LLM 调用次数并行执行动态适应性鲁棒性上下文消耗错误恢复适用任务ReAct极低一个 while 循环即可高严格串行每步等待工具与推理最高每步一次推理不支持极强每一步都可即时调整中可能陷入循环或错误传播极高历史消息持续堆积仅限单步自我修正探索性强、步骤不确定性高的任务Plan-and-Execute低需要规划器和执行器中等执行可部分并行但规划串行低规划一次执行零推理支持但依赖关系需静态确定弱需额外重规划机制中计划不当时整体失败低仅需存储计划与结果可触发全局重规划步骤清晰、依赖固定的结构化任务Reflexion中需评估器、反思生成和记忆检索中等与底层架构相同但会重试增加延迟高失败重试增加额外反思调用取决于底层架构强通过记忆跨任务适应高能持续从错误中学习改进中需管理反思记忆强历史反思引导避免重复错误需多次尝试的复杂推理、封闭评估场景ReWOO中低需 PlannerWorkerSolver 三阶段低Worker 阶段批量并行极低仅 2 次规划汇总静态批量并行依赖占位符解析极弱无法处理条件分支低占位符替换易因格式不符失败极低Plan 轻量无中间对话历史几乎无计划失败即终止工具调用密集且依赖简单、可预见的任务LLMCompiler高需 DAG 调度器、动态任务注入、并发控制最低流式动态并行趋近理论下限低类似 2 次规划汇总元任务额外调用动态流式并行实时解锁后继任务中可通过元任务动态扩展但初始 DAG 固定较高依赖显式图失败可增量修复低DAG 结构轻量结果按需组装高可精准定位失败子图并动态重规划多工具、依赖复杂、含条件分支的高并发任务以上即为单智能体下的5种主流框架随着搭建的从简单到复杂能力也逐渐增强。我们也可以看到并不是能力越强的框架就一定好从业务实际出发选择合适的框架才是真正重要的。下一篇将开始介绍多智能体下的Agent框架感谢阅读