Agent 开发是当前 AI 应用方向里离业务最近的技能之一。最近看到一份实战学习体系标题写得很直接从入门到 Agent 开发大佬包含 RAG、Agent、LangChain、应用落地50 个实战项目初中高级全都有并且明确强调“可写进简历”。这套东西覆盖的技术栈正好是当前 AI 应用岗位招聘 JD 里反复出现的组合。先给结论这个学习路线是能落地的。RAG 解决知识库问答Agent 解决自动调用工具完成复杂任务LangChain 负责把组件串联起来LangGraph 负责流程编排和状态控制。从最近各类 RAG 实战、LangChain 实战、Agent 开发学习路线相关讨论来看核心技能点高度重合。你把这条链路跑通基本等于打通了 AI 应用开发的主干线。这篇文章会把整个知识体系拆开讲清楚然后给出三段可以直接运行的代码示例RAG 文档问答链路、Agent 工具调用、LangGraph 工作流编排再分析 50 个实战项目怎么分层、怎么挑、怎么写进简历最后补一份常见问题和排查清单。硬件、显存、接口依赖会在对应章节说明尽量不让你卡在环境上。适合这几类读者正在准备 Agent 开发面试的人后端、前端开发想转到 AI 应用方向的人已经会用大模型 API 但想补工程化能力的开发者以及需要做知识库问答、智能客服、自动化流程等业务方案的技术负责人。内容偏实践建议一边看一边敲代码。1. 核心能力速览能力项说明学习定位Agent 开发实战体系覆盖入门到高级核心技术栈RAG、Agent、LangChain、LangGraph实战项目规模标题明确提到 50 个实战项目初中高级分层主要应用场景知识库问答、Agent 自动化工具调用、企业级 AI 工作流前置基础Python 基础、大模型 API 基础关键词覆盖RAG、向量化、Embedding、重排、Agent、ReAct、工具调用、多 Agent、LangGraph简历价值标题定位“可写进简历”偏求职导向硬件需求视部署方式而定API 调用几乎无本地硬件门槛本地模型部署需按模型实测适合人群想转 AI 应用开发、准备 Agent 面试、补工程化能力的开发者从标题信息看这属于“从应用到工程”的全链路学习资源不是单纯讲概念的入门课。它的亮点不在于某个单独知识点而在于把 RAG、Agent、LangChain 这三件事串成一条完整的学习路径这是很多零散教程做不到的。2. 适用场景与学习边界这套体系最适合解决一个核心问题把“会调用大模型 API”升级成“能搭建完整 AI 应用”。普通开发者最常见的瓶颈不是不会写 Prompt而是不知道怎么处理文档切分、检索召回、工具调用、状态管理这些工程环节。RAG 和 Agent 恰好是这两个方向的基础设施。具体来说学完这套内容后你可以做出这样的应用上传一批内部文档让 Agent 自动回答文档相关问题给你一个需求Agent 自动拆解步骤并调用搜索、计算、日程等工具完成整个任务或者用 LangGraph 把一个复杂的多步骤业务流编排成可维护的图结构。这些都是市场上真实存在的业务需求。但它不太适合以下场景想研究模型预训练和微调算法的人这套体系偏应用工程而非算法研究完全零编程基础的人至少要有 Python 语法基础再开始只想拿一个“一键部署包”而不想理解原理的人这套体系强调手写链路和问题排查需要投入实操时间。使用边界必须强调。RAG 知识库涉及文档语料语料来源要有合法授权不能把未授权抓取的内部数据入库。Agent 连接外部工具时要注意权限最小化不要给 Agent 开放超出业务范围的系统操作权限。生成内容要做人工复核尤其是面向外部用户或涉及专业判断的场景。这些合规要求不是附加项而是 Agent 应用能否落地的前提。3. 知识体系拆解Agent、RAG、LangChain、LangGraph很多人在学习时会卡在第一步Agent、RAG、LangChain、LangGraph 到底是什么关系这里先把这个底层结构理清楚。3.1 Agent 是什么Agent 是智能体核心公式可以写成Agent LLM 规划 工具 记忆。LLM 是决策大脑负责理解用户意图规划负责把复杂任务拆解成多个步骤工具负责执行具体动作记忆保存对话上下文和历史状态。举一个实际例子。用户说“帮我查下周一下午有没有空闲会议室有的话帮我预订一间”。传统程序需要写死条件判断而 Agent 可以自主完成调用会议室查询工具 - 拿到空闲列表 - 判断哪个会议室合适 - 调用预订工具 - 返回结果。整个过程中模型决定“下一步调用哪个工具”而不是程序员写死逻辑。3.2 RAG 解决什么问题RAGRetrieval-Augmented Generation检索增强生成解决的是模型“不知道”的问题。大模型训练数据有截止时间也不知道企业私有知识。RAG 的思路是用户提问后先把问题向量化在知识库中检索最相关的内容片段把这些片段拼接到 Prompt 里再让模型基于这些内容生成回答。RAG 五步链路是固定的文档加载、文本切分、向量化、检索、生成。实际工程中还会加一个重排Rerank环节用来对检索回来的候选结果做二次排序。很多人在热词里看到“rag向量化流程”“embedding rerank”指的就是这条链路中的关键环节。3.3 LangChain 和 LangGraph 的区别这是一个高频问题。LangChain 是一套工具集提供模型封装、Prompt 模板、文档加载器、向量存储对接、Chain 串联方式。它适合快速构建结构化链路比如“加载文档 - 切分 - 向量化 - 检索 - 调用模型回答”几十行代码就能跑通。LangGraph 是编排层定位更接近“流程引擎”。它用图的方式控制状态、条件路由、循环和分支。复杂 Agent 场景经常需要“判断是否要继续检索”“多个工具按条件执行”“多轮循环直到任务完成”这类需求用 LangChain 的 Chain 表达起来很别扭用 LangGraph 的节点和边就清晰很多。更稳妥的判断是先用 LangChain 快速验证业务逻辑再用 LangGraph 做生产级流程控制。两者不是替代关系而是工具链和编排层的关系。4. RAG 实战从文档到可问答知识库这一节写一段可以直接运行的 RAG 示例。环境建议用 Python 3.10 以上版本先创建虚拟环境并安装依赖。4.1 安装依赖python -m venv .venv # Windows .venv\Scripts\activate # macOS / Linux source .venv/bin/activate pip install langchain langchain-openai langchain-community chromadb如果需要本地模型部署可以参考 Ollama 方式安装本地大模型然后替换下面的模型实例。这里先以 OpenAI 兼容接口为例。4.2 完整 RAG 链路代码import os from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OpenAIEmbeddings from langchain_community.vectorstores import Chroma from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI # 通过环境变量注入 Key生产环境不要硬编码 os.environ[OPENAI_API_KEY] sk-xxxx # 1. 加载文档 loader TextLoader(docs/agent_notes.md, encodingutf-8) documents loader.load() # 2. 文本切分 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) chunks splitter.split_documents(documents) # 3. 向量化并存储到 Chroma embeddings OpenAIEmbeddings() vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db ) # 4. 检索增强生成 qa RetrievalQA.from_chain_type( llmChatOpenAI(modelgpt-4o-mini, temperature0), retrievervectorstore.as_retriever(search_kwargs{k: 4}) ) answer qa.invoke(请总结文档中提到的 Agent 开发关键点) print(answer[result])这段代码完成了四条核心操作加载文档、把长文本切成块、向量化入库、检索后生成回答。chunk_size控制切分长度chunk_overlap控制相邻块之间的重叠字符数重叠部分可以缓解切分把语义割裂的问题。执行之后程序会在当前目录生成chroma_db目录里面是向量索引文件。第二次运行时可以直接加载已有索引不需要每次都重新向量化。4.3 检索质量怎么调RAG 效果不好时优先检查三个位置切分、向量模型、重排。切分方面chunk_size太小会导致语义不完整太大则检索精度降低还可能超出模型上下文长度。一般先按 300 到 800 字符测试再根据文档类型调整。代码文档和自然语言文档适合的切分方式不同这也是实战中常踩的坑。向量模型方面不同 Embedding 模型对中文和专业领域效果差异明显。常见开源模型有 BGE、M3E 等具体选择需要按自己数据实测。API 类 Embedding 服务的好处是稳定本地部署则要关注显存和内存占用具体数字要以实际环境为准。重排方面RAG 链路可以加一层 Rerank先用向量检索召回 10 条候选再用重排模型精排取前 3 条。这样能明显提升答案质量代价是增加一次模型推理耗时。5. Agent 实战让模型自动调用工具RAG 解决的是“让模型知道更多”Agent 解决的是“让模型能做事”。Agent 的核心机制是 ReAct推理Reason 行动Act。模型先分析当前任务需要什么信息然后决定调用哪个工具拿到结果后再推理下一步。5.1 先定义一个工具from langchain.agents import create_openai_tools_agent, AgentExecutor from langchain.tools import tool from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate # 定义工具根据城市查询天气 tool def get_weather(city: str) - str: 根据城市名查询当前天气例如北京、上海。 # 这里可以换成真实天气 API 的调用逻辑 return f{city} 的天气晴25℃适合外出测试工具定义最关键的是函数签名和 docstring。模型会根据函数名、参数说明、docstring 推断这个工具是干什么的、应该传入什么参数。描述写得模糊模型就可能传错参数或者不会主动调用。5.2 创建 Agent 并执行llm ChatOpenAI(modelgpt-4o-mini, temperature0) prompt ChatPromptTemplate.from_messages([ (system, 你是一个擅于使用工具的助手。), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 创建 Agent agent create_openai_tools_agent(llm, [get_weather], prompt) executor AgentExecutor(agentagent, tools[get_weather], verboseTrue) # 执行任务 result executor.invoke({input: 帮我查询一下北京的天气}) print(result[output])注意prompt里必须有agent_scratchpad占位符这是 Agent 中间推理过程的临时存储区域。如果不加Agent 无法保存“已经调用过哪些工具、得到了什么结果”的状态信息。执行executor.invoke后模型会先判断“查询天气需要调用 get_weather 工具”生成工具调用参数执行工具再把结果放回上下文最后生成回答。verboseTrue会在控制台打印整个推理过程调试时建议打开。5.3 Agent 实战中要注意什么工具调用最怕死循环。模型可能反复调用同一个工具而不收敛或者工具报错后不知道停止。工程化时至少要加两个保护最大迭代次数限制和超时控制。在AgentExecutor里可以通过max_iterations参数限制最多执行轮数。工具本身的异常处理也很重要。工具内部要做 try-except把错误信息返回给模型让模型知道“这个调用失败了你需要换一种方式”而不是直接抛异常中断整个 Agent。真实业务里工具返回的应该是模型能读懂的文本而不是程序堆栈。6. 进阶Agentic RAG 与 LangGraph 编排把 RAG 和 Agent 组合起来就是目前讨论度很高的 Agentic RAG。6.1 从 RAG 到 Agentic RAG传统 RAG 是固定流程用户问 - 检索 - 生成。问题复杂时一次检索往往不够。Agentic RAG 的思路是让模型决定是否需要检索、需要检索几次、是否需要追问用户。比如用户问“对比 A 和 B 两份文档中的方案”Agent 先检索 A 相关内容再检索 B 相关内容还可能根据第一次结果调整第二次的检索词最后综合生成回答。这种“检索 - 判断 - 再检索”的能力是普通 RAG 链路难以实现的但用 LangGraph 表达起来很自然。6.2 LangGraph 工作流编排示例LangGraph 的核心概念是节点、边、状态。节点是处理逻辑边是流转关系状态是节点之间传递的数据。from typing import TypedDict from langgraph.graph import StateGraph, END class State(TypedDict): question: str context: str answer: str # 节点检索知识库 def retrieve_node(state: State): # 这里接入已有的检索逻辑返回结果写入 state[context] state[context] f根据问题检索到的内容{state[question]} return state # 节点生成回答 def generate_node(state: State): state[answer] f基于检索内容生成的回答{state[context]} return state # 构建图 graph StateGraph(State) graph.add_node(retrieve, retrieve_node) graph.add_node(generate, generate_node) graph.set_entry_point(retrieve) graph.add_edge(retrieve, generate) graph.add_edge(generate, END) app graph.compile() result app.invoke({question: 什么是 Agentic RAG}) print(result[answer])这个示例是简化版但结构清晰StateGraph接收状态类型add_node注册节点set_entry_point指定入口add_edge定义流转关系compile生成可执行实例。实际项目中可以在retrieve和generate之间加条件判断比如判断检索结果是否足够、是否需要再次检索。LangGraph 不同大版本的 API 有一定差异具体以当前安装版本为准。6.3 多 Agent 协作思路更复杂一点的是多 Agent 协作。通常有三种方式主管 Agent 模式一个 Agent 负责拆解任务并派发给子 Agent子 Agent 返回结果后汇总路由 Agent 模式根据用户意图把请求分发到不同的专用 Agent辩论模式多个 Agent 从不同视角分析问题由汇总 Agent 综合多方观点。多 Agent 的思路是好的但不要为了多而多。每个 Agent 增加一层模型推理会引入额外的延迟、成本和错误概率。多数业务场景下单 Agent 工具调用已经够用如果任务确实有清晰的职责边界再拆成多 Agent。7. 50 个实战项目怎么练、怎么写进简历标题明确提到 50 个实战项目初中高级全包含。没有拿到完整课表的情况下可以从分层思路来把握这套体系的项目结构。7.1 初级项目跑通单点能力初级项目围绕“一个模型 一个能力”展开比如文档问答、个人知识库搭建、简单的 Prompt 优化工具、FAQ 客服机器人。这类项目的作用是让你把 RAG 链路跑通知道文档加载、切分、向量化、检索、生成每一步在做什么。练初级项目的最低标准是不看教程能自己从零写出一套文档问答 Demo并且说清楚每个参数调整后对结果的影响。达不到这个标准不要急着进中级。7.2 中级项目加入 Agent 和工具调用中级项目开始需要模型自主决策比如带联网搜索的问答机器人、自动生成并发送日报的 Agent、通过调用多个 API 完成数据查询和汇总的助手。这类项目锻炼的是工具定义、Agent 调试、错误处理、参数调优。中级项目会踩到大量实战坑工具描述不清导致模型不调用、Tool call 参数格式错误、模型陷入死循环、上下文过长导致响应超时。把这些坑逐个解决掉就是实打实的工程经验。7.3 高级项目LangGraph 编排和多 Agent 协作高级项目聚焦于复杂工作流比如企业级知识库多级检索系统、自动生成报告并分发的 Agent、多 Agent 协作完成市场调研、基于 LangGraph 构建的人工审核流程。高级项目写进简历时的竞争力不在于用到的模型多先进而在于你有没有处理长任务、状态管理、异常恢复的能力有没有设计多 Agent 协作架构的实际经验有没有把效果量化出来。7.4 简历怎么写简历上建议用 STAR 结构背景、任务、行动、结果。不要只写“负责开发某某系统”要写清楚用什么框架、解决了什么问题、达到什么效果。一个示例条目项目背景内部文档分散人工检索耗时严重。技术方案基于 LangChain Chroma 构建 RAG 知识库支持 500 篇文档的向量化检索接入 Agent 工具调用实现自动文档问答与摘要。实际结果将常见问题检索时间从人工平均 10 分钟缩短到 10 秒内回答准确率显著提升。要注意简历项目可以练手但不能虚构上线数据和效果。真实做过什么就写什么把运行逻辑和踩坑细节讲清楚面试官问两轮就能听出真假。7.5 面试准备方向这类项目面试时高频考点通常集中在以下几个方向方向高频问题RAG为什么要切分文档chunk_size 怎么定向量检索和关键词检索的区别Embedding 模型怎么选RAG 怎么加 Rerank如何评估 RAG 效果AgentReAct 是什么工具调用协议怎么定义Agent 死循环怎么处理多个工具冲突时如何让模型决策Memory 管理方式LangChain / LangGraphChain 和 Graph 的区别什么场景适合用 LangGraph如何保存中间状态节点异常如何处理流程超时和重试设计面试前建议把简历里涉及的项目代码重新跑一遍重点调试其中最容易出问题的环节。面试问“你遇到过什么问题、怎么排查”比问“你做了什么功能”更能检验实战水平。8. 本地环境准备、工具选型与性能观察8.1 基础环境无论做 RAG 还是 Agent建议先准备一套干净的环境。推荐 Python 3.10 以上版本使用虚拟环境隔离依赖避免多个项目之间冲突。安装命令可以参考第 4 节。IDE 方面PyCharm 或 VS Code 都可以关键是能打断点调试工具调用逻辑。8.2 模型与向量库选型模型层有两条路线API 调用和本地部署。API 调用门槛低、稳定适合快速验证本地部署适合数据敏感或离线场景但需要准备对应模型运行资源具体显存占用要按实际模型版本测试。Embedding 模型可以选 API 服务也可以选开源模型本地部署。向量库层面Chroma 轻量、适合本地学习生产环境可以换 Milvus、PGVector 等支持更大数据量但架构复杂度更高。前期学习阶段先用 Chroma 把链路跑通最重要。8.3 性能观察方法性能观察分两个维度。API 调用维度关注响应时延、Token 消耗、失败率和重试次数。本地模型维度关注显存占用、内存占用、首次响应时间、并发请求吞吐量这些数据建议用监控工具记录不要凭感觉判断。RAG 链路中性能瓶颈通常集中在三个位置向量存储检索耗时、Rerank 模型推理耗时、大模型生成耗时。调优时可以分别计时定位到底是哪一段拖慢了整体响应。批量任务场景下要设计好并发控制避免同时打满 API 配额或本地 GPU 显存进而导致任务失败。9. 常见问题与排查清单问题现象可能原因排查方式解决方案安装依赖时报版本冲突不同包要求的 langchain 版本不一致查看完整报错堆栈检查已安装版本用虚拟环境重新安装按项目要求锁定版本Embedding 模型下载慢或失败网络不稳定或资源较大观察下载进度确认网络连接配置镜像源或提前下载到本机缓存向量库目录无法持久化路径权限不足或目录冲突检查路径是否存在、是否有写权限更换存储目录或删除旧索引重新生成检索结果和问题不相关切分不合理、Embedding 模型不适配打印检索返回的文本片段检查 chunk 内容调整 chunk_size更换 Embedding 模型增加 RerankAgent 反复调用同一个工具Prompt 误导或工具描述不清晰打开 verbose 日志观察推理中间过程精简工具描述增加最大迭代次数限制工具返回结果模型无法理解工具返回了堆栈或非结构化数据检查工具异常分支在工具内部做 try-except返回干净的文本错误信息API 调用超时或者被限流请求频率过高或上下文过长查看接口返回状态码和耗时增加重试、降低并发压缩 Prompt 长度LangGraph 执行时节点顺序不对边配置错误或状态字段绑定不正确打印每次 state 变化检查 add_edge 和 set_entry_point 配置中文场景效果明显变差Embedding 和 LLM 对中文支持不足对比不同模型在同一批数据上的效果换用中文表现更好的开源模型做小规模评估排查问题的核心思路只有一条先把链路拆开一段一段定位。RAG 问题就先单独测检索环节看返回的文本片段是否相关Agent 问题就打开 verbose 日志看模型做了哪些决策、卡在哪一步性能问题就计时每个节点找到真正的耗时瓶颈。10. 总结与下一步行动这套 Agent 实战体系最有价值的地方是把 RAG、Agent、LangChain、LangGraph 串成了一条完整的学习路径并且用 50 个实战项目做了初中高级分层。它解决的不是“某个工具怎么用”而是“一个完整的 AI 应用项目怎么做出来”。建议按这个顺序行动先跑通第 4 节的 RAG 示例确认文档问答链路没问题再跑通第 5 节的 Agent 工具调用示例重点理解工具描述和推理过程然后把两者结合做一个“能检索知识库并调用工具的 Agent”最后用 LangGraph 把流程画成图加上条件和循环。每一步都要动手改代码、调参数、记录问题这四个步骤做完你已经具备实际的 Agent 开发能力。最容易踩的坑有三个一是上来就调复杂模型和服务忽略了切分和检索质量的调试二是不看 Agent 的 verbose 日志凭感觉猜问题三是把简历项目写得很大但被问到细节时答不上来。建议项目记录做到“每一步为什么这么做、出现问题怎么定位、效果怎么评估”都可以讲清楚。下一步可以往这些方向继续扩展把 RAG 链路加上评估体系量化检索效果把单 Agent 升级成多 Agent 协作把本地部署跑通做数据合规的私有化方案或者把 LangGraph 工作流接入真实业务系统。这套学习路径建议收藏备用。它的核心不是让你背概念而是逼着你动手写出一个能真正运行的 AI 应用。跑通 10 个项目和跑通 50 个项目的差别会直接体现在你对工程细节的理解上。