第一卷大模型 基础篇第3章 模型能力认知第7节Agent为什么能够自己完成任务——ReAct、Planning与Agent Loop详解引言前面我们已经学习了LLM ↓ 生成Token ↓ 产生回答随后我们又学习了 Tool Calling。User Request ↓ LLM ↓ Tool Decision ↓ Tool Calling ↓ Tool Result ↓ Final Answer这时一个问题出现了。假设用户说帮我检查客户A最近三个月的订单情况如果销售额下降超过30%分析可能原因并创建一个风险工单。这个任务显然不是一次Tool Calling就能完成的。Agent可能需要查询客户信息 ↓ 查询订单数据 ↓ 计算销售趋势 ↓ 分析下降原因 ↓ 判断是否达到风险条件 ↓ 创建风险工单 ↓ 返回执行结果问题来了Agent是怎么知道下一步应该做什么的答案就在 Agent 最核心的运行机制中Reasoning ↓ Action ↓ Observation ↓ Reasoning ↓ Action ↓ Observation ↓ …… ↓ Task Complete这就是我们常说的Agent Loop而 ReAct则是理解这一循环机制的重要思想框架。本节我们将从 Tool Calling 出发真正进入 Agent 的核心世界。一、单次Tool Calling为什么还不能算真正的Agent我们先看一个简单流程。用户查询上海地区上个月销售额。系统User ↓ LLM ↓ QuerySales ↓ Tool Result ↓ Answer这种情况下任务只有一步。模型只需要判断要不要调用工具 ↓ 调用哪个工具 ↓ 参数是什么执行完成即可。但是现实中的企业任务通常不是这样的。例如找出最近销售额下降最严重的客户并分析原因。如果确认存在流失风险就通知客户经理。这个任务可能变成Task ↓ Query Customers ↓ Find Sales Data ↓ Calculate Trend ↓ Identify Risk ↓ Analyze Reason ↓ Create Notification ↓ Task Complete关键在于后面的动作往往取决于前一步的结果。例如Query Sales ↓ Result 客户A下降45% ↓ 是否超过30% ↓ Yes ↓ 继续分析原因如果查询结果是客户A下降5%那么无需创建风险工单 ↓ Task Complete所以真正的Agent不是LLM ↓ Tool ↓ Answer而是LLM ↓ Action ↓ Observation ↓ Next Decision ↓ Next Action ↓ …… ↓ Task Complete这就是 Agent 和普通 LLM Application 的重要区别。二、什么是Agent Loop所谓 Agent Loop可以简单理解为Agent不断根据当前信息进行思考、执行动作、观察结果然后决定下一步应该做什么。它的基本结构是User Task ↓ Reasoning ↓ Action ↓ Observation ↓ Context Update ↓ Next Reasoning ↓ …… ↓ Task Complete其中最重要的三个环节是Reasoning 思考下一步 ↓ Action 执行动作 ↓ Observation 观察执行结果然后Observation ↓ 成为新的Context ↓ LLM重新思考例如用户查询客户A最近订单如果金额超过100万创建风险审核任务。Agent第一次思考Reasoning 我需要先查询客户订单。于是Action QueryOrder(customerA)工具返回Observation Order Amount 1,250,000Agent再次思考Reasoning 订单金额超过100万 需要创建风险审核任务。于是Action CreateRiskTicket(customerA)然后Observation Ticket Created Successfully最终Task Complete整个过程就是Reasoning ↓ Action ↓ Observation ↓ Reasoning ↓ Action ↓ Observation ↓ Complete三、ReAct到底是什么ReAct 是 Agent领域非常重要的一种思想。它可以理解为Reasoning Acting即Reasoning Action传统的LLM通常是Question ↓ LLM ↓ Answer而 ReAct 思想则变成Question ↓ Reasoning ↓ Action ↓ Observation ↓ Reasoning ↓ Action ↓ Observation ↓ Final Answer这里的核心变化是模型不再试图一次性想完所有事情。而是想一步 ↓ 做一步 ↓ 看看结果 ↓ 再想下一步例如用户查询北京地区销量最高的产品并检查库存。如果库存不足100件通知采购部门。Agent可能这样运行第一步Reasoning 我需要先查询北京地区的销售数据。↓Action QuerySales(region北京)↓Observation Product X 销量最高第二步Reasoning 现在需要查询 Product X 的库存。↓Action QueryInventory(productX)↓Observation Stock 82第三步Reasoning 库存低于100需要通知采购部门。↓Action NotifyProcurement(productX)↓Observation Notification Sent最终Final Answer 北京地区销量最高的产品为Product X 当前库存82件已通知采购部门。这就是 Agent 的典型工作方式。四、Agent内部到底发生了什么从工程角度看Agent Loop并不是一个神秘的“自主思考系统”。它本质上仍然是Context ↓ LLM ↓ Next Action ↓ Execution ↓ New Context ↓ LLM不断循环。例如当前ContextSystem Prompt 你是销售风险分析Agent。 Available Tools QueryCustomer QueryOrder CreateRiskTicket User Task 检查客户A的订单情况 如果存在销售风险创建风险工单。第一次调用LLM。模型输出{ tool: QueryOrder, arguments: { customer: A } }Runtime执行QueryOrder(A) ↓ Result { sales_change: -45% }然后系统把结果加入Context。User Task Previous Action QueryOrder(A) Observation sales_change -45%再次调用LLM。模型可能决定{ tool: CreateRiskTicket, arguments: { customer: A, reason: Sales dropped 45% } }因此Agent自主完成任务从工程实现角度其实就是LLM调用 ↓ 解析Action ↓ 执行Tool ↓ 获取Observation ↓ 更新State / Context ↓ 再次调用LLM循环直到Task Complete或者Max Steps Reached五、ReAct为什么比“一次性规划”更适合动态任务假设我们让Agent一开始就生成完整计划Step 1 查询客户 Step 2 查询订单 Step 3 分析风险 Step 4 创建工单这就是一种Plan First ↓ Execute Later的方式。这种方法在任务稳定时很好。例如Generate Monthly Report ↓ Query Data ↓ Analyze Data ↓ Generate Chart ↓ Create Report但是现实世界往往存在变化。例如Query Customer ↓ Customer Not Found原来的计划Query Order ↓ Analyze Risk已经无法继续。又例如Query Inventory ↓ API TimeoutAgent需要决定Retry ↓ Use Backup API ↓ Ask Human ↓ Terminate因此 ReAct 的优势在于行动 ↓ 观察真实世界 ↓ 根据最新结果调整可以表示为Plan ↓ Action ↓ Reality Feedback ↓ Update Decision ↓ Next Action所以ReAct更像“边走边看”。而传统Planning更像“先规划好路线再开始执行”。实际企业Agent往往需要两者结合。六、什么是PlanningPlanning就是Agent在执行任务之前先将复杂任务拆分成多个子任务。例如用户帮我生成本季度销售分析报告并找出风险客户然后给相关负责人发送邮件。Agent可以先生成Task Plan 1. 查询本季度销售数据 2. 生成销售趋势分析 3. 识别销售下降客户 4. 查询负责人信息 5. 生成通知内容 6. 发送邮件 7. 汇总执行结果然后逐步执行。Plan ↓ Execute Step 1 ↓ Observe ↓ Execute Step 2 ↓ Observe ↓ …… ↓ Complete这种模式通常称为Plan-and-Execute与 ReAct 相比模式特点适合场景ReAct每一步动态决策环境变化较多Plan-and-Execute先拆解整体任务流程复杂但相对稳定Workflow固定流程执行企业标准业务Hybrid AgentPlanning ReAct Workflow企业复杂场景七、Agent为什么会陷入死循环当我们真正开始开发Agent时很快会发现一个问题。Agent可能会这样Call Tool ↓ Failed ↓ Retry ↓ Failed ↓ Retry ↓ Failed ↓ Retry ↓ ……或者Search ↓ Result不满意 ↓ Search Again ↓ Result不满意 ↓ Search Again ↓ ……这就是Agent Loop带来的副作用。Agent拥有自主决策能力同时也意味着错误决策可能不断重复。例如Reasoning 查询失败 我应该重新查询。模型再次调用QueryDatabase()仍然失败。下一轮Reasoning 可能刚才调用失败 再试一次。如果没有控制机制Infinite Loop就可能发生。所以企业Agent必须设置Max Steps Timeout Retry Limit Loop Detection Budget Limit Human Escalation例如Max Steps 10当执行10次仍未完成Agent ↓ Stop ↓ Return Failure ↓ Record Trace ↓ Human Review八、Agent为什么需要State普通聊天模型主要依赖Context但是复杂Agent通常需要State例如Task ID Current Step Completed Steps Tool Results Retry Count Budget User Information Execution Status假设一个任务已经执行Step 1 查询客户 ✓ Step 2 查询订单 ✓ Step 3 分析风险 Running这些状态不能只依赖模型“记住”。否则Context变化 ↓ 模型重新生成 ↓ 可能重复执行所以工程系统通常需要Agent State例如{ task_id: task_001, current_step: 3, completed_steps: [ query_customer, query_order ], retry_count: 1, status: running }然后LLM 负责 理解 推理 决策 State 负责 记录任务真实状态这是非常重要的工程分工。九、这个问题对Agent有什么影响到这里我们已经可以真正理解Tool Calling只是Agent的手。而Reasoning Planning Observation State Loop才构成了Agent的大脑和执行机制。可以理解为LLM BrainTools HandsPlanning Task DecompositionMemory / State Working MemoryAgent Loop Execution Cycle最终这就是为什么Agent并不是一个Prompt。而是一个完整的LLM Context Tools Planning Memory State Loop Engineering系统。十、工程师应该如何设计一个Agent Loop一个基础的Agent Loop通常如下while not task_complete: response llm(context) if response.tool_call: result execute_tool(response) context.append(result) else: final_answer response break但企业级系统不能这么简单。至少需要加入更完整的逻辑可以理解为这才是一个更接近真实生产环境的 Agent Runtime。十一、企业级Agent应该如何做企业环境下我们不能只关注Agent聪不聪明更重要的是Agent能不能稳定完成任务企业级Agent通常需要四层控制。第一层模型控制Model Temperature Prompt Structured Output Tool Retrieval目的提高决策稳定性。第二层执行控制Schema Validation Permission Check Timeout Retry Fallback目的防止模型错误直接影响业务系统。第三层状态控制Task State Checkpoint Execution Status Idempotency目的防止重复执行和任务状态丢失。第四层可观测性十二、从Tool Calling到真正的Agent现在我们重新回顾整个知识链。一开始LLM ↓ Generate Answer然后LLM ↓ Tool Calling ↓ Get External Information再进一步LLM ↓ Reasoning ↓ Action ↓ Observation ↓ Next Action于是Agent出现了。完整演进可以表示为所以真正理解Agent需要记住一句话Agent并不是因为“会调用工具”就产生了而是因为它能够根据执行结果不断调整下一步行动最终完成一个多步骤任务。面试题问题1什么是Agent Loop参考答案Agent Loop是Agent执行任务的循环机制。模型根据当前Context进行推理和决策执行Action或调用Tool然后获得Observation将结果更新到Context或State中再进行下一轮决策直到任务完成或触发终止条件。核心流程Reasoning ↓ Action ↓ Observation ↓ Context / State Update ↓ Next Reasoning问题2ReAct和普通Tool Calling有什么区别参考答案普通Tool Calling通常只关注一次工具调用LLM ↓ Tool ↓ ResultReAct则强调模型根据执行结果继续推理和行动Reasoning ↓ Action ↓ Observation ↓ Next Reasoning因此ReAct更适合多步骤、动态变化的任务。问题3为什么Agent会陷入死循环参考答案因为Agent每一步都由模型进行动态决策。如果Tool持续失败或者模型不断认为应该重复执行某个动作就可能出现无限循环。工程上通常需要增加Max Steps Timeout Retry Limit Loop Detection Budget Limit Human Escalation来控制Agent执行。问题4Context和State有什么区别参考答案Context主要用于给LLM提供当前推理所需的信息例如Prompt、历史对话、RAG内容和Tool Result。State则用于记录任务真实执行状态例如当前步骤、已完成步骤、重试次数、任务状态和Checkpoint。简单理解Context帮助模型思考State帮助系统管理任务。问题5ReAct、Planning和Workflow应该如何选择参考答案如果任务具有较强的不确定性需要根据实时结果决定下一步可以使用ReAct。如果任务复杂但可以提前拆分为多个步骤可以使用Planning或Plan-and-Execute。如果业务流程稳定例如审批、订单处理、报表生成则更适合Workflow。企业级Agent通常会采用Workflow Planning ReAct的混合模式。本节小结通过本节我们建立了从 Tool Calling 到真正 Agent 的关键认知。✅核心概念Agent的核心不是单次调用Tool而是Reasoning ↓ Action ↓ Observation ↓ Loop✅底层原理Agent通过不断调用LLMCurrent Context ↓ LLM Decision ↓ Action ↓ Observation ↓ Update Context ↓ Next Decision逐步完成任务。✅常见问题Agent可能出现重复调用 无限循环 错误重试 任务状态丢失 重复执行 成本失控✅工程解决方案需要加入State Max Steps Timeout Retry Limit Validation Trace Monitoring Budget Control Human-in-the-loop✅Agent应用真正的Agent能力来自最终形成Tool Calling让LLM拥有了“行动能力”而Agent Loop让它能够根据行动结果不断调整策略最终从“回答问题”走向“完成任务”。下一篇《第3章 第8节Agent为什么需要Memory——短期记忆、长期记忆与企业级Memory架构》下一节我们将继续解决一个非常关键的问题Agent能够不断执行任务但如果任务很长、用户很多、对话跨越多天它到底如何记住之前发生过的事情我们将正式进入