用Python搭了一个AI Agent之后,我才知道LangChain有多坑
- 2026-06-28 02:43:07
“用LangChain，三行代码就能调用大模型，快速搭建智能应用！”
三个月前，我就是被这句话“骗”进坑的。当时想给自己做一个能自动阅读行业报告、总结要点并生成简报的AI助手。想着用现成的框架省事，果断选择了名声在外的LangChain。
结果呢？从“快速搭建”到“能稳定跑起来”，我花了整整两周，其中90%的时间不是在思考AI逻辑，而是在和LangChain的抽象泄漏、版本兼容、以及那些看似美好实则鸡肋的“高级功能” 作斗争。
今天，我把这个“AI简报助手”用纯Python + 直接API调用重构了一遍，代码量少了三分之一，速度提升了两倍，关键是好懂、好改、好维护。踩过LangChain的坑，我才真正理解了“简单就是美” 在AI应用开发里的分量。
往期阅读>>>
Python 自动化管理Jenkins的15个实用脚本，提升效率
App2Docker：如何无需编写Dockerfile也可以创建容器镜像
Python 自动化识别Nginx配置并导出为excel文件，提升Nginx管理效率
坑一：为了“抽象”而抽象，代码绕成了迷宫
LangChain的核心卖点是“组件化”和“链式调用”。听起来很美好，但当你真的想实现一个稍微定制化的流程时，你会发现自己在各种LCEL、Runnable、Chain对象之间来回穿梭。
LangChain“标准”做法（简化版）：
fromlangchain.chainsimportLLMChainfromlangchain.promptsimportPromptTemplatefromlangchain_community.llmsimportOpenAI# 定义Prompt模板prompt = PromptTemplate(input_variables=["report_text"],template="请总结以下报告：{report_text}")# 创建链llm = OpenAI(api_key="your_key")chain = LLMChain(llm=llm, prompt=prompt)# 运行result = chain.run(report_text=long_report)
看起来还行？但当你需要：
在总结前先提取报告中的关键数据表格。
根据总结内容，再去另一份资料里查询相关背景。
把以上所有结果，用特定格式（比如Markdown）组织起来。
你会发现自己需要定义多个Chain，用SequentialChain把它们串起来，或者写自定义的Runnable。代码很快变得臃肿，而且调试极其不直观——错误信息往往来自层层封装的最底层，你很难一眼看出是哪个环节出了问题。
我的“去LangChain”重构：
importopenaiimportjson# 直接调用API，函数即流程，一目了然defsummarize_report_with_openai(report_text, api_key):"""核心总结函数"""client = openai.OpenAI(api_key=api_key)# 清晰的Prompt，直接描述任务system_prompt = "你是一个专业的行业分析师，擅长提炼长文档的核心观点和数据。"user_prompt = f"请用中文，分点总结以下行业报告的核心内容，并提取关键数据：\n\n{report_text}"try:response = client.chat.completions.create(model="gpt-4o-mini", # 明确指定模型messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt} ],temperature=0.2, # 控制创造性max_tokens=1500 )returnresponse.choices[0].message.contentexceptExceptionase:returnf"总结失败：{str(e)}"# 需要多步骤？那就写多个函数，然后组合调用defgenerate_briefing(report_path, background_info_path):"""生成简报的主流程"""# 1. 读取报告report_text = read_file(report_path)# 2. 调用上面的函数总结summary = summarize_report_with_openai(report_text, API_KEY)# 3. 查询背景（另一个函数）background = query_background(background_info_path, summary)# 4. 格式化输出final_briefing = format_to_markdown(summary, background)returnfinal_briefing
感受：重构后的代码，流程就是代码，代码就是流程。任何一个同事（甚至一个月后的我自己）都能在五分钟内看懂它在干什么，以及在哪里修改。而LangChain那一套，我每次都要重新去查文档，回忆那些抽象概念。
坑二：版本迭代如闪电，文档永远慢半拍
LangChain的迭代速度“令人惊叹”。我项目刚开始时用的0.1.x，等到项目中期，已经发布了0.2.x，许多API和导入路径发生了破坏性更新。最痛苦的是，你搜到的Stack Overflow答案、博客教程，很可能基于一个你已经不用的旧版本，代码完全跑不通。
from langchain.llms import OpenAI -> from langchain_openai import OpenAIfrom langchain.chat_models import ChatOpenAI -> 同上，但参数又变了。
我像是个追着火车跑的人，大部分精力花在了“让代码能跑起来”这件本应是最基础的事情上。而直接用openai这个官方库，API稳定得多，文档清晰，社区解答也直接。
坑三：“智能”记忆与状态管理，往往过度设计
LangChain提供了ConversationBufferMemory、ConversationSummaryMemory等高级记忆组件，用于构建多轮对话Agent。这听起来是刚需，对吧？
但在实际构建一个处理文档的Agent时，我发现这些记忆管理带来了巨大的复杂性。我需要小心翼翼地管理memory对象的输入输出，确保对话历史被正确传递和截断。更头疼的是，当我想把某次对话的上下文持久化到数据库，或者实现更复杂的记忆检索（比如只提取和当前问题相关的历史片段）时，LangChain内置的组件要么不够用，要么用起来很别扭。
后来我明白了：对于许多任务型Agent（比如我的简报助手），它根本不需要复杂的多轮对话记忆。它的每次运行都是相对独立的“任务”：输入文档，输出结果。所谓的“记忆”，更多是任务本身的上下文（比如之前处理过哪些报告），这用简单的数据库或者一个字典来记录，反而更清晰、可控。
# 我自己实现的简单“任务记忆”classTaskMemory:def__init__(self):self.processed_reports = {} # report_id: {summary, timestamp}defhas_processed(self, report_id):returnreport_idinself.processed_reportsdefstore_result(self, report_id, summary):self.processed_reports[report_id] = {'summary': summary,'timestamp': datetime.now() }defget_recent_summaries(self, n=5):# 获取最近处理的n份报告摘要，逻辑完全自己掌控pass
结论：LangChain预设了很多“通用”场景，但当你需要“特制”时，这些预设就成了枷锁。
坑四：依赖臃肿，“全家桶”式安装
为了用上LangChain的某个核心功能（比如调用OpenAI），你很可能需要安装langchain-core, langchain-openai, langchain-community等一系列包。这还不算完，如果你要用它的文档加载器（DocumentLoader），可能又要引入处理PDF、PPT、网页的额外依赖。
我的虚拟环境很快就被撑大了。而当我最终决定剥离LangChain时，我发现我的核心需求其实只需要：openai（调用模型）、requests（获取网页/API）、pypdf2或pdfplumber（读PDF）。依赖项清爽了太多，部署和移植也轻松了。
那么，什么时候该用LangChain？
踩了这么多坑，我并不是要全盘否定LangChain。经过这次折腾，我反而更清晰地看到了它的适用边界：
你是绝对的AI应用新手，想用最短时间体验一下“链式调用”的感觉，做一个玩具项目。LangChain的快速入门确实有帮助。
你的需求极其标准，恰好落在LangChain官方示例覆盖的范围内，且你愿意跟随它的版本快速迭代。
你在构建一个需要集成多种不同工具（搜索引擎、数据库、各种API）的复杂Agent，并且愿意花时间深入理解LangChain的架构来换取可能的开发速度（后期）。
但对于像我这样的多数开发者：我们只是想稳定、清晰、可维护地解决一个具体的业务问题，把大模型能力嵌入到现有工作流中。那么，直接从官方SDK开始，用朴素的Python函数来组织你的逻辑，往往是更优选择。
我的“去框架化”AI开发心得
从“裸”API开始：先用
openai、anthropic等官方SDK，把核心的模型调用玩明白。理解system prompt、user prompt、temperature这些基本概念，它们比任何框架都重要。Prompt工程就是你的核心逻辑：花时间设计一个好的Prompt模板，比挑选一个复杂的Chain更有用。把Prompt当成需要精心编写的代码。
用函数和类构建你自己的“微框架”：你需要记忆？写个
Memory类。你需要工具调用？定义清晰的工具接口和路由函数。这样构建出来的东西，完全贴合你的业务，没有冗余。拥抱“胶水代码”：AI应用本质上是“大模型”+“传统编程”的胶水。不要怕写那些读取文件、调用数据库、处理字符串的“无聊”代码，它们才是系统稳定的基石。
你在使用LangChain或其他AI框架时，踩过最大的坑是什么？欢迎在留言区分享你的血泪史。
https://ima.qq.com/wiki/?shareId=f2628818f0874da17b71ffa0e5e8408114e7dbad46f1745bbd1cc1365277631c
