最近在整理团队的技术栈发现一个挺有意思的现象很多同事在接触大模型应用开发时第一反应就是去搜“LangChain教程”。但跟着教程跑通几个Demo后真正要往项目里集成或者处理稍微复杂一点的业务逻辑时又卡住了。要么是Agent调用工具时状态混乱要么是RAG检索的结果总是不尽人意再或者想把多个步骤串联起来时发现代码成了一团乱麻。这其实不怪大家。市面上很多教程包括一些所谓的“速成课”往往只展示了LangChain最光鲜、最“一键生成”的那一面。它们告诉你“用这几行代码就能调用大模型”却很少深入讲清楚为什么需要AgentRAG的“检索-增强-生成”三个环节各自的难点和调优点在哪里当LangGraph出现后它和LangChain的核心区别是什么我们又该如何选择今天我们不追求“一周学完”的速成神话而是尝试换一个思路把LangChain及其生态Agent、RAG、MCP、LangGraph看作一套解决特定问题的“工具箱”和“设计模式”。我们的目标不是记住所有API而是理解每个工具解决什么核心问题它们的边界在哪里以及如何组合起来应对真实的企业级场景。这样或许才能真正“吃透”少走那些在项目后期才会暴露的弯路。1. 重新理解LangChain它不只是“大模型调用库”很多人对LangChain的第一印象是“一个让调用大模型变得更简单的Python库”。这个理解没错但太浅了。如果仅仅是为了调用ChatGPT或文心一言的API直接用requests库或者官方的SDK可能更直接。LangChain真正的价值在于它定义了一套构建基于大模型的应用程序的框架和范式。1.1 核心价值从“一次对话”到“可编排的工作流”想象一下如果没有LangChain你要实现一个“根据用户问题查询数据库再结合查询结果生成报告”的功能可能需要手动拼接用户问题和系统提示。调用大模型API解析返回的JSON。判断返回内容是否需要调用工具比如搜索数据库。如果需要再编写数据库查询逻辑获取结果。将查询结果再次拼接到提示词中重新调用大模型。处理可能出现的错误、重试、超时等问题。这个过程充满了胶水代码且难以复用和调试。LangChain的出现就是把上述步骤中的通用模式抽象出来变成了LLMChain、Tool、AgentExecutor、Memory等组件。它让你从关心“每一步怎么实现”转向关心“整个工作流如何设计”。所以学习LangChain的第一步不是背API而是理解几个核心抽象Chain链将多个组件如提示词模板、大模型、输出解析器按顺序组合起来。这是最基本的工作单元。Agent智能体一个具备“思考-行动-观察”循环的Chain。它可以根据大模型的推理动态决定下一步是调用工具还是直接给出答案。Tool工具Agent可以调用的函数如搜索、计算、查询API等。这是大模型与外部世界交互的桥梁。Memory记忆用于在多次交互中保持状态可以是简单的对话历史也可以是更复杂的向量存储。1.2 常见误区与避坑指南误区一万物皆可Chain。不是所有任务都需要用Chain。简单的单次问答直接调用模型可能更高效。Chain适用于有固定模式的多步任务。误区二过度依赖默认配置。LangChain为许多组件提供了默认的提示词模板。这些模板是通用的起点但针对你的具体任务如客服、代码生成、数据分析几乎百分之百需要自定义和优化。提示词工程是LangChain应用性能的关键。误区三忽视异步和流式处理。在生产环境中响应速度和资源利用率至关重要。LangChain支持异步调用ainvoke和流式输出。在项目初期就应考虑这些模式而不是后期重构。一个简单的、可运行的Chain示例展示了从定义到执行的基本流程from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser # 1. 定义模型 llm ChatOpenAI(modelgpt-4o-mini, temperature0) # 2. 定义提示词模板 prompt ChatPromptTemplate.from_messages([ (system, 你是一个专业的翻译官将用户输入的中文翻译成英文。), (user, {input}) ]) # 3. 构建链模板 - 模型 - 解析器 chain prompt | llm | StrOutputParser() # 4. 调用链 result chain.invoke({input: 今天的天气真好}) print(result) # 输出The weather is really nice today!这个例子很简单但它体现了LangChain“声明式”组合的思想。接下来我们会看到更复杂的Agent如何在此基础上构建。2. Agent实战让大模型学会“使用工具”如果说Chain是固定流程那么Agent就是赋予了大模型“自主权”。它的核心思想是我不直接告诉你答案但我可以思考并决定调用哪个工具来获取信息最终综合所有信息给你答案。2.1 Agent的核心循环ReAct模式目前最主流的Agent模式是ReAct (Reason Act)。它的工作流程如下思考Think大模型分析当前问题、已有上下文记忆和可用工具决定下一步该做什么。行动Act如果决定使用工具就选择最合适的工具并生成调用参数。观察Observe执行工具调用获取结果可能是数据、错误信息或新的状态。循环将观察结果作为新的上下文再次进入“思考”步骤直到模型认为可以给出最终答案。在LangChain中这通常通过AgentExecutor来驱动。它负责管理这个循环处理解析错误、工具调用失败、超时等异常。2.2 工具Tool的定义与集成工具是Agent能力的延伸。定义一个工具非常简单关键在于让它能被模型正确理解和使用。from langchain.tools import tool from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain import hub # 1. 定义一个获取天气的工具 tool def get_weather(city: str) - str: 根据城市名称查询该城市的当前天气情况。 # 这里应该是调用真实天气API此处用模拟数据代替 weather_data { 北京: 晴15°C, 上海: 多云18°C, 深圳: 阵雨22°C } return weather_data.get(city, f未找到{city}的天气信息) # 2. 准备模型、提示词和工具列表 llm ChatOpenAI(modelgpt-4o-mini, temperature0) tools [get_weather] prompt hub.pull(hwchase17/react) # 使用一个标准的ReAct提示词模板 # 3. 创建Agent和Executor agent create_react_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 4. 运行Agent result agent_executor.invoke({input: 北京和上海的天气怎么样}) print(result[output])运行上述代码在verboseTrue模式下你会看到Agent完整的思考过程 Entering new AgentExecutor chain... 我需要比较北京和上海的天气。我应该先查询北京的天气再查询上海的天气。 Action: get_weather Action Input: {city: 北京} Observation: 晴15°C Thought: 现在我有了北京的天气接下来需要上海的天气。 Action: get_weather Action Input: {city: 上海} Observation: 多云18°C Thought: 我现在有了两个城市的天气信息可以回答用户的问题了。 Final Answer: 北京天气是晴15°C上海天气是多云18°C。2.3 企业级Agent开发的关键考量在玩具示例中一切都很美好。但在企业环境中你需要考虑更多工具描述的准确性工具的docstring文档字符串是模型理解工具用途的唯一依据。描述必须清晰、准确包含参数类型和示例。错误处理与重试工具调用可能失败网络超时、API限流。AgentExecutor提供了max_iterations、max_execution_time和错误处理回调必须合理配置。成本与延迟Agent的每次“思考”和“行动”都可能调用一次大模型成本高昂。需要设置合理的超时和最大迭代次数避免陷入死循环。结构化输出最终答案可能需要固定的JSON格式以便下游系统处理。这需要结合OutputParser和自定义提示词来实现。LangChain的工具调用与LLM原生Function Call有何区别这是一个常见问题。像GPT-4o这类模型本身就支持函数调用Function Calling。LangChain的工具调用在底层可以利用这一特性但它提供了更高层次的抽象统一的管理、流式的执行、复杂的编排多Agent协作以及与非OpenAI模型的兼容性。如果你的场景非常简单只用OpenAI模型直接使用原生Function Call可能更轻量。但如果你需要跨模型、或者需要与LangChain的其他组件如Memory RAG深度集成使用LangChain的Tool是更好的选择。3. RAG深入构建真正“有用”的知识库系统RAG检索增强生成是当前将私有知识与大模型结合最流行的架构。但搭建一个RAG系统绝不仅仅是“把文档切块、向量化、存起来、搜一下”那么简单。一个低质量的RAG其回答可能还不如直接问通用模型。3.1 RAG的三层挑战检索、增强、生成一个健壮的RAG系统需要在三个环节都做细致优化环节核心任务常见问题与优化点检索Retrieval从知识库中找到最相关的文档片段。问题检索不准返回无关内容。优化1.分块策略按语义、按标题、重叠分块。2.检索器除了向量检索结合关键词检索BM25进行混合检索。3.元数据过滤在检索时加入时间、来源等过滤条件。4.重排序Rerank使用更精细的交叉编码器模型对初步检索结果进行重排提升Top1精度。增强Augmentation将检索到的上下文与用户问题整合形成给模型的提示。问题上下文过长或噪声大淹没关键信息。优化1.上下文压缩对检索到的多段文本进行摘要或提取关键句。2.提示词工程明确指令模型“基于以下上下文回答”并设定引用格式。生成Generation模型基于增强后的提示生成最终答案。问题模型胡编乱造幻觉或忽略上下文。优化1.模型选择使用更擅长遵循指令的模型。2.温度设置降低temperature以减少随机性。3.后处理与引用要求模型在答案中注明出处并实现可追溯。3.2 从零搭建一个可用的RAG管道下面是一个简化但完整的企业知识库RAG实现示例包含了基本的优化思路from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain_community.vectorstores import Chroma from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import LLMChainExtractor from langchain import hub from langchain_core.runnables import RunnablePassthrough # 1. 加载与分割文档 loader TextLoader(./企业知识库.txt) documents loader.load() text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) splits text_splitter.split_documents(documents) # 2. 向量化与存储 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents(documentssplits, embeddingembeddings, persist_directory./chroma_db) retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 检索4个相关块 # 3. 进阶上下文压缩 - 使用LLM提取检索结果中的关键信息 llm_for_compression ChatOpenAI(temperature0, modelgpt-4o-mini) compressor LLMChainExtractor.from_llm(llm_for_compression) compression_retriever ContextualCompressionRetriever(base_compressorcompressor, base_retrieverretriever) # 4. 构建提示词模板 rag_prompt hub.pull(rlm/rag-prompt) # 一个标准的RAG提示词 # 5. 定义RAG链 model ChatOpenAI(modelgpt-4o-mini, temperature0) def format_docs(docs): return \n\n.join(doc.page_content for doc in docs) rag_chain ( {context: compression_retriever | format_docs, question: RunnablePassthrough()} | rag_prompt | model | StrOutputParser() ) # 6. 提问 result rag_chain.invoke(我们公司的年假政策是怎样的) print(result)3.3 生产环境RAG的进阶议题索引更新知识库不是静态的。需要设计增量更新策略定期或触发式地更新向量索引同时处理文档删除。多路召回与融合结合向量检索、关键词检索、甚至图数据库检索综合打分提升召回率。评估体系如何衡量RAG系统的效果需要设计评估指标如检索相关性、答案忠实度是否基于上下文、答案有用性等。可以使用RAGAS等专业评估框架。Agentic RAG这是前沿方向。让Agent来管理RAG流程例如判断是否需要检索、决定检索策略、对检索结果进行多步推理和验证从而生成更可靠的答案。4. MCP与LangGraph走向复杂与协同当你需要构建涉及多个步骤、有状态、需要并行或条件分支的复杂AI应用时基础的Chain和Agent可能就显得力不从心了。这时LangChain生态中的MCP和LangGraph就该登场了。4.1 MCP为AI应用定义“通用连接器”MCPModel Context Protocol是一个较新的协议它的目标是为AI应用如Codex、Cursor等AI编码助手提供一种标准化、安全的方式来连接各种工具、数据源和服务。你可以把MCP Server想象成一个标准化适配器。无论后端是数据库、云服务API、内部系统只要它实现了MCP协议前端AI应用就能以统一的方式发现和调用它。这解决了两个痛点安全性AI应用无需直接处理API密钥和敏感逻辑所有工具调用通过MCP Server代理权限和审计更可控。可复用性一个写好的MCP Server例如连接公司内部项目管理工具的Server可以被所有支持MCP的AI客户端使用。如何为AI助手添加一个MCP工具如搜索服务器以Codex为例大致步骤是编写或获取MCP Server例如tavily-mcp-server连接网络搜索API。配置Codex在Codex的配置文件中声明MCP Server的启动命令和参数。重启CodexCodex启动时会加载MCP Server并自动发现其提供的工具如search_web。直接使用此后在Codex中你就可以直接使用search_web这样的自然语言指令来触发搜索。MCP让工具集成从“每个应用各自为政”走向“一次编写处处可用”。4.2 LangGraph用“图”来编排复杂工作流LangGraph是LangChain官方推出的库用于构建有状态、多参与者的图工作流。如果说LangChain的Chain是“线”那么LangGraph就是“网”。它的核心概念是节点Node一个执行单元可以是一个函数、一个Chain或一个Agent。边Edge连接节点决定工作流的走向。边可以是条件式的根据上一个节点的结果决定下一步去哪。状态State一个贯穿整个工作流的共享字典所有节点都可以读取和修改它。LangGraph与LangChain Agent的区别是什么LangChain Agent核心是单个智能体的“思考-行动”循环。适合目标明确、需要自主调用工具的任务。LangGraph核心是多个节点可以是多个Agent也可以是其他函数按照预定义的图结构协同工作。适合流程固定但复杂、需要严格状态管理、有条件分支或循环的任务。一个LangGraph的典型场景客服工单处理想象一个流程用户提交工单 - 分类Agent判断紧急程度和类型 - 如果是技术问题转给技术知识库RAG节点如果是账单问题转给查询API节点 - 各节点处理完后汇总节点生成最终回复并更新工单状态。用LangGraph可以清晰地定义这个流程其中“分类Agent”的输出决定了走哪条“边”而“工单状态”在整个流程中被传递和修改。这是用单个Agent难以清晰实现的。from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated from langchain_core.messages import HumanMessage import operator # 1. 定义贯穿整个图的状态结构 class AgentState(TypedDict): messages: Annotated[list, operator.add] # 消息列表每个节点都可以添加 problem_type: str # 问题类型 solution: str # 解决方案 # 2. 定义各个节点函数 def classifier_node(state: AgentState): 分类节点判断问题类型 # 这里简化处理实际会调用一个LLM user_input state[messages][-1].content if 登录 in user_input: state[problem_type] technical elif 扣费 in user_input: state[problem_type] billing else: state[problem_type] general return state def technical_agent_node(state: AgentState): 技术问题处理节点模拟调用RAG state[solution] f[技术支持] 已为您检索到相关解决方案请尝试清除缓存后重试。 return state def billing_agent_node(state: AgentState): 账单问题处理节点模拟调用API state[solution] f[账单查询] 您本月的扣费是正常的详情已发送至您的邮箱。 return state def general_agent_node(state: AgentState): 通用问题处理节点 state[solution] f[通用咨询] 您的问题已记录客服将在24小时内回复您。 return state def router(state: AgentState) - str: 路由函数根据问题类型决定下一个节点 return state[problem_type] # 3. 构建图 workflow StateGraph(AgentState) # 添加节点 workflow.add_node(classifier, classifier_node) workflow.add_node(tech_agent, technical_agent_node) workflow.add_node(billing_agent, billing_agent_node) workflow.add_node(general_agent, general_agent_node) # 设置入口 workflow.set_entry_point(classifier) # 从分类节点到路由 workflow.add_conditional_edges( classifier, router, { technical: tech_agent, billing: billing_agent, general: general_agent } ) # 设置终点 workflow.add_edge(tech_agent, END) workflow.add_edge(billing_agent, END) workflow.add_edge(general_agent, END) # 编译图 app workflow.compile() # 4. 运行图 initial_state {messages: [HumanMessage(content我的账号登录不上了)]} result app.invoke(initial_state) print(f问题类型{result[problem_type]}) print(f解决方案{result[solution]})这个例子展示了LangGraph如何将复杂的、有分支的业务逻辑清晰地建模成一个可执行的工作流。对于需要长期记忆、多轮对话、复杂协作的AI应用LangGraph提供了比传统Agent更强大、更可控的范式。5. 企业级项目实战如何规划你的AI应用架构学完了所有组件最后我们来谈谈如何将它们用到实处。企业级项目关心的不只是功能更是稳定性、可维护性、成本和可扩展性。5.1 技术选型决策树面对一个新需求可以按以下路径思考需求是简单的单次问答吗是- 直接调用大模型API 精心设计的提示词。无需引入LangChain。否- 进入下一步。需要串联多个固定步骤吗如提取信息 - 格式化 - 保存是- 使用LangChain Chain。否- 进入下一步。需要模型自主决定调用工具吗如回答问题可能需要搜索、计算、查数据库是- 使用LangChain Agent。仔细设计工具和优化提示词以控制成本与循环。否- 进入下一步。流程非常复杂吗涉及严格状态、多角色协作、条件分支、循环是- 使用LangGraph进行可视化或代码化编排。否- 可能Chain或简单Agent已足够。需要接入私有知识吗是- 引入RAG。重点优化检索质量分块、索引、重排序和提示词工程。需要为多种AI客户端如多个IDE助手提供统一工具服务吗是- 考虑将工具封装为MCP Server。5.2 项目实战清单从原型到生产如果你决定采用LangChain技术栈以下是一个推荐的推进清单阶段一原型验证1-2周目标用最快速度验证核心想法是否可行。动作使用LangChain快速搭建核心流程Agent/RAG/Chain。使用本地文件、模拟数据或简单API作为工具和数据源。在Jupyter Notebook或简单脚本中运行。关键产出一个能跑通的端到端流程证明技术方案大体可行。阶段二系统化与优化2-4周目标解决原型中的主要痛点为集成做准备。动作提示词工程针对你的领域数据系统化地设计和测试提示词。RAG优化实验不同的文本分割器、嵌入模型、检索策略引入重排序。工具完善实现真实的工具函数加入错误处理和日志。评估体系建立简单的评估脚本用一批测试用例衡量效果。关键产出一个效果稳定、代码结构清晰的模块。阶段三工程化集成3-6周目标将AI模块融入现有生产系统。动作服务化将LangChain逻辑封装成API如使用FastAPI便于其他系统调用。配置化将模型参数、提示词模板、工具列表等抽离到配置文件。可观测性集成日志如LangSmith、监控调用耗时、成功率、Token消耗和告警。成本与限流实现调用限流、预算控制和成本分析。数据管道构建生产级的文档处理、向量化索引更新管道。关键产出一个可监控、可配置、与其他服务解耦的生产就绪服务。5.3 绕不开的“坑”与长期维护版本兼容性LangChain生态迭代很快注意langchain-core,langchain,langchain-community等包版本的兼容性使用虚拟环境并锁版本。异步与性能生产环境务必使用异步接口ainvoke,astream并合理设置超时和重试。幻觉与安全性永远不要完全信任模型的输出。对于关键业务必须加入事实核查、输出过滤或人工审核环节。技术债初期为了快可能会写很多胶水代码和硬编码。在第二阶段就要有计划地进行重构抽象出清晰的组件和配置。回到开头的问题为什么跟着教程做Demo容易做项目却难因为教程展示的是“零件”而项目需要的是“组装图纸”和“调试工艺”。LangChain、Agent、RAG、MCP、LangGraph这一套工具链给了我们强大的零件库。但最终能否造出稳定运行的机器取决于我们是否真正理解了每个零件的原理、局限性和组合方式。真正的“吃透”不是背下所有函数名而是在面对一个具体业务问题时能清晰地判断该用什么组件、为什么用它、以及如何把它稳妥地嵌入到现有的工程体系中去。这条路没有99%的捷径但有了正确的认知地图和工具箱每一步都能走得更加扎实。
最近在整理团队的技术栈发现一个挺有意思的现象很多同事在接触大模型应用开发时第一反应就是去搜“LangChain教程”。但跟着教程跑通几个Demo后真正要往项目里集成或者处理稍微复杂一点的业务逻辑时又卡住了。要么是Agent调用工具时状态混乱要么是RAG检索的结果总是不尽人意再或者想把多个步骤串联起来时发现代码成了一团乱麻。这其实不怪大家。市面上很多教程包括一些所谓的“速成课”往往只展示了LangChain最光鲜、最“一键生成”的那一面。它们告诉你“用这几行代码就能调用大模型”却很少深入讲清楚为什么需要AgentRAG的“检索-增强-生成”三个环节各自的难点和调优点在哪里当LangGraph出现后它和LangChain的核心区别是什么我们又该如何选择今天我们不追求“一周学完”的速成神话而是尝试换一个思路把LangChain及其生态Agent、RAG、MCP、LangGraph看作一套解决特定问题的“工具箱”和“设计模式”。我们的目标不是记住所有API而是理解每个工具解决什么核心问题它们的边界在哪里以及如何组合起来应对真实的企业级场景。这样或许才能真正“吃透”少走那些在项目后期才会暴露的弯路。1. 重新理解LangChain它不只是“大模型调用库”很多人对LangChain的第一印象是“一个让调用大模型变得更简单的Python库”。这个理解没错但太浅了。如果仅仅是为了调用ChatGPT或文心一言的API直接用requests库或者官方的SDK可能更直接。LangChain真正的价值在于它定义了一套构建基于大模型的应用程序的框架和范式。1.1 核心价值从“一次对话”到“可编排的工作流”想象一下如果没有LangChain你要实现一个“根据用户问题查询数据库再结合查询结果生成报告”的功能可能需要手动拼接用户问题和系统提示。调用大模型API解析返回的JSON。判断返回内容是否需要调用工具比如搜索数据库。如果需要再编写数据库查询逻辑获取结果。将查询结果再次拼接到提示词中重新调用大模型。处理可能出现的错误、重试、超时等问题。这个过程充满了胶水代码且难以复用和调试。LangChain的出现就是把上述步骤中的通用模式抽象出来变成了LLMChain、Tool、AgentExecutor、Memory等组件。它让你从关心“每一步怎么实现”转向关心“整个工作流如何设计”。所以学习LangChain的第一步不是背API而是理解几个核心抽象Chain链将多个组件如提示词模板、大模型、输出解析器按顺序组合起来。这是最基本的工作单元。Agent智能体一个具备“思考-行动-观察”循环的Chain。它可以根据大模型的推理动态决定下一步是调用工具还是直接给出答案。Tool工具Agent可以调用的函数如搜索、计算、查询API等。这是大模型与外部世界交互的桥梁。Memory记忆用于在多次交互中保持状态可以是简单的对话历史也可以是更复杂的向量存储。1.2 常见误区与避坑指南误区一万物皆可Chain。不是所有任务都需要用Chain。简单的单次问答直接调用模型可能更高效。Chain适用于有固定模式的多步任务。误区二过度依赖默认配置。LangChain为许多组件提供了默认的提示词模板。这些模板是通用的起点但针对你的具体任务如客服、代码生成、数据分析几乎百分之百需要自定义和优化。提示词工程是LangChain应用性能的关键。误区三忽视异步和流式处理。在生产环境中响应速度和资源利用率至关重要。LangChain支持异步调用ainvoke和流式输出。在项目初期就应考虑这些模式而不是后期重构。一个简单的、可运行的Chain示例展示了从定义到执行的基本流程from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser # 1. 定义模型 llm ChatOpenAI(modelgpt-4o-mini, temperature0) # 2. 定义提示词模板 prompt ChatPromptTemplate.from_messages([ (system, 你是一个专业的翻译官将用户输入的中文翻译成英文。), (user, {input}) ]) # 3. 构建链模板 - 模型 - 解析器 chain prompt | llm | StrOutputParser() # 4. 调用链 result chain.invoke({input: 今天的天气真好}) print(result) # 输出The weather is really nice today!这个例子很简单但它体现了LangChain“声明式”组合的思想。接下来我们会看到更复杂的Agent如何在此基础上构建。2. Agent实战让大模型学会“使用工具”如果说Chain是固定流程那么Agent就是赋予了大模型“自主权”。它的核心思想是我不直接告诉你答案但我可以思考并决定调用哪个工具来获取信息最终综合所有信息给你答案。2.1 Agent的核心循环ReAct模式目前最主流的Agent模式是ReAct (Reason Act)。它的工作流程如下思考Think大模型分析当前问题、已有上下文记忆和可用工具决定下一步该做什么。行动Act如果决定使用工具就选择最合适的工具并生成调用参数。观察Observe执行工具调用获取结果可能是数据、错误信息或新的状态。循环将观察结果作为新的上下文再次进入“思考”步骤直到模型认为可以给出最终答案。在LangChain中这通常通过AgentExecutor来驱动。它负责管理这个循环处理解析错误、工具调用失败、超时等异常。2.2 工具Tool的定义与集成工具是Agent能力的延伸。定义一个工具非常简单关键在于让它能被模型正确理解和使用。from langchain.tools import tool from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain import hub # 1. 定义一个获取天气的工具 tool def get_weather(city: str) - str: 根据城市名称查询该城市的当前天气情况。 # 这里应该是调用真实天气API此处用模拟数据代替 weather_data { 北京: 晴15°C, 上海: 多云18°C, 深圳: 阵雨22°C } return weather_data.get(city, f未找到{city}的天气信息) # 2. 准备模型、提示词和工具列表 llm ChatOpenAI(modelgpt-4o-mini, temperature0) tools [get_weather] prompt hub.pull(hwchase17/react) # 使用一个标准的ReAct提示词模板 # 3. 创建Agent和Executor agent create_react_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 4. 运行Agent result agent_executor.invoke({input: 北京和上海的天气怎么样}) print(result[output])运行上述代码在verboseTrue模式下你会看到Agent完整的思考过程 Entering new AgentExecutor chain... 我需要比较北京和上海的天气。我应该先查询北京的天气再查询上海的天气。 Action: get_weather Action Input: {city: 北京} Observation: 晴15°C Thought: 现在我有了北京的天气接下来需要上海的天气。 Action: get_weather Action Input: {city: 上海} Observation: 多云18°C Thought: 我现在有了两个城市的天气信息可以回答用户的问题了。 Final Answer: 北京天气是晴15°C上海天气是多云18°C。2.3 企业级Agent开发的关键考量在玩具示例中一切都很美好。但在企业环境中你需要考虑更多工具描述的准确性工具的docstring文档字符串是模型理解工具用途的唯一依据。描述必须清晰、准确包含参数类型和示例。错误处理与重试工具调用可能失败网络超时、API限流。AgentExecutor提供了max_iterations、max_execution_time和错误处理回调必须合理配置。成本与延迟Agent的每次“思考”和“行动”都可能调用一次大模型成本高昂。需要设置合理的超时和最大迭代次数避免陷入死循环。结构化输出最终答案可能需要固定的JSON格式以便下游系统处理。这需要结合OutputParser和自定义提示词来实现。LangChain的工具调用与LLM原生Function Call有何区别这是一个常见问题。像GPT-4o这类模型本身就支持函数调用Function Calling。LangChain的工具调用在底层可以利用这一特性但它提供了更高层次的抽象统一的管理、流式的执行、复杂的编排多Agent协作以及与非OpenAI模型的兼容性。如果你的场景非常简单只用OpenAI模型直接使用原生Function Call可能更轻量。但如果你需要跨模型、或者需要与LangChain的其他组件如Memory RAG深度集成使用LangChain的Tool是更好的选择。3. RAG深入构建真正“有用”的知识库系统RAG检索增强生成是当前将私有知识与大模型结合最流行的架构。但搭建一个RAG系统绝不仅仅是“把文档切块、向量化、存起来、搜一下”那么简单。一个低质量的RAG其回答可能还不如直接问通用模型。3.1 RAG的三层挑战检索、增强、生成一个健壮的RAG系统需要在三个环节都做细致优化环节核心任务常见问题与优化点检索Retrieval从知识库中找到最相关的文档片段。问题检索不准返回无关内容。优化1.分块策略按语义、按标题、重叠分块。2.检索器除了向量检索结合关键词检索BM25进行混合检索。3.元数据过滤在检索时加入时间、来源等过滤条件。4.重排序Rerank使用更精细的交叉编码器模型对初步检索结果进行重排提升Top1精度。增强Augmentation将检索到的上下文与用户问题整合形成给模型的提示。问题上下文过长或噪声大淹没关键信息。优化1.上下文压缩对检索到的多段文本进行摘要或提取关键句。2.提示词工程明确指令模型“基于以下上下文回答”并设定引用格式。生成Generation模型基于增强后的提示生成最终答案。问题模型胡编乱造幻觉或忽略上下文。优化1.模型选择使用更擅长遵循指令的模型。2.温度设置降低temperature以减少随机性。3.后处理与引用要求模型在答案中注明出处并实现可追溯。3.2 从零搭建一个可用的RAG管道下面是一个简化但完整的企业知识库RAG实现示例包含了基本的优化思路from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain_community.vectorstores import Chroma from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import LLMChainExtractor from langchain import hub from langchain_core.runnables import RunnablePassthrough # 1. 加载与分割文档 loader TextLoader(./企业知识库.txt) documents loader.load() text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) splits text_splitter.split_documents(documents) # 2. 向量化与存储 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents(documentssplits, embeddingembeddings, persist_directory./chroma_db) retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 检索4个相关块 # 3. 进阶上下文压缩 - 使用LLM提取检索结果中的关键信息 llm_for_compression ChatOpenAI(temperature0, modelgpt-4o-mini) compressor LLMChainExtractor.from_llm(llm_for_compression) compression_retriever ContextualCompressionRetriever(base_compressorcompressor, base_retrieverretriever) # 4. 构建提示词模板 rag_prompt hub.pull(rlm/rag-prompt) # 一个标准的RAG提示词 # 5. 定义RAG链 model ChatOpenAI(modelgpt-4o-mini, temperature0) def format_docs(docs): return \n\n.join(doc.page_content for doc in docs) rag_chain ( {context: compression_retriever | format_docs, question: RunnablePassthrough()} | rag_prompt | model | StrOutputParser() ) # 6. 提问 result rag_chain.invoke(我们公司的年假政策是怎样的) print(result)3.3 生产环境RAG的进阶议题索引更新知识库不是静态的。需要设计增量更新策略定期或触发式地更新向量索引同时处理文档删除。多路召回与融合结合向量检索、关键词检索、甚至图数据库检索综合打分提升召回率。评估体系如何衡量RAG系统的效果需要设计评估指标如检索相关性、答案忠实度是否基于上下文、答案有用性等。可以使用RAGAS等专业评估框架。Agentic RAG这是前沿方向。让Agent来管理RAG流程例如判断是否需要检索、决定检索策略、对检索结果进行多步推理和验证从而生成更可靠的答案。4. MCP与LangGraph走向复杂与协同当你需要构建涉及多个步骤、有状态、需要并行或条件分支的复杂AI应用时基础的Chain和Agent可能就显得力不从心了。这时LangChain生态中的MCP和LangGraph就该登场了。4.1 MCP为AI应用定义“通用连接器”MCPModel Context Protocol是一个较新的协议它的目标是为AI应用如Codex、Cursor等AI编码助手提供一种标准化、安全的方式来连接各种工具、数据源和服务。你可以把MCP Server想象成一个标准化适配器。无论后端是数据库、云服务API、内部系统只要它实现了MCP协议前端AI应用就能以统一的方式发现和调用它。这解决了两个痛点安全性AI应用无需直接处理API密钥和敏感逻辑所有工具调用通过MCP Server代理权限和审计更可控。可复用性一个写好的MCP Server例如连接公司内部项目管理工具的Server可以被所有支持MCP的AI客户端使用。如何为AI助手添加一个MCP工具如搜索服务器以Codex为例大致步骤是编写或获取MCP Server例如tavily-mcp-server连接网络搜索API。配置Codex在Codex的配置文件中声明MCP Server的启动命令和参数。重启CodexCodex启动时会加载MCP Server并自动发现其提供的工具如search_web。直接使用此后在Codex中你就可以直接使用search_web这样的自然语言指令来触发搜索。MCP让工具集成从“每个应用各自为政”走向“一次编写处处可用”。4.2 LangGraph用“图”来编排复杂工作流LangGraph是LangChain官方推出的库用于构建有状态、多参与者的图工作流。如果说LangChain的Chain是“线”那么LangGraph就是“网”。它的核心概念是节点Node一个执行单元可以是一个函数、一个Chain或一个Agent。边Edge连接节点决定工作流的走向。边可以是条件式的根据上一个节点的结果决定下一步去哪。状态State一个贯穿整个工作流的共享字典所有节点都可以读取和修改它。LangGraph与LangChain Agent的区别是什么LangChain Agent核心是单个智能体的“思考-行动”循环。适合目标明确、需要自主调用工具的任务。LangGraph核心是多个节点可以是多个Agent也可以是其他函数按照预定义的图结构协同工作。适合流程固定但复杂、需要严格状态管理、有条件分支或循环的任务。一个LangGraph的典型场景客服工单处理想象一个流程用户提交工单 - 分类Agent判断紧急程度和类型 - 如果是技术问题转给技术知识库RAG节点如果是账单问题转给查询API节点 - 各节点处理完后汇总节点生成最终回复并更新工单状态。用LangGraph可以清晰地定义这个流程其中“分类Agent”的输出决定了走哪条“边”而“工单状态”在整个流程中被传递和修改。这是用单个Agent难以清晰实现的。from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated from langchain_core.messages import HumanMessage import operator # 1. 定义贯穿整个图的状态结构 class AgentState(TypedDict): messages: Annotated[list, operator.add] # 消息列表每个节点都可以添加 problem_type: str # 问题类型 solution: str # 解决方案 # 2. 定义各个节点函数 def classifier_node(state: AgentState): 分类节点判断问题类型 # 这里简化处理实际会调用一个LLM user_input state[messages][-1].content if 登录 in user_input: state[problem_type] technical elif 扣费 in user_input: state[problem_type] billing else: state[problem_type] general return state def technical_agent_node(state: AgentState): 技术问题处理节点模拟调用RAG state[solution] f[技术支持] 已为您检索到相关解决方案请尝试清除缓存后重试。 return state def billing_agent_node(state: AgentState): 账单问题处理节点模拟调用API state[solution] f[账单查询] 您本月的扣费是正常的详情已发送至您的邮箱。 return state def general_agent_node(state: AgentState): 通用问题处理节点 state[solution] f[通用咨询] 您的问题已记录客服将在24小时内回复您。 return state def router(state: AgentState) - str: 路由函数根据问题类型决定下一个节点 return state[problem_type] # 3. 构建图 workflow StateGraph(AgentState) # 添加节点 workflow.add_node(classifier, classifier_node) workflow.add_node(tech_agent, technical_agent_node) workflow.add_node(billing_agent, billing_agent_node) workflow.add_node(general_agent, general_agent_node) # 设置入口 workflow.set_entry_point(classifier) # 从分类节点到路由 workflow.add_conditional_edges( classifier, router, { technical: tech_agent, billing: billing_agent, general: general_agent } ) # 设置终点 workflow.add_edge(tech_agent, END) workflow.add_edge(billing_agent, END) workflow.add_edge(general_agent, END) # 编译图 app workflow.compile() # 4. 运行图 initial_state {messages: [HumanMessage(content我的账号登录不上了)]} result app.invoke(initial_state) print(f问题类型{result[problem_type]}) print(f解决方案{result[solution]})这个例子展示了LangGraph如何将复杂的、有分支的业务逻辑清晰地建模成一个可执行的工作流。对于需要长期记忆、多轮对话、复杂协作的AI应用LangGraph提供了比传统Agent更强大、更可控的范式。5. 企业级项目实战如何规划你的AI应用架构学完了所有组件最后我们来谈谈如何将它们用到实处。企业级项目关心的不只是功能更是稳定性、可维护性、成本和可扩展性。5.1 技术选型决策树面对一个新需求可以按以下路径思考需求是简单的单次问答吗是- 直接调用大模型API 精心设计的提示词。无需引入LangChain。否- 进入下一步。需要串联多个固定步骤吗如提取信息 - 格式化 - 保存是- 使用LangChain Chain。否- 进入下一步。需要模型自主决定调用工具吗如回答问题可能需要搜索、计算、查数据库是- 使用LangChain Agent。仔细设计工具和优化提示词以控制成本与循环。否- 进入下一步。流程非常复杂吗涉及严格状态、多角色协作、条件分支、循环是- 使用LangGraph进行可视化或代码化编排。否- 可能Chain或简单Agent已足够。需要接入私有知识吗是- 引入RAG。重点优化检索质量分块、索引、重排序和提示词工程。需要为多种AI客户端如多个IDE助手提供统一工具服务吗是- 考虑将工具封装为MCP Server。5.2 项目实战清单从原型到生产如果你决定采用LangChain技术栈以下是一个推荐的推进清单阶段一原型验证1-2周目标用最快速度验证核心想法是否可行。动作使用LangChain快速搭建核心流程Agent/RAG/Chain。使用本地文件、模拟数据或简单API作为工具和数据源。在Jupyter Notebook或简单脚本中运行。关键产出一个能跑通的端到端流程证明技术方案大体可行。阶段二系统化与优化2-4周目标解决原型中的主要痛点为集成做准备。动作提示词工程针对你的领域数据系统化地设计和测试提示词。RAG优化实验不同的文本分割器、嵌入模型、检索策略引入重排序。工具完善实现真实的工具函数加入错误处理和日志。评估体系建立简单的评估脚本用一批测试用例衡量效果。关键产出一个效果稳定、代码结构清晰的模块。阶段三工程化集成3-6周目标将AI模块融入现有生产系统。动作服务化将LangChain逻辑封装成API如使用FastAPI便于其他系统调用。配置化将模型参数、提示词模板、工具列表等抽离到配置文件。可观测性集成日志如LangSmith、监控调用耗时、成功率、Token消耗和告警。成本与限流实现调用限流、预算控制和成本分析。数据管道构建生产级的文档处理、向量化索引更新管道。关键产出一个可监控、可配置、与其他服务解耦的生产就绪服务。5.3 绕不开的“坑”与长期维护版本兼容性LangChain生态迭代很快注意langchain-core,langchain,langchain-community等包版本的兼容性使用虚拟环境并锁版本。异步与性能生产环境务必使用异步接口ainvoke,astream并合理设置超时和重试。幻觉与安全性永远不要完全信任模型的输出。对于关键业务必须加入事实核查、输出过滤或人工审核环节。技术债初期为了快可能会写很多胶水代码和硬编码。在第二阶段就要有计划地进行重构抽象出清晰的组件和配置。回到开头的问题为什么跟着教程做Demo容易做项目却难因为教程展示的是“零件”而项目需要的是“组装图纸”和“调试工艺”。LangChain、Agent、RAG、MCP、LangGraph这一套工具链给了我们强大的零件库。但最终能否造出稳定运行的机器取决于我们是否真正理解了每个零件的原理、局限性和组合方式。真正的“吃透”不是背下所有函数名而是在面对一个具体业务问题时能清晰地判断该用什么组件、为什么用它、以及如何把它稳妥地嵌入到现有的工程体系中去。这条路没有99%的捷径但有了正确的认知地图和工具箱每一步都能走得更加扎实。
