子任务调用 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 年提出。可以把 ReAct 和 Plan-and-Execute 的区别类比成「边走边问路」和「先看地图再出发」的区别。核心思想让 LLM 充当规划者先制定全局的分步计划再由执行器按步骤逐一完成而非“边想边做”。优势非常适合步骤繁多、逻辑依赖明确的长期复杂任务能有效避免 ReAct 模式在长任务中容易出现的“迷失”或“死循环”问题。例如在处理多阶段项目管理时先输出完整计划如步骤 1: 收集数据步骤 2: 分析步骤 3: 生成报告然后逐一执行。缺点偏向静态工作流执行过程中的动态调整和容错能力较弱。如果环境变化如工具失败可能需要重新规划导致效率低下。具体来说Plan-and-Execute 把整个任务处理流程拆成了两个明确的阶段。第一个阶段是「规划」Planner。把用户的任务目标交给 LLM让它先不急着动手而是站在全局的角度想清楚这个任务要分几步完成每一步具体做什么步骤之间的依赖关系是什么然后输出一份结构化的执行计划。这一步的关键是 LLM 只做规划、不执行任何工具调用全部注意力都集中在「想清楚」这件事上。第二个阶段是「执行」Executor。拿着规划好的计划按顺序一步一步地执行。每一步的执行本身可以用 ReAct 模式来跑也就是说执行器在处理单个子任务时仍然可以「思考 - 行动 - 观察」地循环。但不同的是执行器始终知道自己在整体计划中处于哪一步、下一步要做什么不会像纯 ReAct 那样漫无目的地漂移。pythondef plan_and_execute(question: str, tools: dict): # 第一阶段让 LLM 生成一份完整的执行计划 # 注意这里只做规划不执行任何工具 plan llm.generate(f 请为以下任务制定一个分步执行计划 任务{question} 请输出一个编号列表每一步都要具体、可执行。 ) # 解析出计划中的每一步 steps parse_plan(plan) results [] # 第二阶段按计划逐步执行 for i, step in enumerate(steps): # 每一步可以用 ReAct 模式来执行 # 但执行器知道自己在整体计划中的位置 step_result react_executor( taskstep, toolstools, contextf整体计划共{len(steps)}步当前是第{i1}步, previous_resultsresults # 把前面步骤的结果传进去 ) results.append(step_result) # 关键执行完一步后检查是否需要调整后续计划 # 这就是「动态重规划」机制 if need_replan(step, step_result, steps[i1:]): remaining_steps llm.generate(f 原计划{steps} 已完成到第{i1}步结果{results} 剩余步骤是否需要调整请输出更新后的剩余步骤。 ) steps steps[:i1] parse_plan(remaining_steps) # 最后汇总所有步骤的结果生成最终答案 return llm.generate(f根据以下执行结果回答问题{results})这段代码里有一个非常关键的设计就是「动态重规划」。计划不是定死的而是活的。每执行完一步系统都会检查一下这一步的实际结果和预期是否一致如果某一步的结果出乎意料比如你原计划第二步要查某个 API 但发现这个 API 已经下线了系统会把已有的结果和剩余的步骤重新交给 Planner让它根据新情况调整后续计划。这就像你开车导航时前方突然封路了导航会自动重新规划一条新路线而不是傻傻地让你掉头回起点。与 ReAct 的对比维度ReActPlan-and-Execute规划方式动态、逐步规划静态、全局预规划适用场景动态环境、需实时纠偏步骤明确的长期复杂任务容错能力强每步可动态修正弱环境变化需重新规划上下文管理随迭代持续增长执行步骤相对独立更可控那 Plan-and-Execute 和 ReAct 分别适合什么场景呢ReAct 的优势在于灵活每一步都能根据最新情况做决策特别适合那些任务边界不太明确、需要探索性地获取信息的场景比如开放式的问答、信息搜索这类任务。它的代价是容易漂移而且每一步都要把完整历史带上调 LLM步骤多了 token 消耗会线性增长。Plan-and-Execute 的优势在于有全局视野不容易跑偏特别适合那些目标明确、需要多步骤协作完成的复杂任务比如深度研究、长文写作、多工具协同的数据分析。它的代价是初始规划本身就需要一次 LLM 调用如果任务很简单一两步就能搞定这个规划步骤反而是多余的开销。最佳实践两者并非互斥可结合使用——用 Plan-and-Execute 做全局规划用 ReAct 做每一步的执行。规划阶段用能力更强的大模型比如 GPT-4、Claude Opus来保证计划质量执行阶段用便宜的小模型来跑具体的工具调用这样既保证了全局方向不跑偏又控制了成本。这种大小模型搭配的架构在实际项目中能降低 70% 到 90% 的 LLM 调用成本是非常实用的工程技巧。什么是 Reflection 模式Reflection反思模式赋予 Agent自我纠错与迭代优化的能力核心理念是通过自然语言形式的口头反馈强化模型行为而非调整模型权重即零训练成本。Reflection 通常不单独使用而是作为增强层叠加在 ReAct 或 Plan-and-Execute 之上ReAct Reflection使每轮观察后不仅更新行动计划还进行显式自我反思形成自适应 Agent。实际应用中显著提升了 Agent 在不确定环境下的鲁棒性但会带来额外的 LLM 调用开销。ReAct 就像你一道题一道题挨着做做一道过一道不回头看。Plan-and-Execute 是你先把整张卷子的做题顺序、时间分配定好再按计划做题。Reflection 则是你做完一道题或者整张卷子回头再检查一遍看看有没有算错数、有没有看错题发现错了马上改改完再交卷。讲讲 Agent 的反思机制为什么要用反思具体怎么实现反思机制是让 Agent 在完成一个步骤或整个任务后自我评估输出质量判断有没有问题不达标就重试或调整策略。用反思的原因是 LLM 第一次输出不一定是最优的加一轮自我检查能显著提升质量相当于人写完东西自己再看一遍。代价是多至少一次 LLM 调用token 消耗和延迟都会增加所以我在工程里通常只在质量要求高的关键节点启用反思不是每步都做反思可以在两个粒度上触发它们有不同的适用场景代价也不一样选哪种需要根据任务特点来判断。步骤级反思是在每个工具调用或推理步骤完成后立即检查。它的好处是错误早发现早纠正不会让一个小错误在后续步骤里层层放大。适合这种粒度的场景是步骤之间强依赖、前一步错了后面会全错的任务。代价是每一步都多一次 LLM 调用整体延迟和 token 消耗会大幅增加一个 10 步的任务可能实际要调用 20 次 LLM。任务级反思是整个任务执行完之后做一次整体评估。好处是开销更小整个任务只多一次 LLM 调用而且从整体视角审视能发现步骤级看不到的问题各个步骤单独看都是对的但整体结论前后矛盾或者各部分之间衔接不自然这种问题只有从整体视角才能看出来。除了单 Agent 的自我反思还有一种效果通常更好的方式多 Agent 互评专门设置一个独立的 Critic Agent让它来审查执行 Agent 的输出。什么场景值得开反思输出质量要求高、错误代价大的关键节点比如最终报告生成、重要决策的推理过程以及任务比较复杂、LLM 容易遗漏细节的场景这些是反思最能发挥价值的地方。什么场景不值得开简单直接的任务比如格式转换、简单问答加反思纯粹是浪费。实时性要求高的场景也一样一次反思至少多一次完整的 LLM 调用延迟可能从 1 秒涨到 3 秒有些应用场景根本接受不了。最重要的是防死循环必须设最大轮次通常设 2-3 轮绝对不能依赖 LLM 自己判断停止。原因是 LLM 有时会陷入「为了改而改」的循环每次评估都觉得还有地方能优化改完又有新的「问题」每轮改动都很小但实质没有进步系统就一直在转圈。硬性的轮次上限是唯一可靠的退出机制。最后要对整体代价有清醒认知每轮反思包含一次评估和一次改进3 轮反思意味着在原始生成之外额外增加 6 次 LLM 调用延迟和成本都会大幅增加这是工程上做取舍的核心数字。反思是提升质量的有效手段但不是免费的用在刀刃上才有价值不是每步都做还了解其它Agent设计模式吗第一个是动态 Replan它解决的是 Plan-and-Execute 的一个核心痛点计划定死了中途遇到意外怎么办比如你规划了五步来写竞品分析报告执行到第三步发现某个竞品已经被收购了原来的分析框架需要调整但计划已经定好了后面的步骤还是按老计划跑输出的报告就会有问题。动态 Replan 的做法是在每个步骤执行完之后把当前结果和剩余计划一起交给规划模块让它判断「原来的计划还合理吗需不需要调整」。如果需要就生成一份新的剩余步骤计划替换掉原来的。这样既保留了 Plan-and-Execute「先规划再执行」的结构优势又不会因为计划太僵硬而在意外情况下翻车。代价是每步都多了一次「重新评估计划」的 LLM 调用token 消耗会增加。第二个是Reflexion它把 Reflection 的「自我反思」推到了更深的层次。普通的 Reflection 是「做完了检查一遍、发现问题就重做」有点像考试做完检查一遍。Reflexion 在这个基础上多做了一件关键的事它不仅检查输出对不对还会把每次失败的原因总结成一段「经验教训」存进记忆里下次再遇到类似任务时这段教训会作为上下文传给 LLM让它避免重蹈覆辙。这个机制有点像你做错了一道数学题不只是改答案还会在错题本上写「这类题容易漏掉符号变化下次要特别注意」下次遇到同类题时翻一下错题本再动笔。ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别实际项目中该如何选型这三者是 Agent 开发里最主流的三种设计范式核心区别在于「决策和执行的关系」。ReAct 是边想边干走一步看一步单步迭代实时调整灵活度最高本质就是「思考→行动→观察→再思考」的循环Plan-and-Execute 是针对 ReAct「长任务容易跑偏」的痛点做的针对性优化。是先想全再干先定完整计划再分步执行适合长流程复杂任务不容易跑偏Reflection 不是独立的完整流程而是给前两者加的检查修正 buff用来提升输出质量。实际选型就看三个维度任务复杂度、流程确定性、输出质量要求新手入门首选 ReAct复杂任务用 Plan-and-Execute高要求场景再加 Reflection。任务不复杂、流程不固定、需要实时调整的直接用ReAct够用就好别搞复杂的。任务很长、容易跑偏、需要整体结构清晰的上Plan-and-Execute先把计划定清楚再执行。如果执行过程中经常遇到意外需要调整计划就加上动态 Replan。输出要求高、不能出错的在前两者基础上叠加Reflection做自我检查。如果还需要跨任务积累经验、避免重复犯错就用Reflexion把失败教训沉淀下来。实际项目中还有一种非常常见的混合用法规划阶段用 Plan-and-Execute 的思路定好全局计划每一步的执行用 ReAct 的循环来处理因为单步执行可能也需要多轮工具调用最后对整体输出做一次 Reflection 检查质量。这种三层嵌套的架构听起来复杂但其实在 LangGraph 这类框架里实现起来很自然很多生产级的 Agent 系统都是这么搭的。最容易踩的坑是学了这些范式就全堆在一起又要规划、又要反思、又要 Replan、又要积累经验结果系统又复杂又慢还容易出奇怪的 bug。工程开发永远是够用就好先把最基础的 ReAct 玩明白再根据实际需求往上加别为了炫技搞过度工程化核心回答ReAct 边想边干、灵活度最高但长任务容易跑偏Plan-and-Execute 先规划再执行、结构清晰但灵活度不足Reflection 专门解决输出质量问题代价是增加 token 消耗和延迟复杂任务怎么做的任务拆分为什么要拆分效果如何提升我理解任务拆分的原因是 LLM 一次性处理太复杂的任务很容易出错把大任务拆成小步骤每步聚焦一件事准确率会明显提升。为什么拆LLM 的 context window 有上限任务越大中间状态越多、越容易出错而且拆开后每步可以独立验证和重试怎么拆静态拆分适合流程固定的场景直接写死步骤动态拆分用 Plan-and-Execute 让 LLM 自己规划灵活但规划质量不稳定效果如何验证完备性也就是所有步骤加在一起能不能覆盖原始任务的全部要求有没有遗漏独立性也就是每个步骤的职责边界是不是清晰有没有两个步骤在做同一件事或者某个步骤的输出和另一个步骤的输出有重叠。可验证性也就是每个步骤执行完之后能不能用一个简单的标准判断它做对了没有拆完还要做的事分析步骤依赖关系把能并行的步骤并发跑关键路径时间可以降 40% 到 60%。当然了拆分的粒度把握很重要以原子操作为标准既不能太细也不能太粗Context Engineering 包含哪些内容上下文工程Context Engineering本质上是为 LLM 构建一个高信噪比的信息输入环境。它直接决定了 Agent 的智商上限、任务连贯性以及运行成本。具体来说可以从狭义和广义两个层面来拆解狭义上下文工程主要聚焦于静态的 Prompt 结构化设计。设定 Agent 的人设、工作流规范SOP以及严格的输出格式约束。广义上下文工程囊括了所有影响 LLM 当前决策的输入信息管理。记忆系统Memory短期记忆Session 滑动窗口管理、长期记忆核心事实提取与向量数据库存储。动态增强与挂载RAG Tools根据当前的对话意图动态检索外部文档作为背景知识RAG同时把各种原子工具或复杂技能的功能描述以结构化文本的形式挂载到上下文中让大模型知道当前能调用哪些能力。上下文裁剪与优化Token Optimization这也是工程实践中最关键的一环。因为上下文窗口有限我们需要引入摘要压缩、无用历史剔除或者上下文缓存Context Caching技术在保证信息完整度的同时降低 Token 开销和响应延迟。Context Engineering 包含哪些核心技术我理解的上下文工程Context Engineering远不止是写 System Prompt。如果说大模型是 Agent 的 CPU那么上下文工程就是操作系统的内存管理与进程调度。它的核心目标是在有限的 Token 窗口内以最低的信噪比和成本为模型提供最精准的决策决策依据。我将其总结为三大核心板块静态规则的结构化编排这是 Agent 的出厂设置。为了防止模型在长文本中迷失业界通常采用高度结构化的 Markdown 格式来编排系统提示词强制划分出[Role] 角色设定、[Objective] 核心目标、[Constraints] 严格约束、[Workflow] 标准执行流以及[Output Format] 输出格式。在工程实践中这些规则通常固化为.cursorrules或AGENTS.md这种标准配置文件确保 Agent 在复杂任务中不脱轨。动态信息的按需挂载由于上下文窗口不是垃圾桶必须实现精准的按需加载。工具检索与懒加载比如面对数百个 MCP 工具时先通过向量检索选出最相关的 Top-5 工具定义再挂载避免工具幻觉并节省 Token。动态记忆与 RAG通过滑动窗口管理短期记忆利用向量数据库检索长期事实并将外部执行环境的 Observation如 API 报错日志进行摘要脱水后实时回传。Token 预算与降级折叠机制这是复杂工程中的核心挑战。当长任务接近窗口极限时系统必须具备优先级剔除策略低优先级可折叠将早期的详细对话历史压缩为 AI 摘要。中优先级可精简对 RAG 检索到的背景资料进行二次裁切仅保留核心段落。高优先级绝对保护系统约束Constraints和当前核心工具Tools的描述绝对不能丢失以确保 Agent 的逻辑一致性。优化手段配合 Context Caching上下文缓存 技术在大规模并发请求中进一步降低首字延迟和推理成本。”请你介绍一下 AI Agent 的记忆机制Agent 需要记忆才能在多步任务中保持状态、跨任务积累知识。记忆机制分四层感知记忆当前输入的原始内容用户发来的这条消息、上传的截图、传入的文档。它的生命周期只有一次调用处理完就消失不会主动保留。短期记忆context window 里的对话历史长期记忆存在外部数据库、语义检索召回实体记忆结构化提取的关键事实。四层记忆横向对比类型载体容量生命周期访问方式感知记忆当次输入极小单次调用即时访问短期记忆context window受 token 限制一次任务直接读取长期记忆向量/关系数据库无限持久语义检索实体记忆结构化存储无限持久精确查询在实际开发中应该如何设计Agent的记忆模块实际设计时要解决三个核心问题存什么、怎么存、什么时候取出来用根据信息类型选合适的存储方式再搭配主动检索和按需检索两种策略使用。第一个存什么不是所有内容都值得写入长期记忆存太多反而会引入噪音让检索的精准度下降。判断标准其实很简单「这条信息下次任务开始时如果知道会让 Agent 做得更好吗」通常值得存的有三类用户偏好和习惯语言风格、技术栈偏好、工作习惯、任务执行中产生的关键结论和决策比如「调研发现竞品 A 的定价策略是按用量收费」、以及外部知识产品文档、FAQ、历史案例。不值得存的中间推理过程、工具返回的原始数据日志太啰嗦、闲聊内容。这些存进去只会稀释有价值的记忆让检索的信噪比下降。第二个怎么存根据信息的类型选合适的存储介质而不是一刀切地全部塞进向量数据库。需要语义检索的内容比如文档知识、对话摘要这类非结构化的文本适合存进向量数据库用 embedding 编码后通过相似度检索。结构化的用户偏好和状态字段比如语言偏好、项目配置这些可以精确查询的内容更适合用关系数据库或 Key-Value 存储查询速度快不需要语义理解。整段文档或知识库则适合存进向量数据库配合 RAG 流程做召回。混合存储是主流做法结构化的偏好字段用关系数据库精确查非结构化的知识和历史用向量数据库语义检索两者配合使用。第三个什么时候取出来用这个问题有两种策略实践中通常结合使用。第一种叫「主动检索」在任务开始前用当前任务的描述去检索相关记忆把结果注入 system prompt 作为背景知识。这样 Agent 一开始就带着「历史记忆」进入任务不需要用户每次重新交代背景。第二种叫「被动触发」Agent 在推理过程中判断当前步骤需要某类特定知识时主动发起检索。具体做法是把「查记忆」封装成一个 Tool让 Agent 自己决定什么时候调。这种方式更灵活但依赖模型判断什么时候该去查。实践上两种结合效果最好session 开始时做一次主动检索把关于用户偏好和背景的记忆加载进 system prompt任务执行过程中遇到需要专业知识或历史数据的步骤再让 Agent 按需检索。Context Window 管理短期记忆不够大怎么办Agent 记忆压缩通常有哪些方法短期记忆存在 context window 里而 context window 是有 token 上限的。一个复杂的多步任务对话历史越来越长工具返回的结果越来越多很快就会把 context window 塞满。满了之后新的内容就进不去了或者被迫截断早期的历史Agent 就会「失忆」不知道前面做了什么。记忆压缩常见有四种方法摘要压缩、滑动窗口、重要性过滤、结构化抽取。滑动窗口是只保留最近 N 轮对话摘要压缩是把长对话总结成简短摘要重要性过滤是打分筛选只留重要内容结构化抽取是把关键信息抽成结构化数据存起来。这四种方法不是互斥的也不是按优劣排列的而是从三个不同维度来解决问题的。滑动窗口和摘要压缩解决的是「历史太长怎么截」的问题前者直接截后者截之前先提炼。重要性过滤解决的是「内容不等价怎么挑」的问题打破时间顺序按价值筛选。结构化抽取解决的是「对话文本本身是不是最佳载体」的问题换一种更高效的形式来存储信息。这三个维度可以组合比如先用重要性过滤筛掉低价值内容再用摘要压缩处理剩余历史同时对特定类型的关键信息做结构化抽取。实际系统里往往是多种方法配合使用的。我在实际项目里最常用的是摘要压缩和滑动窗口而且经常组合用。滑动窗口负责控制对话历史的总长度上限摘要压缩负责在历史被丢弃之前做一次提炼把关键信息留下来。这样既有长度控制又不是直接硬截断。如何让 LLM Agent 具备长期记忆能力LLM 本身的上下文窗口通常只有几千到数万 tokens所以需要借助外部机制来扩展其“记忆”能力无法直接处理过多的历史交互信息通过向量数据库RAG机制增强长期记忆“先将对话和知识转换成向量 embedings 存入外部数据库(如FIASS、ChromaDB 或 Pinecone)在新会话发起时根据用户查询检索相关历史内容再将检索到的结果拼接至模型输入上下文弥补原生上下文窗口的缺陷。Memory Transformer/分层记忆体系结合短期记忆(会话上下文)和长期记忆(外部存储的关键摘要或 embeddings)通过 Memory Networks、Neural Turing Machines 或类似机制将重要信息定期摘要成紧凑表示存入专用存储并在需要时根据上下文召回实现分层记忆管理。Agent 的长短期记忆系统怎么做的记忆是怎么存的粒度是多少怎么用的记忆系统分两层短期记忆就是 context window 里的对话历史存当前任务的中间状态任务结束就清掉它就是你每次调 LLM 时传进去的 messages 列表。长期记忆用向量数据库存把信息 embedding 后写入用的时候做语义检索拿回来注入 prompt。长期记忆其实还可以按「类型」细分成三种语义记忆Semantic Memory存的是事实性知识这些是不随时间变化的客观信息。情节记忆Episodic Memory存的是具体事件的经历它带有时间线和因果关系。程序记忆Procedural Memory存的是怎么做某件事的方法论它更像是 Agent 积累下来的行为模式。把记忆按类型区分存储的好处是检索时可以根据当前需求精准地去对应类型的库里查语义记忆库回答「是什么」情节记忆库回答「之前怎么处理过类似情况」程序记忆库回答「该按什么流程来」比一锅端地在混合库里搜召回质量要高不少。粒度通常按一次完整交互或一个关键事件为单位存太细碎检索噪音大太粗糙又丢失细节这个需要根据业务实际调整。什么是 Multi-Agent 系统Multi-Agent 系统是指多个独立 Agent 通过协作完成单一复杂任务的架构每个 Agent 专注于特定角色或职能类比人类的团队分工协作。我理解单个 Agent 主要受两个限制一是 context 窗口大小复杂任务信息量一多就撑爆了二是单点能力什么都让一个 Agent 做每件事都是泛才。Multi-Agent 通过专业分工和并行执行能处理更复杂、更长流程的任务这是我在实际项目里选择多智能体方案的核心原因。核心架构模式Orchestrator-Subagent 模式主流一个编排 AgentOrchestrator负责全局规划和任务分发多个子 AgentSubagent并行或串行执行具体子任务最终由 Orchestrator 汇总输出。Peer-to-Peer 模式Agent 之间平等对话、相互审查如 AutoGen 中的对话式 Agent适合需要辩论或验证的场景如代码审查、文章校对。优缺点