ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

LangChain 1.3入门:从核心抽象到RAG与Agent实战指南

LangChain 1.3入门:从核心抽象到RAG与Agent实战指南 如果你关注过“LangChain 到底该怎么学”这类问题大概率会刷到两种极端声音一种说 LangChain 是“胶水代码”底层就是封装各种大模型 API直接调 OpenAI SDK 就行另一种说 LangChain 生态太复杂版本更新快上午刚学会的写法下午就标记 deprecated根本追不动。这两种说法都有道理但也都不完整。真正的问题是很多入门教程还停留在 0.x 时代的写法而 LangChain 1.x 之后官方对架构做了明显收敛。如果你现在打开那些旧教程会发现照着敲都跑不通。不是代码的问题是版本和思路都变了。这篇教程我会站在 2026 年初的时间点围绕 LangChain 1.3 的现状带你从头梳理 LangChain 的核心抽象拆解一条最小可跑的入门路径然后逐步进入代码实战。你不需要提前啃完那本几百页的官方文档只要跟住这篇文章的节奏把环境配好、把例子跑通、把 Agent 和 RAG 的骨架搭出来就可以回到自己的项目里开始动手了。全文会用“理解概念 写代码验证 踩坑复盘”的方式展开。我会尽量把每个步骤写得可以直接照做也把常见报错和解决思路单独拆成一章方便你后面当手册查。1. 学 LangChain 之前先想清楚你要解决什么问题很多人在 LangChain 上花了很多时间却没想明白它到底解决什么问题所以学着学着就变成“背 API”。先给一个判断如果你的需求只是“调用大模型聊天”那直接用 OpenAI SDK、Anthropic SDK 就够了确实没有必要引入 LangChain。但如果你要做的是一套真实业务系统代码里会同时出现“对话上下文”“知识库检索”“定时任务”“多个模型切换”“用户权限”这些要素LangChain 的价值就出来了。它真正降低的不是“调大模型”的成本而是“把大模型组装进业务系统”的成本。举个例子没有 LangChain 的时候你做一个简单的知识库问答需要自己写文档切分逻辑Embedding 调用与缓存向量数据库的写入和查询Prompt 模板拼接大模型调用上下文管理。这六个环节每一个单独看不难但拼在一起你就会发现代码边界变得很模糊。今天要把 OpenAI 换成国产模型明天要把向量库从 FAISS 换成 Milvus后天要在回答前加一个意图识别每改一处都要动到周围的代码。LangChain 做的事就是把这六个环节抽象成了相对固定的组件接口然后把“组装”的动作标准化。你不需要在每个项目里重新造一遍轮子而是把不同的轮子按同一套接口装上去。所以这篇文章真正要解决的是让你在半天之内建立 LangChain 1.3 的完整心智模型并且跑通一个包含模型调用、Prompt 管理、记忆、RAG 检索、Agent 工具调用的小项目。学完之后你再去看官方文档会明显感觉那些抽象概念都有了落点。适合读这篇教程的读者写过 Python但是第一次接触 LangChain之前看过 0.x 教程发现最新的 1.3 写法对不上已经用 LangChain 写过一个 Demo但对 Agent、Tool、Retriever 之间的边界不清晰准备把 LangChain 运用在自己的毕业设计、内部工具或公司项目里。2. LangChain 的核心抽象把“模型能力”变成“工程组件”LangChain 之所以让很多新手觉得难是因为它不是一个“一个软件包调用完事”的工具而是一套带着接口约定的编程框架。你只有理解了它设计了哪些抽象才能知道该往哪个文件里写什么逻辑。2.1 六大核心抽象LangChain 1.3 的整体设计依然围绕下面几个核心抽象展开抽象解决什么问题一句话理解ChatModel统一不同模型的调用方式不管后端是 OpenAI、Claude 还是本地模型代码里都是llm.invoke()PromptTemplate管理输入到模型之间的文本模板让动态参数与固定指令分离OutputParser把模型输出转成结构化数据从自由文本里拿到 JSON、列表等Memory维护多轮对话上下文记住前面说过什么Retriever从外部知识源中找到相关内容把 RAG 的“检索”动作抽象出来Tool / Agent让模型能调用外部工具并规划步骤模型不再只是“聊天”而是能执行动作这六个抽象并不需要一次性全学会。第一天的目标先把 ChatModel、PromptTemplate、OutputParser 组合起来跑通。2.2 1.3 版本的设计趋势从 1.x 系列的整体变化看LangChain 官方一直在做几件事把 langchain 核心包里的能力拆分得越来越干净将模型实现、向量库实现逐步移到独立的集成包例如 langchain-openai、langchain-community同时将需要复杂状态流转的功能引导到 LangGraph 去做LangChain 本身更聚焦在组件和链路的组合上。所以如果你看到网上有人说 LangChain 项目分成了很多包那不是坏话而是架构演进的必然结果。你在 1.3 里写的代码通常会同时依赖多个包比如langchain langchain-core langchain-openai langchain-community langchain-text-splitters langchain-experimental不用被这些包吓到。大多数场景下你只需要langchain、一个模型集成包、一个向量库集成包最多再加一个文本切分包就够了。2.3 与 LangGraph 的关系很多新手还有一个疑问LangChain 和 LangGraph 到底有什么区别从定位上看可以把 LangChain 理解为组件库把 LangGraph 理解为状态编排引擎。LangGraph 解决的是更复杂的流程控制问题如果 Agent 需要执行多步推理、失败重试、人工确认、条件跳转LangChain 传统的Chain写法会变得笨重而 LangGraph 用图结构来表达流程每个节点是一个函数每条边是状态跳转条件。在入门阶段你不必急着上 LangGraph。先能跑通“链式调用”再理解“为什么简单链不够用”最后再进入 LangGraph路径会顺畅得多。2.4 一个必须纠正的误区LangChain 不是大模型还有一个老生常谈的误区LangChain 本身不提供大模型也没有内置大模型能力。它不负责训练模型也基本不负责推理优化。它更接近 JDBC 在 Java 数据库生态里的角色——定义统一接口、管理驱动、简化调用。所以你在学习 LangChain 时前面一定要先准备好一个可用的模型要么是 OpenAI/Anthropic/国产云厂商的 API Key要么是一个本地模型服务比如 Ollama。3. 环境准备Python 虚拟环境与模型接入在动手写代码之前先把环境整理干净。这一步看起来琐碎但能帮你省掉后面大量“为什么我这报错、别人不报错”的排查时间。3.1 安装 Python 与创建虚拟环境LangChain 是基于 Python 的框架建议使用 Python 3.10 及以上版本。如果你本地同时有多个 Python 版本强烈建议基于虚拟环境运行今天的示例避免包冲突污染全局环境。这里以venv为例先创建一个项目目录并激活虚拟环境mkdir langchain-demo cd langchain-demo python3 -m venv .venv source .venv/bin/activateWindows 上激活命令稍有不同.venv\Scripts\activate激活之后你的命令行提示符前会出现(.venv)前缀说明已经在虚拟环境内部了。3.2 安装 LangChain 相关包接下来安装核心依赖。你不需要一次性装完整套 LangChain 全家桶按需安装即可。pip install -U langchain pip install -U langchain-core pip install -U langchain-openai pip install -U langchain-community pip install -U langchain-text-splitters pip install -U python-dotenv其中langchain-openai不只是支持 OpenAI也兼容一切以 OpenAI 接口协议为基础的服务常见的国产云厂商模型大多支持这种方式接入后面会演示。langchain-community是社区维护的集成包向量库、Embedding 模型、浏览器工具等都在这里。python-dotenv用来读取.env文件管理 API Key。版本说明这里的版本号请以你实际执行时安装到的最新版本为准。LangChain 升级比较频繁但今天用的这些 API 在 1.x 系列里属于核心稳定接口就算有小幅度调整调用思路也不会变。3.3 配置大模型 API Key为了保证代码里不硬编码密钥建议在项目根目录创建.env文件# langchain-demo/.env OPENAI_API_KEYsk-your-key-here然后加载它from dotenv import load_dotenv load_dotenv()如果你使用的大模型服务不是 OpenAI而是其他兼容 OpenAI 接口的服务比如 DeepSeek、Moonshot、智谱、Ollama 本地模型等可以这样配置from langchain_openai import ChatOpenAI llm ChatOpenAI( model你的模型名称, api_key你的API Key, base_urlhttps://你的服务地址/v1, )从 1.x 的设计来看ChatOpenAI是面向 OpenAI 兼容协议的通用类因此这个写法可以覆盖很多场景。本地 Ollama 服务跑起来后把base_url指向http://localhost:11434/v1就可以把本地模型接进来这对学习调试很友好因为不会有网络延迟和费用压力。3.4 验证模型连接无论你使用哪个模型服务先跑一个最小调用from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o-mini) response llm.invoke(用一句话解释 Redis 为什么快) print(response.content)看到正常输出说明模型通道已经打通。后面的所有示例都会基于这个最小调用逐步扩展。4. 从 ChatModel 到 Chain手写你的第一个 LangChain 应用这一节我们不看复杂架构只做一件事从最基础的模型调用出发把 LangChain 中“模板变量拼接、模型调用、输出解析”这三个基本动作连起来。4.1 用 PromptTemplate 管理提示词直接在代码里拼接用户输入有很多坏处指令和业务参数混杂、模板无法复用、prompt 迭代时需要改代码。LangChain 的做法是使用PromptTemplate把模板抽出来。from langchain_core.prompts import PromptTemplate prompt_template PromptTemplate.from_template( 你是资深后端工程师。请针对下面的问题给出技术选型建议。\n 问题{question}\n 要求用 300 字以内回答并给出推荐理由。 )模板中的{question}是占位符调用时传入参数即可。4.2 用 OutputParser 拿到结构化结果大模型输出的是自由文本。如果你需要的是一个 JSON、一个列表或者只想要回答正文最稳妥的方式是让 OutputParser 负责抽取和转换。下面我们定义一个最简单的解析器把模型回答按行剥出来from langchain_core.output_parsers import StrOutputParser output_parser StrOutputParser()StrOutputParser的作用是拿到模型输出的纯文本内容。如果模型本身返回的是带额外结构的数据这个解析器也会尽量把 content 字段提取出来方便后续使用。4.3 用管道符组合成 ChainLangChain 1.x 里最直观的链式写法是|类似 Unix 管道。整个链路可以理解成输入参数 → 模板加工 → 模型调用 → 结果解析。chain prompt_template | llm | output_parser result chain.invoke({question: 做内部知识库问答Elasticsearch 和向量数据库怎么选}) print(result)这段代码虽然只有三行但它已经是一个完整的 LangChain 应用骨架输入一个业务问题它先套用系统提示词模板然后交给模型回答最后解析成纯文本输出。你可以把它保存为chat_demo.py然后运行python chat_demo.py如果输出正常恭喜你LangChain 的应用链路已经跑通了。5. 多轮对话与记忆不只是把历史消息放进数组从单个问答到多轮对话是新手的第一个台阶。很多人会想多轮对话不就是把之前的内容攒在一个列表里下次一起发给模型吗这个思路方向对但工程上还要处理两件事上下文无限累积会迅速超出模型上下文窗口不同历史消息需要不同的压缩和摘要策略。5.1 内置记忆组件LangChain 在langchain_core.messages里定义了HumanMessage、AIMessage、SystemMessage三种基础消息类型。最简单的多轮对话就是维护一个消息列表手动追加用户消息和模型回复。from langchain_core.messages import HumanMessage, SystemMessage, AIMessage messages [ SystemMessage(content你是一个只会用中文回答的运维助手。), HumanMessage(content如何查看 Linux 系统负载), AIMessage(content可以用 uptime 命令查看平均负载。), HumanMessage(content那 1 分钟平均负载超过 CPU 核数说明什么), ] response llm.invoke(messages) print(response.content)这种方式适合演示。在实际项目中你需要把历史消息持久化到 Redis、数据库或其他存储里同时控制消息窗口大小防止过长。5.2 控制上下文长度更工程化的做法有两种截断窗口和摘要压缩。截断窗口就是只保留最近 N 条消息摘要压缩是把早期的消息总结成一段摘要然后与最近消息一起发送。在 LangChain 中你可以借用一些内存相关的类来管理会话也可以在项目里自己实现。对于初学者我建议先自己实现一个简单的会话管理类因为你能更清楚地知道 LangChain 背后到底做了什么。一个简单的控制帧示例class SimpleMemory: def __init__(self, max_messages10): self.history [] self.max_messages max_messages def add(self, role, content): self.history.append({role: role, content: content}) if len(self.history) self.max_messages: self.history self.history[-self.max_messages:] def to_messages(self): result [] for item in self.history: if item[role] user: result.append(HumanMessage(contentitem[content])) else: result.append(AIMessage(contentitem[content])) return result然后在每次调用模型前用to_messages()得到当前轮次需要发送的消息列表。这个实现虽然简单但已经能解释清楚“记忆到底是什么”——记忆本质上是“存储过去交互状态 按策略裁剪后重新注入模型上下文”。6. RAG 实战让 LangChain 回答私有知识库问题如果你只学一个 LangChain 实战场景我建议把时间花在 RAG检索增强生成上。因为 RAG 是当前企业落地大模型最高频的模式而且 LangChain 在这个场景里的抽象最成熟。6.1 RAG 的整体流程RAG 可以分成两个阶段索引阶段建库文档加载读取 PDF、Markdown、TXT 等文本切分把长文档切分成固定长度的 chunk向量化用 Embedding 模型把 chunk 转成向量存储把向量写入向量数据库记录文本内容和元数据。查询阶段问答用户输入问题对问题做向量化在向量库中检索 Top-K 相近片段把提示词、用户问题、检索片段拼在一起交给大模型生成答案。对比传统关键字搜索RAG 的优势在于语义检索哪怕问题表述与原文不完全一致也能找到语义接近的内容。6.2 安装依赖在本小节我们用本地 FAISS 作为向量库用 HuggingFace Embeddings 作为向量化模型。先安装依赖pip install faiss-cpu pip install sentence-transformers如果你网络受限也可以用 OpenAI 的文本向量接口OpenAIEmbeddings代码逻辑几乎一样。6.3 构建索引加载、切分、向量化、入库假设我们有一个简单的文档docs/knowledge.txt内容是公司内部产品的 FAQ。from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS # 1. 加载文档 loader TextLoader(docs/knowledge.txt, encodingutf-8) documents loader.load() # 2. 切分文档 text_splitter RecursiveCharacterTextSplitter( chunk_size200, chunk_overlap20, ) chunks text_splitter.split_documents(documents) # 3. 初始化 Embedding 模型 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) # 4. 构建向量库并保存 vectorstore FAISS.from_documents(chunks, embeddings) vectorstore.save_local(faiss_index) print(f成功切分并索引 {len(chunks)} 个片段)这里真正容易出错的地方是chunk_size的选择。如果 chunk 太小语义信息不完整如果 chunk 太大检索到的片段噪音太多。200 到 500 字是常见起步值具体要看你的业务文档类型。6.4 检索增强问答索引构建好之后就可以把检索链路接入前面的 Chain。from langchain_community.vectorstores import FAISS from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_core.prompts import PromptTemplate from langchain_openai import ChatOpenAI from langchain_core.output_parsers import StrOutputParser embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectorstore FAISS.load_local(faiss_index, embeddings, allow_dangerous_deserializationTrue) retriever vectorstore.as_retriever(search_kwargs{k: 3}) prompt PromptTemplate.from_template( 你是内部知识库助手。请只根据下面检索到的资料回答问题。\n 如果资料中没有相关内容请直接回答知识库中未找到相关信息。\n\n 检索资料\n{context}\n\n 用户问题{question}\n ) def format_docs(docs): return \n\n.join(doc.page_content for doc in docs) def rag_answer(question): docs retriever.get_relevant_documents(question) context format_docs(docs) chain prompt | llm | StrOutputParser() return chain.invoke({context: context, question: question}) print(rag_answer(我们的产品支持单点登录吗))这里需要注意一个小坑在 LangChain 1.x 中部分 retriever 相关代码仍可能出现在langchain_community或langchain_core中不同版本的 API 名称会有差异。如果你发现get_relevant_documents被标记即将弃用可以改用invoke方式。核心思想是相通的让问题先生成检索条件再拿到相关文档。6.5 验证检索质量RAG 的系统质量取决于两个点检索精度和生成指令约束。你可以做一次小实验把k值从 3 调整到 5或者修改chunk_size对比答案质量变化。在真实项目中建议把用户问题和检索文档单独记录到日志里方便分析是“没检索到”还是“模型答偏了”。7. Agent 与工具调用模型开始“动手干活”如果 RAG 是让模型“知道得更多”Agent 则是让模型“做得更多”。在 LangChain 中你可以给模型注册一些工具让它根据用户需求决定调用哪个工具、传什么参数然后根据工具返回结果继续生成最终回复。7.1 为什么要用工具调用假设用户问“北京现在适合穿短袖吗”模型如果只有聊天能力只能根据训练数据瞎猜。如果给模型注册一个天气查询工具它就能先调用工具拿到实时天气再根据温度数据给出衣服建议。这就是 Agent 的价值把模型的推理规划能力和外部工具的执行能力结合起来。7.2 用 tool 装饰器注册工具LangChain 提供了一个非常简洁的方式注册工具。你只需要写一个普通函数然后在函数上加tool装饰器函数名和 docstring 会自动成为模型理解工具用途的依据。from langchain_core.tools import tool tool def get_current_weather(city: str) - str: 查询指定城市的当前天气返回温度与天气状况。 Args: city: 城市名称例如北京、上海。 # 真实项目中这里可以调用天气 API # 这里为了演示返回模拟数据 return f{city}晴26℃docstring 非常关键。模型看不到你的函数实现它只能靠函数名、参数描述和 docstring 来判断“这个工具是干嘛的、何时该用”。7.3 创建 Agent 并执行任务from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate llm ChatOpenAI(modelgpt-4o-mini, temperature0) tools [get_current_weather] prompt ChatPromptTemplate.from_messages([ (system, 你是一个智能助手。请根据用户问题合理使用工具。), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) result agent_executor.invoke({input: 北京现在天气怎么样适合穿短袖吗}) print(result[output])这里用到了agent_scratchpad占位符它的作用是保存 Agent 在执行过程中的中间思考记录和工具调用结果。这是 Agent 与普通 Chain 最大的区别它不是一个单次前向计算而是一个循环过程直到模型认为自己拿到了足够的信息。7.4 Agent 的任务规划能力从哪来很多初学者会问Agent 的任务规划能力是怎么实现的说清楚这一点LangChain 的 Agent 机制就没什么神秘感了。核心机制是“模型先决定要调用哪个工具和参数 → 系统执行工具 → 把结果作为消息返回给模型 → 模型继续推理直到给出最终答案”。这依赖两个前提模型本身经过训练具备在对话中生成结构化工具调用指令的能力即 function callingLangChain 负责把模型输出的工具调用指令解析出来执行对应 Python 函数再把结果拼装回上下文。所以Agent 的“智能规划”本质上是模型逻辑推理能力与外部工具执行循环的组合不是 LangChain 内置了什么天顶星算法。LangChain 的贡献在于把循环和消息拼接标准化了。关于“Agent 可以用不同范式吗”答案是肯定的。LangChain/LangGraph 生态支持多种 agent 范式从简单的 ReAct 风格到 tool-calling 风格再到 Graph 编排的复杂多智能体。对于新手来说先掌握上述 tool-calling Agent 就足够迈入门槛了不要一上来就背 Schemas。8. 常见问题与排查方法很多朋友在跑 LangChain 时报错信息五花八门但底层的成因其实很集中。下面是几个高频问题建议先保存下来遇到报错时对照排查。问题现象可能原因排查方式解决方案ModuleNotFoundError: No module named langchain_openai缺少对应集成包pip list 确认已安装包安装langchain-openai调用模型一直超时网络受限或模型服务不可达curl 测试模型接口地址检查代理和 API 地址或换用本地模型InvalidApiKey.env 未加载或 Key 失效打印 os.environ 检查 Key在代码入口执行load_dotenv()确认 .env 文件路径模型输出没有被解析成预期结构Prompt 指令不够明确单独打印模型原始输出在 Prompt 中明确输出格式或使用with_structured_outputFAISS 加载时报反序列化错误1.x 安全限制查看错误提示本地可信数据加载时可传入allow_dangerous_deserializationTrue生产环境不要加载不可信向量库文件Agent 没有调用工具就直接回答模型不支持 function calling 或高温随机降低 temperature换用支持工具调用的模型更新模型版本或换模型中文乱码文件编码问题检查源文件和终端编码统一使用 UTF-8 编码如果你遇到的是其他报错我建议的排查顺序是看完整 traceback不要只看最后一行确认你安装的包版本和教程示例之间的差异用最小代码复现把问题从 Chain 中逐步拆出来搜索错误信息时加上你的 LangChain 大版本号比如“LangChain 1.3”因为 0.x 的旧解法很可能已经不适用。9. 最佳实践与工程建议当示例代码可以在本地跑通之后真正拉开差距的是工程化细节。这里给出几条建议不空谈每条都对应一个常见事故。9.1 依赖与版本控制LangChain 的包拆分和升级频率很高因此团队项目里用requirements.txt或pyproject.toml锁版本非常必要。建议每次运行完pip install后立即导出pip freeze requirements.txt当队友或服务器上复现报错时这个文件是最快的排障锚点。9.2 配置管理不要把 Key 写进代码、提交到 Git。使用.env加.gitignore是底线。生产环境更推荐使用配置中心或环境变量注入。如果你的项目涉及多个模型服务建议做一个集中配置模块统一维护模型名、base_url、temperature、超时时间等参数避免在业务代码中散落魔法字符串。9.3 Prompt 也走版本管理Prompt 是模型行为的“代码”但它比普通代码更难测试。建议把项目里的 Prompt 模板放到独立目录比如prompts/并在模板顶部写清楚用途、适用模型、版本号。这样当线上 Prompt 被修改导致效果波动时你能快速回滚。# prompts/rag_chat.md ## 版本 v1.2 ## 用途 知识库问答系统的主提示词 ## 注意事项 只使用 context 中的内容禁止编造9.4 异常处理与超时控制大模型 API 的不稳定是常态不设置超时和重试的代码在生产环境很难存活。在调用模型时加入合理的超时参数并对限流、网络错误做好重试。llm ChatOpenAI( modelgpt-4o-mini, temperature0, timeout30, max_retries2, )注意重试要小心“幂等性”问题。如果业务逻辑在调用模型前已经扣了积分或发了通知重试可能造成重复操作。在涉及外部副作用的 Agent 工具中尤其要谨慎。9.5 日志与可观测性LangChain 应用是一个典型的多步骤流水线不记录中间数据排查问题时只能靠猜。建议至少记录用户输入检索命中的文档片段和得分Prompt 最终内容拼接后模型原始输出Agent 每一步调用了哪个工具、工具参数和返回结果耗时、token 消耗。这些日志是你优化 RAG 检索质量、评估 Agent 行为、分析成本的第一手数据。9.6 安全边界在大模型应用中最常见的两个安全风险是提示注入和工具滥用。所谓提示注入就是用户的输入里藏了“忽略之前所有指令”之类的引导试图覆盖你的系统提示词。应对办法是对用户输入做敏感词和异常模式检测在 Prompt 中明确“区分指令和用户数据”对 Agent 可调用的工具做白名单控制不要随意暴露文件删除、命令执行、网络支付等高危能力工具调用前增加人工确认或二次授权机制尤其在自动化执行场景中。9.7 成本控制LangChain 项目跑起来很容易但如果不加控制API 费用会超出预期。建议在开发环境用本地模型生产环境再用商业模型同时设置用量监控比如每日请求量、token 消耗超出阈值自动告警。9.8 别急着上 LangGraph很多朋友学会了简单 Chain 之后就想立刻学 LangGraph想把所有流程都图解化。我的建议是先把简单链和 Agent 用熟理解“循环”“状态”这些概念之后再进入 LangGraph。否则你会同时面临“组件不熟”和“图编排不熟”两个难题学习曲线会非常陡。10. 总结与后续学习方向这篇文章从 LangChain 1.3 的现状出发走完了一条从零到可运行的完整路径先理解了 ChatModel、PromptTemplate、OutputParser、Memory、Retriever、Tool/Agent 六大核心抽象然后配置好了模型接入环境跑通了第一个 Chain做了多轮对话与记忆管理完成了 RAG 知识库问答最后用一个天气工具演示了 Agent 的调用循环。现在你已经具备了自己动手搭建一个 LangChain 项目的基础能力。建议的下一步实践路径是先把你手头一个简单的业务场景比如“常见问题问答”“商品推荐”“代码审查助手”用本文的骨架实现一遍给自己设计一个包含两种工具的 Agent让它完成一个需要“查数据 总结”的任务再把检索环节里的chunk_size、k、Embedding 模型分别替换记录效果变化等这些链路都稳定之后再花时间研究 LangGraph把复杂状态流转迁移到图编排中。有一点需要提醒LangChain 的迭代速度决定了任何教程里的 API 写法都可能在未来版本中调整。但底层概念比如模型调用、模板、解析器、记忆、检索、工具调用、状态编排会长期稳定。你把概念和工程思路学会了API 变化只是查文档的事。所以与其焦虑版本更新不如把今天这套最小系统跑熟把它当成你继续深入 LangChain 生态的“锚点”。如果你在实操中卡在某个报错上欢迎在评论区带上完整错误栈和包版本信息我们一起把问题拆开看一看。
返回列表