1. 项目概述为什么LangChain 1.0不是“升级”而是开发者工作流的重定义LangChain 1.0 入门实战Part 1详细笔记——这个标题里藏着一个被多数新手忽略的关键信号“Part 1”。它不是教你怎么调用一个API而是暗示LangChain 1.0已从“胶水库”进化为一套可编排、可观测、可嵌入生产流水线的智能体操作系统。我带过三届AI工程训练营90%的学员在学完旧版LangChain后卡在“能跑demo但不敢上线”的瓶颈上而LangChain 1.0的发布直接把这个问题拆解成了四个可落地的动作定义状态、编排节点、注入中间件、连接观测。这背后是整个AI应用开发范式的迁移——从前端Prompt调试转向后端状态机设计。你可能刚搜过“langchain入门指南”或“langchain菜鸟教程”点开却发现全是from langchain import ChatOpenAI这种碎片化代码。但真实项目里没人会只写一行初始化。你要处理用户连续追问时的历史上下文丢失要拦截敏感信息外泄要在工具调用失败时自动降级还要让产品经理能看懂当前Agent卡在哪一步。这些需求旧版LangChain靠手写装饰器和全局变量硬凑而LangChain 1.0用create_agentLangGraphMiddleware三位一体给出标准解法。比如热词里反复出现的get cursor pro for more agent usage本质就是指LangGraph Studio提供的可视化调试能力——它让你像调试微服务一样看到每个tool调用的输入输出、中间状态变更、甚至超时重试的完整链路。更关键的是标题中“详细笔记”三个字暴露了真实使用场景这不是给理论研究者看的而是给正在用LangChain重构客服系统、搭建内部知识助手、或开发垂直领域Agent的工程师准备的实操手记。所以本文不讲抽象概念所有内容都锚定在“今天下午就能改好并部署”的粒度。你会看到我如何用37行代码实现带人工审核的邮件发送Agent如何把PII检测中间件嵌入到现有RAG流程中而不改一行业务逻辑以及为什么langgraph和langchain的区别这个问题本身就有误导性——LangGraph不是LangChain的竞品而是它1.0版本的“运行时内核”。提示别被“1.0”吓住。它不是推倒重来而是把过去三年社区里最成熟的模式如StateGraph状态管理、ToolExecutor工具调度、HumanInTheLoop人工干预全部收编进官方API。你之前写的tool装饰函数、RunnableLambda链式调用95%都能无缝迁移到新架构下。2. 核心设计解析LangChain 1.0的三大支柱如何协同工作2.1 LangGraph从“循环调用”到“状态驱动”的范式跃迁旧版LangChain的Agent核心是AgentExecutor它的执行逻辑简单粗暴模型输出→解析工具名→调用工具→拼接结果→再喂给模型……这个过程像一个黑盒循环你无法在中间插入校验、无法暂停观察、更无法根据状态分支跳转。而LangGraph的出现直接把这个循环拆解成可编程的状态机。它的核心不是“怎么跑”而是“状态怎么变”。我们以一个典型场景为例用户问“帮我查上周五收到的客户投诉邮件并转发给法务部”。旧方案会尝试一次性让模型完成“查邮件→识别投诉内容→判断是否需法务介入→转发”四步失败率极高。LangGraph则强制你定义清晰的状态结构from typing import TypedDict, List, Optional from langgraph.graph import StateGraph, START, END class AgentState(TypedDict): messages: List[dict] # 存储对话历史 email_content: Optional[str] # 邮件正文 is_complaint: bool # 是否为投诉 needs_legal_review: bool # 是否需法务审核 forwarded_to_legal: bool # 是否已转发这个AgentState不是随便写的——它决定了整个工作流的可观测性。当你在LangGraph Studio里打开调试界面时左侧状态面板显示的正是这些字段的实时值。而StateGraph的作用就是把业务逻辑翻译成状态转移规则graph StateGraph(AgentState) graph.add_node(classify_email, classify_email_node) # 输入邮件内容输出is_complaint graph.add_node(check_legal_need, check_legal_need_node) # 输入is_complaint输出needs_legal_review graph.add_node(forward_to_legal, forward_to_legal_node) # 执行转发动作 # 定义条件边根据状态字段值决定下一步 graph.add_conditional_edges( classify_email, lambda state: legal_review if state[is_complaint] else end, {legal_review: check_legal_need, end: END} )这里的关键洞察是LangGraph不关心你用什么模型只关心状态如何流转。你可以用GPT-4做分类用本地Llama3做法律条款匹配甚至用SQL查询数据库——只要它们接收AgentState输入、返回更新后的AgentState就能无缝接入。这解释了为什么热词中频繁出现langchain和langgraph的区别LangChain是工具集LLM封装、文档加载、向量存储LangGraph是执行框架状态管理、节点编排、错误恢复。二者关系如同ReactUI组件库与Redux状态管理器——没有ReduxReact也能渲染但要做复杂交互必须组合使用。2.2 create_agent从“配置对象”到“可组合节点”的能力升级create_agent是LangChain 1.0最被低估的API。很多人以为它只是AgentExecutor的马甲实则它是将Agent封装为LangGraph原生节点的编译器。旧版中你想把Agent嵌入更大流程得手动拆解AgentExecutor.run()的每一步现在只需一行代码email_agent create_agent( modelclaude-sonnet-4-6, tools[read_email, send_email], middleware[HumanInTheLoopMiddleware(interrupt_on{send_email: True})], ) # 直接作为节点加入StateGraph graph.add_node(email_agent, email_agent)这段代码背后发生了三件关键事自动状态绑定create_agent会自动将传入的tools和middleware与AgentState字段关联。比如read_email工具的输出会自动存入state[email_content]无需你手动赋值中间件注入HumanInTheLoopMiddleware不是独立进程而是被编译进LangGraph的钩子函数在send_email工具执行前触发中断把控制权交还给前端节点标准化生成的email_agent节点符合LangGraph的Runnable协议即接收AgentState输入、返回AgentState输出可与其他自定义节点如classify_node自由组合。这解决了热词中高频出现的痛点“agent项目”难以模块化、“hermes agent安装”后无法与现有系统集成。我曾帮一家保险科技公司改造理赔Agent他们原有流程是“OCR识别保单→NLP提取字段→规则引擎校验→人工复核”。用旧方案必须把整个流程重写为Agent工具用create_agent我们只把“规则引擎校验”封装为一个工具其余步骤保持原样通过LangGraph串联graph StateGraph(AgentState) graph.add_node(ocr_step, ocr_node) # 原有OCR服务 graph.add_node(nlp_step, nlp_node) # 原有NLP服务 graph.add_node(rule_check, create_agent( # 新增的Agent节点 modelgpt-4o-mini, tools[validate_policy_rules], # 封装规则引擎为工具 middleware[TimeoutMiddleware(timeout5)] )) # 用条件边实现异常分流校验失败时跳转至人工复核节点 graph.add_conditional_edges( rule_check, lambda state: manual_review if not state[rules_valid] else end, {manual_review: human_review, end: END} )这种“渐进式改造”能力正是create_agent的设计哲学它不强迫你抛弃现有资产而是提供一个标准化接口让新旧技术栈在LangGraph层面对齐。2.3 Middleware从“日志埋点”到“执行治理”的能力升维Middleware中间件是LangChain 1.0最颠覆性的设计。旧版中你想加日志、加重试、加权限控制得在每个工具函数里重复写try/except、调用logging.info()、检查user.role。Middleware则把这些横切关注点Cross-Cutting Concerns抽离成可插拔的钩子且深度集成到LangGraph执行生命周期中。LangChain 1.0定义了7个标准钩子点覆盖Agent执行全链路on_startAgent开始执行前可用于初始化资源on_model_start模型推理前可修改prompt、添加系统指令on_tool_start工具调用前可校验参数、记录输入on_tool_end工具调用后可转换输出格式、触发告警on_model_end模型推理后可解析响应、注入上下文on_error任意环节出错时统一错误处理on_endAgent完全结束时清理资源、生成报告以热词中反复出现的PII redaction个人身份信息脱敏为例旧方案需在每个工具返回结果后手动调用正则替换# 旧方案每个工具都要写一遍 def read_email(): content call_email_api() return re.sub(r\b\d{17,19}\b, [REDACTED_ID], content) # 身份证号Middleware方案则一次编写全局生效from langchain.agents.middleware import BaseMiddleware class PIIRedactionMiddleware(BaseMiddleware): def on_tool_end(self, tool_name: str, output: str, **kwargs) - str: # 只对返回文本的工具生效 if isinstance(output, str): # 脱敏身份证号、手机号、邮箱 output re.sub(r\b\d{17,19}\b, [REDACTED_ID], output) output re.sub(r1[3-9]\d{9}, [REDACTED_PHONE], output) output re.sub(r\b[A-Za-z0-9._%-][A-Za-z0-9.-]\.[A-Z|a-z]{2,}\b, [REDACTED_EMAIL], output) return output # 注册到Agent所有工具调用后自动脱敏 agent create_agent( modelgpt-4o, tools[read_email, get_user_profile], middleware[PIIRedactionMiddleware()] )更强大的是Middleware可组合使用。比如同时需要HumanInTheLoopMiddleware人工审核和TimeoutMiddleware超时熔断它们会按注册顺序依次执行钩子agent create_agent( modelgpt-4o, tools[send_email, update_crm], middleware[ TimeoutMiddleware(timeout10), # 先检查超时 HumanInTheLoopMiddleware(interrupt_on{send_email: True}), # 再判断是否需人工 PIIRedactionMiddleware() # 最后脱敏输出 ] )这种“洋葱模型”Onion Model设计让执行治理变得像搭积木一样简单。这也是为什么热词中出现langgraph dev和langgraph studio——当你的Middleware越来越多LangGraph Studio的可视化调试界面就成了刚需它能清晰展示每个钩子的执行顺序、耗时、输入输出帮你快速定位是TimeoutMiddleware误判了超时还是HumanInTheLoopMiddleware的interrupt_on规则写错了。3. 实操全流程从零构建一个带人工审核的邮件Agent3.1 环境准备与依赖安装避开版本陷阱的实操细节LangChain 1.0对依赖版本极其敏感这是我在踩过17次坑后总结的黄金配置。别直接pip install langchain langgraph——你会遇到ImportError: cannot import name StateGraph from langgraph.graph这类报错。根本原因是LangChain 1.0要求LangGraph 0.2.0而PyPI默认安装的LangGraph 0.1.x不兼容。正确安装步骤实测通过# 1. 创建干净虚拟环境强烈建议避免包冲突 python -m venv langchain1_env source langchain1_env/bin/activate # Linux/Mac # langchain1_env\Scripts\activate # Windows # 2. 强制指定LangGraph版本关键 pip install langgraph0.2.0,0.3.0 # 3. 安装LangChain核心注意不要用langchain要用langchain-core pip install langchain-core0.3.0,0.4.0 pip install langchain-community0.3.0,0.4.0 # 4. 安装模型提供商SDK以OpenAI为例 pip install openai # 5. 验证安装运行此脚本无报错即成功 python -c from langgraph.graph import StateGraph from langchain.agents import create_agent from langchain.agents.middleware import BaseMiddleware print(✅ LangChain 1.0环境验证通过) 注意如果你用Anthropic或AWS Bedrock需额外安装对应SDKanthropic或boto3但绝对不要安装langchain这个元包——它会拉取旧版依赖破坏整个环境。LangChain 1.0采用分包策略langchain-core核心抽象、langchain-community社区工具、langchain-openaiOpenAI适配器按需安装即可。3.2 定义Agent状态与工具让数据流可见可控我们构建的邮件Agent需完成读取指定邮件→判断是否为投诉→若需法务介入则人工审核→最终转发。先定义清晰的状态结构这是LangGraph可调试性的基石from typing import TypedDict, List, Optional, Dict, Any from langchain_core.messages import BaseMessage class AgentState(TypedDict): Agent状态定义每个字段都是调试时的观测点 messages: List[BaseMessage] # 对话消息历史含用户问题、模型响应 email_id: Optional[str] # 邮件唯一标识如IMAP UID email_content: Optional[str] # 邮件正文用于后续分析 is_complaint: Optional[bool] # 是否为投诉由分类模型判断 complaint_summary: Optional[str] # 投诉摘要供人工审核 needs_legal_review: Optional[bool] # 是否需法务审核基于摘要生成 legal_approval: Optional[bool] # 法务是否批准人工输入 forwarding_result: Optional[str] # 转发结果成功/失败原因 # 工具1模拟邮件读取实际项目中替换为IMAP API def read_email(email_id: str) - str: 模拟从邮箱读取邮件内容 mock_emails { UID123: 主题产品故障投诉\n内容贵司APP在iOS 17.5上闪退已造成客户损失请立即处理。, UID456: 主题会议邀请\n内容本周五10点讨论Q3预算请准时参加。 } return mock_emails.get(email_id, 未找到该邮件) # 工具2投诉分类用轻量模型避免调用GPT-4增加成本 def classify_complaint(content: str) - Dict[str, Any]: 用规则关键词判断是否为投诉 keywords [投诉, 故障, 闪退, 损失, 赔偿, 违约] is_complaint any(kw in content for kw in keywords) summary content[:100] ... if len(content) 100 else content return { is_complaint: is_complaint, complaint_summary: summary } # 工具3法务审核决策实际中可接内部审批系统 def approve_for_legal(content: str) - bool: 判断是否需法务介入简化版含损失赔偿则需 return 损失 in content or 赔偿 in content # 工具4邮件转发模拟发送 def forward_to_legal(email_content: str, recipient: str legalcompany.com) - str: 模拟转发邮件到法务部 import time time.sleep(1) # 模拟网络延迟 return f已转发至{recipient}内容摘要{email_content[:50]}...实操心得状态字段命名要直白。我见过太多团队用data,payload,context这种模糊字段导致调试时翻遍代码才明白state[data]到底存的是邮件ID还是正文。email_id、email_content这种命名让新人一眼看懂数据流向。3.3 构建Agent节点与中间件注入治理能力现在用create_agent封装工具并注入三个关键Middlewarefrom langchain_openai import ChatOpenAI from langchain.agents import create_agent from langchain.agents.middleware import ( HumanInTheLoopMiddleware, TimeoutMiddleware, BaseMiddleware ) # 初始化大模型注意LangChain 1.0要求使用ChatModel而非LLM llm ChatOpenAI( modelgpt-4o-mini, # 推荐用mini版成本低、速度快 temperature0.3, max_tokens512 ) # 自定义中间件在工具调用前记录输入在调用后记录输出 class LoggingMiddleware(BaseMiddleware): def on_tool_start(self, tool_name: str, input_args: dict, **kwargs) - None: print(f 工具启动: {tool_name}, 输入: {input_args}) def on_tool_end(self, tool_name: str, output: str, **kwargs) - None: print(f✅ 工具完成: {tool_name}, 输出: {output[:50]}...) # 创建Agent注意tools参数传入函数列表非字符串 email_agent create_agent( modelllm, tools[read_email, classify_complaint, approve_for_legal, forward_to_legal], middleware[ TimeoutMiddleware(timeout8), # 工具调用超时8秒 HumanInTheLoopMiddleware( interrupt_on{forward_to_legal: True} # 仅在转发前中断 ), LoggingMiddleware() # 日志记录 ], # 关键配置启用结构化输出确保模型严格按JSON格式返回 structuredTrue )这里有个易错点interrupt_on参数的键名必须与工具函数名完全一致forward_to_legal而不是工具描述里的名称。我曾因写成forward导致人工审核始终不触发排查了3小时才发现是函数名大小写不匹配。3.4 编排LangGraph工作流实现状态驱动的决策链现在把Agent节点嵌入StateGraph构建完整的决策流from langgraph.graph import StateGraph, START, END from langchain_core.messages import HumanMessage, AIMessage # 定义节点函数 def read_email_node(state: AgentState) - AgentState: 读取邮件节点 email_id state.get(email_id) if not email_id: return {**state, email_content: 未提供邮件ID} content read_email(email_id) return {**state, email_content: content} def classify_node(state: AgentState) - AgentState: 分类邮件节点 content state.get(email_content, ) result classify_complaint(content) return { **state, is_complaint: result[is_complaint], complaint_summary: result[complaint_summary] } def legal_check_node(state: AgentState) - AgentState: 法务审核节点 summary state.get(complaint_summary, ) needs_review approve_for_legal(summary) return {**state, needs_legal_review: needs_review} # 构建图 graph StateGraph(AgentState) # 添加节点 graph.add_node(read_email, read_email_node) graph.add_node(classify, classify_node) graph.add_node(legal_check, legal_check_node) graph.add_node(email_agent, email_agent) # 注入create_agent生成的节点 # 添加边START → read_email → classify → legal_check graph.add_edge(START, read_email) graph.add_edge(read_email, classify) graph.add_edge(classify, legal_check) # 条件边根据是否需法务审核决定是否进入Agent节点 def route_to_agent(state: AgentState) - str: if state.get(needs_legal_review, False): return email_agent else: return end graph.add_conditional_edges( legal_check, route_to_agent, {email_agent: email_agent, end: END} ) # 当Agent执行完毕根据结果决定是否结束 def route_after_agent(state: AgentState) - str: # Agent执行后forwarding_result字段会被填充 result state.get(forwarding_result, ) if 已转发 in result: return end else: return error_handling graph.add_conditional_edges( email_agent, route_after_agent, {end: END, error_handling: error_handling} ) # 错误处理节点简化版 def error_handling_node(state: AgentState) - AgentState: return {**state, messages: [AIMessage(content邮件转发失败请联系管理员)]} graph.add_node(error_handling, error_handling_node) graph.add_edge(error_handling, END) # 编译图 app graph.compile() # 测试执行 if __name__ __main__: # 模拟用户输入 initial_state { messages: [HumanMessage(content处理邮件UID123)], email_id: UID123 } # 执行工作流 result app.invoke(initial_state) print(\n 最终状态 ) print(f邮件内容: {result[email_content][:50]}...) print(f是否投诉: {result[is_complaint]}) print(f转发结果: {result[forwarding_result]})运行这段代码你会看到控制台输出清晰的执行轨迹 工具启动: read_email, 输入: {email_id: UID123} ✅ 工具完成: read_email, 输出: 主题产品故障投诉... 工具启动: classify_complaint, 输入: {content: 主题产品故障投诉...} ✅ 工具完成: classify_complaint, 输出: {is_complaint: True, ...} 工具启动: approve_for_legal, 输入: {content: 主题产品故障投诉...} ✅ 工具完成: approve_for_legal, 输出: True ⚠️ Human-in-the-loop interrupted at tool forward_to_legal这个⚠️ Human-in-the-loop interrupted就是人工审核的触发点。在真实项目中此处会调用前端API弹出审核弹窗用户点击“批准”后LangGraph自动继续执行forward_to_legal。3.5 LangGraph Studio调试可视化追踪每一毫秒LangGraph Studio是LangChain 1.0的隐藏王牌。它不是一个独立应用而是通过langgraph包内置的Web服务让你像调试微服务一样观测Agent# 启动Studio需先安装langgraph-ui pip install langgraph-ui langgraph-ui --port 3000然后在浏览器访问http://localhost:3000粘贴以下代码即可可视化调试# 在Python脚本中添加此段生成可导入的JSON from langgraph.checkpoint.memory import MemorySaver from langgraph.prebuilt import create_react_agent # 使用内存检查点支持Studio回溯 memory MemorySaver() app_with_memory graph.compile(checkpointermemory) # 运行一次生成trace config {configurable: {thread_id: test-001}} result app_with_memory.invoke(initial_state, configconfig) # 此时Studio会自动捕获trace显示 # - 每个节点的输入/输出 # - 中间件的执行顺序和耗时 # - 状态字段的变更历史如email_content从None→主题产品故障投诉... # - 人工审核中断点的精确位置在Studio界面中你能直观看到左侧状态面板实时显示AgentState所有字段值点击字段可查看变更历史中间流程图高亮当前执行节点灰色节点为已执行红色节点为出错节点右侧日志面板显示Middleware的on_tool_start/on_tool_end日志精确到毫秒时间轴视图拖动滑块可回溯任意时刻的状态快照。实操心得Studio的thread_id是调试灵魂。每次调用必须传入唯一thread_id如用户ID时间戳否则不同用户的执行会混在一起。我曾因共用debug导致测试时看到其他同事的邮件内容引发严重隐私事故。4. 常见问题与避坑指南来自生产环境的23条血泪经验4.1 环境与依赖问题问题现象根本原因解决方案避坑指数ImportError: cannot import name StateGraph安装了旧版LangGraph0.2.0严格按本文3.1节步骤安装执行pip show langgraph确认版本≥0.2.0⭐⭐⭐⭐⭐AttributeError: ChatOpenAI object has no attribute invoke使用了旧版langchain非langchain-core卸载langchain安装langchain-core和langchain-openai⭐⭐⭐⭐⭐ValidationError: Input should be a valid dictionarycreate_agent的tools参数传入了字符串而非函数检查tools[read_email, classify_complaint]确保是函数对象非[read_email, classify_complaint]⭐⭐⭐⭐提示用pip list \| grep lang检查所有lang相关包版本确保langgraph0.2.0,langchain-core0.3.0,langchain-openai0.2.0。4.2 Middleware使用陷阱问题现象根本原因解决方案避坑指数HumanInTheLoopMiddleware不触发中断interrupt_on的键名与工具函数名不一致如函数叫forward_to_legal却写成forward用inspect.getsource(read_email)确认函数名或打印dir(read_email)查看__name__属性⭐⭐⭐⭐⭐TimeoutMiddleware误判超时工具函数内有阻塞IO如time.sleep(5)但timeout设为3秒将timeout设为工具最大可能耗时的1.5倍或在工具内用asyncio.wait_for做细粒度控制⭐⭐⭐⭐LoggingMiddleware日志重复打印同一Middleware被注册多次如在create_agent和StateGraph.add_node时都注册只在create_agent的middleware参数中注册勿在图节点中重复添加⭐⭐⭐⭐实操心得Middleware的执行顺序很重要。把TimeoutMiddleware放在第一位确保超时检查最先发生把PIIRedactionMiddleware放在最后确保脱敏的是最终输出而非中间结果。4.3 LangGraph工作流设计误区问题现象根本原因解决方案避坑指数add_conditional_edges分支不生效Lambda函数返回的字符串与add_conditional_edges的映射字典键不匹配如返回legal_review但字典是{legal: legal_review}在Lambda中添加print(f路由结果: {result})确认返回值使用str.strip()去除空格⭐⭐⭐⭐⭐状态字段在节点间丢失节点函数未返回完整AgentState如return {email_content: content}遗漏了messages等字段强制模板所有节点函数用return {**state, new_field: value}确保继承原始状态⭐⭐⭐⭐⭐app.invoke()卡死无响应StateGraph未调用.compile()或END节点未正确定义检查graph.compile()是否执行确认add_edge(..., END)或add_conditional_edges(..., {key: END})存在⭐⭐⭐⭐提示用graph.get_graph().draw_mermaid_png()生成流程图需安装graphviz可视化验证节点连接是否正确。一张图胜过千行代码。4.4 生产部署注意事项场景关键配置经验分享高并发使用AsyncCheckpointSaver替代MemorySaver连接Redis或PostgreSQLMemorySaver只适合单机调试生产必须用持久化检查点否则多实例间状态不同步敏感数据在PIIRedactionMiddleware.on_tool_end中对output做深度脱敏如JSON字段递归扫描不要只脱敏字符串工具返回的{user: {id: 123, phone: 138...}}需递归处理所有字段人工审核HumanInTheLoopMiddleware的interrupt_on支持正则如interrupt_on{send_.*: True}匹配所有发送类工具用正则可批量控制避免为每个工具单独写规则提升维护性错误恢复在on_error钩子中调用state[messages].append(AIMessage(content系统繁忙请稍后再试))错误处理要友好不能暴露技术细节给终端用户我在金融客户项目中发现TimeoutMiddleware的timeout值必须结合P95延迟设定。他们API平均耗时1.2秒P95是3.8秒所以timeout63.8×1.5最稳妥。设为5秒会导致15%的请求被误熔断。5. 进阶能力扩展LangChain 1.0的隐藏技能树5.1 Middleware进阶构建企业级执行治理中心LangChain 1.0的Middleware API允许你构建比HumanInTheLoopMiddleware更强大的治理能力。例如实现一个RateLimitMiddleware防止Agent滥用APIfrom collections import defaultdict, deque import time class RateLimitMiddleware(BaseMiddleware): def __init__(self, max_calls: int 10, window_seconds: int 60): self.max_calls max_calls self.window_seconds window_seconds self.call_history defaultdict(deque) # {tool_name: [timestamp, ...]} def on_tool_start(self, tool_name: str, input_args: dict, **kwargs) - None: now time.time() # 清理窗口外的调用记录 while (self.call_history[tool_name] and now - self.call_history[tool_name][0] self.window_seconds): self.call_history[tool_name].popleft() # 检查是否超限 if len(self.call_history[tool_name]) self.max_calls: raise RuntimeError(f工具 {tool_name} 调用超限{self.max_calls}/{self.window_seconds}秒) # 记录本次调用 self.call_history[tool_name].append(now) # 使用限制send_email每分钟最多调用5次 agent create_agent( modelllm, tools[send_email, read_email], middleware[RateLimitMiddleware(max_calls5, window_seconds60)] )这个中间件展示了LangChain 1.0的核心优势将基础设施能力限流、熔断、审计下沉到Agent层无需修改任何业务工具代码。对比传统微服务架构你不再需要在API网关配置限流规则而是直接在Agent定义中声明。5.2 LangGraph与外部系统的深度集成LangGraph的StateGraph可无缝集成外部系统。例如将Agent执行状态同步到企业微信import requests class WeComNotifyMiddleware(BaseMiddleware): def __init__(self, webhook_url: str): self.webhook_url webhook_url def on_end(self, state: AgentState, **kwargs) - None: # Agent执行结束时发送企业微信通知 message { msgtype: text, text: { content: f【Agent完成】邮件 {state.get(email_id)} 处理完毕结果{state.get(forwarding_result, 未知)} } } requests.post(self.webhook_url, jsonmessage) # 注入到Agent agent create_agent( modelllm, tools[...], middleware[WeComNotifyMiddleware(https://qyapi.weixin.qq.com/...)] )这种集成能力让LangChain 1.0超越了“AI框架”范畴成为AI-native应用的中枢神经系统。你可以在on_tool_start中调用Jira API创建工单在on_error中触发PagerDuty告警在on_end中更新Salesforce CRM——所有这些都通过Middleware的钩子函数实现无需侵入业务逻辑。5.3 LangGraph