agent开发学习【第一篇】
前言：
最近在从零手写轻量级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. 架构痛点
短视效应：走一步看一步，缺乏全局视野。面对“整理年度报告并发送邮件”这类多步任务，容易在中间环节迷路。
上下文膨胀：每轮循环都把完整历史塞回Prompt，Token消耗呈线性增长，极易触顶上下文窗口上限。
实际实现
其实就是一个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校验：通过则存入最终结果集；不通过则携带失败原因回退给Planner，Planner微调指令后重新下发（最多重试2次）。
所有子任务均通过校验后，Planner汇总所有结果，生成最终答案。
4. 架构图
5. 为什么选择这种模式？
Prompt工程极简：每个角色只需关注自己的系统提示词，无需在超长Prompt中塞入“既要拆解又要执行还要质检”的矛盾指令。
可观测性极强：日志中清晰记录“哪个环节出了错”，排查线上问题效率倍增（
四、三种架构的横向对比
| 场景 | 推荐模式 | 理由 |
|---|---|---|
| 简单问答、单文件修改 | ReAct | 一两步搞定，规划是浪费 |
| 创建项目、多文件重构 | Plan-and-Execute | 步骤多、有依赖，需要先规划 |
| 大规模任务、需要质量保障 | Multi-Agent | 分工协作 + 审查机制 |
架构演进总览图（三者对比）
总结
我目前三种模式都在用，日常对话其实直接react就够用了，然后这些模式理解起来都很简单，不就是多了一点提示词，但是真正想要成为一个产品还要考虑很多东西，大模型是一个不可控因素，他的决策他想用的工具也很有可能错误，所以这就需要我们在工程上来进行兜底，本质上agent开发其实就是后端开发，就多了一点大模型的东西。