30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度1. 从“对话”到“行动”为什么现在必须理解 AI Agent别再只把大模型当成一个更聪明的聊天机器人了。如果你还在用“用户提问模型回答”的单轮对话模式来思考 AI 应用那你可能已经落后了。真正的变化在于AI 正在从“回答问题”转向“完成任务”。这就是AI Agent的核心。简单说AI Agent 是一个能自主规划、调用工具、执行多步操作直到完成一个复杂目标的智能系统。它不再是“你说一句我回一句”而是“你给一个目标我负责搞定全过程”。比如你让它“帮我研究一下 LangChain 1.0 的新特性并写份报告”一个合格的 Agent 会自己去搜索资料、整理信息、分析对比最后生成一份结构化的文档。这个过程涉及决策、循环和工具调用远非一次 API 调用能解决。为什么现在必须关注这个因为技术栈和市场需求已经到位了。大模型的理解和推理能力尤其是长上下文和工具调用显著提升而像LangChain这样的框架则提供了将这种能力工程化、产品化的脚手架。2025年底LangChain 和 LangGraph 同步发布了 1.0 版本这标志着一个关键转折框架的关注点从如何“链式”调用模型Chaining转向了如何构建带状态、可持久化、能处理长周期任务的智能体工作流Orchestration 和 Harness。对于开发者而言这意味着两件事机会你可以开始构建真正能“干活”的自动化数字员工而不仅仅是问答机器人。应用场景从客服、内容生成扩展到了数据分析、流程自动化、智能研发助手等更深的业务层面。挑战开发模式变了。传统的指令式编程if-else正在部分让位于目标导向式编程告诉模型目标让它自己决定步骤。随之而来的是一系列新的工程问题循环控制、状态管理、工具可靠性、可观测性。所以这篇文章不是另一个“Hello World”式的 LangChain 教程。我会带你穿透概念直接进入LangChain 实现 AI Agent 的核心工作机制并通过一个可运行的实战案例让你理解从零构建到工程落地需要关注的所有关键点。如果你已经厌倦了空谈概念想亲手造一个能自主工作的智能体那么从这里开始正合适。2. LangChain Agent 的核心机制ReAct 循环与四大组件要动手造 Agent必须先理解它的大脑和骨架。LangChain 实现 Agent 的核心模式是ReActReasoning Acting推理-行动循环。这不是一个高深的理论而是一个极其务实的工作流程。2.1 ReAct 循环Agent 如何“思考”与“行动”想象一下你让一个人类助理去订机票。他不会立刻回复你一个航班号而是会经历思考我需要查航班、比价格、看时间→ 行动打开航司网站查询→ 观察看到航班列表→ 再思考这个时间合适但价格高再查一下另一个航司→ 再行动……直到最终给出一个建议。AI Agent 的 ReAct 循环完全模拟了这个过程。其工作流可以分解为以下步骤这是一个不断迭代的循环接收输入用户提交一个任务例如“北京天气怎么样”。推理LLM大语言模型分析任务决定下一步该做什么。它会生成一个结构化的“思考”过程。决策基于推理LLM 判断是调用工具还是直接给出最终答案。行动如果需要工具LLM 会指定使用哪个工具以及输入参数。观察工具执行并返回结果。循环将“观察”到的结果连同历史信息再次喂给 LLM 进行下一轮“推理”。终止当 LLM 认为信息足够可以给出最终答案时循环结束。这个循环由 LangChain 的AgentExecutor或 LangGraph 的图在底层自动管理。开发者需要提供的就是“大脑”LLM和“工具箱”Tools。2.2 四大核心组件拆解LangChain 将 Agent 抽象为四个关键部分理解它们就理解了整个架构组件角色职责对应 LangChain 模块示例LLM大脑理解任务、进行推理、做出决策、生成输出。ChatOpenAI,ChatQwen,Ollama等Agent调度员封装 ReAct 逻辑决定何时调用哪个工具何时结束循环。create_react_agent,create_openai_tools_agentTools工具箱执行具体操作如搜索网络、查询数据库、运行代码、调用 API。tool装饰器定义的函数或BaseTool子类Memory记忆体存储对话历史、中间状态为 LLM 提供上下文。ConversationBufferMemory,ConversationSummaryMemory它们如何协作你初始化一个Agent它内部绑定了一个LLM和一套Tools。用户输入到来Agent将其与Memory中的历史组合发送给LLM。LLM进行推理输出一个结构化指令如Action: 天气查询工具, Action Input: 北京。Agent解析该指令调用对应的Tool。Tool执行并返回结果Observation: 北京晴25度。这个结果被存入Memory并和原始问题一起再次送给LLM进行下一轮推理。当LLM输出Final Answer: ...时Agent终止循环返回最终结果。关键洞察在这个范式下你的编程工作从“编写每一步的业务逻辑”转变为“定义工具和设定目标”。你不再写if query_type “weather”: get_weather(city)而是告诉 LLM“这里有一个get_weather工具当你觉得需要知道天气时就用它。” 决策权移交给了模型。3. 实战入门从零构建你的第一个研究助手 Agent理论足够清晰了现在我们来动手。这个实战案例的目标是构建一个“智能研究助手”你给它一个研究主题它能自动联网搜索并整理出答案。3.1 环境准备与依赖安装首先确保你的 Python 环境建议 3.9并安装核心库。我们将使用 OpenAI 的模型和 Tavily 的搜索 API。# 安装 LangChain 及其 OpenAI 集成 pip install langchain langchain-openai # 安装 Tavily 搜索工具包 (一个为 AI 优化的搜索引擎 API) pip install tavily-python # 可选但推荐安装 langchain-core 和 langgraph 以了解更底层的机制 pip install langchain-core langgraph准备工作准备一个OpenAI API Key。如果你没有可以考虑使用兼容 OpenAI API 的本地模型如通过 Ollama 部署的 Qwen或其它云服务但需要调整初始化代码。去 Tavily 官网 注册一个免费账户获取Tavily API Key。免费额度足够学习和测试。3.2 第一步定义你的工具Tool工具是 Agent 的手和脚。我们先定义一个最基础的网络搜索工具。# research_agent.py import os from langchain.tools import tool from tavily import TavilyClient from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain import hub # 1. 设置 API Keys (建议使用环境变量管理这里为演示直接写入) os.environ[“OPENAI_API_KEY”] “your-openai-api-key” TAVILY_API_KEY “your-tavily-api-key” # 2. 初始化 Tavily 客户端 tavily_client TavilyClient(api_keyTAVILY_API_KEY) # 3. 使用 tool 装饰器定义一个工具 tool def web_search(query: str) - str: “”“ 使用 Tavily 搜索引擎进行网络搜索。 输入一个搜索查询词返回搜索结果的摘要内容。 “”“ try: # 调用 Tavily 搜索限制返回3条结果以保证上下文长度 search_result tavily_client.search(queryquery, max_results3) # 从结果中提取‘content’字段并拼接 contents [result[“content”] for result in search_result[“results”]] return “\n\n”.join(contents) except Exception as e: # 工具调用必须健壮返回错误信息供 Agent 感知 return f“搜索工具调用失败: {str(e)}” # 让我们测试一下工具是否工作正常 if __name__ “__main__”: test_result web_search.invoke(“LangChain 1.0 发布了哪些主要新特性”) print(“工具测试结果”) print(test_result[:500]) # 打印前500字符运行python research_agent.py你应该能看到打印出的搜索结果摘要。这说明你的工具定义和 API 配置是正确的。注意工具函数必须要有清晰的文档字符串“”“”“”LLM 会依靠这个描述来决定何时调用它。输入参数也应力求简单明确。3.3 第二步组装 Agent 并运行有了工具接下来我们需要一个“大脑”LLM和将大脑与工具连接起来的“调度器”Agent。# 接上段代码 # 4. 初始化 LLM (使用 GPT-4 或 GPT-3.5-turbo) llm ChatOpenAI(model“gpt-4o”, temperature0) # temperature0 使输出更稳定 # 5. 获取一个预设的 ReAct 提示词模板 # LangChain Hub 是一个提示词仓库这里拉取一个标准的 ReAct 提示词。 prompt hub.pull(“hwchase17/react”) # 6. 创建 ReAct Agent # 将 LLM、工具列表和提示词模板组合起来形成一个具备 ReAct 推理能力的 Agent 对象。 agent create_react_agent(llmllm, tools[web_search], promptprompt) # 7. 创建 Agent 执行器 # AgentExecutor 负责管理 ReAct 循环的执行、处理解析、控制最大迭代次数等。 agent_executor AgentExecutor( agentagent, tools[web_search], verboseTrue, # 开启详细日志强烈建议调试时打开 handle_parsing_errorsTrue, # 优雅处理 LLM 输出解析错误 max_iterations5, # 防止无限循环最多迭代5次 early_stopping_method“generate”, # 当 LLM 生成 Final Answer 时停止 ) # 8. 运行你的第一个 Agent print(“\n--- 开始执行 Agent 任务 ---”) question “请对比一下 LangChain 和 LangGraph 的主要区别和适用场景。” try: result agent_executor.invoke({“input”: question}) print(“\n--- 最终答案 ---”) print(result[“output”]) except Exception as e: print(f“Agent 执行出错: {e}”)关键参数解析verboseTrue这是最重要的调试开关。打开后你会在控制台看到完整的 ReAct 循环日志包括 LLM 的“思考”Thought、决策Action和工具观察Observation。这是理解 Agent 工作过程的唯一途径。max_iterations5安全阀。防止 Agent 陷入“思考-调用-再思考”的死循环。根据任务复杂度调整。handle_parsing_errorsTrue当 LLM 的输出不符合工具调用格式时尝试让 LLM 重新生成。这能显著提高鲁棒性。运行这段代码。在verbose日志中你会看到类似这样的输出 Entering new AgentExecutor chain... Thought: 用户想了解 LangChain 和 LangGraph 的区别。我需要先获取关于这两个框架的最新信息。 Action: web_search Action Input: LangChain vs LangGraph difference use cases Observation: [这里是 Tavily 返回的搜索结果摘要...] Thought: 根据搜索结果我了解到 LangChain 是一个用于构建 LLM 应用的全栈框架...而 LangGraph 是专注于构建有状态、多步骤工作流的库... 我现在可以总结它们的区别和适用场景了。 Final Answer: LangChain 是一个全面的框架适合快速构建标准的链式和代理应用... LangGraph 更侧重于复杂、有状态的工作流编排... Finished chain.恭喜你已经成功创建并运行了你的第一个 AI Agent。它自动完成了“理解问题 → 决定搜索 → 执行搜索 → 分析结果 → 生成答案”的全过程。4. 从 Demo 到工程化必须面对的四个现实问题让一个 Agent 在 Jupyter Notebook 里跑起来是一回事让它稳定、可靠地服务于真实业务是另一回事。以下是四个你很快就会遇到且必须解决的工程问题。4.1 问题一循环失控与资源消耗现象Agent 陷入无限循环不断调用同一个工具或在不同工具间来回切换就是不输出Final Answer。根因LLM 的推理可能陷入死胡同。工具返回的信息不足以让 LLM 做出最终判断。提示词Prompt没有给出清晰的终止条件指引。解决方案硬性限制务必设置max_iterations如 10-15。这是最后的安全网。提示词工程在 System Prompt 中明确指令。例如“如果你认为已经获得了足够的信息来回答用户的问题或者经过多轮尝试仍无法获得新信息请直接给出最终答案。”工具设计确保工具返回的信息是结构化、高质量的。模糊或无关的工具输出会误导 LLM。超时控制在生产环境中为整个agent_executor.invoke()调用设置全局超时。import signal from contextlib import contextmanager class TimeoutException(Exception): pass contextmanager def time_limit(seconds): def signal_handler(signum, frame): raise TimeoutException(“Agent 执行超时”) signal.signal(signal.SIGALRM, signal_handler) signal.alarm(seconds) try: yield finally: signal.alarm(0) # 使用示例 try: with time_limit(30): # 30秒超时 result agent_executor.invoke({“input”: question}) except TimeoutException: print(“任务执行超时已终止”)4.2 问题二工具调用的脆弱性现象工具调用失败网络错误、API 限流、参数错误导致整个 Agent 流程崩溃。根因工具是 Agent 与外部世界交互的接口而外部系统是不可靠的。解决方案异常捕获与降级在每个工具函数内部进行完善的异常处理并返回对 LLM 友好的错误信息。重试机制为网络请求类工具添加重试逻辑如使用tenacity库。参数验证与清洗在工具调用前对 LLM 生成的输入参数进行基本的验证和清洗防止无效调用。使用备用工具设计功能相似的工具作为备份。from tenacity import retry, stop_after_attempt, wait_exponential tool retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10)) def robust_web_search(query: str) - str: “”“一个带有重试机制的搜索工具。”“” try: # 简单的输入清洗 if not query or len(query.strip()) 2: return “搜索查询词过短或为空。” cleaned_query query.strip()[:200] # 防止查询过长 search_result tavily_client.search(querycleaned_query, max_results2) if not search_result.get(“results”): return “未找到相关搜索结果。” contents [r[“content”] for r in search_result[“results”]] return “\n\n”.join(contents) except Exception as e: # 返回结构化错误信息帮助 LLM 理解 return f“[工具错误] 搜索 ‘{query}’ 时失败: {str(e)}。请尝试重新表述您的问题。”4.3 问题三上下文管理与成本控制现象任务复杂循环次数多导致每次请求的上下文历史对话工具结果越来越长API 调用 Token 数激增成本高昂且可能触及模型上下文长度限制。根因ReAct 模式默认会将完整的交互历史传递给下一轮。解决方案选择性记忆不要使用ConversationBufferMemory这种存储全部历史的记忆。改用ConversationSummaryMemory或ConversationBufferWindowMemory。ConversationSummaryMemory定期让 LLM 对历史对话进行摘要只保留摘要。ConversationBufferWindowMemory只保留最近 K 轮对话。优化工具输出让工具返回简洁、核心的信息而不是原始的大段文本。使用更高效的模型在推理步骤使用低成本模型如 GPT-3.5-turbo仅在需要生成最终答案时使用高性能模型如 GPT-4。LangGraph 的先进状态管理对于超长任务考虑使用 LangGraph。它允许你自定义状态结构精确控制哪些信息被保留和传递而不是一股脑塞进上下文。4.4 问题四可观测性与调试黑洞现象Agent 给出了一个错误或奇怪的答案但你完全不知道它中间经历了什么决策过程。根因Agent 的决策路径是非确定性的、黑盒的。解决方案必须引入可观测性Observability。利用verboseTrue这是本地调试最基本也是最重要的手段。集成 LangSmith这是 LangChain 官方的可观测性平台。它能记录每一次 Agent 运行称为 Trace的完整细节每一步的输入输出、工具调用、耗时、Token 消耗等。这是生产环境不可或缺的工具。它能帮你快速定位是哪个工具调用失败。能帮你分析 LLM 的推理过程是否合理。能帮你对比不同提示词或模型的效果。结构化日志将 Agent 运行的关键步骤如工具调用开始/结束、LLM 调用参数记录到你的应用日志系统中。# 启用 LangSmith 追踪 (需要设置环境变量 LANGSMITH_API_KEY) os.environ[“LANGCHAIN_TRACING_V2”] “true” os.environ[“LANGCHAIN_PROJECT”] “My Research Agent Project” # 之后的所有 LangChain 调用都会被自动记录到 LangSmith5. 进阶与选型LangChain vs. LangGraph 与生产架构思考当你需要构建更复杂、更稳定的 Agent 时你会面临框架选型问题。LangChain 和 LangGraph 是什么关系该怎么选5.1 LangChain 与 LangGraph 的定位区别简单来说LangChain高级框架提供开箱即用的组件如create_react_agent、AgentExecutor。它抽象了底层循环让你能快速搭建标准化的 Agent。它适合大多数入门和中等复杂度的场景。LangGraph底层运行时/编排引擎。它让你能用“图”Graph的概念来精确定义复杂的工作流节点可以是 LLM 调用、工具、条件判断边定义了控制流。它提供了对状态State的精细管理。LangChain 的许多高级 Agent 实现其底层就是 LangGraph。类比LangChain 像 Django快速构建 Web 应用LangGraph 像 Asyncio 状态管理库让你能从头构建任何复杂的异步流程。5.2 何时该用 LangGraph如果你的需求符合以下一点或多点就应该直接使用或深入学习 LangGraph需要复杂、有环路的流程比如一个审批流程需要多人循环确认。需要持久化状态任务可能运行很长时间需要暂停、恢复状态需要保存到数据库。需要精细的条件分支根据工具 A 的结果决定是调用工具 B 还是工具 C或者直接结束。需要多 Agent 协作一个主 Agent 协调多个子 Agent 共同完成任务。# 一个极简的 LangGraph 思路示例非完整代码 from langgraph.graph import StateGraph, END from typing import TypedDict class AgentState(TypedDict): question: str search_results: list analysis: str final_answer: str def search_node(state: AgentState): # 调用搜索工具 state[“search_results”] web_search(state[“question”]) return state def analyze_node(state: AgentState): # 调用 LLM 分析结果 state[“analysis”] llm.invoke(f“分析以下内容{state[‘search_results’]}”) return state def decide_node(state: AgentState): # 根据分析结果决定是否继续 if “需要更多信息” in state[“analysis”]: return “search_node” # 循环回去继续搜索 else: return “generate_node” def generate_node(state: AgentState): # 生成最终答案 state[“final_answer”] llm.invoke(f“根据分析生成答案{state[‘analysis’]}”) return state # 构建图 workflow StateGraph(AgentState) workflow.add_node(“search”, search_node) workflow.add_node(“analyze”, analyze_node) workflow.add_node(“generate”, generate_node) workflow.set_entry_point(“search”) workflow.add_conditional_edges(“analyze”, decide_node, {“search_node”: “search”, “generate_node”: “generate”}) workflow.add_edge(“search”, “analyze”) workflow.add_edge(“generate”, END) app workflow.compile() # 运行这个图 result app.invoke({“question”: “你的问题”})5.3 面向生产的 Agent 架构建议对于严肃的项目不要只写一个脚本。考虑以下分层工具层将工具封装成独立的、可测试的、有重试和降级能力的服务或函数。Agent 核心层使用 LangChain 或 LangGraph 定义工作流。这一层应专注于流程编排和决策逻辑。服务层将 Agent 包装成 API如使用 FastAPI提供任务提交、状态查询、结果获取等接口。任务队列与持久化对于长任务使用 Celery、RQ 或 LangGraph 的持久化检查点Checkpoint机制防止进程中断导致任务丢失。可观测性层集成 LangSmith并建立业务指标监控如任务成功率、平均循环次数、工具调用耗时。评估与反馈层设计机制收集人工反馈用于持续优化提示词和工具。最后也是最关键的一点衡量一个 Agent 的好坏不能只看它某一次是否“答对”。要像观察一个新手员工一样通过大量的运行轨迹Traces来评估其稳定性、决策合理性以及成本效率。可观测性不是可选项是生命线。在你敢让一个 Agent 自主处理真实业务之前先确保你能看清它每一步在做什么。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度