其它内置中间件与执行顺序
其它内置中间件与执行顺序
限流(Model/Tool call limit)、故障转移、重试(指数退避+jitter)、上下文编辑、文件搜索等内置中间件,以及多个中间件的洋葱模型执行顺序与"同名中间件"的坑
上一篇讲了四个最常用的中间件,这一篇把剩下的”其它内置中间件”过一遍,再讲清楚多个中间件一起用时的执行顺序。
次数限制:防止费用失控
ModelCallLimitMiddleware:限制模型调用次数
解决”Agent 太能跑、停不下来”的问题——一次任务反复请求 LLM,费用失控。
from langchain.agents.middleware import ModelCallLimitMiddleware
agent = create_agent( model=model, tools=[], middleware=[ ModelCallLimitMiddleware( thread_limit=2, # 每个线程最多 2 次模型调用 # run_limit=5, # 每次运行最多 5 次模型调用 exit_behavior="end", # 达到限制后退出 ), ],)| 参数 | 含义 |
|---|---|
thread_limit | 每个线程(同一 thread_id)最多调用多少次模型 |
run_limit | 每次运行(一次 invoke)最多调用多少次 |
exit_behavior | "end"(优雅退出)或 "error"(直接抛错) |
ToolCallLimitMiddleware:限制工具调用次数
避免 Agent 无限试错、死循环调工具:
from langchain.agents.middleware import ToolCallLimitMiddleware
middleware=[ ToolCallLimitMiddleware( # thread_limit=2, # 每个线程最多 2 次工具调用 run_limit=2, # 每次运行最多 2 次 exit_behavior="end", ),]实测参数差异:ToolCallLimitMiddleware 多一个 tool_name 参数(只限制某个工具),而且它的 exit_behavior 默认是 "continue"(ModelCallLimit 的默认是 "end")。
设成 "error" 时,超限会抛 ToolCallLimitExceededError: Tool call limit reached: run limit exceeded (4/2 calls)。
故障转移:ModelFallbackMiddleware
主模型无法访问时,自动启用备用模型——做的是”高可用”:
from langchain.agents.middleware import ModelFallbackMiddlewarefrom langchain.chat_models import init_chat_model
primary_model = init_chat_model("openai:gpt-5.4-mini")
fallback = ModelFallbackMiddleware( fallback_models=[ init_chat_model("openai:gpt-4o-mini"), # 可以继续列多个备选,按顺序尝试 ],)
agent = create_agent(model=primary_model, tools=[...], middleware=[fallback])智能工具筛选:LLMToolSelectorMiddleware
工具太多时的解法:主模型挂 100 个工具,光工具定义就要烧掉一大截上下文,模型也容易挑花眼。LLMToolSelectorMiddleware 的做法是让一个子模型先看用户问题,从所有工具里挑出最相关的几个,再交给主模型——主模型看到的工具列表被”瘦身”了。
from langchain.agents.middleware import LLMToolSelectorMiddleware
tool_selector = LLMToolSelectorMiddleware( model="openai:gpt-5.4-mini", # 用于工具筛选的子模型 max_tools=5, # 最多选择 5 个工具 always_include=["get_weather"], # 指定工具不被计数(必带))
agent = create_agent( model="deepseek-v4-flash", tools=[...100个工具...], # 很多工具 middleware=[tool_selector],)课程讲到的三个参数:
| 参数 | 含义 |
|---|---|
model | 用于工具筛选的子模型;不传则复用 Agent 的主模型 |
max_tools | 限定可以调用的工具总数;模型选多了只取前 N 个;不传则不限制 |
always_include | 指定的工具不被计数(不参与 max_tools 配额,且必定保留) |
源码里还有第四个参数 system_prompt(筛选子模型的提示词,默认 "Your goal is to select the most relevant tools for answering the user's query."),一般不用改。
参数怎么起作用:max_tools=0 的三个实验
课程用同一套四个工具(get_weather / get_news / calculate / search_stock)问了同一个问题”北京今天天气如何?今日新闻概要”,只改 always_include,结果完全不同:
| 实验 | 中间件配置 | Agent 实际调用了 |
|---|---|---|
| 举例 1 | max_tools=0, always_include=["get_weather"] | 只有 get_weather(答完天气后表示拿不到新闻) |
| 举例 2 | max_tools=0, always_include=["get_news"] | 只有 get_news(答完新闻后表示拿不到天气) |
| 举例 3 | max_tools=0, always_include=["get_weather", "get_news"] | 两个都调,一次答全 |
max_tools=0 是这个中间件最反直觉、也最好用的玩法:它把”子模型挑出来的工具”配额压到 0,于是只有 always_include 里的工具能活下来——等于绕开子模型的判断,手工把工具列表锁死成白名单。课程正是用它来对照演示 always_include 的效果。
本机假服务端实测(用 http.server 回 OpenAI 格式响应,不花真 token):一次 invoke 里确实发生了两次请求——
max_tools=5, always_include=None 第1次请求 | model=gpt-4o-mini | system: Your goal is to select the most relevant tools... 第2次请求 | model=deepseek-v4-flash | tools=['get_news', 'calculate', 'search_stock']
max_tools=0, always_include=['get_weather'] 第1次请求 | model=gpt-4o-mini | system: Your goal is to select the most relevant tools... 第2次请求 | model=deepseek-v4-flash | tools=['get_weather']三点结论:
- 第一次请求发给的是筛选子模型(这里是
gpt-4o-mini),提示词就是system_prompt;第二次才是主模型 - 主模型拿到的
tools已经被裁过了(5 个工具只留子模型选中的 3 个) max_tools=0时子模型的”选择结果”被完全丢弃,只有always_include的get_weather留下
另外实测看到:max_tools 会被拼进子模型的提示词末尾——"...If you exceed the maximum number of tools, only the first 0 will be used.";工具候选名单(含工具名)是通过结构化输出的 JSON Schema 枚举传给子模型的,不是塞在提示词里。
always_include 里写了不存在的工具名会当场报错(源码里的校验,实测复现):
ValueError -> Tools in always_include not found in request: ['not_exist_tool'].Available tools: ['calculate', 'get_news', 'get_weather']反过来,如果工具列表里除了 always_include 之外没有别的工具(或者压根没有工具),它会直接 handler(request) 放行——连子模型都不调用。
重试:ToolRetryMiddleware / ModelRetryMiddleware
两者都是基于指数退避算法的重试策略。
指数退避(Exponential Backoff) 的核心思想:操作失败时(通常是网络请求、API 调用、数据库连接),不立刻重试、也不每次等固定时间,而是让每次重试的延迟按指数级增长。
为什么不直接重试?想象某个热门网站因为瞬时流量(抢票、秒杀)崩了。如果所有失败客户端都每隔 1 秒重试一次,无异于对已经瘫痪的服务器发起持续的 DDoS,它可能永远缓不过来。
from langchain.agents.middleware import ToolRetryMiddleware
middleware=[ ToolRetryMiddleware( max_retries=6, # 最大重试次数(不含第一次,共最多 1+6=7 次调用) backoff_factor=2.0, # 指数退避因子(每次等待时间 ×2) initial_delay=1.0, # 第一次重试前的初始等待时间(秒) max_delay=10.0, # 最大等待上限(防止无限增长) jitter=True, # 开启抖动 retry_on=(TimeoutError,), # 只对指定异常重试 on_failure="continue", # 重试仍失败时怎么办 ),]| 参数 | 含义 |
|---|---|
max_retries | 最大重试次数(不包含首次调用) |
backoff_factor | 指数退避因子;设为 0 就退化成固定间隔(始终 initial_delay) |
initial_delay / max_delay | 首次等待时间 / 等待时间上限 |
jitter | 抖动:在等待时间上加随机性 |
retry_on | 只对指定异常类型重试(默认捕获所有异常) |
on_failure | 达到最大重试仍失败时的行为 |
为什么要 jitter? 避免大量请求的重试集中在同一时间点(惊群效应)。假设按策略两次请求间隔应为 10 秒,加入抖动后可能是 8.9 秒,也可能是 10.2 秒。
on_failure 的两个常见取值:
| 取值 | 行为 |
|---|---|
"continue" | 把错误信息包装后塞回对话历史,让大模型知道失败了并继续决策 |
"error" | 直接抛出异常,终止流程 |
ModelRetryMiddleware 的用法和参数完全一样,只是重试的对象换成模型调用:
from langchain.agents.middleware import ModelRetryMiddleware
middleware=[ModelRetryMiddleware(max_retries=3, backoff_factor=2.0, on_failure="continue")]工具模拟:LLMToolEmulator
场景:某些情况下工具还没开发完(后端接口没上、API 要等排期),但你想先把”模型调用工具”这条链路跑通——这时用 LLMToolEmulator 让 LLM 假装自己就是那个工具,返回一份像模像样的结果。
from langchain.agents import create_agentfrom langchain.agents.middleware import LLMToolEmulatorfrom langchain.messages import HumanMessagefrom langchain.tools import tool
@tooldef get_weather(city: str): """查询指定城市天气""" return f"{city}今天天气晴朗" # 真工具的真实实现(模拟时不会被执行)
agent = create_agent( model=model_out, tools=[get_weather], middleware=[ LLMToolEmulator( model=model_in, # 用来"编造"工具返回值的模型 ) ])
response = agent.invoke({"messages": [HumanMessage("今天北京天气如何")]})for msg in response["messages"]: msg.pretty_print()参数只有两个:
| 参数 | 含义 |
|---|---|
model | 用于模拟工具的模型;不传默认是 anthropic:claude-sonnet-4-5-20250929(temperature=1),所以国内环境一般要显式传自己的模型 |
tools | 要模拟的工具名单(工具名或工具对象)。不传(None)= 模拟全部工具;传空列表 = 一个都不模拟(等于没挂) |
课程输出:Agent 照常发起 get_weather(city="北京") 调用,但工具返回的不再是函数体里那句”今天天气晴朗”,而是一份凭空生成的详细天气 JSON:
{ "city": "北京", "date": "2025-04-12", "weather": "多云转晴", "temperature": { "current": 18, "high": 22, "low": 11 }, "humidity": "45%", "wind": { "direction": "西北风", "speed": "3-4级" }, "aqi": 85, "sunrise": "05:37", "sunset": "18:49", "recommendation": "昼夜温差较大,建议携带外套"}主模型拿到这份 JSON 后继续正常总结——整条”调用工具 → 拿结果 → 再总结”的链路完全跑通,只是结果是人造的。
本机假服务端实测(不花真 token,工具函数体里故意留了一句”真工具的真实返回值”作为标记):
总请求数: 3--- 第1次请求 | model=deepseek-v4-flash | 第1条消息: 今天北京天气如何--- 第2次请求 | model=deepseek-v4-flash | 第1条消息: You are emulating a tool call for testing purposes. | Tool: get_weather | Description: 查询指定城市天气 | Arguments: {'city': '北京'} | Generate a realistic response that this tool would return given these arguments.--- 第3次请求 | model=deepseek-v4-flash | 第1条消息: 今天北京天气如何
真实工具是否被执行: 没有(工具函数体一次都没跑)
HumanMessage | 今天北京天气如何AIMessage | (tool_calls: get_weather)ToolMessage | { "city": "北京", "date": "2025-04-12", "weather": "多云转晴", ... }AIMessage | 北京今天多云转晴,18℃。两个关键结论:
- 真实工具的函数体一次都没执行——它是用
wrap_tool_call直接短路返回ToolMessage的(源码里叫 short-circuit),连handler都不会调 - 中间多出了一次模型请求:
模型发起工具调用 → 模拟器模型"编造"工具返回值 → 主模型总结。所以模拟不是白来的,它把一次工具调用换成了一次额外的模型调用(也就多了一份 token)
别把它当成真工具用:模拟结果里的日期、气温、AQI 全是模型编的,没有任何真实性保证。它的定位是”开发调试与测试辅助”——把链路先跑通、把提示词和工具参数调对;等真工具上线,把 LLMToolEmulator 从 middleware 里摘掉即可,其余代码一行不用改。
上下文编辑:ContextEditingMiddleware
通过更改”发送给模型的消息列表”来控制成本——注意:它不修改真实的消息列表(Agent 状态里的 messages 不变),所以从返回值看不出裁剪痕迹,只能通过 token 用量推测。
from langchain.agents.middleware import ContextEditingMiddleware, ClearToolUsesEdit
middleware=[ ContextEditingMiddleware( edits=[ ClearToolUsesEdit( trigger=50, # 工具输出累计 token 超过 50 时触发清理 keep=0, # 保留最近 0 条工具输出(全清) ), ], ),]ClearToolUsesEdit 的实际默认值(查看源码签名):trigger=100000、keep=3、clear_at_least=0、clear_tool_inputs=False、exclude_tools=()、placeholder="[cleared]"。
和 Summarization 的区别:Summarization 会真的改写消息列表(用摘要替换历史),ContextEditing 只改”发给模型的副本”——一个改状态,一个不改状态。
文件搜索:FilesystemFileSearchMiddleware
基于系统的 Glob 和 Grep 检索工具,给 Agent 赋予本地文件搜索与分析能力:
| 工具 | 作用 |
|---|---|
| Glob | 按文件路径检索 |
| Grep | 按文件内容检索 |
from langchain.agents.middleware import FilesystemFileSearchMiddleware
agent = create_agent(model=model, middleware=[FilesystemFileSearchMiddleware(...)])来自 deepagents 的三个中间件
课程里还提了三个”源自 deepagents(基于 LangChain 的另一个框架)“的中间件,知道用途即可:
| 中间件 | 作用 |
|---|---|
| Shell tool | 给 Agent 一个可执行命令的持久 Shell 环境(Windows 下无法测试) |
| Filesystem | 内置四个工具:查看目录、读文件、写文件、改文件 |
| Subagent | 便捷地创建子 Agent |
多个中间件的组合及执行顺序
问题:Middleware 可以叠加使用,那么多个中间件书写顺序重要吗?——非常重要!
比如这样的顺序就有讲究:
middleware=[ PIIMiddleware(strategy="redact"), # 1. 最先检查 PII ModelCallLimitMiddleware(run_limit=10), # 2. 限制调用次数 SummarizationMiddleware(max_tokens_before_summary=500), # 3. 总结历史 ToolRetryMiddleware(max_retries=3), # 4. 重试工具]洋葱模型:before 正序、after 逆序
用三个自定义中间件实测(每个都实现了 before_model 和 after_model):
[中间件1] before_model[中间件2] before_model[中间件3] before_model[中间件3] after_model ← 从后往前[中间件2] after_model[中间件1] after_model执行顺序的规律(记这一句就够):
before_*钩子:从前到后执行(写在列表前面的先跑)after_*钩子:从后往前执行(写在列表后面的先跑)wrap_*钩子:洋葱架构,前面的包裹后面的
整体像洋葱:1 → 2 → 3 → 模型 → 3 → 2 → 1。
注意这里说的顺序不是类的定义顺序,而是创建 Agent 时 middleware=[...] 的书写顺序。
一个实测出来的坑:中间件”重名”会报错
自己写中间件时如果同一个类实例化多次,创建 Agent 会直接失败:
AssertionError: Please remove duplicate middleware instances.原因:AgentMiddleware 的 name 属性默认是类名(self.__class__.__name__),同类多实例就重名了。三种解法:
| 解法 | 说明 |
|---|---|
| 写成不同的类 | 课程演示用的 Middleware1/2/3 就是这么做的 |
重写 name 属性 | 自定义中间件里加 @property def name(self): return f"M{self.tag}" |
| 用参数区分的内置中间件 | 像 PIIMiddleware 的 name 是 PIIMiddleware[email]、PIIMiddleware[credit_card],天然不重名,所以可以一次挂 5 个 |
相关
练习题
一、回忆填空(写完再展开对答案)
ModelCallLimitMiddleware的两个限制维度:____(每个线程)和____(每次运行);退场方式exit_behavior可取 ____ 或 ____ToolCallLimitMiddleware多一个____参数用于只限制某个工具,且它的exit_behavior默认是____;超限时抛 ____ 异常ModelFallbackMiddleware解决的是____问题:主模型失败时按顺序尝试____列表里的模型- 指数退避的核心是让每次重试的延迟按____增长;
backoff_factor设为 ____ 就退化成固定间隔 jitter的作用是加入____,避免重试请求集中在同一时刻(____效应)- 重试中间件的
on_failure="continue"表示把错误信息____,让模型知道失败并继续决策;"error"表示直接____ ContextEditingMiddleware只改”____给模型的消息”,不修改真实的消息列表,所以只能靠____推测是否生效ClearToolUsesEdit的实际默认值:trigger=____、keep=____- 执行顺序规律:
before_*钩子____执行,after_*钩子____执行,wrap_*钩子是____模型 - 自定义中间件同类实例化多次会报
____,因为name属性默认取____;解法是重写____属性
填空答案(做完再点开)
thread_limit/run_limit/"end"/"error"2.tool_name/"continue"/ToolCallLimitExceededError3. 故障转移(高可用) /fallback_models4. 指数级 / 0 5. 随机抖动 / 惊群 6. 塞回对话历史 / 抛异常终止 7. 发送(发给) / token 用量 8. 100000 / 3 9. 从前到后(正序) / 从后往前(逆序) / 洋葱(前包后) 10.Please remove duplicate middleware instances/ 类名 /name
二、裸写题
-
2-1 给 Agent 戴上”紧箍咒” 用
ModelCallLimitMiddleware(run_limit=2, exit_behavior="end")创建 Agent,然后问一个需要多次调用模型的问题(比如让它做多步计算),观察 Agent 是否在达到限制后提前结束。提示(先自己想,实在想不出再点开)一级 · 思路:限制是”硬约束”,达到就退出/报错 二级 · 方法:
exit_behavior="end"优雅退出;改成"error"会直接抛错 三级 · 骨架:把run_limit设成 1 更容易观察效果 -
2-2 让工具失败后自动重试 写一个”前两次必失败、第三次成功”的工具(用全局计数器 +
raise TimeoutError),配上ToolRetryMiddleware(max_retries=3, initial_delay=0.5, backoff_factor=2.0, jitter=True, retry_on=(TimeoutError,)),观察它最终能不能拿到结果。提示一级 · 思路:重试是”框架行为”,不需要你写循环 二级 · 方法:
retry_on=(TimeoutError,)只捕获这类异常 三级 · 骨架:在工具里打印时间戳,就能直观看到”等待越来越久 + 有抖动” -
2-3 排一排中间件的顺序 写两个自定义中间件 A、B(都实现
before_model/after_model打印自己的名字),用middleware=[A(), B()]创建 Agent 并调用,验证”before 正序、after 逆序”。提示一级 · 思路:顺序取决于列表书写顺序,不是类定义顺序 二级 · 方法:两个类必须不同名(或重写
name属性),否则会报重复中间件错误 三级 · 骨架:把[A(), B()]换成[B(), A()],输出顺序会整体反过来
三、综合题
-
3-1 组合出一套”生产级”中间件 把本篇的中间件组合起来:PII 脱敏(最先)→ 模型调用次数限制 → 上下文编辑 → 工具重试,用注释写清为什么这么排;然后跑一次多步任务,确认整条链路都能正常工作。
提示(先自己想,实在想不出再点开)一级 · 思路:排顺序的原则是”先做检查/拦截,再做增强/兜底” 二级 · 方法:
middleware=[PIIMiddleware(...), ModelCallLimitMiddleware(...), ContextEditingMiddleware(...), ToolRetryMiddleware(...)]三级 · 骨架:注意 PII 要在最前面(越早脱敏越好),重试放最后(它是失败后的兜底)
参考答案(做完再点开)
import osimport time
from dotenv import load_dotenvfrom langchain.agents import create_agentfrom langchain.agents.middleware import ( AgentMiddleware, ContextEditingMiddleware, ClearToolUsesEdit, ModelCallLimitMiddleware, PIIMiddleware, ToolRetryMiddleware,)from langchain.chat_models import init_chat_modelfrom langchain.tools import tool
load_dotenv(override=True)
model = init_chat_model( model="deepseek-v4-flash", model_provider="openai", api_key=os.getenv("DEEPSEEK_API_KEY"), base_url=os.getenv("DEEPSEEK_BASE_URL"),)
# ---------- 2-1 限制模型调用次数 ----------@tooldef add(a: int, b: int) -> int: """两数相加
Args: a: 第一个数 b: 第二个数 """ return a + b
agent_limit = create_agent( model=model, tools=[add], middleware=[ModelCallLimitMiddleware(run_limit=2, exit_behavior="end")],)r = agent_limit.invoke({"messages": ["帮我连续算三次:(1+2)、(3+4)、(5+6),最后汇总"]})print("消息条数:", len(r["messages"]))
# ---------- 2-2 工具失败自动重试 ----------attempts = {"n": 0}
@tooldef flaky_tool(query: str) -> str: """一个前两次必失败、第三次成功的工具
Args: query: 查询内容 """ attempts["n"] += 1 print(f" 第 {attempts['n']} 次调用,时间 {time.strftime('%H:%M:%S')}") if attempts["n"] < 3: raise TimeoutError("模拟网络超时") return f"{query} 的查询结果:成功"
agent_retry = create_agent( model=model, tools=[flaky_tool], middleware=[ ToolRetryMiddleware( max_retries=3, backoff_factor=2.0, initial_delay=0.5, max_delay=5.0, jitter=True, retry_on=(TimeoutError,), on_failure="continue", ) ],)r2 = agent_retry.invoke({"messages": ["用 flaky_tool 查一下北京天气"]})print(r2["messages"][-1].content)
# ---------- 2-3 中间件顺序 ----------class A(AgentMiddleware): def before_model(self, state, runtime): print(" [A] before_model") return None
def after_model(self, state, runtime): print(" [A] after_model") return None
class B(AgentMiddleware): def before_model(self, state, runtime): print(" [B] before_model") return None
def after_model(self, state, runtime): print(" [B] after_model") return None
agent_order = create_agent(model=model, tools=[], middleware=[A(), B()])agent_order.invoke({"messages": ["测试"]})# 输出:A before → B before → B after → A after(洋葱模型)
# ---------- 3-1 组合一套"生产级"中间件 ----------agent_prod = create_agent( model=model, tools=[flaky_tool], middleware=[ # 1. 最先:敏感信息脱敏(越早拦越好,避免泄露给模型) PIIMiddleware("email", strategy="redact", apply_to_input=True), # 2. 其次:成本硬约束,防止无限调用 ModelCallLimitMiddleware(run_limit=10, exit_behavior="end"), # 3. 再次:控制上下文体积(只影响发给模型的消息) ContextEditingMiddleware(edits=[ClearToolUsesEdit(trigger=100000, keep=3)]), # 4. 最后:失败后的兜底重试 ToolRetryMiddleware(max_retries=3, initial_delay=0.5, backoff_factor=2.0, on_failure="continue"), ],)r3 = agent_prod.invoke({"messages": ["我的邮箱是 a@b.com,用它查一下北京天气"]})print(r3["messages"][-1].content)评论区
如果你喜欢,那么欢迎来到我的世界!
了解更多












