【LangChain】从“链式调用“到“中间件架构“——一场关于“控制“的三年长征-Seo优化-塔城地区网站建设公司

LangChain：从"链式调用"到"中间件架构"——一场关于"控制"的三年长征

演讲者：LangChain 架构演进史

听众：所有在 Agent 开发中"毕业"过、又回来的开发者

开场：一个尴尬的问题

大家好。我想先问在座的各位一个问题：

你们有多少人，用 LangChain 写了个 Demo，觉得"卧槽这框架真香"，然后到了生产环境，发现代码越写越像"框架之外的手写代码"，最后干脆"毕业"离开了 LangChain？

（停顿，看台下举手）

好，我看到不少手。不举手的要么是在座的大佬，要么是还没写到生产环境。

我今天要讲的，就是 LangChain 团队如何花了近三年时间，终于承认了一个事实：

开发者需要的不是"便利"，而是"控制"。

第一章：2022-2023，链式调用的"蜜月期"

回到 2022 年底，ChatGPT 刚火，所有人都在问：“怎么把 LLM 接到我的系统里？”

LangChain 给出的答案是：链（Chain）。

fromlangchainimportLLMChain,PromptTemplate template="""你是一个客服助手。 用户问题：{question} 请给出回答："""chain=LLMChain(llm=ChatOpenAI(),prompt=PromptTemplate.from_template(template))chain.run("我的订单什么时候到？")

三行代码，一个客服机器人。当时所有人都疯了，这太方便了！

于是LLMChain、ConversationChain、SequentialChain、RetrievalQA……各种 Chain 像雨后春笋一样冒出来。

但问题来了。

当你的客服机器人需要：

先查订单状态
再判断用户情绪
情绪不好时转人工
同时控制上下文长度别超过 4K token
还要记录对话历史到数据库

你的"链"就变成了：

# 伪代码，但相信我，真实代码比这更惨chain=SequentialChain(chains=[order_lookup_chain,emotion_analysis_chain,conditional_branch_chain,# 这个 Chain 里还有 if-elsecontext_compression_chain,history_saving_chain])

代码爆炸了。

而且你发现，LangChain 的 Chain 抽象为了"通用性"，把太多东西藏在了黑盒里。你想改一个细节？对不起，要么继承重写，要么干脆不用 Chain，自己手写。

这就是第一个"毕业"潮。

第二章：2024，LangGraph 的"控制革命"

2024 年 2 月，LangChain 团队做了一件事：

他们发布了 LangGraph。

不是作为 LangChain 的一个新 Chain，而是作为一个全新的、独立的框架。

LangGraph 的核心思想很简单：

Agent 不是一个"链"，而是一个"图"。

节点是步骤，边是流转条件，你可以精确控制每一步的输入、输出、状态。

fromlanggraph.graphimportStateGraph builder=StateGraph(State)builder.add_node("lookup_order",lookup_order_node)builder.add_node("analyze_emotion",analyze_emotion_node)builder.add_node("human_handoff",human_handoff_node)builder.add_edge("lookup_order","analyze_emotion")builder.add_conditional_edges("analyze_emotion",route_by_emotion,# 你的自定义路由函数{"angry":"human_handoff","calm":"generate_response"})

控制回来了！

你可以看到每一步的状态，可以插入自定义逻辑，可以精确控制流转。

但新的问题出现了：

控制有了，但上下文工程（Context Engineering）太难了。

怎么在调用模型前压缩历史对话？
怎么动态切换轻量模型和重模型？
怎么加缓存标签？
怎么在模型返回后做安全审查？

这些不是"图结构"能解决的，这是"横切关注点"——每个节点都可能需要，但又不属于任何一个节点的核心逻辑。

于是开发者又开始在 LangGraph 的节点里写重复代码，或者干脆在图外面包一层自己的"前置处理/后置处理"。

第二个"毕业"潮来了。

第三章：2025 年 10 月 20 日，LangChain 1.0——“我们错了”

2025 年 10 月 20 日，LangChain 发布了 1.0.0。

官方博客的标题很直接：

“LangChain 1.0: 为生产级 AI 应用而生”

但在我看来，这篇博客的潜台词是：

“我们错了。过去三年，我们给了你们便利，但剥夺了你们的控制。现在我们要把控制还回来。”

1.0 做了三件大事：

精简主包，生态拆分

langchain主包不再是一个大杂烩。模型集成拆到langchain-openai、langchain-anthropic……按需安装，避免依赖地狱。

LangGraph 独立，但深度协作

LangGraph 成为独立的 PyPI 包，但 LangChain 1.0 的 Agent 直接建立在 LangGraph Runtime 之上。

LangChain 1.0 Agent = LangGraph Runtime（控制流） + LangChain Middleware（上下文工程）

引入 Middleware API——这是今天的重点

LangChain 1.0 从 Web 服务器（Express、FastAPI）借鉴了中间件模式。

在 Agent 的核心循环中，引入了三个拦截点：

fromlangchainimportAgent,MiddlewareclassMyMiddleware(Middleware):asyncdefbefore_model(self,state,config):# 模型调用前：压缩上下文state.messages=compress_history(state.messages)returnstateasyncdefmodify_model_request(self,request,config):# 修改本次请求：加缓存标签request.metadata["cache"]=Truereturnrequestasyncdefafter_model(self,state,response,config):# 模型调用后：安全审查ifcontains_sensitive_info(response):raiseSecurityException("检测到敏感信息")returnstate agent=Agent(model="gpt-4",tools=[search,calculator],middleware=[MyMiddleware(),LoggingMiddleware()])

多个中间件按顺序执行，入站正序、出站逆序。

你可以像搭积木一样组合：

上下文压缩中间件
模型降级中间件（token 贵时切到轻量模型）
缓存中间件
人机协同中间件（Human-in-the-loop）
安全审查中间件

而且，这些中间件是"横切"的——不侵入你的业务逻辑节点，但每个节点都能享受到。

第四章：2026 年，LangGraph 1.0 与生态成熟

2026 年 5 月 27 日，LangGraph 1.0 正式发布。

这标志着 LangChain 生态的分工彻底清晰：

层级职责对应包
运行时 Agent 循环、状态管理、图结构、持久化langgraph
上下文工程中间件、工具调用、提示词管理、模型集成langchain+langchain-core
模型集成各厂商 LLM 的适配器langchain-openai、langchain-anthropic等

截至 2026 年 6 月：