万字长文解读 LLM Agent：总体框架、经典论文与实践

LLM Agent真正走向落地关键不在于给模型叠加更多概念而在于把任务规划、工具调用、环境反馈与自我反思组织成可验证的工程闭环。本文从工具与Agent的基本定义出发梳理总体架构和核心交互机制进一步解读ReAct、Plan-and-Solve等经典工作并延伸到训练数据构建与实践方法帮助开发者建立从论文理解到系统实现的完整视角。基本概念1. 什么是工具只要能够让语言模型从外部获得知识、或者执行操作的接口都可以视为工具。这些“工具”可以是一个检索引擎、一个代码执行器、一个地图 API、一个天气 API、一个与数据库交互的接口等等。2. 为什么要使用工具当前大模型已经具备了很多能力也具备了很强的理解和解决问题能力比如内容创作、语言理解、代码生成等但是依旧无法完成很多复杂的任务。这是因为首先纯LLM的知识固化于训练语料中一旦涉及世界最新资讯或时效性较强的数据如天气、新闻、股票LLM 往往会产生“幻觉”。因此相比其他确定性的工具LLM是“最容易失控的”。这时候通过整合搜索引擎、在线数据库、知识库等工具模型能获得真实世界的知识和反馈在回答用户实时问题时具有更高的准确度与时效性。举例来说检索增强式生成Retrieval-Augmented GenerationRAG就是最常见的工具之一检索引擎可看作是一个“文本搜索”工具我们在用户与LLM交互的时候让LLM能够从外挂知识库中实时检索引入丰富且正确的外部知识避免“幻觉”式回答。其次大模型虽在通用场景下表现出色但当问题需要专业技能如复杂逻辑推理、多语言编程、多模态生成时仅靠自身生成的能力难以解决。如果能“外呼”专业工具如真实执行代码、调用多模态模型等则能大幅提升表现。tool的类型多种多样它们能够帮助LLM完成自己本身做不到的事情3. Agent基本介绍AGENT LLM × 规划记忆工具在这篇文章中我们会对Agent的每个环节做较为详细的介绍。先把架构图放在这里以便有一个整体的认知。在这篇文章中我们会详细介绍规划Planning如何将大型任务分解为较小的、可管理的子目标以便高效的处理复杂任务;反思与自我修正Reflection Self-critics如何对过去的行为进行自我批评和反省并指导接下来的行动记忆Memory工具使用Tool use如何调用外部 API以获取模型权重中缺少的额外信息。4. Agent的不同阶段在这里也是先放一个整体的图以便有整体的认知。之后我们会通过经典论文和实操来了解更具体的细节。Stage 1Task-Planning任务规划是指当模型接收到用户的复杂query后需要先进行意图理解与任务分解。先把整个问题分解成若干容易执行的小任务或步骤并确定这些步骤的依赖关系和执行顺序形成一个有向无环图DAG。Stage 2 Tool Selection在完成任务分解、明确了子问题后模型需要在多个可用的工具或API中检索并选择最合适的工具。不同工具往往功能、输入输出方式都不同因此正确选择不同工具组合对于成功解决子任务至关重要。工具选择的方法也分成两类基于检索器的工具选择Retriever-based Tool Selection。 当工具数目庞大时先用一个外部的检索器来筛选Top-K可能相关的工具再把它们的描述与用户问题一并输入LLM最终由LLM做最后的选择。这是因为模型能接受的上下文长度是有限的如果把所有的工具都堆给它直接就超出了上下文长度这样肯定是不行的。常见的检索方法包括多种传统IR技术TF-IDF/BM25或者语义向量检索。基于LLM的直接选择LLM-based Tool Selection。 当备选的工具数量不是很多时可以直接把工具描述全部拼接进模型输入让LLM选出最优工具。Stage3Tool-Calling在选定要用的工具后LLMs 需要以正确的格式向工具发送调用请求并准确填充调用参数。需要遵循工具说明中要求的格式如参数名称、变量类型、取值范围等否则调用会失败。按照种类来分工具调用分为单工具调用Single Function Call: 如“今天天气怎么样”- 调用get_weather依赖性工具调用Dependent Function Call如“张三的地址处天气怎么样”- 先调用get_address然后调用get_weather平行工具调用Parallel Function Call如“张三的手机号和地址是多少”- 同时调用get_address、get_phone_numberStage4Response Generation工具调用完成后LLM会收到工具调用结果这个结果称为Observation。接下来需要基于这个Observation与自身知识生成最终回答给用户。直接插入式Direct Insertion Methods 这是最简单的办法如让模型回答时先写一句“这里是工具返回结果ToolResult()”然后在呈现给用户前将“ToolResult()”替换成实际工具输出文本。这种方式往往不够灵活也可能影响可读性所以目前使用较少。信息整合式Information Integration Methods 先将Observation作为上下文继续输入LLM让它基于这个信息写出完整、自然的答案。若工具输出过长超出LLM的上下文窗口会先对工具结果进行压缩或抽取。经典论文1. React2022奠定Agent“思考”与“行动”相结合的范式论文标题REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS论文链接https://arxiv.org/pdf/2210.03629这篇系统性地提出了将 Reasoning 与 Acting 结合的范式也就是我们现在熟知的ReAct模式。在 ReAct 模式提出之前LLM的推理主要分为如下两个模式推理Reasoning 例如 Chain-of-Thought (CoT)模型利用内部知识直接输出答案。但是这个的缺点就是模型容易产生幻觉且无法获取外部世界的实时信息。例如问LLM“现在的美国总统是谁”它不能实时联网搜索用的知识都停留在训练时候的老旧数据。行动Acting 模型根据tool-call的执行结果Observation直接输出下一个动作Action。比如下图的(1c)中每次都根据上一轮的Observation来生成下一个动作。(1a) 直接输出答案(1b) 先思考再输出答案 (1c) 只调用工具 (1d) ReAct在调用工具之前先思考在Agent框架下Agent 会不断地与环境交互。 具体地在时间步 tAgent 接收到来自环境的观察 o_t /in /mathcal{O}并根据当前的上下文 c_t (o_1, a_1, /dots, o_{t-1}, a_{t-1}, o_t) 采取行动。Observation观察Agent执行一个动作之后的运行结果比如执行一次数据库查询Observation就是查询的结果。Action动作Agent调用的工具比如search、click等传统策略Act-only通常是学习一个映射 , 其中 是外部动作空间如search[query],click[button]。ReAct 的核心创新在于扩充了动作空间其中 是语言空间。用大白话说就是现在LLM不再是直接输出一个Action了而是先进行一些推理生成Thought然后再输出Action。如上图的(1d)所示每次在生成答案的时候都先生成Thought, 然后再生成Action。Thought 。这是一个内部动作帮助 Agent 整理思路、分解目标或提取关键信息。它不会影响外部环境因此没有对应的观察反馈。Reason-only: 直接输出不调用工具Act-only: 只输出调用工具的ActionReAct: 在输出调用工具的Action之前先进行思考Agent的运行轨迹就是交替Thought - Action - Observation - Thought ...这个做法在现在看来已经是司空见惯尤其是在以o1、deepseek-R1为首的复杂推理模型出来之后都是先做思考thinking、然后再输出答案。我们现在都知道thinking的过程以及thinking长度对于推理结果的正确性而言是非常重要的。不过在当时React还是非常有开创性的。它奠定了Agent“思考”与“行动”相结合的范式也是目前大多数自主Agent框架如LangChain的底层逻辑。2. Plan-and-Solve规划与任务拆解解决长程复杂任务论文标题 Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models论文链接 https://arxiv.org/pdf/2305.04091Plan-and-Solve的核心贡献是提出了“先计划再执行”的策略解决了Agent在面临复杂目标时“走一步看一步”导致的迷失问题。为什么需要用Planner这是因为对于一些复杂的、长链路的任务如“写一个游戏”普通的Agent调用方式如ReAct往往会“走着走着就忘了要去哪”。这时候我们需要就Plan-and-Solve (PS) 模式了先制定完整的计划再逐一执行。在这个模式里面有两个角色Planner和Executor。(a) Planner: 把一个需求变成可执行步骤的“项目经理”。Planner 把一个复杂的任务拆解成 3-5 个清晰的动作有论文验证 plan 的步骤不能过多并且给出不同动作的依赖关系告诉 Agent 哪些步骤可以并行哪些必须串行。这个本质上是创建了一个有向无环图DAG的执行计划后续可以将这些计划分配给对应的 Agent 执行。示例 [1. 搜索2023年财报, 2. 提取净利润数据, 3. 计算同比增长率, 4. 生成图表]在Executor执行的过程中Planner还需要执行监控记录每个任务pending、in progress、completed的状态每完成一步就更新状态。PS 最重要的地方在于动态重规划计划并不是一成不变的而是会根据Executor的执行情况做动态调整。假如某个步骤执行失败了Planner需要根据失败给出原因 改进建议之后进行重新规划。1. **Planner 生成初始计划 [A, B, C, D]。** 2. **Executor 执行 A成功。** 3. **Executor 执行 B失败例如工具报错“数据不存在”。** 4. **Executor 将失败信息反馈给 Planner。** 5. **Planner 被唤醒“任务 B 失败了看来原来的计划行不通。基于现在的观察我需要修改后续计划。”** 6. **Planner 生成新计划 [B, C, D]。** 7. **Executor 继续执行 B。**可选还可以加上human in loop也就是当用户不满意这个plan时可以人为去修改plan。bExecutor拿着 Planner 给的清单一项一项地去调工具执行。二者的交互如下图所示Planner与executor的交互。planner会根据实时的执行结果动态调整planPlan-and-Solve论文中给出的示例如下(a) 普通COT方法 (b) Plan-and-Solve, 先制定计划再一个个执行 © 把执行结果输给LLM生成答案更准确PS在实际应用中的例子Claude-CodeClaude Code 作为Code Agent 也有任务规划模块。下方是Claude Code 的运行截图prompt是帮我生成一个打地鼠游戏它首先做了一个任务规划同时每执行一步都会记录并更新任务的状态“Update Todos”正在进行的任务用彩色表示已经完成任务用绿色表示并用删除线划掉待办的任务用白色表示图片来源https://zhuanlan.zhihu.com/p/19379340937624252143. Reflection自我反思与闭环控制论文标题 Reflexion: Language Agents with Verbal Reinforcement Learning论文链接 https://arxiv.org/pdf/2303.11366核心贡献引入了动态记忆和自我反思机制Agent会根据环境反馈评估自己的表现并将失败经验存入记忆指导下一次尝试。这篇论文是实现自我纠错和Plan-Execute-Observe循环的核心论文。Reflexion的思想很简单就是让Agent从之前的失败中学习。Reflexion会把环境的0/1反馈比如代码执行是否正确或量化的反馈转换成文字描述作为下次迭代中的额外信息让Agent知道怎样改正错误这样就能更好地完成任务了。从上图看出Reflexion框架利用三个不同的模型执行者Actor、评估者Evaluator和自我反思模型Self-Reflection)。Actor基于状态和Observation生成文本和ActionEvaluator对Actor产生的输出计算奖励分数Self-Reflection模型生成自我反思的文本分析以协助Actor自我改进。该过程使用短期和长期记忆其中轨迹历史作为短期记忆而自我反思模型的输出存储在长期记忆中。看下面这个示例图的中间Programming部分可以对上面的流程图有一个直观的了解以代码生成为例在模型拿到一个Task之后它首先生成了一个代码段。之后这个代码段被送给EvaluatorEvaluator会自己生成一些测试用例self-generated unit tests用于测试。假如这个测试失败了assertion fail那么Self-Reflection模型就会分析这次失败的原因形成一个原因分析文本再输入给模型。模型根据上一次失败的教训会重新生成。Self-Reflection在实际应用中的例子swe-agent现在主流的Agent框架都不再采用上述的Actor、Evaluator、Self-Reflection三个模型了而是用一个模型解决所有的问题。具体而言swe-agent是一个让code-agent在其中解决真实repo中issue 报错的框架这个code-agent可以查看文件并运行任意的代码。那么在运行代码的过程中不可避免地会遇到一些报错。这个报错就是模型与环境交互的错误信息了模型在下一步输出的时候就会根据报错的信息进行分析并修复自己的错误。比如在模型认为自己已经修复了issue之后它运行下写的面的代码想看一下自己写的代码是否有效但是很不幸它的代码出现了报错所以之后的轮次模型就在不停地view各种文件并进行修改尝试在经历了若干轮的toolcall-observation-toolcall-observation…之后模型终于解决了问题Agent实践1. Agent训练数据构建用于预训练/SFTstep1. 工具构建工具分为两种真实工具调用外部真实存在的API或服务如天气接口、数据库返回结果是完全真实的如实时股价。但是缺点是开发较为复杂需处理API认证等另外调用成本高频繁使用需支付API费用。虚拟工具工具功能及结果完全由LLM生成无真实后端支持因此不需要API认证等复杂的开发流程也无需API费用。缺点就是结果不可信容易编造不存在的事实、可能违反常识。如果我们方便使用真实工具最好还是使用真实工具的调用结果。例如对于Code-Agent一般都是直接在容器中执行代码并且获得代码的执行结果。只有那种不好调用API的才使用模拟的方式。step2. 任务构建可以使用大模型针对工具List合成问题另外加入persona和场景设计借助指令进化方法使得Agent数据的任务变得更加接近真实使用场景逐渐增加问题难度和多样性。最后可以合并已有的简单任务逐步构建复杂任务。step3. 答案构建搭建带可执行/模拟API调用的环境 → 智能体在环境中交互 → 记录真实调用轨迹trajectory作为训练数据step4. 答案校验为了验证构建轨迹的正确性我们需要进行答案校验。对于那种可以验证正确性的问题我们可以用rule-based的方式来验证正确性。例如对于code-agent任务我们可以通过校验最终的代码是否通过测试用例来验证整个轨迹是否正确。对于那种不好验证正确性的问题我们只能用LLM judge的方式来判断API使用是否合理、工具选择路径是否最优、参数是否合理等。另外还有一个需要注意的一点就是整个轨迹是正确的不代表其中每一步都是正确的因此我们可以对其中不正确的步骤选择mask掉它的loss。例如有的时候LLM生成的工具调用格式可能是错误的如json无法解析、参数格式错误那么这一步是无法调用工具的所以这一步在SFT里面我们不去学习。另外比如code-agent在中间的执行结果可能经常会发生报错那么我们可以选择不去学习导致报错的轮次。2. Agent训练/推理的chat-templateLLMs在聊天应用场景中会由多个消息组成对话在这些消息中每一条都包含一个角色比如system、“user”、“assistant”、“tool”不同的模型会采用截然不同的格式进行训练。一旦模型接受了某种格式的训练需要确保未来的输入使用相同的格式否则就可能会出现损害性能的分布漂移。因此为了使用上的方便防止由于格式不对齐导致chat模型效果有损现在的所有模型均采用在tokenizer中预置chat template的方式固定拼接方式。例如下面就是一个原始对话的例子tools [ { type: function, function: { name: get_current_temperature, description: Get current temperature at a location., parameters: { type: object, properties: { location: { type: string, description: The location to get the temperature for, in the format City, State, Country., }, }, required: [location], }, }, } ] messages [ {role: system, content: You are a helpful agent. n}, {role: user, content: 现在北京的天气怎么样} ]从上面的这段代码我们可以看到它首先有一个system字段描述了 LLM的身份另外有一个第一轮问题user字段 “现在北京的天气怎么样”。另外还有一个tools的定义这个就是工具列表里面有LLM可以调用的所有工具的描述就类似说明书一样描述了每个工具的名称、功能描述、调用参数等。例如上面这个工具叫get_current_temperature,它的作用是实时获得某个地点的温度。它只接受一个传参叫做location是一个string类型的地点信息如Beijing。之后调用apply_chat_template将上面的对话信息变成大模型接受的string类型输入text tokenizer.apply_chat_template( messagesmessages, toolstools, # 所有可调用的工具描述 add_generation_promptTrue, tokenizeFalse )结果如下_systemYou are a helpful agent. # 可用工具 你可以调用tools/tools标签中包含的一个或多个工具来辅助你回答问题,以下是可用工具详情 tools {type: function, function: {name: get_current_temperature, description: Get current temperature at a location., parameters: {type: object, properties: {location: {type: string, description: The location to get the temperature for, in the format City, State, Country.}, unit: {type: string, enum: [celsius, fahrenheit], description: The unit to return the temperature in. Defaults to celsius.}}, required: [location]}}} /tools # 调用方法 你需要遵循工具的要求使用json格式返回工具名称及参数并用tool_calltool_call包含。下方是一个调用模板 tool_call {name: function-name, arguments: args-json-object} /tool_call _user现在北京的天气怎么样_bot将上面的这个文本输入给大模型得到返回结果为了获取当前天气我需要调用get_current_temperature这个工具。 tool_call {name: get_current_temperature, arguments: {location: 北京}} /tool_call之后对这个结果进行解析将tool_call(.*)/tool_call中的部分提取出来尝试使用json进行解析确保可以提取出所调用工具的名字(name)与参数(arguments)如果在tool_call前模型有额外输出作为content字段一并返回给用户如果解析失败模型输出格式不规范则需要返回提示信息给用户并将模型输出直接放进content字段上面结果解析之后如下{ role: assistant, content: 为了获取当前天气我需要调用get_current_temperature这个工具, tool_calls: [ { type: function, function: { name: get_current_temperature, arguments: {location: 北京} } } ] }注意解析的过程一般都是放在vllm里面的所以返回给用户的结果就已经是解析之后的了。用户获取大模型调用工具的具体信息后需要返回给模型调用工具的结果。例如上面调用get_current_temperature API得到北京的温度是10℃。这时候下一步模型的输入就包含了工具调用的结果messages [ { role: system, content: You are a helpful agent. }, { role: user, content: 现在北京的天气怎么样 }, { role: assistant, content: 为了获取当前天气我需要调用get_current_temperature这个工具, tool_calls: [ { type: function, function: { name: get_current_temperature, arguments: {location: 北京} } } ] }, { role: tool, name: get_current_temperature, content: {temperature: 10°C, location: 北京} } ]apply_chat_template之后变成了string格式_systemYou are a helpful agent. ... _user现在北京的天气怎么样 _bot为了获取当前天气我需要调用get_current_temperature这个工具 tool_call {name: get_current_temperature, arguments: {location: 北京}} /tool_call_end _usertool_response{temperature: 10°C, location: 北京}/tool_response_bot用户最终得到的信息是{role:bot, content: 当前北京的天气为10°C。}解决了用户的问题。这里给大家精心整理了一份全面的AI大模型学习资源包括AI大模型全套学习路线图从入门到实战、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等资料免费分享扫码免费领取全部内容1. 成长路线图学习规划要学习一门新的技术作为新手一定要先学习成长路线图方向不对努力白费。这里我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。可以说是最科学最系统的学习成长路线。2. 大模型经典PDF书籍书籍和学习文档资料是学习大模型过程中必不可少的我们精选了一系列深入探讨大模型技术的书籍和学习文档它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。书籍含电子版PDF3. 大模型视频教程对于很多自学或者没有基础的同学来说书籍这些纯文字类的学习教材会觉得比较晦涩难以理解因此我们提供了丰富的大模型视频教程以动态、形象的方式展示技术概念帮助你更快、更轻松地掌握核心知识。4. 2026行业报告行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5. 大模型项目实战学以致用当你的理论知识积累到一定程度就需要通过项目实战在实际操作中检验和巩固你所学到的知识同时为你找工作和职业发展打下坚实的基础。6. 大模型面试题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我们将提供精心整理的大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。7. 资料领取全套内容免费抱走学 AI 不用再找第二份不管你是 0 基础想入门 AI 大模型还是有基础想冲刺大厂、了解行业趋势这份资料都能满足你现在只需按照提示操作就能免费领取扫码免费领取全部内容