本文档系统梳理 AI Agent 的核心理论知识帮助理解”为什么这样设计”为动手构建 Agent 打下认知基础。1. 从 LLM 到 Agent为什么需要 Agent1.1 LLM 的能力与局限大语言模型LLM本质上是一个”文本补全机器”——给定一段文本预测下一个最可能的 token。经过海量数据训练后LLM 展现出了惊人的能力能力说明语言理解理解自然语言的语义、语法、上下文知识存储训练数据中的知识被编码在参数中推理能力能进行一定程度的逻辑推理和分析生成能力生成流畅、连贯的自然语言文本但 LLM 也有明显的局限局限说明举例知识截止训练数据有截止日期不知道最新信息“今天北京天气如何”→ 无法回答无法行动只能生成文本不能执行实际操作“帮我订一张明天的机票”→ 无法执行幻觉问题可能生成看似合理但错误的内容编造不存在的 API 或数据缺乏状态每次调用独立没有持久记忆上一轮对话的信息可能丢失计算受限不擅长精确的数学计算复杂算术可能出错1.2 Agent 如何弥补这些局限Agent 的核心思路是LLM 负责”想”工具负责”做”记忆负责”记”。LLM 单独工作 LLM 作为 Agent 大脑 今天北京天气 今天北京天气 │ │ ▼ ▼ LLM 瞎猜 LLM 思考需要查天气 大概 25°C 吧 │ 可能完全错误 ▼ 调用天气 API 获取真实数据 │ ▼ LLM 组织语言 北京今天晴25°C... 基于真实数据这就是 Agent 的价值让 LLM 从”瞎猜”变成”有据可依”。1.3 一个类比可以把 Agent 理解为一个”聪明的实习生”大脑LLM很聪明理解能力强但不是万事通工具Tools手边有电话、电脑、搜索引擎等工具记忆Memory有笔记本记录之前的对话和任务规划Planning知道如何拆解任务一步步完成老板说”帮我看看明天北京适不适合出差”这个实习生会思考需要查天气和交通信息行动打开天气 App 查天气观察明天有暴雨思考暴雨可能影响航班需要提醒老板回答”明天北京有暴雨建议改期或做好延误准备”这就是 Agent 的工作方式——思考-行动-观察的循环。2. Agent 的定义与核心特征2.1 学术定义Agent智能体在人工智能领域的定义经历了多次演化经典定义Russell NorvigAgent 是能够通过传感器感知环境并通过执行器作用于环境的实体。LLM 时代定义Agent 是以大语言模型为核心推理引擎能够自主规划任务、调用外部工具、管理对话记忆从而完成复杂目标的智能系统。2.2 Agent 的四个核心特征┌────────────────────────────────────────────────┐ │ Agent 四大核心特征 │ │ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ 自主性 │ │ 反应性 │ │ │ │ Autonomy │ │ Reactivity │ │ │ │ │ │ │ │ │ │ 不需要人类 │ │ 能感知环境 │ │ │ │ 逐步指导 │ │ 变化并响应 │ │ │ └──────────────┘ └──────────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ 主动性 │ │ 社交性 │ │ │ │ Pro-activeness│ │ Social Ability│ │ │ │ │ │ │ │ │ │ 能主动采取 │ │ 能与人或其他 │ │ │ │ 行动达成目标 │ │ Agent 交互 │ │ │ └──────────────┘ └──────────────┘ │ └────────────────────────────────────────────────┘1. 自主性 (Autonomy)Agent 能够在没有人类逐步指导的情况下独立运作。用户只需提出目标”查一下北京天气”Agent 自主决定调用什么工具、传什么参数、如何组织回答。2. 反应性 (Reactivity)Agent 能感知环境的变化并做出响应。当工具返回错误时Agent 能识别问题并尝试其他方案而不是直接崩溃。3. 主动性 (Pro-activeness)Agent 不仅被动响应还能主动采取行动。比如查到明天有暴雨主动建议用户带伞而不是只报温度数字。4. 社交性 (Social Ability)Agent 能够与用户进行自然的对话交互理解上下文甚至能与其他 Agent 协作Multi-Agent 场景。2.3 Agent vs. Chatbot vs. Copilot维度ChatbotCopilotAgent核心能力对话回复辅助建议自主完成任务是否调用工具通常不调有限调用自主决定并调用决策权无人类主导Agent 主导典型产品客服机器人GitHub CopilotAutoGPT, Cursor Agent任务复杂度单轮 QA单步辅助多步骤复杂任务3. Agent 的认知架构3.1 整体架构一个完整的 Agent 系统可以分解为以下核心组件┌──────────────────────────────────────────────────────┐ │ Agent 认知架构 │ │ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ 感知层 (Perception) │ │ │ │ 接收用户输入、工具返回结果、环境反馈 │ │ │ └───────────────────────┬─────────────────────────┘ │ │ │ │ │ ┌───────────────────────▼─────────────────────────┐ │ │ │ 认知层 (Cognition) │ │ │ │ ┌──────────┐ ┌───────────┐ ┌──────────────┐ │ │ │ │ │ 理解 │ │ 推理 │ │ 规划 │ │ │ │ │ │ 意图解析 │→ │ 逻辑思考 │→ │ 任务分解 │ │ │ │ │ └──────────┘ └───────────┘ └──────────────┘ │ │ │ └───────────────────────┬─────────────────────────┘ │ │ │ │ │ ┌───────────────────────▼─────────────────────────┐ │ │ │ 行动层 (Action) │ │ │ │ 执行工具调用、生成回复、与环境交互 │ │ │ └───────────────────────┬─────────────────────────┘ │ │ │ │ │ ┌───────────────────────▼─────────────────────────┐ │ │ │ 记忆层 (Memory) │ │ │ │ 存储对话历史、工具结果、学习到的知识 │ │ │ └─────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────┘3.2 各层职责感知层 (Perception)接收用户的自然语言输入接收工具执行的返回结果感知上下文环境对话历史、当前状态认知层 (Cognition)— 由 LLM 驱动理解解析用户意图想查天气想订餐闲聊推理基于当前信息做出判断需要调用哪个工具参数是什么规划复杂任务的分解与排序先查城市 ID再查天气数据行动层 (Action)调用外部工具API 请求、数据库查询等生成自然语言回复执行系统操作记忆层 (Memory)维护对话历史存储工具调用结果管理上下文窗口4. 推理模式Agent 如何思考推理模式决定了 Agent “怎么想问题”。这是 Agent 最核心的能力不同的推理模式适合不同的场景。4.1 ReActReasoning Acting论文《ReAct: Synergizing Reasoning and Acting in Language Models》(Yao et al., 2022)ReAct 是目前最主流的 Agent 推理模式核心思想是让 LLM交替进行推理和行动。核心循环Thought思考→ Action行动→ Observation观察→ Thought → ...示例用户北京明天适合跑步吗 Thought 1: 用户想知道明天北京是否适合跑步我需要查询明天的天气信息 重点关注是否下雨、温度、空气质量等。 Action 1: get_weather(city北京, forecasttrue) Observation 1: 明天北京多云气温 18-24°C湿度 45%空气质量良 东南风 2 级 Thought 2: 天气数据显示明天多云、气温适宜、空气质量良好、风力不大 这是很适合跑步的天气条件。我可以给出肯定的建议了。 Action 2: [无需更多工具调用直接回答] 最终回答明天北京多云气温 18-24°C空气质量良好风力也不大 非常适合户外跑步建议选择早晨或傍晚时段温度更舒适。为什么 ReAct 有效思考使行动更准确LLM 先分析需要什么信息再决定调用哪个工具行动使思考有依据获取真实数据后推理基于事实而非猜测过程可解释每一步的推理过程都是透明的便于调试和理解ReAct vs. 纯推理 vs. 纯行动模式做法问题纯推理 (CoT)只思考不调工具无法获取实时信息容易幻觉纯行动 (Act)不思考直接调工具可能调错工具或传错参数ReAct边思考边行动兼具准确性和灵活性4.2 Chain of Thought思维链论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》(Wei et al., 2022)CoT 不是 Agent 模式但它是 Agent 推理的基础。核心思想让 LLM一步步地思考而不是直接跳到答案。不用 CoT 问一个商店苹果 3 元一斤买 5 斤给了 20 元找零多少 答5 元 用 CoT 问一个商店苹果 3 元一斤买 5 斤给了 20 元找零多少 答让我一步步想 1. 苹果 3 元/斤买 5 斤 2. 总价 3 × 5 15 元 3. 给了 20 元 4. 找零 20 - 15 5 元 答案是 5 元在 Agent 中Thought 阶段本质上就是 CoT 推理。4.3 Plan-and-Execute计划与执行适合复杂任务的模式先制定完整计划再逐步执行。用户帮我规划一个北京三日游 Plan一次性规划: 1. 查询北京未来三天天气 2. 根据天气推荐室内/室外景点 3. 安排每日行程 4. 推荐附近餐厅 Execute逐步执行: Step 1: 调用 get_weather → 获取天气 Step 2: 调用 search_attractions → 获取景点 Step 3: 组织行程安排 Step 4: 调用 search_restaurant → 获取餐厅推荐ReAct vs. Plan-and-Execute维度ReActPlan-and-Execute规划时机每步动态决策先规划后执行适合场景简单/中等任务复杂多步任务灵活性高可随时调整中计划修改成本较高实现难度低中4.4 Reflection反思论文《Reflexion: Language Agents with Verbal Reinforcement Learning》(Shinn et al., 2023)让 Agent 回顾自己的行为从错误中学习第一次尝试 Action: get_weather(cityBJ) Observation: 错误未找到城市 BJ Reflection: 我用了英文缩写 BJ但天气 API 需要中文城市名。 下次应该使用 北京 而不是缩写。 第二次尝试修正后 Action: get_weather(city北京) Observation: 成功获取天气数据5. 工具使用Agent 如何行动5.1 为什么需要工具LLM 的知识是”冻结”在训练数据中的。工具让 Agent 能够工具能力示例获取实时信息天气 API、新闻 API、股票 API执行计算计算器、代码执行器操作外部系统发邮件、操作数据库、调用第三方服务检索知识搜索引擎、知识库、向量数据库5.2 工具的标准定义在 LLM Agent 中一个工具需要包含三要素这样 LLM 才能正确理解和使用它工具三要素 ┌─────────────────────────────────────────────┐ │ 1. Name名称 │ │ 工具的唯一标识符 │ │ 例get_weather │ ├─────────────────────────────────────────────┤ │ 2. Description描述 │ │ 告诉 LLM 这个工具做什么、什么时候该用它 │ │ 例查询指定城市的实时天气和天气预报 │ ├─────────────────────────────────────────────┤ │ 3. Parameters参数 │ │ JSON Schema 格式定义输入参数 │ │ 例{city: string(required), ...} │ └─────────────────────────────────────────────┘描述的质量直接影响 LLM 是否正确选择和使用工具。好的描述应该清晰说明工具的功能说明什么情况下应该使用说明参数的含义和格式差的描述 天气工具 好的描述 查询指定城市的天气信息包括实时天气和未来天气预报。 当用户询问任何与天气、温度、降雨、穿衣建议相关的问题时使用。5.3 工具设计原则原则一单一职责每个工具只做一件事。不要设计一个”万能工具”。差一个 local_life_tool 既查天气又查餐厅又查路线 好get_weather、search_restaurant、get_route 各司其职原则二参数清晰参数命名要直观description 要详细让 LLM 能准确传参。# 差参数含义模糊 {q: {type: string}, t: {type: integer}} # 好参数自解释 { city: {type: string, description: 城市名称如北京}, forecast_days: {type: integer, description: 预报天数1-7} }原则三返回值信息充分工具返回的信息要足够丰富让 LLM 能基于结果生成有价值的回答。# 差信息太少 return 25°C # 好信息充分 return 城市北京天气晴温度25°C体感温度27°C湿度40%风向东南风 2 级空气质量良原则四优雅的错误处理工具出错时返回清晰的错误信息而不是抛出异常让 Agent 崩溃。# 差直接抛异常 raise Exception(API Error 500) # 好返回友好错误信息 return 查询失败未找到城市xxx请检查城市名称是否正确5.4 工具调用的生命周期1. 注册阶段 ┌──────────────────────────────────────────┐ │ Agent 启动时所有工具注册到 ToolRegistry │ │ 每个工具提供 name description schema │ └──────────────────────────────────────────┘ │ 2. 描述阶段 ▼ ┌──────────────────────────────────────────┐ │ 每次请求 LLM 时将所有工具的 schema │ │ 作为 tools 参数传给 LLM │ └──────────────────────────────────────────┘ │ 3. 选择阶段 ▼ ┌──────────────────────────────────────────┐ │ LLM 根据用户意图和工具描述 │ │ 决定是否调用工具调用哪个传什么参数 │ └──────────────────────────────────────────┘ │ 4. 执行阶段 ▼ ┌──────────────────────────────────────────┐ │ Agent 根据 LLM 返回的 tool_calls │ │ 找到对应工具并执行获取结果 │ └──────────────────────────────────────────┘ │ 5. 反馈阶段 ▼ ┌──────────────────────────────────────────┐ │ 将工具执行结果以 tool 消息反馈给 LLM │ │ LLM 基于结果生成最终回答或继续调用工具 │ └──────────────────────────────────────────┘6. 记忆系统Agent 如何记住6.1 为什么需要记忆没有记忆的 Agent 每次对话都从零开始无法理解上下文没有记忆 用户北京天气怎么样 Agent北京今天晴25°C。 用户那上海呢 Agent你在说什么的上海丢失了天气这个上下文 有记忆 用户北京天气怎么样 Agent北京今天晴25°C。 用户那上海呢 Agent回忆之前在聊天气上海今天多云28°C。6.2 记忆的分类┌──────────────────────────────────────────────────┐ │ Agent 记忆体系 │ │ │ │ ┌─────────────────────────────────────────────┐ │ │ │ 短期记忆 (Short-term / Working Memory) │ │ │ │ │ │ │ │ • 当前对话的消息历史 │ │ │ │ • 本轮任务的中间状态 │ │ │ │ • 生命周期单次对话 │ │ │ │ • 实现消息列表 (messages[]) │ │ │ └─────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────┐ │ │ │ 长期记忆 (Long-term Memory) [进阶] │ │ │ │ │ │ │ │ • 跨对话的持久化知识 │ │ │ │ • 用户偏好和画像 │ │ │ │ • 生命周期持久 │ │ │ │ • 实现数据库 / 向量数据库 │ │ │ └─────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────┘6.3 短期记忆的实现消息列表在 OpenAI 兼容的 API 中对话历史以消息列表的形式传递。每条消息有一个roleRole含义示例system系统指令定义 Agent 的角色和行为规范“你是一个本地生活助手…”user用户的输入“北京天气怎么样”assistantAgent 的回复或工具调用决策“北京今天晴…” / tool_callstool工具执行的返回结果“温度25°C湿度40%…”一个典型的消息历史[ {role: system, content: 你是一个本地生活助手...}, {role: user, content: 北京天气怎么样}, {role: assistant, content: null, tool_calls: [ {id: call_1, function: {name: get_weather, arguments: {\city\:\北京\}}} ]}, {role: tool, tool_call_id: call_1, content: 北京晴25°C湿度 40%}, {role: assistant, content: 北京今天天气晴朗气温 25°C相对湿度 40%非常适合外出}, {role: user, content: 明天呢} ]6.4 上下文窗口管理LLM 有 token 数量限制如 Qwen 的 qwen-plus 模型上下文窗口为 128K tokens。当对话很长时需要管理消息列表的大小。策略一滑动窗口保留最近 N 条消息丢弃最早的消息。消息历史: [msg1, msg2, msg3, msg4, msg5, msg6, msg7, msg8] 窗口大小: 5 实际发送: [system_prompt, msg4, msg5, msg6, msg7, msg8]优点实现简单适合大多数场景。 缺点可能丢失早期重要信息。策略二摘要压缩进阶定期让 LLM 总结历史对话用摘要替代原始消息。原始历史: [msg1, msg2, msg3, msg4, msg5] 压缩后: [summary(用户询问了北京天气和上海天气), msg4, msg5]优点保留关键信息节省 token。 缺点实现复杂摘要可能丢失细节。策略三检索增强高级将历史消息存入向量数据库每次根据当前问题检索相关的历史片段。优点能精准回忆相关信息。 缺点需要向量数据库支持实现较复杂。7. Prompt EngineeringAgent 的灵魂7.1 System Prompt 的作用System Prompt 是 Agent 的”性格说明书”它定义了┌────────────────────────────────────────────┐ │ System Prompt 四要素 │ │ │ │ 1. 角色定义 → Agent 是谁 │ │ 2. 能力边界 → Agent 能做什么、不能做什么 │ │ 3. 行为规范 → Agent 应该如何回答 │ │ 4. 工具指导 → 什么时候用什么工具 │ └────────────────────────────────────────────┘7.2 System Prompt 设计模板[角色定义] 你是一个{角色名}专注于{领域}。 [能力说明] 你具备以下能力 - {能力1} - {能力2} [行为规范] 在回答时请遵循以下规则 1. {规则1} 2. {规则2} 3. {规则3} [工具使用指导] 当用户{场景1}时使用 {工具名} 工具。 当用户{场景2}时使用 {工具名} 工具。 [限制] - 不要{限制1} - 如果{情况}请{处理方式}7.3 实际示例本地生活 Agent你是一个本地生活助手擅长帮助用户解决日常生活中的各种问题。 你具备以下能力 - 查询任意城市的实时天气和天气预报 - 根据天气情况给出贴心的生活建议 在回答时请遵循以下规则 1. 回答要自然、友好像朋友一样交流 2. 查询到天气数据后主动给出穿衣、出行等生活建议 3. 如果用户没有指定城市礼貌地询问 4. 使用中文回答所有问题 工具使用指导 - 当用户询问天气、温度、是否下雨、穿什么衣服等问题时使用 get_weather 工具 - 优先使用工具获取准确数据不要凭记忆回答天气问题 限制 - 不要编造天气数据必须通过工具获取 - 如果工具调用失败坦诚告知用户暂时无法获取天气信息7.4 Prompt 调优技巧技巧一给出正例在 Prompt 中展示期望的回答风格回答示例 用户上海天气怎么样 助手上海今天天气不错哦气温 28°C晴天湿度适中。 不过紫外线较强出门记得做好防晒技巧二明确边界条件告诉 Agent 遇到异常情况该怎么办特殊情况处理 - 如果用户问的不是天气相关问题友好地告知目前只支持天气查询 - 如果城市名无法识别请用户确认城市名称 - 如果天气 API 返回错误告知用户天气服务暂时不可用请稍后再试技巧三控制回答长度和格式回答长度简洁明了通常 2-4 句话即可不要过于啰嗦。8. Function Calling从理论到实现的桥梁8.1 什么是 Function CallingFunction Calling 是 LLM 提供的一种结构化输出能力。通常 LLM 返回的是自由文本但 Function Calling 让 LLM 可以返回结构化的工具调用指令。没有 Function Calling LLM 输出我需要查询北京的天气。城市是北京。 Agent 需要解析这段文本提取出查天气和北京 → 容易出错 有 Function Calling LLM 输出{ tool_calls: [{ function: { name: get_weather, arguments: {\city\: \北京\} } }] } Agent 直接解析 JSON精准调用工具 → 可靠8.2 Function Calling 的工作流程Step 1: 定义工具 → 告诉 LLM 有哪些工具可用 ┌────────────────────────────────────┐ │ tools [{ │ │ type: function, │ │ function: { │ │ name: get_weather, │ │ description: 查询天气, │ │ parameters: { │ │ type: object, │ │ properties: { │ │ city: { │ │ type: string, │ │ description: 城市名 │ │ } │ │ }, │ │ required: [city] │ │ } │ │ } │ │ }] │ └────────────────────────────────────┘ │ Step 2: 发送请求 → 把消息和工具定义一起发给 LLM │ ▼ Step 3: LLM 决策 → LLM 分析后决定是否调用工具 ┌────────────────────────────────────┐ │ response.choices[0].message: │ │ role: assistant │ │ content: null │ │ tool_calls: [{ │ │ id: call_abc123, │ │ type: function, │ │ function: { │ │ name: get_weather, │ │ arguments: {city:北京} │ │ } │ │ }] │ └────────────────────────────────────┘ │ Step 4: 执行工具 → Agent 解析 tool_calls执行对应工具 │ ▼ Step 5: 反馈结果 → 将工具结果作为 tool 消息发回 LLM ┌────────────────────────────────────┐ │ messages.append({ │ │ role: tool, │ │ tool_call_id: call_abc123, │ │ content: 北京晴25°C... │ │ }) │ └────────────────────────────────────┘ │ Step 6: 最终回答 → LLM 根据工具结果生成自然语言回答8.3 tool_choice 参数tool_choice控制 LLM 是否调用工具值含义autoLLM 自行决定是否调用工具推荐none禁止调用任何工具required强制调用工具{type: function, function: {name: xxx}}强制调用指定工具8.4 并行工具调用LLM 可以在一次响应中返回多个 tool_calls表示需要并行调用多个工具{ tool_calls: [ {id: call_1, function: {name: get_weather, arguments: {\city\:\北京\}}}, {id: call_2, function: {name: get_weather, arguments: {\city\:\上海\}}} ] }Agent 应依次或并行执行所有工具调用并将结果全部返回给 LLM。9. Agent 设计模式9.1 单 Agent 模式最简单的模式一个 Agent 处理所有任务。用户 ←→ AgentLLM 工具集适合场景功能相对集中、工具数量较少 10 个的应用。9.2 路由 Agent 模式一个路由 Agent 根据用户意图将任务分发给专门的子 Agent。┌───────────────┐ │ Router Agent │ │ 意图分发 │ └───────┬───────┘ ┌─────────────┼─────────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 天气 Agent│ │ 美食 Agent│ │ 出行 Agent│ └──────────┘ └──────────┘ └──────────┘适合场景功能领域差异大每个领域需要不同的 Prompt 和工具集。9.3 多 Agent 协作模式多个 Agent 分工协作完成复杂任务。用户帮我规划周末行程 │ ┌───────┴───────┐ ▼ ▼ 天气 Agent 景点 Agent │ │ └───────┬───────┘ ▼ 行程规划 Agent │ ▼ 输出最终方案适合场景非常复杂的任务需要多个专业领域的知识。9.4 演进路径常见的架构演进路径阶段 1当前 阶段 2 阶段 3 单 Agent 天气工具 → 单 Agent 多工具 → 路由 Agent 子 Agent 简单 中等 高级从简单开始等工具数量超过 10 个或领域差异很大时再考虑升级架构。10. 常见陷阱与最佳实践10.1 陷阱一无限循环问题Agent 反复调用工具但不返回最终答案。原因LLM 无法根据工具结果做出判断或工具返回的信息不足。解决设置最大迭代次数MAX_ITERATIONS优化工具返回值提供足够信息在 System Prompt 中指导 LLM 何时应该停止调用工具10.2 陷阱二工具选择错误问题LLM 选了错误的工具或传了错误的参数。原因工具描述不够清晰或参数 description 含糊。解决写清晰、具体的工具描述参数 description 要包含格式和示例减少工具间的功能重叠10.3 陷阱三上下文爆炸问题对话过长导致超出 LLM 上下文窗口限制。原因没有管理消息历史的长度。解决实现滑动窗口策略工具返回值做必要截断避免超长文本监控每次请求的 token 数量10.4 陷阱四错误处理缺失问题API 调用失败时 Agent 直接崩溃。原因没有在工具层做异常捕获。解决每个工具内部用 try-except 包裹返回结构化的错误信息而非抛异常Agent 层面对工具错误有兜底处理10.5 最佳实践清单实践说明先跑通再优化先用最简单的方式实现 Agent 循环再逐步优化日志要充分记录每次 LLM 调用的输入输出、工具调用详情工具描述是关键花时间写好工具的 description这比调代码更重要Prompt 迭代System Prompt 需要反复调试观察 Agent 行为后不断优化设置安全阀MAX_ITERATIONS、超时时间、重试次数都要有上限渐进式扩展一次只加一个工具确认稳定后再加下一个11. 参考资料11.1 核心论文论文年份要点ReAct: Synergizing Reasoning and Acting in Language Models2022ReAct 推理模式的提出Chain-of-Thought Prompting Elicits Reasoning in LLMs2022思维链推理的基础Toolformer: Language Models Can Teach Themselves to Use Tools2023LLM 自主学习使用工具Reflexion: Language Agents with Verbal Reinforcement Learning2023Agent 自我反思机制A Survey on Large Language Model based Autonomous Agents2023LLM Agent 综述想入门 AI 大模型却找不到清晰方向备考大厂 AI 岗还在四处搜集零散资料别再浪费时间啦2025 年AI 大模型全套学习资料已整理完毕从学习路线到面试真题从工具教程到行业报告一站式覆盖你的所有需求现在全部免费分享扫码免费领取全部内容​一、学习必备100本大模型电子书26 份行业报告 600 套技术PPT帮你看透 AI 趋势想了解大模型的行业动态、商业落地案例大模型电子书这份资料帮你站在 “行业高度” 学 AI1. 100本大模型方向电子书2. 26 份行业研究报告覆盖多领域实践与趋势报告包含阿里、DeepSeek 等权威机构发布的核心内容涵盖职业趋势《AI 职业趋势报告》《中国 AI 人才粮仓模型解析》商业落地《生成式 AI 商业落地白皮书》《AI Agent 应用落地技术白皮书》领域细分《AGI 在金融领域的应用报告》《AI GC 实践案例集》行业监测《2024 年中国大模型季度监测报告》《2025 年中国技术市场发展趋势》。3. 600套技术大会 PPT听行业大咖讲实战PPT 整理自 2024-2025 年热门技术大会包含百度、腾讯、字节等企业的一线实践安全方向《端侧大模型的安全建设》《大模型驱动安全升级腾讯代码安全实践》产品与创新《大模型产品如何创新与创收》《AI 时代的新范式构建 AI 产品》多模态与 Agent《Step-Video 开源模型视频生成进展》《Agentic RAG 的现在与未来》工程落地《从原型到生产AgentOps 加速字节 AI 应用落地》《智能代码助手 CodeFuse 的架构设计》。二、求职必看大厂 AI 岗面试 “弹药库”300 真题 107 道面经直接抱走想冲字节、腾讯、阿里、蔚来等大厂 AI 岗这份面试资料帮你提前 “押题”拒绝临场慌1. 107 道大厂面经覆盖 Prompt、RAG、大模型应用工程师等热门岗位面经整理自 2021-2025 年真实面试场景包含 TPlink、字节、腾讯、蔚来、虾皮、中兴、科大讯飞、京东等企业的高频考题每道题都附带思路解析2. 102 道 AI 大模型真题直击大模型核心考点针对大模型专属考题从概念到实践全面覆盖帮你理清底层逻辑3. 97 道 LLMs 真题聚焦大型语言模型高频问题专门拆解 LLMs 的核心痛点与解决方案比如让很多人头疼的 “复读机问题”三、路线必明AI 大模型学习路线图1 张图理清核心内容刚接触 AI 大模型不知道该从哪学起这份「AI大模型 学习路线图」直接帮你划重点不用再盲目摸索路线图涵盖 5 大核心板块从基础到进阶层层递进一步步带你从入门到进阶从理论到实战。L1阶段:启航篇丨极速破界AI新时代L1阶段了解大模型的基础知识以及大模型在各个行业的应用和分析学习理解大模型的核心原理、关键技术以及大模型应用场景。L2阶段攻坚篇丨RAG开发实战工坊L2阶段AI大模型RAG应用开发工程主要学习RAG检索增强生成包括Naive RAG、Advanced-RAG以及RAG性能评估还有GraphRAG在内的多个RAG热门项目的分析。L3阶段跃迁篇丨Agent智能体架构设计L3阶段大模型Agent应用架构进阶实现主要学习LangChain、 LIamaIndex框架也会学习到AutoGPT、 MetaGPT等多Agent系统打造Agent智能体。L4阶段精进篇丨模型微调与私有化部署L4阶段大模型的微调和私有化部署更加深入的探讨Transformer架构学习大模型的微调技术利用DeepSpeed、Lamam Factory等工具快速进行模型微调并通过Ollama、vLLM等推理部署框架实现模型的快速部署。L5阶段专题集丨特训篇 【录播课】四、资料领取全套内容免费抱走学 AI 不用再找第二份不管你是 0 基础想入门 AI 大模型还是有基础想冲刺大厂、了解行业趋势这份资料都能满足你现在只需按照提示操作就能免费领取扫码免费领取全部内容​2025 年想抓住 AI 大模型的风口别犹豫这份免费资料就是你的 “起跑线”