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