前言最近在从零手写轻量级Agent框架无第三方Agent库基于原生HTTP调用LLM本系列记录架构选型与落地踩坑。本文作为开篇从架构演进角度拆解ReAct、Plan-and-Execute与Multi-Agent三种模式。后端开发的视角看Agent在此之前其实我已经用springai写过项目也调过大模型api用过rag但是始终不清楚agent到底是什么。它和普通LLM接口调用有什么区别常规LLM调用是无状态的“一问一答”而Agent的核心在于“自主决策循环”——它拥有推理能力大脑、工具使用权手脚和短期记忆上下文窗口。本文不堆砌框架术语直接从架构层面拆解Agent从简单到复杂的三种演进形态。ReAct推理-行动循环最快速的搭建一个能跑的agent采用的就是这种模式我对他的理解就是在推理上加了一个行动可以调用工具解决问题然后判断有没有成功没有成功就继续1. 核心思想ReAct Reasoning推理Acting行动。它打破了纯语言模型“只思考不行动”的局限让LLM能够主动调用外部工具获取新信息。2. 运行机制整个过程是一个闭环反馈系统系统将当前用户问题与历史对话拼接注入“思考-行动-观察”格式的System Prompt。LLM输出结构化指令是调用某个工具如查询数据库、调API还是直接给出最终答案。若调用工具则等待工具返回结果并将该结果作为新证据追加到上下文中触发下一轮推理。循环往复直到LLM判定信息充足输出最终答案并终止。3. 架构图4. 架构痛点短视效应走一步看一步缺乏全局视野。面对“整理年度报告并发送邮件”这类多步任务容易在中间环节迷路。上下文膨胀每轮循环都把完整历史塞回PromptToken消耗呈线性增长极易触顶上下文窗口上限。实际实现其实就是一个while循环只有在大模型不返回工具请求的时候会结束然后把回复交给用户Plan-and-Execute规划-执行分离1. 核心思想将“脑力劳动”与“体力劳动”严格解耦。先让LLM静下心来拆解任务生成一份完整的执行蓝图再让执行器按图索骥。其实也就是我们经常用过/plan然后codex就会生成计划。2. 运行机制分为两个清晰的阶段规划阶段Plan将复杂用户指令一次性拆解为若干有序子任务通常以JSON或步骤列表形式输出。该阶段仅消耗一次推理不调用任何外部工具。执行阶段Execute执行器严格按照步骤顺序推进。每一步执行时可以引用前几步的产出结果作为上下文逐步填充任务依赖图。全部步骤完成后汇总所有中间结果交由LLM生成最终的自然语言回复。3. 架构图4. 架构优势与局限相比ReAct它极大提升了复杂任务的完成度逻辑链条更清晰。但执行器依然是单兵作战——如果某个子任务执行失败或者产出质量存疑整个流程缺少“纠偏”机制。Multi-Agent多角色协作1. 核心思想受软件工程中“职责分离SRP”启发将不同能力封装为独立的Agent角色通过标准消息协议协作。我们项目中定义了三种角色2. 角色定义规划者Planner团队的大脑。负责任务分解、资源分配和制定检查点Checkpoint。它不执行具体代码只输出任务蓝图和验收标准。工作者Worker团队的手脚。真正干活的执行单元。接收Planner下发的原子任务调用外部工具HTTP请求、SQL、代码解释器并返回原始结果。审查者Reviewer团队的质量门禁。Worker交付结果后Reviewer依据验收标准进行校验如检查数据非空、格式合规、逻辑自洽。若校验失败向Planner发起“修正请求”触发Worker重试或任务降级。3. 协作流程Planner拆解主任务为多个子任务放入内部队列。Worker依次消费队列任务执行后将结果提交给Reviewer。Reviewer校验通过则存入最终结果集不通过则携带失败原因回退给PlannerPlanner微调指令后重新下发最多重试2次。所有子任务均通过校验后Planner汇总所有结果生成最终答案。4. 架构图5. 为什么选择这种模式Prompt工程极简每个角色只需关注自己的系统提示词无需在超长Prompt中塞入“既要拆解又要执行还要质检”的矛盾指令。可观测性极强日志中清晰记录“哪个环节出了错”排查线上问题效率倍增四、三种架构的横向对比场景推荐模式理由简单问答、单文件修改ReAct一两步搞定规划是浪费创建项目、多文件重构Plan-and-Execute步骤多、有依赖需要先规划大规模任务、需要质量保障Multi-Agent分工协作 审查机制架构演进总览图三者对比总结我目前三种模式都在用日常对话其实直接react就够用了然后这些模式理解起来都很简单不就是多了一点提示词但是真正想要成为一个产品还要考虑很多东西大模型是一个不可控因素他的决策他想用的工具也很有可能错误所以这就需要我们在工程上来进行兜底本质上agent开发其实就是后端开发就多了一点大模型的东西。