前言在前面七篇文章中我们拆解了Embedding、Transformer、幻觉、Prompt Engineering、RAG、会话管理和API调用。这些知识已经足够你从零开始搭建一个大模型应用。但你一定会遇到一个问题“我用大模型API直接写不行吗为什么非要套一个LangChain”这是一个非常好的问题。事实上网上对LangChain的评价两极分化——有人说它是“AI应用开发的必备框架”有人说它是“过度封装的垃圾”。本文的目标不是站队而是帮你理解LangChain到底解决了什么问题、引入了什么新问题从而形成你自己的判断。面试中面试官看到你简历上写了LangChain可能会问“LangChain是干什么的它有什么缺点” 读完本文你能给出一个有思考、有判断的回答而不是背诵官方文档。本文核心问题用大模型API直接写代码不行吗为什么需要LangChainChain链解决了什么问题和直接调用有什么区别Agent智能体和Chain有什么本质不同什么时候用AgentTool工具是怎么让大模型“调用外部函数”的LangChain的局限是什么什么情况下它反而增加复杂度为什么有人觉得LangChain是“过度封装”这种批评合理吗LangChain在你的课程问答项目中扮演了什么角色用了哪些组件不用LangChain还有其他选择吗读完本文你将对LangChain拥有“不吹不黑”的独立判断力。一、直接用API不行吗——从“能用”到“好用”的鸿沟疑问我直接用OpenAI的SDK写代码几行代码就能调用大模型为什么还要套一层LangChain回答当需求足够简单时直接用API确实更好。但当需求变复杂后你会发现自己在“重复造轮子”。1.1 直接调API的代码// 最简单的调用——几行代码搞定OpenAIopenAIOpenAI.builder().apiKey(apiKey).build();StringansweropenAI.chatCompletion(你是谁);当你的应用只需要“用户问一句模型答一句”时这就够了。LangChain在这时候确实是多余的。1.2 当需求变复杂时但你的课程问答助手实际需要的远不止“问一句答一句”实际流程 1. 用户提问 2. 把问题向量化 3. 去向量数据库检索相关课程文档 4. 检查检索结果的相关性不相关的过滤掉 5. 获取对话历史前几轮说了什么 6. 拼接Prompt系统指令 历史对话 检索文档 用户问题 7. 调用大模型流式输出 8. 保存对话历史 9. 返回SSE流如果全部手写你需要管理流程编排9个步骤的顺序和依赖关系状态管理对话历史、检索结果在步骤间的传递错误处理向量数据库挂了怎么办API超时了怎么办可替换性万一想换一个Embedding模型要改多少代码调试追查回答出错了是检索环节的问题还是生成环节的问题而LangChain提供了一套抽象层把这些常见的工作封装成可组合的组件。它用一套统一的接口将上述步骤串联起来调试时可以单独检查每个环节的输出。换Embedding模型时只需改一行配置不需要重写整个Pipeline。1.3 LangChain做了什么LangChain的角色 直接用API → 你管理一切 LangChain → 框架管理流程你只需配置组件和定义链式结构 它不是替代大模型API而是在API之上提供了一层“流程编排” 让你不需要每次都从头写“检索→拼接→生成→存储”这套逻辑。二、Chain——把多个步骤串成一条链疑问Chain是什么为什么叫“链”回答Chain是LangChain最核心的概念——把多个操作串成一条链数据像流水线一样在链上流动。2.1 一个最简单的Chain// 不用Chain手动编排每一个步骤StringquestionJava线程池有哪些参数;Stringprompt请回答question;StringansweropenAI.chatCompletion(prompt);// 用Chain声明式地定义流程LLMChainchainnewLLMChain(llm,promptTemplate);Stringanswerchain.run(question);看起来Chain写了更多代码但区别在于Chain把promptTemplate和llm绑定在一起后续任何调用都自动走“拼接Prompt→调大模型”这个流程。当有10个不同的业务场景都需要这样的调用模式时手动编排的重复代码量会迅速膨胀。2.2 课程问答项目中的ConversationalRetrievalChainConversationalRetrievalChainchainnewConversationalRetrievalChain(llm,// 大模型retriever,// 向量检索器memory// 对话记忆);Stringanswerchain.run(Java线程池有哪些参数);这一个类封装了多步操作拿到用户问题→从memory获取对话历史→用retriever检索文档→自动拼接Prompt→调用LLM生成回答→更新memory。所有这些步骤在链的内部完成流转调用者只需传入问题并拿到答案链就像一个完整的问答流水线。没有Chain的话你需要手动调用Memory查询、手动传递给Retriever、手动拼Prompt结构、手动更新Memory。6个环节每个都可能出错而出错时你只能逐个环节排查——是检索返回了空结果还是拼接时字段错了在Chain中每个环节的输入输出是可观测的调试时可以精准定位到具体的节点。三、Agent——让大模型“自己决定做什么”疑问Agent和Chain有什么不同什么时候用Agent而不是Chain回答Chain是“固定流程”Agent是“动态决策”。Chain是你事先规划好步骤Agent是大模型自己决定先做什么、后做什么、用哪个工具。3.1 固定流程 vs 动态决策Chain 用户问 → 固定步骤1 → 固定步骤2 → 固定步骤3 → 输出 适合流程确定、不需要灵活变通的场景如课程问答永远是检索→生成 Agent 用户问 → LLM分析意图 → 决定做A → 看A的结果 → 决定做B还是C → 继续... 适合目标确定但路径不确定的场景如“帮我查一下明天下雨的概率并写一封邮件给老板”3.2 Agent的工作原理AgentagentnewAgent(llm,tools);// 用户随便问Agent自己决定怎么做agent.run(帮我查一下北京明天天气如果是晴天就帮我写一封邮件给老板说可以出去团建);// Agent的思考过程// 1. 用户想查天气 → 我需要调用天气查询工具(tool)// 2. 天气结果出来了 → 是晴天 → 用户说晴天才写信 → 我需要调用邮件生成工具(tool)// 3. 邮件生成好了 → 返回给用户整个思考过程由大模型自己决策——它不是在执行预设的步骤而是在理解用户意图后动态规划行为。它知道什么时候该调用工具体什么时候该根据工具返回的结果做下一步决策什么时候该直接给出最终答案。这种动态性让Agent能处理Chain做不到的复杂开放式需求。3.3 核心区别总结维度ChainAgent流程固定预设动态LLM决策适用场景任务明确、步骤固定目标明确、路径不确定工具使用不涉及工具调用可调用外部工具灵活性低高复杂度低高稳定性高中等存在“迷路”风险3.4 Agent的“迷路”问题Agent有一个特有的问题它可能在执行多步操作时“迷路”——反复调用同一个工具却得不到有效信息或者在应该停止时继续调用更多工具无限循环消耗Token和用户等待时间。解决方法一般有二设置maxIterations最大迭代次数做硬性兜底结合Few-shot示例让Agent学会在什么情况下应该停止。课程问答项目没有使用Agent因为它的任务是高度固定的永远是检索→总结→回答不需要动态决策。用Chain比用Agent更稳定、更可控。四、Tool——让大模型“动手”的能力疑问Tool是什么为什么Agent需要Tool回答Tool是让大模型能够调用外部函数如搜索引擎、计算器、数据库的接口。如果Agent是“大脑”Tool就是“四肢”。没有四肢的大脑只能思考、不能行动。4.1 大模型的天然局限大模型本质上是进行概率预测的语言模式分析器——它只能“想”和“说”不能“做”。没有Tool的大模型无法回答“今天天气”因为它不能获取实时信息无法进行精确数学计算因为它本质是在猜测结果无法查询数据库中的订单状态因为它无法调用外部系统接口。Tool弥补了这三个根本性的能力缺口局限对应Tool不能查实时信息搜索引擎Tool / 天气查询Tool不能精确计算计算器Tool / 数学引擎Tool不能操作外部系统数据库查询Tool / API调用Tool4.2 Tool是怎么工作的Tool(name天气查询,description通过城市名查询今天天气)publicStringqueryWeather(StringcityName){returnweatherAPI.getTodayWeather(cityName);}Tool(name计算器,description进行数学计算)publicdoublecalculate(Stringexpression){returncalculator.eval(expression);}当用户问“北京明天天气怎么样”时Agent不需要预设这个流程——它看到用户提到了天气检查自己的工具箱里有一个天气查询工具理解这个工具的描述后决定调用它。然后把工具返回的结果“北京明天晴15-25℃”作为上下文继续分析判断是否需要进一步调用其他工具还是可以直接回答用户。整个过程是大模型自身根据任务和工具定义动态决定的。4.3 课程问答项目中为什么没有用AgentTool课程问答的场景是“基于课程文档回答问题”流程高度固定检索→总结→回答。没有需要Agent动态决策的场景——不存在“根据问题类型选择不同工具”“根据文档内容决定是否需要查外部数据库”这类需求。在这种情况下强行引入Agent是过度设计——它增加了不稳定性和Token消耗却没有带来任何功能上的提升。Chain就是课程问答场景的最佳选择。五、为什么有人觉得LangChain是“过度封装”疑问网上对LangChain的批评很多这些批评合理吗回答部分合理。LangChain确实在易用性和灵活性之间存在一些矛盾。理解这些批评能帮你更好地使用它。5.1 主要的批评点批评是否合理具体情况抽象层太多调试困难✅ 部分合理封装太深时定位BUG需要一层层扒源代码版本更新频繁API不稳定✅ 客观事实0.x版本阶段API变化大文档更新常滞后隐藏了Prompt细节✅ 部分合理自带Prompt模板可能不如自己写精确可控性降低对简单场景太重✅ 合理“问一句答一句”确实不需要额外的框架层增加了依赖和部署复杂度✅ 合理框架升级带来额外的依赖管理成本和兼容性维护5.2 LangChain该不该用可以用LangChain的场景 - 多步流程编排检索→拼接→生成→存储 - 需要切换模型/检索器/数据库LangChain的抽象层让切换更容易 - 团队协作开发统一组件接口多人更容易理解流程 - 快速原型验证组件复用性让搭建速度快 不该用LangChain的场景 - 简单问答增加复杂度 - 对Prompt有极致精确控制要求自带的模板可能干扰你的设计 - 追求极致性能和最低延迟框架层带来微小的额外开销 - 不想引入额外的依赖和版本兼容性维护成本 - 团队已经积累了自己的扩展工具库不需要框架的轮子5.3 我的观点LangChain是一套脚手架。对于快速搭建原型和标准化多步流程它非常高效。但不要把它当成“唯一正确的方式”——理解它的原理后当你的需求超出它的能力范围时应该有能力绕开它直接调API实现。框架是工具不是信仰。LangChain的价值在于帮你少写重复代码而不是限制你怎么写。好的用法是理解它的抽象逻辑用它来完成80%的标准化工作剩下的20%通过直接调API来获得精确控制。六、课程问答项目中的LangChain使用疑问你的课程问答项目中具体用了LangChain的哪些组件为什么选这些回答只用了三个核心组件——ConversationalRetrievalChain、ConversationBufferMemory、以及向量检索集成。没多用一个多余的类。// 项目中实际使用的LangChain组件ConversationalRetrievalChainchainnewConversationalRetrievalChain(openAI,// LLMretriever,// 向量检索器Chromamemory// 对话记忆ConversationBufferMemory);选择逻辑组件作用选它的原因ConversationalRetrievalChain串联检索→拼接→生成→存储场景恰好是这个标准流程不需要自己写串联逻辑ConversationBufferMemory记住对话历史短对话最适合全量保留Token压力小Chroma向量检索存储和检索文档向量课程文档量不大不需要Milvus级别的分布式搜索用到什么程度就停下面是几个项目中做出的取舍没用Agent没有需要动态决策的场景。强行引入Agent会引入迷路风险和额外的Token开销换成Chain稳定可控。没用PromptTemplate的默认模板全部Prompt自己编写。课程问答的约束条件比较特殊标注章节来源、不超过300字、不知道就说不知道默认模板太通用自己的模板更贴合需求。没用LangChain的流式输出封装用Spring Boot SSE原生实现。当时LangChain的流式支持还不稳定原生Spring实现更可控和现有技术栈的整合也更自然。七、不用LangChain还有什么选择疑问如果不用LangChain还能用什么回答几个主流选择各有利弊。方案适合谁优势劣势LangChain快速原型、标准流程文档全、组件多、上手快封装深、版本变动大、底层可观测性有限LlamaIndex文档检索为主的应用RAG场景比LangChain更专业生态比LangChain小组件多样性较低Spring AIJava技术栈团队和Spring Boot天然集成基于Spring生态的统一抽象相对较新生态还在建设中直接调API需求明确且有经验的团队完全可控、无依赖的黑盒封装、性能最优工作量更大团队需要自行扩展和维护所有扩展模块根据经验选方案的建议课程问答项目选LangChain是因为它提供了开箱即用的RAG流程。如果未来项目需求变得复杂且团队有足够积累会考虑逐步去掉LangChain换成直接调API 内部自建的标准化组件。选框架取决于当前阶段和需求——早期快速验证时框架的价值是帮你省时间后期需求稳定且团队经验丰富时框架反而可能成为限制。不是框架不好是阶段不同选择不同。总结LangChain不是“套壳”——它在API之上提供了流程编排、状态管理和组件抽象解决的是“从能用变好用”的问题Chain 固定流水线适合步骤确定的场景如课程问答检索→拼接→生成→存储。稳定可控调试时每个环节可独立检查Agent 动态决策者让大模型自己决定用什么工具、按什么顺序处理。适合开放式需求但有“迷路”和不确定性增加的代价Tool 四肢弥补大模型不能查实时信息、不能精确计算、不能操作外部系统三大局限LangChain的局限客观存在封装深导致底层可观测性降低、版本迭代快导致兼容性风险、对简单场景过于笨重课程问答项目只用了三个组件ConversationalRetrievalChain ConversationBufferMemory Chroma检索。场景刚好是标准RAG流程LangChain的串联能力正好匹配框架是工具不是信仰理解它的原理后该用它的时候用它该绕开的时候有能力绕开。选LangChain是因为当前阶段它能帮团队更快迭代而不是因为它是唯一正确的选择专栏完结本文是“AI理论学习”专栏的最后一篇。从Embedding到Transformer从Prompt Engineering到RAG从会话管理到API调用最后到LangChain框架——八篇文章形成了一个完整的AI应用开发知识体系。接下来“AI应用实战”专栏将对这些理论进行项目验证。理论学完了该上代码了。