如果2025年你要入局AI应用开发LangChain这个名字迟早会出现在你的搜索记录里。从我这边的情况看无论是做客服问答、文档解析还是给团队搭内部知识库LangChain几乎都是被提到的第一个框架。当然声量大也意味着争议大——有人说它是AI时代的Spring也有人抱怨版本更新太频繁、文档追不上代码。这些评价其实都对关键是你得先知道它到底是什么。如果你正站在入门门口犹豫想分清LangChain到底是什么、能干什么、该怎么学这一篇就是给你写的也是我这个学习笔记系列的起点。1. 为什么AI应用的开发突然人人都想先聊LangChain1.1 直接调API和真正做个应用之间隔了多远先抛一个我经常在交流群里看到的场景很多人看完大模型文档后觉得AI开发很简单——不就是构造prompt、调一次接口、把返回的文本展示出来吗确实写一段能跑通的聊天代码半小时就能搞定。可一旦真的要做成产品问题就从各个角落冒出来了而且一个比一个现实。你需要处理用户连续提问时的上下文。第一次提问把历史messages带上了第二次呢第三条呢对话超过五轮要不要截断要不要摘要不同的模型对格式要求还不一样。然后你又要处理输出的稳定性有时候模型回了一串Markdown你想提取里面的JSON去调下游系统结果它把注释也写进去了解析直接报错。再往后用户问的问题不只有文字可能问今天杭州天气怎么样你总不能让模型瞎编你需要在服务端接一个天气API把实时数据塞回提示词里让模型参考于是又出现该什么时候调用工具、调用哪个、参数怎么填的新问题。这还没把文档问答这种常见需求算进来。想把公司几万份PDF变成可检索的知识库你得做文档解析、文本切分、向量化、入库、相似度检索、再把检索结果和用户问题拼成新提示词……这些步骤如果都用最原始的HTTP请求去拼每个项目都要重复造一遍轮子只是换个模型、换份文档而已。这就是LangChain出现前AI应用开发者的真实状态模型能力很强但把模型嵌进一个完整业务流程里需要写大量与AI本身无关、又绕不开的胶水代码。更要命的是这些胶水代码没有技术含量却最容易出问题还无法复用换一个模型供应商就要翻一遍。于是大家开始想能不能把这些重复的事情框架化1.2 LangChain的出现逻辑不是多了一个工具是多了一个抽象层LangChain的核心价值我一句话总结它把大模型应用中那些高频重复的环节抽成了标准化的组件和接口让你不用每次从零搭。你不必再关心模型API的细节差异不用为每个新项目重新实现一套历史消息管理逻辑也不用在加载文档、切分、向量化、检索这条链路上反复造轮子框架把这些高频动作用统一的方式给你封装好你的精力可以放到业务流程设计上。你可以把LangChain理解为软件开发里的框架层。就像写Java Web服务时你不会再手动去处理HTTP报文、Servlet容器这些细节而是直接用Spring MVC的Controller、Service、Repository那套分层去组织业务写LangChain应用也一样模型调用、提示词模板、输出解析、记忆管理、检索管道这些杂事被抽象成一个个标准模块你只需要关注业务本身。这个抽象层的价值还有一个隐性好处——可替换性。你今天用的是A厂家的模型明天因为价格或效果想换成B厂家的在LangChain里通常只需要改一行模型类实例化的代码你今天想从OpenAI的向量接口换成开源的本地向量库底层数据访问接口也是统一的。这种换底座不动业务逻辑的能力在技术选型频繁变化的当前阶段比什么都值钱。当然这也带来了LangChain最被人诟病的一点为了兼容性学习成本上去了。你会发现它的类特别多概念特别多文档又经常更新甚至官方教程都可能写着写着就过时。我身边有不少人就是在这一步被劝退的。但反过来想正因为没人能确定明天市场主流模型是哪家一个能屏蔽底层差异的抽象层才是把应用做长久的战略选择。1.3 这套抽象到底值不值得学我的态度很明确值得学但别指望学完就能解决所有问题。值得学的原因是就算你最终不使用LangChain这套库它定义的思维模型仍然有很强的通用性——凡是做大模型应用你早晚都要面对模型接入、提示词管理、上下文、输出控制、工具调用、知识检索这些问题。LangChain把这些问题的解决方案做成了你可以直接观察和拆解的开源样例相当于别人已经把最佳实践摆在你面前。别指望的原因是LangChain本身不是银弹。它擅长搭流程但流程里每一步的质量比如提示词写得好不好、向量检索的召回率够不够仍然取决于你自己的领域经验和调优能力。框架能让你少写样板代码但不能替你解决业务问题。所以这一系列笔记的定位我不是打算让你把LangChain的每一个类都背下来而是带你走一遍它处理问题的思路先认识核心抽象再亲手搭一个最小可用闭环最后讨论框架选型和避坑。这一篇我们从最基础的认识开始。2. 不读官方文档也能懂的LangChain核心概念2.1 Models把各家大模型统一成同一个接口LangChain里最底层的抽象就是Model负责的是跟大模型对话这件事。不管底层是大厂的API还是本地跑的开源模型在LangChain里都通过统一的接口暴露给你。通常你会接触两类Model。一类是LLM以文本进、文本出为主的老一代模型接口适合简单的文本补全另一类是ChatModel面向聊天式对话设计的模型接口输入输出都是消息结构目前的主流模型基本都走这一套。实际开发时我们会用langchain-openai、langchain-anthropic、langchain-ollama这类第三方集成包来实例化具体的模型对象。你在业务代码里不用关心对方API的鉴权方式、请求格式只需要传模型名、温度和超时时间这些参数。这就像家里统一用国标插座不管是哪个牌子的电器插上就能用。这里有一个很多新手会忽略的点LangChain对模型做了统一封装但每个模型的能力边界并不一样。有的模型支持函数调用有的不支持有的上下文窗口长有的短。抽象层保证了接口一致但你不能假设所有模型能力也一致否则模型接进来之后功能反而悄悄消失了。这一点等到后面做Agent时会反复遇到。2.2 Prompts与Output Parsers提示词也可以被设计成组件很多初学者以为提示词Prompt就是一串写好的文字复制粘贴进代码就完了。但在LangChain里Prompt是头等公民是可以结构化复用的一块组件。LangChain里最常用的就是ChatPromptTemplate它允许你在提示词里留出变量槽位运行时再填充。比如你写一个翻译专家的提示词模板你是一个资深翻译。请把下面的{source_language}文本翻译成{target_language}只输出译文不要解释。这里面的{source_language}就是运行时从业务代码里注入的变量。这样做的好处是提示词和业务逻辑解耦产品想要调整语气、追加约束时只需要改模板不需要动程序逻辑团队里不是程序员的人也可以参与维护模板。提示词的另外一半是输出解析器 OutputParser。模型返回的是字符串但程序往往需要结构化数据比如JSON、枚举值、带格式的列表。OutputParser就是用来把模型输出的原始文本按照你定义的格式要求解析成Python对象。一旦解析失败框架还会触发重试机制让模型重新生成符合格式的输出。这个组件在写自动化流程时几乎是必备的后面动手写代码时你就能体会到它的价值。2.3 Chains把复杂任务拆成流水线Chains是LangChain里最核心的组合方式用来把多个步骤串成一个可执行的流水线。最简单的链是一条PromptTemplate - Model - OutputParser的路径。你把用户问题、提示词和输出格式接好调用链的一次invoke就完成了一整个提问-补全-解析流程代码层面不需要手动去串每一步。再复杂一点你可以用SequentialChain把多个链按顺序连接第一个链负责生成一份产品文案的方向和卖点第二个链拿到结果后继续扩写成完整文章最后再有一个链做格式润色。每一步的输入输出都是显式的你可以在任意环节插入人类审核、敏感词过滤、日志记录这类旁路逻辑。这种流水线思维我觉得是LangChain对开发者最大的心智贡献。它把一件模糊的让AI帮我写文章分解成了若干可测试、可替换、可单独优化的环节这正是工程化落地大模型应用的关键。2.4 Memory让对话记得住前文如果你写过聊天机器人一定遇到过模型每次都是失忆的问题。因为大模型本身是无状态的每次请求携带消息请求结束就遗忘。Memory组件就是解决这个状态的抽象。LangChain里提供了一系列Memory实现比如ConversationBufferMemory直接保存全部历史消息适合短对话ConversationSummaryMemory会把旧对话浓缩成摘要保存适合长对话还有基于向量检索的VectorStoreRetrieverMemory能从历史记录里只捞取跟当前问题相关的片段适合知识型问答。但我要提醒一句Memory虽然好用也是最容易踩坑的地方。不加节制地保存全部历史很快你的token消耗就会爆炸而自动摘要又可能丢掉关键细节。实际项目里我更倾向于自己控制历史消息的裁剪策略按角色、时间、窗口大小做分层管理。LangChain提供的是地基怎么装修还得看你的业务需求。2.5 Tools与Agents从问答走向行动如果说前面的组件还停留在让模型好好说话那么Tools和Agents就是让模型变成用得上的助手。Tools描述的是模型可以调用的外部能力比如查天气、查数据库、发邮件、计算数学题。在LangChain里你既可以使用官方预置的几十种工具也可以把一个普通Python函数用tool装饰器直接暴露给模型。函数名、参数说明、返回值会被自动整理成模型能读懂的工具描述模型通过Function Calling机制自主决定要不要调用某个工具、传什么参数。Agents则是调度这些工具的大脑。它不预设固定的执行顺序而是根据当前目标在思考-调用工具-观察结果-再思考的循环里动态决策。最经典的ReAct模式就是如此模型看了工具返回的结果决定下一步是继续调用别的工具还是把最终答案端给用户。我自己第一次跑通Agent的时候确实有一种它真的会自己想办法的感觉。比如让Agent回答明天杭州气温比今天高几度它会主动调天气查询工具取到两天数据后做减法再组织语言返回。这种体验纯靠提示词堆砌是做不到的。2.6 RAG相关组件给模型补上外部知识最后一组核心概念是围绕检索增强生成RAG的一组组件Document Loaders、Text Splitters、Vector Stores、Retrievers。它们合在一起解决一个问题大模型训练数据之外的内容比如公司内部文档、个人笔记怎么让模型也能知道。流程大约是先用Document Loader加载文档把PDF、网页、Markdown统一成结构化的Document对象再用Text Splitter按语义或长度切成小块接着用Embedding模型把每块文字向量化存入Vector Store用户提问时Retriever在向量库里做相似度检索把最相关的几段文字取出来连同问题一起拼进提示词最终由模型基于这些资料作答。这一整套在过去是典型的AI系统架构但LangChain把它们全部做成了统一的组件接口让一个小团队也能在一周之内搭出自己的知识问答系统。后面实战篇我会专门拆一个RAG示例这里先记住它是解决模型不知道你的私有知识这个问题的即可。3. 动手写第一个LangChain应用最小可用闭环3.1 环境准备与依赖安装的注意事项在动手之前先把环境踩平不然后面报错会很劝退。我建议使用Python 3.10及以上版本虚拟环境是必须的因为LangChain生态更新极快直接装在全局环境里很容易和别的项目冲突。创建好虚拟环境后安装这几个包pip install langchain langchain-openai python-dotenv这里解释一下为什么要安装几个不同的包。从0.1版本开始LangChain官方把核心库、各个模型厂商的集成、社区维护的组件拆分开发布这样做的目的是避免每次某个厂商的SDK更新都导致整个包的大版本升级。langchain是核心框架langchain-openai是OpenAI兼容接口的封装层。至于langchain-community里的各种第三方集成并不是必须的可以先不装等用到再装也不迟。接下来配置模型密钥。我以最常见的OpenAI兼容接口为例在项目根目录建一个.env文件OPENAI_API_KEYsk-xxxx然后在代码开头用dotenv把环境变量加载进来。如果你的模型服务是兼容OpenAI格式的本地服务或国内服务只需要把base_url指过去密钥用相应服务商提供的即可。这也是LangChain抽象层的好处接入方式几乎一致。3.2 第一个开发闭环模型加提示词加解析器先把最小闭环跑通。下面这段代码实现一个翻译小助手把用户输入的中文翻译成英文并且只输出翻译结果。from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser load_dotenv() # 1. 初始化模型 llm ChatOpenAI(modelgpt-4o-mini, temperature0) # 2. 定义提示词模板 prompt ChatPromptTemplate.from_template( 你是一个专业翻译。请把下面这句中文翻译成英文只输出译文{input_text} ) # 3. 把模型输出解析为纯文本 parser StrOutputParser() # 4. 用管道操作符组装成一条链 chain prompt | llm | parser result chain.invoke({input_text: 今天天气很好我们去公园散步吧。}) print(result)跑起来后你会得到一个干净利落的英文句子。这里值得解释一下prompt | llm | parser这个语法它是LangChain最经典的组合方式管道左侧的输出自动作为右侧的输入类似于Unix命令行里把上一个命令的结果传给下一个命令。chain.invoke()则触发整条链执行你只需要传入提示词模板里定义的变量字典。可能你会觉得这个Demo太简单但它已经把模板化提示词、模型调用、输出结构化三个最核心的动作跑通了后续再复杂的业务底层都是这样的链路在运作。3.3 加入记忆把单次问答变成多轮对话接下来我们给这个闭环加上对话记忆让它更像一个真正的聊天产品。LangChain 0.3版本推荐的做法是直接在模型调用时传入历史消息列表从langchain_core.messages里引入HumanMessage和AIMessage。from langchain_core.messages import HumanMessage, AIMessage chat_history [] chat_history.append(HumanMessage(content我的英文名是Alex中文名是阿乐)) chat_history.append(AIMessage(content好的阿乐很高兴认识你)) user_input 我叫什么名字 # 把历史消息和当前问题一起交给模型 messages chat_history [HumanMessage(contentuser_input)] response llm.invoke(messages) print(response.content)你会发现模型这次能正确回答出阿乐这个名字。因为历史消息被一起送进了上下文模型不是凭空猜的。很多刚开始学LangChain的人容易一头扎进各种Memory类的封装里其实对于80%的场景你手动维护一个chat_history列表就够用了后续要裁剪、要摘要都可以在这个列表上自己操作可控性反而更好。如果你确实想使用官方封装好的记忆组件也可以用ConversationBufferMemory但在新版LangChain里它更多是配合旧式Chain使用新代码我建议直接管理消息列表这既是官方推荐方向也更贴近未来LangChain的发展路径。等你的场景真的复杂到历史消息需要自动摘要、分层存储时再考虑引入专门的Memory组件也不迟。3.4 一个能查实时天气的Agent雏形最后一个Demo我们把前面的知识串起来让模型学会调用工具回答一个模型本身无法知道的问题——北京现在多少度from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langchain_core.messages import HumanMessage, ToolMessage tool def get_temperature(city: str) - str: 查询指定城市的实时气温。 # 真实项目中这里应该调用天气API这里用模拟数据演示 return f{city}当前气温26摄氏度。天气多云。 llm ChatOpenAI(modelgpt-4o-mini, temperature0) llm_with_tools llm.bind_tools([get_temperature]) def run_agent_with_tool(user_question: str): messages [HumanMessage(contentuser_question)] response llm_with_tools.invoke(messages) # 如果模型决定调用工具 if response.tool_calls: for call in response.tool_calls: function_name call[name] args call[args] if function_name get_temperature: result get_temperature.invoke(args[city]) messages.append(ToolMessage(contentresult, tool_call_idcall[id])) # 把工具结果交给模型生成最终答复 final_response llm_with_tools.invoke(messages) return final_response.content return response.content print(run_agent_with_tool(北京现在多少度))跑通这段代码你就看到了Agent最核心的运作逻辑模型不是装模作样地编答案而是真的去调用工具、拿到真实数据、再基于数据组织回答。整个过程用不了几行代码但背后是工具注册、函数调用、消息回填三个环节的无缝衔接。这也是我强烈建议初学者尽早跑通的一个Demo它会彻底改变你对AI应用到底能做什么的理解。4. LangChain、Dify、CrewAI怎么选三个框架的定位差异4.1 为什么这三个名字总是被放在一起现在只要打开各大平台搜agent框架LangChain、Dify、CrewAI这三个词几乎总是同时出现。很多人被绕晕了以为它们是同一个层面的竞品其实它们的定位差别非常大选错方向会很痛苦。我做了一张简易对比表帮你快速理解区别维度LangChainDifyCrewAI本质形态Python开发框架/SDK开源AI应用开发平台多智能体编排框架面向人群开发者、技术团队产品经理、运营、开发混合团队研究型开发者、Agent探索者使用方式写代码可视化拖拽少量代码写Python代码灵活性极高任何环节都可改中受平台组件限制高但主要聚焦在Agent分工上手门槛较高需要懂编程和AI概念较低非程序员也能搭出MVP中需要对Agent机制有理解适合场景深度定制业务、集成到现有系统快速搭建交付、内部工具、运营后台模拟多角色协作、复杂任务拆解这个表格只能帮你定位大方向接下来展开说各自的细节。4.2 LangChain和Dify一个是工具箱一个是流水线车间我经常用这个类比LangChain是给你一整套工具箱螺丝刀、扳手、电钻都有零件尺寸规范统一你可以用它们组装任何结构但你得自己看图、自己动手。Dify则是一条已经搭好的流水线车间数据接入、知识库、工作流、对话管理都是现成工位你只需要把模块拖到指定位置、填好配置产品就能运转起来。如果你的团队里有非技术背景的人比如产品经理想快速验证一个AI客服的交互逻辑运营想做一个带知识库的问答机器人选Dify会顺手很多。它自带可视化编排、内置的向量数据库、日志管理和简易权限控制几乎覆盖了上线一个AI应用所需要的全部配套设施。但Dify的局限也很明显一旦你的业务流程特别个性化比如某个环节需要调用公司内部不对外开放的服务、需要和自研系统做复杂的数据双向同步拖拽平台往往会让你觉得束手束脚。低代码平台的价值在于帮大多数常见需求提供默认路径代价就是在这个路径之外的地方你需要付出额外的变通成本。LangChain则没有这种边界可以说它几乎没有开箱即用的产品形态它给的是底层抽象。你既可以用它做一个几百行的命令行小工具也可以在它之上构建一整套包含多Agent协作、人工审核、消息队列的高并发系统。代价就是一切都需要你亲手搭建对工程能力和调试经验要求高。一句话总结追求交付速度和团队协作效率选Dify追求极致定制和系统集成深度选LangChain。两者也不是非此即彼很多团队实际用的是Dify做前端交互和演示、LangChain处理底层复杂业务逻辑中间通过API对接。4.3 CrewAI补充的是多角色协作这一环如果你已经理解了Agent的概念那么CrewAI解决的问题会更聚焦多个Agent之间如何分工、协作、接力完成任务。在LangChain里Agent更像一个独行侠它能用工具但通常是单角色单目标。CrewAI则引入了人类团队协作的隐喻你定义不同的Agent角色比如研究员文案写手数据校验员再定义Tasks任务清单最后把它们组成一个Crew设定好流程后CrewAI会按角色分工、顺序执行、传递结果最终汇总成完整产出。举个实际例子做一个竞品分析报告你可以让研究员Agent去检索资料并输出要点让数据分析Agent把要点整理成结构化表格最后让文案Agent润色成报告全文。每个Agent有各自的提示词、工具和模型配置CrewAI负责把它们串成一个多阶段的流水线甚至支持Agent之间互相点评、迭代。不过我也要提醒一点CrewAI的多Agent协作听起来很酷但它对底层的模型推理能力依赖很大。角色太多、任务太细反而容易让结果变得冗长且难控制token开销更是肉眼可见地上涨。我个人的经验是能用一个Agent加几个工具解决的问题绝对不要为了炫技而上三个Agent。多角色协作应该出现在你确实需要并行处理、专业分工的复杂任务里而不是每个Demo的标配。5. 初学者最容易踩的坑以及我给的学习路线5.1 版本和API变更你今天搜到的教程很可能已经过时LangChain是我见过版本迭代最积极的框架之一没有哪个技术社区能保证教程长期有效。我记得有一次按一份很火的教程跑ConversationBufferMemory的示例装的是最新版结果旧写法直接被废弃折腾半天才跑通。问题的根源在于LangChain正在重构很多核心概念新写法不断替代旧写法旧教程自然就成了过期教程。面对这个坑我的应对策略有三条优先看官方文档里和你安装版本号匹配的示例不要盲信冠以最新头衔的第三方文章在pip安装时不要随手装最新版而是固定一个大版本比如langchain0.3,0.4这样团队协作时不会因为各自装的版本不同而行为不一致遇到API报错先把异常信息里的类名和你的版本号一起搜索多半能找到迁移说明。版本问题不是你不细心而是生态本身的变化速度太快。心态上别慌遇到一个废一个慢慢就建立起了自己的最新经验库。5.2 上下文和Token消耗记忆不加节制账单会教你做人跑通多轮对话Demo之后我见过太多人兴奋地给机器人加上无限记忆结果就是每一次请求都把所有历史对话完整带上token费用成倍增长响应时间也肉眼可见变慢。尤其是在做Agent应用时每一轮思考-调用工具-观察结果都要重新发送一遍累积的消息消耗比普通对话大得多。我建议你在设计系统时就把预算机制放在前面限制历史窗口条数比如最多保留最近20条消息更早的要么丢弃、要么压缩成摘要给工具返回结果设长度上限避免一次查询返回一个大JSON然后原封不动塞回上下文在测试阶段记录每次请求的输入token数提前摸清不同场景的成本模型。很多新手觉得token成本是以后的事实际上等你发现月度账单时设计早已经定型了。这个坑我踩过不止一次所以专门列出来提醒。5.3 过度封装不是所有应用都需要上Agent还有一种常见的偏航是把LangChain用得过于隆重。有的同学一上来就设计复杂的Multi-Agent让模型之间互相协调决策。结果呢要么经常性超时要么某一步错误就整条链路失败最后连问题出在哪都难排查。我的建议是从最小可用闭环开始能用普通链解决问题绝不上Agent。如果你的业务流程是固定顺序的取参数-查数据-生成答案一条Chain就够了Agent只适合那些你无法预先确定步骤数和工具顺序的场景。复杂的Agent编排适合放在系统演进到确实需要它的阶段再引入而不是项目一开始就打满。5.4 我推荐的入门路线按顺序走别跳级最后把我带过的几批新手验证过的路线分享出来先裸调用模型API只聊对话和结构化输出搞懂模型本身能做什么、不能做什么再用LangChain的PromptTemplate和OutputParser重写刚才的代码体会抽象组件带来的编码效率提升跑一个Memory多轮会话Demo同时手工控制历史消息的裁剪逻辑搭一个最小RAG系统加载一份本地文档、切分、向量化、检索、问答最后才学Agents和Tools先实现一个能调用单一工具的Agent再逐步增加工具数量和多角色协作。这条路线每一层都建立在前一层的认知上不会出现概念都听过、代码却无从下手的尴尬。等你把Agent玩熟了再往工程化方向走就轮到LangGraph和Agent Inbox这类概念出场了。Agent让机器主动干活但总有它拿不准需要人工确认的节点Agent Inbox就是给人留的审批席让复杂任务在无人值守和人工介入之间找到平衡。提示你不需要在第一步就学全所有组件。先用一个真实场景比如做一个翻译助手或一个小型知识问答贯穿整条路线每次只引入一个概念你会比漫无目的地刷文档高效得多。这一套走下来LangChain对你来说就不再是一堆陌生的名词而是一盒可以随手组合的积木。下一篇笔记我会接着拆RAG实战带你把一个本地文档知识问答系统完整跑通。