什么是大模型 Agent它与传统的 AI 系统有什么不同大模型 Agent 是基于大型语言模型并结合模块化规划、记忆和工具调用的自主决策系统它能够根据最终目标把复杂任务拆分成子任务调用 API、检索数据库或使用插件再通过内部循环不断优化执行流程基本不需要人在每一步都监督。传统 AI 是你问一个问题它回答一个问题每次都是独立的被动响应而 Agent 有自己的规划能力你给它一个复杂目标它会自己把任务拆成多步通过调工具、访问记忆、感知环境来一步步执行直到完成。它不只是输出文字而是真的能做事。主要区别如下:目标导向 vs 被动响应传统大模型通常根据用户输入生成文本缺乏主动性而 Agent 以明确目标为驱动能够主动规划并执行任务。记忆与状态管理Agent具备短期和长期记忆能力能够维护状态信息并根据历史经验调整行为而传统大模型通常依赖于上下文窗口进行信息处理。多任务协同能力Agent 能够处理复杂的多步骤任务协调多个子任务的执行而传统大模型只能一问一答缺乏任务协同能力。推理与环境适应能力和传统 AI 系统主要依赖预先设定的规则引擎或静态模型不同大模型Agent 具备多步推理能力和动态环境适应能力它能在执行过程中不断评估结果、调整策略真正实现端型端的目标导向执行。面试时答这道题一定要点出三件事一是 Agent 有自主规划能力给它一个复杂目标它能自己拆解成多步二是它能行动通过工具调用跟外部世界真实交互三是它有闭环每步的结果会反馈回来指导下一步而不是一次性生成完就结束。另外还要提一句容易混的点模型本身只是「大脑」工具的真正执行是你的代码模型只负责决策。什么是 AI Agent其核心思想是什么AI Agent人工智能智能体是一种能够感知环境、进行决策并执行动作的自主软件系统。它以大语言模型LLM为大脑代表用户自动化完成复杂任务例如自动化处理电子邮件、生成报告、执行多步查询或控制智能设备。不同于单纯的聊天机器人AI Agent 强调自主性和交互性能够在动态环境中持续迭代直到任务完成。核心公式Agent LLM Planning规划 Memory记忆 Tools工具LLM Agent 的基本架构有哪些组成部分Agent核心(LLM本身)作为“大脑”负责理解输入、生成计划和下发指令串联其他模块协同工作。工具使用(Tools)接入搜索、计算、数据库、代码执行、第三方插件等多种外部工具为执行模块提供能力扩展。模型本身不执行工具它只是输出「调哪个工具、传什么参数」的决策真正执行的是代码记忆模块(Memory)短期记忆放在 context window 里存当前任务的中间状态长期记忆用向量数据库实现能跨任务保存用户偏好和历史。规划模块(Planning))将复杂目标拆解成有序的子任务制定多步执行方案并在必要时动态重规划。规划模块的底层其实依赖的是 LLM 的推理能力Agent智能体的工作过程是怎样的接收与理解输入Agent首先“感知”环境或用户输入将自然语言指令转为内部可处理的表示以明确目标和约束条件。规划基于输入LLM生成多步行动计划拆解为子任务并排序就像制定详细食谱确保烹饪思路清晰。决策基于记忆内容和任务目标Agent判断是否继续执行下一步操作或结束流程工具调用Agent根据计划动态选择并调用外部工具或API(如搜索、数据库、计算器等)来完成各子任务。观测在每次工具执行后Agent将输出作为“Observation”反馈给LLM用于更新当前状态和后续决策记忆关键观测和交互细节被存入短期或长期记忆提高多轮对话或复杂任务中的上下文一致性。决策基于最新的观测结果、记忆内容和任务目标Agent判断是否继续执行下一步操作或结束流程输出在所有必要步骤完成后Agent汇总信息生成并返回最终结果给用户。反思与纠错可选地启动自我反思模块评估已执行行动的正确性必要时重规划或修正策略避免重复错误。我用一段伪代码来还原整个运行过程看完你就能理解它们是怎么协作的python# Agent 运行的核心 loop伪代码 def agent_run(user_goal: str): # 第一步规划模块上场把目标拆成步骤列表 plan llm.plan(user_goal) memory [] # 短期记忆用来存每一步的中间结果 for step in plan: # 第二步LLM 核心做决策这一步该怎么做 action llm.decide( stepstep, historymemory, # 把短期记忆传进去让它知道之前做了什么 long_termvector_db.search(step) # 从长期记忆里捞出相关历史 ) if action.type tool_call: # 第三步工具系统负责真正执行 result tools.execute(action.tool_name, action.args) memory.append({step: step, result: result}) # 执行结果存入短期记忆 elif action.type final_answer: return action.content # LLM 判断任务完成返回最终答案看完这段伪代码你会发现 Agent 的核心节奏其实很简单规划 - 决策 - 执行 - 结果存入记忆 - 再决策循环往复直到任务完成。LLM 始终是那个做决策的角色工具系统是执行者记忆系统让它不会「失忆」规划模块帮它把大目标拆成小步骤。LangChain、LlamaIndex、AutoGen 这些主流框架本质上都是围绕这四个组件来设计的只是封装方式和侧重点各有不同什么是 Agent Loop其工作流程是什么Agent Loop 是所有 Agent 范式共享的运行引擎其本质是一个while循环每一次迭代完成LLM 推理 → 工具调用 → 上下文更新的完整链路直至任务终止。标准工作流初始化加载 System Prompt、可用工具列表及用户初始请求组装第一轮上下文。循环迭代核心读取当前完整上下文 → LLM 推理决定下一步行动调用工具 or 直接回复→ 触发并执行对应工具 → 捕获工具返回结果Observation→ 将 Observation 追加至上下文。终止条件当 LLM 在某轮判断任务完成直接输出最终回复而不再调用工具时退出循环。安全兜底为防止模型陷入死循环须设置强制中断条件如最大迭代轮次上限通常 10 20 轮或 Token 消耗阈值。工程视角Agent Loop 的设计难点不在循环本身而在于如何高效管理随迭代不断增长的上下文。上下文过长会导致关键信息被稀释、推理质量下降这也正是 Context Engineering 要解决的核心问题。在 LangChain、LlamaIndex、Spring AI 等主流框架中Agent Loop 均有封装实现可通过监控迭代次数、Token 消耗等指标诊断 Agent 性能瓶颈。WorkflowAgentTools 这三个的概念和区别介绍一下这三个概念是粒度从小到大的三层结构。Tools 是最小的能力单元就是封装好的可调用函数比如搜索、执行代码、发邮件它只负责「执行」本身没有任何决策能力Agent 是一个完整的决策系统内部用 LLM 做大脑自己判断什么时候调哪个 Tool、要不要继续、什么时候结束是主动的Workflow 是更上层的编排框架把 Agent、LLM、Tools 组织成一条确定性流程每个节点做什么、按什么顺序流转都是开发者事先写死的。三者最核心的区别就一句话Tools 不做决策只执行Agent 自己做决策Workflow 是开发者替所有节点把决策提前写好。完全靠 Agent 自主决策的系统其实很少在生产环境里出现原因很现实行为太难控制一旦出问题很难排查成本也容易失控LLM 调太多轮。完全靠 Workflow 写死的系统又太脆因为你没法把所有情况都穷举到代码里遇到预料之外的输入就容易失败或者给出很差的结果。所以目前生产环境里最主流的模式是Agentic Workflo用 Workflow 固定主流程的骨架在需要灵活判断的节点嵌入 Agent其余固定节点直接用 LLM 或 Tools。 骨架是确定的让你能控制整体行为、便于调试关键节点是灵活的让你能应对各种复杂情况。两个优点都有两个缺点都被削弱了。这样兼顾了可控性和灵活性。Workflow和Agent的区别是什么先把两者的本质区别说清楚。Workflow就是一个确定性的流程图你提前定好「第一步做AA完了做BB失败了走分支C」每一步的逻辑都是你硬编码进去的LLM只是其中某个节点的执行工具不负责决策流程本身。好处是行为完全可预测、容易测试、出了问题好排查;坏处是灵活性低遇到你没预料到的情况就会走入死胡同。Agent则相反它把「下一步做什么」这个决策权交给了LLM。你只告诉它目标它自己判断该调哪个工具、该不该继续、什么时候算完成。好处是能处理你事先没设计进去的情况;坏处是行为不确定同样的输入可能走出不同的路径线上出了问题也很难复现。Agent 推理模式有哪些Agent 的推理模式我用过几种。最基础的是直接输出答案没有中间推理CoT 是让 LLM 先把推理过程写出来再给答案准确率更高ReAct 是在 CoT 基础上加了「行动」让 LLM 交替输出思考和工具调用每次行动后再根据结果继续思考形成一个循环。ReAct 是目前 Agent 用得最广的模式因为它推理过程可见又能动态利用外部工具两个优点都有。如何赋予 LLM 规划能力给 LLM 加规划能力主要靠这几种思路。CoT 是让 LLM 把推理步骤写出来线性地一步步推导到答案ToT 是让它同时探索多条推理路径选最优的继续深入GoT 是图结构推理推理节点可以复用和合并适合更复杂的任务。工程上我用 CoT 最多因为实现成本最低就是改个 promptToT 效果更好但调用次数多成本大概是 3 到 5 倍GoT 目前还比较学术生产环境我没见过有人真正落地用的什么是 CoT 思维链如何实现 CoT 思维链LLM 的工作原理是根据你给它的输入一个 token 一个 token 地往后预测。你问它一个简单问题它可以直接说出答案。但如果你问的是一个需要多步推导的问题LLM 在没有任何辅助的情况下往往直接给你一个感觉对的答案而这个答案可能是错的。原因在于当它一口气预测答案时中间的推导步骤都是隐式的没有办法强制自己在每一步都做出正确的推断。误差会在中间某个暗处悄悄累积最终暴露在答案里。CoT(Chain of Thought)思维链的目的是让 AI 像人类一样“思考”在处理复杂问题的时候引导模型展示推理过程按步骤进行思考从而提高回答的准确性尤其对于复杂的推理类问题效果更佳。与此同时让模型展示推理过程也可以帮助我们理解和优化 AI的决策路径。CoT 核心想法极其朴素在 prompt 里加一句「让我们一步步思考」LLM 就会先把推理步骤写出来再给答案而不是直接蹦出结论。为什么加一句话就有效什么是 CoT 思维链和 ReAct 模式它们如何提高 AI 推理能力CoT 思维链(Chain of Thought) 和 ReAct 模式 (Reasoning Acting) 都是增强大型语言模型推理和解决复杂问题能力的技术CoT思维链生成最终答案之前先引导AI 模型输出一系列中间的、连贯的推理步现引导模型“思考过程化”模拟人类解决问题时逐步分析和推导的过程。它通过让模型显式地写出思考步骤可以帮助模型分解复杂问题减少在复杂逻辑链条中出错的概率。这些中间步骤也为我们理解模型的“思路”提供了便利调试和优化都会更简单方便。ReAct模式ReAct是 Reasoning and Acting 的缩写核心思路是在 CoT 的推理链里插入真实的「行动」。它让 LLM 按照「思考 - 行动 - 观察」这个循环来推进任务先思考当前该怎么做然后调用一个工具去获取信息或执行操作把工具返回的结果作为新的「观察」接收回来再进入下一轮思考直到 LLM 判断任务完成。CoT主要关注提升模型内部的逻辑推理连贯性和深度通过显化思考过程实现。ReAct 更注重于让模型与外部世界互动,通过“推里驱动行动,行动反馈观察观察指导推理”的闭环来解决那些需要外部信息或操作才能完成的复杂任务更考验模型动态调整推理路径的能力。ReAct 是什么说说它的原理ReAct是 Reasoning and Acting 的缩写核心思路是在 CoT 的推理链里插入真实的「行动」。它让 LLM 按照「思考 - 行动 - 观察」这个循环来推进任务先思考当前该怎么做然后调用一个工具去获取信息或执行操作把工具返回的结果作为新的「观察」接收回来再进入下一轮思考直到 LLM 判断任务完成。ReAct让模型在生成回答时交替输出“思考”和“行动”步骤从而在内部推理与外部交互之间形成闭环能够边“想”边“做”来完成复杂任务,核心原理推理 (Reasoning)模型先通过自然语言生成“思考过程”明确是否需要工具、需要什么工具、输入什么参数。行动(Action)根据当前思路选择合适的操作 (如调用搜索、工具 API、环境交互等)并输出具体的指令。观察(Observation)执行Action 后系统将返回的结果(网页片段、环境反馈等)提供给模型。循环迭代将 Observation 附加到上下文模型在新的上下文中继续“思考一行动一观察”循环直到输出最终答案或结束指令通俗理解让 AI 在整体目标的指引下“走一步看一步”。它打破了一次性规划全部流程的局限通过动态的交替循环边思考边验证。例如在排查线上服务变慢的故障时后文会举例详细介绍AI 不会死板地执行预设脚本而是先查询监控指标观察到 CPU 飙升及慢 SQL 告警后再动态决定去深挖数据库日志定位全表扫描问题最后基于真实的排查结果通知负责人。这种顺藤摸瓜的过程生成了更可靠、可追踪且能动态纠错的任务解决轨迹。优缺点分析优势显著减少幻觉引入外部真实数据验证、提升复杂任务的成功率、具备极高的可解释性与可调试性完整的推理轨迹清晰可见。局限性多轮循环迭代会导致系统整体响应延迟增加同时其表现高度依赖所集成的外部工具和 Skills 的质量与稳定性。什么是 ReAct如何基于 ReAct 模式构建具备自主规划能力的 AI 智能体ReAct即 ReasoningAcing(推理与行动)是一种结合推理和行动的智能体架构它模仿人类解决问题时“思考一行动一观察”的循环AI 首先对问题进行推理(Reason)将原始问题拆分为多步骤任务明确当前要执行的步骤、然后它会调用外部工具执行行动(Act)比如调用慢索引引擎或访问网页最后它会观察(0bserve)工具返回的结果并将这些结果反馈给智能体用于下一步的决策这个过程会不断循环法代直到任务完成或达到预设的终止条件。基于 ReAct 模式构建具备自主规划能力的 AI 智能体核心在于实现这个 “思考-行动-观察”的循环。这意味着智能体要实现接收用户指令后能分析并拆解成可执行的子任务。根据子任务的需要从可用的工具集中选择合适的工具并执行。分析工具执行的结果判断任务进展决定下一步是继续调用工具、向用户澄清还是结束任务。能否通过你的项目中实际的例子体现 ReAct 模式任务“帮我排查一下今天早上user-service接口变慢的原因并把排查结果发给该服务的负责人。”用 ReAct 的方式AI 会经历如下动态博弈的过程思考 (Thought)用户要求排查接口变慢我需要先获取user-service今天早上的监控指标或告警信息。行动 (Action)调用监控查询工具query_monitor(serviceuser-service, timemorning)观察 (Observation)返回数据表明9:00-9:30 期间 CPU 利用率飙升至 98%同时伴随大量慢 SQL 告警。思考 (Thought)既然有慢 SQL 告警说明数据库查询可能存在瓶颈。我需要去日志系统查询具体的慢 SQL 语句是什么。(注意这一步是动态决定的如果上一步发现是内存 OOM现在的行动就会变成查 Heap Dump)行动 (Action)调用日志查询工具query_slow_sql(serviceuser-service, time09:00-09:30)观察 (Observation)获取到慢 SQLSELECT * FROM users WHERE age 20 ORDER BY created_at DESC并发现该查询没有命中索引导致全表扫描。思考 (Thought)根本原因已经找到全表扫描导致 CPU 飙升。接下来我需要找到user-service的负责人是谁以便发送报告。行动 (Action)调用企业通讯录工具query_service_owner(serviceuser-service)观察 (Observation)查出负责人是“王建国”邮箱是wangjianguocompany.com。思考 (Thought)我现在收集齐了故障原因和联系人信息可以组织排查报告并发送邮件了。行动 (Action)调用邮件发送工具send_email(towangjianguocompany.com, subjectuser-service 故障排查, body发现由于缺少索引导致慢查询...)观察 (Observation)返回结果邮件发送成功。思考 (Thought)任务已全部闭环完成可以向用户输出最终答复了。行动 (Action)结束循环用自然语言回复用户“已查明原因是缺少索引导致的慢 SQL并已向负责人王建国发送了邮件。”如果采用非 ReAct 的模式比如让 AI 一开始就写好计划AI 可能会死板地执行“查日志 - 找人 - 发邮件”。但如果故障原因不在日志里而在网络配置里静态计划就会彻底崩溃。在这个例子中第 4 步的决定完全依赖于第 3 步的观察结果。ReAct 让 Agent 拥有了像人类工程师一样顺藤摸瓜、根据证据修正排查方向的能力。这是单纯的链式调用Chain无法做到的。延伸思考在更成熟的 Agent 系统中上述步骤 2、5 中对监控和日志的联合查询可以被封装为一个名为diagnose_service_performance的Skill——它内部自动编排查监控 查慢 SQL 分析瓶颈三个工具的调用序列并返回一份结构化的诊断摘要。Agent 在推理时只需调用这一个 Skill而不必每次都拆解成多个独立步骤既降低了上下文占用也提升了在同类故障场景下的复用效率。这正是 Skills 作为 Tools 高阶封装形态的核心价值所在。ReAct 是怎么实现的ReAct 的落地实现主要依赖以下五个核心组件协同工作历史上下文HistoryAgent 维护一个统一的交互日志涵盖以往的推理步骤、执行动作以及反馈观察。这为 LLM 提供了即时记忆机制确保决策时能回顾先前事件从而规避冗余步骤或无限循环风险。实时环境输入Real-time Environment Input包括 Agent 当前捕获的外部变量如系统警报信号或用户即时反馈。这些补充数据融入上下文帮助 LLM 准确评估现状并调整策略。模型推理模块LLM Reasoning Module作为 ReAct 的核心引擎处理逻辑分析与规划。每次迭代中LLM 整合历史记录、环境输入及任务目标输出行动方案。执行工具集与技能库Tools Skills充当 Agent 的操作接口与外部实体互动。其中原子工具Tools处理单一操作如数据库查询、邮件发送技能Skills则是对多个相关工具的编排封装提供面向特定业务场景的可复用能力模块如故障诊断技能、竞品分析技能。两者共同构成 Agent 的行动能力边界。反馈观察机制Feedback Observation行动完成后从环境中采集的实际响应包括成功输出、错误提示或无结果状态。这一信息将被追加至历史上下文中成为后续推理的可靠基础。这里以上面提到的例子来展示一下执行流程采用逐轮叙述形式便于追踪动态变化Round 1历史上下文空实时环境输入空核心 Prompt已知当前历史上下文{历史上下文} 实时环境输入{实时环境输入} 用户目标排查 user-service 变慢原因并通知负责人 请做出下一步的决策你必须最少使用一个工具来实现该决策。执行工具query_monitor查询 user-service 早上的监控指标观察结果CPU 飙升至 98%伴随大量慢 SQL 告警。Round 2历史上下文已获取监控指标CPU 飙升有慢 SQL执行工具query_slow_sql查询慢 SQL 日志观察结果发现语句未命中索引导致全表扫描。Round 3历史上下文监控指标 日志结论全表扫描执行工具query_owner查询 user-service 负责人观察结果负责人为王建国邮箱wangjianguocompany.com。Round 4历史上下文监控指标 日志结论 负责人信息执行工具send_email向负责人发送排查报告观察结果邮件发送成功。从底层来看驱动 Agent Loop 运转的核心是一套动态组装的 Promptjson已知 当前历史上下文{历史上下文} 实时环境输入{实时环境输入} 用户目标排查 user-service 变慢原因并通知负责人 请做出下一步的决策 你可以选择调用工具或 Skill或者在任务完成时直接输出最终结果最终输出“已查明 user-service 接口变慢原因是由于慢 SQL 未命中索引导致全表扫描已向负责人王建国发送了详细排查邮件。”什么是 Plan-and-Execute 模式Plan-and-Execute计划与执行模式由 LangChain 团队于 2023 年提出。