1. 项目概述为什么我们需要一个统一的智能体入口如果你最近在折腾LangChain尤其是想把手头的几个工具链、几个大模型API和一堆记忆模块拼成一个能“自己动”的智能体那你大概率会和我一样在某个深夜对着满屏的AgentExecutor、Tool、LLMChain和五花八门的initialize_agent方法感到头疼。代码越写越乱不同版本的Agent初始化方式还不一样调试起来像在走迷宫。这正是create_agent这个函数试图解决的问题——它想成为LangChain智能体世界的那个“总开关”一个统一、清晰、可预测的入口。简单来说create_agent是LangChain框架中一个高阶的、面向未来的工厂函数。它的核心目标不是引入什么惊天动地的新功能而是标准化和简化智能体的创建流程。在过去你要创建一个能使用工具、拥有记忆、并能根据目标规划行动的智能体可能需要手动组合多个底层组件处理复杂的回调函数并且代码风格因版本迭代而差异巨大。create_agent把这些繁琐的步骤封装起来提供一套声明式的API。你只需要告诉它“我需要一个智能体用这个模型配这些工具记忆机制这样设置”它就能给你返回一个配置好、立即可用的AgentExecutor实例。这解决了几个实际开发中的痛点第一是降低入门和使用的认知负担新手不用再深究ReAct、Self-ask-with-search这些架构的内部细节也能快速搭建可用的智能体第二是提升代码的可维护性和一致性团队内部可以用同一套模式创建智能体便于协作和代码审查第三是更好地适应LangChain向更模块化、可组合性发展的趋势create_agent本身可以看作是对底层强大但分散的Agent、Tools、Memory等模块的一次友好封装。对于正在寻找智能体开发最佳实践的开发者无论是想快速验证一个客服机器人原型还是构建一个复杂的、多步骤的数据分析流水线理解并掌握create_agent的使用都能让你的开发效率提升一个档次。它就像乐高积木的说明书告诉你如何用标准件搭出既稳固又富有创意的作品。2. 核心设计思路从“散装零件”到“一体化套件”要理解create_agent的价值我们得先看看没有它的时候我们是怎么“拼装”智能体的。传统的LangChain智能体创建更像是在操作一台精密仪器的内部电路。2.1 传统方式的“组装之痛”在create_agent出现之前一个典型的智能体创建流程可能长这样以使用OpenAI模型和ReAct框架为例from langchain.agents import AgentExecutor, initialize_agent from langchain.agents.react.agent import create_react_agent from langchain_openai import ChatOpenAI from langchain.tools import Tool from langchain.memory import ConversationBufferMemory # 1. 定义工具 def search_api(query: str) - str: # 模拟搜索工具 return f搜索结果: {query} search_tool Tool(nameSearch, funcsearch_api, description用于搜索信息) # 2. 准备LLM和Prompt llm ChatOpenAI(modelgpt-4, temperature0) # 需要手动找到或编写对应的Prompt模板 from langchain.agents.react.agent import ReActDocstoreAgent prompt ReActDocstoreAgent.create_prompt([search_tool]) # 3. 创建Agent链底层 agent create_react_agent(llm, [search_tool], prompt) # 4. 包装成执行器并加入记忆 memory ConversationBufferMemory(memory_keychat_history) agent_executor AgentExecutor.from_agent_and_tools( agentagent, tools[search_tool], memorymemory, verboseTrue, handle_parsing_errorsTrue )这个过程暴露了几个问题组件分散你需要从不同的模块导入AgentExecutor、特定的Agent类如create_react_agent、Tool、Memory并对它们之间的依赖关系有清晰了解。版本兼容性差initialize_agent函数在不同LangChain版本中参数和返回值可能发生变化老代码容易在新版本中报错。配置繁琐记忆Memory的挂载、错误处理handle_parsing_errors、详细日志verbose等配置项需要在多个地方设置容易遗漏。缺乏统一范式对于不同的Agent类型如Plan-and-Execute, OpenAI Functions初始化方式可能完全不同增加了学习成本。2.2create_agent的“一体化”哲学create_agent的设计哲学非常明确约定优于配置封装复杂细节提供流畅体验。它试图将上述所有步骤收敛到一个函数调用中。其核心设计思路体现在以下几个层面参数化驱动将所有可配置项——大模型llm、工具列表tools、系统提示词system_prompt、记忆memory、Agent类型agent_type等——都作为函数的参数。开发者通过调整参数来定制智能体而不是修改组装逻辑。智能默认值对于大多数常见场景create_agent提供了合理的默认值。例如如果不指定agent_type它可能会根据提供的tools和llm的能力自动选择一个最合适的类型如支持函数调用的模型会默认使用openai-functions类型的Agent。返回即用函数直接返回一个配置完备的AgentExecutor或类似的可执行对象而不是一个中间态的Agent对象。这意味着你拿到手的就是可以开始对话或执行任务的智能体无需再进行额外的包装。面向未来扩展其参数设计考虑了未来的扩展性比如预留了agent_executor_kwargs参数允许你将自定义参数直接传递给底层的AgentExecutor构造函数保证了底层能力的可访问性。注意create_agent目前可能仍在LangChain的某些版本中处于experimental或快速迭代阶段。在实际使用前请务必查阅你所使用版本对应的官方文档确认其确切的导入路径、参数列表和默认行为。直接使用from langchain.agents import create_agent可能不总是有效有时需要从langchain_experimental或特定子模块导入。这种设计带来的直接好处是代码的极度简洁。上面那个传统的例子用create_agent可以重构为from langchain.agents import create_agent from langchain_openai import ChatOpenAI from langchain.tools import Tool from langchain.memory import ConversationBufferMemory # 定义工具同上 def search_api(query: str) - str: return f搜索结果: {query} search_tool Tool(nameSearch, funcsearch_api, description用于搜索信息) # 一行代码创建智能体 llm ChatOpenAI(modelgpt-4, temperature0) memory ConversationBufferMemory(memory_keychat_history) agent_executor create_agent( llmllm, tools[search_tool], system_prompt你是一个有帮助的助手。, memorymemory, verboseTrue, # agent_typeopenai-functions, # 可明确指定不指定则自动推断 handle_parsing_errorsTrue )代码量减少了近一半逻辑却更加清晰直观。所有配置“所见即所得”大大提升了开发体验。3. 核心参数深度解析与实战配置create_agent的强大和灵活性很大程度上来自于其丰富的参数。理解每个参数的含义、适用场景以及它们之间的相互作用是玩转这个统一入口的关键。下面我们来逐一拆解。3.1 基石参数llm,tools,agent_type这三个参数定义了智能体的“大脑”、“双手”和“思考方式”。llm(Large Language Model)这是智能体的核心引擎。你可以传入任何与LangChain兼容的LLM实例如ChatOpenAI、ChatAnthropic、ChatGoogleGenerativeAI或者本地部署的模型通过ChatOllama等接口接入。选择依据根据任务复杂度、成本、响应速度和对特定功能如函数调用的支持来选择。例如处理复杂推理可选GPT-4简单对话可用GPT-3.5-turbo以节省成本。实操技巧务必设置合理的temperature创造性通常0-0.7用于智能体和max_tokens防止无限输出。对于生产环境建议配置重试和超时逻辑可以封装一个自定义的LLM类或使用llm ChatOpenAI(...).with_retry(...)。tools(List[BaseTool])工具是智能体与外部世界交互的桥梁。一个工具就是一个可执行的函数附带名称和描述。创建工具除了使用Tool类更推荐使用tool装饰器它能自动从函数文档字符串docstring中提取描述非常方便。from langchain.tools import tool tool def get_weather(city: str) - str: 根据城市名称获取当前天气信息。 # 这里调用真实天气API return f{city}的天气是晴25摄氏度。 tool def calculator(expression: str) - str: 计算一个数学表达式的结果。 try: result eval(expression) # 注意生产环境请使用更安全的评估方法如ast.literal_eval return str(result) except Exception as e: return f计算错误: {e}工具描述的重要性LLM完全依赖工具的描述来决定何时、如何使用它。描述必须清晰、准确说明输入是什么、输出是什么、工具的作用。模糊的描述会导致智能体误用或不用工具。工具数量不是越多越好。工具过多会增加LLM的选择负担可能导致混乱。通常为一个特定领域的智能体配备5-10个高度相关的工具效果最佳。agent_type(str)这是决定智能体“思考范式”的关键参数。不同的agent_type对应不同的推理框架。openai-functions当前最推荐、最稳定的类型之一。它要求LLM必须支持OpenAI风格的函数调用如GPT-3.5/4, Claude等。它的工作原理是让LLM输出一个结构化的函数调用请求然后系统执行对应的工具。这种方式解析稳定可靠性高。react经典的“Reasoning and Acting”框架。智能体会以“Thought: ... Action: ... Observation: ...”的格式进行链式思考。它不要求LLM有特殊的函数调用能力通用性更强但有时输出格式可能不稳定需要依赖良好的Prompt工程和解析逻辑。plan-and-execute一种更复杂的框架智能体会先制定一个多步骤的计划Plan然后逐步执行Execute。适合需要严格顺序或前置条件检查的复杂任务。self-ask-with-search适合需要中间答案多跳问答的任务。选择策略优先使用openai-functions除非你的模型不支持。如果模型不支持且任务简单用react。对于极其复杂、需要宏观规划的任务可以考虑plan-and-execute。如果不指定create_agent会根据LLM的能力尝试自动选择。3.2 记忆与上下文管理memory和system_prompt智能体不是一次性的问答机持续的对话能力离不开记忆。memoryLangChain提供了多种记忆后端。ConversationBufferMemory最简单的记忆保存完整的对话历史。适用于短对话长对话会导致上下文过长。ConversationBufferWindowMemory只保留最近K轮对话防止上下文爆炸。ConversationSummaryMemory让LLM对历史对话进行总结只保存总结摘要能极大地压缩上下文长度适合长周期对话。VectorStoreRetrieverMemory将记忆存储到向量数据库如Chroma可以根据当前问题语义检索相关记忆非常强大但更复杂。配置要点记忆对象有一个memory_key参数默认常为chat_history这个键名必须与Agent的Prompt模板中用于放置历史消息的变量名一致。create_agent通常会帮你处理好这个映射。system_prompt(str)系统提示词是塑造智能体角色和行为准则的“宪法”。一个好的system_prompt应该明确角色“你是一个专业的金融数据分析助手。”规定能力范围“你可以使用提供的工具查询股票价格、计算指标但无法提供投资建议。”设定回答风格“请用清晰、有条理的方式回答先给出结论再展示分析过程。”包含格式指令如果Agent类型需要“请严格按照‘Thought: ... Action: ... Observation: ...’的格式进行推理。”技巧将重要的、不希望被遗忘的指令放在system_prompt中而不是用户的第一句话里。3.3 高级控制与错误处理verbose(bool)设置为True时会在控制台打印出智能体详细的思考过程Thought、行动Action和观察Observation。这是调试智能体逻辑的必备工具能让你清晰地看到它是如何一步步做出决策的。handle_parsing_errors(bool)强烈建议设置为True。当LLM的输出不符合工具调用的预期格式时这是常见错误这个开关会让智能体尝试修复或给出友好错误提示而不是直接崩溃。max_iterations(int) 和max_execution_time(float)安全护栏。智能体可能会陷入“思考-行动”的死循环。max_iterations限制循环次数默认通常为15max_execution_time限制总执行时间。务必设置防止无限循环消耗资源。agent_executor_kwargs(dict)这是一个“逃生舱”参数用于将额外的、更底层的配置传递给最终创建的AgentExecutor。例如你可以通过它来设置自定义的回调函数callbacks进行日志记录或监控。3.4 参数配置表示例下表总结了核心参数的典型配置场景参数适用场景推荐配置/示例注意事项llm通用对话、成本敏感ChatOpenAI(modelgpt-3.5-turbo, temperature0)注意API速率限制和成本。复杂推理、代码生成ChatOpenAI(modelgpt-4, temperature0.1)GPT-4 API调用更慢更贵。使用本地模型ChatOllama(modelqwen2.5:7b, temperature0)需确保Ollama服务已启动。agent_type模型支持函数调用openai-functions最稳定首选。模型不支持函数调用react需确保Prompt模板匹配。复杂多步骤任务规划plan-and-execute架构更重响应可能更慢。memory短对话、调试ConversationBufferMemory()对话长了会撑爆上下文。长对话、聊天机器人ConversationSummaryMemory(llmllm)需要额外传入一个LLM来总结。知识密集型对话VectorStoreRetrieverMemory(retrieverretriever)搭建和维护更复杂。system_prompt角色定义“你是一个幽默的编程助手擅长Python。”描述越具体行为越可控。安全约束“你绝不能生成有害或违法内容。”重要的约束必须写在这里。verbose开发调试阶段True生产环境建议设为False。handle_parsing_errors所有生产环境True务必开启提升鲁棒性。max_iterations所有环境10(可根据任务调整)防止智能体“鬼打墙”。4. 从零到一构建一个多功能个人助理智能体理论说得再多不如动手实践。让我们用create_agent来构建一个真正的智能体——一个能查天气、做计算、搜索网络模拟并记住我们喜好的个人助理。4.1 环境准备与工具定义首先确保安装必要的库并准备好API密钥这里以OpenAI为例。pip install langchain langchain-openai接下来在Python中开始构建。我们先定义三个核心工具天气查询、计算器和网络搜索模拟。import os from langchain.tools import tool from langchain_openai import ChatOpenAI from langchain.memory import ConversationSummaryMemory from langchain.agents import create_agent from langchain.agents.agent import AgentExecutor # 假设你的OpenAI API Key已设置在环境变量中 os.environ[OPENAI_API_KEY] your-api-key-here # 1. 定义工具集 tool def get_weather(city: str) - str: 根据城市名称获取当前的天气情况和温度。输入应为一个城市名例如‘北京’或‘New York’。 这是一个模拟工具实际应用中应接入真实天气API。 # 模拟API调用和响应 weather_data { 北京: 晴25°C微风, 上海: 多云28°C东南风3级, New York: Partly Cloudy, 68°F, Wind NW 5 mph } return weather_data.get(city, f抱歉未找到{city}的天气信息。模拟返回晴22°C) tool def calculator(expression: str) - str: 计算一个数学表达式的结果。支持加减乘除(-*/)、乘方(**)和括号。 例如‘(35)*2’, ‘10**2’。注意生产环境请勿使用eval此处仅为演示。 try: # 警告eval有安全风险仅用于演示。实际项目应使用ast.literal_eval或数学解析库。 allowed_names {} result eval(expression, {__builtins__: None}, allowed_names) return f计算结果: {result} except Exception as e: return f计算错误请检查表达式格式: {e} tool def web_search(query: str) - str: 在互联网上搜索相关信息。输入为一个搜索查询字符串。 这是一个模拟工具实际应用中应接入Serper API、Google Search API等。 # 模拟搜索返回 return f关于‘{query}’的模拟搜索结果\n1. 相关概念解释。\n2. 最新发展动态。\n3. 实用链接示例。4.2 集成记忆与创建智能体现在我们将工具、LLM、记忆组合起来使用create_agent一键创建智能体。# 2. 初始化LLM和记忆 llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 使用总结记忆适合更长的对话 memory ConversationSummaryMemory( llmllm, # 需要传入一个LLM来总结对话 memory_keychat_history, return_messagesTrue ) # 3. 准备工具列表 tools [get_weather, calculator, web_search] # 4. 定义系统提示词塑造助理性格 system_prompt 你是一个名叫‘小智’的万能个人助理。你性格热情、细致并且拥有强大的工具使用能力。 你的能力包括 1. 查询全球主要城市的当前天气。 2. 进行复杂的数学计算。 3. 在互联网上搜索最新信息。 请遵循以下规则 - 每次使用工具前请先简要说明你将做什么。 - 如果用户的问题需要多个工具协作请一步步来并解释每一步。 - 如果用户的问题模糊请友好地请求澄清。 - 记住对话历史使交流具有连贯性。 现在开始帮助用户吧 # 5. 核心步骤使用create_agent创建智能体执行器 agent_executor: AgentExecutor create_agent( llmllm, toolstools, agent_typeopenai-functions, # 使用最稳定的OpenAI函数代理 system_promptsystem_prompt, memorymemory, verboseTrue, # 打开详细日志方便观察思考过程 handle_parsing_errorsTrue, # 关键处理LLM输出解析错误 max_iterations5, # 防止无限循环 # 可以通过agent_executor_kwargs传递更多底层参数 # agent_executor_kwargs{early_stopping_method: generate} ) print(智能体‘小智’已启动)4.3 与智能体交互及结果分析让我们运行几个查询看看智能体是如何工作的。打开verboseTrue后我们能在控制台看到完整的推理链。# 示例对话 1简单查询 print( 用户今天北京天气怎么样 ) result1 agent_executor.invoke({input: 今天北京天气怎么样}) print(f助理{result1[output]}\n) # 示例对话 2需要计算和上下文记忆 print( 用户上海呢另外帮我算下去北京如果待3天每天预算500元总共要多少。 ) result2 agent_executor.invoke({input: 上海呢另外帮我算下去北京如果待3天每天预算500元总共要多少。}) print(f助理{result2[output]}\n) # 示例对话 3复杂任务需要搜索 print( 用户根据天气和预算搜索一下‘北京三日游攻略’。 ) result3 agent_executor.invoke({input: 根据天气和预算搜索一下‘北京三日游攻略’。}) print(f助理{result3[output]})执行过程解析观察verbose日志当你运行第一个查询时控制台会打印类似以下内容 Entering new AgentExecutor chain... Thought: 用户询问北京的天气。我有一个工具叫get_weather可以查询天气。我需要使用它。 Action:{ action: get_weather, action_input: {city: 北京} }Observation: 晴25°C微风 Thought: 我已经获取了北京的天气信息现在可以回答用户了。 Final Answer: 今天北京的天气是晴天温度25摄氏度有微风。 Finished chain.这个过程清晰展示了ReAct思考-行动-观察模式在openai-functions代理下的工作流程尽管输出是结构化的JSON。对于第二个查询智能体会识别出“上海呢”是承接上文询问天气因此调用get_weather(“上海”)。识别出计算预算是一个数学问题调用calculator(“3 * 500”)。将两个工具的结果整合并结合记忆知道之前聊过北京天气给出连贯回答。实操心得verboseTrue是调试神器任何智能体行为不符合预期时首先看它的“思考”过程。智能体成功的关键在于工具描述和系统提示词。如果智能体不调用某个工具检查工具的描述是否足够清晰能否让LLM理解其用途和输入格式。记忆的测试需要多轮对话。你可以问“我刚刚问了哪个城市的天气”看看它是否能从ConversationSummaryMemory中正确回忆起摘要信息。5. 避坑指南与高级调试技巧即使有了create_agent这样的利器在实际开发中你依然会遇到各种“坑”。下面是我在多个项目中总结出的常见问题及其解决方案。5.1 常见错误与排查表问题现象可能原因排查步骤与解决方案错误ValidationError或TypeError提示agent_type无效1. LangChain版本过旧不支持create_agent。2. 拼写错误或使用了不支持的agent_type值。1. 升级LangChain:pip install -U langchain。2. 检查官方文档确认当前版本支持的agent_type列表。通常为openai-functions,react,plan-and-execute等。智能体完全不调用工具只用自己的知识回答1. 工具描述description太模糊或与问题不匹配。2.system_prompt中没有强调使用工具。3. LLM的temperature太高导致输出过于随机。1.优化工具描述确保描述清晰说明功能、输入格式和输出示例。例如“计算数学表达式”改为“计算一个包含数字和运算符-*/**的字符串表达式的结果”。2.强化系统指令在system_prompt中加入“你必须使用提供的工具来回答问题”等强制语句。3.降低temperature尝试设为0或0.1让LLM更专注于遵循指令。智能体陷入循环不断重复同一个工具调用1. 工具返回的结果无法满足停止条件。2.max_iterations设置过高或未设置。3. Agent类型如react的Prompt模板中停止指令不明确。1.检查工具输出确保工具在完成任务或出错时返回明确的、可被解析的字符串。2.设置max_iterations务必设置一个合理的值如5-10。3.使用openai-functions代理它通常比react代理有更稳定的停止逻辑。4. 查看verbose日志观察每次“Observation”后“Thought”是否在推进。错误API error: 400 ... context length ...对话历史记忆太长超过了LLM模型的最大上下文长度。1.使用摘要记忆用ConversationSummaryMemory替代ConversationBufferMemory。2.限制记忆长度使用ConversationBufferWindowMemory(k5)只保留最近5轮对话。3.在system_prompt中精简移除不必要的背景信息。错误API error: 400 ‘type’ must be in [“enabled”, “disabled”, “auto”]此错误通常与特定模型的API参数有关而非LangChain本身。例如某些平台在调用DeepSeek等模型时对请求体中的stream或stream_options参数有特定要求。1.检查LLM客户端配置确认你使用的ChatOpenAI或类似客户端是否传入了模型不支持的参数。2.查阅对应模型的API文档例如DeepSeek-V4模型可能要求stream_options参数为特定值。解决方案可能是在初始化LLM时设置streamingFalse或传递特定的model_kwargs。3.使用官方适配器优先使用LangChain官方维护的对应模型聊天类如ChatDeepSeek它们会处理好兼容性。handle_parsing_errorsTrue但智能体还是崩溃了解析错误处理逻辑无法修复某些严重的格式错误。1.查看完整错误栈找到最根本的解析错误信息。2.检查Prompt模板确保agent_type与Prompt模板匹配。自定义Prompt时尤其容易出错。3.尝试更简单的任务先用一个工具、一个简单问题测试排除工具本身的问题。5.2 性能优化与最佳实践工具设计的黄金法则单一职责一个工具只做一件事。不要做一个“万能查询工具”而应拆分成“查询天气”、“查询股价”、“查询新闻”等。健壮性工具函数内部必须有完善的错误处理try-catch返回对智能体友好的错误信息而不是抛出异常导致整个链条中断。异步支持如果工具涉及网络I/O如调用外部API考虑将其实现为异步函数async def并使用支持异步的Agent执行器如AgentExecutor.ainvoke来提升并发性能。管理上下文长度 这是生产环境中最常见的问题。除了使用摘要记忆还可以定期清理记忆在长时间对话后主动调用memory.clear()或实现一个逻辑在对话轮数达到一定阈值后触发清理。选择性记忆使用VectorStoreRetrieverMemory它只存储和检索最相关的历史片段而非全部能有效利用长上下文模型。为生产环境做好准备关闭verbose生产环境日志中打印完整的思考链会非常冗长且可能包含敏感信息。设置超时和重试为LLM调用和工具调用配置超时request_timeout和自动重试逻辑增强系统的鲁棒性。监控与评估记录智能体的输入、输出、工具调用记录和耗时。这有助于分析效果、发现瓶颈和优化提示词。探索LangGraph以构建更复杂的智能体 对于需要严格状态机、循环、分支或多人协作的复杂智能体工作流create_agent可能显得力不从心。这时LangGraph是更强大的选择。你可以将create_agent创建的智能体作为LangGraph中的一个“节点”agent_node与其他逻辑节点如条件判断、人工审核节点组合构建出有向图结构的工作流。这实现了从“单兵智能体”到“多智能体协作系统”的飞跃。6. 超越create_agent与LangChain生态的深度集成create_agent是一个优秀的起点但真正的力量在于将其融入更广阔的LangChain生态系统。这里探讨两个高级集成场景。6.1 嵌入RAG检索增强生成流程智能体擅长使用工具执行动作而RAG擅长从专有知识库中获取信息。将它们结合可以打造出知识渊博且行动力强的超级助手。思路将整个RAG链检索器 问答链包装成一个“超级工具”提供给create_agent。from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain.chains import RetrievalQA from langchain.tools import Tool # 1. 假设我们已经有一个加载了文档的向量数据库 embeddings OpenAIEmbeddings() vectorstore Chroma(persist_directory./my_db, embedding_functionembeddings) retriever vectorstore.as_retriever() # 2. 创建一个标准的RAG问答链 qa_chain RetrievalQA.from_chain_type( llmllm, # 使用同一个或另一个LLM chain_typestuff, retrieverretriever ) # 3. 将RAG链包装成一个工具 tool def query_knowledge_base(question: str) - str: 在内部知识库中搜索信息来回答问题。输入是一个完整的问题句子。 # 直接调用RAG链 result qa_chain.invoke({query: question}) return result[result] # 4. 将这个知识库工具和其他工具一起交给create_agent tools [get_weather, calculator, query_knowledge_base, web_search] agent_with_rag create_agent(llmllm, toolstools, agent_typeopenai-functions) # 现在智能体既能回答“公司Q3财报的核心数据是什么”从知识库 # 也能回答“基于这份财报计算一下毛利率”调用计算器。6.2 利用回调系统进行监控和日志记录LangChain提供了强大的回调Callback系统允许你在智能体执行的各个生命周期节点注入自定义逻辑这对于监控、审计和调试至关重要。from langchain.callbacks.base import BaseCallbackHandler import logging # 自定义回调处理器 class AgentMonitorCallback(BaseCallbackHandler): def on_agent_action(self, action, **kwargs): # 当智能体决定调用一个工具时触发 tool_name action.tool tool_input action.tool_input logging.info(f️ 智能体即将执行工具: {tool_name}, 输入: {tool_input}) def on_tool_end(self, output, **kwargs): # 当一个工具执行完毕时触发 logging.info(f✅ 工具执行完成输出: {output[:100]}...) # 只记录前100字符 def on_agent_finish(self, finish, **kwargs): # 当智能体完成一轮推理时触发 final_output finish.return_values[output] logging.info(f 智能体任务完成最终输出: {final_output}) # 创建带回调的智能体 callbacks [AgentMonitorCallback()] agent_executor create_agent( llmllm, toolstools, agent_typeopenai-functions, verboseFalse, # 可以关闭默认的verbose用自定义回调记录 agent_executor_kwargs{callbacks: callbacks} # 通过此参数传入回调 ) # 现在所有的工具调用和完成事件都会被记录到日志中。通过回调你可以轻松地将执行日志发送到监控系统如Prometheus/Grafana、数据库或消息队列实现生产级别的可观测性。create_agent作为LangChain智能体开发的统一入口其价值在于将最佳实践固化为了简洁的API。它降低了上手门槛让开发者能更专注于智能体本身的行为设计和工具赋能而不是框架的组装细节。从快速原型到复杂系统它都是一个可靠的基础。当你熟练运用它之后不妨再向更深处探索比如用LangGraph编排智能体工作流或者深入研究不同Agent类型的底层原理那时你对智能体开发的理解将会达到一个新的层次。 LangChain智能体开发：create_agent统一入口详解与实战
1. 项目概述为什么我们需要一个统一的智能体入口如果你最近在折腾LangChain尤其是想把手头的几个工具链、几个大模型API和一堆记忆模块拼成一个能“自己动”的智能体那你大概率会和我一样在某个深夜对着满屏的AgentExecutor、Tool、LLMChain和五花八门的initialize_agent方法感到头疼。代码越写越乱不同版本的Agent初始化方式还不一样调试起来像在走迷宫。这正是create_agent这个函数试图解决的问题——它想成为LangChain智能体世界的那个“总开关”一个统一、清晰、可预测的入口。简单来说create_agent是LangChain框架中一个高阶的、面向未来的工厂函数。它的核心目标不是引入什么惊天动地的新功能而是标准化和简化智能体的创建流程。在过去你要创建一个能使用工具、拥有记忆、并能根据目标规划行动的智能体可能需要手动组合多个底层组件处理复杂的回调函数并且代码风格因版本迭代而差异巨大。create_agent把这些繁琐的步骤封装起来提供一套声明式的API。你只需要告诉它“我需要一个智能体用这个模型配这些工具记忆机制这样设置”它就能给你返回一个配置好、立即可用的AgentExecutor实例。这解决了几个实际开发中的痛点第一是降低入门和使用的认知负担新手不用再深究ReAct、Self-ask-with-search这些架构的内部细节也能快速搭建可用的智能体第二是提升代码的可维护性和一致性团队内部可以用同一套模式创建智能体便于协作和代码审查第三是更好地适应LangChain向更模块化、可组合性发展的趋势create_agent本身可以看作是对底层强大但分散的Agent、Tools、Memory等模块的一次友好封装。对于正在寻找智能体开发最佳实践的开发者无论是想快速验证一个客服机器人原型还是构建一个复杂的、多步骤的数据分析流水线理解并掌握create_agent的使用都能让你的开发效率提升一个档次。它就像乐高积木的说明书告诉你如何用标准件搭出既稳固又富有创意的作品。2. 核心设计思路从“散装零件”到“一体化套件”要理解create_agent的价值我们得先看看没有它的时候我们是怎么“拼装”智能体的。传统的LangChain智能体创建更像是在操作一台精密仪器的内部电路。2.1 传统方式的“组装之痛”在create_agent出现之前一个典型的智能体创建流程可能长这样以使用OpenAI模型和ReAct框架为例from langchain.agents import AgentExecutor, initialize_agent from langchain.agents.react.agent import create_react_agent from langchain_openai import ChatOpenAI from langchain.tools import Tool from langchain.memory import ConversationBufferMemory # 1. 定义工具 def search_api(query: str) - str: # 模拟搜索工具 return f搜索结果: {query} search_tool Tool(nameSearch, funcsearch_api, description用于搜索信息) # 2. 准备LLM和Prompt llm ChatOpenAI(modelgpt-4, temperature0) # 需要手动找到或编写对应的Prompt模板 from langchain.agents.react.agent import ReActDocstoreAgent prompt ReActDocstoreAgent.create_prompt([search_tool]) # 3. 创建Agent链底层 agent create_react_agent(llm, [search_tool], prompt) # 4. 包装成执行器并加入记忆 memory ConversationBufferMemory(memory_keychat_history) agent_executor AgentExecutor.from_agent_and_tools( agentagent, tools[search_tool], memorymemory, verboseTrue, handle_parsing_errorsTrue )这个过程暴露了几个问题组件分散你需要从不同的模块导入AgentExecutor、特定的Agent类如create_react_agent、Tool、Memory并对它们之间的依赖关系有清晰了解。版本兼容性差initialize_agent函数在不同LangChain版本中参数和返回值可能发生变化老代码容易在新版本中报错。配置繁琐记忆Memory的挂载、错误处理handle_parsing_errors、详细日志verbose等配置项需要在多个地方设置容易遗漏。缺乏统一范式对于不同的Agent类型如Plan-and-Execute, OpenAI Functions初始化方式可能完全不同增加了学习成本。2.2create_agent的“一体化”哲学create_agent的设计哲学非常明确约定优于配置封装复杂细节提供流畅体验。它试图将上述所有步骤收敛到一个函数调用中。其核心设计思路体现在以下几个层面参数化驱动将所有可配置项——大模型llm、工具列表tools、系统提示词system_prompt、记忆memory、Agent类型agent_type等——都作为函数的参数。开发者通过调整参数来定制智能体而不是修改组装逻辑。智能默认值对于大多数常见场景create_agent提供了合理的默认值。例如如果不指定agent_type它可能会根据提供的tools和llm的能力自动选择一个最合适的类型如支持函数调用的模型会默认使用openai-functions类型的Agent。返回即用函数直接返回一个配置完备的AgentExecutor或类似的可执行对象而不是一个中间态的Agent对象。这意味着你拿到手的就是可以开始对话或执行任务的智能体无需再进行额外的包装。面向未来扩展其参数设计考虑了未来的扩展性比如预留了agent_executor_kwargs参数允许你将自定义参数直接传递给底层的AgentExecutor构造函数保证了底层能力的可访问性。注意create_agent目前可能仍在LangChain的某些版本中处于experimental或快速迭代阶段。在实际使用前请务必查阅你所使用版本对应的官方文档确认其确切的导入路径、参数列表和默认行为。直接使用from langchain.agents import create_agent可能不总是有效有时需要从langchain_experimental或特定子模块导入。这种设计带来的直接好处是代码的极度简洁。上面那个传统的例子用create_agent可以重构为from langchain.agents import create_agent from langchain_openai import ChatOpenAI from langchain.tools import Tool from langchain.memory import ConversationBufferMemory # 定义工具同上 def search_api(query: str) - str: return f搜索结果: {query} search_tool Tool(nameSearch, funcsearch_api, description用于搜索信息) # 一行代码创建智能体 llm ChatOpenAI(modelgpt-4, temperature0) memory ConversationBufferMemory(memory_keychat_history) agent_executor create_agent( llmllm, tools[search_tool], system_prompt你是一个有帮助的助手。, memorymemory, verboseTrue, # agent_typeopenai-functions, # 可明确指定不指定则自动推断 handle_parsing_errorsTrue )代码量减少了近一半逻辑却更加清晰直观。所有配置“所见即所得”大大提升了开发体验。3. 核心参数深度解析与实战配置create_agent的强大和灵活性很大程度上来自于其丰富的参数。理解每个参数的含义、适用场景以及它们之间的相互作用是玩转这个统一入口的关键。下面我们来逐一拆解。3.1 基石参数llm,tools,agent_type这三个参数定义了智能体的“大脑”、“双手”和“思考方式”。llm(Large Language Model)这是智能体的核心引擎。你可以传入任何与LangChain兼容的LLM实例如ChatOpenAI、ChatAnthropic、ChatGoogleGenerativeAI或者本地部署的模型通过ChatOllama等接口接入。选择依据根据任务复杂度、成本、响应速度和对特定功能如函数调用的支持来选择。例如处理复杂推理可选GPT-4简单对话可用GPT-3.5-turbo以节省成本。实操技巧务必设置合理的temperature创造性通常0-0.7用于智能体和max_tokens防止无限输出。对于生产环境建议配置重试和超时逻辑可以封装一个自定义的LLM类或使用llm ChatOpenAI(...).with_retry(...)。tools(List[BaseTool])工具是智能体与外部世界交互的桥梁。一个工具就是一个可执行的函数附带名称和描述。创建工具除了使用Tool类更推荐使用tool装饰器它能自动从函数文档字符串docstring中提取描述非常方便。from langchain.tools import tool tool def get_weather(city: str) - str: 根据城市名称获取当前天气信息。 # 这里调用真实天气API return f{city}的天气是晴25摄氏度。 tool def calculator(expression: str) - str: 计算一个数学表达式的结果。 try: result eval(expression) # 注意生产环境请使用更安全的评估方法如ast.literal_eval return str(result) except Exception as e: return f计算错误: {e}工具描述的重要性LLM完全依赖工具的描述来决定何时、如何使用它。描述必须清晰、准确说明输入是什么、输出是什么、工具的作用。模糊的描述会导致智能体误用或不用工具。工具数量不是越多越好。工具过多会增加LLM的选择负担可能导致混乱。通常为一个特定领域的智能体配备5-10个高度相关的工具效果最佳。agent_type(str)这是决定智能体“思考范式”的关键参数。不同的agent_type对应不同的推理框架。openai-functions当前最推荐、最稳定的类型之一。它要求LLM必须支持OpenAI风格的函数调用如GPT-3.5/4, Claude等。它的工作原理是让LLM输出一个结构化的函数调用请求然后系统执行对应的工具。这种方式解析稳定可靠性高。react经典的“Reasoning and Acting”框架。智能体会以“Thought: ... Action: ... Observation: ...”的格式进行链式思考。它不要求LLM有特殊的函数调用能力通用性更强但有时输出格式可能不稳定需要依赖良好的Prompt工程和解析逻辑。plan-and-execute一种更复杂的框架智能体会先制定一个多步骤的计划Plan然后逐步执行Execute。适合需要严格顺序或前置条件检查的复杂任务。self-ask-with-search适合需要中间答案多跳问答的任务。选择策略优先使用openai-functions除非你的模型不支持。如果模型不支持且任务简单用react。对于极其复杂、需要宏观规划的任务可以考虑plan-and-execute。如果不指定create_agent会根据LLM的能力尝试自动选择。3.2 记忆与上下文管理memory和system_prompt智能体不是一次性的问答机持续的对话能力离不开记忆。memoryLangChain提供了多种记忆后端。ConversationBufferMemory最简单的记忆保存完整的对话历史。适用于短对话长对话会导致上下文过长。ConversationBufferWindowMemory只保留最近K轮对话防止上下文爆炸。ConversationSummaryMemory让LLM对历史对话进行总结只保存总结摘要能极大地压缩上下文长度适合长周期对话。VectorStoreRetrieverMemory将记忆存储到向量数据库如Chroma可以根据当前问题语义检索相关记忆非常强大但更复杂。配置要点记忆对象有一个memory_key参数默认常为chat_history这个键名必须与Agent的Prompt模板中用于放置历史消息的变量名一致。create_agent通常会帮你处理好这个映射。system_prompt(str)系统提示词是塑造智能体角色和行为准则的“宪法”。一个好的system_prompt应该明确角色“你是一个专业的金融数据分析助手。”规定能力范围“你可以使用提供的工具查询股票价格、计算指标但无法提供投资建议。”设定回答风格“请用清晰、有条理的方式回答先给出结论再展示分析过程。”包含格式指令如果Agent类型需要“请严格按照‘Thought: ... Action: ... Observation: ...’的格式进行推理。”技巧将重要的、不希望被遗忘的指令放在system_prompt中而不是用户的第一句话里。3.3 高级控制与错误处理verbose(bool)设置为True时会在控制台打印出智能体详细的思考过程Thought、行动Action和观察Observation。这是调试智能体逻辑的必备工具能让你清晰地看到它是如何一步步做出决策的。handle_parsing_errors(bool)强烈建议设置为True。当LLM的输出不符合工具调用的预期格式时这是常见错误这个开关会让智能体尝试修复或给出友好错误提示而不是直接崩溃。max_iterations(int) 和max_execution_time(float)安全护栏。智能体可能会陷入“思考-行动”的死循环。max_iterations限制循环次数默认通常为15max_execution_time限制总执行时间。务必设置防止无限循环消耗资源。agent_executor_kwargs(dict)这是一个“逃生舱”参数用于将额外的、更底层的配置传递给最终创建的AgentExecutor。例如你可以通过它来设置自定义的回调函数callbacks进行日志记录或监控。3.4 参数配置表示例下表总结了核心参数的典型配置场景参数适用场景推荐配置/示例注意事项llm通用对话、成本敏感ChatOpenAI(modelgpt-3.5-turbo, temperature0)注意API速率限制和成本。复杂推理、代码生成ChatOpenAI(modelgpt-4, temperature0.1)GPT-4 API调用更慢更贵。使用本地模型ChatOllama(modelqwen2.5:7b, temperature0)需确保Ollama服务已启动。agent_type模型支持函数调用openai-functions最稳定首选。模型不支持函数调用react需确保Prompt模板匹配。复杂多步骤任务规划plan-and-execute架构更重响应可能更慢。memory短对话、调试ConversationBufferMemory()对话长了会撑爆上下文。长对话、聊天机器人ConversationSummaryMemory(llmllm)需要额外传入一个LLM来总结。知识密集型对话VectorStoreRetrieverMemory(retrieverretriever)搭建和维护更复杂。system_prompt角色定义“你是一个幽默的编程助手擅长Python。”描述越具体行为越可控。安全约束“你绝不能生成有害或违法内容。”重要的约束必须写在这里。verbose开发调试阶段True生产环境建议设为False。handle_parsing_errors所有生产环境True务必开启提升鲁棒性。max_iterations所有环境10(可根据任务调整)防止智能体“鬼打墙”。4. 从零到一构建一个多功能个人助理智能体理论说得再多不如动手实践。让我们用create_agent来构建一个真正的智能体——一个能查天气、做计算、搜索网络模拟并记住我们喜好的个人助理。4.1 环境准备与工具定义首先确保安装必要的库并准备好API密钥这里以OpenAI为例。pip install langchain langchain-openai接下来在Python中开始构建。我们先定义三个核心工具天气查询、计算器和网络搜索模拟。import os from langchain.tools import tool from langchain_openai import ChatOpenAI from langchain.memory import ConversationSummaryMemory from langchain.agents import create_agent from langchain.agents.agent import AgentExecutor # 假设你的OpenAI API Key已设置在环境变量中 os.environ[OPENAI_API_KEY] your-api-key-here # 1. 定义工具集 tool def get_weather(city: str) - str: 根据城市名称获取当前的天气情况和温度。输入应为一个城市名例如‘北京’或‘New York’。 这是一个模拟工具实际应用中应接入真实天气API。 # 模拟API调用和响应 weather_data { 北京: 晴25°C微风, 上海: 多云28°C东南风3级, New York: Partly Cloudy, 68°F, Wind NW 5 mph } return weather_data.get(city, f抱歉未找到{city}的天气信息。模拟返回晴22°C) tool def calculator(expression: str) - str: 计算一个数学表达式的结果。支持加减乘除(-*/)、乘方(**)和括号。 例如‘(35)*2’, ‘10**2’。注意生产环境请勿使用eval此处仅为演示。 try: # 警告eval有安全风险仅用于演示。实际项目应使用ast.literal_eval或数学解析库。 allowed_names {} result eval(expression, {__builtins__: None}, allowed_names) return f计算结果: {result} except Exception as e: return f计算错误请检查表达式格式: {e} tool def web_search(query: str) - str: 在互联网上搜索相关信息。输入为一个搜索查询字符串。 这是一个模拟工具实际应用中应接入Serper API、Google Search API等。 # 模拟搜索返回 return f关于‘{query}’的模拟搜索结果\n1. 相关概念解释。\n2. 最新发展动态。\n3. 实用链接示例。4.2 集成记忆与创建智能体现在我们将工具、LLM、记忆组合起来使用create_agent一键创建智能体。# 2. 初始化LLM和记忆 llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 使用总结记忆适合更长的对话 memory ConversationSummaryMemory( llmllm, # 需要传入一个LLM来总结对话 memory_keychat_history, return_messagesTrue ) # 3. 准备工具列表 tools [get_weather, calculator, web_search] # 4. 定义系统提示词塑造助理性格 system_prompt 你是一个名叫‘小智’的万能个人助理。你性格热情、细致并且拥有强大的工具使用能力。 你的能力包括 1. 查询全球主要城市的当前天气。 2. 进行复杂的数学计算。 3. 在互联网上搜索最新信息。 请遵循以下规则 - 每次使用工具前请先简要说明你将做什么。 - 如果用户的问题需要多个工具协作请一步步来并解释每一步。 - 如果用户的问题模糊请友好地请求澄清。 - 记住对话历史使交流具有连贯性。 现在开始帮助用户吧 # 5. 核心步骤使用create_agent创建智能体执行器 agent_executor: AgentExecutor create_agent( llmllm, toolstools, agent_typeopenai-functions, # 使用最稳定的OpenAI函数代理 system_promptsystem_prompt, memorymemory, verboseTrue, # 打开详细日志方便观察思考过程 handle_parsing_errorsTrue, # 关键处理LLM输出解析错误 max_iterations5, # 防止无限循环 # 可以通过agent_executor_kwargs传递更多底层参数 # agent_executor_kwargs{early_stopping_method: generate} ) print(智能体‘小智’已启动)4.3 与智能体交互及结果分析让我们运行几个查询看看智能体是如何工作的。打开verboseTrue后我们能在控制台看到完整的推理链。# 示例对话 1简单查询 print( 用户今天北京天气怎么样 ) result1 agent_executor.invoke({input: 今天北京天气怎么样}) print(f助理{result1[output]}\n) # 示例对话 2需要计算和上下文记忆 print( 用户上海呢另外帮我算下去北京如果待3天每天预算500元总共要多少。 ) result2 agent_executor.invoke({input: 上海呢另外帮我算下去北京如果待3天每天预算500元总共要多少。}) print(f助理{result2[output]}\n) # 示例对话 3复杂任务需要搜索 print( 用户根据天气和预算搜索一下‘北京三日游攻略’。 ) result3 agent_executor.invoke({input: 根据天气和预算搜索一下‘北京三日游攻略’。}) print(f助理{result3[output]})执行过程解析观察verbose日志当你运行第一个查询时控制台会打印类似以下内容 Entering new AgentExecutor chain... Thought: 用户询问北京的天气。我有一个工具叫get_weather可以查询天气。我需要使用它。 Action:{ action: get_weather, action_input: {city: 北京} }Observation: 晴25°C微风 Thought: 我已经获取了北京的天气信息现在可以回答用户了。 Final Answer: 今天北京的天气是晴天温度25摄氏度有微风。 Finished chain.这个过程清晰展示了ReAct思考-行动-观察模式在openai-functions代理下的工作流程尽管输出是结构化的JSON。对于第二个查询智能体会识别出“上海呢”是承接上文询问天气因此调用get_weather(“上海”)。识别出计算预算是一个数学问题调用calculator(“3 * 500”)。将两个工具的结果整合并结合记忆知道之前聊过北京天气给出连贯回答。实操心得verboseTrue是调试神器任何智能体行为不符合预期时首先看它的“思考”过程。智能体成功的关键在于工具描述和系统提示词。如果智能体不调用某个工具检查工具的描述是否足够清晰能否让LLM理解其用途和输入格式。记忆的测试需要多轮对话。你可以问“我刚刚问了哪个城市的天气”看看它是否能从ConversationSummaryMemory中正确回忆起摘要信息。5. 避坑指南与高级调试技巧即使有了create_agent这样的利器在实际开发中你依然会遇到各种“坑”。下面是我在多个项目中总结出的常见问题及其解决方案。5.1 常见错误与排查表问题现象可能原因排查步骤与解决方案错误ValidationError或TypeError提示agent_type无效1. LangChain版本过旧不支持create_agent。2. 拼写错误或使用了不支持的agent_type值。1. 升级LangChain:pip install -U langchain。2. 检查官方文档确认当前版本支持的agent_type列表。通常为openai-functions,react,plan-and-execute等。智能体完全不调用工具只用自己的知识回答1. 工具描述description太模糊或与问题不匹配。2.system_prompt中没有强调使用工具。3. LLM的temperature太高导致输出过于随机。1.优化工具描述确保描述清晰说明功能、输入格式和输出示例。例如“计算数学表达式”改为“计算一个包含数字和运算符-*/**的字符串表达式的结果”。2.强化系统指令在system_prompt中加入“你必须使用提供的工具来回答问题”等强制语句。3.降低temperature尝试设为0或0.1让LLM更专注于遵循指令。智能体陷入循环不断重复同一个工具调用1. 工具返回的结果无法满足停止条件。2.max_iterations设置过高或未设置。3. Agent类型如react的Prompt模板中停止指令不明确。1.检查工具输出确保工具在完成任务或出错时返回明确的、可被解析的字符串。2.设置max_iterations务必设置一个合理的值如5-10。3.使用openai-functions代理它通常比react代理有更稳定的停止逻辑。4. 查看verbose日志观察每次“Observation”后“Thought”是否在推进。错误API error: 400 ... context length ...对话历史记忆太长超过了LLM模型的最大上下文长度。1.使用摘要记忆用ConversationSummaryMemory替代ConversationBufferMemory。2.限制记忆长度使用ConversationBufferWindowMemory(k5)只保留最近5轮对话。3.在system_prompt中精简移除不必要的背景信息。错误API error: 400 ‘type’ must be in [“enabled”, “disabled”, “auto”]此错误通常与特定模型的API参数有关而非LangChain本身。例如某些平台在调用DeepSeek等模型时对请求体中的stream或stream_options参数有特定要求。1.检查LLM客户端配置确认你使用的ChatOpenAI或类似客户端是否传入了模型不支持的参数。2.查阅对应模型的API文档例如DeepSeek-V4模型可能要求stream_options参数为特定值。解决方案可能是在初始化LLM时设置streamingFalse或传递特定的model_kwargs。3.使用官方适配器优先使用LangChain官方维护的对应模型聊天类如ChatDeepSeek它们会处理好兼容性。handle_parsing_errorsTrue但智能体还是崩溃了解析错误处理逻辑无法修复某些严重的格式错误。1.查看完整错误栈找到最根本的解析错误信息。2.检查Prompt模板确保agent_type与Prompt模板匹配。自定义Prompt时尤其容易出错。3.尝试更简单的任务先用一个工具、一个简单问题测试排除工具本身的问题。5.2 性能优化与最佳实践工具设计的黄金法则单一职责一个工具只做一件事。不要做一个“万能查询工具”而应拆分成“查询天气”、“查询股价”、“查询新闻”等。健壮性工具函数内部必须有完善的错误处理try-catch返回对智能体友好的错误信息而不是抛出异常导致整个链条中断。异步支持如果工具涉及网络I/O如调用外部API考虑将其实现为异步函数async def并使用支持异步的Agent执行器如AgentExecutor.ainvoke来提升并发性能。管理上下文长度 这是生产环境中最常见的问题。除了使用摘要记忆还可以定期清理记忆在长时间对话后主动调用memory.clear()或实现一个逻辑在对话轮数达到一定阈值后触发清理。选择性记忆使用VectorStoreRetrieverMemory它只存储和检索最相关的历史片段而非全部能有效利用长上下文模型。为生产环境做好准备关闭verbose生产环境日志中打印完整的思考链会非常冗长且可能包含敏感信息。设置超时和重试为LLM调用和工具调用配置超时request_timeout和自动重试逻辑增强系统的鲁棒性。监控与评估记录智能体的输入、输出、工具调用记录和耗时。这有助于分析效果、发现瓶颈和优化提示词。探索LangGraph以构建更复杂的智能体 对于需要严格状态机、循环、分支或多人协作的复杂智能体工作流create_agent可能显得力不从心。这时LangGraph是更强大的选择。你可以将create_agent创建的智能体作为LangGraph中的一个“节点”agent_node与其他逻辑节点如条件判断、人工审核节点组合构建出有向图结构的工作流。这实现了从“单兵智能体”到“多智能体协作系统”的飞跃。6. 超越create_agent与LangChain生态的深度集成create_agent是一个优秀的起点但真正的力量在于将其融入更广阔的LangChain生态系统。这里探讨两个高级集成场景。6.1 嵌入RAG检索增强生成流程智能体擅长使用工具执行动作而RAG擅长从专有知识库中获取信息。将它们结合可以打造出知识渊博且行动力强的超级助手。思路将整个RAG链检索器 问答链包装成一个“超级工具”提供给create_agent。from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain.chains import RetrievalQA from langchain.tools import Tool # 1. 假设我们已经有一个加载了文档的向量数据库 embeddings OpenAIEmbeddings() vectorstore Chroma(persist_directory./my_db, embedding_functionembeddings) retriever vectorstore.as_retriever() # 2. 创建一个标准的RAG问答链 qa_chain RetrievalQA.from_chain_type( llmllm, # 使用同一个或另一个LLM chain_typestuff, retrieverretriever ) # 3. 将RAG链包装成一个工具 tool def query_knowledge_base(question: str) - str: 在内部知识库中搜索信息来回答问题。输入是一个完整的问题句子。 # 直接调用RAG链 result qa_chain.invoke({query: question}) return result[result] # 4. 将这个知识库工具和其他工具一起交给create_agent tools [get_weather, calculator, query_knowledge_base, web_search] agent_with_rag create_agent(llmllm, toolstools, agent_typeopenai-functions) # 现在智能体既能回答“公司Q3财报的核心数据是什么”从知识库 # 也能回答“基于这份财报计算一下毛利率”调用计算器。6.2 利用回调系统进行监控和日志记录LangChain提供了强大的回调Callback系统允许你在智能体执行的各个生命周期节点注入自定义逻辑这对于监控、审计和调试至关重要。from langchain.callbacks.base import BaseCallbackHandler import logging # 自定义回调处理器 class AgentMonitorCallback(BaseCallbackHandler): def on_agent_action(self, action, **kwargs): # 当智能体决定调用一个工具时触发 tool_name action.tool tool_input action.tool_input logging.info(f️ 智能体即将执行工具: {tool_name}, 输入: {tool_input}) def on_tool_end(self, output, **kwargs): # 当一个工具执行完毕时触发 logging.info(f✅ 工具执行完成输出: {output[:100]}...) # 只记录前100字符 def on_agent_finish(self, finish, **kwargs): # 当智能体完成一轮推理时触发 final_output finish.return_values[output] logging.info(f 智能体任务完成最终输出: {final_output}) # 创建带回调的智能体 callbacks [AgentMonitorCallback()] agent_executor create_agent( llmllm, toolstools, agent_typeopenai-functions, verboseFalse, # 可以关闭默认的verbose用自定义回调记录 agent_executor_kwargs{callbacks: callbacks} # 通过此参数传入回调 ) # 现在所有的工具调用和完成事件都会被记录到日志中。通过回调你可以轻松地将执行日志发送到监控系统如Prometheus/Grafana、数据库或消息队列实现生产级别的可观测性。create_agent作为LangChain智能体开发的统一入口其价值在于将最佳实践固化为了简洁的API。它降低了上手门槛让开发者能更专注于智能体本身的行为设计和工具赋能而不是框架的组装细节。从快速原型到复杂系统它都是一个可靠的基础。当你熟练运用它之后不妨再向更深处探索比如用LangGraph编排智能体工作流或者深入研究不同Agent类型的底层原理那时你对智能体开发的理解将会达到一个新的层次。