
点击上方“Deephub Imba”,关注公众号,好文章不错过 !
用 LangChain 构建 AI Agent 的人应该都遇到过这种情况:测试阶段一切正常,部署到生产环境就开始出各种问题。上下文管理混乱,Agent 的行为变得难以预测,最后不得不写一堆自定义代码来控制信息流向。
这是因为在v1.0 之前的 LangChain 对上下文工程的支持不够系统化。上下文工程的本质其实就是信息管理——给 AI 多少信息、什么时候给、以什么方式给。信息过载会导致模型困惑,信息不足则无法完成任务。这个平衡点一直很难把握。

LangChain v1.0 引入的中间件机制就是为了解决这个问题。中间件的作用类似于一个信息协调层,在用户输入到达模型之前进行必要的处理:
这种架构保证了模型接收到的始终是经过精心组织的上下文。
对于熟悉 FastAPI 的开发者来说,LangChain 中间件的概念几乎可以无缝迁移。FastAPI 的中间件拦截 HTTP 请求,LangChain 的中间件拦截 Agent 调用,底层逻辑完全一致。
FastAPI 中间件处理的典型任务:
LangChain 中间件的对应场景:
执行流程也是相同的组合模式:
Request → Middleware Stack → Endpoint Handler → ResponseUser Input → Middleware Stack → AI Model → Response中间件按照注册顺序依次执行,这种模式让功能扩展变得很直观。
Agent 失败往往不是模型能力的问题,而是上下文处理出了问题。主要体现在几个方面:
缺少灵活的上下文切换机制。不同场景需要不同的上下文策略,但实现起来很麻烦。长对话的上下文管理是个难题。Token 限制对话历史太长模型就处理不过来了。工具调用权限难以精确控制。有时候你只想让 Agent 使用特定的几个工具,但没有优雅的方式来实现这个需求。任何稍微复杂的需求都得写自定义代码,没有标准化的解决方案。
旧的实现方式充斥着大量配置参数:
from langchain.agents import AgentExecutor, create_openai_tools_agent
from langchain_openai import ChatOpenAI
tools = [search_tool, calculator_tool, database_tool]
llm = ChatOpenAI(model="gpt-4")
agent = create_openai_tools_agent(llm, tools, prompt)
# Too many confusing settings!
agent_executor = AgentExecutor(
agent=agent,
tools=tools,
max_iterations=15, # How many times can it try?
max_execution_time=300, # How long can it run?
handle_parsing_errors=True, # What if something breaks?
return_intermediate_steps=True, # Show me the steps?
trim_intermediate_steps=10, # How much to remember?
# and many more confusing options...
)更极端的情况是完全手写 Agent 循环:
def custom_agent_loop(user_input, tools, llm):
messages = [{"role": "user", "content": user_input}]
for iteration in range(10):
# You have to manually do everything!
if len(messages) > 20:
messages = summarize_history(messages) # Clean up old messages
available_tools = select_tools(messages, tools) # Pick which tools to use
system_prompt = generate_prompt(iteration) # Create instructions
response = llm.invoke(messages, tools=available_tools)
# And more manual work...这种实现方式的问题很明显:
代码可读性差,维护成本高。不同项目之间的实现各不相同,无法复用。新增功能需要大量重构,扩展性很受限。
v1.0 的中间件设计借鉴了成熟的软件工程实践,把功能模块化,然后通过组合来实现复杂逻辑。

中间件可以在 Agent 执行流程的不同阶段介入:
before_model 在模型调用前执行,通常用于输入预处理,比如文本清洗或格式标准化。
wrap_model_call 包裹模型调用过程,可以修改传递给模型的参数,比如动态调整可用工具列表。
wrap_tool_call 拦截工具调用,实现权限控制或者参数验证。
after_model 在模型返回后执行,用于输出验证或者安全检查。
LangChain v1.0 提供了一些常用的中间件实现,开箱即用。create_agent 函数的设计就是围绕中间件展开的,这是个很重要的架构决策。
from langchain.agents import create_agent
from langchain.agents.middleware import (
PIIMiddleware,
SummarizationMiddleware,
HumanInTheLoopMiddleware
)
agent = create_agent(
model="claude-sonnet-4-5-20250929",
tools=[read_email, send_email],
middleware=[
# Hide email addresses automatically (privacy protection)
PIIMiddleware("email", strategy="redact"),
# Block phone numbers completely (extra privacy)
PIIMiddleware("phone_number", strategy="block"),
# When conversation gets long, make a short summary
# (like creating a highlight reel of a long movie)
SummarizationMiddleware(
model="claude-sonnet-4-5-20250929",
max_tokens_before_summary=500
),
# Before sending emails, ask a human "Is this okay?"
# (like a safety check before hitting send)
HumanInTheLoopMiddleware(
interrupt_on={
"send_email": {
"allowed_decisions": ["approve", "edit", "reject"]
}
}
),
]
)这段代码实现了几个关键功能:
PIIMiddleware 处理个人敏感信息,邮箱地址会被脱敏处理,电话号码直接阻断,确保隐私数据不会泄露给模型。
SummarizationMiddleware 解决长对话的上下文管理问题。Token 数超过阈值后自动生成摘要,保持上下文简洁的同时不丢失关键信息。
HumanInTheLoopMiddleware 在关键操作前加入人工审核。比如发送邮件这种操作,必须经过人类批准才能执行。
每个中间件负责一个具体的功能,想添加新能力直接往列表里加就行,代码结构很清晰。
除了这几个以外,v1.0 还提供了其他常用中间件:
Token 统计和预算控制、响应缓存机制、错误处理和重试逻辑、自定义日志记录等等。
官方的文档文档写得比较详细,查起来也方便。
内置中间件覆盖了常见场景,但真正体现灵活性的是自定义中间件的能力。
我们举个例子,假设需要根据用户的技术水平动态调整 Agent 的能力:
from dataclasses import dataclass
from typing import Callable
from langchain_openai import ChatOpenAI
from langchain.agents.middleware import AgentMiddleware, ModelRequest
from langchain.agents.middleware.types import ModelResponse
# First, define what you want to track about users
@dataclass
class Context:
user_expertise: str = "beginner" # Is user a beginner or expert?
# Create your custom middleware
class ExpertiseBasedToolMiddleware(AgentMiddleware):
def wrap_model_call(
self,
request: ModelRequest,
handler: Callable[[ModelRequest], ModelResponse]
) -> ModelResponse:
# Check: Is this user a beginner or expert?
user_level = request.runtime.context.user_expertise
if user_level == "expert":
# Experts get powerful AI and advanced tools
model = ChatOpenAI(model="gpt-5")
tools = [advanced_search, data_analysis]
else:
# Beginners get simpler AI and basic tools
model = ChatOpenAI(model="gpt-5-nano")
tools = [simple_search, basic_calculator]
# Update what the AI sees
request.model = model
request.tools = tools
# Send it forward to the AI
return handler(request)
# Now use your custom middleware (just like the built-in ones!)
agent = create_agent(
model="claude-sonnet-4-5-20250929",
tools=[simple_search, advanced_search, basic_calculator, data_analysis],
middleware=[ExpertiseBasedToolMiddleware()], # Your custom middleware here!
context_schema=Context
)这个中间件实现了能力分级:
先从运行时上下文读取用户的技术水平标识。
如果是专家用户,分配更强的模型(gpt-5)和高级工具(advanced_search、data_analysis)。如果是初学者,使用轻量模型(gpt-5-nano)和基础工具(simple_search、basic_calculator)。
每次模型调用前这个逻辑都会自动执行,根据用户身份动态调整 Agent 配置。
这种模式类似游戏的难度调节——新手和老手面对的是不同的游戏环境,但切换过程是无感的。只不过这里调整的不是游戏难度,而是 AI 的能力边界和可用资源。
中间件系统提供了多个介入点,覆盖 Agent 执行的全流程:

带来的改进是系统性的:
代码组织更规范。每个中间件都是独立模块,功能边界清晰,不会出现逻辑耦合的问题。
复用性大幅提升。写好的中间件可以在不同项目间共享,不用每次都重新实现。
组合灵活性很高。像搭积木一样组合不同的中间件,快速实现复杂功能。
测试和调试简化了。每个中间件可以单独测试,出问题也容易定位。
生产环境的适配性更好。常见的生产需求都有对应的模式,不需要从零开始摸索。
v1.0 之前,上下文控制基本靠手写代码,没有统一的抽象层。中间件机制把上下文工程变成了系统化的工程实践。无论是使用现成的中间件处理通用场景,还是开发自定义中间件满足特定需求,这套机制都提供了足够的灵活性和控制力。这对构建可靠的生产级 Agent 来说很关键。
create_agent 以中间件为核心的设计不只是功能上的补充,更像是对 Agent 构建范式的重新定义——把上下文工程提升到和模型选择、工具设计同等重要的位置。
作者:Aayushmaan Hooda
喜欢就关注一下吧:
点个 在看 你最好看!
本文分享自 DeepHub IMBA 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!