2026/9/2 7:00:35
FEATURED · 精选文章 
简介本资源是面向AI开发工程师与大模型应用实践者的LangChain实战教程聚焦RAG检索增强生成与Agent智能体构建两大核心能力系统解决提示词工程落地难、知识融合不精准、智能体任务编排复杂等实际问题。压缩包共235个文件含121个Python源码涵盖链式调用、工具集成、记忆管理等模块、25个中文提示词模板适配Cursor/VSCode Agent等主流AI编程工具、6个PDF技术文档、8个YAML配置文件及多个BIN二进制索引文件用于RAG向量检索底层数据加载整体22.96MB结构清晰、开箱即用。已有315人学习下载资源提供从基础提示词设计、LangChain框架搭建、RAG知识库构建到多步骤Agent任务编排的完整项目路径并配套可运行的端到端案例代码与中文语境优化的编程Rules说明助力开发者快速复现工业级智能应用。1. 项目缘起从“玩具”到“工具”的RAG与Agent实战之路最近两年大模型的风吹得人眼花缭乱。从最初ChatGPT带来的惊艳到后来各种开源模型百花齐放再到如今RAG检索增强生成和Agent智能体成为技术落地的两大核心范式。我见过太多朋友包括我自己都经历过这样一个阶段兴致勃勃地跟着教程跑通一个“Hello World”级别的Demo感觉大模型无所不能但一旦想把它接入自己的业务数据或者让它完成一个稍微复杂点的自动化流程立刻就傻眼了——幻觉频出、逻辑混乱、成本高昂、难以控制。这中间的鸿沟就是“玩具”与“工具”的区别。这个名为“基于主流的LangChain技术从大模型提示词到实战项目”的实战教程瞄准的正是这个痛点。它不是一个泛泛而谈的概念科普而是一个手把手带你跨越鸿沟的工程化指南。核心路径非常清晰以LangChain这一目前最主流的AI应用开发框架为脚手架从最基础的提示词工程入手逐步构建起具备“记忆”和“推理”能力的RAG知识库系统最终打造出能够自主规划、调用工具、完成复杂任务的智能体Agent。这几乎涵盖了一个AI应用工程师从入门到能独立交付项目所需的核心技能栈。为什么是LangChain因为它抽象得好。它把和大模型交互、管理上下文、调用工具、构建工作流这些繁琐且模式化的操作封装成了清晰、可组合的模块。你不用从零开始写HTTP请求、处理token拼接、管理对话历史而是像搭积木一样用LCELLangChain Expression Language声明式地描述你的AI应用逻辑。这对于快速原型验证和后期维护迭代价值巨大。当然社区里也有LlamaIndex、Semantic Kernel等优秀框架但LangChain的生态目前最为繁荣教程、解决方案和社区支持也最丰富作为学习起点和工程选型风险最低。这个教程的价值在于它试图串联起一条从理论到实践、从单点技术到系统工程的学习链路。你学到的不是孤立的“如何用LangChain查向量数据库”而是“如何设计一个服务于客服场景的、能准确引用产品文档的、并且能自动转接人工的智能问答系统”。后者才是真实世界需要的解决方案。2. 基石构建深入理解提示词工程与LangChain核心抽象在急着搭建RAG和Agent之前我们必须先打好地基。这个地基就是与大模型有效沟通的艺术——提示词工程以及LangChain是如何将这些艺术规范化的。2.1 超越“调参”提示词的系统化设计思维很多人把提示词工程理解为“不断尝试不同问法直到模型给出满意答案”。这效率太低且不可复用。系统化的提示词设计应该像编写一份清晰的软件需求说明书。首先是结构化的提示模板。LangChain的PromptTemplate就是干这个的。一个优秀的提示模板通常包含以下几个部分角色与背景Role Context明确告诉模型它现在是谁在什么背景下工作。例如“你是一位资深Linux系统运维专家擅长以清晰、准确的方式解答问题。”任务指令Task Instruction清晰、无歧义地说明需要模型做什么。使用祈使句如“请根据以下提供的产品手册片段回答用户关于安装步骤的问题。”输入数据Input Data以明确的格式如XML标签、Markdown代码块提供模型完成任务所需的信息。这是RAG的核心即把检索到的相关文档片段放在这里。输出格式Output Format严格规定模型回答的格式。例如“请用JSON格式输出包含‘answer’和‘confidence’两个字段。”这对于后续的程序化处理至关重要。示例Few-Shot Examples对于复杂任务提供一两个输入输出的例子能让模型快速掌握你的意图。在LangChain中你可以这样构建一个复杂的提示模板from langchain.prompts import ChatPromptTemplate, SystemMessagePromptTemplate, HumanMessagePromptTemplate system_template SystemMessagePromptTemplate.from_template( “你是一位专业的{domain}专家。你的回答必须基于提供的上下文信息如果信息不足请明确说‘根据现有信息无法回答’。\n” “上下文\n{context}\n” ) human_template HumanMessagePromptTemplate.from_template(“{question}”) chat_prompt ChatPromptTemplate.from_messages([system_template, human_template]) # 使用 formatted_prompt chat_prompt.format_prompt( domain“金融风控” contextretrieved_docs, question“请评估这笔交易的风险等级。” ).to_messages()这种结构化的方式使得提示词不再是魔法字符串而是一个可维护、可测试的代码组件。其次是思维链Chain-of-Thought, CoT的引导。对于需要多步推理的问题直接在提示词中要求模型“逐步思考”。例如在提示词末尾加上“让我们一步步地推理。首先分析问题中的关键条件其次从上下文中找出相关依据最后综合得出答案。” LangChain甚至提供了Chain的抽象来固化这种多步流程。2.2 LangChain的核心抽象Models, Prompts, Chains, AgentsLangChain通过几个核心抽象降低了AI应用的开发复杂度。Models模型这是与各种大模型交互的抽象层。无论是OpenAI的GPT系列、Anthropic的Claude还是开源的Llama、Qwen你都可以通过统一的接口如ChatOpenAI,ChatOllama进行调用。这带来了巨大的灵活性你可以轻松切换模型供应商或同时使用多个模型。from langchain_openai import ChatOpenAI from langchain_community.llms import Ollama # 使用OpenAI llm_openai ChatOpenAI(model“gpt-4” temperature0) # 使用本地Ollama部署的模型 llm_local Ollama(model“llama3:8b”)Prompts提示词如前所述将提示词模板化、参数化。Chains链这是LangChain的灵魂。一个Chain将多个组件模型、提示词、工具、其他链按顺序组合起来形成一个完整的工作流。最简单的LLMChain就是“提示词 模型”。更复杂的链可以实现检索、总结、判断等一系列操作。from langchain.chains import LLMChain, SequentialChain # 一个简单的链 chain LLMChain(llmllm, promptchat_prompt) result chain.run({“domain”: “科技” “context”: “...” “question”: “...”}) # 顺序链先总结再问答 summary_chain LLMChain(llmllm, promptsummary_prompt, output_key“summary”) qa_chain LLMChain(llmllm, promptqa_prompt, output_key“answer”) overall_chain SequentialChain( chains[summary_chain, qa_chain], input_variables[“text” “question”], output_variables[“summary” “answer”] )Agents智能体智能体是具备“思考-行动-观察”循环能力的Chain。它有一个核心的“大脑”通常是一个大模型一套可供调用的“工具”Tools如搜索、计算、API调用以及一个决定何时使用何种工具的“推理逻辑”。智能体通过分析用户目标自主规划步骤并执行是构建自动化AI助理的关键。理解这些抽象是后续构建RAG和Agent系统的前提。它们就像乐高积木的基础颗粒所有的复杂应用都由它们拼接而成。3. 实战RAG构建一个“真正可用”的知识库问答系统RAG听起来很美用向量数据库存储知识用户提问时检索相关片段连同问题一起送给大模型生成答案。但构建一个生产可用的RAG系统处处是坑。我们一步步来拆解。3.1 文档处理与向量化质量决定天花板RAG系统的上限在数据处理的源头就已经决定了。垃圾进垃圾出。第一步文档加载与切分Loading SplittingLangChain支持PDF、Word、HTML、Markdown、数据库等数十种文档加载器。但加载进来后直接整篇送入向量化是灾难性的。你需要根据文档的语义结构进行智能切分。不要用固定字符数切分这会把一个完整的段落或表格拦腰截断破坏语义。使用递归字符文本分割器RecursiveCharacterTextSplitter这是LangChain提供的利器。它优先按段落、换行符、句号等自然分隔符切分如果切出的片段仍过长再按字符数二次切分。你需要精心调整chunk_size如500-1000字符和chunk_overlap如100-200字符。overlap是关键它能保证上下文的连贯性避免一个问题点刚好落在两个chunk的边界而丢失。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, length_functionlen, separators[“\n\n” “\n” “。” “” “” “ “ “”] ) docs text_splitter.split_documents(loaded_documents)第二步向量嵌入与存储Embedding Storage这是将文本转化为机器可理解形式的核心步骤。嵌入模型Embedding Model的选择OpenAI的text-embedding-3系列效果很好但需付费。开源选择中BAAI/bge-large-zh对于中文文本表现出色thenlper/gte-large是多语言模型的佼佼者。关键是要保持一致性入库和查询时必须使用同一个模型。向量数据库Vector Database选型对于学习和中小项目ChromaDB是首选因为它轻量、无需外部服务、API简单。对于生产环境Qdrant、Weaviate、Milvus提供了更好的性能、可扩展性和管理功能。LangChain为它们都提供了统一的接口。from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings # 或使用开源嵌入 # from langchain_community.embeddings import HuggingFaceEmbeddings embeddings OpenAIEmbeddings(model“text-embedding-3-small”) # 创建并持久化向量库 vectorstore Chroma.from_documents( documentsdocs, embeddingembeddings, persist_directory“./chroma_db” ) vectorstore.persist()3.2 检索策略优化从“找到”到“找对”默认的相似性搜索Similarity Search很多时候不够用。最大边际相关性MMR这是解决“检索结果冗余”问题的利器。比如你问“Python多线程的优缺点”相似性搜索可能返回5篇都详细讲“优点”的文章。MMR会在保证相关性的同时尽量让返回的结果之间差异性最大从而覆盖“优点”和“缺点”等多个方面。retriever vectorstore.as_retriever( search_type“mmr” # 使用MMR search_kwargs{“k”: 6 “fetch_k”: 20} # 先取20个再从中选6个最不重复的 )自查询检索器Self-Query Retriever这是应对复杂查询的“大杀器”。当用户的问题包含过滤条件时例如“2023年之后发布的、关于机器学习的产品公告”单纯的语义搜索无能为力。自查询检索器会先用大模型从问题中提取出查询语句和过滤条件如query:“产品公告 机器学习” filter:“发布时间 2023-01-01”然后用查询语句做语义搜索同时用过滤条件对元数据metadata进行筛选两者结合得到最终结果。这需要你在存储文档时为每个chunk附加结构化的元数据如发布时间、文档类型、作者等。上下文压缩Contextual Compression即使检索到了相关文档里面也可能包含大量无关信息浪费token且干扰模型。上下文压缩检索器会在将文档送给大模型前先用一个轻量级模型或规则对其进行摘要或过滤只保留最相关的部分。3.3 生成与评估闭环迭代检索到文档后就是构造提示词并调用大模型生成答案。这里常用RetrievalQA链它封装了检索问答的流程。from langchain.chains import RetrievalQA qa_chain RetrievalQA.from_chain_type( llmllm, chain_type“stuff” # 最常用的将所有检索到的文档“塞”进提示词 retrieverretriever, return_source_documentsTrue, # 非常重要返回源文档用于评估和溯源 chain_type_kwargs{“prompt”: chat_prompt} # 使用我们之前定义的结构化提示词 ) result qa_chain.invoke({“query”: “用户问题”}) answer result[“result”] source_docs result[“source_documents”] # 查看模型依据了哪些文档如何评估RAG的效果不能只靠人工看。需要建立评估体系检索相关性评估人工或用小模型判断检索出的文档是否与问题相关。答案忠实度评估生成的答案是否严格基于提供的上下文有没有“胡编乱造”幻觉。答案有用性评估答案是否真正解决了用户的问题。 可以使用RAGAS、TruLens等框架进行自动化评估它们提供了上述维度的打分。只有持续评估和优化调整切分策略、检索参数、提示词等你的RAG系统才能越用越聪明。实操心得RAG的“最后一公里”往往是提示词。在提示词中强烈要求模型“严格基于上下文”并“引用原文”能大幅减少幻觉。同时一定要保留并展示source_documents这不仅是为了可解释性当用户质疑时你能快速定位是检索错了还是模型理解错了。4. 智能体进阶让AI学会使用工具与自主规划如果说RAG是给大模型“开卷考”那么Agent就是让大模型拥有了“手和脚”可以与环境交互。LangChain提供了多种Agent类型适应不同场景。4.1 工具Tools的定义与封装工具是智能体能力的延伸。任何可以被API调用的功能都可以封装成工具。from langchain.tools import tool from datetime import datetime tool def get_current_time(timezone: str “Asia/Shanghai”) - str: “”“获取指定时区的当前时间。参数timezone是时区字符串如‘Asia/Shanghai’。”“” # 这里是工具的实现逻辑 now datetime.now(pytz.timezone(timezone)) return now.strftime(“%Y-%m-%d %H:%M:%S”) # 更复杂的工具调用外部API from langchain.tools import StructuredTool import requests def search_weather(city: str) - dict: response requests.get(f“https://api.weather.com/v1/city?name{city}”) return response.json() weather_tool StructuredTool.from_function( funcsearch_weather, name“WeatherSearch” description“根据城市名称查询实时天气信息。” )定义工具时名称name和描述description至关重要。智能体的大脑LLM就是根据这些描述来决定是否以及如何调用工具的。描述要清晰、准确说明输入输出。4.2 智能体类型与执行流程LangChain的AgentExecutor是运行智能体的核心。它管理着“思考-行动-观察”的循环。零样本智能体Zero-shot Agent这是最常用的一种。你给它一套工具和一个目标它不需要示例自己决定行动计划。它使用ReActReasoning Acting框架在思考过程中会输出“Thought:”、“Action:”、“Observation:”这样的逻辑链。from langchain.agents import create_react_agent, AgentExecutor from langchain import hub # 从LangChain Hub拉取一个优化过的ReAct提示词 prompt hub.pull(“hwchase17/react”) tools [get_current_time, weather_tool] llm ChatOpenAI(model“gpt-4” temperature0) agent create_react_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) result agent_executor.invoke({“input”: “上海现在几点了如果天气好我该穿什么”})这个智能体会先思考需要知道上海的时间调用get_current_time工具得到时间后再思考需要知道上海的天气调用WeatherSearch工具最后综合两个信息给出穿衣建议。对话智能体Conversational Agent在零样本智能体的基础上增加了记忆功能能记住整个对话历史。这对于多轮交互的聊天机器人场景是必须的。from langchain.memory import ConversationBufferMemory memory ConversationBufferMemory(memory_key“chat_history” return_messagesTrue) agent_executor AgentExecutor.from_agent_and_tools( agentagent, toolstools, memorymemory, verboseTrue ) # 现在它可以进行连贯的多轮对话了规划与执行智能体Plan-and-Execute Agent对于极其复杂的任务让一个模型同时负责规划和执行可能力不从心。这种架构使用一个“规划器”模型通常是大模型来制定高级计划如“第一步搜索资料第二步总结要点第三步生成报告”然后由一个“执行器”模型可以是另一个大模型或一系列链/工具来具体执行每个步骤。这更接近人类的复杂任务处理方式。LangGraphLangChain的新库特别适合构建这种有状态、多参与者的工作流。4.3 避坑指南智能体开发的常见陷阱智能体开发令人兴奋但也容易失控。陷阱一无限循环或无效调用。智能体可能陷入“思考-调用-得到结果-再次思考-再次调用同一工具”的死循环。解决方案在AgentExecutor中设置max_iterations最大迭代次数如10和early_stopping_method提前停止方法。同时优化工具的描述使其更精确。陷阱二工具参数解析错误。大模型可能误解你的指令生成不符合工具函数签名的参数。解决方案使用StructuredTool并配合Pydantic模型来严格定义输入参数的类型和结构LangChain内置的解析器会强制模型输出合规的JSON。陷阱三成本与延迟。每一次工具调用和模型思考都需要消耗token和时间。解决方案对于简单、确定性的任务优先用普通的Chain而不是Agent。在Agent中使用更小、更快的模型如GPT-3.5-turbo作为“思考大脑”只在必要时才调用GPT-4。陷阱四安全性。智能体可以调用任何你赋予它的工具包括删除文件、发送邮件的工具。解决方案在工具层面实现严格的权限检查和输入验证。永远不要赋予智能体超出其任务范围的权限。个人经验在正式让智能体处理真实任务前先用一个“沙盒环境”进行大量测试。记录下它所有的“Thought”和“Action”分析其推理链条中的薄弱环节。很多时候问题不是出在工具上而是出在提示词没有给智能体足够的约束或引导。反复迭代提示词是驯服智能体的关键。5. 项目实战从零搭建一个技术文档智能助手理论说得再多不如动手做一个。我们以“搭建一个公司内部技术文档的智能问答助手”为目标串联起前面所有知识点。这个项目将包含RAG知识库和任务型智能体。5.1 系统架构与技术选型我们的助手需要完成两类任务1基于技术文档的问答RAG2执行简单自动化任务如创建JIRA工单、查询服务器状态Agent。架构如下前端简单的Streamlit或Gradio Web界面用于交互。后端核心Python LangChain文档处理管道使用Unstructured库加载多种格式文档用RecursiveCharacterTextSplitter切分。向量数据库使用ChromaDB开发环境或Qdrant生产环境嵌入模型选用BAAI/bge-large-zh-v1.5。大模型对话和智能体推理使用GPT-4或Claude 3 Sonnet追求效果RAG的生成部分可尝试使用GPT-3.5-turbo平衡成本与效果。本地化选项可用Ollama部署Qwen-14B-Chat。智能体工具集封装查询内部员工目录API、创建Confluence页面草稿、检查CI/CD流水线状态等工具。部署使用Docker容器化通过FastAPI提供标准化API接口。5.2 分模块实现详解模块一知识库构建与更新这不是一次性任务。我们需要一个持续更新的管道。# pipeline.py import os from langchain_community.document_loaders import DirectoryLoader, UnstructuredFileLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma class KnowledgeBasePipeline: def __init__(self, data_dir, persist_dir): self.data_dir data_dir self.persist_dir persist_dir self.embeddings HuggingFaceEmbeddings( model_name“BAAI/bge-large-zh-v1.5” model_kwargs{‘device’: ‘cuda’}, # 如果有GPU encode_kwargs{‘normalize_embeddings’: True} # 标准化提升检索效果 ) self.text_splitter RecursiveCharacterTextSplitter(...) def load_and_split(self): “”“加载并切分所有文档”“” all_docs [] for file_path in os.listdir(self.data_dir): loader UnstructuredFileLoader(os.path.join(self.data_dir, file_path)) docs loader.load() # 为每个文档片段添加元数据如来源文件 for doc in docs: doc.metadata[“source”] file_path split_docs self.text_splitter.split_documents(docs) all_docs.extend(split_docs) return all_docs def create_or_update_vectorstore(self, docs): “”“创建或更新向量存储。增量更新是生产环境关键。”“” # 检查是否已存在向量库 if os.path.exists(self.persist_dir): # 增量更新模式将新文档添加到现有库 vectorstore Chroma( persist_directoryself.persist_dir, embedding_functionself.embeddings ) vectorstore.add_documents(docs) else: # 全新创建 vectorstore Chroma.from_documents( documentsdocs, embeddingself.embeddings, persist_directoryself.persist_dir ) vectorstore.persist() return vectorstore # 使用可以配置成定时任务或由文件系统事件触发 pipeline KnowledgeBasePipeline(“./tech_docs” “./chroma_db”) docs pipeline.load_and_split() vectorstore pipeline.create_or_update_vectorstore(docs)模块二混合型智能体的构建我们的助手需要判断用户意图是问文档问题还是执行任务# assistant_agent.py from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain.tools.retriever import create_retriever_tool from langchain import hub from .tools import jira_tool, confluence_tool, server_status_tool # 自定义的工具 class HybridAssistant: def __init__(self, vectorstore): self.llm ChatOpenAI(model“gpt-4” temperature0.1) # 1. 将RAG检索器包装成一个“工具” retriever vectorstore.as_retriever(search_kwargs{“k”: 4}) rag_tool create_retriever_tool( retriever, “search_technical_docs” “当用户询问关于产品、API、错误代码、配置等具体技术问题时使用此工具搜索内部技术文档。输入应该是清晰的问题关键词。” ) # 2. 定义工具集 self.tools [rag_tool, jira_tool, confluence_tool, server_status_tool] # 3. 使用一个强大的提示词来引导智能体做意图判断 prompt hub.pull(“hwchase17/openai-tools-agent”) # 修改提示词加入我们的系统指令 prompt.messages[0].prompt.template “““你是一个技术文档助手和自动化助手。请遵循以下规则 1. 如果用户的问题是具体的技术问题关于如何使用、配置、错误排查等请务必使用‘search_technical_docs’工具查找文档来回答。 2. 如果用户的问题是请求执行一个任务如创建任务、查询状态等请使用相应的工具。 3. 你的回答必须基于工具返回的事实信息不要编造。 4. 如果工具返回的信息不足请如实告知用户。 ”“” prompt.messages[0].prompt.template agent create_openai_tools_agent(self.llm, self.tools, prompt) self.agent_executor AgentExecutor( agentagent, toolsself.tools, verboseTrue, max_iterations5, handle_parsing_errorsTrue ) def ask(self, question, chat_historyNone): “”“处理用户提问”“” input_dict {“input”: question} if chat_history: input_dict[“chat_history”] chat_history result self.agent_executor.invoke(input_dict) return result[“output”]这个设计的关键在于我们将RAG系统也封装成了一个“工具”。智能体根据提示词中的规则自行判断用户意图是“查询知识”还是“执行任务”从而决定调用哪个工具。这实现了问答与自动化的统一入口。5.3 部署、监控与迭代部署使用FastAPI将上述核心类包装成REST API前端通过调用API进行交互。用Docker打包应用和模型依赖确保环境一致性。监控这是项目上线的重中之重。你需要记录每次问答的完整链路用户问题、检索到的文档及得分、智能体的思考过程、调用的工具、最终答案。性能指标响应延迟、token消耗、各环节耗时。用户反馈提供“回答是否有用”的点赞/点踩按钮。迭代基于监控数据和用户反馈持续优化检索优化如果某些问题总是检索不到正确文档检查文档切分是否合理考虑引入MMR或自查询检索器。提示词优化如果答案出现幻觉或格式错误调整系统提示词加入更严格的约束和示例。工具优化如果智能体频繁错误调用工具优化工具的描述使其更精准。模型优化对于成本敏感的场景尝试用更小、更快的模型如GPT-3.5-turbo承担部分工作或者探索本地化部署的高质量开源模型。这个项目麻雀虽小五脏俱全。完成它你不仅学会了LangChain的API调用更掌握了构建一个完整、可运维的AI应用所必需的工程化思维。从数据处理、服务构建到评估迭代这正是一个AI应用从原型走向产品必须经历的全过程。本文还有配套的精品资源点击获取
LangChain实战：从提示词工程到RAG与Agent系统构建
简介本资源是面向AI开发工程师与大模型应用实践者的LangChain实战教程聚焦RAG检索增强生成与Agent智能体构建两大核心能力系统解决提示词工程落地难、知识融合不精准、智能体任务编排复杂等实际问题。压缩包共235个文件含121个Python源码涵盖链式调用、工具集成、记忆管理等模块、25个中文提示词模板适配Cursor/VSCode Agent等主流AI编程工具、6个PDF技术文档、8个YAML配置文件及多个BIN二进制索引文件用于RAG向量检索底层数据加载整体22.96MB结构清晰、开箱即用。已有315人学习下载资源提供从基础提示词设计、LangChain框架搭建、RAG知识库构建到多步骤Agent任务编排的完整项目路径并配套可运行的端到端案例代码与中文语境优化的编程Rules说明助力开发者快速复现工业级智能应用。1. 项目缘起从“玩具”到“工具”的RAG与Agent实战之路最近两年大模型的风吹得人眼花缭乱。从最初ChatGPT带来的惊艳到后来各种开源模型百花齐放再到如今RAG检索增强生成和Agent智能体成为技术落地的两大核心范式。我见过太多朋友包括我自己都经历过这样一个阶段兴致勃勃地跟着教程跑通一个“Hello World”级别的Demo感觉大模型无所不能但一旦想把它接入自己的业务数据或者让它完成一个稍微复杂点的自动化流程立刻就傻眼了——幻觉频出、逻辑混乱、成本高昂、难以控制。这中间的鸿沟就是“玩具”与“工具”的区别。这个名为“基于主流的LangChain技术从大模型提示词到实战项目”的实战教程瞄准的正是这个痛点。它不是一个泛泛而谈的概念科普而是一个手把手带你跨越鸿沟的工程化指南。核心路径非常清晰以LangChain这一目前最主流的AI应用开发框架为脚手架从最基础的提示词工程入手逐步构建起具备“记忆”和“推理”能力的RAG知识库系统最终打造出能够自主规划、调用工具、完成复杂任务的智能体Agent。这几乎涵盖了一个AI应用工程师从入门到能独立交付项目所需的核心技能栈。为什么是LangChain因为它抽象得好。它把和大模型交互、管理上下文、调用工具、构建工作流这些繁琐且模式化的操作封装成了清晰、可组合的模块。你不用从零开始写HTTP请求、处理token拼接、管理对话历史而是像搭积木一样用LCELLangChain Expression Language声明式地描述你的AI应用逻辑。这对于快速原型验证和后期维护迭代价值巨大。当然社区里也有LlamaIndex、Semantic Kernel等优秀框架但LangChain的生态目前最为繁荣教程、解决方案和社区支持也最丰富作为学习起点和工程选型风险最低。这个教程的价值在于它试图串联起一条从理论到实践、从单点技术到系统工程的学习链路。你学到的不是孤立的“如何用LangChain查向量数据库”而是“如何设计一个服务于客服场景的、能准确引用产品文档的、并且能自动转接人工的智能问答系统”。后者才是真实世界需要的解决方案。2. 基石构建深入理解提示词工程与LangChain核心抽象在急着搭建RAG和Agent之前我们必须先打好地基。这个地基就是与大模型有效沟通的艺术——提示词工程以及LangChain是如何将这些艺术规范化的。2.1 超越“调参”提示词的系统化设计思维很多人把提示词工程理解为“不断尝试不同问法直到模型给出满意答案”。这效率太低且不可复用。系统化的提示词设计应该像编写一份清晰的软件需求说明书。首先是结构化的提示模板。LangChain的PromptTemplate就是干这个的。一个优秀的提示模板通常包含以下几个部分角色与背景Role Context明确告诉模型它现在是谁在什么背景下工作。例如“你是一位资深Linux系统运维专家擅长以清晰、准确的方式解答问题。”任务指令Task Instruction清晰、无歧义地说明需要模型做什么。使用祈使句如“请根据以下提供的产品手册片段回答用户关于安装步骤的问题。”输入数据Input Data以明确的格式如XML标签、Markdown代码块提供模型完成任务所需的信息。这是RAG的核心即把检索到的相关文档片段放在这里。输出格式Output Format严格规定模型回答的格式。例如“请用JSON格式输出包含‘answer’和‘confidence’两个字段。”这对于后续的程序化处理至关重要。示例Few-Shot Examples对于复杂任务提供一两个输入输出的例子能让模型快速掌握你的意图。在LangChain中你可以这样构建一个复杂的提示模板from langchain.prompts import ChatPromptTemplate, SystemMessagePromptTemplate, HumanMessagePromptTemplate system_template SystemMessagePromptTemplate.from_template( “你是一位专业的{domain}专家。你的回答必须基于提供的上下文信息如果信息不足请明确说‘根据现有信息无法回答’。\n” “上下文\n{context}\n” ) human_template HumanMessagePromptTemplate.from_template(“{question}”) chat_prompt ChatPromptTemplate.from_messages([system_template, human_template]) # 使用 formatted_prompt chat_prompt.format_prompt( domain“金融风控” contextretrieved_docs, question“请评估这笔交易的风险等级。” ).to_messages()这种结构化的方式使得提示词不再是魔法字符串而是一个可维护、可测试的代码组件。其次是思维链Chain-of-Thought, CoT的引导。对于需要多步推理的问题直接在提示词中要求模型“逐步思考”。例如在提示词末尾加上“让我们一步步地推理。首先分析问题中的关键条件其次从上下文中找出相关依据最后综合得出答案。” LangChain甚至提供了Chain的抽象来固化这种多步流程。2.2 LangChain的核心抽象Models, Prompts, Chains, AgentsLangChain通过几个核心抽象降低了AI应用的开发复杂度。Models模型这是与各种大模型交互的抽象层。无论是OpenAI的GPT系列、Anthropic的Claude还是开源的Llama、Qwen你都可以通过统一的接口如ChatOpenAI,ChatOllama进行调用。这带来了巨大的灵活性你可以轻松切换模型供应商或同时使用多个模型。from langchain_openai import ChatOpenAI from langchain_community.llms import Ollama # 使用OpenAI llm_openai ChatOpenAI(model“gpt-4” temperature0) # 使用本地Ollama部署的模型 llm_local Ollama(model“llama3:8b”)Prompts提示词如前所述将提示词模板化、参数化。Chains链这是LangChain的灵魂。一个Chain将多个组件模型、提示词、工具、其他链按顺序组合起来形成一个完整的工作流。最简单的LLMChain就是“提示词 模型”。更复杂的链可以实现检索、总结、判断等一系列操作。from langchain.chains import LLMChain, SequentialChain # 一个简单的链 chain LLMChain(llmllm, promptchat_prompt) result chain.run({“domain”: “科技” “context”: “...” “question”: “...”}) # 顺序链先总结再问答 summary_chain LLMChain(llmllm, promptsummary_prompt, output_key“summary”) qa_chain LLMChain(llmllm, promptqa_prompt, output_key“answer”) overall_chain SequentialChain( chains[summary_chain, qa_chain], input_variables[“text” “question”], output_variables[“summary” “answer”] )Agents智能体智能体是具备“思考-行动-观察”循环能力的Chain。它有一个核心的“大脑”通常是一个大模型一套可供调用的“工具”Tools如搜索、计算、API调用以及一个决定何时使用何种工具的“推理逻辑”。智能体通过分析用户目标自主规划步骤并执行是构建自动化AI助理的关键。理解这些抽象是后续构建RAG和Agent系统的前提。它们就像乐高积木的基础颗粒所有的复杂应用都由它们拼接而成。3. 实战RAG构建一个“真正可用”的知识库问答系统RAG听起来很美用向量数据库存储知识用户提问时检索相关片段连同问题一起送给大模型生成答案。但构建一个生产可用的RAG系统处处是坑。我们一步步来拆解。3.1 文档处理与向量化质量决定天花板RAG系统的上限在数据处理的源头就已经决定了。垃圾进垃圾出。第一步文档加载与切分Loading SplittingLangChain支持PDF、Word、HTML、Markdown、数据库等数十种文档加载器。但加载进来后直接整篇送入向量化是灾难性的。你需要根据文档的语义结构进行智能切分。不要用固定字符数切分这会把一个完整的段落或表格拦腰截断破坏语义。使用递归字符文本分割器RecursiveCharacterTextSplitter这是LangChain提供的利器。它优先按段落、换行符、句号等自然分隔符切分如果切出的片段仍过长再按字符数二次切分。你需要精心调整chunk_size如500-1000字符和chunk_overlap如100-200字符。overlap是关键它能保证上下文的连贯性避免一个问题点刚好落在两个chunk的边界而丢失。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, length_functionlen, separators[“\n\n” “\n” “。” “” “” “ “ “”] ) docs text_splitter.split_documents(loaded_documents)第二步向量嵌入与存储Embedding Storage这是将文本转化为机器可理解形式的核心步骤。嵌入模型Embedding Model的选择OpenAI的text-embedding-3系列效果很好但需付费。开源选择中BAAI/bge-large-zh对于中文文本表现出色thenlper/gte-large是多语言模型的佼佼者。关键是要保持一致性入库和查询时必须使用同一个模型。向量数据库Vector Database选型对于学习和中小项目ChromaDB是首选因为它轻量、无需外部服务、API简单。对于生产环境Qdrant、Weaviate、Milvus提供了更好的性能、可扩展性和管理功能。LangChain为它们都提供了统一的接口。from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings # 或使用开源嵌入 # from langchain_community.embeddings import HuggingFaceEmbeddings embeddings OpenAIEmbeddings(model“text-embedding-3-small”) # 创建并持久化向量库 vectorstore Chroma.from_documents( documentsdocs, embeddingembeddings, persist_directory“./chroma_db” ) vectorstore.persist()3.2 检索策略优化从“找到”到“找对”默认的相似性搜索Similarity Search很多时候不够用。最大边际相关性MMR这是解决“检索结果冗余”问题的利器。比如你问“Python多线程的优缺点”相似性搜索可能返回5篇都详细讲“优点”的文章。MMR会在保证相关性的同时尽量让返回的结果之间差异性最大从而覆盖“优点”和“缺点”等多个方面。retriever vectorstore.as_retriever( search_type“mmr” # 使用MMR search_kwargs{“k”: 6 “fetch_k”: 20} # 先取20个再从中选6个最不重复的 )自查询检索器Self-Query Retriever这是应对复杂查询的“大杀器”。当用户的问题包含过滤条件时例如“2023年之后发布的、关于机器学习的产品公告”单纯的语义搜索无能为力。自查询检索器会先用大模型从问题中提取出查询语句和过滤条件如query:“产品公告 机器学习” filter:“发布时间 2023-01-01”然后用查询语句做语义搜索同时用过滤条件对元数据metadata进行筛选两者结合得到最终结果。这需要你在存储文档时为每个chunk附加结构化的元数据如发布时间、文档类型、作者等。上下文压缩Contextual Compression即使检索到了相关文档里面也可能包含大量无关信息浪费token且干扰模型。上下文压缩检索器会在将文档送给大模型前先用一个轻量级模型或规则对其进行摘要或过滤只保留最相关的部分。3.3 生成与评估闭环迭代检索到文档后就是构造提示词并调用大模型生成答案。这里常用RetrievalQA链它封装了检索问答的流程。from langchain.chains import RetrievalQA qa_chain RetrievalQA.from_chain_type( llmllm, chain_type“stuff” # 最常用的将所有检索到的文档“塞”进提示词 retrieverretriever, return_source_documentsTrue, # 非常重要返回源文档用于评估和溯源 chain_type_kwargs{“prompt”: chat_prompt} # 使用我们之前定义的结构化提示词 ) result qa_chain.invoke({“query”: “用户问题”}) answer result[“result”] source_docs result[“source_documents”] # 查看模型依据了哪些文档如何评估RAG的效果不能只靠人工看。需要建立评估体系检索相关性评估人工或用小模型判断检索出的文档是否与问题相关。答案忠实度评估生成的答案是否严格基于提供的上下文有没有“胡编乱造”幻觉。答案有用性评估答案是否真正解决了用户的问题。 可以使用RAGAS、TruLens等框架进行自动化评估它们提供了上述维度的打分。只有持续评估和优化调整切分策略、检索参数、提示词等你的RAG系统才能越用越聪明。实操心得RAG的“最后一公里”往往是提示词。在提示词中强烈要求模型“严格基于上下文”并“引用原文”能大幅减少幻觉。同时一定要保留并展示source_documents这不仅是为了可解释性当用户质疑时你能快速定位是检索错了还是模型理解错了。4. 智能体进阶让AI学会使用工具与自主规划如果说RAG是给大模型“开卷考”那么Agent就是让大模型拥有了“手和脚”可以与环境交互。LangChain提供了多种Agent类型适应不同场景。4.1 工具Tools的定义与封装工具是智能体能力的延伸。任何可以被API调用的功能都可以封装成工具。from langchain.tools import tool from datetime import datetime tool def get_current_time(timezone: str “Asia/Shanghai”) - str: “”“获取指定时区的当前时间。参数timezone是时区字符串如‘Asia/Shanghai’。”“” # 这里是工具的实现逻辑 now datetime.now(pytz.timezone(timezone)) return now.strftime(“%Y-%m-%d %H:%M:%S”) # 更复杂的工具调用外部API from langchain.tools import StructuredTool import requests def search_weather(city: str) - dict: response requests.get(f“https://api.weather.com/v1/city?name{city}”) return response.json() weather_tool StructuredTool.from_function( funcsearch_weather, name“WeatherSearch” description“根据城市名称查询实时天气信息。” )定义工具时名称name和描述description至关重要。智能体的大脑LLM就是根据这些描述来决定是否以及如何调用工具的。描述要清晰、准确说明输入输出。4.2 智能体类型与执行流程LangChain的AgentExecutor是运行智能体的核心。它管理着“思考-行动-观察”的循环。零样本智能体Zero-shot Agent这是最常用的一种。你给它一套工具和一个目标它不需要示例自己决定行动计划。它使用ReActReasoning Acting框架在思考过程中会输出“Thought:”、“Action:”、“Observation:”这样的逻辑链。from langchain.agents import create_react_agent, AgentExecutor from langchain import hub # 从LangChain Hub拉取一个优化过的ReAct提示词 prompt hub.pull(“hwchase17/react”) tools [get_current_time, weather_tool] llm ChatOpenAI(model“gpt-4” temperature0) agent create_react_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) result agent_executor.invoke({“input”: “上海现在几点了如果天气好我该穿什么”})这个智能体会先思考需要知道上海的时间调用get_current_time工具得到时间后再思考需要知道上海的天气调用WeatherSearch工具最后综合两个信息给出穿衣建议。对话智能体Conversational Agent在零样本智能体的基础上增加了记忆功能能记住整个对话历史。这对于多轮交互的聊天机器人场景是必须的。from langchain.memory import ConversationBufferMemory memory ConversationBufferMemory(memory_key“chat_history” return_messagesTrue) agent_executor AgentExecutor.from_agent_and_tools( agentagent, toolstools, memorymemory, verboseTrue ) # 现在它可以进行连贯的多轮对话了规划与执行智能体Plan-and-Execute Agent对于极其复杂的任务让一个模型同时负责规划和执行可能力不从心。这种架构使用一个“规划器”模型通常是大模型来制定高级计划如“第一步搜索资料第二步总结要点第三步生成报告”然后由一个“执行器”模型可以是另一个大模型或一系列链/工具来具体执行每个步骤。这更接近人类的复杂任务处理方式。LangGraphLangChain的新库特别适合构建这种有状态、多参与者的工作流。4.3 避坑指南智能体开发的常见陷阱智能体开发令人兴奋但也容易失控。陷阱一无限循环或无效调用。智能体可能陷入“思考-调用-得到结果-再次思考-再次调用同一工具”的死循环。解决方案在AgentExecutor中设置max_iterations最大迭代次数如10和early_stopping_method提前停止方法。同时优化工具的描述使其更精确。陷阱二工具参数解析错误。大模型可能误解你的指令生成不符合工具函数签名的参数。解决方案使用StructuredTool并配合Pydantic模型来严格定义输入参数的类型和结构LangChain内置的解析器会强制模型输出合规的JSON。陷阱三成本与延迟。每一次工具调用和模型思考都需要消耗token和时间。解决方案对于简单、确定性的任务优先用普通的Chain而不是Agent。在Agent中使用更小、更快的模型如GPT-3.5-turbo作为“思考大脑”只在必要时才调用GPT-4。陷阱四安全性。智能体可以调用任何你赋予它的工具包括删除文件、发送邮件的工具。解决方案在工具层面实现严格的权限检查和输入验证。永远不要赋予智能体超出其任务范围的权限。个人经验在正式让智能体处理真实任务前先用一个“沙盒环境”进行大量测试。记录下它所有的“Thought”和“Action”分析其推理链条中的薄弱环节。很多时候问题不是出在工具上而是出在提示词没有给智能体足够的约束或引导。反复迭代提示词是驯服智能体的关键。5. 项目实战从零搭建一个技术文档智能助手理论说得再多不如动手做一个。我们以“搭建一个公司内部技术文档的智能问答助手”为目标串联起前面所有知识点。这个项目将包含RAG知识库和任务型智能体。5.1 系统架构与技术选型我们的助手需要完成两类任务1基于技术文档的问答RAG2执行简单自动化任务如创建JIRA工单、查询服务器状态Agent。架构如下前端简单的Streamlit或Gradio Web界面用于交互。后端核心Python LangChain文档处理管道使用Unstructured库加载多种格式文档用RecursiveCharacterTextSplitter切分。向量数据库使用ChromaDB开发环境或Qdrant生产环境嵌入模型选用BAAI/bge-large-zh-v1.5。大模型对话和智能体推理使用GPT-4或Claude 3 Sonnet追求效果RAG的生成部分可尝试使用GPT-3.5-turbo平衡成本与效果。本地化选项可用Ollama部署Qwen-14B-Chat。智能体工具集封装查询内部员工目录API、创建Confluence页面草稿、检查CI/CD流水线状态等工具。部署使用Docker容器化通过FastAPI提供标准化API接口。5.2 分模块实现详解模块一知识库构建与更新这不是一次性任务。我们需要一个持续更新的管道。# pipeline.py import os from langchain_community.document_loaders import DirectoryLoader, UnstructuredFileLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma class KnowledgeBasePipeline: def __init__(self, data_dir, persist_dir): self.data_dir data_dir self.persist_dir persist_dir self.embeddings HuggingFaceEmbeddings( model_name“BAAI/bge-large-zh-v1.5” model_kwargs{‘device’: ‘cuda’}, # 如果有GPU encode_kwargs{‘normalize_embeddings’: True} # 标准化提升检索效果 ) self.text_splitter RecursiveCharacterTextSplitter(...) def load_and_split(self): “”“加载并切分所有文档”“” all_docs [] for file_path in os.listdir(self.data_dir): loader UnstructuredFileLoader(os.path.join(self.data_dir, file_path)) docs loader.load() # 为每个文档片段添加元数据如来源文件 for doc in docs: doc.metadata[“source”] file_path split_docs self.text_splitter.split_documents(docs) all_docs.extend(split_docs) return all_docs def create_or_update_vectorstore(self, docs): “”“创建或更新向量存储。增量更新是生产环境关键。”“” # 检查是否已存在向量库 if os.path.exists(self.persist_dir): # 增量更新模式将新文档添加到现有库 vectorstore Chroma( persist_directoryself.persist_dir, embedding_functionself.embeddings ) vectorstore.add_documents(docs) else: # 全新创建 vectorstore Chroma.from_documents( documentsdocs, embeddingself.embeddings, persist_directoryself.persist_dir ) vectorstore.persist() return vectorstore # 使用可以配置成定时任务或由文件系统事件触发 pipeline KnowledgeBasePipeline(“./tech_docs” “./chroma_db”) docs pipeline.load_and_split() vectorstore pipeline.create_or_update_vectorstore(docs)模块二混合型智能体的构建我们的助手需要判断用户意图是问文档问题还是执行任务# assistant_agent.py from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain.tools.retriever import create_retriever_tool from langchain import hub from .tools import jira_tool, confluence_tool, server_status_tool # 自定义的工具 class HybridAssistant: def __init__(self, vectorstore): self.llm ChatOpenAI(model“gpt-4” temperature0.1) # 1. 将RAG检索器包装成一个“工具” retriever vectorstore.as_retriever(search_kwargs{“k”: 4}) rag_tool create_retriever_tool( retriever, “search_technical_docs” “当用户询问关于产品、API、错误代码、配置等具体技术问题时使用此工具搜索内部技术文档。输入应该是清晰的问题关键词。” ) # 2. 定义工具集 self.tools [rag_tool, jira_tool, confluence_tool, server_status_tool] # 3. 使用一个强大的提示词来引导智能体做意图判断 prompt hub.pull(“hwchase17/openai-tools-agent”) # 修改提示词加入我们的系统指令 prompt.messages[0].prompt.template “““你是一个技术文档助手和自动化助手。请遵循以下规则 1. 如果用户的问题是具体的技术问题关于如何使用、配置、错误排查等请务必使用‘search_technical_docs’工具查找文档来回答。 2. 如果用户的问题是请求执行一个任务如创建任务、查询状态等请使用相应的工具。 3. 你的回答必须基于工具返回的事实信息不要编造。 4. 如果工具返回的信息不足请如实告知用户。 ”“” prompt.messages[0].prompt.template agent create_openai_tools_agent(self.llm, self.tools, prompt) self.agent_executor AgentExecutor( agentagent, toolsself.tools, verboseTrue, max_iterations5, handle_parsing_errorsTrue ) def ask(self, question, chat_historyNone): “”“处理用户提问”“” input_dict {“input”: question} if chat_history: input_dict[“chat_history”] chat_history result self.agent_executor.invoke(input_dict) return result[“output”]这个设计的关键在于我们将RAG系统也封装成了一个“工具”。智能体根据提示词中的规则自行判断用户意图是“查询知识”还是“执行任务”从而决定调用哪个工具。这实现了问答与自动化的统一入口。5.3 部署、监控与迭代部署使用FastAPI将上述核心类包装成REST API前端通过调用API进行交互。用Docker打包应用和模型依赖确保环境一致性。监控这是项目上线的重中之重。你需要记录每次问答的完整链路用户问题、检索到的文档及得分、智能体的思考过程、调用的工具、最终答案。性能指标响应延迟、token消耗、各环节耗时。用户反馈提供“回答是否有用”的点赞/点踩按钮。迭代基于监控数据和用户反馈持续优化检索优化如果某些问题总是检索不到正确文档检查文档切分是否合理考虑引入MMR或自查询检索器。提示词优化如果答案出现幻觉或格式错误调整系统提示词加入更严格的约束和示例。工具优化如果智能体频繁错误调用工具优化工具的描述使其更精准。模型优化对于成本敏感的场景尝试用更小、更快的模型如GPT-3.5-turbo承担部分工作或者探索本地化部署的高质量开源模型。这个项目麻雀虽小五脏俱全。完成它你不仅学会了LangChain的API调用更掌握了构建一个完整、可运维的AI应用所必需的工程化思维。从数据处理、服务构建到评估迭代这正是一个AI应用从原型走向产品必须经历的全过程。本文还有配套的精品资源点击获取 
