最近經常被問到一個問題LangChain 到底還值不值得學LangGraph 是來替代 LangChain 的嗎企業做知識庫問答、Agent 自動化到底應該先學什么這些問題的答案其實指向同一條主線LangChain 負責組件生態LangGraph 負責流程編排Agent 是應用形態RAG 是內容增強手段。把它們串起來基本就是當前企業級 LLM 應用開發的核心能力棧。這篇文章不打算做概念堆砌而是按“從入門到可上線”的順序把這條技術棧的學習主線、代碼骨架、工程化方法和常見坑位拆開講清楚。先給結論LangChain 沒有過時但學習重心已經變了。早期大家學 Chain、LCEL、快速封裝模型調用現在官方和社區更強調 LangGraph 的工作流編排能力RAG 也從基礎的“向量檢索 拼接 Prompt”升級到了 Agentic RAGAgent 則從簡單的工具調用演變成多節點、可持久化、可監控的圖結構應用。這篇文章適合三類讀者一是剛入門、想規劃 LangChain 學習路線的開發者二是寫過簡單 RAG Demo、但不知道如何工程化上線的后端工程師三是在評估 LangGraph 能不能接入現有業務系統的技術負責人。文中代碼均為可運行的示意具體版本、模型名、目錄路徑需要按你自己的環境替換。文章會先給一套“核心能力速覽”再依次拆解 LangChain 基礎、RAG 實戰、Agent 設計、LangGraph 編排和企業級工程化最后給出一條可以按周執行的學習路線。1. LangChain LangGraph Agent RAG 核心能力速覽能力項說明技術棧組成LangChain 組件層 LangGraph 工作流編排 Agent 應用形態 RAG 檢索增強核心目標讓開發者快速構建基于大模型的問答、知識庫、自動化決策類應用適合讀者Python 開發者、后端工程師、AI 應用落地團隊前置知識Python 基礎、HTTP/API 調用基礎了解 Prompt 基礎更佳運行環境入門階段有模型 API Key 即可本地部署需要 GPU顯存按模型規模評估模型支持兼容 OpenAI 風格 API、國產大模型、Ollama/vLLM 等本地推理服務交付形態Web API、Streamlit 演示系統、業務系統內嵌、定時任務、消息隊列消費端企業關注點可觀測、可評測、可回滾、權限可控、數據不泄露常見誤區只抄示例不追蹤版本一上來疊概念忽略評測和回歸不設兜底策略這條技術棧的定位很明確它不是某個“開箱即用的一鍵大模型工具”而是一套面向大模型應用開發的編程框架和設計范式。你可以用它寫 20 行的內部小工具也可以構建支持多輪對話、動態規劃、多工具協作的中大型業務系統。不同的復雜度對應不同的學習深度這也是為什么后面要做分階段規劃。2. 這套技術棧在解決什么問題在沒有 LangChain 這類框架之前寫一個調用大模型的應用并不難難的是把“模型調用”變成“可靠業務邏輯”。比如多個文檔要加載解析切成合適的塊回答要引用出處用戶提問要先判斷要不要查庫再判斷要不要調用工具一次任務可能拆成多個步驟某一步失敗要重試整個流程要能被監控出了問題要能回溯。LangChain 解決的是連接問題。它對模型調用、Prompt 模板、文檔加載、文本切分、向量庫、外部工具做了統一的抽象避免每個項目都從零開始造輪子。LangGraph 解決的是流程問題。它把一次 AI 任務建模成一張有狀態的狀態圖節點可以增刪邊可以按條件跳轉狀態可以被持久化任務可以在中途被打斷并恢復。Agent 解決的是決策問題。它讓模型不再是“答一句話”而是根據目標決定“先做什么、再做什么、何時結束”。RAG 解決的是知識來源問題。它把企業私有文檔變成模型在生成時可以參考的上下文緩解幻覺也讓回答可以有出處。從適用邊界看這套技術棧最適合“知識密集型”和“流程密集型”場景比如企業內部知識庫問答、客服工單分類與回復草稿、結構化工單抽取、數據報表的自然語言查詢、自動化測試用例生成等。不適合的場景包括完全依賴模型輸出做最終決策的高風險環節沒有人工復核的自動化操作以及對延遲極其敏感的實時系統——在這些場景中需要先做好權限、緩存、兜底和評測機制再上線。需要特別強調合規邊界RAG 一旦接入企業真實文檔就要確認文檔來源合法、是否包含敏感信息、是否可以用于指定業務Agent 如果涉及自動調用外部系統必須設計操作審計、權限隔離和干預期發布到面向公眾的應用前要對生成內容做一輪人工抽檢。技術能力只是“能做”合法合規之后才是“可上線”。3. 入門階段LangChain 基礎組件怎么學3.1 環境準備入門階段不一定要 GPU優先準備一個可以穩定調用的大模型 API 即可。無論是云廠商的模型服務還是本地 Ollama 啟動的模型只要能通過 OpenAI 兼容接口調用就行。Python 版本建議使用當前的穩定版本比如 3.10 及以上包管理建議用 venv 或 conda 隔離環境避免依賴沖突。# 創建虛擬環境實際命令需要根據系統路徑調整 python -m venv .venv source .venv/bin/activate然后安裝 LangChain 生態的核心依賴。需要說明的是LangChain 包拆分比較頻繁安裝前建議先查看官方文檔確認當前推薦包名和版本。# 示意安裝具體包名和版本以官方文檔為準 pip install langchain langchain-openai langchain-community langgraph3.2 第一次調用模型初學階段最重要的不是背 API而是建立一條“模型調用 - 結構化輸出 - 異常處理”的最小閉環。下面這段代碼使用 OpenAI 兼容接口調用模型如果你使用的是其他服務商把base_url和api_key換成自己的即可from langchain_openai import ChatOpenAI llm ChatOpenAI( modelgpt-4o-mini, temperature0, # 如果使用本地推理服務這里改成對應的 base_url # base_urlhttp://127.0.0.1:8000/v1, # api_keylocal-model-key, ) resp llm.invoke(用一句話解釋什么是 RAG) print(resp.content)這段代碼跑通之后下一步不是繼續加功能而是反推框架里的幾個關鍵概念model對應模型層temperature對應生成參數response對應標準化輸出結構。LangChain 的核心價值之一就是把“不同模型的差異”隱藏在統一接口后面業務代碼不需要跟著模型供應商變化頻繁改動。3.3 入門階段最容易踩的坑版本混裝網上代碼大多來自不同時期的 LangChain 版本直接復制會導致import報錯。解決辦法是固定版本并在環境里查看pip show langchain確認版本號。跳過 Prompt 工程直接做 RAG檢索再準Prompt 寫得含糊生成質量也會受影響。不設超時和重試模型服務偶爾不穩定生產環境必須配置超時、重試和兜底回答。4. RAG 實戰從文檔加載到知識庫問答RAG 是目前 LangChain 技術棧里最容易“跑通 Demo、最難做好效果”的方向。先理解全鏈路再調參。4.1 RAG 的標準鏈路一條完整的 RAG 鏈路至少包含四步文檔加載從 PDF、Word、Markdown、網頁、數據庫等來源取得原始文本。文本切分把長文本切成適合向量化的塊并保留上下文重疊。向量化與存儲用 Embedding 模型把文本塊變成向量寫入向量庫或支持向量檢索的數據庫。檢索與生成用戶提問后用問題向量召回最相關的文檔塊拼進 Prompt 交給生成模型輸出答案。下面的代碼演示了從本地文本文件構建向量庫的示意流程from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_chroma import Chroma # 1. 加載文檔 loader TextLoader(service_docs.md, encodingutf-8) docs loader.load() # 2. 文本切分參數需要根據文檔類型調整 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) chunks splitter.split_documents(docs) # 3. 向量化并寫入向量庫 embedding OpenAIEmbeddings() vectorstore Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./chroma_db ) # 4. 構建檢索器 retriever vectorstore.as_retriever(search_kwargs{k: 3})這個流程跑通之后你會遇到第一個真實問題為什么檢索結果看起來相關但回答質量不穩定原因通常在切分策略和召回數量上。切分太小會丟上下文切分太大又會混入噪聲召回數量太少可能漏信息太多又會稀釋 Prompt 中的關鍵內容。這些問題沒有統一的“最優參數”要根據你的文檔類型和問題分布來做回歸測試。4.2 生成階段把檢索結果接入 Prompt構建一個“檢索 - 生成”的問答鏈可以用 LangChain 提供的create_retrieval_chain也可以手動拼裝 Prompt。手動拼裝的好處是邏輯透明方便插入你自己的業務邏輯。from langchain.prompts import ChatPromptTemplate prompt ChatPromptTemplate.from_messages([ (system, 請基于以下知識庫內容回答問題。如果知識庫中沒有可靠依據請直接說明不知道不要編造。\n\n知識庫內容\n{context}), (human, 問題{question}) ]) def rag_answer(question: str) - str: docs retriever.invoke(question) context \n\n.join([doc.page_content for doc in docs]) chain prompt | llm resp chain.invoke({context: context, question: question}) return resp.content print(rag_answer(我們公司的退款政策是什么))這里有一個很關鍵的工程判斷RAG 的輸出質量不僅取決于模型更取決于召回鏈路。當回答效果不好時不要第一時間換大模型先檢查召回的內容是否準確、是否完整、是否存在互相矛盾的信息。等檢索質量穩定后再去調整 Prompt 或換模型。4.3 企業級 RAG 需要補什么入門版 RAG 能回答“單文檔、單庫”的問題但企業級落地通常需要補充多路召回相同問題同時召回向量相似結果和關鍵詞匹配結果再做合并排序。引用溯源返回答案時把來源文檔 ID、頁碼、切塊 ID 一起返回方便用戶點開原文核對。權限過濾不同角色只能檢索自己有權限訪問的文檔集合。數據更新機制文檔變更后增量更新向量庫而不是每次全量重建。評測與回歸準備一批“標準問答對”每次調整 Prompt、切分參數、召回策略后用同一套題目驗證效果是否回退。5. Agent 實戰從思維鏈到工具調用RAG 解決的是“不知道”的問題Agent 解決的是“不會做”的問題。所謂 Agent簡單說就是讓模型根據用戶目標自己規劃行動步驟、調用外部工具、觀察返回結果、再決定下一步動作的智能體應用。5.1 Agent 的最小設計開發一個 Agent 前先想清楚三件事模型流程如何驅動、Agent 可以調用哪些工具、如何避免循環和失控。一個常見的 Agent 形態是 ReAct 模式模型先分析當前狀態決定調用什么工具拿到工具結果后再繼續推理直到得出最終答案。下面是一個基于 LangGraph 思路的 Agent 骨架示意from typing import TypedDict from langgraph.graph import StateGraph, END class State(TypedDict): messages: list current_tool: str def agent_node(state: State): # 這一步讓模型決定下一步動作返回要調用的工具或最終答案 return {messages: state[messages]} def tool_node(state: State): # 這里根據 current_tool 執行真實函數調用 return {messages: state[messages]} graph StateGraph(State) graph.add_node(agent, agent_node) graph.add_node(tools, tool_node) graph.add_edge(agent, tools) graph.add_edge(tools, agent) graph.set_entry_point(agent) app graph.compile()這個骨架雖然簡單但已經體現了 Agent 的三個關鍵特征有狀態所有歷史消息在 State 中傳遞、有循環agent 和 tools 之間可以反復跳轉、有出口需要設計條件判斷在得到最終答案時結束循環。實際開發時會在agent_node中判斷是返回“調用工具”的指令還是“最終答案”然后通過條件邊決定走向tool_node還是END。5.2 Agent 的工程化要點工具數量要克制不是工具越多越好工具太多會增大模型選錯工具的概率。每個工具都要有清晰的描述、參數定義和調用邊界。要設最大迭代次數Agent 可能陷入反復調用工具的循環必須設置最大步數超過就強制結束并返回正在處理中的提示。要做操作審計涉及查詢訂單、修改配置、推送消息等操作時記錄每次工具調用方便追蹤。要容忍失敗工具可能超時、報錯、結果為空Agent 設計要包含“工具失敗后的備選行動”而不是直接崩潰。要做好權限控制讓模型自動調用有權限風險的工具前先評估是否需要人工確認環節。這里要特別提醒Agent 的“自動化”會放大模型誤判的后果。如果 Agent 自動發送消息、自動下單、自動改配置一定要設計人工審批和灰度開關避免一次誤調用造成連鎖問題。6. LangGraph 實戰把流程變成可維護的工作流6.1 LangGraph 和 LangChain 到底是什么關系這兩個概念經常被混在一起討論。簡單理解LangChain 是組件庫LangGraph 是編排引擎。LangChain 提供模型封裝、文檔加載、向量庫、Prompt 模板等“積木”LangGraph 負責決定這些積木按照什么順序、什么條件、什么狀態去組合執行。早期 LangChain 官方主推 Chain 和 LCEL適合線性流程但企業應用普遍有分支、循環、多角色協作、人工介入等復雜需求LangGraph 顯然更適合承載這些場景。這也是為什么很多人說“LangGraph 會替代 LCEL”。更準確的說法是LangGraph 替代了 LangChain 中“流程編排”那一層的位置而組件層依然是 LangChain 生態的強項。6.2 LangGraph 的核心概念LangGraph 的核心抽象是狀態圖StateGraph圍繞它有五個關鍵概念概念作用學習重點State定義節點間傳遞的數據結構所有節點只能修改 State 中聲明的字段Node圖中的執行單元一個函數或一個可調用對象接收 State 返回新 StateEdge節點之間的連接決定執行順序普通邊固定跳轉Conditional Edge條件邊根據 State 內容動態決定下一個節點Checkpointer狀態持久化支持任務中斷、恢復、回放是企業級核心能力從代碼層面看LangGraph 的“圖”并不是什么新概念但它把 AI 應用中的復雜控制流變成了可視化、可測試、可回放的對象這讓團隊協作和線上排障都容易很多。比如一個客服 Agent如果流程寫成十幾個 if-else沒人敢改如果用狀態圖表達每個節點獨立測試條件邊單獨調試整體風險會小很多。6.3 條件路由示例判斷該走 RAG 還是直接生成下面用條件邊實現一個常見需求根據用戶問題是否涉及知識庫決定走 RAG 節點還是普通生成節點。from typing import TypedDict from langgraph.graph import StateGraph, END class QueryState(TypedDict): question: str need_retrieval: bool context: str def judge_node(state: QueryState): # 這里用模型或規則判斷是否要檢索 need 退款政策 in state[question] or 知識庫 in state[question] return {need_retrieval: need} def rag_node(state: QueryState): return {context: 從向量庫檢索到的內容...} def direct_node(state: QueryState): return {context: } def route_by_need(state: QueryState): return rag if state[need_retrieval] else direct graph StateGraph(QueryState) graph.add_node(judge, judge_node) graph.add_node(rag, rag_node) graph.add_node(direct, direct_node) graph.add_conditional_edges( judge, route_by_need, {rag: rag, direct: direct} ) graph.add_edge(rag, END) graph.add_edge(direct, END) graph.set_entry_point(judge) app graph.compile()這個例子展示的是 LangGraph 的典型用法每個節點只做一件事節點之間的跳轉邏輯通過條件邊表達整體流程清晰也方便在每兩個節點之間插入日志、埋點、人工審核。7. 從入門到企業級工程化與上線清單跑通 Demo 之后離上線還有一段距離。企業級改造通常圍繞接口化、部署、評測、監控四個方向展開。7.1 把鏈路封裝成 API后端項目最常用的是 FastAPI 把 RAG 或 Agent 流程包裝成 HTTP 接口from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class QueryRequest(BaseModel): question: str user_id: str app.post(/api/ask) def ask(req: QueryRequest): # 這里替換為真實 RAG 或 Agent 的調用邏輯 answer rag_answer(req.question) return {answer: answer, request_id: req.user_id}接口層需要額外考慮鑒權方式、請求頻率限制、超時時間、日志結構、錯誤返回格式。不要把模型鏈路直接暴露到公網建議在服務前面加 API 網關統一處理認證和限流。7.2 部署形態的選擇單體服務適合工具函數、接口數量少的內部系統啟動快部署成本低。異步任務隊列適合耗時較長的 Agent 任務如批量文檔處理、多步分析把請求放入隊列后臺 Worker 消費。容器化部署用 Docker 打包應用利用環境變量管理 API Key 和模型地址方便遷移和擴容。部署時需要注意不要把 API Key 寫死在代碼里不同環境的模型名、向量庫地址、切分參數、Prompt 模板要有獨立的配置項發布前要備份可用的上一個配置方便回滾。7.3 質量評測上線前的底線很多項目死在“Demo 效果不錯、上線后效果崩了”原因是沒有評測集。最少準備 30 到 50 組有標準答案的問題覆蓋不同類型的提問方式比如直接提問、模糊提問、跨文檔提問、無答案提問。每次修改 Prompt、切分參數、召回策略后用同一套評測集跑一遍記錄答對數量、未召回數量、錯誤引用數量用數據判斷改動是否正向。評測指標不需要一開始就上完整體系先關注三個正確率答案是否準確、召回率關鍵信息是否出現在答案中、幻覺率是否出現知識庫中不存在的內容。等基礎評測穩定后再逐步引入更細粒度的指標和自動化回歸。7.4 監控與安全線上服務必須能看到“鏈路里發生了什么”。建議至少在三個位置打日志模型調用前后、檢索前后、Agent 的每一步工具調用。日志內容包括請求 ID、耗時、token 消耗、使用的文檔 ID、工具名、入參出參以及異常堆棧。安全方面需要注意用戶輸入可能包含惡意指令需要對輸入長度做限制并過濾敏感內容RAG 涉及企業內部數據時要做好權限隔離Agent 調用外部系統時必須設置操作白名單并對敏感操作做二次確認。8. 學習路線圖一周時間怎么分配結合當前的版本趨勢給出一條偏實踐的學習路線按周為單位規劃時間學習內容產出物第 1 天LangChain 基礎組件能用代碼調用模型理解 Chat、Prompt、Output Parser第 2 天LangChain 文檔處理與切分能加載一個文檔并完成向量化第 3 天RAG 完整鏈路跑通一個帶引用來源的問答 Demo第 4 天Agent 理論基礎與工具封裝實現一個能調用 2 個工具的簡單 Agent第 5 天LangGraph 狀態圖與條件邊用 LangGraph 重構 Agent支持分支和最大步數第 6 天API 封裝與本地化部署把鏈路封裝成 FastAPI 接口做數據評測第 7 天綜合實戰與復盤選一個真實業務場景完成從文檔到接口的全流程這個路線不追求把所有概念都覆蓋核心原則是先跑通鏈路再優化質量再研究高級特性。如果時間緊張優先級是 RAG 大于 AgentLangGraph 大于其他高級技巧因為 RAG 是大多數企業內部知識庫場景的剛需LangGraph 是讓復雜 Agent 可控的基礎。9. 常見問題與排查方法問題現象可能原因排查方式解決方案安裝依賴時 import 報錯包版本不兼容查看pip list中的版本對比報錯信息固定版本號按官方文檔推薦的版本組合安裝模型調用超時網絡不穩定或模型服務響應慢查看超時堆棧測試網絡連接增加超時時間配置重試機制切換更快模型RAG 回答與文檔無關切分不合理或向量模型效果弱打印檢索到的上下文人工核對是否相關調整 chunk_size/chunk_overlap更換 Embedding 模型Agent 反復調用工具不結束缺少最大迭代限制或工具描述不清晰查看日志確認每次工具調用設置最大步數優化工具描述為“何時用、怎么用”LangGraph 編譯報錯圖和狀態定義不一致檢查節點返回字段是否在 State 中聲明統一 State 字段確保節點返回 Key 對齊上線后效果不如 Demo評測樣本不足或 Prompt 過擬合用多組真實問題回歸測試建立評測集分階段調參先穩定檢索再優化生成接口返回慢檢索鏈路耗時或模型推理慢拆解各部分耗時加緩存、換輕量模型、控制上下文長度數據權限泄露風險向量庫未做權限過濾檢查檢索代碼是否按用戶范圍過濾在檢索前增加文檔集合過濾條件排查問題的通用思路是“分段隔離”先確認請求是否到達接口再確認模型是否被調用再確認檢索結果是否準確再確認生成結果是否被 Prompt 影響。逐段打日志問題基本能定位到具體環節。另外要特別提醒網上關于 LangChain 的代碼很多來自不同版本遇到報錯時先看版本號再查官方文檔對應版本的寫法。不要一報錯就懷疑框架能力大多數情況下是參數名或包引入路徑已經變化。10. 總結與下一步這套技術棧最值得投入的不是背誦 API而是理解“組件、狀態、流程、工具、評測”這幾個工程維度。LangChain 幫你把模型接入和文檔處理變簡單LangGraph 幫你把復雜流程變可控Agent 幫你把應用從問答升級成交互式決策RAG 幫你把私有知識安全地帶進生成鏈路。建議最開始先完成三件事用 LangChain 調用一個真實模型用 RAG 跑通一個帶文檔來源的問答接口用 LangGraph 把同一個流程改寫成狀態圖。這三步做完你就已經把最核心的框架思路掌握了。接下來的擴展方向可以是把 RAG 升級成多路召回并加權限過濾把 Agent 接入更多企業工具并加人工審核把應用容器化并接入監控系統。方向不唯一但主線始終是工程化落地。