AI MaaS导航
提交应用
单项目深读

LangChain 把 agent 拆成模型、工具、提示词和中间件

LangChain 以 create_agent 为核心，把 agent 拆成模型、工具、提示词与中间件四部分；

|INS-0005

一个 agent 框架最容易犯的错，是把「简单」做复杂。LangChain 这次反过来了：官网首页对它的定义只有一句——create_agent，一个最小、高度可配置的 agent harness，从模型、工具、提示词和中间件里，组合出你实际需要的那一个 agent。

这句话值得当真。它意味着 LangChain 不再把自己包装成「什么都能干的大而全框架」，而是承认：agent 的本质就是把四样东西拼起来，框架的职责是把拼接这件事做得可配置、可替换、可演进。

从一行模型调用开始的抽象层

README 的 Quickstart 短到有点反常：

bash
uv add langchain
python
from langchain.chat_models import init_chat_model

model = init_chat_model("openai:gpt-5.5")
result = model.invoke("Hello, world!")

两个动作：装包，初始化模型，调用。没有 chain，没有 agent，没有工具注册。这是刻意的——LangChain 的入口是「统一模型接口」，而不是「agent 编排」。

init_chat_model 接受的是 provider:model 形式的字符串。这个设计背后是 README 里反复强调的一条能力：model interoperability。团队在选型阶段会不断换模型，LangChain 的抽象层让换模型不打断工程节奏。字符串里换一个 provider 前缀，调用方式不变。

这条抽象线还延伸到了 embeddings、vector stores、retrievers、tools。README 把它们统称为「a standard interface」——标准接口是 LangChain 整个项目的骨架，agent 只是长在这副骨架上的东西。

四层结构：agent 是怎么被拼出来的

把 README 和官网描述对照着看，LangChain 的架构可以归纳成下面这几层。每一层的组件名都来自素材本身，不是外部推测。

层组成职责
接口层init_chat_model、chat & embedding models、vector stores、retrievers、tools & toolkits用统一接口屏蔽不同 provider 的差异，模型可换、工具可插
组合层create_agent（agent harness）把 model、tools、prompt、middleware 四要素组合成一个可运行的 agent
编排层LangGraph低层 agent 编排框架，处理需要可靠执行复杂任务的场景
上层封装Deep Agents在 LangChain 之上，内置 planning、subagents、file system 使用等常见模式
运行与观测LangSmith、LangSmith Deploymentagent 的 eval、可观测性、调试，以及长时有状态 workflow 的部署与扩缩

这个分层有个清晰的意图：默认路径尽量短，复杂需求逐层下沉。

  • 只想调模型？停在接口层，两行代码。
  • 要一个能调工具的 agent？用 create_agent，在四要素上做配置。
  • 要可控的、多步的、需要状态和分支的编排？交给 LangGraph。
  • 要开箱即用的 planning、子 agent、文件系统？用 Deep Agents，它建在 LangChain 之上。

README 里那句「Flexible abstraction layers」说的就是这件事：从高层 chain 快速起步，到低层组件细粒度控制，抽象层级由你选，应用复杂度增长时框架跟着长。

数据流向上也顺着这个分层走：模型调用经接口层统一；工具调用由组合层的 harness 调度；需要跨步骤保持状态、做分支和循环时，下沉到 LangGraph；整个过程的事件与轨迹经 LangSmith 观测。

中间件：这次真正的差异点

官网描述里最不寻常的词是 middleware。

大多数 agent 框架的四要素是「模型、工具、提示词」，LangChain 多塞了一个中间件。这意味着 agent harness 不是把四样东西硬编码进一个循环，而是在循环的关键位置留了可插拔的钩子——你可以在不重写 agent 主体的前提下，改变它的行为。

素材没有展开中间件的具体接口和生命周期位置，这里不做猜测。但从「minimal, highly configurable」这个自我定位能读出取舍：主体保持最小，配置性交给中间件承担。这跟「堆功能进核心」是两条路。前者核心稳定、扩展在边缘；后者核心膨胀、每次改动都牵一发动全身。LangChain 选了前者。

生态不是附属品，是架构的一部分

README 把生态单独列了一节，并且明确说：框架可以独立使用，但也和 LangChain 产品无缝集成。列出的成员是：

  • Deep Agents — 内置 planning、subagents、file system 的 agent
  • LangGraph — 低层编排框架，面向可靠处理复杂任务
  • Integrations — chat & embedding models、tools & toolkits 等
  • LangSmith — agent 的 eval、observability、debugging
  • LangSmith Deployment — 面向长时有状态 workflow 的部署与扩缩平台

这几个不是并列的产品清单，而是按「抽象高度」和「生命周期阶段」排布的：写 agent 用 LangChain / Deep Agents，编排用 LangGraph，调优用 LangSmith，上线用 LangSmith Deployment。一个项目从原型走到生产，路径是连续的。

和同主题项目比，它站在哪一格

项目语言定位与 LangChain 的关系
LangChainPythonagent 开发平台，统一模型/工具/向量库接口 + create_agent harness—
AutoGPTPython给一个目标，自主规划步骤、调用工具、迭代执行更偏「成品 agent 应用」，LangChain 更偏「造 agent 的底座」
hermes-agentPython把 prompt、工具调用、workflow 串起来，接自己的 LLM 调本地 CLI 或外部 SDK同为 agent 框架，LangChain 的差异在统一接口层与生态分层
ECCJavaScript给 Claude Code、Codex、Cursor 等现有 agent 加装 skills 与记忆层不改 agent 本体，做外挂增强；LangChain 是从接口层开始搭
firecrawlTypeScript网页抓取解析成 Markdown / 结构化 JSON，喂给 LLM 与 RAG数据供给端，可作为 LangChain 的工具或检索数据源
ollamaGo本地一条命令跑模型，提供 CLI 与 SDK模型供给端，与 LangChain 的模型抽象层互补

这张表能看出一件事：LangChain 的位置在「供给端」和「应用端」之间。Ollama 供模型，Firecrawl 供数据，AutoGPT 是跑起来的成品，ECC 是给成品加装能力。LangChain 做的是中间那层——把供给接进来，把应用搭出去。

这也解释了它为什么强调 model interoperability：它站在中间，上游的 provider 会变，下游的应用需求会变，唯一能稳定提供价值的就是那层标准接口。

仓库本身的事实

项值
源码github.com/langchain-ai/langchain
官网文档docs.langchain.com/langchain
语言Python
许可MIT
星标147986
forks24837
open issues657
创建时间2022-10-17
最近推送2026-10-17
topicsagents, ai-agents, anthropic, chatgpt, deepagents, enterprise, framework, gemini, generative-ai, langgraph, llm, multiagent, openai, pydantic, python, rag, typescript

topics 里同时出现 langgraph、deepagents、rag、multiagent、enterprise，和 README 的分层是对得上的：它不是单一用途的库，而是一个覆盖从 RAG 到多 agent 到企业部署的框架族。pydantic 出现在 topics 里，说明类型与结构化输出在它的设计里占位置——这一点 README 没有展开，但可以从 topics 读出方向。

怎么选：三条路径

如果你的需求是下面三种之一，路径不一样：

  1. 只想统一模型调用。停在接口层，init_chat_model 加 invoke，不引入 agent 概念。这是 README 给的最小路径。
  2. 要一个能调工具的 agent。用 create_agent，在 model、tools、prompt、middleware 四个维度上配置。需要改行为时优先动中间件，而不是改 agent 主体。
  3. 要可控的多步编排，或开箱的 planning / 子 agent / 文件系统。往下走 LangGraph，往上走 Deep Agents。README 对这两者的定位写得很明确：LangGraph 是「controllable agent workflows」的低层框架，Deep Agents 是「higher-level package built on LangChain」。

还有一条不在代码里但 README 明确点出的路径：开发、调试、部署阶段接 LangSmith。观测和 eval 不是可选项，是这套分层的一部分。

一句话的取舍

LangChain 这次的核心主张可以压成一句：agent 框架的价值不在替你决定 agent 长什么样，而在让你能精确地组合出你要的那一个，并且在底层技术变化时不用推倒重来。

create_agent 是这句话的落点，中间件是它的弹性来源，统一接口层是它的稳定底座，LangGraph 与 Deep Agents 是它在两个方向上的延伸。至于这条路走不走得通，取决于中间件的表达能力够不够——素材里没给接口细节，这里不下结论。

想上手，从 README 那两行开始就够了：装包，init_chat_model，invoke。先把模型调通，再决定要不要往上加工具、加中间件、加编排。

返回解读列表