简介一份对标大模型应用开发工程师岗位的AI Agent学习资料系统梳理LangChain、LangGraph、Coze、Dify、MCP、RAG与提示词工程等主流技术栈从LLM基础原理、智能体核心组件到企业级部署与微调全链路展开适合从零入门、求职冲刺或项目落地的开发者。资源包共2000个文件包含1588张图解说明、127个Python示例脚本、83篇Markdown笔记、13个实操视频以及多格式文档与数据集整体约513MB按学习阶段与项目模块分类存放便于快速定位。目前已有223人学习下载。内容覆盖金融投研、医疗问诊、电商客服、工业运维、政务解读等真实场景实战项目并附带面试题库、调参建议和故障排查方案可作为从学习到上线的完整参考资料。1. 2026 年 AI Agent 速成指南不是要不要学而是从哪条路切入2026 年聊 AI Agent已经不是要不要学的问题而是从哪条路切入的问题。市面上的速成材料有两个毛病要么从小白科普讲起绕半天没见到 LangChain 一行代码要么直接丢出 LangGraph连 function calling 都没说明白就让你上生产。这篇指南按大模型应用开发工程师的真实岗位技能来拆先立认知讲清 Agent 为什么不是 Chatbot再给完整学习路径用 LangChain 跑通最小闭环接着用 LangGraph 把单轮 Agent 改造成可维护的工作流最后落到面试题库和自检掌握度的验证方法。适合准备转岗、面试或手上有业务但想系统补一遍框架边界的工程师。目标是让你用四到六周能对着真实场景把方案画出来、写出来、上线验证。2. 先搭认知再选框架LLM 调用、工具调用与 Agent 主流架构2.1 从 LLM 到 Agent中间差了一个「工具调用」很多人对着 chatbox 调了几个接口就以为自己在做 Agent。实际上一个裸的 LLM 本质上只是一个「按概率接下文」的模型你给它一段文本它回你一段文本。它没有数据库连接不能读订单系统的接口也不能执行代码。所谓 Agent就是在 LLM 外面包一层循环理解用户输入、决定要不要调用工具、拿到工具结果、再决定下一步动作。这个循环里最关键的咬合点就是工具调用Tool Calling / Function Calling。模型本身不会去访问任何系统它只是输出一个结构化 JSON里面包含你要调用的工具名和参数。真正执行工具的是你写的 Python 代码。执行完你把结果以一条 ToolMessage 追加回对话历史再让模型基于这个结果继续推理。网上常有人问「AI Agent token 是什么意思」——这里的 token 就是你每次循环里来回传递的文本计量单位也是 Agent 成本和时间的主要来源后面讲上下文膨胀时会再回到它。我把这套机制称为 Agent 的「四段式循环」意图输入、模型决策、工具执行、结果回填。无论你用 LangChain、LangGraph 还是 Dify底层都逃不开这四步。区别只在于谁来编排循环状态放哪里异常怎么恢复。2.2 LangChain、LangGraph、Dify、CrewAI2026 年怎么选2026 年聊 Agent 框架最常被拿来对比的就是 LangChain、LangGraph、Dify 和 CrewAI。我的判断是学习顺序先 LangChain 后 LangGraphDify 和 CrewAI 按团队形态决定要不要碰。LangChain 解决的是「把 LLM 和工具粘起来」的组件化问题适合快速原型和 RAGLangGraph 解决的是「状态怎么流转、任务怎么恢复」的工程化问题适合生产级工作流Dify 是低代码可视化平台适合产品同学或非纯代码团队快速验证CrewAI 主打多角色协作在需要模拟团队分工的场景有存在感但企业里落地占比不高。框架核心抽象适合场景学习优先级LangChainChain / Tool / MemoryRAG、快速原型、工具封装先学LangGraphStateGraph / Node / Edge / Checkpoint生产级工作流、多轮状态、人机协同重点补Dify可视化编排、工作流画布低代码验证、非技术团队按需CrewAIRole / Task / Process多角色协作仿真了解我见过不少团队一上来就选 LangGraph结果被状态图绕晕也见过一直停在 LangChain AgentExecutor 的项目跑到上线后被「不可观测、不可打断、不可恢复」折磨。务实的路线是先用 LangChain 把单个 Agent 跑通理解工具调用和 prompt 的作用方式再把循环迁到 LangGraph用图结构把每一步变成可检查的节点。2.3 岗位对标大模型应用开发工程师到底在写什么企业里的大模型应用开发工程师岗位描述写得天花乱坠拆开看核心就几条能设计 prompt 和 few-shot 样例能定义工具 JSON Schema能用框架把模型接到业务系统上能处理多轮上下文能做基础的效果评测。面试题库也是围绕这些能力展开的。很多人背了一堆「什么是 RAG」「什么是微调」的名词可真到现场被问「工具调用失败时你从哪一层排查」立刻露馅。这个岗位的工作更像传统后端开发的变体接口从「第三方 HTTP」变成了「LLM API」业务逻辑里多了一层「模型可能输出错误格式」的不可控性。所以后面所有章节我都会围绕「把不可控的模型行为变成可控的工程行为」来讲——这才是四到六周速成真正要练的东西。3. 完整学习路径从 LLM 基础到 LangChain 最小闭环3.1 四周学习路径表与阶段产出完整学习路径的核心不是「看多少教程」而是「每个阶段有没有拿得出手的产出物」。我给一个可执行的四周拆分每周末你手里应该有一个能跑的代码片段和一张能讲清楚的设计图。周次主题必会产出对应面试考点第 1 周LLM 基础、prompt、temperature、上下文长度一个温度和 system prompt 对照实验脚本temperature 对输出影响、上下文长度限制第 2 周function calling 原理 LangChain 组件bind_tools 跑通一个订单查询工具Tool Schema 怎么设计、pydantic 作用第 3 周AgentExecutor 循环 工具封装一个能回答业务问题的客服 AgentReAct 与原生 Tool Calling 区别第 4 周LangGraph 重构 多轮持久化带状态和 checkpoint 的工作流StateGraph 和 AgentExecutor 区别第 1 周别急着碰框架。先用你最顺手的模型 API 写脚本分别测 temperature0 和 temperature0.9 下同一段 prompt 的输出再故意不写 system prompt 跑一轮你会切身体会「为什么企业里几乎没人把温度调高」。第 2 周开始接触 LangChain重点是工具定义和模型绑定。到了第 3 周才真正让模型进入 Agent 循环。3.2 第一行可运行代码bind_tools 触发工具调用第 2 周的第一个脚本我一般会让新人从 bind_tools 写起。这一步不用管 AgentExecutor只需要让模型输出一个「我要调用工具」的结构化结果from langchain_openai import ChatOpenAI from pydantic import BaseModel, Field # 如果你接的是本地 vLLM/Ollama 等 OpenAI 兼容端点替换 base_url 即可 llm ChatOpenAI( modelqwen-plus, # 换成你手头有 function calling 能力的模型 base_urlhttp://localhost:8000/v1, temperature0, ) class GetOrderStatus(BaseModel): 查询订单状态 order_id: str Field(description订单号形如 2026001) llm_with_tools llm.bind_tools([GetOrderStatus]) resp llm_with_tools.invoke(订单 2026001 现在什么状态) print(resp.tool_calls)这段代码的逻辑是用 Pydantic 类声明工具参数结构bind_tools 把这个结构转换成模型能理解的 JSON Schema 注入请求。模型如果判断需要查询订单就会在返回结果里带上 tool_calls 字段。这里有两个参数值得盯住temperature 设为 0是为了避免采样随机性破坏结构化输出的格式base_url 指向本地端点是因为开发阶段用本地模型调试能省不少成本生产再切商业化 API代码不用改。常见的翻车点是工具描述写得含糊。pydantic 里类的 docstring 和 Field 的 description 会原样进入模型提示描述不清模型就不知道该不该调用这个工具。你多写几个工具后会发现模型参数的准确性一半靠模型能力一半靠你的 Schema 表达得清不清楚。3.3 在 LangChain 里组装 AgentExecutor 跑通 ReAct第 3 周的核心产出是让 Agent 完整跑完一个循环。下面这个例子是客服 Agent 的最小可运行版本我用的姿态是「先跑通再优化」import json from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain.tools import tool from langchain_core.prompts import ChatPromptTemplate llm ChatOpenAI(modelqwen-plus, temperature0) tool def get_order_status(order_id: str) - str: 查询订单状态返回 JSON 字符串。 return json.dumps({order_id: order_id, status: shipped}, ensure_asciiFalse) tool def calculate_shipping(address: str, weight_kg: float) - str: 根据收货地地址和包裹重量估算运费单位元。 return 15.0 tools [get_order_status, calculate_shipping] prompt ChatPromptTemplate.from_messages([ (system, 你是客服助手只能使用工具获取真实信息禁止编造订单状态和运费。), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue, max_iterations5) result executor.invoke({input: 订单 2026001 发货了没运费多少}) print(result[output])这段代码的逻辑是create_tool_calling_agent 依赖模型原生的工具调用能力模型内部完成「该不该调工具」的判断prompt 里的 agent_scratchpad 是占位符运行时会把已经发生的推理和工具结果填进去保证模型看到完整历史。max_iterations5 是安全阀防止模型在工具结果里死循环出不来的情况我在生产环境一般压到 3 到 6。需要特别说明一点传统 ReAct 走的是「Thought / Action / Observation」文本推理而 create_tool_calling_agent 走的是原生 Tool Calling两者在工程上差别很大。原生 Tool Calling 的结构化程度更高解析更稳定2026 年的一线项目几乎都倾向用它。面试若被问到这个区别能说清楚「一个靠解析文本一个靠解析 JSON 字段」会比单纯背概念得分高很多。4. LangGraph 实战把 Agent 从「对话玩具」改成「可控工作流」4.1 StateGraph 的最小认知状态、节点、边、条件路由LangChain 的 AgentExecutor 跑通 demo 很快但真正到生产你会发现它像一个黑匣子循环走到哪一步了状态里积压了多少条消息中途能不能插入人工审批出了问题怎么从某一轮恢复这些它统统不给你抓手。LangGraph 解决的就是这件事。它的核心抽象是状态图所有信息集中在 state 里处理逻辑拆成节点节点之间用边连接边走边就是决策条件。你要先接受一个观念转换在 AgentExecutor 里循环是框架替你维护的在 LangGraph 里循环是你自己画出来的。代价是要多写几行胶水代码收益是每一步都可打断、可检查、可恢复。这个取舍在只做一个周末 demo 时感知不强但一旦 Agent 要处理真实订单、真实转账它就是生死线。4.2 LangGraph 实现订单查询 Agent代码与参数说明沿用第 3.3 节的两个 tool 函数我们把同一个客服 Agent 迁到 LangGraph 上。先定义状态和节点from typing import TypedDict, Annotated, Literal from langgraph.graph import StateGraph, START, END from langgraph.graph.message import add_messages from langchain_core.messages import ToolMessage class AgentState(TypedDict): # add_messages 是 reducer新消息追加进列表而不是覆盖旧列表 messages: Annotated[list, add_messages] def run_agent(state: AgentState): response llm_with_tools.invoke(state[messages]) return {messages: [response]} def run_tools(state: AgentState): last_message state[messages][-1] tool_outputs [] for call in last_message.tool_calls: tool_map {get_order_status: get_order_status, calculate_shipping: calculate_shipping} result tool_map[call[name]].invoke(call[args]) tool_outputs.append(ToolMessage(contentresult, tool_call_idcall[id])) return {messages: tool_outputs} def route_after_agent(state: AgentState) - Literal[tools, __end__]: last_message state[messages][-1] if last_message.tool_calls: return tools return END graph StateGraph(AgentState) graph.add_node(agent, run_agent) graph.add_node(tools, run_tools) graph.add_edge(START, agent) graph.add_conditional_edges(agent, route_after_agent, {tools: tools, END: END}) graph.add_edge(tools, agent) app graph.compile()构图完成后运行时调用方式和 AgentExecutor 很像result app.invoke({messages: [{type: human, content: 订单 2026001 发货了没}]}) print(result[messages][-1].content)这段代码有三个参数细节要讲清楚。第一AgentState 的 messages 字段用 Annotated[list, add_messages] 标注add_messages 是 reducer它决定「节点返回的 messages 和原有 messages 是合并而不是覆盖」没有这个标注每一轮都会把历史消息丢掉Agent 会瞬间失忆。第二run_tools 里构造 ToolMessage 时必须带上 tool_call_id这个 id 必须和 AIMessage 返回的 tool_calls 里那个 id 严格一致模型靠它把工具结果和之前的调用请求对应起来对不上就报错。第三add_conditional_edges 的第三个参数是映射表route_after_agent 返回 tools 就走工具节点返回 END 就结束整个图——这就是「条件路由」的落点。4.3 进阶Checkpointer 做多轮持久化interrupt 做人工审批LangGraph 相比 AgentExecutor 最实用的两个进阶能力一个是多轮持久化一个是人工打断。多轮持久化用 Checkpointer把编译前的 MemorySaver 传入 compileinvoke 时携带一个 thread_id同一线程下的多轮对话就会自动共享历史。这个机制解决的是「用户关掉页面再回来Agent 还认不认得这件事」的问题在客服场景几乎必用。from langgraph.checkpoint.memory import MemorySaver config {configurable: {thread_id: order-2026001}} app graph.compile(checkpointerMemorySaver()) result app.invoke( {messages: [{type: human, content: 刚才我问的订单运费是多少}]}, config, )人工审批适合用在转账、发消息、删除数据这类敏感动作上。通过 interrupt 节点图执行到这里会暂停把审批请求抛给外部系统等人点完「同意」再恢复执行。很多团队上生产时会把「所有写操作都过一遍 interrupt」听起来麻烦实际上是在给模型行为兜底——模型可以出错但错误不能直接落到业务数据上。5. 避坑清单Agent 实战最容易翻车的 4 类问题5.1 温度设置与 system prompt 玄学工具参数为什么会乱现象模型明明声明了工具却把 order_id 填成数字而非字符串或者漏掉必填参数甚至自己拼出一个不存在的工具名。排查到最后问题往往出在 temperature 和 prompt 的相对关系上。原因temperature 大于 0 时模型采样会引入随机性。你把它调到 0.7对话生成确实更「有创造力」但结构化输出也一起被污染了。工具调用的本质是让模型在约束空间里做选择随机性对这种任务是有害的。解决凡是涉及工具调用的节点temperature 一律设 0需要多样性的文本生成单独开一个节点、单独配一个模型实例。system prompt 里明确写「必须通过工具获取数据禁止编造」同时工具描述尽量带上业务上常见的别名。这不是玄学是概率问题——你把随机性降到最低再用 prompt 把选择空间收窄翻车概率自然下来。5.2 工具返回格式不统一LLM 拿到非字符串直接崩现象Agent 第一轮调用工具后报错信息指向 tool_calls processing failure或者模型把工具返回的 None、dict 当成了「查询不到结果」然后自己编一个答案。原因工具函数返回了 Python 对象而不是字符串。LangChain 虽然会尝试把非字符串结果做序列化但只要遇到异常情况返回给模型的内容就不可控。模型侧要求的是干净的文本输入任何反序列化残留都会干扰后续推理。解决所有 tool 函数的返回类型强制写成 str内部用 try/except 包住真实调用tool def get_order_status(order_id: str) - str: 查询订单状态永远返回字符串。 try: data upstream_api.get(order_id) return json.dumps(data, ensure_asciiFalse) except Exception as exc: return f查询失败{exc}这个写法保证了两点模型拿到的永远是合法文本即使上游接口挂了模型也能拿到一个明确的错误状态而不是异常堆栈。把异常吞进工具内部是 Agent 工程里最基本的后悔药。5.3 上下文无限膨胀多轮对话后 Agent 开始「失忆」现象单轮查询表现完美跑到第 10 轮、第 15 轮模型开始重复调用同一个工具或者把用户最早提到的订单号忘掉甚至答非所问。原因messages 列表只增不减很快逼近上下文长度上限。超过模型的有效工作窗口后最早的关键信息比如订单号被截断模型只剩最近几轮的内容看起来就像「失忆」。解决在 LangGraph 的工作流里用 trim_messages 对传入模型的 messages 做裁剪保留 system 和最近几轮而不是一股脑全塞from langchain_core.messages import trim_messages trimmer trim_messages( max_tokens4000, strategylast, start_onhuman, include_systemTrue, ) trimmed_messages trimmer.invoke(state[messages])另一个更彻底的做法是把关键业务字段订单号、用户 id单独放 state 字段不走 messages 列表每次模型需要时从 state 里直接取。我倾向于两者结合state 管关键数据trim 管对话历史。只做裁剪不做关键字段沉淀历史一长照样丢信息。5.4 本地小模型跑 LangGraph路由不准与超时边界现象把 Qwen 7B 这类本地模型接进 LangGraphagent 节点经常不输出 tool_calls或者 route_after_agent 把它误判成结束偶尔调用成功了又因为推理太慢触发 HTTP 超时。原因小模型的 instruction following 能力和工具调用格式稳定性都比大模型弱工具 Schema 稍微复杂一点它就不知道该怎么输出。另一个坑是本地推理速度慢LangChain 侧默认的请求超时撑不住 Agent 循环的多轮往返。解决本地小模型优先选择专门做过 tool calling 微调的版本或者直接换 70B 级别的模型工具描述写得更直白减少嵌套参数。超时方面在 ChatOpenAI 里显式设置 timeout 参数并把 max_iterations 调小避免模型卡在某轮循环里反复重试。记住一条边界小模型能跑通 demo不代表能扛住生产路由不准的问题不是你 prompt 写得不够好而是模型能力天花板摆在那里。6. 面试自检5 道高频题加一条命令验证 Agent 掌握度面试题库要背的东西很多但如果只能押五道题我会押下面这些。它们分别卡住了架构认知、底层原理、框架理解和实战排查四个维度高频面试题考察点Agent 和 Chatbot 的本质区别是什么是否理解工具调用与循环function calling 的原理为什么模型不是「会搜索」是否理解结构化输出与外部执行分离ReAct 文本推理和原生 Tool Calling 的差别是否真正写过 Agent 而非只背概念LangGraph 的 state 为什么要用 add_messages 做 reducer是否理解状态合并机制多轮对话 20 轮后质量下降怎么排查是否有上下文管理实战经验这五题全答上来面试基本能过技术面。但要验证自己真学会了不是靠背题我习惯用一个 20 轮成功率脚本准备一组「必须调用工具才能回答」的问题跑 20 轮统计工具调用命中率和最终答案正确率。from your_project.agent import build_agent cases [ 查询订单 2026001 的状态, 计算到杭州 3kg 的运费, 先查询订单再根据结果计算运费, 你好, # 此条不应触发工具调用 ] def main(): agent build_agent() passed 0 for question in cases: result agent.invoke({input: question}) hit_tool tool_calls in str(result) and len(result.get(tool_calls, [])) 0 expected question.startswith(查询) or question.startswith(计算) if hit_tool expected: passed 1 print(fsuccess_rate{passed / len(cases):.0%}) if __name__ __main__: main()成功率在 90% 以下回头检查工具描述、temperature 和上下文裁剪策略达到 90% 以上再考虑加并发、加人工审批这类生产特性。我每接手一个 Agent 项目第一件事就是把这类脚本丢进去跑一遍这算不上什么聪明技巧只是被坑过太多次换来的习惯。希望帮到你。本文还有配套的精品资源点击获取