用 LangChain 构建 AI Agent 的人应该都遇到过这种情况：测试阶段一切正常，部署到生产环境就开始出各种问题。上下文管理混乱，Agent 的行为变得难以预测，最后不得不写一堆自定义代码来控制信息流向。
这是因为在 v1.0 之前的 LangChain 对上下文工程的支持不够系统化。上下文工程的本质其实就是信息管理——给 AI 多少信息、什么时候给、以什么方式给。信息过载会导致模型困惑，信息不足则无法完成任务。这个平衡点一直很难把握。
LangChain v1.0 引入的中间件机制就是为了解决这个问题。中间件的作用类似于一个信息协调层，在用户输入到达模型之前进行必要的处理：
- 规范化输入格式
- 注入相关背景知识
- 过滤敏感信息
- 限制工具调用权限
这种架构保证了模型接收到的始终是经过精心组织的上下文。
后端视角下的中间件模式
对于熟悉 FastAPI 的开发者来说，LangChain 中间件的概念几乎可以无缝迁移。FastAPI 的中间件拦截 HTTP 请求，LangChain 的中间件拦截 Agent 调用，底层逻辑完全一致。
FastAPI 中间件处理的典型任务：
- 身份认证
- 请求日志
- CORS 配置
LangChain 中间件的对应场景：
- 上下文管理
- 安全控制
- 工具调度
- 运行时监控
执行流程也是相同的组合模式：
- FastAPI:
Request → Middleware Stack → Endpoint Handler → Response - LangChain:
User Input → Middleware Stack → AI Model → Response
中间件按照注册顺序依次执行，这种模式让功能扩展变得很直观。
v1.0 之前的技术问题
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
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 构建范式的重新定义——把上下文工程提升到和模型选择、工具设计同等重要的位置。
