目录前言一、从一个困惑说起二、官方分三类产品依赖上却是四层三、四个层次逐层拆第 1 层积木langchain-core第 2 层运行时LangGraph第 3 层薄壳create_agent middleware第 4 层套件Deep Agents四、一张调用链图看清全貌五、一次选型定位该落到哪一层六、工程化要点双向认知参考文献前言本系列贯穿一条英文概念主线Agent Runtime → Harness。本文先建立整个系列的认知地基为什么我们讲「四个层次」而不是你更常听到的「三个框架」。一、从一个困惑说起如果你刚接触 LangChain 生态大概率会被这三个词绕晕LangChain、LangGraph、Deep Agents。它们是三个递进的框架吗是不是「先学 LangChain再学 LangGraph最后学 Deep Agents」我该从哪个入手为什么 LangChain 官网一会儿说自己是「框架」一会儿又冒出一个「运行时」、一个「套件」这套困惑不是你的问题是这个生态自己给自己挖的坑——它把产品和依赖层次两件事混在一起讲读者自然分不清。这篇先做一件事把「三类产品」和「四个层次」同时摆在你面前讲清楚它们各是什么、又怎么对应。这是后面各篇的地基值得现在花五分钟立稳。二、官方分三类产品依赖上却是四层先看官方口径。官方把 Agent 开发生态分成三类Runtime / Framework / Harness[1]——LangChain 自家三个产品 LangGraph / LangChain / Deep Agents SDK 正好各占其一[2]官方类别产品一句话定位Runtime运行时LangGraph控制 Agent智能体怎么执行图、状态、检查点、流式Framework框架LangChain提供组件和create_agent工厂Harness套件Deep Agents SDK把一套内置中间件栈各自注入常用工具打包好的开箱即用套件按产品数就是3 类。这没错。但注意两点一是这个「三类」是对整个生态的分类——每一类里都还有第三方选项Runtime 还有 Temporal / InngestFramework 还有 CrewAI / OpenAI Agents SDKHarness 还有 Claude Agent SDK 等只是本系列只讲 LangChain 自家的三个二是官方产品名现在是Deep Agents SDK另有独立的 Deep Agents CLI本文为行文简洁下文一律简称Deep Agents。但落到依赖关系上事情变了——因为LangChain 不是一个整块。它被 LangGraph 从中间「劈」成了两半langchain-core积木messages / tools / models / bind_tools ← LangChain 的一半在 LangGraph 之下 ↑ 依赖 LangGraph运行时图、状态、Checkpoint、流式、HITL ↑ 依赖 create_agent middlewareLangChain 薄壳 ← LangChain 的另一半在 LangGraph 之上 ↑ 依赖 deepagents / create_deep_agentDeep Agents 套件所以是「3 类产品、4 层依赖」。多出来的那一层正是把 LangChain 劈开的结果langchain-core我们叫它「积木」在 LangGraph之下——它是 LangGraph 的地基LangGraph 依赖它create_agent 中间件我们叫它「薄壳」在 LangGraph之上——它包在 LangGraph 外面是 LangGraph 的一层封装。这条是我全系列反复强调的铁律不要把 LangChain 画成一整块叠在 LangGraph 之上。很多人包括早期教程也包括我当年自己画的图都在这栽过跟头后果是讲create_agent的时候逻辑对不上——它明明「包着」LangGraph怎么会和「垫着」LangGraph 的langchain-core是同一个东西三、四个层次逐层拆从下往上看一层一层说清楚它「是什么、管什么」。第 1 层积木langchain-core最底层也是最「无聊」、最该先吃透的一层。它提供的是最小原子messages消息对象Human / AI / Tool / Systemtools工具的声明与描述models大模型的统一调用接口bind_tools把工具「绑」到模型上让模型知道它能调用什么以及后面讲检索与 RAG 的篇章要展开的检索组件Document / Embedding / Retriever 等。这一层不关心「Agent 怎么循环、怎么记忆、怎么中断」它只关心「一个消息长什么样、一个工具怎么声明、一次模型调用怎么发」。你后面写的每一行from langchain_core ... import用的都是这层。为什么它是最底层因为 LangGraph 自己就是建立在它之上的——Agent 场景下StateGraph里流动的状态通常是MessagesState一组messages不过状态本身可以是任意TypedDict结构。节点里调用的就是models和tools。第 2 层运行时LangGraphLangGraph 是执行引擎回答的问题是「Agent 每一步该怎么走」。它提供了图 / 节点 / 边把 Agent 拆成一个个节点调用模型、调用工具用边串成执行流状态StateAgent 每一步的输入输出、累积的对话历史都存在一个显式的状态对象里Checkpoint检查点每一步的中间状态可持久化支持断点恢复官方称时间旅行time travel讲 Checkpoint 与断点恢复的篇章会专门展开流式stream把执行过程以 token / 节点为单位推出来Human-in-the-loopHITL人在环在任意节点暂停等人类确认再继续讲 HITL 的篇章会给出底层interrupt()。一句话积木是「零件」运行时是「流水线」。LangGraph 决定零件按什么顺序、在什么状态驱动下流转。第 3 层薄壳create_agent middleware这是 LangChain 在 LangGraph之上的那半。LangGraph 已经能跑 Agent但手写StateGraph太啰嗦——一个「调模型 → 调工具 → 再调模型」的最简 Agent你要自己写节点、写条件边、写循环终止。于是 LangChain 提供了一个create_agent工厂一行代码生成一个标准的「模型 工具」循环图还附带一套中间件middleware栈让你在「模型调用前 / 调用后」「工具调用时」等时机插入自定义逻辑讲中间件的篇章会专门展开。所以「薄壳」的「薄」是刻意的它不改变LangGraph 的执行语义只是在外面包了一层更省事的 API。你要控制得更细随时可以「下沉」回 LangGraph。第 4 层套件Deep Agents最顶层最省力。create_deep_agent来自deepagents包在create_agent的基础上再打包一层把「写计划、读写文件、执行代码、管理长期记忆、人在环」这些生产级 Agent 几乎都要用的东西作为一套内置中间件栈各自注入内置工具预先装好。它和薄壳的关系就像薄壳和运行时套件是薄壳的薄壳薄壳是运行时的薄壳。你从第 4 层起步需要什么控制力就逐层往下沉。四、一张调用链图看清全貌认知篇不贴代码后面每篇都有能跑的代码用一张调用链图把四层的关系钉死。假设你最终写下这样一行fromdeepagentsimportcreate_deep_agent agentcreate_deep_agent(...)这行代码背后是自上而下的一串依赖调用你的代码 │ 调用 ▼ create_deep_agent(...)← 第4层 套件 │ 内部调用 ▼ create_agent(...) middleware 栈 ← 第3层 薄壳 │ 内部调用 ▼ StateGraphnodes / edges / state ← 第2层 运行时 │ 依赖 ▼ langchain-coremessages / tools / models / bind_tools ← 第1层 积木记这张图时抓两点方向是自上而下的依赖上层调用下层下层不反过来依赖上层。create_deep_agent不认识你的业务它只调用create_agentcreate_agent不认识「写计划」它只构建StateGraphStateGraph不关心「Agent」它只流转messages。LangChain 横跨两层create_agent薄壳在 LangGraph 之上langchain-core积木在 LangGraph 之下。这就是「3 类产品 / 4 层」的由来——Framework这一个产品拆出了两个依赖位置。五、一次选型定位该落到哪一层认知篇的「实战」不是写代码而是练一种选型直觉拿到一个需求或一个报错能立刻判断「它该由哪一层来负责」。这是我这些年排查问题和做架构评审时最高频的动作给你几道我真实遇到过的情况试着先自己想再看定位。场景 A「我要一个能调工具、带记忆、能写文件的 Agent最好明天就能演示。」→ 落第 4 层套件。create_deep_agent一行搞定规划、文件、记忆都是内置的。别手写StateGraph——那是把「明天要演示」的活干成「下周」。场景 B「我要在每次调用模型之前注入一段动态的系统提示比如按用户等级加载不同人设。」→ 落第 3 层薄壳。这是create_agent的中间件before_model干的活。用第 4 层做不了这么细的「卡点」用第 2 层又太重。场景 C「我要一个多智能体编排一个 supervisor 派单给几个子 Agent各自有独立的检查点和中断点还要能回放任一步。」→ 落第 2 层运行时。多图、独立 checkpoint、断点恢复/回放这是StateGraph 子图的地盘。第 3、4 层是「单 Agent 循环」的封装硬套多智能体会拧巴。场景 D报错AttributeError: BaseChatModel object has no attribute bind_tools发生在你往 LangGraph 节点里传模型的时候。→ 这是第 1 层积木的问题——bind_tools是挂在模型对象上的方法第 1 层的模型接口报这个错几乎总是因为你传进去的不是 ChatModel 对象比如拿成了裸 provider 模型、旧的BaseLLM或对象被错误包装。顺着「它属于第 1 层」去查你传进去的模型对象而不是在 LangGraph 的图逻辑里瞎找。我的选型口诀能用高层就绝不手写底层但一旦你要「精确控制」某一步就一路下沉到管那一步的那层别在高层的缝里硬抠。这也正是官方推荐的方向——默认从 Deep Agents 开始需要控制再下沉讲选型决策的篇章会把它展开成一套决策树。六、工程化要点双向认知最后把这个「双向认知」立住它能解释整个系列的编排逻辑自底向上 依赖顺序学习 / 理解时的顺序langchain-core→ LangGraph →create_agent→ Deep Agents。你要搞懂「为什么create_agent能包住 LangGraph」就得先知道 LangGraph 依赖什么、LangGraph 又能提供什么。所以本系列从 LangGraph 讲起而不是从「最省力的 Deep Agents」讲起——那不是最省力是「会用但不懂」。自顶向下 使用顺序真实开发时的顺序Deep Agents →create_agent→ LangGraph →langchain-core。上手永远是最高层逐层下沉直到拿到你要的控制力。两者不矛盾就像「装配一台发动机要从零件理解起但开车出门是从点火起步」。本系列 Part 1 快速起步、Part 2 系统讲运行时、Part 3 讲薄壳与积木、Part 4 讲套件、Part 5 组装成主案例正是这条双向认知的落地。记住本文最该带走的一句话官方是 3 类产品Runtime / Framework / Harness依赖上是 4 层——因为 LangChain 被劈成了「积木下 薄壳上」两块。这句话会是后面各篇反复回来校准的坐标原点。参考文献[1] LangChain 官方文档 · ConceptsProductsRuntimes, frameworks, harnesses— https://docs.langchain.com/oss/python/concepts/products[2] LangChain 官方博客《Deep Agents vs LangChain vs LangGraph》— https://www.langchain.com/blog/deep-agents-vs-langchain-vs-langgraph[3] LangGraph 官方文档 · Overview — https://docs.langchain.com/oss/python/langgraph/overview 更多专栏系列文章可以查看博客主页 若文章对你有所触动恳请点赞 ⭐ 关注 ⭐ 收藏