LangChain 1.0 之后：从 Agent 框架走向 AI 应用运行时

截至 2026 年 9 月，LangChain OSS Python 主线已经进入 1.4.x。回看 1.0.0 之后这一阶段，会发现 LangChain 真正发生的变化，并不是"又增加了一堆模型和工具集成"，而是逐渐完成了一次产品定位上的迁移：从早期的 LLM 编排框架，转向以 Agent 为核心、以 Middleware 为扩展机制、以 LangGraph 为运行时底座、以模型能力抽象和 MCP 为生态接口的 AI 应用基础设施。

一、LangChain 1.0 之后到底变了什么

如果只用一句话总结：

LangChain 1.0 之后的主线，不再是"封装更多 LLM 能力"，而是"把 Agent 从一个 demo 级 loop，逐渐变成一个可控制、可恢复、可扩展、可治理的应用执行单元"。

这个变化大致沿着六条线展开：

演进方向	代表能力	工程意义
Agent API	`create_agent` 持续增强	Agent 成为一级开发抽象
Middleware	retry、fallback、HITL、PII、summarization、tool selector 等	把 Agent 的"控制逻辑"组件化
Model Abstraction（抽象）	`profile`、ProviderStrategy、统一 content blocks	从"统一 API"走向"统一能力模型"
Streaming	Event Streaming v3、content-block-centric streaming	从"返回结果"走向"实时执行状态"
MCP	`langchain.mcp.MCPAdapter`	从自定义 Tool 生态走向开放 Tool 协议
Agent Harness	Deep Agents、skills、filesystem、subagents、memory	从"Agent loop"进一步走向"复杂任务执行环境"

所以，真正值得关注的并不是某一个 API，而是这一套架构逐渐形成了一个非常明确的层次：

Model → Tool → Agent → Middleware → LangGraph Runtime → Deep Agent/Harness

LangChain 自己越来越聚焦上层 Agent building blocks；LangGraph 承担可靠执行与状态管理；更复杂的任务型 Agent 则交给 Deep Agents。官方现在甚至明确把三者定义成不同层次：LangChain 是 Agent building blocks，LangGraph 是低层 orchestration（编排）/runtime，Deep Agents 是更"batteries-included"的 agent harness。

二、1.1：第一个明显变化，是 LangChain 开始"理解模型能力"

LangChain 1.0 本身已经确定了新的基本形态：create_agent 成为标准 Agent API，并且通过 Middleware 暴露扩展点；原来的大量 legacy 能力则被迁移到 langchain-classic。

而 1.1 做的一个非常重要、但容易被低估的事情，是加入了 Model Profiles。

以前 LangChain 的抽象更多是：

"所有模型都实现同一套接口。"

1.1 往后，它开始变成：

"所有模型都有统一接口，但同时可以描述自己的 capability。"

例如：

复制代码

model.profile

现在可以暴露包括：

max_input_tokens
tool_calling
structured_output
image_inputs
reasoning_output

等能力信息。官方文档说明，这些数据主要来自 models.dev，并由 LangChain 各 provider integration 进行补充和增强。

这看上去只是多了一个 profile 字段，但对于 Agent runtime 来说意义非常大。

因为以前应用开发者往往需要写这种代码：

ini 复制代码

if provider == "openai":
    ...
elif provider == "anthropic":
    ...
elif provider == "gemini":
    ...

现在越来越多逻辑可以变成：

csharp 复制代码

if model.profile.get("structured_output"):
    ...

或者根据 context window 决定什么时候做 summarization。

这实际上意味着 LangChain 的抽象层从：

API compatibility（兼容性）

逐渐开始向：

Capability abstraction（能力抽象）

演进。

这是一个非常关键的架构升级。

因为真正做多模型应用之后，最大的痛点从来不是：

"怎么把 OpenAI 换成 Anthropic？"

而是：

"怎么让应用知道这个模型到底支持什么，然后动态决定应该怎么运行？"

LangChain 1.1 开始明显在解决这个问题。

三、1.1 的另一个重点：Middleware 开始成为 LangChain 的"操作系统层"

如果要找 LangChain 1.x 最重要的架构设计，我会把 Middleware 放在非常靠前的位置。

1.0 已经把 middleware 作为 create_agent 的核心扩展机制，而之后几个版本实际上一直在持续增强它。

现在官方已经提供了一整套 production-oriented middleware（面向生产的中间件），例如：

Summarization
Human-in-the-loop
Model retry
Tool retry
Model fallback
Model/tool call limit
PII detection
To-do list
LLM tool selector
Context editing
Shell
File search
Filesystem
Subagent

等。

这说明 LangChain 对 Agent 的认识发生了一个变化。

早期 Agent 通常是：

sql 复制代码

LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
Final Answer

而现在更接近：

bash 复制代码

                ┌──────────── Middleware ────────────┐
                │                                    │
Input ──→ before_agent ──→ Model ──→ Tool ──→ after_agent
                              ↑           ↑
                      before/after    wrap_tool
                              │           │
                         wrap_model       │
                │                                    │
                └────────────────────────────────────┘

Middleware 暴露了诸如：

before_agent
before_model
after_model
after_agent
wrap_model_call
wrap_tool_call

等 hook。

这其实已经非常接近一个 Agent execution pipeline。

对于真正的企业应用来说，这个抽象比"多几个 Agent API"重要得多。

因为企业 Agent 最终一定要处理：

重试
fallback
timeout
quota
audit
PII
guardrail
human approval
context management
tool policy
dynamic routing

如果这些东西都写进 Agent prompt 或者写在业务代码里，系统很快就会失控。

Middleware 的意义，就是把这些 concern 从 Agent business logic 中拆出去。

四、1.1：Summarization 开始从"聊天历史技巧"变成 Context Engineering

另一个值得注意的变化是 SummarizationMiddleware。

它真正要解决的不是传统意义上的"聊天记录太长"，而是今天 Agent 系统中的一个核心问题：

Context Engineering

官方现在已经把 context engineering 单独作为 Agent 架构的重要概念来描述：什么信息应该给模型、什么时候给、应该保留多少、哪些应该持久化，都属于 Agent 的运行时 context 管理。

例如 summarization middleware 可以根据 token 数等条件，把历史消息压缩成 summary，同时保留最近消息。

这背后的思维发生了变化：

以前：

Prompt Engineering = 怎么写好 system prompt。

现在：

Context Engineering = 怎么在整个 Agent 生命周期中动态构造模型看到的 context。

这也是后面 Deep Agents、Skills、Memory、Filesystem 等能力会出现的理论基础。

五、1.2：LangChain 开始正式拥抱"Provider-specific capabilities"

1.2 是一个很有意思的版本。

它没有继续追求：

"把所有 Provider 差异抹平。"

反而开始承认：

Provider 的高级能力本来就是不同的。

因此 1.2 给 Tool 引入了 extras 这一类 provider-specific configuration 能力，使 Agent 可以使用 Anthropic 的 programmatic tool calling、tool search，以及不同 provider 的 built-in tools。

同时，1.2 加强了 structured output：

ini 复制代码

response_format=...

可以在：

复制代码

ProviderStrategy
ToolStrategy

之间进行选择。

当模型原生支持 structured output 时，可以优先使用 provider-native 能力；否则再退回 tool calling。

更重要的是，1.1 引入的 Model Profile 和这一机制结合以后，LangChain 可以自动判断：

"这个模型是否支持 native structured output？"

从而决定应该采用哪种 strategy。

这意味着 LangChain 的模型抽象正在从：

复制代码

统一接口

变成：

diff 复制代码

统一接口
+
能力描述
+
能力协商
+
Provider-specific escape hatch

这是非常成熟的一种 framework design。

因为真正意义上的"抽象"从来不是把所有东西强行做成一样，而是：

把共同部分标准化，把差异部分显式化。

六、1.2 之后，Structured Output 开始从"JSON 输出"走向"应用协议"

这一点对 AI 应用开发者尤其重要。

很多早期 Agent 代码里都有：

arduino 复制代码

json.loads(llm.invoke(...))

或者：

javascript 复制代码

请严格输出 JSON

这种方式本质上仍然是 prompt-level contract。

LangChain 现在更强调：

ini 复制代码

response_format=MySchema

然后让底层选择：

markdown 复制代码

Native structured output
        ↓
ProviderStrategy

或

Tool calling
        ↓
ToolStrategy

最终 Agent state 中拿到的是结构化结果。

这实际上意味着 Agent 的输出越来越像：

application protocol

而不是：

一段碰巧长得像 JSON 的文本。

这对前后端、工作流、Agent-to-Agent 调用都非常重要。

七、另一个长期趋势：Content Blocks

LangChain 1.0 引入的 content_blocks 在 1.x 后续版本持续变得重要。

传统 LLM abstraction 一个非常明显的问题是：

不同 provider 对模型响应的表达完全不同。

Anthropic 可能有：

arduino 复制代码

thinking
tool_use
text
citation

OpenAI 可能有：

复制代码

reasoning
web_search
computer_use

而不同 SDK 又可能用完全不同的 object structure。

LangChain 现在用标准化 content blocks 提供了一层统一表示：

复制代码

message.content_blocks

把 reasoning、text、tool call 等内容转换成统一结构，同时保留原始 content 兼容性。

这个设计的真正价值是：

Agent 应用不再必须知道每一个模型 provider 的内部 message schema。

于是下面这种代码开始成为可能：

erlang 复制代码

for block in message.content_blocks:
    if block["type"] == "reasoning":
        ...
    elif block["type"] == "tool_call":
        ...

这件事情看似只是"数据结构统一"，实际上是 LangChain 正在建立一个：

Model Interaction Intermediate Representation（模型交互中间表示）

可以把它理解成：

LLM 世界里的 IR。

这对后面的 streaming、frontend rendering、observability、agent routing 都非常重要。

八、1.3：重点开始转向 Streaming------从"结果 API"进入"执行事件 API"

1.3 一个很明确的变化，是为 Agent 增加：

ini 复制代码

stream_events(..., version="v3")

支持。

这一变化背后的重要性，比版本号看起来大得多。

早期 Agent streaming 主要关注：

"把 token 一个一个吐出来。"

但真正的 Agent UI 需要知道的东西其实远不止 token：

sql 复制代码

Model started
Model thinking
Tool call started
Tool call arguments
Tool result
State update
Sub-agent started
Sub-agent completed
Final response

所以现在 LangChain 的 Event Streaming 越来越强调 typed projections：

messages
tool calls
state
custom updates
final output

而且直接继承 LangGraph 的事件模型。

这代表一个很明显的架构变化：

从

复制代码

LLM → token stream

变成

csharp 复制代码

Agent Run
  ├── Model event
  ├── Tool event
  ├── State event
  ├── Middleware event
  └── Final output

对于做真正产品的团队，这非常重要。

因为现在 Agent 前端不再只是一个：

ChatGPT-like streaming text box。

而越来越像：

Agent execution console

例如：

markdown 复制代码

正在分析任务
    ↓
正在调用搜索工具
    ↓
搜索完成
    ↓
正在运行 SQL
    ↓
需要人工确认
    ↓
继续执行

LangChain 现在的 streaming infrastructure（基础设施）已经明显朝这个方向设计。

九、Human-in-the-loop：Agent 开始具备真正的"人机协同执行模型"

这是 LangChain 1.x 很值得工程师关注的一条线。

HITL 已经不是：

"让模型输出一句'请人工确认'。"

而是：

scss 复制代码

Model proposes tool call
        ↓
Middleware intercept
        ↓
interrupt()
        ↓
Persistence
        ↓
Human decision
        ↓
resume

现在内置的 HumanInTheLoopMiddleware 支持：

approve
edit
reject

三类决策。

更关键的是，interrupt 之后的执行状态由 LangGraph persistence 保存，因此 Agent 可以真正停下来，等人处理，然后从原来的执行位置恢复。

这意味着 Agent 的 execution model 已经从：

vbscript 复制代码

request → response

变成：

vbscript 复制代码

request
  ↓
plan
  ↓
action
  ↓
interrupt
  ↓
human
  ↓
resume
  ↓
action
  ↓
result

这才真正符合企业 Agent 的现实。

例如：

复制代码

读取邮件
 ↓
生成回复
 ↓
发送邮件 ← HITL
 ↓
人工批准
 ↓
真正发送

或者：

sql 复制代码

分析生产数据库
 ↓
生成 UPDATE SQL
 ↓
HITL
 ↓
人工批准
 ↓
执行

从架构角度讲，这意味着：

Agent 不再只是 autonomous agent，也开始成为 governed（受控） agent。

十、Guardrails 开始进入 Agent Runtime，而不再只是 Prompt

LangChain 后续大量 middleware 的另一个共同主题，就是 Safety / Reliability（可靠）。

比如 PII middleware 可以：

block
redact
mask
hash

并可以分别检查：

input
model output
tool results

等位置。

这说明 LangChain 对 guardrail 的理解已经从：

perl 复制代码

system prompt:
不要泄露隐私

走向：

css 复制代码

Agent Runtime
    ↓
Input Guardrail
    ↓
Model
    ↓
Tool
    ↓
Output Guardrail

这当然不是说 prompt guardrail 没用了。

而是说：

安全策略应该尽可能靠近执行边界。

这也是 middleware 架构真正有价值的地方。

十一、Retry / Fallback / Limits：Agent 开始具备"生产系统属性"

另一个变化非常工程化，但我认为非常重要。

LangChain 现在已经有：

Model Retry
Tool Retry
Model Fallback
Model Call Limit
Tool Call Limit

等机制。

这代表 LangChain 对 Agent 的假设已经从：

"模型大多数时候会成功。"

变成：

"模型是一个不可靠的远程依赖。"

实际上 Agent 系统里的 failure mode 非常多：

bash 复制代码

LLM timeout
LLM rate limit
Tool timeout
Tool 500
Provider unavailable
Context overflow
Malformed structured output
Model generated invalid tool args
Human intervention

如果这些都由业务代码处理：

erlang 复制代码

try:
    ...
except:
    ...

最终代码一定会非常复杂。

Middleware 把这些横切逻辑统一起来后，Agent 本身的业务逻辑反而可以保持简单。

十二、MCP：LangChain 的 Tool 世界开始从"框架内部协议"变成"开放协议"

这是 1.x 后期非常值得关注的一次演进。

之前 LangChain 有：

复制代码

Tool
BaseTool
ToolKit
langchain-mcp-adapters

后来 MCP 被越来越多 Agent 平台采用，LangChain 先通过独立的 langchain-mcp-adapters 对接 MCP server。

到了 LangChain 1.4.0，MCP 支持正式进入：

复制代码

langchain.mcp

核心是：

复制代码

MCPAdapter

并替代原先独立的 langchain-mcp-adapters 作为主路径。

现在一个 MCPAdapter 可以接：

URL
stdio local server
in-process server
多 server 配置
已存在的 FastMCP client

然后：

ini 复制代码

tools = await adapter.list_tools()

直接把 MCP tools 接到：

scss 复制代码

create_agent(...)

中。

这一步很重要。

因为它实际上把 LangChain 的 Tool 抽象和 MCP 的 Tool 抽象连接起来了：

arduino 复制代码

                MCP Ecosystem
                     │
                     ↓
              MCP Server
                     │
                     ↓
                 MCPAdapter
                     │
                     ↓
              LangChain Tool
                     │
                     ↓
                 Agent

于是 Agent 的工具来源开始从：

复制代码

开发者自己写 Tool

变成：

diff 复制代码

Python Tool
+
Provider Built-in Tool
+
MCP Tool
+
Subagent Tool

这会显著降低 Agent 接入外部能力的成本。

十三、MCP 进一步解决了一个以前很麻烦的问题：工具发现与能力元数据

1.4 的 MCP adapter 不只是"把一个函数转成 LangChain Tool"。

它还会保留 MCP 的 metadata，例如：

sql 复制代码

server identity
tool annotations
destructive_hint

等信息。

这就带来一个很有价值的工程能力：

Tool 不再只是一个 callable，而开始成为一个带 provenance、permission、semantic hints 的 capability object。

比如：

复制代码

delete_customer

如果带有：

ini 复制代码

destructive_hint = true

那么 Agent Runtime 就可以自动把它放进：

swift 复制代码

Human approval required

这一类 policy。

因此 MCP 和 HITL/Middleware 并不是两条孤立的线，实际上它们正在逐渐汇合。

十四、LangChain 开始面对一个更大的问题：复杂 Agent 到底怎么写？

做到这里，create_agent() 已经非常强了。

但是还有一个现实问题：

普通 agent loop：

复制代码

think → tool → think → tool → answer

并不适合所有复杂任务。

例如：

"帮我研究一家公司的 AI 战略，搜索 30 个网页，读取 PDF，写报告，运行一些数据分析，最后生成一个带引用的结果。"

这已经不是简单的 tool calling。

它需要：

Planning
Context management
Filesystem
Subagents
Long-term memory（长期记忆）
Task decomposition（分解）
Sandbox
Human approval

于是 LangChain 生态里又出现了一个更高层的东西：

Deep Agents。

十五、Deep Agents：从 Agent Loop 走向 Agent Harness

这里需要特别澄清：

Deep Agents 不是 langchain package 本身。

它是 LangChain 生态中的独立 SDK，构建在 LangChain agent building blocks 和 LangGraph runtime 之上。官方把它称为：

Agent harness。

其核心能力包括：

arduino 复制代码

Planning
Filesystem
Subagents
Memory
Skills
Human-in-the-loop
Sandbox
Context management

一个 Deep Agent 已经不只是：

复制代码

LLM + Tools

而更接近：

复制代码

Agent
├── Planner
├── Filesystem
├── Memory
├── Skills
├── Subagents
├── Middleware
└── Durable Runtime（持久运行时）

这和 Cursor、Claude Code、Codex 一类 coding/research agent 的系统结构就开始比较接近了。

十六、Filesystem：这是 Deep Agents 一个很重要的设计

为什么 Agent 需要 filesystem？

因为一个现实问题是：

Context window 不是无限的。

假设 Agent 连续调用：

css 复制代码

Web Search
PDF Parse
Database Query
Code Execution

把所有结果一直塞进 messages，context 会迅速膨胀。

Deep Agents 的做法是引入 filesystem abstraction：

复制代码

StateBackend
FilesystemBackend
StoreBackend
CompositeBackend
Sandbox backend

让 Agent 把大块中间结果放到文件里，需要时再读取。

这个设计其实非常值得借鉴。

它的核心思想是：

Context 不应该等于 Memory。

或者说：

kotlin 复制代码

Short-term context
        +
Externalized working memory
        +
Long-term memory

才是复杂 Agent 比较合理的数据模型。

十七、Subagents：LangChain 开始解决"Context Bloat（膨胀）"

Deep Agents 又引入了 subagent。

这不是简单意义上的：

css 复制代码

Agent A 调 Agent B

而更重要的是：

Context Isolation（隔离）

比如主 Agent：

复制代码

Research task

把：

复制代码

搜索
PDF 分析
代码分析

分别交给不同 subagent。

每一个 subagent 都有独立 context。

最后只把 summary 返回给主 Agent。

官方对这一点的解释非常直接：subagent 最重要的价值之一，就是避免大量工具输出把主 Agent 的 context window 塞满。

因此复杂 Agent 的结构开始从：

vbnet 复制代码

Single giant（巨型） agent

走向：

复制代码

Supervisor
   ├── Researcher
   ├── Coder
   ├── Data Analyst
   └── Writer

但这些 subagents 并不一定共享完整上下文。

这其实更接近大型软件系统的：

css 复制代码

service isolation

思想。

十八、Skills：从"Prompt"走向"可复用能力包"

Deep Agents 又进一步引入了 Skills。

一个 skill 通常对应一个目录：

markdown 复制代码

skills/
  └── financial-analysis/
      ├── SKILL.md
      ├── scripts/
      └── references/

Agent 并不是启动的时候把所有东西都塞进 system prompt。

而是：

bash 复制代码

发现 skill
   ↓
读取 SKILL.md
   ↓
需要时加载 references/scripts
   ↓
执行

这叫做：

Progressive Disclosure（渐进式披露）

官方明确把 Skills 定义为 reusable agent capabilities，并强调"按需加载"以降低 context 成本。

从软件工程角度，这其实就是：

复制代码

Prompt Package

或者：

sql 复制代码

Procedural Knowledge Module

所以 Agent 开发开始出现类似传统软件工程的：

java 复制代码

library
package
module
plugin

这些概念。

十九、Memory 也开始被重新定义

Deep Agents 的 Memory 不再简单等于：

bash 复制代码

chat history

它开始区分：

arduino 复制代码

short-term context
long-term memory
procedural memory（程序性记忆）
episodic memory（情节记忆）

例如 AGENTS.md 可以成为长期上下文，而 Skills 则更像 procedural memory。

这一点非常值得关注。

因为过去很多项目都把"memory"理解为：

复制代码

Vector DB

而 LangChain 现在的思路更接近：

ini 复制代码

Memory ≠ Vector Search

Memory = Persistent Context（持久化上下文）

真正的 memory 可能存在：

perl 复制代码

Database
Store
Filesystem
Skill
AGENTS.md
structured state

里面。

这也是 AI Agent 工程开始从：

LLM application engineering

走向：

Agent systems engineering

的一个标志。

二十、所以 LangChain 1.x 到底解决了什么？

如果把 1.0 之后这些功能压缩成几个工程问题，会更加清晰。

1. "模型不一样"怎么办？

LangChain 通过：

diff 复制代码

Unified model interface
+
Model Profile
+
ProviderStrategy
+
Provider-specific extras
+
Content Blocks

解决。

2. "Agent 不稳定"怎么办？

通过：

复制代码

Retry
Fallback
Limits
Structured Output
Guardrails
PII

解决。

3. "Agent 太黑盒"怎么办？

通过：

vbnet 复制代码

Middleware
Event Streaming
LangSmith tracing

解决。

4. "Agent 需要人工控制"怎么办？

通过：

vbnet 复制代码

HumanInTheLoop
Interrupt
Persistence
Resume

解决。

5. "工具生态太碎片化"怎么办？

通过：

复制代码

MCP
Tool abstraction
Provider built-in tools

逐渐解决。

6. "长任务 context 爆掉"怎么办？

通过：

复制代码

Summarization
Context editing
Filesystem
Subagents

解决。

7. "Agent 越做越复杂"怎么办？

通过：

复制代码

Deep Agents
Skills
Memory
Subagents
Sandbox

往更高层的 Agent Harness 演进。

二十一、LangChain 的定位其实已经发生了一次变化

这可能是整个 1.x 演进里最值得资深工程师关注的地方。

早期的 LangChain 更像：

复制代码

LLM Application Framework

典型代码是：

复制代码

Prompt
  ↓
LLM
  ↓
Parser
  ↓
Retriever
  ↓
Chain

到了 1.0：

复制代码

Agent Framework

核心变成：

scss 复制代码

create_agent()

再到 1.x 后期：

复制代码

Agent Runtime / Agent Infrastructure

开始围绕：

复制代码

Agent
├── Model abstraction
├── Tool abstraction
├── Middleware
├── Streaming
├── HITL
├── Guardrails
├── MCP
└── Structured Output

而复杂任务进一步向：

复制代码

Deep Agent
├── Filesystem
├── Memory
├── Skills
├── Subagents
└── Sandbox

延伸。

于是 LangChain 的架构关系越来越清楚：

markdown 复制代码

                 ┌─────────────────────┐
                 │    Deep Agents      │
                 │   Agent Harness     │
                 └──────────┬──────────┘
                            │
                 ┌──────────▼──────────┐
                 │      LangChain      │
                 │ Agent Building API  │
                 │ Model / Tool / MW   │
                 └──────────┬──────────┘
                            │
                 ┌──────────▼──────────┐
                 │      LangGraph      │
                 │ Runtime / State     │
                 │ Durable Execution   |
                 |    (持久化执行)      │
                 └─────────────────────┘

官方现在也是按照类似思路描述三者分工。

二十二、一个很重要的趋势：LangChain 正在主动减少"魔法"

这一点对于资深工程师尤其重要。

过去很多开发者对 LangChain 的批评是：

"抽象层太多。"
"Chain 太 magic。"
"不知道内部发生了什么。"

到了 1.x，LangChain 的方向其实是在反过来减少这种 magic。

核心 API 越来越简单：

ini 复制代码

agent = create_agent(...)

但真正复杂的行为，都被拆到了显式的：

perl 复制代码

middleware
state
runtime
tools
response_format
context
store
interrupt

里面。

也就是说：

简单场景更简单，复杂场景则更加显式。

而这恰恰是成熟框架的典型演进路径。

二十三、如果现在开始做一个企业级 AI Agent，应该怎么理解 LangChain？

一个比较合理的技术决策模型是：

简单 Agent

只需要：

scss 复制代码

create_agent(...)

就够了。

例如：

复制代码

客服 Agent
内部知识助手
简单数据查询 Agent

中复杂度 Agent

开始加入：

复制代码

Middleware
Structured Output
HITL
Retry/Fallback
Streaming

例如：

复制代码

销售助理
金融分析 Agent
企业审批 Agent

工作流 + Agent 混合系统

如果业务流程明显是：

css 复制代码

 A
 ↓
判断
 ├── B
 ├── C
 └── D
 ↓
汇总

或者存在：

perl 复制代码

parallel
routing
state machine
human approval
saga
retry

那么应该直接下沉到：

复制代码

LangGraph

而不是强行让一个 Agent 解决所有问题。LangChain 的 middleware 本身也运行在 create_agent 返回的 LangGraph runtime 中，并且 Agent 可以作为更大 StateGraph 的 node/subgraph 使用。

复杂任务 Agent

如果开始出现：

复制代码

planning
filesystem
subagents
skills
memory
sandbox

那么 Deep Agents 会比从零手撸 Agent loop 更合适。

二十四、从工程实践角度，我认为 1.x 最值得关注的不是"功能数量"，而是这 5 个变化

第一，Agent 开始拥有 Runtime

以前：

r 复制代码

LLM call

现在：

复制代码

Agent execution

这两者不是一个层次。

第二，Context 开始成为一等公民

现在越来越重要的问题不是：

"Prompt 写得好不好？"

而是：

"在第 N 次模型调用的时候，模型到底应该看到什么？"

Middleware、Summarization、Context Editing、Filesystem、Subagents、Skills 都是在回答这个问题。

第三，Tool 开始成为真正的 Capability

Tool 已经不只是：

ruby 复制代码

def search():
    ...

而越来越接近：

ruby 复制代码

Capability
├── schema
├── metadata
├── permissions
├── provenance
├── retry policy
└── execution policy

MCP 恰好又把这个方向进一步标准化。

第四，Agent 开始接受"治理"

真正的企业 Agent 不可能完全 autonomous。

它必须拥有：

复制代码

policy
approval
audit
guardrail
limits
fallback

这也是为什么 Middleware/HITL/PII/Retry/Fallback 会成为 1.x 的高频建设方向。

第五，LangChain 正在把"复杂 Agent 的复杂性"下沉

真正复杂的 Agent 系统通常需要：

复制代码

State
Persistence
Interrupt
Streaming
Subagent
Memory
Filesystem
Sandbox

LangChain 自己不再试图把所有东西塞进一个大框架，而是逐步形成：

markdown 复制代码

LangChain
    +
LangGraph
    +
Deep Agents
    +
LangSmith

这样的分层生态。

这可能是 LangChain 在 1.0 之后最重要的架构选择。

二十五、最后：怎么看待 LangChain 1.0 之后的这轮演进？

我认为最准确的评价不是：

"LangChain 又加了很多新功能。"

而是：

LangChain 正在完成从"LLM framework"到"Agent application infrastructure"的转型。

这个转型可以浓缩成一条时间线：

sql 复制代码

LangChain v0.x
    │
    │  Chains / Prompts / Retrievers
    ▼
LangChain v1.0
    │
    │  create_agent
    │  content_blocks
    │  middleware
    ▼
LangChain v1.1
    │
    │  model profiles
    │  adaptive summarization
    │  retry / moderation
    ▼
LangChain v1.2
    │
    │  provider-specific capabilities
    │  native structured output
    ▼
LangChain v1.3
    │
    │  event streaming v3
    │  richer middleware / tool selection
    ▼
LangChain v1.4
    │
    │  first-party MCP
    ▼
Agent Infrastructure
    │
    ├── LangChain → Agent abstraction
    ├── LangGraph → Runtime / orchestration
    ├── MCP → Tool ecosystem
    ├── Middleware → Control plane
    ├── LangSmith → Observability / evaluation
    └── Deep Agents → Agent harness

截至 2026 年 9 月，LangChain 1.4.0 已正式把 MCP 纳入 langchain.mcp，而 1.x 的版本策略也明确以 minor release 持续增加能力，同时保持 1.x 公共 API 的向后兼容；这意味着 LangChain 1.x 并不是"重写后停住的稳定版"，而是一个仍在快速演进的 Agent infrastructure line。

因此，对于已经有多年 AI 应用开发经验的工程师，我认为理解 LangChain 1.x 最好的方式，不是背 API，而是理解下面这几个抽象：

ini 复制代码

Model       = Intelligence
Tool        = Capability
Agent       = Decision Loop
Middleware  = Control Plane
LangGraph   = Runtime
MCP         = Capability Protocol
Memory      = Persistent Context
Deep Agent  = Task Execution Harness

一旦从这个角度看，LangChain 1.0 之后的大多数设计其实都可以串起来。

它真正想解决的问题，也已经非常明确：

不是"怎样调用一个大模型"，而是"怎样让一个由模型驱动的软件系统，可靠地完成一个真实世界的长期任务"。

这也是为什么到了今天，LangChain 最值得研究的部分已经不再是早期那些 Chain API，而是：

Agent + Middleware + Context Engineering + Runtime + Tool Protocol + Durable Execution。

这几个方向，才是 LangChain 1.x 真正留下来的架构资产。

主要参考

LangChain 官方文档：《What's new in LangChain v1》------create_agent、Middleware、langchain-classic、内容块等。
LangChain 官方 Changelog------记录 v1.1、v1.2、v1.3、v1.4 的官方版本变化。
LangChain 官方 Middleware 文档------Middleware hook 与内置 middleware。
LangChain 官方 Structured Output / Models 文档------ProviderStrategy、ToolStrategy、Model Profiles。
LangChain 官方 Event Streaming 文档------v3 event streaming 与 typed projections。
LangChain 官方 MCP 文档与 1.4.0 changelog------MCPAdapter、elicitation、认证和 metadata。
LangChain 官方 Deep Agents 文档------filesystem、memory、skills、subagents、sandbox 等。
LangChain GitHub Releases------1.x 实际发布节奏及 patch/minor release 内容。