1. 项目概述为什么现在要自己动手做AI Agent最近和几个做产品的朋友聊天发现大家不约而同地都在琢磨同一个事儿怎么把手头那些需要人工判断、多步骤操作的任务交给一个能自己“想事儿”的程序去干。比如让系统自动分析用户上传的合同提取关键条款再根据公司政策给出风险评估或者做一个能理解自然语言指令自动去数据库查数据、生成图表、甚至写邮件通知相关同事的“数字助理”。这背后指向的就是AI Agent智能体。你可能在各种文章里见过这个词感觉它既高级又有点模糊。简单说一个合格的AI Agent不是那种你问一句它答一句的聊天机器人。它是一个具备一定自主性的软件实体能理解复杂目标规划执行步骤调用各种工具比如搜索、计算、操作API并在过程中根据反馈动态调整策略直到完成任务。它像是一个数字世界里的“执行者”大脑是大型语言模型LLM手脚是各种工具Tools。那为什么现在“从零开始构建”变得如此重要直接使用现成的平台比如一些低代码AI应用搭建工具不香吗这里有个很现实的考量控制力与定制深度。现成平台确实能快速搭出个原型但当你需要深度定制工具、精细控制执行逻辑、优化响应速度或者将智能体深度嵌入到现有复杂业务系统时自己基于框架开发就成了必选项。这就好比你想快速做个展示用的小木屋可以用预制板但你要盖一栋符合特殊地质要求、功能复杂的自住房就必须从打地基开始自己设计施工。LangChain正是在这个背景下成为了开发者手中的“瑞士军刀”。它不是一个开箱即用的Agent产品而是一个框架专门用于简化基于LLM的应用程序开发。它把跟LLM对话、管理对话历史、调用工具、控制执行流程这些繁琐但通用的环节封装成了清晰、可组合的模块。你可以把它理解为乐高积木提供了各种标准件组件让你能专注于搭建你想要的独特造型业务逻辑而不用自己去烧制每一块塑料。所以这个项目的目的很明确我们不满足于仅仅使用Agent我们要深入其内部理解它的骨骼和神经用LangChain这把利器亲手打造一个能解决真实问题的、可掌控的AI智能体。整个过程我们会聚焦于最核心、最实用的**Tool-use Agent工具调用型智能体**的开发。2. 核心架构解析LangChain如何组织一个智能体在动手写代码之前我们必须先在大脑里建立起AI Agent在LangChain世界里的“心理模型”。一个典型的Tool-use Agent其核心运行逻辑是一个循环可以概括为思考Plan- 执行Act- 观察Observe- 再思考Plan...直到任务完成或无法继续。LangChain巧妙地用几个核心组件将这个循环具象化。2.1 核心组件四要素一个功能完整的Agent在LangChain中由四个部分紧密协作构成LLM大型语言模型智能体的“大脑”。负责理解用户输入、进行逻辑推理、决定下一步该做什么是直接回答还是调用某个工具。你可以接入OpenAI的GPT系列、Anthropic的Claude或者开源的Llama、Qwen等。选择不同的大脑直接决定了智能体的“智商”和“性格”。Tools工具智能体的“手”和“脚”。这是智能体与外部世界交互的接口。一个工具本质上是一个函数它有明确的名称、描述和参数。例如SearchTool接收一个查询词返回搜索结果。CalculatorTool接收一个数学表达式返回计算结果。DatabaseQueryTool接收一个SQL语句返回查询数据。自定义业务工具比如SendEmailTool、GenerateReportTool。 LLM根据对任务的理解会选择调用合适的工具并生成符合工具要求的参数。Agent智能体执行器智能体的“调度中枢”。这是LangChain封装好的高层抽象。你不需要自己写那个“思考-执行”循环。你只需定义一个AgentType例如ZERO_SHOT_REACT_DESCRIPTION然后传入LLM和Tools列表LangChain就会帮你生成一个具备推理能力的Agent对象。这个对象知道如何驱动LLM进行思考并管理工具调用的流程。Agent Executor智能体执行器智能体的“运行引擎”。它负责实际运行Agent定义的循环。它调用Agent获取下一步的行动决策是输出最终答案还是调用工具如果调用工具则执行工具并获取结果然后将结果观察连同历史对话一起再次喂给Agent进行下一轮决策。它还负责处理错误、管理迭代次数以防无限循环。2.2 两种关键的“提示工程”驱动这个循环运转的是两种精心设计的提示词PromptAgent Prompt这是指导LLM如何扮演一个“决策者”的提示词。一个经典的ReActReasoning Acting格式提示词大致如下你是一个有帮助的助手可以使用以下工具[工具列表及其描述]。你的任务是根据用户的问题决定是直接回答还是使用工具。如果使用工具请严格按照格式输出Thought:你的思考过程Action:工具名Action Input:工具的输入参数。用户的问题是{用户输入}这个提示词让LLM学会了“先思考再行动”并且输出结构化的决策文本。Tool Prompt每个工具的描述description本身也是一种提示词。描述的质量至关重要。它必须清晰、无歧义地说明这个工具是干什么的、输入应该是什么格式。例如一个糟糕的描述是“计算东西”。一个好的描述是“一个计算器工具用于计算基础算术表达式。输入应该是一个字符串格式的数学表达式如 ‘(5 3) * 2’。”实操心得Agent的“智商”一半来自LLM本身另一半就来自这些提示词的设计。在调试Agent行为不正常时第一个要检查的就是工具描述是否清晰以及Agent的提示词是否给了足够的推理指引。我经常发现把工具描述写得像给一个有点马虎但很聪明的新员工看的说明书一样详细效果会好很多。2.3 与LLM原生Function Calling的异同你可能会问像GPT-4这样的模型本身就支持function calling为什么还要用LangChain的Agent这是个非常好的问题触及了框架的核心价值。LangChain Agent提供的是一个更高层次的、多步的、可定制的执行框架。它管理了整个“规划-行动-观察”的循环支持复杂的多工具顺序或条件调用并且可以轻松集成各种类型的LLM不仅限于支持function calling的。它更像一个导演负责整个剧本任务的推进。LLM原生Function Calling是LLM提供的一种单次交互能力。模型在一次响应中可以输出一个“建议调用某个函数”的请求然后由开发者手动执行该函数并将结果再传回LLM进行下一轮对话。它需要开发者自己编写循环和管理状态。它更像一个演员能给出一次精彩的即兴表演建议。简单比喻用原生function calling你需要自己写舞台调度、灯光切换和提醒演员下一幕的台词。而用LangChain Agent你告诉导演Agent最终要演什么戏它来负责指挥所有演员Tools和推进剧情。在需要快速实现一个复杂、多步骤的自动化流程时LangChain Agent的开发效率优势非常明显。3. 实战构建一个多功能查询助手智能体理论说得再多不如一行代码。接下来我们构建一个实用的“多功能查询助手”。这个智能体能根据你的问题自动决定是进行网页搜索、计算数学题还是查询当前时间。我们将使用OpenAI的LLM和LangChain的最新稳定版API。3.1 环境准备与依赖安装首先确保你的Python环境在3.8以上。创建一个新的虚拟环境是个好习惯。# 创建并激活虚拟环境以conda为例 conda create -n langchain-agent python3.10 conda activate langchain-agent # 安装核心依赖 pip install langchain langchain-community langchain-openai这里解释一下包的选择langchain: LangChain核心框架。langchain-community: 包含大量第三方集成的工具和组件如一些搜索工具。langchain-openai: OpenAI模型的官方LangChain集成包。你还需要一个OpenAI的API密钥。将其设置为环境变量# 在终端中设置临时 export OPENAI_API_KEYyour-api-key-here # 或者在代码中设置 import os os.environ[“OPENAI_API_KEY”] ‘your-api-key-here’3.2 定义工具赋予智能体“手脚”我们将定义三个工具搜索、计算和获取时间。from langchain.agents import Tool from langchain_community.tools import DuckDuckGoSearchRun from langchain_community.utilities import WikipediaAPIWrapper import datetime import math import re # 工具1互联网搜索使用DuckDuckGo search DuckDuckGoSearchRun() search_tool Tool( name“Web Search” funcsearch.run, description“当需要获取最新的、实时的信息或回答关于当前事件、事实查询时使用此工具。输入应该是一个明确的搜索查询词。” ) # 工具2计算器 def calculator(query: str) - str: “”“计算一个安全的数学表达式。只支持基础算术和math库中的安全函数。”“” # 安全过滤移除危险字符和函数 safe_query re.sub(r‘[^0-9\-*/().\s]’ ‘’ query) try: # 使用eval有风险此处仅用于演示生产环境应用ast.literal_eval或专用库 # 更安全的做法是使用 numexpr 或自己写解析器 result eval(safe_query, {“__builtins__”: {}}, {“math”: math}) return str(result) except Exception as e: return f“计算错误{e} 请检查表达式 ‘{query}’ 是否合法。” calc_tool Tool( name“Calculator” funccalculator, description“用于计算数学表达式。输入应该是一个字符串格式的算术表达式例如 ‘(15 7) * 3 / 2’。支持加减乘除和括号。” ) # 工具3获取当前时间 def get_current_time(_) - str: # 参数通常由Agent传入这里我们不需要 now datetime.datetime.now() return now.strftime(“%Y-%m-%d %H:%M:%S”) time_tool Tool( name“Current Time” funcget_current_time, description“当用户询问当前时间、今天日期或类似问题时使用此工具。此工具无需输入参数。” ) # 将所有工具放入一个列表 tools [search_tool, calc_tool, time_tool]注意事项工具描述是灵魂仔细看每个工具的description它直接决定了LLM是否能在正确的时候选择它。描述要具体、说明使用场景和输入格式。安全第一计算器工具中直接使用eval是极不安全的因为它会执行任意代码。这里仅为演示简洁。在生产环境中必须使用更安全的方法如ast.literal_eval仅支持字面量、numexpr库或自己实现一个简单的表达式解析器。工具函数签名工具函数通常接收一个字符串参数即Action Input。如果工具不需要输入如获取时间函数可以定义一个参数但不使用它或者使用lambda表达式。3.3 初始化大脑与创建智能体现在我们引入“大脑”LLM并将所有部件组装起来。from langchain_openai import ChatOpenAI from langchain.agents import initialize_agent, AgentType # 1. 初始化LLM。我们使用gpt-3.5-turbo性价比高响应快。 # 温度temperature设置为0.1让输出更确定、更专注于工具调用。 llm ChatOpenAI(model“gpt-3.5-turbo” temperature0.1) # 2. 创建智能体。我们使用最常用的 ZERO_SHOT_REACT_DESCRIPTION 类型。 # 这是一种零样本Zero-Shot的ReAct代理它依靠提示词来引导推理不需要额外的示例。 agent initialize_agent( toolstools, llmllm, agentAgentType.ZERO_SHOT_REACT_DESCRIPTION, # 代理类型 verboseTrue, # 设为True可以看到智能体完整的“思考-行动”过程便于调试 handle_parsing_errorsTrue, # 优雅地处理LLM输出格式解析错误 max_iterations5, # 防止无限循环最多迭代5次 early_stopping_method“generate” # 当Agent认为可以给出最终答案时停止 )关键参数解析AgentType.ZERO_SHOT_REACT_DESCRIPTION: 这是最基础也是最常用的类型适合大多数工具调用场景。还有STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION要求LLM支持结构化输出、OPENAI_FUNCTIONS专为OpenAI的function calling优化等可根据LLM特性选择。verboseTrue:调试神器。开启后控制台会打印出Agent完整的思考链Thought、行动Action和观察Observation让你一目了然它是如何决策的。handle_parsing_errorsTrue: LLM的输出偶尔会不符合Agent预期的解析格式这个参数能防止程序因此崩溃而是尝试让LLM重新输出。max_iterations:必须设置。这是安全绳防止智能体陷入“思考-调用-再思考”的死循环。3.4 运行与测试见证智能体工作让我们用几个问题来测试我们的智能体。# 测试1需要计算和搜索的复杂问题 query1 “珠穆朗玛峰的高度是多少米把这个高度从米换算成英尺并告诉我换算结果。” print(“ 查询1:” query1 “”) result1 agent.invoke({“input”: query1}) print(“最终答案” result1[‘output’]) print(“\n” “”*50 “\n”) # 测试2简单计算 query2 “计算一下 125 的平方根加上 30 等于多少” print(“ 查询2:” query2 “”) result2 agent.invoke({“input”: query2}) print(“最终答案” result2[‘output’]) print(“\n” “”*50 “\n”) # 测试3查询时间 query3 “现在几点了” print(“ 查询3:” query3 “”) result3 agent.invoke({“input”: query3}) print(“最终答案” result3[‘output’])当verboseTrue时你会在控制台看到类似下面的输出以查询1为例 查询1: 珠穆朗玛峰的高度是多少米把这个高度从米换算成英尺并告诉我换算结果。 Entering new AgentExecutor chain... Thought: 用户的问题分为两部分首先需要知道珠穆朗玛峰的高度米然后进行单位换算。我应该先搜索珠穆朗玛峰的准确高度。 Action: Web Search Action Input: 珠穆朗玛峰 高度 米 Observation: 珠穆朗玛峰的最新测量高度约为8848.86米。 Thought: 我已经得到了高度是8848.86米。现在需要将其换算成英尺。我知道1米约等于3.28084英尺。我需要使用计算器工具。 Action: Calculator Action Input: 8848.86 * 3.28084 Observation: 29031.7 Thought: 我已经计算出了结果大约是29031.7英尺。现在我可以把这两个信息组合起来回答用户。 Action: Final Answer Final Answer: 珠穆朗玛峰的高度约为8848.86米。换算成英尺大约是29031.7英尺。 Finished chain. 最终答案 珠穆朗玛峰的高度约为8848.86米。换算成英尺大约是29031.7英尺。看到这个过程了吗智能体完美地展示了ReAct范式思考需要搜索- 行动调用搜索工具- 观察得到8848.86米- 再思考需要计算- 再行动调用计算器- 再观察得到29031.7- 最终回答。它自主地规划了步骤并选择了正确的工具。4. 性能优化与高级技巧一个能跑起来的Agent只是第一步。要让它在生产环境中可靠、高效地运行还需要考虑很多问题。4.1 工具调用速度的影响因素与优化LangChain工具调用的速度瓶颈通常不在LangChain框架本身而在以下几个环节LLM API调用延迟这是最主要的影响因素。每次Agent“思考”都需要请求一次LLM API。GPT-3.5-Turbo比GPT-4快但能力稍弱。优化方法选择合适的模型在精度允许的情况下使用更快的模型。优化提示词清晰、简洁的提示词能让LLM更快地理解意图减少“胡思乱想”有时还能减少请求的token数。设置合理的超时和重试在初始化LLM时配置request_timeout参数。工具本身的执行时间如果你的工具需要查询一个慢速数据库、调用一个响应慢的外部API那么整个Agent就会被阻塞。优化方法工具异步化将工具函数定义为async函数并使用支持异步的Agent执行器如initialize_agent支持异步。设置工具超时在自定义工具内部实现超时逻辑避免一个失败的工具拖垮整个Agent。缓存对耗时且结果不常变动的工具如某些数据查询引入缓存机制。Agent的迭代次数不必要的迭代会显著增加延迟。优化方法精确的工具描述避免LLM因误解而选错工具导致无效迭代。设置max_iterations根据任务复杂度合理设置通常5-10次足够。使用更高效的Agent类型对于简单任务可以尝试AgentType.OPENAI_FUNCTIONS它利用OpenAI原生的function calling可能更高效。4.2 处理复杂逻辑与状态管理LangGraph的引入我们上面构建的Agent是线性的“思考-行动”循环。但现实世界的任务往往更复杂可能包含分支、循环、并行执行或者需要维护一个跨多轮对话的复杂状态。这时基础的AgentExecutor就显得力不从心了。这就是LangGraph出场的时候。你可以把LangGraph理解为LangChain的“工作流引擎”或“状态机管理器”。它允许你用图Graph的形式来定义Agent的执行流程节点Node可以是调用LLM、执行工具、条件判断边Edge定义了节点之间的流转逻辑。一个简单对比LangChain Agent像是一个有固定套路的流水线适合顺序性强的任务。LangChain LangGraph像是一个可以自定义的流程图适合有分支、循环、并行等复杂逻辑的任务。例如你可以构建一个这样的智能体流程用户提出一个复杂分析请求。Agent节点决定需要调用A、B两个工具并行获取数据。两个工具节点并行执行。所有数据收集完成后进入一个“合成”节点调用LLM分析数据并生成报告。根据报告内容决定是直接返回给用户还是再调用一个“发送邮件”的工具节点。实操心得对于绝大多数工具调用场景基础的AgentExecutor已经足够强大。只有当你需要显式地控制执行流比如“先做A如果A成功再做B否则做C”或者任务步骤间有复杂的依赖关系时才需要考虑引入LangGraph。它增加了架构的复杂性但也提供了无与伦比的灵活性和控制力。4.3 错误处理与鲁棒性提升一个健壮的Agent必须能妥善处理各种意外。工具调用失败网络错误、API限流、资源不存在等。应该在工具函数内部做好异常捕获返回清晰的错误信息如“搜索服务暂时不可用”而不是抛出异常导致整个Agent崩溃。Agent的LLM大脑通常能理解这些错误信息并尝试其他方案或告知用户。LLM输出格式错误尽管有handle_parsing_errorsTrue但有时LLM会输出完全无法解析的内容。更健壮的做法是自定义一个OutputParser或者使用AgentType.STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION这类依赖LLM结构化输出如JSON的代理类型容错性更好。无限循环除了设置max_iterations还可以观察Thought。如果连续几轮的Thought内容重复或毫无进展可以在自定义回调中实现更早的中断逻辑。输入安全与过滤永远不要相信用户输入或LLM生成的工具参数。在工具函数内部对输入进行严格的验证、清洗和转义防止注入攻击或其他安全漏洞。前面计算器工具的安全风险就是一个典型例子。5. 从Demo到生产关键考量与部署实践让一个Agent在本地跑起来和让它稳定服务成百上千的用户是两回事。以下是走向生产环境必须考虑的几点。5.1 监控、日志与可观测性“黑盒”是AI应用的大忌。你必须知道你的Agent每天都在做什么哪里慢了哪里出错了。结构化日志记录每一轮交互的ThoughtActionAction InputObservation以及最终输出。这不仅是调试的依据也是优化提示词、分析用户意图的宝贵数据。关键指标监控延迟平均响应时间、P95/P99响应时间。成本每次调用消耗的Token数特别是输入Token因为通常更贵。成功率任务完成率 vs. 中途失败率。工具使用分布哪个工具被调用得最频繁哪个最容易出错链路追踪TracingLangChain内置了对LangSmith的良好支持。LangSmith是一个可视化平台可以像看分布式系统调用链一样查看一次Agent调用的完整生命周期每个组件的耗时、输入输出一目了然是开发和调试的利器。5.2 成本控制策略LLM API调用是按Token收费的尤其是使用高性能模型时成本可能快速增长。对话历史管理AgentExecutor会默认将完整的对话历史包括冗长的工具观察结果传递给下一轮思考。这会导致Token消耗快速增长。需要合理设置max_token_limit或使用ConversationSummaryBufferMemory等记忆组件来压缩历史只保留精华。工具描述的精简在保证清晰的前提下尽量精简工具的description减少不必要的Token。模型分级使用对于简单的工具选择或格式化任务可以考虑使用更便宜、更快的模型如GPT-3.5-Turbo对于复杂的合成、推理步骤再使用更强的模型如GPT-4。这需要更精细的架构设计例如使用LangGraph来路由不同的任务到不同的模型。5.3 部署模式选择Web API服务最常用的方式。使用FastAPI或Flask将你的Agent封装成RESTful API。注意处理好并发、异步和生命周期管理。from fastapi import FastAPI app FastAPI() # 注意在生产中Agent实例的创建和初始化需要考虑并发安全性和资源复用。 # 通常需要依赖注入或全局状态管理。 app.post(“/ask”) async def ask_agent(query: str): result await agent.ainvoke({“input”: query}) # 使用异步调用 return {“answer”: result[“output”]}异步任务队列对于耗时较长的Agent任务如需要调用多个慢速工具不适合同步HTTP请求。可以将其放入Celery或RQ等任务队列通过WebSocket或轮询向客户端返回结果。容器化与云原生使用Docker将你的Agent应用及其所有依赖打包。结合Kubernetes可以轻松实现扩缩容、滚动更新和高可用部署。构建AI Agent的过程是一个不断在“智能”与“可控”、“灵活”与“稳定”之间寻找平衡点的过程。从定义一个清晰的工具开始到设计高效的提示词再到处理各种边界情况和性能优化每一步都需要开发者既理解AI的能力也理解软件工程的规范。LangChain提供的这套范式极大地降低了入门门槛但真正打造一个能在生产环境创造价值的智能体考验的仍然是开发者的综合设计能力和对业务需求的深刻理解。我个人的体会是开始时不必追求大而全从一个能解决具体痛点的小工具集入手让它稳定可靠地运行起来再逐步扩展其能力和边界这条路会走得更加扎实。 基于LangChain从零构建AI Agent：核心架构与实战指南
1. 项目概述为什么现在要自己动手做AI Agent最近和几个做产品的朋友聊天发现大家不约而同地都在琢磨同一个事儿怎么把手头那些需要人工判断、多步骤操作的任务交给一个能自己“想事儿”的程序去干。比如让系统自动分析用户上传的合同提取关键条款再根据公司政策给出风险评估或者做一个能理解自然语言指令自动去数据库查数据、生成图表、甚至写邮件通知相关同事的“数字助理”。这背后指向的就是AI Agent智能体。你可能在各种文章里见过这个词感觉它既高级又有点模糊。简单说一个合格的AI Agent不是那种你问一句它答一句的聊天机器人。它是一个具备一定自主性的软件实体能理解复杂目标规划执行步骤调用各种工具比如搜索、计算、操作API并在过程中根据反馈动态调整策略直到完成任务。它像是一个数字世界里的“执行者”大脑是大型语言模型LLM手脚是各种工具Tools。那为什么现在“从零开始构建”变得如此重要直接使用现成的平台比如一些低代码AI应用搭建工具不香吗这里有个很现实的考量控制力与定制深度。现成平台确实能快速搭出个原型但当你需要深度定制工具、精细控制执行逻辑、优化响应速度或者将智能体深度嵌入到现有复杂业务系统时自己基于框架开发就成了必选项。这就好比你想快速做个展示用的小木屋可以用预制板但你要盖一栋符合特殊地质要求、功能复杂的自住房就必须从打地基开始自己设计施工。LangChain正是在这个背景下成为了开发者手中的“瑞士军刀”。它不是一个开箱即用的Agent产品而是一个框架专门用于简化基于LLM的应用程序开发。它把跟LLM对话、管理对话历史、调用工具、控制执行流程这些繁琐但通用的环节封装成了清晰、可组合的模块。你可以把它理解为乐高积木提供了各种标准件组件让你能专注于搭建你想要的独特造型业务逻辑而不用自己去烧制每一块塑料。所以这个项目的目的很明确我们不满足于仅仅使用Agent我们要深入其内部理解它的骨骼和神经用LangChain这把利器亲手打造一个能解决真实问题的、可掌控的AI智能体。整个过程我们会聚焦于最核心、最实用的**Tool-use Agent工具调用型智能体**的开发。2. 核心架构解析LangChain如何组织一个智能体在动手写代码之前我们必须先在大脑里建立起AI Agent在LangChain世界里的“心理模型”。一个典型的Tool-use Agent其核心运行逻辑是一个循环可以概括为思考Plan- 执行Act- 观察Observe- 再思考Plan...直到任务完成或无法继续。LangChain巧妙地用几个核心组件将这个循环具象化。2.1 核心组件四要素一个功能完整的Agent在LangChain中由四个部分紧密协作构成LLM大型语言模型智能体的“大脑”。负责理解用户输入、进行逻辑推理、决定下一步该做什么是直接回答还是调用某个工具。你可以接入OpenAI的GPT系列、Anthropic的Claude或者开源的Llama、Qwen等。选择不同的大脑直接决定了智能体的“智商”和“性格”。Tools工具智能体的“手”和“脚”。这是智能体与外部世界交互的接口。一个工具本质上是一个函数它有明确的名称、描述和参数。例如SearchTool接收一个查询词返回搜索结果。CalculatorTool接收一个数学表达式返回计算结果。DatabaseQueryTool接收一个SQL语句返回查询数据。自定义业务工具比如SendEmailTool、GenerateReportTool。 LLM根据对任务的理解会选择调用合适的工具并生成符合工具要求的参数。Agent智能体执行器智能体的“调度中枢”。这是LangChain封装好的高层抽象。你不需要自己写那个“思考-执行”循环。你只需定义一个AgentType例如ZERO_SHOT_REACT_DESCRIPTION然后传入LLM和Tools列表LangChain就会帮你生成一个具备推理能力的Agent对象。这个对象知道如何驱动LLM进行思考并管理工具调用的流程。Agent Executor智能体执行器智能体的“运行引擎”。它负责实际运行Agent定义的循环。它调用Agent获取下一步的行动决策是输出最终答案还是调用工具如果调用工具则执行工具并获取结果然后将结果观察连同历史对话一起再次喂给Agent进行下一轮决策。它还负责处理错误、管理迭代次数以防无限循环。2.2 两种关键的“提示工程”驱动这个循环运转的是两种精心设计的提示词PromptAgent Prompt这是指导LLM如何扮演一个“决策者”的提示词。一个经典的ReActReasoning Acting格式提示词大致如下你是一个有帮助的助手可以使用以下工具[工具列表及其描述]。你的任务是根据用户的问题决定是直接回答还是使用工具。如果使用工具请严格按照格式输出Thought:你的思考过程Action:工具名Action Input:工具的输入参数。用户的问题是{用户输入}这个提示词让LLM学会了“先思考再行动”并且输出结构化的决策文本。Tool Prompt每个工具的描述description本身也是一种提示词。描述的质量至关重要。它必须清晰、无歧义地说明这个工具是干什么的、输入应该是什么格式。例如一个糟糕的描述是“计算东西”。一个好的描述是“一个计算器工具用于计算基础算术表达式。输入应该是一个字符串格式的数学表达式如 ‘(5 3) * 2’。”实操心得Agent的“智商”一半来自LLM本身另一半就来自这些提示词的设计。在调试Agent行为不正常时第一个要检查的就是工具描述是否清晰以及Agent的提示词是否给了足够的推理指引。我经常发现把工具描述写得像给一个有点马虎但很聪明的新员工看的说明书一样详细效果会好很多。2.3 与LLM原生Function Calling的异同你可能会问像GPT-4这样的模型本身就支持function calling为什么还要用LangChain的Agent这是个非常好的问题触及了框架的核心价值。LangChain Agent提供的是一个更高层次的、多步的、可定制的执行框架。它管理了整个“规划-行动-观察”的循环支持复杂的多工具顺序或条件调用并且可以轻松集成各种类型的LLM不仅限于支持function calling的。它更像一个导演负责整个剧本任务的推进。LLM原生Function Calling是LLM提供的一种单次交互能力。模型在一次响应中可以输出一个“建议调用某个函数”的请求然后由开发者手动执行该函数并将结果再传回LLM进行下一轮对话。它需要开发者自己编写循环和管理状态。它更像一个演员能给出一次精彩的即兴表演建议。简单比喻用原生function calling你需要自己写舞台调度、灯光切换和提醒演员下一幕的台词。而用LangChain Agent你告诉导演Agent最终要演什么戏它来负责指挥所有演员Tools和推进剧情。在需要快速实现一个复杂、多步骤的自动化流程时LangChain Agent的开发效率优势非常明显。3. 实战构建一个多功能查询助手智能体理论说得再多不如一行代码。接下来我们构建一个实用的“多功能查询助手”。这个智能体能根据你的问题自动决定是进行网页搜索、计算数学题还是查询当前时间。我们将使用OpenAI的LLM和LangChain的最新稳定版API。3.1 环境准备与依赖安装首先确保你的Python环境在3.8以上。创建一个新的虚拟环境是个好习惯。# 创建并激活虚拟环境以conda为例 conda create -n langchain-agent python3.10 conda activate langchain-agent # 安装核心依赖 pip install langchain langchain-community langchain-openai这里解释一下包的选择langchain: LangChain核心框架。langchain-community: 包含大量第三方集成的工具和组件如一些搜索工具。langchain-openai: OpenAI模型的官方LangChain集成包。你还需要一个OpenAI的API密钥。将其设置为环境变量# 在终端中设置临时 export OPENAI_API_KEYyour-api-key-here # 或者在代码中设置 import os os.environ[“OPENAI_API_KEY”] ‘your-api-key-here’3.2 定义工具赋予智能体“手脚”我们将定义三个工具搜索、计算和获取时间。from langchain.agents import Tool from langchain_community.tools import DuckDuckGoSearchRun from langchain_community.utilities import WikipediaAPIWrapper import datetime import math import re # 工具1互联网搜索使用DuckDuckGo search DuckDuckGoSearchRun() search_tool Tool( name“Web Search” funcsearch.run, description“当需要获取最新的、实时的信息或回答关于当前事件、事实查询时使用此工具。输入应该是一个明确的搜索查询词。” ) # 工具2计算器 def calculator(query: str) - str: “”“计算一个安全的数学表达式。只支持基础算术和math库中的安全函数。”“” # 安全过滤移除危险字符和函数 safe_query re.sub(r‘[^0-9\-*/().\s]’ ‘’ query) try: # 使用eval有风险此处仅用于演示生产环境应用ast.literal_eval或专用库 # 更安全的做法是使用 numexpr 或自己写解析器 result eval(safe_query, {“__builtins__”: {}}, {“math”: math}) return str(result) except Exception as e: return f“计算错误{e} 请检查表达式 ‘{query}’ 是否合法。” calc_tool Tool( name“Calculator” funccalculator, description“用于计算数学表达式。输入应该是一个字符串格式的算术表达式例如 ‘(15 7) * 3 / 2’。支持加减乘除和括号。” ) # 工具3获取当前时间 def get_current_time(_) - str: # 参数通常由Agent传入这里我们不需要 now datetime.datetime.now() return now.strftime(“%Y-%m-%d %H:%M:%S”) time_tool Tool( name“Current Time” funcget_current_time, description“当用户询问当前时间、今天日期或类似问题时使用此工具。此工具无需输入参数。” ) # 将所有工具放入一个列表 tools [search_tool, calc_tool, time_tool]注意事项工具描述是灵魂仔细看每个工具的description它直接决定了LLM是否能在正确的时候选择它。描述要具体、说明使用场景和输入格式。安全第一计算器工具中直接使用eval是极不安全的因为它会执行任意代码。这里仅为演示简洁。在生产环境中必须使用更安全的方法如ast.literal_eval仅支持字面量、numexpr库或自己实现一个简单的表达式解析器。工具函数签名工具函数通常接收一个字符串参数即Action Input。如果工具不需要输入如获取时间函数可以定义一个参数但不使用它或者使用lambda表达式。3.3 初始化大脑与创建智能体现在我们引入“大脑”LLM并将所有部件组装起来。from langchain_openai import ChatOpenAI from langchain.agents import initialize_agent, AgentType # 1. 初始化LLM。我们使用gpt-3.5-turbo性价比高响应快。 # 温度temperature设置为0.1让输出更确定、更专注于工具调用。 llm ChatOpenAI(model“gpt-3.5-turbo” temperature0.1) # 2. 创建智能体。我们使用最常用的 ZERO_SHOT_REACT_DESCRIPTION 类型。 # 这是一种零样本Zero-Shot的ReAct代理它依靠提示词来引导推理不需要额外的示例。 agent initialize_agent( toolstools, llmllm, agentAgentType.ZERO_SHOT_REACT_DESCRIPTION, # 代理类型 verboseTrue, # 设为True可以看到智能体完整的“思考-行动”过程便于调试 handle_parsing_errorsTrue, # 优雅地处理LLM输出格式解析错误 max_iterations5, # 防止无限循环最多迭代5次 early_stopping_method“generate” # 当Agent认为可以给出最终答案时停止 )关键参数解析AgentType.ZERO_SHOT_REACT_DESCRIPTION: 这是最基础也是最常用的类型适合大多数工具调用场景。还有STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION要求LLM支持结构化输出、OPENAI_FUNCTIONS专为OpenAI的function calling优化等可根据LLM特性选择。verboseTrue:调试神器。开启后控制台会打印出Agent完整的思考链Thought、行动Action和观察Observation让你一目了然它是如何决策的。handle_parsing_errorsTrue: LLM的输出偶尔会不符合Agent预期的解析格式这个参数能防止程序因此崩溃而是尝试让LLM重新输出。max_iterations:必须设置。这是安全绳防止智能体陷入“思考-调用-再思考”的死循环。3.4 运行与测试见证智能体工作让我们用几个问题来测试我们的智能体。# 测试1需要计算和搜索的复杂问题 query1 “珠穆朗玛峰的高度是多少米把这个高度从米换算成英尺并告诉我换算结果。” print(“ 查询1:” query1 “”) result1 agent.invoke({“input”: query1}) print(“最终答案” result1[‘output’]) print(“\n” “”*50 “\n”) # 测试2简单计算 query2 “计算一下 125 的平方根加上 30 等于多少” print(“ 查询2:” query2 “”) result2 agent.invoke({“input”: query2}) print(“最终答案” result2[‘output’]) print(“\n” “”*50 “\n”) # 测试3查询时间 query3 “现在几点了” print(“ 查询3:” query3 “”) result3 agent.invoke({“input”: query3}) print(“最终答案” result3[‘output’])当verboseTrue时你会在控制台看到类似下面的输出以查询1为例 查询1: 珠穆朗玛峰的高度是多少米把这个高度从米换算成英尺并告诉我换算结果。 Entering new AgentExecutor chain... Thought: 用户的问题分为两部分首先需要知道珠穆朗玛峰的高度米然后进行单位换算。我应该先搜索珠穆朗玛峰的准确高度。 Action: Web Search Action Input: 珠穆朗玛峰 高度 米 Observation: 珠穆朗玛峰的最新测量高度约为8848.86米。 Thought: 我已经得到了高度是8848.86米。现在需要将其换算成英尺。我知道1米约等于3.28084英尺。我需要使用计算器工具。 Action: Calculator Action Input: 8848.86 * 3.28084 Observation: 29031.7 Thought: 我已经计算出了结果大约是29031.7英尺。现在我可以把这两个信息组合起来回答用户。 Action: Final Answer Final Answer: 珠穆朗玛峰的高度约为8848.86米。换算成英尺大约是29031.7英尺。 Finished chain. 最终答案 珠穆朗玛峰的高度约为8848.86米。换算成英尺大约是29031.7英尺。看到这个过程了吗智能体完美地展示了ReAct范式思考需要搜索- 行动调用搜索工具- 观察得到8848.86米- 再思考需要计算- 再行动调用计算器- 再观察得到29031.7- 最终回答。它自主地规划了步骤并选择了正确的工具。4. 性能优化与高级技巧一个能跑起来的Agent只是第一步。要让它在生产环境中可靠、高效地运行还需要考虑很多问题。4.1 工具调用速度的影响因素与优化LangChain工具调用的速度瓶颈通常不在LangChain框架本身而在以下几个环节LLM API调用延迟这是最主要的影响因素。每次Agent“思考”都需要请求一次LLM API。GPT-3.5-Turbo比GPT-4快但能力稍弱。优化方法选择合适的模型在精度允许的情况下使用更快的模型。优化提示词清晰、简洁的提示词能让LLM更快地理解意图减少“胡思乱想”有时还能减少请求的token数。设置合理的超时和重试在初始化LLM时配置request_timeout参数。工具本身的执行时间如果你的工具需要查询一个慢速数据库、调用一个响应慢的外部API那么整个Agent就会被阻塞。优化方法工具异步化将工具函数定义为async函数并使用支持异步的Agent执行器如initialize_agent支持异步。设置工具超时在自定义工具内部实现超时逻辑避免一个失败的工具拖垮整个Agent。缓存对耗时且结果不常变动的工具如某些数据查询引入缓存机制。Agent的迭代次数不必要的迭代会显著增加延迟。优化方法精确的工具描述避免LLM因误解而选错工具导致无效迭代。设置max_iterations根据任务复杂度合理设置通常5-10次足够。使用更高效的Agent类型对于简单任务可以尝试AgentType.OPENAI_FUNCTIONS它利用OpenAI原生的function calling可能更高效。4.2 处理复杂逻辑与状态管理LangGraph的引入我们上面构建的Agent是线性的“思考-行动”循环。但现实世界的任务往往更复杂可能包含分支、循环、并行执行或者需要维护一个跨多轮对话的复杂状态。这时基础的AgentExecutor就显得力不从心了。这就是LangGraph出场的时候。你可以把LangGraph理解为LangChain的“工作流引擎”或“状态机管理器”。它允许你用图Graph的形式来定义Agent的执行流程节点Node可以是调用LLM、执行工具、条件判断边Edge定义了节点之间的流转逻辑。一个简单对比LangChain Agent像是一个有固定套路的流水线适合顺序性强的任务。LangChain LangGraph像是一个可以自定义的流程图适合有分支、循环、并行等复杂逻辑的任务。例如你可以构建一个这样的智能体流程用户提出一个复杂分析请求。Agent节点决定需要调用A、B两个工具并行获取数据。两个工具节点并行执行。所有数据收集完成后进入一个“合成”节点调用LLM分析数据并生成报告。根据报告内容决定是直接返回给用户还是再调用一个“发送邮件”的工具节点。实操心得对于绝大多数工具调用场景基础的AgentExecutor已经足够强大。只有当你需要显式地控制执行流比如“先做A如果A成功再做B否则做C”或者任务步骤间有复杂的依赖关系时才需要考虑引入LangGraph。它增加了架构的复杂性但也提供了无与伦比的灵活性和控制力。4.3 错误处理与鲁棒性提升一个健壮的Agent必须能妥善处理各种意外。工具调用失败网络错误、API限流、资源不存在等。应该在工具函数内部做好异常捕获返回清晰的错误信息如“搜索服务暂时不可用”而不是抛出异常导致整个Agent崩溃。Agent的LLM大脑通常能理解这些错误信息并尝试其他方案或告知用户。LLM输出格式错误尽管有handle_parsing_errorsTrue但有时LLM会输出完全无法解析的内容。更健壮的做法是自定义一个OutputParser或者使用AgentType.STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION这类依赖LLM结构化输出如JSON的代理类型容错性更好。无限循环除了设置max_iterations还可以观察Thought。如果连续几轮的Thought内容重复或毫无进展可以在自定义回调中实现更早的中断逻辑。输入安全与过滤永远不要相信用户输入或LLM生成的工具参数。在工具函数内部对输入进行严格的验证、清洗和转义防止注入攻击或其他安全漏洞。前面计算器工具的安全风险就是一个典型例子。5. 从Demo到生产关键考量与部署实践让一个Agent在本地跑起来和让它稳定服务成百上千的用户是两回事。以下是走向生产环境必须考虑的几点。5.1 监控、日志与可观测性“黑盒”是AI应用的大忌。你必须知道你的Agent每天都在做什么哪里慢了哪里出错了。结构化日志记录每一轮交互的ThoughtActionAction InputObservation以及最终输出。这不仅是调试的依据也是优化提示词、分析用户意图的宝贵数据。关键指标监控延迟平均响应时间、P95/P99响应时间。成本每次调用消耗的Token数特别是输入Token因为通常更贵。成功率任务完成率 vs. 中途失败率。工具使用分布哪个工具被调用得最频繁哪个最容易出错链路追踪TracingLangChain内置了对LangSmith的良好支持。LangSmith是一个可视化平台可以像看分布式系统调用链一样查看一次Agent调用的完整生命周期每个组件的耗时、输入输出一目了然是开发和调试的利器。5.2 成本控制策略LLM API调用是按Token收费的尤其是使用高性能模型时成本可能快速增长。对话历史管理AgentExecutor会默认将完整的对话历史包括冗长的工具观察结果传递给下一轮思考。这会导致Token消耗快速增长。需要合理设置max_token_limit或使用ConversationSummaryBufferMemory等记忆组件来压缩历史只保留精华。工具描述的精简在保证清晰的前提下尽量精简工具的description减少不必要的Token。模型分级使用对于简单的工具选择或格式化任务可以考虑使用更便宜、更快的模型如GPT-3.5-Turbo对于复杂的合成、推理步骤再使用更强的模型如GPT-4。这需要更精细的架构设计例如使用LangGraph来路由不同的任务到不同的模型。5.3 部署模式选择Web API服务最常用的方式。使用FastAPI或Flask将你的Agent封装成RESTful API。注意处理好并发、异步和生命周期管理。from fastapi import FastAPI app FastAPI() # 注意在生产中Agent实例的创建和初始化需要考虑并发安全性和资源复用。 # 通常需要依赖注入或全局状态管理。 app.post(“/ask”) async def ask_agent(query: str): result await agent.ainvoke({“input”: query}) # 使用异步调用 return {“answer”: result[“output”]}异步任务队列对于耗时较长的Agent任务如需要调用多个慢速工具不适合同步HTTP请求。可以将其放入Celery或RQ等任务队列通过WebSocket或轮询向客户端返回结果。容器化与云原生使用Docker将你的Agent应用及其所有依赖打包。结合Kubernetes可以轻松实现扩缩容、滚动更新和高可用部署。构建AI Agent的过程是一个不断在“智能”与“可控”、“灵活”与“稳定”之间寻找平衡点的过程。从定义一个清晰的工具开始到设计高效的提示词再到处理各种边界情况和性能优化每一步都需要开发者既理解AI的能力也理解软件工程的规范。LangChain提供的这套范式极大地降低了入门门槛但真正打造一个能在生产环境创造价值的智能体考验的仍然是开发者的综合设计能力和对业务需求的深刻理解。我个人的体会是开始时不必追求大而全从一个能解决具体痛点的小工具集入手让它稳定可靠地运行起来再逐步扩展其能力和边界这条路会走得更加扎实。