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

演讲者：LangChain 架构演进史

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

---

开场：一个尴尬的问题

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

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

（停顿，看台下举手）

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

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

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

---

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

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

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

from langchain import LLMChain, 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-else
        context_compression_chain,
        history_saving_chain
    ]
)

代码爆炸了。

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

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

---

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

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

他们发布了 LangGraph。

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

LangGraph 的核心思想很简单：

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

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

from langgraph.graph import StateGraph

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 做了三件大事：

1. 精简主包，生态拆分

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

2. LangGraph 独立，但深度协作

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

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

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

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

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

from langchain import Agent, Middleware

class MyMiddleware(Middleware):
    async def before_model(self, state, config):
        # 模型调用前：压缩上下文
        state.messages = compress_history(state.messages)
        return state
    
    async def modify_model_request(self, request, config):
        # 修改本次请求：加缓存标签
        request.metadata["cache"] = True
        return request
    
    async def after_model(self, state, response, config):
        # 模型调用后：安全审查
        if contains_sensitive_info(response):
            raise SecurityException("检测到敏感信息")
        return state

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 月：

• langchain 最新 1.3.10
• langchain-core 最新 1.4.8
• langgraph 最新 1.0.0
• PyPI 总下载量突破 24 亿次

Python 3.9 已被放弃，最低要求 3.10+，部分新包甚至要求 3.11+。

---

尾声：给还在"毕业"路上的开发者

LangChain 的三年演进，其实是一个框架与开发者之间"信任重建"的过程。

• 0.x 时代：框架说"我帮你搞定一切"，开发者说"好"，然后发现搞不定。
• LangGraph 时代：框架说"我给你控制"，开发者说"好，但上下文工程太烦"。
• 1.0 时代：框架说"我给你控制，也给你上下文工程的工具"，开发者说"这次好像真的可以了"。

中间件架构的本质，是承认了一件事：

Agent 开发的复杂度，不是来自"业务逻辑"，而是来自"横切关注点"——安全、成本、缓存、审查、人机协同……

这些不应该散落在每个节点里重复实现，而应该像 Web 开发一样，通过可组合、可复用、可插拔的中间件来解决。

---

结束语

如果你曾经因为 LangChain 的"黑盒"而离开，现在可能是时候回来看看了。

LangChain 1.0 不是完美的，但它终于听懂了开发者真正想要什么。

我们要的不是"少写代码"，而是"在需要控制的时候，能控制得了"。

谢谢大家。

---

（全文完，2026 年 6 月 29 日）